The Roman Model for Automated Synthesis in Practice: the SM4All Experience

Transcription

1 The Roman Model for Automated Synthesis in Practice: the SM4All Experience An implementation of the game structure based automated syntesis of services applied to a real scenario Mario Caruso 1 Claudio Di Ciccio 1 Vincenzo Forte 1 Ettore Iacomussi 1 Massimo Mecella 1 1 SAPIENZA Università di Roma Dipartimento di Ingegneria informatica automatica e gestionale ANTONIO RUBERTI cdc@dis.uniroma1.it Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 1 / 65

2 Outline 1 Introduction Service composition SM4ALL 2 Framework The Roman Model for automated composition 3 Service, data and composition model Service model Service Behaviour Language Data model Service and data model Composition model Composition Behaviour Language 4 Realization Extended Roman Model vs service/data model Implementation Software component implementation 5 Experiments Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 2 / 65

3 Outline 1 Introduction 2 Framework 3 Service, data and composition model 4 Realization 5 Experiments Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 3 / 65

4 Service composition The automated service composition Services are software artifacts, that 1 export a description of themselves, 2 are accessible to external clients and 3 communicate through a common interface. Service Oriented Computing (SOC) is a computing paradigm whose basic elements are services, used as building blocks to devise other services. Automated service composition is the problem of automatically combining a set of available services, so to synthesize a more complex service, according to a desired specification. Here we describe a framework for automated service composition, based on: 1 the Roman Model ([BCDG + 03]) for representing services conversational behaviors; 2 the reduction of the composition problem to a safety game for the implementation of the synthesis process ([Pat09]). Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 4 / 65

5 Service composition The automated service composition Services are software artifacts, that 1 export a description of themselves, 2 are accessible to external clients and 3 communicate through a common interface. Service Oriented Computing (SOC) is a computing paradigm whose basic elements are services, used as building blocks to devise other services. Automated service composition is the problem of automatically combining a set of available services, so to synthesize a more complex service, according to a desired specification. Here we describe a framework for automated service composition, based on: 1 the Roman Model ([BCDG + 03]) for representing services conversational behaviors; 2 the reduction of the composition problem to a safety game for the implementation of the synthesis process ([Pat09]). Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 4 / 65

6 Service composition The automated service composition Services are software artifacts, that 1 export a description of themselves, 2 are accessible to external clients and 3 communicate through a common interface. Service Oriented Computing (SOC) is a computing paradigm whose basic elements are services, used as building blocks to devise other services. Automated service composition is the problem of automatically combining a set of available services, so to synthesize a more complex service, according to a desired specification. Here we describe a framework for automated service composition, based on: 1 the Roman Model ([BCDG + 03]) for representing services conversational behaviors; 2 the reduction of the composition problem to a safety game for the implementation of the synthesis process ([Pat09]). Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 4 / 65

7 Service composition The automated service composition Services are software artifacts, that 1 export a description of themselves, 2 are accessible to external clients and 3 communicate through a common interface. Service Oriented Computing (SOC) is a computing paradigm whose basic elements are services, used as building blocks to devise other services. Automated service composition is the problem of automatically combining a set of available services, so to synthesize a more complex service, according to a desired specification. Here we describe a framework for automated service composition, based on: 1 the Roman Model ([BCDG + 03]) for representing services conversational behaviors; 2 the reduction of the composition problem to a safety game for the implementation of the synthesis process ([Pat09]). Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 4 / 65

8 Service composition The automated service composition Services are software artifacts, that 1 export a description of themselves, 2 are accessible to external clients and 3 communicate through a common interface. Service Oriented Computing (SOC) is a computing paradigm whose basic elements are services, used as building blocks to devise other services. Automated service composition is the problem of automatically combining a set of available services, so to synthesize a more complex service, according to a desired specification. Here we describe a framework for automated service composition, based on: 1 the Roman Model ([BCDG + 03]) for representing services conversational behaviors; 2 the reduction of the composition problem to a safety game for the implementation of the synthesis process ([Pat09]). Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 4 / 65

9 SM4ALL The SM4ALL project SM4ALL (Smart homes for All) is a European-funded project, started on September 1st, 2008 and finishing on August 31st, SM4ALL aims at studying and developing an innovative platform for software smart embedded services in immersive environments, based on a service-oriented approach and automated composition techniques. The service-oriented paradigm is used to abstract under a single representation the heterogeneous devices in use, thus overcoming the different standards, communication protocols, data represenation formats. The automated composition techniques are used to make the home system able to perform complex tasks through the orchestration of smart devices, each typically limited in computational resources. The framework presented here has been developed as part of the contribution to this project, from SAPIENZA Università di Roma. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 5 / 65

10 SM4ALL The SM4ALL system architecture Figure: The SM4ALL system architecture Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 6 / 65

11 SM4ALL The contribution of this work to SM4ALL Figure: Off-line Synthesis Engine (OffSEn) in the SM4ALL system architecture Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 7 / 65

12 SM4ALL Off-line Synthesis Engine (OffSEn) The OffSEn is named off-line since it is required to synthesize new virtual services, given the available ones, at system deployment time. OffSEn virtual services (routines) are supposed to be stored, once computed, and be launched in the future by users. OffSEn reasoning core is based the composition techniques described in [Pat09]. The work presented here is not tailored to the SM4ALL case: it can be used as a stand-alone application for testing service compositions. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 8 / 65

13 SM4ALL Off-line Synthesis Engine (OffSEn) The OffSEn is named off-line since it is required to synthesize new virtual services, given the available ones, at system deployment time. OffSEn virtual services (routines) are supposed to be stored, once computed, and be launched in the future by users. OffSEn reasoning core is based the composition techniques described in [Pat09]. The work presented here is not tailored to the SM4ALL case: it can be used as a stand-alone application for testing service compositions. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 8 / 65

