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,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
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 minhapreocupaçã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]
-------------------------------------------------------------------------
