Model-driven software development

from Wikipedia, the free encyclopedia

Model-driven engineering ( English model-driven software development , MDSD or MDD) is a generic term for technologies that automates formal models executable software generate. Here are modeling languages , especially languages domain-specific (DSLs) together with code generators and interpreters employed.

definition

The aim of model-driven software development is to generate the source code for a software system in whole or in part from a model, the model being of significantly simpler complexity than the source code to be generated. In particular, the DRY principle comes into play here. In addition to the source text, other artifacts such as non-executable files as well as tests and documentation can also be generated automatically. Because appropriate abstractions for the description of different subject areas (domains) of a software system cannot always be found with the resources of the respective programming language alone, abstractions independent of the target language are created in the form of modeling languages.

Modeling languages ​​can be specially tailored to the respective subject area. One then speaks of a domain-specific language (DSL). The use of universal modeling languages ​​such as the Unified Modeling Language (UML) is also common. The modeling language is mapped onto the target platform either generatively or interpretatively.

The use of model-driven software development has effects on all levels of a project - both technically, professionally and in the management area. Therefore, the specialist literature on model-driven software development not only describes how to develop DSLs and code generators , but also how to integrate them sensibly into development processes.

advantages

Due to the higher degree of abstraction of DSLs, problem descriptions are much clearer, simpler and less redundant. This not only increases the speed of development, but also ensures clearly understandable domain concepts within the project. The concept of the ubiquitous language from domain-driven design is applied here to the concept level of the software architecture.

Furthermore, the evolution of the software is significantly simplified by separating the technical mapping and the business models. Test cases can be created more quickly or more thoroughly, since you no longer test every single line of code, but check the system behavior statically and dynamically on a functional level.

Domain-specific validation in the development tools ensures very short turnarounds .

disadvantage

The initial effort for developing a DSL or for the customized mapping of UML to the target language can be considerable, especially in non-trivial projects.

Since the metamodels, and thus the models, are usually limited to partial aspects of the reality to be mapped, often only a framework (data structures, interfaces, function bodies, etc.) is generated, which has to be supplemented by hand with the actual function. This means that the actual project effort can be significantly underestimated. As a rule, this does not apply to client parts of client-server applications and pure data management applications. Also to be excluded are cases in which sophisticated domain-specific languages ​​(DSL) are used that cover dynamic aspects of the system behavior to such an extent that the source text can be generated completely or almost completely (e.g. Simulink ).

In the case of non-trivial errors, those that cannot be traced back to specification errors, troubleshooting is usually necessary during runtime. This is particularly the case if the generated code has been supplemented by handwritten parts. Support for troubleshooting at the model level is often not or only incompletely available.

Tools

  • Pure graphic modeling tools: These are only used for graphic display and do not support automatic transformations. The model is exported here in a textual exchange format such as ( XMI ) and further processed with separate transformers.
  • Pure textual modeling tools: These are based on one or more textual domain-specific languages and always support transformation (e.g. in source code or documents)
  • Pure transformers: These serve exclusively to transform models and do not contain any graphic modeling functionalities. Models are imported into an internal model format in a textual exchange format such as XMI , transformed and then exported again.
  • Integrated MDD tools: These offer modeling, model transformations and code generation in one tool. Export and import processes, compatibility problems with data exchange and set-up effort with regard to integration are avoided. Navigability and synchronization between the functional and technical model and implementation code is supported.

Examples of integrated MDD tools

See also

Web links

Individual evidence

  1. ↑ a b Thomas Stahl, Markus Völter, Sven Efftinge: Model-driven software development. Techniques, engineering, management . 2nd updated and expanded edition. Dpunkt-Verlag, Heidelberg 2007, ISBN 978-3-89864-448-8 .
  2. ↑ Juan Carlos Flores Beltran, Boris Holzer, Thorsten Kamann, Michael Kloss, Steffen A. Mork, Benedikt Niehues, Karsten Thoms: Model-Driven Software Development. MDA and MDSD in practice . Ed .: Georg Pietrek, Jens Trompeter. Developer Press, Frankfurt am Main 2007, ISBN 978-3-939084-11-2 .