This section presents a procedure for choosing the views, and applies that procedure to two real-world systems.
Here is a simple three-step procedure for choosing the views for your project.
Enumerate the stakeholders for your project's software architecture documentation down the rows. Your stakeholder list is likely to be different from the one in Table 9.1; however, be as comprehensive as you can. For the columns, enumerate the views that apply to your system. As discussed in the Prologue, some views (such as decomposition, uses, and work assignment) apply to every system, while others (C&C views, the layered view) only apply to systems designed according to the corresponding styles.
Once you have the rows and columns defined, fill in each cell to describe how much information the stakeholder requires from the view: none, overview only, moderate detail, or high detail.
The candidate view list consists of those views for which some stakeholder has a vested interest.
First, look for views in the table that require only overview, or that serve very few stakeholders. See if the stakeholders could be equally well served by another view having a stronger constituency.
Next, look for views that are good candidates to become combined views. For small and medium projects, the work assignment and implementation views are often easily overlaid with the module decomposition view. The decomposition view also pairs well with the layered and uses views. Where different parts of a system exhibit different component-and-connector styles, the corresponding views might be easily overlaid. Finally, the deployment view usually combines well with whatever C&C view shows the components that are allocated to hardware elementsthe communicating-processes view, for example.
- You don't have to complete one view before starting another. People can make progress with overview-level information, so a breadth-first approach is often the best.
- Some stakeholders' interests supersede others. A project manager, or the management of a company with which yours is partnering, often demand attention and information early and often.
- If your architecture has not yet been validated or evaluated for fitness of purpose, then documentation to support that activity merits high priority.
- Resist the temptation to relegate rationale documentation to the "do when we have time" category, because rationale is best captured when fresh.
Software Architectures and Documentation
Part I. Software Architecture Viewtypes and Styles
The Module Viewtype
Styles of the Module Viewtype
The Component-and-Connector Viewtype
Styles of the Component-and-Connector Viewtype
The Allocation Viewtype and Styles
Part II. Software Architecture Documentation in Practice
Documenting Software Interfaces
Choosing the Views
Building the Documentation Package
Other Views and Beyond
Rationale, Background, and Design Constraints