MOF QVT

1
MOF QVT

• 1st Submission by
• CBOP, DSTC IBM
• Keith Duddydud_at_dstc.edu.au

2
OverviewNever send a human to do a machines
job -- Agent Smith, The Matrix

• Relationships between Query, View
  Transformation
• Requirements in addition to RFP
• Styles of Transformation
• Main Model Concepts
• Patterns
• Transformation Rules
• Trackings
• Transformations
• Rule Reuse
• Example
• Meeting the RFP Requirements
• Summary

3
Relationships between Query, View and
Transformation

• Queries and Views and Transformations
• Are defined with respect to a source model
• Queries and Views
• Do not create new objects, but refer to source
  model elements
• Views and Transformations
• Result in a target model defined in terms of
  the source model
• Queries
• Queries return only a set of tuples
• Views
• Result in target models with values that are
  updated when the source models values are
  changed
• Transformations
• Create new instances which are not updated when
  the source changes

4
Requirements in Addition to RFPFunctional

• The transformation language must be able to
• match elements, ad-hoc tuples of elements, by
  polymorphic type or specific type
• Filter matched elements based on attribute
  values, associations and other navigable context
• Match collections as well as single elements with
  implicit quantification
• Establish trackings of which target elements were
  created as a result of matching which source
  elements
• Establish ordering over ordered AND unordered
  model collections
• Handle recursive structure in models to arbitrary
  depth
• Match and create model elements at different
  meta-levels
• Support multiple source and multiple target models

5
Requirements in Addition to RFPUsability

• There should be no explicit ordering of rule
  application, and all rules should apply to all
  source model elements
• Creation of target objects must be implicit to
  facilitate arbitrary rule ordering and/or
  matching
• Multiple target elements may be created by a
  single rule
• A single target element may be defined by several
  rules
• Patterns may be defined separate from rules and
  reused
• Rules may be grouped for readability and
  modularity
• Transformations should be composable
• Transformations may be source-driven,
  target-driven, or aspect-driven

6
Styles of Transformation

• Source Driven
• Rules are structured for the classes in the
  source model
• Typically one rule per source metamodel class,
  attribute and association
• In refinement mappings, the target part of the
  rule with create a whole structure of instances
• Target Driven
• Rules are structured for the classes in the
  target model
• Typically one rule will create all parts of a
  target object
• In refinement mappings, the source part of the
  rule will match many complex patterns
• Aspect Driven
• Rules are structured by concepts, not classes
• Rules may address small parts of several objects
  in source and target

7
Simplified Model

1
/term
name string
1
1
name string
uses

parent
child
body
0..1

Expression
extends
name string
supersedes
0..1
source 1
1
VariableExpr
target
8
Model OverviewPatterns

• Pattern Definitions are named expressions
• They have a number of formal parameters
• They may be recursive
• Pattern Uses are either
• In source expressions in which their parameters
  return matching values to variables
• In target expressions in which they act as
  templates and their params provide values

9
Model OverviewTransformation Rules

• Rules
• Have names (mainly to facilitate concrete syntax)
• Consist of a source and a target expression
• Own a number of variables
• They are evaluated by
• Applying the source expression to a set of model
  instances
• as a predicate to match
• to bind values to variables
• If the source expression matches model element(s)
  then the target part of the rule is applied

10
Model OverviewTrackings

• Trackings
• are associations between source model elements
  and the target elements created because of a rule
  match
• are used in the source expression of a rule to
  query whether a model element was created
  elewhere
• are used in the target expression of a rule to
  assert a relationship between source model
  elements and created target model elements
• can be considered as named tuples
• can be related to other trackings in
  inheritance hierrachy

11
Model OverviewTransformations

• A Transformation is a container for
• Pattern Definitions
• Variables
• Rules
• Tracking Definitions

12
Model OverviewRule Reuse

• Rules may be reused in two ways
• Rule Extension Allows
• Additional clauses to be added to source match
• Addional model elements to be created in target
• Rule Superseding Allows
• (Optional) additional clauses to be added to
  match
• Which override the superseded rule to apply a
  different target expression to the original rule

13
Concrete Syntax Issues

• Concrete Syntax should be familiar to different
  kinds of Query/View/ Transformation users
