Avaliação de técnicas de Linha de Produto de Software no processo de adaptação e manutenção de sistemas customizáveis

Texto

(1)UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. Avaliação de Técnicas de Linha de Produto de Software no Processo de Adaptação e Manutenção de Sistemas Customizáveis. Fernanda Almeida Passos. SÃO CRISTÓVÃO/ SE 2014.

(2) UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. Fernanda Almeida Passos. Avaliação de Técnicas de Linha de Produto de Software no Processo de Adaptação e Manutenção de Sistemas Customizáveis. Proposta de Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação (PROCC) da Universidade Federal de Sergipe (UFS) como parte de requisito para obtenção do título de Mestre em Ciência da Computação.. Orientador: Prof. Dr. Alberto Costa Neto. SÃO CRISTÓVÃO/ SE 2014.

(3) Fernanda Almeida Passos. Avaliação de Técnicas de Linha de Produto de Software no Processo de Adaptação e Manutenção de Sistemas Customizáveis. Proposta de Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação (PROCC) da Universidade Federal de Sergipe (UFS) como parte de requisito para obtenção do título de Mestre em Ciência da Computação.. BANCA EXAMINADORA. Prof. Dr. Alberto Costa Neto, Presidente Universidade Federal de Sergipe (UFS). Prof. Dr. Rohit Gheyi, Membro Universidade Federal de Campina Grande (UFCG). Prof. Dra. Leila Maciel de Almeida e Silva, Membro Universidade Federal de Sergipe (UFS).

(4) FICHA CATALOGRÁFICA ELABORADA PELA BIBLIOTECA CENTRAL UNIVERSIDADE FEDERAL DE SERGIPE. P289a. Passos, Fernanda Almeida Avaliação de técnicas de Linha de Produto de Software no processo de adaptação e manutenção de sistemas customizáveis / Fernanda Almeida Passos ; orientador Alberto Costa Neto. – São Cristóvão, 2014. 177 f. : il. Dissertação (mestrado em Ciência da Computação) Universidade Federal de Sergipe, 2014.. –. 1. Engenharia de software. 2. Software – Customização. 3. Software – Manutenção. 4. Computação – Metodologia. 5. Linha de Produto de Software – Técnica. I. Costa Neto, Alberto, orient. II. Título. CDU 004.416.6.

(5) Avaliação de Técnicas de Linha de Produto de Software no Processo de Adaptação e Manutenção de Sistemas Customizáveis. Este exemplar corresponde à redação final da Dissertação de Mestrado, sendo o Exame de Defesa da mestranda Fernanda Almeida Passos para ser aprovada pela Banca examinadora.. São Cristóvão - SE, 24 de setembro de 2014. ______________________________________ Prof. Dr. Alberto Costa Neto Orientador. ______________________________________ Prof. Dr. Rohit Gheyi Membro. ______________________________________ Prof. Dra. Leila Maciel de Almeida e Silva Membro.

(6) Dedicatória. À minha família.. vi.

(7) Agradecimentos Em primeiro lugar à Deus, por ter me conduzido durante toda essa caminhada me dando forças para prosseguir e superação a cada momento difícil. Senhor Deus, tu és a vida em mim! À minha família, meu esposo Fábio e meus filhos Eduardo e Guilherme, preciosos em minha vida, que mesmo sendo muito difícil entender as minhas ausências me deram apoio, acreditaram em mim e estiveram sempre comigo. Vocês são meu alicerce! Aos meus pais que me ensinaram que o aprendizado nunca é perdido e a educação é o maior patrimônio que os pais podem deixar para os seus filhos. Aos meus irmãos que sempre me incentivaram a fazer o mestrado. Ao meu orientador Alberto Costa Neto que muito admiro e respeito, pela dedicação e preciosos momentos de orientações, discussões e reflexões fundamentais para concretização deste trabalho e também para o meu crescimento quanto pesquisador. Pela paciência, incentivo e amizade nos momentos mais difíceis. Obrigada por ter acreditado na minha capacidade! Ao professor Methanias Colaço Júnior que teve uma participação fundamental neste trabalho através de seus ensinamentos e sugestões. À professora Leila Maciel de Almeida e Silva pelos ensinamentos, amizade e conselhos. Obrigada por me incentivar nos momentos mais difíceis. Te admiro! Ao professor Rohit Gheyi pelas sugestões e correções apresentadas no exame de qualificação. Aos alunos de iniciação científica, Galileu, Glayderson, Kleber e Raphael pelas contribuições prestadas durante toda essa caminhada. Aos meus companheiros de mestrado Christiano, Felipe e Leonardo pela paciência e incentivo, pelos momentos de estudo para disciplina de Métodos Formais e trabalhos conjuntos. Aos amigos e companheiros de equipe Levy e Danilo por terem assumido juntos com muito profissionalismo e dedicação às minhas atribuições no Núcleo de Tecnologia de Informação (NTI) da UFS. À minha amiga Ana Karina grande incentivadora desde o início desta caminhada e sempre torcendo por mim. Aos meus amigos Janisson e July pelo apoio e motivação nos momentos difíceis e pelos maravilhosos momentos de descontração. A toda equipe do NTI da UFS, principalmente minha chefe Estelamaris pelo apoio, confiança e compreensão e a Igor, Israel e Matheus pela contribuição que prestaram aos experimentos. Ao Instituto Nacional de Ciência e Tecnologia para Engenharia de Software (INES), pelo ambiente disponibilizado para vii.

(8) a execução dos experimentos. Por fim, aos docentes e discentes do PROCC que participaram de forma direta ou indireta desta caminhada. Este trabalho foi parcialmente apoiado pelo INES, financiado pelo CNPq, processos 573964/2008-4.. viii.

(9) "A grande conquista é o resultado de pequenas vitórias que passam despercebidas." PAULO C OELHO. ix.

(10) Resumo. Customizações em sistema de software open-source, tais como o desenvolvimento de artefatos específicos que atendam seus requisitos funcionais e não funcionais, pode ser licenciada às organizações adquirentes. Contudo, traz problemas futuros à manutenção do sistema, o qual paralelamente está em constante evolução pelos seus criadores. O maior desafio neste cenário é lidar com as evoluções do sistema original realizadas pelos criadores, que normalmente impactam os artefatos das organizações adquirentes. Neste contexto, a aplicação de técnicas de Linha de Produto de Software (LPS) surge como uma proposta para prover suporte na customização de software adquirido. Este estudo objetiva avaliar em um contexto real e através de experimentos controlados, o processo de adaptação e manutenção de sistemas customizados, comparando a abordagem atualmente usada nas customizações realizadas diretamente no código base do sistema original com as técnicas LPS AspectJ, FeatureHouse e XVCL. A seleção dessas técnicas para avaliação foi baseada em uma análise comparativa das técnicas levantadas no estudo sistemático realizado, tomando como premissa a possibilidade de criação de artefatos customizáveis e a implementação das variações separada do código base, mantendo-o intacto. Finalmente, após o experimento proposto neste estudo, resultados quantitativos e qualitativos sobre o uso das técnicas de LPS AspectJ, FeatureHouse e XVCL na adaptação e manutenção de sistemas customizáveis foram obtidos. Estes resultados mostram que FeatureHouse e XVCL foram consideradas equivalentes entre si e à abordagem atual. AspectJ, embora tenha se provado viável, demanda uma acentuada curva de aprendizado. Entretanto, a adoção de uma destas técnicas de LPS traz ganhos qualitativos devido à possibilidade de criar artefatos de software customizáveis e a separação das variações do código base do sistema. Palavras-Chave: Customização em aplicativo de software, Técnicas de Linha de Produto de Software, Variabilidade, Comparação das Abordagens. x.

