class Professor {}
class Course {
private Professor teacher;
}
Ou seja, uma associa��o _�_ implementada como
uma referencia.
Nesta mesma apostila � o seguinte sobre
agrega��o:
Uma agrega��o _�_ uma especializa��o de uma
associa��o em que o "todo" � relacionado a suas partes. A apostila ainda tr�s
estes testes para identificar uma agrega��o:
A frase "parte de" � usada para descrever o
relacionamento?
Algumas opera��es no todo se aplicam a parte? (ex:
move o carro, move a porta)
Alguns valores de atributos se propagam do todo
para as partes? (ex: o carro � azul, a porta � azul)
Existe uma assimetria intr�nsica no relacionamento,
indicando uma subordina��o: (ex: Uma porta � parte do carro, o carro N�O � parte
da porta)
Um relacionamento de agrega��o pode ser de dois
tipos, por referencia e por valor. Uma agrega��o por valor implica
que a "vida" dos objetos dependendes s�o restritos a "vida" do objeto que
os agrega. Uma agrega��o por referencia implica que a "vida" dos objetos
podem ser independentes.
Neste caso espec�fico de Aluno <-> Aula,
creio que n�o exista agrega��o...
Sobre as classes de associa��o:
Durante o design, uma classe de associa��o se torna
uma classe entreposta entre as duas classes antes diretamente associadas, sendo
estabeleciadas associa��es entre a classe de associa��o e as outras duas classes
com as devidas multiplicidades.
Leonardo Bueno.
....................................................
Leonardo Souza
Mario Bueno
itera Inform�tica
[EMAIL PROTECTED]
Phone: 55 27
337 0317
Cell: 55 27 9971 1375
Visit our website at:
http://www.itera.com.br
....................................................
----- Original Message -----
Sent: Monday, March 19, 2001 1:33
PM
Subject: RES: [java-list] Para Alexandre:
implementa��o de agrega��es e associa��es
Jorge,
Eu concordo com o Sven neste caso. A existencia de uma classe
"Aula" ou
"Disciplina"
retrata melhor o que queremos modelar. Um professor nao
tem,
_necessariamente_
que estar associado a um aluno. "Professor" pode,
inclusive
ser um titulo que
o cara ostenta, sendo assim um conceito muito mais
abrangente
do que
simplesmente uma pessoa que da aulas (apesar de ser estranho,
eh
possivel).
Acho que a
interpretacao do codigo nao esta errada nao. Se voce diz que
um
professor
referencia um conjunto de alunos, voce esta _sim_ dizendo
que
os Alunos "fazem
parte" do Professor. Esta associacao eh,
inclusive, problematica
sob o ponto de
vista de implementacao. Eu explico:
1. Imagine que um
professor mude de disciplina no meio do semestre ou ano
letivo.
Com a sua
modelagem teriamos que reassociar todos os alunos (centenas,
talvez).
Com a classe
"Aula" isso seria um procedimento trivial.
2. "Aula" (ou
"Disciplina") eh uma entidade que independe de um professor especifico.
No seu caso, como modelariamos uma disciplina que eh
ensinada por mais de um
professor? Teriamos que manter todos os conjuntos
de associacoes simultaneamente,
o que nao eh muito eficiente. Digamos que duas disciplinas
sao ensinadas, cada uma,
por
tres
professores e tem 100 alunos (cada). Teriamos, entao, 3 x 100 = 300
referencias
para representar
uma aula. Se os professores trocassem de turma, teriamos
que
atualizar 600
referencias. Um pensamento similar seria aplicado para o caso de
termos
alunos cancelando
disciplinas (fato extremamente comum).
3. Digamos que nao
houve troca de professores; simplesmente o semestre
acabou.
Teriamos que,
novamente, atualizar MILHARES de referencias, ja que neste
caso
TODOS os
professores terao novos alunos. Em uma universidade com 50 mil
alunos
e 5 mil
professores isto pode ser um pouco caro.
4. Mais: depois
que o semestre terminar, onde iremos buscar as informacoes
a
respeito de uma
determinada disciplina, ensinada em um determinado
semetre?
Ou se um aluno
cursou esta disciplina ou quando ele a cursou? A classe "Aula"
(cujo semestre
faria parte de seu identificador -- o metodo equals() ajudaria) resolve
o problema de uma
maneira elegante.
Acho que, por
estas razoes, a existencia da classe "Aula" eh de
fundamental
importancia e
associar um professor diretamente a um aluno nao eh muito
eficiente.
Cordialmente,
Andre
Mendonca
Sakonnet
Technology, LLC
596 Broadway,
Suite 1008
New York City, NY
10012
N�o concordo.
Um
refer�ncia em java n�o representa que um objeto t�m um outro. Este objeto
n�o � do outro, apenas h� uma refer�ncia para ele, coerente com a defini��o
de associa��o.
N�o discordamos do conceito, seja dito. Mas sua interpreta��o do
c�digo est� equivocada. O fato do Professor ter uma (ou mais refer�ncias)
para um Aluno n�o representa que o Aluno fa�a parte do professor. E sim o
comportamento destas entidades.
E
voc� pode perceber que no meu modelo est� implementado uma rela��o
bidirecional e em nenhum momento aluno faz parte de professor. Apenas n�o h�
uma classe descrevendo esta associa��o.
N�o tenho a m�o o Rational Rose, mas acredito que uma associa��o sem
"association class" ser� modelada como eu descrevi.
De
qualquer forma esta � uma boa discuss�o, pois trata-se da implementa��o e
visualiza��o de modelos em c�digo java.
abra�os
Jorge
Jorge Martins wrote:
[EMAIL PROTECTED]"
type="cite">
Sven,
N�o � necess�rio ter uma classe que descreve a
associa��o para ser uma associa��o. Ela s� � necess�ria quando o
relacionamento det�m alguma informa��o ou possui algum comportamento
pr�prio que precisa ser encapsulado.
A implementa��o em java para a associa��o
tipicamente � uma refer�ncia para o objeto da outra classe. O que define
como associ��o ou agrega��o � o comportamento das
entidades.
abra�os
Jorge
ps: veja em ferramentas UML como o Together e perceba como o c�digo
gerado para ambas as op��es s�o iguais, apenas com um coment�rio ao lado
indicando o tipo do
relacionamento.
Association de acordo
com Rational:
Association
A relationship that models a
bi-directional semantic connection among instances.
Aggregation
An
association that models a whole-part relationship between an aggregate and
its parts.
Por�m, quando uma classe faz parte de uma outra classe (a
tem b) falamos de uma agrega��o. Ae, cualquer coisa assim:
class
Professor{
private Collection alunos;
}
ou
class
Professor{
private Aluno[] alunos;
}
� por
defini��o uma agrega��o, ja que agora o aluno �faz parte do� professor. No
caso de um relacionamento de professores e alunos n�o � a situa��o que vc
quer. A informa��o sobre o relacionamento de professor com o aluno n�o �
apropriado para ser contido dentro das classes. Um professor n�o *tem*
alunos e o alnuno n�o *tem* professores, apesar do fato que eles tem *algum
tipo* de relacionamento. Ai vem a Aula. O professor d� aula e os alunos
recebem as aulas, portanto pode dizer que:
Uma aula *tem* zero ou varias
professor(es) e *tem* zero ou varias alunas:
class Aula{
private Collection alunos;
private Collection professores;
}
Uma cone�ao semantica de uma classe com a outra (o professor que d�
aulas aos alunos) � uma associa��o.
Testei ambos no Rose e no
Together, mas infelizmente o Together nem d� para definir um �association
class�, por�m esse modelo n�o pode ser modelado no Together, mas o Rose
gera:
//Source file: c:\\temp\\Professor.java
public class
Professor
{
public Professor()
{
}
}
e
//Source file:
c:\\temp\\Aluno.java
public class Aluno
{
public Aluno()
{
}
}
e
//Source file: c:\\temp\\Aula.java
public
class Aula
{
public Aula()
{
}
}
No caso de uma associa��o bidirectional ae ter� que modelar
ainda a agrega��o Aula-Aluno e Aula->Professor
ai gera:
//Source
file: c:\\temp\\Aula.java
public class Aula
{
public Professor theProfessor[];
public Aluno
theAluno[];
public Aula()
{
}
}
Sven
[EMAIL PROTECTED]"
type="cite">
