What the C&C Viewtype Is For and What Its Not For

What the C C Viewtype Is For and What It s Not For

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.

  • What are the system's principal executing components, and how do they interact?
  • What are the major shared-data stores?
  • Which parts of the system are replicated, and how many times?
  • How does data progress through a system as it executes?
  • What protocols of interaction are used by communicating entities?
  • What parts of the system run in parallel?
  • How can the system's structure change as it executes?

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.

PERSPECTIVES

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?

graphics/03fig04.gif

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.

D.G.

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

References



Documenting Software Architectures(c) Views and Beyond
Documenting Software Architectures: Views and Beyond
ISBN: 0201703726
EAN: 2147483647
Year: 2005
Pages: 152

Similar book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net