Критические и нейтральные точки

Тезис 15. Валентные точки делятся на нейтральные и критические.

Тезис 16. Точка называется нейтральной, если применение операции “ввод атома” к данной точке является возможным, но не обязательным. В отличие от нее критическая точка требует обязательного ввода атома.

Тезис 17. Валентные точки находятся в заготовках и атомах. Они показаны на рис. 115 и 122, где нейтральные точки обозначены светлыми кружками, критические — жирными точками.

Тезис 18. Если в фигуре (заготовке или атоме) одна критическая точка, ввод атома обязательно производится именно в нее; при этом критическая точка уничтожается. Если фигура имеет две критические точки, обязательный ввод атома делается только в одну из них; при этом критическая точка, в которую произведен ввод, уничтожается, а другая критическая точка нейтрализуется, т. е. становится нейтральной.

Тезис 19. Полная совокупность критических точек охватывает:

! критические точки в пустых атомах;

! одну критическую точку в заготовке-примитив;

! одну критическую точку в заготовке-силуэт.

 

Тезис 20. Полная совокупность нейтральных точек охватывает:

! входные и выходные точки атомов;

! две внутренние точки в атоме “цикл ЖДАТЬ”;

! одну точку в заготовке-силуэт;

! точки, полученные в результате нейтрализации критических точек.

 

Правила использования операции “ввод атома”
при построении дракон-схемы

Тезис 21. Операция “ввод атома” применяется для ввода только простых и пустых атомов, а также цикла ЖДАТЬ. Ввод непустого атома осуществляется в два этапа; сначала вводится пустой атом, затем в его критическую точку вводится функциональный атом.

Пояснение. Ввод пустого атома — очень удобный строительный прием. Он позволяет обеспечить богатство и разнообразие создаваемых дракон-схем и используемых в них конфигураций. Среди последних особую роль играет так называемая “матрешка”.

Тезис 22. Матрешка — фигура, полученная путем ввода пустого атома в критическую точку пустого атома, а также путем многократного вложения пустых и непустых атомов друг в друга (рис. 123).

Тезис 23. Матрешка бывает пустой (если все содержащиеся в ней атомы пустые), частично пустой (если в ней есть как пустые, так и непустые атомы) и непустой (если все ее атомы непустые). См. рис. 124—126.

Пояснение. После того как пользователь эффективно использовал пустые атомы для придания дракон-схеме желаемой конфигурации, он должен убрать их из схемы.

Тезис 24. Чтобы устранить пустые атомы из дракон-схемы, есть два способа:

! превратить пустой атом в непустой;

! преобразовать пустой атом в пустую матрешку, затем превратить ее в непустую.

 

Тезис 25. Устранение из дракон-схемы пустых атомов автоматически приводит к уничтожению всех критических точек.

Операция с лианой

Тезис 26. Лиана — часть дракон-схемы, имеющая один вход и один выход, именуемые “началом лианы” и “концом лианы” соответственно. Началом лианы может быть любой выход икон “вопрос” и “вариант”, если он (выход) не является петлей цикла. Концом лианы считается точка слияния, в которой нижняя часть лианы соединяется с другой линией (концом лианы не может быть неразветвленный вход иконы).

Тезис 27. Лиана может быть нагруженной (если она содержит иконы) и ненагруженной (если это просто линия).

Пересадка лианы

Тезис 28. Пересадка лианы — преобразование дракон-схемы, выполняемое за четыре шага.

Шаг 1. Производится отрыв конца лианы от точки присоединения (рис. 119).

Шаг 2. Конец лианы с помощью вертикальных и горизонтальных линий присоединяется к любой валентной точке, куда лиана может дотянуться без пересечения с другими линиями (рис. 119). При этом запрещается:

! формировать второй вход в ветку (ошибка “сиамские близнецы” — см. рис. 127);

! образовывать новый цикл;

! создавать второй вход в цикл.

 

