Spaghetti Modeling with MBSE - Formal Mind GmbH (2024)

There are many ways on how to do Model Based Systems Engineering (MBSE) wrong. One of the problems I often see in the field is what I call Spaghetti Modeling.

What is MBSE?

I like the following definition for Model Based Systems Engineering (MBSE) from INCOSE:

MBSE: A formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later lifecycle phases.

INCOSE

Rather than using documents and drawings, we use a more formalized modeling language.

Modeling languages have been around for specific domains for a long time. For instance, a circuit diagram is a model for electronic circuits. However, it’s just for a specific domain, electronics. Systems modeling languages should, in theory, cover all domains and the all lifecycle phases. The currently most popular systems modeling language is SysML.

Why MBSE?

The driver for Model Based Systems Engineering is Systems complexity. Due to the increased used of software, networking and more stringent regulation, systems complexity has been exploding. MBSE is one approach to master this complexity, for instance via a systematic breakdown using the black box / glas box approach.

If done right, MBSE has the potential to drastically improve product development. MBSE is an enabler for change management, automation, product lines and much more. But it comes at a cost and deployment of MBSE is risky, as it requires a high upfront investment. And it often goes wrong…

Spaghetti Code

Spaghetti code is a term from software development that appeared in the 1970s. It referred to unstructured and difficult to maintain code. Sadly, even today, we find lots of spaghetti code everywhere. Anybody who ever had to work on a legacy software project knows this.

Spaghetti code is caused by many things, including volatile project requirements, lack of programming style rules, and software engineers with insufficient ability or experience.

Volatile requirements, lack of style rules, insufficient experience… sounds familiar?

Spaghetti Modeling

The reasons that caused spaghetti code are similar to those creating spaghetti models. Even though SysML has been around for over 20 years, it is not that widely used. Organizations that don’t understand the importance of structure let teams figure things out on their own, instead of providing their employees with proper training, leading to lack of methodology and inexperienced practitioners.

And modeling is at least as complex/complicated as programming. Consider using SysML with Cameo:

• SysML includes 9 diagram types, that can be used (and abused) in many different ways
• Cameo Systems Modeler has approximately 200 menu entries, including various options for customization and functionalities for simulations and analyses.
• The SysML metamodel defines over 50 different types of elements, including blocks, value properties, constraints, activities, actors, and more.
• Compund that with around 20 predefined stereotypes, such as «block», «constraint», «requirement», «testCase», «problem», etc. Plus the ones that you define yourself.
• Even though MBSE should always been tailored and customized, a typical SysML diagram typically includes up to 30 different diagrammatic elements, such as actions, activities, states, blocks, ports, lifelines, fragments, and others.
• Back to the tooling: Cameo offers over 100 customizable parameters and settings for diagrams, model elements, and project configurations.

What Can We Learn From Software Development?

While we still encounter spaghetti code, it has gotten much, much better. Why?

• Extensive use of libraries: Nobody in their right mind would program a linked list from scratch, because we can use a library instead. And library code these days is of extremely high quality.
• Using established architecture: There is a limited number of software “types”: Web application, embedded controller, mobile app, first person shooter, etc. Each application type these days has a small number of recommended architectures. The tooling and libraries make it easy to use the architecture.
• Design Patterns: Related to architecture, one level down, well-established design patterns provides a structured way to solve common programming problems.
• New programming paradigms: Paradigms like object oriented programming, aspects, and the like do not allow programming anything new. Rather, they support the programmer to write maintainable code.

Abandoning the “GOTO” statement helped to drastically reduce spaghetti code. New paradigms (procedures, conditionals and repetition clauses) offered alternatives.

A case against the GO TO statement, Edsger W.Dijkstra

• Tool support: Modern programming tools provide feedback on code quality while programming. This goes beyond spaghetti code: Linting points out all kinds of problem related to code smell.
• Automated Testing: Writing automated tests, including unit tests, integration tests, and end-to-end tests, ensures that code changes do not introduce new bugs.
• Code Reviews and Pair Programming: Regular code reviews and pair programming practices ensure that multiple eyes review the code, catching potential issues early and ensuring that the code adheres to best practices and is easy to understand.

How to Prevent Spaghetti Modeling

Some of the idas from software development are already applied to systems modeling. The aspects of architecture and design patterns manifest themselves in methodologies, to a degree.

Methodologies provide guidance with respect to model architecture, design and best practices when modeling in general. Examples include MagicGrid from Dassault or SYSMOD from Tim Weilkiens. Unfortunately, these are not that accessible. They are available as books with very limited tool support. Just reading the book is not enough, you also need to apply the knowledge to get familiar with it, ideally in a real-world project. Without an experienced modeler in the project there is still the risk of spaghetti modeling.

Other paradigms, like reviews and pair modeling, could also be applied right away. However, this requires a budget. It took a long time in programming to convince decision makers that these practices are a good long term investment. With MBSE, we still have problems convincing them of many other, much more mundane expenses (like tools and training).

Biggest Problem: Purposeful Modeling

The biggest problem I see in practice is the lack of specific purpose. The unspecific purpose is usually to save time, increase quality, and to decrease cost of change and reuse. But how can we achieve this specifically? In software development, this is fairly straightforward, as the biggest deliverable is running software. But what is the deliverable of MBSE?

MBSE is several steps away from the actual product, which makes it much more tricky to demonstrate usefulness and to make it purposeful. The best approach is to identify specific, value-adding use cases. Then we need to ensure that the model supports those use cases effectively. Conveniently, here is a list of 18 ideas that can act as a starting point for identifying those use cases.

For instance, consider document generation. You can read this article on document generation from UML models that provided significant value to the team by improving stakeholder communication. Having a clear purpose of the modeling made it much easier to tailor the tooling to support the activities in question.

How to get started?

Here is a checklist to help you prevent spaghetti modeling. Your mileage might vary depending on how far you are with your MBSE implementation:

• Understand the purpose of MBSE in your specific situation. You should have some high-level goals, e.g. “being compliance ready”. Then identify specific use cases that support that high-level goal. Ideally, they are quantifiable, so that you can measure success.
• Make yourself familiar with methodologies and pick one suited for your situation. Pick those elements of the methodology that are relevant for your situation.
• Pick a tool, if one has not yet been decided on. While there are the “usual suspects” (IBM Rhapsody, Dassault Cameo and Sparx Enterprise Architect), there are many others. Often the alternatives are simpler to use and cheaper, but also much less powerful. Pick wisely and keep your long-term goals in mind, as tool switching is difficult.
• Get outside help if possible. While you may have a very smart team, it is advisable to have someone from outside, who can spot issues to which your organization is “color-blind”.
• Involve all relevant stakeholders from the very beginning. You need the decision maker on board (MBSE is expensive), your team (they must use it), corporate IT (they must support the modeling tool), and so on.

Conclusion

Model Based Systems Engineering is a high-risk, high-reward technology. Due to the required high up-front investment, many decision makers shy away from it. Risks like spaghetti modeling or Ivory Tower Modeling are real. But understanding the risks is the first step in mitigating them. Use the checklist from this article to be as good prepared as possible.