Моделирование в "Системном мышлении 2022" (отрывок из черновика учебника)

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

Описания и методы описания, модели и мета-модели

Само (ролевое, view) описание состоит из множества отдельных моделей (models), которые можно трактовать как формальные или неформальные части описания системы, отражающие ещё более частные важные характеристики, чем собранное из этих моделей суммарное ролевое описание. Например, полное системное описание включает в себя финансовое описание создающей системы-предприятия, но в финансовом описании можно в свою очередь выделить разные модели, нужные для ответа на разные вопросы интересующейся финансами проектной роли: баланс, отчёт о прибылях и убытках (profit and loss, P&L) и денежный поток (cash flow). Если у вас есть только баланс, то вы не ответите на вопрос о безубыточности работы предприятия, а если у вас отчёт о прибылях и убытках и даже баланс, то вы не сможете обсудить кассовый разрыв без наличия документов по денежному потоку. Одно ролевое описание для одного предмета интереса, три разные модели для трёх подпредметов интереса (конечно, предметы интереса/важные характеристики тоже разбиваются на подпредметы/подхарактеристики!).

Каждая из моделей должна быть выполнена с использованием одной из мета-моделей/meta-models/model kinds (это подробно обсуждается в трансдисциплине онтологии), причем каждая из мета-моделей устанавливает определенные язык, правила и приёмы моделирования (соглашения), используемые при разработке модели. Так же как отдельные модели (models), отвечающие на какой-то подинтерес, объединяются в более полное тематическое/ролевое описание (view), так и мета-модели (metamodels/model kinds), определяющие язык, правила и приёмы моделирования, используемые при ролевых/тематических/частных описаниях, объединяются в ролевые/тематические/частные методы описания (viewpoints), отражающие/frame предмет интереса. Методы описания с их мета-моделями описываются часто в документе «соглашение о моделировании», для каких-то данных мета-модель называется часто «модель данных» (данные = модель системы, модель данных = мета-модель системы).

Например, для финансового описания создающей системы-предприятия нужно прежде всего выбрать один из методов описания — РСБУ (Российские стандарты бухгалтерского учёта) или МСФО (международные стандарты финансовой отчётности). При составлении баланса (одна модель финансового описания) и отчёта о прибыли и убытках (другая модель финансового описания) нужно использовать мета-модели (соглашения по тому, как делать модели) для этих видов моделей из какого-то одного метода описаний — либо РСБУ, либо МСФО.

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

