oihane
Uploaded by
11 SLIDES
255 VUES
110LIKES

Logic Programming Based Model Transformations

DESCRIPTION

This work provides a comprehensive overview of logic programming techniques applied to model transformations, addressing the inconsistencies in models and their transformations. It explores state-of-the-art methods, existing challenges, and how we can contribute to resolving gaps. The discussion includes simplification strategies between ISO and CCOM, encoding constraints in ASP, and future implementation of Ecore/OCL constraints in ASP. It emphasizes the use of Prolog and Alloy for model transformation analysis, showcasing practical approaches like JTL and PTL to enhance consistency and efficiency in model transformations.

1 / 11

Télécharger la présentation

Logic Programming Based Model Transformations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Logic Programming BasedModel Transformations An overview of related work

  2. GOAL – WHY? • Exploring the reasoning techniques for querying the inconsistencies in Models and model transformations • State of the art, challenges, gaps and how we can contribute • Simplify transformations between ISO and CCOM

  3. CARE approach(ASP) • Each metamodel elements > class, attribute and reference ASP facts. • Model elements > object, value and link ASP facts. • Conformance constrains have been manually defined [in pseudocode in table] and encoded in ASP. • Meta-model specific Ecore/OCL constrains > ASP constrains in future version of prototype. • Language semantics(object-oriented) need to be encoded as well. • Ecore <> ASP transformations are implemented by Xtend (a flexible and expressive dialect of Java) • A constraint solver produces an output, which is a set of facts describing which objects, values, and links are conform or not, and adds these new facts to the CARE knowledge base.

  4. JTL approach(ASP) • Modeled as Graphs composed of nodes, edges and properties – logic assertions • (1)Each (meta)model elements > metanode, metaedge, and metaprop predicate symbols • (1)Each model element > node, edge, property • (2)JTL(QVT-R like syntax) > ASP relation and constrains by means of ATL transformation • (4)Transformation (JTL) engine is based on ASP bidirectional transformation program executed by DLV solver(find stable models) Transformation process steps:1. the execution engine induces all the possible solution candidates according to the specified relations; 2. the set of candidates is refined by means of constraints (ASP rules). (3)Target model is deducted based on ASP rules from candidate solutions.

  5. Analysis of MT(Alloy) • based on meta-modelling • MOF meta-models/OCL > Alloy by means of UML2Alloy transformation tool • Transformation rules > Alloy mapping relation • STEPS Step 1:Translate the Model Transformation Specification to Alloy. Step 2: Analysis using the Alloy Analyzer. • Alloy model of MT which can be analysed by Analyzer(Simulation)

  6. QVT-R Bidirectional (Alloy) • UML(annotated with OCL) + QVT-R > Alloy • principle of least change restores consistency by simply returning target models that are at a minimal distance from the original -> the“check-before-enforce” policy (QVT-R) is satisfied. • Classes and associations (including attributes) > signatures and relations in Alloy. Inheritance relationship in Alloy. • For each relation R > Alloy predicates to specify Rforwardand Rbackward • Predicates are used to specify the when and where clauses, and the domain patterns of each relation • checkonly mode - check the consistency predicate for a pair of models

  7. PTL approach(Prolog) • Each (meta) model elements > set of classes, attributes, roles and helpers. • Each model elements > set of classes, attributes, roles, helpers and objects. • PTL > Prologencoding - based on a Prolog library for handling meta-models • PTL (ATL like syntax) = ATL style rules + logic Rules in Prolog(helpers). Prolog style rules serve as a query language. Prolog is used as a transformation engine for PTL. • A Prolog program is automatically obtained from a PTL program. The encoding of PTL programs with Prolog is based on a Prolog library for handling meta-models

  8. Inductive logic(Prolog) • Modeled as Graphs composed of nodes, edges and properties – logic assertions • Source and target models are mapped into Prolog clauses • Mapping models are represented by tuples ref (ri , src1, . . . , srcn, trg1, . . . , trgm).

  9. Conclusions • Logic clause, fact, assertion = represents models and meta-models • Logic rule = used to encode model transformation and constraints on models • taking advantage of model finding(SAT-solver) abilities • Being solver-based, the main drawback is performance - incremental solving techniques- mechanisms to infer which parts of target model can be fixed in design time • Model & transformation > logic programming is manual, except in JTL approach

More Related