ST6RI-417 Reflective library models for abstract syntax

[seidewitz]

This pull request updates the reflective library models KerML.kerml in the Kernel Semantic Library and SysML.kerml in the Systems Library to include all metaclasses, enumerations and (navigable) properties from the abstract syntax models for KerML and SysML. These are generated using a model-to-text transformation implemented by Xtend programs added to the org.omg.sysml project in the package org.omg.sysml.generation. These programs use a special SysML.uml (in the package directory) that retains the top-level packaging from the abstract syntax (i.e., Root, Core, Kernel and Systems), which is created using a new QVT transform PrepareMetamodelPackages.

Abstract Syntax Mapping

The MOF abstract syntax model is mapped to KerML and SysML as follows.

1. The KerML model contains subpackages for Root, Core and Kernel, but all elements are also imported into the top-level package, so they can be referenced directly from the KerML namespace. The SysML model imports all elements from KerML and directly contains all elements mapped from the Systems package, without any subpackaging.
2. A metaclass from the MOF model is mapped into a metaclass (in KerML) or a metadata def (in SysML).
   • The MOF metaclass name is mapped unchanged.
   • Generalizations of the MOF metaclass are mapped to owned specializations (e.g., specializesOwningMembership, Featuring)
   • All properties from the MOF metaclass are mapped to features of the corresponding KerML metaclass or SysML metadata definition (see below). All non-association-end properties are grouped before association-end properties.
3. A property from the MOF model is mapped into a feature (in KerML) or an attribute or item (in SysML, depending on whether the property type is a data type or a class).
   • The following prefix keywords are used as appropriate:
     • abstract if the MOF property is a derived union
     • In KerML only, composite if the MOF property is composite.
     • readonly if the MOF property is read-only.
     • derived if the MOF property is derived.
     • In SysML only, ref if the MOF property is not composite.
   • The MOF property name is mapped unchanged, but is surrounded in single quotes if it is the same as a keyword (e.g., 'type' in KerML).
   • The MOF property type is mapped to an owned feature typing (e.g., : Type).
   • The MOF property multiplicity is mapped to an owned multiplicity range (e.g., [0..*])
   • Subsetted properties from the MOF property are mapped to owned subsettings (e.g., subsetsannotatedElement, owningRelatedElement).
   • Redefined properties from the MOF property are mapped to owned redefinitions (e.g., redefinestarget, annotatedElement).
   • If the MOF property is annotatedElement, then annotatedElement is added to the list of redefined properties for the mapping because, otherwise, there would be a conflict with the annotatedElement property inherited from Metaobject.
4. An enumeration from the MOF model is mapped into a datatype (in KerML) or an enum def (in SysML).
   • The MOF enumeration name is mapped unchanged.
   • Each enumeration literal from the MOF enumeration is mapped into a member feature (in KerML) or an enum (in SysML).
     • The MOF enumeration literal name is mapped unchanged, but is surrounded in single quotes if it is the same as a keyword (e.g., 'private').
     • In KerML only, the member feature is explicitly typed by the containing data type and has multiplicity [1].

Note that associations are not mapped from the MOF model and, hence, non-navigable association-owned end properties are not included in the reflective models.

Note: There is an inconsistency in the abstract syntax model for ConjugatedPortTyping in the Systems abstract syntax, which results in a validation error on the mapping of ConjugatedPortTyping::portDefinition. As a result, this feature is currently commented-out in SysML.sysml. This issue needs to be resolved in the 2022-09 baseline metamodel before it can be fixed in the reflective abstract syntax model. When the baseline is updated under ST6RI-597, this will be fixed in SysML.sysml.

Reflection Implementation

The implementation of reflection for model-level evaluable expressions has been updated as follows.

1. "Meta-casting" of a feature using as now returns a special metadata feature known as the "metaclass feature" for an element. This feature is typed by the appropriate metaclass from the reflective abstract syntax. It is generated on request and cached in the ElementAdapter for the element. Note: "Meta-casting" will be replaced with a more specific notation for metaclass access under ST6RI-597, and the implementation here will be further refined at that time.
2. References to reflective abstract syntax metaclass features can now be evaluated when the target is a metaclass feature. The evaluation is done by making a dynamic EMF call to get the value of the Ecore structural feature of the annotated element of the metaclass feature with the same name as the referenced feature.
3. The implementation of model-level evaluation has also been generally updated to, as much as possible, return an "unevaluated expression" as the result when an expression is not evaluable at some point, rather than returning null as before. For import filtering, unevaluable expressions are now treated as if they were "false", rather than being ignored as before.

[seidewitz]

cc: @himi @ivan-gomes

[vincemolnar]

All my concerns have been addressed.