SysML v2 Definition vs. Usage: What's It All About?

Not Really New: The Terminology of Definition and Usage

First of all, the distinction between definition and usage in modeling languages is not a new concept at all. It already existed in SysML 1.x; more precisely: in the underpinned UML. The Block Definition Diagram (bdd) in SysML v1 is—as its name reveals—a diagram of the definition level, whereas the Internal Block Diagram (ibd) is a diagram of the usage level. The elements defined in a bdd (e.g., a SysML Block) are used as so-called Part Properties in a specific context that is depicted in an ibd.

As I shortly mentioned in a previous blog article, this pattern of distinguishing between definition and usage is now handled even more consequently in SysML v2. For example, there are now also requirement definitions and usages, or use case definitions and usages. This was not the case in SysML 1.x.

But the crucial question is: What is the benefit of this? What purpose is this distinction good for? To answer these questions, let's take a closer look.

Definitions in SysML v2

With a definition element, you create something like a type description in your model, compareable to a data sheet. This type description is valid for a class of similar entities or objects. Thus, definition elements are sometimes also compared to a blueprint. In the SysML v2 Specification you find the following explanation for Definitions:

In general, a definition element classifies a certain kind of element (e.g., a classification of attributes, parts, actions, etc.).

Let's take a very simple part that can be find in a lot of systems as an example: a screw. It should not be just any screw, but a M6 hexagon head bolt in accordance with the DIN-EN-ISO 4017 industry standard, made of rustproof and acid-resistant V4A stainless steel (material number 1.4401) with a length of 40 mm. In the textual notation of SysML 2.0, this screw would be described as follows:

package DefinitionExample {
    private import ScalarValues::*; // String
    private import SI::*; // mm

    part def M6_HexagonHeadBolt {
        attribute diameter :> ISQBase::length = 6[mm]; 
        attribute nominalLength :> ISQBase::length = 40[mm];
        attribute materialNumber : String = "1.4401";
        attribute normativeStandard : String = "DIN EN ISO 4017:2022-10";
    }
}

Our screw is desribed here by a SysML Part Definition named M6_HexagonHeadBolt. The so-called kind keyword part specifies the language construct—in this case a modular unit of structure—, and the addition def indicates that this is a definition of a part. The screw has four properties that are specified as attributes. By the way, these are attribute usages. Without going into too much detail at this point, just briefly: The attribute normativeStandard for instance has its data type String in the imported library package ScalarValues.

We have now defined a screw with very specific properties in our system model. However, although we have described this screw sufficiently with this specification, we have not yet put it to any use.

Usages in SysML v2

Usages refer to the purpose for which a defined element—such as our M6 hexagon head bolt—is used. The screw described in the previous definition can be used multiple times in our system and perform different tasks or can have different roles there. In the SysML v2 Specification you can find the following explanation for Usages:

A usage element is a usage of a definition element in a certain context.

In order to use our defined screw, we must put it into an application context, meaning it must become a subpart of something larger, such as a system. To do this, we also need to model the system of interest and have to nest all usages of our screw (and also other parts) in it. In SysML v2, we talk about the so-called Features of the whole, in this case of the system.

Let's take a steel wall shelf as an example. The corresponding textual notation in SysML v2 might look something like this:

package DefinitionUsageExample {
    private import ScalarValues::*; // String
    private import SI::*; // mm

    part def M6_HexagonHeadBolt {
        attribute diameter :> ISQBase::length = 6[mm]; 
        attribute nominalLength :> ISQBase::length = 40[mm];
        attribute materialNumber : String = "1.4401";
        attribute normativeStandard : String = "DIN EN ISO 4017:2022-10";
    }
    
    part def SteelPlate;
    part def WallBracket;
    
    part wallShelf {
        part shelf : SteelPlate;
        part leftBracket : WallBracket;
        part rightBracket : WallBracket;
        part leftMountingScrew[2] : M6_HexagonHeadBolt;
        part rightMountingScrew[2] : M6_HexagonHeadBolt;
    }
}

Two further part definitions have now been added here: the definition of a steel plate and a wall bracket. Their definitions are very simple, because they don't have any further features, like attributes or subparts. From line 15 onwards, the parts that make up the shelving system are specified. The wallShelf itself is a part usage without having an explicit part definition created beforehand. This is permissible. SysML v2 supports a purely usage-oriented modeling approach that allows usage elements, e.g., parts, attributes, ports, actions, etc., to be created without explicit definitions.

Special attention should be paid to our screws here. As can be seen, the system contains four screws: two in the role of left mounting screws and two as right mounting screws. However, they are the same type of bolt that we've defined earlier.

Rendered as a graphical view (diagram), our wall shelf looks as follows:

In SysML v2 graphical notation, definition elements are depicted by rectangular symbols with sharp corners, whereas usages are depicted by rectangular symbols with rounded corners.

Conclusion

I hope this blog article has clearly explained the difference between definition and usage in SysML v2. And it has probably also become clear what purpose this differentiation serves: it is a reuse pattern! Model elements can be defined once with their features (e.g., attributes) and then (re-)used in different contexts. Among other things, for instance, this concept allows modelers to create domain-specific model libraries with reusable elements. Furthermore, changes to a definition, such as adding or modifying an attribute, are automatically reflected in all of its usages. This ensures consistency and results in less effort and fewer errors.

You want to dive deeper into Systems Modeling Language 2.0 and MBSE? Take a look at our portfolio of training courses and seminars on this topic.