exceptional transformations

*McGill UniversityMontreal, Canada

†Universiteit AntwerpenAntwerp, Belgium

Exceptional Transformations

Eugene Syriani*,Jörg Kienzle*, and Hans

Vangheluwe*†


OUTLINE

Motivation

Classification

Modelling of transformation exceptions

Exception handling in the transformation

Conclusion2


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)

1. The transformation design

2. The model on which it is applied

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 ...



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

• 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

• 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

• 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

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


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


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

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: return to the normal flow, right after where the transformation was interrupted

2) Restart: re-run enclosing transformation from the beginning

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

19


IMPLEMENTATION IN MoTif [1]

Virtual Machine

SE

Convert to TEALE

TLSE TLSE

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


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

20

exceptional transformations

Documents