Home arrow Practices arrow Page 5 - Finishing the System`s Outlines

Prototypes Are Worth a Thousand Words - Practices

This second part of a two-part article completes our coverage of how to talk to a client so that you are both on the same page when designing a system and understanding what it will be required to do. It is excerpted from Prefactoring, written by Ken Pugh (O'Reilly; ISBN: 596008740). Copyright © 2007 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.

TABLE OF CONTENTS:
  1. Finishing the System`s Outlines
  2. Abstracting
  3. Not Just a String
  4. Constant Avoidance
  5. Prototypes Are Worth a Thousand Words
By: O'Reilly Media
Rating: starstarstarstarstar / 2
May 22, 2008

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

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.



 
 
>>> More Practices Articles          >>> More By O'Reilly Media
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

PRACTICES ARTICLES

- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: