Análise e Projetos de Sistemas E4_ANPS

Prévia do material em texto

E-book 4
ANÁLISE E PROJETO 
DE SISTEMAS
Gláucia Silva Bierwagen
Neste E-Book:
INTRODUÇÃO ���������������������������������������������� 3
RELACIONAMENTOS COM OS 
DIAGRAMAS DE CLASSES E OBJETOS �������4
Associação ���������������������������������������������������������������4
Multiplicidade �����������������������������������������������������������5
Interpretação em programas ����������������������������������7
Nomes de associação, direção de leitura de 
papéis �����������������������������������������������������������������������9
Classes associativas �������������������������������������������� 11
Associação reflexiva ou autoassociação ������������ 13
Associação bidirecional ��������������������������������������� 14
Agregações e composições ��������������������������������� 15
Generalizações e especializações ����������������������� 18
Dependências �������������������������������������������������������� 19
Regras de Restrição ���������������������������������������������� 21
DIAGRAMAS DE SEQUÊNCIAS E 
INTERAÇÕES ���������������������������������������������� 23
Ocorrências de execução ������������������������������������� 25
Criação e Destruição de Objetos ������������������������� 25
Mensagens síncronas e assíncronas ������������������ 28
CONSIDERAÇÕES FINAIS �����������������������31
SÍNTESE ������������������������������������������������������� 32
2
INTRODUÇÃO
Por meio da leitura deste módulo, você conhecerá 
os relacionamentos de diagramas de classe e obje-
tos� Estudaremos o relacionamento de associação 
que especifica objetos conectados uns aos outros; 
compreenderemos do que se trata a multiplicidade 
e o que são classes associativas�
Será identificado aqui que a associação reflexiva as-
socia objetos com papéis distintos da mesma classe, 
e que a associação bidirecional é representada por 
uma seta de duas pontas com um par de proprieda-
des inversamente vinculadas. Verificaremos que a 
generalização e a especialização são dois pontos de 
vista do mesmo relacionamento e que as dependên-
cias podem ser usadas para demonstrar relaciona-
mentos transitórios�
Em seguida, os diagramas de sequências oferecem 
uma visualização de como os objetos interagem, por 
exemplo: ocorrências de execução caracterizam o 
tempo em que o objeto está ativo, isto é, o tempo em 
que ele está realizando alguma operação�
E, por fim, analisaremos a criação de um objeto como 
o momento em que esse objeto passa a existir no 
sistema, e passa a realizar suas responsabilidades� 
Enquanto a destruição de um objeto é um momento 
no qual este objeto deixa de existir no sistema.
Desejo a você bons estudos!
3
RELACIONAMENTOS COM 
OS DIAGRAMAS DE CLASSES 
E OBJETOS
Você já estudou o que são diagramas de classes e 
objetos� Neste tópico você aprenderá os relaciona-
mentos que ocorrem entre as classes e os objetos� 
Dentre eles temos: a associação, multiplicidade, 
classes associativas, associações reflexivas, asso-
ciações bidirecionais, agregações e composições, e 
intepretação em programas. Verificará também como 
se dão nomes às associações, direção de leitura e 
papéis�
Associação
A associação demonstra um relacionamento es-
trutural que especifica objetos conectados uns aos 
outros� Geralmente, uma associação é representada 
no diagrama de classes por uma linha ligando as 
classes às quais pertencem os objetos relacionados� 
No exemplo da figura 1, temos as seguintes asso-
ciações: (1) na área de vendas, um cliente compra 
produtos; (2) na área bancária, uma conta corrente 
possui um histórico de transações; (3) em um ho-
tel, há vários hóspedes que ocupam vários quartos 
(BEZERRA, 2007).
4
Cliente Pedido
Hóspede Quarto
ContaCorrente HistóricoTrasações
Figura 1: Exemplo de associações entre objetos. Fonte: Bezerra (2007, 
p. 114) adaptado.
Multiplicidade
A multiplicidade se refere à quantidade de objetos 
que podem ser conectados pela instância de uma 
associação. Para Bezerra (2007), cada associação 
em um diagrama de classes possui duas multiplicida-
des, uma em cada extremo da linha que a representa. 
Existem símbolos possíveis para representar uma 
multiplicidade, conforme tabela abaixo.
Nome Simbologia
Apenas 1 1
Zero ou Muitos 0..*
Um ou Muitos 1..*
Zero ou Um 0..1
Intervalo Específico li��ls
Tabela 1: Simbologia para representar multiplicidade. Fonte: Bezerra 
(2007, p. 114)
5
SAIBA MAIS
O capítulo 9 (pp. 179-181) do livro “Utilizan-
do UML e padrões”, de Craig Larman, traz mais 
exemplos de uso de multiplicidade, além de des-
tacar, de forma mais detalhada, que o seu uso 
está relacionado ao contexto e à necessidade da 
equipe de desenvolvimento� O livro está disponí-
vel em sua biblioteca virtual (Minha Biblioteca).
Na figura 2 temos a associação de duas classes: 
Pedido e Cliente� A leitura dessa associação nos 
revelam três situações que podem ocorrer: (1) um 
objeto da classe Cliente que esteja associado a vá-
rios objetos da classe Pedido – isso é representado 
pela parte * do símbolo 0..*- ;(2) um objeto da classe 
Cliente que não esteja associado a pedido algum – 
isso é representado pela parte 0 do símbolo 0..*- e 
(3) um objeto da classe Pedido está associado a um, 
e somente um, objeto da classe Cliente�
Cliente
1 0..*
Pedido
Figura 2: Exemplo de utilização de símbolos de multiplicidade. Fonte: 
Bezerra (2007, p. 115) adaptado.
Com relação ao símbolo geral da multiplicidade 
dos intervalos específicos, as expressões li e ls são 
substituídas por valores correspondentes aos limites 
inferior e superior, respectivamente, do intervalo que 
6
se quer representar. No exemplo a seguir (figura 3), 
são representadas informações sobre velocistas e 
corridas em que é permitido o mínino de e o máximo 
de 6 velocistas participantes� Então, o valor para li 
é 2 (mínino dois velocistas) e para ls é 6 (máximo 6 
velocistas).
Velocista
2..6 0..*
Corrida
Figura 3: Exemplo de utilização de intervalo para valores de multipli-
cidade. Fonte: Bezerra (2007, p. 115) adaptado.
Interpretação em programas
Neste subtópico, você verificará alguns exemplos 
de uso da linguagem de programação Java� Essa 
linguagem é bastante usada porque não depende 
de um sistema operacional específico, tendo seus 
programas executados por meio da máquina virtual 
Java. Tem ferramentas de desenvolvimento, como: 
compiladores, depuradores, bibliotecas de desenvol-
vimento para desktop, dispositivos móveis, entre ou-
tros� Vamos observar o diagrama de classes a seguir� 
Leia-o atentamente. A partir dele, vamos verificar a 
representação de software mais comum, que é a de 
um campo ou de uma propriedade (FOWLER, 2005).
7
Pedido
datadeRecebumento:
Date[0..1]
éPré-pago: Boolean[1]
número: String [1]
preço: Money
expedir()
encerrar()
Cliente Corporativo
nomedeContato
classedeCrédito
limitedeCrédito
{sePedido.cliente.obterClassedeCrédito 
é “ruim”, então Pedido.éPré-pago deve 
ser “Verdadeiro”}
faturaMensal(Integer)
aviso()
Cliente Pessoal
NúmerodoCartãodeCrédito
{obterClassedeCrédito() == “ruim”}
0..1Linha de Pedido
Produto
quantidade: Integer
preço: Money
Cliente
nome [1]
endereço [0..1]
obterClassdeCrédito(): String
Funcionário
rep. de vendas
navegável
* {ordered}
operações
itensdeLinha
1
1
*
*
*
nome do 
papel
restrição
multiplicidade
atributos
associação
generalização classe
Figura 4: Diagrama de classes simples. Fonte: Fowler (2005, p. 52) 
adaptado.
Dessa forma, a classe Linha de Pedido (figura 5) mos-
tra os possíveis códigos em Java correspondentes, 
onde é definida a classe que está relacionando quan-
tidade, preço, pedido e produto�
8
public class LinhadePedido...
private int quantidade;
private Dinheiro preço;
private Pedido pedido;
private Produto produto;
Figura 5: Código em Java para a classe Linha de Pedido. Fonte: 
Fowler (2005, p. 55) adaptado.
Neste caso, temos como atributo de proprieda-
des públicas utilizando o nome da classe destino 
LinhadePedido associdadas aos campos privados 
com relação a: quantidade,preço, pedido e produto.
Acesse o Podcast 1 em Módulos 
Nomes de associação, direção 
de leitura de papéis
A UML define três recursos de notação para escla-
recer o significado de uma associação no diagrama 
de classes: nome de associação, direção de leitura 
e papel�
A figura 6 apresenta uma associação na qual são 
representados os papéis específicos ou roles – 
Contratante e Contratado – e o seu nome Contrata, 
com significado semântico à mesma, posicionada 
na linha de associação entre as classes envolvidas� 
9
Você observará a notação da direção de leitura, ou 
seja, como a associação deve ser lida� Ela é represen-
tada por um pequeno triângulo posicionado próximo 
a um dos lados do nome da associação e, nesse 
caso, trata-se de: organização contrata indivíduo, e 
não o contrário (BEZERRA, 2007).
Organização
contratante
Papel
Papel
Nome da
associação
Direção de 
leitura
Contrata contratado
* *
Indivíduo
Figura 6: Exemplo de utilização de nome de associação, direção de 
leitura e de papéis. Fonte: Bezerra (2007, p.117) adaptado.
Pode haver diversos motivos pelos quais um objeto 
precisa saber sobre outro� Dessa forma, pode ha-
ver várias associações definidas entre duas clas-
ses no diagrama de classes. Por exemplo, pense 
em duas classes: Empregado e Departamento� Na 
classe Departamento é necessário saber quais são 
seus empregados e quem é o seu gerente� Nesse 
caso, temos duas associações diferentes, embora 
as classes envolvidas sejam as mesmas�
10
Classes associativas
As classes associativas são classes que estão li-
gadas a associações, em vez de estarem ligadas a 
outras classes� Ocorre quando duas ou mais classes 
estão associadas� Geralmente, classes associativas 
são ligadas a associações de conectividade muitos 
para muitos, mas pode acontecer associações de 
qualquer conectividade�
Na UML, uma classe associativa é representada pela 
mesma notação utilizada para uma classe comum� 
A diferença é que essa classe é ligada por uma linha 
tracejada a uma associação� Vamos ilustrar a utili-
zação de uma classe associativa em um diagrama 
de classes (figura 7), por meio de um diagrama que 
indica que uma pessoa pode trabalhar como empre-
gado em várias empresas� Uma empresa, por sua vez, 
pode ter vários empregados� A classe associativa 
Emprego – representada pela mesma notação de 
uma classe comum ligada por uma linha tracejada 
– possibilita saber, para cada par de objetos [empre-
gado, empregador], qual o salário e a data de contra-
tação do empregado em relação àquele empregador� 
(BEZERRA, 2007).
11
Pessoa *
nome
telefone
endereço
Emprego
salário
dataContratação
empregado empregador
Empresa
razãoSocial
endereço
*
Figura 7: Exemplo de classe associativa. Fonte: Bezerra (2007, p. 
119) adaptado.
SAIBA MAIS
As páginas 87 e 88 do livro “UML Essencial: um 
breve guia para linguagem padrão”, de Martin Fo-
wler, trazem bons exemplos de classes associati-
vas� Um deles demonstra o diagrama que indica 
que uma pessoa pode participar de muitas reuni-
ões� Ele pretende mostrar a informação sobre o 
quanto essa pessoa estaria desperta por adicio-
nar o atenciosidade à associação� Estude como 
isso foi realizado� O livro está disponível em sua 
biblioteca virtual (Minha Biblioteca).
Por meio do exemplo anterior, você pôde verificar 
que uma classe associativa é um elemento híbrido, 
isto é, tem características de uma classe e também 
características de uma associação�
Um diagrama de classes que contém uma classe as-
sociativa pode ser modificado retirando-a. Como isso 
pode ser feito? No exemplo da figura 8, eliminou-se 
12
a associação correspondente à classe associativa 
e esta, por sua vez, foi então substituída por uma 
classe ordinária Emprego, que tem participação obri-
gatória em ambas as associações (BEZERRA, 2007).
Pessoa
nome
endereço
telefone
Empresa
razãoSocial
endereço
Emprego
salário
dataContratação
1 * * 1
Figura 8: Classe associativa sendo substituída por uma classe ordi-
nária. Fonte: Bezerra (2007, p. 120) adaptado.
Associação reflexiva ou 
autoassociação
A associação reflexiva associa objetos com papéis 
distintos da mesma classe. Por exemplo, visualize 
a figura 9, em que existe uma associação reflexiva 
entre objetos de Empregado que ora assumem o 
papel de supervisor ora o papel de supervisionado� 
(BEZERRA, 2007).
13
supervisionado
supervisor
1
*
Emprego
Figura 9: Exemplo de associação reflexiva. Fonte: Bezerra (2007, p. 
122) adaptado.
É importante destacar que a associação reflexiva não 
indica que um objeto se associa a ele próprio, ou seja, 
um empregado não pode ser supervisor dele próprio� 
Reforçamos que a autoassociação representa que 
um objeto de uma classe se associa a outros objetos 
da mesma classe (BEZERRA, 2007).
Associação bidirecional
A associação bidirecional representada por uma seta 
de duas pontas é um par de propriedades inversa-
mente vinculadas. No exemplo da figura 10, a classe 
Carro tem a propriedade proprietário: Pessoa[1] e a 
classe Pessoa tem uma propriedade carros: Carro[*]. 
O vínculo inverso entre elas significa que, se você 
seguir as duas propriedades, deverá retornar a um 
conjunto que contém seu ponto de partida�
14
CarroPessoa
proprietário
*0..1
Figura 10: Exemplo de associação bidirecional. Fonte: Fowler (2005, 
p. 57) adaptado.
Agregações e composições
 Bezerra (2007) traz algumas características especí-
