Construção de Diagramas de Colaboração

Apresentação em tema: "Construção de Diagramas de Colaboração"— Transcrição da apresentação:

1 Construção de Diagramas de Colaboração
© Nabor C. Mendonça 2001

2 Da Análise ao Projeto (Design)
Artefatos de análise capturam os resultados da investigação do domínio do problema Artefatos de design capturam uma solução para o problema baseada no paradigma OO Diagramas de colaboração Diagrama de classes de software Artefato Questões Respondidas Casos de uso Quais são os cenários usuário-sistema? Modelo conceitual Quais são os conceitos e seus relacionamentos? Diagramas de seqüência Quais são as operações do sistema? Contratos O que fazem as operações do sistema?

3 Diagramas de Colaboração
Um diagrama de colaboração ilustra as interações de mensagens entre objetos do modelo do domínio (diagrama de classe simplificado), para realizar uma operação de sistema (operação com contrato) Atribuição de responsabilidades aos objetos Ponto de partida é o cumprimento das pós- condições especificadas no contrato da operação Baseado na suposição de que as pré-condições da operação são satisfeitas

4 Diagramas de Colaboração
Diagrama de colaboração Ilustra interações num formato de grafo ou rede A mensagem não-numerada (a primeira) é uma operação de sistema Note que mandar uma mensagem m() para um objeto X corresponde a executar o código X.m(), isto é, invocar o método m() de X 1: message2() message1() 2: message3() :ClassAInstance :ClassBInstance

5 Diagramas de Colaboração
Os exemplos serão apoiados no modelo conceitual do sistema Terminal de Vendas (TV) Livro de Larman

6

7

8 Diagramas de Colaboração
Exemplo para a operação fazerPagamento, do sistema ProcessarVendas de um supermercado 1: makePayment (amount) 1.1: create(amount) :POST :Sale p:Payment makePayment(amount) parameter direction of message first message instance first internal message link line 1.2: associate(p)

9 Como Fazer um Diagrama de Colaboração
Regras úteis 1. Criar um diagrama em separado para cada uma das operações de sistema sendo desenvolvidas na iteração corrente - Para cada mensagem de operação de sistema, criar um diagrama com essa mensagem como mensagem inicial 2. Se um diagrama fica muito complexo (não cabe facilmente num folha de papel A4), o diagrama deve ser dividido em diagramas menores 3. Usar as pós-condições dos contratos de operação, e a descrição dos casos de uso para projetar um sistema cujo objetos interagem para cumprir as tarefas exigidas, segundo o modelo do domínio

10 Diagramas de Colaboração e Outros Artefatos
Modelo do Domínio Cashier System enterItem (upc, quantity) endSale() makePayment (amount) Collaboration Diagrams Sequence Diagram Operation: enterItem Postconditions: 1. If a new sale, a new Sale has been created... Operation: makePayment 1. ... Contracts :POST enterItem(upc, qty) makePayment(amount)

11 1: makePayment(amount)
Notação Básica Classes e instâncias Links 1: makePayment(amount) :POST :Sale msg1() link line

12 Notação Básica Mensagens Parâmetros 1: message1() 2: message2()
:POST :Sale msg1() all messages flow on the same link 1: makePayment(amount: Money) :POST :Sale msg1() parameters

13 Notação Básica Valor de retorno 1: tot := total(): Real :POST :Sale
msg1() return value type return value name

14 Notação Básica Mensagem para “self” ou “this” Iteração
1*: li := nextLineItem(): SalesLineItem :POST :Sale msg1() iteration recurrence values omitted

15 1*: [i := 1..10] li := nextLineItem(): SalesLineItem
Notação Básica Cláusula de iteração Iteração com múltiplas mensagens 1*: [i := 1..10] li := nextLineItem(): SalesLineItem :POST :Sale msg1() iteration clause 1*: [i := 1..10] msg2() :A myB :B msg1() note that iteration clauses are equal myC :C 2*: [i := 1..10] msg3() { for i := 1 to 10 myB.msg2() myC.msg3() }

16 Notação Básica Criação de instância 1: create(cashier) :POST :Sale
msg1() create message, with optional initializing parameters new created instance «new» "«new»" is optionally allowed for emphasis

17 Notação Básica Seqüenciamento de mensagens :ClassA msg1() :ClassB
:ClassC 1.1: msg3() not numbered legal numbering

18 Notação Básica Seqüenciamento complexo de mensagens ;ClassA msg1()
:ClassB 1: msg2() :ClassC 1.1: msg3() 2.1: msg5() 2: msg4() :ClassD 2.2: msg6() first second fourth sixth fifth third

19 Notação Básica Mensagens condicionais
1: [nova venda] create() :TV :Venda :LinhaDeVenda 1.1: create() entrarItem() conditional message, with test Exercício: modificar o diagrama para entrar com novas linhas de uma venda já criada

