Новые цели стандартизации блок-схем

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

! Существуют три сферы применения блок-схем:

1) практическое программирование;

2) теоретическое программирование;

3) учебная и научно-техническая литература[23].

Во всех трех сферах используется различная топология блок-схем, унификация отсутствует. Имеющиеся стандарты на блок-схемы относятся только к первой сфере и не касаются двух других. Но главный недостаток состоит в том, что во всех случаях доминируют неформальные блок-схемы.

! Дальнейшее использование неформальных блок-схем во всех случаях следует признать нецелесообразным. С появлением языка SDL и его модификаций началась эра формальных блок-схем. Однако графический синтаксис известных попыток формализации блок-схем не согласуется с видеоструктурными принципами Дейкстры, а также развитым на их основе шампур-методом и по этой причине нуждается в улучшении.

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

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

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

 

Правила визуального структурного программирования (или, что одно и то же, визуальный синтаксис языка ДРАКОН) удовлетворяют пере­численным требованиям и, следовательно, могут быть положены в основу проекта упомянутого стандарта, а гарантом его выполнения и единого понимания может стать визуальный ДРАКОН-редактор.

Чем отличаются блок-схемы
от Дракон-схем?

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

С точки зрения правил языка ДРАКОН, первая блок-схема на рис. 132 (заимствованная из [5]) имеет следующие недостатки.

! Неоправданно большое число изломов линий (в блок-схеме 16 изломов, в дракон-схеме только 5).

Большое число “паразитных” элементов: 18 стрелок и 4 кружка, которые в дракон-схеме отсутствуют.

 

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

! Функционально однородные иконы Ф1 — Ф5 в блок-схеме разбросаны по всей площади чертежа, занимая четыре разных горизонтальных уровня; в дракон-схеме они расположены на одном уровне, что служит для читателя наглядной подсказкой об их функциональной однородности.

! Ромбы имеют выход влево, что в дракон-схеме не допускается.

! Икона Ф1 и ее вертикаль расположены слева от шампура (в дракон-схеме это запрещено).

! Ниже икон Ф4, Ф5 имеется четыре уровня горизонтальных линий, которые имеют “паразитный” характер; в дракон-схеме четыре уровня сведены в одну линию.

 

Вторая блок-схема на рис. 132 (взятая из [17]) имеет следующие изъяны.

! Слева от иконы А2 имеется пересечение линий (в дракон-схеме пересечения запрещены).

! Возле иконы Е3 имеется линия под углом 45º (в дракон-схеме наклонные линии не допускаются).

! Иконы А2, А3 и Е3 имеют более одного входа (в дракон-схеме это запрещено).

! Иконы А1, А2, А3, Е3 имеют входы сбоку (в дракон-схеме вход разрешается только сверху).

! Отсутствует шампур, так как выход иконы “заголовок” и вход иконы “конец” не лежат на одной вертикали.

 

Предыдущие два примера “плохих” блок-схем были случайным образом взяты из технической литературы. Следующий (третий) пример (см. рис. 132) скопирован из источника [18], где он характеризуется как “стандартная блок-схема ANSI” (Американский национальный институт стандартов). Блок-схема, выполненная по американскому стандарту, также имеет многочисленные дефекты:

! Ниже иконы G имеет место разрыв шампура (нарушено правило, согласно которому один из путей, идущих от входа к выходу, должен проходить по главной вертикали).

! Икона G имеет два входа (в дракон-схеме разрешается только один вход).

! Икона G имеет вход сбоку (в дракон-схеме это запрещено).

! У иконы G выход находится слева (в дракон-схеме он должен быть снизу).

! Две петли обратной связи обычного цикла находятся слева от шампура и закручены по часовой стрелке (в дракон-схеме они расположены справа от шампура и закручены против часовой стрелки).

! Используются неудобные ромбы (в дракон-схеме их заменяют эргономичные иконы “вопрос”).

! Ромб L имеет выход слева (в дракон-схеме он должен быть справа).

! Используются 12 стрелок, из которых 10 — паразитные (в дракон-схеме всего 2 стрелки).

! Имеется один избыточный излом линии (в блок-схеме 9 изломов, в дракон-схеме только 8).

 

Таким образом, американская блок-схема, как и предыдущие при­меры, по всем параметрам проигрывает дракон-схеме.

В чем сходство визуального и текстового
структурного программирования?

Можно предложить девять правил, устанавливающих соответствие между понятиями шампур-метода и классического структурного кодирования.

1. Понятие “функциональный атом” (рис. 122) эквивалентно понятиям “функциональный узел”, “функция” [3] и “узел обработки” [5], используемым в литературе по структурному программированию.

2. Макроикона “развилка” (рис. 122), в которую произведен ввод функционального атома в левую или обе критические точки, эквивалентна конструкциям if-then и if-then-else соответственно [3] — см. также две верхние графы на рис. 131.

3. Макроикона “обычный цикл” (рис. 122), в которую произведен ввод функционального атома в одну или обе критические точки, экви­валентна конструкциям do-until, while-do, do-while-do соответственно [3] — см. две нижние графы на рис. 131.

