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

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


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


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


Исходя из этого, логично было бы составлять алгоритмы в графическом виде. Посмотрите на инженеров. Они повсеместно используют чертежи. Чем же программисты хуже? Они тоже могли бы составлять чертежи алгоритмов. Некоторые здесь возразят: визуальное программирование якобы неэффективно. UML неудобен, а в блок-схемах легко запутаться. Уж лучше программировать традиционным способом — текстом. В структурном программировании есть хотя бы структура, и она обеспечивает порядок и единообразие. А кроме того, рисовать диаграммы долго и трудно. Печатать быстрее, чем рисовать.


Так что же, программисты обречены всю жизнь работать только с текстом?
Возможно, не всё так плохо. Существуют визуальные языки для представления алгоритмов, в которых тоже есть порядок и структура, например ДРАКОН, BPMN и LML Action Diagrams. Здесь мы рассмотрим визуальный алгоритмический язык ДРАКОН.


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


ДРАКОН не является самостоятельным языком программирования. Он работает в паре с текстовым языком, например, с JavaScript, Python или C++. Вместе с текстовым языком, ДРАКОН образует гибридный язык: ДРАКОН-JavaScript, ДРАКОН-Python или ДРАКОН-C++.


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


  1. Рисуем ДРАКОН-схему.
  2. Внутрь икон помещаем небольшие кусочки кода на соответствующем языке программирования.
  3. Программа-транслятор преобразует ДРАКОН-схему в текстовый файл с исходным кодом.
  4. Этот текстовый файл включается в проект обычным образом.
    Генерацию кода из диаграмм на сегодняшний день поддерживают несколько редакторов. Примеры в данной статье сделаны в DRAKON Editor.

Генерация кода из диаграммы


В диаграмме ДРАКОН берёт на себя управление потоком выполнения. Поэтому кусочки исходного кода в иконах не должны содержать ключевых слов типа if, else, switch, case, for, while и т. п.


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


Также не рекомендуется применять логические выражения: and, or, not. Их тоже изображают средствами ДРАКОНа.


Генерация кода происходит следующим образом:


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

На рис. 1 представлен пример небольшой диаграммы на гибридном языке ДРАКОН-JavaScript и сгенерированный код на JavaScript:


Прямоугольник с текстом console.log(cat, dog) на рис. 1 — это икона «Действие». Сколько кода можно поместить в одну икону «Действие»? Следует стремиться к тому, чтобы в одной иконе содержалась одна мысль. Иногда это одна строка кода, иногда несколько.
Сгенерированный код снабжён комментариями, в которых указаны номера икон. Находясь в редакторе, можно быстро перескочить к любой иконе, нажав Ctrl+I.


image
Рис 1. Диаграмма на ДРАКОН-JavaScript и сгенерированный из неё код.

Икона «Вопрос»


Для ветвления применяются иконы «Вопрос» и «Выбор».


Икона «Вопрос» (рис. 2) соответствует конструкции if-then-else.


Обратите внимание, что вместо слов true и false используются слова Да и Нет (можно переключить на Yes и No).


«Истина» и «ложь» — это звучит эффектно, по-учёному. Однако человеку ближе знакомые с раннего детства «да» и «нет».


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


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


image
Рис 2. Икона «Вопрос»

Визуальные логические формулы


Язык ДРАКОН делает ненужными логические операторы И, ИЛИ и НЕ, а также оператор «не равно». Сами логические операции, конечно, необходимы. Но вместо текстовых операторов ДРАКОН вводит визуальные логические формулы.


Чтобы получить визуальную логическую формулу, следует соединить несколько икон «Вопрос» (как на рис. 3).


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


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


image
Рис 3. Визуальные логические формулы

Цикл со стрелкой


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


Итак, если соединить икону «Вопрос» со стрелкой, получится цикл. Это аналог конструкций while и do-while. На рисунке 4 показаны несколько видов циклов со стрелками.
Икона «Вопрос» в цикле со стрелкой проверяет условие выхода из цикла. Конечно, вместо одной иконы «Вопрос» может быть несколько. Тогда за выход из цикла отвечает визуальная логическая формула.


image
Рис 4. Стрелочные циклы

Икона «Выбор»


Икона «Вопрос» содержит логическое выражение, то есть может принимать два значения: Да и Нет. Типичный пример — сравнение двух объектов. Если же нужно сравнить некое выражение с несколькими значениями, применяется икона «Выбор» (рис. 5). Это соответствует конструкции witch-case.


Значения, с которыми будет сравниваться выражение в иконе «Выбор», помещаются в иконы «Вариант». Если в самом правом варианте нет текста, это означает «все остальные значения». Такой пустой вариант похож на ключевое слово default внутри оператора switch.
Самый правый вариант может окончиться стрелкой, которая ведёт вверх. В таком случае мы опять имеем дело со стрелочным циклом. В таком цикле за условие выхода будет отвечать икона «Выбор», а не «Вопрос».


image
Рис 5. Икона «Выбор» и иконы «Вариант»

Икона «Цикл ДЛЯ»


Вместо циклов for и foreach в ДРАКОН-JavaScript применяется икона «Цикл ДЛЯ». Икона «Цикл ДЛЯ» (рис. 6) может быть нескольких видов.


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


Если после ключевого слова foreach стоят две переменные, DRAKON Editor поймёт, что требуется итерация по свойствам объекта (записям хэш-таблицы). Только собственные свойства объектов попадут в перечисление.


Третий вариант цикла подразумевает наличие трёх выражений, разделённых точками с запятой. Это традиционный цикл for, характерный для языков C и Java.


Из цикла под управлением иконы «Цикл ДЛЯ» возможен досрочный выход при помощи иконы «Вопрос» или «Выбор». Такой выход примерно соответствует ключевому слову break.


