Archimate Derived Relationships

[Peter Kelley]

Hi,

I know that the Archimate permitted relationship matrix in the spec is a big mess however should I be able to create derived relationships if I need them?

For example Application Services can be realized by Application Functions, Application Processes or Application Interactions. These in turn can have Application Components assigned to them. If I want to show a relationship between Application Services and Application Components I should be able to use  a Realization relationship being the weaker of the two but all I'm offered is association.

The Archi tool allows this however my customer is using Sparx.

[Glassboy]

Are you talking about the quicklinker?  You can create whatever relationship you like, even a non ArchiMate relationship.

[Peter Kelley]

Of course, the palette! My brain was doing a mental block.

Sparx then disallows this particular relationship until you go to Start->Preferences->Links and turn off strict connector syntax.

[Glassboy]

Of course, the palette! My brain was doing a mental block.

Sparx then disallows this particular relationship until you go to Start->Preferences->Links and turn off strict connector syntax.

My memory might be failing me but I believe that Sparx implemented all of the explicit relationships from the tables in the specification.  That table doesn't include derived and implicitly allowed relationships.

[Paolo F Cantoni]

Of course, the palette! My brain was doing a mental block.

Sparx then disallows this particular relationship until you go to Start->Preferences->Links and turn off strict connector syntax.

My memory might be failing me but I believe that Sparx implemented all of the explicit relationships from the tables in the specification.  That table doesn't include derived and implicitly allowed relationships.

That's correct GB,

the matrix only indicates the explicit relationships.  The derivation of relationships is a process to determine the most appropriate implicit relationship to render (especially where multiple paths might be involved).

Unfortunately, EA doesn't provide a universal "derivation" indicator (property).

Paolo

[Glassboy]

the matrix only indicates the explicit relationships.  The derivation of relationships is a process to determine the most appropriate implicit relationship to render (especially where multiple paths might be involved).

I can't be bothered going and looking but I believe that we decided that you could imply implicit relationships from both derivation and another section of the specification.

[Paolo F Cantoni]

the matrix only indicates the explicit relationships.  The derivation of relationships is a process to determine the most appropriate implicit relationship to render (especially where multiple paths might be involved).

I can't be bothered going and looking but I believe that we decided that you could imply implicit relationships from both derivation and another section of the specification.

Yes, the rules are defined, but they require traversal of the (specific) path to determine the relationships involved and from that determine the most appropriate implied relationship.

Paolo

[Peter Kelley]

Of course, the palette! My brain was doing a mental block.

Sparx then disallows this particular relationship until you go to Start->Preferences->Links and turn off strict connector syntax.

My memory might be failing me but I believe that Sparx implemented all of the explicit relationships from the tables in the specification.  That table doesn't include derived and implicitly allowed relationships.

The spec would tend to suggest otherwise:

"This appendix details the normative requirements for relationships between elements of the ArchiMate modeling language. It is constructed from the metamodel figures in Chapters 3 through 13 and the derivation rules for relationships outlined in Section 5.6."

Looking in the table Application Component to Application Service is listed as irvtfo where r is realization. This means that Sparx disallows a valid relationship in the relationship table when in strict relationship mode.

As I said in my original post the relationship table is a mess, it doesn't match the text of the spec, but at least this one is present.

[matthew.james]

I seem to remember discussions in other threads about derived relationships and the many pragmatic challenges. Whilst other tools do attempt to support automatic derived relationships I can understand that the ambiguities of the spec and vagaries of different peoples' intentions would make such a feature extremely difficult to implement successfully.

What I think would be useful however would be for Sparx to be aware of 'manually' created derived relationships. As a modeler I could explicitly create the 'derived' relationships that I care about so that I can create simplified diagrams by excluding some intermediate elements. If those intermediate elements are shown however, the connector for the direct 'derived' relationships would be hidden (automatically, or perhaps by use of a filter).

This would require Sparx to:
- Understand when a connector is 'derived' (@Paolo - is that what you had in mind wrt the 'universal "derivation" indicator' ?)
- Be able to determine when there is an alternative (non-'derived') path between elements connected by such a 'derived' connector, so that the derived path can be hidden
- Allow 'derived' connectors to be created within the strict connector syntax / model validation rules

[matthew.james]

... the relationship table is a mess, it doesn't match the text of the spec, but at least this one is present.

Sparx support engineers have indicated in other posts that the Archimate validation rules in Sparx have been implemented based on the text of the spec only and don't consider the table; due to inconsistencies and ambiguities therein.
From which I infer that *if* the relationship is declared in the text of the spec and Sparx doesn't like it (fails validation, not in quicklinker), this is considered a bug.  If it is in the table only, then not so much.

