• Nenhum resultado encontrado

TÓPICOS AVANÇADOS EM E N G EN H A RIA DE SOFTWARE

N/A
N/A
Protected

Academic year: 2019

Share "TÓPICOS AVANÇADOS EM E N G EN H A RIA DE SOFTWARE"

Copied!
10
0
0

Texto

(1)

TÓPICOS AVANÇADOS EM

ENGENHARIA DE SOFTWARE

Relatório da Atividade 3

-

Oportunidades de Modularidad

e

Alunos: Lucas Praciano Marinho {lpm@cin.ufpe.br}

Ivson Diniz {ids@cin.ufpe.br}

Professor: Paulo Borba {phmb@cin.ufpe.br}

Centro de Informática - Universidade Federal de Pernambuco

(2)

Introdução

$ Este relatório descreve a experiência e resultados encontrados na execução da Atividade

3 da disciplina Tópicos Avançados em Engenharia de Software lecionada no Centro de Informática da Universidade Federal de Pernambuco no período 2010.2.

$ Para realizar esta atividade fizemos o uso de três ferramentas para analisar o código do

projeto 1 do sistema Research group management system, a SourceMiner, a AOPMetrics e a

metricsTool. O objetivo foi tentar identificar oportunidades de aumento de modularidade no código, e propor mudanças adequadas que oferecessem os benefícios de desenvolvimento independente, manutenção independente e compreensão independente característicos de um código modular. A estratégia básica aplicada consistiu dos seguintes passos:

• Inicialmente foi feita a escolha de concerns adequados que permitissem uma perspectiva interessante sobre o código.

• Após isso os concerns escolhidos foram então mapeados para cada elemento do código através do Concern Mapper, agregado ao SourceMiner, e os gráficos oferecidos pela ferramenta foram analisados com o objetivo de se ter uma perspectiva global sobre possíveis problemas de modularidade no código.

• Com a informação fornecida pelo SourceMiner um mapeamento de concern mais preciso foi

feito para o AOPMetrics e o metricsTool com o objetivo de ter informações e métricas mais detalhadas sobre cada possível problema de modularidade.

• O código de cada possível problema foi analisado em mais detalhes e uma lista de problemas de modularidade foi elaborada para possível modificação.

As seções a seguir irão descrever cada um desses passos em mais detalhes bem como as considerações feitas durante cada um.

Concerns

$ A identificação dos concerns é uma fase importante da estratégia adotada. Concerns mal

escolhidos podem resultar em identificação de problemas não existentes de um ponto de vista prático no projeto, resultando em aumento de vocabulário desnecessário bem como gerar dificuldades na manutenção e entendimento do código. Concerns bem escolhidos devem, após a análise de código, resultar no aumento da modularidade de forma significativa para o fluxo de desenvolvimento.

$ Para a escolha dos concerns procuramos seguir as indicações dadas durante a aula da

discplina, sempre procurando isolar concerns que possuem boa probabilidade de mudança bem

como representem um domínio de conhecimento com mínimas dependências de outros

(3)

$ Avaliar a probabilidade de mudança de um concern específico foi particularmente

problemático considerando o fato de não temos conhecimento do contexto de mercado onde o sistema será implementado nem do planejamento para versões futuras. Dessa forma a avaliação da probabilidade de mudança da camada de persistência, por exemplo, é um pouco especulativa, já que não se conhece os planos de modificação de banco de dados no futuro. No caso de haver grande estabilidade nessa camada, considerar casos de uso como concerns poderia

ser uma opção mais interessante. Nossa estratégia foi então a de usar como base para a probabilidade de mudança a nossa experiência e conhecimento sobre outros projetos desta natureza.

$ Inicialmente para a identificação dos concerns procuramos reler a descrição do projeto

procurando restrições já especificadas nos requisitos, em particular notamos requisitos quanto à presença de interface gráfica, persistência e geração de relatórios através de um formato BibTex e requisitos de negócio.

