show all comments


Managing Co-Evolution of Domain-Specific Languages and Models: Part 1 on rename/update

January 08, 2019 15:11:44 +0200 (EET)

Domain-specific languages and related generators are refined when the domain or development needs change. As this happens frequently I'll describe in this blog series practices for managing the co-evolution of modeling languages and generators along with the models been already created.

I'll address the evolution from two angles. The first angle is part of the modeling solution evolving: It’s abstract syntax, concrete syntax or semantics. The second angle is the nature of the change: are we adding, renaming/updating or deleting things from the modeling solution. In this blog entry (Part 1) I'll focus on renaming and updating the metamodel.

Renaming or updating language elements in the metamodel has an effect on concrete syntax and often on semantics too. Moreover, it always has an effect on existing models. In MetaEdit+, renaming elements of the language (updating metamodel) is automatically reflected to all parts of the language definition, such as to binding rules on legal connections, to constraints, notational elements, dialogs, and most importantly to existing models. This enables fast and easy language updates without worrying if something breaks or that existing models don’t open anymore. Figure below illustrates this using the Digital watch from the evaluation version as an example. Here after renaming a language element 'State' to 'DisplayState', MetaEdit+ updates automatically all bindings (for connections with other objects), constraints (like unique name of 'DisplayState'), nesting with subgraphs and notation.

Renaming a domain concept is updated automatically to the rest of language definition

Even more importantly for language users, all models where 'State' existed are updated to follow the changed language. Figure below illustrates this showing a diagram in Diagram Editor:  now renamed 'DisplayState' is shown in the sidebar, property sheet, and status bar of the editor and all instances of 'State' are updated accordingly to 'DisplayState'.

Models and editor functionality is updated automatically to follow metamodel changes

An exception for automatic update is related to generators that are used to produce identifiers, conditions for notational symbols, checks or generate the code and other artifacts. This because the same (domain) term could be also used in other parts of the language definition, e.g. there could be a role type or a property type called 'State' too - which we would not like to update. So, when renaming or updating the metamodel, language engineers can use Advanced Find… provided by Generator Editor showing all possible places to be updated. Generator Editor below shows all generators accessing the renamed 'State' element.

Searching and updating generators with Generator Editor

Renaming a property type can be a special case if the language reuses the same definition in many parts of the language. If you want to rename the property for one case only but leave the other situations unchanged, then you may just rename the local name. This is in fact one way to establish language integration: Reuse the same property type (and its values with property sharing), yet name the property differently based on the type/language in which it is applied. Note that in MetaEdit+ any type as a langauge element can be used when defining other languages too.

The language definition features of MetaEdit+ are developed so that the domain-specific modeling languages can evolve along with the domain and language engineers can easily rename concepts knowing that existing models will be available and open for all language users in modeling editors.


Industrial Experiences on Domain-Specific Modeling: Panel summary

November 17, 2016 16:21:37 +0200 (EET)


The 16th workshop on Domain-Specific Modeling took place at SplashCon, Amsterdam. Papers and presentations are available online. This year we had also a panel with industry participants sharing their experiences on Domain-Specific Modeling. The full panel summary is available as pdf.

I was particularly happy to hear about the 5+ productivity gains reported as they are in line with what we have seen from others: e.g. reported in Modelsward 2016 paper on Industry experiences and what the company I work for can share publicly from customer cases.

One of the panelists put it perhaps most nicely: I have not seen a technique comparable providing similar results with productivity improvements. Therefore the real question is not if to apply MDE/DSM/DSL, but how to introduce it. Large portion of the panel went to discuss how to handle obstacles and follow the same success path as the panelists. If you are interested in speeding development activities I can recommend reading the panel summary.


Modeling for Internet of Things devices

September 18, 2015 15:32:58 +0300 (EEST)

I've been working a bit on the area of Internet of Things, and lately related with IoT device Thingsee. This device provides a wide variety of sensors (location, temperature, humindity, pressure, light, speed, etc.) along with wireless connectivity. For my purpose the size and complexity of the applications grew quickly so it felt natural for me that raising the level of abstraction from the code is needed. I also needed full access to device API like displays, handling multiple apps (called purposes) and linking between purposes available only in coding manually.

I've created during a weekend a language that covered most of the sensors along with code generator producing jsn code. The benefits of this become quickly visible: from a model shown below (harbor monitoring) 370 lines of code is generated to be run in the device. So far for the larger apps created over thousand lines of code is the generated.

Winter docking Internet of Things application

The video below tries to show you the idea: in 2 minutes an application for speed tracking is created and about 100 lines of code been generated.

Video on Internet of Things example

I then extended the language to cover more details and also add there features that are useful also for other purposes than for plain code generation. For example,

  • Safety issue: language warns me when creating application that is dangerous, leads to loss of property or similar (e.g. temperature is set so high that device should not be used there)
  • Language also prevents from generating apps that are illegal or incomplete (e.g. conflicting triggers, entering values for pressure, luminance etc. not possible)
  • Language also warns if something is not complete (e.g. unconnected states, no start state)

If you want to play with this language feel free to download it along with the example models (mec) and (mxs). To use it you need MetaEdit+ modeling and code generation tool, available at: After you start and login to MetaEdit+ import the .mec and .mxs files there and you should see sample apps too. Now you can start creating IoT apps pretty quickly and easily.

I included there also my applications for monitoring boat in harbor, during winter docking and while sailing. You may also freely extend the language and generator with other services and connections with other tools.


Modeling for Safety Engineering

January 12, 2015 12:27:41 +0200 (EET)

Related to the released EAST-ADL support in MetaEdit+, I was last month working a bit with safety engineering following standards like ISO 13849-1 and ISO 26262 that focus on the development of software for electrical and/or electronic (E/E) systems. Rather than creating models for safety analysis from the scratch we applied the already existing architecture models. As a result, safety engineers can choose the nominal architecture, or part of it, and translate it to equivalent safety model. In MetaEdit+ this model-to-model transformation takes existing functional architecture model and transfers it to a dependability model and to a number of error models depending on the size of the architecture chosen. Safety engineers can then adapt the model for various safety cases and run safety analysis calling the wanted analysis tool.

Due to customer request I applied Sistema tool but it would work similarly for other tools too. Tool integration was straightforward after having created a generator that takes dependability model and related error models and produces Sistema's project file and at the end opens the tool for it. Analysis tool then has already the safety functions, subsystems, blocks, channels etc. and can then be used to run analysis with different options.

This integration provides several benefits, including:

  • Ensures that safety analysis is done for the intended/designed architecture
  • Makes safety analysis faster as it is largely automated
  • Error-prone routine work is reduced

What makes this even more interesting is the feedback back to architecture models. First, models in MetaEdit+ could already include component specific performance levels permitting even more automated calculation of reliability values. In fact, my colleague even made performance level annotations back to MetaEdit+ by calculating ASIL values (as used in automotive). This kind of extension naturally called for modifying the language which was EAST-ADL in our case.

Another interesting direction is updating the model data and annotating it based on the analysis. In the sample screenshot below I've tried to illustrate this by highlighting blocks influenced with the blue color. If the analysis tool has open interfaces then MetaEdit+ and its integration mechanisms (command line, XML, API, generator-based parsing) can utilize it.

Error Model sample


DSM'14: Call for Papers and Demonstrations

June 18, 2014 11:05:19 +0300 (EEST)


This year the workshop on Domain-Specific Modeling will be held at SPLASH conference, Portland, Oregon, 21st October.

The 14th workshop on DSM continues to keep emphasizes also on the _work_ part in the workshop permitting the participants to leave with ideas for what to do next to improve the field. We are looking in particular for experience papers, demonstrations and also early level research descriptions in terms of position papers too. The call for contributions is available at:


Results of LinkedIn Poll: What is the most challenging part when starting to define your own modeling languages and generators?

May 07, 2014 16:10:21 +0300 (EEST)

