Sparx Systems Forum

Discussion => Uml Process => Topic started by: Paolo F Cantoni on March 09, 2017, 11:03:15 am

Title: ControlFlow not bi-directional
Post by: Paolo F Cantoni 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
Title: Re: ControlFlow not bi-directional
Post by: Simon M 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.
Title: Re: ControlFlow not bi-directional
Post by: Paolo F Cantoni 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
Title: Re: ControlFlow not bi-directional
Post by: Glassboy 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. 
Title: Re: ControlFlow not bi-directional
Post by: Paolo F Cantoni 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
Title: Re: ControlFlow not bi-directional
Post by: Glassboy 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.
Title: Re: ControlFlow not bi-directional
Post by: Paolo F Cantoni 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)
Title: Re: ControlFlow not bi-directional
Post by: Paolo F Cantoni 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
Title: Re: ControlFlow not bi-directional
Post by: Geert Bellekens 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
Title: Re: ControlFlow not bi-directional
Post by: Simon M 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.
Title: Re: ControlFlow not bi-directional
Post by: Paolo F Cantoni 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
Title: Re: ControlFlow not bi-directional
Post by: Glassboy 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.
Title: Re: ControlFlow not bi-directional
Post by: Paolo F Cantoni 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
Title: Re: ControlFlow not bi-directional
Post by: Glassboy 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
Title: Re: ControlFlow not bi-directional
Post by: Paolo F Cantoni 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
Title: Re: ControlFlow not bi-directional
Post by: Sunshine on April 20, 2017, 10:05:41 am
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
One of the benefits of creating your own MDG. I did the same thing for my ArchiMate based MDG.

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

Yeah I totally agree I've been using ArchiMate Notation for close to 10 years before there was a spec. and have to use some artistic licence with its interpretation. If only they'd use a modelling tool to write the spec instead of visio and Word they may have better quality and consistency. Funny that people preaching stuff via a specification about modelling but don't actually use a modelling tool to ensure its correct. Bah! amateurs aye? The world is full of them and its seems to be getting worse.

I'm not religious but these words form the bible are fitting "Father, forgive them, for they do not know what they are doing."   :(
Title: Re: ControlFlow not bi-directional
Post by: qwerty on April 20, 2017, 04:13:15 pm
Whom are you talking of? Oh My God? Their error-prone PDF spec is based on "models" which merely are used to create diagrams. Amateurs? Yes, professional amateurs.

q.
Title: Re: ControlFlow not bi-directional
Post by: Sunshine on April 25, 2017, 02:46:36 pm
Whom are you talking of? Oh My God? Their error-prone PDF spec is based on "models" which merely are used to create diagrams. Amateurs? Yes, professional amateurs.

q.
Just keep those professional amateurs away from designing and building aircraft. Just imagine if an aircraft manufacturer built a plane with the same lack of professional integrity as those guys wrote those Archimate Specs. Would you fly in it?
Title: Re: ControlFlow not bi-directional
Post by: qwerty on April 25, 2017, 03:25:12 pm
The OMG amateurs don't build airplanes. But airplane engineers use those amateur's spec to build airplanes. I'm flying less frequent these days.

q.
Title: Re: ControlFlow not bi-directional
Post by: Sunshine on April 26, 2017, 08:08:25 pm
The OMG amateurs don't build airplanes. But airplane engineers use those amateur's spec to build airplanes. I'm flying less frequent these days.

q.

Just to be clear I was talking about ArchiMate Standard by the Open Group and how it lacks robustness and consistency. Nothing to do with OMG or its specs. Point was there was a lack of quality that wouldn't be tolerated in some areas.

FYI  - Aircraft engineers use ISO/ IEEE /AS/ MIL-Q etc standards to build aircraft so rest assured air travel is still the safest form of travel and they ARE PROFESSIONAL ENGINEERS who design and build them.

Notations like UML, SysML etc may be used to design along with some formal methods to meet safety critical needs as well as comprehensive testing to validate.

Worked in aviation industry for 9 years where I designed and built avionic systems so had first hand knowledge of it all.

But alas we drift off topic so lets call it a day.