A DSVL for Domain Translation using Graph Transformations

1
A DSVL for Domain Translation using Graph
Transformations

• Jonathan Sprinkle, Aditya Agrawal, Tihamer
  Levendovszky, Feng Shi, and Gabor Karsai

2nd Workshop on DSVLs OOPSLA 2002 Seattle, WA
4 November 2002
2
Introduction
3
Ways to perform transforms

• DSVL domain models
• May be represented as multi-graphs
• Always have a spanning tree
• Utilize graph transformation techniques
• Allow for typed graph descriptions
• Create a language capable of describing graph
  transforms
• Interesting DSVL concepts
• Graph transform language uses components from the
  metamodeling language
• Components are associated to describe patterns
  which are searched on, and then replaced with
  other patterns (analogous to a text document)
• Notions of sequencing and decisions reside on a
  different hierarchical layer from the graph
  patterns
• Additional concern Semantics!!

4
Transformation language details

• Language requirements
• Meta-Information
• Transformation steps must have knowledge of the
  two DSVLs
• Rule definitions
• Pattern components refer to classes in the DSVL
  metamodels
• These component types are based on the
  meta-metamodel
• Mapping definitions
• What can be done once a pattern is matched
• E.g., delete, replace, rename
• Rule Execution
• Sequencing
• Decision support (if, then, else)

5
Meta-information knowledge
UML Class diagrams define the syntax of a DSVL
6
Rule definitions
7
Mapping definitions
Types of mapping - Create new - Replace -
Same - Create Reference - Create Link -
Delete - Refer, else, Create - Create inside -
Refer to
8
Rule execution
9
Fine details

• Attribute mapping
• Remember, attributes have semantic meaning
• Imperative language can provide additional
  mapping abilities
• CInt C/C
• Parameter passing
• Objects matched or created in one rule may be
  passed to the next rule as parameters
• Rule execution model of computation
• Analogous to Petri-net, execution based on input
  parameter presence
• Fine-grain control over depth/breadth-first
  traversal
• Result of Transform Language compilation
• a compact (XML) representation of the rules and
  sequences
• used as the program in a graph-rewriting engine
  (GRE)

10
Example

• A body of models exists that define signal
  processing algorithms described in a visual
  language
• Language uses signal processing units
• Processing units may be composed hierarchically
• Customer has a similar visual language
• Does not use hierarchical processing units
• Wants to transform hierarchical models to work in
  this flat visual language
• Preservation of semantics is essential
• Requirement the transformed signal processing
  model describes the same algorithm

11
Example
12
Example
13
Example

• Process to convert from HSF to FSF
• Change all Compounds without parents to
  RootContainers
• Change each Port inside a Compound into a Queue
• Extract all Compounds from within Compounds to be
  Actors
• Change all Primitives to Actors inside the
  appropriate RootContainer
• Change all Input Ports inside Primitives to
  Receivers
• Change all Output Ports inside Primitives to
  Transmitters
• Extract all Signals between Ports as appropriate
  InputSingals/OutputSignals between Transmitters,
  Receivers, and Queues

14
Example
15
Example
16
Future research

• Model migration and model transformation
• Migration
• small iterations in DSVL evolution
• more suited for small changes to input domain
  model graph
• Transformation
• semantically similar DSVLs with major syntactic
  differences (e.g., this example)
• more suited for complete model rewriting
• Migration would benefit from generating the graph
  transformations automagically
• Providing a smaller set of rules, based on
  modifying the original graph
• Generating the full graph transformation (i.e.,
  actually creating a new graph) by automating the
  creation rules

17
Conclusions

• This language is promising for high-level graph
  rewriting specifications, especially due to its
  linkage to the DSVL definition (i.e., the
  metamodel)
• The language is independent of a particular
  graph-rewriting engine, and could be used as a
  front-end to different rewriting engines
• Language is not trivial, but provides a metamodel
  based method to describe transformations better
  than non-Meta based textual code

18
Questions?
Well HAL, Im damned if I can find anything
wrong with it. Yes. Its puzzling, isnt
it. -- 2001 A Space Odyssey