Step 5(c): Repeat (In Reverse) - Practices

Expand the scope of your process to whole systems (designed with Deployment Diagrams). Repeat Steps 1–4 as appropriate for the current scope.

This optional step is for distributed systems: systems that must be deployed to multiple nodes. In this step, you’ll expand your scope to look at an entire system made up of the components identified in Step 4. By zooming out to the scope of the entire system, you can apply a similar Assign-and-Design process to determine the structure of the system.

UML Notation

In UML, the structure of a system is displayed using Deployment Diagrams, which consist primarily of two types of elements: nodes and associations.

Nodes

A node represents any hardware system in which your components may be installed or with which your components may interact. It may be thought of as a large component, realizing the interfaces of the components installed on it (though the only significant interfaces for a Deployment Diagram are those accessed by components on other nodes).

In a Deployment Diagram, a node is depicted as a cube with shaded top and right edges.

Nodes: A .NET Perspective

In .NET code, a node is primarily any machine to which you deploy .NET components. At the time of this writing, that means mostly Windows PCs (and soon, I hope, the Pocket PC platform as well). But there are ongoing efforts by third parties to port .NET to other environments and platforms.

And of course, there are other nodes besides Windows machines even in today’s .NET apps, including

• The devices—printers, modems, etc.—with which your code interacts

• Other computers that access an ASP.NET site via the Web

• Other computers that access Web services via SOAP

Associations

In a Deployment Diagram, an association represents a connection between two nodes through which two components may communicate (via their interfaces). It is depicted on a Deployment Diagram as a solid line connecting the nodes.

Deployment Associations: A .NET Perspective

In .NET code, the associations between nodes will represent concrete mechanisms like Ethernet and R/F, hardware protocols like TCP/IP and 802.11b, and software protocols like SOAP and .NET Remoting.

Deployment Diagrams

Given these elements, then, a Deployment Diagram depicts nodes and associations between them. Figure 2-62 is a Deployment Diagram that depicts the nodes and associations that may be useful in the Kennel Management System.

Figure 2-62.  Deployment Diagram of the Kennel Management System

In addition, you may choose to list within or under each node the components that are deployed to that node. Such a diagram is illustrated in Figure 2-63.

Figure 2-63.  Deployment Diagram of the Kennel Management System, with components

Looking at the Deployment Diagram and at earlier Component Diagrams, you can see which interfaces must be remote interfaces. For instance, Care Giver Notify is realized by the Paging System, which is deployed to the Care Giver Station; but it’s accessed by the Check Out Form, which is deployed to the KMS Server. Therefore, Care Giver Notify must be a remote interface, and we must define a remoting protocol for it.

Note also that Check In Form and Check Out Form are deployed to the KMS Server, not to the Owner’s PC. This reflects our intention that these should be Web user interfaces: no code is actually delivered to the Owner’s PC, just HTML pages. The actual components that generate the HTML reside on the KMS Server. This also allows us to provide the identical interface to the Reception Station to support walk-in reservations.

Logical Deployment vs. Physical Deployment

The diagram in Figure 2-63 is an example of a logical Deployment Diagram: it depicts the components, the nodes to which they are deployed, and the necessary communication between the nodes. You may also wish to produce a physical Deployment Diagram that depicts the physical mechanisms by which the nodes are connected (usually without showing the components). This will help you to plan hardware acquisitions and connections.

In a physical Deployment Diagram, it is very common to use custom stereotypes that reflect the type of each node. You may also label the associations to describe how two devices are connected if it isn’t clear.

For example, Figure 2-64 is a physical Deployment Diagram for the Kennel Management System.

In this final exercise of the chapter, you and your team can wrap things up by creating Deployment Diagrams from the components and interface dependencies you’ve identified in previous exercises. The steps are summarized in the section that follows.

Figure 2-64.  Physical architecture of the Kennel Management System

 

Designing Deployment: A Summary

Start the process by looking through your components and assigning them to an appropriate node.

If you don’t have an existing node that should host that component, then you’ll need to add a new node icon to the Deployment Diagram. List the component under the appropriate node icon.

Next, based on the interface dependencies identified in the Component Diagrams, add appropriate associations between the nodes.

Finally, redraw the Deployment Diagram, adding appropriate devices and associations to produce a physical Deployment Diagram.

TIP To learn more about Deployment Diagrams, see Chapter 11.

>>> More Practices Articles          >>> More By Apress Publishing

blog comments powered by Disqus