PADRÕES POSA - PADRÕES DE PROJETO

PADRÕES POSA - 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

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

Classificação Comunicação: ajudam a organizar a comunicação entre os componentes: Forwarder-Receiver Client-Dispatcher-Server Publisher - Subscriber

Whole-Part

Whole-Part Contexto Implementar objetos agregados

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.

Whole-Part Clientes enxergam o objeto agregado (whole) como um objeto atômico que não permite acesso direto às partes

Whole-Part

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.

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.

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.

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.

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.

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.

Mestre-Escravo (Master-Slave)

Mestre-Escravo (Master-Slave) Variantes

Mestre-Escravo (Master-Slave)

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;

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.

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.

Proxy Problema É inapropriado o acesso direto ao componente; O acesso ao componente tem que ser transparente; O acesso ao componente tem que ser eficiente.

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.

Proxy Estrutura

Interface Comum do Proxy e Original Proxy Componente

Proxy

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.

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.

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.

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.

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.

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.

Padrão Command Processor Estrutura:

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.

Padrão Command Processor Estrutura:

Padrão Command Processor Dinâmica:

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.

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;

VIEW HANDLER 42 42

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)

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.

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.

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.

Padrão View Handler Estrutura:

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.

Padrão View Handler Estrutura:

Padrão View Handler Dinâmica:

Padrão View Handler Dinâmica: Um cliente aciona um view handler para abrir uma determinada visão; O view handler instancia e inicia a visão desejada. A visão registra-se no mecanismo de propagação de mudança de seu supplier.

Padrão View Handler Dinâmica: O view handler adiciona a nova visão à sua lista interna de visão abertas. O view handler aciona a visão para exibir a si própria. A visão abre uma nova janela, recupera os dados do supplier, prepara os dados para exibição e apresenta ao usuário.

Padrão View Handler Conseqüências: Tratamento uniforme das visões; Extensibilidade e mutabilidade das visões Coordenação das visões por especificidade de aplicação

FORWARD-RECEIVER 55 55

Padrão Forward-Receiver O padrão de projeto Forwarder-Receiver provê comunicação inter-processo transparente para sistemas de software com um modelo interativo peer-to-peer. Ele introduz forwarders e receivers para desacoplar os peers dos mecanismos internos de comunicação.

Padrão Forward-Receiver Contexto: Comunicação peer-to-peer

Padrão Forward-Receiver Problema: Uma forma de construção de aplicações distribuídas é através de mecanismos de baixo-nível, comunicação entre inter-processos, como protocolos, filas de mensagens. O problema é que muitas vezes eles dependem de Sistema Operacionais e protocolos de rede.

Padrão Forward-Receiver Solução: Comunicação peer-to-peer. Peers distribuídos colaboram para resolver um problema particular. Um peer pode atuar como um cliente, requisitando serviços, com um servidor, provendo serviços, ou ambos.

Padrão Forward-Receiver Solução: Os detalhes do mecanismo de comunicação inter-processos para o envio e recebimento de mensagens são escondidos dos peers através de encapsulamento.

Padrão Forward-Receiver

Padrão Forward- Receiver

Padrão Forward-Receiver Peer: Cada peer conhece o nome dos outros peers remotos com os quais ele precisa de comunicar. Usa o Forward para enviar mensagens para os outros peers e Receiver para receber mensagens. Forward: envia as mensagens para os peers. Ele contém um mapeamento de nomes para o endereço físico dos receptores. Quando um forward envia uma mensagem para um peer remoto, ele determina sua localização física através do mapeamento. Receiver: recebe as mensagens.

Padrão Forward-Receiver

Padrão Forward-Receiver Conseqüências Eficiência na comunicação inter-processos; Encapsula as facilidades da comunicação inter-processos.

CLIENT-DISPATCHER-SERVER
66 66

Padrão Client-Dispatcher-Server O padrão de projeto Client-Dispatcher-Server introduz uma camada intermediária entre clientes e servidores, o componente dispatcher. Esse componente oferece transparência de localização por meio de um serviço de nomes e esconde os detalhes do estabelecimento da conexão de comunicação entre clientes e servidores.

