poo - unidade 2 (parte 1) - diagrama de classe - associação (versão 2)
DESCRIPTION
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.TRANSCRIPT
Prof. Marcello Thiry <[email protected]>
PROGRAMAÇÃO ORIENTADA A OBJETOS
Unidade 2 (parte 1)
3º período
UML3
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 UML4
14 diagramas
7 diagramas estruturais
Visão estática
7 diagramas comportamentais
Visão dinâmica
Diagramas UML6
14 diagramas
Mas, iremos trabalhar nesta disciplina com apenas 2 diagramas
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
UM aluno é orientado por UM professor
Mas,
Regras de negócio:
Todo e qualquer aluno precisa ter um orientadorNem 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 UMobjeto 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 multiplicidade32
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
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?
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
47Se utilizarmos uma associação bidirecional no nosso exemplo, o nome da associação valerá apenas para uma das direções!
48Mas, 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
Nomeando uma associação com nomes de papel (role names)
Representa o modificador de visibilidade “privado”
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
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>
Você precisa garantir as regras:
Um aluno não pode ficar sem coordenadorUm 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, poisexigem 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
65Para exercitar!
Modele um diagrama UML a partir dos seguintes conceitos:
Aluno, Professor, Turma, Disciplina, Curso
Pense na sua realidade dentro da universidade
Referências66
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 ModelingLanguage v2.5, 2013. http://www.omg.org/spec/UML/2.5/Beta2/PDF/
