Skip to content
Software Architecture Guide

Goal Hierarchy to Component Mapping

Explanation

Section titled “Explanation”

A use case describes how a user reaches a goal with the help of a system. You can label each use case with a goal level. The label tells readers how much detail to expect. The preferred level is the user goal, informally called sea level.

A use case also has a subject. The subject can be a system, a sub-system or a single component. So the scope of a use case can range from a black-box view of a whole organization down to one component.

This range is the basis for the mapping. A broad goal fits a large building block. A narrow goal fits a small one. Each component then receives the goals of matching size as its responsibilities. The article Responsibility Allocation covers how duties are assigned.

The arc42 building block view has a similar shape. It is a hierarchy of white boxes. A white box shows the inner parts of a block. The hierarchy starts with the whole system at level 1 and goes deeper from there. Each important black box, which hides its inner parts, should have its responsibility described. Goals from the use cases can supply that text.

When you group similar business functions into one block, arc42 says cohesion should be the primary driver. Cohesion means the parts of a block belong together. See Coupling and Cohesion.

Functional decomposition is one way to shape the top level. One arc42 example bases its level-1 structure on it. Functional decomposition means splitting a system by the functions it performs.

Example

Section titled “Example”

An online shop has the broad goal “Run the shop”. The shop owner has a user goal, “Fulfill an order”. That goal needs a smaller step, “Calculate shipping cost”.

The architect assigns the broad goal to the system as a whole. The user goal goes to a block that groups order-related functions. The small step goes to a small component inside that block. Each block’s description in the building block view then names the goals it is responsible for.

Trade-offs

Section titled “Trade-offs”

Grouping by function is only one way to form blocks. arc42 names cohesion as the primary driver, so check each functional grouping against it. The arc42 example above also relies on a second concept besides functional decomposition. A goal-based mapping alone may not cover every concern.

Goals of different size are assigned to building blocks of matching size.

Diagram source 
flowchart TD
  A[Broad goal] --> S[Whole system]
  B[User goal] --> P[Package of similar business functions]
  C[Small supporting step] --> K[Small component]
  S --> P
  P --> K

Checks

Section titled “Checks”
  • Use cases are annotated with a goal level so readers know the expected level of detail.
  • Every important black box in the building block view has a described responsibility.
  • Blocks that group similar business functions are formed with cohesion as the primary driver.
  • The scope of each use case (system, sub-system or component) is stated and fits the building block it is assigned to.
Section titled “Related”

Sources

Section titled “Sources”