Use Cases COMM1B: Information Systems Analysis

1
Use CasesCOMM1B Information Systems Analysis

• These slides are based on Dr TC Tans slides
• available from http//osiris.sund.ac.uk/Module_Inf
  o/com325/tc/comm81/comm81.htm

2
Use Cases

• A typical interactions between a user and a
  computer system
• captures some user-visible function
• small or large
• achieve a discrete goal for the user
• document behaviour of the system from users
  points of view

3
How to Capture Use Cases

• Talk to user
• identify discrete things they want
• allocate a distinct name for each
• describe each with a short textual description
• elaboration stage

4
Use of Use Cases

• Capturing requirements
• identify actors
• what they need
• other interactions they expect to have with the
  system
• planning iterations of development
• validating systems

5
Use Case Diagrams
6
Actors

• an actor is a role that a user plays with respect
  to the system

• a user may also play more than one role
• carry out use cases
• actors do not have to be humans
• A single actor can perform many use cases
• a use case may have several actors performing it

7
Beneficiaries

• an actor for whom a use case is of particular
  value
• should stay involved with the development of the
  use case

8
Identifying actors

• human
• relatively easy
• different roles at different times
• non human
• less clear cut
• boundaries between systems
• pragmatic

9
Scenario

• A scenario is a particular instance of a use case
• a possible interaction between the system and
  some people or systems/devices
• eg
• Book borrower Mary Smith borrows the librarys
  third copy of War and Peace,when she has no other
  books out on loan. The system is updated
  accordingly
• Book borrower Joe Smith tries to borrow the
  librarys 1st copy of Moby Dick, but is refused
  because he already has six books out on loan,
  which is his maximum allowance.

10
System boundary
11
Relationships between use cases

• ltltusesgtgt
• when a chunk of behaviour is similar across a
  number of use cases (some call this ltltincludesgtgt)
• ltltextendsgtgt
• when one use case is similar to another BUT does
  a bit more
• ltlt gtgt - notation indicates stereotypes

12
An Aside Stereotype definition

• A stereotype is, in effect, a new class of
  modeling element that is introduced at modeling
  time. It represents a subclass of an existing
  modeling element with the same form (attributes
  and relationships) but with a different intent.

13
ltltusesgtgt relationship

• show common functionality between use cases
• show how the system can use a pre-existing
  component

14
ltltusesgtgt relationship
Borrow copy of book A Bookborrower presents a
book. The system checks that (i) the potential
borrower is a member of the library, and (ii) if
he/she is within the borrowing limit. If both
checks succeed, the system checks whether there
is a reservation on the book (use case Check for
reservation) if so the system refuses the loan,
else the loan is granted.
15
ltltextendsgtgtrelationship

• Separating variant behaviour
• Separates a main case from its subsidiary ones

Borrow copy of book A Bookborrower presents a
book. The system checks that (i) the potential
borrower is a member of the library, and (ii) if
he/she is within the borrowing limit. If either
check fails the loan is refused.
16
ltltextendsgtgt relationship

• Identifying variant use cases
• Procedure
• Capture the simple, normal use case first
• to identify any variants for every step of the
  use case
• what could go wrong?
• what might work differently?
• Plot all variations as extensions of the given
  use case

17
Summary

• uses cases
• notations (actors use case)
• relationship between use cases
• ltltusesgtgt
• ltltextendsgtgt