35067

КАК Улучшить работу ума. Алгоритмы без программистов — это очень просто!

Книга

Психология и эзотерика

Маленькая увертюра 9 Третий глаз для бизнесменов и руководителей 11 Интеллектуальный терроризм: фантазия или реальность Вместо предисловия 13 Почему умные люди страдают и гибнут 13 Разве такая проблема существует 14 Информационный стресс зловещий спутник информационного общества 14 Камикадзе умственного труда 15 Что такое интеллектуальный терроризм 15 Гуманитарная постановка задачи 16 Компьютерная мифология: облегчают ли компьютеры умственный труд 18 Что такое...

Русский

2013-09-08

8.66 MB

17 чел.


Владимир Паронджанов

____________________________________________________________________________________________

КАК
Улучшить
работу
ума

Алгоритмы
без программистов —
это очень просто!

____________________________________________________________________________________________

НОВЫЕ СРЕДСТВА
ДЛЯ ОБРАЗНОГО
ПРЕДСТАВЛЕНИЯ ЗНАНИЙ,
РАЗВИТИЯ ИНТЕЛЛЕКТА
И ВЗАИМОПОНИМАНИЯ

Академия народного хозяйства
при Правительстве Российской Федерации

____________________________________________________________________________________________

Москва
Издательство «Дело»
2001

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

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

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

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


УДК 37+681.3.06+331.015.11

ББК 32.973

П18

Рецензенты:

Ю. И. Журавлев,  академик РАН, зам. директора Вычислительного
центра РАН, председатель Научно-методического совета
по информ
атике Министерства образования;

П. П. Пархоменко,  член-корреспондент РАН, гл. научн. сотрудник
Института пр
облем управления РАН им. акад. В. А. Трапезникова;

Ю. В. Трунов,  д-р техн. наук, профессор, Генеральный директор —
Генеральный конструктор Научно-производственного центра
автомат
ики и приборостроения им. акад. Н. А. Пилюгина,
зав. Базовой кафедрой Московского института радиотехники, электроники и а
втоматики;

Я. В. Безель,  д-р техн. наук, профессор, Генеральный конструктор
Мо
сковского НИИ приборной автоматики;

В. П. Кутепов,  д-р физ.-мат. наук, профессор, зав. кафедрой
прикладной математики Московского энергетического института (Техн
ического университета)

Паронджанов В. Д.

П18  Как улучшить работу ума: Алгоритмы без программистов — это очень просто! — М.: Дело, 2001. — 360 с. — Илл.: 154.

ISBN 5–7749–0211–0

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

Для студентов, изучающих информатику, учителей и преподавателей информатики; алгоритмистов, программистов, математиков, системщиков, постановщиков задач, специалистов по CASE-технологиям, работающих непосредственно на фирмах; бизнесменов и руководителей, желающих эффективно контролировать потоки информации в своих организациях; психологов, изучающих работу ума, а также для широкой публики.

УДК 37+681.3.06+331.015.11

ББК 32.973

ISBN 5–7749–0211–0

©  Издательство “Дело”, 2001



ОГЛАВЛЕНИЕ

Маленькая увертюра 9

Третий глаз для бизнесменов и руководителей 11

Интеллектуальный терроризм: фантазия или реальность?
(Вместо предисловия) 13

Почему умные люди страдают и гибнут? 13

Разве такая проблема существует? 14

Информационный стресс — зловещий спутник информационного
общества 14

Камикадзе умственного труда 15

Что такое интеллектуальный терроризм? 15

Гуманитарная постановка задачи 16

Компьютерная мифология: облегчают ли компьютеры
умственный труд? 18

Что такое интенсификация интеллекта? 19

Критерий Декарта и эргономизация науки 20

О чем эта книга? 21

Секреты мудрого ДРАКОНА: объяснение на пальцах 22

Справка о состоянии дел 27

ГЛАВА 1. На подступах к новому языку 28

Зачем нужен язык ДРАКОН? 28

В чем секрет ДРАКОНА? — В когнитивном подходе 29

Почему люди не интересуются собственным мозгом? 29

Станет ли ДРАКОН чемпионом мира по критерию
“понимаемость алгоритмов”? 31

На кого рассчитан язык ДРАКОН? 32

Перечень задач, решаемых с помощью языка ДРАКОН 32

Выводы 34

ГЛАВА 2. Можно ли создать язык, улучшающий понимание
и взаимопонимание?
35

Почему специалисты не понимают друг друга? 35

Язык ДРАКОН как “эсперанто” делового мира 36

Что такое интеллектуальное взаимопонимание? 36

В чем особенность ДРАКОНА? 37

Выводы 38

ГЛАВА 3. Соображения, повлиявшие на создание
языка
ДРАКОН 39

Что важнее: компьютеры или человеческий мозг? 39

Что такое производительность умственного труда? 40

Зависит ли производительность персонала от производительности компьютеров? 41

Можно ли увеличить скорость работы человеческого мозга? 42

Проблема формализации профессиональных знаний 44

Можно ли обойтись без когнитологов? 45

Чем отличается алгоритм от технологического процесса? 46

Что такое технологический язык? 47

Технологические и декларативные знания 48

Почему нельзя жить по-старому? 50

Социальные технологии и электронные методологии 51

Методология быстрой разработки систем RAD 52

Схемы действий и язык ДРАКОН 54

Необходимость культурных изменений 54

Техноязык как элемент культуры 55

Выводы 56

ГЛАВА 4. Понимание и взаимопонимание — ключевые
проблемы информатики
58

Отсутствие понимания ведет к миллионным убыткам 58

Издевательство над здравым смыслом под названием
“абсолютно правильная программа” 59

Спецификации программ — вот главный “гадючник”! 59

Спецификации программ и методология RAD 61

Концепция когнитивного программирования 62

Выводы 64

ГЛАВА 5. Проблема улучшения работы ума: новый
когнитивный подход
65

Текст как зрительная сцена 65

Симультанное и сукцессивное восприятие 66

Как повысить продуктивность человеческого мозга? 66

Когнитивный недостаток текстового представления знаний 68

Каким должен быть формат диосцены? 69

Когнитивные рекомендации 71

Зачем нужны психологические эксперименты? 72

Ошибка Джеймса Мартина 74

“Это чудакам-инженерам нужны большие чертежи, а мы,
хитрецы-программисты, обойдемся маленькими” 74

Возможна ли стратегическая реформа мировой практики
программирования 78

Выводы 79

ГЛАВА 6. Изюминки языка ДРАКОН 80

Критика блок-схем 80

Преимущества дракон-схем 80

Иконы и макроиконы 81

Зачем нужна ветка? 81

Как работает ветка? 86

Как следует располагать ветки в поле чертежа? 86

Что такое шапка? 86

Что лучше: примитив или силуэт? 90

Как описать силуэт с помощью текстового языка? 91

Есть ли в алгоритме “царская дорога”? 93

Главный маршрут силуэта 95

Пересечения линий? — боже упаси! 95

Визуальный и текстовый синтаксис ДРАКОНА 101

Семейство ДРАКОН-языков 101

Выводы 102

ГЛАВА 7. Эргономичные алгоритмы 104

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

Что такое эргономичный алгоритм? 105

Чем отличается икона “вопрос” от развилки? 105

Маршруты и формулы маршрутов 108

Что такое рокировка? 108

Использование рокировки для улучшения эргономичности 111

Вертикальное и горизонтальное объединение 112

Эргономичность литеральных алгоритмов 112

Что делать, если эргономические требования противоречат
друг другу? 118

Икона-вставка как эргономический прием 118

Что такое подстановка? 119

Улучшение эргономичности алгоритмов с помощью цепочки
эквивалентных преобразований 124

Выводы 125

ГЛАВА 8. Визуализация циклов 126

Обычный цикл 126

Переключатель и переключающий цикл 133

Цикл  ДЛЯ 133

Веточный цикл 135

Главный маршрут силуэта 139

Выводы 142

ГЛАВА 9. Визуализация логических формул 143

Визуализация функции И 143

Визуализация функции ИЛИ 148

Визуализация функции НЕ 148

Визуализация сложных логических функций 153

Выводы 153

ГЛАВА 10. Что такое эргономичный текст? 154

Можно ли сделать логические выражения эргономичными? 154

Пример для исследования эргономичности логических выражений 154

Логическое выражение с абстрактными идентификаторами 155

Логическое выражение с короткими смысловыми идентификаторами 158

Логическое выражение с длинными смысловыми идентификаторами 159

Важный момент, о котором часто забывают 159

Как присвоить значение логической переменной? 160

Правила записи рамочных логических выражений 161

Как построить эргономичный логический текст? 161

Выводы 164

ГЛАВА 11. Визуальные операторы реального времени 165

Список операторов реального времени 165

Операторы ввода-вывода 165

Оператор “пауза” 166

Операторы “пуск таймера” и “синхронизатор” 167

Цикл ЖДАТЬ 169

Оператор “период” 170

Оператор “параллельный процесс” 171

Особенности операторов реального времени 173

Выводы 176

ГЛАВА 12. Дружелюбное программирование 177

Гибридный язык программирования ДРАКОН-СИ 177

Гибридный язык программирования ДРАКОН-МОДУЛА 180

Пример эргономической оптимизации программы 180

Диалоговые программы 181

Идентификаторы 183

Обработка массивов 185

Абстрактные дракон-схемы 187

Философия языка ДРАКОН 192

Классификация знаний 192

Выводы 193

ГЛАВА 13. Человеческая деятельность и формализация
знаний: живописные примеры
194

Что такое профессиональные знания? 194

Учебные экспертные системы 196

Визуализация экспертных систем 198

Визуализация описания технологических процессов 200

Что такое методология? 201

Визуализация методологий 201

Система “человек — машина” 212

Визуализация биологических алгоритмов 213

Визуализация медицинских алгоритмов 216

Другие примеры визуализации 216

Описание структуры деятельности 223

Нужен ли стандарт для описания деятельности? 224

Выводы 225

ГЛАВА 14. Визуальный дракон-редактор 226

Зачем нужен дракон-редактор? 226

Заготовка-примитив и заготовка-силуэт 226

Что такое атом? 226

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

Операция “пересадка лианы” 229

Операция “заземление лианы” 231

Пример построения дракон-программы “силуэт” 231

Формирование надписей “да” и “нет” 235

Выводы 235

ГЛАВА 15. Описание визуального синтаксиса языка ДРАКОН 236

Общие понятия 236

Шампур-блок 236

Операция “ввод атома” 237

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

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

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

Выводы 244

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему самолет не машет крыльями? 264

Выводы 265

ГЛАВА 17. Исчисление икон и попытка предсказать будущее 267

Визуальное логическое исчисление 267

Общеизвестные сведения о математической логике 267

Об одном распространенном заблуждении 268

Визуализация понятий математической логики 270

Исчисление икон 271

Еще раз о шампур-методе 272

Шампур-схема как абстрактная модель программы 273

Преобразование шампур-схемы в шампур-программу 274

Шампур-метод и доказательство правильности программ 274

Возможна ли теория визуального программирования? 275

Гипотеза о будущем императивных языков программирования 276

Визуализация логики и интенсификация интеллектуальной деятельности 278

Выводы 281

ГЛАВА 18. Место языка ДРАКОН в системе человеческой
культуры
282

Между Сциллой и Харибдой 282

Принцип структуризации деятельности 283

Генеральная концептуальная схема 284

Проблема деятельности в эргономике 286

Искусственный интеллект: алгоритмизация — это ночной кошмар! 287

Эргономический анализ проектно-конструкторской деятельности 290

Подводные камни проектно-конструкторской деятельности 291

Почему взорвался чернобыльский реактор? 292

Сон разума рождает чудовищ 297

Интенсификация интеллекта и языки программирования 298

Улучшение работы ума — проблема номер один 299

Выводы 300

ГЛАВА 19. Возможна ли эргономизация математики? 302

Почему Джон фон Нейман провалился на экзамене? 302

Существует ли пропасть между математикой и эргономикой? 303

Алгебра Диофанта 304

Эргономический анализ алгебры Диофанта 307

Эргономизация алгебры после Диофанта 308

Осознание полезности эргономического поворота в математике 311

Эргономическая победа Лейбница 312

Методологическая ошибка историков математики 314

Аналогия между математической диосценой и панелью
отображения информации 316

Математическая и эргономическая эффективность 317

Как повысить производительность математического труда? 319

Два метода визуализации математики 320

Проект “Когнитивный стиль” (CogniStyle) 321

Пример математической визуализации с помощью метода CogniStyle 322

Выводы 325

ГЛАВА 20. Можно ли стать интеллектуальным суперменом? 326

На пороге создания теории улучшения работы ума 326

Человеческий мозг нужно грамотно проектировать 327

Разгадка тайны человеческого интеллекта 334

Развитие и интенсификация интеллекта 336

Знаковая и предметная информация 337

Знаковое и предметное обеспечение информатики 337

Знаковая и предметная программа 339

Переломная веха в истории информатики 340

Одноглазые миссионеры, или Заброшенное дитя информатики 341

Когнитивная письменность — новый способ представления знаний 343

“Кастрированный” интеллект 344

Что такое проектоника? 345

Проектоника и искусственный интеллект 346

Особенности проектоники 347

Мироинформация и мироинтеллект 348

Стратегическая интеллектуальная инициатива 349

Дорога в будущее (Вместо заключения) 352

Интеллектуальные трудности как глобальная проблема 352

Вызов интеллектуального терроризма 353

Бессилие интеллекта 353

Цель — значительное улучшение интеллекта 353

Список литературы 355


МАЛЕНЬКАЯ  УВЕРТЮРА

Чем отличается хорошее мышление от плохого?... Как улучшить мышление? Свое мышление? Мышление вообще?...

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

Макс Вертгеймер

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

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

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

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

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

Легкомысленный словарик

Алгоритм — точное описание решения задачи, которое ведет к победе

Алгоритм — точно описанная последовательность человеческих действий

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

Визуальный алгоритм — алгоритм, изображенный не в виде текста, а в виде наглядной картинки

Визуализация алгоритма — преобразование алгоритма, который записан в виде плохого и непонятного текста, в хорошую и понятную картинку

Когнитивный — познавательный. Это неуклюжее словечко надо запомнить, так как оно будет попадаться на каждом шагу

Программа — последовательность действий, которые человек ленится выполнять сам и поэтому поручает компьютеру или роботу

Формальный — точный

Формальное описание — точное, однозначное и полное описание, лишенное пробелов и двусмысленностей

Формализация — превращение обычного (плохого) описания в формальное (хорошее)

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

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

Алгоритмизация — то же самое, что формализация деятельности

Алгоритмизация — внесение порядка в царство анархии, устранение путаницы и разгильдяйства, наведение технологической дисциплины

Алгоритмизация — процесс создания алгоритма

Эргономика — наука о том, как превратить сложную, трудную и противную работу в простую, легкую и приятную

Когнитивная эргономика — наука о том, как облегчить и улучшить умственную работу

Эргономизация науки — облегчение и улучшение научной деятельности

Эргономизация образования — облегчение и улучшение учебной деятельности


ТРЕТИЙ ГЛАЗ для бизнесменов
и руководителей

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

Давид Лассер

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

Гордость вашей организации, ее интеллектуальный костяк составляют золотые умы — квалифицированные специалисты, обладающие драгоценными профессиональными знаниями; в своей работе они используют компьютеры, объединенные в локальные и иные сети. В этой книге описан практически полезный метод, позволяющий улучшить работу ума этих людей, чтобы увеличить их интеллектуальный вклад в процветание вашей частной фирмы или государственной организации.

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

Здесь уместны некоторые пояснения общего характера. Когда говорят об автоматизации, имеют в виду автоматизированные системы управления предприятиями, технологическими процессами, научными исследованиями, конструкторскими разработками, проектированием, программированием, финансовой деятельностью, войсками и множество других. В XX в. широкая волна компьютеризации и автоматизации охватила весь мир и принесла замечательные плоды. Общественное богатство увеличилось. Доля физического труда сократилась, умственного — возросла. В этот период были осознаны две важные истины.

1. Современный мир — продукт мысли и ума. В конечном счете именно человеческий ум произвел все то, что мы видим и ощущаем вокруг себя. Цивилизация — это результат усилий человеческого ума.

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

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

Можно показать, что в этих рассуждениях скрыта тонкая и коварная ошибка. На самом деле автоматизация и улучшение работы ума — хотя и связанные, но существенно разные вещи. Творческая продуктивность человеческого мозга не зависит от мощности и других характеристик компьютеров; она определяется совсем другими факторами.

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

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


Интеллектуальный
терроризм:
фантазия или реальность?

(Вместо предисловия)

Мы просто не научились еще использовать на полную “проектную мощность” возможности нашего мозга.

Эвальд Ильенков

Почему умные люди страдают и гибнут?

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

В науке драматические ситуации, увы, не редкость. Тауринус, доведенный до крайности равнодушием математиков, сжег свой труд об основах геометрии. Больяи впал в душевное расстройство. Лобачевского в одной из рецензий объявили чуть ли не сумасшедшим. Клейна постигла катастрофа — соперничая с Пуанкаре в построении теории автоморфных функций, он надорвался, тяжело заболел и вынужден был навсегда прекратить научную работу по математике. Даже великий Гаусс, несмотря на блестящие успехи и выдающиеся открытия, однажды признался: “Смерть мне милее такой жизни”, причем историки предполагают, что его ипохондрия и душевный недуг — ответная реакция на неимоверно интенсивную работу и сверхчеловеческое усердие.


РАЗВЕ ТАКАЯ ПРОБЛЕМА СУЩЕСТВУЕТ?

Анализируя подобные случаи, трудно избавиться от впечатления, что за трагедиями конкретных людей скрывается и постепенно набирает силу новое и крайне негативное социальное явление, которое иногда характеризуют как “интеллектуальный терроризм”, но которое, наверно, было бы лучше назвать интеллектуальной каторгой. В той или иной степени с ним сталкиваются все, кому приходится испытывать хроническое перенапряжение и трудиться на пределе своих возможностей. Для некоторых непосильные перегрузки начинаются уже в школе. Отчасти этому способствуют недостатки преподавания. Жан-Луи Лорьер пишет: «Существует определенный вид интеллектуального терроризма, когда некоторых учеников называют “нуль в математике”, хотя их единственная вина состоит в том, что они не понимают то, о чем... никогда не говорится» [1].

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

ИНФОРМАЦИОННЫЙ СТРЕСС — ЗЛОВЕЩИЙ СПУТНИК ИНФОРМАЦИОННОГО ОБЩЕСТВА

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

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

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

КАМИКАДЗЕ УМСТВЕННОГО ТРУДА

Защита интеллектуальных работников от стресса ведется во многих направлениях: от медицинской профилактики до облегчения труда через усиление возможностей интеллекта. Вот далеко не полный перечень известных “противоядий”: гигиена умственной деятельности, рациональная организация труда, повышение интеллектуальной культуры специалистов [2], стимулирование научного творчества [3], использование возможностей интуиции, совершенствование интеллектуальных способностей [4], различные теории развития интеллекта, например [5], концепция гибридного интеллекта [6] и множество частных методик, таких, как ТРИЗ (теория решения изобретательских задач) [7], динамическая техника силы ума [8] и т. д. Хотя существующие средства, теории и инструменты несомненно являются полезным и порою весьма эффективным лекарством, тем не менее, к сожалению, они не соответствуют глобальному масштабу и нарастающей значимости проблемы.

К чему это приводит? Не справляясь с неуклонным ростом сложности цивилизационных процессов, которая существенно превышает наличные интеллектуальные возможности человечества, последнее вынуждено компенсировать слабость и нехватку интеллектуальных инструментов за счет нервного перенапряжения (читай — истощения!) и увеличения длительности рабочего дня добровольных и вынужденных трудоголиков. При этом за кадром общественного внимания, телевидения и средств массовой информации остается тот факт, что интеллектуальные работники зачастую превращаются в интеллектуальных камикадзе, которых общество приносит в жертву жестокому и коварному Молоху интеллектуального прогресса.

Известный математик Герман Вейль подчеркивает: недопустимо, когда трансцендентное господствует над человеком, превращая его всего лишь в рупор интеллектуального откровения. И делает вывод: хотя наука — высокая объективная ценность, одновременно она — “ветвь человеческой деятельности, ради которой нельзя приносить в жертву самое жизнь” [9].

ЧТО ТАКОЕ ИНТЕЛЛЕКТУАЛЬНЫЙ
ТЕРРОРИЗМ?

— Виновен ли профессор математики геттингенского университета Давид Гильберт в гибели своих учеников?

— Нет.

— Хотел ли он их смерти?

— Нелепый вопрос. Конечно, нет.

— В таком случае, что явилось причиной самоубийства?

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

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

ГУМАНИТАРНАЯ
ПОСТАНОВКА ЗАДАЧИ

Можно ли повысить качество решений сложных и сверхсложных интеллектуальных проблем, необходимых для развития цивилизации, и одновременно защитить людей от опасных для здоровья умственных перегрузок? Как облегчить и улучшить работу человеческого ума? Увеличить продуктивность творческого мышления? Преобразовать трудные и непосильные задачи в легкие и посильные? Словом, превратить интеллектуальные муки-мученические во что-нибудь более достойное человека и даже приятное? Можно ли решить эту “сверхзадачу” хотя бы в принципе?

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

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

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

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

Однако нынешняя наука не может не калечить — так уж она устроена. Почему? В частности потому, что на протяжении всей истории ее развития создатели научных теорий и методов ставили перед собой какие угодно цели и задачи, но только не задачу эффективной защиты человека от интеллектуальных перегрузок. По этой причине человеческий мозг, этот хрупкий сосуд разума, сталкиваясь с демоном науки, оказывается в крайне уязвимом положении — не выдерживая запредельной нагрузки, он получает вызванные стрессом многочисленные травмы.

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

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

КОМПЬЮТЕРНАЯ МИФОЛОГИЯ:
ОБЛЕГЧАЮТ ЛИ
КОМПЬЮТЕРЫ УМСТВЕННЫЙ ТРУД?

Чтобы избежать опасных для здоровья перегрузок, надо уменьшить  интеллектуальную нагрузку на человеческий мозг. С другой стороны, развитие цивилизации приводит к усложнению интеллектуальных задач и непрерывному увеличению их количества, что предъявляет к мозгу постоянно растущие требования. Как разрешить это противоречие? Можно ли выполнить два противоположных требования — облегчить работу мозга и одновременно увеличить его умственную продуктивность?

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

Все больше исследователей приходят к выводу, что применение компьютеров во многих случаях не только не упрощает, а наоборот, резко усложняет интеллектуальные задачи, которые остаются на долю человека. Например, Эдсгер Дейкстра пишет о “неисчерпаемой” и “беспрецедентной” сложности задач, которые приходится решать программистам. Психолог М. Ярошевский отмечает: “Успехи кибернетики, все расширяющиеся перспективы передачи техническим устройствам поддающихся формализации умственных операций, которые раньше поглощали значительную часть интеллектуальных усилий ученого, резко повышают требования к формированию его способностей производить такие действия, которые не могут совершаться компьютерами” [10]. Большинство ученых признает, что информационная технология — самая сложная из всех известных технологий, а некоторые даже утверждают, что использование компьютеров приводит к усилению эксплуатации нервной энергии трудящихся и в ряде случаев “отрицательно влияет на развитие мыслительных процессов” [11].

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

ЧТО ТАКОЕ ИНТЕНСИФИКАЦИЯ ИНТЕЛЛЕКТА?

На наш взгляд, для решения поставленной задачи следует перейти от экстенсивной умственной деятельности к интенсивной. Поясним термины. Деятельность называется экстенсивной, если скорость, с которой мозг решает задачи, предполагается относительно неизменной, а выполнение сложной работы в сжатые сроки достигается за счет уплотнения рабочего времени и удлинения рабочего дня. Это означает, что человек работает на износ — по 12, 16 или 20 часов в сутки, причем перерывы для отдыха сокращаются почти до нуля (“бутерброд перехватить некогда!”). Если сотрудник, действуя в таком режиме, выполняет работу досрочно и с высоким качеством, его называют интеллектуальным героем и ставят в пример: он сделал невозможное! При этом считается хорошим тоном стыдливо умалчивать о том, насколько подобная работа приблизила нашего героя к больнице или могиле.

При интенсивной умственной деятельности своевременное окончание задания достигается не за счет подобных варварских методов, а за счет увеличения скорости работы мозга. Интенсификация интеллекта — совокупность интеллектуальных приемов и средств, изменяющих режим функционирования человеческого мозга в благоприятном направлении, чтобы использовать его возможности “на полную проектную мощность”. Указанные средства специально конструируются таким образом, чтобы одновременно улучшить работу ума за счет повышения продуктивности мозга и облегчить умственный труд путем минимизации интеллектуальных затрат на единицу получаемых интеллектуальных результатов.

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

КРИТЕРИЙ ДЕКАРТА И ЭРГОНОМИЗАЦИЯ НАУКИ

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

Сопоставляя мысли Декарта с идеями предшественников, В. Катасонов подчеркивает: «Вдохновляясь мечтой францисканского миссионера XIII в. Р. Луллия о “великом искусстве”, которое могло бы автоматизировать процесс мышления, многие мыслители заняты поисками удобной знаковой системы, универсального алгоритма, позволившего бы “без излишней траты умственных сил” решить все возможные проблемы. Само создание алгебры в XVI—XVII вв. представляется даже как бы лишь побочным продуктом этой титанической “супер-идеи”» [13].

В отличие от Катасонова титанической суперидеей мы склонны считать не всеобщую математику Декарта или универсальную характеристику Лейбница, проложившие путь к созданию современной математической логики, а скорее их интеллектуальную квинтэссенцию, энергетический сгусток, мощное ядро, инициировавшее многие великие идеи и открытия, подобно тому, как во время Большого Взрыва вся наша грандиозная вселенная родилась из первичного сверхплотного ядра.

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

Вспомним рассуждения Декарта. Он начинает с утверждения, что в основании всех наук лежит одна и та же тождественная себе человеческая мудрость, относящаяся к разным наукам, как солнце к различным освещаемым предметам. Для познания, следовательно, было бы гораздо полезнее, чем искать “многознания” в науках, обратиться к исследованию законов самой этой мудрости. На этом пути Декарт формулирует основные положения своего метода [12].

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

О ЧЕМ ЭТА КНИГА?

