Overview chapter 3 Head First Object Oriented Design and Analysis

#OOAD
#chapter3
#Overview
#Head First Object Oriented Design and Analysis

Transcript

1. 1 / 20 Chapter 3: Requirements change Tien Dinh
2. 2 / 20 Think you’ve got just what the customer wanted? Not so fast... ` `- So you’ve talked to your customer, gathered requirements, written out your use cases, and delivered a killer application. - It’s time for a nice relaxing cocktail, right? - Right... until your customer decides that they really wanted something different than what they told you. - They love what you’ve done, really, but it’s not quite good enough anymore. => In the real world, requirements are always changing, and it’s up to you to roll with these changes and keep your customer satisfied.
3. 3 / 20 You are hero • Doug‘s making some serious bucks with your code • Over 10000 sold
4. 4 / 20 But then came a phone call After a period of use, Todd and Gina encounter some new problems • They are too tired to listen to Fido's barking all day long. Sometimes they do not hear so k opened the dog to crank in the house. • They lose control, or forget to control in another room and then too lazy to get to the room. • Too tired to press the button all the time. => They want the door to automatically open when their dog barks.
5. 5 / 20 The customer is always right Even when requirements change, you’ve got to be ready to update your application and make sure it works like your customers expect. When your customer has a new need, it’s up to you to change your applications to meet those new needs.
6. 6 / 20 The one constant in soft ware analysis and design • No matter where you work, what you’re building, or what language you are programming in, what’s the one true constant that will always be with you? • No matter how well you design an application, over time the application will always grow and change. You’ll discover new solutions to problems, programming languages will evolve, or your friendly customers will come up with crazy new requirements that force you to “fix” working applications.
7. 7 / 20 Solution • We need more barking reception on the door. • The barks reception that hears the barking will send a request to the door.
8. 8 / 20 Solution • Barker hears the bark when the dog is outside (has completed its work) • The barks identify sends a request to open the second.
9. 9 / 20 Optional Path? Alternate Path? Who can tell? Use case is confusing. It looks like Todd and Gina always hear Fido barking, but the bark recognizer only hears him sometimes. => But that’s not what Todd and Gina want...
10. 10 / 20 Use cases have to make sense to you Gina and Todd want to automatically detect the bark automatically, then automatically open the door instead of using the remote
11. 11 / 20 Use cases have to make sense to you • With alternative directions in use case. We have a lot of ways to get the dog out and back home. • One of those ways is (see side photo) • Or the door in the correct order from 1-8 in the main path (main path)
12. 12 / 20 Let’s get ready to code... Find out what we need to do: 1. The dog door opening must be at least 12” tall. 2. A button on the remote control opens the dog door if the door is closed, and closes the dog door if the door is open. 3. Once the dog door has opened, it should close automatically if the door isn’t already closed.
13. 13 / 20 Power up the new dog door 1. 1. Update the DogDoorSimulator source code:
14. 14 / 20 Power up the new dog door 2. Recompile all your Java source code into classes.
15. 15 / 20 Power up the new dog door 3.Run the code and watch the humanless dog door go into action:
16. 16 / 20 What happend In our new version of the dog door,the door doesn’t automatically close! • In the scenarios where Todd and Gina press the button on the remote control, here’s the code that runs:
17. 17 / 20 What happend In our new version of the dog door,the door doesn’t automatically close! • But in BarkRecognizer, we open the door, and never close it:
18. 18 / 20 What do YOU think about Doug’s idea? 1. Updating the dog door : Let’s take the code that closed the door from the Remote class, and put it into our DogDoor code. 2. Simplifying the remote control: You’ll need to take this same code out of Remote now, since the dog door handles automatically closing itself 3. A final test drive
19. 19 / 20 Sometimes a change in requirements reveals problems with your system that you didn’t even know were there. Change is constant, and your system should always improve every time you work on it.
20. 20 / 20 Thanks for your attention!