Beginning Programming: Designing a Program

This chapter is from the book

Sams Teach Yourself Beginning Programming in 24 Hours, 2nd Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

Sams Teach Yourself Beginning Programming in 24 Hours, 2nd Edition

Learn More Buy

Steps to Design

There are three fundamental steps you should perform when you have a program to write:

1. Define the output and data flows.

2. Develop the logic to get to that output.

3. Write the program.

Notice that writing the program is the last step in writing the program. This is not as silly as it sounds. Remember that physically building the house is the last stage of building the house; proper planning is critical before any actual building can start. You will find that actually writing and typing in the lines of the program is one of the easiest parts of the programming process. If your design is well thought out, the program practically writes itself; typing it in becomes almost an afterthought to the whole process.

Step 1: Define the Output and Data Flows

Before beginning a program, you must have a firm idea of what the program should produce and what data is needed to produce that output. Just as a builder must know what the house should look like before beginning to build it, a programmer must know what the output is going to be before writing the program.

Anything that the program produces and the user sees is considered output that you must define. You must know what every screen in the program should look like and what will be on every page of every printed report.

Some programs are rather small, but without knowing where you're heading, you may take longer to finish the program than you would if you first determined the output in detail. Liberty BASIC comes with a sample program called Contact3.bas that you can run. Select File, Open, and select Contact3.bas to load the file from your disk. Press Shift+F5 to run the program and then you should see the screen shown in Figure 3.1. No contacts exist when you first run the program, so nothing appears in the fields initially. A field, also known as a text box, is a place where users can type data.

Figure 3.1 Even Liberty BASIC's small Contact Management program window has several fields.

If you were planning to write such a contact program for yourself or someone else, you should make a list of all fields that the program is to produce onscreen. Not only would you list each field but you also would describe the fields. In addition, three Windows command buttons appear in the program window. Table 3.1 details the fields on the program's window.

Table 3.1 Fields That the Contact Management Program Displays

Many of the fields you list in an output definition may be obvious. The field called Name obviously will hold and display a contact's name. Being obvious is okay. Keep in mind that if you write programs for other people, as you often will do, you must get approval of your program's parameters. One of the best ways to begin is to make a list of all the intended program's fields and make sure that the user agrees that everything is there. As you'll see in a section later this hour named "Rapid Application Development," you'll be able to use programs such as Visual Basic to put together a model of the actual output screen that your users can see. With the model and with your list of fields, you have double verification that the program contains exactly what the user wants.

Input windows such as the Contacts program data-entry screen are part of your output definition. This may seem contradictory, but input screens require that your program place fields on the screen, and you should plan where these input fields must go.

The output definition is more than a preliminary output design. It gives you insight into what data elements the program should track, compute, and produce. Defining the output also helps you gather all the input you need to produce the output.

The output definition consists of many pages of details. You must be able to specify all the details of a problem before you know what output you need. Even command buttons and scrolling list boxes are output because the program will display these items.

In Hour 1, you learned that data goes into a program and the program outputs meaningful information. You should inventory all the data that goes into the program. If you're adding Java code to a Web site to make the site more interactive, you will need to know if the Web site owners want to collect data from the users. Define what each piece of data is. Perhaps the site allows the user to submit a name and e-mail address for weekly sales mailings. Does the company want any additional data from the user such as physical address, age, and income?

A few years ago some OOP experts developed a process for designing OOP programs called object-oriented design (OOD). OOD made an advanced science out of specifying data to be gathered in a program and defining that data in a way that was appropriate for the special needs of OOP programmers. Grady Booch was one of the founders of object-oriented design. It is his specifications from over a decade ago that help today's OOP programmers collect data for the applications they are about to write and to turn that data into objects for programs.

In the next hour, "Getting Input and Displaying Output," you'll learn how to put these ideas into a program. You will learn how a program asks for data and produces information on the screen. This I/O (input and output) process is the most critical part of an application. You want to capture all data required and in an accurate way.

