Two Examples
This section provides two examples of applying the procedure in the previous section to select a set of views for a project.
9.3.1 A Small Project: A-7E
The U.S. Navy's A-7E avionics program, used as a source for some of the documentation examples in this book, was one of the first software engineering projects that paid special attention to engineering and documenting its architecture as a set of related but separate views. It was by most standards a small project, with staff size of ten or less for most of its duration. Here are A-7E architecture views under the three-step method outlined above.
Step 1: Produce a Candidate View List
Stakeholders include the current and future architects, the project manager, members of the development team, testers and integraters, and maintainers. The architecture was designed to deliver three primary qualities: modifiability, real-time performance, and the ability to be fielded in incremental subsets. Hence, it is important to analyze the architecture for these qualities, and so by extension, the analysts become stakeholders. The agency responsible for funding the project was also a stakeholder; their interest was in knowing how the architecture leads to a system more maintainable than other avionics programs of the same generation.
Applicable views in the module viewtype include the decomposition, uses, and layered views. Generalization is not employed in the A-7E architecture. The system is structured as a set of cooperating sequential processes, and so in the C&C realm the communicating-processes view applies. The system also has a central data store called a Data Banker; its function is to isolate producers and consumers of data from each other to enhance modifiability. Therefore, the shared-data C&C view also applies. In the allocation viewtype, the work assignment, implementation, and deployment view, all apply as well.
Table 9.2 shows the stakeholders for the A-7E architecture documentation and the views useful to each. At this point, the candidate view list contains eight views.
| Module Views | C&C Views | Allocation Views | ||||||
|---|---|---|---|---|---|---|---|---|
| Stakeholder | Decom-position | Uses | Layered | Communicating-processes | Shared-data | Deployment | Implementation | Work Assignment |
| Current and future architect | d | d | d | d | d | d | s | s |
| Project manager | s | s | s | d | o | d | ||
| Member of development team | d | d | d | d | d | s | s | d |
| Testers and integraters | d | s | d | |||||
| Maintainer | d | d | d | d | d | s | s | s |
| Analyst for performance | d | d | d | d | s | d | ||
| Analyst for modifiability | d | d | d | s | s | d | o | o |
| Analyst for "subsettability" | d | d | d | s | s | d | o | |
| Funding agency | o | o | o | |||||
| Key: d = detailed information, s = some details, o = overview information | ||||||||
Step 2: Combine Views
The A-7E's hardware environment features a uniprocessor, and so the deployment view can be dispensed with. By adopting modules (as defined in the module decomposition view) as the basic unit of work assignment and development file structure, the work assignment and implementation views can easily be combined with the decomposition view. These simple decisions quickly eliminate three of the eight views from the candidate list.
Consultations with stakeholders revealed that the shared-data view was unnecessary. Performance analysts can build performance and schedulability models using the communicating-processes view. Developers, testers, integraters, and maintainers can do their jobs with the module decomposition view[1] (which tells them what the systems' parts were) and the layered view (which tells them what those parts are allowed to use).
[1] The module decomposition view was able to partially supplant a C&C view in this case because in the A-7E architecture there is a straightforward, almost one-to-one mapping between modules and components.
After this step, four views remain: decomposition, uses, layered, and communicating-processes.
Step 3: Prioritize
Most of the stakeholders are served by the module decomposition view, and so that was chosen as the first undertaking. Because of the tight correspondence between modules and work assignments in this project, the creation of a module is also the commissioning of a work assignment. Before that work assignment can be carried out, the programmers need to know what other software they are allowed to use. Hence, the module decomposition and layered views proceeded hand in hand through successively finer levels of detail.
Communicating-processes views are created once the modules are decomposed to a sufficiently fine grain so that the communication and synchronization needs can be decided and then documented.
The uses view has the lowest priority, targeted for documentation only during the module implementation phase. The allowed-to-use information of the layered view constrains programmers but still leaves them with considerable latitude. As a trivial example, a programmer writing a "double(x)" routine is allowed to use multiplication (2x) or addition (x+x) to implement that function. The uses view reflects the programmers' actual choices. Since the uses view is not employed until it is time to begin fielding subsets, it is the last A-7E view to emerge.
9.3.2 A Large Project: ECS
ECS is a system for capturing, storing, distributing, processing, and making available extremely high volumes of data from a constellation of earth-observing satellites. By any measure, ECS is a very large project. Many hundreds of people are involved in its design, development, deployment, sustainment, and use. Here is how the three-step view selection approach might have turned out, had it been applied to the ECS software architecture.
Step 1: Produce a Candidate View List
Stakeholders for the ECS architecture include the usual suspects: the current and future architect, developers, testers and integraters, and maintainers. But the size and complexity of ECS, plus the fact that it is a government system whose development is assigned to a team of contractors, add complicating factors. In this case, there is not one project manager, but several: one for the government, and one for each of the contractors. Each contractor organization has its own assigned part of the system to develop, and hence, its own team of developers and testers. ECS relies heavily on COTS components so the people responsible for selecting COTS candidate components, qualifying them, selecting the winners, and integrating them into the system play a major role. We'll call these stakeholders COTS engineers.
The important quality attributes for ECS begin with performance. Data must be ingested into the system to keep up with the rate at which it floods in from the satellites. Processing the raw data into more sophisticated and complex "data products" must also be done every day to stay ahead of the flow. Finally, requests from the science community for data and data analysis must be handled in a timely fashion. Data integrity, security, and availability round out the important list of quality at-tributes and make the analysts concerned with these qualities important architectural stakeholders.
ECS is a highly visible and highly funded project which attracts oversight attention. The funding authorities require at least overview insight into the architecture to make sure the money over which they have control is being spent wisely. Finally, the science community using ECS to measure and predict global climate change also require insight into how the system works, so they can better set their expectations about its capabilities.
At least five of the component-and-connector views discussed in Chapter 4 and all four of the module views of Chapter 2 apply to ECS. It is primarily a shared-data system. Its components interact in both client-server and peer-to-peer fashion. Many of those components are communicating processes. And while the system is not actually built using pipes and filters, the pipe-and-filter style is a very useful paradigm to provide an overview to some of the stakeholders. (Information more detailed than the overview will be in a different view, becoming an implementation refinement of the pipe-and-filter view.)
In addition to the five C&C views, all four of the module views discussed in Chapter 2 apply to ECS, as do all three of the allocation views discussed in Chapter 5.
Table 9.3 shows the stakeholders for the ECS architecture documentation and the views useful to each. At this point, the candidate view list contains 12 views.
Step 2: Combine Views
Because of the large size of this project and the number of different development organizations involved, the work assignment view (normally a good candidate for combination) would likely be kept separate. Similarly, because a large number of stakeholders interested in the module decomposition would not be interested in how the modules were allocated to files in the development environment, the implementation view would also be kept separate.
Three of the C&C views would prove good candidates for combination. Augmenting the shared-data view with other components and connectors that interact in client-server or peer-to-peer fashion allows those three views to become one. The pipe-and-filter view can be discarded; the shared-data view plus some key behavioral traces showing the data pipeline from satellite to scientist would provide the same intuitive overview to the less detail-oriented stakeholders.
Finally, recording uses information as a property of the decomposition view yields a combination of the decomposition and uses views.
After this step, eight views remain:
- In the module viewtype, decomposition, layered, and generalization
- In the C&C viewtype, shared-data and communicating-processes
- In the allocation viewtype, deployment, implementation, and work assignment.
Step 3: Prioritize
To let the project begin to make progress requires putting contracts in place, which in turn requires coarse-grained decomposition. Thus, the higher levels of the decomposition and work assignment views would likely receive the highest priority.
| Stakeholder | Module Views | C&C Views | Allocation Views | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Decomposition | Generalization | Uses | Layered | Pipe-and-filter | Shared-data | Client-server | Peer-to peer | Communicating processes | Deployment | Implementation | Work Assignment | |
| Current and future architect | d | d | d | d | s | d | d | d | d | d | s | s |
| Government project manager | d | o | o | s | o | s | o | o | o | s | d | |
| Contractors' project managers | s | o | s | s | o | s | s | s | o | d | s | d |
| Member of development team | d | d | d | d | o | d | d | d | d | s | s | d |
| Testers and integraters | s | s | d | s | o | d | d | d | s | s | d | |
| Maintainer | d | d | d | d | o | d | d | d | d | s | s | s |
| COTS engineers | d | s | d | d | d | d | s | d | d | |||
| Analyst for performance | d | s | d | s | o | d | d | d | d | d | ||
| Analyst for data integrity | s | s | s | d | o | d | d | d | d | d | ||
| Analyst for security | d | s | d | d | o | s | d | d | d | d | o | o |
| Analyst for availability | d | s | d | d | s | s | d | o | ||||
| Funding agency | o | o | o | o | ||||||||
| Users in science community | o | o | o | o | ||||||||
| Key:d =detailed information,s =some details,o =overview information | ||||||||||||
In ECS, the layering in the architecture is very coarse-grained and can be quickly described. Similarly, generalization occurs largely in only one of the three major subsystems, is also coarse-grained, and can also be quickly described. Hence, these two views might be given next priority because they can be quickly dispatched.
The shared-data, communicating-processes, and deployment views would follow, nailing down details of runtime interaction only hinted at by the module-based views. During this phase, the architect can see if the communicating processes map straightforwardly to components in the shared-data view, in which case those two views could also be combined.
Finally, because the implementation view can be relegated to each contractor's own internal development effort, it would receive the lowest priority from the point of view of the overall system.
The result is four "full-fledged" views (decomposition, work assignment, shared-data/communicating-processes, and deployment), and three minor ones that stop at high levels or can be deferred.