New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing relationships in Archi 4 #164

Closed
jbsarrodie opened this Issue Nov 21, 2016 · 49 comments

Comments

Projects
None yet
9 participants
@jbsarrodie
Member

jbsarrodie commented Nov 21, 2016

Hi,

Original content:
It is not possible to create Access relationships from Behavior Technology Elements to Artifact...

JB

This entry is now used to track all issues related to relationship (i.e. relationships that should exist but are not in the official Appendix B)

  • Behavior Technology Elements Accesses Artifact
  • Artifact Realizes Data Object
  • Actor/Role AssignedTo Work Package
  • Actor/Role AssignedTo Implementation Event
  • Implemetation Event flows/triggers Implementation Event
  • Technology Process realizes Application Process
  • Technology Process realizes Application Function
  • Technology Function realizes Application Process
  • Technology Function realizes Application Function
  • Technology Interaction realizes Application Process
  • Technology Interaction realizes Application Function
  • Technology Interface realizes Application Interface
@jbsarrodie

This comment has been minimized.

Show comment
Hide comment
@jbsarrodie

jbsarrodie Nov 21, 2016

Member

Answer to myself, in fact Archi 4 is really ArchiMate 3.0 compliant, even for its bugs...

The issue is that the official relationship table is missing the same relationship.

My 2 cts: we have to allow those access even if non standard or users will not be able to use Archi4 & ArchiMate3.

JB

Member

jbsarrodie commented Nov 21, 2016

Answer to myself, in fact Archi 4 is really ArchiMate 3.0 compliant, even for its bugs...

The issue is that the official relationship table is missing the same relationship.

My 2 cts: we have to allow those access even if non standard or users will not be able to use Archi4 & ArchiMate3.

JB

@Phillipus

This comment has been minimized.

Show comment
Hide comment
@Phillipus

Phillipus Nov 23, 2016

Member

What would be helpful would be to get a list of missing/incorrect relationships and then I/someone could edit the relationships.xml file.

Member

Phillipus commented Nov 23, 2016

What would be helpful would be to get a list of missing/incorrect relationships and then I/someone could edit the relationships.xml file.

@jbsarrodie

This comment has been minimized.

Show comment
Hide comment
@jbsarrodie

jbsarrodie Nov 30, 2016

Member

@Phillipus I agree, let's log here all issues found. For each new one, I'll update the main content to have an easy to read list.

Member

jbsarrodie commented Nov 30, 2016

@Phillipus I agree, let's log here all issues found. For each new one, I'll update the main content to have an easy to read list.

@jbsarrodie jbsarrodie modified the milestone: 3.0.0 Nov 30, 2016

@jbsarrodie jbsarrodie added the bug label Nov 30, 2016

@jbsarrodie jbsarrodie added this to the 4.0.0 milestone Nov 30, 2016

@pjjv

This comment has been minimized.

Show comment
Hide comment
@pjjv

pjjv Dec 15, 2016

Another one is:

  • Actor/Role AssignedTo Implementation Event

BTW, many of these relations exists on Figures 77, 97 & 104, but missed in Appendix B tables

pjjv commented Dec 15, 2016

Another one is:

  • Actor/Role AssignedTo Implementation Event

BTW, many of these relations exists on Figures 77, 97 & 104, but missed in Appendix B tables

@jbsarrodie

This comment has been minimized.

Show comment
Hide comment
@jbsarrodie

jbsarrodie Dec 15, 2016

Member

Good catch, I'm adding it to the list

Member

jbsarrodie commented Dec 15, 2016

Good catch, I'm adding it to the list

@pjjv

This comment has been minimized.

Show comment
Hide comment
@pjjv

pjjv Dec 27, 2016

  • Access/Specialization/Aggregation/Composition/Serving/Influence to/from Junction/OrJunction

pjjv commented Dec 27, 2016

  • Access/Specialization/Aggregation/Composition/Serving/Influence to/from Junction/OrJunction
@jbsarrodie

This comment has been minimized.

Show comment
Hide comment
@jbsarrodie

jbsarrodie Dec 27, 2016

Member

Hi,

Re "Access/Specialization/Aggregation/Composition/Serving/Influence to/from Junction/OrJunction"...

No, those relationships are not allowed with a junction, as stated in the standard:
The relationships that can be used in combination with a junction are all the dynamic relationships, as well as assignment, realization, and association.

JB

Member

jbsarrodie commented Dec 27, 2016

Hi,

Re "Access/Specialization/Aggregation/Composition/Serving/Influence to/from Junction/OrJunction"...

No, those relationships are not allowed with a junction, as stated in the standard:
The relationships that can be used in combination with a junction are all the dynamic relationships, as well as assignment, realization, and association.

JB

@pjjv

This comment has been minimized.

Show comment
Hide comment
@pjjv

pjjv Dec 27, 2016

