DIAGRAMA DE COMUNICAÇÃO

Transcrição

1 Universidade de São Paulo, Instituto de Ciências Matemáticas e de Computação DIAGRAMA DE COMUNICAÇÃO SSC 621: Análise e Projeto Orientados a Objetos Prof. Dr. Lucas Bueno R. Oliveira 2º Semestre 2015

2 O QUE JÁ FOI VISTO ATÉ AGORA Diagrama de Casos de Uso Casos de Uso Completo Abstrato Ator Principal: Atendente Interessados e Interesses: Caso de Uso: Emprestar Livro Emprestar Livro - Atendente: deseja registrar que um ou mais livros estão em posse de um leitor, para controlar se a devolução será feita no tempo determinado. - Leitor: deseja emprestar um ou mais livros, de forma rápida e segura. - Bibliotecário: deseja controlar o uso dos livros, para que não se percam e para que sempre se saiba com que leitor estão no momento. Pré-Condições: O Atendente é identificado e autenticado. Atendente Bibliotecária Devolver Livro Incluir Livro Leitor Consultar Livro Garantia de Sucesso (Pós-Condições): Os dados do novo empréstimo estão armazenados no Sistema. Os livros emprestados possuem status emprestado Cenário de Sucesso Principal: 1. O Leitor chega ao balcão de atendimento da biblioteca e diz ao atendente que deseja emprestar um ou mais livros da biblioteca. 2. O Atendente seleciona a opção para realizar um novo empréstimo. 3. O Atendente solicita ao leitor sua carteira de identificação, seja de estudante ou professor. 4. O Atendente informa ao sistema a identificação do leitor. 5. O Sistema exibe o nome do leitor e sua situação. 6. O Atendente solicita os livros a serem emprestados. 7. Para cada um deles, informa ao sistema o código de identificação do livro. 8. O Sistema informa a data de devolução de cada livro. 9. Se necessário, o Atendente desbloqueia os livros para que possam sair da biblioteca. 10. O Leitor sai com os livros. Fluxos Alternativos: Comprar Livro (1-8). A qualquer momento o Leitor informa ao Atendente que desistiu do empréstimo. 3. O Leitor informa ao Atendente que esqueceu a carteira de identificação. 1. O Atendente faz uma busca pelo cadastro do Leitor e pede a ele alguma informação pessoal para garantir que ele é mesmo quem diz ser. 4. O Leitor está impedido de fazer empréstimo, por ter não estar apto. 1.Cancelar a operação. 7a. O Livro não pode ser emprestado, pois está reservado para outro leitor. 1. O Atendente informa ao Leitor que não poderá emprestar o livro e pergunta se deseja reservá-lo. 2. Cancelar a operação (se for o único livro) 7b. O Livro não pode ser emprestado, pois é um livro reservado somente para consulta. 1. Cancelar a operação (se for o único livro) 2

3 O QUE JÁ FOI VISTO ATÉ AGORA Casos de Uso com substantivos e verbos sublinhados Caso de Uso 1 1. O Leitor chega ao balcão de atendimento da biblioteca e diz ao atendente que deseja emprestar um ou mais livros da biblioteca. 2. O Atendente seleciona a opção para adicionar um novo empréstimo. 3. O Atendente solicita ao leitor sua carteirinha, seja de estudante ou professor. 4. O Atendente informa ao sistema a identificação do leitor. 5. O Sistema exibe o nome do leitor e sua situação. 6. O Atendente solicita os livros a serem emprestados. 7. Para cada um deles, informa ao sistema o código de identificação do livro. 8. O Sistema informa a data de devolução de cada livro. 9. O Atendente desbloqueia os livros para que possam sair da biblioteca. 10. O Leitor sai com os livros. Caso de Uso n 1. O Leitor chega ao balcão de atendimento da biblioteca e diz ao atendente que deseja emprestar um ou mais livros da biblioteca. 2. O Atendente seleciona a opção para adicionar um novo empréstimo. 3. O Atendente solicita ao leitor sua carteirinha, seja de estudante ou professor. 4. O Atendente informa ao sistema a identificação do leitor. 5. O Sistema exibe o nome do leitor e sua situação. 6. O Atendente solicita os livros a serem emprestados. 7. Para cada um deles, informa ao sistema o código de identificação do livro. 8. O Sistema informa a data de devolução de cada livro. 9. O Atendente desbloqueia os livros para que possam sair da biblioteca. 10. O Leitor sai com os livros. Atendente nome Bibliotecaria nome n registra refere-se a > Leitor nome tipo : char registra 0..n 0..n ^ faz n Modelo Conceitual 1..1 faz Reserva período situacao : char 0..1 Empréstimo/Devolução data do empréstimo n situação : Char Livro titulo : String[30] autor : String[30] ano : int ISBN : string[20] editora : int tipo : char possui 0..n 0..1 corresponde a corresponde a CopiaDoLivro 0..1 nro sequencial situacao : char liberadoparaemprestimo : char 1..1 possui 1..n 0..1 LinhaDoEmpréstimo data_prevista_devolução data_entrega_real n < refere-se a 3

