In-Depth

Interconnecting Technology with UML

• March 12, 2001

Architecture modeling starts with an essential model (one that is uncommitted to any particular technology) and maps it to a chosen technology. You can use UML to show both the interconnections among technology artifacts and the distribution of your software system across these artifacts.

In this [article], we look at UML packages that only show software partitioning, UML deployment diagrams that only show hardware partitioning, and UML deployment diagrams that show both hardware and software partitioning. Since no two shops have exactly the same notion of a package, I can best describe it generally as a grouping of software elements. Within an object-oriented system, a package is often a collection of classes. It might be a collection of classes in a purchased library, a collection of classes for a particular application, or a collection of classes that capture aspects of a real-world thing (such as CustomerFinancials, CustomerShipping, and CustomerProfile, each of which addresses one set of customer characteristics).

UML depicts a package as a stylized folder, similar to the folder icon used in many desktop applications (see Fig. 1).

The two packages in Fig. 1 presumably dwell in the library of a hospital Information Systems (IS) shop. PatientPackage is a collection of classes relating to a patient, such as Patient and PatientMedicalHistory. HospitalWardPackage is a collection of classes relating to a ward, such as Ward, Bed, and Nurse.1 The fully qualified name for this Bed class is HospitalWardPackage::Bed. Using the fully qualified name distinguishes this class from a Bed class in any other package, such as in HospitalInventory.

A dotted arrow between two packages signifies dependency. In this example, the arrowhead at each end of the arrow shaft reveals a dependency in each direction. The rightward arrow indicates that PatientPackage depends on HospitalWardPackage (perhaps Patient refers to the occupied Bed) and the leftward arrow indicates that HospitalWardPackage depends on PatientPackage (perhaps Nurse contains a reference to Patient).

The UML package diagram in Fig. 2 illustrates how packages can be contained within packages, much as folders can be contained within folders in file-management utilities.

The BusinessDomain package is simply a grouping of the two packages we saw earlier. The ArchitectureDomain package is a grouping of purchased library packages for the hardware/software platform on which the application is to be run: GUISupportLibrary (which contains classes to implement graphical user interface features) and DBSupportLibrary (which contains third-party add-on classes for database support). The vertical ellipses indicate that there are other libraries in the ArchitectureDomain package.

The ApplicationDomain package contains two packages that are specific to a single application for patient admission and discharge.

The PatientAdmitDischargeAppl package contains the software that implements the policies and procedures for admitting and discharging a patient. Since the classes in this package make many references to classes in both PatientPackage and HospitalWardPackage, I placed dependency arrows from PatientAdmitDischargeAppl to PatientPackage and HospitalWardPackage. Alternatively, I could have shown this with a single arrow to the entire BusinessDomain package.

The PatientAdmitDischargeGUI package contains the software for the interface to the application. The classes within the PatientAdmitDischargeGUI package are built using artifacts from the GUISupportLibrary — hence the dependency arrow from the former to the latter.

Deployment diagrams for hardware artifacts

Figure 3 illustrates the hardware technology of a three-tier client-server system.2 On the users' desks, workstations are connected to a departmental file-server via a local-area network (LAN). The departmental file-server may hold individual objects (specifically, their instance variables) and/or the executable code for object classes. The departmental file-servers are, in turn, connected to the corporate server via a wide-area network (WAN). The corporate server may contain information that is central to the corporation or that needs to be kept securely. Each department has an operator workstation that is directly connected to the file-server via LAN and to the corporate server via WAN.

Figure 4 shows an abstraction of Fig. 3 called a UML deployment diagram, which depicts the location of the technology units and the communication links between them.3

The example in Fig. 4 shows that several user workstations are connected to a single departmental file-server via a local communication link (named interDeptLink, of class LAN). Each departmental file-server is attached to an operator workstation via a link (named opLink, also of class LAN). The departmental file-servers and the operator workstations are connected to the corporate server via links (named deptCorpLink and opCorpLink, respectively, both of class TCPIP).

A deployment diagram, such as the one in Fig. 4, is a framework to which you can attach all kinds of statistics and model numbers to specify the technology units and their links. For example, you might specify a certain workstation to be of class Blatz-888-100 (a fabulous workstation from Ignatius Blatz Enterprises), with so many gigabytes of RAM and so many terabytes of fixed-disk. Or, you might define interDeptLink to be of class MellactoLAN (the best-selling LAN from Sid Melly Networks), with a certain protocol and bandwidth.

You may also indicate the multiplicity of the connected nodes, as I have in Fig. 4. For example, we see from the diagram that each userStation is connected to exactly one deptServer and that a given deptServer has at least one userStation connected to it.

Deployment diagrams for software constructs

