1.1 Overview

Team-Fly     Documenting Software Architectures: Views and Beyond By Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, Judith Stafford Table of Contents Chapter 1.  The Module Viewtype 1.1 Overview 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 services�typically, procedures and functions�together 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. ADVICE 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: The decomposition style, used to focus on containment relationships among modules The uses style, to indicate functional dependency relationships among modules The generalization style, to indicate specialization relationships among modules The layered style, to indicate the allowed-to-use relation in a restricted fashion between modules Team-Fly     Top