2022-03 - SysML v2 Pilot Implementation

This is an incremental update to the 2022-02 release. It corresponds to Eclipse plugin version 0.22.0.

Language Features

1. Metadata annotation.

   • Definition. Previously, metadata was defined simply as a datatype in KerML or an attribute def in SysML. Now it is defined using a metaclass in KerML (which is a kind of struct) or a metadata def in SysML (which is a kind of item def).
   • Usage. Most syntactic restrictions on a feature declared in the body of a metadata declaration have been removed. In particular, it is now possible for a feature defined in the body of a metadata declaration to itself have nested subfeatures. However, some additional validation checks have also been implemented for such features (see details under "Backwards Incompatibilities" below).
   • Annotated elements. A metadata definition or usage now, by default, inherits an annotatedElement feature from the Kernel base metaclass Metaobject. If this feature is (concretely) subsetted or redefined in a metadata definition or usage to have a more restrictive metaclass (using the reflective KerML or SysML models) than the default of KerML::Element, then the metadata can only annotate elements consistent with that metaclass. For example, if a metadata definition includes the redefinition :>> annotatedElement : SysML::PartUsage;, then any usage of that definition can only annotate part usages.

   [PR #347]

2. Semantic metadata. The new Kernel Library package Metaobjects defines the metaclass SemanticMetadata (see below). Any metaclass or metadata definition that specializes SemanticMetadata should bind the inherited baseType feature to a reference to a feature or usage from a user library model (see "Casting" below on how to do this). When such a specialization of SemanticMetadata is used to annotate an appropriate type declaration, the specified baseType is used as the implicit base specialization of the annotated type.

   • If the annotated type is a Feature/Usage, then the annotated feature implicitly subsets the baseType.
   • If the annotated type is a Classifier/Definition, then the annotated classifier implicitly subclassifies each type of the baseType.

   Note. It is currently only possible to specify a feature or usage as a baseType. This will be expanded to also allow classifiers in the future.
   [PR #349]

3. Casting. The cast operator as has been implemented 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. This can be used, for example, to bind baseType = vehicleasKerML::Feature; for SemanticMetadata.
   [PR #349]

4. Keywords (SysML only). 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; }. It is not possible to specify nested features for a metadata feature annotation in the keyword notation.
   • If the given metaclass or metadata definition is a kind of SemanticMetadata, then the implicit specialization rules given above for "Semantic metadata" apply. In addition, a user-defined keyword for semantic metadata may also be used to declare a definition or usage without using any language-defined keyword. For example, if provider is the human ID of a specialization of SemanticMetadata whose baseType is the feature serviceProviders : ServiceProvider, then #providerdefBankingService;is a definition with an implicit subclassification of ServiceProvider and #provider bankingService; is a usage with an implicit subsetting of serviceProviders.

   [PR #349]

Model Library

Kernel Library

1. Metaobjects. This is a new package with the following members.

   • Metaclass Metaobject (subclassifies Objects::Object) is the implicit base type of all metaclasses.
   • Metaclass SemanticMetadata (subclassifies Metaobject) is used to extend the language implicit specialization mechanism for use with user-defined semantic libararies (see "Semantic metadata" above).
   • Feature metaobjects is the implicit base type of all metadata features. (This is not itself a metadata features, because a metadata feature is an annotating element, while metaobjects is not.)

   [PR #347]

2. KerML. All struct declarations in the KerML package have been changed to metaclass (with Element implicitly subclassifying Metaobject). (Note that the reflective KerML abstract syntax model still does not include any features on these metaclasses.)
   [PR #347]

Systems Library

1. Metadata. This is new package with the following members.

   • Metadata definition MetadataItem (subclassifies Items::Item and Metaobjects::Metaobject) is the implicit base type of all metadata definitions.
   • Item usage metadataItems is the implicit base type of all metadata usages. (This is not itself a metadata usage, because a metadata usages is an annotating element, while metadataItems is not.)

   [PR #347]

2. SysML. All item def declarations in the SysML package have been changed to metadata def. (Note that the reflective SysML abstract syntax model still does not include any features on these metadata definitions.)
   [PR #347]

Analysis and Metadata Domain Libraries

1. Metadata definitions. Those attribute definitions in packages AnalysisTooling, ModelingMetadata and RiskMetadata that were intended to be used to define metadata have been changed to metadata definitions.
   [PR #347]

Backward Incompatibilities

1. Keywords. KerML: added metaclass. SysML: removed feature.

2. Annotations. An annotation relationship is no longer added to an annotating element that is an owned member of a namespace and does not explicitly specify any annotated elements (i.e., no about part). Instead, its owning namespace is simply considered to be the annotated element by default, without the need for an annotation relationship. (There is no change to the concrete syntax notation.)
   [PR #347]

3. Documentation. Documentation is now a special kind of comment that always has its owning element as its single annotated element, rather than a special kind of annotation association to a regular comment element. (There is no change to the doc notation, just a different mapping to the abstract syntax.)
   [PR #347]

4. Prefix Comments. The comment keyword is now used for a prefix comment (/**...*/), e.g., to give it a name, rather than the doc keyword. Previously, prefix comments were supposed comments owned by the following element using a documentation relationship, but it was difficult to implement them that way. They are now ordinary (non-documentation) comments that are just always about the lexically following element.
   [PR #347]

5. Metadata.

   • The following validation checks are now performed on the declaration of a metadata feature or usage:
     • It must be defined by a concrete metaclass (in KerML) or metadata definition (in SysML).
     • Each of its nested features/usages (if any) must pass the following validation checks:
       • It must redefine a feature (owned or inherited) of a generalization of its owning feature.
       • If it has a feature value, the value expression must be model-level-evaluable.
       • Each of its nested features (if any) must also pass these validation checks.
   • Usages declared in the body of a metadata usage are now parsed as reference usages. The optional keyword for their declaration is therefore now ref instead of feature.

   [PR #347]

6. Classifier base type. A validation check has been added that a classifier or definition directly or indirectly specializes the correct library base type. This will typically only be violated for vacuous circular specializations or invalid circular conjugations.
   [PR #351]

Jupyter

None.

Visualization

1. PlantUML

   • Improve rendering of connections.
   • Support visualization of
     • inherited feature ends or expressions.
     • nested features in metadata annotations
     • ports with directed features

   [PR #348]

2. Tom Sawyer
   None.

Technical Updates

1. Vulnerability. Updated yarn.lock to address security alerts.
   [PR #346]

Bug Fixes

1. Multiplicity subsetting. Fixed the KerML grammar for MultiplicitySubset.
   [PR #350]
2. Circular conjugation. Fixed stack overflow caused by a circular conjugation declaration.
   [PR #351]
3. Non-ASCII characters. Revised the loading of libraries for Jupyter so that UTF-8 is always used as the character encoding (regardless of the platform default).
   [PR #352]
4. Space modeling. Corrected errors related to space modeling in the Kernel Library Occurrences and Objects models, in the Geometry Domain Library ShapeItems model and in the example CarWithShapeAndCSG. Also added PlanarCurve to ShapeItems.
   [PR #355]