tsitinis@qucis.queensu.CA (Vaggelis Tsitinis) (02/26/89)
Structured programming emphasizes programming language constructs such as
while loops, until loops, and if then else statements. Properly used, these
constructs make occurences of loops and branching of control obvious.
Many algorithms have been proposed for restructuring a program into a
simplest one, eliminating the nested loops and avoiding the use of gotos.
However, these techniques do not necessarily produce clear flow of control.
Misuse of control constructs may mislead the reader into expecting patterns
of control flow which do not exist in the initial program. For example, these
techniques may use a repeat statement when the contained code cannot be executed
more than once or add numerous control variables to avoid goto statements. They
also may avoid goto statements by copying segments of code or creating subrou-
tines. The former method results in longer programs and bugs may be introduced
when all the identical segments must be modified. The latter method may result
in subroutines which appear unnatural.
Therefore, we must concentrate on the principles for the use of basic
control structures. These principles fall into two categories:those which
concern the nesting of statements and those which concern the use of branching
statements, such as goto, next, break and stop. A properly structured program
is a program which obeys the aforementioned structuring principles.
A rather straightforward algorithm is one which transforms a flowgraph into
a properly structured program. In general, the properly structured program may
contain goto statements. However, the goto statements occur only where no other
available control contrust describes the flow of control.
Many tools exist dealing with the concept of software restructuring and one
of them is "struct" for structuring fortran programs. The tool has been built
by Brenda S. Baker, Bell Labs, Murray Hill, NJ. 07974
If you know anything for that tool or you have used it, I would appreciate
a comment or to let me know more about it.
Thanks in advance.
e-mail address : tsitinis@qucis.queensu.ca
mail address : Tsitinis Vaggelis
Department of Computing & Information Science
Queen's University
Kingston, Ontario
K7L 3N6
C A N A D Abillwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) (02/27/89)
From article <172@qusunb.queensu.CA>, by tsitinis@qucis.queensu.CA (Vaggelis Tsitinis): > > Many algorithms have been proposed for restructuring a program into a > simplest one, eliminating the nested loops and avoiding the use of gotos. > However, these techniques do not necessarily produce clear flow of control. The January 1988 issue of CACM abstracts (page 140) an October 1988 JACM article which addresses this topic: Eliminating GOTOs While Preserving Program Structure Lyle Ramshaw Suppose we want to eliminate the local GOTO statements of a Pascal program by replacing them with multilevel loop exit statements. The standard ground rules for eliminating GOTOs require that we preserve the flow graph of the program, but they allow us to completely rewrite the control structures that glue together the program's atomic tests and actions. The GOTOs can be eliminated from a program under those ground rules if and only if the flow graph of that program has the graph-theoretic property named reducibility. This paper considers a stricter set of ground rules, introduced by Peterson, Kasami, and Tokura, which demand that we preserve the program's original control structures, as well as its flow graph, while we eliminate its GOTOs. In particular, we are allowed to delete the GOTO statements and the labels that they jump to, and to insert various exit statements and labeled repeat-endloop pairs for them to jump out of. But we are forbidden to change the rest of the program text in any way. The critical issue that determines whether GOTOs can be eliminated under these stricter rules turns out to be the static order of the atomic tests and actions in the program text. This static order can be encoded in the program's flow graph by augmenting it with extra edges. It can then be shown that the reducibility of a program's augmented flow graph, augmenting edges and all, is a necessary and sufficient condition for the eliminability of GOTOs from that program under the stricter rules. For Correspondence: Digital Equipment Corporation Systems Research Center, 130 Lytton Ave., Palo Alto, Ca 94301 USA Bill Wolfe, wtwolfe@hubcap.clemson.edu
psrc@pegasus.ATT.COM (Paul S. R. Chisholm) (02/27/89)
<"Would you like me to summon Data so he could offer a few dozen synonyms?"> In article <172@qusunb.queensu.CA>, tsitinis@qucis.queensu.CA (Vaggelis Tsitinis) writes about software restructuring tools, such as struct (translates unstructured Fortran into structured Ratfor). There are several such products on the market, mostly aimed at Cobol. (Wrinkle up your nose in disgust if you must, but look at it the other way: ninty-nine percent of the *ugly* programs companies depend on are written in Cobol!) But in languages such as Pascal and C, it's not the flow control structures that make maintenance programming difficult. Instead, it's the data structures. First and foremost, because they were never really designed (or even defined) well originally. Second, because there's darned little information left on the data design. Third, because the data structures have changed over the life of the system, often in mischievous ways. (For example, what originally was an abstract data type has been pried open, and the dependecies on data representation have grown throughout the system like a cancer.) Face it; despite the occasional calls for a return to GOTO, flow of program control is one of the few things we understand about programming. WHILE and IF/THEN/ELSE are critical. Multiple choice conditionals (SWITCH in C, CASE in Pascal and nearly every other language) are handy; so are "n-and-a-half" loops, and other ways of terminating a loop at places besides the top. If a chunk of code has a single point of entry and a single point of exit, that code's easier to read and verify. The only controversy lies in abnormal escapes other than the usual exit (RETURN'ing from a subroutine in more than one place; various kinds of compiler generated exception handling). To the problem of structuring a program's flow of control, we've come up with stepwise refinement and top-down design. (Bottom up has its proponents for other reasons, but top-down is *a* solution to *this* problem.) What's the equivalent for the problem of structuring a program's data? Object oriented design seems to be on the right track. Still, we're a long way from having as final an answer for data structures as we have for control structures. > Tsitinis Vaggelis, Department of Computing & Information Science > Queen's University, Kingston, Ontario, K7L 3N6, C A N A D A > tsitinis@qucis.queensu.ca Paul S. R. Chisholm, AT&T Bell Laboratories, att!pegasus!psrc psrc@pegasus.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind.