Skip to content

2025-04 - SysML v2 Pilot Implementation

Latest
Latest
Compare
Choose a tag to compare
@seidewitz seidewitz released this 23 May 13:57
· 22 commits to master since this release
2025-04
dd82a0f
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

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

Language Features

  1. Control node bodies. In the SysML abstract syntax, control nodes (i.e., fork, join, decide and merge nodes) are kinds of action usages that are typed by ControlActions from the Systems Model Library. The abstract syntax allows control nodes to have any sort of owned members that other kinds of action usages can. However, the textual notation syntax previously allowed only annotations to be declared in the body of a control node. This has now been corrected to allow control nodes to have regular action bodies.

    In particular, with this change, it is possible to declare control nodes with parameters, enabling the modeling of flows through them. For example:

    action def A {
    action a1 {
        out x1;
    }
    then j1;

    action a2 {
        out x2;
    }
    then j1;

    flow a1.x1 to j1.x1;
    flow a2.x2 to j1.x2;

    join j1 {
        in x1;
        in x2;
        out y = (x1, x2);
    }
    then a3;

    flow j1.y to a3.y;

    action a3 {
        in y;
    }
}

    Note that it is still necessary to have successions (or succession flows) into and out of control nodes in order to get the proper "control" semantics.
    [PR #642]

  2. Constructor expression evaluation. The model-level evaluation of a constructor expression has been implemented to simply return the result parameter of the expression. This works, because a constructor expression is parsed as an expression whose instantiated type is instantiated by its result parameter, with argument expressions bound to appropriate features of the instantiatedType.

    For example, given the following:

    part def P {
   attribute a;
   attribute b;
}
part p = new P(1,2);
attribute p_a = p.a;
attribute p_b = p.b;

    the feature p evaluates to the result parameter of the constructor expression, which is a usage of P with its attributes bound to the argument expressions. Therefore, p_a evaluates to the literal integer 1 and p_b evaluates to the literal integer 2.
    [PR #645]

Model Libraries

None.

Backward Incompatibilities

None.

Issue Resolutions

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

KerML

The resolution for the following issues was approved on KerML FTF2 Ballot 7. It was previously implemented, except for the model-level evaluation of constructor expressions.

SysML

The resolution for the following issue was approved on SysML v2 FTF2 Ballot 7. (This resolution should have been implemented in the 2025-02 release, but it was missed.)

The resolution for the following issue, approved on SysML v2 FTF2 Ballots 9, had already been previously implemented.

  • SYSML2_-803 Correction to the resolution of SYSML2_-510

Jupyter

  1. %projects command. The magic command %projects has been added to list the name and identifier of all projects in the repository.
    [PR #616]

  2. %load command. The magic command %load has been added to load models from a project in the repository.

    %load [--id=<PROJECT ID>] [--name=<NAME>] [--branchid=<BRANCH ID>] [--branch=<BRANCH_NAME>] [<NAME>]

Download previously published models from a project in the repository. (Use %projects to view repository contents.)
Named elements of the downloaded models may then be referenced by models in the notebook.
<NAME> is the full name of the project.
If <PROJECT ID> is given, then the project with that UUID is loaded. In this case, the <NAME> must not be given.
If <BRANCH NAME> or <BRANCH ID> is given, then the model is loaded from this branch of the project.
If no <BRANCH NAME> or <BRANCH ID> is given, the default branch is used.
If <BRANCH ID> is given, then a <BRANCH NAME> must not be given.

    [PR #616]

  3. %publish command. Previously, the %publish command in Jupyter always created a new project on the API server, posting all elements of a model in the one and only commit on the "main" branch. The command has been updated to post incremental changes based to a specified project based on the delta between the remotely stored models and their local models. (Currently this usually means that the new commit completely replaces the content of the model – since re-parsing a model in Jupyter creates entirely new element UUIDs – but it is at least possible to publish multiple versions of a model in multiple commits to a single project in the repository.)

    Note. Previously, a model was published by default including values for all derived properties. The default is now to publish without derived property values (which greatly reduces the size of the published model). To include derived property values, use the -d option.

    %publish [-d] [--project=<PROJECT NAME>] [--branch=<BRANCH NAME>] <NAME>

Publish the model elements rooted in <NAME> to the repository. <NAME> must be fully qualified.
Use the -d flag to include derived properties.
If <PROJECT NAME> is given, it is used as the name of the project to create or update.
If <PROJECT NAME> is not given, the (simple) name of the model element is used.
    If no project exits with the given name, then a new project with that name is created.
    Otherwise, the existing project is updated with a new commit.
If <BRANCH NAME> is given, then the model is written to this branch of the project.
If <BRANCH NAME> is not given, the default branch is used.

    [PR #633]

  4. %repo command. The magic command %repo has been added to allow the repository API base path to be changed.

    %repo [<BASE PATH>]

Set the API base path for the repository accessed by the %projects, %publish and %load commands.
<BASE PATH> is a URL (possibly including port number), such as: https://my.domain.com/sysml_repo:9000.
If <BASE PATH> is not given, the current repository base path is printed.
If <BASE PATH> is given, the repository base path is set to this.

    [PR #644]

Visualization (PlantUML)

  1. Shorthand notations. Visualization has been updated to render short hand graphical notations, when possible, for event occurrence, perform action, exhibit state and include use case usages.
    [PR #647]

Technical Updates

  1. SysMLv2 menu. A SysMLv2 submenu has been added to the popup menu for projects, with the following options:

    • Generate Library Index: Moved under SysMLv2 menu.
    • Pull model from API: Download models from a repository and save in .sysmlx files. This requires that .settings/org.omg.sysml.remote.properties exists with the following contents: 
      base.url=repository url
remote.projectId=project id
remote.branchId=branch id
      (remote.branchId is optional; if not provided, the default branch is used)

    [PR #616]

  2. Jupyter magic commands. The implementation of magic commands for Jupyter has been extended external users to define and register additional commands that can reuse the state of the Jupyter kernel without needing to recompile the existing codebase.
    [PR #649]

  3. Continuous integration builds. The running of continuous integration builds has been switched from Travis CI to GitHub Actions.
    [PR #650]

Bug Fixes

  1. new keyword. Fixes highlighting of the new keyword in Jupyter.
    [PR #643]
  2. Rendering of «variant». Removes the rendering of «variant» for an enumeration definition in PlantUML.
    [PR #646]
  3. Operation isCompatibleWith. Adds a Boolean return type to the Feature::isCompatibleWith operation.
    [PR #648]
  4. XMI generation. Corrects a possible exception when generating XMI for a model when implied relationships are included.
    [PR #651]
Assets 4
Loading