Architectural AdaptationAdaptationGoals of this LectureSources and Motivations for ChangeChanges Arising from Product Line ForcesMotivation for Online Dynamic ChangeStewart Brand’s Shearing Layers of ChangeShearing Layers in a BuildingThe Six Shearing LayersThe Six Shearing Layers (cont’d)To Shear or Not to Shear – Pompidou CenterSlide 12Changing Component InteriorsChange of Component InterfaceConnector ChangeChange in the ConfigurationChange Agents and Context (1)Change Agents and Context (2)Time of ChangeArchitecture-Centric AdaptationConceptual Architecture for AdaptationActivities, Agents, and EntitiesStrategy, Tactics, and OperationsCategories of TechniquesArchitectures/Styles that Support AdaptationArchitectures/Styles Supporting AdaptationAPI-Based ExtensionPlug-In Based ExtensionComponent-Object ApproachScripting-Based ExtensionEvent-Based ExtensionThe Special Problems of On-the-fly ChangeCopyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.Architectural AdaptationSoftware ArchitectureLecture 252Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureAdaptationChange is endemic to softwareperceived and actual malleability of software induces stakeholders to initiate changes, e.g.:Users want new featuresDesigner wants to improve performanceApplication environment is changingAdaptation: modification of a software system to satisfy new requirements and changing circumstances3Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureGoals of this LectureCharacterize adaptation, showing what changes, why, and who the players are Characterize the central role software architecture plays in system adaptation Present techniques for effectively supporting adaptation, based on an architecture-centric perspective4Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureSources and Motivations for ChangeCorrective ChangesBug fixesModification to the functional requirements New features are neededExisting ones modifiedPerhaps some must be removedNew or changed non-functional system propertiesAnticipation of future change requests Changed operating environmentObservation and analysis5Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureChanges Arising from Product Line ForcesCreating a new variantChange at branch pointE.g.: Adding an integrated TV/DVD device to a TV product line Creation of a new branch point Merging product (sub)linesRationalizing their architectures6Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureMotivation for Online Dynamic ChangeNon-stop applicationssoftware cannot be stopped because the “application” cannot be stoppedE.g., 24/7 systems Maintaining user or application statestopping the software would cause the user to lose (mental) context saving and/or recreating the software’s application state would be difficult or costlyRe-installation difficultyapplications with complex installation propertiesE.g., software in an automobile7Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureStewart Brand’s Shearing Layers of Change “How Buildings Learn – What happens after they’re built” examines how and why buildings change over timeCategorization of types of change according to the nature and cost of making a change8Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureShearing Layers in a BuildingFigure adapted from “How Buildings Learn”; Stewart Brand, © 1994 Stewart Brand.9Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureThe Six Shearing LayersSite: the geographical setting, the urban location, and the legally defined lotits boundaries and context outlast generations of ephemeral buildings.Structure (“the building”): the foundation and load-bearing elements perilous and expensive to change, so people don’tSkin: exterior surfaces change every ~20 years, to keep up with fashion, technology, or for repair10Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureThe Six Shearing Layers (cont’d)Services: working guts of a building: communications wiring, electrical wiring, plumbing, sprinkler systems, etc.Space Plan: interior layout – where walls, ceilings, floors, and doors goStuf: chairs, desks, phones, pictures, kitchen appliances, lamps, hair brushesthings that switch around daily to monthly11Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureTo Shear or Not to Shear – Pompidou CenterSoftware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.12Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureThe Six Shearing LayersSiteStructureSkinServicesSpace PlanStuff How do these relate to software architecture?13Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureChanging Component Interiors A component’s performance may be improved by a change to the algorithm that it uses internallyCapabilities that facilitate component adaptation Knowledge of self and exposure of this knowledge to external entitiesKnowledge of the component’s role in the larger architecture Pro-active engagement of other elements of a system in order to adapt14Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureChange of Component InterfaceIn many cases adaptation to meet modified functional properties entails changing a component’s interfaceAdaptors/wrappers are a popular technique to mitigate “ripple effect” but, subsequent changes to previously unmodified methods become even more complex15Foundations, Theory, and PracticeSoftware ArchitectureSoftware ArchitectureConnector ChangeTypically changes to connectors are motivated by The desire to alter non-functional propertiessuch as distribution of components, fault-tolerance, efficiency, modifiability, etc.increased independence of sub-architectures in the face of potential failuresimproved performanceThe more powerful the connector the easier architectural change E.g., connectors supporting event-based communicationWhat is the downside?16Foundations, Theory, and