Análise dos modelos obtidos de MaRiSA-AOCode

Nesta seção relatamos a experiência envolvida na transformação entre o modelo de projeto detalhado (aSideML) e o modelo abstrato de programação (Metaspin), e a transformação deste último para modelos específicos de plataforma (AspectLua e CaesarJ), realizando uma análise qualitativa que considera os seguintes parâmetros:

• Completude: dado um processo de transformação entre modelosm, esse critério visa considerar se existem elementos em um modelo de entrada que não foram mapeados para um elementos correspondentes no modelos de saída.

• Rastreabilidade: nesse critério avaliamos se o modelo de saída do processo de transformação representa todos os elementos especificados no modelo entrada, e se é possível identificar quais elementos do modelo de entrada originaram um elemento específico no modelo saída.

• Corretude: esse critério avalia se os elementos do(s) modelo(s) de saída foram corretamente gerados através do processo de mapeamento, não apresentando erros sintáticos de acordo com os templates definidos para cada linguagem .

4.7.1 Avaliação do modelo abstrato de programação gerado a partir do projeto detalhado

a) Completude: os modelos usados como entrada do processo de transformação de

MaRiSA-AOCode vêm da abordagem de MaRiSA-DP [Montenegro, 2008]. Embora aSideML permita a modelagem estrutural, comportamental e composicional de aspectos, através do modelo de projeto detalhado gerado por MaRiSA-DP, consideramos somente a modelagem estrutural. Nesse contexto, as regras de mapeamento utilizam os principais elementos estruturais de aSideML: Aspect, Base Element, Crosscutting Interface, Template Match, Join Point, Template Parameter, Redefinition, Refinement, Additions, Uses, Operation e Tags. No entanto, existem elementos de aSideML que não tem correspondente direto no Metaspin. Por exemplo, o elemento Crosscutting Relationship não tem correspondência, porém seus elementos possuem correspondentes diretos espalhados pelo modelo Metaspin. Dessa forma, a completude entre os modelos ocorre através do mapeamento direto ou indireto

entre os modelos. Outro exemplo relacionado é o valor do elemento

PointcutLanguageEvaluator no contido no Predicate do JoinPointSelector do aspecto no Metaspin. A linguagem aSideML define essa informação somente em modelos comportamentais, os quais não são tratados em nossa abordagem. Para os modelos comportamentais adota-se como valor padrão para essa informação a primitiva execution. No entanto, por tratarmos somente da modelagem estrutural de aSideML em nossa abordagem, decidimos por utilizar como valor padrão para esta informação a primitiva call visto ser o tipo de chamada de interceptação de join points mais comum entre as linguagens de programação OA. Podemos considerar que houve completude no mapeamento visto que os elementos

estruturais de aSideML foram mapeados direta ou indiretamente para um elemento no Metaspin.

b) Rastreabilidade: nesse critério avaliamos se o modelo Metaspin representa todos os

elementos especificados no modelo aSideML, e se é possível identificar quais elementos de aSideML originaram um elemento específico no modelo Metaspin. Em virtude de os elementos estruturais serem mapeados para um elemento correspondente no Metaspin, podemos afirmar que as informações contidas em um modelo aSideML são todas salvas. Como forma de permitir a visualização do relacionamento origem/fonte de cada elemento gerado no modelo Metaspin são utilizados comentários em grande parte dos elementos, como é o caso de operações pertencentes a classes e interfaces, bem como propriedades do aspecto que são provenientes de relacionamentos transversais e interfaces transversais de aSideML. Adicionalmente, nossa abordagem permite a propagação de informações desde a modelagem de requisitos em AOV-Graph para descrição arquitetural em AspectualACME (definido em MaRiSA), e descrição arquitetural em AspectualACME para o projeto detalhado em aSideML (definido em MaRiSA-DP). Por exemplo, as propriedades de AspectualACME, as quais mantêm informações adicionais de requisitos que não são representados por elementos de primeira classe, são mapeados para Tags aSideML, que por sua vez, são armazenadas em forma de comentário no modelo Metaspin.

4.7.2 Avaliação dos modelos específicos de plataforma gerados a partir do modelo abstrato de programação

a) Completude: avaliamos nesse critérios se existem elementos do Metaspin que não

foram mapeados para AspectLua e/ou CaesarJ. O Metaspin é um metamodelo que visa atender a diversas linguagens de programação orientadas a aspectos. Dessa forma, os elementos atendem a diversos paradigmas de programação. Para o nosso mapeamento, foram escolhidos elementos que atendessem a necessidade do mapeamento para a linguagem AspectLua, que embora sejam uma linguagem de scripting possui mecanismos que permitem simular a orientação a objetos, e a linguagem CaesarJ, que tem como linguagem o Java, uma linguagem orientada objetos.