(11) Abstract. Customization of open source software systems, such as the development of specific artifacts that meet their functional and non-functional requirements, can be licensed to acquiring organizations. However, it brings future problems to system maintenance, which in parallel is in constant evolution by their creators. The biggest challenge on this scenery is handling the evolutions of the original system made by their creators, which usually impact the acquiring organizations artifacts. In this context, the application of Software Product Lines (SPL) techniques emerges as a proposal to provide support in customizing acquired software. This study aims to evaluate in a real context and through controlled experiments the process of adaptation and maintenance of customized systems by comparing the approach currently used in the customizations, performed directly on the base code of the original system with the LPS techniques AspectJ, FeatureHouse and XVCL. The selection of those techniques for evaluation was based on a comparative analysis of the techniques raised on a systematic study that was realized, taking as a premise the possibility of creating customizable artifacts and the implementation of the variations apart of the base code, keeping it intact. Finally, after the experiment proposed in this study, quantitative and qualitative results regarding the usage of the SPL techniques AspectJ, FeatureHouse and XVCL in the adaptation and maintenance of customizable systems were obtained. These results show that FeatureHouse and XVCL were considered equivalent to each other and to the current approach. AspectJ, though it proved feasible, requires a steep learning curve. However, the adoption of one of those SPL techniques brings qualitative gains due to the possibility of creating customizable software artifacts and to the separation of the variations from the system base code. Keywords: Customization in software application, Software Product Line Techniques, Variability, Techniques Comparison.. xi.

(12) Lista de Figuras 2.1. Modelo de Característica . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34. 2.2. Composição dos artefatos de software aos aspectos . . . . . . . . . . . . .. 46. 2.3. Composição de FSTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 49. 2.4. Composição de código Java . . . . . . . . . . . . . . . . . . . . . . . . . .. 49. 2.5. Funcionamento do XVCL . . . . . . . . . . . . . . . . . . . . . . . . . . .. 52. 3.1. Processo de atualização de versões do SIG . . . . . . . . . . . . . . . . . .. 57. 3.2. Subsistemas do SIGAA . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 60. 3.3. Subsistemas do SIPAC . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 61. 4.1. Representação do BoxPlot . . . . . . . . . . . . . . . . . . . . . . . . . .. 68. 4.2. Variáveis Independentes e Dependentes da Primeira Etapa do Experimento .. 74. 4.3. Variáveis Independentes e Dependentes da Segunda Etapa do Experimento .. 74. 4.4. Estrutura da Organização das Implementações em AspectJ . . . . . . . . .. 86. 4.5. Estrutura da Organização das Implementações em FeatureHouse . . . . . .. 88. 4.6. Estrutura da Organização das Implementações em XVCL . . . . . . . . . .. 89. 5.1. Boxplot do Tempo gasto para implementar as Variações 01 a 06 . . . . . . .. 102. 5.2. Boxplot do Tempo gasto para implementar as Variações 07 a 12 . . . . . . .. 103. xii.

(13) 5.3. Boxplot do Grau de Gravidade de Erros cometidos na Implementação das Variações 01 a 06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5.4. Boxplot do Grau de Gravidade de Erros cometidos na Implementação das Variações 07 a 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5.5. 115. Boxplot da Diferença nos Graus de Gravidade de Erros na Implementação das Variações 01,02,04 e 06 . . . . . . . . . . . . . . . . . . . . . . . . . .. 5.9. 114. Boxplot da Diferença dos Tempos gasto na Implementação das Variações 09 a 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5.8. 113. Boxplot da Diferença dos Tempos gasto na Implementação das Variações 05 a 08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5.7. 106. Boxplot da Diferença dos Tempos gasto na Implementação das Variações 01 a 04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5.6. 105. 118. Boxplot da Diferença nos Graus de Gravidade de Erros na Implementação da Variação 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 119. 5.10 Boxplot do Tempo gasto para Atualização do SIG Customizado à nova Versão por Solicitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 124. 5.11 Boxplot do Grau de Gravidade de Erros para Atualização do SIG Customizado à nova Versão por Solicitação . . . . . . . . . . . . . . . . . . . . . .. 125. 5.12 Dotplot do Tempo gasto na Atualização da versão do SIG Customizado . .. 128. 5.13 Nível de conhecimento dos participantes sobre as Técnicas LPS . . . . . .. 132. 5.14 Quantitativo de participantes que trabalha / trabalhou em cada técnica . . .. 133. 5.15 Nível de dificuldade enfrentado pelos participantes na implementação das variações em cada técnica . . . . . . . . . . . . . . . . . . . . . . . . . . .. 134. 5.16 Nível de dificuldade enfrentado pelos participantes na atualização da versão SIG customizado em cada técnica . . . . . . . . . . . . . . . . . . . . . .. xiii. 134.

(14) 5.17 Quantitativo de participantes que adotariam cada técnica em seu ambiente de trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 135. B.1 Arquivo DIFF da Variação . . . . . . . . . . . . . . . . . . . . . . . . . .. 167. B.2 Formulário de Coleta dos dados do experimento . . . . . . . . . . . . . . .. 168. B.3 Caso de Teste da Variação 03 . . . . . . . . . . . . . . . . . . . . . . . . .. 169. B.4 Orientações para Atualização do SIG Customizado à nova Versão por Solicitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 172. B.5 Questionário Web de feedback . . . . . . . . . . . . . . . . . . . . . . . .. 177. xiv.

(15) Lista de Tabelas 2.1. Classificando as Técnicas de LPS de Abordagem Anotativa. . . . . . . . .. 37. 2.2. Classificando as Técnicas de LPS de Abordagem Composicional. . . . . . .. 38. 2.3. Classificando as Técnicas de LPS de Abordagem de Modelagem. . . . . . .. 40. 2.4. Classificando as Técnicas de LPS de Abordagem Transformacional. . . . .. 41. 3.1. Quantificação das variações ao SIG UFS. . . . . . . . . . . . . . . . . . .. 62. 3.2. Catálogo e Quantificação das variações ao SIG UFS. . . . . . . . . . . . .. 64. 4.1. Sequência das Abordagens para Implementação da Variações. . . . . . . .. 77. 4.2. Sequência das Abordagens para Atualização da Versão SIG Customizado. .. 78. 4.3. Escolha dos tipos de variações realizadas no SIG UFS. . . . . . . . . . . .. 80. 4.4. Tipo de variações selecionadas por Módulo do SIG UFS. . . . . . . . . . .. 81. 4.5. Níveis de Gravidade de Erros. . . . . . . . . . . . . . . . . . . . . . . . .. 94. 5.1. Classificação dos Erros encontrados na primeira etapa do experimento. . . .. 96. 5.2. Tempo gasto na Implementação das Variações. . . . . . . . . . . . . . . . .. 98. 5.3. Erro e Grau de Gravidade cometido na Implementação das Variações. . . .. 99. 5.4. Medidas Descritivas referentes ao Tempo gasto na Implementação das Variações. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. xv. 100.

