Towards RequirementsDriven Autonomic Systems Design Alexei Lapouchnian Sotirios

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

Overview 1. Autonomic Computing 2. Goal-Oriented Requirements Engineering 3. From Requirements to High-Variability Designs 4. Towards Autonomic Computing Systems 5. Conclusion May 1 -2, 2005 DEAS’ 05 May 21, 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, selfprotection, self-healing, self-optimization) May 1 -2, 2005 DEAS’ 05 May 21, 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 May 1 -2, 2005 DEAS’ 05 May 21, 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 To make this possible we need: Ø Concepts to analyze large spaces of alternative behaviours/configurations May 1 -2, 2005 DEAS’ 05 May 21, 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 [HLM 03] May 1 -2, 2005 DEAS’ 05 May 21, 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 DEAS’ 05 May 21, 2005

Meeting scheduler example May 1 -2, 2005 DEAS’ 05 May 21, 2005

Toward High-Variability Designs Ø Variability in problem domain must be reflected in the solution domain as alternative configurations, behaviors, structures, concerns, etc. 1. Configuration variability: feature models in the product-line family software 2. Behavioral variability: transitional systems typically statecharts 3. Structural variability: components compositions patterns in software architectures 4. Concerns variability: aspect-oriented compositions 5. … and so on so forth … May 1 -2, 2005 DEAS’ 05 May 21, 2005

Converting Goal Models Into Feature Models May 1 -2, 2005 DEAS’ 05 May 21, 2005

Converting Goal Models Into Statecharts May 1 -2, 2005 DEAS’ 05 May 21, 2005

Converting Into ADL May 1 -2, 2005 DEAS’ 05 May 21, 2005

Light-weight Enrichments • Goal models in the AND/OR graph form need to be enriched with design-specific information to transform into a highvariability 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 DEAS’ 05 May 21, 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” [KC 03] Ø 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 DEAS’ 05 May 21, 2005

How Goal Models Can Help 1. 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 May 1 -2, 2005 DEAS’ 05 May 21, 2005

How Goal Models Can Help 2. Goal models can be used to support traceability b/w AC system design and requirements 1. Easy to see how some particular goal is decomposed and assigned to components/AEs 2. Easy to determine how a failure of an AE affects the overall goal of the system May 1 -2, 2005 DEAS’ 05 May 21, 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 1. Helps in achieving globally optimal behaviour May 1 -2, 2005 DEAS’ 05 May 21, 2005

A Hierarchical Autonomic Architecture (HAA) A hierarchy of AEs that is structurally to the goal hierarchy of the corresponding goal model 1. Each goal in the goal model is the responsibility of one AE 2. Managed elements of the leaf-level AEs are the actual components/resources 3. Higher-level AEs orchestrate lower-level AEs 4. The root AE represents the whole system 5. Communication channels b/w parent/child AEs for control/monitoring information exchange May 1 -2, 2005 DEAS’ 05 May 21, 2005

The Knowledge of AE (1) 1. The goal that its achieving 2. How this goal is achieved – the decomposition of the goal 3. Information on monitored/controlled parameters of its sub-AEs 4. Success/failure metrics 5. Various strategies 6. etc. 7. The core of the knowledge is the properly enriched goal model May 1 -2, 2005 DEAS’ 05 May 21, 2005

The Knowledge of AE (2) May 1 -2, 2005 DEAS’ 05 May 21, 2005

Benefits of HAA 1. Partitioning of high-variability design space into lower-variability subspaces 2. Easy composeability of AEs and AC systems 3. Straightforward propagation of high-level concerns from the room AE down to leaf-level elements 4. Straightforward propagation of diagnostic information from low-level AEs to high-level elements 5. In case of an AE failure: easy identification of affected AEs and goals May 1 -2, 2005 DEAS’ 05 May 21, 2005

Example: Propagating High-level Concerns Down 1. The root AE receives a high-level policy 2. It acts on the policy by determining which available alternative fits the policy best 3. Produce new policies for its children AEs 4. Pass these policies down to them 5. … 6. 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 DEAS’ 05 May 21, 2005

Example: Handling AE failures 1. An AE “A” detects that its goal is not being achieved by the selected system configuration 2. 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) 3. 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 DEAS’ 05 May 21, 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 [SJM 04] and buttom-up [GMN 02] goal reasoning approaches can be used to support these activities. May 1 -2, 2005 DEAS’ 05 May 21, 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 DEAS’ 05 May 21, 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 reengineering”. Journal of Systems and Software 66(3): 225 -239 (2003) • quality-based software reuse – J. C. Leite, et al. “Quality-based software reuse”, CAi. SE’ 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”. May 1 -2, To 2005 appear, RE’ 05. DEAS’ 05 May 21, 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, 2 nd 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 DEAS’ 05 May 21, 2005

3. 1 b For configuring variability May 1 -2, 2005 DEAS’ 05 May 21, 2005

3. 2 b For behavioral variability May 1 -2, 2005 DEAS’ 05 May 21, 2005

3. 3 b For structural variability May 1 -2, 2005 DEAS’ 05 May 21, 2005

3. 1 c From goal to feature May 1 -2, 2005 DEAS’ 05 May 21, 2005

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

3. 3 c From goal to interfaces May 1 -2, 2005 DEAS’ 05 May 21, 2005