Themes

1. Themes • Select 4 themes for breakout sessions • Organisers identified 8 themes • Summary of the themes from the introductory slides • Participants to rephrase or propose new themes • Participants to voteon themes thatthey would like to join the discussions

2. Breakout Sessions • The core of the discussions and the roadmap paper • actively participate in the discussions • willing to continue working after the seminar • Each group • moderator for guiding the discussions • scribe for taking notes and report back to the plenary • organisers may roam between the groups

3. Summary of the Themes • requirements: • design: models, feedback control, software architectures, configurable components, how to integrate reusable and problem-specific solutions, reference architectures, modelling formalisms, feature modelling, composition, variability spaces, product-line, self-organization as a means to build layered systems from adaptive components • programming: loose programming techniques • evaluation: (run-time) V&V, testing, benchmarking, metrics, control science, exemplars, correctness • evolution: reuse • processes: balancing design- and run-time effort, development support • collect: • analyse: techniques, quantitative (Markov) • decide: utility functions • assurances: model fidelity vs. trusted verification, self-organising systems, who cares about assurances?, architectures where failure is not a problem • applications: highly dynamic and massively distributed systems, cloud computing, what is needed to apply them?, ultra large scale systems, context-aware (including management), service-oriented architectures, end-user design • socio-technical aspects • self-adaptation vs self-organisation: methods and techniques, how to engineer self-organisation • manage/architect competition-cooperation of self-adaptive software systems • foreseen vs unforeseen system evolutions, boundaries and role of context, dealing with uncertainty, dynamism • elasticity vs. change management • balancing quality of service vs. over-provisioning vs. cost of Ownership • reactive vs. proactive adaptation • feedback control vs. other adaptation strategies • issues: uncertainty (volatility), dynamism, scalability, coordination, policies, design spaces

4. Some General Themes • Validation of the adaptation • Design space for adaptation • The spectrum of adaptive systems • Control science or run-time checking • Balancing design- and run-time effort • Top-down vs bottom-up • Implementing adaptation • Reasons for adaptation

5. Validation of the Adaptation • Conventional model of failure • Naïve model • No repair mechanisms • Precise specifications of discrete states

6. Validation of the Adaptation • High assurance model of failure • Recognize degraded service • Add internal & external repair mechanisms • Assume precise specifications of states, as before

7. Validation of the Adaptation • Not failure, degree of satisfaction • Precise specs are not realistic • Not for whole system • Even less so for internal states • How can we do without them? • Know gradient of quality • Acquire expectation incrementally • Adaptation strategy • Know gradient of quality • Always run processes that improve quality • Recognize “degraded” border between OK and broken

8. A Design Space for Adaptation The design space in which a designer seeks to solve a problem is the set of decisions to be made about the designed artifact together with the alternative choices for these decisions. A representation of a design space is one of the static textual or graphical forms in which a particular design space – or a subset of that space – may be rendered. Activation | ## reader pull | ## sender push Privacy | ## private | ## public Authorship | ## solo | ## shared

9. A Design Space for Adaptation • Can we identify the design decisions we make (implicitly or explicitly) when creating the actual adaptation code? • What decisions must be made, what are the choices for each? • These decisions often create a feedback loop • How can we be sure the feedback loop is complete? • What other alternatives are there for adaptation? • Homeostasis, equilibrium, …?

10. A Design Space for Adaptation • Space for adaptive techniques(strawman for discussion) • How is target (desired) system state represented? • [fixed, formula, bounds, objective fcn, implicit in code, etc] • What information is used to determine current state? • [external data, internal data, both, implicit, etc] • How does system determine state from that info? • [direct measurement, inference from proxy, etc] • How does system cause adaptation to happen? • [modify data, call procedure, start new process, etc] • How does system decide what change to make? • [constant, proportional, PID, ad hoc, utility function, etc]

11. The Spectrum of Adaptive Systems When are architecture-based approaches more suitable for a particular domain/application? When are control-based approaches more suitable for a particular domain/application? How can we assess different highly adaptive control approaches?

12. Control Science or Run-Time Checking • Validate results produced by managed system • Monitor context: your own state and the environment • Analyze and generate hypotheses • Adapt system accordingly • Validate hypotheses • Validate adapted managed system • Validate adapted controller