For access please check section 5.2.2, last paragraph before Example 7, on page 28:
If two passive structure elements are, for example, alternative information sources and only one of them is needed by the internal behavior element, an or junction (see Section 5.4.3) can be used.

For serving (paragraph before Example 6):
If two services are alternative solutions and only one of them is needed by the internal behavior element, an or junction (see Section 5.4.3) can be used.

pjjv commented Dec 27, 2016

For access please check section 5.2.2, last paragraph before Example 7, on page 28:
If two passive structure elements are, for example, alternative information sources and only one of them is needed by the internal behavior element, an or junction (see Section 5.4.3) can be used.

For serving (paragraph before Example 6):
If two services are alternative solutions and only one of them is needed by the internal behavior element, an or junction (see Section 5.4.3) can be used.

@jbsarrodie

This comment has been minimized.

Show comment
Hide comment
@jbsarrodie

jbsarrodie Dec 27, 2016

Member

@pjjv That's an inconsistency in the standard itself. It was not meant to be like that. That being said, we had some discussions on that topic inside the ArchiMate Forum and this might change with ArchiMate 3.1.

Regards,

JB

Member

jbsarrodie commented Dec 27, 2016

@pjjv That's an inconsistency in the standard itself. It was not meant to be like that. That being said, we had some discussions on that topic inside the ArchiMate Forum and this might change with ArchiMate 3.1.

Regards,

JB

@pjjv

This comment has been minimized.

Show comment
Hide comment
@pjjv

pjjv Dec 28, 2016

Well, we do not have 3.1 yet ... and in both 2.1/3.0 it is permitted.

For me there is no big distinction between OrJunction on Flow and Access relation. Same holds for Serving/Realization distinction. So being curious about next update of the Standard with explanation.

But as (And)Junction is extremely useful graphical simplification of complex relations, it is nice that it is supported, even on those relations where OrJunction would not in next incarnation of the Standard.

pjjv commented Dec 28, 2016

Well, we do not have 3.1 yet ... and in both 2.1/3.0 it is permitted.

For me there is no big distinction between OrJunction on Flow and Access relation. Same holds for Serving/Realization distinction. So being curious about next update of the Standard with explanation.

But as (And)Junction is extremely useful graphical simplification of complex relations, it is nice that it is supported, even on those relations where OrJunction would not in next incarnation of the Standard.

@jbsarrodie

This comment has been minimized.

Show comment
Hide comment
@jbsarrodie

jbsarrodie Dec 28, 2016

Member

in both 2.1/3.0 it is permitted.

Sorry, but it is not permitted in 2.1: junction can only be used with flow and trigger. And in 3.0 it was not meant to be used with anything other than flow, trigger, assignment, realization, and association (even if, I agree, this rule could be relaxed in upcomming version).

For me there is no big distinction between OrJunction on Flow and Access relation.

Access implies a data flow while a flow can be anything other than data (money, value, trust...) so even if it looks like the same it is not.

Same holds for Serving/Realization distinction.

Serving and Realization are not similar at all: serving means that you provide a service to something, but Realization means that you abstract something into a less tangible one.

But as (And)Junction is extremely useful graphical simplification of complex relations, it is nice that it is supported, even on those relations where OrJunction would not in next incarnation of the Standard.

Archi is meant to support the ArchiMate standard, not add anything on top of it, so junctions will be implemented strictly.

Member

jbsarrodie commented Dec 28, 2016

in both 2.1/3.0 it is permitted.

Sorry, but it is not permitted in 2.1: junction can only be used with flow and trigger. And in 3.0 it was not meant to be used with anything other than flow, trigger, assignment, realization, and association (even if, I agree, this rule could be relaxed in upcomming version).

For me there is no big distinction between OrJunction on Flow and Access relation.

Access implies a data flow while a flow can be anything other than data (money, value, trust...) so even if it looks like the same it is not.

Same holds for Serving/Realization distinction.

Serving and Realization are not similar at all: serving means that you provide a service to something, but Realization means that you abstract something into a less tangible one.

But as (And)Junction is extremely useful graphical simplification of complex relations, it is nice that it is supported, even on those relations where OrJunction would not in next incarnation of the Standard.

Archi is meant to support the ArchiMate standard, not add anything on top of it, so junctions will be implemented strictly.

@Phillipus

This comment has been minimized.

Show comment
Hide comment
@Phillipus

Phillipus Dec 28, 2016

Member

Hi,

just to confirm what JB says, we'll implement what is published in the ArchiMate spec as it is now to avoid confusion. If this changes in an update (2.1) we'll update Archi to reflect that.

Phil

Member

Phillipus commented Dec 28, 2016

Hi,

just to confirm what JB says, we'll implement what is published in the ArchiMate spec as it is now to avoid confusion. If this changes in an update (2.1) we'll update Archi to reflect that.

Phil

@pjjv

This comment has been minimized.

Show comment
Hide comment
@pjjv

pjjv Dec 29, 2016

Phillipus,

