Skip to content
Software Architecture Guide

Architecture Viewpoint

Explanation

Section titled “Explanation”

A viewpoint is a set of patterns, templates and conventions. You use it to build one type of architecture view. A view is a representation of the system (see Architecture View).

A viewpoint also identifies the stakeholders whose concerns it reflects. Stakeholders are the people with an interest in the system. Concerns are what they care about (see Stakeholder and Concern).

Each viewpoint produces a single view. So the viewpoint is the recipe, and the view is the result.

A published catalog. One well-known catalog has six core viewpoints for information systems architecture:

  • Functional
  • Information
  • Concurrency
  • Development
  • Deployment
  • Operational

The same catalog adds a Context viewpoint.

Viewpoints and perspectives. A perspective is a different thing. It is a set of activities, tactics and guidelines. Its goal is to make sure the system shows required quality properties. You never use a perspective alone. You apply it to a view. That is why perspectives cut across views, while a viewpoint produces only one view (see Architectural Perspective).

Example

Section titled “Example”

A team documents an online shop. One viewpoint guides a deployment view, which shows where the software runs. Another guides a functional view, which shows what the system does. Each viewpoint tells the team what to draw and which stakeholders it serves. Later, the team applies a security perspective to both views. It uses the perspective’s guidelines to check that each view shows what security needs.

Checks

Section titled “Checks”
  • Each view in the document is built from a named viewpoint.
  • Each viewpoint names the stakeholders whose concerns it reflects.
  • Quality perspectives are applied to views, not treated as views of their own.
Section titled “Related”

Sources

Section titled “Sources”