Сценарии для чат-ботов обычно создаются в виде блок-схем. Это удобно для проектирования — понятно, за какой репликой следует ответ и что происходит дальше. Но чтобы разобраться в схеме, команда тратит десятки часов: при больших сценариях результат выглядит крайне запутанным и похож на лабиринт. Это затягивает разработку, а её стоимость растёт. Проблем становится ещё больше, когда в схеме что-то нужно поменять.
Меня зовут Кирилл Богатов, я дизайнер разговорных продуктов в KODE. Я нашёл способ упрощать сложные схемы при помощи языка ДРАКОН. В статье расскажу о том, как я к нему пришёл, чем он так хорош и как с его помощью мы стали тратить на проектирование почти вдвое меньше времени.
Традиционный подход к проектированию чат-ботов
В прошлом году наша команда готовила сценарий передачи показаний счётчиков. На первый взгляд в нём нет ничего сложного: пользователь диктует пары чисел, а голосовой помощник отправляет их на сервер. Но чем дольше мы работали над сценарием, тем больше нюансов находили. Представьте, что творится «в голове» у бота в этот момент:
— Помощник, передай показания счётчиков!
— Хорошо, диктуйте показания.
— Вода — 103, свет — 208.
— Но ведь у вас несколько пар счётчиков... Да и квартиры две! А вода холодная или горячая? Как может быть 103, когда в прошлом месяце было 1030? А 208 — это первая фаза или вторая?
Из-за подобных деталей схема быстро увеличивалась в размерах. Новые блоки приходилось размешать всё дальше от центра, что приводило к появлению пересечений и длинных линий. В какой-то момент схема стала настолько запутанной, что мы разбирали её и пересобирали заново. И так — несколько раз. Теперь представьте, что такая схема на проекте не одна, а десятки. Например, если вы работаете над комплексным чат-ботом для социальных служб и многочисленные сценарии не просто сложны, но ещё и переплетаются между собой.
Все большие схемы, которые будут встречаться в статье, залил на Гугл-диск. Если нужно рассмотреть и увеличить, пользуйтесь.
Подобные сценарии тяжело поддерживать. Чтобы внести изменения, нужно заново вникать в схему, перемещать её части и рисовать новые линии (что может привести к новым пересечениям и окончательно всех запутать).
Я посмотрел, как эти проблемы решают другие команды. Как правило, всё сводилось к добавлению новых цветов (см. красные линии на схеме выше) или ссылок для перехода между частями схемы. Внешний вид тоже менялся: кто-то рисовал майндкарты, а кто-то следовал требованиям ГОСТ или UML. Тем не менее, базовый принцип оставался неизменным: схема — это всегда «дерево».
Древовидные схемы последовательны. Пользователь ограничен рамками сценария и не может свободно перемещаться между его частями. Подобные схемы подходят для проектирования телефонных роботов с тоновым набором и прочих линейных сценариев.
В разговорных интерфейсах сценарии непоследовательны. Пользователь может пропускать шаги, ошибаться и задавать уточняющие вопросы. Каждое подобное отхождение от сценария — это новая линия или ветка на дереве.
Разговор — это дерево с переплетёнными ветвями.
Осознав несовершенство древовидных схем, мы начали искать альтернативы.
Ситуационный дизайн
Первым вариантом, который мы всерьёз рассматривали, стала методология ситуационного проектирования (Situational Design), предложенная Полом Катсингером, руководителем отдела голосового дизайна в Amazon.
Ситуационное проектирование основано на понимании контекста. Если пользователь может сходить с намеченного пути, то и отталкиваться нужно не от пути, а от текущей ситуации. Прямо как в магазине, когда продавцу приходится отходить от скрипта и подстраиваться под покупателя.
Сценарий в ситуационном проектировании — это ряды карточек. По горизонтали откладываются шаги диалога, а по вертикали — его вариации. Если сценарий должен отличаться для пользователей, у которых один и несколько счётчиков, то в таком сценарии будет как минимум два ряда карточек.
Каждая карточка (шаг диалога) состоит:
из реплики пользователя,
условий попадания в карточку,
ответа бота,
реплики бота для продолжения диалога.
Ситуационное проектирование красиво смотрится в обучающих статьях. Но почему-то в них показывают только простые сценарии из одного-двух рядов карточек. Посмотрим, справится ли эта методология с нашими счётчиками.
На схеме слева синим цветом выделен блок с репликой подтверждения операции — к ней можно прийти из нескольких мест сценария. Оранжевым цветом выделены действия, которые можно совершить после этой реплики.
На схеме справа данная реплика входит в состав нескольких карточек, так как каждая карточка — это и запрос пользователя, и ответ бота. Каждый раз мы описываем реплику как новую, хотя имеем в виду одно и то же. Следовательно, чтобы описать действия, доступные после этой реплики, нам пришлось бы дублировать оранжевый фрагмент схемы после каждой карточки, в которой эта реплика содержится (выделены синим). Действия те же, а контекст — разный.
Ситуационное проектирование концентрируется на конкретных состояниях системы, но плохо передаёт связи между ними. Это усложняет проверку сценариев и может привести к дублированию сущностей. Сложные проекты превращаются в свалку карточек.
Ситуационное проектирование плохо масштабируется.
Другая проблема методологии — её неинтуитивность. Разработчики не понимают, как работать с таким сценарием и как перевести его в код.
Карточки ситуаций
Так как нас не устроил ни один из существующих подходов, мы решили взять лучшее из каждого. Нарисовали древовидную схему, вынесли из неё часть элементов и упаковали их в специальные контейнеры — карточки ситуаций.
Ситуация — это одношаговое событие за рамками основного сценария. Например, вывод сообщения об ошибке или ответ на уточняющий вопрос. Подобные события часто можно вызвать из нескольких мест сценария.
Карточки ситуаций состоят из трёх областей:
контекст (в каком месте диалога ситуация может быть вызвана),
описание ситуации (что сказал или сделал пользователь)
реакция системы (что должен сделать бот и как будет развиваться диалог).
Вот как изменился наш сценарий:
Изменения особенно заметны на примере ветки с ошибкой (выделена оранжевым). Её перенос в карточки позволил избавиться сразу от шести длинных линий.
Карточка ситуации — это событие, которое можно вызвать из нескольких мест.
Новые элементы помогли упростить схему, но не решили её главную проблему — это всё тот же лабиринт, хоть и меньший по размеру.
ДРАКОН
Всё это время мы отталкивались от методологий, которые уже применялись в разговорном дизайне. Не найдя оптимального варианта, мы решили взглянуть на проблему шире: начали изучать рекомендации по проектированию алгоритмов и когнитивной эргономике. Мы искали решение, которое будет простым в освоении и комфортным для восприятия. Таким решением для нас стал ДРАКОН.
ДРАКОН расшифровывается как Дружелюбный Русский Алгоритмический язык Который Обеспечивает Наглядность. Изначально он использовался в космической отрасли, но впоследствии нашёл применение и в других сферах: в медицине, промышленности и сельском хозяйстве. Я же узнал о нём из книги «Алгоритмы и жизнеритмы на языке ДРАКОН».
ДРАКОН основан на когнитивном подходе, то есть стремится рационально использовать ограниченные возможности мозга. Его цель — не просто описать процесс, но и сделать его комфортным для понимания.
Базовые принципы ДРАКОН:
Время на схеме движется сверху вниз, а ветвление — слева направо.
Вместо стрелок используются обычные линии.
Пересечения запрещены.
Разрешены только прямые углы и линии.
Сложные схемы в ДРАКОН принято разбивать на ветки и перемещаться между ними с помощью специальных элементов. Мы называем их «порталами». У каждого портала может быть несколько входов, но только один выход.
Подобное разбиение даёт сразу несколько преимуществ:
Сценарий становится легче проверять — не нужно раз за разом вести глазами по одним и тем же частям схемы.
Легче править — изменения внутри одной ветки не затрагивают остальные.
Комфортнее проектировать — порталы помогают фиксироваться на небольшом участке сценария. Слона легче есть по кусочкам.
Порталы — это закладки для быстрой навигации по сценарию.
Порталы хорошо передают нелинейность разговора. Если к одной и той же части схемы можно прийти несколькими способами, то её можно вынести в отдельную ветку и подвести к ней порталы.
ДРАКОН для разговорного UX
Несмотря на свою гибкость, ДРАКОН не был рассчитан на проектирование разговорного UX. Поэтому мы внесли в него ряд изменений.
Разрешили себе разбивать «счастливый путь» пользователя порталами. Это делает его менее наглядным, но позволяет ссылаться на отдельные части.
Добавили карточки ситуаций, чтобы снизить количество порталов.
Добавили несколько новых элементов для обозначения специфических действий вроде заполнения слотов.
Вот как изменилась наша схема после перехода на язык ДРАКОН.
Рассмотрим ту часть, с которой не справилось ситуационное проектирование. На ДРАКОН-схеме этот фрагмент находится справа. Раньше было тяжело определить, при каких условиях можно попасть в него — приходилось вести глазами по каждой стрелке. Теперь же это легко отследить с помощью порталов.
Чтобы отредактировать подобный сценарий, достаточно добавить новый портал или удлинить другие ветки. Никаких пересечений, никаких линий через всю схему.
Частые вопросы
В этом году я рассказывал про ДРАКОН на конференции по разговорному AI Conversations. В целом методологию приняли с интересом, но были и вопросы. Ниже — ответы на самые распространённые из них.
Как к ДРАКОН отнеслись разработчики и заказчики?
Отнеслись хорошо. ДРАКОН — достаточно простой язык, ему можно обучить за один 30-минутный созвон. Разработчики также могут найти в нём знакомые черты. Так, работа порталов похожа на работу чекпойнтов в RASA — фреймворке для разработки разговорного AI.
Для ДРАКОН есть визуальные конструкторы?
ДРАКОН-схемы можно рисовать в любом современном редакторе: draw.io, Miro, Lucid.app. Специализированный конструктор есть, но ему не хватает гибкости и функций для совместной работы.
Есть ли объективные доказательства эффективности перехода на ДРАКОН?
Конкретные цифры назвать сложно, так как адаптировать старые древовидные схемы под ДРАКОН проще, чем если бы мы рисовали их с нуля. Тем не менее, нам удалось вдвое снизить среднее количество итераций правок в новых сценариях. Дизайнеры совершают меньше ошибок и быстрее находят неучтённые пути пользователя при проверке.
Резюме
После перехода на ДРАКОН дизайнеры получили визуальный язык, с которым комфортно работать и которому можно быстро обучить членов команды.
Главная выгода для бизнеса в целом — это снижение трудозатрат на проектирование и поддержание сценариев. Меньше ошибок и меньше лишних коммуникаций.
Благодаря ДРАКОН мы снизили количество итераций сценариев почти вдвое.
Единственный недостаток ДРАКОН, который мы нашли, — с ним нецелесообразно работать на маленьких проектах. Для них лучше использовать обычную блок-схему или ситуационное проектирование.
Комментарии (45)
Keeper13
20.12.2022 14:10+9Как только люди не изгаляются, лишь бы код не писать.
Rezzet
20.12.2022 15:30+1Попробуйте в коде задать граф квестов и потом научить гейм-дизайнеров его делать, некоторые структуры гораздо проще задавать визуально, графы это одна из них, дракон это грубо говоря правила упорядочивания графа, что бы он не превращался в огромного макаронного монстра.
Даже табличное представление квестового графа это полная ж... ГД тут же начинают плакать и просить цветовую подкраску что бы хоть как-то читать это.
Keeper13
20.12.2022 16:07Кстати, о гейм-дизайнерах. Для "Planescape: Torment" диалоги и квесты расписывали как раз в таблице Excel.
Andrey_Solomatin
20.12.2022 18:51Было ли это легко в работе?
Вот тут сделали собственный редактор для создания диалогов на Unity.
https://www.youtube.com/watch?v=JJsBJty8DKoRezzet
20.12.2022 19:57Точно не легко, такую работу вижу каждый день, без минимальной цветовой раскраски невозможно работать, в экселе это решали заливкой ячеек. И мысль пока развивается в сторону примерно такого редактора, но никто не пробовал насколько удобно будет им пользоваться, это красиво выглядит когда в демке примерно 1% от необходимого контента, что будет когда добавят остальные 99% не понятно, но думаю что в любом случае будет лучше, если не давать пользователям свободно размещать блоки и связи, а контролировать геометрическое расположение блоков будут правила как в Драконе.
nin-jin
20.12.2022 16:18-2Описание квестов в виде конечного автомата, а не набора правил, приводит к запоротым сейвам, когда игрок действует не так, как задумывал дизайнер.
Andrey_Solomatin
20.12.2022 18:44+2В чем проблема конечного автомата? В том, что он плохо интегрируется в игру и переходы не осуществляются как надо?
nin-jin
20.12.2022 19:49-2В том, что он имеет своё состояние, никак не связанное с состоянием мира. Классический пример: по квесту надо поговорить с персонажем, а он самоубился ранее, упав с высоты.
tmxx
20.12.2022 19:59+2из моего опыта программирования интерфейсов пользователей оборудования (из этого можно сделать тот еще квест):
Взаимодействуя с системой пользователь создает в своем мозге ее модель.
Если поведение системы не соответствует модели, пользователь испытывает боль и негодование.
Задача программиста - при проектировании системы постараться, чтобы взаимодействие с системой как можно быстрее приводило к формированию в мозге пользователя той модели, которая запрограммирована.
мои наблюдения показывают, что модели на базе конечных автоматов (в т.ч. иерархических) гораздо понятнее (быстрее усваиваются), чем на базе цепочек действий, флагов, таблиц, наборов правил и т.п.
mayorovp
22.12.2022 14:25Только вот граф квестов, скорее всего, будет иметь больше связей чем разрешено в драконе.
Создатели дракона гордятся тем что на их языке нельзя составить программу нарушающую принципы структурного программирования — а при составлении квестов требуется прямо противоположное: возможность предусмотреть как можно больше переходов.
Насколько я знаю, единственный способ представить произвольный КА в виде дракон-схемы — воспользоваться "силуэтом", но это будет так же экселька, вид с боку.
DvoiNic
22.12.2022 15:40но ведь «переходы» — они «по условию». Где тут нарушения?
Если вы можете это описать словами, таблицей, программой — значит, сможете и отобразить в блок-схеме, даже обставленной более строгими правилами.
Единственное, что может не быть «главного пути».Создатели дракона гордятся тем что на их языке нельзя составить программу нарушающую принципы структурного программирования
в одной из прошлых веток доказали, что можно.mayorovp
22.12.2022 15:52Ну вот возьмём простейшую цепочку из 4х стадий: A — B — C — D, и попробуем добавить сокращения A — C и B — D. Насколько я знаю, дракон не даст добавить оба сокращения, хотя в блок-схеме такое отображается без проблем.
в одной из прошлых веток доказали, что можно
Ага, путём перехода к "силуэту". Но это убивает главное достоинство графического представления — наглядность.
DvoiNic
22.12.2022 16:10в большой схеме наглядности уже не будет. в декомпозированой — еще не будет.
Итого применимость — для детских поделок.
Rezzet
22.12.2022 22:44Идея в том что бы брать что-то хорошее из одной системы и адаптировать для другой системы. Если не подходит чистый Дракон, можно сделать же какую-то подходящую модификацию на основе идеи дракона о том что одинаковые логически схемы выглядят одинаково. Как мне видится нодовый редактор квестов, это обычный нодовый редактор, только с автоматическим позиционированием элементов. Возможно это нельзя сделать в полной мере, возможно вообще нельзя, у меня еще не было возможности проработать эту идею.
mayorovp
23.12.2022 06:34Основная идея Дракона — в том, чтобы запрещать рисовать на схеме произвольные связи. И эта идея прямо противоречит тому, что необходимо гейм-дизайнеру при проектировании квеста.
А автоматическое позиционирование элементов придумано не в Драконе.
nin-jin
20.12.2022 16:02+7Как пользователь могу сказать: засуньте себе в жопу этих чат-ботов и дайте мне форму с 4 полями, а потом уже говорите про эргономику.
DvoiNic
20.12.2022 16:44«вы не понимаете своего счастья!»©
/sarcasm
Да, даже в «форме из 4 полей» эти дизайнеры умудряются сделать 6 полей — ибо показания счетчиков горячей воды отправляются в 2 конторы — поставщику воды и поставщику тепла.
И что забавно, в поле для «поставщика воды» допустим только ввод цифр, а для «поставщика тепла» и цифр, и букв.
mixsture
20.12.2022 21:17+2После перехода на ДРАКОН дизайнеры получили визуальный язык, с которым комфортно работать и которому можно быстро обучить членов команды.
Все проблемы блок-схем раскрываются с увеличением сложности. Вот когда блок-схема становится на 10 экранов по ширине и по высоте. Начинаются проблемы с навигацией, отладкой, переиспользованием.
Кроме всего блок-схемы часто скрывают структуры данных, в которых все хранится. Действия в них видно, а вот что между ними передается, где и какое значение и чем перезапишется — не видно.
Все эти проблемы в той ли иной степени удобства решены в классическом подходе с кодом. У блок-схем же с этим пока туго. Поэтому блок-схемы появились чуть ли не раньше языков программирования, но использование их очень нишевое.
Вы можете дизайнеров обучить коду — дорого, не у всех выйдет — это все да, но оставшиеся смогут. А вот если вы выбрали подход с блок-схемами и сложность в них доросла до критичного уровня — обучением тут уже ничего не добьешься. Рефакторинг поможет, но это крайне дорогая операция, запускать ее часто не выйдет — проект выйдет золотым.
Parondzhanov
21.12.2022 01:25Поддерживаю Кирилла Богатова @Rainvention. Применение языка ДРАКОН для описания сценариев чат-ботов — интересное направление. Хорошо, что по этой теме появилась статья на Хабре.
@Keeper13 "Как только люди не изгаляются, лишь бы код не писать".
Язык ДРАКОН позволяет писать код. Для этого используется концепция "гибридный язык", например Дракон-Си, Дракон-JavaScript, Дракон-Python, Дракон-Lua и т.д.
@mixstureВсе проблемы блок-схем раскрываются с увеличением сложности. Вот когда блок-схема становится на 10 экранов по ширине и по высоте.
Этого можно избежать с помощью декомпозиции. Для декомпозиции в языке ДРАКОН служит икона Вставка (по ГОСТ 19.701-90 она называется "предопределенный процесс").
@DvoiNic «рекомендации по проектированию сложных условий» — это Паронджанов придумал специально для умственно неполноценных, неспособных к тому, что ученики средней школы 30 лет назад осваивали
Это не так. Умственная неполноценность и неспособность тут ни при чем. Суть в том, что речь идет об очень занятых людях, у которых нет времени изучать дополнительную информацию.
Вот пример. Сейчас написана медицинская книга
«Клиническая алгоритмическая медицина. Алгоритмы диагностики и лечения на медицинском языке ДРАКОН».
При создании книги участвовали 5 докторов медицинских наук и 3 кандидата медицинских наук. Это специалисты очень высокой квалификации. О чем книга? Например, глава 15. «Проблема COVID-19. Респираторная терапия дыхательной недостаточности, ассоциированной с COVID-19».
Врачи очень заняты. Их задача — лечить людей, в частности, от коронавируса. Они могут выделить очень мало своего драгоценного времени на изучение правил записи клинических алгоритмов.
Однако правила клинических алгоритмов они должны знать. Как же быть? Ответ простой. Надо упростить задачу и сделать ее наглядной и легкой для понимания. Это можно сделать с помощью языка ДРАКОН.mixsture
21.12.2022 19:10+1Этого можно избежать с помощью декомпозиции. Для декомпозиции в языке ДРАКОН служит икона Вставка (по ГОСТ 19.701-90 она называется «предопределенный процесс»).
Да, это похоже на вызов функций. Но все также не дотягивает до классического подхода. Где тут сигнатура функции с описанием параметров и типов (а в некоторых языках еще и с типами бросаемых исключений)? Что вернет эта функция и куда? А как передать ошибку вместо результата? Как передать параметры по ссылке и по значению в функцию? А вот если функция принимает на вход сложный тип данных — объект с 5 полями — это как описать?
А как хранить эти функции? В одной общей куче или есть деление по модулям?
Вот в итоге и получается, что вроде функции есть, но на таком зачаточном уровне, что много и часто их применять не выйдет. Ответы на все вопросы выше не зря придуманы в классическом подходе — каждый из них снижает связность функции и внешнего мира, что снижает сложность восприятия алгоритма, позволяя реализовывать более сложные при все тех же ограничениях человека.Parondzhanov
21.12.2022 20:08-1@mixsture Вы говорите о программировании. "Чистый" ДРАКОН описывает только поток управления (control flow), поток работ (workflow), но не программирование.
Чтобы программировать, нужно использовать гибридные языки, например Дракон-Си. Для этого служат специальные программные средства, например ДРАКОН-конструктор Геннадия Тышова "ИС Дракон".mixsture
21.12.2022 22:11Вы говорите о программировании. «Чистый» ДРАКОН описывает только поток управления (control flow), поток работ (workflow), но не программирование.
Допустим, пусть только поток работ (хотя в чат-боте то пытаются на нем программировать, но оставим это на совести автора). Смысл остается тем же:
1) при крайне ограниченных инструментах снижения сложности, вся система довольно быстро упрется в максимально осознаваемую человеком сложность. И эта точка на порядки ближе, чем для классического программирования. Затем придется решать, либо переходить к лапше-стилю (условия и циклы на драконе, а операторы внутри на классическом ЯП) и у этого стиля масса недостатков, либо все с нуля переписать на классическом ЯП.
2) данные все равно гуляют по схеме (например, между квадратиками с работами), но это никак не отражается на схеме. Каждый волен понимать состав по-своему.Parondzhanov
21.12.2022 22:57-1@mixsture либо переходить к лапше-стилю (условия и циклы на драконе, а операторы внутри на классическом ЯП) и у этого стиля масса недостатков
Здесь нужны конкретные примеры. Ваше описание похоже на программирование на ДРАКОНе на гибридном языке.
Посмотрите пять примеров Степана Митькина. Каждый пример содержит
1) программу на гибридном языке ДРАКОН-JS и
2) эквивалентную классическую текстовую программу на JavaScript.данные все равно гуляют по схеме (например, между квадратиками с работами), но это никак не отражается на схеме.
Почему не отражается? Это не так. Можно отразить с помощью иконы Полка и иконы Комментарий.
Rsa97
22.12.2022 00:33+1Пять примеров, говорите. Я вижу, например, какая каша из if/else получилась в третьем примере из-за дословного следования блок-схеме. А ведь всё читается гораздо проще при использовании early return.
Переписанный примерАналогично и с другими примерами. Каждый из них можно переписать так, что он будет гораздо понятнее.function Tree_itemClick(machine, item, event) { if (event.button !== 0) { return; } const now = getUnixTime(); const isDoubleClick = item.lastClick && now - item.lastClick < DoubleClickThreshold; if (machine.state === "expanding") { if (isDoubleClick) { machine.postponedDClick = item.id; } return; } if (isDoubleClick) { Tree_doubleClick(machine, item, event); return; } item.lastClick = now; if (event.ctrlKey) { Tree_ctrlClick(machine, item); return; } if (item.leaf) { Tree_singleClick(machine, item, event); return; } Tree_clearSelection(machine); Tree_selectItem(machine, item); Tree_toggleExpand(machine, item, event); }
Parondzhanov
22.12.2022 08:53-1Я вижу, например, какая каша из if/else получилась в третьем примере из-за дословного следования блок-схеме. А ведь всё читается гораздо проще при использовании early return.
Аналогично и с другими примерами. Каждый из них можно переписать так, что он будет гораздо понятнее.
Вы совершенно правы. Что отсюда следует?
Две нотации эквивалентны, они дают одинаковый результат.
Нотация ДРАКОНа позволяет писать программы.
ДРАКОН-схему можно автоматитчески преобразовать (транслировать) в эквивалентный код на классическом языке программирования.
В оттранслированный код смотреть не нужно, точно так же, как мы не смотрим на машинный (executable) код после компиляции.
Исходником (исходным кодом) является ДРАКОН-схема и только она.
Все исправления, изменения и улучшения делаются только в исходнике, то есть в ДРАКОН-схеме.
Производить изменения и улучшения в оттранслированном коде ЗАПРЕЩЕНО.
Таким образом, ваши слова "всё читается гораздо проще при использовании early return" в рамках ДРАКОН-технологии просто не нужны.
Почему не нужны? Потому что все читается гораздо проще, когда мы смотрим на ДРАКОН-схему (а не на код).
Впрочем, некоторые профессиональные программисты, привыкшие к текстовому коду, с этим могут не согласиться. Но ДРАКОН создан не для них, а для тех, кто испытывает трудности при работе с кодом.
Rsa97
22.12.2022 09:29+1Потому что все читается гораздо проще, когда мы смотрим на ДРАКОН-схему (а не на код).
Всё гораздо проще читается, когда мы смотрим на красивый, правильно структурированный код, а не на листик с блок-схемой. Хороший код читается практически линейно.Все исправления, изменения и улучшения делаются только в исходнике, то есть в ДРАКОН-схеме.
Кстати, раз уж упомянули об изменениях и улучшениях, как там у дракона с diff-ами? Как мне увидеть изменения между двумя версиями схемы?
Rainvention
22.12.2022 12:54Вы правильно заметили по поводу линейности хорошего кода. Однако разговорные интерфейсы (чат-боты, голосовые помощники) редко бывают такими. Например, пользователи могут пропускать шаги, переспрашивать или вовсе уходить от темы.
Проектирование сценариев не ограничивается кодом. Так, на этапе проектирования мы читаем сценарий по ролям, чтобы учесть как можно больше вариантов поведения пользователя. А для этого нужно видеть весь флоу, с чем прекрасно справляется схема.
Кроме того, дизайнер сценариев и программист - это разные роли с разными скиллсетами.
Rsa97
22.12.2022 13:45Я не спорю с тем, что дракон — неплохой стайлгайд для блок-схем. Я не спорю с тем, что есть сценарии, когда блок-схема в работе удобнее, чем другие способы представления.
Я возражаю против того, чтобы называть дракон языком программирования и пытаться сделать из него серебряную пулю.
Нарисовать общий сценарий работы чат-бота — возможно. Переносить (транслировать) код напрямую из блок-схемы — так себе решение (что можно увидеть на тех пяти примерах Митькина), особенно с учётом того, что отлаживать то придётся по коду, отладчиков для схемы у дракона нет.Rainvention
22.12.2022 17:08+1Статья описывает использование ДРАКОН для дизайна нелинейных сценариев чат-ботов. Мы не используем его для программирования/переноса кода.
DvoiNic
22.12.2022 12:22+1Аналогично и с другими примерами. Каждый из них можно переписать так, что он будет гораздо понятнее.
Вы совершенно правы. Что отсюда следует?
Напрашивается ответ, что оттуда следует низкая квалификация того, кто писал первоначальные варианты, не правда ли?
особенно если почитать претензии Митькина «Снова противная „ёлочка“ из фигурных скобок.» или «эти функции имели бы странные, мало значащие имена» (На мой взгляд, функции имеют такие имена, которые им дает автор. Если Митькин дает странные имена — глупо этим возмущаться. Хотя, возможно, он давал имена по вашим рекомендациям)схему можно автоматитчески преобразовать (транслировать) в эквивалентный код на классическом языке программирования.
для этого нужно в каждую иконку вписать код на требуемом языке программирования. Собственно, ровно такой же «транслятор» можно сделать для блок-схем. Никакой разницы.В оттранслированный код смотреть не нужно, точно так же, как мы не смотрим на машинный (executable) код после компиляции.
потому, что там сплошные goto. Более-менее полноценный транслятор вы (вся ваша команда) не осилили. И вы знаете, почему.Исходником (исходным кодом) является ДРАКОН-схема и только она.
Отладчик с отображением на дуракон-схеме сделали? Средства верификации? средства коллективной разработки? средства отслеживания изменений?Впрочем, некоторые профессиональные программисты, привыкшие к текстовому коду, с этим могут не согласиться.
А есть ли «профессиональные программисты, не привыкшие к текстовому коду»? А есть ли профессиональные программисты, пользующиеся дураконом? Есть ли более-менее сложные системы, надураконенные (задураконенные?) такими программистами?Но ДРАКОН создан не для них, а для тех, кто испытывает трудности при работе с кодом.
т.е для «умственно неполноценных программистов».
DvoiNic
22.12.2022 16:09-1данные все равно гуляют по схеме (например, между квадратиками с работами), но это никак не отражается на схеме. Каждый волен понимать состав по-своему.
С данными тут еще хуже, чем с потоком управления. Ибо в одной из реализаций дуракона все данные — глобальные. Никакого описания данных нет. Никакого разграничения доступа нет. никакого контроля типов — нет.
Все потому, что дуракон замер на этапе советских реалий 1985 года. (ибо у буржуев уже в 68 году обозначился «кризис программного обеспечения», и они были вынуждены начать его решать тогда). С тех пор появились новые языки (а некоторые уже и умерли), IDE изменились до неузнаваемости, поменялись технологии (все эти асинхронности, например). а это осталось на уровне языка ПРОЛ-2.
И даже для описания workflow он убог.
Rsa97
21.12.2022 08:04+1IMHO, до полноценного языка дракон сильно недотягивает. Максимум его можно назвать стайлгайдом для блок-схем.
Parondzhanov
21.12.2022 20:21-1@Rsa97 Это не так. ДРАКОН — язык моделирования и программирования. Программирование осуществляется с помощью гибридных языков типа Дракон-(target language). Подробнее см. Википедию, страница ДРАКОН.
Rsa97
21.12.2022 20:43+2Единственная разница между классической блок-схемой и драконовской — правила оформления. Однако блок-схемы никто не называет языком программирования.
Я могу в блок-схему (в том числе и оформленную по правилам дракона) вписать текст на русском языке. Это не сделает дракон русским языком.Подробнее см. Википедию, страница ДРАКОН.
Вспоминаем знаменитые Лемовские сепульки.Сепульки«СЕПУЛЬКИ — важный элемент цивилизации ардритов (см.) с планеты Энтеропия (см.). См. СЕПУЛЬКАРИИ».
«СЕПУЛЬКАРИИ — устройства для сепуления (см.)».
«СЕПУЛЕНИЕ — занятие ардритов (см.) с планеты Энтеропия (см.). См. СЕПУЛЬКИ».
Parondzhanov
23.12.2022 11:23Приведу пример реального использования языка ДРАКОН
для программирования в промышленной автоматике
(на газоперерабатывающем заводе, в сенсорном программируемом контроллере).На видео показана установка глубокой переработки широкой фракции легких углеводородов (ШФЛУ) Южно-Балыкского газоперерабатывающего завода компании "Сургутнефтегаз" и шкаф управления установкой, где используется управляющая программа, 70%-80% которой написано на языке ДРАКОН.
Программа загружается в энергонезависимую память Сенсорного программируемого контроллера СПК 107 М01 фирмы ОВЕН.
Подробности по ссылке.
Разработчик шкафа управления установкой и программы управления ОКБ АМУР №3.
DvoiNic
т.е. вы не знали, что в блок-схемах есть такой элемент, как соединитель?
Rainvention
В основе ДРАКОН лежат принципы эргономизации традиционных блок-схем. Соединители - один из элементов для достижения этой цели.
DvoiNic
ну, вся эргономизация там сводится к запрету пересечений, и (отсутствующено у вас в описании из четырех пунктов) «главного пути». Но вам, как следует из
в блок-схемах не хватало именно соединителей. Ну, или знаний о том, что таковые в блок-схемах существуют.Rainvention
Это не совсем так. Помимо запрета пересечений, ДРАКОН предполагает упорядоченное расположение элементов. По моим наблюдениям, многие дизайнеры пренебрегают этим, за счет чего схема превращается в подобие осьминожки.
Есть и другие принципы, которые остались за рамками статьи. Про один из них вы правильно отметили - выделение «главного пути». Помимо этого, в методологии есть принцип «общей судьбы» (однотипные элементы разных веток располагаются на одном уровне) и рекомендации по проектированию сложных условий.
Кроме того, мы внесли в методологию ряд собственных изменений, чтобы сделать её удобнее для работы с разговорными продуктами. Главное из них - карточки ситуаций.
DvoiNic
Ну в общем, вместо ДУРАКОНа получили те же блок-схемы, только упорядоченные.
(«рекомендации по проектированию сложных условий» — это Паронджанов придумал специально для умственно неполноценных, неспособных к тому, что ученики средней школы 30 лет назад осваивали)
зы. попробуйте BPMN. Там как раз есть разделение по ролям (как раз в первой схеме у вас разделение на действия юзверя и действия бота), есть нормальные рисовалки (которые автоматически верифицируют процесс), есть даже средства моделирования.
Rainvention
Мы рассматривали IDEF3 в качестве одного из вариантов, но ДРАКОН показался нагляднее и легче для восприятия.
DvoiNic
IDEF3 (его Process Schematics) явно недостаточен и неудобен. Даже инструментально.
tmxx
Это немного разные области.
Я, например, использую BPMN для описания общих бизнес-процесса и ДРАКОН для конкретных сценариев, пробовал таблицы параметров - гораздо сложнее воспринимается.
Действительно, для BPMN есть рисовалки, верификаторы и автоматизация, но особенности реализации в нем гораздо менее наглядны.