Tabela 8 - quantificação dos elementos do metaspin

Metamodelo nº elementos existentes nº elementos utilizados

Pointcut 14 9

Join Point 14 6

Advice 11 6

Advice Binding 8 6

TOTAL 45 25

Na tabela 8 quantificamos os elementos existentes no Metaspin organizando-os de acordo com cada sub-metamodelo. No metamodelo de Pointcut foram utilizados 9 elementos dentre os 14 existentes, são eles: Pointcut Language Evaluator, Base Language, Predicate, Primitive Selector, Join Point Selector e Custom Predicate. No metamodelo de Join Point utilizamos apenas 6 elementos dos 14 disponíveis, visto que tratamos somente join points estáticos em nossa abordagem, são eles: Join Point, Structural Join Point Part, Object Oriented Join Point Part, Class Join Point Part, Method Join Point Part e Statement Join Point Part. O restante dos elementos desse metamodelo corresponde a elementos utilizados para representação de join points dinâmicos, os quais não são tratados nesse trabalho. No metamodelo de Advice foram utilizados 6 elementos dentre os 11 existentes, são eles: Advice, Advice Action, Meta-level Action, EvalJoinPointInstructio, Primitive Base Action, Advice Evaluator. Os elementos utilizados representam a contento a abstração de advice para AspectLua e CaesarJ. Por fim, o metamodelo Advice Binding foram utilizados 4 elementos dos 6 existentes, são eles: Aspect , Variable, Selector Advice Binding e Intertype Declaration. Dos 45 elementos existentes de todo o Metaspin, para o tratamento de informações estruturais de aSideML e geração de código nas linguagens CaesarJ e AspectLua foram utilizados 25 elementos.

O Metaspin possui um grande número de elementos de forma a ser genérico o suficiente para abranger os conceitos relacionados à orientação a aspectos de diversas linguagens de POA. No entanto, para o escopo de nosso trabalho onde serão utilizadas duas linguagens de programação OA não foi necessário a utilização de todos os elementos presentes no metamodelo.

Além disso, foram utilizados somente elementos estruturais, visto que neste trabalho tratamos somente a modelagem estrutural de aspectos descrita em aSideML. Nesse sentido, não foram utilizados elementos que representam características comportamentais de aspectos, nem tampouco elementos que tratam join points dinâmicos. Dessa forma, podemos dizer que

não houve completude no mapeamento dos elementos dos modelos, embora os elementos utilizados do Metaspin tenham sido suficientes para representar tanto as abstrações de orientação a aspectos em um nível abstrato de programação, quanto em um nível específico de plataforma (AspectLua e CaesarJ). Neste caso, conclui-se que a utilização de um número reduzido de elementos do Metaspin deve-se a abrangência que este metamodelo tem, bem como pelo fato de estar sendo utilizado em nosso trabalho em um contexto específico. Ou seja, embora o Metaspin disponibilize uma grande diversidade de elementos no seu metamodelo, foram utilizados somente alguns elementos, os quais foram suficientes para a representação de aspectos e a geração de código para AspectLua e CaesarJ.

b) Rastreabilidade: os elementos dos modelos AspectLua e CaesarJ gerados pelas regras

de transformação são em sua grande maioria anotados com comentários de forma a permitir sabem qual elemento do projeto detalhado deu origem a determinado elemento tanto no modelo Metaspin, quanto no modelo AspectLua e/ou CaesarJ onde essas informações são propagadas. Um exemplo disso são operações de classes e interfaces, operações advindas de redefinições e refinamentos que são anotadas em nível de modelos e em nível de código. Além disso, é realizada a propagação de informações desde a fase de requisitos que chegam até o nível de Tags em aSideML. Essas Tags são também armazenadas em forma de comentário nas operações a que elas pertencem. Dessa forma existe a rastreabilidade de informações desde a fase de projeto detalhado aSideML, sendo estas propagadas no nível abstrato de programação do Metaspin, bem como no nível específico de programação de AspectLua e CaesarJ.

c) Corretude: avaliamos se os elementos dos modelos de saída (AspectLua e CaesarJ)

foram corretamente gerados através do processo de mapeamento descrito em MaRiSA- AOCode. Embora os aspectos e código base sejam gerados automaticamente, é necessário a intervenção do programador para a definição da lógica de negócio a ser implementada, visto que o código gerado é proveniente de modelos estruturais de projeto detalhado e não comportamentais. Além disso, MaRiSA-AOCode garante a corretude sintática do código gerado, em virtude de a geração de código ser feita através de templates pré-definidos baseado na sintaxe textual tanto de AspectLua, quanto de CaesarJ para os respectivos códigos. Como exemplo, dentre as 31 classes e interfaces geradas a partir do modelo base do Health Watcher, nenhuma delas apresentou problemas de sintaxe.