Dragon language - tutorials. Visual programming in the dragon language

Have you heard anything about the DRAGON programming language? We are not. But our reader claims that DRAGON has already been included in the high school computer science course curriculum.

Have you heard anything about the DRAGON programming language? We are not. But our reader claims that DRAGON has already been included in the high school computer science course curriculum. The author's spelling and punctuation have been preserved. - approx. ed.

In 1976, in the USSR, in the strictest secrecy, the development of the reusable transport spacecraft Buran began as part of the Buran-Energia project. It was a huge project. 86 ministries and departments and 1,286 enterprises of the USSR (about 2.5 million people in total) took part in its creation.

Buran made its first and only space flight on November 15, 1988. The orbital ship was launched from the Baikonur Cosmodrome using the Energia launch vehicle. After flying around the Earth, Buran landed at the specially equipped Yubileiny airfield at Baikonur. The flight took place without a crew, in fully automatic mode. Unlike the American Shuttle, which can only land using manual control. Due to the collapse of the USSR and the difficulties of the transition period, work on the Energia-Buran program was suspended in 1990, and in 1993 the program was finally closed.

Development of programming languages for Buran

During the development of Buran, the problem of developing and testing software was considered one of the most difficult. It was initially assumed that several thousand programmers would be needed to solve the problem. It should be taken into account that our programmers were accustomed to writing programs in assembler, since the memory capacity of the Biser-4 on-board computer at that time was very limited.

In materials of the Institute of Applied Mathematics named after. M.V. Keldysh RAS speaks about the difficulties and achievements of that period as follows:

"In 1983, the developers of the Buran spacecraft turned to the Institute [of Applied Mathematics] with a request to help develop on-board software and software for ground testing of the ship. According to their estimates, several thousand programmers were required for this work. After studying the problem, it was decided to develop problem-oriented languages based on the terms, concepts and form of presentation of control and test algorithms used by the ship's developers. The implementation of these languages made it possible to involve the ship's developers themselves - the authors of the control and test algorithms - in the creation of on-board and test software. The development of languages and corresponding tools was carried out in a small manner. a team of highly qualified programmers from the Institute of Applied Mathematics, in an extremely short time, created a specialized real-time language PROL2 and a system for automating the programming and debugging of SAPO PROL2 based on it... To develop software for ground testing of the ship, a problem-oriented language DIPOL and was created. a programming and debugging automation system based on it"…

Thus, in order to solve the problem of the lack of programmers when creating Buran, at our request, the Institute of Applied Mathematics of the Russian Academy of Sciences created two Russian-language languages:

real-time language PROL2 for the development of on-board integrated programs (author Viktor Kryukov)
problem-oriented language for developing ground test programs DIPOL (author Vladimir Lutsikovich)

In addition, the LAX language for modeling was developed at the Pilyugin Center under the leadership of Konstantin Fedorov. Thus, three new languages appeared: PROL2, DIPOL and LAX.

The DRAGON language was born in a cosmic cradle

Although the languages successfully solved their problems, it became clear that the narrow specialization of languages was hindering the process. This idea was expressed in 1986 by the head of the complex department, Yuri Trunov (later General Designer and General Director of the Pilyugin Center). Trunov summoned Vladimir Paronjanov, head of the laboratory for the integrated development of the Buran computer system, and instructed him to create a universal language that could replace the three mentioned above. However, Paronjanov decided to pose the problem differently. He believed that the new language should not only satisfy the practical needs of space technology, but also solve an extremely wide range of problems that go far beyond the scope of traditional programming.

In this regard, when creating the DRAGON language, humanitarian requirements that were unusual for programmers, mathematicians and “technicians” were put forward.

1. Improve the functioning of the human mind.
2. To propose effective means for describing the structure of human activity.
3. To provide a person with language tools that dramatically simplify the perception of complex procedural problems and communication with colleagues, make the incomprehensible understandable and, due to this, literally force a person to think clearly, deeply and productively. Under these conditions, the likelihood of misconceptions, miscalculations and mistakes inevitably decreases, and productivity increases.
4. Radically facilitate intersectoral and interdisciplinary communication between representatives of different organizations, departments, departments, laboratories, scientific schools and professions.
5. Eliminate or reduce barriers of mutual misunderstanding between workers of various specialties (doctors and physicists, mathematicians and designers, biologists and economists, etc.), as well as programmers and those who are allergic to any programming.
6. Achieve a radical improvement in the quality of software according to the criterion of “understandability of algorithms and programs.”

Development of the DRAGON language and its software

The development of a new language and programming system began in 1986. After 11 years, an automated technology for designing algorithms and programs (CASE technology) called “GRAPHITE-FLOX” was built on the basis of DRAGON.

All work was completed by 1996. Then the DRAGON language and the GRAPHITE-FLOX system went into operation. With their help, algorithms and programs for the pre-acceleration module of spacecraft of the International Sea Launch project were developed. In total, it took three years to develop and test the software and other elements of the control system. By 1999, all work was completed. The system was ready to start.

The first launch of the Sea Launch missile system took place on March 28, 1999. It happened at 5 o'clock. 30 min. Moscow time (March 27, 1999 at 6:30 p.m. Pacific time) from the Odyssey launch platform in the Pacific Ocean near the Kiribati Islands.

This launch was a baptism of fire for the DRAGON language and the technology for creating Graphite-Phlox programs. He convincingly demonstrated their effectiveness and reliability. Since then, 29 rocket launches have been carried out under the Sea Launch program. The last launch took place on September 24, 2008. The DRAKON language is successfully used in many other space programs:

Fregat spacecraft upper stage;
modernized Proton-M launch vehicle;
pre-acceleration module for spacecraft DM-SL-B (project “Start in the Desert”, or “Land Launch”), etc.

Since the results of using the Dragon were consistently high, the management of the Pilyugin Center decided to use Dragon technology in all subsequent projects.

Programming without programmers

DRAGON is a very easy language. So easy that the development of many computer programs for space rockets is in practice carried out not by programmers, but by engineers - according to the principle of “programming without programmers.” The reason for the abandonment of programmers is simple. When solving practical applied problems, engineers have a thorough knowledge of the material and are well aware of the formulation of the problem. In contrast, programmers do not know the “physics of the process” and become “extra people”, without whom in some cases (although not always) it is quite possible to do without.

This allows you to significantly reduce costs, improve the cost-result ratio, and speed up the progress of work. And completely get rid of “broken phone” errors caused by mutual misunderstanding between programmers and engineers.

Secrets of space developments - for the national economy

DRAGON is universal. It can be used for visual representation and rapid development of algorithms not only in “space”, but also in “terrestrial” types of human activity. The practical usefulness of DRAGON was highly appreciated. It can be assumed that the DRAGON language will become widespread in a variety of areas, including in the education system. At one time, Niklaus Wirth, the author of the Pascal language, believed that Pascal should be the very first language with which to start learning programming. This point of view has become almost universally accepted.

At that time, programs were written in text form. For text programming, Pascal was indeed the best learning language.

