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.)readonly.Occurrences
Clocks
var to the declarations of Clock::currentTime and BasicClock::currentTime.Performances
constructorEvaluations as the base feature of all ConstructorExpressions.Transfers
Transfer::source::sourceOutput and Transfer::target::targetInput from Occurrence to Anything.Transfer::item, SendPerformance::sentItem and AcceptPerformance::acceptedItem to payload.Triggers
TriggerWhen and TriggerAt.ShapeItems
radius feature on several kinds of shapes redefinable by moving their declaration bindings to the features they were bound to.RiskMetadata
RiskLevel.var const Removed: readonlyconstant Removed: readonlyderived keyword. The derived keyword must now come immediately after any direction keyword and before abstract or any other prefix keyword.FlowConnections to Flows, along with the renaming of base types within it, does not effect the surface syntax for flows, but will effect any explicit references to that package and its elements.This release includes implementation of resolutions to the issues listed below.
KerML
The resolution for the following issue was approved on KerML FTF2 Ballot 2. (This resolution should have been implemented in the 2024-12 release, but it was missed.)
Resolutions for the following issues were approved on KerML FTF2 Ballots 5 and 6.
Resolutions for the following issues had already been previously implemented:
SysML
Resolutions for the following issues were approved on SysML v2 FTF2 Ballot 5. (These resolutions should have been implemented in the 2024-12 release, but they were missed.)
Resolutions for the following issues were approved on SysML v2 FTF2 Ballots 7 and 8.
The resolution for the following issue had already been previously implemented:
None.
Visualization (PlantUML)None.
Technical UpdatesNote. Regenerating the SysML parser from the SysML.xtext grammar now requires at least 10G of heap space. This needs to be set as a VM option on the launch configuration Generate SysML (sysml) Language Infrastructure: -Xmx10g.
tool-support that generates the Quantities and Units Domain Library ISQ models.ResultExpressionMemberships in Functions and Expressions.TradeStudyObjective::fn to eval to avoid a name conflict.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