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