The Unified Modeling Language

(UML)
Brief Summary of UML
The Unified Modeling Language (UML) is a general-purpose visual
modeling language that is used to specify, visualize, construct, and
document the artifacts of a software system. It captures decisions and
understanding about systems that must be constructed. It is used to
understand, design, browse, configure, maintain, and control information
about such systems. It is intended for use with all development methods,
lifecycle stages, application domains, and media. The modeling language
is intended to unify past experience about modeling techniques and to
incorporate current software best practices into a standard approach.
UML includes semantic concepts, notation, and guidelines. It has static,
dynamic, environmental, and organizational parts. It is intended to be
supported by interactive visual modeling tools that have code generators
and report writers. The UML specification does not define a standard
process but is intended to be useful with an iterative development
process. It is intended to support most existing object oriented
development processes.
The UML captures information about the static structure and dynamic
behavior of a system. A system is modeled as a collection of discrete
objects that interact to perform work that ultimately benefits an outside
user. The static structure defines the kinds of objects important to a
system and to its implementation, as well as the relationships among the
objects. The dynamic behavior defines the history of objects over time
and the communications among objects to accomplish goals. Modeling a
system from several separate but related viewpoints permits it to be
understood for different purposes.
The UML also contains organizational constructs for arranging models into
packages that permit software teams to partition large systems into
workable pieces, to understand and control dependencies among the
packages, and to manage the versioning of model units in a complex
development environment. It contains constructs for representing
implementation decisions and for organizing run-time elements into
components.

UML is not a programming language. Tools can provide code generators

from UML into a variety of programming languages, as well as construct
reverse engineered models from existing programs. The UML is not a
highly formal language intended for theorem proving. There are a number
of such languages, but they are not easy to understand or to use for most
purposes. The UML is a general- purpose modeling language. For
specialized domains, such as GUI layout, VLSI circuit design, or rule-based
artificial intelligence, a more specialized tool with a special language
might be appropriate. UML is a discrete modeling language.
It is not intended to model continuous systems such as those found in
engineering and physics. UML is intended to be a universal general-purpose
modeling language for discrete systems such as those made of software,
firmware, or digital logic.

UML Walkthrough
This chapter presents a brief walkthrough of UML concepts and diagrams
using a simple example. The purpose of the chapter is to organize the
high-level UML concepts into a small set of views and diagrams that
present the concepts visually.
It shows how the various concepts are used to describe a system and
how the views fit together. This summary is not intended to be
comprehensive; many concepts are omitted. For more details, see the
subsequent chapters that outline the UML semantic views, as well as the
detailed reference material in the encyclopedia chapter. The example
used here is a theater box office that has computerized its operations.
This is a contrived example, the purpose of which is to highlight various
UML constructs in a brief space. It is deliberately simplified and is not
presented in full detail. Presentation of a full model from an implemented
system would neither fit in a small space nor highlight a sufficient range
of constructs without excessive repetition.
UML Views
There is no sharp line between the various concepts and constructs in
UML, but, for convenience, we divide them into several views. A view is
simply a subset of UML modeling constructs that represents one aspect of
a system. The division into different views is somewhat arbitrary, but we
hope it is intuitive. One or two kinds of diagrams provide a visual
notation for the concepts in each view.
At the top level, views can be divided into three areas: structural
classification, dynamic behavior, and model management.

Structural classification describes the things in the system and their

relationships to other things. Classifiers include classes, use cases,
components, and nodes. Classifiers provide the basis on top of which
dynamic behavior is built. Classification views include the static view, use
case view, and implementation view.

Static View
The static view models concepts in the application domain, as well as
internal concepts invented as part of the implementation of an
application. This view is static because it does not describe the timedependent behavior of the system, which is described in other views. The
main constituents of the static view are classes and their relationships:
association, generalization, and various kinds of dependency, such as
realization and usage. A class is the description of a concept from the
application domain or the application solution. Classes are the center
around which the class view is organized; other elements are owned by
or attached to classes. The static view is displayed in class diagrams, so
called because their main focus is the description of classes.
Classes are drawn as rectangles. Lists of attributes and operations are
shown in separate compartments. The compartments can be suppressed
when full detail is not needed. A class may appear on several diagrams.
Its attributes and operations are often suppressed on all but one
diagram.
Relationships among classes are drawn as paths connecting class
rectangles. The different kinds of relationships are distinguished by line
texture and by adornments on the paths or their ends.
Figure 1 shows a class diagram from the box office application. This
diagram contains part of a ticket-selling domain model. It shows several
important classes, such as Customer, Reservation, Ticket, and
Performance. Customers may have many reservations, but each
reservation is made by one customer. Reservations are of two kinds:
subscription series and individual reservations. Both reserve tickets: in
one case, only one ticket; in the other case, several tickets. Every ticket
is part of a subscription series or an individual reservation, but not both.
Every performance has many tickets available, each with a unique seat
number. A performance can be identified by a show, date, and time.
Classes can be described at various levels of precision and concreteness.
In the early stages of design, the model captures the more logical
aspects of the problem.
In the later stages, the model also captures design decisions and
implementation details. Most of the views have a similar evolutionary
quality.

