| Re: [mdt-papyrus.dev] Activity Diagram Pins |
|
Hi Michael, Here is some feedback about the activity diagrams.
As Arnaud mentioned, ValuePins and ActionInputPins can be useful anywhere. In this case, I would make no choice for the user, as it has always been done (or
claimed) in Papyrus. As a consequence, I would go for solution A, that means having 3 tools in the Palette: InputPin, ActionInputPin and ValuePin. I have the feeling that this will lead to an issue on the complexity of the tool, with many possible pins for
many different features. This would give the advantage of covering the full flavor of UML. The complexity could be hidden by some customization, predefined or user-defined Does the ongoing work by Florian on Element Type Configuration could simplify your work ? >> Note that the sheet also shows a few other problems: >> - some features are not mapped at all, e.g AddStructuralFeatureValueAction#insertAt, the whole columns E/F or G are red in the table
I think this comes from the fact that insertAt was not present in the previous versions of the UML spec, and the migration of Papyrus to 2.4/2.5 has not been
fully done, especially for this graphical node. >> - LoopNode#bodyOutput at cell [G17] is special case we don't understand at all The goal in this case it to reference some outputpin from the executable node (Typically an Action or a StructuredActivityNode) which defines the BodyPart of
the LoopNode. You do not have to create a new outputpin in this case on the loopnode but this would be useful to display it, as you do not display those from the bodyPart node. The implementation should allow the creation of a new outputpin, but this would 1-Create an output pin on the body part of the loopnode and 2- reference it
in the bodyOutput of the loopNode and display it on the loopnode representation. If this is too hard to implement for now, you could give the ability to select in the Property view the outputPins for the bodyOutput reference for the loop node, and then display
them on the diagram using the filters>Show/hide content). I do not know how possible it is to draw referenced elements (not in containment) in GMF tooling. Perhaps this needs some new developments in the GMF tooling model. >> - - if there was intention behind this, it should probably be implemented for other non-containments, e.g. LoopNode#decider
yes >> - - may be it is related that creation of LoopNode#loopVariable output pin fails (Bugzilla XXX) This seems to be a containment feature, there should not be any issue there or at least not similar to the previous discussion. This is probably more an issue
on current implementation of the edit part. >> - for some actions / pins there is also some synchronization logic implemented but we don't want to touch this topic for now This synchronization is something which has been deactivated and should be reimplemented in a better way. This was done with the validation framework, which
is not the right way to do that. Some kind of refactoring or synchronized stuff should be implemented for that, but I agree this is another topic ;-) >> So the questions here are: >> - does anybody care? :) Yes, we care ;-) >> - is there any logic we missed behind the choice A vs B? The implementation was not complete, as the first version of the activity diagram did not have these “sugars” in the needed list >> - what would you suggest as a choice A vs B for newly added actions for Mars? B, as explained earlier >> - whatever the choice, should we enforce it for all existing ActivityD actions? Yes ;-) Does that answers all your questions, Michael? Regards, Rémi ------------------------------------------------------- Rémi SCHNEKENBURGER +33 (0)1 69 08 48 48 CEA Saclay Nano-INNOV Institut CARNOT CEA LIST De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de CUCCURU Arnaud Hi Michael, The UML specs says: “When the Action is enabled by other means, values are computed as specified for the ValuePins and ActionInputPins owned by an Action, and
the results are provided as inputs to the Action when it begins execution. A ValuePin provides a value by evaluating a ValueSpecification (e.g., this may be used as a simple way to specify constant inputs to an Action.) When the Action
is enabled by other means, the ValueSpecifiation of the ValuePin is evaluated, and the result is provided as an input to the Action when it begins execution. An ActionInputPin provides values by executing another Action. When an Action is enabled by other
means, the fromActions on any ActionInputPins owned by the Action are also enabled. The fromActions must execute before the Action owning the ActionInputPins, and the outputs of the fromActions are placed in the corresponding ActionInputPins. The process recurs
on any ActionInputPins of the fromActions. In the case that ActionInputPins are used for all inputs, this forms a tree structure that is an Action model of nested expressions, bottoming out at Actions that have no inputs (such as ReadVariableActions or ReadSelfActions).” In other words, ValuePins and ActionInputPins are just some kind of syntactic sugar, to make diagrams look a little bit more simpler (e.g., instead of having
a ValueSpecificationAction with its Outpin, connected with an ObjectFlow to an argument InputPin of say of a CallBehaviorAction, you can just put an argument ValuePin on the on the CallBehaviorAction with the appropriate ValueSpecification). So, ValuePins and ActionInputPins can really be used anywhere an InputPin can be used, and I don’t see any particular for imposing a choice here, including
***. Cheers, Arnaud De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Michael Golubev Hello,
Here is our basic understanding of the context: - for both inputs and outputs, only the containment features has to be mapped to some child node in gmfgen, while derived unions AND non-containment references should not be mapped. - None of the two specializations is ever directly referenced by any feature, all features always are of type InputPin - UML does not have any restrictions of using any of the InputPin specializations, while some combinations for some actions does not look good (***) The actual state of ActivityD is shown at google sheet [2] which is open for comments from everyone.
We can guess that there were 2 different attempts to solve the above complexity:
A: "Map Everything" - to add all 3 possible GMF mappings for every qualifying containment feature - this correctly shows imported models or models created without the diagram - user can create any specialized type of InputPin B: "Map Once" - map only the simplest InputPin - this still correctly shows the imported models, including those with ValuePin's, because ValuePin extend InputPin - user can only create InputPins - attempt to create ValuePin via dedicated palette entry does not work case B is represented as a red cells in the columns E/F
- some features are not mapped at all, e.g AddStructuralFeatureValueAction#insertAt, the whole columns E/F or G are red in the table
- LoopNode#bodyOutput at cell [G17] is special case we don't understand at all - - if there was intention behind this, it should probably be implemented for other non-containments, e.g. LoopNode#decider - - may be it is related that creation of LoopNode#loopVariable output pin fails (Bugzilla XXX) - for some actions / pins there is also some synchronization logic implemented but we don't want to touch this topic for now So the questions here are: - does anybody care? :) - is there any logic we missed behind the choice A vs B? - what would you suggest as a choice A vs B for newly added actions for Mars? - whatever the choice, should we enforce it for all existing ActivityD actions?
[2] "ActivityD pins status Luna SR1 / Mars M3" :
https://docs.google.com/spreadsheets/d/1JewgQ-ySQrRt5qsTACA1dnsZ9W-g-iZukSk7tYDmaJ4/edit#gid=0
** -- note, that regeneration of the ActivityD is still waiting for some gerrits to be merged for Mars. But we at least can run it internally.
*** -- e.g, TestIdentityAction#first vs #second, should not they be of the same specialization type?
Regards,
Michael "Borlander" Golubev 1165/1 Dvorecka, 14700, Prague-4 Podoli tek: +420 602 483 463 |
