BECOME A COMPUTER GURU Beginning Programming: Designing a Program There are three fundamental steps you should perform when you have a program to write: DEFINE THE OUTPUT AND DAT FLOWS DEVELOP THE LOGIC TO GET TO THAT OUTPUT . 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 youre 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 BASICs 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 programs window. Table 3.1 Fields That the Contact Management Program Displays Field Type Description Contacts Scrolling list Displays the list of contacts Name Text field Holds contacts name Address Text field Holds contacts address City Text field Holds contacts city State Text field Holds contacts state Zip Text field Holds contacts zip code Phone # Text field Holds contacts phone number Stage Fixed, scrolling list Displays a list of possible stages this contact might reside in, such as being offered a special follow-up call or perhaps this is the initial contact Notes Text field Miscellaneous notes about the contact such as whether the contact has bought from the company before Filter Contacts Fixed, scrolling list Enables the user to search for groups of contacts based on the stage the contacts are in, enabling the user to see a list of all contacts who have been sent a mailing Edit Command button Enables the user to modify an existing contact Add Command button Enables the user to add a new contact OK Command button Enables the user to close the contact window Many of the fields you list in an output definition may be obvious. The field called Name obviously will hold and display a contacts 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 programs parameters. One of the best ways to begin is to make a list of all the intended programs fields and make sure that the user agrees that everything is there. As youll see in a section later this hour named Rapid Application Development, youll 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. CAUTION Some programs produce a huge amount of output. Dont skip this first all-important step in the design process just because there is a lot of output. Because there is more output, it becomes more important for you to define it. Defining the output is relatively easy—sometimes even downright boring and time-consuming. The time you need to define the output can take as long as typing in the program. You will lose that time and more, however, if you shrug off the output definition at the beginning. 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 youre 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? Object-Oriented Design Throughout this 24-hour tutorial you will learn what object-oriented programming (OOP) is all about. Basically, OOP turns data values, such as names and prices, into objects that can take on a life of their own inside programs. Hour 14, Java Has Class, will be your first detailed exposure to objects. 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 todays 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, youll 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 youre headed by designing the output. But how do you go from data to output? Thats 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. Thats 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. Thats 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 todays 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 dont, you will have a frustrating time as a contract programmer or as a corporate programmer because youll 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 users 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 programs 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 programs 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 users point of view. CAUTION The prototype is often only an empty shell that cannot do anything but simulate user interaction until you tie its pieces together with code. Your job as a programmer has only just begun once you get approval on the screens, but the screens are the first place to begin because you must know what your users want before you know how to proceed. 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 youll 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 dont 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, dont quit your day job if your day job is programming, because youre still in demand. TIP Teach your users how to prototype their own screens! Programming knowledge is not required to design the screens. Your users, therefore, will be able to show you exactly what they want. The prototyped screens are interactive as well. That is, your users will be able to click the buttons and enter values in the fields even though nothing happens as a result of that use. The idea is to let your users try the screens for a while to make sure they are comfortable with the placement and appearance of the controls. 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 programs 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 dont 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. TIP One of the keys to top-down design is that it forces you to put off the details until later. Top-down design forces you to think in terms of the overall problem for as long as possible. Top-down design keeps you focused. If you use bottom-up design, it is too easy to lose sight of the forest for the trees. You get to the details too fast and lose sight of your programs primary objectives. Here is the three-step process necessary for top-down design: Determine the overall goal. Break that goal into two, three, or more detailed parts; too many more details cause you to leave out things. 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 (youll 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 its 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. NOTE The overall goal keeps you focused. Despite its redundant nature, Have a wedding keeps out details such as planning the honeymoon. If you dont put a fence around the exact problem you are working on, youll get mixed up with details and, more importantly, youll forget some details. If youre planning both a wedding and a honeymoon, you should do two top-down designs, or include the honeymoon trip in the top-level general goal. This wedding plan includes the event of the wedding—the ceremony and reception—but doesnt include any honeymoon details. (Leave the honeymoon details to your spouse so you can be surprised. After all, you have enough to do with the wedding plans, right?) Now that you know where youre 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. Dont 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 ceremonys people include the guests, the wedding party, and the workers (minister, organist, and so on—but those details come a little later). TIP Dont worry about the time order of the details yet. The top-down designs goal is to produce every detail you need (eventually), not to put those details into any order. You must know where you are heading and exactly what is required before considering how those details relate to each other and which come first. Eventually, you will have several pages of details that cannot be broken down any further. For instance, youll 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 programs 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 payrolls 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, dont ask. The design is not ready for all those details. Figure 3.3 The first page of the payroll programs 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 doesnt 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, youll 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 users approval on the programs specifications. CAUTION Only after learning to program can you learn to develop the logic that goes into a program, yet you must develop some logic before writing programs to be able to move from the output and data definition stage to the program code. This chicken before the egg syndrome is common for newcomers to programming. When you begin to write your own programs, youll have a much better understanding of logic development. 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 doesnt 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 programs 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 flowcharts 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 programs 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 doesnt 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. BECOME A COMPUTER GURU
Posted on: Thu, 10 Jul 2014 12:04:06 +0000
Trending Topics
Recently Viewed Topics
© 2015