Умеет ли человечество писать алгоритмы? Безошибочные алгоритмы и язык ДРАКОН

Содержание

Введение
1.
Трагедия Боинга 737 МАХ
2.
Безошибочность алгоритмов
3.
Язык ДРАКОН
4.
Визуальное структурное программирование
5.
Аксиоматический метод
6.
ДРАКОН-конструктор
7.
Алгоритмическая логика
8.
Доказательство правильности
9.
Семейство ДРАКОН-языков
10.
Автоматное программирование
11.
Учебное пособие по языку ДРАКОН для вузов
12.
Недостатки языка ДРАКОН
13.
В чем сила языка ДРАКОН
14.
На руках разработчиков алгоритмов кровь сотен людей
15.
Литература

Аннотация. О чем пойдет речь?

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

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

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

Телестудия Роскосмоса.
Кадр из фильма «Жирограф и ДРАКОН Пилюгина».

.

Сколько стоят ошибки в алгоритмах

Умеют ли люди писать алгоритмы? В корпорации Боинг трудятся умные люди высочайшей квалификации. Они, несомненно, умеют писать алгоритмы.
Но с ошибками.
Сколько стоят ошибки? Немало. Фирма Boeing согласилась выплатить 2,5 миллиарда долларов, чтобы избавиться от суда об утаивании проблем с самолетом Боинг 737 MАХ от авиационного регулятора FAA.

И всего-навсего 500 миллионов долларов (из этих денег) достанутся семьям погибших в авиакатастрофах компаний Ethiopian Airlines и Lion Air.

Цель — безошибочность

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

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

Новая нотация

Актуальная задача — предложить новую нотацию и показать, что она содействует безошибочности. Этого мало. В новую нотацию нужно встроить незаметный для пользователей математический аппарат, предотвращающий ошибки.

Чтобы подчеркнуть важность понятия «безошибочный алгоритм», полезно проанализировать инцидент с самолетом Боинг 737 МАХ, алгоритмы которого оказались ошибочными и привели к катастрофе.

Макроалгоритмы

Макроалгоритмы — это алгоритмы в широком смысле. Макроалгоритмы делятся на компьютерные алгоритмы (которые выполняются компьютерами) и жизнеритмы, выполняемые людьми.

Макроалгоритм большой человеко-машинной системы содержит взаимоувязанные и согласованные между собой алгоритмы и жизнеритмы.
Примером большой человеко-машинной системы служит фирма Боинг, огромная фирма, на которой трудятся 150 000 человек. Это люди высочайшей квалификации, обладающие огромными знаниями. Что же их подвело?

Что случилось с лайнером Боинг 737 MAX

Сайт корпорации Боинг

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

Трагедия повторилось дважды: 29 октября 2018 года в Индонезии и спустя полгода, 10 марта в Эфиопии. Погибли 346 человек: все пассажиры и оба экипажа. Выживших не было.

В тисках конкуренции

Знаменитая американская корпорация Боинг была озабочена конкуренцией с мощной европейской фирмой Эйрбас. Соперничество двух авиагигантов всегда было напряженным. Самолеты Боинг 737 и европейский А320 стали рабочими лошадками мира пассажирских перевозок.

Они тысячами летали на маршрутах короткой и средней дальности по всей планете. Их продажи были для обоих концернов надежным источником дохода. Рынок был поделен примерно поровну. Но обновленный лайнер А320 грозил нарушить равновесие и вывести Эйрбас далеко вперед.

Новые А320 обещали быть существенно дешевле в эксплуатации. В последние годы расходы на топливо составляли почти 25% операционных расходов авиакомпаний. Эйрбас обещал, что новые самолеты будут на 15% экономичнее прежних.

Новые двигатели на лайнере Боинг 737 MAX

Заказы на новый самолет, названный A320neo, посыпались на европейский концерн. Спрос на лайнер 737 между тем заметно снизился. Боинг не мог оставить это без ответа.
Современные двигатели гораздо тише и экономичнее своих предшественников, но по технологическим причинам они гораздо больше в диаметре.

Боинг собирался установить на самолетах 737 МАХ наиболее экономичные двигатели LEAP производства фирмы CFM. Но Эйрбас его опередил.

Коммерческое самоубийство

Как только было объявлено, что Эйрбас будет использовать более бережливые двигатели на новом самолете А320, у Боинга не осталось выхода. Поступить иначе означало совершить коммерческое самоубийство.

И работа закипела! Однако под низко расположенное крыло лайнера 737 новый двигатель не влезал. Его пришлось выдвинуть на пилоне вперед и вверх. Это решило одну проблему, но создало другую.

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

Слишком большой угол атаки

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

Опытные пилоты-испытатели обнаружили, что новый самолет 737 МАХ управляется совсем не так, как предыдущие поколения 737-й модели. Значит, прежние навыки пилотирования здесь не годятся.

Что делать? Создавать учебный тренажер-симулятор нового лайнера и переучивать сотни пилотов? Но ведь это лишнее время и огромные расходы.

Зачем понадобилась система MCAS

Творческая мысль на выдумки хитра. Находчивые инженеры Боинга придумали палочку-выручалочку под названием «Улучшение характеристик системы маневрирования» — Maneuvering Characteristics Augmentation System (MCAS). Она должна была убрать головную боль и сделать лайнер 737 МАХ похожим в управлении на предыдущие самолеты.

Заодно программа MCAS устраняла недочеты в аэродинамике. Она автоматически предотвращала свойственные лайнеру 737 МАХ попытки самостоятельно задрать нос, когда угол атаки чрезмерно велик. Тем самым устраняется опасность сваливания, вызванная задранным носом.

Гладко было на бумаге, да забыли про овраги

При этом разработчики подчеркивают, что система MCAS не является системой предотвращения сваливания, а нужна для того, чтобы «улучшить горизонтальную стабильность самолета, чтобы он походил в управлении на остальные лайнеры 737-й модели».

Хотя между предыдущим поколением и лайнером 737 МАХ есть значительные отличия, но — благодаря замечательной системе MCAS — пилоты, летавшие на старых Боингах, могли чувствовать себя уверенно. От них требовалось совсем немного: пройти короткий онлайн-курс обучения на флешке — и можно спокойно сесть за штурвал нового самолета.

Так было задумано и допущено к полетам. Но, как говорится, гладко было на бумаге.

— Отличный мозг! Но в чем  дело? Почему люди не умеют писать безошибочные алгоритмы?

.

Что получилось на самом деле

В кабине раздавались новые сигналы тревоги. Командир безуспешно пытался восстановить контроль над самолетом. Надо срочно набирать высоту! Но как?
Когда капитан Яред Гетачу пытался поднять нос Боинга, электронные системы опускали его обратно.

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

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

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

Игра со смертью в кабине Боинга

Пилоты снова включили электронику, и капитан вновь попытался поднять нос Боинга с помощью переключателя на штурвале. На какое-то время это помогло: самолет вновь начал набирать высоту.

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

Но и эта последняя попытка не удалась. Самолет продолжал набирать скорость, пикируя все круче, пока не врезался в землю на скорости более 800 километров в час. Всего через шесть минут после взлета.

На те же грабли

Пятью месяцами ранее такой же Боинг 737 MAX индонезийской компании Lion Air вылетел обычным рейсом из Джакарты. Полет в город на западе Индонезии должен был занять около часа. Но спустя несколько минут после взлета пилоты оказались в похожей ситуации.

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

Проблемы с управлением летающего дьявола

Это произошло более 20 раз подряд. На земле диспетчеры забеспокоились, глядя на экраны радаров — Боинг явно терял высоту. Один из пилотов сообщил, что у них возникли проблемы с управлением.

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

В конце концов, они полностью потеряли контроль над самолетом. Он вошел в крутое пике и на большой скорости врезался в воды Яванского моря.

Серьезный просчет руководства фирмы Боинг и FAA в области безопасности полетов

Потеря двух новых самолетов, трагическая гибель свыше 300 человек, запрет на продолжение полетов и отказ ряда авиакомпаний от закупок новых самолетов 737 МАХ явились тяжелым ударом для Боинга.

 Одновременно это выявило упущения в работе Федеральной авиационной администрации США — Federal Aviation Administration (FAA), которая отвечает за безопасность и сертификацию самолетов и летчиков.

Почему вопиющие ошибки в области безопасности самолетов и подготовки пилотов остались незамеченными? Было начато расследование в конгрессе США, ФБР и других инстанциях.

Сенатор Блюменталь: «Они находились в летающих гробах»

На слушаниях в конгрессе расчеты фирмы Боинг и ее руководителя Денниса Мюленбурга подверглись яростной критике.

Сенатор Ричард Блюменталь заявил:
«У этих пилотов не было шансов. У этих кем-то любимых людей не было шансов. Они находились в летающих гробах».

Здесь я должен прервать рассказ и вернуться к теме.
Нас интересует проблема алгоритмов. Какую роль сыграли алгоритмы в трагедии лайнера 737 МAX?
Причина авиационного инцидента связана с низким качеством и неполнотой алгоритмов и жизнеритмов.

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

Применительно к лайнеру 737 МАХ слово «жизнеритм» можно трактовать как бизнес-процесс. Имеются в виду бизнес-процессы в широком смысле слова, описывающие функционирование не только коммерческих фирм, но и государственных учреждений (FAA), а также взаимодействие между ними.

При традиционном подходе алгоритмическая часть бизнес-процесса зачастую описывается не строго и эргономически не удовлетворительно.
В случае с лайнером 737 МАХ анализ алгоритмов и жизнеритмов не позволил выявить погрешности проектирования и своевременно устранить их. Не позволил предотвратить беду и спасти людей.

Алгоритмы и жизнеритмы

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

Иными словами, все алгоритмические подробности и оттенки алгоритмов и жизнеритмов должны быть тщательно проработаны и аккуратно изложены. Потому что от точности и эргономичности описаний и моделей может зависеть жизнь людей.

Кризис самолета 737 МАХ или кризис понятия «алгоритм»

Алгоритмы находятся внутри компьютеров и выполняются автоматически. Жизнеритмы описывают поведение людей в разнообразных бизнес-процессах. Нужно иметь и то, и другое. Необходимо тщательно сопрягать алгоритмы и жизнеритмы.
При создании и эксплуатации самолета 737 МАХ понятие «жизнеритмы» охватывает следующую группу процессов:

— внутренние бизнес-процессы фирмы Боинг, описывающие взаимодействие работников различных отделов и подразделений фирмы друг с другом;

— бизнес-процессы, регламентирующие взаимодействие сотрудников фирмы Боинг и Федеральной авиационной администрации FAA;

— бизнес-процессы, описывающие взаимодействие сотрудников Боинга с авиакомпаниями и другими контрагентами;

— бизнес-процессы, регламентирующие обучение и сертификацию пилотов самолета 737 МАХ, в том числе, в критических и нештатных ситуациях полета.

Жесткое требование

Анализ алгоритмов и жизнеритмов должен показывать реальное состояние дел и демонстрировать упущения, ошибки и слабые места.

Это очень жесткое требование. Двойная авария лайнера 737 МАХ показала, что данное требование не выполняется. Алгоритмы и жизнеритмы не позволили заблаговременно выявить и устранить недостатки, допущенные при разработке и эксплуатации самолета 737 МАХ.
Почему? Может быть, понятие алгоритма нуждается в уточнении?

Анализ понятия «алгоритм»

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

Актуальной задачей является уточнение понятия «алгоритм» исходя из требования безошибочности. Это требование относится не только к одиночным алгоритмам, но и к алгоритмическим системам, содержащим сотни и тысячи взаимодействующих алгоритмов.

Входит ли нотация в понятие алгоритма

Алгоритм — сложное понятие, в котором можно выделить:
— определение алгоритма (интуитивное и формальное);
— свойства алгоритма;
— нотации, т. е. способы записи алгоритма.

До сих пор свойства и нотации алгоритма рассматривались и изучались в отрыве от потребностей практики, которая заинтересована в сокращении числа ошибок. Это имело негативные последствия.

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

Комплексная программа уменьшения числа ошибок

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

«Нет-нет-нет, мы хотим сегодня! Нет-нет-нет, мы хотим сейчас!». Я понимаю, но статья имеет пределы.

Свойства и нотация безошибочных алгоритмов

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

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

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

Понятность и понимаемость безошибочного алгоритма

Следует различать два свойства алгоритма: понятность и понимаемость. Свойство «понятность» говорит о том, что алгоритм должен быть понятен компьютеру, т. е. состоять из инструкций, входящих в его систему команд. Это разумное и очевидное свойство алгоритма.

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

Такая проверка может проводиться в любое время в процессе жизненного цикла алгоритма. Проверку могут проводить разные люди: автор алгоритма, его руководитель, заказчик, специалисты по сопровождению (эксплуатации) алгоритма и др.

Понимаемость (understandability) алгоритма для человека (в отличие от понятности для компьютера) означает удобочитаемость, то есть ясность, доходчивость, пригодность алгоритма для быстрого и легкого понимания и выявления ошибок.

Зачем нужна понимаемость

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

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

Если бы алгоритмы и жизнеритмы (бизнес-процессы) фирмы Боинг и FAA обладали надлежащим качеством и свойством «понимаемость», то ошибки, упущения и слабые места в самолете 737 МАХ были бы своевременно выявлены и устранены, катастрофа не произошла бы, а пассажиры и экипажи остались бы живы.

Задачи становятся все сложнее.
Их все труднее понять. Понимание — это труд. Производительность этого труда недопустимо мала.
Необходимы новые: когитивнно-эргономические и формальные методы, чтобы облегчить понимание.

.

Дискуссия о понимании алгоритмов

— Можно ли читать алгоритмы, как увлекательную повесть, быстро и с удовольствием?
— Нет, нельзя.
— Как сделать алгоритмы легкими и удобными для изучения?
— Увы, это невозможно.
— Почему?
— Потому что алгоритмы очень трудны и предназначены для вдумчивого, серьезного, медленного чтения, обеспечивающего глубокое понимание.
— Все это так, но жизнь идет вперед и ставит новые задачи. То, что вчера было невозможно, завтра станет возможным. Жизнь требует, чтобы сложные алгоритмы стали удобными для людей — дружелюбными, понятными, доходчивыми (people-friendly, user-friendly). Алгоритмы должны быть легкими для быстрого восприятия и усвоения, пригодными для быстрого выявления ошибок.

Почему алгоритмы трудны для понимания

Низкая понимаемость алгоритмов и программ — важный недостаток современного программирования.
Джозеф Фокс, руководитель отделения федеральных систем IBM, у которого в подчинении было 4400 человек, объясняет, в чем дело:

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

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

Разве можно с этим мириться?

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

Чтобы прочитать всего четыре страницы и докопаться до истины, превосходному программисту пришлось изрядно помучиться. И потратить три или четыре дня.

Отсюда следует неутешительный вывод.
Глядя на исходный текст программы, понять сложный алгоритм очень трудно. А быстро понять — невозможно.
Разве это хорошо? Разве можно с этим мириться?

Метод проб и ошибок: чему учит история авиации

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

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

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

Нотация безошибочного алгоритма

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

При обычном подходе к выбору нотации требование об отсутствии ошибок не ставится и не рассматривается. Такой подход уязвим для критики, ибо позволяет использовать для записи алгоритмов любую подходящую нотацию, например:
— естественный язык (включая словесно-формульную запись);
— псевдокод;
— язык программирования;
— блок-схему согласно ГОСТ 19.701-90 (ISO 5807-85);
— схему деятельности (activity diagram) языка UML;
— диаграмму Несси-Шнейдермана и т. д.

Все нотации не годятся

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

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

— Что делает этот чудак?
— Изобретает новую нотацию.

.

Когнитивно-эргономический подход

Цель — облегчить и ускорить понимание алгоритмов и выявление ошибок.
Для этого необходимо устранить или ослабить когнитивные затруднения, то-есть трудности понимания алгоритмов.

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

Можно ли создать алгоритмический язык, способный предотвращать ошибки

