Community
Participate
Working Groups
The goal is to enable a strong synchronization between visual elements displayed in the diagram with elements contained in the model. This mechanism can be added locally for each element by using CSS. For example, you would like to see: - synchronize compartment of enumeration literal for all enumeration. - synchronize compartment of attributes and operation for all class stereotyped ….
With commit 60b6251 I have commented out the edit-policy provider of the new oep.uml.diagram.synchronizeview plug-in because it causes regression failures in numerous (more than 90?) test cases. Please fix this provider before reinstating the extension. BTW, from the name of this new plug-in, I thought it implemented something to do with the Eclipse Team framework's Synchronize view. Perhaps some other name would be in order ...
I have uploaded a couple of demo videos showing progress on the refactored op.infra.gmfdiag.canonical plug-in: * Tech preview of canonical list and shape compartments: http://youtu.be/NhdDWIlpXao * Interaction of canonical edit policy with undo/redo: http://youtu.be/qbLF_4l-SF4 A feature branch is published to Git: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/?h=committers/cdamus/433206-diagram-sync with a Hudson build: https://hudson.eclipse.org/papyrus/job/Papyrus-Feature-DiagramSync/ and a test build: https://hudson.eclipse.org/papyrus/job/Papyrus-Feature-DiagramSync-Tests/
A small follow-up video shows new Properties view support for synchronization: http://youtu.be/aOcCthCuDBI and also drag-and-drop interactions.
Demonstration of a new CSS 'canonical' attribute: http://youtu.be/cfoQQKPlsxw This is a special case of new support for CSS inference of Styles that have a single attribute (see commit ea27655d8d6d9d5e7d7151e4f624d6cdaf52117d on branch committers/cdamus/433206-diagram-sync). This is like the inference of implied NamedStyles except for the more specific style types such as CanonicalStyle. The idea of restricting it to single-attribute styles is to ensure sensible mapping from the CSS attribute name, but I'm not sure that it would be strictly necessary. At any rate, the implementation currently only actually recognizes the CanonicalStyle's 'canonical' attribute.
A brief demonstration of canonical composite structure diagrams: http://youtu.be/uo2jpPd-n2s
Here's something odd: the latest build on this enhancement's feature branch: https://hudson.eclipse.org/papyrus/job/Papyrus-Feature-DiagramSync-Tests/22/ has considerably fewer test failures (10) than the master branch (23) : https://hudson.eclipse.org/papyrus/view/Mars/job/Papyrus-Master-Tests/790/ based on the same master-branch commit. Notably, all of the interaction-overview diagram tests pass, which hasn't happened in quite some time.
(In reply to Christian W. Damus from comment #5) > A brief demonstration of canonical composite structure diagrams: > > http://youtu.be/uo2jpPd-n2s Nice to see the progress, Cristian! I have a two question related to this, especially related to the aspects related to UML-RT. 1) The visualization of the port on the part, what is it that controls this? I have had several discussion with Bran Selic and others, regarding this. When you drag-and-drop a class to create a part, not necessarily all the ports of this class shall be visualized on the border of the part, e.g. SAP kind of port (not isService, not isWired, not isPublish, protected visibility) shall probably in most (if not all) cases not be shown. The ruling in older tools has all been a bit inconsistent in what controls what ports are visualized (RoseRT used visibility, RSARTE used isService). The most tricky thing is SPP kind of ports (isService, not isWired, isPublish, public visibility). Even though it is both public and isService, it should not necessarily be shown on the border. Sure, you can probably hide it per part, but it will be a bit cumbersome to change this for each part you create. This should be based on some property of the port on the class typing the part, not specifically for the port on the part itself. 2) The recursive display within parts I assume should be possible to control, right? Yes, this is nice to be able to show in some cases, but with deep nested structures with lots of part, ports and connectors this will be just to cluttered (and hard to maintain). In most cases you only want to show the parts but not the "inside" of those parts. Any comments? 3) Is the inheritance of the layout for composite structure diagrams (and also state machine diagrams) as needed by UML-RT part of this work you are doing now? I guess that will come later, but I guess that you should be consider the support for this as well.
(In reply to Peter Cigéhn from comment #7) > > 1) The visualization of the port on the part, what is it that controls this? Two things: the CSS stylesheet and the canonical edit policy's pluggable strategies for which elements to present in the diagram. > I have had several discussion with Bran Selic and others, regarding this. > When you drag-and-drop a class to create a part, not necessarily all the > ports of this class shall be visualized on the border of the part, e.g. SAP > kind of port (not isService, not isWired, not isPublish, protected > visibility) shall probably in most (if not all) cases not be shown. The developer of a diagram can plug into the canonical edit policy a strategy that it will delegate to to determine which related elements need to be presented, including which ports of the part's type and which further nested parts (if any). > 2) The recursive display within parts I assume should be possible to > control, right? Yes, this is nice to be able to show in some cases, but with Yes, that is all controlled by the extensible canonical edit policy. > deep nested structures with lots of part, ports and connectors this will be > just to cluttered (and hard to maintain). In most cases you only want to > show the parts but not the "inside" of those parts. Any comments? My only comment is that it is entirely in the hands of the diagram developer (assuming that the API is sufficient to meet the need, of course). > 3) Is the inheritance of the layout for composite structure diagrams (and > also state machine diagrams) as needed by UML-RT part of this work you are > doing now? I guess that will come later, but I guess that you should be > consider the support for this as well. No, that is something separate entirely. This enhancement covers a Papyrus specialization of GMF's CanonicalEditPolicy, which is defined and understood by the GMF Run-time as specifically providing a "canonical" (matched one-to-one and synchronized) visualization of the structure of a model element in a diagram. Model-to-model and diagram-to-diagram synchronization are outside of the scope of GMF; there is a prototype of the latter to which I shall turn my attention again once the canonical edit policy is (as much as it needs to be) complete.
Thanks a lot for the response Christian. Always good to get a better understanding. I guess then that we need to get back to the final decision on what ports to show on the part when the detailed UML-RT tooling is going to be made.
> My only comment is that it is entirely in the hands of the diagram developer (assuming that the API is sufficient to meet the need, of course). If I understood correctly, the recursion is driven by the Notation/CSS, which says that not only the Structured Classifier is Synchronized, but also its Properties (Parts) and Ports So the recursion is not specified at the Diagram Type level, but at the Diagram Instance level (Which can be either inherited from a more general strategy, e.g. Workspace preferences, or customized for each specific Diagram) In the specific case of UML-RT, I suspect we'll have a UML-RT-specific stylesheet defining the Synchronization strategy
(In reply to Camille Letavernier from comment #10) > > In the specific case of UML-RT, I suspect we'll have a UML-RT-specific > stylesheet defining the Synchronization strategy If you have RT-specific style attributes, I expect that an RT-specific canonical strategy should be able to access them because it has both the semantic and notation elements on which basis to decide which related semantic elements should be visualized in the diagram.
New Gerrit change created: https://git.eclipse.org/r/44367 WARNING: this patchset contains 9299 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
(In reply to Eclipse Genie from comment #12) > New Gerrit change created: https://git.eclipse.org/r/44367 This Gerrit change set is targeted for this week's M6 API Freeze milestone. There are further changes that can follow M6 as they would not be expected to have API impact, including: * canonical strategy extensions in various behaviour diagrams, especially for connection views * further JUnit test coverage * possibly more work on layout of canonical shape compartments, although I think that would probably wait for the integration of the advanced layout engine that is anticipated for Mars or Mars+1
WARNING: this patchset contains 9889 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
WARNING: this patchset contains 9983 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/44367 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=076626232757a6cc017b64d4d9d9d3cbe31906a1 WARNING: this patchset contains 11220 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
WARNING: this patchset contains 11220 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
Commit 703b3a5 adds considerable improvement in the layout of canonically created views: https://youtu.be/ydTiYbcJQss
New Gerrit change created: https://git.eclipse.org/r/45343 WARNING: this patchset contains 4099 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
Here's a first look at the generation of automated tests for view synchronization: http://youtu.be/ZIZPceUdvE8 The first step is generation of tests for canonical creation of top nodes for new elements in the model. That actually requires the diagram view, itself, to be stylobate by CSS, which is bug 464443.
Commit 9ffd94c adds synchronization to the Profile Diagram.
New Gerrit change created: https://git.eclipse.org/r/46273
Gerrit change https://git.eclipse.org/r/46273 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=6daac06228f0cf85370e40bb060fc2f8f8bc0746
Some dependencies were reversed: bug 417986, bug 420549, and bug 450844 depending on synchronization were linked as blocking synchronization. The synchronization feature is now essentially complete for Mars. A few diagrams simply are not ready for synchronization, not providing the drop edit-policies and/or layout capabilities needed to make synchronization actually useful for them. These are split out into separate enhancements: bug 465412 and bug 465414. And automated testing of synchronization is now wrapped up in the in-progress tests generation framework (bug 464647), which being a largely orthogonal effort cannot remain linked as a blocker.
