DRAKON.SU

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

Топор пригоден рубить собор, дрова и головы. И даже гвозди заколачивать.

Да.
Но не в каждой задаче.
Использовать его для автоматного программирования можно, но не нужно. Именно с точки зрения дидактики.
Если для начального алгоритмического творчество он очень хорош, то формализм автоматного программирования уже и надо вводить как формализм, не пытаясь эмулировать Драконом.
Когда-то же надо пересаживаться с трёхколёсного велика на двухколёсный. А когда-то и на авто. Здесь как раз тот случай, когда пора.

Полное отсутствие эргономического обоснования.
Хотя идея здравая.

А вот это как раз не очевидно и вообще ниоткуда не следует.

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

На Хабре вышла интересная статья, и в ней приведен пример описания логики работы устройства с помощью графа:


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

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

Такой кусочек:


описывается, как мне представляется, так:


В сравнении, как мне кажется, становится понятна мощь ДРАКОНа: каждое действие очевидно, в отличие от графа, например, отсутствие инициализации в состоянии WR_ST, когда (DIR != 0).
А то, что ДРАКОН в сравнении с графом визуально тяжеловат, можно простить, т.к. многие элементы силуэта, со временем, становятся незаметными, т.к. по сути являются обрамлением алгоритма, а не самим алгоритмом.

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

К вопросу о визуальном сжатии Гармошки: думаю, что можно предложить какой-нибудь вариант выделения этого знака: обводить Иконку "Гармошка" жирной линией по контуру, или помещать её на цветную прямоугольную подложку/фон. Тогда читатель не сможет перепутать её с отдельно стоящими Вопросами и Вставкой, и явно отметит "склеенность" Гармошки.

Зачем соединять иконы?
Можно же сократить между ними промежуток и забыть про "Гармошку".

Процедурно Гармошка так и получается: рисуем Вставку (или Действие), добавляем снизу Вопрос (или несколько).

Речь идет не об иконе "Гармошка", а о приеме оформления, композитной макроиконе, если угодно: макроиконе, изготовленной из нескольких икон с разными свойствами, но объединенной неким "клеем" (общим пространством имен)

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

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

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

Прекрасный пост: и оппонента заклеймили, и направление работ задали (но без перспектив реабилитации), и параметры оценки результата определили. Шарман!

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

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

Да. Надо называть вещи своими именами. И честно себе самому признаваться в неприятных открытиях.

Это необходимо.
Без наличия критериев не то что сравнивать ничего нельзя, но и вообще говорить не о чем.

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

Последнее очень и очень важно.

Вот вы уже начали сами себе противоречить: только что ратовали за "неподготовленного пользователя" (в т.ч. ребёнка), а теперь стало ясно, что всё-таки требуется "намётанный глаз"!

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

Да, это улучшит читабельность, но проблемы в целом не решит, см. выше.

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

Я привел пример с начальной диаграммой, представив вариант на ДРАКОНе. Достоинства и проблемы обоих видны. Не вижу необходимости приводить все диаграммы. Sapienti sat.

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

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

Зачем много отдельных сообщений? Очень неудобно.

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

Демагогия продолжается, увы.

Читаем: "Не вижу необходимости приводить невыгодный для меня пример".

Это хорошо. Но на них напрашиваетесь очень активно, к сожалению.

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

А что это за инициализация такая? Её же не было ни в исходном алгоритме, ни в статье на Хабре.



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

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

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


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

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

Собственно, речь-то и велась о том, что в текущем состоянии ДРАКОН не обеспечивает простоту описания автоматов, по сравнению с тем же графом состояний. Но у него есть некоторые преимущества, в части очередности он однозначен: для узла IDLE есть три признака перехода, и какой из них сработает при одновременном изменении - не очевидно. Автор подкрасил "DIR=1" красным, и объяснил, что так он обозначил приоритет. А если бы мы статью не прочитали, то было бы не понятно, как это всё понимать. Опять же, при рассматривании графа осталась неопределенность: одновременно обрабатываются процессы по двум оставшимся петлям, или по очереди. Если по очереди, тогда какое состояние возникнет при одновременном изменении обоих признаков?

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

А перегруз ДРАКОНа - это и мне заметно, да. Однако, не стоит забывать, что его перегруз связан в том числе и с определенной избыточностью описания, пусть даже не полностью. В определенных ситуациях это может стать преимуществом, опять же вспоминая вариант с инициализацией. Я также предполагаю, что визуально ДРАКОН кажется запутанным, потому что Читателю требуется осмысление символов силуэта, правила оформления которого заставляют Автора трижды упоминать название одного узла в разных местах: в Заголовке ветки, в Адресе и во Вставке. Но, как мне кажется, если Силуэт используется часто, то его элементы будут уже не так перегружать внимание. Есть существенная проблема другого вида: ребро в графе очевидно и кратко. В Силуэте этой краткости добиться сейчас невозможно. Нужен Адрес, нужен длинный путь взглядом по шампуру/веткам, и Читателю нужно найти и прочитать соответствующее состояние в Заголовке ветки. В Графе - одно движение/взгляд, в Силуэте - несколько мысленных операций/движений/взглядов. Это, как я понимаю, именно то "умственное усилие", которое упоминал Алексей.

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

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


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

Был выявлен интересный факт: для описания диаграммы состояний "монеты при подбрасывании" необходимы две вершины и четыре записи с условиями перехода. Диаграмма на ДРАКОНе с применением Гармошки требует две Гармошки и две записи с условиями перехода.