Deployment Diagram in UML

Over the previous articles in this series, we discussed eight of the nine UML diagrams. The final
UML diagram that we will cover is the deployment diagram. The deployment diagram is related
to the component diagram that we covered in the previous article and falls in the family of
Implementation diagrams as the component diagram.
Basics
After all the UML diagrams that we have seen till now, you might groan—one more UML
diagram? Well, until now we have discussed UML diagrams that cover the application side in
terms of both static and dynamic behavior. The component diagram that we covered in the
previous article still focused on the representation of the physical implementation of the
application components that perform and provide required functionality. The deployment
diagram provides a different perspective of the application. The deployment diagram captures
the configuration of the runtime elements of the application.
This diagram is by far more useful when a system is built and ready to be deployed. But, this
does not mean that you should start on your deployment diagram after your system is built. On
the contrary, your deployment diagram should start from the time your static design is being
formalized using, say, class diagrams. This deployment diagram then evolves and is revised until
the system is built. It is always a best practice to have visibility of what your deployment
environment is going to be before the system is built so that any deployment-related issues are
identified to be resolved and not crop up at the last minute. The general rule of thumb is that
correction costs due to changes increase as the project nears completion.
So, how are deployment diagrams and component diagrams related? Essentially, the components
in a component diagram are contained in the deployment diagram elements. Hence, while
components provide the application functionality, the deployment diagram elements provide the
necessary environment for the components to execute in.
The basic deployment diagram element is the node. The node represents the environment in
which a component or a set of components execute. This means that a node in a deployment
diagram can represent a multitude of things—physical hardware such as a server machine, a
system software like an operating system, or even application infrastructure software like a Web
server, application server, database server, and so forth. The different nodes in the deployment
diagram can be interconnected to represent interdependencies, thus providing a deployment
diagram that is easy to comprehend and provides the complete deployment environment of a
system.
Now that we understand the concepts of a component in a component diagram, let us see what
notations to use to draw a component diagram.
Elements of a Deployment Diagram
A deployment diagram consists of the following elements:
Element and its description Symbol
Node: The element that provides the execution environment for
the components of a system. Depicted by a cube with the name of
the object in it, preceded by a colon, and underlined.

Connection: Similar to the relation/association used in class

diagrams to define the interconnection between nodes.

Creating a Deployment Diagram

Click here for a larger image.

Figure 1 Screen shot of the Poseidon tool
The screen shot of the Poseidon tool in Figure 1 shows the different options to model the
Deployment diagram and define dependencies between the nodes of the deployment diagram.
Case Study—Courseware Management System
Over the course of the previous articles, we have modeled different static and dynamic design
aspects of the Courseware Management System. Now, we need to define how we plan to deploy
the application components of the Courseware Management System. The first part in defining
the deployment diagram of the Courseware Management System is to identify the components
that need to be deployed. Once we are clear on this, we will identify what deployment
environment will be needed.
For our case study, we will continue the assumption that the components of the Courseware
Management System have been partitioned on the lines of the Model View Controller
architecture. In addition, the Courseware Management System will interact with a database to
store and retrieve the data manipulated by the application.
Identifying deployment elements in the Courseware Management System
Since components of the Courseware Management System will be the primary elements
represented in the deployment diagram, we will add the components from the component
diagram (discussed in the previous article) to the deployment diagram. These components are:
• View
• Controller
• Model
• Database Access
The next step is to identify the deployment environment for the Courseware Management
System. A good deployment environment is normally well partitioned to ensure that the
application components have proper resources in their execution environment. Hence, we will
define the nodes of our deployment environment as follows:
• Web Server—This node represents the Web server that will receive user requests and
send responses from the application.
• Application Server—The application server node that will process user requests from the
Web server and send application responses back to the Web server is represented by this
node. The application server node will host the different components of the Courseware
Management System, such as View, Controller, Model, and Database Access.
• Database Server—The database server node will host the database server used by the
components in the application server node to store and retrieve the data used by the
Courseware Management System.
Notice that the nodes that we have listed above were not referred at all until this point in the
article series. This is because these are implementation level details—exactly the stuff you
should avoid considering when you work on the design of the application.
The different modeling diagrams that make up your application design must not have any
dependencies on or references to the deployment environment.
These extra implementation elements that we have introduced are standard for a multi-tier Web
application architecture. Let us see how this is so.
If, for example, the same Courseware Management System application were to deployed on, say,
a deployment environment consisting of, say, Apache Web Server, BEA WebLogic application
server, and Oracle database server, the deployment diagram would hold true. Now, if we want to
replace BEA WebLogic application server with, say, IBM Websphere, neither the UML models
(static and dynamic) nor the deployment diagram will change.
On the other hand, if we now wanted to make this a client/server application, the changes will be
required only to the deployment diagram by removing the Web server node and changing the
deployment environment to something more suited for a client/server software environment. The
components that run in this deployment environment will have none to minimal changes. This in
effect demonstrates the clean separation of deployment diagram from the other UML diagrams
and demonstrates the robustness of the application's design.
Now that we have an idea of the nodes that will make up the deployment diagram and the
components in each of these nodes, we are ready to draw the deployment diagram using our
UML modeling tool.
Deployment Diagram

Click here for a larger image.

Figure 2 Deployment diagram for the Courseware Management System
Figure 2 shows the Deployment diagram for the Courseware Management System. The
deployment diagram shows the three nodes PRD_WEB_SERVER, PRD_APP_SERVER, and
PRD_DB_SERVER that represent the nodes for the Web server, application server, and database
server, respectively. The View, Controller, and Model components are depicted in the
application server node and the three nodes are interconnected to denote association between
them in the Courseware Management System.
Summary
With this discussion of the deployment diagram, we have covered all nine UML diagrams in the
Unified Modeling Language. Through these articles, we aimed to understand the concepts behind
each of these UML diagrams and the underlying rules to build them. The Courseware
Management System for which we built each of these UML diagrams is just one example of how
you apply the UML diagrams to a system. Remember, there is no substitute to experience to
master UML diagrams. As you build more and more complex systems, you will evolve your
skills and gain a deeper understanding and varied ways to utilize the power of UML diagrams.
The reason behind the popularity of the Unified Modeling Language is the broad palette of
design elements it provides for modeling systems and most importantly, uniformity in notations.
So, happy modeling!
In the final two articles of this series, we will take a quick look at two more areas that utilize the
UML diagrams to complete our understanding of the Unified Modeling Language—Design
Patterns and the Rational Unified Process (RUP).