Towards Requirements-Driven Autonomic Systems Design

1. Towards Requirements-Driven Autonomic Systems Design Alexei Lapouchnian Sotirios Liaskos John Mylopoulos Yijun Yu May 21, 2005

2. Overview • Autonomic Computing • Goal-Oriented Requirements Engineering • From Requirements to High-Variability Designs • Towards Autonomic Computing Systems • Conclusion

3. 1. Autonomic computing IT industry challenges: • Software Systems Complexity • Software maintenance costs dominate Autonomic Computing: • Move most of maintenance complexity into the software • Self-management/adaptation (self-configuration, self-protection, self-healing, self-optimization)

4. Building AC Systems Three ways to make a system autonomic: 1. Design the system to support a space of possible behaviours (our approach) • System has many possible configurations built it • Ability to select the most appropriate configuration 2. Make a system multiagent • Composed of intelligent agents • Social interactions, planning, etc. • Dynamic system composition/configuration 3. Use evolutionary approaches

5. Building AC Systems Three ways to make a system autonomic: 1. Design the system to support a space of possible behaviours (our approach) • System has many possible configurations built it • Ability to select the most appropriate configuration To make this possible we need: • Concepts to analyze large spaces of alternative behaviours/configurations

6. 2. Goal-Oriented RE • Early Requirements • Identify stakeholders • Goals of stakeholders • Identify system goals – functional requirements • Use Goal Models to: • Refine system goals (AND/OR refinements) into tasks • Model Non-Functional (quality) Requirements (NFRs) → Softgoals • Model correlation among goals and softgoals to rank alternatives [HLM03]

7. 3. Capturing Variability • A key aspect in the design of autonomic systems is that the system must adapt its behavior to the changes in its environment • It is beneficial to identify and implement many alternative behaviours • Alternative ways to solve a problem are captured by the OR decompositions in goal models • Alternatives in the goal model capture variability in the problem domain • Variability in problem domain must be reflected in the solution domain as alternative configurations, behaviors and structures

8. Meeting scheduler example

9. Toward High-Variability Designs • Variability in problem domain must be reflected in the solution domain as alternative configurations, behaviors, structures, concerns, etc. • Configuration variability: feature models in the product-line family software • Behavioral variability: transitional systems typically statecharts • Structural variability: components compositions patterns in software architectures • Concerns variability: aspect-oriented compositions • … and so on so forth …

10. Converting Goal Models Into Feature Models

11. Converting Goal Models Into Statecharts

12. Converting Into ADL

13. Light-weight Enrichments • Goal models in the AND/OR graph form need to be enriched with design-specific information to transform into a high-variability design • Such enrichments are light-weight: minimal information to derive the design • Keeping the traceability among the variabilities is crucial to the design of AC systems

14. 4. Towards AC Systems: Autonomic Elements • Autonomic Element (AE) – basic building block of AC systems • Its behaviour and its relationships with other AEs are “driven by goals that its designer embedded in it” [KC03] • AE manages itself to deliver its service in the best possible way • Monitor its managed element(s) • Analyze data and diagnose the problem • Plan course of action • Execute • Overall self-management of the system results from internal self-management of its AEs

15. How Goal Models Can Help • Goal models provide a means to represent many ways in which the objectives of the system can be met and analyze/rank these alternatives with respect to stakeholder quality concerns • This allows for exploration and analysis of alternative system behaviours at design time • Can lead to more predictable and trusted AC systems • If predefined alternatives perform well, there is no need for complex social interactions among AEs

16. How Goal Models Can Help • Goal models can be used to support traceability b/w AC system design and requirements • Easy to see how some particular goal is decomposed and assigned to components/AEs • Easy to determine how a failure of an AE affects the overall goal of the system

17. How Goal Models Can Help 3. Goal models provide a unifying intentional view of the system by relating goals assigned to individual autonomic elements to high-level system objectives and quality concerns • Helps in achieving globally optimal behaviour

18. A Hierarchical Autonomic Architecture (HAA) A hierarchy of AEs that is structurally to the goal hierarchy of the corresponding goal model • Each goal in the goal model is the responsibility of one AE • Managed elements of the leaf-level AEs are the actual components/resources • Higher-level AEs orchestrate lower-level AEs • The root AE represents the whole system • Communication channels b/w parent/child AEs for control/monitoring information exchange

19. The Knowledge of AE (1) • The goal that its achieving • How this goal is achieved – the decomposition of the goal • Information on monitored/controlled parameters of its sub-AEs • Success/failure metrics • Various strategies • etc. • The core of the knowledge is the properly enriched goal model

