Visual Nesting Advisory in the Validator

Started by Manj75, November 01, 2019, 14:01:50 PM

Previous topic - Next topic

Manj75

Hi,

There seems to be a small bug which I'm not sure if it has been looked at in v4.6 Beta.  I have numerous Visual Nesting advisories in the Validator when run, however when the nested element in question is nested and does a have a relationship that is stated on the Visual Nesting Hint.  For example a Business Event is nested in a Business Function with an Assignment relationship but still flags this as a Visual Nesting - should not be nested ... unless there is a valid relationship, and the corresponding hint for Visual Nesting states:

QuoteAn element in a View is nested inside of another element. However, this is only visual as the two elements do not have a semantic relationship in the model.

The relationship between the elements should be either Composition, Aggregation, Assignment, Access, Realization, or Specialization.

As you can see this is ambiguous according to the hint assignment is valid and therefore there should not be an Visual Nesting advice.

Regards,
Manjit

Phil Beauvoir

#1
Hi Manjit,

A Business Function can't be assigned to a Business Event or vice-versa. Are you sure this is the relationship you have?
If you value and use Archi, please consider making a donation!
Ask your ArchiMate related questions to the ArchiMate Community's Discussion Board.

Manj75

My mistake I must have read it wrong - I know that a Biz function cannot be assigned to an event, but thought that is what I read and I cannot now find the advisory instance.

Ignore or close this thread - thanks

Manj75

#3
Hi Phil et al,

I need to resurrect this topic as I wanted to put forward a number of Visual Nesting Advisories in the validator that I think should be valid.  The problem I find is that the ArchiMate specification does not make it definitively clear regarding what can and can't be nested, but I believe as long as there is a valid relationship then it should be permitted.

Source Element -> Relationship -> Target:


  • Business Actor -> Assignment -> Business Role | Actor nested in Role
  • Business Function -> Triggering -> Business Event | Event nested in Function (I got it wrong in my first post when I stated Assignment)
  • Business Function -> Serving -> Buisness Interface | Interface nested in Function
  • Application Function -> Triggering -> Application Event

Taking the first one an example of this is a Marketing User:Business Actor performs the role of a Content Editor:Business Role using an Assignment, but nesting the actor in the role throws up a visual nesting advisory, surely this should be permitted as it is a valid relationship and the nesting has valid semantic.

Thanks,
Manjit





Phil Beauvoir

#4
Hi Manjit,

1 is a "reverse" nesting where the direction of the relationship is reversed. I guess it depends on whether users want the option of not warning about these in the Validator.

Triggering and Serving relationships are not included in the rule of nested relationships. Only Structural and Access relationships are included.

What do people think?

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

Manj75

Hi Phil,

I think regarding point 1, I could not see from ArchiMate standard where nesting an Actor in a Role would be prohibited and it does carry semantic value, see attahed.  I have a number of views that have this nesting and I would like for this particular nesting to be supported, rather than have a means to suppress it.

For the remaining points, again it makes for having simpler views to support triggering and serving in the rule of nesting within Archi.  I think as long as it conforms to the ArchiMate specification then it should be allowed.  We have a number of views where again it simplifies the diagram to have elements nested in Functions/Process where there is a Triggering/Serving relationship.

I am hopeful that all 4 points would be supported in a future Archi minor release and will not refactor our View diagrams to address the advisories unless you let me know that it is a definite no no.

Kind Regards,
Manjit

Phil Beauvoir

#6
You can nest whatever elements you like as set up in the ARM preferences in Archi, but for the Validator the rules try to follow the spec.

The following is from ArchiMate spec https://pubs.opengroup.org/architecture/archimate31-doc/chap03.html#_Toc10045297

"Nesting elements inside other elements can be used as an alternative graphical notation to express some relationships. This is explained in more detail in Section 5.1 and in the definition of each of these relationships."

Section 5.1 covers these relationships:

Composition
Aggregation
Assignment
Realization

The Validator allows these nested relationships:

Composition
Aggregation
Assignment
Realization
Specialization
Access

Specialization and Access were included in the Validator rules for reasons I can't remember.

So the issue then (if this needs changing) is to get a consensus of what should be raised as an issue in the Validator regarding nested relationships - what relationship types and whether both directions allowed.

At the end of the day, the user should use discretion and rely on their own modelling decisions. The Validator is only intended as optional advice, and nesting advisories can, in fact, be switched off. It's meant as a helping tool not mandatory enforcement.


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

Manj75

Great comprehensive response and good to know the listed rules for nesting in Archi, I completely take your point that the advisories are not warnings so can be switched off or ignored.  I'm just one of those people that sees the tool like a programming environment and always strive to remove all errors/warnings/information.

I will see if consensus on this grows over time but in the meantime I've got our department model at 0 errors & warning and a couple of hundred Visual Nesting advisories - low enough to now switch it off.

Many thanks,
Manjit

Phil Beauvoir

I'm happy to make changes to the Visualiser rules, as long as there's consensus among users, and as long as things don't get too complicated.
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

Hi,

It seems that I have to jump into this thread...

Quote from: Phil Beauvoir on November 15, 2019, 10:25:14 AM
Specialization and Access were included in the Validator rules for reasons I can't remember.

Simply because they are defined in the specification ;-)