Повторим вопрос: можно ли улучшить работу ума и одновременно облегчить деятельность мозга, чтобы интеллектуальная работа выполнялась без ущерба для здоровья? На первых порах нет необходимости решать эту сверхсложную проблему в общем виде. Вполне достаточно продемонстрировать существование эффективного решения хотя бы для некоторых значимых частных случаев. Подобный прием покажет, что проблема не безнадежна, что она в принципе поддается решению. А раз так, появляется обоснованная надежда на то, что, действуя по аналогии, можно искать решение и для других случаев.

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

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


Язык ДРАКОН — общедоступный интеллектуальный инструмент нового типа, специально сконструированный для облегчения и улучшения работы ума интеллектуальных работников и учащихся, особенно полезный при решении трудных и сверхтрудных задач систематизации и автоформализации профессиональных знаний, описания структуры человеческой деятельности и многих других задач, о которых речь впереди.

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

СЕКРЕТЫ МУДРОГО ДРАКОНА:
ОБЪЯСНЕНИЕ НА ПАЛЬЦАХ

Некоторые идеи, связанные с языком ДРАКОН, необычны. Их очень трудно изложить кратко, понятно и вместе с тем строго научно. Чтобы избавить читателя от утомительных длиннот и громоздких объяснений, этот параграф написан в форме забавного диалога.

Автор. Не правда ли, выполняемая вами работа очень сложна и требует больших умственных усилий? Так вот, если изобразить вашу работу на языке ДРАКОН, наблюдается следующий неожиданный эффект. Хорошо знакомая задача на глазах преображается и предстает перед вашим изумленным взором в совершенно новом свете — она резко упрощается и становится ясной, четкой и обозримой. То, что выглядело сложным и запутанным, оказывается прозрачным и очевидным. Смутное — отчетливым. Абстрактное — наглядным. А прежде скрытые ошибки видны, как на ладони.

Читатель. Но ведь чудес не бывает! За счет чего это достигается?

Автор. За счет использования более эффективных (более ДРУЖЕЛЮБНЫХ по отношению к человеку) образных средств представления профессиональных знаний, проектов и документации.

Читатель. Наверно, это очень трудно?

Автор. Как раз наоборот. Язык наглядных образов — самый легкий язык. Девиз ДРАКОНА: взглянул — и сразу стало ясно!

Читатель. Но ведь языков и так расплодилось великое множество. Зачем создавать еще один?

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

Притча о том, как Господь Бог языки создавал

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

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

— А как же остальные? — удивились референты и апостолы. — Ведь им тоже нужны свои языки.

— Какие такие остальные?

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

— Зачем им свои языки? Пусть пользуются языками программирования.

— Да они их не знают.

— Что значит не знают. Пускай выучат.

Наступило неловкое молчание. Наконец, апостол Павел дипломатично произнес:

— Ваше Божественное Всемогущество! Поскольку Вы сами создали все языки, для Вас выучить язык программирования — раз плюнуть. Но человек слаб.

— Это верно, он слаб, — подтвердил Господь.

— Поэтому для среднего работника умственного труда (не программиста), у которого своих забот выше крыши, разобраться в тонкостях программирования довольно трудно.

— Трудности можно преодолеть.

— Можно-то оно можно. Так ведь душа не лежит, потому как — противно, а главное — зачем? Нельзя же насильно заставлять человека учить то, что ему не нужно для работы. Для большинства людей язык программирования — это “собачий” язык, а написанные на нем программы — странная окрошка из египетских иероглифов. Они непонятны никому, кроме горстки их создателей.

— Что вы такое говорите! — возмутился Господь. — Сразу видно, что вы отстали от жизни. Академик Ершов учит, что “программирование — вторая грамотность”. Нынче даже школьники программы освоили. А студенты их, как орехи, щелкают. Запомните: программирование должны знать все! Это и будет общий язык для взаимопонимания между специалистами. И никаких других языков не нужно. Все. Совещание окончено. Выполняйте!

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

Читатель. Так, может, этим специалистам и не нужны никакие языки?

Автор. Это не так. Язык — интеллектуальное оружие специалиста. Чем лучше язык, тем лучше работает мозг, тем выше производительность умственного труда.

Читатель. Как же быть?

Автор. Прежде всего следует признать, что при выборе генерального направления разработки искусственных языков допущена стратегическая ошибка. Нынешняя ситуация, когда 90% специалистов не имеют языка, пригодного для быстрого и эффективного решения своих задач, является ненормальной и неприемлемой.

Читатель. Где же выход?

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

Смена терминов
или изменение концепции?

Читатель. Стало быть, ДРАКОН — это не язык программирования, а что-то новенькое. Как же прикажете его величать?

Автор. Назвать можно как угодно. Например, “технологический язык”, сокращенно “техноязык”.

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

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

Читатель. Все равно непонятно.

Автор. Рассмотрим пример. Химик написал формулу

HCl + NaOH = NaCl + H2O

Какой язык здесь использован? Ясно, что это не язык программирования, а язык химических формул. Последний является “родным” языком химиков и помогает им успешно справляться со своими проблемами. Правда, этот язык не общий, а частный: он позволяет решать не все задачи, волнующие химиков, а только некоторые. А за рамками химии он вообще почти никому не интересен. В отличие от него техноязык — это универсальный язык, пригодный для широкого класса задач практически в любых областях человеческой деятельности.

Самая сложная вещь на свете

Читатель. Что значит “в любых областях деятельности”? Что общего между деятельностью врача и конструктора, финансиста и агронома, металлурга и микробиолога?

Автор. Общее то, что все они работают, т. е. занимаются деятельностью. Человеческая деятельность — самая сложная вещь на свете.

Читатель. Что в ней такого уж сложного?

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

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

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

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

Кстати, программирование — это тоже деятельность. Поэтому техноязык можно использовать как язык программирования (обратное неверно).

Читатель. Ага, так значит ДРАКОН — это все-таки язык программирования!

Автор. Послушайте, вы, по-моему, нарочно хотите поссорить меня с теми, ради кого написана эта книга. Надо же учитывать человеческую психологию! Если я скажу, что ДРАКОН — язык программирования, немалая часть потенциальных читателей тут же отшвырнет ее со словами: “Это для программистов, мне это не нужно!” Их можно понять, потому что сам термин “язык программирования” для многих уже давно превратился в красную тряпку, в ненавистное пугало.

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

Зачем ДРАКОНУ две головы?

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

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

Читатель. Стало быть, вы хотите угодить и нашим, и вашим?

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

СПРАВКА О СОСТОЯНИИ ДЕЛ

Язык ДРАКОН разработан совместными усилиями Российского космического агентства (НПЦ автоматики и приборостроения, г. Москва) и Российской академии наук (Институт прикладной математики им. М.В. Келдыша, г. Москва) как обобщение опыта работ по созданию космического корабля “Буран”. На базе ДРАКОНА построена автоматизированная технология проектирования программных систем (CASE-технология) под названием “ГРАФИТ-ФЛОКС”. Она успешно используется в ряде крупных космических проектов: “Морской старт”, “Фрегат”, “Протон-М” и др.

ДРАКОН — очень легкий язык. Настолько легкий, что разработку многих компьютерных программ для космических ракет на практике ведут не программисты, а обычные специалисты — по принципу “программирование без программистов”. Причина отказа от программистов проста. При решении практических прикладных задач специалисты досконально владеют материалом и прекрасно знают постановку задачи. В отличие от них программисты не знают “физику процесса” и становятся “лишними людьми”, без которых вполне можно обойтись. Это позволяет значительно сократить издержки, улучшить показатель “затраты—результат”, ускорить ход работ и полностью избавиться от ошибок “испорченного телефона”, вызванных взаимным непониманием между ПРОГРАММИСТАМИ и СПЕЦИАЛИСТАМИ.

ДРАКОН универсален. Он может применяться для наглядного представления и быстрой разработки алгоритмов не только в “космосе”, но и в “земных” видах человеческой деятельности. Практическая полезность ДРАКОНА получила высокую оценку. Министерство образования включило изучение языка ДРАКОН в программу курса информатики высшей школы (см.: Примерная программа дисциплины “Информатика”. Издание официальное. — М.: Госкомвуз, 1996. С. 3, 4, 15, 16).

Ведется подготовка учебных книг для средней и высшей школы. Уже издана первая из них — игровое учебное пособие для детей младшего и среднего школьного возраста:


Г Л А В А  1

НА ПОДСТУПАХ К НОВОМУ ЯЗЫКУ

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

Джордж Паджет Томсон

ЗАЧЕМ НУЖЕН ЯЗЫК ДРАКОН?

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

Хотя ДРАКОН внешне очень напоминает обычные блок-схемы алгоритмов и программ, фактически он является оригинальной разработкой. Наиболее близким функциональным аналогом ДРАКОНА следует считать схемы действий (action diagrams) [1–4] и схемы деятельности (activity diagrams) [5].

Для дотошных читателей, которые любят подробности, аналогами ДРАКОНА — в той или иной степени — можно назвать и более дальних “родственников”. К их числу относятся: диаграммы Несси—Шнейдермана [6], HOS-схемы [1], схемы “гринпринт” [7], SPD-диаграммы фирмы NEC [8], PAD-схемы фирмы Хитачи [8], деревья и таблицы решений, схемы декомпозиции [4], схемы зависимости [1], язык SDL и
его производные, систему
BLS, созданную А. Смоляниновым из Санкт-Петербургского электротехнического университета, R-схемы И. Вельбицкого, -схемы В. Прохорова и т. д.


В ЧЕМ СЕКРЕТ ДРАКОНА? — В КОГНИТИВНОМ ПОДХОДЕ

Впрочем, сравнение с аналогами в данном случае малопродуктивно, так как оно не позволяет раскрыть наиболее существенную особенность ДРАКОНА, которая называется “когнитивный подход” [9]. Термин “когнитивный” (познавательный) пока еще не получил широкого распространения среди проектировщиков, разработчиков, инженеров и программистов, однако он является тайным паролем нового могущественного научного ордена, вернее сказать, знаменем двух новых, бурно развивающихся направлений в психологии и науке об интеллекте, известных как когнитивная психология и когнитивная наука2.

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

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

Под когнитивным фактором в данной книге понимаются познавательные, интеллектуальные, мыслительные, творческие аспекты деятельности ученых, специалистов и учащихся. Чем сложнее объект технического и социального проектирования, тем важнее делать акцент на необходимости тщательного учета когнитивных характеристик деятельности людей. Академик П. Симонов подчеркивает: для разработчиков систем “чрезвычайно важно знание правил, следуя которым живой мозг воспринимает, обрабатывает, фиксирует и использует вновь полученную информацию. Сведения о таких правилах, выявленных в эксперименте, поставляет когнитивная психология” [11].

Использование названных правил позволяет получить практический результат — повысить производительность умственного труда.

ПОЧЕМУ ЛЮДИ НЕ ИНТЕРЕСУЮТСЯ
СОБСТВЕННЫМ МОЗГОМ?

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

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

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

Наука о человеческих факторах называется эргономикой. Когнитивные проблемы — важная часть эргономики. Чтобы вычленить когнитивную группу среди других эргономических вопросов, иногда употребляют термины “когнитивная эргономика” и “когнитивно-эргономические проблемы”.


СТАНЕТ ЛИ ДРАКОН ЧЕМПИОНОМ МИРА
ПО КРИТЕРИЮ “ПОНИМАЕМОСТЬ АЛГОРИТМОВ”?

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

Как и все прочие языки, ДРАКОН опирается на математику и логику. Однако сверх того, он самым тщательным образом учитывает когнитивные вопросы. Благодаря систематическому использованию когнитивно-эргономических методов ДРАКОН приобрел уникальные эргономические характеристики. Можно предположить, что в будущем ДРАКОН сможет претендовать на звание чемпиона по критерию “понимаемость алгоритмов и программ” (в классе императивных языков)3.

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

Человечность языка ДРАКОН, стремление создать максимальный комфорт для работы человеческого мозга, всемерная забота о повышении творческой продуктивности персонала позволяет надеяться, что ДРАКОН получит самое широкое применение в народном хозяйстве, бизнесе, обороне, науке и системе образования. Используя не просто наглядные, а предельно наглядные формы представления знаний, облегчая работу мозга, ДРАКОН обеспечивает заметный рост производительности интеллектуального труда.

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

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

НА КОГО РАССЧИТАН ЯЗЫК ДРАКОН?

Язык в равной степени рассчитан на четыре категории лиц:

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

ПЕРЕЧЕНЬ ЗАДАЧ, РЕШАЕМЫХ С ПОМОЩЬЮ
ЯЗЫКА ДРАКОН

Язык ДРАКОН может быть использован при решении следующих задач:

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

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

  •  стратегический обзор функций корпораций (strategic overview of corporate functions);
  •  описание логических отношений между процессами (logical relationship among processes);
  •  описание укрупненной структуры программ (overall program structure);
  •  описание детальной логики программ (detailed program logic) [1];
  •  полная декомпозиция программ (ultimate decomposition), начиная от укрупненной логики и кончая деталями кода, что в равной мере полезно при проектировании как сверху вниз (top-down design), так и снизу вверх (bottom-up design) [4];
  •  проектирование программ до последнего момента может вестись независимо от языка и лишь на последнем этапе осуществляется переход к нужному языку [1];
  •  обучение конечных пользователей, стимулирующее их анализировать и проектировать детальную логику процессов (detailed process logic) [1];
  •  описание процедур организационного управления (management procedures) [4];
  •  описание компьютерных методологий (computer methodologies) [4];
  •  описание методологий информационной техники (methodologies of information engineering) [4].

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

ВЫВОДЫ

1. Традиционные цели и методы создания искусственных языков, в частности языков программирования, следует признать во многом устаревшими.

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

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

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


Г Л А В А  2

МОЖНО ЛИ СОЗДАТЬ ЯЗЫК,
УЛУЧШАЮЩИЙ
ПОНИМАНИЕ И ВЗАИМОПОНИМАНИЕ?

— ...Скажите, отчего разбрелись все ученые в разные стороны и каждый говорит языком, которого другой не понимает? Отчего мы все изучили, все описали и почти ничего не знаем?

— Извините, это не мой предмет, я только собираю факты — я статистик.

Владимир Одоевский

ПОЧЕМУ СПЕЦИАЛИСТЫ НЕ ПОНИМАЮТ
ДРУГ ДРУГА?

В 1880 г. баварский ксендз Иоган Шлейер, стремясь улучшить взаимопонимание между людьми, придумал язык “воляпюк” (искаж. от world speak, что значит “всемирный язык”). Чуть позже варшавский врач Земенгоф изобрел эсперанто. Хотя эти проекты всемирных языков
не оправдали надежд, однако они сыграли положительную роль, ибо приковали внимание к назревающей проблеме — созданию искусственных языков.

Сегодня, когда число искусственных языков программирования перевалило за три тысячи, проблема взаимопонимания между людьми почти так же далека от решения, как и во времена Шлейера и Земенгофа. Да, действительно, языки Бейсик, Паскаль, Си, Си++, Ява и многие другие давно стали всемирными языками. Однако популярность языков вовсе не говорит о том, что написанные на них программы
понятны всем, кому это нужно. Многие программисты жалуются, что свою собственную программу они с трудом понимают через полгода,
а то и через месяц. А если речь идет о чужой программе? Тогда становится совсем тяжко. Нередко бывает легче написать свою программу, нежели разобраться в том, что делает чужая. Поэтому среди требований, предъявляемых к современным алгоритмическим языкам, на первое место все чаще выходит
понимаемость программ (comprehensibility), которая определяется как свойство программы минимизировать интеллектуальные усилия, необходимые для ее понимания.

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

ЯЗЫК ДРАКОН КАК “ЭСПЕРАНТО”
ДЕЛОВОГО МИРА

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

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

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

ЧТО ТАКОЕ ИНТЕЛЛЕКТУАЛЬНОЕ
ВЗАИМОПОНИМАНИЕ?

При разработке сложных проектов (таких, как космический корабль “Буран”, атомная электростанция или химический завод), при проведении сложных исследований (например, в теоретической физике, биологии, медицине), при решении других, более простых задач (например, при программировании) нередко возникает вопрос: как добиться взаимопонимания между соисполнителями работ? Трудность в том, что каждый исследователь и разработчик, каждый участник общего дела хорошо знает лишь свой собственный, относительно небольшой (по размерам), хотя и весьма сложный (по глубине идей) участок работы и довольно смутно представляет, что творится у соседей. Отсюда взаимные недоразумения, неувязки и ошибки на стыках. Логично спросить: в чем причина неприятностей? Не слишком ли большие ресурсы (людские, материальные, финансовые и временне) приходится затрачивать для обеспечения эффективного взаимодействия между специалистами, участвующими в совместной работе? Почему крупные исследования и разработки нередко затягиваются на месяцы, а то и на годы?

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

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

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

В ЧЕМ ОСОБЕННОСТЬ ДРАКОНА?

Недостаток традиционного подхода состоит в том, что создатели языков и компьютерных систем, как подчеркивает психолог Дональд Норман, “слишком часто начинают с машины, а о человеке думают только
в конце, когда уже поздно”. Чтобы избежать подобных ошибок, в ходе разработки языка
ДРАКОН был выбран совершенно иной подход. Была объявлена стратегическая цель: создать наиболее комфортные условия для работы человеческого интеллекта, обеспечить наилучшие возможности для повышения эффективности коллективного разума специалистов.

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

ВЫВОДЫ

При создании языка ДРАКОН были выдвинуты следующие гуманитарные требования.

1. Улучшить работу человеческого ума.

2. Предложить эффективные средства для описания структуры деятельности.

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

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

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

6. За счет использования когнитивно-эргономического подхода к проектированию синтаксиса и семантики добиться кардинального улучшения качества программного обеспечения по критерию “понимаемость программ”.


Г Л А В А  3

Соображения,
повлиявшие на создание
языка ДРАКОН

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

Поль Страссман

ЧТО ВАЖНЕЕ:
КОМПЬЮТЕРЫ ИЛИ ЧЕЛОВЕЧЕСКИЙ МОЗГ?

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

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

Чтобы избежать неприятностей, необходимо четко разграничить три понятия:

  •  интегральную производительность системы “персонал—компьютеры”;
  •  производительность компьютеров;
  •  производительность собственно персонала, т. е. человеческого мозга.

Сказанное позволяет сформулировать тезис. Интегральная производительность систем “персонал—компьютеры” зависит от двух независимых показателей: производительности компьютеров и продуктивности мозга. Первая быстро растет, вторая, наоборот, все больше отстает от растущих требований и нередко превращается в основной тормоз повышения эффективности организаций.

Почему растет производительность компьютеров? За счет роста их быстродействия и объема памяти, повышения эффективности программ и передачи им все новых функций. Однако все эти причины не оказывают ровным счетом никакого влияния на скорость работы человеческого мозга, так как последняя не зависит ни от мощности компьютеров, ни от степени автоматизации. Именно здесь коренится одна  из основных причин многочисленных неудач, связанных с непродуманными попытками поднять интеллектуальную производительность персонала.

ЧТО ТАКОЕ ПРОИЗВОДИТЕЛЬНОСТЬ
УМСТВЕННОГО ТРУДА?

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

Уже давно признано, что узким местом стали не столько вычислительные, сколько человеческие ресурсы, поэтому задача экономии человеческих, а не машинных ресурсов стала центральной для технологии программирования. Нетрудно сообразить, что этот вывод выходит далеко за рамки программирования и имеет всеобщий характер, охватывая самые разнообразные типы сложного интеллектуального труда. Начиная с некоторого предела дальнейшее наращивание интеллектуальной мощи компьютеров, программ и сетей будет бессмысленным, если человеческий мозг окажется не в состоянии перерабатывать поступающую к нему информацию. Это означает, что уже в первые десятилетия XXI в. недостаточная продуктивность человеческого мозга станет основным фактором, ограничивающим возможность наращивания умственной мощи человеческих институтов и сдерживающим интеллектуальный прогресс цивилизации.

Учитывая вышеизложенное, необходимо устранить двусмысленность выражения “производительность умственного труда”, исключить возможность ложных трактовок и дать предельно ясное и четкое определение этого важнейшего понятия. По мнению автора, наилучший путь состоит в том, чтобы ограничить неоправданно широкий объем понятия и трактовать его в узком смысле как повышение продуктивности мозга.

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

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

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

ЗАВИСИТ ЛИ
ПРОИЗВОДИТЕЛЬНОСТЬ ПЕРСОНАЛА
ОТ ПРОИЗВОДИТЕЛЬНОСТИ КОМПЬЮТЕРОВ?

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

Понятно, что скорость человеческого мышления (понимаемая как скорость работы человеческого мозга при решении тех или иных производственных заданий) не зависит ни от быстродействия компьютеров, ни от объема компьютерной памяти и определяется совсем другими причинами. Какими же?

Если учесть, что при работе с компьютером свыше 99% информации человек получает с помощью зрения, то наиболее важным видом компьютерной информации (с точки зрения человеческого восприятия) является письменная, т. е. “впитываемая глазами” информация, которая определенным образом взаимодействует с мозгом и оказывает значительное влияние на его работу. В чем заключается это влияние? Зависит ли продуктивность мозга от качества поступающей в него информации? По-видимому, да. Можно предположить, что время решения человеческим мозгом интеллектуальных задач зависит от скорости восприятия, понимания и усвоения поступающих в мозг сообщений, а последняя — от наглядности, доходчивости, смысловой полноты и других полезных свойств информационного материала, который должен точно и наглядно отражать сущность вопроса, постановку задачи и ход ее решения. Если любая (в том числе самая сложная) информация будет предъявляться по принципу “взглянул — и сразу стало ясно”, если благодаря удачной форме подачи материала каждый работник быстро вникнет в суть дела и за короткое время выполнит задание, интеллектуальная производительность персонала, несомненно, будет высокой.

МОЖНО ЛИ УВЕЛИЧИТЬ СКОРОСТЬ РАБОТЫ
ЧЕЛОВЕЧЕСКОГО МОЗГА?

Каким образом можно повысить продуктивность мозга? Ответ поясним на примерах. Замена языка римских чисел на язык арабских чисел дала возможность резко увеличить производительность труда при выполнении арифметических действий. Как отмечает Дэвид Марр, “это главная причина того, почему римская культура не смогла развить математику так, как это сделали ранние арабские культуры”.

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

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

Многие авторы подчеркивают, что выбор эффективного языка может оказать благотворное влияние на продуктивность мышления. Например, Эрнст Шредер пишет, что употребление удачных знаков позволяет значительно усилить человеческое мышление. Неудачные знаки оказывают тормозящее влияние на мышление. Знаки нужны не только для передачи другим наших мыслей, но и для формирования самих мыслей. Неудачные языки даже простую проблему способны сделать неразрешимой. И наоборот, задача, получившая удобное знаковое выражение, оказывается наполовину решенной [4].

Особенно удачными оказываются новейшие визуальные языки, которые можно охарактеризовать как эффективные методы графического представления знаний, позволяющие выявить скрытые резервы повышения продуктивности двухполушарного мозга. Джеймс Мартин и Карма Мак-Клюр отмечают: хорошие, ясные изображения играют важную роль при проектировании сложных систем и разработке программ. Наша способность мыслить зависит от языка, который мы используем для мышления. Изображения, с помощью которых мы описываем сложные процессы, являются формой языка. Подходящие изображения помогают нам визуализировать и изобретать указанные процессы. Неудачный выбор изображений может ухудшить мышление. И наоборот, применение хороших изображений может ускорить работу и улучшить качество результатов [5].

Сказанное позволяет выдвинуть следующую рабочую гипотезу: чтобы улучшить работу ума, повысить продуктивность человеческого мозга при решении интеллектуальных производственных заданий, необходимо улучшить когнитивные характеристики профессионального языка, используемого при выполнении интеллектуальной работы. Эта гипотеза положена в основу разработки языка ДРАКОН. Обоснование гипотезы можно найти в [6].


ПРОБЛЕМА ФОРМАЛИЗАЦИИ
ПРОФЕССИОНАЛЬНЫХ ЗНАНИЙ

С появлением миллионов персональных компьютеров доступ к вычислительной технике помимо профессиональных программистов получили две большие группы непрограммирующих пользователей. Первую группу составляют люди относительно низкой и средней квалификации: секретари, клерки, лаборанты, кассиры и другие технические работники. Во вторую группу входят высококвалифицированные специалисты народного хозяйства и социальной сферы: ученые, конструкторы, технологи, экономисты, юристы и т. д.

С другой стороны, большая часть компьютерного парка планеты до сих пор используется для решения сравнительно простых задач. Например, в качестве пишущей машинки при оформлении документации и редактировании текстов, в режиме электронного карандаша при рисовании чертежей, диаграмм и картинок, для ввода, поиска, сортировки и пересылки информации и т. д. Хотя названные услуги несомненно полезны и экономят немало времени, они почти совсем не касаются одной из наиболее важных проблем: профессиональных знаний и умений высококвалифицированных специалистов, т. е. содержательной, творческой стороны решаемых ими сложнейших профессиональных задач.

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

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

Традиционное компьютерное программирование иногда рассматривают как частный случай формализации знаний. Бытует мнение, что программисты лучше других умеют формализовать свои знания. Это не совсем так. Значительная часть знаний не попадает в текст программы, оставаясь в голове программиста. Как отмечает академик А. Ершов, “язык программирования кодирует объекты предметной области задачи, а наше знание об этих объектах остается за пределами программного текста” [7]. Именно поэтому понять сложную программу в отсутствие ее автора очень трудно или даже невозможно. Приходится признать, что известные методы формализации несовершенны и нуждаются в серьезном обновлении.

МОЖНО ЛИ
ОБОЙТИСЬ БЕЗ КОГНИТОЛОГОВ?

Существуют две точки зрения на проблему формализации. Согласно одной из них специалист, обладающий профессиональными знаниями (обычно его называют “эксперт”), не в состоянии самостоятельно, без посторонней помощи формализовать свои знания, так как задача формализации слишком трудна. Представитель этого направления Э. Фейгенбаум подчеркивает: “По опыту нам известно, что большая часть знаний в конкретной предметной области остается личной собственностью специалиста. И это происходит не потому, что он не хочет разглашать свои секреты, а потому, что он не в состоянии сделать этого — ведь специалист знает гораздо больше, чем сам осознает”. Утрируя, можно сказать, что согласно этой позиции эксперт отчасти напоминает собаку: глаза умные, а сказать (на формальном языке) ничего не может. Отсюда делается вывод, что для решения задачи формализации необходимы особые помощники — инженеры по знаниям (когнитологи), которые, действуя по специальной методике, интервьюируют эксперта, формализуют “извлеченные” из него знания и вводят их в компьютер.

Иную позицию занимает Г. Громов, полагающий, что эксперт должен формализовать свои знания самостоятельно, без помощи инженеров по знаниям и профессиональных программистов, точнее говоря, при их “минимальной технической поддержке”. Данный метод называется “автоформализация знаний” [8]4.

Автоформализация полезна тем, что позволяет устранить ненужных посредников и избежать ошибок типа “испорченный телефон”. Здесь однако возникает вопрос. А сможет ли эксперт формализовать свои знания? Не окажется ли задача непосильной для него?

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


ЧЕМ ОТЛИЧАЕТСЯ АЛГОРИТМ
ОТ ТЕХНОЛОГИЧЕСКОГО ПРОЦЕССА?

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

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

Алгоритм — конечный набор предписаний, определяющий решение задачи посредством конечного количества операций [9]. Технологический процесс — совокупность приемов и способов получения, обработки или переработки сырья, материалов, полуфабрикатов или изделий, осуществляемых в промышленности, строительстве, сельском хозяйстве и других отраслях [10]. Поверхностный анализ этих определений может привести к ложному выводу, что алгоритмы и технологические процессы не имеют ничего общего. Однако в действительности это не так.

Известно, что термин “алгоритм” используется и в более широком смысле для представления человеческой деятельности в виде строгой последовательности отдельных элементарных действий или процедур [11], а технологический процесс можно определить как “последовательность направленных на создание заданного объекта действий (технологических операций), каждое из которых основано на каких-либо естественных процессах (физических, химических, биологических и др.) и человеческой деятельности” [11]. Тщательный анализ этих и многих других определений показывает, что исследуемые понятия в значительной степени совпадают, а имеющиеся различия в определенном смысле несущественны. Иными словами, технологический процесс и алгоритм — это понятия-близнецы или во всяком случае “близкие родственники”. Чтобы сделать эту мысль более убедительной, попытаемся отойти от традиционной точки зрения и предложим новые определения.

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

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

ЧТО ТАКОЕ ТЕХНОЛОГИЧЕСКИЙ ЯЗЫК?

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

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

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

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

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

Мысль о возможности и целесообразности создания универсального технологического языка опирается, в частности, на следующие предпосылки. Девяносто процентов специалистов, занятых в народном хозяйстве, не умеют программировать. Между тем эти люди успешно решают стоящие перед ними задачи. Значит, они обладают знаниями о последовательности действий, необходимых для решения своих задач. Указанные знания можно назвать технологическими (императивными, процедурными, алгоритмическими). Таким образом, налицо любопытная ситуация: подавляющее большинство специалистов народного хозяйства обладают технологическими знаниями, но не умеют их точно выразить (алгоритмизировать), поскольку в настоящее время отсутствует легкий и удобный язык, рассчитанный на непрограммистов и предназначенный для алгоритмизации (формализации) знаний.

ТЕХНОЛОГИЧЕСКИЕ
И ДЕКЛАРАТИВНЫЕ ЗНАНИЯ

Человеческие знания, выраженные с помощью любого письменного языка, можно разбить на две части: технологические5 и декларативные.

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

Декларативные (дескриптивные, атрибутивные, описательные) — это знания не о действиях, а об описаниях информационных и физических объектов. Примером является типичная запись в базе данных:

Фамилия

Имя

Отчество

Год
рождения

Образование

Должность

Семейное
положение

Иванов

Сергей

Петрович

1970

высшее

менеджер

женат

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

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

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

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

Во-первых, создаются благоприятные предпосылки для построения универсального технологического языка, позволяющего выражать любые технологические знания в любой предметной области в ЕДИНОЙ СТАНДАРТНОЙ ФОРМЕ.

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

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

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

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

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

ПОЧЕМУ НЕЛЬЗЯ ЖИТЬ ПО-СТАРОМУ?

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

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

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

СОЦИАЛЬНЫЕ ТЕХНОЛОГИИ
И ЭЛЕКТРОННЫЕ МЕТОДОЛОГИИ

Информационные технологии — не самоцель, а средство для улучшения промышленных и социальных технологий. Социальные технологии — новое и многообещающее направление [14,15], нацеленное на повышение эффективности взаимодействия людей, групп, организаций и государств (как в локальном, так и в глобальном масштабе). Неумение проектировать эффективные социальные технологии — это, пожалуй, главная причина нынешних бед цивилизации. Поэтому крайне важно научиться использовать огромный опыт человечества, накопленный при создании технических технологий для проектирования технологий социальных.

На повестке дня остро стоит вопрос о разработке нового поколения социальных технологий, способных вывести планету из нынешнего цивилизационного тупика. Это грандиозная по сложности задача. Необходимо превратить всемирную армию политиков, чиновников и специалистов (от низовых работников до руководителей государств) в профессиональных социальных технологов и социальных конструкторов, вооруженных всем богатством социально-гуманитарных и иных знаний и методов. Впрочем, это дело будущего. Сегодня делаются лишь первые шаги по совершенствованию отдельных частных аспектов социальных технологий. Одним из них является чрезвычайно интересная группа идей и подходов, направленных на качественное улучшение эффективности организаций, для обозначения которых используются выражения: “реинжиниринг бизнес-процессов”, “управление процессами”, “электронные методологии”7. Примеры методологий: RAD, IDEF и др. Мы ограничимся кратким знакомством с первой из них.

МЕТОДОЛОГИЯ БЫСТРОЙ РАЗРАБОТКИ
СИСТЕМ
RAD

Методология RAD (Rapid Application Development) служит для разработки (при активном участии пользователей) относительно небольших, но довольно сложных коммерческих информационных систем для бизнес-приложений, обеспечивающих (в этом вся суть) качественный рост эффективности организаций. Работа выполняется одним человеком или командой (до шести человек) за срок от трех до шести месяцев по строго определенной технологии. Она включает четыре этапа:

1) анализ и планирование требований,

2) проектирование,

3) конструирование,

4) внедрение,

и преследует триединую цель: обеспечить высокую скорость разработки систем при одновременном повышении качества программного продукта и снижении его стоимости [16].

Методология RAD является обобщением мировых достижений и  ориентирована на использование мощных инструментальных средств. Она постоянно пополняется новыми изобретениями и вместе с тем содержит твердое ядро основополагающих идей.

Изложение методологии RAD не входит в наши планы. Руководство [16] — фундаментальный труд, насчитывающий более 800 страниц. Это энциклопедия и одновременно патетический гимн во славу RAD,
а лучше сказать, настольная библия для разработчиков информационных систем, в которой детально расписаны указания, обеспечивающие эффективное практическое использование этого метода.

Мы ограничимся лишь самыми краткими сведениями, позволяющими ответить на вопрос: в каких отношениях находятся два понятия: “методология RAD” и “язык ДРАКОН”.

В 1989 г. журнал “Форчун” попытался выяснить, почему так трудно писать программы: «Программное обеспечение — это “материя чистой мысли”, бестелесная и умозрительная; поэтому проектировщики не в состоянии нарисовать ясные, точные и подробные чертежи и схемы, как это делают разработчики электронных приборов, чтобы дать четкие указания программистам, что нужно сделать. Следовательно, повседневное общение между программистами, их начальниками и обычными людьми, которые используют программы, — это вещь в себе». Однако сторонники RAD думают по-другому. Комментируя указанную статью, Джеймс Мартин пишет: “Важно понять, что эта народная мудрость сегодня уже неверна”. В рамках RAD применяются “точные и детальные чертежи и схемы (аналогичные тем, что рисуют конструкторы электронного оборудования) с помощью технологии I-CASE, причем из этих чертежей генерируется программный код. На уровне чертежей выполняется значительная часть проверок. Эти чертежи и схемы весьма эффективны при повседневном общении программистов, системных аналитиков, менеджеров и конечных пользователей. Попытка создавать программы без этих средств означает только одно — безответственное руководство” [16].

Добавим, что I-CASE (Integrated Computer-Aided Systems Engineering) — это специальный термин, обозначающий интегрированную технологию автоматизированного создания систем, обязательный признак которой — в отличие от обычной, неинтегрированной CASE-технологии — наличие автоматического преобразования чертежей в исходный код нужного языка (и далее — в объектный код).

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

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

Каждая из перечисленных схем представляет собой строго определенный визуальный (графический) язык. Средства I-CASE позволяют устанавливать точные связи между схемами, увязывая их тем самым в единую компьютерную гиперсхему, конвертировать чертежи друг в друга, хранить их значение в репозитории (так называется база знаний, представляющая собой общее хранилище всей информации о проекте). Репозиторий снабжен координатором знаний (knowledge coordinator), который обеспечивает согласованность между различными частями знаний, хранящимися в репозитории, и проверку на правильность вновь вводимых в него данных. Информация с выхода репозитория поступает на генератор кода и, если нужно, оптимизатор. Эти и многие другие методы, средства и инструменты, предусмотренные в RAD, обеспечивают значительный рост производительности труда.

СХЕМЫ ДЕЙСТВИЙ И ЯЗЫК ДРАКОН

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

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

Для представления программных структур в методологии RAD используются специальные чертежи под названием “схемы действий” (action diagrams). Эти схемы можно рисовать независимо от любого языка программирования в виде графического псевдокода, а можно настроить на какой-либо конкретный язык, например язык генератора кода. Они используются также для представления спецификаций в структурной форме.

Большинство ведущих CASE-технологий используют схемы действий. Мартин считает, что они “представляют собой наилучший способ для представления структурных программ и работы с ними” [16].

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

В последнее время появились новые схемы — схемы деятельности (activity diagrams). Однако они также явно проигрывают по сравнению с ДРАКОНОМ.

НЕОБХОДИМОСТЬ КУЛЬТУРНЫХ ИЗМЕНЕНИЙ

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

На наш взгляд, техноязык должен повлечь за собой определенные изменения в культуре, иначе говоря — стать новым элементом языковой культуры. Представляется уместной следующая аналогия. Несколько столетий назад развитие машиностроения и строительного дела сдерживалось наряду с другими причинами отсутствием языка, позволяющего эффективно фиксировать необходимые знания. Общественная потребность в таком языке была чрезвычайно велика. Когда Гаспар Монж впервые предложил идеи начертательной геометрии и появились три проекции (фасад, план, профиль), это привело к формированию, закреплению в стандартах и всемирному распространению языка конструкторских и строительных чертежей. Последний стал одним из важнейших языковых средств технической цивилизации и одновременно достоянием мировой культуры. Человечество получило столь необходимый и давно ожидаемый языковый инструмент для фиксации и обогащения соответствующих знаний. В итоге развитие промышленности заметно ускорилось.

Думается, сегодня имеет место примерно такая же ситуация, ибо сформировалась общественная потребность в техноязыке, как инструменте интеллектуального взаимопонимания и взаимодействия людей, межотраслевого синтеза и автоформализации императивных знаний, эффективного описания структуры деятельности, проектирования социальных технологий, улучшения работы ума. Известно, что “многие люди с активным умом и блестящими идеями оказываются не в состоянии заставить своих коллег точно понять, что они имеют в виду”, причем подобная ситуация, вызванная неадекватностью используемых языковых средств, является одной из причин недостаточной восприимчивости современной индустрии к новым идеям [17]. Эти и другие соображения свидетельствуют о том, что для улучшения взаимопонимания необходимо провести отнюдь не простые системные изменения в культуре. По-видимому, в качестве одного из первых шагов целесообразно сделать техноязык частью системы образования в школе и вузе, причем не как факультатив, а как обязательный компонент учебной программы.

ТЕХНОЯЗЫК КАК ЭЛЕМЕНТ КУЛЬТУРЫ

Изложим без доказательства пять тезисов по вопросу о возможной роли языка ДРАКОН в человеческой культуре. Автор отчетливо сознает дискуссионный характер тезисов, однако питает надежду, что, дочитав книгу до конца, вы, возможно, посчитаете их хотя бы частично обоснованными.

  •  В настоящее время ощущается острая необходимость в создании специального высокоточного средства для улучшения интеллектуального взаимодействия между людьми — техноязыка, который призван стать новым элементом языковой культуры человечества.
  •  Несмотря на то, что в современных компьютерных методологиях, в частности в методологии RAD, применяется значительное число — свыше десятка — различных графических языков (схемы “сущность—связь”, схемы потоков данных, схемы действий и т. д.), с точки зрения человеческой культуры все они имеют лишь локальную эффективность как инструменты создания информационных систем и не удовлетворяют требованиям, предъявляемым к техноязыку. Это значит, что ни один из этих языков не может стать новым элементом языковой культуры человечества, который следует рекомендовать для массового изучения в школах и вузах.
  •  Среди указанного семейства графических языков единственным более или менее приемлемым средством для представления технологических знаний и описания структуры деятельности являются схемы действий и схемы деятельности. Однако они обладают серьезными недостатками и по своим эргономическим и дидактическим характеристикам значительно уступают языку ДРАКОН. Поэтому в качестве техноязыка и нового элемента культуры следует использовать ДРАКОН, а не схемы действий.
  •  Ставка на язык ДРАКОН является оправданной, так как она позволяет осуществить системные изменения в культуре: в системе образования, на производстве (программы и технологии), в науке (улучшение общения между учеными), в социальных технологиях и других областях.
  •  Обучение языку ДРАКОН целесообразно начать в средней школе, используя единую визуальную форму для записи структуры деятельности, алгоритмов, программ, технологий, а также любых императивных знаний, связанных с другими школьными предметами. Это позволит с самого начала преодолеть ныне существующий разрыв между алгоритмическими и технологическими знаниями, укрепить межпредметные связи, повысить качество школьного обучения за счет системного подхода к развитию деятельностного, алгоритмического и технологического мышления и совершенствованию визуального интеллекта учащихся.

ВЫВОДЫ

1. Необходимо различать три понятия: производительность системы “персонал—компьютеры”, производительность компьютеров и производительность персонала. Последняя не зависит от характеристик компьютеров и определяется характеристиками языка. Чтобы повысить продуктивность персонала, нужно улучшить когнитивные характеристики профессионального языка, используемого специалистами при выполнении интеллектуальной работы.

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

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

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

5. Автоформализация технологических знаний, описание структуры деятельности — один из важнейших видов интеллектуального труда. Чтобы добиться резкого повышения производительности этого труда и сделать автоформализацию доступной практически для всех специалистов, нужно создать межотраслевой техноязык, обладающий высокими когнитивными характеристиками.

6. Техноязык следует использовать в современных компьютерных методологиях, что заметно повысит их эффективность.

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


Г Л А В А  4

Понимание и взаимопонимание —
ключевые проблемы
информатики

Понимание — функция разума, главная его функция...

Наталья Автономова

ОТСУТСТВИЕ ПОНИМАНИЯ ВЕДЕТ
К МИЛЛИОННЫМ УБЫТКАМ

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

Вспомним общеизвестные факты не столь уж далекого прошлого. Один из руководителей фирмы IBM Джозеф Фокс сообщает, что в начале 1970-х гг. две основные авиакомпании возбудили дело против своих подрядчиков, поскольку созданная ими система обработки данных стоимостью 40 млн. долл. не только не работала, но и вообще не подавала никаких признаков жизни. Крупный европейский банк направил в суд иск о взыскании 70 млн. долл., выплаченных за программное обеспечение. Военно-воздушные силы США затратили более 300 млн. долл. на тщетную попытку автоматизировать комплексную систему перевозок и снабжения. Продолжая тему, Альгирдас Авиженис отмечает случаи, когда сложные и дорогие системы так и не смогли заработать из-за того, что в рамках установленных сроков и средств не удалось устранить ошибки в программном обеспечении. Джон Муса указывает: эксплуатационные и экономические последствия программных ошибок становятся “поистине ужасными”. Причина всех этих “земных катастроф” больших программистских проектов, как правило, заключалась в том, что заказчик и исполнитель совершенно по-разному понимали задачу. Грубо говоря, заказчик надеялся получить систему “про Фому”, а исполнитель сделал “про Ерему”.

Перечисленные классические примеры крупномасштабных неудач, а также многие другие факты, в том числе эпидемия казавшихся непонятными провалов проектов АСУ8 в нашей стране хотя и стали достоянием истории, тем не менее остаются поучительными до сих пор. Анализ подобных инцидентов позволяет сделать четыре вывода:

1) успех крупного проекта напрямую зависит от взаимопонимания между его участниками;

2) чтобы добиться взаимопонимания, нужны недели и месяцы, а в сложных случаях — годы кропотливой совместной работы заказчика и исполнителя;

3) проблему взаимопонимания нельзя считать решенной до сих пор; достижение взаимопонимания — тяжелый и сложный интеллектуальный труд, производительность которого крайне низка;

4) было бы крайне желательно формализовать этот труд и резко увеличить его производительность.

ИЗДЕВАТЕЛЬСТВО НАД ЗДРАВЫМ СМЫСЛОМ
ПОД НАЗВАНИЕМ
“АБСОЛЮТНО ПРАВИЛЬНАЯ ПРОГРАММА”

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

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

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

СПЕЦИФИКАЦИИ ПРОГРАММ — ВОТ
ГЛАВНЫЙ “ГАДЮЧНИК”!

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

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

Проблема спецификаций — одна из центральных в программировании. Джеймс Мартин пишет: “То и дело встречается одна и та же печальная история: после нескольких лет напряженной разработки системы обработки данных конечные пользователи заявляют, что это вовсе не то, что они хотели... Обычная реакция разработчиков на такую скверную ситуацию — заявление, что требования к системе не были определены пользователем достаточно полно. И это несмотря на то, что требования к системе иногда представляются в виде многих томов документации”.

Что же является причиной ошибок в спецификациях? Рассмотрим вопрос на примере разработки АСУ технологическими процессами атомной электростанции (АСУ ТП АЭС). Заказчики (разработчики АЭС) прекрасно знают “физику процесса”, т. е. технологию работы реакторного и турбинного отделений и других систем АЭС, но, к сожалению, не являются профессорами по части АСУ и программирования. Исполнители (разработчики АСУ ТП АЭС), наоборот, детально знакомы с компьютерами, программированием, особенностями построения систем управления, но, увы, мало что смыслят в реакторах, спецводоочистке и прочих секретах АЭС. Таким образом, проблема состоит в том, что те и другие должны научиться понимать друг друга. Для этого нужно произвести взаимное обучение, взаимный обмен знаниями, которые обычно представлены в виде той или иной документации. Успех взаимного обучения во многом зависит от когнитивных свойств используемого профессионального языка (языка представления знаний). Очевидно, что речь идет о чрезвычайно тонких, деликатных и сложных когнитивных проблемах, в первую очередь, о проблеме понимания.

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

1) ошибки в спецификациях представляют собой одну из наиболее сложных проблем теории и практики программирования;

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


СПЕЦИФИКАЦИИ ПРОГРАММ
И МЕТОДОЛОГИЯ
RAD

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

Новый подход тесно связан с понятием “качество программного продукта”. По мнению Джеймса Мартина, раньше большинство организаций пользовались неудачным определением этого понятия. Они понимали его как “максимально возможное соответствие письменным спецификациям”. При традиционном подходе спецификации, подписанные пользователем, замораживались на весь период, пока выполнялись проектирование, кодирование и тестирование. Зачастую это приводило к тому, что внесение изменений в спецификации запрещалось на срок до восемнадцати месяцев и разрешалось лишь после запуска системы в работу. Естественно, за это время бизнес-требования к проектируемой системе успевали существенно измениться, а созданная система полностью игнорировала этот факт! Так что заказчик был вынужден начинать работу с заведомо непригодной системой, ибо она учитывала не все, а лишь часть его требований, не говоря уже об ошибках в спецификациях, вызванных просчетами пользователя, в связи с чем часть исходных требований была неточна, а многое вообще упущено из виду.

Так было. Однако методология RAD дает новое определение качества программ, понимая его как “максимально возможное удовлетворение истинных бизнес-требований (требований пользователя) на момент предъявления работающей системы заказчику”. Чтобы этого добиться, пришлось многое изменить: резко увеличить скорость разработки с помощью I-CASE-инструментов и, сверх того, радикально улучшить взаимоотношения разработчика и пользователя. Если раньше пользователю “выкручивали руки”, заставляя подписывать бумажные спецификации, которые он плохо понимал, то теперь ситуация изменилась. После короткой серии четко организованных начальных ознакомительных переговоров, результаты которых немедленно вводятся в компьютер, разработчик быстро создает компьютерный прототип системы и немедленно передает его пользователю. Последний, сидя за компьютером, пробует проект “на зуб”, осознает свои заблуждения и направляет разработчику ответную порцию уточнений. Разработчик быстро изменяет прототип и тут же выдает пользователю усовершенствованную версию. Подобная игра в пинг-понг между разработчиком и пользователем повторяется несколько раз и приводит к тому, что прототип постепенно превращается в работающую систему.

Главная хитрость в том, что пользователи больше не должны покупать кота в мешке и подписывать кишащие ошибками бумажные спецификации (разобраться в которых — выше их сил). Они ставят подпись на проекте, полученном с помощью инструментария I-CASE, который вполне доступен их пониманию и который они могут профессионально оценить. Таким образом, действия пользователя, связанные с контролем проекта, имеют компьютерную точность. Участвуя в отработке проекта за экраном компьютера, пользователь гораздо глубже вникает в детали, чем при умозрительном анализе бумажных спецификаций. Изложенный метод иногда называют “раннее прототипирование при спиральном цикле разработки”, потому что прототип тестируется заказчиком на каждом витке спирали, чтобы снизить вероятность ошибки в законченной системе.

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

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

КОНЦЕПЦИЯ
КОГНИТИВНОГО ПРОГРАММИРОВАНИЯ

При разработке нового языка программирования обычно стараются найти разумный компромисс между различными, нередко противоречивыми требованиями, которые, в частности, включают следующие:

1) легкость понимания программ;

2) небольшая трудоемкость написания программ;

3) минимизация потребной машинной памяти;

4) малое время выполнения программ;

5) небольшое время трансляции;

6) легкость автоматизированного выявления ошибок.

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

Разработка языка ДРАКОН опирается на концепцию когнитивного программирования, в основе которой лежат следующие постулаты.


ПОСТУЛАТ 1.  Когнитивные требования к языку рассматриваются как основные, машинные — как второстепенные. Обоснование постулата состоит в том, что сегодня, когда быстродействие компьютеров и объем памяти резко возросли, а их удельная стоимость снизилась, основной проблемой является низкая производительность персонала, поэтому улучшение работы ума, повышение продуктивности человеческого мозга является задачей номер один.

ПОСТУЛАТ 2.  Легкость понимания программ — более важное требование, чем удобство их написания. Как отмечает Я. Пайл, возможность прочитать программу и отчетливо осознать ее смысл гораздо важнее, чем возможность кратко и быстро ее написать. Причиной служит однократное выполнение работы автором программы и необходимость многократного чтения программы в течение ее жизненного цикла9. Известно, что высокая удобочитаемость программ облегчает их сопровождение.

ПОСТУЛАТ 3.  При создании языка выполнение когнитивных и машинных требований следует осуществлять в два этапа, используя разные средства. На первом этапе основное внимание следует сосредоточить на реализации когнитивных требований и (в разумной степени) игнорировать вопросы машинной эффективности программ. При таком подходе использование языка приведет к созданию гарантированно понятных, но, возможно, неэффективных программ. На втором этапе (который во времени может перекрываться с первым) должна решаться проблема машинной эффективности программ, для чего следует использовать:

1) оптимизирующие трансляторы нового поколения;

2) методы автоматического улучшения (оптимизации) программ, обеспечивающие преобразование неэффективных, но понятных программ в эквивалентные, более эффективные;

3) методы интеллектуализации компьютеров;

4) улучшение характеристик компьютеров до границ, делающих массовую эксплуатацию неэффективных (или частично неэффективных) программ экономически приемлемой и даже выгодной;

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

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

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

ВЫВОДЫ

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

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

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


Г Л А В А  5

Проблема улучшения работы ума:
новый когнитивный
подход

Разум! Когда же кончится столь долгое несовершеннолетие твое!

Уильям Гэзлит

ТЕКСТ КАК ЗРИТЕЛЬНАЯ СЦЕНА

Сетчатка человеческого глаза состоит из 126,5 миллионов чувствительных элементов — рецепторов. Она способна воспринимать свет с различной длиной волны (в пределах 380...760 нанометров), отражаемый объектами, находящимися в поле зрения, и преобразовывать его в электрические импульсы, которые направляются в высшие отделы мозга по зрительному нерву. Свет воздействует на чувствительное вещество (родопсин) рецепторов, вызывает изменения в структуре белка (опсина) и запускает цепь биохимических процессов в сетчатке, инициирующих передачу импульсов по зрительному нерву [1].

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

Диосцена — Двумерная Информационная Оптическая сцена, предназначенная для зрительного восприятия информации человеком, целиком лежащая в поле зрения и предъявляемая человеку на бумаге или экране компьютера. Диосцена обычно имеет форму прямоугольника, размеры которого удобно задавать с помощью понятия “формат диосцены”. Для простоты ограничимся форматами, принятыми в стандарте ЕСКД (Единая Система Конструкторской Документации): А0, А1, А2, А3, А4, А4×4. Для зрительного восприятия важен не только формат диосцены, но и ее телесный угол, зависящий от расстояния между глазом и диосценой.

Диопрограмма — это любая компьютерная программа (будь то один из чертежей технологии I-CASE, исходный текст, распечатка объектного кода и т. д.), рассматриваемая как диосцена.


СИМУЛЬТАННОЕ И СУКЦЕССИВНОЕ
ВОСПРИЯТИЕ

За миллионы лет эволюции система “глаз — мозг” изменялась таким образом, чтобы решать две задачи: “видеть, как можно больше (одномоментно), и видеть, как можно отчетливее” [2].

Для решения первой задачи у человека, во-первых, сформировалось поле зрения чрезвычайно больших размеров: 100...110° по вертикали и 120...130° — по горизонтали; во-вторых, образовался аппарат периферийного зрения. Для решения второй задачи в сетчатке глаза возникла область высокой остроты зрения (фовеа) и образовался аппарат центрального (фовеального) зрения [2].

Глаз и мозг способны работать в двух режимах: симультанном (быстрый панорамный прием обзорной информации с помощью периферийного зрения) и сукцессивном (медленный прием детальной информации с помощью центрального зрения). Их оптимальное сочетание позволяет получить важный приспособительный эффект. При симультанном (simultaneous) восприятии система “глаз — мозг” обладает способностью быстро, практически мгновенно воспринимать огромные объемы зрительной информации. Симультанно мы воспринимаем человеческие лица, картины природы, уличные сценки
и многое другое. При сукцессивном
(successive) восприятии производится тщательный последовательный анализ важной информации, первичное выделение которой произошло в ходе симультанного восприятия.

При чтении длинного словесного текста глаз и мозг работают преимущественно в сукцессивном режиме (т. е. медленно), при восприятии изображений доминирует симультанный (быстрый) режим. Если одну и ту же информацию можно представить и в текстовой, и в графической форме, последняя обеспечивает более высокую скорость понимания за счет того, что преимущественно сукцессивный режим восприятия текста заменяется на преимущественно симультанный режим анализа изображения [3].

КАК ПОВЫСИТЬ ПРОДУКТИВНОСТЬ
ЧЕЛОВЕЧЕСКОГО МОЗГА?

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

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

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

КОГНИТИВНЫЙ НЕДОСТАТОК
ТЕКСТОВОГО ПРЕДСТАВЛЕНИЯ ЗНАНИЙ

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

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

Между тем периферийная система важнее центральной в том смысле, что “для адекватного понимания зрительной сцены важнее способность к одномоментному крупномасштабному схватыванию отношений между предметами, чем возможность тонкого... анализа отдельных деталей” [2]. Из клинической практики известно, что поражение всех зон поля зрения, кроме центральной (фовеальной) области практически равносильно слепоте. Таким образом, создав текстовые книги, текстовое программирование и компьютеры с текстовым пользовательским интерфейсом, т. е. искусственно отключив значительную часть периферийного зрения, авторы названных изобретений обрекли читателей деловой литературы, программистов и пользователей на частичную “слепоту”, образно говоря, выключили из работы значительную часть их мозга, вследствие чего громадные резервы коллективного интеллекта этих людей не используются.

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

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

КАКИМ ДОЛЖЕН БЫТЬ ФОРМАТ ДИОСЦЕНЫ?

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

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

Для текстового случая обычно используемый формат экрана и принтера А4, видимо, близок к оптимальному. Однако для визуального программирования дело обстоит иначе.

Принцип зависимости эффективности восприятия от используемой доли поля зрения. Скорость симультанного восприятия визуальной диосцены зависит от ее габаритов и телесного угла, т. е. от фактически используемой доли поля зрения. Если эта доля невелика, скорость будет незначительной, если велика — большой. Если доля слишком мала, следует говорить о недоиспользовании возможностей симультанного восприятия, т. е. об искусственно вызванной частичной “слепоте”, которая отрицательно влияет на продуктивность мозга.

Другой недостаток состоит в том, что необоснованное уменьшение формата визуальной диосцены может привести к когнитивной перегрузке мозга. Предположим, имеется чертеж визуальной программы, занимающий всю площадь большого листа бумаги формата А1. Предположим далее, что мы в исследовательских целях разрезали его на восемь страниц формата А4 и стали поочередно предъявлять их человеку, который должен прочитать чертеж программы и детально в ней разобраться.

Чтобы выявить суть дела, прибегнем к аналогии. Допустим, нужно опознать человека по фотографии. Если перед нами нормальная фотография, задача решается легко. Но что будет, если фотография разорвана на восемь частей, на которые запрещается смотреть одновременно и которые предъявляются только по очереди? Очевидно, при таких условиях решение задачи опознания становится чрезвычайно трудным, а с увеличением числа фрагментов — невозможным.

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

Для условий описанного примера справедливо заключение: если заменить восемь “рваных кусков” формата А4 на единую стройную картину формата А1, можно значительно увеличить скорость мышления и продуктивность мозга программиста. Этот вывод подтверждается мировой практикой создания машиностроительных чертежей и электрических схем, где широко используются большие форматы А1 и А0, что нашло закрепление в соответствующих международных и национальных стандартах.

Изложенные соображения позволяют сформулировать принцип приоритета целостного образа. Если имеются два эквивалентных графических представления одной и той же программы: 1) в виде одного большого чертежа (например, формата А4×4, А1 или А0), который хорошо отражает структуру проблемной ситуации в форме целостного и стройного визуального образа, и 2) в виде набора из нескольких маленьких чертежей (например, четырех, восьми или шестнадцати форматок А4), то замена набора мелких чертежей на один большой увеличивает продуктивность мозга за счет увеличения активно используемой доли физиологического поля зрения, замены образов памяти на образы восприятия, устранения паразитной когнитивной нагрузки и более эффективного использования симультанных механизмов.


КОГНИТИВНЫЕ РЕКОМЕНДАЦИИ

Говорят, один рисунок стоит тысячи слов, и это действительно так при условии, что рисунок хороший. Последнее условие является существенным, так как неумелое использование чертежей и рисунков может принести только вред. Возникает вопрос: при каких условиях замена текста изображением дает максимальный когнитивный выигрыш с точки зрения интенсификации работы мозга?

Говоря упрощенно, таких условий всего два: визуальная диосцена должна иметь, во-первых, хорошие размеры, во-вторых, хорошую структуру11.

Что значит хорошие размеры? Размеры зависят от когнитивной сложности проблемы. Для более простых случаев можно использовать форматы А4 и А3, для более сложных — форматы А4×4, А1, для особо сложных А0. Напомним еще раз, что все эти форматы прошли массовую проверку в мировой инженерной практике. Они начинают применяться и в практике программирования. Например, при использовании CASE-инструмента ProKit WORKBENCH фирмы McDonnel Douglas Information Systems используются программные чертежи размером 3 × 4 фута (91 × 122 см) — что-то среднее между форматами А1 и А0.

Что значит хорошая структура? Ниже дается примерный ответ, но не для общего случая, а только для блок-схем (потому что язык ДРАКОН строится на основе блок-схем; большинство программных чертежей методологии RAD — тоже блок-схемы)12. По нашему мнению, блок-схемы обладают хорошей структурой, если при их создании учитываются (возможно, с исключениями) следующие правила.

  •  Структура диосцены должна быть не хаотичной, а регулярной и предсказуемой.
  •  Диосцену желательно разбить на зоны, имеющие зрительно-смысловое значение13 (зона обычно содержит несколько блоков).
  •  Назначение зон желательно разъяснить с помощью надписей, расположение которых в поле чертежа подчиняется визуальной логике картины и облегчает ее понимание.
  •  Границы зон (выделяемые пробелами или линиями) должны иметь простую прямоугольную форму.
  •  Структурные зоны, блоки и их связи желательно упорядочить по двум декартовым осям. Предварительно нужно четко определить критерии ориентации содержания диосцены по осям х и у, специально оговорив критерии и смысл движения взгляда по указанным осям как в прямом, так и в обратном направлении.
  •  Соединительные линии между блоками должны быть вертикальными и горизонтальными. Наклонные линии не рекомендуются.
  •  Желательно, чтобы входы и выходы блоков имели однозначную ориентацию. Например, если определено, что входная линия присоединяется к блоку сверху, то иное присоединение (справа, слева и снизу) следует считать не очень хорошим.
  •  Число пересечений, обрывов и изломов на соединительных линиях нужно минимизировать.
  •  Следует избегать визуальных помех, т. е. избыточных обозначений, без которых можно обойтись и которые отвлекают внимание от главного.
  •  Замкнутые контуры предпочтительнее, чем разорванные линии.
  •  Следует использовать простые и интуитивно ясные средства, позволяющие отделить смысловую фигуру (простую или составную) от фона.
  •  Линии контура блоков должны быть жирнее, чем соединительные линии.
  •  Следует использовать также некоторые правила, рекомендуемые в инженерной психологии для проектирования средств отображения информации, например правило метра и ритма [5].

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

ЗАЧЕМ НУЖНЫ ПСИХОЛОГИЧЕСКИЕ
ЭКСПЕРИМЕНТЫ?

Современный подход к когнитивному проектированию языковых средств программирования состоит из шести частично перекрывающихся этапов:

  •  разработка теоретических положений когнитивного программирования;
  •  трансформация их в конкретные эргономические правила проектирования языковых средств;
  •  разработка желаемого языка программирования с нужными когнитивными и иными характеристиками с учетом указанных правил;
  •  проверка когнитивной эффективности конструкций нового языка с помощью управляемого психологического эксперимента, построенного в соответствии со строгими критериями, принятыми в экспериментальной психологии [6];
  •  оценка когнитивного качества нового языка методом экспертных оценок, полученных на основе использования языка в нескольких программных проектах;
  •  доработка языка с целью устранения когнитивных недостатков.

Цель данного параграфа — подчеркнуть особую значимость управляемого психологического эксперимента как мощного средства контроля, необходимого для улучшения когнитивного качества проектируемых языков.

Термин “психология программирования” ввел Том Лав, психолог фирмы “Дженерал Электрик”, занимавшийся методами усовершенствования производства программ [6]. Психология программирования призвана решить ряд задач, в частности, исключить случайные и субъективные факторы, обусловленные сиюминутными проектными и коммерческими соображениями и приводящие к приблизительным, качественным суждениям о том, “что людям должно нравиться” или “что проще в использовании”. Для экспериментального обоснования своих рекомендаций психология программирования предпочитает использовать точные количественные методы исследования человеческой деятельности [7].

Если вчера многие разработчики языков программирования зачастую обосновывали свою позицию с помощью аргументов типа “это удобно”, “это наглядно и понятно каждому”, “это предельно ясная и читабельная языковая конструкция”, “так проще”, “так быстрее”, “так доходчивее”, то сегодня все яснее становится крайняя неопределенность, слабость и субъективность подобных утверждений. Несостоятельность традиционных методов оценки наглядности и удобства особенно ярко проявляется в тех ситуациях, когда в ходе полемики на тему “чья нотация лучше?”, каждый из авторов, отстаивающих диаметрально противоположные точки зрения, объявляет свою систему нотаций “более наглядной” и “более удобной”.

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

К сожалению, в нашей стране психология программирования развита слабо и практически не имеет связей с кафедрами информатики, вычислительной математики и программирования вузов. По мнению автора, в качестве первого шага следует ввести курс психологии программирования или когнитивных основ программирования для студентов факультета вычислительной математики и кибернетики МГУ, а также на соответствующих кафедрах других ведущих ВУЗов, готовящих программистов.

ОШИБКА ДЖЕЙМСА МАРТИНА

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

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

“ЭТО ЧУДАКАМ-ИНЖЕНЕРАМ НУЖНЫ
БОЛЬШИЕ ЧЕРТЕЖИ,
А МЫ, ХИТРЕЦЫ-ПРОГРАММИСТЫ,
ОБОЙДЕМСЯ МАЛЕНЬКИМИ”

По мнению автора, позиция Мартина отражает общее заблуждение, глубоко укоренившееся в умах многих специалистов по информатике и препятствующее прогрессу в деле повышения продуктивности мозга программистов.

Проследим ход рассуждений Мартина. Они весьма просты. Персональные компьютеры и дешевые принтеры получили массовое распространение и доступны всем.  В отличие от них плоттеры встречаются


Таблица  1

Утверждение Мартина

Возражение

Чертежи программ должны быть компактными [8]

Компактность — не самоцель.
К ней следует стремиться в тех случаях,
когда она увеличивает производительность.
Если же компактность чертежа
затрудняет понимание вопроса и снижает продуктивность, разумно от нее отказаться

Чертежи программ следует выполнять на бумаге
формата А4 [8]

Это верно, если проблема простая
и иллюстрирующий ее рисунок целиком размещается на листе формата А4.
Если же проблема сложная и требует, например, 400 форматок А4, выгодней перейти к большим форматам.
В этом случае понадобится всего 50 листов формата А1 или 25 листов формата А0. Большие чертежи, нарисованные в соответствии с когнитивно-эргономическими правилами с помощью технологии
I-CASE, снижают когнитивную нагрузку на мозг читателя и повышают умственную производительность в процессе понимания
и анализа сложных программных проектов

Большие чертежи неудобны тем,
что их трудно посылать другим людям или брать домой [9]

Это неверно. Во всем мире инженеры пользуются большими чертежами:
их постоянно пересылают из одной организации в другую, берут для работы домой и т. д. Автор сам это делал много раз и может поручиться, что при этом
не возникает никаких проблем. Чертежи форматов А1 и А0 известным способом несколько раз перегибаются и укладываются в папку для бумаг формата А4

Некоторые аналитики, программисты и администраторы данных любят рисовать цветные настенные схемы шириной
шесть футов (2 м 10 см).
Это можно сделать с помощью плоттера
CALCOMP, однако такие плоттеры дороги и недоступны большинству аналитиков
и программистов. Нужно отказаться от подобных громадных чертежей
и ограничиться форматом, который можно напечатать с помощью обычного персонального
компьютера и принтера [9]

Рассуждение некорректно, ибо Мартин рассматривает две крайние позиции:
либо роскошные двухметровые цветные чертежи, сделанные на сверхдорогом плоттере, либо маленькие форматки обычного персонального компьютера.
В действительности существует промежуточный вариант: малогабаритный щелевой плоттер с рапидографом, позволяющий рисовать черно-белые
чертежи формата А1. Такие плоттеры относительно недороги и представляют собой разумный компромисс.
Существуют и другие приемлемые
варианты плоттеров

Окончание табл. 1

Утверждение Мартина

Возражение

Иногда чертеж требует больших размеров бумаги.
В этом случае следует увеличивать не горизонтальный,
а вертикальный размер чертежа, чтобы напечатать его
на фальцованной (сложенной
на сгибах) бумаге на обычном принтере [8]

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

1  В данном случае можно достичь компромисса, если с помощью программных средств повернуть компьютерный образ чертежа на 90° и вывести его на обычный принтер в графическом режиме. Это позволит превратить неудобную вертикальную “кишку” в приятный  для глаза чертеж, у которого длинный размер наращивается по горизонтали. Однако такой прием неприменим к схемам действий, которые специально (и крайне неудачно) сконструированы именно в форме вертикальной кишки, что хорошо согласуется с характеристиками принтера, но плохо согласуется с характеристиками человека. Переделать их в горизонтальную форму, более удобную с точки зрения биомеханики глаза, принципиально невозможно. Таким образом, схемы действий построены исходя из технократических, а не когнитивных соображений.

сравнительно редко. Поэтому при выборе формата визуальных чертежей следует ориентироваться на имеющуюся технику. Исходя из этого, Мартин, жертвуя наглядностью ради уменьшения формата, предлагает тщательно продуманную систему мер, позволяющих сократить размеры чертежей [9], чтобы использовать “дешевые принтеры” и сэкономить на плоттерах. Хотя в каких-то частных ситуациях такой подход может оказаться разумным, однако в масштабе национальной или мировой экономики идея “дешевых принтеров” не улучшает, а наоборот, ухудшает экономические показатели информационной отрасли, так как, выигрывая по стоимости плоттеров, мы несоизмеримо проигрываем на производительности труда. Это значит, что в стратегическом плане Мартин пожертвовал не пешку за ферзя, а наоборот, ферзя за пешку.

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

Против Мартина работает еще один аргумент, связанный с уроками истории. Всемирная практика развития машиностроения и электротехники привела инженеров к двум выводам:

1) замена текстового описания механических и электрических устройств чертежами повышает производительность;

2) форматы чертежей в зависимости от обстоятельств целесообразно увеличить до нужных размеров.

Сегодня программисты, можно сказать, уже согласились с первым выводом и решили, что им, как и инженерам, тоже нужны чертежи. Однако второй вывод по-прежнему отвергается, поскольку миф об исключительности программистов оказывается необыкновенно живучим (см. заголовок этого параграфа). Ясно, однако, что зрительный анализатор и мозг программиста по своей конструкции не отличаются от мозга инженера. Механизмы зрительного восприятия чертежей определяются нейробиологическими и психологическими закономерностями, которые едины для программистов и инженеров. Это значит, что сказав А, нужно сказать и Б. Логично предположить, что рано или поздно в программировании будет узаконен тот же набор форматов чертежей, что и в инженерном деле. Чем скорее это будет сделано, тем лучше.

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

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

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

ВОЗМОЖНА ЛИ
СТРАТЕГИЧЕСКАЯ РЕФОРМА МИРОВОЙ ПРАКТИКИ ПРОГРАММИРОВАНИЯ

Согласно исследованиям американского специалиста Джона Мусы за двадцать лет между 1965 и 1985 гг. потребность в программном обеспечении увеличилась в сто раз, однако производительность программистов выросла лишь в два раза. А. Питер и Т. Рэймонд характеризуют этот факт, как “кризис производительности” [10].

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

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

1) переход от текстового представления знаний и текстового программирования к визуальному;

2) увеличение формата диосцен и диопрограмм до оптимальных размеров, позволяющих устранить эффект “частичной слепоты”;

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

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

ВЫВОДЫ

1. С точки зрения нейробиологии и психологии, информационные сообщения, записанные с помощью нотаций письменного языка и предъявляемые человеку на бумаге или экране, поступают в высшие отделы мозга через зрительный анализатор. Следовательно, указанные сообщения есть не что иное как оптический код, представленный в виде одной или нескольких диосцен. Этот код имеет оптический синтаксис и оптическую семантику.

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

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

4. Новый когнитивный подход — это попытка подготовить теоретическую платформу для разработки некоторых методов повышения интеллектуальной продуктивности человеческого мозга и построения языков следующего поколения, удовлетворяющих критерию улучшения работы ума и сверхвысокого понимания. Предполагается, что это создаст предпосылки для стратегической реформы мировой практики программирования.


Г Л А В А  6

Изюминки языка ДРАКОН

Графический язык является главным средством достижения наглядности

Константин Гомоюнов

КРИТИКА БЛОК-СХЕМ

Эффективным средством для улучшения понимаемости алгоритмов является визуализация программирования [1], а несколько раньше для этой цели использовались блок-схемы [2]. Однако в последнее время блок-схемы подвергаются критике. Противники блок-схем утверждают, что они непригодны для структурного программирования, не поддаются формализации, поэтому их “нельзя использовать как программу для непосредственного ввода в машину” [3]. Они занимают много страниц, причем “в клеточки блок-схем можно вписывать весьма ограниченные сведения”. Блок-схемы “затрудняют обучение и снижают производительность при понимании” [4]. Кроме того, они удобны не для всех — работу с блок-схемами предпочитают только “индивидуумы с правым ведущим полушарием, ориентированные на визуальную информацию, интуитивные, распознающие образы”, однако их избегают “индивидуумы с левым ведущим полушарием, ориентированные на словесную информацию, склонные к дедуктивным рассуждениям” [4] и т. д.

Если до 1980 г. блок-схемы были наиболее широко применяемым средством, то сегодня они “больше не считаются необходимыми и их популярность падает”. Хотя имеются отдельные попытки приспособить блок-схемы к современным нуждам (язык SDL и др.), однако в целом блок-схемы явно оказались на обочине бурно развивающегося процесса визуализации программирования, а их громадные потенциальные возможности фактически не используются. Язык ДРАКОН позволяет устранить или существенно ослабить отмеченные недостатки блок-схем.

Для обозначения блок-схем, построенных по правилам языка ДРАКОН, используется термин “дракон-схемы”.

ПРЕИМУЩЕСТВА ДРАКОН-СХЕМ

Чем же отличаются дракон-схемы от блок-схем? Блок-схемы не обеспечивают автоматическое преобразование алгоритма в машинный код. Дракон-схемы, напротив, пригодны для формализованной записи, автоматического получения кода и исполнения его на компьютере. Однако более важным является второе (когнитивное) отличие. Хотя блок-схемы порою действительно улучшают понимаемость программ, однако это происходит не всегда, причем степень улучшения невелика. Кроме того, есть немало случаев, когда неудачно выполненные блок-схемы запутывают дело и затрудняют понимание. В отличие от них дракон-схемы удовлетворяют критерию сверхвысокой понимаемости.

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

ИКОНЫ И МАКРОИКОНЫ

Графоэлементы (графические буквы) языка ДРАКОН называются иконами (рис. 1). Подобно тому, как буквы объединяются в слова, иконы объединяются в составные иконы — макроиконы (рис. 2).

Соединяя иконы и макроиконы по определенным правилам, можно строить разнообразные алгоритмы, примеры которых показаны на рис. 3, 4, 6, 8—11.

Шампур-блок — часть дракон-схемы, имеющая один вход сверху и один выход снизу, расположенные на одной вертикали. Примерами шампур-блоков являются иконы И3 — И10, И12 — И16, И18, И20, И21 (рис. 1) и макроиконы 2—20 (рис. 2).

ЗАЧЕМ НУЖНА ВЕТКА?

Когда принцесса Анна развелась с маркизом Ле-Шателье, возник спор о разделе имущества. Судья потребовал указать, какие покупки принцесса сделала до замужества, а какие — после.

А теперь забудем об этой семейной драме и сравним между собой рис. 3а и 3б. Легко видеть, что первый не позволяет ответить на вопрос судьи. Что касается второго, то он, наоборот, содержит нужную информацию. Более того, алгоритм на рис. 3б нарочно нарисован так, что покупки, сделанные до и после замужества, четко делятся на два списка. Эти списки зрительно и пространственно разнесены, поэтому деление алгоритма на две части независимо от воли читателя буквально бросается в глаза. Такой прием называется разбиением алгоритма на смысловые части по принципу “взглянул — и сразу стало ясно!” А сами смысловые блоки именуются ветками.

Слово “ветка” имеет два значения. С одной стороны, это смысловой “кусок” алгоритма.  Например, алгоритм на рис. 3б имеет две ветки


1


2


(“Покупки до замужества” и “Покупки после замужества”). На рис. 4 — четыре ветки (“Подготовка к ловле”, “Ожидание клева”, “Рыбацкая работа”, “Обратная дорога”). С другой стороны, ветка — составной оператор языка ДРАКОН, который не имеет аналогов в известных языках. Оператор “ветка” состоит из трех частей: начала ветки (икона “имя ветки”), тела ветки (которое может содержать большое число икон) и конца ветки (который содержит одну или несколько икон “адрес” либо икону “конец”).

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



КАК РАБОТАЕТ ВЕТКА?

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

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

КАК СЛЕДУЕТ РАСПОЛАГАТЬ ВЕТКИ
В ПОЛЕ ЧЕРТЕЖА?

Ветки упорядочены двояко: логически и пространственно. Логическая последовательность исполнения веток определяется метками, записанными в иконах “адрес”. Однако логический порядок — это еще не все. На рис. 5 показаны три разных способа пространственного расположения веток, которые имеют один и тот же логический порядок. Чтобы устранить пространственную неоднозначность и облегчить понимание смысла дракон-схемы, вводится правило “чем правее — тем позже”. Оно означает: ветка, нарисованная правее, работает позже всех веток, находящихся левее.

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

В разрешенных (эргономичных) алгоритмах имеет место следующий порядок работы (рис. 3, 4, 5в, 6а):

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

ЧТО ТАКОЕ ШАПКА?

С точки зрения читателя, любой незнакомый или забытый нетривиальный алгоритм — чрезвычайно сложная проблема, которую он отчаянно пытается понять, преодолевая мощное “сопротивление материала”. Чтобы упростить дело и облегчить задачу понимания, нужно,  чтобы





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

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

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

1) как называется проблема?

2) из скольких частей она состоит?

3) как называется каждая часть?

Ведь именно с этих вопросов начинается наше знакомство с любой задачей при рациональном подходе к делу.

Вот ответы для рис. 4.

  •  Как называется проблема?  Рыбная ловля.
  •  Из скольких частей состоит проблема?  Из четырех.
  •  Как называется каждая часть?  1. Подготовка к ловле. 2. Ожидание клева. 3. Рыбацкая работа. 4. Обратная дорога.

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

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

ЧТО ЛУЧШЕ: ПРИМИТИВ ИЛИ СИЛУЭТ?

Дракон-схема с ветками называется силуэтом, без веток — примитивом. Силуэт, представленный на рис. 6а, можно изобразить в виде примитива (рис. 6б). Примитив есть последовательное соединение иконы “заголовок” шампур-блоков и иконы “конец”. У примитива иконы “заголовок” и “конец” обязательно лежат на одной вертикали, которая называется шампуром. На этой же линии лежат главные вертикали шампур-блоков. Образно говоря, шампур пронизывает иконы примитива (возможно, не все) подобно тому, как настоящий шампур пронизывает кусочки шашлыка.

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

Например, алгоритм на рис. 6б выглядит громоздким и неоправданно сложным для восприятия. Это вызвано тем, что он содержит 19 икон, однако изображен в виде примитива. Криминал в том, что схема на рис. 6б не позволяет читателю мгновенно (за несколько секунд) распознать визуально-смысловую структуру алгоритма. В самом деле, из скольких частей состоит решаемая проблема? Глядя на рис. 6б, ответить на этот вопрос довольно трудно, а быстро ответить — невозможно. Положение в корне меняется, когда мы смотрим на рис. 6а, где тот же самый алгоритм изображен в виде силуэта. Тут, как говорится, и ежу ясно: алгоритм состоит из четырех частей: “поиск автобуса”, “ожидание посадки”, “посадка в автобус”, “поездка”. Однако это не все: не менее важно и то обстоятельство, что запутанность зрительного рисунка исчезла и схема приобрела новое эстетическое (эргономическое) качество: элегантность, ясность и прозрачность.

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

КАК ОПИСАТЬ СИЛУЭТ С ПОМОЩЬЮ
ТЕКСТОВОГО ЯЗЫКА?

Из рис. 7 видно, что для описания веток в текстовый язык пришлось внести ряд изменений. В частности, появились два новых текстовых оператора, отсутствующие в традиционных языках:

ВЕТКА < идентификатор ветки >

АДРЕС < идентификатор ветки >

Оператор текстового языка ВЕТКА объявляет название ветки (записываемое на визуальном языке внутри иконы “имя ветки”). Оператор АДРЕС безусловно передает управление на текстовый оператор ВЕТКА, имя которой записано справа от оператора АДРЕС.



