Drakon Book : Chapter 16 [English Translation]

Chapter 16

Page HistoryLast edited by PBworks 8 years, 5 months ago

VISUAL structured programming

Our thinking is based primarily on visual perception.

Vadim Glazer

FORMULATION OF THE PROBLEM

Let’s try to play an imaginary “side Spotlight” and look at the problem from a different angle. There is some, and very deep, though not always obvious similarities between the ideas outlined above and the concept of structured programming.Based on this, we introduce the term “visual structured programming” and define it as a set of rules, which coincides with the visual syntax of the language of dragons. In concentrated form, these rules are set forth in Sec. 15.

To distinguish the theoretical aspects of the visual structured programming from minor details, we need the term “skewer method”. However, sometimes the term “skewer method” and “visual structured programming” will be used interchangeably.

Reflecting on the problem, the author has come to the following preliminary conclusions, or rather, assumptions.

  • Despite the presence of a number of common features, text and visual structured programming – essentially different things.
  • Traditional (text) structured programming is apparently the best solution of the corresponding problem for the traditional (text) programming.
  • For visual programming this statement incorrect. You can, of course, stupid rules to transfer text structured programming to visual case. But it would not be a good solution.
  • In order to develop an efficient method for visual structuring options must be, based on the rules of structured programming text, significantly modify them.
  • Structuring principles underlying the visual syntax DRAGON, is the desired solution.

In this chapter, an attempt to justify the alleged conclusions.

HISTORICAL REFERENCE

According to the classical theorem Bohm and Dzhakopini, any real program can be constructed of the functional blocks (actions) and two designs: the cycle and dichotomous choice (a fork). Edsger Dijkstra enriched and strengthened the idea by proposing to abandon the unconditional jump goto statement, and limited to three control structures: sequence, cycle selection.

Donald Knuth Dijkstra criticized the thesis of the complete elimination of goto, showing cases where goto is useful. As a result, there was a fruitful discussion, strictly speaking, is not completed until now, which revealed four possible views (tab. 4).

Position panelists There are three structural design? Substitutes used goto? Used goto?
Option 1 Yes No No
Option 2 Yes No Yes
Option 3 Yes Yes Yes
Option 4 Yes Yes No

Option 1 describes the orthodox position Dijkstra, according to which the goto statement is “disastrous consequences” and therefore “should be excluded from all high-level programming languages.” On this basis developed language withoutgoto: PDL, BLISS and others.

Option 2 reflects the view of the early critics Dijkstra, whose position is expressed in the words: “the use of the goto statement may be appropriate in the best structured programs”; “I have always been examples of programs that do not contain goto and gently placed a ladder in accordance with the level of nested, but it is not clear, and there were other programs that contain goto yet completely understandable.” Therefore it is necessary “to avoid using the goto, wherever possible, but not at the expense of clarity of the program.”

As you know, the debate on goto “stir up a hornet’s nest,” and stirred up “all the programmer’s world.” Options 1 and 2 express the extreme positions of participants, among which, as it seemed at first, compromise is impossible. However, the situation has changed with the invention and widespread substitutes goto, examples of which are in the C language – statements break, continue, return and EXIT buttons function () in Modula-2 – Operators RETURN, EXIT, HALT procedure and so on. D.

Substitutes – a special tool that is significantly different from both the three structural control structures, and from goto.They have two important advantages compared to goto:

  1. without requiring labels substitutes eliminate errors caused by confusion with labels;
  2. Each substitute may not transfer control anywhere (like goto), and in one single point, uniquely identified by a keyword replacer and its place in the text. As a result, the set of points where the transition is allowed is reduced by an order that prevents errors.

Option 3 describes the C language, ADA and others., Where there are alternatives, and in any case is maintained goto.

Option 4 corresponds to the language Modula-2, which also features a substitute, but goto is excluded. It should be emphasized that the presence of substitutes for the scope of the goto sharply narrowed, so that the proportion of errors associated with its use, markedly reduced; therefore the exclusion of goto loses former sharpness.

