Introduction to Use Cases

1
Introduction to Use Cases

• One of the many tools within UML
• Supported by Select Enterprise software
• Used at the Feasibility and early Analysis stages
  of a project - to specify WHAT the system should
  do (not How - this comes later)
• Provide a catalyst for discussion with users

2
Use Cases - what for?

• Describe the functions of / processes within a
  system - the Use Cases
• Identify the boundary of a system
• Identify who and/or what uses the system - the
  Actors

3
Use Cases - approach

• Iteration - initially take a broad, top level
  view, then later add lower level detail
• as your investigation reveals more facts
• as you concentrate on specific areas
• Refinement - enable the Use Cases to evolve by
  correcting/improving previous iterations
• Document however little you know, then add to it.
  

4
Use Cases - format

• Diagrams are easy to assimilate
• Processes in ellipses
• Actors as stick-people
• Interactions as lines
• Text descriptions provide detail

5
Use Case - example
Watsons SalesWeb System
Report Sales
Salesperson
Accounting system
Review Individuals Sales
Inventory system
Review Regional Sales
Regional Sales Manager
(From Understanding UML, Harmon Watson)
6
Actors

• Include users and other systems
• an actor on a diagram a role
• 1 person/system may have 1 or more roles (i.e. in
  different interactions)
• 1 role may comprise 1 or more people
• by convention people are on left, systems on
  right

7
Processes

• Functions (initially the major ones only) within
  the system
• NOT departments in the organisation
• So the name must be a verb
• a system response may be a process with no actor
  involved

8
Interactions

• Where some exchange occurs between an actor and a
  process
• may be in either direction
• the detail of the interaction need not be known
  at this stage
• can be labelled/named

9
Finding the Actors and Use Cases

• Use appropriate fact-finding techniques
  (interviewing, questionnaires, observation,
  document inspection, )
• Identify all users, then the processes they
  initiate or participate in.
• Identify all external events to which the system
  must respond, then relate to actors and processes.

10
Exercise

• Manually draw a Use Case diagram for a video
  rental shop
• start with a top-level view
• add more detail after
• When completed put the diagram into Select
  Enterprise

11
Special Relationships between Use Cases

• Normally it is not necessary to identify
  interactions between use cases (too much detail
  for this stage)
• However the functionality of a use case can
  sometimes be split up into modules by
• extends
• uses

Sept 1999
K.Ingram J.Westlake
12
The Extends relationship

• If 2 use cases are similar but 1 does more than
  the other, can you identify some common
  functionality?
• If so, consider putting the common functionality
  in 1 use case and the extras in a second - the
  second then extends the first.

13
Example of Extends

• If your customer tries to pay for a rented video
  but has forgotten their wallet, you may put the
  video behind the counter until they return with
  the money.
• This is an extension to the normal use case of
  Pay for video
• to bundle it up with the usual situation will
  clutter up the logic

14
Example of Extends
Pay for video
Customer
ltltextendsgtgt
No money
15
Identifying Extends relationships

• 1. Document the normal, simple use case
• 2. identify what could go wrong?
• 3. identify how may it work differently?

16
The Uses relationship

• Do 2 (or more) use cases have a chunk of
  identical functionality?
• If so, consider extracting the common
  functionality from both and putting it in another
  use case - this can then be used by each of the
  others.

17
Example of Uses

• If a customer asks for a particular video the
  assistant checks where the copies are. If the
  manager is doing stock checks this may include
  finding where specific titles are.
• to include it in each of the original cases means
  you would have to handle it twice in your UML, to
  code it twice, to test it twice,.

18
Example of Uses
Request video
Customer
ltltusesgtgt
Locate video
ltltusesgtgt
Check stock
Manager
19
When is a Use Case not a Use Case?

• A use case is a function required of the system
  being considered (no need to document functions
  outside our remit).
• a use case can normally be broken down into many
  steps - do NOT show each individual step as a
  separate use case.
• A use case can be carried out at One Time, in One
  Place, by One Person (OTOPOP).

20
One diagram or many?

• Too much on a diagram negates its purpose
• You may decide it all fits on 1 diagram or you
  may decide to split the diagram
• 1 diagram for each actor
• or 1 diagram for each main business activity
• Splitting the diagram mean a Use Case or an Actor
  may be shown more than once.

21
Use Case Descriptions

• The text to describe a particular use case
  interaction - in the form of a 2-way dialogue
  between the actor and the system
