5. Особенности системного моделирования

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

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

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

Например, полное системное описание включает в себя «финансовое описание»::view предприятия::создатель (и между описанием и описываемым предметом отношение представления/representation).

В финансовом описании можно в свою очередь выделить разные составляющие его модели, нужные для ответа на разные вопросы интересующейся финансами проектной роли:

• баланс (balance),

• отчёт о прибылях и убытках (profit and loss, P&L),

• денежный поток (cash flow).

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

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

Каждая из моделей должна быть выполнена с использованием одной из мета-моделей/meta-models/model kinds, причём каждая из мета-моделей устанавливает определенные языки, правила и прочие соглашения о моделировании (например, о том, каким объектам мы присваиваем какие типы мета-модели или мета-мета-модели и как будем выбирать имена объектов и имена типов из длинных рядов синонимов).

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

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

И помним, что есть ещё и уровень мета-мета-модели (то, что РСБУ::viewpoint — это как раз использование наставлений из нашего руководства для присвоения типа, мы сказали, что РСБУ — это метод описания, использовали тип мета-мета-модели фундаментальной дисциплины, общий тип для всех дисциплин. А РСБУ представляет собой мета-модель, метод описания предметной/прикладной дисциплины).

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

Напомним то, что вы уже знаете из предыдущих руководств программы рабочего развития:

• Карта — это не территория, а модель территории. Ходят не по карте, а по местности. Но выбираете вы маршрут обычно по карте. Другое дело, что набор условных обозначений (viewpoint) не даст вам карту (view), её придётся делать самостоятельно, заниматься моделированием какой-то местности (domain). А потом генерировать несколько маршрутов походов по этой карте, критиковать их («вау, этот маршрут ведёт в болото! Не пойдём туда!»), выбирать согласно какой-то из теорий решений наилучший способ действий, наилучший маршрут (лучший метод работы), а затем ещё и заставить себя (да и уговорить других) пойти по этому маршруту, то есть кроме выбора метода ещё и сделать саму работу по методу. Это всё метафора, конечно, но вам нужно разобраться в этой метафоре. В любом случае, ваша мысль должна дотягиваться до реальной работы, для которой вы должны определить метод (стратегировать: понять метод в ситуации, когда метод неизвестен), в каждом методе есть его предметы метода из его предметной области, они даны в какой-то модели, а эта модель имеет свою мета-модель.

• Есть несколько уровней абстрактности, они же мета-моделирования, от самой общей модели теории понятий (theory theory — «всё есть объекты и отношения», это можно считать foundational ontology, не путать с «foundation model»/LLM) через мета-мета-модель как набор типов для объектов и отношений из фундаментальных методов мышления (в том числе набор типов системного подхода — «система», «окружение», «системный уровень», «создатель», и т.д.), затем мета-модель какой-то предметной области (в том числе менеджмент с его типами: орг-архитектура, органиграмма, выпуск/проход/throughput и т.д.), затем модель с её уже значениями (например, выпуск/проход 3 сепульки в день на $30). Конечно, этих уровней может быть и больше (например, можно выделить метаУ-модель, метаС-модель). По факту, есть территория (мир), карта (модель), мета-модель (карта карты, то есть система обозначений для domain), есть мета-мета-модель (карта карты карты, то есть система обозначений для системы обозначений карты, универсальная для всех систем обозначений, то есть для всех domain), и есть даже мета-мета-мета модель (система обозначений для системы обозначений для системы обозначений карты). В системном мышлении вы должны это всё удерживать и не путать. Если вы вдруг заговорите терминами мета-мета-модели (словами из нашего руководства), то вас никто не поймёт. Обсуждайте не системы обозначений, а карту. Но сами вы в голове должны удерживать то, откуда пришли обозначения на карте, и откуда пришли обозначения того, что дано в таблице обозначений.

• На любом из уровней абстракции вы можете или моделировать строго (карта в масштабе, с точными обозначениями в какой-то проекции) или не очень строго (детская карта, карта метро — где важно донести плохо понимающим в картографии людям какую-то одну идею, а не иметь точную модель). В моделировании это выбор уровня формальности — от формальности с учётом унивалентных оснований математики (они будут построже, чем основания математики, построенной на теории множеств, и подразумевают конструктивизм — даже не theory theory с объектами и отношениями, а пока плохо определённую и крайне нераспространённую фронтирную теорию понятий с объектами и операциями их конструирования, подробней это затронем в следующем разделе нашего руководства) до формальности былин и эпосов, когда вы от мета-мета-мета-модели (foundational ontology) на базе объектов и отношений вдруг переходите к рассуждениям по аналогии (скажем, прототипной теории понятий, когда фрукты определяются как «разные варианты яблок, всё более и более на яблоки не похожие»), concept blending и прочей уже не логике, а чуть ли не лингвистике. Люди всё-таки в основном используют быстрый и лёгкий режим мышления S1, а не трудный и неудобный режим мышления S2. Рассуждения в S1 трудно критиковать, они «аналоговы», а вот рассуждения в S2 критиковать легко — там работает логика, и там либо вы правы, либо ошиблись. Если вам важна точность, то надо быть формальным: на неточных рассуждениях ракету не построишь, подлодка утонет, предприятие разорится. Но если вы будете только строгим логиком, то вы не сможете разговаривать с «простыми людьми».

В любом случае, нельзя ничего описывать, если ты не осознал, как именно ты описываешь, каким способом описания! Нельзя понять чьё-то описание, если ты не осознал, как именно, каким способом описания это чьё-то описание сделано!

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

Вопрос, а как же тут быть — если всем нужны какие-то разные описания? Как быть, например, в случае того же финансового учёта (для управленцев, pre mortem) и бухгалтерского учёта (для налоговой инспекции, post mortem?). Конечно, надо просто делать несколько разных описаний! Описываемому предмету никак не помешает, если вы сделаете его фотографии с разных ракурсов, разными фотокамерами, а иногда ещё и видеосъёмку, а ещё и просветку в рентгеновских лучах, а потом ещё добавите описание текстом в стихах.

Так, управленцы могут организовать СебеУчёт по Голдратту, а ТебеУчёт1 по РСБУ (для своей налоговой) и ТебеУчёт2 по МСФО (например, для акционеров). Это ОК, это нормально, так и надо делать — только приглядывать за тем, чтобы описывался один и тот же объект (деньги предприятия и их движение), а не разные. Иногда говорят о правилах соответствия (correspondence rules) между объектами разных описаний, но эти правила соответствия не всегда возможно определить, тут не надо обольщаться: соответствий между фотографией кипящего чайника в инфракрасном свете и ведомостью комплектующих для изготовления чайника может не обнаружиться. Но вот в разных инженерных моделерах могут встретиться разные значки для отображения функционального объекта — и тут можно указать, что есть соответствие/correspondence, например, между какой-нибудь functional block из DIN 66001 и functional module из IEC 61346. Конечно, для того, чтобы обнаружить такое соответствие, вы должны подняться на мета-уровень по отношению к этим стандартам: понять, что все эти объекты — функциональные объекты, а не конструктивные или объекты размещения (места).

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

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

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

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

Скажем, вы приняли какое-то решение на совещании. Это решение — описание будущей ситуации, какого-то состояния каких-то объектов. Не записано (и не в протокол, ибо протоколы не выживают больше пары недель, дальше они забываются) — значит решение не принято, а просто «обсуждено». Решение в письменном виде наверняка будет иным, нежели всем «послышалось» как оно звучит устно, там будут обнаружены ошибки, несоответствия другим ранее принятым решениям и т.д. Описания — это отнюдь не только предписанные в каком-то инженерном или менеджерском стандарте описания! Надо очень жёстко отличать системы (и ситуации, то есть системы в каких-то состояниях, учитывающие происходящие с ними изменения состояний) и описания систем, а также выполнять все требования к описаниям, какие бы они ни были. Например, решение на совещании: если это описание (view), то там обязательно должен быть и метод описания (viewpoint). Что именно вы описываете, какие типы основных объектов будут в вашем описании решения совещания?

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

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

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

• Прожекторный метод очень удобен: всё собрано в одном месте, да ещё и согласовано. Проблем типа «вот тут у меня длина в футах, а у вас в метрах, а вот тут у них в попугаях» не возникает, мета-моделирование централизовано!

• Это кошмар для архитекторов: чтобы чуть-чуть пошевелить какое-то описание, надо шевелить сразу все описания вместе, поддерживать это согласование! Прожекторный метод становится «бутылочным горлышком», запрещая по факту автономную работу команд, занимающихся разными описаниями.

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

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

Как увязывают описания в каком-то большом проекте? Обычно используют идеи из стандарта ISO 11354-1:2011, framework for enterprise interoperability (он будет помянут в подразделе «Платформы и инструментальные стеки» нашего руководства, а затем в руководстве по системной инженерии в подразделе «Интеграция данных»):

• Интеграция: есть общий метод описания, которому следуют все участники проекта, это прямая отсылка к прожекторному подходу. Все части проекта в момент создания согласовываются между собой. Дорого, долго, но гарантированно работает! Это вариант «в нашем проекте все говорят на окситанском языке², другие языки запрещены. Кто начинает у нас работать, должен выучить окситанский язык».

• Унификация: согласовываются только описания, которыми обмениваются подсистемы (например, подразделения в организации или космический корабль с ускорительным блоком), а внутри каждой подсистемы описания более-менее автономны/инкапсулированы. Прожекторный подход в каждой подсистеме, далее объявленная публично модель взаимодействия — и прожекторный подход в системе в целом. Это вариант «вы все говорите как хотите, хоть по-испански или по-английски, или вот тут у нас три китайца говорят на мандаринском, но рабочий язык у нас будет — окситанский, совещания только на нём, словарь и учебник опубликованы в стандарте».

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

Отдельное замечание — это мы говорим пока только об описаниях в локальных представлениях. Описания в распределённых представлениях (например, в виде больших языковых моделей в AI-агентах, или в виде просто нейросетей, если речь идёт о каких-то простых описаниях производственных процессов в непрерывном производстве, например, химическом производстве или генерировании электроэнергии) тут мы не рассматриваем. Но это не означает, что их нет и их можно не учитывать. Если рассматривать эти описания, то они сделаны тоже каким-то методом (например, методами глубокого обучения³). В этой области пока нет какого-то понимания методов работы с такими описаниями, но она довольно бурно развивается. По большому счёту, работа с описаниями в человеческой голове тоже проходит в распределённых представлениях. Лучшая практика тут — попробовать отмоделировать нужные части этих описаний при помощи локальных представлений. Тут работает ход, аналогичный вышеописанным ходам с интегрированием, унификацией и федерированием: внутри каждого такого описания может быть что угодно, но для коммуникации надо будет перейти к локальным представлениям — и тогда будет работать всё, что известно про системные описания, данные в локальных/символьных представлениях.

Моделирование: цепочки классификации (операционная модель, мета-модель, мета-мета-модель)

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

Системная модель, мета-модель, мета-мета-модель

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

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

Моделирование — это и есть описание только самого важного, и опускание при описании неважного. Хотите бороться со сложностью — мыслите моделированием!

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

Собранность и моделирование идут рука об руку, биологическому мозгу в моделировании не верим, все результаты моделирования записываем! Мышление моделированием — это не «ментальный акт», это просто явное использование какого-то метода описания в ходе мышления письмом. Не пишешь — не моделируешь, не думаешь!

Для моделирования на каждом уровне абстракции нужно знать три вида объектов:

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

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

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

