POO - Unidade 2 (parte 1) - Diagrama de Classe - Associação (versão 2)

Prof. Marcello Thiry <marcello.thiry@gmail.com>
PROGRAMAÇÃO ORIENTADA
A OBJETOS
Unidade 2 (parte 1)
3º período

marcello.thiry@gmail.com
UML
3
 Linguagem de Modelagem Unificada
 Padrão OMG (Object Management Group) desde 1997
 http://www.uml.org/
 http://www.omg.org/spec/UML/2.5/Beta2/PDF/

Diagramas UML
4
 14 diagramas
 7 diagramas estruturais
 Visão estática
 7 diagramas comportamentais
 Visão dinâmica

5
UML 2.5 (beta 2), pg. 718

Diagramas UML
6
 14 diagramas
 Mas, iremos trabalhar nesta disciplina com apenas 2
diagramas

7
Visão estática
Visão dinâmica

Diagrama de classe
 Descreve a estrutura de um sistema
 Um diagrama de classe permite visualizar:
 classes do sistema, seus atributos e operações
 relacionamentos entre as classes
 relacionamentos entre classes e interfaces
8

Principais relacionamentos
 Generalização / Especialização (herança)
 Associação
 Agregação e Composição
9
Já trabalhamos
com herança na
Unidade 1

Associação
 Relação entre ocorrências (objetos) das classes
 Indica que objetos “Professor” estarão associados com
objetos “Aluno”
10

11
Professores Alunos
marcello
alessandro
fabiane
anita
joao
maria
pedro
jose
objetos com objetos

Associação
 Mas, qual é a relação entre Professor e Aluno?
12

Associação
13

14
Nome da associação
(indica a semântica da
conexão entre os objetos)

15
Note que a semântica é
diferente nas duas
associações

16
O nome da associação deve
sempre ser uma frase verbal

A semântica aqui é diferente?
São mesmo duas associações
diferentes?

Se a semântica é a mesma,
então é a mesma associação

19
Mas, como devemos ler a associação?
 quem orienta quem?
 quem coordena quem?

20Sem conhecer o negócio, a leitura
destas associações é ambígua!

E agora?
Facilitou o entendimento?

Indica a direção da
associação (orienta a
leitura)

Lado da associação
(uma associação possui
dois lados)

Professor “orienta” Aluno
Professor “coordena” Aluno

Mas, um professor pode orientar
quantos alunos?

UM professor orienta VÁRIOS alunos
VÁRIOS = = 0, 1 ou mais
*

UM aluno é orientado por UM professor
Mas,
Regras de negócio:
Todo e qualquer aluno precisa ter um orientador
Nem todo professor precisa orientar um aluno

UM professor coordena VÁRIOS alunos
UM aluno é coordenado por UM professor
Pegou a ideia?

Multiplicidade
 Define quantos objetos participam em um
relacionamento
 O número de objetos de uma classe relacionada a UM
objeto da outra classe
 Deve ser especificada em cada lado da associação
30

Multiplicidade x Cardinalidade
 Cardinalidade
 Número de elementos em um conjunto
 Multiplicidade
 A especificação do intervalo de valores de cardinalidade
permitidas – o tamanho – que um conjunto pode assumir
31
(Booch, Rumbaugh e Jacobson, 1999)

Indicadores de multiplicidade
32
Vários/Muitos/Zero, um ou mais:
Um ou mais:
Zero ou um:
Exatamente um:
Exatamente três:
Faixa especificada:
Múltiplas faixas:
*
*1..
0..1
1
3
2..4
2..4, 6..8

Veja se você consegue ler....

34
Professores Alunos
marcello
alessandro
fabiane
anita
joao
maria
pedro
jose
1 para 1

35
Professores Alunos
marcello
alessandro
fabiane
anita
joao
maria
pedro
jose
1 para *

36
Professores Alunos
marcello
alessandro
fabiane
anita
joao
maria
pedro
jose
para
**

1 1
Um objeto Professor aponta para um objeto Aluno
O objeto Professor precisa de um ponteiro (objeto)

1 1
A classe Aluno é independente da classe Professor
A classe Professor depende da classe Aluno

0..1 *
Agora, as regras de negócio espelham melhor a
realidade:
 Nem todo professor precisa ter um orientando ( = 0, 1 ou +)
 Um professor pode ter vários orientandos ( = 0, 1 ou +)
 Um aluno pode ter ou não um professor orientador, mas
nunca mais do que um orientador (0..1)
*
*

