SoftCraft
разноликое программирование

Top.Mail.Ru

Графические и текстовые формы спецификации сложных управляющих алгоритмов: непримиримая оппозиция или кооперация?

Зюбин В.Е.
Институт автоматики и электрометрии СО РАН, Новосибирск

Опубликовано в сборнике трудов VII Международной конференции по электронным публикациям "EL-Pub2002"
8-10 октября 2003 г., г. Новосибирск, Академгородок
[ http://www-sbras.nsc.ru/ws/elpub2003/ ]

Анотация


        Графические средства программирования привлекают внимание специалистов. Основная причина этого интереса заключается в достаточно распространенном мнении о безусловной предпочтительности графики. Примечательно то, что сам тезис о преимуществах графики так и не получил однозначного экспериментального подтверждения. Экспериментальные данные весьма противоречивы. Почему в одних случаях использование графики правомерно, а в других имеет явно негативный эффект? В самом начале эры программных языков высокого уровня специалистами было обращено внимание на то, что ответ на вопрос о применимости формального языкового средства должен лежать в сфере психологии, должен быть связан с природой человека и структурой его памяти. В рамках этой концепции возникло тесно переплетающееся с психологией научное направление HCI (human computer interaction), оказавшееся весьма плодотворным. Однако до сих пор исследование эргономических характеристик языков так и не вошло в практику при их разработке.

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


Насколько идеальна графика?

        Большинство программистов считают, что графическая форма представления информации предпочтительнее любой другой. На рынке появляются разнообразные языки визуального программирования. Чувствуя тенденцию, производители используют привлекательное слово в названиях средств, изначально базирующихся на текстовой форме описания (например, Visual C). Мы уже не можем представить свою жизнь без средств разработки класса WYSIWYG (what-you-see-is-what-you-get), подавляющее большинство ПО персональных компьютеров - это средства WIMP (windows-icons-menu-pointing_device). В качестве эпитетов для графики используются слова "дружественный", "интуитивный", "простой" , "читабельный", "привычный", "привлекательный", "надежный", "понятный", "легкий", "запоминающийся", "непосредственный", "очевидный" . Часто графика позиционируется как некая оппозиция "устаревшей" текстовой форме представления. Однако при попытках найти строгое теоретическое или экспериментальное обоснование подобным заявлениям выявляются крайне нелицеприятные для графики факты: эксперимент не позволяет говорить о несомненном превосходстве графической формы представления алгоритмов. Более того, нередки случаи, когда графическая форма записи уступает обычной текстовой [1, 2, 3, 4].

        Один из классических примеров несовершенства графики был выявлен в [1]:

figure 01.jpg




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


        Пример является аналогом текстовой записи (язык Си):
        C = A;
        D = !A && B;
        E = !A && !B;

        Сравнительный анализ двух форм показывает чрезвычайную сложность работы с графикой в данном случае. Менее компактное представление, наличие пересечения линии, обилие элементов затрудняют для графики ответы на достаточно простые вопросы. Например, для приведенного примера экспериментальная проверка показывает, что ответ на вопрос, "значение какого из выходов будет "ИСТИННО", если значение входов А и B "ЛОЖНО"?", занимает в случае графики в два раза больше времени, чем в случае текста.

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

        В чем тут дело?


База для выработки критериев оценки выразительных средств

        В самом начале эры языков высокого уровня специалисты обратили внимание на то, что исследование языковых средств и критерии их оценки должны лежать в области психологии и эргономики. Эта мысль присутствует в трудах Ершова А.П. [7], Дала У., Дейкстры Э., Хоора К. [8]. Первые же серьезные исследования в области психологии программирования [например, 9] показали, что использование имеющихся в психологии хорошо разработанных методов и знаний позволяет повысить качественный уровень программирования и освободиться от существующих вредных заблуждений.

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

        Наибольший интерес с точки зрения понимания когнитивных механизмов представляет кратковременная память, обеспечивающая динамическую работу с информативными сущностями. Кратковременная память впервые была описана в классической работе Дж. Миллера "Магическое число семь - плюс или минус два: предел наших способностей обрабатывать информацию" [10]. Основной вывод работы - в ее названии. Другой чрезвычайно интересный вывод Миллера, сделанный по результатам эксперимента, - возможность преодолеть ограничения за счет разбиения информации по разным признакам: "лучше (проще - В.З.) знать немногое о многом, чем многое о немногом" [там же]. Например, возможность обработки существующего числа фонем - числа, заведомо большего, чем семь, - объясняется тем, что фонема имеет несколько признаков. Звук может быть гласным, согласным, глухим, звонким, шипящий и т.д. Использование кратковременной памяти сопряжено также с высокой степенью напряжения человека, что ведет к стремлению выгрузить информацию и отдохнуть. Эта особенность работы с кратковременной памятью называется в психологии проблемой закрытия [9].

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


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

        Понимание механизмов ментальной деятельности человека позволяет объяснить многие факты и выработать некоторые принципы оценки языкового средства. Во-первых, относительно формы представления становится очевидным, что форма представления сама по себе не важна. Во-вторых, оценка языкового средства возможна только после анализа того, насколько данное средство удобно для работы. При анализе требуется учитывать: а) особенности прикладной области, б) характеристики пользователя и в) принципы работы компьютера [11, 12]. При этом важнейшим качеством языка записи исходного текста программ является понимаемость, как свойство программы минимизировать интеллектуальные усилия, необходимые для ее понимания [13].

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

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

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

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

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

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


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

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

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

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

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

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

        Проектирование, несмотря на исключительную важность, является неформализуемым этапом создания программы [9]. Большую часть усилий на этапе проектирования занимает выявление задачи, что предполагает активное взаимодействие разработчика с пользователем, который не является программистом. Более того, пользователь зачастую и сам не имеет четкого представления о своих нуждах. Попытка выбрать для общения с пользователем формальный язык или специализированную компьютерную терминологию обречена на неудачу в силу языковой нестыковки [26]. Хорошая подборка материалов по разработке программного интерфейса, проблеме общения с потенциальным пользователем и критериям оценки полезности (usability) программ представлена в [27].

        Поскольку программа является многоаспектной сущностью, ее проектирование предполагает различные ракурсы рассмотрения: с точки зрения взаимодействия с пользователем, с точки зрения интеграции в существующую систему, с точки зрения данных, потока управления и т.п. Необходимость таких проработок привела к появлению UML (Unified Modeling Language) - набора графических средств многоаспектной спецификации [28]. Такой "ракурсный" подход ограничивает рассматриваемую область, позволяет снизить нагрузку на кратковременную память и преодолеть проблему закрытия. Время создания законченной модели сокращается. Основные побочные эффекты такого подхода - а) средствами UML невозможность соединить разработанные ракурсы воедино и, следовательно, создать спецификацию, пригодную для получения из нее машинных кодов, б) содержание модели, как правило, неформализовано.


