UML Class Relationships

views:

351

answers:

+1 Q:

UML Class Relationships

Hi, I would 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

+3 A:

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.

CesarGon 2010-03-14 01:28:56

Thanks for your reply CesarGon. Yeah I did read in a UML book that one should not lose any sleep over whether to use Aggregation or composition - the book just said default to aggregation, and change it latter, i forgot about that. This whole designing before coding is really new to me. One thing though, what do you mean by abstract whole/part relationship? Do you mean you create an abstract class and have specialized classes inherit from it? Or is it more than that? I googled it but did not find a clear definition.Thanks again

01010011 2010-03-14 01:42:02

Much simpler than that. I mean just use a "white diamond" shape meaning "whole/part relationship", without caring whether it's an aggregation or a composition. After all, "aggregation" and "composition" are meaningless mumbo-jumbo in UML. They lack a solid definition and as soon as you try to formalise their meanings, you find serious inconsistencies. So stick with something simpler, like "whole/part", which is enough to capture the semantics of most situations you will find around you. As I said, you can complete this with annotations where necessary for extra details.

CesarGon 2010-03-14 01:51:45

Ok great, thanks. One more thing, do you know of any sites that focus on designing code or sites for people who like to look at well designed code or code designs? I think this will help me a lot if I can read how much more experienced people than me code

01010011 2010-03-14 06:35:37

No, I don't. Sorry. In general, diagrams in books and web sites suck great time (point in case, the diagrams provided by the accepted answer to this question are wrong; see my comment). UML is so user-unfriendly (in both its semiotics and the way it is documented) that people tend to use it incorrectly very often. Sorry I can't help you here. In any case, I emphasise the point I made in my answer: don't waste your time tryind to find *correct* models; they don't exist. Some models are useful and some are not.

CesarGon 2010-03-14 12:37:19

@CesarGon, is there a more precise alternative to UML inthe works?

01010011 2010-03-14 16:31:13

There is the Precise UML (pUML) Group (http://www.cs.york.ac.uk/puml) and the Executable UML (http://en.wikipedia.org/wiki/Executable_UML) work being done by Steve Mellor and others. As you can imagine, both are based on UML.

CesarGon 2010-03-14 21:06:25

@CesarGon, ok thanks

01010011 2010-03-15 07:06:41

+1 A:

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.

duffymo 2010-03-14 01:51:34

Still, it doesn't explain aggregations and compositions. :-)

CesarGon 2010-03-14 01:53:48

Are you saying that software *engineers* are supposed to communicate with a tool that is *unable* to produce engineering artefacts? :-)

CesarGon 2010-03-14 01:58:32

Fowler does explain the difference between aggregation and associations, which are two types of composition. I would give you the page number, but my copy is at work As for "UML unable to produce engineering artifacts" - that's exactly what I'm saying. UML is not on a par with engineering drawings. You cannot throw a UML spec on a developer's desk, walk away, and expect a working system to come out. But you can do exactly that if you give a machinist a engineering drawing of a mechanical part.

duffymo 2010-03-14 02:16:55

That is incorrect. Aggregation and Composition are subtypes of Association. In particular, they add extra semantics to what a "vanilla" association means. The problem with the UML spec is that it does a very poor job at explaining those semantics. I don't have Fowler's book with me, but it may be wrong or oudated. Please see http://stackoverflow.com/questions/1138247/uml-notation-aggregations-compositions-vs-vanilla-associations

CesarGon 2010-03-14 02:26:34

I don't disagree with you on the fact that UML is useless as a tool for precise communication between engineers, by the way. :-) The MDA guys seem to be trying to sell it as such, but clearly it doesn't work.

CesarGon 2010-03-14 02:29:48

Personally, I don't think it much matters. The important idea is cascading delete behavior: when a parent has a child, and you eliminate the parent, does the child live on its own or disappear? Fowler's book does a very good job of explaining it; he doesn't agree with your choice of words. It's always been inheritance versus composition in my mind, with association or aggregation as subtypes of composition. Inheritance mean IS-A, composition means HAS-A. I've never read it as inheritance versus association anywhere.

duffymo 2010-03-14 02:32:23

I only say that because I was a mechanical engineer, so I actually know something about engineering drawings. I can tell you that UML does not compare and never will. MDA has been trying for a long time. As you've pointed out, it is not working.

duffymo 2010-03-14 02:33:27

I suggest you have a look at the UML metamodel then. :-)

CesarGon 2010-03-14 02:33:58

And yes, I totally agree with you about mechanical drawings. UML is lightyears away from the precision and accuracy that they provide.

CesarGon 2010-03-14 02:34:35

Honestly, I don't think UML is worth the effort. Boxes and arrows on a whiteboard are sufficient. Nobody that I work with really gives a damn about splitting hairs on meta models.

duffymo 2010-03-14 03:10:47

Well, nice to meet you! You know somebody who cares about metamodels now. :-)

CesarGon 2010-03-14 03:11:51

You don't have to end every comment with a smiley.

duffymo 2010-03-14 03:13:13

And I'll bet that correcting teammates who "mistakenly" use the wrong meta-model terminology (according to you) is endearing. The real point is expressing the correct behavior in software. Arguing over its name hardly seems productive. Even people like Martin Fowler and Peter Coad don't have a universally agreed terminology.

duffymo 2010-03-14 03:17:17

