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.

Anúncios


5 Responses to “Mapeamento de interesses com o ConcernMapper”

  1. 1 Ari Jr

    Muito interessante essa ferramenta (o post foi meiero, to brincando), estava pensando em utilizar essa ferramenta, para criar um mapeamento de casos de uso (nosso interesse) com os códigos relacionados. Fiquei com uma dúvida, não sei se você passou por isso, você utilizou com mais de uma estação de trabalho? passou pelo processo de merge de vários mapeamentos, ou criou arquivos distintos?

  2. 2 Ari Jr

    Seguindo um link no próprio site do ConcernMapper achei o FEAT (http://www.cs.mcgill.ca/~swevo/feat/). Ele trabalha de forma similar, porém você pode ter uma hierarquia de interesses (concerns e subconcerns). Além disso a forma de associação do interesse com os pedaços de código (fragments) é mais limpa. Cada pedaço de código é considerado um Participante (participants) do interesse. A ferramenta monta automaticamente as relações (relations) entre os participantes de um determinado interesse, ou seja, se um participante chama um método de outro, se um participante cria uma instância de outro e etc. E por fim permite navegar facilmente entre parcicipantes, relações e o link com o código.

    Cadê o pessoal que não comenta nada? ninguém se interessou pelas ferramentas?

  3. 4 Péricles Alves

    Olá Cleverson,

    O que você acha de uma extensão do ConcernMappper que permitisse além de adicionar métodos e classes aos concerns, permitisse também indicar quais partes do código da classe ou do método implementam o concern?

    Por exemplo, em um método onde um concern esteja sendo implementado por um laço do tipo while ou uma chamada a outro método, seria possível adicionar ao concern apenas esses fragmentos.

    Aguardo uma resposta com a sua opínião.

    Obrigado!

    • À princípio me parece que vai tornar o processo de mapeamento mais penoso ainda, mas é possível que isso dê mais controle para os casos que a solução atual não atende. Desde que seja opcional o nível de detalhamento do mapeamento, por que não? 😉

      Seria bom a opinião de especialistas no assunto. A minha opinião é de um utilizador que fui.


E aí, o que você achou? Comenta aí...

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s