Однако разрешается строить новый путь из середины обычного цикла к единственному входу в этот цикл, создавая визуальный эквивалент оператора continue языка СИ (см. рис. 90, пример 7, а также рис. 41).

Шаг 3. Производится эквивалентное преобразование топологии дракон-схемы, чтобы лиане не пришлось загибаться наверх (рис. 128) и соблюдались правила построения шампур-блока (рис. 129).

Шаг 4. Устраняются неоправданные изломы линий (рис. 130).

Заземление лианы

Тезис 29. Заземление лианы — преобразование дракон-схемы, выполняемое за четыре шага.

Шаг 1. Производится отрыв конца лианы от точки присоединения (рис. 120).

Шаг 2. Конец лианы с помощью вертикальной линии присоединяется к любой точке нижней горизонтальной линии силуэта, куда он может дотянуться, не пересекая другие линии.

Шаг 3. Производится разрыв линии в нижней части лианы и в место разрыва вставляется икона “адрес” (рис. 120).

Шаг 4. Устраняются неоправданные изломы линий.

Прочие операции

Тезис 30. Боковое присоединение — преобразование дракон-схемы, с помощью которого в схему добавляются иконы “синхронизатор” или “формальные параметры”.

Икона “синхронизатор” размещается слева от другой иконы и соединяется с ней горизонтальным отростком. Перечень икон, к которым осуществляется боковое присоединение синхронизатора, показан на рис. 2 (п. 8—20).

Икона “формальные параметры” размещается справа от иконы “заголовок” и соединяется с ней горизонтальным отростком, как показано на рис. 2 (п. 1).

Тезис 31. Добавление варианта — преобразование дракон-схемы, с помощью которого в атом “переключатель” добавляется еще одна икона “вариант”. Число добавлений не более 14, так что максимальное число вариантов в переключателе равно 16.

Тезис 32. Добавление ветки — преобразование силуэта, в который добавляется еще одна ветка. Число добавлений не более 14, так что максимальное число веток в силуэте равно 16.

Тезис 33. Удаление последней ветки — преобразование силуэта, при котором удаляется крайняя правая ветка. Этот прием используется при описании бесконечного параллельного процесса, как показано в примерах на рис. 88 и 89.

Тезис 34. Удаление конца примитива — преобразование примитива, при котором удаляется икона “конец”. Это необходимо для описания бесконечного параллельного процесса.

Тезис 35. Дополнительный вход — преобразование силуэта, с помощью которого добавляется еще одна икона “заголовок”, которая размещается над любой иконой “имя ветки” (кроме левой) и соединяется с ней вертикальным отростком. При этом на верхней горизонтальной линии силуэта рисуют направленную вправо стрелку, как показано в примере на рис. 84 справа.

О г р а н и ч е н и е. При наличии веточного цикла запрещается присоединять дополнительный заголовок к середине веточного цикла.

Основные результаты

Тезис 36. Любая правильно построенная дракон-схема “примитив” является результатом преобразования заготовки-примитив с помощью конечного числа операций: ввод атома, пересадка лианы, добавление варианта, боковое присоединение, удаление конца примитива.

Тезис 37. Любая правильно построенная дракон-схема “силуэт” является результатом преобразования заготовки-силуэт с помощью конечного числа операций: ввод атома, добавление ветки, пересадка лианы, заземление лианы, добавление варианта, боковое присоединение, удаление последней ветки, дополнительный вход.

Пояснение. Тезисы 36 и 37 могут рассматриваться как окончательные определения понятий “примитив” и “силуэт”.

Выводы

1. Изложенные выше 37 тезисов (вместе с рисунками, на которые они ссылаются) дают однозначное описание визуального синтаксиса, которое при желании можно изложить строгим математическим языком.

