TOWARDS SELF-ADAPTIVE
SOFTWARE-INTENSIVE
SYSTEMS
Hausi A. Müller
University of Victoria, Canada
IWPSE-EVOL
Amsterdam, The Netherlands
August 24-25, 2009
CONGRATULATIONS
10th Anniversary of International Workshop on
Principles of Software Evolution (IWPSE)
 5th Anniversary of ERCIM Workshop on Software
Evolution (EVOL)


Tremendous achievements!
Congratulations!
2
MY BACKGROUND

Founding Director of Bachelor of Software Engineering




Associate Dean Research, Faculty of Engineering
IBM Toronto




Since 1991
CSER/NSERC CRD Project
Design and Evolution of Autonomic Application Software
SOA Governance
CA Canada Inc. (formerly Computer Associates), Toronto



http://www.bseng.uvic.ca
47 courses; 15 software engineering courses
Since 2005
CSER/NSERC CRD Project
Logging, Monitoring & Diagnosis Systems for Enterprise Applications
SEI (Software Engineering Institute), Pittsburgh



Since 1995
SOA Governance and Service Oriented Computing
Ultra Large Scale Systems
3
KEEP IN MIND …
4
ENGINEERING
SELF-ADAPTIVE SYSTEMS
High degree of dynamism
Goals / policies change at run-time
Validation and verification
performed at run-time
Agility at run-time
Müller, H.A.: SEAMS 2008 Panel—Report from Dagstuhl
Seminar 08031 on Engineering Self-Adaptive Systems
5
VERY HIGH EXPECTATIONS
FOR SELF-ADAPTABILITY
Software systems must become more






versatile, flexible, resilient, dependable
service-oriented, mashable, inter-operable,
continuously available, robust, decentralized,
energy-efficient, recoverable, customizable,
configurable, self-healing, configurable,
self-optimizing, self-*, …
by adapting to changing operational contexts and
environments
6
IWPSE 1998: SESSION 3
DYNAMIC/RUNTIME STRUCTURES

Analyzing Dynamic Change in Software Architectures


Software Evolution and the Chemical Abstract Machine


Kurt Geihs, Holger Grunder (University of Frankfurt)
Decentralized Software Evolution


Yasuhiko Sugiyama (Nihon University)
Dynamic Objects for Software Evolution in Distributed Object Systems


Hidehiko Masuhara, Akinori Yonezawa (University of Tokyo)
Runtime Software Evolution based on Version Management


Noriki Amano, Takuo Watanabe (JAIST)
A Reflective Approach to Support Software Evolution


Michel Wermelinger (University of Nova de Lisboa)
A Procedural Model of Dynamic Adaptability and its Description Language


Jeff Kramer, Jeff Magee (Imperial College)
Peyman Oreizy (University of California, Irvine)
Support for Evolution of System Through Software Composition

R. Pandey, P. Devanbu, V. Akella (University of California, Davis)
Architect, design for software adaptation …
Decentralized software evolution …
7
SOFTWARE EVOLUTION
GREAT SUCCESS STORIES
Many methods, techniques, and tools
 Artifact identification and dependencies,
(de)-composition
 Models, meta-models, exchange formats
 Analysis: impact, change, code smells,
analysis paralysis, patterns
 (Multi-dimensional) separation of concerns
 Tooling: parsing, repositories, visualization,
analysis, program transformation
 Several distinct research communities


ICSM, IWPSE, EVOL, ICPC, IWPC, WCRE, PASTE,
SCAM, MSR, VISSOFT, ATEM, and many others
8
CO-SOFTWARE EVOLUTION


Do we concentrate too much on the code?
Are we too reactive and not enough pro-active?


Can we apply and inject our evolution experience into new
development paradigms (e.g., service oriented systems)?
IEEE Standard 830-1998
Software Requirements Specifications
Product
functions
User
characteristics
Nonfunctional
requirements
Context and
environment
Constrain
ts
Co-evolve requirements, context, constraints, policies, code
9
Evolving
Software
Systems
ULS
Systems
Autonomic
Systems
What do
these
systems
have in
common?
SOA
Systems
Control
Systems
10
Evolving
Software
Systems
Selfmanaging
Systems
SOA
Systems
Feedback
Loops
ULS
Systems
Control
Systems
Autonomic
Systems
11
OUTLINE
Motivation for self-adaptive systems
 SOA governance and evolution governance
 Realizing self-adaptive systems using feedback loops
 Evolution of self-adaptive systems
 Research challenges

12
RISE OF THE DYNAMIC VALUE SET

