September 2, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Deployment Diagram in UML

  • December 22, 2003
  • By Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy
  • Send Email »
  • More Articles »

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





Page 1 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel