I have short question about class diagrams. In my book we have class Person and class Gender and agregation arrow between them(with diamond pointing to person). Now, in general when I want to decide whether we have agregation or not I am using one of these two rules:
1.When you destroy class that is whole, than part can exist without it;
2.Class that is part in agregation relation, can be mutual to one or more wholes.
Now if we look at this example and rule number 2, it is OK, because one gender is mutual to one or more persons. But for the first one, if there is not person, than we can't talk about gender right?So I would set composition here. Probably I am missing main difference between these two. Any help is appriciated.
In general
Your rule about when using aggregation is not wrong. But it's unnecessarily complex. There is a simpler much simpler rule about when you'd better use aggregation: never.
This may sound provocative, but the hard truth is that the meaning of aggregation is not defined in the UML specifications, which makes it ambiguous and subject to a lot of unnecessary time-consuming debates:
Sometimes a Property is used to model circumstances in which one instance is used to group together a set of instances; this is called aggregation. (...) Precise semantics of shared aggregation varies by application area and modeler.- UML specifications 2.5.1, page 112.
I know, it comes as a shock. For years in my career, I have myself selected very carefully aggregation whenever there was a part-whole relation with non-exclusive ownership. But when I came accross James Rumbaugh famous quote, I challenged my own assumptions and realized how vain and subjective this quest was:
Keep in mind that aggregation is association. Aggregation conveys the thought that the aggregate is inherently the sum of its parts. In fact, the only real semantics that it adds to association is the constraint that chains of aggregate links may not form cycle (...) In spite of the few semantics attached to aggregation, everybody thinks it is necessary (for different reasons). Think of it as a modeling placebo.- James Rumbaugh in Unified Modeling Language Reference Manual, chapter 14.
So, whenever you have aggregation in a model, you could simply replace it with an association without real loss of information.
In your specific example
The association: Person ----- Gender expresses perfectly that a person has a gender, and that several persons can share the same gender.
If you want to be super-accurate, you could use the dot notation (with a small dot on Gender side). This would convey the information that Person owns the end of the association.
Composition would definitely be wrong here, because it's an exclusive ownership and no two persons could share the same gender.
Aggregation is ambigous: what is the whole, what is the part? If gender is a part, wouldn't character be a part as well. And what with the name, then ?
A final remark: if you want to implement this with Person having a gender:Gender property (an OOP mechanism called "object composition") the, you don't need aggregation (even if it's a popular practice).
Related
Here I am, with another question about aggregation and association. I wanted to learn some basics of UML, so I started reading "UML distilled" by Martin Fowler. I read both chapters about classes, and there is one thing that I can't fully grasp I think, and that is aggregation vs association. In the book there is this quote:
In the pre-UML days, people were usually rather vague on what was aggregation and what was
association. Whether vague or not, they were always inconsistent with everyone else. As a result,
many modelers think that aggregation is important, although for different reasons. So the UML
included aggregation (Figure 5.3) but with hardly any semantics. As Jim Rumbaugh says, "Think of it
as a modeling placebo" [Rumbaugh, UML Reference].
As I understand from this quote and topics that I read on Stack Overflow it doesn't matter which one of those two relations I use, they mean basically the same, or is there any situation where the usage of aggregation instead of association would be justified and/or I could not change one to the other without changing the "meaning" of a class diagram?
I am asking this, because this book is from 2003 and some things could have changed during those few years.
Maybe this can help you, but i don't think you will find the perfect explanation:
The difference is one of implication. Aggregation denotes whole/part
relationships whereas associations do not. However, there is not
likely to be much difference in the way that the two relationships are
implemented. That is, it would be very difficult to look at the code
and determine whether a particular relationship ought to be
aggregation or association. For this reason, it is pretty safe to
ignore the aggregation relationship altogether. [Robert C. Martin | UML]
And an example for each situation:
a) Association is a relationship where all object have their own
lifecycle and there is no owner. Let’s take an example of Teacher and
Student. Multiple students can associate with a single teacher and
single student can associate with multiple teachers, but there is no
ownership between the objects and both have their own lifecycle. Both
can create and delete independently.
b) Aggregation is a specialized form of Association where all object have their own lifecycle but there is ownership and child
object can not belong to another parent object. Let’s take an example
of Department and teacher. A single teacher can not belong to
multiple departments, but if we delete the department, the teacher object
will not be destroyed. We can think about “has-a” relationship.[Maesh | GeeksWithBlogs]
Rumbaugh's statement is the most telling and Uncle Bob's good advice. As I've said elsewhere, Aggregation is semantically so weak as to offer nothing practically beneficial. It only has one valid corner case (acyclicity of recursive relationships) however few people know and understand that. So you end up having to point out in comments anyway.
I just don't use it. And have never felt any loss. Stick with simple binary associations and focus on what really matters - getting the cardinality and naming right. You'll get far more from that than trying to decide the undecidable association vs. aggregation.
hth.
I tend to use Aggregation to show a relation that is the same as a Composition with one big distinction: the containing class is NOT responsible for the life-cycle of the contained object. Typically, a (non-null) pointer or reference to the object-to-be-contained is passed to the containing class's constructor. The containing object, for the duration of its life-cycle, depends upon the contained object existing. The containing object cannot do its job (fully) without the contained object. This is my interpretation of the "Part/Whole" relationship implied by Aggregation.
This term often gets confused.
Aggregation and composition are some of the types of association. There is
hardly a difference between aggregations and associations during
implementation, and many will skip aggregation relations altogether in
their diagrams with association relation.
You can get the idea from this analogy.
Class:A(person) and Class:B(car) has association relation, if
Class:A has a Class:B declaration, and also Class:B(car) object is not essential to create a Class:A(person) object.
Class:A(car) and Class:B(tyre) has aggregation relation, if
Class:A has a Class:B declaration, and also Class:B(tyre) object is essential to create a Class:A(car) object.
Cheers!
In UML aggregation is under-defined and since they haven't got any clearly defined semantic.
A valid use-case of an aggregation is the encapsulation of a several classes, as stated in "Domain Driven Design" by Eric Evans.
E.g. a car has four wheels.
You might want to calculate the total amount of meters each wheel has driven, for each car.
This calculation is done by the car-entity, since it knows which wheels it has and you don't care which wheels belong to which car.
The car is the aggregation-root for all it's parts, like wheels, and you can't access the parts of a car from outside the aggregation, just the root.
So basically an aggregation encapsulates a set of classes which belong to each other.
They do not mean the same! I can put it in this way:
Association relationship: A class references another class. Actually it shows that a class is related to another class but they
don't necessarily have attributes to show this relationship... e.g
'Teacher' and 'Student' classes, although 'Teacher' class has no
attribute that refer to students, but we do know that in reality a
teacher do have students... And also 'School' class has 'teachers' and
'students' properties that now make those two classes related to each
other.
Aggregation relationship: A class contains another class. But if the container(ClassRoom) is destroyed, the contained(Chair) is not.
Actually the ClassRoom owns the Chair. Aggregation is a more stronger
relationship than the Association relationship.
Here is also a tutorial about it and the whole UML2.0 which explains everything easy and simple, you may find it useful: https://github.com/imalitavakoli/learn-uml2
TIP: Also let me mention that because the Association relationship exists between classes most of the times, we sometimes don't draw it to prevent unnecessary complexity.
Implementation wise there is not much of a difference but conceptually there is big difference: aggregations are used to express a hierarchy. When you work with a hierarchy of components there are certain type of operations you need to have in the root interface:
find subcomponents in the hierarchy
add/remove subcomponents to/from the hierarchy
change common attributes of all components
traverse the hierarchy recursively (Visitor pattern)
reconfigure the hierarchy and the links (associations) between the components
Most of these operations are not needed when dealing with associations.
To add, I would just suggest to download the UML specification from the OMG site: best reference and see p 110.
None indicates that the property has no aggregation semantics.
Shared indicates that the property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
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).
I'm currently studying software engineering patterns and one that we've been given to study is the "historical association pattern" It refers to the historical mapping pattern given in Fowler's "Analysis patterns" book. The example we've been given is as follows:
I've tried looking for information online on how this structure would be implemented but I've found nothing regarding historical mapping associations. What would be a code/pseudo-code example of this structure?
Short answer
This pattern consist simply of using some dates for an association, by the means of an association class.
Full explanation
The diamond in the middle is a ternary association between Employee, Date and Money. The dotted line says that the Salary is the association class and it is also associated with a Date.
The association class would be typically be implemented with tuples/composed classes of Employee, Date, Money and the Salary attributes. The way it is done can be very different: in Java you’d directly refer to the associated objects, whereas in a db you’d have a mix of ids and salary attributes. Much simpler than this impressive diagram.
There are simpler models for that!
This diagram is difficult to read (ternary association), difficult to understand (multiplicity in ternary associations are not obvious to grasp), ambiguous (i.e. is Salary associated with two dates, from the ternary association it represents and from the direct association? or is it just a graphical redundancy?).
It would be much simpler to understand if it would be refactored into a binary association, and if value objects such as Dare would be shown as attributes.
Here I am, with another question about aggregation and association. I wanted to learn some basics of UML, so I started reading "UML distilled" by Martin Fowler. I read both chapters about classes, and there is one thing that I can't fully grasp I think, and that is aggregation vs association. In the book there is this quote:
In the pre-UML days, people were usually rather vague on what was aggregation and what was
association. Whether vague or not, they were always inconsistent with everyone else. As a result,
many modelers think that aggregation is important, although for different reasons. So the UML
included aggregation (Figure 5.3) but with hardly any semantics. As Jim Rumbaugh says, "Think of it
as a modeling placebo" [Rumbaugh, UML Reference].
As I understand from this quote and topics that I read on Stack Overflow it doesn't matter which one of those two relations I use, they mean basically the same, or is there any situation where the usage of aggregation instead of association would be justified and/or I could not change one to the other without changing the "meaning" of a class diagram?
I am asking this, because this book is from 2003 and some things could have changed during those few years.
Maybe this can help you, but i don't think you will find the perfect explanation:
The difference is one of implication. Aggregation denotes whole/part
relationships whereas associations do not. However, there is not
likely to be much difference in the way that the two relationships are
implemented. That is, it would be very difficult to look at the code
and determine whether a particular relationship ought to be
aggregation or association. For this reason, it is pretty safe to
ignore the aggregation relationship altogether. [Robert C. Martin | UML]
And an example for each situation:
a) Association is a relationship where all object have their own
lifecycle and there is no owner. Let’s take an example of Teacher and
Student. Multiple students can associate with a single teacher and
single student can associate with multiple teachers, but there is no
ownership between the objects and both have their own lifecycle. Both
can create and delete independently.
b) Aggregation is a specialized form of Association where all object have their own lifecycle but there is ownership and child
object can not belong to another parent object. Let’s take an example
of Department and teacher. A single teacher can not belong to
multiple departments, but if we delete the department, the teacher object
will not be destroyed. We can think about “has-a” relationship.[Maesh | GeeksWithBlogs]
Rumbaugh's statement is the most telling and Uncle Bob's good advice. As I've said elsewhere, Aggregation is semantically so weak as to offer nothing practically beneficial. It only has one valid corner case (acyclicity of recursive relationships) however few people know and understand that. So you end up having to point out in comments anyway.
I just don't use it. And have never felt any loss. Stick with simple binary associations and focus on what really matters - getting the cardinality and naming right. You'll get far more from that than trying to decide the undecidable association vs. aggregation.
hth.
I tend to use Aggregation to show a relation that is the same as a Composition with one big distinction: the containing class is NOT responsible for the life-cycle of the contained object. Typically, a (non-null) pointer or reference to the object-to-be-contained is passed to the containing class's constructor. The containing object, for the duration of its life-cycle, depends upon the contained object existing. The containing object cannot do its job (fully) without the contained object. This is my interpretation of the "Part/Whole" relationship implied by Aggregation.
This term often gets confused.
Aggregation and composition are some of the types of association. There is
hardly a difference between aggregations and associations during
implementation, and many will skip aggregation relations altogether in
their diagrams with association relation.
You can get the idea from this analogy.
Class:A(person) and Class:B(car) has association relation, if
Class:A has a Class:B declaration, and also Class:B(car) object is not essential to create a Class:A(person) object.
Class:A(car) and Class:B(tyre) has aggregation relation, if
Class:A has a Class:B declaration, and also Class:B(tyre) object is essential to create a Class:A(car) object.
Cheers!
In UML aggregation is under-defined and since they haven't got any clearly defined semantic.
A valid use-case of an aggregation is the encapsulation of a several classes, as stated in "Domain Driven Design" by Eric Evans.
E.g. a car has four wheels.
You might want to calculate the total amount of meters each wheel has driven, for each car.
This calculation is done by the car-entity, since it knows which wheels it has and you don't care which wheels belong to which car.
The car is the aggregation-root for all it's parts, like wheels, and you can't access the parts of a car from outside the aggregation, just the root.
So basically an aggregation encapsulates a set of classes which belong to each other.
They do not mean the same! I can put it in this way:
Association relationship: A class references another class. Actually it shows that a class is related to another class but they
don't necessarily have attributes to show this relationship... e.g
'Teacher' and 'Student' classes, although 'Teacher' class has no
attribute that refer to students, but we do know that in reality a
teacher do have students... And also 'School' class has 'teachers' and
'students' properties that now make those two classes related to each
other.
Aggregation relationship: A class contains another class. But if the container(ClassRoom) is destroyed, the contained(Chair) is not.
Actually the ClassRoom owns the Chair. Aggregation is a more stronger
relationship than the Association relationship.
Here is also a tutorial about it and the whole UML2.0 which explains everything easy and simple, you may find it useful: https://github.com/imalitavakoli/learn-uml2
TIP: Also let me mention that because the Association relationship exists between classes most of the times, we sometimes don't draw it to prevent unnecessary complexity.
Implementation wise there is not much of a difference but conceptually there is big difference: aggregations are used to express a hierarchy. When you work with a hierarchy of components there are certain type of operations you need to have in the root interface:
find subcomponents in the hierarchy
add/remove subcomponents to/from the hierarchy
change common attributes of all components
traverse the hierarchy recursively (Visitor pattern)
reconfigure the hierarchy and the links (associations) between the components
Most of these operations are not needed when dealing with associations.
To add, I would just suggest to download the UML specification from the OMG site: best reference and see p 110.
None indicates that the property has no aggregation semantics.
Shared indicates that the property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
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).
Here I am, with another question about aggregation and association. I wanted to learn some basics of UML, so I started reading "UML distilled" by Martin Fowler. I read both chapters about classes, and there is one thing that I can't fully grasp I think, and that is aggregation vs association. In the book there is this quote:
In the pre-UML days, people were usually rather vague on what was aggregation and what was
association. Whether vague or not, they were always inconsistent with everyone else. As a result,
many modelers think that aggregation is important, although for different reasons. So the UML
included aggregation (Figure 5.3) but with hardly any semantics. As Jim Rumbaugh says, "Think of it
as a modeling placebo" [Rumbaugh, UML Reference].
As I understand from this quote and topics that I read on Stack Overflow it doesn't matter which one of those two relations I use, they mean basically the same, or is there any situation where the usage of aggregation instead of association would be justified and/or I could not change one to the other without changing the "meaning" of a class diagram?
I am asking this, because this book is from 2003 and some things could have changed during those few years.
Maybe this can help you, but i don't think you will find the perfect explanation:
The difference is one of implication. Aggregation denotes whole/part
relationships whereas associations do not. However, there is not
likely to be much difference in the way that the two relationships are
implemented. That is, it would be very difficult to look at the code
and determine whether a particular relationship ought to be
aggregation or association. For this reason, it is pretty safe to
ignore the aggregation relationship altogether. [Robert C. Martin | UML]
And an example for each situation:
a) Association is a relationship where all object have their own
lifecycle and there is no owner. Let’s take an example of Teacher and
Student. Multiple students can associate with a single teacher and
single student can associate with multiple teachers, but there is no
ownership between the objects and both have their own lifecycle. Both
can create and delete independently.
b) Aggregation is a specialized form of Association where all object have their own lifecycle but there is ownership and child
object can not belong to another parent object. Let’s take an example
of Department and teacher. A single teacher can not belong to
multiple departments, but if we delete the department, the teacher object
will not be destroyed. We can think about “has-a” relationship.[Maesh | GeeksWithBlogs]
Rumbaugh's statement is the most telling and Uncle Bob's good advice. As I've said elsewhere, Aggregation is semantically so weak as to offer nothing practically beneficial. It only has one valid corner case (acyclicity of recursive relationships) however few people know and understand that. So you end up having to point out in comments anyway.
I just don't use it. And have never felt any loss. Stick with simple binary associations and focus on what really matters - getting the cardinality and naming right. You'll get far more from that than trying to decide the undecidable association vs. aggregation.
hth.
I tend to use Aggregation to show a relation that is the same as a Composition with one big distinction: the containing class is NOT responsible for the life-cycle of the contained object. Typically, a (non-null) pointer or reference to the object-to-be-contained is passed to the containing class's constructor. The containing object, for the duration of its life-cycle, depends upon the contained object existing. The containing object cannot do its job (fully) without the contained object. This is my interpretation of the "Part/Whole" relationship implied by Aggregation.
This term often gets confused.
Aggregation and composition are some of the types of association. There is
hardly a difference between aggregations and associations during
implementation, and many will skip aggregation relations altogether in
their diagrams with association relation.
You can get the idea from this analogy.
Class:A(person) and Class:B(car) has association relation, if
Class:A has a Class:B declaration, and also Class:B(car) object is not essential to create a Class:A(person) object.
Class:A(car) and Class:B(tyre) has aggregation relation, if
Class:A has a Class:B declaration, and also Class:B(tyre) object is essential to create a Class:A(car) object.
Cheers!
In UML aggregation is under-defined and since they haven't got any clearly defined semantic.
A valid use-case of an aggregation is the encapsulation of a several classes, as stated in "Domain Driven Design" by Eric Evans.
E.g. a car has four wheels.
You might want to calculate the total amount of meters each wheel has driven, for each car.
This calculation is done by the car-entity, since it knows which wheels it has and you don't care which wheels belong to which car.
The car is the aggregation-root for all it's parts, like wheels, and you can't access the parts of a car from outside the aggregation, just the root.
So basically an aggregation encapsulates a set of classes which belong to each other.
They do not mean the same! I can put it in this way:
Association relationship: A class references another class. Actually it shows that a class is related to another class but they
don't necessarily have attributes to show this relationship... e.g
'Teacher' and 'Student' classes, although 'Teacher' class has no
attribute that refer to students, but we do know that in reality a
teacher do have students... And also 'School' class has 'teachers' and
'students' properties that now make those two classes related to each
other.
Aggregation relationship: A class contains another class. But if the container(ClassRoom) is destroyed, the contained(Chair) is not.
Actually the ClassRoom owns the Chair. Aggregation is a more stronger
relationship than the Association relationship.
Here is also a tutorial about it and the whole UML2.0 which explains everything easy and simple, you may find it useful: https://github.com/imalitavakoli/learn-uml2
TIP: Also let me mention that because the Association relationship exists between classes most of the times, we sometimes don't draw it to prevent unnecessary complexity.
Implementation wise there is not much of a difference but conceptually there is big difference: aggregations are used to express a hierarchy. When you work with a hierarchy of components there are certain type of operations you need to have in the root interface:
find subcomponents in the hierarchy
add/remove subcomponents to/from the hierarchy
change common attributes of all components
traverse the hierarchy recursively (Visitor pattern)
reconfigure the hierarchy and the links (associations) between the components
Most of these operations are not needed when dealing with associations.
To add, I would just suggest to download the UML specification from the OMG site: best reference and see p 110.
None indicates that the property has no aggregation semantics.
Shared indicates that the property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
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).
I've always avoided using aggregation because it seems so subjective which one-to-many relationships should be classed as aggregations. But I'm reviewing a model produced by someone else in which aggregations are used for many-to-many relationships (as in: a course consists of several modules, a module may be part of several courses). That strikes me as plain wrong, but I can't find a definitive rule against it. What's the official ruling?
Two things:
Are shared aggregations allowed? According to the UML spec, yes.
Is it useful in practice? Generally I'd say no.
I am not a fan of the UML Aggregation relationship. Whilst ownership is intuitively appealing, it is too subjective practically. I don't use it, and generally don't recommend it be used (although see footnote). Instead, focus on the important questions:
What's the cardinality?
What's the create/delete behaviour?
Why does the relationship exist? (i.e. what business fact/rule is the relationship capturing?
All above can be done with straight associations. If the answer is (a) it's one to many, (b) the 'one' end is responsible for creating/deleting the 'many' end and (c) you really want to, then use the Composite association. Aggregation however doesn't generally improve readability of the model, it adds confusion and detracts from surfacing the underlying domain rules/requirements.
hth.
footnote: there is one scenario where Aggregation does have well-defined semantics and can be useful. Specifically, if you have a recursive relationship, Aggregation says the resultant object structure is acyclic (i.e. a DAG). Downside is relatively few people realise that property - certainly not business domain experts. So you typically have to highlight anyway, e.g. in a comment / constraint.
A good website for this is
http://www.uml-diagrams.org/class-diagrams.html
If you search there for "Shared and Composite Aggregation" you will read, that shared parts can be modeled as aggregations. Even if the composite holding the part will be discarded the parts are allowed to survive.
This seems to make many to many relationships possible. For example sharing a part of a view for several view-components. Why not...
Personally this matches my understanding, that UML is very interpretative.
Let's set the terms. The Aggregation is a metaterm in the UML standard, and means BOTH composition and shared aggregation, simply named shared. To often it is named incorrectly "aggregation". It is BAD, for composition is an aggregation, too. As I understand, you mean "shared".
Again, if we'll look at the UML standards (look for Superstructure documentation there), we'll find, that "Precise semantics of shared aggregation varies by application area and modeler." So, ANY strategy you choose is acceptable. And you even can use different strategy for different projects.
But the shared aggregation IS useful and CAN be used with multiplicities on both sides and even the empty diamond can be on both sides.
The association in UML is an abstraction, that can be realized in any language and in any way, only the realization must be up to the diagram.
Such association, as on the diagram, can be realized as following:
Every instance of Student has a list of courses he is registered to,
and every instance of Courses has a list of registered
students/participants.
But this is not the only way of realization. There could be arrays instead of lists, and even somebody can make it without any normal collection at all - simply using the addresses in memory in C++.
Of course, we could draw two associations, one for student's list of courses and the second for courses' list of students. But thus:
our diagram becomes more complex and, therefore, less readable.
we are describing thoroughly the elementary things that any coder will do anyway in 99% cases.
we are limiting the freedom of coders. And in 1% of cases they'll have to choose between not following the diagram and not coding effectively. It is simply not your job.
So, do as you wish. Forbidden is only to change the strategy during one project and to FORBID others to use their only strategy.