UML for the Software Developer, Part 4: Deployment Diagrams : Page 4

Deployment diagrams act as the link and reference point between how the system is built and where it is displayed. Learn how capacity planning, n-tier development, and coordination of tasks between different teams can all benefit from these diagrams.

by Mark Goetsch

Apr 18, 2005

Page 4 of 4

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.

Author's Note: The agile philosophy does not support the use of diagrams because of the difficulty in maintaining them when the system evolves. Agile Modeling by Scott Ambler suggests using a whiteboard similar to the OOPSLA design sessions (another excellent conference to go to, but more on the academic side) so that they can be erased after they have been discussed with the other developers. Deployment diagrams exist outside of just software development and impact other projects in the enterprise, as well as infrastructure. They only change when systems change, when major new enhancements are added, or when the system is wrapped as a legacy system. It is for these reasons that the deployment diagrams are kept.

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.

Mark Goetsch is an Enterprise Software Architect with Wheels, Inc, and has more than fifteen years of experience in software development, enterprise modeling, and software architecture. He has another seven years experience as a trader, dealer, Broker, and an expert in e-trading. He was one of the enterprise modelers of the Tapestry Project at ABNAMRO, one of the most extensive uses of UML component and deployment diagrams to date. He is the lead architect for the MAP (Meta-Architectural Processes) framework, which is a framework for mapping the role of the software architect into software development processes. Mark is certified in Intermediate UML with the OMG and a member of WWISA. He also has a Masters in Distributed Systems from DePaul University.