# Runtime View

**In short:** The runtime view shows how building blocks work together and talk to each other while the system runs. It covers a few chosen scenarios, picked for architectural relevance rather than completeness.

## Explanation

A static view shows which building blocks exist. The runtime view shows what they do. It describes concrete behavior and interactions, written as scenarios (f1, f8).

**What to cover**

The arc42 template (see "arc42 Architecture Documentation Template") names several kinds of scenarios (f8):

- Key use cases.
- Interactions across external interfaces.
- Start-up and administration.
- Error cases.

**Choosing scenarios**

You do not document every flow. The main test is architectural relevance (f2). Pick scenarios that teach a reader something important about how the system is built. Skip the rest.

**Notations**

Many notations work. arc42 lists step lists, flowcharts, sequence diagrams, BPMN and state machines (f3). It specifically suggests sequence diagrams (f7). See "UML Sequence Diagram" for how they read.

The C4 model has a similar idea, called a dynamic diagram. It shows how elements from the static model collaborate at runtime (f9). It builds on UML communication diagrams, which number the interactions. You can also draw it in sequence style (f10).

**Traceability**

Each activity in a scenario should map to an existing building block (f6). That keeps the runtime view consistent with the static structure.

## Example

Imagine an online shop. The team documents "customer places an order" as a numbered list:

1. The web shop receives the order.
2. The web shop asks the payment service to charge the card.
3. The payment service confirms.
4. The web shop passes the order to the warehouse system.

Each named actor is a building block already shown in the static view. The team skips minor flows, such as changing a profile photo, because they teach nothing about the architecture.

## Trade-offs

The facts support one clear limit: you must choose. Scenarios are selected for architectural relevance, not completeness (f2). A runtime view will therefore leave many flows undocumented on purpose.

You also have a choice of notation. Sequence diagrams are the suggested default (f7), but other notations are listed as valid (f3).

A generic runtime scenario: building blocks exchange messages in order.

```plantuml
@startuml
actor Customer
participant "Web Shop" as W
participant "Payment Service" as P
participant "Warehouse System" as H
Customer -> W : place order
W -> P : charge card
P --> W : confirmed
W -> H : ship order
@enduml
```

## Checks

- Scenarios are selected for architectural relevance, not to cover every flow.
- Each activity in a runtime scenario maps to an existing building block.
- The runtime view covers key use cases, external interfaces, start-up or administration, and error cases as scenarios.
- Scenarios use a recognized notation, such as sequence diagrams, step lists, flowcharts or BPMN.

## Related

- [UML Sequence Diagram](https://arc.fuet.ch/concepts/modeling-uml/sequence-diagram.md)
- [arc42 Architecture Documentation Template](https://arc.fuet.ch/concepts/documentation/arc42-documentation-template.md)
- [C4 Model](https://arc.fuet.ch/concepts/documentation/c4-model.md)
- [Component View](https://arc.fuet.ch/concepts/documentation/component-view.md)
- [Essential Architecture Views (Context, Component, Runtime, Distribution)](https://arc.fuet.ch/concepts/documentation/contemporary-essential-views.md)
- [Runtime View Antipattern: Code-Level Activity Diagram](https://arc.fuet.ch/concepts/documentation/runtime-view-antipattern-code-level-activity-diagram.md)
- [Traceability](https://arc.fuet.ch/concepts/principles/traceability.md)
- [BPMN 2.0 Notation](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-2-0-notation-overview.md)

## Sources

- [6 - Runtime view | arc42 Documentation](https://docs.arc42.org/section-6/) — docs.arc42.org, accessed 2026-11-09
- [Dynamic diagram | C4 model](https://c4model.com/diagrams/dynamic) — c4model.com, accessed 2026-11-09