=Paper=
{{Paper
|id=Vol-2019/mrt_2
|storemode=property
|title=Reflexive and Evolutional Digital Service Ecosystems with Models at Runtime
|pdfUrl=https://ceur-ws.org/Vol-2019/mrt_2.pdf
|volume=Vol-2019
|authors=Dhaminda Abeywickrama,Eila Ovaska
|dblpUrl=https://dblp.org/rec/conf/models/AbeywickramaO17
}}
==Reflexive and Evolutional Digital Service Ecosystems with Models at Runtime==
https://ceur-ws.org/Vol-2019/mrt_2.pdf
Reflexive and Evolutional Digital Service Ecosystems
with Models at Runtime
Dhaminda B. Abeywickrama Eila Ovaska
Service and Information Architectures Service and Information Architectures
VTT Technical Research Centre of Finland VTT Technical Research Centre of Finland
Kaitoväylä 1, 90570 Oulu, Finland Kaitoväylä 1, 90570 Oulu, Finland
dhaminda.abeywickrama@gmail.com eila.ovaska@gmail.com
Abstract—Uncertainty in digital service ecosystems (DSEs) novel and solid software architecting methods, techniques and
can be attributed to several factors like the dynamic nature of the tools.
ecosystem and unknown deployment environment, change and
evolution of requirements, and co-evolution among ecosystem In traditional software architecting approaches, uncertainty
members. Managing uncertainties in DSEs is challenging, and is addressed by identifying robust solutions at design-time.
therefore, novel and solid software architecting methods, However, for DSEs which are deployed in highly dynamic
techniques and tools are needed. Our research explores the environments, identifying solutions at design-time is
means to handle uncertainties at the software architecture level impractical. It is difficult to anticipate all environmental
of DSEs. In this regard, we apply valuable lessons learnt from the conditions they will encounter throughout lifetime. Recently,
models at runtime (M@RT) technique. This paper proposes a models at runtime (M@RT or runtime models) have been
novel, dynamic knowledge engineering approach to handle adopted in dynamically adaptive systems (DASs) to cope with
uncertainties in DSEs at runtime using M@RT. This uncertainty uncertainty and resolve them at runtime. A runtime model
handling approach aims to identify and solve two interrelated captures relevant information of the running system for
research problems: reflexivity and evolution of the ecosystem different purposes, which can be part of the system functional
between the architecture and running system of services. features or non-functional features providing quality assurance
Reflexivity means that the system must have knowledge of its and analysis [2].
components to make intelligent decisions based on self-
awareness. In addition, we provide tool support towards In the past, the concept of uncertainty has been explored
automating reflexivity and evolution. Complex state machines of extensively by researchers in different scientific disciplines,
M@RT that serve as a dynamic knowledgebase are modeled such as economics [3], physics and psychology. There is
using executable state machines, and generation of software extensive literature on model-based system reconfiguration
artifacts of the model is performed at execution time. Causal and on self-adaptive systems at the architecture level (e.g., [4],
connection is maintained between the runtime models and the [5]). Also, there are several related works on runtime models
running system. We validate and illustrate our approach using a to address uncertainties in DASs (e.g., [2], [6], [7], [8]).
DSE in an ambient-assisted living environment for elderly However, most of these works have been limited to conceptual
people.
frameworks or reference models. Also, to the best of our
Keywords—dynamic knowledge; model-driven development;
knowledge, none of them provide concrete tool support and
reflexivity; evolvability; uncertainty; digital ecosystems case study validation especially in the context of digital
service engineering. This provides motivation for this study.
The contribution of this paper is twofold. First, this paper
I. INTRODUCTION proposes a novel, dynamic knowledge engineering approach
Today the entire industrial world is transforming from a to handle uncertainties in DSEs at runtime using M@RT.
physical world to a digital one. In this context, a new Second, it provides tool support towards automating the
paradigm has emerged called digital service ecosystems engineering approach.
(DSEs), which are open, loosely coupled, domain-clustered,
In our approach, M@RT is a dynamic knowledgebase [2]
demand-driven, self-organizing agents’ environments where
that abstracts important information about the system, its
each entity is proactive and responsive for its own benefit [1].
operational context, and requirements. The approach aims to
In DSEs, the business stakeholders provide the most
identify and solve two interrelated research problems. They
significant driving factor, which requires digital services
are: reflexivity and evolution of the DSE between architecture
(DSs) to handle uncertainty. Uncertainty in DSEs can be
and running system of services (e.g., cloud services).
attributed to several factors, such as the dynamic nature of the
Reflexivity means that the system must have knowledge of its
ecosystem and unknown deployment environment,
components to make intelligent decisions based on self-
composition and users; change and evolution of requirements;
awareness [9]. To support reflexivity, we propose a set of
and co-evolution among ecosystem members. Therefore,
quality-driven, self-adaptive architectural patterns. Complex
managing uncertainties is a challenge, and there is a need for
state machines of M@RT that serve as a dynamic
knowledgebase are modeled using Enterprise Architect’s context, we introduced the ADSEng methodology [9], which is
executable state machines [10]. We support evolution between a novel, systematic service engineering methodology proposed
architecture and running system of cloud services using for ecosystem-based engineering of autonomous DSs. This
generation of software artifacts of the model at execution time. integrated and model-based methodology covers from
The runtime models and the running system are causally requirements engineering to architecting, and running systems
(loosely) connected, so that the both abstractions evolve at the of DSs. The current paper is based on the ADSEng
same time. The approach is validated using a DSE, which methodology. However, it is a significant step further,
describes an ambient-assisted living (AAL) environment for presenting a dynamic knowledge engineering approach as well
elderly people. as practical tool support and case study validation.
The rest of the paper is organized as follows. Section II,
provides background information to our work. In Section III, III. ENGINEERING OF DYNAMIC KNOWLEDGE MODELS
we propose our knowledge engineering approach using In this section, we describe our dynamic knowledge
M@RT. The case study and the application of the approach engineering approach using M@RT to handle uncertainties in
are described in Section IV. In Section V, we present key DSEs at runtime. First, an overview of the engineering process
related work, and Section VI concludes this paper. (see Fig. 1) is provided followed by a description of each step.
We use the Sparx Systems’ Enterprise Architect (13.0) case
II. BACKGROUND tool towards automating the engineering process.
A. Definitions A. Approach Overview
1) Uncertainty: In our approach, a runtime model is a dynamic
Uncertainty [11] is a system state of incomplete or knowledgebase that abstracts important information about the
inconsistent knowledge so that an adaptive system is unable to system, its operational context, and requirements. MAPE-K is
know which alternative environmental or system a reference model introduced by IBM for autonomic control
configurations hold at a specific point. It can be caused by loops [16]. Here, the basic monitor-analyze-plan-execute over
missing or ambiguous requirements, false assumptions, a knowledgebase (MAPE-K) architecture [16] of the DSE is
unpredictable entities or phenomena in the execution extended at the architecture level to use models that evolve, so
environment, and unresolvable conditions caused by that the software system is able to better manage uncertainty.
incomplete and inconsistent information. This information can This is realized by analyzing new properties about the
be obtained by potentially imprecise, inaccurate, and unreliable execution environment and the system itself based on
sensors in its monitoring infrastructure [11]. Uncertainty and monitoring information collected at runtime. The four key
variability are two separate, yet related notions, and in our processes in the architecture - monitor, analyze, plan and
research, we aim to deal with uncertainty. execute – can analyze the system and environmental data to
refine and extend the information stored in the runtime
2) Reflexivity and Evolution: models.
Reflexivity is an important characteristic of a self-managed
autonomic system, which means that the system must have Towards supporting reflexivity, we propose a set of
knowledge of its components, current status, capabilities, quality-driven, self-aware and self-adaptive architectural
limits, boundaries and interdependencies with other systems patterns, which are extended MAPE-K loops with quality
and available resources [12]. Also, the system must be aware assurances (see Section III-B). The goal is to use the patterns
of its possible configurations and how they affect specific non- to create and customize the dynamic knowledge models in
functional, quality requirements. In this study, we consider different domains. We model the complex state machines of
reflexivity as a technique that can be exploited to support M@RT using Enterprise Architect’s executable state
evolution of the ecosystem. machines. Evolution between architecture and running system
of cloud services is supported using generation of software
By evolution we refer to the ability of the ecosystem to artifacts of the model at execution time. Causal connection is
evolve in dynamic situations (e.g., see [13]). An ecosystem is maintained between runtime models and the running system.
dynamic, evolving all the time as new members, services and
value networks emerge [14]. Therefore, to adapt to the needs In this manner, the main steps in the dynamic knowledge
of the ecosystem, the ecosystem’s knowledge management engineering process are (see steps 1-3 in Fig. 1):
model should evolve too. (1) create dynamic knowledge models of requirements and
architecture in the example domain (see step 1b in Fig.
B. ADSEng Methodology and Contribution 1). At the architecture level, this is assisted by a
Previously in [15], we established several characteristics as collection of self-aware and self-adaptive architectural
part of an evaluation framework to compare existing autonomic patterns (step 1a, Fig. 1);
computing approaches in DSEs. They are: top-down vs. (2) create an executable state machine artifact to run the
bottom-up approaches, decentralized control, self-* properties knowledge models in architecture and then generate the
and context-awareness, reflexivity, quality attributes, and code and compile it (step 2, Fig. 1);
validation/case study. Later, in [9], these characteristics (3) execute, simulate and validate the dynamic knowledge
corresponded to several key requirements that are significant in models (step 3, Fig. 1).
a service engineering method for autonomous DSEs. In this
B. Step 1: Create Dynamic Knowledge Models
We use two types of knowledge models at the requirements
and architecture levels, respectively. They are: (i) a KAOS-
based goal model that represents the requirements; and (ii)
model-based finite state machines (FSMs) at the architecture
level. For the goal-based requirements model, a simplified
KAOS metamodel is used to represent goals where each goal is
associated with a name and a priority. FSMs, which are
embodied in the architectural patterns, describe the behavior of
the system with respect to the current goals and context. A
FSM runtime model can show the current state information of a
component during its operation.
1) Architectural Patterns Collection for DSEs:
The main step (see also [9]) for supporting reflexivity is
representing the uncertainty factors using architectural
patterns. The main goal is to use them for creating and
customizing the knowledge models in different domains. The
patterns have been modeled in Enterprise Architect using
UML templates (UML activity and state models), which can
be instantiated to a particular domain using UML 2.5 models.
Here the traditional autonomic MAPE-K loops [16] have been
extended with quality guarantees to handle uncertainty at the
software architecture level.
Both decentralized and centralized feedback loop
approaches have been suggested to facilitate autonomic
behavior in adaptive systems [17]. We integrate these
Fig. 1. Dynamic knowledge models-based service engineering.
approaches in the patterns to exploit the benefits of both. With
this our approach aims to support both collective adaptation the MAPE elements of an AM interact with the quality
and adaptation by subparts. Although centralized approaches assurance component to obtain or update information about the
allow global behavior control, they contain a single point of system states, environment, and quality assurance criteria.
failure and suffer from scalability issues. Conversely,
decentralized approaches do not require any a priori b) Centralized DS Pattern:
knowledge, nor do they contain a single point of failure. In this This pattern (see Fig. 3) is characterized by a global
paper, we describe two main patterns from the collection——the feedback loop, which manages a higher-level adaptation of
autonomic DS pattern and centralized DS pattern (see Fig. 2 behavior of multiple autonomic components (e.g., two DSs in
and Fig. 3). The former applies the decentralized feedback loop Fig. 3). The adaptation in the centralized DS pattern is handled
approach while the latter applies the centralized approach. by a high-level AM called a super AM. Like an AM, a super
AM also has a quality-driven, extended MAPE-K adaptation
a) Autonomic DS Pattern: model. This is while the single DSs are able to self-adapt their
The autonomic DS pattern (see Fig. 2), which is modeled as individual behavior using their own external feedback loops in
a UML template, is characterized by the presence of an the AMs (Fig. 3).
explicit, external feedback loop (Autonomic Manager / AM) to
direct the behavior of the DS, which is the managed element. C. Step 2: Create Executable State Machine Artifact,
This pattern exhibits self-* properties, such as self-awareness Generate and Compile Code
and self-adaptation. The DS has sensors, effectors and a
representation of goals. An AM handles the adaptation of the Next, in the knowledge engineering process, we design the
DS. Several AMs can be associated with the DS, each closing a executable state machine artifact, which is used to generate
feedback loop devoted to controlling a specific adaptation the code for the model that can be compiled and executed (see
aspect of the system, and adding different levels of AMs step 2 in Fig. 1). This artifact essentially describes the classes
and objects involved in the DSs and their AMs in the patterns,
increases the autonomicity. Here, the novelty is that the
their initial properties and relationships. It acts as the binding
traditional autonomic MAPE-K loop is extended with a quality
script that links multiple objects together and determines how
assurance component at the architecture level for DSs. This
quality assurance component implements a QoS model that these will communicate in a simulation at runtime.
provides QoS guarantees. It corresponds to the dynamic The underlying technique we explore to support evolution
knowledgebase in Fig. 1. The quality assurance component can between the architecture and the running system of cloud
include three types of runtime models depending on their services is generation of service software at execution time. In
subject, such as system models (i.e., abstract view of the DSEs, which are characterized by a high level of uncertainty,
running system), context models (e.g., environment), and the generation of software needs to happen at runtime as it
quality requirements of the DS. During the adaptation process, cannot necessarily be foreseen during design time. In this study
IV. APPLYING THE APPROACH
After presenting the proposed approach, now we describe
how we have applied it to the AAL case study. The scope of
the knowledge engineering process is large. Therefore, as
applied next using the case study, this paper focuses on step 1
and step 2 to support reflexivity and evolution of DSEs
between architecture and running system of cloud services.
Simulating and validating of knowledge models (step 3) in the
case study will be addressed in a future paper.
Fig. 2. Autonomic digital service pattern. A. Problem Domain and Case Study
The case study describes a DSE in digital health revolution,
which provides an AAL environment for elderly people [9]
(see Fig. 4). Advanced smart homes depend on adaptivity to
function properly [9]. This can be associated with several
uncertainty factors; e.g., sensors or devices can fail, and the
behavior of the elderly person him/herself can be highly
uncertain. Therefore, in such uncertainty situations, the system
needs to satisfy the requirement in some other way. In AAL,
the DSE includes two main cloud-based services: (i) a
monitoring and security service and (ii) a diagnosis service.
The monitoring and security service utilizes different
monitoring devices to analyze the elderly person’s activities
and provides security services. This service can include several
supporting cloud services; for example, several sensor-based
Fig. 3. Centralized digital service pattern. monitoring services and an elderly care security service. The
service providers can be different businesses that provide
we use the dynamic code generation feature of the executable sensor services, and an elderly care security service.
state machine artifact to support the evolution between Meanwhile, the diagnosis cloud service is used by a doctor or
architecture and running system of services. The automated another person (e.g., a nurse) to make a diagnosis based on
model transformations in the code generation process support monitored data. This service can include several supporting
the causal connection between the runtime models and the cloud services provided by several service providers; for
running system. This means that when the model is modified, example, electric health records, health insurance and clinical
the running system is changed correspondingly. Thus, the two information systems.
abstractions synchronize and evolve at the same time.
In this context, we describe a scenario of an elderly person
D. Step 3: Simulate and Validate Knowledge Models called Peter: Peter is 74 years old, and suffers from nocturnal
epileptic seizures; and he is also an alcoholic. The main goal
Finally, we exploit Enterprise Architect’s ability to
for Peter is to maintain health (i.e., reduce the triggering of
perform simulations with its simulation feature which allows
seizures), which can be dependent on two factors: high
executing the dynamic knowledge models created (step 3, Fig.
alcohol level and lack of sleep due to disturbances to sleep
1). As the executable state machine executes, the relevant state
pattern. Several devices can be associated with several context
machine diagrams are displayed where the active state for the
dimensions, such as: a waist-worn fall detector; an intelligent
instance completing a step is highlighted and the other states
bed with epileptic sensor to monitor seizures; activity
remain dimmed. The state machines can be changed at
monitors to monitor sleep level; an intelligent cellar with
runtime by user interaction. The simulation provides a visual
RFIDs to monitor the locations of alcohol containers;
reflection of the real compile code as it is executing. When the
intelligent mug with sensors to monitor the alcohol level
execution is completed the generated code can be deployed to
consumed.
the target system. This code can be further modeled by the
engineer to derive the running system of cloud services. The devices——the intelligent cellar and intelligent mug——
We use the debugging features of the Enterprise Architect are supporting cloud services. They are connected to the
environment to validate the complex dynamic knowledge ambient-assisted home hub unit for a more high-level handling
models of state machines. These can be inserting simulation of sensor information and adaptation of the DSs. Thus, there
breakpoints, firing waiting triggers, tools to pause and run a are two supporting cloud services: iCellar (i.e., RDF
simulation, and tools to examine local variables and the call tracking sensor cloud service in Fig. 4) and iMug, and the
stack. Thus, it allows us to verify the correct behavior of the ambient-assisted home hub unit can be considered
generated code. as a high-level service. Here, a composite DS can be the
orchestration of the iCellar and iMug DSs. The goal of the
ambient-assisted home hub unit service is to
monitor the alcohol volume of the containers in the cellar, and
Fig. 4. Case study: ambient-assisted living (AAL) digital service ecosystem.
alcohol volume consumed from the mug, so the maximum right configurations is in the priority level of the low
alcohol intake level is not exceeded. In this example, we alcohol consumption softgoal where the right
assume that there is a single container in the iCellar. Table configuration has a higher priority.
1 summarizes the main goals of these cloud services and their
associated uncertainty factors. TABLE I. GOALS AND ASSOCIATED UNCERTAINTY FACTORS OF
SUPPORTING CLOUD SERVICES
B. Applying the Approach to Case Study Supporting Cloud Goals Uncertainties
Service
1) Create Dynamic Knowledge Models: Intelligent cellar Maintain alcohol Alcohol containers can
a) Requirements Model: (iCellar) volume consumed get misplaced or lost
from container
In the AAL case study, we use KAOS-based goal models to Intelligent mug Maintain alcohol Alcohol content can be
represent the requirements, i.e., goals (functional) and softgoals (iMug) volume consumed spilled;
(non-functional) of the scenario. Fig. 5 provides an excerpt of a from mug other drinking objects
can be present
goal graph created to mitigate uncertainties. There the top-level Ambient- Ensure that maximum Alcohol intake level is
goal is refined as a goal lattice in which branches and goals are assisted home alcohol intake level is exceeded which can
refined into expectations and requirements. The main goal for hub unit not exceeded; cause Peter to get
Peter is to maintain his health by avoiding triggering of Raise an alarm if it intoxicated and become
exceeds a certain unhealthy
seizures. In the goal model, KAOS obstacles are used to threshold level
represent the uncertainty factors, e.g., Peter's behavior. More
specifically, it can happen that Peter forgets to control alcohol
intake. That is, it is uncertain whether Peter will avoid high
alcohol intake; he could forget to control drinking and the
effect could mean he exceeds alcohol intake, becomes
intoxicated and eventually unhealthy.
As stated in Section III-B, a simplified KAOS metamodel is
used to represent goals where each goal is associated with a
name and a priority. The goal priorities can be affected by
context changes, thereby affecting tasks execution by the user
(e.g., Peter) or entity (e.g., iCellar, iMug or ambient-
assisted home hub unit) at runtime. The system
depending on the goal priority and the relation between the
goals weighs the requirements during task execution and
selects a set of tasks to be performed. This goal configuration
graph for the ambient-assisted home hub unit Fig. 5. Requirements: goal model to mitigate uncertainties in AAL.
service is shown in Fig. 6. The difference between the left and
Fig. 6. Two goal configurations for the requirements of the ambient-
assisted home hub unit service.
b) Architecture Model:
We now describe the architectural models realized
applying our approach to simulate several feedback loop
structures in the iCellar-iMug DSs composition of the
AAL case study (see Fig. 7). These models are created using
the patterns presented in Section III-B. In this study, UML 2.5
activity models and state machines have been used as the
primary notation to model the behavior of the loops. A
feedback loop provides the interplay between flow (control or
data) and actions on the flows.
One of our main motivations of the present research is to
address uncertainty. To this end, the approach and the
simulation scenario add unexpected context information to
model uncertainty using state machines. To address
uncertainty, the monitoring needs to be context-aware. The
analysis phase then reasons using new (unknown) context Fig. 7. AAL Case study: digital services and autonomic managers.
information and interprets how the goals are affected, thus
planning for the system to cope with such changes. data through sensors (e.g., collect alcohol volume in
Monitor of AutonomicManager_ICellar, Fig. 8)
about the current state and/or occurring events of the system,
Managed Elements and Autonomic Managers: There are the context, and the requirements (goals). It checks for
two managed elements (DSs) in the AAL case study example: changes of goals, which can be changed by the user or the
DigitalService_ICellar and system itself. The monitoring process updates the runtime
DigitalService_IMug (Fig. 7). The two AMs— model that represents knowledge about the state, context, and
AutonomicManager_ICellar and requirements (change of goals).
AutonomicManager_IMug——close separate, Analyzing: There are two main tasks in this process: (i) it
decentralized feedback loops to handle the adaptation of gathers runtime models and interprets data collected by the
alcohol volume in container and alcohol volume in mug (and monitoring process against goals and constraints; and (ii)
spilled volume), respectively. Also, there is a high-level AM detects system and environmental changes that may need
called a super AM adaptation. The analyze process decides that a behavior
(SuperAutonomicManager_AmbientAssistedHome adaptation is required to satisfy the detected goal changes. In
HubUnit) that closes a separate, centralized feedback loop. the example, this can be gathering and interpreting alcohol
Here, this super AM handles the adaptation of alcohol volume volume data from the runtime model and checking against the
in both the iCellar and the iMug. As stated in Section III- goals to detect changes that require adaptation (see Analyze
B, a super AM can manage the adaptation of multiple SCs. of AutonomicManager_ICellar, Fig. 8).
This example implements and integrates both decentralized
and centralized feedback control loop techniques using the Planning: The planning process reads the runtime model
two patterns——autonomic DS pattern and enhanced by the analysis process. Then some reasoning is
centralized DS pattern. In the example, the runtime performed to identify how the running system should be best
model is now a goal model with constraints, an environment adapted to changes of the system, context, and requirements.
model, and an initial behavior model in the form of FSMs. The planned changes can be in the form of a runtime model. In
the example, the high availability softgoal of the
The resolving of uncertainties at runtime by the different ambient-assisted home hub unit service
phases (i.e., monitoring, planning, analyzing and executing) of (SuperAutonomicManager_AmbientAssistedHome
the extended MAPE-K loop architecture is explained next.
HubUnit) has a much high priority than the softgoal low
Monitoring: The monitoring process has two main tasks: alcohol consumption (see Fig. 6, left). Therefore, the
monitoring and updating of runtime models. It measures raw planning step for that component can generate a new
Runtime
model before
goals change
iCellar
Digital Service
(Managed
Element)
Autonomic
Manager for
iCellar
’
’
Runtime
model after
goals change
Fig. 9. M@RT of the ambient-assisted home hub unit service in AAL.
and state machines on knowledge models then we design the
executable state machine artifact
(AALCaseStudy_ExecutableArtifact, Fig. 10). This
artifact describes the classes and objects involved in the
example (i.e., the DSs and their AMs in the patterns). They
Fig. 8. Modeling iCellar service and autonomic manager in AAL. can also describe their initial properties and relationships. We
behavioral model or adapt the existing one (see M@RT state define initial state of instance by assigning property values to
machines in Fig. 9, top). Here, there is a reduced alcohol the class attributes. For example, see property values assigned
consumed level safety margin where the critical behavior is to DS_ICellar, DS_IMug and
entered only if the alcohol level is greater than 80. The SAM_AmbientAssistedHomeHub. Also, we define how
ambient-assisted home hub unit continues to each property can reference other properties by defining
perform its tasks according to the specialized state machine relationships based on the class model that they are instances
until goals changed by the user or system itself. Let us assume of.
that the goals change to the situation as depicted in the second
Afterwards, using the executable state machine artifact
configuration (see Fig. 6, right). Now the low alcohol
created in the example, we generate the code in Java and
consumption goal has a higher priority. The monitoring compile it. See Fig. 10 for system output with code
step of the loop senses this change of goals, and updates it in successfully generated for all classes. The generation of code
the runtime model. The analyze activity decides that a behavior from the executable state machine artifact supports causal
adaptation is necessary and the planning step tries to fulfill the connection between the runtime models and the running
new constraints. In this case, the MAPE loop will generate or system, thus both evolving at the same time. Next, the
adapt the existing state machine (see M@RT’ state machines in compiled code can be executed, simulated and validated using
Fig. 9, bottom). The new behavioral model uses a higher safety the simulation and debugging features of Enterprise Architect.
margin for alcohol consumed level (critical stage is entered
when it is greater than 90). In addition, it introduces a new state
called Error to handle the critical behavior of the state V. RELATED WORK AND DISCUSSION
machine by adding additional operations (functions) through A key research area related to our study is model-based
error handling extensions in the ambient-assisted system reconfiguration. Rainbow framework [4] is a seminal
home hub unit service. work on architecture-based self-adaptation. It extends
architecture styles to provide reusable infrastructure with
Executing: The Execution process directly applies a set of mechanisms to specialize the infrastructure to the needs of
changes for the running system stored in some runtime models specific systems. Braberman et al. [5] proposed a three-
by the planner. In this example, it can be notifications sent on layered reference architecture called MORPH for architecture-
over alcohol consumption and to control drinking. based adaptation that involves runtime change of system
2) Create Executable State Machine Artifact, Generate configuration and behavior update. Meanwhile, Morin et al.
[18] proposed an approach that combines aspect-oriented and
and Compile Code:
model-driven techniques to limit the number of artifacts
As mentioned in Section III-C, after creating the classes
needed to realize dynamic variability. However, these works
Executable state machine artifact
knowledgebase. However, the MAPE-K extensions proposed
in their approach are only at the conceptual level.
DYNAMICO (Dynamic Adaptive, Monitoring and Control
Objectives model) [7] is a reference model for engineering
context-based self-adaptive software composed of feedback
Classes loops. It aims to guarantee the coherence of adaptation
mechanisms with respect to changes in adaptation goals and
monitoring mechanisms. Tamura et al. [8] present a proposal
System Output for including software validation and verification (V&V)
Generate Code
operations explicitly in MAPE-K loops for achieving software
self-adaptation goals. They discuss runtime V&V enablers,
i.e., requirements at runtime, models at runtime, and dynamic
context monitoring, for providing effective support to
Fig. 10. Executable state machine artifact and code generation.
materialize V&V assurances for self-adaptation.
are neither based on M@RT explicitly nor target digital To summarize, extensive literature exist on model-based
service ecosystems. system reconfiguration and on self-adaptive systems in the
architecture level (e.g., [4], [5]). Also, there are several
Maes [19] described one of the pioneering works on approaches on runtime models to address uncertainties in
reflection with respect to object-oriented programming DASs (e.g., [2], [6], [7], [8]). However, most of these have
languages. The author defines a computational system been limited to conceptual frameworks. Also, to the best of our
causally connected to its domain and a change in its domain is knowledge, none of them provide concrete tool support and
reflected on it and vice versa. The Twin Peaks model [20] case study validation especially in the context of DSEs. We
deals with a similar notion to reflexivity proposed here. It is an have presented an approach for supporting M@RT in DSEs
iterative process that develops progressively more detailed that provide reflexivity and evolution.
software requirements and architectural specifications
concurrently. Requirement reflection [21] supports runtime
representation of requirements by making requirements VI. CONCLUSIONS AND FUTURE WORK
available as runtime objects for DASs. Bencomo [21] In this paper, we presented a dynamic knowledge
classifies uncertainty and adaptations that a self-adaptive engineering approach to handle uncertainties in DSEs at
system need to face. There to deal with uncertainty, goal- runtime using the M@RT technique. The approach aims to
oriented requirements modeling has been extended with the solve two interrelated research problems, i.e., reflexivity and
RELAX language. The goal of their work is to manage evolvability of the ecosystem between the architecture and the
uncertainty primarily at the requirements level. running system of services. Complex state machines of M@RT
that serve as a dynamic knowledgebase have been modeled
In [11], the authors have proposed a taxonomy of potential
using executable state machines, and the generation of software
sources of uncertainty and techniques for mitigating them in
artifacts has been performed at execution time. Causal
the requirements, design, and execution phases of DASs. In
connection has been maintained between the runtime models
[22], the authors present a goal-based modeling approach to
and the running system to support evolution. We presented an
develop requirements of an adaptive system with
example involving a DSE in an AAL environment for elderly
environmental uncertainty. While our technique of handling
people for validating the approach.
uncertainties using a KAOS-based goal-model follows [22],
our work differs from [22] in that we handle uncertainty using The aim of our work is not to enhance model-driven
M@RT at the architecture level as well. architecture but to create an approach that can be applied to
digital service engineering and is based on service architecture.
Adaptation patterns have been explored as a technique to
The approach needs to be easy to understand as the target
provide self-adaptation in several works (e.g., [23]). However,
audience is software engineers and not specialists in autonomic
the novelty is the patterns defined here for DSEs contain a key
computing. Currently, by using the capability of Enterprise
quality assurance component for providing quality guarantees
Architect, our approach can automate the forward
in addition to the adaptation handling MAPE elements.
synchronization of the causal connection between the
There are several works (e.g., [2], [6], [7], [8]) that use architecture and running system. At present, we are exploring
runtime models as a technique to manage uncertainties and techniques for supporting the backward synchronization from
provide assurance in DASs. The authors in [2], [6] propose running system of cloud services to the architectural models.
extensions to the MAPE-K loop architecture with runtime Our future work will include completing the building of the
models to cope with uncertainty at runtime. In [6], the authors collection of quality-driven adaptation patterns. Also, so far,
present a conceptual reference model called MAPE-MART, our modeling has considered only a single user in the
which extends the traditional MAPE-K model with quality ecosystem (i.e., elderly person). This needs to be applied to
assurance mechanisms for self-adaptation. The notion of multiple users of the ecosystem to further validate our
dynamic knowledgebase was originally motivated by the work approach. Finally, in order to provide a true assessment of our
in [2] where the authors identify a runtime model as a dynamic knowledge engineering approach, developing industrial case
studies with empirical cases is significant.
ACKNOWLEDGMENT [11] A. J. Ramirez, A. C. Jensen and B. H. C. Cheng, "A taxonomy of
uncertainty for dynamically adaptive systems," in Proceedings of the 7th
This work was carried out during the tenure of an ERCIM International Symposium on Software Engineering for Adaptive and
“Alain Bensoussan” Fellowship Programme. This research has Self-Managing Systems (SEAMS'12), Zurich, Switzerland, 2012, pp. 99-
also been supported by a grant from Tekes—the Finnish 108.
funding agency for technology and innovation, and VTT as [12] H. A. Müller, L. O’Brien, M. Klein and B. Wood, "Autonomic
computing,", Carnegie Mellon University, USA, Rep. Report No.:
part of the Digital Health Revolution Programme. CMU/SEI-2006-TN-006 2006.
[13] G. Briscoe and P. De Wilde, "Digital ecosystems: evolving service-
REFERENCES orientated architectures," in Proceedings of the 1st Bio-Inspired Models
of Network, Information and Computing Systems Conference
[1] H. Boley and E. Chang, "Digital ecosystems: principles and semantics," in
(BIONETICS 2006), Madonna di Campiglio, 2006, pp. 1-6.
Proceedings of the International Conference on Digital EcoSystems and
Technologies (DEST '07), Cairns, Australia, 2007, pp. 398-403. [14] A. Immonen, E. Ovaska, J. Kalaoja and D. Pakkala, "A service
requirements engineering method for a digital service ecosystem,"
[2] H. Giese, N. Bencomo, L. Pasquale, A. J. Ramirez, P. Inverardi, S.
Service Oriented Computing and Applications, vol. 10, no. 2, pp. 151-
Wätzoldt and S. Clarke, "Living with uncertainty in the age of runtime
172 2016.
models," in Models@run.time: Foundations, Applications, and
Roadmaps, N. Bencomo et al, Eds. Cham: Springer, 2014, pp. 47-100. [15] D. B. Abeywickrama and E. Ovaska, "A survey of autonomic computing
methods in digital service ecosystems," Service Oriented Computing and
[3] J. Laffont, The Economics of Uncertainty and Information, The MIT
Applications, vol. 11, no. 1, pp. 1-31 2017.
Press, 1989.
[16] J. O. Kephart and D. M. Chess, "The vision of autonomic computing,"
[4] D. Garlan, S. Cheng, A. Huang, B. Schmerl and P. Steenkiste, "Rainbow:
Computer, vol. 36, no. 1, pp. 41-50 2003.
architecture-based self-adaptation with reusable infrastructure,"
Computer, vol. 37, pp. 46-54, 2004. [17] T. Haupt, "Towards mediation-based self-healing of data-driven business
processes," in Proceedings of the 7th International Symposium on
[5] V. Braberman, N. D'Ippolito, J. Kramer, D. Sykes and S. Uchitel,
Software Engineering for Adaptive and Self-Managing Systems, Zurich,
"MORPH: A reference architecture for configuration and behaviour self-
Switzerland, 2012, pp. 139-144.
adaptation," in Proceedings of the 1st International Workshop on Control
Theory for Software Engineering, Bergamo, Italy, 2015, pp. 9-16. [18] B. Morin, O. Barais, G. Nain and J. M. Jezequel, "Taming dynamically
adaptive systems using models and aspects," in Proceedings of the IEEE
[6] B. C. Cheng, K. Eder, M. Gogolla, L. Grunske, M. Litoiu, H. Müller, P.
31st International Conference on Software Engineering, 2009, pp. 122-
Pelliccione, A. Perini, N. Qureshi, B. Rumpe, D. Schneider, F. Trollmann
132.
and N. Villegas, "Using models at runtime to address assurance for self-
adaptive systems," in Models@run.Time, N. Bencomo et al, Eds. [19] P. Maes, "Concepts and experiments in computational reflection," in
Springer International Publishing, 2014, pp. 101-136. Proceedings of the Object-oriented Programming Systems, Languages
and Applications Conference (OOPSLA'87), Orlando, Florida, USA,
[7] N. M. Villegas, G. Tamura, H. A. Müller, L. Duchien and R. Casallas,
1987, pp. 147-155.
"DYNAMICO: A reference model for governing control objectives and
context relevance in self-adaptive software systems," in Software [20] B. Nuseibeh, "Weaving together requirements and architectures,"
Engineering for Self-Adaptive Systems II: International Seminar, Computer, vol. 34, no. 3, pp. 115-117, mar 2001.
Dagstuhl Castle, Germany, October 24-29, 2010 Revised Selected and [21] N. Bencomo, "Requirements for self-adaptation," in Generative and
Invited Papers, R. de Lemos et al, Eds. Springer, 2013, pp. 265-293. Transformational Techniques in Software Engineering IV, R. Lämmel, J.
[8] G. Tamura, N. M. Villegas, H. A. Müller, J. P. Sousa, B. Becker, G. Saraiva and J. Visser, Eds. Berlin Heidelberg: Springer, 2013, pp. 271-
Karsai, S. Mankovskii, M. Pezzè, W. Schäfer, L. Tahvildari and K. 296.
Wong, "Towards practical runtime verification and validation of self- [22] B. C. Cheng, P. Sawyer, N. Bencomo and J. Whittle, "A goal-based
adaptive software systems," in Software Engineering for Self-Adaptive modeling approach to develop requirements of an adaptive system with
Systems II: International Seminar, Dagstuhl Castle, Germany, October environmental uncertainty," in Model Driven Engineering Languages
24-29, 2010 Revised Selected and Invited Papers, R. de Lemos et al, Eds. and Systems, A. Schürr and B. Selic, Eds. Berlin Heidelberg: Springer,
Springer, 2013, pp. 108-132. 2009, pp. 468-483.
[9] D. B. Abeywickrama and E. Ovaska, "ADSEng: a model-based [23] D. B. Abeywickrama, N. Hoch and F. Zambonelli, "Engineering and
methodology for autonomous digital service engineering," in implementing software architectural patterns based on feedback loops,"
Proceedings of the 8th International ACM Conference on Management Scalable Computing: Practice and Experience, vol. 15, no. 4, pp. 291
of Digital EcoSystems (MEDES'16), Hendaye, France, 2016, pp. 34-42. 2014.
[10] Sparx Systems Enterprise Architect. Executable State Machines [Online].
Available: http://www.sparxsystems.com/resources/user-
guides/simulation/executable-state-machines.pdf. Last Accessed:
6/7/2017.