From scaffolding and UML to MDSD and DSL

From scaffolding and UML to MDSD and DSL pdf

Every framework should decrease work for the developer and help him to follow certain rules. Even if the paradigms and functions used internally are designed differently, all frameworks have the same goal: to make development of individual applications fast, easy, flexible and efficient. With slogans like MVC patterns, components or APIs they compete for the developer's favour. Often, a so-called scaffolding function provides the possibility to generate a prototype for an extension with minimal effort.

Oftentimes these scaffolding functions fail to take long-term maintainability into account. The applications that were created must be kept up to date and conform to changes of the framework used below the surface. Over time, more and more applications are created, which then need to be regularly adapted to new versions and their corresponding architectural changes. This affects developers of free modules as well as commercial interest maintaining applications for their clients.

Earlier model-based approaches like UML were used for describing and documenting software systems. These are generally not considered intuitive notations though, as they are constructed in a very technical and complex way.

Model-driven software development (MDSD) does not simply describe an application with a model, but lets the model completely embody an application. The modeling language is customised for a certain problem space, called a domain specific language (DSL). The language, therefore, takes on a formal character and its elements similarly semantic meaning. This is a prerequisite for automated processing of models, for instance for model-to-model-transformations and the generation of source code, or other files like documents or configuration settings.

With model-driven development it is possible to achieve and even ensure that all applications fulfill the qualitative requirements of the framework. Maintaining multiple solutions to recurring problems becomes sustainable and free from tedious, repetitive work. In addition to an increased development speed, maintainability and software quality benefit significantly from this approach. Changes in the generator can be used by all applications that are based on it, automatically. The Zikula project profits, too. With time the advantages can add up.