Posted: September 13th, 2017

MIS 441;Systems Analysis and Design

For this assignment, you will need to use a visualization tool (e.g., MS Visio, LucidChart, or other UML diagramming tool).
MIS 441
Systems Analysis and Design
MODULE 3: Use Case, 15 points
Introduction
The use case model consists of a use case diagram, a set of use case descriptions, a set of
actor descriptions and a set of scenarios. The use case diagram models the problem
domain graphically using four concepts: the use case, the actor, the relationship link and
the boundary.
Using the Wheels Case Study, the UML symbols used to model these concepts are shown
in here (and also in Fig. 3-12, p. 81 of the textbook). USEC ASUSEDE IA CGASRESA M 41
Receptionist
System boundary
@
A use case: an ellipse labelled with the name of the use case.
Conventionally we start each use case name with a verb to make
the point that use cases represent processes. So we have
‘Maintain customer list’ rather than ‘Customer list’, ‘Handle
enquiries’ rather than ‘Enquiries’.
An actor: a stick figure labelled with the name of the actor. We
capitalize actor names so that they are easy to identify as such
(e.g. Administrator, Receptionist). The stick figure icon is used
even when the actor is non-human, e.g. another computer
system or an organization.
A use case relationship: a line linking an actor to a use case. The
line shows us which actors are associated with which use cases.
This relationship is also known as a communication association.
Receptionist
The boundary: a line drawn round the use
cases to separate them from the actors and to
delineate the area of interest. Can be labelled
to indicate the diagram domain. The boundary
is often omitted.
Figure 3.1 The UML symbols for use case diagrams
cases: ‘Maintain bike list’, ‘Maintain customer list’, ‘Handle
enquiries’, ‘Issue bike’ and ‘Handle bike return’. Conceptually a
use case diagram is similar to a top-level menu which lists the five
main things that the system does. Each use case is linked by a line
to an actor. The actor, represented by a stick figure, is the person
(sometimes a computer system or an organization) who uses the
system in the way specified in the use case or who benefits from the
use case.
Here is an example of a use case of the Wheels case study. The functionality of
the new system has been divided into five use cases: ‘Maintain bike list’,
‘Maintain customer list’, ‘Handle enquiries’, ‘Issue bike’ and ‘Handle bike
return’. Conceptually a use case diagram is similar to a top-level menu which
lists the five main things that the system does.
The Use Case
When identifying use cases, the task is to divide up the system’s functionality
into chunks, into the main system activities. What dictates the split is what the
user sees as the separate jobs or processes, i.e., the tasks he or she will do
using the system. There is no attempt in the use case model to achieve a
division of the system into logical software units; we are just attempting to
capture the user’s view of the system.
Identifying use cases from scenarios. Another approach to identifying use
cases is to start with scenarios. As mentioned in the Wheels case study, a
scenario describes a series of interactions between the user and the system in
order to achieve a specified goal. A scenario describes a specific sequence of
events, for example what happened when Annie successfully issued a bike to a
customer.
MIS 441 Page 2 of 10
Figure 3.1 The UML symbols for use case diagrams
Figure 3.2
cases: ‘Maintain bike list’, ‘Maintain customer list’, ‘Handle
enquiries’, ‘Issue bike’ and ‘Handle bike return’. Conceptually a
use case diagram is similar to a top-level menu which lists the five
main things that the system does. Each use case is linked by a line
to an actor. The actor, represented by a stick figure, is the person
(sometimes a computer system or an organization) who uses the
system in the way specified in the use case or who benefits from the
use case.
Admin~ist
Recep~fio
Use case diagram for Wheels
Each use case represents a group of scenarios. Scenarios belonging to the
same use case have a common goal, such that each scenario in the group
describes a different sequence of events involved in achieving (or failing to
achieve) the use case goal. The example below is a scenario belonging to the
‘Issue bike’ use case.
A use case is a complete end-to-end use of the computer, a complete path
through the system. A use case must deliver some benefit to the actor associated
with it; it must have a goal. Each use case will have several scenarios associated
with it. Some will be successful, i.e. achieve the use case goal, some will not.
The software developer needs to be aware of all possible scenarios because the
system must be able to cope with them all and respond appropriately.
Use Case Descriptions
The use case description is a narrative document that describes, in general
terms, the required functionality of the use case. Typically it describes the use
case goal and gives a general description of what usually happens, the normal
course of events, adding a brief description of any minor variations.
The description is written in terms of what the system should do, not how it
should do it. What happens behind the scenes in terms of coding, data storage
structures and other implementation details is not relevant in a use case
MIS 441 Page 3 of 10
things to happen in the new system. A careful study of scenarios
depicting both typical and exceptional uses of the system is a very
good way to understand what the system does and how it is used. It~ a
bottom up approach to understanding a system. You start by looking at
the details of how the system is used and from this work out what the
overall aims and objectives are and from this what the use cases are.
Each use case represents a group of scenarios. Scenarios
belonging to the same use case have a common g o a l – each scenario
in the group describes a different sequence of events involved in
achieving (or failing to achieve) the use case goal. Figures 3.3 and
3-4 describe scenarios belonging to the ‘Issue bike’ use case; in
both cases Annie is trying to issue a bike to a customer.
9 Stephanie arrives at the shop at 9.ooam one Saturday and chooses a mountain bike
9 Annie sees that its number is 468
9 Annie enters this number into the system
9 The system confirms that this is a woman~ mountain bike and displays the
daily rate (s and the deposit (s
9 Stephanie says she wants to hire the bike for a week
9 Annie enters this and the system displays the total cost s + s = s
9 Stephanie agrees this
9 Annie enters Stephanie~ name, address and telephone number into the system
9 Stephanie pays the s
9 Annie records this on the system and the system prints out a receipt
9 Stephanie agrees to bring the bike back by 9.ooam on the following Saturday.
Figure 3.3 Successful scenario for the use case “Issue bike”
9 Michael arrives at the shop at 12.oo on Friday
9 He selects a man~ racer
9 Annie see the number is 658
9 She enters this number into the system
9 The system confirms that it is a man~ racer and displays the daily rate (s and
the deposit (s
9 Michael says this is too much and leaves the shop without hiring the bike.
Figure 3.4 Scenario for “Issue bike” where the use case goal is not achieved
description, only what the user sees happening. In other words, the use case
describes the system as the user sees it.
High-level description. It is useful to have two distinct types of use case
description. In the early stages of software development, when no detailed
decisions have been made about the design of the system and particularly the
design of the user interface, it is enough to have short, unstructured
descriptions, known as high- level descriptions. These descriptions need only
document the purpose of the use case, the actors involved and give a general
overview of what happens. Here is an example:
Expanded use case description. This description is more detailed and
structured than the high-level use case description. (The textbook version in
Chapter 5 is called a “fully developed use case”.) It should document:
• What happens to initiate the use case (e.g., trigger)
• Which actors are involved
• What data has to be input
• The use case output
• What stored data is needed by the use case
• What happens to signal the completion of the use case
• Alternatives in the sequence of events (see below).
every sequence of events, every scenario, relating to the use case.
The description is written in terms of what the system should
do, not how it should do it. What happens behind the scenes in
terms of coding, data storage structures and other implementation
details is not relevant in a use case description, only what the user
sees happening. In other words, the use case describes the system
as the user sees it and does not aim to form the basis of a program
specification or provide information about the internal processes of
the system.
UML does not dictate any particular format for describing use
cases. Different practitioners use different methods. The best advice
is that we have a look at different techniques described by experts on
the subject and choose something that works for us. The standard we
will use in this book, which closely follows the style recommended
by Larman (1998), is illustrated in Figures 3-5 and 3.6.
High-level description. It is useful to have two distinct types of use
case description. In the early stages of software development, when
no detailed decisions have been made about the design of the
Figure 3.5 High-level description of the “Issue bike” use case
MIS 441 Page 4 of 10
The expanded use case description would then be presented as in the figure
below.1
48 A STUDENT GUIDE TO OBJECT-ORIENTED DEVELOPMENT
Figure 3.8 Expanded description of the “Issue bike” use case with preconditions
Actors and actor descriptions
Actors are external to the system- they represent people or things that
interact with the system and receive some benefit from it. Normally an
actor is a user, but sometimes it is another system such as a banking or
accounting system; an actor can also represent a hardware device such
as a printer. Typically an actor is someone who inputs information to
the system or receives information from it (or both).
1 A version of this template is available on Blackboard with Module 3
MIS 441 Page 5 of 10
Instructions
The goals for this assignment are to:
1. Determine use cases based on seven scenarios.
2. Based on these use cases, draw a use case diagram.
3. With new observations, revise the use case.
4. Develop an expanded use case descriptions
(A Word document template is attached with this module on Blackboard)
For this assignment, you will need to use a visualization tool (e.g., MS Visio,
LucidChart, or other UML diagramming tool).
Please submit your diagram in a PDF or Word format.
Background
James Barlow is a recently graduated software developer. He and his wife,
Caitlin, have just set up their own business, Barlow & Barlow. They have been
asked by a video rental company, View Us, to convert their rather antiquated
computer system to something more modern. Barlow & Barlow have decided
that an object-oriented system will be just the ticket. James has just spent a
morning rather nervously observing what goes on at View Us as customers and
employees go about their normal business. James jotted down the sequence of
events that he observed, hoping to make sense of it later.
1. James’ notes are written as a long undivided list of events. The following list
of events are separated into scenarios. Based on these scenarios,
determine the uses cases for each. For example, Scenarios 1 and 2 are
descriptions of sequences of events that occur in the ‘Loan a video’ use
case.
MIS 441 Page 6 of 10
Scenario 1. Use case: Loan a video Actor:
• Lucy comes into the shop
• She finds two videos she wants to borrow
• She takes the empty video covers to the counter and says she wants to
borrow them tonight
• She presents her membership card
• Phil, the assistant, finds the videos
• He scans the barcode on the membership card
• Lucy’s details come up on the screen
• Phil checks that Lucy still lives at 6 Privet Drive
• He sees that she has no videos outstanding and does not owe View Us
any money
• He scans the barcodes on the videos and hands them to Lucy takes
the money for the rental and says Lucy must return the videos by 8pm
the next evening
• Lucy leaves the shop with the videos
Scenario 2. Use case: Loan a video Actor:
• Ian comes into the shop
• He finds a video he wants to borrow for one night
• He takes the video case to the counter
• Phil asks for his membership card
• Ian says he isn’t a member but he’d like to become one
• Phil takes details of his name, address, telephone number and bank
account number and sort code
• He prints out a membership card for Ian
• He scans the video barcode
• Phil takes the money for the rental and says Ian must return the video
by 8pm the next evening
• Ian leaves with the video and his new membership card
MIS 441 Page 7 of 10
Scenario 3. Use Case: Actor:
• Rachel comes into the video shop with three videos she borrowed the
previous day
• She hands them to Phil
• Phil scans the video barcodes
• He checks that the videos are back in time and that
• Rachel doesn’t owe them any money
• Rachel leaves the shop
Scenario 4. Use Case: Actor:
• Hannah comes into the shop and says she wants to become a member
• Phil takes details of her name, address, telephone number and bank
account number and sort code
• He prints out a membership card for Hannah
• He asks Hannah if she wants to borrow a video now
• She says ‘No’
• She leaves with her new membership card
Scenario 5. Use Case: Actor:
• Andy comes into the shop with two videos to return
• The videos are a day late
• Phil is busy with another customer
• Andy puts the videos into the returned video box and leaves
• When Phil has finished with his customer he retrieves the videos and
scans the barcodes
• He notices that they are a day late and checks that the system has
registered this against Andy’s name
MIS 441 Page 8 of 10
Scenario 6. Use Case: Actor:
• Kim, the View Us manager, arrives with a box of new videos
• Phil and Kim sort through the videos allocating barcodes and prices:
newly released videos are more expensive to rent than older ones
• Kim enters the details of the new videos on to the system
Scenario 7. Use Case: Actor:
• Tony comes into the shop
• He chooses three videos
• Phil swipes his membership card
• He notices that Tony still has two videos out, they are three days overdue
• He says he cannot let Tony borrow any more videos until he returns
those still out.
2. Based on these 7 scenarios, draw a use case diagram to model what
happens at the video rental business, “ View Us”
James returns ten days later to View Us, this time accompanied by Caitlin.
While James discusses the use case diagram you drew in #2 with Kim,
Caitlin notices a customer complaining to Phil that all of the copies of the
video he wants to borrow are out on loan. Phil says that he can reserve that
video for the customer. On further enquiry she finds that reserving videos is
quite common.
What happens is that a video is marked on the system as reserved, then as
soon as any copy of that video is returned it is put under the counter and a
postcard is sent to the member who reserved it. When the reserving
member comes in he presents the postcard and is issued with the video in
the normal way.
3. Redraw your use case diagram incorporating this extra information.
MIS 441 Page 9 of 10
Scenarios 1 and 2 and 7 are all descriptions of sequences of events that can
happen in the ‘Loan a video’ use case. There are significant differences
between these sequences.
4. Write an expanded use case description that identifies a typical
sequence of events for the ‘Loan a video’ use case and incorporates
the differences as alternative courses.
MIS 441 Page 10 of 10