Asper School of Business
University of Manitoba
Systems Analysis & Design
Instructor: Bob Travica
Updated 2014







The use case concept
Business events and systems
Elements of use case diagram
Include and Extend relationships between use cases
Reading use case diagrams
Creating use case diagrams
3510 Systems Analysis & Design * Bob Travica 2

• Use case is a model of system functionality.
• Think of main functions a system performs for users – “cases” of using a system.
Use case
Use Case
Diagram of
Order-Entry
Subsystem for RMO
Figure 6-3
3

• Use Case helps to model system requirements
• Easier for users to understand than other diagrams
3510 Systems Analysis & Design * Bob Travica 4

• A stimulus that requires a system’s response
• Delineated in time; stands on its own
External events occur outside the system
Temporal Events
“clerk calls up customer account”
Figure 5-2
Events affecting a payment system that determine what system has to do – functions, use cases
5


External Events (outside an IS)

Caused by external agent (human, system)

Temporal Events ( inside an IS)

Occur at a certain point in calendar time


State Events ( inside an IS)

Changes in system states, such as data
Event: QuantityOnHand =< ReorderAmount (QOH goes under a min.)
System’s response: Create new purchase order
Internal events - logic of automated decisions
3510 Systems Analysis & Design * Bob Travica 6

Input Output
Figure 5-10
3510 Systems Analysis & Design * Bob Travica 7

• Actor is someone interacting with use case
(system function). Named by a noun.
Name
• Similar to the concept of user, but
(a) can be non-human and
(b) a user can play different roles ;
(e.g.,: an employee can be worker and manager – plays 2 roles in a system*).
System
• System
• Shape of oval, contains small ovals that stand for use cases (system functions)
3510 Systems Analysis & Design * Bob Travica 8

• Actor triggers (initiates, starts) use case (a system function).
•Actor has responsibility toward the system (inputs), and
Actor has expectations from the system (outputs).
• System has responsibility to respond properly to events
– to execute an appropriate function.
3510 Systems Analysis & Design * Bob Travica 9 of 14

Do something

System function (process – automated or manual).
Named by a v erb.

Each Actor must be linked to a UC, while some use cases may not be linked to actors (e.g., functions responding to temporal events, UC related to another UC).
= Use Case
3510 Systems Analysis & Design * Bob Travica 10

Connection between Actor and Use Case
Boundary of system
Relationships between Use Cases
<<include>>
Include relationship between Use Cases (one UC must call another; e.g., Login UC includes User Authentication UC)
<<extend>>
Extend relationship between Use Cases (one UC may call another under certain conditions; think: if-then decision points)
3510 Systems Analysis & Design * Bob Travica 11

• Include relationship – a standard UC linked to a
mandatory UC. includes
Do something
And do as part of
Do something
• Example: to Authorize Car Loan (standard use case), a clerk must run Check Client’s Credit History (include use case).
• The standard UC includes the mandatory UC (use the verb to figure direction arrow).
• Standard use case can NOT execute without the include case  tight coupling .
• Note: Visio calls this “uses” relationship.
3510 Systems Analysis & Design * Bob Travica 12

3510 Systems Analysis & Design * Bob Travica 13

• Extend relationship – linking an optional use case to a standard use case.
extends
Do something
Do if conditions apply
• Example: Register Course (standard use case) may have
Register for Special Class (extend use case) – class for non-standard students, in unusual time, with special topics, requiring extra fees…).
• The optional UC extends the standard UC
• Standard UC executes without the extend UC; an extend UC executes instead of standard UC.  loose coupling.
3510 Systems Analysis & Design * Bob Travica 14




Invoke them sparingly, only when necessary to show connections between system functions.
Do not fall in a functions.
process trap - thinking about
UCs as steps of a process. UCs are system
Note: UC diagram vs. Activity diagram
System
3510 Systems Analysis & Design * Bob Travica 15 of 14

<<extends>>
Log in
<<extends>>
<<extends>> Overdraft
WDL
<<extends>>
3510 Systems Analysis & Design * Bob Travica 16 of 14

1. List main system functions (use cases) in a column:



 think of business events demanding system’s response users’ goals/needs to be accomplished via the system
Create, Read, Update, Delete (CRUD) data tasks
Naming use cases – user’s needs usually can be translated in data tasks
2. Draw ovals around the function labels (use cases)
3. Draw system boundary
4. Draw actors and connect them with use cases (if more intuitive, this can be done as step 2)
5. Specify include and extend relationships between use cases
(yes, at the end - not before, as this may pull you into process thinking, which does not apply in UC diagramming).
3510 Systems Analysis & Design * Bob Travica 17