Architecture & DesignDeployment Diagram in UML

Deployment Diagram in UML content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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.


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

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

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.


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).

About the Authors

Mandar S. Chitnis, Lakshmi Ananthamurthy, and Pravin S. Tiwari are the co-founders of Novusware. Inc.. They have co-authored the book Teach Yourself BEA WebLogic Server 7.0 in 21 Days (SAMS Publishing, Oct. 2002) based on the recently launched WebLogic Server 7.0 by BEA Systems, Inc.

For any questions or queries regarding the article contents, please contact

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories