This is the (live) summary of the MELO 2011 workshop that tries to bring together two different communities: the Model-Driven Engineering (MDE) community and the logic programming community, to explore how each community can benefit from the techniques of the other. In our case, we have used logic programming to check UML models (see our UMLtoCSP tool) and to solve configuration problems .
A summary of the papers(full papers available here ) presented in the workshop is the following (summary created live during the workshop, apologies for typos, misunderstandings,..):
- ODM-based UML Model Transformations using Prolog , by Jesus M. Almendros-Jimenez and Luis Iribarne. The paper presents a framework for the specification of model transformations by means of Prolog rules using an ODM representation of UML models (to simplify using Prolog to write the transformation rules). In addition, Prolog rules are also used for the validation of source and target models. To me, the main contribution is the paper is to bring prolog users to MDE. The idea is not so much to convince MDE experts to write transformations in Prolog but introduce to MDE people which is already used to work with logic-based methods. Nevertheless as further work they plan to provide a more high-level syntax (similar to ATL) for the approach.
It would be nice to see also how the efficiency of a prolog-based approaches compares with the more traditional transformation languages - Model-Driven Engineering for Constraint Database Query Evaluation , by María Teresa Gómez-López, Antonia Reina-Quintero and Rafael M. Gasca. Constraint Databases were defined to represent in a compact way data that could be very large or even infinite. Problem is that there are no standards for constraint databases everything is completely technology-dependent. The idea is to follow and MDA approach for the development of this kind of databases. They have developed several metamodels (constraint database query metamodel, constraint database metamodel, ) and the transformation to go from there to different solvers, query languages, .
- Model Transformation by Refinement in Constructive Logic , by Simon Foster, Georg Struth, Ondrej Rypacek and Anthony Simons. The paper presents the ?rst steps of a formalisation of meta modelling in a constructively typed programming language ( Agda ), explaining its potential
for specifying model transformations. They are also able to express modal constraints on the models. Goal: to provide an environment for formally developing software transformations, which are correct by construction and machine-checked proof. Good question is how really the concept of refinement applies to model transformations. Maybe this could help to go from high-level transformation specifications to more low-level (executable) ones. - Logical constraints for managing non-determinism in bidirectional model transformations , by Antonio Cicchetti, Davide Di Ruscio, Romina Eramo and Alfonso Pierantonio. Bidirectionality is a very nice property for model transformations but of course only possible in some situations. When the transformation is non-bijective, back propagation of changes on the target model is not deterministic. Janus Transformation Language (JTL) is a bidirectional model transformation language whose semantics are defined in terms of Answer Set Programming. Additional constrains defined as part of the transformation help to narrow down the number of generated models. Transformation themselves are specified as relations. I’d LIKE TO be able TO predefine SOME heuristics that play the role OF (implicit) additional CONSTRAINTS FOR the process TO free the designer FROM SOME OF the WORK.
- VIDEAS: Supporting Answer-SET Program Development USING Model-Driven Engineering Techniques , by Johannes Oetsch, Jörg Pührer, Martina Seidl, Hans Tompits AND Patrick Zwickl. Research ON ASP has focused ON fundamentals but less attention given TO methodology AND tool assistants. This IS the goal OF the VIDEAS framework based ON MDE. Videas allows the modeling OF ASP problems WITH EntityRelationship diagrams. CONSTRAINTS ARE generated FROM such models )what about CONSTRAINTS that cannot be expressed graphically IN the ER model?). FActs can also be generated FROM the INPUT DATA form IN the FactBuilder. NO notion OF PIM/PSM, there’s no problem when working with different ASP solvers? (as typical with CSPs).
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
A couple of clarification comments from Patrick Zwickl
“what about constraints that cannot be expressed graphically in the ER model?”
The generated constraints are implicitly derived from the ER diagram. Additional constraints may be added by using ASP code in the usual manner. So, constraints which are not implicitly modeled, can be added conventionally, but are not graphically specified.
there’s NO problem WHEN working WITH different ASP solvers?
The code has TO be adopted TO the solver’s capabilities, e.g. disjunctions are removed and instead N rules replace the initial one—for (N-1) disjunctively connected head literals; the most extreme case. The generation itself, however, is very similar which allows the support for several solvers. The rule notation itself (without the “advanced features” of solvers) are however similar. So, the discussion is on which ASP features are supported rather than on solvers notation typically.