ST6RI-521 Keyword metadata for language extension

[seidewitz]

This pull request adds a mechanism that allows "semantic metadata" annotations to be used to specify implicit specialization of declared types. It also provides a new keyword notation for annotations in the SysML grammar.

1. Semantic metadata. The SemanticMetadata metaclass was included in the Kernel Metaobjects package added in PR #347. It is intended to be specialized with its baseType feature bound to a specific reflective Type metaobject value. When a specialization of SemanticMetadata is used to annotate an appropriate type declaration, the specified baseType is used to implicitly specialize the annotated type.

   • If the annotated type is neither a Classifier nor a Feature, then the annotated type implicitly specializes the baseType.
   • If the annotated type is a Classifier and the baseType is a Classifier, then annotated classifier implicitly subclassifies the baseType.
   • If the annotated type is a Classifier and the baseType is a Feature, then the annotated classifier implicitly subclassifies each type of the baseType.
   • If the annotated type is a Feature and the baseType is a Feature, then the annotated feature implicitly subsets the baseType.
   • In all other cases, no implicit specialization is added.

2. Casting. The cast operator as has been added to the implemented operators for model-level evaluable expressions. In addition, if the target type of the case is a metaclass, and the argument expression evaluates to a feature whose abstract syntax metaclass conforms to the given metaclass, then the result is a "meta-upcast" to the metaobject representation of the feature. (E.g., if vehicle is a part usage, then vehicleasKerML::Feature evaluates, as a model-level evaluable expression, to a MetadataFeature for vehicle with type SysML::PartUsage.)

   Note: The 2022-02 baseline did not add an expression for obtaining the metaclass of an element. Using the cast operator is a workaround at this time. It means that, currently, it is only possible to specify a feature as a SemanticMetadata::baseType. However, this is sufficient to also define implicit specializations for classifiers, as described above.

3. Keywords. A user-defined keyword is a (possibly qualified) metaclass/metadata definition name or human ID preceded by the symbol #. Such a keyword can be used in the SysML textual notation in package, dependency, definition and usage declarations. The user-defined keyword is placed immediately before the language-defined (reserved) keyword for the declaration and specifies a metadata annotation of the declared element. For example, if SafetyCritical is a visible metadata definition, then #SafetyCriticalpartbrakes; is equivalent to partbrakes { @SafetyCritical; }.

   Notes:

   • User-defined keywords are not currently available in the KerML notation.
   • If the given metaclass or metadata definition is a kind of SemanticMetadata, then the implicit specialization rules given above apply.
   • It is not possible to specify nested features for a metadata feature annotation in the keyword notation.

4. Extended definitions and usages. The metaclasses Definition and Usage are no longer abstract in the 2022-03 baseline abstract syntax. This allows the possibility of declaring a definition or usage without a language keyword identifying a more specialized kind, as long as a user-defined keyword is given to specify SemanticMetadata to be used for implicit specialization. For example, if provider is the human ID of SemanticMetadata whose baseType is the feature serviceProviders : ServiceProvider, then #providerdefBankingService; parses to a Definition with an implicit subclassification of ServiceProvider and #provider bankingService; parses to a Usage with an implicit subsetting of serviceProviders.

[himi]

I'm confused that the explanation of as operator. If we write vehicle as KerML::Feature, I think it should be upcast to KerML::Feature rather than SysML::PartUsage. Or am I misunderstand it? In my understanding, as operator is needed to resolve diamond problems in multiple inheritance. Is that right?

[seidewitz]

I'm confused that the explanation of as operator.

The static type of an expression like xasKerML::Feature is KerML::Feature, and that is what is used for static type checking. However, dynamically the expression evaluates to the actual meta object for x (as long as that is a subtype of KerML::Feature). Thus, if x is a part usage, then the result will be an instance of SysML::PartUsage, which is an (indirect) subtype of KerML::Feature.

Other than the meta-shift, this is similar to normal up-casting, in which the dynamic runtime type of the result may be a subtype of the static type given in the cast. The important thing is that this is consistent with the static type checking.

[himi]

Oh, I see. as actually allows incompatible cast to pass static type checking. Thanks.