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 the basics of SysML semantics and classification
• Learn about specialization relationships and their meaning in SysML
• Learn about model refactoring in Syside

Today’s lesson is a little more theoretical in nature. However, these are fundamental concepts necessary to obtain a solid understanding of the language. We promise to keep it as simple as we can!

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.

Basics of SysML Semantics

First, we will learn a little about SysML’s semantics, which relies on classification.

Classification means that we categorize things in a real or envisioned universe into classes, which are essentially sets of things that share some common properties or significance.

This occurs at multiple levels in SysML. First, the metamodel classifies the elements we can use in the language. The language defines concepts like type, definition, and usage, and the model elements we create are instances of these classes.

The same thing happens between the levels of models and instances. When we create a definition called Sleigh, for example, the meaning of that is a class of things in the universe we are modeling. We refer to the set of things in the class as the extent of the type. Interpretation, also often referred to as instantiation or execution, occurs when we assign these sets to types in our model, effectively defining their exact meaning.

As you learned in the previous lesson, definition elements classify single things in the universe (for example, sleighs or reindeer), while usages classify tuples, representing relationships between these things (for example, reindeer pulling a sleigh). This is illustrated in the figure below. Notice the difference between the definition “Reindeer” and the usage “reindeer” – instances of the usage are actually pairs of a sleigh and an actual reindeer.

Specialization Relationships in SysML

Having seen the basics of classification, we are now ready to discuss specialization relationships in SysML.

The precise meaning of specialization is that we restrict the instances of a class to a subset of the instances. As a consequence, specialization implies the inheritance of features – since every instance of the special type is an instance of the general type, it obviously also has the same features.

Specialization is useful for refining our concepts by adding more constraints, gradually excluding elements that do not conform to our vision of the modeled concept. The ultimate goal is that every legal instance of our model element satisfies our needs – for example, any possible instance conforming to the Santa’s sleigh model should be suitable to be presented to Santa.

In terms of terminology, the target of specializations is usually called a general type or a supertype, while the source is called a special type or subtype. We can also say “specialized type” and “specializing type” to emphasize their role in the relationship. In every case, the general type will have a larger extent (it can actually be the same), and the extent of the special type will be a subset of it.

Hold on to these ideas for the rest of the lesson because they will be applicable in every special case – and there are quite a few. SysML has several kinds of specialization relationships.

When it is between definitions, we call it subclassification (if you hear only specialization, it probably also refers to this case). Between usages, we can have subsetting or redefinition. There is also a relationship called definition between a usage and its definition. All of these are specializations, and they will behave exactly along the principles we have just discussed.

We will now take a closer look at them. There are also some special kinds of subsettings, but we will discuss them in later episodes.

Subclassification (“specializes”)

Observe the figure and the model snippet below.

As you already know, subclassification is between definitions. There should be no surprises in the figure: every SantaSleigh we eventually manufacture will also be a Sleigh, but not all sleighs will be as cool as our SantaSleigh. This means that the extent of SantaSleigh is a subset of the extent of Sleigh.

Subsetting (“subsets”)

Subsetting is between usages and expresses the same relationship as subclassification.

Rudolph, as a specific role in the sleigh’s design, and not the friendly reindeer himself, is actually a subset of all the reindeer pulling the sleigh. We could also define a subset of the reindeer whose noses have a warm color. Examining the extents, we can again see that these are relationships; however, the subset relationship remains the same as in the previous case.

Redefinition (“redefines”)

Now for something trickier. Redefinition is again between usages, but they are between usages of a more general and a more specific type.

When we specialize Sleigh with our SantaSleigh design, we inherit the “reindeer” usage. We can redefine it in SantaSleigh to restrict it further – we will see this in practice shortly.

If you observe the figure, we can again see that the set of reindeer pulling our super-cool SantaSleigh is the subset of the reindeer pulling any kind of sleigh.

If you compare subsetting and redefinition, you may notice that they are symmetric in a sense. Subsetting restricts the set of pairs by restricting the second value of the pair (more specific reindeer), while redefinition restricts the first value of the pair (more specific sleigh).

Definition (“defined by”)

Last but not least, defining a usage by a definition is also a kind of specialization.

This is somewhat surprising to many people, but the idea is that the set of reindeer actually pulling a sleigh is the subset of all the reindeer, some of whom may not pull a sleigh. In any case, it provides us with all the features of the “Reindeer” definition in the “reindeer” usage. Arguments about whether this semantics is good or not will probably continue among the more formally inclined people.

How to Model With Specializations?

Let us see all this in a complex example. The model below is a version of Santa’s sleigh, tailored to demonstrate specializations. As usual, you can find it in Syside Cloud (get access by registering for Advent of SysML v2).

This time, we have a definition in line 3 called SantaSleighSketch, which represents the initial idea for Santa’s new sleigh. We already know that there will be a dashboard and that it will be pulled by reindeer. Here in line 5, we immediately find the first specialization – a definition relationship, which is denoted either by a colon (“:”) or the “defined by” keyword that you can also see below in line 9. As we said, the usage inherited the features of the definition, so the reindeer usage also has a nose color.

Next, we see a more elaborate design of Santa’s sleigh in line 8, which specializes the sketch version. This is a subclassification, denoted by the keyword “specializes” or the “:>” symbol. In this case, we use it to refine a partial design, but we could also create other design alternatives of the sketch, and it can also be used to factor out common features from several similar definitions.

Within the design in line 9, we can see a redefinition combined with another definition relationship. The redefinition, denoted by the keyword “redefines” or the “:>>” symbol, means that in the context of “SantaSleighDesign”, the inherited dashboard should be called “nnDashboard”, and it should be defined by the “NaughtyNiceDashboard” part definition. With this line, we captured a design decision about the dashboard in our design, which is more specific than the one inherited from the sketch.

Moving on, we can also observe a subset relationship in line 10, denoted by the “subsets” keyword or the “:>” symbol, which happens to be the same as the symbol for subclassification. This should not surprise us now, after having seen that they actually mean the same thing. This line means that the usage “rudolph”, again as a role, is a subset of all the reindeer pulling the sleigh. We can use subsetting to enumerate the elements of a set with singleton subsets, or to define more restricted subsets for different purposes.

A combination of these happens here. Inside the usage “rudolph” in line 11, we redefine the attribute “noseColor” to be red, this time using the symbol “:>>”. This is an extra constraint that the values of the “rudolph” usage will have to satisfy. What we said is that only red-nosed reindeer can be Rudolph.

With this, you have seen all the basic specialization relationships in action, and you should be ready to experiment on your own in today’s challenge.

Challenge for Tomorrow

Your challenge after this lesson is to model the contents of the cargo bay in Santa’s sleigh. This is an alternate design where the cargo bay is a regular cargo bay, but the gift bag is magical. Go to Syside Cloud and extend the model as follows:

• Define the bottomless gift bag that can hold any number of gifts (gifts are items)
• Model Santa’s sleigh as a special kind of sleigh
• In this sleigh, the cargo bay’s payload should be called a gift bag
• The gift bag should always be bottomless
• The gift bag should contain at least a toy train, a teddy bear, and a candy cane

Be sure to get the specializations right! You should use all four kinds. Explain in comments why you use each kind whenever you use one.

Summary

In this episode, you learned about definitions and usages, a core concept in SysML v2. You should now know when to use which and what happens if you mix them up. You also saw how you can refactor models in Syside manually and automatically. If you haven’t yet done so, it is now time to go to Syside Cloud to do the challenge. Don’t forget to come back tomorrow for another episode of the Advent of SysML v2!