The idea of ​​structuring has had a great impact on practice. Virtually all high-level imperative languages ​​at the stage of their development, or were later introduced structural design cycle and branches, as well as, most importantly, various substitutes goto.

Obsolescent method?

However, structured programming has created exaggerated hopes, which were replaced by disappointment and accusations of reneging on promises. In fact, in the initial stage of development of the technology was no structural shortage of optimistic forecasts. The structural approach has been called “a revolution in programming.” In 1972, Dijkstra wrote: “We have learned so much that in the next few years could turn into programming activities in many ways different from what is available today – so different that we have to prepare ourselves very well to shock awaits us. .. The seventies will conclude that we will be able to design and implement systems that currently require the exertion of all our faculties, and their costs will be only a small percentage in the man-year of their current value, and, in addition, these systems are virtually free from mistakes. “

As to whether these forecasts? Here he writes N. Brusentsov in 1985 (Vol. E., Five years after Dijkstra designated “target date”): “the expected effect of these actions has not yet been given. Efforts to develop and support programs, and if reduced, then only slightly. Reliability remains the most acute problem. Even fervent advocates of the idea of ​​structuring recognize that the revolution has failed. “ In these circumstances, some authors have hastened to declare structured programming “obsolescent method”.

RIGHTS IS IGOR VELBITSKY?

Reflecting on the causes of failure and trying to improve matters, I. Velbitsky offers radically revise the concept of “the structure of the program.” According to him, “structure – a multi-dimensional concept. Therefore, the mapping of this concept by means of linear texts (the sequence of statements) brings virtually no advantage of the structural approach.Huge associative possibilities of the visual apparatus and the apparatus of human thinking are used almost in vain – for the recognition of structural images of a uniform sequence of characters. “

Developing the idea, Velbitsky opposes the text and visual programming, concludes that “on rails text presentation software” reserves increase productivity in programming have been exhausted, and concludes on the need to change the “base” program, ie. E. To move from the text to the program visual.

Currently, visual programming is booming, the number of his supporters is growing. Nevertheless, it is appropriate to ask to what extent the proposed revision of the concept Velbitskim “program structure” is consistent with pioneering views Dijkstra?

Four principles of structuring flowchart PROPOSED E. Dijkstra

Let’s try one more time to look into the dark alleys of history and carefully re-read the classic work by Dijkstra’s “Notes on Structured Programming”. To the surprise, we find that the basic thesis of the structural control constructs (which called for the designation of the author introduces the term “joint”, “choice”, “repetition”) is presented with a direct appeal to the visual language of flowcharts! Direct analysis of the source clearly confirms deykstrianskaya “structural revolution” began with the fact that Dijkstra, using block diagrams as a tool to analyze the structure of programs offered, along with other important ideas of the four principles of structuring block diagrams, which were later forgotten or We got nothing, in our opinion, is too liberal interpretation. These principles are as follows.

  1. Principle limitation topology flowcharts. Structural program should lead “restrict topology flowcharts compared to various flowcharts that can be obtained if the permit the arrows from any unit to any other unit. Abandoning a wide variety of flowcharts and limit … three types of control statements, we follow thus a certain sequential discipline “.
  2. The principle of the vertical orientation of the inputs and outputs of a block diagram. Due to the six types of flowcharts (if-do, if-then-else, case-of, while-do, repeat-until, as well as the “action”), Dijkstra wrote “The common property of these block diagrams is that each of them on top of one input and one output below”.
  3. The principle of a single vertical. The input and output of each sample flowchart should be based on the same vertical.
  4. The principle of stringing standard flowcharting to a single vertical. When connecting the typical block diagram should be connected, avoiding kinks trunks to exit the top and bottom of the input circuit block lying on the same vertical.

Although Dijkstra does not give verbal formulation of the third and fourth principles, they clearly derive from existing illustrations in his work. To the reader in no doubt, we give exact copies of the original drawings Dijkstra (Fig. 131, the middle and the left graph) 1.

