UML Weekend Crash Course™ - To Parent Directory

264
Sunday Morning
The purpose of a Deployment diagram is to present a static view, or snapshot, of the
implementation environment. A complete description of the system will likely contain a
number of different Deployment diagrams, each focused on a different aspect of the system
management. For example:
One diagram might focus on how software components are distributed, such as
where the source code resides and where it is shipped for implementation.
Another diagram might model how the executable is loaded from one node to
another node where it actually runs.
For a multi-tiered application, the Deployment diagram would model the distribution
of the application layers, their physical connections, and their logical paths of
communication.
Note
Remember that the Component and Deployment diagrams are relatively new
for most people and there are a lot of different ideas out there about how to
use them. These tools can be very helpful, but they will not make or break an
implementation. Use good judgment. Practice. Find out where the benefits lie
for your project. Exploit the tool for your success instead of just following a
standard.
Defining the Notation for the Deployment Diagram
By now, the pattern for these physical diagrams should be getting pretty familiar (that is,
resources and connections). Just like the Package and Component diagrams, the Deployment
diagram has two types of elements: nodes (resources) and associations (connections).
The node icon is drawn as a 3D box (the shading is not necessary). Figure 26-1 models four
types of nodes: Server, Client, Database Server, and Printer. The lines between the nodes are
physical associations that are represented as a solid line from one node to another. Use multiplicity
notation to define the number of nodes on each end of the association. For example,
Figure 26-1 says that each Server is connected to one or more Client nodes, and each Client
node is connected to exactly one Server node.
Naming the node associations poses an interesting problem. Because all the associations
are physical connections, they could all end up with the same name, “connects to.” Instead,
you may want to use stereotypes to describe types of connections. Figure 26-1 says that the
Server node and Client nodes are connected by an Ethernet connection using the
stereotype.
The node is a classifier (like classes, Use Cases, and components), so it can have attributes
and specify behaviors in terms of the executables it deploys. Figure 26-2 shows an
object-level view of a Deployment diagram. The object-level diagram models instances of
each node just as an Object diagram models real entities. The name compartment on top
identifies the node name and type, as well as the optional stereotype. The attribute compartment
in the middle defines the properties of the node. The operations compartment at
the bottom defines the components that run on the node.