On the Combination of Domain Specific Modeling Languages

On the Combination of
Domain Specific
Modeling Languages
Antonio Vallecillo
GISUM/Atenea Research Group
ECMFA, Paris, June 2010

Domain Specific Modeling Languages
A DSML permits describing (and reasoning about) a view of a
system using a language close to the domain experts and
with the right size and level of abstraction
A system specification is made from many views, each one
using its own DSML (vocabulary, rules, notation, style,…)
Yet they need to be related and consistent…
…they all describe the same system!
ECMFA, paris, June 2010A. Vallecillo: "On the Combinination of DSMLs" 2
[Picture borrowed
from J. Bézivin]

Viewpoint specifications
System
Owner
Programmer
End-user
Maintainer
Tester
Multiple aspects
of a system
Different
stakeholders’
views
Start Shift Accelerate Brake
Engine Transmission Transaxle
Control
Input
Power
Equations
Vehicle
Dynamics
Functional/Behavioral Model
Structural/Component Model
Performance Model
Mass
Properties
ModelStructural
Model
Safety
Model
Other Engineering
Analysis Models
Cost
Model
System Model

What is (in a) DSML?
[Picture borrowed
from E. Rivera]

Metamodels and models

Combining DSMLs: Issues to address
How to combine the independent views?
How to build a “combined” language?
Combined Metamodel with the Abstract Syntax?
Combined Concrete Syntax?
Combined Semantics?
How the combined language relates back to the
original ones (and to their related tools)?

In this work
We discuss different scenarios of use, and different
mechanisms for DSML combination; the advantages
they introduce, as well as their limitations
We propose a general proposal for combining DSMLs
that subsumes them, based on the concept of
unification and its realization using model-driven
techniques

Some remarks
The combined (or unified) language might not be
“domain specific” any more
It is usually to complex and cumbersome for user
consumption and usability (understandability,
operability, learnability, attractiveness,…)
Tools should be responsible for constructing it
The user work with the individual views
Tools build the model and extract information from it
[At the end of the day a model is nothing but an artefact
built to answer questions about a system under study!]

An running example
Adapted from Peter Linington’s “Black cats and coloured birds
– What do viewpoint correspondences do?” [WODPEC 2007]
Four viewpoints of a system, each one focusing on a different
aspect

Creatures viewpoint
Various kinds of creatures
They breed true and are not cannibals
[Many thanks to Martin Gogolla for suggesting the OCL expressions for this example]

Habitats viewpoint
Inhabitants live in a habitat
There are different kinds of habitats

Colours
ColouredThings have a colour
An operation establishes the rule for mingling two
Colours
A colour clashes with other strongly contrasted colours

Travelling around
A Position indicates where a Thing is in a moment in time
A Movement transports together a set of things (which are
in the same place) from one location to another using a
sequence of moves
A Move establishes a valid path between two positions

Three main issues to be addressed
How to relate the elements from the different views?
How to integrate the models of the views into a
common workable model?
How to extract information (and other views) from the
common model
Viewpoint relation
Synthesis
Analysis

Correspondences
Simple correspondences establish the relationships
between elements in different viewpoints
Creatures.Creature <-> Habitats.Inhabitant
Creatures.Creature <-> Colours.ColouredThing
Habitats.Inhabitant <-> Movement.Thing
Habitats.Habitat <-> Colours.ColouredThing
Correspondences do not form part of any viewpoint
Constraints on Correspondences:
We do not want to have red cats or blue woodlands
The colour of an inhabitant cannot clash with the colour
of its habitat!

Correspondences

Existing approaches for VP synthesis
Metamodel inheritance
Metamodel extension
Language embedding
Metamodel merge

Model inheritance [7,10]

Model Extension [6]
The combined metamodel contains the “duplicate-free
union” of the metamodels being combined
The user defines the elements that should be “unified”
based on the correspondences between them

Combined model

Language embedding [8,9]
UML, Skala, Haskell, Maude… are typical host languages
The embedded language(s) can use the syntax of the
host language, its module system, associated tools, …
The embedding is defined in terms of a mapping that
defines how elements of the embedded language are
represented in terms of constucts of the host language
Embedding can be used to provide (translational)
semantics to a language

Language embedding

That was easy and painless,
wasn’t it?
But… Does it always work?

Problems of language embedding
It means re-definining the embedded languages
E.g. MSCs and statecharts in UML 1
This hinders the use of their native associated tools
The concrete syntax is completely distorted
Semantics adaptations are frequent
E.g. MSCs and statecharts in UML
The relations between the view elements gets blurred
The host metamodel is complex
It does not have mechanisms for expressing correspondences
Users lose the conciseness and simplicity of DSMLs and
are forced to use a complex language
Combination of embedded languages is not properly
defined (e.g., SysML+MARTE?)
Users soon start making use of elements of the host language
outside their viewpoint languages!

Other option: (Meta)model merge

Model Merge [5,7]
An algorithm for merging models based on
correspondences defined between them
The merge is again the duplicate-free union of the
model elements

Problems of metamodel merge

It might work…

More problems of metamodel merge

Another problem
How to merge these two metamodels?

And what about this?
How to merge BPMN and UML activities models?

And what about this?
The situation is not that simple, though…
or and

A DSML combination approach
based on Model Unification

Model Unification

Some comments
Inspired in the original notion of Viewpoint Unification [15]
The form of unification depends on the DSMLs to be combined
The kind of projections depend on the relationship between
the DSMLs and the unified language
Refinement; abstraction; equivalence; implementation; …
Viewpoint consistency is checked using the projections and
the fact that they have to respect the correspondences
Model unification subsumes all previous approaches
The unified model can be developed using model inheritance,
extension or merge – whenever possible
The unified model corresponds to the “least developed
unification” of [5]
Projections are the inverse of mapping functions

module t4;
create OUT : Movements
from IN : MG ;
…
rule inh2thing {
from i : MG!Inhabitant
to t : Movements!Thing
}
…

Does this always work?
Sometimes it is not possible (inconsistent views)
1 1
1 1

Does this always work? (II)
Sometimes there are several choices: No unique
unified metamodel
Continuous refines discrete, or discrete refines continuous

Viewpoint analysis
From the unified metamodel and the set of projections:
The projections are mappings that provide the bridges
between the unified metamodel and the views
Viewpoint analysis is automatic if projections are
defined in terms of model transformations
E.g., we have defined ATL model transformations to
implement the projections for the Zoological example
New views can be defined by projections (model
transformations) from the unified metamodel

Further issues
What happens with the concrete syntax?
In our proposal users do not need to deal with the unified
language…
Otherwise,
Do you super-impose icons? :-O
Do you invent yet another notation? :-(
…
What happens with the semantics?
This is tough in most approaches…
In an unification context, the semantics of the individual
viewpoints and of the unified metamodel are preserved
Projections act as semantic bridges that relate the
semantics

A typical application scenario
A user is confronted with two DSMLs to combine
The user defines the correspondences
Model weaving techniques can be useful here
Can model extension or model merge algorithms work?
If so, apply the algorithms described in [5] or [6]
The projections are just the inverse of their mappings functions
Otherwise, define a new combined language
By language embedding (if none of the issues mentioned above
represent a problem for you)
Projections are the inverse of the mappings
By defining a new metamodel
Projections are defined by the user (as model transformations!)

Conclusions
We have discussed the different mechanisms available
for DSML combination, their advantages and limitations
We propose a general framework for combining DSMLs
that subsumes them, based on the concept of
unification and its realization using model-driven
techniques
We are applying our work in the context of Multi-
Viewpoint approaches such as MDWE or RM-ODP

Thanks!
Acknowledgements:
44ECMFA, paris, June 2010A. Vallecillo: "On the Combinination of DSMLs"

On the Combination of Domain Specific Modeling Languages

More Related Content

Similar to On the Combination of Domain Specific Modeling Languages (20)

More from Antonio Vallecillo (12)

On the Combination of Domain Specific Modeling Languages