Overview chapter 4 Head First Object Oriented Design and Analysis

#OOAD
#Head First Object Oriented Design and Analysis

Transcript

1. Chapter 4 : ANALYSIS Tien Dinh
2. One dog, two dog, three dog, four... • The Doug's Dog Door version is selling very well but has a bad idea about the product. • Door can not distinguish between neighbors dogs with dogs of Todd and Gina.
3. Your software has a context • So far, we’ve worked on writing software in a vacuum, and haven’t really thought much about the context that our software is running in. • But our software has to work in the real world, not just in a perfect world. => Analysis: figuring out potential problems, and then solving those problems—before you release your app out into the real world.
4. Identify the problem The first step in good analysis is figuring out potential problems. We already know that there’s a problem when there are multiple dogs in the same neighborhood:
5. Plan a solution Below is a part of the diagram detailing how the dog door system works:
6. Update your use case • Change our dog door diagram • Update it with the new steps • Make to our code.
7. Sam: updating the DogDoor class Sam created a new Bark object, he takes a slightly different path than Randy did in updating his version of the DogDoor class
8. Delegation in Sam’s dog door: an in-depth look Sam is doing something very similar in his Bark and DogDoor classes. • The BarkRecognizer gets a Bark to evaluate. • BarkRecognizer gets the owner’s dog’s bark from DogDoor • BarkRecognizer delegates bark comparison to Bark • Bark decides if it’s equal to the bark from Doug’s hardware
9. The power of loosely coupled applications
10. UML Up Close
11. Pay attention to the nouns in your use case Maria’s figured out something really important: the nouns in a use case are usually the classes you need to write and focus on in your system.
12. It’s all about the use case • Take a close look at Step 3 in the use case, and see exactly which classes are being used • Step 3 in Randy’s use case looks a lot like Step 3 in our use case... but in his step, the focus is on the noun “bark”, and not “the owner’s dog.”
13. A good use case clearly and accurately explains what a system does, in language that’s easily understood. With a good use case complete, textual analysis is a quick and easy way to figure out the classes in your system.
14. Remember: pay attention to those nouns!
15. Code Magnets It’s time to do some more textual analysis. .
16. Code Magnets Solutions
17. UML Investigation Complete
18. Class diagrams aren’t everything Class diagrams provide limited type information Class diagrams don’t tell you how to code your methods Class diagrams only give you a 10,000 foot view of your system
19. How does recognize() work ?
20. Thanks for your attention!