Something is still missing in all this design discussion. You understand the importance of gathering data. You understand the importance of knowing where you're headed by designing the output. But how do you go from data to output? That's the next step in the design process—you need to determine what processing will be required to produce the output from the input (data). You must be able to generate proper data flows and calculations so that your program manipulates that data and produces correct output. The final sections of this hour will discuss ways to develop the centerpiece—the logic for your programs.

In conclusion, all output screens, printed reports, and data-entry screens must be defined in advance so you know exactly what is required of your programs. You also must decide what data to keep in files and the format of your data files. As you progress in your programming education you will learn ways to lay out disk files in formats they require. When capturing data, you want to gather data from users in a way that is reasonable, requires little time, and has prompts that request the data in a friendly and unobtrusive manner. That's where rapid application development (discussed next) and prototyping can help.

Prototyping

In the days of expensive hardware and costly computer usage time, the process of system design was, in some ways, more critical than it is today. The more time you spent designing your code, the more smooth the costly hands-on programming became. This is far less true today because computers are inexpensive and you have much more freedom to change your mind and add program options than before. Yet the first part of this hour was spent in great detail explaining why up-front design is critical.

The primary problem many new programmers have today is they do absolutely no design work. That's why many problems take place, such as the one mentioned earlier this hour about the company that wanted far more in their Web site than the programmer ever dreamed of.

Although the actual design of output, data, and even the logic in the body of the program itself is much simpler to work with given today's computing tools and their low cost, you still must maintain an eagle-eye toward developing an initial design with agreed-upon output from your users. You must also know all the data that your program is to collect before you begin your coding. If you don't, you will have a frustrating time as a contract programmer or as a corporate programmer because you'll constantly be playing catch-up with what the users actually want and failed to tell you about.

One of the benefits of the Windows operating system is its visual nature. Before Windows, programming tools were limited to text-based design and implementation. Designing a user's screen today means starting with a programming language such as Visual Basic, drawing the screen, and dragging objects to the screen that the user will interact with, such as an OK button. Therefore, you can quickly design prototype screens that you can send to the user. A prototype is a model, and a prototype screen models what the final program's screen will look like. After the user sees the screens that he or she will interact with, the user will have a much better feel for whether you understand the needs of the program.

Although Liberty BASIC does not provide any prototyping tools, programming languages such as Visual C++ and Visual Basic do. Figure 3.2 shows the Visual Basic development screen. The screen looks rather busy, but the important things to look for are the Toolbox and the output design window. To place controls such as command buttons and text boxes on the form that serves as the output window, the programmer only has to drag that control from the Toolbox window to the form. So to build a program's output, the programmer only has to drag as many controls as needed to the form and does not have to write a single line of code in the meantime.

Figure 3.2 Program development systems such as Visual Basic provide tools that you can use to create output definitions visually.

Once you place controls on a Form window with a programming tool such as Visual Basic, you can do more than show the form to your users. You actually can compile the form just as you would a program and let your user interact with the controls. When the user is able to work with the controls, even though nothing happens as a result, the user is better able to tell if you understand the goals of the program. The user often notices if there is a missing piece of the program and can also offer suggestions to make the program flow more easily from a user's point of view.

Rapid Application Development

A more advanced program design tool used for defining output, data flows, and logic itself is called Rapid Application Development, or RAD for short. Although RAD tools are still in their infancy, you will find yourself using RAD over the span of your career, especially as RAD becomes more common and the tools become less expensive.

RAD is the process of quickly placing controls on a form—not unlike you just saw done with Visual Basic—connecting those controls to data, and accessing pieces of prewritten code to put together a fully functional application without writing a single line of code. In a way, programming systems such as Visual Basic are fulfilling many goals of RAD. When you place controls on a form, as you'll see done in far more detail in Hour 16, "Programming with Visual Basic," the Visual Basic system handles all the programming needed for that control. You don't ever have to write anything to make a command button act like a command button should. Your only goal is to determine how many command buttons your program needs and where they are to go.

