Interconnecting Technology with UML -- ADTmag

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.

The following article is excerpted from Fundamentals of Object-Oriented Design in UML, by Meilir Page-Jones. Used with the permission of the author, Dorset House Publishing and Addison Wesley Longman Inc.

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

> for a navigation path between windows.

From a menu, the user arrives at the main window (ModifyPriceList) for modifying the price list for a product. At that point, he may select New from the pull-down menu under File, which will take him to the NewPriceList window for starting a new price list. Alternatively, he may select Open from the pull-down menu under File, which will take him to the OpenPriceList window to retrieve an existing price list. In any case, he must return to the ModifyPriceList window, where he may then inspect the details of the price list by clicking the Details button. He need not return from the ModifyPriceDtls window (because, presumably, he may exit from the entire price list modification while he still has that window open).

A window-navigation diagram shows only an abstraction of each window. (The window-layout diagram has the job of showing a window's details.) It shows just the buttons, double-clicks, and so on, that cause transitions from one window to another. Similarly, it shows only the menu items and sub-items that cause transitions. Figure 11 provides a key to the symbols of the window-navigation diagram. Figure 12 shows a navigation diamond, which is used to indicate a branch point between two alternative navigation paths. From the main menu (of an order-entry application, in this case), the user arrives at a window for selecting customers. Presumably, this window lists customers (objects of class Customer) in a table, with enough information in the columns (such as name and address) for the user to recognize each customer. The user may then select a customer with a mouse — to "bring focus to a customer row." We'll term this selected customer focusCust.

Once the user has selected the focusCust, the New Order button becomes enabled. Clicking this button takes the user to the window for adding the focusCust's new order. However, there are two groups of customers for this company: domestic and overseas. The latter group requires a special window for order entry, with all kinds of special fields for customs, letters of credit, export authorization, and whatnot.

The application must take the user to the order-entry window that's appro- priate for that focusCust. I show this navigational fork in the road as a black diamond with two paths leading from it, one to each kind of order-entry window. Alongside each navigation path, a Boolean guard expression in brackets indicates which path is enabled for a given customer.

As a matter of human-interface design, navigation diamonds should be used sparingly, because their overuse may confuse the user. However, when you do need to model them, the diamonds and their guards are very expressive.

A brief digression: What's object oriented about a GUI?

Like object orientation itself, graphical user interfaces have attracted diverse responses. Some effervescent folk see GUIs as the pièce de résistance of object orientation, exclaiming, "Wow! GUIs! That means having objects on the screen. Hey, we're object oriented. Yippee!" But other folks, glum souls, complain that graphical user interfaces shouldn't even be mentioned in a book on object orientation. My view is that since the modern GUI has object-oriented aspects, both philosophically and practically, it does belong in a book on O-O. So, first the philosophy, then the practice.

A system that presents itself to its users as a cooperating set of windows normally follows the object-action paradigm. This means that a user selects an object with a single mouse-click (where the object is perhaps shown as an icon or as a row in a table) and then applies an action to the object (perhaps via a menu selection or a double mouse-click).

The object-action paradigm brings object orientation out to the human interface. I say this because the idea of first identifying an object and then requesting it to do something corresponds exactly to sending a message, where we first identify an object by its handle and then invoke one of its operations.

Another object-oriented concept, polymorphism, may also be important in the human interface. As I mentioned in [an earlier chapter], you may highlight an object on a window and then "tell it to print itself." How it prints itself will depend on whether the selected object is a spreadsheet, a text document, or a diagram.

On the practical side, object-oriented design is an approach that's very appropriate for building a system's human interface. You can design the user interface just like any other object-oriented application. For example, when a window of class UpdatableWindow closes, it sends a message to a SaveIgnoreOrCancel window to warn the user that changes may be lost. (The class UpdatableWindow may inherit from the class Window.)

Window objects may also exchange messages with business objects. As a simple example, a window of class ProductItemWin may send a message to an object of class ProductItem in order to display the sellByDate of a particular product item that's on the window.

Thus, in both the philosophical (object-action) sense and in the practical (object-oriented design) sense, graphical user interfaces will have a prominent place on the object-oriented stage for many years to come.

Summary

This [excerpt] presented additional modeling notation necessary for developing systems, especially ones with a sophisticated system architecture or a graphical user interface.

UML offers two complementary diagrams for capturing the software and hardware aspects of system architecture. The first is the package diagram, which depicts groupings of purely software elements. This diagram is valuable for modeling the high-level structure of the software to be implemented.

The second diagram is the deployment diagram, which depicts the technology units (especially hardware such as processors and mass storage, together with their physical communication links) on which the system will be implemented. The deployment diagram can also model how software will be distributed across the chosen technology units, by superimposing software components and their interconnections onto a deployment diagram that represents pure physical technology (such as processors).

A software component is a body of run-time code with a well-defined interface that provides services to other components. In practice, a software component on a deployment diagram may be a dynamically linked library, a package, or even (rarely) a single object. Some shops, rightly or wrongly, choose packages to be the software components that they show on their deployment diagrams.

The window-layout diagram defines the content of a window to be delivered as part of a system's human interface. It approximates the layout of the windows, but doesn't contain every eventual cosmetic refinement. The window-layout diagram serves both as a prototype of the ultimate window and as a framework on which to specify field validations, window/field behavior, messages between business objects, and so on.

The window-navigation diagram, which depicts application-meaningful paths between windows, allows interface designers and users to explore interface navigation before the system is built. It abstracts each window as a skeletal rectangle that bears the window's navigational buttons. The paths between windows appear as arrows, annotated where necessary with menu-selection choices. I use UML stereotypes to indicate windows, buttons, and navigation paths. I also use a navigation diamond where the navigation paths divide, and I place guard expressions along the exit paths of the diamond.

Meilir Page-Jones is president and senior consulting methodologist at Wayland Systems, and has extensive experience in training, consulting and hands-on system development. He has also created several of Wayland's courses on object-oriented software engineering and project management.

Footnotes:

In some methodologies, packages such as PatientPackage and HospitalWardPackage are termed sub-domains of the business domain.
I use the term tier to mean hardware tier.
This is roughly equivalent to the architecture-interconnect diagram of Hatley, D.J., and I.A. Pirbhai. Strategies for Real-Time Systems Specification, 2nd ed. New York: Dorset House Publishing, 1988, and Hatley, D.J., and P. Hruschka. Process for System Architecture and Requirements Engineering. New York: Dorset House Publishing, 2000.
This deployment diagram is roughly equivalent to the architecture-flow diagram of [Hatley and Pirbhai, 1988] or the processor model of Ward, P., and S. Mellor. Structured Development for Real-Time Systems. Englewood Cliffs, N.J.: Prentice-Hall, 1985.
An attitude controller controls the various flight angles of the airplane and not, as one of my students thought, the mood of the passengers.
Oddly, the "little open bars on one side" have no connectional purpose in UML diagrams (although the "little open lollipops" certainly do, as we shall see). My colleague Stan Kelly-Bootle points out that little open bars should always have a connectional purpose. Nevertheless, when I draw a software component on a whiteboard, I replace the bars with little lines — or nothing at all.
When I recently proposed to Professor Sid Dijkstra — an internationally feted expert on the UML package symbol — that UML's package and component symbols be merged into a single symbol, he was aghast. "Meilir, you idiot!" he exclaimed with vehemence. "Don't you realize that packages depict static, lexical properties of the systems, whereas components depict dynamic, run-time structure?" Oh well — can't win 'em all, I suppose!