Click here to view the complete list of archived articles

This article was originally published in the Winter 2006 issue of Methods & Tools

Creating a Domain-Specific Modeling Language for an Existing Framework

Juha-Pekka Tolvanen, MetaCase, http://www.metacase.com

Domain-specific languages are a natural extension to code libraries and frameworks, making their use faster, easier and more consistent.This article describes how to define modeling languages on top of a library or a framework.

Developers usually agree that it does not make sense to write all code character by character. After coding some features they usually startto find similarities in the code and patterns that seem to repeat. For mostdevelopers it would then make sense to focus just on the unique functionality,the differences between the various features and products, rather than wastingtime and effort re-implementing similar functionality again and again. Avoidingreinventing the wheel is good advice for a single developer, but even more so if colleagues too are implementing almost identical code.

One well-known practice is to move the common parts into a reusable library, or make them into a framework that is used as a basis fordeveloping features or even whole products. Application developers can then getto know the framework and its architecture, find out its class hierarchies,learn its APIs and study the programming model required. The use of a frameworkis supported by documentation, application examples and guidelines. The bad newsis that both research and practice show that for most developers it is oftenhard to use the framework and find the right component for the right task. Thereare usually also interdependencies that need to be understood, optional servicesand multiple alternative ways to provide the same functionality. It takes time to learn these and become enough of an expert on the framework to use it well.

Domain-Specific Modeling (DSM) provides a solution: it allows the framework developer to hide the details of the framework by raising thelevel of abstraction on which applications are built. The basic concepts of theframework are represented as the available kinds of objects in a new,domain-specific modeling language. Application developers can model theapplications using these high-level concepts and generate working code that takes best advantage of the framework.

This automation is possible because both the modeling language and generators need only fit the requirements of the specific frameworkand application type. Automation minimizes routine work, makes many typicalerrors impossible and leads to a fundamentally faster development process. Adomain-specific language can also cover the rules of the architecture andcomponent use, guaranteeing that the framework is used correctly. Developers arethus guided to follow the best practices – those the experienced framework developer knows work well.

DSM example

Before we look at how to create such a language, let’s first illustrate domain-specific modeling with an example. For this purpose weuse a well known domain: a digital wristwatch. Suppose your developers make thewatch applications, such as a stopwatch or time setting and display. Theseapplications are implemented on a top of a framework that provides commonservices like time calculations, showing an icon, ringing an alarm etc. Theframework expects that a particular programming model is applied when making the application and calling the framework services.

Before any new features can be implemented, or existing ones modified, developers must design how they should work in the watch problemdomain. This involves applying the terms and rules of the watch, such asbuttons, alarms, display icons, states and user’s actions. DSM applies these very same concepts directly in the modeling language.

An example of such a modeling language is illustrated in Figure 1. This modeling language is used to design and create various timerelated applications. The sample design model represents the time settingfeature: the actions a user can make by pressing buttons, the display elements blinking, and the actions changing the time.

Figure 1. Modeling a time setting feature

Although the modeling language raises the level of abstraction and totally hides the details of the framework services from thedeveloper, it is still clearly based on the underlying watch architecture andits framework. The design models describe the missing information that fills thevariation points in the framework to build applications. With this language,developers can focus purely on the design of the application itself. Completeand working application code – using the services of the framework – is generated automatically.

Having a new modeling language, rather than just a model, allows us to make many different watch applications. Figure 2 illustrates amodel of a world time application for the same watch framework, built using thissame modeling language. This application is for a slightly more advanced watch,with an extra Mode button that allows the user to exit this application, orswitch between editing the minutes or hours. The green display function at thetop calculates the time to display: no longer just the clockTime, which is setin the Time application, but the clockTime plus a time zone offset which is set here.

Figure 2. World time application

Figure 3 specifies a basic stopwatch application. The model uses a couple of features of the modeling language which were not used inFigures 1 and 2: straight arithmetic calculations on time variables, anddifferent display functions for different states. The display function for theRunning state is the lower green object, and calculates the time to display as the current system time minus the time the stopwatch was started.

Figure 3. Design of a simple stopwatch application

These applications are not static: they can be developed further just as with source code. If we want an improvement, we simply edit themodel. Consider for example Figure 4, which extends the stopwatch application toadd lap time functionality, and turns an icon on and off to show when the stopwatch is running.

Figure 4. Design of an advanced stopwatch application

Let’s look next how the modeling languages are defined. We’ll use the watch framework and its related modeling language as an example later inthe article.

Page 2   Back to the archive list