14 Outline 1 Introduction 2 Framework 3 Service, data and composition model 4 Realization 5 Experiments Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 9 / 65

15 The Roman Model for automated composition The Roman Model A service is intended as a stateful software artifact characterized by its conversational behavior, i.e., the collection of its potential evolutions resulting from the interaction with some external systems, such as a client service. The so called Roman Model focuses on the conversational behavior of services, represented as Finite State Automata (FSAs) whose transitions are labeled by service s operations, under the assumption that each legal run of the system corresponds to a conversation supported by the service. It is the basis from which we started our research work (see [CGL + 08, BCDG + 03, Pat09]). Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 10 / 65

16 The Roman Model for automated composition Representation of deterministic services Definition A deterministic service (behavior) is represented by a finite deterministic transition system S = O,S,s 0,δ,S f, where: start s 0 o 0 O is the finite alphabet of operations; s 1 S is the finite set of states; s 0 is the initial state; o 2 o 1 δ : S O S is the transition function; S f S is the set of final states. s 2 Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 11 / 65

17 The Roman Model for automated composition Representation of non-deterministic services Definition A non-deterministic service (behavior) is represented by a finite non-deterministic transition system S = O,S,s 0,δ,S f, where: O is the finite alphabet of operations; S is the finite set of states; s 0 is the initial state; ρ S O S is the transition relation; S f S is the set of final states. start s 0 o 2 o 0 o 0 s 1 s 2 o 3 s 3 o 4 Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 12 / 65

18 The Roman Model for automated composition Representation of data Definition Let O be the operation alphabet of a service community C. A data box for C is a tuple DB = O,D,d 0,ρ where: O is the finite set of shared operations, i.e., the whole set of operations services can perform, each of which may or may not affect data box state; D is the finite set of data box states; d 0 D is the initial state; ρ D O D is the transition relation among states. o 0 start d 0 d 1 o 1 Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 13 / 65

19 The Roman Model for automated composition Representation of non-deterministic guarded services Definition A non-deterministic guarded service over a data box DB = O,D,d 0,ρ is a tuple S = O,S,s 0,ρ,G,S f where: O is the same set of operations as in O; S is the finite set of service states; s 0 S is the initial state; S s S is the set of final states; G is a set of boolean functions g : D {, } called guards; ρ S G O S is the service transition relation. start s 0 [g 1 ] o 1 o 0 [g 0 ] o 0 s 1 [g 0 ] o 0 start d 0 d 1 o 1 Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 14 / 65

20 The Roman Model for automated composition The community transition system Definition Let C = {S 1,...,S n,db} be a community, where S i = O,S i,s i0,ρ i,g i,s f i (i = 1,...,n) and DB = O,D,d 0,ρ. The nondeterministic guarded community TS of C, implicitly defined over DB, is the tuple S C = O,{1,...,n},S C,s C 0,γ C,G C,S f C, where: O is, as usual, the shared operation alphabet; {1,...,n} is the set of available service indexes; S C = S 1... S n is the (finite) set of S C states; let s C = s 1,...,s n, we denote s i by com i (s C ) (i = 1,...,n); s C 0 S C, where com i (s C 0 ) = s i0 (i = 1,...,n); S f C S C is the set of S C final states, where s C S f C if and only if com i(s C ) S f C for all i = 1,...,n; G = n i=1 G i is the set of S C guards, where guard g ij stands for g j G i (i.e., g ij is the j-th guard of G i ); γ C S C G O {1,...,n} S C is the S C transition relation, where s C,g,o,k,s C γ C, or s C g,o,k s C is in S C, if ando only if: com k (s C ) g,o com k (s C ) in S k; com i (s C ) = com i (s C ), for i = 1,...,n such that i k. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 15 / 65

21 The Roman Model for automated composition The orchestrator at a glance Intuitively, a trace of a nondeterministic available service over a data box represents a possible synchronous evolution of the service and the data box. A nondeterministic service history is any finite prefix of a trace. The orchestrator is a partial function that, given the community TS history and the operation to perform, returns the index of the available service to delegate such operation to (w.r.t. the DB and services behaviours, and the guards). Definition An orchestrator P for C is a composition of the target service S t by the nondeterministic services in C over DB iff it realizes all traces of S t on DB. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 16 / 65

22 The Roman Model for automated composition The composition problem Given a nondeterministic community C = {S 1,...,S n,db} and a deterministic target service S t over DB, synthesize an ochestrator for C that is a composition of S t by S C Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 17 / 65

23 The Roman Model for automated composition The simulation relation Definition Let C = {S 1,...,S n,db} be a nondeterministic community, DB as usual the data box, and S t a deterministic target service over DB. An ND-simulation relation of S t by S C on DB is a relation R S t S C D such that s t,s C,d R implies: 1 if s t S f t then s C S f C ; 2 for each transition s t g,o s t in S t with g(d) =, if there exists a transition d o d in DB then there a exists a k {1,...,n} such that the following holds: 1 there exists a transition s C g,o,k s C in S C with g(d) = ; 2 for all transitions s C g,o,k s C in S C with g(d) = and d o d in DB, s t,s C,d R Theorem Let C = {S 1,...,S n,db} be a (nondeterministic) community and S t a (deterministic) target service over DB. An orchestrator P for C that is a composition of S t by S C on DB exists if and only if (s t0,s C 0,d 0 ). Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 18 / 65

24 The Roman Model for automated composition The composition problem Given a nondeterministic community C = {S 1,...,S n,db} and a deterministic target service S t over DB, synthesize an ochestrator for C that is a composition of S t by S C The largest ND-simulation relation between S t and C can be computed in polynomial time w.r.t. the size of S t and C. Since the number of states in C is exponential in the number of available services n, can be computed in exponential time. Theorem The problem is EXPTIME-hard. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 19 / 65

25 The Roman Model for automated composition The composition problem Given a nondeterministic community C = {S 1,...,S n,db} and a deterministic target service S t over DB, synthesize an ochestrator for C that is a composition of S t by S C The largest ND-simulation relation between S t and C can be computed in polynomial time w.r.t. the size of S t and C. Since the number of states in C is exponential in the number of available services n, can be computed in exponential time. Theorem The problem is EXPTIME-hard. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 19 / 65

26 Outline 1 Introduction 2 Framework 3 Service, data and composition model 4 Realization 5 Experiments Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 20 / 65

27 Service model The service model: an introduction The service model reference implementation (service model for short) is based on a set of XML Schemata defining the behaviour of services and orchestrator generators. 1 The SBL (Service Behaviour Language) describes both services and targets. 2 The UIC (User Interface Configuration) defines the User Interface specifications for services and targets (icons, labels and so forth). Such standards are all located on the web: We will enter into the SBL details only. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 21 / 65

28 Service model The service model: an introduction The service model reference implementation (service model for short) is based on a set of XML Schemata defining the behaviour of services and orchestrator generators. 1 The SBL (Service Behaviour Language) describes both services and targets. 2 The UIC (User Interface Configuration) defines the User Interface specifications for services and targets (icons, labels and so forth). Such standards are all located on the web: We will enter into the SBL details only. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 21 / 65

29 Service model The service model: an introduction The service model reference implementation (service model for short) is based on a set of XML Schemata defining the behaviour of services and orchestrator generators. 1 The SBL (Service Behaviour Language) describes both services and targets. 2 The UIC (User Interface Configuration) defines the User Interface specifications for services and targets (icons, labels and so forth). Such standards are all located on the web: We will enter into the SBL details only. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 21 / 65

30 Service model Service Behaviour Language: a simple example The header of an SBL document <?xml version="1.0" encoding="utf-8"?> <service name="name of the service" description="description of the service" xmlns=" stid="uri-like identifier" class="service-type"> <ts><!-- The transition system description goes here --></ts> </service> Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 22 / 65

31 Service model Service Behaviour Language: a simple example <?xml version="1.0" encoding="utf-8"?> <service name="sampleone" description="sample One Service Model" xmlns=" stid=" class="service-type"> <ts> <state name="a" type="initial"> <transition action="foop"> <target state="b" /> </transition> </state> <state name="b" type="transient"> <transition action="goop"> <target state="c" /> </transition> </state> <state name="c" type="final"> <transition action="loop"> <target state="a" /> </transition> </state> </ts> </service> start A loop foop B C goop Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 23 / 65

32 Service model Service Behaviour Language: a simple example <?xml version="1.0" encoding="utf-8"?> <service name="sampleone" description="sample One Service Model" xmlns=" stid=" class="service-type"> <ts> <state name="a" type="initial"> <transition action="foop"> <target state="b" /> </transition> </state> <state name="b" type="transient"> <transition action="goop"> <target state="c" /> </transition> </state> <state name="c" type="final"> <transition action="loop"> <target state="a" /> </transition> </state> </ts> </service> start A loop foop B C goop Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 24 / 65

33 Service model Service Behaviour Language: a simple example <?xml version="1.0" encoding="utf-8"?> <service name="sampleone" description="sample One Service Model" xmlns=" stid=" class="service-type"> <ts> <state name="a" type="initial"> <transition action="foop"> <target state="b" /> </transition> </state> <state name="b" type="transient"> <transition action="goop"> <target state="c" /> </transition> </state> <state name="c" type="final"> <transition action="loop"> <target state="a" /> </transition> </state> </ts> </service> start A loop foop B C goop Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 25 / 65

34 Service model Service Behaviour Language: a devilish non-deterministic example <?xml version="1.0" encoding="utf-8"?> <service name="sampleone" description="sample One Service Model" xmlns=" stid=" class="service-type"> <ts> <state name="a" type="initial"> <transition action="foop"> <target state="b" /> <target state="c" /> </transition> </state> <state name="b" type="transient"> <transition action="goop"> <target state="a" /> </transition> </state> <state name="c" type="transient"> <transition action="hoop"> <target state="d" /> </transition> </state> <state name="d" type="final"> <transition action="loop"> <target state="d" /> </transition> </state> </ts> </service> start goop B foop A foop C hoop D loop Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 26 / 65

35 Service model Service Behaviour Language: interacting with the home environment Figure: Services, devices and the home environment Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 27 / 65

36 Service model Service Behaviour Language: the pre-conditions language Pre-conditions grammar (Backus-Naur form) 1 <SYNTAX> ::= <EXPR> 2 <EXPR> ::= ( <EXPR> ) <AND> <OR> <NOT> <CMP> 3 <AND> ::= <EXPR> and <EXPR> 4 <OR> ::= <EXPR> or <EXPR> 5 <NOT> ::=! <EXPR> 6 <CMP> ::= <GT> <LT> <EQU> <GTE> <LTE> 7 <GT> ::= gt( <VAR>, <VAL> ) 8 <LT> ::= lt( <VAR>, <VAL> ) 9 <GTE> ::= gte( <VAR>, <VAL> ) 10 <LTE> ::= lte( <VAR>, <VAL> ) 11 <EQU> ::= equ( <VAR>, <VAL> ) 12 <VAR> ::= variable_name 13 <VAL> ::= " variable_value " A pre-condition string example!( equ(favouritedishtonight,"roastchicken") and equ(chicken,"0") or equ(favouritedishtonight,"pastasalmon") and (equ(pasta,"0") or equ(salmon,"0")) ) Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 28 / 65

