Apply Locks to Connectors - why is it not symmetrical?

[Ian Mitchell]

As I underdstand it, the option "Apply Locks to all Connectors" is a refinement of the EA locking mechanism: don't just lock element, lock connectors as well.
But I don't quite understand why it works the way it does.
As an example, say that the option is ON, and I have two elements, A and B, and A is in a package which is locked to me, but B is not.
When I try to draw a connector from A (the locked element) to B (the unlocked one) then EA puts up a helpful error message ("Warning: Connector cannot be created....").

Excellent: expected behaviour.

But when I try to draw a connector the other way around, from B to A, EA will allow me to create almost any kind of connector.
If the connector is directionless - say an Association - then its just strange. A to B doesn't work but B to A does, so if the user starts drawing from A, no connector, if from B, they get a connector.
If the direction is meaningful (Dependency, Realization etc) then EA seems to allow inbound (B to A) connections, but not allow outbound ones. Which at least is self-consistent. So I can make A 'a part of' B, but not B a part of A.

Does anyone else feel this is a bit strange?

I'm tempted to expand the function of this option by intercepting the 'create connector' event, and saying NO when either end of the connector is locked to the current user. That way, I'll get behaviour I expected: no connectors means no connectors. Not 'only inbound connectors, or directionless ones when you start from an un-locked element'.
 
Can anyone see a problem with making the locking more restrictive? Or am I 20 years late into a debate that has already happened?

[Geert Bellekens]

Can anyone see a problem with making the locking more restrictive? Or am I 20 years late into a debate that has already happened?

Yes, I have situation where I have a locked package with business processes.

My functional analist are making use cases that realize those business processes, and as such they create a dependency from the use case to the business process.

If your proposal was followed, this would not be possible without unlocking the business process package.

Most relations are unidirectional, so only the source should be writeable to be able to create a new relation.
Exception are the bi-directional associations. For those I could understand that both ends should be writeable.

Geert

[qwerty]

Exception are the bi-directional associations. For those I could understand that both ends should be writeable.

EA has only uni-directional connectors (I think like UML). There's source and target. Navigation arrows are a setting that's repsected only in the rendering but does on no way influence which is source and which is target.

q.

[Paolo F Cantoni]

Exceptions are bi-directional associations. For those, I could understand that both ends should be writeable.

EA has only uni-directional connectors (I think like UML). There's a source and target. Navigation arrows are a setting that's respected only in the rendering but does in no way influence the source and the target.

q.

The OLD Navigability vs Directionality conflation...

I like Ian's suggestion, but Geert makes a good argument.  I suspect (live thought - no analysis) that the answer rests with the conceptual semantics of the particular relationship.
In other words, the rules may vary depending on the nature of the relationship.

Also, as many will recall, I'm a great proponent of qwerty's observation that you can't draw a line without an origin and a destination.  Consequently, the arc cannot be created if the origin is locked.  If the destination is locked, then it depends...  (It may be one of those "the exception proves the rule" cases)

Some thoughts,
Paolo

[Edit: FWIW: Once I got to work, I posed the question to one of my fellow "Centre of Excellence" colleagues (not a big modeller, but a great coder), and he agrees it's likely a question of the semantics of the relationship as to whether it should be allowed or not).]

[Geert Bellekens]

I agree with Paolo, it depends on the "dependency" direction.
Who depends on who.

In most cases the source depends on the target. So adding a relation from the source to the target effectively changes the target, without changing the source.

Associations in UML don't have a source or target. They have one in EA, but that is a technical solution, not a functional property.
You could think of rules when to allow associations (e.g. look at the owned property thing), but the safest bet is to restrict the creation of an association if either source or target are locked.

In ArchiMate there is (to my frustration) even a example of the reverse logic. The relation Serving (a.k.a. UsedBy in v2) has an inverse dependency.
If I create a serving relation from A to B, that means that B depends on A.

To conclude: in most cases following the source to target logic makes sense, but there are exceptions.

Geert

[qwerty]

I'd say: bi-directional associations are a shortcut for two associations in either direction.

q.

[Modesto Vega]

Having read the whole thread, I am concluding that there are 2 use cases: one for directionless connectors and another for directional connectors.

For directionless connectors, I agree with Ian: if one of the elements is in a locked package, it should not be possible to create a new association involving one of the elements.

For directional connectors (e.g., realizations, dependencies and so on), I definitely see Geert's point. The example that Geert mentions is what I would describe as a "ways of working" example, and, as a result, I am tempted to suggest that whether new directional connectors involving one locked element can be created or not should be configurable.

But the UML specification v2.5 (https://www.omg.org/spec/UML/2.5.1/PDF), section 7.8 Classifier Descriptions, complicates matters a bit, it defines more relationships than just directionless and directional.

P.S.: It may not help that connectors in Sparx EA are 2nd class citizens and not proper classes as per the specification.

[Paolo F Cantoni]

I'd say: bi-directional associations are a shortcut for two associations in either direction.

q.

Formally, binary associations are the composition of two unidirectional access functions (one being the inverse of the other - for example, parent of - child of).
See Jean Raymond Abrial's seminal "Data Semantics" article from the 1970s!

Paolo

[qwerty]

Hu, I know took a look into UML 2.5. Turns out that I got confused by EA's definition which puts anything into t_connector. There is no UML element named Association. Only (abstract) Relationship which relates any number of Elements. And DirectedRelationship which has Source and Target.

q.

[Geert Bellekens]

Hu, I know took a look into UML 2.5. Turns out that I got confused by EA's definition which puts anything into t_connector. There is no UML element named Association. Only (abstract) Relationship which relates any number of Elements. And DirectedRelationship which has Source and Target.

q.

There is in fact. Look at §11.8.1 on page 219

An association is both specialization of Classifier and Relationship, and it is linked to [2..*] memberends.
But definitely no Source or Target anywhere near the Association.

Geert

[qwerty]

When did you have time to read and remember all that? The word Association is used so often there that it's basic definition drowned. Alas, the EA implementation is a conflation of DirectedRelation with Assocation.

q.

[Geert Bellekens]

The word Association is used so often there that it's basic definition drowned.

I know, but I also remember looking up the details a few years ago, so I knew it existed.
So it was a matter of Ctrl-Shift-F for "Association" and scrolling through the results until I found "Association [Class]"

Geert

[Modesto Vega]

[SNIP]
There is no UML element named Association. Only (abstract) Relationship which relates any number of Elements. And DirectedRelationship which has Source and Target.

[SNIP]
An association is both specialization of Classifier and Relationship, and it is linked to [2..*] memberends.
But definitely no Source or Target anywhere near the Association.

This exactly why I referred to the specification. Association does not exist as an abstract relationship; it only exists as a specialisation of Relationship with the other specialisation being DirectedRelationship.

This is confusing in this context.

[Ian Mitchell]

Thanks a lot to everyone for their wisdom.
My summary of all of this is that most connections DO have what we might call semantic direction: they go from somewhere to somewhere else. So the EA approach is both sensible and consistent.
I think I will, however, write something to remove the case of a simple, fully-symmetrical 'association' type connector.

[Paolo F Cantoni]

Thanks a lot to everyone for their wisdom.
My summary of all of this is that most connections DO have what we might call semantic direction: they go from somewhere to somewhere else. So the EA approach is both sensible and consistent.
I think I will, however, write something to remove the case of a simple, fully-symmetrical 'association' type connector.

Hi Ian,
Would you elaborate on exactly what you are proposing?  It's not clear to me.  Apropos your point in the browser post, we users might be able to provide something useful...

Paolo