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
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.
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.
- 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
- 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
- Open Architecture Software: A Flexible Approach to Decentralized Software Evolution
- Using Weaves for Software Construction and Analysis (ICSE 1991)
- An Architecture-based Approach to Self-Adaptive Software (IEEE Intelligent Systems and Their Applications, 1999)