ficas das agregações e composições que as diferem 
das associações simples�
• Agregações/composições são assimétricas, 
no sentido de que, se um objeto A é parte de 
um objeto B, o objeto B não pode ser parte 
do objeto A.
• Agregações/composições propagam com-
portamento, no sentido de que um comporta-
mento que se aplica a um todo automatica-
mente se aplica às suas partes.
• Nas agregações a UML define dois tipos 
de relacionamentos todo-parte, a agregação 
e a composição, sendo casos especiais de 
associações/composições, as partes são 
normalmente criadas e destruídas pelo todo. 
Na classe do objeto todo, são definidas ope-
15
rações para adicionar e remover as partes 
(BEZERRA, 2007, p. 123).
Como aplicar uma agregação ou composição? 
Bezerra (2007) sugere a aplicação de uma regra que 
pode verificar se faz sentido a utilização de um rela-
cionamento todo-parte – agregação ou composição� 
Pode-se verificar da seguinte forma:
Sejam duas classes associadas, X e Y. Se uma 
das duas perguntas a seguir for respondida 
com um sim, provavelmente há um relaciona-
mento todo-parte envolvendo X e Y, no qual X 
é o todo, e Y é a parte. 1) X tem um ou mais 
Y? 2) Y é parte de X? (BEZERRA, 2007, p. 123)
Observe o exemplo de agregação (Figura 11) – re-
presentada por uma linha que conecta as classes 
relacionadas, tendo um losango sem preenchimento 
perto da classe que indica o todo – por meio de um 
diagrama que demonstra uma associação esportiva 
formada por diversas equipes, que, por sua vez, são 
formadas por diversos jogadores� Por outro lado, um 
jogador pode fazer parte de diversas equipes�
AssociaçãoEsportiva Equipe
Afiliada
*
membro
Jogador
* * *
Figura 11: Exemplo de agregação. Fonte: Bezerra (2007, p. 124) adap-
tado.
16
A composição é representada na UML por meio de 
um losango com preenchimento em contraponto do 
losango branco da agregação�
*
Pedido
data
hora
ItemPedido
quantidade
Produto
nome
descrição
preçoUnitário
desconto
1
1
1..*
Figura 12: Exemplo de composição. Fonte: Bezerra (2007, p. 124) 
adaptado.
SAIBA MAIS
Craig Larman, no livro “Utilizando UML e pa-
drões” (2004, p. 528), sugere que se deve con-
siderar o uso da composição quando: 1) o tem-
po de vida da parte estiver vinculado ao tempo 
de vida do composto – existe uma dependência 
criação-destruição da parte em relação ao todo; 
2) existir uma relação física todo-parte óbvia ou 
um agrupamento lógico; 3) algumas proprieda-
des do composto se propagam para as partes, 
como sua localização� O livro está disponível em 
sua biblioteca virtual (Minha Biblioteca).17
Generalizações e 
especializações
Os relacionamentos entre classes demonstram rela-
ções de generalidade ou especificidade entre as clas-
ses envolvidas� A generalização e a especialização 
são dois pontos de vista do mesmo relacionamento: 
dadas duas classes A e B, se A é uma generalização 
de B, então B é uma especialização de A.
Nos diagramas de classes (figura 13), a herança é 
representada na UML por uma flecha partindo da sub-
classe (classe herdeira, classe que herda as proprie-
dades de outra classe através de uma generalização) 
em direção à superclasse (classe base, a classe que 
possui propriedades herdadas por outras classes). 
Percebe-se que a subclasse é uma especialização 
de sua superclasse (a subclasse especializa a super-
classe), e que uma superclasse é uma generalização 
de suas subclasses (a superclasse generaliza as 
subclasses). (BEZERRA, 2007)
Subclasse1 Subclasse2
Superclasse
... SubclasseN Subclasse1 Subclasse2
Superclasse
... SubclasseN
Figura 13: Representações alternativas para o relacionamento de 
generalização na UML. Fonte: Bezerra (2007, p. 129) adaptado.
É importante lembrar que uma classe representa 
um conjunto de objetos que partilham um conjunto 
18
comum de propriedades (atributos, operações, as-
sociações). Mas, alguns objetos, embora bastante 
semelhantes a outros, podem ter um conjunto de 
propriedades que outros não possuem. Por exem-
plo, em um diagrama de uma empresa, podemos 
ter uma classe chamada Funcionários que pode ter 
os mesmos atributos como nome, endereço, sa-
lário base; mas, no caso de funcionários específi-
cos, como vendedores, temos os atributos como 
região onde trabalham e comissão� Nesse caso, 
os vendedores pertecem a classe Funcionários e a 
classe Vendedores que herda as propriedades dos 
Funcionários (BEZERRA, 2007).
Dependências
Nas classes, as dependências podem existir por vá-
rias razões: uma classe envia uma mensagem para 
outra; uma classe tem outra como parte de seus 
dados; uma classe menciona uma outra como um 
parâmetro de uma operação�
A figura 15 exemplifica algumas dependências. A 
classe Janela de Benefícios é dependente da classe 
Funcionários.
REFLITA
Vamos refletir! Em um sistema de uma univer-
sidade de Controle de Alunos, você conseguiria 
criar alguma classe com dependência? Que pala-
19
vras-chave poderia usar? Seria possível criar uma 
classe Aluno e uma classe dependente chamada 
Notas?
Janela de 
Benfícios
cliente fornecedor
dependência
Funcionário
Entrada de Dados 
de Funcionários
Entrada de Dados 
de Benefícios
Figura 14: Exemplo de dependência. Fonte: Fowler (2005, p. 6) adap-
tado.
Em UML há muitas variedades de dependência, cada 
uma com semântica e palavras-chave (tabela 1) es-
pecíficas. As dependências podem ser usadas para 
demonstrar relacionamentos transitórios, no caso de 
um objeto passado para outro parâmetro�
Palavra-chave Significado
<<call>> A origem chama uma operação no destino�
<<create>> A origem cria instâncias do destino�
<<derive>> A origem é derivada do destino�
<<instantiate>> A origem é uma instância do destino. (Note 
que, se a origem é uma classe, a própria classe 
é uma instância de classe da classe; isto é, a 
classe de destino é uma metaclasse.)
<<permit>> O destino permite que a origem acesse seus 
recursos privados�
20
Palavra-chave Significado
<<realize>> A origem é uma implementação de uma especifi-
cação ou interface definida pelo destino (página 
80).
<<refine>> O refinamento indica um relacionamento entre 
diferentes níveis semânticos; por exemplo, a 
origem poderia ser uma classe de projeto e o 
destino, a classe de análise correspondente�
<<substitute>> A origem é substituível pelo destino (página 61).
<<trace>> Usada para controlar coisas como requisitos de 
classes ou como alterações em um modelo se 
vinculam a alterações em outro lugar�
<<use>> A origem exige o destino para sua 
implementação�
Tabela 2: Palavras-chave e significados. Fonte: Fowler (2005, p. 63) 
adaptado.
Regras de Restrição
Fowler (2005) destaca que a UML permite que se use 
várias linguagens para descrever restrições� Pode ser 
a linguagem natrual ou a linguagem formal de restri-
ções de objeto� As restrições devem ser colocadas 
entre chaves ({}). O uso de notação formal pode evitar 
o risco de uma interpretação errônea, devido ao uso 
de uma linguagem natural que pode ser ambígua�
21
Pilha
tamanho : Inteiro {tamanho >=0}
inserir( elemento )
retirar() : Objeto
{ pós-condição: novo tamanho = 
tamanho anterior + 1 }
{ 
pós-condição: novo tamanho = 
tamanho anterior - 1
 }
Figura 15: Exemplo de Restrições. Fonte: Larman, (2004, p. 282)
SAIBA MAIS
Sobre os símbolos de anotações que podem ser 
usados em UML, como notas, comentários, res-
trições e corpo de métodos, leia as páginas 273 a 
276, do livro “Utilizando UML e padrões”, de Craig 
Larman� O livro está disponível em sua biblioteca 
virtual (Minha Biblioteca).
22
DIAGRAMAS DE 
SEQUÊNCIAS E 
INTERAÇÕES
Os diagramas de sequências oferecem uma visua-
lização de como os objetos interagem� Podem ser 
representados por quadros (figura 16). Cada quadro 
fornece um contexto posicionando elementos como 
linhas de vidas e mensagens; tendo um operador e 
cada fragmento pode ter uma sentinela� As sentine-
las são expressões condicionais colocadas entre 
colchetes e indicam que uma mensagem é enviada 
somente se a sentinela for verdadeira�
:Pedido cuidadoso:Distribuidor
regular:
Distribuidor :Mensageiro
loop
alt
operador
confirmar
quadro
opt
[para cada item de linha]
[valor > $10.000]
[precisaConfirmação]
despachar
despachar
despachar
[else]
sentinela
Figura 16: Exemplo de Diagrama de sequências e laços condicionais. 
Fonte: Fowler (2005, p. 71) adaptado.
23
Em UML existem vários operadores (figura 16). Para 
mostrar um laço, utiliza-se o operador loop – geral-
mente, possui um número de limite – com um único 
fragmento e coloca a base da interação na sentinela� 
Para lógica condicional, é possível usar o operador alt 
(se-então-senão) e colocar uma condição em cada 
fragmento� Somente o fragmento cuja sentinela é 
verdadeira será executado. No caso de ter um única 
opção, pode-se usar um operador opt (se)�
Operador Significado
alt Múltiplos fragmentos alternativos; somente aque-
le cuja condição for verdadeira será executado.
opt Opcional; fragmento é executado somente se a 
condição fornecida for verdadeira� Equivalente a 
um alt, com apenas um caminho�
par Paralelo; cada fragmento é executado em 
paralelo�
loop Laço; o fragmento pode ser executado várias 
vezes e a sentinela indica a base da interação�
region Região crítica; o fragmento pode ter apenas uma 
linha de execução ativa por vez.
neg Negativo; o fragmento mostra uma interação 
inválida�
ref Referência; refere-se a uma interação definida 
em outro diagrama� O quadro é desenhado de 
forma a abordar as linhas de vida envolvidas na 
interação. Você pode definir parâmetros e um 
valor de retorno�
sd Diagrama de sequência; usada para circundar um 
diagrama de sequência inteiro; se você quiser.
Tabela 3: Operadores comuns para quadro de iteração. Fonte: Fowler 
(2005, p. 72) adaptado.
24
Acesse o Podcast 2 em Módulos 
Ocorrências de execução
As ocorrências de execução caracterizam o tempo 
em que o objeto está ativo, isto é, o tempo em que 
ele está realizando alguma operação� Temos como 
notações gráficas de ocorrências de execução blocos 
retangulares que são posicionados sobre a linha de 
vida de um objeto� No topo de uma ocorrência de 
execução, encontramos o receptor com o recebi-
mento de uma mensagem� Na parte inferior dessa 
ocorrência de execução, temos o término de uma 
operação realizada pelo objeto�
Muitas vezes, as ocorrências de execução não são 
utilizadas em diagramas de sequências� Quando uti-
lizadas, tornam desnecessário o uso de mensagens 
de retorno. Por que isso acontece? Porque o final de 
uma ocorrência de execução corresponde ao retorno 
do fluxo de controle para o emissorda mensagem, 
no caso de mensagens síncronas (BEZERRA, 2007).
Criação e Destruição de Objetos
A criação de um objeto é o momento em que esse 
objeto passa a existir no sistema, e passa a realizar 
suas responsabilidades� Enquanto que a destruição 
25
de um objeto é o momento no qual esse objeto deixa 
de existir no sistema.
No caso de o objeto existir desde o início, deve ser 
posicionado no topo do diagrama. No entanto, existe 
a possibilidade de que a própria interação crie um 
ou mais objetos de certa classe� Então, a posição 
vertical de um objeto em um diagrama de sequência 
indica o momento no qual ele é criado (instanciado) 
e começa a participar da interação� Nesse momento, 
o retângulo que representa o objeto deverá ser po-
sicionado mais abaixo no diagrama. A instanciação 
de um objeto é sempre requisitada por outro objeto 
participante da interação através de uma mensagem 
que pode ser elaborada de duas maneiras:
1. com o estereótipo <<create>> ou
2. com o nome do método construtor que será ati-
vado (BEZERRA, 2007).
Observe que a flecha da mensagem é pontilhada 
e aponta para o objeto em vez de para a linha de 
vida� Perceba que a mensagem de criação utiliza o 
estereótipo <<create>> e está em forma de seta que 
termina na cabeça da linha de vida do objeto sendo 
criado (figura 17).
26
ObjetoCriador
ObjetoCriado<<create>>
Figura 17: Criação de um objeto no diagrama de sequência. Fonte: 
Bezerra (2007, p. 197) adaptado.
FIQUE ATENTO
Estereótipos tratam-se de mecanismos de uso 
geral da UML, que são utilizados para estender o 
significado de determinado elemento de um dia-
grama. A equipe de desenvolvimento pode definir 
estereótipos quanto à forma; estereótipos gráfi-
cos (ou ícones) e estereótipos textuais.
Os diagramas de sequência podem mostrar também 
a destruição de objetos no decorrer de uma intera-
ção� Quando o objeto não é mais necessário na inte-
ração, geralmente é destruído� O símbolo X na parte 
de baixo da linha de vida de um objeto representa que 
ele está sendo destruído� Além disso, a mensagem 
de destruição é chamada com o estereótipo <<des-
troy>>. A figura 18 mostra um exemplo da notação 
para destruição de objetos�
27
ObjetoDestruidor
<<destroy>>
ObjetoDestruído
Figura 18: Destruição de um objeto em um diagrama de sequência. 
Fonte: Bezerra (2007, p. 97) adaptado.
Mensagens síncronas e 
assíncronas
Em UML o conceito de mensagens está relaciona-
do ao tipo de comunicação gerado para realizar as 
mensagens. Sendo assim, temos os seguintes tipos:
1. Uma mensagem síncrona indica que o ob-
jeto remetente espera que o objeto receptor 
processe a mensagem antes de recomeçar 
o seu processamento. Ou seja, o remetente 
fica bloqueado até que o receptor termine de 
atender à requisição. Uma mensagem síncro-
na está tipicamente relacionada à chamada 
de uma operação definida na classe do objeto 
receptor da mensagem.
28
2. Uma mensagem assíncrona é aquela na 
qual o objeto remetente não espera a resposta 
para prosseguir com o seu processamento.
3. Uma mensagem de sinal é aquela usada 
para enviar um sinal. Um sinal pode repre-
sentar o envio de uma requisição entre dois 
módulos (por exemplo, cliente e servidor) em 
um sistema distribuído.
4. Uma mensagem de retomo é aquela utiliza-
da para especificar o retorno (término) de uma 
mensagem enviada anteriormente. (BEZERRA, 
2007, p. 186)
E como são as notações de mensagens em um dia-
grama de sequência? Geralmente são flechas dese-
nhadas na horizontal, conectando uma linha de vida a 
outra� O objeto do qual parte a seta é aquele que está 
enviando a mensagem, ou seja, o objeto remetente� 
O objeto para o qual a seta está apontando é aquele 
que está recebendo a mensagem, ou seja, o objeto 
receptor� Você poderá perceber que o formato da 
ponta da seta indica o tipo de mensagem que está 
sendo enviada: síncrona, assíncrona, retorno e cria-
ção de objeto� Dessa forma, temos alguns formatos 
possíveis em um diagrama de sequência (figura 19). 
O rótulo da mensagem é posicionado acima dessa 
linha� É possível notar a passagem do tempo no dia-
29
grama de sequência observando-se a direção vertical 
no sentido de cima para baixo. Sendo que, quanto 
mais abaixo uma mensagem aparece no diagrama, 
mais tarde no tempo a mensagem foi enviada�
Mensagem síncrona
Mensagem assíncrona
Mensagem de retorno
Mensagem de criação de objeto<<create>>
Figura 19: Notações para os diversos tipos de mensagens em diagra-
mas de sequência. Fonte: Bezerra (2007, p. 195) adaptado.
30
CONSIDERAÇÕES FINAIS
Neste último módulo, abordamos os relacionamen-
tos de diagramas de classe e objetos� Estudamos 
o relacionamento de associação que especifica ob-
jetos conectados uns aos outros e verificamos que 
a multiplicidade refere-se à quantidade de objetos 
que podem ser conectados pela instância de uma 
associação, enquanto que as classes associativas 
são classes que estão ligadas a associações, em 
vez de estarem ligadas a outras classes�
Em seguida, verificamos que a associação reflexi-
va associa objetos com papéis distintos da mes-
ma classe� Tratamos da generalização e da espe-
cialização como dois pontos de vista do mesmo 
relacionamento�
Percebemos que os diagramas de sequências ofe-
recem visualização de como os objetos interagem� 
Estudamos a criação de um objeto como um momen-
to em que ele passa a existir no sistema, e passa a 
realizar suas responsabilidades� E que a destruição 
de um objeto é um momento no qual esse objeto 
deixa de existir no sistema.
Finalmente, verificamos o comportamento de men-
sagens síncronas e assíncronas� Espero que tenha 
aprendido bastante com a leitura deste conteúdo�
31
SÍNTESE
MECANISMOS DE UML
1) Associação demonstra um relacionamento estrutural que especifica objetos 
conectados uns aos outros. 
3) Classes associativas são aquelas que estão ligadas as associações, em vez de 
estarem ligadas a outras classes. 
4) Associação Reflexiva ou autoassociação associa objetos com papéis 
distintos da mesma classe. 
2) Multiplicidade se refere à quantidade de objetos que podem ser conectados pela 
instância de uma associação. 
ANÁLISE E PROJETO 
DE SISTEMAS
5) Associação bidirecional é representada por uma seta de duas pontas, é um par 
de propriedades inversamente vinculadas. 
6) Agregações e composições podem ser assimétricas, propagam 
comportamentos, a utilização de um todo-parte. 
7) Generalizações e especializações são dois pontos de vista do mesmo 
relacionamento. 
9) Os diagramas de sequências oferecem uma visualização de como os objetos 
interagem. 
10) A criação de um objeto é o momento em que esse objeto passa a existir no 
sistema, e passa a realizar suas responsabilidades. Enquanto que a destruição de 
um objeto é o momento no qual este objeto deixa de existir no sistema. 
11) Mensagens síncronas indicam que o objeto remetente espera que o objeto 
receptor processe a mensagem antes de recomeçar o seu processamento. 
12) Mensagem assíncrona é aquela na qual o objeto remetente não espera a 
resposta para prosseguir com o seu processamento. 
8) Dependências podem existir por várias razões: uma classe envia uma mensagem 
para outra; uma classe tem outra como parte de seus dados; uma classe menciona uma 
outra como um parâmetro de uma operação. 
Referências Bibliográficas 
& Consultadas
BEZERRA, E. Princípios de análise e projeto de 
sistemas com UML. Rio de Janeiro: EIsevier, 2007.
FOWLER, M. UML essencial: um breve guia para 
a linguagem-padrão de modelagem de obje-
tos. 3. ed. Porto Alegre: Bookman, 2005. [Minha 
Biblioteca]
GONÇALVES, E� J� T� Análise e projeto de sistemas� 
3. ed. Fortaleza: EdUECE, 2015.
LARMAN, C� Utilizando UML e padrões� 3� ed� 
Porto Alegre: Bookman, 2004. [Minha Biblioteca]
MARINHO, A� L� Análise e modelagem de sis-
temas. São Paulo: Pearson Education do Brasil, 
2016. [Biblioteca Virtual]
MEDEIROS, E� Desenvolvendo software com UML 
2.0: definitivo. São Paulo: Pearson Makron Books, 
2004. [Biblioteca Virtual]PAGE-JONES, M� Fundamentos do desenho orien-
tado a objeto com UML. 1. ed. São Paulo: Makron 
Books, 2001. [Biblioteca Virtual]
PAULA FILHO, W. P. Engenharia de software: funda-
mentos, métodos e padrões. 3. ed. Rio de Janeiro: 
LTC, 2009. Disponível em: [Minha Biblioteca]
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de sof-
tware: uma abordagem profissional. 8. ed. Porto 
Alegre: AMGH, 2016. [Minha Biblioteca]
SOMMERVILLE, I� Engenharia de software. 10. ed. 
São Paulo: Pearson Brasil, 2019. [Biblioteca Virtual]
	Introdução
	Relacionamentos com os diagramas de classes e objetos
	Associação
	Multiplicidade
	Interpretação em programas
	Nomes de associação, direção de leitura de papéis
	Classes associativas
	Associação reflexiva ou autoassociação
	Associação bidirecional
	Agregações e composições
	Generalizações e especializações
	Dependências
	Regras de Restrição
	Diagramas de sequências e interações
	Ocorrências de execução
	Criação e Destruição de Objetos
	Mensagens síncronas e assíncronas
	Considerações finais
	Síntese