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  Manager – Sees potential improvements

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.

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

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.

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

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?

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.

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.

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.

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.

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.

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

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.

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.

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.