Self-Adaptive, Healing Architectures

Software engineering aims for the systematic, principled design and deployment of applications that fulfill software's original promise-applications that retain full plasticity throughout their lifecycle and that are as easy to modify in the field as they are on the drawing board... Self-adaptive software will provide the key. — Peyman Oreizy

Concepts

Current software architecture research assumes that a system's architecture is static, in the sense that the architecture does not evolve during execution. Modification of static systems typically require the system to be exited, modified, and then restarted.
Many system architectures are dynamic, meaning that they evolve during execution. Examples include systems built using .NET, CORBA, or EJB, in which new components may be loaded and unloaded during execution.
Many systems could benefit from the dynamism afforded by a dynamic architecture. Examples include systems characterized as long running and mission critical since the delays and risks associated with shutting down these systems for upgrades may be expensive.
Not all dynamism can reasonably be driven by human operators, some must be self-adaptive, changing in response to its environment such as distributed systems faced with unpredictable connectivity, or self-healing such as space exploration vehicles which may not have the luxury of a terminal.
Dynamism can exist at many different levels of granularity from one extreme of conditional expressions at the source code level to another extreme of evolutionary programming and incorporating machine-learning techniques to generate new algorithms on the fly. The former extreme intertwines adaptation specifications with application specifications making it difficult to independently analyze and evolve concerns of software adaptation from software functionality.

Techniques

Enact dynamism at the architectural level. An architectural perspective shifts focus away from source code to coarse-grained components and their interconnections. This allows designers to abstract away obscuring detail and focus on the big picture: the system structure, interactions among components, the assignment of components to processing elements, and runtime change.
Strictly separate computation from communication using flexible, first-class, connectors. This support runtime evolution by letting a system's computation and communication relationships evolve independently from one another, including rearranging and replacing the components and connectors of an application during runtime.
Separate adaptation management from evolution management (the "Figure-8" diagram). Adaptation management monitors and evaluates the application and its operating environment, plans adaptations, and deploys change descriptions to the running application. Evolution management involves the process of applying and controlling those changes, maintaining consistency between the software architectural model and its running implementation.
Maintain system consistency and integrity using a knowledge-based self-adaptation approach that reasons over the space of possible adaptations. This ensures that applying a selected adaptation results in an architecture where each elements' assumptions about the operating environment remain valid.

Styles

C2 - Chimera-2, a component- and message-based architectural style for component reuse and flexible system composition that is well-suited for large-scale, heterogeneous, and distributed applications
Weaves - networks of concurrently executing tool fragments that communicate by passing objects

Tools

AEM - Architecture Evolution Manager, a part of ArchStudio 3.0
KBAAM - Knowledge-Based Architectural Adaptation Management
ArchShell [LEGACY] - a command line tool supporting runtime dynamism

Self-Adaptive, Healing Architectures

Concepts

Techniques

Styles

Tools

See Also