Economics 101: UML in Embedded Systems

share on: 
Cartoon: Economics 101
Table of Contents

With UML, just as with anything else in the embedded space, the ultimate criterion for success is the return on investment (ROI). Sure there are many factors at play, such as “coolness factor”, yearning for a “silver bullet” and truly “automatic programming” all fueled by the aggressive marketing rhetoric of tool vendors. But ultimately, to be successful, the benefits of a method must outweigh the learning curve, the cost of tools, the added maintenance costs, the hidden costs of “fighting the tool” and so on.

ROI and Code Generation

As it turns out, the ROI of UML is lousy unless the models are used to generate substantial portions of the production code. Without code generation, the models inevitably fall behind and become more of a liability than an asset. In this respect I tend to agree with the “UML Modeling Maturity Index (UMMI)“, invented by Bruce Douglass. According to the UMMI, without code generation UML can reach at most 30% of its potential, and this is assuming correct use of behavioral modeling. Without it, the benefits are below 10%. This is just too low to outweigh all the costs.

"High Ceremony" == High Costs

Unfortunately, code generation capabilities have been always associated with complex, “high ceremony” UML tools with a very steep learning curve and a price tag to match. With such a big investment side of the ROI equation, it’s quite difficult to reach sufficient return. Consequently, all too often big tools get abandoned and if they continue to be used at all, they end up as overpriced drawing packages.

So, to follow my purely economic argument, unless we make the investment part of the ROI equation low enough, without reducing the returns too much, UML has no chance. On the other hand, if we could achieve positive ROI (something like 80% of benefits for 10% of the cost), we would have a “game changer”.

The Biggest Bang for the Buck

To this end, when you look closer, the biggest “bang for the buck” in UML with respect to embedded code generation are: (1) hierarchical state machines (UML statecharts) and (2) an embedded real-time framework (RTEF). Of course, these two ingredients work best together and complement each other. State machines can’t operate in vacuum and need an event-driven framework to provide execution context, thread-safe event passing, event queueing, etc. Framework benefits from state machines for structure and code generation capabilities.

The Role of the Framework

I’m not sure if many people realize the critical importance of a framework, but a good framework is in many ways even more valuable than the tool itself, because the framework is the big enabler of architectural reuse, testability, traceability, and code generation to name just a few. The second component are hierarchical state machines, but again I’m not sure if everybody realizes the importance of state nesting. Without support for state hierarchy, traditional “flat” state machines suffer from the phenomenon known as “state-transition explosion”, which renders them unusable for real-life problems.

Changing the Game

As it turns out, the two critical ingredients for code generation can be had with much lower investment than traditionally thought. An event-driven, real-time framework can be no more complex as a traditional bare-bones RTOS (e.g., see the family of the open source QP frameworks). A UML modeling tool for creating hierarchical state machines and production code generation can be free and can be designed to minimize the problem of “fighting the tool” (e.g., see QM). Sure, you don’t get all the bells and whistles of IBM Rhapsody, but you get the arguably most valuable ingredients. More importantly, you have a chance to achieve a positive ROI on your first project. As I said, this to me is game changing. Can a lightweight framework like QP and the QM modeling tool scale to really big projects? Well, I’ve seen it used for tens of KLOC-size projects by big, distributed teams and I haven’t seen any signs of over-stressing the architecture or the tool.


2 Responses

  1. It’s quite funny that you post this right now. I’m having some discussions on the usefulness of IBM Rhapsody for our projects. Some developers indeed see it only as a very overpriced drawing tool for UML charts. The code generation feature is only used for very basic things (like classes and their associations).

    I’m really new to Rhapsody and haven’t had a training course, so I’m quite lost at the moment and end up fighting with the tool (it’s not intuitive is it?). I currently don’t feel as productive as I could be without Rhapsody.

    So at the moment I’m really asking myself how efficient can you get with Rhapsody and is it really worth it. Maybe I should buy a copy of your book to get a different view on UML and the benefits of it…

    Also if I want to start to argue against the use of Rhapsody I should probably create a not so simple project and demonstrate the benefits of a different way like your QM/QP. Are you familiar with SIL (IEC 61508) and can you comment on how well the requirements can be covered with QM? (actually I’m not very familiar with it so I can’t really spell out what I’m looking for, probably a bad place to start)

    1. First, I’d like to note that the QM tool is not in the same class of “big tools” as IBM Rhapsody. QM has no support for requirements management or use cases. QM’s role begins in the design stage.

      Currently, QM supports packages, classes, class inheritance, class attributes, class methods, and state machines associated with classes. State machines are supported in graphical way, and I believe that drawing hierarchical state machines in QM is a lot easier than in Rhapsody and they look better in QM. A lot of thinking and work has been done in QM to respect the designer’s preferences on attachment points and routing of transitions, placement of labels, and even sensitivity of the background in nested states. You simply need to try both QM and Rhapsody to appreciate that in QM you don’t need to “fight the tool” every step of the way.

      Also, with QM you are much closer to the code. Any code that you enter into the QM model (and every model regardless of the tool has a lot of textual information, such as actions executed by state machines) is in C or C++, depending on your initial choice of the framework. No indirections of an “Action Language” is used.

      The code organization and generation in QM is also fundamentally different than Rhapsody (Please see my previous post “Turning Automatic Code Generation Upside Down”). Again, the main goal in designing this feature was to minimize “fighting the tool”. In QM, you ask the tool to generate elements of your code, where you believe that the tool can help. But otherwise you can keep the tool out of your way in places that it does not add value. You don’t need to tweak hundreds of parameters of code generation.

      Regarding the safety standards, QM provides no formal, built-in support for IEC 61508, the various SILs, or IEC 26262. But, at the same time there is nothing, which would prevent you from developing compliant designs and code with QM. The strength of the QM tool relies to a large degree on the underlying QP frameworks, which very favorably compare with the frameworks supported by Rhapsody (such as OXF). The QP frameworks have been recently updated to a high level of compliance with MISRA-C:2004 (QP/C and QP-nano) and MISRA-C++:2008 (QP/C++). The Application Notes and MISRA Compliance Matrices ( ) provide the ready-to-use quality system with automated rule checking and test–a huge time saver for anyone interested. The QP frameworks provide also strong support for testing through the built-in QS (Quantum Spy) tracing instrumentation.

      In summary, the right choice of a tool for you depends on the features you actually end up using. If you only end up using diagramming, you don’t need Rhapsody or even QM–you need a “simple drawing tool”. If you seriously think of code generation, QM will provide you exactly this at much lower cost than Rhapsody. Only if you seriously think you will use more than this, Rhapsody could be the right choice. From my experience, however, very few teams reach that level of sophistication.

Leave a Reply