Deployment Style

5.3.1 Overview

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.

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.

• Migrates-to: A relation from a software element on one processor to the same software element on a different processor, this relation indicates that a software element can move from processor to processor but does not simultaneously exist on both processors.
• Copy-migrates-to: This relation is similar to the migrates-to relation, except that the software element sends a copy of itself to the new process element while retaining a copy on the original processing element.
• Execution-migrates-to: Similar to the previous two, this relation indicates that execution moves from processor to processor but that the code residency does not change. A copy of a process exists on more than one processor, but only one is active at any particular time. The execution of the process "migrates" when the active process is changed.

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.

• CPU properties: A set of properties relevant to the various processing elements may be specified. These properties include processor clock speed, number of processors, memory capacity, bus speed, and instruction execution speed.
• Memory properties: A set of properties relevant to the memory stores may be specified. These properties include memory size and speed characteristics.
• Disk or other storage unit capacity: This property specifies the storage capacity and access speed of disk units: individual disk drives, disk farms, and RAID [redundant array of inexperience disks] units.
• Bandwidth: This property indicates the data transfer capacity of communication channels.
• Fault tolerance: Multiple hardware units may perform the same function, and these units may have a failover control mechanism.

Properties that are relevant to software elements include

• Resource consumption: For example, computation takes 32,123 instructions.
• Resource requirements and constraints that must be satisfied: For example, a software element must execute in 0.1 second.
• Safety critical: For example, a software element must always be running.

The following property is relevant to the allocation:

• Migration trigger: If the allocation can change as the system executes, this property specifies what must occur for a migration of a software element from one processing element to another.

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.[1] 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.

[1] 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 Notations

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.

UML

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.