Padrão Client-Dispatcher-Server Problema: Quando um sistema utiliza servidores distribuídos ao longo de uma rede ele deve prover meios para comunicação entre eles. Em muitos casos uma conexão entre os componentes deve ser estabelecida antes da comunicação ocorrer, dependendo dos recursos de comunicação disponíveis. No entanto, a funcionalidade central dos componentes deve ser separada dos detalhes de mecanismos de comunicação. Clientes não devem conhecer onde os servidores estão localizados. Isso permite mudar a localização dos servidores dinamicamente e assegurar estabilidade do sistema contra falhas na rede ou nos servidores.

Padrão Client-Dispatcher-Server Problema: As seguintes forças devem ser ponderadas: Um componente deve ser capaz de usar um serviço independente da localização do provedor do serviço; O código da implementação no núcleo funcional do consumidor do serviço deve ser separado do código utilizado para estabelecer conexão com provedores de serviço.

Padrão Client-Dispatcher-Server Solução: Disponibilizar um componente dispatcher para agir como uma camada intermediária entre clientes e servidores. O dispatcher implementa um serviço de nomes que permite aos clientes fazer referência aos servidores utilizando nomes ao invés de localizações físicas.

Padrão Client-Dispatcher-Server Solução: Isso possibilita transparência de localização. Adicionalmente o dispatcher também é responsável por estabelecer o canal de comunicação entre um cliente e um servidor. Os papéis de cliente e de servidor podem mudar dinamicamente ao contrário da abordagem cliente-servidor tradicional.

Padrão Client-Dispatcher-Server Estrutura:

Padrão Client-Dispatcher-Server Estrutura: Client: responsável por realizar tarefas específicas associadas ao certo domínio de aplicação. Server: disponibiliza um conjunto de operações para os clientes. Ele registra-se ou é registrado no dispatcher pelo seu nome e endereço. Dispatcher:disponibiliza a funcionalidade de estabelecimento de canais de comunicação entre clientes e servidores.

Padrão Client-Dispatcher-Server Estrutura:

Padrão Client-Dispatcher-Server Dinâmica:

Padrão Client-Dispatcher-Server Dinâmica: O server registra a si próprio no componente dispatcher. Num momento posterior, um client solicita ao dispatcher um canal de comunicação para um servidor específico. O dispatcher procura o servidor que associado ao nome especificado pelo cliente no seu registro. O dispatcher estabelece um canal de comunicação com o server. Se for possível iniciar a conexão com sucesso, ele retorna o canal de comunicação para o client. Caso contrário, ele envia ao client uma mensagem de erro.

Padrão Client-Dispatcher-Server Conseqüências: Benefícios: Permutabilidade de servidores; Transparência de localização e migração; Re-configuração; Tolerância a falhas; Limitações: Perda de eficiência devido ao overhead gerado pelo dispatcher; Sensibilidade às mudanças nas interfaces do dispatcher;

PUBLISHER-SUBSCRIBER
79 79

Padrão Publisher-Subscriber Ajuda a manter o estado dos componentes sincronizados. Também conhecido como Observer.

Padrão Publisher-Subscriber Problema Em alguns sistemas, os dados mudam em um certo lugar e vários objetos em outras partes do sistema dependem daqueles dados; É necessário então, utilizar algum mecanismo para informar os dependentes das mudanças; Poder-se-ia introduzir chamadas explícitas do objeto cujo estado mudou para os seus dependentes, mas esta solução não é flexível nem reutilizável; Precisamos de um mecanismo de propagação de mudanças que possa ser aplicado em vários contextos;

Padrão Publisher-Subscriber A solução tem que equilibrar as seguintes forças: Um ou mais objetos tem que ser notificados sobre mudanças em um objeto; O número de dependentes não é conhecido a priori e pode até mudar dinamicamente; Fazer com que os dependentes peguem o estado de tempos em tempos (polling) é muito caro; O objeto que provê o dado e aqueles que o consomem não devem ser fortemente acoplados;

