UML Composition multiplicity

Question

I have a question about indicating multiplicity in an UML diagram.

I have a SpriteObject class, which has a list of animations. The SpriteObject can have 0..* animations. All animations are created inside the SpriteObject and do not exist on their own.

I'm not 100% sure how I should indicate this with multiplicity. After searching the web I have found the following 3 options:

Option 1: The multiplicity should be indicated like this, because every SpriteObject has 0 or more Animations. There is no multiplicity indicated on side of the SpriteObject since the Animation has no clue about the existence of the SpriteObject.

Option 2: The multiplicity should be indicated on both sides like this because we need to indicate the local relationship between the two classes so 1 SpriteObject has 0 or more Animations.

Option 3: The multiplicity should be indicated on both sides likes this, because we need to be able to read the multiplicity and understand it as part of the whole(the game). The game can contain 0..* SpriteObjects and the SpriteObject can contain 0..* Animations. That's why 0..* SpriteObjects has 0..* Animations Can anyone tell me which option is the correct one?(if any of them is)

Answer 1

[Edit]

It should be Option 1. This is a composition relationship

What this means is that SpriteObject contains and manages the lifetimes of the Animation objects.

As an example.

public class SpriteObject : IDispose
{
  private List<Animation> animations;

  // constructor
  public SpriteObject()
  {
    animations = new List<Animations>();

    // initialise the list
  }

  public ovveride Dispose()
  {
    // clear list
  }
}

If this is a an aggregation relationship.

Take note of the symbol, the hollow diamond. This is an aggregagtion relationsip. What this means is that an instance SpriteObject can have zero or more instances of Animation, but the lifetime of the Animation objects is not dependent on the lifetime of the SpriteObject.

A C# code example would look like:

public class SpriteObject
{
  private List<Animation> animations;

  // constructor
  public SpriteObject(List<Animation> animations)
  {
    this.animations = animations;
  }
}

Answer 2

For the multiplicity part - if you omit multiplicity information anywhere (composition, aggregation, association end, attribute, part...), according to UML specification, this means exactly that - you didn't provide the information, it is unknown or irrelevant.

You may choose to provide default value for your model (the UML language specification itself doesn't specify default multiplicity value for user models). Most UML users choose default of exactly one [1] , but I have seen other chosen defaults, like [0..*]. There is no formal way to define default value of multiplicity for a UML model, you have to inform readers of your model in some other way (introductory text paragraph, comment, etc).

If you come across model that doesn't provide this information, safest assumption is that default multiplicity is set to [1].

From this point of view, I would assume that case 1 and case 2 are the same.

For the composition part - semantics of composition relationship, according to UML specification, is as follows: "composite: Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).") - so this rule is applied to objects, not to classes.

It is true that all composed objects have to obey this rule, but that doesn't necessarily mean that all your animation objects have to be composed in sprites. You may have an animation on your intro splash screen, that doesn't belong to any sprite. On the other hand, it is true that composed objects (parts) can't be composed in several composing objects (wholes) at the same time.

Thus, possible situations are:

1. Multiplicity of 0..1 on the Sprite end of composition - this would mean that some animations are part of sprites. Those animations and their lifetime is managed by those sprites. Beside those, there might be other, sprite-independent animations in the system.
2. Multiplicity of exactly 1 (either set explicitly, like in the case 2, or by default, like, probably, for the case 1) - this would mean that all instances of animations must be part of some sprite.
3. Other multiplicity cases, with upper bound greater than 1 - well, since I cannot share composed parts, semantics of composition forbids me to have more than one instance of sprite per animation.

Maybe a little of topic remark at the end:

Setting multiplicity to, let's say 0..* on the sprite end of composition would still produce valid UML (from abstract syntax perspective). It wouldn't make much sense and reader would probably assume some kind of mistake, but when you think about it, you can make instance model that respects all structural and semantical constraints, just by "not using" the possibility to have more than one sprite per animation. It's just like saying that you want some number to be greater than 0 and 10 at the same time. It's not wrong, It's just that it could be specified in simpler and more understandable manner.

Answer 3

I would directly reject option 3 because you mentioned that Animation instance cannot exist on its own and I would be very surprised that the same instance could be related to several SpriteObject instances.

The next question is does an Animation instance have reference to its SpriteObject owner? If not you chose option 1.

Answer 4

• The third one is incorrect. The writing on the line is about one instance of one relationship(it is association this time). You are describing its features. For better feeling, you'd better name it. For example, put animationList on the right side of connection. That would mean, that every animationList is connected to ONE spriteObject(by belonging, most probably), and to many animations (they'd rather be the items of the list).

• The first variant is different, too. It doesn't define the multiplicity on the left side. So, it CAN mean what you want, but it can mean something else, you don't mean. If you haven't decided yet against the variant that the association is not a list structure, but something more complex, that can be connected to several or zero spriteObjects, it would be OK then.

You also have an error in all three pictures - If there will be some references of functions from sprite to animations and NOT vice versa, you MUST put an arrow on the right side.

If you have decided that the connection would be really an attribute of spriteObject, you can show it more precisely by putting a DOT between the right arrow and right class. It is set in most tools by setting classifier's owning for the right end of association.

It is a very good thought to put mutliplicities on the ends. And not only them. The more info you'll put there on aggregation: names, arrows, dots, visibility, the better you'll understand your own model and more chances are you'll notice some problem.

BTW, when you have no arrows on sides (it is the same as having arrows on BOTH arrows), it can show two different variants: one thing that knows about instances on both sides, or (more often) two things simultaneously - TWO different attributes of TWO different instances of TWO different classes - one end is reference from right to left and the other is the reference from left to right. THEN dots become really necessary.