Self Adaptive Software An Architecture-Based Approach to Self-Adaptive Software - Peyman Oreizy, Michael M. Gorlick, Richard N. Taylor, Dennis Heimbigner, Gregory Johnson, Nenad Medvidovic, Alex Quilici,David S. Rosenblum, and Alexander L. Wolf Presenter : Viral Mehta (vmehta@usc.edu)
Self Adaptive Software “Software that modifies its behavior in response to changes in its operating environment – end user input ,external hardware device and sensors” Eg: Fleet of unmanned air vehicles.
Adaptation and Embedded systems Continuously running Applications Changes in Environment paint of a room. network traffic. Can Serve multiple purpose by changing behavior
Issues for adaptation What Conditions? Open or Closed adaptation Type of autonomy Frequency Cost Effectiveness Information Type and Accuracy
Spectrum of self - adaptability
Software Adaptation in the Large Developing a compressive adaptation methodology that spans adaptation in the small to adaptation in the large, and then develop the technology that support the entire range of adaptations.
Software Adaptation in the Large Life Cycle Change app. s/w.
Evolution Management (lower wheel) Process by which changes are applied, controlled and verified. Entities / Phases: Dynamic software Architectures C2 / Weaves Maintaining consistency and system integrity Architecture evolution manager Enacting changes Editors / Interpreter
Dynamic software Architectures - C2 Components are arranged in a hierarchy Service requested form above components Notifications to components below Flexible Components - do not share a common address space / common thread of control
Dynamic software Architectures - Weaves Object flow centric architecture Object as input – object as output Blind communication
Similarities Weaves / C2 (help adaptation) Distinguishes between components and connectors Neither places restriction on granularity of components Asynchronous communication
Maintaining consistency and System integrity Ongoing adaptations continuously threatens system safety, reliability and correctness Strict correspondence between the architectural model and the executing implementation required. Architecture evolution manager (AEM) changes – single / Transaction Maintains consistency between the architectural model and implementation as changes are applied Prevents changes from violating architectural constraints. eg. Each component has to be connected to a connector
Enacting Changes Architecture editor Design Editor Used to construct architecture and describe modification. Eg. Visio Design Editor critiques as arch is built – prevent semantic errors / ensure min amount of safety Modification interpreter to interpret change scripts
Adaptation Management (upper wheel) Describes the life cycle of adaptive software systems Monitors and evaluates the application and its operating environment Plans adaptation Deploys change description to running application
Collecting observations Embedded assertions (inline observers) resource shortage ,violation of low level constrained Expectation agent responds to the occurrence of event pattern Surrounding events Availability of network connection Human observers
Evaluation and monitoring Inconsistencies can occur when some architectural element behaves in a manner inconsistent with the required behavior or when an elements assumption about its environment becomes invalid Static analysis Attributed graph grammar Dynamic analysis runtime checks using observers
Planning changes Adaptation Planning Observation planning Determines which observations are necessary for deciding when and where adaptations are required. Takes in to account environmental assumptions, expected behaviors, availability of observers, and their costs Adaptation Planning Determines which adaptations to make and when For faster reaction : Predefined solution framework
Deploying change description Change agents Propagate among various sites to make required changes carry with them the new components / connectors coordinated changes at multiple sites
Thank you…. Questions ? Comments?