The communicating-processes style is characterized by the interaction of concurrently executing components through various connector mechanisms. Examples of the connector mechanisms are synchronization, message passing, data exchange, start, stop, and so forth.
Communicating processes are common in most large systems and necessary in all distributed systems. Thus, for most systems, the communicating-processes style is an appropriate one to use to understand any behavior associated with concurrency.
4.6.2 Elements, Relations, and Properties
Table 4.6 summarizes the discussion of the characteristics of the communicating-processes style. This style represents a system as a set of concurrently executing units together with their interactions. A concurrent unit is an abstraction of more concrete software platform elements, such as tasks, processes, and threads. Connectors enable data exchange between concurrent units and control of concurrent units, such as start, stop, synchronization, and so on.
|The attachment relation, as defined in the C&C viewtype
|Concurrently executing components that interact via the specific connector mechanisms
|Properties of elements
4.6.3 What the Communicating-Processes Style Is For and What It's Not For
This style is used to understand which portions of the system could operate in parallel, the bundling of components into processes, and the threads of control within the system. Therefore, this style can be used for analyzing performance and reliability. This style is also useful in design stages, when decisions are being made about which components should be assigned to which processes.
The essence of this style is that elements operate relatively independently, and concurrency is an important part of understanding how the system works. However, just because your system has processes doesn't mean that the communicating-processes style is for you. Maybe you want to instead use another style and overlay it with process boundaries later.
4.6.4 Relation to Other Styles
In practice, this style is rarely used in its pure form but instead is usually combined with another style. For example, if you want to show the concurrency aspects of a client-server system, you may want to explicitly mark the concurrent units that are servers and those that are clients. Additionally, this style is often specialized to provide watchdog information, such as a process that monitors the execution time of other processes or resource synchronization.
It is often of interest to know which communicating processes reside on which processors. The deployment style is used to allocate processes to hardware elements.
4.6.5 Examples of the Communicating-Processes Style
Figure 4.5, taken from Appendix A, demonstrates one use of communicating processes within the ECS system.
Figure 4.5. Part of the communicating-processes view from the ECS system. The Ingest subsystem deals with the initial reception of all data received at a facility and triggers subsequent archiving and processing of the data. The subsystem makes data ingest schedules available to users and programs and reports deviations from the schedules as exceptions so they can be handled through intervention by operations or science users.
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