ModularidadeeReusodeSoftware-Atividade3-Equipe8

Modularidade e reuso de software

Oportunidades de modularidade

Iúri Ribeiro, Sérgio René { iara, srpvnf } at cin.ufpe.br

Índice

1. Concerns escolhidos...3

2. Análises do SourceMiner...5

2.1. Matriz de acoplamento de classes...6

2.2. Matriz de acoplamento entre pacotes...8

2.3. Dependência entre classes...9

2.4. Dependência entre pacotes...10

2.5. Visão polimétrica...11

2.6. Grid de acoplamento...12

2.7. Mapa de árvore...13

3. Análises do MetricsTool...15

3.1. Xml de entrada...16

3.2. Entrelaçamento das classes e concerns...17

3.3. Espalhamento de concerns...18

1. Concerns escolhidos

De acordo com as análises feitas pela equipe, foram listados os seguintes concerns com suas respectivas justificativas:

 Persistência

É a responsabilidade de fazer os dados do sistema persistirem, seja através de banco de dados, arquivos xml ou outros meios. É considerado como uma concern separada devido ao fato de que pode ser necessário uma mudança na persistência dos dados ou até que seja necessário dar suporte a outro tipo. Tecnicamente, são as partes de código que transformam objetos de projeto em objetos que irão persistir no meio escolhido (em banco de dados, por exemplo, seriam tabelas).

 Transação

Tecnicamente, são todas as partes que lidam com uma transação, seja para iniciar, fechar, abortar ou concluir (em banco de dados, seria a criação e fechamento de conexão como também rollback e commit). Um exemplo da importância de separar tal concern está em poder dar suporte para diferentes banco de dados (Oracle, MySQL, SQL Server, etc). Neste caso, poderiam ser modificados apenas parâmetros de conexão e outros detalhes específicos.

 GUI

Se refere a métodos que retornam códigos HTML para incrementar as interfaces gráficas utilizadas no sistema. É importante que seja separada das outras para facilitar a mudança de interfaces, caso seja necessário.

 Negócios

Referente a quaisquer partes que definam regras de negócios do sistema. É uma das partes mais cruciais do sistema (regras críticas do sistema, provavelmente estarão neste concern), por isso é importante sua separação.

 Servlets

Se refere a classes que lidam com a comunicação entre a GUI e a Fachada. É importante sua separação pois caso o sistema necessite de novas formas de comunicação, por exemplo, webservices com a mesma funcionalidade, essa seria a camada a ser alterada.

 Fachada

Se refere ao ponto único de entrada do sistema, as partes de código que chamam os controladores para desenvolver suas funcionalidades. Caso seja necessário adicionar uma nova funcionalidade ou alterar a assinatura de uma já existente, a fachada terá que ser alterada.

 Classes básicas

São as entidades do sistema. É importante pois, no futuro pode ser necessário adicionar novas propriedades para as entidades ou até novas entidades.

2. Análises do SourceMiner

As análises foram feitas com a ajuda do SourceMiner, um plugin para o Eclipse com funcionalidades para visualizações não convencionais do código. Com sua ajuda, foi possível verificar possíveis problemas de modularidade no código, através de correlações entre os resultados mostrados pela ferramenta. Cada resultado gerado será mostrado abaixo e posteriormente serão listados os possíveis problemas encontrados.

Como requisito para as próximas realizações, foi definido o conjunto de concerns na ferramenta (ver figura 01), vistos anteriormente com suas justificativas. Sua representação nos informa as cores que serão utilizadas para cada concern específico, o que será importante para entender algumas das próximas análises.

Figura 01. Conjunto de concerns e as cor 1

Figura 01. Conjunto de concerns e as cores utilizadas para representá-los.

2.1.

Matriz de acoplamento de classes