2. Это описание является достаточным для построения ДРАКОН-редак­тора, способного решить две задачи. Во-первых, нарисовать (в соответствии с указаниями пользователя) любую абстрактную дракон-схему, принадлежащую множеству правильно построенных (удовлетворяющих требованиям визуального синтаксиса) дракон-схем. Во-вторых, создать в памяти компьютера формальное описание построенной схемы, пригодное (после заполнения икон надлежащими текстовыми операторами) для трансляции в объектные коды или для выполнения программы в режиме интерпретации.

 

Глава 16:
Визуальное структурное
программированиее

Наше мышление основано в первую очередь на зрительном восприятии.

Вадим Глезер

Постановка проблемы

Попробуем включить воображаемый “боковой прожектор” и взглянуть на проблему под другим углом зрения. Существует некоторое, причем весьма глубокое, хотя и не всегда очевидное сходство между изложенными выше идеями и концепцией структурного программирования. Исходя из этого, введем термин “визуальное структурное программирование” и определим его как набор правил, совпадающий с визуальным синтаксисом языка ДРАКОН. В концентрированном виде эти правила изложены в гл. 15.

Чтобы отграничить теоретические аспекты визуального структурного программирования от второстепенных деталей, нам понадобится термин “шампур-метод”. Впрочем, иногда выражения “шампур-метод” и “визуальное структурное программирование” будут использоваться как синонимы.

Размышляя над проблемой, автор пришел к следующим предварительным выводам или, лучше сказать, предположениям.

! Несмотря на наличие целого ряда общих признаков, текстовое и визуальное структурное программирование — существенно разные вещи.

! Традиционное (текстовое) структурное программирование является, по-видимому, наилучшим решением соответствующей задачи для традиционного (текстового) программирования.

! Для визуального программирования подобное утверждение неправомерно. Можно, конечно, тупо перенести правила текстового структурного программирования на визуальный случай. Но это не будет хорошим решением.

! Чтобы разработать эффективный метод структуризации для визуального варианта, необходимо, взяв за основу правила тексто­вого структурного программирования, значительно модифицировать их.

! Принципы структуризации, положенные в основу визуального синтаксиса языка ДРАКОН, являются искомым решением.

 

В данной главе сделана попытка обосновать заявленные выводы.

Историческая справка

Согласно классической теореме Бома и Джакопини, всякая реальная программа может быть построена из функциональных блоков (действий) и двух конструкций: цикла и дихотомического выбора (развилки) [1]. Эдсгер Дейкстра обогатил и усилил эту идею, предложив отказаться от оператора безусловного перехода goto и ограничиться тремя управляющими конструкциями: последовательность, цикл, выбор [2].

Дональд Кнут подверг критике тезис Дейкстры о полном исключении goto, продемонстрировав случаи, где goto полезен. В итоге возникла плодотворная дискуссия, строго говоря, не завершенная до сих пор, в ходе которой выявились четыре варианта мнений (табл. 4).

Таблица 4

Позиция участников дискуссии	Используются три структурные конструкции?	Используются заменители goto?	Используются goto?
Вариант 1	Да	Нет	Нет
Вариант 2	Да	Нет	Да
Вариант 3	Да	Да	Да
Вариант 4	Да	Да	Нет

Вариант 1 описывает ортодоксальную позицию Дейкстры, согласно которой оператор goto имеет “гибельные последствия” и поэтому “должен быть исключен из всех языков программирования высокого уровня”. Исходя из этого были разработаны языки без goto: PDL [3], BLISS и др.

Вариант 2 отражает мнение ранних критиков Дейкстры, позиция которых выражается словами: “использование оператора goto может оказаться уместным в лучших структурированных программах”; “всегда были примеры программ, которые не содержат goto и аккуратно расположены лесенкой в соответствии с уровнем вложенности операторов, но совершенно непонятны, и были другие программы, содержащие goto и все же совершенно понятные”. Поэтому нужно “избегать использования goto всюду, где это возможно, но не ценой ясности программы” [4].

