An Introduction to Use Case Modeling

Agenda

Requirements Use Cases Use Case Diagrams Use Case Scenarios Use Case Modeling with UML

Requirements
Look at how the traditional approach to requirements has
severely limited our ability to satisfy our customer and stabilize our work effort. Establish a requirement structure that will help ask the right questions and capture the information the Architects, Developers, Testers, and others will need. Recognize that requirements strategies for categorizing, relating and agreeing requirements can greatly minimize the risk for building the wrong product. Embrace the critical nature of a user-centric approach and employ techniques which keep user satisfaction at the center of our effort.

Who needs to understand the system?

Owners
To make sure they are getting the value they paid for Developers To make sure they know what to develop Testers To make sure they know what to test Managers To know where the system will be deployed

Technical Writers
To know how to document the system IT Operations/Support To know how to install and maintain the system Users To know how to use the system

Exercise: Requirements Review

Situation You have been handed these requirements, a deadline, and a budget. Exercise Break into groups of 3-4 people. Review the sample requirements document to become familiar with what the business wants to achieve. As you review, think about the requirements in the context of communication between the owners, developers, managers, testers, technical writers, IT operations, and users. As a group, mark problems in the requirements.

Use Cases Defined

In general, use cases are high-level, user-centric requirements. [Fowler] A use case specifies a sequence of actions, including variants, which the system can perform and that yields an observable result of value to a particular actor. [Jacobson]

Use Cases are: One of many techniques to elicit and elaborate user requirements. A common presentation of requirements for different roles. A handy unit of planning and estimation.

Advantages of Use Cases

Avoid analysis paralysis Use cases help break up the problem so it can be solved incrementally. Do just enough analysis to get started but we dont have to worry that its hard to come back later and add more. Avoid gold plating Using use cases to derive functional requirements avoids stating a functional requirement that is not directly tied to a user task needed to accomplish a business goal.

Use Case Diagrams

A cashier uses the POS system

to scan an item.

A cashier uses the POS system

to total items.

System Boundary
Marks off the system as
separate from its environment

Actors are outside When no system boundary is

shown, the system is assumed

Actor
Someone or something outside
the system that interacts with it

Actors represent roles not

individuals

Use Case
A use case achieves a goal of
value to an actor System does these things for actors What system is for not how it does it Starts with an active verb from the point of view of the system

Communications

Lines between Actor and Use Case summarize

interactions graphically Actors and use cases exchange information to achieve the goal but the details of interaction are not shown

Considerations for Use Case Diagrams

Do not represent the flow of information or sequence of
events. Do not represent communication between actors. Keep the focus on putting the system in context, not the actors. Actors may collaborate through a use case. Actors are not always roles played by a person. Actors may represent the role played by anything that acts on the system such as another system.

Use Case Diagram Summary

Show the system in its environment Show what a system is used for From a behavioral perspective:
For capturing functional requirements For enabling incremental specification To understand who the system is for

Details of interactions are not shown

Levels of Use Cases

Use Case Diagrams can be at different levels of granularity: One diagram can show a system-wide view with every actor This diagram can be later refined into design-level use cases

Use Case Analysis

When do we start use case analysis? During requirements elicitation
Obtain agreement on major concepts Actors, system boundaries, business use cases Maybe as a sketch, transfer to tool later

During requirements analysis

Insure the right questions have been asked and answered Supplement complex text with pictures Disambiguate text with precise models

When do we stop doing use case analysis? When the use cases meet the communication needs
Stakeholders reach consensus

Less is more

Exercise: Use Case Diagrams

Situation You want to put requirements into context with use cases. Exercise Break into groups of 3-4 people. Using the sample requirements document sketch an initial use case diagram. As you create the diagram, think about the interactions between the system and actors. As a group, consider how this level of use case analysis adds value to the existing requirements.

Scenarios
Scenario is another name for a
particular flow of events. A use case covers a range of situations a scenario is just one. Each use case typically has: a main flow describing the happy path alternate flows describing major exceptions Several alternatives exist for specifying the use case scenarios.

Describing Scenarios Textually

Write text to describe the
interaction of the actor(s) and the system. Simple and easy approach May be limiting: Numerous alternate flows make it hard to understand where normal flow can branch. Long alternate flows need to be broken out as steps too.
Use Case: Checks out item
1. Customer sets item on counter. 2. Sales clerk swipes UPC reader across UPC code on
item. System looks up UPC code in database procuring item description and price. System emits audible beep. System announces item description and price over voice output. System adds price and item type to current invoice. System adds price to correct tax subtotal.

3.
4. 5. 6. 7.

Error case 1: UPC code unreadable If after step 2, the UPC code was invalid or was not properly read, emit an audible bonk sound. Error case 2: No item in database If after step 3 no database entry is found for the UPC flash the manual entry button on the terminal. Accept key entry of price and tax code from Sales Clerk. Set Item description to Unknown item. Go to step 4.

Describing Scenarios Graphically

Create an Activity Diagram to
graphically show the interaction of the actor(s) and the system. Requires a little UML savvy Easy to slip into too much detail

Create a Sequence Diagram to

graphically show the interaction of the actor(s) and the system. Requires more UML savvy Great start for design activities

Exercise: Use Case Scenarios

