Nesting of Elements - ArchiMate, Relationships, Visual Purposes

[i4mdone]

The ArchiMate standard allows for determining 4 types of Relationships when it comes to nesting elements.

It appears that Sparx handles nesting in two ways that I am aware of:
1. Logically moving the element "within/under" the containing element
2. Create a Traceability of an owns/owned by between the two elements

The question is in support of ArchiMate, is there a method/approach that I am unaware of that allows you to:
1. Specify one of the 4 Relationship types (composition, aggregation, assignment, realization) as part of the nesting process
2. Just reflect the visual purposes of nesting without logically moving the element "within/under" the containing element

[Geert Bellekens]

2 is just a symptom of 1

1(the second) No, you cannot. You'll have to create the relationship explicitly
2(the second) Yes I think so. IIRC there is an option somewhere that controls this (something like "support for composite objects")

Dragging with ALT key pressed might help as well to avoid nesting.

Geert

[Sunshine]

The ArchiMate standard allows for determining 4 types of Relationships when it comes to nesting elements.

It appears that Sparx handles nesting in two ways that I am aware of:
1. Logically moving the element "within/under" the containing element
2. Create a Traceability of an owns/owned by between the two elements

The question is in support of ArchiMate, is there a method/approach that I am unaware of that allows you to:
1. Specify one of the 4 Relationship types (composition, aggregation, assignment, realization) as part of the nesting process
2. Just reflect the visual purposes of nesting without logically moving the element "within/under" the containing element

Everything that Geert says is true and as I've been using Sparx EA with ArchiMate for just over a decade now I'd like to add something too.

Section 5.1 in ArchiMate Specification V3.01 can be a little confusing. It does make a point in section 5.1 of the ArchiMate specification;

Note, however, that this can lead to ambiguous models, in case multiple structural relationships
are allowed between these elements

So that's a kind of "Here be Dragons" warning.

In addition to the specification if you read "Enterprise Architecture At Work" by Marc Lanckhorst et al the book describes it a little bit more detail in section 5.13 and from that this is how I've interpreted how to nest and use relationships you talk about.

As Sparx EA only allows one parent in nesting the model elements the way I've interpreted that the nesting is for diagramming purposes only to show some things being grouped together. The structure of the model elements can be nested but I would only use composition to represent that as the definition of composition in ArchiMate says

The composition relationship has been inspired by the composition relationship in UML class diagrams. In contrast to the aggregation relationship, the composed concept can be part of only one composition.

Which I take to mean, if you destroy the parent the children are also destroyed with it. i.e. the same as UML.

I interpret the other three relationships aggregation, assignment and realisation as being weaker relationships similar to association as the child elements can exist outside the lifecycle of the parent. Which seems to fall into line with the definitions for those in ArchiMate below;

Code: [Select]

Aggregation Relationship
The aggregation relationship has been inspired by the aggregation relationship in UML class diagrams. In contrast to the composition relationship, an object can be part of more than one aggregation.
Assignment Relationship
The assignment relationship links active structure elements with units of behaviour that are performed by them, business actors with business roles that are fulfilled by them, and nodes with technology objects. It can, for example, relate an internal active structure element with an internal behaviour element, an interface with a service, or a node with a technology object
Realisation Relationship
The realization relationship indicates that more abstract entities (“what” or “logical”) are realized by means of more tangible entities (“how” or “physical”). The realization relationship is used to model run-time realization; for example, that a business process realizes a business service, and that a data object realizes a business object, an artifact realizes an application component, or a core element realizes a motivation element.

Hope that helps.

[Paolo F Cantoni]

My AU$0.05 is that, as usual, it is a matter of terminology and semantics.

@i4mdone, you may care to search the forum for posts (usually by me) on "visual embedding" vs "nesting".

It is important to understand (whatever any standard may say - but most agree) that nesting is concerned with access/pathing to the leaf node via the intervening branch nodes.  For example, we can say a port is "nested" within its encompassing node because you can ONLY reference the port via its parent.

It is semantically spurious to use the term nesting with regard to the other relationship types.

The other relationships are grouping relationships and so under ArchiMate, we can visually embed the clients within the supplier.  But this does NOT change their access (address) when this is done.  EA incorrectly does this with a number of the visually embedding mechanisms - see swimlane processing.

The other point I want to re-iterate is that some relationships indicate relationships between classifiers and others define relationships between the instances of the classifiers.  Thus with composition, a specific instance of the client can exist in no more than one (or none) instances of the supplier at a time.  However the client classifier may be defined to be compose(able) into multiple different suppliers - but the result is that, at most, only one may be active at a time for a given instance.  The client (meronym) structurally becomes part of the supplier (holonym).  Thus, as Sunshine indicates, when the holonym is "destroyed", the (currently attached) meronyms are also "destroyed".  It is interesting to note, particularly in the case of composition, that mandatory meronyms form part of the definition of the holonym.

@i4mdone, we created our own mechanism to handle some of the issues you raised in your original post.  We have a metaclass called GroupingSet (an extension of the UML Generalization Set - which should actually be named Specialization Set)) which defines a particular set of client items that belong to the same supplier.  We have CompositionSets, AggregationSets, AssociationSets etc.  They define the items that can be visually embedded and the nature of the relationship that is in the set.  We can also use these to indicate that a particular visual embedding on a particular diagram may not be "telling the whole story".  You may see three items embedded within the supplier, but the grouping set tells you that there is a total of 5 items in the set so the picture is incomplete.  Conversely, if you see 6 items visually embedded, you know that the is an inconsistency that needs to be resolved.

Notwithstanding that EA "incorrectly" nests certain types of items; as part of our overnight processing, we remove the incorrectly nested items and move them to their defined locations (flattening the structure).  The only items we preserve the nesting for are (so-called) embedded elements; Ports, required/provided Interfaces etc.

HTH,
Paolo