TOWARDS SELF-ADAPTIVESOFTWARE-INTENSIVE SYSTEMS

Hausi A. Müller University of Victoria, Canada

IWPSE-EVOLAmsterdam, The NetherlandsAugust 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

http://www.bseng.uvic.ca 47 courses; 15 software engineering courses

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 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

ENGINEERINGSELF-ADAPTIVE SYSTEMS

5

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 Müller, H.A.: SEAMS 2008 Panel—Report from DagstuhlDagstuhl

Seminar 08031 on Engineering Self-Adaptive SystemsSeminar 08031 on Engineering Self-Adaptive Systems

VERY HIGH EXPECTATIONSFOR 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 3DYNAMIC/RUNTIME STRUCTURES Analyzing Dynamic Change in Software Architectures

Jeff Kramer, Jeff Magee (Imperial College) Software Evolution and the Chemical Abstract Machine

Michel Wermelinger (University of Nova de Lisboa) A Procedural Model of Dynamic Adaptability and its

Description Language Noriki Amano, Takuo Watanabe (JAIST)

A Reflective Approach to Support Software Evolution Hidehiko Masuhara, Akinori Yonezawa (University of Tokyo)

Runtime Software Evolution based on Version Management Yasuhiko Sugiyama (Nihon University)

Dynamic Objects for Software Evolution in Distributed Object Systems Kurt Geihs, Holger Grunder (University of Frankfurt)

Decentralized Software Evolution Peyman Oreizy (University of California, Irvine)

Support for Evolution of System Through Software Composition R. Pandey, P. Devanbu, V. Akella (University of California,

Davis)

7Architect, design for software adaptation …Architect, design for software adaptation …

Decentralized software evolution …Decentralized software evolution …

SOFTWARE EVOLUTIONGREAT 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-1998Software Requirements Specifications

9

Co-evolve requirements, context, constraints, policies, Co-evolve requirements, context, constraints, policies, codecode

10

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: Steve Mills, VP IBM Software Group: The Future of Business, White Paper, The Future of Business, White Paper,

June 2007June 2007

http://www.ibm.com/developerworks/webservices/library/ws-soa-http://www.ibm.com/developerworks/webservices/library/ws-soa-simm/simm/

IBM GLOBAL SERVICES SERVICE INTEGRATION MATURITY MODEL (SIMM) Ultimate goal: dynamically configurable services

14

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 self-adaptation

15

ARCHITECTURE-CENTRIC VS. CONTROL-CENTRIC ORCHESTRATION

16

Control-Centric

Design and Views

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 G. Lewis, D. Smith: SOA and its Implications for Software Maintenance and Evolution, ICSM FoSM Software Maintenance and Evolution, ICSM FoSM

20082008

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 G. Lewis, D. Smith: SOA and its Implications for Software Maintenance and Evolution, ICSM FoSM Software Maintenance and Evolution, ICSM FoSM

20082008

FEEDBACK LOOPS ARE AT THE HEART OF DYNAMICAL SYSTEMS

19

Continuous EvolutionProblems

20

Continuous EvolutionProblems

21

Software Evolutio

n Problems

ULS CHALLENGES APPLY TO SOFTWARE EVOLUTION

The ULS book describes challenges inthree 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

22L. Northrop et al.: Ultra-Large-Scale Systems: The L. Northrop et al.: Ultra-Large-Scale Systems: The Software Challenge of the Future, SEI Tech Report, Software Challenge of the Future, SEI Tech Report,

June 2006June 2006

SPECIFIC CHALLENGES IN GOVERNANCESYSTEM 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 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?

Understanding why indicators change 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 128-bit 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

26Keep in mind: Whenever we talk about Keep in mind: Whenever we talk about “compliance,” we often really mean “compliance,” we often really mean

“conformance.”“conformance.”

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

To satisfaction of requirements by regulation of complex, decentralized systems

28With adaptive systemsand feedback loops How?How?

The system The system shall do shall do this … but this … but it may do it may do this … this … as long as as long as it does it does this …this …

BIOLOGICAL SYSTEMS

The internal mechanisms of humans continuously work together to maintainessential variables within physiologicallimits—the n-dimensional viability zone

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 returningto the equilibrium zone

