1 / 55

TOWARDS SELF-ADAPTIVE SOFTWARE-INTENSIVE SYSTEMS

TOWARDS SELF-ADAPTIVE SOFTWARE-INTENSIVE SYSTEMS. Hausi A. Müller University of Victoria, Canada IWPSE-EVOL Amsterdam, The Netherlands August 24-25, 2009. CONGRATULATIONS. 10 th Anniversary of International Workshop on Principles of Software Evolution (IWPSE)

arnoldo
Download Presentation

TOWARDS SELF-ADAPTIVE SOFTWARE-INTENSIVE SYSTEMS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TOWARDS SELF-ADAPTIVESOFTWARE-INTENSIVE SYSTEMS Hausi A. Müller University of Victoria, Canada IWPSE-EVOLAmsterdam, The NetherlandsAugust 24-25, 2009

  2. CONGRATULATIONS • 10th Anniversary of International Workshop on Principles of Software Evolution (IWPSE) • 5th Anniversary of ERCIM Workshop on Software Evolution (EVOL) • Tremendous achievements!Congratulations!

  3. 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 ProjectDesign and Evolution of Autonomic Application Software • SOA Governance • CA Canada Inc. (formerly Computer Associates), Toronto • Since 2005 • CSER/NSERC CRD ProjectLogging, Monitoring & Diagnosis Systems for Enterprise Applications • SEI (Software Engineering Institute), Pittsburgh • Since 1995 • SOA Governance and Service Oriented Computing • Ultra Large Scale Systems

  4. KEEP IN MIND … Ask Questions Any Time “Let’s make this a truly interactive event!”

  5. ENGINEERINGSELF-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 DagstuhlSeminar 08031 on Engineering Self-Adaptive Systems

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

  7. 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) Architect, design for software adaptation …Decentralized software evolution …

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

  9. 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 Co-evolve requirements, context, constraints, policies, code

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

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

  12. IBM GLOBAL SERVICES SERVICE INTEGRATION MATURITY MODEL (SIMM) • Ultimate goal: dynamically configurable services http://www.ibm.com/developerworks/webservices/library/ws-soa-simm/

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

  14. ARCHITECTURE-CENTRIC VS. CONTROL-CENTRIC ORCHESTRATION Architecture-centric Design and Views Control-Centric Design and Views

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

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

  17. FEEDBACK LOOPS ARE AT THE HEART OF DYNAMICAL SYSTEMS Feedback is ubiquitousin natural and engineered systems ... and in computing systems

  18. Continuous EvolutionProblems Synergy AmongRelated Problems ULS Systems Related Problems Self-Managing/ Autonomic Systems Self-Adaptive Systems Complexity Problems Adaption Problems

  19. Continuous EvolutionProblems Synergy AmongRelated Problems Software Evolution Problems ULS Systems Related Problems Self-Managing/ Autonomic Systems Self-Adaptive Systems Complexity Problems Adaption Problems

  20. 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 L. Northrop et al.: Ultra-Large-Scale Systems: The Software Challenge of the Future, SEI Tech Report, June 2006

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

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

  23. 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?

  24. 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.”

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

  26. CHANGE OF PERSPECTIVE • From satisfaction of requirements through traditional, top-down engineering • To satisfaction of requirements by regulation of complex, decentralized systems The system shall do this … but it may do this … as long as it does this … With adaptive systemsand feedback loops  How?

  27. 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 n-dimensional viability zone equilibrium

  28. Control Decide Resource Measure MOST FAMOUS FEEDBACK SYSTEMAUTONOMIC 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 Monitor and regulate

  29. 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 anelectronic circuit to improveperformance • an automatic control deviceto provide self-corrective action

  30. 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)

  31. CONTROLLER AS ANAUTONOMIC ELEMENT

  32. ACRA: A HIERARCHY OF AUTONOMIC ELEMENTS TO ORCHESTRATE INDICATORS IBM: An Architectural Blueprint for Autonomic Computing, 4th Ed. (2006)

  33. REALIZATION OF ADYNAMIC ARCHITECTURE • Feedback control system with disturbance and noise input Hellerstein, Diao, Parekh, Tilbury: Feedback Control of Computing Systems. John Wiley & Sons (2004)

  34. REALIZATION OF A DYNAMICARCHITECTURE • 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)

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

  36. 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 • Physical • Computing • Social • Engineering • Economic • Biological • Chemical • Therapeutic

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

  38. MODEL REFERENCE ADAPTIVE CONTROLLERS—MRAC FB

  39. MODEL REFERENCE ADAPTIVE CONTROLLERS—MRAC

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

  41. MODEL IDENTIFICATION ADAPTIVE CONTROLLERS—MIAC FB

  42. MODEL IDENTIFICATION ADAPTIVE CONTROLLERS—MIAC

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

  44. 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? Architecture-centric Design and Views Control-Centric Design and Views

  45. RESEARCH CHALLENGES • Model construction • Managing and leveraging uncertainty • Making control loops explicit

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

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

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

More Related