(16) 5.5. Medidas Descritivas referentes ao Grau de Gravidade de Erros cometidos na Implementação das Variações. . . . . . . . . . . . . . . . . . . . . . . . .. 5.6. Teste de Normalidade Shapiro-Wilk das amostras Tempo e Erro referente às Implementações das Variações. . . . . . . . . . . . . . . . . . . . . . . . .. 5.7. 111. Teste de Friedman referente ao Tempo gasto na Implementação das Variações 07 a 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5.9. 107. Teste de Friedman referente ao Tempo gasto na Implementação das Variações 01 a 06. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5.8. 101. 112. Teste de Friedman referente ao Grau de Gravidade de Erros cometidos na Implementação das Variações 01, 02, 04, 06 e 12. . . . . . . . . . . . . . .. 116. 5.10 Teste de Friedman referente ao Grau de Gravidade de Erros cometidos na Implementação das Variações 03, 05 e 07 a 11. . . . . . . . . . . . . . . .. 117. 5.11 Classificação dos Erros encontrados na segunda etapa do experimento. . . .. 120. 5.12 Tempo gasto na Atualização do SIG Customizado à nova versão do SIG Original. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 122. 5.13 Medidas Descritivas referente ao Tempo gasto na Atualização da versão do SIG Customizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 122. 5.14 Erro e Grau de Gravidade cometido na Atualização da versão do SIG Customizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 123. 5.15 Medidas Descritivas referente ao Grau de Gravidade dos Erros cometidos na Atualização da versão do SIG Customizado. . . . . . . . . . . . . . . . . .. 123. 5.16 Teste de Normalidade Shapiro-Wilk das amostras Tempo e Erro referente à Atualização da versão do SIG customizado. . . . . . . . . . . . . . . . . .. 126. 5.17 Teste de Wilcoxon referente ao Tempo gasto na Atualização da versão do SIG Customizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 127. 5.18 Teste de Wilcoxon referente ao Grau de Gravidade dos Erros cometidos na Atualização da versão do SIG Customizado. . . . . . . . . . . . . . . . . . xvi. 130.

(17) 5.19 Comparativo entre as abordagens propostas para o experimento. . . . . . .. 137. A.1 Resultados da Revisão Sistemática. . . . . . . . . . . . . . . . . . . . . . .. 164. A.2 Trabalhos Selecionados da Revisão Sistemática. . . . . . . . . . . . . . . .. 165. xvii.

(18) Lista de Listagem 2.1. Código Original da Classe Stack. . . . . . . . . . . . . . . . . . . . . . . .. 47. 2.2. Implementação da customização em Aspecto. . . . . . . . . . . . . . . . .. 48. 2.3. Inserindo cópia do código Original no X-FRAME. . . . . . . . . . . . . . .. 53. 2.4. Implementação da Variação ACM em XVCL. . . . . . . . . . . . . . . . .. 53. 4.1. Código Original do SIG. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 83. 4.2. Código Customizado do SIG na abordagem Atual. . . . . . . . . . . . . . .. 84. 4.3. Implementação da Variação ACM em AspectJ. . . . . . . . . . . . . . . .. 85. 4.4. Implementação da Variação ACM em FeatureHouse. . . . . . . . . . . . .. 87. 4.5. Inserindo cópia do código Original no X-FRAME. . . . . . . . . . . . . . .. 90. 4.6. Implementação da Variação ACM em X-FRAME. . . . . . . . . . . . . . .. 90. xviii.

(19) Lista de Siglas APIs. - Application Programming Interfaces. DSL. - Domain Specific Language. ERP. - Enterprise Resource Planning. FST. - Feature Structure Tree. GUI. - Graphical User Interface. IDE. - Integrated Development Environment. IFES. -. J2EE. - Java 2 Enterprise Edition. JSP. - Java Server Pages. LPS. -. Linha de Produto de Software. NTI. -. Núcleo de Tecnologia da Informação. PIBIC. -. Programa Institucional de Bolsas de Iniciação Científica. POA. -. Programação Orientada a Aspectos. POO. -. Programação Orientada a Objetos. SIG. -. Sistema Integrado de Gestão. SIGAA. -. Sistema Integrado de Gestão de Atividades Acadêmicas. SIPAC. -. Sistema Integrado de Patrimônio, Administração e Contratos. SQL. - Structured Query Language. UFRN. -. Universidade Federal do Rio Grande do Norte. UFS. -. Universidade Federal de Sergipe. XML. - eXtensible Markup Language. Instituições Federais de Ensino Superior. xix.

(20) Sumário. 1. 2. Introdução. 24. 1.1. Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 24. 1.2. Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 27. 1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 28. 1.3.1. Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . .. 28. 1.4. Hipótese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 29. 1.5. Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 29. 1.6. Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . .. 30. Seleção das Técnicas de Linha de Produto de Software. 31. 2.1. Linha de Produto de Software . . . . . . . . . . . . . . . . . . . . . . . .. 31. 2.1.1. Modelo de Características . . . . . . . . . . . . . . . . . . . . . .. 33. 2.1.2. Variabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34. 2.1.3. Asset Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34. 2.1.4. Conhecimento de Configuração . . . . . . . . . . . . . . . . . . .. 35. 2.1.5. Configuração do produto . . . . . . . . . . . . . . . . . . . . . . .. 35. Abordagens que lidam com Variação em LPS . . . . . . . . . . . . . . . .. 36. 2.2.1. 37. 2.2. Abordagem Anotativa . . . . . . . . . . . . . . . . . . . . . . . . xx.

(21) 3. 4. 2.2.2. Abordagem Composicional . . . . . . . . . . . . . . . . . . . . .. 38. 2.2.3. Abordagem de Modelagem de LPS . . . . . . . . . . . . . . . . .. 39. 2.2.4. Abordagem Transformacional . . . . . . . . . . . . . . . . . . . .. 41. 2.3. Análise comparativa das Técnicas de LPS . . . . . . . . . . . . . . . . . .. 42. 2.4. Técnicas de LPS Selecionadas . . . . . . . . . . . . . . . . . . . . . . . .. 45. 2.4.1. AspectJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 45. 2.4.2. FeatureHouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 48. 2.4.3. XVCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 50. Levantamento e Análise de Variações em um Sistema Customizado. 54. 3.1. Sistema Integrado de Gestão . . . . . . . . . . . . . . . . . . . . . . . . .. 55. 3.2. Abordagem Atual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 57. 3.3. Variações no SIG da UFS . . . . . . . . . . . . . . . . . . . . . . . . . . .. 59. Estudo Experimental. 65. 4.1. Metodologia do Estudo Experimental . . . . . . . . . . . . . . . . . . . .. 66. 4.1.1. Definição do Experimento . . . . . . . . . . . . . . . . . . . . . .. 66. 4.1.2. Planejamento do Experimento . . . . . . . . . . . . . . . . . . . .. 66. 4.1.3. Operação do Experimento . . . . . . . . . . . . . . . . . . . . . .. 67. 4.1.4. Análise e Interpretação dos Dados . . . . . . . . . . . . . . . . . .. 67. Configuração do Estudo Experimental . . . . . . . . . . . . . . . . . . . .. 71. 4.2.1. Definição do Objetivo . . . . . . . . . . . . . . . . . . . . . . . .. 71. 4.2.2. Planejamento do Experimento . . . . . . . . . . . . . . . . . . . .. 71. 4.2.3. Operação do Experimento . . . . . . . . . . . . . . . . . . . . . .. 90. 4.2. xxi.

(22) 5. Análise dos Resultados. 95. 5.1. Primeira Etapa do Experimento . . . . . . . . . . . . . . . . . . . . . . . .. 96. 5.1.1. Análise Descritiva dos Resultados . . . . . . . . . . . . . . . . . .. 96. 5.1.2. Teste de Normalidade . . . . . . . . . . . . . . . . . . . . . . . .. 107. 5.1.3. Avaliação das Hipóteses . . . . . . . . . . . . . . . . . . . . . . .. 108. Segunda Etapa do Experimento . . . . . . . . . . . . . . . . . . . . . . . .. 119. 5.2.1. Análise Descritiva dos Resultados . . . . . . . . . . . . . . . . . .. 119. 5.2.2. Teste de Normalidade . . . . . . . . . . . . . . . . . . . . . . . .. 126. 5.2.3. Avaliação das Hipóteses . . . . . . . . . . . . . . . . . . . . . . .. 127. 5.3. Ameaças à Validade do Estudo . . . . . . . . . . . . . . . . . . . . . . . .. 130. 5.4. Análise das Impressões Pessoais dos Participantes . . . . . . . . . . . . . .. 132. 5.5. Resumo dos Resultados da Análise . . . . . . . . . . . . . . . . . . . . . .. 136. 5.2. 6. Conclusão. 139. 6.1. Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 142. 6.2. Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 146. 6.3. Trabalhos Publicados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 147. Referências. 149. A Revisão sistemática. 160. A.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 160. A.2 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 161. A.2.1 Questão de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . .. 161. A.2.2 Critérios de Inclusão e Exclusão dos Estudos Primários . . . . . . .. 162. xxii.

