ELAINE DA SILVA MONTEIRO
Um Estudo Sobre Modelagem Orientada a Aspectos Baseada em
AspectJ e UML
Palmas – TO
2004
ii
ELAINE DA SILVA MONTEIRO
Um Estudo Sobre Modelagem Orientada a Aspectos Baseada em
AspectJ e UML
“Monografia
apresentada
como
requisito parcial da disciplina Prática
de
Sistemas
de
Informação
I
(Estágio) do curso de Sistemas de
Informação,
orientada
pela
Cristina D’ornellas Filipakis”
Palmas – TO
2004
Profª.
iii
ELAINE DA SILVA MONTEIRO
Um Estudo Sobre Modelagem Orientada a Aspectos Baseada em
AspectJ e UML
“Monografia
apresentada
como
requisito parcial da disciplina Prática
de
Sistemas
de
Informação
I
(Estágio) do curso de Sistemas de
Informação,
orientada
pela
Cristina D’ornellas Filipakis”
BANCA EXAMINADORA
Profª. Cristina D’ornellas Filipakis
Centro Universitário Luterano de Palmas
Prof. M.Sc. Fabiano Fagundes
Centro Universitário Luterano de Palmas
Prof. Jackson Gomes de Souza
Centro Universitário Luterano de Palmas
Palmas – TO
2004
Profª.
iv
Dedico este trabalho àqueles que sonham e,
que com paixão, fazem de suas vidas um
empenho para torná-los realidade.
v
AGRADECIMENTOS
Antes de todas as coisas, agradeço a DEUS. Agradeço por colocar em meu coração
grandes sonhos e por me capacitar a torná-los reais. Agradeço por sua doce presença em
minha vida, que me estimula a prosseguir sempre, mesmo diante das maiores dificuldades.
Vencer mais essa etapa não seria possível sem a ajuda das pessoas que para mim são
(e serão sempre) muito especiais. Pessoas estas que com um simples gesto, ou olhar me
fizeram acreditar e continuar. Não posso esquecer o esforço e empenho dedicados por parte
dos meus pais, Nilo Cavalcante Monteiro e Maria de Jesus da Silva Monteiro, sei que
sempre torceram por mim e vibram a cada conquista alcançada. Muito obrigada, o meu
desejo é ser um motivo de orgulho para vocês. Quero agradecer, também, a minha tia
Arcângela por sua preocupação e cuidado constantes.
Neste tempo de faculdade encontrei grandes amigos, (alguns mais chegados que
irmãos) estes fizeram da minha vida uma diversão à parte. Obrigada pelo companheirismo e
espírito de equipe que nos levaram a perder noites e noites para nos dedicarmos ao estudo e
algumas noites, também, para “desestressar” a cabeça. Em especial, agradeço ao
Alessandro Brandão, Anderson Luiz, Danilo, Nábia, Nalva Neila, Paulo, Pollyane, Renatto
e Victor, vocês fazem parte da minha alegria.
Agradeço, ainda, aos professores que me fizeram valorizar o saber. Alguns foram
mais adiante, foram conselheiros para vida. Este é o caso do Professor Fabiano, que nos
meus momentos de insegurança e medo soube me motivar (as apresentações de trabalhos
ilustram bem isso!!!). Sou muito grata pela Cristina, minha orientadora, por sua paciência e
contribuições para a concretização deste trabalho.
Muito Obrigada.
i
SUMÁRIO
1.
INTRODUÇÃO ...................................................................................... 1
1.1
Objetivos do trabalho................................................................................... 3
1.2
Organização do trabalho ............................................................................. 3
2.
REVISÃO DE LITERATURA ............................................................... 5
2.1
Abordagens Orientadas a Objetos .............................................................. 5
2.2
Abordagens Orientadas a Aspectos ............................................................ 7
2.2.1
Componentes ............................................. Erro! Indicador não definido.
2.2.2
Aspectos .................................................... Erro! Indicador não definido.
2.2.3
Benefícios da AOP .................................... Erro! Indicador não definido.
2.2.4
AspectJ ....................................................................................................... 9
2.2.4.1
Join points.......................................................................................... 11
2.2.4.2
Pointcuts ............................................................................................ 12
2.2.4.3
Advices .............................................................................................. 13
2.2.4.4
Introductions ...................................................................................... 14
2.2.4.5
Aspects............................................................................................... 14
2.3
A Importância da Modelagem................................................................... 17
2.3.1
UML ......................................................................................................... 18
2.3.1.1
Blocos de construção estrutural ......................................................... 19
2.3.1.1.1
Core............................................................................................. 19
2.3.1.1.2
Data Types .................................................................................. 21
2.3.1.1.3
Extension Mechanisms ............................................................... 22
2.3.1.2
Blocos de construção comportamental .............................................. 23
2.3.1.2.1
Common Behavior...................................................................... 23
2.3.1.2.2
Collaborations............................................................................. 23
ii
2.4
A Modelagem Orientada a Aspectos Baseada em AspectJ e UML........ 26
2.4.1
3.
Representando construções do AspectJ em UML .................................... 26
2.4.1.1
Join points.......................................................................................... 27
2.4.1.2
Pointcuts ............................................................................................ 29
2.4.1.3
Advices .............................................................................................. 31
2.4.1.4
Introductions ...................................................................................... 33
2.4.1.5
Aspects............................................................................................... 35
MATERIAIS E MÉTODOS .................................................................. 38
3.1
Local e Período ........................................................................................... 38
3.2
Materiais...................................................................................................... 38
3.2.1
Hardware .................................................................................................. 39
3.2.2
Software.................................................................................................... 39
3.2.3
Fontes Bibliográficas................................................................................ 39
3.3
Metodologia................................................................................................. 39
4.
RESULTADOS E DISCUSSÕES ........................................................ 40
5.
CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS ................... 46
6.
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 48
iii
Lista de Figuras
Figura 1 - Exemplo de herança entre os objetos ................................................................... 6
Figura 2 - Representação de um código entrelaçado (KICZALES, 2001)............................ 7
Figura 3 - Representação de um interesse multidimensional concentrado num aspecto
(KICZALES, 2001) ................................................................................................................ 8
Figura 4 - Representação da estrutura do AspectJ............................................................... 10
Figura 5 - Fluxo de controle em AspectJ (KICZALES, 2001)............................................ 12
Figura 6 - Aspecto CPMF que atua sobre as transações de saque e transferência da classe
Conta..................................................................................................................................... 15
Figura 7 - Classe Conta ....................................................................................................... 15
Figura 8 - Classe Teste ........................................................................................................ 16
Figura 9 - Resultado da compilação e execução do exemplo Banco .................................. 16
Figura 10 - Representação dos pacotes Behavioral Elements, Model Management e
Foundation da especificação UML (OMG, 2000)................................................................ 19
Figura 11- Diagrama de Classes para o domínio Bancário ................................................. 21
Figura 12 - Exemplo de um estereótipo contendo tagged values........................................ 22
Figura 13 - Diagrama de Seqüência para o domínio Bancário............................................ 25
Figura 14 - Estrutura de um pointcut nomeado ................................................................... 29
Figura 15 - Estereótipo <<Pointcut>> para operação (STEIN, 2002)............................. 31
Figura 16 - Estrutura de um advice ..................................................................................... 32
Figura 17 - Estereótipo <<Advice>> para operação (STEIN, 2002).................................. 33
Figura 18 - Estereótipo <<Introduction>> para operação (STEIN, 2002)...................... 35
Figura 19 - Estereótipo <<Aspect>> para classe (STEIN, 2002)....................................... 37
Figura 20 - Modelagem do banco orientada a aspectos ...................................................... 41
Figura 21- Notação para implementação do corpo do advice around ................................. 42
iv
Lista de Tabelas
Tabela 1: PCDs baseados no tipo do join point (JP) .......................................................... 12
Tabela 2: PCDs baseados na propriedade do join point (JP).............................................. 13
Tabela 3: Valores para instâncias do aspecto ..................................................................... 36
v
Lista de Abreviaturas
AODM
Aspect–Oriented Design Model
AOP
Aspect–Oriented Programming
UML
Unified Modeling Language
vi
RESUMO
Este trabalho traz uma discussão sobre programação orientada a aspectos, mais
especificamente sobre a linguagem de programação AspectJ e como os benefícios trazidos
por esta abordagem podem favorecer não só a fase de implementação, mas também a
modelagem de um sistema de software. Então, uma análise sobre a Modelagem Orientada a
Aspectos – AODM, baseada em UML e AspectJ, será apresentada.
Palavras chave: Modelagem orientada a aspectos, AspectJ, UML
vii
ABSTRACT
This work brings a discussion about aspect oriented programming, more specifically
about the AspectJ programming language and how the benefits introduced by this approach
may foment not only the implementation phase, but too the modeling phase of software
system. As soon, an analysis about Aspect-Oriented Design Model – AODM, based on
AspectJ and UML, will be presented.
Keywords: Aspect-Oriented Design Model, AspecJ and UML
1
1. INTRODUÇÃO
Para que os objetivos traçados para a construção de um sistema de software sejam
alcançados com eficácia, alguns critérios em relação à maneira como esse sistema será
representado (nas fases de projeto e implementação) devem ser considerados, como a
clareza na apresentação dos seus requisitos (tanto funcionais, como não-funcionais) e a
separação destes em componentes específicos na modelagem e no código.
Quando abordagens orientadas a objetos são utilizadas para o desenvolvimento de
sistemas complexos, nota-se que os seus interesses (requisitos funcionais e não-funcionais)
não são claramente separados em um nível adequado. Isso acontece porque existem
propriedades que não devem ser encapsuladas totalmente numa unidade funcional, como
uma classe, pois participam de várias dimensões do sistema (classes, objetos). Em
conseqüência dessa característica, essas propriedades são denominadas interesses
multidimensionais.
De fato, as aplicações atuais superam os limites das técnicas de programação
existentes. Por exemplo, há a necessidade crescente de que os softwares sejam construídos
de maneira cada vez mais modularizada, pois isso traz melhorias tanto no desenvolvimento,
como na manutenção desses softwares, possibilitando seu reuso posteriormente. No
entanto, utilizando as técnicas de programação existentes, não há um mecanismo de
abstração que suporte o encapsulamento completo de um interesse multidimensional.
2
Se não há uma separação adequada dos interesses comuns, ocorre o entrelaçamento
entre interesses distintos no sistema. Este entrelaçamento causa dificuldade no
desenvolvimento, na manutenção e no reuso de partes do código-fonte.
No decorrer deste trabalho será utilizado um domínio bancário como ilustração, para
que assim seja possível uma melhor assimilação dos conceitos nele abordados. Num
sistema bancário, cada vez que um cliente invocar o método para sacar um valor em sua
conta será necessário realizar algumas verificações quanto a segurança, persistência,
integridade ou atomicidade das informações que esse cliente forneceu. Em abordagens
orientadas a objetos, o código que implementa essas verificações fica intrínseco ao método,
quando poderia estar em modúlos separados para facilitar a coesão interna e diminuir o
acoplamento externo.
Para resolver isto, foi desenvolvida uma nova técnica de programação - a Programação
Orientada a Aspectos (Aspect-Oriented Programming - AOP), apresentando então o
conceito de aspectos (KISELEV, 2002). Os aspectos são unidades que concentram os
interesses multidimensionais.
Várias abordagens vêm sendo propostas para tratar os aspectos, entre elas a mais
disseminada é AspectJ, que permite uma maneira de implementar os interesses
multidimensionais em separado no sistema de software. AspectJ é uma extensão do Java e
provê algumas construções fundamentais que são: join points, pointcuts, advices,
introductions e aspects. Aspects, os elementos principais dessa abordagem, podem alterar a
estrutura estática ou dinâmica de um programa. A estrutura estática é alterada adicionando,
por meio de introductions, membros (atributos, métodos ou construtores) ao código-fonte
de uma classe, por exemplo. Já a alteração na estrutura dinâmica de um programa ocorre
em tempo de execução por meio dos join points, os quais são selecionados por pointcuts e
através da adição de comportamentos (advices) antes ou depois dos join points (KISELEV,
2002).
A ferramenta AspectJ é eficaz quando trata da implementação de interesses
multidimensionais. Em outras palavras, a fase de implementação é beneficiada pela
separação dos interesses que são distintos no sistema. No entanto, é necessário que desde a
fase de projeto a separação desses interesses seja clara e bem representada. Uma
dificuldade encontrada é que as linguagens de modelagem atuais não provêm recursos para
3
isso. Então, uma nova abordagem foi proposta por STEIN (2002), baseada em AspectJ e
UML – a Modelagem Orientada a Aspectos (Aspect-Oriented Design Model – AODM). Ela
estende a UML (Unified Modeling Language) com recursos capazes de representar os
efeitos causados por interesses multidimensionais.
A UML é baseada em conceitos orientados a objetos e amplamente utilizada para o
desenvolvimento de sistemas complexos. Um fator importante, que justifica seu uso para
esta modelagem orientada a aspectos, é a possibilidade de extensão que a UML oferece
através de um sub-pacote chamado “Extension Mechanisms” que traz os elementos:
taggeds values, restrições e estereótipos. A proposta de STEIN (2002) utiliza os
mecanismos de extensão “de forma a contemplar os conceitos desse paradigma conforme
encontrados em AspectJ” (CHAVES, 2002). Cada construção encontrada no AspectJ (join
points, pointcuts, advices, introductions e aspects) é, portanto, mapeada para a UML.
1.1
Objetivos do trabalho
Este trabalho é apresentado como requisito parcial da disciplina Prática de Sistemas
de Informação I (Estágio) do curso de Sistemas de Informação, orientado pela Profª.
Cristina D’ornellas Filipakis e objetiva principalmente uma análise crítica da Modelagem
Orientada a Aspectos proposta por (STEIN, 2002). Posto que essa abordagem é baseada em
AspectJ e UML, são objetivos específicos trazer:
•
um estudo preliminar das principais construções do AspectJ; e
•
um estudo dos principais elementos do meta-modelo UML, utilizados na
modelagem orientada a aspectos.
1.2
Organização do trabalho
Este trabalho é organizado em seis capítulos. O próximo capítulo traz uma revisão de
literatura, buscando um embasamento teórico. No capítulo três são descritos os materiais e
métodos utilizados para o desenvolvimento deste trabalho. Os resultados e discussões
alcançados através do estudo da modelagem orientada a aspectos são descritos no capítulo
4
quatro. O capítulo cinco traz as conclusões e trabalhos futuros e por fim, no capítulo seis,
são listadas as referências bibliográficas consultadas.
5
2. REVISÃO DE LITERATURA
No decorrer desta seção serão descritos os resultados dos estudos realizados acerca da
revisão bibliográfica sobre as abordagens orientadas a objetos, a aspectos e sobre UML e
AODM.
2.1
Abordagens Orientadas a Objetos
A complexidade da programação está, em sua grande parte, no alto grau de
acoplamento e na fraca coesão interna com a qual um software é construído. O
acoplamento refere-se à dependência, que decorre da necessidade de uma comunicação de
informações, entre os objetos de um sistema. A coesão refere-se ao grau de qualidade com
que um conjunto de códigos se encaixam (LEE et. Al, 2001). Um alto acoplamento e fraca
coesão resultam um sistema difícil de gerenciar, porque os interesses do sistema não são
bem modularizados e isso acarreta um código-fonte confuso. Assim, mecanismos de
abstrações são utilizados para tentar diminuir essa complexidade.
A programação orientada a objetos traz como principal abstração o objeto. Um objeto
é uma representação de uma entidade formada por atributos e métodos. Os métodos
expressam ações sobre os atributos, ou seja, irão atuar sobre eles. O acesso aos atributos
não é realizado diretamente pelos usuários do objeto. Em vez disso, são os métodos desse
objeto que acessam seus atributos. Isso caracteriza um princípio importante da orientação a
objetos – o encapsulamento.
Outro princípio importante da orientação a objetos é a herança, que permite expressar
elementos comuns entre as classes. Assim, uma classe que é similar a outra já antes
6
implementada pode ser facilmente definida através do reuso de partes semelhantes do
código. Este mecanismo representa a generalização e especialização. A Figura abaixo
demonstra um exemplo prático disso. O domínio apresentado é o de um sistema bancário,
onde a classe usuario, uma generalização, possui as especializações funcionario e
cliente.
Uma especialização pode ter novos atributos e métodos incluídos ou, ainda,
estender os métodos herdados.
Figura 1 - Exemplo de herança entre os objetos
Essas características relacionadas acima trouxeram grande evolução na forma de
implementar sistemas e, atualmente, a orientação a objetos é uma técnica bastante aceita e
amplamente utilizada por desenvolvedores. Esta evolução se deu porque a implementação
ficou mais “limpa”, já que atributos e métodos são encapsulados numa mesma unidade
funcional, o objeto, e este é agrupado num domínio comum, a classe. Como conseqüência
disso, melhorias foram notadas também quanto à manutenção e reuso de partes do código
do sistema implementado.
Entretanto, existem propriedades que não se enquadram em componentes da
decomposição funcional, tais como: tratamento de exceções, restrições de tempo real,
distribuição e controle de concorrência. Elas, normalmente, estão espalhadas em diversos
componentes do sistema, afetando a performance ou a semântica da aplicação (PIVETA,
7
2001). Estas propriedades, de forma geral, estão relacionadas a sistemas muito complexos e
mesmo com o uso de elementos da engenharia de software ou padrões de projeto,
continuam espalhadas pelo sistema, ocasionando um fenômeno chamado código
entrelaçado. Assim, quando houver a necessidade de mudança em algumas dessas
propriedades, será necessário alterar todas as partes que são atingidas por elas. Isso
acarreta:
•
a repetição desnecessária de código;
•
a diminuição da legibilidade do código;
•
a diminuição da capacidade de reuso do código.
A Figura 2 representa bem esta característica.
Figura 2 - Representação de um código entrelaçado (KICZALES, 2001)
As barras representam as classes e as linhas vermelhas os interesses
multidimensionais.
Para tanto, um novo mecanismo de abstração foi desenvolvido, o aspecto. A
abordagem orientada a aspectos é o tema das próximas seções.
2.2
Abordagens Orientadas a Aspectos
8
A orientação a aspectos é uma proposta de solução para os problemas causados pela
ineficiência dos atuais paradigmas de programação em prover a modularização adequada
dos interesses multidimensionais no desenvolvimento de software. Ela propõe uma
separação clara dos interesses multidimensionais num sistema, de forma a evitar o
entrelaçamento de interesses distintos. E por meio de um combinador (weaving), possibilita
recompor tais interesses, resultando num sistema de software com interesses bem
modularizados.
A finalidade da AOP não é substituir as técnicas orientadas a objetos, mas
complementá-las para possibilitar a separação dos interesses multidimensionais em uma
unidade - o aspecto. O aspecto permite que mudanças, quando necessárias, sejam definidas
no código-fonte de um sistema de forma menos invasiva (seja em sua estrutura ou em seu
comportamento). Assim, é possível alcançar a modularização, beneficiando tanto o
desenvolvimento como a manutenção de um sistema. A seguir a Figura 3 traz essa
representação.
Figura 3 - Representação de um interesse multidimensional concentrado num aspecto (KICZALES, 2001)
Uma implementação básica em AOP compreende (PIVETA, 2001):
•
uma linguagem de componentes para a programação de componentes;
•
uma ou mais linguagens de aspectos para a programação de aspectos;
9
•
um combinador de aspectos (aspect weaver) para a combinação das
linguagens;
•
um programa escrito na linguagem de componentes; e
•
um ou mais programas escritos na linguagem de aspectos.
Os requisitos funcionais, normalmente, são organizados em um conjunto de
componentes expresso por uma linguagem de programação orientada a objetos e os
requisitos não–funcionais (ou interesses multidimensionais) são organizados em aspectos
(KISELEV, 2002).
KICZALES (1997) separa os interesses de um sistema em componentes e aspectos:
•
Componentes são elementos que podem ser encapsulados de forma clara em
uma unidade de função. Procedimentos, métodos, objetos, classes ou APIs
são exemplos dessas unidades. No contexto do sistema bancário, tem-se:
sacar, ver saldo, ver extrato e transferir como ilustração.
•
Aspectos são propriedades que afetam a performance ou semântica dos
componentes. Tratamento de exceções, consistência de dados, segurança são
citados como exemplos de aspectos.
Por meio da separação dos interesses em componentes e aspectos, a AOP permite
uma modularização na construção do sistema de software. Como conseqüência desta
modularização torna-se mais fácil escrever, compreender, reutilizar e manter um sistema,
porque seu código torna-se mais limpo e simples.
2.2.1 AspectJ
Várias abordagens vêm sendo propostas para implementar aspectos, dentre elas
pode-se destacar HyperJ, programação orientada a assuntos (SOP), AspectC e AspectJ.
Neste trabalho, o enfoque será para AspectJ, já que o objetivo é o estudo da modelagem
orientada a aspectos (STEIN, 2002) que é baseada em AspectJ e UML. Esta seção traz os
conceitos principais desta abordagem.
10
AspectJ (AspectJ, 2004) é uma ferramenta bem aceita por estender a linguagem de
programação Java com construções eficientes para a implementação de interesses
multidimensionais em separado num sistema de software e por ser de uso geral, por meio
dela, pode-se definir a implementação de aspectos em vários pontos de um programa. Esta
é uma proposta do Palo Alto Research Center, tradicional centro de pesquisas da Xerox.
Em AspectJ, Java é a linguagem de componentes utilizada, a linguagem de aspectos é
genérica, possibilitando ao desenvolvedor especificar instruções nos seguintes pontos de
combinação:
•
execução de métodos;
•
recebimento de chamadas a construtores;
•
execução de construtores;
•
acesso a campos; e
•
execução de manipuladores de exceção.
A Figura 4 apresenta a estrutura do AspectJ, na qual as classes são implementadas
na sintaxe da linguagem Java e os aspectos na sintaxe da linguagem AspectJ, ambos são
combinados através do weaver e, então, um novo programa é resultado para proceder, em
seguida, a sua execução.
Programa
Componentes
Weaver
Aspectos
Figura 4 - Representação da estrutura do AspectJ
A função do weaver (combinador de aspectos) é identificar nos componentes pontos
de junção onde os aspectos se aplicam, produzindo o código final da aplicação, que
11
implementa tanto as propriedades definidas pelos componentes como aquelas definidas
pelos aspectos. Combinadores podem atuar em tempo de compilação ou de execução.
Implementações de combinadores em tempo de execução têm a possibilidade interessante
de permitir a adição / exclusão de aspectos com a aplicação em pleno funcionamento
(CHAVES, 2002).
Os elementos básicos em AspectJ são: join points, pointcuts, advices, introductions
e aspects. A seguir, seus conceitos serão estudados e exemplificados por meio da ilustração
de um aspecto que, num domínio bancário, calcula a CPMF sempre que os métodos
sacar() e transferir()
forem executados na classe conta.
2.2.1.1 Join points
Os join points são os pontos na execução de um programa de componentes nos
quais os aspectos serão aplicados. São conceitos abstratos em AspectJ, pois não possuem
nenhuma construção de programa para representá-lo.
Conforme mostra a Figura 5, o modelo de join points do AspectJ é baseado em um
grafo dirigido de envio de mensagens a objetos. Os nós seriam os pontos onde as classes e
objetos recebem uma invocação de método ou têm um atributo acessado. Os vértices
representariam as relações de fluxo de controle entre os nós, partindo do que chama para o
que é chamado. O fluxo de controle, na realidade, ocorre nos dois sentidos: no sentido do
vértice, quando a ação é iniciada, e no sentido contrário, quando a ação realizada pelo subnó estiver concluída (STEIN, 2002).
Isto significa que um join point pode estar em uma das direções do fluxo de
controle, ou seja, quando uma ação é iniciada e quando uma ação é terminada.
12
O método é
chamado e
retorna ou traz
uma exceção
O método é
chamado e
retorna ou traz
uma exceção
O método
executa e
retorna ou traz
uma exceção
Figura 5 - Fluxo de controle em AspectJ (KICZALES, 2001)
2.2.1.2 Pointcuts
Os pointcuts são responsáveis por selecionar join points, ou seja, eles detectam em
quais join points o aspecto deve interceptar. Um pointcut é nomeado através de
designadores (Pointcut designator - PCD), que podem ser primitivos ou derivados (os
programadores podem criar novos tipos a partir dos existentes). Um designador de pointcut
primitivo abrange o tipo, a propriedade e a combinação dos join points. As tabelas abaixo
mostram os designadores primitivos principais suportados pelo AspectJ (CHAVES, 2002).
Tabela 1: PCDs baseados no tipo do join point (JP)
PCD
Pontos de junção selecionados
Call(<ass. De método>)
Quando o método é chamado
execution(<ass. De método>)
Quando o método é executado
get(<ass. De atributo>)
Quando o atributo é acessado
set(<ass. De atributo>)
Quando o atributo é alterado
Handler(<tipo exceção>)
Quando a exceção é tratada
Initialization(<ass.construtor>)
Quando o construtor é executado
StaticInitialization(<tipo>)
Quando a inicialização de classe é executada
13
Tabela 2: PCDs baseados na propriedade do join point (JP)
PCD
Pontos de junção selecionados
Within(Tipo)
Qualquer JP que ocorra na classe
Withincode(Método)
Qualquer JP que ocorra no método/construtor
Cflow(Pointcut)
Qualquer JP que ocorra no contexto de um JP
selecionado pelo PCD
Idem ao anterior, excluindo os JPs selecionados pelo
Cflowbelow(Pointcut)
próprio PCD
this(Tipo)
Qualquer JP que ocorra em um objeto da classe
Target(Tipo)
Quando o objeto alvo do call/get/set é da classe
args(Tipo, ...)
Quando os argumentos são do tipo especificado
If(ExpressãoLógica)
Quando a expressão é verdadeira
Os pointcuts suportam os símbolos *,+,.., . para a especificação de um join point.
Assim:
execution(* sacar(..))
seleciona os join points onde o método sacar, independentemente do tipo, e de zero ou mais
argumentos, seja executado. Um pointcut é definido da seguinte forma:
Pointcut <Nome> (Argumentos): <corpo>;
Um pointcut pode ser aninhado em outro pointcut com os operadores e, ou e não
(&&, ||, e !).
2.2.1.3 Advices
Os pointcuts apenas selecionam os join points. Para implementar realmente os
comportamentos multidimensionais é usado o advice, que é um trecho de código que
executa a cada join point descrito no pointcut. Existem três formas de advice, o before,
around
e after. Como seus nomes sugerem, before executa antes do join point, around
executa antes e após e after executa após.
Um advice é definido da seguinte forma:
14
TipoAdvice([ListaParâmetros]) : Pointcut {<Corpo>}
Os advices around substituem o comportamento original do ponto de junção. Para
isso, a linguagem oferece o comando proceed(), o qual permite que o comportamento
original seja substituído e, ainda, que comportamentos adicionais sejam realizados antes e
após o comportamento original do join point selecionado (CHAVES, 2002).
2.2.1.4 Introductions
O AspectJ provê uma maneira de alterar a estrutura estática de uma aplicação, isto
ocorre por meio das declarações inter-types que são descritas como interesses estáticos
(static crosscutting). Estas declarações provêm uma construção chamada introduction.
Os introductions modificam uma classe estruturalmente, acrescentando a ela novos
membros, como construtores, métodos e campos por meio da cláusula declare parents.
Assim como advices irão atuar em pontos específicos do programa denotados por pointcuts,
introductions irão atuar sobre um conjunto de definições de classes (STEIN, 2002).
2.2.1.5 Aspects
Aspects encapsulam pointcuts, advices e introductions em uma unidade modular de
implementação. São definidos de maneira semelhante às classes, enquanto estas
encapsulam o código que encaixa dentro de classes hierárquicas, aspects encapsulam o
código que é ortogonal a essas classes hierárquicas. Embora o comportamento especificado
pelos advices e introductions declarados modifiquem o sistema ortogonalmente, eles
sempre são localizados no código-fonte dos aspectos.
Abaixo, na Figura 6, segue como deve ser a estrutura da sintaxe de um aspecto. Os
pontos em negrito na classe base ilustrada na Figura 7 representam os join points e o advice
designado neste exemplo é o around. Portanto, o código que implementa os
comportamentos multidimensionais irá atuar antes e após esses pontos. Para isso, é
utilizado o domínio bancário, no qual a cada vez que o método sacar e tranferir for
15
executado deve-se cobrar a CPMF. Esta cobrança é implementada no aspecto.
1
Public aspect CPMF{
2
pointcut creditos(Conta c,double valor):
3
(
4
(execution(* sacar(..)) && args(valor)) ||
5
(execution(* transferir(*,double)) && args(*,valor))
6
) && target(c)
7
;
8
void around (Conta c, double valor):creditos(c, valor){
9
System.out.println("Valor retirado: "+valor);
10
double CPMF = valor - valor*(1-0.0037);
11
proceed(c,valor);
12
c.setSaldo(c.getSaldo()-CPMF);
13
System.out.println("Valor retirado: "+valor);
14
System.out.println("CPMF: "+CPMF);
15
16
}
}
Figura 6 - Aspecto CPMF que atua sobre as transações de saque e transferência da classe Conta
1
Public class Conta{
2
Double saldo;
3
Public void setSaldo(double aSaldo){
4
saldo = aSaldo;
5
}
6
Public double getSaldo(){
7
return saldo;
8
}
9
Public void sacar(double valor){
10
setSaldo(getSaldo()-valor);
11
}
12
Public void transferir(Conta destino, double valor){
13
setSaldo(getSaldo()-valor);
14
destino.setSaldo(destino.getSaldo()+valor);
15
16
}
}
Figura 7 - Classe Conta
16
A classe ilustrada na Figura 8 é utilizada para testar o aspecto CPMF.
1
public class Teste{
2
public static void main(String args[]){
3
Conta c = new Conta();
4
c.setSaldo(500);
5
System.out.println("Saldo Atual:"+c.getSaldo());
6
c.sacar(200);
7
System.out.println("Saldo Atual:"+c.getSaldo());
8
c.transferir(new Conta(),200);
9
System.out.println("Saldo Atual:"+c.getSaldo());
10
11
}
}
Figura 8 - Classe Teste
Abaixo, na Figura 9, é apresentado o resultado da compilação e execução do aspecto
CPMF
e das classes Conta e Teste. Para compilar este exemplo, foi utilizado o comando
ajc, (que se refere ao compilador do AspectJ) e logo após, para executar a classe Teste o
comando java foi utilizado.
Figura 9 - Resultado da compilação e execução do exemplo Banco
17
2.3
A Importância da Modelagem
A modelagem traz consigo uma notável contribuição para tornar viável e fácil o
entendimento de eventos do mundo real em todas as suas áreas. Isto acontece porque ela
apresenta uma abstração de um problema a ser tratado, ou seja, especifica um foco do
problema e deixa de lado aspectos irrelevantes para determinada situação. Desta forma,
possibilita que detalhes antes ignorados possam ser vistos e solucionados com mais
minuciosidade e cuidado.
Em sistemas computacionais, torna-se mais visível a necessidade do uso da
modelagem à medida que os sistemas de software se mostram mais complexos. Contudo,
nada impede que em sistemas de softwares mais triviais o uso da modelagem seja realizado.
Vários recursos são utilizados para o desenvolvimento de um software (pessoas,
ferramentas, dinheiro). Sistemas de software complexos apresentam uma maior quantidade
de recursos envolvidos e isso traz uma conseqüênte necessidade de prover melhor a
comunicação entre as partes que o desenvolvem.
O êxito para o desenvolvimento de um sistema de software está, em grande parte, na
contribuição que a modelagem traz, pois ela garante uma comunicação unificada entre os
desenvolvedores e evita discrepâncias de informações ou ambigüidades. A modelagem é
uma técnica da engenharia, mas não está restrita apenas a ela. É possível avaliar sistemas
por meio dos resultados estatísticos da simulação de modelos, pois são “a simplificação da
realidade” (BOOCH et Al, 2000).
Uma modelagem apresentará bons resultados se alguns princípios forem seguidos.
Esses princípios são listados abaixo (BOOCH et Al, 2000):
•
a escolha dos modelos a serem criados influencia sobre a maneira como um
determinado problema será atacado e como uma solução é definida;
•
cada modelo poderá ser expresso em diferentes níveis de precisão;
•
os melhores modelos estão relacionados à realidade; e
•
nenhum modelo único é suficiente. Qualquer sistema não-trivial será melhor
investigado por meio de um pequeno conjunto de modelos quase
independentes.
18
A forma como os modelos são escolhidos, ou seja, qual realidade irão representar e
em que nível de abstração irão corresponder a essa realidade, bem como a quantidade de
modelos necessária são fatores que devem ser definidos cautelosamente, para que se
aproximem ao máximo do mundo real e então se alcancem soluções eficientes e previstas
para os problemas do domínio do sistema a ser implementado.
A próxima seção traz um estudo sobre a arquitetura UML, abordando seus
principais conceitos, vistos em seu meta-modelo, que serão estendidos para a AODM.
2.3.1 UML
A linguagem de modelagem UML (Unified Modeling Language) traz em sua
especificação recursos capazes de projetar sistemas de software de maneira estruturada e
padronizada.
Estes recursos são eficientes para modelar cada fase do ciclo de vida do software,
que compreende as fases de análise, projeto, implementação e manutenção. A UML é
baseada em técnicas orientadas a objetos e destina-se à visualização, especificação,
construção e documentação dos artefatos de um sistema de software (BOOCH et Al, 2000).
Modelos representados graficamente tornam mais dinâmica a visão e a compreensão
sobre um determinado domínio, mesmo por parte de outro desenvolvedor ou ferramenta.
Modelos específicos são mais restritos e, por consegüinte, mais precisos. Isso ameniza a
probabilidade de ambigüidades num projeto.
Os modelos da linguagem UML podem ser ligados a várias linguagens de
programação (Java, C++, Smalltalk), logo, a partir de um modelo UML pode-se gerar um
código numa linguagem de programação. O processo inverso também acontece, ou seja, é
possível reconstruir um modelo a partir de sua implementação. Quanto à documentação, a
UML aborda os requisitos, a arquitetura do sistema e as atividades de testes (BOOCH et Al,
2000).
A UML, em seu meta-modelo, apresenta os blocos de construção básicos. Estes
blocos são abstrações, relacionamentos e diagramas. Abstrações representam aspectos
estruturais e comportamentais de um sistema, relacionamentos declaram como essas
19
abstrações se relacionam e diagramas apresentam um resumo do conjunto de abstrações e
seus relacionamentos (STEIN, 2002).
A Figura 10 representa os pacotes Foundation e Behavioral Elements da arquitetura
UML. O primeiro provê os blocos de construção estrutural, já o segundo traz os recursos
necessários para modelar comportamentos dinâmicos.
Figura 10 - Representação dos pacotes Behavioral Elements, Model Management e Foundation da
especificação UML (OMG, 2000)
2.3.1.1 Blocos de construção estrutural
Os blocos de construção estrutural são definidos no pacote Foundation da
arquitetura UML. Este pacote é dividido em três sub-pacotes que são Core, Data Types,
Extension Mechanisms (STEIN, 2002). Os próximos parágrafos trazem um esboço sobre
esses sub-pacotes.
2.3.1.1.1
Core
20
O pacote Core abrange os conceitos necessários para descrever a estrutura estática
dos modelos. Isto é feito por meio dos classificadores e relacionamentos. Classificadores
são os elementos modelos que trazem as características estruturais e/ou comportamentais,
tais como atributos e métodos. Classes e interfaces são exemplos de elementos modelos
(STEIN, 2002).
Os elementos modelos são ligados por relacionamentos, como associações,
generalizações e dependências. Abaixo seguem as definições elementares para estes
relacionamentos, segundo (BOOCH et Al, 2000), a Figura 11 traz uma exemplificação
destes conceitos.
Associações definem relacionamentos semânticos entre dois ou mais elementos
modelos. Um tipo especial de associação é a agregação, ela define um elemento modelo
como sendo parte de outro. Em outras palavras, um relacionamento entre todos e partes
(este trabalho é constituído por capítulos e seções, por exemplo). Cada associação pode
especificar um conjunto de meta-propriedades como visibilidade e multiplicidade.
Graficamente uma associação é representada como uma linha que, normalmente, contém o
nome dos papéis e multiplicidades que representa.
Generalizações são relacionamentos de herança entre um elemento mais geral e um
mais específico. Graficamente a generalização é representada por uma linha com uma seta
apontando para o elemento mais geral.
Dependências são relacionamentos semânticos entre dois elementos modelos que
permitem que uma alteração no elemento modelo independente possa afetar a semântica do
elemento modelo dependente. Graficamente, uma dependência é representada por linhas
tracejadas, possivelmente com setas.
Elementos modelos especificados no pacote Core UML são, de forma geral,
visualizados em diagramas de classes, pois eles mostram um conjunto de classes,
interfaces, colaborações e seus relacionamentos.
21
Figura 11- Diagrama de Classes para o domínio Bancário
O diagrama de classes representado acima modela um domínio bancário e traz as
classes Banco, Usuario com as classes especializadas Funcionario e Cliente, Conta com
as classes especializadas Poupanca e Corrente, CaixaRapido com a classe especializada
ContaUniversitaria.
Estas especializações são ligadas às suas classes superiores pelo
relacionamento de generalização. Para a classe ContaUniversitaria existe uma restrição
(ser universitário), ela é representada por uma nota ligada a esta classe.
2.3.1.1.2
Data Types
O pacote Data Types especifica os diferentes tipos de dados que são usados para
definir a UML, e são usados para designar os tipos que serão aceitos para os atributos das
classes, por exemplo (a nível do meta-modelo UML e não de usuário).
22
2.3.1.1.3
Extension Mechanisms
O paco te Extension Mechanisms possibilita estender os blocos de construção
existentes em UML, com novas meta-propriedades e novas semânticas. Isto é realizado por
meio de taggeds values e restrições. Os taggeds values são usados para atribuir uma
informação qualquer a um elemento modelo. Esta informação pode ser quanto à gerência,
geração de código ou semântica adicional requerida por um determinado estereótipo. Com
restrições, novas semânticas podem ser especificadas para um elemento modelo, ou seja, a
criação de uma regra ou alteração de uma existente. A UML pode ser estendida com novos
blocos de construção que são derivados de outros existentes, aos novos blocos dá-se o
nome de estereótipos (STEIN, 2002).
Taggeds values e restrições são representados entre chaves {} (por exemplo:
{tag=valor} e {restrição}). Estereótipos são representados entre os símbolos << >> (por
exemplo: <<aspect>>).
A Figura 12 ilustra um exemplo prático do uso desses mecanismos de extensão. Um
novo estereótipo para uma classe, chamado <<aspect>>, é criado. Este estereótipo requer
novas propriedades, assim taggeds values são utilizadas para conter essas propriedades
(instantiation, base, privileged). Estereótipos para operações também são criados, estes são
denominados pointcut e advice.
<<aspect>>
CPMF
{instantiation=perJVM}
{base=undefined}
{privileged=false}
- Attributos
- Operações
<<pointcut>>
pointcut creditos(Conta c,
double valor)
<<advice>>
around (Conta c,double valorlor)
Figura 12 - Exemplo de um estereótipo contendo tagged values
23
2.3.1.2 Blocos de construção comportamental
Os pacotes Behavioral Elements trazem os recursos necessários para modelar
comportamentos dinâmicos em UML. Este pacote é dividido nos sub-pacotes Common
Behavior, Collaborations, Use Case, State Machines e Activity Graphs (STEIN, 2002).
Somente os dois primeiros serão relatados nesse trabalho, visto que apenas estes serão
tratados no estudo da modelagem orientada a aspectos – AODM.
2.3.1.2.1
Common Behavior
Este pacote tem por finalidade dar suporte à parte comportamental de um projeto,
sendo assim, ele trata basicamente do elemento ação. Em UML, uma ação é “uma
especificação abstrata de uma instrução executável” (STEIN, 2002).
Criação e destruição de um objeto, chamada de operações, acesso a atributos, são
exemplos de ações que a UML suporta. No meta-modelo UML, estas ações são realizadas
por um elemento chamado stimuli, que é responsável por concretizar uma comunicação
entre duas instâncias. Em UML a comunicação entre duas instâncias só acontece se as
instâncias são ligadas por um link. Um link é uma instância de uma associação em tempo de
execução.
2.3.1.2.2
Collaborations
O pacote Collaborations descreve os conceitos necessários para expressar como
diferentes elementos modelos interagem uns com os outros para executar uma tarefa. Então,
este pacote define as características e relacionamentos que instâncias de elementos modelos
participantes na colaboração devem ter para completar com sucesso uma tarefa (STEIN,
2002).
Uma colaboração define uma interação especificando os detalhes de comunicação
entre as instâncias participantes para executar uma tarefa. Em interações, comunicações são
24
especificadas por meio de mensagens para definir as instâncias (remetente e destinatário)
(STEIN, 2002).
Em UML, colaborações são especificadas por diagramas de seqüência e diagramas
de colaborações. Abaixo seguem alguns conceitos fundamentais, segundo (BOOCH et Al,
2000).
Diagramas de seqüência apresentam uma ordenação clara das comunicações
realizadas dentro de uma colaboração. Como pode-se observar na Figura 13, um diagrama
de seqüência é representado graficamente colocando-se os objetos que participam da
interação no eixo X e as mensagens no eixo Y de uma tabela. Duas características especiais
nestes diagramas são o uso da representação de linhas de vida e a existência do fluxo de
controle. A linha de vida de um objeto é uma linha tracejada na vertical que define a
existência de um objeto num período de tempo. O foco de controle é um retângulo, sobre a
linha de vida, que define o período que um objeto desempenha uma ação.
Enquanto diagramas de seqüência enfatizam a ordem cronológica de interações de
uma colaboração, diagramas de colaboração enfatizam o contexto estrutural dessas
interações, o foco principal do diagrama de colaboração é a organização dos objetos que
participam de uma interação. Contudo, neste trabalho, os diagramas de colaração não serão
tratados detalhadamente, pois na modelagem orientada a aspectos proposta por (STEIN,
2002) eles não foram realmente utilizados para representar as construções de programa do
AspectJ.
25
Figura 13 - Diagrama de Seqüência para o domínio Bancário
Esse diagrama de seqüência especifica as etapas para o caso de uso sacar. Assim,
inicialmente, o controle solicita os dados do cartão à fronteira do sistema, que por sua vez,
solicita ao cliente que passe o cartão. O cliente passa o cartão e os dados são enviados ao
controle que faz a validação sobre estes dados. Para realizar isso, os dados do cliente são
transmitidos para a fronteira do banco, que os envia para o sistema central. O controle
26
solicita à fronteira do sistema a senha do usuário, então a fronteira do sistema solicita que o
usuário digite a senha.
O cliente digita a senha e envia a fronteira do sistema, esta envia a senha ao controle
para que ele faça a verificação. Se a senha for incorreta o usuário deverá redigitar (caso
digite a senha errada por três vezes, a conta será cancelada), senão deverá informar a
transação, se for um saque deverá informar também o valor a ser retirado à fronteira do
sistema.
Mais uma vez a fronteira do sistema envia estes dados ao controle, que irá verificar
o balanço, ou seja, se realmente o cliente tem saldo positivo para executar esta ação. Se a
resposta for falsa o cliente deverá digitar outro valor, se não, se for verdadeira o valor é
liberado.
Depois que os elementos básicos da arquitetura UML foram tratados, na próxima
seção será realizado um estudo sobre como esses elementos foram estendidos para
desenvolver a AODM. Os próximos paragráfos trazem conceitos principais e
representações de aspectos.
2.4
A Modelagem Orientada a Aspectos Baseada em AspectJ e UML
Para desenvolver a modelagem orientada a aspectos, (STEIN, 2002) analisou cada
construção de programa do AspectJ e as comparou com os elementos modelos existentes no
meta-modelo UML, de forma a verificar quais desses elementos modelos seriam mais
adequados para representar as construções do AspectJ. Com a ajuda dos recursos para
extensões que a UML provê (já vistos na seção 2.4.1.1.3), estereótipos adicionais e novas
semânticas foram trazidos à especificação UML. Desta forma, foi possível representar os
efeitos dos interesses multidimensionais sobre as classes que atravessam, por meio de uma
notação gráfica, em tempo de projeto.
Nesta seção, será mostrado um estudo sobre a representação UML para as
construções de AspectJ.
2.4.1 Representando construções do AspectJ em UML
27
2.4.1.1 Join points
Ainda que os join points não tenham uma construção de programa específica em
AspectJ, é interessante que na modelagem orientada a aspectos eles sejam representados
para denotar os pontos de atuação do código multidimensional. (STEIN, 2002) relata que o
modelo dos join points baseia-se em quatro principais tipos de ações nos quais os aspectos
podem atuar, que são:
•
criação de objetos;
•
invocação de métodos;
•
acesso a campos; e
•
tratamento de exceções.
Desta forma, ele buscou uma semelhança no meta-modelo UML e constatou que
UML percebe as ações de criação, invocação, atribuição e envio de um objeto. É necessário
lembrar que um join point pode afetar uma ação quando ela é iniciada e quando é
terminada, por isso é inviável que os join points sejam representados por estas ações
diretamente. Outro motivo que impossibilita isso é que uma ação, em UML, “representa
uma especificação estática em vez de uma execução dinâmica” (STEIN, 2002). É necessário
que o elemento modelo que represente um join point seja semelhante a um ponto distinto na
execução dinâmica de um programa, pois esta é a sua principal característica.
Logo, um elemento modelo proposto para essa representação foi um link, que é uma
instância de uma associação em tempo de execução (Links são especificados no pacote
Common Behavior da especificação UML, conforme descrito na seção anterior 2.3.1.2.1
“Common Behavior”). Ele é adequado para esta representação porque é usado para
transmitir uma comunicação entre duas instâncias e pode ser interpretado como vértice de
um grafo, no qual o fluxo de controle passa duas vezes: uma quando a comunicação é
enviada e outra depois que a comunicação é completada (STEIN, 2002).
Porém, nem sempre um link pode ser interpretado como um join point. Somente
quando é utilizado para concretizar a comunicação entre duas instâncias que englobam a
invocação de um método, a criação de um objeto ou o tratamento de uma exceção (estas
28
são as ações sobre as quais o modelo de join points se baseia). Quando um link é utilizado
para destruir uma instância, por exemplo, ele não representa um join point (STEIN, 2002).
Para visualizar estas comunicações, o elemento modelo mensagens é utilizado.
Mensagens são especificadas no pacote Collaborations do meta-modelo UML (como visto
na seção 2.4.1.2.2) e são representadas graficamente como setas no diagrama de interação.
Quando join points são modelados, percebe-se que alguns elementos do AspectJ não
possuem representação direta no meta-modelo UML. De acordo com STEIN (2002), para
algumas das ações UML vários join points são definidos. Por exemplo, para ações de
criação de objetos o AspectJ define join points para chamada, execução e inicialização, e
para ações de invocação de métodos são definidos join points para chamada e execução.
Isto ocorre porque, em AspectJ, essas ações precisam ser distintas para permitir maior
exatidão em relação à designação dos interesses multidimensionais.
A UML não diferencia a inicialização e a execução atual de uma ação. Na realidade
ela trata a execução de construtores/métodos e inicialização de classes/objetos por meio de
ações uninterpretadas. Ações uninterpretadas são elementos modelos da especificação
UML que servem para “tratar ações que não correspondem a chamadas e envios de
mensagem, e nem são facilmente categorizadas em outros tipos de ações” (OMG, 2000).
Assim, os estereótipos <<Initialize>> e <<Execute>> foram definidos para
possibilitar que a execução de construtores/métodos e inicialização de classes/objetos sejam
representados distintamente em UML, ou seja, sem ser de forma uninterpretada; dessa
forma podem-se definir os pontos de atuação dos aspectos.
Em UML, ações de acesso a campo não utilizam nenhum link para representar um
join point, isso porque tais ações não representam uma comunicação entre instâncias. Para
representar esses join points os desenvolvedores devem definir operações especiais para
cada atributo da classe, estas operações são set e get. Assim, em vez de uma ação de
acesso, uma ação de chamada é usada para acessar o campo; para diferenciar essa ação de
chamada das demais elas são classificadas nos estereótipos <<set>> e <<get>>. Assim,
obtém-se um link utilizado para esta ação que pode ser identificado como um join point
(STEIN, 2002).
29
2.4.1.2 Pointcuts
Um poincut é responsável por selecionar os join points, ou seja, os pontos de
atuação de um código multidimensional, que, como já visto anteriormente, são
implementados no corpo do advice. Ao se modelar um pointcut, essas informações não
devem ser relevadas. Como STEIN (2002) declara, um pointcut é tanto um membro de um
aspecto, como uma instrução para o processo weaving, pois mostra a esse processo em que
pontos o advice irá executar seu código multidimensional. Sendo assim, um pointcut deve
ser representado preservando essas duas características.
A Figura 14 representa a estrutura de um pointcut, que é dividida em duas partes: a
primeira é a assinatura do pointcut, que contém o nome e a lista de parâmetros e a segunda
é a sua declaração, formada pelos pointcut designators que podem estar concatenados por
meio dos operadores booleanos (&&, ||, e !).
Pointcut creditos(Conta c,double valor):
Assinatura
((execution(*sacar(..))&&target(c);
Declaração pointcut
Figura 14 - Estrutura de um pointcut nomeado
Representar um pointcut no sentido de um membro de um aspecto é relativamente
simples. Ele é denotado como uma operação de um aspecto, devido a sua semelhança
estrutural com relação às operações padrões da especificação UML. Para isso, um novo
estereótipo para operações é apresentado ao meta-modelo UML chamado <<pointcut>>.
Para representar um pointcut no sentido de uma instrução para o processo weaving
(processo que combina os componentes e aspectos de um sistema), um novo meta-atributo
é definido por meio de taggeds values para conter essa instrução. Como visto
anteriormente, na seção 2.3.1.1.3, taggeds values podem ser usados para representar uma
informação tais como de gerência, geração de código ou semântica adicional que é
requerida por um determinado estereótipo.
Taggeds values são adequados para representar os pointcuts em sua função de
weaving através de duas formas (STEIN, 2002):
30
•
Quando taggeds values são utilizados para represesentar informações de
geração de código; e
•
Quando um estereótipo é definido para a meta-classe method da
especificação UML, que requer a presença de um particular tagged value.
(STEIN,
2002)
propõe
<<containsWeavingInstructions>>,
um
estereótipo
para
métodos
chamado
para conter os pontos de atuação dos aspectos, ou
seja, as instruções para o processo weaving. Para tanto faz-se necessário a definição de uma
meta-propriedade, que é chamada “base” que irá conter essas instruções.
Para definir esta meta-propriedade “base”, um novo tipo de dado deve ser
apresentado ao meta-modelo UML para poder reconhecer esses valores. Este tipo de dado é
chamado LinkSetExpression e irá conter uma instrução para avaliar um conjunto de join
points quando são atingidos.
A representação de pointcuts quanto a instruções weaving não é tão simples. Deve
ter o auxílio de uma ferramenta apropriada, que avalia a expressão contida no valor
etiquetado “base” e então marca cada join point definido por ela.(STEIN, 2002).
A Figura 15 abaixo, traz como esse estereótipo é representado no meta-modelo
UML.
31
Figura 15 - Estereótipo <<Pointcut>> para operação (STEIN, 2002)
Como mostra a Figura 15, é necessário observar que o estereótipo <<Pointcut>>
tem
algumas
restrições.
Ele
<<containsWeavingInstructions>>.
deve
ser
implementado
pelo
estereótipo
O meta-atributo “isQuery” deve ser “true”, isso
porque pointcuts por si mesmos não alteram o estado de um sistema. Seus parâmetros
devem ser do tipo“out”, visto que seus parâmetros não recebem nenhum parâmetro, ou seja,
nenhuma solicitação de serviço de um objeto externo. O meta-atributo “body” deve ser
vazio, porque não traz nenhuma implementação, apenas especifica um conjunto de join
points. Esses meta-atributos fazem parte da especificação de uma operação no metamodelo UML e estão presentes porque o pointcut é representado como um estereótipo de
uma operação.
2.4.1.3 Advices
Os advices trazem a implementação do código multidimensional e o executam de
três maneiras distintas devido ao fato de um join point poder ser atribuído quando uma ação
32
é iniciada e quando uma ação é terminada. Assim, sua execução pode acontecer antes, após
ou antes e após a ação (before, after e around, respectivamente).
Da mesma forma que os pointcuts, os advices também têm uma estrutura bastante
similar às operações padrões da especificação UML. A Figura 16 representa a estrutura de
um advice.
void around (Conta c, double valor):
creditos(c, valor){...}
Assinatura
Declaração Pointcut
Figura 16 - Estrutura de um advice
Devido a essa semelhança, na modelagem orientada a aspectos eles são
representados como estereótipos de operações, chamados <<advice>>, logo, são
representados como membros de um aspecto. Em sua declaração, um advice define os
pontos onde atuará, ou seja, traz uma definição dos pointcuts. Portanto, novamente o
estereótipo para métodos <<containsWeavingInstructions>> é utilizado. Ele tanto
representa a implementação de pointcuts como de advices.
A Figura 17 mostra como o estereótipo <<advice>> é representado no meta-modelo
UML.
33
Figura 17 - Estereótipo <<Advice>> para operação (STEIN, 2002)
Como mostra a Figura 17, é necessário observar que o estereótipo <<Advice>> tem
algumas
restrições.
Ele
deve
ser
<<containsWeavingInstructions>>.
implementado
pelo
método
do
estereótipo
Os meta-atributos “isRoot” e “isLeaf” devem ser
“true” e o meta-atributo “isAbstract” deve ser “false”, isso porque um advice não pode ser
abstrato e nem ser cancelado. Ele sempre traz um código a ser executado em algum ponto
da aplicação demarcado por um conjunto de join points. Esses meta-atributos fazem parte
da especificação de uma operação no meta-modelo UML e estão presentes porque o advice
é representado como um estereótipo de uma operação.
2.4.1.4 Introductions
Como visto na seção anterior 2.2.3.4, os introductions modificam uma classe
estruturalmente, acrescentando a ela novos membros, como construtores, métodos e
atributos. Eles são atribuídos a um conjunto de definição de classes, ao invés de join points,
como ocorre com advices. Para representar introductions na modelagem orientada a
aspectos, duas características devem ser observadas (STEIN, 2002):
34
•
Introductions são utilizados para representar a inserção de novas
características dentro dos elementos modelos;
•
Introductions podem atribuir novos relacionamentos aos elementos modelos.
Na modelagem proposta por (STEIN, 2002) – AODM, um estereótipo para
templates collaboration é incluído ao meta-modelo UML para representar introductions
chamado <<introduction>>.
Esse estereótipo requer a presença de um parâmetro somente, que deve ser o
estereótipo <<containsWeavingInstructions>>. Como já visto anteriormente, este
estereótipo requer uma meta-propriedade chamada “base”, no entanto, desta vez ela conterá
o conjunto de classes que serão atingidas pelo aspectos de forma a alterá-las
estruturalmente, ao invés do conjunto de join points. Assim, é necessário que um novo tipo
de dado seja acrescido ao meta-modelo UML, que é o ClassDefinitionSetExpression.
Este tipo permite definir o meta-atributo dos parâmetros templates do estereótipo
<<containsWeavingInstructions>>.
modelo UML:
A Figura 18 representa este estereótipo no meta-
35
Figura 18 - Estereótipo <<Introduction>> para operação (STEIN, 2002)
Uma restrição encontrada para <<Introduction>> é o fato dele suportar apenas um
parâmetro do estereótipo <<containsWeavingInstructions>>.
2.4.1.5 Aspects
Aspectos encapsulam os interesses multidimensionais que afetam estrutural ou
comportamentalmente uma classe, por meio dos pointcuts, advices e introductions.
Aspectos, em AspectJ, servem como containers para várias características, tais como
atributos, operações, pointcuts, advice e introductions, de forma semelhante às classes
especificadas em UML. Para possibilitar a representação de aspectos o estereótipo para
classes <<aspect>> é utilizado (STEIN, 2002).
Classes do estereótipo <<aspect>> são suplementadas com meta-atributos
adicionais para conter as meta-propriedades dos aspectos. Exemplos disso são a cláusula de
instanciação, a declaração pointcut contida nesta cláusula e ainda meta-atributos que
especificam o acesso a membros de classes bases. Para conter a cláusula de instanciação, o
valor etiquetado “instantiation” é definido e serve para armazenar a forma como os
aspectos serão instanciados. Para reconhecer esses valores um novo tipo de dado é criado,
36
chamado: InstantiationKind. Um valor etiquetado “instatiation” pode ter somente os
valores para instâncias apresentados na Tabela 3 (STEIN, 2002).
Tabela 3: Valores para instâncias do aspecto
PerJVM
A classe do estereótipo <<aspect>> é instanciada uma vez para o
ambiente global.
PerThis
A classe do estereótipo <<aspect>> é instanciada uma vez para cada
objeto que é executado nos join points selecionado.
PerTarget
A classe do estereótipo <<aspect>> é instanciada uma vez para cada
objeto que é marcado nos join points selecionados.
PerCFlow
A classe do estereótipo <<aspect>> é instanciada uma vez para cada
fluxo de controle que inicia os join points selecionados.
PerCFlowBelow A classe do estereótipo <<aspect>> é instanciada uma vez para cada
fluxo de controle que inicia abaixo dos join points selecionados.
Para especificar o privilégio de acesso aos membros das classes bases (qualquer
classe, mesmo privadas), o tagged value “privileged” é apresentado. Ele comporta os
valores booleanos true e false.
Abaixo, na Figura 19, segue-se a representação para o estereótipo aspect, no metamodelo UML.
37
Figura 19 - Estereótipo <<Aspect>> para classe (STEIN, 2002)
Como observado na Figura 19 cada valor etiquetado requerido pelo aspecto deve
conter o tipo específico. Para “instantiation” o tipo deve ser InstantiationKind, para o valor
“Base” o tipo deve ser LinkSetExpression, e para a tag “privileged” o tipo deve ser
booleano.
Este capítulo buscou tratar as técnicas para modelagem de sistemas de softwares,
partindo da orientação a objetos para a orientação a aspectos. Assim, as vantagens e
devantagens de cada uma dessas abordagens foram apresentadas. A próxima seção traz a
metodologia utilizada para o desenvolvimento deste trabalho.
38
3. MATERIAIS E MÉTODOS
Para este trabalho foram utilizados diversos recursos bibliográficos, de hardware e
software, que em conjunto às orientações permitiram o seu desenvolvimento.
3.1
Local e Período
Este trabalho foi desenvolvido durante o primeiro semestre de 2004, como parte da
disciplina “Prática em Sistemas de Informação I”. Os locais utilizados para sua elaboração
foram os laboratórios de informática do curso de Sistemas de Informação e o Núcleo de
Desenvolvimento de Software (NDS) do Centro Universitário Luterano de Palmas.
3.2
Materiais
Os recursos utilizados para o desenvolvimento do trabalho foram disponibilizados
pelo próprio curso Sistemas de Informação do CEULP/ULBRA em seus laboratórios, tais
como hardware e software licenciados. As demais ferramentas free foram adquiridas via
Internet.
39
3.2.1 Hardware
•
Pentium III, 750 Mhz e 128 Mb de RAM (Disponível no laboratório);
•
Pentium IV, 2.4 Ghz e 256 Mb de RAM (Disponível no laboratório);
3.2.2 Software
•
Microsoft Windows 2000 Professional;
•
Microsoft Office 2000 Professional;
•
Internet Explorer 6.0;
•
Acrobat Reader 6.0;
•
AspecJ;
•
Rational Rose;
3.2.3 Fontes Bibliográficas
3.3
•
Teses de Mestrados;
•
Publicações Científicas;
•
Artigos;
•
Site do AspectJ (AspecJ, 2004);
•
Sites diversos.
Metodologia
A metodologia utilizada foi baseada principalmente em pesquisas. Estas pesquisas
foram realizadas no sentido de juntar as informações referentes ao domínio do trabalho
desenvolvido, de maneira que permitisse oferecer uma sustentação teórica necessária para a
sua conclusão. Com base nestas informações colhidas, foi possível analisar, criticamente, a
abordagem proposta por (STEIN, 2002) e assim realizar um levantamento dos seus pontos
fortes e fracos.
40
4. RESULTADOS E DISCUSSÕES
Esta parte do trabalho apresenta um exemplo da utilização da Modelagem Orientada a
Aspectos (STEIN, 2002). O exemplo aborda um domínio bancário que já foi utilizado em
ilustrações anteriores. Na Figura 20 é representado o diagrama de classes que mostra este
domínio.
41
Figura 20 - Modelagem do banco orientada a aspectos
Na Figura 20 é representada uma notação para o aspecto CPMF, um estereótipo de
uma classe chamado <<aspect>> que contém os mecanismos para afetar a classe
caixaRapido.
Esse aspecto especifica que, sempre que o método sacar() for executado,
ele deverá ser interceptado, ou seja, o código do aspecto irá atuar sobre essa classe. Neste
aspecto, estereótipos especiais para operações são apresentados que são <<pointcut>> e
<<advice>>.
O <<pointcut>> estabelece o conjunto dos pontos aonde o aspecto deverá atuar.
Neste caso, ele declara que será sempre na execução do método sacar(). O <<advice>>
apresenta em sua declaração o seu tipo (before, after ou around) e a declaração pointcut.
A implementação deste advice around, que no diagrama de classe é representado por uma
interface ligada ao aspecto por um relacionamento realize, é representado em detalhes
através do diagrama de seqüência na Figura 21.
42
Figura 21- Notação para implementação do corpo do advice around
Neste diagrama de seqüência pode-se observar que a seqüência das ações é normal
até que o controle solicita à fronteira do sistema que informe qual transação o usuário
deseja realizar. Assim, essa informação é passada para o usuário. Caso sua resposta seja
efetuar um saque (sacar(double valor)), essa seqüência normal é interrompida por um
momento, até que o aspecto termine sua execução.
43
Visto que o advice utilizado neste domínio é um around, ele executa antes e após a
execução do método sacar(). Desta forma, quando o método sacar inicia sua execução ele
é interrompido e o around começa a executar, como descrito na seqüência deste diagrama,
atualizando o valor da CPMF. Por meio do comando proceed, o controle de execução
retorna ao método sacar() inicial da classe caixaRapido e assim a seqüência continua seu
fluxo normal. Então, é verificado o balanço; se o cliente possui saldo suficiente o dinheiro é
liberado, senão é informado a ele que solicite outro valor para o saque. Assim, quando essa
transação termina, o controle de execução retorna a execução para o advice, por meio do
comando proceed, que irá realizar a cobrança da CPMF na conta do cliente. Para
representar o relacionamento entre o aspecto e a classe que é afetada por ele, um novo
relacionamento é apresentado ao meta-modelo UML, chamado crosscut.
A seção seguinte traz algumas considerações sobre a Modelagem orientada a
aspectos.
44
4.1 Considerações sobre a abordagem de STEIN
A modelagem orientada a aspectos - AODM descreve uma notação para representar
os aspectos implementados em AspectJ por meio da UML. No entanto, nem todos os
elementos do AspectJ têm uma representação direta com os elementos modelos da
linguagem de modelagem UML. Com base nessa verificação, STEIN (2002) adotou os
mecanismos de extensão especificados no meta-modelo UML para estender os elementos
modelos existentes com novas semânticas, de forma que pudessem representar
graficamente os aspectos.
STEIN (2002) fez uma comparação minunciosa entre AspectJ e UML. Nesta
comparação constatou que links, na especificação UML, são adequados para representar os
pontos aonde os aspectos atuarão (join points do AspectJ). Tanto pointcuts e advices podem
ser representados como operações estereotipadas, devido à grande semelhança estrutural
destas construções em relação às operações padrões da UML. Por sua vez, introductions
são representadas como estereótipos de templates para colaborações. Aspectos são
semelhantes a classes, dessa forma são representados como classes estereotipadas. O
relacionamento entre classes e aspectos é representado por um novo estereótipo para
relacionamento chamado crosscut.
Esta abordagem é baseada em duas ferramentas bem aceitas pelos desenvolvedores
(AspectJ e UML), mas uma desvantagem notada nisso, apesar de serem ferramentas bem
disseminadas e muito utilizadas, é o fato da AODM estar restrita a elas. A UML não é um
padrão único para realizar a modelagem de sistemas e o AspectJ também não é um padrão
único para implementar aspectos. Essas características tornam a AODM muito restrita.
Outra dificuldade encontrada é o fato de que nem todos os links podem ser
representados como join point, visto que para links serem pontos de atuação de aspectos,
devem especificar apenas as comunicações que expressam as ações descrita no modelo dos
join points que são: criação de objetos, invocação de métodos, acesso a campos, e
tratamento de exceções. Isto causa uma certa inconsistência, pois num momento um link é
visto como join point e em outro não, (quando são utilizados para comunicar a destruição
de uma instância, por exemplo, não são vistos como join points).
45
Existem ainda algumas ações que não possuem um link pelo fato de não
estabelecerem uma comunicação entre duas instâncias. Um exemplo disso são ações de
leitura e escrita de atributos. Assim, não podem ser representados graficamente. Uma
maneira para resolver este problema, como proposto por (STEIN, 2002), seria a criação de
operações auxiliares de leitura e escrita (set e get) para cada atributo da classe. Para
diferenciar essas operações das demais é feito o uso de estereótipos especiais (<<set>> e
<<get>>).
Na verdade, as ferramentas atuais para modelar sistemas (tais como o Rational Rose e
Visio) ainda são muito restritas quando se referem ao campo dos aspectos. Elas não
apresentam todos elementos modelos propostos para representar os interesses
multidimensionais de um sistema e isto inviabiliza, de certa forma, a avaliação quanto à
verdadeira potencialidade das propostas de modelagens orientadas a aspectos.
Entretanto, apesar dessas dificuldades, a AODM se mostra ainda uma abordagem de
grande importância e bem estabelecida para o começo da padronização de sistemas de
software baseados em aspectos. Ela possibilita que as vantagens da modularização de
sistemas sejam trazidas para a fase de projeto, tais como maior compreensão do sistema a
ser desenvolvido e maior facilidade quanto à manutenção, adaptabilidade e reusabilidade do
sistema, visto que desde o inicío seus interesses serão tratados de forma separada, conforme
o domínio de cada um.
46
5. CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS
Várias linguagens de programação têm sido propostas para a implementação de
aspectos, pois, de fato, o desenvolvimento de sistemas de software aponta para esta área,
devido aos beneficios proporcionados pela conseqüente modularização. Com isso, começou
a surgir a necessidade de trazer estes benefícios para as fases anteriores ao processo de
implementação, propriamente.
Assim, muitas são as abordagens que trazem propostas para a modelagem de aspectos.
Neste trabalho, a abordagem estudada foi a de (STEIN, 2002) que buscou utilizar a mesma
semântica da UML, salvo algumas alterações semânticas para representar aspectos
implementados em AspectJ. Essas alterações tornaram-se possíveis devido aos mecanismos
de extensões suportados pelo meta-modelo UML. No entanto, tais mecanismos devem ser
utilizados cautelosamente para evitar que o príncipio de padronização na comunicação
entre desenvolvedores e ferramentas seja quebrado.
Sabendo que se tratam de paradigmas relativamente novos (sua criação remonta ao ano
de 1997), há ainda muito por fazer para que o uso da orientação a aspectos realmente seja
implementado potencialmente. No caso da modelagem, por exemplo, as ferramentas para
tal fim necessitam ser estendidas para suportar as novas abstrações da orientação a
aspectos.
Este trabalho descreveu uma validação para AODM. Representando, por meio de um
domínio bancário, como os interesses multidimensionais desse sistema podem ser tratados
separadamente, tendo apenas um relacionamento para definir a ligação que ilustra como
esses interesses interceptam a classe base.
47
Como trabalhos futuros, é proposto que seja realizada uma comparação entre as
principais abordagens existentes, de forma a verificar o que cada uma oferece ou mesmo
restringe, levantando assim as vantagens e desvantagens obtidas com uso de cada uma. E,
por fim, realizar uma padronização dessas abordagens, reunindo os elementos mais
vantajosos de cada uma.
48
6. REFERÊNCIAS BIBLIOGRÁFICAS
(AMBLER, 1997)
AMBLER, Scott W. Análise e projeto orientados a objetos.
Rio de Janeiro. Editora Infobook, 1997
(ASPECTJ, 2004)
AspectJ Home Page. Disponível em www.aspectj.org.
Acessado em 15/06/2004.
(BOOCH et Al, 2000)
BOOCH, Grady. RUMBAUGH, James. JACOBSON, Ivat.
UML – Guia do usuário. Rio de Janeiro. Editora Campus,
2000.
(CARDOSO, 2003)
CARDOSO, Caíque. UML na prática - Do problema ao
sistema. Rio de Janeiro: Ciência Moderna, 2003.
(CHAVES, 2004)
CHAVES, Rafael. Alves. Aspectos e MDA Criando
modelos executáveis baseados em aspectos.. Dissertação de
Mestrado
(Mestrado
em
Ciência
da
Computação)
Universidade Federal de Santa Catarina, Florianópolis, 2004
–
49
(COAD et. Al, 1993)
COAD, Peter. YOURDON, Edward. Projetos baseados em
objetos. Rio de Janeiro. Editora Campus, 1993.
(COAD et. Al, 1993)
COAD, Peter. YOURDON, Edward. Análise baseada em
objetos. Rio de Janeiro. Editora Campus, 1992.
(KICZALES et. Al, 1997)
KICZALES, Gregor et al. Aspect-oriented programming. In
Proc. of ECOOP, Springer-Verlag, 1997.
(KICZALES et.Al, 2001)
KICZALES, Gregor et al. Aspect–oriented programming
with AspectJ. In OOPSLA’01, Tutorial, Tampa FL.
(KISELEV, 2002)
KISELEV, Ivan. Aspect – Oriented Programming with
AspectJ, Ed. Sams Publishing, 2002.
(LEE et. Al, 2001 )
LEE, Richard C. TEPFENHART, William M. UML e C++ Guia prático de desenvolvimento orientado a objeto. São
Paulo. Editora Makron Books, 2001
(OMG, 2000)
Object Management Group (OMG). Unified Modeling
Language Specification, Versão 1.3. 2000
(PIVETA, 2001)
PIVETA, Eduardo Kessler. Um modelo de suporte a
programação orientada a aspectos. Florianópolis, 2001.
Dissertação
de
Mestrado
(Mestrado
em
Ciência
da
Computação) – Universidade Federal de Santa Catarina,
Florianópolis, 2001.
(SOARES, 2002)
Soares, Sérgio. Borba, Paulo “AspectJ – Programação
Orientada a Aspectos em Java”. Tutorial no SBLP 2002, 6º
50
Simpósio Brasileiro de Linguagens de Programação. PUCRio: Rio de Janeiro, 2002.
(STEIN, 2002)
STEIN, Dominik. An Aspect-Oriented Design Model Based
on AspectJ and UML. Dissertação de Mestrado (Mestrado
em
Gerenciamento
de
Sistemas
Universidade de Essen, Germany, 2002.
de
Informação)
–