Software systems must adapt their behavior in response to changes in the environment or in the requirements they are supposed to meet. Despite adaptation capabilities could be modeled with great detail at design time, anticipating all possible adaptations is not always feasible. To address this problem the requirements model of the system, which also includes the adaptation capabilities, is conceived as a runtime entity. This way, it is possible to trace requirements/adaptation changes and propagate them onto the application instances. This paper leverages the FLAGS [1] methodology, which provides a goal model to represent adaptations and a runtime infrastructure to manage requirements@runtime. First, this paper explains how the FLAGS infrastructure can support requirements@runtime, by managing the interplay between the requirements and the executing applications. Finally, it describes how this infrastructure can be used to adapt the system, and, consequently, support the evolution of requirements.
Software systems must be able to adapt to continue to achieve their requirements while they are executing. The need for adaptation may be triggered by di erent events: the application reaches a particular execution state, the context changes, established requirements are not satis ed, or the objectives of the system change. Some of these events can be foreseen in advance, and thus the corresponding adaptation capabilities, foreseen adaptations, can be planned and designed carefully, while others cannot and adaptation capabilities, unforeseen adaptations, must be devised completely at runtime. Note that, besides predictability, there is a tradeo between the number of di erent events the system is able to react to (completeness) and the cost of embedding these reactions from the beginning. Furthermore, even if all possible adaptations could be anticipated from the beginning, some of them may become useless when requirements evolve, due to new business objectives or users' needs.
In the last years, di erent modeling notations [
This paper clari es how FLAGS supports requirements@runtime. In
particular, the goal model is conceived as a runtime entity and is fed by the data coming
from the running application instances. The goal model can dynamically change
to accommodate new/changing requirements. We assume that applications are
expressed as BPEL [
The paper is structured as follows. Section 2 describes how the FLAGS model can be used to represent adaptations. Section 3 illustrates the runtime infrastructure to support requirements@runtime. Section 4 describes how the infrastructure activates adaptations at runtime and supports the interplay between the requirements and the running application. Section 5 discusses some related approaches and concludes the paper. 2
This section classi es di erent kinds of adaptation, and demonstrates how they can be elicited through FLAGS. We use an example of a web portal, Click&Eat, which collects information regarding di erent restaurants that deliver food at home and allows customers to order food from one of them. 2.1
Adaptations can be classi ed along several dimensions [
{ E ect. Adaptations may just change the underlying implementation or may also modify the actual requirements of the system. In the rst case, they can be performed automatically and may a ect one or all application instances.
Single Instance. These adaptations are suitable to cope with transient events and can modify the execution ow of a process instance or one of its partner links. Hence, the e ects of these adaptations are temporary and do not have an impact on the process de nition.
All Instances. They restructure the process by changing the de nition of all (executing and future) process instances. Hence, the e ects of these adaptations are permanent.
Despite it can be feasible to apply temporary actions to all process instances or permanent actions on a single instance, we did not nd useful to introduce this further distinction for our purposes.
In case some requirements cannot be satis ed, due to, for example, lack of resources or premature design choices, or to accommodate context changes, adaptation actions modify the requirements model |including the adaptation capabilities| and propagate their e ect on all application instances. { Anticipation. Adaptations can be planned ahead of time or not. Foreseen adaptations are modeled by the designer along with the other conventional requirements of the system. This way the underlying process can adapt autonomously when a speci c scenario takes place (e.g., a goal is violated, a speci c event happens). Unforeseen adaptations are determined by changes in the requirements that may take place after an application is already on the market, due to new users needs, or mutations in the organization, laws and business opportunities. Requirements changes may also be due to the execution of an adaptation that modi es the requirements model. In all these cases, new adaptations must be identi ed, or some of the existing adaptations may no longer be useful or may need to be modi ed. Despite requirements changes cannot be identi ed automatically, the way new requirements impact on the underlying application can be detected semi-automatically through requirements traceability. 2.2
Adaptation goals must be speci ed over the conventional requirements of the system. Figure 1(a) shows a FLAGS model of Click&Eat. The general objective of the system is to manage the customers' requests (goal G1). Customers want to browse available restaurants to view o ered food items and their cost (goal G1.1). To this aim they must search a set of potential restaurants (goal G1.1.1) and select one among them (goal G1.1.2). The search can be performed by name (operation SearchByName) or by kind of provided food (operation SearchByType). All customers must register (goal G1.2) to be able to make an order (goal Show
del(Show)
Perform (op1, op2, G1.1.1) op1: Get Restaurant op2: Add Restaurant
AG1 [Signal new restaurant] del(AG1)
G1.1.1 [Search restaurant]
G1.1 [Choose restaurant]
AND
AG2 p[MeramkeanAeGn1t] del(G1.1.1) RegisterOp
SearchBy SearchBy Select LoginOp
Type Name fix(AG1)
AG3 [Increase customer satisfaction] tense(G1.1.1)
Select Food CalcTotal Insert
Address G1.3). This application also aims to collect the customers' feedbacks regarding a selected restaurants (goal G1.4). Finally the average satisfaction of all customers must be high (goal G1.5). xSearch by type xSearch by name xG1.1.1 [Search restaurants] G1.1.1a [Search open restaurants] (b) Search open Search open
by type by name G1.2 [Register]
G1 [Manage Requests] AND G1.3 [Make order]
G1.4 [Vote restaurant] Send feedback
Notify Confirm
G1.5 [High cust. satisfaction] Legend goal adaptation goal operation event G1.1.2 [Select restaurant]
(a)
Adaptation goals de ne the adaptation capabilities embedded in the system at requirements level. The operationalization of these goals de nes the actions to be carried out when adaptation is required. Each adaptation goal is associated with a trigger and a set of conditions. The trigger states when the adaptation goal must be activated. Conditions specify further necessary constraints that must be satis ed to allow the corresponding goal to be executed. Conditions may refer to properties of the system (e.g., satisfaction levels of goals, or adaptation goals already performed) or domain assumptions.
Adaptation goals can embed process-level actions that simply change the way goals are achieved (process activities, partner services), or goal-level actions that modify the goal model. Process level adaptations have conditions that do not depend on the satisfaction of goals, but are just expressed through untimed formulas over runtime data. Furthermore, they can be performed any number of times, while goal level adaptations must be performed at most once. Processlevel actions are: perform([o1,: : :, on], g /o), may optionally execute a sequence of operations (o1, : : :, on) and resumes the execution before operation o or goal g is executed; substitute(a1, a2 [, o]), substitutes agent a1 with a2 for all operations performed by a1 (in case the third parameter is not speci ed) or only when a1 executes operation o (otherwise); x(ag), includes the e ects of an adaptation goal (ag) in the process de nition4. Goal level actions are: add /remove(g), adds or removes (conventional/adaptation) goal g; add(o, g), adds operation o to goal g; remove(o), removes operation o; add /remove(e/ev /a), adds or remove an entity (e), or an event (ev), or an agent (a); relax(g, constr), modi es the de nition 4 Action f ix(ag) can be applied in case ag temporarily modi es the process execution ow, without changing the process de nition or the goal model. of a leaf goal (g) making it less strict (e.g., by adding a new disjunct constraint or relaxing the corresponding membership function); tense(g, constr), modi es the de nition of a leaf goal (g) by making it stricter (e.g., by adding a new conjunct constraint or tensing the corresponding membership function). Adaptation goals are associated with other elements of the goal model (dependencies). In case at least one element in the dependencies is removed or modi ed, the adaptation goal must be consequently removed. This way adaptations can be automatically adjusted to comply with the modi cations of the goal model.
To handle those cases in which a desired restaurant cannot be found, a temporary adaptation goal (AG1) is de ned. It aids goal G1.1.1, is triggered when event Show takes place (i.e., after operation SearchByName), under the condition that attribute list of event Show does not contain any restaurant. As actions, AG1 performs operations Get Restaurant and Add Restaurant, which respectively retrieve the information of a restaurant from a user and add it to the list of available restaurants. This adaptation depends on event Show : in case this event is removed from the the model, AG1 must be consequently removed. In case AG1 is triggered too many times, a permanent adaptation goal (AG2) is applied. It performs action x(AG1), which removes AG1 and adds the actions performed by AG1 to the process de nition. It is triggered when AG1 is performed and under the condition that AG1 has been triggered more than 10 times. When some goals (G1.5) are not satis ed enough, due to wrong design choices, the requirements of the system should change. For example, adaptation goal AG3 may be applied to tense goal G1.1.1 by adding a conjuntive constraint. This new constraint asserts that only those restaurants with a feedback greater than 40% must be shown to the customer.
The customers may change their requirements while the system is executing. For example, they may want to visualize only those restaurants that are open at the moment when the search is performed. To address these changes it is necessary to modify the goal model manually, by substituting goal G1.1.1 with G1.1.1a, as shown in Figure 1(b). Consequently, new unforeseen adaptations must be automatically applied at the applications level to propagate these modi cations to all instances. 3
As shown in Figure 2, FLAGS provides a conceptual infrastructure to enact requirements at runtime. Its components operate respectively at the process and the goal level, whereas the Process Reasoner handles the interplay between them. To support requirements evolution the infrastructure manages two models at runtime: the FLAGS model and the implementation model. The former includes the requirements and the adaptation capabilities performed at the goal level, while the latter includes the de nition of the process together with the data collection, monitoring and adaptation capabilities necessary to support the adaptations at the process level. These models are managed respectively by the components at the goal and process level.
Process Reasoner
mappinggss (prmoccaeespsspsi-n-ggooaalsls)) mappings ((pprroocess - goals)
AAnAnanalyalyzlyzezererr
At the process level a BPEL engine supports the execution of the process
instances. We use a modi ed version of ActiveBPEL [
Runtime data are sent to the Goal Reasoner, through the Process Reasoner, and are used to update the elements of the goal model (i.e., events, entities, satisfaction of leaf goals and performed adaptations). The Process Reasoner also evaluates the satisfaction of leaf goals, by invoking a speci c Analyzer, depending on the kind of constraint (i.e., temporal or untimed) that must be checked. When the goal model changes, the Goal Reasoner noti es the Process Reasoner, which propagates these modi cations on the running and next process instances. To manage the interplay between the goal model and the process, the Process Reasoner uses a bidirectional mapping between the elements of the FLAGS model, and those of the implementation model. Note that the adaptations that are applied at runtime may generate di erent versions of the implementation model and the FLAGS model. For this reason, the Process Reasoner must store di erent mappings, depending on the versions of the models that are in use.
The Process Reasoner orchestrates the adaptation at the process level, according to the directives of the implementation model. It monitors the runtime data to check if the trigger and conditions of an adaptation are satis ed. In this case, it activates proper adaptation actions through an Adaptor, which can temporarily change the execution ow of a single process instance or may change the implementation model, by modifying the de nition of the process and the adaptation capabilities. To adapt the running process instances, the Adaptor intercepts the execution at a \safe" point, where the modi cations can be correctly applied, since they do not break any conversation or transaction. To adapt the next process instances the Adaptor transparently deploys a new version of the process in the BPEL engine.
At the goal level, the Graphical Designer [
Every time the last version of the FLAGS model is modi ed at runtime, a new version is created. Consequently, all live instances of the FLAGS model and their corresponding process instance must migrate to the new version of the model, if possible. A new version of the implementation model is inferred. In particular, the new version of the process is inferred and deployed on the BPEL Engine, the new mappings between the goal model and the process are generated and stored at the Process Reasoner, and the components at the process level must be properly re-con gured to update and apply process level adaptations for the modi ed instances of the FLAGS model. A live instance of the FLAGS model is canceled every time the Process Reasoner signals that the corresponding process instance has terminated. In case there is no running instance of a process associated with an old version of the FLAGS model, that version is removed together with its corresponding mappings at the Process Reasoner. 4 This section describes how adaptations are applied at runtime and their impact on the implementation and the FLAGS model. The implementation model may change when process level adaptations are performed. The FLAGS model can change when the designer manually modi es it or when goal level adaptations are applied, and, in these cases, the implementation model must evolve accordingly. 4.1
Adaptations at the process level are applied on a single process instance and may perform a small set of actions. They can change the process execution ow (action perf orm) or substitute a partner service with another one (action substitute). These adaptations require to keep the process blocked at speci c execution points, while their conditions are checked and their actions are applied, if necessary. The trigger of these adaptations must clearly identify the execution point where the adaptations are performed. Since conditions must be evaluated \on-the- y", while the process is blocked, they must be expressed as untimed formulas. The Process Reasoner can verify them by invoking one of the Analyzers that have been plugged in the infrastructure.
To apply action perform([o1; : : : ; on]; g=o), the operations included in the
rst argument (op1; : : : ; opn) are translated into a sequence of activities that
must be temporarily performed. These activities can be executed, for
example, by invoking an external partner service. The second argument is
associated with a concrete execution point where the process execution must be
restored. This action can be applied at runtime through a suitable Adaptor, such
as Dynamo [
To apply action substitute(a1, a2 [, o]), the BPEL partner links p1, p2 that are associated with agents a1, a2 must be identi ed. This action substitutes p1 with p2 for all process activities in which p1 is used, in case the third parameter is not speci ed. Otherwise, it is necessary to identify the process activities associated with operation o, and substitue p1 with p2 for all of them. Both adaptation actions can be supported by Dynamo. In the rst case, we can use recovery action rebindPartnerLink(name, wsdl), which changes partner link p1, identi ed by a name, with p2, identi ed by its wsdl. In the second case we can apply action rebind(wsdl, operation), which substitutes partner link p1, which performs activity operation, with p2, identi ed by its wsdl.
restore
call ES invoke-receive Get Restaurant
invoke Add Restaurant
G1.1.1
onMessage (SearchByName) invoke-receive SearchByName reply RestList
trigger AG1 while [cond1] pick ... ...
onMessage
(Select) Restaurant <
Select.id cond1 <- false
AG3
invoke-receive add FilterRestaurant
Fig. 3. BPEL process for the Click&Eat application.
For example, AG1 is an adaptation goal that applies action perf orm(GetRestaurant; AddRestaurant; G1:1:1) on a single process instance. To support its enactment at runtime, the Internal Probes must be instrumented to intercept the process execution at the points when event Show (trigger) takes place. In our example (see Figure 3) this corresponds to the execution point after activity reply RestList. This way, every time the process terminates this activity, its execution is blocked, and, in case the condition is satis ed, an external service (ES) is invoked. It performs a sequence of activities associated with the operations GetRestaurant and Add Restaurant and restores the process execution before activity pick, which is the execution point where G1.1.1 starts to be activated.
All adaptations that are applied on all process instances have a permanent e ect on the implementation model. The trigger of these adaptations only identi es the moment when the condition can be veri ed. A set of \safe points" must be identify the process point at which an adaptation must be applied. In case a running process instance has already passed all safe points, it cannot be migrated. All the other adaptations at the process level are temporarily deactivated, until all instances complete the migration to the next version of the process, when possible. The new mappings between the new version of the process and the last version of the FLAGS model must be also added to the Process Reasoner. Finally the adaptation capabilities at the Data Collector and Process Reasoner may also change.
AG2 falls in this category, since it applies action x(AG1) to modify the process de nition. After the Process Reasoner performs AG1 (trigger) for one of its process instances, the condition associated with AG2 must be veri ed. AG2 applies a set of modi cations at the Process Reasoner, since it removes AG1 and all the directives necessary to support its execution. AG2 also modi es the process de nition by inserting a set of activities after the execution point identi ed by the trigger of AG1 (i.e., after activity reply RestList ). These activities are: an if activity, which veri es the condition of AG1, and the activities that were temporarily performed by external service ES. A new version of the process that includes all these modi cations is deployed as well in the BPEL Engine. 4.2
For goal level adaptations things work slightly di erently. Their trigger and conditions are checked by the Goal Reasoner every time a new element of the goal model is updated. When an adaptation at the goal level is applied, the Goal Reasoner suspends all further updates of the goal model and stores all runtime data received from the Process Reasoner in a bu er, until the adaptation completes. It also sends a noti cation to the Process Reasoner to block all running process instances at the end of the activity they are currently executing. An adaptation at the goal level generates a new version of the FLAGS model, and must apply the corresponding modi cations onto its live instances. Note that only those instances that comply with the last version of the FLAGS model can potentially migrate to the new version. The migration can take place only if the corresponding process instance has not already passed the safe points where modi cations must be applied.
A new version of the implementation model is created accordingly. In particular, the Process Reasoner creates a new version of the mappings between the process and the goal model and indicates what are the process instances that must actually follow this mapping. Consequently the probes and the Process Reasoner change their con guration to respectively intercept the process at di erent points, collect di erent data, evaluate di erent leaf goals (speci ed with di erent constraints) and activate di erent adaptation actions. Finally the de nition of all running and next process instances must change to comply with the modi cations of the goal model. For example, if some goals or operations are added/removed, the corresponding activities in the process de nition must be added/removed. In case agents are added/removed, the corresponding partner links must be added/removed from/to the process de nition and so on.
After all aforementioned actions are performed, the execution of all process instances can be restored. All runtime data received by the Process Reasoner that are not associated with any element at the goal level are automatically removed. The Goal Reasoner will start to process the data stored in its bu er only after all process instances correctly migrated to their new version (if possible). The Goal Reasoner will discard all the data that are associated with leaf goals, entities and events that do not exist anymore or have been modi ed. Goal level adaptations can be triggered while a process level adaptation, which modi es the process de nition, is being performed on the process. In this case, it is necessary to guarantee that only the previous adaptation is applied, or both of them are applied. In other cases a goal level adaptation can be triggered while one or more process instances are performing a process level adaptation that just temporarily modi es the process execution ow. In this case the process instance must terminate the execution of the temporary activities and must be blocked before performing the activity associated with the restore point.
In our example, AG3 applies a goal level adaptation when the satisfaction of G1.5 is low (trigger). It changes the de nition of goal G1.1.1 and its operationalization. As an e ect, the Goal Reasoner creates a new version of the FLAGS model, manage the migration for the live instances of the model, and adds a new version of the mappings to the Process Reasoner. At the process level the next process instances can be migrated by deploying a new version of the BPEL process, which complies with the new version of the FLAGS model. The running process instances can be migrated by intercepting their execution before activity pick and adding activity invoke-receive FilterRestaurant after invoke-receive SearchByName, as shown in Figure 3. A similar procedure is followed when a new version of the FLAGS model is manually created by designer, who directly modi es the last version of the FLAGS model. This can happen when, for example, the requirements of the system change, as shown in Figure 1(b). In this case, the Graphical Designer noti es the Goal Reasoner that propagates the modi cations on the live instances of the FLAGS model and on the process. A goal model at runtime allows us to reshape the adaptations at the process level, depending on the modi cations applied on the process. In this example all the adaptation goals that have been de ned can persist, since goal G1.1.1 and event Show are not removed. However the way adaptations are supported at runtime changes. For example, at the process level AG3 will be added after another activity (invoke-receive SearchOpenByName), and will modify the new de nition of G1.1.1 by adding its conjunct constraint to its modi ed consequent. 5
Di erent solutions have been already proposed to support requirements
evolution. Courbis and Finkelstein [
To support requirements at runtime the link between the requirements and
the underlying implementation cannot be lost. The changes in the system
requirements at runtime may trigger the execution of a set of analysis (e.g.,
consistency check, requirements veri cation) that have been traditionally performed
o ine. Baresi and Ghezzi [
Our approach needs further improvements. It lacks a mechanism to verify the consistency and correctness of the models updated by the designer. It should better handle con icts between adaptations that are activated at the same time. We are also planning to exploit requirements@runtime in the security domain. Security is a critical property whose violation must be avoided. The countermeasure used to support this property depend on the context and, for this reason, it may be fundamental to detect changes that can take place in the assets to be protected or in the environment. These changes may trigger suitable analysis at runtime and activate new countermeasures necessary to continue to guarantee the satisfaction of security requirements.