1. INFO 355Week #21 Systems Analysis II Use Cases INFO 355 Glenn Booker

2. Use Cases  As part of the activity to define functional requirements, we can capture those requirements in “use cases”  “A use case is an activity the system performs, usually in response to a request by the user” (text, 69) INFO 355Week #22

3. INFO 355Week #23 Use Cases and OO  Though use cases are often associated with object oriented analysis, use cases are not object oriented  They could be used to help capture functional requirements for any type of system

4. Finding use cases  Two methods (at least) for finding use cases for a system User goal technique Event decomposition technique  To validate a draft list of use cases, the CRUD technique can be used INFO 355Week #24

5. User goal technique  The main idea behind this technique is to identify the types of users of a system, then determine what goals or assigned tasks each type of user has when using the system  Those goals often correspond to use cases INFO 355Week #25

6. User goal technique  The user goal technique is: Identify all potential users for a system (Optional) Classify users by functional role (shipping, marketing, sales) and operational level (operational, management, executive) Interview each user and determine what goals they have when using the system INFO 355Week #26

7. User goal technique Make a preliminary list of use cases for each type of user Look for duplicates and inconsistencies across users Identify when multiple users need the same use case Review completed list with users and other stakeholders for validation INFO 355Week #27

8. Event Decomposition  This approach looks for all events that would lead to the information system being used Each event typically leads to a use case Simplify events to ones that have a clearly defined start and end, and achieve a clear business purpose Those are Elementary Business Processes (EBPs) = use cases INFO 355Week #28

9. Event Decomposition  Focusing on events keeps attention on the macro scale purpose of the system, not internal details  Events can be External – caused by an actor Temporal – done at fixed time intervals State – triggered by an internal condition, e.g. low inventory INFO 355Week #29

10. Event Decomposition  Focus on events that directly cause the system to be used Not prior conditions that are invisible to the system Many important business processes do not involve the system directly!  Avoid trivial use cases (logging on) but DO include system controls (admin functions such as backup) INFO 355Week #210 The last point differs from the text!

11. Event Decomposition  The event decomposition process is Identify relevant external events  For each, name a use case Identify relevant temporal events  For each, name a use case and define when it occurs Identify relevant state events  For each, name a use case Omit trivial use cases, but keep system controls INFO 355Week #211

12. CRUD technique  Use this technique for verifying an existing list of use cases  Recall CRUD – create, read, update, or delete data  The goal of this technique is to verify at least one use case has been identified to perform all relevant aspects of CRUD Relevant aspects? INFO 355Week #212

13. CRUD technique steps  Identify major data entities for your system  For each, verify that at least one use case does each of CRUD, as appropriate to your system  Add use cases if needed  Make sure data ownership is clear if more than one application interacts INFO 355Week #213

14. Naming use cases  Give use cases a short name (2-4 words), starting with an action verb Track shipment Create new user Produce monthly sales report  The reason for brevity is so we can put them on a use case diagram INFO 355Week #214

15. INFO 355Week #215 Use Case Diagram  A use case diagram summarizes all the major use cases for a system  To define a use case diagram, need: List of Use Cases Actors External Systems (if any) System Boundary (automation boundary)

16. INFO 355Week #216 Actors  Actors are types of users of the system – the role of someone who uses the system  Actors must interact directly with the system Interaction could be through any mechanism – keyboard, mouse, touch screen, card reader, voice, biometric,…

17. INFO 355Week #217 Actors  Examples of actors include Customer/Client/Patient/Patron/Donor/ Subscriber (if they interact directly) Manager (should be more specific) System Administrator Clerk Foreman

18. INFO 355Week #218 External Systems  External systems are any non- human (generally computerized) actor which your system needs to perform one or more use cases Can be a Timer, to initiate automatically repeating use cases Are systems you don’t control, and are outside the scope of your system development

19. INFO 355Week #219 External Systems  Could include systems owned by vendors E.g. a service to maintain your online catalog  Could be a custom legacy system which isn’t being replaced E.g. an existing human resource system, or accounting system

