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]