Download - Validated Model Transformation
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?