The value chains of today are the result of linked individual business
tasks that come together to form a valuable end product
Just like a physical assembly line, each participant in the value chain
contributes something to increase the value of the end product
 Although these value chains have become increasingly distributed,
they still tend to be predictable, structured and linear


Set of service providers is changing dynamically based on who is in the
best position to perform a given task at a given time
Service providers are becoming interconnected to the point that mapping
their relationships yields more of a net than the traditional linear chain
 Familiar value chains are morphing into dynamic value nets


Value nets are orchestrated by the organization that delivers the end
product to market

This orchestration may be the lead brand organization’s unique value add
13
Steve Mills, VP IBM Software Group: The
Future of Business, White Paper, June 2007
IBM GLOBAL SERVICES SERVICE
INTEGRATION MATURITY MODEL
(SIMM)

Ultimate goal: dynamically configurable services
14
http://www.ibm.com/developerworks/webservices/library/ws-soa-simm/
SELF-ADAPTIVE SYSTEMS:
ANTICIPATED AND UN-ANTICIPATED
ADAPTATION

Anticipated adaption


The different contexts to be accommodated at run-time
are known at design-time
Un-anticipated adaption
The variation possibilities are recognized and computed
at run-time
 The decision which variant is best is computed using
self-awareness and environmental context information


Pure un-anticipated self-adaptive system are rare

Most self-adaptive systems feature a combination of
anticipated self-adaptation and un-anticipated selfadaptation
15
Control-Centric
Design and Views
Architecture-centric
Design and Views
ARCHITECTURE-CENTRIC VS.
CONTROL-CENTRIC
ORCHESTRATION
16
SOA GOVERNANCE
Governance has been rated as the main inhibitor
of SOA adoption
 SOA governance provides a set of policies, rules,
and enforcement mechanisms for developing,
using and evolving service-oriented systems, and
for analysis of their business value
 SOA governance includes policies, procedures,
roles and responsibilities for design-time
governance and runtime governance

17
G. Lewis, D. Smith: SOA and its Implications for
Software Maintenance and Evolution, ICSM FoSM 2008
SOA GOVERNANCE TYPES

Design-time governance
Includes elements such as rules for strategic identification of
services, development, and deployment of services; reuse; and
legacy system migration to services
 Enforces consistency in use of standards, SOA infrastructure
and processes


Run-time governance
Enforces rules to ensure that services are executed only in
ways that are legal and that important runtime data is logged
 Service level agreements (SLAs) including runtime validation
of contractual specifications on performance, throughput, and
availability; the use of automated metrics for tracking and
reporting; and problem management

18
G. Lewis, D. Smith: SOA and its Implications for
Software Maintenance and Evolution, ICSM FoSM 2008
FEEDBACK LOOPS ARE AT THE
HEART OF DYNAMICAL SYSTEMS
Feedback is ubiquitous
in natural and
engineered systems
... and in computing systems
19
Continuous Evolution
Problems
20
Continuous Evolution
Problems
Software
Evolution
Problems
21
ULS CHALLENGES APPLY TO
SOFTWARE EVOLUTION

The ULS book describes challenges in
three broad areas:
Design and evolution
 Orchestration and control
 Monitoring and assessment


The challenges in all three areas apply readily to
the maintenance and evolution of software
systems
L. Northrop et al.: Ultra-Large-Scale Systems: The Software
Challenge of the Future, SEI Tech Report, June 2006
22
SPECIFIC CHALLENGES IN GOVERNANCE
SYSTEM MONITORING AND ASSESSMENT

With respect to governance
How do we evaluate the effectiveness of system design,
operation, evolution, orchestration, and control?
 How do we monitor and assess system state, behavior,
and overall health and well being?


Challenges include





Defining indicators
Understanding why indicators change
Prioritizing the indicators (e.g., to form a hierarchy)
Handling change and imperfect information
Gauging the human elements
23
SPECIFIC CHALLENGES FOR
SYSTEM MONITORING AND
ASSESSMENT

Defining indicators


Understanding why indicators change


What system-wide, end-to-end, and local quality-of-service
indicators are relevant to meeting user needs and ensuring
the long-term viability of the subject system?
What adjustments or changes to system elements and
interconnections will improve or degrade these indicators?
Prioritizing the indicators
Which indicators should be examined under what conditions?
 Are indicators ordered by generality?


General overall health reading versus specialized particular diagnostics
24
SPECIFIC CHALLENGES FOR
SYSTEM MONITORING AND ASSESSMENT

Handling change and imperfect information



