Last week I attended the PhD Thesis defense of José E. Rivera (thesis supervised by Antonio Vallecillo and Francisco Durán ) proposing a method for the formal definition of Domain specific modeling languages (DSMLs).
IMHO, the thesis covers an important gap in Model-driven engineering. Right now, many people tend to believe that by defining the concrete and abstract syntax (i.e. metamodel) of a DSML, the work is done, forgetting that the semantics of the DSMLs must be defined as well to make sure everybody interprets models conforming to that DSML in the same way. This thesis proposes a method for doing this.
I’m enclosing the abstract of the thesis below. If you are interested, the full thesis is available here .
On the Semantics of real-time domain specific modeling Languages
Domain specific modeling languages (DSMLs) have been proposed as a commonplace for specifying systems at a high-level of abstraction, usign a notation very close to the problem domain and quite intuitive for domain experts. However, DSMLs are usually defined only in terms of their abstract and concrete syntaxes, with no precise semantics. This lack is something that may limit unambiguous communication among model developers, hamper the development of formal analysis and simulation tools, and present a possibility for semantic mismatch between design models and modeling languages of analysis tools, among others.
In this thesis we propose an approach for the formal definition of DSMLs by means of two views: structure and behavior. We identify the elements involved in the definition of these views: abstract syntax, concrete syntax and semantics; and we propose a way to enable the DSML designer to automatically define the semantics of the DSML.
To define the structural view of a DSML we use metamodels expressed in Ecore, a language developed for the Eclipse platform that allows the specification of metamodels. To define the behavioral view of a DSML, we have developed our own DSML and tool (for the Eclipse platform too), called e-Motions, that supports the specification of time-dependent behavior of real-time DSMLs. The e-Motions tool extends in-place model transformations with a model of time and with mechanisms to state action properties. These extensions have been defined to cope with real-time and complex systems, and they promote the separation of concerns between the structural and behavioral specifications: they avoid modifying the DSML’s metamodel to include time and action properties related to the behavior of the language. The tool enables the use of the graphical concrete syntax of the language , allowing modelers to perceive themselves as working directly with domain concepts.
Once this is done, we are able use rewriting logic in Maude to perform simulation and reachability and model checking analysis of the specification. In particular, we have developed a metamodel for Maude and semantic bridges bewteen Ecore and Maude by means of model transformations.
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
I agree that it is a good thing if you can encode the semantics of your metamodel as part of its description so they can be automatically checked and implemented (BTW, isn’t that what Kermeta IS FOR?).
I would say however that even if your metamodel description LANGUAGE does NOT support it, one can still specify semantics via documentation (see JLS), supported by manual implementation IN tools (compiler, linker, VM, etc). Programming languages have always been specified this way. Granted, that IS NOT the model-driven way, but it does NOT mean it IS forgotten/missing.
As a side note, the UML metamodel does define many restrictions AND behaviors IN terms OF OCL, but still has TO express ALL those rules IN terms OF plain English, so that suggests that encoding semantics IN your metamodel LANGUAGE does NOT free you FROM manually stating those semantic rules IN a human-readable way AS well.
Cheers,
Rafael
http://abstratt.com/blog
Dr. Richard Soley, Chairman AND CEO FOR OMG, IS speaking AT Business Technology Summit about a standard TO LOWER costs AND increase quality broadly IN the software world, driven by static code analysis, software modeling AND shared patterns AND anti-patterns OF good practice. Dr. Soley’s keynote will give an overview of the process and schedule for developing the standard, and the expected uses of of the standard when complete
I agree that defining the semantics OF your DSML IN a formal way does NOT free you FROM specifying it IN NATURAL LANGUAGE too. But, usually, we do NOT need ONLY TO understand the meaning OF the models, but we also need TO perform simulation AND analyis over them. Defining a precise AND formal semantics by USING a semantic DOMAIN, such AS rewriting logic, helps IN this task, AND allows you TO make use OF the tools available IN the semantic DOMAIN (TO perform, e.g., reachability analysis AND model checking). This kind OF analysis cannot usually be done (OR would be very difficult TO implement) IN tools WHERE the semantics OF your LANGUAGE IS dictated by the compiler. This kind OF tools normally provides ONLY simulation facilities (LIKE Kermeta does).
Jose E. Rivera
Jose, it is a very nice work! I watched the presentation and have a question: there is a large section that describes extensions to in-place transformations to model behavioral semantics. Then another section follows that shows the same extensions in Maude. Is the former a concept and the latter is (manual?) realization thereof in Maude?
I used to know and work with AToM3 people at McGill, and glad to see you mentioning AToM3 in credits! What was their role in the project?
Cheers,
Andriy Levytskyy
Thank you very much Andriy. The extension of in-place transformation includes the model of timed behavior that we propose to specify the behavior of DSMLs (in a graphical and intuitive way), and then we give formal semantics to this language by automatically transforming the specifications into Maude.
Regarding ATOM3, we included a Maude parser and serializer in the tool to provide it with reachability analysis and model checking facilities. But this work do not include our model of timed behavior (the specification of the system is done with “standard” graph transformations) since it was done before we extended in-place model transformations.
King Regards,
Jose E. Rivera