SysML Block Definition Diagram

Abstract exploration of initial values

Abstract exploration of initial values
This is a hybrid diagram, supported in the MD SysML Plugin of MagicDraw™ UML, where the initialValues compartment can be shown on a property symbol in the structure compartment on a BDD.

The Type has 5 value properties, only 4 of which have a UML Property.defaultValue, and only 2 of which are re-initialised in a higher usage context UseType:

The class-level default values of v2[1] and v3[0..*] will be "overridden" (on/after construction) with an explicit property-specific initial value, and SysML1.2 specifies that these may by shown in the initialValues compartment for property t:Type of context UseType in an IBD.

Vallue property v5[0..1] has no initial value (since it has neither a class-level default value nor a property-specific initial value).

Dr Darren has suggested that v1[1] and v4[0..1] should take their class-level default values as initial value - although, AFAIK, SysML tools do not (yet) support this. In other words, the static values should "show through" to the initialValue compartment.

PsychoMediumBoxWithSmallBallBox (BDD): progressive redefinition to represent deep value state

PsychoMediumBoxWithSmallBallBox (BDD): progressive redefinition to represent deep value state

One strategy for representing values of deep layers is to progressively (and tediously) redefine the UML Property.defaultValue with more and more complex nested InstanceSpecifications, as shown for the PsychoMediumBoxWithSmallBallBox, which redefines the Property sbb:SmallBallBox to give it more "psychedlic" colours1.

Note that we are still only using UML capabilities, however there is no way of showing in the BDD (or in a Class Diagram) what the newly defined deep values are, i.e., one can't tell from the Blocks alone that, for example, the ball becomes red.

During practical systems engineering modelling one does not want to always have to show InstanceSpecifications this way; SysML however offers another solution, in the Internal Block Diagram (IBD) ..

  • 1. My apologies if these colours are a bit hard on the eyes.

MediumBoxWithSmallBallBox (BDD): a container with deep nesting

MediumBoxWithSmallBallBox (BDD): a container with deep nesting

Now some deep nesting is introduced, and the complexity quickly increases. For demonstration, the new MediumBoxWithSmallBallBox redefines the color to be green, and recall that the default Ball of a SmallBallBox has color orange.

And now we can start to see one of the main points of this tutorial; how can one describe a configuration of the system where the shallow nested SmallBallBox and the deeply nested Ball have arbitrary desired colour ?

There are 2 main cases to be explored:

  1. Describe desired values of deeply nested properties at the moment the outermost Block "constructs itself"
  2. Describe values of deeply nested properties at any moment after construction (which may be provided by an additional time slice context), or equivalent, describe values of deeply nested properties in an environmental context (such as under a range of test conditions, or weather conditions)

This is bread-and-butter stuff for even basic systems engineering. It turns out that Unified Modeling Language™ (UML™) can only handle progressive initialisation/configuration level by level, and that Systems Modeling Language™ (SysML™) is making headway towards handling this in more general cases, which we'll examine shortly .

First however, lets look inside the MediumBoxWithSmallBallBox as is ..

Structure compartment

This content area is UNDER CONSTRUCTION or MIGRATION

Constraints compartment

This content area is UNDER CONSTRUCTION or MIGRATION

Box.bdd: composition

Box.bdd: composition

Amongst the Webel props are a variety of boxes that can be used as containers of things, to construct a containment hierarchy (not to be confused with the containment operator or containment of model elements in a model repository or browser).

This is more formally known in UML as aggregation (or sometimes as "composition"), where the AggregationKind can be one of (none, shared, composite), for which SysML™ has, in the case where the composed element is a plain Block, the special (implicit, not stereotyped) property types 'part property' and 'reference property' (which covers both cases of 'shared' and 'none' aggregation). We'll see later how these might all be used, for now we will be using only the accessible 'part property' concept, which is usually interpreted to mean that if an instance of the aggregating Block is destroyed, so will the instances it composes/aggregates.

The Box block shown has a content:ColoredThing part property, and lower multiplicity 0 (empty), and maximum multiplicity 1 (full), which must be explicitly indicated because of the special rules for default multiplicities introduced by SysML™. (For simplicity, it will be assumed that a Boxcan't contain more than one thing, which assumption works quite well with most of the Webel props.)

Since a Ball is a ColoredThing, a Box may contain a Ball. And since a Box is also a ColoredThing, a Box may also contain a Box.

But what happens if 2 boxes are the same size ? Surely they can't fit inside each other !
This a situation where the systems engineering aspect, as opposed to "just" software engineering, enters; just as well the Box has been left abstract (so that nonsense can't be instantiated). One can do a lot of things with software objects that don't work with physical objects in the real world.

It might be tempting to introduce a UML-style contraint, but what would it target ? It would have to say something like:

"If the instance content:ColoredThing of a Box instance is itself a Box then its length must be smaller than that of the containing Box"

It quickly becomes clumsy, and it can't preempt all possible types of contained things anyway. One way of addressing this is through subclassing (inheriting Blocks), as we'll see soon.

First however, a quick look at the matching IBD for abstract Box ..

ColoredThing.bdd: giving things some value

ColoredThing.bdd: giving things some value

We start with the simplest abstract Thing, and an abstract ColoredThing, (which happens to have blue1 as the default colour).

  • 1. Blue is a random choice, the set of props modelled used does not have white things or black things or something more neutral

SysML Block Definition Diagram (BDD) in MD SysML

SysML Block Definition Diagram (BDD) in MD SysML

In MD SysML you are freely encouraged to use the UML InstanceSpecification to explore "instances", however they are not formally permitted in SysML diagrams (although they are used behind the scenes for carrying value state anyway).

Syndicate content