Tech Brief

Domain-Specific Modeling

How DSM code generation can go beyond the benefits delivered by UML.

• By Juha-Pekka Tolvanen
• 11/01/2006

Increasing complexity of software is leading many companies to add a modeling phase to the development process. Currently the best-known means for making designs is a notation called Unified Modeling Language (UML), which aims to provide a visual representation of the code. While making a design before beginning the implementation work makes a lot of sense, companies often want more from the models than just throwaway specification or documentation that often ends up not reflecting what is actually built. Automatically generating production code from the UML designs would provide a solution, but this is where the UML generally falls short: In practice, it's possible to generate only very little usable code from UML models.

Domain-Specific Modeling (DSM) is a new approach for modeling software that promises to change the modeling landscape. Unlike UML, it provides modeling constructs that mimic the real-world objects more closely. Most importantly, it provides complete code-generation capabilities. Together, these lead to a much more productive way for developers to build applications.

Lead by Example
Comparing DSM and UML with a simple but concrete example makes the difference visible: Building an application for signing up to a conference using a phone, with the ability to choose a payment method and view the conference program.

Using UML, we would start by illustrating the external requirements for the application in a use case diagram, followed by specifying the internal design in diagrams like UML's class diagram and behavior in UML sequence and state diagrams.

[click image for larger view]

Code-Focused vs. Domain-Specific

It becomes obvious that while we move to designing more details, more possible design solutions become available and different developers will choose different solutions, many of which will not be the most preferred ones. UML allows this and thus provides no help in getting our designs right. After all, UML doesn't know anything about the application we're building. To make correct designs, developers need to know the problem domain (the phone), the platform upon which the application is built (e.g. Symbian) and how to draw UML correctly.

Finally, after having made other similar diagrams out of any of the 13 UML diagram types available, we finally get to write the code. We naturally would like to generate as much of it as we can, but here the UML fails. Why? UML is a general-purpose modeling language, meaning you can use it no matter what type of software you intend to build. Because of this, the creators of UML had to make many compromises, making UML quite good for everything but great for nothing. As a result, developers can generate only very little usable code from UML designs. After all the modeling we have a good understanding of the application, but still no working program. Inevitably, the coding and testing phases will introduce changes that developers often don't bother to update in all the models, rendering them outdated.

Code Generator
DSM says that developers can design software more effectively if they use a notation tailored to fit the problem domain at hand. It should allow developers to capture all the needed aspects of the application and nothing more than just that. Provided this notation and the way it maps to code is defined by a company's expert, the rest of the developers will be able to automatically generate full, top-quality code from their designs. Naturally, there needs to be tool support for DSM, where these tools need to make it easy to define, use and maintain the DSM languages and generators. This should take days rather than months. With companies like Microsoft, MetaCase and Xactium and frameworks like Eclipse GMF providing support for DSM, the tools are actually there already.

Using such a domain-specific language tailored to fit our phone problem domain we can create a more expressive design, which is based directly on phone domain concepts such as Note, Pop-up or SMS, and the rules that are valid in each.

With DSM, we can focus on finding the solution in domain concepts instead of code. As the descriptions capture all the required static and behavioral aspects of the application, it's possible to generate the application fully from the models. This is clearly different when looking at the UML models shown earlier.

Domain-Specific Modeling allows faster development based on models of the product rather than on models of the code. Our case of phone application development gives one example.

Implementation of DSM is not an extra investment if you consider the whole cycle from design to working code. Rather, it saves development resources. Traditionally, all developers work with the problem-domain concepts and map them to the implementation concepts manually -- and among developers, there are big differences. Some do it better, but many not so well. So let the experienced developers define the concepts and mapping once, and others need not do it again. If an expert specifies the code generator, it produces applications with better quality than could be achieved by normal developers by hand.