1 Также есть (должно быть) ограничение по максимальной скорости, т.е. формула: ограничение по скорости и по мощности одновременно.
2 Мощность. 250 вт - это уже мопед. Велосипед - это ДО 250 Вт. В продаже таких самокатов не видел, т.к. должна быть указана цифра 249 Вт (и менее). Вообще обычно обзоры мотор-колес начинаются с цифры 250 Вт, т.е. уже "за рамками".
3 Мощность 249 Вт (или 250 - 0,00001) - это мало ("не едет"). У меня s3 Куго, там 350. Сомневаюсь, что в прокатах "честные 250", как написано тут:
— Большинство частных кик-скутеров имеют большую мощность и формально вроде бы относятся к транспортным средства. А что с прокатными?
— Нет, мы не считаем их механическими транспортными средствами, — говорит представитель Urent Алена Сухаревская. — Мощность наших самокатов настроена на 0,24 кВт, а мощность мопедов по действующему законодательству — 0,25–4 кВт. При этом исходная модель Ninebot ES4 имеет мощность 0,3 кВт, то есть формально является мопедом, но для проката используется версия со сниженной мощностью.
4 Все эти ухищрения "программного снижения мощности" типа "мотор-колесо на 4 кВт, но я програмно снизил до 249,9 Вт" (т.е. это теперь уже велосипед) - это обычно ровно мопедная тема на 50 кубов: 80% предложений в магазинах прямо говорит, что "по документам 50", а реально воткнут 110 (125) кубовый движок. Иначе техника "50-кубов" без этих "формально 50" - не покупалась бы, т.к. на ней ехать почти невозможно, тем более двум взрослым. Полагаю, что такое будет (есть) с электросамокатами \ велосипедами.
Если самоделка, то кроме как ориентироваться на шильдики (в первую очередь набитые цифры на мотор-колесе) - никаких доступных инструментов нет. Я когда заказываю у китайцев мотор-колеса, прошу вообще не набивать на них значение мощности (ударные клейма стоят недорого).
5 Начинается игра с "пиковой" (до секунды) / "максимальной" (минуты) / "номинальной" (крейсерской) мощностью электросамоката \ велосипеда \ мопеда. Кстати эти (пиковые, максимальные) параметры не выдуманные, а задаются в настройках BMS (battery management system / система управления батареи): попробуйте там существенно увеличить цифру порогового пикового значения мощности и смотрите откуда пойдет дым.
6 Полагаю, что реально обеспечить контроль мощности и скорости "в прокате" можно только путем выпуска и продажи собственного "отечественного" контроллера мотор-колеса и заменой на него на каждом прокатном самокате. Только это утопия.
В России Urent заказывает небольшие мелкие запчасти для ремонта,
Утопией также является производство отечественных электросамокатов, т.к. это потребовало бы повторную индустриализацию страны, что в свою очередь потребовало бы мобилизацию (но в хорошем смысле слова) - науки и образования. Сейчас если поставить простую задачу: реально отечественный современный (не хуже китайских) массовый (дешевый) электросамокат - это привело бы к переосмыслению существующей высокотехнологичной составляющей отечественной промышленности.
Пользователь явно не видит этих отношений (троек: объект -> связь -> объект \ свойство) в своей программе (интерфейсе), но он их создает (триплеты). По ним строятся, что графы ZettelKasten, что схемы BPM. Проблема лишь, чтобы "их вытащить" и сделать экспорт в стандартный формат.
Возражение в том, что пользователю особо поддерживать ничего не нужно, триплеты - это внутренний механизм, присутствующий в самом ZettelKasten \ BPM, но просто так не называемый. Пользователь каждый раз сам рисует или вводит через ссылки эти связи - триплеты. Нужно просто уметь их выгрузить в стандартном формате.
Web публикацию бесплатную в Obsidian как сделать? Может сторонние средства есть простые?
В основном из-за этого перешел на Logseq.
Еще бы хотелось, чтобы в ZettelKasten можно было сразу триплетами (RDF или иное) связи строить (скриптами логику \ семантику дописывать \ править). И выгружать граф из Obsidian \ Logseq прямо в RDF и воспроизводить его в других ZettelKasten. К этому хоть движется какой-либо ZettelKasten? Про сложные системы LD знаю, интересует LD уровня "для домохозяйств".
Можно и этот (для начала), но на нем, полагаю, что в основном "драконо-почитатели", хотелось бы что-то из форумов (площадок) BPM (BPM-почитатели), мы же схемы бизнес-процессов рисовать планируем.
На каких-либо BPM - площадках обсуждали Дракона для формализации БП? Чтобы получился не "холодный" заход (звонок), а публика была уже немного "прогрета".
нового направления в области совершенствования нотаций и инструментария для бизнес-процессов
Предлагаю вначале понять, чего не хватает в ЕРС для описания БП. И что нужно заимствовать из Дракон? Предложите площадку для обсуждения.
Далее нужно формализовать этот «ЕРС-D» (дракон).
Еще лучше (можно параллельно) составить универсальный Smart Designer для БП, который может по «Одной и той же табличке с алгоритмом в столбик» строить схемы в разных нотациях, например, на ЕРС, Драконе и потом ЕРС-D. Для начала можно начать с ЕРС, чем я и занимаюсь:
Это было предложение собрать Smart Designer на Falang.io. Однако по Falang.io не нашел информации, он есть на github? Если это закрытое ПО, - то не стоит и начинать. Так же для меня загадка: придумывают новые редакторы, так почему формат файла xml (хранение схемы БП) не заимствовать от существующих, например, drawio?
Смысл универсального Smart Designer для БП в том, что человек, вообще не знающий ни одной нотации БП, расписал бы «в столбик» пошагово свой процесс, начал кнопку «показать» и увидел, как его пошаговый процесс выглядит в разных нотациях. И выбрал для себя наиболее понятную.
До универсального Smart Designer (который умеет строить схему по нотациям, т.е. более чем одной) применительно к описанию БП нужно сделать (повторить АРИСовский) хотя бы для одной из нотаций для БП. Желательно Smart Designer (БП) построить не на каком-нибудь эксклюзиве, а на чем-то очень распространенным, типа drawio или visio.
Финальный шаг - прикрутить к полученному LD. И тогда все забудут про АРИС и приручат Дракона (БП-Дракона).
Посмотрел. Простенько как-то. Даже для начала 90-х не впечатлительно.
1 На форуме Дракона несколько лет назад встречались откровения, что не может Дракон про бизнес-процессы. WorkFlow может, а вот что-то подобное ЕРС - нет.
На указанных примерах вижу, что события ЕРС (шестиугольник) - в Дракон это "нижняя половина шестиугольника" (порча \ утрата браслета, хотя в книжке "Книга алгоритмов дракон" встречаются "зачем-то" и другие "альтернативные" обозначения событий), а роли - указываются в верхнем прямоугольнике "сдвоенного прямоугольника" (роли + операции). Наглядность и понятийность явно хуже чем в ЕРС.
2 Для описания бизнес-процессов нужно указать, кроме событий, кто выполняет операцию (система, актор, исполнитель, роль и т.п.), также: какими инструментами (например, ИТ-система) и какие входы и выходы у операции (функции, действия), т.е. фактически рядом с WorkFlow показать DocFlow. Пример:
3 Предлагаю подумать над "ответвлением": "Драконовские бизнес-процессы" или BPM-DRAKON, как скрещивание Дракона и ЕРС. Или адаптация ЕРС под Драконовские идеи, типа левый - основной ствол WorkFlow (ЕРС такой подход не содержит) и др. В приведенных примерах бизнес-процесс смотрится не "ВРМ-образно", а всего то нужно вместо "половины" шестиугольника нарисовать правильный шестиугольник, как в ЕРС (полный и красного цвета), роли выделить явно (различимо) и др.
4 Еще лучше: сразу сделать BPM (ЕРС) \ Дракон на принципах Linked Data. Что-то подобное обсуждалось:
LD-инструменты, которые могли бы "уложить" RDF в нечто похожее на ЕРС, т.е. поток workflow уложить вертикально, а окружение функции - горизонтально (хотя бы как кластер в dot)?
Применительно к ГОС-ТОП-менеджменту (вкл., около государственные корпорации, банки и т.п.). Объект, которым управляет система управления, оказался намного более сложным, чем существующая примитивная система управления (этот самый ТОП-менеджмент, который управляет Объектом).
п.1 Более 90% современного ТОП-менеджмента (ТОП-предприятий, ГосДу*ы и т.п.) - это не случайные люди, т.е. их проф-квалификация - вообще значения не имеет при постановке на пост. Совсем другие критерии отвечают за замещение таких ТОП-вакансий (круг друзей - сослуживцев, преданность и т.п.). Есть исключения, типа главы ЦБ, но они редкие.
п.2 Что делать, если Объект оказался намного более сложным, чем примитивная система управления этим объектом? Развивать проф-навыки ТОП-менеджмента (улучшать систему управления) - тупик, см. п.1.
п.3 Проще сделать сам Объект более примитивным, чтобы их уровень сложности сравнялся и "система управления оказалась в зоне своего комфорта". Это и происходит сегодня: деградация "всего", кроме давно деградированной системы управления в РФ. Основная цель ТОП-ов - это поддержка имиджа своего личного и своего подразделения в глазах руководства и ТОП-ов смежных подразделений, чтобы хотя бы формально "соответствовать должности".
ARIS Smart Designer (EPC) - это не совсем "последовательность бизнес-процессов". Это скорее "Связанные данные", которые умеют в ["картинка" -> "таблица"] и обратно. Это позволяет заполнять таблички и получать схемы, т.е. можно нотацию вообще не знать.
Второй плюс: т.к. у нас есть таблица со ВСЕМИ данными о процессе, то это уже BPM - хранилище. Так и до "большого АРИСа" недалеко.
Полагаю, что у Дракона так и не появилась ветка "бизнес-процессы" (подобие EPC).
Редакторы блок-схем и ARIS Smart Designer (на примере EPC)
Есть ARIS Smart Designer (EPC). Хотелось бы его повторить на чем-то еще кроме ARIS Express, например, Drawio, Falang.io, DgrmJS и т.п.
Подготовил макет (прилагаю) Excel 2016 + Drawio в части Event + Function (только два объекта из EPC, чтобы идея была проще видна). Такое повторить бы в реальном времени, как в ARIS Smart Designer: автоматическое обновление, таблицу размещать непосредственно рядом со схемой процесса. Была бы интересна интеграция "встроенной" таблицы с Excel и Google Sheets.
К макету: нужно указать пути (Drawio + Temp) на листе «Set» (нужно локально поставить Drawio, можно portable). Далее на листе List1 нажимать «в паре» кнопки: «Выгрузка в файл» и «Запуск файла». Также можно нажимать и другие кнопки, которые создают новые или удаляют Event + Function. Это функции: добавить объект (Event or Function) вниз (Добавление), вставить объект в указанное место (выбранную строку, Вставка), удалить конкретный объект (выбранную строку), очистить (удалить все). В ARIS Express добавляется объект только в конец, а потом перемещается вручную кнопками "вверх" \ "вниз". В макете показан более удобный вариант.
Пользователю будут отображаться только столбцы с названиями Event & Function (остальные строки в Excel можно скрыть).
Простой (только WorkFlow) Макет на Excel 2016. Половина кода - файловые преобразования: чтобы русские буквы были в Drawio, пришлось из стандартного Excel ASCII делать Unicode noBOM.
Не интересовался коммерческими военными симуляторами - прогнозерами, но десять лет с небольшим назад некоторые западные АСУВ (C4i) тактического звена продавались открыто.
В них было общее ядро, отдельная ветка для своей армии (без продаж конечно), отдельная коммерческая - "для гражданских применений", хоть для страйкбола, хоть МЧС и других силовиков. Названий уже не помню, в форумах стракбола попадались обсуждения.
в статье речь идёт скорее о более общем моделировании и прогнозировании, чем реальное 3д, реальная физика (приближенная), либо я вас не так понял,
И да и нет. Конечно моделирование боевых действий на разных уровнях (от стратегического до отделения) – различается, но есть общие вещи. На WOT уже можно имитировать батальонный уровень управления и ниже. Если посмотрите миникарту WOT, то принципиально она не отличается от тактических планшетов, сделанных как под страйкбол, так и различных ГИС в составе «ЕСУ ТЗ» (вроде как «единая система», а в реальности «лебедь, рак и щука» и конечно же «аналогофнет»).
Про «реальную 3Д». В основе симуляторов (ситуационное моделирование) – алгоритмы, которые часто сложно осознать: их масса и они обычно непростые. Есть конечно простые, типа минимальное отношение наступающих к обороняющимся (3:1), но в целом сложно «умом охватить» всю «механику поля боя».
Как раз, эти «3Д-вставки», "3Д погружения" (хотя настоящий 3D – это стереопары, но не суть), позволяют в режиме реального времени (т.е. не пошагово) и в режиме деловой игры (бизнес-симуляции) увидеть, как "вживую" работают эти алгоритмы. Совсем грубо: вы в "укрепах" (более заметно в 7х7 Vl уровень) в одном случае растягиваете линию обороны, в другом случае, концентрируете удар (это к модели концентрация огня \ сил на определённом участке) и смотрите как работают разные сценарии. Причем вы видите с командирского места (командира танка) эту механику (поведение), с точностью до единичного попадания (впрочем, как и обобщение - через мини-карту). Режим деловой игры с одной стороны позволяет увидеть механику (не только игровую, но и предметную), а с другой - добавляет зрелищность в изучение «скучных» алгоритмов.
Дополнительно приведу еще пример из WOT: значимость разведки. Вы можете иметь десять «слепых» тяжелых (сильно бронированных) танков, но вас легко разберет тройка небронированных, но с хорошим обзором легких танков. Прямая аналогия с поля боя вряд ли возможна, но "концептуально" (применяются иные средства поражения) - ровно также (недаром в C3 добавили разведку).
Когда симулятор работает на уровнях выше батальонного, то этих «мелочей» уже не видно, но многие элементы механики схожие (более сложные и главное - более критичные по последствиям). Конечно, даже в батальонном\ротном звене - масса разных моделей, но некоторые из них можно «прощупать» (разглядеть) в режиме "3Д погружения" в WOT. Примерно, как поведение микроорганизмов под микроскопом, оказывая на них различные воздействия, а потом обобщая результаты увиденного в концепцию поведения. При этом, ключевое преимущество, - не находясь на реальной передовой.
В итоге, «общее моделирование и прогнозирование» на «большой карте» большого полководца – это одно, но оно складывается из тактических «мелочей» и многие из этих даже «мелко мелочей» имеют схожие принципы «со стратегическим военным мышлением» (типа концентрация огня, безопасность флангов, отношение оборона \ наступление). Некоторые эти «мелко мелочи» - видны как "3Д обзор" игрока-танкиста, а сами «мелочи» - на тактической карте обстановки (правый нижний угол экрана).
Более верхние уровни управления – это обобщение более нижних и использование дополнительных (специфичных для своего уровня управления, с усиливающимся «туманом войны» и т.п.) алгоритмов анализа и прогнозирования. Но часто важно уметь "провалиться" вниз, чтобы увидеть "под микроскопом" общие закономерности.
С3, C4i и т.д. в основном фиксируют (описывают, формализуют, документируют) as is & to be в ручном режиме. Хотя на тактическом уровне отрисовка позиций может вестись (уже ведется) по gps, но не принципиально.
Следующий шаг – это «Военное вычислительное мышление», как военный симулятор (боты проигрывают разные сценарии боевых действий). Ситуационное моделирование обстановки «автоматом» полагаю, если и начинает использоваться для реального боевого применения, то только в передовых армиях и недавно. Это перспективное направление, но намного более сложное, чем, например, шахматные алгоритмы.
Видимо должны появится игры, которые реализуют стратегические основы. На примере WOT: если оттуда выбросить вязкую «детскую забаву» аркаду, типа попадания в маленький лючок танка, дерганье (точнее более грубое слово) из-за холма / укрытие (на мгновение высунул ствол, почти вслепую отстрелил и ушел обратно), а усилить именно тактические аксиомы, то получилась бы близкая к реальности стратегия (причем не пошаговая). Имеется ввиду, что успех сражения должен определяться такими аксиомами, как концентрация огня на определённом участке (артиллерия - «богом войны» будет еще долго, но речь применительно к WOT и о танках), организацией перекрёстного огня (небольшой охват противника с фланга) и т.п. При этом должна учитываться точность орудий (и еще 100+ факторов): или точный Хаймарс (уже в 2000 было завершено перевооружение НАТО и с тех пор «неуправляемый» - это только один из режимов, а все остальные «управляемые») или отечественное «старье», преобразующее поля в «лунные пейзажи» (про краснополь знаю, но это тоже старье).
В WOT элементы концентрации огня и перекрестный огонь хорошо можно моделировать в игровом режиме, например, «в укрепах», что иногда позволяет «выходить на ноль» путем противопоставления более совершенной тактике более высоким скилам игроков противника (аркады, умения быстро жать кнопки, выцеливания лючков и т.п.). Клон WOT с минимизацией аркады имеет хорошие шанс стать игрой другого класса.
Похожим к задаче анализ «закреплённых и незакрепленных флангов» может быть сценарий «укрепления фланга» типа «Бег к морю» — название операций как немецких, так и англо-французских войск на Западном фронте Первой мировой войны, имевших цель охватить фланги противника. Такой же «бег к морю» - также часто наблюдаем в WOT (что море, что красная линия периметра в WOT – ограничивают этот маневр).
Полагаю, что «Военное вычислительное мышление» - как тактический симулятор (точнее разных уровней, и оперативного тоже) для реальной армии – востребованная задача, но явно ей в текущей РФ не будут заниматься: первый шаг это С3, C4i (их бы сделать), кстати, СССР был в этой (АСУВ) области передовиком, см. – ПАСУВ МАНЕВР.
Насколько понял: нарисовать аналогичную (заявка на отпуск) шапшной картинки (голосование) - большая сложность. Я полагал, что в нотации "событийная семантика" (как на рисунке в шапке) схема алгоритма будет более понятной, чем RDF - граф.
Или еще круче, просить нарисовать эту схему на RDF
Вроде как есть инструменты автогенерации схемы (графа) по скрипту (RDF), типа:
Часть скрипта мной же и показана. Конечно такой grapher нарисует мало похожее на "стройную" ЕРС, но все связи передаст в точности.
Кстати, есть ли LD-инструменты, которые могли бы "уложить" RDF в нечто похожее на ЕРС, т.е. поток workflow уложить вертикально, а окружение функции - горизонтально (хотя бы как кластер в dot)? Конечно, вместо "кругов - овалов" - использовать набор примитивов: шестиугольник для событий, скругленный прямоугольник для функций и т.п.
Меня пугает, что вместо BPM упорно упоминаете BMP. Мы точно говорим про BusinessProcessManagement?
В продолжение: "Сравнение субъектно-событийного подхода с существующими BPM системами" как "событийная семантика" vs BPM, подскажите, чем она лучше BPMN?
Итак, никакие связи не только не выпадают, а все, что вы нарисуете (именно нарисуете) на EPC-диаграмме, в EventFlow движке можно декомпозировать до исполняемых событий и свойств артефактов и без программирования создать семантическую модель процесса
Так я и прошу просто "нарисовать" такую "семантическую модель процесса" (про отпуск). Собственно, мой вопрос остаётся прежним.
Кроме того, когда читаю "Событийная онтология vs объектная" создаётся впечатление, что речь идет об обычных BPM и EA (архитектура предприятия), которые "по определению" включают в себя как Событийную онтологию (архитектура процессов, динамика), так и объектную (структуры, включая орг-структуру и ролевую).
Да, этот текст совсем не на тему BMP, не про нотации. И поэтому он в разделе "семантика".
Хотелось бы пояснить разницу «этого текста» и BPM на простом примере. Полагаю, что процессы, (алгоритмы, логика), события, действия (функции), исполнители (акторы) и артефакты (предметы, документы и т.п.) – они что в «этом тексте», что в BPM имеют одни и те же понятия, впрочем, как и связи (семантические связи) между ними. Или «событие» - тут это что-то иное?
Для примера возьмем простенькую схемку процесса в EPC, что есть базовая нотация ARIS, который в свою очередь классический пример классического BPM (это тот, который неисполняемый):
В ней (EPC) полагаю, что присутствуют: событийные семантики, Базовые семантические примитивы в событийной онтологии, семантически определенные отношения, базовые семантические примитивы и т.п.
Ровно также в BPM «В событийной семантике деятельность описывается последовательностью актов» или нет?
По аналогии с:
:john :hasMother :helga— У Джона есть мама и её зовут Хельга. :john :hasFather :henrich— а отца Джона зовут Генрих
Триплеты, детализирующие объект «Функция», например, Функцию 1:
:Роль 1 :Исполняет функцию :Функция 1.
:Функция 1 :Имеет результат :Артефакт 1.
…
Если в EPC все объекты представить в виде кружка (вершина графа), то получится «настоящий» (привычный) семантический граф, т.е. фактически в нотациях BPM для каждого типа объекта указан свой графический примитив, типа:
Т.е. это такой же граф связей (Linked Data и т.п.). Изначально (начало 90-х, ARIS\EPC) именно этот подход вроде как был заложен в классический BPM.
Вопрос: в чем отличие приведённого «триплетного BPM \ EPC» от событийной семантики и как приведенный алгоритм (цветная картинка) в нотации EPC будет представлен событийной семантикой, EventFlow, DataFlow и прочей «Архитектурой на основе событийной семантики» (графически + триплетами)?
Понятно, что в представлении EventFlow \ DataFlow никакие объекты и связи не должны «выпасть» (по отношению к EPC), иначе не будет однозначно воспроизведен приведённый алгоритм.
Есть понятие BPM, т.е. наука по процессам. Может быть «событийная семантика» = «событийная онтология» = BPM?
Под «изменением» понимается как создание нового индивида
Может «изменение» - это просто результат процесса или сам процесс?
Так покраска забора может быть описана и как действие, состоящее из множества актов: «подготовил кисть», «смешал краску», «нанес первый слой», «нанес второй слой».
Может это просто нарезка процесса на подпроцессы? Это хорошо визуализируется VAD диаграммой как сквозной процесс.
На примере ЕРС (ARIS), т.е. самой что не наесть "событийной" нотации. Есть функция (процедура), ее выполняет исполнитель (как тут называют актор), для выполнения процедуры требуются инструменты. Есть входы (заготовки) и выходы (продукты).
Это рисуется, а связи так и называют: Исполнитель > связь типа «исполняет» > функция №1.
Подробнее типы связей см. Требования к использованию типов соединений (стр. 85)
Есть связи для входных документов (заготовок) в функцию, и выходных (продукт функции).
Жизненный цикл документов описывается через их стадии (docflow): шаблон заявления – переход – заявление «согласовано» - переход - заявление «утверждено» и т.д.
Однако, если обратить внимание на содержание происходящего - действие принятия решения, – то для его моделирования целесообразнее, конечно же, использовать событийную семантику и вместо атрибута фиксировать один из актов: «утвердил» или «отклонил». В этом случае принятие решения будет записано с помощью одного утверждения «Иванов отклонил документ».
Это же и есть "просто" моделирование процессов. В терминах BPM это укладывается во многие нотации, начиная с ЕРС, и в них также присутствуют семантические связи, которые явно указаны прямо в редакторе типа ARIS.
Это все к тому, что может велосипед уже изобретен и он называется BPM (EPC, ARIS)? Там также все основано на семантике, только не пишутся триплеты в явном виде. Причем это не только для алгоритмов (workflow), но и для описания структур (иерархий), включая орг-структуру и связь с ролевой моделью (роль в процессе), и для описания иерархий ИТ-систем и продуктов.
Или в статье про что-то иное, совсем не на тему BPM?
Если все же на тему BPM, то почему не использовать понятийный аппарат BPM?
1 Также есть (должно быть) ограничение по максимальной скорости, т.е. формула: ограничение по скорости и по мощности одновременно.
2 Мощность. 250 вт - это уже мопед. Велосипед - это ДО 250 Вт. В продаже таких самокатов не видел, т.к. должна быть указана цифра 249 Вт (и менее). Вообще обычно обзоры мотор-колес начинаются с цифры 250 Вт, т.е. уже "за рамками".
3 Мощность 249 Вт (или 250 - 0,00001) - это мало ("не едет"). У меня s3 Куго, там 350. Сомневаюсь, что в прокатах "честные 250", как написано тут:
https://www.nn.ru/text/transport/2021/05/17/69915263/
4 Все эти ухищрения "программного снижения мощности" типа "мотор-колесо на 4 кВт, но я програмно снизил до 249,9 Вт" (т.е. это теперь уже велосипед) - это обычно ровно мопедная тема на 50 кубов: 80% предложений в магазинах прямо говорит, что "по документам 50", а реально воткнут 110 (125) кубовый движок. Иначе техника "50-кубов" без этих "формально 50" - не покупалась бы, т.к. на ней ехать почти невозможно, тем более двум взрослым. Полагаю, что такое будет (есть) с электросамокатами \ велосипедами.
Если самоделка, то кроме как ориентироваться на шильдики (в первую очередь набитые цифры на мотор-колесе) - никаких доступных инструментов нет. Я когда заказываю у китайцев мотор-колеса, прошу вообще не набивать на них значение мощности (ударные клейма стоят недорого).
5 Начинается игра с "пиковой" (до секунды) / "максимальной" (минуты) / "номинальной" (крейсерской) мощностью электросамоката \ велосипеда \ мопеда. Кстати эти (пиковые, максимальные) параметры не выдуманные, а задаются в настройках BMS (battery management system / система управления батареи): попробуйте там существенно увеличить цифру порогового пикового значения мощности и смотрите откуда пойдет дым.
6 Полагаю, что реально обеспечить контроль мощности и скорости "в прокате" можно только путем выпуска и продажи собственного "отечественного" контроллера мотор-колеса и заменой на него на каждом прокатном самокате. Только это утопия.
Утопией также является производство отечественных электросамокатов, т.к. это потребовало бы повторную индустриализацию страны, что в свою очередь потребовало бы мобилизацию (но в хорошем смысле слова) - науки и образования. Сейчас если поставить простую задачу: реально отечественный современный (не хуже китайских) массовый (дешевый) электросамокат - это привело бы к переосмыслению существующей высокотехнологичной составляющей отечественной промышленности.
Так вроде по моей ссылке доходчиво показано на примере BPM (ЕРС). Восемь объектов, синим - тип связи между ними, рядом соответствующие триплеты.
В ZettelKasten ровно такой же подход, просто за объектами не закреплен графический примитив и они на графе все одинаковыми кружками отображаются.
И в dot, упомянутый Вами, ровно такие же триплеты (А > B, "связь такая то"), только их в graphviz так не называют, но суть не меняется.
Все тройки (вся семантика) уже есть "под капотом" что ZettelKasten, что BPM, например: https://habr.com/ru/post/708026/comments/#comment_25053928
Пользователь явно не видит этих отношений (троек: объект -> связь -> объект \ свойство) в своей программе (интерфейсе), но он их создает (триплеты). По ним строятся, что графы ZettelKasten, что схемы BPM. Проблема лишь, чтобы "их вытащить" и сделать экспорт в стандартный формат.
Возражение в том, что пользователю особо поддерживать ничего не нужно, триплеты - это внутренний механизм, присутствующий в самом ZettelKasten \ BPM, но просто так не называемый. Пользователь каждый раз сам рисует или вводит через ссылки эти связи - триплеты. Нужно просто уметь их выгрузить в стандартном формате.
Web публикацию бесплатную в Obsidian как сделать? Может сторонние средства есть простые?
В основном из-за этого перешел на Logseq.
Еще бы хотелось, чтобы в ZettelKasten можно было сразу триплетами (RDF или иное) связи строить (скриптами логику \ семантику дописывать \ править). И выгружать граф из Obsidian \ Logseq прямо в RDF и воспроизводить его в других ZettelKasten. К этому хоть движется какой-либо ZettelKasten? Про сложные системы LD знаю, интересует LD уровня "для домохозяйств".
В статье под этим понимают роль, а не ПО.
Очень оптимистично и самонадеянно.
Готово
Можно и этот (для начала), но на нем, полагаю, что в основном "драконо-почитатели", хотелось бы что-то из форумов (площадок) BPM (BPM-почитатели), мы же схемы бизнес-процессов рисовать планируем.
На каких-либо BPM - площадках обсуждали Дракона для формализации БП? Чтобы получился не "холодный" заход (звонок), а публика была уже немного "прогрета".
Предлагаю вначале понять, чего не хватает в ЕРС для описания БП. И что нужно заимствовать из Дракон? Предложите площадку для обсуждения.
Далее нужно формализовать этот «ЕРС-D» (дракон).
Еще лучше (можно параллельно) составить универсальный Smart Designer для БП, который может по «Одной и той же табличке с алгоритмом в столбик» строить схемы в разных нотациях, например, на ЕРС, Драконе и потом ЕРС-D. Для начала можно начать с ЕРС, чем я и занимаюсь:
Редакторы блок-схем и ARIS Smart Designer (на примере EPC)
Это было предложение собрать Smart Designer на Falang.io. Однако по Falang.io не нашел информации, он есть на github? Если это закрытое ПО, - то не стоит и начинать. Так же для меня загадка: придумывают новые редакторы, так почему формат файла xml (хранение схемы БП) не заимствовать от существующих, например, drawio?
Смысл универсального Smart Designer для БП в том, что человек, вообще не знающий ни одной нотации БП, расписал бы «в столбик» пошагово свой процесс, начал кнопку «показать» и увидел, как его пошаговый процесс выглядит в разных нотациях. И выбрал для себя наиболее понятную.
До универсального Smart Designer (который умеет строить схему по нотациям, т.е. более чем одной) применительно к описанию БП нужно сделать (повторить АРИСовский) хотя бы для одной из нотаций для БП. Желательно Smart Designer (БП) построить не на каком-нибудь эксклюзиве, а на чем-то очень распространенным, типа drawio или visio.
Финальный шаг - прикрутить к полученному LD. И тогда все забудут про АРИС и приручат Дракона (БП-Дракона).
Посмотрел. Простенько как-то. Даже для начала 90-х не впечатлительно.
1 На форуме Дракона несколько лет назад встречались откровения, что не может Дракон про бизнес-процессы. WorkFlow может, а вот что-то подобное ЕРС - нет.
На указанных примерах вижу, что события ЕРС (шестиугольник) - в Дракон это "нижняя половина шестиугольника" (порча \ утрата браслета, хотя в книжке "Книга алгоритмов дракон" встречаются "зачем-то" и другие "альтернативные" обозначения событий), а роли - указываются в верхнем прямоугольнике "сдвоенного прямоугольника" (роли + операции). Наглядность и понятийность явно хуже чем в ЕРС.
2 Для описания бизнес-процессов нужно указать, кроме событий, кто выполняет операцию (система, актор, исполнитель, роль и т.п.), также: какими инструментами (например, ИТ-система) и какие входы и выходы у операции (функции, действия), т.е. фактически рядом с WorkFlow показать DocFlow. Пример:
https://habr.com/ru/post/708026/comments/#comment_25053928
3 Предлагаю подумать над "ответвлением": "Драконовские бизнес-процессы" или BPM-DRAKON, как скрещивание Дракона и ЕРС. Или адаптация ЕРС под Драконовские идеи, типа левый - основной ствол WorkFlow (ЕРС такой подход не содержит) и др. В приведенных примерах бизнес-процесс смотрится не "ВРМ-образно", а всего то нужно вместо "половины" шестиугольника нарисовать правильный шестиугольник, как в ЕРС (полный и красного цвета), роли выделить явно (различимо) и др.
4 Еще лучше: сразу сделать BPM (ЕРС) \ Дракон на принципах Linked Data. Что-то подобное обсуждалось:
https://habr.com/ru/post/708026/comments/#comment_25055686
LD-инструменты, которые могли бы "уложить" RDF в нечто похожее на ЕРС, т.е. поток workflow уложить вертикально, а окружение функции - горизонтально (хотя бы как кластер в dot)?
Применительно к ГОС-ТОП-менеджменту (вкл., около государственные корпорации, банки и т.п.). Объект, которым управляет система управления, оказался намного более сложным, чем существующая примитивная система управления (этот самый ТОП-менеджмент, который управляет Объектом).
п.1 Более 90% современного ТОП-менеджмента (ТОП-предприятий, ГосДу*ы и т.п.) - это не случайные люди, т.е. их проф-квалификация - вообще значения не имеет при постановке на пост. Совсем другие критерии отвечают за замещение таких ТОП-вакансий (круг друзей - сослуживцев, преданность и т.п.). Есть исключения, типа главы ЦБ, но они редкие.
п.2 Что делать, если Объект оказался намного более сложным, чем примитивная система управления этим объектом? Развивать проф-навыки ТОП-менеджмента (улучшать систему управления) - тупик, см. п.1.
п.3 Проще сделать сам Объект более примитивным, чтобы их уровень сложности сравнялся и "система управления оказалась в зоне своего комфорта". Это и происходит сегодня: деградация "всего", кроме давно деградированной системы управления в РФ. Основная цель ТОП-ов - это поддержка имиджа своего личного и своего подразделения в глазах руководства и ТОП-ов смежных подразделений, чтобы хотя бы формально "соответствовать должности".
Принципы видимо.
ARIS Smart Designer (EPC) - это не совсем "последовательность бизнес-процессов". Это скорее "Связанные данные", которые умеют в ["картинка" -> "таблица"] и обратно. Это позволяет заполнять таблички и получать схемы, т.е. можно нотацию вообще не знать.
Второй плюс: т.к. у нас есть таблица со ВСЕМИ данными о процессе, то это уже BPM - хранилище. Так и до "большого АРИСа" недалеко.
Полагаю, что у Дракона так и не появилась ветка "бизнес-процессы" (подобие EPC).
Редакторы блок-схем и ARIS Smart Designer (на примере EPC)
Есть ARIS Smart Designer (EPC). Хотелось бы его повторить на чем-то еще кроме ARIS Express, например, Drawio, Falang.io, DgrmJS и т.п.
Подготовил макет (прилагаю) Excel 2016 + Drawio в части Event + Function (только два объекта из EPC, чтобы идея была проще видна). Такое повторить бы в реальном времени, как в ARIS Smart Designer: автоматическое обновление, таблицу размещать непосредственно рядом со схемой процесса. Была бы интересна интеграция "встроенной" таблицы с Excel и Google Sheets.
К макету: нужно указать пути (Drawio + Temp) на листе «Set» (нужно локально поставить Drawio, можно portable). Далее на листе List1 нажимать «в паре» кнопки: «Выгрузка в файл» и «Запуск файла». Также можно нажимать и другие кнопки, которые создают новые или удаляют Event + Function. Это функции: добавить объект (Event or Function) вниз (Добавление), вставить объект в указанное место (выбранную строку, Вставка), удалить конкретный объект (выбранную строку), очистить (удалить все). В ARIS Express добавляется объект только в конец, а потом перемещается вручную кнопками "вверх" \ "вниз". В макете показан более удобный вариант.
Пользователю будут отображаться только столбцы с названиями Event & Function (остальные строки в Excel можно скрыть).
Простой (только WorkFlow) Макет на Excel 2016. Половина кода - файловые преобразования: чтобы русские буквы были в Drawio, пришлось из стандартного Excel ASCII делать Unicode noBOM.
Макет посложнее EPC: WorkFlow + DocFlow тут
Не интересовался коммерческими военными симуляторами - прогнозерами, но десять лет с небольшим назад некоторые западные АСУВ (C4i) тактического звена продавались открыто.
В них было общее ядро, отдельная ветка для своей армии (без продаж конечно), отдельная коммерческая - "для гражданских применений", хоть для страйкбола, хоть МЧС и других силовиков. Названий уже не помню, в форумах стракбола попадались обсуждения.
И да и нет. Конечно моделирование боевых действий на разных уровнях (от стратегического до отделения) – различается, но есть общие вещи. На WOT уже можно имитировать батальонный уровень управления и ниже. Если посмотрите миникарту WOT, то принципиально она не отличается от тактических планшетов, сделанных как под страйкбол, так и различных ГИС в составе «ЕСУ ТЗ» (вроде как «единая система», а в реальности «лебедь, рак и щука» и конечно же «аналогофнет»).
Про «реальную 3Д». В основе симуляторов (ситуационное моделирование) – алгоритмы, которые часто сложно осознать: их масса и они обычно непростые. Есть конечно простые, типа минимальное отношение наступающих к обороняющимся (3:1), но в целом сложно «умом охватить» всю «механику поля боя».
Как раз, эти «3Д-вставки», "3Д погружения" (хотя настоящий 3D – это стереопары, но не суть), позволяют в режиме реального времени (т.е. не пошагово) и в режиме деловой игры (бизнес-симуляции) увидеть, как "вживую" работают эти алгоритмы. Совсем грубо: вы в "укрепах" (более заметно в 7х7 Vl уровень) в одном случае растягиваете линию обороны, в другом случае, концентрируете удар (это к модели концентрация огня \ сил на определённом участке) и смотрите как работают разные сценарии. Причем вы видите с командирского места (командира танка) эту механику (поведение), с точностью до единичного попадания (впрочем, как и обобщение - через мини-карту). Режим деловой игры с одной стороны позволяет увидеть механику (не только игровую, но и предметную), а с другой - добавляет зрелищность в изучение «скучных» алгоритмов.
Дополнительно приведу еще пример из WOT: значимость разведки. Вы можете иметь десять «слепых» тяжелых (сильно бронированных) танков, но вас легко разберет тройка небронированных, но с хорошим обзором легких танков. Прямая аналогия с поля боя вряд ли возможна, но "концептуально" (применяются иные средства поражения) - ровно также (недаром в C3 добавили разведку).
Когда симулятор работает на уровнях выше батальонного, то этих «мелочей» уже не видно, но многие элементы механики схожие (более сложные и главное - более критичные по последствиям). Конечно, даже в батальонном\ротном звене - масса разных моделей, но некоторые из них можно «прощупать» (разглядеть) в режиме "3Д погружения" в WOT. Примерно, как поведение микроорганизмов под микроскопом, оказывая на них различные воздействия, а потом обобщая результаты увиденного в концепцию поведения. При этом, ключевое преимущество, - не находясь на реальной передовой.
В итоге, «общее моделирование и прогнозирование» на «большой карте» большого полководца – это одно, но оно складывается из тактических «мелочей» и многие из этих даже «мелко мелочей» имеют схожие принципы «со стратегическим военным мышлением» (типа концентрация огня, безопасность флангов, отношение оборона \ наступление). Некоторые эти «мелко мелочи» - видны как "3Д обзор" игрока-танкиста, а сами «мелочи» - на тактической карте обстановки (правый нижний угол экрана).
Более верхние уровни управления – это обобщение более нижних и использование дополнительных (специфичных для своего уровня управления, с усиливающимся «туманом войны» и т.п.) алгоритмов анализа и прогнозирования. Но часто важно уметь "провалиться" вниз, чтобы увидеть "под микроскопом" общие закономерности.
С3, C4i и т.д. в основном фиксируют (описывают, формализуют, документируют) as is & to be в ручном режиме. Хотя на тактическом уровне отрисовка позиций может вестись (уже ведется) по gps, но не принципиально.
Следующий шаг – это «Военное вычислительное мышление», как военный симулятор (боты проигрывают разные сценарии боевых действий). Ситуационное моделирование обстановки «автоматом» полагаю, если и начинает использоваться для реального боевого применения, то только в передовых армиях и недавно. Это перспективное направление, но намного более сложное, чем, например, шахматные алгоритмы.
Видимо должны появится игры, которые реализуют стратегические основы. На примере WOT: если оттуда выбросить вязкую «детскую забаву» аркаду, типа попадания в маленький лючок танка, дерганье (точнее более грубое слово) из-за холма / укрытие (на мгновение высунул ствол, почти вслепую отстрелил и ушел обратно), а усилить именно тактические аксиомы, то получилась бы близкая к реальности стратегия (причем не пошаговая). Имеется ввиду, что успех сражения должен определяться такими аксиомами, как концентрация огня на определённом участке (артиллерия - «богом войны» будет еще долго, но речь применительно к WOT и о танках), организацией перекрёстного огня (небольшой охват противника с фланга) и т.п. При этом должна учитываться точность орудий (и еще 100+ факторов): или точный Хаймарс (уже в 2000 было завершено перевооружение НАТО и с тех пор «неуправляемый» - это только один из режимов, а все остальные «управляемые») или отечественное «старье», преобразующее поля в «лунные пейзажи» (про краснополь знаю, но это тоже старье).
В WOT элементы концентрации огня и перекрестный огонь хорошо можно моделировать в игровом режиме, например, «в укрепах», что иногда позволяет «выходить на ноль» путем противопоставления более совершенной тактике более высоким скилам игроков противника (аркады, умения быстро жать кнопки, выцеливания лючков и т.п.). Клон WOT с минимизацией аркады имеет хорошие шанс стать игрой другого класса.
Похожим к задаче анализ «закреплённых и незакрепленных флангов» может быть сценарий «укрепления фланга» типа «Бег к морю» — название операций как немецких, так и англо-французских войск на Западном фронте Первой мировой войны, имевших цель охватить фланги противника. Такой же «бег к морю» - также часто наблюдаем в WOT (что море, что красная линия периметра в WOT – ограничивают этот маневр).
Полагаю, что «Военное вычислительное мышление» - как тактический симулятор (точнее разных уровней, и оперативного тоже) для реальной армии – востребованная задача, но явно ей в текущей РФ не будут заниматься: первый шаг это С3, C4i (их бы сделать), кстати, СССР был в этой (АСУВ) области передовиком, см. – ПАСУВ МАНЕВР.
Action: Instance: ЗаявкаНасколько понял: нарисовать аналогичную (заявка на отпуск) шапшной картинки (голосование) - большая сложность. Я полагал, что в нотации "событийная семантика" (как на рисунке в шапке) схема алгоритма будет более понятной, чем RDF - граф.
Вроде как есть инструменты автогенерации схемы (графа) по скрипту (RDF), типа:
https://www.ldf.fi/service/rdf-grapher
Часть скрипта мной же и показана. Конечно такой grapher нарисует мало похожее на "стройную" ЕРС, но все связи передаст в точности.
Кстати, есть ли LD-инструменты, которые могли бы "уложить" RDF в нечто похожее на ЕРС, т.е. поток workflow уложить вертикально, а окружение функции - горизонтально (хотя бы как кластер в dot)? Конечно, вместо "кругов - овалов" - использовать набор примитивов: шестиугольник для событий, скругленный прямоугольник для функций и т.п.
Меня пугает, что вместо BPM упорно упоминаете BMP. Мы точно говорим про Business Process Management?
В продолжение: "Сравнение субъектно-событийного подхода с существующими BPM системами" как "событийная семантика" vs BPM, подскажите, чем она лучше BPMN?
"субъектно-событийный подход" = "событийная семантика"?
Так я и прошу просто "нарисовать" такую "семантическую модель процесса" (про отпуск). Собственно, мой вопрос остаётся прежним.
Кроме того, когда читаю "Событийная онтология vs объектная" создаётся впечатление, что речь идет об обычных BPM и EA (архитектура предприятия), которые "по определению" включают в себя как Событийную онтологию (архитектура процессов, динамика), так и объектную (структуры, включая орг-структуру и ролевую).
Ваша "событийная семантика" как то связана с S-BPM (в S-BPM не dataflow архитектура)? https://ekonomika.snauka.ru/2014/11/6316
А "шапшную" картинку лучше включать в состав статьи. Я про нее и не догадался:
Хотелось бы пояснить разницу «этого текста» и BPM на простом примере. Полагаю, что процессы, (алгоритмы, логика), события, действия (функции), исполнители (акторы) и артефакты (предметы, документы и т.п.) – они что в «этом тексте», что в BPM имеют одни и те же понятия, впрочем, как и связи (семантические связи) между ними. Или «событие» - тут это что-то иное?
Для примера возьмем простенькую схемку процесса в EPC, что есть базовая нотация ARIS, который в свою очередь классический пример классического BPM (это тот, который неисполняемый):
В ней (EPC) полагаю, что присутствуют: событийные семантики, Базовые семантические примитивы в событийной онтологии, семантически определенные отношения, базовые семантические примитивы и т.п.
Ровно также в BPM «В событийной семантике деятельность описывается последовательностью актов» или нет?
По аналогии с:
:john :hasMother :helga—У Джона есть мама и её зовут Хельга.:john :hasFather :henrich—а отца Джона зовут Генрихhttps://habr.com/ru/post/17946/
Составляем EPC-триплеты:
Workflow – триплеты (черные стрелки):
:Функция 1 :hasParent :Событие 1.:Функция 2 :hasParent :Функция 1....
Триплеты, детализирующие объект «Функция», например, Функцию 1:
:Роль 1 :Исполняет функцию :Функция 1.:Функция 1 :Имеет результат :Артефакт 1.…
Если в EPC все объекты представить в виде кружка (вершина графа), то получится «настоящий» (привычный) семантический граф, т.е. фактически в нотациях BPM для каждого типа объекта указан свой графический примитив, типа:
:Функция 1 :есть объект типа :Функция.:Функция :имеет примитив :Скругленный зеленый прямоугольник.Т.е. это такой же граф связей (Linked Data и т.п.). Изначально (начало 90-х, ARIS\EPC) именно этот подход вроде как был заложен в классический BPM.
Вопрос: в чем отличие приведённого «триплетного BPM \ EPC» от событийной семантики и как приведенный алгоритм (цветная картинка) в нотации EPC будет представлен событийной семантикой, EventFlow, DataFlow и прочей «Архитектурой на основе событийной семантики» (графически + триплетами)?
Понятно, что в представлении EventFlow \ DataFlow никакие объекты и связи не должны «выпасть» (по отношению к EPC), иначе не будет однозначно воспроизведен приведённый алгоритм.
Есть понятие BPM, т.е. наука по процессам. Может быть «событийная семантика» = «событийная онтология» = BPM?
Может «изменение» - это просто результат процесса или сам процесс?
Может это просто нарезка процесса на подпроцессы? Это хорошо визуализируется VAD диаграммой как сквозной процесс.
На примере ЕРС (ARIS), т.е. самой что не наесть "событийной" нотации. Есть функция (процедура), ее выполняет исполнитель (как тут называют актор), для выполнения процедуры требуются инструменты. Есть входы (заготовки) и выходы (продукты).
Это рисуется, а связи так и называют: Исполнитель > связь типа «исполняет» > функция №1.
Подробнее типы связей см. Требования к использованию типов соединений (стр. 85)
https://cssrzd.ru/news/BusinesProcess_RZD.pdf
Есть связи для входных документов (заготовок) в функцию, и выходных (продукт функции).
Жизненный цикл документов описывается через их стадии (docflow): шаблон заявления – переход – заявление «согласовано» - переход - заявление «утверждено» и т.д.
Это же и есть "просто" моделирование процессов. В терминах BPM это укладывается во многие нотации, начиная с ЕРС, и в них также присутствуют семантические связи, которые явно указаны прямо в редакторе типа ARIS.
Это все к тому, что может велосипед уже изобретен и он называется BPM (EPC, ARIS)? Там также все основано на семантике, только не пишутся триплеты в явном виде. Причем это не только для алгоритмов (workflow), но и для описания структур (иерархий), включая орг-структуру и связь с ролевой моделью (роль в процессе), и для описания иерархий ИТ-систем и продуктов.
Или в статье про что-то иное, совсем не на тему BPM?
Если все же на тему BPM, то почему не использовать понятийный аппарат BPM?