The standard clearly state that these are the only official cases where nesting is allowed:

  • Target nested into source for Composition, Aggregation, Assignment, Realization, Access
  • Source into target for Specialization

So by default the Visualiser must tick to this.

Quote from: Manj75 on November 15, 2019, 07:50:10 AM

  • Business Actor -> Assignment -> Business Role | Actor nested in Role
  • Business Function -> Triggering -> Business Event | Event nested in Function (I got it wrong in my first post when I stated Assignment)
  • Business Function -> Serving -> Buisness Interface | Interface nested in Function
  • Application Function -> Triggering -> Application Event

So none of them is allowed per spec.

Quote from: Phil Beauvoir on November 15, 2019, 11:37:55 AM
I'm happy to make changes to the Visualiser rules, as long as there's consensus among users, and as long as things don't get too complicated.

There's an issue opened on github for that. My suggestion would be to have two different checks in the Visualizer: either check per specs (ie. what we have now), or check based on ARM settings.This would cover both use-cases.

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.

Manj75

Hi JB,

Thanks for your contribution a long with Phil's - I've now gone through much of the ArchiMate specification digesting and now better understanding it.

Please correct me where applicable as you guys have a deeper understanding of the specification than me :)

So, all of my 4 points given are not permitted for nesting because only Structural Relationships are permitted to be nested as detailed in section 5.1, which comprises of Composition, Aggregation, Assignment and Realization.  In addition to this the specification also permits nesting for Specialization, as stated in section 5.4.1 by nesting the specialized element inside the generic element.

This therefore prohibits nesting for relationships for Dependency and Dynamic Relationships, which from my 4 points covers Serving and Triggering, respectively.

In the case of point 1, I should always interpret Assignment as a 'Performs' such that a Business Actor performs Business Role, and therefore the only valid nesting is Business Role (Target) nested inside Business Actor (Source), not vice-versa.

On the basis that my understanding above is now correct, I believe that these should not be flagged up as Advisories in Archi, but instead should be Errors, following the specification strictly.  Archi, itself would help to teach and consolidate the ArchiMate specification.  If these were raised as errors then it would prompt to correct and if these are to be accepted then they could be configured to be ignored as per feature request stated by JB on github.

Also, If the ARM feature request issue is to be developed - it would be ideal to have it configure on a per View basis rather than a global configuration, this will better fit with Archi being used Collaboratively.

BTW - can you tell me what ARM stands for (sorry if this should be obvious)

Thanks,
Manjit

Jean-Baptiste Sarrodie

Hi,

Quote from: Manj75 on November 18, 2019, 11:03:35 AM
On the basis that my understanding above is now correct,

It is.

Quote from: Manj75 on November 18, 2019, 11:03:35 AM
I believe that these should not be flagged up as Advisories in Archi, but instead should be Errors, following the specification strictly.  Archi, itself would help to teach and consolidate the ArchiMate specification.  If these were raised as errors then it would prompt to correct and if these are to be accepted then they could be configured to be ignored as per feature request stated by JB on github.

Well, ArchiMate (by design) is a bit blurry about what is stricly forbidden and which rule you can brake on some occasion. The end goal is to be able to better communicate, so if for some cases, nesting make it easier to achieve this goal, then the spirit of ArchiMate is that you should do it even if this is not a case explicitely allowed by the standard.

That being said, if at some point, we address my issue on GitHub and offer an option to do a check based on ARM configuration, then we could change the "error level" associated. But I'm still not sure what would be best.

Quote from: Manj75 on November 18, 2019, 11:03:35 AM
Also, If the ARM feature request issue is to be developed - it would be ideal to have it configure on a per View basis rather than a global configuration, this will better fit with Archi being used Collaboratively.

In theory, yes (but per viewpoint, not per view). Nesting rules are one of those things that shoujld be part of a viewpoint definition. But this in fact raises the question of a custom check that would verify if a view respects its viewpoint, as a whole (not just nesting).

Quote from: Manj75 on November 18, 2019, 11:03:35 AM
BTW - can you tell me what ARM stands for (sorry if this should be obvious)

Automatic Relationship Management

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.

Manj75

I look forward to the ARM feature - but I'm still of the opinion that 'Visual Nesting' Advice for the stated relationships should be promoted to 'Error' instead, clearly conveying that it is not permitted.  ARM could then override this once available, but semantically it would be better aligned to the specification as an error, however this is a minor point.

Thanks :)

Jean-Baptiste Sarrodie

Hi,

Strictly speaking, this is not an error if used to ease communication and understanding.

There is no "right" or "wrong" in ArchiMate in general. The only exception is with relationship table which is the single point of truth, and with real meaning of derived relationship (the meaning of a derived relationship is the meaning of the full relationship chain leading to the derived one).

This is a big conceptual difference between ArchiMate and, for example, UML which is designed to be "executable" (ie. you should be able to convert it to code).

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.

Manj75

I totally understand that, as I have worked with UML too and ArchiMate being loosely defined is one of its main appeals for Architects modelling at a conceptual/logical level.  I think that with this the specification can be interpreted differently in many tool implementation, e.g. Sparx EA would be stricter to the specification, which I've previously used, but in any case Archi I find to be better in its simplicity.  Thanks.