Author Topic: ControlFlow not bi-directional  (Read 392 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5510
  • Karma: +55/-37
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
ControlFlow not bi-directional
« on: March 09, 2017, 11:03:15 am »
An ArchiMate Flow relationship is implemented using a ControlFLow connector.  It seems that ControlFlow connectors can only be defined as Source -> Destination. Is that true?

As a consequence, bi-directional flows cannot be defined.  A quick look at the ArchiMate 3.0 specification doesn't seem to preclude this.

Thoughts, before I put in a Bug report?
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6046
  • Karma: +40/-3
    • View Profile
Re: ControlFlow not bi-directional
« Reply #1 on: March 09, 2017, 05:31:24 pm »
From what I can tell from the specification and schema for the interchange format. All ArchiMate connections are implicitly unidirectional. (Direction is specified by a single source and target attribute in the xsd)

As a result, any attempt to do this will likely cause interchange issues. So I would say you are better off using two connectors.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5510
  • Karma: +55/-37
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: ControlFlow not bi-directional
« Reply #2 on: March 09, 2017, 05:51:27 pm »
From what I can tell from the specification and schema for the interchange format. All ArchiMate connections are implicitly unidirectional. (Direction is specified by a single source and target attribute in the xsd)

As a result, any attempt to do this will likely cause interchange issues. So I would say you are better off using two connectors.
Interestingly, I still have a source and destination (the primary direction). 

And anyway, Associations can be marked as bi-directional even ArchiMate_Associations.

So is it the case that a ControlFlow is ONLY "Source -> Destination"?

In the general case, this is (I think) an unnecessary restriction.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Glassboy

  • EA User
  • **
  • Posts: 757
  • Karma: +47/-43
    • View Profile
Re: ControlFlow not bi-directional
« Reply #3 on: March 10, 2017, 07:28:17 am »
From what I can tell from the specification and schema for the interchange format. All ArchiMate connections are implicitly unidirectional. (Direction is specified by a single source and target attribute in the xsd)

As a result, any attempt to do this will likely cause interchange issues. So I would say you are better off using two connectors.

Plus archimate connectors are actually the reverse direction to their supposed UML counterparts. 

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5510
  • Karma: +55/-37
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: ControlFlow not bi-directional
« Reply #4 on: March 10, 2017, 10:49:57 am »
From what I can tell from the specification and schema for the interchange format. All ArchiMate connections are implicitly unidirectional. (Direction is specified by a single source and target attribute in the xsd)

As a result, any attempt to do this will likely cause interchange issues. So I would say you are better off using two connectors.

Plus ArchiMate connectors are actually the reverse direction to their supposed UML counterparts.
But that's only because UML got it wrong first...  ;)

I DO find ArchiMate relationships more semantically consistent than UML ones.

In any event, in our extended ArchiMate MDG, we see NO reason to not have bi-directional ControlFlows (on which the Flow relationship is based).

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Glassboy

  • EA User
  • **
  • Posts: 757
  • Karma: +47/-43
    • View Profile
Re: ControlFlow not bi-directional
« Reply #5 on: March 10, 2017, 11:56:33 am »
I DO find ArchiMate relationships more semantically consistent than UML ones.

In any event, in our extended ArchiMate MDG, we see NO reason to not have bi-directional ControlFlows (on which the Flow relationship is based).

I don't know if I agree.  I find they confuse people.  There's a whole lot of discussion of fora such as LinkedIn and none of the answers really satisfy the objective of all of the people understanding what they look at when they look at an Archimate viewpoint.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5510
  • Karma: +55/-37
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: ControlFlow not bi-directional
« Reply #6 on: March 15, 2017, 06:02:43 pm »
OK, so more "grist to the mill".

We decided that in our modelling environment, we would allow ControlFlows to be bidirectional.  Since the UI disabled the direction property of the ControlFlow, we changed the value directly in the t_connector table.  Unsurprisingly, the direction property was still disabled, but what was surprising was that the value displayed in the dialog was still "Source -> Destination" not Bi-Directional!  Imagine our further surprise when the shapescript we updated DID show the bidirectional addition, correctly responding to the Source shape's:
Code: [Select]
if (hasproperty("direction","Bi-Directional"))
{
...
}
snippet

EAUI of the month award!

So, given what we've found, I think I should add a feature request to allow ControlFlow direction to be altered.  (We're not interested in exchange with other than our modelling environment at this stage)
« Last Edit: March 15, 2017, 06:08:04 pm by Paolo F Cantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5510
  • Karma: +55/-37
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: ControlFlow not bi-directional
« Reply #7 on: March 16, 2017, 06:14:47 pm »
So while the UI doesn't show the correct setting in the DB, if you change any property other than the direction, when you save the connector, the direction is reset to "Source -> Destination" even though you didn't ask for that.

Bug report time.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 7448
  • Karma: +137/-20
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: ControlFlow not bi-directional
« Reply #8 on: March 16, 2017, 11:33:53 pm »
Archimate used to be plain wrong in the way they interpreted the direction and the placement of roles in their own metamodel.
I've seen that this has been improved in the latest version of the specs (3.0) but it makes me doubt the ability of meta-model makers if they make these kind of rooky mistakes in what should be a highly consistent and QA-ed meta-model.

