Community
Participate
Working Groups
Usability of the Activity Diagram could be improved by supporting a "drag'n drop"-based creation of actions. For example, if a model contains an activity Act(Integer):Integer, it could be possible to generate a CallBehaviorAction (with one input pin and one ouput pin, both typed by Integer) by dragging Act from the outline to an activity diagram. The same principle could be applied to other kinds of elements such as operations, classifiers, properties, associations, etc., possibly with an intermediate dialog in the case where: - the creation of the action requires some additional information (e.g., in the aforementioned activity example, it may be necessary to specify the value of property "isSynchronous") - there may be multiple options regarding the kind of action to create (e.g., dragging a Class could result in the creation of a CreateObjectAction or a ReadExtentAction) The following list (probably not exhaustive) identifies the kind of model elements that could be droped, and the various kind of actions that may be created in response: - Association => ClearAssociationAction, CreateLinkAction, ReadLinkAction, WriteLinkAction - Behavior => CallBehaviorAction, ReduceAction - Classifier => CreateObjectAction, ReadExtentAction, ReadIsClassifiedObjectAction, UnmarshallAction - Operation => AcceptCallAction, CallOperationAction - Property => AddStructuralFeatureValueAction, ClearStructuralFeatureAction, ReadStructuralFeatureAction - Signal => AcceptEventAction, BroadcastSignalAction, SendSignalAction
Created attachment 255234 [details] Spec of Activity DnD and pin management
Hi, this request is now addressed. It is implemented in two steps : -the drag and drop of the elements -the pin update algorithms The Dnd is based on a generic DropStrategy specialized for each supported case. All the supported cases are listed in the attached Excel sheet, it corresponds to those listed by Arnaud in this request. There should be probably others to be implemented in the future. Each specialization declares a supported dropped element, the element to create for this drop, and the reference to set (if any) between the dropped element and the created Element. Example : drop a "Behavior" to create a "CallbehaviorAction" and set the "behavior" reference from the action to the dropped behavior. This generic strategy allows to drop one or several elements into an Activity or an ActivityGroup. In case of multiple element drop, if the elements have different nature, user may be asked to select the right drop strategy (using the existing drop strategy popup menu). In that case, only the element supported by the selected drop strategy will be effectively dropped. Notice that this generic drop strategy also support the drop of a single element on an existing target object. In the previous example, if the behavior is dropped on an existing CallBehaviorAction, the behavior reference will be updated to the dropped object. The pin update is handled in a separated mechanism, relying on Papyrus ElementType Advices. The advice is generally triggered by a SetRequest. Hence the generic drop strategy is using CreateElementRequest and SetRequest to create the dropped objects and update the reference. In the example, the "behavior" reference setting with the SetRequest is triggering the advice that will call the pin update method for CallBehaviorAction. Thanks to Advice mechanisms, this method is also called when the reference is updated through the properties view for instance. There is mostly one single advice associated to the abstract ActivityNode metaclass. This advice relies on a PinUpdateCommandFactory to create the right Command depending on the kind of Node. The update methods are generally conservative to avoid to break existing connections: they try to preserve and update existing pins, and only destroy the pins which no more matching with any parameter of properties for instance. Notice that additionnal advices have been associated to other elements such as SignalEvent. AcceptEvent output pins may depend on the properties of the signal referenced by the SignalEvent associated the AcceptEvent. If the SignalEvent references a new signal, the output pins of ALL the AcceptEvent referencing this SignalEvent have to be updated. Hence there is a crossReferencing use to find all the impacted acceptEvent. Last, the pin display is made thanks to the cannonical mechanism. I provide a CSS setting by default the cannonical attribute to true for all the supported ActivityNode types (unfortunately CSS doesn't support yet the setting of attribute to Abstract metaclass such as ActivityNode).
New Gerrit change created: https://git.eclipse.org/r/63171
Gerrit change https://git.eclipse.org/r/63171 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus-moka.git/commit/?id=dddca01576b578b771178e0c169f03d5d914d9c0
Sebastien, as discussed, can you move the generic strategies from Moka to Papyrus? Thanks!
Gerrit change https://git.eclipse.org/r/63171 was merged to []. Commit: http://git.eclipse.org/c/papyrus/org.git/commit/?id=dddca01576b578b771178e0c169f03d5d914d9c0
