Modeling with Domain-Specific Languages

By Martijn Iseger, Juha-Pekka Tolvanen

December 2, 2005

(Modeling with Domain-Specific Languages :  Page 1 of 1 )

Domain-specific languages (DSLs) may well lead many of us away from the one-size-fits-all approach of current programming and design languages like C, Java, and UML. They raise the level of abstraction of development from coding to more real-world objects, yet allow in many cases to generate final products from the high-level specifications. This makes development truly model-driven. DSLs took center stage during recent leading conferences like OOP, OOPSLA, UML & Design World, and the ACM/IEEE MoDELS conference. What are DSLs? How do they differ from their more generic counterparts and why have they started receiving so much attention? In this article, we focus on the use of DSLs for modeling and therefore speaks about Domain-Specific Modeling (DSM) languages instead of DSLs, which usually have been text-based languages, often backed by dedicated compilers.

The Problem With Generic Languages

One reason for the growing interest in DSM is the possibility it offers for accelerating software and system development by making it truly model-driven: Design the solution with real-world domain concepts and generate full products in code or configuration files from these higher-level designs. Traditionally, design and programming languages have focused on implementation concepts and have thus offered only modest possibilities to raise the level of abstraction and automate development (see Figure 1).

The first step in developing any software or system is to think of a solution in terms that relate to the problem domain of the software. If we are developing a portal for insurance product comparison and purchase, we will use insurance domain concepts like "Risk", "Bonus", and "Damage" while we define the insurance products (the solution). For developing voice menus for a home automation system on the other hand, we will think in terms of "Menus", "Prompts", "Voice Entries" and when we develop applications for TV set-top boxes, we probably work with concepts such as "Channel", "Program Guide", "Aspect Ratio", and the like.

 Page 1 of 1