Capsule Structure Diagram Inheritance
← Older revision
Revision as of 16:22, 2 January 2017
(3 intermediate revisions by the same user not shown)
Line 40:
Line 40:
The extension elements are stored in a special resource maintained in the resource set, called the ''extension extent''. This resource, therefore, indirectly contains any "virtual elements" that are these implicit members or other model content. It also maintains an adapter on every element contained within it that, when some concrete change is made to it (thus effecting an incremental redefinition of some inherited element), ''reifies'' the object by moving it and any stereotype applications it may have into the user model (in the appropriate containment reference, of course).
The extension elements are stored in a special resource maintained in the resource set, called the ''extension extent''. This resource, therefore, indirectly contains any "virtual elements" that are these implicit members or other model content. It also maintains an adapter on every element contained within it that, when some concrete change is made to it (thus effecting an incremental redefinition of some inherited element), ''reifies'' the object by moving it and any stereotype applications it may have into the user model (in the appropriate containment reference, of course).
+
+
Extensions thus far are used only to define containment references for the distinct "shadow" elements representing the local view of an element inherited by some namespace. These typically are named <code>implicitXyz</code> (e.g., implicitPort) and are added to the <code>Namespace::ownedMember</code> superset as a non-standard subset, for access via the Eclipse UML2 UML API. They are in addition to queries such as <code>Namespace::inheritedMember()</code> and further supersets such as <code>Namespace::member</code> which account for inheritance by presenting the same definitions of elements in the supertype.
+
+
Extensions are not used for inheritable containment references such as <code>MultiplicityElement::lowerValue</code> and <code>Connector::end</code>. These are handled by customized setting/list implementations (<code>InheritableSetting</code> and <code>InheritableEList</code>, respectively) that take care of presenting "shadows" of inherited elements in the unset state and automatically reifying the contained elements when they are modified to effect redefinition. By implementing this inheritance in the unset state, the serialization of a model is assured never to contain an element in such a reference unless it is a redefinition. And, as these are not typically <code>RedefinableElement</code>s according to the UML metamodel, their traceability to the elements that they redefine is implied by the reference in which they are contained (e.g., lower or upper value of a multiplicity element) and position (in case of a reference collection). Furthermore, in the case of an inheritable reference collection such as <code>Connector::end</code> or <code>Operation::ownedParameter</code>, if any element is redefined and thus requires it to be persisted (making the containment reference "set" as compared to "unset"), then all elements in the collection are persisted and are, effectively, redefinitions of the inherited elements. This is unavoidable owing to the significance of ordering in these collections.
+
+
=== Deviations from UML ===
+
+
Clearly, none of these extension and inheritance semantics can be implemented without significant deviations from the standard structure of the UML metamodel, especially as is encoded in its Ecore representation for the benefit of the EMF Run-time and applications such as EMF Compare that, to a large extent, are generic and driven by the Ecore metadata.
+
+
Although the customized UML implementation classes for UML-RT can change the outward behaviour of the API, they cannot (reasonably) change the Ecore metadata describing that API to EMF-based applications. The two most obvious deviations of the API's behaviour from what applications would expect according to the Ecore metadata are of two kinds:
+
+
* features presenting "unsettable" semantics that in the Ecore are declared as not unsettable. This somewhat confusing nomenclature in Ecore just indicates whether a feature has a discrete "unset" state in addition to its value
+
* references, especially containments, appearing to have EObject values even in the unset state (default values for <code>EReference</code>s are not supported by EMF)
+
+
Both of these semantic deviations are in support of inheritance: properties of an element that can be inherited from the element that it redefines (according to UML-RT incremental inheritance) must behave as though unsettable, so that the unset state can inherit the value and the set state can override it. And containment references such as <code>MultiplicityElement::lowerValue</code> and <code>Connector::end</code> must be able to present the inherited values in their unset state.
+
+
The EMF Run-time is generally well-behaved in the face of these deviations, including the <code>ChangeRecorder</code> that is used for automatic undo/redo of model edits. It is not concerned about receiving <code>UNSET</code> notifications or notifications with <code>isSetChange</code> from features that are not declared as unsettable; it just faithfully records set-state changes and performs <code>eUnset()</code> as appropriate on apply. Likewise for notifications received from extension features: they are handled correctly despite not actually being features of the notifier's <code>EClass</code>.
+
+
In general, applications that process notifications should behave as expected if they do not make any assumptions about the kinds of notifications that they will received based on the Ecore metadata. Applications that are primarily driven by the Ecore metadata (for more than just reacting to notifications) may have to make adjustments to account for UML-RT models if they do not just treat all features as though they were unsettable (which, in fact, is generally advisable as it does not lead to contradictions or erroneous behaviour in most cases anyways).
== Façade API ==
== Façade API ==
Line 72:
Line 91:
For the visualization of inherited features in the Capsule Structure Diagrams, I have decided not to use the synchronization framework (<code>org.eclipse.papyrus.infra.sync</code>) introduced in the Papyrus Mars release. Prototyping work with this framework showed that it is simply too unwieldy, prone to failure of undo/redo, and that it is in large part obviated by work done in [http://eclip.se/467545 bug 467545] on an implementation of UML-RT semantics in the UML metamodel. So, inheritance in the diagrams is implemented by means of a coördination of GEF edit policies:
For the visualization of inherited features in the Capsule Structure Diagrams, I have decided not to use the synchronization framework (<code>org.eclipse.papyrus.infra.sync</code>) introduced in the Papyrus Mars release. Prototyping work with this framework showed that it is simply too unwieldy, prone to failure of undo/redo, and that it is in large part obviated by work done in [http://eclip.se/467545 bug 467545] on an implementation of UML-RT semantics in the UML metamodel. So, inheritance in the diagrams is implemented by means of a coördination of GEF edit policies:
−
* Canonical Edit Policy: the Papyrus-RT visual children
strategy uses
the UML-RT façade API to find and return inherited elements
+
* Canonical Edit Policy: the Papyrus-RT
semantic and
visual children
strategies use
the UML-RT façade API to find and return inherited elements
−
* Inheritance Edit Policy: ({{new}}) manages
three aspects of inherited elements:
+
* Inheritance Edit Policy: ({{new}}) manages
optional
tracking of the visuals of the inherited elements from the capsule structure diagram in which they are defined
−
**
tracking of the visuals of the inherited elements from the capsule structure diagram in which they are defined
+
−
** transience (non-persistence) of the views of inherited elements
+
−
** reification of redefining elements when their presentation is customized in the inheriting diagram
+
* Applied Stereotype Comment Edit Policy: specialized in Papyrus-RT to omit the comment view for inherited elements
* Applied Stereotype Comment Edit Policy: specialized in Papyrus-RT to omit the comment view for inherited elements
+
+
In the Capsule Structure Diagram, all views of inherited elements reference the root definition as the semantic element, regardless of whether it is an inherited element (which is not attached to the model resource and so would break the serialization) or even a redefinition (which is a real, distinct element in the UML model). The edit-parts override the <code>IGraphicalEditPart::resolveSemanticElement()</code> and <code>IAdaptable::getAdapter()</code> APIs to resolve their notation view's reference to the appropriate redefinition or virtual "shadow" element in the local namespace for inherited elements. This ensures that UI components such as the Properties View that correctly use these APIs to get the semantic element (not simply assuming that it is the notation view's element reference) will get the correct <code>EObject</code> to present, so that any edits made on it will automatically trigger redefinition. However, there are many Papyrus edit-policies and other classes that do not resolve the semantic element correctly via the edit-part, which have to be overridden in Papyrus-RT to do so.
=== Properties View ===
=== Properties View ===
Line 96:
Line 114:
The properties view context/XWT contributions for capsules and protocols are updated to use the <code>FacadeModelElement</code> for their names, ports/parts (of capsules), and protocol messages. Likewise the creation dialog XWT descriptions for capsules and protocols that request only the name in certain UI workflows.
The properties view context/XWT contributions for capsules and protocols are updated to use the <code>FacadeModelElement</code> for their names, ports/parts (of capsules), and protocol messages. Likewise the creation dialog XWT descriptions for capsules and protocols that request only the name in certain UI workflows.
+
+
=== Model Explorer ===
+
+
Inherited elements in capsule (ports, parts, connectors) and protocols (messages) are presented via EMF Facets with reference queries implemented on the Façade API. By default, purely inherited elements are not shown (they are shown in the Properties View), but they can be enabled by an additional facet override in the customization dialog (the ''UML-RT Structure Inheritance'' customization). Excluded elements and redefinitions are always shown, with appropriate decorations.
+
+
The children of different dispositions are shown in a definite order:
+
+
* Capsule
+
** inherited RT ports — if shown, per above, either by redefinition/exclusion or customization to include inherited elements
+
** inherited capsule-parts
+
** inherited RT connectors
+
** locally-defined RT ports — root definitions initially defined by the capsule
+
** locally-defined capsule-parts
+
** locally-defined RT connectors
+
** other ports (non-RT, if applicable)
+
** other attributes (that are not capsule-parts)
+
** other connectors (non-RT, if applicable)
+
* Protocol
+
** inherited outgoing messages — if shown, per above, either by redefinition/exclusion or customization to include inherited elements. This ordering matches what was presented in the Properties View since the 0.7.x releases
+
** inherited incoming messages
+
** inherited in/out messages
+
** locally-defined outgoing messages — root definitions initially defined by the protocol
+
** locally-defined incoming messages
+
** locally-defined in/out messages
+
** ''(there is no provision in UML-RT for operations that are not protocol messages)''