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. Identificando padrões A organização de vários sistemas computacionais seguem alguns exemplos de sucesso. A Interfaces de Usuário Gráficas (GUI) e os Sistemas Distribuídos em Redes seguem uma organização em camadas. Browser HTTP Solicitação HTTP Resposta do servidor Servidor HTTP HTTP TCP TCP/IP Ethernet Ligação física TCP/IP TCP Sistemas de Interfaces Gráficas Aqua - Macintosh Cliente Servidor Sistemas Web
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 e 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
Tipos de padrões de software Padrões de projeto design patterns (software design) [Buschmann-POSA] arquitetural (estilos arquiteturais) design (micro-arquiteturas) idiomas (baixo nível programação) 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 Categorias de padrões de projeto 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 - provê um esquema para refinamento dos subsistemas ou módulos de um sistema de software. 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
Forma de Alexander (forma canônica) 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 Engenharia em sistemas de Software, conhecidos Jair C Leite, 2004 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 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
Catálogo 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 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
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
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
Padrão 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% Padrão Observer Estrutura Subject attach(observer) detach(observer) Notify( ) Atualizar todos observadores Observer ConcreteSubject getstate( ) setstate( ) Retornar estado do sujeito ConcreteObserver :concretesubject Notify( ) setstate( ) a:concreteobserver getstate( ) b:concreteobserver setstate( ) 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% Padrão MVC estrutura update 1..* Observer Model 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( ) 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( ) getdata( ) Display( ) getdata( ) Padrão Proxy - idéia 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: 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. : Client service : Proxy : Service pre-processing Client AbstractService service service post-processing Proxy service 1 1 Service service 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) estrutura Contexto: O ambiente é distribuído e heterogêneo com componentes cooperativos independentes. 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. Client Proxy marshal unmarhal receive_result service_p * 1 calls Client call_service_p start_task * 1 message exchange 1 Broker main_loop srv_registration srv_lookup transmit_message calls 1 * message exchange Server Proxy marshal unmarshal dispatch receive_request calls Bridge 1 marshal Server unmarshal start_up forward_message main_loop transmit_message service_i * O Padrão Broker dinâmica : Client : Client Proxy : Broker : Server Proxy : Server method (proxy) locate_server register_servic e assigned port start_up server port marshal receive_reques t unmarshal receive_resul t unmarshal dispatch method (impl.) result marshal result