• Apresentação é uma característica do software que tem grande probabilidade de

modificação, além de ser um domínio de conhecimento distinto em relação ao resto de um software por envolver comunicação com o usuário, fluxos de interação, posicionamento de elementos visuais bem como estilização. Dessa forma ter um concern de Apresentação é

adequado por isolar o conhecimento pertinente a esta área bem como facilitar modificações.

• Persistência também representa um domínio de conhecimento bastante distinto, seja no acesso a um banco de dados ou a um sistema de arquivos é necessário ter conhecimento da plataforma usada para tais operações bem como possíveis linguagens de queries, além disso este domínio tem probabilidade razoável de ser modificado como um todo.

• Negócio é o conhecimento relacionado ao comportamento dos objetos que representam o domínio da realidade que o software pretende simular, seria o “núcleo” do sistema. Esse conhecimento tem grande probabilidade de modificação, pois qualquer atualização substantiva de um software costuma oferecer novas funcionalidades relacionadas ao domínio onde é usado bem como representa uma área de conhecimento bastante distinta dos outros

concerns aqui descritos.

• BibTex foi um domínio de conhecimento especificado pelos requisitos que consideramos razoavelmente distinto em relação aos outros já que poderia ser modificado eventualmente por mudanças em especificações ou em APIs externas eventualmente usados para a sua implementação.

$ Após esta análise inicial procuramos observar de forma geral a arquitetura adotada no

projeto escolhido. A partir dessa observação achamos necessário adicionar dois novos concerns

(4)

• Exceção mostrou-se um domínio bastante distinto no funcionamento do software, por fugir

do comportamento normal a exceção precisa ser considerada especialmente, muitas vezes fora do domínio onde ela é gerada, surgem questões como lo%ing, fluxo de interação alternativo, telas de erro e informar administradores de sistema. Esse comportamento excepcional pode ser mudado como um todo com freqüência, principalmente no período de manutenção do ciclo de vida de um software. Dessa forma mostra-se adequado considerar um

concern distinto o tratamento destas exceções.

• Comunicação foi um concern identificado a partir da observação da implementação da

interface gráfica. Por ser um sistema cliente-servidor o código que serve o conteúdo para o

cliente e o que descreve a interface gráfica deve ser diferenciado já que estão executando em domínios bem distintos. Além disso modificações no código de comunicação com o cliente são freqüentes quando começam a envolver questões de otimização na fase de manutenção. Separar este código do código de Apresentação torna-se então uma tarefa importante do

ponto de vista de modularização.

$ Talvez tão importante quanto a decisão de que concerns foram escolhidos seja destacar

porque certos concerns não foram escolhidos, especificamente por que foi feita a escolha por concerns “horizontais”(supondo arquitetura em camada) ao invés de concerns “verticais”, como

casos de uso.

$ Casos de uso representam candidatos interessantes para concerns do ponto de vista de

modificações de código que envolvam adição de novos casos, remoção dos mesmos ou alteração em todo o seu fluxo, no entanto modularizar este concern pode ser problemático do ponto de vista da manutenção dos subsistemas bem como modificações em casos existentes que exijam o trabalho de diversos membros da equipe, já que todos estariam modificando o mesmo módulo. Fica em então sob ao critério da equipe de desenvolvimento priorizar que tipo de modificação dessas será mais provável. No caso do nosso sistema assumimos que o conjunto de casos de uso sofrerá poucas adições ou remoções, reduzindo então a vantagem de usar estes casos como concerns.

Análise no SourceMiner

$ A ferramenta Concern Mapper, associada ao SourceMiner não apresenta muita precisão

no mapeamento de concerns, não se pode, por exemplo, mapear uma linha de código para um

concern, a unidade mínima é o método. No entanto consideramos que seria positivo do ponto

de vista da visualização nos gráficos ter um mapeamento básico feito a partir dos concerns

escolhidos anteriormente. Para realizar este mapeamento optamos por marcar métodos que continham mais de um concern com todos os concerns que estavam dentro dele, dessa forma um

