Diagramas de Colaboração e Padrões GRASP

Transcrição

1 UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Projeto e Desenvolvimento de Sistemas de Informação Diagramas de Colaboração e Padrões GRASP

2 O que vimos até agora Diagramas de Caso de Uso Casos de uso resumido e completo Modelo Conceitual Diagramas de Sequência do Sistema Contratos de Operações Notação dos Diagramas de Comunicação

3 Atendente nome n registra 1..1 Leitor nome tipo : char ^ faz 0..n 0..n faz n Reserva período situacao : char 0..1 Empréstimo/Devolução data do empréstimo situação : Char 0..1 corresponde a corresponde a possui Bibliotecaria nome refere-se a > 1..1 Objetivo ao final da fase de projeto registra n 1..1 Livro titulo : String[30] autor : String[30] ano : int ISBN : string[20] editora : int tipo : char possui 0..n CopiaDoLivro nro sequencial situacao : char liberadoparaemprestimo : char 1..n 0..1 LinhaDoEmpréstimo data_prevista_dev olução data_entrega_real n < refere-se a

4 nome tipo Leitor calculardatadevolucao( ) 1 0..* faz Emprestimo data_do_emprestimo situacao : char adicionarcopia( ) devolvercopia( ) Mais a especificação das interfaces (métodos) LinhaDoEmprestimo data_prevista_devolução data_entrega_real possui 1..* refere-se a 1 CopiaDoLivro nro_sequencial situacao : char liberadoparaemprestimo : char codcopia( ) atualizardatadev( ) 0..* 1 mudarsituacao( ) codcopia( ) sinalizardevolucao( )

5 Como projetar as responsabilidades de cada objeto Sabemos que os objetos precisam se comunicar para completar as operações. Os Diagramas de comunicação mostram escolhas de atribuições de responsabilidades a objetos. Mas quem é o melhor candidato para realizar cada uma das operações ou métodos do sistema?

6 Como projetar as responsabilidades de cada objeto Responsabilidade: Um contrato ou obrigação de um tipo ou uma classe(booch e Rumbaugh) Responsabilidades estão relacionadas às obrigações de um objeto em termos de seu comportamento. Dois tipos de responsabilidades básicas: Fazer Fazer algo (criar um objeto, executar uma operação,...) Iniciar ações em outros objetos(delegação). Controlar e coordenar atividades em outros objetos. Conhecer Conhecer dados privados encapsulados. Conhecer objetos relacionados. Conhecer dados/atributos que podem ser derivados ou calculados.

7 Responsabilidades e Diagramas de Interação Diagramas de interação mostram escolhas de atribuição de responsabilidade a objetos. Exemplo: atribuir aos objetos do tipo Venda a responsabilidade de imprimirem a si próprios. imprimir() :Venda Responsabilidade de imprimir a si própria

8 Exemplo: Motivação para aplicação de Padrões Diagrama de Comunicação para a operação EmprestarFita(fcodigo) Implementação inchada ou concentradora X Implementação leve, distribuída

9 Sistema Videolocadora Cod Cópia fita Emprestar :Atendente Camada de Interface açãoexecutada(eventodaação) :CWindow emprestarfita(fcodigo) Camada do Domínio :????

10 Videolocadora Modelo Conceitual Sistema Videolocadora possui possui

11 Comunicação entre os objetos 2: emprestimocorrente := getemprestimocorrente emprestarfita(fcodigo)----> :Videolocadora clientecorrente: Cliente 3: criar() 1: fita:=get(fcodigo) 5: associaritem(item) 4: associarfita(fita) fitas: Fita emprestimocorrente: Emprestimo item: ItemDeEmprestimo Qual é o problema desta solução?

12 Pseudo-código Concentrador VideoLocadora Classe VideoLocadora fitas: Conjunto; clientecorrente: Cliente Método emprestarfita(fcodigo: String) fita:fita; emprestimocorrente: Emprestimo; item: ItemDeEmprestimo; fita := fitas.get(fcodigo); emprestimocorrente := clientecorrente.getemprestimocorrente(); item := itemdeemprestimo.new(); Item.associarFita(fita); EmprestimoCorrente.associarItem(item); Fim Método; FIM Classe;

13 Comunicação entre objetos (concentrador) 2: emprestimocorrente := getemprestimocorrente emprestarfita(fcodigo)----> :Videolocadora clientecorrente: Cliente 3: criar() 1: fita:=get(fcodigo) 5: associaritem(item) 4: associarfita(fita) fitas: Fita item: ItemDeEmprestimo emprestimocorrente: Emprestimo

