Rule-based programming has been shown to be very successful in many application areas. Two prominent examples are the specification of model transformations in model driven development approaches and the definition of structured operational semantics of formal languages. General rewriting frameworks such as Maude are flexible enough to allow the programmer to adopt and mix various rule styles. The choice between styles can be biased by the programmer's background. For instance, experts in visual formalisms might prefer graph-rewriting styles, while experts in semantics might prefer structurally inductive rules. This paper evaluates the performance of different rule styles on a significant benchmark taken from the literature on model transformation. Depending on the actual transformation being carried out, our results show that different rule styles can offer drastically different performances. We point out the situations from which each rule style benefits to offer a valuable set of hints for choosing one style over the other.

1. Evaluating the performance of model
transformation styles with Maude
Roberto Bruni Alberto Lluch Lafuente
Uni Pisa IMT Lucca
Acks to Artur Boronat (Uni Leicester)
International Symposium on Formal Aspects of Component Software
September 14-16, 2011, Oslo

2. ·1· Background and Motivation
·2· Case studies
·3· Some implementation notes
·4· Experiments
·5· Conclusion

3. ·1· Background and Motivation
·2· Case studies
·3· Some implementation notes
·4· Experiments
·5· Conclusion

4. ·1· Background and Motivation
·2· Case studies
·3· Some implementation notes
·4· Experiments
·5· Conclusion

5. ·1· Background and Motivation
·2· Case studies
·3· Some implementation notes
·4· Experiments
·5· Conclusion

6. ·1· Background and Motivation
·2· Case studies
·3· Some implementation notes
·4· Experiments
·5· Conclusion

7. ·1· Background and Motivation
·2· Case studies
·3· Some implementation notes
·4· Experiments
·5· Conclusion

13. Server
status: busy
Client
status: connected

14. Server Server
status: busy status: free!
Client Client
status: connected status: disconnected!

16. Server
status: free
Client
status: disconnected

17. Server Server
status: free status: Y
Client Client
status: disconnected status: connected!

18. Server Server
status: free status: Y
Client Client
status: disconnected status: connected!
if
Server Server
status: free status: Y

19. Server Server
status: free status: Y
Client Client
status: disconnected status: connected!
if
Server Server
status: free status: Y
and
Client Client
status: disconnected status: connected!

21. Locality
Server
Locality
Server
Client
Client Client

22. Locality
Server
Locality
Server
Client
Client Client

23. Locality
Server
Locality
Server
Client
Client Client

24. GT vs SOS?

25. GT vs SOS?
● Easiness;

26. GT vs SOS?
● Easiness;
● Understandability;

27. GT vs SOS?
● Easiness;
● Understandability;
● Verification;

28. GT vs SOS?
● Easiness;
● Understandability;
● Verification;
● …

29. GT vs SOS?
● Easiness;
● Understandability;
● Verification;
● …
● Performance (this paper!)

30. ·1· Background and Motivation
·2· Case studies
·3· Some implementation notes
·4· Experiments
·5· Conclusion

31. case study #1: component migration

32. case study #1: component migration

33. case study #1: component migration

34. case study #1: component migration

35. case study #1: component migration

36. case study #1: component migration

37. case study #1: component migration

38. case study #1: component migration

39. case study #1: component migration

40. case study #1: component migration

41. case study #1: component migration

42. case study #2: class diagrams to relational schemas

43. case study #2: class diagrams to relational schemas

44. case study #2: class diagrams to relational schemas

45. case study #2: class diagrams to relational schemas

46. case study #2: class diagrams to relational schemas

47. case study #2: class diagrams to relational schemas

48. case study #2: class diagrams to relational schemas

49. case study #3: pullup refactoring

50. case study #3: pullup refactoring

51. case study #3: pullup refactoring

52. case study #3: pullup refactoring

53. case study #3: pullup refactoring

54. ·1· Background and Motivation
·2· Case studies
·3· Some implementation notes
·4· Experiments
·5· Conclusion

56. a a
P → P' Q → Q'
τ
P|Q → P'|Q'

57. A rule like
a
t → t'

58. A rule like
a
t → t'
Following Verdejo is implemented as
t => {a}t'

59. A rule like
a
t → t'
Following Verdejo is implemented as
t => {a}t'
Our case studies allow this “top-down” variant
{a}t => t'

60. ·1· Background and Motivation
·2· Case studies
·3· Some implementation notes
·4· Experiments
·5· Conclusion

61. experiment #1

62. experiment #1/hypothesis
“SOS* outperforms SOS”

63. experiment #1/results
Yes! :)
No! :(
Well... :|

64. experiment #1/results
Yes! :)
No! :(
Well... :|

65. experiment #1/results
Yes! :)
No! :(
Well... :|

66. experiment #2

67. experiment #2/hypothesis
“SOS degenerates when the
number of possible (unnecesary)
transformations increases ”

68. experiment #2/setting
Component Component
status: normal status: status1

69. experiment #2/setting
Component Component
status: normal status: status1
Component Component
status: normal status: status2

70. experiment #2/setting
Component Component
status: normal status: status1
Component Component
status: normal status: status2
...
Component Component
status: normal status: statusN

71. experiment #2/results

72. experiment #3

73. experiment #3/hypothesis
“the performance of SOS* and
GT varies a lot depending on the
setting”

74. experiment #3/results
SOS*
SPO
SPO

75. experiment #3/results
SOS*
GT
GT

76. experiment #4

77. experiment #4/hypothesis
“SOS suffers in presence of
cross-layering edges”

78. experiment #4/setting

79. experiment #4/setting

80. experiment #4/setting

81. experiment #4/setting

82. experiment #4/setting

83. experiment #4/results
(before)

84. ·1· Background and Motivation
·2· Case studies
·3· Some implementation notes
·4· Experiments
·5· Conclusion

85. Summary
● Many ways to program MDT;

86. Summary
● Many ways to program MDT;
● We have considered two prominent ones;

87. Summary
● Many ways to program MDT;
● We have considered two prominent ones;
● Performance varies drastically;

88. Summary
● Many ways to program MDT;
● We have considered two prominent ones;
● Performance varies drastically;
● Each exploits a different representation...

89. Summary
● Many ways to program MDT;
● We have considered two prominent ones;
● Performance varies drastically;
● Each exploits a different representation...
● but we can pass from one to the other.

90. experiment #5

91. experiment #5/hypothesis
“flattening is more efficient
than nesting”

92. experiment #5/results

93. Outlook
● Other styles, implementations, examples;

94. Outlook
● Other styles, implementations, examples;
● Export to other settings;

95. Outlook
● Other styles, implementations, examples;
● Export to other settings;
● (Heuristic) strategies;

96. Outlook
● Other styles, implementations, examples;
● Export to other settings;
● (Heuristic) strategies;
● Parallellism;

97. Outlook
● Other styles, implementations, examples;
● Export to other settings;
● (Heuristic) strategies;
● Parallellism;
● Non-determinism;
● ...

98. thanks a lot!

99. alberto.lluch@imtlucca.it
linkedin.com/in/albertolluch