37 Service model Service Behaviour Language: the pre-conditions language Pre-conditions grammar (Backus-Naur form) 1 <SYNTAX> ::= <EXPR> 2 <EXPR> ::= ( <EXPR> ) <AND> <OR> <NOT> <CMP> 3 <AND> ::= <EXPR> and <EXPR> 4 <OR> ::= <EXPR> or <EXPR> 5 <NOT> ::=! <EXPR> 6 <CMP> ::= <GT> <LT> <EQU> <GTE> <LTE> 7 <GT> ::= gt( <VAR>, <VAL> ) 8 <LT> ::= lt( <VAR>, <VAL> ) 9 <GTE> ::= gte( <VAR>, <VAL> ) 10 <LTE> ::= lte( <VAR>, <VAL> ) 11 <EQU> ::= equ( <VAR>, <VAL> ) 12 <VAR> ::= variable_name 13 <VAL> ::= " variable_value " A pre-condition string example!( equ(favouritedishtonight,"roastchicken") and equ(chicken,"0") or equ(favouritedishtonight,"pastasalmon") and (equ(pasta,"0") or equ(salmon,"0")) ) Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 28 / 65

38 Service model Service Behaviour Language: the post-conditions language Specification of post-conditions in the SBL <postcondition variable="variable name"> <increase quantity="integer value to add" /> <decrease quantity="integer value to subtract" /> <assign-from variable="variable to transfer the value from" /> <set-value value="value to set" /> </postcondition> A sample post-conditions specification (code snippet) <transition action="buyingredients"> <! > <postcondition variable="pasta"> <set-value value="1"/> </postcondition> <postcondition variable="salmon"> <set-value value="1"/> </postcondition> </transition> Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 29 / 65

39 Data model The data model: an introduction Definition The data model is an extendible conceptual framework for the definition of environmental variable types. The data model reference implementation (service model for short) is based on a set of XML descriptors, defining the values that environmental variables can assume. Each service developer can define her own types, provided that: 1 they are identified by a unique name; 2 they are either: 1 boolean, or 2 an ordered finite collection of values. Data model types concern variables appearing in pre-conditions and post-conditions. The main idea of (small) enumerations is to reduce the variables value space so to decrease the computational effort for the reasoner. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 30 / 65

40 Data model The data model: an introduction Definition The data model is an extendible conceptual framework for the definition of environmental variable types. The data model reference implementation (service model for short) is based on a set of XML descriptors, defining the values that environmental variables can assume. Each service developer can define her own types, provided that: 1 they are identified by a unique name; 2 they are either: 1 boolean, or 2 an ordered finite collection of values. Data model types concern variables appearing in pre-conditions and post-conditions. The main idea of (small) enumerations is to reduce the variables value space so to decrease the computational effort for the reasoner. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 30 / 65

41 Data model The data model: an introduction Definition The data model is an extendible conceptual framework for the definition of environmental variable types. The data model reference implementation (service model for short) is based on a set of XML descriptors, defining the values that environmental variables can assume. Each service developer can define her own types, provided that: 1 they are identified by a unique name; 2 they are either: 1 boolean, or 2 an ordered finite collection of values. Data model types concern variables appearing in pre-conditions and post-conditions. The main idea of (small) enumerations is to reduce the variables value space so to decrease the computational effort for the reasoner. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 30 / 65

42 Data model The data model: an introduction Definition The data model is an extendible conceptual framework for the definition of environmental variable types. The data model reference implementation (service model for short) is based on a set of XML descriptors, defining the values that environmental variables can assume. Each service developer can define her own types, provided that: 1 they are identified by a unique name; 2 they are either: 1 boolean, or 2 an ordered finite collection of values. Data model types concern variables appearing in pre-conditions and post-conditions. The main idea of (small) enumerations is to reduce the variables value space so to decrease the computational effort for the reasoner. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 30 / 65

43 Data model The data model: an example Variables belong to the defined types. Non-boolean types are defined in VML (Variable Modeling Language) files. All variables are listed in VDD (Variable Declaration Descriptor) files. An example of an enumeration-based data type (VML) <variable-model... name="airtemperature"> <value value="cold" id="0"/> <value value="cool" id="1"/> <value value="temperate" id="2"/> <value value="warm" id="3"/> <value value="hot" id="4"/> </variable-model> An example of a declaration of variables (VDD) <home...> <variable name="kitchen_airtemp" type="custom" model="air_temperature.vml.xml" /> <variable name="livingroom_airtemp" type="custom" model="air_temperature.vml.xml" /> </home> Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 31 / 65

44 Service and data model Service and data model: a complete example I <service... name="bathtub" description="bathtub service" class="service-type"> <! > <ts> <state name="empty" type="initial-final"> <transition action="dofillupbathtub"> <target state="filled" /> <precondition><![cdata[equ(waterhot,"1")]]></precondition> <postcondition variable="bathfilled"><set-value value="1"/></postcondition> </transition> </state> <state name="filled" type="initial-final"> start empty <transition action="dofillupbathtub"> <target state="filled" /> doemptybathtub /bathfilled = <precondition><![cdata[equ(bathfilled,"0")]]></precondition> <postcondition variable="bathfilled"><set-value value="1"/></postcondition> </transition> <transition action="doemptybathtub"> <target state="empty" /> <postcondition variable="bathfilled"><set-value value="0"/></postcondition> </transition> </state> </ts> </service> [waterhot = ] dofillupbathtub /bathfilled = filled [bathfilled = ] dofillupbathtub /bathfilled = Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 32 / 65