14 Diagrama de Comunicação não Concentrador emprestarfita(fcodigo)----> :Videolocadora 5: associaritem() 1: fita:=get(fcodigo) emprestimocorrente: Emprestimo 2: emprestar(fita) 4: criar() fitas: Fita 3: adicionar(fita) 6: associarfita(fita) clientecorrente: Cliente item: ItemDeEmprestimo

15 Código com Responsabilidade Classe VideoLocadora fitas: Conjunto; clientecorrente: Cliente; Distribuída Classe Emprestimo Itens:Conjunto; Metodo emprestarfita(fcodigo:string) fita:fita; fita:=fitas.get(tcodigo); clientecorrente.empresta(fita) Fim Metodo; Fim Classe; Classe Cliente emprestimocorrente: Empretimo; Metodo adicionar(fita:fita); item: ItemDeEmprestimo; item := ItemDeEmprestimo.new(); self.associaitem(item); item.associafita(fita); Fim Metodo; Fim Classe; Método emprestar(fita:fita); emprestimocorrente.adiciona(fita); Fim Método; Fim Classe;

16 Discussão Qual dos códigos é mais fácil de entender e manter? Em qual dos códigos as responsabilidades das classes parecem mais intuitivas? Para desenvolver um bom projeto, precisamos de princípios para nos guiar na atribuição de responsabilidades -> padrões de projeto OO.

17 Responsabilidade Responsabilidade não é a mesma coisa que um método. Métodos são implementados para satisfazer as responsabilidades Responsabilidades são implementadas usando métodos que agem sozinhos ou colaboram com outros métodos e objetos. Padrões de projeto são princípios para guiar a atribuição de responsabilidades aos objetos.

18 Padrões Desenvolvedores experientes em OO criaram um repertório de princípios gerais e boas soluções para guiar a construção de software. Essas soluções foram descritas em um formato padronizado (nome, problema, solução) e podem ser usadas em outros contextos(outros projetos). Surgiram com base no trabalho do arquiteto Christopher Alexander, (Padrões Arquitetônicos). Ganharam impulso após a publicação do livro sobre Padrões de Projeto (Design Patterns Gamma e outros GoF- 1994)

19 Padrões Padrões usualmente não contem novas idéias Organizam conhecimentos e princípios existentes, testados e consagrados. Padrão é uma descrição nomeada de um problema e uma solução, que pode ser aplicado em novos contextos. Nomear padrões melhora a comunicação (criase um vocabulário, ou idioma)

20 Padrões GRASP GRASP = General Responsability Assignment Software Patterns. Descrevem princípios fundamentais de atribuição de responsabilidades a objetos. A compreensão dos padrões de projeto durante a criação de diagramas de comunicação é importante, pois: São princípios de bons projetos Orientado a Objetos. Levam a projetos OO de qualidade.

21 Padrões GRASP Alguns padrões GRASP principais: Especialista (Expert) Criador (Creator) Coesão alta (High Cohesion) Acoplamento fraco (Low Coupling) Controlador (Controller) Esses padrões abordam questões básicas comuns e tópicos fundamentais de desenvolvimento.

22 O padrão Especialista (Expert) Problema: qual é o princípio mais básico para atribuir responsabilidades em projeto orientado a objetos? Solução: Atribuir responsabilidade ao especialista da informação a classe que tem a informação necessária para satisfazer a responsabilidade.

23 Exemplo No sistema biblioteca, quem seria o responsável por calcular a data de devolução de um livro?

24 Modelo Conceitual Biblioteca Atendente nome 1 0..n registra 1 Leitor nome tipo : char ^ faz 0..n 0..n faz 1 0..n Reserva período situacao : char 0..1 Empréstimo/Devolução data do empréstimo situação : Char 0..1 corresponde a corresponde a possui Bibliotecaria nome refere-se a > 1 registra 1 0..n 1 Livro titulo : String[30] autor : String[30] ano : int ISBN : string[20] editora : int tipo : char possui 1..n 0..1 LinhaDoEmpréstimo data_prevista_devolução data_entrega_real 0..n < refere-se a 0..n CopiaDoLivro nro sequencial situacao : char liberadoparaemprestimo : char 1

25 Especialista A data de devolução ficará armazenada no atributo data_prevista_devolução do objeto LinhaDoEmprestimo Mas quem possui conhecimento necessário para calculá-la?

