show all comments

DSM

Managing Co-evolution of Domain-Specific Languages and Models: Part 1 on renaming

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 we describe in this article series practices for managing evolution of modeling languages along with the models that have already been created.

The evolution is addressed from two angles. The first angle is the nature of the change: are we adding things, renaming/updating or deleting things from the modeling solution. The second angle is the part of the modeling language been changed: It’s abstract syntax, concrete syntax or semantics. In this first blog entry, we focus on renaming and updating the metetamodel. In part 2 we address language extensions.

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+, updating the language definition (aka updating the metamodel) is automatically reflected to all parts of the language definition, such as to the binding rules on legal connections, to constraints, submodel structures, notational elements, dialogs, and most importantly to existing models. This enables fast and easy language updates without worrying that something breaks or that existing models don’t anymore open.

Figure below illustrates this using Digital watch from the evaluation version as an example. When a ‘State’ object is renamed to ‘DisplayState’, it’s bindings with relationships and roles, constraints (like submodels and unique name) as well as notation is updated automatically.

Update in metamodel reflects to notation, checks, dialgos, toolbar etc.

Even more importantly in terms of evolution, all models where State existed are automatically updated to follow the new metamodel (see figure below where ‘DisplayState’ currently been shown in the sidebar, property sheet, and status bar).

Models updated automatically when metamodel changes

The only exception in terms of automated update is related to generators that are potentially used to produce identifiers, conditions for notational symbols, checks or generate the code. This because the same term could be used also in other parts of the language definition, e.g. there could be role or property called State too. So, when renaming or updating the metamodel you should use Advanced Find… provided by Generator Editor showing all possible places to be updated. Generator Editor below shows all generators accessing the renamed element.

Updating generators after renaming language element

Renaming a property can be a special case if the language reuses the same property definition in many places of the metamodel. If you want to rename the property for one case only but leave the other situations unchanged, then you may just rename the given local name. This is in fact one way to establish language integration: reusing the same type and its values, yet name the property differently based on the type/language in which it is applied.

The language definition features of MetaEdit+ are developed so that the languages can evolve along with the domain and language engineers can make easily changes knowing that existing models will be available and open for all language users.