Sinelabore Homepage

Parts#

Role in SysML v2#

A part definition represents a modular unit of structure such as a system, system component, or external entity that may directly or indirectly interact with the system.

A part usage is a kind of item usage that is a usage of one or more part definitions.

Mapping to C++#

Parts are mapped to C++ classes which are derived from the Part base class. This base class is defined in the framework header which defines helper functionality required for the execution of the generated model.

Part usages can only be used within a part and are mapped to class attributes.

Example#

SysML v2 source code:

private import ScalarValues::*;

package Test { 
  part def PartDef1;
  part def PartDef2 {
    /* members */
    part part1 : PartDef1;
    
    part part2 : PartDef1 {
      /* members */
    }

  }
}

C++ source code:

namespace Test {

class PartDef1 : public Part {

public:
  PartDef1() {}

  virtual void process() override {}

  // must be called by derived classes after constructing the parts
  virtual void init(void) override {}
};

class PartDef2 : public Part {

public:
  PartDef2() {}

  std::unique_ptr<PartDef1> part1 = std::make_unique<PartDef1>();

  virtual void process() override { part1->process(); }

  // must be called by derived classes after constructing the parts
  virtual void init(void) override {
    assert(part1);
    part1->init();
  }
};

} // end of namespace Test

Multiplicity#

Part usages may declare multiplicity. Fixed counts, ranges, and bounds that refer to attributes are supported:

part def A {}

part def P {
    attribute n : Integer default 5;

    part a[1] : A;
    part b[0..2] : A;
    part c : A[2..7];
    part d[*] : A;
    part e[n] : A;
}

Iterate over part arrays in actions with for x in y — see Actions.

Specialization and usage prefixes#

Parts can specialize other parts with :>. Features can be redefined with :>> / redefines. Usages may also use ref, abstract, and subsets for references and collections:

part def Vehicle {
    attribute speed : Real default 50.5;
    part engine : Engine;
}

part def SportsCar :> Vehicle {
    attribute speed :>> Vehicle::speed : Positive = 120;
    part engine :>> Vehicle::engine : ElectricEngine;
}

See the 7.2.6 release notes for short examples of redefinition and related features.

Collections of parts#

A common pattern is one collection that groups several named members, so that each part can be addressed individually and the whole group can be iterated:

part def Controller {
    // the collection itself
    abstract ref part lamps : Lamp [*];

    // named members of that collection
    ref part redLamp    subsets lamps : Lamp;
    ref part yellowLamp subsets lamps : Lamp;
    ref part greenLamp  subsets lamps : Lamp;
}

This generates a ConstrainedVector<Lamp*> whose bounds come from the multiplicity, and the init code fills it from the subsetting members:

std::unique_ptr<ConstrainedVector<Lamp*>> lamps =
    std::make_unique<ConstrainedVector<Lamp*>>(0, SIZE_MAX, PreFillPolicy::None, "lamps");
...
lamps->clear();
lamps->push_back(redLamp.get());
lamps->push_back(yellowLamp.get());
lamps->push_back(greenLamp.get());

abstract is what turns the usage into a collection. Without it — part lamps : Lamp [*]; — the multiplicity is dropped and you get a single owned Lamp that has no relation to redLamp and its siblings. Mark a grouping usage abstract so it is not instantiated in its own right, and add ref when the parts are owned elsewhere, as above.

Iterate over such a collection in an action with for x in lamps — see Actions.