(23) A.2.3 Estratégia para realização das buscas . . . . . . . . . . . . . . . .. 162. A.3 Condução e Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 164. B Artefatos Produzidos para o Experimento. 166. B.1 Arquivo DIFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 166. B.2 Formulário de Coleta do Tempo dos Participantes . . . . . . . . . . . . . .. 167. B.3 Caso de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 168. B.4 Orientações para Segunda Etapa do Experimento . . . . . . . . . . . . . .. 170. B.5. 170. Questionário Web para os Participantes . . . . . . . . . . . . . . . . . . .. xxiii.

(24) Capítulo 1 Introdução Neste capítulo é apresentada inicialmente na Seção 1.1 uma breve introdução contendo a contextualização acerca do tema de pesquisa. Em seguida, a Seção 1.2 apresenta a justificativa do trabalho. Na Seção 1.3, os objetivos do trabalho são discutidos. A Seção 1.4, apresenta a hipótese que se pretende provar com a realização deste trabalho. As principais contribuições do trabalho durante o seu desenvolvimento são descritas na Seção 1.5. Por fim, na Seção 1.6, a estrutura da organização da dissertação é descrita.. 1.1. Contextualização. Atualmente, cada vez mais aumenta a complexidade no desenvolvimento de software tanto devido à necessidade de lidar com requisitos não funcionais complexos, como diferentes tipos de rede, protocolos, interfaces com usuário, sistemas operacionais, Application Programming Interfaces (APIs), quanto pelas variações nos requisitos funcionais que são necessárias para que um software seja adaptado aos seus usuários finais e distribuidores. Desta forma, a evolução do software é uma atividade inevitável em aplicativos de software não só por terem de lidar com as mudanças no domínio de aplicação, mas com requisitos dos usuários referentes a melhorias na aplicação e a novos requisitos. Além disso, um único aplicativo de software nem sempre consegue satisfazer aos diferentes requisitos para grupos de usuários distintos. 24.

(25) Diante dessa realidade, as empresas fornecedoras de sistemas desenvolvem software Open Source licenciando o direito das organizações adquirentes de realizarem customizações no código. As empresas criadoras muitas vezes não possuem o interesse de criar os artefatos necessários para os mais variados clientes, seja devido ao elevado número de clientes, ou por conta de questões econômicas e estratégicas. Nesse contexto, as organizações adquirentes desses sistemas precisam obter o conhecimento necessário do sistema original para desenvolver artefatos específicos que satisfazem seus requisitos funcionais e não funcionais, além de lidar com futuras evoluções desse sistema realizadas pelos criadores que normalmente geram impacto sobre estes artefatos desenvolvidos. As customizações realizadas pelas organizações adquirentes podem ser desde a simples criação de novos artefatos a alterações em artefatos já existentes no sistema original, levando a problemas futuros de manutenção e evolução. Isto ocorre porque novas versões desse sistema são disponibilizadas pelos criadores sem as adaptações e os novos artefatos criados pelas organizações adquirentes. Sendo assim, quando uma atualização do sistema original é lançada pelo fornecedor, só é disponibilizada aos usuários finais depois de ser readaptada pelas organizações adquirentes, o que é um trabalho muito difícil, demorado e sujeito a falhas. O problema abordado é uma realidade vivenciada por muitas organizações que adquirem o sistema original de empresas fornecedoras de sistemas e pretendem realizar adaptações e manutenções no software. Essas customizações realizadas são diretamente no código base do sistema original, o qual paralelamente está em constante evolução pelos seus criadores. A customização de plataformas de software, como a plataforma Open Source Android 1 , para satisfazer aos requisitos dos fabricantes de hardware representa este cenário. As variações realizadas no sistema base Android pelos fabricantes de hardware devem ser reintroduzidas e adaptadas toda vez que é lançada uma nova versão original do Android com a finalidade de continuar atendendo aos requisitos dos adquirentes, o que ocasiona retrabalho e a impossibilidade de uma atualização automática para a versão atual do Android. 1. http://developer.android.com. 25.

(26) Outro exemplo deste cenário são os sistemas integrados de gestão, ou ERP (Enterprise Resource Planning) que ao serem implantados nas organizações adquirentes passam por customizações necessárias para atender especificidades de cada negócio. Com isso, elevam-se os esforços de manutenção devido às customizações realizadas, que devem ser realinhadas ao sistema ou até mesmo reescritas, diante das atualizações constantes realizadas pelos fornecedores para incorporar novos recursos e correções de problemas no sistema. Por este motivo, Rothenberger e Srite (2009) investigaram sobre customizações em ERP através dos relatos de vários trabalhos e revelam a importância da reengenharia nos processos da empresa adquirente para adequar-se aos processos do ERP a fim de minimizar as customizações. O fato é que as empresas são bastante resistentes a mudanças nos seus processos, portanto consideram mais fácil adequar os sistemas. Uma das formas de lidar com variações existentes em um software é através da criação de Linha de Produto de Software (Software Product Line — LPS) (POHL et al., 2005). Linha de Produto de Software é um conjunto de sistemas de software que compartilham um conjunto comum e gerenciado de características satisfazendo as necessidades específicas de um segmento de mercado ou missão particular e que são desenvolvidos a partir de um conjunto comum de artefatos de uma forma prescrita (CLEMENTS; NORTHROP, 2001) e são diferenciados entre si em termos das suas características variantes (PARNAS, 1979). Ainda assim, nem todas as empresas desenvolvedoras de software utilizam a abordagem de LPS no desenvolvimento dos sistemas. Essa abordagem tornaria mais fácil obter produtos com variações, sejam funcionais ou não funcionais, satisfazendo as necessidades dos clientes. Porém, é preciso conhecer as variações de cada produto e aplicar metodologias de desenvolvimento, processos, técnicas e ferramentas adequadas para tal fim. Em função da evidente importância e criticidade no processo de adaptação e manutenção em sistemas originais fornecidos por empresas desenvolvedoras de software e adquiridos por outras organizações, o presente trabalho pretende investigar e avaliar abordagens que possibilitem a implementação das variações nos requisitos das organizações sem modificar diretamente o código base do sistema original adquirido visando apoiar a evolução do software.. 26.

