Validated Model Transformation Tihamér Levendovszky Budapest University of Technology and Economics Department of Automation and Applied Informatics Applied Computer Science Group CAMPaM 2006

Outline  Visual Modeling and Transformation System  Models Metamodeling in VMTS Visualization  Transformation Graph transformation The VMTS approach  Validated High-level constraint constructs Global constructs Efficient validation

Visual Modeling and Transformation System

Metamodeling  To be used by tools Database analogy  Ideal architecture for tools Set of hard-wired constructs (“visual vocabulary”) One instantiation (“language generation rules”) Layer transparency – for the general access

Metamodeling - 2  The VMTS approach  Set of hard-wired constructs Node (Atom) Edges (Relationship) Attributes Inheritance Containment  Layer transparency

Metamodeling - 3  One instantiation MOF 0/ MOF 1 (UML object and class diagram)  “Natural traversal” Metamodel as a class diagram Model elements are objects in a programming language A simple alternative to GT-based MT

Open Issues - Metamodeling  Metamodeling for tools Minimal set of hard-wired constructs? Consistent attribute instantiation?  Functions vs. attributes in Class diagram  Potency (Next level)?  Other constructs?  Enough experience? - Time to make a comparison and conclusions On the constructs, not on the names For tools, not for language definition

Visualization – a DSL Approach Code generation with model transformation

Open Issues - Visualization  DSL vs. other approaches?  Set of mandatory graphical constructs?  Refresh – simulation solutions?

Graph Rewriting

Metamodel-Based Rewriting  An instantiation of LHS must be found in the graph the rule being applied to instead of the isomorphic subgraph of the LHS

Model transformation in VMTS  DPO-Based  Free parameters  Natural constructs E.g. multiplicities Inheritance

Validated Model Transformation  High-level constructs in OCL property P before the step S property P after the step S Validationtrue falsestep S fails Preservationtrue false Guaranteetrue falsetrue

DB2Class Transformation  Classes that are marked as non- abstract in the source model should be transformed into a single table of the same name in the target model.  The resultant table should contain one added primary key column, one or more columns for each attribute in the class, and one or more columns for associations based on the next rule.

DB2Class Transformation  Associations Many-to-many (N:N) associations, should be mapped to distinct tables. The primary keys for both related classes should become attributes of the association table (foreign keys). Foreign keys do not allow NULL values, because a link between two objects requires that both of them be known. One-to-many (1:N) associations, using one or more foreign key columns should be merged into the table for the class on the “many” side. For one-to-one (1:1) associations, also the foreign key should be buried optionally in one of the affected tables.

DB2Class Transformation -2  Parent class attributes should be mapped into tables created from inherited classes.  An association class should be transformed based on the multiplicity of the association. For N:N association, the attributes of the association class become columns of the distinct table. For a 1:N or 1:1 the attributes of the association class become columns of the table in which the foreign key is buried.  These requirements guarantee the third normal form

DB2Class Transformation -2  Requirements Each table has primary key, Each class attribute is part of a table, Each parent class attribute is part of a table created for its inherited class, Each many-to-many association has a distinct table, Each one-to-many and one-to-one association has merged into the appropriate tables, Foreign keys not allow NULL value, and Each association class attribute buried into the appropriate table based on the multiplicities of its association.

Online Validation  Offline validation - hard Paper and pencil Based on concurrency theorem  There is a need for a solution that can validate model transformation specifications: online validated model transformation that guarantees if the transformation finishes successfully, the generated output (database schema) is valid, and it is in accordance with the requirements above.

VMTS Class diagram and Relational Database metamodels

Example input of the case study, and required output of the example input model

Control Flow Model of The Transformation Class2RDBMS

Step CreateTable

Step ProcessAssociation

Step AddParentAssociation, Step ShiftParentClassHelper, and External Causalities

Transformation Step ProcessAssociation – Removing Crosscutting Constraints context Class inv Const1: not Abstract context Class inv Const1: not Abstract context Atom inv Const2: self.class.attribute->forAll(self.table.column-> exists(c | (c.columnName = class.attribute.name)) context Atom inv Const2: self.class.attribute->forAll(self.table.column-> exists(c | (c.columnName = class.attribute.name))

Global Constraint Weaver

Constraint Aspect and the Constraint Aspect Weaver Algorithm

Separating Constraints in Validated Model Transformation  A refining constraint complete the conditions required by the structure of LHS of a transformation step.  A validation constraint expresses a semantically motivated constraint without which the transformation would work correctly, except for abortion.

Summary - Validation  If the transformation successful, then validated  Intuitive: because the problem needs intuition and human interaction  Whole transformation can be validated: weaving  Limitation: 3rd Normal Form – need a book

Open Issues - Validation  More case studies? How efficient is the formalism?  Other constraint constructs for transformation?  Heuristics for OCL Compilers?