hide 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.