PADRÃO CHAIN OF RESPONSIBILITY

Slides:



Advertisements
Apresentações semelhantes
Soluções elegantes para problemas recorrentes
Advertisements

Análise e Projeto Orientado a Objetos
Requisitos de Software
PADRÕES DE PROJETO..
Curso: Banco de Dados I Análise de Sistemas PUC Campinas
SISTEMAS OPERACIONAIS ERP E SCM
Administração e Projeto de Redes
UML Material retirado da apostila do Professor Cesar Augusto Tacla
Chain of Responsibility
Elizabeth Suescún Monsalve
Projeto de Sistemas de Software
Chain of Responsibility
Padrões de Projeto Prototype.
Projeto de Sistemas de Software Leandra Mara da Silva
Atribuição de Responsabilidades em Projeto OO
Professora: Aline Vasconcelos IF Fluminense
Padrões GoF – Factory Method
Chain of Responsibility
1 Comunicação Inter-Processos -> RMI -> RPC -> TCP -> UDP (Abstração de passagem de mensagem)
APRESENTAÇÃO DE ESTÁGIO
Filipe Ferraz Salgado Orientador: Francisco Reverbel Tipo de Trabalho: Estágio Supervisionado Após a criação do pacote com a versão 3.1 do jBPM, surgiu.
ESTRUTURA DE COMUNICAÇÃO DE DADOS
Padrões para Atribuições de Responsabilidades
Aspectos Avançados em Engenharia de Software Aula 3 Fernanda Campos
Observer Mantendo seus objetos atualizados
Trabalho de Conclusão de Curso
Classes e objetos Modelagem
Análise e Projetos de Sistemas UML-Linguagem de Modelagem Unificada Modelo de Dados com UML Diagrama de Classes Professor: Armando Hage.
Padrão de Projeto Chain of Responsability e Template Method
Universidade do Vale do Rio dos Sinos - São Leopoldo -
Software de Rede Willamys Araújo.
Modelo de referência OSI
Interconexão e Transporte em Redes
Chain of Responsibility
URI - Santo Ângelo - DECC
Processos de Software Profa. Cintia Carvalho Oliveira
hubs passivos e splitters
Concorrência e Java RMI
Padrões de Projeto e Arquitetura em Camadas
UNIDADE 2 UML MODELAGEM TEMPORAL
UTILIZANDO A ABORDAGEM DIRIGIDA A RESPONSABILIDADES PARA A CRIAÇÃO DO SUBFRAMEWORK DE ANÁLISE SINTÁTICA E SEMÂNTICA DE FÓRMULAS Rodolfo Adamshuk Silva.
Prof. Alexandre Monteiro Recife
Tópicos Especiais J2EE Prof. Cristina Valadares Curso de Ciência da Computação.
Curso de Aprendizado Industrial Desenvolvedor WEB Disciplina: Programação Orientada a Objetos I Professora: Cheli Mendes Costa Membro Static.
SNAPSHOT PADRÃO DE PROJETO.
Curso de Aprendizado Industrial Desenvolvedor WEB Disciplina: Programação Orientada a Objetos I Professora: Cheli Mendes Costa Classes e Objetos em Java.
PADRÃO COMMAND João Paulo Paschoal Arnaldo Correia Eric Carvalho.
SISTEMAS DISTRIBUIDOS Aula 4
Java RMI João Gabriel (jggxm).
Representação Arquitetural
1 Padrões de Software Padrões GoF (Parte 2) Eduardo Bezerra Outubro/2005.
Decorator POO - Avançado.
Integração de Ferramentas CASE
Engenharia de Software
Fluxo de Análise e Projeto 7 - Atividade Projetar Classes.
Design Patterns A adoção dos padrões terá um efeito profundo e duradouro sobre a forma de escrevermos programas Ward Cunningham e Ralph Johnson.
1 Padrões: Composite (p. 163) Objetivo: compor objetos em estruturas de árvores para representar relações de parte/todo. “Composite” permite tratar objetos.
Padrão Composite Definição
Jobson Ronan Padrões GoF Jobson Ronan
Infraestrutura de Redes
UCSal – Bacharelado em Informática Tópicos Especiais em Informática II Profa. Semíramis Assis
Interações entre objetos
É capaz de produzir resultados expressivos em um prazo relativamente curto; Eliminação do desperdício de tempo, talento, energia e materiais; Melhora.
Aula 6 – Padrão Factory Method
Aula: Arquiteturas de redes: modelo de referência OSI 04/12/2010.
Padrões de Projeto Aula 10 – Padrão Façade.
©2003, Alexandre Vasconcelos & Augusto Sampaio CIn-UFPE1 Análise e Projeto de Sistemas Modelagem de Requisitos com Casos de Uso.
SOCKET - É um canal de comunicação entre processos que estabelece uma conexão entre eles na forma de cliente-servidor. Por meio de sockets, os computadores.
Linguagem de Programação – Aula 04 Prof. Me. Ronnison Reges Vidal.
Lucas R. Costa Rodrigo R. Bezerra Kaio A. da silva
Transcrição da apresentação:

