ББК 32.973 7 страница

! Границы зон (выделяемые пробелами или линиями) должны иметь простую прямоугольную форму.

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

! Соединительные линии между блоками должны быть вертикальными и горизонтальными. Наклонные линии не рекомендуются.

! Желательно, чтобы входы и выходы блоков имели однозначную ориентацию. Например, если определено, что входная линия присо­единяется к блоку сверху, то иное присоединение (справа, слева и снизу) следует считать не очень хорошим.

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

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

! Замкнутые контуры предпочтительнее, чем разорванные линии.

! Следует использовать простые и интуитивно ясные средства, позволяющие отделить смысловую фигуру (простую или составную) от фона.

! Линии контура блоков должны быть жирнее, чем соединительные линии.

! Следует использовать также некоторые правила, рекомендуемые в инженерной психологии для проектирования средств отображения информации, например правило метра и ритма [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.