Universidade Federal de Pernambuco Centro de Informática Disciplina: Tópicos Avançados em Engenharia de Software (

Universidade Federal de Pernambuco

Centro de Informática

Disciplina: Tópicos Avançados em Engenharia de Software (

Professor: Paulo Henrique Monteiro Borba (

Atividade 2

Oportunidades de modularidade

Equipe:

 Filipe Wanderley Lima (fwl@cin.ufpe.br);

 Maria Carolina Revoredo Martiniano (mcrm2@cin.ufpe.br).

1

Controle de Versões

Versão

Data

Descrição

Autor(es)

2

Sumário

1. Atividade... 3

2. Concerns escolhidos ... 4

3. SourceMiner ... 5

3.1. Mapas de árvore... 5

Mapa de árvore - LOC ... 6

Mapa de árvore - Complexidade... 6

3.2. Visão polimérica ... 7

3.3. Dependências ... 7

Dependência entre pacotes ... 8

Dependência entre classes ... 9

3.4. Força das dependências... 9

Matriz de acoplamento entre pacotes ... 10

Matriz de dependência entre classes ... 11

Grade de acoplamentos ... 12

4. AOP Metrics ... 13

4.1. Pacotes ... 13

4.2. Tipos ... 14

5. Metrics Tool ... 16

5.1. Separação de concerns ... 16

5.2. Complexidade ... 16

5.3. Grau de entrelaçamento ... 17

6. Situações suspeitas ... 18

6.1. Operações com mais de 20 LOC ... 18

6.2. Operações consideradas complexas ... 18

6.3. Muitas classes extendendo de HttpServlet ... 18

6.4. Classes muito grandes ... 18

3

1.

Atividade

Analisar o sistema escolhido utilizando o SourceMiner, AOP Metrics, e Metrics Tool. Registrar:

 Concerns escolhidos, com justificativa;

 Módulos suspeitos devido a tamanho, complexidade, profundidade, dependências (indesejadas, acoplamento, ciclos), entrelaçamento, e espalhamento;

4

2.

Concerns escolhidos

Após uma análise feita em cima dos arquivos do projeto, escolhemos os concerns listados abaixo devido ao seu alto grau de espalhamento, entrelaçamento e sucetibilidade a mudanças. São eles:

 Persistência - este concern está bastante concentrado no pacote dao e na maioria dos métodos da classe Fachada. São normalmente classes do pacote java.sql como o Connection, ResultSet e PreparedStatement;

5

3.

SourceMiner

O SourceMiner é um plugin para o Eclipse que usa metáforas visuais não convencionais para exibir informações úteis dos códigos fonte para os programadores. Com ele, programadores podem explorar informações sobre o código fontes seguindo um processo de três etapas: visão geral, zoom e filtros, e detalhes por demanda.

Ele usa nas suas perspectivas quatro princípios fundamentais na compreensão do software: a estrutura pacote-classe-método, a hierarquia de herança, as dependências e suas forças.

3.1.

Mapas de árvore

As representações em mapas de árvore são visões que dizem respeito à perspectiva da estrutura pacote-classe-método do software. Ela trata da hierarquia modular e como eles estão organizados em pacotes, classes e métodos. O importante nesta perspectiva é a representação de métricas tais como tamanho (LOC) e complexidade (McCabe). Estas duas métricas são convenientes para enriquecer a organização alto-nível da hierarquia pacote-classe-método que são melhores apropriadas para a visualização da arquitetura do software.

Um mapa de árvore é um método de visualização capaz de representar coleções de dados quantitativos com alto grau de hierarquia. É uma visualização 2D que mapeia estruturas de árvores em retângulos, com cada retângulo representando um nodo. Eles são muitos eficazes em mostrar atributos dos nodos usando tamanho (área) e cor, permitindo os usuários compararem nodos e sub-árvores em vários níveis de profundidade da árvore.

6

Mapa de árvore - LOC

Neste mapa destacam-se três classes com alto grau de LOC para os métodos:

GerarListaPublicacaoAux, PublicacaoAux e MembroAux, pertencentes ao mesmo pacote

(view). Os métodos são respectivamente: gerarPublicacaoBibTex, publicacaoAux e membroAux.

7

Neste mapa destacam-se 6 métodos com alto grau de complexidade:

PublicacaoDAO.definirPublicacao (5), LinhaPesquisaDAO.cadastrarLinhaPesquisa (4),

MembroAux.membroAux (3), PublicacaoAux.publicacaoAux (3),

PublicacaoDAO.cadastrarPublicacao (3) e MembroDAO.cadastrarMembro (3).

3.2.

Visão polimérica

A perspectiva da hierarquia de herança de software está relacionada a abstração de dados. A herança em programação orientada à objetos usa o conceito de generalizações e especializações para organizar a abstração, melhor distribuir funcionalidades e promover polimorfismo e reuso de código.

A visão polimérica é uma visualização 2D que usa retângulos para representar entidades, tais como classes e interfaces, e arestas para representar relações de herança entre elas. As dimensões dos retângulos são usadas para representar propriedades das entidades.

Nesta ferramenta, a largura corresponde ao número de métodos, enquanto que a altura corresponde ao LOC de uma classe ou interface. A cor indica o tipo do elemento, por exemplo, se ele é uma classe externa, classe abstrata, classe interna, classe comum, enumeração ou uma interface.

Através dessa visualização podemos ver claramente a relação de herança entre as classes Membro e Publicacao e suas respectivas especializações. As classes PublicacaoDAO e MembroDAO também chamam atenção por suas alturas, ou seja, alto grau de LOC. Percebe-se também o grande número de classes que herdam de javax.servlet.http.HttpServlet, os famosos servlets.

3.3.

Dependências

A perspectiva de dependência de software diz respeito ao problema dos acoplamentos dos módulos. A comunidade de engenharia de software lista o acoplamento como uma perspectiva essencial na complexidade do software. O fundamento básico do paradigma orientado à objeto é baseado em objetos que encapsulam dados para reduzir o acoplamento.

8

 Acoplamento aferente - quais nodos dependem do nodo em questão;

 Acoplamento eferente - quais nodos o nodo em questão depende.

Dependência entre pacotes

9

Dependência entre classes

Como foi dito anteriormente, classes do pacote basic como Membro e Publicacao e JDBCConnection do pacote util possuem alto grau de acoplamento aferentes. Já classes como a Fachada, um alto grau de acoplamento eferente.

3.4.

Força das dependências

10

Matriz de acoplamento entre pacotes

11

Matriz de dependência entre classes

Aqui notamos, como era de se esperar, as dependências entre as classes PublicacaoDAO e

Publicacao, MembroDAO e Membro, LinhaPesquisaDAO e LinhaPesquisa e a Fachada e

12

Grade de acoplamentos

13

4.

AOP Metrics

O objetivo do projeto AOP Metrics é fornecer uma ferramenta capaz de extrair métricas de projetos orientado à objetos e aspectos.

4.1.

Pacotes

Nome do pacote NOT A RMartin Ce RMartin Ca RMartin I RMartin

D Ce Ca I Dn

br.ufpe.cin.in980.linhapesquisa 8 0 9 0 1 0 12 0 1 0 br.ufpe.cin.in980.projeto 6 0 6 1 0,86 0,14 11 1 0,92 0,08 br.ufpe.cin.in980.logic 4 0 4 19 0,17 0,83 10 19 0,34 0,66 br.ufpe.cin.in980.basic 11 0 0 29 0 1 0 29 0 1 br.ufpe.cin.in980.dao 3 0 3 7 0,3 0,7 11 7 0,61 0,39 br.ufpe.cin.in980.pdf 1 0 2 0 1 0 7 0 1 0 br.ufpe.cin.in980.util 3 0 1 14 0,07 0,93 3 14 0,18 0,82 br.ufpe.cin.in980.publicacao 1 0 2 0 1 0 8 0 1 0 br.ufpe.cin.in980.view 20 0 17 2 0,89 0,11 23 2 0,92 0,08

Number of types (NOT) - é o número de tipos (classes, inner e anonymous classes e aspectos) pertencentes ao um dado pacote. É um dos indicadores de extensibilidade do pacote.

Os pacotes basice viewsão os que tem maior número de tipos. Enquanto que os pacotes pdfe publicacaopossuem as menores quantidades.

Abstractness (A) - é a razão entre o número de módulos abstratos e o número total de módulos

abstratos no pacote. Varia entre 0 e 1. O valor 0 indica um pacote completamente concreto e o valor de 1 completamente abstrato.

Não há nenhum módulo abstrato neste projeto, portanto o valor é sempre 0.

Afferente couplings (Ca) - é o número de módulos fora do pacote que depende dos módulos dentro do pacote. É um indicador da responsabilidade do pacote.

Ver a matriz de acoplamentos entre pacotes do SourceMiner.

Efferent couplings (Ce) - é o número de módulos dentro do pacote que dependem de módulos fora

do pacote. É um indicador da independência do pacote.

Ver a matriz de acoplamentos entre pacotes do SourceMiner.

Instability (I) - é a razão entre o Ce o acoplamento total (Ce + Ca), tal que I = Ce / (Ce + Ca). É um indicador da resiliência de um pacote mudar. Varia entre 0 e 1. O valor 0 indica um pacote completamente estável e o valor 1 indica um pacote completamente instável.

14

4.2.

Tipos

Lines of class code (LOCC) - conta o número de linhas de código perfeitas de uma classe.

Notamos que as classes MembroDAOe PublicacaoDAOpossuem o maior número de linhas de código.

Weighted operations in module (WOM) - conta o número de operações em um dado módulo.

Notamos que as classes do pacote basicpossuem o maior número de métodos, devido ao alto número de getters e setters.

Depth of inheritance tree (DIT) - é o tamanho do caminho mais longo de um dado módulo para a

raiz da hierarquia da classe/aspecto.

Notamos que o caminho mais longo de herança pertence as classes servlets, pois elas herdam de HttpServlete este por sua vez, herda de GenericServlet.

Number of children (NOC) - é o número de subclasses ou sub-aspectos imediatos de um dado

módulo.

15

Crosscutting degree of an aspect (CDA) - é o número de módulos afetados por pointcuts e pela

introdução em um dado aspecto.

Notamos que todos os aspectos do projeto afetam pelo menos 3 outros módulos.

Coupling on advice execution (CAE) - é o número de aspectos que contém advices possivelmente

desencadeado pela execução de operações em um dado módulo.

Notamos que as classes que mais sofrem interferência por aspectos são as classes: Fachada com a inserção de métodos de PDF, linha de pesquisa, publicação e projetos e PublicacaoDAOcom a inserção de métodos de PDF, deletar publicação e associar projeto.

Coupling on method call (CMC) - é o número de módulos ou interfaces que declaram métodos que

são possivelmente chamados por um dado módulo.

Coupling on field access (CFA) - é o número de módulos ou interfaces que declaram campos que

são acessados por um dado módulo.

Coupling between modules (CBM) - é o número de módulos ou interfaces que declaram métodos

ou campos que são possivelmente invocados ou acessados por um dado módulo.

Response for a module (RFM) - é o número de métodos ou advices pontecialmente executados em

resposta a uma mensagem recebida por um dado módulo.

Lack of cohesion in operations (LCO) - é o número de pares de operações que trabalham em

16

5.

Metrics Tool

5.1.

Separação de concerns

Concern

CDC DOSC SLOC ADOSC

Persistência 16 0.82 464

0.89

Lógica 31 0.95 319

Concern diffusion over components (CDC) - número de classes associadas a um concern.

Degree of scattering across classes (DOSC) - grau no qual um concern está distribuído entre as

classes. Varia de 0 a 1. Quando o DOSC é 0, todo o código está em uma classe. Quando o DOSC é 1, o código está distribuído igualmente entre todas as classes. Diferentemente do CDC, o DOSC não considera somente quais elementos estão envolvidos na implementação de um concern, mas também como o código está distribuído entre esses elementos.

Average degree of scattering (ADOS) - é a média do grau de espalhamento entre todos os

concerns. Ele indica a modularidade geral de um sistema.

Degree of tangling (DOT) - grau no qual um elemento de um sistema (componente, aspecto,

classe) está associado a um ou mais concerns do sistema. É muito similar ao DOS, exceto que o DOT é com respeito aos elementos do programa ao invés dos concerns.

Média de DOT - é a média do grau de entrelaçamento entre todos os elementos de um sistema.

5.2.

Complexidade

CBC LCO DIT NOC LOC WOM VS

130 509 46 7 2673 310 57

Coupling between components (CBC) - é o somatório da métrica CBM para todo o sistema. Para

mais detalhes, ver o tópico Aopmetrics.

Lack of cohesion over operations (LCO) - é o somatório da métrica LCO para todo o sistema. Para

mais detalhes, ver o tópico Aopmetrics.

Depth of inheritance tree (DIT) - é o somatório da métrica DIT para todo o sistema. Para mais

detalhes, ver o tópico Aopmetrics.

Number of children (NOC) - é o somatório da métrica NOC para todo o sistema. Para mais

detalhes, ver o tópico Aopmetrics.

Lines of code (LOC) - somatório da métrica LOCC para todo o sistema. Para mais detalhes, ver o

17

Weighted operations in module (WOM) - somatório da métrica WOM para todo o sistema. Para

mais detalhes, ver o tópico Aopmetrics.

Vocabulary size (VS) - é o somatório da quantidade de tipos de todo o sistema (classes e aspectos).

5.3.

Grau de entrelaçamento

Componente

DOT Média de DOT

BuscarMembroServlet 0.37

0.28

MembroAux 0.38

PublicacaoAux 0.39

LinhaPesquisaDAO 0.42

ProjetoPesquisaDAO 0.42

NaoMembroDAO 0.44

MembroDAO 0.47

AssociarProjetoAux 0.56

GerarListaPublicacaoPDFAux 0.56

ProjetoPesquisaAspect 0.60

EditarLinhaPesquisaServlet 0.61

CadastrarLinhaPesquisaServlet 0.61

PublicacaoDAO 0.62

ControleNaoMembro 0.67

EditarPublicacao2Servlet 0.70

JDBCConnection 0.71

ControleMembro 0.71

Fachada 0.72

CadastrarPublicacao2 0.74

LinhaPesquisaAspect 0.75

AspectPublicacao 0.83

ControleLinhaPesquisa 0.85

AspectPDF 0.88

ControlePublicacao 0.89

ControleProjetoPesquisa 0.92

18

6.

Situações suspeitas

Após análise dos resultados apresentados pelas ferramentas e discussão entre outras equipes e o professor, chegamos as seguintes situações consideradas como suspeitas e que devem ser levadas em consideração na hora refatorar o projeto.

6.1.

Operações com mais de 20 LOC

As seguintes operações, com mais de 20 LOC, foram consideradas como grandes demais:

 GerarListaPublicacaoAux.gerarPublicacaoBibTex;  GerarListaPublicacaoAux.geNomes;  GerarListaPublicacaoServlet.doGet;  CadastrarPublicacao2.doGet;  EditarPublicacao2Servlet.doGet;  PublicacaoDAO.cadastrarPublicacao;  MembroDAO.buscarMembro;  MembroDAO.cadastrarMembro;  LinhaPesquisaDAO.cadastraLinhaPesquisa;  EditarLinhaPesquisaServlet.doGet;  CadastraLinhaPesquisaServlet.doGet;  PublicacaoAux.publicacaoAux;  MembroAux.membroAux.

A idéia é que todos estes métodos sejam analisados e sejam quebrados em métodos menores.

6.2.

Operações consideradas complexas

Dentre as operações consideradas complexas segundo a métrica McCabe, os seguintes métodos considerados realmente complexos do ponto de vista de legilibidade:

 PublicacaoDAO.definirPublicacao;

 PublicacaoAux.publicacaoAux;

 MembroAux.membroAux.

A idéia é que estes métodos sejam melhor organizados, de maneira que o número de ifs seja diminuído e faça mais sentido.

6.3.

Muitas classes extendendo de HttpServlet

Notou-se que muitas classes estendem de HttpServlet e a maioria possuem duplicação do método doPost.

A idéia é que seja criado uma nova classe (ex: RGMSServlet) que estenda de HttpServlet e já faça o redirecionamento do método doPost para o doGet, evitando assim a replicação do código. Além disso, os servlets devem ser analisados para verificar a possibilidade de juntá-los caso suas funcionalidades estejam muito relacionadas.

6.4.

Classes muito grandes

As seguintes classes foram consideradas como muito grandes:

 MembroDAO ;

 PublicacaoDAO;

 LinhaPesquisaDAO;

19

 MembroAux;

 PublicacaoAux.

A idéia é que estas classes sejam analisadas e se verifique a possibilidade de talvez quebrá-las em uma ou mais classes.

Dependências entre pacotes

A organização de pacotes de maneira em camadas (dados, negócio, comunicação e GUI) talvez não seja a melhor maneira de organizar;

20

Referências

 Site da disciplina de Tópicos Avançados em Engenharia de Software;  Manual do usuário do SourceMiner;

 Site do AOP Metrics;