Page 82 - Introduction to Programming with Java: A Problem Solving Approach

48 Chapter 2 Algorithms and Design
Sometimes it’s appropriate to think about programs differently from how program- mers think about programs. Suppose all you want to do is use somebody else’s program, and you don’t really care how it’s written. In that case, you would be a user or a client, and what you would need is a client view of the program. The high-level pseudocode im-
mediately above is an example of an informal client view of a desired program. A formal client view of that program would typically include a description of how to use the program and examples of actual input and output. Later, you’ll see many “client views” of Java code that has already been written and is free for you to use as part of any program you write.
It’s useful to keep in mind these two alternate views of a typical computer program. You’ll want to be able to switch back and forth between a client view (when you’re acting as or communicating with an end user of a program), and an implementation view (when you’re designing and writing the program).
2.13 Problem Solving: Asset Management (Optional)
In this section, we ask you to think about a real-world managerial problem at a fairly abstract level. Imagine that you are the Information-Technology (IT) specialist working in the government of a small city. The head of that city’s water department respects your organizational skills and has asked you to come to a city coun- cil meeting and lead a discussion of how you might set up a computer program to help the council manage the assets of that city’s water system.
First, you suggest that the city-council members help you come up with an overall sequence of steps. On a blackboard, you’ll write high-level pseudocode for the “program.” To avoid jargon, you’ll just call this
Describe program to client.
Apago PDF Enhancer
high-level pseudocode a “to-do list.”
After some discussion, the council members agree on—and you list—the following overall steps:3
1. Make an inventory of all water system assets.
2. Prioritize those assets.
3. Schedule future changes, replacements, and additions to those assets.
4. Prepare a long-range budget.
This high-level pseudocode is just four sequential steps, like the sequential steps in the left-hand picture in Figure 2.5.
The council thanks you for your help, and for the next meeting, they ask you to flesh out this list with enough detail to show how you plan to implement each of the four steps. They don’t want to see a bunch of computer code. They just want to see how you’d proceed—to get a feeling for the difficulty of the project.
Translate client view into server view.
Back in your office, you create an informal implementation view of the problem. This view is sometimes called a programmer view or the server view, because the programmer’s implementation provides a service to the client. For step 1, you identify seven variables: assetName, expectedLife, condition, serviceHistory, adjustedLife, age, and remainingLife. For each asset, you’ll have to ask someone in the water depart-
ment to provide appropriate input for each of the first six variables. Then your program will calculate a value for the last variable. You’ll have to repeat this for each significant asset. So here’s an abbreviated pseudocode description of the implementation of step 1:
3 These four steps and their subsequent elaboration are based on recommendations in Asset Management: A Handbook for Small Water Systems, Office of Water (4606M) EPA 816-R-03-016, www.epa.gov/safewater, September, 2003.