njit 1 use cases chapter 6 applying uml and patterns craig larman
Post on 21-Dec-2015
229 views
TRANSCRIPT
![Page 1: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/1.jpg)
1
NJIT
Use Cases
Chapter 6
Applying UML and Patterns
Craig Larman
![Page 2: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/2.jpg)
2
Define the Problem
The most critical question: “Is this the right system to make?”
![Page 3: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/3.jpg)
3
Use Case Relationships
Domain Model
Use Case Model
Interaction DiagramsDesign
Requirements
Business Model
Objects, attributes, associations
VISION
GLOSSARY
SUPPLEMENTARYSPECIFICATION
![Page 4: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/4.jpg)
4
Use Cases are not Diagrams
Use Cases may have a diagram associated with them, and a use case diagram is an easy way for an analyst to discuss a process with a subject matter expert (SME).
But use cases are primarily text. The text is important. The diagram is optional.
![Page 5: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/5.jpg)
5
Emphasize Goals
Investigating goals rather than tasks and procedures improves information gathering by focusing on the essence of requirements—the intent behind them.
Seeing requirements as identifying tasks to be done has a strong bias toward reproducing the existing system, even when it is being replaced because it is seriously defective.
![Page 6: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/6.jpg)
6
Why Use Cases?
Simple and familiar storytelling makes it easier, especially for customers, to contribute and review goals.
Use cases keep it simple (KISS) They emphasize goals and the user
perspective. New use case writers tend to take them too
seriously.
![Page 7: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/7.jpg)
7
Actors or Use Case First?
Because you have to understand each part of Use Cases, the parts are presented separately. But those who create use cases switch back and forth. The text describes use cases substantially before paying attention to actors. Typically, both actors and use cases are identified early and then examined to see if more use cases can be found from the actors, or more actors found by examining the use cases.
![Page 8: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/8.jpg)
8
Identify Use Cases
Capture the specific ways of using the system as dialogues between an actor and the system.
Use cases are used to Capture system requirements Communicate with end users and Subject
Matter Experts Test the system
![Page 9: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/9.jpg)
9
Specifying Use Cases
Create a written document for each Use Case Clearly define intent of the Use Case Define Main Success Scenario (Happy Path) Define any alternate action paths Use format of Stimulus: Response Each specification must be testable Write from actor’s perspective, in actor’s
vocabulary
![Page 10: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/10.jpg)
10
www.usecases.org Template
Name Primary Actor Scope Level Stakeholders and
Interests Minimal Guarantee Success Guarantee Main Success Scenario Extensions
This is the basic format used in the text and in Alistair Cockburn’s Writing Effective Use Cases (Addison Wesley, 2000, ISBN 0201702258).
I prefer to modify it slightly to use the actor actions and system response in tabular form. Larman calls this the Two-Column Variation.
![Page 11: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/11.jpg)
11
Optional Items
You can add some of the following items Trigger (after Success Guarantee)
(at end:) Special requirements Technology and Data Variations Frequency of Occurrence Open Issues
![Page 12: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/12.jpg)
12
Elements in the Preface
Only put items that are important to understand before reading the Main Success Scenario. These might include:
Name (Always needed for identification) Primary Actor Stakeholders and Interests List Preconditions Success Conditions (Post Conditions)
![Page 13: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/13.jpg)
13
Naming Use Cases
Must be a complete process from the viewpoint of the end user.
Usually in verb-object form, like Buy Pizza Use enough detail to make it specific Use active voice, not passive From viewpoint of the actor, not the
system
![Page 14: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/14.jpg)
14
Hint
Appropriate use case names are very important. Because they are selected early, they tend to set the direction for the entire project.
Most common errors in use case diagrams are poor names, showing procedures instead of complete user processes, and not including the boundary and system name.
Rational Rose does not show the boundary and name, so assignments turned in using that tool do not have to have them. Rational Rose is preferred for assignments.
![Page 15: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/15.jpg)
15
Golden Rule of Use-Case Names
Each use case should have a name that indicates what value (or goal) is achieved by the actor's interaction with the system
Here are some good questions to help you adhere to this rule: Why would the actor initiate this interaction
with the system? What goal does the actor have in mind when undertaking these actions? What value is achieved and for which actor?
From Dr. Use Case (Leslee Probasco) in the Rational Edge, March, 2001
![Page 16: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/16.jpg)
16
Use Case Name Examples
Excellent - Purchase Concert Ticket Very Good - Purchase Concert Tickets Good - Purchase Ticket (insufficient detail) Fair - Ticket Purchase (passive) Poor - Ticket Order (system view, not user) Unacceptable - Pay for Ticket (procedure,
not process)
![Page 17: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/17.jpg)
17
CRUD
Examples of bad use case names with the acronym CRUD. (All are procedural and reveal nothing about the actor’s intentions.)
C - actor Creates data R - actor Retrieves data U - actor Updates data D - actor Deletes data
![Page 18: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/18.jpg)
18
Singular or Plural
This is usually determined by context. There is a preference for the simplest form, but
most common form can be better. In the example of concert tickets, most people
buy more than one, but a significant number buy only one.
At a supermarket, Buy Items would be best. At a vending machine, it would be Buy Item.
![Page 19: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/19.jpg)
19
Identify Actors
We cannot understand a system until we know who will use it Direct users Users responsible to operate and maintain it External systems used by the system External systems that interact with the system
![Page 20: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/20.jpg)
20
Specifying Actors
Actors are external to the system Actors are non-deterministic What interacts with the system? Actors may be different roles that one
individual user interacts with the system Actors may be other systems Don’t assume that Actor = Individual
![Page 21: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/21.jpg)
21
Types of Actors
Primary Actor Has goals to be fulfilled by system
Supporting Actor Provides service to the system
Offstage Actor Interested in the behavior, but no contribution
In diagrams, Primary actors go on the left and others on the right.
![Page 22: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/22.jpg)
22
Define Actors
Actors should not be analyzed or described in detail unless the application domain demands it.
Template for definition: Name Definition
Example for an ATM application:
Customer: Owner of an account who manages account by depositing and withdrawing funds
![Page 23: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/23.jpg)
23
Identifying Actors
Primary Actor Emphasis is on the primary actor for the
use case. Stakeholders and Interests
Other actors are listed as stakeholders. The interests of each key actor should
be described.
![Page 24: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/24.jpg)
24
Working with Use Cases
Determine the actors that will interact with the system
Examine the actors and document their needs
For each separate need, create a use case
During Analysis, extend use cases with interaction diagrams
![Page 25: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/25.jpg)
25
Preconditions
Anything that must always be true before beginning a scenario is a precondition.
Preconditions are assumed to be true, not tested within the Use Case itself.
Ignore obvious preconditions such as the power being turned on. Only document items necessary to understand the Use Case.
![Page 26: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/26.jpg)
26
Success Guarantees
Success Guarantees (or Postconditions) state what must be true if the Use Case is completed successfully. This may include the main success scenario and some alternative paths. For example, if the happy path is a cash sale, a credit sale might also be regarded a success.
Stakeholders should agree on the guarantee.
![Page 27: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/27.jpg)
27
Scenarios
The Main Success Scenario, or “happy path” is the expected primary use of the system, without problems or exceptions.
Alternative Scenarios or Extensions are used to document other common paths through the system and error handling or exceptions.
![Page 28: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/28.jpg)
28
Documenting the Happy Path
The Success Scenario (or basic course) gives the best understanding of the use case
Each step contains the activities and inputs of the actor and the system response
If there are three or more items, create a list Label steps for configuration management and requirements
traceability Use present tense and active voice Remember that User Interface designers will use this
specification
Note: Do not use the term “happy path” in formal documents.
![Page 29: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/29.jpg)
29
Extensions (Alternative Flows)
Extensions or Alternative Flow Use Cases allow the specification of Different ways of handling transactions Error processes
Sections are convenient way to handle alternative courses of action Sections are a segment of a use case
executed out of sequence
![Page 30: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/30.jpg)
30
Two Parts for Extensions
Condition Describe the reason for the alternative
flow as a condition that the user can detect
Handling Describe the flow of processing in the
same manner as the happy path, using a numbering system consistent with the original section.
![Page 31: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/31.jpg)
31
Documenting Extensions
Use same format as Happy Path Document actions that vary from ideal path Include error conditions Number each alternate, and start with the
condition:3A. Condition: If [actor] performs [action] the system … If subsequent steps are the same as the happy
path, identify and label as (same) Steps not included in alternate course are
assumed not to be performed.
![Page 32: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/32.jpg)
32
Special Requirements
If a non-functional requirement , quality attribute, or constraint affects a use case directly, describe it as a special requirement.
![Page 33: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/33.jpg)
33
Technology and Data Variations List
Often there are technical differences in how things are done even though what is done is the same. These things can be described in the Technology and Data Variations List.
For example, if a card reader cannot read the magnetic stripe on a credit card, the cashier might be able to enter it on the keyboard.
![Page 34: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/34.jpg)
34
Types of Use Cases
The most common Use Cases are High Level Use Cases and Expanded Essential Use Cases in analysis, and Expanded Real Use Cases in design. The next slide gives definitions.
In addition, Use Case diagrams may be used in discussions with stakeholders while capturing their requirements.
![Page 35: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/35.jpg)
35
Elaborating Use Cases
High Level Use Case (Brief) Name, Actors, Purpose, Overview
Expanded Use Case (Fully Dressed) Add System Events and System Responses
Essential Use Case (Black Box) Leave out technological implications
Real Use Case (White Box) Leave in technology
![Page 36: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/36.jpg)
36
Note on Nomenclature
Use cases have been widely adopted in industry, and the descriptive names have changed frequently. It is a good idea to be familiar with the alternative names (expanded vs. fully dressed) (high level vs. brief)
Also, the technology is rapidly evolving, and it is necessary to keep up.
![Page 37: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/37.jpg)
37
Defer Decisions
By using essential use cases as long as possible, and only using real use cases during module design, you allow time to understand the problem before you create a solution. Premature use of real use cases often confirms existing technology when a better technology might be available.
![Page 38: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/38.jpg)
38
Technology The distinction between an essential (black
box) use case that leaves out technology and a real (white box) use case that includes technology is fundamental.
For example, in an Automated Teller Machine, an essential use case can mention identification or validation, but only a real use case can mention a key pad or card reader.
![Page 39: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/39.jpg)
39
Expanded Essential Use Cases(Fully Dressed Use Cases)
Purpose: to allow the system designer and client to visualize the flow of actor
actions and system responses. From this the client will understand how users will use the system, and the designer will be able to write pseudocode for each function. In addition, it is possible to use this document to anticipate opportunities for user error, which must be accounted for in the final system.
Definitions: What it is: an analysis document which describes in detail the
elements of functions identified in a High Level Use Case. What is is not: Expanded Essential Use Cases are not graphical
drawings. They do not include stick figures, boxes representing the system, or any other icons found in a High Level Use Case although they may be associated with one.
![Page 40: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/40.jpg)
40
Expanded EssentialUse Cases
How to make one: Step 1: Name the Use Case (system function, e.g. “enter
timesheet information”). Step 2: Identify the Actor(s) involved. Step 3: Describe the Intent of the Use Case in language the client
will understand. Step 4: Identify the Assumptions and Limitations relevant to this
Use Case and other Use Cases which the current one might extend or build upon.
Step 5: Specify the ideal flow of actions using two columns labeled “Actor Actions” and “System Responses.” Number each step. This constitutes the Happy Path for this Use Case.
Step 6: Identify opportunities for user error and create an Alternative Path to handle each.
![Page 41: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/41.jpg)
41
Note (from page 68 of text)
The example on pages 68-72 of the text of a fully dressed use case is very detailed and contains just about everything you could put into a use case. It is that detailed mainly for instructional purposes.
Almost all use cases are much smaller, usually a page or two.
![Page 42: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/42.jpg)
42
Postconditions
Postconditions (or success guarantees) state what always must be true for a use case to succeed. Avoid the obvious, but clearly document any that are not obvious. This is one of the most important parts of a use case.
![Page 43: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/43.jpg)
43
Conditions and Branching
Stick to the “Happy Path,” “Sunny Day Scenario,” Typical Flow, or Basic Flow (all names for the same basic idea) in the main section and defer all conditional sections and branching to the extensions or alternate flows.
![Page 44: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/44.jpg)
44
Segmentation
When a use case is repeated, you don’t want to repeat the contents
For example, an alarm clock might show the same display when you are setting the current time and when you are setting the wake-up time
Separate out the “Display Time” use case and refer to it in both use cases
![Page 45: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/45.jpg)
45
Extension Use Cases
Users appreciate simplicity, so most use cases leave out alternate courses
You can do this by extending the use case while leaving the original use case alone
![Page 46: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/46.jpg)
46
Warning
Use cases should not be misused to imitate function specification by successive iteration
Don’t refine them until the program is fully specified
The uses relation should only be used when the same scenario is encountered more than once
![Page 47: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/47.jpg)
47
Feature Lists
Older methods of detailing requirements tended to have many pages of detailed feature lists. Usually the details could not be seen in context.
Current philosophy is to use a higher level of detail with use cases instead of a list.
High level System Feature Lists are acceptable when they can give a succinct summary of the system.
![Page 48: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/48.jpg)
48
Use Cases not an OO idea
Use Cases are not an Object-Oriented methodology. They are common in structured development as well.
However, the Unified Process encourages use-case driven development.
![Page 49: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/49.jpg)
49
Use case levels
User-goal level A complete process from the view point of a
user to meet a goal of the user, roughly corresponding to an elementary business process.
Subfunction level Details steps to support a user goal.
![Page 50: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/50.jpg)
50
Use-case driven development
Requirements are primarily recorded in the Use Case model.
Iterations are planned around implementing particular Use Cases.
Use Case Realizations drive design. Use Case often influence the way user
manuals are organized.
![Page 51: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/51.jpg)
51
Use Cases are always wrong!
Written documentation gives the illusion of authority and correctness, but it is an illusion.
Use cases give a preliminary understanding that users and developers can discuss and agree on.
But there should be constant feedback from customers in the development process to correct missing information and misinformation before it jeopardizes the functionality of the program.
![Page 52: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/52.jpg)
52
NJIT
Diagramming Use Cases
The text is the Use Case!
Diagrams may supplement the text or help during discovery.
![Page 53: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/53.jpg)
53
Overview
A use case diagram identifies transactions between actors and a system as individual use cases
Set Time
Set Current Time Set Alarm Time
SnoozeButton
Sound Alarm
Flash Display Ring Bell
Alarm Clock
Sleeper
Operator
![Page 54: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/54.jpg)
54
Actor An actor is an idealized
user of a system Actors can be users,
processes, and other systems
Many users can be one actor, in a common role
One user can be different actors, based on different roles
An actor is labeled with the name of the role
![Page 55: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/55.jpg)
55
Non-human Actor Actors can be users,
processes, and other systems.
Show non human actors in a different manner, usually as a rectangle
Non human actors are usually not primary users, and thus are usually shown on the right, not the left.
Inventory
System
![Page 56: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/56.jpg)
56
Use Case
A use case is a coherent unit of externally visible functionality provided by a system and expressed by a sequence of messages
Additional behavior can be shown with parent-child, extend and include use cases
It is labeled with a name that the user can understand
![Page 57: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/57.jpg)
57
System
A system is shown as a rectangle, labeled with the system name
Actors are outside the system
Use cases are inside the system
The rectangle shows the scope or boundary of the system
Don’t forget the boundary and the system name, unless you are using Rational Rose!
![Page 58: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/58.jpg)
58
Association Relationship
An association is the communication path between an actor and the use case that it participates in
It is shown as a solid line It does not have an arrow, and
is normally read from left to right
Here, the association is between a Modeler and the Create Model use case
![Page 59: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/59.jpg)
59
Relationships in Use Cases
There are several Use Case relationships:
Association Extend Generalization Uses Include
Most Use Cases have only associations. Use other relationships sparingly.
![Page 60: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/60.jpg)
60
Extend Relationship
Extend puts additional behavior in a use case that does not know about it.
It is shown as a dotted line with an arrow point and labeled <<extend>>
In this case, a customer can request a catalog when placing an order
![Page 61: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/61.jpg)
61
Use Case Generalization Generalization is a
relationship between a general use case and a more specific use case that inherits and extends features to it
It is shown as a solid line with a closed arrow point
Here, the payment process is modified for cash and charge cards
![Page 62: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/62.jpg)
62
Uses Relationship When a use case uses
another process, the relationship can be shown with the uses relationship
This is shown as a solid line with a closed arrow point and the <<uses>> keyword
Here different system processes can use the logon use case
![Page 63: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/63.jpg)
63
Include Relationship
Include relationships insert additional behavior into a base use case
They are shown as a dotted line with an open arrow and the key word <<include>>
Shown is a process that I observed in an earlier career
![Page 64: NJIT 1 Use Cases Chapter 6 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.us/reader036/viewer/2022062300/56649d5d5503460f94a3bdc8/html5/thumbnails/64.jpg)
64
Use Case Example: Alarm Clock
This is a contrivedexample, to showmany relations.Your diagrams
should be simpler.