I pointed that both Access and Serving Junctions ARE in ArchiMate 3.0 permitted with references to respective sections in the 3.0 Standard:

For access please check section 5.2.2, last paragraph before Example 7, on page 28:
If two passive structure elements are, for example, alternative information sources and only one of them is needed by the internal behavior element, an or junction (see Section 5.4.3) can be used.
For serving (paragraph before Example 6):
If two services are alternative solutions and only one of them is needed by the internal behavior element, an or junction (see Section 5.4.3) can be used.

So despite about informal discussion on some committee, Access and Serving junctions has to be supported now as they are in the 3.0 Standard.

For other usage of junctions, note that derivation rules apply, so try to derive on chain where one of the relations has OrJunction on it.


JB,

I know what is Flow and Serving, I meant that if:

  • Flow has OrJunction specifying alternative flows (forks or merges), the underlying material or information flow can be specified by less abstract access permission, try to express OR without allowing OrJunction on Access relation
  • Realization has OrJunction specifying alternative realizations, the Realization-Serving chain should follow the same principle with respect to derivation rules, otherwise we have an issue in derivation.

Ad Archi is meant to support the ArchiMate standard, not add anything on top of it, so junctions will be implemented strictly.:
Check the standard, how many times it said that (Or)Junction has no semantic interpretation, and how clearly e.g. section D.2 distinguishes ArchiMate junctions from BPMN's gateway semantics. I see no contradiction of my usage of (And)Junctions, especially as I use BPMN/UML when I need detail view on topic.

Personally, for me:

  • I am only using OrJunction as meaning optional with single inflow and outflow (I know it is not Standard, but it is better accepted by stakeholders and it is supported by tools like Archi). Then Standard interpretation of OrJunction is combination of Junction and optional.
    In case of tools that enforce standard by permitting at least one multiflow side (in, out or both) on OrJunction, null element placeholder can be used in model, but not shown on diagram,

pjjv commented Dec 29, 2016

Phillipus,

I pointed that both Access and Serving Junctions ARE in ArchiMate 3.0 permitted with references to respective sections in the 3.0 Standard:

For access please check section 5.2.2, last paragraph before Example 7, on page 28:
If two passive structure elements are, for example, alternative information sources and only one of them is needed by the internal behavior element, an or junction (see Section 5.4.3) can be used.
For serving (paragraph before Example 6):
If two services are alternative solutions and only one of them is needed by the internal behavior element, an or junction (see Section 5.4.3) can be used.

So despite about informal discussion on some committee, Access and Serving junctions has to be supported now as they are in the 3.0 Standard.

For other usage of junctions, note that derivation rules apply, so try to derive on chain where one of the relations has OrJunction on it.


JB,

I know what is Flow and Serving, I meant that if:

  • Flow has OrJunction specifying alternative flows (forks or merges), the underlying material or information flow can be specified by less abstract access permission, try to express OR without allowing OrJunction on Access relation
  • Realization has OrJunction specifying alternative realizations, the Realization-Serving chain should follow the same principle with respect to derivation rules, otherwise we have an issue in derivation.

Ad Archi is meant to support the ArchiMate standard, not add anything on top of it, so junctions will be implemented strictly.:
Check the standard, how many times it said that (Or)Junction has no semantic interpretation, and how clearly e.g. section D.2 distinguishes ArchiMate junctions from BPMN's gateway semantics. I see no contradiction of my usage of (And)Junctions, especially as I use BPMN/UML when I need detail view on topic.

Personally, for me:

  • I am only using OrJunction as meaning optional with single inflow and outflow (I know it is not Standard, but it is better accepted by stakeholders and it is supported by tools like Archi). Then Standard interpretation of OrJunction is combination of Junction and optional.
    In case of tools that enforce standard by permitting at least one multiflow side (in, out or both) on OrJunction, null element placeholder can be used in model, but not shown on diagram,
@jbsarrodie

This comment has been minimized.

Show comment
Hide comment
@jbsarrodie

jbsarrodie Dec 29, 2016

Member

So despite about informal discussion on some committee, Access and Serving junctions has to be supported now as they are in the 3.0 Standard.

I was present during discussions about junction when we created ArchiMate 3.0 and I can say that those relationships are not permitted. The issue you pointed is due to an editorial error (the same remark has been added before each example despite not being relevant for some relationships). This has then been discussed and this will changed in ArchiMate 3.1 (in a way or another, not yet decided). So the official interpretation is: "The relationships that can be used in combination with a junction are all the dynamic relationships, as well as assignment, realization, and association."

For other usage of junctions, note that derivation rules apply, so try to derive on chain where one of the relations has OrJunction on it.
Realization has OrJunction specifying alternative realizations, the Realization-Serving chain should follow the same principle with respect to derivation rules, otherwise we have an issue in derivation.

Derivation rules are not intended to find relationships that exists, but relationship that might exist, so having a junction in the middle of a chain don't change anything, it only provide you two derived relationship instead of one (remember that a junction is not a relationship but an element -relationship connector-).

