Community
Participate
Working Groups
USE CASE 1: Drag-and-drop of a class from Model Explorer into a diagram. What you see in Model Explorer should also be displayed in the diagram by default, without having to use the "secret" Ctrl+Drag-and-drop. Getting the diagrams updated/synchronized usually requires many mouse clicks. USE CASE 2: When adding a new attribute to a class using the palette and adding it to the class in a diagram, the Model Explorer view get properly updated. When adding a new attribute to a class by creating a new attribute child for the class in Model Explorer, the diagram does not get updated. To get the diagram properly updated there is a lot of extra clicking. USE CASE 3: When re-ordering the order of e.g. attributes in Model Explorer the diagram gets out of synch with the Model Explorer view. For a larger model, with the slow UI response and updates, and even when knowing about this "secret" Ctrl+Drag-and-drop, manually getting the diagram to get back in synch with the Model Explorer view is quite time consuming. When deploying Papyrus in larger scale for multiple design teams spread across multiple sites across the planet, the lack of synchronization of Model Explorer and diagrams _will_ cause problems and additional costs in time, and may lead to costly bugs in the developed products, especially when integrating generated code from models with existing legacy code. A user must always be able to trust that the order of attributes, operations, parameters etc. which is displayed in the diagram is the real order of things.
Papyrus Mars now supports optional semantic-to-diagram synchronization I close this task
Testing a class "Synchronized with Model" in Papyrus UML 1.1.0.201504270824 Use Case 3 above is not supported, that is, reordering of attributes and operations in Model Explorer for a class is not reflected in the diagram. (should be tested also for operation parameters) When drag-and-dropping another copy of class into the diagram, the order of attributes and operations in the diagram get correct = synchronized with ME for the newly drag-and-dropped class.
(In reply to Toni Siljamäki from comment #2) > Testing a class "Synchronized with Model" in Papyrus UML 1.1.0.201504270824 > > Use Case 3 above is not supported, that is, reordering of attributes and > operations in Model Explorer for a class is not reflected in the diagram. > (should be tested also for operation parameters) I'll have a look at supporting synchronization of the order of elements in list compartments (for shape compartments there is no sensible ordering, I expect). Does this ordering need to be implemented also for collections that the UML metamodel designates as unordered? For example, according to UML, there is no ordering of owned receptions of a Class (although owned operations, attributes, and even nested classifiers are ordered).
Hmm. It appears that Papyrus does not use the ListCompartment notation view for list compartments such as in class and enumeration shapes. These are implemented with BasicCompartments. Hopefully these are consistently managed by some kind of ListCompartmentEditPart, though, so that the canonical edit-policy can know that ordering matters. I'll ensure that the canonical edit-policy does *not* mess with the ordering of views in the case that the compartment does happen to be a ListCompartment (or otherwise have the SortingStyle), as it would be assumed then that the notation specifically directs the presentation order.
Oh, okay, so it seems we have SortingStyles added explicitly to these BasicCompartments (rather than my mix-in inheritance in the ListCompartment). I'll restrict the canonical edit-policy's ordering function to those compartments that have the sorting kind 'none' where the SortingStyle is present.
The remaining problem of canonical ordering of list compartments is fixed on master for RC1.