However, today the situation has changed. The future belongs to ergonomic languages. Under these conditions, grandfather Pascal lost his former glory as an excellent educational tool.

Today this role is transferred to the visual language DRAGON. It is DRAGON that becomes the simplest, easiest, most convenient and logically harmonious language with which to begin studying algorithmization and programming.

Dragon in the education system

In 1996, the State Committee for Higher Education of the Russian Federation included the study of the DRAKON language in the high school computer science course program. This fact is reflected in the document of the State Committee for Higher Education entitled:

Currently, educational books for secondary and higher schools are being prepared. The first of them has already been published - a game teaching aid for children of secondary school age.

Last edited by PBworks 12 years, 3 months ago

HIGHLIGHTS OF THE DRAGON LANGUAGE

CRITICISM OF FLOW DIAGRAMS

An effective tool for improving the understandability of algorithms is visualization of programming, and somewhat earlier flowcharts were used for this purpose. However, flowcharts have recently come under criticism. Opponents of flowcharts argue that they are unsuitable for structured programming, cannot be formalized, and therefore “cannot be used as a program for direct input into a machine.” They take up many pages, and “very limited information can be entered into the cells of the flowcharts.” Flowcharts “impair learning and reduce comprehension performance.” In addition, they are not convenient for everyone - working with flowcharts is preferred only by “individuals with the right leading hemisphere, oriented towards visual information, intuitive, pattern recognition”, but they are avoided by “individuals with the left leading hemisphere, oriented towards verbal information, inclined to deductive reasoning”, etc.

While flowcharts were the most widely used tool before 1980, today they are “no longer considered necessary and are declining in popularity.” Although there are individual attempts to adapt flowcharts to modern needs (SDL language, etc.), in general, flowcharts have clearly found themselves on the sidelines of the rapidly developing process of programming visualization, and their enormous potential capabilities are not actually used. The DRAGON language allows you to eliminate or significantly weaken the noted shortcomings of block diagrams.

To designate flowcharts built according to the rules of the DRAKON language, the term “dragon diagrams” is used.

ADVANTAGES OF DRAGON SCHEMES

How do dragon diagrams differ from flow diagrams? Flowcharts do not automatically translate an algorithm into machine code. Dragon schemes, on the contrary, are suitable for formalized recording, automatic receipt of code and its execution on a computer. However, the second (cognitive) difference is more important. Although flowcharts sometimes do improve the understandability of programs, this does not always happen, and the degree of improvement is small. In addition, there are many cases where poorly executed flowcharts become confusing and difficult to understand. In contrast, dragon-schemes satisfy the criterion of ultra-high comprehensibility.

Thanks to the use of special formal and informal cognitive techniques, dragon diagrams make it possible to depict the solution to any, no matter how complex, technological problem in an extremely clear, visual and intelligible form, which can significantly reduce the intellectual effort of personnel necessary for visual perception, understanding, verification and an error-free solution problems.

ICONS AND MACROICONS

Graph elements (graphic letters) of the DRAGON language are called icons (Fig. 1). Just as letters are combined into words, icons are combined into compound icons - macro icons(Fig. 2).

By connecting icons and macroicons according to certain rules, you can build various algorithms, examples of which are shown in Fig. 3, 4, 6, 8-11.

Skewer block- part of the dragon circuit, having one entrance from above and one exit from below, located on the same vertical. Examples of skewer blocks are icons I3 - I10, I12 - I16, I18, I20, I21 (Fig. 1) and macroicons 2-20 (Fig. 2).

WHY DO YOU NEED A BRANCH?

When Princess Anne divorced the Marquis Le Chatelier, a dispute arose over the division of property. The judge demanded to indicate which purchases the princess made before her marriage and which ones after.

Now let's forget about this family drama and compare the rice with each other. 3a and 3b. It is easy to see that the first does not allow answering the judge's question. As for the second, it, on the contrary, contains the necessary information. Moreover, the algorithm in Fig. 3b is deliberately drawn so that purchases made before and after marriage are clearly divided into two lists. These lists are visually and spatially separated, so the division of the algorithm into two parts, regardless of the will of the reader, is literally striking. This technique is called breaking the algorithm into semantic parts according to the principle “I looked and it immediately became clear!” And the semantic blocks themselves are called branches.

The word “branch” has two meanings. On the one hand, this is a semantic “piece” of the algorithm. For example, the algorithm in Fig. 3b has two branches (“Shopping before marriage” and “Shopping after marriage”). In Fig. 4 - four branches (“Preparing for fishing”, “Waiting for a bite”, “Fishing work”, “Return”). On the other hand, branch is a compound operator of the DRAGON language, which has no analogues in known languages. The “branch” operator consists of three parts: start of the thread(icon “branch name”), branch bodies(which may contain a large number of icons) and end of the branch(which contains one or more “address” icons or an “end” icon).

So why do we need a branch? To help the knowledge worker, programmer and technology developer formalize the semantic division of a problem, program or technical process into parts and give the parts convenient semantic names. At the same time, dividing the problem into N semantic parts are implemented by dividing the algorithm into N branches.

HOW DOES A BRANCH WORK?

A branch has one input and one or more outputs. The input is the “branch name” icon, which contains the branch ID. The visual operator “branch name” does not perform any actions; it is just a label that declares the name of the semantic part of the program. The execution of the dragon algorithm always starts from the leftmost branch (Fig. 3, 4).

The exit from a branch is the “address” icon, in which the name of the next branch in the order of execution is written. The “address” icon is a disguised transition operator (goto), but it does not transfer control anywhere, but only to the beginning of the selected branch. Entry to a branch is possible only through its beginning. The exit from the last branch is carried out through the “end” icon.

HOW SHOULD THE BRANCHES BE PLACED IN THE DRAWING FIELD?

The branches are ordered in two ways: logically and spatially. Logical The sequence of execution of branches is determined by the marks written in the “address” icons. However, logical order is not everything. In Fig. 5 shows three different methods spatial locations of branches that have the same logical order. To eliminate spatial ambiguity and facilitate understanding of the meaning of the dragon diagram, the rule “the further to the right, the later” is introduced. It means: the branch drawn to the right works later than all the branches to the left.

An algorithm drawn according to the rule “the further to the right, the later” is considered good and ergonomic (Fig. 5c). Schemes where this rule is violated are declared bad (Fig. 5a, b), and their use is prohibited.

In the allowed (ergonomic) algorithms, the following operating order takes place (Fig. 3, 4, 5c, 6a):

The leftmost branch works first, the rightmost branch lasts;
the remaining branches pass control to each other from left to right (it may happen that some branches are skipped);
sometimes a so-called “branch cycle” is formed. This happens when the “address” icon contains the name of its own branch or one of the left branches. In Fig. 4 and 6a, the branch cycle is marked with black triangles.

WHAT IS A HAT?

