Aula 09 - LPG

Prévia do material em texto

Aula 09: Relacionamentos entre Classes e entre Objetos 
 
Objetivos 
 
 Recordando... 
Nas aulas passadas, criamos algumas aplicações nas quais as classes possuíam uma 
relação entre si que implicava em que uma classe (a subclasse) era uma especialização de 
outra (a superclasse). Tal relação, como vimos, é a relação de herança. 
Em muitos problemas, entretanto, esta relação não é a que desejamos representar. 
Especialmente, quando temos relacionamentos a indicar entre os objetos que serão 
instanciados a partir das classes, que, apesar de se relacionarem, são oriundos de classes 
totalmente distintas. Para tais casos, que exemplificaremos no decorrer da aula, são 
usados outros modelos de relações entre classes e entre objetos. 
 Outros tipos de relações entre classes 
A linguagem UML possui representações para três tipos de relações entre classes: de 
herança (que já vimos anteriormente), de 
dependência e de associação. A relação de 
dependência não implica em uma relação entre 
objetos, mas muitas vezes é útil para a 
implementação de algum método de uma das classes, dessa forma é indicada no 
diagrama de classes. A representação de dependência é feita com uma seta tracejada, 
como no exemplo ao lado: 
Neste caso, a classe Diretoria depende da classe Disciplina, pois se algo mudar em 
Disciplina, esta mudança poderá afetar a forma de implementação de Diretoria, ou seja 
haverá alteração em algum método que faça referência à classe de dependência. No caso, 
o método CriaCurso pode depender de algum parâmetro da classe Disciplina. 
As relações de herança e dependência são relações exclusivamente entre classes. Já as 
relações de associação dizem respeito diretamente aos objetos instanciados a partir das 
classes representadas no diagrama de classes. 
 Relações de associação 
Existem três tipos de relação de associação. Nas associações simples, os objetos 
derivados das classes associadas possuem alguma 
associação entre si. Veja o exemplo ao lado: 
Se quisermos representar a relação apenas de um 
lado para o outro, por exemplo, queremos apenas 
saber qual o endereço de um professor, então 
colocamos na classe Professor um atributo que seja da classe Endereço: 
 
public class Professor{ 
 Endereço endereço; // atributo simples 
 ... 
} 
 Apresentar outros relacionamentos entre classes e entre objetos 
 Compreender as relações de associação 
 Compreender as relações de agregação 
 Compreender as relações de composição 
 
 
Caso haja necessidade de saber, dado um determinado endereço, qual a pessoa (ou 
professor) que está a ele relacionado, então também haveria necessidade de incluir 
referências na classe Endereco à classe Professor, ou a uma classe hierarquicamente 
superior (Pessoa, por ex.): 
 
public class Endereco{ 
 Pessoa pessoa; // atributo simples 
 ... 
} 
 
Caso a cardinalidade da relação fosse maior que um, deveríamos criar uma coleção. 
Assim, se o diagrama fosse: 
Então a implementação deveria permitir à classe 
professor possuir vários endereços: 
 
public class Professor{ 
 Endereço[] endereço; // atributo array 
 ... 
} 
 
Podemos ainda ter associações recursivas entre 
elementos de uma determinada classe, como do 
diagrama ao lado: 
A associação permite definir um papel (titular e 
reserva, no ex.). A implementação, caso estivéssemos 
interessados em saber apenas quem é o professor 
substituto de um professor titular, seria: 
 
public class Professor{ 
 Professor substituto; //atributo recursivo simples 
 ... 
} 
 
Há casos, entretanto, em que a relação é mais complexa e é definida por uma classe, 
chamada de classe de associação: 
Neste caso, a implementação da classe de 
associação provavelmente fará referência aos 
objetos das classes que se relacionam, além de 
acomodar outros atributos e operações de 
interesse para esta associação: 
 
public class Contrato{ 
 Aluno contratante; 
 Instituicao contratado; 
 ... 
} 
 
 
 Relações de agregação 
O segundo tipo de relações de associação é a relações de agregação. Neste tipo de 
relação, uma das classes faz parte da outra, mas 
também pode existir por sua própria conta. 
Veja: 
Neste caso, um curso agrega disciplinas, mas 
pode haver uma disciplina independentemente 
da existência do curso. 
 
public class Curso{ 
 Disciplina[] disciplinas; 
 ... 
} 
Neste caso, mesmo que um objeto da classe Curso deixe de existir, os objetos da classe 
Disciplina que faziam parte deste curso poderão continuar a existir, até porque estas 
disciplinas podem também fazer parte de outros cursos que não tenham sido extintos. 
 
 Relações de composição 
O terceiro tipo de relações de associação é uma relação de agregação especial, chamada 
de composição, em que uma classe, além de fazer parte da outra, não pode existir sem a 
classe que a contém. Neste caso, a extinção de um objeto da classe que contém causa a 
extinção dos objetos das classes que a 
compõem. Veja o exemplo: 
 
 
public class Instituicao{ 
 Departamento[] departamentos; 
 ... 
} 
 
 
 Exercício 
Observe o diagrama de classes UML abaixo: 
Crie a estrutura das classes, adicionando às mesmas os atributos que julgue necessários 
para contemplar as associações de acordo com as cardinalidades e papeis descritos no 
diagrama de classes. 
O método encerrar projeto deve avaliar todos os funcionários que estão participando de 
um determinado projeto e, caso seja um funcionário contratado, emitir um aviso de 
demissão ou, caso seja um funcionário efetivo, desvinculá-lo do projeto e avisar ao chefe 
de departamento que o funcionário está disponível para ser alocado a outro projeto. O 
método de remuneração para o funcionário efetivo deve considerar o seu salário mais 
abono de 10% caso a duração em meses decorridos do projeto não tenha excedido o 
tempo de duração em meses (que é o tempo previsto originalmente para o projeto). Para 
o caso do funcionário contratado, a remuneração deve constar do salário mais um bônus 
de 5% caso o projeto esteja no primeiro terço do tempo previsto, 10% para o segundo 
terço e 15% para o terceiro terço. Caso o projeto tenha excedido o tempo, a remuneração 
deve ser somente o salário.