Thank you for the comments and for the votes to the poll. See results below (I took the screenshot from the original poll ( because LinkedIn stated that these would not be any more available after mid May). Clearly the two most common challenges deal with identifying the domain and defining the languages. I voted for the first, partly perhaps because my work is often related to early phases of language definition dealing with issues like what to model and what to leave out.

Poll results

I should reveal that the same poll in a group on Domain-Specific Modeling (DSMForum) lead to different results as the actual language and generator development was not seen a big issue. For 50% in DSMForum the most challenging part is identifying a suitable domain, and 27% saw tool integration the biggest challenge. I think this could be because participants at DSMForum have perhaps more experiences on creating the languages and generators whereas in MDA group there are perhaps more people interested in using ready solutions than creating their own. For the same reason the number of participants in MDA group is bigger than in DSMForum including mostly language engineers only.

The poll has also a number of shortcomings if we evaluate the research method in terms of data collection and small number of answers, but as commented by others it reveals something interesting that perhaps would deserve a more detailed and better planned research. Having some demographics or background data could help to analyze the differences too, like those mentioned in the comments where Rafael sees hard to find a domain for DSL whereas Jens things that to be perhaps the last thing to vote for.


Scaling to large: > 100.000 model elements

March 25, 2014 15:18:34 +0200 (EET)

How about scalability? From time to time I hear this question when showing various examples of domain-specific modeling and code generation. It is also a bit hard question to answer as scalability can mean different things, like size of a diagram, number of model elements, depth of model hierarchies, number of languages used in parallel, number of concurrent engineers and obviously speed of the tool when working in the "large scale". I recorded a short session opening and working with something that can be called large: tens of different languages, thousands of diagrams, and hundreds of thousands model elements.

The video shows how MetaEdit+ performs: opening and working in large project look pretty much the same than when working in a small project.

Tool is obviously one, and important part when providing scalability, but perhaps the right question would be: how to define the modeling languages that acknowledge scalability?


On extending modeling languages based on user feedback

March 03, 2014 16:17:57 +0200 (EET)

Based on my experience, often the best ideas for the language and generators come when trying them out in typical development cases - in contrast to initial language definition (aka creating plain metamodel). By best I mean what language users appreciate the most. This lesson got recently confirmed again when working with a relatively large modeling language. By large I mean that the number of types (metamodel elements) is close to the number of types in languages like SysML or UML.

With this language case, there are in fact many different sub-languages and different engineers are interested in working on certain views and sublanguages only (e.g. Hardware, Functions, Timing, Events, Features, Failure behavior etc.). In fact, I can't see that a single engineer would really need all the parts of the language for his job. Still, for this domain in automotive, it is obvious to support collaboration among team members and provide integration among various views and sublanguages.

To give an example, we (2 language engineers) had defined modeling support to specify, check, and view allocations among functions and hardware. Usually both of these are graphical models, but for allocations some people prefer to have diagrams and others matrix. With MetaEdit+ we then support both and have various checking there (like that the same function is not allocated several times) along with generators (like for AUTOSAR style runnables etc). Later when the language was used with a bigger case it was told to us that a good way would be to illustrate directly in HW architecture the functions been allocated. We never had thought about that - nor the original language spec - but after 30 minutes work with the example we had to agree: makes a lot of sense and nicely illustrates graphically the integration of different views! See screenshot below showing HW components and how various logical functions are been allocated. This visualization support can be turned on/off as needed

visualizing allocation

Things obviously didn't stop here as we tested immediately also options to hide the ports when showing allocations so that the graphical model would show only that part of information that is considered relevant: allocations. Now having used this visualization support to meet language users' needs, we could do the similar visualizations for all other parts of the language, like show features been realized in a function, show all functions that satisfy a given requirement, safety cases been covered per function etc. Rather than rushing back to edit the language definition (metamodel) in MetaEdit+ we stopped and wanted to follow our experience: let's first see what kind of visualization aids/views are needed in practical work and then provide support for those. In other words, let's build the language based on the needs of the practice - not on what all could be done. The particular nice part of MetaEdit+ is that you can define the languages while they are been used and already existing models update to the new language version and features ... just like in the above case of visualizing function allocations in HW architecture.


How to Compare Language Workbenches

December 09, 2013 17:49:24 +0200 (EET)

Several ways have been proposed and applied to compare Language Workbenches (see a review of the work done). Language Workbench Challenge 2014 continues the tradition of inviting tools to be presented showing their solution to the challenge: implementing the support for the given domain-specific language. Past editions of LWC have followed the same pattern in 2011, 2012 and 2013.

LWC is great because it allows people to see different tools at the same time and see how they support the given case. Unfortunately its format is not completely suitable for comparison. One reason is that not all tools participating have implemented all the tasks. Secondly, effort to implement the solution has not been reported (man-hours, number of persons involved, expertise needed, etc.) and I would expect that that would be of interest to many. For example, in 2011 challenge only one participant and tool actually showed in live how the implementation is done. Third, LWC has focused on building a partial language solution from the scratch as in reality - similarly to software development - most work deals with redeveloping and maintaining the tooling while it is already been used. Fourth, there is hardly ever only one person for both developing and using the language, and I was particularly happy to see that LWC 2014 extends the scope to scalability and collaboration (larger teams, larger models, several language engineers working together). These same issues are at least partly demonstrated in a 9 min video showing how MetaEdit+ approaches collaboration.

Single event or study obviously can't address all the aspects of tool comparison, but LWC is bringing perhaps the largest number of tools to the table. Hopefully there will be many submissions. Visit for the submission guidelines.


Choosing the Best Level of Abstraction for Your Domain-Specific Language

May 28, 2013 10:11:07 +0300 (EEST)

Aligning a language closer to the problem to be tackled, regardless if the language is internal or external, represented as a graphical, textual, map, matrix etc. will almost automatically offer major improvements. Empirical studies (1, 2, 3, 4) have reported improvements for example in error detection and prevention, quality of code, productivity, maintainability and in communication and understanding of the system developed. The biggest improvements, however, are achieved when the level of abstraction is raised as high as possible. For me this means that the appropriate language-level abstraction should be the same as the problem domain. Or at least it should be as close as possible to the problem domain, area of interest that the language targets.

I have a pleasure joining the workshop on language design and implementation to defend my claim that the best level of abstraction for a language is as high as possible. I have no arguments against DSL'ish ideas of extending current programming languages, embedding a DSL to a host language, using better naming for API calls etc., but I don't see them raising the level of abstraction much from the implementation level. I'm afraid that these efforts then don't provide significant benefits to the development teams either.

At the workshop I plan to proof my claim by showing results from cases (partly public like 4, 5, 6, 7, 8, 9, 10) that develop and test different type of software, such as consumer electronics, telecommunication, product lines, medical, and automation systems with domain-specific languages, models and generators. These industry cases report 5-10 fold productivity increase. While many find such ratios hard to believe they are quite easy to demonstrate by showing some of the languages in action with a concrete case data. Obviously those cases target specific needs - as all DSLs - and the good way to find out if domain-specific modeling languages could help in a particular situation is trying it out, e.g. by running a short workshop as a proof-of-concept.

The industry cases also show that when raising the level of abstraction closer to the actual problem domain, traditional textual approach, dominating programming language design, is not necessarily the most suitable way. Instead the domain and the most "natural" way to express and find solutions in that domain should guide the language designers. For example, graphical block languages of Simulink and LabView have been de-facto way for engineers in signal processing and in control engineering, spreadsheets are heavily used in accounting, telecom standards are specified in MSCs of SDL, etc. Linear text presentation can still be generated to feed the compiler, integrate with existing libraries and code.

I can't avoid discussing tools, and I argue that the domain - area of interest - that the language addresses should again drive the language design, not the capabilities of a particular implementation technology or tool. Still DSLs can't survive without infrastructure such as tooling support. Too often companies have started to build this infrastructure along their DSLs, just to find out few years later that tool development is not their core business. And that building the tooling support took more time and effort than expected - yet to remember that tools need to be maintained too.

While metasystems, metaCASE tools, language workbenches etc. can help in creating the tooling support for the languages, such as editors, checkers and generators, most of them still require significant amount of resources (for a comparison of the creation functionality in tools, see [12]. Since maintaining the languages and supporting tooling is much bigger effort than their initial creation, perhaps at the workshop we can discuss issues after language design too. For example, at MetaCase we have tried to implement MetaEdit+ tool so that it supports also language maintenance, updates previously made models to a newer version of the language automatically (so that work is not lost and editors always open and work), support for multiple concurrent language engineers (each focus on different parts of the language (family), generators, testing while language is defined etc).

This year EC* 2013 combines ECMFA, ECOOP and ECSA and I expect that domain-specific languages and models are well covered from modeling, programming and architecture point of view!