How do the monitoring and assessment processes handle
continual changes to components, services, usage, or
connectivity?
Imperfect information can be inaccurate, stale, or imprecise.
Gauging the human elements

What are the indicators of the health and performance of the
people, business, and organizational elements of the SOA
subject system?
25
BRIEF SIDE NOTE ...
COMPLIANCE VS. CONFORMANCE

Compliance implies adherence to a standard or regulation
You either pass or fail
A company can be in compliance with Sarbanes-Oxley auditing requirements
A browser can comply with a specific security requirement by providing 128bit security and TLS encryption
 Service delivery is compliant with an SLA




Conformance describes how well a given implementation
matches or does not match a standard or a reference
A conformance testing suite that returns results that certain aspects of an
implementation match a reference implementation
 A Web services implementation can conform with the WS-I basic
interoperability profile
 Service delivery is conformance with an SLA depends on the importance of
the customer


A lack of conformance does not necessarily imply a value judgment
the way that lack of compliance with a law or regulation does
Keep in mind: Whenever we talk about “compliance,”
we often really mean “conformance.”
26
MONITORING
DYNAMICAL SYSTEMS

Perform critical regression tests dynamically to observe
satisfaction of requirements
Testing run-time (and design-time) governance
 Govern and enforce rules and regulations


Perform V&V operations (transformations) regularly to
ascertain V&V properties




Monitor compliance and conformance
Assess whether services are used properly
Recognizing normal and exceptional behaviour
Monitor functional and non-functional requirements when
the environment evolves



SLAs
Assess and maintain quality of service (QoS)
Manage tradeoffs
27
CHANGE OF PERSPECTIVE


From satisfaction of requirements through
traditional, top-down engineering
The system
shall do this
… but it may
do this …
as long as it
does this …
To satisfaction of requirements by regulation of
complex, decentralized systems
How?
With adaptive systems
and feedback loops 
28
BIOLOGICAL SYSTEMS

The internal mechanisms of humans
continuously work together to maintain
essential variables within physiological
limits—the n-dimensional viability zone
n-dimensional
viability zone
equilibrium
 The goal of human self-managing
behavior is directly linked to survivability

If the external or internal environment pushes
the system outside its physiological equilibrium
zone, the system will work towards returning
to the equilibrium zone
29
MOST FAMOUS FEEDBACK SYSTEM
AUTONOMIC NERVOUS SYSTEM (ANS)
Autonomic nervous system (ANS)
Measure
Temperature
Heart rate
Breathing rate
Blood pressure
Blood sugar
Pupil dilation
Tears
Digestion
Immune response
Resource
Sympathetic
 Stressful situation processes
Decide

Parasympathetic
 Day-to-day internal processes
Control

Monitor and regulate
30
FEEDBACK SYSTEMS

Merriam-Webster’s Online Dictionary
the return to the input of a part of the output of a machine,
system, or process


producing changes in an
electronic circuit to improve
performance
an automatic control device
to provide self-corrective action
31
APPROACH: FEEDBACK LOOP
32
Dobson, S. et al.: A Survey of Autonomic Communications. ACM Trans.
on Autonomous and Adaptive Systems (TAAS) 1(2):223-259 (2006)
CONTROLLER AS AN
AUTONOMIC ELEMENT
33
ACRA: A HIERARCHY OF AUTONOMIC
ELEMENTS TO ORCHESTRATE INDICATORS
34
IBM: An Architectural Blueprint for
Autonomic Computing, 4th Ed. (2006)
REALIZATION OF A
DYNAMIC ARCHITECTURE

Feedback control system with
disturbance and noise input
Hellerstein, Diao, Parekh, Tilbury: Feedback Control of
Computing Systems. John Wiley & Sons (2004)
35
REALIZATION OF
A DYNAMIC
ARCHITECTURE

Reference input



Reference input minus (measured)
transduced output
Control Input


Goal, objectives, specified desired
output
Control Error

Parameters which affect behavior of
the system—number of threads, CPU,
memory, parameters
Disturbance input


Affects control input—arrival rate
Controller


Managed system


Measurable feature of the system—
response time
Noise input


Dynamical system, process, plant—
often characterized by differential
equations
Measured output


Change control input to achieve
reference input—design is based on a
model of the managed system
Affects measured output
Transducer

Transforms measured output to
compare with reference input
36
Hellerstein, Diao, Parekh, Tilbury: Feedback Control of
Computing Systems. John Wiley & Sons (2004)
ADAPTIVE CONTROL
Modify the control law to cope by changing
system parameters while the system is running
 Different from Robust Control in the sense that it
