Skip to content

Releases: Systems-Modeling/SysML-v2-Pilot-Implementation

2022-11 - SysML v2 Pilot Implementation

20 Jan 07:21
@seidewitz seidewitz
2022-11
8e58963
Compare
Choose a tag to compare
2022-11 - SysML v2 Pilot Implementation

This is an incremental update to the 2022-10 release. It corresponds to Eclipse plugin version 0.30.0.

Language Features

  1. Membership and namespace import. The abstract syntax for Import has been revised so that it is now abstract with two concrete subclasses, MembershipImport and NamespaceImport. The textual and graphical notations are unchanged, but their parsing is different.

    • An import declaration of the form importqualifiedName; now parses to a MembershipImport with its importedMembership given by the resolution of the qualifiedName. If the qualifiedName is suffixed by ::**, then isRecursive = true.
    • An import declaration of the form importqualifiedName::*; now parses to a NamespaceImport with its importedNamespace given by the resolution of the qualifiedName. If ::** is also added, then isRecursive = true.

    [PR #426]

  2. Membership and namespace expose. In the SysML abstract syntax, Expose is a kind of Import. Parallel to the abstract syntax change for Import, Expose is now abstract with two concrete subclasses MembershipExpose and NamespaceExpose. ViewUsage has also been updated to replace the exposedNamespace and viewedElement properties with a single exposedElement. As a result of these changes, it is now possible for a ViewUsage to have MembershipExpose relationships to the Memberships for individual elements, even if those elements are not named.
    [PR #426]

Model Libraries

  1. KerML and SysML. The reflective syntax models KerML and SysML have been updated to reflect the changes in the abstract syntax for Import and Expose.
    [PR #426]
  2. Interchange data. .project and .meta files have been added to each of the model library directories in the sysml.library project, conformant with the format required in subclause 10.2 of the latest KerML Specification. As a result, compressing each of these directories into a ZIP archive results in a legal project interchange (.kpar) file, having model interchange files using the textual notation (.sysml).
    [PR #437]

Backward Incompatibilities

There are no changes to the concrete syntax, so all existing valid models will continue to be valid. However, the abstract syntax for Import and Expose relationships has changed, so import and expose declarations will parse differently than before, as described above.

Jupyter

None.

Visualization

  1. PlantUML
    See bug fixes
  2. Tom Sawyer
    None.

Technical Updates

  1. Eclipse version. The minimum required version for Eclipse installation has been updated to 2022-09.
    [PR #425]

  2. JSON schema. The following JSON Schema files have been added to the org.omg.sysml project under a new json-schema directory:

    • KerML.json – KerML abstract syntax (also to be used for API payload validation)
    • SysML.json – SysML abstract syntax (also to be used for API payload validation)
    • ModelInterchange.json – Interchange project information (.project) and interchange project file metadata (.meta)

    [PR #433]

Bug Fixes

  1. RequirementDerivation. Corrected the baseTypes for OriginalRequirementMetadata to originalRequirements and DerivedRequirementMetadata to derivedRequirements. These had been switched.
    [PR #432]
  2. Feature chain evaluation. Corrected the evaluation of feature chains with intermediate features that are redefined.
    [PR #435]
  3. Rendering of subjects (PlantUML). Rendered requirement and case subjects as distinct nodes in order to render subjects with bindings or subsettings.
    [PR #428]
  4. Start/done and entry/exit action rendering (PlantUML). Properly rendered start and done in actions and entry and exit actions in states.
    [PR #429]
  5. Variant visualization (PlantUML). Revised visualization of variants to align with specification.
    [PR #431]
  6. Short name rendering (PlantUML). Fixed an er...
Read more
Loading

2022-10 - SysML v2 Pilot Implementation

10 Nov 17:20
@seidewitz seidewitz
2022-10
ab0a3b7
Compare
Choose a tag to compare
2022-10 - SysML v2 Pilot Implementation

This is an incremental update to the 2022-09 release. It corresponds to Eclipse plugin version 0.29.0.

Language Features

  1. User-defined keywords.
    • User-defined keyword notation (#keyword) is now available in KerML.
    • In both KerML and SysML, multiple user-defined keywords can now be used in a single declaration.
  2. Binding connectors and successions. In KerML only, it is now possible to declare the ends of a binding connector or succession using end feature declarations in the connector body, rather than using the special notation ... = ... or first ... then ....
  3. Cast operators. The parsing of the cast operators as and meta has been changed to make the target type directly the type of the result parameter of the operator expression. (This is a backward compatible change.)
  4. Flow payloads. Previously, the textual notation only allowed limited declaration of the name and type of the payload feature (of...) of an item flow (in KerML) or a flow connection usage (in SysML). Now, payload features can have full declarations, including subsetting and redefinition specializations and feature value bindings. This is useful for modeling e.g., a message in SysML with a specific value for its payload. 
    message of fuelCommand : FuelCommand = engineController.engineControlPort.incomingFuelCommand
    from engineController to engine;

[PR #420]

Model Libraries

  1. BaseFunctions. The functions in the Kernel Semantic Library package BaseFunctions corresponding to the cast operators have been updated consistent with the change noted above.
    [PR #420]
  2. Connections. See Bug Fixes below.

Backward Incompatibilities

None.

Jupyter

None

Visualization

  1. PlantUML

    • Updated PlantUML to 1.2022.7.
      Important Note: To work with this release, existing Eclipse installations will need to have their PlantUML installation updated from the update site https://https://github.com/himi/p2-update-puml-sysmlv2/raw/main/updates.
    • Updated compartment title style to be centered and italic.

    [PR #419]

  2. Tom Sawyer
    None.

Technical Updates

There were a number of changes to clean up the abstract syntax, which should not effect user models.

  1. Implementation-specific metaclasses. The abstract syntax as implemented previously contained five metaclasses that were specific to the pilot implementation but not considered part of the normative abstract syntax model documented in the specifications. Two of these (ItemFeature and ItemFlowEnd) have now been made normative, while three others (ItemFlowFeature, SourceEnd and TargetEnd) have been removed, with the pilot implementation updated to not need them.
  2. Multiplicity lower bounds. Previously, the Feature::type property had a multiplicity lower bound of 1. This has now been changed to 0, as has the multiplicity lower bound for all properties that (directly or indirectly) subset this property. This allows models to be peristed and interchanged without explicit typing, with semanticly necessary types ultimately provided via implied relationships added by tooling.
  3. Ecore. Previously, during preprocessing of the exported MOF model, the property Feature::isNonunique was added to SysML.uml for use as an workaround in parsing the nonunique keyword. In addition, the OperatorExpressions::operand property was included in the abstract syntax model as an implementation workaround for parsing operator expressions. Now, these two features are added to SysML.ecore by the custom UML to Ecore converter and are not included in the SysML.uml model.

[PR #420]

Bug Fixes

  1. Flow connections. In the Systems Library model Connections, corrected MessageConnection to specialize Actions::Action and messageConnections to specialize Actions::actions.
    [PR #421]
Loading

2022-09 - SysML v2 Pilot Implementation

21 Oct 21:34
@seidewitz seidewitz
2022-09
9521de8
Compare
Choose a tag to compare
2022-09 - SysML v2 Pilot Implementation

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

Language Features

KerML and SysML

  1. Library packages. The keyword library can be used to identify a package as a library package, e.g., library packageDynamicsModelLibrary { ... }. Further prefixing a library package declaration with the keyword standard identifies it as a standard library package. However, standard should only be used to identify library packages that are part of the standard KerML and SysML model libraries (i.e., those in the sysml.library project in the pilot implementation), or other accepted standard model libraries in the future.
    [PR #416]

  2. Metadata access. A metadata access expression has the form elementName.metadata, where elementName is a qualified name for any kind of element. Such an expression evaluates to a sequence of instances of the reflective metaclass KerML::Metaclass representing the owned metadata feature annotations of the named element, in order. In addition, the last element of the sequence is always an instance of the reflective abstract syntax metaclass for the named element representing the instantiation of the element in the model.

    For example, given the model

    import RiskMetadata::*;
part def SystemDesign {
    metadata Risk {
        totalRisk = RiskLevelEnum::medium;
    }
}

    The expression SystemDesign.metadata evaluates to a sequence of two values, the first of which is an instance of the metadata definition RiskMetadata::Risk, and the second of which is an instance of SysML::PartDefinition. The following operators are convenient for operating on such sequences of metadata:

    • elementName@@Metaclass is a shorthand for elementName.metadata@Metaclass. It tests whether any of the metadata of the named element is a direct or indirect instance of Metaclass. For example, given the above sample model, the expressions SystemModel @@ Risk and SystemModel @@ SysML::Definition both evaluate to true.
    • elementNamemetaMetaclass is a shorthand for elementName.metadata asMetaclass. It filters the metadata of the named element for only those that are instances of Metaclass. This is useful for accessing the values of features of the metadata. For example, given the above sample model, (SystemDesignmetaRisk).totalRisk.probability evaluates to LevelEnum::medium and (SystemDesignmetaKerML::Element).name evaluates to "SystemDesign" (note that the parentheses are required, due to meta having the operator precedence of a binary operator).

    [PR #416]

  3. "Same" operator. The === operator checks if two occurrences are portions of the same life (i.e., have the same "identity"). The operator !== is the inverse of ===. For example, given the model

    part car {
   timeslice drivenByAlice;
   then timeslice drivenByBob;
}

    the expression car.drivenByAlice == car.drivenByBob evaluates to false, because the two timeslices are different occurrences, but car.drivenByAlice === car.drivenByBob evaluates to true, because the two timeslices are both portions of the life of the same car. For data values (i.e., non-occurrences), the === operator is the same as ==.

    Implementation Note: Expression evaluation in the pilot implementation currently does not implement the functionality of === and !== and simply treats them the same as == and !=.
    [PR #417]

SysML Only

  1. Conjugated port typing. While the notation for conjugated port typing has not changed, the way the conjugated port definition is resolved has changed. Previously, in a declaration such as portp : ~P;, the conjugated port typing was a relationship between the port usage p and the port definition P, with the actual conjugated port definition being derived as the one owned by P. Now, the conjugated port typing relationship is instead between the port usage and the actual conjugated port definition, which is found by resolving the constructed qualified name P::'~P'. The corresponding port definition P is now a derived property of the conjugated port typing, determined as the owning port definition of the conjugated port definition.
    [PR #416]

  2. Send action. Send action syntax has been extended to include a new via clause: sendpayloadviasendertoreceiver;. This allows for arguments for both the sender (via) and receiver (to) parameters of SendAction (see also the model library update description below). While having both via and to is allowed, it is expected that generally only one or the other will be used, with via being used to send "out" through a port (parallel to the use of via on an accept action for accept "in" through a port).
    [PRs #410, #416]

  3. Messages. The parsing of message declarations has changed. A declaration of the form message fromsourceEventtotargetEvent; still parses to a connection usage, but without connection ends. Instead, it redefines Transfer::sourceEvent and Transfer::targetEvent to reference the given sourceEvent and targetEvent , respectively (see also model library update description below). This allows such a message to be realized by either a message connection in which the sourceEvent is a send action and the targetEvent is an accept action, or a flow connection, such as between two ports, in which case the source and target ports are also the sourceEvent and targetEvent.
    [PR #410]

Model Libraries

General

  1. Library packages. All standard model library packages are now declared as standard library package.
    [PR #416]

  2. Reflection. The reflective abstract syntax models KerML and SysML now include all navigable properties from the normative MOF abstract syntax model as features of the corresponding metaclasses/metadata definitions.
    [PR #408]

Kernel Semantic Library

  1. Event handling. Updated the models Occurrences, Performances, Transfers, TransitionPerformances and StatePerformances to capture semantics related to event handling, including prioritized dispatch, accept matching and run-to-completion.
    [PR #410]

Kernel Functions Library

  1. Base and data functions.

    • Added the abstract function '===' to BaseFunctions, for use as the function invoked by the === operator. Added the function '!==' as the opposite of '===' and the function invoked by the !== operator.
    • Added a specialization of BaseFunctions::'===' for data values to DataFunctions, for which it is the same as '=='.

    [PR #417]

  2. Sequence functions. Added the following new functions to SequenceFunctions.

    • same compares whether two sequences are the same using === (as opposed to equals, which uses ==).
    • includingAt returns a sequence of values constructed from two input sequences by adding the second sequence at a given index in the first sequence.
    • excludingAt returns a sequence of values containing all the values from an input sequence except those within a given range of indices (inclusive).

    Added the following behaviors for convenient "standalone" modification of a sequence given with an inout parameter:

    • add adds a sequence of values to the end of the input sequence (using including).
    • addAt adds a sequence of values at a given index of the input sequence (using includingAt).
    • remove removes a set of values from the input sequence (using excluding).
    • removeAt removes the values within a given range of indexes (inclusive) of the input sequence (using excludingAt).

    [PR #417]

  3. Occurrence functions. Added a new OccurrenceFunctions package that defines functions that operate on occurrences, primarily related to the time during which those occurrences exist.

    • '===' specializes BaseFunctions::'===' for occurrences. It tests whether two occurrences are portions of the same life. That is, whether they represent different portions of the same entity (colloquially, whether they have the same "identity").
    • isDuring tests whether a performance of the function happens during the input occurrence.
    • create ensures that the start of a given occurrence happens during a performance of this function. The occurrence is also returned from the function.
    • destroy ensures that the end of a given occurrence happens during a performance of this function. The occurrence is also returned from the function.
    • addNew adds a newly created occurrence to the given group of occurrences and returns the new occurrence.
    • addNewAt adds a newly created occurrence to the given ordered group of occurrences at the given index and returns the new occurrence.
    • removeOld removes a given occurrence from a group of occurrences and destroys it.
    • removeOldAt removes the occurrence at a given index in an ordered group of occurrences and destroys it.

    [PR #417]

Systems Library

  1. Connections.
    • Added MessageConnection as the most general base type for connection definitions and usages, with FlowConnection as specialization of MessageConnection.
    • Added the features sourceEvent and targetEvent to MessageConnection to identify the events occurrences within the source and target of the connection that create and accept the connection as a transfer, e.g., a source send action and a target accept action. For non-message flow connection usages, sourceEvent and targetEvent default to source and target.

...

Read more
Loading

2022-08 - SysML v2 Pilot Implementation

15 Sep 05:47
@seidewitz seidewitz
2022-08
6417b90
Compare
Choose a tag to compare
2022-08 - SysML v2 Pilot Implementation

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

Language Features

KerML

  1. Unioning, intersecting and differencing. New relationships have been added for the unioning, intersecting and differencing of types. They are notated using new clauses that can be used in any kind of type declaration (including classifiers, features, connectors, etc.), included in the set of clauses that appear after the specialization part of the declaration.

    • unionsA, B, ... – Specifies that the declared type has unioning relationships with each of the types A, B, ..., meaning that the declared type classifies everything that is classified by any of the listed types.
    • intersectsA, B, ... – Specifies that the declared type has intersecting relationships with each of the types A, B, ..., meaning that the declared type classifies everything that is classified by all of the listed types.
    • differencesA, B, ... – Specifies that the declared type has differencing relationships with each of the types A, B, ..., meaning that the declared type classifies everything that is classified by the first type but is not classified by any of the remaining types.
    class Adult;
class Child;

class Person unions Adult, Child {
    feature dependents : Child[*];
    feature offspring : Person[*];
    feature grownOffspring : Adult[*] :> offspring;
    feature dependentOffspring : Child[*] :> dependents, offspring 
        differences offspring, grownOffspring 
        intersects dependents, offspring;
}

    [PR #396]

  2. Reference subsetting. Previously, the related feature of a connector was related to a connector end using a regular subsetting relationship. Now a special referencing subsetting relationship is used instead, syntactically distinguishing the related feature from other subsetting features the connector end might have. Notationally, this means that, in the named connector end notation, the new keyword references or the equivalent symbol ::> must be used.

    connector :A from a1 ::> f to a2 ::> g;
connector :B (b1 ::> f, b2 ::> g, b3 ::> h);
connector :B {
    end b1 references f subsets x;
    end b2 subsets y references g;
    end b3 references h;
}

    [PR #394]

SysML

  1. Flow connection definition. Previously, flow connection usages were typed by regular connection definitions specializing the base type FlowConnection. Now flow connection definitions have been added, and flow connection usages must (implicitly or explicitly) be typed by flow connection definitions. The notation is the same as for regular connection definitions, but using the keyword flow def instead of connection def. A flow connection definition is a connection definition, an action definition and a kernel interaction. A flow connection usage is now also an action usage, in addition to being a connection usage and a kernel item flow.
    [PR #390]

  2. Reference subsetting. Reference subsetting is also used in the following places in SysML.

    • Connections. To identify the related features of connections, as for KerML connectors (see above). 
      connection :A connect a1 ::> f to a2 ::> g;
connection :B connect (b1 ::> f, b2 ::> g, b3 ::> h);
connection :B {
   end b1 references f subsets x;
   end b2 subsets y references g;
   end b3 references h;
}
    • Usages. To identify the features referenced by certain kinds of usages.
      • The asserted constraint of an assert constraint usage.
      • The satisfied requirement of a satisfy requirement usage.
      • The event occurrence of an event occurrence usage.
      • The performed action of a perform action usage.
      • The exhibited state of an exhibit state usage.
      • The included use case of an include use case usage.
      perform a; // This is equivalent to the following action.
perform action references a;

// The performed action is "a" in both of the following.
perform action a1 references a subsets b;
perform action a2 :> b ::> a;

satisfy r by p; // This is equivalent to the following satisfy.
satisfy requirement references r by p;
    • Relationships. To identify the features referenced by certain kinds of membership relationships.
      • The constraint referenced by a requirement constraint membership (assume or require).
      • The concern referenced by a framed concern membership (frame).
      • The requirement referenced by a requirement verification membership (verify).
      • The rendering referenced by a view rendering membership (render).
      requirement r {
   require c; // This is equivalent to the following required constraint.
   require constraint references c;

   // The referenced constraint is "c" in both of the following.
   assume constraint ac1 references c subsets d;
   assume constraint ac2 :> d ::> c;
}
    • Variants. The notation variantreferenced-usage now parses to a reference usage with a reference subsetting to the referenced-usage. However, there is no surface notational change, and there is no requirement to use reference subsetting otherwise in variant declarations. 
      part p;
variation part q {
   variant p; // This is equivalent to the following.
   variant ref p1 references p;
   variant part p2 subsets p; // But this is also still acceptable.
}

    [PR #394]

  3. User-defined keywords. The notation has been updated to allow user-defined keywords in the following additional places.

    • assume#keywordconstraintconstraint-usage
    • require#keywordconstraintconstraint-usage
    • frame#keywordconcernconcern-usage
    • verify#keywordrequirementrequirement-usage
    • actor#keywordusage
    • stakeholder#keywordusage
    • subject#keywordusage
    • objective#keywordrequirement-usage

    Note. In items 1–4, the constraint, concern, or requirement keyword is optional when a user-defined keyword is included. However, if neither keyword is included, then the declaration is a reference, rather than the declaration of a named usage. For example, requireaGoal; is equivalent to require constraint referencesaGoal;, while require #goalaGoal;is equivalent to require #goal constraintaGoal;, where aGoal is a name of the required constraint usage, not a reference to another constraint usage.
    [PR #397]

Model Libraries

Systems Library

  1. Connections. FlowConnection and SuccessionFlowConnection have been made flow connection definitions. flowConnections and successionFlowConnections have been made messages (that is, flow connection usages without target output or source input features declared).
    [PR #390]

Backward Incompatibilities

  1. Reserved words.
    • KerML: differences intersects references unions
    • SysML: references
  2. Reference subsetting. The reference subsetting must now be used in the named notation for the related features of a connector or connection end. In other cases in SysML, reference subsetting should be used to retain the same meaning as previously. For example, in perform actionpasubsetsa; (or perform actionpa :> a;), a is no longer the performed action, it is simply a subsetted action. Instead, use perform actionpareferencesa; (or perform actionpa ::> a;).
    [PR #394]
  3. Prefix comments. Prefix comments (i.e, comments starting with /**) will no longer generate a warning. They will simply be parsed as regular comments about the namespace they are a member of (not about the following member). For example, in 
    package P {
    /** This is a comment */
    attribute x;
}
    the comment parses as being about package P (not x) with the body text * This is a comment.
    [PR #390]

Jupyter

None.

Visualization

  1. PlantUML

    • Updated to visualize language extensions with <<#...>> in the title. In addition, two new styles have been added:
      • HIDEMETADATA – Do not render callouts to show metadata.
      • SHOWMETACLASS – Always show metaclasses for types as well as metadata usages.

    [PR #385]

  2. Tom Sawyer
    None.

Technical Updates

None

Bug Fixes

  1. ItemFlow::itemType Fixed an error in the implementation of the derivation of itemType that caused an IndexOutOfBoundsException.
    [PR #386]
  2. Message ends. Corrected bugs related to the parsing of message declarations.
    [PR #387]
  3. Conditional succession. Corrected the computation of the featuring type of an implicit connector/connection.
    [PR #388]
  4. Usage::isComposite. Fixed the default for the isComposite property of a usage.
    [PR #389]
  5. Conjugate port types (PlantUML). Fixed the rendering of conjugate port types (by using the effective name).
    [PR #391]
  6. State actions (PlantUML). Removed the slash from the rendering of state actions.
    [PR #392]
  7. Anonymous packages (PlantUML). Fixed the rendering of packages without names.
    [PR #393]
  8. Cyclic types (PlantUML). Prevented a StackOverflowException when rendering cyclic types.
    [PR #395]
Loading

2022-07 - SysML v2 Pilot Implementation

10 Aug 19:46
@seidewitz seidewitz
2022-07
20831a2
Compare
Choose a tag to compare
2022-07 - SysML v2 Pilot Implementation

This is an incremental update to the 2022-06 release. It corresponds to Eclipse plugin version 0.26.0.

Language Features

The notation for a number of kinds of elements has been extended to allow them to have bodies ({...}).
[PR #381]

KerML

  1. Relationships. The relationship notation has be extended to allow any kind of element to be declared as an owned related element of a relationship, not just element declarations and annotations. In addition, the following relationship notations have also been extended to allow similar relationship bodies.

    • import
    • alias
    • specialization (including subclassification, subsetting and redefinition)
    • conjugation
    • disjoining
    • inverting
    • featuring

  2. Multiplicities. The multiplicity declaration notation can now have a full feature body.

SysML

  1. Relationships. The import, alias and dependency notations have been extended to allow bodies, but these bodies can only contain annotations (comments, documentation, textual representation or metadata).

  2. Action body elements. The following notations (used within action definitions and actions usages) can now have full usage bodies.

    • Guarded successions (firstsourceNameifconditionthentargetName;)
    • Target successions (thentargetName; and ifconditionthentargetName;)
    • Control nodes (fork, join, decision, merge)

  3. Transition usages. Within state definition and usage bodies, transition usages can now have full action bodies.

Model Libraries

Kernel Libraries

  1. Subdirectories. The Kernel Libraries directory has been reorganized into three subdirectories:

    • Kernel Semantic Library – Library models that provide the base types for required implicit specializations in KerML user model constructs, plus additional semantic models for more advanced capabilities (such as state-based behavior, etc.).
    • Kernel Data Type Library – Library models of standard data types that can be used in user models.
    • Kernel Function Library – Library models of standard functions that can be used in user models, including functions corresponding to all the operators in the KerML expression syntax.

    [PR #384]

  2. Local clocks.

    • Clocks. The singleton defaultClock feature has been renamed to universalClock. The defaults for the clock parameters of the TimeOf and DurationOf functions have been changed from defaultClock to localClock (see below).
    • Occurrences. A localClock feature has been added to Occurrence that defaults to Clocks::universalClock. The localClock of an Occurrence is passed down as the default for each of its composite suboccurrences.
    • SpatialFrames. The defaults for the clock parameters of various functions in this package have been changed from defaultClock to frame.localClock.
    • Triggers. The defaults for the clock parameters of TriggerAt and TriggerWhen have been changed from defaultClock to localClock.

    [PR #382]

Domain Libraries

  1. Local clocks.

    • Time. The singleton defaultClock part has been renamed to universalClock. The defaults for the clock parameters of the TimeOf and DurationOf calculation definitions have been changed from defaultClock to localClock.
    • SpatialItems. The existing declaration of localClock for SpatialItem has been updated to redefine Occurrences::localClock and default to Time::universalClock.

    [PR #382]

The above updates for local clocks allow, for example, the following:

part context {
  // This defines a local clock used by default within the “context” part.
  part :>> localClock = Time::Clock();

  state behavior {
    entry; then S1;
    
    state S1;
    
    transition
      first S1
      // The time instant in the trigger is, by default, 
      // relative to context::localClock.
      accept at Time::Iso8601DateTime("22-05-12T00:00:00")
      then S2;
    
    state S2;
  }
}

Backward Incompatibilities

The following textual notations have been removed, because they are considered to have become redundant or unnecessary as the notation has evolved.
[PR #381]

  1. Logical operators. For certain Boolean operators, the expression notation currently includes both operator symbols (adapted from C/Java expression syntax) and equivalent operator keywords (introduced later). This release removes the operator symbols in favor of the keywords.

    Removed Retained
    ! not
    && and
    || or
    ^^ xor
    => implies
    ... ? ... : ... if... ? ...else...

    Note that the pure logical operators & and | have also been retained.

  2. Parameter declaration. The textual syntax previously allowed for a parenthesized functional notation for declaring the parameters of a behavioral element (e.g., behaviors and steps in KerML and action definitions and usages in SysML), similarly to how parameters are declared in many programming languages. However, in KerML and SysML, parameters are simply directed features of behavioral elements which can also be declared in the body of a behavioral element. This release removes the parenthesized notation in favor of consistently using the same directed feature declaration syntax used for structural elements (e.g., ports).

    Previously allowed

    action def A (
   x : T1,
   out y : T2
);
calc def B (
    x : T1;
) return : T2;

    Alternative using directed features

    action def A {
    in x : T1,
    out y : T2
}
calc def C {
    in x : T1;
    return : T2;
}

    Note that the direction must be provided when declaring a parameter as a directed feature (unlike the special parameter notation, in which in was the default), otherwise the feature will not be directed and not considered a parameter. Parenthesized functional notation is can still be used for invoking a function or calculation in an expression, e.g., C(t1).

  3. flow from shorthand. The textual notation previously allowed for a flow from shorthand on a usage declaration, for a flow connection into that usage, similar to the feature value shorthand for a binding. This has been eliminated.

  4. Prefix comments. Previously, a comment starting with /** (i.e., with two stars instead of one) was parsed as a "prefix comment", which was automatically about the lexically following element in a namespace body. This notation has been eliminated in favor of using a documentation (doc) comment nested in the body of the element being annotated. In order to allow this more generally, the textual syntax has also been extended to allow bodies on elements that where not able to have them before (see "Language Features" above).

    (For this release only, the previous prefix comment notation will generate a warning that the notation is no longer supported. This warning will be removed in the next release, at which point the notation will simply parse as a regular comment without any warning.)

Jupyter

None.

Visualization

  1. PlantUML
    • Feature values whose value expression is a feature reference or a feature chain are now visualized as binding connectors on interconnection and action views.
      [PR #379]
  2. Tom Sawyer
    • Fixed the visualization of connectors on structural interconnection diagrams.

Technical Updates

  1. Derived properties. The implementation for all derived properties has been moved from handwritten, in-line method code in metamodel Impl classes into separate delegate classes, using the Eclipse "setting delegate" mechanism.
    [PR #380]

Bug Fixes

  1. State and state transition performances. Errors in the Kernel Library models for StatePerformance and StateTransitionPerformance have been corrected.
    [PR #383]
Loading

2022-06 - SysML v2 Pilot Implementation

21 Jul 19:59
@seidewitz seidewitz
2022-06
f9fbe18
Compare
Choose a tag to compare
2022-06 - SysML v2 Pilot Implementation

This is an incremental update to the 2022-05 release. It corresponds to Eclipse plugin version 0.25.0.

Language Features

None.

Model Library

Metadata Domain Library

  1. Refinement. A metadata definition for Refinement (short name refinement) has been added to the existing ModelingMetadata package. This can be applied to a dependency declaration to model a refinement relationship in which the source elements refine the target elements. No formal semantics is provided for this relationship at this time. For example:

    part def DesignModel;
package Specification;
requirement def SystemRequirements;

#refinement dependency DesignModel to Specification, SystemRequirements;

    [PR #377]

  2. Parameters of Interest. The new ParametersOfInterestMetadata package contains two metadata definitions for marking attribute usages that as a MeasureOfEffectiveness (short name moe) or a MeasureOfPerformance (short name mop).
    [PR #375]

  3. Images. The new ImageMetadatapackage includes the following.

    • Image attribute definition, which captures the data necessary for the physical definition of a graphical image. This can be used directly within Icon annotations (see below), or it can be used to create library models of image usages that can be referenced from Icon annotations. Alternatively, the images themselves can be physically stored in separate resources from the SysML model and referenced by URI.

    • Icon metadata definition, which can be used to annotate a model element with an image to be used to show render the element on a diagram and/or a small image to be used as an adornment on a graphical or textual rendering. Alternatively, another metadata definition can be annotated with an Icon to indicate that any model element annotated by the containing metadata can be rendered according to the Icon.

    [PR #373]

Requirements Derivation Domain Library

This new model library contains two packages to address the modeling of derived requirements.

  1. DerivationsConnections package.

    • Derivation is an abstract connection definition with no ends, but having two non-end requirement usages, one for an originalRequirement and one for all corresponding derivedRequirements. This connection definition also asserts that the originalRequirement value is not one of the derivedRequirements values and, if the check of the originalRequirement is true, then the checks for all the derivedRequirements are true.

  2. RequirementDerivation package.

    • DerivationMetadata (short name derivation) is semantic metadata for declaring Derivation connections.
    • OriginalRequirementMetadata and DerivedRequirementMetadata (short names original and derived – note that "derived" is already a reserved word) are semantic metadata for marking usages representing original and derived requirements, particularly on the end features of Derivation connections.

A connection definition or usage specializing Derivation can add one end feature for the desired original requirement, subsetting originalRequirement, and one or more end features for the derived requirements, subsetting derivedRequirements. This can be modeled succinctly using the metadata from the RequirementDerivation package (which also publicly reexports the content of the DerivationsConnection package).

For example:

requirement req1;
requirement req1_1;
requirement req1_2;

#derivation connection {
    end #original :> req1;
    end #derive :> req1_1;
    end #derive :> req1_2;
}

[PR #378]

Cause and Effect Domain Library

This new model library contains two packages to address cause-and-effect modeling.

  1. CausationConnections package.

    • Multicausation is an abstract connection definition with no ends, but having two non-end features that collect cause occurrences and effect occurrences. This connection definition also asserts constraints that the the intersection of causes and effects is empty and that all causes exist (i.e, have at least started) before all effects.
    • Causation as a binary connection definition that specializes Multicausation for the simple case of a binary relationship between one cause and one effect.

  2. CauseAndEffect package.

    • CausationMetadata is a metadata definition that can be used to annotate whether a causation isNecessary and/or isSufficient, and what its probability is.
    • MulticausationSemanticMetadata and CausationSemanticMetadata (short names multicausation and causation) are semantic metadata for declaring (respectively)Multicausation and Causation connection definitions and usages.
    • CauseMetadata and EffectMetadata (short names cause and effect) are semantic metadata for marking usages as representing causes or effects in causations (particularly on the end features of multicausation connections).

A connection usage typed by Multicausation can add end features to relate the desired causes and effects. Each such end feature should subset one of the desired causes or effects and subset either the causes (for a cause) or effects (for an effect) feature of Mulitcausation. A binary causation can be modeled by a connection usage typed by Causation, in which case the first related element is the cause and the second one is the effect.

This modeling approach is simplified by use of the semantic metadata from the CauseAndEffect package (which also publicly reexports the content of the CausationConnections package).

// Causes and effects can be any kinds of occurrences.
occurrence a;
item b;
part c;
action d;

// The #multicausation keyword identifies this as a Multicausation connection.
// The ends tagged #cause are the causes, and the ends tagged #effect are the effects.
#multicausation connection {
    end #cause :> a;
    end #cause :> b;
    end #effect :> c;
    end #effect :> d;
}

Instead of tagging the ends of the connection, the connected usages can instead be identified as causes and effects, allowing for a more compact connector syntax. Note that each such usage can be a cause or an effect, but not both.

#cause causeA :> a;
#cause causeB :> b;
#effect effectC :> c;
#effect effectD :> d;

#multicausation connect ( causeA, causeB, effectC, effectD );

For a binary causation, it is not necessary to use the #cause and #effect keywords, because the first related element is always the cause and the second related element is always the effect.

#causation connect a to c;

CausationMetadata includes isNecessary, isSufficient and probability attributes that can be used with causation and multicausation connections. (No further formal semantic model has been provided for these attributes at this time.)

#causation connect b to d {
    @CausationMetadata {
        isNecessary = true;
        probability = 0.1;
    }
}

[PR #376]

Backward Incompatibilities

None.

Jupyter

None.

Visualization

  1. PlantUML
    None.
  2. Tom Sawyer
    None.

Technical Updates

None.

Bug Fixes

  1. API client accessibility. Exports API client packages from omg.org.sysml so they can be used by dependent plugins. (Resolves issue #370).
    [PR #374]
Loading

2022-05 - SysML v2 Pilot Implementation

15 Jun 22:00
@seidewitz seidewitz
2022-05
3307d64
Compare
Choose a tag to compare
2022-05 - SysML v2 Pilot Implementation

This is an incremental update to the 2022-04 release. It corresponds to Eclipse plugin version 0.24.0.

Language Features

  1. Feature inverses (KerML only). A new feature inverting relationship has been added. The basic notation for this relationship is

    invertingnameinversefeatureInvertedofinvertingFeature;

    The invertingname part may be omitted.

    A feature inverting that is owned by its featureInverted may be specified in the declaration of that Feature:

    featurefeatureInverted inverse ofinvertingFeature;

    The inverse ofinvertingFeature part must come after any specialization or conjugation part in the Feature declaration. However, it is now allowable to specify the chaining, disjoining, inverting and featuring parts of a Feature declaration in any order.

    Two features related by a feature inverting relationship are asserted to be inverses of each other. The features can be arbitrarily nested. So, for example, given

    classifier A {
    feature b1 :B {
        feature c1 : C;
    }
}

    and

    classifier C  {
    feature b2 : B {
        feature a2 : A inverse of A::b1::c1;
    }
}

    then it must always be the case that, for any a1 : A, a1.b1.c1.b2.a2 == a1.
    [PR #361] [PR #366]

Model Library

Kernel Library

  1. Base. A new that feature has been added as a nested feature of things, the base for all features. It is constrained in Anything (the base type of everything) such that the that reference for all values reached by navigating through any nested feature of anything is the nesting thing.

    For example, given

    classifier Example {
    feature f;
}
feature x : Example[1];

    the value of x.f.that is x.
    [PR #365]

  2. Occurrences. Space modeling additions:

    • inner and outer space boundaries. In Occurrence, inner and outer occurrence references have been added, nested under spaceBoundary. These are space slices that also have no spaceBoundary, where the outer one surrounds the inner ones (see SurroundedBy below).
    • OutsideOf associations. The following new associations from Occurrence to itself (indirectly) specialize the existing association OutsideOf:
      • JustOutsideOf, linking occurrences that have space slices with no space between them (MatesWith).
      • MatesWith, specializing JustOutsideOf, linking occurrences that have no space between them.
      • InnerSpaceOf, linking an occurrence to another that completely occupies the space surrounded by an inner space boundary of the first occurrence. Added Occurrence::innerSpaceOccurrences as the cross-navigation feature for this.
      • SurroundedBy, linking an occurrence that is included in space by an innerSpaceOccurrence of the other. Types additional connectors in Occurrence that ensure spaceBoundary surrounds spaceInterior and spaceInterior surrounds inner space boundaries.

    [PR #360]

  3. Performances. A new this feature provides a context for performances similar to the "this" pointer in object-oriented programming languages such as C++, Java and JavaScript. For all occurrences that are not performances (such as items and parts in SysML), this defaults to self. For performances that are owned via composite features of an object (including owned actions of a part), this is the owning object. For performances that are owned via composite features of a performance (such as subactions in SysML), this defaults to the same value as for the owning performance.

    So, for example, an action declared at "package level" will be the this reference for all subactions in the composition tree it roots:

    package Example1 {
    action def A {
        action b {
            action c;
        }
    }

    action a : A;
    // a.b.c.this == a
}

    On the other hand, an action declared within a part definition will have an instance of that part definition as the this reference for itself and all subactions within it:

    package Example2 {
    part def C {
       action a {
            action b;
       }
    }

    part c : C;
    // c.a.b.this == c
}

    [PR #365]

Systems Library

  1. Items. Space modeling additions:

    • Generalized Item::envelopingShapes to cover curves and surfaces enveloping two dimensional shapes.
    • Added Item::boundingShapes specializing envelopingShapes as StructuredSpaceObjects in which every face/edge intersects the item.
    • Added Item::voids as the SysML name for innerSpaceOccurrences. Defined isSolid as having no voids.

    [PR #360]

  2. Actions. AcceptAction has a receiver parameter that references the occurrence via which an incomingTransfer may be accepted. The declaration for AcceptAction has been updated so that the default receiver is this (see description above). In the concrete syntax for accept actions, the receiver is specified using a via clause. The default is used if no via clause is given. For example, in

    part def Device {
    state Device_Behavior {
        state off;
        transition
            first off
            accept On_Signal
            then on;
        state on;
    }
}

    the default receiver for accept On_Signal is the instance of Device owning the Device_Behavior performance. (Note that this is similar to the concept of the "context object" for event pooling in UML/SysML v1.)

    Note. Performed actions and exhibited states are always referential, not composite. Therefore, the subactions of a performed action or exhibited state do not have the performing or exhbiiting part as their this reference. Instead, this is determined by the composite structure that actually contains the action or state being performed/exhibited.
    [PR #365]

Backward Incompatibilities

  1. Reserved words (KerML). Added: inverting inverse
  2. this and that. The new feature this is inherited by all kinds of occurrences (e.g. SysML items, parts, actions, etc.). The feature that is inherited by all nested features (SysML usages). Therefore, the names this or that for features in user models.
    [PR #365]
  3. MeasurementReferences. The Quantities and Units Domain LIbrary package UnitsAndScales has been renamed to MeasurementReferences, which better reflects what it contains (units and scales are kinds of measurement references). References to the package in all other library and example models in the repository have been updated to the new name.
    [PR #369]
  4. Subsetting validation. The validation of the owner of a subsetted feature has been tightened. This may cause some new warnings in existing models. This can usually be corrected using the dot notation.
    [PR #368]

Jupyter

None.

Visualization

  1. PlantUML
    • Improved the rendering of features whose types are vector quantities.
      [PR #362 ]
  2. Tom Sawyer
    None.

Technical Updates

  1. Security advisories. Removed yarn.lock and prevented it from being recommitted for the JupyterLab extension. This eliminates security advisory notifications related to declared version dependencies.
    [PR #363]

Bug Fixes

  1. Inherited memberships. Corrected the traversal of general types in TypeImpl::addInheritedMemberships.
    [PR #367]
  2. Variation usages. Corrected the implicit subsetting for variant usages of a variation usage.
    [PR #368]
  3. PlantUML. Fixed visualization of specializations of feature chains.
    [PR #364]
Loading

2022-04 - SysML v2 Pilot Implementation

15 May 21:41
@seidewitz seidewitz
2022-04
9637ffd
Compare
Choose a tag to compare
2022-04 - SysML v2 Pilot Implementation

This is an incremental update to the 2022-03.1 release. It corresponds to Eclipse plugin version 0.23.0.

Language Features

  1. Short names. What was previously called the "human ID" of an element is now known as its short name. However, the surface notation remains the same, e.g., part<shortName> longDescriptiveName;. Aliases can now also have short names, e.g., alias<shortAlias> longDescriptiveAliasforlongDescriptiveName;. The name resolution rules for short names are identical to those for regular names.
    [PR #359]
  2. Owning membership. The owned members of a namespace are now related to the namespace using a specialized membership relationship called an owning membership. Previously, the name of an element was derived as the member name given in the membership that owned it. Now, the element name is no longer derived and, instead, the owned member name of an owning membership is derived as the name of its owned member element. This has no effect on the surface notation, but may effect how a model is traversed, e.g., by a tool using the API.
    [PR #359]
  3. Invocation arguments. The argument expressions in an invocation expression are now parsed as feature values on the argument parameters, similarly to how parameter values would naturally be bound in a KerML expr or SysML calc usage. For example, F(x=1, y=2) now parses essentially equivalently to 
    expr : F {
    in feature redefines x = 1;
    in feature redefines y = 2;
}
    [PR #359]

Model Library

Kernel Library

  1. Control functions. The expr features on various Functions in the ControlFunctions package have now all been marked as in parameters, which work consistently with the new parsing for invocation expressions, as described above. Previously, these features were not parameters and were handled as special cases for the invocations of these Functions.
    [PR #357]

Quantities and Units Domain Library

  1. UnitsAndScales. CoordinateFrame has been added as a specialization of VectorMeasurementReference along with three concrete specializations of CoordinateTransformation, namely CoordinateFramePlacement, TranslationRotationSequence and AffineTransformationMatrix3D. Minor updates have been made to other models in the UnitsAndScales package consistent with this.
    [PR #354]

Geometry Domain Library

  1. ShapeItems. The ShapeItems library model has been revised and significantly expanded.
    [PR #357]

  2. SpatialItems. SpacialItem has been updated to use the new CoordinateFrame type.
    [PR #354]

Backward Incompatibilities

  1. Reserved words (KerML). Added: chains Removed: is
  2. Features (KerML only).
    • The featurexisy; notation for un-owned features is no longer supported.
    • The featurexisa.b.c; notation for named feature chains has been replaced with the chains clause in a feature declaration, e.g., featurexchainsa.b.c;. This clause may be used in conjunction with all other parts of a regular feature declaration. It comes after any specialization part and before any disjoining or type featuring part, e.g., featurex : Tsubsetsychainsa.b.cdisjoint withz;
  3. Invocations. As part of the update to the parsing of invocation expressions, there are some additional validations that existing models could now potentially fail.
    • If an invocation expression uses named argument notation, then each of the arguments must all name input parameters of the invoked function, and any parameter must be referenced at most once.
    • If a body expression (i.e., one with the form {...}) is used as the argument of an invocation expression, then the corresponding parameter of the invoked function must have an Evaluation type (which is the case, e.g., if the parameter is a KerML expr or SysML calc).
      [PR #359]
  4. Coordinate frames.
    • A general VectorMeasurementReference no longer has a placement. Instead, use a CoordinateFrame whose transformation is a CoordinateFramePlacement.
    • Various specializations of VectorMeasurementReference in the ISQ library models that previously had names of the form ...CoordinateSystem now have names of the form ...CoordinateFrame (e.g., ISQBase::Cartesian3dSpatialCoordinateSystem is now called ISQBase::Cartesian3dSpatialCoordinateFrame).
      [PR #354]
  5. Shapes. In a small number of cases, changes to the ShapeItems library model may not be compatible with uses of the previous version of this model. Corrections should be obvious from reviewing the latest ShapeItems model.
    [PR #357]

Jupyter

None.

Visualization

  1. PlantUML
    • Minor improvements as part of baseline update.
      [PR #359]
  2. Tom Sawyer
    • Fixed visualization of connectors on behavioral connector diagrams.

Technical Updates

None.

Bug Fixes

  1. Model libraries. Fixed the SystemUtil.isModelLibrary method so that it works correctly on Windows.
    [PR #358]
Loading

2022-03.1 - SysML v2 Pilot Implementation

20 Apr 04:53
@seidewitz seidewitz
2022-03.1
9281e82
Compare
Choose a tag to compare
2022-03.1 - SysML v2 Pilot Implementation

This release is the same as the 2022-03 release, except that it adds highlighting for user-defined keywords in Jupyter. It corresponds to Eclipse plugin version 0.22.1.

The release notes for 2022-03 are repeated below for convenience

Language Features

  1. Metadata annotation.

    • Definition. Previously, metadata was defined simply as a datatype in KerML or an attribute def in SysML. Now it is defined using a metaclass in KerML (which is a kind of struct) or a metadata def in SysML (which is a kind of item def).
    • Usage. Most syntactic restrictions on a feature declared in the body of a metadata declaration have been removed. In particular, it is now possible for a feature defined in the body of a metadata declaration to itself have nested subfeatures. However, some additional validation checks have also been implemented for such features (see details under "Backwards Incompatibilities" below).
    • Annotated elements. A metadata definition or usage now, by default, inherits an annotatedElement feature from the Kernel base metaclass Metaobject. If this feature is (concretely) subsetted or redefined in a metadata definition or usage to have a more restrictive metaclass (using the reflective KerML or SysML models) than the default of KerML::Element, then the metadata can only annotate elements consistent with that metaclass. For example, if a metadata definition includes the redefinition :>> annotatedElement : SysML::PartUsage;, then any usage of that definition can only annotate part usages.

    [PR #347]

  2. Semantic metadata. The new Kernel Library package Metaobjects defines the metaclass SemanticMetadata (see below). Any metaclass or metadata definition that specializes SemanticMetadata should bind the inherited baseType feature to a reference to a feature or usage from a user library model (see "Casting" below on how to do this). When such a specialization of SemanticMetadata is used to annotate an appropriate type declaration, the specified baseType is used as the implicit base specialization of the annotated type.

    • If the annotated type is a Feature/Usage, then the annotated feature implicitly subsets the baseType.
    • If the annotated type is a Classifier/Definition, then the annotated classifier implicitly subclassifies each type of the baseType.

    Note. It is currently only possible to specify a feature or usage as a baseType. This will be expanded to also allow classifiers in the future.
    [PR #349]

  3. Casting. The cast operator as has been implemented for model-level evaluable expressions. In addition, if the target type of the case is a metaclass, and the argument expression evaluates to a feature whose abstract syntax metaclass conforms to the given metaclass, then the result is a "meta-upcast" to the metaobject representation of the feature. E.g., if vehicle is a part usage, then vehicleasKerML::Feature evaluates, as a model-level evaluable expression, to a MetadataFeature for vehicle with type SysML::PartUsage. This can be used, for example, to bind baseType = vehicleasKerML::Feature; for SemanticMetadata.
    [PR #349]

  4. Keywords (SysML only). A user-defined keyword is a (possibly qualified) metaclass/metadata definition name or human ID preceded by the symbol #. Such a keyword can be used in the SysML textual notation in package, dependency, definition and usage declarations.

    • The user-defined keyword is placed immediately before the language-defined (reserved) keyword for the declaration and specifies a metadata annotation of the declared element. For example, if SafetyCritical is a visible metadata definition, then #SafetyCriticalpartbrakes; is equivalent to partbrakes { @SafetyCritical; }. It is not possible to specify nested features for a metadata feature annotation in the keyword notation.
    • If the given metaclass or metadata definition is a kind of SemanticMetadata, then the implicit specialization rules given above for "Semantic metadata" apply. In addition, a user-defined keyword for semantic metadata may also be used to declare a definition or usage without using any language-defined keyword. For example, if provider is the human ID of a specialization of SemanticMetadata whose baseType is the feature serviceProviders : ServiceProvider, then #providerdefBankingService;is a definition with an implicit subclassification of ServiceProvider and #provider bankingService; is a usage with an implicit subsetting of serviceProviders.

    [PR #349]

Model Library

Kernel Library

  1. Metaobjects. This is a new package with the following members.

    • Metaclass Metaobject (subclassifies Objects::Object) is the implicit base type of all metaclasses.
    • Metaclass SemanticMetadata (subclassifies Metaobject) is used to extend the language implicit specialization mechanism for use with user-defined semantic libararies (see "Semantic metadata" above).
    • Feature metaobjects is the implicit base type of all metadata features. (This is not itself a metadata features, because a metadata feature is an annotating element, while metaobjects is not.)

    [PR #347]

  2. KerML. All struct declarations in the KerML package have been changed to metaclass (with Element implicitly subclassifying Metaobject). (Note that the reflective KerML abstract syntax model still does not include any features on these metaclasses.)
    [PR #347]

Systems Library

  1. Metadata. This is new package with the following members.

    • Metadata definition MetadataItem (subclassifies Items::Item and Metaobjects::Metaobject) is the implicit base type of all metadata definitions.
    • Item usage metadataItems is the implicit base type of all metadata usages. (This is not itself a metadata usage, because a metadata usages is an annotating element, while metadataItems is not.)

    [PR #347]

  2. SysML. All item def declarations in the SysML package have been changed to metadata def. (Note that the reflective SysML abstract syntax model still does not include any features on these metadata definitions.)
    [PR #347]

Analysis and Metadata Domain Libraries

  1. Metadata definitions. Those attribute definitions in packages AnalysisTooling, ModelingMetadata and RiskMetadata that were intended to be used to define metadata have been changed to metadata definitions.
    [PR #347]

Backward Incompatibilities

  1. Keywords. KerML: added metaclass. SysML: removed feature.

  2. Annotations. An annotation relationship is no longer added to an annotating element that is an owned member of a namespace and does not explicitly specify any annotated elements (i.e., no about part). Instead, its owning namespace is simply considered to be the annotated element by default, without the need for an annotation relationship. (There is no change to the concrete syntax notation.)
    [PR #347]

  3. Documentation. Documentation is now a special kind of comment that always has its owning element as its single annotated element, rather than a special kind of annotation association to a regular comment element. (There is no change to the doc notation, just a different mapping to the abstract syntax.)
    [PR #347]

  4. Prefix Comments. The comment keyword is now used for a prefix comment (/**...*/), e.g., to give it a name, rather than the doc keyword. Previously, prefix comments were supposed comments owned by the following element using a documentation relationship, but it was difficult to implement them that way. They are now ordinary (non-documentation) comments that are just always about the lexically following element.
    [PR #347]

  5. Metadata.

    • The following validation checks are now performed on the declaration of a metadata feature or usage:
      • It must be defined by a concrete metaclass (in KerML) or metadata definition (in SysML).
      • Each of its nested features/usages (if any) must pass the following validation checks:
        • It must redefine a feature (owned or inherited) of a generalization of its owning feature.
        • If it has a feature value, the value expression must be model-level-evaluable.
        • Each of its nested features (if any) must also pass these validation checks.
    • Usages declared in the body of a metadata usage are now parsed as reference usages. The optional keyword for their declaration is therefore now ref instead of feature.

    [PR #347]

  6. Classifier base type. A validation check has been added that a classifier or definition directly or indirectly specializes the correct library base type. This will typically only be violated for vacuous circular specializations or invalid circular conjugations.
    [PR #351]

Jupyter

  1. Highlighting. User-defined keywords starting with # are highlighted like reserved words.

Visualization

  1. PlantUML

    • Improve rendering of connections.
    • Support visualization of
      • inherited feature ends or expressions.
      • nested features in metadata annotations
      • ports with directed features

    [PR #348]

  2. Tom Sawyer
    None.

Technical Updates

  1. Vulnerability. Updated yarn.lock to address security alerts.
    [PR #346]

Bug Fixes

  1. Multiplicity subsetting. Fixed the KerML grammar for MultiplicitySubset.
    [PR #350]
  2. Circular conjugation. Fixed stack overflow caused by a circular conjugation declaration.
    [PR #351]
  3. Non-ASCII characters. Revised the loading of libraries for Jupyter so that UTF-8 is always used as the cha...
Read more
Loading

2022-03 - SysML v2 Pilot Implementation

16 Apr 17:00
@seidewitz seidewitz
2022-03
92f7022
Compare
Choose a tag to compare
2022-03 - SysML v2 Pilot Implementation

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

Language Features

  1. Metadata annotation.

    • Definition. Previously, metadata was defined simply as a datatype in KerML or an attribute def in SysML. Now it is defined using a metaclass in KerML (which is a kind of struct) or a metadata def in SysML (which is a kind of item def).
    • Usage. Most syntactic restrictions on a feature declared in the body of a metadata declaration have been removed. In particular, it is now possible for a feature defined in the body of a metadata declaration to itself have nested subfeatures. However, some additional validation checks have also been implemented for such features (see details under "Backwards Incompatibilities" below).
    • Annotated elements. A metadata definition or usage now, by default, inherits an annotatedElement feature from the Kernel base metaclass Metaobject. If this feature is (concretely) subsetted or redefined in a metadata definition or usage to have a more restrictive metaclass (using the reflective KerML or SysML models) than the default of KerML::Element, then the metadata can only annotate elements consistent with that metaclass. For example, if a metadata definition includes the redefinition :>> annotatedElement : SysML::PartUsage;, then any usage of that definition can only annotate part usages.

    [PR #347]

  2. Semantic metadata. The new Kernel Library package Metaobjects defines the metaclass SemanticMetadata (see below). Any metaclass or metadata definition that specializes SemanticMetadata should bind the inherited baseType feature to a reference to a feature or usage from a user library model (see "Casting" below on how to do this). When such a specialization of SemanticMetadata is used to annotate an appropriate type declaration, the specified baseType is used as the implicit base specialization of the annotated type.

    • If the annotated type is a Feature/Usage, then the annotated feature implicitly subsets the baseType.
    • If the annotated type is a Classifier/Definition, then the annotated classifier implicitly subclassifies each type of the baseType.

    Note. It is currently only possible to specify a feature or usage as a baseType. This will be expanded to also allow classifiers in the future.
    [PR #349]

  3. Casting. The cast operator as has been implemented for model-level evaluable expressions. In addition, if the target type of the case is a metaclass, and the argument expression evaluates to a feature whose abstract syntax metaclass conforms to the given metaclass, then the result is a "meta-upcast" to the metaobject representation of the feature. E.g., if vehicle is a part usage, then vehicleasKerML::Feature evaluates, as a model-level evaluable expression, to a MetadataFeature for vehicle with type SysML::PartUsage. This can be used, for example, to bind baseType = vehicleasKerML::Feature; for SemanticMetadata.
    [PR #349]

  4. Keywords (SysML only). A user-defined keyword is a (possibly qualified) metaclass/metadata definition name or human ID preceded by the symbol #. Such a keyword can be used in the SysML textual notation in package, dependency, definition and usage declarations.

    • The user-defined keyword is placed immediately before the language-defined (reserved) keyword for the declaration and specifies a metadata annotation of the declared element. For example, if SafetyCritical is a visible metadata definition, then #SafetyCriticalpartbrakes; is equivalent to partbrakes { @SafetyCritical; }. It is not possible to specify nested features for a metadata feature annotation in the keyword notation.
    • If the given metaclass or metadata definition is a kind of SemanticMetadata, then the implicit specialization rules given above for "Semantic metadata" apply. In addition, a user-defined keyword for semantic metadata may also be used to declare a definition or usage without using any language-defined keyword. For example, if provider is the human ID of a specialization of SemanticMetadata whose baseType is the feature serviceProviders : ServiceProvider, then #providerdefBankingService;is a definition with an implicit subclassification of ServiceProvider and #provider bankingService; is a usage with an implicit subsetting of serviceProviders.

    [PR #349]

Model Library

Kernel Library

  1. Metaobjects. This is a new package with the following members.

    • Metaclass Metaobject (subclassifies Objects::Object) is the implicit base type of all metaclasses.
    • Metaclass SemanticMetadata (subclassifies Metaobject) is used to extend the language implicit specialization mechanism for use with user-defined semantic libararies (see "Semantic metadata" above).
    • Feature metaobjects is the implicit base type of all metadata features. (This is not itself a metadata features, because a metadata feature is an annotating element, while metaobjects is not.)

    [PR #347]

  2. KerML. All struct declarations in the KerML package have been changed to metaclass (with Element implicitly subclassifying Metaobject). (Note that the reflective KerML abstract syntax model still does not include any features on these metaclasses.)
    [PR #347]

Systems Library

  1. Metadata. This is new package with the following members.

    • Metadata definition MetadataItem (subclassifies Items::Item and Metaobjects::Metaobject) is the implicit base type of all metadata definitions.
    • Item usage metadataItems is the implicit base type of all metadata usages. (This is not itself a metadata usage, because a metadata usages is an annotating element, while metadataItems is not.)

    [PR #347]

  2. SysML. All item def declarations in the SysML package have been changed to metadata def. (Note that the reflective SysML abstract syntax model still does not include any features on these metadata definitions.)
    [PR #347]

Analysis and Metadata Domain Libraries

  1. Metadata definitions. Those attribute definitions in packages AnalysisTooling, ModelingMetadata and RiskMetadata that were intended to be used to define metadata have been changed to metadata definitions.
    [PR #347]

Backward Incompatibilities

  1. Keywords. KerML: added metaclass. SysML: removed feature.

  2. Annotations. An annotation relationship is no longer added to an annotating element that is an owned member of a namespace and does not explicitly specify any annotated elements (i.e., no about part). Instead, its owning namespace is simply considered to be the annotated element by default, without the need for an annotation relationship. (There is no change to the concrete syntax notation.)
    [PR #347]

  3. Documentation. Documentation is now a special kind of comment that always has its owning element as its single annotated element, rather than a special kind of annotation association to a regular comment element. (There is no change to the doc notation, just a different mapping to the abstract syntax.)
    [PR #347]

  4. Prefix Comments. The comment keyword is now used for a prefix comment (/**...*/), e.g., to give it a name, rather than the doc keyword. Previously, prefix comments were supposed comments owned by the following element using a documentation relationship, but it was difficult to implement them that way. They are now ordinary (non-documentation) comments that are just always about the lexically following element.
    [PR #347]

  5. Metadata.

    • The following validation checks are now performed on the declaration of a metadata feature or usage:
      • It must be defined by a concrete metaclass (in KerML) or metadata definition (in SysML).
      • Each of its nested features/usages (if any) must pass the following validation checks:
        • It must redefine a feature (owned or inherited) of a generalization of its owning feature.
        • If it has a feature value, the value expression must be model-level-evaluable.
        • Each of its nested features (if any) must also pass these validation checks.
    • Usages declared in the body of a metadata usage are now parsed as reference usages. The optional keyword for their declaration is therefore now ref instead of feature.

    [PR #347]

  6. Classifier base type. A validation check has been added that a classifier or definition directly or indirectly specializes the correct library base type. This will typically only be violated for vacuous circular specializations or invalid circular conjugations.
    [PR #351]

Jupyter

None.

Visualization

  1. PlantUML

    • Improve rendering of connections.
    • Support visualization of
      • inherited feature ends or expressions.
      • nested features in metadata annotations
      • ports with directed features

    [PR #348]

  2. Tom Sawyer
    None.

Technical Updates

  1. Vulnerability. Updated yarn.lock to address security alerts.
    [PR #346]

Bug Fixes

  1. Multiplicity subsetting. Fixed the KerML grammar for MultiplicitySubset.
    [PR #350]
  2. Circular conjugation. Fixed stack overflow caused by a circular conjugation declaration.
    [PR #351]
  3. Non-ASCII characters. Revised the loading of libraries for Jupyter so that UTF-8 is always used as the character encoding (regardless of the platform default).
    [PR #352]
  4. Space modeling. Corrected errors related to space modeling in the Kernel Library Occurrences and Objects models, in the Geometry Domain Library `...
Read more
Loading