Показано, что заданным требованиям удовлетворяет визуальный алгоритмический язык ДРАКОН.
На Хабре: Визуальное программирование на языке ДРАКОН.
В Википедии: ДРАКОН.
In Wikipedia: DRAKON.
Книга: Алгоритмы и жизнеритмы на языке ДРАКОН. Разработка алгоритмов. Безошибочные алгоритмы.

Как и все прочие языки, ДРАКОН опирается на математику и логику. Однако сверх того, он самым тщательным образом учитывает когнитивные вопросы. Благодаря систематическому использованию когнитивно-эргономических методов ДРАКОН приобрел уникальные эргономические характеристики.

В будущем он сможет претендовать на звание чемпиона по критерию «понимаемость алгоритмов и программ» (в классе императивных языков).

Язык ДРАКОН. Алгоритмическая макроконструкция «силуэт»

Рис. 1. Алгоритм «Проверка летающей тарелки»

Язык ДРАКОН. Алгоритмическая макроконструкция «примитив»

Рис. 2. Плохой дракон-алгоритм.
а) Нарушено правило «Чем правее, тем хуже».
б) Нарушенр правило: «Главный маршрут должен идти по шампуру».

Главный маршрут (жирная линия) все время петляет и делает зигзаги.
Его трудно проследить взглядом.

Главный маршрут — это царская дорога (happy path). Это наиболее благоприятный маршрут алгоритма.

.

Рис. 3. Хороший дракон-алгоритм.
Он получен в результате улучшения схемы на рис. 2 с помощью операции «рокировка».
а) Выполняется правило «Чем правее, тем хуже».
б) Главный маршрут прямой как стрела. Он идет по шампуру.

.

Предшественники: Эдсгер Дейкстра, Бертран Мейер, Игорь Вельбицкий

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

Начнем с истории. В 1968 году Эдсгер Дейкстра в журнале «Communications of the ACM» указал, что оператор goto, используемый во многих языках программирования высокого уровня, является основным источником ошибок и потому должен быть запрещен.

Затем Бертран Мейер выявил еще два опасных элемента — операторы break и continue, который также следует запретить как замаскированные goto. По словам Мейера, это те же старые «goto в овечьей шкуре».
Еще дальше идет Игорь Вельбицкий, который считает, что из программирования следует исключить:

«ключевые слова-паразиты и соответствующие им конструкции языков типа: goto, if, for, while, break, begin-end, {-} и т. д… Эти конструкции являются основным источником ошибок и проблем в современном программировании».

Язык ДРАКОН продолжает и развивает традицию, начатую Дейкстрой и продолженную Вельбицким и Мейером. Традицию, направленную на выявление и изгнание потенциально опасных операторов управления, которые могут послужить причиной ошибок.

В чем идея

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

Визуальное (двумерное) структурное программирование

Приведем список исключенных из языка ДРАКОН опасных элементов, обеспечивающих управление вычислительным процессом. Сюда относятся:
— служебные слова goto, break, continue, if, then, else, case, of, switch, while, do, repeat, until, for, foreach, loop, exit, when, last и их аналоги;
— логические скобки begin end, { };
знаки пунктуации: круглые скобки, квадратные скобки, косые скобки, двоеточие, точка с запятой.

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

Замена текстовых операторов на их точные графические эквиваленты означает, что язык ДРАКОН использует двумерное (2d) структурное программирование. Последнее можно рассматривать как дальнейшее развитие одномерного (1d) структурного программирования, которое создали Эдсгер Дейкстра, Тони Хоар, Оле-Йохан Дал и др.

«Чем вам ключевые слова, логические скобки и знаки пунктуации помешали?»

Правило Эшфорда гласит:
«Бесполезно стремиться направить внимание на важнейшие характеристики, если они окружены лишними, не относящимися к ним визуальными раздражителями, мешающими восприятию главного».

Опасный катализатор ошибок

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

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

Человек рисует графические операторы управления (дракон-схемы похожи на блок-схемы) и работает с ними.

Какова цель

Цель заключается в том, чтобы улучшить способность языков проектирования и программирования предупреждать появление ошибок.

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

Сравнение текста и графики для оператора while

Слева имеются паразитные элементы (while и две скобки). Справа их нет

Рис. 4. Оператор while можно удалить и заменить на управляющую графику языка ДРАКОН

В си-программе на рис. 4 имеются избыточные элементы, которые можно изъять с целью улучшения исходного кода программы. Вот они:
— while;
— две круглые скобки;
— две фигурные скобки.

Си-оператор на рис. 4 слева содержит загромождающие паразитные элементы, отсутствующие в дракон-операторе справа. Следствием является неоправданное усложнение си-оператора, которое засоряет программу и отвлекает внимание программиста.

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

Катализатор ошибок. Анализ операторов switch, case, break

Рис. 5. Оператор switch, case, break можно удалить и заменить на управляющую графику ДРАКОНа

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

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

С точки зрения языка ДРАКОН, дело обстоит принципиально по-другому. То, что важно и необходимо для Си, язык ДРАКОН рассматривает как лексический и синтаксический мусор, как слова-пустышки и знаки-паразиты, как бессмысленные, ненужные и вредные элементы, которые подлежат изъятию и удалению. Потому что они являются катализаторами ошибок.

Расчет

Приведем количественный расчет. В си-программе на рис. 5 использовано 55 символов (characters) без пробелов, а в дракон-программе всего 19, т. е. в 2,9 раза меньше. Благодаря графике дракон-программа легче для восприятия, в ней проще разобраться и заметить ошибку.

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

Мышление пора менять

ДРАКОН должен удовлетворять требованию безошибочности алгоритмов. Такое требование предъявляется к языку впервые. Оно символизирует принципиально новый подход к разработке алгоритмического языка.

Требование не выполняется, но стимулирует изменение мышления.
Впрочем, почему не выполняется? Вот народные отзывы из сети:

Участник vtral:
Язык Дракон — это способ визуального описания алгоритмов, исключающий ошибки.

Сергей Иголкин (Orthodox):
Дракон, на самом деле — чертовски хорош.
Не тем, что красивые диаграммки. Или охрененные разнообразные возможности (хотя хватает).
А тем, что главную свою цель обеспечивает — сложные алгоритмы писать и отлаживать без ошибок.

Индивидуальный предприниматель Сергей Ефанов:
Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.
Функция заработала сразу!
Более того, при переносе алгоритма в дракон-схему, я обнаружил, что у меня в ней была ошибка! Эта функция работала уже довольно давно, не в одной сотне изделий. Ошибка не была фатальной, она возникала редко, и компенсировалась переподключением к серверу. Но она была! 
В тексте на Си ее было незаметно. А при попытке перенести алгоритм на дракон-схему, ошибка стала не просто заметной — алгоритм в этом месте «не вырисовывался»!

Что значит «алгоритм не вырисовывался»?

Это значит, что ДРАКОН срывает с ошибки шапку-невидимку и делает ее видимой. Ошибка как бы выпрыгивает из чертежа, бьет разработчика кулаком в нос и громовым голосом кричит: «Вот она я! Заметь меня!».

Больше того, умная программа ДРАКОН-конструктор (интеллектуальный графический редактор) во многих случаях не дает человеку ошибиться. Физически не позволяет.

Каким образом? В программу заложены правила рисования дракон-алгоритмов (визуальное логическое исчисление), которые она строго соблюдает. Отступление от правил невозможно. Если человек попытается нарушить правила и совершить ошибку, ДРАКОН-конструктор откажется повиноваться и не станет рисовать глупости.
Именно это означает фраза Сергея Ефанова «алгоритм не вырисовывался».
Это пример того, как работает мантра безошибочности.

Дракон-схемы и блок-схемы

Чем отличаются дракон-схемы от блок-схем? Это все равно, что спросить: «Чем отличается человек от обезьяны».
Чтобы не тратить много слов, приведу два отзыва из сети.

Роман Озеров: «Я на ДРАКОНе работаю уже 6 лет. Любое создание программы начинаю с него и при отладке работаю только с ним.
Скорость разработки, качество возрастает в разы!
ДРАКОН это сила, но многие не догоняют, думают, что это обычная блок-схема».

Участник dvuugl: Если нужно рисовать алгоритм, теперь только и только на Драконе. Считаю, что он должен стать государственным стандартом для блок-схем вместо существующего.
Удивительно, что авторы книг продолжают использовать прежние схемы, на которые после Дракона без ужаса смотреть невозможно».

Специальный математический аппарат: визуальный аксиоматический метод (визуальная формальная система)

Мантра безошибочности включает специальный математический аппарат — логическое исчисление. Особенность в том, что это визуальное логическое исчисление.

В языке ДРАКОН есть две визуальных аксиомы:
— аксиома-силуэт,
— аксиома-примитив.

Рис. 6. Аксиома-силуэт и аксиома-примитив служат заготовками для построения силуэта и примитива соответственно.
Кружками показаны валентные точки.

.

Любой дракон-алгоритм силуэт (см. рис. 1) логически выводится из аксиомы-силуэт с помощью правил вывода (визуального логического вывода).

Любой дракон-алгоритм примитив (см. рис. 3) логически выводится из аксиомы-примитив точно так же — с помощью визуального логического вывода.

Что значит «выводится»? Это значит, что графика макроконструкций силуэт и примитив является визуальной теоремой. Доказанной теоремой. Ее не надо доказывать, так как она уже доказана в силу свойств логического исчисления.
Данное исчисление называется «исчислением икон».

Причем здесь аксиоматический метод?

Ответ под спойлером:

Spoiler

Ершов Ю.Л., Палютин Е.А. Математическая логика. —
М.: Наука, 1079. — 320 с. — С.12, 13.

Основным итогом деятельности в области оснований математики можно считать становление математической логики как самостоятельной математической дисциплины, а принципиальным достижением математической логики — разработку современного аксиоматического метода, который может быть охарактеризован следующими тремя чертами:

1.    Явная формулировка исходных положений (аксиом) той или иной теории.
2.    Явная формулировка логических средств (правил вывода), которые допускаются для последовательного построения (развертывания) этой теории.
3.    Использование искусственно построенных формальных языков для изложения всех положений (теорем) рассматриваемой теории…


Введение и использование подходящих обозначений было на протяжении всей истории математики весьма важной и продуктвной процедурой…


Основным объектом изучения в математической логике являются различные исчисления.

В понятие исчисления входят такие основные компоненты, как:
а) язык (формальный) исчисления;
б) аксиомы исчисления;
в) правила вывода…


Еще одним замечательным достижением математической логики является нахождение математического определения понятию алгоритма


Изучение исчислений составляет синтаксическую часть математической логики…


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

Валентные точки языка ДРАКОН

«Основной недостаток блок-схем заключается в том, что они не приучают к аккуратности при разработке алгоритма. Ромб можно поставить в любом месте блок-схемы, а от него повести выходы на какие угодно участки.
Так можно быстро превратить программу в запутанный лабиринт, разобраться в котором через некоторое время не сможет даже сам ее автор».

В языке ДРАКОН подобные чудеса невозможны, в частности, благодаря институту валентных точек. Последние служат для предотвращения ошибок.

Рис. 7. На анимации валентные точки показаны желтыми кружками.
Иконы и макроиконы можно вводить только в валентные точки и больше никуда.

Рис. 8. Размножение валентных точек при проектировании дракон-алгоритма

Формализация точек размещения икон

Валентные точки можно рассматривать как точки размещения икон, или точки ввода икон.

На каждом шаге построения алгоритма происходит размножение валентных точек. Процесс размножения показан на рис. 8.
В аксиоме-силуэт всего 3 валентных точки. После добавления конструкции «Ветка» будет уже 5 точек. А после вставки иконы Действие число точек увеличивается до 6 (рис. 8). Дальнейший процесс построения силуэта приводит к монотонному росту числа валентных точек.

Это значит, что иконы можно вставлять не куда угодно, а только в строго определенные места. Для каждой валентной точки определен список икон, которые разрешается вставить в данную конкретную точку.

Ввод иконы производится так. Сначала происходит разрыв соединительной линии в выбранной пользователем валентной точке. Затем в место разрыва вставляется икона.

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

Математический чертеж дракон-алгоритма

Математический чертеж алгоритма — это чертеж, для которого определены:
— формальное описание алфавита графических фигур (икон и макроикон), причем иконы заданы вместе с отростками, что исключает неоднозначность;
— формальное описание синтаксиса, то есть соединительных линий между фигурами;
— визуальное логическое исчисление, позволяющее из аксиомы-силуэт и аксиомы-примитив строить формализованный чертеж алгоритма методом логического вывода.
Язык ДРАКОН разработан исходя из этих предпосылок.

Интеллектуальный ДРАКОН-конструктор

Попробуйте бесплатный онлайн ДРАКОН-конструктор DrakonHub. Вот инструкция.
Вы убедитесь, что процесс рисования происходит удобно, легко и с большой скоростью.

Забудьте о линиях! Не царское это дело — рисовать линии

Во избежание ошибок пользователю запрещено рисовать соединительные линии между иконами на дракон-схеме. Потому что он такого нарисует — мама не горюй!
Все соединительные линии автоматически создает интеллектуальная программа ДРАКОН-конструктор.

Почему она интеллектуальная? Потому что использует специальный математический аппарат — визуальное логическое исчисление (исчисление икон).

Как работает ДРАКОН-конструктор

Ответ показан на анимациях (рис. 9 и рис. 10). Слева панель инструментов (toolbar).
Рис. 9 демонстрирует скорость работы. Рис. 10 поясняет, как переделать уже сделанное.

Оба рисунка показывают работу с макроконструкцией примитив. Редактирование силуэта происходит точно так же.
Переход от примитива к силуэту и обратно производится кнопкой на тулбаре внизу справа.

Рис. 9. ДРАКОН-конструктор позволяет создать сложный алгоритм в наглядном виде и очень быстро

Рис. 10. ДРАКОН-конструктор позволяет переделывать алгоритм (удалять, вставлять и переставлять графические фигуры) очень быстро

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

Правила ДРАКОНа

Язык ДРАКОН содержит большое число правил. К счастью, их не надо учить и запоминать. Почему? Потому что правила знает назубок, хранит в своей памяти и скрупулезно выполняет программа ДРАКОН-конструктор.

Вот пример. В дракон-схемах запрещено пересечение линий, обрывы линий и внутренние соединители. Запрет выполняется автоматически. Конструктор гарантирует отсутствие пересечений на основе строгой математической теории — исчисления икон.

Визуальная алгоритмическая логика языка ДРАКОН. Математическая логика в алгоритмах. Визуальная алгебра логики

Это большая тема и в рамках статьи изложить ее невозможно. Будут даны лишь самые краткие пояснения.

Рис. 11. Стандартный (слева) и нестандартный (справа) алгоритм «ИЛИ»

Классическая (текстовая) и неклассическая (визуальная) алгебра логики

Укажем различие между классическим и неклассическим вариантами алгебры логики (на примере дизъюнкции).

В классическом варианте используется линейная запись логической функции  «ИЛИ», которая не показывает свою инверсию и принципиально не может описать инверсный маршрут алгоритма (рис. 11, в самом низу).

В неклассическом случае применяется графическая запись логической функции «ИЛИ» (рис. 11), которая изображает одновременно как главный, так и инверсный выходы.

Зададим вопрос: какой принцип используется для разграничения успеха и неудачи?

Классический вариант использует «принцип отделения единицы (Истина) от нуля (Ложь)». Если функция равна 1 — это хорошо, если равна 0 — плохо.

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

Стандартный и нестандартный логический алгоритм «ИЛИ»

Стандартный логический алгориитм «ИЛИ» для N логических переменных — это алгоритм, содержащий N икон Вопрос, которые:
— расположены лесенкой;
— в каждой иконе Вопрос содержится одна логическая переменная.

Стандартный алгоритм «ИЛИ» для трех логических переменных представлен на рис. 11, слева.

Нестандартный логический алгоритм «ИЛИ» для N логических переменных — это алгоритм, полученный с помощью рокировки стандартного алгоритма «ИЛИ». На рис. 11 (справа) показан нестандартный алгоритм для случая трех переменных.

Стандартная и нестандартная схемы «ИЛИ» равносильны. Они описывают один и тот же алгоритм.

Четыре маршрута стандартного алгоритма ИЛИ. Формулы маршрутов

