1. Exploiting the hierarchical structure of
rule-based specifications for decision planning
Alberto Lluch
Artur Boronat
Roberto Bruni
Ugo Montanari
Generoso Paolillo
IFIP International Conference on Formal Techniques for Distributed Systems
June 7 – 10, 2010, Amsterdam

2. MOF UML RS CD1 CD2 OC1 OC2 TRANSFORMATION REFACTORING RECONFIGURATION
The idea is particularly interesting in model-driven engineering approaches, where models and their manipulation are used in many modelling and analysis activities, at different levels of abstraction.
We focus on the structure of models and structural changes like changes at the meta-model level (e.g. transformation of CD into RDBS), at the model level (refactoring of CDs), or at the instance level (architectural reconfiguration).
RECONFIGURATION
OC1
OC2

3. MOF UML RS CD1 CD2 OC1 OC2 TRANSFORMATION Rewriting Logic Semantics
[Boronat,Meseguer
@FASE'08]
CD1
REFACTORING
CD2
The idea is particularly interesting in model-driven engineering approaches, where models and their manipulation are used in many modelling and analysis activities, at different levels of abstraction.
We focus on the structure of models and structural changes like changes at the meta-model level (e.g. transformation of CD into RDBS), at the model level (refactoring of CDs), or at the instance level (architectural reconfiguration).
RECONFIGURATION
OC1
OC2

4. MOMENT2=ECLIPSE+MAUDE
MOF
UML
TRANSFORMATION RS
Rewriting Logic Semantics
[Boronat,Meseguer
@FASE'08]
CD1
REFACTORING
CD2
The idea is particularly interesting in model-driven engineering approaches, where models and their manipulation are used in many modelling and analysis activities, at different levels of abstraction.
We focus on the structure of models and structural changes like changes at the meta-model level (e.g. transformation of CD into RDBS), at the model level (refactoring of CDs), or at the instance level (architectural reconfiguration).
RECONFIGURATION
OC1
OC2
MOMENT2=ECLIPSE+MAUDE

5. a In particular our work stems from our previous approaches:
1) Algebraic Semantics for MOF: maude-supported framework for declarative, executable and verifiable model transformations.
2) Algebraic presentations of Hierarchical Graphs and their rule-based manipulation.

6. a
[G(a)] | [H(a)]
In particular our work stems from our previous approaches:
1) Algebraic Semantics for MOF: maude-supported framework for declarative, executable and verifiable model transformations.
2) Algebraic presentations of Hierarchical Graphs and their rule-based manipulation.

7. a [G(a)] | [H(a)] SOS-like rules
In particular our work stems from our previous approaches:
1) Algebraic Semantics for MOF: maude-supported framework for declarative, executable and verifiable model transformations.
2) Algebraic presentations of Hierarchical Graphs and their rule-based manipulation.

8. a [G(a)] | [H(a)] MAUDE SOS-like rules
In particular our work stems from our previous approaches:
1) Algebraic Semantics for MOF: maude-supported framework for declarative, executable and verifiable model transformations.
2) Algebraic presentations of Hierarchical Graphs and their rule-based manipulation.
MAUDE

9. a [G(a)] | [H(a)] MAUDE ADR [Montanari, Bruni, Lluch,
Gadducci, Tuosto, etc.
@TGC'10]
SOS-like rules
In particular our work stems from our previous approaches:
1) Algebraic Semantics for MOF: maude-supported framework for declarative, executable and verifiable model transformations.
2) Algebraic presentations of Hierarchical Graphs and their rule-based manipulation.
MAUDE

10. 1
We promote passing from an implict representation of containment-like relations with flat graphs to an explict onw with hierarchical graphs.
We promote passing from reduction rules (à la SPO) to conditional ones (à la SOS).
Main consequence: proofs are trees, matching localised.
For planning with multi-criteria we propose semirings.
Our propose is of minimal harm for us: flat and hierarchical representations are “homomorphic” (one can have both and use the most convenient at each step), and everything can be implemente within the same back-end tool: Maude.
For GTTs not so easy. Only supported by HGTTs (examples?)

11. 1 2
We promote passing from an implict representation of containment-like relations with flat graphs to an explict onw with hierarchical graphs.
We promote passing from reduction rules (à la SPO) to conditional ones (à la SOS).
Main consequence: proofs are trees, matching localised.
For planning with multi-criteria we propose semirings.
Our propose is of minimal harm for us: flat and hierarchical representations are “homomorphic” (one can have both and use the most convenient at each step), and everything can be implemente within the same back-end tool: Maude.
For GTTs not so easy. Only supported by HGTTs (examples?)

12. 1 2
We promote passing from an implict representation of containment-like relations with flat graphs to an explict onw with hierarchical graphs.
We promote passing from reduction rules (à la SPO) to conditional ones (à la SOS).
Main consequence: proofs are trees, matching localised.
For planning with multi-criteria we propose semirings.
Our propose is of minimal harm for us: flat and hierarchical representations are “homomorphic” (one can have both and use the most convenient at each step), and everything can be implemente within the same back-end tool: Maude.
For GTTs not so easy. Only supported by HGTTs (examples?) 3 q

13. 1 2
We promote passing from an implict representation of containment-like relations with flat graphs to an explict onw with hierarchical graphs.
We promote passing from reduction rules (à la SPO) to conditional ones (à la SOS).
Main consequence: proofs are trees, matching localised.
For planning with multi-criteria we propose semirings.
Our propose is of minimal harm for us: flat and hierarchical representations are “homomorphic” (one can have both and use the most convenient at each step), and everything can be implemente within the same back-end tool: Maude.
For GTTs not so easy. Only supported by HGTTs (examples?) 3 q

14. A B
0..1
0..*
The structure of models is basically given by the notions of classes with attributes and their relations.
Relations are subject to constraints. One typical example are composite aggregation relations which must form a containment relation (e.g. unique container, no self-containment).
As a running example we will use a simple model with just one class (colored boxes) and two relations: a free one (pointers) and a containment one (contains).

15. BOX contains color: ●●●... points
The structure of models is basically given by the notions of classes with attributes and their relations.
Relations are subject to constraints. One typical example are composite aggregation relations which must form a containment relation (e.g. unique container, no self-containment).
As a running example we will use a simple model with just one class (colored boxes) and two relations: a free one (pointers) and a containment one (contains).
points

16. What is an instance (configuration)?
In the graph-based tradition it is a graph typed over the model: objects are represented by nodes, relations with edges.
Containment relations are represented as any other relation
We promote the use of hierarchical graphs (or trees), where containment is explicit: objects can be nested objects.
Both representations are “homomorphic”, no information is lost. The point is how contaitment is represented and exploited.

17. What is an instance (configuration)?
In the graph-based tradition it is a graph typed over the model: objects are represented by nodes, relations with edges.
Containment relations are represented as any other relation
We promote the use of hierarchical graphs (or trees), where containment is explicit: objects can be nested objects.
Both representations are “homomorphic”, no information is lost. The point is how contaitment is represented and exploited.

18. < a:Box | content:b > , < b:Box | container:a >
What is an instance (configuration)?
In the graph-based tradition it is a graph typed over the model: objects are represented by nodes, relations with edges.
Containment relations are represented as any other relation
We promote the use of hierarchical graphs (or trees), where containment is explicit: objects can be nested objects.
Both representations are “homomorphic”, no information is lost. The point is how contaitment is represented and exploited.

19. < a:Box | content:b > , < b:Box | container:a >
What is an instance (configuration)?
In the graph-based tradition it is a graph typed over the model: objects are represented by nodes, relations with edges.
Containment relations are represented as any other relation
We promote the use of hierarchical graphs (or trees), where containment is explicit: objects can be nested objects.
Both representations are “homomorphic”, no information is lost. The point is how contaitment is represented and exploited. b

20. For instance, model conformance, requires to check, among other, that relation constraints are satisfied.
In plain graphs, this containment constraints require a global check (on the whole graph) to detect cycles (top) or non-uniqueness (bottom).
The hierarchical representation ensures correct containment by construction.
In the examples the plain graphs(left) are graphs to be checked, while the pictures on the left are just not hierarchical graphs.

21. For instance, model conformance, requires to check, among other, that relation constraints are satisfied.
In plain graphs, this containment constraints require a global check (on the whole graph) to detect cycles (top) or non-uniqueness (bottom).
The hierarchical representation ensures correct containment by construction.
In the examples the plain graphs(left) are graphs to be checked, while the pictures on the left are just not hierarchical graphs.