[Paolo F Cantoni]

I seem to remember discussions in other threads about derived relationships and the many pragmatic challenges. Whilst other tools do attempt to support automatic derived relationships I can understand that the ambiguities of the spec and vagaries of different peoples' intentions would make such a feature extremely difficult to implement successfully.

What I think would be useful however would be for Sparx to be aware of 'manually' created derived relationships. As a modeler I could explicitly create the 'derived' relationships that I care about so that I can create simplified diagrams by excluding some intermediate elements. If those intermediate elements are shown however, the connector for the direct 'derived' relationships would be hidden (automatically, or perhaps by use of a filter).

This would require Sparx to:
- Understand when a connector is 'derived' (@Paolo - is that what you had in mind wrt the 'universal "derivation" indicator' ?)
- Be able to determine when there is an alternative (non-'derived') path between elements connected by such a 'derived' connector so that the derived path can be hidden
- Allow 'derived' connectors to be created within the strict connector syntax/model validation rules

Yes, we need an easily referencable property to indicate a derived relationship (We hijacked the isLeaf field for a connector to do that - and also created some tagged values {for defining the type of derivation and other information))
We also use the new arc-to-arc relationships to indicate explicitly which relationships are derived by what means.
We assume that "all bets are off" with derived connectors - that is we don't implement strict syntax for them.   As I said, the derivation rules are quite complex and a derived relationship that is valid at creation time may become invalid if one of the traversals is changed.
BTW, we sometimes show BOTH the derived and derivation paths on the same diagram.  It's not a given that the derived arc should be hidden if the alternate path is available.

Paolo

[Peter Kelley]

I seem to remember discussions in other threads about derived relationships and the many pragmatic challenges. Whilst other tools do attempt to support automatic derived relationships I can understand that the ambiguities of the spec and vagaries of different peoples' intentions would make such a feature extremely difficult to implement successfully.

What I think would be useful however would be for Sparx to be aware of 'manually' created derived relationships. As a modeler I could explicitly create the 'derived' relationships that I care about so that I can create simplified diagrams by excluding some intermediate elements. If those intermediate elements are shown however, the connector for the direct 'derived' relationships would be hidden (automatically, or perhaps by use of a filter).

This would require Sparx to:
- Understand when a connector is 'derived' (@Paolo - is that what you had in mind wrt the 'universal "derivation" indicator' ?)
- Be able to determine when there is an alternative (non-'derived') path between elements connected by such a 'derived' connector so that the derived path can be hidden
- Allow 'derived' connectors to be created within the strict connector syntax/model validation rules

Yes, we need an easily referencable property to indicate a derived relationship (We hijacked the isLeaf field for a connector to do that - and also created some tagged values {for defining the type of derivation and other information))
We also use the new arc-to-arc relationships to indicate explicitly which relationships are derived by what means.
We assume that "all bets are off" with derived connectors - that is we don't implement strict syntax for them.   As I said, the derivation rules are quite complex and a derived relationship that is valid at creation time may become invalid if one of the traversals is changed.
BTW, we sometimes show BOTH the derived and derivation paths on the same diagram.  It's not a given that the derived arc should be hidden if the alternate path is available.

Paolo

Are Archimate derived relationships a property of the instances or a property of the class? I have element instances with derived relationships with no intervening instance. This is useful because sometimes I don't care about the application functions/processes for COTS applications but I do care about the application components (which will be deployed) and the application services (which will be used by business processes).

In terms of the tool I'd like to be able to manually add derived relationships that I care about with checking turned on. Bonus points for being able to create an automatic style for their display such as colouring them red.

I believe that there is a version of a fixed matrix floating around done by someone outside the committee but I couldn't find it just now. I'll have to have a look tomorrow and see if I can edit this post with a link to it.

[Paolo F Cantoni]

Hi Peter,
As you probably know, ArchiMate doesn't make much distinction between instances and classifiers, so the question overall is somewhat moot.

However, the derivation is a result of the specific arcs involved.

As I mentioned in the previous post, "all bets are off" with derived relationships.  We allow (so designated) derived relationships without having to specify how they are derived.  (Just enough modelling).  As you have noted, yourself.

With derivation by traversal (only ONE of the types of derivation), we use the ArchiMate relationship strength (5.6.1) list to determine for a given traversal the metatype of the derived relationship.

Paolo