CSC323 2010S Software Design

Head First OOA&D 4: Taking Your Software Into The Real World

McLaughlin, Brett D., Pollice, Gary, & West, David (2007). Taking Your Software Into The Real World. Chapter 4 of Head First Object-Oriented Analysis & Design. Sebastapol, CA: O'Reilly.

Why is the book advertising Apple products? [-]

What was I supposed to learn in the reading from HFOOAD? The chapter is called Analysis, but they just go on and on about the dog door example. [-]

What was I supposed to get out of this reading? I've been trying to come up with a question, but I can't. I don't know what I was supposed to learn. There were a few vague ideas, but they weren't clearly defined, or if they were, the book did a good job of hiding them from me. [-]

The use case (Pg. 177) for Opening/Closing the door is very long with many alternate paths. Would it make sense to at some point split into 2 use cases- one for open/closing the door with a remote and one for automatic opening when a bark is recognized? Is it better to have multiple simple use cases or less but more comprehensive ones?

Is there any reason whatsoever NOT to filter out nouns that aren't part of the system at the time of noun analysis?

Why is the bark/Bark/list of barks kept in the DogDoor? It would seem like the BarkRecognizer would be a better place to store this. [x2]

Why is it a better design decision to go with multiple barks instead of using a less strict version of equal to? The solution given still has an issue in the real world, because if not enough barks are recorded, then the dog door is still going to fail in the same way.

What happens if the owner has multiple dogs or if many dogs in the neighborhood sound similarly? Is the code able to store two different dogs' barks?

In what context do you use the notation 1.1, 1.2, 1.3, for alternate paths in use cases rather than 1.1, 2.1, 3.1?

Disclaimer: I usually create these pages on the fly, which means that I rarely proofread them and they may contain bad grammar and incorrect details. It also means that I tend to update them regularly (see the history for more details). Feel free to contact me with any suggestions for changes.

This document was generated by Siteweaver on Tue Feb 16 08:15:26 2010.
The source to the document was last modified on Tue Feb 16 08:01:46 2010.
This document may be found at

You may wish to validate this document's HTML ; Valid CSS! ; Creative Commons License

Samuel A. Rebelsky,

Copyright © 2010 Samuel A. Rebelsky. This work is licensed under a Creative Commons Attribution-NonCommercial 2.5 License. To view a copy of this license, visit or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.