Default Nested Elements Relationship Changed in Ver4.9

Started by Xiaoqi, October 20, 2021, 19:00:26 PM

Previous topic - Next topic

Xiaoqi

Hello,

After upgraded and working in v4.9 for past days, it's quite smooth, however, today I noticed one difference when doing the drag-and-drop for making Nesting.

As attached, we have numbers of element hierarchy built based on our internal agreed meta-model, one sample is "business process", we agreed to use the Composition relation so that Level 1 Process compose Level 2 Process.

In ver 4.8.1, when drag the element to upper level element and drop, the pop-up "New Relationship" dialog has the sequence 1. Composition 2. Aggregation 3. Specialization. We used to just click OK as the Composition is at the top and the default.

While, in ver 4.9.0, just realized that the pop up dialog's sequence changed to 1. Aggregation 2. Composition 3. Specification; so for several nesting structure, we made wrong relation to Aggregation.

Actually from Archimate it's not a big different other than the "stronger incluing" or not, but in the backend, we extract the element / relation to import into PowerBI for analytical purpose, the relation is used as certain criteria, so it is required to keep one the same agree Relation.

After all, I can manually switch to "Composition" every time as it's now the 2nd choice in the list, but it's not convenient so far.

Just curious on two questions:

1) What's the reason for making this change? Is any recommendation that "Aggregation" relation is more preferred for the nesting than "Composition"?

2) Do we have any configuration setting that I can adjust this suggested relations sequences? That would be great so that I can keep using 4.9.0 in more flexible manner.

Thanks a lot for your attention.
Regards,
Xiaoqi

Phil Beauvoir

#1
In Archi 4.9 the list is alphabetically sorted. Before that, the order was arbitrary.

It seems that the issue for you is what is selected in the list as the default so you can hit OK or return to close the dialog. If it is generally agreed that Composition is the most likely candidate, we could look at setting that as the default selection in the list.
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Xiaoqi

Thanks Phil for your quick reply, I think we just used to be the previous version's arbitrary order.

Agree that the new way of using aplhabetically sorted order is more natural and making sense, will try to adopt this in 4.9.

Nice day,
Xiaoqi

Xiaoqi

Hi Phil,

QuoteIf it is generally agreed that Composition is the most likely candidate, we could look at setting that as the default selection in the list.

At least in our using practice, we normally use "Composition" for showing the strong relation as the Hierarchy represent.

Have gone through ArchiMate 3.1 Specification, think again about the alternative way on how's the better, I think one of the reason we intend to use Composition instead of Aggregation (just for this sample scenario) is base on the sequence of relationship introduced in the Chapter 5.

Within Spec. Chapter 5, the different relationship are introduced in following order, when reading the logic, one possible structure is base on from strongest to weakest, as below:

  • Structural Relationship: Composition -> Aggregation -> Assignment -> Realization
  • Dependency Relationship: Serving -> Access -> Influence -> Association
  • Dynamic Relationship: Triggering -> Flow
  • Other Relationship: Specialization

Not sure your previous arbitrary order was based on these sequence already or not, but if say a more logical way that easier to remember, I suggest, that in the pop-up dialog, follow the group then relationship, e.g. Composition is always the top if applicable, and Realization is before Serving, Associatio is before Triggering, etc..

If that make sense in your view?

Regards,
Xiaoqi

Jean-Baptiste Sarrodie

Hi,

Quote from: xiaoqi on October 21, 2021, 01:19:04 AMHave gone through ArchiMate 3.1 Specification, think again about the alternative way on how's the better, I think one of the reason we intend to use Composition instead of Aggregation (just for this sample scenario) is base on the sequence of relationship introduced in the Chapter 5.

Within Spec. Chapter 5, the different relationship are introduced in following order, when reading the logic, one possible structure is base on from strongest to weakest, as below:

[...]

Not sure your previous arbitrary order was based on these sequence already or not, but if say a more logical way that easier to remember, I suggest, that in the pop-up dialog, follow the group then relationship, e.g. Composition is always the top if applicable, and Realization is before Serving, Associatio is before Triggering, etc..

The strengh order of relationships is only meant to be used in the context of derivation rules, not nesting. And there's no rules defined or suggested in the specification to help you choose a nested relationship from the allowed list. That's for a simple reason: you should already know in advance which relationship you want to use and just pick it on the list, not think about it afterward.

So that's only something we experience with a tool, and because we are lazy, having the first proposed relationship be the one we had in mind could help :-)

Quote from: Phil Beauvoir on October 20, 2021, 19:03:17 PMIf it is generally agreed [...], we could look at setting that as the default selection in the list.

So if we try to get the first one right in the majority of cases, here are my remarks:

There's a natural tendancy to see nesting as a kind of structural link (ie. something is inside a box, not another one), so composition should be the first and aggregation the second.

