Componentes do SME

Nesta subseção são discutidos em detalhes os componentes do SME, tomando com base a infraestrutura apresentada na Figura5.2.

5.3.1.1 Fonte de Dados

As fontes de dados são essenciais para as tarefas de análise de dados em Engenharia de Software. No domínio da evolução do software, elas são variadas e geralmente armazenam grandes quantidades de dados.

O SME usa um sistema de gerenciamento de código fonte como a sua principal fonte de dados. Na sua versão atual, o SME trabalha com o repositório Subversion (Pilato,2004). Desse SCM, o SME recupera diferentes versões de um projeto de software. O conceito de versão é definido pelo usuário, ou seja, o SME permite ao usuário escolher o que é uma versão (ou versão SME). O usuário é capaz de navegar no SCM e selecionar qualquer release de interesse para que esta seja uma versão. Ele pode, por exemplo, escolher usar cada release ou simplesmente as principais releases do software como uma versão SME. Como o SME é um plug-in do Eclipse, cada versão SME é considerada como um projeto completo do Eclipse. Desta forma, ela possui o código fonte associado, bem como pode possuir outros documentos relativos à release. Em nossos estudos, utilizamos apenas as releases estáveis que foram marcadas no repositório como novas versões. O SME usa o código fonte como a sua principal fonte de dados. O código fonte de cada versão SME é processado através da árvore sintática abstrata (AST - Abstract Syntax Tree) do Eclipse. Diversas métricas do código fonte são extraídas neste processo.

Outra fonte de dados usada atualmente pelo SME são os arquivos de mapeamento de features (concerns no SM). Esta fonte de dados é usada para análise de evolução de features em uma das estratégias abordadas pelo SME. Existem várias ferramentas que produzem mapeamentos entre as features e os módulos de código fonte (Robillard and Murphy,2002) (Buckner et al.,2005) (Robillard and Murphy,2007). No SME, esses mapeamentos são obtidos através de arquivos XML. O SME usa os arquivos de mapeamento XML de acordo com o formato fornecido pela ferramenta ConcernMapper (Robillard and Murphy,2002) (Robillard and Weigand-Warr,2005), uma das mais populares para tal fim.

5.3.1.2 Métricas

As métricas fornecidas pelo SME baseiam-se no código fonte. Atualmente ele trabalha com: linhas de código (LOC), número de métodos (NOM), número de classes (NOC), número de

5.3. SOURCEMINER EVOLUTION - SME

pacotes (NOP), complexidade ciclomática (CC), fan in, fan out, e número de features.

Algumas das métricas são aplicáveis a tipos específicos de módulos de software. Por exemplo, a métrica NOC é aplicável para os pacotes, mas não para classes ou métodos. Em outras palavras, mesmo que todas estas métricas estejam disponíveis, elas são usadas de acordo com a cena visual e o que está sendo mostrado na mesma.

5.3.1.3 Visões

O SME utiliza várias visões para representar a evolução do software. Atualmente, possui cinco visões estáveis, quatro filtros e várias outras visões em teste e desenvolvimento. O trabalho desta tese foca em discutir as visões estáveis e os filtros do SME. As visões estáveis são: Treemap, Polymetric, Dependency, Parallel Coordinates e Timeline Matrix. As três primeiras visões são oriundas do SourceMiner4. Os filtros são: Filters View, FeatureFilter view, Evolution Filters Viewe TimeLine Filters View. Os dois primeiros filtros são oriundos do SM, os outros dois foram desenvolvidos no escopo do trabalho apresentado nesta tese.

As cinco visões são mostradas na Figura 5.3. Três delas são chamadas de visões globais (Treemap, Polymetric, Dependency). As outras duas visões, (TimeLine Matrix e Coordenadas Paralelas), são visões sob demanda das três globais. As visões apresentam os dados em diferentes níveis de detalhe.

A Figura5.3apresenta as cinco visões com coloração utilizada no contexto do SME. As setas representam a forma como funciona a navegação entre as visões. Este recurso foi desenvolvido no contexto deste tese, e se mostrou muito importante na realização das atividades de engenharia de software que o SME se propõe a fazer. Como pode ser observado, por meio das três visões globais, é possível chegar às outras duas visões sob demanda. Além disso, a visão Treemap pode ser alcançada a partir de qualquer outra visão no SME. Ela é usada como visão de referência na infraestrutura, pois ela permite visualizações da estrutura do software, mostrando detalhes ao nível de métodos, contextualizados por seus pacotes e classes. A necessidade de utilização de uma visão de referência foi uma das importantes observações dos estudos de validação do ambiente.