• We envisage several syntaxes mapped from the
  single metamodel
• OCL based (requires extensions)
• SQL/OQL based (see examples)
• XPATH based
• Generated HUTN
• Generated XMI

14
Example Pattern

• Define a pattern for getting all the attributes
  of a class, including those from supertypes
• PATTERN hasAttr(C, A)
• FORALL Class C, Attribute A, Class C2
• WHERE A.owner C
• OR (C.super C2 AND hasAttr(C2, A))

15
ExampleObject to Relational Mapping

• Map each Class to a Table, and each Attribute to
  an owned Column, with trackings
• RULE attr2col
• FORALL Attribute Att,
• Class Cls
• WHERE hasAttr(Cls, Att)
• AND isMostDerived(Cls)
• MAKE Table Tbl, Column Col
• LINKING Cls to Tbl by c2t,
• LINKING Att to Col by a2c

RULE clsAttr2tblCol FORALL Attribute Att,
Class Cls WHERE c2t LINKS Cls to Tbl AND a2c
LINKS Att to Col MAKE Table Tbl, Column Col,
Col.owner Tbl
16
Example - cont

• Map Class and Attribute names to Table and Column
  names using tracking generalisation
• TRACKING c2t ISA named2named
• TRACKING a2c ISA named2named
• RULE named2named
• FORALL NamedElt n1
• WHERE named2named LINKS n1 to n2
• MAKE Named n2, n2.namen1.name

17
Example - cont

• Map multi-valued attributes differently from the
  default attribute mapping by superseding the
  previous rule
• RULE clsMultiAttr2tblCol supersedes
  clsAttr2tblCol
• FORALL Attribute Att, Class Cls,
• WHERE Att.multivalued TRUE
• MAKE Table AttTbl, Column KeyCol,
• Column AttCol,
• KeyCol.ownerTbl, AttCol.ownerTbl,
• KeyCol.name Cls.name
• LINKING Att to AttTbl by mva2t

18
Meeting the RFP RequirementsMandatory

• 1. Language for Querying Models
• The expresion language subset of the model meets
  the needs for ad-hoc queries
• 2 3. Language fortransformation definitions.
  Abstract syntax to be defined in MOF 2.0
• The model for transformation definitions is
  given in Chapter 4 in psuedo-MOF2.0
• 4. Transformation definition can be automated
• DSTCs prototype, MOFLog automates the execution
  of transformation model instances

19
Meeting the RFP RequirementsMandatory

• 5. Transformation definition can create views
• A View is defined in the same way as a
  transformation evaluation semantics is
  different
• 6. Transformation definitions shall be
  declarative.
• Our model for transformation definitions is
  declarative and makes no calls to hidden code,
  contains no imperative programming constructs
• 7. Mechanisms shall operate using MOF 2.0.
• As far as possible this submission anticipates
  the form of MOF 2.0 (but we may need to wait
  until MOF Facility is defined)

20
Meeting the RFP RequirementsOptional

• 1. Transformations can execute in two directions
• A subset of models in our language may do so
  but must not use some features of the pattern
  language.
• 2. Traceability of transformation executions
• Traceability relationships between source and
  target model are used primarily for rule
  cross-referencing. Tools could store all of this
  persistently. But we recommend an additional
  target model.
• 3. Reuse and extension of generic transformations
• We supports the definition of patterns (named
  queries), the extension of patterns, and the
  extension and overriding of rules

21
Meeting the RFP RequirementsOptional

• 4. Transactional transformation definitions
• Transformation rules are not required to produce
  complete instances. Declarative nature makes Txn
  unnecessary. Transformations considered atomic.
• 5. Additional data as input, and defaults
• Transformations are parameterised with
  additional data (source models), no support for
  default values
• 6. Same source and target (in place update)
• This is not permitted in this proposal.

22
Summary

• Fully Declarative language
• Rich, named, reusable patterns
• Variable bindings in source pattern of rule gives
  values to populate target pattern
• Aspect-driven transformation style
• Rules may address any granularity or structure of
  elements in source and target
• Implicit creation, simple qauntification
  collection management
• Trackings cross-reference between rules
• Rule extension and overriding
• Multiple concrete syntaxes supported