[1] A view that a UseCase (UC) is a "dialog" between the System under Consideration (SuC) and an Actor (for a specific UC) brings focus to what "messages need to be exchanged between the SuC and Actor to reach UC Goal". [2] Agreeing on and specifying UC Goal is related to business or application. UC Goal would be the right first step of UC description. [3] There are many "means" of generating "messages from SuC", through various internal activities within the SuC. They need not be (I would even say should not be) specified in UC Description. [4] The concept of UseCase is profound and useful because it is a "dialog" but NOT a process. This distinction is not defined and clarified which is why, I think, the full benefits of UC modeling are not widely realized. [5] This view of UC (as per 1, 2 & 3) clearly separates the "internal processes" of the SuC from UC. The "internal processes" can be hypothesized and evolved separately using UML Sequence Diagrams. All the business / user needs can be specified with sufficient precision and rigor through the “messages” of UC dialog. There are no external dependencies, though constraints may exist and have to be taken care of. I have REVISED & uploaded the PPT with TWO Sections, Section 2 First. [6] I would like to study applications and demonstrate how the "dialog" view of UseCase would simplify & clarify UseCase description for the business user as well as system developer without sacrificing precision and usefulness. 02 FEB 14

1. UseCase is
A DIALOG
Putcha V. Narasimham
Kenablersys@yahoo.com

2. 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
02 FEB 14
Section 2:
This is what is NEW
1. 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
2

3. Section 2:
UseCase is a DIALOG
This is presented first since this is what is NEW and important.
Those who may NOT be familiar with UseCases may start at Slide 20
02 FEB 14
3

4. UML describes UC as Interaction
SuC
 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!
02 FEB 14
4

5. UML describes UC as Interaction
SuC
messages
Dialog
SuC Action:
Processing
B
A
User
thinking
User Actions
• But what is interaction? A or B
• UML has NO answer but we need correct & precise answer
02 FEB 14
5

6. What is Interaction & its Scope?
SuC
Dialog
SuC Action:
Processing
A
User
thinking
User Actions
B
It should ONLY be DIALOG “A”
02 FEB 14
6

7. Interaction Scope: Only DIALOG!
System option
Dialog
Actor Selection
Interaction is just the DIALOG messages
What happens beyond is
PRIVATE ACTION but NOT INTERACTION
02 FEB 14
7

8. More precisely, UseCase is a Dialog
SuC
 A Dialog of messages
between
 The SuC and
 A User (Actor)
 To reach specified Goal
 This definition
 Adds precision &
 Removes inconsistencies
02 FEB 14
User or
Actor
Use-case
Name 1
Actor UC
Association
8

9. Subject of UseCase Modeling
SuC
 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)
UC1
The UC’s
are NOT
inside SuC
BUT UML
puts them
inside
UC3
UC4
02 FEB 14
9

10. UseCase Modeling Steps
SuC
1. Creating UseCase
Diagram or Table
2. Finding Actors &
UseCases of SuC
3. Defining UseCase Goals
(not emphasized)
UC1
The UC’s
are NOT
inside SuC
BUT UML
puts them
inside
UC3
UC4
02 FEB 14
10

11. Validate & Consolidate the Big Picture
 Don’t miss any
 UseCase Diagram is a
big picture of
 SuC & Actors, UC
Services + Goals
 Check & validate with
stakeholders & Actors
 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-usecase-table-with-actors-goals-08-sep12
02 FEB 14
11

12. 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
02 FEB 14
 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/combineduse-case-description-mock-up-screens-and-systemsequence-diagram
12

13. Sample UseCase & Critiquing
UseCase: ManageBasket
Brief Description: The customer changes the
quantity of an item in the basket
 Critique (vital fields are shown)
 No goal in the description
Primary Actor: Customer
 Enable Customer to change quantity of an
item & update selection & see new costs
Preconditions:
1: The shopping basket contents are visible
 UML has no primary & secondary Actors
Main flow:
1. UC starts with customer selecting an item in the
basket
2. If the Customer selects “delete item”
2.1: SuC removes the item from the basket
3. If the Customer types in a new quantity
3.1 The SuC updates the quantity of the item in
basket
02 FEB 14
 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?
13

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 Services
but NOT Goals
02 FEB 14
 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
14

15. 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, Not clarified
in the UML
 A part or
Spec or
 A component publications
 A Goal
02 FEB 14
 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
SuC
Use-case
Name 1
15
15

16. 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
02 FEB 14
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
16

17. UseCase is only a Dialog
Dialog
SuC
Created during
discussion with
Mujtaba Safdar—
19NOV10
02 FEB 14
 But NOT interaction
 Internal activities of
SuC are beyond
UseCase scope
 Shown in Sequence
Diagram later
Each message is
System Option or
Actor selection
17

18. 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
02 FEB 14
18

19. 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. See
1. 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-usecase
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
02 FEB 14
Section 1
follows
19

20. Section 1:
UseCase Specification
From OMG specification of UML 2.5 Beta
Explanation, comments, errors, inconsistencies and analysis
02 FEB 14
20

21. Use Case: A Great Concept
 Very PROFOUND,
 Originated by Ivar
Jacobson
 Used mostly for IT
and at times non-IT
applications also
02 FEB 14
 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
21

22. 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
02 FEB 14
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
22

23. UseCase Description UML 2.5b & Criticism
1. A UseCase specifies
2. a set of actions
performed 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
02 FEB 14
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’
23

24. 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
02 FEB 14
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
24

25. UML Actor is different from UP Worker
Actor: specifies a role played by a user or any other
system that interacts with the subject (SuC)
UML Standard Graphics
Icon
Alternate Graphic
<<actor>>
Name
Name
I prefer this
02 FEB 14
Worker of
Unified
Process
Used in workflow
diagrams
25

26. 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
02 FEB 14
SuC
Use-case
Name 1
2
3
Use-case
Name n
26

27. Nature of UseCase
The UML specification
1. 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
02 FEB 14
Comments & Explanation
1. The specification is generic
2. An instance is a particular
occurrence
Emergent is something that arises
newly (not predetermined),
It is unique but is within the generic
specification
3 UseCase is described by
Interactions (but what is its scope?)
27

28. 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
02 FEB 14
SuC
Use-case
Name 1
2
3
Actor-UC
Association
Use-case
Name n
28

29. Analysis and Corrections
 Pointed out errors and inconsistencies of UseCase
Specification 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
Think and
Proceed
02 FEB 14
29