Esta representação nos diz o nível de acoplamento entre as classes, ou seja, diz quanto uma classe necessita de outras (ver figura 02). Nas linhas e colunas (mesma numeração da linha) estão todas as classes do sistema e suas cores representam o pacote que estão. Os números que aparecem nas posições [i, j] dizem quantas vezes a classe da linha está referenciando a classe da coluna. A partir desta visão, é possível identificar casos em que existam um acoplamento muito forte, basta verificar números altos. Tais acoplamentos podem ser candidatos à problemas de modularidade. Para saber se são, é necessário verificar se eles fazem parte de diferentes concerns.

Verificamos, então, que classes como LinhaPesquisaDAO e LinhaPesquisa, MembroDAO e

Membro como também PublicacaoDAO e Publicacao aparecem como um dos maiores índices de acoplamento. Porém, nestes casos, o acoplamento é necessário, pois não temos como Figura 02. Representação do nível de acoplamento entre as classes.

transferir ou capturar um objeto de projeto de um objeto de persistência sem receber ou criar, respectivamente, a classe básica referente àquele objeto. Contudo, podemos verificar que as classes Fachada e JDBCConnection estão com alto grau de acoplamento também. Como elas possuem responsabilidades distintas, então eles devem ser analisados mais detalhamente. Eles são candidatos de problemas de modularidade.

2.2.Matriz de acoplamento entre pacotes

Semelhante à representação da matriz de acoplamento entre classes, porém com pacotes ao invés de classes.

Podemos verificar que o pacote DAO tem um alto grau de acoplamento com o pacote Basic. Isto já era esperado, como explicado anteriormente.

2.3.

Dependência entre classes

Esta visão mostra a dependência entre as classes. Cada classe é representada por um círculo e suas dependências são representadas como setas para outras classes (ver figura 04). Iremos analisar esta representação com o modo de coloração de concerns, ou seja, as cores de cada classe representará o concern que a classe está e os números dirão a quantidade.

Poucas informações foram obtidas a partir desta representação. Isso porque classes que possuem mais de um concern, acabam aparecendo com apenas com a cor de um dos concerns. Para demonstrar isso, não conseguimos visualizar facilmente nenhuma classe de persistência (cor amarela), como também a fachada (cor azul). Isso dificulta a análise. De qualquer forma, as classes básicas (em verde) são bastante referenciadas, porém isso já era esperado.

Figura 04. Dependência entre as classes. Cada seta que liga duas classes representa que uma determinada classe é dependente da outra.

2.4.

Dependência entre pacotes

Semelhante à representação de dependência entre classes, contudo ao invés de classes lista os pacotes do sistema.

Figura 05. Dependência entre pacotes. Cada seta que liga dois pacotes representa que um determinado pacote é dependente de outro.

É possível visualizar que não existem ciclos na dependência de pacotes, caso existisse, demonstraria um alto grau de acoplamento entre os pacotes envolvidos no ciclo.

2.5.

Visão polimétrica

Esta visão mostra cada classe (representadas por retângulos) e suas heranças. As classes pais estão acima se ligando com as classes filhas (ver figura 06). Além disso, ela ainda nos dá mais duas informações no altura e largura dos retângulos. A altura significa a quantidade de linhas de código (LOC) da classe, enquanto a largura é a quantidade de métodos existentes na classe. As cores de cada classe mostram o concern em que ela possui, assim como o número representa a quantidade de concerns.

Podemos verificar que existem ao menos duas classes bastante grandes e, ainda mais, estão com 3 concerns atrelados à elas. Então devemos analisá-las mais detalhadamente para saber se é possível dividi-las, tanto pelo tamanho da classe (muitas linhas de código) como também pela quantidade de concerns atreladas à elas. Assim, são duas candidatas à problemas com modularidade. Existe também uma classe com 19 filhos o que também é um candidato a ser analisado melhor, pode ser necessário a criação de mais algum nível na hierarquia para agrupar melhor.

Figura 06. Visão polimétrica. Mostra a relação de herança entre classes como também o tamanho delas (altura) e sua quantidade de métodos (largura).

2.6.

Grid de acoplamento