Thanks duffymo for your reply, book recommendation and recommending Martin Fowler. I spent some time reading his "Patterns in Enterprise Software" page hmmmmmm... boy do I have a lot to learn still. I just started reading Design Patterns by the Gang of Four so I guess this is a good place to start, patterns wise. Anyway, I'll definately take your advice and not get hung up on UML, but I am finally beginning to understand it so I'll just apply what I know and just change it afterwards.

01010011 2010-03-14 07:56:25

@duffymo: Sorry if my smileys upset you, but they are a part of the way I write. Regarding your comment on correcting people on their usage of terminology, I think that's the point. You were talking before about communication: miscommunication occurs when people use the wrong terms or map terms to concepts in a loose and vague way. My intention (and my efforts here in SO) is about helping people do a better job at being precise with words, because that increases the quality of the communication. People who disregard the "therory behind" as not importante are missing a lot. :-)

CesarGon 2010-03-14 14:22:46

@duffymo: Furthermore, I have personally discussed UML issues with Fowler at a couple of conferences, and I can assure you that he would agree with me on my definitions of association and whole/part relationship. Nobody in modelling would say that "association is a type of composition". Sorry if I sound pedantic, but letting these things go uncommented cause lots of confusion to less experienced people.

CesarGon 2010-03-14 14:25:43

@CesarGon - your smileys don't upset me. I think they do detract from the way you write, just as people who are imprecise about words are missing a lot. I do agree with the need to be precise, but I also think that sometimes those efforts might not be that well received. It's up to each of us to decide when it's worthwhile to push a point and when to let it go.

duffymo 2010-03-14 14:40:12

@CesarGon - I'm not convinced by your alleged conversation with Fowler. I'll cite this URL http://accu.org/index.php/journals/551: "...There are a few problems with at least one of the above examples of aggregation. As Martin Fowler states [Fowler], there is dispute at this level even amongst the gurus. A company and its workforce is either an aggregation or just a simple association, depending upon who you listen to..." Note the use of the words "association" and "aggregation", just as I'm using them. And, most importantly, "no agreement". That's my point here.

duffymo 2010-03-14 14:42:52

@duffymo: Of course there is disagreement; this is a hot area in research right now. Certain things are pretty clear, though, and "association is a type of composition" is clearly incorrect, no matter how much you stretch the definitions of "association" or "composition". It is the other way around. I respect Fowler a lot and I am sure he would agree. For crystal-clear concepts in this area, I suggest "Improving the UML Metamodel to Rigorously Specify Aggregation and Composition" by Bruel, Henderson-Sellers et al., or "What is This Thing Called Aggregation?" by Henderson-Sellers and Barbier.

CesarGon 2010-03-14 21:14:29

"Hot area of research"? Over a naming convention? You're overstating it now. And you're also contradicting yourself - it's either a hot area of research or "pretty clear", but not both. I respect Fowler too, but I'm not as sure that he'll agree with you. Your debating skills need as much work as your UML.

duffymo 2010-03-14 22:22:43

+2 A:

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

kiwicptn 2010-03-14 02:19:34

Yes, also Aggregation: "owns a" and "A part may belong to more than one whole". Composition: "is a part of" and "each part belongs to one whole at a time and when the whole is destroyed, the part is also destroyed"

01010011 2010-03-14 08:05:12

+1 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 :)

Paul Jenkins 2010-03-14 03:43:58

It looks like you've got composition and aggregation backwards. When a composite is discarded, so are its parts (but see the conversation between CesarGon and duffymo).

outis 2010-03-14 04:52:17

Thanks for your reply Paul Jenkins. I'm new to this but I thought a "has a" relationship referred to association; "owns a" relationship referred to aggregation; "is a part of" relationship referred to composition? In other words: aggregation = credit card (aggregate) PIN (a part) and PIN can be reused in debit card and other ATM cards; composition = when whole is destroyed, part is also destroyed.

01010011 2010-03-14 06:57:47

"...the convention that I use to remember..." but obviously not very well. Sorry, it was late. Edited to correct and thanks for the catch :-)

Paul Jenkins 2010-03-14 11:02:18

+3 A:

Hi,

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

Aggregation

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

Composition

Transplant is impossible

Composition

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

regards,

Arthur Ronald F D Garcia 2010-03-14 04:53:03

01010011 2010-03-14 07:41:17

@Arthur, one more thing: do you know of any sites where aspiring programmers can visit and read well written code? I'm particularly interested in C++. I think it will be a huge education to read code written by experts.

01010011 2010-03-14 08:00:40

-1 Your "diamonds" are on the wrong side! The "diamond" shape indicates the "whole" class rather than the part. In your examples, that would be Hand, not Finger.

CesarGon 2010-03-14 12:34:09

@CesarGon You are right. Sorry my mistake. I will fix it.

Arthur Ronald F D Garcia 2010-03-14 13:07:49

@CesarGon Can you review your vote ?

Arthur Ronald F D Garcia 2010-03-14 13:19:02

@01010011 Although i am not a C++ developer, i have a good knowledge in Object-To-Relational mapping. Some of its knowledge has been provided through Java Persistence with Hibernate book. I do know any resources in C++. Sorry

Arthur Ronald F D Garcia 2010-03-14 13:22:38

@Arthur: Of course. No problem. :-)

CesarGon 2010-03-14 14:18:18

@Arthur, ok thanks

01010011 2010-03-14 16:33:46

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

2010-03-17 09:45:48

ansaurus

tags:

views:

answers:

UML Class Relationships

related questions