ere's an interesting coincidence: The "UML Conference," where I delivered the keynote speech a few days ago, changed its name to "MoDELS & UML." Similarly, the "UML & Design World" conference where I spoke a few weeks ago was previously called "UML World." The fact that both these leading conferences have changed their name indicates a big shift in the modeling world that may well lead us away from the one-size-fits-all approach offered by the Unified Modeling Language. One of the new approaches causing this shift is called Domain-Specific Modeling, DSM for short. In this first of a series of articles I will introduce DSM with a short example. Later articles will provide the opportunity to dive a little deeper into the subject, compare it to other approaches, identify characteristics of areas where DSM makes most sense and, of course, show real world examples from the software industry.

Domain-Specific Modeling mainly aims to do two things. First, raise the level of abstraction beyond programming by specifying the solution in a design language that directly uses concepts and rules from a specific problem domain. Second, generate final products in a chosen programming language from these high-level specifications. This automation is possible because both the language and generators need fit the requirements of only one company's problem domain. In other words, they are both domain-specific.

Raising Abstraction and Productivity
I'll start introducing DSM by addressing the importance of the abstractions developers work with. Throughout the history of software development raising the level of abstraction has been the cause of the largest leaps in developer productivity. The most recent example was the move from Assembler to Third Generation Languages (3GLs), which happened decades ago. As we all know, 3GLs such as FORTRAN and C gave developers much more expressive power than Assembler, and in a much easier to understand format; yet compilers could automatically translate them into Assembler. According to Capers Jones' Software Productivity Research, 3GLs increased developer productivity by an astonishing 450 percent. In contrast, the later introduction of object-oriented languages did not raise the abstraction level much further. For example, the same research suggests that Java allows developers to be only 20 percent more productive than BASIC.

Another way for companies to raise the abstraction level is to use software platforms, frameworks or component libraries. These offer abstractions that help in managing complexity, but usually still require developers to program and specify mappings to the components manually, in code. Modeling usually does not help the developer here because most current modeling languages are based on the coding concepts and offer only modest possibilities to raise the abstraction level. For example, UML uses programming concepts (classes, return values etc.) as its central modeling constructs. These are the constructs used most often, and the only ones that generate even skeleton code.

The root problem is that changing the representation of a construct without increasing the abstraction level doesn't improve productivity. In UML, using a rectangle symbol to illustrate a class in a diagram and later creating the equivalent code representation in a programming language does not provide a higher level of abstraction! Figure 1 shows the relationship of models to code.

Figure 1. Bridging the Abstraction Gap: Developers have bridged the abstraction gap between an idea in domain terms and its implementation differently over time. DSM allows them to model directly in domain terms without the need to manually map the solution to code.

If raising the level of abstraction reduces complexity then we need to ask ourselves how we can raise it further. The first step in developing any software (as shown in Figure 1) is to think of a solution in terms that relate to the problem domain—a solution on a high abstraction level (step one). Using UML, after developers figure out a solution (what to do) on this level, they need to map it to a design in UML (how to do it, step two). From there they must implement the design in a programming language (step three). It is remarkable that developers still have to perform step one without any tool support, especially when we know that mistakes in this phase of development are the most costly ones to solve. Most of us will also argue that finding a solution on this level is exactly what has been most complex. Step three, making a model of the solution in UML, has gained little in popularity over since its introduction 10 years ago: 61 percent of developers find it slows them down or makes no difference to productivity (SD Times, 8/15/2004).

While making a design before beginning implementation makes a lot of sense, I believe companies want more from the models than just throw-away specification or documentation that often ends up not reflecting what is actually built. UML and other code-level modeling languages often just add an extra stepping-stone on the way to the finished product. Automatically generating code from the UML designs (automating step 3) would remove the duplicate work, but this is where the UML generally falls short: In practice, it's possible to generate only very little usable code from UML models.

Rather than having extra stepping-stones and requiring developers to master the problem domain, UML and coding, an ideal situation would allow developers to specify applications in terms they already know and use, then have generators take those specifications and spit out the same kind of code developers used to write by hand. This would raise the abstraction level significantly, moving away from programming with bits and bytes, attributes, and return values, and toward the concepts and rules of the problem domain developers are working in. If this new programming language is a visual one rather than based it on text, then it essentially merges steps one and two, and completely automates step three. That raised abstraction level coupled with automatically-generated code is the goal of Domain-Specific Modeling.