1.Use Cases

1
1.Use Cases

• Modelling Functionality

2
Describing Functionality

• 1 Use-cases
• 2 The Use-case Diagram.
• 3 Actors System.
• 4 Finding Use-cases.
• 5 Relating Use-cases to each other.
• 6 Describing Use-cases.
• 7 Testing Use-cases.

3
1.1 Use-cases

• Developed and formalised by Ivar Jacobson in
  Objectory method and adopted by the UML.
  
• Elaborational method of discovering user goals or
  system interactions.
  
• Use-cases represent black box functionality of
  the system.

4
Defining use cases

• UML defines a use case as a set of sequences of
  actions a system performs that yield an
  observable result of value to a particular
  actor.
• Use case always initiated by an actor.
• Use case provides a service to an actor.
• Use cases must be complete.

5
Purpose of Use-cases

• To lay down the functional requirements for
  agreement between users and developers of the
  system.
  
• Used as a basis for further design work.
• Provides basis for system testing.
• Provide traceability from requirements model to
  implementation model for change requests and
  design iterations.

6
1.2 The Use-case Diagram
Take out policy
Sales stats.
Insurance Salesperson
Customer
Customer stats.
7
1.3 Actors System

• Use cases depict interactions between the user
  (an actor) and the system.
  
• Actors are represented diagrammatically as a
  stick figure.
  
• The system is represented as a box.
• Similar notation to context of SSADM.

8
Actors

• Actors represent roles, not necessarily humans
  though.
  
• Actors perform the use cases.
• Use cases are about externally required
  functionality, finding actors helps to find use
  cases, look for external events.
  
• Actors may have various roles wrt a use case.

9
Finding Actors

• Who will use system main functions ?
• Who needs regular support from the system to do
  their job ?
  
• Who will keep the system going ?
• What hardware does the system need to use ?
• What other systems does our system use?

10
1.4 Finding Use-cases

• For each actor found, ask the following.
• What does the actor need to do and what
  functionality does it require?
  
• Does the actor read, create, destroy, modify or
  store information in the system?
  
• Are events sent and\or received by the actor,
  what functionality do those events represent?
  
• Is there some new functionality required?

11
1.5 Relating Use-cases

• There are three relationships between use cases.
• Extends, generalising relationship, adds actions
  to general use case.
  
• Uses, generalising relationship, includes general
  use case as a part of a specialised use case.
  
• Grouping, a packaging mechanism of UML.

12
Extends Relationship

• Pick choose which parts of the use case being
  extended.
  
• Textual description leads to difficulty in
  defining which parts in the extended use case are
  reused from the generalised, which are redefined
  and which are added.

13
Uses Relationship

• Entire use case is used in extends relationship.
• Not necessarily in same order.
• If use case is never used by itself, it is called
  an abstract use case.
  
• Useful when there is similar behaviour across
  many use cases.

14
Guide to Uses Extends

• Use extends when describing a variation on normal
  behaviour.
  
• Use uses when you want to avoid repetition across
  several use cases.

15
1.6 Describing Use-cases

• Text description of use case should include the
  following.
  
• Objective of the use case, should be goal
  oriented.
  
• How is it initiated?
• Show flow of messages between system actor and
  describe the finish of the use case.
  
• Mention alternative execution paths through the
  use case

16
Now look at the first cut.

• Do all actors in a use case have an association
  with it?
  
• Can we abstract out a common role among actors to
  get a base class actor?
  
• Can we find commonality to develop a uses
  relationship among use cases?
  
• Can we find an extends relationship?
• Are there any actors or use cases without
  communication associations?
  
• Are the use cases complete?

17
1.7 Testing Use-cases

• Validation
• Present and discuss model with customer\end
  users.
  
• Iterative process.
• Verification
• Works according to the specification, must have
  some part of the system implemented.
  
• Source of black box system test cases.

18
Realizing Use Cases

• Use cases may have many realizations.
• A collaboration is a number of diagrams showing
  the context and the interactions between the
  participants in the collaboration.
  
• Diagrams may be developed as follows.
• Collaboration Diagram
• Sequence Diagram
• Activity Diagram

19

• Transform steps and actions of use case to
  classes, operations on the classes and
  relationships between them.
  
• This is not a simple mechanical task.
• CASE tools should provide hyperlinks for
  realizations.
  
• Following notation may be used.

20
Realizing Use Cases

Collaboration
Use case



Class A
Class B
Use case description 1.Actor push button 2.Use
case does something 3.Use case responds with
message
4. ...
Class C
Op1() Op2()
Op1() Op2()
Op1() Op2()