Intro to UML - Use Case diagrams

UML Behavioral Modeling Diagrams Use Case diagrams Jerry Myong

Use Cases
For analysts who want to model user and system interactions.
Define behavior, requirements and constraints in the form of scripts or scenarios.
Use Case Model
Captures the requirements of a system.
Communicates with users and other stakeholders what the system is intended to do .
Components
Actors - external entities are referred to as actors.
Represent roles which may include human users, external hardware or other systems.
Usually drawn as a named stick figure, or alternatively as a class rectangle with the «actor» keyword.
Use cases - a single unit of meaningful work
Provides a high-level view of behavior observable to someone or something outside the system.
Notation for a use case is an ellipse.
Uses connector - connecting line with an optional arrowhead showing the direction of control (refer to “System Boundary” diagram below)
May have multiplicity (e.g., 0 .. 1, 0 .. *) values at each end

Use Cases
Use case typically includes:
Name and description - Normally named as a verb-phrase and given a brief informal textual description.
Requirements - Define the formal functional requirements that a use case must supply to the end user.
Correspond to the functional specifications found in structured methodologies.
Requirement is a contract or promise that the use case will perform an action or provide some value to the system.
Constraints - Condition / restriction that a use case operates under and includes pre and post conditions.
Pre - Conditions that need to be met before the use case can proceed.
Post - Conditions that must be true after execution of the use case.
Scenarios - Formal description of the flow of events that occur during the execution of a use case instance.
Defines the specific sequence of events between the system and the external actors.
Normally described in text
*Corresponds to the textual representation of the sequence diagram .
“ Included” Use Case
A reference to an included use case has the following syntax:
[condition_statement] “include” use_case_name
The included use case describes a lower-level goal (more detailed) than the base use case.
Every step in a use case is written as sentence about a goal that succeeds.
If the goal is broken out into its own use case, then the step "calls" the sub-use case, or it "includes the behavior" of the "included" use case.
The verb phrase part of that sentence is the name of a potential sub-use case (“Included” Use Case).

Use Cases
“ Extending” Use Case
A base use case can have several extension points
Each extension point has a unique name that identifies one or several locations in the behavior sequence of the base use case
Extension point – is where an extending use case is added
Marker in the logic of a base use case indicating where extension is allowed
Example: “Extension points: <step #>: Use case <#> <Use case name>
In the figure below, the name of the extension is listed in the Extension Points compartment of the base use case

Use Cases
“ Inherits” Use Case (realizes Generalization Relationship) In UML modeling, a generalization relationship is a relationship in which one model element (the child) is based on another model element (the parent).
Generalization relationships are used in use case diagrams (as well as class, component, deployment diagrams)
“ Inherits” Use Case – “ A generalization relationship between use cases implies that the child use case contains all the attributes, sequences of behavior and extension points defined in the parent use case, and participates in all the relationships of the parent use case” ---- Writing Effective Use Cases, A. Cockburn, 1999

Use Cases
Base Course of Action - “Use the ATM”
Included Use Case – “Withdraw Cash”
An arrow goes from the base use case to the included use case, signifying that the base use case "knows about" the included one
Use the stereotype of <<include>> on a dependency relationship
<<include>> dependency can be viewed as:
Invocation of a use case by another one
Same idea of a function call or invoking a method
Use <<include>> dependencies whenever one use case needs the behavior of another

Use Case diagrams
Extending Use Case - “Spell Check”
Use an arrow going from the extending use case back to the base use case
Signifies that the extending use case "knows about" the base use case
The reverse of the "includes" relation.

Use Case diagrams
Extending Use Case
Extension Points - point at which an extending use case is added
Marker in the logic of a base use case indicating where extension is allowed. (stereotype <<extend>> marks extension use case)
Why use them?
Conceptually inserts additional action sequences into the base use-case sequence
Picks up the course of behavior, and when done, deposits the actor back at the point (extension) in the base use case that got interrupted.
Just a scenario extension that outgrew the use case in which it was embedded.
Alistair Cockburn recommends: “Don't use extension use cases, unless you have a really good reason. If you do use them, absolutely don't expose the extension points in the use case diagram.” ---- Writing Effective Use Cases, A. Cockburn, 1999

Use Case diagrams
“ Inherits” Use Case - “Do one transaction” (parent)
Inheriting use case would completely replace one or more of the scenarios (paths) of the “parent” use case
Good test phrases for any "generalized" concept is "generic" or "some kind of".
If you find yourself describing a generic interaction (or actor), then you have a candidate for "generalizes”; “inheritance” principle