(5)

$ Após este mapeamento configuramos os filtros nas opções padrão e escolhemos as cores

relacionadas a cada concern, mostradas na seguinte imagem:

O primeiro gráfico analisado foi então o grafo de dependência, primeiramente para pacotes:

$ Neste grafo notamos inicialmente que alguns pacotes estão bem restritos a um concern

enquanto outros tocam uma grande variedade deles. Em particular temos em azul claro com 6

concerns o pacote “view”, em rosa com 4 concerns o pacote “linhapesquisa” e em azul escuro com 5 concerns o pacote “projeto”. Enquanto o critério de escolha dos pacotes não precise estar

restrita necessariamente a um concern é interessante que um pacote não toque domínios muito diferentes, ter pacotes para cada concern é interessante do ponto de vista de modificações

(6)

$ Em relação às dependências vemos que os pacotes “util” e “basic” concentram muito, no

entanto isso é algo inevitável considerando que eles oferecem as classes básicas usadas praticamente em todas as camadas do sistema.

$ Indo para o diagrama de classes colorido por concern temos a seguinte visualização:

$ Neste grafo temos as classes Membro e Publicação e NaoMembro em rosa

concentrando grande parte das dependências, algo inevitável considerando que fazem parte do vocabulário básico do código. Em amarelo no lado esquerdo, concentrando boa parte das dependências, temos a classe JDBCConnection, usado pelo código de persistência para acesso ao banco, neste caso há um problema claro, esta classe é característica de persistência, mas temos diversas classes de outras cores com dependências em relação a ela, há um provável problema de modularidade.

(7)

Neste gráfico notamos inicialmente em amarelo(persistência) classes muito grandes mas com

pouca largura, isso indica poucos métodos muito grandes, particularmente temos PublicacaoDAO e MembroDAO na esquerda chamando bastante atenção, bem como LinhaPesquisaDAO. Isso pode indicar oportunidades de modularização através de subclasses ou classes auxiliares, como todas essas classes são de persistência é possível que existam operações comuns entre elas que possam ser separadas. Outra classe que chama a atenção é Fachada, rosa, com 2 concerns e bastante longa, talvez seja possível passar este concern para

outra classe e reduzir o seu tamanho.

(8)

No TreeMap podemos observar o quão bem os pacotes e classes se relacionam com os concerns

definidos bem como observamos também o número total de concerns em cada classe para

procurar oportunidades de modularização interessantes.

Em específico pudemos notar que a classe Fachada apresenta um grande número de métodos com mais de um concern bem como as classes de Comunicação que apresentam em diversos lugares métodos com tratamento de exceção.

AOPMetrics e metricsTool

Usamos estas ferramentas para realizar uma análise mais precisa dos problemas de modularidade no projeto. O mapeamento de concerns deve ser refeito para o uso nessas

ferramentas pois elas exigem que o mapeamento seja descrito em um XML especificando quantas linhas de código relacionadas a cada concern estão presentes em cada classe, informação não considerada no Source Miner. O mapeamento foi feito inicialmente para as classes mais interessantes percebidas no uso do Source Miner, mas eventualmente fizemos o mapeamento de todas as classes para melhorar a significância das métricas.

(9)

Os principais dados extraídos através desta análise com o uso do AOPMetrics e do metricsTool foram os seguintes:

C K :

R E L E A S E S C B C L C O

D I T

N O C L O C W O M V S

B A S E

130 509 46 7 2673 310 57

D O S :

(Colunas DOSM e CDO retiradas por serem zeradas.)

C

O N C E R N

N

A M E

C D C

D O S C

S L O C

P

E R S I S T Ê N C I A

B

I B

T

E X

A

P R E S E N T A Ç Ã O

N

E G Ó C I O

C

O M U N I C A Ç Ã O

E

X C E Ç Ã O

8 0.7643722295761 754

1 0.0 156