(27) 1.2. Justificativa. O processo de adaptação e manutenção em sistemas originais adquiridos é uma realidade frequente e ocorre em qualquer sistema customizado por organizações adquirentes ou em empresas fornecedoras de sistemas customizados para atender a clientes específicos. As atividades envolvidas neste processo não são triviais porque as variações nos requisitos para satisfazer os usuários finais são relativamente frequentes e muitas vezes afetam vários pontos do sistema base, o que torna difícil o gerenciamento das variações de forma localizada. Além disso, as organizações que customizam o sistema adquirido têm que lidar com as evoluções do sistema base realizadas pelos criadores que normalmente geram impacto sobre as variações desenvolvidas por serem realizadas diretamente sobre o código base do sistema original. Consequentemente, o processo de adaptação e manutenção precisa ser aprimorado, necessitando de abordagens que possibilitem:. • A criação de produtos customizáveis perante as necessidades específicas de cada organização; • A separação das implementações das variações do código base do sistema original, sem que seja preciso modificá-lo; • Gerenciamento das variações realizadas pelas organizações adquirentes no sistema original através da facilidade de localização das mesmas; • Agilidade no processo de sincronização de versões ao ser disponibilizada uma nova versão pelo fornecedor do sistema original.. Diante deste cenário, a utilização de técnicas que lidam com variações em Linhas de Produtos de Software, através de seus princípios de variabilidade, será investigada como uma possível solução para aprimorar o processo de adaptação e manutenção em sistemas customizados.. 27.

(28) 1.3. Objetivos. Este trabalho tem como principal objetivo avaliar a utilização de técnicas que lidam com variações em Linhas de Produtos de Software no processo de adaptação e manutenção de sistemas customizados, realizado por organizações adquirentes, visando a separação das variações do código base do sistema original, sem efetuar refatorações.. 1.3.1. Objetivos Específicos. Para atingir o objetivo principal, alguns objetivos específicos foram estabelecidos:. • Planejar e executar uma revisão sistemática que concentra-se em averiguar as técnicas que lidam com variabilidades em LPS. • Analisar e selecionar, dentre as técnicas de LPS levantadas no estudo sistemático, quais poderiam ser introduzidas ao processo de adaptação e manutenção de sistemas customizados, condizentes com critérios relevantes à proposta do trabalho; • Levantar e catalogar as variações realizadas no código fonte de um sistema base real proposto como objeto de estudo deste trabalho; • Planejar um estudo experimental para avaliação das técnicas de LPS selecionadas, detalhando as fases do planejamento para condução do experimento. • Executar o experimento planejado. O experimento consiste na introdução das técnicas de LPS selecionadas no processo de adaptação e manutenção das customizações realizadas no sistema real proposto; • Analisar e discutir os resultados obtidos do experimento referente à aplicação de cada técnica ao objeto de estudo, comprovando ou não a viabilidade do uso de técnicas de LPS no processo de adaptação e manutenção em sistemas customizados, atendo-se ao contexto do objeto de estudo proposto.. 28.

(29) 1.4. Hipótese. Considerando a necessidade de melhoria gradativa no processo de adaptação e manutenção em sistemas customizados por organizações, tem-se como hipótese que: "A utilização de técnicas que lidam com variações em Linha de Produto de Software permitirá a implementação das variações separada do código base, facilitando a gestão das variações e tornando o processo de atualização da versão do sistema mais rápida e com menos falhas na reintrodução das variações nas novas versões do sistema original".. 1.5. Contribuições. Com o desenvolvimento desta dissertação, destacam-se como principais as seguintes contribuições:. • Revisão das principais técnicas de Linha de Produto de Software que lidam com variações aplicáveis ao processo de adaptação e manutenção de sistemas customizados, através de um estudo sistemático. • Comparação e seleção de técnicas de LPS levantadas na revisão sistemática observando critérios como: (i) criação de artefatos de software customizáveis; (ii) separação das variações do código base do sistema original; e (iii) implementação das variações sem modificar o código base do sistema original. • Aplicação e avaliação das técnicas de LPS selecionadas no processo de customização e atualização da versão do sistema adquirido junto ao sistema original, através de um estudo experimental. O estudo compara as técnicas de LPS selecionadas e a abordagem atualmente utilizada por organizações adquirentes do sistema, comprovando ou não a viabilidade do uso das técnicas de LPS no cenário atual. Neste estudo, é avaliado o desempenho das técnicas em relação ao tempo gasto e erros cometidos durante as fases de implementação das customizações e atualização do sistema customizado para a nova versão do sistema base original.. 29.

(30) 1.6. Estrutura da Dissertação. Este trabalho está organizado em seis capítulos. Este capítulo introduziu o problema de pesquisa, apresentando os objetivos e a hipótese do trabalho, além das contribuições alcançadas durante o desenvolvimento do trabalho. • O Capítulo 2 apresenta alguns conceitos básicos relacionados a Linha de Produto de Software (LPS), a análise comparativa das técnicas de LPS levantadas na revisão sistemática classificando-as em diferentes abordagens de desenvolvimento, além da seleção de algumas técnicas. Por fim, apresenta uma visão geral das técnicas selecionadas, discutindo as principais características e funcionamento; • O Capítulo 3 apresenta o sistema proposto como alvo de estudo deste trabalho e discute a aboradegm atualmente utilizada para realizar as customizações no sistema. Além disso, são apresentados o levantamento e catálogo das variações existentes em dois módulos do sistema; • O Capítulo 4 apresenta a metodologia e a configuração do estudo experimental, descrevendo os conceitos principais do processo de experimentação e a instanciação das fases desse processo para a condução do experimento proposto neste trabalho. • O Capítulo 5 apresenta as análises quantitativas e qualitativas, realizadas a partir dos resultados obtidos da execução dos experimentos, utilizando métricas de eficiência e eficácia; • Finalizando, no Capítulo 6 são apresentadas as principais conclusões obtidas dos resultados analisados no capítulo anterior, bem como os trabalhos relacionados à pesquisa, algumas perspectivas de trabalhos futuros e os trabalhos publicados durante o desenvolvimento deste trabalho.. No Apêndice A encontram-se detalhes da revisão sistemática que fundamentam o Capítulo 2, enquanto que no Apêndice B são apresentados exemplos dos artefatos utilizados durante e após a execução dos experimentos para obtenção de dados quantitativos e qualitativos. 30.

(31) Capítulo 2 Seleção das Técnicas de Linha de Produto de Software Neste capítulo é realizada uma revisão da literatura sobre os principais conceitos que caracterizam uma Linha de Produto de Software. Em seguida, são apresentadas as técnicas LPS encontradas no estudo sistemático, detalhado no Apêndice A, classificando-as de acordo com as abordagens de implementação das variantes em LPS. Logo após, é realizada uma análise comparativa das técnicas com o objetivo de verificar quais delas se enquadrariam nos critérios relevantes à resolução do problema de pesquisa e assim selecioná-las. Por fim, é apresenta uma visão geral das técnicas selecionadas, discutindo-se as principais características e funcionamento.. 2.1. Linha de Produto de Software. Atualmente, vem crescendo a utilização de Linhas de Produtos de Software na indústria. Um exemplo típico são os aplicativos de software para dispositivos portáteis como celulares, que visam atender à grande variedade de dispositivos celulares existentes no mercado, o que demonstra a relevância da abordagem LPS para atender às crescentes e diferentes demandas do mercado. De acordo com Pohl et al. (2005), uma LPS é constituída por um conjunto de aplicações 31.