But these tools cannot read your mind. RAD tools do not know that, when the user clicks a certain button, a report is supposed to print. Programmers are still needed to connect all these things to each other and to data, and programmers are needed to write the detailed logic so that the program processes data correctly. Before these kinds of program development tools appeared, programmers had to write thousands of lines of code, often in the C programming language, just to produce a simple Windows program. At least now the controls and the interface are more rapidly developed. Someday, perhaps a RAD tool will be sophisticated enough to develop the logic also. But in the meantime, don't quit your day job if your day job is programming, because you're still in demand.

Top-Down Program Design

For large projects, many programming staff members find that top-down design helps them focus on what a program needs and helps them detail the logic required to produce the program's results. Top-down design is the process of breaking down the overall problem into more and more detail until you finalize all the details. With top-down design, you produce the details needed to accomplish a programming task.

The problem with top-down design is that programmers tend not to use it. They tend to design from the opposite direction (called bottom-up design). When you ignore top-down design, you impose a heavy burden on yourself to remember every detail that will be needed; with top-down design, the details fall out on their own. You don't have to worry about the petty details if you follow a strict top-down design because the process of top-down design takes care of producing the details.

Here is the three-step process necessary for top-down design:

1. Determine the overall goal.

2. Break that goal into two, three, or more detailed parts; too many more details cause you to leave out things.

3. Put off the details as long as possible, then keep repeating steps 1 and 2 until you cannot reasonably break down the problem any further.

You can learn about top-down design more easily by relating it to a common real-world problem before looking at a computer problem. Top-down design is not just for programming problems. Once you master top-down design, you can apply it to any part of your life that you must plan in detail. Perhaps the most detailed event that a person can plan is a wedding. Therefore, a wedding is the perfect place to see top-down design in action.