Flow has OrJunction specifying alternative flows (forks or merges), the underlying material or information flow can be specified by less abstract access permission, try to express OR without allowing OrJunction on Access relation

I don't see an issue as having a junction in the middle of a flow doesn't mean the information is different but only the origin (or target) internal behavior is, so when looking at the details, two access exists because each active structure accesses its data.

Archi is meant to support the ArchiMate standard, not add anything on top of it, so junctions will be implemented strictly

This simply means that only official relationships (those listed on the appendix tables and official definition of concepts) will be implemented. This is required to be sure that nobody creates an ArchiMate model that could not be imported in another tool (through the ArchiMate Exchange Format).

Personally, for me

Personally for me junction is not well defined in ArchiMate. If you really think about it, a junction is a way to put a constraint on several relationships, so I would suggest to make it a visual shortcut (like those defined for Communication Network and Path) for a constraint associated to relationships. This would have the advantage to be allowed for each and every relationships...

Member

jbsarrodie commented Dec 29, 2016

So despite about informal discussion on some committee, Access and Serving junctions has to be supported now as they are in the 3.0 Standard.

I was present during discussions about junction when we created ArchiMate 3.0 and I can say that those relationships are not permitted. The issue you pointed is due to an editorial error (the same remark has been added before each example despite not being relevant for some relationships). This has then been discussed and this will changed in ArchiMate 3.1 (in a way or another, not yet decided). So the official interpretation is: "The relationships that can be used in combination with a junction are all the dynamic relationships, as well as assignment, realization, and association."

For other usage of junctions, note that derivation rules apply, so try to derive on chain where one of the relations has OrJunction on it.
Realization has OrJunction specifying alternative realizations, the Realization-Serving chain should follow the same principle with respect to derivation rules, otherwise we have an issue in derivation.

Derivation rules are not intended to find relationships that exists, but relationship that might exist, so having a junction in the middle of a chain don't change anything, it only provide you two derived relationship instead of one (remember that a junction is not a relationship but an element -relationship connector-).

Flow has OrJunction specifying alternative flows (forks or merges), the underlying material or information flow can be specified by less abstract access permission, try to express OR without allowing OrJunction on Access relation

I don't see an issue as having a junction in the middle of a flow doesn't mean the information is different but only the origin (or target) internal behavior is, so when looking at the details, two access exists because each active structure accesses its data.

Archi is meant to support the ArchiMate standard, not add anything on top of it, so junctions will be implemented strictly

This simply means that only official relationships (those listed on the appendix tables and official definition of concepts) will be implemented. This is required to be sure that nobody creates an ArchiMate model that could not be imported in another tool (through the ArchiMate Exchange Format).

Personally, for me

Personally for me junction is not well defined in ArchiMate. If you really think about it, a junction is a way to put a constraint on several relationships, so I would suggest to make it a visual shortcut (like those defined for Communication Network and Path) for a constraint associated to relationships. This would have the advantage to be allowed for each and every relationships...

@pjjv

This comment has been minimized.

Show comment
Hide comment
@pjjv

pjjv Dec 29, 2016

To me this discussion only shows:

We have text full of relationships omitted from Appendix B, not mentioning those missed in the middle of the table in section B.1. This was start of this thread.

This simply means that only official relationships (those listed on the appendix tables and official definition of concepts) will be implemented. This is required to be sure that nobody creates an ArchiMate model that could not be imported in another tool (through the ArchiMate Exchange Format).

We have hard facts:

  1. We have seen added text to Standard sections that is newly added to 3.0, pls compare to version 2.1.

This simply means that only official relationships (those listed on ... official definition of concepts) will be implemented.

  1. We have ArchiMate Exchange Format (S161) XSD definitions, which permits these junction*relation combinations.

This is required to be sure that nobody creates an ArchiMate model that could not be imported in another tool (through the ArchiMate Exchange Format).

  1. We do not have official OpenGroup errata published.

Ad Derivation rules:

  1. A junction is used to explicitly express that several elements together participate in the relationship (and junction) or that one of the elements participates in the relationship (or junction).
  2. If two structural or dependency relationships r:R and s:S are permitted between elements a, b, and c such that r(a,b) and s(b,c), then a structural relationship t:T is also permitted, with t(a,c) and type T being the weakest of R and S.

==> standard algebra distributive rules applies here between 1st and 2nd rule to be mathematically sound?

I was personally present during many standard & law creation process, all what counts, is the de iure text, with acompanying judicature (maybe meeting notes can enlight the intension), not what was discussed and maybe looks like typo to some members of the committee. Can we agree that Standard and ArchiMate Exchange Format (S161) are the only constraints we have now?
BTW, I saw presentations of some other members of the committee that shows junctions for Specialization relationship as well ...

pjjv commented Dec 29, 2016

To me this discussion only shows:

We have text full of relationships omitted from Appendix B, not mentioning those missed in the middle of the table in section B.1. This was start of this thread.