4 4 O QUE JÁ FOI VISTO ATÉ AGORA Diagrama de Sequência do Sistema (para cada caso de uso) Modelo Conceitual + Casos de Uso :Atendente 1: iniciarempréstimo(id_leitor) 2: emprestarlivro(id_livro) Sistema * mais livros a emprestar 3: encerrarempréstimo()

5 5 O QUE JÁ FOI VISTO ATÉ AGORA Diagrama de Sequência do Sistema (para cada caso de uso) Contrato da Operação (para cada operação relevante) :Atendente Sistema Operação: encerrarempréstimo() 1: iniciarempréstimo(id_leitor) 2: emprestarlivro(id_livro) * mais livros a emprestar 3: encerrarempréstimo() Referências Cruzadas: Caso de uso: Emprestar Livro Pré-Condições: Umleitor apto a emprestar livros já foi identificado; pelo menos umlivro já foi identificado e está disponível para ser emprestado. Pós-Condições: umnovo empréstimo foi registrado; o novo empréstimo foi relacionado ao leitor já identificado na operação iniciar o empréstimo ; a situação dos livros emprestados foi alterada para emprestado.

6 CONCLUSÃO DA FASE DE ANÁLISE A fase de análise enfatiza uma compreensão dos requisitos do sistema Fazer a Coisa Certa compreender objetivos, conceitos e características do domínio do problema Artefatos estudados: Artefato da análise Casos de Uso Modelo Conceitual Diagramas de Sequência do Sistema Questões respondidas Quais são os processos do domínio? Quais são os conceitos (objetos)? Quais são os eventos e operações? 6

7 INÍCIO DA FASE DE PROJETO Nessa fase, é desenvolvida uma solução lógica baseada no paradigma de orientação a objetos objetos, mensagens, classes, métodos,. Fazer certo a coisa projetar de maneira competente uma solução que satisfaça os requisitos Os dois artefatos principais a serem desenvolvidos são: Diagramas de Interação Diagramas de Classe de Projeto 7

8 DIAGRAMAS DE INTERAÇÃO Os Diagramas de Interação apresentam como os objetos interagem, por meio de mensagens, para responder a um determinado evento Importantes para o desenvolvimento de um bom projeto Exigem criatividade A UML fornece dois tipos de diagramas de interação que permitem representar interação (colaboração) entre classes (ou objetos): diagramas de comunicação formato de grafo diagramas de sequência formato de cerca 8

9 DIAGRAMA DE COMUNICAÇÃO mensagem1() :Instância da Classe A 1:mensagem2)) 2:mensagem3() :Instância da Classe B Os diagramas de comunicação têm melhor capacidade de expressar informações contextuais e podem ser mais econômicos em termos de espaço 9

10 DIAGRAMA DE SEQUÊNCIA :instância de Classe A :instância de Classe B :instância de Classe C mensagem1() 1:mensagem2() 2:mensagem3() 3:mensagem4() 10

11 DIAGRAMA DE COMUNICAÇÃO O Diagrama de Comunicação é um dos artefatos mais importantes do projeto OO O tempo gasto na sua criação deveria absorver um percentual de tempo significativo projeto Elaborar diagramas de comunicação exige conhecimento de: princípios de atribuição de responsabilidades padrões de projeto 11

12 CLASSES E INSTÂNCIAS Classe Instância Instância nomeada Venda :Venda venda1:venda 12

