Графика или текст:какой язык нужен программисту?

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

Большинство программистов считает, что графическая форма представления информации предпочтительнее любой другой. На рынке появляются разнообразные языки визуального программирования. В названиях программных продуктов и CASE-средств, изначально базирующихся на текстовой форме описания, производители стараются подчеркнуть ориентацию на графику (пример — Visual C). Уже нельзя представить жизнь без средств разработки категории WYSIWYG, а подавляющее большинство программ для ПК реализуется в соответствии с формулой WIMP (window — icon — menu — pointing_device). В качестве эпитетов для графических средств используются слова «дружественный», «интуитивно понятный», «простой», «привлекательный». Часто графика позиционируется как прогрессивная альтернатива «устаревшей» текстовой форме представления. Однако при попытках найти строгое теоретическое или экспериментальное обоснование подобным заявлениям выявляются крайне нелицеприятные для графики факты. Ни теория, ни эксперимент не позволяют говорить о несомненном превосходстве графической формы представления алгоритмов. Более того, специалисты по эргономике утверждают: нередки случаи, когда графическая форма записи менее понятна, чем обычная текстовая. Классический пример, демонстрирующий неоднозначность работы с графикой, был выявлен при анализе графических языков LabView [1].

Рис. 1. Графическая и текстовая форма представления (знак в треугольнике — логическое отрицание, знак в прямоугольнике — логическое И)

Сравнительный анализ двух вариантов записи (рис. 1) показывает ощутимую сложность работы с графикой — менее компактное представление, наличие пересечения линии, обилие элементов затрудняют для графики ответы на достаточно простые вопросы. Эти умозрительные выводы подтверждает и экспериментальная проверка; в эксперименте [1] участвовало две группы. Одной группе предъявлялось графическое представление, другой — текстовое. Задавался вопрос, «значение какого из выходов будет ИСТИННО, если входы А и B имеют значение ЛОЖНО?». Эксперимент показал, что ответ на вопрос в случае графического представления занимает в два раза больше времени, чем при работе с текстом.

Выводы специалистов в области эргономики поддерживают и программисты-профессионалы, которые критикуют WIMP-средства за неповоротливость, неуклюжесть, избыточность и неудобство. В чем тут дело?

Психология запоминания и критерии оценки языка

Давно подмечено, что для успешной разработки языковых средств и определения критериев их оценки требуются определенные познания в области психологии. Эта мысль присутствует в трудах А. Ершова, У. Дала, Э. Дейкстры, К. Хоора. Исследования в области психологии программирования [2] показывают, что использование имеющихся в психологии методов позволяет повысить качественный уровень программирования, освободившись от вредных заблуждений. Действительно, программирование не может быть сведено к математическим формализмам: обоснование для существования идентификаторов, структуризации, языков высокого уровня следует искать в первую очередь в человеческой природе. К сожалению, рассматривая свойства языков, «человеческий фактор» либо просто игнорируют, либо проводят на непрофессиональном уровне. Между тем, даже поверхностное знание того, как функционирует человеческая память, позволяет более качественно оценить выразительные средства.

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

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

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

Текст и графика. Плюсы и минусы

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

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

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

Графика позволяет использовать метафору, то есть представление новых или необычных для пользователя явлений через другие явления, хорошо ему известные из повседневной жизни [3]. Механизм работы метафоры с точки зрения психологии заключается в использовании уже существующих у пользователя знаний — долговременной памяти. Это чрезвычайно упрощает освоение нового продукта для новичков в программировании. Классическим примером такого подхода при создании языкового средства служит язык релейных схем (ladder diagram) из состава международного стандарта МЭК 61131. Алгоритм работы устройства на этом языке описывается в виде соединенных реле, которые широко применялись в 60-х годах. Язык релейных схем был ориентирован на пользователей, знакомых с реле, и упрощал переход управления с реле на микроконтроллеры. Схож по принципу построения и язык функциональных блоков (function block diagram), описанный в том же стандарте. Алгоритм работы некоторого устройства, выраженный средствами этого языка, напоминает функциональную схему электронного устройства с элементами «логическое И», «логическое ИЛИ» и т.п., соединенными линиями-проводниками. Однако кажущаяся простота такого подхода таит в себе «подводные камни»; даже для относительно простых случаев очень трудно подобрать подходящую метафору, выразительная сила метафорического языка крайне низка, существует опасность возникновения «метафорических артефактов», побочных аналогий в сознании пользователя [3]. Построение действительно полезной графики является скорее искусством, чем операцией, доступной любому пользователю.

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

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

Создание программ. Специфика предметной области

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

