Association + Multiplicity vs. Aggregation vs. Composition
Joined: Dec 16, 2002
Hi all, I do not want to just ask what is the difference between a) association plus multiplicity, b) aggregation and c) composition? The chance to get an answer would be too low. Timber Lee allready had asked in another topic:
Originally posted by Timber Lee (in another topic): What structure can express aggregation and composition in java program?
I think that it is worth to make it an extra topic. Fowler had the nice example of modelling a car, having 1 motor and 4 wheels. This is, what we would call a hmmmmmm - he sais aggregation, maybe association - but I would say a composition, because removing the motor or at least one wheel the car will no longer be a car, in a functional sense. In the following diagrams please note the legend: ------> (solid line) <> (open diamond) and <#> (filled diamond) Class rectangles are left away because too hard to be edit with ASCII characters.
Aggregation: What is the (semantic?) difference: --------> vs. <>------>
-------->(0..*) vs. <>------>
-------->(0..*) vs. <>------>(0..*)
Is <>------> allways to be thought as implemented as a kind of array (vector, list, ...)?
How would you model a car, having 1 motor and 4 wheels?: (and why!)
Car: ---->1 Motor ---->4 Wheel vs. Car: <>---->1 Motor <>---->4 Wheel vs. Car: <#>---->1 Motor <#>---->4 Wheel Composition, composite, ...: Sun SL500 "J2EE Patterns", vol.1, p.6-6, says: "Structural class patterns use inheritance to organize structure, with fixed relationships at compile time. Structural object patterns, on the other hand, use composition to organize structure. The relationships in a structural object pattern might be fixed at compile time or changeable at runtime." But as long as I do not feel firm with the definition and notation of composition, these well sounding sentences make no sense to me. M.Hitz et al. has quite another approach to composition in "UML@Work", p.35: There are 6 composition "arrows" leading from 1 main class to 6 part classes. That is what I intuitively would call a notation of composition. Would you call all these 1+6 classes together be the composition (to be honest, M.Hitz leaves this open)? Or would you call each of the <#>----> "arrows" one composition each? Any understandable (and correct) definition in literature, any definitive link? * * * * * Before I decided to post this topic, I was pretty down about the lack of precision in UML - it is widely an uggly conglomerate of not precisely defined words. I did read from Martin Fowler and Kendall Scott in "UML distilled", that he allways tryed to avoid the word "aggregation" and used "association" instead. Is it this what made him fameous?. And then I remembered one of my first projects, nearly two decades ago: I had just signed for a new employment and was able to take my vacancies before. My new boss asked me, wether I could try to learn PL/I besides diving in Cuba (I was a Pascal programmer at that time). I was very surprised, but he told me how: You are used to program in Pascal, right? So decide what features of the accoustomed language you usually use and want to use in the new language. Then concentrate on how to solve the old Pascal patterns in PL/I. Do not care about the rest of PL/I as long as you do not need a new feature or pattern. So I did and enjoyed the sun in Cuba, and spent just a few hours on "learning" PL/I, i.e. on scribbling some transforming patterns for "array / for ==> ...", "file / while ==> ...". And this worked wunderfull. * * * * * How could I bring this "life pattern" to my today-situation? Up to now I do not need agregation and composition notations (even if I might use their principles). Or will I need them for the exam? Or can I just leave them off? What will there be what I can not read or model without aggregation and composition notation? Thomas.
Wheel on or off a car is still a wheel. <> Arm off a man is no longer an arm ( barring a medical miracle ). <#>
I was pretty down about the lack of precision in UML - it is widely an uggly conglomerate of not precisely defined words
You would be more down if we still had to deal with all the modelling languages UML combined. While UML is imprecise, you have over time gained a knowledge of the speaker. So when you or your architect draws a <> that means something different than <#> to those that know the author. Whether wheel and car are drawn with association, composition, or aggregation one knows that wheel and car are classes that interact. So wheels are not an array of string arrays that are a memeber of car.
Is it this what made him fameous?.
No, that stuff Booch wrote was so hard to read, that Fowler seemed so very great. I guess it is because we could undertand what he said. Booch just put us to sleep.
How could I bring this "life pattern" to my today-situation?
It used to be we drew flow charts, activity diagrams are OO and a lot sexier. :roll: And be careful not to call a reference a pointer or you'll be branded an idiot.
Up to now I do not need agregation and composition notations (even if I might use their principles).
The projects are larger and more complicated than they used to be. UML is supposed to be a standard tool that the team can use to draw pictures to give ideas to everybody on the team. Somebody who knows what the stakeholders want built draws up a plan. The architect then passes this onto the developers who now quickly have an idea of what they plan to build. Coders know they have to build classes for every square on the class diagram. They know what the responsibilties of their class are and where they can get the other things they need. DBAs look at the drawing and start seeing tables and DDL. Manager can say when I have a problem with the Custoemr Class that's Taeger's baby. While the associations are an important concept no association is important too. There's no association between orderLine and Customer ( UML Distilled Figure 4.3 ) therefore we know that order line is not going to do myCust.getName().. But orderLine is capable of if ( myOrder.isPrePaid() )... Now if you have to change Customer you know no change should be needed to orderline. I found Applying UML and Patterns by Craig Larman a much better resource than UML Distilled.
Joined: Dec 16, 2002
Hi Rufus, thank you for your kind assistance in dark times.
Originally posted by Rufus BugleWeed: Wheel on or off a car is still a wheel. <>
That is what I wunder and up to now can not agree to be general or even the normal case. For a car parts seller this is true, ok. He has his bill of material in the computer and can tell the customer which wheel to buy when one has been broken. There is no additional semantic about those objects, therefore it is no composition but an aggregation. On the other hand, imagine a modern car gathering signals from the four wheels and sending commands (break...) to the wheels. In this case I consider the car and its four wheels to be a composition. Like in your example of the arm: if the car is scraped then the wheels are scraped with it and do not exist anymore in terms of our use case. Buying one of these scraped wheels for reparing another old car is another use case not concerned by the first use case. That is the reason why I consider a car a composition and not just an aggregation, except if it is just a bill of material, in this case I would call it an aggregation. But must a car be modelled as a composition then or is this just a "nice to have"? And in the exam?
Originally posted by Rufus BugleWeed: I found Applying UML and Patterns by Craig Larman a much better resource than UML Distilled.
Ok, I have ordered it.
I would have appreciated someone to try to answer my simple "What is the (semantic?) difference:... vs. ..." questions about multiplicity and aggregation graph, sounding much simpler as many of the mock questions. Thomas.
subject: Association + Multiplicity vs. Aggregation vs. Composition