1. * McGill University Montreal, Canada † Universiteit Antwerpen Antwerp, Belgium Eugene Syriani *, Jörg Kienzle *, and Hans Vangheluwe *†

2. OUTLINE  Motivation  Classification  Modelling of transformation exceptions  Exception handling in the transformation  Conclusion 2

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 ) 3

4. EXCEPTIONAL SITUATIONS 4 In a transformation model, faults may originate from: (in workflow order) design 1.The transformation design model 2.The model on which it is applied context 3.The context in which the MT is executed

5. CLASSIFICATION OF EXCEPTIONS IN MT 5 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 6 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 7 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 8 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 9 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 10 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 11 Deeper branches Some classes of exceptions may be empty for certain MT environments (ALE, TSLE)

12. DEBUG VS. RELEASE MODE design faults 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 dependability 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) 12

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

14. EXCEPTIONAL RULE 14 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) 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 Purist Approach 15

16. EXCEPTION HANDLING MODEL (II)  Add a handler block as dispatcher to properly handle the flow according to TE type Pragmatic Approach 16

17. POST-HANDLING CONTROL FLOW 1)Resume 1)Resume: return to the normal flow, right after where the transformation was interrupted 2)Restart 2)Restart: re-run enclosing transformation from the beginning 3)Terminate 3)Terminate: skip the entire flow of the transformation – End in applicable/not-applicable state (and not exception) What happens after we handle the exception? 17

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 18

19. MoTif IMPLEMENTATION IN MoTif [1] 19 Virtual Machine SE Convert to TE ALE TLSETLSE TLSE RDE TSE [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 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 modelled Exceptions modelled in the transformation language handlers – Extended with handlers – Control-flow – Control-flow issues fault-tolerant transformations Enables the design of fault-tolerant transformations 20

21. INTER-COMPONENT EXCEPTION PROPAGATION 21 T-Core element def packetIn(self, π): try: result = apply(π) self.packet = result.packet self.success = result.success except TCException, χ: self.exception = χ except χ: self.exception = χ MoTif-Core (atomic) element def externalTransition(state): E = state.peak(packetInport) π = extractPacket(E) state.TC.packetIn(π’) def output(state): if state.TC.exception: χ = exceptionToEvent(TC.exception) poke(exceptionOutport, χ) else: π = packetToEvent(self.TC.packet) if state.TC.success: poke(successOutport, π) else: poke(failOutport, π) T-Core error VM error    Transformation design