Единственно эффективное направление работы со сложными системами, способное гарантировать выполнение этого комплекса противоречивых требований, основывается на иерархическом подходе. Выявление иерархической структуры — «творческий процесс, часто требующий использования знаний, которые будут получены лишь на более поздней стадии конструирования системы. Таким образом, как ни болезненно воспринимать этот факт программисту, всякое проектирование программного обеспечения представляет собой сложный итеративный процесс, включающий реконструкцию и исправление на каждой стадии разработки». Время и силы, затраченные на этапе проектирования, вознаграждаются тем, что при удачной декомпозиции каждый компонент можно программировать и модифицировать независимо или почти независимо от остальной системы [4]. Можно добавить, что этап проектирования предполагает большую нагрузку на кратковременную память, что обуславливает острую постановку проблемы закрытия. От разработчика требуется высокая степень терпимости к неопределенности [2]. По завершению этапа проектирования разработчик получает структурированное представление о задаче, возможных путях ее решения; может бегло ориентироваться в проблеме — информация о задаче перемещается в долговременную память.

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

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

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

Поскольку, как отмечалось, к программе предъявляется комплекс разнообразных требований, на этапе проектирования она рассматривается в различных ракурсах: с точки зрения взаимодействия с пользователем, с точки зрения интеграции в существующую систему, с точки зрения данных, потока управления и т.п. Необходимость таких проработок привела к появлению набора графических средств многоаспектной спецификации — языка моделирования Unified Modeling Language. Такой «ракурсный» подход ограничивает рассматриваемую область, позволяя временно устранить часть деталей, что дает возможность сконцентрировать внимание на одной подпроблеме, снизить нагрузку на кратковременную память и преодолеть проблему закрытия. Время создания законченной модели сокращается. Основные побочные эффекты данного подхода таковы: средствами UML невозможно соединить разработанные ракурсы воедино и, следовательно, создать спецификацию, пригодную для получения из нее машинных кодов; содержание модели, как правило, неформализовано, непригодно для автоматического получения машинных программ.

Говоря об UML, нужно сделать ремарку о его недостаточной увязке с более ранними наработками в области стандартизации. Вызывает сожаление явно неудачная попытка дублирования стандартов ISO в части создания средств описания потока управления (язык activity diagram) — средств, хорошо известных отечественному пользователю по Единой Системе Программной Документации.

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

Области применимости графики и текста

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

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

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

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

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

Таким образом, при создании сложных программ значительно повысить эффективность можно за счет совместного использования графических средств разработки, например, набора языков UML, и текстовых средств кодирования, например, Си++. К выводу о возможности применения нескольких языков при создании программы приходят и другие авторы. Например, в [7] говорится: «На каждом шаге имеется свой уровень абстрактного представления программного продукта. Для каждого уровня программистом используются свои, наиболее целесообразные языковые средства, которые при переходе к следующему уровню абстракции подвергаются усложняющим их преобразованиям до тех пор, пока не будет получено требуемое представление программы (например, на языке Фортран)». Не следует смешивать способ создания программ с мультиязыковым программированием — использованием разных языков на одном уровне абстракции (кодировании), что крайне негативно сказывается на надежности создаваемого программного обеспечения [2, 5]. Например, одновременное использование Фортрана и Си, как правило, приводит к «классическим» ошибкам, обусловленным разными принципами индексации массивов. В нашем же случае речь идет об использовании разных языковых средств программирования для разных уровней абстракции.

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

Серьезные проблемы с обеспечением бесшовности могут свести на нет все перечисленные преимущества. Графическая спецификация должна быть картой, облегчающей ориентацию в алгоритме на этапе кодирования. А интеллектуальные усилия программиста на этапе кодирования должны быть направлены только на описание тонкостей машинной реализации. Поскольку задачи программирования распадаются на классы, не может быть предложена универсальная пара графического и текстового языков, обеспечивающая бесшовный переход. Для каждого выделенного класса должна быть выявлена проблемно-ориентированная «графо-текстовая» пара, для которой должно быть показано существование бесшовного перехода. Например, для блок-схем и автоматных языков в случае описания управляющих алгоритмов существует простое преобразование из графики в текст [8].

Заключение

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

Литература

1. Green T.R.G., Petre M. When Visual Programs are Harder to Read than Textual Programs. Human-Computer Interaction: Tasks and Organization, Proc. 6th European Conference on Cognitive Ergonomics. G.C. van der Veer, M.J. Tauber, S. Bagnarola, M. Antavolits (Eds.), Rome, 1992.
2. Шнейдерман Б. Психология программирования. М.: Радио и связь. 1984.
3. Авербух В.Л. Метафоры визуализации. Программирование, 2001, № 5.
4. У., Дейкстра Э., Хоор К. Структурное программирование. М.: Мир, 1975.
5. Review Guidelines on Software Languages for Use in Nuclear Power Plant Safety Systems. Decker D., Dinsmore G., Graff S., Green W., Hecht H., Justice M., Koch S., Lin D., Ossia K., Pollard J., Shorki E., Sorkin A., Tai A., Tso K.S., Wendelboe D. NRC, 1997.
6. Хазин Б. Мост над пропастью. // Открытые системы, 1996, № 1.
7. Шабалин А.Н. О росте сложности разрабатываемой программы. // Программирование, 1988, № 6.
8. Зюбин В.Е. Графические и текстовые формы спецификации сложных управляющих алгоритмов: непримиримая оппозиция или кооперация? VIII Международная конференция по электронным публикациям (EL-Pub2003), Новосибирск, 2003.

Структура памяти человека

Графика против текста

Специфика графических признаков

Случаи эффективного использования