The Journal of Systems and Software 130 (2017) 94–112

Contents lists available at ScienceDirect

The Journal of Systems and Software

journal homepage: www.elsevier.com/locate/jss

A domain-specific language for the control of self-adaptive

component-based architecture
Frederico Alvares a,∗, Eric Rutten b, Lionel Seinturier c
a
IMT Atlantique & Inria & LS2N, Nantes, France
b
Universit Grenoble Alpes, Inria, CNRS, LIG, Grenoble, France
c
Université Lille 1 & Inria, Lille, France

a r t i c l e i n f o a b s t r a c t

Article history: Self-adaptive behaviours in the context of Component-based Architecture are generally designed based on
Received 16 February 2016 past monitoring events, configurations (component assemblies) as well as behavioural programs defining
Revised 13 January 2017
the adaptation logics and invariant properties. Providing assurances on the navigation through the config-
Accepted 31 January 2017
uration space remains a challenge. That requires taking decisions on predictions on the possible futures
Available online 1 February 2017
of the system in order to avoid going into branches of the behavioural program leading to bad configura-
MSC: tions. We propose the design of self-adaptive software components based on logical discrete control ap-
10.040 proaches, in which the self-adaptive behavioural models enrich component controllers with a knowledge
10.280 not only on events, configurations and past history, but also with possible future configurations. This arti-
10.090 cle provides the description, implementation and discussion of Ctrl-F, a Domain-specific Language whose
10.050
objective is to provide high-level support for describing these control policies. Ctrl-Fis formally defined
20.120
by translation to Finite State Automata models, which allow for the exploration of behavioural programs
Keywords: by verification or Discrete Controller Synthesis, i.e., by automatically generating a controller to enforce
Component-based architecture correct self-adaptive behaviours. We integrate Ctrl-F with FraSCAti, a Service Component Architecture
Self-adaptation middleware platform and we illustrate the use of Ctrl-Fby applying it to two case studies.
Discrete control
© 2017 Elsevier Inc. All rights reserved.

1. Introduction capsulate functionalities that can be accessed through well-defined

interfaces that do not depend on their particular implementations.
Architecting software-intensive systems has become a challeng- In addition to the benefits of modularity and reuse (Jacobson et al.,
ing task. From tiny applications embedded in house appliances or 1997) – which are consequences of this structural organization
automobiles, passing through highly connected cyber physical sys- – adaptability and reconfigurability are key properties which are
tems, to huge and distributed services in the Cloud, nowadays soft- sought with this approach: one wants to be able to adapt the com-
ware systems have to fulfil a number of requirements in terms of ponent assemblies in order to cope with new requirements and
operational cost, safety and Quality of Service (QoS) while facing new execution conditions occurring at runtime.
highly dynamic environments (e.g., varying workloads and chang- Architecture Description Languages (ADLs) are used to capture
ing user requirements) and platforms (e.g., software/hardware re- the high-level structure of software systems by describing how
source availability and failures). That level of dynamicity makes it they are organized by the means of a composition of components.
difficult, of ten almost impossible, to manage such software sys- In order to attain self-adaptation, ADLs are generally used to define
tems in a manual way. It becomes thus imperative to engineer and initial configurations, whereas adaptive behaviours are achieved by
architect with principles of self-adaptiveness in mind, i.e., to equip programming fine-grained actions (e.g., to add, remove, connect
these software systems with capabilities to cope with environmen- elements), in either general-purpose languages within reflective
tal and contextual changes occurring at runtime. component-based middleware platforms (Bruneton et al., 2004;
The design of such complex computing systems has been Warren et al., 2006; Seinturier et al., 2012), or with the support
improved by the help of structural organization support of of reconfiguration domain-specific languages (DSLs)(David et al.,
component-based architecture, in which software components en- 2008; Garlan et al., 2004a).
This low level of abstraction may turn the definition of tran-
∗
sitions among configurations into a very tedious and costly task,
Corresponding author.
E-mail addresses: [email protected] (F. Alvares), eric.rutten@
which consequently may lead to error-prone adaptive behaviours.
inria.fr (E. Rutten), [email protected] (L. Seinturier). In fact, it may be non-trivial, especially for large and complex

http://dx.doi.org/10.1016/j.jss.2017.01.030
0164-1212/© 2017 Elsevier Inc. All rights reserved.
 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112 95

Fig. 1. Approach overview.

architectures (e.g., web applications with hundreds/thousands of have to be kept invariant regardless of the configuration at run-
replicated components with specific tuning parameters and con- time.
straints), to conceive well-mastered self-adaptive behaviours, with Ctrl-F programs are modelled in Heptagon/BZR (cf. Fig. 1(b))
assurances on the way the navigation through the configuration with a set of data-flow equations, automata and contracts, which is
space is performed. Our previous work (Alvares et al., 2015b) tack- used to specify the controllable variables and the control objectives
les this problem by proposing Ctrl-F, a DSL that extends classic used for DCS. The result of the compilation of a given behavioural
ADLs with high-level constructs to describe adaptation in software program is an executable function, i.e.,a controller (cf. Fig. 1(c), DCS
components by means of behavioural programs, i.e., in terms of Ctrlr) which, at each decision step, takes the current state and cur-
order and/or conditions under which reconfigurations take place; rent events (u in Fig. 1(c), referring to uncontrollable variables),
and policies, i.e., constraints that have to be enforced all along and returns a control value (c in Fig. 1(c)) corresponding to the
the execution. In other words, Ctrl-Fis a first-class language that next configuration such that the stated policies are respected.
is applicable to any Component-based application requiring self- Since the combinatorial complexity of the formal exploration
adaptation with formal guarantees. performed by DCS can be exponential in the number of configu-
Adaptation decisions are taken at runtime by choosing the next rations and hence very costly to be performed at runtime, we ad-
configuration in function of not only the observed past history vocate that the DCS should rather be performed off-line. That is
(monitoring events, states, configurations), but also on behavioural to say that controllers are compiled away so as to provide correct
programs describing the adaptation logics and properties to be solutions at runtime. It is obvious that it comes at the cost of re-
kept invariant all over the managed system’s execution (Garlan quiring a previous knowledge on all possible configurations of the
et al., 2004b; Kouchnarenko and Weber, 2014). That form of de- system, which is the case of the behavioural programs of Ctrl-F. On
cision must involve not only updating the current advancement in the other hand, having controllers generated at design-time makes
the behaviours, but also some predictions on the possible futures decision-making more reactive at runtime, because the solutions
of the system. These guarantees can be achieved with the support are already computed. In addition, decisions made by controllers
of control theoretical approaches (Brun et al., 2009), where the may be way more complex than just selecting configurations. It
use of behavioural models allows for predictive decisions. Control- may involve also incoming events, past and future configurations,
based approaches for software systems have been investigated, which makes it difficult to achieve without the proper formal sup-
mainly concerning quantitative aspects and using continuous con- port, and even more so if guarantees have to be provided. Fur-
trol (Abdelzaher et al., 2008). The use of discrete control is how- thermore, DCS is done in a maximal permissive way, meaning that
ever more appropriated in the context of this work, since the pur- besides ensuring the correctness of decisions, the generated con-
pose here is to choose configurations in a logical-basis. In partic- troller makes it optimal, in the sense that it keeps the maximum of
ular, we address the design of such a decision-maker as a Discrete possible configurations not violating the stated policies, and hence
Controller Synthesis (DCS) problem (Marchand et al., 20 0 0), which making the controlled system maximally flexible.
consists in automatically generating a controller capable of control- With respect to our previous contributions (Alvares et al.,
ling a set of input variables such that a given temporal property is 2015a; 2015b), this article provides a more complete and detailed
satisfied. description of the Ctrl-Flanguage, on the whole translation pro-
For that purpose, our previous work formally define the seman- cess into Heptagon/BZR, as well as on its implementation and in-
tics of Ctrl-Fbehavioural programs by the translation to Finite State tegration with FraSCAti (Seinturier et al., 2012), a middleware al-
Automata (FSA) behavioural models (Alvares et al., 2015a), which lowing for runtime reconfiguration of Service Component Archi-
provide knowledge on events, states, past history as well as on tecture (SCA) software systems. Besides the news web application
possible futures, i.e., the space of reachable configurations. Hence, case study Znn.com (Cheng et al., 2009), which is used to illustrate
we are be able to, by control, avoid going into behavioural pro- the main concepts of Ctrl-Fand their compilation towards Hep-
gram branches leading to wrong configurations. More precisely, we tagon/BZR, this article also illustrates the use of Ctrl-Fto a work-
provide full translation from Ctrl-Fto the reactive language Hep- flow application with mutual exclusion requirements, which allows
tagon/BZR (Delaval et al., 2010), which allows the compilation to- for more elaborated discussions on certain features that cannot be
wards formal tools and thereby benefit from state space explo- deeply explored by Znn.com, such as making decisions considering
ration by both DCS and verification. the possible future configurations.
The principle is to have a feedback control loop within each The remainder of this article is organized as follows.
component (cf. Fig. 1(a)), which takes decisions in response to Section 2 introduces the main concepts necessary to understand
occurred events, while taking into consideration the current/past our approach. Section 3 presents the Ctrl-Flanguage in details,
configurations, a behavioural program, and determining as result while its compilation to Heptagon/BZRis detailed in Section 4.
which configurations (i.e.,how architectural elements are put to- Section 5 provides some details on the Ctrl-Fcompilation tool-
gether) have to be terminated and which ones have to be started. chain and integration with a FraSCAti middleware platform.
We rely on Ctrl-Fto specify: (i) behaviours in a in terms of se- Section 6 presents two case studies that foster a detailed discus-
quences, alternative/conditional/parallel branches and loops of con- sion on the applicability, usefulness and limitations of our ap-
figurations; and (ii) policies, which take the form of properties that proach. Related work is discussed in Section 7 and Section 8 con-
96 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112

cludes this article while pointing out some perspectives for future
work.

2. Background

2.1. Component-based software architecture

2.1.1. Architecture basics and description language

