Глава 24
ЧТО ДЕНЬ ГРЯДУЩИЙ НАМ ГОТОВИТ?
(Проект преобразования
алгоритмического языка)Визуализация дает возможность увидеть невидимое — она интенси-
фицирует процесс научного открытия и способствует рождению глу-
боких и неожиданных озарений.
Александр Зенкин [1]ЦЕЛЬ ПРОЕКТА —
РАЗВИТЬ АЛГОРИТМИЧЕСКОЕ МЫШЛЕНИЕ
КАК СОЦИАЛЬНО НЕОБХОДИМЫЙ НАВЫКОдна из важнейших задач книги состоит в следующем:
• Подвергнуть критике существующие (традиционные)
способы представления алгоритмов (но не программ);
• Предложить новый способ представления алгоритмов
(имеется в виду алгоритмический язык Дракон);
• Подчеркнуть, что существует возможность во многих
или даже в большинстве случаев полностью отказаться от тради-
ционных способов представления алгоритмов и безболезненно
заменить их на язык Дракон;
• Для обозначения отказа от традиционных способов
в пользу языка Дракон мы используем термин «Проект преоб-
разования алгоритмического языка»;
• По нашему мнению, широкомасштабная практическая
реализация Проекта позволит получить существенный выигрыш;
• Мы не рассматриваем практическую реализацию Проекта
как некую бюрократическую процедуру, требующую вмешательства
каких-либо влиятельных инстанций или авторитетных кругов;
• Мы исходим из того, что реализация Проекта будет проис-
ходить естественным путем, без всякого давления сверху
• Проект будет осуществляться по мере распространения све-
дений о языке Дракон в результате добровольного решения и свобод-
ного волеизъявления людей, проявляющих интерес к данной теме;
• Мы возлагаем надежду на добровольную инициативу учителей
школ и преподавателей университетов, которые пожелают ввести в прог-
рамму своих курсов (программу обучения) информацию о языке Дракон
• Важным каналом распространения информации о Драконе явля-
ются различные форумы в сети Интернет, публикации и т.д.
• Особую роль в Проекте играют усилия инициативных групп и
отдельных специалистов, которые будут создавать все более совершен-
ные дракон-редакторы и другие средства. Это позволит закрепить навыки
алгоритмизации на практике, приблизить их к жизни. Чтобы любой человек,
нажимая на клавиши компьютера, мог убедиться в удобстве и эффективно-
сти работы с языком Дракон, так сказать, на кончиках пальцев.
• Конечный результат Проекта подразумевает широкое распростра-
нение алгоритмического мышления и преодоление ныне существующей
массовой алгоритмической неграмотности. (Разумеется, алгоритмическое
мышление не противопоставляется другим типам человеческого мышления,
а всего лишь дополняет и обогащает их).
ТРАДИЦИОННЫЕ СРЕДСТВА ЗАПИСИ АЛГОРИТМОВ УСТАРЕЛИ
И ПРЕВРАТИЛИСЬ В ТОРМОЗ РАЗВИТИЯ ОБЩЕСТВАДля наших целей необходимо развести два понятия:
• алгоритмический язык (именно на нем мы сосредоточим
внимание в данной главе);
• языки программирования (о них будет лишь кратко упомя-
нуто в конце главы в «Проекте преобразования языков программиро-
вания»).
Четкое разделение понятий «программы и алгоритмы» означает, что
мы рассматриваем языки программирования как средство для записи
программ, но не алгоритмов. Языки программирования не приспособ-
лены для записи алгоритмов. Поэтому мы исключаем их из рассмот-
рения.
Причина проста: чтобы превратить исходники в удобную для понимания
форму представления алгоритмов, понятную для других людей, надо зат-
ратить неоправданно большой труд. Это невозможно реализовать на прак-
тике в приемлемых масштабах.
Использование принципов объектно-ориентированного программирования
еще более усугубляет проблему алгоритмизации. Оно исключает возмож-
ность целостного восприятия сложной алгоритмической картины. И превра-
щает сложные алгоритмы в кусочно-рваную мозаику, непригодную для
быстрого понимания.
В результате непрограммирующие специалисты лишаются доступа в мир
алгоритмов. Мы рассматриваем этот факт как серьезную социальную проб-
лему, как неоправданное препятствие, ограничивающее интеллектуальные
возможности общества.
По нашему мнению, большинство программистов недооценивает важность
проблемы, связанной с умением создавать сложные алгоритмы, пригодные
для быстрого понимания ЧЕЛОВЕКОМ.
Исходя из этого, мы отклоняем традиционные представления об алгоритми-
ческом языке как неудовлетворительные и устаревшие.
Какие же средства предлагает нам традиция для записи алгоритмов (но не
программ)?
К числу наиболее известных можно отнести:
• псевдокод (pseudo code);
• блок-схемы алгоритмов (flowcharts).
ЧТО ТАКОЕ ПСЕВДОКОД?Псевдоко́д — упрощенный язык описания алгоритмов, предназначен-
ный для восприятия алгоритмов человеком, а не для трансляции в
машинный код. Для обозначения управляющих структур используют-
ся ключевые слова и отступы (интендация).
Можно сказать, что псевдокод — это вариант письменного разговор-
ного языка, сокращенный для создания видимости компьютерного
языка высокого уровня.
Цель использования псевдокода — сделать описание алгоритма более
воспринимаемым, чем исходный код на языке программирования. Псевдо-
код широко используется в учебниках и научно-технических публикациях.
Иногда он применяется на начальных стадиях разработки компьютерных
программ.
В отличие от стандартизации синтаксиса языков программирования, на
синтаксис псевдокода обычно не устанавливается стандартов, так как
последний непосредственно не компилируется в исполняемую програм-
му.
Обычно каждый автор публикации применяет свой оригинальный псевдо-
код. Чтобы сделать текст понятным для читателя, авторы публикаций,
содержащих псевдокод, иногда заимствуют нужные им конструкции из
какого-либо языка программирования.
Бывает и по-другому. Зачастую источником псевдокода служат сразу
несколько языков. Поэтому псевдокод может не содержать специфи-
ческих признаков конкретного языка программирования. Кроме того,
математические выражения часто включаются в псевдокод в том виде,
как их принято записывать в математике, а не в языках программирова-
ния.
Некоторые фрагменты псевдокода могут быть фразами естественного
языка (русского, английского и т. д.).
Нередко в псевдокоде применяют управляющие конструкции таких
языков программирования, как Паскаль, Си, Фортран и др. Их исполь-
зование можно объяснить как личными симпатиями авторов, так и рас-
пространенностью на момент написания книги или статьи.
В русско-язычных текстах в качестве псевдокода часто используется
перевод ключевых слов языков программирования с английского на
русский. Такой подход практикуется, в частности, в учебниках по инфор-
матике.
Псевдокод удобен для записи простых алгоритмов. Если же алгоритм
становится чуть сложнее и занимает несколько страниц, чтение псевдо-
кода становится затруднительным. Порою оно напоминает работу по рас-
шифровке египетских иероглифов.
Рассмотрим случай, когда на псевдокоде записан многостраничный алго-
ритм. Например, «Алгоритм Global_Value_Numbering, реализующий проце-
дуру обнаружения неэффективных мест в программе на основе глобального
метода нумерации значений».
Текст этой процедуры на псевдокоде занимает 12 страниц книги
[2, с. 120—131]. Легко убедиться, что запись сложного алгоритма
на псевдокоде создает неоправданные помехи для понимания и
требует значительных затрат труда и времени.
Итоговые замечания:
• Псевдокод является важным социальным изобретением,
получившим широкое распространение. Но только для программи-
стов и математиков.
• Недостатки псевдокода являются продолжением его
достоинств. Сюда относятся принципиальная невозможность
стандартизации и принципиальная невозможность общепринятой
формализации управляющих структур.
• Фундаментальным недостатком является полная непри-
годность псевдокода для непрограммирующих специалистов. Псев-
докод наглухо закрывает для них дорогу в мир сложных алгоритмов,
обрекая население на алгоритмическую неграмотность.
БЛОК-СХЕМЫ АЛГОРИТМОВБлок-схемы алгоритмов при желании можно раcсматривать как гра-
фическую альтернативу псевдокоду. Одно из отличий состоит в том,
что для псевдокода стандартов нет, а для блок-схем есть.
Действующий международный стандарт на блок-схемы (flowcharts)
ISO 5807—85 выпущен в 1985 году [3]. Отечественный стандарт
ГОСТ 19.701—90 [4] является точной копией международного.
По нашему мнению, указанные стандарты имеют множество
недостатков и являются устаревшими.
Существуют и другие средства для записи алгоритмов. В некоторых
англоязычных учебниках наряду с псевдокодом и блок-схемами
используются диаграммы Насси-Шнейдермана (см., например, [5]).
Создание блок-схем связано с именем выдающегося ученого Джона
фон Неймана. Блок-схемы оказались удивительно эффективным
социальным изобретением, которые завоевали огромную популяр-
ность, вышли далеко за пределы информатики и проникли почти
во все области знания.
________________________________________________________
Пример
использования блок-схем алгоритмов
в медицинской литературеВ медицинском руководстве [6] приведены блок-схемы диагно-
стических алгоритмов клинических синдромов, наиболее часто
встречающихся в общей врачебной (семейной) практике. В руко-
водстве представлены блок-схемы 24 диагностических алгорит-
мов, в том числе: остро возникшая головная боль, хроническая
головная боль, головокружение, синкопальное состояние, нару-
шение остроты зрения, красный глаз, боль в ухе, боль в горле,
боль в груди и т.д.
_________________________________________________________________________
ДОСТОИНСТВА И НЕДОСТАТКИ БЛОК-СХЕМ
• Блок-схемы алгоритмов — это единственный алгоритмический
язык, который сумел преодолеть пропасть между информатикой и други-
ми дисциплинами и найти применение во многих (почти во всех) областях
человеческого знания.
• Хотя при обучении программированию, псевдокод нередко
рассматривается как основное средство, однако, популярность блок-
схем во много раз превышает популярность псевдокода, если учесть
не только программирование и математику, но и другие отрасли зна-
ния.
• Визуальный синтаксис блок-схем алгоритмов, описанный
в действующих стандартах, имеет серьезные недочеты. Он не имеет
научного (математического и когнитивно-эргономического) обоснова-
ния.
• Это обстоятельство является фундаментальным недостатком
блок-схем, который резко ограничивает возможности людей и создает
непреодолимый барьер при работе со сложными алгоритмами.
• Блок-схемы способны проникнуть во многие области знания,
однако они пригодны для работы только с простыми алгоритмами. Блок-
схемы принципиально не позволяют выразить содержание сложных алго-
ритмов. Потому что с ростом сложности блок-схемы стремительно теряют
наглядность и становятся нежизнеспособными.
• Сказанное означает, что блок-схемы алгоритмов и другие тради-
ционные средства не позволяют преодолеть нынешнюю массовую алгорит-
мическую неграмотность.
ПРИЧИНЫ
МАССОВОЙ АЛГОРИТМИЧЕСКОЙ НЕГРАМОТНОСТИМы живем в обществе знаний. Носителями профессиональных знаний
являются специалисты, например, агрономы, нефтяники, микробиологи,
технологи, экономисты, химики, врачи. Большинство из них далеки от
программирования.
Парадокс в том, что эти люди прекрасно знают свою работу. Они четко
знают последовательность выполняемых ими действий, то есть алгорит-
мы своей работы. А также алгоритмы предметной области.
Но они, увы, не знают, что их знания называются алгоритмами. Эти заме-
чательные специалисты не умеют описывать алгоритмы. Они не умеют
расчленять свои знания и выделять среди них алгоритмическую (проце-
дурную) часть. Они не в состоянии выразить свои знания на бумаге в
форме алгоритмов.
Допустима ли подобная алгоритмическая неосведомленность? В чем
причина алгоритмической неграмотности? Неграмотности подавляю-
щего большинства специалистов?
Это важный вопрос. Чрезвычайно важный.
______________________________________________________________
Нынешние алгоритмы, используемые во всем мире, имеют серьезный
дефект. Они чрезвычайно трудны для понимания.
______________________________________________________________
Существующая практика изучения, разработки и эксплуатации
алгоритмов является неудовлетворительной. Она требует неоп-
равданно больших затрат труда и времени. Эти трудозатраты
настолько велики, что во много раз превышают реальные резер-
вы времени, которыми располагают люди.
Алгоритмическая неосведомленность специалистов-непрограм-
мистов объясняется тем, что в современных условиях изучение
алгоритмов и алгоритмизации является слишком сложным и даже
непосильным делом. Поэтому работа с алгоритмами для подавляю-
щего большинства профессионалов оказывается невозможной.
Это плохо. Алгоритмическая неграмотность многих умных людей
неблагоприятно отражается на развитии общества.
ЧТО ДОЛЖНО СТАТЬ
ЧАСТЬЮ ПРОФЕССИОНАЛЬНОЙ КУЛЬТУРЫ
СПЕЦИАЛИСТОВ-НЕПРОГРАММИСТОВ:
АЛГОРИТМИЗАЦИЯ ИЛИ ПРОГРАММИРОВАНИЕ?Наша позиция такова:
• Надо глубоко осознать разницу между понятиями «алго-
ритмизация» и «программирование».
• Массовое обучение программированию невозможно и
не нужно по двум причинам.
Во-первых, оно неимоверно трудно. Во-вторых, оно дает знания,
которые большинству просто не нужны.
• Массовое обучение алгоритмизации, наоборот, полезно
и необходимо.
• В обществе знаний во многих случаях возникает острая
необходимость формализовать собственные процедурные профес-
сиональные знания специалистов.
__________________________________________________________
Умение формализовать собственные процедурные знания специа-
листов-непрограммистов, а также умение разрабатывать и изобра-
жать алгоритмы в своей предметной области должно стать частью
их профессиональной культуры.
___________________________________________________________
ТРАДИЦИОННЫЙ АЛГОРИТМИЧЕСКИЙ ЯЗЫК
И ЯЗЫК ДРАКОНПод традиционным алгоритмическим языком мы понимаем все
традиционные средства, предназначенные для записи алгорит-
мов (но не программ). Сюда относятся: псевдокод, блок-схемы
алгоритмов, диаграммы Насси-Шнейдермана и др.
Под «Проектом преобразования алгоритмического языка» пони-
мается добровольный отказ учителей, преподавателей и специа-
листов от традиционного алгоритмического языка и постепенный
переход к широкомасштабному (или даже повсеместному) исполь-
зованию языка Дракон.
Алгоритмический язык Дракон содержит две части: формальную
и неформальную. Первая является математически строгой. Вто-
рую пишут на естественном языке.
В отличие от традиционных средств для описания алгоритмов
(псевдокода, блок-схем и др.) визуальный синтаксис язык Дракон
опирается на безупречную математику и серьезные эргономиче-
ские проработки.
По этой причине язык Дракон претендует на то, чтобы стать меж-
дународным стандартом, принятым в соответствии с процедурами
Международной организации по стандартизации (International Stan-
dard Organization).
ЗАКЛЮЧИТЕЛЬНЫЕ ЗАМЕЧАНИЯ
ПО «ПРОЕКТУ ПРЕОБРАЗОВАНИЯ
АЛГОРИТМИЧЕСКОГО ЯЗЫКА»Ниже указаны наиболее важные свойства и особенности алгорит-
мического языка Дракон. Он позволяет:
• изображать линейные, разветвленные и цикличные
алгоритмы с расширенным ассортиментом циклов по сравнению
с традиционным.
• изображать вложенные, последовательные и парал-
лельные алгоритмы.
• изображать логические элементы И, ИЛИ, НЕ и слож-
ные логические функции;
• преобразовывать логические элементы и сложные
логические функции из текстовой формы в визуальную и обратно;
• использовать эквивалентные преобразования алгорит-
мов (рокировка, вертикальное объединение, горизонтальное объе-
динение) для улучшения эргономических характеристик алгорит-
мов;
• изображать базовые управляющие структуры визуаль-
ного структурного программирования;
• строить алгоритмы из базовых управляющих структур;
• изображать алгоритмы реального времени с использо-
ванием элементов управления временем: пауза, период, пуск тай-
мера, синхронизатор по таймеру, параллельный процесс;
Концепция языка Дракон опирается на так называемый шампур-
метод. Напомним его основные черты:
• Необходимо отказаться от текстовой формы управля-
ющих конструкций, преобразовав их в визуальную форму сог-
ласно правилам визуального структурного программирования
(см. главу 22);
• Необходимо отказаться от текстовых управляющих
операторов (например, if—then—else, while—do и т.д.), заменив
их управляющей графикой.
• В шампур-методе при разработке алгоритмов активно
используется операция вложения (ввод атома, ввод ветки), а так-
же пересадка лианы и заземление лианы.
• Графическое представление управляющих конструкций
не изоморфно текстовым конструкциям. Оно принципиально отли-
чается от традиционных управляющих ключевых слов.
• При переходе от псевдокода и блок-схем к дракон-схе-
мам привычный способ мышления пользователя при разработке
алгоритмов существенно меняется и становится более легким.
Производительность труда повышается.
• Необходимо (в пределах возможного) исключить слож
ые термины «истина» и «ложь», характерные для текста. И заме-
нить их удобными словами «да» и «нет», пригодными для графи-
ческих чертежей. Такая замена упрощает визуальные логические
рассуждения, делая их более легкими.
• Предусмотрены и другие эргономичные приемы (шап-
ка, правило «чем правее — тем хуже») и многое другое. Когни-
тивно-эргономические методы делают дракон-схему более понят-
ной и более качественной.
На этом мы заканчиваем рассмотрение Проекта преобразования
алгоритмического языка.
ПРОЕКТ ПРЕОБРАЗОВАНИЯ ЯЗЫКОВ ПРОГРАММИРОВАНИЯВыше мы рассмотрели Проект преобразования алгоритмического
языка.
Возможен ли аналогичный проект для программирования?
Можно ли говорить о Проекте (хотя бы частичного) преобразова-
ния языков программирования?
Это сложный вопрос. И у нас нет готового ответа.
Тем не менее, попытаемся в порядке предварительного обсуж-
дения сделать первый скромный шаг в этом направлении.
ОТКАЗ ОТ ТЕКСТОВЫХ УПРАВЛЯЮЩИХ КОНСТРУКЦИЙ
В ПОЛЬЗУ УПРАВЛЯЮЩЕЙ ГРАФИКИТекстовое и визуальное программирование опираются на раз-
ные системы понятий, которые по-разному расчленяют дейст-
вительность.
Поэтому визуальное программирование нельзя рассматривать
как результат механического переноса классических понятий
структурного программирования на новый язык.
При визуальном структурном программировании программист
работает только с чертежом программы, не обращаясь к ее тексту.
Точно так же программист, работающий, скажем, на Дельфи, не
обращается к ассемблеру и машинному коду — они для него
просто не существуют.
Это значит, что столь тщательно обоснованная Дейкстрой и его
последователями коллекция ключевых слов, описывающих развил-
ки и циклы, при переходе к визуальному программированию стано-
вится ненужной. Для программиста она просто перестает существо-
вать!
Поскольку в визуальном варианте структурного программирования
ключевое слово goto не используется, теряют смысл и все споры
относительно законности или незаконности, опасности или безопас-
ности его применения.
Становится ненужной обширная литература, посвященная обсуж-
дению этого, некогда казавшегося столь актуальным вопроса.
Визуальные программы, будучи «выполнимой графикой», строят-
ся из «выполняемых» икон и «выполняемых» соединительных ли-
ний.
При построении программ с помощью дракон-редактора пользова-
тель не применяет понятия if-then-else, goto и т.д., ибо в этом нет
никакой необходимости.
Нельзя путать задачу и систему понятий, на которую опирается
метод ее решения. В обоих случаях — и при текстовом, и при
визуальном структурном программировании — ставится одна и
та же задача: улучшить понятность программ и обеспечить бо-
лее эффективный интеллектуальный контроль за передачами
управления.
Однако система понятий коренным образом меняется. Ту функ-
цию, которую в текстовой программе выполняют ключевые слова,
в визуальной программе реализуют совершенно другие понятия:
иконы, макроиконы, соединительные линии, шампур, главная вер-
тикаль шампур-блока, лиана, атом, пересадка лианы, запрет пере-
сечения линий и т. д.
При переходе к визуальному программированию задача решается
по-другому, с помощью другого набора понятий. Отказ от старого
набора понятий и замена его на новый позволяет добиться новой
постановки задачи и более эффективного ее решения.
Повторим важную мысль. В языке программирования Дракон текс-
товые управляющие конструкции (развилки и циклы и др.) полно-
стью устранены. Им на смену пришла значительно более легкая
и удобная управляющая графика.
ТРИ ЧАСТИ ЯЗЫКА ПРОГРАММИРОВАНИЯВ общем виде почти любой язык программирования можно раз-
делить на три части:
• маршрутную;
• командную;
• декларативную.
Маршрутная часть языка программирования описывает марш-
рут движения рабочей точки от начала до конца программы и
содержит элементы, организующие линейные, разветвленные,
цикличные, вложенные и параллельные участки маршрутов,
а также элементы реального времени, организующие работу
в реальном времени.
Маршрутная часть строится из управляющих конструкций.
Пример управляющей конструкции: if—then—else, while—do
и т.д.
В маршрутную часть мы включаем также все элементы алго-
ритмического языка Дракон, описанные в этой книге и кратко
подытоженные в этой главе в параграфе «Заключительные
замечания по Проекту преобразования алгоритмического язы-
ка»
Командная часть языка программирования описывает после-
довательность команд. Пример команды: a:=b+c.
Декларативная часть языка программирования содержит опи-
сания данных, классов и т.д.
В центр нашего анализа поместим маршрутную часть языка.
По-нашему мнению, маршрутная часть языков программиро-
вания — это отдельная, самостоятельная и очень важная про-
блема.
Думается, в языке Дракон эта проблема решена лучше, чем
во многих других языках.
Некоторые специалисты утверждают, что управляющая графика
языка ДРАКОН является мощным инструментом, причем ее мощь
легка в освоении и легко применима на практике.
Возникает вопрос. Можно ли задел, разработанный в языке Дракон
и хорошо себя зарекомендовавший, использовать в качестве част-
ного элемента для «Проекта преобразования языков программиро-
вания»?
Или такой подход следует признать спорным или даже ошибочным?
Ниже мы будем иметь в виду такие языки, как например, Ява, Си#,
Питон, Перл, Руби, Ада, Оберон и др.
КРИТИКА ЯЗЫКОВ ПРОГРАММИРОВАНИЯПопытаемся вынести на суд читателей несколько, возможно, оши-
бочных предположений.
• В языках программирования имеется слабое звено. Это
касается не всех языков, но многих.
• Слабым звеном языков является маршрутная часть, опи-
санная в предыдущем параграфе, в том числе, текстовые управля-
ющие конструкции, служащие для организации разветвленных, цик-
личных, вложенных и параллельных процессов (участков маршрутов),
а также элементы реального времени, организующие работу в реаль-
ном времени.
• Чтобы устранить слабое звено, необходимо отказаться
от использования текстовых управляющих конструкций, заменив
их управляющей графикой.
• В качестве управляющей графики предлагаются структур-
ные, математически строгие блок-схемы — дракон-схемы.
• Дракон-схемы позволяют устранить слабое звено языков
программирования и за счет этого повысить производительность тру-
да.
ГИПОТЕТИЧЕСКИЙ ПЛАН
ПРЕОБРАЗОВАНИЯ ЯЗЫКОВРискуя ошибиться, можно предложить план преобразования язы-
ков программирования.
Исходная посылка. Почти каждый язык программирования име-
ет слабое звено, которое вносит в работу с языком значительные не-
удобства.
Этим слабым местом являются текстовые управляющие конструкции,
организующие маршрутную часть языка.
Языки, подлежащие изменению, назовем кандидатами. Выберем в
качестве кандидатов, например, 10 языков программирования (цифра
совершенно условная).
С каждым из кандидатов выполняем следующие действия.
1. Проверяем языки-кандидаты, и убеждаемся, что наме-
чаемые преобразования действительно улучшают качества языка
(делают его более выразительным, более понятным и удобным для
работы).
2. Преобразуем маршрутную часть языка-кандидата (то есть,
превращаем текстовые управляющие конструкции в управляющую
графику). Маршрутную часть желательно делать универсальной для
всех языков-кандидатов.
3. Командную и декларативную часть языка-кандидата остав-
ляем без изменения. (Имеется в виду, что команды записываются вну-
три икон дракон-схемы, а декларации — вне икон или даже вне схемы).
Перечисленные три пункта и составляют «Проект преобразования язы-
ков программирования».
Какой эффект будет получен в результате реализации проекта? Пред-
положительно, повышение производительности труда, уменьшение
числа ошибок и т.д.
ВЫВОДЫ1. Существует возможность во многих или даже в большин-
стве случаев полностью отказаться от традиционных способов пред-
ставления алгоритмов и безболезненно заменить их на язык Дракон
2. Для обозначения отказа от традиционных способов в поль-
зу языка Дракон используется термин «Проект преобразования алго-
ритмического языка».
3. Реализация Проекта будет происходить естественным путем,
по мере распространения сведений о языке Дракон в результате добро-
вольного решения людей, проявляющих интерес к данной теме.
4. Особую роль играет добровольная инициатива учителей
школ и преподавателей университетов, которые пожелают ввести в
программу обучения информацию о языке Дракон.
5. Большое значение имеют усилия инициативных групп и
отдельных специалистов, которые будут создавать все более совер-
шенные дракон-редакторы и другие средства. Это позволит закре-
пить навыки алгоритмизации на практике, приблизить их к жизни.
6. Конечный результат Проекта подразумевает широкое рас-
пространение алгоритмического мышления и преодоление ныне суще-
ствующей массовой алгоритмической неграмотности.
7. Большинство программистов недооценивает важность проб-
лемы, связанной с умением создавать сложные алгоритмы, пригодные
для быстрого понимания ЧЕЛОВЕКОМ.
8. Блок-схемы алгоритмов, псевдокод и другие традиционные
средства не позволяют преодолеть нынешнюю массовую алгоритми-
ческую неграмотность.
9. Нынешние алгоритмы, используемые во всем мире, имеют
серьезный дефект. Они чрезвычайно трудны для понимания.
10. Алгоритмическая неосведомленность специалистов-непрог-
раммистов объясняется тем, что в современных условиях изучение
алгоритмов и алгоритмизации является слишком сложным и даже не-
посильным делом. Поэтому работа с алгоритмами для подавляющего
большинства профессионалов оказывается невозможной.
11. Алгоритмическая неграмотность многих умных людей не-
благоприятно отражается на развитии общества.
12. Язык Дракон позволяет устранить недостаток. Умение фор-
мализовать собственные процедурные знания специалистов-непрограм-
мистов, а также умение разрабатывать и изображать алгоритмы в сво-
ей предметной области должно стать частью их профессиональной
культуры.
13. В отличие от традиционных средств для описания алгорит-
мов (псевдокода, блок-схем и др.) визуальный синтаксис язык Дракон
опирается на безупречную математику и серьезные эргономические
проработки. По этой причине язык Дракон претендует на то, чтобы со
временем стать международным стандартом, принятым в соответ-
ствии с процедурами Международной организации по стандартиза-
ции (International Standard Organization).
14. Проект преобразования алгоритмического языка позволяет
создать задел для Проекта частичного преобразования языков прог-
раммирования.
15. В языке программирования Дракон текстовые управляю-
щие конструкции (развилки и циклы и др.) полностью устранены.
Им на смену пришла значительно более легкая и удобная управля-
ющая графика.
16. Большинство языков программирования можно разделить
на три части: маршрутную, командную и декларативную.
17. Маршрутная часть языка программирования описывает
маршрут движения рабочей точки от начала до конца программы и
содержит элементы, организующие линейные, разветвленные, цик-
личные, вложенные и параллельные участки маршрутов, а также эле-
менты реального времени, организующие работу в реальном времени.
Маршрутная часть строится из управляющих конструкций.
18. В языках программирования имеется слабое звено. Это ка-
сается не всех языков, но многих.
19. Слабым местом языков является маршрутная часть.
20. Чтобы устранить слабое звено, необходимо отказаться -
от использования текстовых управляющих конструкций, заменив
их управляющей графикой.
21. Проект преобразования языков программирования вкратце
сводится к следующему:
Преобразуем маршрутную часть языка-кандидата,
превращая текстовые управляющие конструкции в управляю-
щую графику.
Командную и декларативную часть языка-кандидата оставляем
без изменения.
22. В качестве управляющей графики предлагаются структур-
ные, математически строгие блок-схемы — дракон-схемы.
23. Предполагается, что Дракон-схемы позволят устра-
нить слабое звено языков программирования и за счет этого по-
высить производительность труда.
ЛИТЕРАТУРА1. Зенкин А. А. Когнитивная компьютерная графика. М.: Наука, 1991.
С. 19.
2. Саркисян А.А. Повышение качества программ на основе автомати-
зиро-ванных методов. М.: Радио и связь, 1991. С. 120—131.
3. ISO 5807—85. Unified System for Program Documentation. Data,
program and system flowcharts, program network charts and system re-
sources charts. Documentation symbols and conventions for flowcharting.
4. Гост 19.701—90. Единая система программной документации.
Схемы алгоритмов, программ, данных и систем. Условные обозначения
и пра-вила выполнения.
5. Robertson L.A. Simple Programm Design. A Step-by-step Appro-
ach. Fourth edition. Thomson, Australia, Canada, Mexico…, 2004.
Русский перевод: Робертсон Л.А. Программирование — это просто.
Пошаговый подход. Перевод с 4-го английского издания. М.: Бином
Лаборатория знаний, 2008.
6. Практическое руководство для врачей общей (семейной)
практики. Под редакцией академика РАМН И.Н. Денисова. М.: ГЭОТАР-
МЕД, 2001. — 720с.