A IMPORTÂNCIA DOS REQUISITOS NÃO FUNCIONAIS NO DESENVOLVIMENTO DE UM SISTEMA ORIENTADA A ASPECTO

Transcrição

1 UNIVERSIDADE DO PLANALTO CATARINENSE CURSO DE SISTEMAS DE INFORMAÇÃO (BACHARELADO) JOSÉ AUGUSTO ZANOTTO FRANKLIN A IMPORTÂNCIA DOS REQUISITOS NÃO FUNCIONAIS NO DESENVOLVIMENTO DE UM SISTEMA ORIENTADA A ASPECTO LAGES (SC) ANO

2 JOSÉ AUGUSTO ZANOTTO FRANKLIN A IMPORTÂNCIA DOS REQUISITOS NÃO FUNCIONAIS NO DESENVOLVIMENTO DE UM SISTEMA ORIENTADA A ASPECTO Trabalho de Conclusão de Curso submetido à Universidade do Planalto Catarinense para obtenção dos créditos de disciplina com nome equivalente no curso de Sistemas de Informação - Bacharelado. Orientação: Prof(ª). Hugo Estevam Longo, Esp. LAGES (SC) ANO

3 JOSÉ AUGUSTO ZANOTTO FRANKLIN A IMPORTÂNCIA DOS REQUISITOS NÃO FUNCIONAIS NO DESENVOLVIMENTO DE UM SISTEMA ORIENTADA A ASPECTO ESTE RELATÓRIO, DO TRABALHO DE CONCLUSÃO DE CURSO, FOI JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS DA DISCIPLINA DE TRABALHO DE CONCLUSÃO DE CURSO, DO 8º. SEMESTRE, OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE: BACHAREL EM SISTEMAS DE INFORMAÇÃO Lages (SC), 23 de agosto de 2015 Prof. Hugo Estevam Longo, Esp. Orientador BANCA EXAMINADORA: Prof. Madalena Pereira da Silva, Msc. UNIPLAC Prof. Claiton Camargo de Souza. UNIPLAC Prof. Claiton Camargo de Souza. Coordenador de Curso Prof. Madalena Pereira da Silva, Msc. Professora de TCC

4 Dedico esse trabalho e todos que me apoiaram para que sempre progredisse no curso e todos que auxiliaram na conclusão desse trabalho. Em especial a minha família. 3

5 LISTA DE ILUSTRAÇÕES FIGURA 1 - Ideia geral do trabalho proposto FIGURA 2 - Abstração do encapsulamento de um caixa eletrônico FIGURA 3 - Método sacar FIGURA 4 - Diagrama UML de classes que (relacionamentos de herança) FIGURA 5 - Exemplo de polimorfismo FIGURA 6 - Exemplo de chamada de polimorfismo FIGURA 7 - Problemas de espalhamento e entrelaçamento causadas pela OO FIGURA 8 - Exemplo para demonstrar o entrelaçamento de código FIGURA 9 - Manutenção transversais FIGURA 10 - Distribuição dos registros de log no Tomcat FIGURA 11 - Aplicação bancária com o método de transferência de valores FIGURA 12 - Versão simplificada com novos objetivos (concerns) FIGURA 13 - Código do negócio (sincronização de objetos concorrentes) FIGURA 14 - Combinação de um processo weaving FIGURA 15 - Relação entre Aspectos, components e pontos de junção FIGURA 16 - Decomposição relacionado a separação de interesses FIGURA 17 - Exemplo de mais de um ponto de junção para um ponto de função.. 37 FIGURA 18 - Exemplo de advice do tipo around FIGURA 19 - Exemplo de args FIGURA 20 - Implementação de ponto de corte FIGURA 21 - Ponto de corte call FIGURA 22 - Weaver fazendo a mesclagem dos módulos FIGURA 23 - Estratégia de Elicitação de Requisitos Não Funcionais FIGURA 24 - Checklist de RNFs FIGURA 25 - Caso de Uso FIGURA 26 - Requisitos funcionais versus Casos de uso FIGURA 27 - RNF versus Casos de uso FIGURA 28 - Diagrama de classe FIGURA 29 - Diagrama de Atividade da Função Saque FIGURA 30 - Diagrama de Sequência Função Saque FIGURA 31 - Diagrama de Atividade da Função Depósito FIGURA 32 - Diagrama de Sequência da Função Depósito FIGURA 33 - Diagrama de Atividade Função Transferência FIGURA 34 - Diagrama de Sequência Função Transferência FIGURA 35 - Diagrama de Atividade Consulta Extrato FIGURA 36 - Diagrama de Sequência Consulta Extrato FIGURA 37 - Interface Login FIGURA 38 - Interface Operações

6 FIGURA 39 - Interface Confirma Saque\Transferênci FIGURA 40 - Interface Saque FIGURA 41 - Interface Transferência FIGURA 42 - Interface Depósito FIGURA 43 - Interface Extrato FIGURA 44 - Estrutura do projeto FIGURA 45 - Classe Comuns FIGURA 46 - Métodos classe Conta FIGURA 47 - Classe repositório FIGURA 48 - JSON e XML FIGURA 49 - Classe Transações FIGURA 50 - Classe static Static FIGURA 51 - Classe Traces FIGURA 52 - Classe Program FIGURA 53 - Método de validação de conta FIGURA 54 - Método LoadAccount() (logout) FIGURA 55 - Método LoadAccount() (SetDeposit) FIGURA 56 - Método LoadAccount() (SetTransfer) FIGURA 57-7Método LoadAccount() (GetBalance) FIGURA 58 - Método LoadAccount() (SetWithdraw) FIGURA 59 - Etapas de Desenvolvimento de Software Orientado a Aspectos FIGURA 60 - Estrutura de projeto com implementação de aspecto FIGURA 61 - Biblioteca PostSharp FIGURA 62 - Implementação aspecto de segurança FIGURA 63 - Aspecto Segurança FIGURA 64 - Advice Log FIGURA 65 - Advice Exception FIGURA 66 - Advice Security FIGURA 67 - Exemplo de Pointcuts FIGURA 68 - Aspecto inserido no fluxo principal FIGURA 69 - Tela de login do protótipo FIGURA 70 - Tela Operações Protótipo FIGURA 71 - Operação Saque Protótipo FIGURA 72 - Operação Saque Protótipo FIGURA 73 - Operação deposito Protótipo FIGURA 74 - Operação Transferência Protótipo FIGURA 75 - Confirmação transferência Protótipo FIGURA 76 - Operação extrato Protótipo QUADRO 1 - Comparativo entre código espalhado e código emaranhado QUADRO 2 - As três variações possíveis de advice after QUADRO 3 - Linguagens POA QUADRO 4 - Autenticação da conta QUADRO 5 - Efetuar Saque QUADRO 6 - Efetuar Depósito

7 QUADRO 7 - Efetuar Transferência QUADRO 8 - Emitir Extrato QUADRO 9 - Verificação de transferência QUADRO 10 - Validação de saldo para saque QUADRO 11 - Verificação de saldo para transferência QUADRO 12 - Validação de conta destino QUADRO 13 - Validação de valor para transferência QUADRO 14 - Validação de saldo para saque QUADRO 15 - Validação de conta QUADRO 16 - Requisitos não funcionais QUADRO 17 - Comparação entre a quantidade de linhas implementadas

8 LISTA DE ABREVIATURAS E SIGLAS AJAX DSOA DSOO HTML IA JSON LAL OA OO POA POO PU RNF RUP SOAP UdI UML XML XHTML - Asynchronous Javascript and XML - Desenvolvimento de Software Orientado a Aspectos - Desenvolvimento de Software Orientado a Objetos - HyperText Markup Language - Inteligência Artificial - JavaScript Object Notation - Léxico Ampliado da Linguagem - Orientação a Aspecto - Orientado a Objeto - Programação Orientada a Aspecto - Programação Orientada a Objeto - Processo Unificado - Requisito Não Funcional - Rational Unified Process - Simple Object Access Protocol - Universo de Informações - Unified Modeling Language - extensible Markup Language - extensible Hypertext Markup Language

9 RESUMO Durante anos, os engenheiros de softwares lutam quanto à estruturação de códigos, a fim de maximizar sua reutilização e diminuir o risco de defeitos. Enquanto a Programação Orientada a Objeto (POO) fornece uma estrutura sólida para a organização de códigos, acaba apresentando dificuldades para reutilizar características transversais, levando a duplicações desnecessárias de códigos e a um aumento de erros na fase de produção, causando uma diminuição na qualidade e tempo de mercado. O trabalho proposto tem por objetivo apresentar essa nova ideia de Programação Orientada a Aspecto (POA) o qual seu objetivo se define em separar os níveis de preocupação durante o desenvolvimento de software. A metodologia consistiu numa revisão bibliográfica sobre o tema e a programação de um sistema com uso dos conceitos de POO, onde constatou-se que é possível pensar separadamente nos problemas referentes as camadas do sistema. Para facilitar o levantamento destas características transversais, se torna viável basear-se pelos requisitos não funcionais, visto que os mesmos são de impacto em várias camadas do sistema, pois tratam especificamente de particularidades relacionadas ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade e manutenibilidade. A refatoração da POA é dividida em 3 fases sendo elas a decomposição, implementação e recomposição. Para demonstrar a eficácia da POA, o trabalho consistiu no desenvolvimento de um sistema de caixa eletrônico, o qual apresenta uma solução em POO, e sua refatoração em POA, facilitando a identificação de pontos fortes na utilização desse novo conceito. Como considerações destaca-se que a POA, não deve ser pensada como um novo padrão de programação, e sim como um complemento para a POO, visto que trata de preocupações diferentes, tendo como seu objetivo facilitar a reutilização de códigos, deixando assim com uma estrutura de fácil manutenção, entendimento e com maior facilidade de evolução devido sua facilidade de reutilização de códigos. 8

10 ABSTRACT Over the years, software engineers struggle as the code structure in order to maximize reuse and reduce the risk of defects. While the Object Oriented Programming (OOP) provides a solid framework for the organization of code, just presenting difficulties to reuse crosscutting, leading to unnecessary duplication of code and an increase of errors in the production phase, causing a decrease in the quality and time to market. The proposed work aims to present this new idea of Aspect Oriented Programming (AOP) which your goal is defined in separating the levels of concern during the software development. The methodology consisted of a literature review on the topic and programming a system with use of the concepts of the POA. During the research, it was found that it is possible to consider separately the problems related to the storage of data, business modelling, security, distribution audit log records etc. To facilitate the lifting of these crosscutting, it becomes feasible based on the non-functional requirements, as they are impact in various system layers, as specifically deal with particulars related to the use of the application in terms of performance, usability, reliability, security, availability, maintainability, as well as the technologies involved. The POA is divided into three phases and they decay, implementation and recovery. To demonstrate the effectiveness of POA, work was the development of an ATM system, which presents a solution in OOP, and a refactoring POA, facilitating the identification of the strengths using this new concept. As considerations it is emphasized that the POA should not be thought of as a new standard of programming, but as a complement to OOP, since dealing with different concerns, having as its objective to facilitate the reuse of code, leaving with a structure easy to maintain, and easier understanding of evolution due to its ease of code reuse. Keywords: Aspecto, Programação Orientada a Aspecto, Requisitos Não Funcionais.

11 SUMÁRIO 1 INTRODUÇÃO Apresentação Descrição do problema Justificativa Objetivo geral Objetivos específicos Metodologia REVISÃO BIBLIOGRÁFICA Desenvolvimento de software Programação Orientada a Objetos Encapsulamento Herança Polimorfismo Dificuldades encontradas na POO Entrelaçamento do Código (Tangled Code) Espalhamento do Código (Scattering Code) Programação Orientada a Aspectos Conceitos Fundamentais sobre a Programação Orientada a Aspectos Motivação (Importância da POA) Sincronização de Objetos Concorrentes Conceitos e Terminologias Problemas na utilização da POA Benefícios da Programação Orientada a Aspectos Linguagens que implementam POA Requisitos do sistema Requisitos Funcionais Requisitos Não Funcionais Estratégia para licitar Requisitos Não Funcionais Como identificar requisitos não funcionais Conclusões do capítulo MODELAGEM DO SISTEMA Processo unificado: UML Descrição do estudo de caso Caso de uso... 50

12 3.2.1 Diagrama de caso de uso Levantamento de Requisitos Requisitos Funcionais Requisitos Não funcionais Diagrama de classe Operações Função Saque: Função Depósito Função Transferência Consulta Extrato Prototipação de interface Considerações finais DESENVOLVIMENTO Tecnologias utilizadas XML JSON PostSharp Programação Orientada a Objetos Programação Orientada a Aspectos Diferencial entre a programação orientada a aspecto sobre a orientada a objeto APRESENTAÇÃO DO SISTEMA CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS

13 1 INTRODUÇÃO 1.1 Apresentação A Programação Orientada a Objetos (POO) é o padrão mais utilizado entre a comunidade científica, acadêmica e comercial. Sua estrutura é baseada na geração de objetos, formando uma estrutura organizada que limita o uso, a inserção e a alteração das informações contidas nesses objetos, devendo seguir suas regras de classe em que o objeto esteja incluso. De acordo com estudos realizados, pode-se afirmar que a POO foi o primeiro método que permitiu a herança de atributos e objetos de classes ditas superclasses para outras classes criadas que necessitam dessas operações, chamadas subclasses, o que ajuda a reutilização de código. Além da herança, a POO permitiu o uso do polimorfismo para permitir que funcionalidades sejam dinamicamente selecionadas durante a execução dos programas. Diante do exposto fica claro que a POO apresenta um grande papel no processo de evolução no desenvolvimento de softwares, porém mesmo com todas as funcionalidades exploradas, existem algumas dificuldades são existentes na formação de uma aplicação, como o caso das características transversais, que conforme o próprio nome diz, são métodos que atravessam toda a estrutura dos softwares, causando assim um acúmulo de códigos duplicados, ilegibilidade, dificuldades e auto custo de manutenção. Normalmente os interesses transversais estão associados a requisitos não funcionais, onde estes resultam em um conjunto de aspectos (crosscutting, concerns) relacionados às propriedades que afetam o comportamento do sistema. Com o uso da abordagem, os requisitos não funcionais podem ser facilmente manipulados sem causar 9

14 impacto no código de negócio (requisitos funcionais), uma vez que estes códigos não estão entrelaçados e espalhados em várias unidades do sistema. Desta forma, a Programação Orientada a Aspecto (POA) possibilita o desenvolvimento de programas utilizando tais aspectos, o que inclui isolamento, composição e reuso de códigos de implementação dos aspectos. A POA por ser um objeto de estudo recente, está sendo muito abordada por engenheiros de software, pesquisadores e programadores interessados em utilizar essa técnica que busca reduzir a complexidade e aumentar a produtividade no desenvolvimento de software. A (OO) é um método eficaz até certo ponto, pois, precisava de uma evolução que não foi obtida, o encapsulamento dos requisitos que produzem efeitos em todo o sistema, não passou por revisões e adaptações profundas nas suas descrições. Por isso, a Orientação a Aspectos (OA) ganhou força na comunidade científica e tecnológica como a provável solução para essa brecha deixada pela (OO), com certa eficácia na mudança de pensamento e do conhecimento na área de desenvolvimento de sistemas. Muitas empresas têm incorporado rapidamente a OA por não exigir nenhuma adaptação de seus equipamentos e ser de fácil compreensão aos desenvolvedores e testadores de software. O presente estudo contemplou os seguintes capítulos: Capítulo 1 foi apresentado o projeto do trabalho, ou seja, definição do problema, justificativa, objetivos e metodologia. O segundo capitulo se aprofundou no estudo de viabilidade através do levantamento bibliográfico, abordando os temas referente aos paradigmas de programação (OO) e (OA), e também formas de licitação de requisitos não funcionais. No terceiro capítulo, foi apresentado a modelagem do sistema. No quarto capitulo foi realizado o desenvolvimento de um sistema (OO), refatorando em uma solução (OA), apresentando com tudo um comparativo com as devidas vantagens e desvantagens existentes na (POA) sobre a (POO). O quinto capítulo tratou-se de uma apresentação do sistema com suas formas de utilização e no capítulo final apresentou-se a conclusão geral do trabalho. 1.2 Descrição do problema 10

15 Nos dias atuais existe uma grande dificuldade no controle de características transversais o que acaba deixando um emaranhado de código espalhado por todo o sistema, tornando cada vez mais difícil de controlar, modificar e reutilizar estas características em comum, aumentando assim o custo de seu desenvolvimento. Neste caso, será que com o uso da (POA) será possível resolver as dificuldades levantadas? 1.3 Justificativa Durante anos, os engenheiros de softwares lutam quanto à estruturação de códigos, a fim de maximizar sua reutilização e diminuir o risco de defeitos de um sistema. Enquanto a POO fornece uma estrutura sólida para a organização de códigos, acaba apresentando dificuldades para reutilizar características transversais, levando a duplicações desnecessárias de códigos, e aumentando os erros na fase de produção, causando uma diminuição na qualidade do produto, com perda de atuação no mercado. O modelo utilizado na POO para a formação de classes acaba não se preocupando com estas características transversais, deixando o código com uma estrutura difícil ou até mesmo impossível de se realizar uma centralização de código em um único lugar de forma efetiva. Esse formato de desenvolvimento resulta em problemas associados a uma fraca separação de interesses, impactando em uma evolução cara e difícil com baixo reuso, além de integração complicada e software muito sensível a alterações de características por conta da rastreabilidade dos impactos. A programação Orientada a Aspecto tem este objetivo, tentar separar os níveis de preocupação durante o desenvolvimento de software. Logo seria possível pensar separadamente nos problemas referentes à persistência dos dados, modelagem de negócios, segurança, distribuição auditoria, registros de logs etc. A proposta é poder desenvolver as partes do sistema sem se preocupar com as demais partes. A cada iteração da integração insere-se um novo nível de preocupação sem ser necessário alterar o que já esta pronto. (KICZALES et al. 1997, P. 12). Desta forma este TCC visa utilizar a POA para mostrar a separação dessas funcionalidades ortogonais através da geração de aspectos. Será comparado a construção de um sistema sem a valorização destes artefatos versus um sistema preocupado com as 11

