ArchiMate Grouping and Alternatives

[Viking]

Hi, I am afraid that I asked a similar question before decided for Grouping. But I cannot find it anymore.

Currently I use ArchiMate Grouping to group several independent components that could potentially even run on different computers, so that it can be easier managed in Enterprise Architecture Management (see also https://www.archimetric.com/exploring-composite-elements-in-archimate-unveiling-grouping-and-location). In my case these components are frontend, server, and database. I like Grouping, but I am having trouble to use it with EA. For example, Time Aware Modelling does not support Grouping. So, following alternatives come into my mind:

• Composite Element: for EA, this is Grouping, see https://sparxsystems.com/enterprise_architect_user_guide/17.0/modeling_languages/composite_elements.html
  
• Application Collaboration: a collaboration is as an aggregate. The collaboration has normally aggregation relationships to its aggregated components. The database has been modelled as a system component and does not support aggregation between Collaboration and Database. But that does not really matter. I would leave the relationships away. The Collaboration still “groups” the elements, meaning if I put them inside the component, they are all moved together.
  
• Application Component Stereotyped: an additional element as a stereotype that inherits from Application Component and maybe has no color (like grouping) and a symbol like grouping. Rem.: Application Component supports the same realtionships as Application Collaboration.

What are the advantages and disadvantages of the approaches? What do you recommend?

[Viking]

After investigating I think I should stay with Grouping, because the grouped elements / components spread over different layers of an application architecture.

Better ideas are still welcome.

[Guillaume]

Looking at the ArchiMate Grouping element, it is not clear from the Open Group specification how this should be implemented. I would have used the UML Class as the metaclass instead of a Boundary so I can manage this element like other ones instead of diagram element under the ... special packages.

Working on an MDG, I managed to define Grouping as a Class stereotype and change the ShapeScript to render it the same way.

[Modesto Vega]

A key challenge in the Sparx Systems implementation of both the UML Package and the ArchiMate Grouping element is the conflation of an element's type with its role as a container. This design choice, while pragmatic in some respects, restricts the ability to create relationships to or from the container itself and other "proper" elements, fundamentally complicating modelling efforts such as the one described by the OP.

[Paolo F Cantoni]

A key challenge in the Sparx Systems implementation of both the UML Package and the ArchiMate Grouping element is the conflation of an element’s type with its role as a container.  This design choice, while pragmatic in some respects, restricts the ability to create relationships to or from the container itself and other “proper” elements, fundamentally complicating modelling efforts such as the one described by the OP.

I basically agree with Modesto (surprise, surprise! ) with a few, hopefully minor, caveats (see below).  We also used Guillaume’s solution to create our own Grouping Element (with a set of supporting scripts).

The Standard says: (4.5.1 Grouping)
“The grouping element is used to aggregate or compose an arbitrary group of concepts, which can
be elements and/or relationships of the same or of different types.”
Now, you’ll note that there is NO mention of a boundary!  Notwithstanding the way the element is depicted in the associated diagram - the dotted borders to the Element, suggesting, in Sparx terms, a Boundary (a non-UML item), there is no mention of boundary in the entire definition section!

Just as “Correlation is NOT Causation”, “Rendering is NOT Implementation”! 

Now to the question of containment...  Our view is that, while the standard mentions aggregation and composition relationships, the definition of a grouping element is actually that of a holonym (the whole-holonym, rather than the parts-meronym)!  Also, the mention of aggregation and composition is to determine the nature of the holonymy (and thus the nature of the relationship between the meronym and the holonym).  That is, if a meronym can exist in more than one grouping at the same time, then the holonymy is an aggregate; otherwise, it is a composition.  This becomes a property of the Grouping element (which we surface as required with our shapescript).  There is NO implication of structural containment!

Consequently, the Grouping Element is neither a boundary nor a container, merely a normal element indicating that a set of other elements may be considered a group of related things.  Indeed, one could argue (and we do that the example shown in 4.5.1 of the Standard is a little misleading.  The REAL relationships are between the Service, the two processes, and the object.  The Grouping Element is merely a shorthand view—albeit a formal and rigorous one—to reduce visual complexity.

As I said earlier, we implemented our own Grouping Element that supports the Standard while providing the properties identified above.

HTH,
Paolo

[Modesto Vega]

We can indeed used Guillaume’s solution, I think I used it once in the past.

The Standard says: (4.5.1 Grouping)
“The grouping element is used to aggregate or compose an arbitrary group of concepts, which can
be elements and/or relationships of the same or of different types.”

As noted by Paolo, in a much more sophisticated language, the issue with the way this is implemented is that, from memory, it is not possible to draw aggregations and compositions between a grouping and the elements it groups.

This, of course, brings to the forefront the way the browser was designed and implemented, and one of Paolo's favourite subject: visual nesting vs physical nesting (Paolo, sorry for paraphrasing).

The issue is that the browser enforces physical nesting where an element can exist only in one package or as a composite of another element - i.e., the element can only have 1 parent element (package or standard). This means, the same version of an element can only exist once in the browser. I suspect, Sparx Systems sees implementing the ArchiMate grouping, which could be argued is a form of visual nesting (not physical nesting), as completely redesign of both the browser and the underlying data model; something they may not want to undertake.

[Paolo F Cantoni]

We can indeed use Guillaume’s solution. I think I used it once in the past.

The Standard says: (4.5.1 Grouping)
“The grouping element is used to aggregate or compose an arbitrary group of concepts, which can
be elements and/or relationships of the same or of different types.”

As noted by Paolo, in a much more sophisticated language, the issue with the way this is implemented is that, from memory, it is not possible to draw aggregations and compositions between a grouping and the elements it groups.

This, of course, brings to the forefront the way the browser was designed and implemented —and one of Paolo’s favourite subjects: visual nesting vs. physical nesting (Paolo, sorry for paraphrasing).

I take a very rigorous approach to nomenclature.  I reserve the term “nesting” for physical nesting, in which the identity of an item depends on its holonym.  I use the term “Visual Embedding” to describe the ability to move an item into or out of (just as important) another item on a diagram.

The issue is that the browser enforces physical nesting, meaning an element can exist only in one package or as a composite of another element—i.e., it can have only 1 parent element (package or standard).  This means, the same version of an element can only exist once in the browser.  I suspect Sparx Systems sees implementing the ArchiMate grouping, which could be argued is a form of visual nesting (not physical nesting), as a complete redesign of both the browser and the underlying data model; something they may not want to undertake.

Not quite; Grasshopper...  The ArchiMate Grouping is a Holonym (either an aggregate or composite - as required), consequently, the convention of suppressing the holonymic relationships when visually embedding applies.  That is, the impetus is reversed from what your statement implies.

As Guillaume and I have shown, no redesign of the browser is required; all that is required is to redesign the concept in our brains.  It is easy enough to implement.

Cheers,
Paolo

[Modesto Vega]

I take a very rigorous approach to nomenclature.  I reserve the term “nesting” for physical nesting, in which the identity of an item depends on its holonym.  I use the term “Visual Embedding” to describe the ability to move an item into or out of (just as important) another item on a diagram.

I know, and was aware I could get in trouble by using a less rigorous approach to nomenclature. But I will blame the forum poor search engine for not allowing me to quickly find one of the posts where we discussed this is the past. Perfectly happy with "nesting" meaning physical nesting, and using "visual embedding" to describe the ability to move an item in or out of another item on a diagram. Having said this, Sparx EA, at times, doesn't do "visual embedding" very graciously.

Also "nesting" is really a form (de-)composition but, AFIK, there is no relationship for it in any modelling language I am familiar with. It this not the same to represent "car" as a group of interrelated elements - e.g., engine, wheels, chassis, body, and so on - or a one element with (physically) nested elements.

As Guillaume and I have shown, no redesign of the browser is required; all that is required is to redesign the concept in our brains.  It is easy enough to implement.

Just to clarify my point, I know you and Guillaume have proven you can do this with an MDG. Actually I have done it myself. My point is two fold:
1 - From previous interactions with Sparx Systems through the support desk, and with Eve and other people in this forum, I got the impression that changing the way the Grouping element works is considered a very significant change not very high up in their plans.
2 - From a usability point of view, the package browser, which is essentially a physically nested structure (almost an extended folder structure), often makes collaborative work on a single repository difficult and leads to unwanted data duplication. The collaboration problem would be easier to solve if a view, a Sparx EA view, could be constructed showing how elements are/or could be visual embedded. If the browser could be hidden for certain users, this view could be the main entry point for any work done by some of the users we typically collaborate with. After all, some relationships are a natural visual embedment: specialisation, aggregation, and composition.

[Paolo F Cantoni]

I take a very rigorous approach to nomenclature.  I reserve the term “nesting” for physical nesting, in which the identity of an item depends on its holonym.  I use the term “Visual Embedding” to describe the ability to move an item into or out of (just as important) another item on a diagram.

I know, and was aware I could get in trouble by using a less rigorous approach to nomenclature.  But I will blame the forum’s poor search engine for not allowing me to quickly find one of the posts where we discussed this in the past.  Perfectly happy with “nesting” meaning physical nesting, and using “visual embedding” to describe the ability to move an item in or out of another item on a diagram.  Having said this, Sparx EA doesn’t do “visual embedding” very gracefully at times. 

It wasn’t trouble, merely a gentle correction.   I agree with your point about the searching capability.  Why is searching SO hard (as a functionality)?  It’s not just here that one can criticise the searching as being less than optimal.  Anyway, another gentle correction (to myself, not the least), Nesting doesn’t actually apply to physical nesting; it applies to referential or access nesting - as I have indicated in the past, nesting defines the namespace of the meronym - in other words, you have to access the higher level items to get to the lower level item  (x.y.z).  The physical nesting in the browser is just a manifestation of that concept.

Also, “nesting” is really a form (de-)composition, but AFIK, there is no relationship for it in any modelling language I am familiar with.  Is this not the same as representing “car” as a group of interrelated elements - e.g., engine, wheels, chassis, body, and so on - or a one element with (physically) nested elements?

Yes, you are correct, it is a form of composition, but from the point of view of accessing the item via its FQN.  We use the Nestign Connector as described in the User Guide:
Index > Modeling Languages > Unified Modeling Language (UML) > UML Connectors > Nesting
extensively so that if the meronym and the holonym are on the same diagram, there will be a visual indication that there is a referential nesting, even if the name doesn’t show that (we use use-friendly Aliases a LOT).  The UG places it under UML Connectors (as you can see above), but I couldn't find any reference to it in the Superstructure. 

As Guillaume and I have shown, no redesign of the browser is required; all that is required is to redesign the concept in our brains.  It is easy enough to implement.

Just to clarify my point, I know you and Guillaume have proven you can do this with an MDG.  Actually, I have done it myself.  My point is two-fold:
1 - From previous interactions with Sparx Systems through the support desk, and with Eve and other people in this forum, I got the impression that changing the way the Grouping element works is considered a very significant change, not very high up in their plans.I, too, have observed this.

2 - From a usability point of view, the package browser, which is essentially a physically nested structure (almost an extended folder structure), often makes collaborative work on a single repository difficult and leads to unwanted data duplication. The collaboration problem would be easier to solve if a view, a Sparx EA view, could be constructed showing how elements are/or could be visually embedded.  If the browser could be hidden for certain users, this view could serve as the main entry point for work by some of the users we typically collaborate with.  After all, some relationships are a natural visual embedding: specialisation, aggregation, and composition.

Since we gave away the notion of the browser indicating any form of holonymy, we basically haven’t had that problem.  Only items that require referential nesting are nested.  All other items are in a "flat" structure (by type).  The diagrams are in a separate branch of the repository and can be structured however you like.  Consequently, we don't have as much of a problem as you do.

Paolo