At MoDELS 2012, an interesting paper has been published: An Exploratory Study of Forces and Frictions aecting Large-Scale Model-Driven Development by Adrian Kuhn, Gail Murphy and Albert Thompson. It present an empirical study on the problems that currently plague model-driven development in the industry. They have interviewed a number of developers from General Motors who use mainstream model-driven development tools (mostly Matlab/Simulink, IBM Rhapsody and MS Word for Requirements management) for embedded software development. The results are very interesting and worth discussing here, because mbeddr improves on all friction areas identified in the study.

Diffing: Diffing between various versions of the same model is insufficiently supported. Because of the fear to miss a change, developers have resorted to manually written comments that describe each change. Sometimes they even use a textual diff tool on the generated source. In some cases they create screenshots of a new version of a model, mark the changes with a red pen, and send the picture back to the owner of the model to incorporate the changes. When stating their requirements towards model diffing, they suggested that a facility like the diff support for code would be just what they needed.

mbeddr improves on this situation since any model or program can be diffed (and merged) with the diff and merge tooling provided by MPS. This works for any language, regardless of abstraction level and notation.

Point-to-Point Tracing: Traceability between implementation artifacts (model, code) and requirements is very important to all engineers interviewed in the study. The current tool-chain only provides document-to-document traceability, which is not granular enough. Traceability is required on the level of model or program elements, for any level of abstraction. Currently, the engineers rely on naming conventions and ticket IDs (as defined by their issue tracker) as a workaround. Since only very limited tool support is provided, this approach is tedious and error-prone.

mbeddr solves this problem completely by providing element-level traceability from arbitrary program elements to requirements or other high-level specifications. The traces are actual references and not just based on name equality. Tracing works for program elements expressed in any language, representing any abstraction level. Since all languages live inside the same language workbench, consistent tracing is much simpler than across a set of non-integrated (and often non-extensible) tools.

Problem-Specific Expressibility: The engineers interviewed in the study complained about the need for problem-specific expressibility, i.e. the ability to define their own “little languages” for particular abstractions relevant in the domain. The study cites two particular examples. One refers to the ability for domain experts to use concise visual notations when they describe requirements, and then generate code from the resulting diagrams. The other example identifies support for physical units as a major problem in the (Matlab-based) implementation models. They reverted to Hungarian
notation to encode unit information into signal and variable names (“The printed list of all prefixes used in the system fills four pages”).

mbeddr improves on this situation generally and specifically. The ability to extend existing language with domain-specific concepts allows end users to plug in their own “little languages” and generate abstractions available in the base language. Admittedly, mbeddr does not yet support graphical languages (as requested by the engineers in the study). However, it is safe to assume that the same kind of problems will arise with predefined textual languages. mbeddr also helps specifically with the two problems discussed in the study. mbeddr’s requirements language can be extended with arbitrary domain-specific languages, and the models that become part of the requirements in this way can be used directly in the implementation of the final system. Also, mbeddr ships with a language extension for physical units that can be used with C or any of its other extensions.

Long Build Times: The engineers in the study report build times of the model-driven tool-chain in the range of several hours — in contrast to ca. 30 minutes in the old, C-based tool-chain. These long build times prevent exploratory development of control algorithms, especially while in the car on the test track: whenever a change had to be made, the test drive had to be rescheduled for another day. Ideally, developers should be able to apply (certain kinds of) changes at runtime and continue the test drive immediately.

mbeddr does not provide an out-of-the-box solution for this problem, but it can help. To be able to change parts of a system on the fly, two approaches can be used (both suggested in the study). The first one relies on interpretation or data-driven development, where the behavior of a part of a system can be changed at runtime, for example, by changing the values of configuration parameters. To enable this approach, these configuration parameters have to be integrated with the hard-coded algorithm, and the constraints on the values of the parameters have to be described in a rigid way to prevent misconfiguration. Specific extensions of C (or other languages) can be developed with mbeddr, where the parameters and their constraints can be described succinctly, integrated with the hard-coded algorithm. Static consistency checking and IDE support is provided as well. This is much more robust than the ad-hoc XML-file based descriptions of configurability often found today.

The second approach for improving turn-around times mentioned in the study is hot-swapping of code generated in the field. To make this possible, the underlying system must be partitioned well, and the interfaces between different program parts must be clearly defined. mbeddr’s interfaces and components, plus a suitable DSL for defining the partitioning of the target binary, can help solve this problem. Note that better modularity and clearer interfaces reduce build times in general, since there is no need to regenerate the whole system when a part changes. Together with mbeddr’s support for
testing and mocking, this can improve testability. Taken together, these two approaches can significantly reduce turn-around times during the development phase.

Graphical Notations: The paper does not identify the graphical notations provided by the mainstream tools used by the engineers as a friction. However, the paper does point out a set of problems with graphical notations (the paper points out that these problems apply to the notations and tools used in the study, may not be generalizable to graphical notations in general) and the limited set of abstractions provided by the modeling tools (such as scopes or subroutines). Another problem is reported to be the fact that diagrams have no obvious reading direction, which is compensated by modeling guidelines. Developers report to be struggling with reading visual models, to make sure they do not miss important parts. The paper states that,

[..] when offered an alternative to visual programming, engineers seem to prefer non-visual representations.

In the available tools these were forms and tree views. It is reasonable to assume that, if textual notations had been available, these would have been preferred over trees and forms, since the developers express that they miss “programming” in other parts of the paper. The discussion of the visual notations provided by the tools used in the study also points out the following:

While this language is visual, it does not seem be an actual abstraction from source code. Even worse, as we learned through our interviews, the level of abstraction seems to be lower than high-level source code. For example, engineers reported that they struggle to introduce abstraction such as nested scopes of variable visibility, enumerators, or refactoring duplicated code into a new method.

mbeddr takes a fundamentally different approach. First, it uses textual, symbolic and tabular notations. Second, since it starts out from C, existing C abstraction mechanisms such as the nested scopes of variable visibility or enumerators are supported. The IDE supports various refactorings. Third, additional domain-specific abstractions can be added at any time, in a modular way.

Summing up, the paper draws a rather bleak picture of today’s mainstream use of model-driven development in embedded software (and our experience is certainly in line with this picture). mbeddr improves on several of the problems discussed in the paper and our preliminary experience with mbeddr confirms this.

More recently, a session about mbeddr has been accepted for Eclipsecon France. Bernd will present it.

The session is part of the Cool Stuff track — I guess that’s a fitting choice

The paper has just been accepted at the Dagstuhl 2013 MBEES Workshop.

All in all, this is a very significant enhancement for mbeddr — not so much in terms of coding of course, but in terms of being able to build an overall software engineering environment.