UML Class Relationships

I wo开发者_JAVA技巧uld like to confirm whether I am on the right track when identifying common UML class relationships. For example, is the relationship between:

1 a stackoverflow member and his/her stackoverflow user account categorized as a composition relationship or an aggregation relationship? At first I thought it was an association because this member "has a" account. However on second thought, I am thinking its composition because each "part" (user account) belongs to only one whole (user) at a time, meaning for as long as I am logged into stackoverflow, I have to use this one and only account until I log off. If I log back onto stackoverflow with a different account then its composition again. Do you agree?

2 a database and a person's user account an aggregation relationship? I think so because 1 database (the whole) can store 0...* number of user accounts (the parts) but another database can store the same user accounts.

Finally, can anyone recommend a website that specializes in designing code using UML? Thanks in advance

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 !!