arc42 section 6: Runtime View

Behavior of building blocks in important scenarios

The description covers the logical, development, process and physical (deployment) views. → 4+1 View Model
No single all-in-one model tries to show every aspect of the system. → Architectural View
Each view covers one aspect of the architecture and is not an overloaded all-in-one model. → Architecture View Model
Each viewpoint names the stakeholders whose concerns it reflects. → Architecture Viewpoint
Each component is described as related functionality behind a well-defined interface. → C4 Model
The documentation names an editor that can reopen the embedded diagrams, such as VS Code with the Draw.io Integration extension. → Diagram Metadata in PNG (drawio.png)
Generated diagrams are regenerated automatically before the documentation build. → Diagrams as Code
The runtime view covers a representative selection of architecturally relevant scenarios. → Essential Architecture Views (Context, Component, Runtime, Distribution)
Each view states which stakeholders and concerns it addresses. → Model vs. View
Every relationship line has a label that matches its direction and intent. → Rules of Thumb for Modeling
Scenarios are selected for architectural relevance, not to cover every flow. → Runtime View
Each activity in a runtime scenario maps to an existing building block. → Runtime View
The runtime view covers key use cases, external interfaces, start-up or administration, and error cases as scenarios. → Runtime View
Each runtime scenario was chosen for its architectural relevance, and the set is a representative selection. → Runtime View Antipattern: Code-Level Activity Diagram
Scenarios refer to building blocks, not to code-level elements such as package or script names. → Runtime View Antipattern: Code-Level Activity Diagram
Each scenario assigns activities to building blocks, so responsibilities are visible. → Runtime View Antipattern: Code-Level Activity Diagram
Any non-standard notation is accompanied by a legend. → Self-Invented Notation Drawback
The documentation contains a building block view showing the static decomposition of the system. → View Creation Method
Domain events used inside one domain model are distinguished from integration events that cross bounded contexts. → Domain Event
Use cases carry a goal level, aimed at user goal or subfunction for API and service design. → Consistency of User Story and Use Case
The level of detail of each use case fits its audience, and the template is simplified where less detail is needed. → Use Case
Where a channel has several competing receivers, the document states that only one receiver consumes each message. → Connector Cardinality
Each connector names its roles, so each participant in the interaction is identifiable. → Software Connector
The claim check is published only after the payload write succeeds. → Claim Check
The document says what happens when one reply is missing or delayed, since that blocks the whole aggregate. → Composed Message Processor
Where publishers broadcast events, the document says that each subscriber gets its own copy and the publisher does not name recipients. → Connector Transparency (Direct vs Indirect Connection)
Where receivers need only a few items from a large message, the document names a filtering step that removes the rest. → Content Enricher and Content Filter
The document distinguishes removing data inside a message (Content Filter) from dropping whole messages (Message Filter). → Content Filter
The document states what happens to a message that matches no rule. → Content-based Router
The design states that each request carries a unique ID. → Correlation Identifier
Where requests expect replies on a callback queue, the document names that queue as the return address sent with the request. → Correlation Identifier
Senders have a documented rule for choosing the channel that matches the data type. → Datatype Channel
Someone is named to watch and clear the dead-letter queue, since it is not cleaned automatically. → Dead Letter Channel
The document says how the router handles a message that matches several recipients, for example first match or all matches. → Dynamic Router
A dead letter queue or equivalent exists for messages that cannot be delivered. → Enterprise Integration Patterns
Events that must stay in order share a partition key, and the document states where order is not guaranteed. → Event Sourcing with Distributed Event Log
Where a push consumer is used with RabbitMQ, a prefetch limit is set and is not 0 (unlimited). → Event-Driven Consumer
The document says how duplicates are detected, for example by storing the IDs of processed messages. → Idempotent Receiver
The document separates receiver-judged invalid content from delivery failures handled by the messaging system (Dead Letter Channel). → Invalid Message Channel
Each channel carries one data type, so receivers can tell the message type from the channel. → Message Channel
The design states what happens to messages that do not match: dropped, sent to a discard channel, or raised as an error. → Message Filter
Every Aggregator that waits for replies defines a time-out strategy, so one missing message cannot block processing. → Message Routing
Each message in a sequence carries a position identifier that orders it. → Message Sequence
Request messages carry a Return Address in the header rather than in the application data. → Message Structure
If a common message format is used, it is independent of any specific application. → Message Translator
Consumers that can see duplicate messages say how they ignore them, for example with a stable deduplication key. → Messaging
The document explains how the router detects the format of each message, including messages with no explicit type. → Normalizer
Where several consumers share a channel, the document notes that processing order is not guaranteed and says how order is handled if needed. → Point-to-Point Channel
Where consumers block while waiting, the document accounts for the thread each blocked consumer uses. → Polling Consumer
The document names the central unit that keeps the state of the sequence and decides the next step. → Process Manager
The document states whether any consumer relies on the order of messages across subscribers. → Publish/Subscribe Channel
Where Scatter-Gather is used, the document states whether a Recipient List distributes the requests and so controls the recipients. → Recipient List
Each application’s data is reachable only through its exposed procedures. → Remote Procedure Call
The reply channel is point-to-point, so replies reach only the requestor. → Request-Reply
Requests carry a return address in the message header, so the replier does not need to know it in advance. → Request-Reply
Request messages carry the reply destination in a header, not in the business data. → Return Address
Requesters discard replies whose correlation ID they do not recognize. → Return Address
The document states whether the slip is computed once up front or must be computed on the fly, and picks the matching pattern (Routing Slip or Dynamic Router). → Routing Slip
The document says whether a missing or delayed reply can block the combined result. → Scatter/Gather
The document states which message headers or properties consumers select on, because selectors cannot use the message body. → Selective Consumer
The document says how differences in sender and receiver speed are handled, for example by a buffer. → Stream Connector
Where a sender must keep working while the receiver is down, a queue or similar asynchronous connector is used. → Synchronous vs Asynchronous Connector
Long chains of synchronous calls between services are identified, with a stated way to handle their combined downtime. → Synchronous vs. Asynchronous Communication
The visibility timeout or lock duration is set deliberately and is longer than normal processing time. → Timeout-based Delivery
The document states which ARIS version it follows (four views or five). → ARIS Process Views
Process chain diagrams are filed under the control view. → ARIS Process Views
Process models in the documentation have been checked for deadlock and lack of synchronization (soundness). → BPMN 2.0 Model Quality
The team names the modeling guidelines it follows for model quality, such as 7PMG. → BPMN 2.0 Model Quality
Each process model uses sequence flow to show the order of steps. → BPMN 2.0 Notation
Boundary events are modeled as intermediate catch events, and each is marked as interrupting or not on purpose. → BPMN 2.0 Notation
Reusable process logic is modeled as a call activity, not as a collapsed subprocess. → BPMN Activity
Each embedded subprocess has exactly one none start event. → BPMN Activity
Each event subprocess is marked clearly as interrupting or non-interrupting. → BPMN Activity
Ad hoc sub-processes in the model contain no start or end events. → BPMN Ad Hoc Sub-Process
Where no completion condition is defined, the team knows the sub-process ends once all activated elements are done. → BPMN Ad Hoc Sub-Process
Rules that must be enforced are modeled with real process elements, not only in text annotations, because engines ignore annotations. → BPMN Artifacts (Group and Text Annotation)
Operational-level process models use a separate pool per participant instead of lanes. → BPMN Collaboration Diagram
Interaction between participants is shown with message flows between pools. → BPMN Collaboration Diagram
Pools are ordered so message flows cross other pools as little as possible. → BPMN Collaboration Diagram
Each activity that may need undoing has a compensation boundary event attached to it. → BPMN Compensation Event
The model triggers compensation with a throwing compensation event inside the process scope that holds the completed activities. → BPMN Compensation Event
Connectors between two elements in the same pool are sequence flows, not message flows. → BPMN Connecting Object
Communication between participants is shown as message flow between separate pools. → BPMN Connecting Object
The default path from a decision point is marked with a slash on its sequence flow. → BPMN Connecting Object
Every process diagram uses sequence flow to show the order of steps. → BPMN Core Elements
Each joining gateway matches its split: a parallel join where all paths must arrive, an exclusive join only where one path is taken. → BPMN Core Elements
Data stores are used for information that must outlast a single process instance, such as a database or file system. → BPMN Data Element
The document states whether the tool treats data objects and data stores as modeling-only or as executable. → BPMN Data Element
Where a collaboration diagram shows a partner’s internals as hidden, that partner’s pool is drawn as a black box. → BPMN Diagram Types
Boundary events in the process models are intermediate catch events. → BPMN Event
Terminate end events inside a subprocess are understood to stop only that subprocess. → BPMN Event
Each message has exactly one sender and one recipient. → BPMN Focus on Connected Businesses
Every exclusive split that has a branch without a condition declares that branch as the default flow. → BPMN Gateway
Each branch of an event-based gateway leads to an intermediate catch event of type timer, message, or signal. → BPMN Gateway
Every inclusive (OR) split is closed by an inclusive join, not by a parallel join. → BPMN Gateway Mismatch Antipatterns
Each process run reaches any end event at most once (proper completion). → BPMN Gateway Mismatch Antipatterns
Each process level has about 10 activities or fewer, so it fits on one page. → BPMN Modeling Guidelines
Every process shows explicit start and end events. → BPMN Modeling Guidelines
XOR gateways show the X symbol, carry a question, and have outgoing flows labeled as answers. → BPMN Modeling Guidelines
No message flow connects two elements inside the same pool. → BPMN Swimlane (Pool and Lane)
Each loop in a model targeting Camunda 7 is modeled explicitly (for example with gateways), not with the loop marker. → BPMN Task Marker and Task Type
Each compensation handler is linked by association and triggered by a compensation event, not reached by sequence flow. → BPMN Task Marker and Task Type
Error boundary events in the model are interrupting. → Boundary Event
Escalations are handled by a catch event in the nearest parent flow scope. → Boundary Event
Important business objects have their lifecycle drawn as a state machine diagram or statechart. → Business Object Lifecycle
Process events are described as business-relevant states of information objects. → Business Object Lifecycle
Analytical process models include data such as time, cost and resources where inefficiencies are to be analyzed. → Capturing Business Behavior via Process Modeling
Each message has a single sender and a single recipient. → Data Exchange between BPMN Processes
Every parallel (AND) join in the process models is preceded by a parallel split, so no branch can fail to deliver a token. → Deadlock in Process Models
Process models have been checked for soundness, including option to complete. → Deadlock in Process Models
Each process model in the document contains neither a deadlock nor a lack of synchronization. → Errors in Process Models
Each outgoing flow of an event-based gateway leads to an event or receive task, not to a decision based on data. → Event-Based Gateway
If the target is Camunda 8, every outgoing flow of the event-based gateway ends at a timer, message or signal intermediate catch event. → Event-Based Gateway
Decisions based on data use a data-based exclusive gateway, not an event-based gateway. → Event-Based Gateway
Catching events use an unfilled icon and throwing events use a filled icon, consistently across the diagrams. → Intermediate Event
Boundary events are modeled only as catching events. → Intermediate Event
Timer and conditional events are modeled as catching events only. → Intermediate Event
Every place where parallel branches from an AND split come back together uses a parallel (AND) join, not an exclusive (XOR) join. → Lack of Synchronization
Tasks after a merge of parallel branches run only once per process instance. → Lack of Synchronization
Readability and traceability, including the choreography between pools, hold from the top level to the bottom level. → Levels of Process Modeling
Every throwing link event has a catching link event with exactly the same name. → Link Event
No link event is used to express business meaning; each one only replaces a sequence flow. → Link Event
Each process has a start event and end events that show its trigger and outcomes. → Process Analysis
Exclusive gateways are labeled as questions and their outgoing flows as answers. → Process Analysis
Actors are shown as pools and lanes at the top-level process or collaboration, not inside subprocesses. → Process Analysis and Modeling
The document states that event data for process analysis links to a case ID, activities and timestamps. → Process Mining
If event data is exchanged between tools, the document names the format used, such as XES (IEEE 1849). → Process Mining
Large process models are split into smaller subprocess models. → Process Model Complexity
Operational models use separate pools per participant rather than lanes. → Process Model Complexity
The document states that a model is deployed as a versioned process definition from which instances are started. → Process Model versus Process Instance
When EPC models are converted to BPMN, the result is reviewed for unnecessary intermediate events. → Process Notations Comparison (EPC, BPMN, UML Activity Diagram)
The document states whether EPC roles become BPMN lanes or remain roles. → Process Notations Comparison (EPC, BPMN, UML Activity Diagram)
Process models in the documentation have been checked for both deadlock and lack of synchronization. → Soundness of Process Models
Each parallel (AND) split in a process model has a parallel (AND) join that waits for all its branches. → Structured Process Modeling with Fragments
Exclusive joins are used only where paths are alternatives, since they do not wait for other paths. → Structured Process Modeling with Fragments
Where a process runs branches in parallel, a parallel gateway splits the flow and a parallel gateway joins it again. → Workflow Pattern
Each exclusive split has conditions on its outgoing flows, because the gateway takes the first flow whose condition is fulfilled. → Workflow Pattern
Every synchronous call (filled arrowhead) has a dashed reply arrow with an open arrowhead. → Common Sequence Diagram Mistake
Asynchronous messages have no reply arrow. → Common Sequence Diagram Mistake
Asynchronous messages are marked by an open arrowhead, not by a dashed line. → Common Sequence Diagram Mistake
Each region of a composite state has at most one initial state indicator. → Composite State
Fork transitions leaving a fork target states in different regions of an orthogonal state. → Composite State
Composite states with two or more regions are treated as orthogonal, with regions running concurrently. → Composite State
Each orthogonal composite state has at least two regions. → Concurrent Region
No transition connects states that lie in different regions. → Concurrent Region
Runtime scenarios are chosen for architectural relevance, and each uses a notation that fits it, such as a sequence diagram. → Matching Diagram Type to System Aspect
Runtime scenarios in the architecture document are shown with sequence diagrams, or another deliberately chosen scenario notation. → Message Types in Sequence Diagrams
The sequence diagrams make clear what each participating building block is responsible for. → Message Types in Sequence Diagrams
Entry and exit behaviors are attached to states, not duplicated on each transition. → State Entry, Exit and Do Behavior
A state with a do activity has an outgoing completion transition, or an event transition that interrupts it. → State Entry, Exit and Do Behavior
Each region has at most one initial vertex. → State Machine Diagram
Transition labels write the guard in square brackets and the effect after a slash. → State Machine Diagram
Completion transitions leaving the same state have mutually exclusive guards. → State Machine Diagram Modeling Mistakes
Transitions without a trigger are intentional completion transitions, and any guard on them is stated. → State Machine Transition
The document states that each event is processed completely before the next one is dispatched. → State and Event
Signal and call triggers match the receptions and operations of the owning class. → State and Event
Guards on transitions that compete for the same event do not overlap. → Transition Syntax (Trigger, Guard, Behavior)
Each transition that should skip entry and exit behavior is modeled as an internal transition, not an external one. → Transition Syntax (Trigger, Guard, Behavior)
Diagrams that show the static architecture are structure diagrams. → UML 2.5 Diagram Taxonomy
Runtime scenarios are described with a behavior notation such as an activity diagram, sequence diagram or state machine. → UML Behavioral Diagram
Where a sequence diagram is used, it shows the responsibility of each participating building block. → UML Behavioral Diagram
Swimlanes in an activity diagram of a runtime scenario correspond to building blocks. → UML Behavioral Diagram
Runtime scenarios in the runtime view are described with sequence diagrams (or another listed notation) so each building block’s responsibility is visible. → UML Sequence Diagram
Each participant in a sequence diagram has its own lifeline, and the diagram reads in time order. → UML Sequence Diagram
Each UML diagram is identifiable as a structure diagram or a behavior diagram. → Unified Modeling Language (UML)
Included use cases describe mandatory behavior; optional behavior is modeled with extend instead. → Use Case Goal Hierarchy with Include Relationships
Runtime scenarios use sequence diagrams (or another notation) that show each building block’s responsibility. → Why Use UML in Architecture Documentation
The control component is named, and its rule for choosing the next knowledge source is described. → Blackboard Pattern
The document explains how errors are handled in each filter, and whether retries are safe. → Pipe-and-Filter
The document states how each filter handles breaking errors and whether it is idempotent. → Pipes and Filters
The document states whether subscribers select messages by topic or by content filtering. → Publish-Subscribe Pattern
The document states how a tripped breaker recovers: a time-out, a health-check probe, or a manual reset. → Circuit Breaker
Technical error handling concepts are written for developers, briefly and by priority. → Exception Handling Tactic
The business has agreed which function is core when not all requirements can be met. → Graceful Degradation
The document states what happens when heartbeats stop: a fault correction component is notified. → Heartbeat
Delays between retries grow (incrementally or exponentially) and are spread across callers. → Retry