Definiç˜ao Modular da Sintaxe de AspectJ usando - DC

Propaganda

Definição Modular da Sintaxe de AspectJ
usando Parsing Expression Grammar
Luı́s Eduardo de Souza Amorim,
Vladimir Oliveira Di Iorio,
Giorgio P. F. Guimarães Torres,
Felipe da Silva Pinheiro
Leonardo Vieira dos Santos Reis
Departamento de Ciências Exatas e Aplicadas
Universidade Federal de Ouro Preto
Email: [email protected]
Departamento de Informática
Universidade Federal de Viçosa
Email: [email protected], [email protected],
[email protected], [email protected]
Resumo—Propostas de novos recursos para linguagens orientadas a aspectos são objeto de muita pesquisa. Sendo AspectJ
a linguagem orientada a aspectos mais utilizada, boa parte
dessa pesquisa envolve a extensão de AspectJ. Para facilitar o
desenvolvimento e teste de novos recursos, é desejável se ter
uma especificação da linguagem AspectJ que seja construı́da de
forma modular e que ofereça facilidades para extensão.
Este trabalho apresenta uma definição da sintaxe de AspectJ
usando o formalismo conhecido como Parsing Expression Grammar (PEG). Um analisador sintático é gerado utilizando a ferramenta Rats!, que inclui recursos para construir especificações
com alta modularidade e para facilitar a extensibilidade. São
apresentados testes comparativos que mostram que esse analisador apresenta desempenho superior a outros analisadores com
caracterı́sticas similares.
I. I NTRODUÇ ÃO
A linguagem AspectJ, desde sua criação, tem sido a linguagem orientada a aspectos mais estudada e utilizada. Muitos
trabalhos desenvolvidos no sentido de propor novos recursos
e caracterı́sticas para linguagens orientadas a aspectos são
implementados como extensões para AspectJ, frequentemente
envolvendo extensão da sintaxe concreta [1], [2].
Para facilitar a especificação e testes de novos recursos para
AspectJ, é necessário, primeiramente, dispor de uma definição
sintática da linguagem que permita uma composição modular
de extensões. Novas construções propostas devem poder ser
combinadas sem que haja conflitos com as já existentes.
Ferramentas devem estar disponı́veis para automaticamente
construir, a partir dessas definições, analisadores sintáticos
cujo desempenho não seja comprometido pelas extensões.
Este artigo apresenta uma definição sintática para a linguagem AspectJ com o objetivo de facilitar a criação de extensões,
de maneira modular. A sintaxe é definida usando o formalismo
Parsing Expression Grammars (PEG) [3]. Um analisador
sintático é construı́do com a ferramenta Rats! [4], que fornece os recursos necessários para construção de analisadores
sintáticos rápidos, extensı́veis e modulares. Testes mostram
que essa combinação pode alcançar resultados superiores nos
quesitos de facilidade para criação de extensões e eficiência
dos analisadores, quando comparada com trabalhos similiares.
O texto está estruturado da seguinte maneira. Na Seção II,
apresentamos alguns trabalhos relacionados, em que também
foram propostas definições sintáticas para AspectJ. A Seção III
apresenta o formalismo de PEG e a Seção IV lista recursos da ferramenta Rats!. Na Seção V, detalhes sobre a
definição de AspectJ usando PEG e Rats! são discutidos. A
definição construı́da é comparada com trabalhos relacionados,
na Seção VI. Para a comparação, são avaliadas as facilidades
para extensibilidade e recursos de modularidade, e ainda o
desempenho dos analisadores sintáticos gerados. Finalmente,
a Seção VII apresenta conclusões e possı́veis trabalhos futuros.
II. T RABALHOS R ELACIONADOS
Esta seção discute diferentes especificações para a sintaxe
de AspectJ, usadas para implementar analisadores sintáticos
para a linguagem. Oferecimento de recursos para extensibilidade é uma preocupação de alguns trabalhos, pois foram
desenvolvidos com o objetivo de proporcionar facilidades para
pesquisa sobre possı́vel evolução de AspectJ.
A ferramenta ajc [5] consiste de um compilador completo
para AspectJ, projetado de modo a ter geração de código e
execução eficientes. É o compilador original para AspectJ,
atualmente desenvolvido e suportado pelo projeto AspectJ
Eclipse. Não são oferecidas facilidades para extensibilidade,
uma vez que isso não fez parte dos objetivos principais do
projeto.
O projeto AspectBench Compiler (abc) [6] também oferece
um compilador completo para a linguagem AspectJ. Esse
compilador foi projetado de modo a permitir uma maior
facilidade para extensão de seus componentes, especialmente
o analisador sintático.
No abc, a sintaxe de AspectJ é especificada por uma
gramática livre de contexto LALR(1). Um analisador sintático
é construı́do automaticamente, a partir dessa gramática, usando
a ferramenta Polyglot [7], que oferece recursos para extensibilidade da sintaxe. Produções podem ser estendidas, eliminadas
e inseridas na gramática. O analisador léxico do abc é dividido
em estados, que permitem que suas palavras-chave sejam
sensı́veis ao contexto, isto é, dependendentes do contexto onde
são utilizadas. Diferente da sintaxe, há poucos recursos para
extensão dos componentes léxicos da linguagem.
Outra definição para a gramática de AspectJ é baseada no
formalismo SDF [8], que oferece suporte à extensibilidade e
recursos para especificações de forma modular. Analisadores
sintáticos gerados com SDF são scannerless [9], isto é, reconhecem construções léxicas ao mesmo tempo em que realizam
a análise sintática. A definição de AspectJ com SDF pode
seguir um dos três modelos:
• AJF, que é a definição mais liberal, onde somente ambiguidades reais são resolvidas, por exemplo, reservando
palavras-chave em pontos especı́ficos.
• AJC, que adiciona restrições à linguagem para ser mais
compatı́vel com o compilador oficial de AspectJ. As
restrições adicionais são em maioria relacionadas a conflitos shift-reduce no analisador sintático LALR de ajc.
• ABC, que usa palavras-chave sensı́veis ao contexto. Define a linguagem suportada pelo compilador abc.
Este trabalho apresenta uma especificação da sintaxe de
AspectJ utilizando o formalismo conhecido como Parsing
Expression Grammar (PEG), que é discutido na Seção III.
Até onde vai nosso conhecimento, esta é a primeira descrição
completa de AspectJ usando PEG.
III. PARSING E XPRESSION G RAMMARS
O sistema generativo de Chomsky, particularmente gramáticas livres de contexto (CFG, do inglês, Context Free
Grammars) e expressões regulares, foram, por muito tempo,
os formalismos mais utilizados para expressar a sintaxe de
linguagens de programação. Parsing Expression Grammars
(PEG) [3] é um novo formalismo oferecido para tal propósito.
PEGs são parecidas estruturalmente com gramáticas livres de
contexto, contendo recursos de expressões regulares e notação
Extended Backus-Naur Form.
A ideia de PEG está intimamente relacionada à construção
de analisadores top-down, que podem ser considerados como
uma forma mais natural e compreensı́vel de análise sintática.
Sintaticamente, PEGs são similares a CFGs, mas têm uma
interpretação diferente, diretamente ligada à implementação de
uma análise descendente recursiva (recursive descent parser).
Uma diferença chave entre PEG e CFG é a utilização do
operador de escolha “prioritária” (representado pelo sı́mbolo
‘/’) que, diferentemente do operador ‘ou’ (representado por
‘|’), leva em consideração a ordem na qual os padrões são
definidos.
Diferentemente de CFGs, PEGs não são ambı́guas, ou seja,
se uma palavra é “aceita”, ela possui somente uma árvore
de derivação (parse tree) válida. Isso faz com que PEGs
sejam úteis para expressar linguagens de programação, e não
linguagens naturais. PEG, assim como SDF, é scannerless, ou
seja, não é necessária análise léxica separada.
Formalmente, uma PEG pode ser definida como uma tupla
(Σ, N , P , es ) onde:
Σ
é um conj. finito de terminais.
N
é um conj. finito de não-terminais.
P
é um conj. finito de regras (parsing rules) da forma
“A ← e” onde A ∈ N e e é uma parsing expression.
es
é uma parsing expression chamada expressão inicial.
Uma parsing expression é uma expressão hierárquica similar
a uma expressão regular, que é construı́da conforme o modelo
descrito a seguir.
Uma parsing expression atômica consiste de:
• um sı́mbolo terminal;
• um sı́mbolo não-terminal; ou
• a palavra vazia λ.
Dadas parsing expressions e, e1 , e e2 , uma nova parsing expression pode ser construida usando os operadores mostrados
na Tabela I. Aspas simples ou duplas representam uma palavra
literal, e abre e fecha colchetes representam uma classe de
caracteres. O simbolo ‘.’ representa qualquer caractere.
Operador
‘’
“”
[]
.
(e)
e?
e*
e+
&e
!e
e1 e2
e1 / e2
Tipo
primário
primário
primário
primário
primário
sufixo unário
sufixo unário
sufixo unário
prefixo unário
prefixo unário
binário
binário
Descrição
String Literal
String Literal
Classe de Caracteres
Qualquer Caracter
Agrupamento
Opcional
Zero ou mais
Um ou mais
Predicado And
Predicado Not
Sequência
Escolha Priorizada
Tabela I
O PERADORES PARA CONSTRUÇ ÃO DE PARSING E XPRESSIONS
A sequência de expressões ‘e1 e2 ’ procura uma correspondência (match) de e1 imediatamente seguido por uma correspondência de e2 . Se alguma dessas correspondências falha,
a análise volta ao ponto anterior, utilizando backtracking. A
expressão de escolha priorizada ‘e1 / e2 ’ primeiro realiza uma
tentativa de correspondência com e1 , e depois com e2 do
mesmo ponto, se e1 falha. Os operadores ?, * e + são os
mesmos presentes na sintaxe de expressões regulares.
Já os operadores & e ! denotam predicados sintáticos,
e não consomem valores da entrada quando são avaliados,
somente os valores booleanos de correspondência da entrada
são utilizados.
Uma das implementações de PEG mais eficientes é a proporcionada pela ferramenta Rats!, discutida na seção seguinte.
IV. Rats!
Conforme discutido na Seção II, ferramentas para definir extensões de linguagens necessitam de suporte a extensibilidade
em diversos nı́veis. Rats! [10] é uma ferramenta para geração
de analisadores sintáticos para Java que suporta facilmente
sintaxes extensı́veis.
Gramáticas para construções de analisadores sintáticos para
Rats! são escritas em PEG, o que permite uma melhor performance do analisador quando são construı́das extensões para
gramáticas, visto que PEG não permite ambiguidade. Além
disso, gramáticas escritas para Rats! são concisas e facilmente
modificáveis. Rats! permite:
1) Usar Parsing Expression Grammars em vez de gramáticas livres de contexto, e integrar análise léxica com
análise sintática, isto é, é scannerless;
2) Organizar especificações em módulos;
3) Permitir suporte à geração automática de Árvores de
Sintaxe Abstratas (AST, do inglês Abstract Syntax Tree);
4) Prover uma interface bem definida para geração de
analisadores sintáticos extensı́veis.
Outra vantagem de um analisador sintático gerado por essa
ferramenta é que Rats! memoriza resultados intermediários,
o que garante um tempo linear na presença de lookahead
ilimitado e backtracking [11]. Por esse motivo, o analisador
sintático gerado pode ser chamado de packrat parser.
Apesar das gramáticas para Rats! serem construı́das utilizando PEG, sua sintaxe possui algumas diferenças e são mais
expressivas do que a descrição de PEG da Seção III.
Uma gramática em Rats! consiste em um módulo no nı́vel
superior, que é o módulo especificado na linha de comando
ao invocar o Rats! e zero ou mais módulos dependentes. Cada
módulo pode iniciar com várias declarações:
• Uma declaração de módulo, que especifica seu nome
completo dentro da gramática. Opcionalmente essa declaração pode ter um ou mais parâmetros, que são tratados
como nomes de outros módulos e substituidos através do
seu corpo.
• Zero ou mais declarações de dependência que especificam
como o módulo atual depende de outros módulos.
Rats! permite três tipos de declarações de dependências.
Dependências do tipo import fazem não-terminais de outros módulos referenciáveis de dentro do módulo corrente.
Dependências do tipo modify fazem as produções de outro
módulo disponı́veis para modificação no módulo atual. Cada
módulo pode ter apenas uma dependência do tipo modify.
Além disso, podem haver dependências do tipo instantiate que
instanciam outros módulos (normalmente módulos que possuem argumentos) e tornam seus nomes disponı́veis para uso
em outras dependências. Esses são recursos fundamentais para
aumentar a modularidade e extensibilidade das especificações.
Após as declarações, seguem as produções. Uma produção
escrita segundo a especificação de Rats! é da forma:
Atributos Tipo Não-Terminal = e ;
onde os Atributos são uma lista, separada por espaço, de zero
ou mais atributos da produção, Tipo é o Tipo em Java do valor
semântico, Não-terminal é o nome do não-terminal, e e é a
expressão a ser analisada. Além disso, uma expressão pode
ser rotulada com um nome, que possibilita sua modificação
por outro módulo.
Expressões podem ser construı́das utilizando os elementos
da Tabela I juntamente com os elementos da Tabela II, que são
operadores especı́ficos de Rats!. O operador é semelhante
ao operador de qualquer caracter de PEG. Já o operador { }
define uma ação semântica, semelhante às ações definidas para
gramática livres de contexto. Os outros operadores são usados
na construção de expressões. id : e constrói uma amarração
entre e, fazendo-o ser do tipo id. É possı́vel também amarrar
uma expressão a um String, utilizando o operador “”: e, e além
disso, podemos marcar uma produção utilizando o operador
< nome >, onde nome é o nome da marcação.
Operador
{}
id : e
“ ”: e
void : e
<nome> e1 ... e2
Tipo
primário
primário
prefixo unário
prefixo unário
prefixo unário
binário
Descrição
Qualquer Caracter
Ação Semântica
Amarração
Combinação de String
Valor void
Sequência
Tabela II
O PERADORES PARA CONTRUÇ ÃO DE E XPRESSIONS EM Rats!
Em uma produção, é opcional a definição de uma ação
semântica visto que Rats! constrói automaticamente a árvore
de sintaxe abstrata. Uma produção sem ação semântica deve
ser declarada do tipo genérico.
Conforme dito anteriormente, um módulo pode modificar
produções de outro módulo através da declaração modify.
Produções que adicionam novas opções a produções de outro módulo podem ser escritas utilizando o operador +=, e
definindo a posição onde ela acrescenta a nova alternativa.
Pode-se também remover opções de uma produção através
do operador -=. Finalmente, é possı́vel substituir todas as
alternativas através do operador de sobreescrever, :=.
Boa parte dos recursos de extensibilidade e facilidades para
especificações de forma modular de Rats! foram utilizadas na
definição de AspectJ que é discutida na Seção V.
V. D EFINIÇ ÃO DE A SPECT J
Como AspectJ é uma extensão da linguagem Java, sua
definição tem como base a gramática de Java. A definição
proposta neste artigo segue os moldes da gramática construı́da
pelo compilador abc [6] para Java 4.
A. Análise Léxica
A análise léxica de AspectJ é complicada pelo fato de que
existem três linguagens diferentes sendo analisadas: o código
Java normal, as declarações de aspectos e as definições de
pointcut.
O compilador abc divide o contexto da linguagem nessas três linguagens e faz com que as palavras-chave sejam
sensı́veis a sua localidade. Porém, ao utilizarmos PEG, que
é uma linguagem scannerless, optamos por implementar a
análise léxica seguindo a definição AJC vista na Seção II,
por ser uma definição mais liberal e compatı́vel com essa
caracterı́stica.
Sendo assim, neste trabalho, a análise léxica é feita juntamente com a análise sintática, com palavras-chave empregadas
em pontos especı́ficos da gramática.
B. Análise Sintática
Vimos, na Seção IV, que Rats! é uma ferramenta para
geração de analisadores sintáticos que permite extensibilidade
e modularidade. Essas caracterı́sticas foram essenciais para a
escolha dessa ferramenta para a construção da gramática de
AspectJ utilizando PEG.
A gramática de Java, base de AspectJ, que foi implementada
originalmente por Robert Grimm [10], possui a modularidade
necessária para implementação da extensão. A gramática de
AspectJ segue praticamente o mesmo esquema de modularidade da gramática de Java, estendendo-a em alguns módulos.
Os módulos para as gramáticas de Java e AspectJ foram
esquematizados conforme a Figura 1.
Figura 1.
Módulos contidos na Gramática de AspectJ
A figura mostra uma separação completa entre AspectJ
e Java. Cada identificador representa um módulo. Todas
as dependências são tratadas com modificações de módulo
(modify) ou passagem de módulos como parâmetro para os
novos módulos de AspectJ. Os módulos principais instanciam
vários módulos (instantiate) para que seus nomes possam ser
utilizados como parâmetro.
O módulo principal é identificado com o nome AspectJ. Ele
instancia vários módulos e modifica o módulo AspectJCore.
Ao fazer isso, todas as produções existentes em AspectJCore
são executadas a partir deste módulo. Os módulos instanciados
são os parâmetros necessários a AspectJCore.
Spacing é um módulo para análise léxica que contém
produções para definir o espaçamento entre cada token do
programa. Além disso, define também como se dão os comentários na linguagem. Como, nesse caso, comentários e
espaçamento de AspectJ são idênticos aos de Java, esse
módulo não é modificado.
Symbol também é um módulo que contém uma gramática
para análise léxica que contém os sı́mbolos e operadores
necessário para JavaSymbol. AspectJSymbol o recebe como
parâmetro e o modifica, acrescentando o sı́mbolo “..”.
AspectJIdentifier é um módulo contendo os identificadores especı́ficos de AspectJ. Ele recebe como parâmetro AspectJSymbol e Spacing para modificar o módulo JavaIdentifier
e contém as produções necessárias para definir alguns identificadores em AspectJ, que podem possuir o sı́mbolo ‘*’.
JavaConstant e JavaType são módulos necessários para
AspectJCore, e só se modificam em virtude dos parâmetros
AspectJSymbol, AspectJIdentifier e Spacing passados a eles.
AspectJPatterns é um módulo acrescentado à hierarquia de
AspectJ, que define as construções de patterns dentro de um
aspecto. Patterns são padrões de nomes de métodos, classes,
tipos e expressões que são usados na definição de pointcuts
dentro de um programa em AspectJ. Eles permitem, por exemplo que identificadores contenham caracteres especiais para
definição de hierarquia de classes, ou contenham métodos,
classes ou tipos que comecem, terminem ou possuam alguma
sequência de caracteres.
O módulo AspectJCore modifica o módulo JavaCore, incluindo assim a definição de todas as construções presentes
em Java. Este módulo garante a extensibilidade entre Java e
AspectJ e possui como parâmetro os módulos instanciados
anteriormente. Através do operador +=, esse módulo acrescenta a opção de se construir um aspecto, adicionando AspectDeclaration ao não-terminal TypeDeclaration. Além disso,
esse módulo também modifica o não-terminal Declaration,
dando a possibilidade de se definir pointcuts e outros aspectos
dentro de uma construção (classe, interface ou aspecto). A
última modificação feita nas produções de Java consiste em
adicionar a possibilidade de se chamar o método proceed().
Isso é feito adicionando essa possibilidade ao não-terminal
PrimaryExpression. As produções vistas na Figura 2 ilustram
as modificações descritas neste parágrafo.
No mais, o módulo AspectJCore define como se dá a estrutura sintática em AspectJ, de maneira semelhante à estrutura
definida pela gramática LALR(1) do compilador abc.
Em se tratando da tradução da gramática em si, foram feitas
poucas modificações à gramática do abc, eliminando somente
casos de recursividade à esquerda, pois PEG não permite esse
tipo de recursividade.
C. Testes
Um analisador sintático foi gerado usando a ferramenta
Rats!. O analisador consiste em uma classe Java que recebe
um programa de entrada e o analisa. Caso o programa esteja
sintaticamente correto, uma representação por meio de uma
AST é construı́da.
Para testarmos o analisador com diversas instâncias,
foi utilizado o framework JUnit [12]. Os programas de
teste são os exemplos de aspectos definidos no endereço
http://www.eclipse.org/aspectj/sample-code.html. Todos os
testes foram corretamente processados pelo analisador.
Um único problema encontrado no conjunto de testes foi a
definição de um pointcut, num dos aspectos. A definição
execution(Object !Cloneable+.clone());
Node TypeDeclaration +=
<Interface> ...
/
<Aspect> AspectDeclaration
;
Node Declaration +=
<Class> ...
/
<Aspect> AspectDeclaration
/
<Pointcut> PointCutDeclaration
;
Node PrimaryExpression +=
<Proceed> ProceedExpression
/
<Call> ...
;
Figura 2.
Produções que estendem a Gramática de Java
não é aceita pelo analisador construı́do, nem pela gramática
do compilador abc. Porém, ao substituirmos essa definição por
execution(Object (!Cloneable+).clone());
a definição passa a ser aceita.
Isso ocorre, principalmente pelo fato da linguagem AspectJ
não possuir um padrão. As diferenças entre os modelos
apresentados na Seção II, mais especificamente, entre o AJC
e o ABC, fazem com que ocorra esse “erro” de sintaxe.
Foram também construı́dos exemplos que continham propositalmente erros sintáticos, introduzidos arbitrariamente no
conjunto descrito acima. Todos os testes com esses exemplos
apresentaram o resultado esperado.
conflitos entre as gramáticas e ainda oferece recursos para
especificações modulares.
Testes de desempenho foram realizados para avaliar a velocidade e o consumo de memória, comparando o analisador
sintático apresentado em [8] e o analisador produzido neste
trabalho. Os testes foram realizados no ambiente do Eclipse
Helios, instalado na arquitetura descrita a seguir:
• Processador AMD Athlon(tm), modelo P320, Dual-core,
2100Mhz
• Memória total instalada 4 Gigabytes
• Sistema Operacional Microsoft Windows 7 de 32 bits
Como o Rats! gera um analisador na linguagem Java, o
analisador sintático gerado a partir da descrição em SDF
deveria também estar escrito em Java, para que o teste ficasse
mais justo. Assim foi usado o gerador JSGLR, que faz parte
da ferramenta Spoofax [13] e atende aos requisitos desejados.
Enquanto analisadores sintáticos produzidos pelo Rats! não
necessitam nenhuma atividade prévia à análise, o JSGLR
precisa carregar uma tabela que descreve a gramática desejada,
antes de iniciar a análise dos programas. O tempo transcorrido
e o gasto de memória para a carga dessa tabela não foram
computados nos testes comparativos.
A Tabela III apresenta resultados da comparação. Os programas em AspectJ cuja sintaxe é analisada são os mesmos
programas usados nos testes da Seção V-C. Os casos de teste
que vão do 11 ao 14 consistem em replicação de partes do
código do programa de número 8, com o objetivo de testar
arquivos mais extensos. Nenhum desses casos apresentam erro
de sintaxe, pois o objetivo é testar a performance durante toda
a análise.
Número
do
teste
11
Tamanho do
Arquivo de Teste
(kbytes)
121,444
12
220,662
VI. C OMPARAÇ ÃO COM TRABALHOS SIMILARES
13
341,884
Este trabalho tem como objetivo apresentar uma especificação de AspectJ que facilite a construção de extensões, para
permitir experimentos com a linguagem. Dessa forma, não
pode ser comparado adequadamente com o compilador ajc [5],
que não tem objetivo de extensibilidade e não oferece recursos
para isso.
A gramática usada no compilador abc [6] serviu de modelo
para a definição apresentada na SeçãoV. Mas este trabalho não
apresenta um compilador completo como o abc. Comparando
as duas abordagens, pode-se concluir que a extensibilidade
é mais facilitada com a especificação deste trabalho, pois
extensões são definidas sem a geração de conflitos que o
analisador LR do Polyglot pode gerar. Além disso, os recursos
para extensibilidade do analisador léxico do abc são muito
restritos.
A especificação de uma gramática apresentada em [8],
escrita em SDF, é a que pode ser melhor comparada com
a deste trabalho. A SDF facilita extensibilidade, sem gerar
14
395,86
Parser
JSGLR
Rats!
JSGLR
Rats!
JSGLR
Rats!
JSGLR
Rats!
Tempo de
Análise
(ms)
3409
75
6701
201
15721
164
19090
180
Memória
Gasta na Análise
(kbytes)
117133
11603
160947
18147
189294
27839
141568
71631
Tabela III
TABELA DE COMPARAÇ ÃO DE DESEMPENHO
A Tabela III apresenta o tempo transcorrido na execução
dos analisadores sintáticos quando os programas de teste são
processados, bem como a memória utilizada. Os valores são
uma média de 5 execuções. O analisador apresentado neste
trabalho foi superior ao gerado pelo JSGLR, em todos os
casos de testes, tanto em tempo de processamento quanto em
memória consumida.
É possı́vel notar uma falta de linearidade entre os valores de
tempo de procesamento e de consumo de memória, quando se
comparam os testes 8 e 10. O teste 8 é uma classe em Java que
contém grande quantidade de comandos complexos. Já o teste
10 é um aspecto que contém apenas uma grande quantidade
de pointcuts. Os analisadores consomem mais recursos em um
programa complexo em Java, do que em um aspecto contendo
apenas pointcuts. Essa discrepância é ainda mais evidente no
analisador gerado com Rats!.
Através dos resultados dos testes, pode-se concluir que
o analisador sintático apresentado neste traballho é muito
mais eficiente que o apresentado em [8], quando gerado com
JSGLR.
Na questão de desempenho, outra possibilidade é fazer uma
comparação com o analisador sintático do compilador ajc,
visto que ele é um benchmark, ou seja, possui o melhor
desempenho dentre os trabalhos similares.
VII. C ONCLUS ÃO E T RABALHOS F UTUROS
R EFER ÊNCIAS
Este trabalho apresentou uma especificação e implementação de um analisador sintático para AspectJ. Para esse
analisador, foram destacadas caracterı́sticas esperadas, como
modularidade, facilidade para extensibilidade e eficiência na
execução. A sintaxe do analisador foi baseada na especificação
utilizada no projeto abc. Foi utilizado o formalismo PEG
para descrever a especificação e a ferramenta Rats! para gerar
automaticamente um analisador sintático.
O trabalho foi comparado com abordagens semelhantes.
A definição de AspectJ encontrada que mais se aproximava
do modelo proposto foi uma especificação em SDF, que
procura reunir qualidades de alta modularidade e oferecimento
de facilidades para construção de extensões. Comparando
o analisador apresentado neste trabalho com um analisador
gerado a partir da especificação em SDF, foi possı́vel observar
uma grande diferença de desempenho. O analisador proposto
apresentou resultados muito superiores em tempo de processamento e gasto de memória. Dessa forma, concluı́mos que o
objetivo do trabalho foi satisfatoriamente cumprido.
A gramática descrita neste trabalho pode ser obtida no
endereço http://code.google.com/p/aspectj-rats/, dentro de um
projeto Eclipse. O projeto inclui ainda todos os testes de
validação e os testes comparativos, permitindo reproduzir os
resultados discutidos na Seção VI.
A modularidade da especificação proposta não foi devidamente avaliada neste trabalho. Uma definição modular pode
tornar mais fácil reaproveitar suas partes, e facilitar também a
construção de extensões. Para realizar uma avaliação do trabalho nesses quesitos, faz parte dos planos futuros a elaboração
de diversas extensões de AspectJ baseadas na especificação
proposta, avaliando o processo de construção, de modo similar
ao realizado em [8]. É importante lembrar, que apesar de
não avaliar a extensibilidade, o próprio trabalho se trata da
implementação de uma extensão de uma linguagem, da linguagem AspectJ estendida da linguagem Java, e conforme vimos
na Seção V, não houve conflitos para sua implementação de
maneira modular.
Outra tarefa que faz parte dos planos futuros é produzir
uma nova definição que englobe as caracterı́sticas de AspectJ
5, incluindo funcionalidades como anotações e generics.
[1] J. Aldrich, “Open Modules: Modular Reasoning About Advice,” in
ECOOP 2005 - Object Oriented Programming: 19th European Conference, Glasgow, UK, July 25-29, 2005. Proceedings, ser. Lecture Notes
in Computer Science, A. P. Black, Ed., vol. 3586. Springer, 2005, pp.
144–168.
[2] Éric Tanter, K. Gybels, M. Denker, and A. Bergel, “Context-aware
aspects,” in Software Composition, 5th International Symposium, SC
2006, Vienna, Austria, March 25-26, 2006, Revised Papers, ser. Lecture
Notes in Computer Science, W. Löwe and M. Südholt, Eds., vol. 4089.
Springer, 2006, pp. 227–242.
[3] B. Ford, “Parsing expression grammars: a recognitionbased syntactic foundation.” in POPL, N. D. Jones and
X. Leroy, Eds. ACM, 2004, pp. 111–122. [Online]. Available:
http://pdos.csail.mit.edu/ baford/packrat/popl04/
[4] R. Grimm, “Better extensibility through modular syntax,” in PLDI ’06:
Proceedings of the 2006 ACM SIGPLAN conference on Programming
language design and implementation. New York, NY, USA: ACM,
2006, pp. 38–51.
[5] “The AspectJ Compiler,” avaliable from URL:
http://www.eclipse.org/aspectj/doc/next/devguide/ajc-ref.html.
[6] P. Avgustinov, A. S. Christensen, L. Hendren, S. Kuzins, J. Lhoták,
O. Lhoták, O. de Moor, D. Sereni, G. Sittampalam, and J. Tibble,
“abc: an extensible aspectj compiler,” in AOSD ’05: Proceedings of the
4th international conference on Aspect-oriented software development.
New York, NY, USA: ACM, 2005, pp. 87–98.
[7] N. Nystrom, M. R. Clarkson, and A. C. Myers, “Polyglot: An extensible
compiler framework for java,” in In 12th International Conference on
Compiler Construction. Springer-Verlag, 2003, pp. 138–152.
[8] M. Bravenboer, E. Tanter, and E. Visser, “Declarative, formal, and extensible syntax definition for AspectJ. A case for scannerless generalizedlr parsing,” in Proceedings of the 21th ACM SIGPLAN Conference
on Object-Oriented Programing, Systems, Languages, and Applications
(OOPSLA’06), W. R. Cook, Ed. Portland, Oregon, USA: ACM Press,
October 2006, pp. 209–228.
[9] D. J. Salomon and G. V. Cormack, “Scannerless nslr(1) parsing of
programming languages,” in Proceedings of the ACM SIGPLAN 1989
Conference on Programming language design and implementation, ser.
PLDI ’89. New York, NY, USA: ACM, 1989, pp. 170–178. [Online].
Available: http://doi.acm.org/10.1145/73141.74833
[10] R. Grimm, “Better extensibility through modular syntax,” in
Proceedings of the 2006 ACM SIGPLAN conference on Programming
language design and implementation, ser. PLDI ’06.
New
York, NY, USA: ACM, 2006, pp. 38–51. [Online]. Available:
http://doi.acm.org/10.1145/1133981.1133987
[11] M. G. J. van den Brand, J. Scheerder, J. J. Vinju, and
E. Visser, “Disambiguation filters for scannerless generalized
lr parsers,” in Proceedings of the 11th International
Conference on Compiler Construction, ser. CC ’02. London,
UK: Springer-Verlag, 2002, pp. 143–158. [Online]. Available:
http://portal.acm.org/citation.cfm?id=647478.727925
[12] “JUnit test tool, http://www.junit.org.”
[13] L. C. L. Kats and E. Visser, “The Spoofax language workbench. Rules
for declarative specification of languages and IDEs,” in Proceedings
of the 25th Annual ACM SIGPLAN Conference on Object-Oriented
Programming, Systems, Languages, and Applications, OOPSLA 2010,
October 17-21, 2010, Reno, NV, USA, M. Rinard, Ed., 2010, pp. 444–
463.
AGRADECIMENTOS
Por bolsas de iniciação cientı́fica que foram usadas por dois
dos autores deste trabalho, agradecemos à Fapemig e ao CNPq.