13 MENSAGENS Sintaxe UML: retorno := mensagem ( parâmetro : tipoparâmetro ) : tiporetorno O retorno pode não existir Os tipos podem ser omitidos ser forem óbvios ou não forem importantes Exemplo: especificacao := obterespecificacaoproduto(id) especificacao := obterespecificacaoproduto(id:iditem) especificacao := obterespecificacaoproduto(id:iditem) : EspecificacaoProduto 13

14 MENSAGENS No paradigma de orientação a objetos: Mensagem é o mecanismo de comunicação entre objetos Invoca as operações desejadas O processo de invocar um método é chamado de envio de uma mensagem ao objeto Ex: quando uma mensagem facaalgo() é enviada a uma objeto obj, o método facaalgo() definido na classe de obj é executado: obj.facaalgo() 14

15 LIGAÇÕES Conexão entre dois objeto que indica a possibilidade de alguma forma de navegação ou de visibilidade entre eles Permite que mensagens fluam de um objeto para outro :TPV total:=totalizarvenda():float :Venda :Venda.totalizarVenda() 15

16 MENSAGENS MÚLTIPLAS Várias mensagens, em ambos os sentidos, podem fluir ao longo de uma mesma ligação: Usar seta para indicar direção da mensagem Usar números de sequência para indicar ordem de execução das mensagens :Instância Classe A 1:mensagem1() 2:mensagem2() 3:mensagem3() 4:mensagem4() :Instância Classe B 16

17 EXEMPLO acionar() :BotaoElevador 1:atualizar( ) 2:iluminar( ) :ControladorElevador 17

18 em algum lugar no sistema PRIMEIRA MENSAGEM A primeira mensagem é aquela enviada ao objeto que inicia o tratamento de um determinado evento O emissor da primeira mensagem não é identificado primeiramsg() :Instância Classe A 1:mensagem1() 2:mensagem2() 3:mensagem3() 4:mensagem4() :Instância Classe B :InstanciaClasseA.primeiraMsg() 18

19 EXEMPLO Aterrissar() :Aeronave 1:ok :=posicionarangulo(angulo):booleano :Flape 19

20 NÚMERO DE SEQUÊNCIA DA MENSAGEM Primeira mensagem não é numerada Numeração formal e agregada indica a ordem e o aninhamento das mensagens msg1() :ClasseA 1:msg2() :ClasseB 1.1:msg3() aninhamento de mensagens :ClasseC 20

21 ANINHAMENTO DE MENSAGENS msg1() :ClasseA msg1() :ClasseB.msg2() 1:msg2() msg2() :ClasseC.msg3() :ClasseB 1.1:msg3() :ClasseC 21

22 ANINHAMENTO DE MENSAGENS EXEMPLO Msg1() :ClasseA 1:msg2() 2:msg4() :ClasseB 1.1:msg3() 2.1:msg5() :ClasseC 2.2:msg6() :ClasseD 22

23 ANINHAMENTO DE MENSAGENS EXEMPLO em algum lugar no sistema :ClasseA.msg1() msg1() :ClasseB.msg2() :ClasseC.msg4() msg2() :ClasseC.msg3() msg4() :ClasseB.msg5() :ClasseD.msg6() 23

24 AUTOMENSAGEM (THIS) msg1() :ClasseA 1: msg2() iniciarsistema() :TPV 1: iniciar() 24

25 msg1() ITERAÇÃO msg1() :ClasseA 1*:[i:=1..10]msg2() for i=1 to 10 { :ClasseB.msg2() :ClasseC.msg3() } :ClasseB 2*:[i:=1..10]msg3() :ClasseC 25

26 ITERAÇÃO msg1() :TPV 1 * : linha:=proxlinhaitem():linhaitemvenda :Venda Cláusula de Iteração ([i:=1..10]) é opcional 26

27 CRIAÇÃO DE INSTÂNCIA Uma mensagem pode ser usada para criar uma instância nomear mensagem como criar() :TPV iniciarvenda() 1:criar(caixa) mensagem criar(), com parâmetros opcionais, normalmente é interpretada, na implementação, como chamada a um construtor da classe de software :Venda 27