This simply means that only official relationships (those listed on the appendix tables and official definition of concepts) will be implemented. This is required to be sure that nobody creates an ArchiMate model that could not be imported in another tool (through the ArchiMate Exchange Format).

We have hard facts:

  1. We have seen added text to Standard sections that is newly added to 3.0, pls compare to version 2.1.

This simply means that only official relationships (those listed on ... official definition of concepts) will be implemented.

  1. We have ArchiMate Exchange Format (S161) XSD definitions, which permits these junction*relation combinations.

This is required to be sure that nobody creates an ArchiMate model that could not be imported in another tool (through the ArchiMate Exchange Format).

  1. We do not have official OpenGroup errata published.

Ad Derivation rules:

  1. A junction is used to explicitly express that several elements together participate in the relationship (and junction) or that one of the elements participates in the relationship (or junction).
  2. If two structural or dependency relationships r:R and s:S are permitted between elements a, b, and c such that r(a,b) and s(b,c), then a structural relationship t:T is also permitted, with t(a,c) and type T being the weakest of R and S.

==> standard algebra distributive rules applies here between 1st and 2nd rule to be mathematically sound?

I was personally present during many standard & law creation process, all what counts, is the de iure text, with acompanying judicature (maybe meeting notes can enlight the intension), not what was discussed and maybe looks like typo to some members of the committee. Can we agree that Standard and ArchiMate Exchange Format (S161) are the only constraints we have now?
BTW, I saw presentations of some other members of the committee that shows junctions for Specialization relationship as well ...

@jbsarrodie

This comment has been minimized.

Show comment
Hide comment
@jbsarrodie

jbsarrodie Dec 29, 2016

Member

To me this discussion only shows that you don't want to understand anything that I said, so this is going nowhere, sorry. And the fact that other members show non standard things just means that they prepared things in advance (ie. before standard was agreed) or that they use non standard tools.

Member

jbsarrodie commented Dec 29, 2016

To me this discussion only shows that you don't want to understand anything that I said, so this is going nowhere, sorry. And the fact that other members show non standard things just means that they prepared things in advance (ie. before standard was agreed) or that they use non standard tools.

@Phillipus

This comment has been minimized.

Show comment
Hide comment
@Phillipus

Phillipus Dec 29, 2016

Member

Please note - the exchange format does not enforce any relationship rules.

Member

Phillipus commented Dec 29, 2016

Please note - the exchange format does not enforce any relationship rules.

@pjjv

This comment has been minimized.

Show comment
Hide comment
@pjjv

pjjv Dec 29, 2016

Phillipus,

yes, I know (read those XSDs before), but I did not introduced it as an argument.
I used it only to show its invalidity as a constraint. Others are Relationship Connector treated as an Element (in reality it is Concept only), ignoring of Derivation rules algebra etc.


JB,
the whole discussion shows that you do not want to accept Standard as a whole, including whole section 5.2, 5.4 and 5.6.

Serving, Accessing has written Junction example in Standard 3.0, not present in 2.1.

We can dispute if the paragraphs in section 5.2 or 5.4 are valid or not (similarly as we dispute validity of Appendix B/B.1). But please no more unofficial intensions from often dynamic standardization process at OpenGroup.

We can put it on hold until you during specification of derivation rules for Archi find that you need both Access and Serving to have junction permitted.

pjjv commented Dec 29, 2016

Phillipus,

yes, I know (read those XSDs before), but I did not introduced it as an argument.
I used it only to show its invalidity as a constraint. Others are Relationship Connector treated as an Element (in reality it is Concept only), ignoring of Derivation rules algebra etc.


JB,
the whole discussion shows that you do not want to accept Standard as a whole, including whole section 5.2, 5.4 and 5.6.

Serving, Accessing has written Junction example in Standard 3.0, not present in 2.1.

We can dispute if the paragraphs in section 5.2 or 5.4 are valid or not (similarly as we dispute validity of Appendix B/B.1). But please no more unofficial intensions from often dynamic standardization process at OpenGroup.

We can put it on hold until you during specification of derivation rules for Archi find that you need both Access and Serving to have junction permitted.

@mwherman2000

This comment has been minimized.

Show comment
Hide comment
@mwherman2000

mwherman2000 Jan 12, 2017

Where is the relationship matrix stored in the Archi repo?

mwherman2000 commented Jan 12, 2017

Where is the relationship matrix stored in the Archi repo?

@pjjv

This comment has been minimized.

Show comment
Hide comment
@pjjv

pjjv Jan 13, 2017

If you mean repository - current beta has it in Archi\plugins\com.archimatetool.model_4.0.0.201612151122\model, where file relationhips.xml reside

pjjv commented Jan 13, 2017

If you mean repository - current beta has it in Archi\plugins\com.archimatetool.model_4.0.0.201612151122\model, where file relationhips.xml reside

@mwherman2000

This comment has been minimized.

