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. Metamodeling Language describe 1 DSVL DSVL’ describes describes 2 Domain-Specific Models (Domain-Specific Models)’ describe describe Computer based system Describe the process to transform from DSVL to DSVL’ 1 Using the formal description in [1], transform the domain models accordingly 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, I’m damned if I can find anything wrong with it.” “Yes. It’s puzzling, isn’t it.” -- 2001: A Space Odyssey