show all comments


Managing Co-evolution of Domain-Specific Languages and Models: Part 2 on adding

February 01, 2019 13:56:07 +0200 (EET)

Domain-Specific Languages and related generators are refined when the domain or development needs change. As this happens frequently we describe in this article series practices for managing co-evolution of languages and models. Part 1 discussed updates with renaming and part 3 deletion. In this part 2 we focus on adding elements to the language, and demonstrate how the change reflects to existing work done.

Adding new elements to the modeling solution is usually safe as it does not affect existing models. Such a new element could be a new concept (abstract syntax added to metamodel), notation been part of the concrete syntax, or semantics such as new generators or checks.

As soon as any of these elements are added in MetaEdit+ they can be immediately applied in all modeling editors, browsers, generators etc. And when using multi-user version for collaborative modeling, such additions can be automatically provided to all language users. This is important as it ensures that people all are using the up-to-date language version.

However, if the addition is related to semantics and constraint then its influence on the existing models needs to be checked as there may be models that do not satisfy the new constraint. Language engineer don’t need to make language updates blinded without considering infuence to existing models as Type Browser gives access to all the instances for the given type. Language engineers can also use Info Tool for traceability among elements in language definition. 

If the change is contextual (i.e. models cannot be updated automatically but require input from the model creator to make the right change based on the model data), language engineer can create a model checker with MERL notifying language users on the changes needed. This check can be run separately when moving to the new metamodel or highlight the elements requiring update with a symbol definition as illustrated below: a conditional symbol element is added showing red text when element has illegal values. The same could be applied for other kind if changes too, like if model has illegal objects, relationships, roles, ports, submodels, non-uniquenesss, etc.

Defining a model uddate guidance

Figure below illustrates how this would work in practice and show in Diagram Editor. Here temperature sensor has previously accepted too high temperatures, and now a new constraint has been added restricting the value. The model checker in this example is run in two places to illustrate alternative possibilities: First temperature sensors having too high value are annotated directly in the symbol (giving right context for modeler), as well as in LiveCheck pane at the bottom of the window: Clicking the reported element selects the respective element in the diagram and in the design context so developer can decide how to update the temperature in the given context.

Diagram Editor opened showing update needs within context

Finally, if the type of model update is not contextual and thus can be automated, you may use API to update models programmatically. Our experiences, and backed also by research, indicates that this option is not typical albeit one might think so in the beginning.