28 MENSAGENS CONDICIONAIS Uma mensagem condicional só será enviada se a cláusula entre [ ] tiver valor true :ClasseA msg1() 1: [condição] msg2() msg1() if (condicao = true) { :ClasseB.msg2() } :ClasseB 28

29 MENSAGENS CONDICIONAIS msg1() :TPV 1: [nova venda] criar() :Venda 29

30 CONDICIONAL MUTUAMENTE EXCLUSIVA Apenas uma ou outra mensagem é enviada dependendo da condição ser verdadeira ou falsa msg1() :ClasseA 1a: [condição] msg2() msg1() if (condicao = true) :ClasseB.msg2() else :ClasseC.msg3() :ClasseB 1b:[not condição] msg3() :ClasseC 30

31 CONDICIONAL MUTUAMENTE EXCLUSIVA :ClasseE 2:msg6() msg1() :ClasseA 1a: [condição] msg2() :ClasseB 1b:[not condição] msg4() 1a.1:msg3() :ClasseD 1b.1:msg5() :ClasseC 31

32 MULTIOBJETOS Um multiobjeto é uma coleção de instâncias, representada por um único ícone Uma mensagem pode ser enviada ao multiobjeto ou a cada membro da coleção 32

33 MENSAGENS PARA MULTIOBJETOS :Venda msg1() mensagem enviada à coleção 1: qt:=obterquantidade( ) : Int ItemLinhaVenda :Venda msg1() 1*: id:=obterid( ) * ItemLinhaVenda mensagem enviada a cada membro da coleção 33

34 EXEMPLO TPV - DSS :Caixa iniciarnovavenda( ) Comprar Itens :Sistema entraritem(cup, quantidade) descrição item, total *[mais itens] terminarvenda() fazerpagamento(quantia) troco, recibo 34

35 EXEMPLO TPV MODELO CONCEITUAL Venda data hora 1..1 Capturada-em 1..1 TPV 1..1 Paga-por 1..1 Pagamento quantia 35

36 EXEMPLO - DIAGRAMA DE COMUNICAÇÃO fazerpagamento(quantia) :TPV 1:fazerPagamento(quantia) :Venda 1.1:criar(quantia) :Pagamento 36

37 PORTANTO É importante ser consistente ao sublinhar os nomes de instância quando realmente se deseja uma instância; caso contrário, mensagens para instâncias e mensagens para classes podem ser interpretadas incorretamente. 37

38 GRASP: PADRÕES PARA ATRIBUIÇÃO DE RESPONSABILIDADES Responsabilidade Um contrato ou obrigação de um tipo ou classe Serviços fornecidos por um elemento (classe ou subsistema) Incorpora os objetivos de um elemento 38

39 GRASP: PADRÕES PARA ATRIBUIÇÃO DE RESPONSABILIDADES Dois tipos de responsabilidades básicas: Fazer: fazer algo (criar um objeto, executar uma operação ) iniciar ações em outros objetos coordenar e controlar atividades em outros objetos Saber: conhecer dados privados encapsulados conhecer objetos relacionados conhecer coisas que podem ser derivadas ou calculadas 39

40 RESPONSABILIDADE Exemplos: uma Venda é responsável por criar ItemLinhaVenda - FAZER uma Venda é responsável por conhecer o seu total - SABER Obs: responsabilidades do tipo saber frequentemente podem ser deduzidas do modelo conceitual (atributos e associações) 40

41 RESPONSABILIDADES E DIAGRAMAS DE COMUNICAÇÃO Diagramas de comunicaçã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 41

42 EXEMPLO fazerpagamento(quantia) :Venda 1:criar(quantia) Responsabilidade Fazer Pagamento atribuída ao objeto Venda colaboração entre Venda e Pagamento :Pagamento 42

43 PADRÕES Padrão é uma descrição nomeada de um problema e uma solução, que pode ser aplicado em novos contextos Padrões usualmente não contêm novas ideias organizam conhecimentos e princípios existentes, testados e consagrados 43

44 PADRÕES GRASP GRASP = General Responsibility Assignment Software Patterns Descrevem princípios fundamentais de atribuição de responsabilidade a objetos Principais padrões GRASP: Especialista (Expert) Criador (Creator) Coesão alta (High Cohesion) Acoplamento fraco (Low Coupling) Controlador (Controller) 44