4. Непустая макроикона “переключатель” (рис. 122), в которую введено нужное число икон “вариант” с помощью операции “добавление варианта”, эквивалентна конструкции case [2] — см. рис. 131.

5. Непустая макроикона “цикл ДЛЯ” (рис. 122) эквивалентна циклу for языка СИ.

6. Непустая макроикона “переключающий цикл” (рис. 122), в которую введено нужное число икон “вариант”, эквивалентна циклу с вложенным оператором саse, используемым, например, при построении рекурсивных структурированных программ по методу Ашк­рофта—Манны [3].

7. Шампур-блок — видеоструктурный эквивалент понятия “простая программа” [3].

8. Атом — общее понятие для основных составляющих блоков, необходимых для построения программы согласно структурной теореме Бома и Джакопини [1]. Оно охватывает также все элементарные структуры структурного кодирования, кроме последовательности [3] (последняя в шампур-методе считается неэлементарной структурой).

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

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

В чем различие визуального и текстовго
структурного программирования?

Структурные, лианные и адресные блоки

Шампур-метод позволяет строить как структурные, так и метаструктурные (лианные) программы. Выше мы выяснили, что базовые операции моделируют классическое структурное кодирование. Чтобы смоделировать полезные функции оператора goto, в шампур-методе предусмотрены операции “пересадка лианы” и “заземление лианы”.

Введем три понятия.

Структурный блок — шампур-блок, построенный только с помощью базовых операций, без использования действий с лианой.

Лианный блок — шампур-блок, полученный из структурного блока с помощью операции “пересадка лианы”.

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

В примитиве могут использоваться только структурные и лианные блоки (рис. 133, 134), в силуэте — все три типа блоков: структурные, лианные и адресные (рис. 135, 136)[24].

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

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

Чтобы убедиться в этом на примере, вернемся к анализу рис. 27. В гл. 7 мы рассмотрели эргономические преимущества схемы на рис. 27 б по сравнению с рис. 27 а. Было показано, что улучшение эргономич­ности достигнуто за счет использования равносильных преобразований алгоритмов: вертикального и горизонтального объединения. При этом за кадром осталась важная проблема — проблема синтаксиса: как построить указанные схемы? Теперь мы имеем возможность осветить этот вопрос. Схема на рис. 27 а представляет собой структурный блок, полученный с помощью операции “ввод атома”. В отличие от нее схема на рис. 27 б — это лианный блок, построенный методом пересадки лианы.

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

Пересадка лианы узаконивает лишь некоторые, отнюдь не любые передачи управления, поскольку определение данной операции (см. гл. 15, тезис 28) содержит ряд ограничений. Запрет на образование нового цикла вызван тем, что переход на оператор, расположенный выше (раньше) в тексте программы, считается “наихудшим применением оператора goto ” [4]. Указанный запрет вводится, чтобы выполнить требование: использовать goto только для передачи управления вперед по программе, “которое некоторыми организациями принимается в качестве компромиссной версии структурного программирования”.

Запрет на образование второго входа в цикл соответствует требованию структурного кодирования, согласно которому цикл, как и любая простая программа, должен иметь не более одного входа. Лишь третий запрет является оригинальной особенностью шампур-метода: он запрещает передачи управления, изображение которых с помощью лианы ведет к пересечению линий. Таким образом, пересадка лианы разрешает только те переходы вниз по ДРАКОН-программе, которые образуют связи с валентными точками и изображаются легко прослеживаемыми маршрутами, т. е. непересекающимися линиями.

Является ли
текстовое структурное программирование
формальным методом?

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

По мнению специалистов, “правила структурного программирования верны в 95%. Но остаются злополучные 5%” [20]. Чтобы поправить дело, решить проблему пяти процентов и создать метод, пригодный для широкой практики, пришлось пойти на компромисс и дать добро на использование заменителей и так называемое “ограниченное применение goto ” (см. табл. 4, варианты 2—4). Благодаря этому проблема массовой практики программирования была решена. Но какой ценой? Ценой отказа от строгого формализма.

Это нетрудно показать. Например, авторы учебника языка СИ со­ветуют осторожно и редко применять заменители break и continue, “поскольку слишком частое их использование ухудшает читаемость программы, увеличивает вероятность ошибок и затрудняет ее модификацию” [21]. Далее они пишут: избегайте использовать goto, ибо это “чрезвычайно плохое” средство, которое следует применять “как можно реже или не применять совсем” [21].

Отсюда вытекает, что решение о списке случаев, когда нужно или не нужно употреблять перечисленные операторы, предоставляется программисту, который будет действовать, возможно, из лучших побуждений, но в соответствии со своим личным опытом и пристрастиями. Таким образом, о строгой формализации в данном случае речь идти не может.

Следовательно, мы вправе сделать существенное замечание. Структурное кодирование, используемое в широкой практике программирования, не является формальным методом, так как к формальным правилам Дейкстры пришлось добавить неформальные правила, касающиеся goto и заменителей.

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

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