13. Control Science or Run-Time Checking Dahm: US Air Force Chief Scientist Report: A Vision for Air Force Science & Technology During 2010-2030. Vol. 1, AF/ST-TR-10-01 (2010) What are the critical properties of highly adaptive systems that can be checked effectively at run-time using V&V and control theory tools? What design-time V&V techniques can be applied at run-time? What information needs to be monitored to perform run-time V&V?

14. Balancing design- and run-time effort • Design-, deployment- and run-time • activities performed during design-time could be performed during deployment- and run-time deployment-time deployment-time service-time deployment-time time development-time run-time

15. Balancing design- and run-time effort • Two extremes • not much can be changed, there is a limit what a system can perform during deployment- and run-time • design-time activities have to be reconsidered since more activities can be performed during deployment- and run-time • How to exchange and exploit design rational between the different design- and run-time? • What assurances can be obtained?

16. Top-down vs Bottom-up • Self-adaptive and self-organising systems • how they complement each other? • what are the common methods and techniques • How to engineer self-organisation to deal with complexity? • self-organization as a means to build layered systems • What type of assurances can be obtained from self-organised systems? • how architectures can affect assurances in self-organising systems?

17. Implement Adaptation Internal Approach External Approach [Salehie&Tahvildari2009]

18. Implement Adaptation Option to Implement Adaptation Reuse Option: • Software Platform of the Product-Line Source for Variability: • Feature Model FeatureModel Software Platform Software Product Production

19. Reuse Options: No Reuse Component Reuse Frameworks Product-Lines ... Implement Adaptation(1) Base Elements/Systems (Function) Source for Variability: • Planned Variations • Configuration • Selection/Configuration • Feature Model • …

20. Implement Adaptation(2) Realize Variations (Function) Offline Techniques: • Code level: Program Variations • Model-Driven: Generate Variations Online Techniques: • Code level: e.g., Reflection, Parameter Adjustment, Architectural Reconfiguration Operations • Model-Driven: e.g., realize Variations using runtime models

21. Implement Adaptation(2) (Adaptation Engine) Online Techniques: • Code level: • Rule-based adjustment • Generate & evaluate • … • Model-Driven: e.g., determine suitable Variations on the fly using runtime models • Rule-based adjustment • Generate & evaluate • …

22. Supervisory Logic Controller design & Reference value selection System identification Reasons for Adaptation Revenue = r * (number of Completed transactions) Cost = c * (number of responses longer than the response time constraint W) Profit model Profit = Revenue - Cost Economics & Feasibility Addressed Problem Users Location of the Problem [Hellerstein+2003] [Hellerstein+2004] Reference value MaxUsers Feedback Controller Completed Transactions Response Time Server Log Administrator Server

23. External Uncontrollable Context: Social context Legal requirement changes Requirement changes Physical context Environment (only via context) World (also only via context) Internal Controllable Context Platform: Hardware platform changes Software platform changes Application software Software state Layers! Reasons for Adaptation(1) Location of the Problem Environment Context Software system Application software Platform SW-Platform HW-Platform World

24. Economics: to minimize operation efforts (required resources) to minimize administration efforts and the need for human oversight to minimize maintenance efforts (software aging resp. laws of software evolution) Feasibility: To enable systems where human oversight alone could not cover the required adaptation Reasons for Adaptation(2) Economics & Feasibility

25. Problem: A suitable balance of alternative solutions can only be achieved when the context of today‘s software and/or the software is taken into account Uncertainty in the context and/or the software has to be mastered by the software itself Dynamism in the context of today‘s software and/or the software requires that the software adapts itself The unforeseeable evolution of the context of the software and/or the software requires that the software that adapt itself … Reasons for Adaptation(3) Addressed Problem

26. Some General Themes –Adapting… • Validation of the adaptation • Design space for adaptation • The spectrum of adaptive systems • Control science or run-time checking • Balancing design- and run-time effort • Top-down vs bottom-up • Implementing adaptation • Reasons for adaptation

27. Some General Themes – Final • 1+4+8+3(problem) • 2+3(solution) • 5+process+7 • 6 (incl. self-organising)