In this chapter and the next, we look at ways to document the modular structures of a system's software. Such documentation enumerates the principal implementation units, or modules, of a system, together with the relationships among these units. We refer to these descriptions as module views. As we will see, these views can be used for each of the purposes outlined in the Prologue: education, communication among stakeholders, and the basis for analysis.
The concept of modules emerged in the 1960s and 1970s, based on the notion of software units with well-defined interfaces providing a set of servicestypically, procedures and functionstogether with implementations that either fully or partially hide their internal data structures and algorithms. More recently, these concepts have found widespread use in object-oriented programming languages and modeling notations, such as UML.
Today, the way in which a system's software is decomposed into manageable units remains one of the important forms of system structure. At a minimum, it determines how a system's source code is partitioned into separable parts, what kinds of assumptions each part can make about services provided by other parts, and how those parts are aggregated into larger ensembles. Choice of modularization often determines how changes to one part of a system might affect other parts and hence the ability of a system to support modifiability, portability, and reuse.
Plan for your documentation package to include at least one view in the module viewtype.
It is unlikely that the documentation of any software architecture can be complete without at least one view in the module viewtype.
We begin by considering the module viewtype in its most general form. In the next chapter, we identify four common styles:
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