Figure 1. Class diagram

Use Case View

The use case view models the functionality of the system as perceived by
outside users, called actors. A use case is a coherent unit of functionality
expressed as a transaction among actors and the system. The purpose of
the use case view is to list the actors and use cases and show which
actors participate in each use case.
Figure 2 shows a use case diagram for the box office example. Actors
include the clerk, supervisor, and kiosk. The kiosk is another system that
accepts orders from a customer. The customer is not an actor in the box
office application because the customer is not directly connected to the
application. Use cases include buying tickets through the kiosk or the
clerk, buying subscriptions (only through the clerk), and surveying total
sales (at the request of the supervisor). Buying tickets and buying
subscriptions include a common fragmentthat is, making charges to the
credit card service. (A complete description of a box office system would
involve a number of other use cases, such as exchanging tickets and
checking availability.)

Use cases can also be described at various levels of detail. They can be
factored and described in terms of other, simpler use cases. A use case is
implemented as a collaboration in the interaction view.

Figure 2. Use case diagram

The Project
The RDN's Subject Portals Project (SPP) is funded under the
JISC's DNER Development Programme. There were two proposals, SAD I
(Subject Access to the DNER) and SAD II. The original SAD I proposal
was part of a closed JISC DNER call, 'Enhancing JISC Services to take
part in the DNER'. The SAD II proposal was successful under the JISC

5/99 call, 'Enhancing the DNER for Teaching and Learning'. The original
project proposals are available [1].
The aim of the project is to improve the functionality of five of the RDN
hub sites to develop them into subject portals. Subject portals are filters
of Web content that present end users with a tailored view of the Web
within a particular subject area. In order to design software tools that
simultaneously satisfy the needs of a variety of different sites and make
it easier for institutional portals to embed our services in the future, we
are designing a series of Web "portlets". One portlet will be built for each
of the key portal functions required, focussing initially on authorisation
and authentication (account management); cross-searching; and user
profiling; but including eventually a range of "additional services" such as
news feeds, jobs information, and details of courses and conferences.
The project is committed to using open source software wherever
possible.

Figure 3. Activity diagram of registration.

Figure 4. Activity diagram of Administration.

Figure 5. Activity diagram of user.

The hub sites involved in the SPP are EEVL (based at Heriot Watt
University, Edinburgh), SOSIG (University of Bristol), HUMBUL (University
of Oxford); BIOME (University of Nottingham) and PSIGate (University of
Manchester). The project is managed from UKOLN based at the
University of Bath, and the technical development is led from ILRT at the
University of Bristol.

Distributed Development: The Problems

The fact that the SPP partners are geographically dispersed has posed a
number of challenges. Since the objective of the SPP is the enhancement
of the existing hub sites, hub representatives have naturally wished to be
closely involved, both on the technical and on the content management
sides of the project. At the last count, 38 people are involved in the
project, devoting to it varying percentages of their time. But this means
that physical meetings are difficult to organise and costly: since work
began in December 1999 on the SAD II project, only two full project
meetings have been held, with another planned for the beginning of
2003. Smaller physical meetings have been held by the technical
developers at ILRT and the five hubs, but these again are extremely
time-consuming.
We also faced the problem that many of the project partners had never
worked together before. Not only was this a challenge on a social level, it
was also likely to prove difficult to find where the skills and experience
(and software preferences) of the developers overlapped, and at the
beginning of 2002, the then project manager Julie Stuckes commissioned
a skills audit to discover the range and extent of these skills and where
the disparities lay. It was also likely to be hard to keep track at the
project centre of the different development activities taking place in order
to produce a single product, and to reduce the risk of duplicating effort,
or worse, producing incompatible work. We also thought moreover that it
was desirable to develop a method of describing the technical work
involved in the project in a way easily understood by the content
managers and non-technical people outside of the project.

The Solutions
We tackled the problem of communication across the project by the use
of a project JISCmail mailing list [2]. The list is archived on the private

version of the SPP Web site [3] where other internal documents are also
posted.
The developers have their own list (spp-dev@dev.portal.ac.uk) and
their own private Web site [4] which is stored in a versioning system
(CVS - Concurrent Version System [5]) which gives any authenticated
user the ability to update the site remotely.
In addition the developers hold weekly live chat meetings using IRC
(Internet Relay Chat [6]) software (as shown in Figure 1), the transcripts
of which are logged and archived on the developers' Web site.
Using IRC means the developers are able to keep each other informed of
their activities in a relaxed and informal manner; this has aided closer
working relationships.

