• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Hausi Müller - Towards Self-Adaptive Software-Intensive Systems
 

Hausi Müller - Towards Self-Adaptive Software-Intensive Systems

on

  • 1,930 views

This set of slides was used by Prof. Hausi Müller for an invited talk given at the CHOOSE Forum 2008.

This set of slides was used by Prof. Hausi Müller for an invited talk given at the CHOOSE Forum 2008.

Statistics

Views

Total Views
1,930
Views on SlideShare
1,894
Embed Views
36

Actions

Likes
1
Downloads
0
Comments
0

3 Embeds 36

http://choose.s-i.ch 33
http://www.slideshare.net 2
http://192.168.10.100 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Hausi Müller - Towards Self-Adaptive Software-Intensive Systems Hausi Müller - Towards Self-Adaptive Software-Intensive Systems Presentation Transcript

    • TOWARDS SELF-ADAPTIVE SOFTWARE-INTENSIVE SYSTEMS Hausi A. Müller University of Victoria, Canada Choose Forum 2008 Bern, Switzerland December 8, 2008
    • MY BACKGROUND
      • Founding Director of Bachelor of Software Engineering
        • http://www.bseng.uvic.ca
        • 47 courses; 15 software engineering courses
      • IBM Toronto
        • Since 1991
        • CSER/NSERC CRD Project: Design and Evolution of Autonomic Application Software
        • SOA and Service Oriented Programming Models
      • CA Canada Inc. (formerly Computer Associates), Toronto
        • Since 2005
        • CSER/NSERC CRD Project: Logging, Monitoring and Diagnosis Systems for Enterprise Software Applications
      • SEI (Software Engineering Institute), Pittsburgh
        • Since 1995
        • SOA and Service Oriented Computing
        • Ultra Large Scale Systems
    • 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
    • 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
    • OUTLINE
      • Motivation for self-adaptive systems
      • Challenges in SOA governance
      • Realizing self-adaptive systems using feedback loops
      • Maintainability of self-adaptive systems
      • Research challenges
    • 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
      Steve Mills, VP IBM Software Group: The Future of Business, White Paper, June 2007
    • IBM GLOBAL SERVICES SERVICE INTEGRATION MATURITY MODEL (SIMM) http://www.ibm.com/developerworks/webservices/library/ws-soa-simm/
      • Ultimate goal: dynamically configurable services
    • 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
    • ARCHITECTURE-CENTRIC VS. CONTROL-CENTRIC SOA ORCHESTRATION Control-Centric Design and Views
    • KEY PERFORMANCE INDICATORS (KPI) AND QUALITY-OF-SERVICE INDICATORS XML and Web Services Unleashed, SAMS Publishing Instrumenting all Levels for Indicators
    • 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
      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
      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
    • Continuous Evolution Problems
    • ULS CHALLENGES APPLY TO SOA
      • 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 SOA systems and in particular to the issues of governance
      L. Northrop et al.: Ultra-Large-Scale Systems: The Software Challenge of the Future, SEI Tech Report, June 2006
    • SPECIFIC CHALLENGES IN GOVERNANCE SYSTEM MONITORING AND ASSESSMENT
      • With respect to governance
        • How do we evaluate the effectiveness of SOA 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
    • 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 SOA 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
    • 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?
    • 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
      Keep in mind: Whenever we talk about “compliance,” we often really mean “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
    • CHANGE OF PERSPECTIVE
      • From satisfaction of requirements through traditional, top-down engineering
      • To satisfaction of requirements by regulation of complex, decentralized systems
      With adaptive systems and feedback loops  How? The system shall do this … but it may do this … as long as it does this …
    • BIOLOGICAL SYSTEMS
      • The internal mechanisms of humans continuously work together to maintain essential variables within physiological limits—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 returning to the equilibrium zone
      n-dimensional viability zone equilibrium
    • MOST FAMOUS FEEDBACK SYSTEM AUTONOMIC NERVOUS SYSTEM (ANS)
      • Autonomic nervous system (ANS)
      • Parasympathetic
        • Day-to-day internal processes
      • Sympathetic
        • Stressful situation processes
      Temperature Heart rate Breathing rate Blood pressure Blood sugar Pupil dilation Tears Digestion Immune response Decide Resource Measure Control Monitor and regulate
    • 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
    • APPROACH: FEEDBACK LOOP 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
    • HIERARCHY OF AUTONOMIC ELEMENTS TO ORCHESTRATE INDICATORS; ACRA 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)
    • REALIZATION OF A DYNAMIC ARCHITECTURE
      • 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
      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.
    • 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
    • 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.
    • MODEL REFERENCE ADAPTIVE CONTROLLERS—MRAC FB
    • MODEL REFERENCE ADAPTIVE CONTROLLERS—MRAC
    • 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
    • MODEL IDENTIFICATION ADAPTIVE CONTROLLERS—MIAC FB
    • MODEL IDENTIFICATION ADAPTIVE CONTROLLERS—MIAC
    • 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
    • MAINTAINABILITY CONCERNS
      • How different are the maintainability concerns for self-adaptive SOA systems compared to static, non-adaptive SOA systems?
      • Is a SOA system that is designed for dynamic variability or adaptation easier to maintain?
      Control-Centric Design and Views
    • RESEARCH CHALLENGES
      • Model construction
      • Managing and leveraging uncertainty
      • Making control loops explicit
    • 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
    • RESEARCH CHALLENGES: MANAGING AND LEVERAGING UNCERTAINTY
      • When we model potential disturbances from the environment of an SOA 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 SOA systems with reliability and assurance guarantees
    • RESEARCH CHALLENGES: MAKING CONTROL LOOPS EXPLICIT
      • Investigate architecture-centric vs. control-centric design and run-time views for SOA systems
      • Software engineers are trained to develop abstractions that hide complexity
      • Designers of SOA 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 SOA systems
      • Further benefits could be realized by identifying common forms of adaptation and then distilling design and V&V obligations
    • 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 dynamical 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 concerns for self-adaptive 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 Software 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 Communications. 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)
    • MARK YOUR CALENDARS HOPE TO SEE YOU ALL IN CANADA IN 2009
      • ICSE 2009—May 16-24
        • ACM/IEEE International Conference on Software Engineering (ICSE), Vancouver, British Columbia
      • ICSM 2009—September 20-26
        • IEEE International Conference on Software Maintenance (ICSM), Edmonton, Alberta
    • SEAMS 2009
        • http://www.seams2009.cs.uvic.ca
      • ACM/IEEE Software Engineering for Adaptive and Self-Managing Systems
        • Two-Day ICSE Workshop
        • Mon/Tue, May 18-19, 2009
        • Vancouver, British Columbia, Canada
      • Important Dates
        • Submission deadline: Saturday, January 26, 2009
        • Camera ready copy: Thursday, February 19, 2009
      • General Chair
        • Hausi A. Müller, University of Victoria, Canada
      • Program Chair
        • Jeff Magee, Imperial College, UK
    • VISSOFT 2009
      • IEEE International Workshops on Visualizing Software for Understanding and Analysis
        • Two-Day Workshop collocated with ICSM 2009
        • Fri/Sat, September 25-26, 2009
        • Edmonton, Alberta, Canada
      • General Chair
        • Hausi A. Müller, University of Victoria, Canada
      • Program Chair
        • Michele Lanza, University of Lugano, Switzerland
        • Margaret-Anne Storey, University of Victoria, Canada
    • QUESTIONS, FEEDBACK, COMMENTS, IDEAS, AHA-EXPERIENCE, INSIGHTS, ...