Show comment
Hide comment
@mwherman2000

mwherman2000 Jan 13, 2017

Thank you ...I also found them here (which I assume maps to the following location): https://github.com/archimatetool/archi/tree/master/com.archimatetool.model/model

mwherman2000 commented Jan 13, 2017

Thank you ...I also found them here (which I assume maps to the following location): https://github.com/archimatetool/archi/tree/master/com.archimatetool.model/model

@mwherman2000

This comment has been minimized.

Show comment
Hide comment
@mwherman2000

mwherman2000 Jan 16, 2017

FYI: I've created a Neo4j graph database based on what is in the relationships.xml file. It's pretty interesting to query and visualize different parts of the relationship matrix. Here's an example.
structural-business and application-simplified2

The first thing that is obvious is the ArchiMate 3.0 spec should include some way to denote the "core" relationships - separate from all of the derived possibilities. The tables in Appendix B of the Spec (http://pubs.opengroup.org/architecture/archimate3-doc/apdxb.html#_Toc451758118) include some 11,000+ relationships for 61 entities ...a bit crazy.

TIP: Also note that if you open the relationships.xml in Excel, you get a nice 3-column spreadsheet (source, target, relations) that can be saved as a CSV file, for example.

Update

Checkout Crossing the EA Chasm: Graphitization of ArchiMate 3.0

mwherman2000 commented Jan 16, 2017

FYI: I've created a Neo4j graph database based on what is in the relationships.xml file. It's pretty interesting to query and visualize different parts of the relationship matrix. Here's an example.
structural-business and application-simplified2

The first thing that is obvious is the ArchiMate 3.0 spec should include some way to denote the "core" relationships - separate from all of the derived possibilities. The tables in Appendix B of the Spec (http://pubs.opengroup.org/architecture/archimate3-doc/apdxb.html#_Toc451758118) include some 11,000+ relationships for 61 entities ...a bit crazy.

TIP: Also note that if you open the relationships.xml in Excel, you get a nice 3-column spreadsheet (source, target, relations) that can be saved as a CSV file, for example.

Update

Checkout Crossing the EA Chasm: Graphitization of ArchiMate 3.0

@pjjv

This comment has been minimized.

Show comment
Hide comment
@pjjv

pjjv Jan 16, 2017

Another missing:

  • Implemetation event flows/triggers Implementation event

pjjv commented Jan 16, 2017

Another missing:

  • Implemetation event flows/triggers Implementation event
@jbsarrodie

This comment has been minimized.

Show comment
Hide comment
@jbsarrodie

jbsarrodie Jan 17, 2017

Member

@pjjv @mwherman2000

Good catch, I've added those issues to the list.

Member

jbsarrodie commented Jan 17, 2017

@pjjv @mwherman2000

Good catch, I've added those issues to the list.

@pjjv

This comment has been minimized.

Show comment
Hide comment
@pjjv

pjjv Jan 23, 2017

Another set:
cf. section 12.2 last paragraph:

  • Artifact realizes Business Object
  • Artifact realizes Contract
  • Technology Process realizes Business Process
  • Technology Process realizes Business Function
  • Technology Process realizes Business Interaction
  • Technology Function realizes Business Process
  • Technology Function realizes Business Function
  • Technology Function realizes Business Interaction
  • Technology Interaction realizes Business Process
  • Technology Interaction realizes Business Function
  • Technology Interaction realizes Business Interaction

pjjv commented Jan 23, 2017

Another set:
cf. section 12.2 last paragraph:

  • Artifact realizes Business Object
  • Artifact realizes Contract
  • Technology Process realizes Business Process
  • Technology Process realizes Business Function
  • Technology Process realizes Business Interaction
  • Technology Function realizes Business Process
  • Technology Function realizes Business Function
  • Technology Function realizes Business Interaction
  • Technology Interaction realizes Business Process
  • Technology Interaction realizes Business Function
  • Technology Interaction realizes Business Interaction
@Phillipus

This comment has been minimized.

Show comment
Hide comment
@Phillipus

Phillipus Jan 23, 2017

Member

@jbsarrodie When's the best time to make changes to relationships.xml? Do we need to make a definitive list and sign them off? Do we need to wait for update the written spec?

Member

Phillipus commented Jan 23, 2017

@jbsarrodie When's the best time to make changes to relationships.xml? Do we need to make a definitive list and sign them off? Do we need to wait for update the written spec?

@jbsarrodie

This comment has been minimized.

Show comment
Hide comment
@jbsarrodie

jbsarrodie Jan 23, 2017

Member

An errata should be published by The Open Group soon. During this activity a fixed table will be published.
IMHO, we should keep the beta until this fixed table is official inside the Archimate Forum, but release the next beta with a fixed (but unofficial) relationships.xml file.

Member

jbsarrodie commented Jan 23, 2017

An errata should be published by The Open Group soon. During this activity a fixed table will be published.
IMHO, we should keep the beta until this fixed table is official inside the Archimate Forum, but release the next beta with a fixed (but unofficial) relationships.xml file.

@mwherman2000

This comment has been minimized.

Show comment
Hide comment
@mwherman2000

mwherman2000 Jan 27, 2017

New: With respect to Technology Processes and Technology Functions, why does Archi not allow Access relationships from these to [Technology] Artifacts? This seems very odd.

mwherman2000 commented Jan 27, 2017

New: With respect to Technology Processes and Technology Functions, why does Archi not allow Access relationships from these to [Technology] Artifacts? This seems very odd.

@Phillipus

This comment has been minimized.

Show comment
Hide comment
@Phillipus

Phillipus Jan 27, 2017

Member

If there are any missing relationships in Archi, it's simply because they are not in the relationship matrix in the official specification document so not enabled. It's easy enough to enable these relationships by editing an XML file, the only thing I need is agreement from users and the green light.

Member

Phillipus commented Jan 27, 2017

If there are any missing relationships in Archi, it's simply because they are not in the relationship matrix in the official specification document so not enabled. It's easy enough to enable these relationships by editing an XML file, the only thing I need is agreement from users and the green light.

@mwherman2000

This comment has been minimized.

Show comment
Hide comment
@mwherman2000

mwherman2000 commented Jan 27, 2017

greenlight

;-)

@Phillipus

This comment has been minimized.

Show comment
Hide comment
@Phillipus

Phillipus Jan 27, 2017

Member

:-) OK, we have a number of relationships that need to be green-lighted in this thread. I'm now wondering what's the best way to make a definitive list.