Сравнивая два языка: визуальный и текстовый, можно заметить, что соответствующие алгоритмы (рис. 6а и 7) эквивалентны14. Однако визуальный язык несомненно более нагляден и доходчив. Второе преимущество состоит в том, что графика позволяет полностью исключить избыточные (паразитные) элементы, каковыми в текстовом языке оказываются почти все ключевые слова: АЛГОРИТМ, ВЕТКА, АДРЕС, КОНЕЦ ВЕТКИ, ЕСЛИ, ТО, ИНАЧЕ, КОНЕЦ ЕСЛИ, ЦИКЛ ЖДАТЬ, КОНЕЦ ЦИКЛА, КОММЕНТАРИЙ, ПЕРЕХОД НА, а также метки.

ЕСТЬ ЛИ В АЛГОРИТМЕ
“ЦАРСКАЯ ДОРОГА”?

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

Для этого вводится правило: “главный маршрут примитива должен идти по шампуру”. Меняя местами слова “да” и “нет” в развилках и варианты в переключателях (а также присоединенные к ним гирлянды икон), следует добиться, чтобы на царском пути оказался тот выход развилки или переключателя, который ведет к наибольшему успеху (рис. 8). А побочные маршруты нужно расположить по правилу: “чем правее — тем хуже” (рис. 9). Если эти правила нарушены, дракон-схема считается плохой (рис. 10а). Однако ее всегда можно превратить в хорошую (рис. 10б).

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



ГЛАВНЫЙ МАРШРУТ СИЛУЭТА

В предыдущем параграфе мы узнали, как упорядочить маршруты примитива. Теперь настала очередь силуэта.

Шампуром ветки называется вертикаль, соединяющая икону “имя ветки” с иконой “адрес”, а если у ветки несколько выходов — с левым из них. Для ветки сохраняют силу оба “царских” правила:

  •  главный маршрут ветки должен идти по шампуру;
  •  побочные маршруты ветки следует упорядочить слева направо по какому-либо критерию.

Предположим, в качестве критерия выбран принцип “чем правее — тем хуже”. В этом случае каждая ветка силуэта должна быть построена по единому правилу: чем правее (чем дальше от шампура данной ветки) расположена очередная вертикаль, тем менее успешные действия она выполняет.

Например, на рис. 6а ветка “посадка в автобус” имеет три вертикали. Левая вертикаль (главный маршрут) описывает наибольший успех, так как вы будете ехать в автобусе сидя. Правая вертикаль означает наименьший успех, поскольку вы вышли из автобуса и поездка откладывается. Средняя вертикаль (расположенная выше иконы “Есть желание ехать стоя?”) занимает промежуточное положение, потому что —
в зависимости от ответа — может иметь место либо частичный успех (вы будете ехать, но не сидя, а стоя), либо неудача, поскольку вы выходите из автобуса несолоно хлебавши.

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

ПЕРЕСЕЧЕНИЯ ЛИНИЙ? — БОЖЕ УПАСИ!

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


10а


10б


11


12


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

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

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

Теорема 1.  Любая структурная программа может быть изображена
на языке
ДРАКОН двумя способами: в виде примитива и в виде силуэта.

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

Чтобы прояснить вопрос, обратимся к примерам. На рис. 13а приведена запрещенная дракон-схема: примитив, в котором имеется неустранимое (без введения дополнительных переменных) пересечение. На рис. 13б изображен силуэт, который, как нетрудно убедиться, эквивалентен примитиву на рис. 13а и вместе с тем не содержит ни одного пересечения. Таким образом, пример на рис. 13 подтверждает справедливость теоремы 215.

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

ВИЗУАЛЬНЫЙ И ТЕКСТОВЫЙ
СИНТАКСИС ДРАКОНА

ДРАКОН — визуальный язык, в котором используются два типа элементов: графические фигуры (графоэлементы) и текстовые надписи, расположенные внутри или снаружи графических фигур (текстоэлементы). Следовательно, синтаксис ДРАКОНА распадается на две части. Визуальный синтаксис охватывает алфавит графоэлементов, правила их размещения в поле чертежа и правила связи графоэлементов с помощью соединительных линий. Текстовый синтаксис задает алфавит символов, правила их комбинирования и привязку к графоэлементам (привязка необходима потому, что внутри разных графических фигур используются разные типы выражений). Оператором языка ДРАКОН является графоэлемент или комбинация графоэлементов, взятые вместе с текстовыми надписями.

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

СЕМЕЙСТВО ДРАКОН-ЯЗЫКОВ

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

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

ДРАКОН-2 — язык визуального программирования реального времени. Он является элементом CASE-технологии для разработки программного обеспечения систем управления ракет и космических объектов, а также атомных электростанций, нефтехимических и металлургических заводов, биотехнологических производств и т. д.

Кроме того, семейство включает гибридные визуальные языки программирования: ДРАКОН-БЕЙСИК, ДРАКОН-ПАСКАЛЬ, ДРАКОН-СИ
и т. д. Чтобы получить гибридный язык, например,
ДРАКОН-СИ, необходимо взять визуальный синтаксис ДРАКОНА и присоединить к нему по определенным правилам текстовый синтаксис языка СИ.

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

В настоящей книге основное внимание уделяется визуальному псевдоязыку ДРАКОН-1. Что касается остальных языков ДРАКОН-семейства, даются лишь краткие пояснения.

ВЫВОДЫ

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

  1.  Сложный алгоритм следует рисовать в виде силуэта, простой — в виде примитива.
  2.  В иконе “заголовок” запрещается писать слово “начало”; вместо этого следует указать понятное и точное название алгоритма.
  3.  Разбейте сложный алгоритм на части, каждую часть изобразите в виде ветки. Дайте частям доходчивые и четкие названия и запишите их в иконах “имя ветки”.
  4.  Вход в ветку возможен только через ее начало.
  5.  В иконе “адрес” разрешается писать имя одной из веток, другие надписи запрещены.
  6.  Ветки следует располагать в пространстве согласно правилу: чем правее, тем позже. Наличие веточного цикла модифицирует это правило.
  7.  Примитив обязательно имеет шампур. Это значит, что у примитива иконы “заголовок” и “конец” всегда лежат на одной вертикали, которая и называется “шампур”.
  8.  Каждая ветка обязательно имеет шампур. У правой ветки шампур — это вертикаль, соединяющая иконы “имя ветки” и “конец”. У остальных веток шампуром служит вертикальная линия, соединяющая иконы “имя ветки” и “адрес”, а если адресов несколько — с левым из них.
  9.  Алгоритм всегда имеет главный маршрут, который должен идти по шампуру.
  10.  Побочные маршруты должны быть упорядочены слева направо
    согласно одному из выбранных критериев, например: чем правее — тем хуже.
  11.  В иконе “конец” следует писать слово “конец”.
  12.  Соединительные линии могут идти либо горизонтально, либо вертикально. Наклонные линии не допускаются.
  13.  Пересечения линий запрещены.
  14.  Обрывы линий запрещены.
  15.  Использование соединителей запрещено.


Г Л А В А  7

Эргономичные алгоритмы

На ошибках мы горим! —
Мне сказал Алеха.
Непонятный алгоритм —
Это очень плохо.

Мы ошибки победим!
Надо сделать вот чего —
Надо сделать алгоритм
Ясным и доходчивым!

Юрий Примашев

ВИЗУАЛЬНАЯ ПРОВЕРКА АЛГОРИТМОВ

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

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

Мозговую проверку, как и любую другую деятельность, нужно грамотно проектировать. Критерием ее эффективности служит минимизация средних интеллектуальных усилий мозга, затрачиваемых на выявление одной ошибки. Нейронная конструкция мозга такова, что он может эффективно проводить визуальную проверку отнюдь не при любых условиях, а только в том случае, если проверяемые чертежи обладают высоким когнитивным качеством. Чтобы минимизировать удельные интеллектуальные усилия, необходимо, чтобы когнитивно-значимые характеристики чертежей были хорошо согласованы
с конструктивными характеристиками мозга. Это значит, что спецификации и алгоритмы должны быть специально приспособлены для быстрой и надежной проверки, для легкого и вместе с тем глубокого понимания.

ЧТО ТАКОЕ ЭРГОНОМИЧНЫЙ АЛГОРИТМ?

В связи с этим полезно ввести понятие эргономичный алгоритм, т. е. алгоритм, удовлетворяющий критерию сверхвысокой понимаемости. Преимущество эргономичных алгоритмов в том, что они намного понятнее, яснее, нагляднее и доходчивее, чем обычные. Если алгоритм непонятный, в нем трудно или даже невозможно заметить затаившуюся ошибку. И наоборот, чем понятнее алгоритм, тем легче найти дефект. Поэтому более понятный, эргономичный алгоритм намного лучше обычного. Лучше в том смысле, что он облегчает выявление ошибок,  а это очень важно. Ведь чем больше ошибок удастся обнаружить при визуальной проверке, тем больше вероятность, что вновь созданный алгоритм окажется правильным, безошибочным, надежным. Кроме того, эргономичные алгоритмы удобнее для изучения, их проще объяснить другому человеку.

В предыдущей главе мы рассмотрели несколько способов, позволяющих улучшить эргономические характеристики алгоритмов. В этой главе, продолжая тему, попытаемся ответить на вопрос: можно ли повысить эргономичность алгоритмов, используя формальный метод эквивалентных преобразований?

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

ЧЕМ ОТЛИЧАЕТСЯ ИКОНА “ВОПРОС”
ОТ РАЗВИЛКИ?

На рис. 1 (позиция И4) изображена икона “вопрос”. Она называется так, потому что внутри нее пишут “да-нетныйвопрос, т. е. вопрос, на который можно ответить либо “да”, либо “нет”. Все другие ответы запрещены. Вот примеры да-нетных вопросов: утюг сломался? Тетя приехала? Вася купил хлеб? Преступника арестовали? Эта лужа больше, чем та? Температура выше нуля?

Икона “вопрос” имеет один вход сверху и два выхода: вниз и вправо. Выход влево запрещен и никогда не используется.

На рис. 2 (позиция 2) показана макроикона “развилка”. Она содержит икону “вопрос”, точку слияния и два плеча: левое и правое (рис. 14б). Левое плечо есть путь от нижнего выхода иконы-вопроса до точки слияния. Правое плечо начинается у правого выхода иконы-вопроса и заканчивается в точке слияния (рис. 15). Таким образом, плечо имеет в своем составе надпись “да” или “нет”, соединительные линии, точку слияния, а также иконы. Одно из двух плеч может быть пустым (не содержать икон).

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

крайней мере одна простая развилка. На рис. 10а показаны три сложные развилки. Например, развилка “Борщ очень вкусный?” сложная, так как ее левое плечо содержит простую развилку “Борщ сильно пересолен?”. Другие примеры сложных развилок показаны на рис. 17.



МАРШРУТЫ И ФОРМУЛЫ МАРШРУТОВ

На рис. 18а представлена дракон-схема “Охота на мамонта”. Заменим текст внутри икон буквами. Вместо “Охота на мамонта” запишем букву А, вместо “Поймай мамонта” — букву Б и т. д. В результате получим литеральную (буквенную) дракон-схему на рис. 18б. Литеральные схемы удобно использовать для описания маршрутов.

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

Линейный (неразветвленный) алгоритм имеет только один маршрут и одну формулу. Например, схема на рис. 18б описывается формулой

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

ЧТО ТАКОЕ РОКИРОВКА?

Рокировка — это преобразование алгоритма, при котором левое и правое плечо развилки меняются местами. Простейшие примеры рокировки показаны на рис. 8 и 21.

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

Следовательно, указанные дракон-схемы равносильны.

Формальное преобразование алгоритма А1 в алгоритм А2 называется равносильным, если алгоритмы А1 и А2 равносильны. Сказанное означает, что рокировка является равносильным преобразованием алгоритмов. При рокировке слова “да” и “нет” обязательно меняются местами.


18-20


21-22


ИСПОЛЬЗОВАНИЕ РОКИРОВКИ
ДЛЯ УЛУЧШЕНИЯ ЭРГОНОМИЧНОСТИ

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

Попытаемся обосновать аналогичный вывод для рис. 21, рассмотрев последовательно все промежуточные шаги рассуждений.

На первом шаге выдвигаем гипотезу: для сравнения двух маршрутов на рис. 21а можно использовать признак “лучше—хуже”.

На втором шаге проверяем гипотезу с помощью рассуждений: если брюки впору — это хорошо, если их приходится подворачивать — это плохо. Следовательно, использование в данном алгоритме признака “лучше—хуже” правомерно.

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

На четвертом шаге констатируем, что главный маршрут на рис. 21а не идет по шампуру. Делаем вывод: алгоритм на рис. 21а является плохим, неэргономичным, однако его можно исправить с помощью рокировки.

На пятом шаге выполняем рокировку и получаем более эргономичный алгоритм на рис. 21б. На этом процедура заканчивается16.

Рассмотрим теперь более сложный алгоритм на рис. 10а. Этот алгоритм тоже плохой, потому что содержит три плохие (неэргономичные) развилки: 1) “В меню есть твой любимый салат?”, 2) “Борщ очень вкусный?”, 3) “Жаркое, как подошва?”. Последовательно применяя к развилкам три операции “рокировка”, получаем эргономичный алгоритм на рис. 10б.

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


ВЕРТИКАЛЬНОЕ И ГОРИЗОНТАЛЬНОЕ
ОБЪЕДИНЕНИЕ

Бывает, что в дракон-схемах одинаковые иконы повторяются несколько раз. Например, на рис. 23а икона “Отдай мотоцикл в ремонт и впредь будь умнее” встречается три раза. Это плохо: навязчивые повторения раздражают читателя, которому приходится тратить лишнее время и несколько раз читать одно и то же. К счастью, некоторые повторы можно устранить. Такая возможность появляется, если одинаковые иконы соседствуют друг с другом, причем их выходы соединены между собой (рис. 23а). В этом случае действует правило “повторы запрещены”. Устранение повторов производится с помощью вертикальной линии (рис. 23б) и называется вертикальным объединением. Нетрудно доказать, что операция “вертикальное объединение” осуществляет равносильное преобразование алгоритмов.

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

Сравнивая алгоритмы на рис. 23а и б, легко заметить, что схема на рис. 23б обладает более высоким эргономическим качеством: она стала более компактной, ясной и наглядной, поскольку освободилась от бессмысленного повторения икон. Отсюда проистекает вывод: равносильное преобразование “вертикальное объединение” позволяет улучшить эргономичность алгоритмов.

Иногда для исключения повторов используется не вертикальная, а горизонтальная линия. Соответствующая операция называется горизонтальным объединением. Она также является равносильным преобразованием.

Рассмотрим пример на рис. 24а. Сначала с помощью горизонтального объединения устраним повторение иконы “Съешь кашу” и получим схему на рис. 24б. Затем применим вертикальное объединение и исключим повторение развилки “Есть можно?”. Окончательный результат показан на рис. 24в. Полученная схема более удобна и занимает меньше места, чем исходная схема на рис. 24а.

Разобранный пример показывает, что равносильное преобразование “горизонтальное объединение” также улучшает эргономичность алгоритмов.

П р е д о с т е р е ж е н и е: выполняя вертикальное и горизонтальное объединение, нужно следить, чтобы не появились пересечения соединительных линий (рис. 25).

ЭРГОНОМИЧНОСТЬ ЛИТЕРАЛЬНЫХ АЛГОРИТМОВ

Можно ли улучшить эргономичность литеральных дракон-схем с помощью равносильных преобразований? Мы уже знаем, что рокировка в этом случае бесполезна. Однако вертикальное и горизонтальное объединение позволяют заметно повысить эргономичность литеральных схем.


23


24


24-25


Чтобы убедиться в этом, обратимся к рис. 26 и 27. В самом деле, схема на рис. 26а выглядит неоправданно громоздкой: она содержит семь вертикалей, тринадцать икон и заставляет читателя шесть раз читать идентификатор В, чтобы убедиться, что правые шесть икон одинаковые. А равносильная ей схема на рис. 26б (полученная методом вертикального объединения) свободна от этого недостатка. Она наглядна, проста и изящна, содержит только две вертикали и восемь икон, занимает втрое меньше места на листе бумаги (на экране) и к тому же имеет всего два прямоугольных излома линий (на рис. 26а — семь изломов). Таким образом, литеральная схема на рис. 26б более эргономична, чем ее соседка.

Еще более громоздкой выглядит литеральная схема на рис. 27а, в которой насчитывается 14 вертикалей. А равносильная ей схема на рис. 27б (полученная методом вертикального и горизонтального объединения) снова выигрывает: позволяет уменьшить число вертикалей почти в пять раз (с 14 до 3), сокращает число икон более чем в три раза (с 65 до 21), обеспечивает более экономное топологическое упорядочивание маршрутов, заметно сокращает суммарную длину соединительных линий.

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



что делать, если эргономические требования
противоречат друг другу?

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

  •  правило главного и побочного маршрутов,
  •  минимизация числа вертикалей.

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

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

Чтобы исправить недостаток, необходимо выполнить:

  •  вертикальное разъединение в точке С (эта операция обратна вертикальному объединению);
  •  рокировку развилки “Заболел?”;
  •  рокировку развилки “Врач помог?”.

В итоге получим схему на рис. 28б, где все маршруты упорядочены слева направо по принципу “чем правее — тем хуже”. В самом деле, левая вертикаль означает, что дела идут хорошо, ибо человек здоров; значит, главный маршрут идет по шампуру. Вторая вертикаль показывает легкое недомогание, которое можно снять таблеткой. Третья вертикаль говорит: самочувствие ухудшилось, нужен врач. Наконец, четвертая (крайняя правая) вертикаль означает, что дела обстоят плохо — пришлось лечь в больницу.

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

ИКОНА-ВСТАВКА КАК ЭРГОНОМИЧЕСКИЙ ПРИЕМ

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

Тогда можно взять бумагу больших размеров, например формата А1. А если схема громадная и все равно не помещается? На этот случай предусмотрены специальные приемы, позволяющие уменьшить габариты дракон-схемы и разрубить ее на куски. Эти приемы позволяют разместить дракон-схему на листах желаемого размера. Рассмотрим проблему на “миниатюрном” примере.

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

На рис. 29 показаны два варианта решения проблемы. Алгоритм на рис. 29а не годится, так как на участке АВ рабочая точка движется вверх, что запрещено правилами языка ДРАКОН. Преодолеть затруднение можно двумя способами: применить конструкцию “силуэт” (о которой шла речь в гл. 6) либо разделить алгоритм на две части. Рассмотрим последний способ. Для этого удалим из алгоритма несколько связанных по смыслу икон, а вместо них нарисуем икону-заместитель, которая называется вставкой (рис. 29б). Вставка нужна, чтобы напомнить об изъятых иконах. Вставка занимает мало места — намного меньше, чем выброшенные иконы, поэтому алгоритм становится короче. Разумеется, выброшенные иконы не пропадают — они образуют новый алгоритм — алгоритм-вставку.

Икона-вставка — это команда “Передай управление в алгоритм-вставку” (рис. 30). Икона “конец” алгоритма-вставки означает: “Верни управление в основной алгоритм”. При этом управление возвращается в точку, расположенную после иконы-вставки. На языке программистов алгоритм-вставка — это процедура, а икона-вставка — это оператор “Вызов процедуры”.

ЧТО ТАКОЕ ПОДСТАНОВКА?

Операция “подстановка” связана с использованием иконы-вставки. Она выполняется за три шага.

Шаг 1. Из дракон-схемы удаляется фрагмент, имеющий один вход и один выход.

Шаг 2. Вместо него подставляется икона-вставка с именем Х.

Шаг 3. К удаленному фрагменту добавляется икона-заголовок с тем же именем Х и икона-конец; в результате получается алгоритм-вставка.

Два алгоритма на рис. 29 неравносильны: их формулы не совпадают, поскольку маршрут на рис. 29а содержит 14 икон, а на рис. 29б — 17 икон (см. также рис. 30). Вместе с тем нетрудно убедиться, что подстановка — эквивалентное преобразование алгоритмов, так как исходный и преобразованный алгоритмы дают одинаковые результаты для одних и тех же исходных данных. Попутно заметим, что равносильные алгоритмы всегда эквивалентны (обратное неверно). Таким образом, операция “подстановка” представляет собой эквивалентное (но не равносильное) преобразование алгоритмов.


рис. 29


рис. 30


Рис. 31 — на 2 стр.



УЛУЧШЕНИЕ ЭРГОНОМИЧНОСТИ АЛГОРИТМОВ
С ПОМОЩЬЮ ЦЕПОЧКИ
ЭКВИВАЛЕНТНЫХ ПРЕОБРАЗОВАНИЙ

Когда рисуешь алгоритм, нужно стремиться, чтобы он с самого начала удовлетворял правилам и был эргономичным. А если это не получилось? Если первый блин комом, как на рис. 31а? В этом случае необходимо довести алгоритм до ума с помощью последовательности эквивалентных преобразований. Вообще говоря, в примере на рис. 31а достаточно сделать всего две рокировки (преобразовав обе развилки)
и мы сразу получим нужный ответ — искомую эргономичную схему на рис.
 31д.

Однако, чтобы сделать изложение более наглядным, лучше избрать другой путь и двигаться к цели мелкими шажками. Для начала используем визуальную формулу на рис. 32 и с ее помощью заменим нижнюю развилку на рис. 31а на икону-вставку “Приведи комнату в порядок”. Результат подстановки представлен на рис. 31б. Затем выполним рокировку и получим схему на рис. 31в. После этого произведем обратную подстановку по формуле на рис. 32 и заменим икону-вставку на развилку “Чернильница разбилась?” Полученная схема показана на рис. 31г. Наконец, делаем еще одну рокировку и приходим к искомой эргономичной схеме на рис. 31д.

Для удобства читателя на рис. 33 дана общая сводка эквивалентных преобразований.


ВЫВОДЫ

1. Понятие эргономичного алгоритма весьма актуально. Применение достижений эргономики к теории алгоритмов позволяет значительно улучшить понимаемость алгоритмов и программ.

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

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


Г Л А В А  8

Визуализация циклов

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

Наталья Завалова, Борис Ломов,
Владимир Пономаренко

ОБЫЧНЫЙ ЦИКЛ

В языке ДРАКОН имеется следующий ассортимент циклов:

  •  обычный цикл;
  •  переключающий цикл;
  •  цикл ДЛЯ;
  •  веточный цикл;
  •  цикл ЖДАТЬ.

Первые четыре цикла рассматриваются в этой главе, цикл ЖДАТЬ — в гл. 11.


рис. 37


рис. 38 и 39


рис. 40 и 41


рис. 42


рис. 43 и 44


Составной визуальный оператор “обычный цикл” (рис. 2, макроикона 4) содержит иконы “вопрос” и “петля цикла” (рис. 1, иконы И4, И24). Он охватывает циклы трех типов (рис. 34—36):

  •  цикл ДО (do-while),
  •  цикл ПОКА (while-do),
  •  гибридный цикл (do-while-do).

Примеры циклов ПОКА и ДО приведены на рис. 37, 38. Досрочный выход из цикла показан на рис. 39—42. Конструкция “цикл в цикле” представлена на рис. 43—45.

Анализируя рисунки, можно заметить следующие особенности.

  •  Оператор “обычный цикл” имеет один вход и один или несколько выходов.
  •  Цикл с одним выходом представляет собой шампур-блок (вход и выход находятся на одной вертикали).
  •  Если цикл имеет более одного выхода, основной выход размещается на главной вертикали, дополнительные — правее ее.
  •  Петля цикла находится правее главной вертикали и закручена против часовой стрелки.
  •  Икона “вопрос” задает условие цикла, которое распадается на две части: условие продолжения и условие окончания (рис. 37).
  •  Условие продолжения соответствует правому выходу иконы “вопрос”, условие окончания — нижнему.
  •  Условие окончания может помечаться как словом “нет”, так и словом “да”. То же самое относится и к условию продолжения.

ПЕРЕКЛЮЧАТЕЛЬ И ПЕРЕКЛЮЧАЮЩИЙ ЦИКЛ

Предположим, в алгоритме нужно организовать разветвление на несколько направлений. Задачу можно решить двумя способами: с
помощью иконы “вопрос” (рис. 46
а) и с помощью переключателя (рис. 46б).

Переключатель — составной визуальный оператор (рис. 2, макроикона 3), имеющий один вход и один выход, содержащий одну икону “выбор” и несколько (две и более) икон “вариант” (рис. 1, иконы И5, И6). Внутри иконы “выбор” делается надпись, обычно в утвердительной форме, которая обозначает вопрос, имеющий строго определенное число ответов (два и более). Ответы записываются в иконах “вариант”. Таким образом, число вариантов равно числу ответов. Говоря формально, в иконе “выбор” записывается переменная, в иконах “вариант” — ее значения. На рис. 46б переменная “Светофор” принимает три значения: зеленый, желтый, красный.

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

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

ЦИКЛ ДЛЯ

На рис. 49 и 50 показаны два варианта решения простой математической задачи. В первом случае используется цикл ДО, во втором — цикл ДЛЯ. Цикл ДЛЯ — составной визуальный оператор (рис. 2, макроикона 6), содержащий иконы “начало цикла ДЛЯ” и “конец цикла ДЛЯ” (рис. 1, иконы И12, И13), между которыми располагаются одна или несколько других икон. Внутри иконы “начало цикла ДЛЯ” указываются переменная цикла, ее начальное и конечное значения и шаг.  Порядок


46


записи этих величин определяется выбранным вариантом текстового синтаксиса. На рис. 50 изображен вариант, по умолчанию принимающий, что шаг равен 1.

ВЕТОЧНЫЙ ЦИКЛ

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

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


рис.48, 49, 50


51, 52


53


При замене примитива на эквивалентный ему силуэт гибридный цикл нередко превращается в веточный цикл. В этом легко убедиться, сравнив эквивалентные алгоритмы на рис. 41 и 53.

ГЛАВНЫЙ МАРШРУТ СИЛУЭТА

В этом параграфе мы продолжим изучение веточных циклов и попытаемся ответить на вопрос: как найти главный маршрут веточного цикла? Для этого нужно проанализировать понятие “главный маршрут силуэта” (рис. 54).

Линейный (неразветвленный) силуэт имеет один-единственный маршрут, который и является главным. Он проходит по шампурам всех веток и по всем иконам силуэта (рис. 54а).

Формула маршрута для силуэта имеет особенность: одноименные иконы “адрес” и “имя ветки” обозначаются одной буквой, которая повторяется в формуле дважды. Например, силуэт на рис. 54а имеет формулу

где парные буквы обозначают переход с первой ветки на вторую (СС) и со второй на третью (DD).

