3. Air traffic control systems
Telephone switching
Unacceptable
Increased cost
delays
Shut down &
restart system
Losing
Any other?
customers
4. 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
5. 1. Changes to system requirements
2. Changes to system implementation
Runtime Software
Evolution supports
both type of
changes.
6. 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)
7. Corrective evolution
Remove software faults
Perfective evolution
Enhance product functionality
Adaptive evolution
To run in a new environment
8. Perfective evolution
Observer design pattern
State of the added component
Example: Adobe Photoshop plug-in
10. Two conditions are required:
The state of the executing component must be
transferred to the new component
Both components must not be simultaneously
active during the change
11. Recombining existing functionality to modify
overall system behavior
Altering connector bindings
Example: UNIX’s pipe and filter
13. 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
14. Connectors separate a component’s
interfacing requirements from its functional
requirements
Connector purposes:
Specifying communication mechanism
Visualizing and debugging system behavior
Integrating tools
15. 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
16. 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
17. 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
18.
19. Java C2 class framework
Fundamental C2 concepts: components,
connectors, and messages
Current implementation encapsulates
architectural model in an Abstract Data Type
(ADT)
20.
21. 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
22. Argo
Graphical depiction of the architectural model
ArchShell
Textual, command-driven interface for specifying
runtime modifications
Extension Wizard
Deploy modifications to end-users
23.
24. A simple logistic system for routing incoming
cargo to a set of warehouses
30. 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.
