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