chapter 14 part ii: architectural adaptation
DESCRIPTION
Chapter 14 Part II: Architectural Adaptation. By: Aaron Mckay. Causes of Architectural Adaptation. Change is triggered when someone determines that the behavior of a system is not as desired: User – Doesn’t like the interface Developer – Code optimization - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/1.jpg)
Chapter 14 Part II:Architectural AdaptationBY: AARON MCKAY
![Page 2: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/2.jpg)
Causes of Architectural Adaptation
Change is triggered when someone determines that the behavior of a system is not as desired: User – Doesn’t like the interface Developer – Code optimization Manager – Sees potential improvements
![Page 3: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/3.jpg)
Basic Techniques
State: The run time values of a program’s objects. Since the values are constantly changing, state is relative to time. Monitoring State is useful for discovering what will be effected when
a change is made. Unrepresented features might not rely on state
Example: Adding a feature to an ATM to trigger an alarm and go into safe mode when G-forces are detected.
Platform changes Software might have to be changed in order to work on various
platforms.
![Page 4: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/4.jpg)
Gathering the State
Techniques: Observing the User Interface Monitoring a program Bolt-on – hardware analyzers to inspect program state without
disturbance to run time. Seeding a program with print statements
![Page 5: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/5.jpg)
Analyzing and Planning a Change
Monitor for specific situations: Example: Electronic Commerce Application: When customer
transactions increase, bring additional servers online MTAT System: Helps engineers understand event based
architecture using trace connectors. Trace connectors feed copies of all messages into a relational database. This allows the engineer to understand the relationship of
components. For example, when message a from component A is sent, then message b from component B is also sent.
![Page 6: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/6.jpg)
Proposing a Change
Types of changes: Patches: Initially used to refer to small changes to a file. Service Packs: Collection of changes to an application Upgrades: Improvements to speed or quality Releases: Different versions of the software
![Page 7: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/7.jpg)
Analyzing a Proposed Change
Is the solution complete and appropriate for deployment to the target platforms?
Are there any unattached links in the software? Consistency Are all components properly licensed? Example: GPL licenses on
commercial products Does communication between components meet security
requirements? If over network is it encrypted?
![Page 8: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/8.jpg)
Applying Changes to an Architecture
Once the changes needed are listed, a person is assigned to make the changes, and are responsible for making all of the requested changes.
Changes made are reviewed and tested. Old system is compared to the new system to make sure desired
modifications were successful.
![Page 9: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/9.jpg)
Issues with Applying Changes
If a system is required to be online at all times, deployment can be difficult.
Failures during the update process due to network and host problems.
![Page 10: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/10.jpg)
Styles That Support Adaption
ArchStudio – supports architecture based adaption. Uses architecture implementation framework to ensure mapping
between architecture and implementation. Calculates the difference between two architectures Merges the original and the differences (the new model is not
needed). The merging engine acts as a change client. Supports additions, modifications, and removal of elements.
![Page 11: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/11.jpg)
Interface Focused Architectural Solutions
APIs (one of the most common adaptation methods) – Allow the developers to extend the application. Developers use existing functions and create new modules by combining these functions.
Plug-Ins – Similar to APIs, but instead of the component calling the original application, the application calls out to the added component. They are registered with the application so the application is aware of its existence.
Component/object Architectures – Add-ons alter the behavior of the host application by adding new components that interact with the existing components.
![Page 12: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/12.jpg)
Interface Focused Architectural Solutions (Continued)
Scripting Languages: The application provides its own language and run time environment. The architect uses this to implement add-ons and allows the user to be more creative and use the program in their own way. Scripting languages can be easy enough for non-programmers to use.
![Page 13: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/13.jpg)
On-The-Fly Autonomous Adaption Problems
Adapting a system while it remains in operation complicates the process.
Human adaption is absent or greatly minimized. Compared to living in a house while under renovation:
Sometimes necessary but seldom pleasant. Also compared to surgery, we want to keep the patient alive (running) while the procedure takes place.
Only run what is necessary to keep running Timing: make changes during time of least activity Restoration or transfer of state
![Page 14: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/14.jpg)
Conditions for When to Effect a Change
Timing: Make changes at ideal times. Example: make changes to a weather satellite while the weather is clear since weather is typically slow changing.
Make changes to a component when it is going to be down anyways.
Some systems will be much more complicated and there might not be a good time to update. For this situation, try to make changes one component at a time to reduce down time and chances of error.
![Page 15: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/15.jpg)
Management of State
Keep track of state. If component A is replaced with component B, then component B needs to start with the same state that component A ended with.
Externalize the state: Copy the state to a third party and initialize the new component from the third party upon startup.
![Page 16: Chapter 14 Part II: Architectural Adaptation](https://reader036.vdocuments.site/reader036/viewer/2022081513/5681628c550346895dd2f9ca/html5/thumbnails/16.jpg)
Conclusion
Making changes to an application can vary in difficulty Many techniques are available for making these changes and
proper planning is important. Designing a program with change in mind can help ease the
process up improving the program. Keep in mind potential improvements even if you don’t think they
are likely to be added.