Нельзя делать карты и/или давать рассматривать другим проектным ролям карты, если изготовителю карты и/или другим проектным ролям неизвестна легенда карты и методы картографирования. Карты, сделанные по разным методам описания, потом нельзя сопоставлять друг с другом. Нельзя делать карту, используя слои, подготовленные согласно разным методам картографирования — нельзя брать подготовленную геодезистами карту водных ресурсов города и подготовленную службами метрополитена карту-схему станций метро и просто накладывать их друг на друга. Нельзя брать баланс по РСБУ, а отчёт о прибылях и убытках делать в МСФО. Все модели (models) из описания (view) должны быть подготовлены с использованием мета-моделей из одного метода описания (viewpoint). И да, метод описаний нужно согласовывать с проектной ролью, ибо в зависимости от предмета интереса и предпочтений роли в характеристиках этого предмета интереса разные проектные роли будут требовать использовать разные методы описаний! Например, финансисты из бухгалтерии будут требовать финансовые описания по МФСО (и у них важным будет описание себестоимости), а операционные менеджеры будут отказываться от таких описаний и настаивать на ведении собственного финансового учёта, потому что они будут считать «себестоимость» вредной и сбивающей с толку характеристикой, настаивая на совершенно других методах финансового расчёта, более пригодных не для целей налогообложения, а для целей операционного менеджмента. Они могли бы настаивать на использовании методов описания, принятых в учёте протока/throughput accounting из теории ограничений Голдратта [https://en.wikipedia.org/wiki/Throughput_accounting]

Метод описания чаще всего бывает библиотечным (library), это означает, что вместо раскрытия его содержания приводят просто ссылку на литературу по этому методу. Это всё равно как вместо полного текста и картинок легенды карты можно было бы просто дать ссылку на книгу или картографический стандарт, где приведён список условных значков и подробный текст о том, использовать эти значки для изображения деталей рельефа, флоры, фауны, полезных ископаемых, плотности населения и т.д. Но если нет ещё текста с готовым методом описания, то вам придётся описывать какой-то предмет интереса таким способом, который до сих пор не использовался. Тогда вместо этой ссылки на библиотечный метод описания вы обязаны к описанию приложить документированный вами самими метод описания: без указания метода описания сами описания делать нельзя. Метод описания — это альфа, так что для свидетельствования состояния этой альфы потребуется артефакт/рабочий продукт/документ. И описание требует документирования, и метод описания требует документирования.

Главное — это запомнить: любое описание — это описание системы, любое описание системы сделано с использованием метода описания (даже если описывающий этого не осознаёт), доступно людям описание становится только после его документирования, метод описания — это описание описания (поэтому уместны вопросы и про метод описания метода описания, и про документирование метода описания метода описания!).

Метод описания (viewpoint) оформляет (frame) целевую характеристику (concern) проектной роли. Одно из следствий рассматриваемой схемы: если у проектной роли/stakeholder нет соответствующей важной характеристики/concern, то описание/view для удовлетворения интереса к этой характеристике не делается (и, соответственно, это описание не документируется, и метод описания для него тоже не нужен): описания, в которых не затрагиваются важные для каких-то ролей характеристики, не нужны, они избыточны. Даже если какой-то используемый стандарт требует какого-то описания, но никто его читать не будет (менеджеры просто проверят «для соответствия стандарту») — такое описание не нужно делать, это бессмысленная трата ресурсов проекта. И наоборот: если у проектной роли есть целевая характеристика и начинается её обсуждение, то описание для такой характеристики делается и обязательно документируется. Речь никогда не идёт об устных ответах на вопросы. На бумаге, или в базе данных, или в файлах, но описание должно быть документировано.

Описания (views) согласно ISO 42010 могут быть двух видов: прожекторные (projective) и синтетические (synthetic).

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

Синтетические описания — это когда наоборот: исходные описания даны в виде отдельных документов моделей, причём каждая модель документирована не просто как часть одной общей для всех моделей базы данных (как в прожекторных описаниях), а отдельный бумажный или электронный документ. Между этими автономными моделями из отдельных документов устанавливаются правила соответствия (correspondence rules, «этот объект этой модели — это вон тот элемент вон той модели»), и общая модель тем самым получается синтетически объединением отдельных автономных моделей. Рассуждения про системные/полные и ролевые/частные описания системы при этом не меняются от того, как собираются эти описания из документации моделей — сразу в общем документе (прожекторный подход к описаниям) или после создания отдельных документов моделей (синтетический подход).

Синтетические и прожекторные описания оказываются эквивалентными в плане мышления о работе с описаниями, предложенный в ISO 42010 набор понятий работает для обоих вариантов. Просто в синтетических описаниях приходится много сил тратить на согласование независимо подготовленных описаний, «интеграцию данных жизненного цикла». А в прожекторных описаниях приходится много сил тратить ещё до начала моделирования конкретной системы на то, чтобы согласовать методы описания для документирования всех ролевых описаний в одной базе данных. В общем случае, конечно, побеждают синтетические описания, поскольку они не подразумевают предварительной огромной работы по интеграции инструментов моделирования. Но желание иметь прожекторные описания, с которыми потом удобно работать, достаточно сильно. Поэтому современные проекты имеют несколько частных прожекторных описаний, вместе составляющих синтетическое (ибо ни одно из частных прожекторных описаний не отражает все проектные предметы интереса).

Мультимодель и трансдисциплинарность

Моделирование в системном мышлении — это главное средство борьбы со сложностью в проектах. Большая сложность — это когда чересчур много деталей в описаниях, поэтому мозгу (и компьютерам, ему помогающим) нужно делать много вычислений. Число вычислений можно резко сократить, если выкинуть вычисления над неважным. Сходу обычно непонятно, что в этих описаниях важно, а что неважно. Моделирование — это и есть описание только самого важного, и опускание при описании неважного. Документирование моделей позволяет не просто описать важное, но и удержать важное во внимании столько времени, сколько нужно для рассуждений. А неважное во внимании не удерживается, остаётся только в разговорах в ходе моделирования.

Моделирование — это способ получения описаний важных характеристик, при котором один объект (модель, model) используется для вынесения суждений о другом (моделируемом) объекте. В моделировании используется знание минимально на трёх онтологических уровнях (и это изучается онтологией, одной из дисциплин интеллект-стека):

• Ситуация (как-то связанные между собой предметы в какой-то предметной области/domain), которая моделируется. В конечном итоге это какие-то предметы физического мира, о них известно что-то кому-то важное, и что-то совсем неважное. Но может быть и цепочка моделирования, и тогда речь идёт о модели какой-то модели. Информации много, объектов внимания много, и задача моделирования как раз справиться с этой проблемой: размышлять про предметную область саму по себе трудно, вычислитель агента (мозги и компьютеры, а хоть и трудового коллектива), который действует в предметной области, перегружается обработкой маловажной информации. Такие тонкости, как различия реальности и действительности тут в расчёт не берём. Реальность – это всё, что есть, а действительность – это всё, что мы знаем о том, что есть в реальности и как-то можем описать, поэтому воспринимаем мы не всю реальность, а только действительность. Разбирательство с предметной областью и есть предмет онтологии.
• Типы объектов, которые нужно найти. Они задаются методом описания, в основе которого лежит мета-модель. Эта мета-модель как типы объектов, которые нам важны в предметной области, чтобы выделить из действительности только важные объекты, задаётся какой-то дисциплиной (прикладной или мыслительной из интеллект-стека).
• Сама модель. В случае физической модели это какие-то предметы, сохраняющие в себе основные характеристики, задаваемые мета-моделью, а в случае информационной модели это какие-то элементы описания, типы которых задаются мета-моделью.

Как определить, что важно? Важно в описаниях только то, что помогает отвечать на вопросы по какому-то предмету интереса: для разных проектных ролей важными характеристиками в системе являются разные характеристики, и двигать их значения разные проектные роли хотят в разные стороны, и им для этого нужно знать значения многих других характеристик (в системах же всё связано, части системы взаимодействует, поэтому значения всех характеристик взаимоувязаны, все роли это понимают). То, что важно для какой-то роли, задаётся метамоделью. Метамодель есть всегда, часть метамоделей в длинной цепочке мета-моделирования определяется аппаратурой мозга человека (или аппаратурой компьютера, воспринимающего мир). Важность определяется не в один шаг моделирования, а во множество шагов: даже то, что в мире есть объекты и отношения оказывается результатом моделирования (и это называется мета-мета-мета-моделью, или foundational ontology, а мета-мета-модель называется upper ontology, а мета-модель называется middle ontology или прикладной онтологией и это всё ещё типы, а вот модель экземпляров/операционная модель – это просто «модель». Также «моделью» называют и любую из мета-моделей, легко запутаться. И уровней «мета», то есть уровней задания типов для типов, то есть уровней отношений классификации может быть много, хотя обычно хватает трёх-четырёх).

Мы ещё несколько раз повторим это рассуждение, ибо оно важно: вы обращаете своё внимание не на произвольные объекты в мире и других моделях, которые вам «бросаются в глаза» (они ведь могут быть как важными, так и неважными. И неважные объекты могут сильно отвлекать внимание от важных!). Вы обращаете внимание, и даже специально их ищете (или предлагаете, если речь идёт о проектировании) на важные объекты, и наличие этих важных объектов задаётся мета-моделью, которая в этот момент у вас есть. А если мета-модели у вас нет, то вы ищете её объекты точно так же: обращая внимание на те объекты, которые задаются мета-мета-моделью, ибо это рассуждение работает на любом онтологическом уровне. Если вы ищете что-то важное в мета-мета-модели, то у вас в голове в этот момент есть мета-мета-мета-модель, которая по факту мета-модель для мета-мета-модели. Важность задаётся многоуровнево, мы выхватываем своим вниманием неслучайные объекты. Образование нужно для того, чтобы узнать, какие именно важные объекты мы ищем в мире или (в случае придумывания чего-то нового) в своём воображении. Образование нужно для экономии времени на вычислениях по неважным поводам! Образование нужно в том числе и для того, чтобы понять, зачем оно нужно (как ни странно это звучит). Например, нужно образование, чтобы понять: без знания онтологии никакого системного мышления не будет, ибо вы не сможете осознанно строить системные описания.

Вот буквально следующий абзац содержит описание реальной ситуации, размеченное типами из нашего курса/учебника системного мышления. Как это делается – это изучается не в нашем учебнике, а в курсе онтологики (онтологика это общее название для целого ряда дисциплин, включающее онтологию, логику, семантику, теорию понятий).

Финансист::роль хочет предотвратить::предпочтение/интерес кассовый разрыв::предмет интереса — и модель денежного потока::описание будет отвечать на его вопросы по этому предмету интереса. Всё остальное даже из финансов (баланс, прибыль и убытки) при этом неважно, другие модели из других описаний будут использоваться для ответов на другие вопросы этой же, или другой проектной роли.

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

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

Предмет интереса/concern отражается/framed методом его описания/viewpoint, а в этом методе описания как раз указывается, что самое важное в моделируемом объекте, что нужно учесть в различных моделях, получаемых при помощи этого метода описания. Это «самое важное» для какой-то модели и называют мета-модель, и выражена она главным образом в типах самых важных объектов.

Для карты, являющейся моделью территории, мета-модель — это легенда карты, типы изображённых на карте объектов. Карта содержит ничтожную часть информации о территории, но это только важная информация. А легенда карты указывает на то, что на территориях важно, и поэтому нужно отображать в моделях. Дорогу на дорожной карте вы увидите, это важно, а вот цвет асфальта на этой дороге — нет, это не важно! А вот на карте животного мира вы и дороги не увидите, ибо не это важно. Тип важных объектов «дорога» для дорожной карты и «место обитания фауны» для карты животного мира задаётся мета-моделью, легендой карты. А сами объекты на дорожной карте – типа «дорога», а на карте животного мира типа «места обитания фауны». Тип один (задаётся легендой карты, методом описания, мета-моделью – это всё способ говорить об одном и том же: «что важное нас интересует»), а объектов этого типа в описании может быть множество, и этот тип может быть использован для построения множества описаний. Можно представить себе комбинированную карту, где изображены и дороги, и места обитания фауны. На таких картах удобно обсуждать, например, миграцию фауны и препятствия для этой миграции. Можно совмещать это на одной карте (говорят при этом о прожекторном описании, как у театрального прожектора внутри все цвета, так и тут в одном описании собрано несколько разных, и одно описание можно от других отделить фильтрацией), можно положить рядом две отдельных тематических карты и смотреть на них одновременно (это синтетическое описание: берём несколько разных описаний и синтезируем из них одно).

Бывают и мета-мета-модели, ибо одни описания могут моделировать другие. Так, холодильник моделируется для инженера-ремонтника его принципиальной схемой, на которой обозначены функциональные части холодильника и какие-то соединения между ними (на принципиальных схемах обычно изображены какие-то обрабатывающие потоки чего-то функциональные части и между ними линии, указывающие сами эти потоки. Электрические схемы показывают электрический ток, в принципиальной схеме холодильника мы увидим ток тепломассопереноса между функциональными частями холодильника). Принципиальная схема тут модель холодильника, а вот её обозначения (легенда) будут мета-моделью холодильника. Мета-модель холодильника -- это те типы объектов, которые мы должны увидеть в холодильнике и отразить в его модели. Но когда мы говорим о том, как в компьютерном редакторе принципиальных схем моделируются обозначения для принципиальных схем холодильников, речь идёт уже о мета-мета-модели холодильника. Моделирование многоуровнево, и для компьютерных структурных [почему важно уточнять, что речь идёт именно о структурных моделях? Потому что сейчас есть и коннекционистские (нейронные) компьютерные модели, для которых эти рассуждения неприменимы] моделей обычно бывает три-четыре уровня мета-моделирования.

Множество связанных друг с другом моделей, сделанных с использованием разных методов описания (неважно, в рамках прожекторного или синтетического подхода к описанию системы) обычно называют мультимоделью. Это всё равно как сборник множества карт для одной и той же территории: флоры, фауны, плотности населения, рельефа, и т.д.. Неважно даже, всё это отображено на одной карте-документе (прожекторная модель), или разных (то есть физически это сборник разных документов, синтетическая модель). Рассуждения абсолютно одинаковы для обоих этих случаев.

Обычно моделирование системы мультидисциплинарно, а каждая дисциплина/теория задаёт своё описание системы, то есть предписывает моделирование для какого-то набора своих собственных моделей. Это прикладное моделирование, в отличие от системного. Так что системное моделирование — это мультидисциплинарное мультимоделирование (а само системное моделирование трансдисциплинарно, оно не является одной из этих дисциплин, а собирает модели всех этих дисциплин вместе).

Незнакомые с системным подходом люди с трудом воспринимают идею множественности моделей, описывающих сложную систему. Обычно они требуют указать «главную модель», которая является «правильной» по отношению к другим «вторичным» или «вспомогательным» моделям — но в системном мышлении нет «главной модели», для каждой проектной роли просто даётся её набор моделей для ответа на вопросы ее ролевых предметов интереса. Нет «главной модели», нужны все модели! А ещё моделирование должно быть «многомасштабным», выполнено на нескольких системных уровнях: модели нужны не только для целевой системы, но ещё и для надсистемы, и для подсистем (и в силу необходимости показывать эмерджентные характеристики, это будут разные модели на каждом системном уровне, нужные для согласования разных ролей, исполняющих разные практики. Модели кирпича, модели стены и модели здания – это совсем разные модели). Для систем ведения жизненного цикла/создания целевой системы тоже нужны модели. Множественность описаний означает множественность моделирования. Внимание удерживать на главном, определяемом как типы мета-модели, и не отображать в модели неглавное нужно сразу для многих дисциплин, требующихся для ведения проекта создания системы. Для этого и служит моделирование: отражение главного, типы которого берутся из культуры (если кто-то с этим уже работал до вас) или получаются из исследований, если вы первый, кто разбирается в новой предметной области и пытается понять, на каких типах объектов в ней удаётся получить объяснения, как связаны в этой предметной области причины и следствия.

Как узнать, что должно быть главным? Мета-моделировать! Но главное в мета-моделировании тоже не произвольно, а задаётся типами мета-мета-модели. Один из критериев хорошей модели – это удобство обсуждения причинно-следственных связей в предметной области, а для этого удобство проведения контрфактических рассуждений. Типы из мета-модели поэтому должны быть не любыми, а пригодными для таких рассуждений, этим вопросом пригодности занимается мыслительная практика объяснений (входит в состав интеллект-стека). Нахождением таких типов занимается практика исследований, это тоже одна из мыслительных практик, входящих в интеллект-стек. Получается, что системное мышление, которое занимается составлением системных описаний/системным моделированием, находится довольно высоко в интеллект-стеке, и для хорошего владения системным мышлением нужно быть уже достаточно образованным человеком. Именно поэтому системное мышление у людей встречается не так часто: нужно учиться не только ему, но и остальным дисциплинам интеллект-стека (подробней об этом в курсе/книге «Образование для образованных 2021», а материалы по моделированию раскрываются в курсе/книги «Онтологика и коммуникации 2022» [https://system-school.ru/united, первая глава https://blog.system-school.ru/2021/10/13/chto-takoe-ontologika/, видеоверсия https://youtu.be/ocNar2pC03I, вторая глава - https://blog.system-school.ru/2021/11/29/opisaniya-sootvetstvuyushhie-trebovaniyam/, видеоверсия https://www.youtube.com/watch?v=50VYDmV9DQY).

Проектных ролей много, и что модель для одной роли — информационный шум и перегрузка «думалки» играющего эту роль агента (вычислителя с конечными ресурсами: будь то мозг, мозг с компьютером или даже просто компьютер) для другой роли, и наоборот. Возникает соблазн моделировать меньше, избавиться от лишней работы, но этого нельзя делать. Нужно моделировать (и документировать модели) для удовлетворения всех интересов всех причастных проектных ролей: ошибки в описании системы дорогостоящи, а эти ошибки обычно выявляются как расхождения/коллизии/collision между различными моделями системы. Вы узнаете о проблемах, ибо проектные роли предъявят претензии к моделям (а иногда и претензии к мета-моделям). Ошибки/коллизии в системной модели желательно выявлять и исправлять при описании и документировании системы перед изготовлением, а не после изготовления, и уж тем более не при эксплуатации системы. Семь раз опиши, один раз изготовь!

Ещё одна ошибка в том, что модели специфичны для проектных ролей каждого системного уровня, и если выбрать неверный системный уровень, то можно скатиться к редукционизму или холизму. Редукционизм -- это пробовать объяснить сложную систему взаимодействием не её подсистем, а каких то частей системы на существенно более низких уровнях, даже если в этих неадекватно выбранных уровнях выделить что-то на этих уровнях важное и опустить при описании всё на этих уровнях неважное. Да, человек состоит из атомов, это правда — но это неправильный системный уровень для объяснения того, чем человек отличается от роботов и кошек. Если захочется отремонтировать экскаватор, то моделирование экскаватора из атомов, или даже молекул для ведения этих ремонтных работ будет крайне неверным решением. То же самое относится к холизму: объяснению того, что в системах всё зависит исключительно от их надсистем. Нет, модели должны быть удобны для деятельности на каждом уровне, они должны позволять проводить объяснения (обсуждать причины и следствия происходящего в предметной области интереса), а не абстрактно «научно правильными». Повторимся: системное мышление — это не чистая математика, не чистая логика, его модели и рассуждения с их использованием определяются интересами в деятельности, опора тут на методологию как дисциплину интеллект-стека. Если какие-то модели и рассуждения по ним формально правильны, но не помогают что-то сделать в физическом мире, то они бесполезны, их не нужно делать.

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

Метод описания и мегамодель

Кроме набора карт нам нужно ещё иметь и набор легенд для этих карт. Для разных наборов данных, чтобы их прочесть, нужно иметь их модели данных. Например, для базы данных сведений о концертах в Париже осенью 2020 года нам нужна модель данных для таких сведений, а не только сами сведения. Нужна мета-модель сведений о концертах, а не только сами сведения о концертах. Будем называть мультимодель в сумме с определяющими её мета-моделями — мегамоделью.

Если наш ролевой предмет интереса географический, то он оформляется географическими описаниями — картами. Для географического описания/моделирования холма в соседней деревне нам потребуются самые разные модели (карты), составляющие целый атлас (мультимодель), но кроме этого нам потребуется знание, какие виды моделей должны быть в атласе (например, физическая карта, политическая/административная карта, карта полезных ископаемых, карта плотности населения, карта флоры, карта фауны, карта почв и т.д.), задаваемые мета-моделями (легендами соответствующих видов карт, которые разрабатываются исследователями-географами и обычно доступны из культуры, их можно «нагуглить»).

Если нам потребуется отмоделировать холм около другой деревни, то у нас будет другая мультимодель при сохранении всех тех же мета-моделей. Рассматривать же и обсуждать в целом можно будет только мегамодель: без обсуждения видов карт, соглашения об условных обозначениях на этих картах и прочего, относящегося к мета-моделированию, обсуждать карты нельзя. Если вы не договорились, на каком языке пишете проектную документацию (китайском, суахили или украинском), то вам может понадобиться её переписывать — но перед перепиской всё равно придётся договориться о языке. Если вы не договорились, в каком формате вы предоставляете отчёт о прибылях и убытках, то вам может понадобиться его переписывать, но перед перепиской всё равно нужно будет договориться о мета-модели из финансового метода описания — какой же формат отчёта о прибылях и убытков нужно предоставить. Нельзя моделировать без знания мета-модели и договорённости о том, что она сможет отразить предмет интереса проектной роли. Не знаете типов (не имеете образования, например), не нашли нужный учебник и выдумали мета-модель «из головы», «на коленке», не документировали мета-модель – и дальше будут бесконечные провалы из-за невозможности объяснений по поводу значений важных характеристик, отражённых как объекты плохих или вообще неизвестных/непонятных типов. «-- Петька, приборы! – Восемь! – А чего восемь?! – А чего приборы?!».

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

Учат методам моделирования — они будут одни и те же для разных систем, они будут помогать учитывать интересы одних и тех же проектных ролей, хотя играть эти проектные роли будут разные люди в разных проектах — знание мета-моделей помогает переносить из проекта в проект опыт о том, что является в системе важным и что отвечает на интересы проектных ролей. Вы один раз учитесь 3D-моделированию инженерных систем, затем используете это мастерство моделирования во множестве самых разных проектов.

Если вы даёте кому-то описание системы, то вы обязаны также сообщить, как вы получили это описание, указать использованный метод, задать типы важных объектов, отражённых в модели. Вы должны понимать, что это описание — результат моделирования, то есть оно должно содержать только важные факты для той проектной роли, которой вы даёте это описание, и не должно содержать ничего другого, что будет для этой проектной роли информационным шумом. Если вы не можете сказать, каким методом вы описали систему, если вы не знаете, отражает ли этот метод предмет интереса проектной роли, вы делаете ошибку, эта ошибка вам дорого обойдётся.</strong></span>