Projeto de Software

Orientado a Objetos

Profa. Maria Istela Cagnin Machado

2
Disciplina: Análise e Design

Artefatos
(Design):
Diagramas de
Comunicação e
Diagrama de
Classes

3
Disciplina de Projeto (design) de
Software
• Visa produzir uma solução para o problema
identificado pela análise:
– Casos de Uso
– Modelo conceitual
– Diagramas de Sequência do Sistema (DSS)
– Contratos

• Projetar uma arquitetura de software para realizar

concretamente o sistema

4
Disciplina de Projeto de Software
Os artefatos produzidos durante a análise OO representam o
“quê” o sistema faz, sem detalhes que comprometam a
solução a uma tecnologia específica

A disciplina de projeto contém detalhes sobre “como” o

sistema poderá ser implementado

Para conseguir isso, será necessário detalhar as informações

sobre as classes que comporão o sistema, incluindo o
comportamento esperado de cada objeto e a colaboração
entre os objetos 5
Disciplina de Projeto de Software
• No Processo Unificado, o projeto é conduzido
utilizando basicamente dois tipos principais de
diagramas UML:
– os Diagramas de Comunicação (podem ser
substituídos por Diagramas de Sequência) e
– o Diagrama de Classes

6
Disciplina de Projeto de Software
• Diagramas de Comunicação:
– Deve haver pelo menos um para cada operação ou
consulta complexa de sistema, levando em conta o modelo
conceitual e os contratos
– Apóia a identificação dos métodos necessários para
concretizar cada operação e consulta de sistema

• Diagrama de Classes:
– Se baseia, em primeiro lugar, no modelo conceitual,
adicionando mais informações (métodos, tipos dos
atributos, etc.)

7
Disciplina de Projeto de Software
• Pode-se dizer que o núcleo do Projeto de Software
Orientado a Objetos é o Diagrama de Classes!

Mas o Diagrama de Comunicação é muito

importante!!!

8
Disciplina de Projeto de Software
• Diagrama de Comunicação x Implementação
– Alguns dizem ser capazes de implementar sem “perder
tempo” desenhando diagramas
– Outros usam diagramas de comunicação só para
documentar
– Estão ERRADOS!!!!

– Diagramas de Comunicação + Padrões de Projeto (Design

Patterns) permitem descobrir o local adequado para
implementar cada método
– Solução mais elegante e eficaz

9
 Diagrama de
Comunicação

10
Diagrama de Comunicação
• Diagramas de Comunicação permitem realizar a
modelagem dinâmica do sistema
– ou seja, como os objetos que fazem parte da arquitetura
trocam mensagens para realizar suas responsabilidades

• Também conhecidos como Diagramas de Interação

– É modelado como:
• Diagrama de Colaboração na UML 1
• Diagrama de Comunicação na UML 2
• Ou até como Diagrama de Sequência (opção alternativa para
modelar colaborações)
11
Diagrama de Comunicação
• Representam a interação entre objetos por meio de
mensagens

• INTERAÇÃO / COLABORAÇÃO entre objetos

– As mensagens resultam na ativação de métodos, os quais

realizam as ações necessárias

– O que é um objeto?

12
Relembrando...
Objetos e Classes: Exemplos

Leitor le1: Leitor le2: Leitor

nome nome = Maria dos Santos nome = Joao da Silva
matricula matricula = 523231 matricula = 323232
dataNascimento dataNascimento = 04/25/1973 dataNascimento = 02/23/1978

classes
objetos

FornoDeMicroondas forno1: FornoDeMicroondas

capacidade capacidade = 40
potência potencia = 600
status status = desligado
horário
hora = 09:35

13
Relembrando...
Objetos e Classes: Exemplos
• Classe é um agrupamento de objetos similares

• Todo objeto é uma instância de uma Classe

• Os objetos representados por determinada classe

diferenciam-se entre si pelos valores de seus atributos

• Conjunto de objetos que possuem

– propriedades semelhantes (ATRIBUTOS),
– o mesmo comportamento (MÉTODOS),
– os mesmos relacionamentos com outros objetos, e
– a mesma semântica
14
Relembrando...
Objetos e Classes: Exemplos

• Métodos são invocados por Mensagens

• Cada objeto possui seu próprio conjunto de métodos

15
Atributos e Métodos

Automóvel

proprietário
marca
placa Atributos
ano

registrar()
transferir_Proprietário()
mudar_Placa() Métodos

16
Métodos X Mensagem
mensagem

método

public void alterarNome(String novoNome){

this.nome = novoNome;
}

17
Diagrama de Comunicação
• Deve haver um diagrama de comunicação para cada
contrato descrito na análise
Nome da operação ou
consulta

18
Diagrama de Sequência
• Também pode ser utilizado no projeto
• Neste caso, deve haver um diagrama de sequência para cada
contrato descrito na análise

Nome da operação
ou consulta
19
Diagrama de Sequência (DS)
vs Comunicação
(DC)
• Ambos são especializações do diagrama de interação da UML

• Ambos podem ser utilizados para expressar interações entre

objetos por meio de troca de mensagens

• Os DCs ilustram as interações entre objetos em forma de grafo

ou rede
– os objetos podem ser colocados em qualquer lugar do diagrama

• Os DSs ilustram as interações de forma vertical (em raias)

– cada objeto novo é acrescentado à direita
20
Mensagem entre dois objetos
• No paradigma OO deve-se projetar o sistema em
termos de objetos e da comunicação entre eles

• A única forma de um objeto se comunicar com outro

é enviando uma mensagem para esse outro objeto,
que poderá responder a essa mensagem

21
Mensagem entre dois objetos
• Um objeto, ao receber uma mensagem, executa um
método para atender a essa mensagem
Uma mensagem representa uma chamada/invocação a um
método do objeto

• A notação da UML para comunicação entre objetos é

ilustrada a seguir

22
Mensagem entre dois objetos no
diagrama de comunicação

• O objeto obj1 é uma instância da classe Classe1

– O nome do objeto poderia ter sido omitido, portanto poderia ter sido
colocado dentro do retângulo apenas : Classe1

• obj2 é uma instância da classe Classe2

• A mensagem está sendo enviada pelo objeto obj1 ao objeto obj2

• A mensagem passa dois parâmetros para o objeto obj2

23
Classes x Instâncias

Instância
Classe Instância
nomeada

Venda :Venda venda1:Venda

24
 Exemplo
Modelo Conceitual - Diagrama de classes -
antes depois

Nova mensagem
Diagrama de identificada
Comunicação
1. mudarSituacao(“disponivel”): void

25
Exemplo
1. mudarSituacao(“disponivel”): void

• O objeto itemEmp (da classe ItemDoEmprestimo) envia uma mensagem ao

objeto exLivro (da classe Exemplar) para solicitar que a situação da cópia
seja modificada para “disponível”, após a devolução do livro

• A classe Exemplar deve possuir um método para alterar o valor do atributo

situação (o nome desse método é mudarSituacao e ele possui um
parâmetro do tipo String)

26
Ordem das mensagens

• Já sabemos que o Diagrama de Comunicação mostra a

comunicação entre vários objetos para realizar um
certo comportamento desejado
– Exemplo: se um objeto não contém conhecimento
suficiente para responder a uma determinada mensagem,
ele pode recorrer a outros objetos que conheça,
enviando-lhes mensagens para obter o conhecimento
desejado

27
Ordem das mensagens
• Assim, a ordem em que as mensagens são enviadas é
frequentemente muito importante

• Por isso, as mensagens são numeradas!

– Pode ser sequencial: 1, 2, 3, ....,n

– Ou aninhada: 1, 1.1, 1.2, 1.3, 1.4, 2, 2.1, 3,...n

28
Ordem das mensagens

29
Variáveis de retorno
A variável tipo é passada
como parâmetro para o
construtor de
ItemDoEmprestimo

obterTipoLeitor retorna um
resultado que é armazenado na
variável tipo
30
Variáveis de retorno
• Em um Diagrama de Comunicação, pode ser necessário
armazenar certos resultados de invocação de mensagens
para serem utilizados posteriormente, por exemplo, para
serem passados como parâmetros em outras mensagens
– Para isso, pode-se utilizar variáveis

• Na mensagem n.2, obterTipoLeitor(), obtêm-se o tipo do

leitor (por exemplo, aluno, professor, etc.), que é
atribuído a uma variável tipo
– Esse tipo é passado como parâmetro para a criação da
ItemDoEmprestimo
– Nesse caso específico, linhaDoEmprestimo utiliza tipo para
calcular a data de devolução do livro
31
Invocação condicional
• Pode ser desejável que certas mensagens só sejam
executadas em circunstâncias pré-definidas
– Exemplo: um empréstimo só pode se concretizar se o leitor
estiver apto a emprestar livros (não ultrapassou a quantidade
máxima de livros permitidos e não está devendo nenhum
livro à biblioteca)

• Isso pode ser feito utilizando cláusulas ou predicados

booleanos antes do nome da mensagem

