Domain-Specific Modeling raises the level of abstraction beyond programming by specifying the solution directly using domain concepts. The final products are generated from these high-level specifications. This automation is possible because both the language and generators need fit the requirements of only one company and domain. In this article, the author introduces Domain-Specific Modeling (DSM) and explains how such languages and generators can be implemented.

Domain-Specific Modeling raises the level of abstraction beyond programming by specifying the solution directly using domain concepts. The final products are generated from these high-level specifications. This automation is possible because both the language and generators need fit the requirements of only one company and domain. This article introduces Domain-Specific Modeling (DSM) and explains how such languages and generators can be implemented. Article concludes by comparing DSM to Model-Driven Architecture (MDA).

 

UML for code generation

Generating complete code from models has been an industry goal for many years. Models serve as mechanisms for better understanding and documentation, but they can also be input for code generators. This automates development leading to improved productivity, quality and complexity hiding.

Unfortunately, many current modeling languages are based on the code world and offer only modest possibilities to raise design abstraction and to achieve full code generation. For example, UML uses directly programming concepts (classes, return values, etc.) as modeling constructs. Having a rectangle symbol to illustrate a class in a diagram and then equivalent textual presentation in a programming language does not provide real generation possibilities – the level of abstraction in models and code is the same! As a consequence of this, developers easily find themselves making models that describe functionality and behavior that they find easier to write directly as code. The limited code generation possibilities force developers to start manual programming after design. It has also lead to round-trip problems: Having the same information in two places, code and models, is a recipe for trouble.

Domain-Specific Modeling solution

Generation challenges can be solved in a similar manner as in the past with programming languages: by continuing to raise abstraction. Models should not be conceived to visualize code, but describe higher-level abstractions above programming languages. Similarly, in the past it was better to move to C to raise the abstraction than start visualizing Assembler code!

In Domain-Specific Modeling (DSM), the model elements represent things in the domain world, not the code world. The modeling language follows the domain abstractions and semantics, allowing modelers to perceive themselves as working directly with domain concepts. The rules of the domain can be included into the language as constraints, ideally making it impossible to specify illegal or unwanted design models. The close alignment of language and problem domain offers several benefits. Many of these are common to other ways of moving towards higher levels of abstraction: improved productivity, better hiding of complexity, and better system quality.

The higher level of abstraction varies between applications and products, though. Every domain contains its own specific concepts and correctness constraints. Therefore, modeling languages need to be specific for each domain. If we are developing a portal for insurance product comparison and purchase, why not use the insurance terminology directly in the design language? Language concepts like Risk, Bonus and Damage capture facts about insurances better than Java classes do. An insurance-specific language can also guarantee that the products modeled are valid: insurance without a premium is not a good product, so such a product should be impossible to design. These domain concepts are typically already known and in use, are more natural and reflect already the underlying computational models needed to design the products. Similarly if we are developing the Internet telephony services, why not have the relevant concepts and rules of the domain supported already by the language. It is far more natural to think about telephony service logic with Switch, Call, Signaling actions etc. than with code. Final code (assembler, 3GL, object-oriented etc.) can be still generated from these high-level specifications. Cornerstone for this automated code generation from models is that both the language and generators need fit only company's requirements.

What a DSM language looks like: an example

To illustrate DSM in more detail let's take an application domain that is familiar to everyone: digital wristwatch applications, such as time, stopwatch and world time. These applications are implemented into mobile phones using MIDP, which is a set of Java APIs providing a standard application runtime environment targeted at mobile information devices.

Before any new features can be implemented developers must design them in the watch domain. This involves applying the terms and rules of the watch, such as buttons, alarms, display icons, states and user's actions. DSM language applies these very same concepts directly in the modeling language. Using familiar terminology the design models become easier to read, remember, validate and maintain. A simple example of such a modeling language is illustrated in Figure 1. The model represents the time setting feature: the actions a user can make by pressing buttons, the display elements blinking, and the actions changing the time.

The modeling language, here based on state machines, also includes domain rules, preventing developers from making designs that are illegal (e.g. connecting two watch buttons together). A clear indication of the higher level of abstraction is that the modeling language operates on and applies the rules of the watch, not of implementation. You don't see any MIDP concepts or Java code in the model! After drawing the design, the developer can run the generator and execute the application on the target (Figure 2). Complete implementation of the language and generator is available from www.metacase.com/download.

 

Figure 1. Model in a DSM language for designing watch applications

 

 

Figure 2. Generated code and its execution in the target device

sum:

0 €

» Library of the Month
» Workshop
» Software Engineering
» Programming Tools
» Interview
» High quality and
secure programming
» Reverse Engineering
» Portable GUI
» Artificial intelligence