Padrões de Design. Jair C Leite

Transcrição

1 Padrões de Design Jair C Leite Padrões Padrões são soluções para problemas específicos que ocorrem de forma recorrente em um determinado contexto que foram identificados a partir da experiência coletiva de desenvolvedores de software. A proposta original de padrões veio do trabalho de Christopher Alexander na área de arquitetura. Sua definição para padrões: Cada padrão é uma regra (esquema) de três partes que expressa uma relação entre um certo contexto, um problema, e uma solução.

2 Contexto, Problema, Solução e Forças O contexto descreve uma situação no desenvolvimento na qual existe um problema. O problema que ocorre repetidamente no contexto deve também ser descrito bem como as forças (requisitos, restrições e propriedades) associadas a ele. A solução descreve uma configuração ou estrutura de componentes e suas interconexões, obedecendo às forças do problema. As forças, denominação dada por Alexander, descrevem: os requisitos que caracterizam o problema e que a solução deve satisfazer, as restrições que devem ser aplicadas às soluções as propriedades desejáveis que a solução deve ter. Vantagens Descreve abstrações de software Vocabulário comum Comunicação efetiva de princípios complexos Ajuda a documentar a arquitetura do software Captura as partes essenciais do design de forma compacta Atenção: Padrões não apresentam uma solução exata Não resolvem todos os problemas de design Não é exclusivo de design orientado-a-objetos

3 Principais referências Design Patterns Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (The Gang of Four - GOF). Pattern-Oriented Software Architecture (POSA) A System of Patterns F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal John Wiley and Sons Ltd, Chichester, UK, 1996 Catálogos e Sistemas de Padrões Catálogo de padrões GOF uma coleção de padrões relacionados, nos quais os padrões são subdivididos num pequeno número de categorias abrangentes [Gamma, Helm, Jonhson, Vlissides,, 1995] Sistema de Padrões POSA um conjunto coesivo de padrões relacionados que trabalham em conjunto para auxiliar na construção e evolução das arquiteturas [Buchmann,, 1995]

4 Categorias de padrões - GoF Purpose Creational Structural Behavioral Class Factory Method Adapter Interperter Scope Object Abstract Factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Momento Observer State Strategy Vistor Categorias de padrões de design (POSA) Padrões arquiteturais - expressam o esquema de organização estrutural fundamental para um sistema de software. Assemelham-se aos Estilos Arquiteturais descritos por [Shaw & Garlan 96]. Exemplos: Camadas, Tubos-e-Filtros, Blackboard, Broker, Model- View-Controller,... Padrões de design (OO) - provê um esquema para refinamento dos subsistemas ou módulos em classes e objetos. Conhecidos como padrões GoF (Gang-of-Four). Exemplos: Mestre-escravo, Proxy, Observer, Command,... Idiomas - são padrões de baixo nível, específicos para a implementação em uma determinada linguagem de programação. Exemplos: Singleton, Counted Pointer

5 Exemplos de padrões - POSA Padrões Arquiteturais Layers (camadas) Pipes and Filters Blackboard Broker Model-View-Controller Presentation-Abstraction- Control Microkernel Reflection Padrões de design (OO) Whole-part Master-slave Proxy Command-processor View-Handler Forwarder-receiver Client-Dispatcher-Server Publisher-Subscriber Idiomas Counted Pointer (C++) Outros tipos de padrões de software Padrões de Processo (Processo de Software) [Coplien] Padrões de Interação Padrões Organizacionais (estrutura das organizações/projetos) Padrões de Análise [Flower] Padrões específicos do domínio

6 Descrição de padrões (forma canônica - Alexander) Nome nome significativo Problema o enunciado do problema Contexto a situação que causa o problema Forças a uma descrição das forças e restrições relevantes Solução solução conhecida para o problema Exemplos Amostras de aplicações de padrões Contexto resultante o estado do sistema após o padrão ter sido aplicado Rationale explicação das regras no padrão Padrões relacionados relacionamentos estáticos e dinâmicos Usos conhecidos ocorrência do padrão e de suas aplicações em Arquitetura sistemas de Software conhecidos Jair C Leite Padrão OO: Observer (Observador) Contexto: Situações nas quais vários componentes dependem de dados que são modificados em outro componente (sujeito). Problema: Os dados do componente sujeito modificam-se constantemente e precisam ser atualizados nos outros componentes. O número de componentes pode variar. Solução: Utilizar um mecanismo de registro que permite ao componente sujeito notificar aos interessados sobre mudanças. A B C A = 50% B = 30% C = 20%

7 Padrão Observer Estrutura Subject attach(observer) detach(observer) Notify( ) Atualizar todos observadores Observer Update( ) ConcreteSubject getstate( ) setstate( ) Retornar estado do sujeito ConcreteObserver Update( ) :concretesubject setstate( ) Notify( ) Update( ) attach(a ) a:concreteobserver getstate( ) b:concreteobserver attach(b) Update( ) getstate( ) Padrão Model-View-Controler - MVC Contexto: Aplicações interativas com interfaces de usuário gráficas flexíveis e controladas pelo usuários. Problema: Interfaces gráficas precisam representar uma mesma interface em diferentes janelas. O usuário deve poder tomar a iniciativa de controle de entrada e mudanças dos dados. Todas as janelas devem ser atualizadas sempre que houver mudanças nos dados. Solução: Utilizar o padrão Observer e estendê-lo para permitir o controle das janelas baseado-em-eventos. O Padrão MVC estende o Observer incorporando um elemento controlador (Controller). O MVC foi introduzido originalmente no Smalltalk-80. A B C A = 50% B = 30% C = 20%

