McLaughlin, Brett D., Pollice, Gary, & West, David (2007). Give
Them What They Want. Chapter 2 of Head First Object-Oriented
Analysis & Design. Sebastapol, CA: O'Reilly.
McLaughlin, Brett D., Pollice, Gary, & West, David (2007). I Love
You, You're Perfect, Now Change. Chapter 3 of Head First Object-Oriented
Analysis & Design. Sebastapol, CA: O'Reilly.
Are requirements written primarily as an aid to programming or for an inexperienced audience such as a user of the software?
Requirements are written to ensure that the customer and the programmers agree on the main goals of the software.
Should the development of use cases and requirements both be done with
the customer? It eems that everything would be more accurate if both
the programmer and the customer were present.
You don't need the customer there all the time, but you should certainly
review use cases and requirements carefully with the customer.
The concept of a main (or "happy") path and alternate path makes sense in a use case. Do programmers traditionally write out use cases and scenarios for their programs, or is this an example designed to make us think about how to apply requirements we're given to the programs we write?
Authors of reasonable-sized programs regularly write out use cases. Use cases (or something similar) are an important part of most OO methodologies.
Is there a standard system for modeling use cases that is similar to UML? If there is, why didn't this book describe it, and if there isn't, why isn't there one?
In fact, the UML has a notation for use cases. However, there seems to be less consistency in the OO design community about the detail necessary for use cases. UML use case diagrams seem to have a bit less detail than do the narratives in the book.
On page 139, the code for timer is moved from the Remote to
the DogDoor but the code for the test: if (door.isOpen())
{...} is left in the remote. Shouldn't this test also be moved
to DogDoor so that the Remote only sends a
message to DogDoor and then lets the door decide if it's
already open or not? Also, should timer.cancel() also be
called in close()? Will close() be called
twice if the door is already open when close is called the first time? [+]
Good criticisms. Their forucs seems to be more on the overall idea
of the project than on all of the details
DogDoor's open() method seems poorly named, given
that by the end of Chapter 4, it both opens and closes the door. Is there a better way to design this?
The primary purpose is still opening the door, so I think the name is reasonable. It is worth discussing, though.
How does the actual code interface with the hardware regarding the bark receiver? The text explains that the system acknowledges when it receives a bark, but I'm confused with how it actually knows that a bark has been received.
There's some hidden code that calls the appropriate method. You're not supposed to worry about it.
In chapter 2, why does the remote query the door for its open status?
Shouldn't the door be able to take care of that logic for itself? That's
how things with remotes work in real life.
Pedagogical reasons, I think.
It seems like a poor design decision to have the door open on every bark by any dog. When you see an obviously bad design like this from a client, should you try to change their minds before implementing it or just do it (and get more money from them when they want it changed)?
I would discuss the design with them. I would also expect a variety of use cases to reveal the problems. Hey, maybe the bark recognizer can distinguish different dogs. But you'll see further analysis of this issue in Chapter 4.
On page 82, it seems like the code is set up to automatically close 5 seconds after it is opened. Isn't this poorly designed? It would be very inconvenient: this means that every time that Fido goes outside, the owners would have to listen for him to bark and let him back in, therefore having to stay awake longer and press the remote twice. The book suggests that this would only happen occasionally - but with the 5 second time limit, this would happen every time the dog went out. Is this the desired operation? Wouldn't some system involving a sensor be better?
I think this is an attribute of the system that would be field tuned.
At what point does a customer requirement reach the point where it makes sense for a software designer to flat out say no rather than telling the customer what the costs of implementing that requirement would be and having them make a decision based on that?
I'd make the cutoff at the point that it wasn't worth my time or energy. More generally, I expect it depends on resources. For example, if you expect that a project will require more resources than you can provide (e.g., because your resources need to be devoted to more than one project), even if the client is willing to pay for them, then I think you have to say no.
How should we document use cases and requirements when designing our own software? Are there tools available to aid this process when designing complex real-world applications?
For now, include the details you consider appropriate. In the end, what format you use will depend on your company's standards.
;