45 Service and data model Service and data model: a complete example II <service... name="waterheatingsystem" description="water Heating System Service Model" class="service-type"> <! > <ts> <state name="idle" type="initial-final"> <transition action="doswitchoff"> <target state="idle" /> cooling </transition> <transition action="doheatwater"> <target state="warming" /> docoolwater /waterhot = <postcondition variable="waterhot"><set-value value="1"/></postcondition> </transition> <transition action="docoolwater"> <target state="cooling" /> doswitchoff <postcondition variable="waterhot"><set-value value="0"/></postcondition> </transition> </state> <state name="cooling" type="transient"> <transition action="doswitchoff"> <target state="idle" /> </transition> <transition action="doheatwater"> <target state="warming" /> start idle docoolwater /waterhot = <postcondition variable="waterhot"><set-value value="1"/></postcondition> </transition> </state> doswitchoff <state name="warming" type="transient"> <transition action="doswitchoff"> <target state="idle" /> doheatwater /waterhot = </transition> <transition action="docoolwater"> <target state="cooling" /> <postcondition variable="waterhot"><set-value value="0"/></postcondition> </transition> </state> </ts> </service> doheatwater /waterhot = Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 33 / 65 warming

46 Service and data model Service and data model: a complete example III <service... name="preparebathroom" description="set up the bathroom for taking a bath" class="target"> <ts> <state name="st0" type="initial-final"> <transition action="doheatwater"> <target state="st1" /> </transition> </state> <state name="st1" type="transient"> <transition action="dofillupbathtub"> <target state="st2" /> </transition> </state> <state name="st2" type="transient"> <transition action="doemptybathtub"> <target state="st3" /> </transition> </state> <state name="st3" type="transient"> <transition action="doswitchoff"> <target state="st0" /> </transition> </state> </ts> </service> start doheatwater dofillupbathtub doemptybathtub st 0 st 1 st 2 st 3 doswitchoff Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 34 / 65

47 Composition model Composition model: an introduction The composition model is a compact representation for orchestrations. The language for describing them is named CBL (Composition Behaviour Language) Like the SBL format, it is XML-based. Its BPEL-like syntax is expressly designed to make it processable by service orchestrators (as in SM4ALL actually happens). The header of a CBL document <?xml version="1.0" encoding="utf-8"?> <composition xmlns=" xmlns:xsi=" xsi:schemalocation=" name="name of the composition"> <!-- The composition description goes here --> </composition> Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 35 / 65

48 Composition model Composition model: an introduction The composition model is a compact representation for orchestrations. The language for describing them is named CBL (Composition Behaviour Language) Like the SBL format, it is XML-based. Its BPEL-like syntax is expressly designed to make it processable by service orchestrators (as in SM4ALL actually happens). The header of a CBL document <?xml version="1.0" encoding="utf-8"?> <composition xmlns=" xmlns:xsi=" xsi:schemalocation=" name="name of the composition"> <!-- The composition description goes here --> </composition> Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 35 / 65

49 Composition model Composition Behaviour Language For each target service state (conversational-target-state), according to (community-state) 1 the service community state (service-conversational-state) and 2 the variables current value (variable-value), it describes (transition) 1 which service instance to call (invoke attribute) for the next action (action attribute) to be executed; 2 which is the next target state (invoke); 3 (optionally) the effects of the action (postcondition). A sample of a CBL document content (code snippet) <composition...> <conversational-target-state name="st1" type="transient"> <conversational-orchestration-state> <community-state> <service-conversational-state service="bathtub" state="empty"/> <service-conversational-state service="waterheater" state="heating"/> <variable-value name="waterheater_waterhot" value="1"/> <variable-value name="bathtub_bathfilled" value="0"/> </community-state> <transition action="dofillupbathtub" invoke="bathtub"> <target state="st2"/> <postcondition variable="bathtub_bathfilled"><set-value value="true"/></postcondition> </transition> </conversational-orchestration-state> <! > </conversational-target-state> <! > </composition> Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 36 / 65

50 Outline 1 Introduction 2 Framework 3 Service, data and composition model 4 Realization 5 Experiments Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 37 / 65

51 Extended Roman Model vs service/data model On the reduction of FSAs to the SBL Terms used are quite the same with some slight modifications, reported here below. service service instance, belonging to a service type operation action databox set of environmental variables (a.k.a. variables ) guard pre-condition on the action, w.r.t. the current service state (a.k.a. pre-condition, with a little abuse of definition) The services translation is straightforward from the finite state automaton expression to the SBL format. s 0 S <state name="si" type="initial"> s i S <state name="si" type="transient"> s f i Sf <state name="sfi" type="final"> s o s <state name="s"...><transition action="o"><target state="s " /></transition></state> s o s s o s <state name="s"><transition action="o"><target state="s "/><target state="s "/> </transition></state> s [g]o s <state name="s"><transition action="o"><target state="s " /><precondition>g</precondition> </transition></state> Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 38 / 65

52 Extended Roman Model vs service/data model On the reduction of FSAs to the SBL Terms used are quite the same with some slight modifications, reported here below. service service instance, belonging to a service type operation action databox set of environmental variables (a.k.a. variables ) guard pre-condition on the action, w.r.t. the current service state (a.k.a. pre-condition, with a little abuse of definition) The services translation is straightforward from the finite state automaton expression to the SBL format. s 0 S <state name="si" type="initial"> s i S <state name="si" type="transient"> s f i Sf <state name="sfi" type="final"> s o s <state name="s"...><transition action="o"><target state="s " /></transition></state> s o s s o s <state name="s"><transition action="o"><target state="s "/><target state="s "/> </transition></state> s [g]o s <state name="s"><transition action="o"><target state="s " /><precondition>g</precondition> </transition></state> Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 38 / 65

53 Extended Roman Model vs service/data model Databox and SBL The databox evolution is implicitly stated in post-conditions (effects over the action, w.r.t. the current state, with a little abuse of definition). On the next translation rule Here we consider a databox whose state set is D = {d,d }. s o/d d s <state name="s"...><transition action="o"><target state="s " /> <postcondition variable="d"><set-value value="d "> </postcondition></transition></state> Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 39 / 65

54 Extended Roman Model vs service/data model Databox and SBL The databox evolution is implicitly stated in post-conditions (effects over the action, w.r.t. the current state, with a little abuse of definition). On the next translation rule Here we consider a databox whose state set is D = {d,d }. s o/d d s <state name="s"...><transition action="o"><target state="s " /> <postcondition variable="d"><set-value value="d "> </postcondition></transition></state> Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 39 / 65

