o far, you and I have journeyed through the realm of class diagrams. Classes are a good start for understanding how an application is hooked together, and while they describe the static relationships between the objects in the system, classes are just an abstraction of the software itself. What happens after the classes are built? The answer is, of course, that they need to be deployed. But where? How do I model deployments? The answer is a new diagram type?the deployment diagram.

Deployment diagrams are one of the least understood?and most important-diagrams in the UML pantheon. Many developers don’t even know what they are, yet consider themselves experts in UML. The purpose of a deployment diagram is to model the execution environment for a project. They can also be used to describe the enterprise environment, but this is more the enterprise architect’s domain.

I will take you through a three-step process that explains how deployment diagrams are used, helps prepare the project for deployment, and maps out where all of the new components will live and act in a production blueprint.

Before discussing the three steps, let’s examine the UML components that make up a deployment diagram. There are only a few elements used, but they can quickly become complicated if your development environment requires a lot of detail.

Deployment Diagram Elements
There are four elements used in a deployment diagram:

1. Nodes: A node corresponds to hardware. In the older versions of UML the node was the same as a separate piece of hardware that had at least one processor. In UML 2.0 the node can represent a piece of a larger hardware component, represented by encapsulating the node (having one node inside the other node). The node contains a stereotype that represents what the hardware is used for. The attributes of the node represent the hardware’s configuration.
2. Components: Components represent software. Each component is representative of one or more classes that implement one function within the system. A component can represent something as granular as a price adapter in the Richmen Inc. example (from the previous articles in this series), to a sub-system to handle a trade entry.

Figure 1. UML Elements: This figure shows all of the different UML elements used in a deployment diagram. In some of the modeling tools the dependency line can be replaced by adding the component to the node. The attributes beneath the element names refer to the stereotype between <<>>.

3. Dependencies: Dependencies show that one component relies upon another component. They are sometimes used in deployment diagrams, but for individual projects I prefer to leave dependencies for component diagrams. I do use dependencies on deployment diagrams as an alternative method of encapsulation of a component within a node, but not every modeling tool supports having a component inside the node. The basic rule for dependencies is that the component points to, or depends upon, the other component.
4. Links: Links are used to tie together two nodes. They are implemented with nodes using associations, but with node instances they are implemented as links. The links will usually be stereotyped with a protocol as well, such as TCP/IP.

The last thing to explain before jumping into the process is the difference between components and component instances and nodes and node instances. Nodes and components are a high-level view of the major software and hardware that compose a system. Node instances and component instances model the actual components and hardware used. We will see some differences when looking at how these concepts create alternate views of the same deployment.

The Process
Any process needs participants. In modeling UML, we refer to these participants as roles or actors depending upon whether we are describing the participants (roles) or modeling them (actors). In this case we are using actors to account for departments as well as individuals. Our primary actor is the developer representing the different roles in software development. Secondary actors include the infrastructure that represents the roles needed to deploy the software and business analysts representing the requirements and the users.

There are three steps in the deployment diagramming process:

1. Pre-Stage: determining the initial hardware requirements for deployment.
2. Staging: adding the different software components to the deployment diagram.
3. Production: associating the hardware requirements with the actual hardware.

Each of these three steps occurs during different times in the project. Each step can be iterated throughout the software development lifecycle. If there is a change in a previous iteration, the diagramming should be restarted.

In the rest of this article I will show you how our friends at Richmen Inc. from part one used deployment diagrams with their trade entry application. There were two parts to this project: trade entry and using market quotes.

Pre-Stage
The pre-stage step is used to determine the overall hardware needs for the project, as determined by the third-party software used, special technologies, or other architectural constraints. The developers will meet with infrastructure and business analysts to determine the initial requirements. This stage may iterate through multiple proof-of-concepts (POC) used to test out critical architectural pieces of the project and determine the needs of any third-party software used.

Figure 2. Pre-Stage Step: The pre-stage deployment diagram for Richmen Inc. shows two servers and one client. I also showed the components encapsulated within the nodes, which is an alternative method in UML.

This first step is used during the project to determine resource allocation, budget allotment, and by the infrastructure to schedule the purchasing and configuration of hardware for the project. This can be iterated throughout the project but if this part is changed then both the staging and production stages will need to be updated to reflect this.

In the case of Richmen Inc., mentioned in the previous articles, there was a legacy component that was used for entering trades. This component was written in VB 6.0 by the “SuperTradeEntry Company” and used SQL Server v. 7.0. Another component was used for quotes. One of the leading vendors of quotes, QuoteMaster, Inc., has a product that automates the download and maintenance of live equity quotes used in the previous article.

Not every component is displayed in Richman Inc’s deployment diagram. The two components TradeEntry and FastQuote represent vendor software. In this example, each will only be one component but there may be cases in which, initially, only one component is displayed that represents a whole vendor subsystem. In other cases, a vendor component will be added to as further iterations uncover expanded vendor details. Notice that the attributes on each server and the client represent the requirements of the software for this project. They do not represent the actual server configuration that might be used for other projects as well.

The example already has some value. The infrastructure has some upfront information that can be used for planning the new deployment. This is also useful for the business when explaining about POCs for vendor software and to give them some perspective on the true scope of a project.

Staging
The stage step adds the in-house developed components to the pre-stage diagram. Each component represents a set of classes similar to the ones that we added in the previous articles. Each component is a separate function in the system using the “Separation of Concerns” pattern from the last article. (See sidebar “Patterns“)

Figure 3. Staging Step: In this deployment diagram the components for both the third-party software and in-house software are displayed. I have taken the attributes off the node since they were already captured in the first deployment diagram.

In the staging diagram for Richmen Inc., I added components for the in-house developed pieces of the project. The Portfolio Calculator, PortfolioTradeIntegrator, PortfolioDBInterface, and BrokerEntry were built by development and stereotyped as executables. For reference I added a language attribute to the executable stereotype. There is also a configuration file called BrokerEntry.Config that contains configuration information for the client side of the project. I didn’t add a web.config file because it is one more detail that can be safely ignored here.

The nodes in the diagram have also changed. I added a new node called PortfolioServer. The connections between the nodes have changed as well. Client is connected through PortfolioServer to QuoteServer and TradeEntryServer. This doesn’t invalidate the other deployment diagram, but think of it as a different view of deployment.

Production
The production step is used as the roadmap for implementing the system in production. The nodes are changed to node instances and the actual machine names are added. The components become component instances and will, in some cases, have multiple instances. Multiple node instances may be used for each node to represent clustering and failovers. If the company uses system diagrams, then the nodes correspond in name and number with the systems on the system diagram.

Figure 4. Production Step: The production deployment diagram uses the actual hardware names. I habitually append a number to the end of both the component and node instance names. This is useful when the naming standards of the organization are not as well defined. In organizations that use naming standards these names are picked in a different fashion.

Richmen Inc. had only two servers on which to deploy the software, so the TradeEntry and FastQuote software was added to the same server. From the pre-stage deployment diagram (see Figure 2) it is easy to see that SV002 is a big enough server. SV001 was ordered for this current project. Both servers are typed (the “:” after SV001 and SV002 shows how these servers relate to the project). The client node instances Clnt001 and Clnt002 are two different workstations. In this instance, they have the same configuration but that is not always the case. In larger environments there are standard builds or images for each machine. The workstations in these environments can often be represented by one sample workstation.

The component instances in the diagram are typed against their base component. There isn’t that much information to the component except for the name. In some environments there might be minimal configurations that are added as attributes to the component instance.

Class diagrams, which I discussed in an earlier article, may or may not be kept, depending upon the software process used. They are not expected to be representative of the current production code and, at best, only serve as guidelines to the construction of the system. Deployment diagrams, on the other hand, are maintained throughout the life of the system. For infrastructure, they represent the current state of the system and if the system needs to be moved to new hardware. The infrastructure will need to change the production deployment diagrams. For business analysts, the staging documents tell you which components are implemented. Developers will also use the staging diagrams as a method for understanding the current system and planning for new changes. Any changes in this diagram will also change the production deployment diagrams as well. The pre-stage diagram is only useful when replacing or understanding third-party software and can be helpful when new third-party software is significantly different from the previously used software.

There are many different ways to use this entire process. It is possible to use all of these as one diagram passing through different states leading up to the final deployment diagram. All three diagrams can also be kept to document some of the different abstractions that led up to the final deployment diagram.

We can now deploy our software. In the next installment of this series, I will examine components in more detail and use another type of implementation diagram.