MDD in embedded

After many years of resistance it seems that modeling is gaining foothold in the area of embedded software development. I do not have any hard numbers about the acceptance though. Anyone able to provide a pointer here?

Development of embedded software has - like in other areas of software development - grown more complex and the pressure of delivering in ever shorter development cycles has increased. A natural way to deal with complexity is the use of software platforms and modeling.

Although embedded developers have no ears for the OMG's MDA, UML currently is the leading notation for modeling embedded software. The problem with acceptance of UML in embedded has several reasons, one of the most important ones is that UML is an object-oriented notation where much of embedded software development still is functional. UML thus requires developers to adopt another way of thinking about development, which - naturally - is meeting with heavy resistance. Furthermore, UML - as is - is poorly suited for embedded development. While reading about companies like ARTiSAN, I was surprised to see they basically have extended the UML metamodel with embedded-specific (read: domain-specific) concepts: time tags in the sequence diagram in order to add support for timing issues, tweaked UML diagrams in creating a system definition diagram and a system architecture diagram, and finally by adding a whole new diagram with completely new-to-UML-modeling concepts: a concurrency diagram. Nice job as they did haul Siemens VDO in with it, who are using their tool for engine management development.

After reading about it I wondered: Why not take it a step further? UML is missing a lot of notation possibilities to capture embedded software and systems correctly, it still requires developers to think in an OO-way, and even IF they already think in an OO-way then it still does not significantly raise abstraction nor support the design work: What does UML really say about engine management systems, about pacemakers, mobile phones, avionics or weapon systems? Yep....zilch.

If however you define a design language yourself, you have the ability to base it on which ever orientation (OO, functional, look & feel, generated output, hardware architecture, variability, domain concepts) is most suited for your situation. There will be no need to learn a whole new notation as you will use the same concepts (and rules that govern them) that you normally speak about (It will be much more easy to communicate with than with UML) and are familiar with. Additionally, it will not allow you to generate just 80% of the production code but 100%. Forget about reverse engineering....you won't need it anymore.

I will likely write more on this area, embedded development is extremely well suited for DSM.

Definition: MDA tool (2006)

I just read the special on MDA tools in Software Development Magazine. Although it has as title "A special guide to MDA and UML tools", surprisingly some tools in there were neither, nor do their websites claim to be. After reading on, I came to the conclusion that we have to forgive the author for doing this: It seems rather difficult to determine what exactly is an MDA or UML tool these days.

I thought I'd try to give a definition of an MDA tool, based on the information, no doubt carefully prepared and provided by all vendors. Here we go:

MDA Tool: A tool that may, or may not, generate code, limited, or not limited, to just one single technology platform, from models. These models may be the "de-facto" standard UML or some proprietary derivative from this standard (in which case you still seem to be allowed to call it compliant). The model-to-code or model-to-model transformations may, or may not be completely proprietory, and may, or may not be customizable. Some tools already claim to support the "QVT standard" although according to the OMG (the standardizing organization) this is not a standard yet. Some also claim to support the "XMI standard" for model interchange between tools although each tool seems to support its own version of this standard, making model interchange impossible in practice. Also "MDA-compliant" are those tools that support tweaking UML via MOF, proprietary metamodels, standard profiles, non-standard profiles, standard OCL or non-standard OCL ("OCL-like" often is close enough), essentially these are thus standards for de-standardizing the standard OR proprietary means for standard de-standardization, after which you - naturally - may still claim standard-compliance.

Standards somethimes seem to make things difficult, don't they?