1. Lab3 Use Case Modeling Lessons Learned COP 4232: Software Systems Development © Dr. David A. Workman School of EE and Computer Science University of Central Florida November 14, 2005

2. September 28, 2005(c) Dr. David A. Workman2 Document Purpose and Scope The document IS the Use Case Model and cannot be defined in terms of itself. This section must: –Describe the information contained in the document. –Describe the purpose and use of the document. –Identify who the reading audience is; that is, for whom is the document written? "This document is an operational model of Jiffy Stop Convenience Store intended to serve as the basis for developing a realistic simulation of Jiffy Stop's day to day business activities. It describes the services (use cases) offered to its customers and suppliers. It models the physical layout of Jiffy Stop premises and the interaction scenarios experienced by its users. Jiffy Stop Management and the simulation developer are the intended readers. JS Management should validate the model for its accuracy and completeness. The software developer should use this document as a source of requirements for simulation development."

3. September 28, 2005(c) Dr. David A. Workman3 Business Case Motivate the need for the Use Case Modeling effort. Why are we doing this? What situation led to this effort? (Customer complaints – loss of business to competitors) Justify the simulation approach. What are the advantages of a business simulation? (Low cost analysis tool. A variety of Jiffy Stop changes can be modeled and simulated at almost no additional cost to determine their effect. This is much more time and cost effective than making real changes to the system to see if the situation improves) State the specific questions Management hopes to answer from the simulated model.

4. September 28, 2005(c) Dr. David A. Workman4 Concept of Operation Includes a Use Case Diagram as the central focus. (Many UCDs were incomplete – missing use cases. Some UCDs were in error because the Clerk/Cashier was depicted as an actor – it is part of the Jiffy Stop system. Some UCDs used relationships incorrectly, or did not identify use cases by verb phrases.) The supporting narrative should refer to the UCD and the use cases by name. A story should be told describing exactly how actors and use cases interact in a logical and sequential fashion. The narrative should read like a script each actor must follow to accomplish a use case. (Many scenarios were confusing and incomplete, leaving the reader with many unanswered questions.)

5. September 28, 2005(c) Dr. David A. Workman5 System Layout & Interfaces Give figures illustrating interface features. Support figures with narrative that identifies the use cases and actors that require these features. The narrative could walk the reader through each of these use case scenarios indicating what features actors use for input and what features the system uses for output. (Many of you had wonderful diagrams, but no supporting narrative. Interaction steps described by text boxes on the diagram are OK, but are not as effective as a well-written narrative referring to diagram features. The narrative should identify the actors and the use case names.)

6. September 28, 2005(c) Dr. David A. Workman6 Use Case Specification System State Diagram or System Activity Diagram (Most of you had diagrams, but most were neither pure State diagrams nor pure Activity diagrams.)(Activity diagrams are probably the best choice for a Use Case Model – they show explicitly the flow of use case execution by actors – they can express conditional flow paths more clearly and explicitly than State diagrams can.) Pre- and Post- conditions. Should refer to points on the Activity flow or states on the Transition diagram. Interaction (and Alternative) Flows should be a sequence of actions performed by an actor or the system in response. These should be numbered and listed in their logical sequence. Repetition of steps should be stated. Problem data that enters or leaves the system interface objects should be explicitly stated. (Many did not explicitly list the interactions as a sequence of actions at the proper level of detail.) Communication Diagrams should depict graphically the interaction sequence as messages flowing between actor and system interface objects. (Most Communication Diagrams did not identify the interface objects in sufficient detail, or the flows were not numbered, or the direction of the flow as reversed.)

7. September 28, 2005(c) Dr. David A. Workman7 Requirements Traceability List valid references or sources of requirements: 1.Lecture notes 2.Lab Specification 3.Project Specificaton 4.Personal interview with Dr. Workman 5.On-site study of XXXX Convenience Store –The list of requirements should be sufficient to cover all use cases and non-functional aspects of the JS operation relevant to simulation. (Most everyone was deficient in this section – I was more generous than I should have been.)

8. September 28, 2005(c) Dr. David A. Workman8 Glossary This section describes (summarizes) all technical and problem related terminology. Should have had around 24 entries.