Exceptional Transformations

1. Exceptional Transformations Eugene Syriani*, Jörg Kienzle*, and Hans Vangheluwe*†

2. Outline • Motivation • Classification • Modelling of transformation exceptions • Exception handling in the transformation • Conclusion

3. Motivation • Goal: • Industrial adoption of Model Transformation (MT) • Requirements: • Safe and dependable MTs • Debugging of MT • Problem: • Verifying and proving correctness of an MT is very hard • Solution: • Provide forward error recovery mechanism: EXCEPTION HANDLING (generic approach )

4. Exceptional Situations In a transformation model, faults may originate from:(in workflow order) • The transformation design • The model on which it is applied • The context in which the MT is executed

5. Classification OF Exceptions in MT • Execution Environment Exceptions (EEE) Typically originate from the run-time environment • System Exceptions (SE) Context environment, outside of the transformation model • Run out of memory • I/O exception for logging • Communication/access error for remote services • ...

6. Classification OF Exceptions in MT • Execution Environment Exceptions (EEE) Typically originate from the run-time environment • Action Language Exceptions (ALE) Exception tree for specific constraint/action language (e.g., OCL) • Arithmetic manipulations • List manipulations • De-referencing null references • ...

7. Classification OF Exceptions in MT • Transformation Language-Specific Exceptions (TLSE) • Unbound input parameter of rule (ProGReS, QVT, Fujaba) • Invalid pivot node passing (GReAT) • Creation of duplicate elements in presence of key (QVT-R) • Bad timing synchronization in event scheduler for rules evaluated concurrently (MoTif)

8. Classification OF Exceptions in MT • Rule Design Exceptions (RDE) Fault in the design of the transformation model • Inconsistent Use Exceptions (IUE) Conflict between 1 or more rule(s) • Multiple matches found AND rule executed iteratively:loop (ProGReS), for/while-loop (QVT-OM), FRule/SRule (MoTif) • Maybe only one or all possible outputs are correct:Need external input

9. Classification OF Exceptions in MT • Rule Design Exceptions (RDE) Fault in the design of the transformation model • Synchronization Exceptions (YE) Parallel execution of the transformation • Non-independent rules (application of one disables the other) • Non-trivial merging without knowledge of application domain

10. Classification OF Exceptions in MT • Transformation-Specific Exceptions (TSE) • User-defined exceptions • Check desired properties of model at specific checkpoints • Assertion on sub-transformation (pre/post-condition) • Ability to explicitly raise an exception if assertion fails

11. Classification Outline • Deeper branches • Some classes of exceptions may be empty for certain MT environments (ALE, TSLE)

12. Debug vs. Release Mode • Debug: eliminate design faults • Debugging a MT is not trivial • Exception handling can help detecting logical errors • Add assertion rules which raise a TSE if not applicable • Release: increase dependability of the MT at run-time • Must produce correct output: ability to recover from exceptional situation • Instead of suddenly terminating the transformation (EEE) • Device not writable  retry later (SE) • Fatal errors  exit in a safe state (SE) • External input (IUE)

13. Transformation exception model • Exceptions should be treated as first-class entities • An exception is modelled explicitly conform to a distinct meta-model: • What? • Context: stack frame + local/global state of MT + local/global state of model • Stack keeps track of the invoking contexts • Where? • Information on activation point: exact path to rule • Granularity: CRUD or Rule or Transformation Operator • When? • Useful for profiling & debugging

14. Exceptional Rule • Receive a model as input • Three possible outcomes: • Successfully transformed model (applicable) • Unmodified model (inapplicable) • Exception (error occurred) • Case of error occurrence • Matching phase: model not modified • Rewriting phase: may be partially modified • Partial output • Backward error recovery

15. Exception Handling model (I) Purist Approach • A transformation exception (TE) is a model that can be matched and transformed in a MT • TE is input to other rules whose pre-condition looks for a specific TE type • Branching among possible expected TE types • Default handler if not an expected type • Priorities can be used • Elegant, but unusable in practice

16. Exception Handling model (II) Pragmatic Approach • Add a handler block as dispatcher to properly handle the flow according to TE type

17. Post-Handling control flow What happens after we handle the exception? • Resume: return to the normal flow, right after where the transformation was interrupted • Restart: re-run enclosing transformation from the beginning • Terminate: skip the entire flow of the transformation • End in applicable/not-applicable state (and not exception)

18. Exception Propagation • Some transformation models are hierarchical • Nesting, scoping, composition • Locally handling an exception is not always feasible • Define a handler in a more global context • Local clean-up before propagation • Propagation at top-most “composing block” • Halt execution and display debugging information • Once an exception is handled it can no longer be propagated • Handler must create a user defined exception referring to the original one

19. Implementation in MoTif [1] TLSE TSE TLSE RDE TLSE Virtual Machine ALE Convert to TE SE [1] Syriani, E. and Vangheluwe, H. (2009) DEVS as a Semantic Domain for Programmed Graph Transformation . In book: Discrete-Event Modeling and Simulation: Theory and Applications. CRC Press, Boca Raton (USA).

20. Conclusion • Classified potential exceptions that can occur in MT • Different uses at different steps of the development of the MT • Handled by the transformation model itself • Exceptions modelled in the transformation language • Extended with handlers • Control-flow issues • Enables the design of fault-tolerant transformations