3 0.62809920311 33 20 0.948941886425 739

21 0.914936542511 612 11 0.925324678421 44 ADOSC = 0.6969457566738129

<project name="researchProject_OO1">

<concern_model>

<concern name="Persistencia">

<component name="BuscarMembroServlet" loc="8"/>

<component name="Fachada" loc="35"/>

</concern>

(10)

B

A S E

D O T:

(Classes com DOT = 0.0 foram omitidas)

C

O M P O N E N T

D O T

E

D I T A R

L

I N H A

P

E S Q U I S A

S

E R V L E T

R

E M O V E R

L

I N H A

P

E S Q U I S A

S

E R V L E T

P

R O J E T O

P

E S Q U I S A

S

E R V L E T

F

A C H A D A

C

A D A S T R A R

M

E M B R O

S

E R V L E T

B

U S C A R

M

E M B R O

S

E R V L E T

B

U S C A R

P

U B L I C A C A O

S

E R V L E T

G

E R A R

L

I S T A

P

U B L I C A C A O

S

E R V L E T

C

A D A S T R A R

P

U B L I C A C A O

2

D

E L E T A R

M

E M B R O

S

E R V L E T

E

D I T A R

P

U B L I C A C A O

2 S

E R V L E T

E

D I T A R

M

E M B R O

S

E R V L E T

0.231409788131714 0.4318338632583620 0.3988919258117680 0.5559895634651180 0.469333291053772 0.71005916595459 0.414814829826355 0.414814829826355 0.237037062644958 0.4318338632583620 0.2429388165473940 0.449999988079071 Average DOT = 0.08752556119048804

A

N Á L I S E

$ A partir desses dados foi possível confirmar algumas suspeitas já apontadas durante a

análise anterior, em particular na tabela Base DOT temos um alto grau de emaranhamento em diversas classes Servlet(de Comunicação) e na Fachada, em particular se destaca

BuscarMembroServlet. No entanto como um todo o projeto apresenta um DOT médio baixo

(0.08).

$ Na tabela DOS percebemos um alto grau de divisão do código dos concerns nas diversas

classes que os usam, no entanto essa informação pode ser tanto positiva quanto negativa do ponto de vista de modularidade, uma vez que pode indicar um alto grau de scattering ou apenas uma boa divisão do concern entre suas classes especializadas.

$ Na tabela CK observamos um Lack of Cohesion(LCO) alto para o projeto, indicando

Referências

Documentos relacionados

- desenvolver a pesquisa de acompanhamento das atividades de ensino desenvolvidas nos cursos na modalidade à distância; - participar de grupo de trabalho para o desenvolvimento

Neste estudo foram estipulados os seguintes objec- tivos: (a) identifi car as dimensões do desenvolvimento vocacional (convicção vocacional, cooperação vocacio- nal,

Banco do Brasil S.A. Banco do Brasil S.A. Banco do Brasil S.A.. Banco do Brasil S.A.. TEME) PRODUTOS AGRÍC.. EM CULTURAS PERM. PERM.) COLHEITA PRODUTOS AGRÍC.. de Alvenaria 5

Nessa situação temos claramente a relação de tecnovívio apresentado por Dubatti (2012) operando, visto que nessa experiência ambos os atores tra- çam um diálogo que não se dá

Este dado diz respeito ao número total de contentores do sistema de resíduos urbanos indiferenciados, não sendo considerados os contentores de recolha

A espectrofotometria é uma técnica quantitativa e qualitativa, a qual se A espectrofotometria é uma técnica quantitativa e qualitativa, a qual se baseia no fato de que uma

O teste de patogenicidade cruzada possibilitou observar que os isolados oriundos de Presidente Figueiredo, Itacoatiara, Manaquiri e Iranduba apresentaram alta variabilidade

A STACK dispõe também de 6 bate-estacas do tipo queda-livre sobre rolo para cravação de estacas pré-moldadas para cargas de até 120T, perfis, tubos metálicos e estacas