370 likes | 474 Views
Introdução à AOP. Desenvolvimento de Sistemas Orientados a Aspectos Prof. Rodrigo Ribeiro. Evolução. Linguagens de programação Evolução dirigida pelas necessidades Assembly Linguagens de alto nível (não estruturadas). Linguagens estruturadas. Linguagens orientadas a objetos. Herança
E N D
Introdução à AOP Desenvolvimento de Sistemas Orientados a Aspectos Prof. Rodrigo Ribeiro
Evolução • Linguagens de programação • Evolução dirigida pelas necessidades • Assembly • Linguagens de alto nível (não estruturadas). • Linguagens estruturadas. • Linguagens orientadas a objetos. • Herança • Polimorfismo • Evolução: Permitiu gerenciar complexidade do software.
Evolução • Porém... • A evolução resolve antigos problemas... • A cada novo software, possivelmente novos problemas são levantados... • Possivelmente, abordagem atual não os resolve de maneira adequada. • Abordagem Atual: OOP. • Encapsulamento, Herança e Polimorfismo. • Mas a OOP resolve todos os problemas?
Evolução • Metodologia OOP • Padrões de projeto e de arquitetura de sistemas • Bom desenho de software custa $$$ • Dilema do arquiteto • Pergunta: Quanto de desenho é necessário? • Desenho Elaborado • Prevê mudanças de requisitos e se adapta bem a estas. • Porém pode ser difícil de implementar e entender • Custo e prazo de entrega elevados • Desenho normal • Custo e prazo de entrega OK. • Dilema do arquiteto: equilíbrio entre qualidade e custo
Evolução • Processos e metodologias de software • Mudanças de requisitos • Bom desenho • Permite a alteração e inclusão de novos requisitos • Usando OOP... • Existem requisitos que afetam diversos módulos já implementados. • Exemplo: Mudança de regras para autenticação • Alteração na regra • Possivelmente nos pontos de utilização
Evolução • OOP não resolve todos os problemas... • Sistemas de software e interesses • Software como um conjunto de interesses • Regras de negócio • Persistência de dados • Sincronização e concorrência • Logging • Segurança • Problema • Estes interesses se espalham por todo o software
Interesses e Requisitos • Requisitos (requirements) • Funcionalidades núcleo de um sistema • Ex: Gerenciamento de contas e clientes em um sistema bancário. • Interesses (concern) • Funcionalidades que são comuns aos requisitos. • Ex: persistência, logging, autenticação, etc... • Problema: O que é requisito e o que é interesse?
Separação de Interesses • Separando interesses... • Reduzimos a complexidade do sistema. • Implementação separada de interesses • Interesses são ortogonais • Ortogonal: Independentes • Ex: Alteração do mecanismo de persistência não deve modificar a implementação de outros interesses
Separação de Interesses Segurança Lógica de negócio Persistência
Implementação de Interesses • Tradicionalmente: • Segurança • Persistência • Lógica de negócio • Problema: • Como modularizar algo espalhado?
Implementação de Interesses • Exemplo • Sistema Bancário • Controle de contas, de clientes e módulo gerencial • Crédito e débito em contas • Cadastro de clientes e contas • Interesse: Logging • Registrar todo acesso ao sistema bancário • Objetivo: Auditoria de sistema • Problema • Interesse que se espalha por todos os módulos • Difícil reuso e manutenção
Implementação de Interesses Módulo de clientes Módulo de Logging Módulo de contas Chamadas de API Módulo gerencial
Implementação de Interesses • Queremos reutilizar interesses espalhados! • Mas como? • Linguagens estruturadas: funções • Linguagens OO: Classes • Usar tecnologia OO? • Não. Classes não são capazes de modularizar interesses espalhados. • Porquê?
Implementação de Interesses • Interesses espalhados são... • Espalhados! Problema: • Com OOP: • Interesses são concentrados em classes • Mas a utilização continua espalhada... • Então... • Temos que obter uma maneira para contornar isso... • Solução • Interesse concentrado em um único módulo. • Especificar regras para “misturar” interesse com o resto do código do programa.
Implementando Interesses - AOP Chamada de API Módulo de clientes Módulo de Logging Aspecto de Logging Módulo de contas Chamadas inseridas por um combinador (weaver) Módulo gerencial
Implementação de Interesses • Abordagem Tradicional – Logging publicinterface Logger { public void log(String message); }
Implementação de Interesses • Classe de Conta Bancária public class Account extends AbstractAccount{ //variáveis de instância da classe //instância do logger Logger logger = LoggerFactory.getLoggerInstance(); public void debit(Double value){...} public void credit(Double value){...} public void save(){...} public void load(){...} }
Implementação de Interesses • Método de crédito publicvoid credit(double value) { logger.log(“Init crediting:” + value); //manipulação do saldo... logger.log(“Finish crediting:”+ value); }
Interesses Transversais • Algumas observações... • Logging não é relacionada com contas bancárias... • Problema: • Desenho OO não adequado... • Método de crédito não somente manipula saldo: realiza logging. • Em sistemas OO reais... • Situação comum. Interesses espalhados por diversas classes.
Interesses Transversais • Sintomas • Código entrelaçado (code tanggling) • Um módulo implementa diversos interesses. • Código espalhado (code scattered) • Um interesse espalhado por diversos módulos.
Interesses Transversais • Código Entrelaçado Legenda: Lógica de Negócio Persistência Segurança Logging
Interesses Transversais • Código Espalhado Frente de caixa Internet banking Autenticação Caixa Eletrônico Banking phone
Interesses Transversais • Problemas • Difícil compreensão e evolução do código • Código espalhado • Menos reuso • Problema: Código entrelaçado • Menos qualidade • Código entrelaçado dificulta revisões de código
Introdução à AOP • AOP é baseada em... • Tecnologia orientada a objetos • Utilizada para representar requisitos de lógica de negócio. • Novos conceitos para representar interesses transversais • Aspecto: Encapsula um interesse transversal. • Ex: Classe de conta bancária • Não sabe que existe autenticação ou logging. • Autenticação e logging em um Aspecto.
Introdução à AOP • Realmente precisamos de AOP? • Não é possível resolver usando OOP? • Padrões de Projeto • Dynamic Proxy (Presente em Java >= 1.3) • Outras abordagens (Ainda em pesquisa...) • Programação orientada a sujeitos – Subject Oriented Programming • Programação Adaptativa – Adaptive Programming
Introdução à AOP • Padrão Proxy
Introdução à AOP • Dynamic Proxies • Recurso para modularizar o padrão Proxy • Dinamicamente associar o objeto ao seu proxy. • Baseado em Reflexão (Reflection) • Buschmann, 1996 • Problema • Reflection em Java compromete a performance... • Adequado para modularizar interesses simples...
Introdução à AOP • Metodologia AOP • Similar a OOP • Identificar requisitos (classes) • Implementá-las • Combiná-las • Em AOP... • Além de identificar requisitos: identificar Interesses! • Implementar • Combinar
Introdução à AOP • Metodologia AOP • Só uma metodologia não é útil • Java: Implementação de OOP • Definição da linguagem e ferramentas • Implementação de AOP • Precisamos de uma linguagem • Sintaxe e semântica definidas • Como implementar interesses transversais? • Ferramentas • Compilador, IDE...
Introdução à AOP • Características de uma linguagem AOP • Implementação de interesses transversais • Recursos para modularização similares a Java, C++... • Especificação de regras de combinação (weaving) • Regras de combinação • Determinam como combinar interesses para formar o sistema • Expressas declarativamente (Usando lógica, similar a Prolog) • Ex: Logging • Logging realizado em pontos especificados por regras de combinação • Ex: Autenticação • Verificação de permissões e acesso
Introdução à AOP AOP Weaver Lógica de negócio Sistema Final Interesses + Regras de combinação
Introdução à AOP • Benefícios • Permite tornar claras responsabilidades de cada módulo. • Maior modularização • Mais reuso • Facilidade de evolução • Decisões de desenho podem ser tomadas a posteriori • E isso leva a... • Redução de tempo de desenvolvimento de um projeto • Redução de custos.
Introdução à AOP • Mitos e realidades sobre AOP • Fluxo de execução difícil de entender • Verdade... • AOP não resolve novos problemas • Verdade... • AOP promove software´s de desenho ruim • Falso... • AOP substituirá a OOP • Falso...
Introdução à AOP • Na aula de hoje vimos... • Que a OOP não resolve todos os problemas • Dilema do arquiteto: Muito ou pouco desenho? • Conceitos de: • Requisitos • Interesses transversais • Código espalhado • Código entrelaçado • Características de uma linguagem AOP • Próxima aula... • Introdução à linguagem AspectJ