(32) similares de um domínio, que podem ser desenvolvidas a partir de uma arquitetura genérica comum, a arquitetura da LPS, e um conjunto de componentes que povoam a arquitetura. Segundo Parnas (1979), uma coleção de sistemas que compartilham características comuns é chamada de "família de sistemas", sendo atualmente chamado de Linha de Produtos de Software. O conceito de famílias de software introduzido por Dijkstra (1970), propôs um modelo de desenvolvimento baseado na família, onde as diferenças em decisões de projeto distinguem os membros da família. Para Parnas (1976), famílias são caracterizadas como grupos de itens que estão fortemente relacionados por suas semelhanças e para os quais as similaridades são mais importantes do que as variabilidades entre os membros da família. O reuso de software em LPS é essencial e provém da utilização de software já existente para a construção de um novo software. A reutilização de software é importante para construir sistemas maiores, complexos, confiáveis, menos custosos e com a entrega no prazo. Os métodos de engenharia de software tradicionais não suprem todas essas demandas de construção de software. Com isso, a finalidade de uma linha de produto de software é diminuir os esforços de engenharia necessários para construir aplicativos customizáveis e extensíveis de forma sistemática, a partir de artefatos gerenciáveis e reutilizáveis, aproveitando a semelhança entre os sistemas e a capacidade de gestão de variações existentes entre os mesmos. A linha de produto de software suporta o conjunto de produtos, que é determinado pela variabilidade da linha de produtos especificados. Consequentemente, alguns artefatos são importantes em Linhas de Produtos de Software para que sejam modeladas e especificadas as similaridades e as variabilidades da LPS e assim se torne possível sistematizar o processo de derivação de produtos. Os principais artefatos são: Modelo de Características (Seção 2.1.1), Variabilidade (Seção 2.1.2), Asset Base (Seção 2.1.3), Conhecimento de Configuração (Seção 2.1.4) e Configuração do Produto (Seção 2.1.5).. 32.

(33) 2.1.1. Modelo de Características. Linhas de produtos são estruturadas como um conjunto de características (em inglês, features) de acordo com o modelo de características que é usado para representar uma visão geral de alto nível da organização hierárquica das características com dependências, relacionamentos e restrições entre as mesmas (TURNES, 2012). Uma característica é uma funcionalidade do sistema que é relevante e visível para os stakeholders (partes interessadas) e é utilizada para representar comunalidades ou variabilidades entre os produtos em uma linha de produtos (ANTKIEWICZ; CZARNECKI, 2004). Nos modelos de características são modeladas e especificadas as características comuns e variáveis em uma linha de produtos, definindo o seu escopo de domínio e as configurações válidas de produtos, os quais podem ser gerados para a linha de produtos de software (KANG et al., 2003). As características podem ser de quatro tipos: (i) Obrigatória: representa a comunalidade de uma família de produtos e deve ser incluída em todos os produtos da família; (ii) Opcional: representa uma variante que pode estar presente ou não em um produto específico da família; (iii) Alternativa: pertencem a um grupo de característica podendo somente uma delas estar presente em cada produto; e (iv) Or-feature: pertencem a um grupo de características, no entanto, a seleção de mais do que uma característica deste grupo é permitida. A Figura 2.1 ilustra o modelo de características da linha de produtos de Automóveis, onde as carecterísticas Combustível e Cor são obrigatórias; a característica Ar condicionado é opcional; as características Gasolina e Etanol são or-features e, por fim, as características Branco, Preto e Azul são alternativas. Além da visualização gráfica das características comuns e variáveis de uma LPS e suas relações, é possível também determinar algumas restrições de relacionamento entre as características, como exemplo, poderia ser definido uma restrição relacionada ao modelo de característica da Figura 2.1 especificando "Se a característica Azul estiver selecionada, não selecione a característica Ar condicionado".. 33.

(34) Figura 2.1: Modelo de Característica. Adaptado de (MATOS JR., 2008).. 2.1.2. Variabilidade. O conceito de variabilidade é fundamental no desenvolvimento de linhas de produtos e está relacionado à possibilidade de mudar ou personalizar os produtos de uma linha através da representação dos pontos de variabilidade e variantes respectivos. Segundo Pohl et al. (2005) variabilidades são diferenças encontradas entre os produtos de uma LPS podendo ser reveladas e distribuídas entre os artefatos. Esses artefatos devem ser suficientemente adaptáveis de modo a permitir detalhes de implementação de um produto específico. Um ponto de variabilidade é o local específico do artefato de software da LPS em que uma decisão de projeto pode ser tomada, e variantes são alternativas de projeto associadas a este ponto. Sendo que esses pontos de variabilidade podem ser abertos ou fechados. Os abertos permitem que novas variantes sejam adicionadas ao ponto já definido e os fechados não permitem que novas variantes sejam adicionadas (VAN GURP et al., 2001).. 2.1.3. Asset Base. Um asset base é um artefato utilizado na produção dos produtos de uma Linha de Produto de Software (ALVES et al., 2007). A coleção de assets forma a base de ativos reutilizavéis para uma Linha de Produto de Software e representa a especificação e implementação de artefatos 34.

(35) como documentos de requisitos, modelos de domínio, arquitetura de software, código, classes, componentes, templates, casos de testes, arquivos XML (eXtensible Markup Language) entre outros.. 2.1.4. Conhecimento de Configuração. O Conhecimento de Configuração representa um artefato importante para a geração de produtos da LPS, pois expressa as relações entre o modelo de características e os assets de código, isto é, define como combinações específicas de características são mapeadas para um conjunto de artefatos de software (CAZZOLA et al., 2011). A especificação do conhecimento de configuração pode ser realizada de duas maneiras: (i) seleção dos assets de código correspondentes ao conjunto de características que representam o produto a ser derivado, sendo esta seleção baseada na configuração das características definidas anteriormente; e (ii) construção, composição ou transformação de um conjunto de assets de código que compõe a arquitetura LPS para atender a seleção de características correspondente ao produto a ser derivado. Portanto, dada uma configuração do modelo de característica válida, a especificação do conhecimento de configuração relaciona os assets de código necessários para construir o produto correspondente, ou seja, são mapeadas quais características se relacionam a determinadas classes, aspectos, arquivos de configurações e outros elementos da aplicação para o processo de derivação de produtos da LPS.. 2.1.5. Configuração do produto. A Configuração de Produto representa a configuração de um subconjunto de características do modelo de características através de uma seleção válida de características satisfazendo as restrições presentes no modelo de características para obtenção de um produto específico da LPS a ser gerado pelo processo de derivação de produtos (TURNES, 2012). O processo de derivação de produtos consiste em construir um produto a partir dos artefatos de código reutilizáveis que implementam uma LPS sendo utilizado o modelo de carac35.

(36) terísticas e o conhecimento de configuração para geração de instâncias de produtos.. 2.2. Abordagens que lidam com Variação em LPS. A implementação de variabilidades em Linhas de Produtos de Software permite construir assets customizáveis e extensíveis para a concepção de diferentes produtos de software derivados de uma LPS. Existem diferentes abordagens para a implementação das variantes em LPS, podendo ser classificadas nas seguintes categorias: anotativa (SAAKE et al., 2010), composicional (SAAKE et al., 2010), modelagem (BEUCHE, 2003) e transformacional (PARTSCH; STEINBRÜGGEN, 1983) detalhadas, respectivamente, nas seções 2.2.1, 2.2.2, 2.2.3 e 2.2.4. Neste contexto, são apresentadas as técnicas de LPS encontradas no estudo sistemático (Apêndice A), associando-as às abordagens. As técnicas de LPS são classificadas seguindo critérios adicionais relevantes à implementação de variabilidades em sistemas. Os critérios foram definidos para verificar dentre as técnicas levantadas, quais se enquadrariam na abordagem proposta neste trabalho. Para isso, a técnica deve permitir o suporte à fase de implementação do ciclo de vida do software, à derivação de produtos, à criação de artefatos de software customizáveis com suporte no nível de granularidade grossa e fina e à separação das variações do código base do sistema original. Sendo assim, os critérios utilizados para classificação das técnicas foram: (i) Configuração do Produto: especificação de um produto da LPS a ser gerado pelo processo de derivação de produtos baseado na configuração de funcionalidades; (ii) Fases do ciclo de Vida da LPS: as fases do ciclo de vida do software providas pela ferramenta no desenvolvimento de LPS; (iii) Seleção dos Componentes Concretos: assets de código concretos (classes, aspectos, arquivos e outros) mapeados às funcionalidades selecionadas para geração do produto final; (iv) Geração dos Componentes Flexíveis: suporta adaptações, composições e transformações dos assets reusáveis para contemplar possíveis variações conforme as funcionalidades selecionadas para geração do produto final; (v) Granularidade da Variabilidade: o nível de granularidade (grossa ou fina) provida pela técnica para implementação dos assets reusáveis e de variações nos mesmos. O nível de granularidade grossa possibilita adicionar novas classes, aspectos, métodos e atributos ou estender pontos de variações 36.