16 características transversais, partindo da modelagem do sistema até a formação de aspectos, tornando assim, um sistema com código mais legível e de fácil manutenção, trazendo como benefício um aumento na produtividade em relação a reutilização de classe, e com um processo mais eficiente para a formação de novos softwares. Como os aspectos têm a propriedade de permitir a alteração do funcionamento do software de maneira não invasiva, espera-se conseguir uma abordagem que faça com que a linha de produtos de software possa crescer incrementalmente com o tempo. Essa seria uma grande vantagem para as linhas de produtos, já que uma das preocupações e desvantagens no seu desenvolvimento é o alto esforço inicial de trabalho investido (PACIOS, 2006, p. 3). A POA é um paradigma de programação relativamente novo e significativo para a comunidade de software, o qual surgiu para complemento do paradigma da POO. Como já dito, a POO apresenta dificuldades na separação de interesses em algumas circunstâncias como por exemplo, os requisitos não funcionais (KICZALES et al., 1997). A principal função da POA é identificar os interesses transversais e em que ponto do código eles serão utilizados, normalmente os interesses transversais estão associados a requisitos não funcionais. Tentar focar nas soluções que a POA traz para colocar na justificativa (GROVES, 2013). Por ser uma abordagem incremental, reduz-se a carga de trabalho necessária no início da produção da linha de produtos. Isso é conseguido graças à utilização de aspectos. Com isso, tem-se as vantagens de linhas de produtos ao mesmo tempo amenizando a desvantagem do risco do alto investimento inicial não ter o retorno esperado (PACIOS, 2006, p. VII). 1.4 Objetivo geral Realizar um estudo para demonstrar as vantagens inerentes na (POA), levando em consideração os requisitos não funcionais para geração dos aspectos. 1.5 Objetivos específicos a) Realizar um estudo de conceito sobre a POA; 12

17 b) Estudar as abordagens utilizadas para estender a modelagem de requisitos para tratar de interesses transversais para o desenvolvimento de aspectos; c) Demonstrar com um exemplo a metodologia POO; d) Refatorar o exemplo utilizando o contexto de aspectos para demonstrar suas vantagens. 1.6 Metodologia A primeira parte do trabalho consistiu no pré projeto, onde foi realizado um levantamento bibliográfico através de livros e materiais disponíveis na Internet quanto a viabilidade da utilização da (POA) para o desenvolvimento de um sistema, identificando qual a sua importância, diferencial e sua aplicabilidade. Após foi descrito um levantamento teórico embasado nos estudos realizados no levantamento bibliográfico, seguindo para uma terceira parte o qual foi verificado como modelar a aplicação e realizar a separação de interesses através da divisão dos requisitos não funcionais, a fim de alcançar o nível de abstração de dados para formação dos aspectos. Na quarta etapa foi desenvolvido um exemplo utilizando o paradigma (OO), para que esse exemplo seja transformando em uma solução orientada a aspecto, apresentando então seu diferencia, vantagens e desvantagens da (POA) sobre a (POO). Na sequência, foi apresentado o modo de operação do sistema proposto, finalizando com o próximo capitulo o qual expos uma conclusão do trabalho. 13

18 2 REVISÃO BIBLIOGRÁFICA A Figura 1 apresenta um esboço quanto a estruturação desse trabalho, Onde Durante o próximo capítulo será iniciado a contextualização das tecnologias abrangidas nesta proposta, iniciando com uma retrospectiva quanto ao desenvolvimento de softwares, sua evolução até a chegada da revolucionaria POO, seu diferencial, vantagens e dificuldades encontradas. Explicará o surgimento da Programação Orientada a Aspecto, vantagens, motivações, e conceitos necessários para o entendimento dessa tecnologia complementar a POO, assim como as desvantagens em sua utilização. FIGURA 1 - Ideia geral do trabalho proposto. (FONTE: Próprio Autor, 2015) Como para iniciar uma aplicação orientada a aspecto é necessário inicia-la durante a fase de modelagem do sistema, também iremos fundamentar e trabalhar a licitação de requisitos não funcionais ligados indiretamente com a programação orientada a aspecto para facilitar na refatoração do sistema desenvolvido inicialmente orientado a objeto, cessando objetivo final desse capítulo. 2.1 Desenvolvimento de software. 14

19 Ao longo dos últimos anos a Engenharia de Software disponibilizou vários métodos, técnicas e ferramentas para auxiliar os desenvolvedores de software a produzirem com maior qualidade. Outas características foram perseguidas, sendo talvez as mais importantes para a produtividade, a reusabilidade e manutenibilidade. (GROVES, 2013). No desenvolvimento estruturado, a separação de interesses ocorre através das diferentes funcionalidades oferecidas pelo software. Cada função é implementada em um único módulo, ou procedimento. Neste paradigma de desenvolvimento, apesar dos interesses relativos a funcionalidades ficarem separados, interesses relativos a dados ficam distribuídos em um único módulo. Em engenharia de software, o princípio da separação de características está relacionado à decomposição e modularização (PARNAS, 1972). Para garantir este princípio, durante o desenvolvimento, deve-se usar a decomposição em unidades menores, cada uma abordando uma única característica, diminuindo a complexidade com código modular, onde o relacionamento mútuo desses módulos formará um sistema. Com o desenvolvimento de aplicações complexas, cresceram as demandas por metodologias que possam abstrair e modularizar as estruturas básicas de um programa, surgindo assim o conceito em desenvolvimento de softwares chamado de POO. 2.2 Programação Orientada a Objetos Com o Advento da POO houve um ganho na organização dos sistemas. O mundo passou a ser modelado na forma de classes de objetos, e como tal, as classes de objetos puderam ser reutilizadas com maior facilidade (GROVES, 2013). Para trabalhar com a POO se faz necessário compreender a utilização de objetos para melhor elaborar uma aplicação, sendo ele um elemento que representa no domínio da solução, alguma entidade (abstrata ou concreta) do domínio de interesse do problema sob análise. Objetos similares são agrupados em classes e, um objeto não é muito diferente de uma variável normal (RICARTE, 2001). 15

20 As classes são consideradas como um identificador para que posteriormente sejam referenciadas no momento da criação de um Objeto. Dentro destas classes, temse os métodos, os quais definem funções existentes dentro das classes. O autor (RICARTE, 2001) também descreve que os métodos definem as funcionalidades da classe, ou seja, o que será possível fazer com os objetos dessa classe. Cada método é especificado por uma assinatura, composta por um identificador (o nome do método), o tipo para o valor de retorno e uma lista de argumentos, sendo cada argumento identificado por seu tipo e nome. A POO trouxe uma nova perspectiva de modelagem de dados, auxiliando o desenvolvedor com métodos fáceis para garantir uma maior desenvoltura durante o desenvolvimento de sistemas. Dentre as grandes vantagens podem ser citadas três, sendo elas: (encapsulamento, herança e polimorfismo) que nasceram com o paradigma, diferenciando de qualquer outra programação utilizada anteriormente Encapsulamento O encapsulamento consiste em definir o que os outros objetos poderão acessar, sendo implementado através do uso das palavras reservadas public, private e protected. Existem algumas situações em que o encapsulamento se faz absolutamente indispensável. Um exemplo, seria o caso relacionado a um caixa eletrônico. A quantidade de pessoas que conhecem o funcionamento de um caixa eletrônico é mínima. Isso é verdade por duas razões: primeiramente, algumas pessoas necessitam saber como o caixa funciona para realizar manutenções, para os usuários, não há nenhuma necessidade em saber como funciona um caixa eletrônico por dentro (SERSON, 2007). A Figura 2 apresenta uma abstração de um caixa eletrônica com e sem encapsulamento. 16

21 FIGURA 2 - Abstração do encapsulamento de um caixa eletrônico (FONTE: SERSON, 2007) Na Figura 2, o caixa eletrônico encapsulado é como se fosse um cofre. Para um usuário, não há a necessidade de saber o que há por dentro do caixa eletrônico. O encapsulamento é o mecanismo a partir do qual os detalhes da implementação dos métodos de uma classe são ocultados para usuários da classe. Isso é conquistado mantendo-se atributos private e disponibilizando os dados para visualização por meio de métodos get e permitindo que os dados sejam alterados somente por métodos set. Através destes métodos criados para acessar as variáveis implementadas, obtém-se questões de segurança para acesso as classes, onde as variáveis private só podem ser acessadas dentro da própria classe. É como se elas fossem invisíveis para o escopo de outras classes. Assim, evita-se que outros métodos, classes ou até mesmo hackers tenham acesso aos dados de determinada classe, que muitas vezes podem ser dados privados, como é o caso de aplicações para empresas e bancos. Ainda no exemplo do caixa eletrônico citado acima, supondo que seja necessário criar uma aplicação para um banco, onde deve ser limitado o número de saques de um cliente. Os valores do saldo desse cliente ficarão armazenados na variável saldo. Se tiver acesso total a essa variável, o cliente poderia usar de forma descontrolada os serviços do banco. Porém, pode-se criar um método em que, cada vez que o cliente saque dinheiro ele ative um contador, conforme mostra o código da Figura 3. 17

22 FIGURA 3 - Método sacar (FONTE: SERSON, 2007) No trecho do código acima, quando o usuário tenta sacar, através do menu do caixa eletrônico, seguirá para o método setsaque(). Então cada vez em que o cliente sacar, seu saldo irá diminuir em valor e um contador (que é uma variável de classe), é incrementado para controle de limite de saque diário. O método get não foi ilustrado, mas serve para obter a informação do saldo, e esse tipo de método sempre retornará um valor, já o método set é utilizado para definição do valore do saque Herança O mecanismo de herança no paradigma é um dos seus grandes trunfos. Este permite poupar tempo quando se trata de criar classes que são similares a outras. De uma forma simples, herança é o mecanismo que faz com que uma nova classe herde da classe mãe (ou superclasse) atributos e métodos em comum. Cada classe existente é chamada de superclasse e a classe nova é chamada de subclasse. Cada subclasse pode se tornar superclasse para futuras subclasses. Uma subclasse, usualmente, adiciona seus próprios campos e métodos. Dessa forma, uma subclasse é mais específica que sua superclasse, além de representar um grupo mais especializado de objetos. Normalmente a subclasse exibe os comportamentos de sua superclasse e comportamentos adicionais específicos. A superclasse direta é a superclasse a partir da qual a subclasse herda diretamente (SERSON, 2007). A Figura 4 demonstra os conceitos de superclasses direta e indireta. A classe Manager é superclasse direta da classe Employee. A classe Director é superclasse direta da classe Manager e a classe Director é superclasse indireta da classe Employee. 18

23 FIGURA 4 - Diagrama UML de classes que representam relacionamentos de herança. (FONTE: SERSON, 2007) Ainda de acordo com (SERSON, 2007), uma herança significa especialização. Uma subclasse se especializa ao herdar todos os atributos e métodos de sua superclasse e adicionar outros. Os atributos e métodos adicionais tornam a subclasse mais restritiva ou, em outras palavras, mais especial Polimorfismo Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de uma mesma superclasse podem invocar métodos que têm a mesma identificação (assinatura), mas, com comportamentos distintos, especializados para cada classe derivada, usando para tanto uma referência a um objeto do tipo da superclasse. Esse mecanismo é fundamental na POO, permitindo definir funcionalidades que operem genericamente com objetos, abstraindo-se de seus detalhes particulares quando esses não forem necessários. 19

24 Através deste fundamento de polimorfismo, segundo (SERSON, 2007), a extensibilidade é promovida pelo polimorfismo a partir do momento em que ele permite unificar o processamento de objetos relacionados por herança ou por implementação de interfaces. Do ponto de vista arquitetural, novas classes podem ser adicionadas que o processamento polimórfico permanecerá imutável. Sem meios apropriados para sua separação em um sistema OO, os interesses transversais tendem a ficar espalhados e entrelaçados com outros interesses. Um interesse é dito espalhado quando afeta vários componentes do sistema e entrelaçado quando se mistura com outros interesses dentro de um mesmo módulo. Estas duas características são indesejáveis porque causam uma maior dificuldade de entendimento, evolução e reutilização dos artefatos de software (GARCIA et Al., 2004). Com o polimorfismo, os mesmos atributos e objetos podem ser utilizados em objetos distintos, porém com implementações lógicas diferentes. Por exemplo, tem-se uma classe Animal e nela sabe-se que todo animal come, sendo que Cães comem ração e Tigres comem carne. Dentre os métodos de chamadas existentes, pode-se ter os comportamentos citados, na Figura 5. FIGURA 5 - Exemplo de polimorfismo (FONTE: SERSON, 2007) Para utilizar o método polimórfico, tem-se o exemplo, ilustrado na Figura 6. 20

25 FIGURA 6 - Exemplo de chamada de polimorfismo (FONTE: SERSON, 2007) Nota-se então, que cada chamada irá fazer algo diferente, porém como existe herança entre as classes, todos os métodos irão funcionar, porque são do tipo mais genérico (Animal) ou são filhos do mais genérico. Através destas 3 fundamentações, tem-se ainda algumas dificuldades encontradas nas implementações da POO, tais quais serão abordadas no próximo tópico. 2.3 Dificuldades encontradas na POO Conforme apresentado nas seções anteriores, a POO trouxe algumas contribuições importantes para o desenvolvimento de sistemas no que se refere a facilidade de manutenção e reutilização de código. Contudo, existem alguns problemas, tal como espalhamento e entrelaçamento de dados, que a técnica OO. Sozinha é incapaz de lidar. Os mesmos serão abordados a seguir. A Figura 7 (CHAVEZ, 2004) ilustra os problemas de espalhamento e entrelaçamento causados pelas abordagens estruturadas e orientada a objetos. Sendo que na Figura 7(a), o mesmo dado pode ser utilizado em diferentes funções (procedimentos), e cada função trata de diferentes dados. Na Figura 7(b) o mesmo comportamento (método) é desempenhado em diferentes componentes e cada componente desempenha comportamentos diferentes. 21

26 FIGURA 7 - Problemas de espalhamento e entrelaçamento causadas pela OO (FONTE: CHAVEZ, 2004) Esses dois problemas expostos, evidenciam a dificuldade nos processos de manutenção e reuso do código. E a grande evidência dos problemas na OO é o surgimento da POA, que apresenta soluções de uma forma simplória e eficiente aos olhos dos programadores. Antes de aprofundar os estudos na POA, deve-se analisar então com muita cautela alguns problemas relacionados a POO Entrelaçamento do Código (Tangled Code) Para o DSOO (Desenvolvimento de Software Orientado a Objetos), o mundo é representado através de objetos e classes. Para o correto funcionamento, um sistema necessita de atributos e métodos para compor as classes que irão representar uma entidade do mundo real. Durante o processo de integração dos componentes ao software final, ocorre o fenômeno conhecido como entrelaçamento do código. Quando o trabalho de preenchimento dos métodos se inicia, faz-se necessário inserir chamadas de responsabilidade de uma classe em outra. Estas linhas de código inseridas em outro componente para integração são denominadas código intrusivo ou invasivo. (RESENDE; SILVA, 2005 p.179). 22

27 FIGURA 8 - Exemplo para demonstrar o entrelaçamento de código (FONTE: RESENDE; SILVA, 2005) Nas linhas 34 e 36 por exemplo, ocorrem duas chamadas intrusivas, Banco.conectar() e Banco.fechar(). Isso também poderia ocorrer com tratamento de exceções, registros de logs, persistência de dados, etc. Assim, a lógica do sistema fica embaralhada, portanto, assuntos que deveriam ser tratados somente em suas classes de origem estão sendo tratadas em outras classes. Os autores (RESENDE; SILVA, 2005) expõem ainda mais dois possíveis problemas gerados pelas chamadas invasivas: Dificuldade em saber exatamente o que ocorre com uma classe ao ler o seu código, pois as chamadas referentes ao entrelaçamento estão fora da mesma; Comportamento emergente. Alguns pesquisadores da área de IA (Inteligência Artificial) levantaram a hipótese de que a inserção de chamadas a métodos em componentes que foram concebidos sem 23

