KAPITEL
4
Entwurf von Programmen
| Next | Titel | Inhalt | Vorwort | 1 | 2 | 3 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | Appendix | @ CAAD | Teachers |
KAPITEL
4
Entwurf
von Programmen
It may be helpful to consider what we normally do when confronted with a problem such as: buying fruits. We immediately think of subtasks: need money to pay, select fruits, transport, and others. Perhaps the next thing we may do is to order these subtasks, i.e. which subtask needs to be done before any other subtasks. For example, we cannot pay for the fruits before we have selected the ones we want. Modular program development follows a process that is quite similar.
The concept of modular program development is very simple and very powerful. It involves dividing a task into smaller subtasks and then developing solutions for each of the subtasks. A subtask may be divided into further subtasks and so on. The advantages of this strategy in problem solving (since that is why we write computer programs) are two-fold. First, it is easier to find a solution for a small problem than a bigger one. Second, it is possible that the solutions developed for smaller problems (or subtasks) of one big problem may be reusable in another big problem.
While modular programming provides a good strategy for developing and writing programs, two additional concepts need to be understood as well. These are data models and control structures supported in a specific programming language.
Consider the problem of buying the fruits. We need a list of names of fruits (i.e. character strings), amount of each fruit we wish to buy (which may be a whole number like 6 bananas or a number with fractions like 1.25 kilograms of berries). Further, we may have a list that we consult during the shopping trip and upon which we tick off each fruit as we take it off the shelf. These are the different kinds of data types we normally use in computer programs.
An additional thing to note here with the example of shopping for fruits is that we keep a list of fruits from the start till the end, i.e. it is available at all times during the shopping trip. In computer programs such data items are referred to as global variables. On the other hand, while selecting the berries, we may look for one kind of color or smell, and for the bananas, a different color or smell. These kinds of data items in computer programs are referred to as local variables, i.e. data that are useful in one context but that are different or not needed in another context.
4.3 Control Structures
A computer program consists of a series of statements that are executed by a computer in the order in which each statement is written in a program. The following are the three possibilities to control the flow of execution of computer programs in most programming languages.
The program planning techniques that are introduced here use natural language to describe the structure of a program. Flow charts and structure diagrams employ visual aides as well. All of these techniques help to organize a project and to isolate possible flaws in the logical structure of a problem solving strategy. They may also reveal opportunities for streamlining a program. At least one of these techniques should be employed to fully outline a new programming task before ANY programming is done.
;Problem Statement: Buy Fruit. ;Problem Statement: Buy Fruit.
;Make a fruit list. ;Go to the ;Make a fruit list. ;List
market. ;Select fruit. ;Pay fruits to buy. ;List the
for the Fruit. ;Go home. quantities. ;Go to the market.
;If open enter. ;If closed go
to another market. ;If
three are closed: Go home.
;find fruit department. ;Select
Fruit. ;find fruit. (loop for
each fruit on list.) ;if
available and good: select.
;if not: find next fruit on list.
;Pay for the Fruit. (if selected.)
;if fruit found: ;pay for
it. ;else, go to another
market or Go home. ;If all
fruit not found: ;go to
another market or Go home. ;Go
home.
Pseudo-code
will help identify what types of data structures and variables might best suit
the task at hand. For instance, the problem illustrated above could employ a
global variable called *fruit_list*, that is a list of sublists; each
sublist containing the name of a fruit and the desired quantity. The need for
various local variables, such as counters, can also be derived from such a
format. Actions that are described more than once in such a description, indicate the chance to write a general operation that can be used for all required occasions. For instance, "Go home" appears four times in the above pseudo-code, indicating a cancellation or successful conclusion of the Buy Fruit program. By checking if all (or any) of the desired fruit has indeed been purchased, a single, generalized go_home function can be written to fit all of the situations in which it might be called.
The degree to which a given programming task should be expanded depends greatly on the complexity of the given task and the programmer's own experience. The goals are clarity, simplicity and legibility.
Statements or structure blocks indicate either a definitive action, a further subset of the program code or an entire program. Statements are limited to one entry point and one point of exit each. Sequential programming is depicted by linking two or more statements together. Conditional constructs are indicated by diamond shapes that also have only one point of entry, but have more than one exiting point. Loops are indicated by combining a sequence of one or more statements and a directional arrow that connects the exit point of the last statement to the entry point of the first statement in a loop. The following is a flow chart equivalent to the simple form of the pseudo-code illustrated in the previous section:
Each statement or structure block of this flow chart can be extended into a more detailed representation. The following illustrates an expansion of the Select fruit statement:
Notice that the expanded statement, like the original, also has only one point of entry and one exit. The expanded version must require and produce exactly the same information that the simpler statement does. In this example, the *fruit_list* variable, created while executing the statement Make a list, was required in order to perform the action indicated by the first substatement of Select fruit: Look for 1st fruit on list. The *fruit_list* variable is also altered during the course of Select fruit, if fruit on the list is indeed found and selected. By passing the updated version of the *fruit_list* variable out of Select fruit, and into the next statement, Pay for the fruit will be able to check what must be paid for.
4.4.3 Structure Diagrams
Structure diagrams are similar in many ways to flow charts. They graphically represent the basic structure of the problem solving strategy selected for a given Problem Statement, using a slightly different graphic vocabulary. Structure diagrams tend to require terminology related more closely to programming language than flow charts do. The following are representations used to illustrate some of the more common control structures in a program: Statement, if-then-else, conditions and loops.
As in the case of flow charts, statements can represent specific actions, subdivisions of a program or entire programs. Statements can be constructed out of any legal combination of the control constructs, as well as further embedded statements. Structure diagrams are built within a rectangular framework. This facilitates easy visual checks for completeness that the free form of a flow chart does not allow. The following structure diagram is equivalent to the expanded flow chart illustrated in the previous section.
Note that it is not possible to jump horizontally between statements or constructs in a structure diagram. All actions flow downward, with the exception of loops, towards the terminating bottom line. Complicated programs may require separate structure diagrams for substatements that can be referenced in the main diagram by number or name. Here too, it is important to remember that expanded structure blocks and their simplest statement forms must accept and produce the identical information and results.
The Problem Statement for exercise 5 is the following: Write a program that draws a four cornered building with one of three possible roof forms. The program must be able to do the following tasks: Prompt the user to input the corner points of the building outline; allow the user to specify the height of the building; ask the user to select a roof type where the choices (flat, gable, hip or mansard) are signified by an integer; draw the building specified on two different layers: wall and roof. Other variables such as roof height may also be necessary. The Mansard roof type is optional. (See the description of exercise 5 for further details.)
You should be able to use this pseudo-code as an outline for the next exercise. The pseudo-code should be expanded beyond the minimum level, but not be more than about a page long. Similarly, the flow chart or structure diagram can either be evenly expanded to a reasonable level or one part can be described in complete detail, while the rest remains in simple structure blocks. Spend time considering and documenting function and variable naming conventions. These can either be listed at the appropriate places in your pseudo-code or described separately.
Write the pseudo-code in a text file named 04_name.txt. Include a description of the naming conventions that you have developed for the task. The flow chart or structure diagram can be done in AutoCAD (saved as 04_name.dwg), in any other program or by hand. Submit your finished files to /homes5/prog/abgabe. Charts or diagrams done in programs other than AutoCAD or by hand should be submitted separately in paper form.
| Next | Titel | Inhalt | Vorwort | 1 | 2 | 3 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | Appendix | @ CAAD | Teachers |
This website has been archived and is no longer maintained.