Object CSCI 4448
Popular in Course
Popular in ComputerScienence
This 22 page Study Guide was uploaded by Allie West II on Thursday October 29, 2015. The Study Guide belongs to CSCI 4448 at University of Colorado at Boulder taught by Staff in Fall. Since its upload, it has received 27 views. For similar materials see /class/231995/csci-4448-university-of-colorado-at-boulder in ComputerScienence at University of Colorado at Boulder.
Reviews for Object
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 10/29/15
Give Them What They Want Kenneth M Anderson University of Colorado Boulder CSCI 44486448 Lecture 6 09132007 Saturday September 15 2007 Lecture Goals 0 Review material from Chapter 2 of the OO AampD textbook 0 Give Them What They Want 0 Requirements and Use Cases 0 Discuss the Chapter 2 Example Todd amp Gina s Dog Door 0 Emphasize the OO concepts and techniques encountered in Chapter 2 Saturday September 15 2007 2 Requirements and Use Cases 0 Chapter 2 does an excellent job of introducing you to the concepts of requirements and use cases 0 What s a requirement 0 It s a specific thing your system has to do to work correctly 0 Who defines correct behavior 0 The customer 0 What s a use case 0 A use case describes what your system does to accomplish a particular customer goal 0 What s the relationship between them 0 Each requirement can be translated into one or more customer goals Saturday September 15 2007 3 The Scenario 0 Doug has a company that creates custom dog doors you work for Doug 0 Todd and Gina are your first customers 0 They want a remotecontrolled dog door for their dog Fido 0 In realistic fashion the book quickly codes up a solution 0 It is ALWAYS tempting to go straight to coding humans love solving problems and humans love to create 0 for developers what we create is code 0 In realistic fashion the first attempt fails 0 Gina uses the dog door and discovers a rabbit in her kitchen Saturday September 15 2007 Page 61 Classic Developer Reaction It s the User s Fault Classic Developer Reaction 0 There s nothing wrong with our code Gina must have forgotten to press the button on the remote again after Fido came back in It s not my fault she s using the door incorrectly 0 Wrong 0 The user is our customer 0 The system is not correct until it satisfies their needs 0 Humbling Experience 0 Watch a system you ve developed being tested for usability Saturday September 15 2007 6 Take Two 0 Given that the code first ask questions later strategy has failed we now adopt an alternative process 0 Gather requirements for the dog door by talking to Todd and Gina 0 Figure out what the door should really do 0 Get any additional information ie iterate 0 Build the door RIGHT 0 This is the start of an analysis process that will help us with step 1 of our 00 AampD process from last lecture 0 make sure your software does what the customer wants it to do Saturday September 15 2007 7 What s a Requirement Revisited 0 Def It s a specific thing your system has to do to work correctly 0 A requirement is usually a single testable thing your system has to do 0 The focus is on the entire system 0 A system will typically have more than one requirement 0 It s the customer who decides what correct behavior is not the developer 0 The key problem encountered with the original system was that Todd and Gina expected the dog door to close automatically 0 Gina opened the door to let Fido out then never closed it and the bunny took advantage Evil Bunny Saturday September 15 2007 8 Initial Requirements Requirements List 1 The dog door opening must be at least 12quot tall 2 A button on the remote control toggles the state of the door it opens the door it closed and closes the door it open 3 Once the dog door has opened it should close automatically after a short delay take that Rabbit Page 65 Classic Developer Reaction Take Two 0 Is this list really going to help Todd and Gina completely forgot to tell us they wanted the door to automatically close before won t they just forget something again 0 Yes but 0 We have to start somewhere and we need to understand what the customer wants 0 Remember that analysis is an iterative process you will cycle on 0 gather and interpret use case creation 0 implement 0 evaluate 0 many many times 0 Also remember that customers will sometimes choose to not reveal everything at once because they don t think you re ready Saturday September 15 2007 10 Use Case Creation 0 After you have requirements you start to think about what the system really needs to do 0 this includes thinking about issues that your customer didn t raise 0 such as anticipating how things can go wrong 0 The book does this by creating a scenario of use for Todd and Gina s door 0 Pages 68 and 69 does an excellent job of this 0 These pages graphically illustrate the scenario and annotate each step with questions of what might go wrong Saturday September 15 2007 11 Scenario of Use What the Door Does t Fido barks to be let out Does Fido always bark 2 Todd or Gina hear Fido What if they don t 3 Todd or Gina presses the button on the remote control 4 The dOOr OIOGHS What if Fido was barking for 5 Fido 068 out some other reason 6 Fido takes care of business 7 Fido goes back inside and so onquot 8 The door shuts automatically Alternative Paths 0 For step 6 Fido takes care of business the book asks the question 0 What if the door shuts while Fido is outside 0 For this they develop an alternate path that shows how the scenario can proceed and still succeed 0 61 The door shuts automatically 0 62 Fido barks to be let inside 0 etc Saturday September 15 2007 13 What s a Use Case Revisited 0 Def A use case describes what your system does to accomplish a particular customer goal 0 Use cases area all about what not how 0 A single use case focuses on a single goal 0 The use case is written from the perspective of the user who is outside of the system 0 We do not write from the perspective of the system 0 This helps developers keep our customer focus 0 The use case ends when the goal has been achieved 0 An alternate path describes a situation where an error occurs but then offers insight into what occurs next to get back on the path to success 0 Sometimes success cannot be achieved if so the use case ends Saturday September 15 2007 14 One Use Case Three Parts 0 Clear Value Every Use case must provide clear value to the system 0 If a use case doesn t help a customer achieve a goal delete it 0 Start and Stop Every use case must have a definite starting and stopping point This helps developers understand the scope of a use case 0 External Initiator Every use case is started by an external initiator also known as the primary actor Typically the primary actor is human but it could also be an external software system that is contacting our system for some reason Saturday September 15 2007 15 What s the Point 0 Use cases appear to contain information that is a LONG way from code 0 If a use case was too technical you wouldn t be able to share them with your users if you keep them at a high level the user can read them and provide feedback 0 Use cases help you see the system from an external perspective 0 Sometimes what the developer focuses on or thinks is really cool about a system is completely invisible to the user 0 The developer needs to think about how the system is going to be used and then base decisions concerning specific features on that understanding 0 As we will see use cases are the starting point of a design process that can transform use case scenarios into information that is closer to code Saturday September 15 2007 16 Validation 0 Requirements and use cases go hand in hand in helping you to validate the information that you gather during the analysis phase of a software project 0 For each use case you should be able to map steps in the use case to requirements in your requirements document 0 That is the scenarios that you need to support spring from the requirements 0 From the reverse perspective use cases can help you check that you have covered all of your requirements 0 If you map each step in all of your use cases back to your requirements list you can discover requirements that are not being addressed or that have only been weakly or partially addressed 0 You can then iterate and add new use cases to cover the gaps Saturday September 15 2007 Example Requirements List 1 The dog door opening must be at least 12 tall 2 A button on the remote control toggles the state of the door it opens the door it closed and closes the door it open 3 Once the dog door has opened it should close automatically after a 4 short delay take that Rabbit 1 2 3 4 5 6 7 8 What the Door Does Fido barks to be let out Todd or Gina hear Fido Todd or Gina presses the button on the remote control The door opens Fido goes out Fido takes care of business Fido goes back inside The door shuts automatically Note some steps in the scenario do not map back to the requirements There are a lot of things that happen outside the system that don t require a response Saturday September 15 2007 Back to Code 0 With the use case created and the alternate path defined we can now move back to our prototype and add functionality 0 Demonstration 0 Note since we have two paths through our use case we need to make sure that we test both paths 0 As the book says Your system must work in the real world so plan and test for when things go wrong 0 Its sometimes difficult for developers to deliberately test error conditions in their systems 0 developers have the tendency to be optimistic see Chapter 1 of Fred Brooks The Mythical ManMonth and so tend to test just the main paths of their use cases not the alternate paths aka extensions Saturday September 15 2007 19 Requirements from Use Cases 0 The chapter ends with a very useful exercise 0 They provide details on three new user scenarios 0 Kristen wants to be able to lock the dog door via a keypad 0 Holly wants the dog door to open when her dog scratches the door 0 John wants the door to close immediately after his dog goes out 0 He wants to make sure the dog is not muddy before he lets the dog backin 0 They then develop the use cases first and THEN update the requirements 0 They also cover additional use case formats see Appendix I for more details Saturday September 15 2007 20 Tools for your 00 AampD Toolbox 0 Requirements 0 Good requirements ensure your system works like your customers expect 0 Make sure your use cases cover all of the requirements for your system 0 Use your use cases to discover things your customers forgot to tell you 0 Use cases will sometimes reveal incomplete or missing requirements 0 Fix the problem and then iterate to make sure your use cases cover the new requirements Saturday September 15 2007 21 Coming Up Next 0 Lecture 7 Dealing with Change 0 Read Chapter 3 of the OO AampD book 0 Lecture 8 Ready for the Real World 0 Read Chapter 4 of the OO AampD book Saturday September 15 2007 22
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'