PADRÃO CHAIN OF RESPONSIBILITY Classificação: Comportamental Evita acoplar o remetente de uma requisição ao seu destinatário ao dar a mais de um objeto a chance de servir a requisição. Compõe os objetos em cascata e passa a requisição pela corrente até que um objeto a sirva Professor: Ângelo de Moura Guimarães Tutor: Guilherme Manso Aluno: Anderson Giovani

PROPÓSITO Não conhecer de antemão qual objeto irá responder a uma determinada requisição. Compor os objetos em cascata e passar a requisição pela corrente até que um objeto a sirva [Silva, 2005]. Evitar a união entre o remetente de uma solicitação e seu receptor, dando aos diversos objetos uma chance de tratar da solicitação [Allen & Bambara, 2003].

MOTIVAÇÃO Em projetos orientados a objetos manter os objetos com acoplamento fraco, mantendo específica e mínima a responsabilidade entre eles, faz com que mudanças sejam inseridas com menos risco de falhas. Os clientes apenas enxergam a interface visível do objeto permanecerem isolados de detalhes de implementação [Metsker, 2004].

MOTIVAÇÃO Uma máquina de refrigerantes necessita armazenar em locais diferentes cada tipo de moeda possível. Pode ser útil que um objeto receba a moeda, mas se ele não for capaz de armazenar no local correto, passe-o para outro objeto buscando a colocação correta da moeda [Silva, 2005]. Isso é um exemplo de tentativa de desacoplamento, já que se alguém não pode resolver determinada tarefa ocorre uma delegação da responsabilidade para outro objeto de forma totalmente transparente.

APLICABILIDADE Mais de um objeto pode tratar de uma solicitação e este é desconhecido. Uma solicitação deve ser emitida para um entre os vários objetos e o receptor, não sendo especificado explicitamente. O conjunto de objetos capaz de tratar da solicitação deve ser especificado dinamicamente.

ESTRUTURA No Chain of Responsability, ilustrado na Figura 1, um modelo de objetos assume a tarefa de descobrir qual objeto pode satisfazer sua solicitação.

PARTICIPANTES Alimentador : define a interface para tratar as solicitações e implementa a referência ao sucessor (opcional). AlimentadorConcretoA, ..., AlimentadorConcretoN : trata as solicitações pelas quais é responsável. Pode acessar seu sucessor. Se o AlimentadorConcreto pode tratar a solicitação, ele assim o faz; caso contrário ele repassa a solicitação para o seu sucessor. Cliente : Inicia a solicitação para um objeto AlimentadorConcreto da cadeia. Requisição : As instâncias de Requisição é que iram transportar as informações para os alimentadores executarem algo.

VANTAGENS Evita acoplamento do transmissor de um requisição com seus receptores, fazendo com que mais de um projeto tenha a chance de manipular a requisição. Encadeia os objetos receptores e passa a requisição ao longo dessa cadeia até que um objeto possa manipulá-lo. Reduz a vinculação. Adiciona flexibilidade. Permite que um conjunto de classes atue como uma classe; eventos produzidos em uma classe podem ser enviados para outras classes dentro da composição.

IMPLEMENTAÇÃO No exemplo ilustrado na Figura 2, a implementação é relacionada a uma máquina de refrigerantes, na qual vai-se adicionando moedas até o valor do refrigerante ser alcançado para a sua aquisição. As classes contidas dentro do pacote “moedas” são os AlimentadoresConcretos, enquando Moeda é a requisição enviada.

IMPLEMENTAÇÃO Como existem infinitos tipos de moedas, pois é possível encontrar moedas tanto as que estão em circulação em nosso país, como as que estão em circulação nas mais de outras duzentas nações, além das moedas que já são antigas e não possui mais validade monetária, a máquina de refrigerantes tem que descobrir qual moeda entrou através de possíveis padrões, como por exemplo, a espessura, raio e peso. Neste exemplo, a cada moeda que entra - a cada requisição - uma classe alimentadora analisa a moeda e busca ver se está dentro dos seus padrões, caso não esteja, vai passar para alguma outra classe alimentadora até que seja descoberta qual moeda entrou. Caso não se encaixe em nenhuma das especificações, a moeda será descartada e não será computado valor algum.

IMPLEMENTAÇÃO Chain of Responsibility pode ser implementada com estratégias que permitem maior ou menor acoplamento entre os participantes •Usando um mediador: só o mediador sabe quem é o próximo participante da cadeia •Usando delegação: cada participante conhece o seu sucessor

CONCLUSÃO Este padrão de primeira vista parece simples, o que na realidade não deixa de ser, no entanto, inicialmente ele causa indagações com relação a sua real utilidade, não chega-se a perceber no primeiro olhar que ele é um padrão importante e útil. É difícil imaginar cenários aplicáveis a ele, o que dificulta sua implementação.

REFERÊNCIAS http://www.argonavis.com.br/cursos/java/j930/index.html Acesso em 3 /10/2009 http://www.pg.cefetpr.br/coinf/simone/patterns/chain.php Acesso em 3/10/2009