55 Extended Roman Model vs service/data model Databox, data model and SBL The databox evolution is implicitly stated in post-conditions (effects over the action, w.r.t. the current state, with a little abuse of definition). On the next translation rule We considered operations on the data box depending on the current state (i.e., the current variable value) on integer values. Thanks to the enumeration facet, increase and decrease operations can express transitions on symbolic values as well. s o/d d s <state name="s"...><transition action="o"><target state="s " /> <postcondition variable="d"><increase quantity="1"> </postcondition></transition></state> A slider-like representation of DB Figure: A temperature type variable Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 40 / 65

56 Extended Roman Model vs service/data model Databox, data model and SBL The databox evolution is implicitly stated in post-conditions (effects over the action, w.r.t. the current state, with a little abuse of definition). On the next translation rule We considered operations on the data box depending on the current state (i.e., the current variable value) on integer values. Thanks to the enumeration facet, increase and decrease operations can express transitions on symbolic values as well. s o/d d s <state name="s"...><transition action="o"><target state="s " /> <postcondition variable="d"><increase quantity="1"> </postcondition></transition></state> A slider-like representation of DB Figure: A temperature type variable Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 40 / 65

57 Extended Roman Model vs service/data model Databox, data model and SBL The databox evolution is implicitly stated in post-conditions (effects over the action, w.r.t. the current state, with a little abuse of definition). On the next translation rule We considered operations on the data box depending on the current state (i.e., the current variable value) on integer values. Thanks to the enumeration facet, increase and decrease operations can express transitions on symbolic values as well. s o/d d s <state name="s"...><transition action="o"><target state="s " /> <postcondition variable="d"><increase quantity="1"> </postcondition></transition></state> A slider-like representation of DB Figure: A temperature type variable Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 40 / 65

58 Extended Roman Model vs service/data model A conceptual model Composition +compositionid: String +description: String +xmlmodel: CBL 0..n TargetService +targetid: String +name: String +description: String 0..n +xmlmodel: SBL n Orchestration <<type>> ServiceType +stid: String +xmlmodel: SBL 0..n 1..n 0..n Action +name: String 1 +orchestrationid: long <<instantiate>> <<type>> VariableType <<invoke>> +vtid: String +xmlmodel: Schema XSD <<instantiate>> <<instance>> Service +siid: String +name: String +description: String <<use>> <<instance>> Variable +viid: String <<use>> Figure: A conceptual model of services, variables and compositions Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 41 / 65

59 Extended Roman Model vs service/data model New databox definition The concept of databox DB = O,D,d 0,ρ changes in the SM4ALL context. Due to the fact that: 1 compositions are stored and required to be started at any further point in time, 2 the environmental variables evolution is not under the direct control of services (i.e., they can change their value even though no action has been performed), and 3 we can rely on the full observability of both databox and services states, the environmental data are described by the Databox, where: 1 each state is a tuple in the asynchronous product of the variables value ranges ((2.) and (3.)) W = {V 0,V 1,...,V n } is the set of variable value sets, each V i being a variable values set for the variable v i ; D = V 0 V 1...V n 2 the databox transition system constitute a complete graph ((2.) and (3.)); we can ignore the O labels in the DB definition: post-conditions will constrain the evolution of the v i values; 3 each state is a potential initial state ((1.) and (2.)) Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 42 / 65

60 Extended Roman Model vs service/data model New databox definition The concept of databox DB = O,D,d 0,ρ changes in the SM4ALL context. Due to the fact that: 1 compositions are stored and required to be started at any further point in time, 2 the environmental variables evolution is not under the direct control of services (i.e., they can change their value even though no action has been performed), and 3 we can rely on the full observability of both databox and services states, the environmental data are described by the Databox, where: 1 each state is a tuple in the asynchronous product of the variables value ranges ((2.) and (3.)) W = {V 0,V 1,...,V n } is the set of variable value sets, each V i being a variable values set for the variable v i ; D = V 0 V 1...V n 2 the databox transition system constitute a complete graph ((2.) and (3.)); we can ignore the O labels in the DB definition: post-conditions will constrain the evolution of the v i values; 3 each state is a potential initial state ((1.) and (2.)) Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 42 / 65

61 Extended Roman Model vs service/data model New databox definition The concept of databox DB = O,D,d 0,ρ changes in the SM4ALL context. Due to the fact that: 1 compositions are stored and required to be started at any further point in time, 2 the environmental variables evolution is not under the direct control of services (i.e., they can change their value even though no action has been performed), and 3 we can rely on the full observability of both databox and services states, the environmental data are described by the Databox, where: 1 each state is a tuple in the asynchronous product of the variables value ranges ((2.) and (3.)) W = {V 0,V 1,...,V n } is the set of variable value sets, each V i being a variable values set for the variable v i ; D = V 0 V 1...V n 2 the databox transition system constitute a complete graph ((2.) and (3.)); we can ignore the O labels in the DB definition: post-conditions will constrain the evolution of the v i values; 3 each state is a potential initial state ((1.) and (2.)) Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 42 / 65

62 Extended Roman Model vs service/data model New databox definition The concept of databox DB = O,D,d 0,ρ changes in the SM4ALL context. Due to the fact that: 1 compositions are stored and required to be started at any further point in time, 2 the environmental variables evolution is not under the direct control of services (i.e., they can change their value even though no action has been performed), and 3 we can rely on the full observability of both databox and services states, the environmental data are described by the Databox, where: 1 each state is a tuple in the asynchronous product of the variables value ranges ((2.) and (3.)) W = {V 0,V 1,...,V n } is the set of variable value sets, each V i being a variable values set for the variable v i ; D = V 0 V 1...V n 2 the databox transition system constitute a complete graph ((2.) and (3.)); we can ignore the O labels in the DB definition: post-conditions will constrain the evolution of the v i values; 3 each state is a potential initial state ((1.) and (2.)) Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 42 / 65

