Figure 1 presents an example of a fully rendered UML 2 deployment diagram for the student administration application. The three-dimensional boxes represent nodes, either software or hardware. Physical nodes should be labeled with the stereotype device, to indicate that it's a physical device such as a computer or switch. As you can see I didn't indicate that WebServer is a device – it will at least be some sort of software artifact and very well may be one or more physical devices as well but my team hasn't made that decision yet. Remember, models evolve over time. Connections between nodes are represented with simple lines, and are assigned stereotypes such as RMI and message bus to indicate the type of connection.

Nodes can contain other nodes or software artifacts. The ApplicationServer node contains EJBContainer (a software node) which in turn contains three software components, a deployment specification, and a software artifact. The software components use the same notation as component diagrams (I could have annotated them with their interfaces although that wouldn't have added any value in my opinion). Deployment specifications are basically configuration files, such as an EJB deployment descriptor, which define how a node should operate. They are depicted as two-sectioned rectangles with the stereotype deployment spec, the top box indicates the name and the bottom box lists the deployment properties (if any) for the node. In my opinion the deployment properties is superfluous as this is the type of information that is contained in the actual deployment specification file at run time. Software artifacts are shown with the visual stereotype of a page with a folded corner or with the textual stereotype artifact (or both sometimes, which I also believe is superfluous). In this case the software artifact is a fictional persistence framework purchased from AmbySoft (the vendor is indicated with a UML property string).

Figure 1. UML 2 deployment diagram for the university information system.

When you stop and think about it, the stereotypes that I've applied to the connections aren't correct. In reality the software on the web server is communicating via the RMI protocol over the connection to the software on the application server. The physical connection between the physical hardware nodes is at a lower level, perhaps an Ethernet connection, so in reality I really should have modeled a connection between the hardware nodes with Ethernet as a stereotype and a second connection between software elements with the RMI stereotype. I'd also need to model a dependency relationship between the software connection and the hardware connection, perhaps with the stereotype of over. Although this would be more accurate it would be a lot of work that I likely wouldn't get much benefit from. Remember, agile models don't need to be perfect, they need to be just barely good enough.

I never draw deployment diagrams following the style show in Figure 1, except when I'm writing about deployment modeling, because in my opinion this notation is visually wasteful. A better example is shown in Figure 2. Software elements are now simply listed by their physical filenames, information that developers are very likely to be interested in, and thus a more compact diagram is possible. I've also used a drum as a visual stereotype for the University DB database, making it easier to distinguish on the diagram. Another difference is that the concise version shows less details, not as many tagged values are shown as this information can be captured in either supporting documentation, configuration files, or source code. Deployment diagrams tend to become very large very quickly because they reflect the physical complexities of your system, therefore a concise notation becomes critical to your success.

Figure 2. Concise UML 2 deployment diagram.

How agile are deployment diagrams? As always, it depends on your goals. Very often less-detailed network diagrams, which are arguably deployment diagrams with extensive use of visual stereotypes, are a better option. This is particularly true when you are modeling an environment consisting of a many interconnected machines. Sometimes a high-level free-form diagram is a better option because the notation is much more flexible. The information contained in Figure 2 can just as readily be captured in either a network diagram or a free-form diagram in combination with installation scripts. When you think about it installation scripts are effectively "deployment source code".

To determine whether you need to create a deployment model, ask yourself this: if you knew nothing about the system and someone asked you to install it and/or maintain and support it, would you want a description of how the parts of the system fit together? When I ask this question of the project teams I work with, we almost always decide to develop some form of 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.

When determining how to model the deployment architecture for a system, regardless of the artifacts chosen, I will typically:

1. Identify the scope of the model. Does the diagram address how to deploy a version of a single application or does it depict the deployment of all systems within your organization?
2. Consider fundamental technical issues. What existing systems will yours need to interact/integrate with? How robust does your system need to be (will there be redundant hardware to failover to)? What/who will need to connect to and/or interact with your system and how will they do it (via the Internet, exchanging data files, and so forth)? What middleware, including the operating system and communications approaches/protocols, will your system use? What hardware and/or software will your users directly interact with (PCs, network computers, browsers, and so forth)? How do you intend to monitor the system once it has been deployed? How secure does the system need to be (do you need a firewall, do you need to physically secure hardware, and so forth)?
3. Identify the distribution architecture. Do you intend to take a fat-client approach where the business logic is contained in a desktop application or a thin-client approach where business logic is deployed to an application server? Will your application have two tiers, three tiers, or more? Your distribution architecture strategy will often be predetermined for your application, particularly if you are deploying your system to an existing technical environment.
4. Identify the nodes and their connections. Your distribution strategy will define the general type of nodes you will have, but not the exact details. You need to make platform decisions, such as the hardware and operating systems to be deployed, including how the various nodes will be connected (perhaps via RMI and a message bus as in Figure 2).
5. Distribute software to nodes. Both versions of the deployment diagrams indicate the software that is deployed on each node, critical information for anyone involved in development, installation, or operation of the system.

Source

This artifact description is excerpted from Chapter 10 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.

Translations

• Japanese

Disclaimer

The notation used in these diagrams, particularly the hand drawn ones, may not conform perfectly to the current version of the UML for one or more of reasons:

• The notation may have evolved from when I originally developed the diagrams. The UML evolves over time, and I may not have kept the diagrams up to date.
• I may have gotten it wrong in the first place. Although these diagrams were thoroughly reviewed for the book, and have been reviewed by thousands of people online since then, an error may have gotten past of us. We're only human.
• I may have chosen to apply the notation in "non-standard" ways. An agile modeler is more interested in created models which communicate effectively than in conforming to notation rules set by a committee.
• It likely doesn't matter anyway, because the modeling tool(s) that you're using likely won't fully support the current version of the UML notation perfectly anyway. Bottom line is that you're going to be constrained by your tools anyway.

If you're really concerned about the nuances of "official" UML notation then read the current version of the UML specification.