Use Cases

1
Use Cases

• Based on the paper
• Form Use Cases to System Operations
  Specifications by Shane Sendall and Alfred
  Strohmeier
• in UML 2000 pages 1-15

2
Nature of Use Cases

• Use cases are textual descriptions.
• Use case diagrams tell nothing more than names
• Structural Properties of Use Cases
• Extends, includes and specializes
• Recently there has been an awakening of interests
  in use cases.

3
Background

• Jacobson
• A use case is a sequence of transactions
  performed by a system, which yields an observable
  result of value.
• Transaction consists of a set of actions
  performed by a system.
• Cockburn
• A use case is a description of the possible
  sequences of interaction between the system under
  discussion.

4
Cockburns Clarification of Transactions

1. The primary actor sends request and data to the
   system
2. The system validates the request and the data
3. The system alters its internal state
4. The system replies to the actor with the result.

5
Granularity Levels of Use Case ala Chris Cockburn

• Summary Level
• The 50,000 feet level perspective
• Shows life cycle sequencing of related goals.
• User-goal Level
• The sea-level perspective
• Goal of the primary actor in doing something.
• Sub-function Level
• Underwater perspective.
• Those required in carrying out user goals.

6
Operation Schemas

• A precise form of system level operations.
• Declaratively describes effect of a system level
  operation by its pre and post conditions.
• Used instead of sub-function level descriptions
• Can map use cases to operation schemas.
• The punch line of this paper.

7
Running Example Elevator
8
(No Transcript)
9
Format of Use Case Descriptions

• Main Success Scenarios
• Describes the standard path
• Alternatives
• May have a serial or parallel relationship with
  each other.
• Paper uses some devices as actors, Gomaa does not
  no standard here!

10
Operation Schemas Again

• Why do they fit in?
• Not limited to natural language
• Map 1-1 with a collaboration diagram
• Advantages
• Operation schemas describe interfaces and system
  functionality.
• System operation transaction ala Jacobson
• A sequence of systems operations (or a collection
  of them) forms a use case

11
Operation Schema - I

• Uses an abstract state representation of the
  system
• Describes the effect of operation on the abstract
  state.
• Written declaratively
• Specifies the initial state preconditions and
  after state by a post condition.

12
Operation Schema - II

• The system model is reactive
• All communication is by means of asynchronous I/O
  events (signals).
• All system operations are triggered by input
  events.
• Change is state is described in terms of objects,
  attributes and association links.

13
Operation Schemas - III

• Post conditions can assert
• creation of objects,
• change of attribute values,
• added or removed association links.
• Events sent to outside actors.
• Uses Analysis level class model, and actors
  present in the environment

14
Operation Schema Template

• Operation name, parameter list
• Description written in natural language
• Use Cases cross references super-ordinate use
  cases
• Declares all constants and variable in design
  objects, data types used in Pre and Post
  conditions
• Prewritten in OCL
• Post written in OCL

15
Operational Schema Example

• atFloor operation schema for the elevator.
• Description
• The elevator cabin has reached a floor. What must
  it do next?
• If requested stop at that FL dropoff/pick up
• Else respond to request for service events.
• Use Case Take Elevator

16
Mapping Use Cases to Operation Schemas

• Operation schemas can be derived from user-goal
  level use cases.
• Need a class model, a first approximation of the
  system state.
• Goal partition a use case into a sequence of
  system operations.
• Trigger event exists for each system operation

17
Example from use cases to system operations

• Take elevator use case Main success scenario
• User makes request for service
• Triggers an event externalRequest is a system
  operation
• When elevator reaches floor sensor triggers an
  event. atFloor is a system operation
• If some one got in the elevator and requested
  service. internalRequest is a system operation.

18
Extensions

• In externalRequest system operation
• If no elevators are available must queue and
  schedule the request.
• Every time a door closes, a scheduling decision
  has to be made as to where the cabin goes.
• doorCloses is a system operation.
• bestStuitedCabin is another system operation
  makes a decision based on resources.
• Some system operations can be executing in
  parallel.

19
Related Work

• D. Coleman. Fusion with Use Cases Extending
  Fusion for Requirements Modeling. Prentice Hall
  1994
• Action Specifications in the Catalysis Approach
  of DSouza.
• Two types of actions
• Localized system operations
• Joint Actions for multi-party collaborations

20
Multi-Actor Use Cases an artifact for modeling
Collaboration and Coordination

• Based on Chapter 4 of
• Object Components and Frameworks with UML
• Desmond F. DSouza and Alan C. Wells

21
Joint Action Use Cases

• Change of state in many participants without
  attributing the responsibility to any one of them
• Localized Action
• They are invoked (by someone)
• Is requested in which the receiver is required to
  achieve the post condition.
• Must start when pre condition is true

22
Joint Action Use Cases II

• Joint Action
• A representation of possibilities
• Not directly invoke-able.
• Represents a description of a future that must
  become true.
• Parameters
• Some may be distinguishable as participants and
  other not.

23
Example

• A buyer-seller negotiation.
• Why would any one be the primary actor?
• Isnt the distinction a matter of perspective?
• How about wars?
• Example
• action(buyerRetailer, vendorWholesaler,item)
• post let priceitem.product.price in
• vendor.customer-gtincludes(buyer)

24
From Joint to Localized Actions I

• Joint actions effect all participants.
• An example joint action
• (retailer,wholesaler.agent)sale(xitem)
• A joint action initiated by one participant
• retailer-gt(wholesaler,agent)sale(xitem)
• A directed joint action designates retailer as
  initiator
• retailer-gt(wholesaler,agent)sale(xitem)

25
From Joint to Localized Actions II

• A direct joint action initiated by an unknown
  object and received by the the agent.
• Initiatorobject-gtagentsale(..)
• A Use Case Template for Joint Actions
• use case sale
• participants retailer, wholesaler
• initiator retailer
• receiver wholesaler
• parameters set of items

26
Use Cases Joint Actions

• use case sale
• participants retailer, wholesaler
• parameters set of items
• pre items in stock, retailer registered
• and has case
• post retailed receives items and pays cash
• wholesaler receives cash and gives items

27
Actions and Effects

• Traditional relations
• ltltusesgtgt and ltltextendsgtgt
• Catalysis adds
• ltltactionsgtgt, ltlteffectsgtgt to indicate sharing
• Actions and operations describe interactions
• Effects describe state transitions
• Also represents responsibilities of objects

28

• effect Retailerbuy(xItem)
• pre --have enough cash
• post -- has paid and got items paid for
• effect Wholesalersell(xItem)
• pre --items in stock etc
• post -- gained price of item
• action (rretailer,wwholesaler)sale(xItem)
• post r.buy(x) and w.sell(x) and rregister_at_pre

29
Concurrent Actions

• An example of an ongoing producer-consumer
  relationship
• action (retailer, wholesaler)supply
• guarantee retailer.stock-gtsize gt10
• rely wholesaler.inBusiness
• Every action has 4 clauses
• Guarantee condition maintained while action in
  progress
• Rely what must be true for every other clause to
  hold

30
Collaborations

• A set of related actions playing certain roles
• Actions grouped to show that they serve a common
  purpose
• Represents a distribution of responsibilities
• Two Types
• Open requirements expressed as invariants or
  joint actions
• Encapsulated Behavior of objects typed