22. For instance, model conformance, requires to check, among other, that relation constraints are satisfied.
In plain graphs, this containment constraints require a global check (on the whole graph) to detect cycles (top) or non-uniqueness (bottom).
The hierarchical representation ensures correct containment by construction.
In the examples the plain graphs(left) are graphs to be checked, while the pictures on the left are just not hierarchical graphs.

23. For instance, model conformance, requires to check, among other, that relation constraints are satisfied.
In plain graphs, this containment constraints require a global check (on the whole graph) to detect cycles (top) or non-uniqueness (bottom).
The hierarchical representation ensures correct containment by construction.
In the examples the plain graphs(left) are graphs to be checked, while the pictures on the left are just not hierarchical graphs.

24. Object Collections
(flat graphs)
Conformant

25. (hierarchical graphs)
Object Collections
(flat graphs)
Nested Object
Collections
(hierarchical graphs)
Conformant
Conformant

26. 1 2
We promote passing from an implict representation of containment-like relations with flat graphs to an explict onw with hierarchical graphs.
We promote passing from reduction rules (à la SPO) to conditional ones (à la SOS).
Main consequence: proofs are trees, matching localised.
For planning with multi-criteria we propose semirings.
Our propose is of minimal harm for us: flat and hierarchical representations are “homomorphic” (one can have both and use the most convenient at each step), and everything can be implemente within the same back-end tool: Maude.
For GTTs not so easy. Only supported by HGTTs (examples?) 3 q

27. In the graph-based tradition, models are transformed in a declarative way, by using rules.
The typical rule declares a graph pattern for the redex (blue cloud) and possibly a side condition in form of a negative graph pattern (nac).
Rule matching requires to find the pattern (sub-graph) and check the condition in the whole context (the entire configuration graph).

28. In the graph-based tradition, models are transformed in a declarative way, by using rules.
The typical rule declares a graph pattern for the redex (blue cloud) and possibly a side condition in form of a negative graph pattern (nac).
Rule matching requires to find the pattern (sub-graph) and check the condition in the whole context (the entire configuration graph).

29. In the graph-based tradition, models are transformed in a declarative way, by using rules.
The typical rule declares a graph pattern for the redex (blue cloud) and possibly a side condition in form of a negative graph pattern (nac).
Rule matching requires to find the pattern (sub-graph) and check the condition in the whole context (the entire configuration graph).

30. In the graph-based tradition, models are transformed in a declarative way, by using rules.
The typical rule declares a graph pattern for the redex (blue cloud) and possibly a side condition in form of a negative graph pattern (nac).
Rule matching requires to find the pattern (sub-graph) and check the condition in the whole context (the entire configuration graph).

31. Consider the following recurrent pattern: elimination of a (red) container with content migration (which requires color change)
For plain graphs we have two rules: one for individual migration, another one for removing the container if empty.

32. Consider the following recurrent pattern: elimination of a (red) container with content migration (which requires color change)
For plain graphs we have two rules: one for individual migration, another one for removing the container if empty.

33. In the graph-based tradition, models are transformed in a declarative way, by using rules.
The typical rule declares a graph pattern for the redex (blue cloud) and possibly a side condition in form of a negative graph pattern (nac).
Rule matching requires to find the pattern (sub-graph) and check the condition in the whole context (the entire configuration graph).

34. In the graph-based tradition, models are transformed in a declarative way, by using rules.
The typical rule declares a graph pattern for the redex (blue cloud) and possibly a side condition in form of a negative graph pattern (nac).
Rule matching requires to find the pattern (sub-graph) and check the condition in the whole context (the entire configuration graph).

35. In the graph-based tradition, models are transformed in a declarative way, by using rules.
The typical rule declares a graph pattern for the redex (blue cloud) and possibly a side condition in form of a negative graph pattern (nac).
Rule matching requires to find the pattern (sub-graph) and check the condition in the whole context (the entire configuration graph).

36. We promote the use of conditional rules, guided by the containment hierarchy.
In many situations this makes sense: level-by-level transformations, reconfigurations of hierarchical configurations with monitors, etc.
The main consequence is that rule contexts are reduced.
One typical rule format (figure) allows for an object to change (color) if its content is able to change (color) accordingly.
Note that collecting the content is necessary for plain graphs, not for hierarchical ones.

37. We promote the use of conditional rules, guided by the containment hierarchy.
In many situations this makes sense: level-by-level transformations, reconfigurations of hierarchical configurations with monitors, etc.
The main consequence is that rule contexts are reduced.
One typical rule format (figure) allows for an object to change (color) if its content is able to change (color) accordingly.
Note that collecting the content is necessary for plain graphs, not for hierarchical ones.