image
Рис 6. Различные виды иконы «Цикл ДЛЯ» в ДРАКОН-JavaScript

Только один вход в цикл


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


Несколько выходов из цикла — это допустимо, но вход должен быть только один. На рис. 7 показаны циклы, у которых есть по два выхода. Это разрешено. На рис. 8 представлены примеры запрещённых циклов. Запрещённых потому, что в них можно войти разными путями.
Однако не стоит заучивать наизусть внешний вид этих запрещённых циклов. DRAKON Editor автоматически обнаружит такие циклы и выдаст ошибку.


image
Рис 7. Разрешённые циклы, у которых по два выхода

image
Рис 8. Запрещённые циклы, у которых по два входа

Отличия от текстового структурного программирования


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


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


image
Рис 9. Алгоритм, который трудно изобразить только текстом

Преимущества графического языка


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


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


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


Во-вторых, путь через алгоритм можно проследить пальцем (или взглядом). После if не нужно искать else. Идите по линии и попадёте в нужный квадратик. Не требуется бегать глазами по исходному коду в поисках ответа на вопрос: что же было дальше?


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


Особые эргономические правила


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


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

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


Диаграммы на рис. 10 и 11 демонстрируют эргономические приёмы языка ДРАКОН на реальных примерах.


image
Рис 10. Эргономические приёмы языка ДРАКОН на примере

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

Чем правее, тем хуже


ДРАКОН имеет средство для изображения happy path, или царской дороги. Царская дорога — это наиболее удачный путь через алгоритм. В некоторых алгоритмах понятия «удачный/неудачный», «хороший/плохой» не применимы. В них царская дорога показывает наиболее ожидаемый путь. Царская дорога проходит по вертикали, расположенной в левой части диаграммы. Эта вертикаль называется шампур. Менее вероятные и менее удачные сценарии, а также обработка ошибок помещаются в правой части диаграммы. Причём чем ситуация хуже, тем правее она должна быть расположена. Хорошим стилем является размещение кода, который бросает исключения или возвращает код ошибки, справа на диаграмме.


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


Общая судьба


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


Рис. 12 показывает шампур с царской дорогой, а также применение приёма «общая судьба».


image
Рис 12. Царская дорога и общая судьба

Силуэт


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


Силуэт состоит из нескольких малых диаграмм, соединённых в один целостный блок. Эти малые диаграммы называются ветками силуэта. Наверху каждой ветки расположена икона «Шапка ветки», внизу — икона «Адрес». В шапке ветки помещают название данной ветки, а в адресе указывают название следующей ветки. Названия веток расположены на одной горизонтальной линии в верхней части диаграммы. Благодаря этому, можно ухватить суть алгоритма, пробежав лишь по шапкам веток. Силуэт отвечает на три царских вопроса:


  1. Как называется проблема?
  2. Из скольких частей она состоит?
  3. Как называются эти части?

Рассмотрим пример на рис. 13. Вот ответы на царские вопросы:


  1. Как называется проблема? Упорядочить связанный список.
  2. Из скольких частей она состоит? Из четырёх.
  3. Как называются эти части? Построить матрицу связей. Проверить наличие циклов. Пройтись по матрице связей. Завершить.

image
Рис 13. ДРАКОН-схема «силуэт»


Силуэтный цикл


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


image
Рис 14. Силуэтный цикл и метки

Соединение веток силуэта запрещено


Соединения двух веток силуэта (как на рис. 15) запрещены. Каждая ветка внутри силуэта должна быть самостоятельной.


image
Рис 15. Соединение веток силуэта запрещено.

Размер диаграмм


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


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


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


Рассмотрим основные направления критики программирования на ДРАКОНе и попытаемся дать на них ответ.


  • «ДРАКОН-схемы занимают больше места на экране, чем текстовые программы.» Это правда. Но надо иметь в виду, что задача ДРАКОНа — показать сложность, как она есть. Читатель программы не должен распаковывать в голове сложные структуры. Они должны быть показаны ему в явном виде.
  • «Простые алгоритмы лучше смотрятся в текстовом виде». Возможно. Hello world на любом языке смотрится элегантно. Но в реальной жизни не всё просто. Как только появляется хотя бы один if, вложенный в другой if, ДРАКОН выигрывает.
  • «ДРАКОН не имеет средств для отображения исключений (exceptions).» Такая проблема есть. Исключения были недавно добавлены в язык ДРАКОН, но не все реализации их поддерживают. Пока реализации не подоспели, можно писать блоки try/catch на соответствующем языке программирования.
  • «ДРАКОН-схемы долго рисовать.» В специализированных редакторах рисовать ДРАКОН-схемы гораздо легче, чем, например, в Visio. А в некоторых из них рисовать стало почти так же просто, как писать.
  • «Отсутствует инструменты для diff и merge.» Это, к сожалению, так. При работе с системой контроля версий сравнивать приходится сгенерированные исходные файлы.
  • «Отсутствуют средства отладки ДРАКОН-схем.» Это правда. Но можно отлаживать сгенерированный код. В нём есть метки, которые указывают, к какому месту в диаграмме относится данный кусок кода.

Обзор языка дракон


На рисунке 16 представлен обзор языка ДРАКОН.


image
Рис 16. Обзор языка ДРАКОН

Инструменты для работы с языком дракон


Самой первой реализацией языка ДРАКОН была система ГРАФИТ-ФЛОКС (рис. 17). ГРАФИТ-ФЛОКС создавалась в 1986-1996 гг. специалистами ФГУП НПЦ АП им. Пилюгина под руководством В.Д. Паронджанова. Эта среда предназначалась для проектирования систем управления ракет-носителей и космических аппаратов.


ГРАФИТ-ФЛОКС — закрытая разработка, поэтому о ней известно относительно немного. Список космических аппаратов, созданных с применением ГРАФИТ-ФЛОКС, можно посмотреть здесь.


