Заметки с XII рабочей встречи INCOSE RUS по проблемам системной инженерии.

Политическая информация Русское (по языку, а не по стране) отделение INCOSE продолжает работать по-прежнему, игнорируя любые санкции и попытки остановить жизнь, работу, исследования и общение. Название тоже не меняем, на формальные аспекты ситуации внимания не обращаем: пусть бюрократы заняты своим, а мы будем заниматься делом. Чтобы насилия в мире было поменьше, нужно иметь хорошую (то есть системную) инженерию, и не только киберфизических систем, но и всего инженерного стека систем разных уровней -- вещества, киберфизики (с софтом), существа, личности, организации, сообщества, общества, человечества. Напастей (эпидемий, войн, природных явлений, астероидов и так далее) в мире много, их число не будет уменьшаться, старые проблемы будут возвращаться вновь и вновь, а самые большие неприятные неожиданности нам пока ещё неизвестны. К этим проблемам нужно быть готовым и лично, и организационно. Так что решаем не прямо сегодняшнюю ситуацию, а играем вдолгую -- и стараемся работать быстро. Мы смеялись, что INCOSE в Vision 2025 и 2035 берёт ответственность аж за всю Землю, потому как "мы системщики и инженеры, если не мы разберёмся в этой сложности, то кто же?". Но по факту мы работаем как раз в этом направлении. Общие архитектурные закономерности многомасштабного устойчивого управления Вечерний четверговый мой доклад был по традиции о танцах: на этом примере мы разбирались с устойчивым (robustness) управлением -- это которое при неожиданных масштабных воздействиях со стороны внешней среды не срывается, не приводит к краху/катастрофе/поломке/уничтожению системы. 1. Внимание и сознание для системного мышления Внимание нужно прежде всего для выделения им архитектурных объектов в составе системы. Так что нам нужно попробовать поразбираться с танцем как сложным примером динамической системы, чтобы лучше понять про управление вниманием и сознание как механизм для этого управления. Для этого используем различные объяснительные механистичные и (по возможности) безмасштабные/панпсихические теории сознания и внимания, без которых системное мышление оказывается невозможно (второй абзац в https://ailev.livejournal.com/1622664.html). Внешнее восприятие (тело), внутреннее восприятие (сома): биомеханика с биостатикой и биодинамикой как внешнее описание против соматомеханики с соматостатикой и соматомеханикой как внутреннее операционное восприятие. Порождающее моделирование мира и себя: не факт, что одно и то же (моделирование-то ведётся восприятия в рамках active inference, а не "объективно существующих объектов"). Процедуры знаниевой передачи субъективного опыта через 4Е и переход к 4D (выполнить подготовку к измерению, потом провести измерение и сказать "то, что измерено -- это и есть X". Показать таким образом несколько разных вариантов/в разных контекстах, предложить обобщить в класс/тип). Важность телесной проработки для управления вниманием и работы с сознанием (ходы на TAE: внимание к онтологическому дребезгу, к архитектурному felt sense, вербализации интуиции), близость курса собранности и необходимость его прохождения как для управления вниманием в танце, так и для управления вниманием в ходе инженерного проекта. 2. Математическое и физическое моделирование в инженерии Математику используем как foundational ontology и upper ontology для абстрактных объектов, а физику используем как функциональные объекты. Всё же вместе -- это работа с типами, она мало отличается от того, что мы обычно делаем в архитектурном моделировании (подробней в "Физмат-моделировании и компактификации/универсализации знаний", https://ailev.livejournal.com/1621997.html и чуть более ранние рассмотрения в https://ailev.livejournal.com/1619901.html и https://ailev.livejournal.com/1619346.html и даже https://ailev.livejournal.com/1618414.html). Математика и физика -- это очень компактные описания, их типы удобны для моделирования самых разных явлений. Так, можно использовать идеи вариационного исчисления для описания соматодинамики (пример с "лестницей усилий"), и это оказывается легче и проще, чем специально разработанное для этих целей "моделирование образами и аналогиями". Всё-таки физики и математики довольно долго работали над компактификацией своих описаний, и этим идеям стоит учить не как идеям именно механики и математики, а как идеям компактного описания сложного мира, идеям моделирования. Математику, физику и классические системные (физичность, функциональность, стоимость и т.д.) рассмотрения нужно использовать совместно. Так математики-физики в своих текстах допускают множество классических ошибок, с которыми уже разобрались системные инженеры. Пример ошибок для Markov/Friston blanket (и эти ошибки автоматически не исправляются переходом на физико-математическое описание): -- неразличение карты и территории (MB это описание или таки часть физической системы) -- неразличение функционального описания с портами и конструктивного/модульного с интерфейсами (когда говорим о физике и формулах состояния в момент operations, то это обычно функциональное описание, но потом вдруг разговор не про порты и потоки а про "из чего сделано" и неожиданно всё становится про модули и интерфейсы). Это очень больное место: Якобсон со товарищи в Essence пытался его пройти через ALPHA как функциональные объекты и work products как физические, но поскольку у него ещё и путаница по первому пункту, то получился онтологический винегрет. У людей в active inference с этим ничуть не лучше (тем более что "физические объекты" в части их типов и аннотирования этих физических типов объектов математическими типами из математики -- это таки функциональные объекты, но в бытовом языке physical objects это конструктивы/модули, в частности в ISO 15926 ровно такое наименование, по контрасту с functional objects). -- путаница интерфейса и интерфейсного модуля (там два интерфейса: вовнутрь и наружу). Есть про эту путаницу отдельный раздел у меня в учебнике системного мышления, очень частая ошибка). 3. Контроллеры в составе систем и underactuated robotics. Общие архитектурные закономерности построения систем должны даваться один раз для всех масштабов в эволюционном/системном/инженерном стеке, и тут мы переходим к панпсихическим рассмотрениям Дойля (от киберфизики к живому, устойчивые системы управления с большим разнообразием характеристик их элементов и множественными обратными связями внутри контроллера, https://ailev.livejournal.com/1622346.html) и Фристона (от живого через киберфизику вообще к молекулам, active inference с enactive восприятием, раздел "прагматический поворот: active inference" в https://ailev.livejournal.com/1619025.html). Работы Дойля интересны не только своим содержанием (математика и архитектурные рекомендации для создания быстрых и точных систем из медленных и неточных элементов), но и отношением к этим работам со стороны биологов: они их не воспринимают, есть барьер в понимании универсальности результатов по части многомасштабности/трансдисциплинарности. Это означает, что мы точно так же столкнёмся с непониманием в части "мышления" (онтологического понимания, "как устроено"). В части инженерии (нормативного понимания) у Дойля тоже проблемы: идеи intelligent design (жизнь создана богом, а не эволюцией -- и не трогайте бога своей эволюцией) почему-то распространены и им трудно возражать, а противоположная идея design only by evolution (жизнь создана эволюцией, а не богом -- и не трогайте эволюцию) оказывается так же неприемлема. Intelligent design by engineer для жизни абсолютно необходим. Если мы понимаем, как устроено управление, чтобы наше медленное общество действовало быстро в условиях внешних и внутренних опасностей (это не вопрос, будут ли опасности, вопрос в том только, когда они будут), то наш долг использовать это понимание для социальной инженерии: точно так же, как использовать для лечения человека понимание того, где и как он поломается (включая профилактическую медицину). То есть оппозиция идёт как от религиозных людей (у вас плохие теории -- на них опасно опираться), так и от инженеров (у вас плохие теории -- на них опасно опираться). Это соображения даже не про науку, а про нормативную науку, то есть инженерию. Работы Фристона интересны тем, что восприятие оказывается активным -- это не "сенсорный акт", а "сенсоромоторный акт" (и он требует управления (Дойль рассказывает, как сложно должно быть устроено это управление, чтобы успевать системе быть быстрой и точной, а управлению быть устойчивым -- не срываться в выдачу неадекватных управляющих сигналов на эффекторы). Фристон интересен тем, что задаёт критерии минимизации свободной энергии для управления, но он мало что говорит о моделях, разве что эти модели должны быть порождающими (так, ранние его работы говорят о байесовской рациональности при принятии решений, а работы с Fields говорят о квантовой рациональности). Ещё одно соображение -- это необходимость учёта недостаточности не только замеров, чтобы снять неопределённость в определении состояния среды/окружения и системы/сомы, но и недостаточности актуаторов, чтобы привести систему в целевое состояние. В случае механики это underactuated robotics, http://underactuated.mit.edu/. Нужен синтез этой современной инженерной дисциплины с идеями Дойля о многомасштабности с одной стороны и с выходом на общее описание underactuated control, управляющий взаимодействием системы с окружающим миром в условиях недостатка актуаторов на каждую степень свободы, даже немеханической природы. 4. Панпсихизм и физикализм в одном флаконе Панпсихизм -- это когда неживому придают свойства живого, а физикализм -- это когда живое низводят до "физической системы". Chris Fields (равно как Виталий Ванчурин и многие другие) со товарищи формулирует идею панпсихизма в варианте минимального физикализма: безмасштабные (то есть работающие на самых разных системных уровнях, в том числе описывающие структуру этих системных/эволюционных уровней) описания систем, позволяющие выразить и свойства живого (например, разум, сознание, восприятие) и свойства неживого (например, выполнение термодинамических законов, ограничения по скорости-точности управления в силу физических ограничений). Это всё хорошо понимается для уровня личности (человек это и живая система, и физическая система), но для других системных уровней приходится довольно много работать, чтобы обеспечить понимание. Так, работы по поиску сознания у муравейника (https://philpapers.org/archive/FRITAC-4.pdf) сами по себе кажутся странными, а уж если искать "сознание" у организации и тем более сообщества, так и подавно непонятно, как об этом думать. Все текущие даже научные описания мира оказываются привязанными к выпяченному уровню человека. Весь этот "новый квантовый панпсихизм-физикализм", где даже "квантовость" оказывается безмасштабной и вовсе не относится только к микромиру, а понимается информационно, крайне контринтуитивна. Общность квантовости, сознания и даже интеллекта, поддержания устойчивости в каких-то границах Friston blanket ("физически-базированная онтология") на многих уровнях, бесконечности развития -- такое восприятие мира непривычно, слова для его выражения подбираются плохо, примеров успешного описания и в науке, и в инженерии не так много. Дэвид Дойч много говорил о необходимости ухода от "парохиальных" (частных, человекоцентричных) объяснений к глобальным, где человек будет только одной из многочисленных систем в многоуровневой вселенной. Нужно переходить от разговоров к действиям: построению учебных курсов, которые учат такому взгляду на мир. Если не будет курсов, то не будет и ухода от этих "парохиальных объяснений". Это большая задача: сформулировать системную инженерию как "безмасштабную". В INCOSE Vision 3035 эта идея даётся в неявном виде. Мы должны её сформулировать явно и предложить учебный курс именно для такой парадоксальной инженерии, "человечно-бесчеловечной", "эволюционно-инженерной". Мы так и даём курс инженерии предприятий: "смотрите на предприятие прежде всего как на практики, физический объект -- а не как на людей. Но потом обязательно рассматривайте людей, без лидерства никак. Но и без предприятия-как-не-очень-живого тоже никак". Системноинженерный стек Мы отдельно рассматриваем безмасштабный стек методологических дисциплин, и отдельно стек инженерных дисциплин, все из которых будут изводами системной (то есть работающей с самыми разными системными/эволюционными уровнями) инженерии. Похоже, что надо делать не столько курс классической "железной" или даже "киберфизической" системной инженерии, сколько курс безмасштабной системной инженерии. Это означает, что мы берём текущее лучшее наше понимание о том, как устроены практики системной инженерии и обобщаем его для всех уровней системноинженерного стека: -- инженерия требований -- архитектурное проектирование -- неархитектурное проектирование (переиспользование, изготовление, приобретение) -- контроль качества инженерии (assurance case) -- управление конфигурацией и изменениями/ЖЦ -- эксплуатация А вот системно-инженерный (он же эволюционный) стек: -- вселенная -- все инопланетные цивилизации -- человечество -- мы тут одни на маленьком глобусе -- общество -- дальний порядок (не знаем контрагентов в лицо), но может быть достаточно организованным, чтобы выставлять границы на территории -- сообщество -- можете посмотреть определения subculture, counterculture, community, community of practice, learned society, school of thought из википедии: все говорят об одном и том же, подчёркивая разные стороны. И мы тоже можем говорить разным языком, подчёркивая разные стороны. У нас субкультура, контркультура, сообщество практики, сообщество наученных (деятелей, не учёных!), "незримый колледж". Но можно говорить и о племени (очень модно!), и о "муниципальном образовании" типа "деревня, где все друг друга знают", землячестве бывших (или даже нынешних) членов одного общества в каком-то другом обществе. Ориентируемся на число Данбара, ещё относительно ближний порядок. -- Коллектив/организация, которая трудится -- это проекты (организованные коллективы, то есть с понятными ролями и полномочиями каждого). Инженерия предприятия как раз тут. -- личность, тут разные психотерапии, образование и практики личной продуктивности как "инженерия личности". Включать ли сюда разные варианты xGI не на базе homo sapience -- почему бы и нет. -- Существо -- тут разведение живых существ от вирусов через растения, а дальше червей, рыб и до зверей (включая приматов и даже человека вне аспектов его разума). Медицина/ветеринария, фермерство, генная инженерия, искусственная жизнь (системная биология, включая её инженерные изводы). -- Киберфизические системы (физические системы, включающие софт на базе универсального компьютера). Классическая системная инженерия -- Вещество (молекулы, простые физические детали): тут от органического синтеза до инженерии мыльниц и электролампочек, то есть инженерия простых систем без сложного управления с контроллерами-компьютерами в их составе. Изложение инженерии тем самым состоит из трёх уровней: -- относительно абстрактных идей о практиках системной инженерии (нужно делать требования, нужно выполнять архитектурное проектирование и т.д.). Обобщённая схема OMG Essence. -- идей о том, как конкретизировать практики для того или иного уровня системноинженерного стека: классической инженерии киберфизических систем (конвергенция "железной" системной инженерии, инженерии систем управления и программной инженерии), инженерии предприятия с её "требования для предприятия -- это стратегия", строительства сообществ/community building, социальной инженерии (со всеми спорами по поводу её возможности и приемлемости) и т.д.. Обобщённая схема OMG Essence с "воплощением системы" как объект одного из уровней (вещество, существо, организация и т.д. -- без конкретизации по подтипам). -- идей о том, как устроена инженерия совсем уж конкретных видов систем: авиационная инженерия, образование композиторов или даже просто образование какому-то виду мастерства, системный менеджмент для стартапов. Конкретизированная схема OMG Essence (например, в варианте "Мастерства обучать образованных" -- вокруг "мастерства"). При таком подходе решается в том числе и проблема системноинженерного менеджмента ("как организовать предприятие для выполнения проекта системной инженерии), и проблема дообучения людей практикам системной инженерии -- просто это варианты "инженерии предприятия", "инженерии личности". Всё это сводится к "системной инженерии", только в приложении к специфическим объектам разных уровней системно-инженерного стека. Структура курса системной инженерии Важно при обучении системной инженерии разделить определение того, чему учить (результат методологической работы, результат -- описание мастерства, на вузовском языке это -- описание выходных компетенций) и того, как учить в виде набора курсов (результат методической работы: учебные предметы как "курсы", учебные часы, учебные программы, которые вместе научат каким-то видам мастерства, полученным на предыдущем такте). Основная проблема в обучении системной инженерии в текущем варианте -- это отсутствие достаточного числа часов для обучения трансдисциплинам методологического стека. Без этого невозможно разобраться с системным моделированием (типы и онтологии на этих типах), многомасштабным (системным) мышлением, ролью исследований и местом инженерии (прагматический поворот, цели жизни). Если не разделять "курс" и "дисциплину", то проблема эта невидима. Так, в курс "инженерия требований" нужно вроде как объяснять выявление требований, анализ требований, формулирование (моделирование) требований, документирование требований и т.д. -- но без надлежащего владения методологическими дисциплинами это объяснить не удаётся: студенты не могут отклеить понятия от терминов, не могут сопоставить элементы даваемой им мета-мета-модели объектам мета-модели предметной области "из жизни", не могут понять сути самого объекта "требования". Поэтому нужно отдельно учить трансдисциплинам, а отдельно -- практикам инженерии. Курс системной инженерии будет устроен как идущий после курсов дисциплин методологического стека курс по инженерным практикам, подчёркивающий безмасштабный/системный статус этих практик: -- перед ним будут курсы системного саморазвития и собранности (в том числе системный фитнес). Итог: изменение расписания, постановка устойчивого внимания, предварительное знакомство с идеями бесконечного развития -- далее идёт курс онтологики и коммуникации, потом введение в системное мышление -- текущий курс системного мышления бьётся на два разных: системное мышление (по факту это текущий учебник примерно до глав про жизненный цикл) и методология (главы про жизненный цикл, а также разделы про управление жизненным циклом и практики из курса системного менеджмента, которые нужно будет из видеоформата перевести в текст. Эти понятия просто дополняют материал системного мышления, а к менеджменту они относятся ровно постольку, поскольку методология -- это дисциплина о деятельности, а в нынешней ситуации у нас "деятелем" пока является человек. Проблемы "безмасштабной трансгуманистической деятельности" пока не решаем). -- далее идёт курс системной инженерии, в котором первый раздел будет про его структуру, плюс изложение идей из моей книги "Системноинженерное мышление" (2015), которые не вошли в "Системное мышление", например идей о научности и ненаучности инженерии. Далее раскрывается содержание практик системной инженерии по тому плану изложения, который приведён в предыдущем разделе (абстрактные идеи отдельных инженерных практик типа "инженерия требований", конкретизированные кейсы этих практик для разных уровней системно-инженерного стека, конкретные кейсы для конкретных типов систем). Примерно по 50 страниц текста на каждую абстрактную практику и 50 страниц для некоторых кейсов с этими практиками для отдельных системноинженерных уровней. У нас есть какие-то заделы для уровней личности (системное саморазвитие, мастерство обучать образованных), киберфизики (собственно классическая системная инженерия, в том числе программная инженерия и аэрокосмос), организации (системный менеджмент). -- далее идут прикладные курсы инженерий по системным уровням (уже есть системный менеджмент как "инженерия организационных систем", системное саморазвитие как "инженерия себя, любимого", мастерство обучать образованных как "инженерия части личности", потом можно думать об инженерии киберфизических систем как классического курса "введение в системную инженерию" в его традиционном варианте, или инженерии авиакосмических систем, как в курсах Косякова и Николенко, специализации курса для программной инженерии, community building и т.д.). Эти прикладные курсы могут быть не очень большого объёма, ибо основное понимание у студентов будет сформировано в рамках универсального для всех системных уровней кругозорного курса -- и нужно будет только уточнить терминологию, показать какие-то SoTA практики для выбранного вида систем. -- далее идут прикладные курсы отдельных видов инженерных практик для одного из уровней (инженерия требований для киберфизических систем в авиационном или атомном варианте, операционный менеджмент по Reinertsen, и т.д.). Гипотеза в том, что такое изложение позволит отказаться от множества низкоуровневых курсов. Так, при создании кругозорного курса системного менеджмента с опорой на работу с типами удалось в существенной мере устранить нужду в отдельном прикладном курсе архитектуры предприятия: после курса с преподавателем становится очевидным, что и как нужно делать для создания даже не просто архитектуры предприятия, а actionable архитектуры. Но насколько такой подход переноса времени обучения с прикладных дисциплин на дисциплины методологического стека и дисциплины системноинженерного стека будет работать для самых разных типов систем -- непонятно. Так, вряд ли общий курс "инженерии человеческого тела" (он же -- курс медицины) будет как-то рабочим после знакомства с общими понятиями. Вполне возможно, что проблема низкоуровневых курсов в начальной квалификации студента: если у него уже есть хоть какой-то производственный опыт и начитанность, то структурированное изложение структуры инженерной деятельности позволит ему дальше быстро продвигаться в предмете самостоятельно. Но если производственного опыта и начитанности нет (школьники, студенты и даже магистры), то прикладных курсов может потребоваться много. Но это всё догадки, которые нужно будет проверять. Заметки по содержанию курса системной инженерии с прошлой встречи системных инженеров в Бекасово год назад: https://ailev.livejournal.com/1563471.html (можно сравнить, насколько продвинулось понимание за год). Курс о том, как делать учебные курсы (заодно это пример прикладного инженерного курса для системноинженерного уровня личности): Изложение основных инженерных идей Изложение инженерных идей должно вестись на максимально абстрактном уровне, который позволит потом проводить рассуждение для самых разных вариантов конкретных инженерных практик, которые встретятся студентам на предприятиях. Примером тут может быть практика инженерных обоснований (assurance). Проверка и приёмка тут просто частные виды assurance, связанные с обоснованием разных видов систем (целевой и надсистемы). Основная практика для assurance -- это argument map (https://en.wikipedia.org/wiki/Argument_map), и ссылаемся на результаты обсуждений при создании ISO 15026 (https://ailev.livejournal.com/578461.html в 2008 году, через пару лет в 2010 году я вернулся к этому вопросу -- https://ailev.livejournal.com/811715.html, но с тех пор много уже воды утекло, так что SoTA нужно отдельно смотреть). Для аргументации в обоснованиях есть множество самых разных методов: -- моделирование (головой эксперта, имитационной моделью и множество гибридных вариантов) -- использование гипотезы эргодичности, то есть ссылка на аналогию -- испытания (test) -- ... Как пример из этого списка, испытания это: -- предварительно полученные ожидания (из требований, потребностей, конфигурации и т.д.) и толерантности -- измерения (как в физике: подготовка ситуации взаимодействия предмета измерения и измерителя, взаимодействие как собственно измерение, считывание результата измерения и передача/запись результата измерения. При необходимости -- повторения, набор статистики. Внешний осмотр это тоже измерение, а эксперт с его глазами -- это прибор!) -- принятие решения о результате испытания и уверенности в этом результате. Это очень небольшой материал, если тут можно опереться на знание онтологики (логики, теории понятий, онтологии, семантики) для понимания argument map, знание физики (теория измерений), знание (байесовской, а не фишеровской, или даже для некоторых случаев квантовой/неколмогоровской) статистики. Если же студент всего этого не знает, то основы инженерных обоснований будут ему недоступны -- будь то обоснования в разработке софта (результаты приёмо-сдаточных испытаний) или обоснования для принятия менеджерских решений (измерения для менеджерских целей, на системном уровне организации). Ожидается, что после прохождения некоторого числа примеров для разных ситуаций обоснований для систем разных уровней системноинженерного стека у студента будет достаточное понимание, чтобы разобраться в конкретном варианте устройства обоснований в каком-то конкретном проекте, в который он попадёт после прохождения курса системной инженерии. В этом плане курс системной инженерии "университетский" (на развитие интеллекта), а не "институтский/техникума" (владение какой-то конкретной практикой типа "нагрузочные испытания корпоративных информационных систем" или "обоснование спортивных достижений в лёгкой атлетике" -- с этими практиками при потребности студент разберётся сам, уже после выпуска. Ну, или можно будет подготовить короткие прикладные курсы, учитывающие уровень интеллекта студента после прохождения курсов интеллект-стеков, то есть курсов по дисциплинам методологического стека и дисциплинам системно-инженерного стека). Моделеры: что с этим делать Мы рассмотрели несколько ключевых решений, которые позволили как-то решить проблему моделирования для инженерии организационной системы (материал по инженерии предприятия в составе курса системного менеджмента): -- не нужно было опираться на формальные методы для foundational ontology и upper ontology (это тупик). -- не нужно опираться на диаграммные нотации и формальные языки. Но онтологическую работу нужно базировать на аннотировании типами. -- нужно очень чётко рассказывать: кто что моделирует (книжка Chris Partridge и курс онтологики для разбирательства с мета-мета-мета-моделированием/foundational ontology, нужна для строителей моделеров, выпускники наших курсов укладывают в голову мета-мета-модель из учебников системного мышления и системной инженерии, в том числе в варианте инженерии организационных систем/системного менеджмента, специалисты-эксперты предприятия знают мета-модель и наши выпускники помогают её доработать и выразить в подручном моделере, простые работники предприятия работают с операционной моделью). Главное тут -- это на предприятии держать мета-мета-мета-модель и мета-мета-модель в голове, а аннотирование типами не давать вслух! Не нужно никого смущать, это только замедляет работу. Если нужно, чтобы работники предприятия сами без наших выпускников моделировали мета-модель, то их обязательно нужно отправить на полноценные курсы ОиК, системного мышления, системной инженерии и менеджмента, или ничего не получится при любом моделере. -- Если в голове нет машинки типов и чёткого понимания работы с уровнями мета-моделирования (включая кто каким уровнем моделирования занимается, что и где пишем в табличках, а что в уме), то моделирование невозможно. В табличном моделировании нужно понимать, что ключевое -- это аннотированный типом из мета-мета-модели/учебника заголовок колонки таблицы как мета-модель/понятие целевого domain, а элемент таблицы -- это типизированный заголовком domain. Ключом оказалось то, что тип мета-мета-модели не пишется вообще, а элемент таблицы имеет название на естественном языке (а не "идентификатор" для типизированного элемента). Productivity tools отлично поддерживают такой стиль моделирования. Конечно, можно документировать и типизацию более высоких уровней (комментариями), но в маленьких проектах можно этого не делать, а в больших командных проектах квалификации модельеров обычно уже для такого хватает. -- Моделер к моделированию относится как ручка писателя к качеству его романов или кисти художника к качеству его картин. Важно, что в голове модельера. А дальше он это содержание выкладывает в наилучшем доступном медиа. Простейший моделер -- это влажный песок и веточка, далее идёт салфетка и карандаш, флипчарт и фломастер, потом компьютер с Word или Excel. Все "формальные универсальные моделеры" с чётко прописанной foundational и upper ontology пропускаем, "рисовалки" типа Visio, языки моделирования типа Архимейт или SysML -- игнорируем. За ними идут productivity tools как смесь электронных таблиц, реляционных баз данных, редактора текстов (coda.io, notion.so, хуже airtable), а характер actionable modeling им придают разные средства интеграции данных. В инженерной работе эволюция прошла по линии PDM-PLM-eXperience platform-digital twin, но это для обработки машиночитаемых данных и порождающего проектирования (CAD/CAM). Но это линия моделирования данных для профи, не для общего образования. -- важными оказались примеры моделирования в таком стиле "мышления письмом/моделированием", на эту тему сняли видео по нескольким докладам. И проблемы с моделерами и моделированием как-то сильно уменьшились. Например, для начала организационного моделирования (архитектуры предприятия) студентам стало хватать кругозорного курса системного менеджмента -- и не только лучшим студентам, но почти всем выпускникам последних потоков "Системного менеджмента и стратегирования". Кадр из трансляции с заседания (обратитесь к организаторам, чтобы получить доступ к видео и презентациям -- оплатившие оргвзнос участники встречи получили доступ к видео в онлайн, официальная страница мероприятия https://incose-rus.tilda.ws/bekasovo-2022):