28 pensar em tal interação poderia apresentar um novo comportamento. Esta especulação advém da teoria de IA sobre a interação de agentes inteligentes, que, através de sinergia da cooperação entre eles, um novo comportamento pode surgir Espalhamento do Código (Scattering Code) Ainda com o problema de ter classes inchadas com códigos invasivos tratando aspectos não pertinentes a seus objetos, tem-se o problema de repetição destes códigos. Analisando o exemplo anterior das classes Banco e Questão (Figura 8) e supondo que aquelas mesmas chamadas intrusivas fossem feitas por outras classes, caso fosse necessário alterar o nome do método conectar() da classe Banco para abrirconexao(), seria necessária a alteração de todas as chamadas a esse método em todo o sistema. Isso causaria sérios problemas de manutenibilidade e produtividade. Por exemplo, analisando a Figura 9(a) abaixo, é possível notar que o método conectar() se faz presente em diversas classes, podendo esses estarem espalhados em diversas partes de um programa. A manutenção para uma alteração desse método impactara em todas as classes que fazem uso deste. A Figura 9(b) representa a alteração desses métodos. FIGURA 9 - Manutenção transversais (FONTE: RESENDE; SILVA, 2005) 24

29 Abaixo é apresentado outro exemplo o qual é possível a visualização desse problema, a Figura 10 mostra a quantidade de registros de logs no servlet container Tomcat. As barras verticais são as classes e as linhas horizontais representam o espelhamento obtido pelas chamadas para registros de logs. FIGURA 10 - Distribuição dos registros de log no Tomcat (FONTE: RESENDE; SILVA, 2005) Agora analisando o exemplo acima, imaginando que a pessoa responsável pela manutenabilidade do sistema não se faz mais presente, e existe a necessidade de uma alteração envolvendo uma Feature que se relaciona com duas ou mais classes, o quão grande será o impacto dessa manutenção? O Quadro 1 se refere a um resumo das principais características de códigos espalhados e códigos entrelaçados, também conhecido como códigos emaranhados. QUADRO 1 - Comparativo entre código espalhado e código emaranhado Termo Original Tradução Descrição Scattering Code Código espalhado Código necessário para cumprir um interesse propagado em classes que precisam cumprir interesses. O Código espalhado pode ser dividido em duas categorias distintas: Bloco de Código Duplicado e Bloco de Código Complementar. Tangled Code Código emaranhado Utilização de uma única classe ou método para implementar múltiplos interesses. 25

30 O código emaranhado ocorre quando um módulo é implementado com múltiplos interesses simultaneamente. Um desenvolvedor frequentemente considera os interesses como lógica do negócio, performance, sincronização, segurança, dentre outros, durante a implementação do módulo. Isso resulta na implementação de vários interesses em um mesmo módulo. (FONTE: SERSON, 2007) 2.4 Programação Orientada a Aspectos Pode-se dizer que a POA é um novo conceito, devido ser alvo de estudo na esfera acadêmica e principalmente por ser de interesse dos arquitetos de softwares que buscam diariamente metodologias ágeis e de fácil compreensão, apresentando um retorno positivo para a equipe durante o processo de desenvolvimento. Em 1997 Kiczales líder da empresa Xerox, coordenava uma equipe de pesquisados, que primeiro descreveu a POA em Ele e sua equipe estavam preocupados com o uso de repetições clichê que eram muitas vezes necessárias e se tornavam caras pela utilização em diversos blocos de códigos orientados a objetos. São citados como exemplos destas características, o controle de log, cache, transação, persistência, entre outros. O autor Kiczales (1997) e sua equipe descrevem os problemas que POO foi incapaz de capturar e resolver de uma forma clara. Eles observaram que essas preocupações transversais acabaram sendo espalhadas por todo o código, deixando este com um emaranhado de código, se tornando cada vez mais difícil de desenvolver e modificar. Eles analisaram todas as razões entre as técnicas utilizadas para identificar o motivo de se apresentar este descontrole, resultando neste emaranhamento. A POA complementa a POO, fornecendo outra maneira de pensar sobre a estrutura do programa. A unidade fundamental da modularidade em POO é a classe, enquanto que em POA a unidade de modularidade é o aspecto. Aspectos permitem a modularização de preocupações, tais como gerenciamento de transações que atravessam vários tipos e objetos. 26

31 O principal objetivo da POA é separar o código referente ao negócio dos códigos transversais, uma divisão de interesses (requisitos), abrangendo o problema de legibilidade como a questão da modularidade. Esses interesses transversais são divididos em aspectos mantendo o código referente ao negócio como fluxo principal da aplicação e sem qualquer alteração Conceitos Fundamentais sobre a Programação Orientada a Aspectos Um aspecto é o elemento básico de encapsulamento dos outros elementos que dão suporte ao uso da POA, os quais são os pontos de corte, os adendos e as declarações inter-tipos que são os atributos, os métodos e as classes internas, que podem alterar a estrutura estática (static crosscutting), adicionando membros a uma classe; e dinâmica, interceptando pontos de junção e da adição de comportamento antes e depois desses pontos de junção ou ainda por meio da obtenção de total controle sobre o ponto de execução, de um programa, mudando a hierarquia do sistema, conforme (SOARES e BORBA, 2002). Seguindo com o conceito de POA, os recursos que permeiam várias classes de um sistema, vinculando mesmo aquelas que implementam regras conceitualmente distantes, são chamados de cross-cutting. São exemplo desses recursos; criação de logs de operações, auditoria em alteração de dados, níveis de permissão de acesso a dados, autorização para executar operações, tratamento de exceções, etc. Para melhorar a solução para esses tipos de recursos foi proposta POA, onde o código que implementa os recursos cross-cutting são retirados das classes de negócio e inseridos em métodos próprios. A POA depende ainda de um mecanismo que permita vincular a execução dos códigos do aspecto à execução das regras de negócio. A solução proposta pela POA é centrada no modelo de pontos de ligação (Join Points). O modelo de pontos de ligação é definido por três características: o momento em que o código poderá ser executado, chamado de Join point, uma forma de especificar esses modelos e uma forma de especificar o código que deve ser executado em cada momento. 27

32 Um ponto de ligação pode ser encarado como um evento que ocorre no código da regra de negócio, marcado pela execução de um determinado método ou pela alteração no valor de uma propriedade. Criar pontos de ligação significa indicar quais desses eventos devem ser monitorados pelo aspecto, usando para isso estruturas chamadas de pointscuts. Os pointscuts se valem de uma sintaxe especial para possibilitar a indicação de quais métodos e propriedades dispararão a execução do código relativo a um ponto de ligação (FABBRO, 2011). O autor (GROVES, 2013) exemplifica uma característica transversal através do seguinte contexto: considere um método que faz X. Se realizado um logging de performance (C) nesse método X, caso exista outros métodos Y e Z que necessitem desse controle de performance, será necessário colocar C em cada um desses métodos também. Sendo assim, C é a preocupação transversal. Embora a preocupação transversal seja um termo conceitual cross-cutting que é definido por uma ou duas sentenças, que resulta em um código concreto funcional. Enfim, a POA é uma tecnologia de programação em nítida evolução que oferece suporte a novos mecanismos e recursos de abstração e composição com o objetivo de permitir alcançar uma melhor separação de interesses no nível da implementação. A POA é evolucionária porque considera atribuições reconhecidas da separação de interesses proporcionadas por tecnologias anteriores Motivação (Importância da POA) Conforme cita o autor (KICZALES, 1997), a POA tem como objetivo a separação do código segundo a sua importância para a aplicação, permitindo que o programador encapsule o código secundário em módulos separados do restante da aplicação. Por exemplo, considera-se que uma aplicação bancária simplesmente transfere um valor de uma conta para outra, conforme ilustra a Figura

33 FIGURA 11 - Aplicação bancária com o método de transferência de valores (FONTE: KICZALES, 1997) Porém, numa aplicação bancária construída para o mundo real, este método de transferência está longe do adequado. É necessário incluir valores de segurança, que determinam se o usuário possui autorização para realizar a operação. É preciso também envolver a operação em uma transação para prevenir perda de dados. Finalmente, é preciso fazer o log dos dados da aplicação. Uma versão simplificada que contém estes novos objetos (concerns) está ilustrada na Figura 12. FIGURA 12 - Versão simplificada com novos objetivos (concerns) (FONTE: KICZALES, 1997) Comparando com a primeira versão, o código perdeu a sua elegância e simplicidade, depois que o código foi voltado para outros objetivos misturado com 29

34 aquele que implementa as regras do negócio. Deve-se considerar o que ocorre quando é necessário alterar, por exemplo, a implementação de segurança da aplicação. No exemplo mostrado, o código é espalhado por vários métodos, e qualquer mudança significa um grande esforço de codificação. Por fim, pode-se dizer que este código não está devidamente encapsulado nos seus próprios módulos. Isto aumenta a complexidade do sistema e torna a manutenção do mesmo muito difícil. A POA então, busca resolver este problema permitindo que o programador implemente essas questões (segurança, log, transações, e etc.) através de aspectos. Em muitas linguagens que implementam POA, o aspecto é constituído de uma ou mais peças de advices (fragmentos do código, como métodos) e uma lista de join points (pontos no programa principal na qual os advices são inseridos) Sincronização de Objetos Concorrentes Um programa em que dados os globais sejam compartilhados, necessita sincronizar suas atividades através de mecanismos que possibilitem sua execução. Um exemplo de política de sincronização seria que todos os objetos podem realizar operações de leitura em um determinado objeto, se ele não estiver sendo modificado, mas, somente um deles pode realizar uma operação de escrita por vez (CAHILL & DEMPSEY, 1997). Logo, existem diversos benefícios em se possuir uma propriedade importante de um sistema expressa de maneira bem localizada em uma única unidade ou seção de código. A partir desta separação, pode-se entender com maior facilidade como esta age no sistema como um todo, já que não é necessário procurá-la em diferentes lugares separá-la de outras propriedades. Ainda, é possível analisá-la, modificá-la, estendê-la e reusá-la mais facilmente (CZARNECKI & EISENECKER, 2000). Para (GROVES, 2013) quando preocupações transversais são codificadas sem POA, os códigos muitas vezes passam por dentro de um método sendo misturados logicamente, perdendo toda a regra de negócio. Essa abordagem é conhecida como tangling. 30

35 Quando a preocupação do código transversal é utilizada em vários métodos e várias classes (usando o copiar e colar, por exemplo), esta abordagem é chamada de scattering (dispersão) por que o código fica espalhado em toda a aplicação. Na Figura 13, tem-se o código de lógica de negócio em verde, e o código de registro em vermelho. FIGURA 13 - Exemplo de código do negócio relacionado a sincronização de objetos concorrentes (FONTE: GROVES, 2013) A preocupação do código transversal está nas mesmas classes como ocorre na lógica de negócio. Quando é refatorado utilizando POA, todo o código em vermelho é movido para uma nova classe, e tudo o que permanece na classe original é o código em verde que executa a lógica de negócios. Então, é necessário informar a ferramenta de POA para aplicar o aspecto (classe vermelho) para a classe de negócio (classe verde), especificando um pointcut. A ferramenta de POA executa este passo de combinação com um processo chamado de (weaving), conforme esboça a Figura 14. Na Figura 13, o código combinado parece com o código original, misturando verde e vermelho em uma classe. Não terá nada do código combinado em seus arquivos de código fonte. O código terá as classes que está trabalhando, terá uma separação 31

36 organizada se mantendo agradável para o desenvolvimento, de maneira que as ferramentas de POA realizarão o processo de tecelagem de acordo com ferramenta utilizada. FIGURA 14 - Combinação de um processo weaving (FONTE: GROVES, 2013) Conceitos e Terminologias Antes de apresentar as propostas referentes à modelagem orientada a aspectos, é conveniente fazer uma rápida revisão dos conceitos relacionados a esse tipo de programação, principalmente do ponto de vista da linguagem AspectJ, a implementação mais popular. O mecanismo mais utilizado em (DSOA) Desenvolvimento de Software Orientado a Aspectos para a implementação de aspectos é o uso de advices, trechos de códigos que devem ser inseridos ou substituir trechos na estrutura ou execução de componentes, e Join points, trechos identificáveis dentro da execução de um componente, onde os advices podem ser inseridos (KICZALES, 1997). Esses 32

37 mecanismos podem ser utilizados de forma dynamic crosscuting, para a modificação da execução dos componentes, executando advices antes ou depois de métodos do componente, substituindo parâmetros, ou mesmo trocando a execução de um método do componente por um advice do aspecto. Ou podem ser usados de forma statis crosscuting, alterando a própria estrutura dos componentes: adicionando métodos e propriedades, ou modificando a hierarquia de classes, conforme detalha a Figura 15. FIGURA 15 - Relação entre Aspectos, components e pontos de junção (FONTE: BARDOU, 1998) Por ser uma área relativamente nova na computação, ainda não existe uma tradução usual para muitos termos utilizados na literatura a respeito de POA sendo assim, esse trabalho irá dar enfoque em apenas algumas terminologias, como por exemplo: Separation of concern; Aspect; Join Point; Advices; Introduction e Weaving Separação de Interesses O termo separação de interesses foi cunhado por (DIJKSTRA, 1976) para denotar o princípio que guia a visão em partes: todo sistema de software lida com diferentes interesses, sejam eles dados, operações, ou outros requisitos do sistema. Segundo o autor (LADDAD, 2009), o ideal seria que a parte do programa dedicada a 33

38 satisfazer a um determinado interesse estivesse concentrada em uma única localidade física, separada de outros interesses, para que o interesse possa ser estudado e compreendido com facilidade. Tem-se em consideração uma boa prática de desenvolvimento de sistemas, onde a decomposição de um sistema através da divisão de interesses permite-se um melhor nível de abstração dos dados, diminuindo assim a complexidade das características individuais, permitindo assim que o desenvolvedor mantenha o foco especificamente no que for de interesse aumentando o processo de evolução de desenvolvimento. A ideia central por trás da orientação a aspectos é que os mecanismos de abstração e composição das tecnologias existentes não são suficientes para separar alguns interesses especiais encontrados em sistemas mais complexos. Esses interesses são chamados de interesses transversais (crosscutting concerns) uma vez que afetam a modularidade de outros elementos (chamados de componentes), atravessando seus limites. Sem os meios apropriados para a separação e a modularização, interesses transversais tendem a ficar espalhados e entrelaçados com outros interesses. As consequências naturais são uma menor compreensibilidade, uma menor evolução e uma menor reutilização dos artefatos do código. A orientação a aspectos utiliza o aspecto como um novo mecanismo de modularização para a separação de interesses transversais e fornece um novo mecanismo para combinar aspectos em componentes em pontos de combinação bem definidos (RESENDE; SILVA, 2005). O desenvolvimento estruturado realizou a separação de interesses orientandose através das diferentes funcionalidades oferecidas pelo software. Cada função é implementada em um único módulo, ou procedimento. Daí surgiram conceitos que ajudam a manter a separação de interesses, como o baixo acoplamento e a alta coesão. O objetivo do desenvolvimento orientado a aspectos é encapsular interesses transversais em aspectos fisicamente separados do restante do código. Em termos abstratos, a orientação a aspectos introduz uma terceira dimensão de decomposição, conforme ilustra a Figura 16. Além de decompor o sistema em objetos (dados) e métodos (funções), é então transformado cada objeto e função de acordo com o interesse sendo 34

39 servido e agrupados a cada interesse em um módulo distinto, ou aspecto. FIGURA 16 - Exemplo 3D de decomposição relacionado a separação de interesses (FONTE: NELSON, 2005) Aspectos Aspectos são definidos como propriedades de sistemas que afetam componentes e, mais especificamente, como propriedades que afetam o desempenho ou a semântica de componentes de forma sistêmica (KICZALES, 1997). Para estabelecer uma terminologia independente de linguagem, usa-se o termo característica transversal (crosscutting feature) a fim de denotar qualquer melhoria comportamental ou estrutural especificada dentro do aspecto para afetar um ou mais componentes nos pontos de combinação especificados, e o termo interface transversal (crosscutting interface) para denotar o conjunto de pontos de combinação especificados dentro do aspecto (LAMPING, 1999). As interfaces transversais incorporam especificações de pontos de combinação, ou seja, elas descrevem os tipos de pontos de combinação de interesse para o aspecto, restritos pelo modelo de pontos de combinação adotado. As características transversais são atributos e operações que descrevem melhorias na estrutura e no 35

40 comportamento de componentes. Essas melhorias podem adicionar uma nova estrutura e comportamento para um ou mais componentes, refinar ou até mesmo redefinir o comportamento existente. Os aspectos podem afetar um ou mais componentes, possivelmente afetando sua estrutura e comportamento. Além disso, amplia-se o uso do termo para denotar também um relacionamento genérico de um aspecto para um ou mais componentes Pontos de Junção São métodos bem definidos na execução do fluxo do programa que compõem pontos de corte. Segundo (KICZALES, 2001), pontos de junção podem ser considerados como os nós do grafo de chamada de um objeto em tempo de execução. Nesse grafo, por exemplo, os nós incluem locais onde um objeto recebe uma chamada de método e locais onde um atributo de um objeto é referenciado, enquanto as arestas apresentam as relações de fluxo de controle entre os nós. Os pontos de junção são classificados em diversos tipos, dependendo do local específico onde eles residem no programa. Conjuntos de pontos de junção podem identificar um único ponto de junção ou a composição de vários deles, usando operadores lógicos como e, ou, além de operadores como a negação. Os conjuntos de junção podem ser identificados na própria declaração dos advices ou serem identificados por um nome e, posteriormente, podem ser referidos por esse mesmo nome na declaração dos advices. Os pontos de junção são os elementos chaves da orientação a aspecto, pois ele é responsável por permitir a separação dos comandos de um software para realizar a composição entre os comandos. Inclusive acrescentando outros comandos com trechos de códigos escritos separadamente. É o ponto onde aplica-se um interesse transversal por meio de aspecto, como por exemplo a chamada de métodos, construtores, tratamento de exceções e outros. Dessa forma, pode-se ter os pontos de atuação que tem como função capturar as chamadas aos pontos de função, com a finalidade de ter mais um ponto de junção para um ponto de função, conforme a Figura

