Atividade II
Identificar oportunidades de aumento da modularidade
de código mais suscetível a mudanças ou variações
André Ricardo Rolim dos Reis
Thaís Melise Lopes Pina
1.
Concerns escolhidos
Lógica de negócios: parte do código que verifica regras de negócio. Localizado em grande parte no pacote logic.
Acesso aos dados (persistência): Concentrado nas classes do pacote dao. Possi código que acessa os dados.
Bibtex: Funcionalidade do sistema escolhida para ser analisada.
2.
SourceMiner
2.1. TreeMap
2.1.1. Complexidade
Figura 1. Árvore mapa - Complexidade
2.1.2. Linhas de Código
Figura 2. Árvore mapa - linhas de código
2.2. Polymetrics
Figura 3. Profundidade
É possível observar na figura acima que as classes 1 e 2 possuem muitas linhas de código, isso prejudica da modularidade do projeto, já que as mesmas são suscetíveis a erro e a independência no desenvolvimento seria dificultado.
Um exemplo de classe que possui muitos métodos é a Membro, visualizada em 3.
Também notamos que há várias classes que herdam de HttpServlet (classe externa ao projeto, visualizada em 4), o que mostra uma dependência muito grande desse código. Em caso de mudança, um grande esforço para a atualização. Uma solução seria tentar encontrar particularidades comuns entres as classes-filhas e criar nova classe intermediária.
2.3. Dependency
2.3.1. Package
Figura 4. Dependência dos pacotes
É possível ver que os pacotes basic, util e dao possuem módulos utilizados por vários outros partes do projeto (acoplamento aferente). De maneira contrária, há pacotes que não são utilizados por outros, mas utilizam módulos de diversos outros pacotes (acoplamento eferente), como linhapesquisa e logic. Existem também aqueles que não são acoplados a nenhum pacote, por exemplo, o pacote pdf.
2.3.2. Classes
As classes JDBCConnection, Membro, NaoMembro e Publicacao se destacam por serem bastante utilizadas, ou seja, possuem grande dependência com outras classes (acoplamento aferente).
As classes Fachada, PublicacaoDAO, GerarListaPublicacaoAux e ControleMembro se destacam por utilizarem muitas outras classes, também possuem grande dependência com outras classes (acoplamento eferente).
2.4. GridCoupling
Essa perspectiva de análise nos mostra as mesmas dependências entre as classes do projeto citadas no tópico 2.3.2. Mas com ela conseguimos detectar a classe
PublicacaoDAO como uma classe que possui bastante utiliza muito outras classes
(acoplamento eferente), que não tínhamos percebido com a perspectiva anterior por causa da visualização da imagem.
2.5. GridCoupling
Essa perspectiva possibilita a visualização não só da quantidade de dependências, mas também a quais classes tal classe é dependente.
2.5.1. Packages
2.5.2. Classes
3.
AOP Metrics
3.1.
Pacotes
A métrica NOT mostra a quantidade de tipos existentes nos diversos pacotes do sistema. Podemos ver que os pacotes basic e view são os que possuem mais tipos enquanto os pacotes pdf e publicacao possuem menos.
A métrica I indica a estabilidade de um pacote, ou seja, a probabilidade dele sofrer alterações. O pacote basic possui a menor quantidade porque depende de nenhum outro pacote. Já os pacotes linhapesquisa, pdf e publicacao são muito dependentes de outros pacotes e possuem uma alta taxa I.
A métrica A possui valores entre 0 e 1. O valor zero indica que o pacote é completamente concreto, como é o caso do projeto analisado. Já o valor um seria um pacote completamente abstrato.
As métricas Ca e Ce não serão analisadas, pois referem a acomplamento aferente e eferente que já foram contemplados com algumas das perspectivas do SouceMiner. Mas um bom exemplo é o pacote basic que possui Ce igual a 0 e Ca igual a 29.
3.2.
Tipos
A métrica LOCC conta o número de linhas de código de cada tipo. Na tabela acima notamos que MembroDAO e PublicacaoDAO possuem muitas linhas de código. Esse aspecto já tinha sido notado com a visualização TreeMap do SourceMiner.
A métrica NOC mostra a quantidade de filhos (subtipos) àquele tipo, portanto é uma medida relativa à dependência entre módulos (dependência de propriedades herdadas). Percebe-se que o projeto possui pouco uso de herança e apenas dois tipos são pais de outros tipos: Membro e Publicacao.
A métrica DIT indica a profundidade de um dado módulo. No caso do projeto analisado, a maioria das classes que possuem DIT diferente de zero herdam de HttpServlet e têm profundidade 2.
A métrica CDA indica os tipos que são mais afetados por um dado aspecto. Isso dá uma ideia geral do impacto que o aspecto tem nos módulos do sistema. São justamente os tipos de aspectos que possuem valor da métrica CDA diferente de zero.
As métricas CMC, CFA medem o acoplamento entre os módulos em relação a chamada de métodos, acesso a campos (atributos). A métrica CBM indica o acoplamento entre módulos e, na prática, é a soma entre as duas métricas anteriores.
A métrica RFM mede o potencia de comunicação entre um módulo de dados e outro.
A métrica LCO indica o grau com que os métodos de um dado tipo acessam os atributos do mesmo. Na tabela podemos notar que as classes básicas possuem um alto LCO, devido aos getters e setters.
4.
Metrics Tool
A métrica DOSC indica o grau com que um concern está distribuído entre as classes. Se o concern está em apenas uma classe, o valor de DOSC é zero, como no caso do concern bibtex. O concern basic possui alto valor DOSC porque está distribuído em diversas classes, o que é normal. Outra característica desse concern é que ele está presente em dois outros pacotes do sistema devido a funcionalidades possivelmente inseridas durante o decorrer do projeto (projetopesquisa e linhapesquisa).
A métrica CDC mostra o número de classes relacionadas a um concern. É possível notar que apenas uma classe está associada ao concern bibtex, o que explica o valor zero da métrica DOSC. Esta funcionalidade é facilmente retirada do sistema caso seja preciso visto que está concentrada em uma única classe.
A métrica ADOSC é a média do grau de espalhamento entre todos os concerns escolhidos. Indica então o grau de espalhamento do sistema.
As métricas CBC, LCO, DIT, NOC, LOCC e WOM indicam a soma das métricas CBM, LCO, DIT, NOC, LOCC e WOM, repesctivamente, geradas pela AOP Metrics.
