Arquiteturas baseadas em camadas

Transcrição

1 Arquiteturas baseadas em camadas Por Sergio Crespo Prof. Dr. Sergio Crespo C S Pinto 2010/01

2 Introdução O problema fundamental a ser resolvido em grandes sistemas é justamente como quebrá-lo em pedaços de tal forma que seu entendimento, implementação e manutenção seja gerenciável por programadores humanos. Padrões de Projetos são uma boa receita de sucesso neste problema. São chamados de Padrões Arquiteturais (Architectural Patterns) que tratam do problema em alto nível e grande escala.

3 Architectural Patterns High level decompositions: Layers Façade Adapter Bridge MVC (ntrodução) Three-tier architecture Pipes and filters Blackboard Distributed systems: Broker Interactive systems: Model-view-controller Presentation-abstraction-control Adaptable/reusable systems: Microkernel Scripted components

4 Architectural Patterns: Layers O padrão Layer ajuda a estruturar aplicações que podem ser decompostas dentro de grupos de sub-tarefas, na qual cada grupo possui um particular nível de abstração.

5 Layers - Exemplos Protocolos de redes são os melhores exemplos de uso deste padrão. Um protocolo consiste de um conjunto de regras e convenções que descrevem como programas de computador se comunicam com outros em diferentes máquinas. Sendo assim, formatos, conteúdos e significado das mensagens precisam ser definidos.

6 Layers - Exemplos

7 Architectural Patterns: Layers Layers/Camadas: Problema O sistema tem diferentes níveis ou camadas de abstração Típico: Requisições para camada inferior e recebimento de notificãções que retornam desta camada.

8 Layers: Desafios Desafios: É possível definir uma interface estável entre estas camadas? Como fazer para adicionar ou alterar uma camada em tempo de execução? Como pensar a granularidade de uma camada? Qual a complexidade de uma camada? Se for muito complexo o seu entendimento o que fazer? Sub-dividir o problema em outra camada? Como gerenciar a performance? Por exemplo: quando uma grande quantidade de dados necessita ser transferida para ser processada por outra camada, como realizar esta atividade?

9 CRC card Classe Layer J Colaborador Cliente usa Layer J Responsabilidades Prover serviços que serão utilizados pela camada (Layer) J +1 Layer J - 1 Layer J - 1 Layer J - 2 Delegar sub-tarefas para a camada J - 1. Layer 1 A principal característica do Padrão Estrutural Layer é que o serviço provido pelo Layer J somente será usado pelo Layer J + 1

10 Exemplo Classe Layer J Responsabilidades Prover serviços que serão utilizados pela camada (Layer) J +1 Delegar sub-tarefas para a camada J - 1. Colaborador Layer J - 1 Layer 3 Componente 3.1 Componente 3.2 Componente 3.3 Layer 2 Componente 2.1 Componente 2.2 usa Componente 2.3 Layer 1 Componente 1.1 Componente 1.2 Componente 1.3

11 O que tem de estranho aqui? Classe Layer J Responsabilidades Prover serviços que serão utilizados pela camada (Layer) J +1 Delegar sub-tarefas para a camada J - 1. Colaborador Layer J - 1 Layer 3 Componente 3.1 Componente 3.2 Componente 3.3 Layer 2 Componente 2.1 Componente 2.2 usa Componente 2.3 Layer 1 Componente 1.1 Componente 1.2 Componente 1.3

12 Discussão Classe Layer J Responsabilidades Prover serviços que serão utilizados pela camada (Layer) J +1 Delegar sub-tarefas para a camada J - 1. Colaborador Layer J - 1 Layer 3 Componente 3.1 Componente 3.2 Componente 3.3 Layer 2 Componente 2.1 Componente 2.2 usa Componente 2.3 Layer 1 Componente 1.1 Componente 1.2 Componente 1.3

