1

I'm having some trouble fully understanding composition and aggregation. From what i'm understanding a composition relationship means if one dies the other dies. aggregation means they're formed of that, but not necessarily dependent on that things continued existence.

This is the UML I put together for a game of hearts. Am I grasping this concept correctly? UML Diagram

rizz
  • 41
  • 3
  • I will tell you that your Card class looks wrong. What are all those integer attributes supposed to accomplish? – Jim L. Apr 03 '16 at 01:23
  • @JimL. Haha i'm working with a pre-defined Card class. I would not have designed it this way, But have to work around this design. – rizz Apr 03 '16 at 05:59
  • What tool did you use to draw this diagram, and why does it duplicate the memberName twice for a couple of classes? Doesn't look like real UML. – Jim L. Apr 03 '16 at 12:45
  • I used visio, And it's incomplete. I didn't define the variables and methods yet. I was just trying to get a better understanding of the aggregation/composition types. – rizz Apr 03 '16 at 22:39

1 Answers1

1

What is composition and aggregation ?

The composition and aggregation represents a whole/part relationship (UML 2.5, section 11.5.3.1):

A binary Association may represent a composite aggregation (i.e., a whole/part relationship).

So if you use a diamond, you should first ask yourself if it's really a whole/part relationship, before thinking how objects are created or deleted.

Then composition have additional constraints over a shared aggregation. In a composition relationship (UML 2.5, section 9.5.3):

(...) the composite object has responsibility for the existence and storage of the composed objects.
Composite aggregation is a strong form of aggregation that requires a part object be included in at most one composite object at a time. If a composite object is deleted, all of its part instances that are objects are deleted with it.

Analysis of your specific diagramm

According to your diagram:

  • The players exists only within a game (i.e. temporary identification not accounts existing across several games). The composition could make sense, as players can be seen as parts of the game.
  • The hand exist only in relation to a player. That makes sense. But is it really a composition relationship ? Is the hand a part of a player ? Is the player composed of hands ? Wouldn't a player have several hands sequentially but not in the same time ? I really have my doubt about a composition here; I'd represent this with a normal 1 player to many hands association.
  • The game aggregates several decks. I don't know your game but I'd expect one deck. If several decks are used, and the decks only exists within a game (similarly to the players), I'd rather see a composition instead of an aggregation. Alternatively you could mean not the deck, but the deck together with its state. In this case, I'd opt for a one to many association and not a composition (the deck+state would not be a component of your game, but define the state of the game).
  • A deck is the aggregation of cards that exist independently of the deck. This troubles me a lot, as my world experience has always shown that a card is part of a deck. If I find an isolated card somewhere I always look for it's deck. I'd therefore rather expect a composition between cards and deck.
  • Finally a hand is the aggregation of several cards, which seems to make sense. Note that this is not incompatible with a composition between the deck and the card.
Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Thanks. This helped a ton. – rizz Apr 03 '16 at 22:39
  • 1
    Your references to UML 2.5 are incomplete. They also, confusingly, say "A part object may be removed from a composite object before the composite object is deleted, and thus not be deleted as part of the composite object". See my SO answer http://stackoverflow.com/questions/734891/aggregation-versus-composition/27889087#27889087 – Gerd Wagner Apr 05 '16 at 03:19