Upload
ali-nguyen
View
2.983
Download
0
Tags:
Embed Size (px)
Citation preview
04/11/23 CSci 5802 Univ. of Minnesota 1
Use Cases and Use Case Diagram
04/11/23 CSci 5802 Univ. of Minnesota 2
A Use Case
Represents the functionality from the user’s point of view• Some sort of functionality interface to the users• Answer the question: How can the system
provide observable value to the users, or to fulfill their goals?
Represents the functional requirements Defines the boundaries of the system Written in natural language
• Advantages?• Disadvantages?
04/11/23 CSci 5802 Univ. of Minnesota 3
Description of a Use Case
Name Participating actors Flow of events Entry condition Exit condition Quality requirement
04/11/23 CSci 5802 Univ. of Minnesota 4
Example
Name: withdraw Participate actor: customer Flow of event:
1. Customer selects withdraw button 2. The system displays the withdraw screen, and initializes the input amount use case…
… Quality requirement: at any point during the flow
of events, this use case can include the cancel transaction use case. The cancel transaction use case is initialized when the cancel button is selected.
04/11/23 CSci 5802 Univ. of Minnesota 5
Organizing Flow of Events
Basic course of actions/major scenario Alternative course of actions
• Use to describe the branching Benefits of using such organization?
04/11/23 CSci 5802 Univ. of Minnesota 6
Scenario vs. Use Case
Scenario• An instance of a use case• Description of a concrete set of actions• Like an execution trace of a program• No branching, no entry condition, no exit
conditions (why?)• The focus is the understandability
Use case• An abstraction that describe all possible
scenarios involved in certain functionality• Like an algorithm• The focus is the completeness
04/11/23 CSci 5802 Univ. of Minnesota 7
Separation of Concerns
Decomposing use cases• Separating the common cases from the
exceptions and errors handling• Separating common functionality to avoid
redundancy To make decomposition work, relationships
among the use cases needs to be described• Include• Extend• Inheritance
04/11/23 CSci 5802 Univ. of Minnesota 8
Use-Case Diagram
A UML diagram that represents the relationship between actors and use cases, and among the use cases
Represents an “architectural” view of the requirements
04/11/23 CSci 5802 Univ. of Minnesota 9
Major Components
Actors• External entities (e.g., user role, another system)
Relationship between actors and use cases• Initiation• Communication
Relationship among different use cases• Enables the decomposition of complex use
cases into smaller ones
04/11/23 CSci 5802 Univ. of Minnesota 10
Use Case Diagram for E-homework management system
E-homeworkdistributionTA Students
E-homeworksubmission
E-homeworkgrading
04/11/23 CSci 5802 Univ. of Minnesota 11
Include Relationship
Use case A includes use case B if the flow of events for A contains the flow of events for B
A whole-part relationship Allow use case A to access another common
use case B
04/11/23 CSci 5802 Univ. of Minnesota 12
Representation
In use case description• At a particular point during the flow of events
• Mention the inclusion at that point• At any point in the flow of events
• Mention the inclusion in the quality requirement In the use case diagram
<<include>>
04/11/23 CSci 5802 Univ. of Minnesota 13
Example
<<include>>withdraw
Input amount
Cancel transaction
<<include>>
customer
04/11/23 CSci 5802 Univ. of Minnesota 14
When to Refactor Using Include Relation When a particular flow of events is
repeatedly described in more than on use cases• Purpose of refactoring: reduce redundancy
When a particular flow of events corresponds to a concept in the problem domain• Purpose of refactoring: improving the
understandability When the description of a use case is too
long• Purpose of refactoring: improving the
understandability
04/11/23 CSci 5802 Univ. of Minnesota 15
Example from “Patterns for Effective Use Cases”
04/11/23 CSci 5802 Univ. of Minnesota 16
04/11/23 CSci 5802 Univ. of Minnesota 17
04/11/23 CSci 5802 Univ. of Minnesota 18
04/11/23 CSci 5802 Univ. of Minnesota 19
Extension Relation
A use case A extends a use case B if the flow of events in A can occur amid the flow of events in B when certain condition is true
It is like an “interrupt” It is used to separate the exceptional
behavior from the normal behavior• Advantage?
04/11/23 CSci 5802 Univ. of Minnesota 20
Representation
Use case description• Mentioned extension in the entry condition in
the extending use case• Specifying the condition that would trigger the
extending use case Use case diagram
<<extend>>
04/11/23 CSci 5802 Univ. of Minnesota 21
Example
Connectiondown
Deposit
withdraw
<<extend>>
<<extend>>
Name: connection down…Entry condition: This use case extends the Deposit and withdraw use case. It is initialized by the system whenever the connection between the customer and the central sever is lost.
04/11/23 CSci 5802 Univ. of Minnesota 22
Comparing include and extend
Similarity• They are equivalent: both are mechanisms for
composing two use cases to describe a functionality
Difference• The major difference is the location of the
triggering conditions• Suppose that A and B together describe a
functionality– A includes B when A has the triggering condition for B: in
this case, A has to know about B– B extends A when B has the triggering condition for B: in
this case, A does not need to know about B
04/11/23 CSci 5802 Univ. of Minnesota 23
Include vs. Extend
<<include>
A B
<<extend>>
A B
Move triggering condition for B fromA to B
Move triggering condition for B fromB to A
Guideline: judge to see whether the triggering condition for B is an integral part of A or an integral part for B.
04/11/23 CSci 5802 Univ. of Minnesota 24
Example: Why extend is better than include here?
Connectiondown
Deposit
withdraw
<<extend>>
<<extend>>
Name: connection down…Entry condition: This use case extends the Deposit and withdraw use case. It is initialized by the system whenever the connection between the customer and the central sever is lost.
04/11/23 CSci 5802 Univ. of Minnesota 25
Inheritance Relationship
It represent specialization or conceptual classification
A specialized use case can inherit the participating actor, entry and exit conditions, and some courses of actions from the base use case• Enable polymorphism from the client’s
perspective Inheritance can be used to simplify the use
case diagram
04/11/23 CSci 5802 Univ. of Minnesota 26
Representation
Description• Mention the inheritance of various descriptions
from another use case • Participating actor• Entry/exit conditions• Different courses of actions
Diagram
Authenticatewith finger
Authenticate
with passwd
Authenticate
04/11/23 CSci 5802 Univ. of Minnesota 27
Example
Name: Authenticate with passwordParticipating actor: Inherited from Authenticate use caseFlow of events:
….Entry condition: Inherited from Authenticate use caseExit condition: Inherited from Authenticate use case
04/11/23 CSci 5802 Univ. of Minnesota 28
What we’ve learned
Use cases and use case diagrams Factoring and organizing use cases using
“include”, “extend”, and “inheritance” relationships
Question: • Are these relationships enough for organizing
the use cases?