SQUID IMPACT ANALYSER: UMA FERRAMENTA PARA ANÁLISE … · de métricas de cobertura, precisão e...

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

NATAL - RN

Maio, 2012

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

NATAL - RN

Maio, 2012

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. RN/UF/BSE-CCET CDU 004.041

v

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

financiamento deste trabalho tornando-o viável.

vi

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.

Palavras-chave: Linha de Produto de Software; Análise de Impacto de Mudanças;

Evolução de Linhas de Produto de Software; Engenharia de Software Automatizada.

vii

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.

Keywords: Software Product Lines; Change Impact Analysis; Software Product

Lines Evolution; Automated Software Engineering.

viii

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.3 Extração de Artefatos da LPS ....................................................... 34

ix

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 Experimento 2........................................................................................... 81

x

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

ANEXO I ................................................................................................................ 109

xi

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


xii


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


xiii





xiv

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 Sementes (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

Tabela 15. Métricas precisão e cobertura da estratégia não orientada a análise de

dependência de código. ............................................................................................. 86

xv

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

VSoC Virtual Separation of Concerns

1

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

sujeitos a sofrerem impacto durante mudanças, tais como: (i) modelagem e implementação

2

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

análise de impacto de mudança ainda mais difícil e complexa.

3

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

análise de impacto de mudanças através da avaliação de mudanças que ocorrem na LPS

4

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

implementação, mapeamentos de características com artefatos de implementação e

5

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

informações de relacionamento entre eles.

6

(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

desdobramentos de trabalhos futuros.

7

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.,

2005), tais como:

8

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

realizadas na LPS estejam de acordo com o planejamento definido.

9

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

permitam a geração automática de software através de especificações em alto nível como

10

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

um determinado produto.

11

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 comunidade

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

representação visual dos elementos de implementação da LPS (componentes, classes,

12

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 tipo @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 elementos 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

e farão parte de qualquer instância do produto da LPS.

13

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

GenArch. O GenArch adota quatro plug-ins extensíveis da plataforma Eclipse de forma a

14

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.

Figura 4. Arquitetura da ferramenta GenArch.

15

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.

Entretanto, no caso de LPS há cenários de evolução mais complexos, onde é preciso lidar

16

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

componentes são classificadas em: nova implementação para o componente, modificação

17

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 intuito 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

longo do ciclo de vida e iterações de desenvolvimento, é fundamental a disponibilidade de

18

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 como 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

dada a escala de variabilidades e produtos distintos que o engenheiro deve lidar.

19

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

configurar o software para as mudanças e localizar os seus efeitos. Além de permitir que

20

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 realiza 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

mudanças.

21

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 é

realizada quando não há ferramentas para a linguagem de programação alvo ou quando as

22

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

Checkstyle também identifica outros problemas como o alto nível de acoplamento entre

23

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 estruturais 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

Model. A Design Wizard é a ferramenta de análise estática de código escolhida para

24

implementação deste trabalho, principalmente por permitir a extração da relação de

dependências de atributos, métodos, classes e pacotes, diferenciando os tipos de

relacionamentos. Outro fator é a compatibilidade da extensão com o nosso projeto, que é

implementado em Java. A adoção da Design Wizard apenas requer incluir a biblioteca em

um projeto Java e iniciar a análise passando como argumento o caminho do projeto a ser

analisado. Enfim, a Design Wizard atende as necessidades de análise de código

requisitadas para este trabalho, apresenta uma interface de interação objetiva, e é uma

ferramenta gratuita de código-fonte aberto.

2.5 Sumário

Este capítulo apresentou os conceitos fundamentais abordados ao longo da

dissertação. Vimos que linhas de produto de software são famílias de sistemas de um

mesmo domínio que compartilham características comuns e variáveis, a abordagem de LPS

se diferencia do processo de desenvolvimento tradicional de software ao direcionar o foco do

desenvolvimento de sistemas específicos para o desenvolvimento de família de sistemas.

Nesse sentido foram apresentadas técnicas de gerências de variabilidades e algumas

ferramentas para esse contexto, tais como, GenArch, Gears e pure::variants. Em especial,

o GenArch foi apresentado com mais ênfase por ser adotada para o desenvolvimento desse

trabalho.

Outro assunto abordado foi o de evolução de software no contexto de LPS, que

apresenta algumas diferenças em relação à evolução de software no contexto de

desenvolvimento tradicional de sofware. Também foram apresentadas algumas técnicas

conhecidas que auxiliam os engenheiros de LPS a lidar com a evolução, tais como, análise

estática de código e rastreabilidade de características em LPS. No âmbito de análise

estática de código foi apresentada a ferramenta Design Wizard, uma API para análise de

código Java.

25

3 Squid Analyser: Uma Infraestrutura Extensível de

Análise de Linhas de Produto de Software

Este capítulo apresenta o Squid Analyser, uma infraestrutura extensível para

análise de propriedades de implementações de LPS, uma das contribuições desta

dissertação. A Seção 3.1 apresenta uma visão geral da arquitetura da infraestrutura e seu

funcionamento. A Seção 3.2 descreve o projeto detalhado da infraestrutura apresentando

os componentes de software que a constituem. Por fim, a Seção 3.3 apresenta exemplos de

uso da infraestrutura e como pode ser instanciada para diferentes cenários.

3.1 Arquitetura Geral da Infraestrutura

A arquitetura da infraestrutura Squid Analyser está organizada em três

componentes principais: (i) o componente de extração de artefatos da LPS; (ii) o

componente de extração de dependências entre artefatos da LPS; e (iii) o componente da

análise de propriedades da LPS propriamente dita. A análise de propriedades da LPS pode

envolver a implementação de buscas sobre um modelo que armazena as informações

extraídas, denominado Squid Analyser Model (Seção 3.2.2), bem como visualizações

específicas para os resultados de tais buscas.

A Figura 5 apresenta a estrutura lógica da arquitetura com os componentes

utilizados na infraestrutura. As caixas em cor amarela representam os componentes

internos do Squid, enquanto as caixas de cor azul representam os componentes externos

utilizados pelo Squid. E as caixas de cor verde representam os componentes flexíveis

utilizados pelo Squid, ou seja, podem ser substituídos por outros componentes de acordo

com a instanciação realizada.

26

Figura 5. Visão Geral da Infraestrutura.

A Figura 6 apresenta um diagrama de componentes que explicita os

relacionamentos entre os componentes da arquitetura. O componente Extrator de Artefatos

da LPS realiza o processo de extração de informações relacionadas aos artefatos da LPS,

bem como quais desses artefatos estão relacionados a similaridades e variabilidades. Em

particular, neste trabalho foi realizada uma instanciação na qual os modelos EMF gerados

pela ferramenta de derivação GenArch provêm as informações para a extração de

variabilidades da LPS. O GenArch representa a LPS em três modelos: Modelo de

Característica, Modelo de Configuração e Modelo de Arquitetura. Estes modelos foram

descritos em detalhes na Seção 2.2.1. Para esta etapa utiliza-se a API fornecida pelo EMF

para manipular, tanto os modelos do GenArch, quanto o Squid Analyser Model, e dessa

forma os dados da LPS são extraídos para o Squid Analyser Model. Este processo é

detalhado na Seção 3.2.3.

27

Figura 6. Diagrama de Componentes da Infraestrutura.

Em seguida, o componente Analisador de Dependências de Código complementa

as informações relacionadas a variabilidades providas pelo processo anterior, agregando

ao Squid Analyser Model os relacionamentos de dependência entre artefatos de código.

Neste trabalho foram desenvolvidas duas instâncias deste componente baseadas em duas

ferramentas de análise estática de código, uma utilizando a API Design Wizard

(BRUNET; GUERRERO; FIGUEIREDO, 2009), e a outra utilizou a API de manipulação

de árvore sintaxe abstrata oferecida pelo Java Development Tooling (JDT) da plataforma

Eclipse. Apesar de haver duas versões do componente Analisador de Dependência de

Código, apenas uma deve ser selecionada durante a implementação de uma dada

ferramenta na infraestrutura. A motivação para desenvolver duas instâncias é apresentada

na Seção 3.2.4, assim como os detalhes de implementação de ambas.

28

Após a conclusão das etapas anteriores, o Squid Analyser Model contém

informações suficientes para que o componente de Análise de propriedades da LPS possa

processá-las e obter informações relevantes para apoiar o desenvolvimento e evolução da

implementação da LPS, através da implementação de buscas e visualizações específicas.

A Seção 3.2.5 descreve em detalhes o processo de análise através da realização de buscas

e Seção 3.2.6 o desenvolvimento de visualizações de análises da LPS.

3.2 Projeto Detalhado

Esta seção detalha a implementação da infraestrutura de análise de propriedades da

LPS. A Seção 3.2.1 apresenta o núcleo da arquitetura do Squid, detalhando suas classes e

funcionamento. A Seção 3.2.2 apresenta a definição do modelo e análise do Squid adotado

para armazenar as informações de LPS. A Seção 3.2.3 apresenta a etapa de extração de

artefatos da LPS e um exemplo de sua instanciação, em seguida etapa de análise de

dependências de código é descrita na Seção 3.2.4. A Seção 3.2.5 descreve e exemplifica a

implementação de buscas sobre o Squid Analyser Model, finalmente, as visualizações de

análises são descritas na Seção 3.2.6.

3.2.1 Módulo Núcleo do Squid

A implementação do Squid focaliza uma solução flexível, onde a infraestrutura de

software permite aos usuários desenvolver seus próprios extratores, analisadores de

código, buscas e visualizadores com o objetivo de atender o contexto de aplicação

desejado pelos usuários. Esta implementação também comporta a reutilização de módulos

previamente desenvolvidos por outros usuários, permitindo assim a instanciação da

ferramenta apenas com o reuso de módulos.

A implementação flexível é baseada em pontos de extensões disponibilizados pelas

classes que implementam o núcleo do Squid. A Figura 7 apresenta um diagrama de classes

contendo as classes que compõe o núcleo da infraestrutura, e também as interfaces que

descrevem os pontos de extensão fornecidos. A classe fachada SquidAnalyserFacade é

um ponto fixo da infraestrutura e mantém referências para objetos dos tipos definidos

pelas interfaces Extractor, SourceCodeAnalyser, Query e Visualizer. Cada

interface especifica um ponto flexível, com os métodos que o usuário deve implementar

para que o Squid possa utilizá-lo, tais como, runExtractor(), runCodeAnalyser(),

29

runQuery() e runVisualizer() que são os métodos de execução invocados pela

classe fachada. A interface Extractor especifica um ponto de extensão para a etapa de

extração de informações dos artefatos da LPS, como artefatos de implementação da LPS,

bem como variabilidades e similaridades da LPS, e respectivo conhecimento de

configuração. O ponto de extensão para a etapa de análise de dependência de código é

descrito pela interface SourceCodeAnalyser, a instância dessa interface deve analisar o

código fonte da LPS para obter informações de dependências entre os artefatos de

implementação. A interface Query descreve um ponto de extensão para o

desenvolvimento de buscas sobre o Squid Analyser Model, em outras palavras, onde o

usuário pode desenvolver as análises específicas sobre as informações de LPS.

Finalmente, a interface Visualizer é um ponto de extensão para a construção de

visualizadores sobre os resultados obtidos pelas buscas.

Figura 7. Diagrama de classes da infraestrutura.

A Figura 8 apresenta um diagrama de interação ilustrando o funcionamento interno

do Squid, onde é explicitada a seqüência de chamadas entre as classes durante o uso da

30

ferramenta. O usuário deve fornecer as instâncias das interfaces requeridas pela classe

SquidAnalyserFacade, e implementar os métodos de execução (run) que serão

invocados pela classe fachada durante o seu funcionamento. O fluxo de execução é

iniciado com a instanciação da classe fachada onde são passados como argumentos as

instâncias das interfaces Extractor e SoucerCodeAnalyser, também é passada uma

referência para o projeto da LPS a ser analisada. Durante a etapa 2, a classe fachada

executa o extrator invocando o método runExtractor(:IProject), que deverá

retornar uma instância do Squid Analyser Model com as informações básicas da LPS

como: características, conhecimento de configuração e artefatos de implementação. Em

seguida, o analisador de código é executado na etapa 3 da seqüência, através da invocação

do método runCodeAnalyser(:Object, :AnalysisModel), que retorna o Squid

Analyser Model já contendo as dependências entre os artefatos de código. Após realizar a

análise de código, o Squid Analyser Model possui informações relevantes relacionados à

gerência de variabilidades e dependências de artefatos de código que permita realizar

buscas e análises de propriedades da LPS. Dada a sua importância, o modelo é persistido

para ser reutilizado em diferentes buscas de análise.

Figura 8. Diagrama de interação da infraestrutura.

A etapa 4 inicia com a solicitação de execução de uma busca através do método

executeQuery() fornecido pela classe fachada, o método recebe como parâmetro uma

implementação da interface Query e uma implementação da interface Visualizer. Na

31

etapa 5, a classe fachada executa a busca passada como parâmetro invocando o método

runQuery() que recebe o Squid Analyser Model como parâmetro. A busca deve retornar

um objeto do tipo Object contendo uma estrutura de dados para armazenar o resultado da

busca, este objeto é o queryModel. O queryModel é definido pelo próprio desenvolver

da busca de acordo com as funcionalidades de análise de propriedades da LPS que se

deseja . Por fim, a etapa 6 é a visualização da busca, na qual a classe fachada invoca o

método runVisualizer() passando como parâmetro o resultado da busca armazenado

no queryModel. A função do Visualizer é gerar uma visualização conveniente de

propriedades da própria LPS, de forma a facilitar o seu desenvolvimento e evolução da

LPS. Vale ressaltar que a etapa 4 da sequência pode ser executada mais de uma vez,

realizando várias buscas sobre o mesmo Squid Analyser Model gerado nas etapas

anteriores.

3.2.2 Squid Analyser Model

O Squid Analyser Model (SAM) é um modelo projetado para o propósito de

armazenar as informações úteis para análise em LPS e é adotado pela infraestrutura Squid

Analyser para esse finalidade. O SAM é preenchido com as informações obtidas na etapa

de extração (Seção 3.2.3), o qual será posteriormente utilizado para realizar as buscas de

análise sobre LPS exemplificadas na Seção 3.2.5. Este modelo é organizado seguindo a

estrutura geral de um modelo generativo para LPS, tornando explícita a separação entre

espaço de problema, espaço de solução e conhecimento de configuração. A Figura 9

ilustra a organização das principais abstrações presentes no SAM bem como o

relacionamento entre as mesmas.

As entidades presentes no SAM são abstrações que representam quatro tipos de

informação associadas à modelagem de LPS, sendo elas: (i) características (Feature); (ii)

artefatos de implementação (Asset); (iii) mapeamento (Mapping); e (iv) casos de uso

(UseCase). As informações de características são relativas ao espaço do problema e

modelam as similaridades e variabilidades de uma LPS. Cada característica é expressa por

nome (name) e tipo (type) – opcional, obrigatória e alternativa – e por associações de

agrupamento (groups) e de restrição (constraints) entre características. No espaço do

problema também há a entidade casos de uso (UseCase) que identifica um caso de uso

que pode ser associado a um artefato de implementação por meio de anotações de código.

32

Figura 9. Squid Analyser Model.

A entidade mapeamento (Mapping) representa o conhecimento de configuração,

responsável por associar abstrações presentes no espaço do problema com abstrações

presentes no espaço da solução. Dessa forma, o mapeamento é importante para obter

rastreabilidade dos elementos que compõem a LPS auxiliando na implementação de

análises relacionadas aos seus artefatos de realização. O mapeamento é descrito por uma

expressão booleana de características (featureExpression), que indica quais são as

características que participam do mapeamento com o artefato. Essa expressão é avaliada

por ferramentas de derivação, e de acordo com a configuração de características do

produto. A avaliação da expressão retorna o valor true se o artefato do mapeamento deve

ser incluso no produto, caso contrário a avaliação retorna o valor false.

A entidade artefato (Asset) está associada ao espaço do problema e representa

todos os artefatos que são utilizados para implementar os diferentes produtos da LPS. Um

artefato é denotado por nome (name), tipo (type) e caminho (path). Esta entidade pode

ser reusada para representar diferentes tipos de artefatos que modelam ou implementam as

características de uma LPS, tais como, pacotes, classes, métodos, atributos, bibliotecas,

arquivos de configuração, arquivos binários, documentação, etc.

33

O SAM foi elaborado com a finalidade de ser o mais universal possível, podendo

ser especializado para contemplar diferentes tipos de implementações de LPSs. Neste

trabalho foi realizada uma extensão do SAM para melhor atender aspectos de projetos

desenvolvidos no paradigma de orientação a objetos com a linguagem de programação

Java, e assim obter análises focadas neste tipo de estrutura. A Figura 10 apresenta um

diagrama de classes da extensão do SAM.

Figura 10. Extensão do Squid Analyser Model.

O exemplo de extensão do SAM apresentado (Figura 10) foi projetado para

implementações de LPS em linguagens orientadas a objetos, onde um artefato (Asset)

pode ser especializado em classe (Class), método (Method), atributo (Field) ou

fragmento de código (CodePiece), e as dependências continuam sendo expressas pelo

relacionamento de dependências (depends) de artefato (Asset). Por exemplo, os

34

relacionamentos de dependência de uma classe são as classes abstratas implementadas e

interfaces realizadas. As dependências de um atributo são o tipo de classe declarada,

métodos invocados na inicialização e classe na qual foi declarado. Já as dependências de

um método são expressas pelos métodos invocados, atributos acessados, classe na qual foi

declarado e classes utilizadas. Por fim, um fragmento de código pode possuir

dependências com métodos invocados, atributos acessados, método ao qual foi associado e

classes utilizadas.

3.2.3 Extração de Artefatos da LPS

A extração de artefatos da LPS consiste em obter informações relacionadas aos

diferentes tipos de artefatos que modelam e implementam a LPS, bem como quais desses

elementos representam similaridades ou variabilidades. Tais informações são usadas

posteriormente para a implementação de análises de propriedades de uma LPS. Elas

podem ser obtidas a partir de artefatos que modelam e implementam a LPS, tais como,

modelos, artefatos de implementação, anotações de código e documentação existente.

Conforme explicitado anteriormente (Figura 7), a etapa de extração é um ponto flexível da

infraestrutura que permite a instanciação de extratores específicos para importar diferentes

tipos de informação dos artefatos de modelagem e implementação da LPS. Assim, o

módulo de extração pode ser estendido com a incorporação de componentes de extração

customizados, permitindo assim melhor adequar-se aos diversos tipos de informações.

O componente de extração de artefatos é responsável pela obtenção das seguintes

informações: (i) Extração de Variabilidades: modelagem das características, incluindo os

relacionamentos de restrição entre elas; (ii) Extração de Artefatos de Implementação:

abstrações do espaço de solução, que são os artefatos de implementação da LPS; e (iii)

Extração de Conhecimento de Configuração: abstrações de conhecimento de configuração

que determinam mapeamentos de abstrações pertencentes ao espaço de problema e

solução, tais como, anotações em código (ou diretivas de compilação condicional)

indicando mapeamento de um dado artefato ou trecho de seu código com uma dada

característica obrigatória ou variável da LPS. Ao final, as informações extraídas são

armazenadas dentro do SAM (Seção 3.2.2), no caso dos artefatos de implementação ainda

haverá a etapa de análise dependências de código (Seção 3.2.4) que busca obter

informações detalhadas sobre diferentes tipos de dependência existentes entre artefatos de

código.

35

A instanciação desse ponto de extensão representando a extração de artefatos da

LPS depende da fonte de origem das informações da LPS. Essas informações podem ser

extraídas de artefatos gerados por ferramentas de gerência de variabilidades e derivação

automática de produtos, tais como, GenArch, CIDE e pure::variants. As ferramentas

citadas realizam a modelagem de variabilidades podendo, portanto, serem reutilizadas

para alimentar o SAM, para isso, basta processar e importar as informações mantidas por

elas para o SAM implementando um extrator específico.

Um exemplo de instanciação do módulo de extração de artefatos foi implementado

nesta dissertação, com o objetivo de obter a modelagem de dados gerada pela ferramenta

de derivação GenArch. Conforme descrito na Seção 2.2.1, o GenArch armazena as

informações de LPS em três modelos EMF: (i) modelo de características: variabilidades

da LPS e seus relacionamentos; (ii) modelo de configuração: conhecimento de

configuração; e (iii) modelo de arquitetura: artefatos de implementação. Nossa

instanciação utilizou a plataforma de manipulação de modelos fornecida pelo EMF para

ler as informações presentes nos modelos gerados pelo GenArch e, posteriormente,

armazená-las no modelo e configuração. Graças à modelagem do GenArch e do Squid

serem baseadas na abordagem generativa para LPS, a correlação entre as entidades

presentes no SAM e as entidades presentes no modelos do GenArch pode ser facilmente

obtida.

A Figura 11 ilustra em vermelho a correspondência das características Music e

PhotoAlbum presentes no Feature Model do GenArch para o Analysis Model mantido

pelo Squid. Pode ainda ser visto em verde, a correspondência do artefato de

implementação método setMainMenu() do ArchitectureModel (GenArch) com o Analysis

Model (Squid). Por fim, pode ser visto em azul, o conhecimento de configuração

representado pelo nome do artefato “setMainMenu(SelectTypeOfMedia)” e a expressão de

características “Music and PhotoAlbum”, observa-se que a entidade Feature Expression do

Configuration Model (GenArch) é sintetizada na entidade Mapping do Analysis Model

(Squid).

36

Figura 11. Transformação GenArch para Squid.

3.2.4 Analisador de Dependência de Código

A análise de dependência de código é realizada após a extração dos artefatos da

LPS para o SAM. Esta etapa tem como objetivo obter as relações de dependência entre os

artefatos que implementam a LPS, tais como, métodos invocados, classes instanciadas,

atributos acessados, classes abstratas implementadas e interfaces realizadas. Tais relações

de dependência são usadas posteriormente para promover a análise de propriedades

específicas sobre a LPS. Este processo é realizado utilizando uma ferramenta de análise

estática de código, que permita extrair as dependências entre artefatos diretamente do

código-fonte de cada componente da arquitetura. Atualmente existem vários frameworks e

ferramentas que permitem extrair informações relacionadas à análise estática de código,

37

tais como, TPTP (MATZEN, 2009), PMD (COPELAND, 2005), Checkstyle (BURN,

2011), Find Bugs (COLE et. al., 2006) e SOOT (VALL´EE-RAI et. al., 1999).

Nossa abordagem permite integrar diferentes ferramentas para análise estática de

código, e nesta dissertação foram desenvolvidas duas instâncias de referência deste

módulo, ambas para análise de LPSs implementadas na linguagem Java. A primeira

instância adotou uma estratégia baseada na análise de bytecode Java, com o uso da API

Design Wizard (BRUNET; GUERRERO; FIGUEIREDO, 2009), que por sua vez foi

desenvolvida usando o framework ASM (BRUNETON, E.; LENGLET, R.; COUPAYE,

2002). Já a segunda instância implementada, seguiu uma abordagem de análise do código

fonte Java usando a árvore sintática abstrata (AST) Java fornecida pelo JDT (ECLIPSE

FOUNDATION, 2012). Detalhes destas implementações são apresentados nas Seções

3.2.4.1 e 3.2.4.2, respectivamente. A diferença essencial entre estas abordagens é que na

abordagem baseada em análise de bytecode Java é possível analisar apenas projetos

sintaticamente corretos e que apresentem o bytecode gerado. No entanto, tratando-se de

LPS nem sempre esse panorama é contemplado, as LPS podem ser constituídas por um

conjunto de artefatos que reunidos em um único projeto geram erros sintáticos, porém ao

derivar produtos, a LPS gera produtos sintaticamente corretos. Outra diferença relevante é

a granularidade da análise, usando a versão atual da Design Wizard não é possível realizar

a análise em fragmentos de código isolados que implementam determinadas variabilidades

da LPS, dessa forma não seria possível obter as dependências destas entidades ou

abstrações. Por outro lado, a implementação baseada na manipulação da AST permite a

análise estática em fragmentos de código fonte.

3.2.4.1 Implementação baseada em bytecode Java

Nesta implementação foi utilizada a API Design Wizard, que realiza uma análise

estrutural do bytecode Java, sobre a qual é possível obter informações de relacionamentos

entre artefatos de implementação, e assim, complementar o SAM com as informações de

dependência entre artefatos de implementação. A Figura 12 apresenta código fonte que

demonstra o uso da API Design Wizard para obter dependências de um método.

38

Figura 12. Código do método extractMethodDependencies.

O código apresentado faz parte da classe ByteCodeAnalyser, que implementa o

ponto de extensão de análise estática de código dentro do Squid. Neste caso, o método

extractMethodDependencies() tem o objetivo de extrair as informações de dependências

de um método de classe. O método aceita dois parâmetros, o primeiro projectLocation é

uma string do caminho do projeto de implementação da LPS, enquanto o segundo

(methodTarget) é uma instância da classe MethodData do SAM, sobre o qual deseja-se

obter as dependências. Na linha 2, cria-se uma instância do analisador de código

(DesignWizard) passando o endereço do projeto onde estão os artefatos de

implementação. Na linha 4, obtêm-se uma instância do método alvo (methodInstance)

indexado pela Design Wizard, o objeto methodInstance possui todas as informações de

dependências resultantes da análise de código, basta acessá-las utilizando os métodos de

acesso disponibilizados. Na linha 6, invoca-se o método getAccessedFields() que retorna

os atributos de classe acessados pelo método alvo. Na linha 7, obtêm-se as dependências

de tipos utilizando o método getCalleeClasses(). Por fim, a linha 8 invoca o método

getCalleeMethods() que retorna todos os métodos invocados pelo método alvo. Todas as

dependências são armazenadas no SAM dentro de uma instância de MethodTarget, a qual

é retornada no final do método.

3.2.4.2 Implementação baseada na Árvore Sintática Abstrata Java

Esta implementação baseia-se na manipulação da AST do plugin JDT do Eclipse.

Tal AST é uma representação estrutural do código fonte de Java na forma de uma

estrutura de dados em árvore, onde cada nó da árvore está associado a uma entidade da

sintaxe de Java. A AST consegue representar a hierarquia e relacionamentos entre os

elementos presentes no código fonte. A Figura 13 mostra uma visualização da AST da

classe AlbumController utilizando o plugin ASTView (ECLIPSE FOUNDATION,

2012) para a plataforma Eclipse. Nesta visualização, podemos observar que a AST provê

39

diversos tipos de nós dos quais podemos extrair informações úteis para análise, tais como,

pacotes (Package), classes importadas (Imports), interfaces utilizadas

(SuperInterfacesTypes), classes estendidas (SuperclassType), declaração de

métodos (MethodDeaclaration), atributos declarados (FieldDeclaration), blocos

de código (Block), nomes simples (SimpleName), comentários Javadoc (Javadoc),

entre outros. Os nós da árvore podem ser expandidos para obter mais detalhes e os nós

filhos na hierarquia.

Figura 13. Visualização da AST Java pelo plugin ASTView.

40

A abordagem de análise estática de código fonte utilizando a AST é composta de

cinco atividades, que estão ilustradas no diagrama de atividades apresentado na Figura 14.

A atividade 1 consiste em selecionar uma classe presente no SAM e, em seguida, a

atividade 2 efetua o parser da classe selecionada. O parser retorna uma instância da AST

contendo todos os nós. A terceira atividade consiste em visitar a instância da árvore e

selecionar apenas os nós de tipos relevantes para a análise de dependências, tais como,

MethodDeaclaration, TypeDeclaration, FieldDeclaration, Javadoc e

SimpleName. Os nós selecionados são armazenados na SquidTree, uma estrutura de

dados do tipo árvore similar a estrutura da AST do JDT. A SquidTree foi projetada para

armazenar apenas os nós de interesse da análise de impacto de mudanças ordenando-os

hierarquicamente. A motivação principal para o uso dessa estrutura é necessidade de

expressar o nó fragmento de código que não é nativo AST do JDT, além de simplificar a

manipulação dessas informações.

Figura 14. Atividades da análise de código utilizando a AST Java.

Em seguida, a atividade 4 tem o objetivo de identificar os fragmentos de código

(CodePiece) contidos em métodos. Os fragmentos de código são envolvidos por

anotações em comentários Javadoc, o início do fragmento de código é demarcado pelo

41

comentário: “/**#Feature(name="[Nome da Feature]", parent="[Nome da

Feature Pai]", type=[Tipo da Feature])*/”, e o fim é demarcado pelo

comentário “/** #endFeature */”. Os nós do tipo Javadoc incluídos na SquidTree

são analisados e os fragmentos identificados, dessa forma, o fragmento é criado e incluído

na árvore substituindo o comentário Javadoc na hierarquia. A Figura 15 apresenta o

código fonte da classe MediaController que faz parte da linha de produtos Mobile

Media [FIGUEIREDO et al, 2008], o método handleCommand(:Command) possui dois

fragmentos, um compreendido entres as linhas 13 e 23, e o outro entre as linhas 17 e 19,

nota-se que o segundo fragmento está aninhado no primeiro fragmento. Ao final da

atividade 4 a SquidTree está completa, ou seja, com todos os nós necessários para análise

de dependências da atividade 5.

Figura 15. Anotações de fragmentos de código.

A atividade 5 analisa a SquidTree identificando as dependências de classes,

métodos, atributos e fragmentos de código, para cada tipo existe uma estratégia diferente.

Para os artefatos do tipo classe, as dependências podem ser classes abstratas estendidas

(SuperclassType) ou interfaces utilizadas (SuperInterfacesTypes). No caso de

dependências de atributos, métodos e fragmentos de código adota-se uma estratégia

baseada na resolução de ligações (resolve bindings), essas ligações analisadas durante o

42

parser do código e posteriormente são associadas aos nós do tipo SimpleName e um

método de acesso a essa informação é provido pela JDT. O nó do tipo SimpleName da

AST da JDT representa um nome genérico que é utilizado como uma referências para uma

entidade qualquer, que pode ser um atributo declarado, uma classe declarada ou um

método declarado. Para melhor explicar os SimpleName, a Figura 16 apresenta o código

fonte da classe NewLabelScreen do Mobile Media, em que os nomes simples estão

sublinhados de vermelho. Por exemplo, na linha 9 o nome simples cancel está ligado ao

atributo cancel declarado na linha 5, e na linha 10 o nome simples addCommand está

ligado ao método addCommand(:Command) declarado na mesma classe (não está

presente na figura). A linha 4 apresenta um caso especial, onde a primeira ocorrência do

nome simples TextField está ligada a classe TextField, porém a segunda ocorrência

está ligada ao método construtor TextField(:String, :String, :int) declarado

na classe TextField. Após a identificação das dependências entre os artefatos na

SquidTree, a atividade final da análise estática de código é exportar os relacionamentos de

dependências para o SAM, associando-os aos respectivos artefatos.

Figura 16. Código fonte com as entidades do tipo nome simples destacadas.

Nossa instanciação utilizou a API JDT fornecida pela plataforma Eclipse para

realizar o parser do código fonte e ter acesso às informações da AST Java. A Figura 17

apresenta parte do código fonte da classe ASTExplorer, que manipula as informações

retornadas pelo parser. No trecho de código apresentado o construtor da classe recebe

como parâmetro uma referência da classe a ser analisada (classCompilationUnit), e

também uma referência do projeto Java de qual a classe faz parte (iJavaProject).

43

Inicialmente, o parser é criado (linha 9) passando como argumento a versão da

especificação da linguagem Java desejada no caso JLS3 (Java Language Specification 3).

Em seguida, o parser é configurado para aceitar como entrada um objeto do tipo

ICompilationUnit (linha 10), e a classe a ser analisada é passada para o parser (linha

11). Na linha 12, o parser é configurado para resolver as ligações entre os nós da árvore, e

na linha 13 o projeto Java é passado como parâmetro, para que o parser consiga resolver

ligações com entidades externas à classe a ser analisada. O parser é então executado

(linha 15) e retorna o nó raiz da AST gerada, este nó é armazenado na variável node. Em

seguida, instancia-se o visitor ASTSquidVisitor (linha 17), ao ser executado (linha 18)

o visitor seleciona o nós relevantes para análise e os inclui em uma instância da

SquidTree. Ao final, a instância da SquidTree é armazenada em um atributo da classe

(linha 10), para ser acessada posteriormente durante os processos de identificação de

fragmentos de código e de identificação de dependências.

Figura 17. Código do classe ASTExplorer do analisador estático de código.

3.2.5 Buscas de Análises de Código da LPS

Depois do preenchimento do SAM com informações sobre características, artefatos

de implementação, conhecimento de configuração e relacionamentos de dependências

entre os artefatos de implementação, podem ser implementadas buscas específicas sobre

44

tal modelo de forma a avaliar alguma propriedade da LPS. As buscas de análise

representam algoritmos que acessam o SAM com a finalidade extrair informação úteis

para o desenvolvimento e evolução de uma LPS. As buscas são desenvolvidas pelos

usuários do Squid que desejam analisar aspectos e propriedades específicas de LPS, o

SAM oferece uma série de informações para esta tarefa. A implementação de buscas é

realizada por meio da extensão do ponto flexível representado pela interface Query, da

infraestrutura oferecida pelo Squid, conforme apresentado na Seção 3.2.1.

A Figura 18 apresenta o código da classe FeatureTraceability, que é um

exemplo de instanciação do ponto de extensão de buscas, que tem o objetivo de obter os

artefatos de implementação relacionados a uma dada característica. Esta classe

implementa a interface Query e declara os métodos requeridos runQuery() e

getName(). O objeto da classe SquidAnalysisModelContent (declarado na linha 4)

é utilizado para a manipulação do SAM. A classe TraceabilityQueryModel,

instanciada na linha 5, é utilizada para armazenar o resultado da busca. O atributo

featureName declarado na linha 6 contém o nome da característica a ser analisada. O

construtor (linhas 8 até 11) recebe o nome da característica e inicializa a variável

queryModel com o nome da busca obtido pela chamada do método getName(). O

método runQuey(:SquidAnalysisModel) é o método invocado pela classe fachada

(SquidAnalyseFacade) que recebe o SAM e cria uma instância da classe

SquidAnalysisModelContent. O método executeQuery() realiza a busca de

rastreabilidade (linha 19), recuperando a instância da característica no SAM utilizando o

método findFeature(:String). Em seguida, utilizando o método

findMappingsOf(:Feature) é obtido uma lista com todas as entidades de

mapeamentos associadas à característica analisada (linha 20). A interação com a lista de

mapeamentos extrai os artefatos (assets) associados e os inclui no queryModel (linhas

21-23). O método getName() (linha 25) retorna o nome da busca concatenando o nome

da classe com o nome da característica analisada. Ao final o método

runQuery(:SquidAnalysisModel) retorna o resultado obtido, que compreende todas

os artefatos que estão mapeados com a característica alvo.

45

Figura 18. Código da busca FeatureTraceability.

3.2.6 Visualizações de Análise em Linha de Produto

As visualizações do Squid têm o objetivo de apresentar para os engenheiros da

LPS, os resultados de buscas realizadas através de uma interface gráfica que ressalte as

propriedades sendo analisadas da LPS. O usuário da plataforma tem a liberdade de criá-las

fazendo uso de diversas tecnologias, como por exemplo, exibir os resultados usando

representações como gráficos, modelos ou textos em arquivos. O usuário desenvolve

visualizações estendendo o ponto flexível provido pela interface Visualizer, e após

executar as buscas de análise, a classe fachada (SquidAnalyserFacade) invoca o ponto

de extensão executando a visualização.

A Figura 19 apresenta o código fonte da classe

FeatureTraceabilityVisualizer, que exemplifica a implementação de um

visualizador, neste caso a visualização consiste em salvar em um arquivo de texto o

resultado da busca FeatureTraceability, que retorna uma lista de artefatos

46

associados a uma determinada característica. A Seção 3.2.5 detalhou a implementação de

tal busca. Esta classe implementa o método runVisualizer() que recebe,

respectivamente, como parâmetros: a instância do queryModel com o resultado da busca,

o nome da busca e o caminho do projeto no sistema de arquivos. Inicialmente, o arquivo

de saída é criado com o nome da busca e o caminho do projeto (linha 10) e um cabeçalho

é inserido no arquivo de texto (linha 12). Em seguida, ocorre a interação com os artefatos

listados no queryModel (linhas 13-15), para cada artefato o nome e o caminho são

escritos no arquivo (linha 14). Ao final, todos os artefatos associados à característica

analisada pela busca FeatureTraceability são listados no arquivo de saída gerado

pela visualização.


A Figura 20 apresenta um exemplo do arquivo de gerado pela visualização

FeatureTraceabilityVisualizar como resultado da execução da busca

FeatureTraceability para a característica SMS da versão 6 do Mobile Media. O

arquivo gerado apresenta todos os artefatos mapeados com característica SMS, no entanto

a Figura 20 exibe apenas o cabeçalho e os sete primeiros artefatos.

47


3.3 Instanciação da Infraestrutura

Uma vez tendo extraído informações relacionada às abstrações do espaço de

problema, conhecimento de configuração e espaço de solução de uma LPS, e armazenado

as mesmas no SAM, a etapa seguinte da abordagem é instanciar a infraestrutura para

promover a análise de propriedades do código da LPS. De forma a contemplar tal

objetivo, ferramentas específicas de análises devem ser desenvolvidas a partir da

infraestrutura.

A instanciação de uma dada ferramenta de análise a partir da infraestrutura envolve

a implementação de novos módulos para seus pontos flexíveis ou o reuso de módulos

previamente implementados para um de seus pontos de extensão. Diferentes ferramentas

ou funcionalidades de análise de implementações de linhas de produto de software podem

48

ser implementadas usando a nossa infraestrutura. A seguir apresentamos exemplos de

análises que podem ser contempladas pela nossa abordagem:

Rastrear impactos de mudança entre características, casos de uso e artefatos

de implementação. O SAM possui a entidade mapeamento que descreve os

relacionamentos entre as entidades que representam artefatos de implementação, casos de

uso e características. Através dos relacionamentos de mapeamento obtidos é possível

analisar os impactos de mudanças entre as entidades envolvidas, ou seja, podemos inferir

quais serão as entidades afetadas ao realizar alterações em alguma das entidades. Um

exemplo desse tipo de análise é o cenário em que um artefato de código implementa um

conjunto de características, neste caso o conjunto de características pode ser afetado por

modificações realizadas em artefatos que as implementam. O benefício dessa análise de

impacto de mudanças para LPS é prover informações úteis para o planejamento das

alterações a serem realizadas durante o desenvolvimento ou evolução da LPS,

promovendo o rastreamento entre seus diferentes artefatos de modelagem e

implementação.

Identificar restrições entre características por meio de relacionamentos de

artefatos de implementação. As relações de dependências entre artefatos de

implementação no espaço da solução podem gerar dependências entre entidades no espaço

de problema. Por exemplo, características que não possuem uma associação direta podem

estar correlacionadas indiretamente por meio de um relacionamento entre os artefatos que

as implementam. Devido à separação entre espaço do problema e espaço da solução, estas

dependências indiretas dificilmente serão identificadas analisando apenas uma das

abstrações, porém ao realizar consultas no SAM proposto podemos cruzar informações de

mapeamento entre abstrações dos espaços de problema e solução, e assim identificar

relacionamentos indiretos. Esta análise contribui com a descoberta de restrições entre

características, que são difíceis de identificar durante modelagem das características de

uma LPS, ou que são detectadas durante o processo de extração ou engenharia reversa de

uma LPS a partir de artefatos de implementação existentes.

Análise de inconsistências no conhecimento de configuração. O conhecimento

de configuração descreve a coligação entre espaço do problema e espaço da solução. Dada

a complexidade da sua especificação, a modelagem do conhecimento de configuração

pode conter inconsistências, tais como, mapeamentos replicados, artefatos que não

49

possuem associação com características, características não associadas a algum artefato de

implementação, características que possuem implementações idênticas e outros

problemas. Conforme discutido por (TEIXEIRA; ROHIT; BORBA, 2011), em razão das

inconsistências no conhecimento de configuração, a LPS pode gerar produtos inválidos.

Especificamente, inconsistências no conhecimento de configuração podem criar conflitos

de implementação, como por exemplo, dependências não contempladas, e assim gerar

erros sintáticos que levam a produtos não compiláveis como resultado da derivação. As

inconsistências podem ser detectadas através do desenvolvimento de buscas específicas

sobre o SAM, verificando, por exemplo, mapeamentos duplicados, características ou

artefatos de implementação não mapeados. A principal contribuição desse tipo de análise

é oferecer uma análise de suporte a composição segura de produtos, que diz respeito a

derivar produtos sintaticamente ou semanticamente corretos.

3.4 Sumário

Neste capítulo foi apresentado o projeto e a implementação da infraestrutura de

software Squid Analyser, o propósito da infraestrutua proposta é servir como plataforma

para desenvolvimento de ferramentas de análise de LPS. Em linhas gerais foi detalhada a

arquitetura do Squid Analyser, apresentando e delineando os pontos de extensão

disponibilizados, especificamente, extrator de artefatos de LPS, analisador de dependência

de código, buscas de análise e visualizações de análise. Para cada ponto de extensão foi

apresentado um exemplo de implementação. Além disso, foi especificado o Squid Analyse

Model, modelo adotado pela infraestrutura para armazenar as informações de análise.

50

4 Squid Impact Analyser: Uma Ferramenta para Análise de

Impacto de Mudanças

Este capítulo apresenta uma ferramenta para análise de impacto de mudanças para

Linhas de Produto de Software. A abordagem da ferramenta é fundamentada na análise de

dependências entre artefatos presentes no espaço da solução em conjunto com

informações de rastreabilidade entre variabilidades do espaço do problema e artefatos de

implementação do espaço da solução. A ferramenta proposta é nomeada Squid Impact

Analyser, e foi desenvolvida através da instanciação da infraestrutura Squid. A Seção 4.1

apresenta uma visão geral explicando o passo a passo executados pela ferramenta. A

Seção 4.2 descreve a arquitetura da ferramenta e como foi realizada a instanciação dos

pontos de extensão da infraestrutura Squid. A Seção 4.3 descreve as buscas de análise de

impacto de mudanças desenvolvidas para a ferramenta, enquanto a Seção 4.4 apresenta

visualizações de análise de impacto providas pela ferramenta.

4.1 Visão Geral do Funcionamento da Ferramenta

O objetivo da ferramenta proposta neste capítulo é estimar quais são os impactos

gerados por mudanças na implementação de artefatos de implementação de uma LPS,

durante o seu desenvolvimento ou evolução. Tais mudanças podem ser decorrentes de:

correções de erros; inserção, remoção ou modificação de funcionalidades; refatorações

para melhoria do código fonte, entre outras. Os impactos resultantes de mudanças em um

dado artefato de implementação podem ocasionar erros em outros, e dessa forma, a LPS

pode gerar produtos com erros de compilação ou semântico como o funcionamento não

adequado de determinadas características.

A ferramenta proposta é baseada na análise de diversos tipos de informações

relacionadas a uma LPS, tais como, características, conhecimento de configuração,

artefatos de implementação, restrições entre características e dependências entre artefatos

de implementação. O objetivo principal da ferramenta é utilizar informações de

relacionamentos entre entidades (características comuns e variáveis) que compõem o

espaço do problema com informações de relacionamentos entre entidades (classes,

interfaces) que compõe o espaço da solução, associando-as por meio do conhecimento de

configuração. Dessa forma, obtêm-se uma cadeia de relacionamentos entre entidades do

51

espaço do problema e entidades do espaço da solução. E assim, por meio das cadeias de

relacionamento das entidades envolvidas em uma mudança, a análise de impacto de

mudanças estima quais entidades poderão ser afetadas.

A Figura 21 ilustra um exemplo de uma cadeia de relacionamentos envolvendo

entidades do espaço do problema (esquerda) e do espaço da solução (direita) da LPS

Mobile Media. A cadeia apresentada parte da característica Music e prossegue conforme a

sequência de relacionamentos, representados por setas. As setas em vermelho representam

os relacionamentos de mapeamento da característica Music com os artefatos de

implementação, em verde estão os relacionamentos de dependência que outros artefatos

possuem com os artefatos que implementam a característica Music. E por fim, em azul,

está o mapeamento das classes dependentes com características do espaço do problema.

Este exemplo simula uma análise de impacto mudanças, onde a partir da cadeia de

relacionamentos obtida é possível extrair artefatos de implementação e outras

características que podem ser afetados por mudanças na característica Music.

Figura 21. Exemplo de cadeia de relacionamentos.

A Figura 22 apresenta um diagrama de atividade com as quatro atividades que

compreendem a análise de impacto de mudanças realizada pelo Squid Impact Analyser. A

atividade 1 consiste em obter o conjunto semente da mudança . O conjunto semente da

mudança é um conjunto inicial de entidades (características e/ou artefatos de

52

implementação), das quais se tem um conhecimento prévio que serão modificadas ou

afetadas pela mudança. Tal conjunto semente é usado como ponto de partida para a análise

de impacto de mudanças. O conjunto semente pode ser obtido por diferentes estratégias,

tais como, a partir da documentação do projeto de mudança (casos de uso, descrição da

arquitetura, análise de requisitos, entre outros) elaborado por um engenheiro da LPS, ou

por uma análise prévia que estima quais entidades serão afetadas pela mudança antes de

iniciar o desenvolvimento ou evolução da LPS. O conjunto semente traz apenas uma

previsão inicial das mudanças, e não uma estimativa completa que contempla todas as

entidades que são afetadas. Realizar uma estimativa completa manualmente é uma

atividade complexa que demanda tempo e um grande esforço de análise dos artefatos de

implementação. A busca por uma estimativa completa e mais precisa é justamente o

objetivo da ferramenta de análise de impacto de mudanças, que complementa o conjunto

inicial estimado.

Figura 22. Diagrama de atividades da ferramenta Squid Impact Analyser.

53

Na atividade 2 da executada pela ferramenta são selecionados quais serão os tipos

de relacionamentos adotados para compor as cadeias de relacionamento. O conjunto de

relacionamentos utilizado é uma variável importante para a análise de impacto de

mudanças, pois interfere no tamanho das cadeias de relacionamento afetando a precisão e

a cobertura da análise. Exemplos de tipos de relacionamentos que podem ser explorados

pela estratégia da ferramenta são: hierarquia de características, interação entre

características (inclusão ou exclusão), dependências entre artefatos de implementação,

hierarquia de artefatos de implementação e mapeamento entre características e artefatos de

implementação.

A atividade 3 tem como objetivo obter as cadeias de relacionamentos que serão

utilizadas posteriormente para extrair as entidades estimadas durante a análise de impacto

de mudanças. As cadeias de relacionamento podem ser representadas por estruturas de

dados que interligam as entidades que compõem a LPS. As relações entre entidades que

podem ser exploradas são justamente aquelas selecionadas na atividade 2. A geração das

cadeias de relacionamento é uma tarefa sistemática, que se inicia obtendo os

relacionamentos das sementes e sucessivamente a análise prossegue obtendo os

relacionamentos subseqüentes. A profundidade dos relacionamentos representa a distância

entre dois elementos em um grafo. Na Figura 23, por exemplo, a distância entre os

vértices A e E é dois, enquanto a distância entre B e D é um. Para este contexto a

profundidade é aplicável aos relacionamentos de dependência, o nível de profundidade

pode afetar o tamanho das cadeias de relacionamento, interferindo na precisão e cobertura

da análise.

Figura 23. Exemplo de grafo.

54

A atividade 4 compreende a seleção de quais entidades inclusas nas cadeias de

relacionamentos farão parte do Conjunto de Impacto Estimado pela análise. Os critérios

de seleção variam conforme os objetivos da análise. A Figura 21 ilustra, por exemplo, que

se o objetivo for obter os impactos em características geradas por dependências em

artefatos de implementação, o resultado será as características PhotoAlbum e

CopyMedia. Nossa ferramenta gera, portanto, como resultado final, o Conjunto de

Impacto Estimado contendo as entidades - características e artefatos de implementação -

que possivelmente serão afetadas por mudanças no Conjunto Semente.

A ferramenta especificada nesta seção foi elaborada com objetivo de oferecer

diretrizes para uma ferramenta de análise de impacto de mudanças. Não é viável

implementá-la sem o uso de técnicas automatizadas de extração e análise, pois em

aplicações reais o volume e a variedade de informações necessárias para a análise é

elevado, o que demanda tempo e esforço. Nesta dissertação, a ferramenta foi

implementada utilizando a infraestrutura Squid (Capítulo 3) e, dessa forma, propõe-se

uma ferramenta para análise de impacto de mudanças apresentada na seção a seguir.

4.2 Arquitetura

A ferramenta Squid Impact Analyser tem a finalidade de auxiliar os engenheiros de

LPS durante atividades de evolução, apresentando previamente os impactos provocados

por mudanças planejadas, e seu escopo de aplicação compreende as LPS implementadas

usando a linguagem Java de programação orientada a objetos. A ferramenta foi

desenvolvida com base na infraestrutura de software Squid Analyser, e utiliza os modelos

de característica, configuração e arquitetura gerados pela ferramenta de derivação

GenArch como fonte de informações da LPS.

A infraestrutura Squid Analyser foi adotada como base para a ferramenta, pois

apresenta uma infraestrutura flexível e capaz de satisfazer os requisitos necessários para a

ferramenta proposta. Especificamente, o ponto de extensão para extração automática de

informações de artefatos da LPS permite a extração de características, conhecimento de

configuração e artefatos de implementação. Do mesmo modo, o ponto de extensão para

análise estática de código proporciona a obtenção de relacionamentos de dependência

entre artefatos de implementação. Finalmente, o SAM disponibilizado pela infraestrutura

55

organiza e disponibiliza as informações necessárias para análise. O algoritmo de análise

pode ser implementado no ponto de extensão de buscas de análise, acessando as

informações contidas no SAM através da API de manipulação gerada pelo EMF.

A Figura 24 ilustra a instanciação da ferramenta Squid Impact Analyser a partir da

infraestrutura Squid. O ponto de extensão de extrator é realizado pelo componente

GenArchExtractor, um extrator que extrai informações de artefatos de LPS

provenientes dos modelos gerados pela ferramenta de derivação GenArch. O componente

JavaASTAnalyser realiza o ponto de extensão de análise estática de código. Ele analisa

a árvore sintática abstrata do código fonte para obter os relacionamentos de dependência.

Dessa forma, para a implementação da ferramenta foi promovido o reuso das

instanciações de referência dos pontos de extensão extrator e analisador estático de código

(versão utilizando a AST Java) que foram detalhados, respectivamente, nas seções 3.2.3 e

3.2.4.2. Além disso, também foi adotado o SAM estendido para LPSs desenvolvidas com

linguagens orientadas a objetos, que foi apresentado pela Seção 3.2.2.

Figura 24. Diagrama de componentes de instanciação da infraestrutura.

Com o reuso dos componentes GenArchExtractor e JavaASTAnalyser, o

esforço para a instanciação da ferramenta foi reduzido para o desenvolvimento das buscas

e visualizações. Nesse sentido, a implementação das buscas é a parte mais relevante para a

implementação da ferramenta de análise de impacto de mudanças proposta, pois ela

contempla a estratégia da ferramenta, enquanto os outros módulos oferecem o suporte à

extração de informações requeridas para análise e visualização.

56

A Figura 25 apresenta um diagrama de atividades que sintetiza o passo a passo da

execução da ferramenta Squid Impact Analyser seguindo o fluxo de execução da

infraestrutura Squid. O fluxo de execução tem início com a seleção da LPS alvo da análise

(atividade 1). Em seguida, é realizada extração das informações de artefatos da LPS alvo

(atividade 2), executando o componente GenArchExtractor e obtendo as

características, conhecimento de configuração e artefatos de implementação (classes,

métodos, atributos e fragmentos de código). Posteriormente, é realizada a análise estática

de código fonte (atividade 3), na qual as dependências são extraídas dos artefatos de

implementação e o SAM é complementado com estas informações.

Figura 25. Atividades da ferramenta Squid Impact Anayser.

Neste ponto do fluxo de atividades, o SAM está completo e contém todas as

informações necessárias para a ferramenta proposta. Assim, as buscas por impacto de

mudanças, implementadas de acordo com a estratégia descr ita neste capítulo, podem ser

executadas. A atividade 4 consiste em selecionar quais serão as entidades que constituem

o Conjunto Semente que alimentará as buscas de análise. Já a atividade 5 executa as

57

buscas de análise de impacto de mudanças propriamente ditas. Finalmente, a atividade 6

recebe o Conjunto de Impacto Estimado e gera a visualização do resultado da análise

realizada. As implementações das buscas de análise de impacto de mudanças e das

visualizações de análise são detalhadas nas seções a seguir.

4.3 Buscas de Análise de Impacto de Mudanças

Nesta seção são apresentadas quatro buscas de análise de impacto de mudanças que

foram desenvolvidas para demonstrar a instanciação da ferramenta proposta utilizando a

infraestrutura Squid.

4.3.1 Busca de Impactos de Remoção de Características

O propósito desta busca é identificar quais serão os artefatos afetados em uma

situação de remoção de uma característica da LPS. Em determinados momentos da

evolução de uma LPS, pode ser necessário remover uma característica. Uma dada

característica pode ser removida por não atender mais uma necessidade dos usuários, ou a

LPS está sob um processo de redefinição do seu escopo ocasionando a sua reestruturação

em outras LPSs.

O processo para remover uma característica de uma LPS e corrigir os impactos

causados por essa remoção é iniciado com a identificação dos artefatos que são exclusivos

da característica (mapeados apenas com a característica alvo) e deverão ser removidos.

Em seguida, deve-se identificar os artefatos compartilhados com outras características,

que também poderão sofrer impactos, e dessa forma será necessário verificar a

necessidade de modificações afim de evitar problemas com as características associadas

aos mesmos. Outro caso são os artefatos que dependem dos artefatos exclusivos, ou seja,

que estão mapeados diretamente com a característica a ser removida. Tais artefatos

deverão também ser rastreados e verificados, pois seguramente apresentarão problemas

decorrentes da remoção dos artefatos exclusivos, prejudicando o funcionamento de outras

características associadas a eles.

A busca de análise de impacto para remoção de características recebe como

semente uma string com o nome da característica alvo da remoção. A busca retorna como

resultado: a lista de artefatos exclusivos da característica alvo, a lista de artefatos

58

compartilhados com a característica alvo, a lista de artefatos dependentes dos artefatos

exclusivos e a lista de outras características que podem ter seu funcionamento prejudicado

pela remoção da característica alvo. A Figura 26 apresenta o método

runQuery(AnalysisModel) da classe ImpactOfRemovingFeature que implementa

uma busca e realiza a análise de impacto de remoção de características.

Figura 26. Trecho de código fonte da classe ImpactOfRemovingFeature.

A seguir é descrito o algoritmo da busca de remoção de características conforme o

código fonte apresentado:

1. Linha 6: é criada uma instância da classe SquidAnalysisModelHandler ,

que será utilizada para a manipulação do SAM. A instância é iniciada com a

referência do SAM recebido como parâmetro.

59

2. Linha 7: obtém-se a referência da característica alvo no SAM, utilizando o

método findFeature(String). O nome da característica foi recebido no

construtor da classe ImpactOfRemovingFeature que está oculto.

3. Linha 14: utiliza-se o método findMappingOf(Feature) para recuperar a

lista de mapeamentos associados a característica alvo.

4. Linhas 16 até 17: são selecionados da lista de mapeamentos, os artefatos que

estão mapeados exclusivamente com a característica alvo, estes serão salvos na

variável exclusiveAssets.

5. Linhas 18 até 19: selecionar da lista de mapeamentos os artefatos que são

compartilhados com outras características e salvá-los na variável

sharedAssets.

6. Linhas 24 até 26: para cada artefato da lista exclusiveAssets, obter os

artefatos que dependem destes utilizando método

getAssetsDependenciesOf(Asset) e salvá-los na variável

dependentAssets.

7. Linhas 28 até 31: Para cada artefato dependente contido na lista

dependentAssets , obter quais as características estão associadas a ele e

incluí-las na variável affectedFeatures.

8. Linha 33: é criado o objeto result da classe RemoveFeatureQueryModel,

que foi projetada para armazenar os resultado da análise de remoção de

característica.

9. Linha 36: ao fim, a análise retorna o objeto result, posteriormente este objeto

será utilizado pelo visualizador para gerar a visualização da análise.

4.3.2 Busca de Impacto de Mudanças de Características em

Profundidade.

O objetivo da busca de impacto de mudanças de características por profundidade é

prever os impactos de mudanças em uma determinada característica, o parâmetro

profundidade delimita até quantos níveis a busca vai avançar no grafo de dependências de

artefatos de implementação. Muitas vezes durante a evolução de uma LPS, uma

determinada característica precisa ser modificada podendo haver a necessidade de

refatorar o seu código. Exemplos que podem motivar este tipo de mudança são:

60

manutenções para ajustes na lógica de negócio ou no desempenho, erros durante a

execução da característica, erro na geração de produtos com a característica, entre outros.

Para realizar modificações em características, como os casos citados anteriormente,

é preciso saber quais são os artefatos que implementam a característica a ser alterada,

quais outros artefatos que dependem dos artefatos que a implementam, quais as

características que podem ser afetadas pela mudança na característica alvo. A busca de

impactos de mudanças de características recebe como Conjunto Semente o nome da

característica a ser modificada. A busca deve retornar os artefatos de implementação que

serão impactados, e também as características que poderão ser afetadas por uma mudança

na implementação da característica alvo. Esta busca permitirá ao engenheiro da LPS ter

um panorama geral em termos de impactos causados por mudanças na característica alvo,

e assim poder planejar uma estratégia de mudança contando com estas informações. A

seguir é apresentada uma síntese das etapas realizadas nesta busca:

1. Utilizando as informações de conhecimento de configuração, obter artefatos

que implementam a característica alvo e incluí-los na lista de impactos.

2. Para os artefatos de implementação inclusos no passo anterior, procurar as

dependências dos mesmos fazendo uso de uma estratégia recursiva para buscas

de profundidade em grafos. A profundidade é um parâmetro informado pelo

usuário ao criar a busca.

3. Obter outras características que compartilham os artefatos que implementam a

característica alvo e adicioná-los na lista de impactos.

4. Por meio da entidade constraint do SAM, procurar as características que

possuem restrição de inclusão com a característica alvo e incluí-las como

impacto.

5. Incluir como impacto as características que possuam o mesmo pai na hierarquia

da árvore de características.

6. Para cada característica do passo anterior incluir os artefatos mapeados na lista

de impacto de mudança.

7. Ao final, os impactos estimados são armazenados em um objeto apropriado

para essas informações. Depois este objeto será utilizado na etapa de

visualização.

61

4.3.3 Busca de Impacto de Mudança de Artefatos em Profundidade.

A finalidade da busca de impacto de mudanças de artefatos em profundidade é

estimar quais serão os artefatos e características que serão afetados por mudanças em um

determinado artefato de implementação. A profundidade delimita até quantos níveis a

busca vai avançar no grafo de dependências de artefatos de implementação.

Modificações em artefatos de implementação são atividades corriqueiras na

manutenção e evolução de uma LPS. Exemplos de cenários que levam à modificação de

artefatos de implementação são: correção de erros, adequações às regras arquiteturais,

atualização de tecnologias, entre outros. Essas modificações devem ser realizadas com o

devido cuidado para não inserir erros em outros artefatos de implementação da LPS, para

isso o desenvolvedor deve estar ciente de tudo que será afetado em decorrência da

modificação que realizará. No contexto de LPS, este tipo de modificação pode ter o

agravante do desenvolvedor estar imerso no espaço do solução (artefatos de

implementação) e ter dificuldade de associar às mudanças aos seus respectivos impactos

no espaço de problema (características). Para modificar um artefato de implementação, o

desenvolvedor dever estar ciente tanto dos outros artefatos de implementação que podem

sofrer impactos, quanto das características que podem ser afetadas. Dessa forma, poderá

avaliar estratégias de implementação evitando gerar erros na LPS. A seguir é apresentado

o conjunto de passos executados pela busca de impacto de mudanças em artefatos de

implementação:

1. Buscar artefatos de implementação que dependem do artefato alvo e incluí-los

na lista de impactos estimados. Essa consulta utiliza uma estratégia recursiva

para buscas de profundidade em grafos. A profundidade é um parâmetro

informado pelo usuário ao criar a busca.

2. Consultar as informações de conhecimento de configuração a fim de obter

características associadas ao artefato alvo e aos artefatos obtidos no passo 1.

3. Para cada característica mapeada ao artefato alvo, obter: características que

possuam o mesmo pai na hierarquia, características filhas e características que

possuam o relacionamento de inclusão. Em seguida, incluir tais informações na

lista de impacto.

62

4. Para cada característica encontrada no passo anterior, incluir na lista de impacto

os artefatos mapeados a elas.

5. Finalmente, salvar a lista de impactos estimados em um objeto que será

retornado como resultado.

4.3.4 Busca de Impacto de Mudanças de Tipo de Característica de

Obrigatória para Opcional

O propósito dessa busca é estimar os impacto gerados por uma mudança no tipo de

uma característica, especificamente neste caso, o tipo alterna de característica obrigatória

para característica opcional. No decorrer da evolução de uma LPS as características

podem ter o seu tipo alterado, neste caso os artefatos que a implementam podem passar a

ser opcionais. Isso significa que todos os artefatos de implementação obrigatórios que o

utilizam (invocam um de seus métodos, por exemplo) devem ser também modificados no

caso em que a característica opcional que determina a inclusão de tal artefato não seja

incluída na derivação de um determinado produto. Dessa forma, os trechos de código onde

esses artefatos (que agora são opcionais) são utilizados, precisarão ser tratados,

possivelmente com a inserção de pontos de variação.

A busca de mudanças de tipo de característica de obrigatória para opcional deve

retornar os artefatos de implementação que estão diretamente ligados à característica

modificada. Uma parcela destes artefatos de implementação deverão ser modificados para

se tornar pontos de variação. De forma discriminada, deverá retornar os artefatos

compartilhados com características obrigatórias, pois estes artefatos serão analisados

separadamente e possivelmente não serão flexibilizados como ponto de variação. A busca

também deve retornar os artefatos que utilizam diretamente os artefatos associados à

característica modificada, parte destes artefatos poderá ter pontos de variação inclusos.

Além disso, as características associadas aos artefatos que dependem dos artefatos que

implementam a característica alvo também serão considerados impactos, pois pode ser

necessário atualizar as restrições com a característica alvo. A seguir é apresentado um

resumo do algoritmo da busca:

1. Utilizando as informações de conhecimento de configuração, buscar e incluir

na lista de impacto estimado todos os artefatos de implementação que estão

mapeados na característica alvo.

63

2. Para cada artefato do passo anterior procurar os artefatos que possuem

dependência dos mesmos, e incluí-los na lista de impactos.

3. Para cada artefato obtido no passo anterior analisar o conhecimento de

configuração a fim de obter as características mapeadas.

4. Armazenar em um objeto os impactos estimados, descriminando-os em:

artefatos que implementam a característica alvo, artefatos compartilhados com

características do tipo obrigatória, artefatos dependentes e características

afetadas.

5. Retornar o objeto com o resultado da análise.

4.4 Visualizações de Análise de Impacto de Mudanças

Uma funcionalidade de visualização de impacto de mudanças foi elaborada com o

intuito de expor os resultados das buscas de impacto de mudanças apresentadas na Seção

4.3. Além, disso, ela também exemplifica o desenvolvimento de pontos de extensão de

visualizações da infraestrutura de análise Squid. Esta seção apresenta a implementação da

visualização ImpactVisualizerModel, que consiste em um modelo desenvolvido com o

plugin EMF para a plataforma Eclipse. A visualização propriamente dita é desempenhada

pelo visualizador de modelos gerado pelo EMF.

A Figura 27 apresenta o diagrama de classe do modelo de visualização de

impactos. O ImpactVisualizerModel é utilizado pela classe ImpactVisualizer para

exportar os resultados da análise de impactos e assim poderão ser visualizados pelos

usuários por meio do visualizador do modelo. Em uma visualização pode haver um ou

vários conjuntos de resultados (ResultSet), estes conjuntos têm a finalidade de

subdividir os resultados em categorias, que podem ser nomeadas pelo atributo name. Os

conjuntos de resultados podem conter entidades presentes no SAM, especificamente,

características (Feature), conhecimento de configuração (Mapping) e artefatos de

implementação (Asset).

64

Figura 27. Diagrama de classe do modelo de visualização de impactos.

A Figura 28 apresenta o código fonte da classe RemovingFeatureVisualizer.

Tal classe realiza o ponto de extensão de visualização da infraestrutura Squid. Esta

visualização foi projetada para a busca de impacto de remoção de características explicada

na Seção 4.3.1. Em resumo, a classe RemovingFeatureVisualizer recebe como

parâmetro o objeto RemovingFeatureQueryModel e, em seguida, transcreve as

informações de tal modelo para uma instância do modelo de visualização de impactos

(linhas 11-32). Finalmente, o modelo é salvo em um arquivo do modelo

ImpactVisualizerModel (linha 37).

65

Figura 28. Código fonte da visualização de impacto de mudanças.

A Figura 29 apresenta a visualização do modelo gerado, onde podemos ver o

resultado subdividido em quatro conjuntos de resultados (ResultSet), seguido pela

quantidade de entidades contidas no conjunto, especificamente: artefatos exclusivos,

artefatos dependentes, artefatos compartilhados e artefatos afetados. Observa-se que os

conjuntos presentes neste modelo estão alinhado com a busca de remoção de

características (ImpactOfRemovingFeature) apresentada na Seção 4.3.1 e com código

da visualização RemovingFeatureVisualizer apresentado na Figura 28.

66

Figura 29. Vizualização do modelo de impacto de mudanças.

4.5 Sumário

Neste capítulo foi apresentado o projeto de implementação da ferramenta Squid

Impact Analyser que oferece suporte para análise de impacto de mudanças para Linhas de

Produto de Software. A implementação da ferramenta foi apresentada através da

instanciação da infraestrutura de software Squid Analyser para o desenvolvimento da

ferramenta. Além disso, fazendo o uso de diagramas de atividades UML, também foi

explicada a estratégia de análise de impacto de mudanças provida pela ferramenta. Para

finalizar foram apresentadas as implementações de buscas e visualizações desenvolvidas.

67

5 Avaliação do Squid Impact Analyser

Este capítulo apresenta a avaliação da ferramenta de análise de impacto de

mudanças, o Squid Impact Analyser. De forma a atingir tal objetivo, foram realizados

diversos experimentos de análise de mudanças dentro de cenários de evolução de uma

linha de produto de software. Os experimentos de avaliação buscam sempre comparar os

artefatos impactados retornados pela ferramenta com os artefatos reais modificados dentro

de um dado cenário de evolução. A avaliação proposta procura responder a seguinte

questão de pesquisa:

“Qual a influência do uso simultâneo de informações de mapeamento de

características e informações de dependência entre artefatos de

implementação para a análise de impacto de mudanças em LPS?”

A Seção 5.1 apresenta as métricas utilizadas para comparar a análise de impacto de

mudança no contexto dos experimentos. A Seção 5.2 apresenta a LPS Mobile Media que

foi adotada na nossa avaliação. As Seções 5.3 e 5.4 apresentam os experimentos

realizados.

5.1 Métricas para Avaliação da Análise de Impacto de Mudanças

De forma a permitir a comparação dos resultados da análise de impacto providos

pela ferramenta Squid Impact Analyser com o impacto real nos artefatos durante a

evolução de uma LPS, foi necessário organizar os dados obtidos durante a análise de

impacto de mudança. A Figura 30 apresenta a forma como os dados foram categorizados

em conjuntos para facilitar tal análise. A seguir são descritos os conjuntos obtidos como

resultado da análise de impacto de mudança.

68

Figura 30. Categorização dos artefatos na análise de impacto de mudanças.

Conjunto de Sementes (CS): é um conjunto inicial de artefatos impactados

(classes, métodos, atributos e fragmentos de código), este conjunto é utilizado como ponto

de partida para a análise de impacto de mudanças.

Conjunto de Impacto Real (CIR): contém todos os artefatos que sofreram

mudanças na evolução. Neste trabalho, o CIR é obtido com uma abordagem semi-

automática, na qual é utilizada uma ferramenta de comparação de código fonte para obter

as diferenças textuais entre artefatos de código. No entanto, é necessária a inspeção

manual do código para verificar quais mudanças apontadas pela ferramenta são relevantes.

Por exemplo, mudanças em comentários ou nome de identificadores não são inseridas no

CIR, enquanto mudanças estruturais são consideradas no CIR.

Conjunto de Impacto Estimado (CIE): é composto pelos artefatos que a

ferramenta de análise de impacto de mudanças estimou como sendo impactados em um

dado cenário de evolução. A estimativa da ferramenta é realizada a partir de informações

de entrada, neste caso o Conjunto Semente, e utilizam-se estratégias para análise de

impacto de mudanças para calcular os artefatos possivelmente afetados.

Conjunto Falso-Positivo (CFP): são os artefatos que foram estimados pela

ferramenta de análise de impacto de mudanças, porém não foram afetados na evolução. Os

69

artefatos falso-positivos pertencem ao CIE, porém não pertencem ao CIR, ou seja,

representam as estimativas equivocadas.

Conjunto Falso-Negativo (CFN): consiste no conjunto de artefatos que sofreram

mudanças na evolução, entretanto não foram estimados pela análise de impacto de

mudanças. Os falso-positivos são artefatos que pertencem ao CIR, porém não pertencem

ao CIE.

Conjunto Intersecção (CI): compreende os artefatos que foram estimados pela

análise de impacto de mudanças e realmente foram afetados na evolução, ou seja, as

estimativas corretas. O CI é a intersecção entre o CIR com o CIE.

Para permitir a avaliação da qualidade da resposta de análise de impacto de

mudança informada pela ferramenta Squid, foram utilizadas métricas que quantificam a

precisão e cobertura dos resultados retornados pela ferramenta em comparação co m os

artefatos de fato impactados. Tais métricas foram extraídas do estudo apresentado por

[HATTORI; GUERRERO; FIGUEIREDO, 2008], no qual foi proposta a sua utilização

para o contexto de avaliação de ferramentas de análise de impactos de mudanças. A

seguir, é apresentada uma descrição de cada métrica adotada.

Métrica Cobertura: representa o quão eficaz a análise de impacto de mudanças é

em estimar os impactos reais obtendo a menor quantidade de falso-negativos possível, ou

seja, o maior número de estimativas corretas. A cobertura é calculada conforme a seguinte

fórmula: C (Cobertura) =|CI|/|CIR|. Dessa forma, em uma análise de impacto de mudança

em que o valor da métrica Cobertura é 1 equivalendo a 100%, temos que o CIE é igual ao

CI e o CFN é vazio.

Métrica Precisão: avalia o quão eficiente a análise de impacto de mudanças é em

estimar os impactos obtendo a menor quantidade possível de falso-positivos, ou seja, o

menor número de estimativas equivocadas. A precisão é calculada conforme a seguinte

fórmula: P (Precisão) = |CI|/|CIE|. Por exemplo, em uma análise de impacto cujo valor da

métrica precisão é 1 equivalendo a 100%, temos que CI = CIR e CFP é vazio.

Média Harmônica: medida que considera tanto a cobertura como precisão. A

finalidade de usar a média harmônica é relacionar em um número só a cobertura e

70

precisão, para a média harmônica ser alta, ambas as medidas precisam ser altas. A média

Harmônica é calculada conforme a seguinte fórmula: Média Harmônica = (2CP)/(P+C)

Os valores obtidos como resultado do cálculo das métricas variam de 0 a 1, porém

para uma melhor interpretação esses valores foram convertidos para correspondência em

percentagem, onde o valor 0 equivale a 0% e o valor 1 equivale a 100%.

5.2 Linha de Produto Mobile Media

O Mobile Media é uma linha de produto de software para aplicações de

manipulação de mídias digitais em dispositivos móveis. Ela representa uma LPS

desenvolvida para propósitos científicos, já tendo sido utilizada em diversos estudos de

caso e experimentos de evolução de LPS [FIGUEIREDO et al, 2008] [YOUNG, 2005].

Apesar de ser uma LPS desenvolvida para propósito acadêmico, ela foi derivada a partir

de uma aplicação real [YOUNG, 2005], e foi implementada usando tecnologias e padrões

de projeto comuns dentro do seu domínio de aplicação. A Figura 31 apresenta o modelo

de características da versão 7 do Mobile Media, explicitando suas similaridades e

variabilidades. Os modelos de características das demais versões estão presentes no Anexo

I.

Figura 31. Modelo de características da versão 7 do Mobile Media.

71

O Mobile Media possui oito versões, as quais, a partir deste ponto são referidas,

respectivamente, no texto como V1, V2, V3, V4, V5, V6, V7 e V8, conforme a sequência

da evolução do Mobile Media. A Tabela 1 resume as alterações realizadas a cada evolução

do Mobile Media. As versões V1 e V2 do Mobile Media não são caracterizadas como

LPS, pois ainda não possuem variabilidades. Elas representam versões do Mobile Photo,

que deu origem ao Mobile Media com a inclusão de variabilidades. Logo, na V3 é inclusa

a variabilidade Sorting, e assim o Mobile Media passa a ser uma LPS. Nossos estudos de

avaliação utilizaram as evoluções do Mobile Media das versões V3 à V7, devido a

limitações de tempo não foi possível realizar a análise para a evolução entre V7 e V8.

Tabela 1. Evoluções do Mobile Media.

Versão Variabilidades Evolução

V1 Nenhuma -

V2 Nenhuma Inclusão de tratamento de exceções

V3 Sorting Inclusão da variabilidade Sorting

V4 Sorting, Favourites Inclusão da variabilidade Favourites

V5 Sorting, Favourites,

Copy Inclusão da variabilidade Copy


Copy, Sms Inclusão da variabilidade Sms


Copy, Sms, Photo

Flexibilização da característica Photo,

que anteriormente era obrigatória.

Inclusão da variabilidade Music.

V8

Sorting, Favourites, Copy, Sms, Photo,

Video, CapturePhoto,

CaptureVideo

Inclusão das variabilidades Video,

CapturePhoto, CaptureVideo

Para cada versão do Mobile Media, há duas implementações disponíveis: (i) uma

que utiliza programação orientada a objetos em Java combinada com programação

orientada a aspectos [FILMAN et al, 2005] em AspectJ para implementar as

variabilidades; e (ii) a outra que combina programação orientada a objetos em Java com

técnicas de compilação condicional. Nossa avaliação utilizou as implementações baseadas

na abordagem de compilação condicional, pois um de nossos objetivos era avaliar as

dependências entre artefatos de implementação, incluindo os artefatos de granularidade

fina como fragmentos de código. A Tabela 2 apresenta o número artefatos existente em

cada versão do Mobile Media implementado com compilação condicional, nota-se que a

cada evolução há um aumento no número de artefatos.

72

Tabela 2. Quantidade de artefatos por versão do Mobile Media.

Tipo de

Artefato V3 V4 V5 V6 V7

Classes 25 25 30 37 46

Métodos 140 159 161 202 238

Atributos 71 74 75 107 132

Fragmentos 7 13 15 24 52

Total 243 255 281 370 468

Além dos motivos citados anteriormente, como quantidade de artefatos e aceitação

da comunidade, outra importante motivação para uso do Mobile Media para a avaliação

do Squid Impact Analyser, é a quantidade de versões com código fonte e documentação

disponíveis em [MobileMedia] [KHAN et al, 2010]. Assim, temos um objeto de estudo

relevante no contexto de evolução de LPS para a avaliação da ferramenta.

Tabela 3. Resumo de mudanças de artefatos durante evoluções do Mobile Media.

Evolução ∆ Tipo de Artefato

Total Classe Método Atributo Fragmento

V3-V4

Idêntico 20 133 71 6 230

Modificado 5 7 0 1 13

Adicionado 0 3 3 6 12

Removido 0 0 0 0 0

V4-V5

Idêntico 17 129 76 13 235



Removido 0 19 8 5 32

V5-V6

Idêntico 23 156 75 12 266



Removido 0 0 0 0 0

V6-V7

Idêntico 22 170 100 17 309


Adicionado 10 43 31 29 113

Removido 1 7 5 1 14

A Tabela 3 apresenta um resumo da quantidade de artefatos afetados entre as

versões V3 e V7 do Mobile Media. As evoluções do Mobile Media são identificadas por

um nome contendo as versões de início e fim, especificamente, V3-V4, V4-V5, V5-V6 e

V6-V7. Para cada evolução as mudanças são caracterizadas pela coluna ∆ (letra delta do

73

alfabeto grego) em idêntico, modificado, adicionado ou removido, também são

discriminados os tipos de artefatos em classes, métodos, atributos e fragmentos. A coluna

total apresenta o somatório de cada variação, e assim observa-se que a quantidade de

modificações e adições tende a aumentar a cada evolução.

5.3 Experimento 1

A finalidade do primeiro experimento foi avaliar se o uso de informações

relacionadas às características e ao conhecimento de configuração de uma LPS influencia

na análise de impacto de mudanças orientada a uma estratégia que utiliza apenas

informações sobre dependências de artefatos de código. Para isso, neste experimento foi

realizada uma comparação utilizando o Squid Impact Analyser, sendo executado com duas

configurações diferentes: (i) na primeira a análise considera as informações de

características e conhecimento de configuração; enquanto (ii) na segunda configuração, a

ferramenta utiliza apenas as informações dos artefatos de implementação e suas

dependências. O algoritmo utilizado é essencialmente o mesmo para ambas as estratégias,

porém as informações de características e conhecimento de configuração presente no

modelo de análise são removidas na execução da segunda configuração da ferramenta.

Mais objetivamente, este experimento procura responder a seguinte pergunta:

“A análise de impacto de mudanças em evolução de LPS é mais eficiente ou

eficaz se utilizarmos informações de características e conhecimento de

configuração na estratégia de estimativa dos artefatos impactados?”

Para este experimento, o conjunto semente (CS) utilizado pela ferramenta é obtido

por uma seleção aleatória dos artefatos que compõe o conjunto de impacto real (CIR). A

quantidade de artefatos selecionados para o CS deve corresponder entre 5% e 15% do total

de artefatos contidos no CIR. A idéia do uso do CS como uma amostragem parte da

pressuposição que, os artefatos alterados em uma evolução, correspondem às mudanças

relativas a uma determinada característica da LPS e, portanto, possuem uma correlação

sintática ou semântica entre si. Deste modo, analisando um subconjunto do CIR é possível

obter os outros artefatos que também foram alterados.

74

5.3.1 Configuração do Experimento

Para cada evolução do Mobile Media foi executado o fluxo de etapas especificado

abaixo. Após a execução do fluxo de etapas utilizando ambas as estratégias, foi possível

comparar os resultados das métricas calculadas.

1. Comparar a versão inicial com a versão final da evolução, e assim determinar o

CIR da evolução.

2. A partir dos artefatos contidos no CIR, selecionar aleatoriamente um

subconjunto entre 5-15% que serão inclusos no CS.

3. Executar a ferramenta de análise de impacto de mudanças utilizando como

entrada o CS obtido na etapa anterior. Ao final é gerado o conjunto de impacto

estimado (CIE).

4. Comparar o CIE gerado pela ferramenta com o CIR, depois categorizar cada

artefato em CI, CFP e CFN.

5. Com os conjuntos computados na etapa anterior, calcular as métricas de

cobertura, precisão e média harmônica da ferramenta de análise de impacto de

mudanças.

5.3.2 Resultados e Avaliação do Experimento

Esta seção apresenta os resultados e a avaliação do experimento. Os conjuntos CIR,

CS, CFP, CFN, CIE e CI, são apresentados em tabelas com o detalhamento da quantidade

de artefatos de cada tipo (classe, método, atributo ou fragmento) em cada evolução do

Mobile Media. Posteriormente são apresentados os resultados do cálculo das métricas

cobertura, precisão e média harmônica. Os comentários da avaliação são apresentados ao

longo da seção.

A Tabela 4 apresenta o CIR para cada evolução, nesse cálculo são considerados

como mudança os artefatos que foram modificados e os artefatos removidos de acordo

com a Tabela 3, pois esses são os tipos mudanças que a ferramenta pode identificar. Os

artefatos adicionados não são considerados no CIR, pois a adição de novos artefatos não

pode ser estimada pelas técnicas de análise implementadas, já que os mesmos não existem

na versão anterior que é aplicada a análise de impacto de mudança. Em seguida, são

75

apresentadas as sementes selecionadas de cada tipo de artefato, as sementes correspondem

de 5% a 15% do total de artefatos do CIR.

Tabela 4. Conjunto de Impacto Real (CIR) e Conjunto de Sementes (CS).

Tipo de

Artefato V3-V4 V4-V5 V5-V6 V6-V7

Conjunto de

Impacto Real

Classes 5 8 7 16

Métodos 7 31 7 39

Atributos 0 8 0 11

Fragmentos 1 5 3 8

Total 13 52 17 74

Conjunto de

Sementes

Classes 1 1 1 3

Métodos 0 5 1 5

Atributos 0 1 0 2

Fragmentos 1 1 0 1

Total 2 8 2 11

A Tabela 5 apresenta os CIE para as duas estratégias avaliadas. Inicialmente, são

apresentados os resultados para a estratégia orientada a características, em seguida é

apresentada a quantidade de artefatos estimados pela estratégia não orientada a

características. Conforme a análise dos CIE apresentados nota-se que estratégia orientada

a características estimou mais artefatos que a estratégia não orientada a características.

Tabela 5. Conjunto de Impacto Estimado (CIE).

Estratégia Tipo de


Orientada a

Características

Classes 5 8 7 15

Métodos 11 36 7 53

Atributos 1 11 1 12

Fragmentos 4 8 5 14

Total 21 63 20 94

Não Orientada a

Características

Classes 5 7 6 14

Métodos 7 27 6 37

Atributos 2 8 0 9

Fragmentos 2 3 1 3

Total 16 45 13 63

Após a etapa de comparação entre o CIR com os CIE de ambas as estratégias, foi

calculado entre os artefatos estimados quais pertencem ao conjunto de falso-positivos

(CFP) e quais pertencem ao conjunto de falso-negativos (CFN). A Tabela 6 apresenta os

76

falso-positivos e falso-negativos encontrados para cada estratégia, observa-se que a

análise da estratégia orientada a características tende a apresentar um número maior de

falso-positivos em relação a falso-negativos, enquanto a estratégia não orientada a

características tende a apresentar um número maior de falso-negativos em relação a falso-

positivos.

Tabela 6. Falso-Positivos e Falso-Negativos.

Estratégia Tipo de

Artefato

V3-V4 V4-V5 V5-V6 V6-V7

FP FN FP FN FP FN FP FN

Orientada a

Características

Classes 0 0 1 1 0 0 1 2

Métodos 4 0 11 6 1 1 16 2

Atributos 1 0 0 2 1 0 5 4

Fragmentos 3 0 0 1 3 1 6 0

Total 8 0 12 10 5 2 28 8

Não Orientada a

Características

Classes 0 0 1 2 0 1 1 3

Métodos 2 2 5 9 0 1 6 8

Atributos 2 0 3 3 0 0 4 6

Fragmentos 1 0 1 3 1 3 0 5

Total 5 2 10 17 1 5 11 22

A Tabela 7 apresenta o resultado final da etapa de comparação, os falso-positivos

são subtraídos dos CIE e assim é obtido o CI, que representam apenas os artefatos que

foram estimados corretamente pela estratégia. Uma observação geral a respeito dos dados

dessa tabela é o fato da estratégia orientada a características apresentar uma quantidade

maior de artefatos estimados corretamente em relação à estratégia não orientada a

características.

Depois de calcular CIE, CFN, CFP e CI para ambas estratégias é possível calcular

as métricas que foram apresentadas e descritas na Seção 5.1. A Tabela 8 apresenta o

resultado do cálculo das métricas de precisão, cobertura e média harmônica para a

estratégia orientada a características. Ao analisar a precisão e a cobertura da estratégia

orientada a características, pode ser notado que os resultados de cobertura são melhores

que os de precisão. Ao longo das evoluções a variação da cobertura se manteve entre 80%

e 100%, enquanto precisão variou entre 60% e 75%, e por fim a média harmônica fico u

entre 69% e 82%.

77

Tabela 7. Conjunto Intersecção.

Estratégia Tipo de Artefato V3-V4 V4-V5 V5-V6 V6-V7

Orientada a

características

Classes 5 7 7 14

Métodos 7 25 6 37

Atributos 0 6 0 7

Fragmentos 1 4 2 8

Total 13 42 15 66

Não orientada a

características

Classes 5 6 6 13

Métodos 5 22 6 31

Atributos 0 5 0 5

Fragmentos 1 2 0 3

Total 11 35 12 52

Tabela 8. Métricas precisão, cobertura e média harmônica para Estratégia Orientada

a Características.

Métrica Tipo de Artefato V3-V4 V4-V5 V5-V6 V6-V7

Precisão

Classes 100% 87.5% 100% 93.3%

Métodos 63.9% 69.4% 85.7% 69.8%

Atributos - 54.5% - 58.3%

Fragmentos 25% 50% 40% 57.1%

Total de Artefatos 61.4% 60.7% 75% 70.2%

Cobertura

Classes 100% 87.5% 100% 87.5%

Métodos 100% 80.6% 85.7% 94.8%

Atributos - 75% - 63.6%

Fragmentos - 80% 66.7% 100%

Total 100% 80.7% 88.2% 89.1%

Média Harmônica

Classes 100.00% 87.50% 100.00% 90.31%

Métodos 77.97% 74.58% 85.70% 80.40%

Atributos - 63.13% - 60.83%

Fragmentos - 61.54% 50.01% 72.69%

Total 76.08% 69.29% 81.07% 78.53%

A Tabela 9 apresenta os resultados obtidos para análise da estratégia não orientada

a características. A precisão obtida na análise para todas as evoluções analisadas manteve-

se entre 68% e 93%, enquanto a cobertura variou entre 67% e 85%, e finalmente a média

harmônica ficou entre 75% e 80%. Percebe-se que a cobertura da estratégia não orientada

a características apresenta taxas inferiores para os artefatos de granularidade fina como

fragmentos e atributos.

78

Tabela 9. Métricas precisão, cobertura e média harmônica da estratégia não orientada

a características.


Precisão

Classes 100% 85.7% 100% 92.8%

Métodos 71.4% 81.4% 100% 83.7%

Atributos -% 62.5% - 55.5%

Fragmentos 50% 66.7% 0% 100%

Total de Artefatos 68.7% 77.7% 92.3% 82.5%

Cobertura

Classes 100% 87.5% 85.7% 81.2%

Métodos 71.4% 70.9% 85.7% 79.4%

Atributos - 62.5% - 45.4%

Fragmentos 100% 40% 0% 37.5%

Total 84.6% 67.3% 70.5% 70.2%

Média Harmônica

Classes 100.00% 86.59% 92.30% 86.61%

Métodos 71.40% 75.79% 92.30% 81.49%

Atributos - 62.5% - 49.94%

Fragmentos 66.67% 50.01% - 54.55%

Total 75.83% 72.13% 79.94% 75.85%

A Figura 32 apresenta um diagrama de barras que demonstra a comparação entre os

valores da métrica precisão para ambas as estratégias. Ao avaliar o diagrama de precisão

observa-se que a análise de impacto de mudanças da estratégia não orientada a

características obteve melhores resultados de precisão para todas as evoluções em relação

à estratégia orientada a característica. Em média, a abordagem que utiliza

simultaneamente informações de mapeamento de características e informações de

dependência entre artefatos de implementação obteve 11% a mais de precisão.

79

Figura 32. Taxas da métrica precisão.

A Figura 33 apresenta um diagrama de barras que demonstra a comparação da taxa

de cobertura entres as duas estratégias. Ao avaliar o gráfico nota-se que a estratégia

orientada a características alcançou melhores resultados de cobertura para todas as

evoluções comparadas ao compararmos com a estratégia não orientada a características.

Calculando a média da diferença percentual temos que a abordagem que utiliza

simultaneamente informações de mapeamento de características e informações de

dependência entre artefatos de implementação obteve 18.5% a menos de cobertura.

80

Figura 33. Taxas da métrica cobertura.

A Figura 34 apresenta um diagrama de barras que demonstra a comparação da taxa

da média harmônica obtidas por ambas as estratégias. Pode-se observar que, em geral, em

todas as evoluções analisadas a diferença da média harmônica foi reduzida, exceto para a

evolução V6-V7 na qual a estratégia orientada a características obteve um resultado

visivelmente superior. Ao calcular a média da diferença de percentual da média a

harmônica, a estratégia que utiliza simultaneamente informações de mapeamento de

características e informações de dependência entre artefatos apresenta uma vantagem de

3%.

81

Figura 34. Média Harmônica.

5.4 Experimento 2

A finalidade do segundo experimento foi avaliar, no contexto de LPS, se as

informações de dependência de artefatos de implementação obtidas pela análise estática

de código afetam positivamente ou negativamente os resultados da análise de impacto de

mudanças no contexto de cenários de evoluções de remoção de característica. Abaixo é

apresentada a pergunta de pesquisa sendo explorada nesse experimento:

“A análise de impacto de mudanças para LPS utilizando, simultaneamente,

informações de mapeamento de características e informações de

dependência entre artefatos de implementação apresenta vantagens ao

estimar os impactos em uma operação de remoção de característica em

82

comparação com uma estratégia que considera apenas informações de

mapeamento de características?”

Para responder a pergunta de pesquisa proposta foi realizada uma avaliação

utilizando o Squid Impact Analyser em duas configurações: (i) a primeira considerou

informações de mapeamento de características juntamente com informações de

dependência de artefatos de implementação; enquanto (ii) a segunda contou apenas com as

informações de mapeamento de características. A ferramenta será executada utilizando a

LPS Mobile Media que foi adotada para a realização do experimento. No entanto, no

conjunto de evoluções do Mobile Media, não há casos de remoção de características, para

viabilizar o experimento foi realizada uma análise invertida da sequência de evoluções. A

cada evolução em que se inclui uma característica, analisamos a regressão dessa evolução

onde temos a remoção da característica, e assim é possível simular uma mudança de

remoção de característica. Portanto as evoluções analisadas entre a versão V3 e V7 são

V4-V3, V5-V4, V6-V5 e V7-V6.

5.4.1 Configuração do Experimento

Abaixo é apresentado o fluxo de etapas para a execução do experimento, que foi

executado para cada evolução do Mobile Media. Após a execução do fluxo de etapas

utilizando ambas estratégias, foi possível comparar os resultados das métricas calculadas.

1. Comparar o código da versão inicial com a versão final da evolução, e assim

determinar o CIR da evolução.

2. Analisar a evolução a fim de identificar as características removidas e incluí-las

no CS.

3. Executar a ferramenta de análise de impacto de mudanças utilizando como

entrada o CS obtido na etapa anterior. Ao final é gerado o CIE.

4. Comparar o CIE gerado pela ferramenta com o CIR, depois categorizar cada

artefato em CI, CFP e CFN.

5. Com os conjuntos computados na etapa anterior, calcular as métricas de

cobertura, precisão e média harmônica da ferramenta de análise de impacto de

mudanças.

83

5.4.2 Resultados e Avaliação do Experimento

Esta seção apresenta os resultados e a avaliação do experimento. Este experimento

focalizou a análise das evoluções de remoção de característica, neste caso o CIR é

composto dos artefatos modificados e removidos na evolução. Dado que estamos

analisando as evoluções invertidas do Mobile Media, para o CIR das evoluções inversas,

os artefatos removidos são equivalentes aos artefatos adicionados das evoluções

cronológicas. Por exemplo, conforme a Tabela 3 na evolução V4-V5 foram adicionados

78 artefatos, então a evolução inversa V5-V4 vai contabilizar a remoção de 58 artefatos. A

Tabela 10 apresenta o CIR calculado para as evoluções inversas.

Tabela 10. Conjunto de Impacto Real (CIR).

Tipo de

Artefato V4-V3 V5- V4 V6-V5 V7- V6

Conjunto de Impacto

Real

Classes 5 13 14 25

Métodos 10 49 46 75

Atributos 3 9 32 37

Fragmentos 7 7 12 36

Total 25 78 104 173

Após a execução da ferramenta passando como parâmetro as características a

serem removidas na evolução, é gerado o CIE para ambas as estratégias. A Tabela 11

apresenta o CIE para cada evolução do Mobile Media, a primeira parte da tabela apresenta

os resultados da estratégia orientada a análise de dependência de código, enquanto a

segunda parte apresenta os resultados obtidos pela estratégia não orientada à análise de

dependência de código. Nota-se que a estratégia orientada à análise de dependência de

código estimou mais artefatos para todas as evoluções.

84

Tabela 11. Conjunto de Impacto Estimado (CIE).

Estratégia Tipo de


Orientada a análise de

dependência de código

Classes 5 14 15 26

Métodos 12 57 50 89

Atributos 4 14 36 44


Total 27 91 112 205

Não orientada a análise de dependência de

código.

Classes 0 2 2 8

Métodos 5 35 34 57

Atributos 3 9 18 30


Total 14 48 65 118

Depois de executar a ferramenta, os artefatos contidos no CIE são comparados com

o CIR e contabilizados para gerar o CFN e o CFP. A Tabela 12 apresenta o detalhamento

da quantidade de falso-positivos e falso-negativos de cada estratégia. Observa-se que a

estratégia não orientada à análise de dependência de código não gerou falso-positivos,

pois todos os artefatos estimados pela ferramenta são provenientes do mapeamento com a

característica que será removida, e consequentemente são afetados mesmo que as

mudanças sejam apenas de remoções de diretivas de compilação condicional de código.

Em relação aos falso-negativos a estratégia orientada à análise de dependência de código

obteve uma quantidade menor de artefatos.

Tabela 12. Conjunto de Falso-Positivo (CFP) e Conjunto de Falso-Negativo (CFN).


FP FN FP FN FP FN FP FN

Orientada a análise de

dependência

de código.

Classes 0 0 2 1 1 0 3 2

Métodos 2 0 14 6 9 5 18 4

Atributos 1 0 6 1 7 3 12 5

Fragmentos 1 2 1 2 3 4 13 3

Total 4 2 23 10 20 12 46 14

Não orientada a

análise de dependência

de código.

Classes 0 5 0 11 0 12 0 17

Métodos 0 5 0 14 0 12 0 18

Atributos 0 0 0 0 0 14 0 7

Fragmentos 0 1 0 5 0 1 0 13

Total 0 11 0 30 0 39 0 55

85

O CI é apresentado na Tabela 13 e representa o conjunto de artefatos estimados

corretamente pela análise, o cálculo desse conjunto é obtido da comparação do CIR com o

CIE. No caso da estratégia não orientada à análise de dependência de código o CI é igual

ao CIE, pois não houve falso-positivos. Ao analisar e comparar os resultados de ambas

estratégias percebe-se que, apesar de apresentar mais falso-positivos, a estratégia

orientada à análise de dependência de código estimou mais artefatos corretamente.

Tabela 13. Conjunto Intersecção.


Orientada a análise de dependência de

código.

Classes 5 12 14 23

Métodos 10 43 41 71

Atributos 3 8 29 32

Fragmentos 5 5 8 33

Total 23 68 92 159

Não orientada a análise de

dependência de

código.

Classes 0 2 2 8

Métodos 5 35 34 57

Atributos 3 9 18 30


Total 14 48 65 118

O cálculo das métricas cobertura, precisão e média harmônica são realizados sobre

os dados dos conjuntos calculados anteriormente. O método de cálculo das métricas está

descrito na Seção 5.1. A Tabela 14 apresenta os resultados das métricas cobertura,

precisão e média harmônica da estratégia orientada à análise de código. Ao avaliar os

resultados da tabela observa-se que na maioria das evoluções o resultado das três métricas

ficou acima de 74%, havendo em média uma melhor taxa de cobertura em relação a

precisão.

86

Tabela 14. Métricas precisão e cobertura da estratégia orientada a análise de

dependência de código.


Precisão

Classes 100% 85.7% 93.3% 88.4%

Métodos 83.3% 75.4% 82% 79.7%

Atributos 75% 57.1% 74.3% 72.7%

Fragmentos 83.3% 83.3% 72.7% 71.7%

Total 85.1% 74.7% 82.1% 77.5%

Cobertura

Classes 100% 92.3% 100% 92%

Métodos 100% 87.7% 89.1% 94.6%

Atributos 100% 88.9% 90.6% 86.4%

Fragmentos 71.4% 71.4% 66.7% 91.6%

Total 92% 87.1% 88.4% 91.9%

Média Harmônica

Classes 100.00% 88.88% 96.53% 90.16%

Métodos 90.89% 81.09% 85.40% 86.51%

Atributos 85.71% 69.54% 81.64% 78.96%

Fragmentos 76.89% 76.89% 69.57% 80.44%

Total 88.42% 80.42% 85.13% 84.09%

Tabela 15. Métricas precisão e cobertura da estratégia não orientada a análise de

dependência de código.


Precisão

Classes 100% 100% 100% 100%

Métodos 100% 100% 100% 100%

Atributos 100% 100% 100% 100%

Fragmentos 100% 100% 100% 100%

Total 100% 100% 100% 100%

Cobertura

Classes 0% 15.4% 14.2% 32%

Métodos 50% 71.4% 73.9% 76%

Atributos 100% 100% 56.2% 81%

Fragmentos 85.7% 28.5% 91.6% 63.8%

Total 56% 61.5% 62.5% 68%

Média Harmônica

Classes 0.00% 26.69% 24.87% 48.48%

Métodos 66.67% 83.31% 84.99% 86.36%

Atributos 100.00% 100% 71.96% 89.5%

Fragmentos 92.30% 44.36% 95.62% 77.90%

Total 71.79% 76.16% 76.92% 80.95%

87

A Tabela 15 apresenta o resultado do cálculo das métricas cobertura, precisão e

média harmônica da estratégia não orientada à análise de código, nota-se que a precisão se

manteve em 100% por não apresentar nenhum falso-positivo. Em relação à cobertura

observa-se que a estratégia não orientada a análise de dependência de código obteve um

resultado inferior ao estimar os impactos de granularidade grossa, especificamente em

artefatos do tipo classe. Isso se deve ao fato de muitas classes não estarem diretamente

mapeadas com a característica, porém seus métodos e atributos estão mapeados. Esses

relacionamentos de hierarquia não são considerados utilizando apenas a análise de

rastreabilidade de características.

Figura 35. Taxas da métrica precisão.

A Figura 35 apresenta um diagrama de barras que demonstra a taxa de precisão

para as duas estratégias. Ao compararmos as estratégias é notável que a taxa de precisão

da estratégia não orientada a análise de dependência de código ficou em 100% para todas

as evoluções. Conforme explicado anteriormente, no caso da operação de remoção de uma

característica, as informações de mapeamento entre características e artefatos sempre

88

apontam artefatos que seguramente são impactados. A estratégia orientada a análise de

dependência de código apresentou uma taxa de precisão inferior, pois as estimativas

baseadas em dependências de código retornam uma parcela de falso-positvos entre os

resultados corretos.

A Figura 36 apresenta o diagrama de barras dos resultados da métrica de cobertura.

Ao analisar o gráfico nota-se que a estratégia orientada a análise de código apresentou

resultados superiores para todas as evoluções, ficando entre 87% e 92%. Enquanto para

estratégia não orientada a análise de código os resultados da métrica ficaram entre 56% e

68%. Como a estratégia orientada à análise de código também utiliza as informações de

características, a diferença da taxa de cobertura se deve aos artefatos impactados que são

obtidos por meio da análise de informações de dependência de código fonte. Em média a

estratégia que utiliza simultaneamente informações de mapeamento de características e

informações de dependência entre artefatos apresentar 27,8% a mais de cobertura.

Figura 36. Taxas da métrica cobertura.

89

Finalmente, a Figura 37 apresenta um diagrama de barras que compara os

resultados da métrica média harmônica de ambas as abordagens, conforme o gráfico nota-

se que a estratégia orientada a análise de código obter melhores resultados para todas as

revoluções avaliadas. A calcular a media da diferença de percentual da média a harmônica

a estratégia que utiliza simultaneamente informações de mapeamento de características e

informações de dependência entre artefatos apresenta uma vantagem de 8%.

Figura 37. Média Harmônica.

5.5 Ameaças à Validade do Experimento

Ameaças à validade do experimento são as variáveis que podem afetar os

resultados das métricas de cobertura, precisão e média harmônica, e dessa forma influir

nas considerações a respeito dos resultados obtidos. Nosso experimentou sofreu das

seguintes ameaças:

1. O cálculo do conjunto de impacto real entre as versões da LPS é realizado

manualmente com o apoio de uma ferramenta de diff textual, o que pode

90

acarretar em erros no cálculo do conjunto de impacto real devido ao fator

humano envolvido.

2. O sorteio do grupo sementes que foi utilizado na análise de impacto pode

também influenciar nos resultados obtidos, dependendo das sementes

sorteadas as métricas podem apresentar resultados variáveis. Dessa forma,

os resultados obtidos são coletados considerando um conjunto específico de

sementes. Assim, idealmente o experimento deveria considerar o sorteio

aleatório de várias sementes, fazer o cálculo de análise de impacto de

mudança para cada uma destas sementes e fazer uma análise dos valores

obtidos considerando as diferentes sementes (por exemplo, tirando uma

média dos valores obtidos para a análise de impacto de mudança).

5.6 Sumário

Neste capítulo foi apresentado um estudo de avaliação da ferramenta de análise de

impacto de mudanças proposta. Nossa avaliação utilizou implementações que refletem a

evolução da LPS Mobile Media para concepção de experimentos. Dois experimentos

foram apresentados, nos quais a ferramenta foi executada utilizando diferentes

configurações com o propósito de avaliar as estratégias de análise de impacto de

mudanças para LPS.

O primeiro experimento focalizou na análise da influência das informações de

características na análise de impacto de mudanças usadas em conjunto com informações

de dependência de código em contraposição a prover uma análise de impacto de mudança

baseada apenas nas informações de dependência. Os resultados indicaram que o uso de

informações de característica na análise de impacto de mudanças melhora a cobertura da

ferramenta, ao custo da diminuição da precisão.

O segundo experimento avaliou a influência na análise de impacto de mudanças de

informações de dependência de código em conjunto com informações de características

em contraposição a utilização apenas de informações de características. Tal estudo foi

conduzido considerando cenários de evoluções de remoção de características. Os

resultados do estudo indicaram que o uso de informações de dependência de código fonte

também melhora a cobertura da ferramenta, porém como efeito colateral, há a diminuição

da precisão da ferramenta. Em resumo, considerando a média harmônica que faz um

91

calculo que leva em consideração a cobertura e a precisão, a avaliação demonstrou que o

uso combinado de informações de rastreabilidade de características com informações de

dependência de código leva a uma melhora dos resultados de análise de impacto de

mudança. Essa melhora foi mais contundente no segundo experimento.

92

6 Trabalhos Relacionados

Este capítulo apresenta e confronta os trabalhos relacionados com os resultados do

trabalho proposto nesta dissertação. A Seção 6.1 discute a ferramenta AMPLE

Traceability Framework (ATF) proposta pelo consórcio AMPLE, que promove a

rastreabilidade entre artefatos de modelagem e implementação de LPS. A

Seção 6.2 apresenta a abordagem Emergent Interfaces proposta por (RIBEIRO et al.,

2011), a qual permite rastrear dependências entre características e artefatos de

implementação de compilação condicional. Finalmente, a Seção 6.3 descreve o trabalho

de (OLIVEIRA, 2011) que propõe uma abordagem para análise de impacto de mudanças

baseada em rastreabilidade.

6.1 AMPLE Traceability Framework

Um dos trabalhos relacionados ao tema desta dissertação é o AMPLE Traceability

Framework (ATF) (Anquetil et al., 2010), um framework dirigido por modelos para

rastreabilidade de artefatos. A proposta principal do ATF é oferecer suporte para

rastreamento de artefatos ao longo do ciclo de vida de desenvolvimento de LPS, através

do uso de técnicas de engenharia dirigida a modelos. O framework é flexível para permitir

adaptações para diferentes cenários de rastreabilidade em LPS.

A aplicação de técnicas de rastreabilidade de artefatos pode apresentar diversos

benefícios ao desenvolvimento de software como: (i) relacionar artefatos com as decisões

de projeto correspondentes; (ii) obter um retorno ao projetistas sobre o estado atual do

desenvolvimento; e (iii) facilitar o entendimento do projeto entre os envolvidos.

Para o contexto de LPS, os benefícios de técnicas de rastreabilidade podem ser

estendidos para suportar seus aspectos particulares, como por exemplo, identificar as

ligações entre artefatos produzidos na engenharia de domínio e engenharia de aplicação. A

análise dessas informações é fundamental para um melhor gerenciamento de

variabilidades de LPSs, auxiliando engenheiros de software a gerenciar o desenvolvimento

e a evolução dos artefatos da LPS.

O ATF foi estruturado como um framework orientado a objetos que define uma

infraestrutura de software que provê serviços de busca e armazenamento de ligações entre

93

artefatos. A flexibilidade da abordagem é fundamentada em um metamodelo de

rastreabilidade de referência e em um conjunto de pontos de extensão que permite criar

funcionalidades específicas para rastreabilidade em LPS.

Internamente o framework está organizado em quatro módulos extensíveis: (i)

TraceRegister, (ii) TraceStorage, (iii) TraceQuery e (iv) TraceView. O módulo

TraceRegister fornece mecanismos para criar, atualizar, remover e buscar as ligações entre

o modelo de características e os outros artefatos, enquanto o TraceStorage define

mecanismos para persistência das ligações entre os artefatos de LPS. O módulo

TraceQuery permite criar e realizar buscas específicas por ligações armazenadas.

Finalmente, o módulo TraceView tem como finalidade especificar representações visuais

de ligações entre artefatos de uma busca. Os módulos apresentados são compostos de

classes abstratas e interfaces para que os usuários do framework possam especificar

extratores, visualizadores e buscas especiais.

O metamodelo de rastreabilidade formaliza as entidades envolvidas no processo de

rastreabilidade: TraceableArtefact, TraceableArtefactType, TraceLink, TraceLinkType e

TraceContext. A entidade TraceableArtefact representa um artefato comum e esta

associado a um tipo definido pela entidade TraceableArtefactType que especifica um tipo

de artefato e suas propriedades. TraceLink corresponde a uma abstração da relação de um

artefato com outro(s) e está associado a um tipo definido pela entidade TraceLinkType.

Por fim, a entidade TraceContext expressa a justificativa da existência de um artefato ou

de uma relação entre artefatos, esta entidade é opcional.

O ponto de extensão para criar buscas sobre as informações de rastreabilidade

possibilita a construção de análises específicas que inferem em informações relevantes

para o desenvolvimento e controle da evolução de LPS. Como por exemplo, a análise da

cobertura de requisitos por características, a análise de impacto de mudanças e o

rastreamentos de variantes por produto. No caso da análise de impacto de mudanças, é

possível especular sobre quais serão os artefatos afetados após a alteração de um artefato,

com base nas informações de ligações (links) de rastreamento com outros artefatos

mantidos pelo ATF.

Como mencionado anteriormente o ATF é um framework para rastreabilidade de

artefatos LPS, o qual possibilita realizar diversas análises relativas às informações de

94

rastreabilidades, entre elas a análise de impacto de mudanças. Assim, pode-se dizer que

ATF não foi elaborado com o foco específico em análise de impacto de mudanças, mas

sim procura atender um escopo mais amplo de funcionalidades de rastreamento. Dessa

forma, por exemplo, a abordagem não prevê explicitamente a análise estática de código

com integração de ferramentas e frameworks específicos para tal fim, muito embora seja

possível usar as informações oferecidas por ela para alimentar a base de ligações de

rastreamento do ATF. Também não prevê um suporte especializado para análise da

interação entre características, este ponto é mencionado pelos autores como um possível

trabalho futuro.

Este trabalho de mestrado se diferenciar do framework ATF por apresentar uma

ferramenta de suporte a análise de impacto de mudanças, prevendo o tratamento explícito

de informações de análise estática de código e de análise de interação entre características.

Tanto a análise estática de código como a dependência entre características são usadas

para inferir o impacto de mudança de artefatos na LPS. Assim sendo, a abordagem

proposta neste trabalho está mais preparada para lidar com a análise de impacto de

mudanças em LPS que a proposta originalmente pelo ATF.

Por outro lado, a infraestrutura Squid proposta nesta dissertação tem diversos

pontos comuns com o framework ATF, já que ambos se propõem a gerenciar informações

de dependência de artefatos produzidos para uma LPS. Embora ambas as propostas

permitam o gerenciamento de informações de rastreamento entre os artefatos, a

infraestrutura Squid é orientada a análise de código de implementações de LPS em

combinação com informações de rastreamento de características, incluindo aquelas de

natureza de granularidade fina, tais como, as implementadas através de compilação

condicional.

6.2 Interfaces Emergentes

O trabalho de (Ribeiro et al., 2011) propõe uma ferramenta para oferecer 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). A

idéia principal da abordagem VSoC é reduzir a poluição no código causada pelas diretivas

de compilação condicional #ifdef e #endif. A estratégia consiste em ocultar os fragmentos

de código fonte das características sobre o qual o programador não está interessado em

95

trabalhar no momento, permitindo assim concentrar-se apenas no código das

características em que se está trabalhando. Apesar da modularização de código, que busca

organizar os fragmentos com o intuito de diminuir o acoplamento entre eles, estes

fragmentos podem compartilhar componentes de código comuns como variáveis e

método, havendo uma dependência entre os fragmentos. O uso da VSoC oculta essas

dependências entre fragmentos para o desenvolvedor, ao realizar uma modificação no

código fonte de uma característica, o desenvolvedor pode gerar erros que prejudicam o

funcionamento de um fragmento que implementa outra característica. Este tipo de situação

demanda muito tempo em atividades de inspeção do código dos demais fragmentos a

procura de erros propagados. Se o problema não for detectado previamente um erro latente

poderá ocorrer para determinadas configurações de produto.

O trabalho de (RIBEIRO et al., 2011) procura atacar o problema das dependências

entre fragmentos ocultados pela VSoC com uma ferramenta de auxilio ao desenvolvedor

durante as modificações de código. A ferramenta proposta é o CIDE EI2 (CIDE +

Emergent Interfaces), ela atua oferecendo suporte ao desenvolvedor, analisando o fluxo de

dados da LPS e informando 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.

O CIDE EI2 foi construído como uma extensão da ferramenta Colored Integrated

Development Environment (CIDE), que permite o gerenciamento de variabilidades

baseada na coloração de código. A ferramenta permite que programadores associem cores

aos elementos de código responsáveis pela implementação de uma dada variabilidade. Os

elementos de código são associados a nodos da AST da linguagem fonte e, internamente,

o CIDE agrega informações de características aos elementos da AST.

O CIDE EI2 utiliza o framework SOOT (VALL´EE-RAI et al., 1999) para

otimização e análise de código Java, capturando assim dependências entre elementos a

partir da AST. As informações da análise de dependências obtidas com SOOT são

cruzadas com as informações de características associadas à AST do CIDE. Dessa forma,

a ferramenta avisa ao programador quais os elementos de código de quais características

são impactados por uma mudança.

96

Apesar do CIDE EI2 oferecer benefícios para rastrear dependências entre

elementos de código que implementam as características, as análises de impacto obtidas

são pouco profundas. A abordagem utiliza apenas as informações de características e

elementos de código para a análise, não permitindo verificar os impactos para outros tipos

de artefatos. A ferramenta também não permite a parametrização das análises, assim como

não oferece ao desenvolvedor uma API para construir buscas específicas. O CIDE IE2 foi

construído para um contexto específico de LPS baseadas em compilação condicional e de

apoio a abordagem VSoC.

A abordagem desta dissertação difere de CIDE IE2 ao propor uma infraestrutura de

software para análise de impacto de mudanças e não uma ferramenta de caráter específico.

A infraestrutura proposta oferece uma API para desenvolvimento de análises de impacto

de mudanças específicas, possibilitando trabalhar com diferentes tipos de informação

associadas à modelagem da LPS. Além disso, ela também permite estender o modelo de

análise para aceitar outros tipos de informação de análise e não depende da técnica

utilizada para implementar variabilidades.

6.3 Análise de Impacto Baseada em Rastreabilidade para LPS

O trabalho de (OLIVEIRA, 2011) apresenta uma abordagem para a análise de

impacto de mudanças em LPS baseada em técnicas de rastreabilidade de artefatos. Ela

também provê uma ferramenta para a abordagem proposta e uma avaliação da análise de

impacto realizada. Na abordagem proposta, as informações de rastreabilidade são

utilizadas para apoiar a análise de impacto de mudanças, através da avaliação das

implicações de mudanças que ocorrem nos sistemas de software por meio dos seus

artefatos.

Esta abordagem oferece suporte para três tipos de artefatos: diagrama de casos de

uso, modelo de características e diagrama de classes. As informações extraídas dos

artefatos são associadas a um modelo de rastreabilidade, o qual foi definido com base no

metamodelo de rastreabilidade de artefatos proposto por (SOUZA et al., 2009). São

definidos três tipos de relação: (i) satisfatibilidade – um artefato A atende os requisitos de

B, por exemplo, as relações de satisfatibilidade entre características e classes, pois as

classes devem implementar a característica expressa pela característica; (ii) dependência –

expressam que um artefato A depende do artefato B se A invoca B, ou se uma mudança

97

em B reflete em A; (iii) evolução – podem acontecer entre classes, quando uma classe A

evolui para classe B. Isso implica que a classe A foi alterada para classe B durante a

evolução da LPS, geralmente ocorre entre versões diferentes da LPS.

Com base no modelo de rastreabilidade realiza-se a análise de impacto de

mudanças. A análise proposta está dividida em quatro etapas além de uma etapa final de

avaliação. A primeira etapa é “Analisar as Requisições de Mudança” na qual são

analisadas as mudanças propostas para a LPS no nível de documentação de casos de uso.

A atividade “Rastrear Potencial de Impacto” utiliza os resultados da atividade anterior

para estimar quais artefatos poderão sofrer mudanças, obtendo assim o impacto estimado.

Na atividade “Implementar Requisições de Mudança” são identificados os artefatos que

realmente são afetados pela execução das mudanças, resultando no impacto afetado. Por

fim, compara-se o impacto afetado com o impacto estimado com intuito de obter os falsos

positivos e os impactos não identificados. Após a análise de impacto de mudanças é

realizada uma avaliação dos resultados obtidos, na qual são aplicadas métricas para avaliar

se a análise de impacto foi bem sucedida ao estimar os artefatos alterados, calculando a

taxa de erro, taxa de acerto e a precisão da análise de impacto.

A ferramenta Satori foi construída para dar suporte a abordagem proposta. Ela foi

desenvolvida sob a plataforma Eclipse utilizando o EMF para extrair as informações dos

modelos de casos de uso, de classes e de características. Após a extração, o Satori exporta

as informações dos artefatos para uma instância do modelo de rastreabilidade em um

banco de dados relacional, o qual é encarregado de armazenar as informações de

rastreabilidade. A ferramenta também provê uma aplicação web para manipulação das

informações contidas no modelo de rastreabilidade, para simulação de mudanças nos

artefatos e para visualização dos resultados das métricas de avaliação.

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 de domínio e de

aplicação da LPS para auxiliar nessa atividade. Essa é uma desvantagem considerável,

pois a cada evolução da LPS, essas relações de rastreabilidade precisam ser atualizadas

para que a ferramenta funcione corretamente. Dentro do contexto de LPSs de larga escala,

esta atividade pode ser muito dispendiosa.

98

Por adotar modelos no quais os elementos de granularidade mais fina são as

classes, a abordagem não consegue lidar com situações onde há várias características

implementadas por uma mesma classe. Por exemplo, o Satori identifica uma mudança

realizada em uma determinada classe como impacto para todo o conjunto de

características associadas àquela classe, porém a modificação pode estar relacionada a

apenas uma das características associadas. Esse tipo de situação prejudica a precisão da

análise de impacto de mudanças inserindo muitos falsos positivos no resultado, esta

condição foi verificada no experimento apresentado.

Em relação a este trabalho de mestrado, (OLIVEIRA, 2011) realiza a análise de

impacto de mudanças apenas com base em informações de rastreabilidade de artefatos de

alto nível, não havendo nenhum tipo de análise de dependência de artefatos de código.

Conforme comentado anteriormente, o uso de tais informações de dependência de código,

pode ajudar a melhorar a previsão da análise de impacto de mudança. De forma similar a

(RIBEIRO et al., 2011), este trabalho não se preocupa em oferecer uma solução flexível

preparada para receber extensões que venham permitir aos engenheiros de LPS customizar

as estratégias de análise de impacto, de acordo com as suas necessidades.

99

7 Considerações Finais

Essa dissertação envolveu o projeto e implementação de uma infraestrutura de

software para a instanciação de ferramentas de análise de implementações de linhas de

produto de software, usando como base informações relacionadas as suas variabilidades

bem como dependências entre artefatos de código. A infraestrutura oferece pontos

flexíveis que podem ser concretizados para: (i) extração de informações de características

de artefatos de modelagem e implementação de LPS; (ii) extração de dependências de

artefatos de implementação; (iii) buscas sobre um modelo de análise que agrega as

informações extraídas dos artefatos da LPS; e (iv) visualizações específicas para os

resultados das buscas. A dissertação também apresentou implementações de referência dos

pontos de extensão providos pela infraestrutura.

Como forma de instanciação da infraestrutura Squid foi desenvolvida uma

ferramenta de análise de impacto de mudanças em LPS, denominada Squid Impact

Analyser. A ferramenta propõe um conjunto de estratégias de análise de impacto de

mudanças para o contexto de LPS implementadas na linguagem Java, fazendo uso

combinado de informações de características de LPS e de dependência de artefatos de

implementação. As informações de dependência de artefatos de implementação são

obtidas através de um módulo da infraestrutura Squid que realiza análise estática de

código fonte da LPS para extrair dependência entre elementos de implementação

incluindo trechos de código anotados com compilação condicional.

Finalmente, a dissertação também apresentou uma avaliação sistemática da

ferramenta Squid Impact Analyser, através da realização de experimentos de análise de

impacto de mudança no contexto de evolução da LPS Mobile Media. Foram realizados

dois experimentos, o primeiro focalizou a avaliação da influência do uso de informações

de características na análise de impacto de mudanças em LPS, enquanto o segundo

investigou a influência simultâneo de informações de mapeamento de características e

informações de dependência entre artefatos na análise de impacto de mudanças. Para a

avaliação e análise dos resultados foram adotadas métricas para análise de impacto de

mudanças. Os resultados dos experimentos de avaliação mostraram que:

100

(I). Em ambos experimentos nota-se que parte dos impactos de mudança estimados

corretamente é proveniente de informações de rastreabilidade de características,

enquanto a outra parte é proveniente de informações da análise estática de

código. Esse resultado demonstrou que o uso combinado de informações de

dependência entre artefatos de implementação e informações de mapeamento

de características nos artefatos da LPS, induzem a uma melhora da taxa de

cobertura da análise de impacto de mudanças, porém o seu efeito colateral foi

uma diminuição da taxa de precisão da análise.

(II). No caso de evolução de remoção de características de LPS, o uso de

informações de dependências contribuiu para o aumento na cobertura da análise

ao custo da redução na precisão da ferramenta.

(III). Os resultados do segundo experimento mostraram que, para o contexto da

análise de impacto de remoção de características, as informações de

rastreabilidade das características apontam artefatos que certamente sofrem

impactos de mudança para este tipo de evolução.

(IV). Os resultados da métrica média harmônica demonstram que o uso simultâneo

de informações de mapeamento de características e informações de

dependência entre artefatos na análise impacto de mudanças se reflete um

melhor resultado ao uso isolado dessas informações. A diferença pode ser

observada de forma mais contundente no experimento 2, no qual houve uma

diferença media de 8%.

7.1 Contribuições

A seguir apresentamos as contribuições diretas resultantes do desenvolvimento

deste trabalho:

(I). Projeto e implementação do Squid – uma infraestrutura de software extensível

para o desenvolvimento de ferramentas de análise de implementações de LPSs;

(II). Projeto e implementação da ferramenta Squid Impact Analyser que define

estratégias de análise de impacto de mudanças no contexto de evolução de

LPSs implementadas em Java;

(III). Avaliação das estratégias de impacto de mudança da ferramenta Squid Impact

Analyser no contexto de cenários de evolução da LPS Mobile Media, através do

101

desenvolvimento de experimentos de análise da cobertura, precisão e média

harmônica de tais estratégias;

(IV). Projeto e implementação de um módulo de extração para a plataforma Squid de

informações de modelos de características, conhecimento de configuração e

artefatos de implementação da ferramenta de derivação GenArch. Assim como,

extensão do GenArch para oferecer suporte para anotações de características

em atributos, métodos e trechos de código.

(V). Projeto e implementação de dois módulos de extração de informações de

dependência de artefatos de implementação, um baseado no DesignWizard e

um baseado no JDT/Eclipse. Sendo que este último foi implementado para

extrair informações de dependência entre trechos de código em variabilidades

de granularidade fina.

(VI). Modelo de análise extensível do Squid – que pode ser estendido para prover

diferentes tipos de análise ou promover o armazenamento e interoperabilidade

de informações de características, conhecimento de configuração e

dependências de artefatos de código no contexto de ferramentas de linhas de

produto de software.

7.2 Trabalhos Futuros

A seguir são apresentados trabalhos futuros que podem ser realizados como

desdobramentos desta dissertação:

(I). Estender a ferramenta Squid Impact Analyser para levar em consideração na

sua estratégia de análise também os tipos de características (opcionais, OR-

features e alternativos);

(II). Implementar novos visualizadores para a ferramenta Squid Impact Analyser

que permitam fazer consultas interativas sobre resultados informados da busca;

(III). Realizar novos estudos experimentais com o objetivo de avaliar o Squid Impact

Analyser no contexto de evolução de outras LPSs e também comparar seus

resultados com ferramentas industriais de análise de impacto de mudança;

(IV). A infraestrutura Squid e o modelo de análise podem ser estendidos para

acrescentar a manipulação de diversos tipos de informações relacionadas aos

requisitos, arquitetura e implementação da LPS, assim ampliando o escopo de

102

possibilidades de ferramentas de análise. Exemplos de análise que poderiam

ser desenvolvidas com a plataforma são: análise de impactos de mudanças em

casos de uso em LPS, rastreamento de requisitos ou componentes arquiteturais

em LPS, análises de inconsistências no conhecimento de configuração da LPS,

entre outros.

(V). Avaliar o uso do modelo de análise do Squid na interoperabilidade entre

ferramentas de modelagem de LPS. Em especial, comparar tal modelo com a

especificação da Variability Common Language (VCL) proposta recentemente

pela Object Management Group (OMG), que está sendo desenvolvida com tal

propósito;

(VI). Extensão do analisador de código fonte para incorporar outras informações de

análise como: tratamento de exceções, organização arquitetural da LPS,

anotações de casos de teste entre outros.

(VII). Realizar outros estudos experimentais (estudos de casos e experimentos

controlados) sobre a influência de outros tipos de informações de modelagem

(casos de uso, requisitos, regras de negócio entre outros) na análise de impacto

de mudanças em código-fonte.

103

REFERÊNCIAS

AJILA, S.A. Change Management: Modeling Software Product Lines Evolution. In Proceedings of the

6th World Multiconference on Systemics, pp.492-497, Cybernetics and Informatics, Orlando, Florida.

2002.

AJILA, S.A.; KABA, A.B. Using traceability mechanisms to support software product line evolution.

In The 2004 IEEE International Conference on Information Reuse and Integration (IEEE IRI-2004),

pp. 157–162, November 8–10, 2004, Las Vegas, NV, USA. 2004.

ANQUETIL, N.; GRAMMEL, B.; GALVÃO, I.; NOPPEN, J.; KHAN, S.S.; ARBOLEDA, H.;

RASHID, A.; GARCIA, A. Traceability for model driven, software product line engineering. In

Proceedings of the ECMDA Traceability Workshop (ECMDA-TW), pp.77–86. Sintef, Trondheim.

2008.

ANQUETIL, N·; KULESZA, U·; MITSCHKE, R.; MOREIRA, A.; ROYER, J.C.; RUMMLER, A.;

SOUSA, A. A model-driven traceability framework for software product lines. In Software and

Systems Modeling. 2010.

ANTONIOL, G.; CANFORA, G.; CASAZZA, G.; DE LUCIA, A.; MERLO, E. Recovering

Traceability Links between Code and Documentation. In IEEE Trans. Softw. Eng., pp. 970-983. 2002.

BAYER, J.; WIDEN, T. Introducing traceability to product lines. In Fourth International Workshop on

Product Family Engineering (PFE-4), pp.399-406. 2001.

BERG, K.; BISHOP, J.; MUTHIG, D. Tracing Software Product Line Variability - From Problem to

Solution Space. In Proceedings of the South African Institute of Computer Scientists and Information

Technologists (SAICSIT), pp.111-120. 2005.

BEUCHE, D. Modeling and Building Software Product Lines with pure::variants. In SPLC, pp.358.

IEEE Computer Society. 2008.

BINKLEY, D. Source Code Analysis: A Road Map. In Proceedings of the 2007 Future of Software

Engineering (FOSE '07), pp.104-119. 2007.

BRUNET, J.; GUERRERO, D.; FIGUEIREDO, J. Design Tests: An Approach to Programmatically

Check your Code Against Design Rules. In Proceedings of the 31st International Conference on

Software Engineering (ICSE 2009), New Ideas and Emerging Results, Vancouver, Canada. 2009.

104

BRUNETON, E.; LENGLET, R.; COUPAYE, T. ASM: A code manipulation tool to implement

adaptable systems. In Proceedings of Adaptable and extensible component systems. 2002.

BUDINSKY, F.; STEINBERG, D. et al. Eclipse Modeling Framework, Addison-Wesley. 2003.

BURCH, E.; KUNG, H. Modeling Software Maintenance Requests: A Case Study. In Proceedings

IEEE Int"l Conf. Software Maintenance, pp. 40-47. 1997.

BURN, O. Checkstyle. Disponível em: http://checkstyle.sourceforge.net. Acesso em: 22 de novembro

de 2011.

CHASTEK, G.; DONOHOE, P.; MCGREGOR, J. D. A Study of Product Production in Software

Product Lines. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. 2004.

CIRILO, E. GenArch: “Uma Ferramenta Baseada em Modelos para Derivação de Produtos de

Software”. Dissertação (Mestrado em Informática) - Pontifícia Universidade Católica do Rio de

Janeiro, Rio de Janeiro. 2008.

CLELAND-HUANG J.; BERENBACH B.; CLARK S.; SETTIMI R.; ROMANOVA E. Best practices

for automated traceability. In IEEE Comp., pp.27–35. 2007.

CLEMENTS, P.; NORTHROP, L. Software Product Lines: Practices and Patterns. Addison-Wesley,

Boston, MA, USA. pp.563. 2002.

COHEN, S., Product Line State of the Practice Report. Technical Note CMU/SEI-2002-TN-017,

Carnegie Mellon University, Software Engineering Institute. 2002

COLE, B.; HAKIM, D.; HOVEMEYER, D.; LAZARUS, R.; PUGH, W.; STEPHENS, K. Improving

your software using static analysis to find bugs. In Companion to Proceedings of OOPSLA'06, pp.673-

674. 2006.

COLYER, A. Eclipse AspectJ: Aspect-Oriented Programming with AspectJ and the Eclipse AspectJ

Development Tools, Addison-Wesley. 2004.

COPELAND, T. PMD Applied. Centennial Books, November. 2005.

CUSUMANO, M.A.; SELBY R.W. Microsoft Secrets. Simon & Schuster, New York. 1998.

CZARNECKI, K.; EISENECKER, U. W. Generative Programming: Methods, Tools, and

Applications. Boston: Addison-Wesley. 2000.

105

D’ANJOU, J.; FAIRBROTHER, S.; KEHN, D. et al. The Java developer’s guide to eclipse. Addison-

Wesley. 2005.

DEELSTRA, S.; SINNEMA, M.; BOSCH, J. Product derivation in software product families; a case

study. In Journal of Systems and Software, pp. 173–194. 2005.

DHUNGANA, D.; NEUMAYER, T.; GRUENBACHER, P.; RABISER, R. Supporting the Evolution

of Product Line Architectures with Variability Model Fragments. In Proceedings of the Seventh

Working IEEE/IFIP Conference on Software Architecture (WICSA 2008), p.327-330, February 18-21.

2008.

DONOHOE, P. Software Product Lines: Experience and Research Directions. Kluwer, Dordrecht,

Netherlands. 2000.

ECLIPSE FOUNDATION. Java Development Tools. URL:

http://www.eclipse.org/jdt/ui/astview/index.php. Acesso em: 18 de março de 2012.

ECLIPSE FOUNDATION. Abstract Syntax Tree View. URL:

http://www.eclipse.org/jdt/ui/astview/index.php. Acesso em: 18 de março de 2012.

ERNST, M.D. Static and dynamic analysis: synergy and duality. In Proceedings of WODA’2003

(ICSE Workshop on Dynamic Analysis), Portland. 2003.

FIGUEIREDO, E. et al. Evolving software product lines with aspects: an empirical study on design

stability. In Proceedings of the 30th International Conference on Software engineering, May 10-18,

Leipzig, Germany. 2008.

FILMAN, R. et al. Aspect-Oriented Software Development. Addison-Wesley. 2005.

GODFREY, M.W.; GERMAN, D.M.; The past, present, and future of software evolution. In 24th Intl.

Conf. Software Maintenance. 2008.

GOTEL, O.C.Z.; FINKELSTEIN A.C.W. An analysis of the requirements traceability problem. In

Proceedings of the 1st Int. Conference on Requirements Engineering (ICRE), pp.94–101, Colorado

Springs. 1994.

HAASE, A.; VÖLTER, M.; EFFTINGE, S.; KOLB, B. Introduction to openArchitectureWare 4.1.2.

In Model-Driven Development Tool Implementers Forum (co-located with TOOLS 2007). 2007.

106

HATTORI, L.; GUERRERO, D.; FIGUEIREDO, J. On the Precision and Accuracy of Impact

Analysis Techniques. In Proceedings of the 7th IEEE International Conference on Computer and

Information Science. Washington, DC, USA: IEEE Computer Society, 2008.

HAYES, J.H., DEKHTYAR A., OSBORNE J. Improving Requirements Tracing via Information

Retrieval. In Proceedings of the 11th IEEE International Requirements Engineering Conference,

Monterey. 2003.

JIRAPANTHONG, W.; ZISMAN, A. Supporting Product Line Development through Traceability. In

Proceedings of the 12th Asia-Pacific Software Engineering Conference (APSEC 2005),Taiwan. 2005.

KANG, K.; COHEN, S.; HESS J.; NOWAK W.; PETERSON S. Feature-Oriented Domain Analysis

(FODA) Feasibility Study. Technical Report, CMU/SEI-90-TR-21, In Software Engineering Institute,

Carnegie Mellon University, Pittsburgh, PA, November. 1990.

KHAN, S. S. et al, “Usecases for MobileMedia Application”.

URL: http://www.comp.lancs.ac.uk/~shakilkh/MMData/docs/MMusecases.pdf. Acesso em: 3 de maio

de 2010.

KRUEGER, C. BigLever software gears and the 3-tiered SPL methodology. In Proceedings of the

Conference on Object Oriented Programming Systems Languages and Applications (OOPSLA’07),

ACM, pp. 844–845, Montreal, Quebec, Canada. 2007.

KRUEGER, C.W. Easing the Transition to Software Mass Customization, Revised Papers from the

4th International Workshop on Software Product-Family Engineering, p.282-293. 2001.

LINDEN, F.; SCHMID, K.; ROMMES, E. Software Product Lines in Action: The Best Industrial

Practice in Product Line Engineering. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2007.

MAIA, M.C.O.; BITTENCOURT, R.A.; DE FIGUEIREDO, J.C.A.; GUERRERO, D.D.S.; The

Hybrid Technique for Object-Oriented Software Change Impact Analysis. In Software Maintenance

and Reengineering (CSMR), Madrid, Spain. 2011.

MATOS, P. Analisys of Techniques for Implementing Software Product Lines Variabilities.

Dissertação de mestrado, Universidade Federal de Pernambuco, Recife, Brasil. 2008.

MATZEN, M. Testing, Profiling and Monitoring using Eclipse with the Test & Performance Tools

Platform Project. Seminar Eclipse Technologien. 2009.

MITSCHKE, R.; EICHBERG, M. Supporting the evolution of software product lines. In Proceedings

Traceability Workshop (ECMDA-TW), pp. 87–96. 2008.

107

OpenUP. OpenUP Process. URL: http://www.eclipse.org/epf/. Acesso em: 29 de novembro de 2011.

PAULK, M. C.; WEBER, C. V.; CURTIS, B.; CHRIS- SIS, M. B. The Capability Maturity Model-

Guidelines for Improving the Software Process. Addison-Wesley, Reading, MA. 1997.

PINHEIRO, F. Formal and Informal Aspects of Requirements Tracing. Position Paper In Proceedings

of 3rd Workshop on Requirements Engineering (III WER), Rio de Janeiro. 2000.

POHL, K.; BÖCKLE, G. et al. Software Product Line Engineering: Foundations, Principles and

Techniques, Springer, 2005.

PRESSMAN, R.S. Engenharia de software, 6a edição. Mcgraw Hill. 2006.

PUSSINEN, M. A Survey of Software Product-Line Evolution. Technical Report, Tampere University

of Technology. 2002.

RIEBISCH, M. Supporting evolutionary development by feature models and traceability links. In

Proceedings of the 11th International Conference on Engineering of Computer-Based Systems

(ECBS), pp. 370–377, Brno, Czech Republic, May. 2004

SCHACH, S.R.; TOMER, A. Development/Maintenance/Reuse: Software Evolution in Product Lines.

In Proceedings of the First Software Product Line Conf., pp. 437-450. 2000.

SEI - Software Engineering Institute. A framework for software product line practice, version 5.0.

Pittsburgh. Disponível em: http://www.sei.cmu.edu/productlines/frame_report/PL.essential.act.htm.

Acesso em: 29 de novembro de 2011.

SOMMERVILLE, I. Engenharia de Software. Harlow, UK, Addison-Wesley. 2007.

SOUSA, A.; KULESZA, U.; RUMMLER, A.; ANQUETIL, N.; MOREIRA, R.M.A.; AMARAL, V.;

ARAÚJO, J.A. A model-driven traceability framework to software product line development. In

Proceedings of the ECMDA Traceability Workshop (ECMDA-TW) 2008, pp. 97–109. Sintef,

Trondheim. 2008.

SOUZA, S.; ANQUETIL, N.; OLIVEIRA, K.M. A Study of the Documentation Essential to Software

Maintenance. In Proceedings of the International Conference on Design of Communication:

Documenting and Designing for Pervasive Information, pp. 68-75. 2005.

SPANOUDAKIS, G.; ZISMAN, A. Software Traceability: A Roadmap, Handbook of Software

Engineering and Knowledge Engineering, Vol. III: Recent Advancements, Chang S. K., World

Scientific Publishing. 2005.

108

SVAHNBERG, M.; BOSCH, J. Characterizing evolution in product-line architectures. In Proceedings

of the 3rd International Conference on Software Engineering and Applications (IASTED). 1999.

SVAHNBERG, M.; BOSCH, J. Evolution in Software Product Lines. Journal of Software

Maintenance–Research and Practice, pp.391–422. 1999.

TEIXEIRA, L.; ROHIT G.; BORBA, P. Safe Composition of Configuration Knowledge-based

Software Product Lines. In 25th Brazilian Symposium on Software Engineering (SBES). 2011.

VALL´EE-RAI, R.; CO, P.; GAGNON, E.; HENDREN, L.; LAM, P.; SUNDARESAN, V. Soot - a

java bytecode optimization framework. In Proceedings of CASCON’99. IBM Press. 1999.

YOUNG, T. Using AspectJ to Build a Software Product Line for Mobile Devices. Dissertação.

University of British Columbia, 2005.

109

ANEXO I

Este anexo contém as figuras dos modelos de características a partir da versão 3 do

Mobile Media.


110


111


112



113


SQUID IMPACT ANALYSER: UMA FERRAMENTA PARA ANÁLISE … · de métricas de cobertura, precisão e...

Documents

Transcript of SQUID IMPACT ANALYSER: UMA FERRAMENTA PARA ANÁLISE … · de métricas de cobertura, precisão e...