Alguma ideia para tratar
este lado da associação?
Como um objeto Professor
poderá apontar para
vários objetos Aluno?

0..1 *

*0..1

*
O que você acha? Faz mais sentido?
0..1

Navegabilidade
45
Unidirecional
Bidirecional
Indefinida

Navegabilidade
 Os dados podem fluir em uma ou em ambas as direções
através da associação
 Canal de comunicação pelo qual, os objetos conversam
entre si (trocam mensagens)
 Uma mensagem pode ser uma requisição por informação
ou uma requisição para executar uma ação
 Uma mensagem é trocada quando um objeto “chamador” invoca
uma operação de um objeto “receptor”
46

47
Se utilizarmos uma associação bidirecional no nosso
exemplo, o nome da associação valerá apenas para uma das
direções!

48
Mas, quando pensamos na implementação, precisamos
considerar um atributo para cada lado, certo?!
Papel (role) assumido
pelos objetos Aluno
nesta associação
Papel (role) assumido
pelo objeto Professor
nesta associação

Nomeando uma associação com nomes de papel
(role names)
Note que, se utilizarmos nomes de papel, é uma boa prática evitar
o nome da associação (poderia deixar o diagrama “poluído”)

Implementando a partir dos nomes dos papéis
interpretados pelas classes
Papel do
Professor
Papel do
Aluno

(role names)
Você notou o sinal?

(role names)
Representa o modificador
de visibilidade “privado”

Tudo ok com esta representação?
O que deveríamos interpretar?

Haveria duplicação de atributos com o
mesmo nome!
Se você utilizou uma associação, não coloque sua
implementação nas classes do diagrama

Mas, qual é o problema
que temos quando a
associação é bidirecional?

Vamos considerar um cenário, onde temos um Professor
chamado “marcello” que orienta dois Alunos chamados
“joao” e “pedro”
Vamos criar primeiro o objeto Professor:
Professor marcello = new Professor (“Marcello”);
Observe que se Professor fosse obrigado a ter um orientando,
teríamos uma situação inconsistente
Poderíamos criar o objeto Aluno antes e repassá-lo ao
Professor no momento da instanciação
Mas, se um Aluno também tivesse que ter obrigatoriamente um
orientador?

joao.setOrientador(marcello);
pedro.setOrientador(marcello);
Cenário onde temos um objeto Professor chamado “marcello” e dois
objetos Aluno chamados “joao” e “pedro”:
Como seria a implementação da
operação “setOrientador”?

Se houver um
orientador, então
precisamos sincronizar
antes...
E garantir que o
novo orientador
também conhecerá o
novo orientando
Operação “Atômica” (indivisível)

Outra forma, caso não seja implementada a operação
“delOrientando” na classe Professor
Retornaria a lista
de orientandos
ArrayList<Aluno>

Lembre-se:
Semânticas diferentes, associações diferentes!

Você precisa garantir as regras:
 Um aluno não pode ficar sem coordenador
 Um coordenador precisa ter, pelo menos, um aluno
 ...

Para considerar:
 Associações bidirecionais...
 ... aumentam o acoplamento (dependência entre
classes), reduzindo a reusabilidade
 ... aumentam a complexidade da implementação, pois
exigem que o sincronismo seja mantido nos dois
lados da associação
 ... quando definidas como vários para vários,
aumentam ainda mais a complexidade da
implementação

65
Para exercitar!
Modele um diagrama UML a
partir dos seguintes conceitos:
Aluno, Professor, Turma,
Disciplina, Curso
Pense na sua realidade dentro
da universidade

Referências
66
 Grady Booch, James Rumbaugh, and Ivar Jacobson. The Unified
Modeling Language User Guide. 2nd ed. Addison-Wesley, 2005.
 Ricardo Pereira e Silva. UML 2 em Modelagem Orientada a
Objetos. Visual Books, 2007.
 OMG (Object Management Group), OMG Unified Modeling
Language v2.5, 2013.
 http://www.omg.org/spec/UML/2.5/Beta2/PDF/

POO - Unidade 2 (parte 1) - Diagrama de Classe - Associação (versão 2)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a POO - Unidade 2 (parte 1) - Diagrama de Classe - Associação (versão 2)

Semelhante a POO - Unidade 2 (parte 1) - Diagrama de Classe - Associação (versão 2) (7)

Mais de Marcello Thiry

Mais de Marcello Thiry (10)

Último

Último (20)

POO - Unidade 2 (parte 1) - Diagrama de Classe - Associação (versão 2)