• ThesisLog
• Outline

Current Thesis Topical Outline

Updated February 28, 2008

• 1 Coping with Change
  • 1.1 Self-Adaptation Loop of Control
    • 1.1.1 External, Feedback Control
    • 1.1.2 IBM Autonomic Architecture
  • 1.2 Architecture-Based Self-Adaptation
  • 1.3 Opportunities for Improving the State-of-Art
    • 1.3.1 Insufficient Self-Adaptation Capabilities
    • 1.3.2 Lack of Support for Quality-of-Service Trade-Off
    • 1.3.3 High Cost of Development and Maintenance
  • 1.4 This Thesis
    • 1.4.1 Thesis Evaluation Plan
    • 1.4.2 Thesis Contributions
    • 1.4.3 Document Roadmap
• 2 Self-Adaptive Systems
  • 2.1 Software Engineering
    • 2.1.1 Software Architecture Styles and Description Languages
    • 2.1.2 Quality Attributes and Tactics
    • 2.1.3 Software Analytical Models
    • 2.1.4 Continuous Software Evolution
  • 2.2 “External” Contributing Disciplines
    • 2.2.1 Control Systems
    • 2.2.2 Control Paradigm
    • 2.2.3 Decision and Utility Theory
    • 2.2.4 System and Network Management
    • 2.2.5 AI Systems
  • 2.3 Related Self-Adaptation Solutions
    • 2.3.1 Adaptive Technologies
    • 2.3.2 IBM Autonomic Computing and Industry Initiatives
    • 2.3.3 Architecture-Based Adaptation
  • 2.4 Limitations to State-of-Art Addressed
• 3 Rainbow: Self-Adaptation Approach
  • 3.1 Overview of Approach
    • 3.1.1 Software Architecture Model and Style
    • 3.1.2 Control System and the Self-Adaptation Cycle
    • 3.1.3 Utility Theory
  • 3.2 Znn.com Example
  • 3.3 Tailorable Rainbow Framework
    • 3.3.1 Rainbow Models
    • 3.3.2 Translation Infrastructure — Monitoring and Action
    • 3.3.3 Model Manager
    • 3.3.4 Architecture Evaluator
    • 3.3.5 Adaptation Manager
    • 3.3.6 Strategy Executor
  • 3.4 Rainbow Application to Znn.com
  • 3.5 Adaptation Engineering Process
  • 3.6 Summary
• 4 Stitch: Language for Self-Adaptation
  • 4.1 Rainbow Context for the Language
  • 4.2 Requirements for the Self-Adaptation Language
  • 4.3 Self-Adaptation Concepts of Stitch
    • 4.3.1 Adaptation Objectives and Conditions
    • 4.3.2 Operator
    • 4.3.3 Tactic
    • 4.3.4 Strategy
    • 4.3.5 Trade-Off Analysis
    • 4.3.6 Failure-Handling
  • 4.4 Semantics of Stitch Constructs
    • 4.4.1 Model of Adaptation
    • 4.4.2 Utility-Based Trade-Off for Strategy Selection
    • 4.4.3 Adaptation Execution
  • 4.5 Stitch Illustration Using Znn.com
  • 4.6 Summary
• 5 Cost-Effective Self-Adaptation Framework
  • 5.1 Design Principles
  • 5.2 Architecture and Design of Rainbow
    • 5.2.1 Model Manager and Rainbow Models
    • 5.2.2 Translation Infrastructure — Monitoring and Action
    • 5.2.3 Architecture Evaluator
    • 5.2.4 Adaptation Manager
    • 5.2.5 Strategy Executor
    • 5.2.6 Rainbow Deployment Architecture
  • 5.3 Rainbow Adaptation Integrated Development Environment
    • 5.3.1 Stitch Interpreter
    • 5.3.2 Stitch Script Editor
    • 5.3.3 Rainbow Control Console
  • 5.4 Framework Effort and Reuse
  • 5.5 Summary