In Fig. 5, there are three processors: a guidance machine (a Blatz Super5000), a main control-surface controller (a WiggleZap 2B), and a backup control-surface controller (also a WiggleZap 2B). The guidance machine talks to each control-surface controller via a guidance bus.

Well, that's all hardware stuff — like the deployment diagram in Fig. 4. But Fig. 5 also has software allocations.4 Each control-surface controller has a flaps controller running on it (each an instance of FlapsController). Also, the guidance machine has an attitude controller running on it.5 These three pieces of software are UML software components, each depicted by a rectangle with little open bars on one side.6

The criteria for designating UML software components seem to vary from shop to shop. Formally speaking, a UML software component is any element of software that has both an abstract specification (as an interface) and a concrete realization (as a body). I've seen some shops define a software component to be any separately compilable software unit, including: a class; a dynamically linked library (DLL); a C++ pair, comprising a header file (.h) and a code file (.cpp); or a CORBA IDL interface wrapped around a body of legacy code. Other shops choose packages to be the software components of deployment diagrams, using the component symbol to depict the package, rather than the UML symbol that I introduced [earlier].7

But now, back to Fig. 5. A component interface — a "little lollipop," such as those on the left side of flapsController — shows a service that a software com- ponent makes available to the outside world, via an interface. In this example, I've shown FlapManipServices, an interface that provides operations (such as, say, setAngle) for manipulating flaps. (Another interface might be FlapTestServices.)

A dashed arrow pointing to a component interface represents communication. The initiator of the communication is at the tail end. However, information may pass in both directions, as with the in-and-out arguments of a message. For example, in Fig. 5, I added a "ping" between the main and backup flap-controller components to illustrate the application of a UML stereotype to a deployment diagram's communication arrow. The ping allows each component to check the other's operational status periodically. The «ping» stereotype can then be defined for protocol, frequency and so on.

Sometimes, you need to model explicitly certain architectural relationships, such as which software components run on which hardware nodes. Figure 6 uses two stereotypes to accomplish this.

Figure 7 models a less specific relationship, answering the general question, "Which hardware platforms are compatible with a given software component?"

Deployment diagrams are also found in business shops, as often as in real-time shops — although "as rarely" may be a better description of my experience. For example, in Fig. 8, we see a deployment diagram for part of a bank's automated teller application. The atmProcessor (a ScroogeTeller86 machine) communicates via the atmLink (a WAN) with the regionalAccountServer (a DataBlast12A machine). On the atmProcessor, there's a software component (CashDispenser) that controls the doshing out of moolah to the customer. This component communicates with another software component (AccountDataServer), which deals with account data via the interface AccountServices.

Depicting the Human Interface

This section covers two additional diagrams, for window layout and window navigation. Although these two diagram types are not part of traditional UML, they're indispensable for building a typical modern system with a GUIful of windows. The window-layout diagram, which I discussed [earlier], captures the properties of each individual window.

The window-navigation diagram, which I explore [a little later], captures the transitions among the windows that form the application-specific navigation paths. A short digression on the "object orientedness" of graphical user interfaces [is also included].

As Fig. 9 shows, a window-layout diagram corresponds in many ways to the actual window that will be delivered for this part of the application. In this case, the application is a sales system.

Early in the project — perhaps during a prototyping effort — the diagram will show the fields, buttons, and menus of the windows, but it will not be cosmetically correct. For example, the fields may be unaligned and the colors and fonts may be arbitrary. Later, the development team can enhance the diagram's appearance so that it's more in line with the shop's GUI standards. For example, if the final product will have mandatory fields in cyan and optional fields in white, the team can adjust the window-layout diagram to distinguish the two kinds of field.

Especially during prototyping, the window-layout diagram may be a rough-and-ready tool. Indeed, some shops develop theirs on large yellow sticky notes and slap them up on whiteboards. (This approach is termed lo-tech or lo-fi UI prototyping.) Other shops maintain their diagrams in machine-readable form, but not necessarily using a purpose-built windowing tool.

The main purpose for the window-layout diagram is to provide a framework for further design specification, which includes required field cross-validations, field synchronizations, database lookups, and so on. A nontrivial window-layout diagram may be the source of several pages of window specifications.

The purpose of a window-navigation diagram is to show how the users may traverse from one window to another along major, application-meaningful paths. Often, a window-navigation diagram shows the human-computer interaction paths for a single use case.

The window-navigation diagram is a straightforward adaptation of the screen-transition diagram (see, for example, [Yourdon, E. Modern Structured Analysis. Englewood Cliffs, N.J.: Prentice-Hall, 1989, p. 392.]), which is itself an adaptation of the state diagram structure.

Figure 10 shows an example of a window-navigation diagram for the product-pricing part of a sales system. I've inserted stereotypes for the specific roles of the diagram's symbols: > for a window; > for a command button; and