Juha-Pekka on DSM

The 8th OOPSLA workshop on Domain-Specific Modeling takes place 19-20th October. The workshop format is a combination of paper presentations and demos, interactive sessions, and group work on selected topics. This structure was found effective during the past workshops. In this workshop we have for the first time an interactive panel (goldfish bowl) on DSM evolution and a keynote on model repositories. The proceedings and program are available at: www.dsmforum.org/events/DSM08.

JAOO, the premier developer conference in Europe, and in my scale definitely the number 1 in Scandinavia, starts next week. The conference includes a number of interesting topics, including a track on domain-specific languages. The DSL track, hosted by Glenn Vanderburg, covers Domain-Specific Modeling, internal DSLs by Martin Fowler and Language Workbenches by Neal Ford. I have the pleasure to start the track with defining modeling languages that work - raise abstraction and offer full code generation.

A more in-depth session with actual language creation and modification exercises is following the next day as JAOO conference sessions are followed by tutorials.

Hope to see you in Aarhus!

IEEE Software seeks submissions for a special issue on Domain-Specific Languages and Modeling. This issue will focus on particular benefits observed or quantified by domain-specific practitioners and designers, especially when capabilities that are unavailable using general-purpose techniques can be shown. See details here.

The idea of using standardized modeling constructs while defining domain-specific languages is often raised. Supporting arguments include easier language definition and reuse of existing already working languages and their constructs. Sometimes another, and usually hidden, argument is that the tool used does not allow anything else. A classical example is the use of UML profiles.

A much more powerful approach to define languages is to work directly with the metamodels. Based on our experience this is much easier too. Basically, we may:

1. Extend the existing metamodel (add new constructs, and I consider here extending existing language constructs with profiles one option too)
2. Modify the existing metamodel (add, delete, modify)
3. Define the metamodel from the scratch
4. Define the metamodel and possible reuse individual language constructs

With MetaEdit+ all these options are possible, but clearly 3 & 4 are the most successful ones: both in terms of the effort needed when defining the domain-specific language and more importantly in terms of the productivity gains obtained with the language. Option 2 would also be good, but this is not usually possible since the problem domain is usually different. We know this very well, since although the current version of MetaEdit+ comes with 1135 language constructs (metamodel elements), hardly ever existing complete languages are used as a basis to define domain-specific modeling languages. Parts of them, however, can be reused.

Consider for instance the domain of developing mobile phone applications ( Chapter 1 in DSM book ). A sample model for one mobile application is visible here . Would it make sense to even try to define similar high-level language using existing standardized modeling concepts? Obviously not. The use of profiles does not make sense since the amount of new stereotypes, tagged values and constraints would be huge. The language definition would take ages and we don't even speak about maintenance of it or making generator to produce the running application code. Also the use of existing standardized languages, such as UML, BPMN or SySML, as a basis and then starting to modify their metamodels is not a reasonable option: We would need to remove first over 99% of their concepts! If you don't believe, try to implement a modeling language for mobile application development based on UML metamodel (or profiles).

When it comes to the effort needed, the language for the mobile domain was implemented in 4 days along with the editor. This language was developed from scratch. Implementation of the generator took other 6 days producing executable complete code (in Python). Nothing was reused from existing modeling languages, although some constructs, like start and stop states, could be reused. In MetaEdit+ the effort to define Start and Stop state and their connections with other constructs is just 1-2 minutes, so reuse is not so crucial here.

This year OOPSLA has a panel dedicated on domain-specific languages. My aim is to be on “the Good” side. While this position comes naturally for me, having seen many times in industrial cases how productivity has improved 500-1000% when moving to DSM, it looks that all the other panelists want to be on the Good side too ;-) The great thing is that the panelists have different backgrounds and perspectives on creating, using and maintaining domain-specific textual or graphical modeling languages. Take a look of the panel and other program now available at OOPSLA website.

"MetaCase continues to demonstrate leadership in the area of Domain-Specific Modeling, improving developer productivity while helping the industry get the message about the power of DSM," said Alan Zeichick, editorial director at SD Times.

We at MetaCase are naturally deeply honored. It is very gratifying to be selected again and notify how the popularity of Domain-Specific Modeling is raising. It is not only exciting for us as a tool vendor, but thrilling for us as software developers. An increasing number of organizations - from automotive giants to embedded device manufacturers - are radically improving their software development performance, and we're proud to be leading this move forward.

It is particularly interesting to see how “meta” has became relevant in other categories than modeling too. See the complete SD Times TOP 100 list.

ICTNoviQ organizes a workshop on creating DSLs, including a contest: During the workshop participants implement a DSL for a medical device to create different medicine mixing processes. The domain is small and clearly bounded and the contest assignment suggests several ways to raise the level of abstraction. It is up to the language designer to choose which parts is put to the modeling language, what generators do, and which parts are left to the domain framework.

My schedule does not permit participation, but I implemented the language anyway - there is a promise that the designers of the “best” DSL will be rewarded ;-) Although I doubt that remote participation in competition is possible I sent my DSL, implemented with MetaEdit+, to the organizers anyway. If you are interested, take a look of the domain description as it nicely hints about several ways to implement the language. I’ll post my version of the language after the workshop (held 18th June).