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

Bug 334888

Summary: [usability][ActivityDiagram] "Drag'n drop"-based creation of actions
Product: [Modeling] Papyrus Reporter: Arnaud Cuccuru <arnaud.cuccuru>
Component: DiagramAssignee: Project Inbox <mdt-papyrus-inbox>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: P3 CC: jeremie.tatibouet, papyrus-bugs, rschnekenburger, sebastian.herzig, sebastien.gerard, sebastien.revol
Version: 0.8.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
See Also: https://git.eclipse.org/r/63171
https://git.eclipse.org/c/papyrus/org.eclipse.papyrus-moka.git/commit/?id=dddca01576b578b771178e0c169f03d5d914d9c0
https://git.eclipse.org/c/papyrus/org.git/commit/?id=dddca01576b578b771178e0c169f03d5d914d9c0
Whiteboard:
Bug Depends on:    
Bug Blocks: 482394    
Attachments:
Description Flags
Spec of Activity DnD and pin management none

Description Arnaud Cuccuru CLA 2011-01-20 09:24:19 EST 
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
Comment 1 Sebastien Revol CLA 2015-07-16 02:33:28 EDT 
Created attachment 255234 [details]
Spec of Activity DnD and pin management
Comment 2 Sebastien Revol CLA 2015-07-17 04:05:17 EDT 
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).
Comment 3 Eclipse Genie CLA 2015-12-22 12:29:38 EST 
New Gerrit change created: https://git.eclipse.org/r/63171
Comment 5 Remi Schnekenburger CLA 2016-02-12 05:25:42 EST 
Sebastien, as discussed, can you move the generic strategies from Moka to Papyrus? Thanks!