=?iso-8859-1?Q?RE=3A_RE=3A_RES=3A_=5Bjava-list=5D_Para_Alexand?==?iso-8859-1?Q?re=3A_implementa=E7=E3o__de__agrega=E7=F5es_e___associa?==?iso-8859-1?Q?=E7=F5es?=

[Jorge Martins]

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.

 

 

 

-----Original Message-----
From: Sven van �t Veer [mailto:[EMAIL PROTECTED]]
Sent: sexta-feira, 16 de mar�o de 2001 09:52
To: [EMAIL PROTECTED]
Subject: Re: RE: RES: [java-list] Para Alexandre: implementa��o de agrega��es e associa��es

Jorge,

Acho que est� quase certo. Implementando assim, est� errado. A rela��o no caso do seu profesor ainda � tem. Veja o seguir:

/* modelo escola */
class Professor
{
	
}

class Aluno
{
	
}

class Aula{
	private Professor p;
	private Collection alunos;
}

Isso � uma associa��o. Uma associa��o � uma rela��o entre duas ou mais classes gerenciado por uma(s) outras classes. Qualquer rela��o *tem* � uma agrega��o. Por�m neste exemplo a classe Aula � o 'association class' que tem os seguintes rela��es com Aluno e Porfessor:
Uma aula *tem* um professor;
Uma aula *tem* zero ou mais alunos.
As outras rela��es:
Alunos *tem aula* de um Professor
Um professor *d� aula* a varias alunos.


Sven

Jorge Martins wrote:

[EMAIL PROTECTED]" type="cite">

N�o � n�o, valter. Associa��o e agrega��o s�o ambos relacionamentos de
classes. Em java, voc� implementa como uma refer�ncia de um objeto ao outro.

Exemplo:


/* modelo do banco de dados */
class Table
{
	private Row rows[]; /* agrega��o "tem" */
}


class Row
{
	private Table table
}

/* modelo escola */
class Professor
{
	private Aluno alunos[]; /* associa��o leciona */
}

class Aluno
{
	private Professor professores[];
}

A implementa��o dos dois casos � id�ntica, mas o primeiro � uma agrega��o e
o segundo � uma associa��o. 

A difer�n�a est� no tipo da entidade relacionada. Na agrega��o voc� se
relaciona com uma entidade fraca, que t�m a exist�ncia dela dependente a
outra. Grosso modo onde h� na descri��o o verbo ter, h� uma agrega��o. No
exemplo: "Tabela tem linhas".

A associa��o relaciona com entidades fortes, de exist�ncia independente a
outras entidades. Um professor e um aluno existem independentemente, apenas
se associam. O professor leciona aluno. Logo, o professor tem uma associa��o
lecionar com aluno.

Sacou? As diferen�as na implementa��o s�o pequenas. Todas espelham essas
diferen�as de comportamento que eu descrevi acima.

abra�os

Jorge


-----Original Message-----
From: valter vieira de camargo [mailto:[EMAIL PROTECTED]]
Sent: quarta-feira, 14 de mar�o de 2001 19:10
To: [EMAIL PROTECTED]
Subject: Re: RES: [java-list] Para Alexandre: implementa��o de
agrega��es e associa��es


Sobre as associa��es e agrega��es eu estou achando que � realmente isto:
agrega��o - atributo do tipo de outra classe
associa��o - instancia��o de uma classe dentro de algum m�todo de outra...

Quanto � abordagem do Furlan... ser� que se modelarmos um sistema
completamente
OO sem a preocupa��o com chaves, etc.... a dificuldade na implementa��o ser�
muito acentuada, voc� n�o acha ? Eu estou desenvolvendo um projeto de
mestrado e
quero fazer da maneira certa entende ? A minha outra preocupa��o � quanto ao
projeto ..... no modelo de classes de an�lise tudo bem ... mas o meu modelo
de
classes de projeto tem que ter alguma coisa relacional....


Alexandre Rodrigues Gomes wrote:

Valter,

na implementa��o acho que poder�amos resumir na seguinte forma:
para agregar, utilizaremos atributos de inst�ncia, ou seja,
"vari�veis globais" e para associa��o podemos criar apenas
vari�veis locais de m�todos. Ser� que � plaus�vel esta abordagem ?
Se bem que podemos ter atributos de classe que n�o s�o verdadeiras
agrega��es mas apenas realizam papel associativo. Acho que
isto � bem conceitual mesmo. O pessoal da lista podia dar
uma forcinha.....

Quanto �quela abordagem do Furlan, eu questiono um pouco.
Ora, temos hoje que o que se busca � a independ�ncia da fonte
de dados. Devemos abstrair a forma com que a base de informa��es
ser� implementada, nos deter apenas numa interface pr�-definida
e deixar as quest�es peculiares de cada banco com uma camada
de software que realize o mapeamento OO/Relacional. Amarrar
o seu modelo de neg�cios numa solu��o �nica de backend �
limitar seu processo de desenvolvimento � n�o escalabilidade
e evolu��o.