From the reader's point of view, any unfamiliar or forgotten non-trivial algorithm is an extremely difficult problem that he is desperately trying to understand, overcoming the powerful “resistance of the material.” To simplify matters and facilitate the task of understanding, it is necessary for the reader to “see the light” and, having divided the problem into parts, see its semantic structure in terms of the subject area. Moreover, I saw it not in the figurative sense of the word, not with the help of imagination, not with the spiritual eye, but with my own two eyes - on paper or a screen.

But how to do that? The difficulty is that none of the existing languages provides the reader studying a complex program or technology with effective help that allows him to instantly (in a few seconds) understand its structure, i.e., division into semantic blocks. The DRAGON language has special tools that provide a solution to the problem.

The header is the upper part of the dragon diagram (Fig. 4), which includes the title of the algorithm and a set of “branch name” icons. The purpose of the header is to help the reader instantly (in no more than a few seconds) navigate the problem and receive a powerful hint - the answer to the three most important questions:

what is the name of the problem?
How many parts does it consist of?
what is the name of each part?

After all, it is with these questions that our acquaintance with any task begins with a rational approach to the matter.

Here are the answers for fig. 4.

What is the name of the problem? Fishing.
How many parts does the problem have? Out of four.
What is the name of each part? 1. Preparing for fishing. 2. Waiting for a bite. 3. Fishing work. 4. The way back.

Additional conveniences are associated with the fact that the header occupies a “ceremonial” place in the field of the drawing, and the names of the semantic parts are placed inside special frames of a unique shape and, thanks to this, instantly attract the reader’s attention without any effort on his part.

Thus, DRAGON provides the reader with an effective three-step method for understanding an unfamiliar or forgotten problem. At the first stage, analyzing the header, the reader learns the purpose of the algorithm and its division into semantic parts (branches). On the second, an in-depth analysis of each branch is carried out. At the third stage, the interaction of branches is analyzed.

WHAT IS BETTER: PRIMITIVE OR SILHOUETTE?

Dragon diagram with branches is called silhouette, without branches - primitive. The silhouette shown in Fig. 6a can be depicted as a primitive (Fig. 6b). The primitive is a serial connection of the “heading” icon of the skewer blocks and the “end” icon. In a primitive, the “heading” and “end” icons must lie on the same vertical, which is called skewer. The main verticals of the skewer blocks lie on the same line. Figuratively speaking, the skewer permeates primitive icons (perhaps not all of them) just as a real skewer permeates pieces of kebab.

The primitive is recommended to be used if the dragon diagram is very simple (primitive) and contains no more than 5...15 icons. Otherwise, to improve the readability of the program, it is more advantageous to use a silhouette. Violating this rule is usually fraught with trouble, because it prevents the reader from identifying the essence of the problem being solved and, consequently, makes it difficult and slow to understand the meaning of the program.

For example, the algorithm in Fig. 6b looks cumbersome and unreasonably difficult to understand. This is due to the fact that it contains 19 icons, but is depicted in a primitive form. The crime is that the diagram in Fig. 6b does not allow the reader to instantly (within a few seconds) recognize the visual and semantic structure of the algorithm. In fact, how many parts does the problem being solved consist of? Looking at Fig. 6b, it is quite difficult to answer this question, and it is impossible to answer quickly. The situation changes radically when we look at Fig. 6a, where the same algorithm is depicted in silhouette. Here, as they say, it’s a no-brainer: the algorithm consists of four parts: “search for a bus”, “waiting to board”, “boarding a bus”, “trip”. However, this is not all: no less important is the fact that the intricacy of the visual pattern has disappeared and the diagram has acquired a new aesthetic (ergonomic) quality: elegance, clarity and transparency.

Thus, in complex cases, the silhouette can significantly reduce the intellectual effort spent on understanding the algorithm. In silhouette, large structural parts of the program (branches) are clearly highlighted, they are spatially spaced in the field of the drawing, at the same time forming an easily recognizable, stable, predictable and holistic visual image. And in a primitive, the structural parts are not selected and mixed (“everything is in one heap”), which makes it difficult to read and analyze complex algorithms. However, for simple cases (less than 5...15 icons), the primitive, as a rule, turns out to be more preferable.

HOW TO DESCRIBE A SILHOUETTE USING TEXT LANGUAGE?

From Fig. 7 it can be seen that in order to describe the branches, a number of changes had to be made to the text language. In particular, two new text operators have appeared that are not found in traditional languages:

BRANCH< идентификатор ветки >

ADDRESS< идентификатор ветки >

The text language operator BRANCH declares the name of the branch (written in visual language inside the “branch name” icon). The ADDRESS operator unconditionally transfers control to the text operator BRANCH, the name of which is written to the right of the ADDRESS operator.

Let's consider the problem. In a tangled labyrinth connecting the beginning and end of a complex algorithm, you need to single out one single route - a “guiding thread” with which you can visually compare all other routes in order to easily navigate the problem and not get lost in the tangle of forks. This guiding thread (let's call it the “main route”) should be visually easily distinguishable. In other words, having taken a quick glance at the dragon diagram, we should find clear landmarks, thanks to which we can immediately and unmistakably see the “royal” route and the other routes ordered in relation to it.

To do this, a rule is introduced: “the main route of the primitive must follow the skewer.” By swapping the words “yes” and “no” in the forks and the options in the switches (as well as the garlands of icons attached to them), you should ensure that the output of the fork or switch that leads to the greatest success is on the royal path (Fig. 8) . And side routes should be arranged according to the following rule: “The further to the right, the worse”(Fig. 9). If these rules are violated, the dragon circuit is considered bad (Fig. 10a). However, it can always be turned into a good one (Fig. 10b).

In cases where the “better-worse” criterion does not work, some other reasonable criterion should be chosen instead, so that the shift to the right of the main route is always not arbitrary and chaotic, but thoughtful and orderly. For example, when solving mathematical problems, fork outputs and switch options can be arranged from left to right in order of increasing or decreasing the mathematical value (characteristic) corresponding to these outputs (Fig. 11, 12).

MAIN ROUTE OF THE SILHOUETTE

In the previous paragraph, we learned how to order primitive routes. Now it's the silhouette's turn.

Skewered branches is called a vertical connecting the “branch name” icon with the “address” icon, and if the branch has several outputs - with the left one. For the branch, both “royal” rules remain in force:

the main route of the branch should follow the skewer;
side routes of a branch should be ordered from left to right according to some criterion.

Let’s assume that the principle “the further to the right, the worse” is chosen as the criterion. In this case, each branch of the silhouette should be built according to a single rule: the further to the right (the farther from the skewer of a given branch) the next vertical is located, the less successful actions it performs.

For example, in Fig. 6a the “boarding the bus” line has three verticals. The left vertical (main route) describes the greatest success, since you will be sitting on the bus. The right vertical means the least success, since you got off the bus and the trip is postponed. The middle vertical (located above the “Do you want to ride standing?” icon) occupies an intermediate position, because - depending on the answer - there can be either partial success (you will ride, but not sitting, but standing), or failure, since you get off the bus with a light slurp.

