Community
Participate
Working Groups
As discussed in the linked Wiki page, there are modelling domains such as UML RT in which users will want to be able to synchronize the presentation of model elements in a diagram with the presentation of the same or related elements in one or more other diagrams. This is distinct from the synchronization of a diagram with the semantic model elements that it presents (that being bug 433206). An initial prototype was contributed on Gerrit: * https://git.eclipse.org/r/#/c/38587/ This will be refined and the requirements further elaborated to complete the synchronization framework.
(In reply to Christian W. Damus from comment #0) > > An initial prototype was contributed on Gerrit: > > * https://git.eclipse.org/r/#/c/38587/ Nope, it's this one: * https://git.eclipse.org/r/#/c/36747/
I have posted a brief video (under 4½ minutes) demonstrating diagram-to-diagram synchronization in state machines in the context of UML-RT Capsule inheritance: https://youtu.be/BKYe8b84ywM As I don't know the specifics of the UML-RT semantics of state machines, this should be taken as an initial prototype. But, it does demonstrate the capability of the synchronization framework to synchronize two (or more) diagrams visualization two (or more) synchronized model elements (in this case, state machines). That is different from earlier prototypes that only covered the synchronization of multiple visualizations (diagrams) of the same model element. This demonstrates: * triggering of the framework to install/configure synchronization rules, in this case: * on the creation of a StateMachine as the classifierBehavior of a Capsule * on the opening of a StateMachine diagram in a Capsule * synchronization of model elements: * attributes such as names * contained/referenced objects such as the regions of a statemachine/state and vertices in a region * relationships and relationship-like elements such as transitions in a statemachine * synchronization of diagram views: * nested views * positions and sizes of views * connections What is not yet implemented and/or tested includes: * handling deletions of elements in the synchronization 'master' (the parent Capsule's statemachine in this case) * synchronization override: * styles in the diagram that would disable visual synchronization of an element * something (not sure yet what) in the semantic model to disable semantic synchronization of an element * for the most part, undo/redo works as expected, but there are several scenarios yet untested The current implementation does have notation styles that install/configure synchronization of diagram views in an ad hoc fashion, where multiple visualizations of the same semantic content are to be synchronized with one another (this elaborates the very original prototype for capsule package diagrams). These styles are not used in the UML-RT capsule state machine synchronization: those are triggered entirely by the detection of a state-machine behaviour in a <<capsule>> class.
New Gerrit change created: https://git.eclipse.org/r/47188 WARNING: this patchset contains 9228 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
Gerrit change https://git.eclipse.org/r/47188 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=2b5e61b03fdac03f441bbdc61b45639d0c54db4c
New Gerrit change created: https://git.eclipse.org/r/47982
(In reply to Eclipse Genie from comment #5) > New Gerrit change created: https://git.eclipse.org/r/47982 Added a new video to demonstrate automatic synchronization override when changing the layout of a synchronized diagram: http://youtu.be/TwneFmoFmIw
(In reply to Christian W. Damus from comment #6) > (In reply to Eclipse Genie from comment #5) > > New Gerrit change created: https://git.eclipse.org/r/47982 > > Added a new video to demonstrate automatic synchronization override when > changing the layout of a synchronized diagram: > > http://youtu.be/TwneFmoFmIw This looks good, Christian! One additional feature related to this is that you should be able to revert the override of position (and possibly size as well since that seemed to be separately overridden), and "reinherit" that from the superclass. In other tools with this kind of layout inheritance you have the possibility of selecting "Position from superclass". Sometimes you move something in the subclass but then change your mind and want to revert having it positioned (and continue to be synchronized) with the superclass. The reverting to position/size from superclass I guess could be made both by right-clicking and selecting a context-menu choice, but maybe also some option on the appearance tab in the properties view. Preferably you should also be able to multi-select multiple shapes and revert them all to position/size from superclass in one go. In both cases (menu-choice and option) you should be able to see the current state of the synchronization, i.e. if "position from superclass" is enabled or not (check-mark next to menu choice or option on appearance tab).
(In reply to Peter Cigéhn from comment #7) Hi, Peter, I neglected to demonstrate in the video (because I assume by now that it is always just taken for granted) that the overriding of notation synchronization is entirely undoable. The changes in location/size/whatever that are recorded trigger the installation of the override style, the recording of which change is added to the original. This is the same way that undo/redo of the synchronous changes is effected in the first place: changes to the synchronized diagram are appended (for undo/redo) to the master diagram's changes. It's all a basic EMF Transactions capability. But, of course that's not a complete answer. It must be possible to re-establish synchronization at a later time as you observed. The API is available in Papyrus now to do that; it is up to the implementer of the diagram synchronization to give the user the requisite tools according to what is actually synchronizable. What I present in these demos is just that: a demonstration of the framework's capabilities. It doesn't purport to be an implementation of UML-RT state machine synchronization. The UML-RT expert team will have to implement that (perhaps with this demo as a starting point or perhaps not).
(In reply to Christian W. Damus from comment #8) Thank's for the clarification Christian! I also took he undo functionality for granted, so my comment was more related to the case when you want the re-establish the synchronization with the superclass at some later point in time, when undo is no longer possible. It is a bit hard for me to know what functionality goes where, i.e. if it will be in the framework or if it will be in some DSML specific tooling, e.g. the UML-RT tooling, so I just wanted to provide this feedback in case some general support were needed in the framework itself.
Commit cd3207bf30ea8f45592f32b08df84d559ec6ad97 adds an automated test suite for the diagram-to-diagram synchronization framework.
With commit d813c0043b9e6b00e1d53df8e01a71dcaccab8ae adding developer/design documentation for the synchronization framework, this feature is complete. Note that user documentation will naturally be specific to a particular implementation of the framework, such as in UML-RT state machine diagram synchronization. The documentation will need to discuss specifics of what a particular DSML synchronizes and what UI is provided for managing synchronization overrides etc. There is no user documentation applicable to the core framework, which is what this bugzilla covers.
