DRAKON.SU

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

Возможно, вам стоит еще раз внимательно прочитать эту статью

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

Жаль, вероятно я использовал не те слова.

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

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

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

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

Там сказано:

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

Может быть как-то "драконизировать" графы Закревского. Уже были попытки:
https://forum.drakon.su/viewtopic.php?f=176&t=6221

Необходимо сохранить принцип -- на борту лишь "события" и "действия", плюс спец-соединения вершин аля дивергенция/конвергенция.

В нотации ARIS eEPC есть квадратики-действия и вопросики-события (схожие с драконовскими, ну, там, всякое округление углов второстепенно):
https://itrp.ru/questions/notatsiya-opisaniya-biznes-protsessov-aris-eepc/
https://www.businessstudio.ru/articles/article/aris_eepc_ili_protsedura_business_studio/

Там же есть и логические соединения-операторы "and", "or", "xor". У Закревского в графах и прочих формализмах как-то не очень-то отличаются события вида "здесь и сейчас" (аналог if/case или "вопрос"/"выбор" в Дракон-е) от реального ожидания чего-то. В принципе-то, через "xor" выражается if/case, через "or" -- ожидание, м.б. тогда ожидание "всего" -- через "and", а запуск параллельных процессов -- пусть как "#".
И драконоподобную упорядоченность в этот винегрет бы, но не знаю как...

В языке ДРАКОН есть простая возможность исключить операторы and и or.

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

Использован принцип «конъюнкция без знака конъюнкции»,
«дизъюнкция без знака дизъюнкции».

Посмотрите книгу Паронджанов В.Д. Алгоритмы и жизнеритмы на языке ДРАКОН. Разработка алгоритмов. Безошибочные алгоритмы. — М., 2020. — 376 с. — Иллюстраций: 200.

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

Я согласен с Владимиром Даниеловичем, в ДРАКОНе с логикой вполне толково получается. Меня кругляшки ARIS EEPC совсем не вдохновляют.

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

Если мы всерьез обсуждаем новые элементы графического алфавита, может быть обсудим Гармошку?
Думается, А_МУР мог бы оценить этот знак с практической точки зрения. Нечто похожее, как мне помнится, мы обсуждали с ним при очной встрече.

Такой Гармошкой можно описать хоть ДКА, хоть НКА, и схема останется достаточно простой для понимания.
А если нужно ожидать события, например ввода символа, так и напишем в верхнем элементе "Жди ввода символа".
В нижних элементах можно конкретизировать, какой именно знак будет ключом для каждой лианы.

При использовании Гармошки нет нужды помнить про переменные. Селекция направлений происходит внутри иконы, на основании значений внутри "мехов", и настроек истинности/ложности справа от "мехов" (ДА/НЕТ).

Видимо, необходимо уточнить, что есть один узел. Графы переходов, графы Закревского -- это не про "визуальную логику" как здесь (по ссылке выше из "Алгоритмы и жизнеритмы ..."):

а про упорядоченность событий и действий во времени. Так, если "вопросики" выше трактовать как кругляшки из EEPC или графов Закревского, то продвижение по маршруту, например, "Том пошёл за кладом? /нет" --> "Том пошёл за кладом?..." следует интерпретировать как следование двух событий (во втором случае: "пошёл ли Том ещё раз за кладом?" или "была ли вторая попытка?"), нечто вроде икон "синхронизатор", "пауза".

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

Схема останется понятной, но формализм в целом не будет простым в отмеченном выше смысле, если будут и гармошки с ромбиками (в т.ч. совместно переплетенные), ввод/вывод с действиями и какие-то прочие попытки "ожидания" -- уже была демонстрация построить аналог графов Закревского.
В тех графах нет визуального отличия событий как результата предшествующих действий данного процесса от событий-итогов смежных процессов. Разница должна быть понятна из контекста, что, в общем-то, приемлемо. Однако есть хотелка и "визуальной математики" -- комплексные условия раскладывать по частям. Вариант как в ARIS EEPC -- события соединяются логическими визуальными операторами -- да, в целом не очень-то легко воспринимается. К тому же может быть для "бизнес-жизнеритмов" тамошний набор операторов достаточный, но, например, для предметки "деревья отказов" нужно поболее ("запрет" -- "событие с условием", "приоритетное И", "m из n"):
https://www.itexpert.ru/rus/ITEMS/77-30/

