Atividade3

Atividade 3

Professor: Paulo Borba

Alunos: Átila Valgueiro Malta Moreira e Ícaro Valgueiro Malta Moreira

_____________________________________________________________________________________ Primeira Tentativa:

1° Parte Concerns Escolhidos

O projeto em questão, já enunciava uma arquitetura em camadas modularizando os componentes de acordo com o seu propósito, assim optamos por utilizar a mesma nomenclatura que o projeto em questão adota. Essa escolha também facilita pois é uma arquitetura que geral em camadas que já utilizamos a bastante tempo em outros projetos.

Assim a segue abaixo a lista de concerns que adotamos: 1. Apresentacao

2. Controle 3. Modelo 4. Persistencia

Pra gerar o Concern, utilizamos a ferramenta “Concern Mapper” que nos permite mapear cada método de acordo com a camada referente ao mesmo. Assim fizemos análise de cada método do projeto o colocando em um dos Concerns citados acima. Ao final, geramos o arquivo XML que define os concerns do mesmo.

Começamos então a fazer uma análise mais minuciosa dos métodos deste projeto, vamos começar este documento detalhando os pontos mais importantes desta análise assim como os pontos que nos chamaram mais atenção.

2º Analisar Módulos Suspeitos: 1. Tamanho:

Primeiramente utilizamos a ferramenta Source Miner para ter uma visualização geral do grau de complexidade das classes do projeto, através dessa primeira análise, iremos utilizar a ferramenta AOP Metrics para validar a o tamanho desses módulos. 1.1. AlterarDadosPublicacaoServlet: Este servlet tem um total de 104 linhas de código

significativas pelo AOP Metrics, logo sendo um possível candidato de ser um módulo complexo.

1.2. AdicionarPublicacaoServlet: Mesma situação do anterior.

1.3. AlterarDadosMembroServlet: Mesma situação do anterior.

1.4. AlterarDadosNoticiaServlet: Não foi possível gerar o xml desta classe. 1.5. AdicionarNoticiaServlet: Não foi possível gerar o xml desta classe.

2. Complexidade

A segunda métrica abordade é a complexidade de um módulo, para essa métrica iremos prosseguir nossa análise semelhante a como fizemos no anterior. Utilizando o Source Miner, mas nesse caso não temos realmente um forma de fazer um paralelo com o AOP Metrics, dados que a unidade do Source Miner é o Cyclomatic complexity, que é definido pela quantidade de caminhos independentes que o programa pode ter, como não encontrei nem no AOP Metrics, nem no Metric Tools parametros que pudessem fazer um paralelo, mas podemos analisar outras váriaveis que também definem a complexidade de um código.

2.1. AlterarDadosPublicacaoServlet 2.2. AdicionarPublicacaoServlet 2.3. AlterarDadosMembroServlet 2.4. AdicionarMembroServlet 2.5. AdicionarNoticiaServlet 2.6. AlterarDadosNoticiaServlet 2.7. AlterarDadosLinhaPesquisaServlet

Weighted Operations in Module(WOM): Número de operações que são efetuadas em um determinado módulo.

2.8. Membro(31) 2.9. ArtigoPeriodico(10) 2.10. Publicacao(18)

3. Profundidade

Essa métrica define o grau de hierarquia dos módulos, ou seja, que é definide com pela herança do mesmo. Quando o projeto apresenta uma profundiade isso quer dizer que esse mesmo utiliza de mais operações que são referentes as classses herdades que geralmente define um código mais modular, mas também implica numa maior complexidade para enteder o comportamente de um código, assim o tornando menos reutilizável.

Fizemos paralelo com a métrica DIT do AOP Metrics que é justamente a distancia de um objeto até a raiz, assim nos informando qual o nível de hirarquia do mesmo.

3.1. RGMSException 3.2. FotoServlet 3.3. RemoverMembroServlet 3.4. FiltrarMembrosServlet 3.5. AlterarMembroServlet 3.6. DetalharMembroServlet 3.7. AlterarDadosMembroServlet 3.8. DeslogarServlet 3.9. AdicionarMembroServlet 3.10. DaoPublicacao 3.11. Membro 3.12. Estudante 3.13. ControleMembro 3.14. ArtigoPeriodico 3.15. Nivel 3.16. PublicacaoPosGraduacao 3.17. ArtigoConferencia

3.18. Publicacao 3.19. PdfServlet 3.20. AlterarDadosPublicacaoServlet 3.21. RemoverPublicacaoServlet 3.22. FiltrarPublicacoesServlet 3.23. AlterarPublicacaoServlet 3.24. DetalharPublicacaoServlet 3.25. AdicionarPublicacaoServlet

Como podemos ver esse projeto não é muito profundo, possuindo no máximo 2 graus de profundidade e a maior parte deles são de herancas de classes da própria sdk java, assim nos mostrando que esse projeto não apresenta preocupação quando assunto de profundidade. 4. Dependências

4.1. Source Mine 4.1.1. Pacotes

O diagrama abaixo mostra que não existe arquitetura de camadas entre os pacotes, podemos notar que existem muitos ciclos no diagrama a cima, isto pode gerar complicações no momento que precisarmos mudar algo em algum dos pacotes.

4.1.2. Classes

As classes, entretanto mostraram um grau melhor de organização como pode ser visto na classe Controle.java(que está em amarelo no gráfico abaixo), esta tem todas as classes do tipo controle(identificadas pela cor alaranjada) e com sentido apontando para a classe controle.java.

Mesmo assim também fomos capazes de notar que a classe Facade.java(em amarelo no gráfico a baixo) não esta funcionando direito visto que tem outra classes invocando métodos dela. Algumas delas são inclusive as primitivas de Controle.java.

Para uma visão mais detalhada das dependências a ferramenta SourceMiner oferece um grid de dependência. Este contém mais informações, porém é mais complexo para se analisar. Exemplo:

4.2. Metric Tool

Number of Children(NOC): Informa o número de classes ou aspectos imediatos a um determinado módulo. Esse índice indica possiveis módulos que tem são potencias dependentes das propriedades de outros outros.

4.2.1. AbstractBusinessEntity 4.2.2. Membro

5. Entrelaçamento

Entrelaçamento é caracterizado por mistura de camadas em um mesmo modulo, por exemplo, temos entrelaçamento quando em um mesmo método temos regra de negócio, banco e interface juntos.

6. Espalhamento

Espalhamento embora não seja a mesma coisa que entrelaçamento eles coexistem no código. Espelhamento é caracterizado pela divisão de uma tarefa em pequenas tarefas e pela distribuição destes pequenos blocos no projeto.

3° Parte Avaliar Resultado Resolvíveis 1. Tamanho:

1.1. Notamos que todas as classes que possuem métodos grandes neste código possuem estruturas semelhantes, logo poderíamos criar uma única super classe que teria todas estas estruturas e então as outras classes estender esta. Assim teríamos duas únicas classes com tamanho grande. Elas seriam AlterarAbstract e AdicionarAbstract.

2. Complexidade:

2.1. Quando avaliamos complexidade neste código notamos que todos os métodos que declararam ser complexo tem a mesma funcionalidade e o mesmo nome, no caso, doPost. A solução mais simples para diminuir os blocos complexos neste código é implementar um doPost genérico assim diminuindo assim diminuindo a quantidade de código complexo.

3. Profundidade:

3.1. Podemos notar que estamos lidando com um código raso, ou seja, não temos muitas classes abstratas nem interfaces, isto como vimos nos subtópicos 1 e 2 desta terceira parte gerou problemas de complexidade e tamanho. Com a aprofundamento do código trataremos este problema.

4. Dependências:

4.1. Pudemos ver na quarta parte do segundo tópico que temos muitas dependências ciclicas isto é ruim para o projeto ja que demonstra uma baixa modularidade do código.

5. Entrelaçamento:

5.1. Infelizmente nossa configuração inicial se mostrou ruim para detectar entrelaçamento. 6. Espalhamento:

2º Tentativa:

1° Parte Concerns Escolhidos

O projeto em questão, já enunciava uma arquitetura em camadas modularizando os componentes de acordo com o seu propósito, assim optamos por utilizar a mesma nomenclatura que o projeto em questão adota. Além disso, levantamos módulos que poderiam ser alterados caso fosse necessária que o sistema fosse implantado focando outros usuários, teríamos módulos que seriam apenas os mesmos alterados, assim levantamos um concern pra representar a parte de idioma e outro para validação de campos.

Assim a segue abaixo a lista de concerns que adotamos: 1. Apresentacao 2. Controle 3. Modelo 4. Persistencia 5. Idioma 6. Validação

Pra gerar o Concern, utilizamos a ferramenta “Concern Mapper” que nos permite mapear cada método de acordo com a camada referente ao mesmo. Assim fizemos análise de cada método do projeto o colocando em um dos Concerns citados acima. Ao final, geramos o arquivo XML que define os concerns do mesmo. Alem disso, fizemos um mapeamento de concerns manual usando para utilizar na ferramente AOP metrics e na Metrics Tools, isso é devido não podemos fazer uma análise específica usando o Source Miner, pois o mesmo não nos permite analisar no contexto de linha de códigos. Assim, ao terminarmos de mapear esse mesmo temos obtivemos vários resultado, nos cabendo agora a analizar os dados gerado no intuito de achar formas de melhorar o código.

