Book a Demo

Author Topic: AggregationKind - client end concept?  (Read 24378 times)

Frank Horn

  • EA User
  • **
  • Posts: 535
  • Karma: +1/-0
    • View Profile
Re: AggregationKind - client end concept?
« Reply #15 on: February 06, 2010, 02:18:36 am »
I agree that for associations there is no notion of directionality in UML 2. But at least implicitly there is a notion of which package an association belongs to, because without assigning each association to a package you could not reprensent a model as valid XMI.

Consequently any UML tool must either offer means to explicitely assign an association to a package, or it must put it somewhere (as EA does).

beginner

  • Guest
Re: AggregationKind - client end concept?
« Reply #16 on: February 06, 2010, 02:38:13 am »
I stumbled upon this same issue some time ago. I wondered where a connector is stored when a XMI is exported with one element in the exported package and the other one in another package. It was Paolo who told me that it's exported in both.

For what you asked before, the wheel manufacturer would just ignore the connectors (though knowing the wheel were used "somewhere") as loose ends.

b.
« Last Edit: February 06, 2010, 02:40:21 am by beginner »

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: AggregationKind - client end concept?
« Reply #17 on: February 06, 2010, 07:02:24 pm »
Quote
I stumbled upon this same issue some time ago. I wondered where a connector is stored when a XMI is exported with one element in the exported package and the other one in another package. It was Paolo who told me that it's exported in both.

For what you asked before, the wheel manufacturer would just ignore the connectors (though knowing the wheel were used "somewhere") as loose ends.

b.
Yes, b, that was my understanding.  But that's not quite the point that Frank was making.  While the connector is exported in both packages, if the AggregationKind is on the source end, then you can work on that end without checking out the other end (from the VCS).  If it's at the target end, it's always in the wrong package...  You need to check out one package to work on the Holonym itself and the other package to work on the Aggregation arc.

Did I get it right Frank?

Paolo
« Last Edit: February 06, 2010, 07:07:24 pm by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Frank Horn

  • EA User
  • **
  • Posts: 535
  • Karma: +1/-0
    • View Profile
Re: AggregationKind - client end concept?
« Reply #18 on: February 07, 2010, 03:29:16 am »
Yes, Paolo, that's what I meant. It's a very common situation, I think, that you have some reusable core libraries (modelled in controlled packages which are rarely being checked out), and for a new project you start modelling classes partly composed of classes defined in core libraries. And of course you don't want the core packages to be checked out for that.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: AggregationKind - client end concept?
« Reply #19 on: April 16, 2010, 04:14:15 pm »
Additional issue found with respect to Association Classes and EAAggregations.  See: Association Classes on EAAggregations.

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