Esforços de visualização de software podem ser classificados em duas dimensões principais: i) o primeiro concentra-se em questões de computação gráfica, preocupados com desenvolver visualizações escaláveis ou em como exibir grandes quantidades de dados de uma forma atrativa, confortável e eficiente (fácil de interpretar) e, ii) o segundo concentra-se em pragmaticamente ajudar engenheiros de software a realizar tarefas de engenharia de software. Acreditamos que abordagens de visualização de software devam estar sempre bem alinhadas com a segunda dimensão (engenharia de software), ainda que uma grande quantidade de esforço seja necessária para a primeira dimensão (gráfica). Isto é o mesmo que dizer que a visualização de software deve ser sempre orientada para objetivos (Basili et al.,2010), de forma pragmática tentando alcançar as tarefas de engenharia de software. Então, para nós, os objetivos da abordagem proposta devem conduzir a definição de ferramentas de visualização de software e não o contrário.
Neste estudo de mapeamento, nós tentamos capturar claramente os objetivos e as tarefas endereçadas pelas abordagens de VES propostas. Infelizmente, vários estudos apenas descrevem seu objetivo em um nível muito alto de abstração. Eles tentam responder a questões gerais, mas não deixam claro como se podem usar suas descobertas para resolver problemas concretos de engenharia de software. Eles mostram o que aconteceu durante a evolução do software, mas dá pouca ou nenhuma ideia do que um engenheiro de software deve fazer em seguida.
Collberg et al. listam algumas das questões que são comumente abordados pelo estudos em VES [S51]: (a) “Por que o programa é estruturado da maneira que é?; (b) Quais programadores foram responsáveis por quais partes do programa durante os períodos de tempo?; (c) Que partes do programa aparecem instáveis durante longos períodos de tempo e podem precisar ser reescritos?; (d) Quando partes específicas do programa foram criadas?; (e) Durante determinado período, quais partes do programa foram mais fortemente modificadas?; (f) Quais programadores têm modificado que partes do código e quando?; e, (g), Que partes do programa têm crescido em complexidade ao longo do tempo?”. Note-se que algumas dessas perguntas, estão diretamente mapeadas para uma tarefa concreta de engenharia de software. Questão (c), por exemplo, está diretamente relacionada às necessidades de refatoração ou reengenharia. Outros não. Pergunta (e), por exemplo, pode indicar volatilidades passadas, mas dá poucas pistas sobre o que fazer no presente. Estudos que abordam questões deste tipo deixam o que fazer em seguida como uma questão em aberto.
Para atenuar esse problema de classificação dos objetivos das VES propostas, usamos o modelo Goal, Question, Metric (GQM) de Basili e Weiss (Basili and Weiss,1984). Esse template foi utilizado para tentar capturar completamente os objetivos de análise de software expressas
4.2. RESULTADOS
nos artigos de VES. Esse modelo tem normalmente quatro facetas: ponto de vista, objeto de análise, foco e objetivo. O objeto de análise é a entidade de interesse na análise. O objetivo é geralmente classificado em caracterizar, compreender, avaliar, controlar, melhorar ou prever algo. O foco é o principal atributo de interesse no objeto de análise. E, o ponto de vista descreve o grupo dos usuários interessados nas informações analisadas.
Ponto de vista
Mantenedores de software e gerentes de software podem usar muitas abordagens de VES, entretanto a maioria dos artigos não menciona explicitamente qual era o público-alvo para as abordagens que eles propunham. Por uma questão de simplificação do nosso mapeamento, decidimos não catalogar o ponto de vista das abordagens de VES, e assumimos que elas são voltadas para os mantenedores e gerentes de software.
Objeto de análise
Nosso próximo passo foi classificar o objeto de análise das abordagens VES. Para isso, precisávamos de um esquema de classificação para objetivos dos estudos de VES. Infelizmente, não foi encontrada uma classificação pronta na literatura para que pudéssemos utilizar no mapeamento sistemático. Decidimos adotar um esquema de uma área relacionada e expandi-lo para VES. A fonte mais valiosa que encontramos para esta finalidade foi a taxonomia proposta porKagdi et al.(2007). Eles classificaram os estudos de Mineração de Repositórios de Software (MRS), que são, em várias dimensões, muito relacionadas com a VES. Com base na classificação deKagdi et al.(2007), foram agrupadas as abordagens de VES nas categorias apresentadas na Tabela4.1.
A Figura 4.2 apresenta o número de estudos por cada categoria. Alguns estudos foram classificados em mais de uma categoria.
Foco e Propósito
Kagdi et al.(2007) também propôs 10 categorias de tarefas relacionadas a mineração de dados de evolução. Eles classificaram visualização de software na categoria “compreensão de mudança”. Em termos de objetivos do GQM, eles estão dizendo que VES é usada principalmente para compreender (propósito do objetivo) mudanças (foco do objetivo).
De fato, a maioria dos estudos que analisamos apresentam abordagens que contam a história da evolução de um artefato de software, mostrando o que aconteceu com ele desde a sua criação. Por exemplo, muitos trabalhos tentam ajudar os usuários a “obter insights no código (por exemplo, [S26, S44])”; “a lidar com uma grande quantidade de dados (por exemplo, [S42])”, “ajudar os engenheiros de software a construir conhecimento sobre seus sistemas [S63]”, “observar a mudança ao longo da evolução do software. [S99]”; “ajudar na compreensão de como um produto de software tem evoluído desde a sua concepção [S100]”, e “esta representação
Tabela 4.1: O que a abordagem VES visualiza (objeto de análise).
O que a VES visualiza Descrição
Comportamento Visualizar informações dinâmicas, como traços de execução, as execuções de perfis, etc.
Clone de código Visualizar os clones no código fonte e lidar com a sua evolução.
Estrutura de dados Focada em estruturas de dados dos programas.
Defeitos Qualquer tipo de defeitos, geralmente extraídos de sistemas de bug tracking.
Atividades de desenvolvedores
Com o objetivo de visualizar o que os desenvolvedo- res têm feito no projeto, ou onde os desenvolvedores têm trabalhado.
Dependência entre desenvolvedores
Com o objetivo de visualizar como os desenvolve- dores trabalham em conjunto, como eles se comuni- cam entre si, ou que arquivos são de propriedade de mais de um desenvolvedor, etc.
Controle de exceção Focada em lidar com fluxo de exceção em progra- mas.
Mudanças em ecossistemas Visualização dos ecossistemas.
Features Focada em features, concerns ou funcionalidades do código-fonte.
Listas de e-mails Visualizar as informações contidas na lista de e-mail de desenvolvedores.
Métricas
Com foco exclusivo sobre a evolução de métricas. Normalmente expressa em diagramas Kiviat ou co- ordenadas paralelas.
Requisitos Concentrou-se nos requisitos do programa. Arquitetura de Software Focada em modelos, estrutura, ou diagramas UML.
Mudança no código fonte
Visualizar as mudanças relacionadas ao código fonte em si. Métricas de tamanho são comumente utilizados por esses estudos.
Comentários associados as mudanças de código fonte Enriquecer comentários de commits usando visuali- zação de software.
Dependência de código fonte Focado em analisar como o programa está acoplado. Dependência de Sistema Dependência entre sistemas.
Tópicos Visualizar coleções de palavras que co-ocorrem com frequência em um texto (ou código fonte).
4.2. RESULTADOS
Figura 4.2: Número de estudos versus o quê as abordagens VES visualizam.
destaca os momentos críticos – quando grandes mudanças parecem ter acontecido – na evolução de todo o módulo [S56]”.
No entanto, há alguns estudos que não têm uma finalidade específica de engenharia de software. Eles visam discutir principalmente os recursos visuais, apresentando-os como um meio poderoso para representar os dados de visualização de evolução de software [S33]. Classificamos o propósito desses estudos como “fornecer visualização poderosa e escalável”.
A Figura4.2mostra as categorias que foram utilizadas durante a classificação das abordagens de VES. Mais uma vez, alguns estudos foram classificados em mais de uma categoria. É importante dizer que um estudo foi classificado em uma categoria apenas se o objetivo do estudo foi explicitamente declarado no artigo.
A Figura4.3mostra o número de estudos por cada categoria apresentada na Tabela4.2.