An Architecture-Based Approach to Self-Adaptive SoftwareWhat is Self-adaptive software?Why Adaptive Software?What issues to keep in mind?Software Adaptation In-The-Large ISoftware Adaptation In-The-Large IISoftware Adaptation In-The-Large IIIEvolution ManagementDynamic Software Architecture I - Weaves & C2Dynamic Software Architecture II - Weaves & C2Dynamic Software Architecture III - Weaves & C2Maintaining Consistency & System IntegrityEnacting ChangesAdaptation ManagementAdaptation Management cont Requirement for Self-Adaptive SoftwareCollecting ObservationEvaluation and MonitoringPlanning ChangesDeploying Change DescriptorsStrengthWeaknessWeakness cont.Slide 23An Architecture-Based Approach to Self-Adaptive Software PresentersDouglas Yu-cheng SuAjit G. SonawaneWhat 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”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!What issues to keep in mind?ConditionOpen-adaptive or Close-adaptiveCost-EffectivenessFrequencyInformation type and accuracySoftware Adaptation In-The-Large IGoalsDevelop a comprehensive adaptation methodology that supports the entire range of adaptation process or life-cycle.Software Adaptation In-The-Large IIAdaptation Life-CycleSoftware Adaptation In-The-Large IIIImportant 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 softwareEvolution ManagementDynamic Software Architecture- Components, Connectors, and Topology- Reliable Manner with Architectural FormalismsMaintaining Consistency & System Integrity - Facilities for guiding and checking modifications- Manager to coordinate changesEnact Changes- Architecture editorDynamic Software Architecture I- Weaves & C2C2Hierarchy of concurrent componentsService requestBroadcast notificationFlexible component (no inter-dependent component thread)Dynamic Software Architecture II- Weaves & C2WeavesObject as input and outputLaws of blind communicationFlexible connectorsDynamic Software Architecture III- Weaves & C2Similarities between Weaves & C2:Distinguish between components and connectorsNo restrictions on the granularity of the components or implementation languageAsynchronous messages for inter-component communicationComponent encapsulates functionalities and controlsMaintaining Consistency & System IntegrityNeed to integrate facilities for guiding and checking modificationsNeed to provide maintenance for strict correspondence between architectural model and implementationSolution: Architecture Evolution Manager (AEM)Maintain “change transaction” (single, basic, and atomic operation)Maintain consistency between architectural model and executing implementationReify changes in architectural modelPrevent changes from violating architectural constraints.Enacting ChangesArchitecture Editor(To construct architectures and describe modifications)Design Wizard (To prevent semantic errors)Modification Interpreter(To interpret change scripts written by AEM)Adaptation ManagementFunctions Collect Changes Monitors and Evaluates the application and its operational environment Plans Adaptations Deploys change descriptions to running applicationAdaptation Management contRequirement for Self-Adaptive SoftwareObservers 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 applicationRequires infrastructure support in the form of “registry” (e.g. Software Dock)Collecting ObservationEmbedded Assertions (inline observers)Use of ‘Expectation Agent’Monitor events that occur outside of Application e.g. availability of network connection, dynamic architectural changeHuman Observers in cooperation with automated changesEvaluation and MonitoringUse of Attributed graph grammersPlanning ChangesTwo distinct forms of planningObservation Planning Which observations are necessary for deciding when and where adaptations are required Classic Planning ProblemAdaptation Planning Exactly which adaptations to make and whenDeploying Change DescriptorsUse of Mobile AgentsStrengthFine-grain architectural-based approach to supports the entire range of adaptive softwareOthersCRM ERP Workflow AutomationMethodologyWeaknessFine-grain architectural-based approach to supports the entire range of adaptive software. Too Fine-grain???Domain specific ontology/framework for adaptive software?Weakness cont.Example: Workflow AutomationProcessContextcreateProcess()removeProcess()getProcess()startProcess()stopProcess()IProcessProcessaddProcessStep()removeProcessStep()getProcessStep()IProcessStepProcessStepaddProperty()removeProperty()getProperty()PropertygetValue()registerEvent()Thank You.Question or
View Full Document