Как известно, полемика по goto “растревожила осиное гнездо” и всколыхнула “весь программистский мир”. Варианты 1 и 2 выражают крайние позиции участников дискуссии, между которыми, как казалось вначале, компромисс невозможен. Однако ситуация изменилась с изо­бретением и широким распространением заменителей goto, примерами которых являются: в языке СИ — операторы break, continue, return и функция еxit (), в языке МОДУЛА-2 — операторы RETURN, EXIT, процедура HALT и т. д.

Заменители — особый инструмент, который существенно отли­чается как от трех структурных управляющих конструкций, так и от goto. Они обладают двумя важными преимуществами по сравнению с goto:

1) не требуя меток, заменители исключают ошибки, вызванные путаницей с метками;

2) каждый заменитель может передать управление не куда угодно (как goto), а в одну-единственную точку, однозначно определяемую ключевым словом заменителя и его местом в тексте. В результате множество точек, куда разрешен переход, сокращается на порядок, что также предотвращает ошибки.

Вариант 3 описывает языки СИ, АДА и др., где имеются заменители и на всякий случай сохраняется goto.

Вариант 4 соответствует языку МОДУЛА-2, где также есть заменители, однако goto исключен. Следует подчеркнуть, что при наличии заменителей сфера применения goto резко сужается, так что удельный вес ошибок, связанных с его применением, заметно уменьшается; поэтому вопрос об исключении goto теряет прежнюю остроту.

Идея структуризации оказала большое влияние на практику. Практически во все императивные языки высокого уровня на этапе их разработки или позже были введены структурные конструкции цикла и ветвления, а также, что очень важно, различные заменители goto.

Отживающий метод?

Вместе с тем структурное программирование породило преувеличенные надежды, которые сменились разочарованием и упреками в невыполнении обещаний. В самом деле, на начальном этапе развития структурной технологии не было недостатка в оптимистических прогнозах. Структурный подход даже называли “революцией в программировании”. В 1972 г. Дейкстра писал: “Мы научились столь многому, что в течение ближайших лет программирование может превратиться в деятельность, во многом отличающуюся от того, что имеется сегодня, — настолько отличающуюся, что мы должны очень хорошо подготовить себя к ожидающему нас шоку... Семидесятые годы завершатся тем, что мы окажемся способны проектировать и реализовывать такие системы, которые в настоящее время требуют напряжения всех наших способностей, причем расходы на них будут составлять лишь небольшой процент в человекогодах от их сегодняшней стоимости, и, кроме того, эти системы будут фактически свободны от ошибок” [5].

Оправдались ли эти прогнозы? Вот что пишет Н. Брусенцов в 1985 г. (т. е. спустя пять лет после обозначенного Дейкстрой “контрольного срока”): “Ожидавшегося эффекта эти мероприятия пока не дали. Трудозатраты на разработку и сопровождение программ, если и уменьшились, то незначительно. Надежность по-прежнему остается острейшей проблемой. Даже рьяные поборники идеи структурирования признают, что революция не удалась” [6]. В этих условиях некоторые авторы поспешили объявить структурное программирование “отживающим методом” [7].

Прав ли Игорь Вельбицкий?

Размышляя о причинах неудачи и стремясь поправить дело, И. Вель­бицкий предлагает радикальным образом пересмотреть само понятие “структура программы”. По его мнению, “структура — понятие многомерное. Поэтому отображение этого понятия с помощью линейных текстов (последовательности операторов) сводит практически на нет преимущества структурного подхода. Огромные ассоциативные возможности зрительного аппарата и аппарата мышления человека используются практически вхолостую — для распознавания структурных образов в виде единообразной последовательности символов” [8].

Развивая мысль, Вельбицкий противопоставляет текстовое и визуальное программирование, приходит к заключению, что “на рельсах текстового представления программ” резервы повышения производительности труда в программировании исчерпаны, и делает вывод о необходимости изменить “базис” программирования, т. е. перейти от текстового программирования к визуальному.

В настоящее время визуальное программирование бурно развивается, число его сторонников растет. Тем не менее, уместно спросить: в какой мере предлагаемый Вельбицким пересмотр понятия “структура программы” согласуется с пионерскими взглядами Дейкстры?

