AspectJML: Uma Linguagem de Marcação para

AspectJML: Uma Linguagem de Marcação para AspectJ
Leopoldo S. de Melo Junior, Nabor C. Mendonça
Mestrado em Informática Aplicada – Universidade de Fortaleza (UNIFOR)
Av. Washington Soares, 1321 – CEP 60.811-905 Fortaleza – CE
[email protected], [email protected]
Abstract. The classical plain-text representation of source code is convenient
for programmers but requires parsing to uncover the deep structure of the
program, a notoriously difficult task to implement in software engineering
tools. This article presents an XML-based source code representation for
AspectJ, called AspectJML (AspectJ Markup Language). This representation
is more natural for code processing tools and allows easy implementation of
numerous analyses and transformations over AspectJ programs (such as
metrics calculation and refactoring) by leveraging the abundance of XML
technologies currently available.
Resumo. A representação clássica de código fonte em texto plano é
conveniente para programadores, mas requer a análise sintática do código
para revelar detalhadamente a estrutura do programa, uma tarefa
notoriamente difícil de implementar em ferramentas de engenharia de
software. Este artigo apresenta uma representação de código fonte baseada
em XML para AspectJ, chamada AspectJML (AspectJ Markup Language).
Esta representação é mais natural para ferramentas de manipulação de
código e permite a fácil implementação de inúmeras análises e
transformações sobre programas AspectJ (tais como cálculo de métricas e
refatorações) tirando proveito da abundância de tecnologias XML atualmente
disponíveis.
1. Introdução
Desde as primeiras linguagens de programação, programadores têm usado texto plano
para codificar programas. Esta forma de representação de código fonte é bastante
concisa e similar às linguagens naturais. Contudo, o texto plano não é a melhor forma
de manipular código fonte em um nível de abstração desejável para ferramentas de
engenharia de software. Tarefas como análise estrutural e semântica, que requerem a
análise sintática do código, são particularmente difíceis de realizar a partir de uma
representação em texto plano.
O principal problema da representação em texto plano é que ela não captura de
forma explícita a estrutura sintática do código. Neste contexto, vários autores
propuseram linguagens de marcação, baseadas em XML [16], para representar código
fonte de forma estruturada (por exemplo, [10][4][1]). Essas representações, além de
tornarem explícita (e, portanto, mais fácil de consultar, analisar e manipular) a estrutura
sintática do programa, trazem ainda uma série de benefícios para os desenvolvedores de
ferramentas de engenharia de software, incluindo [12]: (i) possibilidade de anotar o
código com informações estruturadas (por exemplo, para representar comentários e
diretivas de compilação); (ii) facilidade para formatar o código de acordo com
diferentes estilos de programação ou visualização (por exemplo, tecnologias de
transformação XML, como XSLT [15], poderiam ser empregadas para aumentar a
legibilidade do código através da utilização adequada de leiautes, cores e fontes);
(iii) possibilidade de associar fragmentos de código diretamente, facilitando a
navegação e permitindo a recolocação de fragmentos de código sem a perda das
referências; e (iv) suporte para a rápida implementação de ferramentas de manipulação
de código em uma variedade de plataformas e linguagens de programação (por
exemplo, utilizando a abundância de padrões e tecnologias disponíveis para
manipulação de dados XML, como XPath [13] e XQuery [14]).
Motivados pelos benefícios acima, e pela crescente popularidade da linguagem
Java entre programadores, alguns autores propuseram representações em XML
específicas para Java [4][10]. Destas, a representação proposta por Badros, denominada
JavaML [4], tem sido a mais amplamente utilizada. JavaML representa informações
semânticas e estruturais de um programa Java tipicamente presentes em árvores
sintáticas abstratas (abstract syntax trees – AST). Mais recentemente, Aguiar et al.
propuseram uma extensão de JavaML, denominada JavaML 2.0 [1], a qual adicionou
suporte para representar referências cruzadas entre as entidades do programa e para
reter as informações léxicas do código fonte (basicamente, comentários e dados de
formatação).
Este artigo apresenta uma evolução de JavaML 2.0, chamada AspectJML
(AspectJ Markup Language), que incorpora todas as características da linguagem
JavaML 2.0 e inclui suporte à estrutura sintática de AspectJ [2]. Esta melhoria foi
motivada pela inexistência de representações sintaticamente completas em XML para
linguagens baseadas no paradigma da Programação Orientada a Aspectos (POA) [8],
em particular, AspectJ, que é uma extensão orientada a aspectos de Java. Assim, a
principal contribuição deste artigo é apresentar AspectJML à comunidade de
desenvolvedores e pesquisadores da POA, estendendo assim os benefícios inerentes às
representações de código fonte em XML a esse novo paradigma. Para isso, ferramentas
estão sendo desenvolvidas para converter entre o código AspectJ e sua representação
correspondente em AspectJML (e vice-versa). Essas ferramentas serão futuramente
disponibilizadas publicamente, para benefício da comunidade como um todo.
O restante do artigo está organizado da seguinte forma. A próxima seção ilustra
as representações JavaML e JavaML 2.0, que constituem a base para AspectJML. A
seção 3 apresenta AspectJML em mais detalhes, incluindo seus principais elementos e
um exemplo de código em AspectJ representado nesse formato. A seção 4 descreve
potenciais aplicações para AspectJML, e a seção 6 discute alguns trabalhos
relacionados. A seção 7 conclui o artigo.
2. JavaML e JavaML 2.0
A linguagem de marcação JavaML [4] provê uma representação completa em XML
para código fonte Java. Esta representação, diferentemente da representação clássica em
texto plano, reflete a estrutura de programas Java diretamente na estrutura hierárquica
do documento XML. Uma das principais contribuições de Badros ao projetar JavaML
foi determinar um ponto intermediário entre a representação clássica do código fonte,
em texto plano, e sua AST. Isto garantiu que JavaML não fosse demasiadamente
import java.applet.*;
import java.awt.*;
public class MyApplet extends Applet {
public void paint(Graphics g) {
g.drawString("3^(-2) = " + Math.pow(3,-2), 25, 50);
}
}
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE java-source-program SYSTEM "java-ml.dtd">
<java-source-program>
<java-class-file name="FirstApplet.java">
<import module="java.applet.*"/> <import module="java.awt.*"/>
<class name="FirstApplet" visibility="public">
<superclass name="Applet"/>
<method name="paint" visibility="public" id="FirstApplet_mth-15">
<type name="void" primitive="true"/>
<formal-arguments>
<formal-argument name="g" id="FirstApplet_frm-13"><type
name="Graphics"/></formal-argument>
</formal-arguments> <block>
<send message="drawString"> <target><var-ref name="g"
idref="FirstApplet_frm-13"/></target>
<arguments><binary-expr op="+"><literal-string value="3^(-2) =
"/>
<send message="pow">
<target><var-ref name="Math"/></target>
<arguments><literal-number kind="integer"
value="3"/><unary-expr op="-"><literal-number kind="integer"
value="2"/></unary-expr></arguments>
</send>
</binary-expr><literal-number kind="integer"
value="25"/><literal-number kind="integer" value="50"/>
</arguments>
</send> </block> </method> </class> </java-class-file>
</java-source-program>
<?xml version="1.0" encoding="UTF-8"?>
<java-source-program xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="javaml-2.xsd">
<java-class-file name="FirstApplet.java"> <import module="java.applet.*"/> <import
module="java.awt.*"/>
<class name="FirstApplet" id="LFirstApplet;" idkind="type">
<modifiers> <modifier name="public"/> </modifiers>
<superclass name="Applet" idref="Ljava/applet/Applet;" idkind="type"/>
<method name="paint" id="LFirstApplet;paint(Ljava/awt/Graphics;)V" idkind="method">
<modifiers> <modifier name="public"/> </modifiers> <type name="void" primitive="true"/>
<formal-arguments>
<formal-argument name="g" id="LFirstApplet;arg15" idkind="formal"><type
name="Graphics" idref="Ljava/awt/Graphics;" idkind="type"/></formal-argument>
</formal-arguments>
<block><send message="drawString"
idref="Ljava/awt/Graphics;drawString(Ljava/lang/String;II)V" idkind="method">
<target><formal-ref name="g" idref="LFirstApplet;arg15" idkind="formal"/></target>
<arguments><binary-expr op="+"><literal-string value="3^(-2) = "/><send
message="pow" idref="Ljava/lang/Math;pow(DD)D" idkind="method">
<target><type name="Math" idref="Ljava/lang/Math;" idkind="type"/></target>
<arguments><literal-number kind="integer" value="3"/><unary-expr op="-"><literalnumber kind="integer" value="2"/></unary-expr></arguments> </send>
</binary-expr><literal-number kind="integer" value="25"/><literal-number kind="integer"
value="50"/></arguments>
</send> </block> </method> </class> </java-class-file>
<type-dependences>
<type-dependence filename="FirstApplet.java" signature="LFirstApplet;">
<type-ref signature="Ljava/applet/Applet;"/><type-ref signature="Ljava/awt/Graphics;"/>
<type-ref signature="Ljava/lang/Math;"/><type-ref signature="Ljava/lang/Double;"/>
<type-ref signature="Ljava/lang/StringBuffer;"/>
</type-dependence>
<type-dependence filename="rt.jar/java/applet(Applet.class)"
signature="Ljava/applet/Applet;"/>
<type-dependence filename="rt.jar/java/awt(Graphics.class)"
signature="Ljava/awt/Graphics;"/>
<type-dependence filename="rt.jar/java/lang(Math.class)" signature="Ljava/lang/Math;"/>
<type-dependence filename="rt.jar/java/lang(Double.class)" signature="Ljava/lang/Double;"/>
<type-dependence filename="rt.jar/java/lang(StringBuffer.class)"
signature="Ljava/lang/StringBuffer;"/>
</type-dependences> </java-source-program>
Figura 1. a) Exemplo de código Java (no alto à direita), e representações do
exemplo em b) JavaML (em baixo à esquerda) e c) JavaML 2.0 (à direita).
descritiva (representação direta da AST) e nem exigisse nenhum tipo de análise sintática
dos nós do documento XML resultante. A Figura 1(a) mostra um pequeno exemplo de
código Java e a Figura 1(b) ilustra a sua representação correspondente em JavaML.
A linguagem JavaML 2.0 [1], por sua vez, adiciona a JavaML informações
léxicas e semânticas que originalmente foram deixadas de fora por Badros. Sobre o
aspecto léxico, JavaML 2.0 preserva informações sobre formatação e comentários. Em
relação às informações semânticas, esta versão implementa a referência cruzada de
todos os símbolos do programa e inclui informações sobre as dependências de tipos
externos. Devido a essas informações adicionais, a representação em JavaML 2.0 de um
código Java tende a ser muito mais verbosa do que a representação correspondente em
JavaML do mesmo código. Esta propriedade pode ser notada na Figura 1(c), que ilustra
a representação em JavaML 2.0 do código fonte mostrado na Figura 1(a).
3. A Linguagem de Marcação AspectJML
A linguagem AspectJML estende a linguagem JavaML 2.0 com suporte às estruturas
sintáticas particulares da linguagem AspectJ [2]. Abaixo apresentamos os principais
elementos que compõem o esquema de AspectJML, e em seguida mostramos um
exemplo de código AspectJ e partes de sua representação em AspecJML.
3.1. Esquema
O esquema de AspectJML foi definido através da evolução direta do esquema de
JavaML 2.0 para suportar as estruturas sintáticas introduzidas por AspectJ. Conforme
apresentado em [6], a linguagem AspectJ é composta por três diferentes
(sub)linguagens: (1) código Java normal, (2) declarações de aspectos, e (3) definições
de conjuntos de junção. Cada uma dessas linguagens tem sua própria estrutura léxica e
sintática. Neste sentido, o esquema de AspectJML foi construído com base no esquema
definido em JavaML 2.0, e nas gramáticas das linguagens de declaração de aspectos e
de definição de conjuntos de junção.
A primeira decisão de projeto na construção do esquema foi determinar, no
esquema de JavaML 2.0, onde acrescentar a declaração de aspectos e a definição de
conjuntos de junção. Em seguida, determinou-se como representar aspectos e conjuntos
de junção em XML, gerando a hierarquia de elementos de AspectJML. Para manter a
compatibilidade com a representação de Java em JavaML 2.0, foram criados, em
AspectJML, os elementos aspectj-source-program e aspectj-file, similares aos
elementos java-source-program e java-class-file, de JavaML 2.0.
3.1.1. Declaração de aspectos
A definição de um aspecto representa a segunda linguagem que compõe o AspectJ. De
acordo com a gramática de AspectJ, um aspecto pode ser declarado de duas maneiras:
(1) como uma declaração de tipo (type declaration), ligado diretamente a uma unidade
de compilação (compilation unit); ou (2) como um membro de uma classe (class
member declaration), de uma interface (interface member declaration) ou de outro
aspecto (aspect member declaration). Para AspectJML suportar a declaração de
aspectos no caso (1), é suficiente incluir um elemento do tipo aspect como um subelemento do elemento aspectj-file. No caso (2), basta adicionar um elemento aspect
como um sub-elemento dos elementos class, interface e do próprio aspect.
O elemento aspect é composto por elementos do tipo modifiers, interface,
perclause, body e um elemento superaspect ou superclass. O elemento superaspect, a
exemplo do elemento superclass, é uma simples referência a um aspecto. O corpo do
aspecto, elemento body, é composto por elementos do tipo aspect, class, interface,
method, declare, advice, pointcut, field e intertype-member-declaration. Destes, este
último define um método ou atributo em uma determinada classe. Alguns elementos
citados acima não serão detalhados por questões de espaço.
Os elementos modifiers, interface, class e method fazem parte da especificação
original de Java e, portanto, já estão definidos no esquema de JavaML 2.0. O elemento
advice, referente a um adendo em AspectJ, é composto por elementos do tipo throws,
pointcut-expr, block, formal-arguments e um formal-argument. Os elementos pointcut e
pointcut-expr serão detalhados a seguir.
3.1.2. Definição de conjuntos de junção
De maneira análoga, um conjunto de junção pode ser definido como membro de uma
classe, de uma interface ou de um aspecto. Desta forma, para AspectJML suportar a
definição de conjuntos de junção, basta adicionar um elemento do tipo pointcut, que
representará um conjunto de junção em AspectJML, com sub-elemento dos elementos
Tabela 1. Categorização dos tipos de expressões de conjuntos de junção
Elementos AspectJ
If
call, execution, withincode
initialization, preinitialization
staticinitialization, handler, within
get, set
cflow, cflowbelow e expressão de
pointcut entre parênteses
this, target
args, referência a um pointcut
existente
adviceexecution
Elementos AspectJML
Informações Requeridas
if
Expressão binária do Java
method-constructor-pointcut-expr Padrão de construtor ou
padrão de método
constructor-pointcut-expr
Padrão de construtor
classname-pointcut-expr
Padrão de nome de classe
field-pointcut-expr
Padrão de atributo
pointcut-pointcut-expr
Expressão de pointcut
formal-argument-pointcut-expr
formal-arguments-pointcut-expr
advice-execution-expr
Padrão de parâmetro
específico de pointcuts
Padrão de lista de parâmetros
específicos de pointcuts
Não exige informações
complementares
class, interface e aspect. O elemento pointcut é composto por elementos do tipo
modifiers, formal-arguments e pointcut-expr. Além destes elementos, um conjunto de
junção também tem os atributos name e id.
A estrutura do elemento pointcut-expr compreende a terceira linguagem que
compõe o AspectJ. São expressões de conjuntos de junção os elementos iniciados pelas
palavras reservadas call, execution, initialization, preinitialization, staticinitialization,
get, set, handler, adviceexecution, within, withincode, cflow, cflowbelow, if, this, target,
args, uma referência a um conjunto de junção existente e uma expressão de conjunto de
junção entre parênteses. Estes 19 tipos de expressões de conjuntos de junção foram
classificados em 9 elementos do AspectJML, conforme mostra a Tabela 1. Esta
classificação agrupou elementos que necessitavam informações da mesma natureza. Por
exemplo, os elementos cflow e cflowbelow ficaram na mesma classe por necessitarem
de uma expressão de conjunto de junção para completar sua definição.
Conforme exibido na coluna “Informações Requeridas” da Tabela 1, expressões
de conjuntos de junção exigem padrões de elementos de linguagem. Para tratar esta
questão, foram criados diversos tipos de padrões de elementos em AspectJML. Para
exemplificar a definição dos tipos de padrões de elementos, será mostrada a seguir a
estrutura do class-type-dot-id, elemento que compõe a definição das expressões dos
conjuntos de junção method-constructor-pointcut-expr e field-pointcut-expr.
O elemento class-type-dot-id é composto por um padrão de tipo de dado seguido
de um padrão de identificador. O padrão de tipo de dado pode ser um simples padrão de
nome (name-pattern) ou uma expressão de padrão de tipo (type-patt-expr) seguido de
um padrão simples de nome (representado pelo atributo simple-name-patt). Além destes
elementos, há também um qualificador de padrão (representado pelo atributo qualifier)
que, neste caso, pode assumir os seguintes valores: ‘.’, ‘+’ e ‘..’. A definição do
elemento class-type-dot-id baseou-se na expressão regular que determina o elemento
classtype_dot_id da linguagem AspectJ, ilustrada na Figura 2.
<clastype_dot_id> ::=
<simple_name_pattern>
| <name_pattern> ‘.’ <simple_name_pattern>
| <name_pattern> ‘+’ ‘.’ <simple_name_pattern>
| <name_pattern> ‘..’ <simple_name_pattern>
| (<type_pattern_expr>) ‘.’ <simple_name_pattern>
Figura 2. Estrutura do elemento classtype_dot_id.
public aspect ChecaExpoente extends Object{
pointcut potenciacaopc(double arg0, double arg1):
args(arg0, arg1) && (call (double Math.po*(doub*, *)));
double around(double arg0, double arg1): potenciacaopc(arg0,
arg1) {
if (arg1 < 0) {
System.out.println("Expoente negativo será considerado
zero.");
return 1.; //Considera expoente arg1 = 0
} else return proceed(arg0, arg1); }
}
<advice id="LChecaExpoente;(DD)D" idkind="advice" kind="around">
<type name="double" primitive="true"/>
<formal-arguments>
<formal-argument name="arg0" id="LChecaExpoente;arg21" idkind="formal">
<type name="double" primitive="true"/>
</formal-argument>
<formal-argument name="arg1" id="LChecaExpoente;arg36" idkind="formal">
<type name="double" primitive="true"/>
</formal-argument>
</formal-arguments>
<formal-arguments-pointcut-expr type="pointcut-ref">
<pointcut-ref name="potenciacaopc" idref="LChecaExpoente;potenciacaopc"/>
<formal-arguments-pointcut-patt>
<formal-argument-pointcut-patt qualifier="simple">
<formal-ref name="arg0" idref="LChecaExpoente;arg21" idkind="formal"/>
</formal-argument-pointcut-patt>
<formal-argument-pointcut-patt qualifier="simple">
<formal-ref name="arg1" idref="LChecaExpoente;arg36" idkind="formal"/>
</formal-argument-pointcut-patt>
</formal-arguments-pointcut-patt>
</formal-arguments-pointcut-expr>
<block>...</block>
</advice>
<pointcut name="potenciacaopc" id="LChecaExpoente;potenciacaopc">
<formal-arguments>
<formal-argument name="arg0" id="LChecaExpoente;arg6" idkind="formal">
<type name="double" primitive="true"/> </formal-argument>
<formal-argument name="arg1" id="LChecaExpoente;arg10" idkind="formal">
<type name="double" primitive="true"/> </formal-argument> </formalarguments>
<binary-pointcut-expr op="&&">
<formal-arguments-pointcut-expr type="args">
<formal-arguments-pointcut-patt> <formal-argument-pointcut-patt
qualifier="simple">
<formal-ref name="arg0" idref="LChecaExpoente;arg6" idkind="formal"/>
</formal-argument-pointcut-patt> <formal-argument-pointcut-patt
qualifier="simple">
<formal-ref name="arg1" idref="LChecaExpoente;arg10" idkind="formal"/>
</formal-argument-pointcut-patt> </formal-arguments-pointcut-patt>
</formal-arguments-pointcut-expr>
<method-constructor-pointcut-expr type="call">
<method-patt>
<basic-type-patt-expr><name-patt simple-name-patt="double"/></basictype-patt-expr>
<class-type-dot-id simple-name-patt="po*" qualifier="dot">
<name-patt simple-name-patt="Math"/> </class-type-dot-id>
<formal-arguments-patt>
<formal-argument-patt> <basic-type-patt-expr>
<name-patt simple-name-patt="doub*"/> </basic-type-patt-expr>
</formal-argument-patt>
<formal-argument-patt> <basic-type-patt-expr> <name-patt simplename-patt="*"/>
</basic-type-patt-expr> </formal-argument-patt> </formal-argumentspatt>
</method-patt>
</method-constructor-pointcut-expr>
</binary-pointcut-expr>
</pointcut>
Figura 3. a) Exemplo de um aspecto em AspectJ (no alto à esquerda) e a
representação correspondente em AspecJML para b) o conjunto de junção
(à direita) e c) o adendo (em baixo à esquerda) definidos pelo aspecto.
3.2. Exemplo
A Figura 3(a) mostra um exemplo bastante simples de um aspecto definido em AspectJ,
denominado ChecaExpoente. Este aspecto tem como única finalidade alterar o
comportamento do método Math.pow (que calcular a potência entre dois valores do tipo
double passados como parâmetro) para não calcular potências de expoentes negativos.
As Figuras 3(b) e 3(c) mostram, respectivamente, a representação em AspectJML do
conjunto de junção e do adendo definidos pelo aspecto da Figura 3(a). Por questões de
espaço, e por ser similar ao elemento block da Figura 1(c), omitiu-se do exemplo o
elemento block do elemento advice.
4. Aplicações
A principal motivação para criação de AspectJML foi o interesse em desenvolver uma
ferramenta de refatoração [5] para AspectJ, utilizando tecnologias XML. Como
qualquer outra técnica de alteração de código, refatorações são aplicadas mais
eficientemente se realizadas através de ferramentas automatizadas. Neste contexto, foi
proposto um arcabouço de refatoração, denominado RefaX [11], que utiliza padrões
abertos, baseados em XML, para facilitar a implementação de ferramentas de
refatoração de código de forma independente de representação de código, tecnologia de
manipulação e linguagem de programação. O trabalho relatado neste artigo tem como
objetivo imediato facilitar a criação e implementação de refatorações para
AspectJ, através da extensão do arcabouço RefaX.
No entanto, a facilidade de manipulação das estruturas de código oferecida pela
representação em XML, bem como o amplo espectro de tecnologias XML atualmente
disponíveis, extrapolam os benefícios de AspectJML para inúmeros outros tipos de
atividades de manipulação de código, como, por exemplo, cálculo de métricas,
identificação de más práticas de programação (ou bad smells), engenharia reversa, e
operações de re-estruturação de código em geral.
5. Trabalhos Relacionados
Este trabalho apresenta similaridades com JBoss AOP [7], AspectWerkz [3] e AML [9]
em termos de utilizar documentos XML para representar código orientado a aspectos.
Apesar disso, nenhum destes trabalhos visa utilizar o código fonte representado em
XML para realizar atividades de análise estrutural e semântica nem implementar
refatorações.
JBoss AOP é um arcabouço da POA de propósito geral que visa suportar
aplicações Java/J2EE comerciais. Além da capacidade de definir comportamentos
transversais, JBoss AOP oferece também a implementação de um conjunto de aspectos
de sistema já prontos, para atender a interesses não funcionais como cache, segurança e
suporte a transações. AspectWerkz é outro arcabouço de propósito geral voltado para a
programação orientada a aspectos em Java, e que permite definir aspectos através de
documentos XML. Por fim, AML é um modelo independente de linguagem, também
baseado em XML, para construir linguagens orientadas a aspectos baseadas em XML.
Em linhas gerais, o modelo AML abstrai os detalhes da programação orientada a
aspectos que são dependentes de uma determinada linguagem ou plataforma de
desenvolvimento, e suporta a implementação de extensões do modelo para solucionar
problemas específicos.
Diferentemente das propostas acima, que visam aumentar o nível de abstração
necessário para programar em linguagens orientadas a aspectos, AspectJML oferece
uma representação de código completa para AspectJ, incluindo tanto informações
léxicas quanto sintáticas e semânticas, viabilizando, assim, a utilização de tecnologias
XML em atividades como análise estrutural e refatoração, por exemplo.
6. Conclusão
Este artigo apresentou AspectJML, uma linguagem de marcação baseada em XML para
AspectJ. AspectJML tem como principal vantagem facilitar a identificação e
manipulação de elementos estruturais de um programa AspectJ. Este benefício resulta
da habilidade de AspectJML representar mais diretamente a estrutura sintática do
programa, o que não ocorre na representação textual clássica.
Dentre as principais aplicações para AspectJML, destaca-se o suporte ao rápido
desenvolvimento de ferramentas de análise e manipulação de código tirando proveito da
grande variedade de tecnologias XML já disponíveis. Neste contexto, ferramentas para
a conversão entre AspectJ e AspectJML serão futuramente disponibilizadas ao público,
permitindo que os benefícios oferecidos por essa forma de representação sejam
estendidos a um maior número de pesquisadores e desenvolvedores de ferramentas de
engenharia de software.
7. Referências
[1] Aguiar, A., David, G., Badros, G. J., “JavaML 2.0: Enriching the Markup Language for
Java Source Code”, In XML: Aplicações e Tecnologias Associadas (XATA'2004), Porto,
Portugal, Fevereiro de 2004.
[2] AspecJ, “AspectJ Project Homepage”. Disponível em http://www.aspectj.org. Último
acesso em 25/07/2005.
[3] AspectWerzk,
“AspectWerkz
Project
Homepage”.
http://aspectwerkz.codehaus.org. Último acesso em 25/07/2005.
Disponível
em
[4] Badros, G. J., “JavaML: A Markup Language for Java Source Code”, In Proc. of the 9th
Int. Conf. on the World Wide Web, Amsterdam, The Netherlands, May 2000.
[5] Fowler, M., “Refactoring: Improving the Design of Existing Programs”, Addison-Wesley,
1999.
[6] Hendren, L., Moor, O., Christensen, A., “The abc Scanner and Parser, Including an
LALR(1) Grammar for AspectJ”. Disponível em http://abc.comlab.ox.ac.uk/documents/
scanparse/index.html. Último acesso em 25/07/2005.
[7] JBoss
Group,
“JBoss
Aspect-Oriented
Programming”.
http://www.jboss.org/products/aop. Último acesso em 25/07/2005.
Disponível
em
[8] Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C. V., Loingtier, J.-M., Irwin,
J., “Aspect-Oriented Programming”, In Proc. of ECOOP’97, pp. 220-242, 1997.
[9] Lopes, C. V., Ngo, T. C., “The Aspect Markup Language and its Support of Aspect
Plugins”, ISR Technical Report UCI-ISR-04-8, October 2004.
[10] Mammas, E. and Kontogiannis, C., “Towards Portable Source Code Representations Using
XML”, In Proc. of the 7th Working Conf. on Reverse Engineering (WCRE’00), Brisbane,
Australia, pp. 172–18, November 2000.
[11] Mendonça, N. C., Maia, P. H. M., Fonseca, L. A., Andrade, R. M. C., “RefaX: A
Refactoring Framework Based on XML”, In Proc. of the 20th IEEE Int. Conf. on Software
Maintenance (ICSM’2004), Chicago, IL, EUA, September 2004.
[12] Simic, H., Topolnik, M., “Prospects of Encoding Java Source Code in XML”, In Proc. of
the 7th Int. Conf. on Telecomm. (ConTel’2003), Zagreb, Croatia, June 2003.
[13] W3C, “XML Path Language (XPath) Version 1.0”, November 1999. Disponível em
http://www.w3.org/TR/1999/REC-xpath-19991116. Último acesso em 25/07/2005.
[14] W3C, “XQuery 1.0 and XPath 2.0 Data Model”, November 2002. Disponível em
http://www.w3.org/TR/2002/WD-query-datamodel-20021115.
25/07/2005.
Último
acesso
em
[15] W3C, “XSL Transformations (XSLT) Version 1.0”, November 1999. Disponível em
http://www.w3.org/TR/xslt. Último acesso em 25/07/2005.
[16] W3C. “Extensible Markup Language (XML)”. Disponível em http://www.w3.org/XML/.
Último acesso em 25/07/2005.