Juha-Pekka on DSM

Software Engineering Radio, the podcast for professional developers, runs an episode on Domain-Specific Modeling. The episode focuses on technical topics and using DSL, models and code generators in practice. The practice part is addressed by discussing our experiences backed by some public industry examples.

I had the pleasure being interviewed by Markus Völter as his comments and arguments made the interview lively interactive - rather than having a monologue or the question and answer chain. As an example, one particular topic in the first half was the discussion on the need of model-to-model transformations. With a small example Markus asked how to model with state machines that from each state an emergency transition should be possible without using M2M. If the case of emergency would be the same for all the states and the state machines there naturally would be no need to model emergency handling at all. If there is variation among these two: systems with emergency and systems with no emergency, a single Boolean property for the whole system would be enough and the MetaEdit+ generator would be:

If :Emergency Stop; then subreport ‘_EmergencyStop’ run endif;

This line appears only once in the generator and it ensures that all systems created have either no emergency handling or have it for all the states. The above choice of emergency transitions needs to be specified also with M2M. The above generator line, illustrates that the language recognizes emergencies policies (we can ask form the model if Emergency Stop is used) and developers we can therefore see completeness and correctness already while creating and editing the specification. Variation in related to Emergency handling could be also specified also per each state machine or each state, if needed.

To look the scalability of this idea, my earlier blog entry copied the case from Martin Fowler, where he introduced the need for different kind of reset events which is a bit more complex than the above Boolean case. From the example you can see that there is no need to specify any transition lines to the reset event object (top right in the diagram) and the code gets still generated.

Last week I was asked: "What kind of language user support do the tools generated with MetaEdit+ provide?" This is obviously one of the most relevant questions when introducing the created DSM solution for the team.

A short technical answer is: "MetaEdit+ creates a language help automatically based on the data entered by language developer". Modeler can then choose Help | Graph Type in editors to open help on the language concepts, their properties, symbols, constraints and available generators.

The usefulness of the created language help is directly depending on what kind of information is given on each language construct. In addition to definition or description of the concept, we may also consider entering help on how to identify the model elements, suggest a naming policy (if not explicitly specified already in the metamodel), describe the constraints or propose modeling practices to be followed.

Staying still on the technical side, people sometimes also prefer to have the language described in additional documents, slides etc. For that purpose we can copy the automatically produced help (keep CTLR pressed while opening the language help to copy it to clipboard). While we may also consider giving the metamodel itself as a document, it does not normally serve language users. They want to see the notation and concrete examples. Examples are particularly good since they have already some context and can be used to learn the language in an interactive manner - being part of the tool. Ready example models also allow running generators to produce code, documents and other outputs.

Creation of the example models does not require much effort since those are already available. They were created to test the language and pilot it in a small project. In fact, often the models created in the pilot are used as examples for the language users. These examples can be provided separately or in a tutorial project along with other projects stored in MetaEdit+ repository. Examples models can also be generated into documents and HTML files using MetaEdit’+s document generators. These documents on language use can be also directly linked from existing tool help of MetaEdit+.

Additional support for the language users are the traditional ways, like training. While learning a language is easier when it uses known concepts and maps to familiar domain, training can be guided towards how to apply modeling languages more effectively. For instance, we provide a 2 day language user training that covers also modeling operations like different copy/paste approaches, model hierarchies, reuse and find/replace for refactoring in addition to language help (more at: http://www.metacase.com/services.html).

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.