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



Responder a