Comments 18
В наше время сложно представить систему моделирования без красивых блок-диаграмм.
Есть ли какой-ибо язык для формализации алгоритмов бизнес-процессов (EPC, WF2M, BPMN) или подобие "Пример прототипирования блок-диаграмм для АСМ SIMODO?
Есть ли какой-ибо язык для формализации алгоритмов бизнес-процессов (EPC, WF2M, BPMN) или подобие "Пример прототипирования блок-диаграмм для АСМ SIMODO?
Никто не против графических нотаций. Однако те из них, которые вы привели, чаще всего используются для общения между людьми. А если нужно их формализовать для алгоритмизации, то всё равно придётся использовать какой-то язык - хоть Питон, хоть С.
А можно конвертировать на предметно-ориентированный язык, если он существует. Об этом речь. Для этих нотаций я не знаю такого языка.
Однако те из них, которые вы привели, чаще всего используются для общения между людьми.
см. BPMN\ BPMN+ https://habr.com/ru/companies/haulmont/articles/918684/#comment_28451102
Неужели у преподавателей кончился ChatGPT?
Можно ли в MATLAB решать следующие задачи и какими инструментами ?
Взаимодействие сотен разных или схожих объектов (летательных аппаратов ....
Крупное промышленное предприятие в условиях реконструкции ....
Биосфера в условиях человеческого влияния ....
На что ChatGPT отвечает -
Да элементарно все решается в MATLAB. Ничего придумывать не нужно.
Флот/техника: Simulink + SimEvents (дискретные события) + Simscape/Blocksets (физика) + Predictive Maintenance & Optimization Toolbox (износ, планирование).
Промпредприятие: SimEvents (логистика) + Simulink/Stateflow (станки) + Optimization Toolbox (расписания) + System Composer (архитектура).
Биосфера: PDE Toolbox/SimBiology (процессы) + Mapping Toolbox & Climate Data Toolbox (геоданные, климат).
Параллельные вычисления ускоряют моделирование во всех трёх случаях.
От себя напишу.
Главная слабость текстовых языков - зависимость от имён: их трудно придумывать, запоминать и не перепутать. Графические нотации снимают большую часть этой когнитивной нагрузки.
Да , в графической нотации есть проблемы с контролем версий и diff-ами. Но это от скудности самих сред разработки. И в этом направлении как раз и стоило бы приложить усилия.
Но там и так прикладывают. Simulink и Stateflow самого начала были гибридными. Там всегда можно было перейти на текст если не хватало графической фантазии.
С другой стороны в чем-то могу согласится. Современные ИИ агенты лучше всего понимают текстовый контекст. Если ту же базу данных дать им в текстовом виде , они легко ее дополняют и редактируют. Но мне вот электричекую схему GPT 3 недавно очень точно проанализировал и выдал список цепей. Так что с текстовой нотацией все быстро закончится. Там нет перспектив.
Главная слабость текстовых языков - зависимость от имён: их трудно придумывать, запоминать и не перепутать
Есть разные подходы, применение которых не вызывает подобных проблем, или, по крайней мере, сильно их упрощает. Например, тот же DDD. Если вы описываете модель на языке предметной области, то имена - это понятия этой предметной области (как правило). И в чём тогда проблема?
Если у вас все задачи решаются в MATLAB, то не вижу проблем. Вам не о чем беспокоится.
По поводу ChatGPT... А вы всегда и во всём с ним советуетесь? :-)
На мой взгляд, у графических нотаций есть одна серьёзная проблема - сложность рефакторинга. Если нужно что-то поменять, то разобраться в спагетти из связей между блоками бывает довольно сложно. Хотя, может быть, всё зависит от самодисциплины и первоначальной структурированности. А ещё от привычки. Мне кажется, мы часто попадаем в ловушку обучения на простых задачах, для которых графические нотации идеальны. Но при усложнении задачи появляются проблемы -- см. предел Дойча.
У графических нотаций есть один недостаток. Кроме их создателя в них чрезвычайно трудно разобраться. У меня пример перед глазами, создаю сложную систему, мне все ясно. Но я понимаю, что года через 3 я все забуду, поэтому нарисовал структурную схему. Мне в ней все понятно. Коллегам - нет. Придется писать еще и инструкцию. И я не про ПО, а про вполне себе железо. Статью про подобную штуку и на Хабр можно опубликовать.Это настолько простая штука что даже лень обьяснять (с).
Это настолько простая штука что даже лень обьяснять (с)
Думаю, многим было бы интересно почитать ваш опыт реализации, а главное, передачи на сопровождение сложной задачи, реализованной с использованием графической нотации. Мне точно интересно! Буду ждать! :-)
У графических нотаций есть один недостаток. Кроме их создателя в них чрезвычайно трудно разобраться. У меня пример перед глазами, создаю сложную систему, мне все ясно.
Если есть метаМодель нотации (семантическая основа), то перевод картинки из одного формата в другой или в таблицу (или скрипт, типа dot, mermaid) - не великая проблема, см. ВРМ. Смарт-инструменты «Таблица -> Схема» для формализации бизнес-процессов. Рестайлинг ARIS SmartDesign
Один и тот же смысл может быть упакован в таблицу, скрипт RDF (отношения - это считай поля таблицы) или иное и отображён в разных нотациях (EPC, VAD, бизнес-слой archimate и т.п.).
Т.е. как семантика может быть представлена разными форматами (языками), так и синтаксис (отображение семантики) в виде разных наборов графических примитивов (графической нотации).
Блок-схемы (как в статье) имеют скудную выразительность (смысловую: объектно-предикатную), поэтому кроме структурной схемы или иерархии объектов - они мало эффективны. Собственно для этого и придуман зоопарк графических нотаций, включая Дракон, EPC, VAD, archimate и т.п. Только у них нет МетаМоделей, т.е. семантической основы. Точнее у некоторых есть, но "кривые", например, archimate.
Сложными графические модели делают "телепорты" сигналов через Goto/From, Off-page connectors .
Это когда ссылаются из одного листа на другой лист или вообще на другой уровень иерархии. Но телепорты это и есть проблема имен поскольку их надо глобально именовать в отличие от локальных портов не требующих глобальной уникальности.
Если все связи выполнены линиями, то сложность резко снижается.
Линиями некоторые разработчики пренебрегают, таща представления о структуре из своих текстовых нотаций.
Но они являются главным элементом диаграм. Потом хорошие графические языки предоставляют еще и шины для агрегации линий.
Словом агрегация и иерархия - вот на чем держится сила графики.
А в пределе Дойча на самом деле скрываются многие десятки листов и файлов текстовой нотации.
Попытка изучения эквививалентного объема текстовой нотации графичекой схемы на пределе Дойча вообще легкий шок вызвал бы. Это я попытался показать вот в этой статье - https://habr.com/ru/articles/581468/
Посмотрите, там маленькая диаграмка, которой далеко еще до предела выливается в такой текст, что редко кто возьмется его анализировать.
По сути нет другого шанса дать человеку быстро изучить реально сложный проект не превратив его в графическое представление. Либо долгие месяцы анализа текстов.
"Телепорты" они же блоки переноса позволяют выполнить структурирование модели. А для того, чтобы они не мешались в кучу при выполнении копирования \ вставки были придуманы и в Simulink и в SimInTech способы ограничения видимости переноса. В SimInTech это сделано при помощи задания уровня видимости прямо в имени блока переноса в формате количество_уровней_видимости_вверх#имя_переноса ,ну и ещё была сделана возможность динамического именования переносов с привязкой к произвольному параметру в формате {имя_сторокой_переменной_которую_формируем_скриптом_вышестоящего уровня} . Соответственно сейчас соединять что-то с чем-то можно практически как угодно, что и используется в некоторых библиотеках блоков. Шины тоже есть. Для наших потребителей при разработке моделей ядерных энергоустановок графический структурный способ спецификации систем является основным на 99%, а иначе там крупномасштабные модели просто делать невозможно.
Как правило при разработке моделей динамики технических систем применяют и графическую и текстовую спецификацию систем. Задачей графической спецификации является дать возможность предметному пользователю задать структуру системы. Задачей текстовой спецификации как правило является задание системы уравнений, описывающей поведение отдельного структурного элемента системы. У нас в нашей системе SimInTech в принципе вот как-то так и есть. По поводу сложности рефакторинга: вложенная упаковка структур с хранением содержимого в отдельных файлах + возможность синхронизации параметров по шаблону проблему неплохо решает, мы так переживали несколько глобальных переездов для некоторых библиотек блоков при обновлении структур без потери связности моделей. Любой графической спецификации можно сопоставить текстовую (наоборот тоже можно с некоторыми ограничениями). В принципе вообще существует два основных подхода: 1. Структурный (Simulink, SimInTech и некоторые другие отраслевые системы моделирования) 2. Языковой (Modelica, Julia, LISMA ). Они друг другу не противоречат и дополняют.
Очень много умных букв, за их деревьями плохо разглядывать лес идей. Это хорошо, при освоении бюджетов, но ключевые идеи - следует доносить короче и точнее.
Посмотрел репозиторий, понравился язык для задания и реализации грамматик fuze:
https://gitverse.ru/simodo/loom/content/dev/data/grammar/json.fuze
https://gitverse.ru/simodo/loom/content/dev/data/grammar/s-script.fuze
Из того, что понял:
Плюсы: отечественная наука (хоть и с опозданием в +50 лет), но дозревает до ЯОП.
Минусы: Вы не сформулировали на языке математики, чего хотите достичь, значит, понимаете задачу интуитивно.
Формулирую задачу: вы решаете задачу управления сложностью: на входе физические объекты - на выходе - их матмодели, проблема: как сделать это минимальными формами? Идея проста: бьём физику на уникальные (не сводимые друг к другу) куски, делаем под них уникальные "инструменты" (грамматика + алгоритмы) и сводим всё вместе. "Инструменты" - вяжем к мат аппаратам: ЯП для векторного исчисления "зеркалит" "грамматику" + алгоритмы из книг по линейной алгебре, ЯП для интегрального исчисления - "грамматику" + алгоритмы из книг по интегральному исчислению, то же и по другим аппаратам и ветвям математики.
Удачность/неудачность сего процесса зависит от опыта и фантазии создающего грамматики.
По конкретным грамматикам: там где вы взяли удачные грамматики, разработанные по науке для предметных областей (BNF, Modeica) - всё отлично. s-script - помесь Си, JavaScript с Питоном - жуть.
PS Рекомендую взглянуть, как с данной задачей справляются французские коллеги из https://www.ill.eu/
мне очень понравилась их грамматика и виртуальная машинка для линала
A compiler and virtual machine for linear algebra calculations
https://github.com/t-weber/matrix_calc/blob/master/test/cryst.prog
Плюсы: отечественная наука (хоть и с опозданием в +50 лет), но дозревает до ЯОП.
Прямо уж +50? За что вы так не любите отечественную науку? :-)
Идеи и определение ЯОП были впервые сформулированы в 1994 году. Ну никак не 50 лет.
И это только идеи ЯОП. Вы считаете, что с тех пор ничего не изменяется в науке в этом направлении?
Минусы: Вы не сформулировали на языке математики, чего хотите достичь, значит, понимаете задачу интуитивно.
Отчасти вы правы. Но в интуитивном понимании задачи нет ничего плохого. В той же математике интуитивисткое направление вполне себе существует. См. например, Морис Клайн "Математика . Утрата определённости".
Задача, закреплённая строгим языком математики, кристаллизуется, а хотелось бы её как бы немного размять. В том числе и по этой причине была написана статья на данной платформе - в попытке поиска возможных путей дальнейшего движения.
Формулирую задачу...
Спасибо :-). В целом всё так, но это взляд только с одной из сторон. Такая формулировка несколько "кондовая", что ли. Хотелось бы оценить насколько она абстрактна, не слишком ли сужает возможные варианты управления сложностью в широком смысле. Для этого как раз и требуется интуиция. Лично я всё ещё в поиске.
Что касается плюсов и минусов нашей разработки языков, то они меняются. Мы находимся в поиске наиболее удобных для наших задач языков. И отталкиваемся именно от конкретных задач, в перую очередь. Это вносит некоторый хаос, но должно привести к хорошему результату, я надеюсь.
PS Рекомендую взглянуть...
Спасибо. Посмотрю.
Идеи и определение ЯОП были впервые сформулированы в 1994 году.
Не соглашусь. BNF - это и есть ЯОП.
А далее - каждый ЯП делали под конкретные задачи. Вот статистика:
Википедия говорит нам о 700 языках.
Олдфаг из 90-х FOLDOC насчитывает 1000 языков.
The Language List насчитывает ~2,500 языков
Коллекция HOPL насчитывает 8945 языков
J.E. Sammet помогала разрабатывать COBOL и одной из первых задалась вопросом отслеживания языков программирования в 1971 году, она насчитала тогда 167 языковhttps://habr.com/ru/companies/timeweb/articles/598277/
Здесь - Генеалогическое древо языков (увеличивается)
https://hopl.info/images/genealogies/tester-country.pdf
не слишком ли сужает возможные варианты управления сложностью в широком смысле
Да, сужает, но в хорошем смысле. Мы пока не дали определение понятию "сложность" и как ей "управлять". В общем случае это тождественно "менять пространство состояний объекта в соответствии с условиями задачи". Примнительно к ЯОП это формулируется так: минимальными формами (языковыми конструкциями) отобразить пространство состояний заданного класса объектов либо, что то же самое, - точно/полно попадать языковыми конструкциями и алгоритмами в пространство состояний заданного класса объектов. Не думаю, что можно сделать ещё что-то новое в этом направлении.
Мы находимся в поиске наиболее удобных для наших задач языков. И отталкиваемся именно от конкретных задач, в перую очередь.
И это - правильно. Только так. Лишь начинается "теоретезированние" при разработке грамматики, без проверки её на практических задачах - ЯП превращается в "борщ" (в плохом смысле этого слова). Это причина неудач многих "языков общего пользования". Особое искусство - не добавлять новые конструкции в грамматику/API, а как раз - их усекать. :)
Не соглашусь. BNF - это и есть ЯОП.
BNF для ЯОП является инструментом. Это - разные концепты. В общем-то, не думаю, что нужно продолжать спор, давайте останемся при своих мнениях.
Это хорошо, при освоении бюджетов, но...
Не хотел писать, но чувствую, что есть недопонимание... О каком бюджете вы писали? На всякий случай - этот проект мы делаем вне работы, хотя порой пользуемся им и на работе: например, студенты берут темы на курсовые и дипломные работы, иногда у них получается внести заметный вклад в проект.
И, конечно, этот проект помогает держать форму, чтобы быть более-менее на современном уровне. Например, сейчас мы делаем инфраструктуру для реализации микросервисов на платформе SIMODO. Следующей весной попробуем целиком перевести лабы по микросервисам с golang на наш язык (как альтернативный). Сейчас работает синхронный вариант взаимодействия (REST API, OAS). К весне подключим оркестрацию и мониторинг.
А ещё, может быть, напишем специализированный язык для бекэнда. Как вам оркестратор распределённых транзакций в виде группы специальных операторов? О, нет! Сечас кто-то кинется в ChatGPT писать запрос и ответит, что такое уже есть и даже код приведёт! :-)
Ладно. В общем. Если что-то выйдет, напишу по этому поводу статью здесь. Надеюсь, будет интересно.
Языково-ориентированное… моделирование?