Thus, we can affirm with certainty that the two ideas (text and visual structured programming), like the twins, appeared on God’s light at the same time. However, those expecting twins different fate – the fate of the prince and the pauper.

Why the scientific community did not accept VIDEOSTRUKTURNUYU CONCEPT E. Dijkstra?

Further events are quite mysteriously, as around 1 videostrukturnoy concept Dijkstra formed long conspiracy of silence.

The trouble is that the above recommendations Dijkstra were not taken into account by developers of national and international standards of the flowcharts (GOST 19.701-90 standard ISO 5807-85, and so on. D.). As a result, the method of standardization, the only method that could improve the widespread drawing flowcharts, was not used, and the idea of ​​Dijkstra was tightly insulated from the actual block diagrams used in the actual practice of programming. What is the reason that more than strange situation?

It is appropriate to make a retreat. American historian and philosopher Thomas Kuhn in his book “The Structure of Scientific Revolutions” says that the history of science from time to time there are special times when nominated “incommensurable” with the same views scientific ideas. Recently he followed R. Bergman, called paradigms. The history of science – history of a paradigm shift. Different paradigms – are different patterns of thinking scientists. Therefore supporters of the old paradigm is often difficult or even impossible to understand the supporters of the new paradigm (the new system of ideas), which replaces the well-established stereotypes of scientific thinking. In our view, the text and the visual programming – two paradigms, the current stage of the development program have the painful process of breaking the previous views, during which the old paradigm of the text is gradually giving way to a new visual paradigm. At the same time – according to the theory of Kuhn – many, though not all prominent members of the old, obsolescent paradigms exhibit peculiar blindness in the perception of a new paradigm, which is in the relentless struggle of ideas ultimately asserts his dominance.

This little excursion into the history and methodology of science to better understand the reasons for striking neglect of the scientific community to the principles set out Dijkstra structuring block diagrams. Let’s start from the beginning. Formal block diagram – this is a two-dimensional drawing, therefore, it is a visual programming tool. It follows that the proposed Dijkstra structuring principles flowcharts is nothing, as historically the first attempt to formulate the basic (though far from complete, and perhaps in need of improvement) principles videostrukturnogo programming.

However, in 1972, at the time of publication of Dijkstra, visual programming of the term, the concept and the concept actually did not exist. So – quite naturally – the essence of the concept of Dykstra was perceived through the prism of the then dominant dogmas text programming with all its consequences. Thus was born attributed to Dijkstra and rightful concept of text structured programming. At the same time (which is also quite naturally) at the appointed time, nobody paid attention to the extremely important fact for our study that the original formulation of the concept of Dykstra was pronounced visual component – it is a method of structuring flowcharts, t. E. Has been described videostrukturnogo in terms of programming.

This neglect has led to what the authors of the standards to the flowcharts felt that this idea does not concern them because the text refers only to the programs and amicably ignored or, say gently, lost sight of the visual component of the structural method Dijkstra.

In fairness add that the father-founder (E. Dijkstra) is usually very persistent in promoting and popularizing his ideas, his attitude to videostrukturnomu offspring with surprising indifference and never made a proposal to consolidate the structural ideas in the standards for the block scheme.

PARADOX structured programming

We have come to the most intriguing point in the history of structured programming. To identify the main link problems, ask the question: are flowcharts and structured programming are mutually exclusive, incompatible solutions? The literature on this subject, there is rare unanimity, yes, they are incompatible. Here are a few comments. Flowcharts “does not agree with the structured programming as largely focused on the use goto”. These “obscure features of programs created by the rules of structured programming”. “C advent of language, consistent with the principles of structured programming, … flowcharts began to die off.”

The paradox is that the above statements are based on a misunderstanding. To the logical defect became apparent, two comparable quotes for the method of “confrontation” (tab. 5). Comparing the opinion of contemporary authors Dijkstra’s position, we can easily see that the critics described the flaw is indeed the case, but only if the rules of drawing flowcharts Dijkstra proposed ignore the principle of limiting topology flowcharts. Conversely, compliance with this principle immediately eliminate defect.

According to critics, convinced of the impossibility of structuring flowcharts Offer E. Dijkstra about structuring flowcharts
“The main drawback of flowcharts is that they are not accustomed to the accuracy when designing the algorithm: diamond can be placed anywhere in the block diagram, and from it lead to any desired outputs portions. So you can quickly turn the program into an intricate maze to figure out where after a while he could not even its author ‘ Structuring flowcharts inevitably leads to “restrict topology flowcharts compared to various flowcharts that can be obtained if the permit the arrows from any unit to any other unit. Abandoning a wide variety of flowcharts and limit … three operators control, thus we follow certain sequential discipline “

Bad block diagram or a bad standard?

The analysis allows to make several important observations.

  • The allegations put forward by opponents of the flowcharts, illegitimate because it put the issue on its head. It is not that the block diagrams are inherently inconsistent structuring principles, and that the development of standards to the flowcharts of these principles have been incorporated. They just do not pay attention, because at that time – just because of the paradigmatic “Blindness” – is that, in practice structured programming should be applied to the text of the program, and not to the block diagram.
  • To make a flowchart useful for structuring, necessary to limit and regulate their topology based on the principles of videostrukturnyh Dijkstra.
  • Videostrukturnaya concept Dijkstra – a fundamental idea, expressed more than twenty years ago, and were unused because it is much ahead of its time.
  • Today ripe favorable conditions for its development. This is facilitated by two circumstances. Firstly, the rapid development of computer graphics and visual programming. Second, the widespread use of CASE-technologies, which use is common to all project participants a set of visual (graphic) language.
  • Dijkstra proposed structuring principles flowcharts correctly identify the general direction of development, but they need improvement, development and detail with the latest achievements of modern science and experience (including negative) gained in the practical implementation of the text of structured programming. In particular, the current flow diagrams must satisfy not only the criterion of structuring and formalizing the criteria and ergonomizatsii.
  • It solves this problem skewer method that on the one hand, the concept of developing videostrukturnuyu Dijkstra, and on the other – take into account the realities of today. Use the skewer method developed a new topology block diagrams (dragon-circuit), the regulation is carried out on the basis of cognitive knowledge formalization.
  • Modern standards of the flowcharts (the international standard ISO 5807-85, domestic GOST 19.701-90, and other national standards, including the American Standard ANSI), as well as instructions for their use should be recognized as obsolete, since they ignore the principles of structuring, formalization and ergonomizatsii and objectively contribute to reducing the quality of the relevant intellectual products.

Flowcharts and theoretical programming

Our interest in the structuring and formalization of flowcharts has another, equally serious reasons. The fact that the theoretical programming, in particular, the theory of program schemes (schematology) and the theory of optimizing transformations programs is closely related to the theory of graphs. According to A. Yershov, “the graphs are the main design for the programmer”, because they “have a huge, inexhaustible pictorial force commensurate scale programming tasks.”

For our purposes, especially important it is the fact that the “Graph form of program schemes”, or what is the same, “Graph scheme” (shorter graph diagram) is similar to the block diagram. Moreover, as clearly shown by Ershov, use a block diagram as graph-schemes, the distinction between these concepts is in a sense arbitrary. The difference in weight (topology) flowcharts and graph-schemes are insignificant, and there are two more terms is justified by the different fields of application, since the term “block diagram” is used primarily in the practical and “flow-chart” – a theoretical programming.

NEW TARGETS Standardization block diagram

The above statement of the problem needs to be generalized and clarified, and that we will do in the form of six theses.

  • There are three areas of application of block diagrams:
    1. practical programming;
    2. theoretical programming;
    3. training and scientific and technical literature 1 .

    In all three areas use different topology flowcharts, no unification. Existing standards flowcharts refer only to the first area and not the other two. But the main drawback is that in all cases dominated by informal block diagrams.

  • Further use of informal flowcharts in all cases be considered unwise. With the advent of the language SDL and its modifications, the era of formal flowcharts. However, the graphical syntax known attempts formalization flowcharts is not consistent with the principles videostrukturnymi Dijkstra and developed on their basis skewer method and therefore needs to be improved.
  • It is desirable to develop a common standard for regulating the visual (but not text) syntax of formal block schemes to be applied in all three areas of use of block diagrams, thereby unifying flow charts, graph-schemes and organigrams as a useful in cognitive terms of socio-cultural phenomenon , is a versatile tool for the visual presentation of mandatory and technological knowledge of any nature, to solve the problem avtoformalizatsii knowledge, describing the structure of activity and so on. d.
  • The theoretical justification of the alleged standard shall mean two things. Firstly, the basis for the formalization of the concept of block diagrams should be put mathematics (graph-theoretic, algebraic and logical) view of the problem of flowcharts. Secondly, it should be noted that in terms of engineering psychology flowchart belong to the class of abstract information display systems that “provide support for the implementation of touch man of logical or mathematical operations.” Therefore, the syntax of formal block schemes should be designed taking into account the recommendations of cognitive ergonomics. Since the formal flowcharts are designed not only for automatic processing in the computer, but also for the visual perception of a person to the extent of their syntax should take into account the characteristics of the visual analyzer, to consider the organization of the human visual system (the principle ergonomizatsii).
  • In an era of mass computerization flowcharts be created by automated method using a special graphics editor, algorithms which will be “hidden” above the standard, and which will thus become the de facto guarantor of the enforcement of the standard for all users. Manual drawing of flowcharts can be used only as an exception (for sketches, drafts and sketches).
  • Terms visual structured programming (or what is the same, a visual syntax DRAGON) satisfy the above requirements and, therefore, may be the basis for the project referred to the standard, and the guarantor of its implementation and a common understanding can be visual DRAGON editor.

What distinguishes FLOWCHARTS the dragon diagram?

We turn now to the analysis of specific examples that will reveal in graphic form difference flowcharts and diagrams dragon.

From the point of view of language rules DRAGON, first a block diagram in Fig. 132 (adapted from) has the following disadvantages.

  • A disproportionate number of breaks lines (in the flow chart 16 breaks in the Dragon scheme, only 5).
  • A large number of “parasitic” elements: 18 points and 4 circle which dragon scheme are not available.
  • To designate a fork used diamond, which occupies too much space and does not allow to put in the required number of readable text, consisting of rows of equal length.
  • Functionally homogeneous icon F1 – F5 in the block diagram are spread over the entire area of ​​the drawing, taking four different horizontal levels; dragon in the scheme, they are at the same level, which serves as a visual clue to the reader about their functional homogeneity.
  • Diamonds have an exit to the left, that dragon scheme is not allowed.
  • Icon F1 and its hierarchy to the left of the rotisserie (in dragon scheme is not permitted).
  • The following icons F4, F5 has four levels of horizontal lines, which are “parasitic” nature; in dragon pattern four levels are summarized in a single line.

The second flowchart shown in Fig. 132 has the following drawbacks.

  • To the left of the icon there is the intersection of the A2 (in dragon pattern crossing forbidden).
  • Near Icon E3 there is a line at an angle of 45? (In dragon pattern diagonal lines are not allowed).
  • Icons A2, A3 and E3 have more than one input (in dragon scheme is not permitted).
  • Icons A1, A2, A3, E3 have inputs on the side (in the dragon-circuit input permitted only from the top).
  • No skewer as the output icons “header” and the input icon “end” does not lie on the same vertical.

The previous two examples of “bad” flowcharts were randomly taken from the technical literature. The next (third) example (see. Fig. 132) is copied from the source where it is described as “a block diagram of a standard ANSI” (American National Standards Institute). Flowchart made according to American Standard, also has numerous defects:

  • Below the icon there is a gap G skewers (violated the rule that one way of going from input to output, must pass along the main vertical).
  • Icon G has two inputs (in dragon scheme is allowed only one entry).
  • Icon G has an input side (in dragon scheme is not permitted).
  • The icon G output is on the left (in the Dragon scheme it should be from the bottom).
  • Two feedback loops are normal cycle the left of the skewers and twisted clockwise (in dragon pattern they are located to the right of the rotisserie and twisted counterclockwise).
  • Used uncomfortable diamonds (in dragon pattern ergonomic icons are replaced by “issue”).
  • Rhombus L has an exit on the left (in the Dragon scheme it should be right).
  • Used 12 arrows, of which 10 – parasitic (in dragon pattern just 2 arrows).
  • Attaching one excess fracture line (in the block diagram 9 breaks in a dragon-only scheme 8).

Thus, the US is a block diagram as the previous examples, in all respects loses dragon pattern.

What are the similarities of visual and text structured programming?

You can offer nine rules establishing correspondence between the concepts skewer method and classical structural coding.

  1. The term “functional atom” (Fig. 122) is equivalent to a “functional unit”, “function” and “processing unit” used in the literature on structural programming.
  2. Makroikona “fork” (Fig. 122), which produced the input function of the atom to the left or the two critical points, equivalent structures, if-then and if-then-else , respectively – see. as the top two graphs in Fig. 131.
  3. Makroikona “normal cycle” (Fig. 122), which produced the input function of the atom in one or both of the critical points, equivalent constructions do-until, while-do, do-while-do , respectively – see. bottom two graphs in Fig. 131.
  4. A non-empty makroikona “switch” (Fig. 122), which enter the number of icons “option” using the “add options”, equivalent to the construction Case – see. fig. 131.
  5. A non-empty makroikona “cycle for” (Fig. 122) is equivalent to the cycle for the C language.
  6. A non-empty makroikona “switching cycle” (Fig. 122), which enter the number of icons “option” is equivalent to a loop nested sase used, for example, in the construction of structured programs recursive method Ashcroft-Manna.
  7. Skewer block – videostrukturny equivalent of the concept of “a simple program.”
  8. Atom – a general term for the main components of the blocks needed to build the program according to the structure theorem Bohm and Dzhakopini. It also includes all the basic structure of the structural coding sequence except for (last in the skewer method is considered a non-elementary structure).
  9. Operation “entering atom” allows you to simulate two operations: first, to construct a sequence of two or more atoms, and secondly, by filling critical points implement multiple attachment of composite operators in each other, so that only one functional unit “is gradually revealed in the complex structure main elements “.

We use the term “basic operations” to describe operations “entering the atom,” “add option” and “lateral connection.”Applying the workpiece primitive basic operations any number of times, we always get a block diagram of a dragon in the traditional sense.

What is the difference of visual and text structured programming?

Structural, liannye and address blocks

Skewer method allows to build both structural and metastrukturnye (liannye) program. We have found that the basic operations of classical structural model coding. To simulate the useful functions of the operator GOTO , to skewer method includes operations “transplant vines” and “ground vines.”

We introduce three concepts.

  • The structural unit – a skewer block, built only by using basic operations without action vine.
  • Lianny block – skewer-unit derived from the structural block using the “grafting vines.”
  • Address unit – the result of converting the structural block using the “ground creepers” and possibly “transplant vines.” The address block is used only in silhouette and a multicast branch (or the bottom). It has one input and at least two outputs connected to the lower horizontal silhouette lines through the icon “e”.

The primitive may be used only structural and liannye blocks (Fig. 133, 134), in silhouette – all three types of units: structural, liannye and address (Fig. 135, 136) 1 .

Operations with the vines and the goto

Operations with creeper model without exception function substitutes GOTO (for example, an additional output of the cycle), as well as some features GOTO , which can not be realized with the help of substitutes. However, they do not lead to chaos caused by the uncontrolled use of GOTO . From an ergonomic point of view, the actions of a vine in the order of more efficient and more convenient than goto and substitutes; On the other hand, they are very effective corrective disadvantages of classical structured programming.

