The relationship between a system's C&C views and its module views may be complex. The same code module might be executed by many of the elements of a C&C view. Conversely, a single component of a C&C view might execute code defined by many modules. Similarly, a C&C component might have many points of interaction with its environment, each defined by the same module interface. Figure 3.5 shows both a module view and a C&C view of the same system.
Figure 3.5. C&C and module views of the Capitalize System. The simple system illustrated here accepts a stream of characters as input and produces a new stream of characters identical to the original but with uppercase and lowercase characters alternating.
The module view represents a typical implementation that one might find in C under UNIX. In this view, the relation between modules is uses, as described in Chapter 2. A main module is used to start things off, invoking the facilities of four modulesTo-upper, To-lower, Split, and Mergethat do the main work. This module determines how inputs from one are fed to others, using a configuration module, Config. All the modules use a standard I/O library to carry out the communication. Note that from a code perspective, the worker modules do not directly invoke services of one anotherbut rather do so only via the I/O library.
In the C&C view, we have a system described in the pipe-and-filter style. Each of the components is a filter that transforms character streams. Pathways of communication between the components are explicit, indicating that during runtime, the pipe connectors will mediate communication of data streams among those components.
It should be clear even with this simple example that the two descriptions differ wildly in what they include and how they partition the system. Hence, there is no simple mapping between them. For example, some of the modules in the module view do not even appear in the C&C view. Conversely, the pipe connector does not appear in the module view, although one might argue that it is most closely associated with the module Stdio.
Although not illustrated in this example, the same code module might be mapped to several execution components: for example, if we used Merge twice. Also, the mapping of interfaces is not at all obvious. For example, the stream input/output interfaces on the filters have no clear mapping to the use of Stdio, which implements the communication interface of the code module.
In some situations, however, module and C&C views have a much closer correspondence.
Finally, even in these types of cases, some correspondences are worth noting. In particular, there is a natural relationship between the componentsSplit, To-upper, To-lower, and Mergeand the modules that carry out the bulk of the computation. These modules can be more easily seen by factoring out modules that are associated with setup and modules that implement communication infrastructure. Because a C&C view describes an executing system, no parts relate to setup. In the example, we have Main and Config. Communication infrastructure is represented as connectors in a C&C view. In the example, this is the module Stdio. After removing these modules, the ones left are those that have a clear mapping to the C&C view.
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