Introduction to Modeling with UML for the Business Analyst Part 2
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:

A Use Case diragram of a grocery store transaction

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.

A Use Case is simple yet completeUse 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.

Comments

Add a comment

No comments, be the first to comment on this page

Enter your comment

Name*  

Email*
(never shown)
 
Web Link  
Type in text*
you see below
Mouse here for help   
*required  

 
eBusiness Project ManagementNothing is more perilous than shepherding a technology project to completion. The fact that most technology projects do not end up delivering what they promised, are over budget or late should be motivation enough for any small business to carefully consider how the project will be managed before committing their hard-earned cash.
Successful eBusiness Project Management

This article describes proven techniques to help ensure the success of your project, such as:
  • Setting a budget
  • Monitoring progress
  • Customer centered scenarios
  • Dealing with scope creep
Click here to read
Modeling Systems in UMLSystems are a combination of hardware, software and peripherals collectively working in an environment where together they fulfill a need of those who use the system. Because there are often many intangible components, it is difficult to create an accurate representation or model of complex engineered IT systems.

This tutorial explains how to create UML diagrams of IT systems in language any business analyst will find easy to read and understand.