Четыре принципа структуризации блок-схем,
предложенные Э.Дейкстрой

Попытаемся еще раз заглянуть в темные переулки истории и внимательно перечитаем классический труд Дейкстры “Заметки по структурному программированию”. К немалому удивлению, мы обнаружим, что основной тезис о структурных управляющих конструкциях (для обозначения которых названный автор вводит термины “сочленение”, “выбор”, “повторение” [2]) излагается с прямой апелляцией к визуальному языку блок-схем! Непосредственный анализ первоисточника со всей очевидностью подтверждает: дейкстрианская “структурная революция” началась с того, что Дейкстра, использовав блок-схемы как инструмент анализа структуры программ, предложил наряду с другими важными идеями четыре принципа структуризации блок-схем, которые в дальнейшем были преданы забвению или получили иное, по нашему мнению, слишком вольное толкование. Эти принципы таковы.

1. Принцип ограничения топологии блок-схем. Структурная программа должна приводить “к ограничению топологии блок-схем по сравнению с различными блок-схемами, которые могут быть получены, если разрешить проведение стрелок из любого блока в любой другой блок. Отказавшись от большого разнообразия блок-схем и ограничившись...тремя типами операторов управления, мы следуем тем самым некоей последовательностной дисциплине” [2].

2. Принцип вертикальной ориентации входов и выходов блок-схемы. Имея в виду шесть типовых блок-схем (if-do, if-then-else, case-of, while-do, repеat-until, а также “действие”), Дейкстра пишет: “Общее свойство всех этих блок-схем состоит в том, что у каждой из них один вход сверху и один выход снизу” [2].

3. Принцип единой вертикали. Вход и выход каждой типовой блок-схемы должны лежать на одной вертикали.

4. Принцип нанизывания типовых блок-схем на единую вертикаль. При последовательном соединении типовые блок-схемы следует соединять, не допуская изломов соединительных линий, чтобы выход верхней и вход нижней блок-схемы лежали на одной вертикали.

Хотя Дейкстра не дает словесной формулировки третьего и четвертого принципов, они однозначно вытекают из имеющихся в его работе иллюстраций [2]. Чтобы у читателя не осталось сомнений, мы приводим точные копии подлинных рисунков Дейкстры (рис. 131, средняя и левая графа)[21].

Таким образом, можно со всей определенностью утверждать, что две идеи (текстовое и визуальное структурное программирование), подобно близнецам, появились на божий свет одновременно. Однако этих близнецов ожидала разная судьба — судьба принца и нищего.

Почему научное сообщество не приняло
видеоструктурную концепцию Э.Дейкстры?

Далее события развивались довольно загадочным образом, поскольку вокруг видеоструктурной[22] концепции Дейкстры образовался многолетний заговор молчания.

Неприятность в том, что изложенные выше рекомендации Дейкстры не были приняты во внимание разработчиками национальных и международных стандартов на блок-схемы (ГОСТ 19.701–90, стандарт ISO 5807–85 и т. д.). В итоге метод стандартизации, единственный метод, который мог бы улучшить массовую практику вычерчивания блок-схем, не был использован, а идея Дейкстры оказалась наглухо изолированной от реальных блок-схем, используемых в реальной практике программирования. В чем причина этой более чем странной ситуации?

Здесь уместно сделать отступление. Американский историк и философ Томас Кун в книге “Структура научных революций” говорит о том, что в истории науки время от времени появляются особые периоды, когда выдвигаются “несоизмеримые” с прежними взглядами научные идеи. Последние он, следуя Р. Бергману, называет парадигмами. История науки — история смены парадигм. Разные парадигмы — это разные образцы мышления ученых. Поэтому сторонникам старой парадигмы зачастую бывает сложно или даже невозможно понять сторонников новой парадигмы (новой системы идей), которая приходит на смену устоявшимся стереотипам научного мышления. По нашему мнению, текстовое и визуальное программирование — это две парадигмы, причем нынешний этап развития программирования есть болезненный процесс ломки прежних взглядов, в ходе которого прежняя текстовая парадигма постепенно уступает место новой визуальной парадигме. При этом — в соответствии с теорией Куна — многие, хотя и не все видные пред­ставители прежней, отживающей парадигмы проявляют своеобразную слепоту при восприятии новой парадигмы, которая в ходе неустанной борьбы идей в конечном итоге утверждает свое господство.