Вот эта тройка объектов есть на каждом уровне моделирования. Ход мышления от моделируемых экземпляров в мире к модели, далее мета-модели и далее мета-мета-модели и так далее называют «мета-моделированием». Скажем, берём мета-модель и для каждого её типа указываем тип мета-мета-модели, более абстрактный — это мета-моделирование. Берём наоборот — мета-мета-модель и для её типов создаём модель предметной области, мета-модель, это будет шаг на моделирование.

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

Например, «крайний уровень» может оказаться не крайним даже для upper ontology, выше него пойдут уровни объектов разных теорий понятий. А внизу иерархии может быть переход не по отношению классификации, а по отношению представления между моделью и моделируемым объектом.

Как эту троицу «моделируемый объект, модель, мета-модель» обнаружить в жизни? Очень просто: в описаниях обращайте внимание на заголовки и их типы в каких-то человекочитаемых форматах, а в машинночистаемых форматах — на модели данных. Обычно:

• Моделируемый объект — он где-то в мире, в описании отсутствует. Например, эксельный документ, который описывает технико-экономический проект/design сепульки на 8 Ватт: сама сепулька будет в мире, а в технико-экономическом проекте только её описание.

• То, что озаглавлено — относится к модели. Например, будет указано, что этот документ — технико-экономический проект именно сепульки, причём мощность сепульки — 8 Ватт.

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

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

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

Помним: если А::число, то умножать число на число можно, но разбить молотком — нельзя. Если А::орех, то разбить молотком можно, но умножать орех на орех — нельзя! Типы уберегают от ошибок и позволяют договариваться о важном. Вот мета-мета-модель и говорит нам о реально важном, что важнее даже заголовков (мета-модели) в формах/шаблонах описаний!

Как определить, что важно? Важно в описаниях только то, что помогает работать по каким-то методам (в том числе и по методам описания, но только «в том числе»). Если вы рубите::метод лес::«предмет метода», то вам описания красоты леса, оттенка зелёного в листьях деревьев, количества муравьёв на гектар леса — все они не нужны, это не надо моделировать. Но надо моделировать толщину деревьев, количество подлежащих рубке деревьев на гектар, просеки для вывоза срубленных деревьев и т.д.

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

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

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

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

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

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

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

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

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

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

А теперь повторим всё это ещё раз. Увы, онтология не самый простой предмет в интеллект-стеке фундаментальных методов мышления, поэтому повторение может оказаться не лишним. Впрочем, надёжное усвоение начинается где-то с пятидесятого повторения, поэтому повторений в тексте руководства и даже всех руководств программы рабочего развития инженеров-менеджеров будет недостаточно, надо будет все эти рассуждения про системное моделирование многократно повторить в рабочих проектах. Беглость у вас появится после создания пятидесятой таблички (если это моделирование в табличках), где вы проследите, чтобы у вас там был озаглавлен тип объекта описания самой табличкой, колонки таблички соответствовали мета-модели, вы явным образом проговорили типы для каждой колонки, значения модели были бы в каждой строчке таблички, а сами экземпляры моделируемых предметов были в жизни (физичны или брались из других описаний) и соответствовали строчкам таблички. Это не так долго: по три таблички в день через день — и можно справиться за месяц! Чудес не бывает, просто от прочтения наставлений руководств моделировать вы не научитесь. Учебник езды на велосипеде помогает научиться ездить на велосипеде, но без реальной езды — ничего не получится.

«Предмет интереса»/concern/«важная характеристика» в описании/модели (view/model) оформляется/framed «методом описания»/viewpoint/meta-model, а в этом методе описания как раз указывается, что самое важное в моделируемом объекте, что нужно учесть в различных моделях, получаемых при помощи этого метода описания. Это «самое важное» для какой-то модели и называют мета-модель, и выражена она главным образом в типах самых важных объектов, названия типов надо искать в разнообразных заголовках. Если заголовков нет (например, лист электронной таблицы, где цифры есть, а заголовков для этих цифр нет), или в заголовках указаны типы мета-мета-модели (например, вместо «хлеборезка» вы видите «оборудование») — ждите ошибок!

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

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

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

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

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

Мульти-модель. Мега-модель.

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

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

• Обязательно включают описание функциональное, конструктивное, размещение, стоимостное (в том числе гибридные описания: концепция использования, концепция системы)

• Обязательно включают описание систем создателей в их графе (как минимум на одно отношение создания).

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

Не знакомые с системным подходом люди с трудом воспринимают идею множественности моделей, описывающих сложную систему. Обычно они требуют в мульти-модели указать «главную модель», которая является «правильной» по отношению к другим «вторичным» или «вспомогательным» моделям — но в системном мышлении нет «главной модели», для каждой проектной роли просто даётся её набор моделей для ответа на вопросы её ролевых предметов интереса. Нет «главной модели», нужны все модели, каждая в своей онтике/мета-модели/meta-model/framework. Хотя «главная модель» (определяющая набор всех этих моделей и то, что вообще должно моделироваться) таки есть, но это не модель и её мета-модель, но мета-мета-модель. При этом помним, что модели чаще всего задаются на формальном языке, мета-модель тоже обычно имеет формальное выражение (с определениями «как в математике»), а вот мета-мета-модель намеренно избегает определений, остаётся довольно общей (как говорит John Sowa, «намеренно недоспецифицированной»/underspecified, чтобы её типы классифицировали самые разные мета-модели). Понятия мета-мета-модели задаются их употреблением в самых разных контекстах, обычно в рамках изложения текстов на естественном языке — и ровно это и делаем мы в нашем руководстве по системному мышлению, системному моделированию и других руководствах программы рабочего развития инженеров-менеджеров.

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

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

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

Нет, модели должны быть удобны для деятельности на каждом системном уровне как уровне масштаба систем, они должны позволять проводить объяснения (обсуждать причины и следствия происходящего в предметной области интереса), а не абстрактно «научно правильными».

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

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

Как узнать, что должно в проекте быть важным? Мета-моделировать, двигаться от модели к мета-модели и затем мета-мета-модели (важное в построении мета-модели тоже не произвольно, а задаётся типами мета-мета-модели).

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

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

• Отмоделировано несколько масштабов (системных уровней), на каждом уровне новые свойства (учтена эмерджентность).

• Отмоделированы обязательные аспекты: функциональный, конструктивный, размещения, стоимостный.

• Отмоделированы создатели.

• Отмоделирован процесс создания и развития целевой системы её создателями.

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

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

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

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

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

Это иногда называют «управление информацией»: все модели, которые кому-то нужны, должны быть доступны и изменения в них должны доводиться до всех «заинтересованных сторон»/ролей/stakeholders.

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

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

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

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

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

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

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

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

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

Вопросы. Множественность описаний в системном моделировании

Портной пришёл к королю договариваться о новом платье. Укажите из того, что у него было с собой — что составляет модель платья:

+++ карандашный эскиз платья ### Да, это модель платья, которая описывает внешний вид платья.

+++ картина маслом, изображающая короля в платье ### Да, это модель платья, которая описывает внешний вид платья.

--- бумага эскиза и холст картины ### Нет, это не модель, и не мета-модель — это инструменты для моделирования, части «моделера».

--- карандаши, краски, кисти ### Нет, это не модель, и не мета-модель — это инструменты для моделирования, части «моделера».

--- учебник рисования, том 1 «Проекция трёхмерных предметов на плоскость» ### Нет, это не модель — это мета-модель, описание способа сделать модель платья.

+++ записка с описанием основных деталей и потребного материала (кружева на воротник, золото для пуговиц и т.п.) ### Да, это модель платья, которая описывает важные для изготовления платья основные детали/конструктивы платья, а также потребный материал.

Дана карта полезных ископаемых. Что входит в мета-модель этой карты?

+++ легенда карты (условные обозначения месторождений) ### Да, это мета-модель — описание карты.

+++ масштаб карты ### Да, это мета-модель — описание карты.

+++ указание проекции (Меркатора, гномоническая, стереографическая, и т.п.) ### Да, это мета-модель — описание карты.

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

--- инвентарный номер, код тома проекта, к которому относится эта карта ### Нет, это не описание карты как модели местности. Это описание документа — носителя информации, т.е. совокупности бумаги и краски, как объекта корпоративного учёта.

--- наименование территории, для которой сделана эта карта ### Нет, это часть модели — часть самой карты.

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

--- модель ### Нет, модель — это исходный текст программы на Паскале, который моделирует (описывает) программу контроллера робота.

--- мета-модель ### Нет, мета-модель — это описание синтаксиса языка Паскаль в нотации Бэкуса-Наура.

+++ мета-мета-модель ### Да, это описание нотации Бэкуса-Наура (мета-мета-модель), которая описывает синтаксис языка Паскаль (мета-модель), который описывает текст программы на Паскале (модель), которая описывает актуальную программу контроллера робота как объект физического мира (физический процесс выполнения программы в компьютере).

--- мета-мета-мета-модель ### Нет, это было бы описанием описания нотации Бэкуса-Наура (скажем, грамматика русского языка, на котором велось описание нотации Бэкуса-Наура)

--- мета-мета-мета-мета-модель ### Нет, это слишком большой уровень мета-описаний, трудно представить, что ему соответствует (на практике число уровней мета-моделирования редко превышает три или четыре).

Диаграмма Ганта в проекте сооружения жилого дома является моделью:

+++ системы создания жилого дома ### Да, эта модель описывает создателя дома, а именно — его работы. Создатель тут — строительная организация, которая создаёт/строит дом своими работами. Диаграмма Ганта описывает не дом, но создателя — в части работ этого создателя.

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

Николай прислал файл с моделью Варе. Варя не смогла с ним разобраться. Что ещё забыл прислать Николай Варе?

--- печеньки ### Нет, это не имеет отношения к делу.

+++ мета-модель ### Да, модель без мета-модели не может быть понята: если метод описания отсутствует, в самом описании невозможно разобраться. Если Варя не знакома с мета-моделью (не проходила модели такого типа в институте) — ей надо дать мета-модель (например, учебник).

--- документ — бумажное описание системы ### Нет, вид носителя информации обычно не важен, если Варя не знакома с мета-моделью — распечатка ей не поможет. Файл вполне документирует модель.

Инженеру поручили минимально описать холодопырку как систему. Он долго думал, потом принёс начальнику принципиальную схему холодопырки - и получил выговор. Что он, скорее всего, сделал не так?

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

--- для принципиальной схемы был выбран неправильный метод описания ### Нет, просто принципиальной схемы (функционального описания) для минимального описания системы будет недостаточно, какой бы метод ни был выбран.

--- не был указан метод описания для принципиальной схемы ### Нет, просто принципиальной схемы (это функциональное описание) для описания системы будет мало, даже если указать метод её описания.

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

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

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

--- нужна была мега-модель принципиальной схемы ### Нет, мега-модель только принципиальной схемы (только функционального описания) не подойдёт. Мега-модель, в которую входят только принципиальная схема и мета-модель принципиальной схемы всё равно не спасли бы ситуацию. Кроме принципиальной схемы нужны другие описания системы (минимально — конструктивное, пространственное и стоимостное). Так что нужна мульти-модель (и даже не любая, а с минимальным набором аспектных описаний для системного подхода) в составе мега-модели.

Инженер-проектировщик заявил, что по окончании проектирования в описании системы у него будут только конструктивное описание и компоновка — этого вполне хватит, технологам завода больше и не надо, а он отдаёт результаты своей работы технологам. Прав ли инженер-проектировщик?

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

+++ нет, нужно больше описаний ### Да, в описании системы должны быть и другие описания — функциональные, стоимостные/финансовые, разбиения работ и т.д. Так что инженер не прав, этих описаний точно не хватит, и не забывайте ещё о концепции использования, без которой вообще непонятно, что описываем — какую систему!

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

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

