|
----- Original Message -----
Sent: Friday, March 16, 2001 9:52
AM
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
1) Somente olhando estas classes n�o d� para fazer nenhuma destas afirma��es. Analisando o dom�nio do problema as duas primeiras afirma��es n�o me parecem l�gicas pois o
ciclo de vida das instancias das classes Professor e Aluno n�o s�o relacionadas ao ciclo de vida
da classe Aula. (Ex: Se uma Aula sair do cat�logo de disciplinas os Professores e Alunos que
tiveram esta aula somem? Se voc� executar alguma opera em uma instancia de Aula o efeito �
propagado para as instancias associadas das classes Professor e Aluno?) Analisando os fontes das classes as duas outras afirma��es tamb�m n�o procedem pois nada indica
que a classe Professor n�o tenha algum relacionamento com a classe Aluno. 2) Uma associa��o n�o precisa ser gerenciada por outras classes 3) Uma rela��o nunca tem uma agrega��o, ela pode eventualmente "ser" uma agrega��o ou ter
uma "Association Classes" relacionada 4) Usar a classe Aula descrita no exemplo como uma "Association Class" est� errado, ela s� teria
sentido se guardasse alguma informa��o sobre a associa��o entre Professor e Aluno. Leonardo Bueno.
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]
-------------------------------------------------------------------------
|