26 Modelo Conceitual Biblioteca Atendente nome 1 0..n registra 1 Leitor nome tipo : char ^ faz 0..n 0..n faz 1 0..n Reserva período situacao : char 0..1 Empréstimo/Devolução data do empréstimo situação : Char 0..1 corresponde a corresponde a possui Bibliotecaria nome refere-se a > 1 registra 1 0..n 1 Livro titulo : String[30] autor : String[30] ano : int ISBN : string[20] editora : int tipo : char possui 1..n 0..1 LinhaDoEmpréstimo data_prevista_devolução data_entrega_real 0..n < refere-se a 0..n CopiaDoLivro nro sequencial situacao : char liberadoparaemprestimo : char 1

27 Especialista Pelo padrão especialista, Leitor deve receber essa atribuição, pois conhece o tipo de Leitor (por exemplo, aluno de graduação, aluno de pós-graduação, professor, etc), que é utilizado para calcular a data em que o livro deve ser devolvido.

28 Especialista adicionarcopia(copialivro)---> : Emprestimo 1: d:=calculardatadevolução() 2: criar(d, copialivro) :Leitor Uso do padrão Especialista linh: LinhaDoEmprestimo

29 Especialista: alternativa mais detalhada adicionarcopia(copialivro) 4: associarlinha(linh) adicionarcopia(copialivro)---> : Emprestimo copialivro: CopiaDoLivro 2: criar(d) 1: d:=calculardatadevolução() :Leitor 3: associarcopia(copialivro) Uso do padrão Especialista linh: LinhaDoEmprestimo

30 Especialista Onde procurar pela classe especialista? Começar pelas classes já estabelecidas durante o projeto. Se não encontrar, utilizar o Modelo Conceitual. Lembrar que existem especialistas parciais que colaboram numa tarefa Informação espalhada -> comunicação via mensagens Existe uma analogia no mundo real.

31 Especialista Discussão É o padrão mais utilizado Tem uma analogia no mundo real Coad: Fazê-lo eu mesmo Lembrar que existem especialistas parciais Benefícios: Mantém encapsulamento -> favorece o acoplamento fraco. O Comportamento fica distribuído entre as classes que tem a informação necessária (classes leves ) -> favorece alta coesão. Favorece o reuso. Contra-indicações contra indicado quando aumenta acoplamento e reduz coesão Ex: quem é responsável por salvar um Empréstimo no banco de dados?

32 Padrão Criador (Creator) Problema: Quem deveria ser responsável pela criação de uma nova instância de alguma classe? Solução: atribua à classe B a responsabilidade de criar uma nova instância da classe A se uma das seguintes condições for verdadeira: B agrega objetos de A B contém objetos de A B registra instâncias de objetos de A B usa objetos de A B tem os valores iniciais que serão passados para objetos de A, quando de sua criação

33 Criador No sistema da Biblioteca, quem é responsável pela criação de uma linhadoemprestimo adicionarcopia(copialivro)---> : Emprestimo 1: d:=calculardatadevolução() 2: criar(d, copialivro) :Leitor Uso do padrão Criador: Emprestimo contém várias linhas de emprestimo linh: LinhaDoEmprestimo Empréstimo/Devolução data do empréstimo situação : Char CriarLinhaEmprest()

34 Discussão Criador O padrão guia a atribuição de responsabilidades relacionadas com a criação de objetos. Escolha adequada favorece acoplamento fraco Objetos agregados, contêineres e registradores são bons candidatos à responsabilidade de criar outros objetos Algumas vezes o candidato a criador é o objeto que conhece os dados iniciais do objeto a ser criado.

35 Acoplamento Acoplamento: dependência entre elementos (classes, subsistemas,...). Normalmente resultante de colaboração para atender a uma responsabilidade. O acoplamento mede o quanto um objeto está conectado a, tem conhecimento de ou depende de outros objetos Acoplamento fraco (ou baixo) um objeto não depende de muitos outros. Acoplamento forte (ou alto) um objeto depende de muitos outros.

36 Acoplamento Problemas do acoplamento alto: Mudanças em classes interdependentes forçam mudanças locais. Dificulta a compreensão do objetivo de cada classe. Dificulta a reutilização. Acoplamento fraco é o desejável

37 Padrão Acoplamento Fraco Problema: como apoiar a baixa dependência entre classes e aumentar a reutilização? Solução: Atribuir responsabilidade de Solução: Atribuir responsabilidade de maneira que o acoplamento permaneça baixo.

