Software Architecture

The structure of a system in terms of its components, the connectors between them, and their configuration and properties — the level of abstraction at which system-wide qualities (latency, availability, cost, reliability) are expressed and reasoned about. In self-adaptive systems the architecture is not just a design document: architecture-based adaptation makes a runtime model of the component-and-connector graph the artefact that is monitored, checked against constraints, and reconfigured, because it is abstract enough to be tractable yet concrete enough to map onto real system elements.

This stance runs from An Architecture-Based Approach to Self-Adaptive Software (Oreizy et al. 1999), which first proposed keeping the architecture “in the loop”, to Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure (Garlan et al. 2004), where the software architecture literally is the runtime model against which constraints are evaluated and repairs planned, and the layered separation of Self-Managed Systems - an Architectural Challenge.

In this vault

Backlinks

Linked Pages

Self-Adaptation

A system’s capability to modify its own behaviour or structure at runtime in response to internal or environmental change, without external intervention. It is typically implemented as a MAPE-K loop (Monitor-Analyse-Plan-Execute over a Knowledge base), the control abstraction introduced by Autonomic Computing.

In this vault

MAPE-K

The reference control loop of Autonomic Computing and self-adaptive software: an autonomic manager runs a closed feedback loop of Monitor → Analyse → Plan → Execute over a shared Knowledge base, acting on a managed element through sensors (probes/gauges) and effectors.

Monitor — collect and aggregate sensor data from the managed element and its environment.
Analyse — detect when adaptation is needed (symptoms, constraint/SLA violations, drift from goals).
Plan — select a course of action (a strategy/tactic, reconfiguration, or repair).
Execute — enact the plan through effectors on the managed element.
Knowledge — models, policies, goals, and history shared across the four phases (see Models@run.time).

Introduced in The Vision of Autonomic Computing (Kephart & Chess 2003) as the organising abstraction for the self-* properties (self-configuration, self-healing, self-optimisation, self-protection). It is the connective tissue linking architecture-based adaptation (Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure), reference models (Three-Layer Reference Model), and the broader survey landscape (Self-Adaptive Software - Landscape and Research Challenges).

In this vault

Models@run.time

The principle that a self-adaptive system should keep a causally-connected, runtime-accessible model of itself (and often of its environment and goals) that both reflects the running system and can be used to reason about and drive adaptation. Where classic model-driven engineering uses models at design time, models@run.time extends abstract models into the running system as first-class artefacts that the adaptation logic queries and updates.

Such a runtime model is the natural home for the Knowledge in a MAPE-K loop: the Monitor phase keeps it in sync with reality, and the Analyse/Plan phases reason over it rather than over raw code. Architecture-based approaches like Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure make the software architecture the runtime model against which constraints are evaluated and repairs planned.

Architectural Pattern

A reusable, named solution to a recurring system-level design problem, described in terms of components, connectors, and constraints on their composition. Unlike design patterns, architectural patterns govern overall structure and cross-cutting quality attributes such as dependability or scalability.

In this vault

Self-Managed Systems - an Architectural Challenge

Self-Managed Systems: an Architectural Challenge

Reference: Kramer, J. & Magee, J. (2007). Self-Managed Systems: an Architectural Challenge. In Future of Software Engineering (FOSE ’07), at ICSE 2007, pp. 259–268. DOI: 10.1109/FOSE.2007.19. URL

Summary

Kramer and Magee frame self-management as fundamentally an architectural problem and offer a reference model for structuring it. Building on their work on dynamic software architecture — systems whose components and connectors can be added, removed, and rewired at runtime — they argue that self-configuration, self-healing, and self-optimisation are best organised around explicit architectural change rather than ad-hoc code.

Their central proposal is a three-layer reference model (see Three-Layer Reference Model), adapted from Gat’s three-layer architecture in autonomous robotics. The bottom component-control layer is the running application, instrumented to report status and to reconfigure itself. The middle change-management layer holds a repertoire of pre-computed plans that respond to status reports and effect reconfigurations, escalating upward when it has no plan for the situation. The top goal-management layer synthesises new plans from high-level goals via (slower) deliberative planning. Separating layers by timescale and abstraction lets fast reactive adaptation and slow deliberative planning coexist cleanly.

The paper is as much an agenda as an architecture. Kramer and Magee catalogue the hard open problems this structure exposes — deriving correct plans from goals, guaranteeing consistency and safety during runtime reconfiguration, managing decentralised control across many self-managed components, and eliciting and evolving the goals themselves — positioning assurance of self-adaptive behaviour as a first-order software-engineering challenge.

Key Ideas

Self-management is an architectural problem, grounded in dynamic (runtime-reconfigurable) software architecture.
Three-layer reference model: component control → change management → goal management, borrowed from robotics.
Separation by timescale/abstraction: fast reactive plan execution below, slow deliberative planning above; escalation when no plan applies.
Runtime reconfiguration must preserve consistency and safety of the executing system.
A research agenda: plan synthesis from goals, assurance, decentralised control, goal elicitation and evolution.

Connections

Conceptual Contribution

Claim: Self-managed systems should be structured as a three-layer architecture that separates component control, change management, and goal management — matching each adaptation concern to the timescale and abstraction at which it operates.
Mechanism: A dynamically reconfigurable component layer reports status upward; a change-management layer applies pre-computed plans and escalates when none fit; a goal-management layer generates new plans from high-level goals through deliberative planning — a layered decomposition of the Plan/Execute half of a MAPE-K loop.
Concepts introduced/used: Three-Layer Reference Model, Dynamic Software Architecture, MAPE-K, Runtime Reconfiguration, Goal Management
Stance: architecture / research agenda
Relates to: Gives The Vision of Autonomic Computing a concrete reference architecture and complements the reusable-infrastructure stance of Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure; the robotics lineage connects to layered control in A Robust Layered Control System; its open problems are surveyed in Self-Adaptive Software - Landscape and Research Challenges.

Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure

Rainbow: Architecture-Based Self-Adaptation with Reusable Infrastructure

Reference: Garlan, D., Cheng, S.-W., Huang, A.-C., Schmerl, B. & Steenkiste, P. (2004). Rainbow: Architecture-Based Self-Adaptation with Reusable Infrastructure. IEEE Computer 37(10): 46–54. DOI: 10.1109/MC.2004.175. URL

Summary

Rainbow is a framework for adding self-adaptation to existing systems by using an architectural model of the target system as the basis for monitoring, problem detection, and repair. Its core claim is that a software architecture — components, connectors, and properties — is the right level of abstraction for reasoning about system-wide adaptation: it is abstract enough to be tractable and to express global constraints (latency, cost, availability), yet concrete enough to map to real system elements. This is a concrete realisation of the MAPE-K loop where the architecture is the runtime model (see Models@run.time).

The framework provides a reusable infrastructure with clearly separated, customisable parts. Probes instrument the running system; gauges aggregate probe readings into updates on the architectural model; a model manager maintains the architecture; a constraint evaluator checks the model against invariants and triggers adaptation when they are violated; and an adaptation engine selects and carries out repairs through system-level effectors. Rainbow separates this generic machinery from a system-specific adaptation knowledge layer — the architectural style, constraints, and repair strategies — so the same infrastructure can be retargeted to different systems at much lower cost than bespoke, code-level adaptation.

Rainbow’s key engineering contribution is thus reuse: rather than weaving adaptation logic into application code, developers supply an architectural model, a set of constraints, and a library of repair strategies, and the shared infrastructure supplies the control loop. The approach is later extended with utility-based strategy selection and the Stitch adaptation language, and exercised on canonical exemplars such as the Znn.com news-service testbed, which together made Rainbow the reference example of architecture-based self-adaptation.

Key Ideas

Architecture as the locus of adaptation: reason about the system through its component-and-connector model, not its source.
Reusable control-loop infrastructure: probes, gauges, model manager, constraint evaluator, adaptation engine, effectors.
Separation of generic mechanism from system-specific adaptation knowledge (style, constraints, strategies) — the source of reuse and low retargeting cost.
Constraint-triggered repair: violated architectural invariants drive selection of a repair strategy.
Externalised adaptation: the adaptation logic lives outside the target system, keeping the application unchanged.
Later refinements: utility-based strategy selection and the Stitch strategy language; Znn.com as the standard testbed.

Connections

Conceptual Contribution

Claim: Self-adaptation should be engineered at the architectural level using a reusable framework: a runtime model of the system’s architecture, plus system-specific constraints and repair strategies, lets the same adaptation infrastructure be retargeted across systems instead of hand-coded each time.
Mechanism: Probes instrument the system; gauges update an architectural model; a constraint evaluator detects invariant violations; an adaptation engine selects repair strategies and enacts them via effectors — a MAPE-K loop over an architectural runtime model, with generic infrastructure cleanly separated from a customisable adaptation-knowledge layer.
Concepts introduced/used: Architecture-Based Adaptation, MAPE-K, Models@run.time, Software Architecture, Constraint Evaluation, Utility Function
Stance: engineering / framework
Relates to: The canonical architecture-based exemplar of The Vision of Autonomic Computing; complements the layered separation of concerns in Self-Managed Systems - an Architectural Challenge and sits inside the taxonomy of Self-Adaptive Software - Landscape and Research Challenges. Its “architecture as formal artefact” stance rhymes with pattern-based dependability in Architectural Patterns for Dependable Software Systems - SOL.

An Architecture-Based Approach to Self-Adaptive Software

Reference: Oreizy, P., Gorlick, M. M., Taylor, R. N., Heimbigner, D., Johnson, G., Medvidovic, N., Quilici, A., Rosenblum, D. S. & Wolf, A. L. (1999). An Architecture-Based Approach to Self-Adaptive Software. IEEE Intelligent Systems 14(3): 54–62. DOI: 10.1109/5254.769885. URL

Summary

This paper is one of the founding statements of architecture-based self-adaptation, arguing — several years before the MAPE-K vocabulary crystallised — that self-adaptive software should be organised around an explicit model of its own software architecture. Rather than scattering adaptation logic through application code, the authors propose using the architectural description (components, connectors, configurations) as the artefact that is monitored, reasoned about, and modified at runtime. Keeping the architecture “in the loop” gives adaptation a principled, system-wide handle: global properties and constraints can be stated and checked at the architectural level, and change can be expressed as reconfiguration of the component-and-connector graph.

The paper decomposes self-adaptation into two intertwined processes. Adaptation management is the outer control activity — evaluating the running system, deciding when and how to change it, and enacting the change while preserving consistency and integrity. Evolution management maintains the architectural model itself and mediates all runtime modifications so that the implementation and its architectural description stay consistent. The authors frame the hard problems as when to adapt, what to change, and how to make the change safely (open questions of validity, ordering, and state transfer during dynamic reconfiguration). They ground the discussion in their work on the C2 architectural style and the ArchStudio/dynamic-reconfiguration tooling built around it.

Key Ideas

Architecture as the basis for adaptation: make the component-and-connector model a first-class, runtime-manipulable artefact, not just a design document.
Two processes: adaptation management (observe → decide → enact change) and evolution management (keep the architectural model and the running implementation consistent).
Dynamic reconfiguration as the mechanism of change: add, remove, replace, and rewire components at runtime under architectural constraints.
Central open questions: when to adapt, what to adapt, and how to adapt safely (consistency, integrity, state transfer, quiescence).
Grounded in the C2 style and explicit architectural modelling; a direct ancestor of later frameworks like Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure.

Connections

Conceptual Contribution

Claim: Self-adaptive software is best engineered around an explicit, runtime-accessible model of its own architecture, so that adaptation is reasoned about and enacted as principled reconfiguration of components and connectors rather than as ad hoc code changes.
Mechanism: Split the system into an adaptation-management loop that decides when/what/how to change and an evolution-management layer that keeps the architectural model causally connected to the running implementation, enacting change through dynamic reconfiguration under architectural constraints.
Concepts introduced/used: Architecture-Based Adaptation, Software Architecture, Models@run.time, Dynamic Reconfiguration, MAPE-K
Stance: engineering / position
Relates to: The direct architectural ancestor of Rainbow - Architecture-Based Self-Adaptation with Reusable Infrastructure and the layered separation in Self-Managed Systems - an Architectural Challenge; predates but anticipates the runtime-model idea later named Models@run.time, and sits inside the taxonomy of Self-Adaptive Software - Landscape and Research Challenges.

Software Architecture

In this vault

Related

Backlinks