Table of contents:

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:

  • 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

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

Advanced Concepts

Documenting Software Interfaces

Documenting Behavior

Choosing the Views

Building the Documentation Package

Other Views and Beyond

Rationale, Background, and Design Constraints


Documenting Software Architectures(c) Views and Beyond
Documenting Software Architectures: Views and Beyond
ISBN: 0201703726
EAN: 2147483647
Year: 2005
Pages: 152

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net