1 / 101

PADRÕES POSA - PADRÕES DE PROJETO

PADRÕES POSA - PADRÕES DE PROJETO. Padrões de Projeto Classificação Decomposição Estrutural: decomposição de sistemas e complexos componentes em partes que se cooperam: Whole-Part Organização do Trabalho: como os componentes colaboram juntos para resolver um problema complexo: Master-Slave.

chaney
Télécharger la présentation

PADRÕES POSA - PADRÕES DE PROJETO

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PADRÕES POSA - PADRÕES DE PROJETO Padrões de Projeto Classificação Decomposição Estrutural: decomposição de sistemas e complexos componentes em partes que se cooperam: Whole-Part Organização do Trabalho: como os componentes colaboram juntos para resolver um problema complexo: Master-Slave

  2. PADRÕES POSA - PADRÕES DE PROJETO Padrões de Projeto Classificação Controle de Acesso: guardam e controlam o acesso a serviços ou componentes: Proxy Gerenciamento: manuseiam coleções homogêneas de objetos, serviços e componentes em sua totalidade: Command Processor View Handler

  3. PADRÕES POSA - PADRÕES DE PROJETO Padrões de Projeto Classificação Comunicação: ajudam a organizar a comunicação entre os componentes: Forwarder-Receiver Client-Dispatcher-Server Publisher - Subscriber

  4. PADRÕES POSA - PADRÕES DE PROJETO Whole-Part

  5. PADRÕES POSA - PADRÕES DE PROJETO Whole-Part Contexto Implementar objetos agregados

  6. PADRÕES POSA - PADRÕES DE PROJETO Whole-Part Ajuda na agregação de componentes. O, Todo (Whole), encapsula seus componentes constituintes, as Partes, (Part). Organiza as colaborações e provê uma interface comum para suas funcionalidades. O acesso direto às partes não é permitido.

  7. PADRÕES POSA - PADRÕES DE PROJETO Whole-Part Clientes enxergam o objeto agregado (whole) como um objeto atômico que não permite acesso direto às partes

  8. PADRÕES POSA - PADRÕES DE PROJETO Whole-Part

  9. PADRÕES POSA - PADRÕES DE PROJETO Whole-Part

  10. PADRÕES POSA - PADRÕES DE PROJETO Whole-Part Conseqüências Flexibilidade com as Partes: O Todo encapsula as partes e assim, separa do cliente. Assim, torna as Partes independentes. Reusabilidade das partes e do todo com as partes.

  11. PADRÕES POSA - PADRÕES DE PROJETO Mestre-Escravo (Master-Slave) O padrão de projeto Master-Slave suporta tolerância à falha, computação paralela e precisão computacional. Um componente mestre distribui o trabalho entre componentes escravos idênticos e computa o resultado final dos resultados que esses escravos retornam.

  12. PADRÕES POSA - PADRÕES DE PROJETO Mestre-Escravo (Master-Slave) Contexto: Para abordar a complexidade de uma tarefa, o projetista precisa dividir uma tarefa em sub-tarefas menores a serem executadas por diferentes agentes ou processos.

  13. PADRÕES POSA - PADRÕES DE PROJETO Mestre-Escravo (Master-Slave) Problema: Como coordenar a realização de uma tarefa complexa? Dividir e Conquistar é um princípio para resolução de problemas; O Trabalho é dividido em várias sub-tarefas menores que são processadas independentemente; Um agente pode dividir uma tarefa e delegar sub-tarefas a outros agentes para melhorar a confiança, desempenho, ou precisão da tarefa que é executada.

  14. PADRÕES POSA - PADRÕES DE PROJETO Mestre-Escravo (Master-Slave) Solução Um componente master (mestre) distribui trabalho a componentes slaves (escravos) que realizam a computação; O componente master divide o trabalho em sub-tarefas iguais e delega as sub-tarefas aos componentes escravos que são semanticamente (sentido) idênticos. Depois os resultados parciais são enviados dos escravos para o mestre, que tem a responsabilidade de computar o resultado final.

  15. PADRÕES POSA - PADRÕES DE PROJETO Mestre-Escravo (Master-Slave) Solução O mestre indica um escravo para cada sub-tarefa, neste caso ele utiliza recruit-all(X) para delegar tarefas para os agentes escravos. Enquanto o escravo computa o resultado parcial da tarefa que foi nomeada pelo mestre, o mestre pode continuar seu trabalho normalmente. Quando um escravo tiver terminado seu trabalho envia uma resposta, usando reply(X), para o mestre que compila o resultado final e retorna para o cliente.

  16. PADRÕES POSA - PADRÕES DE PROJETO Mestre-Escravo (Master-Slave)

  17. PADRÕES POSA - PADRÕES DE PROJETO Mestre-Escravo (Master-Slave)

  18. PADRÕES POSA - PADRÕES DE PROJETO Mestre-Escravo (Master-Slave)

  19. PADRÕES POSA - PADRÕES DE PROJETO Mestre-Escravo (Master-Slave) Variantes

  20. PADRÕES POSA - PADRÕES DE PROJETO Mestre-Escravo (Master-Slave)

  21. PADRÕES POSA - PADRÕES DE PROJETO Mestre-Escravo (Master-Slave) Conseqüências Extensibilidade: ao permitir trocar as implementações do escravos ou ainda acrescentar/retirar novos. Os cliente não são afetados com as mudanças. Separação de camadas: a introdução do mestre, separa o escravo do cliente. Eficiência: processamento paralelo;

  22. PADRÕES POSA - PADRÕES DE PROJETO Proxy Em algumas situações um servidor ou mesmo um sistema inteiro não deve estar acessível diretamente pelos clientes. Exemplo: nem todos os clientes estão autorizados a usar os serviços de um componente ou recuperar uma informação particular que o componente oferece; Proxy é um padrão de design que faz com que clientes de um componente comunique-se com um representante ao invés de comunicar-se com o próprio componente.

  23. PADRÕES POSA - PADRÕES DE PROJETO Proxy Contexto Um cliente necessita acessar um serviço de um outro componente (objetos locais, banco de dados externos, paginas HTML, ou uma imagem em um documento, entre outros) O acesso direto pode ser tecnicamente possível, mas não é a melhor abordagem.

  24. PADRÕES POSA - PADRÕES DE PROJETO Proxy Problema É inapropriado o acesso direto ao componente; O acesso ao componente tem que ser transparente; O acesso ao componente tem que ser eficiente.

  25. PADRÕES POSA - PADRÕES DE PROJETO Proxy Solução Introduz um representante (proxy). O cliente se comunica com o Proxy ao invés de se comunicar com o próprio componente. O proxy oferece uma interface para acesso ao componente e realiza processamento adicional (p.ex.: verificação de controle de acesso) Serve para muitos propósitos incluindo facilidade de acesso e proteção contra usuários não autorizados.

  26. PADRÕES POSA - PADRÕES DE PROJETO Proxy Estrutura

  27. PADRÕES POSA - PADRÕES DE PROJETO Proxy Interface Comum do Proxy e Original Componente

  28. PADRÕES POSA - PADRÕES DE PROJETO Proxy

  29. PADRÕES POSA – PADRÕES DE PROJETO Proxy Conseqüências Separar o cliente da localização dos seus componentes servidores. Eficiência e baixo-custo de localização.

  30. PADRÕES POSA – PADRÕES DE PROJETO Padrão Command Processor O padrão de projeto Command Processor separa a requisição de um serviço de sua execução. Um componente command processor gerencia requisições como objetos separados, agendando suas execuções e provendo serviços adicionais.

  31. PADRÕES POSA – PADRÕES DE PROJETO Padrão Command Processor Problema: Uma aplicação que possua um grande número de funcionalidades se beneficia de uma solução bem estruturada de mapeamento entre a sua interface e sua funcionalidade interna. Isso permite suportar diferentes modos de interação do usuário, como menus pop-up para usuários iniciantes e atalhos de teclado para usuários experientes, ou mesmo o controle externo da aplicação por linguagem de script.

  32. PADRÕES POSA – PADRÕES DE PROJETO Padrão Command Processor Problema: Geralmente é necessário implementar também serviços que vão além da funcionalidade central do sistema para execução de requisições do usuário. As seguintes forças modelam a solução: Usuários diferentes podem interagir com a aplicação de diferentes formas; Empreender aperfeiçoamentos na aplicação não pode quebrar o código existente; Serviços adicionais devem ser implementados de forma consistente para todos os tipos de requisição.

  33. PADRÕES POSA – PADRÕES DE PROJETO Padrão Command Processor Solução: O padrão Command Processor é baseado no padrão Command do GoF. Ambos os padrões seguem a idéia de encapsular requisições em objetos. Quando um usuário chama uma função específica na aplicação, a requisição é transformada num objeto command. O padrão especifica como os objetos command são gerenciados.

  34. PADRÕES POSA – PADRÕES DE PROJETO Padrão Command Processor Solução: O componente central do padrão, o command processor, cuida de todos os objetos command. Ele agenda a execução dos commands e pode armazená-los para futuro desfazimento da operação, podendo ainda prover serviços adicionais como logging. Cada objeto command delega a execução de sua tarefa a componentes denominados supplier contidos no núcleo funcional da aplicação.

  35. PADRÕES POSA – PADRÕES DE PROJETO Padrão Command Processor Estrutura:

  36. PADRÕES POSA – PADRÕES DE PROJETO Padrão Command Processor Estrutura:

  37. PADRÕES POSA – PADRÕES DE PROJETO Padrão Command Processor Estrutura: Abstract Command: define a interface de todos os objetos command. Controller:representa a interface da aplicação. Aceita as requisições e cria os correspondentes objetos comandos. Os objetos commands são entregues ao Command Processor (Receptor). Command Processor:gerencia os objetos command, agendando e iniciando suas execuções (Executor). Efetua logging. Supplier: provê a funcionalidade núcleo da aplicação. Executa o comando e quando um undo é requerido ele salva e restaura seu estado interno.

  38. PADRÕES POSA – PADRÕES DE PROJETO Padrão Command Processor Estrutura:

  39. PADRÕES POSA – PADRÕES DE PROJETO Padrão Command Processor Dinâmica:

  40. PADRÕES POSA – PADRÕES DE PROJETO Padrão Command Processor Dinâmica: O controller aceita requisições do usuário e cria um comando.Após aceitar uma requisição undo, o controller transfere essa requisição para o command processor. O command processor invoca o procedimento de undo para o último comando realizado. O comando ‘capitalizar’ restaura o supplier ao seu estado prévio, substituindo o texto salvo em sua posição original. Se nenhuma atividade adicional é necessária ou possível para o comando, o command processor deleta o objeto command.

  41. PADRÕES POSA – PADRÕES DE PROJETO Padrão Command Processor Conseqüências: Flexibilidade na forma como as requisições são ativadas; Flexibilidade no número e funcionalidades das requisições; Programação de serviços correlatos à execução da funcionalidade; Testabilidade no nível da funcionalidade da aplicação; Concorrência;

  42. VIEW HANDLER 42

  43. PADRÕES POSA – PADRÕES DE PROJETO Padrão View Handler O padrão de projeto View Handler auxilia a gerenciar todas as visões que um sistema de software disponibiliza. Um componente view handler permite aos clientes abrir, manipular e encerrar as visões. Ele também coordena dependências entre as visões e organiza suas atualizações. Exemplo: um aplicativo com interface Multiple Document Interface (MDI)

  44. PADRÕES POSA – PADRÕES DE PROJETO Padrão View Handler Problema: Sistemas que possuem múltiplas visões interativas simultâneas em geral requerem escrita de funcionalidade adicional para gerenciá-las. Os usuários necessitam abrir, manipular e encerrar as visões, como janelas e seus conteúdos. As visões devem ser coordenadas de modo que a atualização de uma visão seja propagada automaticamente para outras visões relacionadas.

  45. PADRÕES POSA – PADRÕES DE PROJETO Padrão View Handler Problema: As seguintes forças conduzem à solução do problema: Gerenciar as múltiplas visões deve ser fácil sob a perspectiva do usuário, e também para os componentes clientes dentro do sistema; Implementações das visões individuais não devem depender de nenhuma outra ou serem misturadas com código utilizado para gerenciar as visões; Implementações de visões podem variar, e tipos adicionais de visões podem ser adicionados durante o ciclo de vida do sistema.

  46. PADRÕES POSA – PADRÕES DE PROJETO Padrão View Handler Solução: Separar o gerenciamento das visões do código requerido para apresentar ou controlar visões específicas. O componente view handler gerencia todas as visões que o sistema provê. Ele oferece a funcionalidade necessária para abrir, coordenar e fechar visões específicas, e também manipular visões – por exemplo, um comando do tipo ‘tile’ apresentará todas as visões de uma determinada forma padronizada na tela. O padrão View Handler adapta a idéia de separação entre a apresentação e o núcleo funcional, como proposto pelo MVC; O componente view handler pode ser considerado como uma composição dos padrões GoF Abstract Factory e Mediator.

  47. PADRÕES POSA – PADRÕES DE PROJETO Padrão View Handler Estrutura:

  48. PADRÕES POSA – PADRÕES DE PROJETO Padrão View Handler Estrutura:

  49. PADRÕES POSA – PADRÕES DE PROJETO Padrão View Handler Estrutura: View Handler: componente central do padrão. Responsável pela abertura de novas visões e serviços de gerenciamento e coordenação de visões. Abstract view:interface que é comum a todas as visões. Specific view:componentes que são derivados de uma abstract view e implementam sua interface. Supplier: provê os dados que são apresentados pelos componentes das visões.

  50. PADRÕES POSA – PADRÕES DE PROJETO Padrão View Handler Estrutura:

More Related