Software architectures define the high-level structure of soft-
ware systems by describing how they are organized by the means
of a composition of components (Jacobson et al., 1997). Architec-
ture description languages (ADLs) (Medvidovic and Taylor, 20 0 0)
Fig. 2. Graphical representation of component lifecycle.
are usually used to capture these architectures. Although the di-
versity of ADLs, the architectural elements proposed in almost all
of them follow the same conceptual basis (Garlan et al., 20 0 0). A
component is defined as the most elementary unit of processing
or data and it is usually decomposed into two parts: the imple-
mentation and the interface. The implementation describes the in-
ternal behaviour of the actual component, whereas the interfaces
define how the component should interact with the environment.
A component can be defined as simple/atomic or composite (i.e.,
composed of other components). A connector corresponds to inter-
actions among components. It mediates an inter-component com-
munication in diverse forms of interactions. A configuration cor-
Listing 1. Textual representation of component lifecycle.
responds to a directed graph of components and connectors de-
scribing the application’s structure. Other elements like attributes,
constraints or architectural styles may also appear in ADLs (Garlan Reactive Languages have been proposed to describe systems
et al., 20 0 0). that at each reaction perform a step taking input flows, comput-
ing transitions, updating states, triggering actions, emitting output
2.1.2. Dynamic reconfiguration flows (Harel and Pnueli, 1985). Their definition is often based on
Contrary to static reconfiguration, dynamic reconfiguration de- Finite State Automata (FSA), which constitute the basic formalism
notes the passage from one configuration to another without the for representing behaviours, as is the case of StateCharts (Harel,
need to stop the system execution or to entirely redeploy it in or- 1987) and of synchronous languages (Halbwachs, 2010).
der for the modification to take effect. As a consequence, the num-
ber of interferences on the system execution is reduced and avail- 2.2.1. Heptagon/BZR
ability is increased. Heptagon/BZR (Delaval et al., 2010) is a language that allows the
Component-based architectures are very suitable for dynamic definition of reactive systems by means of generalized Moore ma-
reconfigurations. Indeed, thanks to their native characteristics of chines, i.e., with mixed synchronous data-flow equations and au-
modularity and reuse, it is possible to isolate the modifications so tomata (Colaço et al., 2005). An Heptagon/BZRprogram is modu-
that the interference on the system execution is mitigated. In addi- larly structured with a set of nodes. Each node corresponds to a
tion, with the advent of reflection, modern component models like reactive behaviour that takes as input and produces as output a
Fractal (Bruneton et al., 2004) and OpenRec (Warren et al., 2006), set of stream values. The body of a node consists of a set of dec-
among others, bring reflection capabilities to software architec- larations that take the form of either automata or equations. The
tures. They a meta level, in which components are equipped with equations determine the values for each output, in terms of ex-
control interfaces so as to allow for the introspection (observa- pressions on inputs’ instantaneous values or other flows values.
tion on the architectural elements e.g., assemblies, interfaces, con- Fig. 2 and Listing 1 show an Heptagon/BZRprogram respectively
nectors, and so forth) and intercession (reconfiguration e.g., cre- in graphical and textual representations. The program describes
ation/suppression of components, connectors, etc.). the control of a component lifecycle that can be in either idle
In short, component-based architectures, and especially the (I), waiting (W) or active (A) states. The program takes as input
ones equipped with reflection capabilities like Fractal, have capa- three Boolean variables: r, which represents a request signal for
bilities that are particularly interesting and applicable in the do- the component; c, which represents an external condition (to be
main of self-adaptive software systems. This is generally achieved used later on as controllable variable); and e, to represent an end
by first using ADL, to define initial architectural configurations, signal. It produces as output two Boolean values, one that indi-
from which, by relying on introspection and reconfiguration mech- cates whether the component is active (a) the another indicating
anisms (Bruneton et al., 2004) or languages (David et al., 2008), a start action (s). When in the initial state, upon a request sig-
one can add or remove elements at runtime in response to envi- nal (i.e., when r is true), the automaton leads to either waiting or
ronment changes, while mitigating the interferences on their exe- active states, depending whether the condition c holds. If it does
cution. not, it goes first to the waiting state and then to active when c
becomes true. All the incoming transitions arriving at active state
2.2. Reactive systems and languages triggers the start action (s). From active state, it goes back to idle
state upon an end signal.
Software components can be controlled according to monitored One important characteristic of Heptagon/BZRis the support for
events, the current state, available configurations and invariant hierarchical and parallel automata composition. Fig. 3 illustrates an
properties (Kramer and Magee, 2007). This reactive nature of soft- example of hierarchical composition, in which a single state super-
ware components makes reactive systems and languages a very automaton embodies the lifecycle automaton of Fig. 2. It has a self-
suited to support design of such control behaviour. transition that results in the resetting of the sub-automaton (i.e.,
 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112 97

the with block (line 5) defines two controllable variables that are
used within the node (lines 7 and 8). In practice, they will be given
values such that variables a1 and a2 are never both true at the
same instant.

2.2.3. Compilation and code generation

The Heptagon/BZR compilation chain is as follows: from source
Fig. 3. Example of hierarchical composition.
code, the Heptagon/BZR compiler produces as output a sequential
Table 1 code in a general-purpose programming language (e.g., Java or C)
Execution of the hierarchical composition. implementing the control logic, in the form of a step function to be
called at each decision in the autonomic loop. At the same time, if
step # 1 2 3 4 5 6 7 8 9 10 ...
the code provided as input contains some contracts, the compiler
b 0 0 0 0 0 0 0 0 1 0 ... will also generate an intermediary code that will be given as in-
r 0 1 0 0 0 0 1 0 0 0 ...
c 0 0 1 0 0 0 1 0 0 0 ...
put to the model checker (e.g., Sigali or Reax), which will, in turn,
e 0 0 0 0 1 0 0 0 0 0 ... perform the DCS and produce as output a Heptagon/BZRcode cor-
a 0 0 0 1 1 0 0 1 1 0 ... responding to the generated controller. The latter is then compiled
s 0 0 1 0 0 0 1 0 0 0 ... again so as to have an executable code also for the generated con-
troller.

3. Ctrl-F language

This section presents Ctrl-F, our domain specific language

(DSL) for describing control policies. Section 3.1 introduces the
Znn.comapplication, which is used throughout the article to illus-
trate the concepts introduced with Ctrl-F. Section 3.2 presents the
core concepts of Ctrl-F. Sections 3.3 and 3.4 define the notions of
Listing 2. Example of contract in Heptagon/BZR.
behaviour and policy that are specific to Ctrl-F.

3.1. Example application

lifecycle) at every occurrence of signal b. A stream of input/output
values for this automaton can be seen in Table 1. In particular, we Znn.com (Cheng et al., 2009) is an experimental platform for
can see at step 9, the resetting of the sub-automaton, which brings self-adaptive applications, which mimics a news website. As in any
it from state active back to idle (at step 10), without any explicit web application, Znn.comfollows a typical client-server n-tiers ar-
transition. Regarding the parallel composition, Listing 2 illustrates chitecture, meaning that it relies on a load balancer to redirect re-
two instances of the lifecycle node (and the operator ’;’). They run quests from clients to a pool of replicated servers. The number of
in parallel, in a synchronous way, meaning that one global step active servers can be regulated in order to maintain a good trade-
(in node twocomponents) corresponds to one local step for every off between response time and resource utilization. Hence, the ob-
instance of the lifecycle node. jective of Znn.comis to provide news content to its clients/visitors
within a reasonable response time, while keeping costs as low as
2.2.2. Contracts and discrete controller synthesis possible and/or under control (i.e., constrained by a certain bud-
BZR is an extension of Heptagon language with specific con- get).
structs for Discrete Controller Synthesis (DCS). That makes Hep- There might be times where only the pool of servers is not
tagon/BZR distinguishable since its compilation may involve formal enough to provide the desired Quality of Service (QoS). For in-
tools for DCS purposes. A DCS consists in automatically generating stance, in order to face workload spikes, Znn.comcan be forced to
a controller capable of acting on the original program to control degrade the content fidelity so as to require fewer resources to
input variables such that a given temporal property is enforced. In provide the same level of QoS. To this end, Znn.comservers are
Heptagon/BZR, DCS is achieved by associating a contract to a node. able to deliver news contents in three different ways: (i) with high
A contract is itself a program with two inputs: eA , an assumption quality images, (ii) with low quality images, and (iii) with only
on the node environment; and eG , a property to be enforced by the text. Thus, content fidelity can be seen as another criterion. In
node. A set {c1 , c2 , . . . , cq } of local controllable variables is used for summary, the objectives are as follows:
ensuring this objective. To put it differently, the contract means • Keep the performance (in terms of response time) as high as
that the node will be controlled by assigning values to {c1 , . . . , cq }
possible;
such that given any input flow satisfying assumption eA , the out- • Keep content fidelity as high as possible or above a certain
put will always satisfy goal eG . When a contract has no control-
threshold;
lable variables provided, there is no need for controller. In which • Keep the number of active servers as low as possible or under
case, the DCS tool verifies that eG is satisfied in the reachable state
a certain threshold.
space, even if no controller is generated. Thus, the formal guar-
anties can be achieved by both: (i) control (via DCS) or (ii) verifi- In order to achieve them, we may tune: (i) the number of active
cation. servers; and (ii) the content fidelity of each server.
Listing 2 shows an example of contract on a node enclosing a
parallel composition of two instances of lifecycle (cf. Fig. 2). It is 3.2. Core concepts
composed of three blocks. The assume block (line 3), which in this
case, states that there is no assumption on the environment (i.e., As depicted in Fig. 4, the abstract syntax of Ctrl-Fcan be divided
eA = true). The enforce block (line 4) describes the control objec- into two parts: a static one, which is related to the common ar-
tive : eG = ¬(a1 ∧ a2 ), meaning that both components are mutu- chitectural concepts (components, connections/bindings, configura-
ally exclusive, i.e., they cannot be active at the same time. Lastly, tions, etc.); and a dynamic one, which refers to reconfiguration be-
98 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112

Fig. 4. Language abstract syntax. Listing 4. Architectural description of component Znn in Ctrl-F.

Listing 5. Architectural description of component LoadBalancer in Ctrl-F.

Listing 3. Architectural description of component Main in Ctrl-F.

haviours and policies that must be enforced regardless of the con-

figuration.
The static part of Ctrl-Fprovides the same core concepts as
many existing ADLs (e.g., Fractal (Bruneton et al., 2004), Acme
(Garlan et al., 20 0 0)). A component consists of a set of interfaces,
a set of event ports, a set of attributes and a set of configurations.
Interfaces define how a component can interact with other compo-
nents. They are used to express a required functionality (client in-
terface) that may be provided by another component and/or to ex-
press a provided functionally (server interface) that might be used
by other components. Event Ports describe the events, of the given
Event Type, a component is able to emit (port out) and/or listen to Listing 6. Architectural description of component AppServer in Ctrl-F.
(port in). A configuration is defined as a set of instances of com-
ponents, a set of bindings connecting server and client interfaces of
those instances (i.e., an assembly), and/or a set of attribute assign- those components is depicted in Figs. 5–7, where the vertical bars,
ments to values. squares, triangles, and upside-down triangles correspond to inter-
The dynamic part consists of a behaviour and a set of policies faces, attributes, port in and out, respectively.
that can be defined for each component. A behaviour takes the The Main component (cf. Listing 3) encompasses two instances
form of orders and conditions (w.r.t. events and attribute values) of the Znn component, namely soccer and politics within a sin-
in which transitions between configurations (reconfigurations) take gle configuration (lines 6 and 7). The server interfaces of both in-
place. The policies are high-level objectives/constraints, which may stances (lines 8 and 9), which provides access to news services, are
imply the inhibition of some of those transitions. bound to the server interfaces of the Main component (line 3) in
The Znn.com example application of Section 3.1 can be mod- order for them to be accessed from outside. A policy to be enforced
eled as a hierarchical composition of four components: Main, Znn, is defined (line 12) and discussed in Section 3.4. Fig. 5 shows the
LoadBalancer, and AppServer. These components are instantiated ac- Main component’s graphical representation.
cording to execution conditions, the system current state (archi- The Znn component (cf. Listing 4) consists of one server inter-
tectural composition), adaptation behaviours and policies defined face (line 3) through which news can be requested. The compo-
within each component. Listings 3–6 show the textual definition nent listens to events of types oload (overload) and uload (under-
of such components with the static part of Ctrl-F. In addition, to load) (line 5), which are emitted by other components. In addition,
better illustrate the Ctrl-Fconcepts, the graphical representation of the component also comprises two attributes (line 7): consumption,
 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112 99

instance as1, whereas consumption is given by to the sum of the

consumptions of instances as1 and lb. conf2 (lines 17–22) extends
conf1 by adding one more instance of AppServer, binding it to the
LoadBalancer and redefining the attribute values with respect to
the just-added component instance (as2). In that case, the attribute
fidelity values the average of the counterparts of instances as1 and
as2 (line 20), whereas for the consumption the same logics is ap-
plied so the consumption of the just-added instance is incorpo-
rated to the sum expression (line 21). The definition of configu-
Fig. 5. Graphical representation of Main component. ration conf3 follows the same idea: it extends conf2 by adding a
new instance of AppServer, binding it and redefining the attribute
values. The graphical representation of the Znn component is given
in Fig. 6.
Listing 5 shows the description of component LoadBalancer,
which consists of four interfaces: one provided, i.e., server inter-
face (line 2), through which the news are provided; and the others
required (line 3), through which the load balancer delegates each
request for balancing purposes. We assume that this component
is able to detect overload and underload situations (in terms of
number of requests per second) and in order for this information
to be useful for other components we define two event ports that
are used to emit events of type oload and uload (line 5). Like for
component Znn, attribute consumption (line 7) specifies the level
of consumption of the component (e.g., 0.2 to express 20% of CPU
consumption). As there is no explicit definition of configurations,
LoadBalancer is implicitly treated as a single-configuration compo-
nent. The graphical notation of component LoadBalancer is depicted
in Fig. 7 (a).
Lastly, the atomic component AppServer, as described in List-
ing 6, has only one interface (line 2) and listens to events of type
oload and uload (line 4). It has also two attributes: fidelity and con-
sumption (line 6), just like component Znn. Three configurations
corresponding to each level of fidelity (lines 8–11, 12–15 and 16)
are defined, and the attributes are valuated according to the con-
cerned configuration, i.e., the higher the fidelity the higher the
Fig. 6. Graphical representation of Znn component.
consumption. Fig. 7(b) gives the graphical representation of com-
ponent AppServer.
It is worth noting that while the diagram in Fig. 7 depicts
the definition of components LoadBalancer and AppServer, the di-
agram in Fig. 6 represents their instantiation within composite
Znn’s definition. The former diagram illustrates atomic compo-
nents in different configurations in terms of attribute value assign-
ments (e.g., consumption = 0.2, f idelity = 0.25, when AppServer is
in mode/configuration text), whereas the latter shows a compos-
ite with different configurations in terms of sub-component as-
semblies, that is, instances of atomic components LoadBalancer,
AppServer that are bound together.

3.3. Behaviours

A particular characteristic of Ctrl-Fis the capability to com-

prehensively describe behaviours in software components. We
mean by behaviour the process in which architectural elements
Fig. 7. Graphical representation of (a) Load Balancer and (b) App Server components. are changed, i.e.,the order and conditions in which configurations
within a component take place.
Behaviours in Ctrl-Fare defined with the aid of a high-level im-
which is used to express the level of consumption (in terms of per- perative language. It consists of a set of behavioural statements
centage of CPU) incurred by the component execution; and fidelity, (sub-behaviours) that can be composed together so as to provide
which expresses the content fidelity level of the component. more complex behaviours in terms of sequences of configurations.
Three configurations are defined for the Znn component: conf1, In this context, a configuration is considered as an atomic be-
conf2 and conf3. conf1 (lines 9–16) consists of one instance of each haviour, i.e.,a behaviour that cannot be decomposed into other sub-
LoadBalancer and AppServer (lines 10 and 11); one binding to con- behaviours. A reconfiguration occurs when the current configura-
nect them (line 12), another binding to expose the server inter- tion is terminated and the next one is started. We assume that
face of the LoadBalancer component as a server interface of the configurations do not have the capability to directly terminate or
Znn component (line 13), and the attribute assignments (lines 14 start themselves, meaning that they are explicitly requested or
and 15). The attribute fidelity corresponds to the counterpart of ended by behaviour statements according to the defined events and
100 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112

Table 2
Summary of behaviour statements.

Statement Description

B when e1 do B1 ,
... , Execute B until an occurrence of ei then reconfigure to execute Bi
en do Bn end
case c1 then B1 ,
... , Execute Bi if ci holds, otherwise execute Be
cn then Bn
else Be end
B1 ||B2 Execute B1 and B2 in parallel
B1 |B2 Execute either B1 or B2
do B every e Execute B and re-execute it at every occurrence of e

Listing 7. AppServer’s behaviour.

policies. Nevertheless, as components are capable to emit events, it

would not be unreasonable to define components whose objective
is to emit events in order to force a desired behaviour (e.g.,to start
or terminate a certain configuration).
Listing 8. Znn’s behaviour.

3.3.1. Statements
Table 2 summarizes the behaviour statements of the Ctrl-
Fbehavioural language. During the execution of a given behaviour alternative one. It is important to mention that the decision on one
B, the when-do statement states that when an event of type ei oc- or other configuration must be taken at runtime according to in-
curs the configuration(s) that compose(s) B should be terminated put variables (e.g., income events) and the stated policies, that is,
and that (those) of the corresponding behaviour Bi is (are) started. there must be a control mechanism for reconfigurations that en-
The case-then statement is quite similar to when-do. The differ- forces those policies. We come back to this subject in Section 4.
ence resides mainly in the fact that a given behaviour Bi is ex- Regarding component Znn, the expected behaviour is to start
ecuted if the corresponding condition ci holds (e.g., conditions on with the minimum number of AppServer instances (configuration
attribute values), which means that it does not wait for an event to conf1) and add one more instance, i.e., leading to configuration
occur. In addition, if none of the conditions holds (c1 ∧ . . . ∧ cn = 0), conf2, upon an event of type (oload). From conf2, one more in-
a default behaviour (Be ) is executed, which forces the compiler to stance must be added, upon an event of type oload leading to con-
choose at least one behaviour. The parallel statement (with opera- figuration conf3. Alternatively, upon an event of type uload, one
tor ||) states that two behaviours are executed at the same time, instance of AppServer must be removed, which will lead the ap-
i.e., at a certain point, there must be two independent branches of plication back to configuration conf1. Similarly, from configuration
behaviour executing in parallel. This construct is also useful in the conf3, upon a uload event, an instance of AppServer is removed,
context of atomic components like AppServer, where we can, for leading the application to conf2. It is notorious that this behaviour
instance, define configurations composed of orthogonal attributes can be easily expressed by an automaton, with three states (one
like fidelity and font size/color (e.g., text || font-huge). per configuration) and four transitions (triggered on the occurrence
The alternative statement (with operator |) allows to describe of oload and uload). However, Ctrl-Fis designed to tackle the adap-
choice points among configurations or among more elaborated se- tation control problem in a higher level, i.e., with statements over
quential behaviour statements. They are left free in local specifica- configurations.
tions and will be resolved in upper level assemblies, in such a way For these reasons, we describe the behaviour with two embed-
as to satisfy the stated policies, by controlling these choice points ded do-every statements, which in turn comprise each a when-do
appropriately. Finally, the do-every statement allows for execution statement, as shown in Listing 8 (lines 6–14 and 8–12). We also de-
of a behaviour B and re-execution of it at every occurrence of an fine two auxiliary configurations: emt1 (line 2) and emt2 (line 3),
event of type e. It is noteworthy that behaviour B is preempted which extend respectively configurations conf2 and conf3, with an
every time an event of type e occurs. In other words, the configu- instance of a pre-defined component Emitter. This component does
ration(s) currently activated in B is (are) terminated, and the very nothing but emits a given event (e.g., e1 and e2) so as to force a
first one(s) in B is (are) started. loop step and thus go back to the beginning of the when-do state-
ments. The main do-every statement (lines 6–14) performs a when-
3.3.2. Example in Znn.com do statement (lines 7–13) at every occurrence of an event of type
We now illustrate the use of the statements we have introduced e1. In practice, the firing of this event allows going back to conf1
to express adaptation behaviours for components AppServer and regardless of the current configuration being executed. conf1 is ex-
Znn of the Znn.comcase study. The expected behaviour for com- ecuted until the occurrence of an event of type oload (line 7), then
ponent AppServer is to pick one of its three configurations (text, the innermost do-every statement is executed (lines 8–12), which
img-ld or img-hd) at every occurrence of events of type oload or in turn, just like the other one, executes another when-do state-
uload. As can be seen in Listing 7, the behaviour can be decom- ment (lines 9–11) and repeats it at every occurrence of an event of
posed in a do-every statement, which is, in turn, composed of an type e2. Again, this structure allows the application to go back to
 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112 101

Listing 10. Example of temporal constraint.

Listing 9. Example of constraint and optimization on attributes.

may become a very difficult task. To specify these constraints, Ctrl-

configuration conf2. Configuration conf2 is executed until an event F provides four constructs, as follows:
of type either oload or uload occurs. For the former case (line 9), • conf1 precedes conf2 : conf1 must take place right before conf2 .
another when-do statement takes place, whereas for the latter (line
It does not mean that it is the only one, but it should be among
10) configuration emt1 is the one that takes place. Essentially, at
the configurations taking place right before conf2 .
this point, an instance of component Emitter is deployed along • conf1 succeeds conf2 : conf1 must take place right after conf2 .
with conf2, since emt1 extends conf2. As a consequence, this in-
Like in the precedes constraint, it does not mean that it is the
stance fires an event of type e1, which forces the application to go
only one to take place right after conf2 .
back to conf1. The innermost when-do statement (line 9) consists • conf1 during conf2 : conf1 must take place along with conf2 .
in executing conf3 until an event of type uload occurs, then config- • conf1 between (conf2 , conf3 ): once conf2 is started, conf1 can-
uration emt2 takes place, which makes an event of type e2 be fired
not be started and conf3 , in turn, cannot be started before conf2
in order to force going back to conf2.
terminates.
It is important to notice that this kind of construction allows to
achieve the desired behaviour while sticking to the language de- Listing 10 shows an example of how to apply temporal con-
sign principles, that is, high-level process-like constructs and con- straints, in which it is stated that configuration img-ld comes right
figurations. It also should be remarked that while in Listing 8, we after the termination of either configuration text or configuration
present an imperative approach to forcibly increase the number of img-hd. In this example, the policies avoid abrupt changes on the
AppServer instances upon uload and oload events, in Listing 7 we content fidelity, such as going directly from text to image high def-
let the compiler choose the most suitable fidelity level according to inition or the other way around. Again, it does not mean that no
the runtime events and conditions. Although there is no straight- other configuration can take place along with img-ld, but the alter-
forward guideline, an imperative approach is clearly more suitable native statement in the behaviour described in Listing 7 leads us
when the solution is more sequential and delimited, whereas as to conclude that only img-ld must take place right after either text
the architecture gets bigger, in terms of configurations, and less se- or img-hd has been terminated.
quential, then a declarative definition becomes more interesting.
4. Compilation through Heptagon/BZR
3.4. Policies
The behavioural programs defined by Ctrl-Fprovides compo-
Policies are expressed with high-level constructs for constraints nents an extra level of knowledge on the possible futures of the
on configurations, either temporal (in the sense of logical time) or component configuration, that is, it allows for the formal explo-
on attribute values. In general, they define a subset of all possible ration of the space of reachable configurations so as to avoid
global configurations, where the system should remain invariant: branches that may lead, in the future, to configurations violat-
this will be achieved by using the choice points in order to con- ing the stated policies. To that end, we provide a set of transla-
trol the reconfigurations. An intuitive example is that two compo- tion schemes allowing for the automatic translation from a Ctrl-
nent instances in parallel branches might have each several pos- Fdescription to the reactive language Heptagon/BZR. The transla-
sible configurations, and some of them have to be kept exclusive. tion process is detailed in the rest of this section.
This exclusion can be enforced by choosing the appropriate config-
urations when starting the components.
4.1. General FSA model structure

3.4.1. Constraints/optimization on attributes The component is the core of the Ctrl-Fdescription and can be
This kind of constraints are predicates and/or primitives of opti- modeled as an Heptagon/BZRnode, as shown in Fig. 8. The node
mization objectives (i.e., maximize or minimize) on component at- takes as input external request (r) and end notification (e) sig-
tributes. Listing 9 illustrates some constraints and optimization on nals, and a set of events {v1 , . . . , vk }, which corresponds to the
component attributes. The first two policies state that the overall event types the component in question (comp) listens to. As out-
fidelity for component instance soccer should be greater or equal put, it produces a set of request (resp. end) signals {r1 , . . . , rm }
to 0.75, whereas that of instance politics should be maximized. (resp. {e1 , . . . , em }) for each configuration confi , for i ∈ [1, m], de-
Putting it differently, instance soccer must never have its content fined within the concerned component. In addition, it also returns
fidelity degraded, which means that it will have always priority a set of weights {w1 , . . . , wl }, for the attribute valuation for each at-
over politics. The third policy states that the overall consumption tribute in the component. The main node (comp in Fig. 8) may con-
should not exceed 5, which can be interpreted as a constraint on tain a contract in which a set of controllable variables {c1 , . . . , cq }
the physical resource capacity, e.g., the number of available ma- (in the case there is any choice point such as a behaviour with an
chines or processing units. alternative statement) and the reference to the set of stated poli-
cies ({p1 , . . . , pt }) in order for them to be enforced by the controller
3.4.2. Temporal constraints resulting from the DCS. The details on how policies are translated
Temporal constraints refer to logical time and take the form of are given in Section 4.3.
predicates on the order of configurations. These constructs might Component behaviours are modeled as a sub-node (bcomp in
be very helpful when there are many possible reconfiguration Fig. 8), which consists of an automaton describing the order and
paths (by either parallel or alternative composition, for instance), in conditions under which configurations take place. For this purpose,
which case the manual specification of such constrained behaviour it gets as input the same request (r), end (e) and event ({v1 , . . . , vk })
102 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112

