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.

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.

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.

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).

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.

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:

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)

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.

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.

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.

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.

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).