Situation You want to elaborate an initial use case sketch with a scenario for one of the use cases. Exercise Break into groups of 3-4 people. Using the initial use case diagram, create a use case scenario. As a group, try both approaches. One person can try to capture the flow textually and another graphically.

Use Case Modeling with UML

In combination with plain text
Large volume of requirements difficult to consume as a whole Modeling provides constructs to help organize ideas Visualization helps clarify complex ideas Standards bring focus to key abstractions

In contrast to ad-hoc diagrams

Standards facilitate precise communication Common language for all members of the team

Reap the benefits of Model-Driven Development (MDD) Get ready for Model-Driven Architecture (MDA)

Use Case Diagrams as the Hub of Architectural Viewpoints

Structural View Implementation View
Component Diagrams

Composite Structure Diagram Package Diagrams Object Diagrams User View Class Diagrams Use Case Diagrams Activity Diagrams Sequence Diagrams Collaboration Diagrams State Machine Diagrams Interaction Overview Diagrams

Deployment Diagrams

Behavioral View

Environment View
Adapted from [Kruchten]

Formal UML Use Case Diagrams

Association

The line between an actor and a

use case is an association. The association means the actor is participating and/or communicating with the system via that use case.

The meaning of the association

can be refined with: Multiplicity Direction Labels

Multiplicity

Typically,
An actor will have up to one interaction with a given use case. A use case instantiation interacts with one and only one of a given actor. Previous to UML 2.0 this was the default association. There are cases where we have multiple interactions simultaneously.

Direction

Indicates who initiates the communication

Warning: does not necessarily indicate flow of information!

Labels
UML allows:
Labels for the association Labels for roles on each end Usage is uncommon and is not recommended

Specialization/Generalization of Actors

One actor can be a

specialization of another.

Arrow points to the more

general (base) actor.

Using Generalization

How Use Cases are Related to Each Other

Generalization
One use case is a special case of another

Includes
Included use case embodies common behavior

Extends
Extending use case adds behavior

Generalization

Shows inheritance and specialization One use case is simply a special kind of another

Includes

Factor out of a use case commonly used behavior Allows reuse of functionality by multiple use cases

Extends

Indicates that one use case adds or replaces behavior of another Must have a an associated extension point May have a condition

Exercise: Use Cases in UML

Situation You want to formalize the initial use case sketch as UML. Exercise Break into groups of 3-4 people. Using the initial use case diagram, create a formal UML use case diagram. As a group, try determine if there are opportunities for reuse with generalization, extends, or includes.

Getting More from Modeling

Modeling maturity levels:
Level 0: No specification Level 1: Textual Level 2: Text with Diagrams Level 3: Models with Text Level 4: Precise Models Level 5: Models only
GAP Model
Level 0 Level 1 Level 2 Level 3 Level 4

Code

Level 5

But getting more means putting more in

Use Case Behavior

Adapted from the Final Adopted Specification for the UML 2.0 Superstructure

Activity
Activity diagrams are an easy way
to represent the high-level flow of activity. Show how activities connect to one another in a process. Sequential or concurrent activities Often used to: model the flow of events in a use case model business processes model internal system processes

Not easy to tell who is responsible

for the behavior.

Interaction
Interaction diagrams help
capture who does what when Most popular way to show dynamic aspects of models. Reveal the details of message passing how objects respond to messages by delegating to others.

State Machine
Use case analysis often reveals
state-based behavior. When you hear status, think of a state machine. Exception flows may occur based on state. The user may operate directly on the state of something in the system.

Quotable Quotes on Using UML

The UML is a large and growing beast, but you dont need all of it. Martin Fowler when learning the UML, you need to be aware that certain constructs and notations are only helpful in detailed design while others are useful in requirements analysis UML needs to be used together with an effective process Brian Henderson-Sellers

A Parting Thought
The term use-case driven is a wonderful marketing term but the reality is that use cases arent sufficient to drive much of anything. Use cases are a good technique to document behavioral requirements but thats only a small part of the functional requirements picture and an even smaller part of the total requirements picture they arent very good at documenting business rules, user interface requirements, constraints, or non-functional requirements. [Ambler]

References
[Fowler] Fowler, Scott, UML Distilled 2nd Edition, AddisonWesley [Jacobson] Jacobson, Booch, Raumbaugh, The Unified Software Development Process, Addison-Wesley [Ambler] Scott Ambler, www.agile-modeling.com [Kruchten] Philippe Kruchten, Architectural BlueprintsThe 4+1 View Model of Software Architecture, IEEE Software 1995

Recommended Reading
Armour, Frank, and Granville Miller, Advanced Use Case Modeling: Software Systems, Addison-Wesley Charbonneau, Serge, Modeling Use Cases with the Borland Suite of Tools, BDN Cockburn, Alistair, Writing Effective Use Cases, Addison-Wesley Miller, Granville, Gathering Requirements: Use Cases, BDN Miller, Randy, Practical UML: A Hands-On Introduction for Developers, BDN Miller, Randy, What's New in UML 2? The Use Case Diagram, BDN Overgaard, Gunnar, and Karin Palmkvist, Use Cases: Patterns and Blueprints, Addison-Wesley BDN content can be found at http://bdn.borland.com/