20 exclusive conditional paths
Notação Básica Caminhos condicionais mutuamente exclusivos 1a: [test1] msg2() :ClassA :ClassB :ClassC 1a.1: msg3() msg1() :ClassD 1b: [not test1] msg4() 1b.1: msg5() :ClassE 2: msg6() unconditional after either msg2 or msg4 1a and 1b are mutually exclusive conditional paths

21 Note que mensagens condicionais simulam IF ... THEN ... ELSE
Notação Básica Operação entrarItem() (diagrama parcial) 1: [nova venda] create() :TV :Venda :LinhaDeVenda 3: create() entrarItem() conditional message, with test 2: [velha venda] criarLinhaDeVenda() Note que mensagens condicionais simulam IF ... THEN ... ELSE

22 Notação Básica Coleções (multiobjects) Mensagens para uma coleção

23 Notação Básica Mensagens para uma coleção e um elemento 1: create()
:Sale sl: SalesLineItem SalesLineItem :SalesLineItem 2: addElement(sl) msg1() 2: print() 1: sl := get(key)

24 Responsabilidades e Métodos
Responsabilidade é “um contrato ou obrigação de um tipo ou classe” [Booch et al.’97] Relacionada com o comportamento dos objetos Dois tipos básicos: De conhecer (alguma coisa) Ex.: dados privados encapsulados, objetos relacionados, informação derivada ou calculada De fazer (alguma coisa) Ex.: Fazer algo individualmente, iniciar uma ação em outros objetos, controlar ou coordenar atividades em outros objetos

25 Responsabilidades e Métodos
Responsabilidade são atribuídas aos objetos do sistema durante o projeto OO Exemplos: “Uma Venda é responsável por imprimir a si própria” (de fazer) “Uma Venda é responsável por conhecer sua data” (de conhecer)

26 Responsabilidades e Métodos
Métodos são implementados para cumprir responsabilidades Podem agir sozinhos ou em colaboração com outros métodos e objetos Exemplo A classe Venda pode definir um método específico para cumprir a responsabilidade de impressão Esse método, por sua vez, pode precisar colaborar com outros objetos, possivelmente enviando mensagens de impressão para cada um dos objetos Item-de-Venda associados à Venda

27 Responsabilidades e Diagramas de Colaboração
Diagramas de colaração ilustram decisões na atribuição de responsabilidades a objetos Quais mensagens são enviadas para diferentes classes e objetos? Guias práticos para facilitar a tomada de decisões na atribuição de responsabilidades são oferecidos pelos padrões GRASP :Sale print() 2*: [i:=1..N] : print() sli:SalesLineItem implies Sale objects have a responsibility to print themselves SalesLineItem :SalesLineItem 1*: [i:= 1..N]] sli := next()

28 Padrões Nome e descrição de um problema comum de domínio e sua respectiva solução Expresso de modo que o padrão possas ser aplicado a novos contextos e circunstâncias variadas Capturam princípios fundamentais de engenharia de software Podem oferecer guias de como responsabilidades devem ser atribuídas a objetos, dada uma categoria específica de problema

29 Padrões Em geral, não contêm novas idéias nem soluções originais
Codificam soluções existentes comprovadas Possuem nomes sugestivos Suportam fácil incorporação ou abstração do conjunto de conceitos representado pelo padão Facilitam comunicação Permitem a discussão de um princípio ou conceito complexo através de um único nome

30 “General Responsibility Assignment Software Patterns”
Padrões GRASP “General Responsibility Assignment Software Patterns” Cinco padrões mais comuns Especialista (“Expert”) Criador (“Creator”) Alta coesão (“High Cohesion”) Baixo acoplamento (“Low Coupling”) Controlador (“Controler”) Os padrões GRASP são interessantes para os testes de qualidade de diagramas de colaboração

31 Padrão Especialista Problema Solução Exemplo
Qual é o princípio mais básico pelo qual responsabilidades são atribuídas no Projeto OO? Solução Atribuir responsabilidade para o especialista na informação — a classe que tem a informação necessária para cumprir a responsabilidade Exemplo Quem deve ser responsável por conhecer o total de uma venda? Informação necessária: conhecer todas as instâncias Item-de- Venda da Venda e o subtotal de cada uma delas

32 Padrão Especialista Exemplo (cont.)
Pelo padrão, a classe Venda deve ser a responsável Mas quem dever ser responsável por conhecer o subtotal de um Item-de-Venda? Informação necessária: Item-de-Venda.quantidade e Especificação-Produto.preço Venda data tempo total() :Venda t := total() Novo método

33 Padrão Especialista Exemplo (cont.)
Pelo padrão, a classe Item-de-Venda deve ser a responsável Porém, para cumprir essa responsabilidade um Item-de-Venda precisa conhecer o preço do Item Venda data tempo total() :Venda t := total() SalesLineItem sli:LinhaDeVenda LinhaDeVenda quantidade subtotal() 2*: [i:=1..N] st := subtotal() New method :LinhaDeVenda 1*: [i:=1..N]] sli := next()

34 Padrão Especialista Exemplo (cont.)
Portanto, o Item-de-Venda deve mandar uma mensagem para a Especificação-Produto para saber o preço do item Venda data tempo total() :Venda t := total() sli:inhaDeVenda LinhaDeVenda quantidade subtotal() 2*: [i:=1..N] st := subtotal() :Especificacao Produto 2.1: p := preco() Especificacao descricao preco UPC preco() New method SalesLineItem :LinhaDeVenda 1*: [i:=1..N]] sli := next()

35 Padrão Especialista Exemplo (cont.)
Concluindo, para cumprir a responsabilidade de conhecer e comunicar o total da venda, três responsabilidades foram atribuídas a três classes de objetos Classe Responsabilidade Venda conhece total da venda Item-de-Venda conhece subtotal do item Especificação-Produto conhecer preço do produto

36 Padrão Especialista Benefícios Também conhecido como
Mantém encapsulamento (baixo acoplamento) Comportamento é distribuído através das classes que tem a informação necessária para cumprir a responsabilidade (alta coesão) Também conhecido como “Quem sabe, faz” “Faço eu mesmo” “Cada serviço com seus atributos”

37 Padrão Criador Problema Solução
Quem deve ser responsável por criar uma nova instância de alguma classe? Solução Atribuir à classe B a responsabilidade de criar uma instância da classe A se: B agrega instâncias de A B contém instâncias de A B registra instâncias de A B usa bem de perto instâncias de A B tem os dados de inicialização para criar instâncias de A (B portanto é um especialista na criação de A)

38 criarLinhaDeVenda(quantidade)
Padrão Criador Exemplo Quem deve ser responsável por criar uma instância de Item-de-Venda? Pelo padrão, Venda deve ser responsável. Benefícios Suporta baixo acoplamento Venda data tempo criarLinhaDeVenda() total() :Venda criarLinhaDeVenda(quantidade) :LinhaDeVenda 1: create(quantidade) New method

39 Padrão Baixo Acoplamento
Problema Como conseguir menor dependência (entre as classes) e maior reuso? Solução Atribuir a responsabilidade de modo que o acoplamento (dependência entre classes) permaneça baixo Exemplo Quem deve ser responsável por criar um Pagamento e associá-lo à Venda? Pelo padrão Criador, poderia ser TV (uma vez que TV “registra” pagamentos no mundo real)

40 Padrão Baixo Acoplamento
Exemplo (cont.) Uma solução melhor, (que preserva baixo acoplamento) é a própria Venda criar o Pagamento :TV p : Pagto :Venda fazerPagto() 1: create() 2: addPagto(p) :TV :Venda :Pagto fazerPagto() 1: fazerPagto() 1.1. create()

41 Padrão Baixo Acoplamento
Benefícios Responsabilidade não é (ou é pouco) afetada por mudanças em outros componentes Responsabilidade é mais simples de entender isoladamente Maior chance para reuso

42 Padrão Alta Coesão Problema Solução Exemplo
Como manter a complexidade (das classes) em um nível “controlável”? Solução Atribuir a responsabilidade de modo que a coesão (força do relacionamento entre as responsabilidades de uma classe) permaneça alta Exemplo Quem deve ser responsável por criar um Pagamento e associá-lo à Venda? Pelo padrão Criador, seria TV. Mas se TV for o responsável pela maioria das operações do sistema, ele vai ficar cada vez mais sobrecarregado e não coeso

43 Padrão Alta Coesão Níveis de coesão Muito baixa Baixa Moderada Alta
Um classe tem muitas responsabilidades em áreas funcionais bastantes diferentes Baixa Um classe é responsável por uma tarefa complexa de uma única área funcional Moderada Um classe tem moderadas responsabilidades em uma única área funcional e colabora com outras classes para cumprir suas tarefas Alta Um classe tem responsabilidades leves apenas em algumas áreas que estão logicamente relacionadas com o conceito da classe

44 Padrão Alta Coesão Benefícios
Aumento da clareza e compreensão do projeto Simplificação de manutenção Baixo acoplamento Reuso facilitado

45 Padrão Controlador Problema Solução
Quem deve ser responsável por tratar um evento do sistema? Solução Atribuir a responsabilidade de tratar um evento do sistema para uma classe “controladora” representando: o sistema como um todo (facade controller) o negócio ou organização com um todo (facade controller) uma coisa ou papel de uma pessoa do mundo real envolvida diretamente com a tarefa (role controller) um “tratador” (handler) artificial para todos os eventos de um caso de uso (use-case controller)

46 Padrão Controlador Exemplo
Pelos padrões Baixo Acoplamento e Alta Coesão, a melhor escolha como controlador é POST TV ... terminarVenda() entrarItem() fazerPagto() Sistema system operations discovered during system behavior analysis allocation of system operations during design, using the Controller pattern