Padrão Publisher-Subscriber Solução O objeto que contém o dado que interessa é chamado de Publisher (subject no GoF) Os objetos dependentes são chamados de Subscribers (observers no GoF) O publisher mantém uma lista dos objetos registrados que são aqueles interessados em receber notificações sobre as mudanças.

Padrão Publisher-Subscriber Solução O publisher oferece uma interface para manifestação de interesse (subscribe interface) Quando o estado do publisher muda, ele envia uma notificação para todos os objetos que manifestaram interesse. Ao receber uma notificação, o subscriber decide se solicita a informação ao publisher ou não.

Subscriber Publisher

PADRÕES POSA – IDIOMAS IDIOMAS São padrões de baixo-nível específicos para uma linguagem de programação. Um idioma descreve como implementar aspectos de um componente ou o relacionamento entre as características de uma linguagem.

Problema: PADRÕES POSA – IDIOMAS Padrão Counted Pointer
Alocação dinâmica de objetos em C++ causa muitos problemas de memória; Objetos tem que ser destruídos explicitamente e muitas vezes não sabemos o lugar apropriado para destruí-lo.

PADRÕES POSA – IDIOMAS Padrão Counted Pointer

Problema: PADRÕES POSA – IDIOMAS Padrão Counted Pointer Forças:
Passar objetos sempre por valor não é apropriado; Vários clientes precisam compartilhar um mesmo objeto não podemos permitir referências para objetos que já foram destruídos (dangling references) Se um objeto não é mais utilizado, ele deve ser destruído para liberar os recursos a solução não deve exigir muito código adicional e deve ser leve computacionalmente;

Solução: PADRÕES POSA – IDIOMAS Padrão Counted Pointer
Introduza contagem de referências utilizando um "apontador contador" Adicione um contador de referências na classe original Crie uma classe Handle que servirá de "apontador inteligente" para o objeto original

PADRÕES POSA – IDIOMAS Padrão Counted Pointer

REFERÊNCIAS

REFERÊNCIAS Alexander, C., Ishikawa, S., Silverstein, M., Angel, S. and Abrams, D. (1975) “The Oregon Experiment”, Oxford University Press. Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I. and Angel, S. (1977) “A Pattern Language: Towns, Buildings, Construction”, Oxford University Press, New York, NY. Alexander, C. (1979) “The Timeless Way of Building”, Oxford University Press, New York. Almeida, S., Alvaro, A., Lucrédio, D., Garcia, C. and Piveta, K. (2004) “Student's PLoP Guide: A Pattern Family to Guide Computer Science Students during PLoP Conferences”, In the 4th Latin American Conference on Pattern Languages of Programming (SugarLoafPLoP), Writers' Workshop, Porto das Dunas-CE, Brazil. Alur, D., Crupi, J. and Malks, D. (2003) “Core J2EE Patterns: Best Practices and Design Strategies”, Prentice Hall. Ambler, S. (1998) “Process Patterns: Building Large-Scale Systems Using Object Technology”, Cambridge University Press. Andrade, R., Marinho, F., Santos, M. e Nogueira, R. (2003) “Uma Proposta de um Repositório de Padrões Integrado ao RUP”, Session Pattern Application (SPA), SugarLoafPLoP 2003, The Third Latin American Conference on Pattern Languages of Programming, Porto de Galinhas, PE. 93

REFERÊNCIAS (CONT.) Appleton, B. (1997) “Patterns and Software: Essential Concepts and Terminology”, Junho. Argonavis. Beck, K. and Cunningham, W. (1987) “Using Pattern Languages for Object-Oriented Programs”, Technical Report nº CR-87-43, Junho. Booch, G., Rumbaugh, J. and Jacobson, I. (2000) “UML, Guia do Usuário: tradução”, Campus, Rio de Janeiro; Brown, W., Malveau, R., McCormick, H. and Mowbray, T. (1995) “AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis”, Wiley. Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. and Stal, M. (1996) “Pattern- Oriented Software Architecture Volume 1: A System of Patterns”, Wiley. Coad, P. (1992) “Object-Oriented Patterns”, Communications of the ACM, V. 35, nº9, pages Coplien, J. (1991) “Advanced C++ Programming Styles and Idioms”, Reading-MA, Addison-Wesley. Coplien, J. (1994) “A Development Process Generative Pattern Language”, Pattern Languages of Programs, Monticello, EUA. Coplien, J. (1994) “Generative pattern languages: An emerging direction of software design”, C++ Report, pages 18-22, 94

REFERÊNCIAS (CONT.) Coplien, J. and Schmidt, D. (1995) “Pattern Language of Program Design”, Addison- Wesley. Coplien, J. (1996) “Software Patterns: A White Paper”, SIGS Publication. Coplien, J. and Harrison, N. (2004) “Organizational Patterns of Agile Software Development”, Prentice Hall. Fowler, M. (1997) “Analysis Patterns: Reusable Object Models”, Addison-Wesley. Freeman, E., Freeman, E., Sierra, K. and Bates, B. (2004) “Head First: Design Patterns”, O’Reilly. Gabriel, R. (2002) "Writers' Workshops & the Work of Making Things: Patterns, Poetry...", Pearson Education. Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1993) “Design Patterns - Abstraction and Reuse of Object-Oriented Design”, LNCS, nº 707, pages Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995) “Design Patterns - Elements of Reusable Object-Oriented Software”, Addison-Wesley. Harrison, B. (2000) “The Language of Shepherding: A Pattern Language for Shepherds and Sheep”, 7th. Pattern Languages of Programs Conference, August, Allerton Park, Monticello, Illinois. 95

REFERÊNCIAS (CONT.) Johnson, R. (1992) “Documenting Frameworks Using Patterns”, OOPSLA '92, pages Jorge H. C. Fernandes ( ) “Padrões de Design Orientados a Objetos” Meszaros, G. and Doble, J. (1996) “MetaPatterns: A Pattern Language for Pattern Writing”, Patterns Languages of Program Design, PLoP. Rising, L. (1998) “The Patterns Handbook: Techniques, Strategies, and Applications”, Sigs. Sane, A. (1995) “The elements of pattern style”, Proceedings of the Second Pattern Languages of Programs Conference, Addison-Wesley, Menlo Park, California. Shalloway, A. and Trott, J. (2001) “Design Pattern Explained – A New Perspective on Object Oriented Design”, Pearson. Schmidt, D., Stal, M., Rohnert, H. and Buschmann, F. (2000) “Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects”, Wiley. Tháis Batista, “Arquitetura de Software”, disponível em Vlissides, J. (1990) “Patterns: The Top Ten Misconceptions,” Object Magazine, Junho. Vlissides, J., Coplien, J. and Kerth, N. (1996) “Pattern Languages of Program Design 2”, Addison-Wesley. Vlissides, J. (1996) “Pattern Hatching: Seven Habits of Successful Pattern Writers”, C++ Report, November. 96

Oportunidades

Oportunidades Especialização em Engenharia de Software com Ênfase em Padrões de Software da UECE/FJN Vagas para alunos especiais (formandos) 98

Oportunidades Mestrado Acadêmico em Ciência da Computação da UECE (MACC) Turma 3 - início de 2009 Grupo de Padrões de Software da UECE (GPS.UECE) Vagas para voluntários Mestrado Integrado Profissional em Computação Aplicada UECE/CEFET-CE (MPCOMP) 99

Contatos 100

Contatos Tarciane de Castro Andrade 101

PADRÕES POSA - PADRÕES DE PROJETO

Apresentações semelhantes

Apresentação em tema: "PADRÕES POSA - PADRÕES DE PROJETO"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

PADRÕES POSA - PADRÕES DE PROJETO

Apresentações semelhantes

Apresentação em tema: "PADRÕES POSA - PADRÕES DE PROJETO"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback