Download as PDF, PPTX
Uploaded byPutcha Narasimham
One Actor & One Session per UseCase
The document outlines the concept of use cases as dialogues involving one system under consideration (SUC) and one actor per session, emphasizing that each use case can only have a single actor involved and that multiple actors cannot participate in the same dialog. It critiques common misunderstandings, such as conflating processes with use cases, using an ATM cash withdrawal example to illustrate these points. The main conclusion is that accurately modeling use cases requires recognizing them as distinct from processes and ensuring proper separation of dialogs associated with different actors.
More Related Content
Similar to One Actor & One Session per UseCase
One Actor & One Session per UseCase
- 1. One Actor & OneSession per UseCase Putcha V. Narasimham Kenablersys@yahoo.com
- 2. UseCase is aDIALOG---NOT A PROCESS UseCase: A dialog Process SuC Activity 1 Output-1 messages Activity 2 Output-2 Activity 4 Activity 5 Activity 3 Output-3 Output-4 Process can have multiple performers, each performing multiple activities & their outputs flowing to other activities 02 FEB 14 Dialog UseCase DIALOG has only two parties exchanging multiple messages 2
- 3. One & OnlyOne Actor per UseCase SuC 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 UC1 2 3 The UC’s are NOT inside SuC BUT UML puts them inside UC3 UC2 02 FEB 14 3
- 4. No Second Actorin a UseCase SuC 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 cannot participate in other’s dialog 02 FEB 14 2 The UC’s are NOT inside SuC X 3 UC 4
- 5. A UseCase canonly 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 02 FEB 14 messages Dialog A break in dialog ends the session and so the UseCase 5
- 6. Well discussed earlier SuC UC1 The nature of UseCase and its implications were discussed in depth in http://www.slideshare.net/putchavn/usecase-case-is-a-dialog-not-aprocess 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 02 FEB 14 6
- 7. UseCase is aDIALOG SuC messages 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 02 FEB 14 7
- 8. 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 02 FEB 14 ATM 1 AH UC Withdraw Cash 2 BC 8
- 9. Need to useProcess 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) 02 FEB 14 1 2 ATM AH BC Activity 1 Msg 1 Activity 2 Activity 3 Msg 2 Activity 7 Msg 4 Activity 6 Activity 8 Msg 5 Activity 4 Msg 3 Activity 5 Activity 9 9
- 10. ATM: Withdraw Cash--- Process Map Actor 1 AH: Account Holder System under Consideration ATM Login data captured earlier Requests Cash Amount Only Gross Activities are shown Collect Cash or Leave 02 FEB 14 Actor 2 BC: Bank's Computer Cash or denial message Sends AC Account No & Amount Dispenses Cash or Declines AC Account No & Amount Processes Request & Decides Decision Message + data 10
- 11. Account Holder &ATM UseCases (Dialogs) Actor 1 AH: Account Holder System under Consideration ATM Login data captured earlier Requests Cash Amount Only Gross Activities are shown Collect Cash or Leave 02 FEB 14 UC 1A UC 1B Sends AC Account No & Amount Dispenses Cash or Declines Cash or denial message Explanation 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 11
- 12. ATM and BankComputer UseCase Dialog Explanation System under Consideration ATM Actor 2 BC: Bank Computer Login data captured earlier 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 02 FEB 14 Sends AC Account No & Amount Dispenses Cash or Declines UC 2 AC Account No & Amount Processes Request & Decides Decision Message + data 12
- 13. UseCase Diagram fromProcess Map Actor 1 AC: Account Holder System under Consideration ATM Actor 2 BC: Bank Computer These two UseCases UseCase names are with Decides if cash can be have to be separate reference to the SuC ATM dispensed or denied Receive Cannot be based on ATM Rules to UC1A Cash combined ATM Acts but each AH Request Because of Does NOT Get Bank’s UC2 dependency on external decide Decision Bank Computer Dispense UC1B 02 FEB 14 Cash or Message UC1A has to be kept on hold till UC2 is completed Then only UC1B can start. So it has to be separate. 13
- 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 02 FEB 31 JAN 14 14
- 15. 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 02 FEB 14 Think and Proceed 15