This paper focuses on the Unified Modeling Language (UML) deployment diagram, a static view of the run-time configuration of processing nodes and the components that run on those nodes. It shows both hardware and software partitioning.
Page-Jones (2001), Ambler (1999) and Eyrolles (1997) agree that the deployment diagram focuses on a system’s infrastructure nodes, depicting system components, objects and the physical arrangement of run-time computational resources. But each author chooses to emphasize different things when implementing a deployment diagram
Page-Jones notes that the deployment diagram is roughly equivalent to the architecture --interconnect or architecture -- flow diagram. He focuses on associations between nodes that represent communication paths and the associations that have stereotypes to distinguish different kinds of paths. He says that a cube represents each hardware resource, showing the physical presence of the equipment within the system. A few deployment diagrams can describe any system. Lines connect the nodes in the deployment diagram to each other and solid lines indicate communication connections between nodes. Stereotypes, indicated with <> notation, are a UML mechanism for extending the modeling language by defining common types appropriate to the problem domain. Figure 1 shows the mapping between the nodes LCD Display and UI Processor to their physical architectural representation.
Figure 1. Illustrating the use of stereotypes in a deployment diagram
Eyrolles views the deployment diagram in much the same way as Page-Jones, but Eyrolles dedicates more discussion to node -- the node classes and node instances. He says the graphical difference between classes and objects is that objects names receive underlining and class names do not. Physically nesting the object symbol inside the node symbol shows the presence of an object on a node and the object symbol may contain the tag location.
Both Page-Jones and Eyrolles concentrate on explaining of nodes. Eyrolles gives more details on nodes association, but both authors ignore the nodes relationship on dependency, generalization and when a software engineer needs to create the deployment model.
Ambler provides the broadest and most accurate material on deployment diagrams, including Page-Jones and Eyrolles’ ideas. He also covers dependency, modeling tips and how to determine whether a system needs to apply the UML deployment model in the software process stage. Many software engineers are happy using the core UML diagrams; such as class, use-case, state and collaboration. But Ambler gives special attention to the deployment diagram, even though it usually gets little attention.
Besides Page-Jones and Eyrolles’ ideas, three suggestions on how and when to apply UML deployment diagrams throughout the software process that Ambler proposes.
First, Ambler discusses node dependencies, the connections between two components (sometimes through interfaces). Dotted lines with arrowheads show dependencies between nodes.
Second, software engineers need to determine whether a project needs to create the deployment model?
This is a common question for software engineers who are in charge of the UML modeling process. It’s very clear that the software engineers must implement UML core diagrams, but what about the deployment diagram and the component diagram? When? Why? Ambler presents a simple way to answer these questions. Ask and answer the following question: If a software engineer know nothing about the system and someone asks him to either install or maintain it, would he wants a description of how the system’s parts fit together? If the answer is yes, Ambler says develop a deployment diagram. Ambler’s practice shows that deployment modeling is well worth it -- deployment models force software engineers to think about important deployment issues long before they must deliver the system.
Third, software engineers should perform the deployment modeling early in the project’s life cycle and update it throughout the project as needed. Ambler says, deployment is a difficult process that software engineers should start early in the life cycle, the process begins with requirements definition during the Inception phase, continues with deployment modeling and deployment planning during the Elaboration and Construction phases, and lead to deployment of the system workflow starting late in the project life cycle. He says that deployment modeling is a key component of the deployment workflow and incorporating the UML deployment diagram into system development efforts will increase the chances of delivering the system successfully.
As a result, deployment modeling and the deployment workflow are an important part of system development models.
Based on Ambler’s discussion, Figure 2 depicts a UML deployment diagram for a university administration system. This figure depicts how software engineers deploy major software components into the production environment, enables the project team to identify its deployment strategy.
Figure 2. A Project-Specific UML Deployment Diagram
In conclusion, three authors suggested that the deployment diagram shows run-time architecture of processors and devices, and visualizes the configuration of physical processing elements and the software components that execute on the processing elements. The first two authors emphasize on how to implement the deployment diagram, and the third author emphasizes how and when software engineers need to apply the deployment diagram in the software process stage. This researcher believes that Ambler’s deployment diagram explanations give a fuller and clearer picture of a system than the methods of other authors. The deployment diagram is an important model for increasing the chance of successfully delivering system.