2025-02 - SysML v2 Pilot Implementation

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

Language Features

KerML

1. Global scope notation. The qualified name notation has been extended to allow it to optionally have the global scope qualifier $ as its initial segment, as in $::A::B::C. Resolution of the remainder of such a qualified name then begins in global scope, rather than in the local scope in which the qualified name is parsed.
   [PR #635]

2. Variable features. Variable features are features of occurrences whose values may vary over time. This is specified semantically by making the domain of a variable feature (i.e., its featuring type) the snapshots of its owning type, rather the owning type itself. Therefore, a variable feature can have different values on different snapshots of an occurrence, effectively "varying over time". The multiplicity of a variable feature is relative to each snapshot, rather than to the life of the occurrence.

   A variable feature is notated in the concrete syntax using the new keyword var.

   // An instance of a Vehicle is a Life by default.
   struct Vehicle {
       // This feature has a single value for the Vehicle's life.
       //  It is not a feature of its timeslices or snapshots.
       feature id : VehicleId [1];
   
       // This feature can have a different single value on each snapshot of a Vehicle.
       var mileage : Distance [1];
   }
   

   A feature that is specified as variable can, nevertheless, be further specified as constant using the keyword const (instead of var), meaning that it does not actually change its value over the duration of its featuring occurrence (this replaces the previous concept of readonly). This can be useful for asserting that a feature has values that are the same over only some of the time an occurrence exists, even though it could potentially vary at other times.

   struct Vehicle {
       feature id : VehicleId [1];
       var mileage : Distance [1];
   
       portion parked :> timeSlices [*] {
           // When a Vehicle is parked, its mileage does not change.
           const :>> mileage;
       }
   }
   

   The end features of an association structure may also be declared as constant features by placing the keyword const before the keyword end. Whether or not an end feature is declared as constant, its value cannot change for the lifetime of an instance of the owning association structure. However, a constant end feature may subset or redefine a variable feature, while a regular end feature cannot.

   struct AssetOwnershipRecord {
       var feature owner : LegalEntity [1];
       var feature ownedAsset : Asset [1];
   }
   assoc struct AssetOwnershipRelationship specializes AssetOwnershipRecord {
       const end feature redefines owner;
       const end feature redefines ownedAsset;
   }
   

   [PR #637]

3. Constructor expressions. Previously, an invocation expression where the invoked type was not a function acted as a constructor for an instance of the invoked type. Instead, a new constructor expression has now been introduced to do instance construction.

   The concrete syntax for a constructor expression is similar to that of an invocation expression, but preceded by the keyword new.

   class Member {
       feature firstName : String;
       feature lastName : String;
       feature memberNumber : Integer;
       feature sponsor : Member[0..1];
   }
   feature thisMember = new Member("Jane", "Doe", 1234, null);
   feature nextMember = new Member(
       firstName = "John", lastName = "Doe", sponsor = thisMember,
       memberNumber = thisMember.memberNumber + 1);
   

   [PR #638]

4. Flows. What were previously called item flows are now just called flows. There is no change to the concrete syntax, but there are corresponding changes in the Kernel Semantic Library (see below).
   [PR #639]

SysML

1. Send and accept actions. The expressiveness of send action textual notation syntax has been improved. In particular, send action notation of the following form is allowed, in which all parameters are bound in the send action body:

   send{
    inpayload =payloadExpression;
    insender =senderExpression;
    inreceiver =receiverExperssion;
}

   as well as the following mixed forms

   sendpayloadExpression {
    insender =senderExpression;
    inreceiver =receiverExperssion;
}

   and

   sendpayloadExpressionviasenderExpression{
    inreceiver =receiverExperssion;
}

   Further, instead of using feature values, values can also be provided for the nested parameters by using either flows or binding connections outside the send action usage. In addition, in the form

   actionactionNamesend viapayloadExpressiontoreceiverExpression;

   the payload parameter is also implicitly redefined, but it can still be referred to by name (e.g., actionName.payload), for use as the target of a flow or binding connection.

   There is also a similar update to the syntax for accept action usages. The current syntax is

   accepttriggerDeclarationviareceiverExpression;

   It is now also possible to redefine the receiver parameter (but not the triggerDeclaration, which declares an output parameter) in the body of the accept action usage, so it can be given a value using an explicit binding or flow. The proposed notation has the form:

   accepttriggerDeclaration{
    inreceiver =receiverExpression;
}

   [PR #626]

2. Global scope notation. Global scope notation (as described above for KerML) is also available in SysML. This can be particularly useful for accessing a library package that would otherwise be hidden be a local package with the same name. For example, in the following model, the use of the global scope notation means that Requirements::FunctionalRequirementCheck resolves to the appropriate element of the library package Requirements, which would otherwise be hidden by the containing Requirements package.

   package UserModel {
       package Requirements {
           requirement`**`r1 : $::Requirements::FunctionalRequirementCheck;
           ...
       }
   }
   

   [PR #635]

3. Variable features. In SysML, it is already expected that features of occurrences can change over time, particularly for structural occurrences like items and parts. For example, if a Vehicle is modeled as having an engine with multiplicity 1..1, then the expectation is that any individual Vehicle as exactly one engine at any point in time, but may have different engines over time. Therefore, a feature of an occurrence definition or usage in SysML is automatically able to vary in time, except for the following kinds of features, which, instead, have values relative to the entire duration of the featuring occurrence:

   • Time slices and snapshots, because they represent specific portions of the duration of their featuring occurrences.
   • Bindings, because they reflect relationships that can hold across time.
   • Successions, because they determine ordering of occurrences across time.
   • Composite subactions, because their values and ordering across time are determined by succession relationships and other control constructs.

   Since whether a feature may time vary is determined automatically, there is no keyword in SysML corresponding to var in KerML. However, a feature that would otherwise be allowed to vary in time may be declared to nevertheless have a constant value using the constant keyword (which replaces the previous readonly keyword). Such a feature must have the same value over the entire duration of a featuring occurrence.

   occurrence def Flight {
       ref part aircraft : Aircraft;
   }
   occurrence def ApprovedFlight :> Flight {
       // This redefines the aircraft feature so it is constant for
       // an entire ApprovedFlight.
       constant ref part approvedAircraft redefines aircraft;
   }
   

   The constant keyword cannot be used on an end feature in SysML. However, any end feature that is automatically variable is also automatically constant.

   [PR #637]

4. Constructor expressions. Constructor expressions (see description above under KerML) can also be used in SysML.
   [PR #638]

5. Flows. What were previously called flow connection definitions, flow connection usages and succession flow connection usages are now called flow definitions, flow usages and succession flow usages, respectively. There is no change to the concrete syntax, but there are corresponding changes in the Systems Library (see below).
   [PR #639]

6. Time slices and snapshots. Time slices and snaphots are no longer required to be typed (implicitly or explicitly) by their individual definition. This avoids anomalies due to unexpected inheritance.
   [PR #640]

Model Libraries

1. All libraries. The .project.json and .meta.json files in each of the library model directories have been updated to reflect the Beta 3 version of the specification, so that, when the directories are compressed as Zip archives, they produce valid KerML Project Archive (.kpar) files. (These .kpar files where submitted to OMG as normative artifacts with the KerML 1.0 and SysML 2.0 Beta 3 specifications, but the files are not themselves included in the SysML 2 Pilot Implementation repository.)
   [PR #641]
2. _Kernel Semant...

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

Resolut...

2024-11 - SysML v2 Pilot Implementation

This is an incremental update to the 2024-09 release (there was no 2024-10 release). It corresponds to Eclipse plugin version 0.46.0.

New Features

1. Terminate actions. A terminate action is used to terminate the performance of some other action. It has the form

   actionnameterminateexpression;

   The action part is optional. The expression evaluates to the action to be terminated. The terminated action ends its performance no later than the completion of the terminate action. If the expression is omitted, the default is the immediately containing action of the terminate action.

   action outerAction {
       in action a;
       action term_a terminate a; // terminates a
       then terminate; // terminates outerAction
   } 
   

   A terminate action usage may also be used to terminate a non-action occurrence (such as a part). In this case, the lifetime of the terminated occurrence must end no later than the completion of the terminate action. That is, the terminate action usage effectively "destroys" the terminated occurrence.

   part container {
       part component : Component[0..1];
       action act {
           assign component := Component(); // Create component
           then terminate component; // Destroy component
       }
   }
   

   [PR #597]

Backward Incompatibilities

1. Reserved words. New SysML keyword: terminate

Issue Resolutions

1. SysML Metamodel. The SysML concrete syntax, abstract syntax and model library have been updated consistent with the resolution of the following SysML v2 FTF issue.

   • SYSML2_-44 Transformation of UML4SysML::ActivityFinalNode is not specified yet

     [PR #597]

   The resolution to the following issue had already been substantially implemented, but the implementation has been further updated consistent with the final resolution.

   • SYSML2_-222 TransitionUsage source and target properties do not support feature chains

     [PR #602]

Jupyter

None.

Visualization (PlantUML)

Bug fix.

Technical Updates

1. Caching. Added clearing of the cached effectiveName and effectiveShortName of elements.

   [PR #595]

Bug Fixes

1. Port conjugation. Fixes the setting of the source and conjugatedType fields of a PortConjugation.

   [PR #596]

2. Transition usage. Fixes the parsing of the source of a transition usage when it is a feature chain.

   [PR #600]

3. Transition usage rendering (PlantUML). Fixes the rendering of transition usages to resolve its succession end features correctly.

   [PR #601}

4. Binding connections. Fixes the implicit subsetting of binding connections as usages in SysML models.

   [PR #603]

2024-09 - SysML v2 Pilot Implementation

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

New Features

None.

Backward Incompatibilities

None.

Issue Resolutions

None.

Jupyter

None.

Visualization (PlantUML)

1. Metadata. Metadata is now rendered in a compartments if it is owned by an element that is rendered with compartments.

   [PR #592]

Technical Updates

1. Peformance. The performance of certain validation and transformation computations has been significantly improved by revising the computation of inherited memberships

   [PR #594]

Bug Fixes

1. Index file encoding. Updates generation of the library index to always use UTF-8 encoding.

   [PR #593]

2024-08 - SysML v2 Pilot Implementation

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

New Features

None.

Backward Incompatibilities

1. Import visibility. The deprecation warning for default-public import visibility has been removed in this release. All imports (other than view usage expose declarations) now have private visibility by default. Further, in the textual notation, it is now mandatory to declare the visibility explicitly, even for private.

   Warning. Parsing errors due to imports without visibility in top-level packages can result in unexpected corruption of the global namespace and cascading errors. For projects with a significant number of models having imports remaining without explicit visibility indicators, it is recommended to correct these before upgrading to this release.

   [PR #589]

Issue Resolutions

1. KerML Metamodel. The resolution of the following issue is now fully implemented.

   • KERML_-74 Make imports private by default

   [PR #589]

2. SysML Metamodel. The resolution of the following issue is now fully implemented.

   • SYSML2_-207 Update language description and concrete syntax related to imports

   [PR #589]

Jupyter

1. Performance. The Jupyter deployment has been updated to use the new library index to significantly improve the performance of processing cells that contain large SysML v2 models. (See also "Library Index" under Technical Updates, below.)

   [PR #587]

Visualization (PlantUML)

None.

Technical Updates

1. Library Index.

   • Performance of name resolution has been significantly improved by using a pre-calculated index of names in the standard library models to avoid long searches in library namespaces for unresolvable names.
   • The library index can be generated by right-clicking on the sysml.library project in an Eclipse runtime instance and selecting Generate Library Index from the drop-down menu. The library models will first all be re-built before the index is generated.
   • The library index is stored in the repository in the sysml.library project, so it is not necessary to re-generate the index unless a change is made to one of the standard library models.

   [PR #589]

Bug Fixes

1. Transition source. Allows a feature chain to used as the source of a transition. (It was already possible to use a feature chain as the target.)

   [PR #590]

2024-07 - SysML v2 Pilot Implementation

This is an incremental update to the 2024-05 release (there was no 2024-06 release). It corresponds to Eclipse plugin version 0.43.2.

New Features

None.

Backward Incompatibilities

1. Import visibility.

   • All imports (other than view usage expose declarations) now have private visibility by default in the KerML and SysML v2 abstract syntax models. In the textual notation, it will be mandatory to declare the visibility explicitly, even for private. However, in order to allow a transitional period, import declarations without an explicit visibility indicator will continue to be default public, but will give a warning message: "Default public import is deprecated; make private if possible". Import declarations with this warning will result in syntax errors in the next release.
   • In addition, imports at the top-level in a model (that is, not nested in any other namespace, and, so, importing into the "root namespace") are now required to be private. (This prevents the "re-export" of names imported into a root namespace directly back into the global scope, which simplifies global name resolution.)
   • Expose declarations are kinds of imports. However, unlike regular imports, expose declarations are know required to have protected visibility. That is, elements exposed by the declaration are visible only within the exposing view usage and any specializations of that view usage. Since the visibility is always protected, a visibility indicator is no longer part of the syntax of an expose declaration.

   [PR #582]

2. Action invocation. Previously, invoking a KerML behavior (as opposed to a function) or SysML v2 action definition (as opposed to a calculation definition) in an expression was specified as performing the behavior, but resulting in a null (empty) result value. This is now changed so such an invocation is treated as a "constructor expression" for the behavior or action, returning the behavior performance itself, which allows access to the values of any output parameters of the behavior or action. For example, in the following model, the value of a_out will be 3.

   action def A {
       in x;
       out y = x;
   }
   action a = A(x = 3);
   ref a_out = a.y;
   

   [PR #582]

3. Analysis actions. The definition for AnalysisAction has been removed from the Systems Library model AnalysisCases. The subactions of an AnalysisCase can be any kind of action, so there was no need for a special kind of AnalysisAction.

   [PR #583]

Issue Resolutions

KerML

1. KerML Metamodel. The KerML abstract and concrete syntax have been updated consistent with the resolutions of the following KerML FTF issues. Changes affecting user models are described under "Backward Incompatibilities" above.

   • KERML_-37 Add derived property for targetFeature
   • KERML_-67 Invocation of a non-functional behavior
   • KERML_-73 Disallow public imports at root level
   • KERML_-74 Make imports private by default

   The resolution of the following issue from KerML FTF2 Ballot 1 was already consistent with previous implementation:

   • KERML_-75 Restrict the functionality of recursive import

   [PR #582]

2. KerML Model Libraries. The reflective abstract syntax model KerML in the Kernel Semantic Library has been updated consistent with the resolution of the following KerML FTF issue. In addition, an explicit public keyword has been added to all public imports in the textual notation for all models in the Kernel Model Libraries, consistent with the resolution to issue KERML_-74.

   • KERML_-65 isOrdered and isUnique are missing from the reflective abstract syntax binding

   [PR #582]

SysML

3. SysML Metamodel. The SysML abstract and concrete syntax have been updated consistent with the resolutions to the following SysML v2 FTF issues. Changes affecting user models are described under "Backward Incompatibilities" above.

   • SYSML2_-183 checkStateUsageExclusiveStateSpecialization and checkStateUsageSubstateSpecialization have problems
   • SYSML2_-187 There is no need for AnalysisAction [also affects the model library]
   • SYSML2_-207 Update language description and concrete syntax related to imports

   [PR #582] [PR #583]

4. SysML Model Libraries. The models States, AnalysisActions and SysML in the Systems Model Library have been updated consistent with the resolutions to the following SysML v2 FTF issues. In addition, an explicit public keyword has been added to all public imports in the textual notation for all models in the Systems Model Library and Domain Model Libraries, consistent with the resolution to issue SYSML2_-207.

   • SYSML2_-184 StateAction::substates has an implied subsetting of exclusiveStates
   • SYSML2_-187 There is no need for AnalysisAction [also affects the abstract syntax]
   • SYSML2_-209 isOrdered and isUnique are missing from the reflective abstract mapping

   [PR #582] [PR #583]

Jupyter

None.

Visualization (PlantUML)

1. Multiplicities in nodes. Rendering of multiplicities inside node symbols is now supported, in addition to rendering multiplicities on edges. Three new style options have been added:

   • NODEMULTIPLICITY – Show multiplicities in nodes. (This is the default for the TREE view.)
   • EDGEMULTIPLICITY – Show multiplicities on edges.
   • IMPLICITMULTIPLICITY – Show implicit multiplicities as well. (Even if multiplicity is not specified explicitly for a feature, the visualizer renders the default or inherited multiplicity.)

   [PR #584]

2. Bug fixes. See below.

Technical Updates

None.

Bug Fixes

1. Inherited features of non-standard libraries (PlantUML). Fixes a bug (introduced in PR #556) that caused inherited features of non-standard libraries to be wrongly hidden.

   [PR #573]

2. Nested inherited features on a connection (PlantUML). Properly renders nested features referenced by connections.

   [PR #574]

3. Inherited features (PlantUML). Fixes a bug (introduced in PR #561) that caused memberships of inherited features to be incorrectly rendered. Also corrects the rendering of subsettings of inherited features.

   [PR #577]

2024-05 - SysML v2 Pilot Implementation

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

New Features

None.

Backward Incompatibilities

None.

Issue Resolutions

None.

Jupyter

None.

Visualization (PlantUML)

Bug fixes.

Technical Updates

1. Parse post-processing. Handwritten code implementing various Xtext parsing workarounds has been moved out of the generated Impl classes into postProcess methods in the corresponding adapter classes.
   [PR #570]

2. Jupyter kernel build. The Maven build configuration has been updated to remove the use of Gradle for building the Jupyter kernel.
   [PR #568]

Bug Fixes

1. Actor and stakeholder properties. Corrects the derivation computation for actor and stakeholder properties.
   [PR #569]
2. Flow connection rendering (PlantUML). Corrects the rendering of certain flow connections when an action model includes a start action.
   [PR #566]
3. Succession rendering (PlantUML). Fixes the rendering of successions declared using the "shorthand" textual notation.
   [PR #567]

2024-04.1 - SysML v2 Pilot Implementation

This release is the same as the 2024-04 release, except for one additional bug fix. It corresponds to Eclipse plugin version 0.41.1.

The release notes for 2024-04 are repeated below for convenience, along with the additional bug fix at the end.

New Features

None.

Backward Incompatibilities

None.

Issue Resolutions

None.

Jupyter

1. JupyterLab version. The JupyterLab deployment now installs JupyterLab 3.x (formerly 2.x) and Node.js 16.x (formerly 14.x on Windows and 15.x on Mac and Unix).
   [PR #564]

Visualization (PlantUML)

Bug fixes.

Technical Updates

1. Eclipse version. The supported Eclipse version has been updated to 2024-03 and all projects are now compiled using Java 17. Earlier versions of Eclipse are no longer supported.
   [PR #563]

2. Derived state computer. The implementation no longer uses the Xtext "derived state computer" mechanism. As a result, KerML and SysML files now open without significant delay in the Eclipse editor. (Note, however, that this change does not improve the performance of subsequent name resolution performed while editing a file, which is essentially the same as before.)
   [PR #562]

Bug Fixes

1. Feature chain rendering (PlantUML). Corrects the rendering of chains of features that do not belong to the chaining feature.
   [PR #558]
2. Visualization crash (PlantUML). Fixes a bug that could cause PlantUML visualization to crash.
   [PR #559]
3. Variation definition rendering (PlantUML). Fixes the rendering of variation definitions.
   [PR #560]
4. Redefinition rendering (PlantUML). Corrects the rendering of certain redefinitions.
   [PR #561]
5. Instantiation exception. Fixes a bug that causes an exception when a view usage with an expose relationship is published (or rendered) in Jupyter.
   [PR #565]

2024-04 - SysML v2 Pilot Implementation

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

New Features

None.

Backward Incompatibilities

None.

Issue Resolutions

None.

Jupyter

1. JupyterLab version. The JupyterLab deployment now installs JupyterLab 3.x (formerly 2.x) and Node.js 16.x (formerly 14.x on Windows and 15.x on Mac and Unix).
   [PR #564]

Visualization (PlantUML)

Bug fixes.

Technical Updates

1. Eclipse version. The supported Eclipse version has been updated to 2024-03 and all projects are now compiled using Java 17. Earlier versions of Eclipse are no longer supported.
   [PR #563]

2. Derived state computer. The implementation no longer uses the Xtext "derived state computer" mechanism. As a result, KerML and SysML files now open without significant delay in the Eclipse editor. (Note, however, that this change does not improve the performance of subsequent name resolution performed while editing a file, which is essentially the same as before.)
   [PR #562]

Bug Fixes

1. Feature chain rendering (PlantUML). Corrects the rendering of chains of features that do not belong to the chaining feature.
   [PR #558]
2. Visualization crash (PlantUML). Fixes a bug that could cause PlantUML visualization to crash.
   [PR #559]
3. Variation definition rendering (PlantUML). Fixes the rendering of variation definitions.
   [PR #560]
4. Redefinition rendering (PlantUML). Corrects the rendering of certain redefinitions.
   [PR #561]

2024-03 - SysML v2 Pilot Implementation

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

New Features

None.

Backward Incompatibilities

None.

Issue Resolutions

None.

Jupyter

Bug fixes.

Visualization (PlantUML)

Bug fixes.

Technical Updates

1. Metamodel operations. The implementation of all OCL operations from the metamodel specifications has been moved from in-line method code in metamodel Impl classes into separate delegate classes, using the Eclipse "invocation delegate" mechanism.
   [PR #554] [PR #555]

2. Maven build. The Maven build was updated to resolve a problem introduced by a newly released version of a plugin used by the tycho-build extension.
   [PR #550 ]

Bug Fixes

1. Standard library element rendering (PlantUML). Corrects the rendering of standard library elements in compartments when SHOWLIB and SHOWINHERITED styles are not used.
   [PR #548]
2. Bindings with standard library metadata (Jupyter). Fixes a bug introduced in the 2024-02 release that caused bindings of enumeration features of metadata usages of metadata definitions from library models to spuriously cause warnings in the Jupyter environment (but not in Eclipse).
   [PR #551]
3. Resolution of results, subjects and objectives. Fixes a bug that caused the incorrect resolution of names of result parameters, subject parameters and objectives that were physically inserted into the abstract syntax tree after parsing.
   [PR #552]
4. Implicit subsetting of occurrenceUsages. Fixes the implementation of the implicit subsetting of occurrenceUsages that are suboccurrences.
   [PR #553]
5. %viz command (PlantUML, Jupyter). Fixes a bug caused by the changes in PR #552 in which the %viz command in the Jupyter environment would sometimes throw a ConcurrentModificationException.
   [PR #557]