Keeping an overview: The inheritance hierarchy of SysML v2

The SysML v2-Spec with 691 pages is not for the faint-hearted. Nevertheless, it is an excellent reference work. But as such, you only recognize certain connections when you work through it more thoroughly. One aspect helped me enormously: The inheritance hierarchy of types. For example, many people who work with SysML v2 know that a Part a specialized Item is. But I didn't realize that a Use Case indirectly also a Action is. And understanding that is useful.

In the following, I will explain what else we can learn from the inheritance hierarchy of SysML v2. And in clear language.

Teaser: I am working with SodiusWillert on a 4-page cheat sheet for SysML v2, which will be published later this year. It will also include a diagram that visualizes the concepts described here.

Reminder: What should SE-Trends donate to in your name? Vote on LinkedIn for one more week >>

KerML as a starting point: Behavior, Structure and Data Type

Many texts on SysML v2 point out the importance of Occurrence Everything in SysML v2 that we work with on a daily basis is in fact an Occurrence.

What is not obvious, however, is that some elements of SysML v2 have additional parent elements from the KerML, the Kernel Modeling Language on which SysML v2 is based. And this multiple inheritance is revealing because it makes the intention of the elements more transparent.

In concrete terms Part, Item and Port also specializations of Structure, which, in my opinion, better expresses what we are doing, namely describing the structure of our system.

The counterpart to Structure in KerML is therefore Behavior, which is the root of the elements that model behavior, such as Action, Calculation and Flow.

Finally, I would like to Attributes which are also not derived from Occurrence, but are specializations of the KerML Data Type. There are also specializations of AnnotatingElement, how Metadata, Comment or Documentation.

The boundary between KerML and SysML v2

This hopefully clarifies why Occurrence plays such an important role in SysML v2: as the root element, it is the anchor point of the language. However, it helps to understand KerML, even if this is not necessarily visible.

Here again the connection between SysML v2 and KerML:

SysML v2 is based on KerML. KerML provides the basic building blocks with which technical systems can be formally described. SysML v2 uses these elements and places a layer on top of them to define the SysML v2 modeling language. KerML is therefore the foundation, SysML v2 the modeling system that builds on it and is intended for everyday work.

In practice, we would therefore not include Behavior Usage in SysML v2 in our model. However, it still helps enormously to know the family tree of the elements.

A closer look at the inheritance hierarchy of SysML v2

Now that we have clarified how the inheritance of KerML elements affects SysML v2, here is a list of relationships that are surprising at first glance and will hopefully help with modeling:

A viewpoint is a requirement, is a constraint

Requirements play an important role in systems engineering and are correspondingly powerful in SysML v2. In particular, this means that we can formalize them so that they can later be better integrated into our system than would be possible with textual requirements.

What I find remarkable, however, is that to this end they have developed a specialization of Constraint are. A constraint is a condition that specifies what is allowed and what is not. It defines a rule or restriction that must always apply for something to count as correct. In SysML v2, a constraint is just such a rule, only formally described and anchored directly in the model. It defines which values, relationships or states are permitted so that the model remains consistent and subsequent errors are avoided.

It is also worth noting that a viewpoint is also a requirement. A viewpoint describes which elements are to be shown, how they are filtered or structured and what the view is used for so that different stakeholders can assess the system in a targeted and consistent manner.

But that is precisely the nature of a requirement If a viewpoint is defined as a specialized requirement, it can be versioned, checked, tracked and validated just like any other requirement. This means that the required viewpoint is not just an informal idea, but a verifiable part of the model.

A use case is a calculation

A Use Case in SysML v2 is first of all a Case, whereby there are also the specializations Verification Case and Analysis Case exists. In SysML v1, we already treated use cases similarly to activities, i.e. we broke down use cases by modeling them as activities. In SysML v2 there are only Actions and it is not surprising that a use case is an action. What I do find surprising, however, is that this relationship is indirect:

Because a Case is a specialization of Calculation, which, in turn, is a specialization of Action is. And as we have seen above, a Calculation (and Case) is therefore a specialization of the KerML element Behavior, Action, however, is not a specialization of Calculation.

The specialization of Case as Calculation makes sense, as the central feature of a calculation is the mandatory provision of a result. This also applies to Case. This focus on results is necessary, not only for the use case: a Analysis Case must return a result about the subject, a Verification Case must make a judgment.

Metadata is an item

SysML v2 provides various methods for adding elements with additional Metadata to provide. This is a specialization of AnnotatingElement, but at the same time a Item. This means that a metadata element is not just a loose annotation, but a fully-fledged model object with identity, type, relationships and lifecycle. If we are aware of this, we can find many useful applications for metadata.

It can be confusing that Comment and Documentation also specializations of AnnotatingElement but do not specialize items at the same time. Metadata is therefore much more powerful than Comment, although it behaves similarly as an annotating element.

An allocation is a part

One Allocation appears at first glance to be a simple relation, albeit an important one. However, in SysML v2 it is a real structural element, via Connection from Part inherited. This means that an allocation can not only be declared, but also actively integrated into the model.

This architectural approach allows modelers to not only declare the allocation as an abstract assignment, but to actively integrate it into the model, refine it and add their own features to describe exactly how the allocation is realized.

Conclusion

The inheritance hierarchy of SysML v2 is a blessing and a curse. The structures are well thought out, but not always easy to penetrate. Added to this is the relationship to KerML. I hope this article has helped you not to get lost in the details, but to keep an eye on the big picture.