Skip to content
Software Architecture Guide

View Creation Method

Explanation

Section titled “Explanation”

A view is a diagram or description of a system made for a specific reader. When you create one, three details should travel with it:

  • the notation, meaning the drawing language you used;
  • the target audience, meaning who the view is for;
  • the purpose, meaning what the view should help that audience do.

Stating these details lets readers judge whether the view fits their needs.

Two views from the arc42 template (see arc42 Architecture Documentation Template) show how purpose shapes content:

  • Building block view. It documents the static decomposition of the system, meaning how it is split into parts. It is mandatory in every architecture documentation.
  • Runtime view. It shows concrete behavior and the interactions between building blocks. You pick its scenarios by how relevant they are to the architecture.

The two views answer different questions. One shows what the parts are. The other shows what they do together.

Example

Section titled “Example”

A team draws a diagram of an online shop. Under the diagram they add a short note: “Notation: simple boxes and arrows. Audience: new developers. Purpose: show the main parts of the shop.” A second diagram shows how those parts talk to each other while a customer places an order.

Trade-offs

Section titled “Trade-offs”

The verified facts here cover only the labeling of diagrams and two arc42 views. They do not describe the full process of creating and refining a view.

Checks

Section titled “Checks”
  • Each diagram states its notation, its target audience and its purpose.
  • The documentation contains a building block view showing the static decomposition of the system.
  • The runtime view covers scenarios chosen for their architectural relevance.
Section titled “Related”

Sources

Section titled “Sources”