38 Padrão Acoplamento Fraco Exemplo: No sistema de biblioteca, suponha que queremos realizar a devolução da cópia do livro. Qual classe deve ser responsável por essa tarefa? Alternativas: A classe Leitor A classe Livro A classe Empréstimo

39 Modelo Conceitual Biblioteca Atendente nome 1 0..n registra 1 Leitor nome tipo : char ^ faz 0..n 0..n faz 1 0..n Reserva período situacao : char 0..1 Empréstimo/Devolução data do empréstimo situação : Char 0..1 corresponde a corresponde a possui Bibliotecaria nome refere-se a > 1 registra 1 0..n 1 Livro titulo : String[30] autor : String[30] ano : int ISBN : string[20] editora : int tipo : char possui 1..n 0..1 LinhaDoEmpréstimo data_prevista_devolução data_entrega_real 0..n < refere-se a 0..n CopiaDoLivro nro sequencial situacao : char liberadoparaemprestimo : char 1

40 Projeto 1: responsabilidade atribuída ao Leitor cop:=busca(codcopia) devolver(datadehoje) Leitor conhece copias do livro? devolvecopia(codcopia)--> leit: Leitor 4: atualizarsituacao('devolvida') 2: devolver(datadehoje) cop: CopiaDoLivro 1: cop:=busca(codcopia) 3: atualizardatadev(datadehoje) copias: CopiaDoLivro Copia conhece linha do empréstimo? linh: LinhaDoEmprestimo

41 Projeto 2: responsabilidade atribuída ao Livro devolvecopia(codcopia)--> liv: Livro 2: devolver(datadehoje) 3: atualizarsituacao('devolvida') 1: cop:=busca(codcopia) cop: CopiaDoLivro copias: CopiaDoLivro 4: atualizardatadev(datadehoje) linh: LinhaDoEmprestimo Eficiente? Cópia conhece a linha de empréstimo?

42 Projeto 3: responsabilidade atribuída ao Empréstimo 1: *[enquanto encontrou=false] linh:==proximo() devolvercopia(codcopia)---> : Emprestimo :LinhaDoEmprestimo 2: * [enquanto encontrou = false] cc:=obtercodigocopia() 4: [encontrou] atualizadatadev(datadehoje) 6: mudarsituacao('devolvida') 3: cc :=CodigoCopia() linh: LinhaDoEmprestimo cop: CopiaDeLivro 5: sinalizadevolucao() encontrou := false enquanto encontrou == false linh := proxima linha do emprestimo cc:=linh.obtercódigocópia() encontrou:=(cc==codcopia) fim-enquanto se encontrou linh.atualizadatadevolucao(datadehoje) fim-se

43 Qual projeto é melhor? Qual dos projetos anteriores favorece o acoplamento fraco? Projeto 1 e 2 acoplamento aumenta (entre cópia do livro e linha do empréstimo, entre leitor e cópia do livro) Projeto 3 não aumenta acoplamento PREFERÍVEL

44 Formas de Acoplamentos Um objeto tem um atributo que referencia um objeto de outra classe. Um objeto tem um método que referencia um objeto de outra classe. Parâmetro, variável local ou retorno Um objeto invoca os serviços de um objeto de outra classe. Uma classe é subclasse de outra, direta ou indiretamente.

45 Discussão: Acoplamento Fraco Acoplamento fraco -> classes mais independentes. Reduz impacto de mudanças. Favorece reuso de classes. Considerado em conjunto com outros padrões Extremo de acoplamento fraco não é desejável Fere princípios da tecnologia de objetos comunicação por mensagens Projeto pobre: objetos inchados e complexos, responsáveis por muito trabalho -> baixa coesão

46 Acoplamento Fraco Discussão: Dica: concentre-se em reduzir o acoplamento em pontos de evolução ou de alta instabilidade do sistema. Benefícios: Classes são pouco afetadas por mudanças em outras partes. Classes são simples de entender isoladamente. Conveniente para reutilização.

47 Coesão Mede o quanto as responsabilidade de um elemento (classe, objeto, subsistema,...) são fortemente focalizadas e relacionadas. (coesão funcional) Objeto com Coesão Alta -> objetos cujas responsabilidades são altamente relacionadas e que não executa um volume muito grande de trabalho. Objeto com Coesão Baixa -> objeto que faz muitas coisas não relacionadas ou executa muitas tarefas. Difícil de compreender, reutilizar e manter. constantemente afetado por mudanças.

48 Coesão Alta Problema: Como manter a complexidade sob controle? Solução: Atribuir responsabilidade de tal forma que a coesão permaneça alta.

