In part 1 of this tutorial we discussed why
business professionals would want to model systems and how UML is intended to
fit that role. If you have not yet read part 1,
please do so before reading part 2.
UML Diagramming
For the purpose of this introduction to UML, we focus on three types of
diagrams which are largely the purview of analysts in the discovery phase of a
project. These are generalized diagrams leaving out many details so a larger
picture can be established.
If you are new to UML diagrams, the initial lack of detail may feel
disconcerting. However, later in the process the technology team will extend the
documentation with more complex UML diagrams and detailed system specifications.
By avoiding unnecessary complexity at the outset of a project, the business
analysts are free to focus their attentions on a system's capabilities.
Therefore, the primary goals of the business analyst's diagrams are:
1. Firmly establish the boundaries of the system
2. Identify all the actors and objects involved in the system
3. Identify the most important activities performed within the system
Use Case Diagrams
We begin with the most simplistic diagram, the use case, which is the initial
effort to identify the system boundary and interaction between the system and
actors. Use cases may also be referred to as user interaction or scenario
diagrams since they attempt to identify the actors performing particular
activities important to the system.
For this tutorial, we use the following example of a small grocery store that
would like to computerize their cash registers: "A shopkeeper scans each
product a customer would like to buy into a register which totals them up and
prints a receipt. The customer pays the amount on the receipt and takes their
items." Our initial use case diagram might look like the following:
Without any explanation, this use case diagram has understandable qualities and
if shared with a group of stakeholders would immediately spark a discussion. One
benefit of use case diagrams are their simplicity and ability to allow many
stakeholders to quickly come to a common understanding about the framework of a
system.
Use
cases are the ovals in the diagram, and represent scenarios. Use cases
encapsulate some behavior or interaction of interest to the system and may be
developed in more detail later (using different models. Actors are depicted with
stick figures. An actor is a person (or sometimes an object) that initiates the
events in a scenario. In the picture at the left a customer places their items
on a conveyer belt and later pays the receipt. The lines between customer, the
belt and the receipt are communication.
The key aspect of this system is that it is simple yet complete. It is simple
because the system is reduced to its most basic functions and complexity such as
payment methods; customer reward programs, etc are avoided at this level. This
additional complexity can be captured in Use Case diagrams that break the
payment system into sub-systems. We also say this diagram is complete because at
the highest level of the system view it has completely captured the system from
the customer's perspective.
Uses
cases attempt to define a system, which can be named for later reference, and
placed inside of a boundary. The boundary is important because it defines the
limits of a system. For example, the customer may interact with this system, but
they are not part of the system. Interaction between actors and use cases is
called a communication (depicted by a line between them). For example, the item
on the belt interacts with the cash register (by moving items to the register to
be scanned). The cash register and the receipt are related but the belt does not
interact with the receipt printer.
One last concept (though not a hard rule of Use Cases) is the sequence of
events. In general, when the sequence of events is important to the system, we
depict passage of time by ordering events from top to bottom. Not all systems
require capturing the sequence of Use Cases and order would be unimportant.
In modeling a system, it is common to develop several use case diagrams,
analogous to different points of view with many viewpoints needed to fully
visualize a system. Developing use cases is also an iterative process, and as a
new diagram is developed, relationships that were not obvious become clear. This
iterative process of system modeling is typical of collaborative teamwork and
involves modifying earlier cases as new understanding and awareness of a system
arises.
Sequence Diagrams
A sequence diagram contains more detail on the sequence of events by
detailing how actors and objects in the system interact. Sequence diagrams are
organized according to time from top to bottom of a diagram. The actors and
objects involved in the operation are listed from left to right and communicate
with messages. Below is a sequence diagram for a transaction in our grocery
store.
The actor initiating the sequence of messages is the customer who places their
items on the conveyer belt. As depicted, messages may be between actors and
objects or by an object to itself. For example, notice the cash register sending
messages to itself to add an item to the receipt, print the receipt and open the
cash drawer.
An
activation bar indicates when an actor or object is participating in a scenario.
In the example at the left, we see the conveyor belt is inactive until the
customer places an item on the belt. Once all items have been advanced, the
belt's job is finished and it is no longer active. The objects or actors used in
a sequence diagram usually come from one or more Use Case diagrams. But the
sequence diagram may also introduce new objects and additional levels of detail
and should not be limited to just what was experessed in a Use Case. For
example, this diagram introduces a new sensor object responsible for detecting
when an item is placed onto the conveyor belt.
Deployment Diagrams
The
physical representation of hardware in a system is modeled using a deployment
diagram. Boxes (or nodes) represent equipment components and each component
belongs on a node. Like the other diagrams, lines connecting boxes indicate a
form of communication between components. While UML uses only boxes, other
modeling software have graphical icons which may better depict the components of
a system.
Summary
This tutorial has introduced the UML modeling language for business analysts
and explained why UML is beneficial for the discovery phase of a project by
helping identify system boundaries, actors and interaction. We have also
introduced UML notations for developing use case, sequence and deployment
diagrams which business analysts can easily understand and use to model and
document a system.
References
1. Krichten, Philippe. The Rational Unified Process, An Introduction,
Addison-Wesley, 2001.
2. Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling
Language, Addison-Wesley, 2000.
3. Embarcadero Technologies, Inc. Practical UML:
A Hands-On Introduction for
Developers, 12/30/2008.
4. Object Management Group, Inc.
Introduction to
OMG's Unified Modeling Language� (UML�), , 12/31/2008.
5. Jackson, Daniel. A Direct Path to Dependable Software,
Communications of the ACM, Vol 52, April 2009.