Material utilizado na disciplina de Programação Orientada a Objetos (animações e outros efeitos foram perdidos no carregamento). Ciência da Computação (3o período). Universidade do Vale do Itajaí - Campus Kobrasol.
8. marcello.thiry@gmail.com
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
28. marcello.thiry@gmail.com
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
30. marcello.thiry@gmail.com
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
31. marcello.thiry@gmail.com
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)
40. marcello.thiry@gmail.com
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)
*
*
46. marcello.thiry@gmail.com
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
48. marcello.thiry@gmail.com
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
49. marcello.thiry@gmail.com
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”)
56. marcello.thiry@gmail.com
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?
64. marcello.thiry@gmail.com
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
66. marcello.thiry@gmail.com
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/