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
1/2/2019
Precise Modelling

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.
1/2/2019
Precise Modelling

3. Background Jacobson: Cockburn:
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.
1/2/2019
Precise Modelling

4. Cockburn’s Clarification of Transactions
The primary actor sends request and data to the system
The system validates the request and the data
The system alters its internal state
The system replies to the actor with the result.
1/2/2019
Precise Modelling

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 carrying out user goals.
1/2/2019
Precise Modelling

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.
1/2/2019
Precise Modelling

7. Running Example: Elevator
1/2/2019
Precise Modelling

8. 1/2/2019
Precise Modelling

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!
1/2/2019
Precise Modelling

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 form a use case
1/2/2019
Precise Modelling

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.
1/2/2019
Precise Modelling

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.
1/2/2019
Precise Modelling

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
1/2/2019
Precise Modelling

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
Pre:written in OCL
Post: written in OCL
1/2/2019
Precise Modelling

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
1/2/2019
Precise Modelling

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
1/2/2019
Precise Modelling

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.
1/2/2019
Precise Modelling

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.
1/2/2019
Precise Modelling

19. Related Work
D. Coleman. Fusion with Use Cases –Extending Fusion for Requirements Modeling. Prentice Hall 1994
Action Specifications in the Catalysis Approach of D’Souza.
Two types of actions:
Localized: system operations
Joint Actions: for multi-party collaborations
1/2/2019
Precise Modelling

20. Multi-Actor Use Cases a tool for modeling Collaboration and Coordination
Based on Chapter 4 of
Object Components and Frameworks with UML
Desmond F. D’Souza and Alan C. Wells
1/2/2019
Precise Modelling

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
1/2/2019
Precise Modelling

22. Joint Action Use Cases II
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.
1/2/2019
Precise Modelling

23. Example A buyer-seller negotiation. Example
Why would any one be the primary actor?
Isn’t the distinction a matter of perspective?
How about wars?
Example
action(buyer:Retailer, vendor:Wholesaler,item)
post: let price=item.product.price in
vendor.customer->includes(buyer)
1/2/2019
Precise Modelling

24. From Joint to Localized Actions I
Joint actions effect all participants.
An example joint action
(retailer,wholesaler.agent)::sale(x:item)
A joint action initiated by one participant
retailer->(wholesaler,agent)::sale(x:item)
A directed joint action designates retailer as initiator
1/2/2019
Precise Modelling

25. From Joint to Localized Actions II
A direct joint action initiated by an unknown object and received by the the agent.
Initiator:object->agent::sale(..)
A Use Case Template for Joint Actions
use case sale
participants retailer, wholesaler
initiator retailer
receiver wholesaler
parameters set of items
1/2/2019
Precise Modelling

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
1/2/2019
Precise Modelling

27. Actions and Effects Traditional relations: Catalysis adds:
<<uses>> and <<extends>>
Catalysis adds:
<<actions>>, <<effects>> to indicate sharing
Actions and operations describe interactions
Effects describe state transitions
Also represents responsibilities of objects
1/2/2019
Precise Modelling

28. effect Retailer::buy(x:Item) pre: --have enough cash
post: -- has paid and got items paid for
effect Wholesaler::sell(x:Item)
pre: --items in stock etc
post: -- gained price of item
action (r:retailer,w:wholesaler)::sale(x:Item)
post: r.buy(x) and w.sell(x) and
1/2/2019
Precise Modelling

29. Concurrent Actions
An example of an ongoing producer-consumer relationship
action (retailer, wholesaler)::supply
guarantee: retailer.stock->size >10
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
1/2/2019
Precise Modelling

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
1/2/2019
Precise Modelling