8 Padrão MVC estrutura Model update 1..* Observer Upadate( ) coredata observers Attach(Observer) Detach(Observer) Notify ( ) getdata Service( ) Attach getdata View mymodel mycontroller Initialize(Model) makecontroller( ) Activate( ) Display() Update() create Controller mymodel myview Initalize(Model,View) handleevent( ) Update( ) Attach callservice Padrão MVC dinâmica :main m:model Initialize(m) makecontroller( ) v:view Attach(v) v:controller Initialize(m,v) Attach(c) starteventprocessing handleevent( ) Service( ) Update( ) Display( ) getdata( ) Update( ) getdata( )

9 Padrão Proxy - motivação O Padrão Proxy permite que clientes de um serviço utilizem um representante do componente que oferece o serviço. Aumenta a eficiência, a segurança e facilita o acesso. O Proxy pode substituir o servidor quando ocorrem problemas com o servidor. O Proxy permite criar uma independência de endereçamento e implementação do servidor. O Padrão Proxy contexto, problema e solução Contexto: Um cliente precisa acessar um serviço de um outro componente em um sistema distribuído. O acesso direto é tecnicamente possível, mas pode não ser a melhor opção. Problemas: O acesso direto pode não ser eficiente em tempo de execução, ter alto custo e não ser seguro. O cliente não precisa ficar dependente de endereço de rede do componente. Solução: Utilize um representante do cliente que ofereça o serviço de forma idêntica e realize pré- e pós-processamento adicionais para garantir a Qualidade do Serviço.

10 Proxy estrutura Uma class abstrata define o servico A classe servidor (server) e o proxy são instâncias desta classe abstrata e implementam o serviço Client AbstractServer service Proxy service 1 1 Server service Proxy - comportamento O cliente requisita o serviço e é atendido pelo Proxy O Proxy faz um pre-processamento empacotar ou codificar dados, por exemplo Em seguida, se ele mesmo não puder atender o serviço, ele repassa a chamada para o servidor Quando recebe a resposta do servidor, o proxy, faz um pósprocessamento (desempacotar ou decodificar) e repassa a resposta para o cliente : Client service : Proxy pre-processing : Server service post-processing

11 O Padrão Broker (Corretor) - idéia O Padrão Broker é utilizado para estruturar sistemas distribuídos separando componentes que interagem através de chamadas remota de serviços. O broker é responsável por coordenar a comunicação, encaminhado as solicitações e transmitido os resultados ou exceções. Eu preciso alugar uma casa Eu vendo carros Eu preciso alugar carro e casa Eu alugo casas Corretor Eu alugo carros O Padrão Broker (Corretor) Contexto: O ambiente é distribuído e heterogêneo com componentes cooperativos independentes que interagem por invocação de serviços remotos Problema: Sistemas acoplados não oferecem flexibilidade, dificultam mudanças e manutenção. Solução: Introduzir um componente broker para permitir uma maior desacoplamento entre clientes e servidores, permitindo independência de plataforma (ambientes heterogêneos) e de endereçamento.

12 Broker forças e benefícios Forças Componentes podem ser distribuidos pela rede Componentes precisam ser trocados, adicionados ou removidos em tempo de execução Componentes precisam se comunicar com mecanismos independentes Componentes precisam localizar serviços providos por servidores remotos Invocação independente de localização Benefícios Modificabilidade e extensibilidade de componentes Interoperabilidade entre diferentes sistemas Transparência de localização Portabilidade do broker Reusabilidade Padrão Broker estrutura

13 O Padrão Broker dinâmica : Client : Client Proxy : Broker : Server Proxy : Server method (proxy) find_server register_service assigned port start_up server port pack send_request unpack call_service foward_request forward_response unpack pack send_response return Padrão Layers (Camadas) Contexto: Um sistema complexo que requer decomposição. Problema: Decompor um sistema e aumentado a abstração diminuindo as dependências entre as partes. Cliente <<usa>> Camada n Camada n-1 Solução: Decompor em camadas de abstração de forma que uma camada não depende da superior e utiliza serviços apenas da camada imediatamente inferior. Camada 1

14 Padrão Layers (Camadas) representação em UML <<camada>> <<camada>> Camada n <<camada>> Camada n-1 <<camada>> <<camada>> Padrão Layer Sistema em Rede Aplicação Aplicação Apresentação ftp Sessão browser ssh Transporte Apresentação Rede Enlace Físico

15 Padrão Mestre-Escravo Contexto: Dividir e Conquistar é um princípio comum para solucionar vários problemas computacionais. Em vários sistemas é necessário aplicar este princípio. Problema: Dividir as tarefas em sub-tarefas idênticas.uma tarefas é dividida em sub-tarefas idênticas que podem ser processadas independentemente. O resultado final será obtido pela junção dos resultados de cada sub-tarefa. Solucão: Introduzir um elemento controlado entre o cliente do serviços e os vários elementos processadores para delegar as sub-tarefas e agrupar os resultados no resultado final. Cliente Mestre meusescravos 2..* Escravo divide() Combina() Sub-tarefa() Controlador 1 * Co-processador Padrão Mestre-Escravo Dinâmica Cliente :Mestre :Escravo :Escravo :Escravo divide() Servico() Sub-tarefa() Sub-tarefa() Podem ser concorrentes Sub-tarefa() combinar