20. INFO 355Week #220 System Boundary  The use case diagram includes a box to show the boundaries of your system Actors are not within the boundary External systems are not within the boundary Box is labeled with your system’s name (not just “System”)  The use case diagram acts like a context diagram

21. INFO 355Week #221 Naming Use Cases  Each use case should have a brief name, typically 2-4 words  Start with a verb, and end with a noun Cancel Customer Order Place Order Validate New Customer  Number use cases sequentially 

22. INFO 355Week #222 Use Case Diagram Notation  Actors are represented by stick people, with their role below them  Use cases are represented by ovals  External systems are represented by rectangles, with “ >” before the system name “ >” is a stereotype The “ >” should be guillemets

23. INFO 355Week #223 Sample Use Case Diagram Tip: Straight lines are easier to use!

24. INFO 355Week #224 Use Case Diagram Notation  Lines connect actors to the use cases they can perform Hence a major purpose of the use case diagram is to show what functions the system can perform, and who can use them  Notice there is no indication of when use cases are performed, or any of the logic behind them

25. INFO 355Week #225 Generalization  A common concept for the use case diagram is when one actor has some special use cases, but also can do everything some other actors can A manager or supervisor can do everything their staff can do, plus additional functions Show this using generalization

26. INFO 355Week #226  Notice the triangle at the top of the line between Manager and Staff This means that Manager inherits all use cases which Staff can do  (Also can use generalization in Class diagrams)  Helps keep use case diagram simpler and easier to read Generalization

27. INFO 355Week #227 “Included” Use Cases  When documenting use cases, might find a clear set of activities that appears in two or more use cases  Can pull those activities out and make that an included use case In Visio, lines to an included use case have the stereotype “ >” In other applications, stereotype is “ >”

28. INFO 355Week #228  The included use case is documented separately from the use cases which use it “Included” Use Cases Use case numbering and system boundary omitted

29. Subsystem use case diagram  Ideally all actors and use cases should fit on one diagram  If not, it’s ok to have a separate use case diagram for each major subsystem Specify whether the diagram includes all users (preferred) or a limited subset of them INFO 355Week #229

30. INFO 355Week #230 Documenting Use Cases  Use cases can be documented to varying levels of detail varying levels of detail  We’ll define two of them Casual use case documentation Detailed use case documentation  These are local terms for the level of documentation, not Cockburn’s (that’s pronounced CO-burn)  The text uses ‘Brief’ and ‘Fully developed’

31. INFO 355Week #231 Casual Use Case Documentation  Consists of: Use case number and name Objective – A sentence to elaborate on the main purpose of the use case Primary Actor – what actor initiates the use case Main Success Scenario – a step-by-step description of the events which should occur during this use case

32. INFO 355Week #232 Detailed Use Case Documentation  Consists of: Use case number and name Objective Primary Actor Secondary Actor(s) – other actors who play a significant role in this use case Trigger – what event forces the start of this use case? Main Success Scenario (MSS)

33. INFO 355Week #233 Detailed Use Case Documentation Extensions – when performing the MSS, what other events could occur?  Extensions often include alternate methods of processing, different ways to do the same thing, and error conditions Performance time – how long it should typically take to perform this use case Frequency – how often will this use case be performed? Open Issues – for scope issues, if any

34. INFO 355Week #234 Beyond Detailed  The MSS and/or extensions should cite included use cases, where appropriate  Additional documentation is possible beyond the detailed template just given – see Cockburn’s site

35. INFO 355Week #235 Main Success Scenario  The Main Success Scenario describes the interaction between actors and the system in order to perform a use case They are critical to write well, since later documentation depends upon them (e.g. sequence diagrams)  See Summary of UML Diagrams handout for details on MSS writing

36. INFO 355Week #236 Main Success Scenario  Where to begin? For most use cases, you can assume the actor has logged into the system (if needed) and are starting at the application’s Main Menu or its equivalent  A MSS describes a use case in more detail than you would typically consider necessary