49 Coesão Alta Exemplo 1: ( o mesmo para o acoplamento fraco): No sistema de biblioteca, suponha que queremos realizar a devolução da cópia do livro. Qual classe deve ser responsável por essa tarefa? Leitor Livro Empréstimo

50 Projeto 1: responsabilidade atribuída ao Leitor cop:=busca(codcopia) devolver(datadehoje) O Leitor fica parcialmente encarregado da devolução da cópia do livro. Neste exemplo, isso seria aceitável, mas o que aconteceria se houvesse 50 mensagens de outro tipo recebidas por Leitor? devolvecopia(codcopia)--> leit: Leitor 4: atualizarsituacao('devolvida') 2: devolver(datadehoje) cop: CopiaDoLivro 1: cop:=busca(codcopia) 3: atualizardatadev(datadehoje) copias: CopiaDoLivro linh: LinhaDoEmprestimo

51 Projeto 2: responsabilidade atribuída ao Livro devolvecopia(codcopia)--> liv: Livro 2: devolver(datadehoje) 3: atualizarsituacao('devolvida') 1: cop:=busca(codcopia) cop: CopiaDoLivro copias: CopiaDoLivro 4: atualizardatadev(datadehoje) linh: LinhaDoEmprestimo cop:=busca(codcopia) devolver(datadehoje) Parece uma solução melhor. Mas se houver inúmeras operações a serem feitas com o livro, ocorre o mesmo problema de Leitor.

52 Projeto 3: responsabilidade atribuída ao Empréstimo 1: *[enquanto encontrou=false] linh:==proximo() devolvercopia(codcopia)---> : Emprestimo :LinhaDoEmprestimo 2: cc:=codigocopia() 4: [encontrou] atualizadatadev(datadehoje) 6: mudarsituacao('devolvida') 3: cc := codigocopia() linh: LinhaDoEmprestimo cop: CopiaDeLivro encontrou := false enquanto encontrou == false linh := proxima linha do emprestimo cc:= linh.obter o código da cópia() encontrou:=(cc==codcopia) fim-enquanto se encontrou linh.atualizadatadev(datadehoje) fim-se 5: sinalizadevolucao() Esta é a melhor solução. O objeto empréstimo representa eventos bem definidos no sistema de biblioteca (empréstimo e devolução), por isso é mais intuitivo que ele assuma esta responsabilidade.

53 Coesão Alta Discussão: Coesão alta, assim como Acoplamento Fraco, são princípios que devem ser considerados para a avaliação de projetos de objetos Má coesão traz acoplamento e vice-versa Má coesão traz acoplamento e vice-versa Regra prática: classe com coesão alta tem um número relativamente pequeno de métodos, com funcionalidades relacionadas, e não executa muito trabalho. Analogia com mundo real Pessoas que assume muitas responsabilidades não associadas podem tornar-se (e normalmente tornam-se) ineficientes.

54 Coesão Alta Benefícios: Mais clareza e facilidade de compreensão do projeto. Simplificação de manutenção e de acréscimo de funcionalidade/melhorias. Favorecimento do acoplamento fraco. Aumento no potencial de reutilização Classe altamente coesa pode ser usada para uma finalidade bastante específica.

55 Será que a solução dada para o evento de devolução da cópia é ideal? Ainda temos um problema: quando ocorre o evento de devolução da cópia, o objeto empréstimo ao qual a cópia emprestada se refere ainda não é conhecido. Portanto, é preciso eleger alguma classe, que conheça os empréstimos, para receber a mensagem devolvercopia. Essa classe terá que identificar o objeto empréstimo cujo código de cópia seja igual ao parâmetro fornecido.

56 A pergunta anterior não está respondida nos slides a seguir. Voltaremos a ela no fim deste assunto.

57 Controlador É um objeto de interface (entre sistema e mundo externo) responsável por tratar um evento externo (evento de sistema). Define (implementa) o método para a operação de sistema. Operações de sistema associadas aos eventos de sistema: Sistema iniciardevo(idlei) devolver(codcop) FinalizarDevol() Sistema entraritem() terminarvenda() efetuarpagamento()

58 Padrão Controlador Problema: Quem deve ser responsável por tratar um evento do sistema (gerado por um ator externo)? Solução: A responsabilidade de receber ou tratar as mensagens de eventos do sistema (operações) pode ser atribuída uma classe que: Representa o sistema todo, representa o negócio ou organização, um dispositivo ou um subsistema (chamado de controlador fachada) Representa algo no mundo real que é ativo (chamado de controlador do papel) Representa um tratador artificial de todos os eventos de sistema de um caso de uso (Controlador do caso de uso) TratadorDe<NomeDoCasoDeUso> ControladorDe<NomeDoCasoDeUso>

