Interconnecting Technology with UML
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.
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.
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 contains two packages that are specific to a single application
for patient admission and discharge.
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.
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.
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
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.
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?"
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
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
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
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.
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.
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