Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Architectural Adaptation Software Architecture Lecture 25.

Similar presentations


Presentation on theme: "Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Architectural Adaptation Software Architecture Lecture 25."— Presentation transcript:

1 Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Architectural Adaptation Software Architecture Lecture 25

2 Foundations, Theory, and Practice Software Architecture 2 Adaptation Change is endemic to software u 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 circumstances

3 Foundations, Theory, and Practice Software Architecture 3 Goals 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 perspective

4 Foundations, Theory, and Practice Software Architecture 4 Sources and Motivations for Change Corrective Changes u Bug fixes Modification to the functional requirements u New features are needed u Existing ones modified u Perhaps some must be removed New or changed non-functional system properties u Anticipation of future change requests Changed operating environment Observation and analysis

5 Foundations, Theory, and Practice Software Architecture 5 Changes Arising from Product Line Forces Creating a new variant u Change at branch point u E.g.: Adding an integrated TV/DVD device to a TV product line Creation of a new branch point Merging product (sub)lines u Rationalizing their architectures

6 Foundations, Theory, and Practice Software Architecture 6 Motivation for Online Dynamic Change Non-stop applications u software cannot be stopped because the “application” cannot be stopped u E.g., 24/7 systems Maintaining user or application state u stopping the software would cause the user to lose (mental) context u saving and/or recreating the software’s application state would be difficult or costly Re-installation difficulty u applications with complex installation properties u E.g., software in an automobile

7 Foundations, Theory, and Practice Software Architecture 7 Stewart 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 change

8 Foundations, Theory, and Practice Software Architecture 8 Shearing Layers in a Building Figure adapted from “How Buildings Learn”; Stewart Brand, © 1994 Stewart Brand.

9 Foundations, Theory, and Practice Software Architecture 9 The Six Shearing Layers Site: the geographical setting, the urban location, and the legally defined lot u its boundaries and context outlast generations of ephemeral buildings. Structure (“the building”): the foundation and load- bearing elements u perilous and expensive to change, so people don’t Skin: exterior surfaces u change every ~20 years, to keep up with fashion, technology, or for repair

10 Foundations, Theory, and Practice Software Architecture 10 The 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 Stuff: chairs, desks, phones, pictures, kitchen appliances, lamps, hair brushes u things that switch around daily to monthly

11 Foundations, Theory, and Practice Software Architecture 11 To Shear or Not to Shear – Pompidou Center Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

12 Foundations, Theory, and Practice Software Architecture 12 The Six Shearing Layers Site Structure Skin Services Space Plan Stuff How do these relate to software architecture?

13 Foundations, Theory, and Practice Software Architecture 13 Changing Component Interiors A component’s performance may be improved by a change to the algorithm that it uses internally Capabilities that facilitate component adaptation u Knowledge of self and exposure of this knowledge to external entities u Knowledge of the component’s role in the larger architecture u Pro-active engagement of other elements of a system in order to adapt

14 Foundations, Theory, and Practice Software Architecture 14 Change 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” u but, subsequent changes to previously unmodified methods become even more complex

15 Foundations, Theory, and Practice Software Architecture 15 Connector Change Typically changes to connectors are motivated by u 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 u E.g., connectors supporting event-based communication u What is the downside?

16 Foundations, Theory, and Practice Software Architecture 16 Change in the Configuration Changes to the configuration of components and connectors represents fundamental change to a system’s architecture Effectively supporting such a modification requires working from an explicit model of the architecture Many dependencies between components will exist, and the architectural model is the basis for managing and preserving such relationships

17 Foundations, Theory, and Practice Software Architecture 17 Change Agents and Context (1) Change Agents – Identity and Location u The processes that carry out adaptation may be performed by human automated agents a combination thereof u If an adaptation agent is part of a deployed application from the outset, the potential is present for an effective adaptation process u Agent may have access to contextual information u E.g., periodically a user of a desktop OS is notified when an OS or application upgrade is available

18 Foundations, Theory, and Practice Software Architecture 18 Change Agents and Context (2) Knowledge u Agent might need knowledge to mitigate adaptation risk u Agent has to know the constraints that must be retained in the modified system u If the system’s architectural design decisions have been violated, architectural recovery will be required Degree of Freedom u Freedom that the engineer has in designing the changes u Greater freedom  large solution space u By learning the constraints of the system, the coherence of the architecture can be retained

19 Foundations, Theory, and Practice Software Architecture 19 Time of Change Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

20 Foundations, Theory, and Practice Software Architecture 20 Architecture-Centric Adaptation In the absence of explicit architecture the engineer is left to reason about adaptation u from memory u from source code Architecture can serve as the primary focus of reasoning about potential adaptations u Descriptive architecture is the reference point

21 Foundations, Theory, and Practice Software Architecture 21 Conceptual Architecture for Adaptation From: “An Architecture-based Approach to Self-Adaptive Software”, Oreizy, et.al. IEEE Intelligent Systems, 14 (3), 1999.

22 Foundations, Theory, and Practice Software Architecture 22 Activities, Agents, and Entities Adaptation management and evolution management can be separated into three types of activities u Strategic refers to determining what to do u Tactical refers to developing detailed plans for achieving the strategic goals u Operations refers to the nuts-and-bolts of carrying out the detailed plans

23 Foundations, Theory, and Practice Software Architecture 23 Strategy, Tactics, and Operations Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

24 Foundations, Theory, and Practice Software Architecture 24 Categories of Techniques Observing and collecting state Analyzing data and planning change Describing change descriptions Deploying change descriptions Effecting the change

25 Foundations, Theory, and Practice Software Architecture 25 Architectures/Styles that Support Adaptation Explicit models First-class connectors Adaptable connectors Message-based communication …others?

26 Foundations, Theory, and Practice Software Architecture 26 Architectures/Styles Supporting Adaptation Application programming interfaces (API) Scripting languages Plug-ins Component/object architectures Event interfaces

27 Foundations, Theory, and Practice Software Architecture 27 API-Based Extension Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

28 Foundations, Theory, and Practice Software Architecture 28 Plug-In Based Extension Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

29 Foundations, Theory, and Practice Software Architecture 29 Component-Object Approach Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

30 Foundations, Theory, and Practice Software Architecture 30 Scripting-Based Extension Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

31 Foundations, Theory, and Practice Software Architecture 31 Event-Based Extension Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

32 Foundations, Theory, and Practice Software Architecture 32 The Special Problems of On-the-fly Change The principle of quiescence u A node in the active state can initiate and respond to transactions. u The state identified as necessary for reconfiguration is the passive state, node must respond to transaction not currently engaged in a transaction that it initiated it will not initiate new transactions


Download ppt "Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Architectural Adaptation Software Architecture Lecture 25."

Similar presentations


Ads by Google