1Taxonomies, Paradigms, and the Untangling of Terminology
Download 210.5 Kb.
|
- Navigate this page:
- 1.1Taxonomies and Paradigms
- 1.2Untangling Terminology, Part 1—the Use of Alternatives and Criteria in Program Logic
- 1.2.1Levels of Program Logic
- 1.2.1.2Intermediate-Level Program Logic
- 1.2.1.3High- (or Top-) Level Program Logic
- 1.2.1.3.1Class 0 High-Level Program Logic
- 1.2.1.3.2Class 1 High-Level Program Logic
- 1.2.1.3.3Class 2 High-Level Program Logic
- 1.2.1.4Logic Levels beyond the Program (“System”-level logic)
- 1.2.2Processing Mode and Program Logic Design
- 1.2.2.2Interactive Processing Mode
- 1.2.2.3Interchangeability between Batch and Interactive Processing Modes
- 1.2.3Interface and Program Logic Design
- 1.2.3.1User Interface Design at Low- and Intermediate-Levels of Program Logic
- 1.2.3.2.3Menu-Driven Chapter 10 includes a discussion of menu-driven program logic. 1.2.3.2.4Direct Manipulation
- 1.2.4.1Operating Systems
- 1.2.4.2Event-Driven Program Logic
1Taxonomies, Paradigms, and the Untangling of TerminologyJoyce Farrell, our textbook author, raises a number of interrelated issues on p. 92. I have tried to analyze her terminology in comparison to a dozen or so other print and web authors. I have tried to summarize or quote a number of these other authors below in outline form. I would propose to distinguish between the following aspects of computer programming:
1.1Taxonomies and ParadigmsThe term “taxonomy” generally means “an orderly classification”. Until recently, it was used mostly by biologists to indicate an orderly classification of plants and animals according to their presumed natural relationships. Computer technology authors have adopted the term to indicate their various efforts to bring order to a complex and constantly evolving discipline. Unfortunately, “taxonomy” is beginning to achieve “buzzword” status. “Paradigm” is another term which is definitely in buzzword status. Nevertheless, it can still be useful if treated carefully. Its basic meaning is “a model, example, or pattern, especially an outstandingly clear or typical pattern or archetype”. More recently, it has come to mean some pattern or method used to interpret, understand, express, or (over?) simplify something more complex, such as “reality”—a kind of “world view” sort of thing. Computer technology authors seem to have adopted the term to classify various major types of programming languages. 1.2Untangling Terminology, Part 1—the Use of Alternatives and Criteria in Program LogicWhat I haven’t found so far is a good characterization of the underlying design decisions that software designers and programmers need to make in order to realize their analysis and design. Toward this end, it may be helpful to consider the role of logical alternatives and their related criteria in a program. As near as I can tell, all programming languages, properly so called, provide some means of specifying alternative evaluations or courses of action, and some means of specifying the criteria to select between those alternatives. In our course discussions so far, that would encompass the “decision” step and its use in selection and repetition structures. It is possible for alternatives criteria to be based entirely on processing which is completely internal to the program, for example alternatives criteria based on a pseudo-random number generator. However, such programs would be self-deterministic, not very flexible, and probably of limited usefulness. It is much more common to base alternatives criteria on input to the program, or, indirectly, on calculations based on input. This allows the programmer to provide the program with various degrees of responsiveness to that input. Most programs, then, are programmer-specified combinations of basic evaluations or courses of action, and criteria-determined alternatives. 1.2.1Levels of Program LogicThese alternatives and their criteria can be applied at any or all of several different levels in the overall program logic. 1.2.1.1Low-Level Program LogicAt a relatively “low” level, alternatives and their criteria can be applied to particular data values. Chapter 5 of Farrell deals primarily with this level of programming. Major sections of chapters 6, 8, 9, and 10 also pertain. 1.2.1.2Intermediate-Level Program LogicAt an “intermediate” level, alternatives and their criteria can be used to direct the processing of blocks of data. Examples include selecting, sorting, and organizing data, merging of multiple files, and the use of “transaction action codes” (“add”, “change”, or “delete”)—on a record by record basis. Chapters 7 and 11 illustrate these examples, along with major sections of chapters 6, 8, and 9. 1.2.1.3High- (or Top-) Level Program LogicThe application of alternatives and criteria at a “high” level of program logic, i.e., in the mainline logic or “main loop” of a program, has the greatest effect on a program’s “personality”, that is, how the program is perceived by its users. For example, the popular distinction between “batch” and “interactive” processing, as well as the various approaches to batch and interactive processing, is most commonly manifested at this level of program design. Chapter 10 includes a discussion of batch processing and interactive processing. Likewise, while user interface issues pertain at all program logic levels, they are particularly relevant at the high level for interactive programs. At this point, I would like to employ some terminology to describe the various types of high level program logic, independent of considerations of processing mode or user interface. If such a terminology is out there discipline wide, so far I haven’t been able to find it. It appears that Farrell is also struggling with this issue. Unfortunately, she has chosen some terminology that is easily confused with other common usages. So, for the purposes of this discussion at least, I would propose the following classes of high level program logic. 1.2.1.3.1Class 0 High-Level Program LogicThis is the simplest possible form of high-level program logic. There are no alternatives and criteria, hence no looping or selection. It just executes straight through, step by step, from start to end. It has very limited application. 1.2.1.3.2Class 1 High-Level Program LogicThis class is the simplest that results in truly useful programs. It includes a “main loop” with but a single criterion to determine whether the end of the input data has been encountered, along with alternatives to loop back and continue processing additional input data if the end has not yet been encountered or to conclude processing if the end has been encountered. Chapters 4 though 9, 11, and parts of 10 and 12 illustrate this approach. 1.2.1.3.3Class 2 High-Level Program LogicFor now, this is a catchall class that encompasses all high-level program logic more complex than Class 0 or Class 1. It will typically include a main loop with program termination as just one of several or even many alternatives and criteria. 1.2.1.4Logic Levels beyond the Program (“System”-level logic)For the sake of completeness, I would note that most modern operating systems provide various facilities such as a (job) control language, “batch command files”, scripting, macros, or “record/playback”. At their most basic, these facilities provide a way to sequence a series of requests to the operating system to perform various system functions or to initiate specified utility or application programs. Once the sequence is initiated, it can be carried out automatically. User or system operator interaction may be provided for, but is not necessary. Many of these facilities also allow for selection and repetition logic through the use of some form of alternative sequences and related criteria. The most advanced forms of scripting even allow alternatives to be applied to standard program input using criteria based on standard program output. 1.2.2Processing Mode and Program Logic Design1.2.2.1Batch Processing ModeMost everyone seems to agree that batch-oriented programs are those that take relatively large collections of data, such as data files, and process these large collections forthwith. The only user intervention consists of gathering the data into the collection, initiating the execution of the program or submitting the program for later execution, and receiving, distributing, and acting on the output produced by the program. The mainline logic of batch-oriented programs is typically “Class 1”. There are examples of “Class 2” batch-oriented programs, such as “command-driven” batch-oriented programs. 1.2.2.2Interactive Processing ModeThere is less agreement about the precise meaning of “interactive”. The most general definition of “interactive processing” is roughly this: a mode of processing where the program receives input, processes the input, and returns output that is “immediately” available to help determine further input. The program then awaits further input. This definition has several significant implications. For one thing, because the computer will be awaiting further input, there must be some “correspondent” (other than a data file) that can provide the further input, based on the previous output. A human user is the most familiar correspondent; but other types of correspondents are possible, including (computer numeric or process control of) machinery, and (interaction with) external physical phenomena or other computer systems. Note that batch processing may also involve interaction, but that this must take place between the time when the program terminates and the time when its execution is next initiated. With the interactive processing mode, interaction takes place between the time when the program is initiated and the time when it terminates, in other words, while the program is still “running”. A second implication is “response time”. The timing requirements of the program’s external correspondent must be taken into consideration. Both hardware and software design features may need to be brought to bear to meet these response time requirements. Systems which are able to meet the response time requirements of external correspondents are commonly called “real time” systems. For the human user, response time requirements may be largely psychological but nonetheless real. A third implication is what to do with a computer system that is awaiting further interactive input. For a mechanical or phenomenal correspondent, the wait time may be from relatively short to practically non-existent. The wait for input from a human user will, on the other hand, be fairly significant from the computer system’s point of view. For a relatively inexpensive single user system, an idle computer system may be acceptable, and no special handling may be needed. For a multi-user or multi-tasking system, there are a number of strategies available to redeem the wait time for use by other users or tasks. A fourth implication is “on-line” connection. “On-line” refers to the state of (equipment) being directly controlled by or in direct communication with a computer. (Active networking is included.) On the other hand, “off-line” refers to (equipment) not being directly controlled by or connected to a computer. (Applications designed for batch processing mode can theoretically tolerate the delays involved with input-output via off-line equipment. Typically, off-line equipment records data into files or outputs data from files independently of the computer that processes the data. Of course, software designed for batch processing mode can just as well use on-line input-output equipment.) The relatively short response time required by interactive processing generally requires on-line input-output equipment, however. Programmers can design very limited interactive programs using only “Class 1” high-level program logic. “Class 2” is usually more difficult to program, but gives the programmer many more options to satisfy human factor requirements in the user interface.
In addition, most modern operating systems provide various facilities such as “batch command files”, scripting, macros, or “record/playback”, and the ability to redirect keyboard input from and console output to data files. With some effort, the programmer can embed interactive-oriented programs in a “batch” environment. Also, there are forms of high-level program logic that can function in either a batch or an interactive mode, although with perhaps varying degrees of effectiveness. One example would be “command-driven” program logic.
1.2.3.1.1Prompting1.2.3.1.2Form Fill-in (Screen/Window-based)1.2.3.2Interface Design at the High-Level of Program Logic1.2.3.2.1Command-DrivenChapter 13 includes a discussion of command-driven program logic. 1.2.3.2.2Function-key Driven1.2.3.2.3Menu-DrivenChapter 10 includes a discussion of menu-driven program logic. 1.2.3.2.4Direct Manipulation1.2.4Implementing High-Level Alternatives and CriteriaThe more high-level alternatives and criteria that a program design calls for, the more complex the mainline logic or main loop becomes. It is certainly possible for the application programmer to directly code all the logic involved with these features. However, several facilities are commonly available to assist the programmer in this regard. 1.2.4.1Operating SystemsOperating system designers and programmers must provide batch and interactive user interfaces for the operating system in order to provide for user control over the system, for example to allow the user to call for the initiation of execution of a particular program. Many aspects of these existing interfaces may be available for use by application programs as well. 1.2.4.2Event-Driven Program LogicEvent-driven program logic is useful for designing and implementing both human user and nonhuman interfaces. Chapter 13 includes a discussion of event-driven program logic. In order to allow the run-time environment or operating system to redeem wait time for other users and tasks, and/or in order to free the application programmer from the complexities of managing events generated by GUIs, many event-based programming environments provide the programmer with a main loop or mainline logic which will wait for events to occur. The application programmer does not have to code the main loop or mainline logic. There are many different ways this can be implemented. In some programming environments, the programmer must code, as part of the program, the criteria that identify the various types of events which may occur and then invoke the appropriate alternative modules. In others, the programmer uses some mechanism external to the program to specify which modules go with which types of events. A third approach is to require the programmer to include executable code, typically part of initial housekeeping, which will inform the run-time environment about which modules are to be associated with which types of events. A fourth approach, which can be used with object-oriented programming languages, is to allow the programmer to provide a new definition for an “event handler” method that will “override” the standard default method of the same name defined for the object class of the object to which the event is related.
Download 210.5 Kb. Share with your friends:
|