As well as holding the developers' Web site, CVS also contains the
project's source code and build environment. This takes the form of a
central repository into and out of which developers check code remotely,
ensuring that their local development environments are kept in step. A
Web interface also provides the option of browsing the code, as well as
reviewing change histories. Automatic e-mail notification alerts the
developers to updates checked into the CVS repository, and all changes
are also logged. This has proved an essential tool when co-ordinating
distributed code development.
The other part of the software development infrastructure is providing a
build environment that takes care of standard tasks, allowing the team
members to concentrate on their coding. Using a combination of opensource tools (e.g. ant [7] and junit [8]) a system has been created that
allows the developer to build their code automatically, run tests against
it, and then configure and deploy it into their test server. As well as this,
the build system will also check for new versions of third-party packages
used by the project, updating them automatically if necessary. This
system is also managed by current project down from the central
repository, build, configure and deploy it, having it running in a matter of
minutes.
Because of the widely dispersed team, the difference in software
preferences and the mixed technical ability across the project, we looked
around for a design process that would best record and standardise our
requirements. UML (Unified Modelling Language [9]) is now a widely

accepted standard for object oriented modeling, and we chose it because

we felt it produced a design that is clear and precise, so making it easy to
understand for technical and non-technical minds alike. UML gave us a
means to visualise and integrate use cases, integration diagrams and
class models. Moreover using UML modelling tools, it was possible to
generate code from the model or update the model whenever the code
was further developed.

Figure 6: The UML Diagram

Finding UML software that had all the features needed was a problem:
there are plenty of products available but none quite met all our
requirements, especially when it came to synchronising the work being
done
by
different
authors.
Eventually
we
opted
to
use
the ICONIX process [10]. This is a simplified approach to UML modeling,
which uses a core subset of diagrams. This enabled us to move from use
cases to code quickly and efficiently using a minimum number of steps,
thus giving the technical side of the project a manageable coding cycle.
Additional funding was obtained from the JISC in order to bring one of
the authors of the ICONIX process (Doug Rosenberg) over from California
to run a three day UML training course. Although this course was
specially designed for SPP, places were offered to other 5/99 projects in
order to promote wider use of this methodology across the JISC
community. Unfortunately, despite early interest, no other project was
represented at the training, although Andy Powell, the technical coordinator for the RDN, attended the course. Additional funding was also
received from the JISC to purchase licences for Rational Rose [11],
which we had identified as the most effective software available to
produce the design diagrams
Finally, to provide greater structure to the project, a timetable of
activities produced using MS Project is posted on the private project Web
site and is kept continually up to date. A message is posted to the project
mailing list to alert partners of any major changes to the timetable.

What We Would Have Done Differently

It would have been sensible for us to have adopted a process for
software development at an earlier stage in the project: it was perhaps a
need that we could have anticipated during the SAD I project phase.
Also, it is worth noting from our experiences that getting the
communications and technical support infrastructure in place is a job in
itself, and should be built into the initial planning stage of any large and
dispersed project.

Continuing Problems
Electronic communication is still no substitute for face-to-face meetings
so the SPP development team continue to try to meet as regularly as

possible. Time is inevitably a major problem wherever project partners

have other work commitments: all the project partners based at the hub
sites have to juggle SPP work which is for the project as a whole, with
that which relates particularly to their own hub's adoption of the project's
outcomes. Increasingly, as the project develops, less work will be
required from the project "centre" and more at the hubs, leading to an
eventual handover of the subject portal developments to the hubs for
future management.

The Future
It is our plan to make use of UML diagrams in the final project
documentation to describe the design and development process. They
will offer a detailed explanation of our decision making throughout the
project and will give future projects an insight into our methodology.
Andy Powell was also so impressed with UML that he is planning to use it
across development work for the RDN in the future.
The future development of the SPP beyond the end of the project is likely
to be led by the technical development partners, for instance in the
continued development of the portlets to enable them to be installed into
alternative open source software platforms to make the technology as
compatible with existing systems as possible. It is therefore greatly to
the benefit of the project that they have become such an effective and
close working team.

References:
1. Subject Portals Project, RDN,
<http://www.portal.ac.uk/spp/documents/>
2. Archives of SPP Mailing List, JISCMail,
<http://www.jiscmail.ac.uk/archives/spp.html>
3. RDN portal development project, RDN,
<http://www.portal.ac.uk/spp/private/> (Note username
and password required)

4. dev.portal.ac.uk,
<http://dev.portal.ac.uk/>
5. CVS - Concurrent Versions System,
<http://www.gnu.org/software/cvs/>
6. Internet Relay Chat (IRC),
<http://www.irchelp.org/>
7. ant, Apache,
<http://jakarta.apache.org/ant/>
8. junit - Testing Resources for Extreme Programming,
<http://www.junit.org/>
9. UML,
<http://www.uml.org/>
10.
ICONIX,
<http://www.iconixsw.com/>
11.
Rational Rose,
<http://www.rational.com/products/rose/>