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?