Programa Multiinstitucional de Pós-Graduação em Ciência
da Computação- PMCC
VISUALIZANDO EVOLUÇÃO DE SOFTWARE EM
DETALHES
Por
Renato Lima Novais
Tese de Doutorado
SALVADOR Agosto/2013
RENATO LIMA NOVAIS
VISUALIZANDO EVOLUÇÃO DE SOFTWARE EM
DETALHES
Tese de Doutorado apresentada ao Programa Multiinstitucional de Pós-Graduação em Ciên-cia da Computaçãoda Universidade Federal da Bahia, Universidade Salvador e Universidade Estadual de Feira de Santana como requisito parcial para obtenção do grau de Doutor em Ciência da Computação.
Orientador: Manoel Gomes de Mendonça Neto
SALVADOR
Agosto/2013
Ficha catalográfica elaborada pela Biblioteca da UFBA, Instituto de Matemática
Novais, Renato Lima S111d
Visualizando Evolução de Software em Detalhes /Renato Lima Novais. – Salvador, 2013.
164p. : il.
Orientador: Prof. Dr. Manoel Gomes de Mendonça Neto.
Tese (doutorado) – Universidade Federal da Bahia, Instituto de Matemática, Programa Multiinstitucional de Pós-Graduação em Ciência da Computação, 2013.
1. Visualização de Software 2. Evolução de Software. 2. Estratégias de Análise Visual. I. Neto, Manoel Gomes de Mendonça. II. Universidade
Federal da Bahia. Instituto de Matemática. III Título.
TERMO DE APROVAÇÃO
RENATO LIMA NOVAIS
VISUALIZANDO EVOLUÇÃO DE SOFTWARE EM DETALHES
Esta tese foi julgada adequada à obtenção do título de Doutor em Ciência da Computação e aprovada em sua forma final pelo Programa Multiinstitucional de Pós-Graduação em Ciência da Computação da UFBA-UEFS-UNIFACS.
Salvador, 05 de Agosto de 2013
Professor e orientador Manoel Gomes de Mendonça Neto, Ph.D. Universidade Federal da Bahia - UFBA
Professor Alessandro Fabricio Garcia, D.Sc.
Pontifícia Universidade Católica do Rio de Janeiro - PUC-RIO
Professora Christina von Flach Garcia Chavez, D.Sc. Universidade Federal da Bahia - UFBA
Professor Cláudio Nogueira Sant’Anna, D.Sc. Universidade Federal da Bahia - UFBA
Professor Leonardo Gresta Paulino Murta, D.Sc. Universidade Federal Fluminense - UFF
Agradecimentos
É chegado o momento de conclusão de uma importante etapa em minha vida. O percurso desta jornada foi, sem dúvidas, bastante intenso e prazeroso. Para concluí-lo foi necessário muito esforço, empenho, insistência, abdicação e também ajuda de muitas pessoas.
Em primeiro lugar gostaria de agradecer a Deus, por iluminar-me e permitir-me chegar neste momento.
Gostaria de agradecer também a minha esposa, Indira Gomes, que me acompanhou e me deu força durante todos estes anos. Ela viveu cada momento, cada dificuldade enfrentada, e se empenhou para me ajudar a superar todos os desafios. Meu amor, muito obrigado por tudo.
Muitas pessoas contribuíram para a construção deste trabalho. Meu muito obrigado ao meu orientador Manoel Mendonça. Uma pessoa fantástica, com o qual aprendi muitas coisas, que vão muito além da formação acadêmica propiciada por um trabalho de doutorado. Gostaria também de agradecer meus amigos do LES, companheiros das incertezas e das conquistas durante estes anos. Em especial ao companheiro, tanto de doutorado quando de trabalho, Thiago Souto, que me ajudou bastante neste processo. A Ivan Machado, que também contribuiu muito, principalmente nas aventuras latexianas. A Ivonei Freitas, pelas conversas nas quais compartilhávamos nossos desafios e incertezas. A vocês quero deixar meus sinceros agradecimentos.
Na construção de uma tese de visualização de software, muita implementação é necessária. Eu quero agradecer aos alunos de iniciação científica e trabalho de conclusão de curso que me ajudaram na implementação do ambiente desenvolvido nesta tese: Paulo Simões Jr, Caio Lima, David Pinho.
Gostaria de agradecer também as diversas pessoas que contribuíram para a realização das diversas atividades desta tese. Pessoas que participaram das diversas reuniões de grupo, discutindo as ideias surgidas ao longo da construção deste trabalho. Pessoas que participaram de experimentos, para validação das propostas aqui apresentadas. Aos professores pesquisadores que deram feedback do andamento do trabalho.
Observe quem vai subindo a ladeira, seja princesa ou seja lavadereira, para ir mais alto vai ter que suar.
Resumo
Evolução do software tem sido destacada como um dos temas mais importantes em engenharia e manutenção de software. Durante a evolução do software, os engenheiros de software precisam compreender uma grande quantidade de dados. Visualização de Software é a área da engenharia de software que tem como objetivo ajudar as pessoas a entender o software através do uso de recursos visuais, e pode ser efetivamente usada para analisar e compreender a grande quantidade de dados produzidos durante a evolução do software. Um grande desafio da área é criar estratégias para visualizar combinadamente muitas versões, muitos módulos (pacotes, classes e métodos) e muitos atributos (e.g. métricas) de software.
As visualizações de evolução de software (VES) propostas atualmente procuram, quase sempre, apresentar os dados de forma global, incluindo todas as versões disponíveis, mostrando informações genéricas sobre o processo de evolução, sem ter acesso aos módulos do software. Entretanto, a maior parte das tarefas de engenharia de software requer o acesso aos módulos em questão, analisando o software em detalhes. Além disso, analisar todas as versões ao mesmo tempo, vai de encontro com o estado da prática, o qual, geralmente, foca na diferenciação entre duas versões sequenciais, ou, em menor quantidade, no entendimento de um número maior, porém controlável, de versões.
Esta tese explora a visualização da evolução do software em detalhes. Para este fim, ela mapeia a área, define uma abordagem e apresenta uma infraestrutura computacional para VES. Esta infraestrutura faz uso combinado de estratégias diferenciais e de estratégias temporais detalhadas, em contraposição as abordagens temporais globais normalmente utilizadas na literatura. Este trabalho contribui através do desenvolvimento de uma abordagem para VES que combina versões, módulos e atributos de software de forma controlada e coordenada. Controlada pelo fato de não mostrar todas as versões ao mesmo tempo, permitindo a análise detalhada dos módulos e seus atributos. Coordenada pelo fato de combinar estratégias complementares que interagem entre si para facilitar a compreensão do software em detalhes, adicionando assim valor ao estado da arte em VES.
O desenvolvimento da infraestrutura para dar suporte à esta abordagem foi incremental e iterativo. A cada fase, procurou-se realizar estudos experimentais com o objetivo de avaliar a abordagem desenvolvida. Os resultados indicam que a abordagem proposta pode ser utilizada para apoiar de forma efetiva a realização de atividades de análise de evolução de software.
Palavras-chave: Visualização de Software, Visualização de Evolução, Estratégias de Análise Visual.
Abstract
Software Evolution has been highlighted as one of the most important topics in software engi-neering and maintenance. During software evolution, software engineers need to comprehend lots of data. Software Visualization is the area of software engineering that aims to help users to understand the software through the use of visual resources, and can be effectively used to analyze and understand the large amount of data produced during the software evolution. A key challenge of the area is to create strategies to visualize many versions, many modules (packages, classes and methods) and many software attributes (e.g. metrics).
Currently software evolution visualization (SEV) approaches seek almost always to pre-sent the data as a whole, including all available versions, showing general information about the evolution process without having access to software modules. However, most software engineering tasks require access to the modules in question, analyzing the software in detail. Furthermore, analyzing all versions at the same time, opposes to the state of the practice, which usually focuses on the distinction between two sequential versions, or to a lesser extent, on understanding a greater, but controllable, number of versions.
This thesis explores the software evolution visualization in detail. To this end, it maps the area, defines an approach and presents an infrastructure for SEV. This infrastructure makes combined use of Differential Strategies and Temporal Overview in detail strategies, as opposed to purely Temporal Overview approaches commonly used in the literature. This work contributes through the development of a SEV approach that combines versions, modules and software attributes in a controlled and coordinated manner. Controlled by the fact that it do not show all versions at the same time, allowing detailed analysis of the modules and their attributes. Coordinated by the fact that it combines complementary strategies that interact themselves to facilitate the understanding of the software in detail, thus adding value to the state of the art in SEV.
The infrastructure’s development to support this approach was built incrementally and iteratively. At each stage, we tried to carry out experimental studies to evaluate the developed approach. The results indicate that the proposed approach can be used to effectively support software evolution analysis tasks.
Sumário
Lista de Figuras xxi
Lista de Tabelas xxiii
Lista de Acrônimos xxv Capítulo 1—Introdução 1 1.1 Contexto . . . 1 1.2 Motivação . . . 3 1.3 Apresentação do Problema . . . 5 1.4 Objetivos . . . 7 1.5 Trabalho Desenvolvido . . . 8 1.6 Contribuições . . . 13 1.7 Organização da Tese . . . 14
Capítulo 2—Referencial Teórico 15 2.1 Evolução de Software . . . 16
2.2 Visualização de Software . . . 18
2.2.1 Tipos de Visualização de Software . . . 21
2.3 Visualização de Evolução de Software . . . 22
2.4 Diffs . . . 27
2.5 Conclusão do Capítulo . . . 28
Capítulo 3—Estratégias de Análise de Evolução de Software 29 3.1 Estratégias Temporais . . . 30
3.1.1 Temporal Overview – TO . . . 30
3.1.2 Temporal Snapshot – TS . . . 32
3.1.3 Temporal Snapshot Acumulativa – TA . . . 33
3.2 Estratégias Diferenciais . . . 34
3.2.1 Estratégia Diferencial Absoluta – DA . . . 35
3.2.2 Estratégia Diferencial Relativa – DR . . . 37
3.3 Combinação de Estratégias . . . 38
Capítulo 4—Um Mapeamento Sistemático em Visualização de Evolução de Software 41
4.1 Processo Utilizado no Mapeamento Sistemático . . . 41
4.1.1 Questões de pesquisa . . . 41
4.1.2 Conduzindo a busca por estudos primários . . . 42
4.1.3 Esquema de classificação . . . 43
4.2 Resultados. . . 43
4.2.1 Objetivos das VES propostas . . . 44
4.2.2 Perspectivas utilizadas pelas VES propostas . . . 47
4.2.3 Estratégias visuais de análise de evolução de software . . . 50
4.2.4 Avaliação das propostas de VES . . . 51
4.3 Discussão . . . 52
4.4 Conclusão do Capítulo . . . 55
Capítulo 5—Um Ambiente Visual Multi-Estratégia de Evolução de Software 57 5.1 Origem do SME . . . 58
5.2 A Infraestrutura do SME . . . 61
5.2.1 Extrator e Analisador . . . 62
5.2.2 Visualizador . . . 63
5.3 SourceMiner Evolution - SME . . . 63
5.3.1 Componentes do SME . . . 64 5.3.1.1 Fonte de Dados . . . 64 5.3.1.2 Métricas . . . 64 5.3.1.3 Visões . . . 65 5.3.1.4 Perspectivas . . . 69 5.3.1.5 Estratégias de Análise . . . 70 5.3.1.6 Mecanismos de Interação . . . 71
5.3.2 Um exemplo do SME em ação . . . 72
5.4 Processo de Desenvolvimento e Avaliação do Ambiente . . . 74
5.4.1 Evoluindo e Avaliando o Ambiente . . . 75
5.5 Conclusão do Capítulo . . . 76
Capítulo 6—Desenvolvendo e Avaliando a Estratégia Diferencial Relativa 79 6.1 A Estratégia Diferencial Relativa no SME . . . 79
6.1.1 Modelando a estratégia Diferencial Relativa no SME . . . 79
6.1.1.2 Interpolação Discreta de Cores . . . 81
6.1.1.3 Processo de Funcionamento da Estratégia Diferencial Relativa 83 6.1.2 Instanciação da Estratégia Diferencial Relativa . . . 84
6.1.3 Atacando tarefas de Engenharia de Software através da Estratégia Dife-rencial Relativa . . . 86
6.1.4 Lidando com as limitações dos thresholds . . . 87
6.2 Um Estudo Exploratório de Viabilidade para Avaliar a Estratégia Diferencial Relativa do SME (Estudo 1) . . . 90
6.2.1 Descrição do Estudo . . . 90
6.2.2 Consequências do Estudo . . . 93
6.3 Um Estudo Exploratório Observacional para Avaliar a Estratégia Diferencial Relativa (Estudo 2) . . . 93
6.3.1 Descrição do Estudo . . . 94
6.3.2 Consequências do Estudo . . . 95
6.4 Conclusão do Capítulo . . . 95
Capítulo 7—Desenvolvendo e Avaliando a Estratégia Diferencial Absoluta 97 7.1 A Estratégia Diferencial Absoluta do SME . . . 97
7.1.1 Modelando a estratégia Diferencial Absoluta do SME. . . 97
7.1.1.1 Representação Discreta de Cores . . . 98
7.1.1.2 Processo de Funcionamento da Estratégia Diferencial Absoluta 98 7.1.2 Instanciação da Estratégia Diferencial Absoluta . . . 100
7.1.3 Atacando tarefas de Engenharia de Software através da Estratégia Dife-rencial Absoluta . . . 103
7.2 Um Experimento Controlado para Avaliar a Estratégia Diferencial Absoluta (Estudo 3) . . . 104
7.2.1 Descrição do Estudo . . . 104
7.2.2 Consequências do Estudo . . . 115
7.3 Conclusão do Capítulo . . . 116
Capítulo 8—Desenvolvendo e Avaliando a Estratégia Temporal Overview Detalhada 117 8.1 A Estratégia Temporal Overview do SME . . . 117
8.1.1 Modelando a estratégia Temporal Overview Detalhada do SME . . . . 117
8.1.1.1 Representação da Temporalidade . . . 118
8.1.2 Instanciação da Estratégia Temporal Overview . . . 120
8.1.3 Atacando tarefas de Engenharia de Software através da Estratégia Tem-poral Overview instanciada. . . 120
8.2 Replicação do Experimento Controlado (Estudo 3) para Avaliar a Combinação de Estratégias (Estudo 4) . . . 121
8.2.1 Descrição do estudo . . . 122
8.2.2 Consequências do Estudo . . . 128
8.3 Conclusão do Capítulo . . . 129
Capítulo 9—Considerações Finais 131 9.1 Contribuições desta Tese . . . 132
9.2 Limitações. . . 133
9.3 Trabalhos em Andamento e Futuros . . . 134
9.3.1 Trabalhos em Andamento . . . 134
9.3.2 Trabalhos Futuros . . . 135
Apêndices 150 A Mapeamento Sistemático em Visualização de Evolução de Software - Lista de Es-tudos Primários 153 A.1 Lista de Estudos Primários . . . 153
Lista de Figuras
1.1 Dois exemplos da visão Project Explorer do Eclipse. . . 3
1.2 Diferentes versões de um mesmo projeto no Project Explorer do Eclipse. . . . 6
1.3 Um exemplo de uma ferramenta de diff. . . 7
1.4 Trabalho desenvolvido durante esta tese. . . 9
2.1 Um exemplo do potencial dos recursos visuais. . . 18
2.2 Um exemplo de visualização de software. Extraído de (Wettel et al., 2011). . . 19
2.3 Um exemplo de visualização de evolução de software. Extraído de (Ball and Eick, 1996). . . 23
2.4 Algumas características da Matriz de Evolução. Extraído de (Lanza, 2001). . . 24
2.5 CodeTimeline mostrando a linha do tempo um projeto. Extraído de (Kuhn and Stocker, 2012). . . 25
3.1 Dois exemplos de visões utilizando a Estratégia Temporal Overview, extraídas de (Voinea and Telea, 2006b) e (Lungu et al., 2010), respectivamente. . . 31
3.2 Alguns exemplos de visões usando a estratégia Temporal Snapshot, adaptado de (Beyer and Hassan, 2006) e (D’Ambros et al., 2009), respectivamente. . . 33
3.3 Um exemplo de visão utilizando a Estratégia de visualização Temporal Snapshot Acumulativa, adaptado a partir de (Wu et al., 2004b). . . 34
3.4 Exemplos de estratégia Diferencial Absoluta que mostra a Comparação da Arquitetura (a) e uma visão da Evolução Comportamental (b), adaptado a partir de (Tu and Godfrey, 2002) e (Bergel et al., 2011), respectivamente. . . 36
4.1 Facetas de classificação do mapeamento sistemático (Novais et al., 2013). . . . 43
4.2 Número de estudos versus o quê as abordagens VES visualizam. . . 47
4.3 Número de estudos por propósito da abordagem de VES. . . 49
4.4 Número de estudos por perspectivas comuns encontradas no estudo. . . 49
4.5 Número de estudos por estratégias. . . 51
4.6 Número de estudos por tipo de avaliação. . . 52
4.7 Número de estudos de viabilidade por tipo e quantidade de projeto. . . 53
5.1 SourceMiner: um ambiente visual multi-perspectiva. . . 59
5.2 Principais componentes da infraestrutura do SME.. . . 62
5.4 O SME em ação. . . 72
5.5 Processo de desenvolvimento e avaliação do SME. . . 75
6.1 Cores utilizadas pela coloração Tonal Contínua da Estratégia DR. . . 80
6.2 Cores utilizadas pela coloração Tonal Discreta da Estratégia DR. . . 82
6.3 Funcionamento geral e visões da estratégia diferencial relativa. . . 83
6.4 SME Diferencial em ação. . . 86
6.5 Exemplos de evolução nas árvores de herança. . . 88
6.6 Exemplos de evolução nos acoplamentos. . . 88
6.7 Seis cenários de análise da evolução do MobileMedia.. . . 91
7.1 Cores utilizadas pela Estratégia Diferencial Absoluta para análise da evolução de features. . . 98
7.2 Funcionamento geral, visões e cores da Estratégia Diferencial Absoluta. . . 99
7.3 Arquivo diff_MobileMedia02_MobileMedia03 com a diferença entre as versões MobileMedia02 e MobileMedia03. . . 100
7.4 Visões e interações do SME feature. . . 101
7.5 SME feature mostrando o diff entre versão 1 e versão 2. . . 103
7.6 Visão geral do funcionamento do SME Feature com as heurísticas. . . 105
7.7 Média de conhecimento dos participantes. . . 107
7.8 Tempo do participante x tarefa. . . 111
7.9 Visão geral da corretude por tarefa. . . 113
8.1 Funcionamento geral e visões da estratégia Temporal Overview. . . 119
8.2 Visão geral do funcionamento do SME Feature com as heurísticas e a visão Timeline Matrix. . . 122
8.3 Experiência dos participantes, considerando: a) cada site individualmente, e b) todos em conjunto. . . 124
8.4 Tempo das atividade AT4 e AT5 em todos os experimentos. . . 128
9.1 SME: Radar de Evolução.. . . 135
9.2 SME: visualização de colaboradores no projeto. . . 136
9.3 SME: visualização de Code Smells no projeto. . . 136
Lista de Tabelas
3.1 Métricas (M) e features (F) de cinco versões (Vi) de módulos de software (mj). 30
4.1 O que a abordagem VES visualiza (objeto de análise). . . 46
4.2 O propósito das abordagens de VES. . . 48
5.1 Estudos experimentais realizados. . . 76
6.1 Visões e métricas utilizadas na Estratégia DR. . . 84
7.1 Hipóteses do estudo. . . 106
7.2 Relação de features utilizadas no experimento.. . . 106
7.3 Descrição das tarefas de compreensão de features. . . 108
7.4 Resultados da análise estatística. . . 113
8.1 Hipóteses do estudo. . . 123
8.2 Quantidade de participantes. . . 124
8.3 Resultados da análise estatística - Sítio 1. . . 126
8.4 Resultados da análise estatística - Sítio 2. . . 126
8.5 Resultados da análise estatística - Sítio 3. . . 127
Lista de Acrônimos
AA Acoplamento Aferente
AE Acoplamento Eferente
CC Cyclomatic Complexity ou Complexidade Ciclomática
CF Cor Final
CI Cor Inicial
CM ConcernMapper
CZ Cor Zero ou Cor Neutra
DA Diferencial Absoluta
DR Diferencial Relativa
EFES Exemplo Fictício de Evolução Software
ES Engenharia de Software
GQM Goal Question Metric
IDE Integrated Development Environment ou Ambiente de Desenvolvimento Integrado
IDG Interactive Direct Graphs ou Grafos Dirigidos Interativos
LOC Lines of Code ou Linhas de Código
MM MobileMedia
MRS Mineração de Repositórios de Software ou Mining software Repositories
NOM Number of Methods ou Número de Métodos
NOP Number of Packages ou Número de Pacotes
OO Orientação a Objetos
POO Programação Orientada a Obejtos
SCA Sistemas de Código Aberto
SCM Source Code Management
SM SourceMiner
SME SourceMiner Evolution
TA Temporal Snapshot Accumulative
TO Temporal Overview
TS Temporal Snapshot
VES Visualização de Evolução de Software
Capítulo
1
Este capítulo apresenta o contexto, a motivação principal e o problema que esta tese lida. Em seguida, ele aborda os objetivos, o trabalho realizado, e as contribuições da tese.
INTRODUÇÃO
1.1
Contexto
Sistemas de software evoluem por natureza (Lehman,1978)(Lehman,1980). A atividade de desenvolvimento de software torna-se mais complexa à medida que os sistemas vão evoluindo, o que conduz à necessidade de manutenções preventivas e corretivas. Esta complexidade se reflete nos custos do software associados à manutenção. Até 90% dos custos totais do software podem estar associados à manutenção (Erlikh,2000), fato que representa um oportuno campo para melhorias.
A compreensão do software é um pré-requisito para a realização de atividades de manu-tenção. Ela é um aspecto chave na evolução de software (Corbi,1989)(Bennett and Rajlich,
2000). Quanto mais complexo for o software, mais difícil fica a extração de informação, e, consequentemente, a sua compreensão. Há muito tempo pesquisadores já têm destacado o alto custo da atividade de compreensão. Por exemplo,Fjeldstad and Hamlen(1982) apontaram que 50% do tempo gasto com a manutenção são utilizados na compreensão do software.
Na grande maioria dos sistemas de software, as modificações executadas são pontuais (em partes específicas do código), o que não permite que se compreenda a completa natureza do sistema (Parnas,1994). Isto acarreta a queda na qualidade do sistema como um todo, ao longo de sua evolução.
Pesquisadores da área de engenharia de software têm buscado investir em soluções para garantir a qualidade do software. Um dos caminhos é facilitar a compreensão do mesmo. Duas áreas que investem nesse sentido são as de Métricas de Software e Visualização de Software.
Ambas as áreas ajudam a compreender melhor o software e consequentemente procuram contribuir com o aumento da qualidade do mesmo.
Medições têm sido utilizadas para garantir o controle de projetos, produtos e processos de software (Wohlin et al.,2000). Muitas métricas foram propostas na literatura. Através destas métricas é possível caracterizar, por exemplo, questões relativas ao tamanho, complexidade e acoplamento do código (Chidamber and Kemerer,1994)(Lanza and Marinescu,2010).
Seguindo a mesma linha, as técnicas de visualização de informação (Chen,2006) e de software (Diehl, 2007) têm sido utilizadas na Engenharia de Software como uma possível solução para a árdua tarefa de compreender, manter e evoluir sistemas de software (Storey et al., 2005). A Visualização de Software (VisSoft) utiliza recursos visuais para facilitar o entendimento do software por parte de programadores e engenheiros de software (Diehl,2007). A visualização de software tem como objetivo facilitar a visualização de propriedades do software. Por propriedades do software, pode-se considerar: a) as métricas associadas aos módulos do software1; b) funcionalidades2implementadas pelos módulos; c) defeitos presentes nos módulos; ou d) alguma característica não desejada3relacionada a um módulo, o qual o faz um candidato à refatoração.
A evolução de software gera uma grande quantidade de informação. Tem-se dados relativos às versões do software, dados de commits, desenvolvedores que trabalharam no software, defeitos, documentação, mapeamento de funcionalidades, entre muitos outros. Essa informação se expande continuamente, tornando a evolução do software uma atividade difícil de ser gerenciada. Por esta razão, técnicas de visualização podem ajudar significantemente na compreensão de dados de evolução de software, transformando estes dados em estruturas visuais mais facilmente interpretáveis que listagens de programas ou grande conjuntos de tabelas de dados.
Todavia, a complexidade inerente à evolução de software também é um desafio para a área de visualização de software. Além das propriedades de software relacionadas a uma única versão, uma nova dimensão (tempo) é adicionada, expandindo a quantidade de informação a ser gerenciada e visualizada. Esta tese trata exatamente deste desafio.
1Nesta tese, utilizaremos os termos módulo, artefato, entidade ou elemento de software para representar partes
representativas do software como pacotes, classes, métodos, funções e atributos.
2Nesta tese, utilizaremos os termos funcionalidades ou features. Feature é um aspecto visível ao usuário, uma
característica de qualidade, ou uma funcionalidade do software (Kang,1990).
3Nesta tese, o termo característica não desejada, é também um exemplo de anomalias ou bad smell (Fowler
1.2. MOTIVAÇÃO
Figura 1.1: Dois exemplos da visão Project Explorer do Eclipse.
1.2
Motivação
Os engenheiros de software, tanto no contexto acadêmico quanto industrial, têm utilizado técnicas de visualização de informação para a compreensão de software nas diferentes etapas do ciclo de vida do mesmo. A Figura1.1apresenta dois cenários da visão Project Explorer do ambiente de desenvolvimento Eclipse (Eclipse,2013), utilizado largamente em desenvolvimento de software. Nesta figura, são apresentados: projetos de software (Figura1.1-A) e um projeto em detalhes (Figura1.1-B).
Nesses exemplos da Figura1.1, recursos visuais são utilizados para informar que projetos possuem algum problema associado (o xis vermelho na Figura1.1-A) e para diferenciar tipos de módulos de software (pacote, classe e método - Figura1.1-B). A este primeiro caso, chamaremos de visualização global do software, uma vez que aspectos relevantes (informação) do software são apresentados, sem se preocupar onde de fato isso está acontecendo. Na Figura 1.1-A, por exemplo, sabe-se que o projeto possui problemas, mas não se sabe até então onde esses problemas estão. Para descobrir a localização do problema, são necessárias visualizações que
mostrem o software em detalhes. A este segundo caso chamaremos de visualização detalhada do software. Um exemplo deste segundo caso é apresentado na Figura1.1-B, onde os módulos do software são apresentados, permitindo-se identificar quais deles apresentam problemas.
Analisar o software em detalhes é mais comum que analisar o software globalmente. Como já dito, as modificações são, via de regra, pontuais (Parnas,1994). Quase sempre, faz-se necessário identificar quais módulos estão relacionados à tarefa em questão. Por exemplo, alguém pode querer:
1. Identificar módulos de software que são hot spots para algum tipo de análise (por hot spotsconsideramos módulos que se destacam de acordo com alguma propriedade); 2. Saber quais módulos são responsáveis por implementar um requisito ou uma
funcionali-dade;
3. Identificar módulos que apresentam alguma característica não desejada, o qual o faz um candidato à refatoração.
Esses são apenas alguns exemplos, e diversos outros poderiam ser citados mostrando a importância de se analisar – e consequentemente de se visualizar – o software em detalhes, para realizar atividades de engenharia de software.
Por outro lado, a relevância de se visualizar o software globalmente deve ser considerada. Este tipo de visualização pode ser importante para se ter uma visão abrangente do software e consequentemente do escopo do problema que está se atacando. Além disso, pelo fato de ela apresentar informações de mais alto nível, sem entrar no software detalhadamente, há uma redução na quantidade de informação a ser apresentada. Isto é uma característica desejada na área de visualização de software, pois quanto mais informação a ser apresentada, mais complexa será a cena visual.
Para ilustrar essa última afirmação, vamos considerar ainda o exemplo da Figura1.1. Imagine que cada um dos softwares com problemas da Figura1.1-A possuísse diferentes módulos com defeitos. Como seria possível visualizar todos eles ao mesmo tempo? Certamente não seria uma atividade trivial.
A visualização global do software é mais voltada ao nível gerencial, enquanto que a visuali-zação detalhada do software é mais voltada para problemas de engenharia, ainda que o gerente de software possa também estar interessado em analisar o software em detalhes. Claramente as duas abordagens são complementares. Em conjunto, elas estão em consonância com o famoso mantra de visualização deShneiderman(1996): visualização geral primeiro, depois obtenha detalhes sob demanda.
1.3. APRESENTAÇÃO DO PROBLEMA
A evolução do software é um cenário bastante complexo para a visualização do software. Há a necessidade de se visualizar tanto as propriedades inerentes a uma versão do software, como as adicionadas pela dimensão do tempo. São muitas versões, muitos módulos e muitos atributos. A primeira aposta de muitos poderia ser utilizar a visualização global do software, indicada para muitos dados. De fato, a maioria absoluta dos trabalhos que encontramos em uma revisão sistemática da área indica a utilização isolada de visualizações globais de evolução de software (Novais et al.,2013). Voinea and Telea(2006a), por exemplo, utilizam visualizações globais, as quais eles chamaram de multi-escalares e multi-variáveis, para visualizar evolução de software. Entretanto, visualizar o software em detalhes continua sendo importante para realizar tarefas de engenharia de software nesse importante e complexo cenário. Exemplos de tarefas de evolução que necessitam da identificação detalhada de módulos de software podem ser citados:
• Quais módulos são hot spots na evolução?
• Quais módulos apresentam bad smells na evolução?
• Quais módulos implementam determinadas features na evolução?
Este cenário nos motivou a investigar o problema de se visualizar o software em detalhes durante a sua evolução.
1.3
Apresentação do Problema
O problema de se visualizar a evolução do software em detalhes passa pelo desafio de se visualizar muitas versões, muitos módulos e muitos atributos de forma controlada e coordenada.
A Figura1.2apresenta quatro versões do software em detalhes do mesmo projeto. Observe que identificar as diferenças entre essas versões, mesmo nesse exemplo com poucas diferenças, não é uma atividade trivial. Neste exemplo, apenas os módulos de software e a dimensão do tempo são considerados. O problema seria bem mais complexo se fossem adicionadas informações sobre as propriedades (atributos) do software, tais como as já citadas features, bad smells, e hot spots.
Pelo menos duas argumentações contrárias a essa afirmação poderiam surgir: a) não necessa-riamente precisamos visualizar todas as versões da evolução do projeto. De fato, concordamos com isso. No contexto industrial, um cenário bastante comum de evolução é fazer uso de ferramentas de diffs. A Figura1.3apresenta um exemplo onde é feita a comparação entre duas versões de um arquivo de um projeto, a qual foca apenas em duas versões por vez; b) não se
Figura 1.2: Diferentes versões de um mesmo projeto no Project Explorer do Eclipse.
faz necessário visualizar todas as propriedades (features, bad smells, hot spots, etc.) ao mesmo tempo. Em atividades reais de desenvolvimento de software, o desenvolvedor ou gerente de software se foca em uma propriedade por vez.
Assumindo como verdade, ou pelo menos como um cenário comum do dia a dia do desen-volvimento de software, as argumentações a) e b) do parágrafo anterior, haverá uma redução do problema de se visualizar a evolução do software em detalhes, se nos focarmos em duas versões por vez (baseado no argumento da importância dos diffs) e em apresentar poucas propriedades do software na mesma cena visual.
Isto nos aponta um primeiro caminho de solução para o problema de como visualizar a evolução do software em detalhes: utilizar o conceito, bastante difundido, de diffs. As ferramentas de diffs são largamente utilizadas na indústria, e de fato, permitem visualizar (ainda que de forma limitada) o software (focado no código fonte) em detalhes. Suas limitações residem no fato de que elas geralmente se focam na diferença sintática entre arquivos textuais, considerando, quase sempre, um arquivo por vez. O arquivo é interpretado de forma textual, sem levar em consideração a semântica associada às propriedades do software. Neste caso, elas não proveem suporte para compreensão de importantes tarefas de engenharia de software, como as aqui já apresentadas. Todavia a combinação de técnicas de diff com visualização de informação, e com técnicas de identificação de atributos (ou propriedades) de software é promissora. Juntas
1.4. OBJETIVOS
Figura 1.3: Um exemplo de uma ferramenta de diff.
elas podem ser usadas para atacar as tarefas de compreensão anteriormente mencionadas. À estratégia usada para este fim, denominamos de Estratégias Diferenciais de visualização de evolução de software.
Um segundo caminho para contornar o problema de como visualizar a evolução do software em detalhes aparece quando faz-se necessário entender a evolução de determinados módulos de software durante várias versões. Por exemplo, para um módulo qualquer, qual é o comportamento de crescimento de uma determinada propriedade ao longo da evolução? Neste caso, as estratégias diferenciais não são suficientes. A solução passa então a ser: fazer uso de visualização detalhada de muitas versões, muitos atributos, porém poucos módulos. Às estratégias usadas para este fim, denominamos de Estratégias Temporais Overview Detalhada. Temporal Overview por visualizar várias versões, seguindo a ideia de visualizar o software globalmente. Detalhada por permitir visualizar o software em detalhes, focando-se em poucos módulos.
Os dois cenários apresentados representam problemas comuns de tarefas de Engenharia de Software. A combinação das soluções apresentadas produzirá visualizações que podem ajudar de forma efetiva engenheiros e desenvolvedores de software.
1.4
Objetivos
O objetivo geral desta tese é apresentar uma proposta de visualização de evolução do software em detalhes. Para este fim, será apresentada uma abordagem de visualização que dê suporte visual do software em detalhes no contexto de atividades de evolução de software. Esta abordagem faz uso combinado de estratégias diferenciais e estratégia temporal overview detalhada, em contraposição às abordagens temporais isoladas normalmente utilizadas na literatura.
visualização de software em detalhes, adicionando assim valor ao estado da arte em visualização de evolução de software.
Como objetivos específicos podem ser citados:
• Fazer um estudo de revisão de literatura sistemático, que possa apresentar direções de pesquisas futuras para a área;
• Apresentar uma categorização de estratégias de análise visual para suporte à visualização de evolução de software;
• Baseado na estratégias estudadas, identificar ou definir visualizações que combinadas possam ser efetivamente usadas para analizar a evolução do software em detalhes; • Construir uma infraestrutura com as visualizações propostas;
• Realizar estudos experimentais com o propósito de validar e evoluir as visualizações desenvolvidas.
1.5
Trabalho Desenvolvido
A Figura1.4apresenta as diferentes atividades, implementações e publicações desenvolvidas durante a tese, dispostas em ordem cronológica. Na Figura1.4, os retângulos brancos de borda abóbora representam atividades diversas, porém sem uma classificação específica, realizadas durante o doutorado. Os retângulos pintados de verde representam duas atividades de cunho mais teórico. Os retângulos azuis representam atividades de implementação da abordagem. Setas azuis entre eles mostram a ordem sequencial de realização das mesmas. Os retângulos vermelhos representam estudos de avaliação das abordagem. As linhas vermelhas tracejadas ligam o estudo à abordagem sendo avaliada pelo estudo. Círculos azuis com uma numeração iniciando com a letra P representam as publicações produzidas no contexto deste trabalho. Linhas azuis tracejadas ligam as publicações aos itens do qual elas tratam.
Iniciamos o trabalho desta tese com uma revisão profunda, porém informal, da literatura associada. Neste passo, foram investigados principalmente trabalhos relacionados à Evolução de Software, Visualização de Software, Visualização de Evolução de Software.
O passo seguinte foi definir um objetivo inicial para o nosso trabalho. Este objetivo foi fortemente baseado na coleta de informações feita no passo anterior. Como já explicado, observamos que muitas tarefas de engenharia de software requerem a necessidade de se avaliar o software em detalhes. Além disso, a evolução de software é, no estado da prática, analisada
1.5. TRABALHO DESENVOLVIDO
através de diffs entre versões sequenciais. Paralelamente, tínhamos um ambiente de visualização de software, chamado SourceMiner (SM). Esse ambiente, construído no contexto de uma pesquisa de doutorado do grupo, dá suporte à compreensão em detalhes de uma única versão do software. Dado este contexto, nosso objetivo era desenvolver uma abordagem visual que permitisse analisar a evolução do software em detalhes utilizando a tecnologia de diffs.
Antes de iniciar de fato o desenvolvimento desta abordagem visual, nós fizemos um levanta-mento das Estratégias de Análise Visual. Isto nos permitiu entender quais as estratégias de análise visual eram utilizadas pelos trabalhos existentes para analisar a evolução do software de forma global e detalhada.
Percebemos com o passo anterior uma oportunidade de contribuição à comunidade. Não havia na literatura uma classificação destas formas de análise visual. Então, decidimos criar uma Taxonomia para Estratégias de Análise Visual de evolução de software. Essa taxonomia é apresentada no Capítulo3.
Paralelamente a este passo, começamos a desenvolver nossa infraestrutura de suporte à análise visual de evolução de software. No primeiro momento, desenvolvemos uma nova estratégia de análise visual: a estratégia Diferencial Relativa. Como produto deste passo, surgiu a primeira versão do infraestrutura desenvolvida nesta tese, chamada de SourceMiner Evolution (SME). Esse desenvolvimento é apresentado nos Capítulos5e6.
O processo de desenvolvimento do SME foi incremental e iterativo. Este processo é deta-lhado no Capítulo5. Para cada fase de desenvolvimento, planejamos e realizamos um estudo de avaliação da abordagem desenvolvida. Cada estudo apontava pontos fortes e fracos da abordagem, os quais eram utilizados como oportunidades de evolução do ambiente. O primeiro estudo realizado foi o Estudo 1. Esse foi um estudo exploratório de viabilidade realizado pelos próprios pesquisadores. Ele é apresentado na Seção6.2.
Dando sequência a avaliação do ambiente, nós realizamos o Estudo 2. Esse foi um es-tudo Exploratório Observacional para Avaliar a Estratégia Diferencial Relativa, realizado com estudantes de Pós graduação. Esse estudo é apresentado na Seção6.3.
A partir dessas duas avaliações, começamos a perceber a necessidade de se visualizar a evolução do software em detalhes focando em um ou poucos módulos, e considerando mais de duas versões por vez. Em consequência disso, nós realizamos o Desenvolvimento da Estratégia Temporal Overview Detalhada 1. Esta fase integrou ao ambiente uma nova forma de se visualizar o software em detalhes. Esse desenvolvimento é apresentado nos Capítulos5e
8.
Demos continuidade ao processo de desenvolvimento e avaliação do ambiente. Além das dificuldades encontradas nos Estudos 1 e 2, que culminou no desenvolvimento da estratégia
1.5. TRABALHO DESENVOLVIDO
Temporal Overview Detalhada 1, queríamos estudar a evolução de features, porém a estratégia Diferencial Relativa não se aplicava bem para esse cenário. Resolvemos então fazer o Desenvol-vimento de uma estratégia Diferencial Absoluta para suporte à evolução de features. Esse desenvolvimento é apresentado nos Capítulos5e7.
Para avaliar essa estratégia realizamos o Estudo 3. Esse estudo foi um experimento con-trolado que contou com a participação de Analistas de Sistemas de duas cidades do Brasil. A Seção7.2apresenta esse estudo em detalhes.
No Estudo 3 percebemos novamente a necessidade de se visualizar a evolução do software
em detalhes focando em um ou poucos módulos, e considerando mais de duas versões por
vez. Isso ficou mais evidente, principalmente pelo fato dos participantes não conseguirem realizar algumas das tarefas propostas no experimento da forma como esperávamos. Por esse motivo, fizemos o Desenvolvimento da Estratégia Temporal Overview Detalhada 2. Como produto dessa fase, foi gerada uma nova forma de visualização de evolução global do software em detalhes. Essa nova forma de visualização foi integrada ao ambiente adicionando valor às estratégias anteriores. Esse desenvolvimento é apresentado nos Capítulos5e8.
Para avaliar essa última integração realizada no contexto desse doutorado, nós realizamos o Estudo 4. Esse estudo foi uma replicação do experimento controlado anterior, considerando a nova forma de visualização. Esse experimento foi realizado em três locais diferentes, sendo dois deles em turmas de cursos de pós-graduação e graduação, e o terceiro numa empresa. Esse experimento, apresentado na Seção8.2, mostrou os benefícios da integração de múltiplas estratégias de análise visual para visualização da evolução do software em detalhes.
É importante ainda ressaltar que após a realização dos Estudos 1 e 2, percebemos a ne-cessidade de se fazer uma investigação mais profunda da área de visualização de evolução de software. Decidimos então fazer um Mapeamento Sistemático da área. Confirmamos nesse mapeamento que quase todas as abordagens da área visualizavam a evolução global do soft-ware. Esse mapeamento, que é apresentado no Capítulo4, deu suporte ao desenvolvimento das estratégias seguintes: Diferencial Absoluta e Temporal Overview Detalhada 2.
Entre Abril e Agosto de 2012, foi realizado também um estágio sanduíche no Fraunhofer Center for Experimental Engineering - Universidade de Maryland, sob orientação do Dr. Forrest Shull. Esse estágio foi bastante importante para o amadurecimento e evolução do trabalho sendo realizado.
Confirme mostrado na Figura1.4, o trabalho desta tese gerou, até o momento, as seguintes publicações:
(2011). On the use of software visualization to analyze software evolution - an interactive differential approach. In R. Zhang, J. Cordeiro, X. Li, Z. Zhang, and J. Zhang, editors, ICEIS (3), pages 15–24. SciTePress.Este artigo apresenta a estratégia diferencial Relativa e o Estudo 1.
(P2) Novais, R., Lima, C., de F Carneiro, G., Simões Júnior, P., and Mendonça, M. (2011). An interactive differential and temporal approach to visually analyze software evolution. In Visualizing Software for Understanding and Analysis (VISSOFT), 2011 6th IEEE International Workshop on, pages 1–4. Este artigo apresenta a estratégia Diferencial Relativa e a estratégia Temporal Overview Detalhada 1.
(P3) Novais, R., F. Carneiro, G., Simões Júnior, P., and Mendonça, M. (2012). On the use of software visualization to analyze software evolution: An interactive differential approach. In R. Zhang, J. Zhang, Z. Zhang, J. Filipe, and J. Cordeiro, editors, Enterprise Information Systems, volume 102 of Lecture Notes in Business Information Processing, pages 241–255. Springer Berlin Heidelberg. Este artigo é um capítulo de livro gerado a partir da publicação P1.
(P4) Novais, R., Nunes, C., Lima, C., Cirilo, E., Dantas, F., Garcia, A., and Mendonça, M. (2012). On the proactive and interactive visualization for feature evolution comprehension: An industrial investigation. In Software Engineering (ICSE), 2012 34th International Conference on, pages 1044–1053. Este artigo apresenta a estratégia diferencial Absoluta e o Estudo 1.
(P5) Novais, R., Lima, Simões Júnior, P., and Mendonça, M. (2012). Timeline matrix: an on demand view for software evolution analysis. In Software Visualization (WBVS), 2012 2nd Brazilian Workshop on, pages 1–8. Este artigo apresenta a estratégia Temporal Overview Detalhada 2.
(P6) Novais, R., Torres, A., Souto, T., Mendonça, M., and Zazworka, N. (2013). Software evolu-tion visualizaevolu-tion: A systematic mapping study. Informaevolu-tion and Software Technology. to appear. Este artigo apresenta o Mapeamento Sistemático.
(P7) Novais, R., and Mendonça, M. (2013). Software Evolution Visualization: status, chal-lenges, and possible research directions. In Book: State-of-the-Art Concepts and Future Directions in Software Engineering. IGI Global. to appear.Este artigo é um capítulo de livro sobre o tema desta tese.
1.6. CONTRIBUIÇÕES
Dois artigos de periódicos estão em fase de produção, sendo que o primeiro deles já foi submetido.
(P8) Novais, R. Mendonça, M. (2013). A multiple strategy software evolution visualization infra-structure. Information and Software Technology. submitted.Este artigo apresenta a abordagem para visualização do software em detalhes desta tese e a taxonomia de estratégias de análise visual.
(P9) Novais, R., Nunes, C., Simões Júnior, P., Santos, A., Cirilo, Garcia, A., and Mendonça, M. (2013). On the proactive and interactive visualization for feature evolution comprehen-sion: A Replicated Experiment. A ser submetido para o Periódico Empirical Software Engineering. Está em fase de escrita. Este artigo apresentará o Estudo 4.
1.6
Contribuições
A contribuição principal desta tese é o desenvolvimento de uma abordagem para visualização de evolução de software em detalhes que combina versões, módulos e atributos de software de forma controlada e coordenada. Controlada pelo fato de não mostrar todas as versões ao mesmo tempo, permitindo a análise detalhada dos módulos e seus atributos. Coordenada pelo fato de combinar estratégias complementares que interagem entre si para facilitar a compreensão do software em detalhes.
Durante o processo de desenvolvimento deste trabalho, outras contribuições foram feitas: • Uma nova categorização da área de visualização de software que define as estratégias
visuais de análise para suporte à evolução do software (Capítulo3);
• Um mapeamento sistemático na área de visualização de evolução do software (Capítulo
4);
• Uma ferramenta visual multi-estratégia para suporte à análise de evolução de software, através da combinação e coordenação de visões, denominada de SourceMiner Evolution (SME) (Capítulo5);
• Uma nova estratégia de visualização diferencial denominada de Estratégia Diferencial Relativa (Seção6.1);
• Uma estratégia de visualização diferencial, denominada de Estratégia Diferencial Absoluta, para a compreensão de evolução de features (Seção7.1);
• Uma nova estratégia de visualização Temporal Overview Detalhada, suportada por uma nova visão denominada de Timeline Matrix - Temporal Detalhada 2 (Figura1.4) - (Capítulo
5)4;
• Um modelo de processo de desenvolvimento para ferramentas de visualização de software (Seção5.4);
• Coleta de evidências dos benefícios da integração de múltiplas estratégias de análise visual em ambientes de visualização de evolução de software, através de experimentos controlados (Seções7.2e8.2).
1.7
Organização da Tese
Além desta introdução, esta tese está organizada da seguinte forma. O Capítulo2 apresenta o referencial teórico com os temas relacionados a esta tese. O Capítulo 3 apresenta uma nova taxonomia para a área de visualização de evolução de software. Nessa taxonomia são categorizadas as estratégias de análise visual de evolução de software. O Capítulo4apresenta um Mapeamento Sistemático da área de visualização de evolução de software. O Capítulo5
apresenta o ambiente visual multi-estratégia desenvolvido. Os três capítulos seguintes detalham as estratégias implementadas no ambiente e os estudos de validação realizados para validação das mesmas. O Capítulo6 apresenta a Estratégia Diferencial Relativa do SME. O Capítulo
7apresenta a Estratégia Diferencial Absoluta do SME. O Capítulo8apresenta as Estratégias Temporal Overview Detalhada do SME. Por fim, o Capítulo9conclui esta tese.
4A estratégia Temporal Overview Detalhada 1 (Figura1.4) foi baseada em Coordenadas Paralelas, a qual é uma
Capítulo
2
Este capítulo aborda assuntos relacionados à esta tese. Inicialmente, ele destaca a importância da evolução de software. Em seguida, conceitos de visualização de software são discutidos, dando ênfase para seu uso na análise de grande quantidade de dados. Como a evolução de software lida normalmente com muito dados, é de se esperar que ela possa também ser benefíciada pela visualização de software. Este capítulo discute então como a visualização de software pode ajudar a área de evolução de software. Por fim, é apresentada uma discussão sobre diffs de software, destacando seu uso bem estabelecido no contexto real de desenvolvimento de software.
REFERENCIAL TEÓRICO
A evolução de software é uma atividade inerente ao ciclo de vida do software. Lidar com essa atividade no dia a dia não é trivial. Sua complexidade está bastante associada ao fato de se ter que manipular uma grande quantidade de dados produzida durante o desenvolvimento do software. Em um cenário bem comum no ciclo de vida de um software, diferentes ciclos de evolução são necessários. Neles diversos artefatos são produzidos ou modificados, e várias pessoas contribuem para este esforço. Tudo isso tem que ser gerido corretamente para que o software não se deteriore.
Para lidar com essa complexidade, diversas áreas da engenharia de software têm investido esforços para melhorar os processos, técnicas e ferramentas de apoio à evolução de software. Uma delas é a área de Visualização de Software, onde muitos se utilizam de recursos visuais na tentativa de lidar com a grande quantidade de dados associada à evolução de software.
Este capítulo aborda conceitos relacionados a essas áreas, considerados relevantes para o trabalho proposto nesta tese. A Seção 2.1apresenta conceitos de Evolução de Software. A Seção2.2discute a Visualização de Software. A Seção2.3apresenta como a Visualização tem sido utilizada para dar suporte à Evolução de Software. Por fim, a Seção2.4apresenta uma breve discussão sobre conceitos de diffs, os quais são utilizados para verificar as diferenças entre diferentes versões de software produzidas durante a evolução.
2.1
Evolução de Software
Evolução de software é um dos mais importantes tópicos da pesquisa moderna em Engenharia de Software. A definição de evolução de software muitas vezes se confunde com a manutenção de software, uma vez que uma manutenção de software faz com que o software evolua. Alguns autores consideram a evolução do software como uma atividade mais ampla, que começa junto com o desenvolvimento inicial do software e persiste durante todo o ciclo de vida, ao passo que a manutenção consiste das fases do processo de desenvolvimento de software realizadas após a entrega do software para produção.
Apesar do termo evolução de software ser muitas vezes utilizado como um termo substituto para manutenção de software (Bennett and Rajlich,2000), em geral a evolução de software é uma atividade mais ampla e está relacionada ao porquê ou como o software muda ao longo do tempo. Essa mudança ocorre muitas vezes a partir de uma manutenção de software.
O Padrão IEEE 1219 (IEEE,1993) define manutenção de software como “a modificação do seu produto após a entrega para corrigir defeitos, melhorar desempenho ou outros atributos, ou para adaptar o produto às modificações do ambiente”.
De acordo com a lei de mudança contínua definida por Lehman no final da década de 70, a mudança do software é inevitável, caso contrário o software morreria (Lehman,1978)(Lehman,
1980). Software necessita mudar devido a diferentes razões. Novos requisitos emergem e os antigos precisam ser mudados à medida que o software está sendo utilizado. Defeitos são detectados e precisam ser corrigidos. Melhorias funcionais ou não funcionais são necessárias para atender novos requisitos do ambiente de negócio. O sistema de software deve trabalhar em um novo hardware ou novas plataformas de software.
Existem quatro tipos de manutenções que podem acontecer com o software:
• Manutenção corretiva: tem como objetivo identificar e corrigir defeitos no software; • Manutenção adaptativa: busca adaptar o software ao ambiente no qual ele está inserido; • Manutenção perfectiva: tem como objetivo atender novos ou mudanças nos requisitos do
usuário, com o intuito adicionar novas funcionalidades e melhorar o software;
• Manutenção preventiva: tem como objetivo melhorar a manutenabilidade ou confiabilidade futuras do software.
Todos estes tipos de manutenção geram a necessidade de modificação no software e a consequente evolução do mesmo.
2.1. EVOLUÇÃO DE SOFTWARE
Ainda que seja mais frequente durante a atividade de manutenção, a evolução está presente em todo o ciclo de vida do software. O ciclo de vida do software começa com a necessidade de se ter o software por parte do cliente, passa por diversas fases de desenvolvimento, e termina quando o software deixa de ser utilizado.
As fases de desenvolvimento são diversas. Exemplos comuns são: análise, modelagem, codificação, testes, implantação. A forma como estas fases estão organizadas, como elas se interagem, são definidas de acordo com o processo de desenvolvimento adotado. Da mesma forma, diversos são os processos de software existentes.
Cada fase do desenvolvimento pode produzir diferentes artefatos, que são importantes para a realização do software. Estes artefatos devem ser gerenciados de forma a facilitar as manutenções que vierem a ocorrer no software.
Para cada mudança que ocorre em algum artefato do software, tem-se um produto evoluído. Essas mudanças podem ser: a) pequenas, como a mudança em uma pequena parte de um módulo do software, para corrigir um defeito, por exemplo; ou b) grandes, que podem implicar em adições de novas funcionalidades, mudanças de plataformas, etc. Essas mudanças podem ser registradas em sistemas de controle de versão. Nesses sistemas, mudanças pequenas são normalmente chamadas de releases, e, quando se tem uma mudança que gera um impacto grande no software, chama-se de versão. De qualquer forma, não existe um padrão universal para definir o que é um release ou uma versão. Isso é bastante dependente do processo de software adotado pela empresa.
Para gerenciar as mudanças, o apoio ferramental é fundamental. Sistemas de controle de versão, sistemas gerenciadores de tarefas, ferramentas de modelagem, e ambientes de desenvolvimentos integrados, são alguns exemplos de ferramentas comumente utilizadas no dia a dia do desenvolvimento do software.
Essas ferramentas produzem e armazenam dados realísticos da história do software. Esses dados podem ser utilizados para tentar responder o porquê e o como o software muda ao longo do tempo, ou seja, para tentar entender a sua evolução.
Entretanto esta não é uma atividade trivial. Diversas áreas da engenharia de software investigam dados evolucionários, na tentativa de identificar padrões, propor modelos ou métricas, que possam contribuir positivamente para a árdua e custosa tarefa de se manter o software.
A atividade de manutenção é, de fato, complexa e impacta significativamente nos custos do software.Erlikh(2000), por exemplo, reportou em seu estudo que até 90% dos custos totais do software estão associados à manutenção.
Neste cenário, o tamanho e a complexidade dos sistemas de software desenvolvidos geral-mente crescem continuageral-mente, para manter compatibilidade com a rápida evolução do hardware
Figura 2.1: Um exemplo do potencial dos recursos visuais.
e com os novos requisitos estabelecidos pelos usuários. Isso tem gerado uma grande preocupação acerca do gerenciamento da evolução de software. Milhares de linhas de código e documentação devem ser mantidas atualizadas, e consistentes entre si, enquanto o sistema evolui. Suporte ferramental se torna assim fundamental neste contexto.
A partir deste ponto, adotaremos nesta tese o termo evolução de software para representar tanto a evolução como um todo, quanto as atividades de manutenção que fazem com que o software evolua.
Considerando a necessidade e importância da evolução do software, novas metodologias, processos e ferramentas para entendê-la e gerenciá-la são necessidades urgentes em organizações de engenharia de software atuais. Uma delas é a Visualização de Software, que faz uso de recursos visuais para facilitar o entendimento de uma grande quantidade de dados de software.
2.2
Visualização de Software
A Visualização de Software é uma subárea da Visualização da Informação. A visualização de informação utiliza recursos visuais para organizar e representar os dados para produzir informação (Mazza,2009).
A Figura2.1mostra, apesar da pouca quantidade de dados, um exemplo do potencial de recursos visuais. Do lado esquerdo da figura tem-se uma tabela com as vendas de três tipos de carros (x, y e z) nos seis primeiros meses de um ano. O leitor deve fazer um esforço razoável para identificar padrões nesses dados. Ao lado direito, é apresentada uma figura que utiliza recursos visuais como posição, tamanho e cores, para representar os mesmos dados. Em pouco tempo é possível observar que o carro “y” é o mais vendido, e que houve um pico de vendas em Março, seguido de um decréscimo nas vendas.
2.2. VISUALIZAÇÃO DE SOFTWARE
Figura 2.2: Um exemplo de visualização de software. Extraído de (Wettel et al.,2011).
A Visualização de Software apresenta dados relativos ao desenvolvimento, análise, execução, utilização e manutenção do software. Ela é definida como o mapeamento de entidades de software (tais como pacotes, classes, e métodos em Programação Orientada a Objetos - POO) e seus atributos (métricas associadas) em uma representação gráfica (Koschke,2003) (Roman and Cox,1992). Esse mapeamento busca facilitar a compreensão do software através de abstrações gráficas. O ser humano é capaz de adquirir informação de forma mais rápida quanto utiliza o raciocínio perceptivo (baseado na percepção visual) ao invés do raciocínio cognitivo necessário à detecção de padrões em tabelas ou textos (Mukherjea and Foley,1996). Abstrações gráficas exploram a facilidade do ser humano em processar cenas visuais (Ware,2004), uma vez que o ser humano faz uso da visão mais do que todos os outros sentidos combinados (Ware,2004).
A Figura2.2, extraída de (Wettel et al.,2011), apresenta um exemplo de visualização de software, no qual os módulos do software são apresentados como paralelepipedos retangulares, onde suas dimensões, posições e cores estão associadas aos atributos de interesse do software. Esta visualização especificamente é chamada de mapa de desarmonia e se baseia em dados de problemas de projeto calculados utilizando as estratégias de detecção deMarinescu(2004). A visualização apresentada nesta figura foi feita através da ferramenta Codecity (2013). A CodeCity é um ambiente integrado para análise de software, em que os sistemas de software são visualizados de forma interativa e navegável como cidades em 3D.
A Visualização de Software pode ajudar na realização das tarefas de engenharia de software. Considere acoplamento entre módulos de software como um exemplo. Usando o grafo como representação visual, esses módulos podem ser representados pelos nós e a informação de
acoplamento pelas arestas direcionadas. Isto constrói uma representação visual intuitiva para a análise de dependência entre módulos de software. Sem uma representação visual, a única forma de analisar esta informação seria olhando internamente o código fonte, tabelas de métricas ou matrizes de dependência, o que requer um trabalho e um esforço cognitivo intenso.
No caso da engenharia de software, a utilização de recursos de visualização é particular-mente útil porque ela transforma entidades de software intangíveis e seus relacionamentos em representações visuais que criam um contexto comum de interpretação para diferentes pessoas. Considere o exemplo anterior, o conceito de acoplamento pode ser interpretado de várias formas, mas a figura que o descreve geralmente só pode ser interpretada de uma maneira. Em um grafo de acoplamento, uma aresta indubitavelmente significa a presença do acoplamento, não deixando margem para interpretações incorretas ou inconsistentes entre dois engenheiros de software. Se estes mesmos engenheiros discutissem acoplamento sobre um pedaço de código fonte, seria necessário garantir que ambos tenham a mesma noção do conceito e da forma de interpretá-lo. Herança é acoplamento? Implementação de uma mesma interface é acoplamento? Caso os dois não tenham exatamente a mesma interpretação, eles podem estar discutindo conceitos diferentes sobre o mesmo artefato. Com a utilização de uma representação visual tal como um grafo, e que tenha seu objetivo bem definido, não haverá discordância de que existe acoplamento entre dois artefatos ligados por uma aresta, mesmo que ambos não conheçam a definição de acoplamento que gerou aquela aresta. É importante observar porém que a semântica do elemento visual precisa estar bem definida entre os dois engenheiros de software. Caso contrário, qualquer representação, seja de código, modelos, ou visualização, pode levar a múltiplas interpretações, impactando negativamente nos resultados desejados.
A visualização de software, apesar de trazer benefícios, tem também fragilidades e limi-tações como qualquer outra área da engenharia de software. Existem limilimi-tações inerentes à representação de informações na tela do computador. Para superá-las, alguns autores optam pelo uso de recursos 3D (McIntosh et al.,2005), outros, destacam a necessidades de múltiplas visões (Carneiro,2011). Independente da escolha, os recursos visuais podem também dificultar e levar a interpretações inconsistentes, principalmente quando mal projetados e mal definidos. Além disso, visualizações mais complexas requerem um esforço significativo para o seu aprendizado. Para tarefas mais simples, o uso de visualizações mais complexas pode até impactar negativa-mente nos resultados da realização de uma atividade de engenharia de software (Novais et al.,
2.2. VISUALIZAÇÃO DE SOFTWARE
2.2.1
Tipos de Visualização de Software
Existem várias taxonomias de classificações para Visualização de Software. Algumas dividem visualização de software quanto ao tipo de objeto visualizado.
Diehl(2007), por exemplo, divide visualização de software em visualização de estrutura, comportamentoe evolução de software. Estrutura refere-se à visualização de partes estáticas do software. Comportamento refere-se à visualização da execução do software. Evolução refere-se à visualização de como o software evolui (Diehl,2007). O trabalho apresentado aqui pode ser classificado como de Estrutura, uma vez que ele se foca na visualização das estruturas do software e de Evolução, pois ele permite visualizar informações de evolução destas estruturas. Uma taxonomia mais abrangente foi proposta em (Price et al.,1993). Esta taxonomia tem seis principais categorias (Escopo, Conteúdo, Forma, Método, Interação, Efetividade), sendo que cada categoria é ainda dividida em um conjunto de 30 características. Cada característica qualifica os sistemas de visualização de software em uma forma específica. De acordo com os autores, o Escopo está preocupado em classificar o escopo da visualização de software. Neste caso, está interessado em classificar características como tipos de classes que o programa visua-liza, se visualiza concorrência, múltiplos programas, se é escalável, etc. O Conteúdo classifica o tipo de dado que está sendo visualizado. Essa categoria classifica a visualização de software em visualização de programas, algoritmos, dados, código, etc. A Forma define os tipos de elementos que são utilizados pela visualização. Por exemplo, tipo de mídia, elementos gráficos, cores, animação, múltiplas visões, entre outras. O Método está interessado em classificar como a visualização é especificada. Neste caso, define o estilo (se é feita especificamente para um programa, se modifica ou não o código sendo visualizado, se é totalmente automatizado a partir da análise do código a ser visualizado, etc.), se a visualização é produzida em batch ou quando o programa executa, se pode ser customizada, etc. A Interação classifica como o usuário interage e controla a visualização. São caracterizadas tipos de navegação, oclusão, etc. Por fim, a Efetividade define o quão boa é a visualização. Neste caso, são caracterizadas qualidades como clareza na transferência da informação, se foi avaliada experimentalmente, e se está de fato em uso por um bom período de tempo.
Software pode também ser visualmente analisado em diferentes perspectivas (Carneiro et al.,
2010). Este conceito está relacionado com a Forma definida na taxonomia de (Price et al.,1993). Entretanto o conceito vai um pouco além. Na taxonomia os autores falam de múltiplas visões. Porém, é possível utilizar diferentes visões com uma mesma perspectiva (Novais et al.,2013). A perspectiva define que visualização pode ser classificada de acordo com o ponto de vista que ela provê aos engenheiros para explorarem o software.
Visualização de software pode ainda ser classificada através dos tipos das paradigmas que ela utiliza para representar o software. Dentre outras, as visualizações podem ser iconográficas, baseada em pixel, baseada em matriz, baseada em grafos e metáforas hierárquicas (Keim,2002) (Ferreira de Oliveira and Levkowitz,2003).
2.3
Visualização de Evolução de Software
No contexto de evolução de software, o uso de visualização se torna ainda mais importante. Isto é justificado pela grande quantidade de informação associada à evolução de um sistema. Essa informação pode ser sumarizada e representada por paradigmas diversos (Keim,2002) (Ferreira de Oliveira and Levkowitz,2003). A visualização pode ajudar a alcançar objetivos relativos à análise da evolução do software como por exemplo: identificação de pontos críticos (hot-spots) de erosão do projeto (design) e decaimento de código (Ratzinger et al., 2005); descoberta de elementos que estão induzindo o decaimento do código (Eick et al.,2001); e, análise de anomalias de código (code smells) no software (Lanza et al.,2005).
O reconhecimento que o uso de visualização de software pode ajudar a análise da evolução do software não é novo. Os primeiros trabalhos na área têm cerca de 20 anos. Todavia, durante os anos recentes, um corpo crescente de trabalhos relevantes está sendo desenvolvido na área.
Um dos primeiros trabalhos na área foi o Seesoft, proposto porEick et al.(1992). O Seesoft mapeia linhas de código em uma linha fina na tela do computador. A cor de cada linha indica um atributo (ou estatística, como os autores definem) de interesse. O Seesoft foi projetado não apenas para visualização de evolução. Ele permite por exemplo: a) fazer análise estáticas para verificar onde funções são chamadas no código; b) fazer análise dinâmicas, para profiling, no qual são representados a memória utilizada e tempo de execução do programa (Eick et al.,1992). Para visualização de evolução de software, ele mostra a idade das linhas de código fonte. A Figura2.3 apresenta um exemplo de visualização da idade das linhas de código fonte (Ball and Eick,1996). As linhas mais recentemente modificadas são pintadas de vermelho, as mais antigas de azul. Há uma interpolação entre estas duas cores, para representar as linhas com idades intermediárias.
Em 2001, Lanza propôs a Matriz de Evolução (Evolution Matrix) para visualizar a evolução do software (Lanza, 2001). A Figura 2.4 mostra um exemplo da Matriz de Evolução. Os retângulos são utilizados para representar os módulos de software, e sua posição horizontal representa as diferentes versões do módulo. É possível observar alguns padrões na evolução do software, tais como o início do crescimento de módulos, a estagnação no desenvolvimento, etc.
2.3. VISUALIZAÇÃO DE EVOLUÇÃO DE SOFTWARE
Figura 2.3: Um exemplo de visualização de evolução de software. Extraído de (Ball and Eick,
Figura 2.4: Algumas características da Matriz de Evolução. Extraído de (Lanza,2001).
O autor utilizou também uma metáfora da astronomia para analisar alguns aspectos da evolução das classes. Neste caso, a evolução das classes era classificada de acordo com alguns tipos de estrelas (e.g. Pulsar, Supernova, Vermelho gigante, etc). Em 10 anos, esse trabalho se tornou o mais referenciado dentro da comunidade de Visualização de Evolução de Software (Novais et al.,2013).
Um trabalho mais recente foi apresentado porKuhn and Stocker(2012). Neste trabalho, os autores propuseram o CodeTimeline: uma abordagem que utiliza visualização para contar a história do projeto de software baseado em seus dados de versionamento. Notas podem ser usadas para compartilhar memórias de acontecimentos da vida de um sistema, como justificativas de um projeto utilizado no passado, e também memórias mais casuais, como fotos de qualquer momento de interesse da equipe do projeto sendo visualizado. A Figura2.5mostra a linha do tempo de um projeto proprietário chamado Outsight. Observe que o CodeTimeline usa cores e posicionamento vertical para contar a história do software. A camada base mostra um mapa autoria1, onde cores identificam os desenvolvedores e as linhas são a história do arquivo. As bolhas são os commits feitos nos arquivos pelos desenvolvedores.
Diversos outros trabalhos foram propostos ao longo desses anos. Em nosso mapeamento sistemático (Novais et al.,2013) identificamos, até o ano de 2011, 146 estudos que abordavam o tema Visualização de Evolução de Software. A seguir alguns deles são citados.
2.3. VISUALIZAÇÃO DE EVOLUÇÃO DE SOFTWARE
Figura 2.5: CodeTimeline mostrando a linha do tempo um projeto. Extraído de (Kuhn and Stocker,2012).
