UML Class Relationships

人盡茶涼 提交于 2019-12-01 09:11:08

A stackoverflow member and his/her stackoverflow user account categorized as a composition relationship or an aggregation relationship ?

Well, Let's see the following diagram

  • Aggregation

Transplant is possible

If i miss some Finger, so other Hand can receive my missing Finger


  • Composition

Transplant is impossible

If i miss some Finger, so no other Hand can receive my missing Finger

Both Aggregation and Composition, A Finger (The part) has its lifecycle bound to that of its owning Entity instance (if i miss my Hand, so its Finger will be missed) So, If i remove my Stackoverflow Member, its UserAccount will be removed.

Back to your question: Your UserAccount, although has its lifecycle bound to its Stackoverflow Member, if missed, can be assigned to another Stackoverflow Member ??? I do not think so. So, it is Composition

The UML spec is incoherent regarding the aggregation vs. composition definitions. They are not properly defined, as has been shown by several authors (Henderson-Sellers among others). I suggest you don't waste your time trying to determine whether something in your mind maps best to one or the other. There is no right answer. :-)

Myself, I often use an abstract whole/part relationship to model wholes and parts. Semantics about binding, lifetime and exclusivity can be given by pseudocode or annotations. There are so many different cases and scenarios that trying to foresee all the possibilities beforehand is not worth it. Edit: this approach was proposed by Henderson-Sellers and myself to OMG during the review round of an earlier version of UML, a few years ago. Unfortunately, it didn't make it. :-)

Even if UML were coherent, there are not right or wrong models; some models are useful and some are not. You create models depending on the purpose you pursue.

The best book for UML is Martin Fowler's "UML Distilled". It's in its third edition, so it's stood the test of time. It has the rare virtue of being packed with good information and remaining thin.

It has a good discussion of aggregation versus association.

Martin Fowler also has some good thoughts about the different UML camps: MDA versus "sketchers". I'm firmly in the sketchers camp: don't get too hung up treating UML as if it produced engineering drawings. It's a communication device, nothing more.

Aggregation: weak 'has a'
Composition: strong 'has a'

The convention that I use to remember which is which is that an composite relationship means that contained instances can't exist without it's enclosing type whereas in an aggregate relationship, objects can exist without the enclosing type As an example:

  • A Car 'has' 4.Wheels (aggregation)

  • A Cars Vehicle Identity Number is 'part of' a Car (composition)

(Rubbish example, but the best I could bring to mind :)

This additional information is only available in UML because you can not for example see the difference in the Java code between aggregation and composition. So I don't agree that aggregation versus composition is not a brilliant idea because this information is important for project quality !!

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!