In general my opinion is that the quality of the specifications of Archimate is far below the quality of something like UML or BPMN. Mostly because of the vagueness (e.g. whats the difference between a Business Function and Business Service, good luck figuring that out using only the Archimate specifications) and because they basically allow anything to be connected to anything else without defining a meaning to that link.

Geert

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6046
  • Karma: +40/-3
    • View Profile
Re: ControlFlow not bi-directional
« Reply #9 on: March 17, 2017, 08:55:13 am »
We decided that in our modelling environment, we would allow ControlFlows to be bidirectional.  Since the UI disabled the direction property of the ControlFlow, we changed the value directly in the t_connector table.  Unsurprisingly, the direction property was still disabled, but what was surprising was that the value displayed in the dialog was still "Source -> Destination" not Bi-Directional!
if you change any property other than the direction, when you save the connector, the direction is reset to "Source -> Destination" even though you didn't ask for that.

What you are seeing is that EA is displaying the appropriate value for its data model, which says that a control flow should only be "Source -> Destination", and then saving the contents of the dialog when you click save. Both behaviours are consistent with disabling the control in the first place as they are preserving the data model.

Imagine our further surprise when the shapescript we updated DID show the bidirectional addition, correctly responding to the Source shape's:
Code: [Select]
if (hasproperty("direction","Bi-Directional"))
{
...
}
snippet
Yes, this is inconsistent with the UI. However, as it's only possible by directly modifying the values in the database I would not classify this as an issue. You can and will cause worse issues by changing the database directly.

So, given what we've found, I think I should add a feature request to allow ControlFlow direction to be altered.  (We're not interested in exchange with other than our modelling environment at this stage)
I'm not sure of your rationale here. Because you can cause behavioral anomalies by changing data behind EA's back you think that is a reason for EA to allow you to make that change in the UI? I'd recommend just considering yourself lucky that you don't break more by directly changing the database.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5510
  • Karma: +55/-37
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: ControlFlow not bi-directional
« Reply #10 on: March 17, 2017, 11:10:36 am »
I've received a formal response from Sparx saying (paraphrased) "tough".

So I rechecked the UML and ArchiMate specifications, I now believe that UML ControlFlow is not the correct underlying type to implement an ArchiMate Flow since the semantics are not the same.  An ArchiMate Trigger is much more closely related semantically to ControlFlow.  So I guess, I'm NOW comfortable with ControlFlow behaviour being the way it is.

I will discuss with my colleagues and determine what we will do in our MDG.  However, can you guys suggest which underlying type might be more useful to allow us to implement bi-directional flows (we use them particularly in derived by union relationships)  An ArchiMate Access (which can be Bi-Directional) is used between an active and a passive item.  ArchiMate Flows are used between active items (and decompose to two Accesses and an intervening passive item).  You can create derived relationships (by the union of two flows that flow in opposite directions to create a Bi-Directional Flow).  I guess my preference is to use Association as does Access.

If you allow derived relationships (which ArchiMate does) then you have to allow Bi-Directional derived Flows - so the Metamodellers got it wrong (as Geert said).

Thoughts?
Paolo
« Last Edit: March 17, 2017, 11:14:25 am by Paolo F Cantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Glassboy

  • EA User
  • **
  • Posts: 757
  • Karma: +47/-43
    • View Profile
Re: ControlFlow not bi-directional
« Reply #11 on: March 17, 2017, 11:17:05 am »
If you allow derived relationships (which ArchiMate does) then you have to allow Bi-Directional derived Flows - so the Metamodellers got it wrong (as Geert said).

The current commentary on LinkedIn from members of the OMG Archimate cabal is that relationships flow in the same direction as the enterprise.  Personally I think that is a meaningless statement.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5510
  • Karma: +55/-37
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: ControlFlow not bi-directional
« Reply #12 on: March 17, 2017, 01:53:15 pm »
If you allow derived relationships (which ArchiMate does) then you have to allow Bi-Directional derived Flows - so the Metamodellers got it wrong (as Geert said).

The current commentary on LinkedIn from members of the OMG Archimate cabal is that relationships flow in the same direction as the enterprise.  Personally I think that is a meaningless statement.
What do you mean you think it is a meaningless statement, it IS a meaningless statement.

An example of "seduction by narrative".  Sheesh!

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Glassboy

  • EA User
  • **
  • Posts: 757
  • Karma: +47/-43
    • View Profile
Re: ControlFlow not bi-directional
« Reply #13 on: March 20, 2017, 01:52:21 pm »
What do you mean you think it is a meaningless statement, it IS a meaningless statement.

I often feel like the whale from Hitchhiker's Guide to the Galaxy, only without the bowl of petunias.  :D

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 5510
  • Karma: +55/-37
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: ControlFlow not bi-directional
« Reply #14 on: March 23, 2017, 02:42:34 pm »
FWIW, on advice from the Sparxians, we have decided to use InfromationFlow as the base relationships type for an ArchiMate "Flow" in our MDG (as opposed to the supplied ControlFlow).   Works a treat!

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!