=?iso-8859-1?Q?RE=3A_=5Bjava-list=5D_Para_Alexandre=3A__implem?==?iso-8859-1?Q?enta=E7=E3o__de__agrega=E7=F5es__e___associa=E7=F5es?=

[Jorge Martins]

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

 

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

[EMAIL PROTECTED]

Sakonnet Technology, LLC

596 Broadway, Suite 1008

New York City, NY 10012

http://www.sknt.com

 

 

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

 

 

-----Original Message-----
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

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">