In the deployment style, elements of a C&C styleusually the communicating-processes styleare allocated to execution platforms. The constraints for any particular allocation are the requirements expressed by the software elements and how those requirements are met by characteristics of the relevant hardware element(s).
5.3.2 Elements, Relations, and Properties
Table 5.2 summarizes the discussion of the characteristics of the deployment style. Environmental elements in the deployment style are entities that correspond to physical units that store, transmit, or compute data. Physical units include processing nodes (CPUs), communication channels, memory stores, and data stores.
|Properties of elements||
|Properties of relations||Allocated-to relation: either static or dynamic, as discussed in Section 6.4|
The software elements in this style are usually derived from elements in a C&C view corresponding to processes. When represented in the deployment style, the software elements are assumed to run on a computer with operating system support. Therefore, software elements in this style are likely operating system processes.
The typical relation depicted in the deployment style is a special allocated-to form that shows on which physical units the software elements reside. The relation can be dynamic; that is, the allocation can change as the system executes. In this case, additional relations, such as the following, may be shown.
It is also possible for the allocation to change over time as a result of manual reconfiguration. In this case, the possibilities represent variation points.
The important properties of the elements, both software and physical, of the deployment style are those that affect the allocation of the software to the physical elements. How a physical element satisfies a software element requirement is determined by the properties of both. For example, if a software element FOO requires a minumum storage capacity, any environment element that has at least that capacity is a candidate for a successful allocation of FOO.
Moreover, the types of analyses performed based on a deployment style also detemine the particular properties the elements must possess. For example, if a memory capacity analysis is needed, the necessary properties of the software elements must describe memory consumption aspects, and the relevant environment element properties must depict memory capacities of the various hardware entities.
Following are some environmental element properties relevant to physical units.
Properties that are relevant to software elements include
The following property is relevant to the allocation:
5.3.3 What the Deployment Style Is For and What It's Not For
The deployment style is used for analyses of performance, reliability, and security. It is also used as a portion of cost estimation.
Performance is tuned by changing the allocation of software to hardware. Optimal or improved allocation decisions are those that eliminate bottlenecks on processors or that distribute work more evenly so that processor utilization is roughly even across the system. Often performance improvement is achieved by colocating deployment units that have frequent and/or high-bandwidth communications with one another. The volume and the frequency of communication among deployable units on different processing elements, which takes place along the communication channels among those elements, is the focus for much of the performance engineering of a system.
Reliability is directly affected by the system's behavior in the face of degraded or failed processing elements or communication channels. If it is assumed that a processor or a channel will fail without warning, copies of deployable units are placed on separate processors. If it is assumed that a warning will precede a failure, deployable units can be migrated at runtime when a failure is imminent. Typical users of this structure are performance engineers, who use this structure to design and to predict system performance; testers, who use this structure to understand runtime dependencies; and integraters, who use this view to plan integration and integration testing.
 If every processing element has enough memory to host a copy of every deployable unit, runtime migration need not occur. When a failure occurs, a different copy of the no-longer-available deployable unit becomes active, but no migration of code occurs.
The cost of deploying a system depends on the hardware elements of that system. Therefore, the deployment view is used to display the hardware elements of a particular configuration and their purposes. The purposes are given by the processes deployed on the various hardware elements.
Modern software architectures seek to make allocation decisions transparent and thus changeable. Therefore, for example, interprocess communication should be coded in exactly the same fashion whether the two processes reside on the same or on different processors. So the deployment style may contain information that implementers should not be allowed to assume or to use. When allocation decisions are dynamic, the migrates-to relation in its various forms must be used to indicate the dynamism.
Additionally, allocations can capture enterprise deployments, whereby the allocation of subsystems is dependent on an organization in the enterprise. Each organization can use its own policies and standards to control the deployment.
An incorrect use of a deployment style is to treat it as the software architecture of a system. A single view of this style, in isolation, is not a complete description of a software architecture. Although this observation is true of every style, no matter what its viewtype, allocation styles seem especially susceptible. When asked for their software architecture, people sometimes present an impressive diagram that shows a network of computers with all their properties and protocols used and the software components running on those computers. Although these diagrams fulfill an important role by helping to organize the work and to understand the software, they do not fully represent the software architecture.
Design errors involving the deployment style usually center on forcing other units of software to conform to the deployable units allocated to a single processor. For example, it is usually not the case that a processor's resident software should correspond to a module or a layer; these are typically spread among several processors.
5.3.4 Notation for the Deployment Style
Informal graphical notations contain boxes, circles, lines, arrows, and so on. Boxes and circles are used to represent the software and environmental elements and the lines and arrows are used to represent the allocated-to relation. In many cases, stylized symbols or icons are used to represent the environmental elements. The symbols are frequently pictures of the hardware devices in question. Additionally, shading, color, border types, and fill patterns are often used to indicate the type of element. Software elements can be listed inside or next to the hardware to which they're allocated. If the deployment structure is simple, a table that lists the software units and the hardware element on which each executes may be adequate. Figure 5.2 shows an example of informal notation for the deployment style.
Figure 5.2. Example view of the deployment style in an informal notation. This example uses distinctive symbols for different types of hardware. The connecting lines are physical communication channels that allow the processes to communicate with one another. The line between the DNS Server and the FTP Server also has a propertyTrustedassigned with it. The allocation of the processes is done by writing their names below the symbol. Note that the "processes" mentioned, such as FTP and Office Suite, are not processes in the operating system sense but rather are applications or components as defined by the C&C viewtype.
Figure 5.3 shows an example of UML notation for the deployment style.
Figure 5.3. A deployment view in UML, showing a client-server system in which the server has a scheduler that maintains a meeting database and the client has planner software (Rumbaugh, Jacobson, and Booch 1999, p. 253)
In UML, a deployment diagram is a graph of nodes connected by communication associations. Nodes correspond to processing elements, usually having a memory and a processing capability. Nodes may contain component instances, indicating that the component resides on the node. Components can be connected to each other by dependency arrows. In a UML deployment diagram, components may contain objects, meaning that the objects are part of those components. Migration of components from node to node (or objects from component to component) is shown by the <> stereotype of dependency. A node is shown using a symbol that looks like a 3-D box, with an optional name inside. Nodes are connected by associations that stand for communication paths. The precise nature of the communication path can be indicated by a stereotype on the association.
5.3.5 Relation to Other Styles
Clearly, the deployment style is related to the C&C style(s) that provided the software elements that are allocated to the physical environment.
5.3.6 Examples of the Deployment Style
Figure 5.4, taken from Appendix A, shows part of the deployment view of the ECS system.
Figure 5.4. Primary presentation from the ECS deployment view. The elements are subsystems, host computers, routers, switches, and networks. The subsystems are the software elements, and they are defined in the ECS decomposition view. The remainder are environmental elements defined in the deployment view's supporting documentation.
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