What is the first thing you must do to have a wedding? First, find a prospective spouse (you'll need a different book for help with that). When it comes time to plan the wedding, the top-down design is the best way to approach the event. The way not to plan a wedding is to worry about the details first, yet this is the way most people plan a wedding. They start thinking about the dresses, the organist, the flowers, and the cake to serve at the reception. The biggest problem with trying to cover all these details from the beginning is that you lose sight of so much; it is too easy to forget a detail until it's too late. The details of bottom-up design get in your way.

What is the overall goal of a wedding? Thinking in the most general terms possible, "Have a wedding" is about as general as it can get. If you were in charge of planning a wedding, the general goal of "Have a wedding" would put you right on target. Assume that "Have a wedding" is the highest-level goal.

Now that you know where you're heading, begin by breaking down the overall goal into two or three details. For instance, what about the colors of the wedding, what about the guest list, what about paying the minister...oops, too many details! The idea of top-down design is to put off the details for as long as possible. Don't get in any hurry. When you find yourself breaking the current problem into more than three or four parts, you are rushing the top-down design. Put off the details. Basically, you can break down "Have a wedding" into the following two major components: the ceremony and the reception.

The next step of top-down design is to take those new components and do the same for each of them. The ceremony is made up of the people and the location. The reception includes the food, the people, and the location. The ceremony's people include the guests, the wedding party, and the workers (minister, organist, and so on—but those details come a little later).

Eventually, you will have several pages of details that cannot be broken down any further. For instance, you'll probably end up with the details of the reception food, such as peanuts for snacking. (If you start out listing those details, however, you could forget many of them.)

Now move to a more computerized problem; assume you are assigned the task of writing a payroll program for a company. What would that payroll program require? You could begin by listing the payroll program's details, such as this:

• Print payroll checks.

• Calculate federal taxes.

• Calculate state taxes.

What is wrong with this approach? If you said that the details were coming too early, you are correct. The perfect place to start is at the top. The most general goal of a payroll program might be "Perform the payroll." This overall goal keeps other details out of this program (no general ledger processing will be included, unless part of the payroll system updates a general ledger file) and keeps you focused on the problem at hand.

Consider Figure 3.3. This might be the first page of the payroll's top-down design. Any payroll program has to include some mechanism for entering, deleting, and changing employee information such as address, city, state, zip code, number of exemptions, and so on. What other details about the employees do you need? At this point, don't ask. The design is not ready for all those details.

Figure 3.3 The first page of the payroll program's top-down design would include the highest level of details.

There is a long way to go before you finish with the payroll top-down design, but Figure 3.3 is the first step. You must keep breaking down each component until the details finally appear. Only after you have all the details ready can you begin to decide what the program is going to produce as output.

Only when you and the user gather all the necessary details through top-down design can you decide what is going to comprise those details.

Step 2: Develop the Logic

After you and the user agree to the goals and output of the program, the rest is up to you. Your job is to take that output definition and decide how to make a computer produce the output. You have taken the overall problem and broken it down into detailed instructions that the computer can carry out. This doesn't mean that you are ready to write the program—quite the contrary. You are now ready to develop the logic that produces that output.

The output definition goes a long way toward describing what the program is supposed to do. Now you must decide how to accomplish the job. You must order the details that you have so they operate in a time-ordered fashion. You must also decide which decisions your program must make and the actions produced by each of those decisions.

Throughout the rest of this 24-hour tutorial, you'll learn the final two steps of developing programs. You will gain insight into how programmers write and test a program after developing the output definition and getting the user's approval on the program's specifications.

In the past, users would use tools such as flowcharts and pseudocode to develop program logic. A flowchart is shown in Figure 3.4. It is said that a picture is worth a thousand words, and the flowchart provides a pictorial representation of program logic. The flowchart doesn't include all the program details but represents the general logic flow of the program. The flowchart provides the logic for the final program. If your flowchart is correctly drawn, writing the actual program becomes a matter of rote. After the final program is completed, the flowchart can act as documentation to the program itself.

Figure 3.4 The flowchart depicts the payroll program's logic graphically.

Flowcharts are made up of industry-standard symbols. Plastic flowchart symbol outlines, called flowchart templates, are still available at office supply stores to help you draw better-looking flowcharts instead of relying on freehand drawing. There are also some programs that guide you through a flowchart's creation and print flowcharts on your printer.

Although some still use flowcharts today, RAD and other development tools have virtually eliminated flowcharts except for depicting isolated parts of a program's logic for documentation purposes. Even in its heyday of the 1960s and 1970s, flowcharting did not completely catch on. Some companies preferred another method for logic description called pseudocode, sometimes called structured English, which is a method of writing logic using sentences of text instead of the diagrams necessary for flowcharting.

Pseudocode doesn't have any programming language statements in it, but it also is not free-flowing English. It is a set of rigid English words that allow for the depiction of logic you see so often in flowcharts and programming languages. As with flowcharts, you can write pseudocode for anything, not just computer programs. A lot of instruction manuals use a form of pseudocode to illustrate the steps needed to assemble parts. Pseudocode offers a rigid description of logic that tries to leave little room for ambiguity.

Here is the logic for the payroll problem in pseudocode form. Notice that you can read the text, yet it is not a programming language. The indention helps keep track of which sentences go together. The pseudocode is readable by anyone, even by people unfamiliar with flowcharting symbols.

For each employee:
 If the employee worked 0 to 40 hours then
 net pay equals hours worked times rate.
 Otherwise,
 if the employee worked between 40 and 50 hours then
  net pay equals 40 times the rate;
  add to that (hours worked –40) times the rate times 1.5.
 Otherwise,
  net pay equals 40 times the rate;
  add to that 10 times the rate times 1.5;
  add to that (hours worked –50) times twice the rate.
 Deduct taxes from the net pay.
Print the paycheck.

Step 3: Writing the Code

The program writing takes the longest to learn. After you learn to program, however, the actual programming process takes less time than the design if your design is accurate and complete. The nature of programming requires that you learn some new skills. The next few hourly lessons will teach you a lot about programming languages and will help train you to become a better coder so that your programs will not only achieve the goals they are supposed to achieve, but also will be simple to maintain.