Skip to content

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

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]
Assets 3
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]
Assets 3
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]
Assets 3
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]
Assets 3
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
Assets 3
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
Assets 3
Loading

2022-02 - SysML v2 Pilot Implementation

18 Mar 05:43
@seidewitz seidewitz
2022-02
d6341d9
Compare
Choose a tag to compare
2022-02 - SysML v2 Pilot Implementation

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

Language Features

  1. Feature chain expressions. Expressions of the form expr.x.y.z that were previously parsed as path step expressions are now parsed in a slightly simpler and more semantically correct way as feature chain expressions.

Model Library

Kernel Library

  1. Occurrences
    • Added modeling for spatial aspects of Occurrence and for constructive relations on occurrences of union, intersection and difference.
    • Added associations to represent spatial relationships SpaceSliceOf, SpaceShotOf and OutsideOf, and the spacetime relationship WithOut.
  2. Objects
    • Added specializations of Object for Body, Surface, Curve and Point, of inner space dimension 3, 2, 1 and 0, respectively.
    • Added StructuredSpaceObject to represent an Object that is broken up into cells of the same or lower inner space dimension (faces, edges and vertices).
  3. SpatialFrame (new). Models spatial frames of reference for quantifying the position vector of a point in a three-dimensional space.
  4. VectorValues (new). Provides a basic model of abstract vectors as well as concrete vectors whose components are numerical values.
  5. VectorFunctions (new). Defines abstract functions on VectorValue corresponding to the algebraic operations provided by a vector space with inner product. It also includes concrete implementations of these functions specifically for CartesianVectorValue.
  6. TrigFunctions (new). Defines basic trigonometric functions on real numbers and provides a constant feature for pi.

Systems Library

  1. Items. Added the following features:
    • shape - The shape of an item is its spatial boundary.
    • envelopingShapes - Other shapes that spatially envelop an item.
    • isSolid - An Item is solid if it is three-dimensional and has a non-empty shape (boundary).

Quantities and Units Domain Library

  1. Quantities. VectorQuantityValue is now a kind of NumericalVectorValue (from VectorValues).
  2. VectorCalculations. Revised to provide calculation definitions for VectorQuantityValue that specialize the corresponding functions from VectorFunctions.

Geometry Domain Library

  1. SpatialItems (new). Models physical items that have a spatial extent and act as a spatial frame of reference for obtaining position and displacement vectors of points within them.
  2. ShapeItems (new). Provides a model of items that represent basic geometric shapes.

Backward Incompatibilities

  1. Select and collect expressions. The new shorthand notation for expr->select{...} is expr.?{...}. The shorthand notation previously used for select, expr.{...}, is now a shorthand for expr->collect{...}.
  2. Suboccurrences. The feature suboccurrences of Occurrence has been renamed to spaceEnclosedOccurrences.
  3. Sum and product functions. The sum and product functions have been moved into NumericalFunctions and removed from DataFunctions and ScalarFunctions.
  4. Mathemetical function names. Non-operator mathematical functions from the various Kernel mathematical function packages have been updated to have a more consistent convention of names starting with a lower case letter.
  5. BasicGeometry. The BasicGeometry model previously in the Geometry Domain Library has been deleted.

Jupyter

None.

Visualization

  1. PlantUML
    None.
  2. Tom Sawyer
    None.

Technical Updates

None.

Bug Fixes

Implementation

  1. Assumed and required constraints. Fixed the implmentation of getAssumedConstraintImpl and getRequiredConstraintImpl in RequirementUsageImpl.
  2. Owned connections. Fixed the implementation of getOwnedConnection in DefinitionImpl.
  3. Validation. Corrected the multiplicity lower bound validation for end features.

Library

  1. Portions. Constrained the portions of an occurrence to have the same life as the occurrences they are portions of.
  2. PortionOf. Corrected the order of the end features of the Occurrences::PortionOf association.
  3. SnapshotOf. Corrected the multiplicity of SnapshotOf::snapshottedOccurrence.
  4. VectorQuantityValue. Updated Collections::Array to allow dimensionless arrays of a single value. This then allows a VectorQuantityValue to be dimensionless (order 0), correcting the former inconsistency of ScalarQuantityValue (with order 0) being a specialization of VectorQuantityValue (previously required to have order 1).
Assets 2
Loading

2022-01 - SysML v2 Pilot Implementation

13 Feb 01:51
@seidewitz seidewitz
2022-01
062576a
Compare
Choose a tag to compare
2022-01 - SysML v2 Pilot Implementation

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

