This is an incremental update to the 2025-06 release. It corresponds to Eclipse plugin version 0.51.0.
Language FeaturesBug fixes.
Model LibrariesKernel Semantic Library
Name collisions. The following models were updated to avoid name collisions due to diamond inheritance:
FeatureReferencingPerformancesObjectsObservationOccurrencesTransfers[PR #679]
Transfers. The features transfers and messageTransfers are now steps instead of flows. As a result, these features no longer have spurious implied subsettings of flowTransfers.
[PR #682]
Transition performances. In the TransitionPerformance model, in TransitionPerformance::accept, the nested redefinition of receive was removed and replaced with a binding connector. This allows the receive parameter of the accepter in a SysML TransitionUsage to be redefined and bound.
[PR #683]
Kernel Function Library
VectorFunctions model was updated to avoid name collisions due to diamond inheritance.Systems Library
Trade studies. The TradeStudies model for TradeStudyObjectives has been updated to avoid validation errors when the objective of a TradeStudy is redefined as intended, to give it a concrete type such as MinimizeObjective or MaximizeObjective.
[PR #676]
Name collisions. The following models were updated to avoid name collisions due to diamond inheritance:
ActionsConnectionsFlowsItemsMetadataPartsPortsSysMLViews[PR #679]
Flows. The flow definition Message and the flow usage messages no longer have owned end features. As a result, messages no longer has a spurious implied subsetting of flows.
[PR #682]
Assignments. In the Actions model, in Action::assignments, a nested owned parameter target was added. This ensures that the parameters redefined by an ActionUsage are target and replacementValues, in that order.
[PR #683]
Geometry Domain Library
Name collisions. The following models were updated to avoid name collisions due to diamond inheritance:
ShapeItemsSpatialItems[PR #679]
Quantities and Units Domain Library
SIUSCustomaryUnitsRequirement Derivation Domain Library
DerivationConnections model was updated to avoid name collisions due to diamond inheritance.Subjects and objectives. Previously, if a requirement definition/usage or case definition/usage was parsed without an owned subject and/or objective, then a subject or objective element was physically inserted into the parse tree by the relevant adapter. Starting with this release, these insertions are no longer being done, which is more conformant with the SysML specification. However, the previous insertion of subjects meant that the validation checks for the subject being the first parameter were satisfied even if the subject was not declared explicitly and there were additional parameters. This is no longer necessarily the case.
For example, the following requirement definition would previously have not produced an error, but now results in a "Subject must be first parameter" validation error.
requirement def R {
// Error: Subject must be first parameter.
in x;
}
In particular, stakeholders and actors are kinds of parameters, so a subject must always be explicitly declared if stakeholders and/or actors are also declared.
concern c {
subject; // Required to avoid error.
stakeholder s;
}
use case uc {
subject; // Required to avoid error.
actor a;
}
Note that this is the case even when specializing a supertype with an inheritable subject:
use case uc1 {
subject subj;
}
use case uc2 :> uc1 {
subject subj; // Implied redefinition of uc1::subj.
actor a;
}
use case uc3 :> uc, uc1 {
subject; // Required to avoid "Only one subject is allowed" error.
}
[PR #677]
Validation. Existing models may now get distinguishibility warnings that were not previously generated. For example, the following model previously did not cause a warning, but now it does as indicated.
part def Vehicle {
part wheels [2..*] : Wheel;
}
part def Car :> Vehicle {
part :>> wheels [3..4];
}
part def Truck :> Vehicle {
part :>> wheels [4..18];
}
part def SUV :> Car, Truck; // Warning: Duplicate of inherited member name 'wheel'
The warning can be removed by redefining both Vehicle::wheels and Truck::wheels within SUV:
part def SUV :> Car, Truck {
part :>> Car::wheels, Truck::wheels;
}
[PR #679]
Spatial items. The item definition SpatialItems::SpatialItem from the Geometry Model Library redefines the feature localClock so that it is typed by Time::Clock from the Quantities and Units Domain Library. However, localClock is also redefined in Occurrences::Occurrence::suboccurrences, which is indirectly specialized by Items::Item::subitems. As a result, declaring a subitem that is a SpatialItem within another SpatialItem now results in a warning.
item def SpacialItemWithSubitem :> SpatialItem {
// Warning: Duplicate of inherited name 'localClock' from SpatialItem, suboccurrences
item aSubItem : SpatialItem; // implied subsetting of subitems
}
In order to avoid having to further redefine localClock within every such subitem declaration, additional features have been added to SpatialItem:
subSpatialItems – Subset this for subitems that are SpatialItems.subSpatialParts – Subset this for subparts that are SpatialItems.componentParts – Subset this for component items that are parts (instead of subsetting componentItems).item def SpacialItemWithSubSpacialItems :> SpatialItem {
item aSubSpaitalItem :> subSpatialItem;
part aSubSpaitalPart :> subSpatialPart;
}
item def SpacitalItemWithComponents :> SpatialItem {
item aComponentItem :> componentItems; // Per specification
part aComponentPart :> componentParts;
}
[PR #679]
Messages. The end features source and target of Mssages::Message and Messages::messages are now inherited and are no longer occurrence usages. This means that they cannot be used as the referenced occurrences in an event occurrence usage. However, this is appropriate, because the referenced events for a message should instead be sourceEvent and targetEvent which are still occurrence usages.
[PR #682]
Binary connectors/connections. Correction of the validateConnectorBinarySpecialization check may result both in cases in which a previously valid connector/connection declaration becomes invalid or a previously invalid declaration becomes valid.
[PR #682]
The KerML 1.1 ans SysML 2.1 RTFs have not yet approved any issue resolutions. However, this release includes proactive resolutions to the following issues to correct library models, largely to avoid validation errors that have now been identified due to corrections in validation checking.
KerML
SysML
None.
Visualization (PlantUML)None.
Technical UpdatesNone.
Bug FixesMembership::isDistinguishableFrom operation.validateConnectorBinarySpecialization to properly handle redefined features when counting connector ends.This is an incremental update to the 2025-04 release. It corresponds to Eclipse plugin version 0.50.0.
Language FeaturesBug fixes.
Model LibrariesBug fixes.
Backward IncompatibilitiesNone.
Issue ResolutionsNone.
JupyterNone.
Visualization (PlantUML)Bug fix.
Technical Updates.gitignore files. Updated .gitignore files in xtend-gen folders..uml and .ecore metamodel files to be consistent with the normative Beta 4 abstract syntax.isCompatibleWith operation. Corrected a non-conformance of the Pilot Implementation with the KerML Specification on the computation of the Feature::isCompatibleWith operation.canAccess operation. Fixed a bug in the implementation of FeatureUtil.canAccess for checking accessibility when the subsetting feature has no featuring types.Occurrences and the SysML Analysis Domain Library model TradeStudies.isConstant for end usages and isAbstract for variation definitions and usages.States::State::substates to inherit two this features (resulting in any state usage that is a substate also inheriting them).This is an incremental update to the 2025-02 release. It corresponds to Eclipse plugin version 0.49.0.
Language FeaturesControl node bodies. In the SysML abstract syntax, control nodes (i.e., fork, join, decide and merge nodes) are kinds of action usages that are typed by ControlActions from the Systems Model Library. The abstract syntax allows control nodes to have any sort of owned members that other kinds of action usages can. However, the textual notation syntax previously allowed only annotations to be declared in the body of a control node. This has now been corrected to allow control nodes to have regular action bodies.
In particular, with this change, it is possible to declare control nodes with parameters, enabling the modeling of flows through them. For example:
action def A {
action a1 {
out x1;
}
then j1;
action a2 {
out x2;
}
then j1;
flow a1.x1 to j1.x1;
flow a2.x2 to j1.x2;
join j1 {
in x1;
in x2;
out y = (x1, x2);
}
then a3;
flow j1.y to a3.y;
action a3 {
in y;
}
}
Note that it is still necessary to have successions (or succession flows) into and out of control nodes in order to get the proper "control" semantics.
[PR #642]
Constructor expression evaluation. The model-level evaluation of a constructor expression has been implemented to simply return the result parameter of the expression. This works, because a constructor expression is parsed as an expression whose instantiated type is instantiated by its result parameter, with argument expressions bound to appropriate features of the instantiatedType.
For example, given the following:
part def P {
attribute a;
attribute b;
}
part p = new P(1,2);
attribute p_a = p.a;
attribute p_b = p.b;
the feature p evaluates to the result parameter of the constructor expression, which is a usage of P with its attributes bound to the argument expressions. Therefore, p_a evaluates to the literal integer 1 and p_b evaluates to the literal integer 2.
[PR #645]
None.
Backward IncompatibilitiesNone.
Issue ResolutionsThis release includes implementation of resolutions to the issues listed below.
KerML
The resolution for the following issues was approved on KerML FTF2 Ballot 7. It was previously implemented, except for the model-level evaluation of constructor expressions.
SysML
The resolution for the following issue was approved on SysML v2 FTF2 Ballot 7. (This resolution should have been implemented in the 2025-02 release, but it was missed.)
The resolution for the following issue, approved on SysML v2 FTF2 Ballots 9, had already been previously implemented.
%projects command. The magic command %projects has been added to list the name and identifier of all projects in the repository.
[PR #616]
%load command. The magic command %load has been added to load models from a project in the repository.
%load [--id=<PROJECT ID>] [--name=<NAME>] [--branchid=<BRANCH ID>] [--branch=<BRANCH_NAME>] [<NAME>]
Download previously published models from a project in the repository. (Use %projects to view repository contents.)
Named elements of the downloaded models may then be referenced by models in the notebook.
<NAME> is the full name of the project.
If <PROJECT ID> is given, then the project with that UUID is loaded. In this case, the <NAME> must not be given.
If <BRANCH NAME> or <BRANCH ID> is given, then the model is loaded from this branch of the project.
If no <BRANCH NAME> or <BRANCH ID> is given, the default branch is used.
If <BRANCH ID> is given, then a <BRANCH NAME> must not be given.
[PR #616]
%publish command. Previously, the %publish command in Jupyter always created a new project on the API server, posting all elements of a model in the one and only commit on the "main" branch. The command has been updated to post incremental changes based to a specified project based on the delta between the remotely stored models and their local models. (Currently this usually means that the new commit completely replaces the content of the model – since re-parsing a model in Jupyter creates entirely new element UUIDs – but it is at least possible to publish multiple versions of a model in multiple commits to a single project in the repository.)
Note. Previously, a model was published by default including values for all derived properties. The default is now to publish without derived property values (which greatly reduces the size of the published model). To include derived property values, use the -d option.
%publish [-d] [--project=<PROJECT NAME>] [--branch=<BRANCH NAME>] <NAME>
Publish the model elements rooted in <NAME> to the repository. <NAME> must be fully qualified.
Use the -d flag to include derived properties.
If <PROJECT NAME> is given, it is used as the name of the project to create or update.
If <PROJECT NAME> is not given, the (simple) name of the model element is used.
If no project exits with the given name, then a new project with that name is created.
Otherwise, the existing project is updated with a new commit.
If <BRANCH NAME> is given, then the model is written to this branch of the project.
If <BRANCH NAME> is not given, the default branch is used.
[PR #633]
%repo command. The magic command %repo has been added to allow the repository API base path to be changed.
%repo [<BASE PATH>]
Set the API base path for the repository accessed by the %projects, %publish and %load commands.
<BASE PATH> is a URL (possibly including port number), such as: https://my.domain.com/sysml_repo:9000.
If <BASE PATH> is not given, the current repository base path is printed.
If <BASE PATH> is given, the repository base path is set to this.
[PR #644]
SysMLv2 menu. A SysMLv2 submenu has been added to the popup menu for projects, with the following options:
Generate Library Index: Moved under SysMLv2 menu.Pull model from API: Download models from a repository and save in .sysmlx files. This requires that .settings/org.omg.sysml.remote.properties exists with the following contents:
base.url=repository url
remote.projectId=project id
remote.branchId=branch id
remote.branchId is optional; if not provided, the default branch is used)[PR #616]
Jupyter magic commands. The implementation of magic commands for Jupyter has been extended to allow external users to define and register additional commands that can reuse the state of the Jupyter kernel without needing to recompile the existing codebase.
[PR #649]
Continuous integration builds. The running of continuous integration builds has been switched from Travis CI to GitHub Actions.
[PR #650]
new keyword. Fixes highlighting of the new keyword in Jupyter.«variant». Removes the rendering of «variant» for an enumeration definition in PlantUML.isCompatibleWith. Adds a Boolean return type to the Feature::isCompatibleWith operation.This is an incremental update to the 2024-12 release. It corresponds to Eclipse plugin version 0.48.0.
Language FeaturesKerML
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]
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]
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]
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
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]
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]
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:
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]
Constructor expressions. Constructor expressions (see description above under KerML) can also be used in SysML.
[PR #638]
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]
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]
.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.)This is an incremental update to the 2024-11 release. It corresponds to Eclipse plugin version 0.47.0.
New FeaturesKerML
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
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;
}
connection def AssetOwnership {
end [1..*] part owner : LegalEntity;
end [*] ordered part ownedAsset : Asset;
}
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;
}
1..1, even for kinds of usages that would otherwise not have that default if they were not 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;
}
crossesownedParts 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.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).IndexExpression metaclass in the abstract syntax. This has no affect on end-user models.This release includes implementation of resolutions to the issues listed below.
KerML
Resolut...
Read more 2024-11 - SysML v2 Pilot ImplementationThis 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 FeaturesTerminate 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]
terminateSysML 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]
None.
Visualization (PlantUML)Bug fix.
Technical UpdatesCaching. Added clearing of the cached effectiveName and effectiveShortName of elements.
[PR #595]
Port conjugation. Fixes the setting of the source and conjugatedType fields of a PortConjugation.
[PR #596]
Transition usage. Fixes the parsing of the source of a transition usage when it is a feature chain.
[PR #600]
Transition usage rendering (PlantUML). Fixes the rendering of transition usages to resolve its succession end features correctly.
[PR #601}
Binding connections. Fixes the implicit subsetting of binding connections as usages in SysML models.
[PR #603]
This is an incremental update to the 2024-08 release. It corresponds to Eclipse plugin version 0.45.0.
New FeaturesNone.
Backward IncompatibilitiesNone.
Issue ResolutionsNone.
JupyterNone.
Visualization (PlantUML)Metadata. Metadata is now rendered in a compartments if it is owned by an element that is rendered with compartments.
[PR #592]
Peformance. The performance of certain validation and transformation computations has been significantly improved by revising the computation of inherited memberships
[PR #594]
Index file encoding. Updates generation of the library index to always use UTF-8 encoding.
[PR #593]
This is an incremental update to the 2024-07 release. It corresponds to Eclipse plugin version 0.44.0.
New FeaturesNone.
Backward IncompatibilitiesImport 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]
KerML Metamodel. The resolution of the following issue is now fully implemented.
[PR #589]
SysML Metamodel. The resolution of the following issue is now fully implemented.
[PR #589]
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]
None.
Technical UpdatesLibrary Index.
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.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]
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]
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 FeaturesNone.
Backward IncompatibilitiesImport visibility.
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.private. (This prevents the "re-export" of names imported into a root namespace directly back into the global scope, which simplifies global name resolution.)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]
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]
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]
KerML
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.
The resolution of the following issue from KerML FTF2 Ballot 1 was already consistent with previous implementation:
[PR #582]
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.
[PR #582]
SysML
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.
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.
None.
Visualization (PlantUML)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]
Bug fixes. See below.
None.
Bug FixesInherited 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]
Nested inherited features on a connection (PlantUML). Properly renders nested features referenced by connections.
[PR #574]
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]
This is an incremental update to the 2024-04.1 release. It corresponds to Eclipse plugin version 0.42.0.
New FeaturesNone.
Backward IncompatibilitiesNone.
Issue ResolutionsNone.
JupyterNone.
Visualization (PlantUML)Bug fixes.
Technical UpdatesParse 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]
Jupyter kernel build. The Maven build configuration has been updated to remove the use of Gradle for building the Jupyter kernel.
[PR #568]
Actor and stakeholder properties. Corrects the derivation computation for actor and stakeholder properties.start action.RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4