Manuel says hi.
Manuel is slightly embarrassed by this post, so will try and keep it short.
Associations and links
When types (or classes) have some sort of… ahem, relationship, this can be shown by drawing a line between them:
This is called association between the types.
When we represent the same between instances of the types, i.e. objects, the association becomes a link:
Naming associations – time for D. T. R.
… or “Defining The Relationship”. If this freaks you out, you are not alone.
To name a relationship, a label can be put on top of the line and an (optional) arrowhead, when there is a certain direction in the relationship, like in the example above.
Associations can be bidirectional too. The diagram below means that each of the classes is associated to the other by keeping a reference (or a pointer) to it as a property. In other words, if you know a Programmer, you have a reference to his Manager, which, in turn references back the same Programmer.
Bidirectional associations between types or classes should be used with care. See the following refactoring advice for an explanation: “Change Bidirectional Association to Unidirectional”.
Multiplicity – “When were you going to tell me?”
The picture above would be closer to reality if we actually made Manager : m_subordinate an array of Programmers, i.e. Manager : m_subordinates[].
As much as I hate to think about it, my relationship with Fossey, my manager, is not that exclusive. It’s not even a triangle, it’s a harem!
When we want to show the number of objects in a relationship, we put numbers and symbols at the relevant ends of the relationship line.
Here is how multiplicity is represented with symbols
- 1 of course means “one object”
- * means “many”
- 0..* means “zero or more”
- 0..1 – “zero or one”
- 1..* – “at least one”
- m..n – “at least m, but no more than n“
Ownership – composition and aggregation
When an object can be considered “part of” another object, this can be shown with a diamond arrowhead at the end of the relationship line coming out of the “whole” object.
For example: if “subordinates” is part of the Manager type, then I’m part of that too.
Providing this is the only type I am a part of, I’d show this with a filled diamond arrowhead. This is called composition. It means that I am “owned” by Fossey and he is the only one I take command from. Good. It also means however, in programming terms, that he is responsible for “creating” and “deleting me” and I’ll have to go too, when he is given the sack. Not so good.
As you might have noticed in previous posts, Fossey is hardly the only one I take command from. In reality I’m in shared custody of him and our salesman Fibbs, to name but two. This is called aggregation and is shown with an empty diamong arrowhead:
Not an ideal situation either, but has its perks…
Definitions
- UML – Unified Modelling Language
- UML Sequence Diagram – a diagram, which describes a scenario in the behaviour of groups of collaborating objects
- actor – something or someone, interacting with a system, but not part of it
- lifeline – a line, representing the life span of a participant in the scenario
- message – a line of communication between participants in the scenario (see “Messages in UML 2.0 Sequence Diagrams” for details on the types of messages and their use)
- Class Diagram – a digram, which shows classes (object types), participating in a system, their properties and the relationships between them
- Class Properties represent the features of a class, which can be attributes or associations
Resources
As much as I would like to take credit for the knowledge in this article, all the UML stuff comes from:
- The UML Standard
- “UML Distilled Third Edition” by Martin Fowler
- “UML 2 for Dummies” by Michael Jesse Chonoles, James A. Schardt
The cool cartoons are courtesy of zlotence.
The blog is cool
Thanks for the clear explanation, really helped me solve the composition and aggregation part of UML!
Thank you, 100 times haha