Ветка называется одноадресной, если она имеет одну икону “адрес”. Если все ветки одноадресные, силуэт считается одноадресным.

Линейный силуэт всегда одноадресный. Однако одноадресный силуэт может быть и разветвленным. В последнем случае его главный маршрут следует по шампурам всех веток, однако он не проходит по всем иконам (рис. 54б).

Если хотя бы одна ветка имеет более одного адреса, может сложиться ситуация, когда какие-то ветки не попадают на главный маршрут. На рис. 54в икона-адрес D лежит на побочном маршруте. Это приводит к тому, что ветка D также оказывается на побочном маршруте. В результате главный маршрут проходит по шампурам всех веток, кроме ветки D (рис. 54в).

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

  •  одноветочные (если цикл помещается в одной ветке);
  •  двухветочные (если цикл занимает две ветки);
  •  трехветочные (цикл в трех ветках)

и т. д.

Как работает одноветочный цикл? Предположим, до начала выполнения цикла на рис. 54г имеют место условия


54


Предположим также, что веточный цикл выполняется два раза, после чего условие Е принимает значение “нет”. Это значит, что при третьем проходе по ветке В произойдет выход из цикла по пути “Е нет С”. В такой ситуации формула главного маршрута для силуэта на рис. 54г принимает вид:

Как выглядит главный маршрут на дракон-схеме? Ответ изображен жирной линией на рис. 54г. Мы видим, что главный маршрут как бы разветвляется в иконе Е и проходит через оба ее выхода. Разумеется, это условность, которая означает следующее. Сначала (когда Е = да) главный маршрут идет по шампуру, затем (когда выполняется условие окончания цикла Е = нет) главный маршрут проходит через правый выход иконы Е.

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

Если в веточном цикле слишком много икон, он может не поместиться в одной ветке. К счастью, его можно разделить на части. Например, веточный цикл на рис. 54д содержит пять икон: Е, F, G, H, R (иконы “имя ветки” и “адрес” не в счет). Поместим иконы Е и F в ветку В,
а иконы
G, H, R — в ветку С. В результате цикл станет двухветочным. Главный маршрут силуэта с двухветочным циклом имеет разветвление в иконе R. Условие R = да позволяет вернуться к началу цикла. Если
R = нет, главный маршрут ведет нас к концу алгоритма (рис. 54д).

Таким образом, двухветочный цикл — это цикл, содержащий две ветки Х и Y, причем в ветке Х имеется икона-адрес Y, а в ветке Y — икона-адрес Х.

На рис. 54е представлена ситуация “цикл в цикле”: веточный цикл С находится внутри веточного цикла В. Из рисунка видно, что в этом случае главный маршрут “разветвляется” дважды: в иконах R и J.

Если выполняется условие R = да, происходит повторение внутреннего цикла С. При сочетании условий

производится выход из цикла С и повторение внешнего цикла В. Наконец, сочетание условий

означает, что выполнение цикла В и алгоритма в целом заканчивается.

ВЫВОДЫ

1. В различных текстовых языках при описании циклов применяются разные наборы ключевых слов, имеющих к тому же разную семантику. Неразбериху усугубляют отличия в логике окончания цикла. Например, в языке Си для циклов while и do-while условие окончания цикла соответствует значению false или 0, условие продолжения — значению true или 1. В языке Паскаль картина иная: в цикле while-do выход из цикла соответствует значению false, а в цикле repeat-until по каким-то загадочным причинам применяется диаметрально противоположный принцип: выход из цикла производится, когда логическое выражение принимает значение true. Все эти путаные правила программист обязан знать и неукоснительно выполнять.

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

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

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

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


Г Л А В А  9

Визуализация логических
формул

Существует форма представления информации наглядная, броская, понятная всем с детства. Такой формой является графика.

Валерий Венда

ВИЗУАЛИЗАЦИЯ ФУНКЦИИ И

— Где можно купить щенка?

— В нашем городке они продаются на рынке, но сегодня рынок закрыт. К тому же щенков продают не каждый день. Щенки довольно дорогие и какие-то невзрачные — не знаю, понравятся ли они вам.

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

  •  рынок открыт (обозначим это условие через Р);
  •  у покупателя деньги есть (Q);
  •  щенки есть в продаже (R);
  •  щенок понравился (S).

В итоге получаем логическую функцию

где Х означает “Можно купить щенка?” (рис. 55).

В традиционных языках программирования значениями логических переменных считаются пары (ИСТИНА, ЛОЖЬ) или (1, 0). С эргономической точки зрения, такой подход нельзя признать удачным. В самом деле, использование “шибко мудреных” слов ИСТИНА и ЛОЖЬ или
таинственных цифр 1 и 0 в примере о щенках (как и в любом другом конкретном примере) является надуманным, дезориентирующим и не содействует пониманию существа вопроса.

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


55. 56


57


58, 59


60


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

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

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

ВИЗУАЛИЗАЦИЯ ФУНКЦИИ ИЛИ

Логическая функция ИЛИ принимает значение “да”, если хотя бы одна логическая переменная имеет значение “да”. Функция принимает значение “нет”, если все логические переменные имеют значение “нет” (рис. 58).

На языке ДРАКОН функцию ИЛИ можно записать двумя способами. Если выбран текстовый способ, рисуют одну икону “вопрос”, содержащую логическое выражение (рис. 59 слева). При визуальном способе используют несколько икон “вопрос”, у которых объединяют нижний выход; в каждой иконе пишут одну логическую переменную (рис. 59 справа). Из рис. 59 и 60 видно, что оба метода эквивалентны.

ВИЗУАЛИЗАЦИЯ ФУНКЦИИ НЕ

Функция W =  называется функцией НЕ, если логические переменные Z и W принимают инверсные значения, т. е. удовлетворяют условиям:

если    Z = да,    то    W = нет;

если    Z = нет,    то    W = да.


61-66


67


68-73


74


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

Упражнения на рис. 62—66 помогут читателю закрепить материал.

ВИЗУАЛИЗАЦИЯ СЛОЖНЫХ ЛОГИЧЕСКИХ ФУНКЦИЙ

Рассмотрим функцию

Х = (A  и    и  C)   или   (D  и  E  и  )

(1)

На рис. 67 показан визуальный способ записи этой функции. Из рисунка видно, что формула (1) разбивается на три части:

1)  А и  и С;       2)  D и Е и ;       3)  Операция “или”.

Функция А и  и С изображается с помощью трех икон А, В, С,
расположенных на одной вертикали. Аналогично рисуют функцию
D и Е и . Связка “или” реализуется с помощью линий, объединяющих нижние выходы икон С и F в точке K (рис. 67).

В формуле (1) некоторые члены записаны без логического отрицания (А, В, D, Е), другие — с отрицанием (, ). Члены без отрицания превращаются в иконы А, В, D, Е, у которых нижний выход помечен словом “да”. Членам с отрицанием соответствуют иконы В и F, где нижний выход помечен словом “нет” (рис. 67). Другие примеры алгоритмов, вычисляющих сложные логические функции, представлены на рис. 68—74.

Изложенные соображения позволяют сформулировать две теоремы.

Теорема 1.  Дракон-схему, содержащую логические связки И, ИЛИ, НЕ внутри икон “вопрос”, всегда можно преобразовать в эквивалентную дракон-схему, не содержащую указанных связок.

Теорема 2.  Если некоторый фрагмент дракон-схемы имеет один вход, два выхода и содержит только иконы “вопрос”, причем первый выход вычисляет функцию X, то второй выход вычисляет ее логическое отрицание  (рис. 67—73).

Доказательство теорем предоставляем читателю.

ВЫВОДЫ

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

2. В языке ДРАКОН используются визуальные логические выражения, позволяющие при желании полностью исключить логические связки И, ИЛИ, НЕ из условных операторов.

3. Визуализация логических формул во многих практически важных случаях заметно облегчает их понимание и уменьшает вероятность ошибок.


Г Л А В А  10

Что такое эргономичный текст?

Все в алгоритме понятно и ясно,
Если он сделан эргономично.
Эргономично — это прекрасно!
Эргономично — значит отлично!

МОЖНО ЛИ СДЕЛАТЬ ЛОГИЧЕСКИЕ ВЫРАЖЕНИЯ
ЭРГОНОМИЧНЫМИ?

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

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

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

ПРИМЕР ДЛЯ ИССЛЕДОВАНИЯ ЭРГОНОМИЧНОСТИ
ЛОГИЧЕСКИХ ВЫРАЖЕНИЙ

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

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

Логический признак, разрешающий (или запрещающий) роботу ехать вперед, имеет идентификатор “Можно.ехать.через.перекресток”. Будем считать, что данный признак принимает значение “да” в трех случаях:

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

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

Введем обозначения, показанные на рис. 76, которым соответствуют очевидные равенства:

Y = Можно.ехать.через.перекресток  (1)

А = Зеленый.сигнал.светофора  (2)

В = Желтый.сигнал.светофора (3)

С = Красный.сигнал.светофора (4)

D = Робот.выехал.на.перекресток (5)

Е = Помехи.для.движения  (6)

Если принять указанные условия и обозначения, логическая функция Y задается формулой

Y = (A & ┐E)(B & D & ┐E)(┐A & ┐B & ┐C & ┐E) (7)

Пример, представленный на рис. 75 и 76, позволяет приступить к изучению проблемы. Ниже мы рассмотрим несколько вариантов записи логических выражений и сравним их между собой с эргономической точки зрения. При этом предполагается, что робот имеет пять датчиков, формирующих логические сигналы А, В, С, D, E, которые поступают в бортовой компьютер, управляющий движением робота.

ЛОГИЧЕСКОЕ ВЫРАЖЕНИЕ
С АБСТРАКТНЫМИ ИДЕНТИФИКАТОРАМИ

Произведем эквивалентное преобразование алгоритма на рис. 75. Учитывая равенство (1) заменим идентификатор “Можно.ехать.через. перекресток” буквой Y, после чего вместо Y подставим логическое выражение из формулы (7). В результате получим алгоритм на рис. 77.

Некоторые математики скорее всего похвалят этот алгоритм. Они, возможно, скажут, что с математической точки зрения выражение в иконе “вопрос” является компактным, лаконичным, изящным и обозримым18.


75-79


К сожалению, подобная позиция не учитывает эргономических соображений и является устаревшей. Сразу оговоримся: речь, разумеется, идет не о том, чтобы заменить математику эргономикой, а всего лишь о том, чтобы, сохраняя математическую строгость в неприкосновенности, решительно отказаться от эргономической беспечности традиционных математических построений. Это означает, что однобокий математический подход должен уступить место системному подходу, в котором органически сочетаются математические и эргономические методы. Для обозначения нового подхода можно предложить термин “когнитивная формализация знаний”.

Сделаем еще одну оговорку. Формула (7) была бы вполне приемлемой, если бы речь шла об абстрактной задаче, цель которой — выявить математическую сущность проблемы. Однако в данном случае речь идет о прикладной задаче — создании программы управления автомобилем-роботом.

Недостаток формулы (7) и алгоритма на рис. 77 состоит в том, что идентификаторы А, В, С, D, Е не смысловые, а абстрактные. Они оставляют наши знания о предметной области за пределами программного текста.

Чем это плохо? Вспомним, что сегодня критической проблемой являются не машинные, а человеческие ресурсы, причем экономия последних теснейшим образом связана с проблемой понимания, которая превращается в центральную проблему информатики. Производительность труда при создании информационных систем и систем управления напрямую зависит от успешного решения проблемы понимания, обеспечивающего быструю и безошибочную разработку алгоритмов и программ. Это общее положение тесно связано с обсуждаемым вопросом. В самом деле, люди, которые прекрасно знают прикладную задачу и предметную область, но не знают или забыли обозначения (1)—(6), например заказчики, постановщики задач, комплексники и т. д., воспринимают идентификаторы А, В, С, D, Е и составленные из них формулы как бессмысленный набор символов. Следовательно, эти люди лишаются возможности принять участие в проверке правильности алгоритмов и программ и внести свой вклад в устранение ошибок.

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

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


ЛОГИЧЕСКОЕ ВЫРАЖЕНИЕ
С КОРОТКИМИ СМЫСЛОВЫМИ ИДЕНТИФИКАТОРАМИ

Абстрактные идентификаторы использовались на первом этапе развития программирования. Сегодня в прикладных программах они встречаются гораздо реже, уступив место так называемым мнемоническим именам, т. е. коротким смысловым идентификаторам, которые в большинстве случаев имеют длину до восьми символов. Преобладание восьмисимвольных идентификаторов характерно для второго этапа развития языков программирования. Вот типичная рекомендация этого периода: “не оправдано применение имен, подобных Х или I, тогда как имена МАХ или NEXT передают смысл гораздо точнее”.

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

Таблица 2

Абстрактный идентификатор

Мнемоническое имя

Y

Можнех

A

Зелсиг

B

Желсиг

C

Красиг

D

Робнапер

E

Пом

На рис. 78 показан алгоритм, полученный в результате такой замены. Можно ли назвать логическое выражение на рис. 78 эргономичным? Очевидно, что мнемонические имена лучше абстрактных. Они были придуманы с благородной целью — облегчить запоминание понятий, чтобы формальное имя создавало намек на содержательную сторону дела. Увы! Говорить намеками — вовсе не значит говорить понятно. Причина неудачи в том, что длина идентификатора восемь символов слишком мала и явно недостаточна для хорошего, ясного и доходчивого описания сложных понятий. Поэтому при создании восьмисимвольных идентификаторов приходится экономить каждый символ и часто использовать невразумительные слова-обрубки, такие, как Зелсиг (зеленый сигнал светофора), Красиг, Желсиг и т. д.

В самом деле, глядя на идентификатор “Робнапер” (рис. 78) мало кто догадается, что речь идет о признаке “Робот.выехал.на.перекресток”.

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

ЛОГИЧЕСКОЕ ВЫРАЖЕНИЕ
С ДЛИННЫМИ СМЫСЛОВЫМИ ИДЕНТИФИКАТОРАМИ

Для третьего этапа развития языков программирования, который начался сравнительно недавно, характерен переход к длинным смысловым идентификаторам, содержащим до 32 символов. Здесь необходимо уточнение. Некоторые трансляторы делят идентификаторы на две части, обрабатывая только первую часть и игнорируя вторую. В результате разные идентификаторы, имеющие различие в последних символах, рассматриваются транслятором как тождественные. Такие случаи мы исключаем из рассмотрения. При дальнейшем изложении подразумевается, что все инструментальные программы, включая транслятор, обеспечивают необходимую программную обработку всех 32 символов идентификатора.

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

Пример логического выражения, в котором используются идентификаторы с точками-разделителями и полными (несокращенными) словами, представлен на рис. 79. Легко видеть, что оно обладает более высокой понимаемостью, чем предыдущие примеры. Тем не менее здесь есть одно “но”.

ВАЖНЫЙ МОМЕНТ,
О КОТОРОМ ЧАСТО ЗАБЫВАЮТ

На рис. 75 записан вопрос “Можно.ехать.через.перекресток”, который объясняет принцип разветвления алгоритма: при ответе “да” выполняется команда “Ехать.вперед”, при ответе “нет” действия отсутствуют. Данный вопрос играет ключевую роль: если его удалить, алгоритм становится непонятным. В связи с этим целесообразно ввести понятие главный вопрос условного оператора.

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

Таким образом, логические выражения на рис. 77—79 имеют общий недостаток, причем весьма существенный. В них нет главного вопроса, нет ключа, объясняющего сущность алгоритма. Налицо парадокс: логические выражения не дают явной информации о том, на какой именно вопрос мы отвечаем “да” или “нет”. Более того, они не позволяют читателю легко и быстро восстановить формулировку главного вопроса и не стимулируют у него стремления к получению подобной информации. Не будет преувеличением сказать, что перечисленные логические выражения затуманивают суть дела, поскольку отсутствие главного вопроса ничем нельзя компенсировать. В итоге алгоритмы на рис. 77—79 оказываются непонятными и эргономически неприемлемыми. Отсюда вытекает, что использование эргономически правильных длинных смысловых идентификаторов является необходимым, но отнюдь не достаточным условием для построения эргономичного логического текста.

КАК ПРИСВОИТЬ ЗНАЧЕНИЕ ЛОГИЧЕСКОЙ
ПЕРЕМЕННОЙ?

Мы уже говорили, что в традиционных языках для значений логических переменных используют слова TRUE и FALSE, ИСТИНА и ЛОЖЬ, 1 и 0. Однако логико-эргономические исследования показывают, что указанные обозначения являются избыточными и могут быть безболезненно и с пользой для дела исключены из программных текстов. Стремление “уничтожить” лишние обозначения объясняется эргономическими причинами, так как все ненужные записи являются визуальными помехами, которые засоряют текст программы и путают читателя.

Язык ДРАКОН позволяет решить задачу двумя способами. В первом случае применяется икона “действие”, внутри которой записывается оператор присваивания (рис. 80). Визуальный оператор на рис. 80 означает, что идентификатору “Можно.ехать.через.перекресток” присваивается некоторое значение. Какое именно? Для этого нужно вычислить рамочное логическое выражение, записанное в трех рамках, соединенных знаками ИЛИ. Результатом вычисления будет “1” или “0”. Таким образом, цель достигнута, хотя обозначения “1” и “0” в программном тексте отсутствуют.

Во втором случае используется икона “полка” (рис. 1, икона И10), на верхнем этаже которой пишут зарезервированное предложение “Установить признак” или “Снять признак”. На нижнем этаже указывают идентификатор признака. Операторы языка ДРАКОН

означают, что логической переменной “Норма.насоса” присваивается значение “1” и “0” соответственно. Еще один пример использования иконы “полка” показан на рис. 81.

Легко видеть, что на рис. 81 используется та же хитрость, что и на рис. 80, а именно: логической переменной присваивается значение “1” или “0”, хотя обозначения “1” и “0” в тексте программы нигде не встречаются!


ПРАВИЛА ЗАПИСИ
РАМОЧНЫХ ЛОГИЧЕСКИХ ВЫРАЖЕНИЙ

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

  •  В иконе “действие” размещают один оператор присваивания.
  •  В верхней строке пишут идентификатор логической переменной и знак присваивания.
  •  Ниже пишут логическое выражение, причем каждая конъюнкция заключается в прямоугольную рамку.
  •  Для операций И, ИЛИ, НЕ используют обозначения &, ИЛИ, ┐ соответственно.
  •  Используют идентификаторы длиной до 32 символов.
  •  Первые символы всех идентификаторов располагают на одной вертикали.
  •  Знак отрицания ┐ пишут слева от идентификатора.
  •  Все знаки отрицания (если они есть) помещают на одной вертикали.
  •  Знаки конъюнкции & записывают справа от идентификатора.
  •  Все знаки конъюнкции пишут на одной вертикали.
  •  Вертикальные линии рамок располагают на одной вертикали.
  •  Знаки  =  и  ИЛИ помещают на одной вертикали.

КАК ПОСТРОИТЬ ЭРГОНОМИЧНЫЙ ЛОГИЧЕСКИЙ ТЕКСТ?

Ранее мы пришли к выводу, что алгоритм на рис. 79 является эргономически неудачным. Каким образом можно его исправить? Вопрос отнюдь не простой. По-видимому, в разных ситуациях он может приводить к разным ответам. В связи с этим изложенные ниже соображения и советы имеют не обязательный, а всего лишь рекомендательный характер. Их нужно рассматривать как один из возможных способов решения проблемы.

  •  В иконе “вопрос” не следует записывать логическое выражение, в особенности сложное. Вместо него рекомендуется поместить один-единственный идентификатор, содержащий ясную и четкую словесную формулировку главного вопроса.
  •  В общем случае указанный идентификатор может оказаться неопределенным. Чтобы исключить эту неприятность, необходимо заблаговременно присвоить ему нужное значение. Для этого существуют два метода: рамочный и визуальный.
  •  В рамочном методе используется рамочное логическое выражение, записанное в иконе “действие”. Производится вычисление рамочного выражения, результат присваивается идентификатору главного вопроса (рис. 80).
  •  В визуальном методе применяется визуальное логическое выражение и два оператора “Установить признак” и “Снять признак”, записанные в иконах “полка”.


80, 81


В отличие от рамочного при визуальном методе вычисление логического выражения как таковое отсутствует. Визуальное выражение разветвляет процесс и приводит его в одну из двух точек (А или В на рис. 81). В первой точке выполняется оператор “Установить признак”, во второй — “Снять признак”. Алгоритмы на рис. 80 и 81 эквивалентны.

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

Оптимальная длина формального смыслового идентификатора составляет примерно 32 символа. Имеется в виду, что инструментальные программы осуществляют обработку 32-байтового поля идентификатора. Желательно, чтобы конкретные идентификаторы в зависимости от сложности понятия имели длину не менее 25 и не более 32 символов. Чтобы исключить ошибки при ручном вводе столь длинных идентификаторов в компьютер, целесообразно ввести запрет повторного ввода. Это значит, что идентификатор вводится в систему только один раз и запоминается в базе данных. При необходимости повторного ввода осуществляется копирование из базы данных. Такой способ требует наличия специальных инструментальных средств, но гарантирует идентичность всех копий одного и того же идентификатора.

Вывод об оптимальности 32-символьных идентификаторов согласуется с анализом истории развития языков программирования, который обнаруживает отчетливую тенденцию: от абстрактных кодов и имен к
8-символьным мнемоническим именам, а затем — к 32-символьным смысловым идентификаторам. Вместе с тем многие программисты, следуя устоявшимся привычкам, “застряли” на этапе 8-символьных имен, так что опыт использования новых возможностей, связанных с разрешением использовать 32 символа, пока еще относительно невелик. Между тем, эргономические перспективы, открывающиеся с увеличением длины до 32 символов, обещают существенно изменить наши прежние представления и привычки, так как благодаря этому замечательному нововведению язык формальных идентификаторов по своей доходчивости значительно приближается к естественному человеческому языку, что отчетливо видно на рис. 80 и 81. В самом деле, множество 32-символьных идентификаторов образует весьма выразительный, хотя и своеобразный язык, законы и правила оптимизации которого еще предстоит открыть, обсудить и подвергнуть экспериментальной проверке.

Специальные обозначения для значений логических переменных как принадлежность языка программирования — это анахронизм, который следует исключить из всех языков как совершенно не нужное и даже вредное “архитектурное излишество”. Чтобы оправдать этот вывод, сравним два выражения в условном операторе:

Если (Норма 1 = 1) & (Норма 2 = 1) & (Авария = 0), то... (10)

Если Норма 1 & Норма 2 & ┐Авария, то.... (11)

Формула (10) читается так:

Если признак “Норма 1” равен единице и признак “Норма 2” равен единице и признак “Авария” равен нулю, то…

(10а)

Формула (11) читается так:

Если есть признак “Норма 1” и есть признак “Норма 2”
и нет признака “Авария”, то…

(11а)

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

ВЫВОДЫ

1. Точкой роста современной науки являются междисциплинарные исследования, в частности на стыке логики и эргономики.

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

3. Предложен двухэтапный метод эргономизации логических выражений. На первом этапе производится разделение логических записей на две части, из которых одна подлежит визуализации, а другая сохраняется в текстовом виде. Второй этап — эргономизация обеих частей: визуальной и текстовой.

4. Эргономизация текстовой части включает, в частности, следующие приемы:

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


Г Л А В А  11

Визуальные операторы
реального времени

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

Александр Зенкин

СПИСОК ОПЕРАТОРОВ РЕАЛЬНОГО
ВРЕМЕНИ

В языке ДРАКОН имеется пять икон реального времени (рис. 1, иконы И16 — И20):

  •  пауза;
  •  период;
  •  пуск таймера;
  •  синхронизатор (по таймеру);
  •  параллельный процесс.

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

Икона “период” является принадлежностью цикла ЖДАТЬ (рис. 2, макроикона 7). Икона “синхронизатор” служит для образования тринадцати составных операторов (рис. 2, макроиконы 8—20).

Назначение операторов поясним, как всегда, на примерах.

ОПЕРАТОРЫ ВВОДА-ВЫВОДА

В языке ДРАКОН предусмотрены два визуальных оператора ввода-вывода: “вывод” (рис. 1, икона И14) и “ввод” (рис. 1, икона И15). Они не относятся к операторам реального времени и рассматриваются здесь только потому, что встречаются в ближайшем примере.

Из рис. 1 видно, что иконы ввода-вывода имеют мнемоническую форму: икона И14 содержит полую стрелку, направленную наружу, что символизирует “вывод”, а икона И15 — стрелку, направленную внутрь (ввод).  Оба оператора “двухэтажные”, причем на верхнем

этаже пишется ключевое слово или ключевая фраза, а на нижнем (в прямоугольнике) — содержательная информация, подлежащая вводу и выводу (рис. 82, 83).

ОПЕРАТОР “ПАУЗА”

Предположим, управляющий компьютер должен выдать серию электрических команд, которые по линиям связи передаются в исполнительные органы и вызывают срабатывание электромеханических реле. В результате происходит открытие трубопровода, включение насоса и другие операции, необходимые для функционирования управляемого объекта. Такая ситуация может встретиться во многих системах управления реального времени: при заправке топливом баллистических ракет, на атомных электростанциях, нефтеперерабатывающих заводах и т. д.

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

  •  выдать команду ОТКРЫТЬ.ТРУБОПРОВОД;
  •  подождать две минуты;
  •  выдать две команды: ВКЛЮЧИТЬ.НАСОС и ОТКРЫТЬ.ЗАСЛОНКУ;
  •  подождать 45 секунд;
  •  выдать команду ПОДАЧА.ТОПЛИВА;
  •  подождать три минуты;
  •  выдать команду ПУСК.АГРЕГАТА.

Соответствующая программа на языке ДРАКОН-2 представлена на рис. 82. Задержка выдачи команд реализуется с помощью иконы “пауза”, внутри которой указывается время необходимой задержки, например, 2 мин (2 минуты), 45 с (45 секунд) и т. д. Если говорить более точно, верхний оператор “пауза” на рис. 82 работает так: после выдачи команды ОТКРЫТЬ.ТРУБОПРОВОД в управляющем компьютере запускается виртуальный счетчик времени на 2 минуты, по окончании которых компьютер выдает в линию связи команды ВКЛЮЧИТЬ.НАСОС
и
ОТКРЫТЬ.ЗАСЛОНКУ.

ОПЕРАТОРЫ
“ПУСК ТАЙМЕРА” И “СИНХРОНИЗАТОР”

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

