1. Analyzing system processes: Use Case Diagram 2/2
Asper School of Business
University of Manitoba
Systems Analysis & Design
Instructor: Bob Travica
Analyzing system processes: Use Case Diagram 2/2

2. Relationships between Use Cases
<<includes>>
Include relationship between Use Cases (one UC must call another; e.g., Login UC includes User Authentication UC)
Pay online
Check balance
<<extends>>
Extend relationship between Use Cases (one UC may call another under certain conditions; think: if-then logic among system functions)

3. Include relationship
Include relationship – a standard UC linked to a mandatory UC.
Do something
(Process loan
application)
And run as part of
(Check credit history)
<<includes>>
Example: to Authorize Car Loan (standard use case),
a clerk must run Check Client’s Credit History (include use case).
BUT, do not imply sequential logic (process thinking)!
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

4. Reading use case diagram with Include relationship
Note: An “s” missing in “include”.
3510 Systems Analysis & Design * Bob Travica

5. Extend relationship
Extend relationship – associating an optional use case
to a standard use case.
Do if conditions
apply (reduce tuition fees for
University Staff actor)
Do something
(Register Course
Section)
<<extends>>
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 no fees or 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

6. UC relationships – warning!
Invoke UC relationship sparingly, only when necessary to show relationships (dependencies) between system functions.
Do not fall in a process trap - thinking about UCs as steps of a large process. UCs are system functions (each consisting of specific steps).
Note: UC diagram vs. Activity diagram
System
collapsed into
An activity diagram shows design of a
a system function in UC diagram, the
content of one oval.
3510 Systems Analysis & Design * Bob Travica

7. 3510 Systems Analysis & Design * Bob Travica
Process trap - Temptations with <<extend>> and <<include>>
Log in
<<extends>>
Lots of errors! Correction: One validation function included by
the function “Log in” and delete all other include and extend
relationships.
3510 Systems Analysis & Design * Bob Travica

8. How to create use case diagram
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 – if any (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