Этот небольшой экскурс в область истории и методологии науки позволяет лучше понять причины поразительного невнимания научного сообщества к изложенным Дейкстрой принципам структуризации блок-схем. Начнем по порядку. Формальная блок-схема — это двумерный чертеж, следовательно, она является инструментом визуального программирования. Отсюда следует, что предложенные Дейкстрой принципы структуризации блок-схем есть не что иное, как исторически первая попытка сформулировать основные (пусть далеко не полные и, возможно, нуждающиеся в улучшении) принципы видеоструктурного программирования.

Однако в 1972 г., в момент публикации работы Дейкстры [2], визу­альное программирование как термин, понятие и концепция фактически еще не существовало. Поэтому — вполне естественно — суть концепции Дейкстры была воспринята сквозь призму господствовавших тогда догматов текстового программирования со всеми вытекающими последствиями. Так родилась приписываемая Дейкстре и по праву принадлежащая ему концепция текстового структурного программирования. При этом (что также вполне естественно) в означенное время никто не обратил внимания на тот чрезвычайно важный для нашего исследования факт, что исходная формулировка концепции Дейкстры имела явно выраженную визуальную компоненту — она представляла собой метод структуризации блок-схем, т. е. была описана в терминах видеоструктурного программирования.

Подобное невнимание привело к тому, что авторы стандартов на блок-схемы посчитали, что данная идея их не касается, ибо относится исключительно к тексту программ, и дружно проигнорировали или, скажем мягче, упустили из виду визуальную компоненту структурного метода Дейкстры.

Справедливости ради добавим, что и сам отец-основатель (Э. Дейк­стра), обычно весьма настойчивый в продвижении и популяризации своих идей, отнесся к своему видеоструктурному детищу с удивительным безразличием и ни разу не выступил с предложением о закреплении структурной идеи в стандартах на блок-схемы.

Парадокс
структурного программирования

Мы подошли к наиболее интригующему пункту в истории структурного программирования. Чтобы выявить главное звено проблемы, зададим вопрос: являются ли блок-схемы и структурное программирование взаимно исключающими, несовместимыми решениями? В литературе по этому вопросу наблюдается редкое единодушие: да, они несовместимы. Вот несколько отзывов. Блок-схемы “не согласуются со структурным программированием, поскольку в значительной степени ориентированы на использование goto ” [4]. Они “затемняют особенности программ, созданных по правилам структурного программирования” [9]. “C появлением языков, отвечающих принципам структурного программирования,... блок-схемы стали отмирать” [10].

Парадокс в том, что приведенные высказывания основываются на недоразумении. Чтобы логический дефект стал очевидным, сопоставим две цитаты по методу “очной ставки” (табл. 5). Сравнивая мнение современных авторов с позицией Дейкстры, нетрудно убедиться, что описываемый критиками изъян действительно имеет место, но лишь в том случае, если правила вычерчивания блок-схем игнорируют предложенный Дейкстрой принцип ограничения топологии блок-схем. И наоборот, соблюдение указанного принципа сразу же ликвидирует недостаток.

 

 

Таблица 5