20. The Knowledge of AE (2)

21. Benefits of HAA • Partitioning of high-variability design space into lower-variability subspaces • Easy composeability of AEs and AC systems • Straightforward propagation of high-level concerns from the room AE down to leaf-level elements • Straightforward propagation of diagnostic information from low-level AEs to high-level elements • In case of an AE failure: easy identification of affected AEs and goals

22. Example: Propagating High-level Concerns Down • The root AE receives a high-level policy • It acts on the policy by determining which available alternative fits the policy best • Produce new policies for its children AEs • Pass these policies down to them • … • Leaf-level AEs tune their managed elements in accordance with the policies received from their parent AEs Note: Each AE retains the freedom to achieve its goal in the way it sees fit provided that it satisfies the policy set by its parent AE

23. Example: Handling AE failures • An AE “A” detects that its goal is not being achieved by the selected system configuration • It determines if it can correct the situation by switching to an alternative behaviour by either: • Modifying the configuration parameters of its managed AE • Switching to alternative AE provided that one exists (e.g., if there is OR decomposition for “A”s goal) • If no corrective action can be performed, the parent AE of “A” is notified Benefits: • Failures are handled as early as possible • Goal model is used to locate the failure and determine if alternative configurations are available

24. Using Goal-Based Reasoning in AC Systems AC systems frequently need to: • Determine if the current alternative satisfies functional and non-functional requirements • Predict if a potential alternative satisfies the requirements • Given changes in user goals/preferences, find the best way to satisfy the new requirements. Top-down [SJM04] and buttom-up [GMN02] goal reasoning approaches can be used to support these activities.

25. 5. Conclusion and Future Work • We presented a requirements-driven approach for designing autonomic systems • Goal models are used to represent and analyze a space of possible behaviours of software systems • Possible to generate design-views preserving the problem domain variability • Proposed a hierarchical autonomic architecture based on requirements goal models Future Work: • Generation of autonomic infrastructure from goal models • Application and validation of our approach in several areas: medical domain, business systems.

26. References (1) • Autonomic Computing systems • J. Kephart and D.M. Chess. “The vision of autonomic computing”. IEEE Computer Journal. 36(1):41-50. 2003. • goal-oriented requirements engineering • A. van Lamsweerde. “From systems goals to software architectures”. FSE. 2004. • L. Chung, B.A. Nixon, E. Yu, J. Mylopoulos. Non-functional requirements in software engineering. Kluwer Academic Press. 1999. • goal-oriented software configuration • B. Hui et al. “Requirements analysis for customizable software: goals-skills-preferences farmework”, RE’03. • S.Liaskos et al. “Configuring common personal software: a requirements-driven approach”. To appear, RE’05. • goal-oriented software tuning • Y.Yu et al. “Software refactoring guided by multiple soft-goals”, REFACE@WCRE’03. • quality-driven software reengineering • Ladan Tahvildari, Kostas Kontogiannis, John Mylopoulos: “Quality-driven software re-engineering”. Journal of Systems and Software 66(3): 225-239 (2003) • quality-based software reuse • J.C.Leite, et al. “Quality-based software reuse”, CAiSE’05. • reverse engineering goal models • Y.Yu, et al. “From goals to aspects: discovering aspects from requirements goal models”. RE’04. • Y.Yu et al. “Reverse engineering goals from source code”, to appear, RE’05. • S.Liaskos et al. “Configuring common personal software: a requirements-driven approach”. To appear, RE’05.

27. References (2) On High-variability software design • Feature model and product-line family: • K.C. Kang et al. “Feature-oriented domain analysis (FODA) feasibility study”, SEI. 1990. • K. Czarnecki et al. Generative Programming: Methods, Tools, and Applications. Addison-Wesley, 2000. • D. Batory et al. “Scaling Stepwise Refinements”. ICSE 2003. • Statecharts • D. Harel. “The STATEMATE Semantics of Statecharts”. TOSEM 5(4):293—333. • Software architectures and ADL • L. Bass et al. Software Architecture in Practice, 2nd Ed. Addison-Wesley, 1998. • Aspect-oriented programming • G. Kiczales. “Aspect-oriented programming”. EOOP. 1997. • C. Zhang et al. “Just-in-time middleware configuration using aspects”. AOSD’05.

28. 3.1b For configuring variability

29. 3.2b For behavioral variability

30. 3.3b For structural variability

31. 3.1c From goal to feature

32. 3.2c From goal to state 3. Transforming hierarchies 1. Defining states 2. Treating dependencies 4. Simplifying leaf statecharts

33. 3.3c From goal to interfaces