UseCase is a DIALOG---NOT a PROCESS

UseCase is

A DIALOGPutcha V. Narasimham

[email protected]

This PPT has Two Sections

Section 1:1. UseCase per UML 2.5 Beta

Specification --NOT a

standard technically

2. Explanation, Errors,

inconsistencies; Criticism of

UC definition & descriptions

3. Professionals may be aware

of this; it is presented later

Section 2:

This is what is NEW1. Analysis & correction of errors of UML

2.5 Beta Spec

2. Distinction of UseCase as DIALOG of messages between SuC and Actor

3. Separation of internal actions of SuC & Actor

4. Linking of 2 & 3

5. Summary and Conclusion

202 FEB 14

Section 2:

UseCase is a DIALOGThis is presented first since this is what is NEW and important.

Those who may NOT be familiar with UseCases may start at Slide 20

302 FEB 14

UML describes UC as Interaction

But what is interaction?

With reference to System under Consideration SuC, Actor and What each does

What is the nature of UseCase?

Is it a process or object or something else?

UML is very vague and uncertain!

SuC

402 FEB 14

UML describes UC as Interaction

• But what is interaction? A or B

• UML has NO answer but we need correct & precise answer

SuC Dialog User thinking

A

B

SuC Action: Processing

User Actions

messages

502 FEB 14

What is Interaction & its Scope?

It should ONLY be DIALOG “A”

SuC Dialog User thinking

A

B

SuC Action: Processing

User Actions

602 FEB 14

Interaction Scope: Only DIALOG!

Interaction is just the DIALOG messages

What happens beyond is

PRIVATE ACTION but NOT INTERACTION

DialogSystem option

Actor Selection

702 FEB 14

More precisely, UseCase is a Dialog

A Dialog of messages between The SuC and

A User (Actor)

To reach specified Goal

This definition Adds precision &

Removes inconsistencies

Use-case Name 1

SuC

User orActor

Actor UC Association

802 FEB 14

Subject of UseCase Modeling

The subject SuC (System under Consideration)

Is to be developed.

It does not exist at the beginning

It is a black-box with

A notional imaginary boundary (it is not concrete)

SuC

UC3

UC4

UC1The UC’s are NOT

inside SuCBUT UML

puts them inside

902 FEB 14

UseCase Modeling Steps

1. Creating UseCaseDiagram or Table

2. Finding Actors & UseCases of SuC

3. Defining UseCase Goals (not emphasized)

SuC

UC3

UC4

UC1The UC’s are NOT

inside SuCBUT UML

puts them inside

1002 FEB 14

Validate & Consolidate the Big Picture

UseCase Diagram is a big picture of

SuC & Actors, UC Services + Goals

Check & validate with stakeholders & Actors

Don’t miss any Actor or UseCase (Service) or Goal

Add New Actors, UseCases & Goals if necessary

This consolidates the big picture

UML allows use of text tables also

See: http://www.slideshare.net/putchavn/5-use-case-table-with-actors-goals-08-sep12

1102 FEB 14

Detail UC Dialog focusing on messages

For each set of Actor, UseCase and Goal

Develop UseCase Dialog

Focusing only on

Messages of UC Dialog

Exclude description of internal actions of SuC & Actor

DO NOT get into internal operations of the SuD

A number of UC’s may be detailed in parallel

Their System Sequence Diagrams or Tables are derived from dialogs LATER

See: http://www.slideshare.net/putchavn/combined-use-case-description-mock-up-screens-and-system-sequence-diagram

1202 FEB 14

Sample UseCase & Critiquing

UseCase: ManageBasket

Brief Description: The customer changes the quantity of an item in the basket

Primary Actor: Customer

Preconditions: 1: The shopping basket contents are visible

Main flow:1. UC starts with customer selecting an item in the

basket2. If the Customer selects “delete item”

2.1: SuC removes the item from the basket3. If the Customer types in a new quantity

3.1 The SuC updates the quantity of the item in basket

Critique (vital fields are shown)

No goal in the description

Enable Customer to change quantity of an item & update selection & see new costs

UML has no primary & secondary Actors

A UC is private and specific to a single Actor. No other actor can interact through the same screen.

A second actor needs his own separate screen to interact. The UML standard is NOT clear & publications are misleading

Is it a start of UC or middle of UC?

1302 FEB 14

Review

UseCase: Profound Concept by Ivar Jacobson

UC Diagram: Big Picture, It has better Structure than Context Diagram of SSAD

Shows SuC, Actors, UC Servicesbut NOT Goals

The precise nature of UC is NOT defined

Many professionals give their own definitions and argue

I am also guilty of it but I have given my reasons & benefits

Here are the summary & conclusions

1402 FEB 14

What UseCase is NOT

To know what a thing is,

At times, it is advantageous to know what it is NOT

UseCase is NOT

A process

A sub-system,

A part or

A component

A Goal

So, it would be more accurate to put the UseCase Oval

ON The System Boundary than in side

This is correct but not a popular convention

15

Use-case Name 1

SuC

Not clarified in the UML Spec or publications

1502 FEB 14

Interaction versus Dialog

The UML specification & other

publications describe UC as

interaction

The scope of interaction, if

not specified, may include the

internal actions of the SuC

& Actor

That is too wide & distracting

1. More precisely, a UC is a DIALOG

of messages between SuC & Actor

2. Internal processes of the SuC or

the Actor to generate the

messages, are out of scope of 1

3. UC details can be complete &

comprehensive without 2

1602 FEB 14

UseCase is only a Dialog

But NOT interaction

Internal activities of SuC are beyondUseCase scope

Shown in Sequence Diagram later

SuC

Dialog

Each message is System Option or Actor selection

Created during discussion with Mujtaba Safdar—19NOV10

1702 FEB 14

Conclusion: DO’s and Reasons

1. UC is a DIALOG,

2. NOT a process & so Activity Diagrams are inappropriate though popular

3. Define UC Goals before detailing UC’s Goal determines messages

4. Develop messages between SuC & Actor (not their actions) to reach UC Goal

5. Messages let you discover data & information to define functionality / processing within the SuC which comes up later

1802 FEB 14

Conclusion: DON’Ts and Reasons

1. If you find a need to include another Actor of different class in the UC DON’T; A fully resolved correct UC has ONLY one Actor

2. See1. http://www.slideshare.net/putchavn/one-use-case-one-actor

2. http://www.slideshare.net/putchavn/use-casesingle-session

3. http://www.slideshare.net/putchavn/one-actor-one-session-per-use-case

3. Don’t use of Activity diagrams for UC (it is NOT a process)

4. Avoid premature entry into Sequence Diagrams, they are derived from messages of UC Dialog

Section 1 follows

1902 FEB 14

Section 1:

UseCase SpecificationFrom OMG specification of UML 2.5 Beta

Explanation, comments, errors, inconsistencies and analysis

2002 FEB 14

Use Case: A Great Concept

Very PROFOUND,

Originated by Ivar Jacobson

Used mostly for IT and at times non-IT applications also

Gives big-picture: Use Case Diagram

Of the System under Consideration SuC &

Its immediate environment

Excellent for eliciting & documenting

FUNCTIONAL Requirements

Not the best for other (non-functional) requirements but can lead to them

2102 FEB 14

UseCase Definition UML 2.5b + Comments

UseCase: Means to capture

the requirements of a system,

what a system is supposed to do

The key concepts: Actors,

UseCases, and

The Subject

Explanation: Straight from the UML specification

Means to elicit, capture & document requirements of a system

Recall the modern distinction between Business & User Requirements (BRD) and Requirements of a System—not reconciled

The key concepts, standard graphics are defined in the next two slides

2202 FEB 14

UseCase Description UML 2.5b & Criticism

1. A UseCase specifies

2. a set of actionsperformed by its subject SuC which yields an observable result

3. that is of value for one or more Actors or other stakeholders of the subject

Explanation & Criticism: UC Definition and Description are different &

inconsistent

There is NO single comprehensive & reliable definition of UC in the UML spec

Note the conflict within UML : Such instances (of UseCases) are often described by Interactions

However, 2 says just “actions” that too performed ONLY by SuC by omitting ‘Actor’

2302 FEB 14

UseCase UML 2.5 Beta Corrections

1. A UseCase specifies

2. a set of actions performed by its subject (SuC) only?, Why are actions of Actor NOT mentioned?

3. which yields an observable result

4. that is of value for one or more Actors or other stakeholders of the subject

Explanation & Correction Interactions (not actions) is more

appropriate since the Actor also ACTS (not just the SuC) & his or her actions are interleaved through a UC dialog

Point 4 is too verbose undefined & unverifiable.

3 & 4 can be combined into: to reach specified goal

2402 FEB 14

Actor: specifies a role played by a user or any other system that interacts with the subject (SuC)

UML Standard Graphics Alternate Graphic

I prefer this

UML Actor is different from UP Worker

Worker of Unified Process

Used in workflow diagrams

<<actor>>Name

Name

Icon

2502 FEB 14

Subject: System under Consideration SuC

Subject:

The system or systems under consideration (SuC)

To which the UseCase applies

(Only?) Subject’s behavior is specified by (1..*) UseCases!

UseCases are defined according to the needs of Actors (by?)

UseCase Goal is NOT explicit

SuC

Use-case Name 1

2

3

Use-case Name n

2602 FEB 14

Nature of UseCase

The UML specification1. A UseCase is a specification

of behavior (of?).

2. An instance of a UseCase refers to an occurrence of the emergent behavior (of?) that conforms to the corresponding UseCase.

3. Such instances are often described by Interactions

Comments & Explanation1. The specification is generic2. An instance is a particular

occurrence Emergent is something that arises newly (not predetermined), It is unique but is within the genericspecification

3 UseCase is described by Interactions (but what is its scope?)

2702 FEB 14

UseCase Diagram

A big picture of SuD,

Actors 1 to n

Association lines 1 to n &

UseCases 1 to n

UML 2.5 allows use of Tables in stead of diagrams

Actor-UC Association

SuC

Use-case Name 1

2

3

Use-case Name n

2802 FEB 14

Analysis and Corrections

Pointed out errors and inconsistencies of UseCaseSpecification of UML 2.5 Beta

Analyzed and corrected them in Section 2, which was presented first

Mistaking UseCase as a process is the prime reason for the confusion

Explained in detail in http://www.slideshare.net/putchavn/one-actor-one-session-per-use-case

29

Think and

Proceed02 FEB 14