Requirements Change! Chapter 3 Object-Oriented Analysis and Design Tom Perkins

Welcome! 10 (+) week book study Tom Perkins Books available at Nerdbooks.com /STUDYGROUPSIG/ OOADhttp:// /STUDYGROUPSIG/ OOAD

Chapter 3 Topics Review –Good software –Use Cases The One Constant in Software Design Todd and Gina’s Idea The Bark Recognizer Scenario A Revised Use Case Introducing the Bark Recognizer Object Updating the Dog Door Simulator Doug’s Idea Duplicate Code for the Timer? Class and Code Walkthrus

Review (Chapter 1) 3 Steps to Good Software 1.Make sure the software does what the customer wants it to do 2.Apply basic OO principles to add flexibility 3.Strive for a maintainable, reusable design

Review – Chapter 2 What is a Use Case? A Use Case describes what your system does to accomplish a singular goal. Focuses on “what”, not “how” Single goal: different goal, different use case Main path; alternative paths (can occur only some of the time) Users outside the system: Gina, Todd, Fido Dog door and remote inside the system Formal Use Case: A technique for capturing the potential requirements of a new system or a software change. It provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific goal. Scenario: a path through the use case that will result in the goal.

Your new programming job: Doug’s Dog Doors (High tech, automated dog doors) Todd Gina Fido Your first Customers What they want: An automated, remote- controlled Dog Door barks !!! want to push button to open door No Problem !!!

Todd and Gina’s Dog Door, Version 2.0 (Review) Dog Door Use Case 1. Fido barks to be let out. 2. Todd or Gina hears Fido barking. 3. Todd or Gina presses the button on the remote control. 4. The dog door opens. 5. Fido goes outside. 6. Fido does his business The door shuts automatically. 6.2 Fido barks to be let in. 6.3 Todd or Gina hears Fido barking (again). 6.4 Todd or Gina presses button on remote control. 6.5 The dog door opens (again). 7. Fido goes back inside. 8. The door shuts automatically.

The One Constant in Software Design

Doug and Gina’s Idea It (the dog door) is working great, but what if … Fido barks (Woof-Woof )!!! Bark Recognizer Attachment Dog Door Opens!

Fido barks Recognizer hears Recognizer Opens door Fido out, does business Fido back in Door closes All is well Door shuts Fido barks Recognizer hears Recognizer opens door Main pathAlternate path Note: Todd and Gina are not in this picture

A Revised Use Case Main Path 1. Fido barks to be let out 2. Bark Recognizer hears 3. Bark Recognizer send open request 4. Dog door opens 5. Fido goes outside 6. Fido does his business. 7. Fido goes back inside. 8. Dog door shuts automatically Alternate paths: 2.1 Todd or Gina hears Fido 3.1 Todd or Gina presses remote control 6.1 Dog door shuts automatically 6.2 Fido barks 6.3 Bark recognizer hears bark Todd or Gina hears 6.4. Bark recognizer requests Todd or Gina presses remote 6.5 Dog door opens

Old Dog Door Object Walkthrus DogDoor Remote Simulator object Walkthru

Dog Door with Bark Recognizer Object Walkthrus Recognizer object Code Walkthru But the door stays open!!!

Doug’s Idea! Put a timer on it! Just copy the one in the remote! Question: Duplicate the timer code in the Remote? Better solution: Put a single timer in the DogDoor class; remove the remote timer. DRY Principle (Don’t Repeat Yourself)

The Modified DogDoor Class Modify code Run Simulator

In-class exercise Suppose it’s January in North Texas, and your car is parked overnight in your garage. Write a use case that would describe the process you go through in starting your car and backing it onto the street. Did you include any alternate paths? Does your car-starting experience always follow the “Happy Path”?