32
Invocação condicional
O construtor de
ItemDoEmprestimo só é
invocado se apto for
verdadeiro

33
Invocação condicional
• Operadores lógicos e relacionais podem ser
utilizados para combinar várias condições
– Exemplo
[naoEstaEmAtraso AND nroLivros<maximoPermitido]

34
Invocação condicional
• Pode-se desviar o fluxo da execução das mensagens
para um método ou outro, simulando um comando
condicional, colocando-se [condição] em um deles e
[not condição] no outro

[condicao] mensagem1()
:ClasseB

:ClasseA

:ClasseC
[not condicao] mensagem2()

35
Repetição de mensagem
• Em alguns casos, uma mensagem pode precisar ser
enviada várias vezes ao objeto, por exemplo em um laço
– A UML 2.x define o uso de * ou *|| para repetição de
mensagens, exemplo: *[i := 1..n], *||[k:1..n]
– Mas nem todas as ferramentas CASE fornecem essa
possibilidade, e para tanto pode-se usar palavras chave tais
como para cada, repita, etc.

[repita i de 1 a 100] mensagem1(i)

:ClasseA :ClasseB

36
Mensagem para coleção de objetos
• Uma mensagem pode ser enviada a vários objetos,
ou seja, para uma coleção de objetos.
– Por exemplo, para obter os títulos dos livros emprestados pelo leitor
em uma certa data, deve-se percorrer todas as linhas de empréstimo
do empréstimo em questão, obtendo de cada uma delas o título do
livro correspondente

1: *[ for each ] obterTituloLivro():String

:Emprestimo :ItemDoEmprestimo

37
Mensagem para coleção de objetos
• Para denotar vários objetos (coleção) em algumas
ferramentas UML utiliza-se um retângulo com linhas
duplas, como mostrado anteriormente
– Deve-se notar que a mensagem obterTituloDoLivro é
enviada uma única vez para cada um dos objetos
itemDoEmprestimo que pertencem à coleção de linhas de
empréstimo do empréstimo atual

38
Mensagem para o próprio objeto
• Uma mensagem pode ser enviada de um objeto para
ele mesmo (auto-mensagem), denotando que o
próprio objeto entende e processa a mensagem
– No exemplo a seguir, o objeto l1 da classe Livro recebe a mensagem
ehDeConsulta, processa-a e armazena seu resultado na variável
booleana cons, que depois é utilizada como condição para mudar ou
não a situação do exemplar do livro

39
Resumo da sintaxe
• Sintaxe básica das expressões de mensagens

retorno = mensagem(parâmetro:tipo,...):tipoDeRetorno

– Exemplo:
inicie()
inicie(cod)
d = obterDescProduto(id:idItem):String

40
 Diagrama de Sequência
• Exemplo de diagrama de sequência: registrarPagamento

• A mensagem registrarPagamento é enviada para uma instância de uma

CaixaRegistradora
• O objeto CaixaRegistradora envia a mensagem registrarPagamento a uma
instância de Venda
41
• A instância de Venda cria uma instância de Pagamento
Diagrama de Comunicação
• Exemplo de diagrama de comunicação: registrarPagamento
• Tem a mesma
leitura do diagrama
anterior

42
 Codificando de acordo com o projeto
public class CaixaRegistradora
{
private Venda venda;
//...
public void registrarPagamento(double quantia)
{
venda.registrarPagamento(quantia);
//...
} public class Venda
//... {
} private Pagamento pagamento;
//...
public void registrarPagamento(double quantia)
{
pagamento = new Pagamento(quantia);
//...
}
//... 43

}
Diagrama de Comunicação x UML
• Modeladores UML novatos não prestam atenção
suficiente nos diagramas de comunicação

Diretriz

Empregue tempo fazendo modelagem de objetos

dinâmica com diagramas de comunicação/ interação,
não apenas modelagem de objetos estática com
diagramas de classe

44
Diagramas de Comunicação no PU
• É a realização de cada pós-condição do contrato da operação de sistema e
de cada resultado da consulta do sistema
– Cada pós-condição corresponderá a uma ou mais mensagens enviadas
entre objetos

• As mensagens enviadas são divididas em dois grupos:

1) Mensagens básicas: realizam aquilo que a pós-condição requer
2) Mensagens delegadas: passam adiante a responsabilidade de realizar
uma operação básica quando o objeto que detém o controle da
execução não possui visibilidade direta para o objeto que deve
executar a operação
• Visibilidade observada no modelo conceitual

