Spaghetti modeling with MBSE: Not like this!

There are many ways to make mistakes when using Model Based Systems Engineering (MBSE). One of the problems I often see in practice is what I call spaghetti modeling.

What is MBSE?

I have often talked about MBSE written. Here is a good definition of INCOSE:

MBSE: A formalized Application of modeling for Support the system requirements, design, analysis, verification and validation of activities performed in the Concept phase start and learn about the entire development and later life cycle phases.

INCOSE

Modeling languages have existed for certain domains for a long time. One Circuit diagram for example, is a model for electronic circuits. However, it is only suitable for a specific domain, namely electronics. System modeling languages should theoretically cover all domains and all life cycle phases. The currently most popular system modeling language is SysML.

Why MBSE?

The driver for model-based systems engineering is the complexity of systems. Due to the increasing use of software, networking and compliance, the complexity of systems has exploded. MBSE is an approach to mastering this complexity, e.g. through systematic decomposition according to the Black box/glass box approach.

When done right, MBSE has the potential to dramatically improve product development. MBSE is an enabler for change management, automation, product lines and much more. But it comes at a price, and using MBSE is risky as it requires high upfront investment. And it often goes wrong...

Spaghetti code

Spaghetti code is a term from software development that emerged in the 1970s. It referred to unstructured software code that was difficult to maintain. Unfortunately, we still find a lot of spaghetti code everywhere today. Anyone who has ever had to work on a legacy software project knows this.

Spaghetti code has many causes, including inconsistent project requirements, lack of coding style rules and software engineers with insufficient skills or experience.

Volatile requirements, lack of style rules, lack of experience... sound familiar?

Spaghetti modeling

The reasons that led to spaghetti code are similar to those that lead to spaghetti models. Although SysML has been around for over 20 years, this modeling language is still not widely used (at least compared to programming languages). Organizations that don't understand the relevance of structure leave their teams to figure things out on their own instead of properly training their employees, leading to a lack of methodology and use of inexperienced employees.

And system modeling is at least as complex/complicated as programming. Let's take a look at the use of SysML with Cameo in more detail:

• SysML includes 9 diagram types that can be used (and misused) in many different ways.
• The Cameo Systems Modeler has around 200 menu items, including many options for customization and functionalities for simulations and analyses.
• The SysML metamodel defines over 50 different types of elements, including blocks, properties, constraints, activities and more.
• In addition, there are around 20 predefined stereotypes such as "Block", "Constraint", "Requirement", "Test Case", "Problem", etc. Then there are the stereotypes that we define ourselves.
• Even though MBSE should always be customized and adapted, a typical SysML diagram contains up to 30 different diagram elements.
• Back to the tools: Cameo offers over 100 customizable parameters and settings for diagrams, model elements and project configurations.

What can we learn from software development?

Even if we still find spaghetti code in the software, it has become much better. Why?

• Wide 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 is of extremely high quality these days.
• Use of an established architecture: There are a limited number of software "types": web application, control device, mobile application, first-person shooter, etc. For each type of application, there is nowadays a small number of recommended architectures. The tools and libraries facilitate the use of the architecture.
• Design pattern: Similar to architecture, but one level deeper, established design patterns offer a structured way to solve common programming problems.
• New programming paradigms: Paradigms such as object-oriented programming, aspects and the like do not enable new functions; rather, they support the programmer in writing maintainable code.

Dispensing with the "GOTO" instruction helped to drastically reduce the 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 during programming. This goes beyond spaghetti code: Linting points out all kinds of problems related to "code smell".
• Automated tests: Writing automated tests, including unit tests, integration tests and end-to-end tests, ensures that code changes do not introduce new errors.
• Code reviews and pair programming: Regular code reviews and pair programming ensure that the code is reviewed by multiple people to identify potential problems early and ensure that the code complies with best practices and is easy to understand.

How we can avoid spaghetti modeling

Some of the ideas from software development are already applied to system modeling. The aspects of architecture and design patterns manifest themselves to a certain extent in the methodologies.

Methodologies provide guidelines for model architecture, design and best practices in modeling. Examples of this are MagicGrid from Dassault or SYSMOD by Tim Weilkiens. Unfortunately, these are not particularly accessible. They are available as books with very limited tool support. It's not enough to just read the book, you need to apply the knowledge to familiarize yourself with it, preferably in a real project. Without an experienced modeler in the project, there is still a risk of spaghetti modeling.

Other paradigms, such as reviews and pair modeling, could also be applied immediately. However, this requires a budget. In programming, it has taken a long time to convince decision makers that these practices are a good long-term investment. In MBSE, we still have trouble convincing them of many other, much more mundane expenses (like tools and training).

Biggest problem: Targeted modeling

The biggest problem I see in practice is the lack of a clear goal. The unspecific goal is usually to save time, increase quality and reduce the costs of changes and reuse. But how can we achieve this in concrete terms? In software development, this is quite simple, as the most important result is working software. But what is the result of MBSE?

MBSE is several steps removed from the actual end product, which makes it much more difficult to demonstrate its usefulness and make it fit for purpose. The best approach is to identify specific, value-adding use cases. Then we need to ensure that the model effectively supports these use cases. On a practical note, a long time ago I already had a List of 18 ideas which can serve as a starting point for identifying these use cases.

Take the generation of documents, for example. This article deals with the generation of documents from UML modelswhich added significant value to the team by improving communication with stakeholders. As the purpose of the modeling was clear, it was much easier to tailor the tools to support the activities in question.

How do I get started?

Here's a checklist to help you avoid spaghetti modeling. The value of course depends on how far along your team is with the MBSE implementation:

• Understand the purpose of MBSE in your specific situation. Your team should have some overarching goals, e.g. "be ready for proof of compliance". Then identify specific use cases that support this overarching goal. Ideally, these are quantifiable so that you can measure success.
• Familiarize yourself with the methodologies and select one that is suitable for your situation. Choose the elements of the methodology that are relevant to your situation.
• Decide on a toolif none is set yet. There are the "usual suspects" (IBM Rhapsody, Dassault Cameo and Sparx Enterprise Architect), but there are also many others. Often the alternatives are easier to use and cheaper, but also much less powerful. Choose wisely and keep your long-term goals in mind, because changing tools is costly.
• Get help from outsideif possible. Even in a competent team, it is advisable to bring in someone from outside who can identify problems for which the organization is "colour-blind".
• Involve all relevant stakeholders right from the start. We need the decision maker on board (MBSE is expensive), the team (they need to use it), the company's IT department (they need to support the modeling tool), and so on.

I help too!

And at this point the obligatory "on my own behalf": the introduction of MBSE is one of the activities that I have been implementing more and more frequently with my company Formal Mind GmbH in recent years. Interested? Then arrange a non-binding meeting to get to know each other.

Conclusion

Model-based systems engineering is a high-risk, high-reward technology. Due to the high initial investment required, many decision-makers shy away from it. Risks such as spaghetti modeling or Ivory tower modeling are real. But understanding the risks is the first step to mitigating them. Use the checklist in this article to be as prepared as possible.