37. INFO 355Week #237 Main Success Scenario The MSS describes the most common way a use case will be performed successfully  If there are multiple processing options, pick the most frequent one for the MSS, and describe the rest in the Extensions  In the MSS, assume all actions will be successful; describe how to handle unsuccessful outcomes in the Extensions The MSS is the Disney version of the use case  Extensions are the Tim Burton version

38. INFO 355Week #238 Main Success Scenario  Typical actor activities in a MSS are: Navigate through the interface to a defined objective  “Shipping clerk navigates to the New Shipment Screen.”  Notice we didn’t say HOW they navigate, just that it’s accomplished somehow Enter data onto an interface  “Shipping clerk enters the data for a new shipment.”  Notice every field entered is not specified

39. INFO 355Week #239 Main Success Scenario Describe when an actor selects something on an interface  “Dispatch manager selects the number of drivers needed.” Indicate when an actor completes an activity, such as by submitting data  “Shipping clerk submits the new shipment data.”  This prompts the system to do something with the data

40. INFO 355Week #240 Main Success Scenario The only remaining type of actor action is to exit the application, which often isn’t part of a MSS (assume you can always cancel or exit from the system)  So there are few types of things an actor might do during a MSS  System actions can be much more complex

41. INFO 355Week #241 Main Success Scenario  Typical system actions include: Create a new interface screen  “System displays Define Shipment screen.” Change or update the contents of an existing screen  “System updates the screen to show the list of artifacts.”

42. INFO 355Week #242 Main Success Scenario Communicate with an external system  “System gets current stock price from NYSE.”  “System emails drivers with shipment info.” Perform an included use case  “System performs Validate Credit Card use case.” Perform background processing  “System validates new customer data.”  “System computes the sales tax.”

43. INFO 355Week #243 Main Success Scenario  Notice that the MSS includes steps which aren’t visible to the actors! Other background processing might include  “System prioritizes the list of drivers.”  “System produces weekly sales summary.” Background processing can include any activity needed to prepare data for presenting the results to the actor

44. INFO 355Week #244 Main Success Scenario Finally, make sure a MSS achieves the overall objective of the use case!  “System saves new customer data.”  “System updates order status.”  “System deletes completed orders.” These steps are typically performing one of the CRUD functions

45. INFO 355Week #245 Main Success Scenario  Writing a MSS might involve making assumptions about where or how data is stored Can assume there is a place that stores Customer Data, or Shipment Data, etc.  External systems should be labeled consistently throughout the design  Can name interfaces (New Customer Screen), but don’t design them (‘click on the submit button’ = no!)

46. INFO 355Week #246 Main Success Scenario  Throughout a MSS, look for actions which need to be repeated  Specify in generic terms how many times steps need to be repeated For each book to be checked out, … For each driver assigned to a shipment, Repeat five times, or until login is successful

47. INFO 355Week #247 Extensions  Extensions, or alternate scenarios, handle when something doesn’t go normally during a use case Extensions are numbered, starting with the MSS step from which they depart  If an extension starts from step 5, the first extension is a condition called 5.a  Then the steps to respond to that condition are 5.a.1, 5.a.2, etc.  A second extension from step 5 is condition 5.b and has steps 5.b.1, 5.b.2, 5.b.3, etc.

48. INFO 355Week #248 Extensions Handle So the lettered step (5.a) describes the condition under which you perform that extension  And the steps under it (5.a.1, 5.a.2, …) are the actor and system actions that follow Optional processing steps can be an extension; the rest of the MSS isn’t affected if they aren’t used  Adding sales tax to an order  Adding gift wrapping to an order

49. INFO 355Week #249 Extensions Handle Failure conditions – when a MSS step can’t be performed successfully  If a search yields no results  If payment is insufficient  Can’t connect to an external system Alternate processing – when a MSS step can be processed differently  Handle domestic versus international orders  Handle different forms of payment

50. Extensions  Assume that interfaces and data transactions inside your system are successful, and won’t result in an extension, e.g. Saving or reading data locally Creating or updating interfaces  Otherwise every system step could be an extension! INFO 355Week #250