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

Overview Autonomic Computing Goal-Oriented Requirements Engineering From Requirements to High-Variability Designs Towards Autonomic Computing Systems Conclusion May 1-2, 2005

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) May 1-2, 2005

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 In fact, most likely a combination of these 3 approaches is needed! May 1-2, 2005

To make this possible we need: 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 May 1-2, 2005

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] May 1-2, 2005

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 May 1-2, 2005

Meeting scheduler example This model shows 6 ways to fulfill the goal Schedule Meeting Analyzing the space of alternatives makes the process of generating functional and quality requirements more systematic in the sense that the designer is exploring an explicitly represented space of alternatives. It also makes it more rational in that the designer can point to an explicit evaluation of these alternatives in terms of stakeholder criteria to justify his choice. May 1-2, 2005

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 … May 1-2, 2005

Converting Goal Models Into Feature Models May 1-2, 2005

Converting Goal Models Into Statecharts May 1-2, 2005

Converting Into ADL May 1-2, 2005

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 May 1-2, 2005

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 May 1-2, 2005

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 If not, and to find possible new better alternatives – need MAS-like behaviour May 1-2, 2005

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 If not, and to find possible new better alternatives – need MAS-like behaviour May 1-2, 2005

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 If not, and to find possible new better alternatives – need MAS-like behaviour May 1-2, 2005

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 May 1-2, 2005

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 May 1-2, 2005

The Knowledge of AE (2) May 1-2, 2005 A fragment of a properly enriched goal model will serve as the core of each AE’s knowledge. For example, Figure 5 presents an AE, whose objective is to achieve the goal G. It has a fragment of the goal model showing the decomposition of this goal. Here, the goal G is AND-decomposed into G1 and G2, which means that the goal model identified only one way to achieve G. The managed elements of the AE in Figure 5 are themselves autonomic elements that achieve the goals G1 and G2. They have different fragments of the goal model assigned to them. For example, the AE achieving the goal G2 knows that to attain that goal it must either achieve G3 or G4. These goals are in turn handled by lower-level AEs (not shown). May 1-2, 2005

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 May 1-2, 2005

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 May 1-2, 2005

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 May 1-2, 2005

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. May 1-2, 2005

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. May 1-2, 2005

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. May 1-2, 2005

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. May 1-2, 2005

3.1b For configuring variability May 1-2, 2005

3.2b For behavioral variability May 1-2, 2005

3.3b For structural variability May 1-2, 2005

3.1c From goal to feature May 1-2, 2005

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

3.3c From goal to interfaces May 1-2, 2005