Parallel Agile
Software: The Elephant in the MBSE Living Room
Doug Rosenberg
doug@parallelagile.com
An important or enormous topic that no one mentions
“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]
SysML Behavior Models are realized in 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.
Most systems are mostly software
Software is a large elephant that dominates the cost of developing systems
Boehm: Software Engineering. 1976
(If you squint a little you can see that this is actually the elephant’s forehead)
Boehm: Software should be an engineering discipline
(Note: this is not agile/scrum)
Behavior Models in SysML start with Use Cases
Use Cases are typically elaborated on either Activity or Sequence diagrams, which detail the behavior of the scenario as a sequence of steps.
We understand how to drive software designs from use cases
However, typical practice in MBSE is to skip writing the use cases and jump straight to activity diagrams, and to follow a functional decomposition approach instead of OOD. And to ignore the fact that most of the system behavior will include software.
Communication by Signals is key to modeling asynchronous behavior
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.
Transition effects are activities which trigger transitions
Which have transition effects which are activities which trigger transitions…
Also states have substates which can have substates
You can model almost any combination of synchronous and asynchronous behavior with SysML behavior models. But mostly people are using activity diagrams as data flow diagrams, while the software is likely object oriented and not functionally designed.
Yet most of the behavior is destined to be realized in software.
In the software field, OOD largely supplanted functional decomposition in the 1990s.
The MBSE community never got the memo.
Not all software is embedded software
Even software intensive systems have lots of software that’s not embedded.
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
We can generate code from SysML models
What makes sense?
Requirements for an MBSE code generator
Let’s start by generating databases and user interfaces.
Executable Domain Models
Object Oriented Design often involves modeling the problem domain. We can generate database tables/collections from Class/Block diagrams, generate the CRUD functions, and wrap those functions in a REST API
Not coincidentally, Executable Domain Models is the PhD research of Dr. Bo Wang
Executable Wireframes
We can draw wireframes inside the use cases, and code generate the UI
Connect the screens to the database
build and deploy MERN stack applications directly from SysML/UML models
DevOps: Generated app automatically deployed
Generated app is immediately available for testing
We can and should generate software from MBSE models
Systems Engineers, Software Engineers and Test Engineers work collaboratively
Generate, Deploy, Test
Thanks for listening
doug@parallelagile.com