9.3 Choosing the Relevant Views
Recall that we introduced a set of structures and views in Chapter 2. What are the relevant views? This is where knowing your stakeholders and the uses they plan to make of the documentation will help you construct the documentation package they need. The many purposes that architecture can serve-as a mission statement for implementors, as the starting point for system understanding and asset recovery, as the blueprint for project planning, and so forth-are each represented by a stakeholder wanting and expecting to use the documentation to serve that purpose. Similarly, the quality attributes of most concern to you and the other stakeholders in the system's development will affect the choice of what views to document. For instance, a layered view will tell you about your system's portability. A deployment view will let you reason about your system's performance and reliability. And so it goes. These quality attributes are "spoken for" in the documentation by analysts (perhaps even the architect) who need to examine the architecture to make sure the quality attributes are provided.
In short, different views support different goals and uses. This is fundamentally why we do not advocate a particular view or a collection of views. The views you should document depend on the uses you expect to make of the documentation. Different views will highlight different system elements and/or relationships.
Table 9.2 shows a representative population of stakeholders and the kind of views they tend to find useful. You should use it to help you think about who your stakeholders are and what views might serve them well. Which views are available from which to choose? Chapter 2 listed a set of views, some of which are reflected in Table 9.2. Chapter 2 divided views into these three groups: module, component-and-connector (C&C), and allocation. This three-way categorization reflects the fact that architects need to think about their software in at least three ways at once:
How it is structured as a set of implementation units How it is structured as a set of elements that have runtime behavior and interactions How it relates to non-software structures in its environment
Table 9.2. Stakeholders and the Architecture Documentation They Might Find Most Useful
|
Project Manager
|
s
|
s
|
|
s
|
|
d
|
|
|
Member of Development Team
|
d
|
d
|
d
|
d
|
d
|
s
|
s
|
|
Testers and Integrators
|
|
d
|
d
|
|
s
|
s
|
s
|
|
Maintainers
|
d
|
d
|
d
|
d
|
d
|
s
|
s
|
|
Product Line Application Builder
|
|
d
|
s
|
o
|
s
|
s
|
s
|
|
Customer
|
|
|
|
|
s
|
o
|
|
|
End User
|
|
|
|
|
s
|
s
|
|
|
Analyst
|
d
|
d
|
s
|
d
|
s
|
d
|
|
|
Infrastructure Support
|
s
|
s
|
|
s
|
|
s
|
d
|
|
New Stakeholder
|
x
|
x
|
x
|
x
|
x
|
x
|
x
|
|
Current and Future Architect
|
d
|
d
|
d
|
d
|
d
|
d
|
s
|
Other views are available. A view simply represents a set of system elements and relationships among them, so whatever elements and relationships you deem useful to a segment of the stakeholder community constitute a valid view. Here is a simple three-step procedure for choosing the views for your project.
Produce a candidate view list.
Begin by building a stakeholder/view table, like Table 9.2, for your project. Your stakeholder list is likely to be different from the one in the table, but be as comprehensive as you can. For the columns, enumerate the views that apply to your system. Some views (such as decomposition or uses) apply to every system, while others (the layered view, most component-and-connector views such as client-server or shared data) only apply to systems designed that way. 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. Combine views.
The candidate view list from step 1 is likely to yield an impractically large number of views. To reduce the list to a manageable size, first look for views in the table that require only overview depth 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 be combined-that is, a view that gives information from two or more views at once. For small and medium projects, the implementation view is often easily overlaid with the module decomposition view. The module decomposition view also pairs well with uses or layered views. Finally, the deployment view usually combines well with whatever component-and-connector view shows the components that are allocated to hardware elements-the process view, for example. Prioritize.
After step 2 you should have an appropriate set of views to serve your stakeholder community. At this point you need to decide what to do first. How you decide depends on the details specific to your project, but remember that 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. Also, some stakeholders' interests supersede others. A project manager or the management of a company with which yours is partnering demands attention and information early and often.
|
