Validated Model Transformation

Tihamér Levendovszky

Budapest University of Technology and EconomicsDepartment 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

Helper

PersClass1PersClass2

Child1

Child2

Child3

Host Model

NonPersClass1NonPersClass2

Helper

PersClass1PersClass2

Child1

Child2

Child3

Host Model

NonPersClass1NonPersClass2

Helper

PersClass1PersClass2

Child1

Child2

Child3

Host Model

NonPersClass1NonPersClass2

PersClass1PersClass2

Child1

Child2

Child3

Host Model

NonPersClass1NonPersClass2

Helper

PersClass1PersClass2

Child1

Child2

Child3

Host Model

NonPersClass1NonPersClass2

Step1: Finding an occurrence of LHSStep2: Remove the unnecessary elementsStep3: Glue the remaining part of RHS

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

L K R

G D Hm

l r

l* r*

m*d

LM KM RM

GM DM HM

lm km rm

gm dm hm

Validated Model Transformation High-level constructs in OCL

property P before the step S

property P after the step S

Validation true true

false step S fails

Preservation true true

false false

Guarantee true true

false true

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

<<Class>>Class

<<Atom>>HelperNode

<<Table>>Table

1

dstTHelpE

<<Class>>Class 1

1srcTHelpE

1

Cons_C1

Cons_T1

context Class inv NonAbstract:not self.abstract

context Table inv PrimaryKey:self.columns->exists(c | c.datatype = 'int' and c.is_primary_key)