Language Features

KerML

  1. Return parameters. It is now possible to mark a parameter declared in a function body as the return parameter in the KerML textual notation (as was already possible in SysML).

SysML

  1. Accept actions. The notation for accept actions (used either within an action model or in a transition) has been updated to allow the payload parameter to be declared with a feature value or incoming flow. In this case, an accepted transfer must have a payload identical to the bound or flowed value.

    • acceptpayloadName:PayloadType=valueExpression;
    • acceptpayloadName:PayloadTypeflow fromsource;

    Note. The syntactic form acceptPayloadType;, without a colon in the payload declaration, is still allowed and still represents a declaration of the payload type, not its name. A binding or flow cannot be included in a declaration of this form.

  2. Change triggers. A change trigger of the form whenchangeCondition can now be used in place of a feature value in a payload declaration. The changeCondition must be a Boolean-valued expression, and the trigger fires when the expression result changes from false to true (or if the result is true when first evaluated).

    • acceptpayloadName:PayloadTypewhenchangeCondition;

    Note. The explicit declaration of the payload parameter is optional, allowing the simple form accept whenchangeCondition;. The form acceptpayloadNamewhenchangeCondition; is also allowed, but this represents a declaration of the payload name, not its type.

  3. Time triggers. A time trigger of the form attimeExpression or afterdurationExpression can now be used in place of a feature value in a payload declaration. The timeExpression must result in a TimeInstantValue, and the trigger fires at that time (relative to the default clock). The durationExpression must result in a DurationValue, and the trigger fires after the elapse of that duration (on the default clock).

    • acceptpayloadName:PayloadTypeattimeExpression;
    • acceptpayloadName:PayloadTypeafterdurationExpression;

    Note. Simplified payload declarations are allowable for time triggers, similarly to change triggers.

Model Library

  1. FeatureReferencePerformances. The Kernel Library package FeatureAccessPerformanceshas been renamed to FeatureReferencingPerformances, and the following behaviors have been added to it:
    • FeatureMonitorPerformance
    • EvaluationResultMonitorPerformance
    • BooleanEvaluationResultMonitorPerformance
    • BooleanEvaluationResultToMonitorPerformance
  2. Clocks and Triggers. The following packages have been added to the Kernel Library:
    • Observation – models monitoring for change and notifying registered observers.
    • Clocks – models clocks that provide a current time reference, with functions for getting the time and duration of an Occurrence relative to a clock.
    • Triggers – provides convenience functions for creating monitored change signals for change triggers, absolute time triggers and relative time triggers.
  3. Time. A specialization of the Kernel Clock model has been added to the Quantities and Units Library Time package, using time instant and duration quantity values.
  4. SI. ScalarQuantityValue in the Quantities and Units Library Quantities package is now a specialization of NumericalValue instead of ScalarValue.

Backward Incompatibilities

  1. Keywords.
    • KerML: Added: return
    • SysML: Added: when at after
  2. FeatureReferencePerformances. The Kernel Library package FeatureAccessPerformanceshas been renamed to FeatureReferencingPerformances.
  3. SI. The Quantities and Units Library package SI no longer imports QuantityCalculations. These means that the SI package no longer re-exports the the calculation definitions from QuantityCalculations or various other members re-exported from QuantityCalculations (such as from ScalarValues and Quantities).
  4. Time. The order of the public owned features of the Iso8601DateTime and Iso8601DateTimeStructure calculation definitions in the Quantities and Units Library has been changed so the non-redefining parameters come first (allowing a more natural use of positional argument notation when invoking these calculations).
  5. USCustomaryUnits. Units other than actual US customary units have been removed from this package.

Jupyter

None.

Visualization

  1. PlantUML
    • Imports (both element and package, recursive or not) are now rendered using the dashed arrow notation. A new option, SHOWIMPORTED, has been added which shows imported elements as well as the traversed elements.
  2. Tom Sawyer
    None.

Technical Updates

None.

Bug Fixes

  1. KerML relationship notation. Fixed the KerML grammar so that
  • A Relationship that is an owned related element of another relationship can have unowned related Eeements.
  • A Relationship can have only owned related elements.
  • All owned related elements of a relationship are added to its targets.
Assets 2
Loading

2021-12 - SysML v2 Pilot Implementation

14 Jan 21:55
@seidewitz seidewitz
2021-12
6774e96
Compare
Choose a tag to compare
2021-12 - SysML v2 Pilot Implementation

This is an incremental update to the 2021-11 release. It corresponds to Eclipse plugin version 0.19.0.

