- The document proposes corrections to errors in use case modeling, defining a use case as a sequence of messages between a system and actor, similar to a BPMN conversation. - It suggests use cases should be modeled externally to the system as hexagons or conversation elements, rather than internally as ovals. Actor should be an external entity rather than role. - A use case can also be modeled as an association class in a class diagram, showing its relationship between an actor class and the system class.

1. ERRORS & Corrections of
UseCase Modeling
Putcha V. Narasimham
Kenablersys@yahoo.com
16 JAN 18 1

2. UseCase Modeling is GREAT
 Hats off to Ivar Jacobson
 The Inventor of UseCase Model
 It is powerful to evolve the System
to be Developed
 But there are too many errors
 They are pointed out and corrected
 Recent BPMN Conversation applies
to UseCase DialogIvar Jacobson
216 JAN 18 2

3. Names & Definitions of UseCase Elements
 Names of UseCase elements are
inappropriate and confusing
 Their definitions are too
informal and incomplete
 Too many inconsistent
statements are scattered in 63
pages of UML 2.5 Specification
 Graphics and explanations are
misleading / inconsistent
 THREE sections here explain
how UseCase is:
 A “Dialog or BPMN
Conversation” in a behavioral
model and
 An “Association Class” in
structural Class Diagram
 In section 3, the benefits of
treating Actor as an entity
are explained
16 JAN 18 3

4. Section 1
UseCase is A Service Dialog
Identification of UseCase as Dialog;
Redefinition, Corrections and Improvements
16 JAN 18 4

5. Problem with UseCase Meaning & Nature
 Ill-defined & uncertain
 It is variously called
Behavior, Action,
Functionality, Interaction,
Process, Part, Sub-system,
Goal…..
 Check out 63 pages of
UML Spec v 2.5
5
UseCase
What is it?
What are its parts?
What is it a part of?
What kind of
thing is it?
What does
it mean?
16 JAN 18 5

6. UseCase: A good and useful concept
 UseCase as a case of use of SuC by an
Actor is OK
 Description of how SuC serves each
Actors helps evolving SuC to meet
business / user needs
 But the exact nature & scope of
UseCase are NOT defined in UML
 It is defined more precisely here
6
UseCase
SuC
Actor
By
Is a
case of
use of
616 JAN 18

7. What kind of thing is UseCase
 Of the various descriptions, “Interaction” is
close but
 “Interaction” itself is NOT precisely defined
 Let us analyze and define “Interaction”
more precisely
16 JAN 18 7

8. Elements of SuC-Actor Interaction
 Three are FIVE elements
 2 is a part of 1 and 5 is a part of 4; They are all defined
 Of these five, only “Dialog” is NOT defined
8
2 Internal
Activity:
Processing
1 SuC
3 Dialog
4 Actor
5
Internal
Activity:
Thinking

9. The Distinct Element “Dialog” is UseCase
 Dialog: Alternating sequence of messages from SuC & Actor
 Message: a sequence of Information and data (Knuth’s Def)
 UseCase does NOT include the actions of SuC or Actor
9
Dialog =
UseCase Message

10. UseCase: A Sequence of Messages, A Dialog
1. UseCase Dialog is a sequence of
alternating messages between
SuC and Actor, leading to
UseCase Goal --- Proposed and
pursued by the author since 2008
2. Dialog or Conversation is NOT
defined in UML
3. In 2011 BPMN defined
“conversation” (same as 1.)
10
Message
from Actor
Created during discussion with Mujtaba
Safdar—19NOV10
Message
from SuC

11. Scope & Nature of UseCase---Conclusion
1. The scope of Interactions can ONLY be the “Messages of
Dialog of Service” between SuC and Actor but NOT their
Activities
2. Messages are based on business or user needs
3. The ACTIVITIES of SuC CANNOT be parts of DIALOG
4. They are NOT known at this stage,
5. They need to be designed later based on 2
16 JAN 18 11

12. BPMN defined “Conversation” in 2011
 BPMN defined “Conversation”
as a distinct new modeling
element in 2011
 The Hexagon on a double line
represents “conversation”
 The bidirectional messages
constituting conversation are
expanded and shown
 UseCase is just that precisely
16 JAN 18 12
SuC Actor
SuC Actor
Service
Dialog ID

13. BPMN Conversation applied to UseCase
13
UseCase
Dialog
SuC
Actor
Activities of SuC and Actor are internal to them
BUT Dialog between SuC and Actor is EXTERNAL to them
UseCase is just “A Sequence of Messages”, a Conversation or Dialog
Messages
16 JAN 18 13

14. UseCase Redefined & Repositioned
 UseCase is a Service Dialog
between SuC & Actor
 UseCase Oval should be
EXTERNAL to SuC
 It is better off as BPMN Hexagon
 The association line is replaced
by a conversation double line
 This is more precise & clear
Actor
UC
16 JAN 18 14
Not internal
to SuC
SuC
Association line
SuC UC
Name
Actor
Communication
double line

15. Corrected (UseCase?) Diagram
 SuC is a blackbox--No
UseCase ovals inside
 SuC internals: yet to evolve
 Actor, human or machine, is
better represented by a
rectangle—NOT Stick figure
 Hexagon replaces UC Oval
and appears outside SuC
correctly
 Is it still UseCase Diagram?1 thrugh 6: Actor Classes
