What the Module Viewtype Is For and What It s Not For
Expect to use the module viewtype for
- Construction. A module view can provide a blueprint for the source code. In this case, the modules and physical structures, such as source code files and directories, often have a close mapping.
- Analysis. Two important analysis techniques are requirements traceability and impact analysis. Because modules partition the system, it should be possible to determine how the functional requirements of a system are supported by module responsibilities. Often, a high-level requirement will be met by a sequence of invocations. Documenting such sequences shows how the system is meeting its requirements and identifies any missing requirements. Impact analysis, by contrast, helps to predict the effect of modifying the system. Context diagrams that describe the module's relationships to other modules or to the outside world build a good basis for impact analysis (see Section 6.2). Modules are affected by a problem report or a change request. Impact analysis requires a certain degree of design completeness and integrity of the module description. In particular, dependency information has to be available and correct in order to create good results.
- Communication. A module view can be used to explain the system's functionality to someone not familiar with the system. The various levels of granularity of the module decomposition provide a top-down presentation of the system's responsibilities and therefore can guide the learning process.
On the other hand, it is difficult to use the module viewtype to make inferences about runtime behavior, because this viewtype is a partition of the functions of the software. Thus, a module view is not typically used for analysis of performance, reliability, or many other runtime qualities. For those, we typically rely on component-and-connector and allocation views.