Uma Abordagem Baseada em Heurísticas para Extração de Linhas de Produto de Software

Transcrição

1 Uma Abordagem Baseada em Heurísticas para Extração de Linhas de Produto de Software Autor: Felipe Nunes Gaia 1, Orientador: Marcelo de Almeida Maia 1 1 Programa de Pós-Graduação em Ciência da Computação Universidade Federal do Uberlândia (UFU) Uberlândia MG Brasil felipegaia@mestrado.ufu.br, marcmaia@facom.ufu.br Nível: Mestrado Ano de ingresso no programa: 2010 Época esperada de conclusão: Agosto / 2012 Resumo. O processo de extração de uma linha de produtos de software (LPS) a partir de um sistema legado pode não ser uma tarefa trivial e consumir muito tempo. Primeiro, os desenvolvedores precisam identificar os componentes responsáveis pela implementação de cada feature do software. Em seguida, devem localizar as linhas de código que referenciam os componentes descobertos no passo anterior. Finalmente, devem extrair essas linhas para módulos independentes ou devem anotar as linhas de alguma forma. A fim de acelerar a extração de linhas de produtos, este trabalho descreve uma abordagem baseada em heurísticas para identificar os melhores cenários de refatoramento das features em uma LPS. A abordagem proposta baseia-se em uma ferramenta identificação dos cenários, que integrado a IDE Eclipse permite identificar cenários através de métricas a partir de colorações pré-estabelecidas. Palavras-Chave. Linhas de produto de software, métricas de software e engenharia de software experimental.

2 1. Introdução e Motivação Linhas de Produto de Software (LPS) refere-se a técnicas emergentes de engenharia que procuram estabelecer o reuso sistemático de software através do compartilhamento de um núcleo comum aos produtos da linha [Clements and Northrop 2001]. Uma LPS contém produtos que compartilham um mesmo domínio de aplicação e possuem pontos de variabilidades entre eles. A adoção desse tipo de abordagem tem como objetivo aumentar a produtividade e a qualidade dos produtos, já que o núcleo é reusado e testado em vários produtos. Várias técnicas já foram utilizadas para implementar LPS. Técnicas baseadas em anotação, como diretivas de pré-processamento [Kernighan and Ritchie 1988], que permitem a separação de features de granularidade menor. Separação virtual de interesses, onde o código é dividido através também de anotações, geralmente por coloração, mas isto é feito virtualmente e não diretamente no código. Técnicas composicionais, como Programação Orientada à Aspectos [Kiczales et al. 1997] e Programação Orientada a Características [Prehofer 1997], que permitem a separação física das features em módulos distintos. No ciclo de vida de um software, mudanças são esperadas e precisam ser acomodadas [Grubb and Takang 2003]. Considerando uma LPS a tendência é existir um número maior de mudanças, já que a LPS necessita de evoluir para atender novas demandas dos stakeholders de vários produtos. Considerando este fato a extração de um LPS a partir de um sistema legado deve proporcionar a facilidade de evolução da mesma, absorvendo a propagação de mudanças e mantendo a estabilidade da arquitetura. Um estudo anterior [Ferreira et al. 2011] tentou estabelecer como melhor se aderem três diferentes técnicas (Compilação Condicional, Programação Orientada à Características e Padrões de Projeto) de implementação de LPS a alguns cenários de evolução. A partir dos resultados obtidos, o principal objetivo deste trabalho é estabelecer um processo para extração de LPS a partir de colorações previamente definidas através de heurísticas baseadas em métricas de modularidade e propagação de mudanças Objetivos Específicos Também são objetivos deste trabalho: - Projetar, implementar e avaliar uma ferramenta para auxílio a extração de LPS a partir de sistemas legados, utilizando as mesmas técnicas de [Ferreira et al. 2011]. A proposta visa facilitar o trabalho de extração de LPS através de alertas de cenários de refatoração onde as métricas de modularidade e propagação de mudanças irão diminuir, consequentemente facilitando posteriores evoluções da LPS. - Propor um processo iterativo para extração de LPS com o objetivo de orientar os desenvolvedores na aplicação da ferramenta proposta. O processo inicia-se com a entrada de uma coloração previamente estabelecida. Posteriormente, o usuário é alertado de possíveis cenários de refatoração do código. A cada etapa, a ferramenta avalia novamente as heurísticas até que não seja mais possível fazer refatorações. - Avaliar o processo de extração proposto em sistemas que possuem cenários de evolução definidos, comparando os resultados obtidos pela aplicação da solução com extrações realizadas manualmente.

3 2. Trabalhos Relacionados Esta seção apresenta alguns trabalhos existentes na literatura que estão relacionados à abordagem proposta. Na subseção 2.1 são apresentados os que se relacionam com as métricas em que este trabalho foi baseado. Em seguida, são abordados os relacionados a avaliação quantitativa de software a partir de métricas (Subseção 2.2). Finalmente, são apresentados alguns estudos já realizados de extração de LPS (Subseção 2.3) Métricas de Software As métricas de software surgiram com objetivo de auxiliar na tomada de decisões ajudando a identificar as possíveis melhorias nos artefatos do software [Fenton and Pfleeger 1998]. Muitas métricas já foram propostas [Chidamber and Kemerer 1994] [Henderson-Sellers 1996] [Lorenz and Kidd 1994], porém este trabalho concentrou-se em dois grupos de métricas: Métricas de estabilidade [Yau and Collofello 1985]: serão utilizadas para quantificar o grau de modificações no código fonte, considerando diferentes níveis de granularidade: Componentes Métodos Linhas de Código Métricas de modularidade [Garcia et al. 2005]: serão utilizadas para quantificar certas propriedades como coesão, acoplamento, separação de interesses e tamanho: Concern Diffusion over Components (CDC) Concern Diffusion over Operations (CDO) Number Of Concern Attributes (NOCA) Concern Diffusion over Lines of Code (CDLOC) Number Of Lines of Concern Code (LOCC) 2.2. Avaliação de Software Baseada em Métricas As abordagens de avaliação existentes que são baseadas em métricas utilizam atributos passíveis de mensuração para identificar características de qualidade como reusabilidade e manutenibilidade. Uma forma comum de se fazer este mapeamento é utilizando modelos de qualidade [Boehm et al. 1976] [Sant anna et al. 2003] [Figueiredo and Staa 2005]. Um modelo de qualidade foi proposto em [Sant anna et al. 2003], revisado em [Figueiredo and Staa 2005], com o objetivo de avaliar sistemas orientado a aspectos. Este modelo utiliza métricas de software para predizer características de manutenibilidade e reusabilidade Extração de LPS Em [Kästner et al. 2007] foi documentado a extração de features do sistema gerenciador de banco de dados (Berkley DB) usando programação orientada por aspectos (AspectJ). Como o sistema era de tamanho e complexidade consideráveis, foram encontrados diversos problemas durante a extração, a maioria decorrentes das limitações de AspectJ em lidar com variabilidades de granularidade fina. Uma abordagem formal para refatoração orientada a features foi descrita em [Liu et al. 2006]. A abordagem proposta, baseada na linguagem composicional AHEAD [Batory 2004], foi usada para extrair features do framework Prevayler. Porém os autores não detalharam as transformações necessárias no código base que permitiram a extração das features para refinamentos (as unidades de modularização suportadas em AHEAD).

4 3. Metodologia e Estado da Pesquisa O trabalho será dividido da seguinte forma: 1. Identificação das heurísticas a partir de 2 estudos de casos já realizados. 2. Implementação da ferramenta que guiará o implementador. 3. Extração da LPS a partir da ferramenta. 4. Comparação dos resultados com a linha extraída pelos projetistas Regras Heurísticas Cada regra é uma expressão baseada em métricas que indicam certas características das colorações avaliadas e podem apontar possíveis cenários de refatoração. O principal objetivo das regras é fornecer uma informação mais abstrata ao desenvolvedor, evitando que este trabalhe diretamente com números e, portanto, facilitar a interpretação dos resultados. Uma regra pode ser expressa como um comando condicional de acordo com a estrutura: SE <condição> ENTÃO <conseqüência> Uma condição contém a combinação de métricas e valores limites para avaliação dos cenários e uma consequência se apresenta como uma classificação da refatoração ideal para aquele cenário Ferramenta para Auxílio à Extração de LPS A ferramenta proposta não tem o objetivo de automatizar a extração da LPS, mas ela irá alertar o usuário sobre cenários onde é possível serem feitas refatorações de código e sugerir como as mesmas devem ser feitas de acordo com a técnica escolhida. Figura 1. Processo para extração da LPS Ela guiará o usuário através de um processo que se repete até que o sistema legado esteja transformado em uma LPS e que não exista mais cenários de refatoração que interessam o desenvolvedor, conforme a figura 1. Inicialmente as métricas são coletadas a partir da coloração, em seguida as regras heurísticas pré-estabelecidas são aplicadas de acordo com as métricas