Language Features

  1. If actions. An if action evaluates a Boolean-valued condition. If the result is true, it performs a nested then action, otherwise it performs a nested else action.
    • An if action has the form
      actionifNameifconditionactionthenActionName{ ... }else actionelseActionName{ ... }
    • The action declaration part may be omitted for the entire if action, the then action and/or the else action:
      ifcondition{ ... }else{ ... }
      The curly braces are required, even if the body of the then action or else action is empty, unless the else action is itself an if action, in which case a simplified notation can be used:
      ifcondition{ ... }else if{ ... }else{ ... }
      This is equivalent to
      ifcondition{ ... }else{if{ ... }else{ ... } }
    • The else action is optional. If it is omitted, then no action is performed if the condition is false.
  2. While-loop actions. A while-loop action repeatedly performs a nested body action as long as a Boolean-valued while condition is true and an until condition is false. The while condition is evaluated before each iteration, and the until condition is evaluated after the iteration.
    • A while loop action has the form
      actionwhileLoopNamewhilewhileConditionactionbodyName{ ... }until untilCondition;
    • The action declaration part may be omitted for the entire while-loop action and/or the body action:
      whilewhileCondition{ ... }until untilCondition;
      The curly braces are required, even if the body is empty.
    • The until condition is optional. If it is omitted, then the default is untilfalse (that is, no effect).
      whilewhileCondition{ ... }
    • The while condition may be replaced with the keyword loop, which is equivalent to whiletrue.
      loop{ ... }until untilCondition;
      If the until condition is also omitted, then the action specifies a non-terminating loop.
      loop{ ... }
  3. For-loop actions. A for-loop action iterates over the values resulting from the evaluation of a sequence expression, assigning each in turn to a for variable feature and performing a nested body action for the assigned value.
    • A for-loop action has the form
      actionforLoopNameforforVariableDeclinsequenceExpractionbodyActionName{ ... }
    • The action declaration part may be omitted for the entire for-loop action and/or the body action:
      forloopVariableDeclinsequenceExpr{ ... }
  4. Path expressions. Previously, a path expression of the form expr.a.b.c was parsed as a tree of path step expressions. That is, it was parsed like (expr.a).b).c). Such expressions are now parsed so that a trailing path of two or more features parses as a feature chain. That is, expr.a.b.c parses as a single expression that applies the feature chain (e.g., a.b.c) to the result of the expression expr.

Model Library

  1. Occurrences. The HappensDuring and HappensBefore associations in the Occurrences Kernel Library model have been updated with cross-relation and transitivity constraints and the semantic constraints on the HappensJustBefore association have been simplified.
  2. Actions. Added the action definitions IfThenAction, IfThenElseAction, LoopAction, WhileLoopAction and ForLoopAction, along with corresponding base usages, to the Actions Systems Library model.
  3. SI. The longName feature binding has been removed from unit declarations. The declarations have been revised so that the declared unit name is its "long name" and its human ID is its abbreviation. Due to the name resolution rules for human IDs, this should have no effect on existing user models.
  4. USCustomaryUnits. A large number of additional units have been added to the USCustomaryUnits model from the Quantities and Units Domain Library, based on the NIST SP811 standard. (Note, however, that a further update to this package is expected in the next release.) All unit declarations in the package now also use the same naming convention described above for the SI package.

Backward Incompatibilities

  1. Keywords. SysML: Added: loop until while.
  2. Implicit typing. The following improvements have been made to the implicit typing of certain expressions, which may result in new type warnings in some places.
    • The result of a path step expression (e.g., expr.a.b.c) is typed like the result of the feature or feature chain being accessed (e.g., a.b.c).
    • The result of a path select expression (i.e., expr.{ ... }) is typed like the result of its first argument (expr), which is the expression that evaluates to the collection being selected from.
    • The result of an invocation expression used as a constructor for a non-function type (e.g., ItemType( ... )) is typed by the type being constructed (e.g., ItemType).
  3. Measurement unit "long names". The longName feature has been removed from the TensorMeasurementReference definition in the UnitsAndScale model from the Quantities and Units Library. If longName was being bound in a unit declaration, the value should instead be used as the name of the unit, with the short name or abbreviation used as the human ID.

Jupyter

None.

Visualization

  1. PlantUML
    None.
  2. Tom Sawyer
    None.