As visões globais foram introduzidas na Seção 5.1. Essas visões são utilizadas no SME para dar suporte às estratégias diferenciais. O que muda nestas visões entre o SM e o SME é a coloração. No caso do SME, a coloração vai depender da estratégia de análise sendo utilizada. Nos Capítulos6e7serão apresentadas as estratégias diferenciais suportadas pelo SME e seus

4_{Apesar do SourceMiner conter outras visões, decidimos focar o estudo de evolução nas três visões, sendo que}

5.3. SOURCEMINER EVOLUTION - SME

sistemas de coloração. Aqui nesta seção, como forma de complementação, explicaremos as visões sob demanda: Parallel Coordinates e Timeline Matrix.

A visão Parallel Coordinates (Mazza,2009) retrata a evolução de várias métricas, ao mesmo tempo. Um esboço desta visão é apresentado na Figura5.3e um exemplo de sua instanciação no SME é apresentado na Figura5.4-F. Nesta visão, o eixo Y mostra o valor da métrica. O eixo X mostra cada versão do projeto, previamente analisadas pelo SME. Nos trabalhos que encontramos na literatura, a visão Parallel Coordinates era utilizada como uma visão independente para mostrar as métricas. No SME ela funciona dentro de um contexto, integrada às outras visões. Assim, ela funciona como um detalhe sob demanda na visualização de módulos de software selecionados. Quando o usuário identifica um elemento de interesse em uma das quatro outras visões, ele pode interagir com o mouse sobre o elemento visual para abrir a evolução temporal desse elemento na visão Parallel Coordinates. Cada linha das coordenadas paralelas representa, por uma cor diferente, a evolução de uma métrica do módulo selecionado.

A segunda visão sob demanda é a Timeline Matrix. Esta visão é uma contribuição original desta tese (Novais et al.,2012c). A visão Timeline Matrix retrata a evolução do software em detalhessob demanda de um até três módulos de software. Um esboço dessa visão é apresentado na Figura5.3, e um exemplo de sua instanciação no SME é apresentado na Figura5.4-D. Cada linha desta matriz 3x3 é chamada de timeline (linha do tempo). Cada uma das três timelines pode representar a evolução de um módulo em três versões SME sequenciais Vk−1, Vk, Vk+1. Uma vez que o módulo de software é identificado em uma das visões globais - Treemap, Polymetric ou Dependency, o usuário pode interagir com o mouse sobre o elemento visual para abrir a evolução temporal desse elemento na visão Timeline Matrix.

Os três timelines podem retratar a evolução do mesmo ou de diferentes módulos. Quando solicitado apenas um módulo a ser representado nos três timelines, nove versões desse módulo podem ser vistas em uma mesma cena visual. Se os timelines representam a evolução de diferentes módulos, o usuário pode realizar uma comparação visual entre eles. Os atributos visuais dos retângulos da Timeline Matrix - comprimento, largura e intensidade de cor - podem ser mapeados para qualquer das métricas disponíveis no SME. Esses atributos visuais desempenham um papel importante na Timeline Matrix. O tamanho do retângulo (altura e largura) e a intensidade de cor são limitados pelo valor máximo da métrica escolhida durante toda a evolução do software. Se uma métrica M é mapeada para a largura do retângulo, a largura máxima será associada ao módulo com o maior valor M na história do software. Todas as outras dimensões de largura são calculadas proporcionalmente. O comprimento do retângulo e intensidade da cor são calculados da mesma forma. Para o caso da cor, a cor mais escura é mapeado para o valor mais alto da métrica M.

A Timeline Matrix usa três cores padrão: azul, vermelho e verde, para representar pacotes, classes e métodos, respectivamente. Estas cores também podem ser configuradas no SME. Além disso, o SME permite colorir a visão Timeline Matrix seguindo a coloração utilizada pela Estratégia Diferencial Absoluta. Um exemplo dessa possibilidade será apresentado no Capítulo

8.

As visões do SME são integradas, coordenadas e interativas. Do ponto de vista de integra- ção, a visão Treemap é utilizada como um ponto de referência para as outras visões. Quando um elemento é identificado nas outras visões em um nível de classe ou pacote, o usuário pode pedir para ver o elemento em detalhe na visão Treemap, detalhando o nível de seus métodos de classe, por exemplo. Do ponto de vista da coordenação, quando um elemento é selecionado em uma visão ele pode ser destacado em outras visões. Finalmente, em termos de interação, os usuários podem usar um conjunto de recursos visuais (zoom in, zoom out, mouse over, clique de mouse, etc.) para pedir detalhes sobre demanda dos elementos mostrados em qualquer visão. Essa integração, coordenação e interação é possibilitada através dos mecanismos de interação (Seção5.3.1.6) e dos Filtros. É importante dizer ainda que a coloração das visões do SME é o mais consistente possível. As três visões globais são decoradas consistentemente de acordo com a estratégia de análise selecionada. A visão Timeline Matrix pode ainda ser colorida de forma consistente com a estratégia Diferencial Absoluta.