13 Passos 1. Definir critérios de abstração para o agrupamento de tarefas em uma camada. 2. Determine o número de níveis de abstração de acordo com um critério pré-estabelecido (quantas camadas). 3. Rotule as camadas e defina suas funcionalidades. 4. Especifique os serviços da camada. 5. Refine as camadas (revise os passos 1 a 4). 6. Especifique uma interface para cada camada. 7. Estruture a camada (se for complexa, pode conter mais de um componente) 8. Especifique a comunicação entre as camadas adjacentes. 9. Desacople camadas adjacentes. 10. Defina estratégias de manipulação de erros.

14 Benefícios e consequências do Padrão Layer Reuso de camadas. Auxilio a padronização. Dependências ficam somente no aspecto local. Facilidade de alteração. Cascata de mudança de comportamento de uma camada. Menor eficiência. Dificuldade de estabelecer a granularidade da camada.

15 Padrão Façade (GOF pg 179) Intenção: fornece uma interface unificada para um conjunto de interfaces em um subsistema. O Façade define uma interface de mível mais alto que torna o subsistema mais flexível.

16 Façade UML

17 Façade

18

19 Façade: Quando usar? Quande se deseja fornecer uma interface simples para um subsistema complexo. Quando existirem muitas dependências entre clientes e classes de implementação de uma abstração. Se você deseja estruturar seus subsistemas em camadas!

20 Façade: consequências do uso Isola os clientes dos componentes do subsistema, reduzindo o número de objetos com que os clientes têm de lidar e tornando o subsistema mais simples de usar. Promove um acoplamento fracoentre o subsistema e seus clientes. Façades ajuda a estratificar um sistema e as dependências entre objetos. Não impede as aplicações de utilizarem as classes do subsistema caso necessitem.

21 Como ficaria esta arquitetura usando um Façade? Layer 3 Componente 3.1 Componente 3.2 Componente 3.3 Layer 2 Componente 2.1 Componente 2.2 usa Componente 2.3 Layer 1 Componente 1.1 Componente 1.2 Componente 1.3

22 Façade: questão...para pensar (1).. Problema: Reusar APIs ou bibliotecas escritas usando linguagens NÃO orientadas a objetos. Estas APIs, por exemplo, acessam redes e macanismos de Threads, bem como interfaces ou Libraries. Como fazer para obter uma adaptação desta API para uma classe em um subsistema orientado a objeto? Pattern-Oriented Software Architecture Volume 2, Douglas Schmidt, Michael Stal, Hans Rohnert e Frank Buschmann, Wiley ed, 2001.

23 Padrão Adapter (GOF pg 140) Intensão: Converter uma interface de uma classe em outra, esperada pelos clientes. Permite que classes com interfaces incompatíveis trabalhem em conjunto. Este padrão é conhecido também como Wrapper.

24 Padrão Adapter: Motivação Considere por exemplo um editor de desenho que deixa usuários desenhar e posicionar elementos gráficos (linhas, polígonos, texto, etc.) em diagramas. Cada objeto gráfico tem a sua forma e pode desenhar a si próprio. A interface para objetos gráficos é definida por uma classe abstrata chamada Forma. O editor define uma subclasse de Forma para cada tipo de objeto gráfico: classe FormaLinha, classe FormaPoligono, FormaTexto, etc. A subclasse FormaTexto que pode mostrar e editar texto é muito difícil de implementar, pois a edição de texto envolve atualizações de tela complicadas e gerenciamento de áreas de memória. Uma biblioteca comercial poderia fornecer uma classe VisaoTexto que manipula texto pronta para usar. Continua..=>

25 Padrão Adapter: Motivação... O ideal seria reutilizar o VisaoTexto para implementar FormaTexto, mas a biblioteca não foi projetada para ser usada com a interface de Forma impedindo que estas classes se comuniquem. Poderíamos mudar a classe VisaoTexto conforme a interface de Forma, mas para isso precisaríamos do código fonte da biblioteca. Mesmo que tivéssemos, não faria sentido mudar VisaoTexto. A biblioteca não deveria adotar uma interface específica para que apenas uma aplicação funcione. Ao invés disto poderíamos definir FormaTexto para adaptar a interface da VisaoTexto para a interface da Forma. Isto poderia ser feito de duas maneiras: Herdando a interface de Forma e a implementação de VisaoTexto; Compondo uma instância de VisaoTexto dentro de FormaTexto e implementando FormaTexto através da interface de VisaoTexto.

26 Usando o Adapter

27 Padrão Adapter do exemplo Estrutura Um Adapter de classe usa múltiplas heranças para adaptar uma interface para outra: Um Adapter de objeto depende de composição de objeto: Participantes Alvo (Forma). Define o domínio específico da interface que o cliente usa. Cliente (Editor de desenho). Colabora com objetos conforme a interface Alvo. Adaptado (VisaoTexto). Define uma interface existente que necessita adaptação. Adaptador (FormaTexto). Adapta a interface do Adaptado para a interface do Alvo.

28 Padrão Adapter do exemplo... Cliente Alvo Adaptado Adaptador

29 Padrão Adapter: Quando usar? Se você quiser usar uma classe existente, mas sua interface não corresponde à sua necessidade, ou seja, não é compatível com a outra interface. Se você quiser criar uma classe reutilizável que coopere com classes não relacionadas o não previstas.

30 Padrão Adapter UML

31 Onde esta aquitetura poderia usar um Adapter? Layer 3 Componente 3.1 Componente 3.2 Componente 3.3 Layer 2 Componente 2.1 Componente 2.2 usa Componente 2.3 Layer 1 Componente 1.1 Componente 1.2 Componente 1.3

32 ? + Quero poder fazer Circulos!

33 Digamos Que seja dificil!

34 Descobri um já feito! Como reusar?? +

35 Descobri um já feito! Como reusar?? +

36

37 Adapter: Problema Fazer em aula. Uma implementação que ilustra o tratamento que pode ser dado à questão do problema do ano 2000 [Heywo96]. Tem-se um classe Customer ( que trata o ano com 4 dígitos ) e uma classe Old Customer ( que trata o ano com 2 dígitos ). A nova classe, Customer, tem o atributo FDOB que trata o ano com 4 dígitos, as operações protegidas são visíveis somente às classes descendentes e as operações property permitem métodos de leitura e escrita, podendo sobrecarregar o operação sem que a classe pai saiba sobre sua nova implementação. Fazer o modelo em UML e implementar o problema proposto usando um padrão Adapter. [Heywo96] HEYWORTH, James. Introduction to design patterns in Delphi. Camberra PC Users Group Delphi, 1996.

38 Padrão Bridge (GOF pg 151) Intensão: Desacoplar uma abstração da sua implementação, de modo que as duas possam variar independentement.

39 Padrão Bridge Motivação: Quando uma abstração pode ter uma entre várias implementações possíveis, a maneira usual de acomodá-las é usando herança. Nem sempre esta abordagem é funcional e flexivel! A herança liga uma implementação a sua abstração permanentemente!

40 Padrão Bridge Quando usar? Desejar evitar um vínculo entre uma abstração e sua implementação. Isto pode ocorrer quando a implementação deve ser alterada em tempo de execução. Quando, tanto as abstrações como suas implementações, tiverem de ser extensíveis por meio de subclasses. Neste caso o Bridge permite combinar as diferentes abstrações e implementações e estendê-las independentemente. Quando desejar compartilhar uma implementação entre múltiplos objetos e este fato deva estar oculto do cliente.

41 Padrão Bridge Consequências do uso. Desacopla a interface da implementação. Extensibilidade melhorada. Ocultação de detalhes de implementação dos clientes.

42 Padrão Bridge UML

43 O que faz este Design? Implementação Abstração

