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 typethe deployment diagram.
Deployment diagrams are one of the least understoodand 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:
- 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.
- 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 <<>>. |
- 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.
- 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.