UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE CIÊNCIAS EXATAS E DA TERRA
DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA
APLICADA
PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E
COMPUTAÇÃO
SQUID IMPACT ANALYSER: UMA FERRAMENTA
PARA ANÁLISE DE IMPACTO DE MUDANÇA EM
LINHAS DE PRODUTO DE SOFTWARE
Alexandre Strapação Guedes Vianna
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE CIÊNCIAS EXATAS E DA TERRA
DEPARTAMENTO DE INFORMÁTICA E MATEMÁTICA
APLICADA
PROGRAMA DE PÓS-GRADUAÇÃO EM SISTEMAS E
COMPUTAÇÃO
SQUID IMPACT ANALYSER: UMA FERRAMENTA
PARA ANÁLISE DE IMPACTO DE MUDANÇA EM
LINHAS DE PRODUTO DE SOFTWARE
Alexandre Strapação Guedes Vianna
Dissertação de Mestrado submetida ao
Programa de Pós-Graduação em Sistemas e
Computação do Departamento de
Informática e Matemática Aplicada da
Universidade Federal do Rio Grande do
Norte como parte dos requisitos para a
obtenção do grau de Mestre em Sistemas e
Computação.
Orientador: Prof. Dr. Uirá Kulesza
Co-orientadora: Profa. Dra. Roberta de Souza Coelho
Catalogação de Publicação na Fonte. UFRN / SISBI/ Biblioteca Setorial Especializada do Centro de Ciências Exatas e da Terra – CCET.
Vianna, Alexandre Strapação Guedes.
Squid Impact Analyser: Uma Ferramenta para Análise de Impacto de Mudança em Linhas de Produto de Software / Alexandre Strapação Guedes Vianna – Natal, RN, 2012.
113f. : il.
Orientador: Uirá Kulesza.
Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. Programa de Pós -Graduação em Sistemas e Computação.
1. Software – Desenvolvimento - Dissertação. 2. Linhas de Produto de Software – Dissertação. 3. Análise de Impacto de Mudanças – Dissertação. 4. Evolução em Linhas de Produto de Software – Dissertação. I. Kulesza, Uirá. II. Universidade Federal do Rio Grande do Norte. III. Título.
AGRADECIMENTOS
Em primeiro lugar agradeço a minha família por todo apoio que me deram durante esses
dois anos. Obrigado aos meus pais, Pedro e Cristina, que com todo amor e dedicação me
ensinaram valores e sempre serviram como exemplo de vida a ser seguido, me motivaram
a estudar, e deram apoio, conselhos e estrutura em todas as fases da minha vida para que
eu conquistasse meus objetivos. Às minhas irmãs, Carolina e Catarina, companheiras
sempre dispostas a me ouvir, também me ajudando a relaxar nos momentos de estresse
quando eu chegava de viajem.
Agradeço em especial a Uirá meu orientador nessa jornada por toda a dedicação
durante o mestrado, os valorosos ensinamentos acadêmicos, as longas conversas e
discussões, as revisões da dissertação, os conselhos acadêmicos e profissionais, e toda a
paciência nesse período. E acima disso, Uirá também ficou marcado como um grande
amigo, sendo um companheiro fora da universidade nos momentos de descontração como
nas peladas de terça feira, nas corridas, nos happy hours, e nas conversas e conselhos para
minha vida pessoal que me ajudaram muito nas indecisões que passei nesse período.
Aos membros da banca examinadora Roberta Coelho, Dalton Serey e Marcia
Lucena, que contribuíram com as discussões para a melhoria deste trabalho. Em especial a
Roberta que também foi co-orientadora deste trabalho e colaborou significativamente com
sugestões de melhorias.
Aos colegas de mestrado que me acompanharam nessa jornada e se tornaram
grandes amigos: Marília, Daniel, Mário, Diogo, Demóstenes, Jadson, Edmilson, Felipão,
Liliane e Tainá. Em especial Marília que sempre se mostrou uma ótima amiga, prestativa e
companheira para açaís, caronas, saídas e conversas.
A Lívia que com amor e carinho me acompanhou nos momentos finais do
mestrado.
Aos amigos que fiz em Natal que sempre me apoiaram e me receberam muito bem
tornando a minha mudança para Natal muito mais tranquila: Bruno Barros, Raquel,
Johnny, Bruno Anacleto, Mayron e Caroline.
Agradeço em especial aos amigos de João Pessoa que sempre estiveram do meu
lado e me proporcionaram ótimos momentos de descontração quando precisei: Luis
Felipe, Lucas, Hugo, Saulo, Caio, Antônio, Amaro, Artur e Pizzol.
A Superintendência de Informática da UFRN e ao CNPQ - que contribuíram com o
RESUMO
Linhas de Produtos de Software (LPS) consiste em um paradigma de
desenvolvimento de software, no qual famílias de sistemas compartilham características
comuns e tornam explícitas outras características que variam de acordo com o sistema
final sendo considerado. Esta abordagem oferece benefícios ao desenvolvimento de
software como redução de custos, qualidade do produto final, produtividade e tempo de
desenvolvimento reduzido. Por outro lado, a abordagem impõe novos desafios para a
atividade de evolução dos artefatos que modelam e implementam a LPS. Trabalhos de
pesquisa recentes propõem abordagens com suporte automatizado de ferramentas de
análise de impacto de mudança no contexto de evolução de LPSs. Tais abordagens são
baseadas em técnicas de análise de impacto de mudanças e rastreabilidade de artefatos,
porém apresentam limitações quanto à análise de impacto de mudanças em variabilidades
de granularidade fina, bem como à customização dos tipos e estratégias de análise
realizadas. Esta dissertação propõe uma ferramenta de análise de impacto de mudança,
denominada Squid Impact Analyzer, que utiliza uma estratégia de estimativa de impacto
baseada em informações de características, mapeamento de tais características em
artefatos de código, e dependência existente entre artefatos de implementação. A
ferramenta é avaliada através da condução de experimentos que realizam a quantificação
de métricas de cobertura, precisão e média harmônica nos resultados de buscas de análise
de impacto de mudança da ferramenta proposta em contraposição às mudanças reais
realizadas nos artefatos de diversas versões de evolução de uma LPS para gerenciamento
de mídias em dispositivos móveis. A ferramenta foi desenvolvida com base em uma
infraestrutura que serve de base para a instanciação de ferramentas de análise de
propriedades de código de LPSs, e que é também parte da contribuição da dissertação.
ABSTRACT
Software Products Lines (SPL) is a software engineering approach to developing
software system families that share common features and differ in other features according
to the requested software systems. The adoption of the SPL approach can promote several
benefits such as cost reduction, product quality, productivity, and time to market. On the
other hand, the SPL approach brings new challenges to the software evolution that must
be considered. Recent research work has explored and proposed automated approaches
based on code analysis and traceability techniques for change impact analysis in the
context of SPL development. There are existing limitations concerning these approaches
such as the customization of the analysis functionalities to address different strategies for
change impact analysis, and the change impact analysis of fine-grained variability. This
dissertation proposes a change impact analysis tool for SPL development, called Squid
Impact Analyzer. The tool allows the implementation of change impact analysis based on
information from variability modeling, mapping of variability to code assets, and existing
dependency relationships between code assets. An assessment of the tool is conducted
through an experiment that compare the change impact analysis results provided by the
tool with real changes applied to several evolution releases from a SPL for media
management in mobile devices.
SUMÁRIO
1 Introdução ... 1
1.1 Problema ... 2
1.2 Limitações das Abordagens Existentes ... 3
1.3 Trabalho Proposto... 4
1.4 Objetivos Gerais e Específicos ... 5
1.5 Organização do Trabalho ... 6
2 Fundamentação Teórica ... 7
2.1 Linhas de Produto de Software ... 7
2.2 Derivação Automática de Produto ... 9
2.2.1 GenArch ... 11
2.3 Evolução de Software no contexto de LPS ... 15
2.3.1 Rastreamento em Linhas de Produto de Software ... 17
2.3.2 Análise de Impacto de Mudanças ... 19
2.4 Análise Estática de Código ... 21
2.4.1 Design Wizard ... 23
2.5 Sumário... 24
3 Squid Analyser: Uma Infraestrutura Extensível de Análise de Linhas de Produto de Software ... 25
3.1 Arquitetura Geral da Infraestrutura ... 25
3.2 Projeto Detalhado ... 28
3.2.1 Módulo Núcleo do Squid ... 28
3.2.2 Squid Analyser Model ... 31
3.2.4 Analisador de Dependência de Código ... 36
3.2.5 Buscas de Análises de Código da LPS ... 43
3.2.6 Visualizações de Análise em Linha de Produto ... 45
3.3 Instanciação da Infraestrutura ... 47
3.4 Sumário... 49
4 Squid Impact Analyser: Uma Ferramenta para Análise de Impacto de Mudanças 50 4.1 Visão Geral do Funcionamento da Ferramenta ... 50
4.2 Arquitetura ... 54
4.3 Buscas de Análise de Impacto de Mudanças ... 57
4.3.1 Busca de Impactos de Remoção de Características ... 57
4.3.2 Busca de Impacto de Mudanças de Características em Profundidade. 59 4.3.3 Busca de Impacto de Mudança de Artefatos em Profundidade. ... 61
4.3.4 Busca de Impacto de Mudanças de Tipo de Característica de Obrigatória para Opcional ... 62
4.4 Visualizações de Análise de Impacto de Mudanças ... 63
4.5 Sumário... 66
5 Avaliação do Squid Impact Analyser ... 67
5.1 Métricas para Avaliação da Análise de Impacto de Mudanças ... 67
5.2 Linha de Produto Mobile Media ... 70
5.3 Experimento 1... 73
5.3.1 Configuração do Experimento ... 74
5.3.2 Resultados e Avaliação do Experimento... 74
5.4.1 Configuração do Experimento ... 82
5.4.2 Resultados e Avaliação do Experimento... 83
5.5 Ameaças à Validade do Experimento ... 89
5.6 Sumário... 90
6 Trabalhos Relacionados ... 92
6.1 AMPLE Traceability Framework ... 92
6.2 Interfaces Emergentes ... 94
6.3 Análise de Impacto Baseada em Rastreabilidade para LPS ... 96
7 Considerações Finais ... 99
7.1 Contribuições ... 100
7.2 Trabalhos Futuros ... 101
REFERÊNCIAS ... 103
LISTA DE FIGURAS
Figura 1. Atividades essenciais de desenvolvimento de LPS. ... 9
Figura 2. Abordagem generativa. ... 10
Figura 3. Modelos GenArch. ... 13
Figura 4. Arquitetura da ferramenta GenArch. ... 14
Figura 5. Visão Geral da Infraestrutura... 26
Figura 6. Diagrama de Componentes da Infraestrutura. ... 27
Figura 7. Diagrama de classes da infraestrutura. ... 29
Figura 8. Diagrama de interação da infraestrutura. ... 30
Figura 9. Squid Analyser Model. ... 32
Figura 10. Extensão do Squid Analyser Model. ... 33
Figura 11. Transformação GenArch para Squid. ... 36
Figura 12. Código do método extractMethodDependencies. ... 38
Figura 13. Visualização da AST Java pelo plugin ASTView. ... 39
Figura 14. Atividades da análise de código utilizando a AST Java. ... 40
Figura 15. Anotações de fragmentos de código. ... 41
Figura 16. Código fonte com as entidades do tipo nome simples destacadas. ... 42
Figura 17. Código do classe ASTExplorer do analisador estático de código. ... 43
Figura 18. Código da busca FeatureTraceability... 45
Figura 20. Código da busca FeatureTraceability... 47
Figura 21. Exemplo de cadeia de relacionamentos. ... 51
Figura 22. Diagrama de atividades da ferramenta Squid Impact Analyser. ... 52
Figura 23. Exemplo de grafo. ... 53
Figura 24. Diagrama de componentes de instanciação da infraestrutura. ... 55
Figura 25. Atividades da ferramenta Squid Impact Anayser. ... 56
Figura 26. Trecho de código fonte da classe ImpactOfRemovingFeature. ... 58
Figura 27. Diagrama de classe do modelo de visualização de impactos. ... 64
Figura 28. Código fonte da visualização de impacto de mudanças. ... 65
Figura 29. Vizualização do modelo de impacto de mudanças... 66
Figura 30. Categorização dos artefatos na análise de impacto de mudanças. ... 68
Figura 31. Modelo de características da versão 7 do Mobile Media. ... 70
Figura 32. Taxas da métrica precisão. ... 79
Figura 33. Taxas da métrica cobertura. ... 80
Figura 34. Média Harmônica. ... 81
Figura 35. Taxas da métrica precisão. ... 87
Figura 36. Taxas da métrica cobertura. ... 88
Figura 37. Média Harmônica. ... 89
Figura 38. Modelo de características da versão 3 do Mobile Media. ... 109
Figura 40. Modelo de características da versão 5 do Mobile Media. ... 111
Figura 41. Modelo de características da versão 6 do Mobile Me dia. ... 112
Figura 42. Modelo de características da versão 7 do Mobile Media. ... 112
LISTA DE TABELAS
Tabela 1. Evoluções do Mobile Media. ... 71
Tabela 2. Quantidade de artefatos por versão do Mobile Media. ... 72
Tabela 3. Resumo de mudanças de artefatos durante evoluções do Mobile Media. .. 72
Tabela 4. Conjunto de Impacto Real (CIR) e Conjunto de Seme ntes (CS). ... 75
Tabela 5. Conjunto de Impacto Estimado (CIE). ... 75
Tabela 6. Falso-Positivos e Falso-Negativos. ... 76
Tabela 7. Conjunto Intersecção. ... 77
Tabela 8. Métricas precisão, cobertura e média harmônica para Estratégia Orientada a Características. ... 77
Tabela 9. Métricas precisão, cobertura e média harmônica da estratégia não orientada a características. ... 78
Tabela 10. Conjunto de Impacto Real (CIR). ... 83
Tabela 11. Conjunto de Impacto Estimado (CIE). ... 84
Tabela 12. Conjunto de Falso-Positivo (CFP) e Conjunto de Falso-Negativo (CFN). ... 84
Tabela 13. Conjunto Intersecção. ... 85
Tabela 14. Métricas precisão e cobertura da estratégia orientada a análise de dependência de código. ... 86
LISTA DE SIGLAS
AJDT AspectJ Development Toolkit
API Application Program Interface
AST Árvore Sintática Abstrata
CFN Conjunto Falso-Negativo
CFP Conjunto Falso-Positivo
CI Conjunto Intersecção
CIE Conjunto de Impacto Estimado
CIR Conjunto de Impacto Real
CS Conjunto de Sementes
EMF Eclipse Modeling Framework
FMP Feature Model Plugin
JDT Java Development Toolkit
LPS Linhas de Produto de Software
SAM Squid Analysis Model
1
Introdução
Linhas de Produtos de Software (LPS) definem famílias de sistemas que
compartilham características comuns (similaridades) e tornam explícitas outras
características que variam (variabilidades) de acordo com o sistema final (produto) sendo
considerado (LINDEN et al., 2007). Esta abordagem oferece benefícios ao
desenvolvimento de software como redução de custos, melhora da qualidade do produto
final e tempo de desenvolvimento reduzido (time-to-market) (CLEMENTS; NORTHROP,
2002). Tais benefícios são obtidos a partir do reuso sistemático de arquiteturas de software
e artefatos de implementação, realizando este reuso de forma mais planejada e direcionada
a um domínio específico. Os benefícios da abordagem de LPS são estendidos com o
suporte de técnicas e ferramentas para automatização de tarefas do processo de
desenvolvimento. Embora, o uso da abordagem de LPS implique em vários benefícios ao
desenvolvimento de software, em contraponto existem alguns desafios técnicos para a
implementação da abordagem de LPS, tais como, mecanismos apropriados de
implementação de variabilidades, rastreamento de artefatos, automação do processo de
derivação de produtos, testes e evolução dos artefatos que determinam a LPS.
Atualmente, o mercado de software impõe um ritmo acelerado de mudanças de
requisitos, assim como também surgem novas tecnologias de implementação e de
hardware. Essas mudanças impactam na evolução de sistemas de software e impõem
desafios para aos engenheiros de software. De acordo com estudos apresentados em
(CUSUMANO; SELBY, 1998), durante o ciclo de vida de software, os requisitos iniciais
do software podem mudar em mais de 30%. Deste modo, a evolução é algo rotineiro e
constante no ciclo de vida de um sistema de software (SOMMERVILLE, 2007), esse
aspecto deve ser pensado desde o início do projeto do software. Quanto mais cedo o
aspecto de evolução for considerado no desenvolvimento de um sistema de software,
menores serão as possibilidades de decadência prematura do mesmo (GODFREY;
GERMAN, 2008).
Como ocorre nos processos tradicionais de desenvolvimento, a evolução de
software também se aplica à abordagem de LPS. No entanto, existem fatores específicos
relacionados às propriedades inerentes do desenvolvimento de LPS, e que portanto, estão
de variabilidades – características que são variáveis na LPS; e (ii) modelagem de
conhecimento de configuração – relacionamentos de mapeamento de variabilidades com
artefatos de implementação. Dessa forma, o gerenciamento de evolução em LPS apresenta
peculiaridades específicas, que envolve lidar com artefatos que representam não apenas
um único software, mas uma família de sistemas relacionados, o que exige abordagens
orientadas para este contexto. A adoção de técnicas para suporte a evolução de LPS
(JIRAPANTHONG; ZISMAN, 2005) (ANQUETIL et al., 2010) pode trazer benefícios ao
desenvolvimento e manutenção das LPS, tais como, diminuir o esforço das atividades de
manutenção e evolução da LPS, evitar a inserção de erros colaterais devido a alterações e
prevenir erros antes que eles aconteçam.
1.1
Problema
O desenvolvimento de LPS envolve a elaboração de inúmeros artefatos, de vários
tipos (implementação, documentação e modelagem), de diferentes níveis de abstração
(espaço do problema, espaço da solução e conhecimento de configuração) e gerados em
diferentes fases de desenvolvimento (engenharia de domínio e de aplicação). Além disso,
existem relacionamentos complexos envolvendo tais artefatos, o que consequentemente
traz dificuldades para gerenciar os artefatos e seus relacionamentos, fazendo-se necessário
o uso de técnicas específicas de gerência e modelagem para LPS.
Durante a evolução de uma LPS, os artefatos gerados estão constantemente sujeitos
a alterações, e é muito provável que alterações em um artefato afetem outros artefatos que
estão direta ou indiretamente relacionados. Os impactos oriundos de tais alterações
precisam ser identificados e analisados pela equipe de desenvolvimento, a qual deverá
tomar as devidas precauções com o objetivo de evitar a introdução de erros nos demais
artefatos. A análise de impacto de mudanças não é uma tarefa trivial de ser executada
manualmente por desenvolvedores e exige o suporte de técnicas e ferramentas
especializadas. No contexto de evolução de LPSs, a diversidade dos artefatos produzidos e
suas respectivas dependências, bem como a complexidade existente oriunda do fato de
uma LPS representar uma família de sistemas para um segmento específico, torna a
1.2
Limitações das Abordagens Existentes
Trabalhos recentes exploram os benefícios para evolução de software de
abordagens de análise de impacto de mudanças baseadas em técnicas de rastreabilidade e
análise estática de código. O trabalho apresentado por (ANQUETIL et al., 2010) propõe
um framework dirigido por modelos para rastreabilidade de artefatos, denominado
AMPLE Traceability Framework (ATF). A proposta principal do ATF é oferecer suporte
para rastreamento de artefatos ao longo do ciclo de vida de LPS, através do uso de
técnicas de engenharia dirigida a modelos. O ATF possibilita a identificação de
dependências entre os artefatos, o que permite avaliar os impactos de mudanças entre os
mesmos. No entanto, o ATF não foi elaborado com o foco específico de análise de
impacto de mudanças, e dessa forma ele não prevê a análise de dependências de artefatos
de código, através da integração com frameworks ou ferramentas existentes de análise
estática ou dinâmica de código.
No trabalho proposto por (RIBEIRO et al., 2011) é apresentado o CIDE Emergent
Interfaces (CIDE EI), uma ferramenta que oferece suporte a evolução de LPS
implementadas utilizando técnicas de compilação condicional e a abordagem de separação
virtual de interesses (VSoC – Virtual Separation of Concerns). O trabalho explora o
problema das dependências entre fragmentos de código de compilação condicional
ocultadas pela VSoC, com uma ferramenta de auxílio ao desenvolvedor durante as
modificações de código. A ferramenta oferece suporte ao desenvolvedor, para analisar o
fluxo de dados da LPS e informar quais componentes (classes, métodos) de código de
quais características estão sofrendo impactos ao modificar o código de uma característica
específica. Apesar do CIDE EI oferecer benefícios para rastrear dependências entre
elementos de código que implementam as características, a ferramenta foi desenvolvida
para lidar explicitamente com dependências de código entre variabilidades implementadas
com compilação condicional. Desta forma, ela oferece suporte para um tipo específico de
análise não fornecendo funcionalidades para definir análises customizadas.
Em (OLIVEIRA, 2011) é apresentada uma abordagem com uma ferramenta
associada para a análise de impacto de mudanças em LPS baseada em técnicas de
rastreabilidade de artefatos. As informações de rastreabilidade são utilizadas para apoiar a
por meio dos seus artefatos. Embora a abordagem ofereça suporte ferramental, nem todas
as etapas são automatizadas. As relações de rastreabilidades não podem ser inferidas
diretamente através dos modelos de entrada, e exigem a participação dos engenheiros da
LPS para auxiliar nessa atividade. A abordagem realiza a análise de impacto de mudanças
com base apenas em informações de rastreabilidade de artefatos de alto nível (diagrama de
casos de uso, modelo de características e diagrama de classes), não havendo nenhum tipo
de análise de dependências de artefatos de código.
Os trabalhos descritos abordam o problema de análise de impacto de mudanças no
contexto de evolução de LPS propondo ferramentas específicas. Apenas o trabalho de
(RIBEIRO et al., 2011) provê uma análise de impacto com base em informações de
características e dependência dos artefatos da LPS, mas que focaliza a análise de
dependências de implementações baseadas em compilação condicional ou com separação
virtual de interesses. Apesar da relevância de tais trabalhos, nenhum deles propõe uma
ferramenta ou abordagem, que seja extensível para permitir: (i) a incorporação de novos
tipos de artefatos e dependência entre os mesmos; (ii) a definição de análises específicas
que levam em consideração as informações das variabilidades da LPS e respectivas
dependências; e (iii) a adoção de técnicas que levem em consideração a análise de
dependências entre artefatos de implementação.
1.3
Trabalho Proposto
Tendo em vista os problemas existentes e as limitações das abordagens atuais, este
trabalho de dissertação propõe o desenvolvimento de uma ferramenta de análise de
impacto de mudanças para LPSs, denominada Squid Impact Analyser, que leva em
consideração informações: (i) das variabilidades da LPS; (ii) do mapeamento de tais
variabilidades para artefatos de implementação; e (iii) de dependências entre seus artefatos
de implementação. A ferramenta proposta é desenvolvida com base em uma infraestrutura
de software extensível implementada na plataforma Eclipse (D’ANJOU et al., 2005), que
disponibiliza pontos de extensão para a definição de análises específicas de acordo com os
tipos de artefatos de modelagem e implementação da LPS. O desenvolvimento de tal
infraestrutura é também parte do escopo desta dissertação. O projeto da infraestrutura de
software compreende a definição de um modelo de análise para armazenar e estruturar as
informações relevantes para análises de LPS, tais como, características, artefatos de
relacionamentos de dependência entre artefatos de implementação. O modelo proposto
lida com o desafio da modelagem dos artefatos que compõem a LPS e seus complexos
relacionamentos, inclusive os relacionamentos entre os artefatos de implementação.
A ferramenta proposta permite a implementação de estratégias de análise de
impacto de mudanças apoiadas por técnicas de rastreabilidade em LPS e de análise
estática de código fonte. Estas técnicas de análise podem apoiar a gerência de evolução de
uma LPS (KRUEGER, 2001). A análise de código fonte é realizada com o auxilio de
ferramentas de análise estática de código fonte, que permitam obter relacionamento de
dependência entre artefatos de granularidade fina, especificamente, métodos, atributos e
fragmentos de código.
Por fim, a ferramenta proposta neste trabalho permite que os potenciais efeitos de
mudanças que ocorrem no contexto de evolução de uma LPS, sejam identificados antes da
sua realização. As informações retornadas pela ferramenta são úteis para o planejamento
das mudanças, possibilitando aos engenheiros da LPS definir estratégias que permitam
lidar com o projeto e a implementação das mudanças.
1.4
Objetivos Gerais e Específicos
O objetivo principal do trabalho é propor e implementar a ferramenta Squid Impact
Analyzer que oferece suporte para a análise de impacto de mudanças de implementações
de linhas de produto de software. A ferramenta permite estimar os impactos de mudanças
em características e artefatos de implementação, bem como prover suporte para a
definição e customização de diferentes análises de impacto de mudanças. Os objetivos
específicos do trabalho são:
(I). Projeto e implementação de uma infraestrutura de software extensível que
permita o desenvolvimento de ferramentas de análise de código de LPS, assim
como prover suporte para a análise de impacto de mudanças.
(II). Definição de um modelo de análise para armazenar e organizar as informações
dos artefatos que modelam e implementam uma LPS, contemplando também as
(III). Incorporação e combinação de técnicas de análise estática de código em
conjunto com informações de rastreabilidade de LPS para promover a análise
de impacto de mudanças em LPS.
(IV). Projeto e implementação de estratégias para análise de impacto de mudanças
que inclua artefatos de granularidade fina, tais como, classes, métodos,
atributos e fragmentos de código.
(V). Avaliação do trabalho através da condução de experimentos com a finalidade
de comparar a influência do uso de informações de dependência de código
fonte e de rastreabilidade de LPS na estratégia de análise de impacto de
mudanças para LPS. A avaliação é realizada com o cálculo de métricas
direcionadas para análise de impacto de mudanças.
1.5
Organização do Trabalho
Além do capítulo introdutório, este documento apresenta mais seis capítulos que
estão organizados como segue. O Capítulo 2 apresenta os conceitos que apoiaram a
fundamentação teórica do trabalho: linhas de produto de software, derivação automática
de produtos, evolução de LPS, rastreabilidade em LPS, análise de impacto de mudanças
em LPS e análise estática de código. O Capítulo 3 apresenta o projeto e implementação da
infraestrutura Squid para o desenvolvimento de ferramentas de análise de código de LPSs.
O Capítulo 4 apresenta o projeto e a implementação do Squid Impact Analyzer, uma
ferramenta de análise de impacto de mudanças desenvolvida como uma instância da
infraestrutura de software proposta no Capítulo 3. O Capítulo 5 apresenta a avaliação do
trabalho, no qual é adotada uma LPS para realizar experimentos e calcular métricas para
avaliação de análise de impacto de mudanças. Os experimentos realizados exploram: (i) a
influência das informações de características na análise de impacto de mudanças em LPSs;
e (ii) a influência das informações de dependências de código fonte na análise de impacto
de mudanças em LPSs. O Capítulo 6 descreve trabalhos relacionados confrontando -os
com o trabalho desenvolvido nesta dissertação. Finalmente, o Capítulo 7 apresenta as
considerações finais a respeito do trabalho, destacando suas contribuições e
2
Fundamentação Teórica
Este capítulo apresenta o contexto teórico em que este trabalho está inserido. Ele
contempla uma visão geral da área de Linhas de Produto de Software (Seção 2.1), uma
breve introdução sobre Derivação Automática de Produtos (Seção 2.2), com a descrição
da ferramenta de derivação GenArch (Seção 2.2.1) que é usada no nosso trabalho. Em
seguida, são apresentados conceitos sobre Evolução de Software no Contexto de Linhas de
Produto de Software (Seção 2.3) e sobre Análise Estática de Código (Seção 2.4), com a
apresentação da ferramenta Design Wizard (Seção 2.4.1).
2.1
Linhas de Produto de Software
Motivadas pela tendência do aumento do reuso em engenharia de software,
pesquisadores da academia e indústria propuseram várias abordagens que direcionam o
foco do desenvolvimento de sistemas específicos para o desenvolvimento de famílias de
sistemas. Essas abordagens culminaram na proposta de desenvolvimento de software na
forma de linhas de produto de software (DONOHOE, 2000). Uma linha de produto de
software (LPS) é uma abordagem que propõe a derivação sistemática de produtos de
software a partir de um conjunto de componentes e artefatos comuns (CLEMENTS;
NORTHROP, 2002). O termo “Linha de Produto de Software” foi designado para nomear
uma família de sistemas que atende a um segmento específico de mercado. Conforme
Cohen, (COHEN, 2002), uma das definições de LPS de maior aceitação é a de Clements e
Northrop que diz que:
“Uma linha de produto de software é um conjunto de sistemas que usam
software intensivamente, compartilhando um conjunto de características comuns e gerenciadas, que satisfazem as necessidades de um segmento particular de mercado ou missão, e que são desenvolvidos a partir de um conjunto comum de ativos principais e de uma forma preestabelecida.”
(CLEMENTS; NORTHROP, 2002).
Diversos benefícios têm sido relatados por pesquisadores no que diz respeito à
adoção de métodos, técnicas e ferramentas de desenvolvimento de LPS (POHL et al.,
Redução no custo de desenvolvimento: artefatos reutilizados em vários sistemas implicam na redução do custo de desenvolvimento e de manutenção individual de cada
sistema.
Aumento de qualidade: os artefatos do núcleo de uma LPS são reutilizados em vários sistemas. Desta maneira, eles são testados e revisados várias vezes. Ou seja, existe
uma grande chance de detectar falhas e corrigí-las, melhorando assim a qualidade final do
produto.
Redução do tempo de entrega (time-to-market): nas fases iniciais de desenvolvimento da LPS exige-se mais tempo comparando ao desenvolvimento de um
sistema por processos tradicionais, pois a implementação da LPS segue uma sistemática
para o reuso dos artefatos posteriormente. Após a implementação da LPS, o tempo de
entrega é reduzido, pois muitos componentes previamente desenvolvidos poderão ser
reusados para a geração de produtos. Após a geração de alguns produtos já se obtêm
benefícios em tempo de desenvolvimento (MATOS, 2008).
Esta inovação na forma de desenvolver sistemas de software trouxe à tona a
necessidade de prover métodos, técnicas e ferramentas para produção em larga escala de
famílias de produtos, dando origem à área de engenharia de LPS. O instituto de
engenharia de software (SEI – Software Engineering Institute) da Carnegie Mellow
University estabelece através da iniciativa Product Line Practice, três atividades
essenciais para a prática de uma abordagem de LPS (SEI, 2011): engenharia de domínio,
engenharia de aplicação e gerenciamento de LPS. A Figura 1 ilustra tais atividades.
Na engenharia de domínio, o foco é o desenvolvimento dos artefatos que deverão
ser reusados em todas as fases do desenvolvimento (ou derivação) de um produto
específico da LPS. Na engenharia de aplicação, os artefatos (ativos) reusáveis produzidos
na engenharia de domínio (arquitetura comum, componentes, modelos etc.), são utilizados
no processo de desenvolvimento permitindo a rápida geração de variantes de produtos, ou
de partes de produtos, que podem ser posteriormente customizados visando atender a
alguma especificidade. E por fim o gerenciamento da LPS busca garantir que as atividades
Figura 1. Atividades essenciais de desenvolvimento de LPS.
2.2
Derivação Automática de Produto
A derivação de produtos em LPS pode ser totalmente automática, completamente
manual, ou semi-automática (CHASTEK; DONOHOE; MCGREGOR, 2004). Um
exemplo de abordagem totalmente manual é o processo de produção baseado em planos
textuais, onde os engenheiros de software seguem um plano com instruções estabelecidas
pelo processo para a derivação de produtos. A derivação automática consiste na
automação do processo de engenharia de produtos, e é implementada com uso de
abordagens ferramentais que utilizam especificações do conhecimento de domínio e de
aplicação, técnicas de implementação de variabilidades e a gerência do conhecimento de
configuração.
A especificação do conhecimento de domínio e de aplicação implementada por
ferramentas de derivação pode ser baseada na abordagem generativa para LPS. A
programação generativa focaliza o estudo e a definição de métodos e ferramentas que
em modelos (CZARNECKI; EISENECKER, 2000). No contexto da derivação automática
de produtos, a programação generativa orientada a modelagem da LPS promove a
separação de interesses entre espaço do problema e espaço da solução, permitindo
abordá-los independentemente. A Figura 2 apresenta a divisão de abstrações de acordo co m a
abordagem generativa: (i) espaço do problema – inclui conceitos e características
associadas a um domínio específico; (ii) espaço da solução – contém a arquitetura do
software e os artefatos usados para derivar produtos de uma família; e (iii) conhecimento
de configuração – compreende um conjunto de mapeamentos entre o espaço do problema
e o espaço da solução, relacionando principalmente características com artefatos.
Figura 2. Abordagem generativa.
Algumas ferramentas para gerência de variabilidades e derivação automática de
produtos de software têm sido desenvolvidas, tais como, Gears e pure::variants.
Gears, é uma ferramenta comercial para derivação de produtos desenvolvida pela
BigLever Software (KRUEGER, 2007). A ferramenta é composta basicamente por três
elementos: (i) infraestrutura: corresponde aos arquivos e diretórios adicionados aos
artefatos de software que implementam a LPS; (ii) ambiente de desenvolvimento: é
utilizado para criar, organizar e manter as LPS; e (iii) configurador: é responsável por
derivar instâncias de uma LPS. O processo de derivação implementado pela ferramenta é
baseado em descrições de alto nível que apresentam as características configuradas para
pure::variants, é uma ferramenta comercial desenvolvida pela pure-systems
GmbH (BEUCHE, 2008). O pure::variants foi desenvolvido para apoiar o
desenvolvimento e a implantação de LPS e famílias de software. O pure::variants provê
suporte no desenvolvimento durante as atividades de análise, modelagem, implementação
e implantação. No processo de derivação de produtos do pure::variants são empregados
dois tipos de modelos: modelo de características e modelo de família. O modelo de
características contém as variabilidades da LPS enquanto o modelo de família descreve a
estrutura interna de cada componente e suas dependências em relação às características.
Essas ferramentas apresentam funcionalidades úteis para a derivação de produtos
de software, mas são, em geral, complexas e pesadas para serem usadas pela comu nidade
de desenvolvedores que possuem com pouca familiaridade com vários dos novos
conceitos propostos pela comunidade de LPS. Para o contexto desse trabalho a derivação
automática de produtos está associada principalmente a etapa de extração de informações
para a análise de impacto de mudanças. A nossa abordagem aproveita as informações de
modelagem de LPS geradas por ferramentas de derivação automática para alimentar um
modelo de análise de LPS. Dessa forma, a idéia é reutilizar a infraestrutura de software
que implementa toda a parte de modelagem de LPS. A Seção 2.2.1 apresenta a ferramenta
de derivação automática GenArch, que foi adotada para a importação de informações de
modelagem de LPS, ao final são apresentadas justificativas para esta escolha.
2.2.1
GenArch
GenArch é uma ferramenta baseada em modelos que visa simplificar a derivação
automática (DEELSTRA et al., 2005) de novos membros de uma LPS ou instâncias de
frameworks OO. A ferramenta é baseada nos conceitos de programação generativa
(CZARNECKI et al., 2000). A programação generativa contempla métodos e técnicas que
permitem a geração automática de membros de uma linha de produtos a partir de
especificações de alto nível. Ela motiva a separação do espaço de problema e do espaço de
solução.
GenArch adota três modelos para a representação das variabilidades e elementos de
implementação de uma LPS: (i) modelo de arquitetura; (ii) modelo de características; e
(iii) modelo de configuração (CIRILO, 2008). O modelo de arquitetura define uma
aspectos, templates, pastas e outros arquivos) com o objetivo de facilitar o mapeamento
entre os elementos de arquitetura (espaço de solução) e características presentes no
modelo de características (espaço de problema). Esse modelo pode ser automaticamente
criado a partir da leitura de diretórios existentes, indicados pelo engenheiro de domínio, e
que contém os elementos de implementação da arquitetura da LPS. Durante esse processo
de importação, cada pacote Java é convertido para um componente, com o mesmo nome,
no modelo de implementação. Já os outros tipos de elementos de implementação (classes,
interfaces, aspectos, templates ou arquivos) possuem uma representação correspondente
no modelo de arquitetura.
O modelo de característica (KANG et al., 1990) é utilizado na abordagem para
representar os pontos de variabilidade presentes na arquitetura da LPS. Uma versão inicial
do modelo de característica pode ser criada a partir das anotações do tip o @Feature
encontradas no código fonte dos elementos de implementação. Cada anotação @Feature
demanda a criação de uma nova característica no modelo de características com seu
respectivo tipo, descrito pelo atributo type. Se a anotação processada possui o atributo
parent, uma característica pai é criada, desde que ela ainda não exista no modelo, para
agregar a nova característica.
Finalmente, o modelo de configuração define um conjunto de mapeamentos entre
elementos do modelo de implementação da LPS e características do modelo de
características. Este modelo representa o conhecimento de configuração proposto pela
abordagem generativa (CZARNECKI et al., 2000), sendo fundamental para conectar o
espaço do problema (características) ao espaço da solução (elementos de implementação).
Uma versão inicial do modelo de configuração pode ser criada a partir das anotações
@Feature presentes no código-fonte dos elementos de arquitetura. Para cada anotação @Feature, a ferramenta GenArch adiciona um mapeamento entre as características
anotadas e o respectivo elemento de implementação anotado. A versão atual do modelo de
configuração mostra os mapeamentos em estrutura de árvore, mas com uma indicação
explícita das características que cada um dos elementos depende. Apenas ele mentos que
dependem explicitamente de alguma característica para serem instanciados são
apresentados no modelo de implementação. Todos os outros são considerados mandatórios
A Figura 3 ilustra a relação dos três modelos GenArch. A representação de um
elemento de implementação no modelo de arquitetura (Figura 3a), uma feature alternativa
no modelo de features (Figura 3c), com a ligação via modelo de configuração (Figura 3b).
Os três modelos foram gerados automaticamente a partir de anotações inseridas no código
de uma aplicação.
Figura 3. Modelos GenArch.
A Figura 4 mostra a estrutura geral da arquitetura de implementação da ferramenta
atender as suas funcionalidades: (i) a elaboração de Wizards; (ii) a navegação pela árvore
de diretórios de um projeto e funções para manipulação de arquivos e diretórios; (iii) a
manipulação dos modelos; e (iv) a geração de código. Para manipulação de código-fonte
Java e AspectJ, a ferramenta GenArch utiliza os plugins Java Development Toolkit (JDT)
(ECLIPSE FOUNDATION, 2012) e AspectJ Development Toolkit (AJDT) (COLYER,
2004), respectivamente. Tais plugins fornecem um conjunto de ferramentas para
gerenciamento da área de trabalho, visões, editores, compiladores e manipuladores de
código. A Application Program Interface (API) de árvore de sintaxe abstrata (AST)
disponível nesses plugins foi utilizada na manipulação (leitura, escrita e remoção) das
anotações GenArch e na captura da estrutura de cada elemento de arquitetura como
classes, interfaces ou aspectos. Como foi apresentado anteriormente, é através das
anotações no código que a ferramenta gera uma versão inicial dos modelos de derivação.
A infraestrutura para manipulação dos modelos do GenArch foi implementada
usando os recursos do Eclipse Modeling Framework (EMF) (BUDINSKY et al., 2003). O
modelo de características, em particular, é implementado pelo Feature Modelling Plugin
(FMP). Esse plugin permite a modelagem do modelo de característica proposto por
(CZARNECKI et al., 2000). O plugin openArchitectureWare (HAASE et al., 2007) provê
um conjunto de componentes que podem ser utilizados para leitura e instanciação de
modelos, verificação de regras, transformação entre modelos e geração de código. A
geração de código é realizada a partir do processamento de templates escritos em uma
linguagem própria, denominada XPand (HAASE et al., 2007).
A implementação desta dissertação faz uso do GenArch para a importação de
informações dos modelos de configuração, arquitetura e características gerados. Tal
importação é fundamental para permitir a análise de impacto de mudanças durante a
evolução de uma LPS. A escolha do GenArch se deve principalmente pela
disponibilização do código fonte para propósitos acadêmicos, o que não ocorre com as
ferramentas comerciais como pure::variants e Gears.
2.3
Evolução de Software no contexto de LPS
Tradicionalmente na engenharia de software um sistema de software é
desenvolvido conforme um processo de desenvolvimento de software, que prevê um ciclo
de vida organizado em fases. Apesar de existir vários tipos de processos de
desenvolvimento de software (PRESSMAN, 2006), a maioria deles prevê que haverá uma
fase de evolução do software. Após o sistema ser desenvolvido a partir de um conjunto de
requisitos iniciais, este passará para a fase de evolução, na qual poderão surgir novos
requisitos, aprimoramentos e correções de erros, estas atividades são essenciais para que o
software continue funcionando e atendendo as necessidades dos usuários. Para cada
conjunto de alterações relativo à evolução do software, uma nova versão do software é
lançada. Estudos realizados por (SOUZA, 2005) e (HSIANG-JUI; BURCH, 1997)
demonstram que o esforço médio estimado para a fase de evolução é elevado,
correspondendo a até 90% do ciclo de vida de um software.
Na abordagem de LPS, seguindo o mesmo preceito válido para a abordagem
tradicional, a evolução de software também faz parte do ciclo de vida das LPSs.
com características específicas de LPS. Por exemplo, na engenharia de LPS existem
atividades relativas à modelagem de características e à configuração de produtos que não
existem em softwares tradicionais, estes artefatos de modelagem também sofrem
modificações durante a evolução de LPS. Também existem particularidades nas
arquiteturas de LPS, que são projetadas tendo em vista determinadas propriedades que
favoreçam a derivação de produtos a partir de um conjunto de componentes, tais como, o
baixo acoplamento entre componentes, pontos de extensão para implementação de
componentes customizados, e outros. Além disso, os projetos de LPS podem utilizar
diversas estratégias para implementar variabilidades como anotações de código, templates,
aspectos e geração de código, aumentando a complexidade das atividades de manutenção
e evolução da linha.
Conforme apresentado por (SVAHNBERG; BOSCH, 1999), a evolução em LPS
pode ser categorizada em:
Evolução de requisitos. Afeta a modelagem do espaço do problema e de acordo com (SVAHNBERG; BOSCH, 1999) pode ser classificada em adição, remoção ou
modificação de requisitos. Podendo ocorrer em três níveis: (i) produto específico – a
modificação foca apenas um produto da LPS; (ii) variabilidade – a modificação de
requisitos ligado a uma característica variável da LPS; (iii) similaridade – as modificações
de requisitos associadas a características comuns da LPS e são válidas para todos os
produtos instanciados. As modificações de requisitos também podem refletir em mudanças
no conhecimento de configuração e no espaço da solução.
Evolução de arquitetura. Mudanças na arquitetura da LPS podem ser motivadas por requisitos não funcionais, pela necessidade de adaptar-se a mudanças em tecnologias
de implementação ou de hardware, e por mudanças nas interfaces de componentes. As
modificações da arquitetura são classificadas em: divisão da arquitetura da LPS, divisão
de componentes, adição de componentes, remoção de componentes, substituição de
componentes e mudanças no relacionamento entre componentes.
Evolução de componentes. A maioria dos requisitos não afeta a arquitetura da LPS, mas tem um grande impacto nos componentes da arquitetura. As modificações de
da implementação do componente, agregar funcionalidade ao componente e desagregar
funcionalidade do componente.
A evolução de LPS é guiada principalmente por mudanças nos requisitos, essas
mudanças de requisitos originam-se de várias fontes distintas, como clientes e usuários
dos produtos, necessidades futuras do mercado e a introdução de novas categorias de
produtos na LPS. Para melhor lidar com a evolução de LPS faz-se necessárias práticas
específicas de implementação com objetivo de facilitar a manutenibilidade de LPS.
Exemplos de tais práticas de implementação são (DHUNGANA et al., 2008): pontos de
extensão, interfaces para componentes, separação entre espaço do problema e espaço da
solução, evitar modificações no núcleo da arquitetura, detectar componentes que
implementam as mesmas funcionalidades, evitar adaptar código com o int uito de
reaproveitá-lo, e por fim, evitar assumir decisões de projeto implícitas no código.
No entanto, apesar de úteis, as práticas de implementação apresentadas são
estratégias para tratar apenas alguns aspectos de caráter específico decorrentes de
mudanças em LPS, e por si só não são suficientes para lidar com os diversos fatores de
complexidade envolvidos na evolução de LPS. Existem abordagens discutidas por
(RIEBISCH, 2004) que envolvem análises específicas dos artefatos para lidar com
evolução de LPS, tais como, rastreamento em LPS discutida na Seção 2.3.1, e análise de
impacto de mudanças para LPS apresentada na Seção 2.3.2.
2.3.1
Rastreamento em Linhas de Produto de Software
Com os avanços na área de engenharia de LPS, fomentados principalmente pelo
desafio contínuo de reduzir custos e tempo de desenvolvimento de software, é
imprescindível um suporte voltado à engenharia de LPS com técnicas e ferramentas de
desenvolvimento específicas para apoio aos processos de desenvolvimento de LPS
(ANQUETIL et al., 2008). Um tipo de técnica útil de suporte ao desenvolvimento de LPS
é o uso de técnicas de análise de rastreabilidade orientadas a artefatos de LPS.
O desenvolvimento de software demanda a produção de artefatos de especificação,
documentação e codificação em todos os níveis, tais como: requisitos, arquitetura, projeto,
implementação, testes e integração. Porém, para manter esses documentos consistentes ao
técnicas e ferramentas com tal propósito. Com o objetivo de simplificar a atualização de
documentos, é necessário uma explícita descrição da relação entre esses documentos e os
artefatos de implementação. Essas informações podem ser agregadas a modelos de
rastreabilidades como apresentado por (GOTEL; FINKELSTEIN, 1994).
A rastreabilidade consiste na análise dos relacionamentos entre artefatos gerados
durante o processo de desenvolvimento de software e na atribuição de um significado para
estes relacionamentos, vinculando também os stakeholders. Os resultados da análise de
rastreabilidade permitem um melhor entendimento da complexidade dos relacionamentos
e dependências existentes entre artefatos gerados durante o desenvolvimento. O uso de
técnicas de rastreabilidade vem sendo empregado com sucesso no suporte ao
desenvolvimento de software baseado em processos tradicionais, apresentando benefícios
para gerência de evolução (CLELAND-HUANG et al., 2007).
No domínio de LPS, a rastreabilidade é reconhecida em muitos estudos co mo de
grande relevância (AJILA; KABA, et al., 2004). Uma das principais motivações para
empregar técnicas de rastreabilidade em LPS é o desafio de gerenciar e relacionar os
artefatos gerados em diferentes níveis de abstração (engenharia de domínio e aplicação)
durante o desenvolvimento de LPSs, provendo um melhor entendimento dos artefatos e
suas respectivas variabilidades por parte dos stakeholders.
As grandes dificuldades associadas à rastreabilidade no âmbito de LPS são
(JIRAPANTHONG; ZISMAN, 2005): (i) a existência de um grande número e uma grande
variedade de artefatos se compararmos ao desenvolvimento de software tradicional; (ii)
outra preocupação é ter consciência dos impactos de uma variabilidade em diferentes fases
do desenvolvimento; (iii) estabelecer uma relação entres produtos membros da LPS e a
arquitetura, ou o relacionamento entre os produtos; e (iv) ainda não há um bom suporte à
gerência de requisitos e ao tratamento de seus relacionamentos com características.
Para gerar resultados relevantes para o contexto de LPS, a análise de
rastreabilidade deve ser implementada com as seguintes características ( BAYER;
WIDEN, 2001): (i) basear-se na semântica dos modelos utilizados para especificar e
modelar a LPS; (ii) deve ser customizada para capturar os tipos de ligações relevantes;
(iii) deve ser capaz de lidar com variabilidades; e (iv) ser automática é imprescindível
A identificação e aquisição de ligações e informações de rastreabilidade podem ser
obtidas por diferentes meios, variando com base no nível de automação oferecido pelas
ferramentas de rastreabilidade (SPANOUDAKIS; ZISMAN, 2005). Esses níveis podem
ser: (i) manual – apesar da identificação das relações ser realizada manualmente por um
stakeholder, pode ser apoiada por ferramentas de visualização de artefatos; (ii)
semi-automática – as relações podem ser obtidas com base em ligações pré-definidas pelos
stakeholders ou com bases em ligações estabelecidas pelo processo de software; e (iii)
automática – baseia-se em técnicas de recuperação de informação (ANTONIOL et al.,
2002) (HAYES et al., 2003), regras de rastreabilidade (SPANOUDAKIS; ZISMAN,
2005), e inferência de axiomas (PINHEIRO, 2000). Apesar dos métodos automáticos de
extração, nem todas as relações podem ser inferidas automaticamente, sendo necessário
que o engenheiro de domínio e de aplicação realize uma análise e indique explicitamente
quais as ligações entre os artefatos e qual o tipo de relacionamento (BERG et al., 2005).
O uso de técnicas de rastreabilidade para o suporte a evolução de LPS pode afetar
positivamente a qualidade dos produtos gerados pela LPS. As informações sobre
dependências e restrições providas pelas ligações de rastreabilidade podem ser aplicadas a
um largo escopo de atividades relacionadas à evolução de LPS. As dependências são
informações chaves para entender os impactos de evoluções em LPS, permitindo ao
engenheiro de LPS elaborar soluções estratégicas para problemas decorrentes da evolução.
A rastreabilidade também permite a identificação dos pontos de variação para
aprimoramentos ou modificações da LPS. Em atividades de mudanças e refatoração da
LPS, as informações de dependências podem ser úteis para estimar previamente o esfo rço
de realização de tarefas planejadas, informando quais são os artefatos que potencialmente
serão afetados após alterações específicas em similaridades ou variabilidades da LPS.
2.3.2
Análise de Impacto de Mudanças
A idéia principal da análise de impacto de mudanças é a identificação de quais
serão as consequências decorrentes de mudanças na implementação. Ignorar ou estimar
erroneamente os impactos decorrentes de mudanças pode ocasionar a baixa qualidade do
software resultante após a fase de desenvolvimento, e o alto custo associado à fase de
manutenção, na qual as mudanças são requisitadas e realizadas. A informação fornecida
pela análise de impacto pode ser usada para planejar e realizar mudanças, adaptar e
os potenciais efeitos da mudança fiquem visíveis antes da sua realização, a análise de
impacto de mudanças pode auxiliar a planejar mudanças, estimar os custos de
implementação de mudanças e também validar o software alterado.
A análise de impacto de mudanças pode ser classificada em dois tipos de
abordagens: análise estática ou análise dinâmica. Também é possível realizar uma análise
hibrida como a descrita por (ERNST, 2003), que combina técnicas das duas abordagens
em busca de resultados mais precisos.
Análise Estática: a abordagem baseia-se em analisar estaticamente os artefatos sujeitos a mudanças, essas análises verificam a organização estrutural dos artefatos
identificando as dependências entre eles (BINKLEY, 2007). Geralmente esse tipo de
análise é realizada sobre os artefatos de código com ferramentas específicas para análise
estática de código, mas também pode ser realizada sobre outros tipos de artefatos como
modelos ou documentos de projeto gerados pelos processos de software.
Análise dinâmica: as dependências entre as entidades de código também podem ser criadas dinamicamente em tempo de execução, dessa forma a análise estática de
código não é capaz de identificar essas dependências. A abordagem dinâmica realiz a a
análise durante a execução assistida do sistema, extraindo ligações criadas em tempo de
execução.
No contexto de LPS, realizar mudanças demanda considerar um número maior de
restrições em diferentes níveis de abstração. O principal diferencial em análise de impacto
de mudanças focalizada em LPS é a incorporação de artefatos de modelagem de
características e conhecimento de configuração entre os artefatos sujeitos a mudanças e
impactos (AJILA, 2002). Além disso, a análise de impacto deve considerar o elevado
nível de complexidade das restrições entre características com os artefatos que as
implementam.
A análise de impacto de mudanças é um dos temas chave da fundamentação deste
trabalho. Nossa abordagem propõe o suporte ferramental para análise de impacto de
mudanças automática em LPS, adotando a abordagem estática de análise de impacto de
2.4
Análise Estática de Código
Devido à complexidade e as inúmeras variáveis envolvidas na tarefa de
programação, principalmente em grandes sistemas de software, é inevitável a existências
de erros ou anomalias gerados na codificação. A análise estática de código visa facilitar a
detecção dos problemas decorrentes da codificação dos sistemas de software. Além disso,
pode ser utilizada de forma preventiva, obtendo análises da estrutura do código fonte,
sobre o qual engenheiros de software podem tomar decisões para futuras implementações.
Existem diversas técnicas de análise estática de código:
Análise de Fluxo de Controle: análise dos pontos de decisão lógica do sistema, retornando informações sobre fluxo de controle do sistema;
Análise de Fluxo de Dados: testa os possíveis caminhos ou fluxos de execução, partindo da definição de uma variável até onde ela possivelmente será utilizada, formando
um par que é chamado de definição-uso (definition-use). Neste método, conjuntos de teste
são gerados para se conseguir 100% de cobertura, para cada par;
Compilação e Padronização de Código: verifica se o código obedece a normas de codificação, que abrangem tanto aspectos arquiteturais quanto estruturas de programação,
permitindo que o software seja mais manutenível e testável;
Geração de Métricas sobre o Código: durante a análise estática podem ser geradas métricas de código que irão contribuir para um maior nível de manutenibilidade e
confiança no código. Exemplos de tais métricas são: complexidade ciclomática, tamanho,
número de chamadas a funções, dentre outras;
Análise Estática de Arquitetura: são análises feitas no código para verificar sua estrutura, como por exemplo: como os módulos e as classes se comunicam, tipos de
retorno, parâmetros, chamadas indevidas, etc.
Um tipo muito comum de análise estática é a inspeção manual de código, na qual
um stakeholder verifica manualmente o código fonte procurando por possíveis problemas
de implementação. Essa abordagem de análise é muito trabalhosa e normalmente é
ferramentas não são capazes de analisar algum aspecto desejado. A inspeção manual de
código também é incluída em alguns processos (OpenUP, 2011) como uma atividade em
que o programador realiza antes de enviar o código para a etapa de testes, e dessa forma
detecta falhas previamente diminuindo a sobrecarga de atividades de testes.
Também existem abordagens automáticas para análise de código. Elas são baseadas
em ferramentas que acessam os artefatos de implementação e realizam uma análise da
estrutura do código. Essas ferramentas de análise são projetadas com o propósito de
analisar algumas características específicas do código. Ainda há frameworks de análise
estática de código que permitem aos usuários construir análises de código, embora os
frameworks também focalizem contextos específicos, eles permitem aos usuários construir
análises customizadas. Algumas ferramentas destacadas:
FindBugs: é um detector de padrões de erros para Java (COLE et. al., 2006). Utiliza uma série de heurísticas projetadas para balancear a precisão e eficiência da
análise. Uma das principais técnicas utilizadas pelo FindBugs é a comparação da sintaxe
do código com padrões de sintaxe identificados como más práticas de programação. Pode
ser estendido utilizando Java para a construção de análises customizadas.
PMD: realiza análise com base na verificação da sintaxe do código, mas não analisa o fluxo de dados do programa (COPELAND, 2005). O PMD focaliza em
verificações de convenções de boas práticas de codificação, por exemplo, indica um bloco
de código catch vazio como erro. O PMD pode ser facilmente estendido por
programadores, que podem escrever novos padrões de erros utilizando Java ou XPath.
Soot Framework: é um framework para otimização e análise de código baseado na sintaxe do código (VALL´EE-RAI et. al., 1999). O Soot provê quatro representações
intermediárias do bytecode Java que podem ser adotadas de acordo com os aspectos que
se deseja analisar. O Soot disponibiliza pontos de extensão que permitem aos usuários
criar análises especializadas.
Checkstyle: analisa o código fonte Java em busca de violações de convenções de codificação com o objetivo de melhorar a legibilidade do código (BURN, 2011). O
classes e o tamanho excessivo de métodos. O Checksyle provê uma interface para os
usuários escreverem as próprias regras de verificação.
A importância de análise estática de código para a abordagem proposta neste
trabalho é o suporte a extração de dependências de baixo nível de artefatos que
implementam a LPS, ou seja, do espaço da solução. A idéia é utilizar uma ferramenta de
análise estática de código para obter informações sobre a organização estrutural do
código, e dessa forma estabelecer os relacionamentos de dependência que são
imprescindíveis para a análise de impacto de mudanças em LPS.
Nesta seção apresentamos algumas ferramentas de análise de código, no entanto,
para a implementação proposta neste trabalho adotou-se a ferramenta Design Wizard que
é descrita em detalhes a seguir.
2.4.1
Design Wizard
A Design Wizard (BRUNET; GUERRERO; FIGUEIREDO, 2009) é uma API de
inspeção automática de software, na qual as informações são extraídas de artefatos de
programas Java com extensão jar ou class. Design Wizard provê uma série de métodos
que verificam a existência de determinadas propriedades estrut urais do código, tais como:
a chamada de métodos, o acesso aos atributos de classe, acessos a classes, acesso a
pacotes, entre outros. Com esses métodos providos pela API é simples checar
dependências entre componentes de código Java. A Design Wizard apóia a verificação de
conformidade arquitetural de softwares, para que estes se tornem mais confiáveis.
Também auxilia o acompanhamento do desenvolvimento de software, checando
propriedades que devem ser mantidas para que não haja diferença entre a arquitetura
inicial proposta e a implementação. A Design Wizard também pode ser utilizada para
controlar a manutenção e a evolução do software, através da verificação de conformidade
da arquitetura com a implementação.
No contexto desta dissertação, a Design Wizard será utilizada para extrair
informações sobre dependências, chamadas e acesso de componentes (classes, interfaces)
presentes no código de LPS implementadas na linguagem Java. Estes dados
complementarão as informações de dependências entre artefatos do Squid Analyser
