Exploiting user-definable synchronizations in graph transformation

1. Exploiting user-definable synchronizationsin graph transformation Ivan Lanese Computer Science Department University of Bologna Italy

2. Roadmap • Synchronized Hyperedge Replacement • The airport case study • Parametric SHR • Computing a transition step-by-step • Conclusions

3. Roadmap • Synchronized Hyperedge Replacement • The airport case study • Parametric SHR • Computing a transition step-by-step • Conclusions

4. Graph transformation • Graphs used to model system structure • (Hyper)edges are components • Nodes are communication channels • Graph transformation model system evolution • Rules replace parts of the graph with new parts • Captures in an intuitive way reconfiguration

5. The SHR approach • Traditional graph transformation (e.g., DPO) requires to match large subgraphs • Difficult to implement in a distributed setting • The SHR approach • Rules (productions) describe the behaviour of single edges • Productions applied locally • Synchronization to coordinate different productions

6. Standard SHR presentation • Algebra to represent graphs • LTS-based semantics • Inference rules to derive transitions from productions • Apt for developing theory • Induction on the derivation, coinduction • Difficult to understand • A transition is a result of many steps of derivation • Heavy technicalities

7. Our SHR presentation • Set-theoretical presentation of graphs • LTS-based semantics • Algorithm to derive the allowed transitions • Each step corresponds to an intuitive check • Choice of the productions, verification of the synchronization constraints, … • More easy to guess the resulting transitions • More easy to program

8. at at R S L chk chk More on productions • Rewrite an edge into a graph preserving the interface • Many productions can be applied concurrently • Synchronization constraints must be satisfied • Mobility can change the interface

9. Basics of synchronization & mobility • Productions can execute actions on attached nodes • Actions executed on each node at each step must be compatible • Actions can carry nodes as parameters • Parameters of synchronizing actions may be merged Synchronization Mobility

10. Roadmap • Synchronized Hyperedge Replacement • The airport case study • Parametric SHR • Computing a transition step-by-step • Conclusions

11. The airport case study • Taken from AGILE project on architectures for mobility • Models airplanes taking off and landing at airports and persons traveling using them • Modeled inside AGILE using • UML extended with mobility primitives • Synchronized variant of DPO • We concentrate on a small part of the case study

12. inBo Our aim univ univ chk inPl inBo chk inPl

13. at in newat at chk in Programming using productions (1) at:<ε,<>> in:<ack,<at>> at:<req,<newat>> chk: <breq,<in>> in:<ε,<>>

14. newat chk at Programming using productions (2) at:<ε,<>> chk: <brd,<newat>> Idle productions always available

15. Roadmap • Synchronized Hyperedge Replacement • The airport case study • Parametric SHR • Computing a transition step-by-step • Conclusions

16. Parametric SHR • A member of SHR family • Synchronization and mobility patterns not fixed but user-definable • Specified using Synchronization Algebras with Mobility • Allows to use each time the most suitable synchronization primitives

17. Synchronization Algebras with Mobility • Specify how actions synchronize • Two at the time, associativity and commutativity required • From Winskel’s synchronization algebras • Partial operator ● for action synchronization • Action ε for “not taking part to the synchronization” • Added • Arities of actions • Function from parameters of the synchronizing actions to parameters of the result • Set of final actions

18. τ in out a a ε Milner SAM • Normal actions, coactions, τ, ε • in ● out = τ • a ● ε = a • Final actions: τ, ε

19. out in out in in in Broadcast SAM • Normal actions, coactions,ε • in ● out = out • in ● in = in • ε●ε = ε • Final actions: out, ε

20. And many more • SAMs can be defined for many synchronization policies • Mutual exclusion • Priority synchronization • … • SAMs can be combined • In the example: req and acq interacting using Milner synchronization and breq and brd interacting using broadcast

21. Applying a SAM • SAMs used to synchronize tuples of actions ai carrying parameters pi • If synchronization is allowed we can compute • A resulting action c • A substitution σ • A tuple of parameters p

22. Applying broadcast • Broadcast synchronization is allowed if • at most one action is “out” • if there is an ε, then all the actions are ε • The result is • ε if all actions are ε • “in” if all the actions are “in” (not allowed on bound nodes) • “out” otherwise • Substitution σ computed as mgu of equalities pi=pj for all i, j • Parameters p computed as piσ (any i can be chosen)

23. Roadmap • Synchronized Hyperedge Replacement • The airport case study • Parametric SHR • Computing a transition step-by-step • Conclusions

24. The algorithm (1) • One production is chosen for each edge • Idle production for passenger not checked in • Productions shown before for other edges • New nodes are local to productions • The actions executed on each node x are synchronized • Action cx, parameters px and substitution σx as results • If x is bound then cx must be final

25. Synchronization in the example ε,<> univ ack,<univ> inBo ε,<> ε,<> req,<newat> ε,<> brd,<new1> breq,<inPl> chk ε,<> brd,<new2> inPl

26. Synchronization in the example ε univ inBo τ univ/newat brd,<new1> breq,<inPl> chk ε brd,<new2> inPl

27. Synchronization in the example ε univ inBo τ univ/newat breq,<inPl> chk ε inPl/new1,inPl/new2 inPl

28. The algorithm (2) • Global substitution σ computed by • Merging the substitutions σx from single nodes • Final label contain • The triple <x, cx, pxσ> for each free x in the LHS • Final graph computed by • Merging the RHSs of the productions • Applying the global substitution σ • Hiding nodes unless free in the LHSs or occurring in the label • Deleting isolated nodes

29. new1 new2 Result of the transition univ newat chk inBo inPl univ/newat, inPl/new1, inPl/new2

30. Result of the transition univ chk inBo inPl univ/newat, inPl/new1, inPl/new2

31. Result of the transition univ chk inBo inPl The label is <x,ε,<>>

32. Result of the transition univ chk inBo inPl All nodes but univ are hidden

33. Roadmap • Synchronized Hyperedge Replacement • The airport case study • Parametric SHR • Computing a transition step-by-step • Conclusions

34. Conclusions • About SHR • Powerful graph transformation framework • Allows to relate local and global views of the system • About PSHR • Allows to simplify the specification of complex transformations • About this presentation of PSHR • Less suitable for developing theory • Hopefully more apt for designers/developers • The two views are (nearly) equivalent: the most suitable can be chosen at each time

35. Future work • I have moved, so I’m not sure I will continue working on this • Some interesting things on SHR under development • Category of SAMs to compose and compare them • Applying SHR to QoS • Abstract semantics for SHR • One thing that is surely missing • Implementation of SHR

36. End of talk Thanks Questions?