MDD and IDEs: making the twain meet in embedded systems design
Embedded system developers are stuck between the rock and the hard place, faced as they are with increasingly complex systems, more lines of code, more powerful processors, and the need to generate code that accurately reflects the real-time and deterministic requirements of applications such as automotive and industrial control.
On the one hand, developers need to use high-level Model Driven Development (MDD) tools, such as UML, to accurately capture the behavior and characteristics of the design environment inside, say, an automobile, in which multiple processors may be linked together to enable all elements in that environment to communicate and, when necessary, work together. On the other hand, developers must also work at the code level, usually within an integrated development environment (IDE) to generate, debug, analyze, and test the code for each element in the system.
However, very often the twain do not meet. And when they do, the linkage between the two has been problematic. The separate stand-alone MDD environments and IDEs within which they've worked have forced embedded system developers to work in either one or the other with no substantive interaction between the two "worlds."
In cases where the developer wants to work with models, if the models don't generate code that includes behavior, he faces the difficult task of writing the code in an IDE and then maintaining both the models and the code since the MDD environment and IDE are completely out of synch with each other. The link between model and code inevitably would be broken; the model information would lose its value as the code changed because most likely the developer would not update the model to reflect the code changes.
Early MDD solutions that did generate code produced black-box code, which is unreadable and offers very little code-level control. Getting the black-box code to look right and operate as intended was nearly a "black art," and if the user could change the code, the model and the code would be out of synch, leading to a major maintenance issue. This lack of control and synchronization of the model and code reduced the value of modeling throughout the development lifecycle.
By incorporating bidirectional linkage between an Eclipse IDE-based code-centric workflow and an MDD model-centric workflow, engineers can work within the familiar code-level IDE and within the same framework use modeling. In addition to easing the learning curve for embedded system developers now reluctant to incorporate model-driven tools into their work flow, the linkage also provides a number of powerful capabilities, including:
• Reverse engineering of existing code into a graphical model;
• Round tripping of changes made to the code at the IDE level being developed back into the model;
• Automatic generation of new code from the model;
• Synchronizing of changes to either the code or the model through the Dynamic Model Code Associativity (DMCA); and
• Ensured code respect; that is, when code is reverse engineered or round-tripped and then regenerated, the user has the option in a bidirectional environment of maintaining the original file structure and naming of the files while also not changing the internal flow, structure, and naming of the code itself.
This combination of capabilities made possible by the bidirectional linkage is particularly effective when challenges arise in meeting the project requirements for the code. By working in the Eclipse IDE to write or modify the code and having the changes automatically appear in the MDD environment, users can ensure that algorithms meet special characteristics including timing, safety, and security. This also is a benefit in situations where the size of the code is of concern or direct interaction with the hardware is required. Additionally, a scenario where the existing code must be included in the project, such as a wish to reuse legacy code or a need to integrate third-party code, the combined Eclipse IDE and MDD environment is a powerful tool.
Graphically modeling the project allows engineers and developers to abstract away from the code, to clearly see how all the elements of the project operate together. With the ability to simulate the model and the code on the host computer during the development process, rooting out problems is done quickly at the beginning of the process, when the costs and time needed to fix these issues is at a minimum.
Additionally, this enables development and testing to begin on the host before the target hardware is available. By automatically generating the code for a majority of the new capabilities and reverse engineering any existing code into the model, engineers can shorten the development time through automation. Perhaps the most valuable feature is the self-documenting workflow. The ability to generate designs of the code being developed makes design intent much clearer to all.
Code visualization and bidirectionality
Conventional wisdom says that jumping into a software development project already underway is not the time to change workflow approaches. This wisdom holds true for most design environments, but the ability to function bidirectionally either in a code- or model-centric approach with a transparency to either process challenges this thinking.
When developers are able to use code-visualization tools to graphically show the structure and architecture of their code using reverse engineering and still continue to work in their existing environment, suddenly adopting a model-centric workflow midstream is not nearly the disruptive force it used to be. In an MDD environment using tight synchronization between the code and the model, the developer can continue developing code or move to the model level, reusing legacy code with better understanding of its functionality through visualization.