Lesson 5 - Enforcing Multiplicity Limits - 3 Runners Caused No Errors

SysML v2 Advent of SysML v2
1

Greetings!

I believe that I defined the multiplicity for “runner” correctly based on the way “reindeer” is defined:

abstract ref part reindeer : Reindeer [9];
// Definition of Runner and Side not shown
abstract part runner : Runner [2];
part leftRunner :> runner { attribute :>> side := Side::leftRunner; }
part rightRunner :> runner { attribute :>> side := Side::rightRunner; }
part centerRunner :> runner; // 3rd Runner. Why does this not cause an error?

If the multiplicity is defined correctly, I would expect that usage of a 3rd runner would result in some kind of notification (error or warning.)

How is the multiplicity enforced or used?

Thanks!

~Ben

2

Hello Ben!

It might not seem intuitive, but in terms of SysML semantics there is vagueness whether leftRunner, rightRunner and centerRunner are all distinct.

In general Editor does not enforce multiplicity since the current SysML v2 spec does not specify any hard restrictions on multiplicities. However, a custom validation can be written using syside Automator to enforce multiplicity rules that suit your needs.

Hope that helps!

-Martynas

3

Hello Ben,

What Martynas said is correct—unfortunately, this is a shortcoming of the specification. The keyword “disjoint" is currently not part of SysML (only KerML), and the open-world semantics allow any type to have an intersection unless explicitly forbidden by the model (by the way, the definition of different nose colors for each reindeer happens to achieve this implicitly).

If you are in the SysML v2 Release Google Group, this thread touched the topic: https://groups.google.com/g/sysml-v2-release/c/IxXXfalPO7U/m/ii1jttcSBwAJ

There are several ideas on how to overcome this, but there is no definitive answer yet. Most of us assume that tools will operate based on some kind of “disjointness policy" to guess user intent (as pioneered by Steve Jenkins in the onology world). If we stick to the open world semantics and the language as it is now, it will takes solvers/provers to figure out if a model is satisfiable—which is probably not very practical.

Vince

4

Martynas, Vince,

Thank you for your explanation and for providing background details.

~Ben

5

Hello!

I have a similar problem to Ben’s, and I had the same idea as you — to validate this myself using my tool. However, I then detected some problems.

Let’s look at this library:

library package TwinSensorLibrary{
    private import TwinTypeSystem::*;
    attribute def Position:>TwinCustomType{
        attribute x:>fields:TwinReal;
        attribute y:>fields:TwinReal;
        attribute z:>fields:TwinReal;
    }

    part def TwinSensor{
        attribute temperature : TwinAttribute;
        attribute position[4] : Position;
    }

Then the user uses the libray and models a TwinSensor:

part def P11:>TwinSensor{
        attribute :>>temperature : TwinReal = PLUS_real(1.0, 2);
        attribute pos1:>position;
        attribute pos2:>position;
        attribute pos3:>position;
        attribute pos4:>position;
        attribute pos5:>position; /*<- this will lead to an error*/

       
    }

    //But what should i do with redefintions

    part def P12:>TwinSensor{
        attribute :>>temperature : TwinReal = PLUS_real(1.0, 2);
        attribute pos1:>>position;
        attribute pos2:>>position;
        attribute pos3:>>position;
        attribute pos4:>>position;
        attribute pos5:>>position;
       
    }

For subsetting, it’s easy in my tool: there will be a validation rule when the number of subsetting validates, and then I raise an error. But what should I do with redefinitions? As i understood redefinitions means that pos1 replaces the position collection here in this context and not like subsetting its now part of the collection.