By Al�!

-----Mensagem original-----
De: valter vieira de camargo [mailto:[EMAIL PROTECTED]]
Enviada em: quarta-feira, 14 de mar�o de 2001 10:48
Para: [EMAIL PROTECTED]
Assunto: [java-list] Para Alexandre: implementa��o de agrega��es e
associa��es

Ok... Alexandre ...
              � justamente no ponto da implementa��o a minha

preocupa��o....

              Gostei do que voc� disse e acho que realmente est� certo.
Minhas d�vidas eram mais quanto �  implementa��o das associa��o. E tamb�m
ach
oque � assim que funciona.... isto �, dentro de uma classe , instancio uma
outra e a utilizo para cumprimento das responsabilidades da primeira.
        No caso da agrega��o, um atributo da classe � do tipo de outra....
        � isto, n�o � ?

        Agora veja bem.

        Em um livro de UML do Furlan, encontrei que para se fazer a
normaliza��o de um modelo de classes, visando o projeto � claro, deve-se
basear em algum tipo de banco de dados ser� utilizado. Se os dados do meu
sistema ser�o persistidos utilizando BD OO a normaliza��o se d� sem a
preocupa��o das chaves prim�rias e estrangeiras... mas quando o me sistema
utiliza BD relacional devo me preocupar com isso... s� que ele apenas
exemplifica a normaliza��o utilizando BD OO. Voc� sabe alguma coisa sobre
essas normaliza��es com BD relacional ?

[]'s Valter.

Alexandre Rodrigues Gomes wrote:

Valter,

no n�vel de linguagem, tanto agrega��o quando associa��o
se d�o de maneiras similiares. O que as distingue � o seu
modelo. Na UML, a associa��o � feita apenas com uma linha
ligando as classes envolvidas enquanto que a agrega��o �
uma linha com um losango na ponta da classe agregadora.

Conceitualmente, deveria-se utilizar agrega��o quando o
prop�sito de uma classe for o de encapsular o funcionamento
de algum objeto, ou seja, ele ser� parte constituinte daquela
classe. No caso da associa��o, a classe apenas tem conhecimento
de alguma outra classe e faz uso de alguma inst�ncia desta para
completude de suas responsabilidades.

No primeiro cap�tulo do livro do Gamma (Design Patterns),
ele d� uma descri��o legal sobre a utiliza��o destas duas
alternativas.

Abra�os,
By Al�!

-----Mensagem original-----
De: valter vieira de camargo [mailto:[EMAIL PROTECTED]]
Enviada em: ter�a-feira, 13 de mar�o de 2001 19:38
Para: [EMAIL PROTECTED]
Assunto: [java-list] implementa��o de agrega��es e associa��es

        Visto que � comum a utiliza��o de linguagens orientadas a
objetos e banco de dados relacionais, pretendo estipular um padr�o de
implementa��o para tais casos de modelagem.
        Estou desenvolvendo uma pesquisa com java e SyBase e devido as
diferen�as entre os dos paradigmas algumas d�vidas surgem.
        Eu gostaria de saber a diferen�a entre a implementa��o de um
modelo de classes com agrega��o e com associa��o. Percebo que a
agrega��o � f�cil identificar, isto �, quando uma classe possui um
atributo cujo tipo � de outra classe. Mas e quando temos uma associa��o
? Como voc�s implementam uma associa��o sendo fiel � documenta��o ?

Valter

------------------------------ LISTA SOUJAVA

----------------------------

http://www.soujava.org.br  -  Sociedade de Usu�rios Java da Sucesu-SP
d�vidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para

[EMAIL PROTECTED]
-------------------------------------------------------------------------

------------------------------ LISTA SOUJAVA

----------------------------

http://www.soujava.org.br  -  Sociedade de Usu�rios Java da Sucesu-SP
d�vidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para

[EMAIL PROTECTED]
-------------------------------------------------------------------------

------------------------------ LISTA SOUJAVA ----------------------------
http://www.soujava.org.br  -  Sociedade de Usu�rios Java da Sucesu-SP
d�vidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para [EMAIL PROTECTED]
-------------------------------------------------------------------------

------------------------------ LISTA SOUJAVA ----------------------------
http://www.soujava.org.br  -  Sociedade de Usu�rios Java da Sucesu-SP
d�vidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para [EMAIL PROTECTED]
-------------------------------------------------------------------------

------------------------------ LISTA SOUJAVA ---------------------------- 
http://www.soujava.org.br  -  Sociedade de Usu�rios Java da Sucesu-SP 
d�vidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para [EMAIL PROTECTED] 
-------------------------------------------------------------------------

------------------------------ LISTA SOUJAVA ---------------------------- 
http://www.soujava.org.br  -  Sociedade de Usu�rios Java da Sucesu-SP 
d�vidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para [EMAIL PROTECTED] 
-------------------------------------------------------------------------