[UML - Diagrama de Classes] Composição x Agregação

Assuntos Gerais Agile
#1

Bom, pessoal.

Não mexo com UML há muito tempo e tenho encontrado uma certa dificuldade para modelar nos meus diagramas de classes as associações com multiplicidade 1 para * ( vários ).

Sempre fico em dúvida se coloco uma associação normal, uma associação com agregação ou uma associação com composição.

Sei que, nesses relacionamentos, quando uma classe é o todo e a outra representa uma parte do todo, há espaço para agregação ou composição. Mas tenho dificuldades para identicar quando é correto utilizar cada um, ou, até mesmo, não utilizar nenhum dos dois, deixando simplesmente a associação.

Neste tópico gostaria que postassem algumas dicas para ajudar no reconhecimento desses elementos, além das que são mostradas nos livros de UML, como o “Guia do Usuário”.

Consultei esses sites antes de criar esse tópico:
http://www.ericksasse.com.br/agregao-x-composio/
http://www.plugmasters.com.br/sys/materias/667/1/Escolha-o-que-usar,-Agrega��o-ou-Composi��o

Mas a explicação deles é praticamente a mesma da literatura que consultei.

Desde já agradeço!

Abraços,

#2

Eu costumo pensar da seguinte forma… imagine um cenário em que eu tenho 2 objetos: “A” e “B”, e estou na dúvida da relação entre eles… faça as seguintes perguntas:

1 - Se eu “deletar” o A, terei que “deletar” também o B ?
Sim = composição
Não = pode ser agregação ou nada… goto pergunta 2
Exemplo: pedido e compras… um pedido pode ter várias compras, mas se eu deletar o pedido, preciso deletar as compras (não faz sentido eu ter um objeto compra sem que ele esteja em nenhum pedido… sua única razão de existir é “compôr” um pedido).

2 - O objeto B tem alguma utilizade sozinho ?
Sim = associação comum
Não = agregação
Exemplo: carro e rodas… se eu deletar um carro, não preciso deletar suas rodas, pois elas podem servir pra outro carro. Isso me fez vir para a pergunta 2, porém uma roda tem utilizade sozinha ? Geralmente não, ela serve sempre para “agregar” uma funcionalidade a outro objeto, como a funcionalidade de andar ao carro (ou a um outro veículo qualquer), ou até mesmo a funcionalidade para crianças sentarem em um “balanço de árvore”, etc…

O caso de composição é o mais claro, agora o de agregação muitas vezes vai da interpretação do analista, pois alguém poderia contestar que uma roda tem sim uma utilidade sozinha para algum caso bizarro que ele observou, ou que existe no “mundo particular dele”.

espero ter ajudado… abraço

#3

sei que esse tópico é meio antigo, mas acho que postando poderei ajudar algum “desesperado”…rs

Tipos de Associação:

  1. Associação Simples (representada por um traço entre as classes)
  2. Agregação (representada por um losango aberto no lado do todo)
  3. Composição (representada por um losando cheio no lado do todo)

Vamos à diferenciação entre eles…
1) Associação simples:
-estabelece uma relação semântica estrutural entre classes.
Ex: uma Pessoa trabalha para uma Companhia, uma Companhia tem vários Escritórios, etc.

2) Agregação:
-estabelece uma relação todo-parte entre classes, sendo que a parte pode existir sem o todo.
Ex: Carro e Roda. Uma Roda é parte de um Carro, porém pode a Roda existe por si só fora do Carro. Você pode por exemplo remover a roda de um carro para colocar em outro.

3) Composição:
-estabelece uma relação todo-parte entre classes, sendo que a parte NÃO existe sem o todo.
Ex: Pedido e Itens de Pedido. Se você destruir o Pedido, os Itens são destruidos junto, eles não tem sentido se não houver um Pedido.

Portanto,
respondendo à pergunta do nosso amigo…
Se NÃO HOUVER a relação todo-parte (excluindo os casos de herança e outras associações que não foram citadas) -> ASSOCIAÇÃO SIMPLES
Se HOUVER a relação todo-parte -> temos que ver se a parte pode existir sem o todo…
Se a parte existir sem o todo -> AGREGAÇÃO
Se a parte não existir sem o todo -> COMPOSIÇÃO

Espero ter ajudado!!!
Abraços
Anderson R. Ferreira

