UML 2 For Dummies

Before your design can see the light of day, you must plan the physical appearance of your system—describing the hardware, communication paths between devices, and the different types of files that run on that hardware. UML provides ways to show all such aspects of implementation on a deployment diagram.

Diagramming the physical architecture

Deployment diagrams show the physical architecture of your system—essentially a connected arrangement of hardware—as nodes (three-dimensional boxes). You draw lines between nodes to represent communication paths between your hardware components.

 Tip   Nodes are very similar to classes. In fact, like the aggregate classes that contain parts, your nodes can contain other nodes. You can document detailed hardware configuration information by adding attributes and operations to your nodes. For instance we would specify that our user’s Web-client hardware have the following attributes:

memory : Kilobytes = 256 diskCapacity : Gigabytes = 20 cpuSpeed : Mhz = 1.2 screenResolution: pixelRes = 1024 x 768

Some UML tools display this information right on the diagram. If not, the configuration information is still accessible in the definition of the node for later retrieval.

Any type of hardware that can execute software and talk to other hardware devices—for example, printers, modems, scanners, and external disk drives—are represented as nodes on a deployment diagram. Your communication paths represent such things as local area networks, the Internet, a USB cable, or (indeed) any mechanism that links one node to another. Use stereotypes to indicate the nature of the communication that goes on between your hardware components.

 Tip   Communication paths between nodes are similar to associations between classes. You can show multiplicity, roles, and even qualifiers on the paths between the nodes. We like to show multiplicity to help developers understand how many nodes are in our design configuration.

 Remember   You can use a number of stereotypes on the nodes and the communication paths of your deployment diagram. Some of the more common stereotypes are as follows:

• Nodes: Use these stereotypes to indicate the type of hardware node you’re deploying:

  • «device»: Use this stereotype for a node that has processing capability.

  • «application server»: A node of this type provides a remote service for an application.

  • «client workstation »: A user’s computer is often designated with the client workstation stereotype.

  • «mobile device»: Laptop computers, cell phones, and other devices that use wireless communications are considered mobile devices.

  • «embedded device»: Yes, developers of real-time embedded systems also have a stereotype.

  • «execution environment»: This is a stereotype of a virtual node providing an environment for executing a program. A virtual node looks like hardware but is not actually hardware. An operating system or a Java virtual machine are examples of an execution environment.

  • «container»: Enterprise-system development that uses Java also uses a “container” node to hold components. Designate that piece of hardware with the container stereotype.

• Communication paths: Use these stereotypes to specify types of communication links between hardware nodes:

  • «serial»: Use this stereotype to indicate a serial-port connection between nodes—for example, a connection between a mouse and a computer via the serial port.

  • «parallel»: Use this path to hook up nodes via the parallel port. Many printers and scanners are hooked up this way.

  • «usb»: The Universal Serial Bus (USB) type of connection is used widely to hook up external devices (nodes) to computers.

  • «lan»: Use this stereotype to indicate that two nodes are networked together.

• «internet»: Use the internet stereotype to indicate that the two nodes are using the vast resources of the Internet to communicate. If you have a Web application, you have an internet connection.

A deployment diagram that shows your hardware layout helps others understand how to build the system you have in mind. Keep it simple—show only the hardware architecture and its configuration. Such a diagram helps you to explore the dependencies among your hardware components. In large systems, this simplicity becomes especially important. Consider, for example, corporate data-warehouse configurations that involve many different types of nodes, including the following

• Online transaction-processing database servers

• Operational database servers

• At least one store server that provides atomicity (requiring each transaction to execute—or not—as a unit)

• Various metadata servers

• Multiple data marts

• Online application servers, load balancers, and users’ desktop computers