45 ESPECIALISTA Problema: qual é o princípio mais básico de atribuição de responsabilidades a objetos? Solução: Atribuir responsabilidade ao especialista da informação. Exemplo: no sistema TPV, alguma classe precisa conhecer o total geral de uma venda 45

46 EXEMPLO Venda => conhece o total da venda ItemLinhaVenda => conhece o subtotal da linha EspecificaçãoProduto => conhece o preço do produto. 46

47 t:=obtertotal( ) :Venda 1*: st:=obtersubtotal( ) * :LinhadeItemdeVenda 1.1: p:=obterpreço( ) :Especificaçãode Produto

48 ESPECIALISTA Discussão: É o padrão mais utilizado Fazê-lo eu mesmo Objetos fazem coisas relacionadas à informação que têm Lembrar que existem especialistas parciais que colaboram numa tarefa informação espalhada comunicação via mensagens Tem uma analogia no mundo real 48

49 ESPECIALISTA Benefícios: Mantém encapsulamento favorece o acoplamento fraco O comportamento fica distribuído entre as classes que têm a informação necessária favorece alta coesão Contraindicações Contra indicado quando aumenta acoplamento e reduz coesão Ex: quem é responsável por salvar uma Venda no banco de dados? 49

50 CRIADOR 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/contém/registra 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 50

51 CRIADOR Exemplo: No sistema TPV, quem é responsável pela criação de uma instância de ItemLinhaVenda? criaritemlinha (quantidade) :Venda Venda contém vários itens de linha de venda 1:criar(quantidade) :ItemLinhaVenda 51

52 CRIADOR Discussão Objetivo do padrão: definir como criador o objeto que precise ser conectado ao objeto criador em algum evento Escolha adequada favorece acoplamento fraco Objetos agregados e contêineres 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 Ex: Venda e Pagamento 52

53 EXEMPLO fazerpagamento(quantia) :Venda Venda possui dados iniciais do pagamento 1:criar(quantia) :Pagamento 53

54 CRIADOR Benefícios Favorece o acoplamento fraco provavelmente o acoplamento não é aumentado porque o objeto criado provavelmente já é visível para o objeto criador, devido às associações existentes que motivaram sua escolha como criador 54

55 ACOPLAMENTO Dependência entre elementos (classes, subsistemas ), normalmente resultante de comunicaçã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 55

56 ACOPLAMENTO Formas de acoplamento: 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 56

57 ACOPLAMENTO Problemas do acoplamento alto: Mudanças em classes interdependentes forçam mudanças locais Dificulta reutilização 57

58 ACOPLAMENTO FRACO Problema: como favorecer a baixa dependência e aumentar a reutilização? Solução: Atribuir responsabilidade de maneira que o acoplamento permaneça baixo. Exemplo: No sistema TPV, suponha que queremos criar uma instância de pagamento e associá-la à venda. Qual classe deve ser responsável por essa tarefa? 58

59 Projeto 1: segundo padrão Criador, responsabilidade atribuída ao TPV fazerpagamento( ) :TPV 1: criar( ) p:pagamento 2 : adicionarpagamento(p) :Venda Projeto 2: alternativa responsabilidade atribuída à Venda fazerpagamento( ) :TPV 1: fazer Pagamento( ) 1.1: criar( ) :Venda :Pagamento

60 Projeto 1: segundo padrão Criador, responsabilidade atribuída ao TPV fazerpagamento( ) :TPV 1: criar( ) p:pagamento 2 : adicionarpagamento(p) :Venda Projeto 2: alternativa responsabilidade atribuída à Venda fazerpagamento( ) :TPV PREFERÍVEL 1: fazer Pagamento( ) 1.1: criar( ) :Venda :Pagamento

61 ACOPLAMENTO FRACO Discussão: Acoplamento fraco classes mais independentes Reduz impacto de mudanças Favorece reúso de classes 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 61

62 ACOPLAMENTO FRACO Discussão: Dica: concentre-se em reduzir o acoplamento em pontos de evolução ou de alta instabilidade do Sistema Ex: cálculo de impostos terceirizados no sistema TPV Benefícios: Classe são pouco afetadas por mudanças em outras partes Classes são simples de entender isoladamente Conveniente para reutilização 62