Мнение критиков, убежденных в невозможности структуризации блок-схем	Предложение Э. Дейкстры о структуризации блок-схем
“Основной недостаток блок-схем заключается в том, что они не приучают к аккуратности при разработке алгоритма: ромб можно поставить в любом месте блок-схемы, а от него повести выходы на какие угодно участки. Так можно быстро превратить программу в запутанный лабиринт, разобраться в котором через некоторое время не сможет даже сам ее автор” [10]	Структуризация блок-схем с неизбежностью приводит “к ограничению топологии блок-схем по сравнению с различными блок-схемами, которые могут быть получены, если разрешить проведение стрелок из любого блока в любой другой блок. Отказавшись от большого разнообразия блок-схем и ограничившись... тремя операторами управления, мы следуем тем самым некоей последовательностной дисциплине” [2]

Плохие блокс-схемы
или плохие стандарты?

Проведенный анализ позволяет сделать несколько важных замечаний.

! Обвинения, выдвигаемые противниками блок-схем, неправомерны, потому что ставят проблему с ног на голову. Дело не в том, что блок-схемы по своей природе противоречат принципам структуризации, а в том, что при разработке стандартов на блок-схемы указанные принципы не были учтены. На них просто не обратили внимания, поскольку в ту пору — именно в силу парадигмальной “слепоты” — считалось, что на практике структурное программирование следует применять к текстам программ, а отнюдь не к блок-схемам.

! Чтобы сделать блок-схемы пригодными для структуризации, необходимо ограничить и регламентировать их топологию с учетом видеоструктурных принципов Дейкстры.

! Видеоструктурная концепция Дейкстры — это фундаментальная идея, высказанная более двадцати лет назад и оказавшаяся невостре­бованной, поскольку она значительно опередила свое время.

! Сегодня созрели благоприятные условия для ее развития. Этому способствуют два обстоятельства. Во-первых, бурное развитие компьютерной графики и визуального программирования. Во-вторых, широкое применение CASE -технологий, в которых используется общий для всех участников проекта набор визуальных (графических) языков.

! Предложенные Дейкстрой принципы структуризации блок-схем пра­вильно указывают общее направление развития, однако они нуждаются в доработке, развитии и детализации с учетом последних достижений современной науки, а также опыта (в том числе отрицательного), накопленного при практическом внедрении текстового структурного программирования. В частности, современные блок-схемы должны удовлетворять не только критерию структуризации, но и критериям формализации и эргономизации.

! Именно эту задачу решает шампур-метод, который, с одной стороны, развивает видеоструктурную концепцию Дейкстры, а с другой — учитывает реалии сегодняшнего дня. С помощью шампур-метода разработана новая топология блок-схем (дракон-схемы), регламентация которой произведена на основе принципа когнитивной фор­мализации знаний.

! Современные стандарты на блок-схемы (международный стандарт ISO 5807–85, отечественный ГОСТ 19.701–90 и другие национальные стандарты, в том числе американский стандарт ANSI), а также инст­рукции по их применению следует признать устаревшими, так как они игнорируют принципы структуризации, формализации и эргономизации и объективно содействуют снижению качества соответствующей интеллектуальной продукции.

Блок-схемы и теоретическое
программирование

Наш интерес к структуризации и формализации блок-схем имеет и другую, не менее серьезную причину. Дело в том, что теоретическое программирование, в частности, теория схем программ (схематология) [11] и теория оптимизирующих преобразований программ [12] тесно связаны с теорией графов. По словам А. Ершова, “графы являются основной конструкцией для программиста”, так как они “обладают огромной, неисчерпаемой изобразительной силой, соразмерной масштабу задачи программирования” [13].

Для наших целей особенно важным является тот факт, что “графовая форма схем программ” [11] или, что одно и то же, “графовая схема” [14] (короче, граф-схема) аналогична блок-схеме [11, 12]. Более того, как убедительно показал А. Ершов, использовавший блок-схемы в качестве граф-схем [15], разграничение этих понятий является в некотором смысле условным. Различия в начертании (топологии) блок-схем и граф-схем несущественны, а наличие двух терминов оправдывается скорее разными сферами применения, так как термин “блок-схема” используется преимущественно в практическом, а “граф-схема” — в теоретическом программировании.