If we now look at the possible cases where composition and aggregation won't be possible, one of the most obvious is nesting behavior inside active structure (on the same layer), and in this case it should be assignement because that's the natural choice for Service nested inside Interface and Internal Behavior nested inside Internal Active Structure. That's also my prefered choice for Service nested inside Internal Active Structure (Realization would also have bee possible) because it is similar to the first ones.

Note that Serving would also have been possible but it rarely makes sense with nesting.

So here we find that Composition > Aggregation > Assignment > (Realization | Serving)

When nesting service inside an internal behavior from the same layer, Realization should be prefered over Serving. That's also true when nesting an application component inside a node for example.

Of course, there are cases where serving would make more sense, but hey are less common and rely on local convention and not on the specification.

So Composition > Aggregation > Assignment > Realization > Serving

And, when nesting passive structure inside active structure, if the active structure is from technology layer, we might have to choose between assignment, realization and access. I think access is the "safest" choice for most people, so I would try to make it the first proposed. So access should be before assignment and realization

It's rare to have to choose only between Access and Serving, but this can happen between Artifact and other active structure or behavior because Artifact can realize active structure which then serves other things. This construct is not so frequent, so I would favor Access over Serving too.

This leads me to Composition > Aggregation > Access > Assignment > Realization > Serving

Now there's the special case of Specialization which is allowed between concepts of the same type. In such case, the other possible relationships are always composition and aggregation and should be prefered over specialization. So specialization can be anywhere in the list as soon as it is after aggregation. I'd suggest to put it just before Serving simply because it is mentioned in the specifications.

So let's say: Composition > Aggregation > Access > Assignment > Realization > Specialization > Serving

Because association and influence are frequently used with motivation, I would make sure influence is sorted before association. The next related question would be: should we favor influence over realization. That's debatable because influence will be always true but potentially less strong than realization. In my experience, I almost only model strong link with motivation, so I would favor realisation (which is also the only one of the two explicitely defined as "nestable" in the specification).

So: Composition > Aggregation > Access > Assignment > Realization > Specialization > Serving > Influence > Association

Last, nesting doesn't really make sense for dynamic relationships (and I assume nobody will enable then in Archi's ARM configuration), but just in case, I would keep them at the end of the list so that even association is prefered over them.

So, from my experience, I would suggest the following order:
  • Composition
  • Aggregation
  • Access
  • Assignment
  • Realization
  • Specialization
  • Serving
  • Influence
  • Association
  • Triggering
  • Flow

Of course, with Archi's default configuration, only nesting explicitely allowed in the specification would be proposed, but for people (like me) who allows some other nestings, this would make Archi also suggest the most accurate relationship in almost all cases.

I would also suggest that reverse relationships use the same order, but appear juste after the "normal" one if both are possible.

Regards,

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Xiaoqi

Hi JB,

Wow, thanks greatly for your thoroughly anaysis, and I learnt a lot on the nesting relationship, as I didn't distinguish deeply on the structures and behaviors.

Quote from: Jean-Baptiste Sarrodie on October 22, 2021, 18:00:19 PMSo, from my experience, I would suggest the following order:

Agree with your order suggestion, it's nice that with your justification, those 4 different groups of relationships now in one single nesting sequence, which is based on clearly practical logical explanable order.

From our day to day work, just from the frequency perspective, "Composition" and "Aggregation" are at least the top 2 nesting way we normally use, and Composition is more often to be chosen, so if the pop up list is following the order as your mentioned, that will be quite time saving.

Thanks again,
Xiaoqi

Phil Beauvoir

The aim in changing the order of the list was to have the relations ordered alphabetically. Perhaps there are some users who might prefer that?
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Jean-Baptiste Sarrodie

Quote from: Phil Beauvoir on October 23, 2021, 08:16:45 AMThe aim in changing the order of the list was to have the relations ordered alphabetically. Perhaps there are some users who might prefer that?

In my experience, people already expect that Archi provides the most logical relationship and most of the time simply accept the first on the list. So the original order was making a bit of sense because composition was first, but was not perfect neither. With relationships in alphabetical order, I think we loose something because people will almost always have to pick another relationship.

So IMHO, either we roll back to what it was before or we use the order I suggested in the previous post. I would suggest to use this new order.

Regards,

JB
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Phil Beauvoir

The new order of relationships in the dialog as proposed by JB is implemented in Archi 4.9.1.
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Xiaoqi

Thanks greatly Phil and JB both, you're superb on making Archi great tool!

Xiaoqi

Hi Phil again,

Quote from: Phil Beauvoir on October 26, 2021, 21:31:06 PMThe new order of relationships in the dialog as proposed by JB is implemented in Archi 4.9.1.

Within 4.9.1, I can confirm the new default ordering is worked perfectly.

As attached, it really save time that I can draft a group of elements directly into one upper level element, and just click OK like before ;-)

Thanks again,
Xiaoqi