• 6 Examples and Supporting Evidence
  • 6.1 Basic Client-Server System
  • 6.2 Libra Videoconferencing System
  • 6.3 University Grade System — Security Dimension

  • 6.4 TalkShoe

    • 6.4.1 Background

    • 6.4.2 TalkShoe Infrastructure

    • 6.4.3 Problem Scenarios for Adaptation
    • 6.4.4 Data and Result

    • 6.4.5 Conversations with the TalkShoe Architect

    • 6.4.6 TalkShoe Summary

  • 6.5 Znn.com News Server
    • 6.5.1 Motivation: Slashdot Effect
    • 6.5.2 Rainbow Customization for Znn.com
    • 6.5.3 Experimental Setup
    • 6.5.4 Slashdot Effect Traffic Profile
    • 6.5.5 Data and Result
    • 6.5.6 Znn.com Summary
  • 6.6 Interview with System Administrators
    • 6.6.1 Methodology
    • 6.6.2 Interview Results
    • 6.6.3 Adaptation Analysis from Almossawi’s Administrative Experiences
    • 6.6.4 Interview Summary
  • 6.7 Real-World Adaptive Scripts in Stitch
  • 6.8 Summary
• 7 General, Cost-Effective, and Composable?
  • 7.1 Hypothesis: Generality
    • 7.1.1 Znn.com Provides In-Depth Demonstration of Adaptation Cycle
    • 7.1.2 Seven Points Covering 3 Styles and 4+1 Quality Concerns
    • 7.1.3 University-Grade System On-Paper Demonstration of Security
  • 7.2 Hypothesis: Cost-Effectiveness
    • 7.2.1 Two Data Points of Framework Reuse

    • 7.2.2 TalkShoe Shows that Rainbow is Easy and Flexible to Customize

    • 7.2.3 Task-Based Effort-Estimation Favors Rainbow
  • 7.3 Hypothesis: Adaptability
    • 7.3.1 Znn.com Showcases Language Features

    • 7.3.2 TalkShoe Demonstrates Adaptability

    • 7.3.3 System Administrator Tasks Shows Expressiveness of Stitch
  • 7.4 Summary
• 8 Discussion of Issues and Limitations
  • 8.1 Control, Synchrony, and Representation Issues
    • 8.1.1 Why Centralized Control?
    • 8.1.2 Synchronous Versus Asynchronous Execution
    • 8.1.3 Achieving Histeresis and Stable Control
    • 8.1.4 Why 3 Concepts: Operator, Tactic, and Strategy?
    • 8.1.5 Uncertainty and Handling of Failures
  • 8.2 Framework Design Choices and Limitations
    • 8.2.1 Commonalities of Systems Adaptable by Rainbow
    • 8.2.2 Does an Architecture Model Limit Adaptation?
    • 8.2.3 Change-Triggered, Constraint-Based Problem Detection
    • 8.2.4 Robustness, Dynamicity, and Intelligence of Adaptation Strategies
    • 8.2.5 Strategy Execution Modality Versus Concurrency
    • 8.2.6 Limitations Achieving Trade-Off and Composability
    • 8.2.7 Does Stitch Adequately Codify Adaptive Tasks?
  • 8.3 Rainbow Framework Adoptability
    • 8.3.1 Impact of Reuse on Cost-Effectiveness
    • 8.3.2 Trust and Confidence in Self-Adaptation
    • 8.3.3 Real-world Adoption of Architecture-Based Self-Adaptation
  • 8.4 Summary
• 9 Conclusion
  • 9.1 Thesis Contributions
  • 9.2 Future Work
    • 9.2.1 Enriching the Environment Model
    • 9.2.2 Enhancing Adaptation Control
    • 9.2.3 Preemptive Adaptation
    • 9.2.4 Improved Support for Failure Handling
    • 9.2.5 Engineering for Adaptation
    • 9.2.6 Incorporating User Input and Task-Oriented Computing
  • 9.3 Closing Remarks