isNavigable & Navigable tagged value inconsistent

[dr_shorthair]

In the Association dialogue in EA it is possible to set the navigability of an association in more than one way:
1. using the "Direction" value on the General tab
2. using the "Navigability" property on the Source Role and Target Role tab.

For most combos set the latter way, this causes the value of the "isNavigable" property of the association-end to be set correctly in the exported XMI document (i.e. in the UML:AssociationEnd/@isNavigable attribute).
 
However, for certain combinations, the value of UML:AssociationEnd/@isNavigable is clearly wrong.

Here's a test model:  
https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/FullMoonTestModels#Test_25 and the XMI
https://www.seegrid.csiro.au/subversion/FullMoon/trunk/resources/xmi-samples/TestAS25.xml

The association between Sample and FT5 is unspecified/non-navigable, but in the XMI both ends are isNavigable="true". Similar problem with FT7.

Worse still with FT8 where the ends are explicitly non-navigable, but both are labelled isNavigable="true"!

(Note that the correct value can be detected by parsing the sourcestyle or deststyle tag, but this is an EA extension, not standard XMI.)

Looks like a pretty serious bug?

[«Midnight»]

Quite correct Doctor,

Paolo has long railed about this schism in the EA paradigm. It shows up in at least a couple of places in the product.

Perhaps it is a side effect of the transition - within either or both of EA and the UML specifications - from UML 1.x to 2.x. Perhaps it is legacy 'hair' in the EA program. At this point in time, who knows?

I don't have a handy reference to Paolo's earlier threads - they go back a long time - but perhaps he'll provide a reminder.

Meanwhile, I agree something needs to be done. This issue is so long in the tooth that 'fixing' either of the two paths you point to would break a lot of already-deployed stuff, thus 'fixing' - making permanent and unchanging - bugs in previously usable add-ins.

Perhaps a new, correct (in the semantics of UML) 'version' of these things could be developed. It would have some different means of invocation, which could supplant the current means in the UI. [You can invoke either behavior from the UI now, giving you an inconsistent model.] This would leave legacy add-ins functioning, not break legacy models. Going forward, as long as the new feature path were used, development of add-ins and models would be free from side effects related to this issue.

Just a thought...

David

PS: But first you - the greater you, the user community - need to make umteen feature requests and bug reports to Sparx. Somehow this needs to be seen as a bug that breaks the EA interpretation of UML, not as a nice-to-have new feature.

[dr_shorthair]

OK - I've made this an official bug report.

[Paolo F Cantoni]

Paolo has long railed about this schism in the EA paradigm. It shows up in at least a couple of places in the product.

Navigability and aggregation may have a bearing...

Paolo

[dr_shorthair]

Thanks - I made a comment - http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1113816520/0#7