Member

Phillipus commented Jan 27, 2017

:-) OK, we have a number of relationships that need to be green-lighted in this thread. I'm now wondering what's the best way to make a definitive list.

@mwherman2000

This comment has been minimized.

Show comment
Hide comment
@mwherman2000

mwherman2000 Jan 27, 2017

I go along with jbsarrodie's idea that we wait a short but reasonable amount of time to see what The Open Group produces ...maybe a couple weeks ...maybe the end of February at the latest? ...or just build our own consensus and put Archi 4.0 out as the "people's standard" for ArchiMate.

mwherman2000 commented Jan 27, 2017

I go along with jbsarrodie's idea that we wait a short but reasonable amount of time to see what The Open Group produces ...maybe a couple weeks ...maybe the end of February at the latest? ...or just build our own consensus and put Archi 4.0 out as the "people's standard" for ArchiMate.

@Phillipus

This comment has been minimized.

Show comment
Hide comment
@Phillipus

Phillipus Jan 27, 2017

Member

OK, fair enough. As far as implementation goes, all it amounts to is simply editing the "relationships.xml" file and putting out a new build. I'm happy to do that at any time.

Member

Phillipus commented Jan 27, 2017

OK, fair enough. As far as implementation goes, all it amounts to is simply editing the "relationships.xml" file and putting out a new build. I'm happy to do that at any time.

@jbsarrodie

This comment has been minimized.

Show comment
Hide comment
@jbsarrodie

jbsarrodie Jan 27, 2017

Member

Hi Guys,

I think we'll not have to wait too long (end of feb seems achievable). What you have to understand is that for any of these missing relationships, there are many others that should have been derived and thus are missing too (but more difficult to pinpoint). So this is not straightforward.

In addition, there are also relationships allowed in the officiel table that should not even exist...

Member

jbsarrodie commented Jan 27, 2017

Hi Guys,

I think we'll not have to wait too long (end of feb seems achievable). What you have to understand is that for any of these missing relationships, there are many others that should have been derived and thus are missing too (but more difficult to pinpoint). So this is not straightforward.

In addition, there are also relationships allowed in the officiel table that should not even exist...

@Phillipus

This comment has been minimized.

Show comment
Hide comment
@Phillipus

Phillipus Jan 27, 2017

Member

Thanks, JB.

What would be great would be a definitive matrix of direct relationships in addition to the derived ones. Would make it simpler for tools to implement.

Member

Phillipus commented Jan 27, 2017

Thanks, JB.

What would be great would be a definitive matrix of direct relationships in addition to the derived ones. Would make it simpler for tools to implement.

@jbsarrodie

This comment has been minimized.

Show comment
Hide comment
@jbsarrodie

jbsarrodie Jan 28, 2017

Member

@Phillipus :we're working on it :-)

Member

jbsarrodie commented Jan 28, 2017

@Phillipus :we're working on it :-)

@smileham

This comment has been minimized.

Show comment
Hide comment
@smileham

smileham Mar 8, 2017

Just wanted to update this bug with a number of issues post "beta 7" and Gerben's temporary update.

"Behaviour" Element flow/triggers Junction (and vice versa)
Plateau triggers Plateau #209

smileham commented Mar 8, 2017

Just wanted to update this bug with a number of issues post "beta 7" and Gerben's temporary update.

"Behaviour" Element flow/triggers Junction (and vice versa)
Plateau triggers Plateau #209

