Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 364066

Summary: [SysML Block Definition Diagram] For an association end in SysML (contrary to UML >=2.2), being navigable should be equivalent to being owned by source classifier.
Product: [Modeling] Papyrus Reporter: Alain Le Guennec <alain.leguennec>
Component: CoreAssignee: Project Inbox <mdt-papyrus-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: benoit.maggi, borlander, cletavernier, eclipse-bugzilla, klaas.gadeyne, rschnekenburger, yann.tanguy
Version: 1.1.0   
Target Milestone: M6   
Hardware: All   
OS: All   
See Also: https://git.eclipse.org/r/38473
https://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=db0896499b93880a4b2b5e629c96b1a7ade19503
Whiteboard:
Attachments:
Description Flags
Illustrates the bug/regression none

Description Alain Le Guennec CLA 2011-11-17 12:20:53 EST 
As stated in the SysML specification:
"SysML excludes variations of associations in UML in which navigable ends can be owned directly by the association. In SysML, navigation is equivalent to a named property owned directly by a block. The only form of an association end that SysML allows an association to own directly is an unnamed end used to carry an inverse multiplicity of a reference property. This unnamed end provides a metamodel element to record an inverse multiplicity, to cover the specific case of a unidirectional reference that defines no named property for navigation in the inverse direction. SysML enforces its equivalence of navigation and ownership by means of constraints that the block stereotype enforces on the existing UML metamodel"

On BDD, Papyrus *almost* enforces this equivalence, but not quite:
-Making an end owned by the classifier makes it navigable => OK
-Making an end owned by the association makes it non-navigable => OK
-Making an end non-navigable makes it owned by the association => OK
-Making an end navigable does not change its ownership => *NOK*
Only the last case (switching from non-navigable to navigable) does not seem to work (and therefore fails to create a reference in the corresponding block).
Comment 1 Klaas Gadeyne CLA 2013-11-06 09:47:50 EST 
Verified in 0.10 nightly build.
Comment 3 Camille Letavernier CLA 2015-03-24 14:02:33 EDT 
> Gerrit change https://git.eclipse.org/r/38473 was merged to [master].

I close the task
Comment 4 Klaas Gadeyne CLA 2015-05-13 03:53:52 EDT 
Created attachment 253428 [details]
Illustrates the bug/regression

Please have a look to the attachment.  I created this one using the latest nightly build from luna, using the scenario described in Comment #1.
I don't know whether this is a regression, which went undetected due to the lack of a unit test, or if this was never fixed properly, but please re-open.

As a side note, if any of the SysML 1.4 developers is cc: here, I wonder if (and how) such kind of issues are being tackled by the new 1.4 editors?
Comment 5 Klaas Gadeyne CLA 2015-07-01 18:08:33 EDT 
Seems to work fine for the mars sysml 1.1 editors now (visualization seems to be screwed up though), but not for the sysml 1.4 editors!

Rationale from 8.3.2.3 Block:

SysML excludes variations of associations in UML in which navigable ends can be owned directly by the association. In SysML, navigation is equivalent to a named property owned directly by a block. The only form of an association end that SysML allows an association to own directly is an unnamed end used to carry an inverse multiplicity of a reference property. This unnamed end provides a metamodel element to record an inverse multiplicity, to cover the specific case of
OMG SysMLTM, v1.4 51
a unidirectional reference that defines no named property for navigation in the inverse direction. SysML enforces its equivalence of navigation and ownership by means of constraints that the block stereotype enforces on the existing UML metamodel.

So Blocks #440082