ARTIST2 - MOTIVES Trento - Italy, February 19-23, 2007 Model Transformation and UML Reiko Heckel University of Leicester, UK Foundations of Model Transformation

Motivation: Model-driven Engineering ● Focus and primary artifacts are models instead of programs ● Core activities include – maintaining consistency – evolution – translation – execution of models ● These are examples of model transformations ● A math. foundation is needed for studying – expressiveness and complexity – execution and optimisation – well-definedness – preservation of semantics of transformations ● Graph transformations can be one such foundation

Outline ● Graph Transformation – why it is fun – how it works ● Semantics-preserving Model Transformation

Why it is fun: Programming By Example StageCast ( a visual programming environment for kids (from 8 years on), based onwww.stagecast.com – behavioral rules associated to graphical objects – visual pattern matching – simple control structures (priorities, sequence, choice,...) – external keyboard control  intuitive rule-based behavior modelling Next: abstract from concrete visual presentation

States of the PacMan Game: Graph-Based Presentation :Ghost :Field :PacMan marbles=3 instance graph (represents a single state; abstracts from spatial layout) type graph (specifies legal instance graphs) :Marble typing Field PacMan marbles:int Ghost Marble 1 11 * * *

Rules of the PacMan Game: Graph-Based Presentation, PacMan f1:Fieldf2:Field pm:PacMan f1:Fieldf2:Field pm:PacMan movePM pm:PacMan marbles=m f1:Fieldf2:Field :Marble f1:Fieldf2:Field pm:PacMan marbles=m+1 collect

Rules of the PacMan Game: Graph-Based Presentation, Ghost f1:Fieldf2:Field g:Ghost f1:Fieldf2:Field g:Ghost moveGhost g:Ghost f1:Fieldf2:Field :PacMan f1:Fieldf2:Field g:Ghost kill

Graph Transformation :Ghost :Field :Marble :PacMan marbles=3 :PacMan marbles=4 typing collect ; kill Field PacMan marbles:int Ghost Marble 1 11 * * *

Outline ● Graph Transformation why it is fun – how it works ● Semantics-preserving Model Transformation

A Basic Formalism: Typed Graphs Directed graphs – multiple parallel edges – undirected edges as pairs of directed ones Graph homomorphism as mappings preserving source and target Typed graphs given by – fixed type graph TG – instance graphs G typed over TG by homomorphism g g:Ghost :Field f:Field g Field PacMan marbles:int Ghost Marble G TG

Rules p: L  R with L  R well-defined, in different presentations – like above (cf. PacMan example) – with L  R explicit [DPO]: L  K  R f1:Fieldf2:Field pm:PacMan movePM: f1:Fieldf2:Field pm:PacMan

Rules p: L  R with L  R well-defined, in different presentations – like above (cf. PacMan example) – with L  R explicit [DPO]: L  K  R – with L, R integrated [UML, Fujaba]: L  R and marking ● L - R as destroyed ● R - L as new f1:Fieldf2:Field pm:PacMan movePM: {destroyed} {new}

Transformation Step  select rule p: L  R ; occurrence o L : L  G  remove from G the occurrence of L\ R  add to result a copy of R \ L f1:Field f2:Field pm:PacMan marbles=3 m2:Marble oLoL G LR p pm:PacMan marbles=m f2:Fieldf1:Field m1:Marble f2:Fieldf1:Field pm:PacMan marbles=m+1 f3:Field m1:Marble oRoR pm:PacMan marbles=4 H f1:Field f2:Field m2:Marble f3:Field

Semantic Questions: Dangling Edges ● conservative solution: application is forbidden – invertible transformations, no side-effects ● radical solution: delete dangling edges – more complex behavior, requires explicit control a:A :B ?

A bit of History … Chomsky Grammars Term Rewriting Petri Nets Graph Transformation and Graph Grammars Diagram Languages Behaviour Modelling and Visual Programming Models of Computation

Outline Graph Transformation why it is fun how it works ● Semantics-preserving Model Transformation – operational – denotational Abstract Syntax Semantic Domain denotational semantics operational semantics transformation

Example: Executable Business Process ● refactoring of business processes, replacing centralised by distributed execution ● How to demonstrate preservation of behaviour?  specify operational semantics of processes  define transformations  show that transformations preserve semantics Receive order Undo order Shipment Warehouse Office

Operational Semantics: Idea ● diagram syntax plus runtime state ● GT rules to model state transitions Abstract Syntax operational semantics

Operational Semantics: Formally GTS = (TG, P) with start graph G 0 defines transition system LTS(GTS, G 0 ) = (S, L,  ) taking – as states S all graphs reachable from G 0 – observations on rules as labels – transformations as transitions

EdgeNode Basic op: String Structured Orch name: String Msg op: String id: String SwitchInvoke src tar current tofrom partner request Reply response Elem corresponds responsible Type Graph: Metamodel …… with runtime state Abstract Syntax

Rules: Invoke another Service e:Edge tar i:Invoke o1:Orcho2:Orch current partner e:Edge tar i:Invoke o1:Orcho2:Orch current partner m:Msg id=new() op=i.op from to req(i.id, m.id) request Abstract Syntax operational semantics

Rules: Answer the Invocation e:Edge tar r:Reply o1:Orcho2:Orch current m1:Msg op=r.op fromto e:Edge tar r:Reply o1:Orcho2:Orch current m1:Msg op=r.op fromto m2:Msg id=new() op=r.op from to reply(r.id, m1.id, m2.id) response src e:Edge src e:Edge Abstract Syntax operational semantics

Rules: Receive the Response i:Invoke o1:Orcho2:Orch current src m1:Msg to from m2:Msg to from e:Edge partner i:Invoke o1:Orcho2:Orch current src e:Edge partner resp(i.id, m2.id) request response Abstract Syntax operational semantics

Simulation :Edge tar i:Invokeo1:Orcho2:Orch current partner :Edge src :Edge tar r:Reply :Edge src current m1:Msg op=i.op from to request m2:Msg op=r.op from to response Observations:req(i.id, m1.id);reply(r.id, m1.id, m2.id);resp(i.id, m2.id)

Refactoring Executable Processes ● replace local control flow by message passing … Orch 1 Orch 2 … … Orch1 Orch 2 > Orch2.op > op > op … … … … … delegate

Semantic Compatibility Processes P 1 and P 2 are semantically compatible if they are weakly bisimilar after hiding labels not in alph(P 1 ) ⋂ alph(P 2 ) Show for trafo P 1  P 2 that P 2 simulates P 1, i.e. – P 1  obs Q 1 implies P 2  obs Q 2 – Q 2 simulates Q 1 and vice versa. Approach: – mixed (local) confluence – critical pair analysis P1P1 Q1Q1 P2P2 Q2Q2 obs obs

Critical Pairs and Local Confluence ● a pair of rules (p 1, p 2 ) in a minimal conflict situation ● constructed by overlapping their left-hand sides so that they intersect in items to be deleted ● system is locally confluent if all critical pairs are G H * G2G2 G1G1 * p1p1 p2p2

Critical Pair Analysis in AGG delegate vs operational rules

Critical Pair LHS of invoke vs delegate delete-use-conflict

Outline Graph Transformation why it is fun how it works ● Semantics-preserving Model Transformation operational – denotational Abstract Syntax Semantic Domain denotational semantics operational semantics transformation

Process Improvement Motivation: – transform process to increase flexibility, performance,... – preserve behaviour! Aim: rule-level verification

Rule-level Verification r LR L R r/o s(L) s(R) G H s(G) s(H) Approach: – check for each rule r if s(L) R s(R) – make sure that s(L) R s(R) implies s(G) R s(H) semantic domain

Works if … ● we select semantic domain SD where relation R is compositional – trace or failures equivalence or refinement in CSP is closed under context ● we can show that semantic mapping s: AS  SD is compositional – maps union of graphs to composition of CSP processes  use GT to define mapping s

Context-Free Graph Grammar do something out in Act Start graph: Act in out Act in out ::= Productions in EBNF-like notation: Act in out Act [c] [not c] Concrete syntax of well-structured activity diagrams Abstract Syntax

Analysis check availability receive order notify client calculate prize send receipt [product not available] [product available]

Pair Grammar A:Act in out A1:Act in out A2:Act do something out in ::= A:Act A1:Act in out A2:Act [c] [not c] Proc(A) ::= Proc(A1) ; Proc(A2) if [c] then Proc(A1) else Proc(A2) do something Source: well-structured activity diagrams Proc(A) Target: CSP Abstract Syntax Semantic Domain denotational semantics

Synthesis Proc(A0) Proc(A1) ; Proc(A2) … Proc(A3) ; Proc (A4) ; if [product available] then Proc(A5) else Proc(A8) … receive order ; check availability ; if [product available] then calculate prize ; send receipt else notify client check availability receive order notify client calculate prize send receipt [product not available] [product available]

Good Enough … ?  Visual  abstract syntax or concrete syntax templates  Bi-directional  swap source and target grammars  Declarative  Expressive ?  context-free graph languages only  Traceable ?  through naming conventions  Efficient ?  NP complete parsing problem  …  Triple Graph Grammars (see Andy’s lecture) Challenge: verify compositionality for more complex mappings

Relevant Theory Chomsky Grammars Term Rewriting Petri Nets Graph Transformation and Graph Grammars   Formal language theory of graphs;   Diagram compiler generators   Concurrency theory   Causality and conflict   Processes, unfoldings   Event-structures   Stochastic concepts   Verification, …   Well-definedness   Termination   Confluence   Semantics of process calculi