Model-Based Design
One of the main reasons why software modeling had limited success in the past is thesemantic gap between the concepts used in modeling and the concepts traditionally used in the implementation. For example, traditional programs are built around the concepts of “naked” threads and various blocking mechanisms of an RTOS, such as time-delays, semaphores and mutextes. These concepts have no direct representation in the modeling language (e.g.,UML).
Instead, the modeling domain uses different concepts at a higher level of abstraction, such as:“events”,“active-objects/active-classes” and“hierarchical state machines” (UML statecharts). Unfortunately, none of these abstractions have direct mapping or representation in C/C++ or the traditional RTOS.
And here is where aReal-Time Embedded Framework (RTEF) comes in. Such a framework exactly supplies the higher level of abstraction and theright abstractions to bridge the semantic gap between modeling and implementation.
The framework also provides the well-defined “framework extension points” designed for customizing the framework into applications, which in turn provide well-defined rules forautomatic code generation.
As it turns out, the ROI of software modeling is negative unless the models are used togenerate substantial portions of the production code. For example, according to theUML Modeling Maturity Index, without code generation modeling 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.
Unfortunately, code generation has been always associated with complex, expensive,“high-ceremony” modeling tools with a very steep learning curve and a price tag to match. After having found that such modeling tools could not pull their own weight, many practitioners have given up modeling altogether. But this rejection of modeling for software is ironic when you consider that software is the engineering medium best positioned to benefit from it.
What embedded software developers are often asking for is a simpler,“low-ceremony” tool that works at a lower-levelcloser to the code. This characterization is not pejorative. It simply means that developers wish that the tool would map their graphical design unambiguously and directly to C or C++ code, without intermediate layers of “Platform-Independent Models” (PIMs), “Platform-Specific Models” (PSMs), complex “Model-Transformations”, or “Action Languages”.
Therefore, theQM™ model-based design tool was designed from the ground up to be“code-centric”. QM is a unique tool on the market that supports both the logical design andphysical design. Unlike other graphical tools, QM gives you complete control over the generated code structure, directory names, file names, and elements that go into every file. You can mix your own code with the synthesized code and use QM to generate as much or as little of the overall code as you see fit.