2º Analisar Módulos Suspeitos:

Mesmo com a criação de concerns não foi possível detectar nada mais pelo source miner, pois os novos concerns estão dentro de métodos, ocupando dos mesmos apenas algumas linhas de código. Assim, essa versão da análise irá conter apenas uma análise sobre os resultados gerados pelo AOP metrics e sobre o metric tools em função do xml de concern que estará em anexo no site da disciplina.

1. Tamanho:

Não Alterou, pois o mesmo não dependia dos concerns. 2. Complexidade:

Não Alterou, pois o mesmo não dependia dos concerns. 3. Profundida:

Não Alterou, pois o mesmo não dependia dos concerns. 4. Dependências:

Não Alterou, pois o mesmo não dependia dos concerns. 5. Entrelaçamento:

5.1. Metric Tools:

No intuito de avaliar o entrelaçamento do código, iremos analisar o BASE_DOT_Details.xls, vendo os os módulos que tenha mais de 1 em TotalLinkedConcerns, então as classes críticas são:

 AlterarDadosMembroServlet Component: AdicionarMembroServlet Concern Contribution Language 4 Apresentacao 99 Total LOC = 73 TotalLinkedConcerns =2

 AlterarDadosMembroServlet Component: RemoverPublicacaoServlet Concern Contribution Verificacao 1 Apresentacao 9 Total LOC = 9 TotalLinkedConcerns = 2  Controle Component: Controle Concern Contribution Verificacao 2 Persistencia 16 Controle 35 Total LOC = 53 TotalLinkedConcerns = 3  AlterarDadosMembrosServlet Component: AlterarDadosMembroServlet Concern Contribution Verificacao 2 Language 4 Apresentacao 99 Total LOC = 105 TotalLinkedConcerns =3  ControlePublicacao Component: ControlePublicacao Concern Contribution Verificacao 6 Persistencia 8 Controle 25 Total LOC = 35 TotalLinkedConcerns = 3

 AlterarDadosPublicacaoServlet Component: AlterarDadosPublicacaoServlet Concern Contribution Verificacao 1 Language 3 Apresentacao 100 Total LOC = 104 TotalLinkedConcerns =3  AlterarPublicacaoServlet Component: AdicionarPublicacaoServlet Concern Contribution Verificacao 1 Language 4 Apresentacao 93 Total LOC = 98 TotalLinkedConcerns =3 6. Espalhamento:

ConcernName CDC CDO DOSC DOSM SLOC

Modelo 0.806922 0 9 0 410 Verificacao 0.77551 0 7 0 14 Persistencia 0.747845 0 6 0 122 Controle 0.670531 0 3 0 82 Idioma 0.794341 0 5 0 16 Apresentacao 0.894055 0 15 0 581

Como podemos ver pelos DOSC, temos que o grau de espalhamento por classe foi relativamente alto. Tendo os Concerns de Apresentação, Modelo, Verificação e Persistência. E temos que a média de espalhamento é ADOSC = 0.7815338969230652. Acredito que concerns que tenham mais de 6 classes relacionadas podem ser potenciais concerns que podiam ser alterados, e iremos detalhar isso melhor na análise de resultados.

3º Analisar Módulos Suspeitos: 1. Tamanho:

Mesmo resultado da primeira avaliação. 2. Complexidade:

Mesmo resultado da primeira avaliação. 3. Profundida:

Mesmo resultado da primeira avaliação. 4. Dependências:

Mesmo resultado da primeira avaliação. 5. Entrelaçamento:

Vemos nos servlets da camada de apresentação, na maior parte deles temos entrelaçado aos mesmos, os concerns de validação e idioma. No intuito de melhorar isso, poderiamos:

 Idioma: Poderiamos fazer um xml para cada idioma, assim poderiamos facilmente mudar o idioma, e como os métodos de busca de texto seriam encapsulados pela fachada, o projeto ficaria mais organizado.

 Verificação: É verificação deveria ocorrer toda no método de validação e o mesmo mandaria a mensagem de erro através de uma exceção, assim não ocorrendo essa validação no meio do código que acaba, misturando os própositos de cada trecho de código.

6. Espalhamento:

No caso caso de espalhamento, verificamos se esse se tratava de comandos ou de sistemas como discutido em sala de aula. Detalhando casos críticos:

 Apresentação: Felizmente, se tratava de um sistema completo e assim não é prejudicial.

 Modelo: Felizmente, se tratava de um sistema completo e assim não é prejudicial.

 Verificação: O concern de verificação se encontra com linhas espalhadas pelo código e isso demonstra que esse concern é fraco e que pode ser prejudicial.

Para corrigimos seria através da mesma proposta que utilizamos para o entrelaçamento que foi dicutido no tópico anterior.