2024-12 - SysML v2 Pilot Implementation

This is an incremental update to the 2024-11 release. It corresponds to Eclipse plugin version 0.47.0.

New Features

KerML

1. Cross subsetting. A cross feature of an end feature is specified using a new cross subsetting relationship between an end feature and its cross feature. The cross multiplicity of an end feature refers to the multiplicity of its cross feature, rather than the multiplicity of the end feature itself, which is always 1..1. The cross ordering and uniqueness of end features similarly refer to those of their cross feature.

   Cross subsetting is identified by the crosses keyword or the equivalent symbol =>. For example,

   struct LegalEntity {
       feature assetsOwned [*] ordered : Asset;
   }
   struct Asset {
       feature owningEntities [1..*] : LegalEntity;
   }
   assoc AssetOwnership {
       end owner : LegalEntity crosses ownedAsset.owningEntities;
       end ownedAsset : Asset crosses owner.assetsOwned;
   }
   

   With the specified cross subsetting, creating an AssetOwnership link between a LegalEntity and an Asset means that the Asset must be one of the aassetsOwned by the LegalEntity and that the LegalEntity must be one of the owningEntities of the Asset. As shown above, the target of a cross subsetting relationship must be a feature chain in which the first feature is the other association end and the second feature is the cross feature for that end.

   Cross feature multiplicity effectively constrains the number of instances of an association. It applies to each set of instances (links) of the association that have the same (single) values for each of the other ends. For a binary association, this is the same as the number of values resulting from "navigating" across the association from an instance of one related type to instances of the other related type. Cross feature uniqueness and ordering apply to the instances navigated to, preventing duplication among them and ordering them to form a sequence.

   If an end instead has an owned cross feature, the cross subsetting is implicit. The cross multiplicity, ordering and non-uniqueness can then be declared directly on an end feature, with a notation that makes it clear that these are properties of the cross feature, not the end feature itself:

   assoc AssetOwnership {
       end [1..*] feature owner : LegalEntity;
       end [*] ordered feature ownedAsset : Asset;
   }
   

   If no cross feature is given for an end, then its cross multiplicity is effectively 0..* by default.

   Connector ends declared in the body of a connector may have cross features, specified using cross subsetting, as for association ends. The cross feature for the connector end further constrains any inherited cross feature(s). In the more common shorthand notation for connectors, the cross multiplicity (but not ordering or non-uniqueness) can be given at the before of the end's related feature (previously this was given after the related feature):

   struct WheelAssembly {
       composite feature halfAxles[2] : Axle;
       composite feature wheels[2] : Wheel;
       // Connects each one of the halfAxles to a different one of the wheels.
       connector from [1] halfAxles to [1] wheels;
   }
   

   [PR #608]

SysML

1. Cross subsetting. The crosses keyword can also be used in SysML, with the same meaning as in KerML.

   part def LegalEntity {
       ref part assetsOwned [*] ordered : Asset;
   }
   part def Asset {
       ref part owningEntities [1..*] : LegalEntity;
   }
   connection def AssetOwnership {
       end part owner : LegalEntity crosses ownedAsset.owningEntities;
       end part ownedAsset : Asset crosses owner.assetsOwned;
   }
   

   The notation for owned cross features is also similar:

   connection def AssetOwnership {
       end [1..*] part owner : LegalEntity;
       end [*] ordered part ownedAsset : Asset;
   }
   

   As is the shorthand notation for connection usages (including interface usages):

   part WheelAssembly {
       part halfAxles[2] : Axle;
       part wheels[2] : Wheel;
       // Connects each one of the halfAxles to a different one of the wheels.
       connect [1] halfAxles to [1] wheels;
   }
   

   In addition, for SysML, end features always have a default multiplicity of 1..1, even for kinds of usages that would otherwise not have that default if they were not ends.
   [PR #608]
2. Transfers across interfaces. The semantic library models for ports and interfaces have been updated to formalize the semantics for the automatic targeting of a transfer outgoing from a port at one end of an interface to a port at another end of the interface. That is, if an send action is used to initiate a transfer via a port, then, if that port is at one end of a binary interface, that transfer will automatically target the port at the other end of the interface, and the transfer can then be accepted via that target port. However, a transfer can only have one target, so, if a port is connected to an interface with more than two ends, or to multiple interfaces, the transfer will be targeted to exactly one of the possible target ports across all other interface ends.

   part def DistributedSystem {
       item def Request;
       item def Response;
   
       part client {
           port clientPort;
           action clientBehavior {
               send Request() via clientPort;
               then accept Response via clientPort;
           }
       }
   
       part server {
           port serverPort;
           action serverBehavior {
               accept Request via serverPort;
               then send Response() via serverPort;
           }
       }
   
       // Transfers from the clientPort automatically target the serverPort
       // and vice versa.
       interface client.clientPort to server.serverPort;
   }
   

   [PR #610]

Backward Incompatibilities

1. Reserved words. New KerML and SysML keyword: crosses
2. Flow connections. Flow connection usages are no longer kinds of structural connection usages (which are kinds of part usages). This has no effect on the concrete syntax or behavioral semantics of flows. But it means that, in the abstract syntax, flow connection usages will no longer appear in the list of ownedParts of a Definition or the nestedParts of a Usage. However, they do still appear in the lists of ownedConnections/nestedConnections (since they are still kinds of KerML connectors). Semantically, composite flows are also no longer subparts of a containing Item or Part, but they remain as subactions of a containing Action. The model library elements related to flow connections have been move out of the library package Connections to the new package FlowConnections.
   [PR #607]
3. Cross features. Formerly, cross multiplicities were specified directly on end features, even though this meant they had a different semantics than multiplicities on regular features. With the introduction of cross features, the multiplicity of end features is now required to be 1..1 (like participant properties in SysML v1). Giving an end feature a multiplicity other than 1..1 currently results in a warning, but this will become an error in the future. However, multiplicities in the old position on connector or connection ends in the shorthand notation will result in syntax errors. In either case, the multiplicity should be moved to the position of a cross multiplicity (as shown above).
   [PR #608]
4. Structure/behavior validation. Validations have been added such that a KerML structure cannot specialize a behavior, and vice versa. In SysML, kinds of structures include definitions of items, parts, ports, metadata, renderings and connections (but not flows). Kinds of behaviors include definitions of actions, states, constraints, requirements, cases, views and flows.
   [PR #609]
5. Feature chain expressions. The target of the implied subsetting of the result of a feature chain expression has been updated to be the feature chain of the expression rather than just the final target feature. This has no affect on end-user models.
   [PR #611]
6. Index expressions. Index expressions are now parsed to a new IndexExpression metaclass in the abstract syntax. This has no affect on end-user models.
   [PR #611]
7. Annotations. The abstract syntax for annotations has been revised so that an annotation relationship must be owned be either its annotated element or its annotating element. These were already the only possibilities when parsing from the textual notation.
   [PR #611]
8. Transitions. Transitions in a state model whose source is not a state usage (for example, if the source is the entry action) are now semantically considered to be decision transactions, that is, they have the same semantics as conditional successions in action models. It is therefore now a validation error to have an accepter on such a transition.
   [PR #612]
9. Inheritence. The Beta 2.4 KerML Specification includes a complete specification of the computation of the inherited memberships of a type, and the implementation has now been updated to conform to this. The update resolves certain anomalies in the case of "diamond inheritence" in which a feature could be unexpectedly inherited multiple times, or in which what was inherited depended on the ordering of specializations. Note, however, that the handling of inheritance for name resolution is separate from this computation, and some anomalies still exist when resolving names.
   [PR #613]

Issue Resolutions

This release includes implementation of resolutions to the issues listed below.

KerML

Resolution of the following issue was approved on KerML FTF1 Ballot 3, but its implementation was blocked until the resolution of SYSML2_-173.

• KERML-43 Performances can be objects, behaviors can be structures

Resolutions for the following issues were approved on KerML FTF2 Ballot 4.

• KERML_-18 Redundancy in association end multiplicities, ordering, and uniqueness
• KERML_-39 Type::inheritedMemberships OCL is missing
• KERML_-68 deriveExpressionResult and deriveFunctionResult should be revised
• KERML_-72 Editorial errors in constraints
• KERML_-99 CheckFeatureChainExpressionResultSpecialization constraint needs to be defined
• KERML_-117 InvocationExpresion::result specialization
• KERML_-119 Navigability of AnnotatingElement<->Annotation meta-association
• KERML_-140 MultiplicityRanges should allow owned members other than bounds

SysML

Resolutions for the following issues were approved on SysML v2 FTF2 Ballot 6.

• SYSML2_-39 Semantics of transfers across interfaces
• SYSML2_-89 Accepters on transition usages from entry actions
• SYSML2_-108 Various constraints need to take feature chaining into account
• SYSML2_-173 Flow connections are incorrectly both structure and behavior
• SYSML2_-263 There is no checkSatisfyRequirementUsageSpecialization constraint
• SYSML2_-265 Missing semantic constraints related to features of Part
• SYSML2_-416 Cross features for connection definitions and connection usages

Jupyter

None.

Visualization (PlantUML)

None.

Technical Updates

1. Adapters. In order to make adapters more robust in the case of multiple generalization of metaclasses in the abstract syntax model, an explicit adapter has been introduced for each metaclass with multiple generalizations. These new adapters have no behavior of their own, but ensure that behavior is delegated to the appropriate general type. Tests were also added to check the adding of implied relationships for semantic constraints.
   [PR #606]
2. SysML parser. If the complexity of an Xtext grammar is too great, then the internal Java parser generated for the grammar can have static initializers whose combined size exceeds the 64K limit allowed by Java. With the introduction of cross features, the SysML grammar has hit this limit (but not the KerML grammar). To resolve this, a step has been added to the generation workflow for the SysML grammar so that the internal Java parser code is automatically split across multiple files, each of which is below the 64K limit.
   [PR #608]

Bug Fixes

1. Owned ports. Corrected the implementation of the implicit specialization of ports nested in a part as ownedPorts of the part.
   [PR #612]