• provides the supporting detail for the use case
  diagram - not to be started until the diagram is
  complete/nearly complete
• also known as Use Case Scripts or Use Case
  Scenarios (beware - the latter has another
  meaning)

22
What to describe

• Describe the most common/normal form of
  interaction first - the basic course
• Describe possible variations separately - the
  alternative courses
• The script should be in a conversational style
• actor requests.
• System responds by.
• Actor does..
• Etc..

23
Example of a Use Case Description

• In the video rental shop, the interaction between
  Counter Assistant and Rent Video use case may be
• Actor Actions System Response
• 1. Customer tenders video(s) to be
• rented and membership card
• 2. Counter assistant enters member 3. System
  provides member details and
• no.into system status of loans and fines
• 4. Assistant enters identification of each
• video to be rented 5. System accepts ids and
  gives fee payable
• 6. Assistant requests payment, takes
• money and enters payment made 7. System logs
  payment details

24
Guidelines

• Include a series of numbered sections or steps
  which describe noteworthy events and possibly
  related context, constraints and business rules
• steps may alternate between actor and system, or
  may be a series of consecutive steps taken by
  either of them
• written from the users point of view
• consist of users vocabulary

25
Conversational Style

• This conversational style script (as if for a
  theatre play) is a good compromise between the
  advantages and disadvantages of other methods
• it is quick and easy to write (important for
  capturing early, outline information)
• it is quick and easy to read and to understand
• it encourages concise-ness
• it identifies the required sequence of actions
• it highlights causes and effects

26
Styles of Description

• In addition to the conversational style script,
  there are other ways of describing the
  interactions e.g.
• unstructured narrative
• structured English
• decision tree
• decision table

27
Unstructured Narrative

• A text description of what happens in standard
  English sentences.
• Advantages
• easy to write
• Disadvantages
• easy to include ambiguity,
• lengthy both to read and to check,
• does not highlight cause and effect
• does not highlight sequence of actions

28
Example of Narrative Description

• How long does it take to understand this
  narrative

29
Structured English

• A text description of what happens but using a
  limited range of phrases.
• Advantages
• concise
• eliminates ambiguity
• highlights sequence of actions
• Disadvantages
• does not highlight cause and effect
• may use phrases which are unfamiliar to some users

30
Examples of other Methods of Description

• How long does it take to understand this using
• Structured English
• You may also like to look at
• a Decision Tree
• a Decision Table

31
Essential Use Cases

• These are used during the feasibility and
  analysis stages of the project.
• The aim is to be free of implementation detail to
  show the essence of the business requirements
  (the conceptual model).
• Enables analysts, developers, users and clients
  to understand the scope of the problem and the
  processes required

32
Real Use Cases

• Now the Essential Use Cases will be used as the
  basis for lateral, creative thinking with the
  opportunity for new ideas on how create the
  system.
• Real Use Cases are used to document the design of
  the project i.e. how it will work in reality.
• For a user interface it may include prototype
  screen shots, print layouts, form layouts, menus.
• For a system interface it may include file
  layouts.

33
Templates

• Here is a template for documenting the scripts
  (uctempbl.rtf)
• Here is an example use case script on the
  template for just the basic course of processing
  (uctempex.rtf)

34
Template Sections

• Use Case - its identifier/name
• Actors - list of actors involved. Show which one
  initiates the use case
• Overview - short outline description summarising
  the use case
• Type - category of the use case
• Cross References - use case relationships
  (covered later)

35
Categories of Use Cases

• 1. Primary - major common process e.g. Rent Video
• 2. Secondary - minor or rare processes e.g.
  Request to supply unstocked New Video
• 3. Optional - processes that may or may not be
  used

36
Alternative Courses

• Alternative courses can describe alternative
  events to the typical story. These are the less
  common, the exceptional or error cases.
• Place all the alternatives after all the typical
  course of events e.g.
• 7. Customer pays clerk by cash or credit
• Alternative Courses
• 7. Customer has unpaid late charges and will not
  pay them. Collect payment or cancel rental
  transaction
• sample use case script with alternative courses

37
Summary

• Use Case descriptions supply the detail of system
  requirements
• Conversational scripts are used to describe the
  interactions between actors and use cases
• The basic course may be followed by 1 or more
  alternative courses
• Essential Use Cases are used during Analysis,
  Real Use Cases are used during Design