Advent of SysML v2 | Lesson 11 – Attributes and Quantities

2025-12-11
, Vince Molnár, Kestutis Jankevicius

Hello and welcome back to the Advent of SysML v2 – a daily, hands-on mini-course designed to bring you up to speed with the new SysML v2 standard and the modern Syside tooling that makes you productive from day one.

By the end of this lesson, you will:

Learn about attribute definitions and usages
Learn about quantities and units
Learn how to specify the value of a usage

If you want to dive deeper into the world of SysML v2, check out The SysML v2 Book, where this topic is also discussed in more detail.

Attributes and Enumerations

We can already model components, so let us investigate how to capture their attributes. Attributes, in the SysML sense, are data types. They should be used whenever you model the characteristics of something (rather than its structure or relationships). They are significantly different from other kinds of elements (like parts, items, actions, etc.) in two ways:

Instances of attributes are abstract concepts like numbers. They do not have an identity – the number 5 is just the number 5, all the time, regardless of the context. If two instances of an attribute look the same, they are the same.
Following from the previous point, attribute usages are always referential. Nobody owns that single number 5 – we just refer to it when we want to describe something.

There are several built-in attributes in the library, for example, “ScalarValues” contains all the usual number concepts. There are also more complex attributes, such as collections. We can also create our own attribute definitions.

package L11_Attributes_Quantities {
    private import ScalarValues::Real;
    private import ISQ::length;
    private import ISQ::mass;
    private import SI::kg;
    private import SI::cm;

    attribute def ReindeerFeatures {
        // Not variables, so cannot be constant!
        attribute noseColor : Color;
        attribute eyeColor : Color;
    }
    
    part def Reindeer {
        constant attribute features : ReindeerFeatures;
        attribute energyLevel : Real;
    }

    enum def Color {
        enum orange; enum yellow; enum green;
        enum blue;   enum indigo; enum violet;
        enum silver; enum gold;   enum red;
        enum brown;  enum white;  enum black;
    }
}

For example, in line 8, we declare the attribute definition “ReindeerFetures” to group all the interesting information about reindeer. We can then use this as the type of the attribute usage “features” in line 15.

Attribute usages must be defined by attribute definitions or KerML datatypes. Furthermore, attribute definitions and usages may only specialize other attributes or KerML datatypes.

Members of attribute definitions are always referential. Furthermore, they are not variables, so they never change their value, and cannot be constant either (see Episode 5). We can say that attributes function similarly to immutable objects in programming languages, at least in this regard.

We can also see that attribute usages in other definitions are variable (like in line 15), so they can also be constant. If we want to change the features of a reindeer, we have to change the whole “ReindeerFeatures” instance – but we explicitly forbid this here with the “constant” modifier.

A special kind of attribute is an enumeration. Enumerations are declared with the “enum” kind keyword, and their values are restricted to those enumerated in the body of the enum. Each possible value is declared after the “enum” keyword. For example, you can see the enumeration “Color” in line 19. Enumerations can be much more complex, but this topic is beyond the scope of this mini-series. We encourage interested readers to dig deeper using the SysML specification (clause 7.8) or The SysML v2 Book.

Quantities

In systems engineering, most numerical attributes represent some physical quantity. Keeping track of the meaning of numbers is therefore essential. In SysML, we can do this with quantities.

package L11_Attributes_Quantities {
    attribute def ReindeerFeatures {
        // …
        attribute antlerLength subsets ISQ::length;
    }
    
    part def Reindeer {
        constant attribute features : ReindeerFeatures;
        constant attribute weight redefines ISQ::mass;
        // …
    }

    // …
}

Quantities are actually not standalone model elements. They are a set of standard attribute definitions in the Quantities and Units Library, accompanied by attribute usages that further refine the role of the quantity (like “length”, “width”, and “height” for “LengthValue”). All standard quantities can be accessed in the “ISQ” package (International System of Quantities, as defined in ISO/IEC 80000). The best way to use them is to subset or redefine one of the usages with our attribute.

Subsetting is the safer option. You can see this in line 4, where we say that “antlerLength” is a kind of length – it subsets “ISQ::mass”. If you use redefinition, like in line 9, you say that “weight” is the mass of the reindeer (and there will be no other kinds of mass). Do this only if you explicitly want to prevent other kinds of the same quantity.

