© nabor c. mendonça 2001 1 construção de diagramas de colaboração
TRANSCRIPT
© Nabor C. Mendonça 2001 1
Construção de Diagramas de Colaboração
© Nabor C. Mendonça 2001 2
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
Da Análise ao Projeto (Design)
Artefato
Casos de uso
Questões RespondidasQuais 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?
© Nabor C. Mendonça 2001 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
© Nabor C. Mendonça 2001 4
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
Diagramas de Colaboração
:ClassAInstance :ClassBInstance
1: message2()2: message3()message1()
© Nabor C. Mendonça 2001 5
Os exemplos serão apoiados no modelo conceitual do sistema Terminal de Vendas (TV)– Livro de Larman
Diagramas de Colaboração
© Nabor C. Mendonça 2001 6
© Nabor C. Mendonça 2001 7
© Nabor C. Mendonça 2001 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)
© Nabor C. Mendonça 2001 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
© Nabor C. Mendonça 2001 10
Diagramas de Colaboração e Outros Artefatos
Cashier System
enterItem(upc,
quantity)
endSale()
makePayment(amount)
CollaborationDiagrams
SystemSequenceDiagram
Operation: enterItem
Postconditions:1. If a new sale, a newSale has been created...
Operation: makePayment
Postconditions:1. ...
Contracts
:POST
:POST
enterItem(upc, qty)
makePayment(amount)
Modelo doDomínio
© Nabor C. Mendonça 2001 11
Classes e instâncias
Links
Notação Básica
Sale :Sale s1: Sale
class instance named instance
1: makePayment(amount):POST :Sale
msg1()
link line
© Nabor C. Mendonça 2001 12
Mensagens
Parâmetros
Notação Básica
1: message1()2: message2()3: message3()
:POST :Sale
msg1()
all messages flow on the same link
1: makePayment(amount: Money):POST :Sale
msg1()
parameters
© Nabor C. Mendonça 2001 13
Valor de retorno
Notação Básica
1: tot := total(): Real:POST :Sale
msg1()
return value type
return value name
© Nabor C. Mendonça 2001 14
Mensagem para “self” ou “this”
Iteração
Notação Básica
:POST
msg1()
1: clear()
1*: li := nextLineItem(): SalesLineItem:POST :Sale
msg1()
iteration
recurrence values omitted
© Nabor C. Mendonça 2001 15
Cláusula de iteração
Iteração com múltiplas mensagens
Notação Básica
1*: [i := 1..10] li := nextLineItem(): SalesLineItem:POST :Sale
msg1()
iteration clause
1*: [i := 1..10] msg2():A myB :B
msg1()
note that iterationclauses are equal
myC :C2*: [i := 1..10] msg3()
msg1(){
for i := 1 to 10 { myB.msg2() myC.msg3()
}}
© Nabor C. Mendonça 2001 16
Criação de instância
Notação Básica
1: create(cashier):POST :Sale
msg1()
create message, withoptional initializingparameters
new created instance
«new»:Sale
"«new»" is optionallyallowed for emphasis
© Nabor C. Mendonça 2001 17
Seqüenciamento de mensagens
Notação Básica
:ClassAmsg1()
:ClassB1: msg2()
:ClassC
1.1: msg3()
not numbered
legal numbering
© Nabor C. Mendonça 2001 18
Seqüenciamento complexo de mensagens
Notação Básica
;ClassAmsg1()
:ClassB1: msg2()
:ClassC
1.1: msg3()
2.1: msg5()
2: msg4()
:ClassD
2.2: msg6()
first second
fourth
sixth
fifth
third
© Nabor C. Mendonça 2001 19
Mensagens condicionais
Notação Básica
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
© Nabor C. Mendonça 2001 20
Caminhos condicionais mutuamente exclusivos
Notação Básica
1a: [test1] msg2()
:ClassA :ClassB
:ClassC
1a.1: msg3()
msg1()
:ClassD
1b: [not test1] msg4()
1b.1: msg5()
:ClassE
2: msg6()
unconditional aftereither msg2 or msg4 1a and 1b are mutually
exclusive conditional paths
© Nabor C. Mendonça 2001 21
Operação entrarItem() (diagrama parcial)
Notação Básica
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
© Nabor C. Mendonça 2001 22
Coleções (multiobjects)
Mensagens para uma coleção
Notação Básica
Salesales : Sale
multiobject
1: s := size() : int:Sale
SalesLineItem:SalesLineItem
msg1()
message sent to thecollection object itself
© Nabor C. Mendonça 2001 23
Mensagens para uma coleção e um elemento
Notação Básica
1: create():Sale sl: SalesLineItem
SalesLineItem:SalesLineItem
2: addElement(sl)
msg1()
2: print():Sale sl: SalesLineItem
SalesLineItem:SalesLineItem
1: sl := get(key)
msg1()
© Nabor C. Mendonça 2001 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
© Nabor C. Mendonça 2001 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)
© Nabor C. Mendonça 2001 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
© Nabor C. Mendonça 2001 27
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
Responsabilidades e Diagramas de Colaboração
:Saleprint() 2*: [i:=1..N] : print() sli:SalesLineItem
implies Sale objects have aresponsibility to printthemselves
SalesLineItem:SalesLineItem
1*: [i:= 1..N]] sli := next()
© Nabor C. Mendonça 2001 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
© Nabor C. Mendonça 2001 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
© Nabor C. Mendonça 2001 30
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
© Nabor C. Mendonça 2001 31
Padrão Especialista
Problema– 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
© Nabor C. Mendonça 2001 32
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
Padrão Especialista
Venda
datatempo
total()
:Vendat := total()
Novo método
© Nabor C. Mendonça 2001 33
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
Padrão Especialista
Venda
datatempo
total()
:Vendat := total()
SalesLineItemsli:LinhaDeVenda
LinhaDeVenda
quantidade
subtotal()
2*: [i:=1..N] st := subtotal()
New method
:LinhaDeVenda
1*: [i:=1..N]] sli := next()
© Nabor C. Mendonça 2001 34
Exemplo (cont.)– Portanto, o Item-de-Venda deve mandar uma
mensagem para a Especificação-Produto para saber o preço do item
Padrão Especialista
Venda
datatempo
total()
:Vendat := total()
sli:inhaDeVendaLinhaDeVenda
quantidade
subtotal()
2*: [i:=1..N] st := subtotal()
:EspecificacaoProduto
2.1: p := preco()
EspecificacaoProduto
descricaoprecoUPC
preco()New method
SalesLineItem:LinhaDeVenda
1*: [i:=1..N]] sli := next()
© Nabor C. Mendonça 2001 35
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
Padrão Especialista
Classe
Venda conhece total da venda
Responsabilidade
Item-de-Venda conhece subtotal do item
Especificação-Produto conhecer preço do produto
© Nabor C. Mendonça 2001 36
Benefícios – 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”
Padrão Especialista
© Nabor C. Mendonça 2001 37
Padrão Criador
Problema– 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)
© Nabor C. Mendonça 2001 38
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
datatempo
criarLinhaDeVenda()total()
:VendacriarLinhaDeVenda(quantidade)
:LinhaDeVenda
1: create(quantidade) New method
© Nabor C. Mendonça 2001 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)
© Nabor C. Mendonça 2001 40
Exemplo (cont.)
– Uma solução melhor, (que preserva baixo acoplamento) é a própria Venda criar o Pagamento
Padrão Baixo Acoplamento
:TV p : Pagto
:Venda
fazerPagto() 1: create()
2: addPagto(p)
:TV :Venda
:Pagto
fazerPagto() 1: fazerPagto()
1.1. create()
© Nabor C. Mendonça 2001 41
Benefícios– Responsabilidade não é (ou é pouco) afetada por
mudanças em outros componentes
– Responsabilidade é mais simples de entender isoladamente
– Maior chance para reuso
Padrão Baixo Acoplamento
© Nabor C. Mendonça 2001 42
Padrão Alta Coesão Problema
– 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
© Nabor C. Mendonça 2001 43
Padrão Alta Coesão
Níveis de coesão– Muito baixa
Um classe tem muitas responsabilidades em áreas funcionais bastantes diferentes
– BaixaUm classe é responsável por uma tarefa complexa de
uma única área funcional
– ModeradaUm classe tem moderadas responsabilidades em uma
única área funcional e colabora com outras classes para cumprir suas tarefas
– AltaUm classe tem responsabilidades leves apenas em
algumas áreas que estão logicamente relacionadas com o conceito da classe
© Nabor C. Mendonça 2001 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
© Nabor C. Mendonça 2001 45
Padrão Controlador
Problema– 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)
© Nabor C. Mendonça 2001 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
terminarVenda()entrarItem()
fazerPagto()
system operationsdiscovered during systembehavior analysis
allocation of systemoperations during design,using the Controller pattern