Исходя из этого, сформулируем задачу управляющего компьютера. Он должен:

  •  включить “секундомер”, т. е. обнулить и запустить виртуальный таймер;
  •  выдать команду ОТКРЫТЬ.ТРУБОПРОВОД;
  •  когда таймер отсчитает две минуты, выдать пару команд ВКЛЮЧИТЬ.НАСОС и ОТКРЫТЬ.ЗАСЛОНКУ;
  •  когда таймер отсчитает 2 минуты 45 секунд, выдать команду ПОДАЧА.ТОПЛИВА;
  •  когда таймер отсчитает 5 минут 45 секунд, выдать команду ПУСК.
    АГРЕГАТА.

Программа, реализующая описанный алгоритм, изображена на рис. 83. В ней используются операторы “пуск таймера” и “синхронизатор”, совместная работа которых обеспечивает нужный эффект.

Оператор “пуск таймера” порождает, обнуляет и запускает виртуальный таймер и присваивает ему имя А. Оператор “синхронизатор” задерживает выполнение размещенного справа от него визуального оператора до наступления момента, описанного в иконе “синхронизатор”. Например, синхронизатор А = 2мин 45с на рис. 83 задерживает выдачу команды ПОДАЧА.ТОПЛИВА до момента, когда таймер А отсчитает 2 минуты 45 секунд.

Сравнивая программы на рис. 82 и 83, можно заметить, что они почти эквивалентны. Почему почти?  Если взять идеальный случай и пред-


рис. 84


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

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

На рис. 84 представлен более сложный алгоритм, в котором используются операторы “пауза”, “пуск таймера” и “синхронизатор”.

В средней ветке изображена икона “пауза” с записью 2мин48с. Это означает, что после завершения процедуры ВОЛШЕБНЫЙ РЕМОНТ ТАРЕЛКИ отсчитывается пауза длительностью 2 минуты 48 секунд и только после этого производится снятие признака АВАРИЯ ТАРЕЛКИ. Еще одна четырехсекундная пауза предусмотрена в левой ветке.

В правой ветке есть икона “пуск таймера” с записью А = 0. Данный оператор порождает, обнуляет и запускает виртуальный таймер А. В той же ветке установлены три иконы “синхронизатор по таймеру” с записями А = 3мин, А = 5мин и А = 8мин. При этом вызов процедуры ВКЛЮЧИТЬ ТЕЛЕПОРТАЦИЮ произойдет не сразу, а только после того, как таймер А отсчитает 3 минуты. Соответственно включение в работу процедур ОТКЛЮЧИТЬ ГРАВИТАЦИЮ и ВЫХОД ИЗ АСТРАЛЬНОГО ТЕЛА будет задержано до тех пор, пока таймер А не примет значения 5 и 8 минут соответственно.

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

ЦИКЛ ЖДАТЬ

Предположим, требуется в течение трех минут ждать появления хотя бы одного из двух признаков ЛЕВЫЙ ДВИГАТЕЛЬ В НОРМЕ и ПРАВЫЙ ДВИГАТЕЛЬ В НОРМЕ. При наступлении этого события (появлении признака) необходимо включить плазменный реактор. Если же названные признаки отсутствуют, по истечении трех минут следует включить фотонный двигатель.

Для решения задачи на рис. 84 используются два оператора: пуск таймера Т, отсчитывающего три минуты, и цикл ЖДАТЬ. В состав последнего входит икона “период” и три иконы “вопрос”, в которых размещены надписи ЛЕВЫЙ ДВИГАТЕЛЬ В НОРМЕ?, ПРАВЫЙ ДВИГАТЕЛЬ В НОРМЕ? и Т > 3мин (последний оператор проверяет: значение таймера Т больше трех минут?). Если оба признака отсутствуют, а значение таймера не превышает трех минут, опрос условий периодически повторяется, причем период опроса указывается в иконе “период”. В данном примере он равен 4 секундам.

Как явствует из рисунка, работа цикла ЖДАТЬ закончится в момент обнаружения одного из ожидаемых признаков, а если они так и не появятся — через три минуты.

В общем виде цикл ЖДАТЬ показан на рис. 85. Он позволяет организовать режим ожидания признаков В, С, D, ..., Е. Если первым появится признак В, выполняется действие F. Если В отсутствует и первым придет признак С, реализуется действие G. И так далее. Операторы А и L обычно не используются.

Задача ожидания нескольких признаков (когда система должна по-разному реагировать на каждый признак) является одной из наиболее типичных при разработке систем управления реального времени. Цикл ЖДАТЬ предлагает чрезвычайно простое, удобное, наглядное и эффективное средство для ее решения, удовлетворяя тем самым важную потребность практики.

ОПЕРАТОР “ПЕРИОД”

Сравнивая макроиконы 4 и 7 на рис. 2 (обычный цикл и цикл ЖДАТЬ), мы видим, что они очень похожи. Поэтому во избежание путаницы нужно иметь какой-то различительный признак. Эту функцию выполняет икона “период”. Если она есть в петле цикла — перед нами цикл ЖДАТЬ. Если нет — обычный цикл.

Человек, который стоит на остановке и ждет появления трамвая или троллейбуса, воспринимает ожидание как нечто непрерывное. Однако программа реального времени организует ожидание как дискретный процесс и запускает цикл ЖДАТЬ периодически. Отсюда вытекает, что период — важная характеристика цикла ЖДАТЬ.

А теперь зададим самый интересный вопрос: как работает оператор “период”? Фокус в том, что на этот вопрос придется дать два совсем разных ответа.

С точки зрения человека, читающего программу на рис. 84, все обстоит очень просто: цикл ЖДАТЬ “крутится” по своей петле с периодичностью 4 секунды, пока не выполнится одно из трех условий, после чего произойдет выход из цикла. Таким образом, оператор “период” задает период повторения цикла ЖДАТЬ.

С точки зрения функционирования программы реального времени, дело обстоит иначе. Суть в том, что длительность периода отсчитывает не прикладная программа на рис. 84, а дракон-диспетчер, входящий в состав операционной системы реального времени. Оператор “период” означает выход из прикладной программы: управление переходит к дракон-диспетчеру (с одновременной передачей параметра 4с). Через каждые четыре секунды дракон-диспетчер передает управление в начало цикла ЖДАТЬ (точка А на рис. 84), и если все три условия дают ответ “нет”, оператор “период” всякий раз возвращает управление в дракон-диспетчер. Таким образом, функционирование цикла ЖДАТЬ обеспечивается совместными усилиями прикладной программы и дракон-диспетчера.

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

ОПЕРАТОР “ПАРАЛЛЕЛЬНЫЙ ПРОЦЕСС”

Пусть заданы два алгоритма А и В, причем А — основной алгоритм,
а
В — вспомогательный. Алгоритмы А и В могут работать последовательно (рис. 86) или параллельно (рис. 87). Чтобы организовать последовательную работу, необходимо в дракон-схеме основного алгоритма А нарисовать икону-вставку с надписью В. Например, на рис. 84 в основном алгоритме ПРОВЕРКА ЛЕТАЮЩЕЙ ТАРЕЛКИ имеется икона-вставка ПРОВЕРКА ДВИГАТЕЛЕЙ. Эти алгоритмы действуют последовательно. Основной алгоритм передает управление алгоритму ПРОВЕРКА ДВИГАТЕЛЕЙ и прекращает работу. Возобновление работы алгоритма ПРОВЕРКА ЛЕТАЮЩЕЙ ТАРЕЛКИ произойдет только тогда, когда алгоритм-вставка ПРОВЕРКА ДВИГАТЕЛЕЙ закончится. В общем виде ситуация показана на рис. 86.

Отличие параллельного режима состоит в том, что после начала вспомогательного алгоритма В основной алгоритм А не прекращает работу и действует одновременно с алгоритмом В (рис. 87).

Чтобы организовать параллельную работу, нужно в дракон-схеме основного алгоритма А нарисовать икону “параллельный процесс” (рис. 1, икона И20). Икона “двухэтажная”: на верхнем этаже пишут ключевое слово, обозначающее команду, изменяющую состояние параллельного процесса, например, “Пуск”, “Останов” и т. д. На нижнем этаже помещают идентификатор (название) параллельного процесса.


86, 87


Обратимся к примеру на рис. 84. В правой ветке находятся два оператора управления параллельными процессами. После окончания процедуры ВЫХОД ИЗ АСТРАЛЬНОГО ТЕЛА производится останов параллельного процесса ШАБАШ ЗЛЫХ ДУХОВ и пуск процесса ШАБАШ ДОБРЫХ ДУХОВ.

При этом предполагается, что до начала алгоритма ПРОВЕРКА ЛЕТАЮЩЕЙ ТАРЕЛКИ некий третий алгоритм выдал команду “Пуск” и запустил параллельный процесс ШАБАШ ЗЛЫХ ДУХОВ. Последний работает одновременно с алгоритмом ПРОВЕРКА ЛЕТАЮЩЕЙ ТАРЕЛКИ вплоть до момента выдачи команды “Останов” (см. последнюю ветку на рис. 84). Указанная команда ликвидирует параллельный процесс ШАБАШ ЗЛЫХ ДУХОВ, в этот момент одновременная работа заканчивается. Однако следующая команда “Пуск” запускает другой параллельный процесс — ШАБАШ ДОБРЫХ ДУХОВ, который начинает работать одновременно с алгоритмом ПРОВЕРКА ЛЕТАЮЩЕЙ ТАРЕЛКИ.

ОСОБЕННОСТИ ОПЕРАТОРОВ
РЕАЛЬНОГО ВРЕМЕНИ

Мы уже говорили, что цикл ЖДАТЬ выполняется прикладной программой при участии дракон-диспетчера. Этот вывод относится ко всем операторам реального времени. Вместе с тем следует подчеркнуть, что данное утверждение относится не к языку, а к реализации системы и для разных реализаций может быть различным.

Операторы реального времени — это формальные операторы языка визуального программирования ДРАКОН-2. Однако их можно использовать и в псевдоязыке ДРАКОН-1 при неформальном изображении алгоритмов — для построения наглядных “картинок”, позволяющих легко объяснить ту или иную идею, относящуюся к системам реального времени. Примеры таких картинок представлены на рис. 88 и 89. При этом в цикле ЖДАТЬ икону “период” обычно опускают, чтобы не загромождать рисунок (см. последнюю ветку на рис. 88). Однако если длительность периода нужна для понимания, икону “период” можно сохранить (рис. 89).

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

Дракон-программа может иметь более одного входа. Чтобы организовать дополнительный вход, нужно разместить икону “заголовок” над иконой “имя ветки”, как показано на рис. 84 справа. Таким образом любая ветка может быть объявлена дополнительным входом. Однако есть исключение: если несколько веток образуют веточный цикл, вход разрешается только в начало цикла. Остальные ветки конструкции “веточный цикл” не могут являться входами в программу.


рис. 88


89


ВЫВОДЫ

1. Наличие операторов реального времени резко расширяет изобразительные возможности языка ДРАКОН и позволяет использовать его при проектировании и разработке не только информационных, но и управляющих систем. Это обстоятельство существенно увеличивает область применения языка.

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

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

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

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


Г Л А В А  12

ДРУЖЕЛЮБНОЕ
Программирование

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

Том Мануэль

ГИБРИДНЫЙ ЯЗЫК ПРОГРАММИРОВАНИЯ
ДРАКОН-СИ

Предположим, нужно построить систему визуального программирования на гибридном языке ДРАКОН-СИ. Задачу можно решить, например, с помощью трех программ: дракон-редактора, дракон-конвертора и компилятора языка СИ. Пользователь с помощью дракон-редактора рисует на экране компьютера программу на языке ДРАКОН-СИ (рис. 90, правая графа). Затем дракон-конвертор преобразует внутреннее представление графических кодов в исходный текст языка СИ (рис. 90, средняя графа), после чего стандартный компилятор СИ превращает исходный текст в объектный код.

Чтобы лучше уяснить преимущества языка ДРАКОН-СИ, произведем мысленно обратное преобразование. Как видно из рис. 90, при преобразовании текстовой программы в визуальную исходный текст СИ-программы разбивается на две части. Операторы присваивания, условные выражения и декларативные описания почти без изменения переносятся в визуальную программу и размещаются внутри ее икон. Остальные текстоэлементы языка СИ (которые можно назвать удаляемыми или “паразитными”) становятся ненужными, превращаясь в графические линии и ключевые слова “да” и “нет” (yes и no). Рисунок 90 показывает, что список паразитных (удаляемых) элементов языка СИ оказывается внушительным: он включает все ключевые слова в примерах 1—7 кроме default, все фигурные, круглые и косые скобки, двоеточия, метки, комментарии в примерах 3—5, и кроме того, точки с запятой в примерах 2, 3, 7 и отчасти 6.

Таким образом, чтобы построить язык ДРАКОН-СИ, надо по определенным правилам соединить визуальный синтаксис ДРАКОНА с текстовым синтаксисом языка СИ, удалив из последнего все элементы, функции которых реализуются визуальными операторами ДРАКОНА. Пара языков СИ и ДРАКОН-СИ эквивалентна в том смысле, что может быть построен конвертор, выполняющий как прямое, так и обратное преобразование. Такой конвертор может превращать исходный текст программы на языке ДРАКОН-СИ (рис. 90, правая графа) в эквивалентную СИ-программу (рис. 90, средняя графа), и наоборот.


рис. 90


рис. 90, 91


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

ГИБРИДНЫЙ ЯЗЫК ПРОГРАММИРОВАНИЯ
ДРАКОН-МОДУЛА

Обратимся к верхнему примеру на рис. 91. В средней графе представлена программа на языке МОДУЛА-2, в правой — эквивалентная ей программа на языке ДРАКОН-МОДУЛА. В левой графе приводится список ключевых слов, которые используются в модула-программе и являются “жизненно необходимыми” для языка МОДУЛА, но которые совершенно не нужны в дракон-программе.

С эргономической точки зрения, эти и многие другие ключевые слова, присутствующие в текстовых языках, есть не что иное как визуальные помехи, притягивающие к себе внимание читателя и отвлекающие его внимание от содержательной стороны дела. Эргономическое преимущество ДРАКОНА состоит в том, что вместо ключевых слов используется визуальный образ, который воспринимается читателем бессознательно, на интуитивном уровне, в то время как канал сознательного внимания действует более продуктивно — для восприятия наиболее важных, содержательных аспектов задачи.

ПРИМЕР ЭРГОНОМИЧЕСКОЙ ОПТИМИЗАЦИИ
ПРОГРАММЫ

На рис. 91 (внизу, в средней графе) написана программа на языке ПАСКАЛЬ. Действуя по аналогии с предыдущими примерами, ее можно легко преобразовать в программу на языке ДРАКОН-ПАСКАЛЬ. Для этого нарисуем визуальный оператор “развилка” и в иконе “вопрос” поместим запись

Нижний выход иконы “вопрос” пометим словом “да” и присоединим к нему переключатель с двумя иконами “вариант”, а правый выход (ответ “нет”) подключим к иконе “вывод”, в которой сверху напишем WRITELN, снизу — ОШИБКА. В итоге получим дракон-схему, которая несомненно является совершенно правильным решением поставленной задачи. (Для наглядности советуем читателю выполнить описанные построения на бумаге.)

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

Бросается в глаза структурное различие между программами. Паскаль-программа содержит две конструкции: if-then-else и case-of. Эргономическая оптимизация состоит в том, что в дракон-программе используется всего один визуальный оператор (переключатель с тремя вариантами), который тем не менее “в одиночку” выполняет те же самые функции, что и два текстовых оператора языка ПАСКАЛЬ. В итоге сложное условие K = 1 OR K = 2 и другие излишества паскаль-программы устраняются, а дракон-схема заметно упрощается и становится лаконичной, прозрачной, элегантной.

ДИАЛОГОВЫЕ ПРОГРАММЫ

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

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

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

Оператор “Сообщение”

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


92, 93


строки служит черный кружок. Например, на рис. 92 с помощью оператора “Сообщение” на экран выводится фраза “Сумма чисел равна” и значение выражения  m + n.

Оператор “Запрос”

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

Предположим, нужно ввести значения m = 23 и n = 45 (рис. 92). Делается это, например, так: подводят курсор в зону m, набирают на клавиатуре число 23 и нажимают клавишу “возврат каретки”. При этом зона m на экране гаснет и вместо нее загорается число 23. Значение n вводится аналогично. Таким образом, оператор “Запрос” запрашивает у пользователя значения переменных, записывает их в память и одновременно отображает на экране вместе с постоянной информацией (если последняя указана на нижнем этаже оператора “Запрос” в белой зоне).

Описание данных

Для описания данных служит икона “полка”. На верхнем этаже пишут ключевое слово “Данные”, на нижнем — описание данных. Например, на рис. 92 в иконе “полка” указано, что переменные m и n имеют тип “целый”.

Можно предложить и другой способ: описание данных выносят за рамки дракон-схемы и помещают в отдельную таблицу.

ИДЕНТИФИКАТОРЫ

Приведем правила записи идентификаторов.

  •  Длина идентификатора 1...32 символа.
  •  Разрешается использовать любые русские и латинские буквы, цифры, точку и, возможно, специальные символы.
  •  Первый символ должен быть буквой (не цифрой и не точкой).
  •  Внутри идентификатора запрещается использовать пробелы.
  •  Слова следует разделять точками, чтобы облегчить чтение.
  •  Запрещается использовать сокращение слов, если длина идентификатора меньше 32 символов.
  •  Если длина идентификатора больше 32 символов, надо заменить некоторые слова сокращениями или уменьшить число слов.
  •  Нужно стремиться придумывать доходчивые идентификаторы, позволяющие легко уяснить смысл понятия, чтобы читатель быстро понял суть дела.

Примеры правильных идентификаторов

Номер.вагона.скорого.поезда

Номер.вагона.пассажир.поезда

Цена.билета.поездом.до.Магадана

Цена.билета.самолет.до.Магадана

Примеры неправильных идентификаторов

Номер.вагона.пассажирского.поезда (здесь 33 символа,
а можно не более 32)

Число.вагонов товарного поезда (используются пробелы)

3-й.запуск.аварийного.насоса (здесь две ошибки:
первый символ — цифра;
кроме того, есть дефис)

Пример сокращения длины сложного понятия

Предположим, нужно создать идентификатор для следующего понятия: “Радиус-вектор центра Земли в центре взлетно-посадочной полосы в посадочной системе координат”. Словесное описание понятия содержит 92 символа. Задача состоит в том, чтобы сократить 92-символьное описание до 32-символьного, сохранив по возможности ясный смысл понятия.

Сокращение проведем по следующему плану:

  •  “Радиус-вектор центра Земли” заменим на “Радиус.земли”.
  •  Вместо “В центре взлетно-посадочной полосы” напишем “на.полосе”.
  •  “В посадочной системе координат” заменим на ПСК, поскольку такое сокращение является общеупотребительным в коллективе разработчиков данной системы.

В итоге получим 26-символьный идентификатор

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

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

Следует различать два случая. Если выражение простое, рекомендуется использовать 32-символьные идентификаторы и “вертикальную” запись математических формул, как показано на рис. 94 и 95.

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

В качестве одного из возможных подходов к развязыванию этого гордиева узла можно предложить план из трех пунктов.

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

ОБРАБОТКА МАССИВОВ

На рис. 94 и 95 даны примеры программ, в которых имеются операции с массивами.

Описание данных размещается на нижнем этаже иконы “полка”.

Запись

МАССИВ ВЕЩ Вес.кролика [100]

означает, что задан одномерный массив с именем “Вес.кролика”, содержащий 100 элементов, каждый из которых является вещественным числом.

Основным элементом обеих программ служит цикл ДЛЯ. Рассмотрим правила оформления цикла. В иконе “начало цикла ДЛЯ” в верхней строке пишут слово “Цикл” и после пробела односимвольный алиас, обозначающий переменную цикла (буква k на рис. 94, 95). В нижней строке указывают диапазон ее изменения, например,

Но что обозначает буква k? Каков физический смысл переменной цикла в данной прикладной программе? Авторы многих программ
забывают (или не считают нужным) ответить на этот вопрос, в результате чего программа нередко превращается в ребус.  Чтобы этого не


94, 95


случилось, в средней строке следует написать формализованный комментарий, например

Знак тождественного равенства ≡ показывает, что после него следует имя-комментарий, т. е. комментарий, который пишется по правилам записи идентификаторов.

Эргономический “навар” формализованного комментария включает два преимущества. Во-первых, он позволяет устранить традиционную “забывчивость” программистов и по-человечески объяснить читателю смысл абстрактного идентификатора: дескать, k — это номер кроличьей клетки. Во-вторых, что немаловажно, объяснение размещается на поле чертежа именно там, где нужно (в иконе “начало цикла ДЛЯ”), по принципу “дорого яичко ко Христову дню”. Это значит, что читатель получает ответ моментально — в ту самую секунду, когда он впервые увидел алиас k и в его голове забрезжил вопрос: а что такое k?

В иконе “конец цикла ДЛЯ” делают запись

Смысл операторов, организующих обработку массивов, ясен из рис. 94 и 95 и не требует пояснений.

АБСТРАКТНЫЕ ДРАКОН-СХЕМЫ

В этом параграфе мы рассмотрим преобразование визуальной программы на языке ДРАКОН-2 в текстовую программу на БЕЙСИКе. Это преобразование полезно в двух отношениях: оно позволит глубже уяснить суть визуализации и познакомиться с важным понятием абстрактной дракон-схемы.

В качестве примера возьмем школьную программу под названием “Игра.угадайка” и напишем ее на языке ДРАКОН-2 (рис. 96). Затем полностью устраним из нее текст и получим чертеж-слепыш, который называется “абстрактная дракон-схема” (рис. 97). Эта схема представляет собой инвариант программы, который можно за два шага преобразовать в программу на любом языке программирования.

Выберем в качестве цели язык БЕЙСИК и приступим к делу. На первом шаге заполним пустые иконы абстрактной схемы текстом на языке БЕЙСИК. В результате получится эквивалентная программа на языке ДРАКОН-БЕЙСИК (рис. 98). На втором шаге переходим к обычной бейсик-программе (мы сознательно выбрали старомодную версию БЕЙСИКа, чтобы для разнообразия продемонстрировать использование операторов goto при описании эквивалента дракон-программы) —
см. рис. 99.


96


97


98


99, 100


ФИЛОСОФИЯ ЯЗЫКА ДРАКОН

Любой императивный язык (СИ, ПАСКАЛЬ, АДА, МОДУЛА, БЕЙСИК
и т. д.) можно разбить на три части, три относительно самостоятельных языка: маршрутный, командный и декларативный.

Маршрутный язык — совокупность управляющих операторов. Командный язык содержит все неуправляющие операторы, например оператор присваивания, правила записи арифметических и логических выражений, идентификаторов, ключевые слова и т. д. Декларативный язык служит для описания данных, классов и др.

Поясним сказанное на примере. Абстрактная дракон-схема, приведенная на рис. 97, есть некоторая “фраза” маршрутного языка. Чтобы сделать ее содержательной, внутри икон следует поместить текст. Этот текст пишется на командном языке. Однако описания данных и классов иногда целесообразно вынести за рамки дракон-схемы и поместить их где-нибудь в другом месте, например, в виде отдельной записи или таблицы.

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

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

Маршрутный язык — это визуальный стандарт дракон-семейства, поддерживаемый визуальным дракон-редактором (см. гл. 14), который имеет небольшие размеры и легко запоминается. Он является неизменной визитной карточкой ДРАКОНА, его стандартизованным зрительным образом (рис. 97).

КЛАССИФИКАЦИЯ ЗНАНИЙ

Любая программа есть некоторая сумма знаний, которую можно расчленить на императивную и декларативную часть. Изложенные выше соображения позволяют уточнить этот тезис. Новый взгляд на проблему представлен на рис. 100 и сводится к следующему:

  •  Для анализа знаний, содержащихся в исходном тексте компьютерной программы, написанной на императивном языке, целесообразно использовать две классификации: базовую и альтернативную.
  •  Базовая классификация состоит в том, что все знания, содержащиеся в исходной программе, разбиваются на императивные и декларативные.
  •  В свою очередь императивные знания делятся на управляющие и командные.
  •  В качестве критерия для альтернативной классификации предлагается вопрос: какие средства лучше использовать для представления знаний — графику или текст?
  •  Ответ состоит в следующем. Для представления управляющих знаний лучше применять графику (маршрутный язык), для командных и декларативных знаний — текст.
  •  Таким образом, при альтернативной классификации знания делятся на визуальные (управляющие) и текстовые (командные и декларативные).

Напоследок добавим: использование текста для представления сложных управляющих знаний выглядит столь же нелепо, как попытка описать географическую карту словами. Тот факт, что текст все еще применяется для этой цели, можно объяснить только одним: программирование намного моложе географии!

ВЫВОДЫ

1. Если в нашем распоряжении имеется формальный визуальный синтаксис, то для построения визуального языка программирования достаточно построить формальный текстовый синтаксис. Мы убедились, что эта задача вполне разрешима, причем несколькими способами. В итоге образуется семейство языков программирования как оригинальных (ДРАКОН-2), так и гибридных (ДРАКОН-СИ, ДРАКОН-МОДУЛА, ДРАКОН-ПАСКАЛЬ, ДРАКОН-БЕЙСИК и т. д.).

2. Можно утверждать, что понимаемость визуальных языков существенно выше, чем понимаемость их текстовых собратьев. Поэтому во всех случаях, когда понимаемость рассматривается как главный критерий качества программ (а таких случаев немало), визуальные языки оказываются вне конкуренции. Здесь уместна оговорка: сам по себе термин “визуальный” ничего не гарантирует. Успех дела достигается за счет тщательного и скрупулезного применения методов науки о человеческих факторах (эргономики). Если говорить точнее, речь идет о синтезе методов информатики и эргономики, формировании нового междисциплинарного направления — инфоэргономики, перестройке всего здания современного программирования на эргономической основе.

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


Г Л А В А  13

Человеческая деятельность
и формализация знаний:
живописные примеры

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

Григорий Громов

ЧТО ТАКОЕ
ПРОФЕССИОНАЛЬНЫЕ ЗНАНИЯ?

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

