Software Design Specifications with UML
Michael W. Bigrigg, Copyright
2004-2007
UML: Introduction
Use Cases: Actors |
Goals | Scenarios
Activity Diagrams: Overview |
Part 1 | Part
2
State Charts: Overview |
Part 1 | Part 2
Deployment Diagrams: Components |
Nodes | Communication
Deployment Diagrams : Components
Michael W. Bigrigg, Copyright
2004-2007
The deployment diagram, type of implementation diagram, describes the interrelationship between the machines, networks, and major software systems. Some may say that the deployment diagram can only be specified after the internals of the software has been designed, but it is rarely the case that we design a system without a general understanding of how we want it to operate. Will it be a web-enabled system? Will there be a central database server? What about an authentication server? Do we have to support Internet access or will all of our remote clients be on an internal high-speed local area network.
Components
To construct a deployment diagram we will again take a bottom-up approach. To start off we want to identify the major software entities. What is a major software entity? The easy answer I can give you is that the software system we are currently designing is one. This is called a component or an artifact and is represented as a box. We must specify that this is an component with the component tag:
FIGURE 1. A Component
These symbols are used to identify the software as a file. The same thing can be done for other documents including scripts or HTML files. What other entities are there? You may then want to say that some database that we use to store student registration information is probably also an entity that we want to identify. A database is a little more complicated so it is a node, but the storage of our registration information can be considered a component.
FIGURE 2. Registration Data
Similarly, we should identify the gradebook data as well as the gradebook application that manages it. The gradebook application is the program that we will design.
FIGURE 3. Gradebook Data and Gradebook Application
A quick scan of our use cases, activity and state diagrams, might help us identify other components such as username and password data.
FIGURE 4. Username/Password Data
When we considered use cases I said that you should not confuse an actor with the tools that the actor uses. Those tools are certainly components, such as the web browswer that our users will use to interface to the gradbook system. Hopefully by now you realized that we were creating a web-enabled system.
Node
Since a component has to be deployed on a machine in order to run or to exist (in the case of data), we have to specify the machine it is going to run on. We signify the node as a cube.
FIGURE 7. A Node
The machine that an artifact runs on is a device node. We started by identifying all the artifacts so that we are not in the position that we just immediately assign each artifact to its own machine. Many of the artifacts can share the same machine. This can often improve performance by reducing the communication.