В начале 90-х годов был создан ещё один ДРАКОН-редактор. Разработка велась в Институте прикладной математики имени М.В. Келдыша под руководством Л.К. Эйсымонта. Редактор Эйсымонта (рис. 18) можно скачать и запустить, но он более не поддерживается. Редактор написан под MS DOS, поэтому для запуска на современных компьютерах может потребоваться DOSBox.


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


DRAKON Editor — ещё один современный ДРАКОН-редактор (рис. 20). DRAKON Editor был разработан группой энтузиастов под руководством Степана Митькина. DRAKON Editor не поддерживает исчисление икон. Это означает, что ДРАКОН-схемы собираются в нём вручную из примитивов, как в векторных графических редакторах. Но зато интерфейс пользователя в DRAKON Editor максимально прост. Он построен по более привычной схеме, чем ИС Дракон. Основным преимуществом среды DRAKON Editor является удобство программирования и генерации кода. DRAKON Editor поддерживает несколько языков программирования, включая C, C++, C#, Java, Processing, JavaScript, Lua, Erlang, Python, Tcl, Verilog, AutoHotkey, D и Go. Для некоторых языков имеется возможность генерировать конечные автоматы. Поддерживаются правила для экспертной системы nools. Реализовано подмножество языка УТОПИСТ Э. Тыугу. DRAKON Editor имеет открытый исходный код.


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


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


image
Рис 17. ДРАКОН-схема в системе ГРАФИТ-ФЛОКС

image
Рис 18. ДРАКОН-редактор Эйсымонта

image
Рис 19. Программа с пояснениями в ИС Дракон

image
Рис 20. DRAKON Editor

Выводы


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


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


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


Список литературы


Есть, что почитать
  1. Dahl, O. J. Dijkstra, E. W. Hoare, C. A. R. (1972). Structured programming. Academic Press Ltd: London.
  2. Паронджанов, В.Д. Учись писать, читать и понимать алгоритмы. — Москва, ДМК Пресс, 2012.
  3. Кауфман, В.Ш. Языки программирования. Концепции и принципы. — Москва, ДМК Пресс, 2011.
  4. Паронджанов, В.Д. Почему врачи убивают и калечат пациентов или зачем врачу блок-схемы алгоритмов?.. — Москва, ДМК Пресс, 2017.
  5. Lifecycle Modelling Language (LML) specification. 2015. http://www.lifecyclemodeling.org/specification/
  6. Business Process Model and Notation specification, 2011. http://www.omg.org/spec/BPMN/2.0/About-BPMN/
  7. Учим ДРАКОН по примерам. https://drakon-editor.com/docs/examples
  8. Mitkin, S. DRAKON. The Human Revolution in Understanding Programs, 2011. https://drakon-editor.com/files/DRAKON.pdf
  9. Mitkin, S. Visual functional programming with DRAKON-Erlang- Erlang User Conference 2015. https://www.youtube.com/watch?v=yZLedcnFA94
  10. Mitkin, S. DRAKON-Erlang: Visual Functional Programming, 2012. http://drakon-editor.sourceforge.net/drakon-erlang/intro.html
  11. C programming with DRAKON Editor. http://drakon-editor.sourceforge.net/cpp/c.html
  12. Lua programming with DRAKON Editor. http://drakon-editor.sourceforge.net/lua/lua.html
  13. Система ГРАФИТ-ФЛОКС. http://drakon.su/grafit-floks-sistema
  14. Обсуждение системы ГРАФИТ-ФЛОКС http://forum.drakon.su/viewtopic.php?p=43805#p43805
  15. ДРАКОН-редактор Эйсымонта. http://drakon.su/instrumenty/eysymont
  16. ИС Дракон Геннадия Тышова. http://drakon.su/programma_is_drakon
  17. Integrator CodeView Олега Гарипова http://integratorsoft.com/?mo=69503271058&vi=2838242471&w=69503271097
  18. DRAKON Editor Степана Митькина http://drakon-editor.sourceforge.net/
  19. Официальный сайт языка ДРАКОН http://drakon.su/
  20. Форум языка ДРАКОН http://forum.drakon.su/

Поделиться публикацией
Ой, у вас баннер убежал!