41 FIGURA 17 - Exemplo de mais de um ponto de junção para um ponto de função (FONTE: WINCK; GOETTEN, 2006) Um ponto de junção é qualquer ponto identificável por aplicações durante a execução de um programa. Aspectos podem ser associados a pontos de junção e executados antes, depois, ou ao invés deles Advices Advice é uma estrutura que denota o que um aspecto deve fazer, ou seja, qual o comportamento do aspecto. O advice designa a semântica comportamental do aspecto. Todo advice está associado a um pointcut, que define pontos de junção. De acordo com o autor (NELSON, 2005), advice são construções semelhantes aos métodos, entretanto, não podem ser chamados diretamente pela aplicação base e nem pelo próprio aspecto, pois sua execução é feita automaticamente após o entrecorte no ponto de junção. Outra diferença em relação aos métodos é que os advices não possuem nome, não tem especificadores de acesso (public, private, etc) e tem acesso a variáveis especiais das execuções dos pontos de junção, como assinatura dos métodos entrecortados, etc. Há três tipos de advice: Before: é o mais simples, simplesmente executa antes do ponto de junção. O único detalhe a se observar é que se o advice levantar uma exceção, o ponto de junção não será mais executado. After: executa depois do ponto de junção. Existem três variações desse advice, que dependem de como a execução do ponto de junção é finalizada, ou seja, se terminou normalmente, com uma exceção, ou de 37

42 qualquer forma. O Quadro 3 sintetiza as variações do after(). QUADRO 2 - after() ponto_de_corte() after() returning: ponto_de_corte() after() throwing: ponto_de_corte() As três variações possíveis de advice after Executa depois do ponto de junção, independente de como ele retornou Executa depois do ponto de junção se ele tiver terminado novamente (sem exceção) Executa depois do ponto de junção somente se este tiver saído com uma exceção (FONTE: NELSON, 2005) Around: o corpo de um advice around é executado substituindo o ponto de junção. No entanto, o ponto de junção pode ser executado dentro do corpo do advice usando-se o método proceed(). Todo advice around deve declarar um tipo a ser retornado. Este tipo deve ser o mesmo tipo dos pontos de junção associados a ele. Por exemplo, se o advice está associado à chamada de um método que retorna inteiro, ele deve retornar um inteiro. Todos os pontos de junção de um advice around devem retornar um tipo compatível com o tipo retornado pelo advice, conforme ilustra a Figura 18. FIGURA 18 - Exemplo de advice do tipo around (FONTE: NELSON, 2005) O aspecto pode usar informações do ponto de junção capturado. Essa informação traz parte do contexto do ponto de junção. É dever do ponto de corte (pointcut) expor o contexto desejado para que o advice possa usá-lo Passagem de Contexto De acordo com o autor (LADDAD, 2009), aspectos frequentemente precisam 38

43 de informações sobre o ponto de junção que será afetado em determinado instante. Sendo assim, através das cláusulas nos pontos de corte, existem 3 tipos de informação: Args(): a cláusula args(var1, var2,... varn) pode ser usada para capturar argumentos passados para um método. No exemplo da Figura 19, o método interceptado adicionalingrediente() recebe como parâmetro um objeto da classe Ingrediente. O ponto de corte captura o objeto passado através da cláusula args. O args recebe como parâmetro uma variável que pode ser usada no advice. A variável é declarada na definição do pointcut, como se fosse um parâmetro do pointcut. No advice, uma nova variável é declarada na declaração do advice, e passada para o ponto de corte. FIGURA 19 - Exemplo de args (FONTE: NELSON, 2005) This: a cláusula this(obj) captura o objeto onde está o ponto de junção, conforme pode ser visualizado no trecho de programa na Figura 20. FIGURA 20 - Implementação de ponto de corte (FONTE: NELSON, 2005) Vai capturar na variável var o objeto da classe A que estiver executando quando for feita a chamada a b.g(). Por exemplo, se executarmos o main() da classe A, o objeto capturado pelo this() acima será o objeto a declarado em main(). Target: esta cláusula é semelhante ao this(), porém ao invés de capturar o objeto que contém o ponto de junção, capturará o objeto que é o alvo 39

44 de uma chamada ou atribuição. No entanto, target() fará sentido quando associar aos pontos de corte call() ou set(), conforme a Figura 21. FIGURA 21 - Ponto de corte call (FONTE: NELSON, 2005) O ponto de corte irá capturar o objeto da classe B sobre o qual está sendo executado o método g(). O resultado do ponto de corte, nesse caso, é a execução de B.g() está na classe B e não na classe A. Assim, o target(var) vai retornar um objeto da classe B Weaving É o processo onde é feita a mesclagem dos módulos do sistema de acordo com os aspectos encontrados. O weaving é como uma outra etapa de compilação. Weaving rules são as regras que devem ser aplicadas durante essa fase da compilação. Através de um compilador especial é possível montar o sistema final combinando os módulos principais e os secundários pelo método weaving (tecelagem), então tem-se o nome de weaver ao compilador. O weaver tem a capacidade de interceptar as chamadas de métodos em tempo de compilação ou execução, conforme seu propósito, podendo desviar o fluxo de execução e até mesmo abortar a execução do método (SILVEIRA et al., 2004). O resultado que a POA modulariza as funcionalidades secundárias, possibilitando a criação de um sistema que é mais fácil de implementar e manter, conforme a Figura

45 FIGURA 22 - Weaver fazendo a mesclagem dos módulos (FONTE: GARCIA, 2015) Problemas na utilização da POA Conforme (KICZALES, 1997), a depuração é um dos maiores problemas. Enquanto no nível sintático o código POA aparece em separado, ele está junto do restante do código em tempo de execução. A inserção de advices pode se tornar imprevisível se não ficar definido que aspecto deve dominar. Os designers de software devem considerar meios alternativos para conseguir a separação do código. Porém, estas abordagens não tem um mecanismo de quantificação que permite que o programador chegue a diversos Join points com apenas uma declaração. Outro problema com a POA é a captura não intencional de Join points através de wilcards. Por exemplo, supõem-se que seja especificado um determinado pointcut a um advice associado, e um wilcard para todos os métodos que tenham certo padrão de nomenclatura. Um programador desatento pode criar um método cujo nome seja compatível com esse wilcard, sem que seja essa a sua intenção, levando a execução inadvertida do advice. Da mesma forma, ao renomear um método, pode-se alterar 41

46 completamente a sua semântica Benefícios da Programação Orientada a Aspectos Conforme apresentado nas seções anteriores, a POA trouxe algumas contribuições importantes para o desenvolvimento de sistemas no que se refere a facilidade de manutenção e reutilização de código. Dentre as diversas vantagens e benefícios que a POA dispõe, podem-se citar algumas delas, conforme o autor (GARCIA, 2015): Responsabilidades mais transparentes de cada módulo: cada módulo é responsável apenas pelas tarefas destinadas ao próprio módulo. Os módulos são mais independentes. Modularização mais alta: as responsabilidades são melhor definidas em cada módulo, os módulos têm baixo acoplamento entre si. Evolução do sistema mais facilitada: o baixo acoplamento possibilita que alterações no sistema sejam feitas sem alteração do núcleo. Decisões de design podem ser tomadas com mais atraso: devido ao baixo acoplamento não é necessário pensar em todos os problemas no início do desenvolvimento do sistema. Mais reusabilidade do código: os módulos podem ser mais reaproveitados devido à alta coesão e baixo acoplamento. Sistemas mais fáceis de desenvolver e manter: os aspectos tornam a integração das partes do sistema um módulo separado, o que traz mais facilidade no desenvolvimento. Custos reduzidos de introdução de novas funcionalidades: novas funcionalidades podem ser introduzidas criando aspectos, não sendo necessário alterar o núcleo para adicionar tais funcionalidades Linguagens que implementam POA A linguagem de programação nada mais é do que comandos dos quais ao 42

47 serem executados realizar alguma função para atender alguma necessidade. O quadro 3 apresenta as linguagens que possibilitam a POA. QUADRO 3 - Linguagens POA Linguagem Framework - (Referencia) C# PostSharp, Spring.Net, aspect# - (ARCHER, 2001). VB.NET DotSpect - (GROVES, 2013) e (PODILA, 2005). Ada Ada - (BARNES, 2012). AutoHotkey AutoHotkey - (HOOKS, 2009). C AspectC - (COADY; FEELEY; SOMOLYN; KICZALES, 2001). C++ AspectC++ - (AspectC++, 2015). COBOL Cobble - (ADAMS, SCHUTTER e ZAIDMAN, 2005). The Cocoa Objective-C AspectCocoa - (COCOADEV, 2015). ColdFusion ColdSprint - (BATEMAN, CORFIELD, ROSS, SCOTT e WIERSMA, 2015). Common Lisp AspectL - (COSTANZA, 2005). Delphi Dsharp - (HODGES, 2014). Delphi Prism Cirrus - (Avram, 2010). ActionScript As3-commons-bytecode - (WARD, 2011). Emacs Lisp GNU Emacs - (GNU, 2015) Groovy Groovy - (Groovy, 2015) Haskell AspectH - (ANDREADE; BORBA; SANTOS, 2004). Java AspectJ - (LADDAD, 2001). JavaScript AspectJS - (ASPECTSCHEME, 2015). Squeak Smalltalk AspectS - (HIRSCHFELD, 2003). Lua AspectLua - (ASPECTLUA, 2006). Make Makao - (MCIS, 2014). Matlab AspectMatlab - (ASLAM, BODZAY, 2015). ML AspectML - (LIGATTI, ZDANCEWIC e WALKER, 2006). Perl PearlAspect - (KENNEDY, 2013). PHP PHPAspect - (PHPASPECT, 2015). Prolog Whirl - (AUCLAIR, 2005). Python SpringPython - (SPRINGPYTON, 2015). Racket AspectScheme - (ASPECTSCHEME, 2015). Ruby AspectR - (BRYANT, FELDT, 2002). (FONTE: Próprio Autor) 2.5 Requisitos do sistema Requisitos de um sistema são descrições dos serviços que devem ser fornecidos por esse sistema e as suas restrições operacionais (SOMMERVILLE, 2007). 43

48 Um requisito de um sistema é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir seus objetivos (PFLEEGER, 2004). Com base nessas definições, pode-se dizer que os requisitos de um sistema incluem especificações dos serviços que o sistema deve prover, restrições sob as quais ele deve operar, propriedades gerais do sistema e restrições que devem ser satisfeitas no seu processo de desenvolvimento. As definições acima apresentadas apontam para a existência de diferentes tipos de requisitos. Uma classificação amplamente aceita quanto ao tipo de informação documentada por um requisito faz a distinção entre requisitos funcionais e requisitos não funcionais Requisitos Funcionais São declarações de serviços que o sistema deve prover, descrevendo o que o sistema deve fazer (SOMMERVILLE, 2007). Um requisito funcional descreve uma interação entre o sistema e o seu ambiente (PFLEEGER, 2004), podendo descrever, ainda, como o sistema deve reagir a entradas específicas, como o sistema deve se comportar em situações específicas e o que o sistema não deve fazer (SOMMERVILLE, 2007) Requisitos Não Funcionais Descrevem restrições sobre os serviços ou funções oferecidas pelo sistema (SOMMERVILLE, 2007), as quais limitam as opções para criar uma solução para o problema (PFLEEGER, 2004). Nesse sentido, os requisitos não funcionais são importantes para a fase do projeto (design), servindo como base para a tomada de decisões nessa fase. Os requisitos não funcionais têm origem nas necessidades dos usuários, em restrições de orçamento, em políticas organizacionais, em necessidades de interoperabilidade com outros sistemas de software ou hardware ou em fatores externos como regulamentos e legislações (SOMMERVILLE, 2007). Assim, os requisitos não 44

49 funcionais podem ser classificados quanto à sua origem. Existem diversas classificações de requisitos não funcionais. O autor (SOMMERVILLE, 2007), por exemplo, classificaos em: Requisitos de produto: especificam o comportamento do produto (sistema). Referem-se a atributos de qualidade que o sistema deve apresentar, tais como confiabilidade, usabilidade, eficiência, portabilidade, manutenibilidade e segurança. Requisitos organizacionais: são derivados de metas, políticas e procedimentos das organizações do cliente e do desenvolvedor, Incluem requisitos de processo (padrões de processo e modelos de documentos que devem ser usados), requisitos de implementação (tal como a linguagem de programação a ser adotada), restrições de entrega (tempo para chegar ao mercado, restrições de cronograma, etc), restrições orçamentárias (custo, custo-benefício), etc. Requisitos externos: referem-se a todos os requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento. Podem incluir requisitos de interoperabilidade com sistemas de outras organizações, requisitos legais (tais como requisitos de privacidade) e requisitos éticos Estratégia para licitar Requisitos Não Funcionais Conforme cita o autor (LEITE, 1995), utiliza-se a ideia de que requisitos, de uma maneira geral, não são estáticos e, portanto, sofrem mudanças durante o ciclo de vida do software. Isso significa que os requisitos identificados, durante a fase de elicitação de requisitos, continuam evoluindo por todo o ciclo de vida do software, devendo o engenheiro de software ficar atento para estas possíveis evoluções e representá-las devidamente. A Figura 23 ilustra, a estratégia de elicitação de requisitos não funcionais. 45

50 FIGURA 23 - Estratégia de Elicitação de Requisitos Não Funcionais (FONTE: LEITE, 1995) Como identificar requisitos não funcionais A elicitação de requisitos não funcionais deve ser feita separadamente dos requisitos funcionais, de forma a manter o engenheiro de software centrado no problema que ele está investigando. Isso significa que, mesmo se durante a elicitação de requisitos funcionais, caso o engenheiro de software identifique algum requisito não funcional, ele não deverá se aprofundar nesse requisito não funcional, e sim anotá-lo à parte para posterior investigação. Essa regra, é claro, vale também para o caso inverso que seria a identificação de um requisito funcional ainda não identificado durante a elicitação dos requisitos não funcionais. Nessa etapa, o engenheiro de software deverá utilizar uma ou mais técnicas de elicitação para identificar os requisitos não funcionais inerentes ao UdI. Assim, utilizase o Léxico Ampliado da Linguagem (LAL), conforme cita o autor (FRANCO, 1992), que tem por objetivo conhecer o vocabulário usado no UdI. O LAL é baseado em um sistema de códigos composto por símbolos, noções e impactos. Este é construído utilizando-se um conjunto de descrições, com o objetivo de se obter a semântica dos símbolos encontrados. Essa descrição utiliza um sistema de representação onde cada símbolo é descrito por noções e impactos. Cada símbolo é uma 46

51 entrada e as noções e impactos são itens dessa entrada, nos quais toda referência a outras entradas deve ser sublinhada (princípio da circularidade). A busca de requisitos não funcionais deverá ter como auxílio os requisitos funcionais encontrados, o que significa dizer que o engenheiro de software, de posse do documento que define os requisitos funcionais do sistema, deverá fazer uma busca em cada requisito funcional descrito no documento, procurando identificar eventuais RNFs a eles associados. Entretanto, alguns desses requisitos não funcionais, como por exemplo segurança de acesso a dados do sistema, podem ser globais ao sistema não estando relacionado a um determinado requisito funcional, e sim, presente em diversas partes do sistema, ou mesmo no sistema como um todo. Um instrumento importante no auxílio a identificação de RNFs pode ser o uso de um checklist de RNFs como guia. A Figura 24 mostra um checklist que poderá ser usado como ponto de partida. Essa lista não pretende ser completa e sim um apanhado dos RNFs mais comuns, sendo portanto aconselhável que a medida que se identifique um RNF não constante da lista que esta seja atualizada. FIGURA 24 - Checklist de RNFs (FONTE: FRANCO, 1992) 47

52 É importante que não sejam identificados apenas os RNFs de forma genérica, como por exemplo, especificar desempenho como um RNF existente e nada mais. É necessário que o requisito não funcional genérico seja instanciado (detalhado) até a identificação do que o sistema precisa possuir ou fazer para que esse RNF seja satisfeito. 2.6 Conclusões do capítulo. Seguindo o que foi apresentado no capítulo anterior, a POA, não é uma nova metodologia de programação, e sim um suplemento para a POO, a qual não é substituída pela POA, e sim complementada por esta. Essa evolução de tecnologia diz respeito a melhorias e facilidades para novas implementações e manutenibilidade no que diz respeito a um sistema, onde os interesses globais são fatorados em módulos separados do código principal, aumentando assim a compreensão do sistema. Esta separação de interesse dividida em módulos apresenta um melhor nível de abstração dos dados, interesse esse considerado como aspecto, conceito principal utilizado pela programação. Os aspectos são separados em classes individuais para que com o auxílio de Pointcut, Joinpoint, Advices e o compilador Weaving as classes de aspectos sejam executadas junto ao fluxo principal do sistema. Para compreender o que considerar como um aspecto, se faz necessário que sua identificação seja realizada ainda na fase de modelagem, e para se ter auxílio, pode se levar em consideração a licitação de requisitos, como principal os não funcionais, os quais expressam condições de comportamento e restrições que devem prevalecer. Os Requisitos não Funcionais, estão normalmente relacionados a Requisitos Funcionais, porém nem todo RNF necessita virar um aspecto. Pode se levar em consideração e também auxiliar em sua escolha, como por exemplo, o impacto desse requisito no sistema, sua abrangência em mais de uma classe e sua necessidade de evolução. Realizando a separação desses aspectos, e possível evoluir no desenvolvimento do sistema orientado a aspecto. 48

