Incorporating the UML deployment diagram into your system development efforts will increase your chances of delivering your system successfully.
The Unified Modeling Language (UML) describes many models that may or may not be useful to you, depending on your project’s needs. Many writers in this field tend to concentrate on a few “core” diagrams—such as class diagrams, use-case diagrams, and scenario diagrams—when they write about UML modeling, while neglecting the other important diagrams. Among these overlooked diagrams is the UML deployment diagram. This month, I will discuss how you can apply UML deployment diagrams throughout the software process.
A deployment diagram depicts a static view of the run-time configuration of processing nodes and the components that run on those nodes. In other words, it shows your system’s hardware, the software installed on that hardware, and the middleware that connects the disparate machines together. A deployment model is a collection of one or more deployment diagrams with their associated documentation.
You should create a deployment model for applications that are deployed on several machines. A good candidate for a deployment model would be a point-of-sale application running on a thin-client network computer that directly accesses a centralized database server. Another would be a customer service system deployed using a distributed object architecture such as CORBA. You also need deployment models for embedded systems designs to show how the hardware and software components work together. In short, all but the most trivial system will require a deployment model.
Figure 1 presents an example of a UML deployment diagram for a simple Internet-based electronic commerce application. Users use browsers to interact with the system (because you can’t get this information directly from the deployment diagram, you need to indicate this in the corresponding documentation or put a UML note on the diagram), then the browsers interact with your application via the Internet. All requests pass through a secure server that has a firewall installed on it. The requests are multiplexed to different application servers which, in turn, interact with your organization’s data servers.
 |
I’ve applied several stereotypes in Figure 1 that are worth discussing. Stereotypes, indicated with the <<some text>> notation, are a UML mechanism for extending the modeling language by defining common types appropriate to your problem domain. In this instance, stereotypes indicate that the connection between the browser and the secure server is secure (potentially using secure sockets), that several servers use the Linux operating system, that the two data servers are deployed to mainframe technology, and that the Linux boxes interact with the mainframes via CORBA. By applying stereotypes to your diagram, you communicate important information to the diagram users consistently and understandably.
Also note how Figure 1 uses solid lines to indicate communication connections from the browsers to the secure server, and dotted lines with arrowheads to show dependencies between the servers. There are dependencies between the servers because each server directly invokes operations on the other servers it interacts with: the secure server invokes specific operations on the application servers. The application servers, in turn, invoke operations on the data servers. If an operation on the mainframe is changed, the potential result will be changes to the code deployed to the application servers; hence, the application servers depend on the interfaces provided by the data servers. The browsers, on the other hand, don’t depend on the secure server that simply serves them standard HTML and 100% pure Java applets: the HTML and the applets could change and, as long as they remain standard and pure, you would not need to change the browsers.
Now for some modeling tips. First, the diagram doesn’t actually show that a firewall has been installed on the secure server. You would either need to include this information in the associated documentation or use a UML note. Notes are graphical means for including important information in your diagrams that doesn’t fit elsewhere. My experience is that notes quickly clutter your diagrams and make them difficult to use, so you should put this sort of information in the appropriate documentation. Notes are useful when you want to resolve questions about a portion of a diagram—once the issue is resolved, you can remove the note and update the diagram and documentation.
Second, deployment modeling should be performed by both the development and engineering folks responsible for building the system and by operations folks who are responsible for operating it and supporting it once in production. The engineers know how to build the system, whereas the operations people will have a better understanding of your system’s current environment and important operational considerations that the engineers may not fully appreciate.
Third, the modeling team should consider a bevy of issues, such as: What existing systems will your system need to interact or integrate with? How robust does your system need to be (will there be redundant failover hardware in case of a system failure)? What and who will need to connect to and interact with your system, and how will they do it (via the Internet, exchanging data files, and so on)? What middleware, including the operating system and communications approaches and protocols, will your system use? What hardware and software will your users directly interact with—PCs, network computers, browsers, and so on? How will you monitor the system once you deploy it? How secure does the system need to be—do you need a firewall, physically secure hardware, and so on?
To determine whether you need to create a deployment model, ask yourself the following: if you knew nothing about the system and someone asked you to either install or maintain and support it, would you want a description of how the system’s parts fit together? When I ask the project teams that I work with this question, we almost always decide to develop a deployment model. More important, practice has shown that deployment modeling is well worth it—deployment models force you to think about important deployment issues long before you must deliver the actual system.
You should perform deployment modeling early in your project’s life cycle, and update it throughout your project as needed. According to the Rational Unified Process (RUP) life cycle depicted in Figure 2, deployment modeling is an important part of your architectural modeling efforts, typically performed during the Elaboration phase as part of the Analysis and Design workflow. When you consider this approach from Rational’s 4+1 architecture view shown in Figure 3, this makes sense: it contains a deployment view that is documented using a deployment model. However, I disagree with the RUP philosophy on this. I believe that deployment modeling is actually a key component of the deployment workflow.
 |
 |
In my experience, deployment is a difficult process that you should start early in the life cycle. It begins with requirements definition during the Inception phase, continues with deployment modeling and deployment planning during the Elaboration and Construction phases, and then results in the actual deployment of your system during the Transition phase. The RUP, for reasons unknown to me, has the deployment workflow starting late in the project life cycle. The key to the Transition phase is to have a realistic and workable deployment plan, not something you can simply pull out of your hat: deployment is an important issue during the full project life cycle, not a last minute consideration.
When developing a deployment plan in parallel with your deployment model, you must take many issues into consideration. How will your system be installed? Who will install it? How long should it take to install? Where can the installation possibly fail? How do you back out if the installation fails? How long does it take to back out? What is your installation window (during what time period can you install your system)? What backups do you need to make before the installation? Do you need to do a data conversion? How do you know that the installation was successful? If different versions of the system will be in production at the same time, how will you resolve differences? What physical sites do you need to deploy to and in what order? How will you train your support and operations staff? Do you need to deploy a production support system so that the support staff uses their own environment to simulate problems? How will you train your users? What documentation, and in what formats and languages, do your users, and support and operations staff need? How will updates to the documentation be deployed? As you can see, deployment planning is more complicated than it appears on the surface.
Many of the mistakes made in system design are the result of unqualified people picking inappropriate technology. Earlier, I discussed using standard HTML and 100% pure Java—this is a perfect example of choosing to use appropriate technology. There are wacky schemes out there for how to deploy client code that are usually for the tool vendor’s benefit and not yours, the disadvantages of which quickly become apparent once you perform deployment modeling. Deployment modeling is a technique for describing the overall approach to delivering your system, showing both hardware and software, letting you communicate your approach to others for their review and input. Deployment modeling, and the deployment workflow in general, is an important part of your system development efforts that will increase your chances of successfully delivering your system.
RECOMMENDED RESOURCES
The Unified Modeling Language User Guide by Grady Booch, James Rumbaugh, and Ivar Jacobson (Addison-Wesley Object Technology Series, 1999)
UML Distilled: Applying the Standard Object Modeling Language by Martin Fowler and Kendall Scott (Addison-Wesley Object Technology Series, 1997)
The 4+1 View Model of Architecture by Philippe Kruchten (1995) www.rational.com/sitewide/support/whitepapers/results.jtmpl?doc
The UML and Beyond by Scott Ambler (1998) www.ambysoft.com/umlAndBeyond.html