SuC
1Actor 1
Actor 3
Actor 2
Actor 4
Actor 5
Actor 66
2
3
5
4
S-Dialog 1
S-Dialog 4
16 JAN 18 15

16. What is the RIGHT name of this Diagram?
 Three three elements: SuC,
Actors, & Service Dialogs
 The name of composite
diagram cannot be the same
name of any of its elements
 It is a Diagram of “SuC with
Actors & Dialogs”
 Let’s coin an apt name
1 thrugh 6: Actor Classes
SuC
1Actor 1
Actor 3
Actor 2
Actor 4
Actor 5
Actor 66
2
3
5
4
S-Dialog 1
S-Dialog 4
16 JAN 18 16

17. Section 2
UseCase in a Class Diagram
A modeling element can be shown in
different models / diagrams in different ways.
16 JAN 18 17

18. Multiple forms of a modeling element
 The “Association” between two
classes in a structural diagram
(Class Diagram) appears as
“Association Class”
 In an Activity Diagram the objects
of the classes appear in two
swim-lanes
 The “Activities” of objects of each
class appear in corresponding
swim-lanes of the objects
 Similarly, UseCase appears as
“Association Class” in a Class
Diagram of SuC & Actor
 Messages DO NOT appear in
Class Diagrams
 But they appear in a
Conversation Diagram
between the SuC and Actor
 See the UseCase as
Association Class here

19. Class Diagram of SuC and Actor Classes
 This is a structural or static
diagram showing relations
 In this Class Diagram each
Actor Class (1 through 6) is
associated with SuC
 Details of Association are
shown in the next slide
1 thrugh 6: Actor Classes
SuC
Actor 1
Actor 3
Actor 2
Actor 4
Actor 5
Actor 6
S-Dialog 1
S-Dialog 4
16 JAN 18 19

20. Association Class models UseCase Correctly
 In a Class Diagram UseCase
is modeled perfectly as an
Association Class
 Actor 1 is associated with
SuC as a whole
 UseCase is NOT an internal
part of SuC
 No internals of SuC are
known at this stage
SuCActor 1
UseCase Name
Attributes
UseCase as
Association
Class
The Association Line
is a solid line

21. Section 3
Actor Modeled as External Entity
UML created Actor as “Role Player” (one Actor one role) but
most users invariably assign multiple roles to Actor. So, it is
better to consider Actor to be an External Entity.
16 JAN 18 21

22. UML Actor: Player of Specified Role
 Actor is a special term introduced by UML
 Actor is NOT a generic entity who / which acts
 UML Actor plays (or should play) only a specified role
 Every specified role must have distinct role name
 What do you call an entity which does: login, load,
checkout, withdraw, retry?
 Actor must be external to and independent of the SuC
 These distinctions are not rigorously applied
22
Plays
Specified
Role
16 JAN 18 22

23. Actor has one and only one UseCase
 If Actor plays ONLY a specific role,
this rule can be applied strictly
 But, that entails too many Actors
with distinct ROLE NAMES
 Not easy in practice
 So, it is better to model Actor as
an Entity (which is being done by
default)---Reasons explained here
23
SuC
ActorService
Dialog ID
16 JAN 18 23

24. External Entity
 Entity is a generic thing that exists and has a name
 An External Entity may play many roles
 Role played by an EE may not have explicit name
but it does not matter
 External Entity is external to and independent of
the SuC
 Widely used but Actor Dialog associations get
complicated
24
External
Entity
Can be human
or a device
Plays many Roles
16 JAN 18 24

25. Complication of Entity Dialog Associations
25
 Two or more External Entities
EE1, EE2 & EE3, playing the
same role are permitted to have
the same conversation
 However two EEs playing
different roles cannot have the
same conversation / UseCase
 Though Buyer, Seller and Bank
are all involved in Buying, Buy
Dialog belongs only to Buyer
SuC
EE1,
EE2,
EE3.
SuC
Buyer,
Seller,
Bank
OK
NOT
OK
16 JAN 18 25
Log In
Buy

26. Treat Actor as An External Entity
26
 Pros and cons are discussed
 Most users of UML DO NOT
know that Actor is a specific role
 They treat Actor as EE
 It is advantageous to go back to
familiar EE
 It is widely used by default
anyway
SuC
Ext
Entities
1,2,3
SuC
Buyer,
Seller,
Bank
OK
NOT
OK
16 JAN 18 26
Log In
Buy

27. Understanding UseCase as Service Dialog
1. UseCase misunderstood and misapplied extensively
2. Applying BPMN Conversation to UseCase brings clarity and
precision to model UseCase as Service Dialog
3. Service Goals need to be formally defined and applied---not
covered here
4. UseCase Descriptions are textual / informal / imprecise;
5. Messages of Service Dialog are structured and specific (narrative
text can still be used)
6. Applied & validated since 2008 Uploaded to SlideShare
2716 JAN 18 27

28. Summary and Conclusion
 UseCase is a simple but profound / useful concept
 It directs & drives BA, RE and SE
 It can be modeled as Association Class directly
 UseCase is essentially a Service Dialog for which there
is NO exact modeling element in UML
 BPMN “Conversation” models dialog specifically and it
can model UseCase perfectly
 See the other PPTs and PDF on
http://www.slideshare.net/putchavn
Keep
Going
282816 JAN 18