53 3 MODELAGEM DO SISTEMA Neste capítulo, serão apresentados conceitos e informações sobre UML e o Processo Unificado, seguido do levantamento de requisitos, casos de uso, expansão de casos de uso, diagrama de classes, diagrama de atividade e prototipação de interface do sistema proposto. 3.1 Processo unificado: De acordo com Falbo, (2000), o Processo Unificado proposto pela Rational (Rational Unified Process RUP), foi criado para apoiar o desenvolvimento orientado a objetos, fornecendo uma forma sistemática para se obter reais vantagens no uso da Linguagem de Modelagem Unificada (Unified Modeling Language UML). De fato, ele não é exatamente um processo: é uma infraestrutura genérica de processo que pode ser especializada para uma ampla classe de sistemas de software, para diferentes áreas de aplicação, tipos de organização, níveis de competência e tamanhos de projetos UML O Processo Unificado e formado por algumas das melhores práticas de desenvolvimento de software de forma que pode ser adaptada a uma vasta variedade de projetos e empresas. Porém, o Processo Unificado não pode ser considerado como apenas uma junção das melhores e principais características das metodologias mais popular, ele também possui características especificas, como ser orientado por casos de uso, ser centrado na arquitetura, ser iterativo e incremental. Estas são as características principais do Processo Unificado, o que o torna único (SEABRA, 2001). Segundo a empresa OMG, (2003) a linguagem de Modelagem Unificada é uma linguagem visual para especificar, construir e documentar os artefatos de um sistema. 49

54 A UML serve de interesse a qualquer pessoa que participe na produção, desenvolvimento ou manutenção de um software. Pois prevê situações ainda não identificadas na fase de desenvolvimento, facilitando assim para que se chegue ao final de um software com maior aproveitamento do projeto Descrição do estudo de caso A UML, é uma linguagem gráfica para visualização, especificação, construção e documentação de artefatos de sistemas complexos de softwares, onde a UML proporciona uma forma-padrão para preparação de planos de arquiteturas de projetos de sistemas, incluindo aspectos conceituais como processos de negócios e funções do sistema, além de itens concretos como as classes escritas em determinada linguagem de programação, esquemas de bancos de dados e componentes de softwares reutilizáveis. (BOOCH et al 2005, p. XIV) Desenvolver uma aplicação Windows Forms, o qual simule três tipos de operações possíveis de serem realizadas em um caixa eletrônico, permitindo que o usuário acesse sua conta e realize operações de saque, transferência e depósito, bem como, visualização de saldo ou extrato. Após finalizada a primeira parte do desenvolvimento utilizando orientação a objeto, serão identificados os possíveis pontos de aspectos, baseados nos requisitos levantados na modelagem para refatoração da aplicação, utilizando o conceito de orientação a aspecto. 3.2 Caso de uso Para Seabra (2015), um caso de uso representa um conjunto de ações realizadas pelo sistema que geram resultados observáveis por um ator, ou seja, um caso de uso é utilizado para estruturar o comportamento de um sistema sem ser necessário especificar sua implementação, além de envolver a interação de atores, que podem ser tanto humanos como sistemas automatizados. O diagrama de caso de uso por meio de uma linguagem simples, demonstra o comportamento externo do sistema, procurando apresentar o sistema através de uma perspectiva do usuário, demonstrando as funções e serviços oferecidos e quais usuários poderão utilizar cada serviço. Este diagrama é, dentre todos 50

55 3.2.1 Diagrama de caso de uso os diagramas de UML, o mais abstrato, flexível e informal, sendo utilizado principalmente no início da modelagem do sistema, embora venha a ser consultado e possivelmente modificado durante todo o processo de engenharia e sirva de base para a modelagem de outros diagramas. (GUEDES, 2005). eletrônico. A figura 25 representa o diagrama de caso de uso de parte de um sistema de caixa FIGURA 25 - Caso de Uso 03 (FONTE: Próprio Autor) 3.3 Levantamento de Requisitos Para (Wazlavick, 2013) a eliciação de requisitos referência a extração de informações sobre as funções que o sistema realiza, e também suas restrições. No entanto, durante a eliciação de requisitos, o analista pode encontrar regras de negócio ou restrições sobre como as funções devem ser realizadas pelo sistema, esse tipo de regra é um requisito não funcional. Sommerville, (2007), reforça que outra forma de registrar requisitos através do uso de um documento que consiste em uma lista de requisitos funcionais, possivelmente acompanhada de uma lista de restrições. 51

56 3.3.1 Requisitos Funcionais As informações que definem as funcionalidades do protótipo proposto serão descritas através, dos quadros 4 a 15: QUADRO 4 - RF1. Autenticação da conta Descrição: Autenticação da conta Para iniciar o sistema, deve-se informar os dados de agência e conta para validação de cadastro, confirmando ou negando o acesso ao sistema. Restrições lógicas: Digitar agência e conta (FONTE: Próprio Autor) RF1. Efetuar Saque Descrição: QUADRO 5 - Efetuar Saque O sistema deve permitir a opção de saque, limitado ao valor diário de no máximo R$ 1.000,00. Antes de realizar essa operação a agência e conta do cliente devem ser informadas. A efetivação da operação depende da confirmação da senha do cliente. Restrições lógicas: Usuário precisa confirmar a senha da conta. (FONTE: Próprio Autor) QUADRO 6 - Efetuar Depósito RF2. Efetuar depósito Descrição: O sistema deve permitir a opção de depósito. Antes de realizar essa operação a agência e a conta do cliente devem ser informadas. A efetivação da operação depende da confirmação da senha do cliente. Restrições lógicas: N/A (FONTE: Próprio Autor) QUADRO 7 - RF3. Efetuar transferência Efetuar Transferência 52

57 Descrição: O sistema deve permitir a realização de transferências entre contas. Antes de realizar essa operação a agência e a conta do cliente devem ser informadas. A efetivação da operação depende da confirmação da senha do cliente. Restrições lógicas: Usuário precisa confirmar a senha da conta. (FONTE: Próprio Autor) RF5. Emitir extrato Descrição: QUADRO 8 - Emitir Extrato O sistema deve permitir a geração de extrato da conta, apresentando o histórico de movimentação dos últimos 15 (quinze) dias. Antes de realizar essa operação a agência e a conta do cliente devem ser informadas. A efetivação da operação depende da confirmação da senha do cliente. Restrições lógicas: Usuário precisa confirmar a senha da conta. (FONTE: Próprio Autor) QUADRO 9 - Verificação de transferência RF6. O sistema não deve permitir transferência para um mesmo número de conta Descrição: O sistema deve verificar se os dados da conta de destino não são os mesmos da conta de origem, para permitir a transferência. Restrições lógicas: Usuário precisa confirmar a senha da conta. (FONTE: Próprio Autor) QUADRO 10 - Validação de saldo para saque RF8. O valor de saque deve ser maior que zero Descrição: O sistema deve verificar se o valor desejado para saque é maior que R$ 0,00, caso contrário, apresentar mensagem de alerta. Restrições lógicas: Usuário precisa confirmar a senha da conta. (FONTE: Próprio Autor) 53

58 QUADRO 11 - Verificação de saldo para transferência RF8. O saldo da conta para realizar a transferência deve ser maior do que o valor transferido Descrição: O sistema deve verificar se o saldo da conta de origem é maior do que o valor de transferência da conta de destino, caso contrário, apresentar mensagem de alerta. Restrições lógicas: Usuário precisa confirmar a senha da conta. (FONTE: Próprio Autor) QUADRO 12 - Validação de conta destino RF8. O sistema deve verificar a existência da conta de destino para realizar a transferência Descrição: O sistema deve verificar os dados da conta de destino para que possibilite realizar a transferência de valores, em caso de inexistência da conta, apresentar mensagem de alerta. Restrições lógicas: Usuário precisa confirmar a senha da conta. (FONTE: Próprio Autor) QUADRO 13 - Validação de valor para transferência RF8. O valor da transferência deve ser maior que zero Descrição: O sistema deve verificar se o valor para transferência é maior que R$ 0,00, caso contrário, apresentar mensagem de alerta. Restrições lógicas: Usuário precisa confirmar a senha da conta. (FONTE: Próprio Autor) QUADRO 14 - Validação de saldo para saque RF8. O saldo da conta deve ser maior do que o valor de saque Descrição: O sistema deve verificar se o saldo da conta é maior do que o valor solicitado para o saque, caso contrário, apresentar mensagem de alerta. Restrições lógicas: Usuário precisa confirmar a senha da conta. 54

59 (FONTE: Próprio Autor) QUADRO 15 - Validação de conta RF8. O sistema deve validar os dados da conta de acesso através de uma senha Descrição: Para garantir a segurança do acesso, o sistema deve solicitar uma senha de confirmação de conta, para assim garantir que a operação a ser realizada é válida. Restrições lógicas: Usuário precisa confirmar a senha da conta. (FONTE: Próprio Autor) Relacionamento entre requisitos funcionais versus casos de uso A Figura 26 demonstra o relacionamento de dependência entre os casos de uso e os requisitos funcionais. FIGURA 26 - Requisitos funcionais versus Casos de uso (FONTE: Próprio Autor) Requisitos Não funcionais 55

60 O quadro 16 apresenta a lista de requisitos não funcionais do sistema. QUADRO 16 - Requisitos não funcionais RNF.01 O sistema deve verificar se a conta informada é íntegra. RNF.02 O sistema deve verificar se o tempo de acesso não expirou. RNF.03 O sistema deve manter um controle de auditoria nas operações. RNF.04 O sistema deve tratar todas as ocorrências de erro em uma tela informativa. RNF.05 O sistema deve manter um tempo de resposta inferior a 1000ms em todas as chamadas. RNF.06 O sistema deve consultar/salvar os dados da conta do usuário em arquivo, através do padrão de repositórios. (FONTE: Próprio Autor) Relacionamento entre requisitos não funcionais versus casos de uso Os requisitos não funcionais apresentam grande impacto no sistema, pois normalmente suas características estão relacionadas a todas as camadas. Após os requisitos levantados é possível identificar os possíveis aspectos, onde para facilitar a visualização destes, foi montada uma tabela comparativa entre requisitos não funcionais e os casos de uso, representado pela Figura 27. FIGURA 27 - RNF versus Casos de uso (FONTE: Próprio Autor) 3.4 Diagrama de classe No diagrama de classes é possível modelar as classes e seus relacionamentos, assim como, definir seus atributos e operações. A Figura 28 apresenta o diagrama de classe do estudo de caso proposto. 56

61 FIGURA 28 - Diagrama de classe (FONTE: Próprio Autor) Para melhorar a compreensão do diagrama, as classes propostas na Figura 29 serão explicadas durante a fase de desenvolvimento. 3.5 Operações A seguir será descrito as principais funções da classe transação pertencente ao estudo de caso proposto Função Saque: O sistema deve permitir que o usuário realize saque. Na Figura 29 será apresentado o Diagrama de Atividade. 57

62 FIGURA 29 - Diagrama de Atividade da Função Saque (FONTE: Próprio Autor) Na Figura 30 será apresentado o diagrama de sequência. FIGURA 30 - Diagrama de Sequência Função Saque (FONTE: Próprio Autor) Função Depósito 58

63 O sistema deve permitir que o usuário realize Depósito. Na Figura 31 será apresentado o Diagrama de Atividade dessa funcionalidade. FIGURA 31 - Diagrama de Atividade da Função Depósito (FONTE: Próprio Autor) Na Figura 32 será apresentado o diagrama de sequência. FIGURA 32 - Diagrama de Sequência da Função Depósito Função Transferência (FONTE: Próprio Autor) 59

64 O sistema deve permitir que o usuário realize Transferência. Na Figura 33 será apresentado o Diagrama de Atividade. FIGURA 33 - Diagrama de Atividade Função Transferência (FONTE: Próprio Autor) Na figura 34 será apresentado o diagrama de sequência. FIGURA 34 - Diagrama de Sequência Função Transferência. (FONTE: Próprio Autor) 60

65 3.5.4 Consulta Extrato O sistema deve permitir que o usuário visualize seu extrato. Na Figura 35 será apresentado o Diagrama de Atividade FIGURA 35 - Diagrama de Atividade Consulta Extrato (FONTE: Próprio Autor) Na Figura 36 será apresentado o diagrama de sequência. FIGURA 36 - Diagrama de Sequência Consulta Extrato (FONTE: Próprio Autor) 61

66 3.6 Prototipação de interface Segundo Sommerville (2003, p.159), a prototipação é parte essencial do processo de projeto de interface. Devido à natureza dinâmica das interfaces com o usuário, as descrições textuais e os diagramas não são suficientemente bons para exprimir os requisitos da interface com usuário. A seguir serão apresentados, da Figura 37 até a Figura 43, os protótipos de interface das telas do sistema proposto. A Figura 37 apresenta o protótipo da tela inicial do sistema. FIGURA 37 - Interface Login (FONTE: Próprio Autor) A Figura acima representa a tela de acesso à conta do usuário, onde devem ser inseridos os dados da agência e conta disponibilizadas pela operadora do cartão cadastrado. Após isso, basta acessar o botão confirmar para prosseguir. A Figura 38, representa as opções de saque, depósito, transferência e extrato, disponíveis para utilização do usuário, bastando clicar na opção desejada. 62

67 FIGURA 38 - Interface Operações (FONTE: Próprio Autor) Para a opção de saque e transferência, será necessário uma confirmação de conta através de uma senha conforme demonstra a Figura 39. Essa senha é fornecida no momento da abertura da conta. FIGURA 39 - Interface Confirma Saque\Transferência (FONTE: Próprio Autor) Confirmando a senha, será apresentado a opção para informar o valor desejado para o saque. A Figura 40 representa a interface para informar o valor do saque. 63

68 FIGURA 40 - Interface Saque (FONTE: Próprio Autor) Na Figura 41 será apresentada a operação de transferência. FIGURA 41 - Interface Transferência (FONTE: Próprio Autor) Na Figura 42 é apresentado a opção de depósito. 64

69 FIGURA 42 - Interface Depósito (FONTE: Próprio Autor) realizadas. Na Figura 43 apresenta uma opção de Extrato para consulta das últimas operações FIGURA 43 - Interface Extrato (FONTE: Próprio Autor) 3.7 Considerações finais Nesse capítulo foi apresentado o processo de modelagem do sistema em questão, onde optou-se pelo processo unificado o qual permitiu realizar o levantamento das necessidades essenciais do sistema, e também realizar definições quanto ao formato de 65

70 sua estrutura e particularidades para seu funcionamento. Com isso, foi possível apresentar as principais classes necessárias para o desenvolvimento, assim como o fluxo de funcionamento para cada opção que estará disponível, assim como as possíveis classes para utilização de aspectos. Também foi realizada toda prototipação de interface, apresentando assim uma documentação inicial do sistema. 66

71 4 DESENVOLVIMENTO Para elaboração do desenvolvimento foram utilizadas as ferramentas de programação Microsoft Visual Studio 2012, juntamente com a linguagem C#. O trabalho será apresentado em duas fases, iniciando com o desenvolvimento do sistema proposto em POO e sua transformação para POA, enfatizando seus princípios, e demonstrando suas vantagens e desvantagens. 4.1 Tecnologias utilizadas Para a implementação do sistema foi necessário o uso de algumas tecnologias e ferramentas. Abaixo são descritos breves conceitos destas tecnologias XML Segundo PEREIRA (2006), o XML traz uma sintaxe básica que pode ser utilizada para compartilhar informações entre diferentes computadores e aplicações. Quando combinado com outros padrões, torna possível definir o conteúdo de um documento separadamente de seu formato, tornando simples para reutilizar o código em outras aplicações para diferentes propósitos. Uma das suas principais características é a portabilidade, pois, por exemplo, um banco de dados pode escrever um arquivo XML para que outro banco consiga lê-lo. XML significa Extensible Markup Language (Linguagem de Marcação Extensível). Linguagens de marcação compreendem todas aquelas que possibilitam a formatação de elementos por meio de tags e atributos como o HTML e XHTML. Por ser extensível, o XML possibilita a criação de elementos, ou seja, você mesmo pode inventar as suas tags. (DÉCIO, 2000). 67