Профессиональные знания должны в конечном итоге вести к желаемому (теоретическому или практическому) результату, а также удовлетворять многим другим требованиям. Например, технология закалки кинжала (рис. 101), хотя и позволяет получить искомый результат, однако с современной точки зрения выглядит дикой, нелепой и бесчеловечной. Причин тому две: на заре человечества моральные нормы были неразвиты, а главное — указанная технология опирается не на научные знания, а на мифологические объяснительные схемы. Древние “технологи” были искренне убеждены, что сила раба “переходит” в кинжал и улучшает его боевые качества.

В данной главе под формализацией знаний будем понимать представление человеческих знаний на формальном или частично формальном языке. Учитывая сказанное ранее (гл. 3), исключим из анализа декларативные профессиональные знания и ограничимся проблемой формализации технологических (императивных) знаний.

План дальнейшего изложения таков. Мы рассмотрим ряд примеров из самых различных, очень непохожих друг на друга областей профессиональной деятельности и покажем,  что язык ДРАКОН “повсюду


101


молодец” — он позволяет эффективно формализовать императивные знания во многих, хотя и не во всех ситуациях. Что это дает? Поскольку процесс формализации знаний оказывается чрезвычайно легким, он становится доступным практически для любого человека, который хорошо знает свое дело. Это означает, что с появлением языка ДРАКОН каждый специалист приобретает новые возможности:

  •  он может формализовать свои знания сам, без помощи инженеров по знаниям или программистов, т. е. воспользоваться всеми благами формализации знаний;
  •  он может выражать свои мысли на своем родном профессиональном языке, но в строгом формализованном виде.

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

УЧЕБНЫЕ ЭКСПЕРТНЫЕ СИСТЕМЫ

Рассмотрим школьную задачу по химии за 10-й класс. Учитель берет одно из шести химических удобрений и помещает его в колбу. Что в колбе — неизвестно. Это может быть аммиачная селитра, натриевая соль, сульфат аммония, суперфосфат, сильвинит или калийная соль. Нужно выполнить эксперимент, позволяющий узнать, какое именно вещество находится в колбе.

Опыт делают в два этапа. Сначала идут подготовительные действия:

1. Положить удобрение в три сосуда.

2. В первый сосуд добавить серную кислоту  Н2SO4.

3. Во второй сосуд добавить раствор хлорида бария  ВаСl.

4. В третий сосуд добавить щелочь.

После этого анализируются результаты и определяется неизвестное вещество на основании табл. 3.

В методических указаниях по курсу “информатика” для средних школ рекомендуется использовать этот пример для ознакомления учащихся с принципом работы профессиональных экспертных систем. Для этой цели школьникам предлагается изучить упрощенную учебную экспертную систему в виде программы на языке БЕЙСИК. Функционирование учебной экспертной системы реализуется в диалоге ученика  и системы. Экспертная система задает ученику серию вопросов, анализирует ответы и сравнивает с хранящимися в ней фактами. Система производит логический вывод и формирует ответ на интересующий пользователя вопрос — в данном случае сообщает ученику название удобрения.


Таблица  3

Название
вещества

Внешний
вид

Результат взаимодействия с

Н2SO4

BaCl

щелочью

Аммиачная
селитра

Белые
кристаллы

Бурый газ

Запах
аммиака

Натриевая
селитра

Бесцветные
кристаллы

Бурый газ

Помутнение

Сульфат
аммония

Светло-серые кристаллы

Белый осадок

Запах
аммиака

Суперфосфат

Светло-серый
порошок

Белый осадок

Сильвинит

Розовые
кристаллы

Калийная соль

Бесцветные
кристаллы

Учебная экспертная система (программа на языке БЕЙСИК)

10 REM Распознавание удобрений

20 PRINT «При взаимодействии с серной кислотой выделяется бурый газ?»

30 INPUT A$

40 IF A$="да" THEN GOSUB 100 ELSE GOSUB 200

50 PRINT «Данное удобрение — »;Х$

60 END

100 REM взаимодействие со щелочью

110 INPUT «При взаимодействии с раствором щелочи ощущается запах аммиака?»;В$

120 IF B$="да" THEN X$="аммиачная селитра" ELSE X$="натриевая селитра"

130 RETURN

200 REM взаимодействие с раствором хлорида бария

210 INPUT «При взаимодействии с раствором хлорида бария и уксусной кислотой выпадает белый осадок?»;С$

220 IF C$="да" THEN GOSUB 300 ELSE GOSUB 400

230 RETURN

300 REM взаимодействие с раствором щелочи

310 INPUT «При взаимодействии с раствором щелочи ощущается запах аммиака?»;D$

320 IF D$="да" THEN X$="сульфат аммония" ELSE X$="суперфосфат"

330 RETURN

400 REM розовые кристаллы

410 NPUT «Розовые кристаллы?»;Е$

420 IF E$="да" THEN X$="сильвинит" ELSE X$="калийная соль"

430 RETURN

ВИЗУАЛИЗАЦИЯ ЭКСПЕРТНЫХ СИСТЕМ

Более удачный вариант решения той же задачи показан на рис. 102. Учебная экспертная дракон-система работает следующим образом. После запуска системы рабочая точка процесса начинает двигаться от иконы “заголовок” к иконе “конец”. По ходу ее движения иконы и соединительные линии вспыхивают и горят на экране более ярким светом, выделяя пройденную часть пути. Когда процесс дошел до иконы-вопрос “При взаимодействии с Н2SO4 выделяется бурый газ?”, данная икона начинает мерцать, привлекая к себе внимание и требуя ответа. Реагируя на это событие, ученик подводит курсор к нужному ответу (да или нет) и щелкает клавишей мыши. Икона перестает мерцать и (при ответе “да”) загорается путь, ведущий к иконе-вопрос “При взаимодействии со щелочью ощущается запах аммиака?”, которая начинает мерцать. Далее события повторяются, пока на экране не загорится искомое название удобрения.

Таким образом, дракон-система выполняет те же самые функции, что и система на БЕЙСИКЕ. Вместе с тем она обладает рядом преимуществ.

  •  Программа на БЕЙСИКЕ содержит 790 символов (не считая пробелов), из которых только 488 символов (60%) описывают задачу на естественном языке, а остальные 302 (40%) представляют собой набор иероглифов — загадочный текст на птичьем языке программирования, который все нормальные люди (не программисты) воспринимают с неудовольствием. В дракон-схеме на рис. 102 повод для недовольства исчезает, “птичья абракадабра” полностью отсутствует, а все необходимые функции тем не менее выполняются. Становится очевидным, что “программные иероглифы” являются паразитными, избыточными и даже вредными, поскольку они работают не на пользователя (которому они не нужны), а сами на себя. В данном случае сущность эргономизации состоит в полном отказе от использования “птичьей абракадабры”.
  •  Другое преимущество заключается в системном подходе к проблеме симультанизации. С точки зрения процесса познания, проблема распознавания удобрения состоит из трех частей:

1) постановка задачи;

2) описание действий с исследуемым веществом и реактивами;

3) логический анализ результатов опыта.

Недостаток программы на БЕЙСИКЕ в том, что она освещает лишь последнюю часть и “прячет от читателя” две первых. Дракон-система свободна от этого дефекта: в первой ветке даны постановка задачи (икона “комментарий”) и описание последовательности ручных манипуляций (четыре иконы “действие”), во второй ветке демонстрируется логический анализ и получение ответа.

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


102


  •  Программа на БЕЙСИКЕ — пример плохой (неэргономичной) экспертной системы, которая общается с пользователем через узкую “замочную скважину”, сквозь которую виден один-единственный вопрос и больше ничего. Тем самым бейсик-система не дает возможности человеку одновременно охватить единым взором и логические детали, и общую картину логического вывода, фактически превращая пользователя в какого-то пасынка или даже дурачка, от которого скрывают все самое интересное.
  •  Хорошо известно, что пользователю далеко не безразлично, каким образом экспертная система приходит к своему решению. Идя навстречу таким пожеланиям, современные экспертные системы помогают пользователю не только принимать решения, но и позволяют выявить мотивы их принятия через систему объяснения. Более того, специалисты считают, что от наличия или отсутствия в системе объяснительной функции зависит право этой системы называться экспертной. Исходя из этого, многие системы разрешают пользователю задавать вопрос “Почему?”, после чего “раскрывают карты” и в словесной форме показывают пользователю ход своих рассуждений. Это хорошо, но мало. В ряде приложений идеальным решением можно назвать такое, при котором система предъявляет пользователю всю панораму возможных логических выводов, на которой выделяется (яркостью или цветом) маршрут цепочки конкретных умозаключений, ведущих к выбранному ответу. ДРАКОН-система реализует именно этот идеальный подход (рис. 102).

ВИЗУАЛИЗАЦИЯ ОПИСАНИЯ
ТЕХНОЛОГИЧЕСКИХ ПРОЦЕССОВ

На рис. 103 представлено упрощенное описание технологического процесса изготовления фруктовых консервов из косточковых плодов (автор технологии Е. Свешникова). Реальный технологический процесс может быть очень сложным. Обычно его описывают как головной процесс, содержащий большое число вставок. В качестве примера в головном процессе на рис. 103 показана вставка “Изготовление сиропа и маринада”, раскрытая на рис. 104.

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

Дракон-схемы технологических процессов могут найти применение в следующих случаях:

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

ЧТО ТАКОЕ МЕТОДОЛОГИЯ?

Джеймс Мартин подчеркивает необходимость различать два понятия: методика (technique) и методология (methodology).

Методика — это способ выполнения одной операции. Например, правила составления схем потоков данных — это методика.

Методология разработки систем охватывает набор задач (операций), которые необходимо решить в процессе создания системы. Существует много задач, при решении которых применяется много методик. Выход одной задачи часто является входом в другую. Применяя компьютеры при разработке систем, желательно полностью автоматизировать те задачи, которые поддаются автоматизации, а остальные выполнять автоматизированным способом, когда человек работает вместе с компьютером. Поток знаний, передаваемых от одной задачи к следующей, должен находиться внутри компьютеризованных инструментов всегда, когда это возможно. Методология RAD использует компьютеризованные средства и ручные методы, разумно связанные между собой, чтобы достичь две цели: большую скорость и высокое качество разработки. Методология определяет, в чем заключается каждая задача, как ее успешно выполнить, какие неприятности и опасности возможны в процессе работы и как их избежать.

ВИЗУАЛИЗАЦИЯ МЕТОДОЛОГИЙ

Иногда высказывают мнение, что язык ДРАКОН хорошо описывает простые задачи и непригоден для изображения сложных проблем. Это неверно. ДРАКОН специально сконструирован, чтобы облегчить формализацию широкого спектра задач, включая самые сложные. Более того, чем сложнее проблема, тем больше выигрыш от использования языка ДРАКОН.

Чтобы убедиться в этом, рассмотрим методологию проектирования атомного реактора. Ясно, что это грандиозная, “запредельная” по сложности проблема.  Целостный взгляд на методологию представлен


103 лев


103 прав


104


на рис. 105. Дракон-схема на рис. 105 содержит большое число вставок, для обозначения которых в данном случае целесообразно ввести термин алгоритм-концепция. Например, во второй и четвертой ветке на рис. 105 имеются иконы-вставки “Расчет стационарных параметров первого контура атомного реактора” и “Расчет реактивностных аварий атомного реактора”. Соответствующие им алгоритмы-концепции показаны на рис. 106 и 10719.

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

Важным достоинством является тот факт, что язык не зависит от уровня иерархии — он один и тот же и на самом верху и у основания пирамиды. Благодаря этому достигается резкое упрощение описания задач любой сложности; в итоге “уму непостижимая” проблема превращается в относительно простую, ясную и наглядную.

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


105лев  


105прав


106лев


106прав


107лев


107прав


нению этого недостатка, более эффективно организовать совместную работу участников сложного проекта и более разумно использовать интеллектуальные ресурсы их коллективного мозга.

СИСТЕМА “ЧЕЛОВЕК—МАШИНА”

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

Во-первых, для проведения эргономического анализа системы “человек—машина” при выборе вариантов:

  •  распределения функций между человеком и машиной;
  •  распределения функций между членами экипажа вертолета;
  •  состава оборудования;
  •  численности экипажа.

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

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

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

ВИЗУАЛИЗАЦИЯ БИОЛОГИЧЕСКИХ АЛГОРИТМОВ

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

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

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


108лев


108прав


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

ВИЗУАЛИЗАЦИЯ МЕДИЦИНСКИХ АЛГОРИТМОВ

Медики редко произносят слово “алгоритм”. А жаль! — ведь алгоритмы составляют значительную часть медицинских знаний. На рис. 109 представлен знакомый почти каждому пример — измерение кровяного давления (которое медики обозначают торжественным словом “сфигмоманометрия”). Этот алгоритм получен путем точного воспроизведения инструкции по выполнению сфигмоманометрии из руководства по клинической профилактике, подготовленного комитетом США по профилактической медицине [2]. Алгоритмическими описаниями полны многие медицинские руководства, например, описания иммунологических методов, клиническая лабораторная диагностика, микробиологические инструкции по идентификации микроорганизмов и многое другое. Вообще говоря, процесс обследования и лечения всегда представляет собой некоторую последовательность действий, следовательно, его можно рассматривать как технологический процесс или алгоритм.

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

ДРУГИЕ ПРИМЕРЫ ВИЗУАЛИЗАЦИИ

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

Следующий пример родился из маленького школьного “приключения”. Присутствуя на уроке в одной из московских школ, автор наблюдал за мучениями мальчика, решавшего задачу, показанную в иконе-комментарий на рис. 112. Чувствовалось, что он знает все формулы и догадывается об общем ходе решения, тем не менее у него никак не складывалась общая картина. Он не мог четко разбить задачу на отдельные этапы и выстроить из них упорядоченную последовательность, ведущую к победе. Почему? Что ему мешало? Заглянув через плечо, автор увидел в тетради “живописную мазню”.  Правильные формулы прыгали


109


110


111


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

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

На основании этих предположений автор по согласованию с учительницей изобразил решение, как показано на рис. 112. Чем же отличается решение на рис. 112 от традиционной записи? Выделим три наиболее важных отличия.

  •  Зрительная сцена имеет предельно четкую структуру. Она упорядочена и по вертикали, и по горизонтали.
  •  Все без исключения этапы решения и формулы имеют разъясняющие словесные заголовки. Последние записываются не где угодно, а в специальных рамочках, каждая из которых “знает свое место”.
  •  Обеспечена симультанность восприятия: в одном визуальном поле находятся: 1) условие задачи; 2) решение; 3) ответ.

Дракон-схема на рис. 113 появилась на свет при сходных обстоятельствах.

Большинство примеров на рис. 101—113 являются адаптированными, описывающими крайне простые, даже примитивные алгоритмы. Использование “игрушечных” примеров связано с тем, что реальные ситуации слишком сложны и “не влезают” в книгу.

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

  •  Расчет угла визирования по курсу и угла визирования по тангажу для определения углового положения линии визирования при полете ракеты.
  •  Последовательность работ и этапов, выполняемых при создании объектов вертолетной техники.
  •  Создание единой системы сейсмологических наблюдений и прогноза землетрясений.
  •  Алгоритм работы системы управления орбитального корабля “БУРАН” в режиме довыведения.
  •  Описание функций интеллектуальной автоматизированной системы ведения и анализа проектной документации.
  •  Термообработка тороидальных сердечников из железо-никелевых сплавов.
  •  Установка изделия (ракетоносителя с закрепленным на нем космическим кораблем) на пусковое устройство стартовой площадки.
  •  Расчет траектории электронов в статических электрическом и магнитном полях.
  •  Обработка информации, поступающей из прибора регистрации затмения солнца.
  •  Управление спринклерной системой реакторного отделения атомной электростанции.
  •  Проверка многослойных печатных плат.


113


  •  Изучение влияния радиации и высокочастотных воздействий на организм кролика.
  •  Художественная вышивка на швейной машинке.
  •  Малоотходная технология переработки свеклы.

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

ОПИСАНИЕ СТРУКТУРЫ ДЕЯТЕЛЬНОСТИ

Попытаемся взглянуть на рис. 101—113 под другим углом зрения. Почти все эти рисунки представляют собой конкретные примеры описания структуры деятельности в различных областях: металлообработке, химии, атомной энергетике, медицине и т. д.

Рисунки 101—113 описывают различные процессы, действия и события, которые на первый взгляд не имеют ничего общего. Если содержание этих рисунков представить в виде текстового описания, общая, инвариантная часть указанных процессов и событий как бы исчезает, становится скрытой, неявной, неуловимой. Образно говоря, язык ДРАКОН срывает шапку-невидимку с этого инварианта, делает его зримым, бьющим в глаза. В данном случае инвариантом является структура деятельности. Уточним сказанное. Любую деятельность можно описать с помощью дракон-схемы. При этом абстрактная дракон-схема является логическим инвариантом деятельности.

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

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

Внимательно анализируя рис. 101—113, абстрагируясь от содержания деятельности и концентрируя внимание на ее структуре и формальных аспектах описания, мы обнаруживаем “сходство в различном” и на конкретных примерах убеждаемся в том, что техноязык ДРАКОН действительно пригоден для описания структуры деятельности в самых разнообразных, непохожих друг на друга сферах деятельности. Преимущество состоит в использовании единой формы для представления технологических (императивных) знаний и описания структуры деятельности.

Для полноты картины заметим, что техноязык ДРАКОН позволяет описывать два класса процессов:

  •  деятельность (рис. 101—107, 109—113);
  •  естественные процессы, протекающие в живых организмах (рис. 108).

НУЖЕН ЛИ СТАНДАРТ ДЛЯ ОПИСАНИЯ
ДЕЯТЕЛЬНОСТИ?

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

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

Неприятность в том, что традиционные понятия “деятельность” [3, 4] и “алгоритм” [5], весьма полезные сами по себе, к сожалению, плохо приспособлены для решения поставленной задачи. Стремясь поправить дело, дадим три новых определения, которые, не претендуя на строгость (в данном случае она не нужна), позволяют выявить глубинную связь понятий “деятельность”, “алгоритм” и “техноязык”.

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

Алгоритм — описание структуры деятельности.

Техноязык — язык для описания структуры деятельности.

ВЫВОДЫ

  1.  Чтобы вскрыть основополагающую структуру человеческих знаний, нужно расчленить их на технологические (императивные) и декларативные. Подобное расчленение мы склонны рассматривать как генеральное деление знаний.
  2.  Ценность технологических (императивных) знаний состоит в том, что они теснейшим образом связаны с одним из наиболее фундаментальных понятий социально-гуманитарных наук — деятельностью.
  3.  Технологические (императивные) знания выявляют, закрепляют в сознании и объективируют структуру деятельности.
  4.  Важным свойством деятельности является существование глубинных логических инвариантов (структурных конструкций), выражаемых с помощью понятия “абстрактная дракон-схема”.
  5.  Традиционные способы описания деятельности не позволяют выявить глубинные инварианты; последние оказываются замаскированными, скрытыми, спрятанными от читателя. Это обстоятельство затрудняет перенос знаний и навыков, играющий важную роль в образовании и практической жизни.
  6.  Техноязык как особое средство, специально созданное для описания структуры деятельности, позволяет выявить и обнажить логические инварианты деятельности, сделать их явными, зримыми, доступными для всех людей.
  7.  Формализация знаний — труд, производительность которого играет важную роль (см. гл. 3). Если этот труд слишком сложен (производительность труда мала), то формализацию могут выполнять только специально подготовленные элитные специалисты; при таких условиях автоформализация практически невозможна. И наоборот, если данный труд удается облегчить, формализация становится посильной почти для каждого — только в этом случае создаются необходимые предпосылки для автоформализации.
  8.  Техноязык ДРАКОН кардинальным образом облегчает труд формализации и повышает его производительность. Следовательно, техноязык пригоден для эффективной автоформализации технологических знаний.
  9.  Целесообразно создать единый межотраслевой стандарт для описания структуры деятельности. Стандарт должен опираться на техноязык ДРАКОН, рассматриваемый как единое средство для описания структуры деятельности методом автоформализации технологических знаний.
  10.  Описание структуры деятельности и результаты формализации технологических знаний целесообразно хранить в компьютерной форме (в виде библиотек визуального гипертекста), а также в виде бумажных визуальных альбомов подходящего формата (например, формата А3).


Г Л А В А  14

Визуальный дракон-редактор

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

Валерий Венда

ЗАЧЕМ НУЖЕН ДРАКОН-РЕДАКТОР?

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

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

ЗАГОТОВКА-ПРИМИТИВ И ЗАГОТОВКА-СИЛУЭТ

Чтобы вырастить огромное дерево, нужно бросить в землю маленькое семечко. Любая сколько угодно сложная дракон-схема тоже вырастает из “семечка”, которое называется заготовкой. Заготовки бывают двух сортов: одна используется для построения дракон-схемы “примитив”, из другой получается силуэт (рис. 115).

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

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

ЧТО ТАКОЕ АТОМ?

Элемент меню на рис. 114 называется атомом, если он имеет два вертикальных отростка.

ДРАКОН-редактор может выполнять несколько операций, среди которых важную роль играет команда “ввод атома” (рис. 116).  Операция

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

Атомы вставляются не куда попало, а только в разрешенные места, которые называются валентными точками дракон-схемы. Перечень точек включает:

  •  валентные точки заготовок (отмечены на рис. 115);
  •  валентные точки макроикон (отмечены на рис. 2);
  •  входы и выходы атомов.

Ввод атома производится так: происходит разрыв соединительной линии в выбранной пользователем валентной точке, после чего в место разрыва вставляется атом, как показано на рис. 116.

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


116


ПРИМЕР ПОСТРОЕНИЯ ДРАКОН-СХЕМЫ
“ПРИМИТИВ”

Дракон-схема строится на экране компьютера методом “сборки из кубиков”. Чтобы посмотреть, как это делается, нарисуем схему, изображенную на рис. 117. В начале работы пользователь вызывает на экран визуальное меню (рис. 114) и размещает его в удобном для себя месте, например в правом верхнем углу экрана. Остальная часть экрана используется как рабочее поле для построения дракон-схемы.

Схема, которую мы хотим построить (рис. 117), — это примитив. Поэтому прежде всего нужно поместить в рабочее поле заготовку-примитив. Для этого на первом шаге графического конструирования пользователь обращается к меню, подводит курсор к макроиконе “заготовка-силуэт”, преобразует ее в заготовку-примитив и копирует последнюю
в рабочее поле экрана (рис. 118, шаг 1). На втором шаге пользователь вызывает из меню икону “действие”. Но куда ее поместить? Пользователь переводит курсор в рабочее поле и указывает точку в заготовке-примитив, в которой следует разорвать соединительную линию, чтобы
в образовавшийся разрыв вставить выбранную икону. Результат операции виден на рисунке (рис. 118, шаг 2).

Два следующих шага выполняются аналогично: в дракон-схему вводятся еще одна икона “действие” и макроикона “переключатель” (рис. 118, шаги 3 и 4).

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

Последующий ход строительства ясен из рис. 118 (шаги 6—8). После того как графический узор (слепыш) дракон-схемы построен, производится заполнение его текстом. Окончательный результат работы редактора показан на рис. 117.

ОПЕРАЦИЯ “ПЕРЕСАДКА ЛИАНЫ”

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

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


117, 118


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

Многие дракон-схемы, представленные в этой книге, построены с помощью пересадки лианы. Укажем некоторые из них: рис. 26б, 27б,
40, 41, 42, 57
в, 60в, 67—74.

ОПЕРАЦИЯ “ЗАЗЕМЛЕНИЕ ЛИАНЫ”

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

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

Заземление лианы использовалось при построении силуэтов с многоадресными ветками, например, на рис. 4, 6а, 51–54, 84, 88, 89.

ПРИМЕР ПОСТРОЕНИЯ
ДРАКОН-ПРОГРАММЫ “СИЛУЭТ”

Построим визуальную программу, изображенную на рис. 96. На первом шаге конструирования пользователь обращается к меню и вызывает в рабочее поле заготовку-силуэт (рис. 121, шаг 1). На следующем шаге с помощью операции “добавление ветки” (которая выполняется без обращения к меню) он модифицирует заготовку, вставляя в силуэт еще одну ветку (рис. 121, шаг 2). Дальнейший ход строительства ясен из рисунка: в шагах 3—8, 10—13 реализуется операция “ввод атома”, в шаге 9 — “заземление лианы”. Графическое конструирование заканчивается в момент получения желаемого слепыша (рис. 121, шаг 13).


119


120


121


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

ФОРМИРОВАНИЕ НАДПИСЕЙ “ДА” И “НЕТ”

Вернемся к обсуждению рис. 121 и подробнее остановимся на шаге 13, на котором завершается графическое построение дракон-схемы и в качестве результата на экране возникает слепыш. Дело в том, что законченный чертеж-слепыш, сформированный при реальной работе ДРАКОН-редактора, имеет отличие от абстрактной дракон-схемы, изображенной на рис. 97. Последняя полностью лишена текста (не содержит ни одной буквы или цифры), а построенный редактором слепыш возле каждой иконы “вопрос” обязательно имеет надписи “да” и “нет”. Эти надписи появляются на дракон-схеме всякий раз, когда из меню вызывается элемент с иконой “вопрос” в ходе операции “ввод атома”. Согласно алгоритму этой операции редактор пишет “да” у нижнего выхода иконы “вопрос” и “нет” — у правого. Чтобы пользователь в случае необходимости мог поменять их местами, в редакторе предусмотрена операция “да-нет”. Применение последней к конкретной иконе “вопрос” приводит к тому, что слова “да” и “нет” у ее выходов меняются местами (при этом все остальные элементы дракон-схемы остаются на своих местах).

ВЫВОДЫ

1. Хотя общее число икон и макроикон языка ДРАКОН равно 45, для построения любой дракон-схемы достаточно иметь небольшое меню, содержащее всего 18 графоэлементов.

2. Визуальное меню существенно облегчает работу пользователя — оно дает возможность конструировать дракон-схему методом “сборки из кубиков”. Для этого служит операция “ввод атома”, позволяющая доставать “кубики” из меню и укладывать их в проектируемую дракон-схему.

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

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

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


Г Л А В А  15

Описание визуального синтаксиса
языка ДРАКОН

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

Галилео Галилей

ОБЩИЕ ПОНЯТИЯ

Тезис 1.  Иконы — визуальные буквы, образующие визуальный алфавит языка ДРАКОН, представленные на рис. 1.

Тезис 2.  Заготовка-примитив и заготовка-силуэт — фигуры, показанные на рис. 115.

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