Class relationship notations unclear

Capella
1

I have created the following example structure:

image
image897Ă—418 22.5 KB

I use association, composition, aggregation and generalization relationships. In my tests, I found some inconsistencies and have some questions. For example, when I select the class 3 composition:

image
image692Ă—767 23.7 KB

The same way, when I select the class 2 aggregation:

image
image715Ă—872 27.8 KB

Q1. The roles are reversed. In the first case, role 1 corresponds to the parent but in the second case, role 1 corresponds to the child. Why is it so?

Q2. When I open the properties of the association (between Class 2 and Class 3), the first role (and properties) I see are of the child. The second role is of the parent. Why is there an inconsistency in the properties?

This gets confusing in large models, and during scripting.

This may very well be a gap in my knowledge of ARCADIA, but I would appreciate some help. Thanks.

2

Hi there,

I am not an expert on the Class Diagram in Capella, but one thing I can say is that this is not really Arcadia related, as Arcadia does not go deep down in defining how data structure should be modelled. The implementation in Capella of this “data” diagram (and more importantly, the underlying data model structure) is originating from UML, and also how UML concepts maps to Ecore, and how EMF orders association ends internally, and how the UI choose to display them.

From there, I am copying and pasting what Chatgpt is saying on this. But obviously you may do the same yourself…Hoping this gives you a little bit more clarity, and more importantly a good strategy for your scripting:

:one: About the “reversed” roles (Q1)

In UML (and in the underlying EMF/Ecore implementation used by Capella), an association always has two ends, but there is no semantic rule that says:

  • role 1 = parent

  • role 2 = child

Composition or aggregation is not determined by the position of the role, but by a property on one association end:

  • For composition → one end is marked as composite

  • For aggregation → one end is marked as shared

The ordering of the ends (role 1 vs role 2) simply depends on how the association was created and stored internally in the model. It is not tied to “parent” or “child”.

So in your examples:

  • In one case, role 1 happens to be the composite end.

  • In another case, role 1 happens to be the part end.

This is not a semantic difference — only an ordering artifact.

:two: About the Properties view ordering (Q2)

The Properties view displays the association ends in their internal model order.

It does not reorder them based on:

  • which end is composite

  • which end could be considered “parent”

  • diagram drawing direction

So what you see (child first in one case, parent first in another) is simply the internal storage order reflected in the UI.

This can indeed feel inconsistent from a human point of view, because we tend to think in terms of parent/child, while the underlying metamodel only defines “association end 1” and “association end 2”.

:three: Important point for scripting and large models

You are absolutely right that this becomes confusing in larger models or when writing scripts.

The key recommendation is:

:right_arrow: Never rely on role index (first/second) to determine parent/child.
:right_arrow: Always check the aggregation/composition property of the association end.

For example, in automation you should explicitly test whether an end:

  • is composite

  • is shared

  • or has no aggregation

That is the only reliable way to determine semantics.

3

I understand, thanks for the detailed answer. Much appreciated!

1 Like