An Examination of Use Cases  Mark Smith  Director Operations Support Services Adaptis, Inc. ( [email_address] )
Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is …  </li></ul><...
The Use Case Model Definition <ul><li>A model of a domain or subject area </li></ul><ul><ul><li>A collection of use cases ...
Use Case Model Elements Name & description of domain or project  Use case map <ul><li>Actor list </li></ul><ul><li>Roles  ...
The Use Case Map Tabular form   <ul><li>Groups together all the use cases for an individual actor </li></ul><ul><li>Tabula...
The Missing Link <ul><li>Use Case Model  </li></ul><ul><li>Links the high-level context diagram and the individual system ...
Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is …  </li></ul><...
A use case is … <ul><li>A structured textual specification </li></ul><ul><li>Tells  who  (the actor) does  what  (the task...
In general - a Use Case <ul><li>Describes a task </li></ul><ul><ul><li>Performed by an actor </li></ul></ul><ul><ul><li>Yi...
Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is …  </li></ul><...
Level of detail Illustration taken from  Writing Effective Use Cases  – Alistair Cockburn Atomic, user level use cases are...
Atomic vs. Composite use cases <ul><li>Atomic </li></ul><ul><li>Singular with respect to: </li></ul><ul><ul><li>Who  </li>...
Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is …  </li></ul><...
A Use Case may have many paths <ul><li>A use case </li></ul><ul><ul><li>Has only one goal, with a single </li></ul></ul><u...
Success and Failure <ul><li>Each path may lead to </li></ul><ul><ul><li>Success </li></ul></ul><ul><ul><ul><li>A scenario ...
The Basic Path <ul><li>Each use case has </li></ul><ul><ul><li>A start state </li></ul></ul><ul><ul><ul><li>Pre-conditions...
Alternative Paths <ul><li>Each use case may have extensions that result in achieving the goal  </li></ul><ul><li>These may...
Exception Paths <ul><li>Each use case may have extensions where the  desired result is not achieved </li></ul><ul><li>Thes...
The Use Case Specification <ul><li>A system use case will specify a collection of paths (scenarios) </li></ul><ul><li>Use ...
Complete specification of all paths <ul><li>A fully specified use case will define all of the ways in which the goal can b...
Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is …  </li></ul><...
Level of abstraction: Business vs System <ul><li>A use case can stated in general terms, or  specific to the technology re...
Business  use case spec - example <ul><li>Title </li></ul><ul><ul><li>Banking customer withdraws cash </li></ul></ul><ul><...
System  use case spec - example <ul><li>Title </li></ul><ul><ul><li>ATM customer withdraws cash </li></ul></ul><ul><li>Tri...
Business  &  system  example – basic path <ul><li>Basic course of action </li></ul><ul><li>Customer identifies self </li><...
Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is …  </li></ul><...
Some use cases may be sufficiently specified at level II Stop when sufficient detail is achieved Unfolding The  use case m...
Establish the foundation <ul><li>Focus on the big picture </li></ul><ul><li>- steps I & II pertain to the use case model <...
Unfold each use case – level by level <ul><li>Detailed analysis may be planned for an appropriate iteration </li></ul><ul>...
Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is …  </li></ul><...
Supporting Views <ul><li>Summary or Scope - Use case diagram </li></ul><ul><li>Use case dependency – Activity diagram </li...
Example of use case diagram <<extends>> Limits exceeded Trader Analyze risk Price deal Capture deal Salesperson Valuation ...
Another Use Case Diagram
Diagramming Use Case Dependencies <ul><li>UML activity diagrams may be used to </li></ul><ul><ul><li>Show use case sequenc...
Use Case and High Level Sequence Diagram Find a Claim – Use Case (Design considerations in parenthesis) Basic Path  1. Use...
Diagramming interaction - Make a phone call Interaction diagram illustrates  basic course
Composite – representing multiple scenarios <ul><li>State diagram summarizes </li></ul><ul><li>Basic course &  </li></ul><...
CRUD Matrix  Combining Use Case & Class Views Entity classes Use Cases &   Scenarios Use Case Class UC UC UC Class Class C...
Modeling Entity State Behavior Use Case Entity UC UC UC Entity Entity Entity C U U C D C Use Cases Entity State Model S 1 ...
Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is …  </li></ul><...
Components of a Use Case <ul><li>A use case template may contain the following elements.  </li></ul><ul><ul><li>Title </li...
Title <ul><li>Title </li></ul><ul><li>Should state the goal of the use case </li></ul><ul><ul><li>End result that is of bu...
Title  (continued) <ul><li>Title </li></ul><ul><li>Try the “reverse it” test </li></ul><ul><ul><li>Flip the verb noun phra...
Actors <ul><li>Actors </li></ul><ul><li>The Primary Actor is the person (role) or external system  initiating  the use cas...
Description <ul><li>Description </li></ul><ul><li>A brief summary </li></ul><ul><li>Elaborates on the title </li></ul><ul>...
Description  (continued) <ul><li>Description </li></ul><ul><li>The description may </li></ul><ul><ul><li>Start as  a narra...
Initiation of a use case <ul><li>How the trigger event and pre-conditions work together … </li></ul><ul><li>When the trigg...
Trigger <ul><li>Trigger  </li></ul><ul><li>An event that initiates an occurrence of the use case </li></ul><ul><ul><li>Sou...
Pre-conditions <ul><li>Pre-conditions </li></ul><ul><li>Assertions stating what conditions must be true in order for an oc...
Initiation  –Special case <ul><li>There may not be a single triggering event </li></ul><ul><li>The special case in general...
Post-conditions <ul><li>Post-condition  </li></ul><ul><li>An assertion stating what conditions are true upon the successfu...
Basic Path <ul><li>Basic path </li></ul><ul><li>Typical, most frequent, shortest, simplest … </li></ul><ul><li>Enumerates ...
Alternative Path <ul><li>Alternative path </li></ul><ul><li>Describes an extension to the basic path </li></ul><ul><ul><li...
Exception Path <ul><li>Exception path </li></ul><ul><li>Describes an extension to the basic path </li></ul><ul><ul><li>Sta...
 
Upcoming SlideShare
Loading in...5
×

Use Cases A Comprehensive Look

4,612

Published on

Published in: Business, Technology
4 Comments
21 Likes
Statistics
Notes
No Downloads
Views
Total Views
4,612
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
4
Likes
21
Embeds 0
No embeds

No notes for slide
  • This page, along with the following pages, presents a complete use case specification using the template presented on the previous page.
  • This page, along with the following pages, presents a complete use case specification using the template presented on the previous page.
  • This is the basic course of action of the ATM customer withdraws cash use case.
  • To be completed
  • Use Cases A Comprehensive Look

    1. 1. An Examination of Use Cases Mark Smith Director Operations Support Services Adaptis, Inc. ( [email_address] )
    2. 2. Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is … </li></ul></ul><ul><ul><li>Level of detail </li></ul></ul><ul><ul><li>Paths </li></ul></ul><ul><ul><li>Purpose of specification </li></ul></ul><ul><li>Elaboration (unfolding) </li></ul><ul><li>Graphical representation </li></ul><ul><li>Use case specification </li></ul>
    3. 3. The Use Case Model Definition <ul><li>A model of a domain or subject area </li></ul><ul><ul><li>A collection of use cases </li></ul></ul><ul><ul><li>Defines “who” does “what” </li></ul></ul><ul><ul><ul><li>Who – the list of actors </li></ul></ul></ul><ul><ul><ul><li>What – the list of use cases </li></ul></ul></ul><ul><ul><li>May have a business and/or system focus </li></ul></ul><ul><li>Contains </li></ul><ul><ul><li>An overview of the domain or project </li></ul></ul><ul><ul><li>A use case “map” (summary of the use cases) </li></ul></ul><ul><ul><li>Actor descriptions </li></ul></ul><ul><ul><li>The detailed use case specifications </li></ul></ul>
    4. 4. Use Case Model Elements Name & description of domain or project Use case map <ul><li>Actor list </li></ul><ul><li>Roles </li></ul><ul><li>Descriptions </li></ul>Model <ul><li>Use Case Specification </li></ul><ul><li>Title </li></ul><ul><li>Description </li></ul><ul><li>Pre & Post Conditions </li></ul><ul><li>Basic course of action </li></ul><ul><li>. . . </li></ul><ul><li>Use Case Specification </li></ul><ul><li>Title </li></ul><ul><li>Description </li></ul><ul><li>Pre & Post Conditions </li></ul><ul><li>Basic course of action </li></ul><ul><li>. . . </li></ul><ul><li>Use Case Specification </li></ul><ul><li>Title </li></ul><ul><li>Description </li></ul><ul><li>Pre & Post Conditions </li></ul><ul><li>Basic course of action </li></ul><ul><li>. . . </li></ul><ul><li>Use Case Specification </li></ul><ul><li>Title </li></ul><ul><li>Description </li></ul><ul><li>Pre & Post Conditions </li></ul><ul><li>Basic course of action </li></ul><ul><li>. . . </li></ul>
    5. 5. The Use Case Map Tabular form <ul><li>Groups together all the use cases for an individual actor </li></ul><ul><li>Tabular, use case or package diagram format </li></ul><ul><li>Together - the use case maps define the scope being modeled </li></ul>Use Case Title Actor Schedule patient for appointment Receptionist Research Claim Billing Clerk Refer patient Referral Coord. Check patient for appointment Receptionist Use Case Diagram Package Diagram
    6. 6. The Missing Link <ul><li>Use Case Model </li></ul><ul><li>Links the high-level context diagram and the individual system use cases </li></ul><ul><li>Roadmap of the ground --scope-- the project will cover </li></ul><ul><li>Connects initial project goals and development activities </li></ul><ul><li>Excellent tool for keeping resources focused on value-added activities </li></ul>
    7. 7. Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is … </li></ul></ul><ul><ul><li>Level of detail </li></ul></ul><ul><ul><li>Paths </li></ul></ul><ul><ul><li>Purpose of specification </li></ul></ul><ul><li>Elaboration (unfolding) </li></ul><ul><li>Graphical representation </li></ul><ul><li>Use case specification </li></ul>
    8. 8. A use case is … <ul><li>A structured textual specification </li></ul><ul><li>Tells who (the actor) does what (the task) </li></ul>Actor Name Role of person performing task or interacting with system Desired result of value to actor Customer Pays bill Use case diagram <ul><li>Use Case Specification </li></ul><ul><li>Title: Customer pays bill </li></ul><ul><li>Description </li></ul><ul><li>Pre-condition </li></ul><ul><li>Post-condition </li></ul><ul><li>Basic path </li></ul><ul><li>Alternative paths </li></ul><ul><li>Exception paths </li></ul><ul><li>. . . </li></ul>Use case specification
    9. 9. In general - a Use Case <ul><li>Describes a task </li></ul><ul><ul><li>Performed by an actor </li></ul></ul><ul><ul><li>Yielding a result of business value </li></ul></ul><ul><li>Business or system focus </li></ul><ul><li>Task may be </li></ul><ul><ul><li>Interactive </li></ul></ul><ul><ul><ul><li>A system use case describes an actor’s interaction with a system in pursuit of the defined business goal </li></ul></ul></ul><ul><ul><li>Manual </li></ul></ul><ul><ul><ul><li>A sequence of actions performed by an actor </li></ul></ul></ul><ul><ul><li>Automated </li></ul></ul><ul><ul><ul><ul><li>A sequence of steps performed by a program or script </li></ul></ul></ul></ul><ul><li>Customer pays bill </li></ul>
    10. 10. Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is … </li></ul></ul><ul><ul><li>Level of detail </li></ul></ul><ul><ul><li>Paths </li></ul></ul><ul><ul><li>Purpose of specification </li></ul></ul><ul><li>Elaboration (unfolding) </li></ul><ul><li>Graphical representation </li></ul><ul><li>Use case specification </li></ul>
    11. 11. Level of detail Illustration taken from Writing Effective Use Cases – Alistair Cockburn Atomic, user level use cases are the goal for system requirements specification Summary User Sub-function Atomic Composite Business process Activity Activity Activity UC UC UC UC UC UC UC UC
    12. 12. Atomic vs. Composite use cases <ul><li>Atomic </li></ul><ul><li>Singular with respect to: </li></ul><ul><ul><li>Who </li></ul></ul><ul><ul><ul><li>One primary actor </li></ul></ul></ul><ul><ul><li>What </li></ul></ul><ul><ul><ul><li>One primary goal </li></ul></ul></ul><ul><ul><li>When </li></ul></ul><ul><ul><ul><li>Once started, must be completed </li></ul></ul></ul><ul><ul><li>How </li></ul></ul><ul><ul><ul><li>Is interactive, manual, or automated, but not a combination </li></ul></ul></ul><ul><li>May be a candidate for decomposition if </li></ul><ul><li>It involves more that one actor that initiates an action </li></ul><ul><li>Has two or more independent, well defined goals </li></ul><ul><li>May be accomplished in independent steps (at different times) </li></ul><ul><li>Is partially supported by a system (interactive or automated) and a partially manual task </li></ul>
    13. 13. Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is … </li></ul></ul><ul><ul><li>Level of detail </li></ul></ul><ul><ul><li>Paths </li></ul></ul><ul><ul><li>Purpose of specification </li></ul></ul><ul><li>Elaboration (unfolding) </li></ul><ul><li>Graphical representation </li></ul><ul><li>Use case specification </li></ul>
    14. 14. A Use Case may have many paths <ul><li>A use case </li></ul><ul><ul><li>Has only one goal, with a single </li></ul></ul><ul><ul><ul><li>Starting point </li></ul></ul></ul><ul><ul><ul><li>Ending point </li></ul></ul></ul><ul><ul><li>May describe multiple paths for getting from start to finish </li></ul></ul><ul><ul><ul><li>I.E. specify behavior for a variety of possible conditions </li></ul></ul></ul><ul><ul><ul><li>Each conditions may require specific action(s) </li></ul></ul></ul><ul><li>Example </li></ul><ul><ul><li>“ Customer pays bill” </li></ul></ul><ul><ul><ul><li>Multiple paths to achieve the goal </li></ul></ul></ul><ul><ul><ul><ul><li>Telephone payment </li></ul></ul></ul></ul><ul><ul><ul><ul><li>By mail </li></ul></ul></ul></ul><ul><ul><ul><ul><li>In person </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>by check </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>cash, etc. </li></ul></ul></ul></ul></ul><ul><ul><ul><li>A path that does not lead to the goal </li></ul></ul></ul><ul><ul><ul><ul><li>Credit card is declined </li></ul></ul></ul></ul>
    15. 15. Success and Failure <ul><li>Each path may lead to </li></ul><ul><ul><li>Success </li></ul></ul><ul><ul><ul><li>A scenario where the goal is achieved </li></ul></ul></ul><ul><ul><ul><li>The basic success scenario </li></ul></ul></ul><ul><ul><ul><ul><li>Typical or normal success path </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Often referred to as the “ happy path .” </li></ul></ul></ul></ul><ul><ul><ul><li>Other success scenarios are called alternate paths </li></ul></ul></ul><ul><ul><li>Failure </li></ul></ul><ul><ul><ul><li>A scenario where the goal is not achieved but still protects the interests of the stakeholders . </li></ul></ul></ul>
    16. 16. The Basic Path <ul><li>Each use case has </li></ul><ul><ul><li>A start state </li></ul></ul><ul><ul><ul><li>Pre-conditions define what must be true at the starting point </li></ul></ul></ul><ul><ul><li>An end state </li></ul></ul><ul><ul><ul><li>Post-conditions define will be true upon successful conclusion </li></ul></ul></ul><ul><ul><li>A basic or “happy” path </li></ul></ul><ul><ul><ul><li>The simplest, “normal”, or most frequent set of steps for achieving the goal </li></ul></ul></ul>Pre-conditions Start Post-conditions End Action 1 Action 2 Action 3 Action 4
    17. 17. Alternative Paths <ul><li>Each use case may have extensions that result in achieving the goal </li></ul><ul><li>These may be referred to as alternate paths </li></ul><ul><ul><li>Alternatate </li></ul></ul><ul><ul><ul><li>Departs after action 1 of the basic path </li></ul></ul></ul><ul><ul><ul><li>Rejoins before action 4 </li></ul></ul></ul><ul><ul><li>Alternatate </li></ul></ul><ul><ul><ul><li>Departs after 1 st action of the alternative path </li></ul></ul></ul><ul><ul><ul><li>Rejoins before action 4 </li></ul></ul></ul>Pre-conditions Start Post-conditions End Action 1 Action 2 Action 3 Action 4
    18. 18. Exception Paths <ul><li>Each use case may have extensions where the desired result is not achieved </li></ul><ul><li>These may be referred to as exception paths </li></ul><ul><ul><li>Exception 1 </li></ul></ul><ul><ul><ul><li>Departs after action 3 of the basic path </li></ul></ul></ul><ul><ul><ul><li>Does not rejoin the basic path </li></ul></ul></ul><ul><ul><ul><li>The use case terminates </li></ul></ul></ul>Pre-conditions Start Post-conditions End Action 1 Action 2 Action 3 Action 4
    19. 19. The Use Case Specification <ul><li>A system use case will specify a collection of paths (scenarios) </li></ul><ul><li>Use Case Specification </li></ul><ul><li>Title </li></ul><ul><li>Description </li></ul><ul><li>Pre & Post Conditions </li></ul><ul><li>Basic Path </li></ul><ul><li>Alternative Path </li></ul><ul><li>Alternative Path </li></ul><ul><li>Alternative Path </li></ul><ul><li>Alternative Path </li></ul><ul><li>Exception Path </li></ul>
    20. 20. Complete specification of all paths <ul><li>A fully specified use case will define all of the ways in which the goal can be achieved </li></ul><ul><ul><li>All the paths from start to finish </li></ul></ul><ul><ul><li>All the way in which the activity can fail to complete </li></ul></ul><ul><li>Specification Guideline : The 80/20 rule for alternate and exception paths </li></ul><ul><ul><li>Identify the condition </li></ul></ul><ul><ul><li>Determine the frequency of occurrence </li></ul></ul><ul><ul><li>Assigned a priority or rank </li></ul></ul><ul><ul><li>And, only if necessary, specify the actions of the path </li></ul></ul><ul><li>Intent : Not to spend a significant amount of effort designing a process/system for a possibility that will rarely occur! </li></ul>Agile concepts!
    21. 21. Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is … </li></ul></ul><ul><ul><li>Level of detail </li></ul></ul><ul><ul><li>Paths </li></ul></ul><ul><ul><li>Purpose of specification - Business vs. System Use Cases </li></ul></ul><ul><li>Elaboration (unfolding) </li></ul><ul><li>Graphical representation </li></ul><ul><li>Use case specification </li></ul>
    22. 22. Level of abstraction: Business vs System <ul><li>A use case can stated in general terms, or specific to the technology required to accomplish the task </li></ul><ul><li>Business focus (Technology/tool independent) </li></ul><ul><ul><li>Perspective: business role of the primary actor </li></ul></ul><ul><ul><li>Portrays essence of business function </li></ul></ul><ul><ul><li>Uses terminology of business domain </li></ul></ul><ul><ul><li>Independent of specific tools required to perform the task </li></ul></ul><ul><li>System focus (UI independent) </li></ul><ul><ul><li>Perspective: business/end user role of the primary actor </li></ul></ul><ul><ul><li>Portrays essence of system interaction </li></ul></ul><ul><ul><li>Uses terminology of the business & system domain </li></ul></ul><ul><ul><li>Independent of specific user interface </li></ul></ul><ul><li>System focus (UI specific) </li></ul><ul><ul><li>Perspective: business/end user role of the primary actor </li></ul></ul><ul><ul><li>Portrays specifics of system interaction </li></ul></ul><ul><ul><li>Uses terminology of the application domain </li></ul></ul><ul><ul><li>Specific to the application use to perform the task </li></ul></ul>
    23. 23. Business use case spec - example <ul><li>Title </li></ul><ul><ul><li>Banking customer withdraws cash </li></ul></ul><ul><li>Triggering event </li></ul><ul><ul><li>Customer identifies self </li></ul></ul><ul><li>Description </li></ul><ul><ul><li>Customer withdraws cash from a bank account </li></ul></ul><ul><li>Pre-conditions </li></ul><ul><ul><li>Account referenced (e.g., checking) is in good standing </li></ul></ul><ul><ul><li>Account balance > withdrawal amount </li></ul></ul><ul><li>Post-conditions </li></ul><ul><ul><li>Account has been debited </li></ul></ul><ul><li>Basic course of action </li></ul><ul><ul><li>… </li></ul></ul>Business use case – business task view
    24. 24. System use case spec - example <ul><li>Title </li></ul><ul><ul><li>ATM customer withdraws cash </li></ul></ul><ul><li>Triggering event </li></ul><ul><ul><li>Card inserted into ATM machine </li></ul></ul><ul><li>Description </li></ul><ul><ul><li>Customer withdraws cash from a bank account using an ATM </li></ul></ul><ul><li>Pre-conditions </li></ul><ul><ul><li>Account referenced (e.g., checking) is in good standing </li></ul></ul><ul><ul><li>Account balance > withdrawal amount </li></ul></ul><ul><li>Post-conditions </li></ul><ul><ul><li>Account has been debited </li></ul></ul><ul><li>Basic course of action </li></ul><ul><ul><li>… </li></ul></ul>System use case –business task view utilizing a system to complete the task
    25. 25. Business & system example – basic path <ul><li>Basic course of action </li></ul><ul><li>Customer identifies self </li></ul><ul><li>Customer makes “withdrawal” request </li></ul><ul><ul><li>Transaction account </li></ul></ul><ul><ul><li>Transaction amount </li></ul></ul><ul><li>Bank representative </li></ul><ul><ul><li>Dispenses cash </li></ul></ul><ul><ul><li>Provides transaction receipt </li></ul></ul><ul><li>Inquires if another transaction is desired </li></ul><ul><li>Customer indicates “no” </li></ul><ul><li>Basic course of action </li></ul><ul><li>Customer inserts card </li></ul><ul><li>System prompts for PIN </li></ul><ul><li>Customer enters PIN </li></ul><ul><li>System asks for transaction type </li></ul><ul><li>Customer indicates “withdrawal” </li></ul><ul><li>System asks for account type </li></ul><ul><li>Customer indicates account type </li></ul><ul><li>System asks for amount </li></ul><ul><li>Customer enters amount </li></ul><ul><li>System displays advertisement </li></ul><ul><li>System dispenses cash </li></ul><ul><li>System prints receipt </li></ul><ul><li>Systems asks “another transaction?” </li></ul><ul><li>Customer indicates “no” </li></ul><ul><li>System ejects card </li></ul><ul><li>Systems displays start screen </li></ul>
    26. 26. Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is … </li></ul></ul><ul><ul><li>Level of detail </li></ul></ul><ul><ul><li>Paths </li></ul></ul><ul><ul><li>Purpose of specification </li></ul></ul><ul><li>Elaboration (unfolding) </li></ul><ul><li>Graphical representation </li></ul><ul><li>Use case specification </li></ul>
    27. 27. Some use cases may be sufficiently specified at level II Stop when sufficient detail is achieved Unfolding The use case model and its individual use cases evolve level by level over time Not all use cases of a model will necessarily need to be specified to the same level of detail Alternate & Exception Paths Basic Path Pre- & Post-conditions Name & Description Includes/ Extends Relationships L 1 Level 2 Level 3 Level 4 Level 5
    28. 28. Establish the foundation <ul><li>Focus on the big picture </li></ul><ul><li>- steps I & II pertain to the use case model </li></ul><ul><li>I. Define the scope by completing the use case map </li></ul><ul><ul><ul><li>List actors </li></ul></ul></ul><ul><ul><ul><li>Enumerate use cases for each actor </li></ul></ul></ul><ul><li>II. Refine the model & understand dependencies </li></ul><ul><ul><ul><li>Identify beginning & end points for each </li></ul></ul></ul><ul><ul><ul><li>Define pre- and post-conditions </li></ul></ul></ul><ul><ul><ul><li>Determine “how often” each case occurs </li></ul></ul></ul><ul><ul><ul><li>Sketch the work flow showing the dependencies </li></ul></ul></ul><ul><li>As the model evolves cases may be added, dropped or their priority changed </li></ul>
    29. 29. Unfold each use case – level by level <ul><li>Detailed analysis may be planned for an appropriate iteration </li></ul><ul><li>- steps III & IV pertain to individual use cases </li></ul><ul><li>III – Individual use cases - define basic path </li></ul><ul><ul><li>Actions that comprise “happy path” </li></ul></ul><ul><li>IV – Define extensions </li></ul><ul><ul><li>Alternative paths </li></ul></ul><ul><ul><ul><li>Identify conditions, frequency, & steps for each (as needed) </li></ul></ul></ul><ul><ul><li>Exception paths </li></ul></ul><ul><ul><ul><li>Identify conditions, frequency, & steps for each (as needed) </li></ul></ul></ul><ul><li>V - Refine structure </li></ul><ul><ul><li>May be illustrated with a use case diagram </li></ul></ul><ul><ul><li>Identify common actions (<<includes>> relationships) </li></ul></ul><ul><ul><li>Diagram key special cases (<<extends>> relationships) </li></ul></ul>
    30. 30. Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is … </li></ul></ul><ul><ul><li>Level of detail </li></ul></ul><ul><ul><li>Paths </li></ul></ul><ul><ul><li>Purpose of specification </li></ul></ul><ul><li>Elaboration (unfolding) </li></ul><ul><li>Graphical representation </li></ul><ul><ul><li>Additional views & supporting UML diagrams </li></ul></ul><ul><li>Use case specification </li></ul>
    31. 31. Supporting Views <ul><li>Summary or Scope - Use case diagram </li></ul><ul><li>Use case dependency – Activity diagram </li></ul><ul><li>Scenario interaction – Interaction diagram </li></ul><ul><li>Scenario – composite view – State diagram </li></ul><ul><li>Entity state (from use cases) - State diagram </li></ul>
    32. 32. Example of use case diagram <<extends>> Limits exceeded Trader Analyze risk Price deal Capture deal Salesperson Valuation <<includes>> <<includes>>
    33. 33. Another Use Case Diagram
    34. 34. Diagramming Use Case Dependencies <ul><li>UML activity diagrams may be used to </li></ul><ul><ul><li>Show use case sequence </li></ul></ul><ul><ul><li>Provide a view of a the business activity </li></ul></ul>[No covered] [Authorization not required] [Covered] Admit Patient Check Eligibility /Benefit Notify Health Plan Request authorization Confirm authorization [Authorization required]
    35. 35. Use Case and High Level Sequence Diagram Find a Claim – Use Case (Design considerations in parenthesis) Basic Path 1. User initiates a claim search per submitted criteria. 2. System returns subset of search results (display of 10 @ a time) 3. User selects claim (click item in upper list pane; item highlighted) 4. System returns claim summary (lower preview pane) 5. User requests full claim detail (link/button from preview pane) 6. System returns full claim detail (pop up -claim header with vertical list of services and encounter details) 7. Repeats process if applicable beginning at step 3 or back to step 1. Alternate Path – Encounter Detail Leaves Basic Path after 4. Returns to Basic Path at 7 1. User requests Encounter detail (encounter hyperlink in claim summary) 2. System returns Encounter detail (pop up -claim header & encounter header with vertical list of service level details) Alternate Path – Claim Detail via Encounter Detail Leaves Basic Path after 4 Returns to Basic Path at 6 1. User requests Encounter detail (encounter hyperlink in claim summary) 2. System returns Encounter detail (claim header & encounter header with vertical list of service level details) 3. User requests full claim detail (link/button from encounter detail screen) Alternate Path – Sort Leaves Basic Path after 2 Returns to Basic Path at 3 1. User sorts list by column heading (i.e. Dates of Service in ascending order) 2. System returns subset of search results in new sort order. (Different set of 10 from full search results) Exception Path - Invalid Search Criteria Leaves Basic Path after 1 1. System returns no records that match criteria 2. System returns error message 3. System directs user back to search page (Can we maintain state from previous search?)
    36. 36. Diagramming interaction - Make a phone call Interaction diagram illustrates basic course
    37. 37. Composite – representing multiple scenarios <ul><li>State diagram summarizes </li></ul><ul><li>Basic course & </li></ul><ul><li>7 alternative paths </li></ul>
    38. 38. CRUD Matrix Combining Use Case & Class Views Entity classes Use Cases & Scenarios Use Case Class UC UC UC Class Class Class C U U C D C Use Cases Class Model
    39. 39. Modeling Entity State Behavior Use Case Entity UC UC UC Entity Entity Entity C U U C D C Use Cases Entity State Model S 1 S 2 S 3 Class S 1 S 2 S 3
    40. 40. Use Case Topics <ul><li>The Use Case Model </li></ul><ul><li>The Basics </li></ul><ul><ul><li>A Use Case is … </li></ul></ul><ul><ul><li>Level of detail </li></ul></ul><ul><ul><li>Paths </li></ul></ul><ul><ul><li>Purpose of specification </li></ul></ul><ul><li>Elaboration (unfolding) </li></ul><ul><li>Graphical representation </li></ul><ul><li>Use case specification </li></ul><ul><ul><li>Use case template & guidelines for each element </li></ul></ul>
    41. 41. Components of a Use Case <ul><li>A use case template may contain the following elements. </li></ul><ul><ul><li>Title </li></ul></ul><ul><ul><li>Actor(s) </li></ul></ul><ul><ul><li>Description </li></ul></ul><ul><ul><li>Trigger </li></ul></ul><ul><ul><li>Pre-conditions </li></ul></ul><ul><ul><li>Post-conditions </li></ul></ul><ul><ul><li>Basic Path </li></ul></ul><ul><ul><li>Alternate conditions & paths* </li></ul></ul><ul><ul><li>Exception conditions & paths* </li></ul></ul><ul><li>*If applicable </li></ul>Customize the template to meet the needs of the project
    42. 42. Title <ul><li>Title </li></ul><ul><li>Should state the goal of the use case </li></ul><ul><ul><li>End result that is of business value to the primary actor </li></ul></ul><ul><li>Use “verb noun” phrasing </li></ul><ul><ul><li>E.G. “Place order” </li></ul></ul><ul><ul><li>The primary actor is the implied subject “ Customer Place s order” </li></ul></ul><ul><li>Use the vocabulary of the business </li></ul><ul><ul><li>Rather than the technical terms or jargon </li></ul></ul><ul><li>Use strong verbs </li></ul><ul><ul><li>Rather than mushy verbs like “maintain” </li></ul></ul>
    43. 43. Title (continued) <ul><li>Title </li></ul><ul><li>Try the “reverse it” test </li></ul><ul><ul><li>Flip the verb noun phrase </li></ul></ul><ul><ul><ul><li>“ noun verb’ed” </li></ul></ul></ul><ul><ul><ul><li>It should state the result of value </li></ul></ul></ul><ul><ul><li>An example that passes the test </li></ul></ul><ul><ul><ul><li>Place order >reversed> Order has been placed </li></ul></ul></ul><ul><ul><li>An example that fails the test </li></ul></ul><ul><ul><ul><li>Maintain employee list >reversed> Employee list is maintained </li></ul></ul></ul><ul><ul><ul><ul><li>This is an ambiguous goal & indicates that the use case should be renamed to be more specific </li></ul></ul></ul></ul>
    44. 44. Actors <ul><li>Actors </li></ul><ul><li>The Primary Actor is the person (role) or external system initiating the use case </li></ul><ul><ul><li>The primary actor is the implied subject “ Customer Place s order” </li></ul></ul><ul><li>There can be multiple actors in a use case. </li></ul><ul><li>Supporting actors are external actors (including systems) that participate or provide input in the use case but do not initiate it. </li></ul>
    45. 45. Description <ul><li>Description </li></ul><ul><li>A brief summary </li></ul><ul><li>Elaborates on the title </li></ul><ul><li>Clarifies the essence of the use case </li></ul><ul><li>Focus is on what is to be accomplished in the use case, not the method or reasoning behind it </li></ul>
    46. 46. Description (continued) <ul><li>Description </li></ul><ul><li>The description may </li></ul><ul><ul><li>Start as a narrative (level 1) </li></ul></ul><ul><ul><li>End as a short, concise summary of a task (level 3 and higher) </li></ul></ul><ul><li>As a use case unfolds, information in the description may end up in other elements of the specification </li></ul><ul><li>When initially written, the description </li></ul><ul><ul><li>Will further describe business value provided </li></ul></ul><ul><ul><ul><li>Amply on end result </li></ul></ul></ul><ul><ul><li>May include mention of the inputs provided </li></ul></ul><ul><ul><li>May mention the “start” and “end” states </li></ul></ul><ul><ul><ul><li>In terms of preceding & following use cases </li></ul></ul></ul><ul><ul><ul><li>And/or in terms of business objects produced or modified </li></ul></ul></ul><ul><ul><li>May mention of actors other than the primary actor </li></ul></ul>
    47. 47. Initiation of a use case <ul><li>How the trigger event and pre-conditions work together … </li></ul><ul><li>When the trigger event occurs … </li></ul><ul><li>The pre-conditions are “checked” before the 1 st step of the UC is taken </li></ul><ul><ul><li>Pre-conditions are also referred to as “guard” conditions </li></ul></ul><ul><li>In words </li></ul><ul><li>When the _<event>_ occurs AND all of the pre-conditions have been found to be true THEN proceed with the use case </li></ul>
    48. 48. Trigger <ul><li>Trigger </li></ul><ul><li>An event that initiates an occurrence of the use case </li></ul><ul><ul><li>Source of event </li></ul></ul><ul><ul><ul><li>Person </li></ul></ul></ul><ul><ul><ul><li>Clock or calendar </li></ul></ul></ul><ul><ul><ul><li>Another system </li></ul></ul></ul><ul><ul><li>Triggers may be the first step in the use case, but are not always </li></ul></ul><ul><ul><li>Example: </li></ul></ul><ul><ul><ul><li>Use Case Title: ATM customer withdraws cash </li></ul></ul></ul><ul><ul><ul><li>Trigger: Card inserted into ATM </li></ul></ul></ul>
    49. 49. Pre-conditions <ul><li>Pre-conditions </li></ul><ul><li>Assertions stating what conditions must be true in order for an occurrence of the use case to begin </li></ul><ul><li>A pre-condition may be stated in terms of the “state” of </li></ul><ul><ul><li>Business object (or, related information) </li></ul></ul><ul><ul><ul><li>“ ___ must exist” </li></ul></ul></ul><ul><ul><ul><li>“ ___ must exist and be in state ___” </li></ul></ul></ul><ul><ul><li>Business process </li></ul></ul><ul><ul><ul><li>“ Action XYZ must have … “ </li></ul></ul></ul><ul><ul><ul><ul><li>Successfully completed </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Failed </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Produced result x </li></ul></ul></ul></ul><ul><ul><li>The system </li></ul></ul><ul><ul><ul><li>“ The ___ workspace is open” </li></ul></ul></ul><ul><ul><ul><li>“ A new ___ has been opened” </li></ul></ul></ul>
    50. 50. Initiation –Special case <ul><li>There may not be a single triggering event </li></ul><ul><li>The special case in general terms: </li></ul><ul><li>Two or more prerequisites must become true AND </li></ul><ul><li>Order is not important </li></ul><ul><li>Trigger </li></ul><ul><li>The final prerequisite to become true triggers the occurrence of the use case </li></ul><ul><ul><li>If all the other prerequisite conditions are still true </li></ul></ul><ul><li>In words </li></ul><ul><li>When all of the pre-conditions have been found to be true THEN proceed with the use case </li></ul>
    51. 51. Post-conditions <ul><li>Post-condition </li></ul><ul><li>An assertion stating what conditions are true upon the successful completion of the use case </li></ul><ul><li>A post-condition may be stated in terms of the “state” of </li></ul><ul><ul><li>Business object (or, related information) </li></ul></ul><ul><ul><ul><li>The results produced by the use case just completed </li></ul></ul></ul><ul><ul><ul><ul><li>“ ___ created” </li></ul></ul></ul></ul><ul><ul><ul><ul><li>“ ___ created and in ___ state” </li></ul></ul></ul></ul><ul><ul><ul><ul><li>“ ___ updated to reflect ___” </li></ul></ul></ul></ul><ul><ul><ul><ul><li>“ ___ updated to be in state ___” </li></ul></ul></ul></ul><ul><ul><ul><ul><li>“ ___ deleted” </li></ul></ul></ul></ul><ul><ul><li>Business process </li></ul></ul><ul><ul><ul><li>The state of the containing process relating to what can happen next </li></ul></ul></ul><ul><ul><ul><ul><li>“ Action QRS … “ </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Can now be initiated </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Must be initiated </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>“ This use case may now be initiated for the next ___” </li></ul></ul></ul></ul><ul><ul><li>The system </li></ul></ul><ul><ul><ul><li>The result is apparent to the user </li></ul></ul></ul><ul><ul><ul><ul><li>“ The revised ___ is displayed” </li></ul></ul></ul></ul>
    52. 52. Basic Path <ul><li>Basic path </li></ul><ul><li>Typical, most frequent, shortest, simplest … </li></ul><ul><li>Enumerates actions performed to accomplish goal </li></ul><ul><ul><li>Actions performed by </li></ul></ul><ul><ul><ul><li>A participating actor </li></ul></ul></ul><ul><ul><ul><li>The system </li></ul></ul></ul><ul><li>Coburn defines three types of actions: </li></ul><ul><ul><li>An interaction or information flow </li></ul></ul><ul><ul><ul><li>“ Member submits claim” </li></ul></ul></ul><ul><ul><li>A validation step </li></ul></ul><ul><ul><ul><li>System confirms eligibility </li></ul></ul></ul><ul><ul><li>An internal change </li></ul></ul><ul><ul><ul><li>“ System suspends claim” </li></ul></ul></ul>Action 1 Action 2 Action 3 Action 4
    53. 53. Alternative Path <ul><li>Alternative path </li></ul><ul><li>Describes an extension to the basic path </li></ul><ul><ul><li>Starts with a condition </li></ul></ul><ul><ul><li>Departs after a specific step </li></ul></ul><ul><ul><li>Enumerates actions performed as a result of the condition </li></ul></ul><ul><li>May rejoin the basic path </li></ul><ul><li>Accomplishes goal </li></ul>Action 1 Action 2 Action 3 Action 4 1a1 1a2 1a Condition … Rejoin
    54. 54. Exception Path <ul><li>Exception path </li></ul><ul><li>Describes an extension to the basic path </li></ul><ul><ul><li>Starts with a condition </li></ul></ul><ul><ul><li>Departs after a specific step </li></ul></ul><ul><ul><li>Enumerates actions performed as a result of the condition </li></ul></ul><ul><li>Does not rejoin the basic path </li></ul><ul><li>Does not accomplished the goal </li></ul>3a Condition Action 1 Action 2 Action 3 Action 4 Condition Rejoin 3a1

    ×