C&C styles specialize the C&C viewtype by introducing a specific set of component-and-connector types and by specifying rules about how elements of those types can be combined. Additionally, given that C&C views capture runtime aspects of a system, a C&C style is typically also associated with a pattern of interaction that prescribes how computation, data, and control flow through systems.
Any particular component or connector may be documented in multiple C&C views, because it may interact with other components or connectors in several ways. For example, a component may be a server in a client-server system. The same component may also act as a respository for data. Thus, assuming that both client-server and shared-data styles are important to understanding the system, views in both styles will include the same component, showing different patterns of interaction.
The component-and-connector viewtype is specialized by numerous styles. The style chosen to represent a C&C view of the system usually depends on both the nature of the runtime structures in the system and the intended use of the representation. For example, if the view documents early, coarse-grained design decisions that will be refined later, it will probably include abstract connector types that will need to be refined later. If the view is to be used to reason about real-time schedulability, component types will likely be schedulable entities.
Many C&C styles exist, and we discuss only a few of them in this chapter. We discuss sixpipe-and-filter, shared-data, publish-subscribe, client-server, peer-to-peer, and communicating-processesthat apply to a wide variety of systems and provide enough semantic richness to illustrate documentation principles.
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