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 2

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

An incremental approach is often the best way to build a domain-specific language: first define a small part of the language, then modelwith it, define generators, make changes to the language, model some more etc.After getting it working for the main parts of the framework, we extend thelanguage to cover other parts and finally the whole framework. This is also anatural approach for cases where the framework and supporting components are not yet completely available.

We can divide the process for defining modeling languages and their generators into four phases:

1. Identifying abstractions and how they work together
2. Specifying the language concepts and their rules (metamodel)
3. Creating the visual representation of the language (notation)
4. Defining the generators for model checking, code, documentation, etc.

Usually the process proceeds in this order, iterating back as necessary. We focus here on the second step: specifying the modeling language.The first step, abstractions, is largely already set by the component frameworkor the library. The framework thus nicely bounds the task of creating themodeling language: we need only support what the developers of the frameworkhave chosen to support. The task remaining for the language designer is thus tomake the framework and its services easily available for application engineers.

When defining the modeling language we should not, however, think of models as directly visualizing code or framework API calls. Instead, weshould seek higher-level abstractions than current programming languages offer:otherwise we will just be reinventing the flowcharts used to document Cprograms! In addition to the framework itself, sample applications built on ithelp us to see how the framework is expected to be used. The sample applications act also as good input and test cases when defining code generators.

Raising the level of abstraction with a language not only improves productivity but also enforces correct use of the framework. This iswhat every architect hopes for. Putting these rules and guidelines right in thelanguage specification makes it impossible to specify applications or featuresthat are not based on the framework. It also saves developers from having torefer constantly to in-house "design guidelines" documents – which are probably out of date anyway.

Defining the modeling language

Language definition deals with specifying the modeling concepts and possible connections between them. A common starting point is touse existing ways of modeling that are used to talk about that kind ofapplication, as opposed to its implementation. It is particularly important toavoid modeling languages like UML class diagrams, which are clearlyimplementation-focused and not at all specific to your problem domain.

In the simplest cases, when all possible functionality is already implemented by the framework, the variation can be specified as a listor tree of parameters. In our digital wristwatch example this approach could beused to capture the number of buttons and icons. Usually it is not this simple,since there are also interdependencies among the parameters: these call for atleast wizards or decision tables to specify the possible variation.

Neither of these, however, is adequate as most variation is more complex than choosing among alternatives. For example rather than justchoosing if the watch has an icon or not we need to know also the circumstanceswhen the icons are used. Also, this approach can only work if all code isalready written: it is no help in the most typical situations where we do not yet have the application code.

Parameter lists or feature selections are not adequate when variation goes beyond static configuration to deal with dynamic or behavioralcode. These cases require models more complicated than a simple list or tree,whose every element is known in advance. The modelers must be able to create newelements and link them into new structures. We saw an example of such a modelinglanguage in Figures 1–4. Whereas a list or tree with 5 Boolean choices willallow at most 32 variants, with such a language there is no limit to the number of variants and indeed new applications that can be built.

Using known models of computation

Since the watch applications are state based and event-driven we could take state machines as the basis for our language definition. Thismodel of computation can then be enriched with the domain concepts and rules.

Figure 5 illustrates the basic definition (metamodel) of a state machine. The metamodel describes that each state machine can have one Start object initiating the state machine with a transition leading to a state. The State object has two properties: its name that is unique inside the model and a description text. A State can be connected with a Transition to another State or to a Stop object (both grouped together here into one "Objects in binding" group, since they are both bound in the same role in this Transition).

Figure 5. Basic metamodel of a state machine

A language also has rules that constrain how models can be made and modified, to ensure model correctness. These rules are specified in themetamodel along with the language concepts. For example in state machines, asspecified also in the metamodel in Figure 5, a Start state can have no incoming transitions, and in each state machine there can only be one start state.

Extended languages with domain-specific concepts and rules

We can now enrich our modeling language with watch-specific concepts and rules. This means mapping the domain concepts and frameworkservices to modeling elements. Some of them can be seen as the objects in themodeling language while others could be better captured as object properties, relationships, sub-models or links to models in other languages.

For example, in a watch each application state can have a display function that calculates what time to show: the current time for a Timeapplication, the time plus a time zone offset for a World Time application etc.Another watch characteristic is that rather than a general concept of event, transitions in a watch are caused by pressing buttons.

An explicit concept of Button is thus added to the modeling language specification. Figure 6 shows an extended metamodel where State has twoadditional properties. A Display that is shown when a state is active and a Timeunit (hour, min, sec, hundredth) to indicate if certain part of the time is blinking – e.g. when that part of the time is being edited.

Transitions are modified to describe watch applications more precisely: users pressing buttons of the watch trigger transitions and during atransition an action can be performed. Both of these are not mandatory: themetamodel in Figure 6 has role cardinality 0,1 in transitions related to Action and Button concept.

Figure 6. Extended state machine with domain-specific transitions

In a similar manner, the other domain concepts and framework services can be added to the language specification. For example the frameworkgives services to use icons: they can be turned on or off. This is specified in the metamodel (Figure 7) with a relationship between an action and an icon.

The relationship also has a property to specify which icon service is used (on, off). Another framework service is ringing an Alarm totrigger a special transition to a State. The metamodel in Figure 7 also includesother framework services like setting and calculating time via variables, describing how the DisplayFn calculates the time and how the Alarm is set.

Figure 7. Extended state machine with watch-specific actions

This language specification is formal so it can be instantiated and used as a modeling language. Actually all models illustrated inFigures 1-4 are instances of the metamodel. Design models are therefore always based on the concepts and rules set in the metamodel.

Page 1    Page 3   Back to the archive list