O SME utiliza quatro filtros para manipular e configurar as visões. Os filtros de estrutura e feature foram originalmente desenvolvidos para o SM e já foram discutidos na Secão 5.1. Os dois Filtros que foram desenvolvidos no escopo do trabalho desta tese são apresentados na Figura5.4(A) e na Figura5.4-C. O Filtro da Figura5.4-A é o EvolutionFilter View. Ele é o filtro central para a análise de evolução no SME. Neste Filtro têm-se os seguintes componentes:

• Project Filter: é uma barra deslizante (slider) que permite selecionar as duas versões, entre as previamente processadas, para serem comparadas nas estratégias diferenciais. As visões globais mostram sempre a versão do lado direito do slider;

• Color Mode: este componente permite ao usuário selecionar as colorações a serem utilizadas no SME. Atualmente, existem três opções disponíveis. i) Metrics: mostra a coloração original baseada em métricas utilizada pelo SourceMiner, conforme explicado na Seção5.1; ii) Features: mostra a coloração original beseada em interesses (ou Features) utilizada pelo SourceMiner; iii) Evolution: utiliza cores para visualizar a evolução. Quando esta opção é selecionada o usuário deve escolher a estratégia a ser utilizada na visualização da evolução, utilizando o componente Evolution Strategy;

5.3. SOURCEMINER EVOLUTION - SME

• Evolution Strategy: permite intercambiar entre as estratégias Diferencial Relativa, para visualizar evolução de métricas, e Diferencial Absoluta, para visualizar evolução de features;

• Os demais componentes, Polymetric Options, Treemap Options e Coupling Options permitem ao usuário selecionar a métrica a ser aplicada em cada visão correspondente, durante o uso da estratégia Diferencial Relativa.

Por fim, o Filtro da Figura5.4-C é o TimelineFilter View. Este filtro permite selecionar as métricas que serão utilizadas em cada um dos atributos visuais dos retângulos (largura, altura e cor) que representam os módulos de software na visão Timeline Matrix.

5.3.1.4 Perspectivas

O SME tem quatro perspectivas diferentes que são usadas para representar as propriedades do software. Três delas foram herdadas do SM. As perspectivas dizem respeito à forma pela qual olhamos para o software (Carneiro,2011). No contexto de software, a perspectiva pode ser representada por um conjunto de visões coordenadas concebidas para representar um grupo de propriedades do software. Por exemplo, pode-se estar interessado em investigar software de acordo com a sua estrutura. Esta perspectiva Estrutural revela como o software está organizado em pacotes, classes e métodos (no contexto de programação orientada a objetos). Os IDEs geralmente oferecem uma visão hierárquica para esta finalidade. O Package Explorer do Eclipse é um exemplo bem conhecido deste tipo de perspectiva. Essa visão usa uma árvore iconográfica para representar os pacotes do sistema e a estrutura dos seus arquivos. O SME utiliza a visão Treemappara representar esta perspectiva.

Outra perspectiva de interesse em sistemas orientados a objetos (OO) é a perspectiva de Herança. Ela é importante para mostrar visualmente quais as classes que estendem outras classes ou implementam interfaces. Neste caso, também é possível usar uma visão hierárquica, mas o SME não utiliza Treemaps, a fim de evitar confusão. Em vez disso, ele usa a visão Polymetric. A terceira perspectiva discutida aqui é a perspectiva de Acoplamento. Ela representa o acoplamento entre entidades de software, neste caso, os módulos de software que dependem de outros módulos. Uma das visões mais úteis para descrever este tipo de informação é a visão de grafos dirigidos interativos (IDG). O SME utiliza a visão Dependency para tal fim.

A quarta perspectiva do SME é a perspectiva de Mudanças. Essa é uma perspectiva específica de evolução. Neste caso, o objetivo é colocar em evidência as alterações feitas no código. No SME, as visões mostram as mudanças ao longo da história do software retratando assim esta perspectiva.

Outra perspectiva específica de evolução de software é a perspectiva de Autores. Este tipo de perspectiva foca em atividades dos desenvolvedores, como quantos commits eles têm realizado ou em quais arquivos que eles têm trabalhado. Este tipo de perspectiva ajuda a responder perguntas como “Quem executou essas modificações no código?”. O SME ainda não dá suporte a este tipo de perspectiva.

5.3.1.5 Estratégias de Análise

Atualmente o SME dá suporte às estratégias Diferencial Relativa, Diferencial Absoluta, e Temporal Overview5.

