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 limitaçõ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).