Fundamentals on Adaptive Software
Lecture 2
Course CODE: XM_0128
Ilias Gerostathopoulos
Assistant professor
Software and Sustainability Group
Computer Science Department
Vrije Universiteit Amsterdam
[Link]@[Link]
Master in Computer Science, October 30th 2024
Plan for lectures
1. Course outline, terminology, task automation
2. Architectural principles
3. Control theoretical approaches
4. Requirements-driven adaptation
5. Evaluation & quality aspects
6. Runtime models
7. Guarantees under uncertainties
8. Learn from experience: ML and search-based approaches
9. Self-adaptation in ML systems
10. Self-adaptation in robotics
11. Self-protection 2
Agenda for this lecture
1. Associated wave, definition, motivation
2. A reference model for architecture-based self-
adaptation
3. A (technical) framework for architecture-
based self-adaptation
3
Reminder!
Wave I: Task automation
4
Reminder!
Autonomic manager – MAPE-K reference model
Relieves administrators of
responsibility to directly manage
the managed element
Element to be monitored
and controlled to realize
administrator’s goals
5
Slide credit: Danny Weyns, “Tutorial: Engineering Self-Adaptive Systems - An Organized Tour”
Reminder!
Autonomic manager – MAPE-K reference model
Determines whether Plans mitigation actions to
adaptation actions are adapt the managed
required based on the element when needed
collected data and
administrator’s goals
Executes the adaptation
Collects data from managed actions of the generated
element and its execution plan, adapting the managed
context to update the element
Knowledge.
Abstraction of relevant aspects of the managed element (self-awareness),
environment (context-awareness), and the administrator’s goals (goal-awareness) 6
Slide credit: Danny Weyns, “Tutorial: Engineering Self-Adaptive Systems - An Organized Tour”
Wave II: Architectural principles
7
systematic engineering
perspective
1. Automating tasks 2. Architectural principles
requirements of self-
adaptive systems theoretical
requirements for framework for
feedback loops complexity of adaptation
concrete design
4. Requirements-
driven adaptation 3. Runtime models 6. Control principles
guarantees under
uncertainty as uncertainty complexity to provide
first-class citizen assurances
5. Guarantees under growing scale and increasingly 7. Learn from experience
uncertainties complex levels of uncertainty
Slide credit:Danny Weyns, “An Introduction to Self-adaptive Systems: A Contemporary Software Engineering Perspective”, Wiley 202 0
Wave 2: Architecture-based adaptation
Lack of principled engineering
Driver
approach
Topic Architecture perspective on self-
adaptation
Enabled Architecture as a driver to define
self-adaptive systems and to reason
about adaptation at runtime
9
Slide credit: Danny Weyns, “An Introduction to Self-adaptive Systems: A Contemporary Software Engineering Perspective”, Wiley 2020
What is software architecture?
▣ Fundamental structure of a software system
▣ Important is the process to arrive to the
structures: architectural decisions
▣ Related terms:
□ Design patterns (e.g. Gang of Four* patterns)
□ Architectural styles (e.g. MVC)
□ Component models (e.g. OSGI)
10
* See book: “Design Patterns: Elements of Reusable Object-Oriented Software”
What is architecture-based self-
adaptation?
▣ Class of self-adaptation approaches that relies
primarily on architectural models of the
system in the managing system
▣ Architectural model
▣ High-level view of a system as a collection of
components and connectors annotated with
properties that indicate component and system
attributes (reliability, performance, security, …)
11
Why architecture-based adaptation?
▣ Separation of concerns
▣ Integrated approach
▣ Leveraging consolidated efforts
▣ Abstraction to manage system change
▣ Dealing with system-wide concerns
▣ Facilitating scalability
12
A reference model for architecture-
based self-adaptation
Emphasis:
Defining self-adaptive systems
13
3-Layer model
“Components automatically configure their interaction in a
way that is compatible with an overall architectural
specification and achieves the goals of the system.”
“… the architectural level seems to provide the required
level of abstraction and generality to deal with the
challenges posed by self-adaption.”
J. Kramer and J. Magee, Self-adaptation: an architectural challenge, Future of Software Engineering, 2007
E. Gat, Three-layer Architectures, Artificial Intelligence and Mobile Robots, MIT/AAAI Press, 1997
14
3-Layer model
Responsible for re-planning and
introducing new goals
Goal
management
Responsible for executing
changes in the lower layer
Change
management based on status changes
Component
control Accomplishes the application
functionality of the system
15
3-Layer model
• Handles requests from the layer
below and introduction new goals
• Takes state and high-level goal to
produce plan to achieve goal
Goal
management
Reacts to changes in state of
the lower level by executing
Change actions to handle the new
management
situation
Component
control • Set of interconnected components
• Facilities to report current status of
components and perform
adaptations
16
DeltaIoT
Configurable options per mote Adaptation Goals
Uncertainties
- Distribution of messages to Average packet loss < 10%
Network interference
parents Average latency <= 5% of cycle time (12 mins)
Fluctuating traffic
- Transmission power Average energy consumption minimized
3-Layer model applied to DeltaIoT
• Network of motes & gateway
• Internal adaptation mechanisms,
e.g. request to re-transmit packets
if received data corrupted
• Management interface allows
collecting operating network data
and adapting motes’ settings
3-Layer model applied to DeltaIoT
• Contains parametrized plans to be
used for adapting network settings
• Parameters: mote id, parent ids
• Variables: transmission power,
distribution of packets to parents
• Logic: Upon observing a violation of
packet loss or latency, determines a
new system configuration,
instantiates plans for each mote that
needs to be adapted, sends plans to
management interface
3-Layer model applied to DeltaIoT
Invoked when change management
cannot handle an event in the system
(e.g. failure of a mote)
Creates a plan in response to “handle
failed mote” goal
E.g. reconfigure the links of the
affected part of the network to not use
the failed mote anymore (next slide)
Goal
management
in DeltaIoT
Exercise
Try to apply the 3-layer model in your exemplar
• What would be the responsibility of each layer?
22
Assumptions and challenges –
Component control
▣ Assumption: system is composed of
interconnected software components
□ Co-located or distributed on computing nodes
Model of a component,
in Darwin Architecture Description Operations on components An example component
Language (ADL) architecture
Assumptions and challenges –
Component control
▣ Main challenge: Preserving safe application
operation during change
□ Avoid undesirable transient behavior, ensure
components are passive and quiescent before change
Model of a component,
in Darwin Architecture Description Operations on components An example component
Language (ADL) architecture
Assumptions and challenges –
Change management
▣ Assumption: system has a precompiled set of
plans/tactics that respond to a predicted class
of state change
▣ Main challenges
□ Distribution □ Decentralization of control
How to obtain consistent How to reliably execute
views of system state on change in the presence of
which to base change partial failure?
decisions?
Assumptions and challenges –
Goal management
▣ Assumption: Goals are precisely specified & a
planner can be used by the system itself
▣ Main challenge (still largely open): how to deal
with unexpected situations for which there no
precompiled plans are available?
□ Some hints: reinforcement learning, “planning as
model-checking” <-- to be covered in next lectures
Exercise
Think of a distributed self-adaptive system like DeltaIoT
• How are decisions made at runtime?
• Can they be made in a more decentralized way?
• When would it make sense?
27
A framework for architecture-based
self-adaptation
Emphasis:
Reasoning about self-adaptation at runtime
28
Rainbow framework - motivation
1. Handling different systems that need to be
adapted at runtime: different component
models/architectural styles, properties of
interest, mechanisms supporting dynamic
change
2. Reduce costs in adding external control to a
system via reusing monitoring, modeling, and
problem-detection mechanisms
29
Rainbow
framework
Goal: keep the response time
below predefined maximum
30
Rainbow
framework
Maintains model of client-server
system (response time,
bandwidth, …)
Model expressed in the Acme
Architectural Description
Language (ADL)
Goal: keep the response time
below predefined maximum
31
Rainbow
framework
Periodically check response
time
If violation -> trigger adaptation
engine
invariant ([Link] < maxResponseTime) ! →
responseTimeStrategy(self);
Goal: keep the response time
below predefined maximum
32
Rainbow
framework
Applies adaptation strategy:
(i) load group too high -> add server;
(ii) available bandwidth of client too low -> move
client to other group
strategy responseTimeStrategy(ClientT C) {
let G = findConnectedServerGroup(C);
if (query("load", G) > maxServerLoad) {
[Link]();
return true;
}
let conn = findConnector(C, G);
if (query("bandwidth", conn) < minBandwidth) {
let G = findBestServerGroup(C);
[Link](G);
return true;
}
return false;
Goal: keep the response time
} below predefined maximum
33
Rainbow
framework
Executes actions of selected adaptation
strategy
Goal: keep the response time
below predefined maximum
34
How is reuse achieved in Rainbow?
Component model System concerns Reuse achieved
Different Different Adaptation infrastructure
Adaptation infrastructure, Properties,
Different Same
Mappings
Adaptation infrastructure, Types,
Same Different Rules, Mappings, Adaptation
operators
Adaptation infrastructure, Types,
Same Same Rules, Properties Mappings,
Adaptation operators
Exercise
Can you compare Rainbow and UPISAS…
• With respect to their motivation?
• With respect to the features/infrastructure they
provide?
36
Key insights from Wave 2
▣ Fundamental architectural concerns of self-
adaptation:
□ change management
□ goal management
▣ Architectural model offers appropriate
representation of system to make adaptation
decisions at runtime
37