e_conf1), conf2 (r_conf2 and e_conf2) and conf3 (r_conf3

and e_conf3). Regarding its body (lines 12–25), znn comprises
one instance of the node that models the behaviour (bznn, line
20) and three instances of node appserver (lines 21–23). The re-
quest and end signals for these instances can be derived from the
request and end signals for configurations (lines 13–18). At last,
attributes are values based on the values of attributes of the in-
stances of node appserver (line 24).

4.2. Behaviours

For each program in Ctrl-F, we need to construct a FSA model,

in Heptagon/BZR, of all its possible behaviours. We translate each
behaviour statement defined inside another behaviour as a sub-
automaton, hierarchically decomposing the whole behaviour into
smaller pieces, down to a configuration.

4.2.1. The top-most behaviour

The top-most automaton i.e.,the automaton modeling the whole
behaviour consists of a two-state model, as depicted in Fig. 9 (a).
The automaton is in state Idle when the component does not take
part in the current configuration. Upon a request signal (r), it goes
to Active state, from where it can go back again to Idle state again
Fig. 8. Translation scheme overview.
upon an end signal (e). Active state accommodates a behaviour
statement itself, which is itself modeled as a sub-automaton of
signals of the main node. As a result of the reaction to those sig- state A.
nals, it produces the same signals for requesting ({r1 , . . . , rm }) and
ending ({e1 , . . . , em }) configurations as the weights ({w1 , . . . , wl }) 4.2.2. Statements
corresponding to the attributes valuation in the current state (con- The automaton that models the statement when-do (cf.
figuration) of the behaviour. We provide further details on the Fig. 9(b)) consists of an initial state B corresponding to the first
translation of behavioural statements in Section 4.2. Lastly, there behaviour statement to be executed. The automaton goes to state
might also be some other sub-nodes ({sub1 , . . . , subn }) referring Bi (corresponding to the execution of the next behaviour) upon a
to components instantiated within the concerned component, i.e., signal (event) vi while producing signals for requesting the initia-
comp. They have interfaces and contents which are structurally tion of to the next behaviour (r _bi ) and the termination (e_b) the
identical to those of the main node. That is to say, that sub- current one (for 1 ≤ i ≤ n). It is important to notice that upon two
nodes may have, in turn, a contract, a behaviour sub-node and events at the same time, a priority is given according to the order
a sub-node per component instance defined inside it. It is note- behaviours are declared. For instance, if v1 and v2 triggers, respec-
worthy that the request (rsubi ) and end (esubi ) signals for a sub- tively, behaviours B1 and B2 , then B1 will be triggered if declared
component subi ∈ {sub1 , . . . , subn } are defined as equations of re- before B2 .
quest and end signals. {r1 , . . . , rm } and {e1 , . . . , em } are respectively Both behaviour statements case and alternative can be modeled
the sets of request and end signals for the configurations conf1 , . . . , by the automaton shown in Fig. 10. As the sub-behaviour state-
confm to which component subi belongs. That means that a sub- ments should be executed at the very first instant upon the re-
component subi will be requested if any configuration it belongs quest of the case or alternative statement, the automaton must be
to is also requested (r1 ∨ · · · ∨ rm ) and none of them is terminated composed in parallel with the automaton modeling the main be-
¬(e1 ∨ · · · ∨ em ), which avoids emitting a request signal for an al- haviour (inside node bcomp, in Fig. 8). Hence, a case or an alter-
ready active component. The same applies for its termination. native statement is modeled as a simple state inside the (super)
Listing 11 shows an excerpt of Heptagon/BZRmodel for com- automaton in the hierarchy that models the main behaviour. Upon
ponents Znn (lines 12–27) and AppServer (lines 1–10). For the a request to those statements (signal r), the main automaton emits
appserver node, besides the request and end signals, it gets as a request signal r that will trigger a transition from state W to the
inputs the events of type oload and uload (line 1). As out- next state (B1 or B2 ) according to variable c. Then it can go either
put, it produces request and end signals for configurations text to another behaviour, if another r is emitted and c states so; or
(r_text and e_text), img-ld (r_ld and e_ld) and img-hd back to W if an end signal (e ) is emitted.
(r_hd and e_hd), apart from the weights, i.e., attribute valua- There are two differences between the use of this automaton
tions (fidelity and consumption). As the behaviour of com- for a case or an alternative statement. First, for the case state-
ponent AppServer is composed of two alternative compositions, we ment, more than two branches are allowed, so there might be
need to equip the node with a contract (lines 2–4), which enforces more states (B1 , B2 , . . . , Bn ) referring to each branch as well as their
properties p1 and p2 defined within the node (lines 7 and 8) (cf. corresponding conditions c1 , c2 , . . . , cn , which was omitted here
Listing 10). To that, we need to define two controllable variables for readability reasons. Second, for the alternative statement, the
c1 and c2, which are used inside the sub-node bappserver conditions ci will be considered as controllable variables in Hep-
(line 6), which in turn, encompasses the automata modeling the tagon/BZR. Thus, a DCS should be performed to guarantee that the
component’s behaviour. The textual representation is omitted here stated policies are not violated.
due to space limitation and for readability reasons, but the graph- The automaton model for the do-every statement is shown in
ical representation is depicted in Fig. 12. Node znn has a very Fig. 11(a). It consists of a single-state automaton, which means that
similar interface as appserver, except that it produces as output it starts by directly executing statement B. It has a self-transition at
request and end signals for configurations conf1 (r_conf1 and every occurrence of signal s, while emitting end (e_b) and request
 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112 103

Listing 11. Heptagon/BZR code for Znn and AppServer.

Fig. 9. FSA modeling: (a) Lifecycle; (b) When-Do.

Fig. 12. Translation of the component AppServer behaviour.

4.2.3. Znn.com Example

Fig. 12 illustrates the translation for the AppServer component
behaviour defined in Listing 7. More precisely, the behaviour is
translated as a Heptagon/BZRnode that is used within the node
appserver in Listing 11. The Heptagon/BZRnode consists of a paral-
lel composition of two automata: one to model the behaviour itself
(on the left-hand side), and another to model the alternative sub-
behaviour statement (on the right-hand side). The first automa-
Fig. 10. Parallel composition of automata modeling the main behaviour and the
Case/Alternative statement. ton corresponds to the top-most automaton, as the one shown in
Fig. 9(a). The active state comprises a sub-automaton represent-
ing the do-every statement, which starts by state B and restarts
it at every occurrence of events oload (overload) or uload (under-
load) while emitting at the same time request and end signals (r _b
and e_b, respectively). The request signal (r _b) is used by the sec-
ond automaton in order to enable transitions to states representing
configurations (txt, ld and hd) according to the controllable vari-
ables c1 and c2 , while emitting proper request signals (r _txt or
r _ld) for the next configurations and end signals (e_txt or e_ld) for
the current one. The end signal (e_b), on the other hand, is used to
enable transitions to other or even the same configuration, in the
presence of the request signal, or to the waiting state W, in the ab-
Fig. 11. Automata modeling: (a) the Every and (b) Parallel statements.
sence of the request signal. It should be mentioned that due to the
lack of space, we omitted the outgoing and incoming transitions of
state hd (configuration img-hd).
(r _b) signals, that is, statement B is re-executed at every occur- In the generated executable code, the output of those automata
rence of event s. Finally, Fig. 11(b) presents the model for the Paral- will be connected to pieces of code dedicated to trigger the ac-
lel statement : simply in the parallel composition of sub-automata. tual reconfigurations. For instance, the presence of signals r _ld and
104 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112

if conf2 terminates before conf1 (e2 ∧¬e1 ) or if conf2 termi-

nates before conf1 has started. The observer that models the con-
straint between (conf1 between (conf2,conf3)) is depicted
in Fig. 13(b). Similarly, r1 , r2 and r3 (resp. e1 , e2 and e3 ) correspond
to the request (resp. end) signal for configurations conf1,conf2
and conf3, respectively. The automaton goes to the error state (E)
whenever configuration conf3 is started (r3 is emitted) after con-
figuration conf2 (e2 ), except when configuration conf1 is started
Listing 12. Example of constraint on attribute in Heptagon/BZR.
and terminated (r1 and e1 ) in the between.

5. Compilation tool-chain and runtime integration

5.1. Target platform

Despite the fact that our contribution is technology-agnostic, for

the sake of proof-of-concept, we rely on FraSCAti (Seinturier et al.,
2012), a Java-based Service Component Architecture (SCA) 1 mid-
dleware, which provides mechanisms for runtime reconfiguration.
The objective is that a middleware platform implementing the SCA
specifications takes care of component implementation, interop-
erability and communication details, so architects and developers
can focus only on the architecture. The FraSCAti Runtime is itself
Fig. 13. Observer automata for temporal constraints.
conceived relying on the SCA model, that is, it consists of a set of
SCA components that can be deployed a la carte, according to the
e_t xt will trigger the reconfiguration script that changes the con- user’s needs. For instance, one can instantiate the frascati-fscript
tent fidelity of given component from text to img-ld (cf. Section 5). component, which provides services allowing for the execution of
an SCA-variant of FPath/FScript (David et al., 2008), a DSL for in-
4.3. Policies trospection and dynamic reconfiguration of Fractal components.
At this point, it is important to notice the complementarity
4.3.1. Constraints/optimization on attributes of Ctrl-F and FraSCAti as both rely on similar Fractal-like compo-
For illustration , Listing 12 shows how the last policy of nent model. FraSCAti is used as target middleware platform bridg-
the Main component (Listing 9, line 4) is translated into Hep- ing application and system levels in a distributed way, whereas
tagon/BZR. This constraint is defined as an equation (line 8) Ctrl-Fprovides support for describing high-level for controlling
that depends on the integer outputs soccer_consumption and self-adaptive components with formal guarantees on adaptive be-
politics_consumption, which are produced by the respective haviours. Put differently, FraSCAti without Ctrl-Fis a middleware
instances of node znn (lines 6 and 7). The equation is hence used (or system) without high-level self-adaptive language with control
in the enforce block of the contract (line 3). support for decision-making with formal guarantees. Conversely,
Although the declaration of optimization objectives are cur- although technology-agnostic, Ctrl-Fwithout FraSCAti is a self-
rently not supported by Heptagon/BZR, one may model a one-step adaptive language and reconfiguration (decision-making) mecha-
optimization directly within the DCS tools Heptagon/BZRrelies on nism without system, or a middleware to communicate with the
Marchand et al. (20 0 0) and Berthier and Marchand (2014). Please system level.
see Dumitrescu et al. (2010) for more details.
5.2. Compilation tool-chain
4.3.2. Temporal constraints
Temporal constraints refer to the logical time events occur, As can be seen in Fig. 14, the compilation process can be
i.e.,they are constraints on the logical order of configurations. They split into two parts: (i) the reconfiguration logics and (ii) the
are modeled in Heptagon/BZRby a set of Boolean equations of re- behaviour/policy control and verification. The reconfiguration log-
quest (r) and end (e) signals that are emitted by automata mod- ics is implemented by the ctrlf2fscript compiler, which takes as
eling behaviours. For simple constraints like conf1 succeeds input a Ctrl-Fdefinition and automatically generates as output a
conf2 (resp. conf1 precedes conf2), just a predicate like script containing a set procedures allowing going from one con-
e_con f 2 ⇒ r _con f 1 (resp. e_con f 1 ⇒ r _con f 2) suffices. However, figuration to another. To that end, we rely on existing differenc-
whenever there is a need for keeping track of the sequence of sig- ing/match algorithms for object-oriented models (Xing and Strou-
nals (to request and/or end configurations), the use of observer au- lia, 2005). The script is later on used by a FraSCAti component
tomata is needed. Observer automata are placed in parallel with (Manager) in charge of controlling the actual running component
the behaviour automata, and generated in Heptagon/BZR as part software system. Listing 13 shows an example of script describing
of the contract. The principle is to have an automaton that ob- a reconfiguration from configuration conf1 to conf2 of Znn com-
serves the sequence of signals that leads to a policy violation and ponent. In this example, the script just wires the reference of in-
state that the state resulting from that sequence (an “error” state) stance lb:LoadBalancer to the as2:AppServer instance’s service, then
should never be reached. Again, here we can rely on the enforce it starts the instance as2:AppServer.
block of a Heptagon/BZR contract. The DCS objective is the invari- The behaviour control and verification part starts with the
ance of the state set deprived of those where the variable error is ctrlf2ept compiler, which takes as input a Ctrl-Fdefinition and pro-
true. vides as output a synchronous reactive program in Heptagon/BZR.
Fig. 13(a) depicts an observer that models the policy dur- This code is given as input to the Heptagon/BZRcompiler, which
ing (conf1 during conf2), where r1 and r2 (resp. e1 and e2 )
correspond to the request (resp. end) signal for configurations
conf1 and conf2, respectively. The error state (E) is reached 1
http://www.oasis-opencsa.org.
 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112 105

the appropriate script that embodies the reconfiguration actions

(line 5) by matching the configurations that have to be stopped
and started, with the reconfiguration scripts previously generated
by ctrlf2fscript. Finally, the matched script can then be execute (line
6) by the middleware platform. For instance, if we have as result of
the step method . . . , e_conf1 = true, r_conf2 = true, . . . , the Man-
ager knows that a reconfiguration taking the application from conf1
to conf2 is needed, which is exactly what the FScript conf1_conf2
does (cf. Listing 13).

5.3. Wrapping the compilation result into SCA components

We wrap the control loop logics into three components, which

are enclosed by a composite named Manager. Component Even-
tHandler exposes a service allowing itself to be sent events (e.g.,
oload and uload). The method implementing this service is defined
as non-blocking so the incoming events are stored in a First-In-
Fig. 14. Ctrl-F compilation chain. First-Out queue. Upon the arrival of an event coming from the
Managed System (e.g., Znn.com), component EventHandler invokes
the step method, implemented by component Architecture Analyser.
The step method output is sent to component Reconfigurator, that
encompasses a method to find the proper reconfiguration script to
be executed.

6. Case studies

Listing 13. Reconfiguration logics in FScript.

This section shows the application of Ctrl-Fin two different sit-
uations. We first present an adaptive scenario by simulating the
Znn.comcase study, whose Ctrl-Fmodel has been already detailed
throughout the previous section. Then when provide a second case
study, in which we apply Ctrl-Fin order to control an application
with a workflow of mutually exclusive tasks.

Listing 14. Control loop sketch. 6.1. Case study 1: Znn.com

We simulate the execution of the two instances of Znn.com

produces code for the model checking and discrete controller application, namely soccer and politics, under the administration
synthesis tool. Heptagon/BZRis currently integrated with ReaX of the Manager presented in the previous section, to observe the
(Berthier and Marchand, 2014) tool. Thus, if the Heptagon/BZRcode control of reconfigurations taking into account a sequence of in-
translated from the Ctrl-Fdescription contains a contract with con- put events. The behaviours of components AppServer and Znn are
trollable variables, the tool generates a controller (if there is any) stated in Listings 7 and 8, respectively. The policies of component
such that the stated properties are guaranteed. Conversely, if there AppServer are defined in Listing 9, while those of component Main
is no need for controller synthesis, the corresponding tool simply are given in Listing 10.
verifies the correctness of the Heptagon/BZR program. The Hep- As it can be observed in the first chart of Fig. 16, we sched-
tagon/BZRprogram corresponding to the target system model along uled a set of overload (oload) and underload (uload) events (ver-
with the generated controller, if that is the case, are compiled tical lines), which simulate an increase followed by a decrease
again with the Heptagon/BZRcompiler. of the income workload for both soccer and politics instances.
The result of the compilation of an Heptagon/BZRcode is a se- Hence, the components lb:LoadBalancer constituting components
quential code in a general-purpose programming language (in our soccer:Znn  and politics:Znn are programmed to emit those events
case Java). It means that, thanks to the ctrlf2ept and all the other at the corresponding steps. The events will be handled by the Man-
compilers of the compilation tool-chain, from a Ctrl-Fprogram, one ager, that is, the EventHandler handles the events by invoking the
can automatically generate a Java, C or OCaml executable code. The step method with oload=true or uload=true, accordingly. The other
generated code comprises two methods: reset, which initializes charts correspond to the overall resource consumption, the over-
the internal state of the program; and step, which is executed at all fidelity, and the fidelity level (i.e., configurations text, img-ld or
each logical step to compute the output values based on a given img-hd) of the three instances of component AppServer contained
vector of input values and the current state. The methods are en- in both instances of component Znn.
capsulated by the FraSCAti component that controls the managed As the workload of politics increases, an event of type oload oc-
system (Manager) and they are typically used by first executing curs at step 2. That triggers the reconfiguration of that instance
reset and then by enclosing step in an infinite loop, in which from conf1 to conf2, that is, one more instance of AppServer is
each iteration corresponds to a reaction to an event (e.g.,oload or added within the Znn instance politics. We can observe also the
uload), as sketched in Listing 14. The step method returns a set progression in terms of resource consumption, as a consequence of
of signals corresponding to the start (e.g., r_conf2) or stop (e.g., this configuration. The same happens with soccer at step 3, and is
e_conf1) of configurations as a response to the input events (line repeated with politics and soccer again at steps 4 and 5. The differ-
4). In other words, the signals indicate exactly which configura- ence, in this case, is that at step 4, the politics instance must re-
tions should be started and stopped at every logical instant (e.g., at configure (to conf3) so as to cope with the current workload while
every occurrence of either event oload or uload). Thus, we can find keeping the overall consumption under control. In other words, it
106 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112

Fig. 15. Manager prototype wrapping the control loop.

Fig. 17. An Example application workflow, showing parallel and alternative

branches.

that is, it releases one instance of AppServer (as3). The same hap-
pens with soccer at step 10, which makes room on the resources
and therefore allows politics to bring back the fidelity level of its
as2 to img-ld. Note that it cannot go directly to from text to img-
hd, even if there are enough resources for that. This is repeated at
steps 13 and 14 for instances politics and soccer respectively, bring-
ing their consumptions at the same levels as in the beginning.

6.2. Case study 2: Mutual exclusive tasks

The integration of Ctrl-Fwith DCS allows for decision-making

with formal guarantees. Moreover, it allows for predictive decision-
making in the sense that configurations can be chosen some steps
ahead in order to avoid going into adaptive program branches lead-
ing to configurations that violate the defined policies. In spite of
the fact that Znn.comis quite illustrative to show the core of Ctrl-
F, it cannot deeply exploit the predictive aspect of Ctrl-Fdecision-
Fig. 16. Execution of the Znn.com adaptation scenario.
making. This sub-section presents a case study that addresses a
workflow-like behaviour, decomposed in sequences of behaviours
executed in parallel, which allows us to focus more on predictive
forces the AppServer instances as2 and as3 to degrade their fidelity decision-making.
level from img-hd to img-ld. It should be highlighted that although Fig. 17 presents the example of a workflow, where boxes rep-
at least one of the AppServer instances (as2 or as3) could be at that resent computing tasks to be executed, and where links are their
time at maximum fidelity level (i.e., img-hd), the knowledge on the execution dependencies from left to right. The application has par-
possible future configurations guarantees the maximum overall fi- allel branches (indicated by a black dot), where all are executed
delity for instance soccer to the detriment of a degraded fidelity starting at the same time. Alternative branches (indicated by a
for instance politics, while respecting the temporal constraints ex- white dot) are also present: one and only of them will be exe-
pressed in Listing 10. Hence, at step 5, when the last oload event cuted, to be chosen by a controller according to the environing
arrives, the fidelity level of soccer instance is preserved by gradu- states and to a given global control objective coordinating parallel
ally decreasing that of politics, that is, both instances as2 and as3 activities around constraints. These alternatives correspond to the
belonging to the politics instance are put in configuration text, but fact that, in a software component-based system, a given service or
without jumping directly fromimg-hd. At step 9, the first uload oc- functionality can have different implementations, or can use differ-
curs as a consequence of the workload decrease. It triggers a re- ent resources. Hence, each task corresponds to the execution of a
configuration in the politics instance as it goes from conf3 to conf2, components assembly, or possibly hierarchically to a sub-workflow.
 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112 107

When the current situation is that task Tij , the jth in branch i, is
active, then upon reception of event eij , the reaction is to go to the
next task in sequence in the flow (there can possibly be several
tasks to start if there is a parallel branch). This is done by a re-
configuration from the current global configuration, towards a new
configuration where the sub-assembly corresponding to the termi-
nated task is replaced by the sub-assembly corresponding to the
new ones.

6.2.1. Control problem

In many cases, constraints forbidding the concurrent execution
of some tasks e.g., because of their combined consumption of a
resource exceeding available capacity, need to be defined. In this
case the control must enforce their exclusivity. In this example,
T13a2 and T22b2 must be kept exclusive. Therefore, a controller su-
pervising the reconfigurations of the system should make the ap-
propriate choices when choosing between alternative implementa-
tions of services. An alternative branch should be entered only if
there is no risk that one of its tasks would have a conflict with
another task in a parallel branch. This choice can be solved simply
by having a semaphore-like mechanism, such that the first of the
two tasks to be started would take the resource, and the other one,
if started before the first one is terminated, must wait for the re- Listing 15. Architectural description of components Application in Ctrl-F.
source to be released again. However, this supposes that the start-
ing of the tasks is controllable, which is not necessarily the case: Table 3
it can be related to an event that is uncontrollable and must be Workflow configurations’ consumption levels.
answered immediately. Configuration r1 r2 Configuration r1 r2
In our case, we consider that only the alternative branches
T0 0.5 0.2 T14 0.25 0.0
choice points are controllable. Hence, when the progression in the T11 0.4 0.0 T21 0.0 0.15
workflow reaches a choice point in an alternative branching, for T12 0.2 0.0 T22a 0.0 0.3
example b in Fig. 17, then the controller must choose the branch T13a1 0.3 0.0 T22b1 0.0 0.2
by evaluating the global situation. If there is an exclusivity con- T13a2 0.7 0.0 T22b2 0.0 0.6
T13b 0.35 0.0 T23 0.0 0.25
straint then:
• if the other choice point a has already been passed then:
– if the branch T13a has been chosen then: stating that the sum of the consumptions of both resources must
∗ if the other task has not been passed yet there is a risk of not exceed a certain capacity threshold. We also define another
a conflict, therefore the controller must choose at point policy stating that the sum of the resource consumptions should
b for the branch T22a be minimized (line 28).
∗ else if it is terminated then no conflict can occur any- It is noteworthy that exclusive components/configurations could
more, and the choice is free at point b between T22a and be expressed in different ways. For instance, there could be two
T22b , sub-components (a and b) , each with a boolean attribute (r) spec-
– else if the branch T13b has been chosen (for some other rea- ifying whether the resource is used or not. Finally, a policy at the
son) then the choice is free at point b, composite level could make it explicit that a and b, regardless of
• else the choice is open on both sides, and can be decided ei- their behaviour must not access the resource r, i.e., ! (a.r and
ther randomly, or based on some other criterion like e.g., op- b.r). For pedagogical purposes, we decided to express the mu-
timization related to costs of the alternative options. However, tual exclusion with numerical attributes and an explicit parallel
if the control for one alternative chooses to enter one of the behaviour, instead of two sub-components, which, when instanti-
branches featuring conflicting components, then this can con- ated, behave implicitly in parallel (e.g., the soccer and politics Znn
strain the choices allowed for the other alternative. instance in the Znn.comcase study).
This decision clearly has to take into account not only the cur- The Ctrl-F behaviour for the workflow is defined inside the be-
rent state of active components/configurations and their resource haviour block (line 22), which is detailed in Listing 16. It consists
consumption, but also the possible future evolutions which can be of an outside when-do statement (lines 2–16), comprising a parallel
predicted according to the structure in branches of the application statement, whose operator can be seen in line 10. Both branches of
behaviour. the parallel statement (lines 3–9 and 11–15) are composed of se-
quences of configurations with choice points. This sub-behaviours
6.2.2. Ctrl-FModel are modeled as a set of embedded when-do and alternative (lines
The workflow example presented above is described in Ctrl-Fas 5 and 12) statements.
shown in Listing 15. For sake of simplicity and readability, we con-
sider a single-component application containing two attributes (r1 6.2.3. Execution
and r2), which corresponds to the consumption of two resources This section shows how the component-based software system
(line 3). The component has several configurations (lines 7–20) in modeled in Ctrl-Fin the previous section reacts to different run-
which, we specify the levels of consumption of each resource (cf. time scenarios, i.e., sequences of input events. More precisely, we
Table 3 for the complete configurations’ specification). The events want to exploit three scenarios where the policy could be vio-
leading the system from one configuration to another are defined lated, which implicitly means a violation on the mutual exclusion
in line 5. The mutual exclusion is specified by a policy (line 25) constraint between configurations T13a2 and T22b2: (i) when the
108 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112

Listing 16. Workflow behaviour in Ctrl-F.

Table 4 Table 6
Workflow Evolution Under Scenario 1. Workflow Evolution Under Scenario 3.

Table 5 Tables 4–6 show how the system evolves in terms of reconfig-
Workflow Evolution Under Scenario 2.
uration in response to a sequence of input events. The first row
shows the incoming events at each logical time ti . The second to
the thirteenth rows indicate whether each configuration is active,
whereas the fourteenth row shows the sum of both attributes r1
and r2.
For the first scenario (cf. Table 4), the sequence e0 , e11−12 and
e12−13 leads the system to the choice point a (at step t4 ) before
the choice point b, which makes the controller pick the alternative
that contains the configuration T13a1 since it minimizes the sum
of attributes r1 and r2. Upon event e21−22 , the system is led to
the choice point b (at step t5 ) and the controller is forced to pick
the alternative containing configuration T22a so as to respect the
exclusion with T13a2 and thus avoid an eventual policy violation
(r1 + r2 > 1.0).
Conversely, the sequence e0 and e21−22 /e11−12 (cf. Table 5) takes
the system first to the choice point b (at step t3 ), which makes
the controller choose the alternative containing T22b1, since it
minimizes the resource consumption at next step. The next event
(e12−13 ), at step t3 , lead the other branch to choice point a (at step
t4 ). Since, at that point in time, configuration T22b2 has not yet
passed, the controller is forced to pick T13b in order to respect the
mutual exclusion.
choice point a is evaluated before choice point b; (ii) when the Finally, for the third scenario (cf. Table 6), upon events e0 ,
choice point b is evaluated before choice point a; and when both e11−12 , e12−13 / e21−22 , the system is lead to both choice points
choice points are evaluated at the same time. We consider the val- a and b at the same time, i.e., at step t3 . At that point, the de-
ues for attributes r1 and r2 for each configuration as shown in cision taken by the controller is performed at the same time for
Table 3. both choice points so that the mutual exclusion is respected and
 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112 109

the sum of resources is minimized. Thus, based on those criteria, extremely reactive in the sense that they take decisions almost in-
for one branch, the configuration T13b is picked, whereas the al- stantaneously.
ternative containing configuration T22a1a is chosen for the other We also have some perspectives to mitigate those shortcomings
branch. (cf. Section 8). First, it may be possible to perform modular DCS,
Although the scenarios above illustrate situations where either which consists in decomposing the DCS problems within Ctrl-Fand
T13a2 or T22b2 Â are executed at the same time, there might be Heptagon/BZRinto smaller ones so as to break down the combina-
scenarios where the alternative statement of one branch is exe- torial complexity. Moreover, we might as well consider DCS in the
cuted entirely before the one of the other branch. This means that context of self-adaptive controllers, that is, controllers that can be
the controller may allow the execution of both T13a2 and T22b2 updated in case the system model (e.g.,the possible configurations)
as soon as the alternative behaviours are not executed at the same changes at runtime, while still providing formal guarantees.
time.
6.3.3. Input events and attribute values
6.3. Discussion and threats to validity In both case studies, the input events are intended to simu-
late critical situations and assess how the controller can manage
6.3.1. Comparison with other approaches them. For instance, this the case when a competition for resources
In spite of the fact that Znn.com is widely known in the self- between the two instances of Znn is simulated in order to ob-
adaptive systems’ community, it cannot yet be considered as a serve how the policy constraining some sequences of configura-
benchmark. Also, most of the approaches that use Znn.com as case tions text, img-ld and img-hd is enforced; or when parallel tasks
study focus more on the numerical aspects of adaptation (e.g., consume resources that are mutually exclusive in order to assess
number of replicas kept under a certain threshold while maxi- if the branches are chosen (in advance) accordingly. Changing the
mizing fidelity), but do not provide support for the combinato- order in which events occur would not affect the managed sys-
rial exploration/management and guarantees, going until the pre- tem itself, but would certainly affect our perception on these nu-
dictive aspects, that are key-features of Ctrl-F. On the other hand, ances that are important for understanding possible systems’ mis-
Ctrl-Fdoes not support continuous/numerical control. Therefore, it behaviours when they are not controlled. Lastly, the values to be
is very hard to quantitatively compare discrete/logical approaches assigned to the attributes were also chosen in order to promote
with continuous/numerical ones. In this context, the case studies the need for adaptation, due to either mutual exclusion and/or
discussed in this section are useful to evaluate qualitative rather scarcity of resources. For example, much greater consumption val-
than quantitative aspects like what the proposed language is in- ues in Znn.com components might make the DCS fail in finding a
tended to describe and what the generated controllers are capable solution, whereas much lower consumptions would find too per-
of guaranteeing. missive solutions, making AppServer component instances to stay
From the language perspective, both case studies show how indefinitely in configuration img-hd, dismissing eventually the need
Ctrl-Fcan help to define, in high-level and descriptive manner, for control.
any kind of component-based software system requiring self-
adaptation. Indeed, they enable the illustration of a range of Ctrl- 7. Related work
Fconstructs like loop (do-every), alternative (|), parallel (||) and
sequence (when-do). From the control-theoretical point of view, Self-adaptation has been given much attention over the past
the adaptation scenarios presented as part of the case studies years and has been associated to many different research fields.
show in a pedagogical way, how controllers obtained from Ctrl- The research roadmap resulting from the 2010’s edition of the
Fcompilation to Heptagon/BZRand DCS are capable of controlling Dagstuhl Seminar on Software Engineering for Self-Adaptive Sys-
reconfigurations by involving an exploration of future branches, tems (de Lemos et al., 2013) points characterisation of the design
from the current global advancement state, taking into account all space, decentralization of feedback loops and validation and veri-
possible event interleavings, and possible control choices in order fication among the major challenges to be faced by self-adaptive
to guarantee the stated policies. software systems. Brun et al. (2009) pointed out the importance
of understanding the notions of feedback loops that can be found
6.3.2. Scalability and on-the-fly DCS in different areas (e.g., control theory and bio-inspired systems) to
As previously stated, the formal exploration performed by the engineer self-adaptive systems. Kramer and Magee (2007) high-
DCS is rather at design-time than at runtime, as its complexity lights the pertinence of building self-adaptive software systems
can be exponential in the number of configurations. That also re- at the architectural level and took inspiration from robotics (Gat,
quires a previous knowledge on all possible configurations of the 1998) to propose a three layer reference model (component con-
system, since it performs computation over an exact previously trol, change and goal management) for self-managed systems. All
known state space, which is used to control the dynamics of the these seminal work have, to a certain extent, inspired the way we
system at runtime as a means to provide guarantees. Note that this designed Ctrl-Fand structured its underlying runtime tooling.
level of guarantee is not achieved by more dynamic approaches, In the domain of Component-based Software Development,
i.e.,by approaches where the decision-making is performed on-the- runtime adaption is classically achieved by first relying on ADLs
fly. It should be reminded that in our approach, adaptation deci- such as Acme (Garlan et al., 20 0 0) or Fractal (Bruneton et al., 2004)
sions are taken based upon observation of the current state and for an initial description of the software structure and architecture,
past events, but also prediction of possible futures from the cur- then by specifying fine-grained reconfiguration actions with dedi-
rent state. The manual design and writing of a control program cated languages like Plastik (Batista et al., 2005) or FPath/FScript
doing this correctly would be very tedious and error-prone. Espe- (David et al., 2008), or simply by defining Event-Condition-Actions
cially, obtaining a correct controller (which would require verifica- (ECA) rules to lead the system to the desired state. In Luckey et al.
tion by model-checking anyway) is not the only goal: it is impor- (2011), the authors propose AdaptCases, a domain-specific mod-
tant to have a maximally permissive controller, in order to keep eling language that relies on UML to formally specify adaptivity,
the maximum flexibility in the execution and be minimally con- in which adaptations are also modeled in an ECA/threshold based
straining by forbidding alternative branches only when necessary. fashion.
Furthermore, since DCS is performed off-line and the solutions are A harmful consequence is that the space of reachable config-
already computed and compiled away, the resulting controllers are uration states is only known as side effect of those reconfigura-
110 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112

tion actions, which makes it difficult to ensure correct adaptive In Calinescu et al. (2012), the authors advocate the employment
behaviours. Moreover, a drawback of ECA rules is that, contrary to of runtime quantitative verification to formally analyse correctness,
Ctrl-F, they cannot describe sequences of configurations. Even so, reliability and performance of systems exhibiting stochastic be-
ECA rules can be expressed in Ctrl-F with a set of when-do (for the haviours, in which probabilities and temporal properties guide the
E part) and case (for the C and A parts) statements in parallel. navigation through states (configurations). An innovating aspect of
FORMS (FOrmal Reference Model for Self-adaptation) (Weyns the approach is that the overhead incurred by verification at run-
et al., 2012) is a unified model for specifying distributed self- time can be mitigated by pre-computing probabilities as symbolic
adaptive systems. The model is the result of the combination of expressions (Filieri et al., 2011), which is, to a certain extent, sim-
three concerns: computation reflection, to facilitate the separation ilar to what is done in the DCS technique. However, our approach
between environment, managed subsystems and adaptation rea- differs in some aspects: first, our model is deterministic and we
soning subsystem; distribution, which eases the specification of focus on the possible future configurations to avoid potential bad
coordination mechanisms among different distributed self-adaptive branches of the adaptive program; further, we also provide an end-
elements; and MAPE-K, to formally define the control loop logics. to-end solution, from a high-level DSL to the actual manager that
While FORMS is intended to serve as a (generic) reference model enacts self-adaptive behaviours in the target system.
to specify self-adaptive systems of any domain, our approach dif- Kouchnarenko and Weber (2014) propose the use of tempo-
fers focus on a specific domain (i.e.,component-based architecture). ral logics to integrate temporal requirements to adaptation poli-
Besides, we provide transformation mechanisms allowing for the cies in the context of Fractal components (Bruneton et al., 2004).
automatic generation of correct-by-construction managers out of a The policies specify reflection or enforcement mechanisms, which
high-level domain-specific model. refer respectively to corrective reconfigurations triggered by un-
Rainbow (Garlan et al., 2004b) provides an autonomic frame- wanted behaviours, and avoidance of reconfigurations leading to
work for Acme components (Garlan et al., 20 0 0). A DSL called unwanted states. While in those approaches, enforcement (resp.
Stitch is used to express autonomic behaviours (called strategies) decisions over strategies’ branches) and reflection are performed at
in a tree-like manner. Branches in strategies are selected online runtime, in our approach, the decision-making is obtained in an off-
by a utility-based algorithm according to runtime conditions. At line manner, through the reactive language Heptagon/BZR and by
the end (when it gets to a leaf in the tree), a strategy is eval- performing DCS. This way, the exploration of behavioural programs
uated as successful or failed and this information is used to im- is compiled away, producing as result a maximal permissive and
prove the selection algorithm. From the language perspective, our correct-by-construction controller that enforces correct autonomic
language provides an interesting set of behavioural statements in- behaviours. That can be seen as a tremendous advantage, since
cluding alternative and parallel, as well as the event-based ones the formal exploration can be very costly and exponential in the
like every and when-do. That makes Ctrl-Fmore expressive in terms number of possible configurations to be performed online, which
of behavioural definition. Furthermore, thanks to the Ctrl-F’s for- is even more complex when the control is required to be least re-
mal model in the reactive language Heptagon/BZR, it is possible strictive. Conversely, due to model incompleteness and uncertain-
to ensure correct adaptation behaviours either by verification or ties inherent to unpredictable environments, assumptions taken at
control, that is, by the generation of correct-by-construction con- design time may no longer hold at runtime.
trollers that enforce such behaviours. One way to mitigate this limitation is to have a multi-tier con-
A body of work (Arshad and Heimbigner, 2005) on how to trol, as proposed by D’Ippolito et al. (2014). The idea is that one
plan a set of actions that safely lead component-based systems can define multiple models and controllers associated to differ-
to a target configuration. In Boyer et al. (2013), the authors pro- ent levels of assumptions (from the least to the most restrictive)
pose a robust reconfiguration protocol establishing proper orders and guaranteeable functionalities. The level of control is then de-
of reconfiguration operations (start, stop, wire, etc.) based on a termined according to the validity of assumptions at runtime. The
contract that has to be fulfilled (e.g.,architectural invariants). This same research group also proposes an approach for controller syn-
protocol is fully formalized and proved with Coq2 proof assistant. thesis of event-based systems (D’ippolito et al., 2013) and more
da Silva and de Lemos (2011) present a test-driven approach for recently a method to dynamically update synthesized controllers
self-adaptive component-based architecture, which consists in gen- (Nahabedian et al., 2016). These approaches perform the controller
erating reconfiguration plans incrementally and checking whether synthesis by generating executable automata out of temporal log-
the components added to a given configuration, at runtime, are ics formulae, i.e.,it does not contemplate the notion of controllable
able to communicate with the other components. In Tichy and and incontrollable. That kind of synthesis differs from the supervi-
Klöpper (2012), graph transformations are used to specify archi- sory control of discrete event-based systems that is used in our
tectural reconfigurations, which are then translated into the Plan- approach, in which from a model (e.g.,automate), from a set of
ning Domain Definition Language (PDDL) (Fox and Long, 2003). controllable and incontrollable input variables and an control ob-
While using PDDL makes it possible to use self-adaptation plan- jective (e.g.,invariance, reachability), a controller that restrains the
ning tools, graph transformations formalisms allow for verification system is synthesized. Still regarding controller synthesis, in Filieri
and code-generation to be executed at runtime. MechatronicUML et al. (2015); 2014). Filieri et al.propose a methodology to auto-
(Becker et al., 2014) also relies on UML and the underlying formal matically generate continuous controllers with formal guarantees
verification tools to prevent reconfigurations operations leading to from a set of high-level specifications, which differs from the DCS
unsafe configurations. In summary, those approaches focus on how used in our approach in that the former deals with numerical and
to plan a set of actions that safely lead systems to a target config- continuous variables, whereas in this work we focus on controlling
uration. Hence, they are complementary to ours in the sense that logically the models corresponding to the behaviour programmed
our focus is on the choice of a new configuration and its control within components.
as the behavioural program progresses. Once a new configuration In Morin et al. (2009) and Parra et al. (2009), feature models are
chosen, we rely on existing mechanisms to determine the plan of used to express variability in software systems. At runtime, a res-
actions actually leading the system from the current to the next olution mechanism is used for determining which features should
configuration. be present so as to constitute configuration. Those approaches rely
on Model-Driven Engineering to ease the mapping between fea-
tures and architectures as well as to automatically and dynami-
2
http://coq.inria.fr. cally generate the adaptation logics, i.e., the reconfiguration actions
 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112 111