38. In the hierarchical case we need to follow a classical pattern of three rules.
The first one is declares the migration at the topmost level: container removal and migration is possible (rule conclusion on the bottom) if content is ready to change color (rule condition on top).

39. In the hierarchical case we need to follow a classical pattern of three rules.
The first one is declares the migration at the topmost level: container removal and migration is possible (rule conclusion on the bottom) if content is ready to change color (rule condition on top).

40. In the hierarchical case we need to follow a classical pattern of three rules.
The first one is declares the migration at the topmost level: container removal and migration is possible (rule conclusion on the bottom) if content is ready to change color (rule condition on top).

41. The second rule allows for collecting color change from sets within the same container.
The last rule is individual color change.

42. The second rule allows for collecting color change from sets within the same container.
The last rule is individual color change.

43. The second rule allows for collecting color change from sets within the same container.
The last rule is individual color change.

44. The second rule allows for collecting color change from sets within the same container.
The last rule is individual color change.

45. The second rule allows for collecting color change from sets within the same container.
The last rule is individual color change.

46. WHICH STYLE
IS BEST?

47. What is an instance (configuration)?
In the graph-based tradition it is a graph typed over the model: objects are represented by nodes, relations with edges.
Containment relations are represented as any other relation
We promote the use of hierarchical graphs (or trees), where containment is explicit: objects can be nested objects.
Both representations are “homomorphic”, no information is lost. The point is how contaitment is represented and exploited.

48. vs What is an instance (configuration)?
In the graph-based tradition it is a graph typed over the model: objects are represented by nodes, relations with edges.
Containment relations are represented as any other relation
We promote the use of hierarchical graphs (or trees), where containment is explicit: objects can be nested objects.
Both representations are “homomorphic”, no information is lost. The point is how contaitment is represented and exploited.

49. What is an instance (configuration)?
In the graph-based tradition it is a graph typed over the model: objects are represented by nodes, relations with edges.
Containment relations are represented as any other relation
We promote the use of hierarchical graphs (or trees), where containment is explicit: objects can be nested objects.
Both representations are “homomorphic”, no information is lost. The point is how contaitment is represented and exploited.

50. vs What is an instance (configuration)?
In the graph-based tradition it is a graph typed over the model: objects are represented by nodes, relations with edges.
Containment relations are represented as any other relation
We promote the use of hierarchical graphs (or trees), where containment is explicit: objects can be nested objects.
Both representations are “homomorphic”, no information is lost. The point is how contaitment is represented and exploited.

51. Note that rewrite proofs can be system executions, reconfigurations, transformations, counterexamples, etc.
Rewrite proofs in flat/spo approaches are sequential (grey path in the figure).

52. Note that rewrite proofs can be system executions, reconfigurations, transformations, counterexamples, etc.
Rewrite proofs in flat/spo approaches are sequential (grey path in the figure).

53. Note that rewrite proofs can be system executions, reconfigurations, transformations, counterexamples, etc.
Rewrite proofs in flat/spo approaches are sequential (grey path in the figure).

54. Note that rewrite proofs can be system executions, reconfigurations, transformations, counterexamples, etc.
Rewrite proofs in flat/spo approaches are sequential (grey path in the figure).

55. With conditional rules, rewrite proofs form trees.
Typically leafs regard individual objects, and internal nodes collect the transformations within containers.

56. With conditional rules, rewrite proofs form trees.
Typically leafs regard individual objects, and internal nodes collect the transformations within containers.

57. With conditional rules, rewrite proofs form trees.
Typically leafs regard individual objects, and internal nodes collect the transformations within containers.

58. With conditional rules, rewrite proofs form trees.
Typically leafs regard individual objects, and internal nodes collect the transformations within containers.

59. SPO PURE SOS time LOCAL SOS 24 25 26 Which style of rules is best?
Usability of the two styles is arguably: the plain one follows a sequential reasoning based on local changes, the hierarchical one an inductive reasoning based on composing changes.
This is a subjective comparison, but there are two objective factors: constraint preservation and performance.
Hierarchical rules preserve containment constraints by construction, plain rules may violate containment constraint.
As for performance, the hierarchical approach is in many cases more efficient due to localisation.
LOCAL SOS 24 25 26

