SysML: Avoid spaghetti models with the right package structure

It is amazing how quickly the number of elements in a system model grows. It is therefore essential to structure them correctly from the outset. Otherwise we quickly end up with "spaghetti models". This refers to models that look like a ball of spaghetti and are therefore difficult to understand. But almost all modeling languages, including SysML, give us the option of structuring the models. In SysML, we do this with the right package structure.

The model tree

Two weeks ago, I presented a simple SysML modelthat showed the interaction between socket, charger, cable and smartphone. At first glance, it appears to be a small model consisting of just a few dozen model elements. But the unfolded model tree is frighteningly large. This is because the parts that hold the model together (relations, etc.) also appear in the model tree. Here is the model tree, hopefully correctly embedded with scrollbar:

I created this model with Cameo/MagicDraw. But it looks similar with other tools (Rhapsody, Enterprise Architect).

Why we need structure

If even such a small model already consists of so many elements, then hopefully it is clear why we need a good model structure. The right structure enables and improves readability, understanding, maintenance, teamwork and much more.

In SysML, there is the package element, which we can use to structure. In principle, a package is nothing more than a folder that can contain additional elements. Packages can be nested to any depth. The whole thing is very similar to a folder on a file system.

However, the package structure not only enables organization, but also actively contributes to the modelling process. For example, we often use packages to specify a scope. For example, we could create a table that lists the properties of ports that are contained one or more levels deep in the package.

Caution: In addition to the package, other elements can also have recursive children, for example blocks. However, the package offers the greatest degree of freedom in terms of what can be included.

Other element types also allow the creation of children of the same type and thus nesting of any depth. There are also many variants.

Spaghetti code and spaghetti models

The term Spaghetti code comes from programming and is a derogatory term for poorly structured software code. Although spaghetti code usually works, it can contain an above-average number of bugs and is difficult to maintain.

The same applies to spaghetti models: they are poorly structured, can contain an above-average number of errors and are difficult to maintain. Spaghetti code is at least an "end product" and (hopefully) does something useful. But it's worse with spaghetti models, since they are an artifact that is supposed to help create the final product. But if it does not reliably support this activity, then it is ignored. Or worse, the errors it contains can lead to expensive rework.

Working with a proven package structure

Fortunately, many experts have already thought about this problem and made suggestions for the package structure. The structure published under SYSMOD comes from Tim Weilkiens. One short, albeit outdated introduction he has published in his blog. However, if you want to use SYSMOD, you should definitely refer to the current and much more extensively documented package structure from the SYSMOD book to fall back on.

Another good package structure is in the MagicGrid book to find. The example of the charger linked above uses the MagicGrid structure.

What all the recommended structures have in common is that they can be nested recursively in order to consistently map the levels of development.

Inclusion and references

A further complication arises from the fact that there is no specification for references as to where they must come from. This is different from containment, where elements belong firmly to a superordinate one.

Here is an example. In the following ibd we see a part of the model tree on the right. There you can see that the loading context contains four parts (Parts, P). These parts have no name (no text before the colon), but are typed. The types are smartphone, socket, charger and user.

Of course, we can search for the referenced elements relatively easily in all tools in order to find them in the model tree. However, a good package structure makes sense here.

Conclusion

There are many dangers lurking in modeling. I already described another one a while ago, the Ivory tower modeling. Another danger is the spaghetti models described today. These problems can only be with a reasonable methodology be prevented. And a good package structure is an important part of this.

Photo by Julia Kadel on Unsplash