Chapter 14 Part II:Architectural AdaptationBY: 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.