Chapter 16 [1]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 | There are three structural | Substitutes | Used | | panelists | design? | used goto? | 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, | Offer E. Dijkstra about | | convinced of the impossibility | structuring flowcharts | | of structuring flowcharts | | |--------------------------------+-----------------------------| | "The main drawback of | Structuring flowcharts | | flowcharts is that they are | inevitably leads to | | not accustomed to the accuracy | "restrict topology | | when designing the algorithm: | flowcharts compared to | | diamond can be placed anywhere | various flowcharts that can | | in the block diagram, and from | be obtained if the permit | | it lead to any desired outputs | the arrows from any unit to | | portions. So you can quickly | any other unit. Abandoning | | turn the program into an | a wide variety of | | intricate maze to figure out | flowcharts and limit ... | | where after a while he could | three operators control, | | not even its author ' | 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 References Visible links 1. https://translate.googleusercontent.com/translate_c?act=url&depth=1&hl=en&ie=UTF8&prev=_t&rurl=translate.google.com&sl=auto&tl=en&u=http://drakon.pbworks.com/w/page-revisions/18205503/%25D0%2593%25D0%25BB%25D0%25B0%25D0%25B2%25D0%25B0%252016&usg=ALkJrhiE4lqkexf4PyQ4bmhZCn73_BmDLQ