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

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

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

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

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.

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.

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.

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

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

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

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

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

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

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

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

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.

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.

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

< 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

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.

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.

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.

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.

Object Collections (flat graphs) Conformant

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

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

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

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

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

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

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.

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.

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

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

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

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.

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.

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

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

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

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

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

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

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

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

WHICH STYLE IS BEST?

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.

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.

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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

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

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

a d b c a c e

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.

IMPLEMENTATION NOTES

Object Configuration Module Nested Object Configuration Module Rewrite rules STATE SPACE

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

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

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

UML UML RDBS

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

CONCLUSION

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

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

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

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

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

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

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!

THANKS!

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