Community
Participate
Working Groups
In 0.8.0 RC3 Actor cannot own property, as a result association between an actor and another classifier is only possible when the association is not navigable from the Actor to its opposite. This should be detected before creation, forbidding the gesture as soon as possible. Currently the gesture is allowed and the following exception can occur: java.lang.UnsupportedOperationException: Cannot add a Property on Classifier SysMLmodel::Actor0 at org.eclipse.papyrus.sysml.service.types.helper.advice.AssociationNoneEditHelperAdvice.addSourceInModel(AssociationNoneEditHelperAdvice.java:118) at org.eclipse.papyrus.sysml.service.types.helper.advice.AssociationNoneEditHelperAdvice$1.doExecuteWithResult(AssociationNoneEditHelperAdvice.java:176) at org.eclipse.gmf.runtime.emf.commands.core.command.AbstractTransactionalCommand.doExecute(AbstractTransactionalCommand.java:247) at org.eclipse.emf.workspace.AbstractEMFOperation.execute(AbstractEMFOperation.java:150) at org.eclipse.emf.workspace.CompositeEMFOperation.doExecute(CompositeEMFOperation.java:217) at org.eclipse.emf.workspace.AbstractEMFOperation.execute(AbstractEMFOperation.java:150) at org.eclipse.gmf.runtime.emf.type.core.commands.CreateElementCommand.doExecuteWithResult(CreateElementCommand.java:96) at org.eclipse.gmf.runtime.emf.commands.core.command.AbstractTransactionalCommand.doExecute(AbstractTransactionalCommand.java:247) at org.eclipse.emf.workspace.AbstractEMFOperation.execute(AbstractEMFOperation.java:150) at org.eclipse.gmf.runtime.diagram.ui.commands.SemanticCreateCommand.doExecuteWithResult(SemanticCreateCommand.java:91) at org.eclipse.gmf.runtime.common.core.command.AbstractCommand.execute(AbstractCommand.java:134) at org.eclipse.gmf.runtime.common.core.command.CompositeCommand.doExecuteWithResult(CompositeCommand.java:403) at org.eclipse.gmf.runtime.common.core.command.AbstractCommand.execute(AbstractCommand.java:134) at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:513) at org.eclipse.gmf.runtime.diagram.ui.parts.DiagramCommandStack.execute(DiagramCommandStack.java:206) at org.eclipse.gmf.runtime.diagram.ui.parts.DiagramCommandStack.execute(DiagramCommandStack.java:169) at org.eclipse.gmf.runtime.diagram.ui.parts.DiagramCommandStack.execute(DiagramCommandStack.java:156) at org.eclipse.gef.tools.AbstractTool.executeCommand(AbstractTool.java:425) at org.eclipse.gef.tools.AbstractTool.executeCurrentCommand(AbstractTool.java:438) at org.eclipse.papyrus.diagram.common.service.AspectUnspecifiedTypeConnectionTool.handleCreateConnection(AspectUnspecifiedTypeConnectionTool.java:289) at org.eclipse.gef.tools.ConnectionCreationTool.handleButtonDown(ConnectionCreationTool.java:77) at org.eclipse.gef.tools.AbstractTool.mouseDown(AbstractTool.java:1091) at org.eclipse.gef.EditDomain.mouseDown(EditDomain.java:245) at org.eclipse.gef.ui.parts.DomainEventDispatcher.dispatchMousePressed(DomainEventDispatcher.java:348) at org.eclipse.draw2d.LightweightSystem$EventHandler.mouseDown(LightweightSystem.java:523) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:191) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4163) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3752) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
Re-orient probably suffers from the same problem.
This forbid the creation of an association in the bdd diagram between an actor and any element. I don't really understand why the creation is aborted if we can't add the end to the source/target in add*InModel but I am not an UML master. Is there a reason ? the end is already owned by the association by default so I don't see the point, if it fails it stay on the association which seems correct to me. I already change the code (remove the throws), I can commit if no objection.
(In reply to comment #2) > This forbid the creation of an association in the bdd diagram between an actor > and any element. > > I don't really understand why the creation is aborted if we can't add the end to > the source/target in add*InModel but I am not an UML master. Is there a reason ? > the end is already owned by the association by default so I don't see the point, > if it fails it stay on the association which seems correct to me. > > I already change the code (remove the throws), I can commit if no objection. Can you attach your patch, I'll review it this afternoon ?
patch attached. another remark (unrelated) : the code handling Association is purely UML. Why is it not in the uml.service plugin ? Moreover most of the code is copy/paste from AssociationEditHelperAdvice. I understand that it should be registered for the sysml element types but it could be done without copying the code, by just referencing the classes from the uml.service plugin into the sysml plugin.xml. Because of that the specific code handling the different type of assocations (none/composite/shared) seems to be only in sysml while it also apply to uml.
Created attachment 204865 [details] patch
(In reply to comment #5) > Created attachment 204865 [details] > patch The created association is incorrect. The tool (matching the element you have patched) is supposed to create an Association navigable in both direction. In SysML the Association navigability is defined by the fact that the ending classifier owns the memberEnd of the Association. In this case, the Association is created but one of its end is owned by the Association instead of being owned by the Actor, meaning that it is not navigable in both direction. The problem with Actor is that one cannot add feature on such Classifier, as a result it is not possible to create SysML association with Actor as a source and navigable on toward the opposite end.
(In reply to comment #4) > patch attached. > > another remark (unrelated) : the code handling Association is purely UML. Why is > it not in the uml.service plugin ? Moreover most of the code is copy/paste from > AssociationEditHelperAdvice. > > I understand that it should be registered for the sysml element types but it > could be done without copying the code, by just referencing the classes from the > uml.service plugin into the sysml plugin.xml. Because of that the specific code > handling the different type of assocations (none/composite/shared) seems to be > only in sysml while it also apply to uml. By the way Association in UML and SysML are different : - navigability is not defined the same way in both languages - no n-ary association in SysML The distinction between UML and SysML is done with an eAnnotation added on each kind of creation. The use of this eAnnotation is to provide property view with different behavior for each or to allow / forbid Association drop in diagram. As an example, I dont want that an Association created in a Class diagram which may be incorrect from a SysML point of view can be dropped in an IBD (this should be done via some kind of explicit refactor action). The work in service types around Association has been done for SysML diagrams (IBD, BDD) and tested / validated on these. I guess some code could be reuse for an equivalent UML implementation and use in UML diagrams but will probably by more complicated (to deal with n-ary assoc, ends owned by assoc...). In case equivalent Association type (none, shared...) for UML are needed, I'd prefer keeping the code separated to limitate possible impact of UML implementation on SysML association, and to avoid the task of re-validating SysML association unless there is a clear benefit for this.
OK thanks, I thought Association was handle the same way in UML and SysML, it is a lot clearer now. I really don't understand why they didn't use the usual navigable feature of the memberEnd instead of this mess...
(In reply to comment #8) > OK thanks, I thought Association was handle the same way in UML and SysML, it is > a lot clearer now. > I really don't understand why they didn't use the usual navigable feature of the > memberEnd instead of this mess... I dont understand either, the result is two language (UML & SysML) that really look compatible but are not completely. Very problematic in my opinion for a tool like Papyrus that attempts to provide UML and SysML diagrams shared as views on a same model... I hope the two specifications will be re-aligned in future versions.
Merged in trunk (0.9) : r7279.
Fixed in r7274 (0.8) and r7279 (0.9).
