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.


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.


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.


Add a comment

No comments, be the first to comment on this page

Enter your comment


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

Connecting Research with ConsultingThe goal of my consulting efforts is to improve strategic alignment between IT resources and business goals for client organizations. Better alignment has been shown to result in cost savings, productivity improvements, and greater organizational efficiency.Learn how IT Goveranance models can benefit your organization
To learn more, click here.
Starting a Business in the Service IndustryIf you are looking for a new career, chances are you will find the greatest opportunity in the services industry.
Service Business Opportunity

This article explains that in order to identify a viable service-business opportunity, it is important to find a niche that satisfies each of the following:
1. An unmet demand by the marketplace;
2. An area of expertise one is also passionate about;
3. A competitive advantage, usually the application of information technology.

Click here to read the article