45
Regras para elaborar Diagramas de
Comunicação
1. Criar um diagrama de comunicação para cada operação ou
consulta de sistema complexa que está sendo desenvolvida
na iteração atual
– Para cada mensagem de operação ou consulta de sistema complexa,
criar um diagrama com essa mensagem como mensagem inicial

2. Usar os artefatos citados abaixo para elaborar os diagramas

de comunicação visando identificar os objetos e a troca de
mensagens entre eles para identificar os métodos que
devem ser implementados em cada classe
1. pós-condições dos contratos de operação de sistema ou os
resultados das consultas de sistema,
2. o modelo conceitual, e
3. a descrição dos casos de uso (caso necessário)

46
• Elaborar o diagrama de comunicação da operação
cancelarConsulta(idConsulta)

1.1: listaConsultas =
retornaConsultasAgendadas(cpf)

47
Modelo
Conceitual
• Exercício feito em
sala de aula

0..* 0..*

0..1

0..*
0..*

0..1
1..* 0..*
Contrato
Operação: cancelarConsulta(idConsulta)
Referências Cruzadas: Caso de uso “Cancelar consulta”
Pré-Condições: Um paciente já foi identificado, as consultas agendadas do
paciente já foram identificadas, uma consulta cujo identificador idConsulta foi
selecionada para ser cancelada
Pós-Condições:
– O objeto cons da classe Consulta cujo identificador é idConsulta foi
identificado.
– cons.situação foi atualizada para “cancelada”.

49
Modelo
Conceitual
• Exercício feito em
sala de aula

0..* 0..*

0..1

0..*
0..*

• Adicionar o 1

atributo situação
1..*
0..1
0..*
descoberta no
contrato
Diagrama de comunicação
• Operação: cancelarConsulta(idConsulta)

51
Exercício 1
• Elabore o diagrama de comunicação da operação
removerConsulta(idConsulta)

52
Contrato
Operação: removerConsulta(idConsulta)
Referências Cruzadas: Caso de uso “Gerenciar consulta”
Pré-Condições: A operação remover foi selecionada, uma consulta com
identificador idConsulta foi informada para ser removida.
Pós-Condições:
– O objeto cons da classe Consulta cujo identificador é idConsulta foi
identificado
– A associação entre cons e dentista foi desfeita
– A associação entre cons e paciente foi desfeita
– A associação entre cons e secretária foi desfeita
– O objeto cons foi excluído.

53
Diagrama de comunicação
• Solução do exercício 1

54
 Exercício 2
• Elabore o diagrama
de comunicação da
operação
agendarConsulta

55
Exercício 2:
agendarConsulta(CPF, CRO, data, hora)
Operação: agendarConsulta(CPF, CRO, data, hora)
Referências cruzadas: Caso de uso “Agendar Consulta”
Pré-condições: O paciente e o dentista estão cadastrados no sistema; a data e hora do
agendamento da consulta foram informadas e estão disponíveis
Pós-Condições:
– O objeto pac de Paciente cujo CPF é igual ao parâmetro CPF foi encontrado
– O objeto dent de Dentista cujo CRO é igual ao parâmetro CRO foi encontrado
– Um objeto cons de Consulta foi criado
– cons.DataAgendamento foi atualizado com a data atual
– cons.dataConsulta foi atualizado com o valor do parâmetro data
– cons.horaConsulta foi atualizado com o valor do parâmetro hora
– cons.situacao foi atualizado para “agendado”
– O objeto pac foi associado ao objeto cons
– O objeto dent foi associado ao objeto cons
56
Referências
• Material didático próprio da FACOM baseado no trabalho das professoras Maria
Istela Cagnin Machado, Debóra Maria Barroso Paiva e Jane Sandim Eleutério.
• Bibliografia Básica:
– BOOCH, G. et al. UML – Guia do usuário. 2.ed. Rio de Janeiro: Campus, 2005.
– WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientados a objetos. Rio de
Janeiro: Campus, 2a edição, 2011.
• Bibliografia Complementar:
– FOWLER, M. UML distilled: a brief guide to the standard object modeling language. 3. ed.
Upple Saddle River: Addison-Wesley, 2003.
– LARMAN, C. Utilizando UML e padrões. 3. ed. Porto Alegre: Bookman, 2007.
SCHACH, S. R. Object-oriented software engineering. New York: McGraw-Hill, 2007.
– STUMPF, R. V.; BEZERRA, E. Princípios de análise e projeto de sistemas com UML, Elsevier
Acadêmico, 3. ed 2014.
– TEAGUE, L. C. Object oriented systems analysis and design with UML. New York: McGraw-Hill,
2004.

APSOO 57