Model-Driven Development Using Domain-Specific Languages

My field of interest is in the scope of software engineering. I am doing research on how to develop onboard software for spacecraft and other systems more effectively by applying model-driven approaches. I am developing languages to describe systems in an easier manner, to make use of code generation mechanisms for onboard software.

As a software developer, I am dealing with development, organisation and management of software projects. My research area at DLR is mainly located in model-driven development. The motivation of model-driven development is to increase productivity by generating project artefacts from the model. A variety of textual and graphical languages as well as custom editors can be used to describe the model. Besides generation, the model is used for information exchange. One of the most common reasons for critical issues in projects’ lifecycle are misunderstandings between developers of different domains, like software and hardware. Model-based development enables different views on one system model, which may present its information in completely different ways, depending on the current viewing developer. This way it is possible to let the electronic developer describe the system’s hardware in a textual language and the software communication flow in a graphical diagram. Different views enable developers of different domains to edit the same model and thus generate one matching software and its documentation. This kind of development increases productivity twice: Short-term productivity is improved by the ability of generating new features from the model, long-term productivity rises because changes in the model can easily handle changing requirements.

Figure 1: Description of a system with textual and graphical DSLs. Models like this can be used to generate source code, documentation and tests.

My speciality is the development of domain-specific languages (DSL)s. DSLs are languages especially developed for a specific task and thus match the project’s requirements precisely. Compared to a general propose languages, this reduces learning effort for the domain experts and custom editor support leads to low error-proneness. Depending on the project’s needs, DSLs may contain graphical as well as textual parts. For example, the project ATON (Autonomous Terrain-based Optical Navigation) uses a graphical model, covering a description of its software modules, their parameters and communication patterns, to generate the communication and integration code as well as their interface documentation. In the project MAIUS (Matter-Wave Interferometry in Microgravity) several models are used to generate the rocket’s onboard software. We use a textual language to describe the hardware and a graphical one to describe the experiment execution in a graph. This enabled us to generate 86% of the MAIUS mission code.

Figure 2: Integration of a textual DSL into a graphical one. The editor supports autocomplete and syntax highlighting.

In my private life I am also interested in psychology and communication science. Considering challenges of human communication might improve information exchange and give a more abstract view on model-based development.