1. An Architecture-Based Approach to Self-Adaptive Software Presenters Douglas Yu-cheng Su Ajit G. Sonawane

2. What is Self-adaptive software? “A software that modifies its own behavior in response to the changes in its operating environment such as end-user input, external hardware devices and sensors”

3. Why Adaptive Software? Software’s original promise: ‘application that retain full plasticity throughout their lifecycle and that are as easy to modify in the field as they are on the drawing board’ High-level programming languages, Object Oriented analysis and design etc falls short of keeping the promise. Self-adaptive software – provides to keep the promise!

4. What issues to keep in mind? Condition Open-adaptive or Close-adaptive Cost-Effectiveness Frequency Information type and accuracy

5. Software Adaptation In-The-Large I Goals Develop a comprehensive adaptation methodology that supports the entire range of adaptation process or life-cycle.

6. Software Adaptation In-The-Large II Adaptation Life-Cycle

7. Software Adaptation In-The-Large III Important Features of Adaptation Life-Cycle: Change Management (Adaptation Management) - Identify and Specify Changes - Plan Changes - Correctness and Coordination of Changes (Software Agents, Explicit Representation of Environment to deploy) Change Mechanism (Evolution Management) - Approaches (Architectural Based) - Maintain Consistency and Enact Change Plan An Ontology for self-adaptive software

8. Evolution Management Dynamic Software Architecture - Components, Connectors, and Topology - Reliable Manner with Architectural Formalisms Maintaining Consistency & System Integrity - Facilities for guiding and checking modifications - Manager to coordinate changes Enact Changes - Architecture editor

9. Dynamic Software Architecture I - Weaves & C2 C2 Hierarchy of concurrent components Service request Broadcast notification Flexible component (no inter-dependent component thread)

10. Dynamic Software Architecture II - Weaves & C2 Weaves Object as input and output Laws of blind communication Flexible connectors

11. Dynamic Software Architecture III - Weaves & C2 Similarities between Weaves & C2: Distinguish between components and connectors No restrictions on the granularity of the components or implementation language Asynchronous messages for inter-component communication Component encapsulates functionalities and controls

12. Maintaining Consistency & System Integrity Need to integrate facilities for guiding and checking modifications Need to provide maintenance for strict correspondence between architectural model and implementation Solution: Architecture Evolution Manager (AEM) Maintain “change transaction” (single, basic, and atomic operation) Maintain consistency between architectural model and executing implementation Reify changes in architectural model Prevent changes from violating architectural constraints.

13. Enacting Changes Architecture Editor (To construct architectures and describe modifications) Design Wizard (To prevent semantic errors) Modification Interpreter (To interpret change scripts written by AEM)

14. Adaptation Management Functions Collect Changes Monitors and Evaluates the application and its operational environment Plans Adaptations Deploys change descriptions to running application

15. Adaptation Management cont Requirement for Self-Adaptive Software Observers Evaluates the behavior of the self-adaptive application and monitors its operating environment. Planners Utilizes the observations to plan adaptive responses. Deployers Enact the responses within the application Requires infrastructure support in the form of “registry” (e.g. Software Dock)

16. Collecting Observation Embedded Assertions (inline observers) Use of ‘Expectation Agent’ Monitor events that occur outside of Application e.g. availability of network connection, dynamic architectural change Human Observers in cooperation with automated changes

17. Evaluation and Monitoring Use of Attributed graph grammers

18. Planning Changes Two distinct forms of planning Observation Planning Which observations are necessary for deciding when and where adaptations are required Classic Planning Problem Adaptation Planning Exactly which adaptations to make and when

19. Deploying Change Descriptors Use of Mobile Agents

20. Strength Fine-grain architectural-based approach to supports the entire range of adaptive software OthersCRMERPWorkflow Automation Methodology

21. Weakness Fine-grain architectural-based approach to supports the entire range of adaptive software. Too Fine-grain??? Domain specific ontology/framework for adaptive software?

22. Weakness cont. Example: Workflow Automation

23. Thank You. Question or Comments?