Program Structure
Since the mid-1960s，industry has used the concept of structured program development. Since that time the structured methodology has gained such acceptance that we introduce it immediately. Let’s summarize the process。
The first and most important step in programming is to define the problem. You may have a perfectly written program but it is useless if it doesn’t solve the correct problem. As part of the problem definition, write down exactly what you want the program to do, including a description of the input to the program and the desired output. Until you can do this, you can't begin to write the program.
After defining the problem, the next step is to break the program that is supposed to solve it ontological sections，or modules．We can represent these modules graphically using a structure chart. An or-generation chart has many similarities to a structure chart: the top boxes in each represent the modules or people that control the program flow or activity in the boxes under them, and the bottom boxes represent the level at which most of the detail work is done.
The upper modules or "manager modules” of a structure chart direct processing to the proper place at the proper time. The worker modules each perform one simple task.
A program is much easier to write, test and modify if we break each of the top modules into smaller and smaller modules, much as we would write an outline. The process is called top-down programming. For example, if we must calculate pay, we might create sub modules to compute regular pay, overtime pay and deductions．
As we break the problem into sub modules, we will get to a point where the module can no longer be decomposed. At this stage we will code the module using pseudopodia, a human- language like programmer's shorthand that can outline the steps that the module must perform. Pseudopodium is BASIC without commas or exact syntax; indeed, the actual translation to BASIC code is quite simple.
Pseudopodia is useful both for program design and for program documentation．Another aid to pro-gram documentation and design is the flowchart. Flowcharting provides a highly visual and easily understood way of representing the program's flow of logic.
Once the program is defined and designed, we encode (or code) it in a programming language again using structured techniques. We have described the logic of each worker module using pseudopodia and/oar flowchart. We have recognized that the manager module or modules direct the order in which the worker modules are called on to perform their tasks．At this point, the translation to BASIC is straight for-ward.
Each worker module becomes what BASIC callas subroutine. Within the subroutines are lines; of BASIC code that may be almost line by -line translations from pseudopodia。
The main manager module (at the top of the structure chart) becomes the driver module. In most programs that you write at this stage of your knowledge, the driver module calls subroutines (worker modules) directly, in proper sequence, to perform their tasks. Later we will introduce "middle manage-management"，that is，subroutines called by the driver module that in turn call lower-level subroutines to perform the lowest level tasks．
As an example, see figure 4-1，in BASIC terms, the Payroll Process module becomes the driver module of the BASIC program. It calls the Read Input subroutine (a middle manager)，which in turn calls two more subroutines（worker modules）：Read Employee Master Record and Read Individual Timecards. As you can see from the Calculate Pay part of the structure chart, there can be more than one level of middle management！For example, once all this is translated to BASIC, the driver module (Payroll Process) would at the correct time call the subroutine Calculate Pay, which at the correct time would call the subroutine Calculate Gross Pay, which at the right time would (finally！) Call the subroutine Calculate Regular Pay.
At first, modular programming may seem cumbersome to you, especially for simpler programs．Why use a subroutine, some would ask, when you can just write fewer instructions”nine line"？The reasons become clear when the programs become lengthy and when each subroutine consists of many lines of code. The modular approach allows the programmer to write in a logical fashion. Coding the general outline first and then coding each section separately. In the past, programmers would be almost finished writing a program only to discover a major flaw in their logic, which often required rewriting nearly the entire pro-gram. With modular programming the basic logic is written and checked first. Because each set of steps is written as a separate module, changes and corrections made to that section don't require changes to other modules. For these reasons, most companies have standardized on structured program development for all their computer tasks．
翻譯：
程序結(jié)構(gòu)
60年代中期，在計算機行業(yè)中 提出了結(jié)構(gòu)化程序設(shè)計的概念。自那以后，結(jié)構(gòu)化程序設(shè)計技術(shù)得到 如此廣泛的承認(rèn)以致我國也立即引 進(jìn)了這種技術(shù)。現(xiàn)在就讓我們來看 一下結(jié)構(gòu)化程序設(shè)計的過程。
結(jié)構(gòu)化程序設(shè)計中，第一步也是最關(guān)鍵的一步就是確定所要解決 的問題。你也許可以編寫出一個很完美的程序，但如果它不能正確地解決問題，是沒有任何用處的。在明確問題的過程中，先寫下想要程序完成哪些功能，包括對程序的輸入和理想的輸出的描述，然后才能開始編程。
問題確定之后，下一步就是把 解決問題的程序分解成邏輯上合理 的幾個部分，即模塊。我們可以壓 結(jié)構(gòu)圖來表示這些模塊。結(jié)構(gòu)圖與 組織機構(gòu)圖有很多相似之處：圖中 頂層的盒子所代表的模塊或，對其下的盒子中程序流起控制作用，最底層的盒子代表是所有必須完成的體的工作。
結(jié)構(gòu)圖中較上層的模塊或稱“管理模塊”指明了“適時適地干 適事”的程序。每個工作模塊只執(zhí)行一項任務(wù)。
如果將每個頂層模塊都分解為很多越來越小的模塊，并畫出詳細(xì)的框圖，則程序的編寫、調(diào)試和修改工作就變得簡單多了。這個過程就叫做自頂向下程序設(shè)計。比如，我們在計算工資時，可設(shè)子模塊分別計算出固定工資、加班費和扣除額等項內(nèi)容。
在把問題分解為子模塊時，一直要分解到模塊不能被再分解為止。這時的模塊可用偽代碼來編寫，即一種類似人類語言的程序員速記，能將模塊必須執(zhí)行的步驟列示出來。偽代碼是沒有標(biāo)點或語法 的BASIC語言。事實上，真正要翻譯成BASIC語言代碼是很簡單的。
偽代碼可用于程序設(shè)計和程序 注釋。另外．流程圖也有助于程序 注釋和程序設(shè)計。用流程圖來表示 程序執(zhí)行的邏輯順序，是一種既高 度可視化，又易于理解的方式。
程序一旦確定并設(shè)計好執(zhí)行順序之后，便可運用結(jié)構(gòu)化技術(shù)，通過編程語言將其代碼化。前面我們已描述過用偽代碼或流程圖表示出各個工作模塊的邏輯執(zhí)行順序。也己知道管理模塊指示的順序正是其 調(diào)用工作模塊執(zhí)行任務(wù)的順序。這時，直接將流程圖轉(zhuǎn)化為BASIC語言即可。
每個工作模塊就是BASIC語言中稱作的子程序。每個子程序由很多行BASIC語句組成，這些語句幾乎全是由偽代碼逐行轉(zhuǎn)換而來。
主模塊（結(jié)構(gòu)圖的頂層模塊） 即是驅(qū)動模塊。在大多數(shù)程序中，憑你所知即可寫下主模塊。驅(qū)動模 塊可在適當(dāng)?shù)臅r候直接調(diào)用子程序 （工作模塊）執(zhí)行相應(yīng)的任務(wù)。接下來我們將介紹“中層管理”模塊，即被驅(qū)動模塊所調(diào)用，同時又可順次調(diào)用較低層子程序去執(zhí)行最底層任務(wù)的那些子程序。
如圖4-1，在用BASIC語言編寫 的程序中，工資單處理模塊是驅(qū)動 模塊。該模塊調(diào)用讀輸入子程序（工作模塊）：讀雇員和雇主記錄 子程序以及讀個人工作時間卡片子 程序。從結(jié)構(gòu)圖中的計算工資子程序可看出，中層管理模塊可不止一 層！比如，當(dāng)結(jié)構(gòu)圖全部轉(zhuǎn)換為BASIC語言程序時，驅(qū)動模塊（工資單處理）將適時調(diào)用計一算工資子 程序，計算工資子程序適時地調(diào)用 計算總工資子程序，而計算總工資 子程序又將（最后?。┻m時地調(diào)壓 計算固定工資子程序。
最初，模塊化程序設(shè)計看起來可能很麻煩，尤其是相對于較簡單的程序而百。有人或許會問，當(dāng)你可以直接地逐行編寫較少的指令時， 為什么要采用子程序設(shè)計的方式呢？在程序變得足夠長且每個子程序都由很多行語句組成時，采用子程序的原因就很明顯了模塊化字設(shè)計方法使編譯者可按一定的順序，完成總框圖的代碼表示私 各個部分的獨立編程。過去，程序員在快要完成整個編程工作時，可以發(fā)現(xiàn)程序在邏輯順序上存在一個主要錯誤，這經(jīng)常導(dǎo)致幾乎整個程導(dǎo)的重新編寫。而采用模塊化技術(shù)編程時．首先編寫和檢查的就是程子的基本邏輯關(guān)系。同時各個子程序都是作為單獨的一個模塊編寫的．修改時不需要改變其他模塊。由于這些原因，許多公司都將結(jié)構(gòu)化工序設(shè)計工作標(biāo)準(zhǔn)化以完成各項計算計編程任務(wù)。
Since the mid-1960s，industry has used the concept of structured program development. Since that time the structured methodology has gained such acceptance that we introduce it immediately. Let’s summarize the process。
The first and most important step in programming is to define the problem. You may have a perfectly written program but it is useless if it doesn’t solve the correct problem. As part of the problem definition, write down exactly what you want the program to do, including a description of the input to the program and the desired output. Until you can do this, you can't begin to write the program.
After defining the problem, the next step is to break the program that is supposed to solve it ontological sections，or modules．We can represent these modules graphically using a structure chart. An or-generation chart has many similarities to a structure chart: the top boxes in each represent the modules or people that control the program flow or activity in the boxes under them, and the bottom boxes represent the level at which most of the detail work is done.
The upper modules or "manager modules” of a structure chart direct processing to the proper place at the proper time. The worker modules each perform one simple task.
A program is much easier to write, test and modify if we break each of the top modules into smaller and smaller modules, much as we would write an outline. The process is called top-down programming. For example, if we must calculate pay, we might create sub modules to compute regular pay, overtime pay and deductions．
As we break the problem into sub modules, we will get to a point where the module can no longer be decomposed. At this stage we will code the module using pseudopodia, a human- language like programmer's shorthand that can outline the steps that the module must perform. Pseudopodium is BASIC without commas or exact syntax; indeed, the actual translation to BASIC code is quite simple.
Pseudopodia is useful both for program design and for program documentation．Another aid to pro-gram documentation and design is the flowchart. Flowcharting provides a highly visual and easily understood way of representing the program's flow of logic.
Once the program is defined and designed, we encode (or code) it in a programming language again using structured techniques. We have described the logic of each worker module using pseudopodia and/oar flowchart. We have recognized that the manager module or modules direct the order in which the worker modules are called on to perform their tasks．At this point, the translation to BASIC is straight for-ward.
Each worker module becomes what BASIC callas subroutine. Within the subroutines are lines; of BASIC code that may be almost line by -line translations from pseudopodia。
The main manager module (at the top of the structure chart) becomes the driver module. In most programs that you write at this stage of your knowledge, the driver module calls subroutines (worker modules) directly, in proper sequence, to perform their tasks. Later we will introduce "middle manage-management"，that is，subroutines called by the driver module that in turn call lower-level subroutines to perform the lowest level tasks．
As an example, see figure 4-1，in BASIC terms, the Payroll Process module becomes the driver module of the BASIC program. It calls the Read Input subroutine (a middle manager)，which in turn calls two more subroutines（worker modules）：Read Employee Master Record and Read Individual Timecards. As you can see from the Calculate Pay part of the structure chart, there can be more than one level of middle management！For example, once all this is translated to BASIC, the driver module (Payroll Process) would at the correct time call the subroutine Calculate Pay, which at the correct time would call the subroutine Calculate Gross Pay, which at the right time would (finally！) Call the subroutine Calculate Regular Pay.
At first, modular programming may seem cumbersome to you, especially for simpler programs．Why use a subroutine, some would ask, when you can just write fewer instructions”nine line"？The reasons become clear when the programs become lengthy and when each subroutine consists of many lines of code. The modular approach allows the programmer to write in a logical fashion. Coding the general outline first and then coding each section separately. In the past, programmers would be almost finished writing a program only to discover a major flaw in their logic, which often required rewriting nearly the entire pro-gram. With modular programming the basic logic is written and checked first. Because each set of steps is written as a separate module, changes and corrections made to that section don't require changes to other modules. For these reasons, most companies have standardized on structured program development for all their computer tasks．
翻譯：
程序結(jié)構(gòu)
60年代中期，在計算機行業(yè)中 提出了結(jié)構(gòu)化程序設(shè)計的概念。自那以后，結(jié)構(gòu)化程序設(shè)計技術(shù)得到 如此廣泛的承認(rèn)以致我國也立即引 進(jìn)了這種技術(shù)。現(xiàn)在就讓我們來看 一下結(jié)構(gòu)化程序設(shè)計的過程。
結(jié)構(gòu)化程序設(shè)計中，第一步也是最關(guān)鍵的一步就是確定所要解決 的問題。你也許可以編寫出一個很完美的程序，但如果它不能正確地解決問題，是沒有任何用處的。在明確問題的過程中，先寫下想要程序完成哪些功能，包括對程序的輸入和理想的輸出的描述，然后才能開始編程。
問題確定之后，下一步就是把 解決問題的程序分解成邏輯上合理 的幾個部分，即模塊。我們可以壓 結(jié)構(gòu)圖來表示這些模塊。結(jié)構(gòu)圖與 組織機構(gòu)圖有很多相似之處：圖中 頂層的盒子所代表的模塊或，對其下的盒子中程序流起控制作用，最底層的盒子代表是所有必須完成的體的工作。
結(jié)構(gòu)圖中較上層的模塊或稱“管理模塊”指明了“適時適地干 適事”的程序。每個工作模塊只執(zhí)行一項任務(wù)。
如果將每個頂層模塊都分解為很多越來越小的模塊，并畫出詳細(xì)的框圖，則程序的編寫、調(diào)試和修改工作就變得簡單多了。這個過程就叫做自頂向下程序設(shè)計。比如，我們在計算工資時，可設(shè)子模塊分別計算出固定工資、加班費和扣除額等項內(nèi)容。
在把問題分解為子模塊時，一直要分解到模塊不能被再分解為止。這時的模塊可用偽代碼來編寫，即一種類似人類語言的程序員速記，能將模塊必須執(zhí)行的步驟列示出來。偽代碼是沒有標(biāo)點或語法 的BASIC語言。事實上，真正要翻譯成BASIC語言代碼是很簡單的。
偽代碼可用于程序設(shè)計和程序 注釋。另外．流程圖也有助于程序 注釋和程序設(shè)計。用流程圖來表示 程序執(zhí)行的邏輯順序，是一種既高 度可視化，又易于理解的方式。
程序一旦確定并設(shè)計好執(zhí)行順序之后，便可運用結(jié)構(gòu)化技術(shù)，通過編程語言將其代碼化。前面我們已描述過用偽代碼或流程圖表示出各個工作模塊的邏輯執(zhí)行順序。也己知道管理模塊指示的順序正是其 調(diào)用工作模塊執(zhí)行任務(wù)的順序。這時，直接將流程圖轉(zhuǎn)化為BASIC語言即可。
每個工作模塊就是BASIC語言中稱作的子程序。每個子程序由很多行BASIC語句組成，這些語句幾乎全是由偽代碼逐行轉(zhuǎn)換而來。
主模塊（結(jié)構(gòu)圖的頂層模塊） 即是驅(qū)動模塊。在大多數(shù)程序中，憑你所知即可寫下主模塊。驅(qū)動模 塊可在適當(dāng)?shù)臅r候直接調(diào)用子程序 （工作模塊）執(zhí)行相應(yīng)的任務(wù)。接下來我們將介紹“中層管理”模塊，即被驅(qū)動模塊所調(diào)用，同時又可順次調(diào)用較低層子程序去執(zhí)行最底層任務(wù)的那些子程序。
如圖4-1，在用BASIC語言編寫 的程序中，工資單處理模塊是驅(qū)動 模塊。該模塊調(diào)用讀輸入子程序（工作模塊）：讀雇員和雇主記錄 子程序以及讀個人工作時間卡片子 程序。從結(jié)構(gòu)圖中的計算工資子程序可看出，中層管理模塊可不止一 層！比如，當(dāng)結(jié)構(gòu)圖全部轉(zhuǎn)換為BASIC語言程序時，驅(qū)動模塊（工資單處理）將適時調(diào)用計一算工資子 程序，計算工資子程序適時地調(diào)用 計算總工資子程序，而計算總工資 子程序又將（最后?。┻m時地調(diào)壓 計算固定工資子程序。
最初，模塊化程序設(shè)計看起來可能很麻煩，尤其是相對于較簡單的程序而百。有人或許會問，當(dāng)你可以直接地逐行編寫較少的指令時， 為什么要采用子程序設(shè)計的方式呢？在程序變得足夠長且每個子程序都由很多行語句組成時，采用子程序的原因就很明顯了模塊化字設(shè)計方法使編譯者可按一定的順序，完成總框圖的代碼表示私 各個部分的獨立編程。過去，程序員在快要完成整個編程工作時，可以發(fā)現(xiàn)程序在邏輯順序上存在一個主要錯誤，這經(jīng)常導(dǎo)致幾乎整個程導(dǎo)的重新編寫。而采用模塊化技術(shù)編程時．首先編寫和檢查的就是程子的基本邏輯關(guān)系。同時各個子程序都是作為單獨的一個模塊編寫的．修改時不需要改變其他模塊。由于這些原因，許多公司都將結(jié)構(gòu)化工序設(shè)計工作標(biāo)準(zhǔn)化以完成各項計算計編程任務(wù)。