One Actor & One Session per UseCase
-
Upload
putcha-narasimham -
Category
Technology
-
view
233 -
download
0
description
Transcript of One Actor & One Session per UseCase
One Actor & One Sessionper UseCase
Putcha V. [email protected]
UseCase is a DIALOG---NOT A PROCESS
Process can have multiple performers,
each performing multiple activities &
their outputs flowing to other activities
2
SuCDialog
messages
UseCase: A dialogProcessActivity 1
Activity 2Output-1
Activity 5
Activity 3
Activity 4
Output-2
Output-3
Output-4
UseCase DIALOG has only two parties exchanging
multiple messages
02 FEB 14
One & Only One Actor per UseCase
SuC can and does interact with multiple Actors (1,2,3)
That is the purpose of SuC
But each Actor can only have
One dialog (UseCase) in one session with SuC
1
SuC
UC3
UC2
UC1
2
3
The UC’s are NOT
inside SuCBUT UML
puts them inside
302 FEB 14
No Second Actor in a UseCase
Each interaction, More appropriately the dialog,
Can only have two members
Actively involved in the dialog
First the SuC and
The second associated Actor
Third party Actor cannotparticipate in other’s dialog
SuC
UC
2
3
The UC’s are NOT
inside SuCX
402 FEB 14
A UseCase can only have one session
Session: a single continuous sitting, or period of sitting, of persons so assembled---online dictionary
A UC can only have two participants: SuC & Actor
The session has to end or kept on-hold if there is an external dependency
A break in dialog ends the session and so the UseCase
Dialogmessages
502 FEB 14
Well discussed earlier
The nature of UseCase and its implications were discussed in depth in http://www.slideshare.net/putchavn/usecase-case-is-a-dialog-not-a-
process http://www.slideshare.net/putchavn/use-casesingle-session http://www.slideshare.net/putchavn/one-use-case-one-actor
Yet there are discussions and justifications for associating multiple actors with a single UseCase
This explains why that is NOT valid & how to model UseCase correctly
SuC
UC1
602 FEB 14
UseCase is a DIALOG
• Involving only one SuC and One Actor per Session
• There is NO scope for another actor to take part in that dialog
• Here is an analysis of ATM Cash withdrawal process NOT UseCase
SuC
Dialogmessages
702 FEB 14
Mistaken ATM UseCase: Withdraw Cash
This is considered to be
A single UseCase in which
Actor 1 AH: Account Holder
Actor 2 BC: Bank Computer
Are required to participate together
This is actually an Unresolved Process but mistaken and misrepresented as a single UseCase
A common but inexcusable error
1
ATM
UCWithdraw
Cash
2
AH
BC
802 FEB 14
Need to use Process Map
When multiple entities perform activities interactively
It becomes necessary to represent them using
Process Map UML Activity Diagrams or
BPMN Diagrams
In real-world, objects also flow (not just Msgs)
Activity 1 Activity 2
Activity 3 Activity 4
Activity 7 Activity 6 Activity 5
Activity 8 Activity 9
Msg 1
Msg 3
Msg 5
Msg 2
Msg 4
9
1 ATM 2
AH BC
02 FEB 14
ATM: Withdraw Cash --- Process Map
Actor 1 AH: Account Holder
System under Consideration ATM
Actor 2 BC: Bank's Computer
Login data captured earlierRequests Cash
Sends AC Account No
& Amount
Amount
Collect Cash or Leave
Only Gross Activities are shown
Processes Request &Decides
Dispenses Cash or Declines
AC Account No& Amount
Decision Message + data
Cash or denialmessage
1002 FEB 14
Account Holder & ATM UseCases (Dialogs)
Actor 1 AH: Account Holder
System under Consideration ATM
Explanation
Login data captured earlier Consider only AH and SuC: ATM There are two sets of messages or
two dialogs or UseCases UC1A and UC1B UC1B has an external dependency It cannot be carried out only by AH
and ATM---there is a session break That is why UC1A and UC1B have
to be separated
Requests Cash
Sends AC Account No
& Amount
Amount
Collect Cash or Leave
Only Gross Activities are shown
Dispenses Cash or Declines
Cash or denial message
UC1 A
UC 1 B
1102 FEB 14
ATM and Bank Computer UseCase Dialog
ExplanationSystem under
Consideration ATMActor 2
BC: Bank Computer
Now consider only the SuC: ATM and Actor 2 BC
Here also there are two sets of messages but
There is NO EXTERNAL Dependency
So, a single UseCase UC2 can be carried out in a single session
Login data captured earlier
Sends AC Account No
& Amount
Processes Request &Decides
Dispenses Cash or Declines
AC Account No& Amount
Decision Message + data
UC 2
1202 FEB 14
UseCase Diagram from Process Map
Actor 1 AC: Account Holder
System under Consideration ATM
Actor 2 BC: Bank Computer
These two UseCases have to be separate
Cannot be combined
Because of dependency on external Bank Computer
UseCase names are with reference to the SuC ATM
ATM Acts but Does NOT
decide
Decides if cash can be dispensed or denied based on ATM Rules to each AH
Receive Cash
Request
Dispense Cash or
Message
Get Bank’s Decision
UC1A has to be kept on hold till UC2 is completedThen only UC1B can start. So it has to be separate.
13
UC1A
UC1B
UC2
02 FEB 14
ATM Example & Analysis
In the case of ATM “Withdraw Cash” Process (not a UC)
There are THREE separate UseCases UC1A, UC2 and UC1B
They must operate one after another in that sequence
For any reason (communication failure or Bank Computer Crash) if UC2 cannot be carried out
UC1B cannot be initiated (so it cannot be a part of UC1A)
The ATM has take Time-Out Action and inform AH that “Withdraw Cash” cannot be serviced
Thus, a UseCase can only have one Actor and one Session
31 JAN 14 1402 FEB 14
Summary & Conclusion
Mistaking and misrepresenting UseCase to be a Process
Is the prime reason for wrongly associating multiple Actors to the same UseCase
A process can have multiple Actors but NOT a UseCase
Some professionals mistake that we are splitting a UseCase
No, we are splitting a process into UseCases
To arrive at two-party dialog which alone can be implemented and realized with one SuC
Think and
Proceed
1502 FEB 14