Deployment Diagram in UML

8/9/2019 Deployment Diagram in UML

1/4

Deployment Diagram in UML

Over the previous articles in this series, we discussed eight of the nine UML diagrams. The finalUML diagram that we will cover is the deployment diagram. The deployment diagram is related

to the component diagram that we covered in theprevious article and falls in the family ofImplementation diagrams as the component diagram.

Basics

After all the UML diagrams that we have seen till now, you might groanone more UMLdiagram? Well, until now we have discussed UML diagrams that cover the application side interms of both static and dynamic behavior. The component diagram that we covered in theprevious article still focused on the representation of the physical implementation of theapplication components that perform and provide required functionality. The deploymentdiagram provides a different perspective of the application. The deployment diagram capturesthe 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, thisdoes not mean that you should start on your deployment diagram after your system is built. Onthe contrary, your deployment diagram should start from the time your static design is beingformalized using, say, class diagrams. This deployment diagram then evolves and is revised untilthe system is built. It is always a best practice to have visibility of what your deploymentenvironment is going to be before the system is built so that any deployment-related issues areidentified to be resolved and not crop up at the last minute. The general rule of thumb is thatcorrection costs due to changes increase as the project nears completion.

So, how are deployment diagrams and component diagrams related? Essentially, the componentsin a component diagram are contained in the deployment diagram elements. Hence, whilecomponents 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 inwhich a component or a set of components execute. This means that a node in a deploymentdiagram can represent a multitude of thingsphysical hardware such as a server machine, asystem software like an operating system, or even application infrastructure software like a Webserver, application server, database server, and so forth. The different nodes in the deploymentdiagram can be interconnected to represent interdependencies, thus providing a deploymentdiagram that is easy to comprehend and provides the complete deployment environment of asystem.

Now that we understand the concepts of a component in a component diagram, let us see whatnotations 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
http://www.developer.com/design/article.php/3115721http://www.developer.com/design/article.php/3115721http://www.developer.com/design/article.php/3115721


2/4

Node: The element that provides the execution environment forthe components of a system. Depicted by a cube with the name ofthe object in it, preceded by a colon, and underlined.

Connection: Similar to the relation/association used in classdiagrams 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 theDeployment diagram and define dependencies between the nodes of the deployment diagram.

Case StudyCourseware Management System

Over the course of the previous articles, we have modeled different static and dynamic designaspects 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 definingthe deployment diagram of the Courseware Management System is to identify the componentsthat need to be deployed. Once we are clear on this, we will identify what deploymentenvironment will be needed.

For our case study, we will continue the assumption that the components of the CoursewareManagement System have been partitioned on the lines of the Model View Controllerarchitecture. In addition, the Courseware Management System will interact with a database tostore and retrieve the data manipulated by the application.
http://www.developer.com/img/articles/2003/12/22/UML1101.gifhttp://www.developer.com/img/articles/2003/12/22/UML1101.gifhttp://www.developer.com/img/articles/2003/12/22/UML1101.gifhttp://www.developer.com/img/articles/2003/12/22/UML1101.gifhttp://www.developer.com/img/articles/2003/12/22/UML1101.gif


3/4

Identifying deployment elements in the Courseware Management System

Since components of the Courseware Management System will be the primary elementsrepresented in the deployment diagram, we will add the components from the componentdiagram (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 ManagementSystem. A good deployment environment is normally well partitioned to ensure that theapplication components have proper resources in their execution environment. Hence, we willdefine the nodes of our deployment environment as follows:

Web ServerThis node represents the Web server that will receive user requests andsend responses from the application.

Application ServerThe application server node that will process user requests from theWeb server and send application responses back to the Web server is represented by thisnode. The application server node will host the different components of the CoursewareManagement System, such as View, Controller, Model, and Database Access.

Database ServerThe database server node will host the database server used by thecomponents in the application server node to store and retrieve the data used by theCourseware Management System.

Notice that the nodes that we have listed above were not referred at all until this point in thearticle series. This is because these are implementation level detailsexactly the stuff youshould avoid considering when you work on the design of the application.

The different modeling diagrams that make up your application design must not have anydependencies on or references to the deployment environment.

These extra implementation elements that we have introduced are standard for a multi-tier Webapplication 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 applicationserver, and Oracle database server, the deployment diagram would hold true. Now, if we want toreplace 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 berequired 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. Thecomponents that run in this deployment environment will have none to minimal changes. This ineffect demonstrates the clean separation of deployment diagram from the other UML diagramsand 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 thecomponents in each of these nodes, we are ready to draw the deployment diagram using ourUML modeling tool.


4/4

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. Thedeployment diagram shows the three nodes PRD_WEB_SERVER, PRD_APP_SERVER, andPRD_DB_SERVER that represent the nodes for the Web server, application server, and databaseserver, respectively. The View, Controller, and Model components are depicted in theapplication server node and the three nodes are interconnected to denote association betweenthem in the Courseware Management System.

Summary

With this discussion of the deployment diagram, we have covered all nine UML diagrams in theUnified Modeling Language. Through these articles, we aimed to understand the concepts behindeach of these UML diagrams and the underlying rules to build them. The CoursewareManagement System for which we built each of these UML diagrams is just one example of howyou apply the UML diagrams to a system. Remember, there is no substitute to experience tomaster UML diagrams. As you build more and more complex systems, you will evolve yourskills 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 ofdesign 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 theUML diagrams to complete our understanding of the Unified Modeling LanguageDesignPatterns and the Rational Unified Process (RUP).
http://www.developer.com/img/articles/2003/12/22/UML1102.gifhttp://www.developer.com/img/articles/2003/12/22/UML1102.gifhttp://www.developer.com/img/articles/2003/12/22/UML1102.gifhttp://www.developer.com/img/articles/2003/12/22/UML1102.gifhttp://www.developer.com/img/articles/2003/12/22/UML1102.gif

Documents

Deployment Diagram in UML