Рис. 12. На схеме «ИЛИ» показаны четыре формулы маршрутов (в четырех желтых выносках). Каждая формула — это конъюнкт.

Алгоритм ИЛИ на рис. 12 имеет четыре маршрута. Для каждого из них можно построить формулу маршрута в виде конъюнкта.

Первый маршрут идет по шампуру и имеет формулу “А да”. Слово «да» означает, что буква А берется без отрицания, как показано в левой выноске.

Второй маршрут идет правее с формулой “A нет B да”. Преобразовав в конъюнкт, получим ¬A & B

Третий маршрут идет еще правее и имеет формулу “A нет B нет С да”. После преобразования в конъюнкт, получим ¬A & ¬B & C

Наконец, четвертый маршрут (крайний справа) имеет формулу “A нет B нет С нет” и превращается в конъюнкт: ¬A & ¬B & ¬C. Последний маршрут задает инверсный выход.

Стандартный и нестандартный логический алгоритм «И»

Рис. 13. Стандартный (слева) и нестандартный (справа) алгоритм «И»

Стандартная логическая схема «И» для N логических переменных — это схема, содержащая N икон Вопрос, которые:
— расположены на одной вертикали;
— в каждой иконе Вопрос содержится одна переменная.

Стандартная схема «И» для трех логических переменных представлена на рис. 13, слева.

Нестандартная логическая схема «И» для N логических переменных — схема, полученная с помощью рокировки стандартной схемы «И».
На рис. 13 (справа) дан пример нестандартной схемы для трех переменных.

Стандартная и нестандартная схемы «И» равносильны. Они описывают один и тот же алгоритм.

Принципиальный дефект (ахиллесова пята) текстового программирования

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

Визуальное программирование на языке ДРАКОН лишено этого недостатка. Чтобы избавиться от логического отрицания, надо (всего лишь!) поменять местами «Да» и «Нет» на выходах иконы Вопрос.
Такой прием называется произвольным расположением «Да» и «Нет» на выходах иконы Вопрос.

Расстановка «Да» и «Нет» на выходах иконы Вопрос в алгоритме «И»

Глядя на рис. 13 (слева), можно заметить, что нижние выходы у трех икон Вопрос помечены словом «Да». Является ли такой подход обязательным? Можно ли изменить расстановку «Да» и «Нет» и поменять их местами?

Да, можно. Чтобы убедиться в этом, на рис. 14 (слева) показан другой вариант — возле иконы B мы изменили расстановку «Да» и «Нет» на противоположную.

На что повлияло такое изменение?

Во-первых, на нестандартную схему «И», где возле иконы В также изменилась расстановка «Да» и «Нет» (рис. 14, справа). Во-вторых, изменение затронуло формулу главного и инверсного выхода (над буквой B либо появился, либо исчез знак отрицания).

Подведем итоги. Пользователь имеет право расставлять слова «Да» и «Нет» по своему усмотрению. Принцип построения логической схемы «И» (как стандартной, так и не стандартной) при этом остается неизменным. Разумеется, нестандартная схема всегда должна выводиться из стандартной с помощью рокировки.

Рис. 14. Стандартный (слева) и нестандартный (справа) алгоритм «И».
Произвольное расположение «Да» и «Нет» на выходах икон Вопрос позволяет удалить неоправданные связки отрицания, которые являются катализаторами ошибок

Логические связки желательно устранить из дракон-алгоритмов

Как известно, логическое отрицание представляет определенную трудность для понимания.

В связи с этим Эдвард Йодан советует:
«Если это возможно, избегайте отрицаний в булевых [логических] выражениях. Представляется, что их понимание представляет трудность для многих программистов».

В похожие ловушки часто попадают не только программисты. Трудности испытывают и многие другие люди.
Опасность ошибочного понимания провоцируют не только знаки отрицания, но и другие связки.

Поэтому Йодан расширяет и усиливает свою мысль:
«Избегайте без нужды использования сложных булевых выражений… Даже если нет неоднозначностей, такие выражения обычно с трудом понимают все, за исключением их автора».

Сходные предостережения делает не только Йодан.
Его поддерживает Гленфорд Майерс:
«Распространенным источником ошибок является использование логических операций И и ИЛИ».

Возникает вопрос: можно ли устранить подобные источники ошибок? Существует ли радикальное средство, позволяющее ликвидировать опасные места, спрятанные в логических выражениях и провоцирующие появление ошибок?

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

Рекомендации эргономики

Эргономика позволяет сделать алгоритмы (дракон-схемы) более легкими и удобными для понимания. Глядя на эргономичную дракон-схему, человек может сказать: «Посмотрел — и сразу понял!».

Многие люди испытывают трудности, когда видят внутри икон Вопрос сложные логические формулы, содержащие знаки И, ИЛИ, НЕ. Таким людям можно помочь, исключив эти нежелательные знаки.

Удаление логических связок из алгоритмов

Дракон-алгоритм, содержащий внутри икон Вопрос логические знаки И, ИЛИ, НЕ, всегда можно преобразовать в эквивалентный дракон-алгоритм, не содержащий указанных знаков.

Рис. 15. Удаление логических связок с целью предотвращения ошибок

Конъюнкция без знака конъюнкции

Рис. 16. Выполняется конъюнкция без знака конъюнкции.
Комментарий в рамке облегчает понимание и страхует от ошибок

.

Дизъюнкция без знака дизъюнкции

Рис. 17. Выполняется дизъюнкция без знака дизъюнкции.
Комментарий облегчает чтение и ускоряет отладку программы

.

Визуальная логика. Визуализация сложной логической функции

На рис. 18 вверху показана сложная логическая функция Z. Она содержит семь логических связок, а именно: четыре конъюнкции &, одну дизъюнкцию V и два отрицания (верхняя черта).
При визуализации мы должны удалить все семь связок.
Результат визуализации формулы Z показан на рис. 18 на главном выходе дракон-алгоритма. Легко видеть, что в дракон-алгоритме логические связки полностью отсутствуют.

Рис. 18. Как нарисовать дракон-алгоритм для сложной логической функции

Мантра безошибочности

В языке ДРАКОН предусмотрено много средств для обеспечения безошибочности. Некоторые из них (но не все) описаны выше.
Полную совокупность средств безошибочности языка ДРАКОН для краткости можно назвать мантрой безошибочности.

Частичное доказательство правильности дракон-алгоритмов

Роберт Андерсон подчеркивает:
«целью многих исследований в области доказательства правильности программ является... механизация таких доказательств».

Дэвид Грис указывает:
«доказательство должно опережать построение программы».

Объединив оба требования, получим, что автоматическое доказательство правильности должно опережать построение алгоритма. Нетрудно убедиться, что метод исчисления икон обеспечивает частичное выполнение этого требования.

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

Во внутренних алгоритмах ДРАКОН-конструктора закодировано исчисление икон. Поэтому любая шампур-схема, построенная с его помощью и не содержащая критических точек, является истинной, то есть правильно построенной. Этот результат означает, что:
ДРАКОН-конструктор осуществляет частичное автоматическое доказательство правильности шампур-схем.

К сожалению, данный метод позволяет доказать правильность шампур-схемы и только. Это составляет лишь часть от общего объема работы, которую нужно выполнить, чтобы доказать правильность дракон-алгоритма на 100%.

Мантра экономичности (без дополнительной затраты времени, средств и ресурсов)

Здесь необходима оговорка. Частичное доказательство правильности дракон-алгоритма с помощью «ДРАКОН-конструктора» осуществляется автоматически и достигается совершенно бесплатно, так как дополнительные затраты труда, времени и ресурсов не требуются.

Так что полученный результат (почти безошибочное автоматическое проектирование графики дракон-алгоритмов) следует признать значительным достижением.

Программно-алгоритмические ошибки и средства борьбы с ними

Ошибки в алгоритмах и программах (software bugs, logic errors) доставляют много неудобств специалистам и пользователям. Для предотвращения, поиска и исправления ошибок используют разнообразные средства:

— требования к программному обеспечению (software requirements);
— спецификация требований программного обеспечения (software requirements specification);
— просмотр кода (code review);
— статический анализ кода (static code analysis);
— тестирование (software testing); 
— тестирование на основе модели (model-based testing);
— отладка (debugging);
— защитное программирование (defensive and secure programming);
— рефакторинг (refactoring);
— система отслеживания ошибок (bug tracking system);
— формальная верификация (formal verification);
— контрактное программирование (design by contract);
— проверка моделей (model checking);
— стандарт оформления кода, стиль программирования (coding standard, coding convention, programming style).

Указанные средства обладают несомненными достоинствами, однако они не снимают проблему. Сохраняется потребность в разработке новых средств противодействия ошибкам.

Метод исчисления икон и метод удаления логических связок могут дополнить этот список для случая визуального программирования.

Брифинг

Под спойлером даны краткие сведения об исчислении икон и автоматическом доказательсте.

1.    Для предотвращения ошибок разработан специальный математический аппарат — визуальное логическое исчисление под названием «исчисление икон».

2.    Данное исчисление является разделом визуальной математической логики.

3.    Графический синтаксис языка ДРАКОН представляет собой исчисление икон.

4.    Исчисление икон является теоретическим обоснованием языка ДРАКОН.

5.    Графика дракон-алгоритмов играет важную роль.

6.    Визуальное логическое исчисление служит для защиты графики от ошибок.

7.    Исчисление икон реализовано во внутренних алгоритмах «ДРАКОН-конструктора».

8.    Программа «ДРАКОН-конструктор» осуществляет частичное автоматическое доказательство правильности графики дракон-алгоритмов.

9.    Почти безошибочное автоматическое проектирование графики дракон-алгоритмов является полезным достижением, повышающим производительность труда при практическом работе.

Семейство ДРАКОН-языков. Гибридные языки

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

Императивную (процедурную) часть языка ДРАКОН можно присоединить к некоторым языкам программирования и получить гибридные языки, например:

Рис. 19. Примеры гибридных языков программирования ДРАКОН-семейства

Как построить гибридный язык Дракон-Си

Чтобы построить язык Дракон-Си, надо по определенным правилам соединить графический синтаксис ДРАКОНа с текстовым синтаксисом языка Си. При этом Си рассматривается как целевой язык (target language). Нужно сделать следующее:

— использовать синтаксис целевого языка (синтаксис языка Си) в качестве текстового синтаксиса гибридного языка Дракон-Си;
— удалить из текстового синтаксиса гибридного языка Дракон-Си все элементы, которые заменяются управляющей графикой ДРАКОНа;
— создать транслятор из дракон-схемы в исходный код языка Си.

Любой гибридный язык (например, Дракон-Си) почти полностью сохраняет концепцию, структуру, типы данных и другие особенности целевого языка (Си). При этом в строго определенном числе случаев текстовая нотация целевого языка заменяется на визуальную. Такой прием позволяет существенно улучшить эргономический облик языка и сократить число ошибок.

ДРАКОН играет роль защитного фильтра

Применяя гибридный язык, например, Дракон-Си, пользователь начинает работу с дракон-алгоритмом и получает все преимущества языка ДРАКОН, связанные с безошибочностью.

Известно, что Си — небезопасный язык. По мнению экспертов,

«не вызывает сомнений, что Си – изобилующий потенциальными опасностями и не вполне прозрачный для восприятия человеком язык».

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

ДРАКОН — это новый способ работать с существующими языками программирования

Что такое ДРАКОН: язык программирования или нет? Здесь имеется заблуждение, которое необходимо устранить.

Некоторые рассматривают ДРАКОН как еще один язык программирования. Дескать, сейчас есть N языков программирования, например 9000 языков, а появился ДРАКОН, их стало на единицу больше N + 1 (9001). Это не совсем так.

ДРАКОН — это ИНОЙ способ работать с уже существующими языками программирования.
ДРАКОН работает не в одиночку, а в паре с чем-то (Мы с Тамарой ходим парой).
Что это значит?

Возьмем к примеру язык Си. Это значит, что в графических иконах ДРАКОНа мы пишем код на языке Си (без управляющих операторов, разумеется). Затем графический ДРАКОН-алгоритм (с сишным кодом) транслируется в исходный код языка Си, после чего компилируется в исполняемый код.

Это называется Гибридный язык Дракон-Си.
Вместо Си могут быть другие языки Java, JavaScript и т. д. Много вариантов.

Автоматное программирование на языке ДРАКОН

Алгоритмическая макроконструкция силуэт представляет собой конечный автомат и способна работать в двух режимах:
— императивное программирование;
— автоматное программирование.

Смотри статью Автоматное программирование на языке ДРАКОН.

Учебное пособие по языку ДРАКОН для вузов «Алгоритмические языки и программирование: ДРАКОН»

Под спойлером краткие сведения об учебном пособии.

Рецензенты:

Терехов А. Н. — доктор физико-математических наук, профессор, заведующий кафедрой системного программирования математико-механического факультета Санкт-Петербургского государственного университета;

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

Паронджанов В. Д. Алгоритмические языки и программирование: ДРАКОН : учебное пособие для вузов. — Москва : Издательство Юрайт, 2020. — 430 с. — (Высшее образование).

ISBN 978-5-534-13146-8 (Издательство Юрайт)

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

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

Содержание учебного пособия соответствует актуальным требованиям Федерального государственного образовательного стандарта высшего образования.

Для начинающих программистов, непрограммистов, программистов-любителей, студентов, бизнесменов и топ-менеджеров.

Рекомендовано Учебно-методическим отделом высшего образования в качестве учебного пособия для студентов высших учебных заведений, обучающихся по ИТ, инженерно-техническим направлениям

Книга будет доступна на образовательной платформе «Юрайт» urait.ru, а также в мобильном приложении «Юрайт.Библиотека»

Первый недостаток: отсутствует фирма, поддерживающая и развивающая язык ДРАКОН и его инструменты

Язык ДРАКОН находится на начальном этапе развития. Он существует как идея (в Википедии ДРАКОН, DRAKON представлен на десяти языках), но он пока еще не существует как товарный продукт.
Нет никакой фирмы, которая разрабатывает, поддерживает и совершенствует язык ДРАКОН и развивает его инструменты. Этим занимаются энтузиасты, которые где-то работают full time, а в свободное время выкраивают время для ДРАКОНа. В сети «В контакте» группа ДРАКОНа насчитывает всего 300 человек, на официальном форуме ДРАКОНа столько же. Это очень мало.

Второй недостаток: инструменты ДРАКОНа имеют экспериментальный характер и нуждаются в совершенствовании

Доступны для использования четыре ДРАКОН-конструктора
для программирования:
1. ИС Дракон (коммерческая программа)
разработчик Геннадий Тышов (Россия, Северодвинск);

2. DRAKON Editor с открытым исходным кодом (public domain)
разработчик Stepan Mitkin (Норвегия);

3. Drakon.Tech с открытым исходным кодом (public domain)
разработчик Stepan Mitkin (Норвегия);

без программирования:
4.
DrakonHub с открытым исходным кодом (public domain)
разработчик Stepan Mitkin (Норвегия).

Существуют еще два ДРАКОН-конструктора, которые недоступны для использования:
Артем Бразовский (Белоруссия, Минск) создал свой ДРАКОН-конструктор и использует его для коммерческих целей.
Oleg Garipov (США, Нью-йорк) разработал для своих целей собственный ДРАКОН-конструктор, но не раскрывает его.

И последнее. Эдуард Ильченко разработал публичный ДРАКОН-конструктор «Фабула» и хранил программу в облаке. Увы, он скоропостижно ушел из жизни, и ссылка стала недоступной.

Третий недостаток: отсутствует стандарт языка ДРАКОН

В качестве стандарта используются книги:
1. Паронджанов В. Д. Алгоритмы и жизнеритмы на языке ДРАКОН. Разработка алгоритмов. Безошибочные алгоритмы. — М.: Препринт, 2019. — 374 с.
2. Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. — М.: ДМК Пресс, 2012, 2014, 2016. — 520 с.

Четвертый недостаток: микроскопическая (почти нулевая) доля рынка

Приведу примеры коммерческого использования языка ДРАКОН, по которым можно составить впечатление об его присутствии на рынке.