ПРИМЕЧАНИЕ. Говоря об UML, нужно сделать ремарку о недостаточной увязке UML с более ранними наработками в области стандартизации. К преимуществу UML следует отнести наличие языков спецификации структуры данных, сценариев, появившихся в рамках развития объектно-ориентированного программирования, а также в связи с широким использованием персональных компьютеров в малом бизнесе и индустрии развлечений. К недостаткам UML следует отнести явно неудачную попытку дублирования стандартов ISO в части создания средств описания потока управления - средств, хорошо известных отечественному пользователю по Единой Системе Программной Документации [29].

        Следует отметить особенности рассматриваемого класса задач - управляющие программы предполагают развитие событий в системе во времени, т.е. алгоритм имеет некоторую направленность. События необратимы. После того, как событие произошло, следует незамедлительная реакция системы, поведение системы меняется. После того, как система прореагировала, в подавляющем большинстве случаев становится неважно, что привело к изменению системы, к ее переходу в новое состояние. В силу этих причин блок-схемы, как графическое средство спецификации алгоритмов, получили широкое распространение. В качестве базовых моделей описания алгоритмов в области автоматизации наибольшей популярностью пользуются конечные автоматы и родственные им сети Петри [16, 30, 31]. Популярность этих средств объясняется их изначальной ориентацией на описание потока управления.


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

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

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

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

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

        К выводу о возможности применения нескольких языков на этапе создания программы приходят и другие авторы. Например, в [35] говорится: "На каждом шаге имеется свой уровень абстрактного представления программного продукта. Для каждого уровня программистом используются свои, наиболее целесообразные языковые средства, которые при переходе к следующему уровню абстракции подвергаются усложняющим их преобразованиям до тех пор, пока не будет получено требуемое представление программы (например, на языке Фортран)". Следует подчеркнуть, что не следует путать предлагаемое с т.н. мультиязыковым программированием, потенциально опасным в плане возникновения ошибок и критикуемым во всех серьезных работах [9, 24]. Например, одновременное использование Фортрана и Си чревато "классическими" ошибками, обусловленными разными принципами индексации массивов. Да, при использовании языков разных уровней абстракции ошибки мультиязыкового программирования исключены. Однако при переходе с этапа проектирования программы на этап кодирования может возникнуть другая проблема - проблема бесшовности, т.е. проблема затрат на преобразование графической формы проектирования в текстовую форму кодирования.

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

        Алгоритм гладкого перехода от блок-схем к тексту может быть предложен на основе уже существующего частичного решения, используемого в рамках стандарта МЭК 61131-3 [16], и языка РЕФЛЕКС, известного ранее под рабочим названием Средство Программирования Алгоритмов Работы Микроконтроллеров (СПАРМ) [36]. Язык SFC из состава языков МЭК 61131-3 трактует состояние конечного автомата как пару, состоящую из двух элементов: шага (step, обозначаемого символом "процесс" блок-схем, прямоугольник) и перехода (transition, обозначаемого символом "решение" блок-схем, ромб). В терминах конечного автомата шаг - это спецификация функции выходов конечного автомата (преопределенные действия с переменными), а переход - спецификация функции переходов (условные операторы изменения потока управления). Таким образом, любая последовательная блок-схема (или ее последовательная часть) может быть преобразована к автоматному виду - паре "шаг-переход". Шаг допустимо делать пустым или объединять в нем серию последовательно идущих друг за другом процессов (в терминах блок-схем, далее, во избежание путаницы из-за разного смысла термина "процесс" в блок-схемах и языке РЕФЛЕКС, слово "процесс" помечается ТБС и ТЯР соответственно). Переход, не содержащий анализа условий, можно опускать. Таким образом, любой последовательный участок блок-схемы может быть представлен в виде последовательности состояний конечного автомата (см. пример такого разбиения на Рис. 2).