5 e identifica os cenários possíveis de refatoração. Em seguida o usuário escolhe um cenário de aplica a refatoração manualmente. Assim o processo se repete coletando as métricas nos artefatos de código alterados Estado da pesquisa Atualmente o segundo estudo de caso está em fase de conclusão e a partir disso começam a ser identificados os cenários de refatoração, as heurísticas que os identificam e a maneira correta de se executar a refatoração de acordo com a técnica escolhida. 4. Cronograma do Trabalho até a Defesa Etapas: Etapas 2011/ Novembro Dezembro Janeiro Fevereiro Março Abril Maio Junho Julho Agosto 1: Identificação das heurísticas. 2: Implementação da ferramenta. 3: Primeiro Estudo de Caso. 4: Submissão de Trabalho. 5: Segundo Estudo de Caso. 6: Submissão de trabalho. 7: Escrita da dissertação. 8: Apresentação / Defesa. Referências Batory, D. (2004). Feature-oriented programming and the ahead tool suite. In Proceedings of the 26th International Conference on Software Engineering, ICSE 04, pages , Washington, DC, USA. IEEE Computer Society. Boehm, B. W., Brown, J. R., and Lipow, M. (1976). Quantitative evaluation of software quality. In Proceedings of the 2nd international conference on Software engineering, ICSE 76, pages , Los Alamitos, CA, USA. IEEE Computer Society Press. Chidamber, S. and Kemerer, C. (1994). A metrics suite for object oriented design. IEEE Transactions on Software Engineering, 20: Clements, P. and Northrop, L. (2001). Software Product Lines: Practices and Patterns. SEI Series in Software Engineering. Addison Wesley. Fenton, N. E. and Pfleeger, S. L. (1998). Software Metrics: A Rigorous and Practical Approach. PWS Publishing Co., Boston, MA, USA, 2nd edition.

6 Ferreira, G., Gaia, F., Figueiredo, E., and Maia, M. (2011). On the use of feature-oriented programming for evolving software product lines: A comparative study. Brazilian Symposium on Programming Languages. Figueiredo, E. and Staa, A. (2005). Avaliação de um modelo de qualidade para implementações orientadas a objetos e orientadas a aspectos. PUC. Garcia, A., Sant Anna, C., Figueiredo, E., Kulesza, U., Lucena, C., and von Staa, A. (2005). Modularizing design patterns with aspects: a quantitative study. In Proceedings of the 4th international conference on Aspect-oriented software development, AOSD 05, pages 3 14, New York, NY, USA. ACM. Grubb, P. and Takang, A. (2003). Software maintenance: concepts and practice. World Scientific. Henderson-Sellers, B. (1996). Object-oriented metrics: measures of complexity. Prentice-Hall, Inc., Upper Saddle River, NJ, USA. Kästner, C., Apel, S., and Batory, D. (2007). A Case Study Implementing Features Using AspectJ. In Proceedings Int l Software Product Line Conference (SPLC), pages Kernighan, B. and Ritchie, D. (1988). The C programming language. Prentice-Hall software series. Prentice Hall. Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J.-M., and Irwin, J. (1997). Aspect-oriented programming. In Aksit, M. and Matsuoka, S., editors, ECOOP 97 Object-Oriented Programming, volume 1241 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg /BFb Liu, J., Batory, D., and Lengauer, C. (2006). Feature oriented refactoring of legacy applications. In Proceedings of the 28th international conference on Software engineering, ICSE 06, pages , New York, NY, USA. ACM. Lorenz, M. and Kidd, J. (1994). Object-Oriented Software Metrics: A Practical Approach. Prentice-Hall. Prehofer, C. (1997). Feature-oriented programming: A fresh look at objects. In Aksit, M. and Matsuoka, S., editors, ECOOP 97 Object-Oriented Programming, volume 1241 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg /BFb Sant anna, C., Garcia, A., Chavez, C., von Staa, A., and Lucena, C. (2003). On the Reuse and Maintenance of Aspect-Oriented Software: An Evaluation Framework. In XVII Brasilian Symposium on Software Engineering. Sociedade Brasileira da Computação. Yau, S. and Collofello, J. (1985). Design stability measures for software maintenance. Software Engineering, IEEE Transactions on, SE-11(9):