1-й и 2-й примеры. Предприниматель Алексей Муравицкий, системный интегратор фирмы ОВЕН

использует ДРАКОН-технологию в нефтегазовой промышленности, пищевой промышленности, теплоэнергетике
для программирования ПЛК при разработке шкафов управления установками и насосами
1.
На видео показана установка глубокой переработки широкой фракции легких углеводородов (ШФЛУ) Южно-Балыкского газоперерабатывающего завода компании "Сургутнефтегаз"и шкаф управления установкой, где используется управляющая программа, 70%-80% которой написано на языке ДРАКОН.
Программа загружается в энергонезависимую память Сенсорного программируемого контроллера СПК 107 М01 фирмы ОВЕН.

2. На видео показан шкаф управления насосами объемного действия частотно-регулируемого электропривода на кустовой насосной станции Азнакаевского нефтегазодобывающего управления компании «Татнефть», где используется управляющая программа, 70%-80% которой написано на языке ДРАКОН. Программа загружается в энергонезависимую память сенсорного программируемого контроллера СПК 107 фирмы ОВЕН.

3-й пример. Предприниматель Сергей Ефанов

использует ДРАКОН-технологию уже 10 лет (с 2010 года) в торговле и других отраслях
при программировании микроконтроллеров: PIC (Microchip), MSP430 (Texas Instruments), STM32 (STMicroelectronics).

За это время с помощью ДРАКОН-конструктора «ИС Дракон» Ефанов сделал несколько десятков проектов:

— торговые автоматы,
— контрольно-кассовые машины,
— блоки защиты электродвигателей,
— GPS-трекеры,
— GSM-устройства
— и др.

4-й пример. Паулюс Добожинскас (Литва), руководитель коммерческого медицинского учебного центра

использует язык ДРАКОН для поточного (9000 человек в год) автономного обучения медиков в симуляционном классе без активного участия преподавателей и инструкторов.
Об успехах Добожинскаса по применению ДРАКОНа рассказано в статье Русской службы ВВС и на рекламном видео (на английском языке с русскими субтитрами).

5-й пример. Специалисты из Поволжского медицинского университета и Института Федеральной службы безопасности России

используют язык ДРАКОН для противодействия новой коронавирусной инфекции COVID-19.

Под спойлером представлен конспект статьи о разработке 17 клинических алгоритмов на медицинском алгоритмическом языке ДРАКОН для лечения больных коронавирусом (респираторной терапии). Алгоритмы были успешно использованы для обучения реманиматологов-анестизиологов за неделю до открытия (перепрофилирования) клиник для приема больных коронавирусом.

Медицинский алгоритмический язык ДРАКОН против пандемии

Обучение анестезиологов-реаниматологов

В статье описана роль языка ДРАКОН при создании алгоритмов респираторной терапии. Лечение поражения лёгких при COVID-19 является трудной проблемой для анестезиологов-реаниматологов. Рост числа больных, нуждающихся в интенсивной терапии и искусственной вентиляции легких, привел к нехватке специалистов, владеющих протективной вентиляцией легких.

Возникла необходимость переподготовки врачей отделений реанимации и интенсивной терапии. Многие анестезиологи-реаниматоло-ги не являются специалистами в области респираторной терапии при осложненных формах COVID-19. Они нуждаются в дополнительных знаниях для эффективного лечения осложнённых форм и снижения летальности пациентов. Им нужна серьезная переподготовка, нужен специальный учебный курс.

Язык ДРАКОН помог врачам качественно разработать алгоритмы респираторной терапии

Группа авторов из Приволжского исследовательского медицинского университета и Института ФСБ России (Сморкалов А.Ю., Чистяков С.И., Горох О.В., Певнев А.А.) изучила медицинский язык ДРАКОН и разработала учебный курс «Интенсивная терапия осложнённых форм коронавирусной инфекции». Они составили Программу дополнительного обучения врачей анестезиологов-реаниматологов, в которой реализован комплексный подход к обучению с использованием симуляционных технологий.

Для выполнения Программы с помощью языка ДРАКОН были разработаны алгоритмы респираторной терапии и лечения осложненных форм у больных с новой коронавирусной инфекцией.

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

Результаты опубликованы в статье: «Особенности реализации программы дополнительной подготовки врачей по специальности “анестезиология-реаниматология” “Интенсивная терапия осложненных форм новой коронавирусной инфекции”».

Статья убедительно демонстрирует практическую значимость языка ДРАКОН. Ниже представлено сокращенное изложение статьи.

Сокращения

COVID-19 — coronavirus disease 2019;
ИВЛ        — искусственная вентиляция легких;
НИВЛ — неинвазивная искусственная вентиляция легких;
НИМВЛ — неинвазивная масочная искусственная вентиляция легких;
ОДН    — острая дыхательная недостаточность;
ОРДС — острый респираторный дистресс-синдром;
ОРИТ — отделение реанимации и интенсивной терапии.

Поражения лёгких при COVID-19. Тяжёлые и крайне тяжёлые пациенты

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

Больные, поступающие в отделение реанимации и интенсивной терапии (ОРИТ) с тяжелой дыхательной недостаточностью, как правило, старше 65 лет. Они страдают сопутствующей соматической патологией (диабет, ишемическая болезнь сердца, цереброваскулярная болезнь, неврологическая патология, гипертоническая болезнь, онкологические заболевания, гематологические заболевания, хронические вирусные заболевания, нарушения в системе свёртывания крови).

Больные, направляемые на реанимацию, относятся к категории тяжёлых или крайне тяжёлых пациентов.

При крайне тяжёлом течении часто развивались быстро прогрессирующие заболевания:
— острая дыхательная недостаточность с необходимостью респираторной поддержки (инвазивная вентиляции лёгких);
— септический шок;
— полиорганная недостаточность.

Респираторная терапия

У больных с дыхательной недостаточностью используется респираторная терапия. В настоящее время существует множество вариантов респираторной терапии:
— ингаляция кислорода (низкопоточная — до 15 л/мин, высокопоточная — до 60 л/мин);
— искусственная вентиляция легких (неинвазивная или инвазивная, высокочастотная вентиляция лёгких).

В терапии классического острого респираторного дистресс-синдрома  для лечения острой дыхательной недостаточности принято использовать ступенчатый подход к выбору респираторной терапии.

Простая схема выглядит следующим образом: низкопоточная кислородотерапия — высокопоточная кислородотерапия или неинвазивная — инвазивная ИВЛ. Выбор того или иного метода респираторной терапии основан на степени тяжести дистресс-синдрома.

О чем говорит мировая практика

Мировая практика свидетельствует о крайне большом проценте летальных исходов при использовании инвазивной ИВЛ (до 85–90%) у больных с вирусной инфекцией, вызванной COVID-19. На наш взгляд данный факт связан с крайне тяжелым состоянием пациентов, особенностями течения заболевания COVID-19 и нарушениями принципов протективной вентиляции, а также применением седации и миорелаксации у этой категории больных.

Тяжесть пациентов, которым показана инвазивная ИВЛ, обусловлена большим объёмом поражения легочной ткани (как правило более 75%), а также возникающей суперинфекцией при проведении длительной ИВЛ.

Отсутствие чётких алгоритмов респираторной терапии и дефицит врачей

Применение ИВЛ у таких больных является серьёзной проблемой для большинства врачей, в том числе и анестезиологов-реаниматологов, не являющихся специалистами в области респираторной терапии.

Одной из основных трудностей проведения респираторной терапии пациентам с COVID-19 является отсутствие чётких алгоритмов и рекомендаций по выбору ее метода и настройке аппаратов ИВЛ.

В свою очередь, увеличение количества пациентов с COVID-19, нуждающихся в интенсивной терапии с потенциальной потребностью в ИВЛ, привело к дефициту врачей, знающих принципы протективной вентиляции легких.

Подбор параметров ИВЛ — это хождение по лезвию ножа

У пациентов с COVID-19 при позднем переводе на искусственную вентиляцию лёгких включается дополнительный повреждающий фактор — транспульмональное давление. Поэтому любая задержка перевода пациента на аппаратную вентиляцию лёгких приводит к увеличению объёма поражения лёгочной ткани.

В то же время сама ИВЛ является мощным повреждающим фактором, особенно при неправильно подобранных параметрах. Основными причинами этого повреждения становятся волюмотравма, баротравма, циклическая травма, оксигенотравма и ателектотравма.

Следовательно, подбор оптимальных параметров ИВЛ у больных с тяжёлыми вирусными пневмониями и ОРДС — это своего рода «хождение по лезвию ножа».

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

Программа дополнительного обучения врачей по курсу «Интенсивная терапия осложнённых форм коронавирусной инфекции»

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

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

Цель обучения в условиях пандемии COVID-19

Цель обучения — удовлетворение образовательных и профессиональных потребностей, обеспечение соответствия квалификации врачей меняющимся условиям профессиональной деятельности и социальной среды; совершенствование имеющихся профессиональных компетенций,.. необходимых для профессиональной деятельности и повышения профессионального уровня в рамках имеющейся квалификации по специальности «Анестезиология-реаниматология».

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

Для учебного процесса нужны алгоритмы действий врача на языке ДРАКОН

Для обеспечения учебного процесса на основании руководящих документов нами были созданы алгоритмы действий по всем модулям с использованием алгоритмического медицинского языка ДРАКОН, которые позволили повысить качество и наглядность обучения.

Занятия проводились в отделениях реанимации соответствующих клиник за неделю до их открытия для приема пациентов с COVID-19. Данная ситуация позволила обучить врачей в условиях отделения, в котором им предстояло работать, что также помогло обеспечить определённый уровень психологической подготовки.

Тренинг на аппаратуре клиники

Для проведения тренинга использовалась аппаратура клиники, в которой предстояло работать врачам (мониторы, аппараты ИВЛ, дефибрилляторы, перфузоры, и т. д.). Навык проведения респираторной терапии отрабатывался на следующих аппаратах ИВЛ:

1. Dräger Savina®
2. Dräger Evita® XL
3. Zisline МV200 К0.20
4. Medtronic Puritan Bennett 840
5. HAMILTON-G5

Принципы обеспечения проходимости дыхательных путей при осложнениях COVID-19 (модуль 3)

Обучение на симуляционном модуле 3 (надгортанные воздуховоды, интубация трахеи, ранняя пункционная трахеостомия) проводилось по стандартной схеме симуляционного тренинга, включающего все 5 этапов.

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

— интубация трахеи,
— плановая ранняя пункционно-дилатационная трахеостомия,
— санация трахеобронхиального дерева,
— замена контура аппарата ИВЛ и бактериальных фильтров,
— экстренная коникотомия.

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

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

Алгоритмы действий врача на языке ДРАКОН, обеспечивающие проходимость дыхательных путей (модуль 3)

Для наглядности с использованием алгоритмического медицинского языка ДРАКОН были созданы следующие алгоритмы действий:
— Перевод в ОРИТ.
— Плановая интубация трахеи.
— Экстренная интубация трахеи.
— Интубация при трудных дыхательных путях.
— Плановая ранняя трахеостомия.
— Экстренная коникотомия.

Принципы неинвазивной респираторной терапии (модуль 4)

Для проведения тренинга по симуляционному модулю 4 нами использовался симулятор пациента Kelli, симулятор высокопоточной оксигенации AIRVO 2 для операционной системы Android и неинвазивная маска. Проведение неинвазивной терапии отрабатывалось на всех доступных в клинике аппаратах ИВЛ. Структура симуляционного тренинга включала 5 стандартных этапов:

1. Входной контроль.
2. Брифинг (инструктаж).
3. Основной этап (симуляционный тренинг-имитация).
4. Дебрифинг.
5. Итоговая аттестация.

Алгоритмы действий врача на языке ДРАКОН, обеспечивающие неинвазивную респираторную терапию (модуль 4)

Для наглядности обучения были разработаны следующие алгоритмы:

— Выбор метода респираторный терапии.
— Высокопоточная оксигенация.
— Неинвазивная вентиляция лёгких.

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

Алгоритмы действий на языке ДРАКОН: Протективная ИВЛ. Эффективность рекрутмент-маневров. Вентиляция в положении на животе (модуль 5)

Подробно следует остановиться на методике изучения модуля 5 (Протективная ИВЛ. Эффективность рекрутмент-маневров. Вентиляция в положении на животе).

Весь процесс перевода на ИВЛ и eго проведение был разбит на четыре основных этапа, по каждому из них, с использованием алгоритмического медицинского языка ДРАКОН, был написан алгоритм действий:

— Подбор базовых параметров ИВЛ в концепции протективной вентиляции.
— Оценка рекрутабельности лёгких и подбор положительного давления в конце выдоха.
— Улучшение оксигенации (в том числе применение прон-позиции).— Отлучение пациента от ИВЛ.

Заключение

Разработаны 17 клинических алгоритмов на языке ДРАКОН для четырех функциональных модулей респираторной терапии при COVID-19:

Обеспечение проходимости дыхательных путей (модуль 3)

1. Перевод в ОРИТ.
2. Плановая интубация трахеи.
3. Экстренная интубация трахеи.
4. Интубация при трудных дыхательных путях.
5. Плановая ранняя трахеостомия.
6. Экстренная коникотомия.

Неинвазивная респираторная терапия (модуль 4)

7. Выбор метода респираторный терапии.
8. Высокопоточная оксигенация.
9. Неинвазивная вентиляция лёгких.

Протективная ИВЛ. Эффективность рекрутмент-маневров. Вентиляция в положении на животе (модуль 5).

10. Подбор базовых параметров ИВЛ в концепции протективной вентиляции.
11. Оценка рекрутабельности лёгких и подбор положительного давления в конце выдоха.
12. Улучшение оксигенации (в том числе применение прон-позиции).
13. Отлучение пациента от ИВЛ.

Интенсивная терапия септического шока и проведение реанимационных мероприятий (модуль 6)

14. Диагностика и интенсивная терапия септического шока.
15. Базовые реанимационные мероприятия у больных с COVID-19. 16. Расширенные реанимационные мероприятия у больных с COVID-19.
17. Перевод пациента в отделение реанимации и интенсивной терапии.

Реализация Программы позволила быстро и качественно подготовить специалистов для работы в отделении реанимации с пациентами COVID-19. Был выработан единый подход к проведению респираторной терапии. Совместно с комплексной терапией это позволило добиться в одной из клиник нулевой летальности.

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

С помощью алгоритмического медицинского языка ДРАКОН были разработаны алгоритмы респираторной терапии и лечения осложненных форм у больных с новой коронавирусной инфекцией.

Пятый недостаток относится непосредственно к языку ДРАКОН

Данный параграф написал специалист Comdiv из Киева:

Ниже представлен список недостатков языка, которые, во многом, характерны для любых языков блок-схем. Одни недостатки являются продолжением преимуществ, а другие могут не являться таковыми в ряде областей.

5.1. Особенность языка подразумевает более сложные способы ввода, редактирования и передачи по сравнению как с плоским, так и, отчасти, насыщенным текстом. Для кода характерны необходимость вырезания, вставки, слияния, поиска и замены по шаблону, что трудно осуществлять с блок-схемами в прямом виде. Частично может быть решено введением текстового представления или разработками в области программ для работы со схемами.

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

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

5.4. Зашумленность кода. При небольшом изучении, особенно в ряде языков, поток выполнения кода становится очевидным, и его подчёркивание, что может быть и полезным в ряде случаях, здесь не только не вносит дополнительной ясности, но и, наоборот, отвлекает от основной сути кода. Есть неустранимое противоречие в представлении кода для разных применений и разных групп пользователей.

5.5. Не всем людям представление кода в виде блок-схем, пусть и составленным по дополнительным эргономическим правилам, даёт преимущество в восприятии кода по сравнению с текстом, и возможна обратная зависимость.

5.6. Недостаточная структурность кода в языке, что не нивелируется полностью очевидностью неструктурных переходов. Например, это увеличивает сцепку кода и усложняет декомпозицию. Сильная декомпозиция, в свою очередь, обесценивает подчёркнутость переходов.

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

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

Причем пользователь ДРАКОНа не обязан знать, что он (пользователь) при разработке алгоритма применяет аксиоматический метод, в котором используются аксиомы, что построение ДРАКОН-алгоритма есть логический вывод из заданных аксиом на основе правил вывода.
Больше того, пользователю не нужно это знать!

Пользователь может даже не догадываться, что ДРАКОН-конструктор производит частичное автоматическое доказательство правильности всех создаваемых ДРАКОН-алгоритмов. Причем эти услуги и удобства пользователь получает бесплатно, не затрачивая дополнительно ни времени, ни денег, ни ресурсов.
Повторяю, он может даже не знать об этом, так как вся математика, направленная на достижение безошибочности, полностью скрыта от пользователя языка ДРАКОН!

Неклассическая теория алгоритмов и язык ДРАКОН

Язык ДРАКОН опирается на неклассическую теорию алгоритмов.
Современная теория алгоритмов не имеет удобного (эргономичного) языка, позволяющего облегчить и ускорить понимание алгоритмов ЧЕЛОВЕКОМ.
Она полностью игнорирует проблему безошибочности. Она не применима к клиническим алгоритмам и не содействует повышению безопасности пациентов. Она не оказывает практической помощи при разработке бизнес-процессов, потоков работ (workflows) и пр.
Современные языки программирования используют управляющие слова (if, then, else, case, switch, break, while, do, repeat, until, for, foreach, continue, loop, exit, when, last и др.) , которые играют роль визуальных помех, провоцируют появление ошибок и мешают понять смысл алгоритма в терминах предметной области.
В докладе предлагаются теоретические и практические средства, чтобы устранить или ослабить указанные недостатки. Презентация доклада здесь.

Великое объединение

Сегодня текстовое программирование доминирует в мире ИТ, опираясь на колоссальные ресурсы, вложенные в его развитие.
Чтобы помочь развитию визуального программирования, оно должно опереться на эти ресурсы. ДРАКОН — попытка использовать указанные ресурсы с помощью великого объединения двух конкурирующих идей: текстового ПО и визуального ПО.

Для решения этой задачи введено понятие гибридный язык программирования и построено открытое множество — семейство гибридных ДРАКОН-языков.

Вот один из этих людей: пилот Яред Гетачу — красивый, молодой, в полном расцвете сил (справа)

Рис. 20. Командир самолета Боинг 737 MAX Яред Гетачу (справа), управлявший рейсом 302 авиакомпании Ephiopian Airlines, вылетевшим из Аддис-Аббебы 10 марта 2019 года в 8:38 по местному времени. Что поизошло через шесть минут мы уже знаем

Может ли текстовое программирование обеспечить создание безошибочных алгоритмов?

В ближайшие десятилетия текстовое программирование будет интенсивно развиваться и добьется замечательных успехов. Будут разработаны новые языки программирования, новые инструменты и IDE, которые позволят улучшить многие параметры, устранить многие недостатки, предоставят программистам новые возможности и облегчат их труд.

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

Почему? Потому что программирование стало слишком сложным (а будет еще сложнее). Проклятие сложности — серьезное препятствие. Оно исключает возможность работать без ошибок.

Что нас ждет в будущем

Чтобы приблизиться к безошибочности, в текстовое программирование будут постепенно вноситься отдельные элементы визуального программирования.

Язык ДРАКОН и ДРАКОН-методология — это попытка двигаться по этому пути. ДРАКОН демонстрирует перспективность данного направления и показывает, как это можно осуществить на практике.

Литература

1. (1995) Паронджанов В. Д. Графический синтаксис языка ДРАКОН // Программирование.  1995, №3. С. 45-62.

2. (1998) Паронджанов В. Д. Как улучшить работу ума. (Новые средства для образного представления знаний, развития интеллекта и взаимопонимания). — М.: Радио и связь, 1998, 1999. — 352 с.

3. (2001) Паронджанов В. Д. Как улучшить работу ума. Алгоритмы без программистов — это очень просто. — М.: Дело, 2001. — 360 с.