#4

Achei esse tópico pois estou fazendo uma modelagem e cai exatamente nessa situação.

Uma coisa que não entendi, nesse exemplo clássico do Pedido e Item Pedido.

Pedido <---------- ItemPedido
1…*

Isso significa que para um pedido eu posso ter 1 ou mais itens nesse pedido.

Em termos práticos, em um diagrama de classes, eu faço esse tipo de modelagem, ou eu defino logo a classe Pedido com um atributo do tipo: List<ItemPedido> ???

Pedido

idPedido;
dataPedido;
valor;
List<ItemPedido>
etc…

Grato

#5

Nesse caso, haverá 2 classes (e entidades de banco): uma para pedido, outro para itemPedido. A entidade itemPedido será referenciada na classe Pedido.
Vc pode fazer assim(vou colocar em código, mas dá pra imaginar como ficaria no diagrama):
Public class Pedido {
itemPedido iPedido; //já tendo implementado pedido em uma outra classe

Em termos de banco, itemPedido será referenciada como uma chave estrangeira em Pedido.
Ok?

#6

Legal o tópico, estou com dois casos de associações que gostaria que avaliassem

CASO 1: Autor X Livro X Errata

O autor publica o Livro porém o Livro não é composto pelo autor - neste caso é uma associação simples.
Já uma Errata só existe se houver Livro, a não existência do Livro faz a Errata perder o sentido - é então um caso de composição.

Engraçado neste caso é que a Errata pode ou não compor o Livro, já que um livro pode existir sem Errata. Nestas condições está certo tratar Errata como composição mesmo?

CASO 2: Prova X Local da prova (Sala de Aula)

Eu não preciso da Sala de Aula para compor a Prova, é uma associação normal (ok?!)
MAS
Se eu disser que a Prova de biologia só pode ser aplicada na Sala de biologia, como ficaria essa Associação, alguém sabe?

Valeu!
abs

#7

http://www.guj.com.br/posts/list/116560.java

#8

Eu usaria um critério menos formal.

Um Livro pode ou não ter uma Errata [A Errata pode ou não fazer parte do livro]. Então será uma associação simples ou agregação a depender do nível de associação que você queira dar.

Pouca associação, num contexto mais geral, associação simples. Muita associação, num contexto mais geral, então é uma agregação.

Um livro precisa de pelo menos um Autor para existir e também assumir a autoria. O autor pode até ajudar a distinguir livros com nomes iguais. Então é uma composição. Um livro sem autor, mesmo desconhecido, nunca existiria.

Autor: desconhecido. Mas a composição não deixa de existir.

A mesma coisa serve para um Produto que não existiria se não fosse feito pelo Fabricante. É uma composição.

Mas a associação não tem muito haver com os atributos do objeto.

O fato do Carro ser composto de rodas não exige um atributo do tipo Rodas. O que o atributo diz é algo semantico: “Um carro é composto por rodas”, 'Um carro é composto por motor". Mas os atributos, formas de implementação, podem ser construídos de várias formas. Exemplo: atributo Roda[4] rodas. atributo List rodas. atributo Rodas[4] pneus.

Então não confundam a associação com a exigência de determinado atributo.

Uma prova é um objeto cujos atributos são: cabeçalho, título, questões.

A aplicação de uma prova depende de alguns objetos: a prova, o local, o tipo de prova, etc.

Prova

  • cabeçalho
  • título
  • questões
  • Disciplina disciplina

AgendaProva/AplicaçãoProva

  • id
  • Prova prova
  • Local local
  • DataHora datahora
  • Turma turma
  • PeriodoLetivo periodo

Uma prova está agregada a uma disciplina. “É a prova X da disciplina de biologia”.
A Aplicação de uma prova é composta da prova, local de realização, data, turma e periodo letivo em que ela será realizada. A aplicação da prova vai ocorrer de acordo com estes moldes.

Obserque que embora prova tenha vários atributos, eu não preciso incluí-los na associação. Pois, associação não implica em atributos. Já na Aplicação a relação é tão forte que cada associação tem um atributo que o relaciona ao objeto Aplicação.

eu faria uma modelagem semelhante a esta

[quote=pgnt]Legal o tópico, estou com dois casos de associações que gostaria que avaliassem

CASO 1: Autor X Livro X Errata

O autor publica o Livro porém o Livro não é composto pelo autor - neste caso é uma associação simples.
Já uma Errata só existe se houver Livro, a não existência do Livro faz a Errata perder o sentido - é então um caso de composição.

Engraçado neste caso é que a Errata pode ou não compor o Livro, já que um livro pode existir sem Errata. Nestas condições está certo tratar Errata como composição mesmo?

CASO 2: Prova X Local da prova (Sala de Aula)

Eu não preciso da Sala de Aula para compor a Prova, é uma associação normal (ok?!)
MAS
Se eu disser que a Prova de biologia só pode ser aplicada na Sala de biologia, como ficaria essa Associação, alguém sabe?

Valeu!
abs

[/quote]

#9

excelente explicação andersonarf, minha dúvida é a implemetação das classes em java.
ex:

//Isso é agregação?

public class Motor{

}
public class Carro{
private Motor motor;
}

e como seria composição? como entendi seria:

public class ItemPedido{

}
public class Pedido{
//instanciado dentro da classe Pedido
private ItemPedido itemPedido = new ItemPedido();
}
ou
public class Pedido{
private ItemPedido itemPedido;
public Pedido(){
//instaciado dentro do construtor
 itemPedido = new ItemPedido();
}
}

está correto? e como seria associação em java?

#10

Java não faz distinção entre agregação e composição, eles são implementados da mesma forma, como atributos de uma classe.

Talvez para modelar o conceito de “Objeto secundário não existe sem o principal”, o jeito é controlar o ciclo de vida do secundário dentro do principal, onde terceiros não consigam instanciar o objeto diretamente.

#11

[quote=gibaholms]Eu costumo pensar da seguinte forma… imagine um cenário em que eu tenho 2 objetos: “A” e “B”, e estou na dúvida da relação entre eles… faça as seguintes perguntas:

1 - Se eu “deletar” o A, terei que “deletar” também o B ?
Sim = composição
Não = pode ser agregação ou nada… goto pergunta 2
Exemplo: pedido e compras… um pedido pode ter várias compras, mas se eu deletar o pedido, preciso deletar as compras (não faz sentido eu ter um objeto compra sem que ele esteja em nenhum pedido… sua única razão de existir é “compôr” um pedido).

2 - O objeto B tem alguma utilizade sozinho ?
Sim = associação comum
Não = agregação
Exemplo: carro e rodas… se eu deletar um carro, não preciso deletar suas rodas, pois elas podem servir pra outro carro. Isso me fez vir para a pergunta 2, porém uma roda tem utilizade sozinha ? Geralmente não, ela serve sempre para “agregar” uma funcionalidade a outro objeto, como a funcionalidade de andar ao carro (ou a um outro veículo qualquer), ou até mesmo a funcionalidade para crianças sentarem em um “balanço de árvore”, etc…

O caso de composição é o mais claro, agora o de agregação muitas vezes vai da interpretação do analista, pois alguém poderia contestar que uma roda tem sim uma utilidade sozinha para algum caso bizarro que ele observou, ou que existe no “mundo particular dele”.

espero ter ajudado… abraço

[/quote]

gibaholms, revivendo o tópico, rapaz, li diversas apostilas e nenhuma delas foi simples e direta igual a sua explicação. Esclareceu uma dúvida minha, abraço.

#12

Desculpem reviver o tópico mais uma vez, porém li sobre o assunto no livro “UML 2 - Uma abordagem prática” e a ideia sobre associação, agregação e composição ficam muito ligado ao sentido que o analista quer empregar.

Uma característica forte da agregação é que os objetos-parte podem ser compartilhados por mais de um objeto-todo.
Caindo no exemplo do carro/roda. No geral as rodas podem existir em outro carro, então pode ser agregação. Em Autor/livro partimos da ideia que se eu deletar um autor pode-se transferir a autoria para um autor “desconhecido”, portanto o livro existe sem um autor “conhecido”.

Já na composição, os objetos-parte não podem ser destruídos por um objeto diferente do objeto-todo ao qual estão relacionados.
Analisando o caso Livro/errata, não faz sentido que uma instancia de errata, que foi criada para um livro especifico, existir quando o livro para a qual foi criada for excluído. Pois a errata se relaciona unica e exclusivamente a um livro.

Foi isso que eu entendi lendo o livro e a discussão de vocês aqui.

Abçs

#13