Use Case diagrams
System Boundary - Usual to display use cases as being inside the system and actors as being outside the (ATM) system.

Use Case Guidelines (by Alistair Cockburn)
Reminders
Write something readable
Casual, readable use cases are still useful, whereas unreadable use cases won't get read
Work breadth-first, from lower precision to higher precision
Precision Level 1: Primary actor's name and goal
Precision Level 2: The use case brief, or the main success scenario
Precision Level 3: The extension conditions
Precision Level 4: The extension handling steps
For each step
Show a goal succeeding
Capture the actor's intention , not the user interface details
Have an actor pass information , validate a condition , or update state
Write between-step commentary to indicate step sequencing (or lack of)
Ask "why" to find a next-higher level goal (lower precision)

Use Case Guidelines (by Alistair Cockburn)
For data descriptions:
Precision Level 1: Data nickname
Precision Level 2: Data fields associated with the nickname
Precision Level 3: Field types, lengths, and validations

Use Case Writing Process (by Alistair Cockburn)
Name the system scope
Brainstorm and list the primary actors
Find every human and non-human primary actor, over the life of the system
Brainstorm and exhaustively list user goals for the system
Select one use case to expand
Consider writing a narrative to learn the material
Write the main success scenario (MSS)
Use 3 to 9 steps to meet all interests and guarantees
Brainstorm and exhaustively list the extension conditions
Include all that the system can detect and must handle
Write the extension-handling steps
Each will end back in the MSS, at a separate success exit, or in failure
Extract complex flows to sub use cases; merge trivial sub use cases
Extracting a sub use case is easy, but it adds cost to the project
Readjust the set: Add, Subtract, Merge, as needed

Questions?
Use Case diagrams

A little Quiz! 
Q1. The “Use Case Model” captures the requirements of a system, by communicating with users and other stakeholders in (choose best answer):
How the system is supposed to work.
What the system will do for the users.
What the system will do for stakeholders.
What the system is intended to do.
Q2. In regards to <include> use cases, use <<include>> dependencies whenever one use case needs the ______ of another.
Q3. Think of an <<include>> dependency as an ________ of a use case by another one – same idea of a function call or invoking a method:
Inclination
Intoxication
Invocation
Annihilation
Q4. In regards to <<extends>> use cases, one use case may be used to _______ the behavior of another.
Q5. In regards to “inheriting” use cases, the inheriting use case would completely _______ one or more of the courses of action of the inherited use case.
Q6. In regards to a System Boundary, it is usual to display use cases as being _______ the system and actors as being _______ the system.
Q7. An extending use case, conceptually inserts additional action ________ into the ________ use-case sequence
Q8. “Spell Check” is an example of what type of use case?
Q9. “Withdraw Cash” is an example of what type of use case?
Q10. For each use case step: Capture the actor’s __________, not the user interface details.
Q11. When writing the main success scenario (MSS), use 3 to 9 steps to meet all ________ and _________.

Quiz Answers!
Q1. The “Use Case Model” captures the requirements of a system, by communicating with users and other stakeholders in (choose best answer):
How the system is supposed to work.
What the system will do for the users.
What the system will do for stakeholders.
What the system is intended to do.
Q2. In regards to <include> use cases, use <<include>> dependencies whenever one use case needs the _ behavior _ of another.
Q3. Think of an <<include>> dependency as an ________ of a use case by another one – same idea of a function call or invoking a method:
Inclination
Intoxication
Invocation
Annihilation
Q4. In regards to <<extends>> use cases, one use case may be used to __ extend __ the behavior of another.
Q5. In regards to “inheriting” use cases, the inheriting use case would completely __ replace __ one or more of the courses of action of the inherited use case.
Q6. In regards to a System Boundary, it is usual to display use cases as being _ inside _ the system and actors as being _ outside _ the system.
Q7. An extending use case, conceptually inserts additional action _ sequences _ into the _ base _ use-case sequence
Q8. “Spell Check” is an example of what type of use case? Extends
Q9. “Withdraw Cash” is an example of what type of use case? Inherits or Includes
Q10. For each use case step: Capture the actor’s _ intention _, not the user interface details.
Q11. When writing the main success scenario (MSS), use 3 to 9 steps to meet all _ interests _ and _ guarantees _.

Intro to UML - Use Case diagrams

by jsm1979

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

Intro to UML - Use Case diagrams Presentation Transcript