Software Engineering

UML – CHAPTER 2
Use Cases

B. Wakim
 Outline

 Use case diagrams

 What is a use case diagram
 Association and Generalization relations

 Extends end Include relations

 Examples of use cases

07/11/2020 I3301- BWAKIM 2

 Use Case Diagrams

 Means of capturing requirements

 Document interactions between user(s) and the system
 User (actor) is not part of the system itself

 But an actor can be another system

 Actors may represent roles played by users of the system

or other systems.
 An individual use case represents a task to be done with
support from the system (thus it is a ‘coherent unit of
functionality’)

07/11/2020 I3301- BWAKIM 3

 Use Case Diagrams

 A use case is a single unit of meaningful work. E.g.

login, register, place an order, etc.
 Each Use Case has a description which describes
the functionality that will be built in the proposed
system.
E.g. for use case “order title” , a brief description:
This use case receives orders from employee or
supervisor, then return the ordered title.

07/11/2020 I3301- BWAKIM 4

 Use-Case Diagrams
Boundary Use Case
Actor Library System

Borrow Employee
Client

Order Title

Return Book

Supervisor

07/11/2020 I3301- BWAKIM 5

 Use-Case Diagrams

 A use-case diagram is a set of use cases

 A use case is a model of the interaction between
 External users of a software product (actors) and
 The software product itself
 More precisely, an actor is a user playing a specific role
 A use-case is use for:
 describing a set of user scenarios
 capturing user requirements
 contract between end user and software developers

07/11/2020 I3301- BWAKIM 6

 Use-Case Diagrams
 Actors: A role that a user plays with respect to the system, including
human users and other systems. e.g., inanimate physical objects (e.g.
robot); an external system that needs some information from the
current system.

 Use case: A set of scenarios that describing an interaction between a

user and a system, including alternatives.

 System boundary: rectangle diagram representing the boundary

between the actors and the system.

07/11/2020 I3301- BWAKIM 7

 Use Case Diagram with Multiple Actors

07/11/2020 I3301- BWAKIM 8

 Use Cases

 Are actually defined as text, including

descriptions of all of the normal and exception
behavior expected
 Do not reveal the structure of the system
 Collectively define the boundaries of the system
to be implemented
 Provide the basis for defining development

07/11/2020 I3301- BWAKIM 9

Use-Case Diagrams:
Association - Generalization
 Association:
communication between an actor and a use case; Represented by a solid line.

 Generalization: relationship between one general use case and a special use
case (used for defining special alternatives) Represented by a line with a
triangular arrow head toward the parent use case.

07/11/2020 I3301- BWAKIM 10

Extension relationships among
actors

07/11/2020 I3301- BWAKIM 11

Use-Case Diagrams:
Include – Extend relations

Include: a dotted line labeled <<include>> beginning at base use

case and ending with an arrows pointing to the include use case.
The include relationship occurs when a chunk of behavior is similar
across more than one use case. Use “include” in stead of copying the
description of that behavior.
<<include>>

Extend: a dotted line labeled <<extend>> with an arrow toward

the base case. The extending use case may add behavior to the base
use case. The base class declares “extension points”.
<<extend>>

07/11/2020 I3301- BWAKIM 12

 Use-Case Diagrams:
Include – Extend relations

A Use Case may be included by one or more Use Cases,

so it reduces duplication of functionality.
Example: the <list orders> Use Case may be included
every time when the <modify order> Use Case is run.

Used when exceptional circumstances are encountered.

For example, the <get approval> Use Case may
optionally extend the regular <modify order> Use Case.

07/11/2020 I3301- BWAKIM 13

EXAMPLES OF USE CASE DIAGRAMS

07/11/2020 I3301- BWAKIM 14

Use-Case Diagram: Tax preparation

07/11/2020 I3301- BWAKIM 15

 Use-Case Diagram: Medical appointment

 Both Make
Appointment and
Request Medication
include Check Patient
Record as a subtask
(include)

 The extension point is

written inside the base
case Pay bill; the
extending class Defer
payment adds the
behavior of this extension
point. (extend)

 Pay Bill is a parent use

case and Bill Insurance
is the child use case.
(generalization)

07/11/2020 I3301- BWAKIM 16

 Use Case Diagram: Place an order

07/11/2020 I3301- BWAKIM 17

 Use case description : Scenario

 Each use case must me described by a tetual

Scenario defining:
 Goal or objective of the use case
 Actors: concerned by this use case
 Pre-condition: need to enter this use case
 Description: of the use case rules and
scenario
 Post-conditions: What happened once the
use case is implemented
07/11/2020 I3301- BWAKIM 18
Use case Diagram: Car Rental

07/11/2020 I3301- BWAKIM 19

 Details for Use Case create customer

 Use case name: create customer

 Goal: to create a new customer
 Precondition: the real world customer to be
recorded is currently not represented
 Description: the user enters the information
needed to create a new customer.
 Post-condition: a new customer exists
 Actors: user

2013-2014 INFO401 - BWAKIM 20

 Details for Use Case create car

 Use case name: create car

 Goal: to create a new car
 Precondition: the real world car to be
recorded is currently not represented
 Description: the user enters the information
needed to create a new car.
 Post-condition: a new car exists
 Actors: user

2013-2014 INFO401 - BWAKIM 21

Details for Use Case book

 Use case name: book

 Goal: to enter a car rental booking
 Precondition: the booking details has to be entered
 Actors: user
 Description: the real world customer wants to rent
a real world car of a certain category:
 start day of the rental is the current day or a day after
the current day;
 end day of the rental lies after the start day
 Post-condition: a new booking exists; the booking
is now an open booking

2013-2014 INFO401 - BWAKIM 22

Details for Use Case cancel

 Use case name: cancel

 Goal: to prevent that a car must be picked up for a
booking
 Pre-condition:
 a real world customer requests a cancelation of an existing
booking
 the start day of a booking is passed and no car has been
picked up by the customer for that booking
 Actors: user
 Description: The system will cancel the booking by
updating cancel_date.
 Post-condition: the booking is marked as closed; no car
will be picked up for this booking

2013-2014 INFO401 - BWAKIM 23

Details for Use Case pickUp

 Use case name: pickUp

 Goal: to deliver a car for a car rental
 Precondition: a booking is present
 Actors: user
 Description: a suitable car must be found among
the currently available cars;
 if none is present, a new car may be added (a new
real world car is purchased)
 Post-condition: a suitable car is marked as
unavailable (a real world car is given to a real world
customer); the booking becomes a current booking

2013-2014 INFO401 - BWAKIM 24

 Details for Use Case return
 Use case name: return
 Goal: to return a car for a car rental
 Precondition: a current booking exists and a car has
been delivered
 Actors: user
 Description:
 early return: a rented car is returned before the end
date of the booking
 late return: a rented car is returned after the end date
of the booking
 Post-condition: the booking becomes closed; the car
becomes available

2013-2014 INFO401 - BWAKIM 25