Não
duvido que seja uma modelagem muito melhor. Sem dúvida é. Meu debate com o Sven
vem por ele considerar que a implementação sem a "association class" determina
uma agregação. Esta explicando que não é necessário uma 'association class' numa
associação e que uma referência em java não representa que um objeto de uma
classe possui (agregaga) outro.
Encontrei um exemplo de associação no livro Modelagem e Projetos Basados
em Objetos, do Rumbaugh, que confirma isso. Este exemplo mostra que uma forma de
implementar associação em C++ é colocando um ponteiro na classe. Em java, este
ponteiro seria uma simples referência.
valeu
Jorge
-----Original Message-----
From: Andre Mendonca [mailto:[EMAIL PROTECTED]]
Sent: segunda-feira, 19 de março de 2001 13:34
To: [EMAIL PROTECTED]
Subject: RES: [java-list] Para Alexandre: implementação de agregações e associações
From: Andre Mendonca [mailto:[EMAIL PROTECTED]]
Sent: segunda-feira, 19 de março de 2001 13:34
To: [EMAIL PROTECTED]
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çosJorge-----Original Message-----Jorge Martins wrote:
From: Sven van ´t Veer [mailto:[EMAIL PROTECTED]]
Sent: sexta-feira, 16 de março de 2001 18:09
To: [EMAIL PROTECTED]
Subject: Re: RE: RE: RES: [java-list] Para Alexandre: implementação de agregações e associações
[EMAIL PROTECTED]" type="cite">Association de acordo com Rational: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
Jorgeps: 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
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">
