ELAINE DA SILVA MONTEIRO. Implementação de um Aplicativo Utilizando AODM, Java e AspectJ

Transcrição

1 ELAINE DA SILVA MONTEIRO Implementação de um Aplicativo Utilizando AODM, Java e AspectJ Palmas TO 2004

2 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

3 iii ELAINE DA SILVA MONTEIRO Implementação de um Aplicativo Utilizando AODM, Java e AspectJ Aprovada em Dezembro de 2004 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 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

4 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

5 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!!!

6 i SUMÁRIO 1. INTRODUÇÃO Objetivos do trabalho Organização do trabalho REVISÃO DE LITERATURA Programação Orientada a Aspectos AspectJ Join points Pointcuts Advices Introductions Aspects Modelagem Orientada a Aspectos Representando construções do AspectJ em UML Join points Pointcuts Advices Introductions Aspects Considerações MATERIAIS E MÉTODOS Local e Período... 22

7 ii 3.2 Materiais Hardware Software Fontes Bibliográficas Metodologia RESULTADOS E DISCUSSÕES Modelagem do aplicativo Requisitos do Sistema Casos de Uso Ver saldo Transferir Cadastrar clientes Alterar senha Excluir clientes Encerrar logon Diagrama de Caso de uso Diagramas de Seqüência de Análise Ver saldo Transferir Cadastrar Clientes Alterar senha Excluir cliente Encerrar logon Contratos Ver saldo Logar Validar usuário Escolher opção Exibir saldo... 36

8 iii Transferir Logar Validar usuário Escolher opção Solicita Dados Fornece dados Valida Dados Transfere valores Cadastrar clientes Logar Validar usuário Escolher opção Solicita dados Fornece Dados Valida Dados Cadastrar Cliente Alterar senha Logar Validar usuário Escolher opção Solicitar nova senha Inserir nova senha Confirmar senha Confirma Senha Validar dados Alterar Senha Excluir clientes Logar Validar usuário Escolher opção Identifica cliente... 45

9 iv Exclui cadastro Encerrar logon Escolher opção Finaliza Sessão Diagramas de Seqüência de Projeto Ver saldo Transferir Cadastrar clientes Alterar senha Excluir clientes Encerrar logon Diagrama de Classes Implementação do aplicativo Considerações CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS ANEXOS... 63

10 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 Figura 5 - Estereótipo <<Pointcut>> para operação (STEIN, 2002) Figura 6 - Estrutura de um advice Figura 7 - Estereótipo <<Advice>> para operação (STEIN, 2002) Figura 8 - Estereótipo <<Introduction>> para operação (STEIN, 2002) Figura 9 - Estereótipo <<Aspect>> para classe (STEIN, 2002) Figura 10 Diagrama de Caso de uso para o aplicativo bancário Figura 11 Diagrama de seqüência de análise Ver saldo Figura 12 Diagrama de seqüência de análise Transferir Figura 13 Diagrama de seqüência de análise Cadastrar clientes Figura 14 Diagrama de seqüência de análise Alterar senha Figura 15 Diagrama de seqüência de análise Excluir cliente Figura 16 Diagrama de seqüência de análise Encerrar logon Figura 17 Diagrama de seqüência de projeto Ver saldo Figura 18 Diagrama de seqüência de projeto Transferir Figura 19 Diagrama de seqüência de projeto Cadastrar clientes Figura 20 Diagrama de seqüência de projeto Alterar Senha Figura 21 Diagrama de seqüência de projeto Excluir clientes Figura 22 Diagrama de seqüência de projeto Encerrar logon Figura 23 Diagrama de classes para o aplicativo bancário Figura 24 Tela do Administrador do sistema Figura 25 Exemplo da execução do método versaldo Figura 26 Exemplo da execução do método cadastrarcliente Figura 27 - Representação dos pacotes Behavioral Elements, Model Management e Foundation da especificação UML (OMG, 2000)... 65

11 vi Figura 28- Diagrama de Classes para o domínio Bancário Figura 29 - Exemplo de um estereótipo contendo tagged values Figura 30 - Diagrama de Seqüência para o domínio Bancário... 71

12 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

13 viii Lista de Abreviaturas AODM AOP SOP UML AJDT Aspect Oriented Design Model Aspect Oriented Programming Subject-Oriented Programming Unified Modeling Language AspectJ Development Tools

14 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

