Elements, Relations, and Properties of the Module Viewtype

Table of contents:

Table 1.1 summarizes the discussion in this section of the elements, relations, and properties of the module viewtype.

Table 1.1. Summary of the module viewtype

Elements The element of a module view is a module, which is an implementation unit of software that provides a coherent unit of functionality.
Relations Relations shown in a module view are a form of is part of, depends on, or is a.
  • The is-part-of relation defines a part/whole relationship between the submodule Athe part, or childand the aggregate module Bthe whole, or parent.
  • The depends-on relation defines a dependency relationship between A and B. Specific module styles elaborate what dependency is meant.
  • The is-a relation defines a generalization relationship between a more specific modulethe child Aand a more general modulethe parent B.
Properties of elements Properties of a module include the following:
  • Name, which may have to comply with namespace rules
  • Responsibilities of the module
  • Implementation information, such as the set of code units that implement the module
Properties of relations
  • The is-part-of relation may have an associated visibility property that defines whether a submodule is visible outside the aggregate module.
  • The depends-on relation can have constraints assigned to specify in more detail what the dependency between two modules is.
  • The is-a relation may have an implementation property, denoting that a more specific modulethe child Ainherits the implementation of the more general modulethe parent Bbut does not guarantee to support the parent's interface and thereby does not provide substitutability for the parent.
Topology The module viewtype has no inherent topological constraints.

1.2.1 Elements

System designers use the term module to refer a variety of software structures, including programming language units, such as Ada packages, Modula modules, Smalltalk or C++ classes, or simply general groupings of source code units. In this book, we adopt a broad definition.


A module is an implementation unit of software that provides a coherent unit of functionality.

We characterize a module by enumerating a set of responsibilities, which are foremost among a module's properties. This broad notion of "responsibilities" is meant to encompass the kinds of features that a unit of software might provide.

Modules can both be aggregated and decomposed. Different module views may identify a different set of modules and aggregate or decompose them based on different style criteria. For example, the layered style identifies modules and aggregates them based on an allowed-to-use relation, whereas the generalization view identifies and aggregates modules based on what they have in common.

1.2.2 Relations

The module viewtype has the following relations:

  • Is part of. The is-part-of relation defines a part/whole relationship between the submodule Athe partand the aggregate module Bthe whole. In its most general form, the is-part-of relation simply indicates aggregation, with little implied semantics. In general, for instance, one module might be included in many aggregates. This relation, however, has stronger forms. In Chapter 2, for example, this relation is refined to a decomposition relation in the module decomposition style.
  • Depends on. A depends-on B defines a dependency relation between A and B. The depends-on relation is typically used early in the design process when the precise form of the dependency has yet to be decided. Once the decision is made, depends-on usually is replaced by a more specific form of the relation. Later, we look at two in particular: uses and allowed-to-use, in the module uses and layered styles, respectively. Other, more specific examples of the depends-on relation include shares-data-with and calls. A call dependency may be refined to sends-data-to, transfers-control-to, imposes-ordering-on, and so forth.
  • Is a. The is-a relation defines a generalization relationship between a more specific modulethe child Aand a more general modulethe parent B. The child is able to be used in contexts in which the parent is used. Later, we look at its use in more detail in the module generalization style. Object-oriented inheritance is a special case of the is-a relation.

1.2.3 Properties

As we will see in Section 10.2, properties are documented as part of the supporting documentation for a view. The list of properties pertinent to a set of modules will depend on many things but is likely to include the following:

  • Name. A module's name is, of course, the primary means to refer to it. A module's name often suggests something about its role in the system: a module called "account_mgr," for instance, probably has little to do with numeric simulations of chemical reactions. In addition, a module's name may reflect its position in a decomposition hierarchy; the name A.B.C.D, for example, refers to a module D that is a submodule of a module C, itself a submodule of B, and so on.
  • Responsibilities. The responsibility property for a module is a way to identify its role in the overall system and establishes an identity for it beyond the name. Whereas a module's name may suggest its role, a statement of responsibility establishes it with much more certainty. Responsibilities should be described in sufficient detail to make clear to the reader what each module does.
  • Visibility of interface(s). An interface document for the module establishes with precision its role in the system by specifying exactly what it may be called on to do. A module may have zero, one, or several interfaces.

    In a view documenting an is-part-of relation, some of the interfaces of the submodules exist for internal purposes only; that is, the interfaces are used only by the submodules within the enclosing parent module. These interfaces are never visible outside that context and therefore do not have a direct relationship to the parent interfaces.

    Different strategies can be used for those interfaces that have a direct relationship to the parent interfaces. The strategy shown in Figure 1.1(a) is encapsulation in order to hide the interfaces of the submodules. The parent module provides its own interfaces and maps all requests, using the capabilities provided by the submodules. However, the facilities of the enclosed modules are not available outside the parent.

    Figure 1.1. (a) Module C provides its own interface, hiding the interfaces of modules A and B; (b) Module C exposes a subset of the interfaces of modules A and B as its interface.


    Alternatively, the interfaces of an aggregate module can be a subset of the interfaces of the aggregate. That is, an enclosing module simply aggregates a set of modules and selectively exposes some of their responsibilities. Layers and subsystems are often defined in this way. For example, if module C is an aggregate of modules A and B, C's implicit interface will be a subset of the interfaces of modules A and B (see Figure 1.1(b)).

  • Implementation information. Because modules are units of implementation, recording information related to their implementation from the point of view of managing their development and building the system that contains them is useful. Although this information is not, strictly speaking, architectural, it is convenient to record it in the architecture documentation where the module is defined. Implementation information might include

    - Mapping to code units. This identifies the files that constitute the implementation of a module. For example, a module ALPHA, if implemented in C, might have several files that constitute its implementation: ALPHA.c, ALPHA.h, ALPHA.oif precompiled versions are maintainedand perhaps ALPHA_t.h to define any data types provided by ALPHA.

    - Test information. The module's test plan, test cases, test scaffolding, test data, and test history are important to store.

    - Management information. A manager may need the location of a module's predicted completion schedule and budget.

    - Implementation constraints. In many cases, the architect will have a certain implementation strategy in mind for a module or may know of constraints that the implementation must follow. This information is private to the module and hence will not appear, for example, in the module's interface.

Styles in the module viewtype may have properties of their own in addition to these. Also, you may find other properties useful that are not listed.



We have used the term substitutability to explain the meaning of the generalization relationship between two modules. We have relied on an intuitive notion of being able to use one module in place of another: In principle, users of the substituted module should not be able to observe any differences in behavior from the original module.

But this informal notion of substitutability begs the question of what we mean by "differences in behavior." This phrase might be interpreted in many ways. For example, if B is substitutable for A, we might mean any of the following, among others.

  • B may be used in the same situations as A.
  • B may be used in the same situations as and produces the same results as A.
  • B may be used in the same situations as, produces the same results as, and has the same performance characteristics as A.

In the preceding progression, the definition of substitutability becomes stronger at each step, moving from syntactic properties to semantic properties to quality attributes.

Which definition is the "right" one? Any of these might be reasonable, but you need to be clear which you mean. The implications for documentation are that when you use a style in which generalization is one of the relations, you should state what kind of substitutability is intended.

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