Mapeamento de interesses com o ConcernMapper

09maio10

fonte da imagem: desconhecida

Conheci recentemente a ferramenta ConcernMapper, um plug-in para o Eclipse que auxilia no mapeamento de interesses de uma aplicação Java. O termo “concern” neste contexto é realmente muito difícil de traduzir, como já haviam me falado antes, por isso, utilizei a palavra “interesse”. Conheci o ConcernMapper por intermédio de um colega, que está criando uma ferramenta para representações gráficas que auxilia na análise dos concerns mapeados pelo ConcernMapper. A ferramenta, que ainda está em fase de construção, será umas das contribuições de sua tese de doutorado. Em breve escreverei à respeito dela também. Por hora, focaremos apenas no ConcernMapper.

O objetivo deste post é relatar a minha experiência (e da minha equipe) no uso da ferramenta ConcernMapper, aplicada à um projeto do Governo Federal, descrevendo todos os passos do processo de mapeamento. Espera-se que este post contribua para tornar o processo repetível por outras pessoas, reduzindo o gap entre um mapeamento e outro. Não é objetivo deste post discutir o estado da arte nem ao menos explicar o uso da ferramenta.

Antes de começar a utilizar o ConcernMapper é preciso definir os concerns. Na linguagem informal, um concern é um tema de interesse de uma aplicação, que agrupa artefatos. Na prática, um concern pode ser um módulo, uma camada, um caso de uso ou até mesmo um requisito não funcional (e.g., segurança, auditoria). Para definir os concerns, é necessário saber exatamente o que se pretende analisar. No nosso caso, os concerns definidos envolveram: camadas conceituais (e.g., apresentação, negócio, persistência), mecanismo de segurança, fluxos alternativos (e.g., exceções) e controle transacional.

Agrupamos os concerns em dois grupos, que tomamos a liberdade de classificá-los como verticais e horizontais. Inventamos estes termos (vertical e horizontal) para discriminar os concerns que agrupam classes em módulos (verticais) dos concerns que cortam transversalmente tais módulos (horizontais). Priorizamos os verticais para só então tratar os horizontais. O importante é que o procedimento envolva todas as classes do projeto.

Para cada concern vertical fizemos o seguinte:

1. Abrimos a classe/interface;

2. Incluímos a classe/interface no concern;

3. Executamos Ctrl+G para localizar todas as referências.

4. Para cada item detectado (método de outras classes/interfaces) fizemos o seguinte:

4.1. Incluímos o item afetado pelo concern no próprio concern;

4.2. Caso o item afetado pertencesse a uma classe/interface que herdasse a classe/interface do concern, fizemos o seguinte:

4.2.1. Executamos recursivamente o processo para a classe/interface afetada a partir do passo 2. A condição de parada da recursividade foi a negação do passo 4.2;

5. Caso todos os métodos da classe/interface tivessem sido mapeados (item 4 e seus subitens), retornamos ao passo 1 para a próxima classe/interface até que todo o concern fosse contemplado.

Com os concerns verticais devidamente mapeados, fizemos o mesmo processo para os concerns horizontais. As classes/interfaces dos concerns horizontais foram mais difíceis de detectar, por estarem espalhadas em diversos pacotes da aplicação. Terminado o processo, armazenamos o arquivo gerado pelo ConcernMapper (formato XML) para posterior análise do resultado.

Percebemos que o ConcernMapper só é capaz de mapear classes e métodos. Outros tipos de artefatos (e.g., textos, planilhas, imagens) não são suportados pela ferramenta. Esta limitação impossibilita um mapeamento rico em detalhes, que sirva de insumo para uma análise de impacto aprofundada. A ferramenta também se mostrou ineficiente no mapeamento de classes/interfaces que não possuam métodos. Tais classes/interfaces simplesmente não apareceram no arquivo XML gerado pela ferramenta.

A impressão pessoal que tive em relação à todo o processo é a seguinte: é um trabalho chato e repetitivo. Acredito que seria possível automatizá-lo com algoritmos recursivos, porém, para isso, seria necessário que o mapeamento inicial mínimo fosse executado manualmente por um especialista. Contudo, o procedimento possibilitou a detecção de classes e métodos desnecessários, além de evidenciar melhorias na arquitetura e na estrutura interna da aplicação. No final das contas, até que valeu à pena! A dúvida que fica no ar é a seguinte: será viável manter mais um artefato no projeto? A resposta para esta pergunta somente o tempo poderá revelar…

E você?! Como vê o uso do mapeamento de interesses no seu dia-a-dia? Contribua! Deixe aqui a sua opinião.

Filed under: Post   |  5 Comments
Tags:Arquitetura, Eclipse, Ferramenta, Relato, Software Livre