BACHARELADO EM ENGENHARIA DE COMPUTAÇÃO
DOUGLAS EDER UNO SILVA
AVALIAÇÃO DA RECUPERAÇÃO ARQUITETURAL DE VISÕES MODULARES A PARTIR DE TÉCNICAS DE AGRUPAMENTO
FEIRA DE SANTANA 2013
AVALIAÇÃO DA RECUPERAÇÃO ARQUITETURAL DE VISÕES MODULARES A PARTIR DE TÉCNICAS DE AGRUPAMENTO
Trabalho de Conclusão de Curso apresentado ao Colegiado de Engenharia de Computação como requisito parcial para obtenção do grau de Bacharel no curso de Engenharia de Computação da Universidade Estadual de Feira de Santana.
Orientador: Prof. Dr. Roberto Almeida Bittencourt
FEIRA DE SANTANA 2013
me apoiaram, direta ou indiretamente na construção desse documento.
Agradecer primeiramente a Deus pelo dom da vida e poder realizar um grande sonho, colar grau.
Agradecer aos meus pais Bosco e Sônia que sempre estiveram ao meu lado e se sacrificando por mim para eu chegar até aqui. Agradeço também pelo apoio de minhas irmãs, Emile, Elaine e Elis.
Agradecer a Cristiane Ribeiro pelo apoio, compreensão e, principalmente, seu amor. Te amo!
Agradeço também a demais familiares, tios, tias, avós, primos e amigos que de alguma forma me ajudaram a atingir meus objetivos.
Agradecer aos colegas do curso pois foram de extrema importância na minha formação.
Agradecer aos professores de curso que se esforçaram para que o conhecimento fosse construído e compartilhado. Agradecendo inclusive ao meu orientador Profo Roberto Almeida Bittencourt de forma especial.
Enfim, agradeço a todos que estiveram participando desse processo, seja direta ou indiretamente. Obrigado!
Algoritmos de agrupamento foram propostos como técnica quase-automática de recuperação arquitetural de visões modulares. Entretanto, poucos trabalhos se debruçaram sobre a avaliação da qualidade dos agrupamentos gerados pelos diferentes algoritmos. Este trabalho apresenta uma avaliação retrospectiva de seis algoritmos através da análise de versões semanais e consecutivas de três sistemas. Para tanto utilizou-se duas métricas de qualidade: autoridade e estabilidade. Em termos gerais os algoritmos aglomerativos apresentaram melhores resultados, tanto na estabilidade quanto na autoridade.
Palavras-chave: evolução de software. arquitetura de software. visão modular. recuperação arquitetural avaliação experimental
Clustering algorithms have been proposed as a semi-automated technique to recover architecture module views. However, few studies have tried to evaluate the quality of clusters generated by different algorithms. This paper presents a retrospective evaluation of six algorithms by analyzing consecutive weekly versions of three systems. To this end, we used two quality metrics: authoritativeness and stability. In general terms the agglomerative algorithms outperformed, both in stability and in authority. Keywords: software evolution. software architecture. modular view. architectural recovery. experimental evaluation
Figura 1 Exemplo de agrupamento. 12
Figura 2 Visão modular de software 16
Figura 3 Características da recuperação arquitetural (POLLET et al., 2007) 17
Figura 4 Algoritmo para execução do K-Means. 19
Figura 5 Matriz de Estrutura de Design (Adaptado de (BROWNING, 2001)) 20
Figura 6 Exemplo de dendograma em algoritmos aglomerativos (ANQUETIL;
LETHBRIDGE, 1999) 22
Figura 7 Exemplo de tokenização 23
Figura 8 Documentos representados como vetores (MANNING; RAGHAVAN;
SCHÜTZE, 2008) 25
Figura 9 Grafo e duas possíveis partições. Adaptado de (MITCHELL;
MANCORIDIS, 2001) 28
Figura 10 Conjunto intracluster e intercluster (MITCHELL; MANCORIDIS, 2001). 29
Figura 11 Aplicando o MeCl (MITCHELL; MANCORIDIS, 2001) 30
Figura 12 Design experimental do estudo 32
Figura 13 Comparação de séries de dados através da métrica Above 36
Figura 14 Aplicando o HML 37
Figura 17 Estabilidade do sistema Sweethome3d 40
Figura 18 Autoridade do sistema Lucene 43
Figura 19 Autoridade do sistema Ant 44
Tabela 1 Entidades de código e seus possíveis relacionamentos
(BITTENCOURT et al., 2009) 16
Tabela 2 Palavras reservadas do Java 24
Tabela 3 Quadro resumo das métricas de qualidade aplicadas 35
Tabela 4 Estabilidade relativa 41
Tabela 5 Métrica HML para estabilidade 41
Tabela 6 Autoridade relativa 46
Tabela 7 Métrica HML para autoridade 46
SAR Software Architecture Reconstruction
SL Single Linkage
CL Complete Linkage
1 INTRODUÇÃO. . . 11
2 FUNDAMENTAÇÃO TEÓRICA . . . 14
2.1 ARQUITETURA DE SOFTWARE . . . 14
2.1.1 VISÕES ARQUITETURAIS MODULARES . . . 15
2.1.1.1 VISÃO MODULAR DE ALTO NÍVEL . . . 16
2.2 RECUPERAÇÃO ARQUITETURAL . . . 17
2.2.1 DADOS DE ENTRADA PARA A RECUPERAÇÃO ARQUITETURAL . . . 18
2.2.1.1 ENTRADAS NÃO-ARQUITETURAIS . . . 18
2.2.1.2 ENTRADAS ARQUITETURAIS . . . 18
2.3 ALGORITMOS DE AGRUPAMENTO . . . 18
2.3.1 K-MEANS . . . 18
2.3.2 MATRIZ DE ESTRUTURA DE DESIGN (DSM) . . . 19
2.3.3 ALGORITMOS HIERÁRQUICOS AGLOMERATIVOS . . . 21
2.4 RECUPERAÇÃO DE INFORMAÇÃO . . . 22
2.4.1 EXTRAÇÃO DE VOCABULÁRIO DE SOFTWARE . . . 23
2.4.1.1 TOKENIZAÇÃO . . . 23
2.4.1.2 REMOÇÃO DE STOP WORDS . . . 23
2.4.1.3 NORMALIZAÇÃO . . . 24
2.4.1.4 STEMMING . . . 24
2.4.2 REPRESENTAÇÃO DE ENTIDADES . . . 25
2.5 MÉTRICAS DE AVALIAÇÃO DE AGRUPAMENTO . . . 27
2.5.1 MOJO E MOJOSIM . . . 27
2.5.2 EDGESIM . . . 28
2.5.3 MECL . . . 29
2.6 AVALIAÇÃO DA RECUPERAÇÃO ARQUITETURAL DE VISÕES MODULARES . . . 31
3 METODOLOGIA . . . 32
3.1 DESIGN EXPERIMENTAL . . . 32
3.2 FERRAMENTAL . . . 33
3.3 SISTEMAS ALVO . . . 33
3.4 EXTRAÇÃO DE MÉTRICAS DAS VERSÕES . . . 34
3.4.1 MÉTRICAS DE AVALIAÇÃO DA QUALIDADE . . . 34
4.1 ESTABILIDADE . . . 38
4.2 AUTORIDADE . . . 43
4.3 RESUMO . . . 47
5 CONCLUSÕES . . . 48
1 INTRODUÇÃO
A maioria dos sistemas de software úteis precisam ser alterados ao longo do tempo, tanto para adicionar novas funcionalidades como para corrigir falhas. Muitas vezes, os sistemas legados podem ser modificados através de medidas emergenciais para manter as aplicações funcionando. Neste caso, é comum fazer a manutenção dos sistemas sem o entendimento completo da estrutura e organização do software. Tais modificações, por menores que sejam, podem alterar o funcionamento de outros componentes do software, comprometendo o seu funcionamento, resultando em reaparecimento de bugs antigos ou na criação de novos. A estrutura do sistema pode deteriorar até o ponto onde a organização do código-fonte se torne tão caótica que o software seja radicalmente reformulado ou abandonado (MANCORIDIS et al., 1998).
Porém, segundo Wiggerts, reescrever todo o sistema, na maioria das vezes, não é uma solução viável (WIGGERTS, 1997). Por essa razão, os engenheiros de software dependem de notações e ferramentas a fim de ajudá-los com a complexidade dos grandes sistemas de software (MANCORIDIS et al., 1998). Dependendo do tamanho do sistema, a tarefa de recuperar sua estrutura original pode ser muito árdua. Por isso, várias abordagens e técnicas vêm sendo propostas na literatura para auxiliar na recuperação arquitetural de software (POLLET et al., 2007).
A recuperação arquitetural possui um papel muito importante, uma vez que busca fornecer respostas para as perguntas dos arquitetos de software de como decompor um sistema em subsistemas menores e recuperar a estrutura original de um sistema legado ou até comparar os modelos documentados com o código-fonte para o aperfeiçoamento do sistema.
As técnicas de recuperação arquitetural são classificados em três tipos: quase-manuais; semi-automáticas e quase-automáticas (POLLET et al., 2007). Na técnica quase-manual, o engenheiro de software identifica manualmente os elementos arquiteturais com o auxílio de uma ferramenta. Na técnica semi-automática, o engenheiro de software instrui a ferramenta com o intuito de identificar elementos arquiteturais. Por fim, na técnica quase-automática, as ferramentas identificam os elementos arquiteturais através de algoritmos próprios.
Algoritmos de agrupamento são técnicas quase-automáticas que procuram identificar grupos de entidades semelhantes a partir de suas características. De maneira geral, pode-se dizer que o agrupamento de entidades em vários grupos, ou módulos, a partir de uma relação de semelhança entre elas é uma forma de modularizar o sistema. Estes agrupamentos, formados por tais algoritmos de
agrupamento, podem ser também chamados de clusters.
Um cluster define uma coleção de entidades agrupadas a partir de algum critério. Como consequência disso, Wiggerts também afirma que cada algoritmo aplicado produz diferentes respostas, isto é, pode impor uma estrutura ao invés de recuperar uma existente como resultado.
De modo geral, estes resultados podem ser avaliados através de métricas, em especial, por métricas que revelem quão similares os resultados de um algoritmo são em relação a um agrupamento de referência produzido manualmente por arquitetos de um dado sistema em análise. A Figura 1 ilustra um agrupamento resultante arbitrário. Cada entidade está representada como um pequeno círculo, enquanto as maiores áreas delimitadoras são os clusters.
Figura 1: Exemplo de agrupamento.
Wu, Hassan & Holt (2005) extraíram versões mensais de alguns sistemas de código aberto e aplicaram diferentes algoritmos de agrupamento nessas versões, definindo as métricas de estabilidade, autoridade e extremidade. De maneira informal, a estabilidade indica que, quando um sistema sofre mudanças, os agrupamentos gerados devem refletir em alto nível essas mudanças. Já autoridade avalia o quanto o agrupamento resultante se aproxima de um agrupamento criado por um arquiteto de software. Finalmente, a extremidade avalia se os agrupamentos resultantes estão gerando clusters muito grandes ou muito pequenos. Neste trabalho foram utilizadas as métricas de Wu, Hassan & Holt (2005), com exceção da extremidade, pois entende-se que, dependendo do sistema, a geração de clusters grandes ou pequenos pode ser uma característica intrínseca da aplicação.
Mitchell & Mancoridis (2001) utilizaram um algoritmo de agrupamento aplicado cem vezes a dez sistemas diferentes, a fim de avaliar quatro métricas de similaridade, isolando entidades especiais para melhorar a similaridade. Bittencourt & Guerrero (2009) usaram as mesmas métricas de Wu, Hassan & Holt (2005) para avaliar a
recuperação arquitetural sobre a evolução de diferentes versões de quatro sistemas. Entretanto, em vez de versões mensais, eles utilizaram releases como o intervalo entre versões e mediram autoridade a partir de visões modulares baseadas nos pacotes Java dos sistemas. Apesar de estes trabalhos avançarem no processo de avaliação de técnicas de agrupamento, eles não incluem as visões arquiteturais de referência produzidas pelos próprios desenvolvedores dos sistemas analisados. Este trabalho procura suprir esta lacuna, incluindo os modelos arquiteturais disponíveis pelos desenvolvedores na avaliação dos três algoritmos de agrupamento estudados.
O capítulo 2 irá fundamentar todo o estudo, mostrando as técnicas a serem utilizadas para a recuperação arquitetural a partir de dependência estrutural e recuperação de informação. O capítulo 3 abordará os passos necessários para alcançar os objetivos desse trabalho. O capítulo 4 tratará dos resultados obtidos com este estudo. O capítulo ?? irá levantar uma breve discussão sobre os resultados gerados e, por fim, o capítulo 5 que irá tratar das considerações finais levantadas.
2 FUNDAMENTAÇÃO TEÓRICA 2.1 Arquitetura de Software
A década de 1990 viveu um crescimento exorbitante na área da engenharia de software com relação à definição do termo arquitetura de software (GORTON, 2006). Para Gorton, o termo "arquitetura", se tornou uma expressão muito genérica, fazendo com que os profissionais utilizassem esse termo de forma vaga, sem ter uma definição mais concisa, inclusive ele.
Uma primeira definição pode ser extraída segundo Jen & Lee (2000), onde a arquitetura é definida como as práticas recomendadas de forma que seja a principal organização do sistema, incorporando em seus componentes, seus relacionamentos e o ambiente e os princípios que gerem seu design e evolução.
Uma segunda definição para a expressão arquitetura de software pode ser retirada de Bass, Clements & Kazman (2003):
"A arquitetura de software de um programa ou sistema de computação é a estrutura ou estruturas de um sistema, e compreende elementos de software, as propriedades visíveis exteriormente dos referidos elementos, e as relações entre eles".
Nessas duas definições, é possível enxergar características em comum sobre a arquitetura de software e extrair os conceitos mais fundamentais. A definição dos elementos de software e seus relacionamentos é uma delas.
Para entender melhor, Bass aborda uma analogia muito interessante dos sistemas de software e a anatomia humana. Assim como um sistema de computação, o corpo humano é formado por diferentes sistemas (circulatório, nervoso, muscular, etc...), formando o corpo humano (BASS; CLEMENTS; KAZMAN, 2003).
Além disso existem as visões nas quais um profissional da área de saúde enxerga o corpo humano. Por exemplo, um cardiologista possui uma visão diferente do neurologista e assim por diante. Logo um diagnóstico completo pode ser feito a partir da análise de cada visão conhecida.
Assim como as visões dos médicos, a arquitetura de software possui também diversas visões, cada uma abordando diferentes elementos. Ao unir todas elas, o sistema estará bem documentado e todas as suas propriedades e relações estarão claras. Segundo Bass, Clements & Kazman (2003), as visões de software são três:
• Alocação • Modular
Na visão componente e conector os elementos são componentes e conexões em tempo de execução. Deste modo, esta visão busca entender melhor a interação entre os processos em execução, a concorrência e os dados compartilhados entre eles.
A visão de alocação se preocupa com a relação dos componentes de software com os do meio externo onde o sistema é criado e executado. O componente pode estar relacionado tanto a um elemento de hardware quanto à uma equipe de desenvolvedores que irá implementa-lo.
A visão modular é constituída de elementos de código do sistema (e.g., arquivos, classes, pacotes, métodos) e as relações são as dependências estruturais estáticas entre estes elementos (e.g., uso, chamada, herança). A Seção 2.1.1 explicará melhor sobre os possíveis tipos de dependência que os sistemas de software podem gerar.
2.1.1 Visões Arquiteturais Modulares
Em códigos-fonte, entidades e suas relações podem ser extraídas através de técnicas de análise estática. As entidades podem ser atributos, métodos, classes ou arquivos, contudo, essas entidades possuem dependências que podem ser expressas de várias formas, como de uso, chamada ou herança. A Tabela 1 ilustra uma lista de entidades e relações extraídas com análise estática através da ferramenta Design Suite que será melhor descrita na seção 3.2.
Tabela 1: Entidades de código e seus possíveis relacionamentos (BITTENCOURT et al., 2009)
Na tabela 1, a coluna intitulada Source Entity indica as entidades que podem ser extraídas no código-fonte. A coluna Relation indica as dependências estruturais nas quais as entidades podem estabelecer umas com as outras.
2.1.1.1 Visão Modular de Alto Nível
Wiggerts (1997) aborda o uso de grafos compostos por camadas onde cada uma representaria um nível de abstração do sistema. Assim, a camada mais baixa constituiria o nível mais baixo de código, e, ao subir na hierarquia, subsistemas seriam compostos por elementos de camadas mais abaixo (WIGGERTS, 1997). Desta maneira, a visão arquitetural modular se daria a partir de um grande grafo contendo vários subgrafos, e as arestas representariam as dependências entres entre os nós e os subgrafos. A Figura 2 ilustra a visão modular do Linux.
A camada mais baixa seria então composta por elementos indivisíveis, caracterizando a menor unidade de informação do código-fonte. De acordo com a tabela 1, os menores elementos de código podem ser os atributos e métodos, pois, estas duas entidades sempre estão contidas nas classes. A partir disto, pode-se visualizar então um primeiro nível somente com atributos e métodos, um acima com as classes que contenham os atributos e métodos e, por fim, os pacotes que contenham essas classes do sistema.
2.2 Recuperação Arquitetural
A recuperação arquitetural (Software Architecture Reconstruction - SAR ) pode ser de três tipos como foi dito no Capítulo 1. Além disso, a recuperação arquitetural apresenta outras características como seus objetivos, entradas e saídas como apresentado na Figura 3.
Figura 3: Características da recuperação arquitetural (POLLET et al., 2007)
A aplicação de técnicas semi-automáticas ajuda a realizar a tarefa de agrupar componentes do sistema. Contudo, agrupar entidades de um sistema de software é organizá-las de tal forma que possam formar grupos coesos e relativamente independentes. Porém, esta tarefa não é simples e, por isso, é grande o desafio da engenharia reversa. Para tentar resolvê-lo, a comunidade da área propôs utilizar técnicas bem-sucedidas na área de reconhecimento de padrões, como algoritmos de agrupamento, para prover soluções quase-automáticas ao problema.
Diversos algoritmos de agrupamento foram propostos na literatura. Dentre eles, destacam-se três: K-Means, Matriz de Estrutura de Design e Aglomerativos. Estes
algoritmos serão descritos na Seção 2.3.
2.2.1 Dados de Entrada para a Recuperação Arquitetural
A recuperação arquitetural pode trabalhar com diversos tipos de entrada classificadas em dois tipos: arquitetural e não-arquitetural (POLLET et al., 2007). Frequentemente os métodos de recuperação arquitetural trabalham com códigos-fonte mas considera também outros tipos de informação.
2.2.1.1 Entradas Não-arquiteturais
Os tipos de entradas não-arquiteturais são:
Código-fonte: Predominantemente utilizado em processos de recuperação arquitetural, realizando buscas a partir de expressões regulares no código-fonte. Informação textual simbólica: Informação simbólica em comentários e nome de
métodos.
Informação dinâmica: Informações a partir de rastros de execução do software. Organização física: Organização dos arquivos, pastas e pacotes.
Organização humana: A estrutura da organização reflete na arquitetura do software. Informação histórica: Pouco utilizada e tenta trabalhar com a evolução simultânea
entre o código e o design.
Habilidade humana: Para altos níveis de abstração, a recuperação arquitetural é iterativa e necessita de intervenção humana para guiá-lo e validar os resultados.
2.2.1.2 Entradas Arquiteturais
Os tipos de entradas arquiteturais são:
Estilos Assim como padrões de projeto, os estilos representam situações arquiteturais recorrentes.
Pontos de vista Analisar diferentes visões de stakeholders do sistema.
2.3 Algoritmos de Agrupamento 2.3.1 K-Means
A versão utilizada do algoritmo K-Means foi uma versão mais eficiente proposta por Hartigan e Wong (HARTIGAN; WONG, 1979).
O objetivo do algoritmo K-Means é dividir M pontos com N dimensões em K agrupamentos, minimizando a distância intraclusters e maximizando a distância interclusters. A expressão minimizar a distância intracluster quer dizer que as entidades dentro de um cluster ficam muito próximas umas das outras. Maximizar a distância interclusters é fazer com que o espaço entre os clusters tendam a ser cada vez maior.
O algoritmo precisa de uma matriz de M pontos com N dimensões e outra matriz com os centroides iniciais dos K clusters em N dimensões (HARTIGAN; WONG, 1979). A tarefa principal é particionar o sistema em K agrupamentos através de K centroides iniciais, representando os centros dos K agrupamentos. Desta forma, cada elemento do sistema é associado ao centroide mais próximo. Logo após, os centroides tem seus valores atualizados a partir dos elementos que passaram a pertencer aos agrupamentos correspondentes. Esse processo se repete até que algum critério de parada seja satisfeito. A Figura 4 apresenta o algoritmo básico do K-Means.
Figura 4: Algoritmo para execução do K-Means.
2.3.2 Matriz de Estrutura de Design (DSM)
A DSM é uma matriz quadrada com rótulo de linha e coluna idênticos, onde cada linha e coluna representam um elemento do sistema. Cada marca, fora da diagonal principal, indica uma dependência entre dois elementos. Uma DSM mostra a relação entre os componentes de um sistema num formato compacto, visual e analiticamente vantajoso (BROWNING, 2001). A Figura 5 apresenta um exemplo de matriz de estrutura de design e a diagonal principal representando os elementos.
Figura 5: Matriz de Estrutura de Design (Adaptado de (BROWNING, 2001))
Segundo Browning (2001), as DSMs são divididas em duas categorias: estática e baseada no tempo. DSMs estáticas são geralmente utilizadas com algoritmos de agrupamento. DSMs baseadas no tempo levam em consideração a ordenação das linhas e colunas, a partir de algoritmos de sequenciamento, fugindo do escopo desse trabalho.
Dentre as DSMs estáticas, tem-se as baseadas em pessoas e as baseadas em componentes. Uma DSM baseada em pessoas é usada para modelar estruturas organizacionais a partir de pessoas, grupos e suas interações (BROWNING, 2001). Uma DSM baseada em componentes documenta interações entre elementos em uma arquitetura de sistema. Uma DSM, assim como o K-Means, minimiza a distância intra-clusters e maximiza a distância inter-clusters. Para isso, o algoritmo busca a DSM que otimize uma função objetivo.
Esta função, no contexto de software, descreve o custo dos componentes a partir do custo de cada componente individualmente (PEREIRA; ELIAS, 2010). Dado um componente Ci o seu custo é fixado a partir das dependências em relação aos outros componentes da DSM. A equação 1 representa o custo de um componente do sistema. custo(Ci) = t
∑
j=1 DSM(i, j) ∗ npowcc (1)onde t é o número de componentes na DSM, DSM(i, j) é o valor da dependência do componente i em relação ao componente j na DSM. O termo n é o número de componentes no agrupamento contendo os componentes i e j, caso pertençam ao mesmo agrupamento, ou caso contrário, representa o valor t, como se todos os elementos na DSM formassem um agrupamento único. O parâmetro powcc permite ajustar a importância do tamanho do agrupamento sobre o custo. Por exemplo, se powcc é igual 0, o tamanho dos agrupamentos não exerce qualquer influência sobre o
cálculo do custo. Porém, se powcc é igual a 1, o custo de coordenação irá aumentar proporcionalmente ao tamanho dos agrupamentos, enquanto que se é igual a 2 é mantida uma relação quadrática, i.e., com o aumento do powcc a relevância aumenta. Assim, o custo total é calculado a partir das somas dos custos individuais dos componentes do sistema de software, como pode ser visto na Equação 2.
custoTotal= t
∑
i=1custo(Ci) (2)
O algoritmo inicialmente atribui cada componente a um agrupamento e o custo inicial total é calculado. Qualquer agrupamento formado a partir desse ponto deve reduzir o custo total inicial e, dessa forma, o algoritmo é configurado para iterar até que o custo total não possa ser mais melhorado após algumas tentativas. Em seguida, um componente é selecionado aleatoriamente para o cálculo do vínculo deste com cada agrupamento, definindo a dependência dos membros de um agrupamento com relação ao componente selecionado. A Equação 3 refere-se ao cálculo do grau de associação entre um componente Ci e os membros do módulo Mk(vinculo(Ci, Mk)).
vinculo(Ci, Mk) = (∑Nk
j=1DSM(i, j) + DSM( j, i))powdep
Nkpowbid (3)
O numerador representa a soma das dependências entre o componente escolhido e cada componente do módulo Mka partir da DSM e Nk equivale ao número de componentes do módulo Mk. O termo powdep permite definir a relevância da dependência entre componentes e powbid determina a importância do tamanho dos agrupamentos, ambos sobre o vínculo entre um componente e um agrupamento. É recomendado atribuir um valor entre 0 e 2 para powdep e entre 0 e 3 para powbid (PEREIRA; ELIAS, 2010)
2.3.3 Algoritmos Hierárquicos Aglomerativos
Os algoritmos hierárquicos aglomerativos começam com entidades individuais, cada uma em um cluster. Em cada passo, entidades são agrupadas até que se forme um grande cluster, contendo todas as entidades (ANQUETIL; LETHBRIDGE, 1999). O algoritmo aglomerativo constrói uma estrutura particular de árvore a partir das folhas, chamada de dendograma, onde as folhas são as entidades do sistema e o nó raiz é composto por todas as entidades juntas em uma única partição.
Assim, a fim de obter um agrupamento, deve-se definir um ponto de corte pertinente. Se o corte for feito na altura zero, serão obtidos clusters unitários e se
o corte for feito na altura máxima, todo o sistema será o único cluster (ANQUETIL; LETHBRIDGE, 1999). A Figura 6 ilustra um dendograma produzido por um algoritmo aglomerativo.
Figura 6: Exemplo de dendograma em algoritmos aglomerativos (ANQUETIL;
LETHBRIDGE, 1999)
Partindo da altura zero, critérios podem ser utilizados para decidir quais entidades serão agrupadas, influenciando diretamente no resultado final do agrupamento, dado um ponto de corte previamente estabelecido. Dois métodos utilizados são o Single Linkage ( SL ) e o Complete Linkage ( CL ). O SL determina a distância entre dois clusters como a mínima entre eles e o CL define a distância como a máxima entre eles. As equações 4 e 5 mostram o cálculo de distância dos dois critérios.
SL: d = min(d1, d2) (4)
CL: d = max(d1, d2) (5)
A partir do cálculo da distância entre os clusters, o SL ou CL agruparão as entidades de acordo com sua regra de distância. SL também é conhecido como regra da vizinhança mais próxima e CL como regra da vizinhança mais distante (ANQUETIL; LETHBRIDGE, 1999).
2.4 Recuperação de Informação
A RI é o ato de procurar material de uma natureza não-estruturada que satisfaça uma necessidade de informação a partir de largas coleções. Geralmente esse material é um conjunto de documentos em forma de texto armazenados em computadores (MANNING; RAGHAVAN; SCHÜTZE, 2008). No caso da engenharia de software, a recuperação de informação é muito utilizada para a extração dos
vocabulários de software dos sistemas alvo.
Segundo Manning, Raghavan & Schütze (2008) para que a RI possa ser corretamente utilizada deve-se realizar quatro etapas, mas, para a extração do vocabulário de software realiza-se basicamente duas:
1. Coletar os arquivos com código-fonte do sistema alvo
2. Realizar pre-processamento linguístico na coleção de códigos-fonte do sistema alvo
Neste caso os documentos são arquivos contendo o código-fonte dos sistemas e o pré-processamento linguístico trata a sequência de caracteres a partir de quatro etapas. Ao fim da execução dessas quatro etapas, obtém-se o vocabulário do software. O vocabulário de software é o conjunto de palavras utilizadas para construir o sistema. As quatro etapas que geralmente acontecem para a extração do vocabulário são elas: Tokenização, remoção de stop words, normalização e stemming.
2.4.1 Extração de Vocabulário de Software 2.4.1.1 Tokenização
Dada uma sequência de caracteres e uma unidade de documento definida, a tokenização é a tarefa de quebrá-los em pedaços chamados tokens e talvez retirar outros como pontuação (MANNING; RAGHAVAN; SCHÜTZE, 2008). Um token é uma instância de uma sequência de caracteres de um documento particular que são agrupados como uma útil unidade semântica para serem processados. A Figura 7 ilustra a tokenização da assinatura de um método.
Figura 7: Exemplo de tokenização
2.4.1.2 Remoção de Stop Words
Às vezes, algumas palavras extremamente comuns provavelmente são de pouco valor com relação ao auxílio da seleção de documentos correspondentes à necessidade do usuário. Essas palavras são chamadas de stop words (MANNING; RAGHAVAN; SCHÜTZE, 2008).
A estratégia mais empregada para determinar uma lista de stop words é ordenar os termos pela quantidade de vezes que aparecem em toda a coleção de documentos e, por fim, retirar as palavras mais frequentes. Duas stop words muito conhecidas na linguagem Java são as expressões get e set, pois são muito utilizadas e não são muito úteis para diferenciar um documento do outro. Além do get e set existem as palavras reservadas da linguagem que obrigatoriamente são stop words. A Tabela 2 apresenta uma lista das palavras reservadas do Java.
Tabela 2: Palavras reservadas do Java
2.4.1.3 Normalização
Segundo Manning, Raghavan & Schütze (2008), existem casos em que duas sequências de caracteres não são exatamente iguais mas é desejável que sejam correspondentes, dessa forma, os tokens passam por uma etapa de equivalência, na qual se elimina diferenças superficiais entre eles.
2.4.1.4 Stemming
As linguagens permitem o uso das palavras de diferentes formas, como o uso do plural, gerúndio, presente e passado. Aliado a isso, existem famílias de palavras que são derivadas de uma outra e com significados similares como Controll e Controller muito utilizados em modelos MVC de programação. A partir disso, os radicais são extraídos das palavras com o intuito de fazê-las equivalentes quando buscadas, logo, ao se fazer uma consulta por Controll, Controller também será retornado ao usuário.
2.4.2 Representação de Entidades
Com o aumento do tamanho das coleções, o número de documentos correspondentes podem exceder muito a quantidade que um ser humano poderia examinar (MANNING; RAGHAVAN; SCHÜTZE, 2008). Logo, tornou-se necessário pontuar e ordenar os documentos. Os termos são contados em cada documento e sua importância é então calculada baseada nas estatísticas de aparecimento dele no documento. Por fim, cada documento é tratado como um vetor onde cada posição indica o peso de cada termo. Esse modelo de representação é conhecido como modelo de espaço vetorial (Vector Space Model). Dessa forma cada vetor possui dimensão igual a quantidade de termos no documento que está sendo representado. A Figura 8 ilustra a representação de documentos em vetores no espaço.
Figura 8: Documentos representados como vetores (MANNING; RAGHAVAN; SCHÜTZE, 2008)
Para que o modelo seja construído deve-se montar o vetor de pesos adequadamente de acordo com a coleção a ser pesquisada. A abordagem mais simples é associar o peso do termo à quantidade de vezes que apareceu no documento. Essa forma de pontuar é chamada de frequência dos termos (term frequency ) e é denotado por t ft,d onde t é o termo e d é o documento (MANNING; RAGHAVAN; SCHÜTZE, 2008).
Porém, quando termos se repetem muito na coleção, é necessário adotar outra abordagem para contagem, pois esses termos repetitivos acabam perdendo relevância. Uma segunda abordagem é contar a quantidade de documentos que contenham um termo t chamado de frequência em documento (document frequency )
e é definido como d ft. A partir disso, é definida a frequência inversa do documento (inverse document frequency ) denotada por id f , onde:
id ft= log N
d ft (7)
onde N é o número de documentos da coleção e o logaritmo é na base 10.
Assim, quando o termo for muito frequente, o seu id f será baixo e quando o termo for muito raro, o seu id f será alto.
Combinando as duas abordagens tem-se a composição de pesos para cada termo em cada documento (MANNING; RAGHAVAN; SCHÜTZE, 2008). Assim, a t f− id f é definida como a multiplicação do valor retornado pelo t f e pelo id f como na equação 8:
t f− id ft,d = t ft,d× id ft (8) t f−id f atribui ao termo t um peso no documento d no qual assume valores mais altos quando t ocorre muitas vezes em um conjunto de documentos e valores menores quando t ocorre poucas vezes em um ou em diversos documentos. Os valores de t f− id f são ainda menores quando o termo ocorre em todos os documentos.
Após o cálculo da pontuação, sendo com t f , id f ou t f − id f , o vetor pode ser montado. Mas como saber se dois documentos são similares ou distantes? Tratando-se de dois vetores, pode-se calcular a similaridade entre eles a partir da computação da distância entre eles.
Uma das formas de se computar a distância entre dois vetores é o cosseno que pode ser calculado pelo produto vetorial divido pelo produto das normas euclidianas, ou seja:
sim(d1, d2) =| ~V (d1) | · | ~V (d2) |
| ~V (d1) | | ~V (d2) | (9)
onde o produto vetorial é dado por ∑Mi=1xiyi e a norma euclidiana q
∑Mi=1~Vi2(d).
O conjunto desses vetores formam uma matriz de tamanho m × n onde m é o tamanho do vocabulário do conjunto de documentos e n é a quantidade de documentos na coleção e é chamada de matriz termo-documento (term-by-document matrix ) (LUCIA et al., 2012).
Porém existem dois problemas muito clássicos na área de RI pois são intrínsecas da linguagem natural: A sinonímia e a polissemia (MANNING; RAGHAVAN; SCHÜTZE, 2008). A sinonímia é o fenômeno de palavras diferentes que significam a
mesma coisa. Já a polissemia indica que uma única palavra pode trazer consigo diversos significados.
A técnica de Indexação Semântica Latente (LSI), do inglês Latent Semantic Indexing, reduz o espaço de conceitos decompondo uma matriz termo-documento em:
A= T · S · DT (10)
Onde T é a matriz termo-conceito, D é a matriz documento-conceito e S é a matriz diagonal com os autovalores dos conceitos. (LUCIA et al., 2012)
Dessa forma, o LSI tenta identificar palavras sinônimas e polissêmicas, diminuindo o tamanho da matriz termo-documento e, por consequência, diminuindo também o processamento sobre essa matriz agora reduzida.
2.5 Métricas de Avaliação de Agrupamento 2.5.1 MoJo e MoJoSim
Tzerpos e Holt (TZERPOS; HOLT, 1999) definiram uma métrica de dissimilaridade entre duas partições arquiteturais chamada de MoJo. Esse cálculo é baseado nas operações para transformar uma decomposição na outra. O MoJo permite basicamente duas operações: move e join (TZERPOS; HOLT, 1999).
Move implica retirar a entidade de um cluster, alocando em outro, e Join implica unir dois clusters existentes, decrementado o número de clusters em uma unidade. Assim, o valor de MoJo entre duas partições A e B pode ser calculado através da equação 11 (TZERPOS; HOLT, 1999).
MoJo(A, B) = min(mno(A, B), mno(B, A)) (11) Onde mno(A, B) retorna o número mínimo de moves e joins para transformar a partição A em B. O operador min() deve ser aplicado devido ao MoJo não ser reflexivo, isto é, geralmente mno(A, B) 6= mno(B, A). Para medir similaridade entre dois agrupamentos, define-se MoJoSim como na Equação 12 (BITTENCOURT; GUERRERO, 2009).
MoJoSim(A, B) = 1 −MoJo(A, B)
n (12)
2.5.2 EdgeSim
Esta métrica foi definida por Mitchell & Mancoridis (2001) em seu artigo para tentar suprir as deficiências do MoJo, pois esta medida de similaridade, como não considera as arestas entre as entidades, ao realizar uma operação de move ou join, decomposições arquiteturais razoavelmente diferentes resultam em valores altos de MoJoSim. Apesar de necessitar de uma quantidade baixa de operações pode ser muito diferente da outra. Desta forma, pretende-se associar tanto as arestas quanto os vértices de um grafo particionado.
Dado um grafo G = (V, E) representando a estrutura de um sistema de software sendo V o conjunto de módulos ou classes e E o conjunto de dependências ponderadas entre os módulos ou classes. Esses pesos geralmente indicam a força do relacionamento entre os pares de módulos em um sistema.
O objetivo do EdgeSim é mapear pares de arestas que são intracluster ou cluster em ambos os agrupamentos a serem comparados. Arestas intracluster são arestas que conectam vértices que se localizam em um mesmo cluster. Arestas intercluster são as quais conectam vértices que se localizam em clusters distintos em ambos agrupamentos. A Figura 9 ilustra um grafo de um sistema qualquer no lado esquerdo e duas possíveis partições resultantes no centro e na direita. Essa mesma figura será utilizada como exemplo base tanto para esta métrica quanto para o MeCl que será descrito na seção 2.5.3.
Figura 9: Grafo e duas possíveis partições. Adaptado de (MITCHELL; MANCORIDIS, 2001)
No fim do cálculo da similaridade, o EdgeSim irá dispor de um conjunto de pares de arestas as quais serão intracluster ou intercluster tanto em A quanto em B. Para simplificar, esta coleção de arestas será chamada de conjunto ϒ. A Figura 10
ilustra o conjunto ϒ baseado nas partições A e B da Figura 9 através das arestas em negrito.
Figura 10: Conjunto intracluster e intercluster (MITCHELL; MANCORIDIS, 2001).
A partir da computação do conjunto ϒ (intraclusters e interclusters), o EdgeSim(A,B) é definido como:
EdgeSim(A, B) = pesos(ϒ)
pesos(E)× 100 (13)
onde pesos(ϒ) é a soma dos pesos das arestas do conjunto ϒ. No caso de arestas sem peso, basta assumir que elas possuem peso 1. A multiplicação por 100 é somente para converter para a forma de porcentagem pois o EdgeSim gera valores entre 0 e 1 no qual000expressa dissimilaridade e010indica total similaridade.
Ao contrário do MoJo e do MeCl (Seção 2.5.3), o Edgesim possui a propriedade de ser reflexivo, logo: EdgeSim(A, B) = EdgeSim(B, A) (MITCHELL; MANCORIDIS, 2001).
2.5.3 MeCl
Assim como o EdgeSim, o MeCl também foi idealizado por Mitchell & Mancoridis (2001) para complementar o EdgeSim, verificando a similaridade entre duas partições a partir de uma perspectiva diferente, considerando também tanto os vértices quanto as arestas. A palavra MeCl, do inglês (Me = Merge e Cl = Cluster ), surgiu pelo fato da métrica dividir uma partição em clusters menores e em seguida reestrutura-los a fim de gerar a outra partição.
partições de B gerando subgrafos. Para a partição A tem-se os clusters {A1, A2e A3} e para B temos os clusters {B1e B2}, sendo assim, seis combinações são necessárias para verificar a intersecções de A para cada cluster de B. A intersecção de A1 com B1 é A1,1, de A1 com B2 é A1,2 e assim sucessivamente até A3,2 neste caso. Finalmente, cada partição de B é união de todas interseções de A realizadas com a partição de B como pode ser visto na Figura 11.
Figura 11: Aplicando o MeCl (MITCHELL; MANCORIDIS, 2001)
Para B1 temos a junção das interseções feitas de A com o B1 e para B2 temos a junção das interseções feitas de A com o B2. Neste caso, como A3,1 não possui intersecções, então não contribui para a métrica, não sendo necessário expor na equação.
Por fim, a computação do MeCl é definida como a junção de arestas interclusters introduzidas a partir do processo de fusão dos subconjuntos. Neste exemplo os subconjuntos são A1,1, A1,2, A2,1, A2,2 e A3,2, logo:
MeCl(A, B) = 1 −pesos(ϒB)
pesos(E) × 100 (14)
Onde pesos(ϒB) é a soma dos pesos do conjunto de arestas que são intraclusters em A mas são interclusters em B, gerando custos quando inserindo novas arestas interclusters. Da mesma forma, se as arestas não são ponderadas, então considera-as como peso 1 e a multiplicação por 100 é para transformar em percentagem.
Como já dito na Seção 2.5.2, o MeCl não é reflexivo, logo MeCl(A, B) 6= MeCl(B, A), sendo necessário fazer o cálculo do MeCl como na Equação 15.
MeClBidirectional(A, B) = min(MeCl(A, B), MeCl(B, A)) (15) Onde MeClBidirectional é o valor mínimo do MeCl entre A e B e entre B e A.
2.6 Avaliação da Recuperação Arquitetural de Visões Modulares
É de relevância para a comunidade acadêmica poder medir a eficácia dos algoritmos de agrupamento para a recuperação arquitetural de software. O uso das métricas definidas na seção 2.5 permite este tipo de avaliação.
Trabalhos prévios analisaram seus agrupamentos resultantes através de métricas de avaliação. Wu, Hassan & Holt (2005) analisaram versões mensais com seis algoritmos, usando as visões arquiteturais extraídas a partir da estrutura de diretórios. Bittencourt & Guerrero (2009) analisaram versões usando as visões arquiteturais retiradas da hierarquia de pacotes Java. Mitchell & Mancoridis (2001) analisaram um algoritmo de agrupamento a partir de várias métricas de similaridade. Porém, esses trabalhos não usaram visões arquiteturais reais providas por desenvolvedores.
Neste trabalho serão avaliados os algoritmos DSM, K-Means e aglomerativos usando visões arquiteturais fornecidas pelos desenvolvedores dos sistemas alvo, a partir de versões semanais extraídas dos repositórios de três sistemas.
3 METODOLOGIA 3.1 Design Experimental
Figura 12: Design experimental do estudo
A Figura 12 ilustra o design experimental deste trabalho. Primeiramente, versões sucessivas e semanais foram extraídas de repositórios, aqui chamadas de V1 até Vn. Em seguida, essas versões foram compiladas para a extração dos grafos de design das versões dos sistemas. Com os grafos das versões, aplicamos os algoritmos de agrupamento K-Means, Matrizes de Estrutura de Design (DSM) e Aglomerativos, gerando agrupamentos (ou clusters), aqui chamados de A1 até An. Finalmente, empregamos as métricas de autoridade e estabilidade nessas versões para cada sistema, geramos alguns gráficos resultantes dessas métricas e os analisamos.
Os algoritmos de agrupamento utilizados foram três, todavia, os algoritmos aglomerativos foram aplicados com quatro configurações distintas utilizadas também por Wu, Hassan & Holt (2005) e foram elas: SL75, SL90, CL75 e CL90, totalizando seis técnicas de agrupamento.
Vale ressaltar que os algoritmos aglomerativos aplicados nesse estudo são baseados em recuperação de informação, ou seja, os agrupamentos produzidos são baseados no vocabulário de software extraído da versão em análise. Já o KMeans e
DSM são aplicados baseado na dependência estrutural dos elementos.
Como visto na Seção 2, o algoritmo K-means precisa do número de clusters como entrada. Por isso, decidimos utilizar 10% da quantidade de classes dos sistemas alvo como padrão.
3.2 Ferramental
Para que esse estudo fosse possível, foi utilizado um conjunto de ferramentas chamada de Design Suite (BITTENCOURT et al., 2009). A Design Suite consiste em um grande conjunto de funcionalidades implementadas através da linguagem de programação Java, com o intuito de dar um maior suporte à área de recuperação arquitetural. Abaixo encontra-se algumas mais utilizadas nesse trabalho:
• Extração automática dos repositórios de software; • Extração dos grafos de baixo nível;
• Algoritmos de agrupamento explicados nas seções 2.3.1, 2.3.2, 2.3.3 já implementados;
O estudo e a utilização dessa ferramenta foi um passo fundamental para a pesquisa, pois, a partir dela, o design experimental abordado na seção 3.1 pôde ser colocado em prática.
3.3 Sistemas Alvo
Definindo como o estudo seria realizado, foram escolhidos três sistemas reais e de código aberto para facilitar a reprodução deste estudo. Chamaremos estas aplicações de sistemas alvo. São eles:
• Lucene: Biblioteca de recuperação de informação totalmente escrita em Java. 1 • SweetHome3D: aplicativo de design de interiores que permite a colocação de
móveis em plantas 2D com visualização 3D. 2
• Ant: Ferramenta popular de construção automática baseada em Java. 3
Com os sistemas alvo estabelecidos, foi necessário adquirir as visões arquiteturais dos desenvolvedores. Para tanto, usamos as visões arquiteturais disponibilizadas por Bittencourt (2012). Desta forma, a visão arquitetural está definida para a métrica de autoridade.
1http://lucene.apache.org/
2http://www.sweethome3d.com/index.jsp 3http://ant.apache.org/
3.4 Extração de Métricas das Versões
Abaixo estão descritos os passos de forma resumida para execução do trabalho ilustrado na Figura 12.
1. Esse estudo tem como base a extração de versões semanais de três sistemas de software reais ao longo de um ano, totalizando cinquenta e duas versões para cada sistema.
2. Após extrair as versões foi necessário realizar a compilação de cada uma para que obtivéssemos os grafos de baixo nível representando cada versão.
3. Com os grafos disponíveis, aplicamos os algoritmos de agrupamento K-Means, DSM e Aglomerativos(SL75, SL90, CL75 e CL90) em todas as versões dos três sistemas alvo.
4. Cálculo da métrica de autoridade 5. Cálculo da métrica de estabilidade 6. Análise dos resultados
Para cada versão gerada por um algoritmo de agrupamento, uma versão correspondente dos desenvolvedores está disponível para a extração do valor de similaridade, estabelecendo a métrica de autoridade. Dessa forma, gera-se 52 valores entre 0 e 1, sendo que quanto maior o valor, maior a similaridade. Porém, somente a autoridade pode não ser suficiente para avaliar de forma completa um algoritmo de agrupamento. Portanto, cada versão gerada pelo algoritmo foi comparada com a próxima versão gerada do mesmo algoritmo. Assim, gera-se 51 valores de estabilidade entre 0 e 1.
3.4.1 Métricas de Avaliação da Qualidade
A partir das medidas de similaridade apresentadas na seção 2.5.1, 2.5.2 e 2.5.3, é possível definir métricas de avaliação dos agrupamentos gerados pelos algoritmos. Como mencionado no Capítulo 1, Wu, Hassan & Holt (2005) definiram três métricas de avaliação de decomposições arquiteturais. Neste trabalho, foram utilizadas apenas as métricas de autoridade e estabilidade, ambas calculadas através de MoJoSim, EdgeSim e MeCl.
Uma heurística para uma medida de autoridade sugere que os agrupamentos gerados por um algoritmo devem ser similares a uma decomposição feita por arquitetos do sistema. Assim, pode-se definir autoridade, segundo Bittencourt &
Guerrero (2009) como: Mo joSim(C,CA), onde C é uma partição gerada por um algoritmo de agrupamento e CA é uma partição gerada pelos arquitetos do sistema.
Uma outra heurística sugere que uma medida de estabilidade deve variar proporcionalmente às mudanças que são feitas no sistema alvo. Logo, pequenas mudanças de código resultam em pequenas mudanças no agrupamento e grandes mudanças de código resultam em grandes mudanças no agrupamento. Assim, a estabilidade pode ser definida, segundo Bittencourt & Guerrero (2009), como: MoJoSim(Ai, Ai+1), onde Airepresenta o agrupamento para a versão i e Ai+1representa o agrupamento para a versão seguinte, portanto, sempre duas versões consecutivas são analisadas.
Assim como a autoridade e a estabilidade foram definidas para o MojoSim, também podem ser definidas para o EdgeSim e MeCl, como mostrado na Tabela 3.
Autoridade Estabilidade MoJoSim MoJoSim(C,CA) MoJoSim(Ai, Ai+1) EdgeSim EdgeSim(C,CA) EdgeSim(Ai, Ai+1)
MeCl MeCl(C,CA) MeCl(Ai, Ai+1)
Tabela 3: Quadro resumo das métricas de qualidade aplicadas
3.5 Análise dos Resultados
Para a análise dos resultados, foram analisados os gráficos gerados pelas métricas de autoridade e estabilidade, além de termos aplicado métricas absolutas e relativas para comparação. Wu, Hassan & Holt (2005) definiram medidas para classificar duas séries de dados ou mais.
A métrica relativa Above compara uma série de dados de um algoritmo com relação aos outros para cada sistema analisado. A Figura 13 ilustra um gráfico com três séries de dados comparadas entre si.
Figura 13: Comparação de séries de dados através da métrica Above
A métrica Above é dada por: (WU; HASSAN; HOLT, 2005).
Above(DSi, DSj) =
|{n|DSi[n] > DSj[n], 1 ≤ n ≤ |DSi|}|
|DSi| (16)
onde DSi e DSj são duas séries de dados a serem comparadas. Para k séries, a medida relativa de DSi em relação às outras séries é:
Above(DSi) = k
∑
j=1Above(DSi, DSj) (17)
Uma métrica absoluta que compara as séries de dados com patamares bem definidos chamados de H, M e L é denominada de avaliação ordinal HML (WU; HASSAN; HOLT, 2005). A Figura 14 ilustra uma série de dados sendo comparada com esses limiares.
Figura 14: Aplicando o HML
Para o uso do HML, os parâmetros foram utilizados segundo a Equação 18 definida por Bittencourt & Guerrero (2009) como:
HML(DSi) = H, se Above(DSi, hm) ≥ 0.8 M, se Above(DSi, ml) ≥ 0.8 L, Caso contrário (18)
onde hm e ml são valores constantes que dividem o gráfico em três regiões. O valor de hm separa a região de valores elevados da região de valores médios, enquanto o mlsepara a faixa de valores médios da de valores baixos da métrica em análise.
4 RESULTADOS 4.1 Estabilidade
As Figuras de 15 a 17 ilustram os gráficos de estabilidade para os sujeitos utilizados no estudo por meio de MojoSim, EdgeSim e MeCl.
(a) Estabilidade do Lucene baseado em MojoSim
(b) Estabilidade do Lucene baseado em EdgeSim
(c) Estabilidade do Lucene baseado em MeCl
(a) Estabilidade do Ant baseado em MojoSim
(b) Estabilidade do Ant baseado em EdgeSim
(c) Estabilidade do Ant baseado em MeCl
(a) Estabilidade do Sweethome3d baseado em MojoSim
(b) Estabilidade do Sweethome3d baseado em EdgeSim
(c) Estabilidade do Sweethome3d baseado em MeCl
Figura 17: Estabilidade do sistema Sweethome3d
A Tabela 4 mostra os resultados obtidos na aplicação da métrica relativa para avaliação da estabilidade. Quanto maior o valor, maior a estabilidade do algoritmo.
(a) Estabilidade relativa baseada em MojoSim
(b) Estabilidade relativa baseada em EdgeSim
(c) Estabilidade relativa baseada em MeCl
Tabela 4: Estabilidade relativa
A Tabela 5 mostram os resultados obtidos na aplicação da métrica ordinal HML. Para a estabilidade, o hm foi definido em 0, 9 e o ml em 0, 7, mesmos valores utilizados em Wu, Hassan & Holt (2005) e Bittencourt & Guerrero (2009).
(a) Estabilidade HML baseada em MojoSim
(b) Estabilidade HML baseada em
EdgeSim
(c) Estabilidade HML baseada em MeCl
Tabela 5: Métrica HML para estabilidade
Antes de efetivamente analisar os algoritmos de agrupamento, procuramos primeiramente verificar a métricas de similaridade mais adequada para este estudo. Dito isto, observamos dois aspectos importantes, foram eles:
• Poder discriminatório • Variabilidade
O poder discriminatório indica a capacidade da métrica de reconhecer mais fielmente as mudanças ocorridas entre duas partições quaisquer, retornando valores altos para grandes mudanças e valores pequenos para pequenas mudanças.
A variabilidade indica a oscilação dos valores de similaridade calculados ao longo das versões. É desejável que a métrica acompanhe as mudanças arquiteturais sofridas pelo sistema. Assim, a métrica deve variar pouco para pequenas mudanças na arquitetura e/ou código, e variar muito para grandes mudanças na arquitetura e/ou código.
A partir dos gráficos de estabilidade mostrados pelas figuras 15 a 17 foi possível identificar as principais características das métricas de similaridade para os três sistemas.
O MojoSim apresentou um bom poder discriminatório nos agrupamentos, porém os cálculos de similaridade baseados nele sofreram grandes variações ao longo das comparações, deixando a desejar no critério de variabilidade. Neste aspecto, os resultados apresentados por Mitchell & Mancoridis (2001) coincidiram com este trabalho.
O MeCl mostrou pouca variabilidade e os cálculos de similaridade apresentaram valores mais altos do que o MojoSim e EdgeSim. Esses valores mais altos podem estar aparecendo devido a métrica não possuir a melhor forma de diferenciar dois agrupamentos, deixando a desejar no critério de poder discriminatório. O EdgeSim apresentou pouca variabilidade, ao mesmo tempo, um bom poder discriminatório devido suas oscilações serem em trechos específicos das versões onde ocorrem mudanças. Dado o exposto, utilizamos esta métrica de similaridade como a métrica mais fiel para avaliação de agrupamentos neste estudo. No estudo de Mitchell & Mancoridis (2001), o EdgeSim apresentou valores de similaridade bem próximos ao MeCl.
De modo geral, os agrupamentos gerados pela maioria dos algoritmos geram altos valores de estabilidade, em torno de 70%. Comparativamente, os algoritmos aglomerativos apresentaram melhores resultados de estabilidade, pois geraram agrupamentos com maiores valores de similaridade entre as versões, conseguiram mais escores ’H’ para o HML e geraram valores maiores de estabilidade relativa.
Em seguida o KMeans apresentou valores medianos de estabilidade, recebendo escores ’M’ em sua maioria para o HML e 2, 1 como valor máximo de
estabilidade relativa.
Por último, o agrupamento por DSM mostrou uma estabilidade inferior aos demais, pois gerou valores de similaridade menores, recebeu vários escores ’L’ para o HML e os valores de estabilidade relativa não passarem de 1, 06.
4.2 Autoridade
As Figuras de 18 a 20 ilustram os gráficos de autoridade para os sujeitos utilizados no estudo por meio de MojoSim, EdgeSim e MeCl.
(a) Autoridade do Lucene baseado em MojoSim
(b) Autoridade do Lucene baseado em EdgeSim (c) Autoridade do Lucene baseado em MeCl
(a) Autoridade do Ant baseado em MojoSim
(b) Autoridade do Ant baseado em EdgeSim
(c) Autoridade do Ant baseado em MeCl
(a) Autoridade do Sweethome3d baseado em MojoSim
(b) Autoridade do Sweethome3d baseado em EdgeSim
(c) Autoridade do Sweethome3d baseado em MeCl
Figura 20: Autoridade do sistema Sweethome3d
A Tabelas 6 mostra os resultados obtidos na aplicação da métrica relativa para avaliação da autoridade. Quanto maior o valor, maior a autoridade do algoritmo.
(a) Autoridade relativa baseada em MojoSim (b) Autoridade relativa baseada em EdgeSim
(c) Autoridade relativa baseada em MeCl
Tabela 6: Autoridade relativa
A Tabela 7 apresenta os resultados obtidos na aplicação da métrica ordinal HML. Para autoridade, o hm foi definido em 0, 8 e o ml em 0, 5, mesmos valores utilizados em Wu, Hassan & Holt (2005) e Bittencourt & Guerrero (2009).
(a) Autoridade HML baseada em MojoSim (b) Autoridade HML baseada em EdgeSim
(c) Autoridade HML baseada em MeCl
Tabela 7: Métrica HML para autoridade
De modo geral, os agrupamentos gerados pela maioria dos algoritmos geram valores relativamente baixos de autoridade, variando em torno de 40%.
Comparativamente, os algoritmos SL75 e SL90 apresentaram melhores resultados para o sistema Lucene, todavia, o CL75 e CL90 apresentaram melhores resultados para os sistemas Ant e Sweethome3d.
Para o sistema Lucene, as métricas de similaridade concordaram com relação aos resultados do SL75 e SL90, contudo, no Ant e Sweethome3d, o MeCl e EdgeSim discordaram do MoJo.
É interessante observar também que, para o Ant e Sweethome3d, MojoSim indicou o SL90 como melhor enquanto EdgeSim e o MeCl apontou como o pior.
4.3 Resumo
A Tabela 8 mostra um quadro resumo das variações de valores das métricas de similaridade tanto para a estabilidade quanto para a autoridade de acordo com cada algoritmo estudado.
(a) Variação do MojoSim (b) Variação do EdgeSim
(c) Variação do MeCl
5 CONCLUSÕES
Este trabalho avaliou seis algoritmos de agrupamento a partir da análise de versões semanais e consecutivas de três sistemas de software open source. Três métricas de similaridade foram avaliadas como candidatas para medir a qualidade dos agrupamentos gerados pelos algoritmos: MoJoSim, EdgeSim e MeCl. A partir dos resultados, percebeu-se que a métrica EdgeSim responde melhor em termos de poder discriminatório e pouca variabilidade durante a evolução. Utilizando as métricas de similaridade, em especial a EdgeSim, calculamos medidas de qualidade dos agrupamentos gerados, tanto em relação a agrupamentos de referência (autoridade) quanto em relação às mudanças nos agrupamentos para versões consecutivas (estabilidade).
Para a estabilidade, o estudo apontou que os algoritmos aglomerativos atingiram uma melhor perfomance do que o KMeans e DSM. Mais especificamente o SL90 e em seguida o SL75
Para a autoridade, os algoritmos aglomerativos também geraram valores bons em sua maioria, contudo o CL90 e CL75 mostraram melhor desempenho para o Ant e o Sweethome3d.
Em trabalhos futuros é interessante avaliar os algoritmos aglomerativos baseados em dependências estruturais e compará-los com os baseados em recuperação de informação utilizados neste estudo. Além disso, pretende-se aumentar a variedade dos sistemas alvo e algoritmos de agrupamento.
Alguns trabalhos usando algoritmos de agrupamento para recuperação arquitetural já foram produzidos pela comunidade acadêmica. Entretanto, faz-se necessária uma análise mais apurada destas técnicas através de trabalhos de avaliação experimental. A verificação da qualidade das técnicas de agrupamento permite saber seus pontos fortes e fracos, descrevendo melhor seu comportamento.
Esse trabalho contribui para a área de recuperação arquitetural, através da avaliação de técnicas de agrupamento de software, caracterizando melhor a qualidade das técnicas de agrupamento e métricas de similaridades existentes na literatura. Este trabalho é um passo nesta direção e, com os trabalhos futuros, pode-se avançar no conhecimento sobre o potencial de algoritmos de agrupamento para recuperação arquitetural.
REFERÊNCIAS
ANQUETIL, N.; LETHBRIDGE, T. C. Experiments with clustering as a software remodularization method. Reverse Engineering, 1999. Proceedings. Sixth Working Conference on, p. 235–255, 1999. Disponível em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=806964>.
BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice (2nd Edition). [S.l.]: Addison-Wesley Professional, 2003. ISBN 0321154959.
BITTENCOURT, R. A. Habilitando a Checagem Estática de Conformidade Arquitetural de Software em Evoluçao. Tese (Doutorado) — Centro de Engenharia Elétrica e Informática, Universidade Federal de Campina Grande, Campina Grande, 2012.
BITTENCOURT, R. A. et al. Design suite: Towards an open scientific investigation environment for software architecture recovery.SBQS 2009: Anais do VIII Simpósio Brasileiro de Qualidade de Software, 2009.
BITTENCOURT, R. A.; GUERRERO, D. D. S. Comparison of graph clustering algorithms for recovering software architecture module views.Software Maintenance and Reengineering, 2009. CSMR ’09. 13th European Conference on, p. 251–254, 2009.
BROWNING, T. R. Applying the design structure matrix to system decomposition and integration problems: a review and new directions. v. 48, n. 3, p. 292–306, 2001. GORTON, I. Essential Software Architecture. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2006. ISBN 3540287132.
HARTIGAN, J. A.; WONG, M. A. Algorithm as 136: A k-means clustering algorithm. Journal of the Royal Statistical Society. Series C (Applied Statistics), JSTOR, v. 28, n. 1, p. 100–108, 1979.
JEN, L. ren; LEE, Y. jye. Working group. ieee recommended practice for architectural description of software-intensive systems.IEEE Architecture, p. 1471–2000, 2000. LUCIA, A. D. et al. Using ir methods for labeling source code artifacts: Is it worthwhile? In: IEEE. Program Comprehension (ICPC), 2012 IEEE 20th International Conference on. 2012. p. 193–202. Disponível em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6240488>.
MANCORIDIS, S. et al. Using automatic clustering to produce high-level system organizations of source code. Program Comprehension, 1998. IWPC ’98. Proceedings., 6th International Workshop on, p. 45–52, 1998. Disponível em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=693283>.
MANNING, C. D.; RAGHAVAN, P.; SCHÜTZE, H. Introduction to information retrieval. [S.l.]: Cambridge University Press Cambridge, 2008.
MITCHELL, B. S.; MANCORIDIS, S. Comparing the decompositions produced by software clustering algorithms using similarity measurements.Software Maintenance, 2001. Proceedings. IEEE International Conference on, p. 744–753, 2001. Disponível em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=972795>. PEREIRA, T. A. B.; ELIAS, G. Uma estratégia de otimização para agrupamento de componentes de software baseada em dsm. Workshop on Software Engineering Optimization, 2010.
POLLET, D. et al. Towards a process-oriented software architecture reconstruction taxonomy. Software Maintenance and Reengineering, 2007. CSMR ’07. 11th European Conference on, p. 137–148, 2007. Disponível em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4145032>.
TZERPOS, V.; HOLT, R. C. Mojo: a distance metric for software clusterings. Reverse Engineering, 1999. Proceedings. Sixth Working Conference on, p. 187–193, 1999. Disponível em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=806959>. WIGGERTS, T. Using clustering algorithms in legacy systems remodularization. Reverse Engineering, 1997. Proceedings of the Fourth Working Conference on, p. 33–43, 1997. Disponível em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=624574>.
WU, J.; HASSAN, A. E.; HOLT, R. C. Comparison of clustering algorithms in the context of software evolution.Software Maintenance, 2005. ICSM’05. Proceedings of the 21st IEEE International Conference on, p. 525–535, 2005. Disponível em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1510147>.