Technical Updates

  1. Content assist. The Xtext generation workflows have been updated to remove the generation of content assist code, including the content-assist-specific parser. This was necessary due to a problem with the generation of the content-assist parser (see the in PR #313), and it resolves the known issue of the editors hanging when content assist is triggered (see issue #220). A custom implementation of content assist may be considered in the future, as time and resources permit.

Bug Fixes

  1. Operands. Fixed the duplicated serialization into XMI of the operands of an OperatorExpression. This also eliminated the duplicate validation checks and error messages on operands.
Assets 2
Loading

2021-11 - SysML v2 Pilot Implementation

11 Dec 18:06
@seidewitz seidewitz
2021-11
9cd8d36
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
2021-11 - SysML v2 Pilot Implementation

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

Language features

  1. Assignment actions. An assignment action is used to change the value of a feature at the time of performance of the action.

    • Assignment to feature in scope. Assigns the result of valueExpression to the feature with a featureName in the current scope.

      assignfeatureName:=valueExpression;

      Example: assigncurrentStatus := StatusEnum::Nominal;

    • Assignment to feature of a target occurrence. Assigns the result of a valueExpression to the feature with name featureName of the occurrence that is the result of a targetExpression.

      assigntargetExpression.featureName:=valueExpression;

      Example: assigntrailer.trailerFrame.coupler := vehicle.hitch;

      Note: In this case the targetExpression is the path step expression trailer.trailerFrame, and the valueExpression is also a path step expression, vehicle.hitch. The featureName is coupler.

  2. Initial values. An initial value is specified when declaring a feature similarly to a bound value, but using the symbol := rather than =. The feature is set to the specified initial value at the start of the lifetime of its containing occurrence, and, unlike if a bound value was specified, the initial value can be subsequently changed using an assignment action.

    attributecount : Integer := 0;

    It is also possible to mark an initial value as a default, in which case it may be overridden in a redefinition of the feature.

    itemsensordefault:= primarySensor;

  3. Invocation using feature chains. Feature chains can now be used as the target of invocation expressions.

    directory.addressOf(userName)

  4. Implicit typing. If a feature is declared without an explicit feature typing, but with a feature value, then the feature is implicitly typed by the result type of the feature value expression.

    attributecolor = ColorEnum::red; // color implicity has type ColorEnum.

    Note that this also works if the feature value is initial and/or default.

Model Library

  1. AssignmentAction. Added the action definition AssignmentAction and the action usage assignmentActions to the SysML Actions model library.

Backward incompatibilities

  1. Keywords. SysML: Added: assign.

  2. Risk metadata. The enumerated values for the LevelEnum and RiskLevelEnum in the RiskMetadata model have been renamed from L, M, H to low, medium, high.

  3. Trade studies. The calculation definition ObjectiveFunction in the TradeStudies model has been renamed EvaluationFunction and the corresponding calculation feature TradeStudy::objectiveFunction has been renamed evaluationFunction.

  4. Enumerations. Previously, if a feature was typed by an enumeration definition, then the name of an enumerated value from the definition could be used as a feature value without qualification. However, it is now necessary to qualify the name, unless it has otherwise been imported into the local namespace.

    attributecolor : ColorEnum = ColorEnum::red; // Qualification is necessary.

Jupyter

None.

Visualization

  1. PlantUML
    • Added new view for cases, including analysis cases, verification cases and use cases.
    • Added special rendering for actors and stakeholders in the tree view.
    • Added compartment rendering for connections.
    • Corrected the rendering of flow connections in the interconnection view.
  2. Tom Sawyer
    • Implemented visualization of "proxy" connections and connection points.
    • Implemented a view that combines aspects of a tree and a nesting view, through actions that expand single nodes as nesting or as a tree.

Technical Updates

  1. Eclipse. Updated the development baseline to Eclipse version 2021-09.

Bug Fixes

  1. Variations. Declaring a case (of any kind) to be a variation no longer results in a spurious "A variation must only have variant owned members." error.
  2. Protected visibility. Fixed the resolution of the name of an inherited member with protected visibility when referenced in a nested scope. Also updated handling of protected visibility to conform to the current specification that resolution of qualified names requires that all segments but the first have public visibility.
  3. Feature value scoping. Names in feature value expressions are now resolved starting with the scope of the owning namespace of the corresponding feature declaration, not in the scope of the feature itself, eliminating anomalous resolution to members of the feature. (Note, however, that this causes the backwards incompatibility for enumerations described above.)
  4. Metadata visualization. For PlantUML, fixed the visualization of feature chains used to specify a metadata feature.
  5. Requirement constraints. For PlantUML, fixed the visualization of require and assume constraints in the constraint compartment of a requirement definition or usage.
Assets 2
Loading