Diagrama de Comunicação. SSC 526 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa

Transcrição

1 Diagrama de Comunicação SSC 526 Análise e Projeto Orientado a Objeto Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de

2 2 O que já foi visto até agora Casos de Uso Completo Abstrato Diagrama de Casos de Uso Emprestar Livro A t o r P r i n c i p a l : A t e n d e n t e I n t e r e s s a d o s e I n t e r e s s e s : C a s o d e U s o : E m p r e s t a r L i v r o - A t e n d e n t e : d e s e j a r e g i s t r a r q u e u m o u m a i s l i v r o s e s t ã o e m p o s s e d e u m l e i t o r, p a r a c o n t r o l a r s e a d e v o l u ç ã o s e r á f e i t a n o t e m p o d e t e r m i n a d o. - L e i t o r : d e s e j a e m p r e s t a r u m o u m a i s l i v r o s, d e f o r m a r á p i d a e s e g u r a. - B i b l i o t e c á r i o : d e s e j a c o n t r o l a r o u s o d o s l i v r o s, p a r a q u e n ã o s e p e r c a m e p a r a q u e s e m p r e s e s a i b a c o m q u e l e i t o r e s t ã o n o m o m e n t o. P r é - C o n d i ç õ e s : O A t e n d e n t e é i d e n t i f i c a d o e a u t e n t i c a d o. Atendente Devolver Livro Leitor G a r a n t i a d e S u c e s s o ( P ó s - C o n d i ç õ e s ) : O s d a d o s d o n o v o e m p r é s t i m o e s t ã o a r m a z e n a d o s n o S i s t e m a. O s l i v r o s e m p r e s t a d o s p o s s u e m s t a t u s e m p r e s t a d o C e n á r i o d e S u c e s s o P r i n c i p a l : Bibliotecária Incluir Livro Comprar Livro Consultar Livro 1. O L e i t o r c h e g a a o b a l c ã o d e a t e n d i m e n t o d a b i b l i o t e c a e d i z a o a t e n d e n t e q u e d e s e j a e m p r e s t a r u m o u m a i s l i v r o s d a b i b l i o t e c a. 2. O A t e n d e n t e s e l e c i o n a a o p ç ã o p a r a r e a l i z a r u m n o v o e m p r é s t i m o. 3. O A t e n d e n t e s o l i c i t a a o l e i t o r s u a c a r t e i r a d e i d e n t i f i c a ç ã o, s e j a d e e s t u d a n t e o u p r o f e s s o r. 4. O A t e n d e n t e i n f o r m a a o s i s t e m a a i d e n t i f i c a ç ã o d o l e i t o r. 5. O S i s t e m a e x i b e o n o m e d o l e i t o r e s u a s i t u a ç ã o. 6. O A t e n d e n t e s o l i c i t a o s l i v r o s a s e r e m e m p r e s t a d o s. 7. P a r a c a d a u m d e l e s, i n f o r m a a o s i s t e m a o c ó d i g o d e i d e n t i f i c a ç ã o d o l i v r o. 8. O S i s t e m a i n f o r m a a d a t a d e d e v o l u ç ã o d e c a d a l i v r o. 9. S e n e c e s s á r i o, o A t e n d e n t e d e s b l o q u e i a o s l i v r o s p a r a q u e p o s s a m s a i r d a b i b l i o t e c a. 10. O L e i t o r s a i c o m o s l i v r o s. F l u x o s A l t e r n a t i v o s : (1-8). A q u a l q u e r m o m e n t o o L e i t o r i n f o r m a a o A t e n d e n t e q u e d e s i s t i u d o e m p r é s t i m o. 3. O L e i t o r i n f o r m a a o A t e n d e n t e q u e e s q u e c e u a c a r t e i r a d e i d e n t i f i c a ç ão. 1. O A t e n d e n t e f a z u m a b u s c a p e l o c a d a s t r o d o L e i t o r e p e d e a e l e a l g u m a i n f o r m a ç ã o p e s s o a l p a r a g a r a n t i r q u e e l e é m e s m o q u e m d i z s e r. 4. O L e i t o r e s t á i m p e d i d o d e f a z e r e m p r é s t i m o, p o r t e r n ã o e s t a r a p t o. 1.C a n c e l a r a o p e r a ç ã o. 7 a. O L i v r o n ã o p o d e s e r e m p r e s t a d o, p o i s e s t á r e s e r v a d o p a r a o u t r o l e i t o r. 1. O A t e n d e n t e i n f o r m a a o L e i t o r q u e n ã o p o d e r á e m p r e s t a r o l i v r o e p e r g u n t a s e d e s e j a r e s e r v á - l o. 2. C a n c e l a r a o p e r a ç ã o ( s e f o r o ú n i c o l i v r o ) 7 b. O L i v r o n ã o p o d e s e r e m p r e s t a d o, p o i s é u m l i v r o r e s e r v a d o s o m e n t e p a r a c o n s u l t a. 1. C a n c e l a r a o p e r a ç ã o ( s e f o r o ú n i c o l i v r o )

