Skip to content

2025-02 - SysML v2 Pilot Implementation

Latest
Latest
Compare
Choose a tag to compare
@seidewitz seidewitz released this 03 Apr 16:03
· 29 commits to master since this release
2025-02
83c0a0d

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 Semantic Library
    • Removed all uses of the keyword readonly.
      [PR #637]
    • Occurrences
      • Added transitivity that was missing for some space/time associations.
        [PR #625]
      • Added semantics for single ownership via composition.
        [PR #627]
      • Added a default value of self to portionOfLife.
        [PR #637]
    • Clocks
      • Added var to the declarations of Clock::currentTime and BasicClock::currentTime.
        [PR #637]
    • Performances
      • Added constructorEvaluations as the base feature of all ConstructorExpressions.
        [PR #638]
    • Transfers
      • Changed type of Transfer::source::sourceOutput and Transfer::target::targetInput from Occurrence to Anything.
      • Changed the names of Transfer::item, SendPerformance::sentItem and AcceptPerformance::acceptedItem to payload.
        [PR #639]
    • Triggers
      • Used the new constructor syntax to construct the result values for TriggerWhen and TriggerAt.
        [PR #638]
  3. Systems Library
    • FlowConnections
      • Renamed to Flows, with all base types in it renamed to remove Connections` from their names.
        [PR #639]
    • Actions
      • Replaced use of FlowConnections::MessageConnection with Flows::MessageAction.
        [PR #639]
  4. Analysis Domain Library
    • SampleFunctions
      • Used the new constructor syntax to construct the result value for the calculation definition Sample.
        [PR #638]
    • TradeStudies
      • Renamed the parameter TradeStudyObjective::fn to eval to avoid a name conflict.
        [PR #630]
  5. Geometry Domain Library
    • ShapeItems
      • Made the radius feature on several kinds of shapes redefinable by moving their declaration bindings to the features they were bound to.
        [PR #628]
  6. Metadata Domain Library
    • RiskMetadata
      • Used the new constructor syntax to construct the enumerated values of the enumeration definition RiskLevel.
        [PR #638]
  7. Quantities and Units Library
    • All ISQ domain packages have been regenerated.
      [PR #621]
    • MeasurementReferences
      • Used the new constructor syntax to construct the value of the attribute usage one.
        [PR #638]

Backward Incompatibilities

  1. Reserved words.
    • KerML – Added: var const Removed: readonly
    • SysML – Added: constant Removed: readonly
  2. End types. End features of associations in KerML and connection definitions in SysML are now restricted to having only a single type.
    [PR #618]
  3. End features. An end feature can now only be redefined by another end feature.
    [PR #631]
  4. derived keyword. The derived keyword must now come immediately after any direction keyword and before abstract or any other prefix keyword.
    [PR #637]
  5. Invocation expressions. It is no longer valid for an invocation expression to have a target that is not a behavior/function or step/expression (as was previously allowed for constructing instances).
    [PR #638]
  6. Flows. The renaming of the Systems Library model 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.
    [PR #639]
  7. Time slices and snapshots. Declaring a "standalone" time slice or snapshot not nested in an occurrence definition or usage is no longer supported.
    [PR #640]

Issue Resolutions

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

KerML

The resolution for the following issue was approvedoin KerML FTF2 Ballot 2. (This resolution should have been implemented in the 2024-12 release, but it was missed.)

  • KERML_-32 Association ends can have more than one type

Resolutions for the following issues were approved on KerML FTF2 Ballots 5 and 6.

  • KERML_-1 isEnd of the redefining feature must match isEnd of the redefined feature
  • KERML_-5 isComposite, semantics?
  • KERML_-36 KerML Libraries' elements shall have an elementId defined
  • KERML_-57 Time and space life/slice/portion modeling patterns are missing
  • KERML_-58 checkFeatureParameterRedefinition fails for named-argument invocations
  • KERML_-101 Global scope notation
  • KERML_-104 Transitivity missing for some time/space associations
  • KERML_-107 The term "Item" in KerML confusing against SysML
  • KERML_-132 Constructor invocation expressions are semantically inconsistent
  • KERML_-151 Corrections to the resolution of KERML_-39
  • KERML_-222 validateParameterMembershipOwningType will fail for ConstructorExpressions

Resolutions for the following issues had already been previously implemented:

  • KERML_-59 OCL for checkFeatureParameterRedefinition is wrong
  • KERML_-146 Need to revise derivation of AnnotatingElement::ownedAnnotatingRelationship
  • KERML_-220 Corrections to the resolution of KERML_-18

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.)

  • SYSML2_-159 Textual notation for send actions is too limited
  • SYSML2_-394 deriveItemUsageItemDefinition is incorrect

Resolutions for the following issues were approved on SysML v2 FTF2 Ballots 7 and 8.

  • SYSML2_-32 Resolve "TODO" in domain library model Time
  • SYSML2_-107 SysML Libraries' elements shall have an elementId defined
  • SYSML2_-158 timeslice/snapshot featuring types required to specialize or be same as types
  • SYSML2_-248 Evaluation problem with TradeStudyObjectives
  • SYSML2_-417 Remove "Connection" from the names "FlowConnectionDefinition", "FlowConnectionUsage", and "SuccessionFlowConnectionUsage"
  • SYSML2_-471 Unredefinable shape attributes
  • SYSML2_-510 Variable features for SysML
  • SYSML2_-766 Constructor expressions in SysML

The resolution for the following issue had already been previously implemented:

  • SYSML2_-515 Corrections to operation and constraints from previous resolutions

Jupyter

None.

Visualization (PlantUML)

None.

Technical Updates

Note. 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.

  1. Quantities library generator. A new tool has been added under tool-support that generates the Quantities and Units Domain Library ISQ models.
    [PR #621]
  2. Library element IDs. The algorithm for generating UUIDs for standard library model elments has been changed to use the new concept of element paths instead of qualified names. Every element has a path, whether the element is named or not, and each path is unique within the composition structure under a specific root namespace.This allows a distinct UUID to be generated for every element in a standard library model, not just the ones with non-null qualified name. For elements with non-null qualified names, though, the path is just the qualified name, so the generated UUID is the same as previously in this case.
    [PR #636]

Bug Fixes

  1. Result expressions. Corrects the validation of ResultExpressionMemberships in Functions and Expressions.
    [PR #617]
  2. Trade studies. Renames the parameter TradeStudyObjective::fn to eval to avoid a name conflict.
    [PR #630]
Assets 4
Loading