Aggregation vs Association in EA Code Engineering

[EricP]

Consider the following code:

struct SCMElements
{
  float swVersionNumber;
  time_t swCompileTime;
  unsigned char theStateOf;
  unsigned char reasonFailurePOST;
  unsigned char reasonSystemNotReady;
  unsigned char autoManualTubeControls;
};

union SysControllerMsg
{
  struct SCMElements theSCMElements;
  char theSysControllerMsg[ sizeof( struct SCMElements ) ];
};

I would consider the relationship between SysControllerMsg and SCMElements to be an aggregation relationship, in that SysControllerMsg "has an" object of type SCMElements.

However, when I run that code through EA's "import from source file", it is modeled as a directed association whereby the SysControllerMsg box connects to the SCMElements box via an open arrow like this:

-------->

... and not like this:

---------|>

... or this:

---------<>

(man, I sure wish I could attach images to this forum so you could see what I mean <sigh>).

Technically I suppose the directed association model is not "wrong" but I would think that the aggregation model would be a lot more accurate.

Do you all agree or disagree?  Is there a way to make EA model that kind of a relationship as an aggregation?

[Geert Bellekens]

Think of this:
Which code do you consider to represent a regular association, and which code should represent an aggregation (or composition for that matter).

The problem is that the difference between those types of relations are of a functional nature. They are not reflected in code.

Compositions are a bit different, as they carry some extra constraints (cascading delete, only be part of maximum one composition at a time), but I don't think these constraints are reflected in the generated code either. Reverse engineering this would even be harder.

Geert

[«Midnight»]

This is further complicated by EA's inconsistent representation of associations and aggregations. Search Paolo's posts from some years ago for detailed a analysis of this issue. It seems to be a legacy dating to EA's transition from UML 1.x to 2.0. Any paradigm that automates or generates from models involving such links should take this into account.

I will leave interested readers (if any) to look up the reference. IIRC it is in this forum section.

[EricP]

Which code do you consider to represent a regular association, and which code should represent an aggregation (or composition for that matter).

Good morning, Geert.

If I am instantiating an object of type struct foo in another class / struct / union, I would certainly consider that an aggregation over anything else.

At the very least I'd like that to be configurable within EA, i.e. have a checkbox under preferences that allows a choice between aggregation and a regular association.

[Geert Bellekens]

Good afternoon Eric  8-)

So if I understand you correctly you consider

Code: [Select]

union SysControllerMsg
{
 struct SCMElements theSCMElements;
 char theSysControllerMsg[ sizeof( struct SCMElements ) ];
};
as the definition of an aggregation (composition?)

Does that mean that this:

Code: [Select]

union SysControllerMsg
{
 SCMElements theSCMElements;
 char theSysControllerMsg[ sizeof( struct SCMElements ) ];
};
Is for you the definition of a regular association?

Disclaimer: I'm not a real programmer, and I'm not sure about the meaning of the struct and union thing.

Geert

[EricP]

Good afternoon Eric  8-)

So if I understand you correctly you consider

Code: [Select]

union SysControllerMsg
{
 struct SCMElements theSCMElements;
 char theSysControllerMsg[ sizeof( struct SCMElements ) ];
};
as the definition of an aggregation (composition?)

Does that mean that this:

Code: [Select]

union SysControllerMsg
{
 SCMElements theSCMElements;
 char theSysControllerMsg[ sizeof( struct SCMElements ) ];
};
Is for you the definition of a regular association?

The two code snippets you included, mean the same thing.

The "struct SCMElements the SCMElements" is a throwback to the C days when you actually had to say "struct".  In C++ you can leave the "struct" out and just say "SCMElements theSCMElements" and it means the same thing.

I would consider both of those to be aggregations.

[Geert Bellekens]

OK, then my question remains, when would you consider something a regular association?
My point is that, in code there is no difference between a regular association and an aggregation.

Geert

[MatthiasH]

Hi,

I also wondered why EA never creates aggregations when importing code, so I am grateful for this discussion. I am not an UML expert, but naively I would assume:


class A;

class B
{
  doSomething( A* pA ) { m_pA = pA };
  A* m_pA;
}

class C
{
  A m_A;
}

class D
{
  D() { m_pA = new A; };
  ~D() { delete m_pA; };
  A* m_pA;
}

class E
{
  D() : m_pA(NULL) {};
  ~D() { delete m_pA; };
  doSomething(){ m_pA = new A; };
  A* m_pA;
}


Class B uses A, in fact it "has" an A, so I'd say this is Association.
Class C also has an A, and its lifetime is directly related to C's lifetime, so this is Aggregation.
Same is true for class D.

What about class E? It does not really control when A is instantiated (it depends on some external entity to call doSomething), but the end of life of A is directly related to class E's lifetime.

I am still not sure when to call it Composition instead of Aggregation - where to draw the line?

Regards,
Matthias

[Geert Bellekens]

Matthias,

I'm not sure about the subtle differences in the code you've posted. (my C++ or whatever language is a bit rusty).
What I do know is the difference between an aggregation and a composition.
In fact an aggregation and a regular association only differ in functional semantics, there is no difference in the formal constraints between the two.
For a composition that is entirely different.
A composition emposes two extra constraints:

• an object can only be part of one composition at a certain moment in its lifetime (0..1)
• an object that is a part of a composition will be deleted when the composite part is deleted.

Geert

[MatthiasH]

Geert,

thanks for the quick reply. So considering the two constraints you mentioned, the conclusion for my examples would be:

class B certainly does not not use composition (both constraints are violated), but I assumed Association originally, which still seems correct.

class C uses composition, since the private member is not shared, and it is destroyed when B is destroyed.

classes D and E could be seen as composition as well, provided the instance of A is not shared.

If C, D or E, respectively, would share the instance of A, it would be Aggregation.
And if they would not destroy the instance of A upon their own destruction, it would be Association.

Is this basically correct?


To put it more generic:

Association: "uses" without exclusive access and without control of the lifetime.

Aggregation: "owns" without exclusive access but with control of the lifetime.

Composition: "exclusively owns" with exclusive access and with control of the lifetime.

Maybe this is somewhat oversimplified, but could you agree?


If yes, I dare say that EA could detect the different shades of association, aggregation and composition when reverse engineering. Maybe it is not easily possible to detect it always, but then association would still be a valid fall-back (as it is in all cases today).

Hmmm... thinking about it... this would mean EA has to parse functional code, searching for instantiations and deletions, having an eye on all the pointers that are passed around etc. If this kind of analysis is no already part of the software then it might be a big mountain to climb...

Regards,
Matthias

[Geert Bellekens]

To put it more generic:

Association: "uses" without exclusive access and without control of the lifetime.

Aggregation: "owns" without exclusive access but with control of the lifetime.

Composition: "exclusively owns" with exclusive access and with control of the lifetime.

Almost except that the aggregation does NOT control the lifetime of its parts. (Deleting the aggregation will leave the parts alone)

Maybe your description of "exclusively own" for compositions is also a bit strong. Although a part can only be part of one composite at the time it can also exist on its one, and be added to another composition (if it is removed from the first composition first).

So this means that Association and Aggregations are formally the same since there is no difference in the constraints.
That is the reason why I usually don't use the aggregation, but only regular associations and compositions.

Geert

[MatthiasH]

So this means that Association and Aggregations are formally the same since there is no difference in the constraints.
That is the reason why I usually don't use the aggregation, but only regular associations and compositions.

Seems to me that the definition for composition, aggregation and association is a bit fuzzy... So for a practical approach it seems reasonable to use only the two "extremes" that can be clearly distinguished.

This discussion helped me a lot - thanks!

Matthias