Juha-Pekka on DSM

One typical place to apply domain-specific languages is to express variability: When developing multiple similar products you have a language that describes what is different among family members. In this post, and in coming parts, I discuss how modeling languages can be defined for product lines. For the start I use Krzysztof Czarnecki's classification as he nicely illustrates the range of variation and different ways to handle them (see figure below).

Wizards recognize the dependencies that pure parameter list ignore. Wizards typically expect that all functionality is already available and the number of variation points is usually rather modest. Feature models, instead, are used to manage a larger number of variation points but are still limited - by nature variability is not only in static structures or come in a structure of a tree. You may see an illustrative example of this by looking the Feature Model example I implemented (source available in MetaCase Forum). The sample feature model illustrates the variation in a digital wrist watch product line. With Feature Models we can’t express variation that deals with behavior side, like for instance execution order. While several extensions are proposed for feature models their best use is at planning and analysis phases rather than in creating variants.

Richer and larger spectrum of variability, notably also dynamic behavior, can be covered with domain-specific languages. Krzysztof uses the wrist watch as an illustration of a DSL This example product line is supported by two languages, one targeting static variation and the other, as illustrated in the figure above (see a bigger picture here), targets more the dynamic parts. Since the language's concepts (metamodel) can be instantiated in many different ways, a domain-specific language can handle a greater range of variants. If the language is based on some more expressive model of computation, like state machine in the figure above, there are also capabilities to create functionality that is not yet available! This is most relevant in practice since we almost never have situation in which all variability is available and we can just pick among them.

Looking from the language design perspective this means that variation is not expressed purely as values to be selected (parameters in a table or features in a tree) but also with dedicated types: Variability is supported right in the language. In terms of metamodeling variation point is not just a property value of an object, but it can be a role that an object may have, a relationship that connects objects, submodels or diagrams an object or a relationship has to specify its details, links to other elements properties, ports and so on. If we step outside the basic language concepts that modeling languages have, such as Graphs, Objects, Roles, Relationships, Ports, Properties, further variation space can be set with rules related to languages, such as how many instances can be in a model or a single diagram, how many times a certain element may connect to another kind of element, etc.

I’ll discuss guidelines for creating domain-specific modeling languages to specify variability in coming posts.

JAX 2008 runs this year a special track on DSLs. I have the pleasure to start the day and demonstrate the new version of MetaEdit+.

This is a bit special kind of day since it is heavily tool focused. It allows to show something concrete and working. I plan to show the bacic goodies but also the advanced stuff like language evolution (change an existing domain-specific language in use in all different ways), update models automatically to the new language version, integrate changes in metamodel to generator, link back from code to models and other features our customers have found relevant in practice. Reversing code to models with MERL, Icon Editor, new metamodeling tools are also on my list but I’m afraid my 1h slot does not allow to show all the details.

Hope to see you at Wiesbaden!

While the metamodel as a word has become “acceptable”, or even fashionable, during the past years, many of those claimed to be a metamodel can actually never be properly instantiated as a language. One clear reason is that the metamodel is incomplete since the metamodeling language used does not address aspects that need to be specified while defining a modeling language, such as uniqueness, occurrence, mandatory values, n-ary relationships, naming policies, reuse rules, integration with other languages etc. without forgetting notation.

Let’s take AUTOSAR as an example since it is a publicly available at www.autosar.org. The current metamodel is specified with over 200 class diagrams. No, it was not a typo, you read it correctly: over 200 diagrams. For me it looks that all this work is done to define the interchange between tools (or something) rather than defining 4-5 modeling language(s). The use of class diagrams (or MOF) to specify the metamodel makes the reading of the language definition particularly hard since it is pretty difficult and time-consuming to identify the different languages (or diagram types). For instance, now the specification lacks the concept of a language - which is pretty basics of language definition! This is obvious since the class diagrams do not recognize such concepts. I found this odd: while seeking to define domain-specific modeling language there is at the same time a belief that a general purpose language (class diagrams here) can be used to specify metamodels!

I see that that much better would be to use a domain-specific language to specify the metamodels - obviously. For instance, in GOPRR the different languages are directly visible in one diagram as shown below in Figure 1. This diagram shows also integration and links between the various language concepts.

For each individual language there is then own separate specification described again as own diagram. Figure 2 shows the different objects, properties, relationships and roles of one language (Software Component Diagram). As a result, the specification of the AUTOSAR metamodel consists of 5 different GOPRR diagrams instead of 217 class diagrams!

I’m naturally biased here, but I would still argue that the metamodels in above figures is also easier to read and understand since different language concepts are clearly identifiable. All concepts are not anymore described as classes. Actually, the use of class diagrams also makes the work of language development unnecessarily difficult since it does not really help in specifying modeling languages. For instance, we can define an association type or a port to the language which never connects any other language concept. This is obvious since a general purpose language can’t guide you in language definition.

Naturally the major issue is not yet even tackled: running and testing the metamodel. In MetaEdit+ after specifying the 5 GOPRR diagrams you could immediately start using the AUTOSAR language and test it. This kind of iterative process would greatly speed the language development and improve its quality and applicability within the domain. The folks at AUTOSAR are doing good work but a proper metamodeling language would help. I see this is especially crucial for them since there are so many companies involved, layers etc so that creating something easier to understand would be much appreciated.

I'm pleased to announce that a new book, devoted to Domain-Specific Modeling, is now available. I have co-authored "Domain Specific Modeling: Enabling Full Code Generation" with my colleague Dr. Steven Kelly. Our intention for writing this book was to share some of our many DSM experiences with the software development industry and to support experienced developers in defining their own DSM languages and generators. See the preface here.

At www.dsmbook.com you can find more details including other previews, as well as the five example DSM cases described in the book. You can review and run them in the free, evaluation version of MetaEdit+ while reading the book. I hope you enjoy!

I participated last week at OOP conference in Münich and tried to follow all talks on domain-specific theme - even those given in German. First time I had a chance to hear about the experiences on using Intentional Software’s approach as Markus Voelter and Henk Kolk gave a talk titled Democratizing Software Creation. This introductory talk described an ongoing work using Intentional Software’s approach to create a domain-specific language and tooling for managing pension related rules. In their case the language user was a non-programmer, a pension expert, and the language used a spreadsheet form to illustrate pension rules.

I liked the talk since it nicely illustrated the benefits of raising the level of abstraction with a domain-specific language. The benefits were similar as those reported by others. What I didn’t like was that the speakers could not answer to the basic questions made by the audience. I got the understanding that they were simply not allowed to speak about the technology. On the experience side Henk Kolk described an interesting lesson about the size of the domain. After having defined a first pension domain language for one company they started to create “Unified Pension Language” that would satisfy the needs of several pension companies in the Netherlands (and perhaps in other EU countries too). They never finalized the unified language simply because the needs among pension companies were different. This goes nicely along our experiences on language and generator creation: the narrower and restricted the focus can be set the easier it becomes to provide support for specification work and automating otherwise manual task. Often the best way to restrict and define a narrow domain for the modeling language is to focus on one company only.

The MDA initiative emphasizes transformations between different models. While interesting, I wonder what problem it tries to solve and how realistic the vision is. Briefly, in MDA after creating a CIM level model, we can transform it to a PIM level, and after refining the PIM model we can transform that to a PSM (or to other PIM) model, refine again the created target model and then transform that to code (or other PSM). As described in the MDA vision there is usually need to update the generated code again before compiling or interpreting it.

Needless to say but this is pretty complex to handle, version, teach and introduce into organization. Most of all, I don’t see how such transformation chains can work in practice. For example, I’m curious to know how people consider changing the models that have been used already in transformation. Remember the MDA vision of refining the target model. What happened to changes (refinements) made to models initially created via transformations? If the languages applied different metamodels (or profiles) how you versioned and managed them? So, if anyone has experiences from practice on such model refinements during transformations, please let me know (jpt at metacase.com)?

I have detected only few situations in which model transformation makes sense. First is when integrating different tools (e.g. there is already a code generator in place that needs input in a particular format). You then hardly ever want to change the input for the generator manually but rather want the transformation be complete. The other case is when the other language is a subset, e.g. when we want to hide information from a different type of users or from subcontractors. This is fine especially since the semantics between two languages are the same. Third case is when transforming legacy models for the newly created domain-specific language. However, here usually almost always the model transformation is partial as legacy models don’t contain all the needed information and have different semantics. Also due to various formats and tools used for create legacy models you need to have different options for transformation.

The 12th International Software Product Line Conference will be held 2008 in Ireland. The call for submissions is now available. In addition to papers we are also looking for demonstrations of state-of-the art systems, languages, environments and applications for product line engineering. (See submission details). Among the topics of SPLC many fit well to demonstrations too, like:

• Application derivation
• Code generation
• Domain-specific languages
• Model-driven engineering
• Techniques and tools for product line adoption
• Testing, modeling & formal verification of product lines
• Variability modeling and variant management