As estratégias Diferencial Relativa e Diferencial Absoluta são realizadas pelas três visões globais: TreeMap, Polymetric e Dependency. Nestas visões, as cores são usadas para retratar as diferenças entre as versões do software escolhido. Os esquemas de cores usados para as estratégias Diferencial Relativa e Absoluta, bem como uma explicação detalhada dessas estratégias, são apresentadas nos Capítulos6e7, respectivamente.

A estratégia Temporal é realizada por duas visões: Parallel Coordinates e Timeline Matrix. Como explicado na Seção5.3.1.3, estas são visões sob demanda das visões globais. Elas repre- sentam a evolução temporal de um módulo de interesse, no caso da visão Parallel Coordinates, ou de um a três módulos de interesse, no caso da visão Timeline Matrix. Note que, apesar de serem visões Temporais Overview, elas mostram o software em detalhe.

Ao contrário das estratégias Diferenciais, as cores não são o atributo de definição de nossas estratégias Temporais. Estratégias Temporais devem apresentar várias versões do mesmo módulo. Posicionamento é o atributo visual de escolha para retratar a evolução em si. As visões temporais mostradas nas Figuras3.1,3.2e3.3, por exemplo, usam o eixo X para visualizar temporalmente as versões do módulo. Nossa estratégia temporal usa uma abordagem similar. A visão Timeline Matrixrepresenta a evolução de um conjunto de três retângulos em três linhas da matriz. A evolução é exibida pela ordem dos retângulos em cada linha. Da mesma forma, a visão Parallel Coordinates utiliza o eixo X no gráfico para visualizar as versões ordenadas de um módulo escolhido. É importante ressaltar que esta visão mostra todas as versões do módulo selecionado, enquanto a Timeline Matrix pode mostrar no máximo nove versões de um módulo de software. É importante observar que as duas estratégias diferenciais utilizadas no SME permitem visualizar a evolução do software em detalhes, utilizando as visões globais (TreeMap, Polymetric e Dependency). Por outro lado, é importante chamar a atenção para outro ponto de inovação 5_{Nós também estamos projetando uma visão que usa a estratégia Temporal Snapshot, mas este é um trabalho}

5.3. SOURCEMINER EVOLUTION - SME

desse trabalho. O SME utiliza a estratégia Temporal Overview, comumente utilizada na literatura para visualizar o software globalmente, para visualizar a evolução do software em detalhes. Isto é possível porque as duas visões temporais funcionam sob demanda, focando-se de um até três módulos por vez.

5.3.1.6 Mecanismos de Interação

O SME tem vários mecanismos de interação para manipular as visões e estratégias. Esses mecanismos dão suporte a uma série de operações simples de usar, mas sofisticadas semantica- mente, permitindo a seleção de módulos de interesse, escolha de estratégias, mapeamento de métricas para atributos visuais, filtragem dinâmica das informações, navegação entre as visões, obtenção de detalhes sob demanda, panning sobre as cenas visuais e zoom in e zoom out (gráfico e conceitual) nas cenas visuais. É importante ratificar que as visões e as operações sobre as visões são integradas e coordenadas. Operações como filtragem (por exemplo, usando um widget de barra de intervalo para exibir apenas os módulos de um determinado tamanho de software) são realizadas em todas as visões globais ao mesmo tempo. Clicar para navegação estrutural em uma entidade visual que representa um módulo de software específico em qualquer visão mostra a sua localização na visão Treemap, por exemplo.

Três mecanismos de interação têm realizado um papel importante na utilização do SME. O primeiro é o tooltip que, apesar de simples, permite a obtenção de dados mais específicos sobre um determinado módulo. Permite confirmar valores, crescimentos, e decrescimentos de métricas, bem como realização de features. O segundo é o menu popup. Este mecanismo, assim como o tooltip, permite obter informações sob demanda em relação a um determinado elemento visual (e.g., quais features foram adicionadas ou removidas na evolução), porém ele permite também executar ações sobre esse elemento. Alguns exemplos dessas ações são: a) Open on Treemap: permite que o elemento sob análise seja aberto na visão Treemap para uma análise estrutural. Isto é especialmente importante quando classes, ou pacotes são visualizados em outras visões, e necessitam-se informações detalhadas dos métodos desses elementos; b) Open on Timeline: permite abrir o elemento de interesse em um dos três timelines disponíveis na visão Timeline Matrix. A evolução desse elemento em questão é então visualizada nessa visão; c) Confirm or Reject Feature: permite revisar o mapeamento de features feito para um módulo de software. O terceiro mecanismo é a navegação entre as visões. A Figura5.3mostra as possibilidades de navegação entre as visões. Os usuários podem obter informações específicas, nas diferentes visões de acordo com a tarefa em questão.

Figura 5.4: O SME em ação.