This question already has answers here:
Aggregation vs Composition
(3 answers)
Closed 4 months ago.
I am having trouble finding the right and easiest answer to the above question.
Can you please answer my question.
There are many kind of answers to association Vs Composition Vs Aggregation.
One is plain and one is hollow ;-)
Indeed, the UML specifications let the semantics of aggregation very hollow, that is unspecified. More precisely, page 112 of UML 2.5.1 about ("shared") aggregation and composition ("composite aggregation") says:
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.
Jame Rumbaugh, one of the UML founder even called aggregation a “modeling placebo”, i.e. some feel better when using it even if it does not add any useful information (the exact quote here)
P.S: you will find lots of misinformation on aggregation. Including the most voted question on SO about it. But it's not a question of belief. UML is a standard (even an ISO standard), so always verify that claims are backed by authoritative references
Related
I have the following UML containing the class School which (in my example right now) can only have one TeacherRoom.
My Question now is what is the official notation for this UML or should i remove the <<use>> assosiation because it is obvious?
Obvious because i am saving a instance of TeacherRoom in my School instance?
I would define it like that:
The fact that you have attribute teacherRoom : TeacherRoom in class School implies that School is using TeacherRoom, so the ≪use≫-dependency is not needed.
You also have a composition association to TeacherRoom. This means that, in addition to the attribute, you have a second relationship with TeacherRoom. So you may remove either one.
According to my understanding of section 10.4 of UML 2.5.1 specification, Usage dependency decribes the fact that a given Component requires an Interface or Services.
So I would remove it, as this has nothing to do with the fact that a "School" is composed of "TeacherRoom".
My second point is your "teacherRoom" property which has more or less the same meaning than your composition so I would remove one of them (Property or Composition).
Since you wrote
can only have one [typo corrected by me] TeacherRoom.
you need to add a multiplicity 1 to the right of the association (and as commented and answered to remove the diamond). Also rather than an attribute in School you should use a role name teacherRoom at the association and make it an owned property by adding a dot.
Some additional remarks to composition: Composition is (my personal impression) something that causes more confusion than it actually helps building models (just look for questions asking about its semantic and/or look out for wrong usage of it). Even worse is the shared aggregation which caused (and causes) even more confusion. Now after many editions, UML 2.5 defines that hollow thingy as what it is: nothing. Just read the box on p. 110. So back to the filled one, the composite aggregation. Basically it's about lifetime of objects, so whether there's an owner of an object who is responsible of its lifetime. When you make a car composed of its wheels, that's obviously not right since the wheel will live on without being attached to the car. Only the car is no longer a car. But that will be expressed by attaching a multiplicity of 4 to the wheel. Any car with not exactly 4 wheels is no longer a car. No composition at all.
So where can you use composite aggregation then? I have only 2 applications in mind. One is for storage managent. Something that had been important in the early days of computing when dinosaurs like me fought along with hard disks at cupboard size that had 20 Megabytes! Only a few border cases still need indication for memory management. The second case would be security. Indication that something has to be deleted along with its parent. And that's still valid. But then this is the only real application for composite aggregation.
This question already has answers here:
UML aggregation vs association
(8 answers)
Closed 4 years ago.
is there any why to know which one of two types of interaction
mentioned[aggregation or association] should be used in class diagram
?
is it even matter to specify which one to use in a certain interaction ?
Assosiation
The most abstract way to describe static relationship between classes is using the Association link, which simply states that there is some kind of a link or a dependency between two classes or more.
Aggregation
In cases where there’s a part-of relationship between ClassA (whole) and ClassB (part), we can be more specific and use the aggregation link instead of the association link, highlighting that the same ClassB instance can also be aggregated by other classes in the application (therefore aggregation is also known as shared association).
If you want to read detailed description then check this LINK
I am confused about the dot operator in Alloy (the formal modelling language). Sometimes it seems that when I perform the relational join I get the expected output however sometimes I feel it is being used just to access a field of the sig and the relational join would not work/just give an empty set.
Thanks,
Kevin
This question has already been answered here: Relational Join and Operators in Alloy
If, after reading the given links, you still have difficulties to understand the way dot joins work on a particular example, please edit your question to include the said example so that we can help you clarify their behavior.
I was given a special task to learn and discuss about UML at work. I have a little background about the topic, though I'm not sure what area should I give more priority since UML has now multiple versions. Should I stick with the the UML first version and give an overview for the UML 2 instead? or should I focus more on the UML 2 since it's the latest version? I'm confuse since I'm not familiar with the difference of the two versions.
I need advise regarding the matter. Thank you in advance. Pardon if this question is irrelevant in this site.
It might be practically difficult to restrain to UML 1 just for the following reason: Nearly all available tools for drawing diagrams implement UML 2 since long time ago. So, each time when drawing some construct, you would manually have to check whether it was already available in UML 1.
The step from 1 to 2 was in a large part motivated by the software engineering hype named MDA (Model Driven Architecture) some 10..15 years ago. This was about generating software directly from the model. To support this, all model elements got defined via some formal semantics. Also, some model and diagram types got enhanced. Sequence diagrams were enriched to control structures to express control flows. Component and deployment diagrams got enhanced.
Now, apart from suggesting that it won't make much sense to go back to UML 1, I read from your question that you need to set priorities. That makes sense, as the definition of UML (1 as well as) 2 is quite lengthy, and you don't want to study every detail of it. So here are a few hints:
With object oriented technology everywhere around, class modeling is the central notion. So you should be familiar with classes, associations, aggregations, composition, inheritance, attributes, operations and their parameters and results, visibility of methods and attributes, abstract classes and methods, and interfaces.
Objects of a class change their states by application of their operations. A central, and sometime underestimated, type of model therefore is state modeling. Here, UML offers two partly redundant model and diagram types: State and activity models. You should get familiar with at least one of them -- switching to the other should then be not too difficult.
Most users of UML are quite fond of use case modeling. I'm not, as those use cases tend to lack either significance (if you constrain to naming use cases and actors) or structure (if you start documenting system data and functionality with your use cases). But the rest of the world will only accept you as an UML expert if you know them, so you won't be able to avoid them. Just before using them extensively, think about how to reach the DRY (don't repeat yourself) principle when describing a system via use cases.
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.