figure 02.jpg

Рис. 2. Пример выделения состояний для линейного участка блок-схемы


        Все последовательные участки блок-схемы, преобразованной к виду шаг-переход, выделяются в процессы (ТЯР). В процессы (ТЯР) выделяются и "предопределенные процессы" (ТБС). Синхронизация (дивергенции и конвергенции процессов) производится штатными средствами языка посредством операторов СТАРТ (конвергенция) и операторов проверки активности текущего процесса (дивергенция) (см. Рис. 3). Другим важным свойством языка РЕФЛЕКС, которое обязательно следует упомянуть при рассмотрении вопроса бесшовности, является русскоязычность, обеспечивающая сохранение информативных идентификаторов стадии разработки.

figure 03.jpg

Рис. 3. Пример выделения процессов в произвольном алгоритме, записанном в виде блок-схемы


        Таким образом, формальное построение автомата в терминах языка РЕФЛЕКС не связано с привлечением инородных механизмов, т.е. бесшовно. На практике некоторые операторы языка РЕФЛЕКС (в частности, оператор ТАЙМАУТ) даже упрощают запись алгоритма в текстовом виде за счет компактного выражения ситуаций, наиболее часто встречающихся на практике. Число состояний, полученных формально, может быть сокращено, если различать ситуационные (предполагающие реакцию внешнего окружения процесса) и алгоритмические (возникающие при локальных математических вычислениях) условия. Алгоритмические условия не требуют выделения в отдельное состояние, поэтому состояния, обусловленные алгоритмическими переходами (знак "решение"), могут быть сокращены. Такое сокращение также способствует более компактному представлению и только упрощает текстовую запись алгоритма.


Заключение

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