59 Padrão Controlador Exemplo: Quem vai tratar os eventos do sistema de biblioteca? :Atendente Sistema 1: iniciarempréstimo(id_leitor) 2: nome e situação do leitor 3: emprestarlivro(id_livro) 4: datadedevolução * mais livros a emprestar 5: encerrarempréstimo()

60 Cod Cópia Livro Emprestar :Atendente Camada de Interface açãoexecutada(eventodaação) :CWindow emprestarlivro(codcopia) Camada do Domínio Objeto de Interface :????

61 Exemplo1: Opções de Controlador todo o sistema (controlador fachada): Biblioteca um tratador artificial do caso de uso: ControladorDeEmprestarLivro iniciaremprestimo( ) :Biblioteca iniciaremprestimo( ) :ControladorDe EmprestarLivro emprestarlivro( ) :Biblioteca emprestarlivro( ) :ControladorDe EmprestarLivro encerraremprestimo() :Biblioteca encerraremprestimo() :ControladorDe EmprestarLivro 61

62 Discussão : Controladores Fachada Um controlador fachada deve ser um objeto (do domínio) que seja o ponto principal para as chamadas provenientes da interface com o usuário ou de outros sistemas pode ser uma abstração de uma entidade física ex: TerminalDeAtendimento pode ser um conceito que represente o sistema ex: Biblioteca São adequados quando não há uma quantidade muito grande de eventos de sistema Ou quando não é possível redirecionar mensagens do sistema para controladores alternativos (ex: outros subsistemas )

63 Discussão : Controladores de Caso de Uso Deve existir um controlador diferente para cada caso de uso Por exemplo, o ControladorDeEmprestarLivro será responsável pelas operações iniciarempréstimo, emprestarlivro e encerrarempréstimo Não é um objeto do domínio, e sim uma construção artificial para dar suporte ao sistema. Ex: ControladorDeEmprestarLivro, ControladorDeDevolverLivro Pode ser uma alternativa se a escolha de controladores fachada deixar a classe controladora com alto acoplamento e/ou baixa coesão (controlador inchado por excesso de responsabilidades) É uma boa alternativa quando existem muitos eventos envolvendo diferentes processos.

64 Controladores inchados Classe controladora mal projetada - inchada coesão baixa falta de foco e tratamento de muitas responsabilidades Sinais de inchaço: uma única classe controladora tratando todos os eventos, que são muitos. Comum com controladores fachada o próprio controlador executa as tarefas necessárias para atender o evento, sem delegar para outras classes (coesão alta, não especialista) controlador tem muitos atributos e mantém informação significativa sobre o domínio, ou duplica informações existentes em outros lugares

65 Possíveis soluções para controladores inchados Acrescentar mais controladores. Projetar o controlador de forma que ele possa delegar o atendimento da responsabilidade de cada operação de sistema a outros objetos. Cuidado: Controladores de papéis podem conduzir a maus projetos(armadilha de projetar objetos semelhantes a pessoas para fazer todo o trabalho é preciso delegar)

66 Corolário do Padrão Controlador Objetos de interfaces HM ( como objetos janela ) e da camada de apresentação não devem ter a responsabilidade de tratar eventos do sistema (arquitetura em camadas)

67 Benefícios do Padrão Controlador e seu corolário Benefícios: aumento das possibilidades de reutilização de classes e do uso de interfaces plugáveis. conhecimento do estado do caso de uso controlador pode armazenar estado do caso de uso, garantindo a seqüência correta de execução de operações

68 Cod Cópia Livro Devolver :Atendente Camada de Interface :CWindow açãoexecutada(eventodaação) devolver Copia? devolvercopia(codcopia) Camada do Domínio???? devolvercopia(codcopia) :Emprestimo

69 Voltando ao problema do slide Qual era o problema: devolvercópia x Empréstimo Qual é a solução? Classe Fachada ou Controladora

70 Cod Cópia Livro Devolver :Atendente Camada de Interface :CWindow açãoexecutada(eventodaação) devolver Copia? devolvercopia(codcopia) Camada do Domínio :Biblioteca devolvercopia(codcopia) :Emprestimo

71 Próximo assunto Refinar Plano Sincronizar artefatos Analisar Projetar Construir Testar Padrões GRASP Estudo de Caso TPV : Projetar uma solução com objetos e Padrões GRASP