--- Снабженца ### Нет, одного основного идентификатора в описаниях нет, все используются на равных — они удобны для разных проектных ролей, использующих их для разных деятельностей. Описание снабженца удобно для снабженца, но нельзя заставлять пользоваться всех остальных только им, считая только его правильным.

--- Монтажника ### Нет, одного основного идентификатора в описаниях нет, все используются на равных — они удобны для разных проектных ролей, использующих их для разных деятельностей. Описание монтажника удобно для монтажника, нельзя заставлять пользоваться всех остальных только им, считая только его правильным.

--- Какой-то ещё ### Нет, одного основного идентификатора в описаниях нет, все используются на равных — они удобны для разных проектных ролей, использующих их для разных деятельностей. Описание кого-то ещё будет удобно для этого «кого-то ещё», нельзя заставлять пользоваться всех остальных только им, считая только его правильным.

+++ Все идентификаторы используются на равных ### Да, одного основного идентификатора в описаниях нет, все используются на равных — они удобны для разных проектных ролей, использующих их для разных деятельностей.

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

+++ квантовомеханическую модель основной реакции ### Да, модели включаются в мега-модель.

+++ мета-модель использованного варианта квантовой механики ### Да, мета-модели включаются в мега-модель.

+++ 3D-модель тиокармы ### Да, модели включаются в мега-модель.

--- письмо автора 3D-модели, указывающее на использование в этом моделировании новейших компьютерных САПР, ускоривших разработку модели ### Нет, это письмо не входит ни в модель, ни в мета-модель тиокармы, это описание создателя тиокармы.

+++ указание на версию компьютерного формата представления 3D-модели ### Да, это указание на мета-модель для 3D-модели, она включается в мега-модель.

+++ текст стандарта, в котором подробно описывается формат представления 3D-модели ### Да, этот стандарт — мета-модель для 3D-модели, он включается в мега-модель. Если текст стандарта легко найти, то можно просто дать на него ссылку.

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

+++ результаты измерений параметров реакции при трёх уровнях температур ### Да, результаты испытаний (они ведь модели) включаются в мега-модель.

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

+++ статьи, где описана параметризация реакции ### Да, мета-модели включаются в мега-модель, а параметризация реакции - это мета-модель для модели реакции в тиокарме. Может, статьи (если их легко найти) нужно включить не текстом, а просто дав на них ссылку.

+++ фотографию тиокармы в сборе и под нагрузкой ### Да, это модель тиокармы, она включается в мега-модель.

+++ все пять диаграмм и четыре таблицы концепции тиокармы ### Да, это просто девять моделей тиокармы, которые все включаются в мега-модель.

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

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

+++ учебник с описанием основ тиокармостроения ### Да, с большой вероятностью этот учебник содержит мета-модели описаний тиокармы — поэтому его правильно включить в мега-модель (может, не целиком, а просто дав на него ссылку).

+++ требования к тиокарме в виде Excel-файла ### Да, это модель/описание тиокармы, и поэтому она должна быть включена в мега-модель. Но помним, что «требования» — это из старой инженерии, и от них отказались не зря. Попробуйте найти и включить также сценарии использования, на основе которых создавались требования, там может обнаружиться много любопытного, а сами требования сегодня — анахронизм.

+++ ссылка на использованный стандарт описания архитектурных решений ### Да, это ссылка на мета-модель для архитектуры, поэтому эту ссылку нужно включить в мега-модель.

Вы хотите подключить к проектированию системы дружественное конструкторское бюро. Для этого вы передаёте им:

--- мульти-модель системы ### Нет, этого будет мало, может не хватить информации о том, как сделаны эти модели, и их не смогут прочесть.

+++ мега-модель системы ### Да, к мульти-модели нужно добавить набор мета-моделей для этой мульти-модели (чаще всего это «настройки САПР и PLM» и их не так-то легко передать). Это и будет мега-модель.

Ваши конкуренты утащили мульти-модель вашей системы и надеются теперь узнать все ваши секреты. Ваши модели хитрые, до вас никто такого сорта моделей не делал. Смогут ли ваши конкуренты раскрыть секреты?

--- увы, да ### Нет, без мета-моделей они ничего не смогут понять в моделях, составляющих мульти-модель.

+++ к счастью, нет ### Да, у конкурентов будут проблемы, без мета-моделей они ничего не смогут понять в моделях, составляющих мульти-модель.

Ваши конкуренты утащили мега-модель вашей системы и надеются теперь узнать все ваши секреты. Ваши модели хитрые, до вас никто такого сорта моделей не делал. Смогут ли ваши конкуренты раскрыть секреты?

+++ увы, да ### Да, если известны мета-модели, то можно прочесть и модели.

--- к счастью, нет ### Нет, неверно: если речь идёт только о мульти-модели (о каких-то описаниях, но не о методах описания), то конкуренты бы не справились. Но тут утащили мега-модель, так что все модели конкуренты поймут.

Понятие конфигурации системы

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

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

В современном производстве принята эволюционная идея, при которой о системе думают как о виде систем: примерно так же, как об эволюционирующем виде животных или растений.

Во-первых, вид систем или животных (это множество, тип) представлен экземплярами (уникальными физическими объектами), которые все генетически немного разные, но принадлежат одному виду. Скажем, система Boeing-737::система при этом мыслится как «вид» из множества экземпляров слегка разных уникальных экземпляров физических авиалайнеров. Как определить, системой называют «вид» или «конкретный самолёт с бортовым номером»? Из контекста, по-другому никак. Если вы говорите о компьютере Dell XPS 13, то вы говорите о нём как обо всех компьютерах серии Dell XPS 13 и их развитии (они будут довольно разные конструктивно, модели каждого года имеют весьма различающиеся конфигурации), или о текущем компьютере с серийным номером, но и тут могут различаться тип центрального процессора, объём памяти, разрешение экрана — это можно выбрать при покупке. И всё это будет Dell XPS 13, в чём-то эти компьютеры будут схожи. То же самое — операционная система Windows, софт в вашем компьютере. Это или все похожие друг на друга версии системы Windows в их отличии от, например, iOS, или же конкретная версия какого-то года, или даже конкретная уникальная версия в вашем компьютере. Как узнать, о чём идёт речь? Из контекста, а если непонятно — переспросить!

Во-вторых отдельно думают о мемоме (все описания системы, они живут и развиваются в организациях-создателях, аналогично геному животных, который содержится в каждой клетке организма животного) и отдельно о феноме (совокупность свойств разработанных и воплощённых систем, у животных это совокупность свойств взрослого организма). В инженерии принят сегодня принцип «непрерывного всего»/ «continuous everything». Прежде всего это «непрерывная разработка»/«continuous delivery», которая не останавливается с выпуском воплощения первой версии системы в качестве MVP, minimal viable product, но главное — «непрерывное введение в эксплуатацию»/«continuous delivery», не путайтесь тут с переводом, это не просто «поставка клиенту», это всё-таки ещё и прошедшее уже разворачивание у клиента, «непрерывное разворачивание»/«continuous deployment» и далее непрерывные испытания/тестирование»/«continuous testing». Непрерывное введение в эксплуатацию означает, что создаются последовательно разные версии системы с разными её конфигурациями (наборами физических материальных частей и соответствующих им описаний, проходящие какие-то альтернативные маршруты по инструментам создателей — какую-то версию на одном станке делали, какую-то на другом), а ещё эти версии имеют разные описания. Понятно, что свойства всех систем получаются при этом разные. И даже эти вроде как конечные описания ещё и изменяются каждое по нескольку раз после доработок, исправлений ошибок, добавления новых возможностей/features в описываемую систему.

Как определить, какие из версий этих описаний должны быть использованы изготовителями для воплощения системы? А если часть изготовителей изменили воплощение системы так, что она уже не соответствует этим описаниям, а часть изготовителей работает «как договаривались» — можно ли быть уверенным, что из изготовленных частей можно будет собрать работающую систему? И какой именно экземпляр работающей системы? Автомобили Tesla разрабатывают сейчас в рамках производственного процесса, где разработчики и завод работают на одной производственной площадке, изменения в конструкцию вносятся без перерывания выпуска, операция на заводе может проводиться в двух альтернативных вариантах по образцу A|B testing⁷, только сравниваются не два варианта всего автомобиля, а множество раз по паре вариантов в разных местах конвейера. Каждый автомобиль Tesla тем самым имеет уникальную конфигурацию, он не похож на другие автомобили той же марки, различаясь во множестве мест. Впрочем, и авиалайнеры делаются так же — чуть разные модификации двигателей, чуть разные конфигурации кресел, чуть разные системы управления, но нет двух одинаковых Boeing-747 в небе. При этом учитываем, что конфигурация системы это одно из конкретных состояний в плане версий частей системы самой «системы как вида» — эта «конфигурация» бегает по дорогам в случае автомобилей Tesla и летает в воздухе в случаях Boeing, это не описание конфигурации, которое не бегает или летает, а документировано в базе данных. Ближайшее к ней приближение — это пока ещё не бегающие и не летающие автомобиль или самолёт, которые уже собраны и проверенные стоят на заводе, они «в металле», но ещё не в эксплуатации. Это только программисты путают конфигурацию своей «проектной документации» (их исходных кодов) с конфигурацией самой системы (их уже работающей в машинных кодах программы). Инженеры «железных» систем точно должны понимать, что конфигурация системы, а то, что там есть ещё и описания без конфигурационных коллизий — это очень хорошо, но недостаточно для разговора о конфигурации, конфигурация описаний системы — это не конфигурация системы в момент её эксплуатации.

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

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

Управление конфигурацией (configuration management) — отслеживание, что конфигурация воплощения системы и описания системы известны и соответствуют друг другу. Эта дисциплина лежит посредине между менеджерскими и прикладными инженерными дисциплинами. Конфигурация составляется из конфигурационных единиц (configuration item) — самых мелких частей, на которые делится система в части её логистики. Речь идёт о единицах передачи частей системы и описаний этих частей от одного исполнителя работ к другому, от одной обработки к другой.

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

Чтобы не потерять эти конфигурационные единицы при учёте, иметь возможность на них сослаться в разговоре и различных описаниях системы, им даются индивидуальные обозначения (designations). Стандарт IEC 81346⁸ представляет собой стандарт, в котором предлагается типовой способ такого описания, учитывающий системный подход — наличие нескольких альтернативных структур системы (функциональной, модульной/продуктовой, размещений, стоимостной и т.д.).

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

В программной инженерии тоже есть варианты стандартов описания конфигураций, но они обычно не учитывают системный подход и опираются главным образом на идею о версиях исходного кода. Популярны «системы именования» частей кода Semantic Versioning⁹, где делается попытка менять имена версии на основании того, большие изменения вносятся в исходный код, или это маленькие изменения, но потихоньку выясняется, что и большие, и маленькие изменения могут поломать систему в случае коллизии одинаково, поэтому предложили вариант попроще и понадёжнее: Calendar Versioning¹⁰, где просто отмечается дата последнего изменения версии — так что можно по имени версии сразу сориентироваться, давно ли что-то в ней менялось.

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

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

Управление изменениями (change management) часто включают в состав управления конфигурацией. Так и пишут: «управление конфигурацией и изменениями», но обычно это отдельная дисциплина. Её не нужно путать с управлением организационными изменениями — как нужно менять организацию, чтобы это не вызывало сопротивления людей и вело к положительным результатам. Инженерное управление изменениями — это про то, как принимать решения по изменению конфигурации, чтобы минимизировать конфигурационные ошибки. Для этого в конфигурации раньше различали 1. обычные рабочие версии с более простыми внесениями изменений, и 2. базисы, внесение изменений в которые связано с дополнительными инженерными и административными проверками на целостность конфигурации. Сегодня это седая старина, используют другие подходы к управлению изменениями, например, trunk-based development¹¹ (trunk/ствол — только ствол дерева версий, без ветвлений). Появилось много интересных наблюдений, например, что качество систем, для изменений базисов которых собирался какой-то совет по внесению изменений по факту не отличалось от качества систем, для которых базис не проходил какой-то коллективной оценки: любое «замораживание конфигурации» замедляло разработку, но не приводило к улучшению качества. Скажем, «заморозить внесение новых фич в конфигурацию, но не заморозить исправление в ней багов» повышало качество, но вот чтобы что-то там «замораживалось» в части описаний или самой конструкции — вот это оказалось вредным. Всё живое, всё меняется к (потенциально, не всегда получается) лучшему, а если ошиблись — это покажет интенсивное тестирование, которое проводится буквально для каждого экземпляра системы (один экземпляр — одна версия системы, как мы говорили), каждой версии каждого описания.

В любом случае, у вас должно быть налажено управление конфигурацией, вы в любой момент должны понимать, какие именно (из всех возможных вариантов) части системы стоят в изготовленной системе, по каким описаниям они производились — и тут важно, чтобы все они были без коллизий, в них не было ошибок и противоречий при объединении частей системы в систему и частных описаний в системное описание. Очень нехорошо получается, когда команда А разрабатывает свою часть системы с учётом результатов совещания, где размер части был принят 220 мм, а команда Б продолжает разрабатывать корпус, где для этой части предусмотрен старый размер 180 мм — ибо про совещание эта команда ничего не знала. Потом при сборке эта части встретятся: вот она, конфигурационная коллизия: ожидаемый корпусом размер части и размер изготовленной части не совпадают на 40 мм, система «не собирается». Лучше бы это найти до того момента, когда команда А уже изготовила эту часть системы, а команда Б — изготовила корпус. Вот этим и занимается управление конфигурацией и изменениями, чтобы такого в принципе не могло бы получиться.

Функциональные описания: принципиальные схемы и сценарии

У очень и очень многих проектных ролей область интересов включает важные характеристики системы времени работы/operations, когда система готова и эксплуатируется, в run-time/operations. Объяснить, как система работает (то есть описать причины и следствия во взаимодействиях подсистем), можно при помощи функциональных описаний. В них мы объясняем назначение (функцию/метод работы) каждой функциональной части системы и вклад этой части в достижение общего назначения системы, общего поведения системы в её окружении (run-time).

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

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

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

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

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

Функциональные части физичны (в момент, когда они воплощены конструктивными/материальными объектами), они выбираются для системы так, чтобы удобно было объяснять работу системы во время её эксплуатации/функционирования (run time, operations). Потоки — это чаще всего логические/ролевые/функциональные объекты, которые тоже физичны, выделяются из мира на основе постоянства пути, а не постоянства вещества (скажем, в реке путь воды одинаков, но сама вода в любом сечении — в каждый новый момент времени разная), и через которые функциональные части взаимно влияют друг на друга. Потоки могут быть самых разных объектов, которые проходят один и тот же путь: могут быть и потоки света, и электрический ток/поток/current, и потоки энергомассопереноса (в тепловых машинах), и даже потоки данных (в программных системах).

Потоки выделяются из физического мира на основе постоянства сохранения пути во времени, равно как функциональные объекты выделяются на основе постоянства сохранения функции во времени, а конструктивные — постоянства материала при изменениях, пространственные — постоянства места. Это идеи из онтологии/мета-мета-модели ISO 15926-2, мы уже обсуждали это в нашем руководстве более подробно в разделе про методы/функции/практики, в подразделе про ролевые объекты/роли и «игру по роли»/функцию/назначение в окружении.

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

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

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

Вот пример такой функциональной диаграммы (function model¹²) в давно морально устаревшей, но чрезвычайно распространённой и часто встречающейся нотации IDEF0. Слева от каждого элемента его входы, а справа — выходы, на стрелках написано, что именно передаётся от выхода предыдущей функциональной части на вход следующей. Какой тут самый распространённый тип ошибки при чтении таких диаграмм? Это функциональные части и «логическое время метода работы», но часто это читается как «физическое время протекания экземпляра работы», и вот тут будет проблема: можно попасться в западню ситуации «ножниц», когда функциональное и конструктивное разбиения будут различными и «логическое/функциональное время» не будет совпадать с «физическим/материальным временем». Для материального времени используются другие диаграммы, на них показывается часто синхронизация — это, например, тоже давно устаревшая нотация IDEF3 (и в этом и проблема, что вместо неё используют нотацию IDEF0, девять раз из десяти ситуаций когда методы/функции и работы относятся как 1:1, это ОК, но в десятой ситуации они расходятся как в примере с ножницами, где ножевой блок и рукоятка не совпали с изготавливаемыми в конструктиве двумя половинками ножниц). Так что вы в жизни обязательно увидите эти IDEF0 диаграммы, будьте аккуратны к тому, что на них пытались изобразить — это не всегда будут функциональные объекты и потоки.

Ещё один вид функциональных описаний — это сценарии (scenario), иногда говорят о сценариях использования (use cases, переводить нужно не как «варианты использования», а именно «сценарии использования» — оригинальный термин придумал Ivar Jacobson по-шведски, и это был как раз «сценарий», case был признан им неудачным переводом на английский¹³).

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

Режимы работы/функционирования какой-то системы обычно рассчитываются именно по функциональным описаниям, они ведь привязаны именно ко времени работы системы, а не ко времени её создания. Мультифизическое моделирование делается именно для функциональных описаний: ищутся оптимальные характеристики функциональных объектов для заданных режимов работы. Конечно, система моделируется в её окружении (это ведь run-time/operations-time, и работа системы существенно зависит от состояния её окружения). Будьте осторожными: мультифизическое моделирование иногда называют в инженерии «системным моделированием» и привязывают к специфическому классу софта, поддерживающему какой-нибудь физический моделер с описаниями на акаузальном языке моделирования физики, например, Modelica. Но нет, это не полноценное системное моделирование, это моделирование функционального описания (например, расчёт значений характеристик функциональных объектов по какой-то принципиальной схеме — часто это называют вообще 1D моделированием, ибо моделируем только одну какую-то характеристику при заданных остальных), а не всех описаний. Как это понять? Из контекста, как всегда: если слышите «системное моделирование» и уж тем более «системный моделер», просто из контекста поймите — вам рассказывают о системном моделировании в рамках системного подхода, или просто этим словом обозначают мультифизическое (механика, плюс электрика, плюс гидравлика и т.д.) моделирование какой-то системы.

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

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

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

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

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

Конструктивные/продуктовые описания

Когда предмет интереса для какого-то метода работы относится не ко времени работы системы, а ко времени построения системы — что-то, что интересно для модульного синтеза, закупки конструктивов/продуктов/модулей/изделий/блоков, сборки системы как конструкции из уже закупленных конструктивных частей, отгрузки уже созданной системы/продукта/изделия, то необходимо использовать конструктивные/продуктовые описания. Эти описания отвечают на вопрос «как сделана система» (ср. с функциональным «как работает система») и они относятся ко времени создания (design-time, construction), а не использования (run-time, operations). Помним, что в design-time мы включаем не только проектирование, но и изготовление, и модернизацию, и уничтожение. Но не включаем время работы/operation/функционирования/эксплуатации/использования.

Как и в случае функциональных частей, есть разные графические (диаграммы), текстовые (на естественном языке, на полуформальном «псевдокоде», на формальных языках) и табличные форматы (например, в электронных таблицах Excel, Coda.io, Notion.so, Airtable) представления описаний конструкций.

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

Часто конструктивные части называют по-разному в зависимости от их уровня в конструктивном разбиении: детали (если не предполагается сборки-разборки, альтернативное название — элемент, «далее неразбираемое на части»), подсборки/subassembly, сборки/assembly, иногда даже подсистемы/subsystems (но тут легко перепутать с подсистемами в их функциональной ипостаси), и далее — система (тоже легко перепутать систему-конструктив с системой в её функциональной ипостаси, системой-ролью-в-окружении). Практика закрепления отдельных имён типов для уровней сборки — плохая, ибо в рамках эволюционирования системы вы заменили три детали и восемь винтов одной деталью сложной формы, изготовленной на 3D-принтере, а то и напечатали подсборку целиком — и всё, надо довольно много менять в плане именований в проекте. Помним: если у вас развесистая иерархия по какому-то одному типу отношения с одним типом объекта (одинаковые операции с этими объектами на каждом уровне, в том числе операции мышления об этих объектах), избегайте давать разные имена типов объектам разных уровней каких-то разбиений: число уровней наверняка поменяется в ходе создания и развития системы, вам придётся долго всё переименовывать.

Интерфейсы конструктивов похожи на порты ролей в том плане, что это именно места присоединения (при этом часто и на диаграммах это выглядит как «место в квадратике, куда присоединяется какая-то стрелка одним из концов»), то есть интерфейсы сами — не конструктивы, они не занимают объёма в пространстве, хотя у них и может быть форма «границы в пространстве». Вилка и штепсель, гнездо и штеккер, кабель USB и гнездо USB: для всех этих пар интерфейс — «то, что между», «междумордие/interface», а не сама «морда/face».

А как назвать сам физический конец электрического шнура, оформленный в соответствии со стандартом вилки, штеккер для какого-то гнезда, разъём в компьютере для USB кабеля? Это всё будут интерфейсные модули, главное назначение которых — реализовать какие-то интерфейсы в физическом мире, то есть быть парой к другому такому интерфейсному модулю. И у этого модуля не один интерфейс обычно, а два интерфейса: один целевой, а другой — присоединяющий его к какому-то модулю, для которого нужен целевой интерфейс. Конечно, «модуль» тут только один из возможных синонимов. «Изделие с интерфейсом», «интерфейсный конструктив»: любое слово, которое относится к конструктивам, времени сборки.

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

Вот пример такого старинного интерфейсного модуля (который в просторечии называют USB-интерфейс, что неверно — у него есть ещё и сигнальный интерфейс к плате, и отдельный интерфейс к питанию и даже интерфейс к человеку: светодиод, который мигает, когда идёт передача данных и кнопка включения, а ещё есть механический интерфейс крепления к корпусу или другой плате):

А как же соединения, которые нужны для работы — все эти трубы, кабели, волноводы? Это тоже конструктивы/модули/продукты/изделия/артефакты, и у них есть свои интерфейсы: они находятся между ними и теми модулями, которые они соединяют. Что проходит через эти интерфейсы, и как оно связано с работой всей системы?

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

Решения модульного синтеза (изобретения в порядке создания концепции системы):

• определяют, роли каких именно функциональных частей будут играться теми или иными конструктивами,

• определяют, какие между этими конструктивами будут интерфейсы, и через эти интерфейсы какие будут проходить потоки между функциональными объектами (их мы обсуждали в предыдущем разделе про функциональные описания),

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

Часто речь идёт о приёме-переработке-выдаче модулем какого-то проходящего через входные и выходные интерфейсы этого модуля физического потока. Этот физический поток будет реализовывать функциональный поток из функционального описания (например, принципиальной схемы), который идёт через функциональную/ролевую часть, на исполнение роли которой назначен модуль. Так, через USB-интерфейс может передаваться тот или иной поток данных (на принтер, на слайд-проектор, на внешний монитор), физически это будет соответствовать прохождению какого-то профиля электрического тока через контакты интерфейсных модулей — но на принципиальной схеме/функциональной диаграмме/dataflow diagram это будут потоки предметных из прикладной предметной области (domain) данных между функциональными частями системы, то есть потоки страниц для принтера, слайдов для проектора, экранов для внешнего монитора.

При интеграции (часто используют это слово) разных конструктивов в целую работающую систему важна не просто механическая сборка из готовых конструктивов, но ещё и согласование работы этих конструктивов после соединения их через их интерфейсы. Монтажник/сборщик должен убедиться, что соединение через интерфейс между парой интерфейсных модулей установлено, соответствует стандарту, описывающему интерфейс, и тем самым модуль сможет играть свою функциональную роль во время работы/функционирования/operations/run-time.

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

Например, принтер и компьютер связаны через USB интерфейс, но какая информация идёт принтеру, это интерфейсу неизвестно. Утюг к электросети подсоединён через интерфейс между евровилкой и евророзеткой, но этому интерфейсу неизвестно, какой через неё пойдёт ток и что этот ток будет делать в run-time. Но известны не зависящие от функциональности предельные значения тока, который может пройти через этот интерфейс, равно как предельное количество информации, которое может пройти через USB-интерфейс в единицу времени. Задача модульного синтеза при проектировании системы — это выбрать такие интерфейсные модули, интерфейсы которых смогли бы выдержать потоки с их рабочими режимами, предусмотренные функциональным описанием системы.

Вот ещё пример конструктивного/модульного/компонентного (в IEC 81346-1 предлагается компонентом называть заказной продукт, который приходит в проект от других создателей) описания, в этом случае речь идёт просто о списке комплектующих (ещё одно название продукта/компонента), которые нужно купить для изготовления iPhone 2008 года, при этом приведены цены — и тут же это становится гибридным описанием, ибо включает и стоимостные оценки¹⁵:

Обратите внимание, сколько тут упоминается разных стандартов: GPS, HSPDA, DDR, Bluetooth — перечисление интерфейсов, описываемых стандартами, обычно для конструктивных описаний. Ведь вся суть модулей — это замена реализации какой-то функциональной части системы путём простой замены конструктивной части: модуля на стандартном интерфейсе. Быстрый прогресс в инженерии смартфонов и ноутбуков определяется именно этим: тщательным описанием интерфейсов.

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

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

Метод борьбы с завышением стоимости заказной разработки — требовать, чтобы межмодульные интерфейсы были прописаны не в контракте, а в открытом стандарте, контракт же содержал только ссылку на открытый широкой публике стандарт. Тогда больше шанс, что возникнет конкуренция и цены на закупаемые модули станут ниже. Этот метод борьбы за низкие цены комплектующих называется открытая архитектура/open architecture¹⁶. Но регулярно архитектуру (решения по нарезке системы на какие-то модули с определением интерфейсов по связи этих модулей, то есть решения по особенностям модульной части модульного синтеза, в котором увязываются решения по функциональной декомпозиции и затем предлагается синтез целой системы из модулей) не открывают из соображений защиты от конкурентов, а также для того, чтобы проще было управлять конфигурацией. В закрытой архитектуре, чтобы поменять интерфейс взаимодействия модулей, нужно договориться меньшему числу людей. Но если интерфейс записан в открытом стандарте, то для изменения стандарта нужно много больше времени. Архитектура iPhone как раз относится к этому классу закрытых архитектур. И это не самое дешёвое устройство, хотя переговорная сила Apple достаточно велика, чтобы держать низкими цены на комплектующие: просто там большие объёмы выпуска каждого модуля, и эти большие объёмы — мощный фактор на переговорах.

Все эти рассуждения относятся и к предприятиям/организациям, но для них функциональные части — это оргроли, функции — методы/способы работы, конструктивные части — это оргзвенья, выполняющие работы по оговорённым в функциональном описании методам. Конечно, между оргзвеньями должны быть определены какие-то интерфейсы, и как они должны работать, определяется орг-архитектурой. Об этом будет рассказано подробней в руководствах по методологии и системному менеджменту, понятие архитектуры подробно разбирается в руководстве по системной инженерии.

Вопросы. Функциональные, конструктивные, пространственные, стоимостные части — 3

Чтобы вызвать Бэтмена, надо изобразить на облаках силуэт летучей мыши. Что реализует интерфейс для вызова Бэтмена?

--- Луч прожектора ### Нет, его недостаточно для появления силуэта летучей мыши на облаках.

--- Прожектор и луч прожектора ### Нет, силуэту будет не на чем проявляться, сигнал не будет передан.

--- Луч прожектора и облака ### Нет, лучу неоткуда взяться.

+++ Прожектор, облака и луч между ними ### Да, прожектор, облака и луч реализуют интерфейс для вызова Бэтмена.

--- Человек-пингвин ### Не имеет отношения к делу.

--- Что такое Бэтмен?! ### Не имеет отношения к делу.

Главное управление разведки РККА внедряет Всеволода Владимировича Владимирова в VI отдел РСХА, с позывным «Юстас». Сведения в ГУР РККА своему куратору «Алексу» он передаёт с помощью связной Кэт, у которой есть передатчик, шифр и протокол связи. Когда говорят про интерфейс между «Юстасом» и «Алексом», то имеют в виду:

--- Связная Кэт, с передатчиком, шифром и протоколом связи ### Нет, реализующие интерфейс конструктивы (связная Кэт, передатчик) — это не интерфейс.

--- Связная Кэт, с передатчиком, шифром и протоколом связи, а также автомобилем, в котором она выезжает к месту проведения сеансов связи ### Нет, реализующие интерфейс конструктивы (связная Кэт, передатчик, автомобиль) — это не интерфейс.

+++ Шифр и протокол связи ### Да, шифр и протокол связи описывают интерфейс — то, как взаимодействуют «Юстас» и «Алекс».

--- Передатчик, шифр и протокол связи ### Нет, реализующий интерфейс конструктив (передатчик) –не входит в интерфейс.

В цехе производства кроссовок на линии изготовления подошв поставили вторую машину для литья под давлением, такую же, как уже работающая, и отрегулированную точно так же. Цех также используется для обучения персонала технологии литья под давлением, новая машина не будет использоваться в процессе обучения. Машина 1 (М1) и Машина 2 (М2):

--- М1 и М2 являются конструктивными частями в системе производства и функциональными частями в системе обучения ### Нет, М2 не является функциональной частью в системе обучения.

+++ М1 и М2 обе являются конструктивом в системе производства, и ещё М1 является конструктивом в системе обучения ### Да, ибо М2 не является конструктивом в системе обучения.

--- М1 и М2 является единым конструктивом М1М2 в системе производства и таким же конструктивом в системе обучения ### Нет, М2 отличается — это не конструктив в системе обучения.

--- М1 и М2 являются функциональными частями как для системы производства, так и для системы обучения ### Нет, М2 не является функциональной частью в системе обучения.

Если рассматривать ассортимент магазина (совокупность товаров, находящихся на складе онлайн-магазина) как целевую систему, то интерфейсным модулем, реализующим интерфейс к ассортименту, будет:

--- Модуль управления корзиной покупателя на сайте магазина ### Нет, этот модуль взаимодействует c покупателями, но не взаимодействует с ассортиментом.

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

+++ Операторы склада, комплектующие и отгружающие заказ покупателю. ### Да, именно модуль «операторы склада» физически соприкасается с ассортиментом, он реализует интерфейс непосредственного взаимодействия с ассортиментом.

--- Протокол HTTPS, по которому покупатели соединяются с веб-сайтом магазина. ### Нет, протокол HTTPS — это вообще интерфейс, а не интерфейсный модуль.

--- Ничего из вышеперечисленного ### Нет, один из ответов вполне описывает интерфейсный модуль к ассортименту — с ассортиментом физически работают операторы склада.

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

--- Конструктив в системе создания гипермаркета ### Нет, монетка ни в каком смысле не «делает» гипермаркет, она не часть создателя гипермаркета.

--- Функциональная часть в создателе гипермаркета ###Нет, монетка ни в каком смысле не «делает» гипермаркет.

--- Конструктив гипермаркета ### Нет, монетка не входит в состав гипермаркета как элемент конструкции.

--- Функциональная часть гипермаркета ### Нет, монетка не входит в состав гипермаркета как функциональная единица.

+++ Конструктив в окружении гипермаркета ### Да, монетка является конструктивным элементом системы выдачи тележек из операционного окружения гипермаркета.

--- Функциональная часть в окружении гипермаркета ### Нет, монетка — это конструктив, а функциональный объект называется как-то по-другому, по функции — например «средство залога за тележку» или «жетон/token для выдачи тележки».

--- Интерфейс к создателю ### Нет, ни о каких интерфейсах к каким-то создающим гипермаркет системам речь не идёт. И монетка — это конструктив, а не интерфейс.

--- Интерфейсный модуль к системе создания гипермаркета ### Система создания — это которая в каком-то смысле создаёт (проектирует, строит, ремонтирует) гипермаркет. Ни о каких интерфейсах к такой системе речи не идёт.

Инженер «ГИПРОПуть» Петя разрабатывает проект укладки рельсового пути (3D-модель с допусками и посадками) и проводит расчёты его механической прочности. Инженер НИИ «Вагон» Маша разрабатывает обод колеса трамвая (3D-модель с допусками и посадками). В своей работе и Петя, и Маша, в том числе, руководствуются стандартами прокладки трамвайной колеи, стандартными длинами рельс и вагонов. Эти стандарты являются описаниями:

+++ Интерфейса между конструктивами трамвая и пути ### Да, именно так — стандарты описывают взаимодействие рельса как конструктива пути и колеса как конструктива трамвая.

+++ Интерфейса между системой трамвая и системой пути ### Да, стандарты описывают взаимодействие между трамваем и путём (системы — это не только функциональные части надсистемы, но и конструктивы тоже, просто это разные их ипостаси).

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

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

Инженер Петя купил японский ноутбук Тошиба в производственном исполнении (работает от -50 до +85 градусов Цельсия, выдерживает падение с высоты человеческого роста, класс защиты от пыли и воды IP67), но обнаружил, что не может использовать его, т.к. блок питания ноутбука на 12 В рассчитан на входное напряжение 110 В, 50 Гц, штекер типа А. Для решения проблемы он покупает трансформатор, который может подключаться к бытовой электросети РФ 220 В и у которого есть питающая розетка 110 В. Петя подключает ноутбук к трансформатору и работает. Петя изменил:

--- Интерфейс питания ноутбука ### Нет, у самого ноутбука сохранился тот же интерфейс для его питания, 12 В.

+++ Воплощение системы питания ноутбука ### Да, воплощение системы питания было изменено: добавился трансформатор.

+++ Интерфейсный модуль питания ноутбука ### Да, интерфейсный модуль питания ноутбука был изменён: туда добавлен трансформатор.

«Интерфейс USB представляет собой маленькую печатную плату с закреплённым на ней USB-разъёмом». Как исправить эту фразу?

+++ Заменить жаргонизм «интерфейс USB» на «интерфейсный модуль USB» ### Да, интерфейс бывает «между модулями», а реализует его какой-то модуль — так что печатная плата — это не интерфейс, а интерфейсный модуль.

+++ Заменить жаргонизм «интерфейс USB» на «интерфейсный модуль USB» и добавить описание интерфейса подключения печатной платы к шине компьютера ### Да, интерфейс бывает «между модулями», а реализует его какой-то модуль — так что печатная плата — это не интерфейс, а интерфейсный модуль. Кроме того, этот модуль имеет какой-то интерфейс подключения печатной платы к шине компьютера, так что можно указать и его.

--- Убрать слова про USB-разъём, ибо и так уже ясно, что это интерфейс USB ### Нет, печатная плата - не интерфейс, интерфейс бывает между модулями, но реализующий интерфейс модуль должен называться «интерфейсный модуль», а не «интерфейс». Если убрать слова про USB-разъём - ошибка останется. Нужно писать «интерфейсный модуль» или «интерфейсный конструктив».

--- Указать тип микросхемы, преобразующей входной сигнал в сигналы стандарта USB ### Нет, печатная плата - не интерфейс, интерфейс бывает между модулями, но реализующий интерфейс модуль должен называться «интерфейсный модуль», а не «интерфейс». Если указать тип микросхемы, эта ошибка не будет исправлена.

«Вчера произошла блокировка автоматики наземной системы управления. Программа полёта была прервана на короткий срок. Проблема была в том, что не прошло подтверждение нормальной работы систем по одному из параметров. Мы в ручном режиме убедились, что системы работают нормально. По всей видимости, причина в дефекте одного из кабелей, кабели были заменены». О замене чего идёт речь?

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

+++ О смене конструктива ### Да, заменили конструктивы/модули (кабели, конструктивные единицы), их функции остались те же.

--- Об изменении топологии ### Нет, топология не имеет отношения к делу.

--- Об изменении размещения ### Нет, компоновка не поменялась.

--- О смене интерфейса ### Нет, способ соединения конструктивов не поменялся.

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

--- Да, утверждение сформулировано корректно ### Нет, у функциональных частей обычно говорят про соединения/связи, а интерфейсы определяют у конструктивов.

+++ Нет, в утверждении термины использованы сомнительно ### Да, сомнительно использование термина «интерфейс» в отношении функциональной части.

«В модуле компьютерного зрения дрона изменили интерфейс к системе распознавания изображений - теперь там используется API облачного сервиса вместо обращения к собственной библиотеке модуля.» Всё ли нормально с данным утверждением?

+++ Да, утверждение сформулировано корректно ### Да, говорится о связи модуля компьютерного зрения с разными модулями, реализующими функциональную часть «система распознавания изображений». Вместо модуля библиотеки через интерфейс используется облачный сервис, и соответственно был изменён интерфейс модуля компьютерного зрения.

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

Платформы и платформенные/инструментальные стеки

Если рассмотреть конструктивное/продуктовое/модульное разбиение (PBS, product breakdown structure в отличие от функционального разбиения SBS, system breakdown structure), в нём можно увидеть на каждом уровне иерархии по отношению композиции какие-то наборы мелких конструктивных «кирпичиков», которые предоставляют через свои интерфейсы сервисы для сборки на их основе конструктивных «кирпичиков» более высокого уровня, которые могут выдать потенциально обширный набор функций во время их использования в каких-то ролях. Вот такой согласованный по предоставляемым ими совместно сервисам (сервис тут чуть-чуть уточняется как «функция, порт функционального объекта которой доступен в момент использования как интерфейс какого-то конструктива») набор модулей с их предопределёнными интерфейсами называют платформой.

Платформа — это всегда конструктивное/продуктовое/модульное рассмотрение системы с подчёркиванием стандартности получения ожидаемого в момент использования сервиса через опубликованный интерфейс.

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

В инженерии

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

• Разработчики берут за должное интерфейс и определяют, какие порты он будет реализовывать во время использования. Их задача — реализовать функциональность в рамках заданных архитектором ограничений (не всякий интерфейс сможет во время использования системы обеспечить работу порта какого-то функционального объекта).

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

Для программных конструктивов (компонент, модулей, приложений, библиотек — термин зависит от предпочтений школы программной инженерии) этот интерфейс обычно называется API (application program interface), программный интерфейс приложения/application program. Тем самым приложение, которое публикует описание своих интерфейсов, по которым можно получить его сервисы путём его вызова откуда-то извне, становится тоже платформой.

Если речь идёт не о программной системе, то можно говорить просто о прикладном интерфейсе (application interface, а не application program interface).

Платформа, если реализована библиотекой программ или «железными» модулями, то можно выбирать в зависимости от проекта:

• входит как конструктив в состав приложения или продукта/изделия в ходе его работы, является его подсистемой, выполняющей какие-то роли,

• входит в состав окружения, предоставляя сервисы для каких-то частей системы (платформа предоставляется сервис-провайдером),

• входит в состав создателя (и тут тоже платформа предоставляется сервис-провайдером).

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

«Внутренняя платформа разработки»/«internal development platform» в platform engineering¹⁷. Сервис-провайдер для этой платформы создаётся инженером внутренней платформы разработки (это одна из ролей в инженерии), а сервисы этой платформы через опубликованный интерфейс получают разработчики — платформа изготавливает своими сервисами из программного кода работающую на компьютерном железе готовую программу. Термин «внутренняя платформа разработки» появился в программной инженерии. Но в «железной» инженерии это завод, который используется разработчиками. Подробней — в руководстве по системной инженерии. Аналогичной платформой будет администрация компании, которая предоставляет сервисы (финансовый, юридический и т.д.) для менеджеров-организаторов компании, она создаётся и поддерживается администрацией. Подробней — в руководстве по системному менеджменту. В учебных организациях поток студентов проходит обработку в деканате, который выполняет ту же роль администрации — это платформа, которая создаёт «учебную организацию» из студенческих групп, тот самый «завод», на котором делают из студентов мастеров. Подробней — в руководстве по инженерии личности.

Маркетплейс тоже называют платформой, ибо маркетплейс публикует интерфейсы сервисов для продавцов и покупателей, а иногда и платёжных систем. Иногда создание таких платформ называют уберизацией/uberisation, а для французской википедии приводят и синоним — платформизация/plateformisation¹⁸ — в честь фирмы вызова такси Uber, которая создала платформу гарантированной «поставки против платежа» с двумя опубликованными интерфейсами: сервиса для водителей такси и сервиса для пассажиров такси. В принципе, сервис поиска каких угодно клиентов для каких угодно сервисов или товаров — это поисковая система, прежде всего Гугл. Но при уберизации платформой выполняется главный сервис: гарантирование поставки против платежа, платформа-маркетплейс выполняет роль страховщика и биллинг-агента как для клиента, так и для провайдера сервиса (а проекты, где этой страховки не происходит, обычно более чем скромны по масштабу — за просто сводничество много денег не дают, без страховки всегда можно найти поставщика сервиса через поисковик, а вот дальше надо будет разбираться со страховкой и биллингом).

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

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

• внутренними для проекта (опубликованы в рамках коллектива разработчиков),

• открытыми (опубликованными от какого-то официального источника в публичном документе, не подразумевающем проверку выполнения или стандарте, подразумевающем проверку выполнения какой-то реализацией),

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

В мышлении это мало отличается от обращения к программному сервису (помним, что «сервисом» часто называют и поведение провайдера, и самого провайдера сервиса, «службу», «сервер»), или обращением за сервисом к какому-то оборудованию. В этом плане и leader и follower, следуя стандарту «базы» танца с её сигналами, представляют друг для друга платформу этой «базы», они предоставляют друг другу сервисы (leader — сервис выдачи интересных сигналов ведения, follower — расшифровки и выполнения этих сигналов, одна из интерпретаций социальных танцев — это совместная «игра в загадки»¹⁹). И важная особенность социальных танцев: стандартизация интерфейса, «платформенность» приводит к тому, что leader и follower, приехав на какую-то фестивальную вечеринку из разных стран и впервые танцуя друг с другом, смогут абсолютно предсказуемо и надёжно взаимодействовать друг с другом, а также «обслужить» множество партнёров. Это взаимодействие в социальных танцах в системном мышлении описывается примерно в том же наборе понятий, что взаимодействие смартфона и его сотовой станции, трамвая с его путями, веб-браузера с веб-сервером — для всех этих случаев мышление устроено одинаково, используются одинаковые типы мета-мета-модели (но, конечно, абсолютно по-разному это всё называется в каждой предметной области. Так, стандарт ведения-следования в социальных танцах никогда не назовут интерфейсом, там таких «умных слов» не знают. Проблема в том, что его вообще никак не назовут, разве что «негласное соглашение о ведении-следовании»).

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

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

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

В электротехнике есть три типа неисправностей: есть контакт там, где он не должен быть, нет контакта там, где он должен быть, и плохой контакт. Это шутка как раз про интерфейсы — которые должны быть именно там, где они предусмотрены конструкцией!

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

Итоговое многоуровневое продуктовое/платформенное разбиение называют платформенным стеком или инструментальным стеком (stack, стопка — диаграммы похожи на стопку подносов в столовой или стопку листов бумаги в пачке). Вот пример различных инструментальных стеков для межкомпьютерной коммуникации в интернете вещей (IoT, internet of things)²⁰:

На диаграмме видно, что в разных сравниваемых стандартах связи описываются/определяются/defined пять платформенных уровней (конструктивов по отношению часть-целое), которые можно разделить на реализующие в момент использования роли для функций передачи физического сигнала (physical), передачи данных (Data Link) и т.д. При этом конструктивы передачи данных при работе обращаются к конструктивам передачи физического сигнала, используя указанные в диаграмме протоколы интерфейсов²¹. И так по всем уровням выше, вплоть до уровня целого конструктива как приложения/application: каждый уровень платформенного/инструментального стека (уровень реализующих этот стек конструктивов) даёт интерфейс для оказания сервиса наверх и использует сам при этом сервисы нижележащих модулей. Где тут пролегает граница между системами и окружением? Всё зависит от проекта: часть этих уровней может быть реализована какой-то системой, а часть — её окружением.

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

Главное в показе этого инструментального стека то, что

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

• интерфейсы реализующих сервисы этих платформенных уровней стандартизованы — как стандартизован и сам набор этих уровней.

Эти инструментальные/платформенные стеки вездесущи. В танцах вы передаёте сигнал от плеча leader к руке follower (то есть от части тела к части тела в целом), а не от мышц к мышцам, или даже от мышц плеча через кожу, затем кожу и дальше через рецепторы и нервы дальше к мышцам руки follower. Мышцы — это конструктивные объекты более низкого уровня, и если у «плеча» и «руки» ничего не поломалось, чтобы чинить это на более низком уровне, то лезть на этот уровень не нужно, нужно пользоваться предписанными интерфейсами. Универсальность при этом растёт с каждым уровнем вниз. Если в социальных танцах можно передавать сигнал ведения-следования от плеча к руке, то на уровне работы мышц уже можно обсуждать не только передачу сигналов, но и самые разные другие сервисы. Если вы обсуждаете самый нижний уровень связных протоколов, то поверх них можно строить самые разные варианты реализации других протоколов. Например, в связном стеке для более-менее универсального протокола IP можно предложить более высокий уровень протокола TCP, но можно использовать и другие протоколы, которые будут реализованы другими конструктивами — UDP и ICMP. Это всё изображено на диаграмме платформенного стека IoT для TCP/IP Protocol Stack. Видно, что стек назван по паре протоколов где-то из середины стека, даже не верхний уровень стека и не все протоколы из того же уровня, что TCP, на иллюстрации приведены всего три протокола уровня TCP, но их там 145 разных²².

Есть два способа изображения таких диаграмм платформенных/инструментальных/модульных/конструктивных стеков:

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

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

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

Верхняя скобка для стандарта интерфейса в надсистему от custom code ведёт как бы в никуда при таком способе показа, поэтому чаще используется способ предыдущей картинки, где платформа обозначается не по назначениям/именам её модулей/слоёв, а назначение указывается сбоку.

Часто оба этих способа перемешивают, получая гибридную конструктивную диаграмму конструктивных/инструментальных уровней для видимости интерфейсов, она разрабатывается архитекторами. Вот, например, диаграмма уровней компилятора искусственных нейронных сетей, где верхние строки — наименования программных пакетов/библиотек для сервисов над нейронными сетями (MXNet, PyTorch, …), а нижние — интерфейсных стандартов для какой-то аппаратуры (OpenCL, CUDA, …)²⁴:

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

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

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

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

Это налаживание взаимодействия в условиях отсутствия стандартов и когда системы уже созданы, называют «федерирование», см. стандарт ISO 11354-1:2011, framework for enterprise interoperability²⁵. Как мы обсуждали в предыдущих подразделах, этот стандарт определяет три подхода к налаживанию взаимодействия/interoperability: федерированный/federated, унифицирующий/unified, интеграционный/integrated. Если разработчики взаимодействующих модулей используют при их создании стандарт взаимодействия/интерфейса, то это «унификация», а если они тщательно совместно разрабатывают оба модуля, проектируя их взаимодействие (что является более исключением, чем типовой ситуацией), то это «интеграция». При федерировании разработчики не соблюдают стандарты и не знают друг о друге, и это самый частый случай. И самый дорогой в реализации. Унификация — это ориентация на стандарты, поэтому вместо федерирования предпочитают унификацию, это обычно дешевле.

Интеграция — это очень редкий случай, и дорогой: вам нужно совместно разрабатывать устройства и согласовывать интерфейс прямо при разработке, это довольно редкий случай. Скажем, электростанцию и электролампочку пришлось бы разрабатывать вместе, договариваясь о напряжении на выходе электростанции и входе электролампочки в рамках общего проекта. При взаимодействии через унификацию этого нет: вы просто соблюдаете стандарт интерфейса, лампочка и электростанция сопрягаются в России на 220 или 230 вольт²⁶ и не требуют совместной разработки, хотя в других странах сопряжение идёт на других значениях: 240 вольт, 110 вольт, и в тех сетях сопряжение тоже идёт через унификацию. Но если у вас лампочка на 220 вольт, а напряжение в городской сети 110 вольт, то вам нужно федерирование (например, нужно поставить повышающий трансформатор: адаптер для сетевого интерфейса).

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

Деньги обычно приходят от удачного и массового использования верхнего, самого прикладного уровня (конечно, для каждого уровня инструментального стека вышестоящий уровень является «прикладным», системное мышление применяется рекурсивно — то есть одинаково для каждого системного уровня, одинаково для каждой в нём системы). Посмотрите примеры явного использования рассуждений о платформе в стратегии фирмы NVIDIA — при описании структуры интеллект-стека²⁷, инструментального стека робо-такси²⁸, стека вычислительной инфраструктуры²⁹ и обратите внимание на тип диаграмм, который там использован.

«Перетряхивание» всего инструментального/платформенного стека, перестройка всех рынков идёт обычно тогда, когда меняется принцип физической реализации самого нижнего уровня конструктивов, то есть меняется реализация платформы самого нижнего уровня.

Например, когда в компьютерах поменялись механические или пневматические элементы на вакуумные электронные лампы, компьютеры стали масштабируемы и они начали напоминать уже функционально современные компьютеры, а не калькуляторы прошлых лет. Замена ламп на дискретную полупроводниковую технику позволила наладить массовый выпуск компьютеров и это разительно изменило компьютерную технику. Замена дискретной электроники на большие полупроводниковые интегральные схемы опять перевернула весь компьютерный рынок со всеми надстройками программного обеспечения. Замена CPU на GPU перевернула рынок искусственного интеллекта. Замена людей-исполнителей на роботов-исполнителей переворачивает все производство. Эта особенность делает конструктивные/инструментальные/платформенные/модульные/продуктовые/аппаратные/софтверные стеки удобными для обсуждения стратегии компании.

При стратегировании обсуждают метод работы компании и предметы этого метода, в том числе какие из конструктивов на этих платформенных уровнях будет компания делать сама, а что закупать вовне, какие стандарты интерфейсов для этих конструктивов она будет устанавливать сама, а какие брать из уже готовых стандартов. Хороший пример такого стратегирования на системных уровнях инструментального стека для искусственного интеллекта даёт компания NVIDIA³⁰.

Моделирование: уровни платформенного стека

Приведите уровни платформенного стека системы в вашем рабочем проекте (не меньше трёх уровней).

Прикладная функциональность против универсальной конструкции

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

Но этот метод разработки, предусматривающий обязательное рисование функциональных диаграмм, существует отнюдь не для всех видов систем. Так, в программной инженерии функциональные/потоковые диаграммы в большинстве проектов рисовать не принято, равно как не принято делать подобные текстовые описания на формальном языке моделирования, или даже на псевдокоде.

Например, программисты думают о функциональности своих программ, но принципиальных/концептуальных схем их работы программисты почему-то не делают, они держат обрывки этих принципиальных схем исключительно в уме — и поэтому в этих схемах нельзя найти пробелы, ошибки, поговорить о функционировании их систем с коллегами. Это не значит, что функциональных/потоковых нотаций не существует, например, data flow diargam³² и даже архитектуры потоков данных (dataflow)³³, лежащие в основе ставшего популярным так называемого «реактивного программирования» ³⁴/«обработки потоков»³⁵.

В исходном коде программ, тем не менее, эти «принципиальные схемы» с их потоками не видны: парадигма программирования чаще всего не предполагает выделенного показа функциональности частей программы, плюс эта функциональность существенно зашумлена деталями описания, достаточными для исполнения кода. В передовых кругах разработчиков софта это не так, и функциональные описания (чаще всего получаемые в рамках практики domain driven design, DDD³⁶) документируются, но пока это ещё не общепринятая культура/практика, скорее приятное и редкое исключение из общей практики.

Этот взгляд на систему как некоторые потоки от входов к выходам — он оказывается важным и для предприятия как системы. Так, операционный менеджмент — это как раз функциональный (иногда говорят — логистический, «транспортный») взгляд на предприятие как потоки работ (workflow), потоки комплектующих и предметов поставки (ERP, enterprise resource planning работает именно с планированием этих потоков, если нет планирования потоков — то это не ERP в оригинальном его значении).

Неработа с функциональностью — типичная ошибка объединившихся в проекте инженеров и менеджеров. «Техпредприниматели» или корпоративные менеджеры беседуют с внешними проектными ролями/stakeholders и выясняют обычно их потребности, а вот концепцией использования, то есть основными сценариями использования целевой системы не занимается вообще никто — инженеры сразу переходят к концепции системы, которая ещё непонятно что должна делать (непонятна её функция в надсистеме). В том числе в сценарии использования входят, заметим, не только happy path, то есть поведение системы, когда всё идёт хорошо и нет неожиданностей.

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

Для этого инженер соединяет через типовые интерфейсы из самых ходовых и простых стандартов типовые конструктивные элементы в надежде, что через восемь итераций всё как-то само-собой с функциональностью утрясётся (будет ведь обратная связь от недовольных клиентов!), и проект в конечном итоге получится успешным. Но это неэлегантно, не lean: добавляется лишняя функциональность, система за счёт этого становится обычно дороже, изготавливается дольше, но нужной функциональности может в первых итерациях и не оказаться, первые итерации потребуют переделок/re-work, они не будут представлять MVP.

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

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

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

Вот почувствуйте разницу:

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

• производитель определяет сервис молотка как «удары», а клиенту нужна функция «загнать гвоздь в доски», хоть «ударами», хоть «вдавливанием»

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

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

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

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

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

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

У нас стоит задача тонкого химического синтеза диметилфторидметилхлорпентилбензолтитана для задач фармацевтической промышленности. Известно, что его трудно синтезировать, и при синтезе получается много примесей, от которых потом люди умирают. Поэтому мы предложим аптекам такой чистый продукт, от которого люди не будут умирать, а маркетинг будет оригинальный: через уборщиц медицинских учреждений, которые будут подбрасывать наши буклеты врачам, а также задушевно беседовать с пациентами в очередях ко врачам. Для того, чтобы получить чистый диметилфторидметилхлорпентилбензолтитан, мы будем использовать четыре стальных реактора, соединённых трубами диаметром 56мм, последняя труба с тефлоновым покрытием. Второй реактор закажем внешним контракторам. Чистоту получающегося диметилфторидметилхлорпентилбензолтитана будем отслеживать при помощи независимой экспертной службы. Все четыре реактора должны будут пройти проверку на выдерживание давления в 156 атмосфер.

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

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

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

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

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

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

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

Рассмотрение функционирования сначала, а конструкции потом — это важная часть системного мышления: сначала нужно обсудить подробно, зачем эти конструкции и как они будут работать, а уже потом рассматривать, из чего они будут собраны.

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

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

• Проект-1: Обучение изготовлению тела — стажировка по системному фитнесу (1 месяц), создание «тренера::создателя себя»

• Проект-2: Изготовление тела - регулярные/специальные занятия (самостажировка, 12 месяцев), эксплуатация тренера, создание заготовки «тело как универсальный модуль».

• Проект-3: Использование тела — изучение спорта/танца/борьбы (6 месяцев), используется универсальный конструктив, продолжение работы сам-себе-тренера, создаётся прикладной конструктив, выполняющий функции в прикладной предметной области.

• Проект-4: Отдельная задача в выбранном спорте (3 месяца), развитие прикладного конструктива сам-себе-тренером до новой потребной приоритетной функциональности (вплоть до того самого «мах прямой ногой к уху с запасом», хотя тут может и не хватить 3 месяцев, но уж точно это будут не 10 лет, минимум впятеро быстрее).

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

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

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

• Проект-2: Изготовление сам-себе-тренером, полученном в предыдущем проекте, универсального своего мастерства системного мышления, достижение беглости — регулярные/специальные занятия («самостажировка», полгода, но на реальных проектах, а не на учебных упражнениях. Впрочем, учебных упражнений в нашем руководстве нет, всё только на рабочих проектах)

• Проект-3: Использование системного мышления для освоения системного моделирования, методологии, какой-то прикладной инженерии, менеджмента, каких-то других методов прикладной работы (по нескольку месяцев каждый метод). В программе рабочего развития инженеров-менеджеров, например, это освоение прикладной работы по руководствам системной инженерии, инженерии личности, системного менеджмента.

• Проект-4: Отдельная задача инженерии-менеджмента (от нескольких минут до 3 месяцев, «подумать и сгенерировать альтернативы, выбрать лучший метод работы, спланировать ресурсы, перейти к действиям и выполнить план»).

Мыслить только про «универсальные в плане функций конструкции» нельзя, универсальных конструкций не бывает. Отсутствие мышления о прикладной функциональности нужно как-то осознавать и исправлять. А это отсутствие мышления о прикладной функциональности заметно только в случае наличия системного мышления — оно позволяет заметить то, о чём вы забыли подумать.

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

Внимательно посмотрите на свой текущий проект: не пропущены ли в нём функциональные рассмотрения? Если пропущены, то помним: без специалистов предметной области (subject matter expert) надсистемы, а потом и целевой системы, и её подсистем, и вашей системы (если она из систем создания) вам не разобраться. Общайтесь, общайтесь, общайтесь. Системные мыслители много общаются с проектными ролями, отвечающими за самые разные прикладные практики, для этого они имеют универсальное/трансдисциплинарное/фундаментальное системное мышление, но они знают, что его результаты всё равно надо довести до какой-то прикладной системной области.

Вопросы. Наличие описания функциональности

