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
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
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
Lógica de negócioPersistência
Segurança
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 contas
Módulo gerencial
Módulo de Logging
Chamadas de API
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
Módulo de clientes
Módulo de contas
Módulo gerencial
Módulo de Logging
Chamada de API
Aspecto de Logging
Chamadas inseridas por um combinador (weaver)
Implementação de Interesses
Abordagem Tradicional – Logging
public interface Logger {
public void log(String message);
}
Implementação de Interesses Classe de Conta Bancáriapublic 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éditopublic void 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ócioPersistênciaSegurançaLogging
Interesses Transversais Código Espalhado
Frente de caixa
Caixa Eletrônico
Internet banking
Banking phone
Autenticação
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
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
Lógica de negócio
Interesses + Regras de combinação
AOPWeaver
Sistema Final
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
Top Related