Notations for the Module Viewtype

1.4.1 Informal Notations

A number of notations can be used in a module view's primary presentation. One common informal notation uses bubbles or boxes to represent the modules, with different kinds of lines between them representing the relations. Nesting is used to depict aggregation, and arrows typically represent a depends-on relation. In Figure 1.1, for example, nesting is used to describe aggregation, and dots are used to indicate interfaces, similar to the UML "lollipop" notation introduced in Section 7.5.

A second common form of informal notation is a simple textual listing of the modules with description of the responsibilities. Various textual schemes can be used to represent the is-part-of relation, such as indentation, outline numbering, and parenthetical nesting. Other relations may be indicated by keywords. For example, the description of module A might include the line "Imports modules B, C," indicating a dependency between module A and modules B and C.

1.4.2 UML

Object-modeling notations, such as UML, provide a variety of constructs that can be used to represent various kinds of modules. Figure 1.2 shows some examples for modules using UML notation. Figure 1.3 shows how the relations native to the module viewtype are denoted using UML.

Figure 1.2. Examples of module notation in UML. A module may be represented as a class, a package, or a subsystem. The graphic on the bottom says that Class A realizes the interface defined by Interface C.


Figure 1.3. From left to right, these examples of relation notations in UML read as follows: module B is part of module A, module D depends on module C, and module F is a type of module E.


UML has a class construct, which is the object-oriented specialization of a module as described here. UML packages can be used when grouping of functionality is important, such as to represent layers and collections of classes. The UML subsystem construct can be used to support specification of interface and behavior.

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 © 2008-2020.
If you may any questions please contact us: