Author Topic: Composition, Aggregation, EAUML and SPEM  (Read 2649 times)

Modesto Vega

  • EA User
  • **
  • Posts: 370
  • Karma: +7/-4
    • View Profile
Composition, Aggregation, EAUML and SPEM
« on: November 20, 2019, 04:06:48 am »
Could somebody remind me why there is no native Composition relationship in Sparx EA (v13) and what is the SPEM profile which appears to be a flavour of UML with a Composition relationship?

qwerty

  • EA Guru
  • *****
  • Posts: 10625
  • Karma: +233/-194
  • I'm no guru at all
    • View Profile
Re: Composition, Aggregation, EAUML and SPEM
« Reply #1 on: November 20, 2019, 08:16:51 am »
Probably because that connector has gone in later UML versions and been replaced by associations with properties on one end.

SPEM? I see all those profiles as SPAM.

q.

KP

  • EA Administrator
  • EA Expert
  • *****
  • Posts: 2659
  • Karma: +41/-2
    • View Profile
Re: Composition, Aggregation, EAUML and SPEM
« Reply #2 on: November 20, 2019, 09:04:10 am »
SPEM = Software & Systems Process Engineering Meta-Model

There will be a specification on the OMG website.
The Sparx Team
support@sparxsystems.com

Modesto Vega

  • EA User
  • **
  • Posts: 370
  • Karma: +7/-4
    • View Profile
Re: Composition, Aggregation, EAUML and SPEM
« Reply #3 on: November 20, 2019, 08:51:18 pm »
Probably because that connector has gone in later UML versions and been replaced by associations with properties on one end.
It hasn't, it is still there but keep reading.

There will be a specification on the OMG website.
I wish you had not suggested checking the specification, which I have done. From page 187 of https://www.omg.org/spec/UML/2.5.1/PDF

Quote
Figure 11.5 shows two possible views of the Car Class. In subfigure (i), Car is shown as having a composition Association with role name rear to a class Wheel and an Association with role name e to a class Engine. In subfigure (ii), the same is specified. However, in addition, in subfigure (ii) it is specified that rear and e belong to the internal structure of the class Car. This allows specification of detail that holds only for instances of the Wheel and Engine classes within the context of the class Car, but which will not hold for wheels and engines in general. For example, subfigure (i) specifies that any instance of class Engine can be linked to an arbitrary number of instances of class Wheel. Subfigure (ii), however, specifies that within the context of class Car, the instance playing the role of e may only be connected to two instances playing the role of rear. In addition, the instances playing the e and rear roles may only be linked if they are roles of the same instance of class Car. In other words, subfigure (ii) asserts additional constraints on the instances
of the classes Wheel and Engine, when they are playing the respective roles within an instance of class Car. These constraints are not true for instances of Wheel and Engine in general. Other wheels and engines may be arbitrarily linked as specified in subfigure (i).

From page 200
Quote
A binary Association may represent a composite aggregation (i.e., a whole/part relationship). Composition is represented by the isComposite attribute on the part end of the Association being set to true. See the semantics of composition in 9.5.3. An end Property of an Association may only be marked as a shared or composite aggregation if the Association is binary and the other end is not marked as a shared or composite aggregation.

And, then, to Sparx EA (both V13 and v15), in both cases I can represent aggregations and compositions in 2 ways:
  • By using an Association and setting the Aggregation property of one of the 2 ends to Composite (so far I can deal with this and explains why I cannot change the type of an existing connector/relationship from something else to Composition
  • However, Sparx EA has a native relationship called Aggregation which can be set to "Aggregation to Whole", "Aggregation to Part", "Composition to Whole", and "Composition to Part". The way this 4 variations is achieve is by setting the Aggregation property accordingly on one of the 2 ends
This is when I get confused because Aggregation as a stand-alone relationship does not appear to be mentioned anywhere in the specification.

Edit 20 November 2019 10:10 - A subtle difference is that to set an Association to an aggregate association, the "shared" aggregation property needs to be specified. Whilst the equivalent for the Aggregation native relationship is "aggregation".
« Last Edit: November 20, 2019, 09:12:27 pm by Modesto Vega »

qwerty

  • EA Guru
  • *****
  • Posts: 10625
  • Karma: +233/-194
  • I'm no guru at all
    • View Profile
Re: Composition, Aggregation, EAUML and SPEM
« Reply #4 on: November 20, 2019, 09:16:41 pm »
As said the composition thingy has changed in the UML specs. So EA keeps the legacy format. They are very conservative (just look on their database which hasn't changed much since 2003 or so).

q.

P.S. I looked into the UML 1.5 specs and even there is was mentioned as a property of an association end. So It's probably some heritage from even before (1.0 which I don't have). A couple of years ago Sparx removed the "Composition" relation but did not really deprecate it (the Sparxians just don't seem to know what that is). As for me: EA is EA and no user will ever be able to change it in a non-Sparxian way. Fate that is...
« Last Edit: November 20, 2019, 09:23:21 pm by qwerty »

Modesto Vega

  • EA User
  • **
  • Posts: 370
  • Karma: +7/-4
    • View Profile
Re: Composition, Aggregation, EAUML and SPEM
« Reply #5 on: November 21, 2019, 07:00:28 pm »
Well to paraphrase a regular contributor: as long as they keep it consistently inconsistent, I guess it is fine. Having said this, there is a limit to how much legacy can be kept without essentially making the tool produce something which is semantically incorrect/questionable.
« Last Edit: November 22, 2019, 05:34:39 am by Modesto Vega »

qwerty

  • EA Guru
  • *****
  • Posts: 10625
  • Karma: +233/-194
  • I'm no guru at all
    • View Profile
Re: Composition, Aggregation, EAUML and SPEM
« Reply #6 on: November 22, 2019, 01:24:18 am »
That goes without an additional comment ;-)

q.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 6867
  • Karma: +147/-104
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: Composition, Aggregation, EAUML and SPEM
« Reply #7 on: November 22, 2019, 10:37:02 am »
Well to paraphrase a regular contributor: as long as they keep it consistently inconsistent, I guess it is fine. Having said this, there is a limit to how much legacy can be kept without essentially making the tool produce something which is semantically incorrect/questionable.
Well, one benefit I've found of EA's self-inconsistency is that is EA stops me doing what I need to do via one path, I can usually find another path that WILL let me do it!

Your last statement exposes the fallacy of retaining the degree of legacy support we currently find in EA, the semantics of the kinds of models that are currently being attempted have moved on.  The discussion on instances is a case in point.

Nevertheless, it is theoretically possible to create a semantically valid output, by hiding the inconsistent parts.

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