In this section, we first provide an overview on the adaptation mechanisms and strategies exploited by our approach [22], in Section 5.1. In Section 5.2, we give a description of the enablers of the design for adaptation. For illustration purpose, we provided a running scenario of the travel assistant example in Section 5.3. The execution model is formalized in Section 5.4.
5.1 Adaptation mechanisms and strategies
The adaptation mechanisms and strategies that we employ implement the dynamic adaptation of fragment-based and context-aware business processes proposed in [22], which are in turn based on AI planning [23]. The link between the approach presented in this article and the approaches in [22] is the use of the APFL to model processes. It allows developers to define flexible processes that are particularly suitable for adaptation and execution in dynamic environments.
The used adaptation mechanisms deal with three types of adaptation needs. The first, which is the one we mainly use in our scenario, refers to the need for refining an abstract activity. This is made by triggering the refinement mechanism whose execution allows the approach to automatically find and compose available fragments in the application, on the basis of the goal of the abstract activity and the current context. As a result, an executable process whose execution guarantees to reach the abstract activity’s goal is provided (details are given in Section 5.3).
The second is called local adaptation mechanism and it refers to the violation of the precondition of an activity that has to be performed. It requires for a solution helping in re-starting a faulted process. For instance, booking a place in a ride-share is constrained by a precondition requiring that the user is subscribed to the specific ride-sharing service.
The last is called compensation mechanism and it allows designers to avoid the explicit definition of activities’ compensation procedures, and to dynamically provide a context-aware compensation process (i.e., when a travel ticket refund is needed).
Furthermore, the AI planning on which the goal-based adaptation relies is able to deal with stateful and non-deterministic services. In addition, the fragments composition (i.e., a plan) returned by the AI planner as a result to an adaptation problem is correct by construction [23], that is, if a plan is found, it is guaranteed that its execution allows the application to reach a situation in which the goal of the adaptation problem is satisfied. However, dealing with stateful services implies that the planner might even not find a solution to an adaptation problem. For these reasons, adaptation strategies have been designed. Indeed, the mechanisms introduced above can be further combined into adaptation strategies allowing the application to handle more complex adaptation needs (e.g., the failure of an abstract activity refinement). The before-mentioned mechanisms and strategies have all been implemented in an adaptation engine [24]. This engine is one of the enablers of our design for adaptation approach.
5.2 Enablers of the design for adaptation approach
The run-time operation of service-based applications realized with our approach relies on different execution and adaptation enablers, shown in Fig. 7.
The Execution Enablers, namely the Domain Objects Manager and the Process Engine, leverage on the different services wrapped up as domain objects and stored in the application’s knowledge base. The execution enablers are in charge of executing the domain objects processes (i.e., core processes and fragments) during the operation of service-based applications. The Adaptation Enablers, namely the Refinement Handler, the Adaptation Manager and the AI planner, instead, leverage on the adaptation mechanisms and strategies, described in Section 5.1. They are in charge of managing the adaptation needs of applications, arising at run-time. Consided as a whole, they represent the adaptation engine.
To start, it is required that developers select the available services in a given domain (e.g., mobility) and wrap-up them as domain objects. These are stored in the Domain Objects Models repository in Fig. 7. To understand how the execution and adaptation enablers interact, we defined a sequence diagram in Fig. 8.
Domain objects core processes (simply processes from here on) are executed by the Process Engine. It manages service requests among processes and, when needed, it sends requests for domain objects instantiation to the Domain Objects Manager. A request is sent for each demanded service whose corresponding process has not yet been instantiated. The domain objects manager replies by deploying the requested process on the process engine. In this way, a correlation between the two processes is defined.
During the normal execution of processes, abstract activities can be met. These activities need to be refined with one or a composition of fragments modeling services functionalities. To this aim, the process engine sends a request for abstract activity refinement to the Refinement Handler component. This component is in charge of defining the adaptation problem corresponding to the received request. In particular, the adaptation problem is represented by: (i) a set of fragments that can potentially be part of the final fragments composition. The selection is driven by the goal defined by the abstract activity. (ii) A set of domain properties, and (iii) the adaptation goal. The planning domain is then derived from the adaptation problem by transforming fragments and domain properties into STS, by applying transformation rules, such as those presented in [25]. The adaptation goal is, instead, transformed into a set of configuration of the planning domain. Then, the refinement handler submits the adaptation problem to the Adaptation Manager. This translates the adaptation problem into a planning problem so that it can be solved by the AI Planner component. After the plan generation (i.e., made as a STS), the AI planner sends the plan to the adaptation manager that will transform it into an executable process. This process can now be sent to the process engine and injected into the abstract activity being refined. At this point, depending on the fragments in the composition, the process engine can request for the instantiation of one or more domain objects, whose processes will be deployed. At the end, the execution of the refinement process can be performed.
5.3 Travel assistant: running scenario
In this section, we show a concrete example on the running execution of the travel assistant. The focus of this section is that of showing (i) how domain objects dynamically inter-operate by exchanging and injecting (composition of) fragments, thus enabling a chain of incremental refinements (such as that in Fig. 9); (ii) how the refinement process allows domain objects to span their external knowledge on the domain, by establishing new soft dependency.
The main features of the travel assistant are the following: (i) collect the user’s requirements (e.g., source and destination points, travel preferences, etc) and set up a journey planning request; (ii) run a local or a global planning; (iii) identify the transport means in the journey’s legs of the solution selected by the user. This way, it goes vertically to find the proper service(s) to use (e.g., the ones of the specific transport companies), if existing in the application.
Executing the travel assistant. Our user, Sara, wants to organize a journey from Trento to Vienna. In Fig. 9, we report examples of chains of incremental refinements, as they are dynamically set up and executed after the specific request of SaraFootnote 4.
The travel assistant is provided as a mobile application (modeled by the domain object Travel Assistant Application in Fig. 3), through which Sara uses it. The execution starts from the core process of this mobile app, modeling the user process. Then, a sequence of three abstract activities (represented with dotted lines and labeled with a goal) need to be refined (see the top side of Fig. 9). Here we focus on the first one, Plan Journey, whose goal models the situation in which Sara ends up with a specific travel plan. The refinement mechanism is triggered and the following steps are performed (see Fig. 9).
Step 1. The fragment PlanJourney provided by the Travel Assistant is selected for the refinement, and injected in the behavior of the mobile app core process. It implements a wider journey planning functionality, allowing for looking for available alternatives and performing a more detailed planning after that a specific alternative has been found and selected by the user. To start, it allows Sara to insert the departure and destination locations.
Step 2. To identify the proper planning mode (local vs. global), the travel assistant domain object relies on the Planners Management domain property, as shown by the abstract activity Travel Assistant Plan Journey in the PlanJourney fragment in execution. The Journey Planners Manager domain object implements the Planners Management domain property. Its fragment SelectPlanningMode is selected for the refinement. This fragment does not implement any logic. Indeed, its activities Plan Request and Receive Planning Type model the communication with its core process, where the request is effectively handled. In particular, the Journey Planners Manager knows only at runtime if a local or global planning is required. In our scenario, having Trento and Vienna, the Journey Planners Manager will reply with a global planning type. This will drive the execution of its fragment through the Plan Global Journey abstract activity.
Step 3. At this point, one or more fragments provided by the available global journey planners existing as domain objects in the application’s knowledge base can be selected for the refinement. In our scenario, we suppose that the Plan Global Journey abstract activity is refined with the fragment Plan provided by the Rome2RioFootnote 5 domain object, a open global planner service. The execution of this fragment will end up with a list of travel alternatives, if any.
Step 4. After that the chain of incremental refinements made by the steps 1, 2 and 3 has been accomplished, the execution returns to the PlanJourney fragment, by continuing with the DataViewerPattern abstract activity. Indeed, an appropriate data visualization pattern must be selected, based on the data format (e.g., a list, a message). This is defined at run-time, when the data (and its format) is known. The Data Viewer domain object provides the DefineDataViewer Pattern fragment for this purpose. At this point, Sara can receive and visualize on her smartphone the list of the found travel alternatives satisfying her requirements.
Step 5. Sara can now select her preferred alternative (we suppose that she selects a multi-modal solution made by a train and a bus travels). Based on the user choice, the Define Journey Legs abstract activity is refined with the HandleJourneyLegs fragment provided by the Journey Manager domain object. It is able to dynamically define the goal for the Refine Journey abstract activity, that will be G: TJ = Response Sent AND BJ = Response Sent, being the selected solutions made by a train and a bus journeys. The refinement of this abstract activity will allow the Travel Assistant to look for and find the proper fragments for each journey leg. Notice that the Refine Journey activity is a so-called higher order abstract activity, that we are going to define in the subsequent paragraph.
Step 6. The last step shows a composition of fragments provided by the transport companies involved in the legs of the journey alternative selected by the user (i.e., Sudtirol Alto Adige and Hello). Their execution provides to Sara the proper solutions, from the two companies, that combined together satisfy her need of planning a journey from Trento to Vienna, passing through Bozen.
Higher Order Abstract Activities. In step 5 of the running example, we have presented the Refine Journey activity as a Higher Order Abstract Activity (HOAA). This kind of activity is actually a regular abstract activity and it is managed as such, with the only difference that its goal is defined at execution time, within the fragment or core process it belongs to. For instance, in Fig. 9 – Step 5, we can notice that the Receive Goal for Legs Specialization activity, is in charge of receiving the HOAA’s goal and labeling the Refine Journey HOAA with it, so that, at the next step, the process engine can execute it.
HOAAs are used for those abstract activities whose goal’s specification is fully depending from the run-time execution environment. Specifying such a goal (i.e., a composition requirements) at design time, would mean defining all the possible alternatives that the goal could assume. But this is exactly what must be avoided. For this reason, we introduced the HOAA construct allowing for the dynamic definition of goals when the execution domain is known.
Example 8
The HandleJourneyLegs fragment exploited at Step 5 in the running example is exposed by the Journey Manager domain object. Its main task is that of relating a specific travel alternative selected by a user with the proper domain objects able to handle it. It is easy to notice that a travel solution can be made from any possible combination of transport means. This implies that the goal of the Refine Journey HOAA, if defined at design time, should model any possible configuration to cover all the corresponding combination of transport means. To the contrary, the Journey Manager implements the logic to dynamically relate a combination of transport means (e.g., train and bus as in our example) with the right goal to be associated with the HOAA handling it (e.g., the goal G: TJ = Response Sent AND BJ = Response Sent in Fig. 9), which is dynamically generated.
5.3.1 Dynamic knowledge extension
An important feature of our approach is represented by the ability of domain objects to span their knowledge on the whole application domain.
The dynamic extension of the knowledge concerns with the external domain knowledge and it is triggered by the execution of the abstract activity refinement mechanism. In particular, it takes place every time that a domain object injects in its own core process one or more fragments containing abstract activities. Indeed, since abstract activities are labeled with a goal, the receiving domain object receives, together with the fragments, also those domain properties on which fragments execution rely on. These domain properties will extend the external domain knowledge.
For instance, in Fig. 10 we depicted the evolution of the external domain knowledge in the Travel Assistant Application domain object, after the execution of step 1 and step 2 of Fig. 9. Both steps, indeed, are characterized by the injection of fragments, namely PlanJourney and SelectPlanningMode, equipped with abstract activities, whose goals (i.e., G4, G7, G8 – see table in Fig. 9) rely on domain properties which are automatically inherited by the Travel Assistant Application domain object. More specifically, the Planning Management, Local Planning and Global Planning properties are received.
This dinamicity is now reflected in the soft dependencies of the Travel Assistant Application because new dependencies are established. In particular, it will establish new dependencies with all the domain objects in the application implementing the three just inherited domain properties.
We can notice how the dynamic knowledge extension allows domain objects to dynamically discover new services that they can, in turn, exploit for the refinement of inherited abstract activities. It is easy to note that the refinement at the step 3 in Fig. 9 would not have been possible without the dynamic extension of the knowledge because, in its design time version, the Travel Assistant Application did not have the Global Planning knowledge required to do it. Lastly, we want to highlight that if new global planners enter the application, the Travel Assistant Application will be able to know and exploit them in its further execution, thanks to the establishment of new soft dependencies.
5.4 Execution model formalization
The following definition captures the current status of the execution of a given core process. The process instance is a hierarchical structure, obtained through the refinement of abstract activities into fragments. A process instance is hence modeled as a list of tuples process-activity: the first element in the list describes the fragment currently under execution and the current activity; the other tuples describe the hierarchy of ancestor fragments, each one with abstract activities currently under execution. The last element in the list is the process model from which the running instance has been created. A process instance is defined as follows:
Definition 9
(Process Instance) We define a process instance Ip of a process p as a non-empty list of tuples Ip=(p1,a1),(p2,a2),…,(pn,an), where:
each pi is a process and pn=p;
ai∈A(pi) are activities in the corresponding processes, with ai∈Aabs(pi) for i≥2 (i.e., all activities that are refined are abstract).
An example of process instance is given by the process of the Travel Assistant Application domain object, shown in Fig. 9, where we reported an example of its execution. A domain object instance, instead, is specified as follows.
Definition 10
(Domain Object Instance) A domain object instance δ of a domain object \(o=\langle {{\mathbb {D}\mathbb {K}}_{I}, {\mathbb {D}\mathbb {K}}_{E},p,\mathbb {F}}\rangle \) is a tuple \(\delta = \langle {{\mathbb {D}\mathbb {K}}_{I}, {\mathbb {D}\mathbb {K}}_{E^{+}},\bar {l}_{I},\bar {l}_{E^{+}},I_{p}}\rangle \) where:
\({\mathbb {D}\mathbb {K}}_{E^{+}}\supseteq {\mathbb {D}\mathbb {K}}_{E}\), is the current set of domain properties in the external domain knowledge;
\(\bar {l}_{I} \in \mathbb {L}_{DK_{I}}\) and \(\bar {l}_{E^{+}} \in \mathbb {L}_{DK_{E^{+}}}\) are the current state of the domain properties in the internal and external domain knowledge;
Ip is its process instance.
Notice that \({\mathbb {D}\mathbb {K}}_{E^{+}} = {\mathbb {D}\mathbb {K}}_{E}\) when the domain object is instantiated. Then, \({\mathbb {D}\mathbb {K}}_{E^{+}} \) might grow during the domain object execution; this mechanism is formally defined later on.
We define now an adaptive system instance.
Definition 11
(Adaptive System Instance) An adaptive system instance ASI of an adaptive system \(AS=\{o_{1}, \dots, o_{n}\}\) is a set of domain object instances ASI={δij} where each δij is an instance of domain object oi.
For instance, if we consider the running scenario depicted in Fig. 9 of the travel assistant system, we can say that the adaptive system instance, for that specific execution, is made by instances of the Travel Assistant Application, Travel Assistant, Journey Planners Manager, Journey Manager, Data Viewer, Rome2Rio, Train and Bus domain objects.
We will now formally define the execution model of domain objects. In the following a refinement need is formalized.
Definition 12
(Refinement need) A refinement need is a tuple η=〈ASI,δ,a〉 where:
ASI is an adaptive system instance;
δ∈ASI is the domain object instance for which the refinement is needed;
a is the abstract activity of δ to be refined.
For instance, considering the process whose refinement is shown in Fig. 9, the domain object instance for which the refinement is needed is an instance of the Travel Assistant Application, while the abstract activity to be refined is the Plan Journey activity.
A refinement is defined as follows.
Definition 13
(Refinement) A refinement for a refinement need η=〈ASI,δ,a〉, denoted with REF(η), is a tuple \(\langle {p_{\eta },{\mathbb {D}\mathbb {K}}_{\eta },\bar {l}_{\eta }}\rangle \) where:
pη is the process to be injected;
\({\mathbb {D}\mathbb {K}}_{\eta }\) is the set of domain properties to be added to the external domain knowledge;
for each a∈Aabs(pη), \(Goal(a) \subseteq {2^{{\mathbb {L}}_{DK_{\eta }}}}\);
\(\bar {l}_{\eta } \in {\mathbb {L}}_{DK_{\eta }}\) is the current state of the domain properties.
The last two items of the previous definition require that, in case the refinement process contains abstract activities, the domain knowledge needed for their refinement is part of the refinement solution. Indeed, this is how the domain knowledge extension is performed.
We will now characterize a correct solution for a refinement need η. Intuitively, a refinement \(\langle {p,{\mathbb {D}\mathbb {K}},\bar {l}}\rangle \) is a correct solution to a refinement need η=〈ASI,δ,a〉, if the execution of p brings the external domain knowledge of object δ in a state that satisfies the goal of a. Notice that p, being a composition of fragments provided by other domain objects, might contain abstract activities that will be refined later on, when the refinement is executed. Our definition of correct refinement is based on the assumption that abstract activities, once refined, will behave as declared in their specification (preconditions and effects on their activities). That is, we treat them as all other activities in the process, assuming that their behavior is correctly specified through their annotations in terms of preconditions and effects.
In the following we give the definitions of action executability, action impact, and abstract run of a process. These definitions are the basis for the formal characterization of a correct refinement.
Definition 14
(Action Executability) An action a of a process p is executable from domain knowledge state \(\bar {l}\in \mathbb {L}_{DK}\), denoted with \({Executable}(a,\bar {l})\), if \(\bar {l}\models {Pre}(a)\) and the effects of action a are applicable in domain knowledge state \(\bar {l}\).
In other words, an action is executable from a given domain knowledge state if, in that state, its precondition is verified and its effects can be applied.
Definition 15
(Action Impact) The impact of action a belonging to some process p when executed from domain knowledge state \(\bar {l}\in {\mathbb {L}}_{DK}\), denoted with \({Impact}(a,\bar {l})\), is a domain configuration \(\bar {l^{\prime }}\in {\mathbb {L}}_{DK}\) such that for every \({dp}_{i} = \langle {{L}_{i}, {{l}^{0}}_{i}, {E}_{i}, {T}_{i}}\rangle \in {\mathbb {D}\mathbb {K}}\), if exists an e∈Eff(a) such that \(\left (\bar {l}{\downarrow }_{dp_{i}},e,l'_{i}\right)\in {T}_{i}\) then \({\bar {l}^{\prime }}{\downarrow }_{dp_{i}}=l'_{i}\), otherwise \({\bar {l}^{\prime }}{\downarrow }_{dp_{i}}=\bar {l}{\downarrow }_{dp_{i}}\).
The action impact is given by the domain configuration in which the domain knowledge of the domain object that is executing the activity evolves.
Definition 16
(Abstract Process Run) Given a process p=〈S,S0,A,T,Ann〉 and a domain knowledge state \(\bar {l}\in \mathbb {L}_{DK}\), π=(s1,a1,s2,…,an−1,sn) is an abstract run of p from \(\bar {l}\) if:
s1∈S0 and ∀i,∈[1,n]:si∈S;
∀i∈[1,n−1]:ai∈A and (si,ai,si+1)∈T;
there exists a domain knowledge evolution of \({\mathbb {D}\mathbb {K}}\), \({\pi }_{DK} = (\bar {l}_{1},\bar {l}_{2},\ldots,\bar {l}_{n})\) such that:
\(\bar {l_{1}} = \bar {l}\);
\({Impact}(a_{i},\bar {l}_{i})=\bar {l}_{i+1}\) for all i∈[1,n−1];
\({Executable}(a_{i},\bar {l}_{i})\) for all i∈[1,n−1].
A process run that terminates in a state with no outgoing transitions (final state) is called a complete run. We denote with \({\Pi _{ABS}}(p,\bar {l})\) the set of all possible complete abstract runs of process p from domain knowledge state \(\bar {l}\in \mathbb {L}_{DK}\).
We can now define a correct refinement.
Definition 17
(Correct Refinement) Given a refinement need η=〈ASI,δ,a〉, with \(\delta =\langle {{\mathbb {D}\mathbb {K}}_{I}, {\mathbb {D}\mathbb {K}}_{E^{+}},\bar {l}_{I},\\ \bar {l}_{E^{+}},I_{p}}\rangle \), we say that a refinement \(\langle {p_{\eta },{\mathbb {D}\mathbb {K}}_{\eta },\bar {l}_{\eta }}\rangle \) is a correct solution for η, if for each complete abstract run \(\pi \in {\Pi _{ABS}}(p_{\eta },\bar {l}_{E^{+}})\), its associated domain knowledge evolution \({\pi }_{DK} = (\bar {l}_{1},\bar {l}_{2},\ldots,\bar {l}_{n})\) is such that \(\bar {l}_{n}\models Goal(a)\).
Intuitively, a refinement is a correct solution for a refinement need if all its complete abstract runs satisfy the goal of the abstract activity to be refined.
As regards the execution of an adaptive system instance, intuitively, it evolves in three different ways. First, through the execution of activities in domain object instances, which will be presented in detail in the following. Second, through the interaction among domain object instances, which happens according to the standard rules of peer-to-peer process communication. Third, through a change in the behavior, or entrance / exit, of domain objects and domain object instances into the system.
In the following we formalize the execution model of a domain object, considering also the injection of a refinement solution in the case in which an abstract activity is executed.
Definition 18
(Action Execution) Given a domain object instance \(\delta = \langle {{\mathbb {D}\mathbb {K}}_{I}, {\mathbb {D}\mathbb {K}}_{E^{+}},\bar {l}_{I},\\ \bar {l}_{E^{+}},I_{p}}\rangle \), with δ∈ASI and Ip=(p1,a1),(p2,a2),…,(pn,an), the execution of action a1, denoted with exec(δ,ASI), evolves δ to \(\langle {{\mathbb {D}\mathbb {K}}_{I}, {\mathbb {D}\mathbb {K}}'_{E^{+}},\bar {l}'_{I},\bar {l}'_{E^{+}},I_{p}}\rangle \), where:
if a1∈Ain(p1)∪Aout(p1)∪Acon(p1) then
\({\mathbb {D}\mathbb {K}}'_{E^{+}} = {\mathbb {D}\mathbb {K}}_{E^{+}}\);
\(\bar {l}'_{I}={Impact}(a,\bar {l}_{I})\) and \(\bar {l}'_{E^{+}}={Impact}(a,\bar {l}_{E^{+}})\);
if next(p1,a1)≠∅ then I′p=(p1,next(p1,a1)),(p2,a2),…,(pn,an), otherwise \(I^{\prime }_{p}=(p_{2}, {next}(p_{2},a_{2})),\ldots, (p_{n}, a_{n})\).
if a1∈Aabs(p1), given \(\langle {p_{\eta }, {\mathbb {D}\mathbb {K}}_{\eta }, \bar {l}_{\eta }}\rangle =REF(\eta)\), with η=〈ASI,δ〉, then
\({\mathbb {D}\mathbb {K}}'_{E^{+}} = {\mathbb {D}\mathbb {K}}_{E^{+}}\cup {\mathbb {D}\mathbb {K}}_{\eta }\);
\(\bar {l}'_{E^{+}}\in {\mathbb {L}}_{DK^{\prime }_{E^{+}}}\) is such that for every \({dp}_{i} = \langle {{L}_{i}, {{l}^{0}}_{i}, {E}_{i}, {T}_{i}}\rangle \in {\mathbb {D}\mathbb {K}}'_{E^{+}}\), if \({dp}_{i}\in {\mathbb {D}\mathbb {K}}_{\eta }\) then \(\bar {l}'_{E^{+}}{\downarrow }_{dp_{i}}=\bar {l}_{\eta }{\downarrow }_{dp_{i}}\), otherwise \(\bar {l}'_{E^{+}}{\downarrow }_{dp_{i}}=\bar {l}_{E^{+}}{\downarrow }_{dp_{i}}\);
\(I^{\prime }_{p}=(p_{\eta },a^{0}_{\eta })(p_{1}, a_{1}), (p_{2},a_{2}),\ldots, (p_{n}, a_{n})\).
Eventually, we previously said as a soft dependency among two domain objects becomes a strong dependency, denoted with δih←δjk, if the domain object δih injects in its internal process a fragment provided by δjk. This is formally defined as follows:
Definition 19
(Strong Dependency) ∀δih,δjk∈ASI with i≠j and h≠k, δih←δjk if \(\exists (f,a) \in I_{p}(\delta _{ih}) | f \in {\mathbb {F}}(o_{j})\).
In the next section, we show how the refinement problem previously presented can be solved by applying the automated fragment composition approach based on AI planning [22].
5.4.1 Automated refinement via AI planning
Within the approach presented in [23] and summarized in Section 7, we said that a fragment composition problem is transformed into a planning problem. Relevantly to our purposes, such techniques cover uncertainty, in order to allow the composition of services whose dynamics is only partially exposed, and is able to deal with complex goals and data flow [25].
In the following we briefly describe how a refinement need η=〈ASI,δ,a〉, with \(\delta =\langle {{\mathbb {D}\mathbb {K}}_{I}, {\mathbb {D}\mathbb {K}}_{E^{+}},\bar {l}_{I},\bar {l}_{E^{+}},I_{p}}\rangle \) is transformed into an AI planning problem. In other words, we say how the approach in [23] is adjusted and used in our framework.
First of all, a set of n fragments, \((f_{1},\dots,f_{n})\), is selected from the soft dependencies of δ: for some δ′∈ASI, with \(\delta \dashleftarrow \delta '\), \(f_{i}\in {\mathbb {F}}(\delta ')\).
Advanced optimization techniques, as the one described in [26], can be used to further reduce the set of fragments on the basis of the functionalities they provide and of the preconditions satisfiability of their preconditions in current domain knowledge state. Both fragments \((f_{1},\dots,f_{n})\) and the set of domain properties \(({dp}_{1},\dots,{dp}_{m})\in {\mathbb {D}\mathbb {K}}_{E}^{+}\), on which the fragments are annotated, are transformed into state transition systems (STS) using transformation rules similar to those presented in [23]. During this encoding, all goals on abstract activities in fragments are ignored, while preconditions and effects are maintained. With this measure, the refinement plan will be built under the assumption that abstract activities will behave according to their annotation, independently from the way in which they will be refined (see Definition 17).
The planning domain Σ is obtained as the product of the STSs \({\Sigma }_{f_{1}}\) …\({\Sigma }_{f_{n}}\) and \({\Sigma }_{dp_{1}}\) …\({\Sigma }_{dp_{m}}\), where STSs of fragments and domain properties are synchronized on preconditions and effects, \( {\Sigma } = {\Sigma }_{f_{1}}\|\dots \|{\Sigma }_{f_{n}}~\|~{\Sigma }_{dp_{1}}\|\linebreak \dots \|{\Sigma }_{dp_{m}}. \) The initial state of the planning domain is derived from the initial state of all fragments and the current state of the domain properties \(\bar {l}_{E^{+}}\), by interpreting it as states of the STSs defining the planning domain. Similarly, the refinement goal Goal(a) is transformed into a planning goal ρ by interpreting the states in \({\mathbb {D}\mathbb {K}}_{E^{+}}\) as states in the planning domain.
Finally, the approach of [23] is applied to domain Σ and planning goal ρ to generate a plan Ση that guarantees achieving goal ρ once executed on system Σ. State transition system Ση can be further translated into an executable process pη, which implements the identified solution.