One Actor & One Sessionper UseCase

Putcha V. NarasimhamKenablersys@yahoo.com

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