15 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

16 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

17 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 a Modelagem Orientada a Aspectos (Aspect-Oriented Design Model AODM). Ela estende a UML (Unified Modeling Language) com recursos capazes de representar os efeitos causados por interesses multidimensionais. 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.

18 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

19 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:

20 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

21 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. Componentes Programa 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 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

22 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) 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).

23 8 Tabela 1: PCDs baseados no tipo do join point (JP) PCD Call(<ass. De método>) Execution(<ass. De método>) Get(<ass. De atributo>) Set(<ass. De atributo>) Handler(<tipo exceção>) Initialization(<ass.construtor>) StaticInitialization(<tipo>) Pontos de junção selecionados Quando o método é chamado Quando o método é executado Quando o atributo é acessado Quando o atributo é alterado Quando a exceção é tratada Quando o construtor é executado Quando a inicialização de classe é executada Tabela 2: PCDs baseados na propriedade do join point (JP) PCD Within(Tipo) Withincode(Método) Cflow(Pointcut) Cflowbelow(Pointcut) This(Tipo) Target(Tipo) Args(Tipo,...) If(ExpressãoLógica) Pontos de junção selecionados Qualquer JP que ocorra na classe Qualquer JP que ocorra no método/construtor Qualquer JP que ocorra no contexto de um JP selecionado pelo PCD Idem ao anterior, excluindo os JPs selecionados pelo próprio PCD Qualquer JP que ocorra em um objeto da classe Quando o objeto alvo do call/get/set é da classe Quando os argumentos são do tipo especificado Quando a expressão é verdadeira Assim: Os pointcuts suportam os símbolos*,+,..,. para a especificação de um join point. 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>;

24 9 (&&,, e!). Um pointcut pode ser aninhado em outro pointcut com os operadores e, ou e não 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 eafter. 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) 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).

25 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 Representando construções do AspectJ em UML 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:

26 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).

27 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 eget. 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) 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

28 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): ((execution(*tranferir(..))&&target(c) Assinatura 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.

29 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

30 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 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.

31 16 UML. A Figura 7 mostra como o estereótipo <<advice>> é representado no meta-modelo 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 estereótipo <<containsweavinginstructions>>. Os meta-atributos isroot e isleaf devem ser true e o meta-atributo isabstract deve ser false, isso porque um advice não pode ser abstrato e nem ser cancelado. Ele sempre traz um código a ser executado em algum ponto da aplicação demarcado por um conjunto de join points. Esses meta-atributos fazem parte da especificação de uma operação no meta-modelo UML e estão presentes porque o advice é representado como um estereótipo de uma operação 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

32 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 metamodelo UML:

33 18 Figura 8 - Estereótipo <<Introduction>> para operação (STEIN, 2002) 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 pode ter somente os valores para instâncias apresentados na Tabela 3 (STEIN, 2002).

34 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 booleanostrue efalse. Abaixo, na Figura 9, segue-se a representação para o estereótipo aspect, no metamodelo UML.

35 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.

36 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.

37 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.

38 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); 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 Fontes Bibliográficas Teses de Mestrados; Publicações Científicas; Artigos; Site do AspectJ (AspecJ, 2004); Sites diversos. 3.3 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.

39 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 Modelagem do aplicativo 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;

40 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 Casos de Uso 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

41 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 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 Cadastrar clientes Caso de uso: Cadastrar clientes Atores: Administrador Finalidade: Realizar cadastro de clientes

42 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 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.

43 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 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.

44 Diagrama de Caso de uso Figura 10 Diagrama de Caso de uso para o aplicativo bancário

45 Diagramas de Seqüência de Análise Ver saldo Figura 11 Diagrama de seqüência de análise Ver saldo

46 Transferir Figura 12 Diagrama de seqüência de análise Transferir

47 Cadastrar Clientes Figura 13 Diagrama de seqüência de análise Cadastrar clientes

48 Alterar senha Figura 14 Diagrama de seqüência de análise Alterar senha

49 Excluir cliente Encerrar logon Figura 15 Diagrama de seqüência de análise Excluir cliente Figura 16 Diagrama de seqüência de análise Encerrar logon

50 Contratos Ver saldo 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: 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: 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: -

51 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: Transferir 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: 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: -

52 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: 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: 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: -

53 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: 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 Cadastrar clientes 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: -

54 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: 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: 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: -

55 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: 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: 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