3 3 O que já foi visto até agora Casos de Uso com substantivos e verbos sublinhados Caso de Uso 1 1. OLeitor chegaaobalcãodeatendimentodabibliotecaedizaoatendentequedeseja emprestar umoumaislivrosdabiblioteca. 2. OAtendenteselecionaaopçãoparaadicionar umnovoempréstimo. 3. OAtendentesolicitaaoleitor suacarteirinha, sejadeestudanteouprofesor. 4. OAtendenteinformaaosistemaaidentificaçãodoleitor. 5. OSistemaexibeonomedoleitor esuasituação. 6. OAtendentesolicitaoslivrosaserememprestados. 7. Paracadaumdeles, informaaosistemaocódigodeidentificaçãodolivro. 8. OSistemainformaadatadedevoluçãodecadalivro. 9. OAtendentedesbloqueiaoslivrosparaqueposamsair dabiblioteca. 10. OLeitor sai comoslivros. Caso de Uso n Atendente nome Bibliotecaria nome n registra refere-se a > 1..1 Modelo Conceitual 1..1 Leitor nome tipo : char registra 0..n 0..n ^ faz n faz Reserva período situacao : char 0..1 Empréstimo/Devolução data do empréstimo n situação : Char 1..1 Livro titulo : String[30] autor : String[30] ano : int ISBN : string[20] editora : int tipo : char possui 0..1 corresponde a corresponde a possui 1..n 0..1 LinhaDoEmpréstimo data_prevista_devolução data_entrega_real 0..n < refere-se a 1. OLeitor chegaaobalcãodeatendimentodabibliotecaedizaoatendentequedeseja emprestar umoumaislivrosdabiblioteca. 2. OAtendenteselecionaaopçãoparaadicionar umnovoempréstimo. 3. OAtendentesolicitaaoleitor suacarteirinha, sejadeestudanteouprofesor. 4. OAtendenteinformaaosistemaaidentificaçãodoleitor. 5. OSistemaexibeonomedoleitor esuasituação. 6. OAtendentesolicitaoslivrosaserememprestados. 7. Paracadaumdeles, informaaosistemaocódigodeidentificaçãodolivro. 8. OSistemainformaadatadedevoluçãodecadalivro. 9. OAtendentedesbloqueiaoslivrosparaqueposamsair dabiblioteca. 10. OLeitor sai comoslivros. 0..n CopiaDoLivro nro sequencial situacao : char liberadoparaemprestimo : char 1..1

4 4 O que já foi visto até agora Modelo Conceitual + Casos de Uso Diagrama de Seqüência do Sistema (para cada caso de uso) :Atendente 1: iniciarempréstimo(id_leitor) Sistema 2: emprestarlivro(id_livro) * mais livros a emprestar 3: encerrarempréstimo()