72 Alguns dos propósitos do XML consiste em auxiliar os sistemas de informação no compartilhamento de dados (especialmente via internet), codificar documentos e inserir seriais nos dados comparando o texto com o de outras linguagens baseadas em serialização (PEREIRA, 2006) JSON Segundo AUGUSTO (2009), o JSON pode substituir o XML, e faz isso muito bem na hora de trabalhar com respostas em AJAX. A estrutura de dados fica mais simples de trabalhar e o tempo de execução de um script lendo dados em JSON é dezenas de vezes mais rápido do que ler um conteúdo XML. O JSON é um formato de troca de dados que também serve para serializar objetos. Um objeto na memória pode ser transformado em um formato independente da linguagem e ser transportado por qualquer meio até o seu destino, de maneira semelhante ao SOAP (SAMPAIO, 2007) PostSharp PostSharp Aspect Framework é uma implementação pragmática de conceitos POA. Todas as implementações ready-made de padrões construídos usando PostSharp Aspect Framework. Você pode usar a mesma tecnologia para automatizar a implementação de seus próprios padrões. (Postsharp.net, 2015). Uma vez o PostSharp estando instalado, você pode encapsular a funcionalidade transversal desejada em um método de aspecto e, em seguida, aplicar esse aspecto individualmente para as classes ou métodos desejados dentro do aplicativo de maneira declarativa e de maneira declarativa também usar seus atributos. (KUNK, 2012). PostSharp é uma extensão 100% compatível para o C# ou VB, linguagens que adicionam suporte para padrões de projetos e segurança de segmentos. As equipes que usam PostSharp são capazes de fornecer recursos com menos linhas de código e menos defeitos. (Postsharp.net, 2015). 68

73 4.2 Programação Orientada a Objetos Neste capítulo será realizado o detalhamento da implementação de um sistema de caixa eletrônico, baseado em todo o levantamento realizado na fase de modelagem Estrutura do projeto Para a estruturação do projeto proposto as classes foram divididas em três camadas (dados, interfaces e negócio), conforme demonstrado na Figura 44: FIGURA 44 - Estrutura do projeto (Fonte: Próprio Autor) A camada de dados é composta pelas classe Conta e as classes de Repositório. A classe Conta conforme demonstrada pela Figura 45 apresenta toda a estrutura do objeto Conta e algumas validações específicas deste objeto, suas declarações e seus tipos de transações possíveis, e também os atributos de um extrato. 69

74 FIGURA 45 - Classe Comuns (Fonte: Próprio Autor) Ainda dentro da classe Conta, também são apresentados os métodos específicos deste objeto, relacionados a controles. A Figura 46 apresenta informações dos métodos disponíveis. FIGURA 46 - Métodos classe Conta (FONTE: Próprio Autor) Abaixo serão apresentados detalhes sobre os métodos da classe Conta Authorized é utilizado para validação da conta. Nesse método é verificado se a conta não expirou, gravando a data da consulta em um arquivo. FilePath apresenta o local em que estão sendo salvas as contas criadas e seus históricos de transações. LoadAccount serve para verificar se os dados da conta existem nos 70

75 arquivos salvos, carregando assim suas informações em uma lista de objetos do tipo Conta. ValidPassword verifica se a senha da conta logada confere com a digitada pelo usuário. AddValue adiciona o valor na conta, gera um extrato e grava em arquivo. RemoveValue remove o valor da conta, gera um extrato e grava em arquivo. A Classe Repositório é uma classe polimórfica pai, a qual seta um padrão para que se possa salvar em arquivo formatado com estilo XML ou JSON. A Figura 47 apresenta a implementação da classe repositório. FIGURA 47 - Classe repositório (Fonte: Próprio Autor) Os métodos apresentados nas linhas 33 e 34, LoadAccount() e SaveAccount() possuem a assinatura da classe de repositório, e são implementadas nas classes de nome RepositórioXML.cs e RepositorioJson.cs. A Figura 48 apresenta esta implementação. 71

76 FIGURA 48 - JSON e XML (Fonte: Próprio Autor) É possível notar que cada uma das classes utilizou os dois métodos override, o qual são de assinatura da classe de Repositório. Sendo assim, os dois invocam os mesmos métodos, cada um utilizando implementações específicas. A camada Interface apresenta todas as classes WindowsForms, o qual constituise de telas do sistema. A camada de Negócio possui a classe Itransactions e a classe Transações que é responsável pela implementação de todos os métodos da classe de interface Itransactions, sendo responsável pelas principais operações do sistema. A Figura 49 serão detalhados os principais métodos de operação do sistema. 72

77 FIGURA 49 - Classe Transações (FONTE: Próprio Autor) Abaixo serão detalhados os principais métodos utilizados pelo sistema: Login, é utilizado para verificar os dados da conta do usuário, validando se a mesma existe, e também para carregar todas as informações do usuário, como por exemplo, sua senha, seu saldo e suas últimas transações. Logout verifica se a conta expirou seu tempo de atividade, ficando assim inativa e não liberando as operações. SetDepósit é utilizado para inserir o dinheiro na conta do usuário, como por exemplo na função depósito e na função transferência. SetTransfer é utilizado para a função transferência, utilizando mais dois métodos para a operação sendo eles o SetWithdraw e SetDeposit. GetBalance serve para obter o saldo atual da conta do usuário. SetWithdraw, é utilizado junto ao método de saque e transferência, sendo o responsável por remover o dinheiro da conta de origem. A classe Static existe para deixar o objeto Conta visível para todo o projeto, podendo ser chamado a qualquer instante. A Figura 50 traz a implementação dessa classe. 73

78 FIGURA 50 - Classe static Static (FONTE: Próprio Autor) A classe Trace serve para definir o diretório utilizado para salvar os arquivos de trace da aplicação. A Figura 51 apresenta o método Write da classe trace. FIGURA 51 - Classe Traces (FONTE: Próprio Autor) sistema. E por último tem-se a classe Program, responsável pelo start inicial do Na Figura 52 é possível visualizar seus métodos de inicialização. FIGURA 52 - Classe Program (FONTE: Próprio Autor) 74

79 Os métodos utilizados nas linhas 14 e 16, preparam os estilos que serão utilizados nas classes WindowsForm, e na linha 19 inicia a tela de login: Formlogin() o qual irá conhecer todos os métodos apresentados pela classe Transações, instanciada através da linha Entrelaçamento de Código (Tangled Code) Conforme verificado nos relacionamentos entre casos de uso e requisitos não funcionais, estas funcionalidades não funcionais, são passíveis de virarem uma classe de aspecto. Neste tópico serão apresentados alguns dos aspectos que serão implementados na fase de desenvolvimento. Na Figura 53, linha 63 é apresentada a função de validação de conta do usuário. Conforme requisito RNF.02, O sistema deve verificar se o tempo de acesso não expirou.. Essa validação é replicada em vários métodos da mesma classe, Realizar o Login, Logout, Transferência, Depósito e atualizar o Saldo ou Extrato. Gerando um excesso de informação, perdendo assim o foco na regra de negócio. FIGURA 53 - Método de validação de conta (FONTE: Próprio Autor) O método (!conta.autorized) é responsável por verificar se o usuário logado no sistema não excedeu seu tempo de utilização, expirando assim seu login no sistema. 75

80 Note que esta função é espalhada em vários métodos, conforme apresentado nas Figuras 54 a 58. FIGURA 54 - Método LoadAccount() (logout) (FONTE: Próprio Autor) FIGURA 55 - Método LoadAccount() (SetDeposit) (FONTE: Próprio Autor) FIGURA 56 - Método LoadAccount() (SetTransfer) (FONTE: Próprio Autor) FIGURA 57-7Método LoadAccount() (GetBalance) 76

81 (FONTE: Próprio Autor) FIGURA 58 - Método LoadAccount() (SetWithdraw) (FONTE: Próprio Autor) O mesmo ocorre para as chamadas de registro de logs de operação. A chamada Traces.Write é repetida por todo o código, chamando a classe de trace e adicionando o status atual do sistema junto ao método Write. O controle de exceção realizado pelo comando throw new exception também é controlado em cada método do sistema, onde se repete em todos os métodos para que em caso de uma ação inesperada o sistema apresente o motivo desta exceção. Sendo assim, estes apresentam características semelhantes durante a operação de um sistema, pois todos estão espalhados por todo o sistema, ocasionando pela falta de um controle centralizado. 4.3 Programação Orientada a Aspectos Nesta seção será transformado o desenvolvimento apresentado no tópico anterior, baseado nos conceitos estudados anteriormente. A ideia principal deste desenvolvimento será focada na utilização de 3 (três) aspectos já apresentados no tópico anterior, para que seja possível apresentar uma solução compacta onde demonstre a eficácia da solução, junto aos seus pontos de funcionamento. O principal diferencial da POA é a facilidade de modularização dos interesses transversais, complementando a POO, e para o seu funcionamento, são necessárias três etapas distintas para a fase de desenvolvimento. Na Figura 59 são apresentadas as etapas de desenvolvimento de software orientado a aspectos, extraída de LADDAD (2003). 77

82 FIGURA 59 - Etapas de Desenvolvimento de Software Orientado a Aspectos (FONTE: LADDAD, 2003) Decomposição dos interesses (aspectual decomposition): identificar e separar os interesses transversais dos interesses do negócio; Implementar os interesses (concern implementation): implementar cada um dos interesses identificados separadamente; Recompor os aspectos (aspectual recomposition): nesta etapa, tem-se o integrador de aspectos que especifica regras de recomposição para criação de unidades de modularização. A esse processo de junção da codificação dos componentes e dos aspectos é dado o nome de combinação (weaving) Estrutura do projeto orientado a aspecto A estrutura do projeto ficou similar ao já apresentado com a solução orientada a objeto. Sendo assim, as classes foram separadas nas camadas (dados, interfaces, negócio e aspectos). A Figura 60 apresenta esta estrutura. 78

83 FIGURA 60 - Estrutura de projeto com implementação de aspecto (Fonte: Próprio Autor) Como a estrutura acima já foi apresentada anteriormente, o próximo passo consiste na apresentação dos conceitos levantados na revisão bibliográfica Classes de aspecto Para a criação dos aspectos foi utilizado o Framework do Postsharp, disponibilizado em sua biblioteca uma estrutura de aspectos prontos para utilização. Para realizar a instalação basta acessar o site: navegar até a aba de download e baixar a versão Após a instalação deve ser verificado se o Postsharp ficou referenciado no projeto, conforme demonstra a Figura

84 FIGURA 61 - Biblioteca PostSharp (Fonte: Próprio Autor) Também é possível realizar a instalação do Postsharp via Gerenciador Nuget de pacotes. Feito isto, basta criar uma nova classe de aspectos adicionando a Tag [Serializable], responsável por deixar a classe visível para que o compilador utilizea em tempo de execução. Para definição do tipo de execução de um aspecto, o Postsharp disponibiliza algumas interfaces prontas para sua implementação, como por exemplo, o OnMethodBoundaryAspect, o qual já disponibiliza a estrutura de métodos para serem utilizados quando esta classe for executada. Os métodos podem ser utilizados antes ou depois da execução do método que invocou o aspecto através dos métodos OnEntry e OnExit. Também é possível utilizar alguns métodos prontos que o postsharp oferece, como é o caso do OnException, que trata exceções no formato de aspecto identificando que deve ser invocado após o acionamento de uma exceção no fluxo principal do programa. A Figura 62 representa a nova classe Aspecto_Security, responsável por validar se não expirou a sessão da conta do usuário que está acessando o sistema. 80

85 FIGURA 62 - Implementação aspecto de segurança (Fonte: Próprio Autor) As linhas 10 e 11 apresentam a estrutura da classe de aspecto. A linha 13 apresenta o momento que será executado o método apresentado nas linhas 15 à 19. Ou seja, nesse caso a clausula OnEntry representa que o método será executado antes do método que o aspecto será inserido no fluxo principal. Para utilizar a classe de aspecto demonstrada acima, basta evidenciar sua necessidade através da marcação [Aspecto_Security]. A Figura 63 apresenta a utilização deste aspecto no fluxo principal, através da classe Transação. FIGURA 63 - Aspecto Segurança (Fonte: Próprio Autor) A linha 79 apresenta a marcação informando ao compilador que ao executar o método SetWithdraw, deverá antes acessar a classe Aspecto_security, para interceptar qual deve ser o momento da execução deste aspecto, sendo para este caso no início do método, ou seja, antes de executar a validação realizada na linha

86 Toda essa implementação de aspecto é tratada dentro dos conceitos utilizados pela POA. No próximo tópico serão detalhados tais conceitos com exemplos utilizados na implementação Classificação de conceitos Nesta seção são apresentados na pratica os principais conceitos da POA, demonstrando suas funções junto ao código implementado do sistema proposto Advice O Advice nada mais é do que o aspecto que está sendo centralizado em uma nova classe. Sendo assim, é o código que será executado em um determinado momento da interrupção do fluxo principal para execução de um código secundário. As Figuras 64, 66 e 66 representam exemplos de advices. FIGURA 64 - Advice Log (Fonte: Próprio Autor) FIGURA 65 - Advice Exception (Fonte: Próprio Autor) 82

87 FIGURA 66 - Advice Security (Fonte: Próprio Autor) Pointcut O Pointcut é um ponto bem definido no fluxo principal do sistema o qual informa o momento de uma interrupção para que seja realizada a execução de um Advice. A Figura 67 representa um exemplo de Pointcuts. FIGURA 67 - Exemplo de Pointcuts (Fonte: Próprio Autor) A marcação [Aspecto_Exception] trata de um pointcut o qual deve interromper o método SetDeposit para tratar a execução, conforme descrito por um Advice, assim como o pointcut [aspecto_log] Joinpoint O Joinpoint é definido por um conjunto de pontos bem definidos no fluxo principal do sistema, o qual une os advices aos Pointcuts. A Figura 68 representa a estrutura de um conjunto dos Joinpoints da classe Transação. 83

88 FIGURA 68 - Aspecto inserido no fluxo principal (Fonte: Próprio Autor) Quaisquer classes com um conjunto de aspectos implementados formam uma estrutura chamada de joinpoints, onde sua responsabilidade é ligar esses com as classes de aspecto e seus devidos métodos. 4.4 Diferencial entre a programação orientada a aspecto sobre a orientada a objeto A POA surgiu com o objetivo de melhorar a modularização dos interesses transversais, envolvendo os requisitos não-funcionais, que tem influência em todo o programa, por meio de abstrações que possibilitam a separação e composição destes interesses para construção de um sistema de software aspectual. Desde então são realizadas pesquisas sobre o assunto para se determinar se a POA é ou não um 84

89 mecanismo eficaz para o desenvolvimento de software, com o seu foco voltado à separação de interesses. Abaixo serão apresentadas as principais vantagens e desvantagens em utilizar a POA Vantagens: Foi possível identificar diversos benefícios que foram supridos pelo surgimento da POA em relação à POO. Dentre eles pode-se destacar: Melhor modularização Foram definidos alguns módulos, os quais foram separados fisicamente em classes de aspectos com características específicas tais como: segurança, tratamentos de exceções e auditoria. Isso possibilitou o tratamento de assuntos transversais em classes individuais tornando o código mais conciso e fácil de manter Menos responsabilidades em cada parte Foi possível constatar que utilizando aspectos para tratar questões relativas à segurança, log do sistema e tratamento de exceções elimina-se os códigos replicados. Assim, a repetição de trechos de código como blocos Trace.write ou "if(!conta.authorized)" são evitados, centralizando estes códigos em classes específicas Facilidade para manutenção Como as classes em aspectos tem-se menos responsabilidades no contexto geral do sistema, tornando o código mais enxuto, as classes de regras de negócio apresentam uma menor complexidade lógica, mantendo em seus métodos apenas o que se propõe a fazer, gerando uma facilidade em se realizar uma manutenção pela centralização de códigos específicos nos aspectos e de fácil identificação no sistema Facilidade de evolução Com a centralização das classes de aspecto, o desenvolvedor pode se focar nas 85

90 regras de negócio, sem se preocupar com o código transversal, sendo assim, para cada nova implementação serão recuperados os códigos já criados de maneira simples e objetiva, aumentado assim a produtividade e facilitando a evolução Menor tempo e custo de desenvolvimento Com a utilização da separação de interesses, os desenvolvedores podem ser melhor distribuídos em um projeto, cada um com foco no que é de seu conhecimento e realmente necessário, como por exemplo, uma equipe poderá cuidar da implementação dos aspectos de log, persistência, exceção, segurança, e outra equipe focará com a implementação das regras focadas no que realmente o sistema se propõe a fazer sem se preocupar com características paralelas as quais poderão ser aproveitadas em qualquer parte do sistema. O fator (facilidade de manutenção) também apresenta grandes benefícios para que o desenvolvedor identifique uma falha e possa corrigi-la com a perda de um menor tempo de procura e manutenção Menor quantidade de linhas programadas Foi feita uma contagem do número de linhas de código gerada por cada versão do aplicativo, onde se obtiveram os seguintes resultados apresentado no Quatro 17. QUADRO 17 - Comparação entre a quantidade de linhas implementadas Tecnologia Classe1 Linhas de código Classe 2 Linha de código POO Transações 173 Aspectos 32 POA Transações 93 Aspectos 50 (Fonte: Próprio Autor) Analisando os dados obtidos, observou-se uma pequena redução no número de linhas do aplicativo feito em POA. Essa redução é proporcional à quantidade de aspectos que forem implementados: quanto mais aspectos, menos código replicado e consequentemente menos linhas de código geradas. É importante frisar que não foram analisados todos os possíveis casos onde a POA poderia ser aplicada nesse software, 86

