Viable Self-Managing Software Systems

1. School of Computing & Mathematical Sciences Viable Self-Managing Software Systems Andy Laws

2. Presentation Overview • Review the context and motivations for this work. • Summarize some related work in this area. • Outline the cybernetic foundations of our approach. • See where this has taken us so far. • Speculate on where these findings may take us in the future.

3. The Context

4. Software Engineering Considerations • The aim of Software Engineering has been described as: “...the systematic, principled, design and deployment of applications that fulfil software’s original promise - applications that retain their full malleability throughout their lifetime and that are as easy to modify in the field as they are on the drawing board.” (Laddaga,1997) • In the thirty years since its establishment as a discipline many techniques have been introduced in pursuit of this goal, e.g. • structured programming - high-level languages- OO - process maturity etc. (Lehman, ) All require the software designer to predict every software circumstance and code to be provided to deal with the situation. • While significant improvements and highly successful systems have undoubtedly resulted, these efforts have failed to deliver on-going malleability and most software systems exhibit a growing fragility caused by continual adaptation to meet changing requirements. • There is growing evidence to suggest that it is time to reconsider the engineering and maintenance of software systems in a manner similar to physical products and that a more organic view of software should be adopted.

5. Software Evolution Considerations • Such a view is becoming especially prevalent in the Software Evolution community • For example, Manny Lehman, in his development of the “laws of software evolution” has long advocated that: • “…software must evolve, undergoing continuous adaptation and change. It must be treated as an ever to be adapted organism, not as a to be produced once artifact.” • Similarly, Brereton et al in a recent research agenda for Software Engineering state: • “…it may be possible to evolve software by learning from biological models, through which the evolution of incredibly complex structures has been achieved.”

6. Coupled with this.. • Over the last two decades, the development of raw computing power coupled with the proliferation of computing devices has grown exponentially. • The production of evermore complex, ambitious and connected systems – distributed systems underpinned by internet developments • Such complexity strains the ability to adapt and maintain such systems manually in a timely manner – yet they are required to be consistently available, highly-resilient, highly dependable etc. • Consequently, much recent attention has focused on devolving some of the responsibility for adaptive and evolutionary activities to the software itself.

7. Some Related Work

8. Self-Adaptive Software • Defined by Laddaga in the 1997 DARPA Broad Agency Announcement as: • “...software that evaluates its own performance and changes behaviour when the evaluation indicates that it is not accomplishing what the software is intended to do...”. • To adapt, the system reacts to environmental change - the problem is recognizing the need for change, then planning, enacting and verifying the change - these are management issues - self-managing systems

9. Self-Adaptive Software • Progress to date has been informed by three guiding metaphors • control systems theory • dynamic planning systems • self-aware or reflective systems. • “Managing complexity is a key goal of self-adaptive software. If a program must match the complexity of the environment in its own structure it will be very complex indeed! Somehow we need to be able to write software that is less complex than the environment in which it is operating yet operate robustly.” (Robertson, Laddaga et al, 2000)

10. IBM’s Autonomic Computing Approach • Inspired by the “autonomic” function of the human central nervous system. Such autonomic control regulates temperature, breathing, heart-rate etc. at a sub-conscious level. • Ideally, autonomic software systems will take care of the mundane elements of systems management themselves

11. Eight Characteristics of Autonomic Systems • Self-knowledge - Detailed knowledge of constituent components, current status etc. • Self-configuration/re-configuration - Adjustments to a changing environment • Self-optimizing - Monitor constituent parts and optimize accordingly • Self-healing - The ability to recover from malfunction • Self-protecting - Detect, identify and protect itself from attack • Environmentally aware – know its environment, the context surrounding its activity and act accordingly • Co-operative – Interact with other systems in a heterogeneous world – open standards • Anticipatory – anticipate and transparently implement the resources required to meet user goals How these should be effectively structured is still open to question.

12. A Cybernetic Approach

13. The Viable System Model • Beer’s VSM implements a control & communication structure via hierarchies of homeostats (feedback loops) • 6 major systems ensure ‘viability’ of the system • Implementation S1 • Monitoring S2 • Audit S3* • Control S3 • Intelligence S4 • Policy S5 • Offers an extensible, recursive, model-based architecture, devolving autonomy to sub-systems Autonomic Systems Anticipatory Self-awareness Deliberative

14. Recursion in the Model • Each System One is expected to develop as a VSM in its own right • Consequently, the model is re-produced in its entirety at each level • So this model contains further VSM’s and is itself contained in a higher level VSM

15. Where this begins to get really interesting • The recursive nature of the underlying model suggests that each System One should develop as a Viable System Model in its own right. • If the recursion is pursued below the level of the human software team then we arrive at the level of the software system. • This strongly implies that the software system should assume the same overall management structure as the human software process • Consequently, we appear to have a theoretically supported management architecture for “self-managing autonomic software”

