1. Use Case Model
Use case diagram – Part 2

2. Use Case Diagram Other Types of Relationships for Use Cases
Generalization
Include
Extend
Inheritance

3. Components of Use Case Diagram
Generalization Relationship
Represented by a line and a hollow arrow
From child to parent
Inheritance
A use case generalization shows that one use case is simply a special kind of another.
A clinic may have a use case such as Pay Bill which would be a parent use case and Bill Insurance which is the child.
A child can be substituted for its parent whenever necessary.
Generalization appears as a line with a triangular arrow head toward the parent use case.
Child use case
Parent use case

4. Example of Relationships
System Boundary
Use cases are enclosed within a system boundary
a box that represents the system and clearly delineates what parts of the diagram are external or internal to it
Name of the system can appear inside or on top of the box

5. Relationships between Use Cases
Include - use cases that are included as parts of other use cases. Enable to factor common behavior.
Extend - use cases that extend the behavior of other core use cases. Enable to factor variants.

6. Includes and Extends Includes Extends base included base extending
You have a piece of behavior that is similar across many use cases
Break this out as a separate use- case and let the other ones “include” it
Examples include
Valuation
Validate user interaction
Sanity check on sensor inputs
Check for proper authorization
Extends
A use-case is similar to another one but does a little bit more
Put the normal behavior in one use- case and the exceptional behavior somewhere else
Capture the normal behavior
Try to figure out what can go wrong in each step
Capture the exceptional cases in separate use-cases
Makes it a lot easier to understand
base
included
<<include>>
base
extending
<<extend>>
05-Use-Cases

7. Use Case Diagram Include Relationship
Represents the inclusion of the functionality of one use case within another
Arrow is drawn from the base use case to the used use case
Write << include >> above arrowhead line
Include relationship
Notice that ONLY between use cases (not between actors)
MANDATORY functional
Multiple use cases may share pieces of the same functionality
Rather than have duplicate functionality in several use cases
Put shared functionality in one use case and show relationship between it and other use cases that “uses” its functionality
Depicted by arrowhead with word “<<include>>” above it
Include relationships factor use cases into additional ones.
Includes are especially helpful when the same use case can be factored out of two different use cases.
If a clinic had a cases of Make Appointment and Request Medication.
Both might include Check Patient Record as a subtask.
Both would include a call to the use case Check Patient Record.
We don’t want to write it twice we simply want to include in as a call from both.
In the diagram,
include notation is a dotted line beginning at base use case ending with an arrows pointing to the include use case.
The dotted line is labeled <<include>>.

8. Use Case Diagram Extend relationship
Represents the extension of the use case to include optional functionality
Arrow is drawn from the extension use case to the base use case
Write << extend >> above arrowhead line
Use Case Relationship
Extend relationship
Used to show optional behavior (behavior that is run only under certain circumstances)
Depicted by arrowhead with word “<<extend>>” above it
An extend relationship indicates that one use case is a variation of another.
This is often used when much of the same code may be in both only one extends the functionality somewhat.
A typical example is a add record to the database and modify that record.
So an add student is similar to a modify student so I may reuse some of the code.
Extend notation is a dotted line, labeled <<extend>>, and with an arrow toward the base case.
The extension point, which determines when the extended case is appropriate, is written inside the base case.

9. Example of Relationships
System Boundary
Use cases are enclosed within a system boundary
a box that represents the system and clearly delineates what parts of the diagram are external or internal to it
Name of the system can appear inside or on top of the box

10. Examples Include Extend <<include>> Purchase Item Verify
Credit card
<<include>>

11. Benefits of Use Cases
Use cases are the primary vehicle for system requirements.
Use cases are described using the language of the customer (language of the domain which is defined in the glossary)
Use cases provide an easily-understood communication mechanism
When requirements are traced, they make it difficult for requirements to fall through the cracks
Use cases provide a concise summary of what the system should do at an abstract (low modification cost) level.

12. Difficulties with Use Cases
As functional decompositions, it is often difficult to make the transition from functional description to object description to class design.
Since UCs do not talk about classes, developers often wind up in a vacuum during object analysis, and can often wind up doing things their own way, making reuse difficult
Use Cases make stating non-functional requirements difficult (where do you say that X must execute at Y/sec?)

13. Use Case Description Complements Use Case Diagram
A breakdown of a single use case (e.g., sequence of steps included in the function “Look up item availability”); process logic included
In contrast to Use Case Diagram, Use Case Description captures variations of a Use Case
Example: “Create new order” can be done via phone+clerk and via Internet ordering – 2 scenarios

14. Level of Use Case Description
Three levels of details:
UC* Brief description
Summary of what system does in response to actor’s actions
UC Intermediate description
Shows steps in use case, if-then
UC Full description
Includes Brief description, expands intermediate description, shows scenarios
* UC=Use Case

15. Brief Description of Use Case
Same description that is usually captured in initial
Use Case Diagrams

16. Intermediate Use Case Description
Telephone Order Scenario for Create New Order Use Case

17. Full Use Case Description
Shows steps (“Flow of Events”) broken down to the actor and the system side – useful!

18. Use Cases Basics A use case has four mandatory elements:
Name: Each use case has a unique name describing what is achieved by the interaction with the actor.
EX: "Turn Light On/Off" and "Print Document" are good examples.
Brief description: The purpose of the use case should be described in one or two sentences.
EX: "This use case controls the selected light bank when instructed by the actor Homeowner.“
Actor(s) List each actor that participates in the use case.
Flow of events: The heart of the use case is the event flow, usually a textual description of the interactions between the actor and the system.
The main (basic) flow of events
The alternate flows of events

19. Use Cases Basics Optional elements in a Use case:
Pre-conditions: Must be present in order for a use case to start. Represent some system state that must be present before the use case can be used.
EX: A pre-condition of the "Print Author's Manuscript Draft" use case is that a document must be open.
Post-conditions: Describe the state of the system after a use case has run. Represent persistent data that is saved by the system as a result of executing the use case.
EX: Post-condition of “Register" use case is that the new data is
added in the profile of the student.

20. Use Cases Basics
Other stakeholders: Other key stakeholders who may be affected by the use case.
EX: A manager may use a report built by the system, and yet the manager may not personally interact with the system in any way and therefore would not appear as an actor on the system.

21. A Recommended Template:
Use Case Description
System:
Use Case name:
Primary actor:
Other actors:
Stakeholders:
Description:
Relationships
Includes:
Extends:
Input:
Pre-conditions:
Steps:
Actor
System
1. Actor does.… 3. 4.
2. System does.…
Alternative and exceptional flows:
4.1 ….
Post-conditions: