Elaboration of UML Extensions
← Older revision
Revision as of 23:58, 9 January 2017
Line 36:
Line 36:
When a generalization relationship is established between capsules or protocols, or a redefinition relationship between state machines, then inheritance of elements is activated that is managed in part by extensions to the UML metamodel. These essentially are structural features of model elements that are stored in separate companion objects (extensions) made accessible through the elements, themselves. So, in a sense they are like features that may be added to metaclasses by package merge, only there is no actual merge; but in practice they are much more like stereotypes, except that they are more deeply integrated into the elements by way of the custom implementation classes.
When a generalization relationship is established between capsules or protocols, or a redefinition relationship between state machines, then inheritance of elements is activated that is managed in part by extensions to the UML metamodel. These essentially are structural features of model elements that are stored in separate companion objects (extensions) made accessible through the elements, themselves. So, in a sense they are like features that may be added to metaclasses by package merge, only there is no actual merge; but in practice they are much more like stereotypes, except that they are more deeply integrated into the elements by way of the custom implementation classes.
−
The extensions are modelled as a metamodel <code>umlext</code> with metaclasses that mirror the extended metaclasses in name and generalization relationships. One important use case for the extensions is to store implicit redefinitions of inherited elements for the cases where they are neither ''excluded'' nor configured differently in any attribute as compared to the inherited element. These implicit redefinitions are stored in extension attributes as depicted in the diagram below. The implementation classes, for example <code>
ClassImpl
</code>, are instrumented to forward access to these features via Ecore reflection to the extension object. This makes it possible, for example, to extend the <code>ownedMember</code> superset in the <code>
ClassImpl
</code> to include the <code>implicitAttribute</code> and <code>implicitConnector</code> properties. This ripples to other derived unions such as <code>ownedElement</code>.
+
The extensions are modelled as a metamodel <code>umlext</code> with metaclasses that mirror the extended metaclasses in name and generalization relationships. One important use case for the extensions is to store implicit redefinitions of inherited elements for the cases where they are neither ''excluded'' nor configured differently in any attribute as compared to the inherited element. These implicit redefinitions are stored in extension attributes as depicted in the diagram below. The implementation classes, for example <code>
ClassRTImpl
</code>, are instrumented to forward access to these features via Ecore reflection to the extension object. This makes it possible, for example, to extend the <code>ownedMember</code> superset in the <code>
ClassRTImpl
</code> to include the <code>implicitAttribute</code> and <code>implicitConnector</code> properties. This ripples to other derived unions such as <code>ownedElement
</code> and <code>feature
</code>.
[[File:Papyrus-RT_UML-Ext.png|frame|none|alt=|UML Extensions]]
[[File:Papyrus-RT_UML-Ext.png|frame|none|alt=|UML Extensions]]
Line 60:
Line 60:
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).
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).
+
+
=== Relation to the UML-RT Profile ===
+
+
These extensions are modelled to capture primarily the implicit redefinitions of inherited elements that provide distinct objects in the model for "purely inherited" elements. This allows, for example, the Papyrus-RT editor UI to present objects with distinct identities in the Model Explorer and the diagrams to represent the '''same''' element inherited by multiple different namespaces. By actually having distinct objects, any change to one of them made by the UI or some third-party plug-in automatically converts that "virtual element" in the extension domain to a "real element" in the UML model, that redefines the inherited element in the normal UML fashion.
+
+
This is the only purpose for which it is anticipated that the extensions capability will be employed. The primary model extension mechanism in UML is the profile, in the case of Papyrus-RT the UML-RT Profile. What this custom extension capability provides is a kind of extension that profiles cannot model: expansion of property supersets to include additional properties not defined by the UML metamodel. A stereotype may define properties of various kinds, but it cannot define a composite property of any UML metaclass type (UML elements must only be owned by other UML elements), and it most certainly cannot add such a property to a derived union of other superset of the UML metaclass that it extends.
+
+
The expansion of supersets, primarily <code>Namespace::ownedMember</code>, to include properties defined in the extension metamodel affords some convenient properties if done carefully. A particularly good example is in the well-formedness constraints for the <code>Connector</code> metaclass. A connector must only connect <code>role</code>s of the <code>Class</code> that owns it. In Papyrus-RT, an inherited connector, implemented as a "virtual element" in the extension of the class, automatically resolves inherited references to connected roles and parts-with-port to the redefinitions of those roles and parts-with-port in the context of the class that owns it. Those roles and parts-with-port may, themselves, be virtual elements that shadow elements inherited from an ancestor class. Because the class's <code>ownedMember</code> superset is expanded to include the <implicitAttribute> property of its extension, these virtual elements are included in the <code>member</code> superset and its derived subset <code>feature</code> and that subset's further derived subset <code>role</code>. The connector constraint is defined in terms of this <code>role</code> property of its owning class, so the constraint is satisfied without any need to override its specification.
+
+
[[File:Papyrus-RT_Extension_Example.png|frame|none|alt=|UML Extension Example]]
+
+
The image above illustrates the inheritance of a connector by the Capsule2 class: the virtual connector element is contained in its <code>implicitConnector</code> collection and it owns virtual ends that inherit the roles and parts-with-port from the Capsule1 connector in the model (the dotted arrows indicate implied redefinitions; UML connector ends are not redefinable elements). So, these ends inherit references to the port and part in the UML model, but resolve them at run-time to the virtual port and part in the extension. Thus, all roles connected by the virtual connector are properly roles of the Capsule2 that owns it (by extension).
+
+
As the UML-RT profile evolves, the kinds of changes that may have to be made in the extension metamodel to accommodate it are generally in the addition of these ''implicitXyz'' properties in the extension metaclasses, as follows. Given a property (usually a composite aggregation) in the UML metamodel that can contain redefinitions of inherited elements, a corresponding extension property for implicit redefinitions should:
+
+
* be modelled in a metaclass corresponding to the extended UML metaclass. These are given the same name as the UML metaclass in the <code>uml-ext.uml</code> model because the EMF generator model prepends an <code>Ext</code> prefix to the generated Java API names to distinguish them. If the appropriate metaclass is not already defined in the uml-ext then it must be added. And then, where appropriate, generalizations between these metaclasses mirroring the UML structure. So, for example, the extension metamodel has <code>Class</code> → <code>EncapsulatedClassifier</code> → <code>StructuredClassifier</code> as in UML to define the <code>implicitOperation</code>, <code>implicitPort</code>, and <code>implicit{Attribute,Connector}</code> properties with <code>implicitPort</code> being a derived subset of <code>implicitAttribute</code> as in UML. So, the extension object of an UML element is always an instance of the correspondingly named extension metaclass for the UML metaclass, even if it wouldn't otherwise define any extension features.
+
* added to the most appropriate superset of the UML metaclass, usually <code>Namespace::ownedMember</code> if applicable. If there is no suitable superset, then it may not be feasible to add the extension, but there should usually at least be <code>Element::ownedElement</code> as an option. This requires overriding the superset property's accessor in the <code>XyzRTImpl</code> Java class to create a<code>DerivedUnionEObjectEListExt</code> that properly accounts for extension properties as subsets
== Façade API ==
== Façade API ==