91 apenas os casos principais. Portanto, a redução de código poderia ser ainda maior Desvantagens: Apesar de todos os benefícios gerados pelo uso da POA em relação ao uso da POO, é importante destacar alguns pontos negativos que devem ser analisados antes de se adotar esse novo paradigma de programação. Dentre eles se destacam os descritos a seguir Pouco material de pesquisa disponível Por se tratar de um paradigma de programação mais recente, uma das maiores dificuldades encontradas para o desenvolvimento desse trabalho foi a limitação de fontes didáticas disponíveis para a busca de conhecimento sobre esse assunto. Apesar da existência de alguns bons livros, a POO leva bastante vantagem sobre a POA nesse quesito, pois é um paradigma já consolidado e amplamente difundido Compilação mais lenta (Performance) Foi possível observar, durante o desenvolvimento desse projeto, que o processo de compilação em POA é mais lento que em POO. Muito provavelmente isso se deve ao fato de antes da compilação ocorrer, um processo é realizado pelo Combinador Aspectual (Weaver). Como dito anteriormente, ele combina as classes escritas em linguagem de componentes, com as classes escritas em linguagens de aspectos. A criação desse código intermediário, que precede a compilação, gera atrasos Refatoração de software orientado a objeto Existe uma dificuldade para refatorar um software já finalizado orientado a objeto, pois a geração de aspectos está ligada a fase de modelagem, e muitos sistemas passaram por incrementações e evoluções não documentadas, sendo necessário um novo projeto de modelagem de forma a identificar todos os aspectos para implementação. 87

92 5 APRESENTAÇÃO DO SISTEMA Mesmo com o foco do trabalho voltado para esse novo conceito do paradigma orientado a aspecto e não para o produto, para mostrar a aplicabilidade da POA foi desenvolvido um protótipo referente a operações básicas de um caixa eletrônico, com intuito de demonstrar um comparativo da POO versus a POA. O sistema desenvolvido permite operações como por exemplo a realização de um saque, depósito, transferência e extrato. O protótipo ficou dividido em 8 telas, sendo a primeira: Tela de Login prevista na modelagem, onde permite acessar as demais opções do sistema descrita na Figura 69. FIGURA 69 - Tela de login do protótipo (Fonte: Próprio Autor) Para acessar o sistema basta digitar os dados da Agência e Conta, clicando após em Confirma. Caso não possua estes dados, para facilitar a criação de uma nova Agência e Conta, basta realizar a tentativa de Login utilizando uma conta ainda não cadastrada que o sistema se encarregará de criá-la, trazendo a senha padrão 123. Na segunda tentativa com esta mesma Agência e Conta, o sistema liberará a sessão de 88

93 acesso com este novo usuário criado. A segunda tela contém as Opções de Operações, apresentando todas as opções disponíveis para utilização, bastando selecionar a desejada. Figura 70. FIGURA 70 - Tela Operações Protótipo (Fonte: Próprio Autor) Iniciando pela função saque, a próxima tela é a de seleção de valores. Nesta tela deve ser informado o valor que se deseja realizar o saque, confirmando a operação clicando em Confirma. Figura 71. FIGURA 71 - Operação Saque Protótipo (Fonte: Próprio Autor) Na sequência aparecerá uma nova tela para confirmação da conta através de uma senha. Figura

94 FIGURA 72 - Operação Saque Protótipo (Fonte: Próprio Autor) A segunda opção é a de depósito, bastando digitar o valor que se deseja depositar que será automaticamente debitado na conta logada no sistema. Figura 73. FIGURA 73 - Operação deposito Protótipo (Fonte: Próprio Autor) A terceira opção é a transferência, nessa tela deve ser informado os dados da agência e da conta em que se deseja realizar a operação. Também deve ser digitado o valor que se deseja transferir. Figura

95 FIGURA 74 - Operação Transferência Protótipo (Fonte: Próprio Autor) Para continuar a operação basta clicar em Confirma, que o sistema irá validar os dados da agência e conta digitada, e caso exista, será apresentada uma nova tela para que se confirme a operação através de uma senha. Figura 75. FIGURA 75 - Confirmação transferência Protótipo (Fonte: Próprio Autor) Nessa tela, basta digitar a senha e clicar em Confirma, que após a validação da senha a operação será realizada. 91

96 A última função disponível é o extrato. Selecionando essa opção, serão apresentadas todas as transações realizadas e salvas no histórico. Figura 76. FIGURA 76 - Operação extrato Protótipo (Fonte: Próprio Autor) 92

97 6 CONCLUSÃO Conforme apresentado no levantamento bibliográfico, as empresas de softwares investem cada vez mais em melhorias relacionadas a modularização dos seus projetos, tendo assim um retorno positivo quanto ao tempo de desenvolvimento, evolução, correção de falhas e manutenções. Devido a POA permitir uma melhor distribuição de um mesmo projeto, está em grande evolução no estudo entre os arquitetos de softwares. A evolução deste conceito também se dá devido a ampla quantidade de Frameworks disponíveis no mercado para diversas linguagens, dentre elas as mais conhecidas como C, C# e Java. Porém, a falta de documentações claras quanto suas utilizações desfavorecem sua evolução. Analisando o paradigma do ponto de vista da solução implementada, é notório que as vantagens apresentadas trazem grandes benefícios para as empresas de softwares, sendo que o foco na fase de modelagem traz uma outra perspectiva no ponto de vista do desenvolvimento da solução proposta. A utilização dos requisitos não funcionais para eliciação dos aspectos, facilita a identificação das características transversais, podendo assim verificar o impacto para o sistema, avaliando a possibilidade de implementação dos requisitos separado do fluxo principal. Sendo assim a POA se mostrou de grande eficácia pelo que se propõe a fazer, pois mesmo com poucos aspectos implementados, ficou visível que as classes ficaram mais coesas, apresentando maior modularização, sendo elas mais legíveis, não necessitando que o desenvolvedor implemente a todo momento a mesma função, aumentando a produtividade e o foco no que é de interesse, gerando assim um código com menos linhas implementadas. 93

98 REFERÊNCIAS BIBLIOGRÁFICAS ADAMS, Bram; SCHUTTER, Kris; ZAIDMAN Andy, AOP for Legacy Environments, a Case Study Disponível em: < eiwas2005/papers/eiwas2005-bram%20adams.pdf > acessado em: 13 Jun ANDRADE, Carlos; BORBA, Paulo H; SANTOS, André. Uma extensão Orientada a Aspectos de Hasekel. Disponível em: < view/rita_v11_n2_p21-32 > acessado em: 05 de Ago ARCHER, Tom, Inside C# (Microsoft Programming) Second Edition. Washington: Paperback, ASLAM, Toheed; BODZAY, Andrew. A FRAMEWORK FOR DYNAMIC SCIENTIFIC LANGUAGES. Disponível em: < mclab/aspectmatlab/index.html > acessado em: 06 de Ago ASPECTC++, AspectC++ Documentation. Disponível em: < > acessado em: 10 de Jun ASPECTLUA. Aspect-Oriented programming in Lua. Disponível em: < Acessado em: 08 de Jun ASPECTSCHEME. AspectScheme. Disponível em: < > acessado em: 05 de Ago AUCLAIR, Douglas. Aspect-Oriented Programming in Prolog. Disponível em: < > acessado em: 01 de Ago AUGUSTO, Danilo. O que é JSON, como e quando utilizar?. Disponível em < Acessado em 13 de Set AVRAM, Abel. Delphi Prism 2010 Oferece um Melhor Desenvolvimento.NET. Disponível em: < > Acessado em: 17 de Jun BARDOU, D. Roles, Subjects and Aspects: how do they relate? In: WORKSHOP ON OBJECT-ORIENTED TECHNOLOGY, ECOOP 98, 12, 1998, Brussels. Berlin: Springer-Verlag, p (Lecture Notes In Computer Science; v. 1543). 94

99 BARNES Jhon, Rationale for Ada 2012: Introduction Reino Unido. BATEMAN, CORFIELD, ROSS, SCOTT e WIERSMA, 2015). BOOCH Grady; IVAR, Jacobson; RUMBAUGH, James. UML Guia do Usuário. Rio de Janeiro: Elsevier, BRAYANT, Avi; FELDT, Robrt. AspectR - Simple aspect-oriented programming in Ruby. Disponível em: < > acessado em: 07 de Ago CAHILL, Vinn, DEMPSEY, John, y. Aspects of System Support for Distributed Computing. Proceedings of the Aspect-Oriented Programming Workshop at ECOOP 97, Finlândia: Springer-Verlag LNCS, CHAVEZ, C. A Model-Driven approach to aspect-oriented design. 2004, 305 p. Tese de Doutorado Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática, Rio de Janeiro, Março de Coady, Yvonne; Feeley, Mike; Smolyn, Greg; Kiczales, Gregor. Using AspectC to Improve the Modularity of Path-Specific Customization in Operating System Code. Columbia, COCOADEV. Aspect Oriented Programming Framework for Cocoa and Objective-C. Disponível em: < > acessado em: 14 de Jun COSTANZA, Pascal. AspectL - Release Notes. Disponível em: < > acessado em: 15 de Jun CZARNECKI Krzysztof, EISENECKER, Ulrich. Generative Programming: Methods, Tools, and Applications. Addison-Wesley, DÉCIO, Otávio C. Guia de consulta rápida: XML. São Paulo: Novatec, DIJKSTRA, E., A Discipline of Programming. Pretice-Hall, Upper Sadlle River, 1976, NK, USA. ELRAD, T.; Aksit, M.; Kiczales, G.; Lieberherr, K.; Ossher, H. Discussing Aspects of AOP. Communications of the ACM, October FABBRO, Luís Gustavo. Artigo: O que é Programação Orientada a Aspectos (POA)? Disponível em: < acessado em: 27 de Fev FALBO, R. De Almeida. Artigo: A Experiência na Definição de um Processo Padrão Baseado Disponível em: < Acessado em: 26 de Jul. de

100 FRANCO, Ana Paula M., Métodos e representações de suporte à aquisição de linguagens da aplicação. Dissertação de Mestrado da PUC-Rio, Abril GARCIA, A. et al. PUC-Rio: Poster Session. In: BRAZILIAN WORKSHOP ON ASPECT-ORIENTED SOFTWARE DEVELOPMENT, Brasília, Brazil, GROVES, Matthew D. AOP in.net; practical aspect-oriented programming. Canada: Manning Publications, GROOVY Objects implements. Disponível em < > acessado em: 02 de Ago GUEDES, Gilleanes T.A. UML 2 Guia de Consulta Rápida Segunda Edição. São Paulo: Novatec Editora Ltda, Novembro de GNU, Appendix D X Options and Resources Disponível em: < 2015> Acessado em: 03 de Ago HIRRSCHFELD, Robert. AspectS Aspect-Oriented Programming with Squeak. Disposnível em: < ogrammingwithsqueak_lncs2591.pdf > acessado em: 06 de Ago HOOKS, Function. Advice is best for end user programming, HODGES, Nick. Developer Skill Sprints - Aspect Oriented Programming using DSharp with Nick Hodges. Disponível em: < index.php/article/technical-articles/1016-developer-skill-sprints-aspect-orientedprogramming-with-nick-hodges > acessado em: 13 de Jun KENNEDY, Adam. Aspect - Aspect-Oriented Programming (AOP) for Perl. Disponível em: < > acessado em: 01 de Ago KICZALES, G. et al. Aspect-Oriented Programming. In: European Conference on Object-Oriented Programming, London. KUNK, Joe. Aspect-Oriented Programming with PostSharp. Disponível em: < Acessado em: 14 de Set LADDAD, Ramnivas. AspectJ in Action, Second Edition. Enterprise AOP with Spring Applications. Greenwich, London, LAMPING, J. (1999). The Role of Base in Aspect-oriented Programming. In: Int l Workshop on Aspect-Oriented Programming At Ecoop

101 LEITE, J.C.S.P., Oliveira, A.P.A, A Client Oriented Requirements Baseline. In Proceedings of the Second IEEE International Symposium on Requirements Engineering, York, UK, IEEE Computer Society Press, 1995 pp LIGATTI, Jay; ZDANCEWIC, Steve; WALKER, David. AspectML - Aspectoriented Functional Programming Language Research. Disponível em: < > acessado em: 02 de Ago MCIS. MCIS LAB MAINTENANCE CONSTRUCTION AND INTELLIGENCE OF SOFTWARE. Disponível em: < > acessado em: 01 de Ago NELSON, Torsten. Aspectos, Treinamento e Consultoria em Engenharia de Software. Belo Horizonte, 01 de novembro de OMG. UML 2 Infrastructure Final Adopted Specifcation. Whitepaper, Object Management Group, September PACIOS, S. F. Uma abordagem orientada a aspecto para desenvolvimento de linhas de produtos de software PARNAS, D. On the Criteria To Be Used in Decomposing Systems into Modules Communications of the ACM, Vol. 15, No. 12, P PEREIRA, Gisele Floriano. Desenvolvimento do Sistema Web do Observatório Astronômico da UFSC f. Graduação (Bacharel) - Curso de Sistemas deinformação, Universidade Federal De Santa Catarina, Florianópolis, Cap. 3. Disponível em: < Acessado em 11 de Maio de 2013>. Acessado em> 10 de Set PFLEEGER, S.L., Engenharia de Software: Teoria e Prática, São Paulo: Prentice Hall, 2ª Edição, PODILA, Pavan. Dotspect Project Home Disponível em: < > acessado em: 04 de Jun POSTSHARP.NET. What is postsharp. Disponível em: < >. Acessado em: 13 de Set RESENDE, Antônio M. Pereira; SILVA, Claudiney Calixto. Programação Orientada a Aspectos em Java: Desenvolvimento de Software Orientado a Aspectos. Rio de Janeiro Brasport, PHPASPECT, PHPAspect Programing if aspect. Disponível em: < > acessado em: 15 de Ago RICARTE, Ivan Luiz Marques. Programação Orientada a Objetos: Uma 97

102 Abordagem com Java. UNICAMP, SAMPAIO, Cleuton. Web 2.0 e mashups: Reinventando a Internet. Brasport, SEABRA, Rodolfo Moacir Jr. Análise e projeto orientado a objetos usando UML e o Processo Unificado. Disponível em: < es/exemplo-rup-rodolfo-seabra.pdf>. Acessado em: 01 de Ago SERSON, Roberto Rubinstein. Programação Orientada a Objetos com Java Curso Universitário. Rio de Janeiro: Brassport, SILVEIRA, Fábio F. et al. Uma abordagem sobre atualização dinâmica em componentes de sistemas orientados a objetos. São Paulo, SOARES, Sergio; BORBA, Paulo. Implementing distribution and persistence aspects with AspectJ. ACM Sigplan Notices , Pernambuco, SOMMERVILLE, I. Engenharia de Software. 6ª Ed. São Paulo: Addison Wesley, SOMMERVILLE, I. Engenharia de Software. 8ª Edição. São Paulo: Pearson Addison Wesley, WARD, James. Introducing Mixing Loom Runtime ActionScript Bytecode Modification. Disponível em: < > Acessado em: 17 de Jun WAZLAWICK, R. Sidinei. Engenharia de software: conceitos e práticas. Rio de Janeiro: Elsevier, WINCK, D. V.; GOETTEN JUNIOR, V. AspectJ: programação orientada a aspectos com Java. São Paulo: Novatec APÊNDICE 98

103 APÊNDICE A ARTIGO

104 APÊNDICE A - ARTIGO A importância dos requisitos não funcionais no desenvolvimento de um sistema orientada a aspecto José Augusto Z. Franklin, Hugo Estevam R. Longo Sistemas de Informação Universidade do Planalto Catarinense (UNIPLAC) Lages SC Brasil Departamento de Tecnologia da Informação - Universidade do Planalto Catarinense guto2908@live.com, hugoestevamrl@hotmail.com Abstract. The article proposes an analogy to the object-oriented programming format, noting the difficulties in controlling cross characteristics, emergence a new concept of aspect-oriented programming. In this section will appear for function format, key concepts and their idea of separation of crosscutting concerns, focusing on system modelling phase which will demonstrate the importance of non-functional requirements for identification of aspects. And lastly present a way to create a look with real examples of use. Resumo. O artigo propõe uma analogia ao formato de programação orientado a objeto, observando suas dificuldades no controle de características transversais, surgimento um novo conceito de programação orientada a aspecto. Nesta seção será apresentado quanto ao seu formato de funcionamento, principais conceitos e sua ideia de separação de interesses transversais, tendo como foco a fase de modelagem do sistema o qual demonstrará a importância dos requisitos não funcionais para identificação dos aspectos. E por último apresentará uma maneira de criação de um aspecto, com exemplos reais de utilização. 1. Introdução Durante anos, os engenheiros de softwares lutam quanto à estruturação de códigos, a fim de maximizar sua reutilização e diminuir o risco de defeitos de um sistema. Enquanto a (POO) Programação Orientada a Objeto fornece uma estrutura sólida para a organização de códigos, acaba apresentando dificuldades para reutilizar características transversais, apresentando problemas de entrelaçamento e espalhamento de código. O autor Kiczales (1997) e sua equipe descrevem os problemas que (POO) Programação Orientada a Objeto foi incapaz de capturar e resolver de uma forma clara. Eles observaram que essas preocupações transversais acabaram sendo espalhadas por todo o código, deixando este 100