63 COESÃO Coesão mede o quanto as responsabilidades de um elemento (classe, objeto, subsistema, ) são fortemente focalizadas e relacionadas Objeto com Coesão Alta objeto 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 afetadas por mudanças 63

64 COESÃO ALTA Problema: Como manter a complexidade sob controle? Solução: Atribuir responsabilidade de tal forma que a coesão permaneça alta. Exemplo (o mesmo para o acoplamento fraco): No sistema TPV, suponha que queremos criar uma instância de pagamento e associá-la à venda. Qual classe deve ser responsável por essa tarefa? 64

65 Projeto 1: segundo padrão Criador, responsabilidade atribuída ao TPV fazerpagamento( ) :TPV 1: criar( ) p:pagamento 2 : adicionarpagamento(p) :Venda O TPV toma parte na responsabilidade de fazer pagamento. Neste exemplo, isso seria aceitável, mas o que aconteceria se houvessem 50 mensagens recebidas por TPV?

66 Projeto 2: alternativa responsabilidade atribuída à Venda fazerpagamento( ) :TPV 1: fazer Pagamento( ) 1.1: criar( ) :Venda :Pagamento Esta solução favorece uma coesão mais alta em TPV e também um acoplamento mais fraco. Portanto, projeto 2 é preferível.

67 COESÃO ALTA Discussão: Coesão alta, assim como Acoplamento Fraco, são princípios que devem ser considerados no projeto de objetos Má coesão traz acoplamento ruim 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 Ex: pessoas que assumem muitas responsabilidades não associadas podem tornar-se (e normalmente tornam-se) ineficientes 67

68 COESÃO ALTA Benefícios Mais clareza e facilidade de compreensão no projeto Simplificação de manutenção e 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 68

69 CONTROLADOR Problema: Quem deve ser responsável por tratar um evento do sistema? Solução: A responsabilidade de receber ou tratar as mensagens de eventos (operações) do sistema pode ser atribuída a uma classe que: Represente todo o sistema, um dispositivo ou um subsistema chamado de controlador fachada - OU Represente um cenário de um caso de uso dentro do qual ocorra o evento TratadorDe<NomeDoCasoDeUso>, ControladorDe<NomeDoCasoDeUso> 69

70 CONTROLADOR Exemplo: quem vai tratar os eventos do sistema TPV? Comprar Itens :Sistema :Caixa iniciarnovavenda( ) entraritem(cup, quantidade) descrição item, total *[mais itens] terminarvenda() fazerpagamento(quantia) troco, recibo 70

71 ID Item Quantidade :Caixa Entrar Item açãoexecutada(eventodaação) Camada de Interface :CWindow entraritem(itemid, quantidade) Camada do Domínio :????

72 EXEMPLO: OPÇÕES DE CONTROLADOR todo o sistema (controlador fachada): TPV um tratador do caso de uso: ControladorDeComprarItem entraritem( ) :TPV entraritem( ) :ControladorDe ComprarItem 72

73 DISCUSSÃO: CONTROLADORES DE CASOS DE USO Deve existir um controlador para cada caso de uso Não é um objeto do domínio, e sim uma construção artificial para dar suporte ao sistema. Ex: ControladorDeComprarItem, ControladorDeDevolução Pode ser uma alternativa se a escolha de controladores fachada deixar a classe controladora com alto acoplamento e/ou baixa coesão É uma boa alternativa quando existem muitos eventos envolvendo diferentes processos 73

74 CONTROLADORES INCHADOS Classe controladora mal projetada Coesão baixa - falta de foco e tratamentos de muitas responsabilidades Sinais de inchaço: Uma única classe controladora tratando todos os eventos, que são muitos. O próprio controlador executa as tarefas necessárias para atender o evento, sem delegar para outras classes Controlador tem muitos atributos ou duplica informações existentes em outros lugares 74

75 CONTROLADOR Curas para controladores inchados Acrescentar mais controladores misturar controladores fachada e de casos de uso Delegar responsabilidades 75

76 CONTROLADOR Benefícios: Conhecimento do estado do caso de uso controlador pode armazenar estado do caso de uso, garantindo a sequência correta de execução de operações Redução da complexidade das classes do modelo 76

77 EXEMPLO: ACOPLAMENTO

78 EXEMPLO: ACOPLAMENTO