@adkendall

This comment has been minimized.

Show comment
Hide comment
@adkendall

adkendall Apr 4, 2017

Scanning through this thread and I see no mention of 'Deliverable Realizes Plateau' - which I think should be allowed (but isn't)

adkendall commented Apr 4, 2017

Scanning through this thread and I see no mention of 'Deliverable Realizes Plateau' - which I think should be allowed (but isn't)

@pjjv

This comment has been minimized.

Show comment
Hide comment
@pjjv

pjjv Apr 11, 2017

Motivation elements shoud realize motivation elements, missing several relations from Figure 32

pjjv commented Apr 11, 2017

Motivation elements shoud realize motivation elements, missing several relations from Figure 32

@Phillipus

This comment has been minimized.

Show comment
Hide comment
@Phillipus

Phillipus Apr 11, 2017

Member

We are going to have an updated relationships matrix soon in Archi.

Member

Phillipus commented Apr 11, 2017

We are going to have an updated relationships matrix soon in Archi.

@mwherman2000

This comment has been minimized.

Show comment
Hide comment
@mwherman2000

mwherman2000 Apr 11, 2017

mwherman2000 commented Apr 11, 2017

@Phillipus

This comment has been minimized.

Show comment
Hide comment
@Phillipus

Phillipus Apr 11, 2017

Member

Sounds good to me!

Member

Phillipus commented Apr 11, 2017

Sounds good to me!

@gabga

This comment has been minimized.

Show comment
Hide comment
@gabga

gabga May 2, 2017

Representation realizes business object is missing.

gabga commented May 2, 2017

Representation realizes business object is missing.

@jyl13

This comment has been minimized.

Show comment
Hide comment
@jyl13

jyl13 May 10, 2017

i have the feeling lot of relationship have been lost since 4.0.0 beta4 When I compare relationships.xml between 4.0.0 beta4 and 4.0.0 pr1 there are a lot of mismatches some are probably correction but other sounds to be new 'error' for example relation between path and application component are 'o' only 4.0.0 pr1, while there where 'fot' and 'fortv' in beta 4.
Here below copare of both section in 'source concept="Path"'
2017-05-10 14_34_54-clipboard

jyl13 commented May 10, 2017

i have the feeling lot of relationship have been lost since 4.0.0 beta4 When I compare relationships.xml between 4.0.0 beta4 and 4.0.0 pr1 there are a lot of mismatches some are probably correction but other sounds to be new 'error' for example relation between path and application component are 'o' only 4.0.0 pr1, while there where 'fot' and 'fortv' in beta 4.
Here below copare of both section in 'source concept="Path"'
2017-05-10 14_34_54-clipboard

@Phillipus

This comment has been minimized.

Show comment
Hide comment
@Phillipus

Phillipus May 10, 2017

Member

There will be even more changes to the relationships very soon in Archi 4 PR2. We will be using the corrected relationships rules. The matrix in the 3.0 spec document is incorrect.

Member

Phillipus commented May 10, 2017

There will be even more changes to the relationships very soon in Archi 4 PR2. We will be using the corrected relationships rules. The matrix in the 3.0 spec document is incorrect.

@roelm

This comment has been minimized.

Show comment
Hide comment
@roelm

roelm May 19, 2017

The help section concerning relationships refers to the Archimate 2.1 specification:
image

roelm commented May 19, 2017

The help section concerning relationships refers to the Archimate 2.1 specification:
image

@Phillipus

This comment has been minimized.

Show comment
Hide comment
@Phillipus

Phillipus May 19, 2017

Member

The help section concerning relationships refers to the Archimate 2.1 specification

I've updated the screenshot for next build.

Member

Phillipus commented May 19, 2017

The help section concerning relationships refers to the Archimate 2.1 specification

I've updated the screenshot for next build.

@Phillipus

This comment has been minimized.

Show comment
Hide comment
@Phillipus

Phillipus May 19, 2017

Member

The relationship rules in Archi 4 PR3 have been put together by Ed Roberts of Elparazim. See http://www.elparazim.com/blog-post/deriving-archimate-3-0-relationships/

From now on, if there are any changes to the relationships rules they will have to be in a format that I can easily consume in order to edit the relationships.xml file. And agreed by all.

Member

Phillipus commented May 19, 2017

The relationship rules in Archi 4 PR3 have been put together by Ed Roberts of Elparazim. See http://www.elparazim.com/blog-post/deriving-archimate-3-0-relationships/

From now on, if there are any changes to the relationships rules they will have to be in a format that I can easily consume in order to edit the relationships.xml file. And agreed by all.

@Phillipus

This comment has been minimized.

Show comment
Hide comment
@Phillipus

Phillipus May 31, 2017

Member

As things have moved on since this was opened, please continue in #243

Member

Phillipus commented May 31, 2017

As things have moved on since this was opened, please continue in #243

@Phillipus Phillipus closed this May 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment