Modelagem de Interações - Slides - Principios de Analise e Projeto de Sistema Com UML - BEZERRA

Princpios de Anlise
e Projeto de Sistemas
com UML
2 edio
Eduardo Bezerra
Editora Campus/Elsevier
Captulo 7
Modelagem de Interaes
Somente aps a construo de diagramas de
interao para os cenrios de um caso de uso, podese ter certeza de que todas as responsabilidades que
os objetos devem cumprir foram identificadas
-Ivar Jacobson.
Tpicos
Introduo
Diagrama de seqncia
Diagrama de comunicao
Modularizao de interaes
Construo do modelo de interaes
Modelo de interaes em um processo iterativo
Princpios de Anlise e Projeto de Sistemas com UML - 2
Introduo
O objetivo dos modelos vistos at agora fornecer um
entendimento do problema correspondente ao SSOO a ser
desenvolvido.
Entretanto, esses modelos deixam algumas perguntas sem
respostas.
No modelo de casos de uso:
Quais so as operaes que devem ser executadas internamente ao
sistema?
A que classes estas operaes pertencem?
Quais objetos participam da realizao deste caso de uso?
Introduo
No modelo de classes de anlise:
De que forma os objetos colaboram para que um determinado caso de
uso seja realizado?
Em que ordem as mensagens so enviadas durante esta realizao?
Que informaes precisam ser enviadas em uma mensagem de um
objeto a outro?
Ser que h responsabilidades ou mesmo classes que ainda no foram
identificadas?
Sesses CRC pode ajudar a identificar quais so as

responsabilidades de cada objeto e com que outros objetos ele
precisa colaborar.
Mas sesses CRC no fornecem um modo de documentar essas
interaes.
Introduo
Para responder s questes anteriores, o modelo de interaes
deve ser criado.
Esse modelo representa mensagens trocadas entre objetos para a
execuo de cenrios dos casos de uso do sistema.
A construo dos diagramas de interao uma consolidao do
entendimento dos aspectos dinmicos do sistema, iniciado nas
sesses CRC.
A modelagem de interaes uma parte da modelagem dinmica
de um SSOO.
Diagramas de interao representam como o sistema age internamente
para que um ator atinja seu objetivo na realizao de um caso de uso. A
modelagem de um SSOO normalmente contm diversos diagramas de
interao. O conjunto de todos os diagramas de interao de um
sistema constitui o seu modelo de interaes.
Introduo
Os objetivos da construo do modelo de interao so:
1. Obter informaes adicionais para completar e aprimorar outros
modelos (principalmente o modelo de classes)
Quais as operaes de uma classe?
Quais os objetos participantes da realizao de um caso de uso (ou cenrio
deste)?
Para cada operao, qual a sua assinatura?
Uma classe precisa de mais atributos?
2. Fornecer aos programadores uma viso detalhada dos objetos e

mensagens envolvidos na realizao dos casos de uso.
Mensagem
O conceito bsico da interao entre objetos a mensagem.
Um sistema OO uma rede de objetos que trocam mensagens.
Funcionalidades so realizadas pelos objetos, que s podem interagir
atravs de mensagens.
Um objeto envia uma mensagem para outro objeto quando o primeiro
deseja que o segundo realize alguma tarefa.
O fato de um objeto precisar de ajuda indica a necessidade

de este enviar mensagens.
Na construo de diagramas de interao, mensagens de um
objeto a outro implicam em operaes que classes devem ter.
Uma mensagem representa a requisio de um objeto remetente a um
objeto receptor para que este ltimo execute alguma operao definida
para sua classe. Essa mensagem deve conter informao suficiente
para que
a operao
do objeto
receptor
possa com
ser executada.
Princpios
de Anlise
e Projeto
de Sistemas
UML - 2
8
Mensagens versus responsabilidades

Qual o objetivo da construo dos diagramas de interao?
Identificar mensagens e, em ltima anlise, responsabilidades
(operaes e atributos)
Uma mensagem implica na existncia de uma operao no

objeto receptor. A resposta do objeto receptor ao recebimento
de uma
mensagem
aeexecuo
operao
Princpios
de Anlise
Projeto de da
Sistemas
com correspondente.
UML - 2
Sintaxe da UML para mensagens

Na UML, o rtulo de uma mensagem deve seguir a seguinte
sintaxe:
[[expresso-seqncia] controle:] [v :=] nome
[(argumentos)]
Onde o termo controle pode ser uma condio ou um iterao:

* [ clusulaiterao ]
[ clusulacondio ]
O nico termo obrigatrio corresponde ao nome da mensagem.

10
Exemplos (sintaxe UML para mensagens)

Mensagem simples, sem clusula alguma.
1: adicionarItem(item)
Mensagem com clusula de condio.

3 [a > b]: trocar(a, b)
Mensagem com clusula de iterao e com limites indefinidos.

2 *: desenhar( )
Mensagem com clusula de iterao e com limites definidos.

2 *[i := 1..10]: figuras[i].desenhar( )
Mensagem aninhada com retorno armazenado na varivel x.

1.2.1: x := selecionar(e)
11
12
13
Notao para objetos

Objetos so representados em um diagrama de interao
utilizando-se a mesma notao do diagrama de objetos.
Pode-se representar objetos annimos ou objetos nomeados,
dependendo da situao.
Elementos de uma coleo tambm podem ser representados.
Classes tambm podem ser representadas.
Para o caso de mensagens enviadas para a classe.
Uma mensagem para uma classe dispara a execuo de
uma operao esttica.
A representao de uma classe em um diagrama de
seqncia a mesma utilizada para objetos, porm o
nome da classe no sublinhado
14
Multiobjetos
Um multiobjeto o nome que a UML d para uma coleo de
objetos de uma mesma classe. Pode ser utilizado para:
representar o lado muitos de uma associao de conectividade um para
muitos.
representar uma lista (temporria ou no) de objetos sendo formada em
uma colaborao.
Um multiobjeto representado na UML atravs de dois

retngulos superpostos.
A superposio dos retngulos evita a confuso com a notao usada
para objetos.
O nome do multiobjeto apresentado no retngulo que fica por cima e
segue a mesma nomenclatura utilizada para objetos.
Conveno: usar o nome da classe de seus elementos para nomear o
multiobjeto.
15
Notao para multiobjetos

Uma multiobjeto representado graficamente na UML atravs
de dois retngulos superpostos.
16
Mensagens para Objetos/Coleo

Uma mensagem pode ser enviada para um multiobjeto, ou pode
ser enviada para um nico objeto (elemento) do multiobjeto.
Quando o smbolo de iterao no usado, convenciona-se que
a mensagem est sendo enviada para o prprio multiobjeto.
Exemplo:
17
Implementao de multiobjetos
Multiobjetos so normalmente implementados
atravs de alguma estrutura de dados que
manipule uma colees.
Portanto, algumas mensagens tpicas que
podemos esperar que um multiobjeto aceite so
as seguintes:
Posicionar o cursor da coleo no primeiro elemento.

Retornar o i-simo objeto da coleo.
Retornar o prximo objeto da coleo.
Encontrar um objeto de acordo com um identificador nico.
Adicionar um objeto na coleo.
Remover um objeto na coleo.
Obter a quantidade de objetos na coleo.
Retornar um valor lgico que indica se h mais objetos a serem
considerados.
18
Implementao de multiobjetos (cont)

A interface List da linguagem Java apresenta
operaes tpicas de um multiobjeto.
public interface List<E> extends Collection<E> {
E get(int index);
E set(int index, E element);
boolean add(E element);
void add(int index, E element);
E remove(int index);
abstract boolean addAll(int index, Collection<? extends E> c);
int indexOf(Object o);
int lastIndexOf(Object o);
ListIterator<E> listIterator();
ListIterator<E> listIterator(int index);
List<E> subList(int from, int to);
}
19
Tipos de diagrama de interao

H trs tipos de diagrama de interao na UML 2.0: diagrama
de seqncia, diagrama de comunicao e diagrama de viso
geral da interao.
O diagrama de seqncia e o diagrama de comunicao so equivalentes.
Diagrama de seqncia: foco nas mensagens enviadas no decorrer do tempo.
Diagrama de comunicao: foco nas mensagens enviadas entre objetos que
esto relacionados.
Diagrama de viso geral de interao. Pode ser utilizado para apresentar uma
viso geral de diversas interaes entre objetos, cada uma delas representada por
um diagrama de interao. Diagrama til para modularizar a construo do
diagramas de seqncia (ou de comunicao).
20
7.2 Diagrama de seqncia
Diagrama de seqncia
Os objetos participantes da interao so organizados na
horizontal.
Abaixo de cada objeto existe uma linha (linha de vida)
Cada linha de vida possui o seu foco de controle.
Quando o objeto est fazendo algo.
As mensagens entre objetos so representadas com linhas

horizontais rotuladas partindo da linha de vida do objeto
remetente e chegando a linha de vida do objeto receptor.
A posio vertical das mensagens permite deduzir a ordem na
qual elas so enviadas.
Ordem de envio de mensagens em um diagrama de seqncia
pode ser deduzida a partir das expresses de seqncia.
Criao e destruio de objetos podem ser representadas.
22
Elementos grficos de um DS
Elementos bsicos em um diagrama de seqncia:
Atores
Objetos, multiobjetos e classes
Mensagens
Linhas de vida e focos de controle
Criao e destruio de objetos
Iteraes
23
Elementos grficos de um DS
24
Mensagens reflexivas em um DS
Em uma mensagem reflexiva (ou auto-mensagem) o remetente
tambm o receptor.
Corresponde a uma mensagem para this (self).
O que isso significa na prtica?
25
Criao/destruio de objetos em um DS
26
7.3 Diagrama de comunicao
Diagrama de comunicao
Chamado de diagrama de colaborao na UML 1.X.
Estruturalmente, bastante semelhante a um diagrama de objetos.
A diferena que so adicionados setas e rtulos de mensagens nas
ligaes entre esses objetos.
As ligaes (linhas) entre objetos correspondem a

relacionamentos existentes entre os objetos.
Deve haver consistncia com o diagrama de classes...
Os objetos esto distribudos em duas dimenses

Vantagem: normalmente permite construir desenhos mais legveis
comparativamente aos diagramas de seqncia.
Desvantagem: no h como saber a ordem de envio das mensagens a no
ser pelas expresses de seqncia.
Direo de envio de mensagem indicada por uma seta prxima

ao rtulo da mensagem.
28
Elementos grficos de um DC
Elementos bsicos em um diagrama de comunicao:
Atores
Objetos, multiobjetos e classes
Mensagens
Ligaes entre objetos
Criao e destruio de objetos
Iteraes
29
Elementos grficos de um DC
30
Criao de objetos em um DC
Durante a execuo de um cenrio de caso de uso, objetos
podem ser criados e outros objetos podem ser destrudos.
Alguns objetos podem sobreviver execuo do caso de uso
(se conectando a outro objetos); outros podem nascer e morrer
durante essa execuo.
A UML define etiquetas (tags) para criao e destruio de
objetos (ou de ligaes entre objetos) no diagrama de
comunicao.
{new}: objetos ou ligaes criados durante a interao.
{destroyed}: objetos ou ligaes destrudos durante a interao.
{transient}: objetos ou ligaes destrudos e criados durante a
interao.
31
Criao de objetos em um DC
32
7.4 Modularizao de interaes
Quadros de interao
Elemento grfico, que serve para modularizar a construo de
diagramas de seqncia (ou de comunicao).
Objetivos especficos:
Dar um nome ao diagrama que aparece dentro do quadro;
Fazer referncia a um diagrama definido separadamente;
Definir o fluxo de controle da interao.
Notao:
34
Diagramas nomeados
Dar um nome ao diagrama que aparece dentro do quadro
35
Diagramas referenciados
Fazer referncia a um diagrama definido separadamente.
36
Fluxo de controle: alternativas
37
Fluxo de controle: opes
38
Fluxo de controle: iteraes
39
7.5 Construo do modelo de interaes
Mensagens versus responsabilidades

O objetivo da modelagem de interaes identificar mensagens
e, em ltima anlise, responsabilidades.
Uma mensagem implica na existncia de uma operao no

objeto receptor. A resposta do objeto receptor ao recebimento
de uma
mensagem
aeexecuo
operao
Princpios
de Anlise
Projeto de da
Sistemas
com correspondente.
UML - 2
41
Alocao de responsabilidades
Podemos ento entender a modelagem de interaes como um
processo cujo objetivo final decompor as responsabilidades do
sistema e aloc-las a classes.
Dado um conjunto de N responsabilidades, uma possibilidade
criar uma nica classe no sistema para assumir com todas as N
responsabilidades.
Outra possibilidade criar N classes no sistema, a cada um
delas sendo atribuda uma das N responsabilidades.
Certamente, as duas alternativas anteriores so absurdas do
ponto de vista prtico. Mas, entre as muitas maneiras possveis
de alocar responsabilidades, como podemos saber quais delas
so melhores que outras?
42
Acoplamento e coeso
A resposta pergunta anterior no nenhuma receita de bolo.
De fato, para construirmos uma bom modelo de interaes,
devemos lanar mo de diversos princpios de projeto:
Dois dos principais princpios so o acoplamento e a coeso.
A coeso uma medida do quo fortemente
relacionadas e focalizadas so as responsabilidades
de uma classe.
extremamente importante assegurar que as
responsabilidades atribudas a cada classe sejam
altamente relacionadas.
Em outras palavras, o projetista deve definir classes de tal
forma que cada uma delas tenha alta coeso.
43
Acoplamento e coeso
O acoplamento uma medida de quo fortemente uma classe
est conectada a outras classes, tem conhecimento ou depende
das mesmas.
Uma classe com acoplamento fraco (baixo) no depende de
muitas outras.
Por outro lado, uma classe com acoplamento forte menos inteligvel
isoladamente e menos reutilizvel.
Alm disso, uma classe com alto acoplamento mais sensvel a

mudanas, quando necessrio modificar as classes da qual ela
depende.
Concluso: criar modelos com alta coeso e
baixo acoplamento deve ser um objetivo de
qualquer projetista.
44
Dicas para construo do MI

Identifique as classes conceituais que participam em cada
caso de uso.
Estas so as entidades do mundo real que estariam envolvidas na tarefa
do caso do uso se este fosse executada manualmente.
Exemplos so: Aluno, OfertaDisciplina, Venda, Pagamento, etc.
Note que classes de fronteira tambm podem ser classes conceituais.

Por exemplo, FormulrioInscrio um objeto de fronteira (para o caso de
uso Realizar Inscrio) que tambm corresponde a um conceito existente
no domnio do problema.
45
Dicas para construo do MI (cont)

Identifique quaisquer classes de software que ajudem a
organizar as tarefas a serem executadas.
classes daque no tm correspondente no mundo real
Essas classes normalmente so necessrias para manter a coeso das
demais classes em um nvel alto.
Segundo Craig Larman, essas classes so fabricaes puras (pure
fabrications).
Aqui, se encaixam algumas classes de fronteira, classes de controle.
Tambm: classes de acesso ao mecanismo de armazenamento, classes
de autenticao, etc.
46
Dicas para construo do MI

Defina tambm que objetos criam (destrem) outros objetos.
Na realizao de um caso de uso, objetos de entidade podem ser
criados pelo objeto de controle, que recebe os dados necessrios
instanciao a partir de objetos de fronteira.
Objetos de entidade tambm podem ser criados (destrudos) por outros
objetos de entidade.
De uma forma geral, em uma agregao (ou composio), o objeto
todo tem prioridade para criar (destruir) suas partes.
Portanto, em uma agregao (ou composio) entre objetos de
entidade, mais adequado que o objeto todo crie (destrua) suas partes
quando requisitado por outros objetos.
47

Verifique a consistncia dos diagramas de interao em
relao ao MCU e ao modelo de classes.
Verifique que cada cenrio relevante para cada caso de uso foi
considerado na modelagem de interaes.
Se assegure de que as mensagens que um objeto recebe esto
consistentes com as responsabilidades a ele atribudas.
Alguns dos objetos necessrios em uma interao j podem ter sido
identificados durante a construo do modelo de classes de anlise.
Durante a construo do diagrama de interao, o modelador pode
identificar novas classes.
Atributos, associaes e operaes tambm surgem como subproduto
da construo dos diagramas de interao.
48

Se certifique de que o objeto de controle realiza apenas a
coordenao da realizao do caso de uso.
Como o controlador tem a responsabilidade de coordenao, todas as
aes do ator resultam em alguma atividade realizada por esse objeto
de controle.
Isso pode levar ao alto acoplamento; no pior caso, o controlador tem
conhecimento de todas as classes participantes do caso de uso.
Responsabilidades especficas no domnio devem ser atribudas aos
objetos de domnio (entidades).
Sempre que for adequado, segundo os princpios de coeso e de
acoplamento, devemos fazer com que as classes de domnio enviem
mensagens entre si, aliviando o objeto de controle.
49

Faa o mximo para construir diagramas de interao o
mais inteligveis possvel.
Por exemplo, podemos utilizar notas explicativas para esclarecer
algumas partes do diagrama de interao que esteja construindo.
Essas notas podem conter pseudocdigo ou mesmo texto livre.
Outra estratgia que ajuda a construir um modelo de interaes mais

inteligvel utilizar os recursos de modularizao que a UML 2.0
acrescentou.
quadros de intereao, referncias entre diagramas, etc.
50

Utilize o princpio de projeto conhecido como Lei de
Demeter.
Esse princpio est associado ao princpio do acoplamento e impe
restries acerca de quais so os objetos para os quais devem ser
enviadas mensagens na implementao de uma operao:
(a) ao prprio objeto da classe (ou self);

(b) a um objeto recebido como parmetro do mtodo;
(c) a um atributo da classe;
(d) a um objeto criado dentro do mtodo;
(e) a um elemento de uma coleo que atributo da classe.
A inteno evitar acoplar excessivamente um objeto e tambm evitar

que ele tenha conhecimento das associaes entre outros objetos.
51
Na modelagem de interaes, quando definimos uma

mensagem, estamos criando uma dependncia entre
os objetos envolvidos.
Isso mesmo que dizermos que estamos aumentando
o acoplamento entre os objetos em questo.
Portanto, necessrio que o modelador fique atento
para apenas definir mensagens que so realmente
necessrias.
Sempre que possvel, devemos evitar o envio de mensagens
que implique na criao de associaes redundantes no
modelo de classes.
Isso porque a adio de uma associao entre duas classes
aumenta o acoplamento entre as mesmas.
52
Procedimento de construo
Vamos agora descrever um procedimento para
construo do modelo de interaes.
Note, primeiramente,
Esse procedimento genrico serve tanto para diagramas

de seqncia quanto para diagramas de comunicao,
resguardando-se as diferenas de notao entre os dois.
Durante a aplicao desse procedimento,
recomendvel considerar todas as dicas descritas
anteriormente.
Antes de descrevermos esse procedimento, necessrio
que definamos o conceito de evento de sistema
53
Eventos de sistema
Eventos de sistema correspondem s aes do ator no cenrio
de determinado caso de uso.
Sendo assim, relativamente fcil identificar eventos de
sistemas em uma descrio de caso de uso: devemos procurar
nessa descrio os eventos que correspondem a aes do ator.
No caso particular em que o ator um ser humano e existe
uma interface grfica para que o mesmo interaja com o
sistema, os eventos do sistema so resultantes de aes desse
ator sobre essa interface grfica, que corresponde a objetos
de fronteira.
54
Eventos de sistema (cont)

Considere o formulrio a seguir, para o caso de uso (do SCA)
denominado "Fornecer Grade de Disponibilidades:
55

No formulrio anterior, temos a seguinte lista de eventos de
sistema:
solicitao de validao de matrcula de professor;
solicitao de adio de uma disciplina grade;
solicitao de adio de um item de disponibilidade (dia, hora final e
hora final) grade;
solicitao de registro da grade.
Importante: nem todo evento de sistema

originado em um objeto de fronteira
correspondente a uma interface grfica.
essa ocorrncia pode ser gerada por um ator que no seja um ser
humano (e.g., outro sistema ou um equipamento).
56

Mas, por que os eventos de sistema so
importantes para a modelagem de interaes?
Porque as interaes entre objetos de um sistema
acontecem por conta do acontecimento daqueles.
Um evento de sistema alguma ao tomada por um
ator que resulta em uma sequencia de mensagens
trocadas entre os objetos do sistema.
Portanto, o ponto de partida para a modelagem de
interaes a identificao dos eventos do sistema.
Uma vez feita essa identificao, podemos desenhar
diagramas de interao que modelam como os objetos
colaboram entre si para produzir a resposta desejada a
cada evento do sistema.
57
Procedimento de construo
Para cada caso de uso, selecione um conjunto de cenrios relevantes.
O cenrio correspondente ao fluxo principal do caso de uso deve ser includo.

Considere tambm fluxos alternativos e de exceo que tenham potencial em
demandar responsabilidades de uma ou mais classes.
Para cada cenrio selecionado, identifique os eventos de sistema:
Posicione o(s) ator(es), objeto de fronteira e objeto de controle no diagrama.

Para cada passo do cenrio selecionado, defina as mensagens a serem
enviadas de um objeto a outro.
Defina as clusulas de condio e de iterao, se existirem, para as
mensagens.
Adicione multiobjetos e objetos de entidade medida que a sua participao
se faa necessria no cenrio selecionado.
58
Observaes sobre o procedimento
A definio das mensagens deve ser feita com base nas

responsabilidades de cada objeto envolvido:
A maioria dos objetos j devem ter sido identificados durante a

construo do modelo de classes.
Verificar as consistncias:
O nome da mensagem
Os argumentos de cada mensagem, se existirem.
O valor de retorno da operao correspondente, se existir.
Clusulas de condio e de repetio, se existirem.
Cada cenrio relevante para cada caso de uso foi considerado?

A mensagens que um objeto recebe esto consistentes com suas
responsabilidades?
As mensagens de um ator a um objeto de fronteira normalmente

so rotuladas com a informao fornecida
por exemplo, item de pedido, id e senha, etc.

59
Observaes sobre o procedimento
Mais de um controlador podem ser criados em um mesmo

caso de uso, dependendo de sua complexidade.
O controlador pode mesmo ser suprimido, tambm em funo da

complexidade do caso de uso.
Mensagens enviadas pelo objeto de fronteira por conta de um

evento de sistema resultam na necessidade de definir
operaes de sistema no objeto controlador do caso de uso.
Por exemplo, no do formulrio de fornecimento de disponibilidades, o

controlador deve possuir as seguintes operaes de sistema:
validarProfessor(matrcula);
adicionarDisciplina(nomeDisciplina);
adicionarItemDisponibilidade(dia, horaInicial, horaFinal).
registrarGrade()
60
7.6 Modelo de interaes em um

processo iterativo
MI em um processo iterativo
So utilizados na fase de construo de um ciclo de vida

incremental e iterativo.
So construdos para os casos de uso alocados para uma iterao desta

fase.
H controvrsias sobre o momento de incio da utilizao

desse modelo (se na anlise ou se no projeto).
Inicialmente (+anlise), pode exibir apenas os objetos
participantes e mensagens exibindo somente o nome da
operao (ou nome da responsabilidade).
Posteriormente (+projeto), pode ser refinado.
criao e destruio de objetos, tipo e assinatura completa de cada

mensagem, etc.
62
Embora modelos de um SSOO representem vises distintas,

eles so interdependentes e complementares.
O MCU fornece cenrios a serem considerados pelo MI.

O modelo de classes de anlise fornece objetos iniciais para o MI.
A construo do MI fornece informaes teis para transformar o
modelo de classes de anlise no modelo de classes de especificao.
Em particular, MI fornece os seguintes itens para refinar o modelo de
classes de anlise:
Detalhamento de operaes
Detalhamento de associaes
Operaes para classes
Novos atributos para classes
Novas classes
63
64
Discusso
Como informaes so passadas de um objeto a outro em um
sistema OO?
Quando utilizar diagramas de interaes (seqncia ou
comunicao)?
H alternativas para esse momento?
Qual a conseqncia da construo dos DIs sobre os demais

artefatos do sistema.
H possibilidade de gerao de cdigo a partir de um diagrama
de interaes?
65

Modelagem de Interações - Slides - Principios de Analise e Projeto de Sistema Com UML - BEZERRA

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Modelagem de Interações - Slides - Principios de Analise e Projeto de Sistema Com UML - BEZERRA

Enviado por

Direitos autorais:

Formatos disponíveis

Princpios de Anlise

Princpios de Anlise e Projeto de Sistemas com UML - 2

Princpios de Anlise e Projeto de Sistemas com UML - 2

Sesses CRC pode ajudar a identificar quais so as

2. Fornecer aos programadores uma viso detalhada dos objetos e

Princpios de Anlise e Projeto de Sistemas com UML - 2

O fato de um objeto precisar de ajuda indica a necessidade

Mensagens versus responsabilidades

Uma mensagem implica na existncia de uma operao no

Sintaxe da UML para mensagens

Onde o termo controle pode ser uma condio ou um iterao:

O nico termo obrigatrio corresponde ao nome da mensagem.

Exemplos (sintaxe UML para mensagens)

Mensagem com clusula de condio.

Mensagem com clusula de iterao e com limites indefinidos.

Mensagem com clusula de iterao e com limites definidos.

Mensagem aninhada com retorno armazenado na varivel x.

Princpios de Anlise e Projeto de Sistemas com UML - 2

Exemplos (sintaxe UML para mensagens)

Princpios de Anlise e Projeto de Sistemas com UML - 2

Exemplos (sintaxe UML para mensagens)

Princpios de Anlise e Projeto de Sistemas com UML - 2

Notao para objetos

Princpios de Anlise e Projeto de Sistemas com UML - 2

Um multiobjeto representado na UML atravs de dois

Notao para multiobjetos

Princpios de Anlise e Projeto de Sistemas com UML - 2

Mensagens para Objetos/Coleo

Princpios de Anlise e Projeto de Sistemas com UML - 2

Posicionar o cursor da coleo no primeiro elemento.

Implementao de multiobjetos (cont)

Princpios de Anlise e Projeto de Sistemas com UML - 2

Tipos de diagrama de interao

7.2 Diagrama de seqncia

As mensagens entre objetos so representadas com linhas

Princpios de Anlise e Projeto de Sistemas com UML - 2

Princpios de Anlise e Projeto de Sistemas com UML - 2

Princpios de Anlise e Projeto de Sistemas com UML - 2

Princpios de Anlise e Projeto de Sistemas com UML - 2

7.3 Diagrama de comunicao

As ligaes (linhas) entre objetos correspondem a

Os objetos esto distribudos em duas dimenses

Direo de envio de mensagem indicada por uma seta prxima

Princpios de Anlise e Projeto de Sistemas com UML - 2

Princpios de Anlise e Projeto de Sistemas com UML - 2

Princpios de Anlise e Projeto de Sistemas com UML - 2

Princpios de Anlise e Projeto de Sistemas com UML - 2

7.4 Modularizao de interaes

Princpios de Anlise e Projeto de Sistemas com UML - 2

Princpios de Anlise e Projeto de Sistemas com UML - 2

Princpios de Anlise e Projeto de Sistemas com UML - 2

Fluxo de controle: alternativas

Princpios de Anlise e Projeto de Sistemas com UML - 2

Fluxo de controle: opes

Princpios de Anlise e Projeto de Sistemas com UML - 2

Fluxo de controle: iteraes

Princpios de Anlise e Projeto de Sistemas com UML - 2

7.5 Construo do modelo de interaes

Mensagens versus responsabilidades

Uma mensagem implica na existncia de uma operao no

Alm disso, uma classe com alto acoplamento mais sensvel a

Dicas para construo do MI