Published on

[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

Published in: Technology, Education
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. UseCase is A DIALOG Putcha V. Narasimham
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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: 02 FEB 14 11
  12. 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: 12
  13. 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. 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. 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. 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. 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. 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. 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. 2. 3. 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. 20. Section 1: UseCase Specification From OMG specification of UML 2.5 Beta Explanation, comments, errors, inconsistencies and analysis 02 FEB 14 20
  21. 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. 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. 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. 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. 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. 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. 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. 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. 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  Think and Proceed 02 FEB 14 29