63 Extended Roman Model vs service/data model New databox definition The concept of databox DB = O,D,d 0,ρ changes in the SM4ALL context. Due to the fact that: 1 compositions are stored and required to be started at any further point in time, 2 the environmental variables evolution is not under the direct control of services (i.e., they can change their value even though no action has been performed), and 3 we can rely on the full observability of both databox and services states, the environmental data are described by the Databox, where: 1 each state is a tuple in the asynchronous product of the variables value ranges ((2.) and (3.)) W = {V 0,V 1,...,V n } is the set of variable value sets, each V i being a variable values set for the variable v i ; D = V 0 V 1...V n 2 the databox transition system constitute a complete graph ((2.) and (3.)); we can ignore the O labels in the DB definition: post-conditions will constrain the evolution of the v i values; 3 each state is a potential initial state ((1.) and (2.)) Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 42 / 65

64 Extended Roman Model vs service/data model New databox definition The concept of databox DB = O,D,d 0,ρ changes in the SM4ALL context. Due to the fact that: 1 compositions are stored and required to be started at any further point in time, 2 the environmental variables evolution is not under the direct control of services (i.e., they can change their value even though no action has been performed), and 3 we can rely on the full observability of both databox and services states, the environmental data are described by the Databox, where: 1 each state is a tuple in the asynchronous product of the variables value ranges ((2.) and (3.)) W = {V 0,V 1,...,V n } is the set of variable value sets, each V i being a variable values set for the variable v i ; D = V 0 V 1...V n 2 the databox transition system constitute a complete graph ((2.) and (3.)); we can ignore the O labels in the DB definition: post-conditions will constrain the evolution of the v i values; 3 each state is a potential initial state ((1.) and (2.)) Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 42 / 65

65 Extended Roman Model vs service/data model Considerations about the new databox definition The Databox turns into a storage for possible values that v i can assume: DB =, D = V 0 V 1...V n, D 0 D, ρ = D D The rationale is to have an extendible database of values affected by service actions. Through this modification, we detached the Databox from the services: variables exist per se, their evolution is free unless service actions interact with the environment. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 43 / 65

66 Extended Roman Model vs service/data model TLV input/output management Figure: The overall synthesis process, step by step Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 44 / 65

67 Extended Roman Model vs service/data model TLV input encoding The solution approach is based on reducing the problem to the synthesis of Linear-time Temporal Logic (LTL) formulae (see [PPS06]) by Model Checking over Game Structures: the composition problem is reduced to the search for a winning strategy in a safety game (see [Pat09]). The implementation makes use of the TLV (Temporal Logic Verifier, see [PS96, Sha04]) system, a SMV-based reasoner (see [KTB00]). On the name of players in the safety game Beware that players in the safety game are named system and environment. Pay attention not to confuse the environment player with the home environment defined by variables. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 45 / 65

68 Extended Roman Model vs service/data model TLV input encoding: an overview I Main module MODULE main VAR env: system Env(sys.index); sys: system Sys; DEFINE good := (sys.initial & env.initial) -- intial state is "good" by definition!(env.failure); -- services are always required not to fail In the next slide: System, Environment and Services Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 46 / 65

69 Extended Roman Model vs service/data model TLV input encoding: an overview II MODULE Sys VAR index : 0..3; -- num of services, 0 used for init INIT index = 0 TRANS case index=0 : next(index)!=0; index!=0 : next(index)!=0; esac DEFINE initial := (index=0); MODULE Env(index) -- Represents the evolution of available services, seen as a whole VAR operation : doemptybathtub,no_op,doheatwater,doswitchoffheater,dofillupbathtub,start_op,docoolwater; db : Databox; target : Target(operation,db); -- "produces" operations s3 : Service3(index,operation,db); -- "consumes" current index and operation s2 : Service2(index,operation,db); -- "consumes" current index and operation s1 : Service1(index,operation,db); -- "consumes" current index and operation DEFINE initial := ( s3.initial & s2.initial & s1.initial & target.initial & operation=start_op); failure := ( s3.failure s2.failure s1.failure (target.final &!( s3.final & s2.final & s1.final ))); -- Databox see the next slides -- Target service see the next slides -- Available service #n see the next slides Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 47 / 65

70 Extended Roman Model vs service/data model TLV input encoding: the databox MODULE Databox VAR v0 : 0..1; -- variable bathtub_bathfilled v1 : 0..1; -- variable waterheater_waterhot INIT TRUE & v0 in 0..1 & v1 in 0..1 Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 48 / 65

71 Extended Roman Model vs service/data model TLV input encoding: a service in the community -- Available service # bathtub MODULE Service1(index,operation,db) VAR state:start_st,empty,filled; INIT state = start_st TRANS case state=start_st & operation=start_op & index=0: next(state) in empty; (index!= 1) : next(state) = state; -- if not selected remain still (state=empty & operation = dofillupbathtub) : next(db.v0) = 1 & next(db.v1) = db.v1 & next(state) in filled ; (state=empty & operation = doemptybathtub) : next(db.v0) = 0 & next(db.v1) = db.v1 & next(state) in empty ; (state=filled & operation = dofillupbathtub) : next(db.v0) = 1 & next(db.v1) = db.v1 & next(state) in filled ; (state=filled & operation = doemptybathtub) : next(db.v0) = 0 & next(db.v1) = db.v1 & next(state) in empty ; esac DEFINE initial := state=start_st & operation=start_op & index = 0; failure := index = 1 &!( (state = empty & ( (operation = dofillupbathtub & db.v1 = 1 ) (operation = doemptybathtub ))) (state = filled & ( (operation = dofillupbathtub & db.v0 = 0 ) (operation = doemptybathtub )))); final := state in empty,filled; -- end of available service # Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 49 / 65

