Software — the Elephant in the MBSE Living Room
“… an important or enormous topic, question, or controversial issue that everyone knows about but no one mentions or wants to discuss because it makes at least some of them uncomfortable …”
[Wikipedia, The elephant in the living room]
Abstract
Software is ubiquitous in modern systems, yet popular MBSE processes and frameworks don’t consider it in much depth. Why don’t more people in the MBSE community talk about software? For many systems engineers and process designers, software is not their specific area of expertise. But software is present in virtually all SysML behavior models and accounts for a preponderance of the complexity and cost of many of them.
In this paper, we review SysML Behavior models, examine the difference between embedded and non-embedded software, propose some requirements for generating useful code from MBSE models, and illustrate these requirements by example. Finally, we propose some use cases for using code generation in an iterative MBSE development process, and introduce the pattern of Model-Generate-Test.
Introduction
The MBSE living room has been occupied by an elephant named “software” for quite some time, yet nobody talks about it very much. Why don’t more people in the MBSE community talk about software? For many systems engineers and process designers, software is not their specific area of expertise. But software is present in virtually all SysML behavior models and accounts for a preponderance of the complexity and cost of many of them.
Figure 1 comes from a presentation I made back in 2013 on Modeling Software Intensive Systems at the No Magic World Conference in Dallas. But the software elephant had been identified some 30 years previously, in 1976, in Barry Boehm’s landmark paper Software Engineering. If you squint at Figure 2 just right, you can see the elephant’s forehead.
To examine why MBSE is so software-intensive, we need to dig into the behavior models defined in SysML. I’ll then propose a method to tie the software engineering aspect of MBSE to the system model in a productive and beneficial way.
SysML Behavior Models
The SysML language consists of nine diagram types, four of which describe system behavior.
Behavior Models in SysML generally start with Use Cases. These are the top level scenario descriptions that describe how the users of a system (Actors) interact with the hardware and software that comprises the system of interest. Use Cases are typically elaborated on either Activity or Sequence diagrams, which detail the behavior of the scenario as a sequence of steps.
Both Activity and Sequence Diagrams can describe a combination of synchronous and asynchronous behavior. When dealing with asynchronous behavior (typical of event-driven systems), communication is accomplished using Signals. Activity Diagrams use Send Signal and Accept Event elements, while Sequence Diagrams show Messages, where each Message combines Send and Accept into a single model element.
Signals tie the various elements of the Behavior Model together, since a Signal element functions as a Trigger for a State Transition. In fact, Signals also tie the Behavior Model to the Structure Model, since Blocks can have Signal Receptions, and Flow Properties on Interface Blocks can be typed by Signals. But for the moment, let’s keep our focus on the Behavior Model. What’s of particular interest is that not only do Signals serve as Triggers that cause State Transitions to fire, but each Transition can have a Transition Effect, which can be another Activity or Sequence Diagram. The full syntax for a State Transition is Trigger [Guard] / Effect, where the Transition Effect is generally detailed on its own diagram.
To make matters even more interesting, State Machines can contain both External Transitions (which go from State to State) and Internal Transitions (in reality not Transitions at all, but they follow the same syntax), which can happen within a State. And, of course, State Machines are hierarchical, so we can have sub-states within states, and sub-substates within sub-states, etc.
Internal Transitions can allow any state to respond to a Trigger Event (Signal) and each state has some predefined Internal Transitions, specifically Entry, Exit, and Do behaviors. Entry behaviors happen on entering a state (initialization), Exit behavior on exiting a state (cleanup) and the Do behavior happens in between entering and exiting.
Combining the various behavior diagrams together allows virtually any combination of synchronous and asynchronous behavior to be represented in SysML. Much of this behavior is destined to be realized in software. Thus, it’s interesting to consider generating code from SysML models.
Embedded vs. Non-Embedded Software
Often, when thinking about generating code from SysML models, people focus on generating the embedded software from the model, and fail to consider that much of the software, even in an embedded system, is not embedded code.
Embedded software is software that is written to control a specific device or piece of hardware. It is typically designed to run on a specific type of microprocessor or microcontroller, and it is closely integrated with the hardware it is running on.
Examples of non-embedded code would include things like scheduling software, navigation software, telemetry software, monitoring software, image processing software, mapping software, command and control software, communication software, networking software, machine learning software, inventory management software, user interface software, calls to 3rd party APIs, general algorithmic logic, database management software, security software, simulations (beyond SysML Parametrics) and test software, just to name a few.
If you’re building a software-intensive system, you’re going to have more software than the embedded parts. This software still has to comply with Requirements from your SysML model, so it doesn’t make sense to develop it in a completely separate environment, with no traceability back to the Requirements. It’s contrary to the whole philosophy of MBSE. And yet, that’s typically what happens across the industry.
We can list a few characteristics that are common to a lot of non-embedded software, and this list can be instructive in guiding us towards code-generation solutions from MBSE models. Not all software has all of these characteristics but they are all relatively common.
· Many software systems have a database, and need to store information, retrieve information, search for information, etc.
· Many software systems have security and authentication requirements. You can’t have someone hacking into a safety-critical system.
· Many software systems have a user interface, often a graphical user interface.
· Many software systems will integrate with other software, often through a REST API.
What kind of code can be generated from a SysML model?
Given the ubiquity of databases, security features, user interfaces, and REST APIs, it’s a reasonable question to ask whether these kinds of software can be generated from SysML/UML models.
In short, the answer is YES! They can all be generated from SysML models. So, what would the requirements for such a code generator look like?
Requirements for an MBSE Code Generator
We can begin by turning the items listed above into Requirements. We’d like our code generator to create database access functions and user interfaces, do that in a secure manner, and allow access to external APIs.
Those requirements are pretty high level, so we can add some detail.
Support for Domain Driven Design. We’d like to support a couple of software engineering paradigms that are both popular because they are useful. The first is Domain Driven Design, made popular by numerous authors, but in particular in a book written by Eric Evans. The basic premise of DDD is that requirements, use cases and software features all change more rapidly than the problem domain does, so basing your software abstractions on a model of the problem space (aka “domain model”) is generally the most stable set of abstractions we can find.
Typically, these abstractions will form the underlying data model (database architecture) for a software system, and are generally modeled on Class or Block (BDD) diagrams. Processes like OOSEM include a step for “Modeling the To-Be Problem Domain” so your MBSE process probably already includes an activity for producing a domain model. Note that sometimes this domain modeling step is confused with drawing a context diagram for the system, which is useful but different from domain modeling.
We can generate database tables (or collections if you’re using a NoSQL database) for each Block on the domain model, where the class attributes (or block values) form the columns of the table. For each collection in our database, we can code generate the basic Create, Read, Update, Delete (CRUD) functions as well as a variety of search/query functions. All of these functions can (and should) be wrapped in a REST API for easy programmatic access.
Security and Authentication issues generally revolve around access to data, and thus the generated database code should support both Role Based Access Control (RBAC) and Attribute Based Access Control (ABAC).
Support for Use Case Driven Development. As we saw earlier, SysML Behavior Models are already driven from Use Cases at the top level. So if we’re going to realize these Behavior Models in software, it certainly makes sense to approach the software engineering from a use case driven perspective. A useful reference text on this topic is the book I wrote with Matt Stephens, Use Case Driven Object Modeling with UML — Theory and Practice, which treats the topic comprehensively.
The original theory of use case driven object modeling involves applying a software design pattern called model-view-controller (MVC) to each use case, where the model part of the use case is represented by objects from the domain model, and the view part of the use case is generally represented by some screens (sometimes called boundary objects).
Given the advent of “low code” generators that can produce user interface code from wireframes, and the availability of wireframe diagrams in SysML modeling tools like Cameo Systems Modeler and Sparx Enterprise Architect, we can think of a wireframe as another way to elaborate a use case. So you might have a use case that is elaborated by an Activity Diagram which describes its logic step-by-step and also have a wireframe “inside” the use case that shows what the screen(s) will look like. We can then generate the user interface code for the screens from the wireframes inside the use cases.
The screens connect to the database via the generated API, and this can be easily accomplished by linking the wireframe to a domain object using a <dependency> connection.
In Figure 14, the username, password, and email fields on the Register page are stored in the User collection in the database, and the Register button links to the generated API endpoint. Because both the database and the user interface code are generated from the same SysML model, the linkages can be made automatically in the generated code.
Support for rapid-iteration Agile and DevOps.
A key development in the evolution of modern software engineering is the idea of evolutionary development enabled by short iterations and automatic deployment. This concept goes by various names including agile, continuous-integration/continuous-deployment (CI/CD), and DevOps.
In order to support rapid iteration and a feedback-driven, agile development process, it’s extremely helpful if the generated code can be automatically deployed. An example of this is shown in Figure 16, where a MERN Stack application (Mongo DB, Express JS, React JS, Node.js) application has been generated and deployed for immediate testing.
Use Cases for MBSE Code Generation
We can illustrate the MBSE code generation approach as a series of use cases. Figure 17 describes an iterative and incremental approach to generating code from SysML models. We start with a simple diagram, generate some code, test the generated code, update the model and repeat the process. Note that since the code is automatically generated, we can immediately focus on acceptance testing the generated output, and don’t have to laboriously follow the TDD process of “write the unit test, make the test fail, write some code to make the test pass, run the code to make sure the test passes” but instead our process is “generate the code, acceptance test the code, update the model”. In short, Model-Generate-Test.
Note also that updating the model is a collaborative effort between system engineers and software engineers, and testing the generated code is a collaborative effort between test engineers and software engineers. It’s also important to note that the iterative cycle described here can be performed on a per-use case basis. So you can effectively start with a use case and its wireframes, and iteratively adjust both the user interface and the underlying database it connects to by updating the model.
Importantly, the iteration time between updating the model and testing the generated code is (worst case) a matter of a few minutes, and (best case) a matter of just a few seconds. So the code generator becomes, in effect, a SysML compiler that generates databases, APIs and, if desired, user interface code (or more accurately, complete web applications that include database, screens and an API that connects them).