leading the target system from the current to the target configura- branches, which, in the future, may lead the system to unsafe
tion. In the same direction, Pascual et al. (2013) propose an ap- states.
proach for optimal resolution of architectural variability specified
in the Common Variability Language (CVL) (Haugen et al., 2013). A 8.2. Contributions
major drawback of those approaches is that in the adaptation log-
ics specified with feature models or CVL, there is no way to define We tackled this problem by first proposing a high-level domain-
stateful adaptation behaviours, i.e., sequences of reconfigurations. specific language, named Ctrl-F, which allows for the description
In fact, the resolution is generally performed based on the current of adaptation behaviours and policies of component-based archi-
state and/or constraints on the feature model. On the contrary, in tectures and then by relying on discrete control to ensure correct
our approach, in the underlying reactive model based on FSA, de- adaptive behaviours. Concretely, we rely on Heptagon/BZR, a Finite
cisions are taken also based on the history and possible futures State Automata-based reactive language, to formally define Ctrl-F’s
of configurations which allows us to define more interesting and semantics. The compilation of Heptagon/BZRinvolves formal tools
complex behaviours, while providing guarantees on them. allowing for verification and Discrete Controller Synthesis (DCS),
As in our approach, in Bouhadiba et al. (2011), the authors which makes it possible to ensure correct adaptive behaviours of
also rely on Heptagon/BZR and DCS techniques to model auto- component-based software systems defined in Ctrl-F. While the
nomic behaviours in the context of Fractal components. An et al. DCS requires a previous knowledge of the system’ configurations
(2013) used Heptagon/BZR to achieve self-adaptation in the con- and may pose some combinatorial limitations, the synthesis is per-
text of partially reconfigurable FPGAs (Field Programmable Gate Ar- formed off-line, with no impact on the running system. Moreover,
rays). Although those approaches provide us with interesting in- that allows for more reactive (i.e.,quasi-instantaneous) decision-
sights on how adaptive behaviours can be formalized, there is no making as part of the adaptation process, while providing tool-
general method allowing for the direct translation from a high- support for managing the combinatorial configurations space, pre-
level description (e.g., ADL) to a synchronous reactive model. It dictive control with formal guarantees. To the best of our knowl-
means that for each new application, the formal model has to be edge, those features are not provided by current approaches in the
recreated. Moreover, reconfigurations are controlled at the level of state-of-the-art literature.
fine-grained reconfiguration actions (e.g., add/remove components This article extends our previous work (Alvares et al., 2015a;
and bindings), which can be considered time-consuming and dif- 2015b) by providing a detailed view on the Ctrl-Flanguage itself,
ficult to scale, especially for large-scale architectures. In compar- its compilation into Heptagon/BZRand its implementation and in-
ison, Ctrl-F proposes a set of high-level constructs to ease the tegration with FraSCAti, a Service Component Architecture middle-
description of adaptation behaviours and policies of component- ware platform. Besides, we applied Ctrl-Fto two cases studies and
based architectures. In addition, we propose an extensible Manager provided a rich discussion about its usefulness, applicability and
that bridges Ctrl-F and a real component platform. Delaval et al. limitations.
(2014) propose the use of components to embody autonomic man-
agers conceived with Heptagon/BZR. The idea is to have modular
8.3. Perspectives and future work
controllers that can be coordinated so as to work together in a co-
herent manner. The approach is complementary to ours: on the
The intrinsic combinatorial complexity of Discrete Controller
one hand, the approach does not provide means to describe be-
Synthesis raises some problems regarding the scalability of the ap-
havioural programs for those managers, although the authors pro- proach. One perspective to be explored to cope with this issue is
vide interesting intuitions on a methodology to do so. On the other
to decompose control problems specified in Ctrl-Fin a systematical
hand, our approach does not provide means for the specification
way, relying on the mechanisms of modular compilation and mod-
of the coordination among components’ controllers. We do believe ular DCS (Delaval et al., 2014). That may require some effort on
however that coordination is a major challenge that has to be tack-
both the language redefinition and the way it is translated to Hep-
led by any modular self-adaptive system. Hence, the integration
tagon/BZR. Another important aspect that should be investigated in
of coordination aspects to Ctrl-F and its behavioural formalization
this domain is the possibility to make the adaption policies them-
must be considered in future work. Moreover, modularity seems to
selves subject to change, in order to react to changes in operation
be an interesting perspective to mitigate the scalability issues due
conditions imposing other properties than the ones specified at de-
to state-space explorations.
sign time. In some contexts like in mobile computing, the presence
of components in the system can change, by appearing or disap-
pearing at any time. Therefore, an important perspective would be
8. Conclusion to work on a notion of adaptive control.