16. Bratman et al’s IRMA Architecture • Bratman et al’s Intelligent Resource-Bounded Machine Architecture (IRMA), a classic BDI agent model • It is noticeable that many of the elements contained in the model correlate directly to elements of the VSM • So • Planning & Means-Ends Reasoning S3 • Opportunity Analyser & Filtering S4 • Beliefs about the world S5 • Desires and Deliberative Process S5 • Intentions - S5 Policy passed to S3 for enactment • It is also apparent that some elements are missing for Viability

17. J-Reference Model

18. A Viable Intelligent Agent Architecture • Using Bratman et al’s IRMA approach and using the VSM as a reference model, we designed a Viable Intelligent Agent Architecture realizable using a multi-agent approach. • The design specifies, in some detail, the higher, deliberative processes of adaptation. • In some respects, the ready-mapping of existing IRMA components and the inclusion of viability components demonstrates the applicability of the VSM-based approach.

19. Some Practical Examples • CLOUDS Project – offers support in the treatment of cancer • Jbel Scripting Language • ITVS Project – In-Vehicle Telematics System

20. Clouds Project • Healthcare Informatics • Decision support systems for oncologist • Combining evidence and Guidelines • Adopting advanced software and knowledge engineering methods • Main research concerns • High-assurance of decision processes and supports • Cross-cutting concerns

21. Our Focus • Research question • Defining mechanisms and scenarios for • enriching expert practice with • medical evidence and guidelines. • tolerating variability and change via • process and systems self-governance. • enabling variety through • separation of concerns and systems self-generation.

22. Our Focus • Distributed Software Engineering Centric • Computational Logic • Stochastic Situation Calculus • Formal Specification, informal, etc. • Dynamic analysis and governance • Self-generative programming for • Systems generation, Deployment and Management • Separation of Concerns • Pluggable Decision Models • Autonomic Middleware for • Intelligence and command and control • Self-management

23. Clouds Prototype V.1

24. Clouds Prototype V.1

25. Clouds Prototype V.1

26. Clouds Prototype V.1

27. Clouds Prototype V.1

28. Clouds Prototype V.1

29. Clouds Prototype V.1

30. Clouds Prototype V.1

31. Clouds Prototype V.1

32. JBel Scripting Language

33. Decision Tree for Radiotherapy (NICE) Surgery Wide local excision and axillary surgery Mastectomy and axillary surgery Breast Radiotherapy Considered young? Discuss Breast Radiotherapy Young Not young Low or intermediate High Consider breast boost radiotherapy Risk Group Consider chest wall radiotherapy Axillary (armpit) radiotherapy may cause serious complications and is only used when no further surgery can be performed or when the cancer has spread to the axillary fat.

34. Rules for Receiving Radiotherapy 4. Chest Wall Radiotherapy Risk = High AND Surgery = Mastectomy 1. Breast Radiotherapy Surgery = Wide local excision 2. Discuss Breast Radiotherapy Surgery = Mastectomy 3. Breast Boost Radiotherapy Age = Young (i.e. < 40 years old) AND Surgery = Wide local excision

35. Decision Tree for the Selection of Adjuvant Systemic Therapies (NICE) Pre/Peri Post MenopausalStatus Low Low Int/High Int/High Risk Group Oestrogen Status - + + - + - + - The numbers 1 to 7 represent the eight different treatment groups identified when the guidelines are represented in this way. 1 2 3 4 5 2 6 7 Group from Tree Recommended single treatment or combination of treatments 1 T1 2 T2 3 (T3 and T4) or T5 4 T4 5 T3 6 T3 or T4 or (T3 andT4) 7 T4 or (T3 andT4) Available Treatments T1 Consider Tamoxifen T2 No treatment T3 Tamoxifen T4 Chemotherapy T5 Ovarian Ablation

36. In-Vehicle Telematics System (IVTS) • IVTS cover a broad range of computer-based systems, these may include or combine: • Engine Management Systems • Driver’s Information Systems • Vehicle Navigation & Tracking Systems • Collision Avoidance Systems • Vehicle Security Systems • Using Jini + Java RMI allows distributed applications to be developed as a series of clients that interact with application services via a look-up service. • The service-oriented abstraction considers a service as a logical concept that can be discovered dynamically by a client and used according to a contract of use

37. Some Implications and Final Comments • The complete realization of a self-managing autonomic software system using the conceptual guidance of classical cybernetics and the VSM still has some way to go. Indeed, it isn’t yet clear that full realization is possible and there are still many problems outstanding. • Nevertheless, the approach offers a recursive generalized architecture from human software team to self-managing software systems • However, the inclusion of the anticipatory and deliberative (Systems 4 and 5) systems appear to offer a step forward from purely “autonomic” systems. Of course, this brings its own problems – environmental modelling ? • Nevertheless, using off-the-shelf technology that does not necessarily reflect this viewpoint exactly has allowed us to make significant progress and indicates that this approach may supply a ready-made theoretical underpinning for such software systems.

38. Thanks & Any Questions?