72 Extended Roman Model vs service/data model TLV input encoding: the post-conditions generation algorithm SMV encoding of the post-conditions 1: procedure GENERATEPOSTCONDITIONS(StringList transition) 2: P := set of postconditions for the transition 3: I := set of all variable identifiers 4: output := 5: for all formula P do 6: output := output. &.formula 7: end for 8: for all identifier I do 9: if identifier / P then 10: output := output. & next(identifier) = identifier hold value 11: end if 12: end for 13: end procedure Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 50 / 65

73 Extended Roman Model vs service/data model TLV input encoding: the target MODULE Target(op,db) VAR state:start_st,st0,st1,st2,st3; INIT state = start_st & op = start_op TRANS case state=start_st & op=start_op : next(state) in st0 & ( next(state) = st0 -> next(op) in doheatwater ); state = st0 & op = doheatwater : next(state) in st1 & ( next(state) = st1 -> next(op) in dofillupbathtub ); state = st1 & op = dofillupbathtub : next(state) in st2 & ( next(state) = st2 -> next(op) in doswitchoffheater ); state = st2 & op = doswitchoffheater : next(state) in st3 & ( next(state) = st3 -> next(op) in no_op ); state = st3 & op = no_op : next(state) in st3 & ( next(state) = st3 -> next(op) in no_op ); esac DEFINE initial := state=start_st & op=start_op; final := state in st3; On the optimization of the input for reducing computation time Only services offering at least one of the actions required from the target are retrieved to compose a local community in the composition process. Only variables involved by pre- and post-conditions of actions offered by the local community are taken into account to build the local databox in the community. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 51 / 65

74 Extended Roman Model vs service/data model TLV raw output: the orchestrator generator I The output file structure consists essentially of four parts: 1 an header that contains informations about the tool version and the libraries loaded; 2 a section containing information about realizability of the specification; 3 a section containing the description of the states for the synthesized automaton; 4 a section that specifies the transitions map of the automaton. Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 52 / 65

75 Extended Roman Model vs service/data model TLV raw output: the orchestrator generator II Output header TLV version System #1: System #2: System #3: Resources used: user time: 0 s BDD nodes allocated: 1712 max amount of BDD nodes allocated: 1712 Bytes allocated: Loading Util.tlv $Revision: 4.3 $ Loading MCTL.tlv $Revision: 4.11 $ Loading MCTLS.tlv $Revision: 4.1 $... Loaded rules file Rules.tlv.... Information about realizability... Check Realizability Specification is realizable Check that a symbolic strategy is correct Transition relation is complete All winning states satisfy invariant... Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 53 / 65

76 Extended Roman Model vs service/data model TLV raw output: the orchestrator generator III Synthesized Automaton States... State 1 env.operation = start_op, env.db.v0 = 1, env.db.v1 = 1, env.target.state = start_st, env.s3.state = start_st, env.s2.state = start_st, env.s1.state = start_st, sys.index = 0, State 2 env.operation = doheatwater, env.db.v0 = 0, env.db.v1 = 0, env.target.state = st0, env.s3.state = idle,env.s2.state = unique, env.s1.state = empty, sys.index = 3, State 3 env.operation = doheatwater, env.db.v0 = 0, env.db.v1 = 1, env.target.state = st0, env.s3.state = idle,env.s2.state = unique, env.s1.state = empty, sys.index = 3, State 4 env.operation = doheatwater, env.db.v0 = 1, env.db.v1 = 0, env.target.state = st0, env.s3.state = idle,env.s2.state = unique, env.s1.state = empty, sys.index = 3, State 5 env.operation = doheatwater, env.db.v0 = 1, env.db.v1 = 1, env.target.state = st0, env.s3.state = idle,env.s2.state = unique, env.s1.state = empty, sys.index = 3,... Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 54 / 65

77 Extended Roman Model vs service/data model TLV raw output: the orchestrator generator IV Synthesized Automaton Transitions (Winning Strategy)... Automaton Transitions From 1 to From 2 to 9 From 3 to 9 From 4 to 6 From 5 to 6 From 6 to 7 From 7 to 8 From 8 to 8 From 9 to 7 From 10 to From 11 to From 12 to Automaton has 12 states, and 24 transitions Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 55 / 65

78 Extended Roman Model vs service/data model TLV output decoding: the composition <composition... name="preparebathroom"> <conversational-target-state name="st0" type="initial"><! > </conversational-target-state> <conversational-target-state name="st1" type="transient"> <conversational-orchestration-state> <community-state> <service-conversational-state service="bathtub" state="empty"/> <service-conversational-state service="waterheater" state="heating"/> <variable-value name="waterheater_waterhot" value="true"/> <variable-value name="bathtub_bathfilled" value="false"/> </community-state> <transition action="dofillupbathtub" invoke="bathtub"> <target state="st2"/> <postcondition variable="bathtub_bathfilled"> <set-value value="true"/> </postcondition> </transition> </conversational-orchestration-state> <conversational-orchestration-state> <community-state> <service-conversational-state service="bathtub" state="empty"/> <service-conversational-state service="waterheater" state="heating"/> <variable-value name="waterheater_waterhot" value="true"/> <variable-value name="bathtub_bathfilled" value="true"/> </community-state> <transition action="dofillupbathtub" invoke="bathtub"> <target state="st2"/> <postcondition variable="bathtub_bathfilled"> <set-value value="true"/> </postcondition> </transition> </conversational-orchestration-state> </conversational-target-state> <! > </composition> Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 56 / 65

79 Software component implementation Off-line Synthesis Engine internal components Figure: The Off-line Synthesis Engine internal components at work Caruso, Di Ciccio, Forte, Iacomussi, Mecella (SAPIENZA) The Roman Model in SM4All 57 / 65