60. 1 2
We promote passing from an implict representation of containment-like relations with flat graphs to an explict onw with hierarchical graphs.
We promote passing from reduction rules (à la SPO) to conditional ones (à la SOS).
Main consequence: proofs are trees, matching localised.
For planning with multi-criteria we propose semirings.
Our propose is of minimal harm for us: flat and hierarchical representations are “homomorphic” (one can have both and use the most convenient at each step), and everything can be implemente within the same back-end tool: Maude.
For GTTs not so easy. Only supported by HGTTs (examples?) 3 q

61. In the hierarchical case we need to follow a classical pattern of three rules.
The first one is declares the migration at the topmost level: container removal and migration is possible (rule conclusion on the bottom) if content is ready to change color (rule condition on top).

62. Performance issues are more significant transformations are not deterministic.
In presence of choices/decisions, we need transformations plans.

63. ?
Performance issues are more significant transformations are not deterministic.
In presence of choices/decisions, we need transformations plans.

64. or ? ?
Performance issues are more significant transformations are not deterministic.
In presence of choices/decisions, we need transformations plans.

65. 1 2
The second rule allows for collecting color change from sets within the same container.
The last rule is individual color change.

66. The second rule allows for collecting color change from sets within the same container.
The last rule is individual color change.

67. a
The second rule allows for collecting color change from sets within the same container.
The last rule is individual color change.

68. a b
The second rule allows for collecting color change from sets within the same container.
The last rule is individual color change.

69. a b
a+b
The second rule allows for collecting color change from sets within the same container.
The last rule is individual color change.

70. 1$,2h
2$,1h
The second rule allows for collecting color change from sets within the same container.
The last rule is individual color change.

71. a,b
c,d
a+c,max(c,d)
The second rule allows for collecting color change from sets within the same container.
The last rule is individual color change.

72. < A , + , x , 0 , 1 >
< Domain , choose , combine , worst , best >
< Nat∞ , min , , ∞ , 0 >
< [0,1] , min , max , , 1 >
< Bool , or , and , false , true >

73. < A , + , x , 0 , 1 >
< Domain , choose , combine , worst , best >
< Nat∞ , min , , ∞ , 0 >
< [0,1] , min , max , , 1 >
< Bool , or , and , false , true >

74. <A,+,x,0,1> X <B,+,x,0,1>=
< AxB, (+,+), (x,x), (0,0), (1,1) >

75. a d b c a c e

76. a b
a x b
The second rule allows for collecting color change from sets within the same container.
The last rule is individual color change.

77. IMPLEMENTATION
NOTES

78. Object Configuration Module
Nested Object Configuration Module
Rewrite rules
STATE SPACE

79. MOMENT2 http://www.cs.le.ac.uk/people/aboronat/tools/moment2-gt/
FRONT-END
INTERFACE
At the we have no front-end or tool integration, only proof-of-concepts implemented directly in Maude.
Once we our approach will be validated (with more case studies and thorough performance evaluations) a natural candidate for tool integration would be MOMENT2.
BACK-END
MAUDE

80. MOMENT2 http://www.cs.le.ac.uk/people/aboronat/tools/moment2-gt/
FRONT-END
INTERFACE
At the we have no front-end or tool integration, only proof-of-concepts implemented directly in Maude.
Once we our approach will be validated (with more case studies and thorough performance evaluations) a natural candidate for tool integration would be MOMENT2.
BACK-END
proof of
concept
MAUDE

81. MOMENT2 http://www.cs.le.ac.uk/people/aboronat/tools/moment2-gt/
FRONT-END
???
INTERFACE
At the we have no front-end or tool integration, only proof-of-concepts implemented directly in Maude.
Once we our approach will be validated (with more case studies and thorough performance evaluations) a natural candidate for tool integration would be MOMENT2.
BACK-END
proof of
concept
MAUDE

83. UML
UML
RDBS

84. SPO
UML
UML
RDBS
Apart from the examples of this talk and the paper we have some preliminary experiment regarding a classical model transformation: from UML to RDBS.
Performance results look promising.
SOS

85. CONCLUSION

86. FLAT
HIERARCHICAL
We promote passing from an implict representation of containment-like relations with flat graphs to an explict onw with hierarchical graphs.
We promote passing from reduction rules (à la SPO) to conditional ones (à la SOS).
Main consequence: proofs are trees, matching localised.
For planning with multi-criteria we propose semirings.
Our propose is of minimal harm for us: flat and hierarchical representations are “homomorphic” (one can have both and use the most convenient at each step), and everything can be implemente within the same back-end tool: Maude.
For GTTs not so easy. Only supported by HGTTs (examples?)

