Air traffic control systems Telephone switching Unacceptable Increased cost delays Shut down & restart system Losing Any other? customers
Shifts developer focus away from lines-of- code to coarse-grained components and overall interconnection structure. Enables system designers to focus on the “big picture” Explicit modeling of Govern interactions Minimize component among components interdependencies
1. Changes to system requirements2. Changes to system implementation Runtime Software Evolution supports both type of changes.
Postponing updates until the next scheduled downtime Web Servers to redirect traffic to a redundant host Modeling changes at the statement in imperative programming languages (redefine variables if affected by a change) Weaves (passing object references i.e., pointers)
Corrective evolution Remove software faults Perfective evolution Enhance product functionality Adaptive evolution To run in a new environment
Perfective evolution Observer design pattern State of the added component Example: Adobe Photoshop plug-in
Treating components’ internal structure as a black box Components should not communicate by directly referencing one another Each component must provide a minimal amount of functional behavior to participate in runtime change
Connectors separate a component’s interfacing requirements from its functional requirements Connector purposes: Specifying communication mechanism Visualizing and debugging system behavior Integrating tools
Layered, event-based architectural style C2 All communication among components occurs via connectors. Every C2 component has top and bottom sides, each side has a single port Every C2 connector has top and bottom sides, but the number of ports is determined by the components attached to it
Explicit architectural model Interconnection between components and connectors, and their mappings to implementation modules. Describing runtime change Modification description uses operations for adding and removing components and connectors, replacing components and connectors, and changing the architectural topology
Governing runtime change Constrains play a natural role in governing change. Mechanisms governing runtime change should also contain when particular changes may occur Reusable runtime architecture infrastructure Maintains the consistency between the architectural model and implementation as modifications are applied
Java C2 class framework Fundamental C2 concepts: components, connectors, and messages Current implementation encapsulates architectural model in an Abstract Data Type (ADT)
Correspondence between Architectural Model and Implementation Determines whether the modification is valid (architectural constraint mechanism or external analysis tool ) AEM of C2-style rules constrain changes
Argo Graphical depiction of the architectural model ArchShell Textual, command-driven interface for specifying runtime modifications Extension Wizard Deploy modifications to end-users
A simple logistic system for routing incoming cargo to a set of warehouses
1. All components and connectors must be written in Java C2 class framework.2. Components addition, removal and Architectural Model reconfiguration are supported by not Component Replacement.3. Only checks invariants derived from the C2- style rules.