To see this as an example, let us return to the analysis of Fig. 27. In Sec. 7 we considered the ergonomic advantages of the circuit in Fig. 27 b compared with Fig. 27 as well . It has been shown that improved ergonomics achieved by using equivalent transformation algorithms: Association of vertical and horizontal. In this behind the scenes remains an important problem – the syntax of how to build these schemes? Now we have the opportunity to highlight this issue. The diagram in Fig. 27 and it is a structural unit derived using the “input atom.” In contrast, the circuit of Fig. 27 b – is lianny block, built by grafting vines.

It is appropriate to recall the admonition G. Myers: “The rules of structured programming often require repeat the same parts of the program in different parts of the module in order to get rid of the use of statements GOTO . In this case, the medicine worse than the disease; duplication dramatically increases the likelihood of introducing errors when changing the unit in the future. “ As can be seen from Fig. 26 and 27, allows the vines transplant elegantly and without loss to solve this difficult problem, while improving visibility and comprehensibility of the program, providing a more efficient topological ordering routes.

Transplant vines legitimizes only a few, not any transfer of control, since the definition of the operation (see. Ch. 15, thesis 28) contains a number of restrictions. The ban on the formation of a new cycle due to the fact that the transition to an operator located above (before) in the program, is considered a “worst-case application of the operator GOTO “. This ban is introduced, to comply with requirement to use goto only for transfer of control down the program, “which was adopted by some organizations as a compromise version of the structured programming”.

It is appropriate to recall the admonition G. Myers: “The rules of structured programming often require repeat the same parts of the program in different parts of the module in order to get rid of the use of statements GOTO . In this case, the medicine worse than the disease; duplication dramatically increases the likelihood of introducing errors when changing the unit in the future. “ As can be seen from Fig. 26 and 27, allows the vines transplant elegantly and without loss to solve this difficult problem, while improving visibility and comprehensibility of the program, providing a more efficient topological ordering routes.

Is the text formally structured programming method?

The orthodox method of Dijkstra, completely banning goto and substitutes (see. p. 238, Table. 4, option 1), clearly a strict formal method. Unfortunately, it is useful only as an interesting theoretical idea that, as shown by the worldwide experience in its purest form was unsuitable for mass use.

According to experts, the “rules of structured programming are correct in 95%. But there are unfortunate 5%. ” To improve matters, solve the problem of five percent and to create a method suitable for the general practice had to compromise and give the green light to the use of substitutes and so-called “limited use GOTO “(see. Table. 4 variants 2-4). Due to this problem of mass programming practice it has been resolved. But at what cost? The price of renunciation of strict formalism.

It is easy to show. For example, the C language textbook authors advise caution and rarely used substitutes break andcontinue , “because too often their use impairs the readability of the program increases the likelihood of error and makes it difficult to modify.” Then they write: avoid using GOTO , for it is “extremely poor” tool that should be used “as little as possible or not to apply at all.”

It follows that the decision on the list of cases in which whether or not to use the listed operators available to the programmer, which will operate perhaps the best of intentions, but in accordance with their personal experiences and preferences. Thus, on a strict formalization in this case we can not go.

Therefore, we can make a significant remark. Structural coding used in the broad practice of programming is not a formal method, as to the formal rules of Dijkstra had to add informal rules concerning goto and substitutes.

The skewer method analogue goto and substitutes are formal operations “transplant vines” and “ground creepers”, the use of which is not imposed any informal restrictions.

Thus, we come to an important conclusion. In contrast to the text of structured programming, has only a partial formalization of the rules of visual formalized structured programming is 100%, which is confirmed by the fact that they are implemented algorithms DRAGON editor.

WHY plane did not flap its wings?

Speaking about the future of structured programming, you must realize that the text and visual programming is based on a different system concepts that different dissect reality. Therefore videostrukturnoe programming can not be regarded as the result of a mechanical transfer of established classical concepts of structured programming a new language.

Let us illustrate this. When visually structured programming programmer works only with the drawing program, without referring to its text, just as a programmer working on, say, Pascal, does not refer to the assembler and machine code – for him they simply do not exist! This means that so thoroughly grounded Dijkstra collection of keywords structured coding (if, then, else, Case, of, while, do, repeat, until, begin, end ) in the transition to visual programming becomes unnecessary – for the programmer it simply ceases to exist ! Equally become superfluous and die and other keywords used in a variety of opponents Dijkstra options for enhanced structural coding: GOTO, continue, Break, EXIT , and so on. d.

It should be particularly emphasized: as a visual form of structured programming keyword goto is not used, lose their meaning, and all disputes regarding the legality or illegality, danger or safety of its use, as well as an extensive literature devoted to the discussion of this, once seemed so urgent issue.

I foresee objections: although called keywords really disappear, but they express concepts remain valid for visual programming. For example, two of the video program in Fig. 27 can be constructed using the concepts of if-then-else andGOTO . This objection can not be accepted, because there was a substitution of the subject matter. Using these concepts, you can not build a video program, and the program text, video programs on rice equivalent. 27. As for the videos, they are being “doable graphics”, built from the “Run” icon and “performed” trunks. And – we emphasize once again – in the process of building (which is realized with the help of the Dragon Editor) the user does not use the concept of if-then-else , and GOTO , for this is not necessary.

Do not confuse the problem and the system of concepts upon which the method of its decision. In both cases – and text, visual and structural coding – put one and the same objective: to improve the comprehensibility of programs and provide a more effective intellectual control over the transfer of management. However, the system concept is radically altered: the function that the program performs in the text keywords in the video program, implement a completely different concept of icons, makroikony, trunks, skewer, skewer the main vertical-block vine atom transplant vines, the prohibition of crossing lines etc.

It is obvious that the use of the concepts expressed keyword classical structured programming, not an end in itself, but serves only to “make our program reasonable, understandable and reasonable to manage.” These concepts do not solve this problem in all cases, but only in the framework of the text programming. In the transition to visual programming problem is solved in another way, with a different set of concepts. It is the rejection of the old set of concepts and replace it with a new one and allows a new formulation of the problem and allow for better solutions. So sometimes expressed criticism: “the lack of a skewer method is that it does not satisfy the requirements of structured programming” is logically incorrect. You can not blame the plane because he did not flap its wings.

CONCLUSIONS

– Conclusions

  1. Visual structured programming (skewer method), and the text structured programming incommensurable (Kuhn in the sense of the word), they rely on different systems of concepts that are different dissect reality.
  2. Text structured programming decided to face him historical tasks exhausted its heuristic possibilities and fulfill its mission lost its relevance. Currently, growth point of scientific knowledge is a visual structured programming.
  3. If you use a skewer method set of keywords classical structured programming is unnecessary. This creates conditions that in the future may allow exclude keywords, and thereby eliminate the confusing disparity of keywords and structural designs in different programming languages.
  4. Unlike text structured programming skewer method it is entirely fictitious.
  5. By visual ergonomics structured programming is much greater than its text equivalent.
  6. The widely held view of the incompatibility of the block diagrams and structured programming is a myth, a ridiculous mistake, based on the inattentive reading of the classical works of E. Dijkstra’s “Notes on Structured Programming”.
  7. Continued use of unstructured, informal and neergonomichnyh flowcharts in all cases be considered unwise.
  8. The existing literature on the block diagram, including international and national standards, 99% obsolete.
  9. Modern standards of the flowcharts objectively contribute to reducing the quality of the relevant intellectual products. These standards ignore three important principles: structuring, formalization and ergonomizatsii.
  10. An urgent task is to develop a new system of international and national standards of the flowcharts, free from these shortcomings. The draft of the new standards it is advisable to put forth in this book, a visual rules of structured programming. Dragon scheme inherit all or nearly all the advantages of the block diagrams and eliminate their disadvantages.

Attachments

Leave a comment

Your email address will not be published. Required fields are marked *


− 2 = seven

Leave a Reply