All these nodes must utilize various corporate networks to communicate. We use a deployment diagram to organize these machines into an architecture. We look for communication bottlenecks in the diagram. We get consensus on the deployment and then publish the final version of the deployment diagram so all the developers understand the complexity of the data warehouse structural design.

 Tip   Don’t try to show everything on your deployment diagram; just show the major pieces of your architecture. You can show computers—or, for that matter, CPU chips—as nodes on a deployment diagram, and if necessary, you can show lots of detail—disk drives, memory cards, backplane communication buses, even specific wires. But these details are not important to most developers of software applications. Just show what’s important to get the job done.

Figure 19-9 illustrates a simple deployment diagram for the hotel-reservation system. Potential guests use a Web Client and gain access to the reservation system through one of several hotel Web Server nodes. The Web Server passes information and requests between the user’s Web Client and a single Reservation Server. The hardware sitting at the hotel’s check-in desk as well as the manager’s office is all one node—the Reservation Client node. This hardware also has access to the Reservation Server by using Java’s remote method-invocation protocol (rmi). The Reservation Server uses the Database Server node for saving reservations and uses one of several available Credit Bureau nodes for credit authorizations.

Figure 19-9: A simple deployment diagram for a reservation system.

Realizing your system as artifacts

 UML2   UML 2 introduces the artifact. We’re not talking relics here. Artifacts are the physical files that make up your implemented system found running on various hardware nodes. Artifacts replace the UML 1.x definition of component.

Your system is logically composed of components, subsystems, classes, and functions. You realize these logical elements as physical artifacts or files. For example, a compiled file with executable code, a Java JAR file, a dynamic link library (dll) file, and a Web script are all artifacts. These are all physical manifestations of your work as a developer. You use deployment diagrams to show not only hardware nodes but also the artifacts that reside on them.

You show artifacts as a rectangle with the name of the artifact inside. The name is usually the filename with its extension, such as room.jar. You use the stereotype «artifact» and optionally a small icon that looks like a dog-eared page. On a deployment diagram, you can show artifacts in the following ways:

• Inside the node on which they reside: Just place the artifact inside the boundary of a node.

• With a location property naming the node on which they reside: The location property is shown below the name of the artifact as follows (replace node name with the actual name of the node):

  {location = node name}

• Along with their dependencies to other artifacts: You show dependencies among artifacts as dashed lines, each with an arrowhead indicating the direction of the dependency.

• With a component property naming the component that the artifact implements: The component property is shown below the name of the artifact as follows (replace component name with the actual name of the node):

  {component = component name}

• As dependencies to the component(s) that they implement: Show the artifact and the component it depends on in your deployment diagram. Then draw a dashed line with an arrowhead from the artifact to the component it depends on.

 Remember   Artifacts are the physical implementation of components or subsystems. So every artifact depends on some component or subsystem, regardless of whether you show it on a deployment diagram.

Figure 19-10 provides an example of a deployment diagram for part of the hotel reservation system. Two artifacts residing on the Reservation Server node—ReservationLogic and Persistence.jar. ReservationLogic depends on the Persistence.jar file because at runtime instances in the ReservationLogic file must invoke instances in the Persistence.jar file. The Persistence.jar file depends on the Rdbms.exe executable file that resides on the Database Server node.

Figure 19-10: Deployment diagram with nodes and artifacts.

You may notice that the diagram shows two ways to indicate an artifact’s dependency on a component. For the ReservationLogic artifact, the component dependency is shown as a property {component = Reservations Business Logic}. For the Persistence.jar artifact, the dependency is shown with a dashed line and an arrow pointing to the PersistentStore component.

 Remember   UML provides you with a number of common stereotypes for your artifacts. Instead of using the plain «artifact» stereotype you can use any of the following to match your deployment situation:

• «executable»: This artifact can be executed as a program on a computer.

• «library»: You use this stereotype when you have a file that is a dynamic (or static) link library or DLL file.

• «script»: Script artifacts are source code files that get interpreted at runtime by some other program. If you have (for example) a Javascript file downloads to a Web browser, use this stereotype.

• «page»: Use the page stereotype to denote a single HTML page.

• «file»: This is a generic stereotype. Use this for any old file that is important to the runtime environment. You might use this for a profile or configuration-setup data file used by a program to start up an application.