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 don’t have to worry that it’s 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 item1. Customer sets item on counter.2. Sales clerk swipes UPC reader across UPC code on
item.3. System looks up UPC code in database procuring item
description and price.4. System emits audible beep.5. System announces item description and price over
voice output.6. System adds price and item type to current invoice.7. System adds price to correct tax subtotal.
Error case 1: UPC code unreadableIf after step 2, the UPC code was invalid or was not properly read, emit an audible ‘bonk’ sound.
Error case 2: No item in databaseIf 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
StructuralView
ImplementationView
BehavioralView
EnvironmentView
User View
Activity DiagramsSequence DiagramsCollaboration DiagramsState Machine DiagramsInteraction Overview Diagrams
Composite Structure DiagramPackage DiagramsObject DiagramsClass Diagrams
Component Diagrams
Deployment Diagrams
Use Case Diagrams
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
But getting more means putting more in
GAPModel Code
Level 0
Level 1
Level 2
Level 3
Level 4
Level 5
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 don’t 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 aren’t sufficient to drive much of anything. Use cases are a good technique to document behavioral requirements but that’s only a small part of the functional requirements picture and an even smaller part of the total requirements picture – they aren’t very good at documenting business rules, user interface requirements, constraints, or non-functional requirements. [Ambler]
References
[Fowler] Fowler, Scott, UML Distilled 2nd Edition, Addison-Wesley
[Jacobson] Jacobson, Booch, Raumbaugh, The Unified Software Development Process, Addison-Wesley
[Ambler] Scott Ambler, www.agile-modeling.com
[Kruchten] Philippe Kruchten, Architectural Blueprints—The “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/
Top Related