ELAINE DA SILVA MONTEIRO
Implementação de um Aplicativo Utilizando AODM, Java e
AspectJ
Palmas – TO
2004
ii
ELAINE DA SILVA MONTEIRO
Implementação de um Aplicativo Utilizando AODM, Java e
AspectJ
“Monografia
apresentada
como
requisito da disciplina Prática de
Sistemas de Informação II do curso
de
Sistemas
de
Informação,
orientada
pela
Profª.
Cristina
D’ornellas Filipakis”
Palmas – TO
2004
iii
ELAINE DA SILVA MONTEIRO
Implementação de um Aplicativo Utilizando AODM, Java e
AspectJ
“Monografia apresentada como requisito
da disciplina Prática de Sistemas de
Informação II do curso de Sistemas de
Informação,
orientada
pela
Cristina D’ornellas Filipakis”
Aprovada em Dezembro de 2004
BANCA EXAMINADORA
Profª. Cristina D’ornellas Filipakis
Centro Universitário Luterano de Palmas
Profª. M.Sc. Thereza Patrícia Pereira Padilha
Centro Universitário Luterano de Palmas
Prof. Jackson Gomes de Souza
Centro Universitário Luterano de Palmas
Palmas – TO
2004
Profª.
iv
Eterno é tudo aquilo que vive uma fração
de segundos, mas, com tamanha intensidade,
que se petrifica e nenhuma força o resgata .
Drummond
v
AGRADECIMENTOS
Agradeço a DEUS por este momento precioso em minha vida. Por abrir caminhos onde não
havia e me fazer acreditar em seu perfeito amor.
Pai e mãe obrigada, dedico este momento da minha vida a vocês, porque não mediram
esforços, e continuam a não medir, para verem a minha felicidade. Espero continuar sendo
um motivo de orgulho para vocês.
Muito Obrigada!!!
i
SUMÁRIO
1.
INTRODUÇÃO ...................................................................................... 1
1.1
Objetivos do trabalho ............................................................................... 2
1.2
Organização do trabalho .......................................................................... 2
2.
REVISÃO DE LITERATURA ................................................................ 3
2.1
Programação Orientada a Aspectos......................................................... 3
2.2
AspectJ ...................................................................................................... 5
2.2.1
Join points .............................................................................................. 6
2.2.2
Pointcuts................................................................................................. 7
2.2.3
Advices ................................................................................................... 9
2.2.4
Introductions........................................................................................... 9
2.2.5
Aspects.................................................................................................. 10
2.3
Modelagem Orientada a Aspectos.......................................................... 10
2.3.1
Representando construções do AspectJ em UML .................................. 10
2.3.1.1 Join points ...................................................................................... 10
2.3.1.2 Pointcuts......................................................................................... 12
2.3.1.3 Advices .......................................................................................... 15
2.3.1.4 Introductions .................................................................................. 16
2.3.1.5 Aspects........................................................................................... 18
2.4
3.
3.1
Considerações.......................................................................................... 20
MATERIAIS E MÉTODOS .................................................................. 22
Local e Período........................................................................................ 22
ii
3.2
Materiais ................................................................................................. 22
3.2.1
Hardware .............................................................................................. 23
3.2.2
Software................................................................................................ 23
3.2.3
Fontes Bibliográficas ............................................................................ 23
3.3
4.
Metodologia............................................................................................. 23
RESULTADOS E DISCUSSÕES ........................................................ 24
4.1
Modelagem do aplicativo ........................................................................ 24
4.1.1
Requisitos do Sistema ........................................................................... 24
4.1.2
Casos de Uso ........................................................................................ 25
4.1.2.1 Ver saldo ........................................................................................ 25
4.1.2.2 Transferir ....................................................................................... 26
4.1.2.3 Cadastrar clientes ........................................................................... 26
4.1.2.4 Alterar senha .................................................................................. 27
4.1.2.5 Excluir clientes............................................................................... 28
4.1.2.6 Encerrar logon................................................................................ 28
4.1.3
Diagrama de Caso de uso ...................................................................... 29
4.1.4
Diagramas de Seqüência de Análise ...................................................... 30
4.1.4.1 Ver saldo ........................................................................................ 30
4.1.4.2 Transferir ....................................................................................... 31
4.1.4.3 Cadastrar Clientes........................................................................... 32
4.1.4.4 Alterar senha .................................................................................. 33
4.1.4.5 Excluir cliente ................................................................................ 34
4.1.4.6 Encerrar logon................................................................................ 34
4.1.5
Contratos .............................................................................................. 35
4.1.5.1 Ver saldo ........................................................................................ 35
4.1.5.1.1 Logar....................................................................................... 35
4.1.5.1.2 Validar usuário ........................................................................ 35
4.1.5.1.3 Escolher opção ........................................................................ 35
4.1.5.1.4 Exibir saldo ............................................................................. 36
iii
4.1.5.2 Transferir ....................................................................................... 36
4.1.5.2.1 Logar....................................................................................... 36
4.1.5.2.2 Validar usuário ........................................................................ 36
4.1.5.2.3 Escolher opção ........................................................................ 37
4.1.5.2.4 Solicita Dados.......................................................................... 37
4.1.5.2.5 Fornece dados.......................................................................... 37
4.1.5.2.6 Valida Dados ........................................................................... 38
4.1.5.2.7 Transfere valores ..................................................................... 38
4.1.5.3 Cadastrar clientes ........................................................................... 38
4.1.5.3.1 Logar....................................................................................... 38
4.1.5.3.2 Validar usuário ........................................................................ 39
4.1.5.3.3 Escolher opção ........................................................................ 39
4.1.5.3.4 Solicita dados .......................................................................... 39
4.1.5.3.5 Fornece Dados......................................................................... 40
4.1.5.3.6 Valida Dados ........................................................................... 40
4.1.5.3.7 Cadastrar Cliente ..................................................................... 40
4.1.5.4 Alterar senha .................................................................................. 41
4.1.5.4.1 Logar....................................................................................... 41
4.1.5.4.2 Validar usuário ........................................................................ 41
4.1.5.4.3 Escolher opção ........................................................................ 41
4.1.5.4.4 Solicitar nova senha ................................................................. 42
4.1.5.4.5 Inserir nova senha .................................................................... 42
4.1.5.4.6 Confirmar senha ...................................................................... 42
4.1.5.4.7 Confirma Senha ....................................................................... 43
4.1.5.4.8 Validar dados........................................................................... 43
4.1.5.4.9 Alterar Senha........................................................................... 43
4.1.5.5 Excluir clientes............................................................................... 44
4.1.5.5.1 Logar....................................................................................... 44
4.1.5.5.2 Validar usuário ........................................................................ 44
4.1.5.5.3 Escolher opção ........................................................................ 44
4.1.5.5.4 Identifica cliente ...................................................................... 45
iv
4.1.5.5.5 Exclui cadastro ........................................................................ 45
4.1.5.6 Encerrar logon................................................................................ 45
4.1.5.6.1 Escolher opção ........................................................................ 45
4.1.5.6.2 Finaliza Sessão ........................................................................ 46
4.1.6
Diagramas de Seqüência de Projeto....................................................... 46
4.1.6.1 Ver saldo ........................................................................................ 47
4.1.6.2 Transferir ....................................................................................... 48
4.1.6.3 Cadastrar clientes ........................................................................... 49
4.1.6.4 Alterar senha .................................................................................. 50
4.1.6.5 Excluir clientes............................................................................... 51
4.1.6.6 Encerrar logon................................................................................ 51
4.1.7
Diagrama de Classes ............................................................................. 52
4.2
Implementação do aplicativo.................................................................. 53
4.3
Considerações.......................................................................................... 56
5.
CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS ................... 58
6.
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 60
ANEXOS..................................................................................................... 63
v
Lista de Figuras
Figura 1 - Representação de um aspecto (KICZALES, 2001)............................................. 4
Figura 2 - Representação da estrutura do AspectJ............................................................. 6
Figura 3 - Fluxo de controle em AspectJ (KICZALES, 2001) ............................................. 7
Figura 4 - Estrutura de um pointcut nomeado ................................................................. 13
Figura 5 - Estereótipo <<Pointcut>> para operação (STEIN, 2002)............................ 14
Figura 6 - Estrutura de um advice ................................................................................... 15
Figura 7 - Estereótipo <<Advice>> para operação (STEIN, 2002) ............................... 16
Figura 8 - Estereótipo <<Introduction>> para operação (STEIN, 2002)....................... 18
Figura 9 - Estereótipo <<Aspect>> para classe (STEIN, 2002).................................... 20
Figura 10
Diagrama de Caso de uso para o aplicativo bancário .................................. 29
Figura 11
Diagrama de seqüência de análise Ver saldo ............................................... 30
Figura 12
Diagrama de seqüência de análise Transferir .............................................. 31
Figura 13
Diagrama de seqüência de análise Cadastrar clientes.................................. 32
Figura 14
Diagrama de seqüência de análise Alterar senha ......................................... 33
Figura 15
Diagrama de seqüência de análise Excluir cliente........................................ 34
Figura 16
Diagrama de seqüência de análise Encerrar logon ...................................... 34
Figura 17
Diagrama de seqüência de projeto Ver saldo ............................................... 47
Figura 18
Diagrama de seqüência de projeto Transferir .............................................. 48
Figura 19
Diagrama de seqüência de projeto Cadastrar clientes.................................. 49
Figura 20
Diagrama de seqüência de projeto Alterar Senha......................................... 50
Figura 21
Diagrama de seqüência de projeto Excluir clientes ...................................... 51
Figura 22
Diagrama de seqüência de projeto Encerrar logon ...................................... 52
Figura 23
Diagrama de classes para o aplicativo bancário .......................................... 53
Figura 24
Tela do Administrador do sistema ................................................................ 54
Figura 25
Exemplo da execução do método verSaldo ................................................... 55
Figura 26
Exemplo da execução do método cadastrarCliente....................................... 56
Figura 27 - Representação dos pacotes Behavioral Elements, Model Management e
Foundation da especificação UML (OMG, 2000)............................................................. 65
vi
Figura 28- Diagrama de Classes para o domínio Bancário ............................................. 67
Figura 29 - Exemplo de um estereótipo contendo tagged values ...................................... 68
Figura 30 - Diagrama de Seqüência para o domínio Bancário ........................................ 71
vii
Lista de Tabelas
Tabela 1: PCDs baseados no tipo do join point (JP) .......................................................... 8
Tabela 2: PCDs baseados na propriedade do join point (JP)............................................. 8
Tabela 3: Valores para instâncias do aspecto .................................................................. 19
viii
Lista de Abreviaturas
AODM
Aspect Oriented Design Model
AOP
Aspect Oriented Programming
SOP
Subject-Oriented Programming
UML
Unified Modeling Language
AJDT
AspectJ Development Tools
ix
RESUMO
O propósito deste trabalho é demonstrar os beneficios trazidos com o uso das
tecnologias advindas da orientação a aspectos. Para tanto, será implementado um aplicativo
que aborda um sistema bancário, utilizando a Modelagem Orientada a Aspectos proposta
por STEIN (2002) na fase de projeto e as linguagens de programação AspectJ e Java na
fase de implementação.
Palavras chave: Modelagem orientada a aspectos, AspectJ, Java
x
ABSTRACT
The intention of this work is evidence the benefits brought with use of technologies
come from aspect-oriented programming. Therefore, will be implemented an application
that approach a banking system, utilizing a Aspect-Oriented Design Model by STEIN
(2002) in project phase and the programming languages AspectJ and Java on
implementation phase.
Keywords: Aspect-Oriented Design Model, AspecJ and Java
1
1. INTRODUÇÃO
Devido à complexidade na criação e implementação de softwares não-triviais, novas
tecnologias são estudadas e aplicadas ao seu processo de desenvolvimento para facilitar
essa tarefa. Isto é realizado desde os primórdios da programação, podendo-se observar a
evolução destas tecnologias partindo da programação utilizando linguagens a nível de
máquina, passando pelos procedimentos, funções e objetos e apresentando então os
aspectos.
A programação orientada a aspectos vem suprir a fragilidade encontrada na orientação
a objetos que é notada quando interesses distintos, requisitos funcionais e não funcionais do
sistema, encontram-se entrelaçados a outras partes de códigos, tornando-os difíceis de
compreender,
desenvolver
e
manter.
Tais
interesses,
são
denominados
como
multidimensionais (crosscutting concerns) porque atravessam várias dimensões - classes do
sistema.
Os aspectos encapsulam interesses que afetam múltiplas classes, por isso permitem aos
programadores modularizar melhor o seu sistema de software. Assim, o código que antes se
tornara confuso em decorrência do entrelaçamento de interesses distintos, agora se torna
mais claro por estar separado num aspecto.
Em primeiro plano, a orientação a aspectos foi direcionada à fase de implementação
(com ferramentas como AspectJ e HyperJ), mas logo foi verificada a necessidade em se
levar as vantagens da modularização às fases anteriores no processo de desenvolvimento do
software. No entanto, uma dificuldade encontrada é que as linguagens de modelagem atuais
2
não provêm recursos para modelar os aspectos. Então, uma nova abordagem foi proposta
por STEIN (2002), baseada em AspectJ e UML
(Aspect-Oriented Design Model
a Modelagem Orientada a Aspectos
AODM). Ela estende a UML (Unified Modeling
Language) com recursos capazes de representar os efeitos causados por interesses
multidimensionais. Tanto os conceitos desta abordagem, como os de AspectJ serão
estudados e exemplificados no decorrer deste relatório. Em seguida, são apresentados os
objetivos e a organização deste trabalho.
1.1
Objetivos do trabalho
A finalidade principal deste trabalho é demonstrar a utilização das novas tecnologias
advindas da orientação a aspectos e isto será feito por meio de um aplicativo de um sistema
bancário. Assim, serão empregadas a Modelagem Orientada a Aspectos proposta por
STEIN (2002) e as linguagens de programação AspectJ e Java.
1.2
Organização do trabalho
O conteúdo deste trabalho está disposto 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 aplicativo bancário são descritos no capítulo 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.
3
2. REVISÃO DE LITERATURA
Para que os propósitos desse trabalho fossem alcançados, foram realizados
pesquisas e estudos envolvendo conceitos e ferramentas referentes à Programação
Orientada a Aspectos, AspectJ e AODM para que proporcionassem uma fundamentação
teórica. Parte desses estudos foram iniciados na disciplina Prática de Sistemas de
Informação I, que teve como tema Um Estudo sobre a Modelagem Orientada a Aspectos
baseada em AspectJ e UML (MONTEIRO, 2004) e serão apresentados no decorrer desta
seção.
2.1
Programação Orientada a Aspectos
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.
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 uma modularização adequada, beneficiando
4
tanto o desenvolvimento como a manutenção de um sistema. A seguir a Figura 1 traz essa
representação.
Figura 1 - Representação de um interesse multidimensional concentrado num aspecto (KICZALES, 2001)
Nesta Figura acima, pode-se observar as classes bases de um sistema, representadas
pelas barras mais claras, e os interesses multidimensionais representados em um aspecto (a
barra em vermelho). Assim, é possível perceber a separação dos requisitos do sistema.
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;
•
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:
5
•
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 aplicativo bancário, ver
saldo, e transferir ilustram isso.
•
Aspectos são propriedades que afetam a performance ou semântica dos
componentes. Tratamento de exceções, consistência de dados, segurança,
controle de acesso, tracing 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 por concentrar e tratar apenas um interesse do
sistema.
2.2
AspectJ
Dentre as propostas para implementar aspectos, pode-se destacar a ferramenta
AspectJ (ASPECTJ, 2004). Esta seção traz os conceitos principais desta ferramenta.
AspectJ é 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. É 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 (ASPECTJ, 2004). 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
6
•
execução de manipuladores de exceção.
A Figura 2 apresenta a estrutura do AspectJ, na qual os componentes são
implementados 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 2 - 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
implementa tanto as propriedades definidas pelos componentes como aquelas definidas
pelos aspectos (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.
2.2.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 3, 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, por exemplo. Os
vértices representariam as relações de fluxo de controle entre os nós, partindo do que
7
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 sub-nó 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. Isto permite
maior exatidão quanto à aplicação dos aspectos em relação ao código-fonte de um
componente qualquer.
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 3 - Fluxo de controle em AspectJ (KICZALES, 2001)
2.2.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).
8
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
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
Cflowbelow(Pointcut)
Idem ao anterior, excluindo os JPs selecionados pelo
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(* transferir(..))
seleciona os join points onde o método transferir, independentemente do tipo, e de zero ou
mais argumentos, seja executado. Um pointcut é definido da seguinte forma:
pointcut <Nome> (Argumentos): <corpo>;
9
Um pointcut pode ser aninhado em outro pointcut com os operadores e, ou e não
(&&, ||, e !).
2.2.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:
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.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.
Analogamente aos advices, que atuam em pontos específicos do programa denotados por
pointcuts, introductions irão atuar sobre um conjunto de definições de classes (STEIN,
2002).
10
2.2.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 se que encaixa dentro de classes hierárquicas, aspects encapsulam o
código que se entrelaça a essas classes hierárquicas. Embora o comportamento especificado
pelos advices e introductions declarados possam modificar todo o sistema, eles sempre são
localizados no código-fonte dos aspectos.
2.3
Modelagem Orientada a Aspectos
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ê (apresentados no Anexo I deste trabalho), 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 parte do trabalho, será mostrado um estudo sobre a representação UML para as
construções de AspectJ.
2.3.1 Representando construções do AspectJ em UML
2.3.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:
11
•
criação de objetos;
•
invocação de métodos;
•
acesso a campos; e
•
tratamento de exceções.
Visto isso, ele buscou uma semelhança no meta-modelo UML e constatou um
paralelo, pois a linguagem UML também 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 no
Anexo I). 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
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 (Anexo I) e
são representadas graficamente como setas no diagrama de interação (seja de seqüência ou
de colaboração).
12
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 linguagem 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 (Anexo I). 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, para que
assim se possa 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 essas ações de acesso a campos como 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 (e isto caracteriza uma comunicação entre instâncias, pois haverá uma chamada a
essas operações para que acessem um 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).
2.3.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
13
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 4 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(*tranferir(..))&&target(c)
Declaração pointcut
Figura 4 - 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 tagged values para conter essa instrução. Tagged values podem ser
usados para representar informações tais como: gerência, geração de código ou semântica
adicional que é requerida por um determinado estereótipo.
Tagged values são adequados para representar os pointcuts em sua função de
weaving através de duas formas (STEIN, 2002):
•
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.
14
STEIN
(2002)
propõe
um
estereótipo
para
métodos
chamado
<<containsWeavingInstructions>>, para conter os pontos de atuação dos aspectos, ou
seja, as instruções para o processo weaving. Para tanto faz-se necessária a definição de uma
meta-propriedade, 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 tagged value
base e então marca cada join point definido por ela (STEIN, 2002).
A Figura 5 abaixo, traz como esse estereótipo é representado no meta-modelo UML.
Figura 5 - Estereótipo <<Pointcut>> para operação (STEIN, 2002)
Como mostra a Figura 5, é necessário observar que o estereótipo <<Pointcut>> tem
algumas
restrições.
Ele
deve
ser
implementado
pelo
estereótipo
15
<<containsWeavingInstructions>>. 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 valor, 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.3.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 é 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 6 representa a estrutura de
um advice.
void around (Conta c, double valor):
creditos(c, valor){...}
Assinatura
Declaração Pointcut
Figura 6 - 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.
16
A Figura 7 mostra como o estereótipo <<advice>> é representado no meta-modelo
UML.
Figura 7 - Estereótipo <<Advice>> para operação (STEIN, 2002)
Como mostra a Figura 7, é necessário observar que o estereótipo <<Advice>> tem
algumas
restrições.
Ele
deve
ser
implementado
pelo
método
do
<<containsWeavingInstructions>>. Os meta-atributos isRoot e isLeaf
estereótipo
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.3.1.4 Introductions
Como visto na seção anterior 2.2.4, os introductions modificam uma classe
estruturalmente, acrescentando a ela novos membros, como construtores, métodos e
17
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):
•
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 aspecto 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>>. A Figura 8 representa este estereótipo no meta-
modelo UML:
18
Figura 8 - Estereótipo <<Introduction>> para operação (STEIN, 2002)
2.3.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
tagged value instantiation é definido e serve para armazenar a forma como os aspectos
serão instanciados. Para reconhecer esses valores um novo tipo de dado é criado, chamado:
InstantiationKind. Um tagged value
instatiation
instâncias apresentados na Tabela 3 (STEIN, 2002).
pode ter somente os valores para
19
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 (quaisquer
classes, mesmo privadas), o tagged value privileged é apresentado. Ele comporta os
valores booleanos true e false.
Abaixo, na Figura 9, segue-se a representação para o estereótipo aspect, no metamodelo UML.
20
Figura 9 - Estereótipo <<Aspect>> para classe (STEIN, 2002)
Como observado na Figura 9 cada tagged value requerido pelo aspecto deve conter
o tipo específico. Para instantiation o tipo deve ser InstantiationKind, para a tag Base o
tipo deve ser LinkSetExpression, e para a tag privileged o tipo deve ser booleano.
2.4
Considerações
Este Capítulo buscou tratar as principais idéias advindas da orientação a aspectos,
partindo do paradigma geral, apresentando as construções de programa da ferramenta
AspectJ e a proposta de modelagem orientada a aspectos de STEIN (2002). Com o uso
desses conceitos observa-se que o desenvolvimento de um sistema de software torna-se
uma tarefa mais clara de ser realizada.
A linguagem de programação AspectJ é vantajosa por abranger a parcela de
desenvolvedores adeptos ao Java, e sendo uma extensão desta linguagem recebe as suas
qualidades, reconhecendo também a sua síntaxe.
21
As construções de programa que o AspectJ traz são capazes de prover melhor
modularização para a implementação de um requisito que tem como característica a
multidimensionalidade num sistema de software, ou seja, seu espalhamento por várias
classes do sistema. Tal requisito pode ser tratado para interceptar o comportamento ou
estrutura de um trecho de código (uma chamada ou execução de método por exemplo).
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. Como já mencionado anteriomente, na seção 2.3 deste
trabalho, 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 é necessário para que as ações sejam bem distintas, a fim de permitir maior
exatidão em relação à designação dos interesses multidimensionais.
Com base nessa verificação, STEIN (2002) adotou os mecanismos de extensão
especificados no meta-modelo UML (Anexo I) para estender os elementos modelos
existentes com novas semânticas, de forma que pudessem representar graficamente os
aspectos.
Por ser fruto de uma tese de mestrado recente, a abordagem de STEIN (2002)
encontra algumas dificuldades de ser representada na íntegra pelas ferramentas de
modelagem atuais, como o Rational Rose. Mesmo assim, se caracteriza como um ponto
importante para o início do desenvolvimento de projetos orientados a aspectos.
Estas características serão exemplificadas no Capítulo 4. O próximo Capítulo traz a
metodologia utilizada para o desenvolvimento deste trabalho.
22
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 segundo semestre de 2004, como parte da
disciplina Prática em Sistemas de Informação II (TCC) . 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 de 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.
23
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;
•
AspectJ (Versão 1.2.1, revisada em Novembro de 2004);
•
Rational Rose;
•
Eclipse;
•
Pluggin AJDT;
•
Java.
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.
24
4. RESULTADOS E DISCUSSÕES
Esta seção tem o objetivo de apresentar uma proposta de desenvolvimento de um
aplicativo no domínio bancário, utilizando para isso a proposta de STEIN (2002) para
realizar a modelagem deste e as linguagens de programação AspectJ - para implementar os
aspectos - e Java para os componentes deste aplicativo. Desta forma, são demonstradas as
características da programação orientada a aspectos, que foram apresentadas no decorrer do
Capítulo 2.
4.1
Modelagem do aplicativo
4.1.1 Requisitos do Sistema
O trabalho desenvolvido durante a disciplina Prática de Sistemas de Informação II
(TCC
Trabalho de Conclusão de Curso) refere-se a um aplicativo bancário e o objetivo
principal, proposto neste trabalho, é demonstrar a utilização das técnicas de separação de
interesses (SoC
Separation of Concerns) contidas no paradigma orientado a aspectos,
utilizando para tal finalidade AspectJ (ASPECTJ, 2004) e AODM (STEIN, 2002).
Os requisitos funcionais do sistema são os seguintes:
•
Ver saldo;
•
Transferir;
•
Cadastrar clientes;
25
•
Alterar senha;
•
Excluir clientes;
•
Encerrar logon;
Este aplicativo bancário não terá como funcionalidades sacar e depositar, visto que não
aborda o contexto de um caixa eletrônico, mas, ao invés disso, representa um domínio no
qual o usuário fará transações simples como ver o seu saldo e transferir uma quantia do seu
saldo para outra conta.
Como requisitos não funcionais têm-se os seguintes itens:
•
Realizar a autenticação do usuário com relação às funcionalidades do aplicativo; e
•
Realizar o controle do fluxo de execução do programa (tracing).
Duas linguagens serão utilizadas para a implementação desses requisitos: a primeira é
Java, que será utilizada para codificar os requisitos funcionais, e a segunda é o AspectJ,
para os requisitos não funcionais.
Os usuários identificados para este aplicativo são o administrador e o cliente. O
administrador deverá ter acesso a todas as funcionalidades do sistema. Já os clientes
poderão somente logar, ver saldo, transferir, alterar senha e encerrar o seu logon. As
próximas seções apresentam os casos de uso e os diagramas em UML correspondentes.
4.1.2 Casos de Uso
4.1.2.1 Ver saldo
Caso de uso: Ver saldo
Atores: Cliente, administrador
Finalidade: Mostrar o saldo do cliente
Visão Geral: Um usuário solicita ao sistema seu saldo, então o sistema emite o saldo
Tipo: primário
26
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
1. Este caso de uso começa quando um
2. Verifica o login e a senha do usuário.
usuário identifica-se no sistema.
3. Escolhe a opção Ver saldo.
4. Exibe o saldo.
Seqüências alternativas:
Linha 4: Dados inconsistentes, o sistema exibe uma mensagem de erro.
4.1.2.2 Transferir
Caso de uso: Transferir
Atores: Cliente, administrador
Finalidade: Realizar a transferência de valores de uma conta para outra
Visão Geral: Um usuário solicita ao sistema transferir valores, então o sistema, a partir dos
dados fornecidos pelo usuário, transfere um valor para outra conta
Tipo: primário
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
1. Este caso de uso começa quando um
2. Verifica a senha e login do usuário.
usuário identifica-se no sistema.
3. Escolhe a opção Transferir.
4. Solicita o número da conta do favorecido
e do usuário e o valor a ser transferido.
4. Fornece os dados
5. Verifica os dados e se o saldo é suficiente.
6. Faz a transferência e emite um
comprovante
Seqüências alternativas:
Linha 5: Dados inconsistentes e saldo insuficiente, o sistema exibe uma mensagem de erro.
4.1.2.3 Cadastrar clientes
Caso de uso: Cadastrar clientes
Atores: Administrador
Finalidade: Realizar cadastro de clientes
27
Visão Geral: O administrador do sistema solicita ao sistema realizar o cadastro de clientes,
então o sistema exibe a tela de cadastro
Tipo: primário
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
1. Este caso de uso começa quando um
2. Verifica a senha e login do usuário.
administrador identifica-se no sistema.
3. Escolhe a opção Cadastrar.
4. Exibe a tela de cadastro.
5. O administrador fornece os dados.
6. Verifica a consistência dos dados.
7. Cadastra o cliente.
Seqüências alternativas:
Linha 6: Dados inconsistentes, o sistema exibe uma mensagem de erro.
4.1.2.4 Alterar senha
Caso de uso: Alterar senha
Atores: Administrador, cliente
Finalidade: Realizar a alteração no cadastro de clientes
Visão Geral: O usuário do sistema solicita ao sistema realizar alteração de senha, então o
sistema exibe a tela de alteração de senha
Tipo: primário
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
1. Este caso de uso começa quando um
2. Verifica a senha e login do usuário.
usuário identifica-se no sistema.
3. Escolhe a opção Alterar senha.
4. Exibe a tela de alteração de senha.
5. Altera os dados.
6. Verifica a consistência dos dados.
7. Altera o cadastro do cliente.
Seqüências alternativas:
Linha 8: Dados inconsistentes, o sistema exibe uma mensagem de erro.
28
4.1.2.5 Excluir clientes
Caso de uso: Excluir clientes
Atores: administrador
Finalidade: Excluir clientes do banco
Visão Geral: O administrador do sistema solicita ao sistema a exclusão de um determinado
cliente
Tipo: primário
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
1. Este caso de uso começa quando um
2. Verifica a senha e login do usuário.
usuário identifica-se no sistema.
3. Escolhe a opção Excluir cliente.
4. Solicita o cliente a ser excluído.
5. Identifica o cliente.
6. Exclui o cliente.
Seqüências alternativas:
Linha 5: Dados inconsistentes, o sistema exibe uma mensagem de erro.
4.1.2.6 Encerrar logon
Caso de uso: Encerrar logon
Atores: cliente, administrador
Finalidade: Encerrar a sessão do usuário no sistema
Visão Geral: Um usuário realiza as operações devidas e então sai do sistema
Tipo: primário
Seqüência Típica de Eventos
Ação do Ator
Resposta do Sistema
1. Este caso de uso começa quando um 2. Encerra a sessão do usuário.
usuário solicita sair do sistema.
29
4.1.3 Diagrama de Caso de uso
Figura 10
Diagrama de Caso de uso para o aplicativo bancário
30
4.1.4 Diagramas de Seqüência de Análise
4.1.4.1 Ver saldo
Figura 11
Diagrama de seqüência de análise Ver saldo
31
4.1.4.2 Transferir
Figura 12
Diagrama de seqüência de análise Transferir
32
4.1.4.3 Cadastrar Clientes
Figura 13
Diagrama de seqüência de análise Cadastrar clientes
33
4.1.4.4 Alterar senha
Figura 14
Diagrama de seqüência de análise Alterar senha
34
4.1.4.5 Excluir cliente
Figura 15
Diagrama de seqüência de análise Excluir cliente
4.1.4.6 Encerrar logon
Figura 16
Diagrama de seqüência de análise Encerrar logon
35
4.1.5 Contratos
4.1.5.1 Ver saldo
4.1.5.1.1
Logar
Nome: Logar(login, senha)
Responsabilidades: Iniciar uma sessão para o usuário
Exceções: Usuário não cadastrado
Saída: Pré-condições: Usuário ser cadastrado no sistema
Pós-condições: -
4.1.5.1.2
Validar usuário
Nome: ValidarCliente(login, senha)
Responsabilidades: Verificar se o usuário existe na base de dados
Exceções: Usuário não cadastrado
Saída: Pré-condições: Usuário ser cadastrado no sistema
Pós-condições: -
4.1.5.1.3
Escolher opção
Nome: EscolherOpção(opção)
Responsabilidades: Selecionar uma das funcionalidades do sistema
Exceções: Saída: Pré-condições: O usuário deve estar logado no sistema
Pós-condições: -
36
4.1.5.1.4
Exibir saldo
Nome: ExibirSaldo(conta)
Responsabilidades: Mostrar o saldo da conta para o usuário
Exceções: Conta inexistente
Saída: Pré-condições: Usuário logado
Pós-condições: -
4.1.5.2 Transferir
4.1.5.2.1
Logar
Nome: Logar(login, senha)
Responsabilidades: Iniciar uma sessão para o usuário
Exceções: Usuário não cadastrado
Saída: Pré-condições: Usuário ser cadastrado no sistema
Pós-condições: -
4.1.5.2.2
Validar usuário
Nome: ValidarCliente(login, senha)
Responsabilidades: Verificar se o usuário existe na base de dados
Exceções: Usuário não cadastrado
Saída: Pré-condições: Usuário ser cadastrado no sistema
Pós-condições: -
37
4.1.5.2.3
Escolher opção
Nome: EscolherOpção(opção)
Responsabilidades: Selecionar uma das funcionalidades do sistema
Exceções: Saída: Pré-condições: O usuário deve estar logado no sistema
Pós-condições: -
4.1.5.2.4
Solicita Dados
Nome: SolicitaDados (conta, contaFavorecido, valor)
Responsabilidades: Solicitar valores para as variáveis conta, contaFavorecido e valor
Exceções: Saída: Pré-condições: O usuário deve estar logado no sistema
Pós-condições: -
4.1.5.2.5
Fornece dados
Nome: ForneceDados (conta, contaFavorecido, valor)
Responsabilidades: Fornecer valores para as variáveis conta, contaFavorecido e valor
Exceções: Saída: Pré-condições: O usuário deve está logado no sistema
Pós-condições: -
38
4.1.5.2.6
Valida Dados
Nome: ValidaDados (conta, contaFavorecido, valor)
Responsabilidades: Verifica a validade dos valores para as variáveis conta,
contaFavorecido e valor
Exceções: Saída: Pré-condições: Os dados dever ser fornecidos pelo usuário
Pós-condições: -
4.1.5.2.7
Transfere valores
Nome: TransfereValores (conta, contaFavorecido, valor)
Responsabilidades: Transferir um determinado valor fornecido pelo usuário para uma
conta que ele definiu
Exceções: Saldo insuficiente
Saída: Pré-condições: Ter saldo suficiente
Pós-condições: Seta as variáveis conta, contaFav e saldo com novos valores
4.1.5.3 Cadastrar clientes
4.1.5.3.1
Logar
Nome: Logar(login, senha)
Responsabilidades: Iniciar uma sessão para o usuário
Exceções: Usuário não cadastrado
Saída: Pré-condições: Usuário ser cadastrado no sistema
Pós-condições: -
39
4.1.5.3.2
Validar usuário
Nome: ValidarCliente(login, senha)
Responsabilidades: Verificar se o usuário existe na base de dados
Exceções: Usuário não cadastrado
Saída: Pré-condições: Usuário ser cadastrado no sistema
Pós-condições: -
4.1.5.3.3
Escolher opção
Nome: EscolherOpção(opção)
Responsabilidades: Selecionar uma das funcionalidades do sistema
Exceções: Saída: Pré-condições: Usuário estar logado no sistema
Pós-condições: -
4.1.5.3.4
Solicita dados
Nome: SolicitaDados(dados)
Responsabilidades: Solicitar os valores que serão definidos para o cadastro de clientes
Exceções: Saída: Pré-condições: Pós-condições: -
40
4.1.5.3.5
Fornece Dados
Nome: ForneceDados(dados)
Responsabilidades: Setar os valores que serão definidos para o cadastro de clientes
fornecido pelo administrador
Exceções: Saída: Pré-condições: Pós-condições: -
4.1.5.3.6
Valida Dados
Nome: ValidaDados(dados)
Responsabilidades: Validar os valores que serão definidos para o cadastro de clientes
Exceções: Saída: Pré-condições: Pós-condições: -
4.1.5.3.7
Cadastrar Cliente
Nome: CadastrarCliente(dados)
Responsabilidades: Setar os valores que serão setados para o cadastro de clientes
Exceções: Saída: Pré-condições: Pós-condições: Variáveis do cadastro de clientes setadas com os valores fornecidos pelos
usuários
41
4.1.5.4 Alterar senha
4.1.5.4.1
Logar
Nome: Logar(login, senha)
Responsabilidades: Iniciar uma sessão para o usuário
Exceções: Usuário não cadastrado
Saída: Pré-condições: Usuário ser cadastrado no sistema
Pós-condições: -
4.1.5.4.2
Validar usuário
Nome: ValidarCliente(login, senha)
Responsabilidades: Verificar se o usuário existe na base de dados
Exceções: Usuário não cadastrado
Saída: Pré-condições: Usuário ser cadastrado no sistema
Pós-condições: -
4.1.5.4.3
Escolher opção
Nome: EscolherOpção(opção)
Responsabilidades: Selecionar uma das funcionalidades do sistema
Exceções: Saída: Pré-condições: Usuário estar logado no sistema
Pós-condições: -
42
4.1.5.4.4
Solicitar nova senha
Nome: solicitaNovaSenha()
Responsabilidades: Enviar uma solicitação ao usuário uma solicitação para que digite uma
nova senha
Exceções: Saída: Pré-condições: Pós-condições: -
4.1.5.4.5
Inserir nova senha
Nome: insereNovaSenha()
Responsabilidades: capturar a nova senha digitada pelo usuário
Exceções: Saída: Pré-condições: Pós-condições: -
4.1.5.4.6
Confirmar senha
Nome: confirmarSenha()
Responsabilidades: Enviar uma solicitação para que o usuário confirme a nova senha
digitada
Exceções: Saída: Pré-condições: Pós-condições: -
43
4.1.5.4.7
Confirma Senha
Nome: confirmaSenha(senha)
Responsabilidades: capturar a confirmação da nova senha que o usuário digitou
Exceções: Saída: Pré-condições: Pós-condições: -
4.1.5.4.8
Validar dados
Nome: validarDados()
Responsabilidades: Verificar a concistência dos dados
Exceções: Saída: Pré-condições: Pós-condições: Variáveis do cadastro de usuário modificadas
4.1.5.4.9
Alterar Senha
Nome: alterarSenha()
Responsabilidades: Trocar a senha antiga pou uma nova que o usuário digitou
Exceções: Saída: Pré-condições: Pós-condições: Senha do usuário modificada
44
4.1.5.5 Excluir clientes
4.1.5.5.1
Logar
Nome: Logar(login, senha)
Responsabilidades: Iniciar uma sessão para o usuário
Exceções: Usuário não cadastrado
Saída: Pré-condições: Usuário ser cadastrado no sistema
Pós-condições: -
4.1.5.5.2
Validar usuário
Nome: ValidarCliente(login, senha)
Responsabilidades: Verificar se o usuário existe na base de dados
Exceções: Usuário não cadastrado
Saída: Pré-condições: Usuário ser cadastrado no sistema
Pós-condições: -
4.1.5.5.3
Escolher opção
Nome: EscolherOpção(opção)
Responsabilidades: Selecionar uma das funcionalidades do sistema
Exceções: Saída: Pré-condições: Usuário estar logado no sistema
Pós-condições: -
45
4.1.5.5.4
Identifica cliente
Nome: IdentificaCliente(cliente)
Responsabilidades: Identificar qual cliente terá seu cadastro alterado
Exceções: Saída: Pré-condições: Pós-condições: -
4.1.5.5.5
Exclui cadastro
Nome: ExcluiCadastro(cliente)
Responsabilidades: Permitir a exclusão de clientes do sistema
Exceções: Cliente inexistente
Saída: Pré-condições: Pós-condições: Cliente excluído
4.1.5.6 Encerrar logon
4.1.5.6.1
Escolher opção
Nome: EscolherOpção(opção)
Responsabilidades: Selecionar uma das funcionalidades do sistema
Exceções: Saída: Pré-condições: Usuário estar logado no sistema
Pós-condições:
46
4.1.5.6.2
Finaliza Sessão
Nome: FinalizaSessao()
Res ponsabilidades: Permitir o encerramento da sessão do usuário
Exceções: Saída: Pré-condições: Pós-condições: -
4.1.6 Diagramas de Seqüência de Projeto
Nos diagramas de seqüência de projeto, representados a seguir, pode-se observar
com detalhes a interceptação dos aspectos trancing e autenticacao nas classes do
aplicativo bancário.
Segundo a Modelagem Orientada a Aspectos de STEIN (2002), os pontos de
atuação de um aspecto são representados como setas nestes diagramas, os quais estendem
as interfaces que representam os advices no diagrama de classes (Figura 23). Sempre que os
métodos são chamados e executados, o aspecto tracing irá atuar para realizar o controle
do fluxo de execução.
Os
métodos
verSaldo,
transferir,
cadastrar,
alterarCadastro
e
excluirCliente são interceptados, ainda, pelo aspecto autenticacao. Este aspecto irá
solicitar a senha do usuário, para então permitir o procedimento normal da execução deste
método, caso a senha esteja correta.
47
4.1.6.1 Ver saldo
Figura 17
Diagrama de seqüência de projeto Ver saldo
48
4.1.6.2 Transferir
Figura 18
Diagrama de seqüência de projeto Transferir
49
4.1.6.3 Cadastrar clientes
Figura 19
Diagrama de seqüência de projeto Cadastrar clientes
50
4.1.6.4 Alterar senha
Figura 20
Diagrama de seqüência de projeto Alterar Senha
51
4.1.6.5 Excluir clientes
Figura 21
4.1.6.6 Encerrar logon
Diagrama de seqüência de projeto Excluir clientes
52
Figura 22
Diagrama de seqüência de projeto Encerrar logon
4.1.7 Diagrama de Classes
O diagrama de classes apresentado na Figura 23, é composto pelas classes Banco,
Usuários (que se especializa em Adm e Clientes) e Conta. Ele representa, ainda, dois
aspectos, tracing e autenticacao. O aspecto tracing irá atuar sobre todos os métodos e,
portanto, ele intercepta diretamente as classes Usuários e Conta. A idéia deste aspecto é
possibilitar um relatório do fluxo de execução. Por meio disso, pode-se saber com que
freqüência os métodos foram acessados, por exemplo. Isso é interessante para a parte
administrativa do banco, pois, assim, pode-se ter um histórico sobre cada usuário, usando o
aplicativo.
Já o aspecto autenticacao implementa o código que intercepta sempre antes da
execução dos métodos verSaldo, transferir, cadastrarCliente, AlterarCadastro e
ExcluirCadastro. Solicitando a senha do usuário, então realiza uma busca na base de
dados e verifica se realmente a senha que o usuário digitou confere com a que está gravada
na base de dados. Se conferir, a execução do método procede normalmente, senão, será
53
emitida uma mensagem ao usuário lhe informando que a senha está incorreta e é terminada
a execução do método.
Figura 23
4.2
Diagrama de classes para o aplicativo bancário
Implementação do aplicativo
Nesta fase do desenvolvimento, foi utilizado AJDT
AspectJ Development Tools
para implementar os componentes e aspectos. O AJDT (AJDT, 2004) é um conjunto de
pluggins para o Eclipse e permite o desenvolvimento de softwares orientados a aspectos
utilizando o AspectJ. Esta ferramenta facilitou muito a implementação dos aspectos, pois
fornece uma interface gráfica bem robusta e ainda possibilita ajuda na sintaxe da linguagem
AspectJ, à medida que o usuário escreve o código.
54
Em seguida são exemplificados os aspectos tracing e auteticacao, atuando sobre
os métodos verSaldo e cadastrarCliente (Figuras 24 a 26).
Figura 24
Tela do Administrador do sistema
Na Figura 24 é apresentada a tela destinada ao Administrador. Nesta estão dispostas
as funcionalidades que este usuário tem acesso. A opção escolhida nesta tela foi a
(ver
saldo), antes desse método começar a executar, ele é interrompido por um momento,
enquanto os aspectos executam seu código adicional.
Assim, o aspecto responsável pela autenticação solicita ao usuário que forneça a sua
senha, como uma maneira de realizar o reconhecimento do usuário, realiza uma busca na
base de dados e verifica a validade da senha que o usuário digitou. Se coincidirem este
aspecto permite a execução normal do método, caso contrário o método é interrompido,
informando ao usuário que a operação não foi realizada porque a senha não está correta.
Neste mesmo método, o aspecto responsável pelo controle da execução de programa,
tracing, escreve na tela o início e o fim em que o método foi executado.
representado na Figura 25.
Isto é
55
Figura 25
O
mesmo
Exemplo da execução do método verSaldo
procedimento
é
realizado
para
os
métodos
transferir,
cadastrarClientes, alterarCadastro, excluirClientes. A Figura 26 apresenta a
interceptação desses dois aspectos sobre o método cadastrarCliente.
56
Figura 26
4.3
Exemplo da execução do método cadastrarCliente
Considerações
O código deste aplicativo, na íntegra, está no Anexo 2. Este capítulo trouxe as
principais etapas do processo de desenvolvimento do aplicativo bancário, apresentando
como os aspectos, implementados em AspectJ, podem ser representados ainda na fase de
projeto, através da Modelagem Orientada a Aspectos (STEIN, 2002).
Algumas dificuldades foram encontradas nesta etapa do projeto. O fato desta
abordagem, AODM, ser relativamente nova implica na limitação de ferramentas, que não
têm todos os requisitos para validá-la. Por exemplo, o Rational Rose 2000 não previa, até a
última versão utilizada, uma forma de representação para os taggeds values dentro de um
estereótipo de uma classe, o aspect. Por isso, foram representados como notas.
Representando os requisitos do sistema em diagramas de seqüência, especialmente
os de projeto, permite uma maior visibilidade do funcionamento deste sistema. Desta
forma, pôde-se observar o exato ponto em que os aspectos atuam. Isto é interessante para
57
que se possa definir o funcionamento de um aspecto ou ainda sua documentação. Neste
sentido a proposta de STEIN (2002) foi validada. No entanto, há pontos ainda questionados
como a representação dos aspectos em diagramas de colaboração e em diagramas de caso
de uso. Esta representação ainda é obscura na própria tese apresentada por ele, sobre a
Modelagem Orientada a Aspectos.
Mas como já mencionado anteriormente, esta tese é importante para o início do
desenvolvimento de projetos orientados a aspecto, pois aponta fortes padrões de
representação dos aspectos por se basear na linguagem UML.
Esta parte do trabalho apresentou ainda o resultado da implementação, verificando
os pontos de atuação dos aspectos. E esta foi a idéia principal deste trabalho: demonstrar
como a orientação a aspectos é aplicada.
Apesar deste aplicativo se constituir num exemplo simples, ainda é válido porque
pode-se perceber como um interesse do sistema que se queira tratar separadamente é
implementado dentro de um aspecto. E, ainda, a forma como esse aspecto intercepta as
classes bases do sistema.
No próximo capítulo estão anotadas as considerações alcançadas bem como os
trabalhos futuros.
58
5. CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS
Este trabalho buscou validar os conceitos do paradigma orientado a aspectos, dando
continuidade assim aos conceitos estudados durante a disciplina Prática de Sistemas de
Informação I (Estágio), no 1º período do ano de 2004.
A implementação de sistemas de software aponta para a utilização das técnicas
orientadas a aspectos, visto os benefícios já mencionados neste trabalho, o que sugere a
necessidade destes serem projetados com recursos que provêem a representação de
aspectos.
A representação dos aspectos durante a fase de projeto é necessária porque uma
complexidade existente no desenvolvimento orientado a aspectos é identificar em um
sistema qual requisito (funcional ou não-funcional) deve ser separado num aspecto.
Identificando isto na fase de projeto, pode-se realizar uma análise de como será a estrutura
desse aspecto e em que pontos do código deverá atuar. O fato de projetar tal aspecto
garante ainda testar sua relevância para o sistema em geral.
Este trabalho trouxe um exemplo demonstrando um domínio bancário. Os aspectos
implementados neste aplicativo puderam tratar os requisitos não-funcionais, autenticação e
tracing, de forma separada, tanto na fase de projeto, como na implementação. Assim, foi
evitada a repetição destes códigos para os métodos das classes bases Conta e Usuario, caso
contrário haveria uma chamada para cada um desses requisitos em cada método destas duas
classes e cada manutenção necessária teria que ser realizada em todos esses pontos.
59
Como trabalhos futuros, é proposto que seja realizado um estudo em relação à
convergência desta tecnologia com outras também recentes como Web services e Enteprise
Java Beans, identificando assim as vantagens e desvantagens obtidas com a integração de
ambas.
60
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
(COAD et. Al, 1993)
COAD, Peter. YOURDON, Edward. Projetos baseados em
objetos. Rio de Janeiro. Editora Campus, 1993.
61
(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
Computação)
de
Mestrado
(Mestrado
em
Ciência
da
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º
Simpósio Brasileiro de Linguagens de Programação. PUCRio: Rio de Janeiro, 2002.
62
(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)
63
ANEXOS
64
Anexo I - 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
abstrações se relacionam e diagramas apresentam um resumo do conjunto de abstrações e
seus relacionamentos (STEIN, 2002).
A Figura 27 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.
65
Figura 27 - Representação dos pacotes Behavioral Elements, Model Management e Foundation da
especificação UML (OMG, 2000)
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.
Core
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
66
relacionamentos, segundo (BOOCH et Al, 2000), a Figura 28 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.
67
Figura 28- 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.
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).
68
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 29 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 29 - Exemplo de um estereótipo contendo tagged values
69
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.
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.
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
especificadas por meio de mensagens para definir as instâncias (remetente e destinatário)
(STEIN, 2002).
70
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 30, 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.
71
Figura 30 - 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
72
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.
73
Anexo II - Código do Aplicativo
Listagem 1
Conta.java
package pcBanco;
import java.sql.*;
public class Conta {
//Declaração das variáveis
private String numConta;
private double saldo = 0;
DBOperacoes base = new DBOperacoes();
//Construtor
public Conta(int idCliente, String numConta, float saldo)
{
base.criarConta(idCliente, numConta, saldo);
}
public Conta(){}
//Métodos para alterar atributos e estado (set)
public void setNumConta(String aNumConta)
{
this.numConta = aNumConta;
}
public void setSaldo(double aSaldo)
{
this.saldo = aSaldo;
base.setSaldo(this.getSaldo(), this.getNumConta());
}
74
//Métodos para consulta (get)
public String getNumConta()
{
return this.numConta;
}
public double getSaldo()
{
return this.saldo;
}
public boolean transferir(String numContaFav, double valor)
{
if ( this.saldo >= valor){
if(base.transferir( numContaFav, valor )){
this.setSaldo( this.getSaldo() - valor );
return true;
}else{
return false;
}
}else{
return false;
}
}
}
75
Listagem 2
Usuario.java
package pcBanco;
import java.sql.*;
public class Usuario {
//Declaração das variáveis
private String idCliente;
private String Login;
private String Senha;
private String Nome;
private String Telefone;
private String Endereco;
private String Cpf;
private String Rg;
private String Tipo;
DBOperacoes base = new DBOperacoes();
//Métodos para alterar atributos e estado (set)
public void setIdCliente(String idCliente)
{
this.idCliente = idCliente;
}
public void setLogin(String login)
{
this.Login = login;
}
public void setSenha(String senha)
{
this.Senha = senha;
}
public void setNome(String nome)
{
this.Nome = nome;
76
}
public void setTelefone(String telefone)
{
this.Telefone = telefone;
}
public void setEndereco(String endereco)
{
this.Endereco = endereco;
}
public void setCpf(String cpf)
{
this.Cpf = cpf;
}
public void setRg(String rg)
{
this.Rg = rg;
}
public void setTipo(String tipo)
{
this.Tipo = tipo;
}
//Métodos para consulta (get)
public String getIdCliente()
{
return this.idCliente;
}
public String getLogin()
{
return this.Login;
}
public String getSenha()
{
return this.Senha;
}
public String getTipo()
{
return this.Tipo;
77
}
public Conta getConta()
{
try {
Conta temp = new Conta();
ResultSet rs = base.getConta(this.Cpf);
if( rs.next() ){
temp.setNumConta(rs.getString("NumConta"));
temp.setSaldo(rs.getDouble("Saldo"));
}
return temp;
}
catch (Exception e) {
System.err.println("Problemas com SQL");
}
return null;
}
public boolean logar(String login, String senha)
{
try {
ResultSet rs = base.getCliente(login, senha);
if(rs.next()) {
setIdCliente(rs.getString("idCliente"));
setLogin(rs.getString("Login"));
setSenha(rs.getString("Senha"));
setNome(rs.getString("Nome"));
setTelefone(rs.getString("Telefone"));
setEndereco(rs.getString("Endereco"));
78
setCpf(rs.getString("Cpf"));
setRg(rs.getString("Rg"));
setTipo(rs.getString("Tipo"));
return true;
}
}
catch (Exception e) {
System.err.println("Problemas com SQL");
}
return false;
}
public void alterarSenha(String senha, String nova, String
confirma)
{
try {
if (nova.equals(confirma) &&
senha.equals(this.Senha))
{
base.alterarSenha(this.Login, nova);
this.setSenha(nova);
}
else
{
System.out.println("Erro na alteração de
senha...");
}
}
catch (Exception e) {
System.err.println("Problemas com SQL");
}
}
public int cadastrarCliente()
{
79
return base.cadastrarCliente(this.Login, this.Senha,
this.Nome, this.Telefone, this.Endereco, this.Cpf, this.Rg, this.Tipo);
}
public boolean excluirCadastro(String login)
{
return base.excluirCadastro(login);
}
}
80
Listagem 3
DB.java
package pcBanco;
import java.sql.*;
public class DB
{
private Connection con;
private Statement stmt;
private ResultSet rs;
public DB(){ }
public boolean criarConexao()
{
String URL = "jdbc:odbc:Base";
String username = "anonymous";
String password = "guest";
try {
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
System.out.println("Driver carregado");
}
catch (Exception e) {
System.err.println("Falha no carregamento do driver.");
System.exit(0);
}
try{
this.con = DriverManager.getConnection(URL, username,
password);
System.out.println("Conexão Criada");
this.stmt = this.con.createStatement();
System.out.println("Statement Criado");
}
catch (Exception e) {
System.out.println("Problemas na Conexao do banco");
81
System.exit(0);
}
return true;
}
public boolean executarUpdate(String sql){
try
{
this.criarConexao();
this.stmt.executeUpdate(sql);
this.fecharConexao();
}
catch (Exception ex) {
System.out.println("Erro ao executar!!");
return false;
}
return true;
}
public ResultSet executarQuery(String sql){
try
{
this.criarConexao();
this.rs = this.stmt.executeQuery(sql);
this.fecharConexao();
}
catch (Exception ex) {
System.out.println("Erro ao executar!!");
}
return this.rs;
}
public boolean fecharConexao(){
try
82
{
con.close();
}
catch (Exception ex) {
System.out.println("Problemas na Conexao do banco");
System.exit(0);
}
return true;
}
}
83
Listagem 4
DBOperações.java
package pcBanco;
import java.sql.*;
public class DBOperacoes extends DB
{
public DBOperacoes(){}
public void criarConta(int idCliente, String numConta, float saldo)
{
String sql = "Insert Into TabConta(NumConta,Saldo,IdCliente)
values ('" + numConta + "', '" + saldo + "', "+ idCliente +")";
this.executarUpdate(sql);
}
public void setSaldo(double saldo, String numConta)
{
String sql = "Update TabConta Set Saldo = '" + saldo +"'
Where NumConta = '"+ numConta + "'";
this.executarUpdate(sql);
}
public boolean transferir(String numContaFav, double valor)
{
try {
String sql = "Select idCliente From TabConta Where
NumConta = '" + numContaFav + "' ";
ResultSet rs = this.executarQuery(sql);
if( rs.next() ) {
sql = "Update TabConta Set Saldo = Saldo + " +
valor +" Where NumConta = '"+ numContaFav + "'";
84
this.executarUpdate(sql);
}else{
return false;
}
}
catch (Exception e) {
System.err.println("Problemas com SQL");
return false;
}
return true;
}
public ResultSet getConta(String cpf)
{
try {
String sql = "Select c.NumConta, c.Saldo From TabConta
as c, TabUsuario as u Where u.Cpf='"+cpf+"' AND u.idCliente=c.idCliente";
ResultSet rs = this.executarQuery(sql);
return rs;
}catch (Exception e) {
System.err.println("Problemas com SQL");
}
return null;
}
public ResultSet getCliente(String login, String senha)
{
try {
String sql = "Select * From TabUsuario Where Login = '"
+ login + "' and Senha = '" + senha + "'";
ResultSet rs = this.executarQuery(sql);
85
return rs;
}
catch (Exception e) {
System.err.println("Problemas com SQL");
}
return null;
}
public void alterarSenha(String login, String senha)
{
try {
String sql = "Update TabUsuario Set Senha = '" + senha
+"' Where Login = '"+ login + "'";
this.executarUpdate(sql);
}
catch (Exception e) {
System.err.println("Problemas com SQL");
}
}
public int cadastrarCliente(String Login, String Senha, String Nome,
String Telefone, String Endereco, String Cpf, String Rg, String Tipo)
{
try {
String sql;
sql = "Insert Into TabUsuario(Login, Senha, Nome,
Telefone, Endereco, Cpf, Rg, Tipo) ";
sql = sql + "values ('" + Login + "', '" + Senha + "', '" +
Nome;
sql = sql + "', '"+ Telefone + "','"+ Endereco + "' , '" +
Cpf + "', '" + Rg + "', '" + Tipo + "')";
86
this.executarUpdate(sql);
sql = "Select * from TabUsuario where Login='"+ Login +"'";
ResultSet rs = this.executarQuery(sql);
if(rs.next()){
return rs.getInt("IdCliente");
}
}
catch (Exception e) {
System.err.println("Problemas com SQL");
}
return 0;
}
public boolean excluirCadastro(String login)
{
try {
String sql = "Delete * From tabUsuario Where Login = '" +
login + "' ";
this.executarUpdate(sql);
return true;
}
catch (Exception e) {
System.err.println("Problemas com SQL");
}
return false;
}
}
Listagem 5
Banco.java
87
package pcBanco;
import javax.swing.*;
public class Banco {
public static void main(String args[])
{
//Declaração das variáveis
int menu,aux;
String login, senha, conta, contaFav;
double valor;
//Instanciação
Usuario u = new Usuario();
Conta c = null;
//Logar
u.setLogin(JOptionPane.showInputDialog("Login:"));
u.setSenha(JOptionPane.showInputDialog("Senha:"));
if (u.logar(u.getLogin(), u.getSenha()))
{
c = u.getConta();
Trace.trace = 2;
Trace.initStream(System.err);
do
{
//Verificação de tipo do usuário
if (u.getTipo().equals("Adm"))
{
// Se o usuário é administrador
menu=Integer.parseInt(JOptionPane.showInputDialog("\n 1 - Ver saldo
\n 2 - Transferir \n 3 - Alterar senha \n 4 - Cadastrar clientes \n 5 Excluir clientes \n 0 - Finalizar operação "));
}
88
else
{
// Se o usuário é Cliente
menu=Integer.parseInt(JOptionPane.showInputDialog("\n 1 - Ver saldo
\n 2 - Transferir \n 3 - Alterar senha \n 0 - Finalizar Operação "));
}
//Tratamento do menu
if(menu == 0)
{
int cod =
JOptionPane.showConfirmDialog(null,"Deseja finalizar a operação?");
if (cod == 0)
System.exit(0);
menu = 0;
}
if(menu==1)
{
//Ver saldo
JOptionPane.showMessageDialog(null,"Saldo Disponível: " +
c.getSaldo());
}
if(menu==2)
{
//Transferir
contaFav =
JOptionPane.showInputDialog("Conta do favorecido:");
valor =
Double.parseDouble(JOptionPane.showInputDialog("Valor de
transferência:"));
89
if (c.transferir(contaFav, valor))
JOptionPane.showMessageDialog(null,"Operação realizada.");
else
JOptionPane.showMessageDialog(null,"Operação não realizada.");
}
if(menu==3)
{
//Alterar
String nova, confirma;
senha = JOptionPane.showInputDialog("Senha
atual:");
nova = JOptionPane.showInputDialog("Nova
senha:");
confirma =
JOptionPane.showInputDialog("Confirma nova senha:");
u.alterarSenha(senha, nova,
confirma);
}
if(menu==4)
{
//Cadastro
Usuario t = new Usuario();
t.setLogin(JOptionPane.showInputDialog( "Login:"));
t.setSenha(JOptionPane.showInputDialog( "Senha:"));
t.setNome(JOptionPane.showInputDialog( "Nome:"));
t.setTelefone(JOptionPane.showInputDialog( "Telefone:"));
t.setEndereco(JOptionPane.showInputDialog( "Endereço:"));
90
t.setCpf(JOptionPane.showInputDialog(
"CPF:"));
t.setRg(JOptionPane.showInputDialog(
"Rg:"));
t.setTipo(JOptionPane.showInputDialog( "Tipo:"));
Conta ct = new Conta();
ct.abrirConta(t.cadastrarCliente(),
JOptionPane.showInputDialog( "Número da Conta:"),
Float.parseFloat(JOptionPane.showInputDialog("Saldo:")));
}
/*if(menu==5)
{
}*/
if(menu==6)
{
login =
JOptionPane.showInputDialog("Login:");
if (u.excluirCadastro(login))
JOptionPane.showMessageDialog(null,"Cadastro excluído!");
else
JOptionPane.showMessageDialog(null,"Cadastro inexistente!");
}
}while(menu != 0); //fim da condição
}//fim condicional do login e senha
else
JOptionPane.showMessageDialog(null,"Login ou senha incorretos!");
}//fim main
91
}
Listagem 6
package pcbanco;
import java.io.PrintStream;
Trace.java
92
public class Trace {
public static int trace = 0;
protected static PrintStream stream = null;
protected static int callDepth = 0;
public static void initStream(PrintStream s) {
stream = s;
}
public static void traceEntry(String str) {
if (trace == 2) callDepth++;
printEntering(str);
}
public static void traceExit(String str) {
printExiting(str);
if (trace == 2) callDepth--;
}
private static void printEntering(String str) {
printIndent();
stream.println("--> " + str);
}
private static void printExiting(String str) {
printIndent();
stream.println("<-- " + str);
}
private static void printIndent() {
for (int i = 0; i < callDepth; i++)
stream.print("
}
}
");
93
Listagem 7
package pcbanco;
Tracing.aj
94
public aspect tracing {
declare precedence: tracing, aspecto;
pointcut classe(): within(Conta) || within(Usuario);
before (): (
(execution(public boolean logar(..))) ||
(execution(public double leSaldo(..))) ||
(execution(public boolean transferir(..))) ||
(execution(public int cadastrarCliente(..))) ||
(execution(public int alterarCadastro(..))) ||
(execution(public void alterarSenha(..))) ||
(execution(public boolean excluirCliente(..)))
)
{
Trace.traceEntry("" + thisJoinPointStaticPart.getSignature());
}
after(): (
(execution(public boolean logar(..))) ||
(execution(public double leSaldo(..))) ||
(execution(public boolean transferir(..))) ||
(execution(public int cadastrarCliente(..))) ||
(execution(public int alterarCadastro(..))) ||
(execution(public void alterarSenha(..))) ||
(execution(public boolean excluirCliente(..)))
)
{
Trace.traceExit("" + thisJoinPointStaticPart.getSignature());
}
}
Listagem 8
Package pcbanco;
import java.sql.*;
Aspecto.aj
95
import javax.swing.*;
public aspect aspecto {
declare precedence: tracing, aspecto;
//Variáveis para a conexão com a base de dados
Statement stmt = null;
Connection con = null;
before(): (
(call(public double leSaldo(..))) ||
(call(public boolean transferir(..))) ||
(call(public int cadastrarCliente(..))) ||
(call(public int alterarCadastro(..))) ||
(call(public boolean excluirCliente(..)))
)
{
String senha = JOptionPane.showInputDialog("Senha:");
System.out.println("Iniciando aspecto de autenticação");
String URL = "jdbc:odbc:Base";
String username = "anonymous";
String password = "guest";
try {
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
System.out.println("Driver carregado");
}
catch (Exception e) {
System.err.println("Falha no carregamento do driver.");
System.exit(0);
}
try{
con = DriverManager.getConnection(URL, username, password);
System.out.println("Conexão Criada");
stmt = con.createStatement();
System.out.println("Statement Criado");
96
}
catch (Exception e) {
System.out.println("Problemas na Conexao do banco");
}
try {
Object o;
String sql = "Select * From TabUsuario ";
sql = sql + "Where Senha = '" + senha + "'";
ResultSet rs = stmt.executeQuery(sql);
if(rs.next()){
if (senha.equals(rs.getString("Senha")))
System.out.println("Senha correta.");
}
else{
JOptionPane.showMessageDialog(null,"Operação não
realizada! Senha incorreta.");
System.exit(0);
}
con.close();
}
catch (Exception e) {
System.err.println("Problemas com SQL");
}
System.out.println("Finalizando aspecto de autenticação");
}
}