Схемы действий и язык Дракон

Мартин подчеркивает, что среди различных графических средств, используемых в методологии 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].