does not need a priori information about the
uncertainties



Robust Control includes the bounds of uncertainties in
the design of the control law.
Thus, if the system changes are within the bounds, the
control law needs no modification.
37
SYSTEM IDENTIFICATION
MODEL BUILDING
Mathematical tools and algorithms to build
dynamical models from measured data
 A dynamical mathematical model in this context
is a mathematical description of the dynamic
behavior of a system or process in either the time
or frequency domain
 Theories and processes





Physical
Computing
Social
Engineering




Economic
Biological
Chemical
Therapeutic
38
MODEL REFERENCE ADAPTIVE
CONTROLLERS—MRAC
Also referred to as Model Reference Adaptive
System (MRAS)
 Closed loop controller with parameters that can be
updated to change the response of the system
 The output of the system is compared to a desired
response from a reference model (e.g., simulation
model)
 The control parameters are updated based on this
error
 The goal is for the parameters to converge to ideal
values that cause the managed system response to
match the response of the reference model.

39
MODEL REFERENCE ADAPTIVE
CONTROLLERS—MRAC
F
B
40
MODEL REFERENCE ADAPTIVE
CONTROLLERS—MRAC
41
MODEL IDENTIFICATION ADAPTIVE
CONTROLLERS—MIAC

Perform system identification while system is
running to modify the control laws


Cautious adaptive controllers


Create model structure and perform parameter
estimation typically using the Least Squares method
Use current system identification to modify control law,
allowing for system identification uncertainty
Certainty equivalent adaptive controllers

Take current system identification to be the true
system, assume no uncertainty
42
MODEL IDENTIFICATION ADAPTIVE
CONTROLLERS—MIAC
F
B
43
MODEL IDENTIFICATION ADAPTIVE
CONTROLLERS—MIAC
44
MIAC AND MRAC ARCHITECTURES
FOR DYNAMICAL COMPUTING
SYSTEMS


The goal of both approaches is to adjust the
control laws in the controller
MRAC approach


Reference model is static—given or pre-computed and
not changed at run-time
MIAC approach

Reference model is changed at run-time using system
identification methods
45
DEBATE QUESTIONS
EVOLUTION CONCERNS

How different are the maintainability and
evolution concerns for self-adaptive systems
compared to static, non-adaptive systems?
Is a system that is designed for dynamic
variability or adaptation easier to maintain?
Control-Centric
Design and Views
Architecture-centric
Design and Views

46
RESEARCH CHALLENGES

Model construction

Managing and leveraging uncertainty

Making control loops explicit
47
RESEARCH CHALLENGES:
MODEL CONSTRUCTION

The process of designing feedback-based computing systems
requires the construction of models which quantify the effect of
control inputs on measured outputs
While performance engineering and queuing theory have developed
advanced models for many different applications, we need models for
many other quality-of-service indicators that come into play in dynamical
applications
 For some of these criteria (e.g., trust) quantification is difficult
 What system-wide, end-to-end, and local quality-of-service indicators are
relevant to meeting user needs?


Models are also needed to design trade-off analyses schemes for
combinations of quality-of-service indicators

Developing feedback models for quality-of-service indicators for
various application domains is a major challenge

Models and quality-of-service indicators related to governance,
compliance, and service-level agreements are of particular importance
for service-oriented business processes and applications
48
RESEARCH CHALLENGES:
MANAGING AND LEVERAGING
UNCERTAINTY






When we model potential disturbances from the environment of a system
(e.g., unexpected saturation of the network) or satisfy requirements by
regulation (i.e., trade-off analysis among several extra-functional
requirements), we introduce some uncertainty
Therefore, designers and maintainers of such dynamical systems should
manage uncertainty because the environment may change in unexpected
ways and, as a result, the system may adapt in such a way that was not
foreseeable at design time
Introducing uncertainty requires trade-offs between flexibility and
assurance
For a maintainer it is critical to know which parts of the environment are
assumed to be fixed and which are expected to introduce uncertainty
Moreover, assurance and compliance criteria should be continuously
validated at run-time—not just at system acceptance time
Thus, understanding, managing, and leveraging uncertainty is important
for delivering evolving systems with reliability and assurance guarantees
49
RESEARCH CHALLENGES:
MAKING CONTROL LOOPS EXPLICIT

Investigate architecture-centric vs. control-centric design and run-time views
for evolving systems

Software engineers are trained to develop abstractions that hide complexity

Designers of evolving systems will likely realize significant benefits by
raising the visibility of control loops and specifying the major components
and characteristics of the control loops explicitly