В общем случае нужны "формулы" как универсальное средство. Может быть тот же ромбик-вопрос использовать как "событие" у Закревского. Один ромбик -- одно событие. Выходов из ромба может быть два и один. Ромб с одиночным выходом "проглатывается" нормально на маршруте, мол как "пауза", аля (выход должен быть всегда помечен "да" или без метки):

Комплексное (но одно) событие -- в виде гармошки-склейки ромбиков (без всяких верхних "действий"). Однако проблема в выразительности. В общем случае, видимо, гармошка будет аля "линейный бинарный граф", с переходами внутри гармошки (!), с возможными повторениями условий и т.д.:
https://forum.drakon.su/viewtopic.php?f=148&t=6693

Тогда необходимо добиться выразительности, не хуже чем традиционные развесистые "лестницы условий" из отдельных ромбов.

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

Всё время удивляюсь, как здешние участники ставят задачи.
Почему, ну почему? Почему никто не хочет решать единственно правильную и имеющую смысл задачу: "Как изобразить конкретный формализм/процесс/алгоритм наиболее когнитивно эргономичным способом?"
Понятно, что тема про инструмент "язык ДРАКОН", но зачем вместо выбора ОПТИМАЛЬНОГО инструмента заниматься попытками к любой задаче прикрутить инструмент неадекватный?

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

Почему проигрывает?
В двух словах: потому, что исходный формализм - это язык высокого уровня.
А все остальные представления создаются путём ТРАНСЛЯЦИИ с языка высокого уровня на язык НИЗКОГО уровня.

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

Ну и, собственно, всё.
Выбирая один из способов представления, вы выбираете сразу все перечисленные плюсы-минусы и получаете результаты в соответствии со своим выбором.
Зачем ломать голову над неоптимальными вариантами использования инструментов?

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

Если рассматривать ДРАКОН как графический ЯЗЫК, то что-то он опишет просто и понятно, а что-то будет монструозно и путанно. И не оптимально, да.

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

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

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

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

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

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

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

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

Нет по всем пунктам.
Компактно? Компактнее адекватного формализма (графа) всё равно не получится.
Понятно? Нет, нет и ещё раз нет.
Понимать такое представление и работать с ним - всё равно что постоянно дизассемблировать в уме машинный код.

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

Дракон вполне подходит. А графы - не вполне. Таблицы - тем более мимо.

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

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

Говорил я. Именно про то, что ставить процедуру в центр внимания - далеко не всегда есть адекватный подход.

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

"Подходящесть" Дракона (и вообще подхода "от процедуры") - кажущаяся простота, которая "хуже воровства", см. выше.

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

Препятствие вовсе не в форме прямоугольников, а в подходе "от процедуры", см. выше.

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

Добавлю важное.
Возводить на пьедестал "неподготовленность" - крайне опасный подход.
Это называется профанацией, и она никого до добра не доводила.

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

Наш диалог похож на спор каллиграфа и воспитателя детсада: дукт vs каракули. При всем рвении никак не получатся "годами сломанные принципы мышления". Им бы хоть минимально научится грамоте алгоритмической - уже будет великое дело.


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

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

Дык, тема-то здесь вроде никак не про ребёнков, а про автоматное программирование, не?

С детьми надо особенно аккуратно.
Настоятельно рекомендую соответствующие разделы форума (а также пообщаться с info21).

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

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

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

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

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

Возьмите лучше топор: это куда более универсальный инструмент. Учите использовать его для забивания и выдирания гвоздей, для вырезания по дереву, для лесоповала и куче связанных задач. Только учтите: ни пилой, ни лобзиком пользоваться НЕЛЬЗЯ!
Почему нельзя? Да потому что именно ТОПОР - ИНСТРУМЕНТ ДЛЯ ВСЕХ. Ибо так решил автор, он лучше знает, чему детей учить.

Я работал со студентами (которые те же дети) и старшеклассниками.
И потому повторю настоятельную рекомендацию: обсуждать эти вопросы на форуме "Информатики-21".
Там как раз именно то место, где имеет смысл обсуждать поставленную вами задачу.
Там вы найдёте в том числе профессиональных преподавателей.
А здесь - только отдельных программистов, которых заинтересовал Дракон - и ничего более.

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

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

Вопрос остается открытым: имеются ли идеи по описанию конечных автоматов ДРАКОНом, но не используя правил языков программирования (как получается у Степана)?
Что не устраивает в идее использования Гармошки, кроме уже высказанных замечаний?

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


Если применить Гармошку, то можно ДРАКОН-схему описать так:


Если же брать некий абстрактный автомат, то схема может выглядеть так:


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

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

Прошу прокомментировать, если есть изъяны в оформлении схем.