Universidade Federal de Pernambuco – UFPE Centro de Informática - CIn
Tópicos Avançados em
Engenharia de Software
Identificar oportunidades de aumento da
modularidade de código mais suscetível a mudanças
ou variações
Dupla
Caio César Sabino Silva (ccss2@cin.ufpe.br) Lais Sousa de Andrade (lsa@cin.ufpe.br)
Professor
Paulo Borba (phmb@cin.ufpe.br)
Identificar oportunidades de aumento da
modularidade de código mais suscetível a mudanças
ou variações
Este documento tem como objetivo analisar a segunda versão do Research Group Management System. A análise do sistema concerne à identificação de oportunidades de aumento da modularidade de código e foi realizada com a utilização de ferramentas como o SourceMiner, o AOP metrics e metrics tool.
Analisando as preocupações relevantes do sistema
Com base na arquitetura do sistema e hierarquia dos pacotes, pode-se perceber que foi adotado o modelo MVC, nos quais existem três camadas básicas: modelo, apresentação e controle. O modelo define como os dados do sistema são representados, enquanto a apresentação lida com a forma como os dados serão mostrados ao usuário. O controlador é a camada que permite a ligação entre apresentação e modelo, garantindo consistência entre eles, permitindo que comandos na apresentação sejam transformados em alterações no modelo, entre outros aspectos. Sobre essas camadas básicas, cinco preocupações puderam ser observadas no projeto:
● Dados ou modelo: consiste em modelar as informações necessárias do sistema em entidades a serem manipuladas pelo programa.
● Acesso aos dados ou persistência: consiste na preocupação em realizar a persistência dos dados ou se comunicar com algum sistema que realize tal função (como um banco de dados).
● Negócio: consistem em verificar se as regras estabelecidas pelo sistema são checadas. ● Comunicação: as entidades que transformam chamadas de funcionalidades vindas das
camadas superiores a chamadas ou transações nas camadas mais inferiores.
● Apresentação: as entidades que definem como os dados serão apresentados ao usuário, representados pelos jsps.
A partir destas, outras preocupações mais específicas são listadas:
● Dados
● Acesso aos dados
○ Controle de transação do banco de dados
○ Realização de operações de persistência (adicionar, remover, atualizar e consultar)
● Negócio
○ Representação de erros em uma funcionalidade do sistema ○ Tratamento de erros do sistema
● Comunicação
○ Captura dos dados de uma requisição ao servidor
○ Delegando operações de negócio em função da requisição ○ Redirecionamento à página correta
● Apresentação
Análise de módulos suspeitos encontrados
Após a classificação de cada concern, inserindo as classes, avaliando a preocupação em cada método de cada classe java, podem-se perceber alguns cenários interessantes:
● Há um entrelaçamento entre os concerns Validação, Processamento de funcionalidades e Controle de transação do banco de dados nas classes Controle e seus subtipos. Pode ser observado no código de amostra abaixo:
public void inserir(Tipo tipo) throws RGMSException { validar(tipo);
Persistence.getInstance().beginTransaction();
this.dao.adicionar(tipo);
Persistence.getInstance().commit(); }
Há duas linhas que lidam com a comunicação com o banco de dados, no controle de sua transação em conjunto com duas linhas que podem ser vistas como regras de negócios, uma para validar o objeto recebido como parâmetro e outra para delegar a inserção à camada de persistência (pode ser visto como o processamento de uma funcionalidade - a de inserção).
Dessa forma, a camada de persistência possuía um espalhamento pela camada de Negócio, uma vez que em alguns pontos tais preocupações se entrelaçavam. Isso traz um ponto bastante negativo, pois há uma dependência entre essas camadas, de forma que se a implementação for distribuída em grupos distintos, um grupo tem que entender como o outro está fazendo e isso não é desejável.
bastante simples (só derivam de Servlet) e possuem bastante coisas em comum, sendo alguns métodos iguais.
Percebe-se que as barras são inúmeras e pouco largas (possuem pouquíssimos métodos) e algumas são bastante altas (principalmente considerando que são finas), indicando que há muitas linhas de código neles. Ou seja, as classes desse grupo possuem muito código numa quantidade pequena de métodos, indicando que os métodos realizam operações provavelmente complexas que possivelmente podem ser divididas em operações mais simples, cada uma tratando uma preocupação distinta. Assim avaliou-se que tais classes estão tratando múltiplas preocupações em um mesmo módulo, tornando o código extenso e mais difícil de compreender (por envolver múltiplos conceitos).
● Tendo como base o tópico anterior em relação aos Servelts, pode-se perceber que uma das preocupações consiste em capturar os dados vindos da requisição, outra em transformar esses dados em chamadas a funcionalidades de outros módulos e ainda mais uma em redirecionamento à pagina adequada. Por exemplo, métodos como processFormField, que por sinal é replicado em classes, poderia ser tratados pelo módulo de captura e interagiria com o módulo de processamento e redirecionamento. Sendo assim, a complexidade desses módulos reduziriam (o AlterarDadosMembroServlet por exemplo fica com região preta no gráfico).
● Pelas dependências que haviam entre as classes, notavelmente (e esperadamente, como foi mencionado na aula) a Fachada (Facade) possuía múltiplas ligações com outros módulos. Embora muitas delas sejam necessárias, como chamadas de método de outras classes, algumas delas são exageradas e geram um efeito de dependência que não é desejado. Por exemplo:
private Facade() {
this.controleMembro = new ControleMembro(); this.controlePublicacao = new ControlePublicacao(); }
é baixo e garante uma independência maior entre as camadas e ainda permite a existência de múltiplas implementações e abstração de que implementação é de fato usada, gerando uma transparência maior. Analogamente isso pode ser aplicado entre os Controles e os Daos.
● Analisando a CouplingMatrix gerada pelo SourceMiner, observa-se que há um padrão que se repete nas dependências das demais classes sobre as classes Dao, Persistence e Controle. A classe Persistence é sempre referenciada juntamente a uma destas duas classes, mas nunca de maneira independente, como se ela fosse uma extensão de ambas. A classe Persistence permite a manipulação das transações com o banco de dados, mas a maneira como estas classes estão se relacionando entre si e com as demais não permite que esta manipulação fique independente ou mesmo transparente no sistema. Uma possível solução seria encapsular estas transações com uma outra abordagem, que não a extração de uma classe.
● Analisando as métricas geradas pelo AOPmetrics, observa-se que os pacotes de apresentação juntos formam a camada com maior NOT (number of types), que está em conformidade com o elevado número de servlets encontrados. Entretanto, o fato de haver muitas classes nesse pacote não implica necessariamente em ser bem modularizado, pois como foi visto, os servlets possuem problema de entrelaçamento de concerns que tornam cada classe deles com código complexo e extenso.
Além disso, como esperado, os pacotes de modelo possuem alto valor de Ca indicando que muitas classes de outros pacotes o utilizam. Isso é esperado pois diversos módulos acima dependem de tais entidades básicas. Essa métrica é importante, pois leva em consideração quantos outros módulos podem ser afetados pelas alterações que ocorrerem nele. Outro valor elevado é no pacote “br.ufpe.cin.rgms”, pois ele contém a Facade que é utilizada em diversas outras camadas. Como definido pela AOPmetrics, esse é um valor que indica o grau de responsabilidade de um pacote.
Pela métrica Ce, pode-se notar que a camada de apresentação, que na prática contém os Servlets, possuem alto grau de dependência em relação a outras camadas. O pacote “util” também possui valor elevado.
Tabela com algumas métricas de pacote da AOPmetrics
● Analisando as métricas do AOPmetrics para as classes, temos:
Tabela com algumas métricas de tipos da AOPmetrics
A métrica DIT é similar ao gráfico de profundidade do SourceMiner e não foi encontrado nenhum valor elevado. A métrica LOCC pode ser comparável ao comprimento das barras no SourceMiner. As demais métricas não indicaram informação útil. Algumas como LCO indicavam que as classes de dados ou a fachada possuíam baixa coesão entre operações (alto valor de falta de coesão), entretanto era ocasionado por métodos do tipo get e set, que operam em atributos diferentes, elevando o valor dessa métrica.
distribuição do código entre estes elementos. Na maioria dos concerns analisados, o valor do DOSC esteve acima de 0.5, muitas vezes próximos a 1, indicando que o código está quase igualmente distribuído entre as classes relacionadas a este concern. Isso pode ser uma coisa boa, indicando uma boa modularidade no sistema. Porém, quando uma classe está envolvida em mais do que uma preocupação isso pode refletir um problema, uma vez que indicaria que a classe envolve uma quantidade significativa de código de várias preocupações, prejudicando a independência da mesma. Isso ocorre de maneira grave nas classes dos pacotes de apresentação (os servlets). Eles contém códigos para captura dos dados de uma requisição ao servidor, muitas vezes eles mesmos realizam a validação destes dados, e ainda executam tratamento de erros do sistema.
Imagem do arquivo DOS.csv gerado pela ferramenta MetricTool
Analisando outra variável, CDC, foi visto que a preocupação com o controle de redirecionamento de páginas é a que possui mais classes envolvidas. Isso, juntamente com o alto valor do DOSC que o concern possui, indica que o código está bem espalhado entre as classes, mas como é um concern que envolve uma área bastante instável do projeto, que são os links das páginas para onde o site será redirecionado, é necessário um cuidado a mais com a manutenção destas informações, pois uma mudança neste módulo envolve muitas entidades. Mapear os links das paginas em um xml externo ao código pode deixar esta preocupação mais fácil de ser modificada.
Estratégias para o uso do SourceMiner
● Na escolha dos concerns, pode-se começar com aspectos principais que se considera importante no sistema. Após feito isso, avalia-se pelas métricas casos de mau cheiro e em função disso refine-se os concerns escolhidos impondo filtros cada vez menos restritos até que se atinja um estado onde nenhum caso interessante ou suficientemente relevante seja encontrado.
● Uso de mais de um tipo de visualização para analisar um problema encontrado para poder mensurar a importância dele em relação a todo o sistema, em seus mais variados níveis (no mesmo pacote, entre pacotes dependentes, entre classes, etc).
● Na view Dependency, pode-se selecionar um nó do grafo e visualizar somente as dependências dele. Dessa forma, fica mais fácil de visualizar e permite que seja analisado um módulo que tenha sido caracterizado como mau-cheiro por outro filtro. ● A visualização de cores no TreeMap pode ser configurada para mostrar tanto que
pacote, classe e método tem maior tamanho ou maior complexidade, medida pelas configurações do próprio SourceMiner. Assim ele pode ser utilizado para verificar se um dado método além de grande possui também muito trecho de código complexo.
● Ao deixar o mouse sobre um retângulo na TreeMap, ele exibe um tooltip mostrando a quantidade de linhas do mesmo, permitindo ver o tamanho efetivo do bloco e não somente o relativo.
Quantidade de situações suspeitas que podem ser resolvidas
Considerando cada situação como um problema (sem contar pela quantidade de vezes em que ele aparece no código), temos que as seguintes situações podem ser resolvidas com a utilização de técnicas simples:
● Espalhamento do concern de controle de transação do banco de dados;
● Entrelaçamento do concern de validação com o de controle de transação com o banco de dados
● Entrelaçamento dos concerns captura de dados, delegação de funcionalidades na camada de negócio e redirecionamento à página correta estão entrelaçadas nos Servlets;
● Espalhamento do concern validação de dados, que ocorre tanto nas classes controle como em alguns Servlets.
Com técnicas mais avançadas de modularidade, como utilização de aspectos (como foi discutido com o professor na última atividade), os seguintes problemas foram detectados e poderão ser resolvidos:
● Entrelaçamento entre os concerns de controle de transação do banco de dados e realização de operação de persistência nos subtipos de Dao.
