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 - Part 3

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

Notation makes a language visible

A pure metamodel, however, is not enough as the language also needs to have notation and visual presentation, usually a diagram, but sometimesa matrix, table, or plain text. The best source for the notation is theapplication domain. Using familiar symbols from the application domain makes themodels easier to read, remember, understand and check. One good way is to lookat designs that developers draw when they have complete freedom, e.g. onwhiteboards or in presentation slides. Here they can apply the concepts andvisualizations that they find most suitable for describing their applications.DSM should mimic and apply these concepts and notations in the modeling language.

In our sample language we have used the notation of basic state machine and extended it with domain concepts like buttons, alarms andicons (see Figures 1-4). We also use coloring to categorize different areas ofconcern according to the MVC (model-view-controller) architecture: green for theviews (icons, displays), red for control path (buttons, triggers, alarms), andblack for the underlying data model (time manipulation). Dark red is used for elements that have aspects of both data model and control.

Running the language definition

Once a metamodel, or a part of it, is defined, it should be tested with sample applications. For this purpose we need tools that provideeditors for modeling with the defined languages. Best is if the tool forlanguage definition and language use is the same. This makes language definition agile: we can modify the language (metamodel) while using it.

Tools should not, however, be restricted only to editor creation based on metamodels. They should guide in defining the metamodel andrecognize if the language definition is incomplete (i.e. illegal in some way)and if a particular language can be integrated with other languages. Toolsshould also allow sharing language versions among developers and updatingexisting models based on language changes. This is crucial in practice sincecompanies simply cannot afford to wait for weeks or months before getting a newlanguage version – and then having to update previously made models by hand.

Fortunately, tools are already available that provide good support for this: whilst a quick prototype editor could be built in a man-yearor even man-months, to make a usable, reliable tool that developers will acceptrequires a far greater amount of work. Using a tool that already offers thesefeatures, an experienced developer in a company can thus tailor design languagesand generators to a specific domain. Other developers can then design with theresulting DSM languages and tools, and generate actual products from their models.

Concluding remarks

Domain-specific languages are a natural extension to frameworks, making them better able to be used. Domain-specific languages workwell with frameworks since both focus on a specific application area and oncreating similar applications. The investment you need to make first is to buildthe domain language and related generators. This investment has been found smallcompared to the payback. For example, the implementation of the watch modelinglanguage as presented above took two days. An additional five days were neededto design the architecture and assemble the framework Java components (withoutany prior Java experience), and one day to implement the code generator. Thisdevelopment effort also produced the first working watch model. From then on,new watch models could be implemented and tested in less than twenty minutes.

In addition to greatly speeding up development, domain-specific languages on top of frameworks may also offer other benefits:

• Routine work in framework use can be minimized
• The complexity of the framework can be hidden
• Rules embedded into the language can better guarantee that the architecture is followed
• The resulting applications will be of better quality, since they are built based on the rules set by the experienced developers who created the languages
• Changes in the framework can be made more easily available by changing the language in which applications are described. Applications using the newer framework can then simply be regenerated from existing models.

These benefits are not easily, if at all, available for developers using traditional manual programming practices: reading textualdocumentation about the framework, browsing components in a library, or tryingto follow a (hopefully) shared understanding of a common architecture. In short,if you are using or developing a framework you should consider defining amodeling language on top of it. It bears mentioning that defining adomain-specific modeling language is not only an interesting challenge—it is also a lot of fun!

The sample language and related code generators for Java and C are available from jpt @ metacase.com upon request.

Page 2   Back to the archive list