Литература

  1. Green T. R. G., Petre M. When Visual Programs are Harder to Read than Textual Programs // Human-Computer Interaction: Tasks and Organisation, Proc. ECCE-6 (6th European Conference on Cognitive Ergonomics). G. C. van der Veer, M. J. Tauber, S. Bagnarola and M. Antavolits (Eds.) CUD: Rome, 1992.
    [ http://citeseer.nj.nec.com/green92when.html ]
  2. Brooke J. B., Duncan K. D. Experimental studies of flowchart use at different stages of program debugging // Ergonomics. 1980. V. 23.
  3. Curtis B., Sheppard S., Kruesi-Bailey E., Bailey J. and Boehm-Davis D. Experimental evaluation of software documentation formats. // J. Systems and Software. 1989. V. 9. No 2.
  4. Whitley K. N. Visual Programming Languages and the Empirical Evidence For and Against // Journal of Visual Languages and Computing. 1997. V. 8/ No 1. [ http://citeseer.nj.nec.com/whitley96visual.html ]
  5. вэн Дам Э. Пользовательские интерфейсы нового поколения // Открытые системы. 1997. No 6. [ http://www.osp.ru/os/1997/06/34.htm ]
  6. Карпов Д.Ю. Этот мерзкий, неудобный, противоестественный оконный интерфейс [опубликовано на http://www.webclub.ru ]
  7. Ершов А.П. О человеческом и эстетическом факторах в программировании // Программирование. 1990. No 1.
  8. Дал У., Дейкстра Э., Хоор К. Структурное программирование. М.: Мир. 1975. -248 с.
  9. Шнейдерман Б. Психология программирования. М.: Радио и связь. 1984. - 304 с.
  10. Miller G.A. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information // Psychological Review. 1956. V. 63. No 2.
  11. Авербух В.Л. Метафоры визуализации // Программирование. 2001. No5.
  12. Бургин М.С. Переменные в языке блок-схем // Программирование. 1978. No 2.
  13. Саркисян А.А. Повышение качества программ с помощью автоматизированных методов. М. 1991.
  14. Зюбин В.Е. Исследование условий применимости языка параллельного программирования СПАРМ для задач построения надежных управляющих программ // Распределенная обработка информации: Тр./Шестой международный семинар. -Новосибирск. 1998
  15. Андриенко Г.Л., Андриенко Н.В. Интеллектуальная картографическая визуализация для поддержки исследования данных в системе IRIS // Программирование. 1997. No 5.
  16. IEC 65B/373/CD, Committee Draft - IEC 61131-3. Programmable controllers. Part 3: Programming languages, 2nd Ed. // International Electrotechnic Commission. 1998.
  17. Касьянов В.Н. Применение графов в программировании // Программирование. 2001. No 3.
  18. Бабурин Д.Е., Бульонков М.А., Емельянов П.Г., Филаткина Н.Н. Средства визуализации при перепроектировании программ. // Программирование. 2001. No 2.
  19. Жоголев Е.А. Графические редакторы и графические грамматики // Программирование. 2001. No 3.
  20. Зюбин В.Е. К пятилетию стандарта IEC 1131-3. Итоги и прогнозы. // Приборы и системы управления. 1999. No 1.
  21. Labrosse J.J. C Coding Standard. Application Note AN-1003 // Micrium, Inc. [ http://www.micrium.com ]
  22. Билкун С.Н., Маслюк Г.Ф. О структурном программировании // Программирование. 1976. No 5.
  23. Vessey I. Cognitive fit: a theory-based analysis of the graphs versus tables literature. // Decision Sciences. 1991. Vol. 22. No 2.
  24. 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. [ http://www.nrc.gov ]
  25. Ericsson K.A., Kintsch W. Long-Term Working Memory // Psychological Review. 1995. V. 102. No 2.
  26. Хазин Б. Мост над пропастью // Открытые системы. 1996. No 1. [ http://www.osp.ru/os/1996/01/70.htm ]
  27. Перевалов Я. Usability в России. Web-портал. [ http://usability.ru/ ]
  28. Леоненков А.В. Самоучитель UML. СПб.: БХВ-Петербург. 2001. - 304 с.
  29. ГОСТ 19.701-90 (ISO 5807-85) Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения // ЕСПД. Издательство стандартов. 1994.
  30. Зюбин В.Е. Проектирование алгоритмов работы микроконтроллеров // Приборы и системы управления. 1998. No 1.
  31. Легалов.А.И. Разноликое программирование. [ http://www.sofcraft.ru ]
  32. Кауфман В.Ш. Принципы стандартизации языков программирования // Программирование. 1988. No 3.
  33. Church T., Matthews P. An Evaluation of Object-Oriented CASE-tools: The Newbridge Experience // CASE'95 Proceedings. Seventh International Workshop on Computer-Aided Software Engineering / Toronto, Ontario, Canada July 10-14, 1995. IEEE Computer Society Press. 1995.
  34. Shanmugham S.G., Roberts C.A. Application of graphical specification methodologies to manufacturing control logic development: a classification and comparison // Int. J. Computer integrated manufacturing. 1998. V. 11. No 2.
  35. Шабалин А.Н. О росте сложности разрабатываемой программы // Программирование. 1988. No 6.
  36. Зюбин В.Е. Язык СПАРМ - средство программирования микроконтроллеров // Автометрия. 1996. No 2.