Model-driven software development
Model-driven software development (MDSD) is an alternative to round-trip engineering. As explained by Thomas Stahler and Markus Voelter in their book, the difference relates to the level of abstraction of the model in each case, compared to the code:
Round-trip engineering is the concept of being able to make any kind of change to a model as well as to the code generated from that model. The changes always propagate bidirectionally and both artifacts are always consistent. The transition from code to model (the reverse engineering) is especially interesting in this context.
In the context of these approaches the model typically possesses the same abstraction level as the code (that is, 'one rectangle per class'). It is actually the visualization of a program's structure. In such a scenario, it is both feasible and useful to track changes to the code in the model automatically.
MDSD takes a different approach: the model is definitely more abstract than the code generated from it. Thus it is generally impossible to keep the model consistent automatically after a manual change of the generated code. For this reason, manual changes to generated code should be avoided. A precise definition that states which parts are generated and which are implemented manually is therefore necessary.[1]
- ^ Model-Driven Software Development: Technology, Engineering, Management (book, ISBN 0470025700) Thomas Stahl, Markus Voelter
Stahler and Voelter suggest four ways by which the same goal can be achieved in MDSD without requiring round-trip engineering:
1. Abstraction
The abstraction level of decisions is raised to model level. This only makes sense if a corresponding abstraction on the model level can be identified.
2. Tagging the model
This involves moving code-level decisions into the model without raising the abstraction level. This procedure is called 'tagging'the model with implementation decisions.
3. Separation of code classes
This involves the adaptation of the target architecture in such a way that manually created code must be written into classes specifically created for this purpose.
4. Tagging the code
This consists of the introduction of protected regions to the code, and is accomplished through the use of special tags that protect the code placed between them from overwriting during regeneration.
This list reflects the various solution's elegance in strictly descending order. Tagging the model still allows a clear separation of responsibilities and enables a fully automated regeneration without further manual treatment.