Although you can also directly type your attribute with the quantity attribute definition, this is generally not recommended. It is much better to refine the role modeled by the usage anyway.

Feature Values and Units

There is only one question left to answer: how to specify the value of usages. This is done by feature values. We will focus on attribute usages, but the same principle applies to the feature values of all usages.

package L11_Attributes_Quantities {
    private import ScalarValues::Real;
    private import ISQ::length;
    private import ISQ::mass;
    private import SI::kg;
    private import SI::cm;

    attribute def ReindeerFeatures {
        // Not variables, so cannot be constant!
        attribute noseColor : Color;
        attribute eyeColor : Color;
        attribute antlerLength subsets ISQ::length;
    }
    
    part def Reindeer {
        constant attribute features : ReindeerFeatures;
        constant attribute weight redefines ISQ::mass default 110 [kg];
        attribute energyLevel : Real default := 100;
    }

    part def Rudolph specializes Reindeer {
        constant attribute :>> features = new ReindeerFeatures(Color::red, Color::brown, 60 [cm]);
        constant attribute :>> weight = 100 [kg];
        attribute :>> energyLevel := 200;
    }

    enum def Color {
        enum orange; enum yellow; enum green;
        enum blue;   enum indigo; enum violet;
        enum silver; enum gold;   enum red;
        enum brown;  enum white;  enum black;
    }
}

There are four kinds of feature values, resulting from the combination of two aspects.

An initial value is applicable to variables only and constrains the value only at the beginning of its owner’s lifetime. In contrast, a bound value constrains the value for the entire lifetime.
A feature value may also be a default value. A default value can be overridden when the usage is specialized. If it is not a default, there is no way to change the value in specializations.

An example of a default initial value can be seen in line 18. It is denoted by the “:=” symbol. It is an initial value because the “energyLevel” of a reindeer may change over time and is not constant, and it is a default value because we want to allow specific reindeer to have different initial energy levels. The default is helpful if someone does not want to change the value – then the default becomes effective.

A default bound value is shown in line 17. It is denoted by the “=” symbol, but if it is a default value, the “=” can be omitted. Here, the weight of the reindeer is assumed to be constant, so we want to specify the value for the whole lifetime of the reindeer. Again, this is a default value because we want to allow specific reindeer to have a different weight.

A non-default initial value is then applied in line 24, overriding the default value of the redefined usage. Similarly, line 23 features a non-default bound value. These lines would give an error if we had not used default feature values in “Reindeer”.

There are two more points of interest in the model above.

This first one is the use of units. Units go with quantities and specify the unit of measurement in which the value of the quantity is specified. However, they are not encoded in the type of the attribute – they belong to the value itself, specified in square brackets (“[ ]”) after the number. This means that a length value can have an initial value specified in any length unit (for example, meters or centimeters) and conversion is handled automatically by the language. SI units can be found in the “SI” package. The other interesting point is an instantiation expression in line 22. When we want to specify a complex value, such as an instance of the “ReindeerFeatures” attribute definition, we can use such an expression to construct it. The expression starts with the “new” keyword, then the reference to the type that we want to instantiate, then a list of parameters enclosed in parentheses. Each value between the parentheses will be assigned to the corresponding usage based on its position – Rudolph’s nose will be red, his eyes will be brown, and his antlers will be 60 cm long.

Challenge for Tomorrow

With this, you are ready to model the characteristics of Santa’s sleigh. It is time to go to Syside Cloud and do the following tasks:

Model a generic Sleigh and specify at least 5 physical attributes. Although there is built-in support for it, model the bounding box of the sleigh yourself with an attribute definition. Use default values whenever appropriate.
Specialize the sleigh model with SantaSleigh and specify the values for the inherited attributes.

Summary

In this episode, you learned about attributes, enumerations, as well as quantities and units. You now know how to specify the values of usages in many different scenarios. If you haven’t yet done so, it is now time to go to Syside Cloud to do the challenge – and don’t forget to come back tomorrow for another episode of the Advent of SysML v2!