105 com um emaranhado de código, se tornando cada vez mais difícil de desenvolver e modificar. Eles analisaram todas as razões entre as técnicas utilizadas para identificar o motivo de se apresentar este descontrole, resultando neste emaranhamento, possibilitando o surgimento de um novo conceito de programação orientada a aspecto. 2. Dificuldades encontradas na Programação Orientada a Objetos Mesmo com a programação orientada a objeto sendo o padrão mais utilizado nos dias atuais nas comunidades cientifica, comercial e acadêmica, neste conceito algumas dificuldades são apresentadas referente ao controle de características transversais, apresentando um descontrole nos códigos que ficam espalhado por todo o sistema trazendo maior deficiência no desenvolvimento de um sistema. A Figura 1 representa esta dinâmica de entrelaçamento de código. Figura 1. Características transversais em camadas Observando a Figura 1, fica visível a representação de três classes (conta, pedido e estoque), onde possuem métodos específicos para cada operação, porém junto a estes métodos existirão códigos redundantes e paralelos, misturando conceitos da classe de negócio com os códigos de Segurança, Visualização e Persistência. Sendo assim, estes códigos atravessarão todas as camadas do sistema, ficando a implementação destes códigos paralelos deficitário para se manter e evoluir durante a fase de desenvolvimento. Esse código intrusivo também pode ser observado através da Figura 2(a), o qual analisando as linhas 34 e 42 e 50 os códigos acabam deixando lógica do sistema embaralhada, portanto, assuntos que deveriam ser tratados somente em suas classes de origem estão sendo tratadas em outras classes. 101

106 Figura 2. Código com características transversais Neste caso é possível notar que o método conectar() se faz presente em diversas classes, podendo também ser espalhados em diversas partes de um programa. A manutenção para uma alteração desse método impactara em todas as classes que fazem uso deste. Por exemplo, a Figura 2(b) representa a alteração desse método, note que neste formato o desenvolvedor deve procurar em todo sistema o método conectar(), e realizar sua alteração de forma descentralizada, necessitando de uma maior quantidade de tempo para esta atividade. Sento assim, este código redundante distribuído pelo sistema representa o problema de entrelaçamento, com consequência no espalhamento de código em várias classes. Esta situação geralmente está associada a alguns problemas conhecidos, sendo eles: Baixa produtividade A implementação simultânea de múltiplos interesses muda o foco do desenvolvedor do interesse principal para interesses periféricos, gerando uma baixa produtividade. Menor reuso de código Devido as circunstâncias, um módulo implementa interesses múltiplos. Outros sistemas requerendo funcionalidades similares podem não conseguir utilizar o módulo prontamente, reduzindo ainda mais a produtividade. Qualidade de código baixa O Entrelaçamento produz código com problemas ocultos. Além disso, por atender a diversos interesses de uma só vez, um ou mais desses interesses podem não receber atenção suficiente. Dificuldade de compressão Fica difícil de saber exatamente o que ocorre com uma classe ao ler o seu código, pois as chamadas referentes ao entrelaçamento estão fora da mesma. Problemas de manutenção Como não se tem um código centralizado a necessidade de alteração de uma nomenclatura irá impactar em diversos métodos do sistema, tendo que o desenvolvedor percorrer diversas linhas de códigos até certificar que todas sejam atualizadas. 102

107 Dificuldade de evolução Atender requisitos futuros pode obrigar a um retrabalho na implementação. Como a implementação não é modularizada corretamente, isso implica em modificar muitos módulos. Devido a todas as situações indesejadas expostas, em 1997 Kiczales, líder da Xerox, coordenou uma equipe de pesquisadores dos quais preocupados com estes problemas, estudaram os motivos destes códigos transversais, sendo os primeiros a descrever o conceito de Programação Orientada a Aspecto. 3. Fundamentos da Programação Orientada a Aspectos Segundo Hecht (2007), várias propostas surgiram nos últimos anos para permitir que interesses transversais sejam solucionados isoladamente, entre elas a Separação Multidimensional de Interesses (Multi-Dimensional Separation of Concerns), a Programação Orientada a Assuntos (Subject-Iriented Programming). No entanto, a técnica que mais se popularizou, gerando não só a maior quantidade de pesquisas, mas também as ferramentas mais avançadas foi a POA, ou (AOP, do inglês Aspect-Oriented Programming). A programação orientada a aspectos introduz novos conceitos à área da computação. Dentre eles, o principal é o aspecto, que, é a unidade de encapsulamento de uma funcionalidade ortogonal. 3.1 Importância da POA A POA complementa a POO, fornecendo outra maneira de pensar sobre a estrutura do programa. A unidade fundamental da modularidade em POO é a classe, enquanto que em POA a unidade de modularidade é o aspecto. Aspectos permitem a modularização de preocupações, tais como gerenciamento de transações que atravessam vários tipos e objetos. O principal objetivo da POA é separar o código referente ao negócio dos códigos transversais, uma divisão de interesses (requisitos), abrangendo o problema de legibilidade como a questão da modularidade Por exemplo, considera-se que uma aplicação bancária simplesmente transfere um valor de uma conta para outra, conforme ilustra a Figura 3. Figura 3. Operação transferência. Porém, numa aplicação bancária construída para o mundo real, este método de transferência está longe do adequado. É necessário incluir valores de segurança, que determinam se o usuário possui autorização para realizar a operação. É preciso também envolver a operação em uma transação para prevenir perda de dados. Finalmente, é preciso fazer o log dos dados da aplicação. Uma versão simplificada que contém estes novos objetos (concerns) está ilustrada na Figura

108 Figura 4. Códigos invasivos Comparando com a primeira versão, o código perdeu a sua elegância e simplicidade, depois que o código foi voltado para outros objetivos misturado com aquele que implementa as regras do negócio. Deve-se considerar o que ocorre quando é necessário alterar, por exemplo, a implementação de segurança da aplicação. No exemplo mostrado, o código é espalhado por vários métodos, e qualquer mudança significa um grande esforço de codificação. Por fim, pode-se dizer que este código não está devidamente encapsulado nos seus próprios módulos. Isto aumenta a complexidade do sistema e torna a manutenção do mesmo muito difícil. A POA então, busca resolver este problema permitindo que o programador implemente essas questões (segurança, log, transações, e etc.) através de aspectos. Em muitas linguagens que implementam POA, o aspecto é constituído de uma ou mais peças de advices (fragmentos do código, como métodos) e uma lista de joinpoints (pontos no programa principal na qual os advices são inseridos). 3.2 Conceitos e Terminologias Para compreender o funcionamento da AOP se faz necessário o conhecimento de alguns conceitos que formam a essência do paradigma. Abaixo será apresentado os principais conceitos: Aspectos: Um aspecto é o elemento básico para o encapsulamento de elementos que dão suporte ao uso da POA, sendo a implementação de um interesse transversal realizada de maneira independente da implementação dos requisitos centrais. Aspectos são definidos como propriedades de sistemas que afetam componentes e, mais especificamente, como propriedades que afetam o desempenho ou a semântica de 104

109 componentes de forma sistêmica (KICZALES, 1997). Os aspectos podem afetar um ou mais componentes, possivelmente afetando sua estrutura e comportamento. Além disso, amplia-se o uso do termo para denotar também um relacionamento genérico de um aspecto para um ou mais componentes JoinPoint. São métodos bem definidos na execução do fluxo do programa que compõem pontos de corte. Segundo (KICZALES, 2001), pontos de junção podem ser considerados como os nós do grafo de chamada de um objeto em tempo de execução. Nesse grafo, por exemplo, os nós incluem locais onde um objeto recebe uma chamada de método e locais onde um atributo de um objeto é referenciado, enquanto as arestas apresentam as relações de fluxo de controle entre os nós. Os pontos de junção são classificados em diversos tipos, dependendo do local específico onde eles residem no programa. PointCut: Pode ser entendido como uma variável. Esta variável armazena uma lista contendo as assinaturas de métodos que se tem interesse em interceptar. Esta interceptação é feita com o objetivo de alterar o fluxo original do programa e inserir novas chamadas, advices (RESENDE; SILVA, 2005). Advice: é uma estrutura que denota o que um aspecto deve fazer, ou seja, qual o comportamento do aspecto. O advice designa a semântica comportamental do aspecto. Todo advice está associado a um pointcut, que define pontos de junção. De acordo com o autor (NELSON, 2005), advice são construções semelhantes aos métodos, entretanto, não podem ser chamados diretamente pela aplicação base e nem pelo próprio aspecto, pois sua execução é feita automaticamente após o entrecorte no ponto de junção. Weaving - É o processo onde é feita a mesclagem dos módulos do sistema de acordo com os aspectos encontrados. O weaving é como uma outra etapa de compilação. Através de um compilador especial é possível montar o sistema final combinando os módulos principais e os secundários pelo método weaving (tecelagem), então tem-se o nome de weaver ao compilador. O weaver tem a capacidade de interceptar as chamadas de métodos em tempo de compilação ou execução, conforme seu propósito, podendo desviar o fluxo de execução e até mesmo abortar a execução do método (SILVEIRA et al., 2004). A linguagem de aspectos deve suportar a implementação das propriedades desejadas de forma clara e concisa, fornecendo construções necessárias para que o programador crie estruturas que descrevam o comportamento dos aspectos e definam em que situações eles ocorrem, para isso vale observar algumas situações que devem ser avaliadas antes de escolher o paradigma. 3.3 Problemas na utilização da POA Existem alguns pontos importantes que devem ser destacados antes de começar a utilização deste conceito orientação a aspecto, sendo o primeiro a depuração é um dos maiores problemas. Enquanto no nível sintático o código POA aparece em separado, ele está junto do restante do código em tempo de execução. (KICKZALES, 1997). 105

110 Outro problema com a POA é a captura não intencional de Join points através de wilcards. Por exemplo, supõem-se que seja especificado um determinado pointcut a um advice associado, e um wilcard para todos os métodos que tenham certo padrão de nomenclatura. Um programador desatento pode criar um método cujo nome seja compatível com esse wilcard, sem que seja essa a sua intenção, levando a execução inadvertida do advice. Da mesma forma, ao renomear um método, pode-se alterar completamente a sua semântica. 3.4 Benefícios da Programação Orientada a Aspectos Conforme apresentado nas seções anteriores, a POA trouxe algumas contribuições importantes para o desenvolvimento de sistemas no que se refere a facilidade de manutenção e reutilização de código. Dentre as diversas vantagens e benefícios que a POA dispõe, podem-se citar algumas delas na Tabela 1, conforme descreve o autor (GARCIA, 2006). Tabela 1. Vantagens e Benefícios disponível pelo paradigma orientado a aspecto. Características Benefícios Responsabilidades transparentes de cada módulo Modularização mais alta mais Cada módulo é responsável apenas pelas tarefas destinadas ao próprio módulo. Os módulos são mais independentes. As responsabilidades são melhor definidas em cada módulo pois estes possuem baixo acoplamento entre si. Evolução do sistema mais facilitada Decisões de design podem ser tomadas com mais atraso Mais reusabilidade do código Sistemas mais fáceis de desenvolver e manter Custos reduzidos de introdução de novas funcionalidades O baixo acoplamento possibilita que alterações no sistema sejam feitas sem alteração do núcleo. Devido ao baixo acoplamento não é necessário pensar em todos os problemas no início do desenvolvimento do sistema. Os módulos podem ser mais reaproveitados devido à alta coesão e baixo acoplamento. Os aspectos tornam a integração das partes do sistema um módulo separado, o que traz mais facilidade no desenvolvimento. Novas funcionalidades podem ser introduzidas criando aspectos, não sendo necessário alterar o núcleo para adicionar tais funcionalidades. Os benefícios da POA tais como modularização, evolutibilidade e a remoção das características negativas da presença dos interesses ortogonais do sistema, junto com a robusteza das linguagens orientadas a aspectos, faz com que o trabalho de reengenharia de sistemas OO seja muito recompensador. Em aspetos, uma das grandes dificuldades do processo de refatoramento é a determinação de pointcuts efetivos para interceptar a execução do 106

111 programa e redirecioná-lo para seu devido advice. Tal processo precisa ser realizado de tal forma que preserve o comportamento original (SILVA, 2011). 3.5 O Uso de POA em requisitos não funcionais A POA surgiu com o objetivo de melhorar a modularização dos interesses transversais, para isso a fase de separação de interesses é de extrema importância, visto que esta identificação servirá de moldura para os aspectos desenvolvidos. Os requisitos não funcionais apresentam características e especificações dos quais expressam detalhes de como as funcionalidades do sistema devem se comportar para alcançarem um determinado objetivo. Sendo assim, normalmente os requisitos não funcionais entrecortam várias classes do sistema, por estarem geralmente associados a camadas de (disponibilidade, segurança, log, persistência, design). Para facilitar a identificação dos aspectos, os requisitos não funcionais servem de pilar para iniciar a abstração destes. Após levantar todos os requisitos não funcionais, é possível classificar alguns requisitos passíveis a virarem aspectos, Para facilitar esta concepção, podese realizar o cruzamento de dados entre RNF versus casos de usos, como por exemplo o modelo criado para esta representação disponibilizado através da Figura 5. Figura 5. Requisitos versus Casos de uso Essa intersecção marcada por um múltiplo relacionamento é passível de ser implementada como um aspecto, de preferência que seja escolhido as intersecções que mais casos de usos afetarem. 4. Programação Orientado a Aspecto em Requisitos não-funcionais O principal diferencial da POA é a facilidade de modularização dos interesses transversais, complementando a POO, e para o seu funcionamento, são necessárias três etapas distintas para a fase de desenvolvimento. Decomposição dos interesses (aspectual decomposition): identificar e separar os interesses transversais dos interesses do negócio; Implementar os interesses (concern implementation): implementar cada um dos interesses identificados separadamente; 107

112 Recompor os aspectos (aspectual recomposition): nesta etapa, tem-se o integrador de aspectos que especifica regras de recomposição para criação de unidades de modularização. A esse processo de junção da codificação dos componentes e dos aspectos é dado o nome de combinação (weaving). Na Figura 6 é apresentado as etapas de desenvolvimento de software orientado a aspectos, extraída de LADDAD (2003). Figura 6. Etapas de desenvolvimento Orientado a aspecto A estrutura de um sistema orientado a aspecto inicia pela licitação dos requisitos transversais, dos quais conforme visto na seção anterior muitas vezes estão associados aos requisitos não funcionais. A fase de implementação é similar ao código que seria criado no fluxo principal no sistema. Finalizando com a recomposição realizada através do processo weaving responsável por juntar todas as camadas em um só Fluxo. Na próxima seção será apresentado uma forma de implementação dos aspectos utilizando a linguagem C# 4.1 Criando um Aspecto Atualmente muitos frameworks já estão disponíveis no mercado para implementação deste novo paradigma, como por exemplo, para a linguagem C# a biblioteca Postsharp, é um plugin para a ferramenta de programação Visual Studio. Sua instalação pode ser realizada via gerenciador Nuget de pacotes e em sua biblioteca tem-se disponível uma estrutura de aspectos prontos para serem utilizados, bastando criar uma nova classe incluindo em sua estrutura a Tag [Serializable], responsável por deixar está visível para que o compilador utilize a classe em tempo de execução. 4.2 Implementações de um aspecto Para criar um Advice (aspecto), o framework disponibiliza algumas interfaces prontas para implementação, como é o caso da interface OnMethodBoundaryAspect, o qual já disponibiliza em sua estrutura alguns métodos para serem implementados e utilizados quando a classe de aspecto for invocada. Um exemplo são os métodos OnEntry e OnExit, que servem para realizar uma instrução no início e (ou) no final do método principal que invocou a classe de aspecto. Para melhorar a abstração deste cenário e também exemplificando, imaginamos um sistema de frente de caixa eletrônico, o qual devemos implementar dois interesses transversais, sendo eles (manter um registro de log e realizar o tratamento de exceções). Para implementar uma estrutura de registro (log), pode ser utilizado o método OnEntry com o comando Console.Write("Entrando no método: " + args.method); servindo para registro do momento da entrada do método executado e também o método OnExit com o código Console.Write("Saindo 108

113 do método: " + args.method); para registro da saída do método executado. A Figura 7 representa está implementação. Figura 7. Códigos invasivos A cláusula args, serve de auxílio para passagem de contextos, esta opção já vem disponível na biblioteca utilizada. Para o exemplo representativo da Figura 7, a cláusula args.method retornará o nome do método em execução. No entanto, com esta estrutura pronta, para todo método criado o qual seria necessário reescrever todas as cláusulas de trace em cada método, agora pode ser inserido apenas um novo ponto de corte no método desejado através da marcação [ nome_classe_aspectoimplementado ] antes de se iniciar a estrutura do método que se deseje utilizar o aspecto. A Figura 8 representa a representação da implementação do aspecto citado a nesse exemplo. Figura 8. Fluxo de funcionamento de um aspecto Para a implementação da tratativa de exceções, o Postsharp também disponibiliza a interface OnExceptionAspect juntamente com o método OnException possibilitando a implementação de uma estrutura para tratamento de exceção, conforme apresentado pela Figura 9. A sua utilização funciona do mesmo formato descrito para o tratamento de log, sendo que deverá ser inserido um novo pointcut no fluxo principal do programa onde se queira introduzir este método. 109