8.1. Problem statement revisited References

Reusability, modularity and reconfigurability are enabling prop- Abdelzaher, T., Diao, Y., Hellerstein, J., Lu, C., Zhu, X., 2008. Introduction to control
erties that make component-based architecture a major player in theory and its application to computing systems. In: Liu, Z., Xia, C. (Eds.), Per-
formance Modeling and Engineering. Springer US, pp. 185–215.
providing self-adaptive capabilities to software-intensive systems. Alvares, F., Rutten, E., Seinturier, L., 2015. Behavioural model-based control for au-
Architecture description languages enable to define initial configu- tonomic software components. In: Proc. 12th Int. Conf. Autonomic Computing
rations, on top of which reconfigurations actions can be programed (ICAC’15). Grenoble, France.
Alvares, F., Rutten, E., Seinturier, L., 2015. High-level language support for reconfig-
in order to adapt the concerned architecture to runtime condi-
uration control in component-based architectures. In: Proc. 9th European Conf.
tions. A negative consequence of following this approach is that on Software Architecture (ECSA). Dubrovnik, Croatia.
the space of reachable configurations is only known as a side-effect An, X., Rutten, E., Diguet, J.-P., Le Griguer, N., Gamatié, A., 2013. Autonomic manage-
ment of dynamically partially reconfigurable FPGA architectures using discrete
of those fine-grained actions, which makes it hard, especially in
control. In: In Proc. of the 10th International Conference on Autonomic Com-
large architectures or in complex adaptive behaviours, to ensure puting (ICAC’13). SAN JOSE, CA, United States.
correctness on the adaptive behaviours. In fact, such kind of adap- Arshad, N., Heimbigner, D., 2005. A Comparison of Planning Based Models for Com-
tive behaviours requires decisions that are taken based not only ponent Reconfiguration. Research Report CU-CS-995-05. U. Colorado.
Batista, T., Joolia, A., Coulson, G., 2005. Managing dynamic reconfiguration in com-
on the past/current configurations and incoming events, but also ponent-based systems. In: Proceedings of the 2Nd European Conference on Soft-
on possible (reachable) futures configurations in a way to avoid ware Architecture. Springer-Verlag, Berlin, Heidelberg, pp. 1–17.
112 F. Alvares et al. / The Journal of Systems and Software 130 (2017) 94–112

Becker, S., Dziwok, S., Gerking, C., Heinzemann, C., Schäfer, W., Meyer, M., Fox, M., Long, D., 2003. Pddl2.1: an extension to pddl for expressing temporal plan-
Pohlmann, U., 2014. The mechatronicuml method: Model-driven software en- ning domains. CoRR abs/1106.4561.
gineering of self-adaptive mechatronic systems. In: Companion Proceedings of Garlan, D., Cheng, S.-W., Huang, A.-C., Schmerl, B., Steenkiste, P., 2004A. Rainbow:
the 36th International Conference on Software Engineering. ACM, New York, NY, architecture-based self adaptation with reusable infrastructure. IEEE Comput. 37
USA, pp. 614–615. (10).
Berthier, N., Marchand, H., 2014. Discrete controller synthesis for infinite state sys- Garlan, D., Cheng, S.-W., Huang, A.-C., Schmerl, B., Steenkiste, P., 2004B. Rainbow:
tems with reax. In: IEEE International Workshop on Discrete Event Systems. architecture-based self-adaptation with reusable infrastructure. Computer 37
Cachan, France, pp. 46–53. (10), 46–54.
Bouhadiba, T., Sabah, Q., Delaval, G., Rutten, E., 2011. Synchronous control of re- Garlan, D., Monroe, R.T., Wile, D., 20 0 0. Acme: architectural description of compo-
configuration in fractal component-based systems: a case study. In: Proceedings nent-based systems. In: Leavens, G.T., Sitaraman, M. (Eds.), Foundations of Com-
of the Ninth ACM International Conference on Embedded Software. ACM, New ponent-Based Systems. Cambridge University Press, pp. 47–68.
York, NY, USA, pp. 309–318. Gat, E., 1998. Artificial Intelligence and Mobile Robots. MIT Press, Cambridge, MA,
Boyer, F., Gruber, O., Pous, D., 2013. Robust reconfigurations of component assem- USA, pp. 195–210. chapter Three-layer Architectures
blies. In: Proceedings of the 2013 International Conference on Software Engi- Halbwachs, N., 2010. Synchronous Programming of Reactive Systems. Springer-
neering. IEEE Press, Piscataway, NJ, USA, pp. 13–22. Verlag, Berlin, Heidelberg.
Brun, Y., Di Marzo Serugendo, G., Gacek, C., Giese, H., Kienle, H., Litoiu, M., Harel, D., 1987. Statecharts: a visual formalism for complex systems. Sci. Comput.
Müller, H., Pezzè, M., Shaw, M., 2009. Engineering Self-Adaptive Systems Program. 8 (3), 231–274. doi:10.1016/0167- 6423(87)90035- 9.
through Feedback Loops. Springer Berlin Heidelberg, Berlin, Heidelberg, Harel, D., Pnueli, A., 1985. Logics and Models of Concurrent Systems. Springer-Verlag
pp. 48–70. New York, Inc., New York, NY, USA, pp. 477–498. chapter On the Development
Bruneton, E., Coupaye, T., Leclercq, M., Quéma, V., Stefani, J.-B., 2004. An open of Reactive Systems
component model and its support in java. In: Proceedings of the International Haugen, O., Wasowski, A., Czarnecki, K., 2013. Cvl: common variability language. In:
Symposium on Component-based Software Engineering (CBSE’2003). Edinburgh, Proceedings of the 17th International Software Product Line Conference. ACM,
Scotland. New York, NY, USA. 277–277
Calinescu, R., Ghezzi, C., Kwiatkowska, M., Mirandola, R., 2012. Self-adaptive soft- Jacobson, I., Griss, M., Jonsson, P., 1997. Software reuse: Architecture process and
ware needs quantitative verification at runtime. Commun. ACM 55 (9), 69–77. organization for business success. ACM Press.
doi:10.1145/2330667.2330686. Kouchnarenko, O., Weber, J.-F., 2014. Adapting component-based systems at runtime
Cheng, S.-W., Garlan, D., Schmerl, B., 2009. Evaluating the effectiveness of the via policies with temporal patterns. In: Fiadeiro, J.L., Liu, Z., Xue, J. (Eds.), FACS
rainbow self-adaptive system. In: Software Engineering for Adaptive and Self– 2013, 10th Int. Symposium on Formal Aspects of Component Software, Revised
Managing Systems, 2009. SEAMS ’09. ICSE Workshop on, pp. 132–141. Selected Papers. Springer, Nanchang, China, pp. 234–253. Revised Selected Pa-
Colaço, J.-L., Pagano, B., Pouzet, M., 2005. A conservative extension of synchronous pers
data-flow with state machines. In: Proceedings of the 5th ACM International Kramer, J., Magee, J., 2007. Self-managed systems: an architectural challenge. In:
Conference on Embedded Software. ACM, New York, NY, USA, pp. 173–182. 2007 Future of Software Engineering. IEEE Computer Society, Washington, DC,
da Silva, C.E., de Lemos, R., 2011. Dynamic plans for integration testing of self- USA, pp. 259–268. doi:10.1109/FOSE.2007.19.
-adaptive software systems. In: Proc. 6th Int. Symp. on Software Engineering Luckey, M., Nagel, B., Gerth, C., Engels, G., 2011. Adapt cases: extending use cases
for Adaptive and Self-Managing Systems, pp. 148–157. for adaptive systems. In: Proceedings of the 6th International Symposium on
David, P.-C., Ledoux, T., Léger, M., Coupaye, T., 2008. FPAth & FScript: language sup- Software Engineering for Adaptive and Self-Managing Systems. ACM, New York,
port for navigation and reliable reconfiguration of fractal architectures. Ann. NY, USA, pp. 30–39. doi:10.1145/1988008.1988014.
Telecommun. 64 (1), 45–63. Marchand, H., Bournai, P., Le Borgne, M., Le Guernic, P., 20 0 0. Synthesis of dis-
Delaval, G., Gueye, S.M.-K., Rutten, E., De Palma, N., 2014. Modular coordination of crete-event controllers based on the signal environment. Discrete Event Dyn.
multiple autonomic managers. In: Proceedings of the 17th International ACM Syst. 10 (4), 325–346.
Sigsoft Symposium on Component-based Software Engineering. ACM, New York, Medvidovic, N., Taylor, R.N., 20 0 0. A classification and comparison framework for
NY, USA, pp. 3–12. software architecture description languages. IEEE Trans. Softw. Eng. 26 (1),
Delaval, G., Marchand, H., Rutten, E., 2010. Contracts for modular discrete controller 70–93.
synthesis. In: ACM International Conference on Languages, Compilers, and Tools Morin, B., Barais, O., Nain, G., Jezequel, J.-M., 2009. Taming dynamically adaptive
for Embedded Systems (LCTES 2010). Stockholm, Sweden. systems using models and aspects. In: Proceedings of the 31st International
de Lemos, R., Giese, H., Müller, H.A., Shaw, M., Andersson, J., Litoiu, M., Schmerl, B., Conference on Software Engineering. IEEE Computer Society, Washington, DC,
Tamura, G., Villegas, N.M., Vogel, T., Weyns, D., Baresi, L., Becker, B., Ben- USA, pp. 122–132.
como, N., Brun, Y., Cukic, B., Desmarais, R., Dustdar, S., Engels, G., Geihs, K., Nahabedian, L., Braberman, V., D’Ippolito, N., Honiden, S., Kramer, J., Tei, K., Uchi-
Göschka, K.M., Gorla, A., Grassi, V., Inverardi, P., Karsai, G., Kramer, J., Lopes, A., tel, S., 2016. Assured and correct dynamic update of controllers. In: Proceedings
Magee, J., Malek, S., Mankovskii, S., Mirandola, R., Mylopoulos, J., Nierstrasz, O., of the 11th International Symposium on Software Engineering for Adaptive and
Pezzè, M., Prehofer, C., Schäfer, W., Schlichting, R., Smith, D.B., Sousa, J.P., Tahvil- Self-Managing Systems. ACM, New York, NY, USA, pp. 96–107.
dari, L., Wong, K., Wuttke, J., 2013. Software Engineering for Self-Adaptive Sys- Parra, C., Blanc, X., Duchien, L., 2009. Context awareness for dynamic service-ori-
tems: A Second Research Roadmap. Springer Berlin Heidelberg, Berlin, Heidel- ented product lines. In: Proceedings of the 13th International Software Product
berg, pp. 1–32. doi:10.1007/978- 3- 642- 35813- 5_1. Line Conference. Carnegie Mellon University, Pittsburgh, PA, USA, pp. 131–140.
D’Ippolito, N., Braberman, V., Kramer, J., Magee, J., Sykes, D., Uchitel, S., 2014. Hope Pascual, G.G., Pinto, M., Fuentes, L., 2013. Run-time support to manage architectural
for the best, prepare for the worst: multi-tier control for adaptive systems. variability specified with cvl. In: Proceedings of the 7th European Conference
In: Proceedings of the 36th International Conference on Software Engineering. on Software Architecture. Springer-Verlag, Berlin, Heidelberg, pp. 282–298.
ACM, New York, NY, USA, pp. 688–699. Seinturier, L., Merle, P., Rouvoy, R., Romero, D., Schiavoni, V., Stefani, J.-B., 2012. A
D’ippolito, N., Braberman, V., Piterman, N., Uchitel, S., 2013. Synthesizing component-based middleware platform for reconfigurable service-oriented ar-
nonanomalous event-based controllers for liveness goals. ACM Trans. Softw. chitectures. Software 42 (5), 559–583. doi:10.1002/spe.1077.
Eng. Methodol. 22 (1), 9:1–9:36. doi:10.1145/2430536.2430543. Tichy, M., Klöpper, B., 2012. Planning self-adaption with graph transformations. In:
Dumitrescu, E., Girault, A., Marchand, H., Rutten, É., 2010. Multicriteria optimal re- Proc. 4th Int. Conf. on Applications of Graph Transformations with Industrial
configuration of fault-tolerant real-time tasks. In: Workshop on Discrete Event Relevance, pp. 137–152. doi:10.1007/978- 3- 642- 34176- 2_13.
Systems, WODES’10. IFAC, Berlin, Germany, pp. 366–373. Warren, I., Sun, J., Krishnamohan, S., Weerasinghe, T., 2006. An automated formal
Filieri, A., Ghezzi, C., Tamburrelli, G., 2011. Run-time efficient probabilistic model approach to managing dynamic reconfiguration. In: Proceedings of the 21st
checking. In: Proceedings of the 33rd International Conference on Software En- IEEE/ACM International Conference on Automated Software Engineering. IEEE
gineering. ACM, New York, NY, USA, pp. 341–350. doi:10.1145/1985793.1985840. Computer Society, Washington, DC, USA, pp. 37–46.
Filieri, A., Hoffmann, H., Maggio, M., 2014. Automated design of self-adaptive soft- Weyns, D., Malek, S., Andersson, J., 2012. Forms: unifying reference model for formal
ware with control-theoretical formal guarantees. In: Proceedings of the 36th specification of distributed self-adaptive systems. ACM Trans. Auton. Adapt. Syst.
International Conference on Software Engineering. ACM, New York, NY, USA, 7 (1), 8:1–8:61. doi:10.1145/2168260.2168268.
pp. 299–310. doi:10.1145/2568225.2568272. Xing, Z., Stroulia, E., 2005. Umldiff: an algorithm for object-oriented design differ-
Filieri, A., Hoffmann, H., Maggio, M., 2015. Automated multi-objective control for encing. In: Proceedings of the 20th IEEE/ACM International Conference on Au-
self-adaptive software design. In: Proceedings of the 2015 10th Joint Meeting tomated Software Engineering. ACM, New York, NY, USA, pp. 54–65.
on Foundations of Software Engineering. ACM, New York, NY, USA, pp. 13–24.