87. FLAT HIERARCHICAL SPO/REDUCTION CRL/SOS
We promote passing from an implict representation of containment-like relations with flat graphs to an explict onw with hierarchical graphs.
We promote passing from reduction rules (à la SPO) to conditional ones (à la SOS).
Main consequence: proofs are trees, matching localised.
For planning with multi-criteria we propose semirings.
Our propose is of minimal harm for us: flat and hierarchical representations are “homomorphic” (one can have both and use the most convenient at each step), and everything can be implemente within the same back-end tool: Maude.
For GTTs not so easy. Only supported by HGTTs (examples?)

88. FLAT HIERARCHICAL SPO/REDUCTION CRL/SOS QUALITATIVE QUANTITATIVE
We promote passing from an implict representation of containment-like relations with flat graphs to an explict onw with hierarchical graphs.
We promote passing from reduction rules (à la SPO) to conditional ones (à la SOS).
Main consequence: proofs are trees, matching localised.
For planning with multi-criteria we propose semirings.
Our propose is of minimal harm for us: flat and hierarchical representations are “homomorphic” (one can have both and use the most convenient at each step), and everything can be implemente within the same back-end tool: Maude.
For GTTs not so easy. Only supported by HGTTs (examples?)

89. FLAT HIERARCHICAL SPO/REDUCTION CRL/SOS QUALITATIVE QUANTITATIVE
Composition-free
Composition-driven
We promote passing from an implict representation of containment-like relations with flat graphs to an explict onw with hierarchical graphs.
We promote passing from reduction rules (à la SPO) to conditional ones (à la SOS).
Main consequence: proofs are trees, matching localised.
For planning with multi-criteria we propose semirings.
Our propose is of minimal harm for us: flat and hierarchical representations are “homomorphic” (one can have both and use the most convenient at each step), and everything can be implemente within the same back-end tool: Maude.
For GTTs not so easy. Only supported by HGTTs (examples?)

90. FLAT HIERARCHICAL SPO/REDUCTION CRL/SOS QUALITATIVE QUANTITATIVE
Composition-free
Composition-driven
Sequences
Trees
We promote passing from an implict representation of containment-like relations with flat graphs to an explict onw with hierarchical graphs.
We promote passing from reduction rules (à la SPO) to conditional ones (à la SOS).
Main consequence: proofs are trees, matching localised.
For planning with multi-criteria we propose semirings.
Our propose is of minimal harm for us: flat and hierarchical representations are “homomorphic” (one can have both and use the most convenient at each step), and everything can be implemente within the same back-end tool: Maude.
For GTTs not so easy. Only supported by HGTTs (examples?)

91. FLAT HIERARCHICAL SPO/REDUCTION CRL/SOS QUALITATIVE QUANTITATIVE
Composition-free
Composition-driven
Sequences
Trees
We promote passing from an implict representation of containment-like relations with flat graphs to an explict onw with hierarchical graphs.
We promote passing from reduction rules (à la SPO) to conditional ones (à la SOS).
Main consequence: proofs are trees, matching localised.
For planning with multi-criteria we propose semirings.
Our propose is of minimal harm for us: flat and hierarchical representations are “homomorphic” (one can have both and use the most convenient at each step), and everything can be implemente within the same back-end tool: Maude.
For GTTs not so easy. Only supported by HGTTs (examples?)
Any choice
Quantitative choice

92. FLAT HIERARCHICAL SPO/REDUCTION CRL/SOS QUALITATIVE QUANTITATIVE
Composition-free
Composition-driven
Sequences
Trees
We promote passing from an implict representation of containment-like relations with flat graphs to an explict onw with hierarchical graphs.
We promote passing from reduction rules (à la SPO) to conditional ones (à la SOS).
Main consequence: proofs are trees, matching localised.
For planning with multi-criteria we propose semirings.
Our propose is of minimal harm for us: flat and hierarchical representations are “homomorphic” (one can have both and use the most convenient at each step), and everything can be implemente within the same back-end tool: Maude.
For GTTs not so easy. Only supported by HGTTs (examples?)
Any choice
Quantitative choice
RL/Maude
...RL/Maude!

93. THANKS!

94.
linkedin.com/in/albertolluch