www.analisi-disegno.com - Use Cases: an Introduction

1
Use Cases an Introduction

• Adriano Comai 1999

2
Goals of this Introduction

• To provide basic information about use cases
• To provide suggestions about their use in
  application development
• These points are treated in more depth, with
  exercises, in the course Requirements and Use
  Cases Definition
• http//www.analisi-disegno.com/a_comai/corsi/sk_re
  q.htm

3
Use Cases

• Proposed by Ivar Jacobson (book published in
  1992)
• New terminology, but a long practised technique
  (study of operational scenarios of system usage)
• Use cases are the ways in which a system can be
  used (the functions which the system provides to
  its users)

4
Use Case Point of View
A use case describes a function from the point of
view of its users

• It starts usually with a request from an actor to
  the system
• It ends with the production of all the answers to
  the request
• It defines the interactions (between system and
  actors) related to the function

The point of view to take into account must be
the actors, not the one of the system
5
Use Cases vs (Internal) Functions

• Use Cases
• call someone
• receive a call
• send a message
• memorize a number
• .
• Point of view USER

• Internal Functions
• transmit / receive
• energy (battery)
• user I/O (display, keys, ...)
• phone-book mgmt.
• ..
• Point of view DESIGNER

6
Use Cases vs (Internal) Functions

• Internal functions
• specialized front-ends
• common front-end
• pre-application controls
• contract management
• system monitoring

• Use Cases
• customer
• orders (payment, buy stocks, etc.)
• inquiries
• contract
• administrator
• verify anomalies

7
Use cases as Interaction

• Use cases can be described as an interaction
  scenario (a dialogue) between the users and the
  system
• customer asks for a list of products
• system shows available products
• customer chooses products she wants
• system shows total cost of selected products
• customer confirms order
• system communicates acceptance of order
• Attention must be given to the interaction, not
  to internal system activities

8
Use Cases Identification

• Identify system users (actors)
• (For each actor) discover in which ways the actor
  will use the system, starting from the goals the
  actor has to achieve
• (For each use case) clarify how the the activity
  starts, the answers the actors expect from the
  system, the sequence of the interaction
• Use cases help to discover requirements

9
Requirements and Use Cases

• (functional) requirement a function, or a
  characteristic of a function, requested by the
  customer or by some other stakeholders of the
  system
• use case a way the system can be used by a user
  (actor)

• Each use case can satisfy many functional
  requirements
• A functional requirement can be related to many
  use cases
• Each use case can have many non-functional
  requirements associated to it

10
Prototype and Use Cases

• For each use case there is an interaction between
  actors and system, realized through interfaces
• It is a good idea to prototype the interaction
  (especially between system and human beings)
  during use case definition
• use case and prototype are complementary ways to
  depict the interaction
• UI prototype helps to clarify use case sequence
• use case description helps to discover needed
  links between interfaces

11
Use Case (Jacobsons Definitions)

• (in a business system) A sequence of
  transactions in a system whose task is to yield a
  result of measurable value to an individual actor
  of the business system
• (in an information system) A behaviourally
  related sequence of transactions performed by an
  actor in a dialogue with the system to provide
  some measurable value to the actor(Jacobson 1995)

12
Use Cases and Transactions

• Each use case can be implemented by a sequence of
  transactions in the system, in order to provide
  the aswers needed by the actor

Transactions verify existence of customer in
DB insert new customer scan signature of
customer insert new account
13
Actors

• Entities interacting with the system, through
  messages
• Actors can be
• human beings
• organizations
• other systems (both hardware and software)
• Each actor is a class, and may have many
  instances
• Ex. Actor customer is a class every individual
  customer is a member of the class

14
Business Actors vs. Information System Actors
15
Business Actors vs. Information System Actors
Actors can be defined following two points of
view, both important and legitimate,
corresponding to two different levels of
abstraction

• Independent from specific organizational and
  technological solutions (Business Model)
• Dependent on a specific organizational and
  technological solution (Information System
  Model)

16
Business / IS Model
From the point of view of the customer, the order
clerk is a part of the system (as a mediator, an
interface)
17
Mediation Forms

• The interface between actor and system changes
• The logic core does not change

18
Mediation Forms

• human interface
• pros flexibility, able to adapt to the specific
  actor
• cons cost, absence of uniformity
• automated interface
• pros cost, uniformity
• cons not able to understand requests that are
  either not-predefined, or specified in an
  unexpected way

19
Use Cases and Scenarios

• Base Scenario (usually) implies success, and a
  linear development of the use case
• Alternate Scenarios can imply success or
  failure, with various complications
• we do not need (it would be very expensive) a
  detailed analysis of every possible use case
  scenario (combination of variances)
• but we must discover every variance that can
  bring to the failure of the use case, or that
  needs a specific treatment

20
example open account

• Customer goes to the bank to open an account
• Clerk welcomes customer and gives explanations
• If customer accepts rates she gives her personal
  info
• Clerk verifies if customer is already known to
  the bank
• Clerk opens a new account
• Clerk gives the customer an account number
• Variances
• (a) If customer does not accept, use case ends
• (b) If the account is opened by many people, it
  is necessary to give personal info of every
  holder
• (a) If customer (one of the set of customers) is
  not known, clerk registers her,asks for the
  signature, scans the signature

21
example open account - more detail

• (5) Clerk opens a new account
• Clerk starts transaction open account
• System asks customers codes
• Clerk inputs codes
• System shows corresponding personal info, and
  asks for rates
• Clerk inputs rates, and confirms
• System prints contract, with new account number
• Variances
• (a) if system does not know a customer, or
  displays unexpected data, clerk can correct or
  stop the transaction

22
Use Case Levels

• Use cases are a specific way to represent
  functions, and they can describe objects at
  different levels

• system
• subsystem
• component (or class)

Whatever the level, use cases define a behaviour
of the object they describe, without revealing
its internal structure
23
Use Cases at the Business Event Level
It is possible to identify and describe use cases
at the level of events triggered by actors (each
use case implies every needed answer to the
event)

• Update Web catalog
• Customer Info Request
• Customer Order
• Payment
• Assistance Request

24
Use Cases at the Transaction Level
It is possible to identify and describe use cases
at the level of each transaction, down to the
point of atomic operations (CRUD) on the classes
of the system

• Create Order
• Read Order
• Update Order
• Delete Order

25
From which Level to Start?

• For a medium-sized system we can have
• about a dozen use cases at the business event
  level
• complete functions from the point of view of
  actors
• meaningful delivery (and system test) units
• more than one hundred use cases at the
  transaction level
• internal system functions
• can be too fragmented to be used as a basis of
  understanding between designers and with system
  customers

26
Use Case Role
Delivery Units
Analysis Design Models

Test cases
27
Are Use Cases OO?

• Were Invented in an Object Oriented context
• Describe system functions from the point of view
  of the external actors (like OO messages)
• Do not reveale the internal structure of the
  system
• Are the best starting place for OO design
• but
• Can be used in a non-OO development process
• OO theory is not needed to understand and to use
  them

28
Use Cases Implementation
requirements
use cases
object oriented analysis and design
structured analysis and design
other methods (as you prefer)
buy components
components