Menu
Actually, make that a couple of amateur UML questions! When creating a UML diagram to model some domain concepts and you come across a domain concept that "holds" some information about another concept, is it better to hold a stamp/reference to that entity or hold the whole entity in the model itself? Please bear in mind that this is relating to creating a simple high-level model - I'm sure in the implementation stage things would be slightly different.
For example, which of the two models below is actually correct? The first one has a composition relationship, with FlightBooking holding the whole of Flight. In the second one, FlightBooking just has a reference to Flight.
Secondly, when creating a high level UML diagram modelling domain concepts, how much detail are you really meant to go? For example, in the diagram below, a flight could hold details about origin/destination as strings, or I could model separate classes for these concepts and create a composition relationship. Which of the two is advisable?
Also, just another thing, when modelling the above where a Flight "holds" an orig/destination as another class rather than a string, which of the two ways is the correct way of modelling this? I'm quite confused as to when to show assosciation and when to show composition.
314
To sum it up association is a very generic term used to represent when a class uses the functionalities provided by another class. We say it's composition if one parent class object owns another child class object and that child class object cannot meaningfully exist without the parent class object.
In UML models, an aggregation relationship shows a classifier as a part of or subordinate to another classifier. In UML models, an association is a relationship between two classifiers, such as classes or use cases, that describes the reasons for the relationship and the rules that govern the relationship.
In Object-Oriented programming, an Object communicates to another object to use functionality and services provided by that object. Composition and Aggregation are the two forms of association.
In UML diagrams, an association class is a class that is part of an association relationship between two other classes. You can attach an association class to an association relationship to provide additional information about the relationship.
Association :
It means two classes have some kind of relationship, could be anything really.
E.g : A uses B, A is related to B in a given way.
Composition :
This is also a special type of association used for modelling 'Ownership'. This is very similar to Aggregation with the only difference that it depicts a Whole-part relationship and the 'part' entity doesn't have its own independent existence
E.g : A consists of B; B is a part of A and hence cannot exist without A.
Good explanation : UML Class Diagram: Association, Aggregation and Composition
137
Sorry if this is a bit long...
If you're trying to model domain concepts then I'd encourage you to forget about composition/aggregation and stick with simple associations. Why? Because deciding on composition / aggregation gets in the way of the important questions. They are:
Relationship naming You accomplish (1) by naming the rel ends. Not with role names (e.g. "Flights" in your first example) because that tells you nothing about why the relationship exists. So in your example 1: what does the relationship represent? Is it a reserved seat on the flight? A confirmed one? Paid for? Impossible to tell from the diagram as it stands. There are various approaches for verb-based naming, see e.g. this post. Why do this? Because it prompts you to make sure you understand the domain. A large percentage (probably a majority, although I've never proven it) of the domain rules exist in the relationships. So understanding why the relationships exist is fundamental to understanding the domain.
Cardinality Probably more obvious than naming. You should determine at both ends - both upper and lower. Important at the lower end is whether it's optional (i.e. 0 or 1). At the upper end, 1 or many. Again this surfaces important rules from the domain. Coming back to your example again: how many flights in a flight booking? Can one flight be in multiple bookings? (whatever 'in' means...).
Create / Delete Behaviour Who creates instances of the relationship? Who deletes? If one end gets deleted, what happens to the other end? Again, all important rules from the problem domain.
Those hopefully answer your second question too. Don't skimp on relationships. Take time to understand them. They are the secret sauce to understanding a domain. Answering all the questions above will give you far more insight than trying to decide among composition/aggregation/association.
If you really want to show composition vs association however it is mechanical if you answer the questions above:
Otherwise use a simple association. As for aggregation: ignore it. Remove it from your vocabulary. Causes more confusion than it's worth. Everything you can say with aggregation you can say far more clearly and precisely with a properly defined simple association.
hth.
PS: a point of syntax: Composition uses a filled diamond. What you've shown is Aggregation.
28
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