context Atom inv ClassAttrsAndTableCols:self.class.attribute->forAll(self.table.column->exists(c | (c.columnName = class.attribute.name))

context Table inv PrimaryAndForeignKey:not self.columns->exists(c | (c.is_primary_key orc.is_foreign_key) and c.allows_null)

Cons_C1

Cons_A1

Cons_T2Cons_C2

context Class inv Processed:not self.isProcessed

Step ProcessAssociation

<<Atom>>HelperNode1

<<Table>>Table1

1

dstTHelpE

<<Class>>Class1 1

1srcTHelpE

1

<<Atom>>HelperNode2

<<Table>>Table2

1

dstTHelpE

<<Class>>Class2 1

1srcTHelpE

1

association

1

1

<<Atom>>HelperNode1

<<Table>>Table1

1

dstTHelpE

<<Class>>Class1 1

1srcTHelpE

1

<<Atom>>HelperNode2

<<Table>>Table2

1

dstTHelpE

<<Class>>Class2 1

1srcTHelpE

1

association

1

1

<<Table>>AssocTable

1

1

0..1

0..1

relation

relationCons_A2

context Association inv OneToOneOrOneToMany:(self.leftMaxMultiplicity = '1' or self.rightMaxMultiplicity = '1') impliesself.attribute->forAll (self.class1.helperNode.table.column->exists(c | (c.columnName = attribute.name)) or self.attribute->forAll(self.class2.helperNode.table.column->exists(c | (c.columnName = attribute.name))

Cons_A1

context Association inv Processed:not self.isProcessed

context Association inv ManyToMany:(self.leftMaxMultiplicity = '*' and self.rightMaxMultiplicity = '*') impliesself.attribute->forAll(self.class1.helperNode.table. connectTable.column->exists(c | (c.columnName = attribute.name))

Cons_A3

Left-Hand Side Right-Hand Side

Step AddParentAssociation, Step ShiftParentClassHelper, and External Causalities

Transformation Step ProcessAssociation – Removing Crosscutting Constraints

Left-Hand Side Right-Hand Side

<<Atom>>HelperNode1

<<Table>>Table1

1

dstTHelpE

<<Class>>Class1 1

1srcTHelpE

1

<<Atom>>HelperNode2

<<Table>>Table2

1

dstTHelpE

<<Class>>Class2 1

1srcTHelpE

1

association

1

1

<<Atom>>HelperNode1

<<Table>>Table1

1

dstTHelpE

<<Class>>Class1 1

1srcTHelpE

1

<<Atom>>HelperNode2

<<Table>>Table2

1

dstTHelpE

<<Class>>Class2 1

1srcTHelpE

1

association

1

1

<<Table>>AssocTable

1

1

0..1

0..1

relation

relation

Const2

context Class inv Const1:

not Abstract

context Class inv Const1:

not Abstract

Const1

Const2Const1Const1

Const1

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))

Const2

Const2

Global Constraint Weaver

GlobalConstraint

Weaver

Const2

Transformation Step

ConstrainedTransformation Step

AO Constraints

Left-Hand Side Right-Hand Side

<<Atom>>HelperNode1

<<Table>>Table1

1

dstTHelpE

<<Class>>Class1 1

1srcTHelpE

1

<<Atom>>HelperNode2

<<Table>>Table2

1

dstTHelpE

<<Class>>Class2 1

1srcTHelpE

1

association

1

1

<<Atom>>HelperNode1

<<Table>>Table1

1

dstTHelpE

<<Class>>Class1 1

1srcTHelpE

1

<<Atom>>HelperNode2

<<Table>>Table2

1

dstTHelpE

<<Class>>Class2 1

1srcTHelpE

1

association

1

1

<<Table>>AssocTable

1

1

0..1

0..1

relation

relation

Const1

Left-Hand Side Right-Hand Side

<<Atom>>HelperNode1

<<Table>>Table1

1

dstTHelpE

<<Class>>Class1 1

1srcTHelpE

1

<<Atom>>HelperNode2

<<Table>>Table2

1

dstTHelpE

<<Class>>Class2 1

1srcTHelpE

1

association

1

1

<<Atom>>HelperNode1

<<Table>>Table1

1

dstTHelpE

<<Class>>Class1 1

1srcTHelpE

1

<<Atom>>HelperNode2

<<Table>>Table2

1

dstTHelpE

<<Class>>Class2 1

1srcTHelpE

1

association

1

1

<<Table>>AssocTable

1

1

0..1

0..1

relation

relation

Const2

Const1Const1Const1

Const2Const2Const2

Const1

Constraint Aspect and the Constraint Aspect Weaver Algorithm

(a) Constraint Aspect

(b) PropagatedConstraint Aspect

<<Class>>Class

<<Attribute>>Attribute

<<DataType>>DataType

1

1..*

1

1

attrs

type

<<Atom>>HelperNode

<<Table>>Table

<<Column>>Column

1

1..*

1

1

dstTHelpE

cols

<<Class>>Class 1

1srcTHelpE

pkey

1

1

Left-Hand Side Right-Hand Side

<<Atom>>HelperNode

<<Table>>Table

1

1

dstTHelpE

<<Class>>Class 1

1srcTHelpE

1

1

Cons_C1

Cons_T1

Cons_C1

Cons_T1

PROPAGATION

Transformation Step

Constrained Transformation Step

Constraint Aspect Weaver

Constraint Aspect

<<Atom>>HelperNode

<<Table>>Table

1

1

dstTHelpE

<<Class>>Class 1

1srcTHelpE

1

1

Cons_C1

Cons_T1

<<Class>>Class

<<Attribute>>Attribute

<<DataType>>DataType

1

1..*

1

1

attrs

type

<<Atom>>HelperNode

<<Table>>Table

<<Column>>Column

1

1..*

1

1

dstTHelpE

cols

<<Class>>Class 1

1srcTHelpE

pkey

1

1

Cons_C1

Cons_T1

<<Class>>Class

<<Attribute>>Attribute

<<DataType>>DataType

1

1..*

1

1

attrs

type

<<Atom>>HelperNode

<<Table>>Table

<<Column>>Column

1

1..*

1

1

dstTHelpE

cols

<<Class>>Class 1

1srcTHelpE

pkey

1

1

Cons_W

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.

LHS RHS

<<Person>>PersonA

<<Company>>CompanyA

<<Person>>PersonB

<<Company>>CompanyB

<<Person>>PersonA

<<Person>>PersonB

<<Company>>CompanyB

Refinement Constraints

Weaving Constraints

Validation Constraints

context Company inv Cons_C1:self.numberOfEmployees > 50

context Person inv Cons_P1: self.age < 200

context Person inv WCons_P2: self.name = ‘PersonA’

context Company inv Cons_C1:self.numberOfEmployees > 50

context Person inv Cons_P1: self.age > 30

Transformation Step

Constraints

Constraint Weaver

<<Person>>PersonA

<<Company>>CompanyA

<<Person>>PersonB

<<Company>>CompanyB

Cons_P1

<<Person>>PersonA

<<Person>>PersonB

<<Company>>CompanyB

Cons_C1

Constrained Transformation Step

Cons_P1

Cons_C2

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?