Main silhouette route- sequential connection of the main routes of alternately operating branches. Thus, DRAGON allows the reader to instantly see the main route of any algorithm, no matter how complex and branched, and, moreover, makes the displacement of all side routes relative to the “royal” one not random, but meaningful and predictable, i.e. easy to understand.

LINE CROSSINGS? - GOD FORbid!

Some experts, prone to harsh expressions, call traditional flowcharts of algorithms “garbage flowcharts” because the intricacies of blocks depicted on them, connected by a chaos of ragged lines walking everywhere, look more like a heap of garbage than a regular structure. DRAGON is distinguished by the fact that its graphic pattern has a strict mathematical and cognitive-ergonomic justification and is subject to strict and carefully thought out rules. Among them, a special place is occupied by the rule: “Intersections and breaks of connecting lines are prohibited.”

When drawing conventional block diagrams, two types of intersection of lines are allowed: explicit, depicted by a cross of lines, and disguised, performed using so-called connectors. As you know, a connector “is used to break a line and continue it in another place ... to avoid unnecessary intersections.”

In the DRAGON language, all the listed tricks (intersections, breaks, connectors) are considered harmful for ergonomic reasons and are strictly prohibited, since they litter the drawing field with unnecessary details, create visual interference for the eyes and distract attention from the main thing.

Since intersection prohibition is a serious topological constraint, the question arises: can an arbitrary algorithm be represented as a dragon diagram?

Theorem 1. Any structural program can be depicted in the DRAGON language in two ways: in the form of a primitive and in the form of a silhouette.

Theorem 2. An arbitrary (non-structural) program in some cases cannot be depicted in the form of a primitive; however, with the help of equivalent transformations that allow the introduction of additional variables (branch identifiers), it can always be depicted as a silhouette.

To clarify the issue, let's look at examples. In Fig. 13a shows a forbidden dragon circuit: a primitive in which there is an irremovable (without introducing additional variables) intersection. In Fig. 13b shows a silhouette, which, as you can easily see, is equivalent to the primitive in Fig. 13a and at the same time does not contain a single intersection. Thus, the example in Fig. 13 confirms the validity of Theorem 2 1.

VISUAL AND TEXT SYNTAX OF DRAGON

DRAGON is a visual language that uses two types of elements: graphic shapes ( graphic elements) and text labels located inside or outside graphic shapes ( text elements). Consequently, the DRAGON syntax breaks down into two parts. The visual syntax covers the alphabet of graphic elements, the rules for their placement in the drawing field, and the rules for connecting graphic elements using connecting lines. Text syntax specifies the alphabet of symbols, rules for their combination and binding to graphic elements (binding is necessary because different types of expressions are used inside different graphic figures). DRAGON language operator is a graph element or a combination of graph elements taken together with text inscriptions.

The simultaneous use of graphics and text suggests that DRAGON addresses not only the verbal and logical thinking of the author and reader of the program, but in addition activates intuitive, imaginative, right-hemisphere thinking, stimulating it with a not written, but drawn program, i.e. a program -a picture.

DRAGON LANGUAGE FAMILY

DRAGON is not one language, but a whole family, all languages of which have the same visual syntax (which visually makes the languages of the family almost twins) and differ in text syntax.

DRAGON-1- visual pseudo-language, a visual analogue of ordinary text pseudo-code. It serves to describe the structure of activities, the creation of technologies, algorithms and program designs, and is used in the method of step-by-step detailing, as well as in the formalization of professional knowledge.

DRAGON-2- real-time visual programming language. He is an element CASE- technologies for the development of software for control systems of rockets and space objects, as well as nuclear power plants, petrochemical and metallurgical plants, biotechnological production, etc.

In addition, the family includes hybrid visual programming languages: DRAGON-BASIC, DRAGON-PASCAL, DRAGON-S, etc. To get a hybrid language, for example, DRAGON-S, you need to take the visual syntax of DRAGON and join it according to certain rules of SI text syntax.

A strict distinction between visual and textual syntax makes it possible to expand the scope of the language to the maximum extent, ensuring its flexibility and versatility. At the same time, the uniformity of the rules of visual syntax of the DRAGON family of languages ensures their conceptual unity, and the variety of text rules (i.e., the ability to choose any text syntax) determines the flexibility of the language and easy adjustment to various problem and subject areas.

This book focuses on the visual pseudo-language DRAGON-1. As for the other languages of the DRAKON family, only brief explanations are given.

CONCLUSIONS

Here is a summary of ergonomic rules that can improve the cognitive quality of dragon circuits and make algorithms, programs and technologies more understandable.

A complex algorithm should be drawn as a silhouette, a simple one - as a primitive.
It is prohibited to write the word “beginning” in the “heading” icon; instead, you should provide a clear and precise name for the algorithm.
Break a complex algorithm into parts, representing each part as a branch. Give the parts intelligible and clear names and write them down in the “branch name” icons.
Entry to a branch is possible only through its beginning.
In the “address” icon it is allowed to write the name of one of the branches; other inscriptions are prohibited.
Branches should be placed in space according to the rule: the further to the right, the later. The presence of a branch cycle modifies this rule.
The primitive must have a skewer. This means that for a primitive, the “heading” and “end” icons always lie on the same vertical, which is called the “skewer”.
Each branch must have a skewer. On the right branch, the skewer is a vertical connecting the “branch name” and “end” icons. For other branches, the skewer is a vertical line connecting the “branch name” and “address” icons, and if there are several addresses, with the left one.
The algorithm always has a main route, which must follow the skewer.
Side routes must be ordered from left to right according to one of the selected criteria, for example: the further to the right the worse.
In the “end” icon the word “end” should be written.
Connecting lines can go either horizontally or vertically. Slanted lines are not allowed.
Crossing lines is prohibited.
Line breaks are prohibited.
The use of connectors is prohibited.

The DRAGON language is used for:

descriptions of the company’s business processes and their audit,
development of solutions based on 1C for their automation,
storing the code of these solutions,
organizing training for employees to work within business processes,
recording and storing user instructions - how to work within the business process.

Its main highlight is that as a result we get a complete business model, which is not limited only to the diagram and instructions for the user. Within this business model, we, together with the development logic we can also store its code- this gives us the opportunity:

audit it,
remember for yourself what you did,
transfer to another programming team,
train and support the Customer's personnel.

Why is the DRAGON language better for describing a business process than other notations?

He understandable- easily perceived visually in practice.
He simple- there are only three types of diagrams and about five actually used icons that allow you to describe all this logic without creating further diagrams.
Well, plus everything - other notations do not have the means that can store development code.

And today we will talk about the technology of using the DRAKON language during the implementation and subsequent operation of 1C products using a specific example.

Theoretical basis for building a business model

In preparation for the presentation, I contacted people who are professionally involved in the development of business models, in particular, Mikhail Anatolyevich Kuznetsov. He conducts project development in ARIS (this is a notation that is mainly used when implementing an SAP system).

According to his findings, business model consists of the following components:

Semantic level, which shows the goals and objectives of the company.
These goals come down in the form of control documents that characterize the processes (this block is designated here as " Process model»).
These processes involve business objects(in other words, resources);
And all this comes together in reports (quarterly or for some other period), according to which top management understands whether they have achieved some of their goals or not (here this block is designated as “ Control Panel»)

This representation of the business model is used mainly for the implementation of KPI systems, but can also be used for other purposes - in quality management systems, etc.

An example of using the Dragon IS to select a solution for automating a customer’s business processes

Let's move from theory to practice. For example, I took detailed design for automation of a furniture factory in our city. There are two parties involved in the project - the Customer and the Contractor. The Customer is the owner of the furniture factory, and the Contractor is me. The Customer and I met and discussed his tasks. As a result, I created a “Dragon Blueprint” of his business model.

Let's see what happened.

On the left is the so-called scheme "Gnome"(this type of circuit is mainly used for notes), which describes catalog of company goals:

The very first element on it is the diagram title.
Next, the company’s mission on the market is highlighted in yellow.
And even lower is an element of the “Insert” type, which is used to navigate through these diagrams.

The diagrams themselves are interactive: for example, on an element of the “Insert” type, you can click the left arrow and you will immediately be taken to the desired diagram. This is what happens decomposition. This allows complex logic to be broken down into simpler blocks.

From the catalog of goals we move on to a diagram of the “Silhouette” type, which contains company goals(circuit type "Silhouette" applies for algorithms, consisting of several semantic parts). Each heading (they are highlighted in a red oval) denotes a chain of user-friendly actions that are deciphered in this thread.

For each Customer Goal, a Concept is developed- an enlarged business process that allows you to achieve this Goals the way management sees it. In the first branch of this scheme we will work with Purpose which is trying to strengthen Vertical integration: according to the "Insert" scheme we go to the scheme Concepts vertical integration - our enlarged plan to achieve this Goals.

On the diagram Vertical Integration Concepts shown in the form of a “Cycle FOR” construction Sales life cycle(the beginning of the cycle is icon No. 5 and the end is icon No. 7).

Please note that there are unshaded areas in this diagram - elements of type "Output"(they are located between the actions shaded in green) - this is governing documents, which go down (for example, for the sales department this could be a sales plan for the year, etc.).
Respectively, the subsequent process is guided by this control document etc.
Indicated here in yellow the most important stage of the sales cycle- this is the so-called “driver”, the main task that drives all other tasks. Through this “insert” we can go to a separate diagram detailing this driver task furniture production life cycle.

So, here is a diagram of the furniture production life cycle:

First, you come to a furniture showroom and order a kitchen.
There they cheat you out of it,
Then they make
They bring it to you
You're paying the price
You sign the act of accepted work (whether you agree or not), and that’s it.

Having described the main business process that the customer wants to automate, we can begin to select the appropriate configuration - the one that has the maximum functionality that meets our requirements. It is desirable that it does not need to be modified - there may be changes, but they should be minimal.

As you can see, when starting work on a project, the DRAGON language allows you to gain an understanding of the Customer’s business model in order to optimally choose a packaged product for a comprehensive solution to its problems, although you haven’t sold or assembled furniture before.

Let's summarize the first stages of our example project:

We discuss the business process directly with the Customer (not a programmer, not an implementer) - he knows better how his furniture is sold and assembled. And we get information about what his business is like.
And then, having composed based on his information detailed diagram, already it's easy to analyze what we can automate, and what not.
And on this basis we are together choose a boxed solution for the project.

Accordingly, the DRAKON language is needed at the start of any project for the implementation of 1C company software products.

An example of using the Dragon IS to support and update software products based on 1C

What are the advantages of using the DRAGON language? at the stage of owning an information system based on 1C, at her updating and improvement?

If we have a business model, we can change it and develop it further.
Dependence on staff is reduced. Because if a person suddenly leaves us and does not have time to transfer the work, we can take the “Dragon Scheme” of his actions and pass it on to a new employee so that he can work with it and learn it. After this, the person is ready to join our orderly ranks and continues to work.
« Dragon diagrams" allow you to describe "real" technical specifications, when the accountants have already discussed what they need and themselves have drawn up the final scheme for the programmer: “we want it to be done like this.”
Plus, because the circuit stores simultaneously both code and development logic, you can easily change teams of programmers and developers - transfer these schemes to them.
And since there is already ready-made code and a list of metadata that were created for this modification, then you spend several times less time on further updates.

Let's take a closer look at the topic of updating the 1C configuration.

Imagine, you installed a standard configuration, made some modifications to it according to the technical specifications, and then there was an update, and some of your modifications were erased. This happens if, for example, a company does not have its own programmer, or he gets sick or quits. You have to pick up the old backup, see what it changed in the metadata, restore these changes, etc. It’s good if there is no data.

To simplify updating my improvements, I usually create a “Dragon Scheme”, for example, like the one shown on the slide. There are special transitions (Insert elements) that interactively take me to development sheets. They are dragon-schemes, where they are described:

metadata, which were created;
development logic- why they were created;
And code which is being executed there.

Accordingly, when I update the configuration, I can already run through this dragon diagram in the test database and check whether all the functionality I added works. Perhaps 1C itself has already implemented some of this, which means I need to give up some of my improvements, and think about some migration mechanisms, do something...

An example of using the Dragon IP in the development process

Let's move on to the third part. Why do you need the DRAGON language in the development process?

I I can see the logic of the code being created and audit it. With the help of “Dragon Schemes” we can understand what works and what doesn’t, see that somewhere we need to remove unnecessary code, etc.
I already mentioned the semantic transfer to another development team - Dependence on programmers is decreasing.

How to make dragon diagrams? Paper, ruler, pencil and eraser?

The diagrams that I showed you were made in the program " IS Dragon" This, in my opinion, is now the most advanced tool for working with this language. Simple and cheap.

There is also "DRAKON Editor" and "Fabula".

How the dragon diagram stores code and how to use it when programming in 1C.

Code translator from the Dragon IS to Configurator 1Uses the GOTO programming method. I will not go into discussions about whether to use it correctly or not. There are plenty of articles on the Internet on this topic. Let's stop at what it is. And this is how it works.

For clarity, I’ll tell you a little about what changes we made to the 1C program for the Customer using the example of placing an order for furniture production.

As you can see, in this “Dragon Scheme” for placing an order, the roles of specific performers are assigned for each action. For example, it is indicated that initially the buyer’s order is entered into the CNF configuration by the accountant, and then, based on this order, the supplier issues a production order.

And here a “bottleneck” arises in the business process; I have highlighted it with a red oval. What's the point? At the customer's two different companies operate in the same database, and materials can come to both of them, and when we assemble the kitchen, we need to these the materials ended up in the warehouse of one company. If we do this manually, then the storekeeper must sit with us, collecting expenses for missing materials from one company to another. That's why we offered the customer to make a “magic button” that automates this process.

The screenshot shows terms of reference for the development of this “magic button”.

What is she doing? Searches for missing goods from the selling company, generates expenditure and receipt documents for the found items. Next comes the “insertion” to move on to the development itself with the code.

Here the whole complex of these schemes:

Each diagram is a procedure or function for the “Order to Supplier” document module. They are the ones who automate this “Magic Button”.

Black dots in the diagram title are indicators that the diagram is a procedure and contains code. At these points, blanks are automatically generated that describe the beginning and end of the procedure (their text is shown in the screenshot below).

Executable code is written in the “black spots” of specific actions, in this case, metadata parameters are set.

This is what it looks like element type "Cycle"(1C language constructs “For each ... Cycle ..."), its boundaries (beginning and end) are indicated in green. Between them is the executable code for this loop.

And this is what it looks like "If" element type. Here you simply write a condition: for “Yes” there is one branch, for “No” there is another one. And the program itself, when generating the code, adds to the module the “If... Then” construction and the labels to which the transition occurs.

For multiple "Ifs" a different type of Dragon-Scheme element is used: "Switch".

In the schema we can also describe changes in metadata. For example, in the screenshot on the left, in the “Gnome” type diagram it is indicated which information registers need to be created for this functionality to work.

And finally the highlighted element is the resulting modifications to the module. In its third “black point” I usually write contact information and the essence of the development.

And the fourth “black dot” is the final code itself. He collected automatically, and then I simply copy it from this window and paste it into the configurator.

As you can see, notes also appear here in the form of comments, indicating which number in the diagram this code is located under.

How to debug such code? Each scheme has a unique number that is not repeated anywhere. For example, the screenshot shows the “If” condition with number 26.

And you can find this code in the comments in the configurator. As you can see, here is "Go" operator, which is an analogue of GOTO in 1C. According to him goes to the label. There is no need to write this manually, everything is generated automatically.

As you can see, at label 41 we go to a message to the user, which returns the error text, and after that the end of the procedure occurs. This is how the development logic is checked.

Working with GOTO (“Go to” - in 1C) is a matter of habit. I like it because it makes it easier to analyze the code in a diagram after some practice.

If you don't want to work with GOTO, just insert the condition text into the actions, and it will generate the code in the procedure the way you wrote it there.

Schema elements can be used simply as containers for storing textual code information.

Of course, I conduct preliminary development not in the Dragon IS environment, but in the configurator. I have a configurator open, where I add, for example, the logic of the request that I need to develop. There is a syntax assistant available, automatic code substitution, in user mode you can launch the query console, test all this, see what I can do, what parameters to substitute. And after I have generated preliminary preparations for each action, I copy this code from the configurator and paste it into the required places in the diagram. This is especially useful if you are working on two screens.

Programming in the Dragon IS is like putting together a puzzle. As a result, you assemble the entire mosaic, which shows the entire development code. Moreover, the module code, which is automatically output, can simply be copied and placed in the configurator. Test, of course, to check that the logic is not broken anywhere.

Conclusion

The DRAKON language is convenient to use for training staff and for communicating with the customer, as well as when developing and supporting configurations on 1C.

As for development, I work on many projects where I periodically have to restore some functionality, finish something, parse some complex other people’s codes, etc. And, as much as I worked, I have never met a code written by a programmer that I could not describe in the DRAGON language.

IP Dragon is a boxed product with support for different languages. I work with 1C, but it also supports C++, the language of microcontrollers, and some other languages. The product itself is sold by the author. His the full version weighs very little and is inexpensive. There is a free demo version, which can be used as a viewing room.

Therefore, if you need to quickly implement 1C, train staff to work in the system and support the further operation of the enterprise without extra costs, then I advise you to use this technology in whole or in part.

This article was written based on the results of a report given at the INFOSTART EVENT 2015 CONNECTION conference on October 15-17, 2015

We invite you to a new conference.

Program developer Tyshov Gennady Nikolaevich
Severodvinsk, worked at OJSC SPO Arktika, www.spoarktika.ru.

The IS Dragon program is intended for:
- practical algorithmization of your activities,
- formulating your tasks,
- formalization of your knowledge.

The program is a tool:
- visual techniques of thinking and communication,
- visual design of activity algorithms and programs,
- visual programming,
- formation of algorithmic activity bases.

The program "IS Dragon" (Integrated Environment Dragon) is an environment for working with Dragon algorithms.
With the help of IS Dragon, an algorithmic culture is being introduced into many types of activities.

Download the "IS Dragon" program

User instructions

The user can save a graphic file of a Dragon sheet or a Dragon diagram. By opening a graphic file in a graphics editor, you can add, for example, graphic attributes of the organization, and you can print a paper copy.

The user can copy the Dragon Sheet or Dragon Scheme image to the system buffer. An image from the system buffer can be inserted into edited text or graphic documents. The image can be copied to the buffer from the screen with elements of the editing process (with the graphic cursor and icon entry points highlighted), this allows you to compile manuals on the use of the Dragon IS and manuals for users of Dragon algorithms.

In addition to a paper copy of the Dragon algorithm, the user can receive a text file with accompanying information from A-, B-, P-texts. This creates the possibility of publishing fully functional Dragon algorithms.

The user can specify file names or an Internet link in the texts of the Dragon algorithms. When you highlight a file name, you can run the file or open a file or link. Opening is carried out using the association of file extensions and applications installed on the computer. If there is no path in the file name, the file is selected by searching for the file in the program folder. In the future, it is planned to search for a file also in the subfolder " DFiles" In the future, it is planned to be able to place file names and links in the " » to execute using a hotkey without highlighting in the text.

The user, using the ability to specify files, creates an information environment external and contextual to the algorithm, including the Internet space.

Instructions for the programmer

The user can have a text file with program code templates in the selected programming language and copy it into the message window. Select a template in the message window and use the system buffer to transfer the template text into the algorithm texts.

The user can set the use of the batch file " Dragon.bat» when assembling program code into program files in a programming language. In this case, a list of program files is generated, transferred to the command file, and the command file is launched for execution. This combines programming with translation and debugging.

The user can set the program code assembly mode with replacing the P-text missing in the icons with a comment with the text “ ……No text" This allows you to block error messages and perform translations early in the algorithm's development.

The user can set the program code generation mode to enable tracing code for the execution of marked icons.

The user can generate the algorithm listing text for the Dragon sheet. The text of the algorithm listing will allow you to programmatically compare versions of the algorithm and find places of changes.

The user can set the property for the Silhouette scheme Machine to perform automatic programming of finite state machines using technology SWITCH. The opportunity was introduced at the suggestion of S.D. Efanova.

It is recommended, in addition to Dragon sheets with algorithms and program codes, to also create Dragon sheets with software operating instructions for users. Instructions are transmitted to users along with the Dragon IS. This is the practice of working at IS Dragon by A.A. Araptanov in the 1C system.

The program has customization tools for various programming languages. The program allows you to assemble Dragon-schemes into source codes of programs in languages that have operators: comment, label, unconditional jump (GOTO), jump by condition; for example, languages of the 1C, Delphi, C families. The icon program code is assembled into a file by the internal Route Translator.

Screensaver of the IS Dragon program

What is dragon leaf?

The dragon leaf is displayed in programming mode.

Text entry points (up to 4 squares) are A, B, S, P-texts.

Points A, B are intended for entering accompanying information, point P is for entering program code, point S is for viewing the collected program code. If there is text, the square turns dark.

Do you know me? Mandatory places for entering text into icons are marked.

Editing a dragon diagram

Icon 3 is selected for editing.
Sign "?" the Address and Branch icons indicate the absence of control transfer. The transfer of control is visually indicated by a dashed line.

Peculiarities

A distinctive feature of the program is the high degree of automation of graphics input.

The second feature is that each icon has several (up to 4) text input levels. One of these levels is displayed on the “body” of the icon, the other may contain a fragment of program code. The remaining levels (A-text, B-text, P-text, S-text) can be used arbitrarily, for example, containing detailed comments, links and supporting information.

To display business processes, icons are supplemented with the names of participants in the business process.

All displayed texts can be multi-line and large.
The maximum number of lines in an icon is set in the program settings; the full text is displayed in a text editor on the tab.

DRT format description

Guidelines for working with IS Dragon

To print, do this: save the graphic file, print it in PAINT. There are printing options with scaling and layout on several A4 sheets, there are settings for printing.

Lessons from the DRAGON

To master the techniques of working with the Dragon IS program, it is useful to watch videos. The process from the first launch of the editor to loading the resulting firmware into the microprocessor is shown.

Additional website of the IS Dragon program

Text options and files of Dragon lesson plans

Drafts by Gennady Tyshov

Accompanying information may contain an indication of legislative, organizational and administrative documents, and contain fragments of documents.

The availability of accompanying information is important for persons working with legally significant algorithms. The presence of accompanying information for the icon substantiates the origin and validity of the legal norm displayed in the icon. It is the presence of accompanying information that determines the relevance of the legally significant Dragon algorithm.

The Dragon IS program is developed on the basis of the visual algorithmic languages Dragon and Gnome created by V.D. Paronjanov and state standard GOST 19.701-90 (ISO 5807–85). The ideas and goals of the Dragon language have been developed for practical and widespread use.

Procedural knowledge, algorithm - describes the order of actions with an object, displayed in Dragon diagrams of the form Primitive And Silhouette.
Declarative knowledge- answers the question: “What is this?”, displayed in the Dragon diagram of the form Dwarf.

Creation and editing of Dragon diagrams is performed in the Dragon IS.

Dragon algorithms on tablets
Some issues of using Dragon algorithms created in the Dragon IS are discussed on the forum in the topic “Dragon IS and Android”.

IS Dragon works in other operating systems
In UNIX-like OS it works with the Wine program.
On MacOS it works with Parallels Desktop.

Actions to icons 19 and 21 are performed by participants in the business process.
The dragon leaf is displayed in programming mode.
Text entry points (up to 4 squares) are A,B,S,P-texts: A,B for entering accompanying information, P for entering program code, S for viewing the collected program code. If there is text, the square is dark.
The sheet can be accompanied by headers and footers: top middle, bottom left, bottom middle, bottom right.
The sign "?" marks the required places for entering text into icons, places for entering icons in an icon block to ensure the functionality of the block.

Algorithms without programmers - it's very simple!

ON THE APPROACH TO A NEW LANGUAGE

In some sections of my book I have gone beyond the theories in which I can claim ownership.
any professional knowledge. I ask those whose protected lands I have invaded to forgive me my rashness. And if the individual trophies I write about exist only in my imagination, then at least such poaching does not cause any harm to the rightful owners, while a random stranger can sometimes see something that is both unexpected and real.

George Paget Thomson

WHY IS THE DRAGON LANGUAGE NEEDED?

DRAGON is an algorithmic language that has an unusual property: at the same time it is a language for describing the structure of activity, a language of understanding and mutual understanding, and a language for the development of intelligence. As a programming language, it satisfies the requirements of mathematical rigor, allowing one to unambiguously obtain object code (machine code for a computer) from source text. But that's not the main point. When creating DRAGON, the main attention was paid to the human factor, improving the visibility and intelligibility of technical and social projects and technologies, improving the ergonomic characteristics of algorithms, in order not in words, but in deeds to turn DRAGON into a language for improving the functioning of the mind, a language of understanding and mutual understanding.

Although DRAGON looks very similar to ordinary flowcharts of algorithms and programs, in fact it is an original development. The closest functional analogue of DRAGON should be considered action diagrams and activity diagrams.

For meticulous readers who love details, more distant “relatives” can also be called analogues of DRAGON - to one degree or another. These include: Nessie-Shneiderman diagrams, HOS diagrams, greenprint diagrams, NEC SPD diagrams, Hitachi PAD diagrams, decision trees and tables, decomposition schemes, dependency diagrams, SDL language and its derivatives, BLS system , created by A. Smolyaninov from St. Petersburg Electrotechnical University, R-scheme by I. Velbitsky, scheme by V. Prokhorov, etc.

WHAT IS THE SECRET OF THE DRAGON? — IN A COGNITIVE APPROACH

However, comparison with analogues in this case is unproductive, since it does not allow us to reveal the most significant feature of DRAGON, which is called the “cognitive approach”. The term “cognitive” (cognitive) has not yet become widespread among designers, developers, engineers and programmers, but it is the secret password of a new powerful scientific order, or rather, the banner of two new, rapidly developing directions in psychology and the science of intelligence, known like cognitive psychology and cognitive science.

One of the goals of these disciplines is to identify the hidden reserves of the human brain and increase the creative productivity of intellectual workers.
The essence of the question is as follows. Developers of technical and social projects, intellectual workers are living people with a brain, the capabilities of which, although great, are nevertheless far from unlimited. Thus, the design problem is not only a technical one, but also a human, cognitive, i.e., cognitive problem.

In this book, the cognitive factor refers to the cognitive, intellectual, thinking, creative aspects of the activities of scientists, specialists and students. The more complex the object of technical and social design, the more important it is to emphasize the need to carefully take into account the cognitive characteristics of people’s activities. Academician P. Simonov emphasizes: for system developers, “it is extremely important to know the rules, following which the living brain perceives, processes, records and uses newly acquired information. Information about such rules identified in the experiment is provided by cognitive psychology.”
Using these rules allows you to get a practical result - increase the productivity of mental work.

WHY ARE PEOPLE NOT INTERESTED IN THEIR OWN BRAINS?

Over the past two decades, neurobiological and psychological research has provided new and extremely important insights into the functioning of the brain. They open the way to revolutionary transformations of intellectual work, creating the prerequisites for a radical increase in its knowledge-generating creative productivity. In fact, we are on the threshold of a strategic reform of intellectual labor, promising the inclusion of new powerful reserves of the human brain and intellect in creative work. But these results, due to known interdisciplinary barriers, have not yet become the property of designers, engineers and programmers developing complex technical and social systems. As a result, a paradoxical situation was created. Let's explain the situation with an example.

Programming is done by people with brains. However, until now, programming languages, methods and theories have been built without taking into account the design of the brain. It is impossible to maximize the creative productivity of programmers' brains without taking into account its design. Therefore, traditional ways of creating programming languages and technologies that ignore the design of the brain are outdated and ineffective.

It seems that this conclusion is also valid in other cases. Ignoring the patterns of brain function and insufficient attention to cognitive issues leads to unpleasant consequences: mutual misunderstanding between co-authors of complex projects, serious misconceptions in scientific knowledge, major scientific and technical miscalculations, the elimination of which requires significant material costs (associated with expensive design modifications and labor-intensive modifications of software), as well as to a noticeable decrease in the resulting labor productivity of developers and other participants in technical and social projects.

The science of human factors is called ergonomics. Cognitive issues are an important part of ergonomics. To isolate the cognitive group from other ergonomic issues, the terms “cognitive ergonomics” and “cognitive-ergonomic problems” are sometimes used.

WILL DRAGON BECOME THE WORLD CHAMPION IN THE “UNDERSTANDABILITY OF ALGORITHMS” CRITERION?

This book is of a purely practical nature. Below it will be shown that the cognitive approach is a working method that produces useful results: improving the understanding of algorithms and programs, projects and technologies, increasing the productivity of complex intellectual work. We will try to substantiate this thesis by gradually revealing the features of the DRAGON language.

Like all other languages, DRAGON is based on mathematics and logic. However, beyond that, it takes cognitive issues into account most carefully. Thanks to the systematic use of cognitive-ergonomic methods, DRAGON acquired unique ergonomic characteristics. It can be assumed that in the future DRAGON will be able to claim the title of champion in the criterion of “understandability of algorithms and programs” (in the class of imperative languages).

DRAGON can be defined as a publicly accessible visual language designed to describe the structure of activities, for systematization, structuring, visual representation and formalization of imperative knowledge, as well as for design, programming, modeling and training. It is a universal intersectoral language of the business world, used to describe scientific, technical, medical, biological, economic, social, educational and other tasks. DRAGON allows you to organize and present a solution to any, no matter how complex, imperative (procedural, activity-based, technological, recipe, algorithmic) problem in the form of visual drawings made according to the principle “ I looked and immediately understood!”.

The humanity of the DRAGON language, the desire to create maximum comfort for the functioning of the human brain, and every possible concern for increasing the creative productivity of personnel allows us to hope that DRAGON will receive the widest application in the national economy, business, defense, science and the education system. Using not just visual, but extremely visual forms of knowledge representation, facilitating the work of the brain, DRAGON provides a noticeable increase in the productivity of intellectual work.
The DRAKON language is based on the idea of cognitive formalization of knowledge, which makes it possible to combine the rigor of logical-mathematical formalization with precise consideration of the cognitive (cognitive) characteristics of a person. As a result, it was possible to radically simplify and facilitate the procedure for describing the structure of activities, formalizing the professional knowledge of specialists, standardizing it and making it suitable for mass practical use. This applies equally to both computer and “non-computer” intellectual activity of people.

Thus, the main goal of creating the DRAKON language is to provide a qualitative leap in increasing the productivity of complex intellectual work by increasing the intellectual productivity of the human brain, identifying and more fully using the reserves of human intelligence, and creating cognitive prerequisites for a significant increase in the efficiency of information technology.

WHO IS THE DRAGON LANGUAGE DESIGNED FOR?

The language is equally designed for four categories of persons:
- for people who are completely unfamiliar (or weakly familiar) with programming and computer technology: mechanics, electricians, complex engineers, instrument engineers, testers, physicists, chemists, geologists, biologists, doctors, agronomists, economists, lawyers, psychologists, etc. ;
- for professional programmers, mathematicians and computer developers, including specialists in operating systems, system and application programming, as well as microprogramming (for personal, universal, control and on-board computers);
- for schoolchildren and students;
- for managers at many levels who want to understand the essence of complex problems in a minimum amount of time.

LIST OF TASKS SOLVED USING THE DRAGON LANGUAGE

The DRAGON language can be used to solve the following problems:

Description of the structure of human activity;
- visual representation of imperative knowledge in any areas of the national economy, science and education;
- description of conceptual solutions and imperative models;
- design of algorithms and programs;
- development of algorithms and programs;
- design of technological processes;
- description of any technologies (industrial, agricultural, medical, pedagogical, managerial, etc.);
- description of the design process;
- description of the processes of functioning of discrete systems and devices, including intelligent systems;
- description of the initial data for the development of computer-aided design systems and automation systems for scientific research;
- description of the process of solving mathematical problems;
- description of the dialogue and interaction between the human operator and the machine (control panel);
- description of the testing and troubleshooting process;
- solving diagnostic problems in any subject areas;
- microprogram development;
- description of the process of functioning of organizations and enterprises;
- automatic formalization of professional knowledge of scientists, designers, mathematicians, doctors, lawyers, agronomists, psychologists, operators, etc.;
- solving educational problems: teaching the skills of algorithmization, programming and automatic formalization of knowledge in an extremely short time.

As already mentioned, the functional analogue of DRAGON is action patterns and activity patterns. DRAGON is capable of performing all the functions of the latter (the reverse is not true). Therefore, the list can be continued by including tasks solved by action schemes. This will allow us to describe some of the functions of the DRAGON using terms characteristic of American literature:

Strategic overview of corporate functions;
- description of logical relationships among processes;
- description of the overall program structure;
- description of detailed program logic;
- complete decomposition of programs (ultimate decomposition), starting from large-scale logic and ending with code details, which is equally useful in both top-down design and bottom-up design;
- program design up to the last moment can be carried out regardless of the language, and only at the last stage is the transition to the desired language made;
- training of end users, encouraging them to analyze and design detailed process logic;
- description of organizational management procedures;
- description of computer methodologies;
- description of methodologies of information engineering.

As can be seen from this list, DRAGON has the property of versatility, proving useful in solving a wide range of diverse problems. Thanks to this, DRAGON serves as a universal language of business communication and mutual understanding for specialists in various specialties. In addition, DRAGON significantly facilitates the process of formalizing knowledge, opening up new opportunities for increasing the level of automation in the design and operation of complex objects.

CONCLUSIONS

1. Traditional goals and methods for creating artificial languages, in particular programming languages, should be considered largely outdated.

2. Recent research in the fields of neuroscience, psychology, cognitive science and ergonomics has provided new and extremely valuable information about the functioning of the brain, which can and should be used in the development of a new generation of languages in order to increase the productivity of the human brain.

3. Currently, there is no well-thought-out strategy aimed at eliminating interdisciplinary barriers, with the goal of equipping developers of artificial languages of the next generation with deep knowledge in the field of human sciences, human factors and human intelligence. This deficiency must be eliminated as soon as possible.

4. The concept of new generation artificial languages is based on an interdisciplinary approach and radically changes traditional ideas about the purpose of artificial languages and the set of priority requirements for them. Humanitarian issues and demands are put at the forefront, which must be appropriately detailed.