Engenharia de Software (ES) é o estabelecimento e o emprego de sólidos princípios de engenharia para obtenção de software de forma econômica, que seja confiável e eficiente em máquinas reais (Mahoney, 2004).
Em outra visão, Musa (1975), define ES como a aplicação da abordagem sistemática, disciplinada e quantificável no desenvolvimento, na operação e na manutenção do Software.
Em 1968, diante da crise do software, em uma conferência na Organização do Tratado do Atlântico Norte (OTAN), Mc Ilroy, conforme mostrado na Figura 11 apresenta as primeiras ideias e os benefícios referentes ao conceito que existe de reuso de software.
Figura 11: Disseminação das primeiras ideias sobre reuso de software
Fonte: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/N1968
Complementarmente, Krueger (1992) relata que durante esta conferência foi apresentada uma definição simples, porém poderosa de reuso de software, momento em que, segundo sua opinião, deveria ter se tornado um padrão em Engenharia de Software.
2.4.1 Reuso de Software
Entre as técnicas de programação, o Reuso de Software é uma das menos evidenciadas, pela sua complexidade e ao baixo conhecimento do corpo técnico a respeito do assunto. Com a utilização desta técnica, para um código desenvolvido, testado e disponibilizado em ambiente de produção, este poderia ser reutilizado em outros cenários similares.
No ano de 1992, Charles Krueger relatou um cenário em que as empresas buscavam melhorias em seu processo de criação de software, principalmente no que diz respeito a
qualidade e produtividade. Neste contexto, Krueger (1992) define Reuso de Software como o processo de criar novos aplicativos a partir de já existentes ao invés de construí-los desde o início.
O reuso de software possibilita, de acordo com Freeman (1987), o uso destes artefatos em outro cenário para o qual não foi produzido inicialmente. Em visão complementar, Werner e Braga (2000), relatam que o reuso necessita de uma sistemática ampla e formal para realizá-la, podendo obter os benefícios e dificuldades descritos no Quadro 3.
Quadro 3: Benefícios e Dificuldades na Abordagem de Reuso de Software Benefícios - Qualidade - Produtividade - Redução de Custos - Redução de Tempo - Flexibilidade Dificuldades
- Identificação, recuperação, compreensão
- Modificação, composição
- Qualidade de componentes
- Barreiras psicológicas, legais e econômicas
- Necessidade de incentivos
Para determinar boas propriedades para reuso de software, Krueger (1992) define cinco dimensões:
Abstração - Identificar unidades de conhecimento reutilizáveis e representá- los de forma abstrata;
Classificação - Armazenar o conhecimento reutilizável em uma base de conhecimento classificada e indexada;
Seleção - Consultar o conhecimento reutilizável em forma parametrizada;
Especialização - Modificar o conhecimento reutilizável para atender novas situações; e
Integração - Combinar o conhecimento reutilizável com seu projeto.
Pode-se citar como exemplos clássicos de reuso de software: as linguagens de programação de alto nível, como a linguagem Java (Gosling, 2000), frameworks, como o Swing (Ekstein et al., 1998) que atua na construção de interfaces gráficas.
Nesta área, existem diversas abordagens, entre elas o DBC (Sametinger, 1997), Linguagens Específicas de Domínio, mais comumente conhecidas pela sua sigla DLS, referindo-se ao termo em inglês Domain Specific Languages (DSL) (Fowler, 2010).
Além das abordagens citadas, existem técnicas como Reengenharia de Software (Jacobson e Lindström, 1991), frameworks de aplicação (Camargo e Masiero, 2005), padrões de projeto (Gamma et al., 1994), desenvolvimento de software orientado a aspectos (Elrad e Bader, 2001), entre outras abordagens menos populares.
Na Seção 2.4.1.1 serão detalhados os conceitos de DBC, que possui abordagens bem sucedidas em integração com aplicações na área de RV (Oliveira et al, 2009), uma vez que componentes são reutilizáveis, intercambiáveis, de uso geral ou específicos, podendo interagir ainda com outros componentes.
2.4.1.1 Desenvolvimento Baseado em Componentes
Segundo Werner e Braga (2000), componentes de software são artefatos autocontidos, identificáveis, possuindo função específica com interfaces bem definidas, de forma a propiciar a sua reutilização em outros ambientes.
Uma visão complementar, Singhal e Zyda (1999) definem componentes como uma unidade que possui interfaces especificadas previamente definidas, por meio de contratos e dependências de contexto explícitas.
Nesta abordagem, um aplicativo é criado a partir da integração entre diversos componentes, fazendo com que, após serem desenvolvidos possam ser reutilizados integralmente em outros aplicativos, viabilizando o aumento de produtividade (Sommerville, 2003).
Morisio (2000) relata que é necessária a introdução de processos de software específicos ao invés de adaptar os processos tradicionais ao paradigma DBC, que é uma das principais causas para fracasso na adoção do DBC. Complementarmente, Sommerville (2003) propõe um fluxo de atividades para o processo de desenvolvimento de sistemas baseados no paradigma DBC, mostrado na Figura 12.
Figura 12: Processo de Desenvolvimento de software baseado em DBC proposto por Sommerville
Segundo Henninger (1997), um ponto chave para obtenção de melhores resultados com DBC é a estruturação de um repositório para acesso e disponibilização dos componentes.
Para a estruturação de um repositório, Guo e Luqui (2000) elencaram no Quadro 4 os requisitos para estruturação de um repositório de componentes, que conforme Werner e Braga (2000) podem ser classificados em: locais, específicos a um domínio e de referência.
Quadro 4: Requisitos para Estruturação de um Repositório de Componentes
Interface para as operações básicas no manuseio de componentes (uso, pesquisa e disponibilização).
Disponibilização de documentação sobre cada componente.
Estrutura padrão para os componentes.
Esquema para classificação nos mais diversos domínios.
Fonte: Guo e Luqui, 2000
Compartilhando a mesma visão, Werner e Braga (2000) identificam que a chance de um desenvolvedor reutilizar um dado componente está diretamente relacionada a disponibilidade com que um componente possa ser localizado e recuperado.
Na Seção 2.5 serão relacionadas as ferramentas que trabalham com aplicação de DBC na área de RV, que é o foco deste trabalho, considerando ambientes nas nuvens, assim como ambientes que não estão nas nuvens.