When arrangements of multiple control loops interact, system design and analysis
should cover their interactions
As control grows more complex, it is important for the control loops to be explicit in
design and analysis
Investigate the trade-offs between hiding the complexity of feedback loops
and treating feedback loops as first class objects with respect to the
construction and operation of evolving systems
Further benefits could be realized by identifying common forms of
adaptation and then distilling design and V&V obligations
50
CHALLENGE FOR SOFTWARE
EVOLUTION COMMUNITIES
To instrument software systems with manageability
endpoints—sensor and effectors—using the reverse
engineering and transformation technology
developed over the past 15 years
 To monitor and control software systems and their
environments at run-time at unprecedented levels

51
CONCLUSIONS



Changes in traditional value chains are giving rise to
interconnected, dynamic value nets
To be able to observe and possibly orchestrate the
continuous evolution of dynamical systems in a complex
and changing environment, we need to push the
monitoring of evolving systems to unprecedented levels
Monitoring evolving systems using feedback loops


Architecture-centric vs. control-centric orchestration




Make feedback loops explicit and first class
Recognize the limitations of evolutionary developments
Combination of anticipated and un-anticipated adaptation
Instrument systems from the ground up for KPIs
Maintainability and evolution concerns for self-adaptive 52
systems compared to static, non-adaptive systems
TO PROBE FURTHER


Hellerstein, J.L., Diao, Y., Parekh, S., Tilbury, D.M.: Feedback Control
of Computing Systems. John Wiley & Sons (2004)
Northrop, L., et al.: Ultra-Large-Scale Systems. The Software Challenge of the Future. SEI Tech
Report, 134 pages, ISBN 0-9786956-0-7 (2006) http://www.sei.cmu.edu/uls

Lewis, G., Smith, D.: SOA and its Implications for Maintenance and Evolution, ICSM FoSM (2008)

Mills, S.: The Future of Business, White Paper (2007)

IBM: An Architectural Blueprint for Autonomic Computing, 4th Ed. (2006)






Huebscher, M.C., McCann, J.A.: A Survey of Autonomic Computing—Degrees, Models, and
Applications. ACM Computing Surveys, 40 (3):7:1-28 (2008)
Dobson, S., Denazis, S., Fernandez, A., Gaiti, D., Gelenbe, E., Massacci, F., Nixon, P., Saffre, F.,
Schmidt, N., Zambonelli, F.: A Survey of Autonomic Comm.. ACM TAAS 1(2):223-259 (2006)
Diao, Y., Hellerstein, J.L., Parekh, S., Griffith, R., Kaiser, G.E., Phung, D.: A Control Theory
Foundation for Self-Managing Computing Systems. IEEE Journal on Selected Areas in
Communications 23(12):2213-2222 (2005)
Müller, H.A., Pezzè, M., Shaw, M.: Visibility of Control in Adaptive System.
In: 3rd ACM/IEEE International ICSE ULSSIS 2008, pp. 23-26 (2008)
Müller, H.A., Kienle, H.M., Stege, U.: Autonomic Computing: Now You See It, Now You Don’t—
Design and Evolution of Autonomic Software Systems. In: De Lucia, A., Ferrucci, F. (eds.):
In ISSL, LNCS 5413, pp. 32–54 (2009)
Brun, Y., Di Marzo Serugendo, J., Gacek, C., Giese, H., Kienle, H.M., Litoiu, M., Müller,
H.A., Pezzè, M., Shaw, M.: Engineering Self-Adaptive Systems through Feedback Loops,
In: Software Engineering for Self-Adaptive Systems, LNCS 5527, pp. 47-69 (2009)
53
HOPE TO SEE YOU ALL IN
EDMONTON IN SEPTEMBER

ICSM 2009—September 20-26


IEEE International Conference on Software Maintenance
(ICSM), Edmonton, Alberta
VISSOFT 2009


MESOA 2009


Ninth IEEE International Working Conference
on Source Code Analysis and Manipulation
WSE 2009


3rd International Workshop on a Research Agenda for Maintenance and
Evolution of Service-Oriented Systems
SCAM 2009


IEEE International Workshops on Visualizing Software for
Understanding and Analysis
11th IEEE International Symposium on Web Systems Evolution
SEAMS 2010—May

Software Engineering for Adaptive Systems (SEAMS)
Workshop at ICSE 2010, Capetown, South Africa
54
QUESTIONS, FEEDBACK, COMMENTS,
IDEAS, AHA-EXPERIENCE, INSIGHTS, ...
55