Model-driven engineering

Model Driven Software Development ( MDSD, English Model-Driven Software Development ) is a generic term for techniques that automatically generate executable software from formal models. Here, modeling languages, especially domain-specific languages ​​( DSLs ) are used together with code generators and interpreters.

The term is also frequently used Model Driven Development, which was originally trademarked by the Object Management Group, was released in 2004 by this again. Also common are the synonymous terms Model Driven Engineering and Model- Driven Software Engineering.

Definition

In model-driven software development is about, to not repeat in the development of software systems as possible ( DRY principle ). Because only with the means of the programming is not always appropriate abstractions to describe various subject areas (domains) of a software system can be found, target language independent abstractions in the form of modeling languages ​​are created.

Modeling languages ​​can be on the relevant subject area especially tailored. This is called a domain-specific language ( DSL). It is also common to use universal modeling languages ​​such as the Unified Modeling Language (UML). The modeling language is mapped either generative or interpretive to the target platform.

The use of model-driven software development has an impact on all levels of a project - both technically, professionally as well as in management. Therefore describes the literature on model-driven software development is not only how to DSLs and code generators developed, but also how to integrate them useful in developing processes.

Benefits

Due to the increased level of abstraction of the problem descriptions DSLs are much clearer, detained easier and less redundant. This not only increases the speed of development, but also provides within the project for clearly understood end of domain concepts. The concept of the Ubiquitous Language of the domain - driven design is applied here to the concept level of the software architecture.

Furthermore, the evolution of the software is greatly simplified by the separation of the image and the technical expert models. Even testing is easier because you no longer will test every single line of code, but only as an example.

Domain-specific validation in the development tools makes for a very short turnaround.

Disadvantages

The initial effort to develop a DSL or for custom mapping of UML to the target language, especially for non- trivial projects considerably.

As the scope of meta-models, and thus the models, usually on some aspects of the imaged reality, only one frame (data structures, interfaces, function bodies, etc.) is often generated, which still needs to be complemented by hand to the actual function. This means that the actual project costs can be significantly underestimated. An exception hereof are usually client portions of client-server applications and pure data management applications.

For non- trivial errors, those which are not due to specification error, troubleshooting runtime is usually necessary. This is particularly the case if the generated code is supplemented by handwritten portions. A support for debugging at the model level is not or only partially present in the rule.

Tools

  • Pure graphical modeling tools: These are only for graphic display and do not support automatic transformations. The model here is exported to 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 the transformation (eg, source code or documents)
  • Pure Transformers: These are for the transformation of models and do not include graphical modeling functionalities. Models are imported in a textual interchange format XMI in an internal model format, transformed, and then re-exported.
  • Integrated MDD tools: This offer modeling, model transformations and code generation in one tool. Export and import operations, compatibility problems when exchanging data and set-up time with respect to integration can be avoided. The navigability and synchronization between business and technical model and implementation code is supported.

Examples of integrated MDD tools

  • Actifsource of actifsource GmbH
  • ArcStyler by Interactive Objects Software GmbH
  • Artisan Studio of Artisan Software Tools
  • ASCET ETAS
  • E2E E2E Technologies Ltd..
  • Eclipse-based Actifsource
  • Apollo for Eclipse Gentleware
  • Eclipse Modeling Framework (EMF ) of the Eclipse Foundation
  • Eclipse openArchitectureWare Enterprise Architect ( UML tool )
  • ModuleStudio of Guite ( Eclipse-based MDSD tool written in PHP for the Zikula - Web Application Framework )
  • OOMEGA of OOMEGA GbR (supports M2M/M2T-Transformationen with ATL and openArchitectureWare )
  • Sympedia GenFw (EMF -based Framework Generator ) * GUIDE Studio Elektrobit Corporation
  • YAKINDU Statechart Tools Open Source Tool of itemis
  • Xtext Open Source Framework of itemis
Interpreter (computing) Domain-Driven Design XML Metadata Interchange ETAS Group Enterprise Architect (software) Atlas Transformation Language Software framework ObjectiF Compuware Rational Rhapsody IBM Specification and Description Language Simulink Stateflow TargetLink Borland Together Borland Model-based testing
577442
de