When defining a domain-specific language, or perhaps better to say here, a product line specific language, it is usually the best to start with by analyzing commonality and variability. If some parameter tables or feature models are already available they can naturally be used as a starting point. When looking the feature models, individual features usually map to objects of a modeling language and leafs of the feature tree are likely properties of the modeling constructs. Consider the two models above: A feature model on the left and a watch-specific language on the right hand side. They basically express the same product line: How watch products consists of a number of applications and of one display. Each display further contains icons, time units and a number of buttons.
The difference between these two models is that they operate at a different level (and satisfy a different purpose). The domain-specific model on the right specifies individual products and shows five different watch products. One of them, called “Ace” is inspected in further detail by showing its display specification. A display “X334” shown in the dialog specifies the icons, time units and buttons of the “Ace”. The dialog thus covers the variation expressed in the feature model, except the root feature “Watch Model” and “Application” part (more on the latter later).
A closer mapping to the feature model we can see from the metamodel of the DSL since the metamodel does not include instance data, individual product specifications. The feature tree is basically mapped to the aggregate structure among the language constructs. Instead of using feature models as a starting point we may naturally apply parameter tables too, albeit they usually lack of formal specification of the dependencies among parameters (among variation points).
Most importantly, a domain-specific language can also cover variation that feature models, wizards or parameters tables can not express. This makes them to be on the creative side in Czarnecki’s scale. For instance, the metamodel above expresses that display names must be unique: we can’t have two displays with the same name meaning different displays. The expressiveness of DSLs over feature models becomes more evident when inspecting variability that is dealing with dynamic, behavioral variability. If we stick with the digital wrist watch product line, we have also variability in terms of:
- execution order among various watch applications (e.g. coaches prefer stopwatch whereas travelers prefer worldtime)
- how buttons are used to activate and use watch applications
- how and when icons are shown
- how time is displayed and calculated, etc.
This kind of variation would be impossible to specify in feature models or other techniques that focus on static variation only. In DSM, this variation can be expressed in the language too by adding them to the metamodel. This is done by having various kinds of relationship types between the objects, role types the objects may have, port types and port rules, various submodel structures and so on. For instance, execution order among applications can be specified by a transition relationship type. In addition, two roles types are needed to specify the direction of the transition, like ‘From‘ and ‘To’ roles.
In practice, covering variability often calls for multiple languages. A typical pattern is to have separate languages for static variability and for dynamic one. The metamodel below describes behavioral variability in a single watch application. You could see it describing the variability in an application: something that we could not describe in the feature model shown above. The metamodel identifies various transitions among the watch applications, their internal states and different kind of actions a watch can have. Such as set time, calculate time, alarm-related actions, icon visualization and so on. When the metamodel is instantiated it can be applied to specify watch applications as shown in the previous post.
The two metamodels illustrated above, however, are not isolated but integrated. This integration is simply needed because a variation can deal with multiple aspects. Consider for instance the specification of icons in the digital watch. In the metamodel (and in the feature model) we specified that there can be a number of icons, but not yet when and how they are applied. In the second metamodel, addressing behavior, the same icon concept is now used in relation to actions: showing and hiding the icon (these are highlighted by a red circle).
The integration among several languages can be specified again via the common metamodel. When the languages are integrated the life for developers becomes easier as they don’t need to maintain the same information in two (or more) places. Since both metamodels can be instantiated in practically infinite different ways the possibilities to handle greater range of variation and create new functionality that is not yet developed makes DSM especially suitable for product lines.
