Relation to Other Viewtypes

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.

• In one such situation, each module has a single runtime component associated with it, and the connectors are restricted to calls procedure connectors. Ignoring shared libraries, this would typically be the case with an Ada program, with each package representing a runtime entity and interactions occurring via procedure calls.
• In a second case, each class in the architectural model of an object-oriented system has a single instance at runtime, and one portrays the C&C view in terms of a peer-to-peer style; that is, the connectors represent method/procedure call interactions. A variation used for performance reasons is to mark select classes as active. Each active class and its supporting classes become a single runtime entity.
• In a third case, "component-based systems" are composed out of executable modulesobject codethat provide one or more service-oriented interfaces that can be used by other modules. Component technologies include component object model (COM), CORBA, and JavaBeans. Although the composition of such modules is in general not known until runtime, many component-based systems have a known configuration that can be represented in similar ways in both a module view and a C&C view. Here again, however, the connector types are restricted to call procedure connectors and, in some cases, publish-subscribe.

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.