Presentation on theme: "* McGill University Montreal, Canada † Universiteit Antwerpen Antwerp, Belgium Eugene Syriani *, Jörg Kienzle *, and Hans Vangheluwe *†"— Presentation transcript:
* McGill University Montreal, Canada † Universiteit Antwerpen Antwerp, Belgium Eugene Syriani *, Jörg Kienzle *, and Hans Vangheluwe *†
OUTLINE Motivation Classification Modelling of transformation exceptions Exception handling in the transformation Conclusion 2
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
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
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 ...
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 ...
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)
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
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
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
CLASSIFICATION OUTLINE 11 Deeper branches Some classes of exceptions may be empty for certain MT environments (ALE, TSLE)
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
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
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
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
EXCEPTION HANDLING MODEL (II) Add a handler block as dispatcher to properly handle the flow according to TE type Pragmatic Approach 16
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
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
MoTif IMPLEMENTATION IN MoTif  19 Virtual Machine SE Convert to TE ALE TLSETLSE TLSE RDE TSE  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).
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