show all comments


Managing Co-Evolution of Domain-Specific Languages and Models: Part 3 on deletion

February 21, 2019 11:27:00 +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 the evolution of DSLs - without forgetting the models already been created. Part 1 addressed renaming, part 2 adding and in this part 3 we focus on deleting elements from the language.

Option 1: Remove, don't delete

Before deleting anything permanently, language engineers should first consider if it is better just to remove the unwanted elements (types) from the language making them no longer available for future model creation. Note that this “light deletion” approach allows still using existing models – after all models have been valid and the generator support for them exists and works.

Removing types works like other metamodeling tasks in MetaEdit+. Figure below illustrates this by showing on the left how concept ‘Alarm’ is currently been removed from the language with Graph Tool. When this change is saved the next time models are opened all editors, like Diagram Editor on the right, provide the updated functionality. After type removal, MetaEdit+ does not allow creating new Alarms (note that type ‘Alarm’ is not available on toolbar), but existing alarms are still available and shown in the models.

Removing language concepts

This light approach also allows users to see and update design data from the past, while guiding them not to use the old language concept anymore. If preferred, alarms can also be decorated or marked with additional symbols or reports as described in part 2.

Similarly other kind of language elements, like relationships, roles, subgraphs links etc., can be removed from a Graph Type: their instances as model data is available but creating new ones is not anymore possible. If the removed type is a property type, it can also be made read-only. In MetaEdit+, adding ‘_’ (underscore) before the local name makes it read-only. Adding double underscore hides the property from editors (Diagram, Matrix, Table) and browsers but both ways keep still existing values available e.g. for generators.

If the deletion is not related to a type but to its notation, the change will be automatically reflected in all models: Visualization updates automatically as language engineers defined them with Symbol Editor. Also deleting a model checking report or generator module with Generator Editor is safe to do as that does not influence to existing models.

Remove with possbile salvage

Removing a concept like ‘Alarm’ as in the above example removed it from the Graph where it was applied. It could be still used in other languages too. However, if we don’t want to see a particular language concept at all we can remove it from users. Type Browser provides mechanism to remove language elements from the repository. Type Browser also allows language engineers to view and access all instances of the type to be removed. During removal MetaEdit+ then checks and informs language engineers if they are removing a language element which is actually still been used in parts of language definition (e.g. in constraint checking, binding rule etc) - or even if it is used in some another language. Such checks make managing the language evolution safe and easier for language engineers.

Removal with Type Browser over permanent deletion provides a very nice bonus: if it is later found that removal was not a good idea, language engineers may bring back the removed parts – and MetaEdit+ will also restore their instances too! This way already existing model instances (like ‘Timer Alarm’) can be used in models without creating it again. Choose Salvage Types… in Type Browser to bring back removed language elements.

Bring removed types back with Salvage

MetaEdit+ traces automatically all changes to models and their elements (like to ‘Timer Alarm’) and model history can be viewed also for the deleted language concepts with Changes & Versions tool. More on versioning models and metamodels (languages) later in Part 4.

Option 2: Permanent deletion

If permanent deletion is preferred, language engineers should first inspect how the deletion influences to the existing language. For example, it could be that the removed type may have connections or constraints which then also need to be removed. Info Tool in all metamodeling tools provides such traces. It shows all language definitions where a given type has been used and well as what types the selected type is using.

Similarly language engineers should inspect how deletion influences to existing models. Before permanent deletion of types all their instances should be removed too - either via browsers providing access to them or with API. Often, however, deletion involves contextual decisions dependent on the model, and then the best is to implement model check functionality similarly to that suggested earlier when adding new constraints (see part 2). This allows users to check their models and update them before permanent deletion of language elements.

Permanent deletion of languages and their concepts is done with Type Manager. Removing a type removes automatically also its notation, dialogs, toolbar etc definition.

Option 3: Moving language definitions

Finally, if languages have been created without having models yet, it is also possible to export the language definition to a file. This is perhaps most typical in early phases when different language definitions are tried out. Type Manager allows exporting language definition to a binary and XML format. This operation leaves automatically all unused types been defined temporarily to the source repository. After export, a new repository can be created and language definition can be imported there. This approach can be also used when language engineer wants to share updated language version for teams using different repositories (more on versioning later in part 4).