(37) explícitos. Já o nível de granularidade fina permite introduzir trechos de código a métodos existentes, estender expressões ou assinaturas de métodos; (vi) Separação da Variação do Código: implementação das variações separada do código base do sistema original. As classificações e dados informados nas tabelas apresentadas nas seções seguintes foram obtidos da análise de informações disponíveis em documentações e periódicos publicados sobre cada técnica. As seguintes abreviações são utilizadas: (i) Fases do Ciclo de Vida: C (Concepção), A (Análise), P (Projeto), I (Implementação) e TD (Todas); (ii) Granularidade da Variabilidade: G (Grossa) e F (Fina).. 2.2.1. Abordagem Anotativa. Na abordagem anotativa, os fragmentos de código de funcionalidades são anotados em uma base de código comum para configurar variantes estaticamente antes da compilação. As anotações também podem ser realizadas em outros artefatos como em modelos (SAAKE et al., 2010). É utilizado nesta abordagem o pré-processador, um programa executado antes do compilador para analisar o código fonte a ser compilado e, de acordo com as anotações adicionadas ao mesmo, executar alterações antes de repassá-lo ao compilador. Dentre as técnicas levantadas, foram identificadas três propostas de abordagem anotativa: Antenna 1 , XVCL (XML-based Variant Configuration Language) 2 e CIDE (Colored Integrated Development Environment) 3 . Tabela 2.1: Classificando as Técnicas de LPS de Abordagem Anotativa. Técnica. Configuração do Produto. Fases do Ciclo de Vida. Antenna CIDE XVCL. SIM SIM SIM. I I I. Seleção dos Componentes Concretos NÃO SIM NÃO. Geração dos Componentes Flexíveis SIM SIM SIM. Granularidade da Variabilidade SIM(G,F) SIM(G,F) SIM(G,F). Separação da Variação NÃO NÃO SIM. De acordo com a Tabela 2.1 as técnicas desta abordagem proporcionam a configuração de produtos e a geração de componentes flexíveis através do mecanismo de anotação explícita com granularidade grossa e fina diretamente no código fonte podendo ser textual ou visual. As técnicas Antenna e XVCL utilizam anotações textuais por meio de diretivas 1. http://antenna.sourceforge.net/wtkpreprocess.php http://xvcl.comp.nus.edu.sg/cms/ 3 http://wwwiti.cs.uni-magdeburg.de/iti_db/research/cide/ 2. 37.

(38) de pré-processamento ou de comandos específicos da técnica diretamente no código fonte. Diferentemente, a CIDE baseia-se em anotações visuais através da marcação do código por uma cor de fundo, o que proporciona uma separação virtual através das cores das funcionalidades, mas não há uma separação de fato do código base do sistema. No entanto, a técnica XVCL possui uma vantagem em relação a Antenna e CIDE que é a separação do trecho de código que contempla a customização do código base do sistema original em outro arquivo, requerendo apenas a anotação dos pontos no código base do sistema original onde estes trechos de código irão ser introduzidos.. 2.2.2. Abordagem Composicional. Na abordagem composicional, as funcionalidades são implementadas separadamente em módulos distintos (arquivos, classes, pacotes, plug-ins e outros) e são geradas instâncias da linha de produtos através da composição destes módulos. Para gerar variantes, estes módulos podem ser compostos em diferentes combinações. Os mecanismos de implementação utilizados são: componentes, mixin layers, classes virtuais, aspectos e outros (SAAKE et al., 2010). Nesta abordagem foram identificadas sete técnicas: AHEAD (BATORY, 2004), FeatureHouse 4 , JPEL 5 , AspectJ (KICZALES et al., 1997), CaesarJ 6 , JBOSS AOP 7 e Spring AOP 8 . Estas últimas quatro técnicas pertencem ao paradigma de Programação Orientado a Aspectos (POA), tendo como unidade modular o aspecto. Tabela 2.2: Classificando as Técnicas de LPS de Abordagem Composicional. Técnica. Configuração do Produto. Fases do Ciclo de Vida. AHEAD FeatureHouse JPEL POA. SIM SIM SIM SIM. I I I I. Seleção dos Componentes Concretos NÃO NÃO NÃO NÃO. Geração dos Componentes Flexíveis SIM SIM SIM SIM. Granularidade da Variabilidade SIM(G,F) SIM(G,F) SIM (F) SIM(G,F). Separação da Variação SIM SIM NÃO SIM. As técnicas enquadradas nesta abordagem, como mostra a classificação realizada na Tabela 2.2, possibilitam a configuração de produtos e a geração de componentes flexíveis atra4. www.fosd.de/fh http://sourceforge.net/projects/jpel/ 6 http://www.caesarj.org/ 7 http://docs.jboss.org/jbossaop/docs/index.html 8 http://static.springsource.org/spring/docs/2.5.5/reference/aop.html 5. 38.

(39) vés da implementação de módulos distintos com granularidade grossa e fina, contemplando as customizações necessárias ao sistema original mediante a composição destes módulos ao código base do sistema. As técnicas AHEAD, FeatureHouse e POA possibilitam a adição de novos campos e métodos a classes do sistema afetando a estrutura estática, ou ainda a adição de comportamento extra no início ou final dos métodos existentes. Diferentemente destes, JPEL limita-se a implementar variações de valor, através de arquivos de parametrização para alterar os valores das variáveis locais, atributos, constantes usadas para calcular uma expressão no sistema, úteis ao realizar testes condicionais e decidir pela adição ou não de variabilidades comportamentais implementadas diretamente no código base do sistema original, não sendo concebível alterar a estrutura do programa.. 2.2.3. Abordagem de Modelagem de LPS. Na abordagem de modelagem de LPS é possível especificar as funcionalidades que contemplam o escopo de toda a linha de produtos, as dependências, os relacionamentos e as restrições entre as mesmas. Além de, sistematizar o processo de derivação de produtos que envolvem a seleção, composição e customização dos artefatos de código que implementam uma LPS com o objetivo de atender a configuração de funcionalidades. Foram levantadas nesta abordagem vinte e uma propostas: CodeScoping (MEDEIROS et al., 2012), CONSUL (BEUCHE et al., 2004), COVAMOF (SINNEMA et al., 2004a), DOPLER 9 , FAMA FW (BENAVIDES et al., 2007), FeatureIDE (THÜM et al., 2014), FeatureMapper (HEIDENREICH et al., 2008), FeaturePlugin (ANTKIEWICZ; CZARNECKI, 2004), Gears (KRUEGER, 2005), GenArch10 , Holmes (SUCCI et al., 2001), Kumbang (KOIVU, 2007), Ménage (GARG et al., 2003), PLUSEE (GOMAA; SHIN, 2004), pure::variants 11 , Requiline (MASSEN; LICHTER, 2003), S2T2 (BOTTERWECK et al., 2009), S.P.L.O.T. (MENDONCA et al., 2009), VarMod. 12. , V-Manage (BAYER et al., 2006) e XTof (GAUTHIER et. al., 2010). 9. http://ase.jku.at/dopler/ http://www.inf.puc-rio.br/~ecirilo/genarch/ 11 http://www.pure-systems.com/fileadmin/downloads/pv-whitepaper-en-04. pdf 12 http://www.sse.uni-essen.de/swpl/SEGOS-VM-Tool/ 10. 39.

