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 connections
• Learn about cross subsetting and reference subsetting
• Learn about cross multiplicities

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.

Connection Definitions and Cross Subsetting

It’s almost the end of the second week, and we are ready to address one of the most complex parts of SysML: connections. Connections are parts that connect other elements. You can avoid them if you want by using referential usages to refer to other elements, but when it comes to bidirectional relationships, they implement an essential pattern. If you are familiar with databases, connections are like junction tables.

In today’s example, we are modeling the connection between the reindeer and Santa’s sleigh – which is actually the harness itself. Accordingly, we declare “Harness” as a connection definition in line 12. It is just like a part definition, but as a connection, it has ends. The first end is a part called “sleigh”, defined by the part definition “Sleigh”, while the second is called “reindeer”, defined by “Reindeer”. Let us take a look at the new keywords.

First, “end” denotes an end feature. Connections can have arbitrary features just like every part, so this keyword tells SysML that we are about to declare the ends, not just a regular feature.

The trickier part is the “crosses” keyword. This denotes a cross subsetting. Semantically, it is no different from a regular subsetting, but it is used to specifically denote the cross-navigation features of the two connected types – the features that can be used to “hop over the connection” to the other side. In this case, “sleigh” crosses “reindeer.pulling”, which means that when a sleigh and a reindeer are connected with a harness, the sleigh can be accessed through the reindeer’s “pulling” feature. Similarly, the reindeer pulling the sleigh will be a value of the sleigh’s “reindeer” feature. With this, we have managed to specify how to populate the usage “pulling” in the definition “Reindeer”, and the usage “reindeer” in the definition “Sleigh”.

If you don’t specify the crossed features, the two ends will still be connected, but there will be no easy way to “navigate” through the connection.

Connection Usages and Reference Subsetting

Once we have the definition, it is time to use it. Note that there is no need to have a connection definition if you don’t want to reuse it in multiple connections. Just like parts and other usages, connections are also fine without a definition.

The model is extended with a part definition to model the context in which the sleigh is being pulled by the reindeer (lines 18–30). Here, we model the “sleigh” and “reindeer” part usages, and apply the pattern from previous lessons to list the reindeer (only Rudolph for now). Then we model the connections on two levels: once generally between the sleigh and the reindeer, and then specifically for each reindeer, once again using the pattern to list the elements.

Line 25 shows the general connection, also showcasing the shorthand notation for connection usages. After the “connection” kind keyword (which declares the connection usage), we can give it a name, which is now “harnesses”. The type is followed by a colon and a reference to the connection definition, as in other usages. There could also be a multiplicity, but that is generally not recommended for connection usages for reasons we are about to discuss. Finally, we see the short body of the connection. The source end is connected to “sleigh” and the target to “reindeer”. And there are two cross multiplicities just before the names of the connected features.

Cross multiplicities are among the less intuitive concepts in SysML, but they are crucial to understand. They do not mean that instances of the connection (called links) are connected to that many elements. Actually, a link always connects a single element on each end. What the cross multiplicity influences is the number of elements we need to connect to a single other element.

In this case, the connection dictates that each sleigh must be connected to nine reindeer, and each reindeer must be connected to exactly one sleigh. Since we have exactly one sleigh and exactly nine reindeer, this will lead to exactly nine links. And this is why it is a bad idea to specify a multiplicity for a connection – the actual number of links will be forced by the cross multiplicities, and if that contradicts the connection’s multiplicity, the model will be invalid.

The figure above illustrates how the cross multiplicities could be violated if the multiplicity of the connected features were not in sync with the cross multiplicities. Here, we have 10 reindeer and two sleighs, totaling 10 links. However, the red dot with the number 1 in it is not connected, violating the constraint that every reindeer must be connected to exactly one sleigh. Similarly, instance number 2 violates the sme constraint by being connected to two sleighs. Finally, instance number 3, which is a sleigh, is connected to only one reindeer instead of the specified nine.

After this short theoretical detour, let’s take a look at the longhand notation as well in line 26. This can be useful when we need more control over the ends. This declaration resembles the connection definition, with both ends redefined to add reference subsettings. A reference subsetting, like the cross subsetting, is semantically just like a regular subsetting, but it has a special role to denote the connected features. An end feature may have multiple subsettings, but there is always a single feature that was meant to be connected. Reference subsetting can be used with any referential feature to denote the referenced feature.

Notice that “sleigh” was defined twice in the scope of the reference subsetting. Because of this, we used a qualified name as explained in Lesson 8.

We also used cross multiplicities in this second connection. In the longhand notation, they come after the “end” keyword. We could have also used them in the connection definition, but that is again not recommended because it would apply to every instance of “Sleigh” and “Reindeer” regardless of whether we model a connection usage or not. It is best to leave the connection definitions unconstrained and specify the end multiplicities in the connection usages.

Challenge for Tomorrow

With this, you are ready to model connections between the entities related to Santa’s Sleigh. It is time to go to Syside Cloud and do the following tasks:

1. Practice connecting things by adding more connections between the reindeer and the sleigh. Experiment with the syntax, try different variations.
2. Model a new connection that will connect Santa to the sleigh. Reproduce the whole pattern from the lesson in the following way:
   • Introduce part definitions for “Person” and “Vehicle”, with referential usages “driving” and “driver”, respectively.
   • Model the connection def “Drives” to connect a person and a vehicle. Ensure the ends cross the relevant usages in “Person” and “Vehicle”.
   • Modify “SantaSleigh” to specialize “Vehicle”, and set the definition of the usage “santa” to “Person”.
   • Model the connection with appropriate cross multiplicities.

Summary

In this episode, you learned about connection definitions and usages. You also learned about the two new kinds of subsetting, as well as cross multiplicities. That’s a lot! 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!