4. (2009 (Паронджанов В. Д. Язык Дракон. Краткое описание. — М., 2009. — 124 с.

5. (2010) Паронджанов В. Д. Дружелюбные алгоритмы, понятные каждому. Как улучшить работу ума без лишних хлопот. — М.: ДМК-пресс, 2010, 2014, 2016. — 464 с.

6. (2012) Ефанов С. Д. Программирование микроконтроллеров на ДРАКОНе. — Сайт Сообщество EasyElectronics.ru

7. (2012) Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. — М.: ДМК Пресс, 2012, 2014, 2016. — 520 с.

8. (2016) Паронджанов В.Д. Визуальный алгоритмический язык ДРАКОН в ракетной технике и медицине // Современные автоматизированные системы управления реального времени как прикладное развитие научных достижений кибернетики» (К 100-летию со дня рождения И.А. Полетаева). Материалы межведомственной конференции 24 марта 2016 г. — ФГБУ «3 ЦНИИ» Министерства обороны РФ, 2016. — 218 с. — С. 57-78.

9. (2017) Паронджанов В. Д. Неклассическая теория алгоритмов и алгоритмический язык ДРАКОН. — М.: ИСП РАН, 2017. — Доклад на семинаре в институте системного программирования РАН 19 мая 2017 г.

10. (2017) Паронджанов В.Д. Почему врачи убивают и калечат пациентов, или Зачем врачу блок-схемы алгоритмов? Иллюстрированные алгоритмы диагностики и лечения — перспективный путь развития медицины. Клиническое мышление высокой точности и безопасность пациентов. / Предисл. члена-корр. РАН Г.В. Порядина. — М.: ДМК Пресс, 2017. — 340 с.

11. (2017) Митькин С.Б. Визуальное программирование на языке ДРАКОН. — Хабр, 2017 ( @rykkinn )

12. (2019) Митькин С. Б. Автоматное программирование на языке ДРАКОН // Программная инженерия. Том 10, № 1, 2019.

13. (2019) Паронджанов В. Д. Алгоритмы и жизнеритмы на языке ДРАКОН. Разработка алгоритмов. Безошибочные алгоритмы. — М.: Препринт, 2019. — 374 с.

14. (2020) Паронджанов В. Д. Нужен ли Вооруженным Силам России и другим структурам Министерства обороны РФ стандарт для описания алгоритмов? — М.: Обращение к Президенту РФ, 2020. — 70 с.

15. (2021) Паронджанов В. Д. Алгоритмические языки и программирование: ДРАКОН : учебное пособие для вузов. — Москва : Издательство Юрайт, 2020. — 430 с. — (Высшее образование). (В печати).

Литература на тему «Медицинский алгоритмический язык ДРАКОН»

16. (2012) Специализированная реанимация новорожденного. Учебник / Под ред. Р. Й. Надишаускене — Литва, 2012. — 396 с.

17. (2014) Aistė Vileikytė, Rūta Jolanta Nadišauskienė, Vladimiras Parandžanovas, Paulius Dobožinskas, Algirdas Karalius, Aušrelė Kudrevičienė. Algoritminės „Drakon“ kalbos pritaikymas medicinoje (на литовском языке). —

18. (2016) Паронджанов В.Д. Можно ли улучшить медицинский язык? // Человек. 2016. №1. — С. 105-122.

19. (2016) Паронджанов В. Только со смертью догмы начинается наука // Медицинская газета. N 97. 23 дек. 2016. — С. 11.

20. (2017) Паронджанов В.Д. Почему врачи убивают и калечат пациентов, или Зачем врачу блок-схемы алгоритмов? Иллюстрированные алгоритмы диагностики и лечения — перспективный путь развития медицины. Клиническое мышление высокой точности и безопасность пациентов. / Предисл. члена-корр. РАН Г.В. Порядина. — М.: ДМК Пресс, 2017. — 340 с.

21. (2018) Гусев С. Д. Алгоритмы и блок-схемы в здравоохранении и медицине : учебное пособие – Красноярск : тип. КрасГМУ, 2018. — 122 с.

22. (2019) Паронджанов В.Д. Перспективы развития медицинской науки и алгоритмическая клиническая медицина Рукопись.

23. (2020). Сморкалов А.Ю., Чистяков С.И., Горох О.В., Певнев А.А. Особенности реализации программы дополнительной подготовки врачей по специальности «Анестезиология-реаниматология», «Интенсивная терапия осложненных форм новой коронавирусной инфекции» // Виртуальные технологии в медицине. № 2 (24). 2020. — С. 42-47.

24. (2021) Митькин С.Б., Паронджанов В. Д. Инструкция. Как нарисовать клинический алгоритм (алгоритм действий врача) с помощью онлайн-редактора DrakonHub. — 2021.

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 574

    +11
    пора уже закопать стюардессу!
      0
      весна не за горами
        +9

        Не взлетит.


        Визуальное программирование попросту неудобно по сравнению с текстом. Раньше (лет 25 назад) считалось, что удобнее, но опыт (и низкая распространённость сред визуального программирования) говорит об обратном.


        Ни разу не встречал, чтобы при программировании текстом кто-то перепутал if и while, ну или else и for. Обычно труднонаходимые ошибки — это ошибки индексации (i вместо i-1), перепутанные переменные (i вместо j), перепутанные константы (PI вместо TWO_PI), перепутанные операции (* вместо **), перепутанный порядок операций (в сложных случаях). Визуальное программирование от этого не спасёт.

          0

          Ну на самом деле это зависит от размеров блоков. При определенном уровне абстракций может быть и взлетит

            +3

            Ага, вот только у Дракона тот самый уровень абстракций ниже чем у современных ЯВУ.

              0
              Ага, вот только у Дракона тот самый уровень абстракций ниже чем у современных ЯВУ.
              ДРАКОН — это новый способ работатьс современными ЯВУ.
                0

                Неа, не получится. Выразительности не хватит, как и уровня абстракций.

            0
            несмотря на книги «как улучшить работу ума» они так и не смогли написать компилятор.
            впрочем, один совет Паронджанова «использовать многосимвольные имена потому, что современные программы позволяют использовать для имен больше 8 символов, аж до 32» (источник не назову сходу, но один из его опусов) — уже показывает, на каком уровне дремучести оно находится. И да, «верификация дуракон-схемы осуществляется путем тщательного просматривания человеком»(это с изи-электроникс — там, правда, ветку после битв почистили изрядно, много перлов пропало)
              +1
              Согласен. Начиная с определенного количества блоков, которое достигается достаточно быстро, отладка в таком визуальном конструкторе превращается в адский треш.

              Пользуюсь таким автоматизатором (Automagic) на телефоне: программируются разные задачи в визуальном стиле. Что-то простое делается на коленке на раз-два, а вот более сложные задачи создавать и отлаживать достаточно сложно.
                0
                Начиная с определенного количества блоков, которое достигается достаточно быстро, отладка в таком визуальном конструкторе превращается в адский треш.
                Это не так.
                1. В ДРАКОНе есть мощные средства визуальой декомпозиции.

                2. Я уже писал в статье, процитирую еще раз:
                Индивидуальный предприниматель Сергей Ефанов:
                Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.
                Функция заработала сразу!
                Более того, при переносе алгоритма в дракон-схему, я обнаружил, что у меня в ней была ошибка! Эта функция работала уже довольно давно, не в одной сотне изделий. Ошибка не была фатальной, она возникала редко, и компенсировалась переподключением к серверу. Но она была!
                В тексте на Си ее было незаметно. А при попытке перенести алгоритм на дракон-схему, ошибка стала не просто заметной — алгоритм в этом месте «не вырисовывался»!
                  +2
                  Я уже писал в статье, процитирую еще раз:

                  Без конкретного примера:


                  • задачи
                  • исходного кода
                  • получившегося кода

                  этот пример является всего лишь субъективным высказыванием одного человека.

                    +1
                    Индивидуальный предприниматель Сергей Ефанов:
                    Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.
                    Функция заработала сразу!

                    Взрослый же человек — неужели не понимаете, что это звучит как рекламный трэш?

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

                    Фу.

                    UPD
                    Что всегда было забавно во фриках — это их способность к организации набегов и лайк-дизлайк-баттлов. Даже тогда, когда очевидно, что публика совершенно не впечатлена (и не будет) очередной «инновацией», «единой теорией всего», «универсальным средством» и т.п. А Министерство обороны, внезапно, денег не дало :-)
                      0
                      Взрослый же человек — неужели не понимаете, что это звучит как рекламный трэш?
                      Это цитата из статьи Сергея Ефанова "Программирование микроконтроллеров на ДРАКОНе", которая приведена в разделе литература. Там есть четыре видео, где все подробно показано с кодами.
                        +1

                        Ну вот пойдем в статью, нам не сложно.


                        Всё, что нужно — аккуратно запрограммировать ОДНУ икону. Только ОДНУ! Когда будем программировать другую — про предыдущую уже можно не вспоминать.

                        Это равносильно утвеждению "нужно аккуратно запрограммировать один модуль, когда будем программировать другой — про предыдущий можно не вспоминать". Работает в любом языке программирования.


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

                      +2
                      Это скорее следствие не из того, что алгоритм был переписан на ДРАКОН, а из того, что он в принципе был переписан
                        +1

                        Давайте так: предлагаю написать вам на Драконе, например, верифицированную функцию сортировки списков слиянием вместе с доказательством корректности, а потом сравним с реализацией (и доказательством) на других языках. Согласны?

                          +2
                          Это на любом языке, кроме Агды, Кога, Пролога и Окамла будет аццкий трэш. У меня даже есть ощущение, что для С или Java придётся сначала написать интерпретатор агды.
                            +2

                            Правильное ощущение.


                            Но я же не сказал, что «на любом другом языке».

                              0
                              Вы уж очень своеобразную задачу выбрали. Это как потребовать переписать v-usb, чтобы требования по флешу и оперативке выросли менее, чем вдвое. Насколько я помню, при переписывании на чистом С (оригинал в основном на асме) требование не выполняется.
                                +3

                                Она, может, и своеобразная, но в рамках топика. Человек спрашивает про написание безошибочных алгоритмов — вот способ¹ писать безошибочные алгоритмы на текстовых языках, а человеку возвращается вопрос о том, как это будет выглядеть на Драконе.


                                Впрочем, интересно, что на предложение проверить язык конкретной задачей Parondzhanov как-то никак не отреагировал. Начинаю склоняться к мысли, что это действительно какое-то инфоцыганство.


                                ¹ Где под ошибкой мы понимаем несоответствия спеке.

                                  +1
                                  Я понятия не имею, что там под капотом, но теоретически можно оттранслировать блок-схему в КА, это даже проще, чем перегнать линейный текст в КА, а вот получится ли вогнать туда temporary logic, без которой верифицировать сложновато.
                          –1
                          Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.
                          Функция заработала сразу!

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

                            0
                            Но это редкий случай для профессиональных программистов.
                            Почему же редкий? Сплошь и рядом.
                            Специалисты высочайшей квалификации, которые проектировали алгоритмы БОИНГа 737 МАХ, которые назубок знают синтаксис языка программирования, погубили 346 человек.
                              0
                              Специалисты высочайшей квалификации, которые проектировали алгоритмы БОИНГа 737 МАХ, которые назубок знают синтаксис языка программирования, погубили 346 человек.

                              пожалуйста, перестаньте передергивать — это Вам очков не добавляет

                                +1
                                пожалуйста, перестаньте передергивать — это Вам очков не добавляет
                                Прошу прощения, но я не понял, в чем заключается передергивание.
                                Боинг погиб из-за ошибки в алгоритмах.
                                Кто в этом виноват?

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

                                  никто не отрицает вины разработчика (= компании Боинг)
                                  Речь о том, что пиариться на этом и продвигать свое решение — тупик, потому что ДРАКОН не решает проблему корректности алгоритма в целом. Garbage in — garbage out.


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

                                  заканчивайте, пожалуйста. Ошибаются все, к сожалению.

                                    –1
                                    Боинг погиб из-за ошибки в алгоритмах.

                                    Насколько я помню, были организационные проблемы то ли с ТЗ, то ли с процессом тестирования. Что бы исправил ДРАКОН?

                                      –1
                                      Проблема была с алгоритмами, которые делятся на компьютерные алгоритмы и жизнеритмы, исполняемые людьми.

                                      Алгоритмы находятся внутри компьютеров и выполняются автоматически.

                                      Жизнеритмы описывают поведение людей в разнообразных бизнес-процессах. Нужно иметь и то, и другое. Необходимо тщательно сопрягать алгоритмы и жизнеритмы.

                                      При создании и эксплуатации самолета 737 МАХ понятие «жизнеритмы» охватывает следующую группу процессов:

                                      — внутренние бизнес-процессы фирмы Боинг, описывающие взаимодействие работников различных отделов и подразделений фирмы друг с другом;

                                      — бизнес-процессы, регламентирующие взаимодействие сотрудников фирмы Боинг и Федеральной авиационной администрации FAA;

                                      — бизнес-процессы, описывающие взаимодействие сотрудников Боинга с авиакомпаниями и другими контрагентами;

                                      — бизнес-процессы, регламентирующие обучение и сертификацию пилотов самолета 737 МАХ, в том числе, в критических и нештатных ситуациях полета.

                                      Жесткое требование
                                      Анализ алгоритмов и жизнеритмов должен показывать реальное состояние дел и демонстрировать упущения, ошибки и слабые места.

                                      Это очень жесткое требование. Двойная авария лайнера 737 МАХ показала, что данное требование не выполняется. Алгоритмы и жизнеритмы не позволили заблаговременно выявить и устранить недостатки, допущенные при разработке и эксплуатации самолета 737 МАХ.

                                      ДРАКОН позволяет улучшить обе составляющие: и алгоритмы, и жизнеритмы с помощью единой нотации и (почти) единой математики.
                                        +1
                                        ДРАКОН позволяет улучшить обе составляющие: и алгоритмы, и жизнеритмы.

                                        нет, не может (фейспалм)

                                          0
                                          жизнеритмы…
                                          ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B4%D0%B0%D1%81%D1%82%D0%B5%D1%8F
                                          тоже, кстати, декларировала «улучшение ума»:
                                          Я разработала метод, с помощью которого можно брать дополнительное время и вводить это время себе в мозг и затем этот мозг начинает работать в более ускоренном режиме. Тем самым человек начинает видеть больше, помнить больше, успевать больше.(ц)
                                          +1
                                          ДРАКОН исправляет:
                                          1. Бизнес-процессы (жизнеритмы). В отличие от должностных инструкций, диаграмм BPMN и прочего, ДРАКОН отвечает исполнителю на вопрос: Что конкретно мне делать сейчас?
                                          2. ТЗ. ДРАКОН объясняет, как работает эта хрень.
                                            0

                                            Так это ЯП или религия?
                                            Очередная вещь, решающая всё с точки зрения её адептов, но почему-то напрочь игнорирующая один важнейший аспект программирования, неочевидный для непрограммистов и изучаемый программистами на 2м курсе вуза… Фтопку.

                                              +1

                                              мне кажется, что для начала автору ДРАКОНа надо избавиться от методов и привычек инфоцыган, но, видимо, это настолько спорное решение, что других вариантов популяризировать его нет

                                                –2
                                                «Так это ЯП или религия?»
                                                Это визуальный язык алгоритмов. Математика + эргономика.
                                                  +4

                                                  Эргономика, конечно, дело субъективное, но математики там незаметно.

                                                    0
                                                    А что Вы хотели бы увидеть в? Т.е. что послужит признаком математики где-либо?
                                                      +1

                                                      Для начала — любое формальное описание свойств языка, в идеале — доказательство его непротиворечивости.


                                                      Упомянутые в статье аксиомы-силуэты звучат как какое-то фричество, если честно.

                                                        0
                                                        Упомянутые в статье аксиомы-силуэты звучат как какое-то фричество, если честно
                                                        Сначала уточню. Не «аксиомы-силуэты». В статье говорится про две аксиомы языка ДРАКОН, из которых математически выводится графика любого дракон-алгоритма.

                                                        Они называются «аксиома силуэт» и «аксиома-примитив». Я рад, что вы на них обратили внимание. Спасибо.

                                                        Насчет фричества. Все привыкли, что аксиомы пишут текстом, а не картинками. Так что ваше недоумение понятно.

                                                        Вы заметили явное отступление от укоренившейся традиции. И обратили на это внимание. Это хорошо.

                                                        Тем не менее, это строгая математика. Самая настоящая математика, хотя, конечно, непривычная.

                                                        Если вы заинтересуетесь это новой областью математической логики, я готов вам всячески помогать.
                                                          0

                                                          Матлог — это хорошо. Где можно максимально сжато почитать про соответствующую логическую систему? Хочется что-то в стиле такого описания, если можно — по непонятным словам я потом дальше сам буду гуглить (или спрашивать вас).

                                                            0
                                                            Матлог — это хорошо. Где можно максимально сжато почитать про соответствующую логическую систему? Хочется что-то в стиле такого описания, если можно — по непонятным словам я потом дальше сам буду гуглить (или спрашивать вас).
                                                            Мои данные Паронджанов Владимир Данилович
                                                            Почта vdp2007@bk.ru
                                                            Тел. +7-916-111-57
                                                            Звонить в любое время дня и ночи.

                                                            Поясню аксиоматический метод ДРАКОНа за 2 шага.

                                                            Шаг 1. Теоретическое введение из книги Ершова и Палютина.

                                                            Ершов Ю.Л., Палютин Е.А. Математическая логика. — М.: Наука, 1079. — 320 с. — С.12, 13.

                                                            Основным итогом деятельности в области оснований математики можно считать становление математической логики как самостоятельной математической дисциплины, а принципиальным достижением математической логики — разработку современного аксиоматического метода, который может быть охарактеризован следующими тремя чертами:

                                                            1. Явная формулировка исходных положений (аксиом) той или иной теории.
                                                            2. Явная формулировка логических средств (правил вывода), которые допускаются для последовательного построения (развертывания) этой теории.
                                                            3. Использование искусственно построенных формальных языков для изложения всех положений (теорем) рассматриваемой теории…

                                                            Введение и использование подходящих обозначений было на протяжении всей истории математики весьма важной и продуктвной процедурой…

                                                            Основным объектом изучения в математической логике являются различные исчисления.

                                                            В понятие исчисления входят такие основные компоненты, как:
                                                            а) язык (формальный) исчисления;
                                                            б) аксиомы исчисления;
                                                            в) правила вывода…

                                                            Еще одним замечательным достижением математической логики является нахождение математического определения понятию алгоритма…

                                                            Изучение исчислений составляет синтаксическую часть математической логики…

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

                                                            Шаг 2. Ссылка на мою книгу. См. Глава 32. ИСЧИСЛЕНИЕ ИКОН — НОВЫЙ МЕТОД ПРЕДОТВРАЩЕНИЯ ОШИБОК Стр. 303 и далее.

                                                            Просьба сориентировать меня. Собираетесь ли вы писать и защищать диссертацию на эту тему?
                                                              +3
                                                              Всё, что там сказано — корректную схему по указанным правилам можно преобразовать в другую корректную схему. Аналогия в текстовом программировании — корректный синтаксис программы.

                                                              Но корректная схема (корректный синтаксис) не гарантирует корректного алгоритма, трансляции в корректную программу и соответствия схемы спецификации.
                                                                –1
                                                                Аналогия в текстовом программировании — корректный синтаксис программы.
                                                                Да, аналогия безусловно есть. Тем не менее, мне кажется, что графический синтаксис ДРАКОНа обеспечивает ( своих рамках, т.е. в рамках управляющих конструкций) более полные правила контроля, чем синтаксис текстового языка программирования. Каково ваше мнение?
                                                                  0
                                                                  Каково ваше мнение?

                                                                  Нет, не обеспечивает.

                                                                    +1
                                                                    Синтаксис — это, наверное, наименьшая проблема в программировании. Программа с синтаксической ошибкой просто не скомпилируется, все современные IDE подсвечивают синтаксические ошибки сразу же, не дожидаясь компиляции.
                                                                    Поэтому отказываться от более компактного и легко переносимого отображения кода, удобной отладки, системы управления версиями, возможности работать с текстом программы в любом текстовом редакторе только ради избегания мизерной доли процента синтаксических ошибок — это не самая лучшая идея.
                                                                      0
                                                                      Поэтому отказываться от более компактного и легко переносимого отображения кода, удобной отладки, системы управления версиями, возможности работать с текстом программы в любом текстовом редакторе только ради избегания мизерной доли процента синтаксических ошибок — это не самая лучшая идея.
                                                                      Я понял ваши слова так: да, графический синтаксис ДРАКОНа, действительно обеспечивает в своих рамках более полные правила контроля, но это составляет мизерную долю процента, так что овчинка выделки не стоит.
                                                                      Я правильно понял вашу мысль?
                                                                        0
                                                                        действительно обеспечивает в своих рамках более полные правила контроля,

                                                                        Не обеспечивает и это было доказано выше, но Вы аргументы не воспринимаете (

                                                                          –1
                                                                          Да. Дракон может дать мизерное преимущество в контроле синтаксиса перед написанием программ в обычном текстовом редакторе.
                                                                          Но по сравнению с IDE с подключённым стайлгайдом он и это преимущество теряет напрочь.
                                                                          При этом во всём, что не относится к синтаксису управляющих конструкций, у дракона нет никаких преимуществ, одни недостатки.
                                                                            +1
                                                                            Да. Дракон может дать мизерное преимущество в контроле синтаксиса
                                                                            Вы говорите о текущем состоянии дел.

                                                                            Забудем на минутку о дне сегодняшнем. И поговорим о возможности развития.
                                                                            Мизерное преимущество ДРАКОНа в дополнительном контроле — что это такое?

                                                                            Я понимаю это так. Это значит, что удалось некоторую часть семантики (пусть мизерную) формализовать и перевести из области семантики в область синтаксиса.

                                                                            Если это так, то это означает рождение новой области: преобразовать порцию семантических правил в синтаксические.

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

                                                                            Каково ваше мнение?
                                                                              0
                                                                              Надстройка над языком, заменяющая только управляющие структуры, не сможет повлиять на семантику.
                                                                              Я говорю именно о синтаксических ошибках, например незакрытой фигурной скобке, которые устраняются за счёт автоматической генерации.
                                                                              Ну и, полагаю, при текущей скорости развития раньше появится искусственный интеллект, создающий программы по техническому заданию произвольной формы, чем дракон дорастёт до коммерческого уровня.
                                                                                0
                                                                                Я понимаю это так. Это значит, что удалось некоторую часть семантики (пусть мизерную) формализовать и перевести из области семантики в область синтаксиса.

                                                                                Это, вообще-то, основа любого языка программирования — выражение части семантики через синтаксические элементы.


                                                                                Если это так, то это означает рождение новой области: преобразовать порцию семантических правил в синтаксические.

                                                                                В том-то и дело, что не новой. Это существующая область, которая уже имеет выражение в существующих языках программирования.

                                                                      +1

                                                                      Спасибо за ссылку на книгу и конкретное указание на то, где читать. Ну и что книга вообще доступна публично, это хорошо.


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


                                                                      Вот в логике есть такое понятие, как ложь. В терминах теории типов оно выражается как тип ⊥, имеющий определение, например, ∀x:*.x, где * — сорт (kind) типов (то есть, этот тип говорит, что для любого типа x можно получить значение этого типа — прямое отображение ну очень древнего принципа ex falso quodlibet, который лично для меня, по крайней мере, куда менее интуитивно понятен и приятен, чем теоретико-типовая формулировка). Соответственно, имея терм f типа ⊥, можно получить терм любого типа t (то есть, доказать любое утверждение), просто применив f к t. И, например, одна важная черта всяких умных языков — что терм типа ⊥ получить нельзя (и это можно считать признаком логической консистентности). Так вот, как в Драконе выражаются эти концепции?


                                                                      Просьба сориентировать меня. Собираетесь ли вы писать и защищать диссертацию на эту тему?

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

                                                                        0
                                                                        Вот в логике есть такое понятие, как ложь.
                                                                        Да, истина и ложь (истинность или ложность) или 1 и 0. Это азы.

                                                                        В ДРАКОНе эти понятия имеются и активно используются.

                                                                        Но. ДРАКОН настроен на упрощение терминологии, там, где это возможно.

                                                                        Поэтому в ДРАКОНе слово Истина заменяется на Да, а слово Ложь заменяется на Нет (в подавляющем большинстве случаев).
                                                                        В связи с вашим вопросом (про ложь и истину). Про это написано в той же самой моей книге, но в другом месте — в части 3.
                                                                        Это тоже математическая логика, но это новый раздел матлогики — визуальная математическая логика.

                                                                        Часть 3. Алгоритмическая логика. Математическая логика в алгоритмах. Визуальная алгебра логики

                                                                        Глава 12. Логические операции И, ИЛИ, НЕ
                                                                        Глава 13. Логическая функция И
                                                                        Глава 14. Логическая функция ИЛИ
                                                                        Глава 15. Как удалить логические связки из логических выражений
                                                                        Глава 16. Канонические логические схемы
                                                                        Глава 17. Логическая функция «исключающее ИЛИ»
                                                                        Глава 18. Сложные логические функции
                                                                          +1

                                                                          Вы мне сделали прямо физически больно. Начать с того, что нельзя приравнивать истину или ложь к 1 или 0 по очевидным причинам. Или к «да» и «нет»
                                                                          Далее идёт история, что должен быть способ описания отсутствия чего бы то ни было в языке (None, Null сюда).
                                                                          Нам в целом мысль коллеги 0xd34df00d была намного глубже

                                                                            0
                                                                            нельзя приравнивать истину или ложь к 1 или 0 по очевидным причинам.
                                                                            Я вовсе не приравнивал Истину и Ложь к 1 и 0.
                                                                            С чего вы взяли?
                                                                            Имеется в виду, что в таблицах истинности иногда пишут 1 и 0, а иногда И и Л.

                                                                            В ДРАКОНе в таблицах истинности можно писать Да и Нет. Посмотрите в моей книге Алгоритмы и жизнеритмы Часть 3. Алгоритмическая логика.
                                                                            Там на 70 страницах все это подробно разжевано.

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

                                                                          Предлагаю вам тему диссертации:
                                                                          «Визуальная математическая логика как теоретическая основа визуального алгоритмичческого языка ДРАКОН».

                                                                          Это новое научное направление, диссертация в ученом совете пройдет на ура. Если вам это интересно, я составлю для вас план диссертации.

                                                                          Защищаться вам можно, например:
                                                                          — в Институте системного программирования Российской академии наук;
                                                                          — или на кафедре системного программирования матмеха Санкт-Петербургского университета.


                                                                          Если хотите, я переговорю с руководителями. Подумайте.
                                                              +1

                                                              Где конкретно там математика?

                                                              0
                                                              Так это ЯП или религия?
                                                              Очередная вещь, решающая всё с точки зрения её адептов
                                                              Это некорректное утверждение.
                                                              Я никогда не говорил (и не мог сказать), что ДРАКОН решает все.
                                                              Такие преувеличения можно встретить только у некоторых уважаемых оппонентов, участников нашей дискуссии, которые в отдельных случаях сплошь и рядом приписывают мне якобы сказанные мной различные несообразности.
                                                      –1
                                                      надураконили они бы ровно то же самое.
                                                      впрочем, достаточно посмотреть на уровень тех, кто этим самым дураконом пользуется. Например, на того же упомянутого Ефанова — он же вываливал свой код? Араптанов, который еще смешнее?
                                                      Более того, вы сами надураконили в своей же собственной дуракон-схеме проверки летающей тарелки «полет навстречу взрыву».
                                                      Специалисты высочайшей квалификации, которые проектировали алгоритмы БОИНГа 737 МАХ, которые назубок знают синтаксис языка программирования
                                                      специалистам по проектированию алгоритмов совсем не нужно знать синтаксис языка программирования.
                                                        0
                                                        Специалисты высочайшей квалификации, которые проектировали алгоритмы БОИНГа 737 МАХ, которые назубок знают синтаксис языка программирования, погубили 346 человек.

                                                        Это не опровергает мой тезис о том, что визуальное программирование неудобно и не годится для серьёзного программирования. Конечно, если бы самолёт не был бы создан, то он бы не потерпел крушение!

                                                          0
                                                          Твой тезис — слишком сильное утверждение и потому неверен.

                                                          Как впрочем и обратный от автора статьи про «Дракона-спасителя».
                                                      +1
                                                      Я, когда писал юнит тесты, тоже обнаружил ошибку в работающем коде :) Вывод — переписать любой код или написать на него тесты полезно.
                                                  0

                                                  Главный недостаток: разработчик сильно оторван от практики. Язык выходит оригинальный, местами интересный, но совершенно непрактичный.

                                                    0
                                                    Именно. Особенно все, чему учат сейчас в вузах, уже сильно устаревшее и невостребованное
                                                    +3
                                                    Много эмоций — мало конструктива. По мнению автора, если бы алгоритм коррекции угла атаки был «правильно разработан на Драконе», то он бы не мешал пилотам вручную изменять этот угол. Случилось это с Боингом по банальной причине отставания от Эйрбаса и угрозой потери рынка и прибыли. Вместо переработки планера или переобучения пилотов воткнули систему опробованную на стенде, видимо без комплексных испытаний. По этой же причине выпускают колбасу из сои со вкусом мяса, а не из мяса. Нынешний рынок это давно не про минимизацию соотношения цена-качество, а только про минимизацию цены в широком смысле. Добавьте сюда опережающий маркетинг и получите боинг и ещё кучу контор со всякими костыльными продуктами в разных отраслях. Высший пилотаж это выпустить тот же самый продукт, но с другим шильдиком и продать как принципиально новый в эн раз дороже (кстати самый безопасный вариант).
                                                      +3
                                                      забавно, что некоторое время назад рассказывали (емнип, даже на хабре), что Боинг разрабатывает софт для самолетов именно в визуальщине, поэтому визуальщина это круто и прогрессивно.
                                                        0

                                                        Скорее бы он не создавал нужды в ручном изменении.

                                                          0

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

                                                        +3
                                                        Третий недостаток: отсутствует стандарт языка ДРАКОН
                                                        Безошибочность без стандарта. Отлично.
                                                          +5

                                                          Было бы интересно увидеть программу из тысячи строк в такой блок-схеме? Мне кажется что любому человеку который хотя-бы год программировал, любая программа кажется проще чем такое графическое представление. А вообще в универе очень бесило, когда к лабораторным надо было рисовать эти блок-схемы. И это отнимало в 5 раз больше времени, чем написание кода

                                                            +2

                                                            Из тысячи? Я видел проекты на несколько миллионов строк. Пожалуй, мне даже не интересно увидеть такую блок-схему.


                                                            А вообще в универе очень бесило, когда к лабораторным надо было рисовать эти блок-схемы.

                                                            Кажется, в "Мифическом человеко-месяце" (ЕМНИП) было написано, что блок-схемы устарели ещё в 1960х. Так что, это бесило не только вас, но и несколько предшествующих поколений программистов!

                                                              +1
                                                              Блок схемы могут быть высокоуровневыми — где квадратик это целая процедура (которая может быть написана и текстом), а связи между ними — переходы конечного автомата FSA, также см мой коммент ниже.

                                                              Тогда получается не так громоздко.

                                                              И кстати, FSA на С++ выглядит ужасно, тут на Хабре были статьи с примерами.
                                                                +1

                                                                Высокоуровневые блок-схемы — это классно, и даже иногда работает. Только возникает вопрос причём тут ДРАКОН :-)

                                                                  0
                                                                  Конечно, я всего лишь про идею программ-схем.

                                                                  А что в данной реализации, мне неохота даже спецки смотреть. Есть там вообще вызовы ф-ций или обработки ошибок.
                                                                    +1
                                                                    ДРАКОН — правила рисования блок-схем.
                                                                    Эти правила не случайны. Они составлены так, чтобы выжать максимум из графического представления алгоритмов. Что дают эти правила?
                                                                    1. Легкость восприятия (примеры: запрет на пересечение линий, только прямоугольные манхеттен-графы).
                                                                    2. Единообразие и предсказуемость (примеры: следующий всегда внизу, ветвление всегда идёт вправо).
                                                                      +1
                                                                      Высокоуровневые блок-схемы — это классно, и даже иногда работает. Только возникает вопрос причём тут ДРАКОН
                                                                      При том, что действительно классные высокоуровневые блок-схемы вы сможете создать только на ДРАКОНе, и никак иначе.
                                                                        0
                                                                        При том, что действительно классные высокоуровневые блок-схемы вы сможете создать только на ДРАКОНе, и никак иначе.

                                                                        Неа. Прекрасно можно нарисовать руками.

                                                                          +1
                                                                          Неа. Прекрасно можно нарисовать руками.
                                                                          Вы правы. Руками, конечно, можно нарисовать.
                                                                          Но, скорее всего, получится с ошибкой. А на ДРАКОНе — без ошибок (почти без ошибок).
                                                                            –1
                                                                            Но, скорее всего, получится с ошибкой. А на ДРАКОНе — без ошибок (почти без ошибок).

                                                                            Нет и нет. Нет в ДРАКОНе никакого волшебства, которое защищает от ошибок вида "забыли вариант в перечислении", "записали не в ту переменную" и так далее.

                                                                              0
                                                                              Нет в ДРАКОНе никакого волшебства, которое защищает от ошибок вида «забыли вариант в перечислении»
                                                                              Вы правы, в том смысле, что ДРАКОН не дает 100%-го устранения ошибок. Он устраняет многое, очень многое, но отнюдь не все.

                                                                              Никогда не было сказано, что ДРАКОН дает 100%-ю гарантию. Такой гарантии он, конечно, не дает, и не может дать.
                                                                                –1
                                                                                Никогда не было сказано, что ДРАКОН дает 100%-ю гарантию. Такой гарантии он, конечно, не дает, и не может дать.

                                                                                Тогда не нужно спекулировать на теме Боинга )

                                                                                  0

                                                                                  Какие конкретно ошибки устраняет ДРАКОН?

                                                                            0

                                                                            От того, что вы похвалите блок-схемы Дракона ещё пять раз, они высокоуровневыми не станут.

                                                                              –1
                                                                              Вы правы. Не станут. Потому что они уже высокоуровненвые.
                                                                              И для этого совсем не нужно их хвалить.
                                                                              Но они могут быть и низкоуровневыми.

                                                                              Насчет уровня. Уровень дракон-алгоритмов выбирает разработчик.
                                                                              Если разработчику нужен высокий уровень, он нарисует высокоуровневые дракон-алгоритмы.
                                                                              Если разработчику нужен низкий уровень, он нарисует низкоуровневые .

                                                                              Уровень — это не показатель качества, а степень абстракции, которая нужна разработчику.

                                                                        0
                                                                        меня тоже бесило. А потом выяснилось, что это универсальный язык, который понимают коллеги «южных гор, до северных морей». Соответственно, если рисовать идею на доске на кухне, используешь блок-схему.
                                                                          +1

                                                                          Если. Идея состоит из 10-20 блоков. А если из 50?

                                                                            0
                                                                            вы переоцениваете, как нашу офисную кухню, так и объём идей.
                                                                              0
                                                                              Тогда дракон-схема типа «силуэт». Если больше 50, до декомпозиция, как и везде.
                                                                              +1
                                                                              А потом выяснилось, что это универсальный язык, который понимают коллеги «южных гор, до северных морей».

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

                                                                                0
                                                                                Всё-таки ромбики для ветвления от прямоугольничков для действия отличают, наверное? Мои отличают, во всяком случае.
                                                                                Но важнее, что все универсально понимают и принимают концепцию изображения алгоритма именно в таком виде. Ни у кого не возникает вопроса, что значит стрелочка, что за чем идёт, и что это вообще за фигня, почему не писать на Яве.
                                                                                  0
                                                                                  Всё-таки ромбики для ветвления от прямоугольничков для действия отличают, наверное?

                                                                                  Я сам не всегда отличаю. Если нарисовать прямоугольник вместо ромбика, и написать вопрос, все равно работает.


                                                                                  Но важнее, что все универсально понимают и принимают концепцию изображения алгоритма именно в таком виде.

                                                                                  В виде просто квадратиков и стрелочек? Ну да. Для алгоритмов определенного типа и определенной сложности.


                                                                                  А теперь попробуйте в таком виде описать взаимодействие двух систем, и становится весело. Прямо вот очень весело.

                                                                                    0
                                                                                    Но важнее, что все универсально понимают и принимают концепцию изображения алгоритма именно в таком виде.

                                                                                    Допускаю, что это так. Но зачем обсуждать алгоритмы с теми, кто не может читать код?
                                                                                    И если алгоритмы, которые приходится обсуждать, просты, почему бы в таком случае не обойтись русским языком, без блок-схем?

                                                                                      0
                                                                                      «Но зачем обсуждать алгоритмы с теми, кто не может читать код?»
                                                                                      Потому что те, кто не может читать код, дают деньги на разработку.
                                                                                      «почему бы в таком случае не обойтись русским языком, без блок-схем?»
                                                                                      Просто русский (или английский) не потянет — слишком сложный сейчас софт. Текст приходится структурировать в виде юз-кейсов. Но с юз-кейсами возникает проблема — повторы. И тогда видишь: да, надо было брать ДРАКОН с самого начала.
                                                                              +4
                                                                              IMHO, крайне легко перепутать направления веток «Да» и «Нет». В том же примере с while, запись текстом читается однозначно: пока выполняется условие повторять тело цикла. На графической схеме достаточно поменять ветки и условие цикла сменится на совершенно противоположное. То есть отслеживать нужно уже не один объект (условие), а два — собственно условие и направление выхода стрелок.
                                                                              То же самое и в сложных логических условиях. Когда вниз идёт то «Да», то «Нет» — это лишний повод запутаться.
                                                                              Совершенно неясно, как комментарий после сложного условия страхует от ошибки? Он либо генерируется магическим образом, что маловероятно при написании условий свободным текстом, либо я могу изменить условия забыв изменить комментарий и он, в дальнейшем, будет служить дополнительной точкой генерации ошибок.
                                                                              Непонятен принцип «Чем правее, тем хуже». Почему в примере case ветка 1 лучше, чем ветка 2, а ветка 2 лучше, чем default?
                                                                                –1
                                                                                это вы еще сгенерированный код не видели…
                                                                                насчет «чем правее, тем хуже» — дуракон вырос из переноса систем управления с аналоговых систем на цифровые вычислители. поэтому «хуже» — это какие-то отклонения в идеальном линейном алгоритме, которые надо обрабатывать, реагировать на отклонения.
                                                                                Просто не было в начале 70-х обучения программированию для инженеров, да и сами «эти эвээмы» были штуками страшными и непонятными. Инженеры самостоятельно написать программу для системы управления не могли, переучиваться не хотели, а программисты были редкостью. поэтому возникла вполне здравая на тот момент идея — рисовать нечто вроде блок-схемы, и по ней генерить программу. Правда, всего через 10 лет обучение программированию в профильных ВУЗах стало обязательным, а еще через 5 — и в школах тоже. Но Паронджанов уже уверовал в свою гениальность…
                                                                                Джозеф Фокс, которого Паронджанов цитирует, работал, емнип, до 1977 года. Собственно, и представления о программировании у команды дуракона примерно этих же времен.
                                                                                  0
                                                                                  Rsa97
                                                                                  Непонятен принцип «Чем правее, тем хуже». Почему в примере case ветка 1 лучше, чем ветка 2, а ветка 2 лучше, чем default?

                                                                                  Хаос — источник ошибок.
                                                                                  Во избежание ошибок, алгоритм должен быть упорядоченным

                                                                                  Принцип «Чем правее, тем хуже» позволяет упорядочить:
                                                                                  — макроконструкцию примитив;
                                                                                  — ветку в макроконструкции силуэт.

                                                                                  ЧТО ДЕЛАТЬ, ЕСЛИ ПРИНЦИП
                                                                                  «ЧЕМ ПРАВЕЕ, ТЕМ ХУЖЕ» НЕ РАБОТАЕТ

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

                                                                                  Годятся любые правила, позволяющие сделать схему упорядоченной. Для разных задач могут понадобиться разные правила. Но у всех правил есть общая черта. В схеме должен быть не хаос, а порядок.

                                                                                  Здесь действует правило хорошей хозяйки:
                                                                                  Если поcтараться, порядок всегда можно навести

                                                                                    –1
                                                                                    Смещение вправо от главного маршрута должно быть не произвольным и хаотичным, а продуманным и логичным.

                                                                                    Вы не задумывались о том, что в программе, вообще-то, бывает больше одного "главного маршрута"? И они бывают вполне себе равноправными?

                                                                                      0
                                                                                      Это правда, часто сценарии равноправны.
                                                                                      Правило «чем правее, тем хуже» позволяет выделять неприятные сценарии (например, обрабоку ошибок).
                                                                                      Позволяет, но не заставляет. Если сценарии равноправны, правило не применяем.
                                                                                        0
                                                                                        Если сценарии равноправны, правило не применяем.

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

                                                                                          +1
                                                                                          Да, это верное замечание. Но на практике это не проблема. Если есть throw или error — кидаешь их в правой части схемы и всё.
                                                                                          С другой стороны, ассимметрия довольно часто бывает.
                                                                                            +2
                                                                                            Если есть throw или error — кидаешь их в правой части схемы и всё.

                                                                                            Это как написать. А я спрашиваю, как читать. Мы же о понятности, правда?

                                                                                              0
                                                                                              Вы совершенно правы здесь, не спорю. Говорю только, что на практике это обычно не проблема. Больше того, абсолютная симметрия путей — редкость. Есть всегда какая-то шняга, и она уходи вправо: пустой массив, null, ошибки, ещё что-то.
                                                                                              Но иногда уходить вправо заставляет топология схемы — иначе не сложишь. Тогда да, читатель ожидает проблем, а там всё хорошо. Правило тогда мешает.
                                                                                                +1
                                                                                                Говорю только, что на практике это обычно не проблема.

                                                                                                На практике и чтение (нормально написанного) текстового кода — не проблема.


                                                                                                Правило тогда мешает.

                                                                                                Наглядная демонстрация того, что это правило не так объективно, как вы это пытаетесь показать.

                                                                                  +4
                                                                                  Приведем список исключенных из языка ДРАКОН опасных элементов, обеспечивающих управление вычислительным процессом. Сюда относятся:
                                                                                  — служебные слова goto, break, continue, if, then, else, case, of, switch, while, do, repeat, until, for, foreach, loop, exit, when, last и их аналоги;

                                                                                  Никуда они не исключены. Вы просто заменили слова на стрелки, но делают они ровным счетом то же самое.


                                                                                  А на этой подмене и строится все последующее якобы доказательство.

                                                                                    –2
                                                                                    lair
                                                                                    Никуда они не исключены…
                                                                                    А на этой подмене и строится все последующее якобы доказательство.
                                                                                    Это не так. Они исключены в том смысле, что человек их не видит, не работает с ними и не смотрит на них. Как мы не смотрим на код после компиляции.
                                                                                      +4
                                                                                      Они исключены в том смысле, что человек их не видит, не работает с ними и не смотрит на них

                                                                                      Он работает со стрелочками, которые функционально выполняют то же самое. Вообще то же самое, как хорошо видно на примере с case.


                                                                                      Вы пытаетесь сделать вид, что "катализаторами ошибок" выступают ключевые слова:


                                                                                      С точки зрения языка ДРАКОН, дело обстоит принципиально по-другому. То, что важно и необходимо для Си, язык ДРАКОН рассматривает как лексический и синтаксический мусор, как слова-пустышки и знаки-паразиты, как бессмысленные, ненужные и вредные элементы, которые подлежат изъятию и удалению. Потому что они являются катализаторами ошибок.

                                                                                      Но это утверждение ничем не подтверждено. Катализатором ошибок, на самом деле, выступает управляющая конструкция (само ветвление, которое увеличивает цикломатическую сложность), а выражено оно ключевым словом switch или набором стрелок — не принципиально.

                                                                                      +1
                                                                                      Делают то же самое, но выглядят иначе. Читать легче.
                                                                                      Кстати, вместо стрелок в ДРАКОНе прямые чистые линии. Стрелка в ДРАКОНе — это знак цикла.
                                                                                        +1
                                                                                        Читать легче.

                                                                                        Это утверждение нуждается в формализации и доказательстве.

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

                                                                                            Да нет, мне не интересно. Это ваше утверждение, вам его и доказывать.


                                                                                            А ваш "личный опыт" — это штука эфемерная. Вот в моем личном опыте читать текст легче, чем картинки смотреть.


                                                                                            А вот с формальным обоснованием «лёгкости» всё в порядке. В основе ДРАКОНа лежат объективные правила эргономики. «Объективные» — значит не важно, нравятся они вам лично или нет, знаете вы о них или нет. Работают и всё.

                                                                                            Пожалуйста, ссылку на конкретное исследование.


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

                                                                                            Муа-ха-ха. Все эти примеры (даже если они верны) говорят только о том, как сделать диаграмму, которая читается лучше другой диаграммы (при прочих равных). Но они ничего не говорят о том, что диаграмма читается лучше, чем не диаграмма.


                                                                                            Ну и да, вы вот говорите, что правило "чем правее, тем хуже" — объективное, а недавно говорили, что его можно не применять. Это, как бы, противоречие.

                                                                                              –3
                                                                                              «диаграмма читается лучше, чем не диаграмма» — это известная вещь, старая проблема.
                                                                                              Если вкратце: на диаграмме можно пальцем (взглядом) проследить путь через алгоритм.
                                                                                              А в тексте есть проблема ёлочки из скобок (или ёлочки выравнивания, если питон): куда переходить, когда скобка закрыта?
                                                                                              image
                                                                                              «Пожалуйста, ссылку на конкретное исследование.»
                                                                                              Ищите сами. Автор статьи даёт знания. Нужны вам эти знания или нет — это ваше личное решение.
                                                                                                +1
                                                                                                Если вкратце: на диаграмме можно пальцем (взглядом) проследить путь через алгоритм.

                                                                                                Нельзя. Потому что мы приходим к выбору, который надо помнить.


                                                                                                А в тексте есть проблема ёлочки из скобок (или ёлочки выравнивания, если питон): куда переходить, когда скобка закрыта?

                                                                                                У вас слева даже полосочка есть, которая отвечает на ваш вопрос.


                                                                                                Ищите сами. Автор статьи даёт знания.

                                                                                                Нет, он дает не знания. Он дает голословные утверждения, которым предлагается верить.

                                                                                      +4

                                                                                      В алгоритме летающей тарелки ошибка: если левый двигатель готов, то правый даже не проверяется. Боинг на ДРАКОНе точно так же уткнулся носом в землю...

                                                                                        0
                                                                                        В алгоритме летающей тарелки ошибка: если левый двигатель готов, то правый даже не проверяется.
                                                                                        Если левый двигатель в норме, то мы включаем плазменный реактор. Так и должно быть. Здесь нет никакой ошибки.
                                                                                          0

                                                                                          И что, летим на одном двигателе?

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

                                                                                            А тут летающая тарелка.
                                                                                              0

                                                                                              Не знал, спасибо. Вопрос снимаю:)

                                                                                        +7
                                                                                        Демагогия и подмена понятий.

                                                                                        1. Боинг не имеет никакого отношения к Дракону. Используется прием из известной теоремы, что крокодил более длинный чем зеленый.

                                                                                        2. Дракон не более безопасный, а может даже и менее. Фактов и доказательств нет.

                                                                                        3. Графические языки давно известны и применяются в промышленности. Но, собственно, они удобны далеко не для всех задач. IEC 61131, Siemens SFC.
                                                                                          +4
                                                                                          Текстовое программирование имеет принципиальный дефект. Оно не способно обеспечить безошибочность программных продуктов.
                                                                                          Для текстового программирования безошибочность — это непосильная задача и недостижимая цель.

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

                                                                                            –5
                                                                                            lair
                                                                                            Это громкое утверждение нуждается в формализации и доказательстве. Или хотя бы, внезапно, доказательстве возможности его доказательства или опровержения.
                                                                                            Сергей, формально вы правы. Вопрос дискуссионный.
                                                                                            Но. Погибли 346 человек. Они погибли в результате ошибок разработчиков фирмы Боинг.

                                                                                            На Боинге работают специалисты высочайшей квалификации, которые знакомы со всеми последними достижениями в области ИТ.
                                                                                            Эта ошибка говорит не только о частном случае — промахе Боинга. Она говорит об общем уровне ИТ-отрасли.
                                                                                              +5
                                                                                              На Боинге работают специалисты высочайшей квалификации, которые знакомы со всеми последними достижениями в области ИТ.

                                                                                              Это утверждение нуждается в доказательстве.


                                                                                              Она говорит об общем уровне ИТ-отрасли.

                                                                                              Но ничего не говорит о возможностях и невозможностях текстового программирования.


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

                                                                                                –2
                                                                                                Но ничего не говорит о возможностях и невозможностях текстового программирования.
                                                                                                Не могу согласиться. Современное программирование — это текстовое программирование. Ошибки характеризуют уровень современного текстового программирования.
                                                                                                Нехорошо.
                                                                                                В рамках комментария невозможно изложить аргументацию. Если Вам интересны мои обоснования, в конце статьи перечислены мои (и не только мои) книги и статьи.
                                                                                                  +1
                                                                                                  Ошибки характеризуют уровень современного текстового программирования.

                                                                                                  Уровень — возможно. Принципиальные ограничения — нет.


                                                                                                  Если Вам интересны мои обоснования, в конце статьи перечислены мои (и не только мои) книги и статьи.

                                                                                                  Они не являются обоснованием вашего мнения. Почему? Обратитесь к Laurent Bossavit, "The Leprechauns of Software Engineering", 2015, там это подробно изложено.

                                                                                              +2

                                                                                              Доказательство возможности его опровержения есть, и оно конструктивно, ЕВПОЧЯ.


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

                                                                                                0

                                                                                                Это же прекрасно.

                                                                                              +3

                                                                                              Как всегда забыли, что алгоритм и реализация алгоритма это не одно и тоже. Боинги упали из-за ошибки алгоритмиста или программиста?
                                                                                              Плюс рекурсивные алгоритмы, плюс динамическое программирование. Кмк этот "дракон" уже не полетит.

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

                                                                                                Если конечно имелось в виду не это динамическое программирование?
                                                                                                  0

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

                                                                                                    0
                                                                                                    Вообще то не утверждает, и в статье есть пример цикла While.

                                                                                                    Кстати, для рекурсии, да и вообще для любой высокоуровневой движухи, нужен достаточно продвинутый механизм вызова функций.

                                                                                                    Ой, а если еще вспомнить про обработку ошибок, вообще Мрак получится (это так дракона звали в одной книге)
                                                                                                0
                                                                                                Все это хорошо для мелких простых примеров. Стоит ввести рекурсию и доказать уже ничего не получится.
                                                                                                  +5

                                                                                                  Я тут посмотрел внимательнее на пример из статьи. Да, вот на этот:


                                                                                                  Проверка летающей тарелки


                                                                                                  И что я там вижу? Что для перехода снизу наверх надо запомнить название узла. Т.е. не пройти глазами по стрелочке, а именно запомнить.


                                                                                                  Ну то есть вот смотрим, крайняя левая схема, последнее ветвление, "тарелка взорвалась?" Предположим, что да. Мы попадаем на узел "ремонт летающей тарелки". Ок. А теперь идем от него по стрелке… и попадаем к выбору из трех узлов ("проверка...", "ремонт...", "пробный полет..."). Хотя этот переход, казалось, бы, должен быть однозначен.


                                                                                                  Или я фундаментально не понимаю, как читать эту схему (и ничего не надо запоминать), или это совсем не "гарантированное отсутствие ошибок", потому что человеку надо запомнить и сопоставить, а это процесс, в котором заведомо возможна ошибка.


                                                                                                  (аналогичные замечания можно высказать и по поводу "установить/снять признак", потому что нет никакого визуального подтверждения, что признак один и тот же, исключительно через память читателя)

                                                                                                    +2
                                                                                                    — Левый двигатель в норме?
                                                                                                    — Нет -> правый двигатель в норме?
                                                                                                    — Да -> Включить плазменный реактор.

                                                                                                    Отлично. То есть, если левый двигатель в норме, то правый двигатель никогда не проверяется! Да и зачем его проверять, ведь гораздо важнее взлететь, а там уж как пойдёт.
                                                                                                    — Чеклист?
                                                                                                    — Нет, не слышал!

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

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

                                                                                                      Ещё такие блок схемы ломают концепцию чек листов — Вы правы.
                                                                                                      Я просто для СД делал такие блок схемы. Представляете себе?
                                                                                                      Предположим, надо сделать три проверки (проверка левого, проверка правого, проверка фотонного двигателя). У нас один вход у алгоритма проверки и 2^3 промежуточных состояний, описывающих что может быть необходимо сделать для ремонта/диагностики. В результате блок-схема получается целиком состоящая из абсолютно однотипных кусков, сделанных копипастом. Для себя же сделал вывод, что если порядок проверки не важен — лучше выносить для исполнителей узлы такой таблицы состояний в подалгоритмы.

                                                                                                        0
                                                                                                        Хотелось бы комментариев, как язык помогает искать подобные логические ошибки

                                                                                                        Я искренне думаю, что никак. Так же, как он не позволяет искать ошибки вида "присвоения не в ту переменную", "пропущенный вариант в switch" и так далее.

                                                                                                          –1
                                                                                                          ссылку дать, к сожалению, не могу, но заявлялось, что «верификация алгоритма осуществляется человеком путем тщательного просматривания шампур-схемы»
                                                                                                            +2

                                                                                                            А для текстово-ориентированных языков верификация осуществляется путем тщательного просматривания текста программы.

                                                                                                              0
                                                                                                              Не всегда. Есть статические анализаторы кода. Есть хотя бы синтаксический анализ.
                                                                                                                0

                                                                                                                Казалось бы, это должно намекать, что код надежнее, чем шампур-схема.

                                                                                                                  –1
                                                                                                                  Надежнее, наверное, не сам код как таковой — просто есть более надежные способы контроля кода: автоматизированные, формализованные.
                                                                                                                  Это же касается и создания: современные текстовые IDE позволяют работать быстрее, с меньшим количеством ошибок.
                                                                                                                  На уровне 1960-х (и самого начала 70-х)- возможно, надежность была бы сравнимой.
                                                                                                                    +1
                                                                                                                    Так же, как он не позволяет искать ошибки вида «присвоения не в ту переменную», «пропущенный вариант в switch» и так далее.
                                                                                                                    Присвоение «не туда» и подобные ошибки копи-пасты, прекрасно видны в LAD Cross-Reference.
                                                                                                                    Пропущенный switch не ловится, как и прочие логические ошибки в любом представлении.

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

                                                                                                                    Да стоит подумать, зачем вообще изобрели UML?
                                                                                                                      +1
                                                                                                                      Хотелось бы комментариев, как язык помогает искать подобные логические ошибки.

                                                                                                                      [...]


                                                                                                                      Пропущенный switch не ловится, как и прочие логические ошибки в любом представлении.

                                                                                                                      Done.

                                                                                                                        –1
                                                                                                                        Давай, лови пропущенный case 'c'
                                                                                                                        switch(c) {
                                                                                                                        case 'a':  i = 1; break;
                                                                                                                        case 'b':  i = 2; break; 
                                                                                                                        default: i = 42;
                                                                                                                        }
                                                                                                                          +1

                                                                                                                          А при чем тут это? Я говорил, что представление Дракона не помогает найти такие ошибки, вот и все.

                                                                                                                            0
                                                                                                                            Тогда я просто не понял done в предыдущем комментарии
                                                                                                                              0

                                                                                                                              Ну как: один человек спрашивает, "как язык [Дракон] помогает искать подобные логические ошибки". Вы пишете, что "[некая ошибка] не ловится, как и прочие логические ошибки". По-моему, второе прекрасно отвечает на первое.

                                                                                                                                0
                                                                                                                                Забыл про «в любом представлении». Что даркон, что текстовые ЯП тут в равных положениях.
                                                                                                                                  +2

                                                                                                                                  С этим я и не спорю — в равных. В равных, а не "ДРАКОН лучше", как нам пытается навязать статья.

                                                                                                          0

                                                                                                          Или вот еще один вопрос к этой же диаграмме. А почему, собственно, в ней три "ветки", а не один "шампур"? Просто поместим "пробный полет" под крайним левым (он же основной), а ремонт — под соответствующим "адресом". Структура алгоритма таким образом будет виднее (в частности, будет видно, что пробный полет состоится всегда).


                                                                                                          Так по какому же формальному критерию можно сказать, что так, как на диаграмме — лучше?

                                                                                                          +3

                                                                                                          Тезис «неверный алгоритм — вовсе не алгоритм» не выдерживает критики. Аналогия с доказательством ложная. Действительно, неверное доказательство не является док-вом скорее всего вовсе. Но вот алгоритм как последовательность действий неверным быть в этом смысле не может. Неверный алгоритм — это ТОЖЕ алгоритм, только делающий вовсе не то, что от него ожидают. Подразумеваем, что мы не собрали синтаксически или логически неверный конструкт (в этом нас страхуют наши нынешние инструментальные средства).


                                                                                                          Ну, и так далее. Вся статья — субъективщина, причём любая.
                                                                                                          Рисование алгоритмов в виде блок-схем — это вообще пахнет 70-ми годами. Текстовая репрезентация победила. Там где нужно — мы всегда по тексту можем сгенерировать визуализацию в виде диаграмм

                                                                                                            +1
                                                                                                            Текстовая репрезентация победила. Там где нужно — мы всегда по тексту можем сгенерировать визуализацию в виде диаграмм
                                                                                                            Вы правы. Так все и делают.
                                                                                                            И получают ошибки. Много ошибок.
                                                                                                            Это увеличивает сроки тестирования и отладки. И иногда приводит к серьезным инцидентам, как с Боингом.
                                                                                                            Такое положение является неприемлемым.
                                                                                                              –2

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

                                                                                                                0
                                                                                                                И коли говорить о концепциях, то если уж переходить, то на концепции ФП и автоматного программирования.
                                                                                                                Ради Бога. ДРАКОН поддерживает и ФП, и автоматное программирование.
                                                                                                                Вот что сказано в статье (повторяю).

                                                                                                                Автоматное программирование на языке ДРАКОН
                                                                                                                Алгоритмическая макроконструкция силуэт представляет собой конечный автомат и способна работать в двух режимах:
                                                                                                                — императивное программирование;
                                                                                                                — автоматное программирование.

                                                                                                                Смотри статью Автоматное программирование на языке ДРАКОН.

                                                                                                                Дракон не выживет и по причине того, что он не умеет во чтобы то ни было, кроме императивной парадигмы. Где ООП? Где ФП?
                                                                                                                Нет вопросов. Все учтено могучим ураганом. В статье описана концепция гибридных языков и Семейство ДРАКОН-языков.
                                                                                                                Вот ссылка: Stepan Mitkin на конфереции Erlang User Conference в Швеции делает доклад по гибридному языку Дракон-Erlang.
                                                                                                                youtu.be/yZLedcnFA94
                                                                                                                  0
                                                                                                                  Ради Бога. ДРАКОН поддерживает и ФП, и автоматное программирование.

                                                                                                                  Вы вообще знаете что такое ФП?

                                                                                                                    0
                                                                                                                    А ты вообще знаешь, что такое Эрланг, или не дочитал до конца? =)

                                                                                                                    Вообще ФП имеет малую область применения, и там где подходит Дракон и подобные, ФП КМК не подходит.
                                                                                                                      0

                                                                                                                      Знаю, знаю, но представить вменяемый гибрид дракона и Эрланга всё равно не получается.

                                                                                                                        0
                                                                                                                        Я видел и вполне себе представляю себе в теории, но на практике проблема чистоты.

                                                                                                                        В общем — конечный автомат, узлы которого — чистые функции.
                                                                                                                      –1
                                                                                                                      Функциональное программирование и ДРАКОН не противоречат друг другу. Наоборот, писать на функциональных языках (или в функциональном стиле) при помощи ДРАКОНа очень даже приколько.