CIS224 Software Projects: Software Engineering and Research Methods

1
CIS224Software Projects Software Engineering
and Research Methods

• Lecture 3
• Use Case Models
• (Based on Fowler (2004, Chapter 9) and Stevens
  and Pooley (2006, Chapters 7 8))

David Meredith d.meredith_at_gold.ac.uk www.titanmus
ic.com/teaching/cis224-2007-8.html
2
Introduction

• A use case model describes a system from the
  users point of view
• User can be a person, software system or
  hardware device
• Used to help with
• Requirements capture
• Planning iterations in the development process
• Validating the design of a system
• Introduced by Ivar Jacobson as a development of
  scenarios
• Scenarios still exist in UML

3
Use case diagrams

• Intuitive and easy to understand so can be
  discussed with customers
• An individual use case, represented by a named
  oval, is a class of task that is supported by the
  system
• Each use case also described in detail using
  text.
• Use case diagram is a summary of the detailed
  information given in the use case descriptions
• Actor represented by stick figure
• Actor connected to use case by a line if the
  actor is involved in carrying out the use case
• System represented by box around use cases

4
Use cases and class associations

• Class Copy represents the set of all possible
  Copy objects
• Class Book represents the set of all possible
  Book objects
• Association is a copy of means that every
  instance of class Copy is a copy of an instance
  of class Book
• BookBorrower actor represents the role of being a
  book borrower in principle, anyone or anything
  could be fulfilling this role in any particular
  situation
• Borrow copy of book use case represents all
  possible scenarios with the goal of borrowing a
  book regardless of whether a book is
  successfully borrowed or not
• A scenario is an instance of a use case just as
  an object is an instance of a class
• Line between BookBorrower actor and Borrow copy
  of book use case represents a communicates
  relation and means that it is possible for
  someone in the role of a BookBorrower to be
  involved in carrying out the use case Borrow copy
  of book
• It does NOT mean that all BookBorrowers are
  always borrowing books

5
Actors

• An actor is a representation of a user in a
  particular role from the point of view of the
  system
• Beneficiary of a use case is an actor that
  benefits from the use case being carried out
• GiftRecipient is beneficiary in Buy gift use case
• Primary actor of a use case is the actor whose
  goal is achieved by carrying out the use case
• GiftBuyer is primary actor in Buy gift use case
• Other actors involved in the use case are
  secondary actors
• A given person might play different roles on
  different occasions and therefore be represented
  by different actors in the use case model
• An actor usually only represents a role carried
  out by an external non-human device or system
  when it is autonomous
• If the device or system is being operated by a
  human, then it is usually the role the human is
  playing that should be represented by the actor
• Credit card authorization system providing
  services to a till system might be represented by
  an actor
• Bar code scanner probably not represented by an
  actor since operated by human

6
Use cases

• A scenario is an instance of a use case just as
  an object is an instance of a class
• Examples of scenarios in Borrow copy of book use
  case
• BookBorrower presents a book and is permitted to
  borrow it. The system is updated accordingly.
• BookBorrower presents a book but is refused
  permission to borrow it because he/she already
  has the maximum number of books on loan
• Use case usually named after the main success
  scenario which is the normal successful scenario
  in the use case
• Other scenarios in a use case are called
  extensions
• Extensions may be either successful or
  unsuccessful
• All scenarios in a use case have the same goal
• Usually use text in third person active voice to
  describe the details of a use case and its
  extensions

7
Using use cases for requirements capture

• To capture requirements using use cases we
• Identify the users and the systems that will
  interact with the system to be built
• Identify the actors (i.e., the different roles
  taken by the users when interacting with the
  system)
• For each actor, find out
• The use cases in which the actor is the primary
  actor or a beneficiary
• The other use cases in which the actor is
  involved
• Find out how important each use case is to the
  users

8
Using use cases for planning

• Before producing an overall plan and cost
  estimation we must have an initial list of all
  the use cases for the system and
• A good understanding of what each use case means
• An understanding of who wants each use case and
  how important it is
• Knowledge of which use cases are the most risky
• An idea of how long each use case will take to
  implement
• Note that this is so that we can carry out the
  inception phase of the project where we produce
  a high-level predictive plan, business case and
  feasibility assessment
• We should not make the plan too rigid because it
  is bound to change when we start doing iterative
  development and presenting users with prototype
  systems to evaluate
• When we have a complete initial list of use
  cases and an understanding of how risky and
  important each is, we can then plan which
  iterations will provide realizations of which use
  cases

9
Choosing which use cases to realize in the early
iterations

• Should aim to realize those use cases in the
  early iterations that the users have indicated
  are most important
• Gibbs (1994) 25 of projects cancelled
• Need to give high priority to realising use cases
  that are considered important by those who are in
  a position to cancel the project!
• But remember that system must ultimately satisfy
  the users needs
• Initial use case analysis can help with
  determining whether or not the project is worth
  doing at all

10
Using use cases in validation

• Validate a design by taking each use case in turn
  and checking if the design supports the use case
  (walking the use case)
• Should be a system test for each significantly
  different scenario family within each case
• In Borrow copy of book, should be system test for
• BookBorrower being permitted to borrow the book
• BookBorrower being refused permission to borrow
  book because already has too many books out

11
Problems with use cases

• Danger of building system which is not
  object-oriented (i.e., component-based)
• Too much emphasis on use cases can cause
  developers to make bad architectural decisions in
  the rush to realize quickly the important use
  cases
• Danger of confusing design with requirements
• Users describe procedures for achieving their
  goals
• Developers must consider other procedures and
  focus in use case analysis on identifying the
  users goals

12
Dependencies between use cases

• Two main ways in which a use case may depend on
  another use case
• A simpler use case may be included as a step
  within a more complex use case
• The more complex use case depends on the simpler
  one
• a change in the simpler one might mean the more
  complex one has to be changed too
• A use case may be an extension of another use
  case
• An extension is a scenario within a use case that
  does not have the same outcome as the main
  success scenario
• Extension depends on main use case since it is
  defined to be a variation on the main success
  scenario

13
The ltltincludegtgt relationship

• Scenarios that are instances of the more complex
  (including) use case contain subscenarios which
  are instances of the simpler (included) use
  case
• More complex use case depends on the simpler use
  case hence dashed arrow with open head which
  indicates dependency in UML

14
Use case descriptions

• Every use case should have a detailed use case
  description which is usually written in
  third-person, active-voice prose

15
Use case description forBorrow copy of book

• A BookBorrower presents a copy of a book and his
  or her library card at the issue desk. The system
  checks that the BookBorrower is a library member
  and that he or she does not already have the
  maximum permitted number of books on loan. This
  maximum is 6 unless the BookBorrower is a staff
  member, in which case the maximum is 12. If both
  checks succeed, the system checks that the copy
  of the book is one that can be borrowed. If it
  is, then the system checks if there is a
  reservation on the book (done according to the
  use case Check for reservation). If there is no
  reservation on the book, the system records that
  the BookBorrower has the book on loan from the
  current date and prompts the librarian to stamp
  the book with the return date. If any of the
  checks fail, the BookBorrower is refused
  permission to borrow the book.

16
Use case description forExtend loan

• A BookBorrower asks (either in person or by
  telephone) to extend the loan of a copy of a
  book. The system checks whether there is a
  reservation on the copy (done according to the
  use case Check for reservation). If so, the
  system refuses to extend the loan. Otherwise it
  records that the BookBorrowers loan of the copy
  has been extended and prompts the librarian to
  stamp the book with the new return date. If the
  BookBorrower is present, the copy of the book is
  stamped. Otherwise, the librarian asks the
  BookBorrower over the phone to write the new
  return date in the book.

17
Use case description forCheck for reservation

• Given a copy of a book, the system determines
  whether or not the book is reserved.

18
Benefits of the ltltincludegtgt relation

• Instance of the write once principle
• Identify common steps in the main use cases and
  factor these out as included use cases so that
  the details of these steps only have to be
  defined once
• Can make use case descriptions shorter
• Helps with identifying reusable components if
  included use cases are coherent units of
  functionality

19
Problems with the ltltincludegtgt relation

• Encourages functional decomposition of system
  instead of an object-oriented design
• Avoid this by developing class model in parallel
  with use case model
• Make sure use case reuse makes sense at the class
  level
• Makes use case diagram harder to understand for
  the user or customer
• Tends to blur boundary between design and
  requirements
• Using ltltincludegtgts implies that some design
  decisions have been made

20
Extending a use case

• If a use case contains two or more scenarios
  with quite different outcomes, then all the
  scenarios apart from the main success scenario
  are called extensions and are considered to be
  variants on the main success scenario
• It is not necessary to represent each extension
  on the use case diagram since all extensions are
  represented within the main use case symbol
• However, you can show an extension as a separate
  use case by creating a new use case oval labelled
  with the name of the extension, then drawing a
  dashed dependency arrow from the extension to the
  main use case and labelling this arrow with the
  keyword ltltextendgtgt to indicate that the extension
  extends the main use case

21
Generalizing an actor and a use case
22
System classes that represent actors

• If a system interacts with an actor it is not
  unusual for the actor to be represented by a
  class within the system
• Two main types of situation when this happens
• When the system must store data about each
  instance of the actor
• e.g., library system must store data about each
  library member such as name, id number, list of
  books borrowed
• When the system represents (or wraps) an external
  device with an internal object and uses the
  interface of the object to interact with the
  device
• e.g., there might be a Sensor class within a home
  alarm system through which the system interacts
  with the physical motion sensors positioned
  around the house

23
Summary

• Use case model represents a system from the point
  of view of the users
• Use case models can help with
• requirements capture
• planning the goals of iterations
• validating the design of a system and testing the
  completed system
• Use case diagram is a summary or table of
  contents on the use case analysis
• each use case must also have a detailed textual
  description
• Each use case is a class of task that is
  supported by the system to be built
• A scenario is a particular instance of a use case
  with a particular outcome
• All the scenarios within a single use case have
  the same goal
• The normal successful scenario within a use case,
  after which the use case is named, is called the
  main success scenario
• The other scanarios within a use case are called
  extensions
• Users can be humans or autonomous devices or
  systems that are external to the system that we
  are building
• An actor represents a particular role that a user
  might adopt when interacting with the system
• A beneficiary of a use case is an actor that
  benefits from the use case being carried out
• The primary actor of a use case is the actor
  whose goal is achieved by carrying out the use
  case
• The other actors involved in a use case are
  called secondary actors
• Important to focus on requirements when doing a
  use case analysis and try not to make design
  assumptions
• Two ways in which use cases may depend on each
  other