44 O que faz este Design? Objeto Figura Objeto Desenho Objeto PD1 ou PD2 Trata-se realmente de um Retângulo ou Círculo, mas o cliente não sabe dizer qual é, pois ambos parecem ser o mesmo! Trata-se realmente de um DesenhoV1 ou DesenhoV2, mas a Figura não sabe dizer qual é, pois ambos parecem ser o mesmo! Esse deve ser o tipo correto de objeto Desenho, quem o utilizar saberá reconhecê-lo!

45 O que faz este código? /** "Implementor" */ interface DrawingAPI { public void drawcircle(double x, double y, double radius); } /** "ConcreteImplementor" 1/2 */ class DrawingAPI1 implements DrawingAPI { public void drawcircle(double x, double y, double radius) { System.out.printf("API1.circle at %f:%f radius %f\n", x, y, radius); } } /** "ConcreteImplementor" 2/2 */ class DrawingAPI2 implements DrawingAPI { public void drawcircle(double x, double y, double radius) { System.out.printf("API2.circle at %f:%f radius %f\n", x, y, radius); } } /** "Abstraction" */ interface Shape { public void draw(); // low-level public void resizebypercentage(double pct); // high-level } /** "Refined Abstraction" */ class CircleShape implements Shape { private double x, y, radius; private DrawingAPI drawingapi; public CircleShape(double x, double y, double radius, DrawingAPI drawingapi) { this.x = x; this.y = y; this.radius = radius; this.drawingapi = drawingapi; } /** "Client" */ class BridgePattern { public static void main(string[] args) { Shape[] shapes = new Shape[2]; shapes[0] = new CircleShape(1, 2, 3, new DrawingAPI1()); shapes[1] = new CircleShape(5, 7, 11, new DrawingAPI2()); for (Shape shape : shapes) { shape.resizebypercentage(2.5); shape.draw(); } } } // low-level i.e. Implementation specific public void draw() { drawingapi.drawcircle(x, y, radius); } // high-level i.e. Abstraction specific public void resizebypercentage(double pct) { radius *= pct; } }

46 Padrão MVC O Padrão arquitetural Model-View-Controller divide uma aplicação interativa em 3 componentes. O modelo (Model) contém as funcionalidades e dados. Visão (View) apresenta informações ao usuário. Controle (Controller) manipula os inputs. Views e Controllers, juntos, compreendem a interface do usuário! O primeiro trabalho sobre MVC data de O MVC foi descrito por by Trygve Reenskaug quando trabalhava com Smalltalk na XEROX. O primeiro artigo sobre o tema foi: Applications Programming in Smalltalk-80: How to use Model View Controller

47

48 MVC

49 MVC

50 CRC MVC Classe Modelo Responsabilidades Prove as principais funcionalidades da aplicação Registra Visões dependentes e Controle. Notifica a componentes dependentes sobre alterações em seu estado. Colaboradores Visão Controle Classe Visão Responsabilidades Cria e inicializa seus controles associados. Apresenta informações ao usuário. Implementa rotinas de atualização. Busca dados do Modelo. Colaboradores Controle Modelo Classe Controle Responsabilidades Aceita evento de entrada do usuário Traduz eventos para serviços do modelo ou visão. Implementa a rotina de atualização se requisitado. Colaboradores Visão Modelo

51 Multi-tier architecture ou three-tier architecture Multi-tier architecture (também conhecida como n-tier architecture ou three-tier architecture ) é uma arquitetura cliente-servidor na qual a apresentação, processamento e a persistência estão logicamente separadas. Three-tier model é uma Arquitetura de Software e um Padrão de projeto! Por exemplo: uma aplicação que usa middleware para requisição de serviços entre usuários e o SBBD utiliza uma arquitetura n-tier.

52

53 Pergunta Qual a diferença entre: Model-View-Controller (MVC) e Three-tier architecture?

54 MVC Three-tier architecture??? MVC Three-tier architecture