Ну, и что?
Реклама
Комментарии 123
  • +7
    Э… мне одному кажется, что это какая-то тупиковая ветвь развития?
    • +6

      Ну, зато там используются иконы.

      • +3
        Имел опыт с подобным (algorithm builder для avr).
        Действительно, сложнее сделать алгоритмическую ошибку. Так что чем выше требуемая надёжность — тем более полезны такие инструменты. Тем более что есть обратный преобразователь (код — диаграмма).
        Если нужны мегабайты исходников в день некритичных к качеству — однозначно не нужно.
        • +3
          Чем выше требования к надежности, тем больше нужно тестов писать. Тесты тоже в этих блок диаграммах?
          • –1
            Для микроконтроллера и тесты «пишутся» в виде железа (стенды).
            Блок-схемы генерируют обычный код. Пишите к нему обычные тесты. Или необычные)
          • 0
            дык может стоит писать код как обычно, а при валидации сгенерить диаграмму и на нее посмотреть?
            • 0
              Почему бы и нет? В статье упоминаются оба подхода.
              • 0
                Диаграмма скорее всего не поместится на экран и ее будет трудно понять.
                У меня богатый опыт рассматривания схем для FPGA — графические схемы очень не просто понимать.
                • 0
                  Я не пользовался ДРАКОН, но думаю что логически законченная диаграмма должна помещаться на экран, т.е. сначала программа пишется очень крупными «мазками», дальше каждый крупный блок «уточняется» и т.д. Собственно говоря я и на С так стараюсь писать, но лень-матушка дает о себе знать и бывает довольно лениво объединять код в функцию в 1-10 строк, вызываемую один раз :(

                  Полагаю, что сравнение схем для FPGA с диаграммами ДРАКОН не совсем корректно, но если заставить себя строго соблюдать правила из ДРАКОН и добавить правило «одного экрана», то будет вполне себе, хотя я схемы для FPGA уже лет 15 не рисовал…
            • +2

              Не, ну как. Для описания простых алгоритмов — положить в печку, ждать 15 минут, достать, посолить — вполне катит. Когда того, кто создаёт алгоритм о программировании знает только из фантастических фильмов. Когда речь идёт о том, чтобы какой-то реальный софт писать — жуткая жуть, конечно.

              • –1
                image
                • 0

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

                  • 0
                    Мне кажется, реальный код скрыт за этими комментариями.
              • +2
                Не переживайте. Ветвь развития действительно абсолютно тупиковая. Эта игрушка устарела 25 лет назад. При сегодняшней насыщенности приложений кодом, такой подход добавлет больше гемороя чем пользы. Из визуальных средств разработки полезными являются средства с более высоким уровнем абстракций: UML, BPMN 2.0. С кодогенерацией там тоже проблем нет.
                • +1

                  Как ни странно, но люди, не имеющие опыта в программировании, но имеющие потребность что-то запрограммировать (и желательно без привлечения специально обученных людей), любят использовать средства графического программирования. Лет 5 назад был популярен ts lab для биржевого трейдинга, rapidminer более-менее распространенный продукт для обработки данных. Забавляет то, что после нескольких лет использования возникают монстры на 1500 прямоугольников и стрелок, и совладать с таким монстром уже становится сложнее, чем научится писать код

                  • 0
                    Прямо про zennoposter рассказал. Визуальное программирование для управления браузером. Используется различными маркетологами в интернате, ищущими бесплатный трафик zennolab.com/ru/products/zennoposter
                    Вот пример простенького шаблона
                    image
                  • –1

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

                    • 0
                      Что вы имеете в виду под «нодовыми системами»? Дайте примеры.
                      • 0

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


                        Примеры:


                        • Cinema 4D c.o.f.f.e.e
                        • Unreal engine blueprints
                        • HiAsm
                    • 0
                      Есть и другие варианты практического графического программирования от народа.
                      1. hiasm.com
                      2. flprog.ru
                    • 0
                      Я правильно понимаю, что это используется исключительно для обучения?

                      Потому как объемный и сложный код в диаграммах… ну это как-то сложно по моему.
                      • 0
                        Если судить по тексту, то он летает.
                        Его основные принципы были заложены ещё самим Дейкстрой. Нынешнюю свою форму ДРАКОН приобрёл в недрах российской космической отрасли. Примечательно то, что правила языка ДРАКОН не возникли случайно. Они были сначала обкатаны в фокус-группах, а потом отточены в реальных космических проектах.
                        • –5
                          По крайней мере теперь стало ясно почему оно так часто летает не туда и тогда, когда нужно…
                          • –6
                            А комментарии у минусующих будут? Потому что у всех этих визуальных штучек есть большая проблема: отслеживание истории и зависимостей. Такие вещи, как grep или «git blame» отсутствуют напрочь.

                            И оп-па: последняя ракета улетает «не туда», потому что кто-то забыл где-то поправить привязку к Байконура. Случайность? Возможно… Но уж очень она характерная…
                            • 0
                              Потому что у всех этих визуальных штучек есть большая проблема: отслеживание истории и зависимостей.

                              С git и grep можно работать и здесь.
                              Но проблема указана правильно.
                              • 0
                                С git и grep можно работать и здесь.
                                Меня больше «git blame» интересует. Он для каждой строки указывает — кто и когда её написал. То есть вы, увидев странную проверку в коде, можете сразу посмотреть на тот changelist, который эту проверку добавил. Иногда, конечно, выясняется, что «странная проверка» появилась как результат работы clang-format'а — но тогда можно отступить на шаг и посмотреть на «git blame» уже там.

                                Главное — нужно просматривать не сотни changelist'ов, а один-два. Очень сильно помогает. Вы говорите, что для ДРАКОНА что-то такое есть. Как оно выглядит и работает-то?
                                • –1
                                  Проблема некоторых программистов, что они видят строки, то есть не очень далеко ушли от кодеров.
                                  Графическое представление алгоритма как раз и нужно для того, что бы наглядно логику алгоритма, то есть более высокий уровень.

                                  Не думаю, что есть готовый инструментарий, но посмотрите на пару-тройку-пятреку-десяток лет назад, сколько было удобный инструментов для JS? Сколько сейчас?
                              • 0
                                нет никаких проблем отследивания зависимостей.

                                Блок-схема (диаграмма итд) — это всего-навсего одно из представлений.
                                Какие проблемы сделать diff?

                                Есть же для xml diff, который не тупо строки сравнивает, а структуру документа, точно так же можно и для этого сделать. Если нужно, конечно
                                • 0
                                  Какие проблемы сделать diff?
                                  Не знаю какие, но «Отсутствует инструменты для diff и merge.» — это цитата из статьи.
                              • –2
                                Как раз российская космонавтика отправляет что нужно и куда нужно в 99% случаев. Вроде бы хабл не был местом для жополизов-хейтеров, как вы-то тут оказались?
                                • –4
                                  Как раз российская космонавтика отправляет что нужно и куда нужно в 99% случаев.
                                  Не в 99% случаев, а, скорее, в 80%. Скажем Протон: 404 запуска, 49 аварий.

                                  Если запускается что-то совершенно новое или радикально изменённое, то это понятно — опыта нет, пока не отработают — аварийность повышена. Как с тем же Фальконом, который взорвался из-за использования экспериментальной процедуры переохлаждения топлива.

                                  У Роскомоса — то что-то неправильно рассчитают, то временной интервал заузят, то скрытую проблему в алгоритме обнаружат.

                                  А ведь все эти рассчёты — это как раз и есть сфера применения суперклассного, высоконадёжного, уникального ДРАКОНа! Или нет?

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

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

                                  Если ДРАКОН — так удобен и крут, то почему так много ошибок из-за которых происходят аварии, а?
                                  • +1
                                    Окай, 80% успешных запусков поротона это собственно по вашему и является основой для хейтеркого по отношению к роскосмосу, который вы тут демонстрировать пытаетесь, прикрываясь горсткой тех. данных и рассуждений якобы по теме. Я вот например не очень понимаю ценности таких вот «оффтопных вставок» еще и невесть на очем осованных, каких делаете вы, отсюда и мой комментарий.
                                    • –3
                                      Я вот например не очень понимаю ценности таких вот «оффтопных вставок» еще и невесть на очем осованных, каких делаете вы, отсюда и мой комментарий.
                                      Основаны они, вообще-то, на оффициальных данных Роскосмоса.

                                      Я как раз скорее Роскосмос уважаю, однако то, что уж очень много у них «ошибок в алгоритмах» в отчётах я давно для себя отметил.

                                      А тут как раз предлагают их подход к программированию использовать. И сразу возникает вопрос: если хочется экзотики, то, может быть, стоит взять лучше обычный язык программирования (но с более более вменяемым, чем у C#/C++/Java синтаксисом), чем вот это вот чудо?
                                      • 0
                                        Ответ простой — дебажить говнокод обычных языков за охренелиард каждую немножко дорого. А ДРАКОН действительно чудо. В рассматриваемой ситуации с неудачным запуском ничего не программировали, хотя надо было. И именно в этом причина. Человеческий фактор.
                                        • –3
                                          А ДРАКОН действительно чудо.
                                          Тогда почему это «чудо» раз за разом приводит к неправильным вычислениям при запусках?

                                          В рассматриваемой ситуации с неудачным запуском ничего не программировали, хотя надо было.
                                          В рассматриваемой — это в какой? Я там наверху три запуска привёл где алгоритмические ошибки привели к проблемам (со слов соответствующей комиссии, по крайней мере).

                                          Человеческий фактор.
                                          Но если «говнокод обычных языков» более эффективно позволяет с ним бороться — то, может, так и надо?
                                          • 0
                                            Идиотничать пытаешься? Получается успешно у тебя. Сам-то статьи по ссылкам своим читал, осмыслить написанное там старался? Или встретил знакомое слово «алгоритм» и возрадовался?
                                • 0
                                  Так ДРАКОН сейчас и не используется же?
                              • 0
                                Там идея исходная такая — инженер своё понимание работы устройства изображает в виде драконовского кода и передаёт программисту. А программист уже пришет собственно код.
                                А сейчас уже навесили генерацию кода. А я как-то даже написал на яваскрипте самоисполняющийся дракончик. Но из меня программист, как из курицы истребитель, поэтому в общем и целом фигня получилась. Но работала.
                                • +4
                                  фигня получилась. Но работала

                                  Вот как раз этого я и опасаюсь :)
                                  • +2
                                    Успокойтесь, я вам купить не предлагаю. Я попробовал и увидел, что это возможно. Всё.
                                    • 0
                                      Да я и не волновался.
                                  • 0
                                    фигня получилась. Но работала

                                    Грамотный костыль есть архитектурное решение!
                                  • 0

                                    Не только, судя по вики

                                  • –1
                                    Я пользуюсь. Очень удобно. Поэтому мне лично наплевать, тупиковая это ветвь развития или нет.
                                    • 0
                                      Залейте картинки на habrastorage.org
                                      И исправьте SSL у себя на drakon-editor.com
                                      • 0
                                        Рисунок 19 доказывает широко-известный факт, что плохой (ненадежный) код можно написать (нарисовать) в любом языке программирования.
                                        • +4
                                          Узнал об этом языке от одного участника форума компании, в которой работаю.
                                          Привожу ниже 2 алгоритма.
                                          Один я нарисовал блок-схемами в VISIO,
                                          второй нарисовал он на ДРАКОНе.
                                          Получилось настолько проще, понятнее и элегантнее, что я проникся

                                          Под спойлером обе версии алгоритма для сравнения:

                                          Обе версии алгоритма
                                          image

                                          image
                                          • +2
                                            Странно, что слово Scatch не прозвучало.
                                            У меня сыновья с удовольствием развлекаются.
                                            • 0
                                              Можно было бы написать и про графические инженерные языки (FBD, SFC и.т.п.), которые используются повсеместно (сложно найти объект телемеханики, где бы их не было использовано), в отличие от дракона, стандартизированы, имеют кучу компиляторов и реализаций.
                                              • 0
                                                В отличие от дракона большинство программ на FBD или CFC не воспринимаются вообще никак.
                                                Поиск ошибки превращается в ад.
                                                Дабы не быть голословным
                                                image

                                                P.S. Мопед не мой, я просто разместил объяву

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

                                                    Проблему конкретного куска кода из комментария выше можно решить, разбив программу на функции.
                                                    Дракон нас вынуждает делать это разбиение и, тем самым, предотвращает появление «хаотичных» связей.
                                                    Программа выше разработана на CFC и там нет такого «принуждения». Оно есть в FBD, но там нет возможности запретить выполнение блока. Что вынуждает нас «ломать» мировоззрение и строить программы исходя из этого ограничения.
                                                    • 0

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

                                              • +5
                                                Ну а теперь призовая задача: вы сделали в программе изменения, отобразите эти изменения графически (что удалено, что вставлено, что изменено). [Подсказка: две диаграммы рядом не размещать]

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

                                                      Предположите, что изначально блоков P, C и G не было. Вася добавил блоки P и C, Петя — блок G.

                                                      А ваша обьединялка, очевидно, должна породить вот то, что справа — с блоками B1, B2, B3, B4.

                                                      Код (на любом языке, не обязательно Драконе) или хотя бы алгоритм — приветствуются.
                                                    • 0
                                                      Я смотрел на youtube ролики, там человек на ДРАКОНе писал программу для микроконтроллера замка. И ДРАКОН использовался совместно с C. Т.е. структура программы оформлялась на нём, а реализация в блоках (функции из одной-двух строк, работавшие с SDK контроллера) уже на C были. И писались прямо из редактора ДРАКОНа. Ну, а ДРАКОН генерировал финальный исходник на C, конечный автомат и т.д. Так что проблем вроде нет.
                                                      • –1
                                                        С учётом того, что прямо в статье написано:
                                                        «Отсутствует инструменты для diff и merge.» Это, к сожалению, так. При работе с системой контроля версий сравнивать приходится сгенерированные исходные файлы.

                                                        Собственно одна эта проблема замедляет разработку сложных систем на порядк, а то и на два.

                                                        Возможно (возможно — я в этом не на 100% уверен) результат будет более качественным — вот только готов он будет того, когда смысла в нём не будет никакого.

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

                                                        Вы правы, присутствует дефицит таких средств.
                                                        Кстати, имеющиеся средства для слияния текстовых программ с трудом справляются, если изменения касаются топологии алгоритма. Отобразить изменения типа CreateWindow -> CreateWindowEx получается хорошо, а переработанный блок вложенных if — не всегда.
                                                      • +1
                                                        Можно подумать над всяким скриптованием простых моделей поведения на этом безобразии для неофитов.
                                                        • +5
                                                          Запрет пересечений принуждает выделять независимые логические блоки, уменьшать цикломатическую сложность:



                                                          Круто, когда строим ракету. В «бизнесе» становится недостатком, т.к. не к месту добавленное условие «если луна в Овне — вот это пропускаем, а тут вместо 5 умножаем на 5.3» может заставить переделывать половину программы.

                                                          Вообще штука безусловно полезная, но очень нишевая. Для формального описания алгоритмов аля «технологический процесс приготовления борща» подходит идеально :)


                                                          • 0
                                                            Хотя всё равно не до конца ясно как будет выглядеть эквивалентная схема борща на ДРАКОНе. Развалится на 6-7 схем, в каждой из которых одна функция с параметрами? Как будет выглядеть силуэт? Тык rykkinn
                                                            • 0
                                                              Плохо будет выглядеть.
                                                              Схема борща — параллельная, допускающая одновременную обработку несколькими процессорами-поварятами.
                                                              А схемы на Драконе — это просто state-machine для одного процессора, строго.
                                                              • 0
                                                                А как бы Вы разбили программу приготовки борща на параллельные процессы?
                                                                • 0

                                                                  дел

                                                                  • 0
                                                                    Если схематически, то разбивка уже написана на технологической схеме, причем без привязки к кол-ву процессов и способу их синхронизации. На Драконе так общо нарисовать не получится.

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

                                                                    P.S. Показал жене — она сказала, что это неправильный борщ, в нем нет ключевого компонента — мяса.
                                                                    • –1
                                                                      Получится. Надо только понять, что тут два процесса, связанные через буфер. В организации производства он называется задел. Типичная задача согласования операций с разной производительностью.
                                                                      • 0

                                                                        Разве я сказал, что процессов два? Или это следует из технологической схемы? В том то и дело, что технологическая схема не определяет параллельность, но дает возможность её сделать.


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

                                                                        • 0
                                                                          1. Это я сказал.
                                                                          2. А их и надо описывать отдельно.
                                                                          3. Конечно, как и любой другой инструмент.
                                                                          • 0
                                                                            Значит мы друг друга поняли.
                                                                  • 0
                                                                    Если знать, что такое межоперационный задел, то два примитива. Ничего хитрого.
                                                                  • 0
                                                                    image
                                                                  • +1
                                                                    Круто, когда строим ракету. В «бизнесе» становится недостатком, т.к. не к месту добавленное условие… может заставить переделывать половину программы.

                                                                    Работаю с ДРАКОНом для ТЗ «бизнесе». Проблемы такой не заметил. Заказчики постоянно добавляют что-нибудь не к месту. Дорисовываю диаграммы, и если добавления содержат противоречия, эти противоречия сразу видны.
                                                                    А схема с борщом грамотная, кстати.
                                                                  • 0
                                                                    Судя по интерфейсу, представленному на рис. 20, DRAKON Editor стал экспортным продуктом?
                                                                    Насколько он популярен в зарубежной среде?
                                                                    • 0
                                                                      Подозреваю что в зарубежной среде Flowcode гораздо популярней DRAKON Editor.
                                                                      • 0
                                                                        Вот тут статистика есть.
                                                                      • 0
                                                                        не знаю почему, но у меня не отображается ни одна картинка из статьи. в комментах картинки вижу все, а в статье ни одной.
                                                                        • 0

                                                                          Этот Ваш Дракон — это правильно, но к сожалению он не развился. Взгляните на Matlab/Simulink/Stateflow сегодня — это то, чем мог бы стать Дракон, если бы развивался дальше. Представление алгоритмов как в виде блок-схем, так и в виде автоматов состояний. Автоматическая генерация кода для процессоров и ПЛИС. Используется и в космосе и в автомобилестроении. Моделирование — важнейшая функция. Сотни различных тулбоксов от DSP и до силовой электроники.
                                                                          Всего не пересчесть.

                                                                          • +1
                                                                            Matlab/Simulink/Stateflow
                                                                            Цена? Не для студента, если что.
                                                                            если бы развивался дальше.
                                                                            Видимо, теперь, когда есть опенсорц редактор, можно и развивать. Потому и статья появилась.
                                                                            • 0
                                                                              Цена? Не для студента, если что.

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

                                                                              • 0
                                                                                Когда-то юзал бесплатный VisSim 3.0 + dll с куском кода, переехавшим в микроконтроллер.
                                                                                А так, в более поздних платных версиях у них тоже есть сишный кодогенератор.
                                                                              • 0
                                                                                Для персонального использования матлаб можно купить за 139$, далее по 29$ за симулинк и каждый тулбокс (справедливости ради стоит отметить что некоторые тулбоксы для персонального использования не продаются, но большинство доступны).
                                                                                • 0
                                                                                  Так этот редактор существует уже много лет. И развился вполне себе. Сначала там не было кодогенерации, а потом появилась, и новые языки добавляются!
                                                                                • 0
                                                                                  Работаю лет 5 на Simulink + TargetLink, все круто, но код приходится часто напильником дорабатывать.
                                                                                  Но плюсов всё таки больше.
                                                                                • –8
                                                                                  православненько
                                                                                  • +2
                                                                                    а как насчёт concurrent/parallel/async кода?
                                                                                    • 0
                                                                                      Есть ДРАКОН-Erlang, но не знаю, насколько удобно и полезно.
                                                                                      • 0
                                                                                        Эти вещи должны быть на уровне языка, т.к. генерация последовательного кода под Erlang ничего не даст.
                                                                                      • +1
                                                                                        В ДРАКОНе есть параллельное исполнение.
                                                                                        Пример с борщом.
                                                                                        Другое дело, что DRAKON Editor это не поддерживает на данный момент.
                                                                                        Приходится обходиться другими методами, включая конечные автоматы в качестве акторов.
                                                                                        • 0
                                                                                          А посыл-приём сигналов как в BPMN?
                                                                                          • 0

                                                                                            Есть иконы "Ввод" и "Вывод". Применются для обозначения приёма и посылки сообщений.
                                                                                            Есть икона "Полка". Там в верхней части обычно пишут исполнителя (если их несколько). Но можно написать отправителя и получателя сигнала. Например: Браузер > Сервер приложения


                                                                                            См. набор икон в https://ru.wikipedia.org/wiki/ДРАКОН

                                                                                          • 0
                                                                                            Спасибо.
                                                                                            А где в описании языка про это сказано?
                                                                                            Здесь не нашел.
                                                                                        • 0
                                                                                          Отлично! Давно искал аутлайнер для lua!
                                                                                          • –1

                                                                                            Алгоритм для "Фрегата" с разворотом на 355 градусов на ДРАКОНе писали?

                                                                                            • 0
                                                                                              Можно ли писать на многоязычном ДРАКОНе: часть, где требуется скорость, на С, остальное на питоне, например, с тем, чтобы биндинги сгенерировались автоматически? Ну или php+js+html
                                                                                              • 0
                                                                                                Конечно, можно! Ещё десяток js-библиотек добавьте, и поперчите ассемблером.
                                                                                                • 0
                                                                                                  Уже помечтать нельзя. В статье и комментариях упоминаются ДРАКОНы для нескольких языков, вдруг я стрелочку нарисую, а они между собой успешно разберутся?
                                                                                                • 0
                                                                                                  Jit-компилятор воткнуть и будет скорость. Не надо усложнять там, где можно упростить.
                                                                                                • 0
                                                                                                  Мой вариант шампура
                                                                                                  image
                                                                                                  Не для создания, а понимания кода.
                                                                                                • 0
                                                                                                  В каких конкретно проектах он используется на практике?

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

                                                                                                  Структурное программирование делает то же самое для «текстовых» программ без изобретания велосипедов.
                                                                                                  • 0
                                                                                                    Структурное программирование делает то же самое

                                                                                                    ДРАКОН — это и есть структурное программирование, но для блок-схем.
                                                                                                    • –1
                                                                                                      Ну тогда здесь нет ничего нового — блок-схема программы, написанной в соответсвии с принципами с.п. будет структурированной без ДРАКОН'ов.
                                                                                                  • 0
                                                                                                    Мне нравится. Но мне всегда нравились графические языки.
                                                                                                    Хотя yes и no возле условного блока мне тяжеловато воспринимать. Было бы лучше, если бы по самой форме блока легко можно было бы сказать, куда пойдёт ветвление в случае yes. Т.е. такое разделение просто условных блоков и блоков с отрицанием — когда царская линия выполняется при отрицании.
                                                                                                    • 0
                                                                                                      В моём «шампуре» Yes — это всегда направо, т.к. любой положительное можно инвертировать: А < Б на А > Б, «дождь идёт?» на «дождь не идёт»…
                                                                                                      Шампур
                                                                                                      image

                                                                                                      Справа налево можно исключительно через диагональные линии.

                                                                                                      __________________________________________________________________
                                                                                                      Забыл, что правый шампур — отброшенный сложный вариант. В нём можно легко перемещаться и вправо и влево, главное знать, что входы выше горизонтальной середины блока, выходы равны или ниже середины блока.
                                                                                                    • 0
                                                                                                      Ну может профи программистам оно и не нужно. А мне как не профи пишущему программки для себя очень нравится(скажу больше мой мозг испытывает своеобразное удовольствие от вида этих блок схемок)). Всегда написание более-менее сложной программки начинал с блок-схемы, начиная от самой общей, и постепенно расписывая, и уточняя, пока не понимал что смогу по нарисованному, без лишнего перегрева мозгов написать код. А тут естественное завершение такого подходя, блок схема переводит себя в код сама. Так что думаю у визуального программирования есть перспективы и своя ниша потребителей.
                                                                                                      • 0
                                                                                                        Я вам больше скажу — мне тоже нравится. Красиво и [относительно] удобно. Если хочется понять, но не модифицировать. Но я сейчас посмотрел на один из наших файлов — за неделю туда внесено тремя разработчиками порядка 20 правок. Из них большая часть «наложилась» без конфликтов, но три (или 4?) вызвали конфликт и их пришлось при слиянии «разводить» руками.

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

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

                                                                                                        А небольшие (и, соответственно, несложные) программы, как бы, и без этого можно разрабатывать. Так кому оно нужно? Тому, кто разрабатывает несложные, но крайне ответственные программы? Ну теоретически — да, возможно, а на практике… есть ли выигрыш?
                                                                                                        • 0
                                                                                                          Есть и такой топик на одном форуме:
                                                                                                          ИС Дракон как форт IDE
                                                                                                          fforum.winglion.ru/viewtopic.php?p=39197
                                                                                                          • 0
                                                                                                            Это просто праздник какой-то! Ещё и Forth!
                                                                                                        • +1
                                                                                                          Здорово напоминает язык SFC из стандарта IEC61107.
                                                                                                          • 0

                                                                                                            А как описать асинхронный процесс из JS?


                                                                                                            Promise.all([
                                                                                                              fetch('http://example.com/foo'),
                                                                                                              fetch('http://example.com/bar')
                                                                                                            ])
                                                                                                              .then(responses => Promise.all(responses.map(res => res.json())))
                                                                                                              .then(([foo, bar]) => {
                                                                                                                console.log('foo', foo);
                                                                                                                console.log('bar', bar);
                                                                                                              })
                                                                                                              .catch(() => {
                                                                                                                console.log('Произошла ошибка');
                                                                                                              });
                                                                                                            • +1
                                                                                                              Вот так
                                                                                                              image
                                                                                                              Но это ДРАКОН, язык. DRAKON Editor (софт) не поддерживает на данный момент некоторые фичи языка ДРАКОН. Поэтому я прибегаю к ДРАКОНовским конечным автоматам для такого.
                                                                                                              Это в следующей статье.
                                                                                                              • 0

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

                                                                                                                • 0
                                                                                                                  По идее, самостоятельно. Но как это будет реализовано, я не знаю.
                                                                                                            • 0
                                                                                                              Можно ли как-то на Драконе изображать схемы в нотации ЕРС? Или в близкой к ней, т.е. указывать входящие и исходящие документы (в конкретную функцию), события и роли (кто выполняет операцию — функцию).
                                                                                                              А у графического языка имеются фундаментальные преимущества по сравнению с текстом.

                                                                                                              Пусть так, но зачем изобретать было велосипед, если уже был ЕРС?
                                                                                                              • +1
                                                                                                                Можно ли как-то на Драконе изображать схемы в нотации ЕРС?

                                                                                                                bipiem, вы задали важный и интересный вопрос. Событийная цепочка процессов (EPC — event-driven process chain) — тип диаграммы, используемой для бизнес-моделирования и для улучшения бизнес-процессов.

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

                                                                                                                С уважением,
                                                                                                                Владимир Паронджанов

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

                                                                                                                  Можно узнать, чем она более «выразительная» по сравнению с ЕРС?
                                                                                                                  Заодно, и чем лучше «для точного описания алгоритмов» чем BPMN?
                                                                                                                  А заодно: чем лучше «великой и могучей» нотации ArchiMate, предназначенной для описания (страшно даже произнести) Enterprise Architecture:
                                                                                                                  habrahabr.ru/post/345948/#comment_10607662
                                                                                                                • 0
                                                                                                                  perfect_genius написал:
                                                                                                                  В моём «шампуре» Yes — это всегда направо, т.к. любой положительное можно инвертировать: А < Б на А > Б, «дождь идёт?» на «дождь не идёт»…

                                                                                                                  Вы правы, любое положительное высказывание теоретически можно инвертировать.
                                                                                                                  Но здесь есть трудность, если учесть необходимость соблюдения норм профессиональной терминологии в терминах предметной области.
                                                                                                                  Отрицание может внести затруднение в понимание сути вопроса (если учитывать требование когнитивной эргономики).
                                                                                                                  Уместно привести слова Эдварда Йодана:
                                                                                                                  Если это возможно, то избегайте отрицаний в булевских выражениях; представляется, что их понимание составляет трудность для многих программистов.

                                                                                                                  Источник: Эдвард Э. Структурное проектирование и конструирование программ. — М.: Мир, 1979. — 415 с. — С. 252.
                                                                                                                  По этой причине в языке ДРАКОН предусмотрены оба случая:
                                                                                                                  1) Да вниз, Нет вправо
                                                                                                                  2) Нет вниз, Да вправо.
                                                                                                                  Такой подход создает наибольшую удобочитаемость и облегчает чтение сложных программных текстов.

                                                                                                                  С уважением,
                                                                                                                  Владимир Паронджанов
                                                                                                                  • 0
                                                                                                                    Почему в ДРАКОНе не используется цвет? Ведь цвет значительно облегчает ориентироваться в мире.
                                                                                                                    Положительные переходы можно было бы синей линией, отрицательные красной.
                                                                                                                    Просто раз уж избавляемся от текста, то надо бы до конца.
                                                                                                                    • 0
                                                                                                                      perfect_genius
                                                                                                                      Почему в ДРАКОНе не используется цвет? Ведь цвет значительно облегчает ориентироваться в мире.

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

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

                                                                                                                      С уважением,
                                                                                                                      Владимир Паронджанов
                                                                                                                  • –1
                                                                                                                    Не хватает третьего измерения. И четвёртого.

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

                                                                                                                    Самое читаемое