5 5 O que já foi visto até agora Diagrama de Seqüência do Sistema (para cada caso de uso) Contrato da Operação (para cada operação) :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 Projetar 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 Diagramas de Interação apresentam como os objetos interagem, por meio de mensagens, para responder a um determinado evento são 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 seqüê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 Diagramas de Comunicação Diagrama de Comunicação - um dos artefatos mais importantes criados no projeto OO o tempo gasto na sua criação deveria absorver um percentual de tempo significativo do tempo gasto no 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: ( obterespecificacaoproduto(id especificacao := ( obterespecificacaoproduto(id:iditem especificacao := 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 façaalgo() é enviada a uma objeto obj, o método façaalgo() definido na classe de obj é executado: () obj.façaalgo 14

15 Ligações Ligação: conexão em 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 :BotãoElevador ( 2:iluminar( ( 1:atualizar( :ControladorElevador 17

18 em algum lugar no sistema Primeira Mensagem A primeira mensagem é aquela enviada ao objeto que inicia o tratamento a 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 () InstÂnciaClasseA.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 1:msg2() :ClasseB () msg1 () ClasseB.msg2 : () msg2 () ClasseC.msg3 : 1.1:msg3() :ClasseC 21

22 Aninhamento de Mensagens Exemplo msg1() :ClasseA 1:msg2() :ClasseB 1.1:msg3() 2:msg4() 2.1:msg5() :ClasseC :ClasseD 2.2:msg6() 22

23 Aninhamento de Mensagens Exemplo (. cont ) () ClasseA.msg1 : em algum lugar no sistema () msg1 () ClasseB.msg2 : () ClasseC.msg4 : () msg2 () ClasseC.msg3 : () msg4 () ClasseB.msg5 : () ClasseD.msg6 : 23

24 Auto-Mensagem (this) () msg1 :ClasseA () msg2 :1 () iniciarsistema :TPV 1: iniciar() 24

25 Iteração msg1() () msg1 for i=1 to 10 { () ClasseB.msg2 : () ClasseC.msg3 : } :ClasseA () 1*:[i:=1..10]msg2 :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() mensagem criar(), com parâmetros opcionais, normalmente é interpretada, na :TPV iniciarvenda() 1:criar(caixa) 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 :ClasseB if (condicao = true) { () ClasseB.msg2 : } 28

29 Mensagens Condicionais msg1() :TPV 1: [nova venda] criar() :Venda 29

30 Caminhos Condicionais Mutuamente Exclusivos 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 : () ClasseC.msg3 : else :ClasseB 1b:[not condição] msg3() :ClasseC 30

31 Caminhos Condicionais Mutuamente Exclusivos :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 TPV 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 versus mensagens para classes podem ser interpretadas incorretamente. 37

38 Exemplo de Diagrama de Comunicação: Calcular o total da compra subtotal() { return quantidade*prodspec.preço() } tot:=total() :Venda 1*:[para cada]liv:=prox() :LinhadeItemdeVenda 2: st:=subtotal() liv:linhadeitem devenda total() { tot:=0 para cada linha de item de venda liv tot:= tot + liv.subtotal() } 2.1:pr:=preço prodespec: Especifi caçãodeproduto 38

39 GRASP: Padrões para Atribuição de Responsabilidades 39

40 Responsabilidade Responsabilidade um contrato ou obrigação de um tipo ou classe ( subsistema serviços fornecidos por um elemento (classe ou incorpora os objetivos de um elemento Dois tipos de responsabilidades básicas: Fazer (, operação fazer algo (criar um objeto, executar uma 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 40

41 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 ( associações conceitual (atributos e 41

42 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 42

43 Responsabilidade A tradução de responsabilidade em classes e métodos é influenciada pela granularidade da responsabilidade. Ex: Fornecer acesso a bancos de dados relacionais pode envolver muitas classes e métodos Imprimir uma venda pode envolver apenas um ou alguns poucos métodos Os métodos são implementados para satisfazer uma responsabilidade Um objeto pode colaborar com outros objetos para atender a uma responsabilidade 43

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

45 Padrões Desenvolvedores de software experientes criaram um repertório de princípios gerais e boas soluções para guiar a construção de softwares Essas soluções foram descritas em um formato padronizado (nome, problema, solução) e podem ser usadas em outros contextos Padrões usualmente não contêm novas ideias 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 45

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

47 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 47

48 Exemplo Venda conhece o total da venda ItemLinhaVenda conhece o subtotal da linha EspecificaçãoProduto conhece o preço do produto. 48

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

50 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 50

51 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 (classes leves ) favorece alta coesão Contra-indicações contra indicado quando aumenta acoplamento e reduz coesão Ex: quem é responsável por salvar uma Venda no banco de dados? 51

52 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 52

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

54 Criador Discussão objetivo do padrão: definir como criador o objeto que precise ser conectado ao objeto criado em algum evento 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 Ex: Venda e Pagamento 54

55 Exemplo ( fazerpagamento(quantia :Venda ( 1:criar(quantia Venda possui dados iniciais do pagamento :Pagamento 55

56 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 56

57 Acoplamento 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 57

58 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 reutilização 58

59 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? 59

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

61 Qual projeto é melhor? Qual dos projetos anteriores favorece o acoplamento fraco? em ambos os casos, Venda será acoplada a (terá conhecimento de) Pagamento projeto 1 acoplamento entre Pagamento e TPV projeto 2 não aumenta acoplamento PREFERÍVEL 61

62 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 62

63 Acoplamento Fraco Discussão: Acoplamento fraco classes mais independentes reduz impacto de mudanças favorece reúso 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 63

64 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 64

65 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 65

66 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? 66

67 Projeto 1: segundo padrão Criador, responsabilidade atribuída ao TPV ( fazerpagamento( :TPV ( criar( 1: p:pagamento ( adicionarpagamento(p : 2 :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?

68 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.

69 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 assume muitas responsabilidades não associadas podem tornar-se (e normalmente tornam-se) ineficientes 69

70 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 70

71 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> 71

72 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 72

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

74 Exemplo: Opções de Controlador todo o sistema (controlador fachada): TPV um tratador artificial do caso de uso: ControladorDeComprarItem entraritem( ) :TPV entraritem( ) :ControladorDe ComprarItem 74

75 Discussão: Controladores Fachada Um controlador fachada deve ser um objeto (do domínio) que sugira uma cobertura sobre outras camadas e 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: TPV pode ser um conceito que represente o sistema ex: sistematpv São adequados quando não há uma quantidade muito grande de eventos de sistema Não é possível redirecionar mensagens do sistema para controladores alternativos (ex: outros subsistemas ) 75

76 Discussão :Controladores de Casos de Uso Deve existir um controlador diferente 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 (controlador inchado por excesso de responsabilidade) É uma boa alternativa quando existem muitos eventos envolvendo diferentes processos. 76

77 Controladores inchados Classe controladora mal projetada - inchada 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. Comum com controladores fachada o próprio controlador executa as tarefas necessárias para atender o ( especialista evento, sem delegar para outras classes (coesão alta, não controlador tem muitos atributos e mantém informação significativa sobre o domínio, ou duplica informações existentes em outros lugares 77

78 Controlador Curas para controladores inchados acrescentar mais controladores misturar controladores fachada e de casos de uso delegar responsabilidades Corolário: objetos de interface (como objetos janela ) e da camada de apresentação não devem ter a responsabilidade de tratar eventos do sistema 78

79 Controlador 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 sequência correta de execução de operações 79

80 ID Item Quantidade :Caixa Entrar Item ( açãoexecutada(eventodaação Camada de Interface :CWindow ( quantidade entraritem(itemid, Camada do Domínio :TPV :Venda ( quantidade criaritemlinhavenda (itemid,

81 Exemplo: Acoplamento Apache syscall graph

82 Exemplo: Acoplamento IIS6 syscal graph