Book a Demo

Author Topic: UML: Aggregate versus Generalize  (Read 7263 times)

Lode

  • EA Novice
  • *
  • Posts: 8
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
UML: Aggregate versus Generalize
« on: October 10, 2007, 11:26:53 pm »
Code 1:

Code: [Select]

class Wizard
{
 public:
 void castSpell();
}

class Man : public Wizard
{
 
}


Code 2:

Code: [Select]

class Magick
{
 public:
 void castSpell()
}

class Man
{
 private:
 Magick magick;

 public:
 void castSpell()
 {
 magick.castSpell();
 }
}


In both cases, Man is a class that has the ability to cast a spell. In the first case, because man IS a wizard, in the second case because man HAS magick.

If I draw the first in a UML class diagram, then man inherits from Wizard so in EA, I then draw a "Generalize" connector from Man to Wizard. The "symbol" of the connector (a little triangle) is at the Wizard class.

In the second case, I draw a "Aggregate" connector from Magick to Man (instead of from Man to Magick). Now the "symbol" of the connector (a little diamond) is near Man!

So at an "is" relationship (Man is X), the connector symbol is at the X, while for a "has" relationship (Man has X), the connector symbol is instead at the side of Man.

I've always found this somewhat confusing, because "has" and "is" relationships are somewhat analogeous so I'd have expected an analogeous notation, but instead it's an opposite notation.

Also, sometimes a solution to the same problem can be done both with an is and a has relationship (such as the casting a spell above), but when drawing it in a UML diagram, the direction of the connectors has to be reversed for both.

And also, in all cases, it's MAN that depends on the other class (wizard or magick). But for the connectors, in the one case the symbol is at the side of that what depends, in the other case it's at the side of what is being depended on. That's also confusing to me.

What is the explanation why for such a has relationship, a connector is used where the symbol is near Man instead of at Magick? Am I thinking in a wrong way?

Thanks :)
« Last Edit: October 10, 2007, 11:30:09 pm by Lode »

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: UML: Aggregate versus Generalize
« Reply #1 on: October 11, 2007, 12:23:41 am »
Hi Lode,

I can't answer in detail at this time, perhaps others can do that.  However, in summary:

1) There are problems with the EA Aggregation relationships - if you look for postings by me with (I think - no time) keywords "Aggregation vs Association" it will describe some issues.  Your confusion there is caused by the implementation.

2) You should also lookup postings by me on the subject of meronymy (the whole-part relationship) which is what aggregation is about

3) IS_A (Not IS - which is an identity function on two items) is not the same as HAS_A - they are not analogous...  Postings by myself and others in the UML category should clarify things.

4) In English we often, unfortunately, use the term "has" very loosely - as, perhaps, in this case.  Being able to use the term "has" in English doesn't necessarily imply aggregation (the diamonds).  In my view there is no aggregation between Man and Magick in the second case.

(with the caveat that this was a bit rushed...)
HTH,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

KP

  • EA Administrator
  • EA Expert
  • *****
  • Posts: 2919
  • Karma: +55/-3
    • View Profile
Re: UML: Aggregate versus Generalize
« Reply #2 on: October 11, 2007, 03:23:19 pm »
Quote
Your confusion there is caused by the implementation.

I read the OP as a comment on the lack of consistency in UML, not EA: a relationship of the type "X verb Y" should have the arrowhead at the "Y" end. To which I would answer: consider the aggregation diamond as a decoration not an arrowhead and it fits that pattern.
The Sparx Team
[email protected]

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: UML: Aggregate versus Generalize
« Reply #3 on: October 11, 2007, 05:26:46 pm »
Quote
I read the OP as a comment on the lack of consistency in UML, not EA: a relationship of the type "X verb Y" should have the arrowhead at the "Y" end. To which I would answer: consider the aggregation diamond as a decoration not an arrowhead and it fits that pattern.
Point taken Neil, but once Lode gets over that point, he'll hit mine (probably)...

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

vidafo

  • EA Novice
  • *
  • Posts: 17
  • Karma: +0/-0
    • View Profile
Re: UML: Aggregate versus Generalize
« Reply #4 on: October 15, 2007, 06:12:09 am »
Hello

My understanding of aggregation is "consists of parts" or "contains parts".


I think the example Code 2 has nothing to do with aggregation but with the delegate pattern which is common to avoid inheritance.


btw shouldn't this post be in the UML thread?

Daniele

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: UML: Aggregate versus Generalize
« Reply #5 on: October 16, 2007, 01:38:38 am »
Quote
btw shouldn't this post be in the UML thread?

Daniele
Yes... but we poor users have no ability to move it... :(

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: UML: Aggregate versus Generalize
« Reply #6 on: February 02, 2010, 11:43:24 am »
See: Aggregation and Association proposal for a proposal to provide consistent processing and rendering of EA Aggregations, Compositions and Associations.

HTH,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13523
  • Karma: +574/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: UML: Aggregate versus Generalize
« Reply #7 on: February 02, 2010, 06:01:04 pm »
Lode,

If model the relation completely you'll find that you have an arrowhead on the Magic element as well since that end is clearly the navigable end.
According to a popular convention the arrow head on the Magic side also indicates the dependency direction between Man and Magic, meaning that Man depends on Magic.
If we forget about wether or not the aggregationKind indicator (diamond) should be there or not, is becomes a lot more consistent.
Both relations point from Man to (Magic or Wizard).

Geert

BTW. I think the point of Daniele is valid. The solution with the Man->Magic looks like an implementation of the Strategy or Bridge design pattern.