(40) Segundo a Tabela 2.3, algumas técnicas adotam somente uma abordagem de modelagem de LPS para a especificação das funcionalidades que compõem o escopo de todo o sistema, modelando as partes comuns e variáveis entre os diversos produtos de software que formam uma LPS. Algumas destas técnicas, como FeatureMapper, FeaturePlugin, Ménage e Kumbang, somente realizam a modelagem, isto é, define os relacionamentos e as dependências entre as funcionalidades cobrindo somente a fase de projeto do ciclo de vida da LPS. Outras técnicas como COVAMOF, DOPLER, Holmes e CodeScoping realizam também o processo efetivo de construção do produto baseado na seleção de componentes concretos através do mapeamento dos assets reusáveis às funcionalidades selecionadas para compor o produto final. Porém, essas técnicas não permitem realizar customizações nos assets que possibilitem a existência de diferentes especificações de código (variações) para uma mesma funcionalidade. Tabela 2.3: Classificando as Técnicas de LPS de Abordagem de Modelagem. Técnica. Configuração do Produto. Fases do Ciclo de Vida. CodeScoping CONSUL COVAMOF DOPLER FAMA-FW FeatureIDE FeatureMapper FeaturePlugin Gears GenArch Holmes Kumbang Ménage PLUSEE pure::variants RequiLine S2T2 S.P.L.O.T. VarMod V-Manage XToF. NÃO SIM SIM SIM NÃO SIM SIM SIM SIM SIM NÃO SIM NÃO SIM SIM SIM NÃO SIM SIM SIM SIM. P A,P,I A,P,I C,A,P,I A, P A,P,I P P A,P,I P, I TD P P A, P TD C,A,P A, P A, P A, P C,A,P,I A,P,I. Seleção dos Componentes Concretos SIM SIM SIM SIM NÃO SIM NÃO NÃO SIM SIM SIM NÃO NÃO NÃO SIM NÃO NÃO NÃO NÃO SIM NÃO. Geração dos Componentes Flexíveis NÃO SIM NÃO NÃO NÃO SIM NÃO NÃO SIM SIM NÃO NÃO NÃO SIM NÃO NÃO NÃO NÃO SIM SIM. Granularidade da Variabilidade NÃO SIM (G) NÃO NÂO NÃO SIM (G) NÃO NÃO SIM (G) SIM (G) NÃO NÃO NÃO SIM (G) NÃO NÃO NÃO NÃO SIM (G) SIM (G). Separação da Variação NÃO SIM NÃO NÃO NÃO SIM NÃO NÃO SIM SIM NÃO NÃO NÃO SIM NÃO NÃO NÃO NÃO SIM NÃO. Por outro lado, as técnicas pure::variants, Gears (KRUEGER, 2005), XToF (GAUTHIER et al., 2010), GenArch13 e CONSUL (BEUCHE et al., 2004), além de realizarem a especificação das funcionalidades correspondentes ao domínio da linha de produtos e a configuração do produto (através de um subconjunto válido de características que satisfazem as restrições presentes no modelo de características especificado para obtenção de um produto específico 13. http://www.inf.puc-rio.br/~ecirilo/genarch/. 40.

(41) da LPS), possuem como recurso adicional, a geração de componentes flexíveis. Esses componentes permitem efetuar customizações nos assets através de transformações e da composição de novos assets para possíveis adaptações às funcionalidades e a evolução da LPS devido a novos requisitos de domínio. O nível de granularidade provida por essas técnicas é grossa.. 2.2.4. Abordagem Transformacional. Na abordagem transformacional, os sistemas de transformação de programa fornecem mecanismos para a realização de modificações arbitrárias e não apenas a composição de módulos, como transformar a linguagem fonte de um programa num novo programa com linguagem diferente (por exemplo, na compilação) ou transformar um programa em um novo programa na mesma linguagem (por exemplo, na refatoração). Os mecanismos de implementação encontrados foram: Linguagem Específica de Domínio (Domain Specific Language - DSL14 ) e meta-programação para definir regras de transformações de programas (SAAKE et al., 2010). Em relação a este tipo de abordagem foram encontradas cinco propostas: DMS (Design Maintenance System) (BAXTER et al., 2004), JaTS (Java Transformation System) 15 , MetaJ 16 , Stratego/XT. 17. e TXL(Turing eXtender Language) 18 .. Tabela 2.4: Classificando as Técnicas de LPS de Abordagem Transformacional. Técnica. Configuração do Produto. Fases do Ciclo de Vida. DMS JaTS MetaJ Stratego/XT TXL. SIM SIM SIM SIM SIM. I I I I I. Seleção dos Componentes Concretos NÃO NÃO NÃO NÃO NÃO. Geração dos Componentes Flexíveis SIM SIM SIM SIM SIM. Granularidade da Variabilidade SIM(G,F) SIM(G,F) SIM(G,F) SIM(G,F) SIM(G,F). Separação da Variação SIM SIM SIM SIM SIM. Essas técnicas utilizam o casamento de padrão a ser correspondido, tornando possível a configuração de produtos e a geração de componentes flexíveis para efetuar customizações nos assets separadamente do código base do sistema original e permite granularidade grossa 14. A Domain Specific Language (DSL) é uma linguagem textual ou gráfica que proporciona abstrações de primeira classe representando diretamente os conceitos de domínio da aplicação. 15 www.cin.ufpe.br/~jats/ 16 www.emn.fr/sudholt/research/metaj/ 17 http://www.strategoxt.org 18 www.txl.ca. 41.

(42) e fina, como mostra a classificação realizada na Tabela 2.4. As técnicas Stratego/XT, DMS e TXL são baseadas em regras de reescrita para realizar as transformações na linguagem alvo de acordo com o padrão informado. A MetaJ e o JaTS utilizam templates que definem um padrão de código cujas sintaxes são bastante similares. Sendo que na MetaJ, os templates são então traduzidos para uma classe Java e o casamento é verificado através do método match() em que o código fonte é passado como parâmetro. O comportamento ao encontrar casamentos de padrões deve ser programado pelo desenvolvedor na linguagem Java. Já o JaTS utiliza templates de casamento e de geração. Os templates de casamento são descritos com base nos padrões do programa que se deseja modificar, enquanto que os de geração definem as modificações que serão produzidas pela transformação do programa.. 2.3. Análise comparativa das Técnicas de LPS. Esta seção traz uma análise comparativa das técnicas LPS nas abordagens de implementação, tendo como objetivo a indicação de algumas das técnicas condizentes com os critérios de implementação de variabilidades em sistemas, mencionados na Seção 2.2, considerados relevantes ao propósito deste trabalho. Na análise realizada sobre a Seção 2.2.3 referente às técnicas de abordagem de modelagem de LPS, foi verificado que apesar de existirem técnicas que efetuam customizações nos assets com granularidade grossa, através de mecanismos de implementação como anotação e composição, as mesmas necessitam das especificações das funcionalidades. As especificações compõem o escopo do sistema para que seja possível gerar diferentes configurações de produtos através da seleção, transformação ou combinação dos assets associados às funcionalidades selecionadas no processo de derivação do produto. Sendo assim, os mecanismos de implementação de variabilidade em LPS proposto por essa abordagem não se alinham com os objetivos deste trabalho, que se refere à customização do código fonte de sistemas originais desenvolvidos por empresas fornecedoras de software e adquiridos por outras organizações sem a realização de refatorações no código original cobrindo somente a fase de implementação e não contemplando a especificação e a modelagem de características do domínio, as quais seriam necessárias para adoção de uma das técnicas de abordagem de. 42.