Программист долго рассказывает про его целевую систему как «прозрачный ящик»: она у него состоит из компьютеров, контейнеров с данными и программами, хранилищ для хранения бэкапов, баз данных, средств балансирования нагрузки и многого другого. Чего не хватает в этом описании, чтобы серьёзно отнестись к его рассказу?

--- всё в порядке, все программисты рассказывают именно об этом ### Нет, не всё в порядке: это всё описания времени создания программы, а не времени эксплуатации. Нет ни одного слова из предметной области, с которой работает система программиста!

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

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

Оргзвенья

В системах из людей конструкты — это прежде всего сами люди, с их аудио, зрительным, тактильным и прочими интерфейсами. Функции людей даже не делается попыток обсуждать, равно как смысл и содержание информации или изменений окружающей среды, которые поступают к людям и уходят от них через интерфейсы человеческого тела. Люди — это универсальные создатели. Помним определение универсальных создателей/по David Deutsch, оно по факту расширяет определение универсальных компьютеров по Alan Turing: если им дать достаточные ресурсы и время, они могут выполнить любое допустимое принципами физики преобразование физического мира точно так же, как универсальный компьютер может выполнить при наличии достаточно времени и памяти любое возможное вычисление. В том числе люди могут при недостатке ресурсов реплицироваться, в том числе люди могут сначала создать инструментарий, а уже затем выполнить необходимое преобразование, работая коллективно и используя инструменты.

Это мы проводим про людей конструктивное/продуктовое рассмотрение, т.е. рассмотрение «как сделать», как составить систему из людей, уж какие они есть перед началом работы — ибо про функциональность мы ничего не говорим, считаем, что поскольку люди универсальны как создатели, они могут быть как-то обучены на выполнение нужных функций. По большому счёту, нас волнуют даже не люди, а универсальные агенты — роботы с AI достаточной силы нам тоже подойдут для рассуждений.

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

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

Конструктивы, из которых созданы организации (то есть отдельные агенты или организованные группы агентов с их инструментами) мы будем называть не «подразделение», а более общим словом — оргзвено.

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

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

Дальше эти минимальные оргзвенья/сотрудники/агенты (некоторые из них — люди) из одного агента объединяются на основе известных им полномочий в оргзвенья следующего уровня, и так — пока оргзвено самого высокого уровня не окажется организацией в целом (предприятием или учреждением, или ассоциацией, или фондом и т.д.). Иногда первичное объединение оргзвеньев называют командой, обычно в команде 5-12 агентов, а сейчас часто говорят о команде как «столько людей, сколько можно за обедом накормить двумя большими американскими пиццами» (two pizza team), как тут поступать с командой роботов, людей и роботов — непонятно, скорее всего так и считать, что речь идёт о 5-12 интеллектуальных агентах, иногда команда — это 2-5 агентов (в Tesla говорят про такие маленькие бригады — mob/банда).

Иногда вводят ещё один уровень — коллектив, это «команда команд». Но помним, что когда разные уровни иерархии (тут — иерархия часть-целое для оргзвеньев) называют разными именами — это кажется удобным поначалу, а потом оказывается неудобным по мере нарастания изменений в количестве уровней для тех или иных ветвей этой иерархии. В риторических (для убеждения людей) целях могут и население страны назвать «командой», чтобы подчеркнуть принадлежность к «маленькой организации» и готовность выполнять согласованные планы работы (при этом желание, конечно, отличается от возможностей — всё, что мы знаем про автономных агентов-людей и аналогичных им роботов уже не полностью подходит к организациям, хотя и те, и другие — «лица» и «стороны», берущие на себя ответственность за выполнение каких-то планов. Это и означает «организованность». А вот с сообществами (агентами, занимающимися какими-то методами работы и обменивающимися опытом по практикованию этих методов работы, например, community of practice³⁹) уже не так, и с обществами (агенты, которые компактно проживают на каких-то территориях, но вот общность каких-то методов работы даже не обсуждается) — тем более не так. Так что разговор об оргзвеньях заканчивается на не очень далёких от одной организации системных уровнях — а именно тех уровнях, где можно какой-то явной договорённостью (а не просто силовым принуждением типа «заплатил налоги — и спи спокойно») говорить о выполнении обсуждаемым конструктивом как системой работ по какой-то стратегии, то есть работ по каким-то договорённым методам по изменению состояния предметов этого метода, с учётом разделения труда между членами организации.

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

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

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

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

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

Именование оргзвеньев — это рассмотрение «как сделано, из чего собрано» отражает этот конструктивный, а не функциональный аспект. В именах самые общие представления об оказываемом сервисе, вне связи с назначением/функцией этого сервиса. Цех №5, палата №6 — простые номера в именах, из которых не следует функций, являются типичными указателями на конструктивное рассмотрение. Самые общие слова без указания предметной области (как «база данных» и «сервер» в информационных технологиях) тут такой же признак («инжиниринг», «юридический отдел», научно-технический совет, проектная группа). Примерно так же могут быть в именованиях уточнения аспекта размещения — но всё равно ничего нельзя сказать о функциях: «Вологодский филиал» понятно, что оргзвено, и понятно, что в Вологде. Но чем занимается? Каким методом какие предметы метода он меняет, какие у него сервисы как у системы? Это всё надо узнавать из других аспектных описаний.

Функций, исполняемых конструктивными элементами предприятия/оргзвеньями, может быть множество, и самых неожиданных. С другой стороны, если «подразделение переезжает в другое здание», то это описание связи ипостасей конструктивной и размещения. «Подразделение будет работать новыми методами» — это обсуждение связи функциональной и конструктивной ипостасей подразделения.

Моделирование: назначение оргзвеньев на оргроли, выполняющие практики

Какие функции/сервисы/«методы работы» каких оргролей выполняются какими оргзвеньями вашего предприятия? Заполните табличку по примеру первой строчки, десять практик.

Необходимость хорошей модульности

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

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

Вот графики компьютерной симуляции зависимости падения стоимости разработки от улучшения n отдельных модулей, при d связей каждого из них⁴⁰:

Видно, что если связь одна, то стоимость разработки с каждым улучшением падает быстро по экспоненте, слабо зависящей от числа модулей. Но если связей больше, то ошибки от локальных улучшений распространяются по этим связям и снижение стоимости разработки от улучшений в отдельных модулях идёт плохо. Каждая связь имеет свою системную цену, и не было бы этой цены, мы не имели бы даже в живой природе «органов», «клеток» и других конструктивов/модулей⁴¹.

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

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

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

Есть множество методов, которые помогают уменьшать связность модулей в создаваемой системе. Одним из наиболее известных таких методов является DSM (design/dependency structure matrix)⁴².

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

Хорошая модульность и минимизация связей между ними совсем не означает, что части системы/подсистемы не находятся в тесном взаимодействии друг с другом. Это означает, что эти взаимодействия частей конструкции ставятся под жёсткий архитектурный контроль, и подсистемы можно улучшать, а в случае стандартизации интерфейса даже заменять на принципиально другие по конструкции и принципу действия, не рискуя при этом ухудшить работу всей системы в целом.

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

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

Борьба со сложностью в мышлении

Edsger Dijkstra в 1974 году ввёл⁴³ понятие разделения предметов интереса (separation of concerns, разделение важных характеристик/предметов интереса/озабоченностей) как способ упорядочивания человеческих мыслей о каком-то предмете. Этот принцип гласит, что нужно обсуждать сложные ситуации по одной важной характеристике (concern) за раз, удерживая внимание самых разных ролей на каком-то одном аспекте, одной ипостаси этой ситуации. Это не значит, что игнорируются все остальные. Просто это удерживание во внимании и одного прямо сейчас обсуждаемого аспекта проблемы, и одновременно удержание внимания на объемлющем обсуждении всей проблемы. По словам Edsger Dijkstra про такое мышление, «It is being one- and multiple-track minded simultaneously».

И это разделение мышления по предметам интереса проводится рекурсивно, в понимании системного мышления — это одинаковыми методами мышления на каждом из многочисленных системных уровней. У каждой системы на каждом системном уровне есть много предметов интереса/важных характеристик, и они там обсуждаются по очереди. Ввиду эмерджентности на каждом системном уровне системы, подсистемы и надсистемы проявляют разные наборы свойств, имеют разные характеристики, и нужно обсуждать и эти разные системы, и их разные характеристики. Предметов интереса много для каждой системы на каждом системном уровне, плюс ещё есть предметы интереса к создателям, там уже отношение не часть-целое, а отношение создания — но это ведь тоже системный подход, начиная со второго его поколения.

Сложность описания/обсуждения системы тем самым уменьшается за счёт разделения одного запутанного сверхсложного обсуждения на отдельные не очень запутанные и не очень сложные обсуждения по двум направлениям:

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

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

• Отдельно обсуждаем создателей в их графе, то есть проходим уже не по отношению часть-целое, а по отношению создания. Системное мышление заставляет удерживать во внимании и создателей!

Детальное и в подробностях обсуждение огромных сложных систем и графов их создателей принципиально (в силу самой сути системного подхода) может быть разбито на достаточно маленькие части, и ни одна часть этого обсуждения не будет забыта, ни одно описание не будет пропущено. Как съесть слона? По кусочку за раз!

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

Но как договориться о том, как склеивать все эти самые разные описания самых разных частей системы в одно целое системное описание? Как договориться всем этим ролям и их исполнителям? Все эти описания можно совместить, если понимать, что они описывают одно и то же место в пространстве-времени, относятся к одному и тому же воплощению системы. В центре любых системных обсуждений будет физическое воплощение системы, рассматриваемое в момент эксплуатации (run-time), к нему будут привязаны все остальные рассуждения.

Без системного подхода сложные проекты с задействованием большого количества разных специалистов выполнить в срок и вовремя невозможно: система будет неуспешна, ибо чьи-то интересы не будут соблюдены (то есть забыты, потеряны: на них не хватит внимания команды!), и в системе тем самым будет ошибка, люди не будут довольны её работой, или не будут довольны работой проекта, который создаёт систему (не будут довольны системами создания). Банально: если вы забыли обсудить какую-то систему, подсистему, надсистему «нашей» системы, или целевой системы, или даже создателя — быть беде, «если что-то может пойти не так, оно пойдёт не так». Неизбежны коллизии, что-то придётся переделывать/re-work, тратить незапланированные ресурсы.

Системы обсуждаются по одной части за раз, одному описанию части за раз — ни на секунду не теряя из вида целой системы в её окружении, а также её создателей.

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

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

В случае инженерии предприятия все системные рассмотрения остаются, но меняется терминология и практики. Так, модулями предприятия называются подразделения (тут реже говорят про оргзвенья, но системное мышление обращает внимание и на коллегиальные органы типа рабочих групп, советов и комиссий), функциональными частями предприятия являются его оргроли, функции/методы работы оргролей часто называют рабочими процессами, а управление конфигурацией предприятия называется учётом. А ещё важно, что оргзвенья не разрабатывают, а организуют, при этом само изготовление — это не производство, а лидерство (людям, которые вменяемы, объясняют, как устроено их оргзвено, и какое оргместо они там должны занять, сотрудничая с другими людьми — это и есть лидерство). Подробней — в руководстве по системному менеджменту.

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

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

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

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

• На основе выбранного метода спланировать ваши действия, привязать к конкретному времени и ресурсам.

• Принять планы всерьёз: выделить (или даже добыть, если поначалу их нет) ресурсы и выполнить эти планы, даже если речь идёт о пошаговом планировании.

• И дальше продолжать системно мыслить, то есть продумывать то важное, на что указывает системное мышление, надёжно удерживать это важное в коллективном внимании участников проекта, не давать вниманию рассеиваться.

Задания: системное моделирование

Поставьте отметку о выполнении:

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