usecase is a dialog---not a process
DESCRIPTION
[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 14TRANSCRIPT
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