Skip to content

2020-06 - SysML v2 Pilot Implementation

Compare
Choose a tag to compare
@seidewitz seidewitz released this 16 Jul 02:59
· 2863 commits to master since this release

This release corresponds to Eclipse plugin version 0.4.0. The following are changes since the 2020-03 release (the previous public release).

Language features

  1. New definition/usage keywords. New keywords have been introduced corresponding to the consistent definition/usage terminology in the 2020-06 baseline of the abstract syntax. The old keywords still work as synonyms for the new keywords.
    • blockpart def
    • assoc blockconnection def
    • linkconnection
    • value typeattribute def
    • valueattribute
    • activityaction def
  2. Item definition and usage. An item is a model of something that exists in space and time but is not considered to necessarily itself be a system or part of a system. An item may be spatially discrete (like a part) or continuous (like water or fuel), and it may flow through, be stored in or be acted upon by a system.
  3. Case definition and usage. A case is a model of the steps necessary to produce a desired result regarding some subject, satisfying a specific objective. The objective of a case is modeled as a requirement.
  4. Analysis case definition and usage. An analysis case is a case carrying out an analysis on its subject. The steps of an analysis case may be drawn from a set of analysis actions that abstract typical capabilities to be applied by analytical tools during an analysis.
  5. Variability modeling. Any kind of definition or usage may be identified as a variation that models a point at which a selection can be made between a specified set of choices during the configuration of a system. All the members of a variation must be variant usages that model the allowable choices for configuration of the variation.
  6. Succession shorthand. The then shorthand can now be used to show succession between individual usages (particularly snapshots and time slices).
  7. Behavioral usages with direction. It is now possible to declare a direction on behavioral usages (e.g, “in action …”).
  8. Nested behavioral usages. It is now possible to have behavioral usages generally nested in action and state usages (this allows, in particular, the nesting of constraint usages in action and state usages).
  9. Space and time quantities and units. The new package ISQSpaceTime in the Quantities and Units domain library covers all quantities and units defined in ISO 80000 Part 3 Space and Time.

Backward incompatibilities

  1. Keywords. The following new keywords have been added as reserved words:
    attribute, analysis, calc, case, connection, item, objective, return, variation, variant
  2. Direction and end keyword placement. The keywords in, out, inout and end now always come before other keywords. For example, the previously allowed syntax part in x; and part end x; must now be written in part x; and end part x;, respectively.
  3. Behavioral definition and usage specialization. The specialization parts for the declaration of behavioral definitions and usages (actions, states, calculations, constraints, requirements, cases and analysis cases) must now come before the parameter parts. For example, the previously allowed syntax action def A (in x) :> B; and action a: A (in x = y) :>> b; must now be written action def A :> B (in x); and action a: A :>> b (in x = y);, respectively.
  4. Measurement units. Measurement units are now attributes, rather than parts. This is consistent with the ability to perform arithmetic operations on measurement units (e.g., kg*m/s). This mostly affects user models that define new measurement units. Models that simply use standard units from the SI or US Customary Units libraries should generally be unaffected.
  5. Public imports in quantities and units models. The use of public import in the Quantities and Units packages has been limited to the cases listed below. This may result in name resolution errors when reprocessing existing models that import Quantities and Units library models. Such errors can be fixed by either explicitly qualifying the names in question or by importing them directly from the appropriate package.
    • The SI package re-exports names from the ISQ package (e.g., quantity value types, such as LengthValue, etc.) and SIPrefixes (e.g., centi, milli, kilo, etc.).
    • The USCustomaryUnits package re-exports names from the ISQ package.

Validations

  1. Default validation. Previous default metamodel validation checking has been disabled (which greatly reduces the cascade of unclear messages due to small errors).
  2. Typing errors. Validation checks have been implementing for the typing of specific SysML elements (e.g., a port usage must be typed by a port definition, etc.).
  3. Warnings. The following warning validations have been implemented (some of which were previously errors). Unlike errors, warnings do not prevent a model from being fully syntactically processed, though it may not be semantically valid.
    • Connected features should have a common context. This warning indicates that there is no common containing context from which a connector and each of its connected features can be reach by valid ownership paths.
    • Bound features should have conforming types. This warning indicates that the types of the features connected by a binding connector do not actually allow for the possibility of the bound features having common values.
    • Subsetting/redefining feature should not be nonunique if subsetted/redefined feature is unique (previously an error).
    • Subsetting/redefining feature should not have larger multiplicity upper bound (previously an error). This is only checked if the upper bounds are given as literal values.
    • Redefining feature should not have smaller multiplicity lower bound (previously an error). This is only checked if the lower bounds are given as literal values.
    • Owner of redefining feature should be a specialization of owner of redefined feature. A redefinition is supposed to be of a feature that would otherwise be inherited, and inherited features come from the generalizations of the owner of the redefining feature.
    • Owner of redefining feature should not be the same as owner of redefined feature. This also follows from the requirement that a redefinition be of a feature that would otherwise be inherited.
    • A package-level feature should not be redefined (by another package-level feature). A feature that is declared in a package that is not a type is effectively considered to be a feature of the most general type Anything. Therefore, redefining a feature at “package-level” with another feature at package-level would be like redefining a feature with the same effective owner, Anything.

Visualization

  1. Tom Sawyer
    • Tree and interconnection views have been significantly updated based on user feedback.
    • A basic action model view has been added.
  2. PlantUML
    • PlantUML visualization is now available in Jupyter Notebook using the '%viz' magic command.
    • An interconnection view has been added.
    • Errors in state visualization have been corrected.