Use Case

1
Use Case Interaction Diagrams

• Outline the role of a Use Case model
• Draw Use Case Diagrams
• With ltltincludegtgt ltltextendgtgt
• Write a Use Case
• Draw interaction diagrams
• Collaboration diagrams
• Sequence diagrams
• Compare the two interaction diagrams
• Relate Use Cases interaction diagrams

2
Summary

• Use Case diagrams
• list of use cases relevant actors
• Interaction Diagrams
• Diagrams describing an interaction
• Objects collaborating to carry out a task
• Collaboration diagrams
• Emphasize relevant objects messages
• Sequence diagrams
• Emphasize timing of message exchange

Same information, different format
3
Use Case Modelling

• Use case model all the use cases for the system
• Just like any model only holds some information
• A use case is a description of a transaction
• A user using the system to do something
• Described in a structured format.
• Describe system behaviour from a users view
• Represents tasks done with support from the
  system.
• A user is anything external interacting with the
  system
• (a person, another system, hardware etc.)

4
Example Use Case

• Name Borrow book
• Purpose User borrows a copy of a book
• Sequence
• A Borrower presents a book.
• Check borrower is a member, and has fewer than
  the maximum number of books. (Normally 6, 12 for
  staff)
• If checks fail, or the book is reserved refuse to
  lend it
• Otherwise record that borrower has this copy of
  the book and display the return date.
• Exceptions
• NotMember tell the borrower how to join
• TooManyBooks ..

5
Use Case Uses

• Use Cases
• Capturing requirements
• A use case can be discussed with users
• Validating systems
• Help develop test scripts
• Use Case Diagrams
• Intuitive diagram that can be discussed with
  clients.
• Checking completeness of use case model
• Planning iterations of development
• Which use cases would generate most benefit?
• Which use cases would be easiest to implement?

6
Elements of use case diagrams

• Use Case
• Actors
• An actor, stick person, represents a type of
  system user
• A role, not an individual, played by various
  objects
• e.g, a librarian may be borrower
• An actor is linked to a use case if it may be
  involved
• System boundary
• A box around use cases represents a system
  boundary

7
Use Case diagram for the library

• Little more than a list of use cases

Library System
Reserve
book
Browse
Borrow copy
of book
Browser
Book Borrower
Return copy
of book
Extend loan
Update
Catalogue
Borrow
journal
Librarian
Return
journal
Journal Borrower
8
Extending Use Case Diagrams

• Extensions to Use Case Diagram notation
• Conflicts with simplicity of use case diagram
• Increases expressive power
• Links between use cases
• Links represented by arrow between use cases
• Stereotypes show link types
• ltltincludesgtgt and ltltextendsgtgt
• Inheritance relationships
• Between actors
• Between use cases

borrower
Borrow Item
BorrowDVD
BorrowBook
librarian
9
Use case reuse ltltincludegtgt

• Abstract common behaviour from several use cases
  
• part of one use case is implemented by another.
• Uses of ltltincludesgtgt
• to show how the system can use a pre-existing
  component
• to show common functionality between use cases
• to show a new reusable component

extend loan
ltltincludegtgt
check for reservation



book
ltltincludegtgt

borrower

borrow book
10
Use Case Descriptions

• Extend Loan
• A BookBorrower asks to extend a loan.
• If there is a reservation on the bookrefuse to
  extend the loan.
• Otherwise
• record that the loan has been extended.
• Display the new return date.
• Check for reservation
• Count the number of reservations for this book,
  n.
• Let m be the number of copies held behind the
  desk.
• If n gt m, this copy is reserved, otherwise it is
  not.

11
Variations ltltextendgtgt

• A use case with several different routes may be
  split into a main use case and subsidiary cases.
• The extension points can be shown in the main use
  case.
• ltltextendsgtgt
• ltltextendsgtgt with extension point

Refuse loan
ltltextendgtgt
Borrow copy
of book
Book Borrower
12
ltltextendgtgt

• One use case is a variation of another
• Neither use case is fully included in the other
• A variation may be conditional
• E.g. refuse to issue reserved book
• Variation may add actions into a use case
• E.g. Borrow ShortLoan is same as Borrow Book
• Except the customer is warned of early return

13
Interaction diagrams

• Two different types of interaction diagram
• Collaboration diagrams
• Sequence diagrams
• Both can show the implementation of a use case
• How the actor interacts with system components

14
Collaboration Diagrams

• Objects (not classes), links and actors
• Achieving a goal
• Implementing a use case
• Can annotate with order of messages
• A simple collaboration, showing no interaction

15
Collaboration Diagrams

• Interaction details can be shown
• Message Method

theBook
The message being implemented
Book
aMemberBookBorrower
2.1 borrowed
borrow(theCopy)
theLibraryMember
theCopy
LibraryMember
Copy
2 borrow
1 okToBorrow
16
Synchronous Message Processing

• In procedural interaction, message handling is
  synchronous
• sending a message passes control to the receiver
• one object is computing at a time
• An object starts to compute when it receives a
  message.
• Eventually it responds to the sender of the
  message.
• While processing a message, an object may
• compute results itself,
• send messages to other objects.
• An object sending a message pauses until it
  receives a response.

17
Sequence Diagrams

• Shows the sequence of interactions between
  objects
• The objects and actors participating in a
  collaboration are shown at the top of dashed
  lines.
• The line, the objects lifeline, represents time
• Time is increases from the top to bottom of the
  diagram.
• When an object is active, a narrow rectangle
  covers its lifeline.
• Put objects which take part earliest on the left
• so most messages flow left to right.
• Interaction shown on a sequence diagram

18
Sequence Diagram

• The same information as a collaboration diagram
• Different emphasis

19
Additional Information

• Sequence Diagrams can also show
• Creation destruction of objects
• Asynchronous call information return
• Branching
• Conditional branch
• Fork (concurrency)
• Iteration
• Close to implementation level
• Possible code generation

20
Summary

• Use Cases
• Specification
• Testing
• Interaction Diagrams
• Sequence diagrams Collaboration diagrams
• Design
• High-level design ? Detailed design
• How much information should be put on the
  diagram?
• Overview?
• Leave detail to programmer?
• Diagram easier to understand
• Lots of detail?
• Generate code automatically?
• Harder to understand