29

n-dimension

al viability

zoneequilibri

um

MOST FAMOUS FEEDBACK SYSTEMAUTONOMIC NERVOUS SYSTEM (ANS)

30

Autonomic nervous system (ANS) Parasympathetic

Day-to-day internal processes Sympathetic

Stressful situation processes

TemperatureHeart rate

Breathing rateBlood pressure

Blood sugarPupil dilation

TearsDigestion

Immune response Decide

Resource

Measur

eControl

Monitor and regulateMonitor and regulate

FEEDBACK SYSTEMS Merriam-Webster’s Online Dictionarythe return to the input of a part of the output of a machine, system, or process producing changes in an

electronic circuit to improveperformance

an automatic control deviceto provide self-corrective action

31

APPROACH: FEEDBACK LOOP

32

Dobson, S. et al.: A Survey of Autonomic Communications. ACM Dobson, S. et al.: A Survey of Autonomic Communications. ACM Trans. on Autonomous and Adaptive Systems (TAAS) 1(2):223-259 Trans. on Autonomous and Adaptive Systems (TAAS) 1(2):223-259

(2006)(2006)

CONTROLLER AS ANAUTONOMIC ELEMENT

33

ACRA: A HIERARCHY OF AUTONOMIC ELEMENTS TO ORCHESTRATE INDICATORS

34

IBM: An Architectural Blueprint IBM: An Architectural Blueprint for Autonomic Computing, 4th Ed. for Autonomic Computing, 4th Ed.

(2006)(2006)

REALIZATION OF ADYNAMIC ARCHITECTURE

Feedback control system with disturbance and noise input

35Hellerstein, Diao, Parekh, Tilbury: Feedback Hellerstein, Diao, Parekh, Tilbury: Feedback

Control of Computing Systems. John Wiley & Sons Control of Computing Systems. John Wiley & Sons (2004) (2004)

REALIZATION OF A DYNAMICARCHITECTURE

36

Reference input Goal, objectives, specified

desired output Control Error

Reference input minus (measured) transduced output

Control Input Parameters which affect

behavior of the system—number of threads, CPU, memory, parameters

Disturbance input Affects control input—arrival

rate

Reference input Goal, objectives, specified

desired output Control Error

Reference input minus (measured) transduced output

Control Input Parameters which affect

behavior of the system—number of threads, CPU, memory, parameters

Disturbance input Affects control input—arrival

rate

Controller Change control input to

achieve reference input—design is based on a model of the managed system

Managed system Dynamical system, process,

plant—often characterized by differential equations

Measured output Measurable feature of the

system—response time Noise input

Affects measured output Transducer

Transforms measured output to compare with reference input

Controller Change control input to

achieve reference input—design is based on a model of the managed system

Managed system Dynamical system, process,

plant—often characterized by differential equations

Measured output Measurable feature of the

system—response time Noise input

Affects measured output Transducer

Transforms measured output to compare with reference input

Hellerstein, Diao, Parekh, Tilbury: Feedback Hellerstein, Diao, Parekh, Tilbury: Feedback Control of Computing Systems. John Wiley & Sons Control of Computing Systems. John Wiley & Sons

(2004) (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 IDENTIFICATIONMODEL 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

38

Physical Computing Social Engineering

Economic Biological Chemical Therapeutic

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

40

FB

MODEL REFERENCE ADAPTIVE CONTROLLERS—MRAC

41

MODEL IDENTIFICATION ADAPTIVE CONTROLLERS—MIAC

Perform system identification while system is running to modify the control laws Create model structure and perform parameter estimation typically using the Least Squares method

Cautious adaptive controllers 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

43

FB

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 QUESTIONSEVOLUTION 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?

46

Control-

Centric

Design and

Views

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 Make feedback loops explicit and first class

Architecture-centric vs. control-centric orchestration 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 systems compared to static, non-adaptive systems 52

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, 4 th 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 IEEE International Workshops on Visualizing Software for Understanding and Analysis

MESOA 2009 3rd International Workshop on a Research Agenda for Maintenance and Evolution of Service-Oriented Systems

SCAM 2009 Ninth IEEE International Working Conferenceon Source Code Analysis and Manipulation

WSE 2009 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