Finishing the System`s Outlines - Prototypes Are Worth a Thousand Words
(Page 5 of 5 )
It is often said that a picture is worth a thousand words. A prototype is like a picture. A user interface described in text is often harder for the customer to visualize than the same interface described with a diagram or picture. Use cases can provide excellent textual descriptions. A prototype (or screen mockup) gives a more concrete perspective on a program's intended operation. The prototype can spark feedback from the client in both the program's operation and in missing requirements.
DON'T THROW AWAY INFORMATION
When I was presenting these prefactoring guidelines in a talk at the Software Development Conference, Jerry Weinberg made an interesting observation about some of the guidelines in this chapter. He stated that they revolve around the central principle of not throwing away information. For example, describing a price as a double, rather than as a Dollar, decreases the information about the price. Lumping a group of concepts into a single class, rather than splitting them into multiple classes, hides information. Now, if I only could have convinced my mother that my comic book collection was really information...
One of the dangers of making a perfect-looking GUI for a prototype is that the interface represents the program to the user. If the interface is complete, the user might expect that the system is almost complete. Some user interface experts suggest that interfaces be designed using whiteboards or Post-it notes. If you are programming in Java, you can use the Napkin Look and Feel (http://napkinlaf.sourceforge.net/). Tim and I created a rough-draft prototype of the screens for the uses cases we worked on with Sam (Figure 2-1). We went
Figure 2-1. Rental screens
over it with Sam. The cases are simple, so he had no changes in its interface. He did note that the buttons should use a large font so that he could read them without his glasses.
PROTOTYPES ARE WORTH A THOUSAND WORDS
A picture of an interface, such as a screen, can be more powerful than just a description.
* For further information on use cases, see Writing Effective Use Cases by Alistair Cockburn (Addison-Wesley Professional, 2000).
* Finding existing solutions can be problematic. Sometimes it can be hard to describe the solution you seek in such a way that Google™ can find a match.
† See Software Tools by Brian W. Kernighan (Addison-Wesley Professional, 1976) for the earliest discussion I have found on the issue of using tools to create solutions.
* See http://www.literateprogramming.com/ for a discussion of names.
* Not all objects have behavior. Objects that contain just data (sometimes called data transfer objects) are useful in interfacing with GUI classes and passing as objects between networked systems. Data
transfer objects are covered in Chapter 7.
† One reviewer notes that clumping without a responsibility definition for the class can lead to datapolluted classes. Clumping should also involve assigning operations to the clumped concept.
* Once upon a time, Montana had no speed limit other than “reasonable speed.” The upper limit still could be a reasonable number (e.g., 200).
† For an article on strong testing with languages that have implicit typing, see http://www.artima.com/
weblogs/viewpost.jsp?thread=4639.
* Michael Green, a reviewer, called this principle “No magic numbers!” after having to deal with numbers that could not be changed or removed (without negative side effects in apparently unrelated
code). He could find no one who knew what they were for or why they were there.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|
 This article is excerpted from Prefactoring, written by Ken Pugh (O'Reilly; ISBN: 596008740). Check it out today at your favorite bookstore. Buy this book now.
|
|
