Use Case: A Great Concept, The Exact Nature of UC is Not Defined, Here is the The Right Name & Definition + some related concepts. The Right Name; Service Dialog Definition; Service Dialog Structure & parts; Service Dialog Tree Diagram; Unnecessary Details; The Detailed Paper---is still in draft stage. Read my comments. They are my raw thoughts. Don't accept or complain. If you are sufficiently offended, you are in right state for closer interaction. See my PS and let's talk. Welcome.

1. Putcha V. Narasimham
Knowledge Enabler Systems Founder Professor & Proprietor
205, Krishna Apts, Avenue No. 6, Banjara Hills,
Hyderabad 500034
Mobile: 98660 71582 (Till 20MAR13. Use email or Skype)
kenablersys@yahoo.com Skype: prof.pvn
Our Ref: In the footer
Date: 03DEC11 29MAY12, 26NOV12, 09DEC12, T 13FEB13
Redefining
Comment [PVN1]: It may be too late now.
We may NOT really change the name but the
definition and interpretation need change.
UML Use Case as
Service Dialog
Comment [PVN2]: The natural language
meaning: Service related Dialog I claim is more
meaningful IMO.
Putcha V. Narasimham
I have been preparing this comprehensive
proposal but I have not been able to complete
it in view of comments / objections----NOT
because I accept them but I want to point out
why those objections are NOT VALID.
Extended Abstract
Use Case: A Great Concept Comment [PVN3]: Hats off to IVAR
JACOBSON. Its full potential is not exploited.
Use Case is a simple but very profound
concept. However, its very name, and wide
scope of its definition causes a lot of
debates, criticism, and misinterpretation. UML
definition of Actor as Role is not used even
Comment [PVN4]: That is unfortunate.
in professional publications. Several revisions of UML standards seem to
have missed these errors and flaws.
5 Redefining UML Use Case as SERVICE DIALOG---ABSTRACT Page No 1 of 5
The Best Anywhere Must Reach the Needy Everywhere

2. Putcha V. Narasimham
Knowledge Enabler Systems Founder Professor & Proprietor
205, Krishna Apts, Avenue No. 6, Banjara Hills,
Hyderabad 500034
Mobile: 98660 71582 (Till 20MAR13. Use email or Skype)
kenablersys@yahoo.com Skype: prof.pvn
Comment [PVN5]: Very fortunate. This has
The Exact Nature is Not Defined shaken the trust one can have on standards.
They seem to be losing touch with the academic
and professional needs.
The natural language meanings of the words
“use & case” do not give a clear meaning of
the phrase Use Case. The technical definitions
and interpretations have not been of much
help (please read the main paper).
Comment [PVN6]: Some professionals argue
that it does not matter but it is most crucial.
Use Case is mistaken as a process or sub- The definitions must be most unambiguous and
clear. That is the least a standard can provide.
system or part or an object and Some examples and counter examples also
help. I am providing them. I invite readers to
contribute.
represented using inappropriate diagrams:
Activity Diagrams or Sequence Diagrams.
Many professionals do not agree; that is the
problem. If a UC were any of these, there is
no need to create UC in the first place. Comment [PVN7]: This should be most
convincing even before my proposal is read.
Taken another look and think.
Comment [PVN8]: This is another
The pervasive but unacknowledged aggravating aspect of problems with UC.
confusion calls for a redefinition, rather,
the right name and definition of Use Case.
Comment [PVN9]: Please excuse my self-
The Right Name & Definition + proclamation. That is just to make a point. I
hope the reasons I advance would be more
convincing.
This is a long section---all in blue font. Sub-
sections titles are NOT bold.
5 Redefining UML Use Case as SERVICE DIALOG---ABSTRACT Page No 2 of 5
The Best Anywhere Must Reach the Needy Everywhere

3. Putcha V. Narasimham
Knowledge Enabler Systems Founder Professor & Proprietor
205, Krishna Apts, Avenue No. 6, Banjara Hills,
Hyderabad 500034
Mobile: 98660 71582 (Till 20MAR13. Use email or Skype)
kenablersys@yahoo.com Skype: prof.pvn
Comment [PVN10]: I am not modest about
The Right Name it. The name “Use Case” can win the worst
name contest.
Service Dialog has a natural language
meaning: service related dialog. Comment [PVN11]: Is there another possible
interpretation?
A specific Service Dialog with a name
becomes a Named Service that the System
provides.
Service Dialog Definition
An alternating sequence of service-offer
messages from the System followed by
service-selection messages from the
Actor, till a defined Service Goal or
Comment [PVN12]: I took years to arrive at
termination condition is reached. it. I know it is tough.
Contrast it with the UML definition of UC. I am
Briefly, A sequence of service-option messages ashamed I used it in hind-sight. I have an
from the System and selection messages from Appendix on how flawed the UML definition is.
Actor, leading to a Service Goal. Comment [PVN13]: That is dense and pithy.
Comment [PVN14]: This is very long and
Service Dialog Structure & parts
elaborate but skipping it allows all
misinterpretation and misunderstanding to
creep in. Now I understand why math and
science text books define so many terms for all
Most practical Service Dialogs tend to be minor variations. They are necessary for
precision and rigor which UML does not seem to
care. Yet it has such bloated standard.
complex with multiple conditional branches. Comment [PVN15]: It is misleading to define
main or successful path and separate it from
So it has become necessary to define and other alternative and exceptional paths. In a
holistic approach the unity and cohesion of Use
Case must be captured and presented as a
represent parts of Service Dialog---Dialog complete concept. The details can be
developed later---they are evolved from the
Segment, Messages and Dialog Node. integral nature of a UC.
Comment [PVN16]: They too have their own
A complex SD has tree structure. microstructure (signature) which prompt the
designers to think of all the powerful internal
objects of the SuD. They are evolved
iteratively. At the beginning they CANNOT be
specified.
5 Redefining UML Use Case as SERVICE DIALOG---ABSTRACT Page No 3 of 5
The Best Anywhere Must Reach the Needy Everywhere

4. Putcha V. Narasimham
Knowledge Enabler Systems Founder Professor & Proprietor
205, Krishna Apts, Avenue No. 6, Banjara Hills,
Hyderabad 500034
Mobile: 98660 71582 (Till 20MAR13. Use email or Skype)
kenablersys@yahoo.com Skype: prof.pvn
Service Goal is very important in defining Comment [PVN17]: This is far more
important than what the standards recognize.
The goals have to be comprehensive and
and partitioning a Service Dialog. complete encompassing all the conditional
branches / alternatives and even failures. The
idea of separating success and failure of a
single UC is misleading and flawed.
Service Dialog Tree Diagram Comment [PVN18]: This is NOT Use Case
Diagram or System Services Diagram. This is a
diagram of tree structure of each complex
There is no standard name or diagram to service diagram.
show SD structure. Dialog Map (Karl
Wiegers) or Navigation Diagram (Scott
Ambler) may be suitable. That is open, let’s
examine but Activity Diagram or Sequence
Diagram are entirely inappropriate, though Comment [PVN19]: Wait till you read the full
paper when it is uploaded. It is up to you if you
want to jump to conclusions based on what is
they are widely used (that is the problem). known. That is what I am questioning.
Unnecessary Details
We consider that <<Uses>>, <<includes>>, Comment [PVN20]: They flow from the
procedural programming mind set which is
incompatible with OOAD. That needs to be
<<extends>> and System / Business Use shed first. This is a prerequisite to UC
modeling.
Cases are redundant. They are certainly not Comment [PVN21]: This is entirely
unnecessary. This is determined by what the
system is. If the system is only software, then
necessary in the early phases of BA and RE. all the UCs are system UCs. If the System is a
business organization with staff and computers
However, it is useful to distinguish Primary then all the UCs are business UCs. A given
system with a single system boundary cannot
have both types of UCs. It is possible to nest
and Secondary Actors as explained separately computer system within an organization system.
Comment [PVN22]: I tried to ignore this
by Alistair Cockburn & Craig Larman. distinction but it is not helpful to do so. Both
types exist in the same UC diagram and they
differ in their purposes and goals substantially.
Not defined in UML. Another example of OMG’s
PTO supreme wisdom.
5 Redefining UML Use Case as SERVICE DIALOG---ABSTRACT Page No 4 of 5
The Best Anywhere Must Reach the Needy Everywhere

5. Putcha V. Narasimham
Knowledge Enabler Systems Founder Professor & Proprietor
205, Krishna Apts, Avenue No. 6, Banjara Hills,
Hyderabad 500034
Mobile: 98660 71582 (Till 20MAR13. Use email or Skype)
kenablersys@yahoo.com Skype: prof.pvn
Comment [PVN23]: I tried to finish and
The Detailed Paper upload it. It is taking time. Sorry. This is a
tentative step. Hope it helps.
The Use Case Diagram is a part of the detailed
paper. It also contains U C Table that also gives
Use Case Goals. The detailed paper includes
definition tables, templates, appendixes, and
cites cases studies, and standards for
professional use. It provides motivation and
reasons for the proposal.
Comment [PVN24]: I am suggesting
Some reviews by professionals of Linkedin something radically different. All my reasons
are not published or known. So it is difficult for
others who know what is popular to understand
Groups have been helpful. More are welcome why I am rocking the boat.
to revise and increase the usefulness of Please wait. Sorry for springing conclusions
without explanation. See PS.
Service Dialog.
Use Case Description or Details of Dialog are
separately given in another paper.
---III---
PS:
I am willing to share the draft paper for review
and feedback. Email kenablersys@yahoo.com
Putcha
5 Redefining UML Use Case as SERVICE DIALOG---ABSTRACT Page No 5 of 5
The Best Anywhere Must Reach the Needy Everywhere