Reforça o que vimos anteriormente que as classes básicas é referenciada inúmeras vezes. Figura 07.

2.7.

Mapa de árvore

Esta representação nos mostra todas as classes do sistema separadas por pacotes. Os retângulos contornados de linhas amarelas representam um pacote e os contornados por linhas vermelhas representam uma classe (ver figura 07). A coloração representa os concerns de cada classe e os números dizem quantas concerns estão atreladas à classe. O tamanho dos retângulos (pacote ou classe) variam com a quantidade de linhas de código (altura) e quantidade de métodos (largura).

A partir desta visão, podemos notar, novamente, que existem várias classes com mais de uma concern atrelada à classe. Além disso, podemos ter uma visualização mais ampla, pois podemos verificar que existem concerns espalhadas entre pacotes. Um exemplo disto está no concern de persistência (em amarelo) que aparece em pelo menos 4 pacotes diferentes, o da GUI (em marrom) que aparece em 3 pacotes diferentes e também o de negócios (em azul claro) que aparece em 5 pacotes diferentes. Seria necessário, então, analisar detalhadamente estes casos para verificar se isto é um problema de fato. Assim, eles são candidatos como problemas de modularidade.´

Figura 08. Mapa de árvore. Mostra os pacotes (conjunto de retângulos) e classes (retângulos menores) com a especificação das concerns atreladas à classe, mostrando a cor e quantidade.

Além da coloração por concerns, podemos também colorir a mesma representação pela complexidade dos métodos pertencentes a cada classe. Quanto mais escuro, mais complexo (ver figura 09). A complexidade é medida pela ferramenta através da quantidade de loops e condições.

Podemos verificar que existem algumas classes que são apontadas como complexas pela ferramente. É necessário verificá-las detalhadamente para saber se há problemas com a modularidade, verificar se poderiam ser subdivididas.

Figura 09. Mapa de árvore. Mostra os pacotes (conjunto de retângulos) e classes (retângulos menores) com a especificação da complexidade da classe através da coloração. Quanto mais escuro, mais complexo.

3. Análises do MetricsTool

Outras análises foram feitas utilizando uma outra ferramenta, o MetricsTool. Sua funcionalidade é parecida com o SourceMiner (visto anteriormente), com algumas diferenças. Uma das importantes diferenças entre eles é que a menor granularidade de um concern no SourceMiner é um método, porém no MetricsTool é possível considerar menos que um método, considerar linhas de código.

3.1.

Xml de entrada

É necessário criar um xml com a configuração dos concerns e suas aparições nas classes. Quando a classe é totalmente atrelada a um concern, basta adicionar um componente com o nome da classe, contudo também é possível informar quantas linhas de código (LOC) o concern representa naquela classe. É gerado um xml a partir do AOPMetrics com algumas métricas presentes, e além disso foi criado um xml especificando quais classes estão em cada concern e, se não corresponder a totalidade da classe, a quantidade de linhas referentes ao concern.

3.2.

Entrelaçamento das classes e concerns

Uma das representações do MetricsTool nos diz o quão uma classe está entrelaçada com os

concerns especificados como entrada. Explicita quais classes possuem concerns diferentes. O

resultado (ver figura 10) é dito em uma escala de 0 a 1, sendo o extremo 1 quando a classe possuir todos os concerns.

Uma rápida análise nestes resultados, nos mostra que boa parte das classes DAO possuem mais de um concern. Sendo assim, as classes DAO são fortes candidatos a serem analisados detalhadamente para possíveis problemas com modularidade.

Figura 10. Entrelaçamento das classes com os concerns. Está filtrado para apenas classes com resultado maior que zero.

3.3.

Espalhamento de concerns

Uma outra análise importante nos diz informações sobre o espalhamento das concerns pelo sistema. Algumas métricas são importantes serem destacadas, como:

 CDC (Concern Difusion over Components). Nos informa o número de classes associadas com um concern.

 DOSC (Degree Of Scattering Classes). Nos informa um percentual, portanto entre 0 e 1, de quão o código está distribuído através das classes. Valores muito baixos significam que a maioria do código pertence a poucas classes, enquanto valores altos mostram que o código está bem dividido entre as classes.

Com base nesta análise, podemos verificar que o código da Fachada está bastante centralizado, o que era esperado (é um ponto positivo, ao menos nesse caso, pois o código está centralizado). Em contrapartida, a maioria dos outros concerns estão espalhados em várias classes (ver figura 11).

4. Resultados

As análises feitas com a ajuda do SourceMiner e o MetricsTool levaram a considerarmos que alguns módulos, classes e/ou métodos devem ser analisados mais detalhadamente para verificar se podem ser modificados visando uma melhor modularidade.

Além das análises mostradas neste documento, também foram analisados métodos com mais de 20 linhas de código (considerado limite para método possivelmente grande) como também métodos que as ferramentas acusavam como complexos. Neste último caso, a ferramenta não conseguiu acusar casos realmente complexos. Os casos que foram ditos, foram analisados porém não foram considerados problemáticos, enquanto outras partes de código que deveriam ter sido acusadas pela ferramenta, e que realmente poderiam ser melhoradas, não foram.

Algumas classes, módulos e métodos foram considerados candidatos a uma análise mais detalhada para resolução de problemas com modularidade, reuso, entre outros. Alguns destes estão mostrados abaixo com suas justificativas:

 Método doGet da classe EditarLinhaPesquisaServlet.java

Este método poderia ser dividido. A criação de um método de leitura do objeto que recebesse o HttpServletRequest seria uma boa solução.

 Método doGet da classe CadastrarLinhaPesquisaServlet.java Similar ao anterior

 Método cadastrarLinhaPesquisa da classe LinhaPesquisaDAO

 Este método poderia ser dividido. A criação de um método de leitura do objeto que recebesse o PreparedStatement seria uma boa solução.

 Método cadastrarMembro da classe MembroDAO Similar ao anterior.

 Método buscarLinhasPesquisa da classe LinhaPesquisaDAO.java

 Este método poderia ser dividido. A criação de um método de leitura do objeto que recebesse o ResultSet seria uma boa solução.

 Método buscarMembro da classe MembroDAO.java Similar ao anterior.

 Método listarMembros da classe MembroDAO.java Similar ao anterior.

 Método adicionarPublicacoes da classe MembroDAO.java Similar ao anterior.

 Método buscarPublicacoes da classe PublicacaoDAO.java Similar ao anterior.

 Método membroAux da classe MembroAux.java

Este método possui muito ifs seguidos. Poderia ser feito, no mínimo, um switch ou if else. Apesar de não ter ganhos expressivos, deixaria o código mais limpo como também não se sabe o que o getFieldName faz internamente, o que poderia causar excesso de processamento inútil.

 Método publicacaoAux na classe PublicacaoAux.java Similar ao anterior.

 Método getNomes da classe GerarListaPublicacaoAux.java

Este método poderia ser modularizado e então reusado. Seria possível criar um método auxiliar que abstraisse a instância da classe em si e retornasse a conversão de uma lista de elementos para uma string.

 Método gerarPublicacaoBibTex da classe GerarListaPublicacaoAux.java

Este método poderia, claramente, ser divido em vários outros. Cada if do método poderia chamar um outro método que, então, faria todos os ‘appends’ necessários.

Além dessas mudanças, vimos que a classe da Fachada não deveria criar conexões e sim a camada de dados, além disso os concerns que estão mais espalhados são os de negócio e de transação, e a camada que tem mais concerns, ou seja que tem maior grau de entrelaçamento é a camada de dados com classes contendo até 3 concerns.

Outra preocupação analisada foi que a classe HttpServlet tem 19 filhos e que a maioria deles poderia ser filho de uma outra superclasse, pois eles tem o método “doGet” identicos, apenas repassando a chamada para o metodo “doPost”