Community
Participate
Working Groups
Forbid manual move of a Association owned property in another Classifier -> this result in an inconsistent Association and should be forbidden
Can be reproduced with 0.10.X
New Gerrit change created: https://git.eclipse.org/r/92179
Reproduced today on Neon.3, using SysML 1.4. This seems critical to avoid inconsistent models, right?
Note that, given the fact that Bug 431251 is also still unsolved, it is currently impossible to move a part from one type to another type by any means. As stated in the above bug, this is a common use case in Systems Engineering...
Hi Klaas, the patch is still in the review state. I think that it will be merged soon. Only manual move of the property of an association should be forbidden.
Created attachment 267912 [details] Invalid model I'm not sure only properties below associations cannot be moved as is. See attached screenshot of a SysML 1.4 Model I created without moving any properties below an association. Pretty flawed, right?
Hi Klaas, Sorry, but I am not sure that I understand your problem. In fact, the patch forbids the move of association property in Model Explorer but not in the diagram editor. In the diagram editor, the endpoing (anchor) of an association could be moved freely. Could you explained more about your problem?
(In reply to Thanh Liem PHAN from comment #7) > Hi Klaas, > > Sorry, but I am not sure that I understand your problem. > In fact, the patch forbids the move of association property in Model > Explorer but not in the diagram editor. In the diagram editor, the endpoing > (anchor) of an association could be moved freely. > > Could you explained more about your problem? I didn't do anything in the diagram editor for creating this situation. Steps to reproduce: - Create a SysML 1.4 model with a BDD and draw 3 (unconnected) Blocks 1, 2 3 on it - Create a partAssociation between Block1 and Block3. So far, so good. - In the model explorer, drag the part property block3:Block3 from Block1 to Block2. New situation is somewhat confusing from a naming point of view, but still correct. - Now select the block1: Block2 memberEnd from A_block3_block1 in the model explorer and change its type to Block1 via the properties view and * drag the A_block3_block1 association into the diagram; * drag the block3:Block3 property into the diagram (onto Block2). Result (see screenshot in attach): - IMO The model is semantically invalid (yet triggers no validation errors). I.e. given the diagram, I would expect block3:Block3 to be a part property of Block1. Yet, in the model explorer, it is a part property of Block2! - the part property block3 is drawn as a port on the IBD instead of an attribute?? Note: - I know this is a stupid set of actions to carry out, but I ended up with (IMO 'corrupt'/'incorrect'/'invalid') SysML models which look like a more complicated version of the above model without anyone ever having carried out this set of stupid actions. - I also don't think this is a SysML problem, or at least only partially...
I can not reproduce your steps. As soon as, the part property block3:Block3 is moved from Block1 to Block2. Its type is also updated also. And when the association is dragged into the diagram. It is displayed normally. Test is done with the latest version of Oxygen.
Hi Thanh, Klaas indicated that he produced the bug on Neon.3. I guess that major issues (corrupt model) are still fixed on the Neon.3 path as well? For your information: * I can reproduce it with the given steps on my Neon.3 * In contrast to Klaas, I get a validation error, but one that has nothing to do with the intended issue: the SysML constraint 8.3.2.3 Block [3] complaining that the name of the Association's ownedEnd should be empty.
Ah yes, sorry Klass, you did indicate that it was on Neon.3.
Gerrit change https://git.eclipse.org/r/92179 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=f96c8b188418a1778aa4f9663a16068e20a9f6eb
(In reply to Thanh Liem PHAN from comment #9) > I can not reproduce your steps. As soon as, the part property block3:Block3 > is moved from Block1 to Block2. Its type is also updated also. Yes, but this is what I stated, right? [/quote] - In the model explorer, drag the part property block3:Block3 from Block1 to Block2. New situation is somewhat confusing from a naming point of view, but still correct. [/quote] The errors only occur after doing the _next_ step! > And when the association is dragged into the diagram. It is displayed > normally. > > Test is done with the latest version of Oxygen. I just check with the oxygen nightly build of papyrus, and using UML class diagrams. The behaviour is _exactly_ the same, apart from the fact that class3 : Class3 attribute from Class2 cannot be dragged inside the attribute compartment of class2
Created attachment 267982 [details] Same reproduction, but using Oxygen, and without SysML
You are right Klass, we don't have the same behavior between UML Class diagram and SysML BDD. In UML Class diagram, if we select the Class 2 (with its property Class3), then F4 to show the element contents, we see no properties from composite association. But in SysML Class diagram, do the same thing, we see that the property Class3 is listed there. That means in UML Class diagram, we distinguises well (1) a normal property (2) a property from an association While this is not the case in SysML. OK, so this is definitely a bug in SysML BDD Diagram. I've created the bug 515832 for this problem.
Hi everyone, The patch has been merged, so is this bug considered "fixed"? If not can you enlighten me on the ongoing works. SysML 1.4 is currently reusing the association from UML so it should not have any differences, except: - possibility to create "Shared" and "Part" Association, only to change the default aggregation value - validation error since the UML association set a property name by default which we don't want in SysML. There is a major change in Papyrus UML between Neon and Oxygen, this patch https://git.eclipse.org/r/#/c/94080/ add some associations (by changing/adding some element type) @Thanh: Can you precise me the step by step use case that is working in UML and not in SysML 1.4? Ths, benoît
Hi Benoit, In my opinion, this bug is fixed as it is related to the DnD of association property in the Model Explorer. To reproduce the problems that we've discussed above, i described more detail in the new bug 515832. Tell me if it is not clear for you.
Hi both, (In reply to Thanh Liem PHAN from comment #17) > Hi Benoit, > > In my opinion, this bug is fixed as it is related to the DnD of association > property in the Model Explorer. > > To reproduce the problems that we've discussed above, i described more > detail in the new bug 515832. Tell me if it is not clear for you. In my opinion, the bug is _not_ fixed (unless I interpret the bug wrongly - which could be since the bug title is rather already formulated as a _solution_ instead of as a _problem_). The (numbered [*]) steps below clearly lead to an _inconsistent_ model, even with the patch applied. The only difference I noticed between UML (oxygen-nightly) and SysML 1.4 (neon-nightly) is in 'result b)' below , where * in the UML model the property class3 cannot be dragged into the Attributes compartment of Class2 * in the SysML model the property block3 can be dragged into the Attribues compartment of Block2, but is visualized using a port notation (whereas it is not a port) HTH, Klaas -- Steps to reproduce (replace SysML by UML etc for the UML reproduction): 1/ Create a SysML 1.4 model with a BDD and draw 3 (unconnected) Blocks 1, 2 3 on it 2/ Create a partAssociation between Block1 and Block3. So far, so good. 3/ In the model explorer, drag the part property block3:Block3 from Block1 to Block2. New situation is somewhat confusing from a naming point of view, but still correct. 4/ Now select the block1: Block2 memberEnd from A_block3_block1 in the model explorer and change its type to Block1 via the properties view and * drag the A_block3_block1 association into the diagram; * drag the block3:Block3 property into the diagram (onto Block2). Result (see screenshot in attach): a) [UML+SysML] IMO The model is semantically invalid (yet triggers no validation errors). I.e. given the diagram, I would expect block3:Block3 to be a part property of Block1. Yet, in the model explorer, it is a part property of Block2! b) [SysML] the part property block3 is drawn as a port on the IBD instead of an attribute?? [*] I added some numbers and letters to avoid confusion...
I can't reproduce it in core papyrus. I'll move it to sysml and test it there with a new installation.
