The C&C viewtype is used to reason about runtime system quality attributes, such as performance, reliability, and availability. In particular, a well-documented view allows architects to predict overall system properties, given estimates or measurements of properties of the individual elements and interactions. For example, to determine whether the overall system can meet its real-time scheduling requirements, you usually need to know the cycle time of each process in a process-oriented view. Similarly, knowing the reliability of individual elements and communication channels supports an architect when estimating or calculating overall system reliability. In some cases, this kind of reasoning is supported by formal, analytical models and tools. In others, it is achieved by judicious use of rules of thumb and past experience.
C&C views allow you to answer the following questions.
C&C views are not appropriate for representing design elements that do not have a runtime presence. For example, a good rule of thumb is that if it doesn't make sense to characterize the interface(s) of an element, it probably isn't a component. However, the inverse is not necessarily true: some things with interfaces are not components.
Data Flow and Control Flow Projections
Two views that have long been used to document software systemsfor so long, in fact, that we might consider them archaic todayare the data flow and control flow views. These views show how data and control, respectively, flow around a system during execution, and each view is useful for performing a particular kind of analysis. Understanding control flow, for instance, helps programmers track down the source of a bug.
Both of these are examples of projections of a C&C view. Each highlights certain aspects of a view in order to simplify discussion or to analyze specific properties of the view. A data flow projection can be derived by examining the connector protocols to determine in which direction data can flow between components. One can then project a data flow view from a C&C view by replacing connectors with one- or two-headed arrows indicating flow of data and by eliminating connectors that have no data component. A similar approach works for control flow. Of course, you need to be clear what you mean by control flow and how that relation is derived from knowledge about the connectors in a C&C view.
When attempting to extract a data flow or a control flow relation from a more general connector, you need to be aware of several pitfalls. For instance, consider the very simple but typical situation illustrated in Figure 3.4, which shows components C1 and C2, which interact via a procedure call connector, P. Assume that procedure P takes some arguments and returns a value. How would we project a data flow relation? In particular, which way should the arrow go? Because C1 passes data to C2 in the form of procedure parameters, you might argue that data flows from C1 to C2. But because C2 returns a value, perhaps the arrow should go the other way. Or should it go both ways?
Figure 3.4. A component-and-connector fragment showing that C1 calls C2. To turn this into a data flow or a control flow projection, which way should the respective arrows point?
The same confusions apply to control flow. C1 invokes C2, so you might argue that control flows from C1 to C2. But C1 must block when C2 is performing its invoked operation, suggesting that C2 controls C1 during that period of invocation. And, of course, when C2 is finished, it returns control to C1.
And this is one of the most simple forms of interaction! Most connectors are more sophisticated, perhaps involving multiple procedure calls, rules for handling exceptions and timeouts, and callbacks.
Two main conclusions can be drawn. First, when creating a data flow or a control flow projection, be explicit about the semantic criteria being used. Second, recognize that data flow and control flow projections are at best approximations to the connectors, which define the interactions between components.