Системное мышление 2019 Левенчук Анатолий

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

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

Три главных таких частных описания – это уже знакомое нам описание подсистем как функциональных объектов, как конструктивных/физических объектов, и как мест в пространстве.

Вот модификация диаграммы из стандарта IEC 81346—1, это иллюстрирующая:

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

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

Минимально в системном подходе нужно увидеть в системе три вида частей:

• Компоненты116 (components), или функциональные элементы, которые позволяют отвечать на вопрос о том, как взаимодействуют части системы, чтобы она выполняла свою функцию («как работает система»). На картинке нарисована принципиальная схема, на которой приведено описание компонент и их соединений (connectors). Компоненты выполняют свою функцию в системе через соединения с другими компонентами, меняя своё состояние от этого взаимодействия и меняя состояния других компонент. Если мы хотим понять, как идёт спектакль, в котором вот этот вот человек говорит своё «To-be-or-not-to-be», нам нужно понять играемую им роль в этом спектакле. Нам понятно, что в спектакле он Принц Гамлет (а не Василий Пупкин, который его играет, Василия при случае ведь и заменить можно на John Doe для пущей убедительности).

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

• Места (locations), или размещения (allocations), которые позволяют отвечать на вопрос, где можно найти части системы, как она скомпонована в пространстве. На картинке изображены отсеки, в которых ведётся монтаж системы и в которых она затем работает, но непонятно из чего система собрана и как она работает. Всё это ролевые части целой системы, изображённой кубиком с цветными гранями – и каждый стейкхолдер в силу специфики своих интересов видит частное определение системы как «прозрачного ящика», состоящее из интересующих его типов элементов, отвечающих на его интерес. Это «не единое» восприятие целостной системы нормально, так и должно быть! Единым в описаниях у разных стейкхолдеров может быть только единонемыслие (Салтыков-Щедрин). Реальное же единство обеспечивает 4D-экстенсионализм: воплощение системы занимает то же место в пространстве-времени, что и компоненты, модули, размещения. Это и даёт единство: это всё разные способы выделения частей одной и той же системы, разные способы организации внимания, выделения главного и отбрасывания второстепенного для стейкхолдеров. Все стейкхолдеры по-разному думают о системе, представляют её по-разному, а единство обеспечивается тем, что в реальном мире воплощение системы одно и то же – и это даёт возможность и даже требует от стейкхолдеров договорённостей по поводу системы.

У немецких инженеров-электротехников был подсмотрен приём: чтобы сразу было видно, о каком виде элемента говорится, части системы именуют с использованием специальных префиксов: компонентный префикс “=», модульный префикс “-», префикс размещения “+». А имена даются по соответствующей холархии. Так =S12=16 означает, что речь идёт о компоненте 16, входящей в состав (отношение composition, part_of) компоненты S12. Проектирование, конечно, ведётся в классах: это имя класса компонент, а не конкретной компоненты конкретной физической системы. Число уровней в таком имени неограничено. Такое имя компоненты часто называют тегом (tag).

Если имя —M87-K5, то речь идёт о модуле К5, который входит в состав модуля М87. Это тоже не конкретный физический объект с серийным номером, а класс этих объектов, продукт определённой модели.

Стандарт IEC 81346 закрепил такое именование, причём он определяет ещё и как давать коды вместо «нормальных» длинных имён. Действительно, если в каком-нибудь Boeing 787 есть 6 миллионов индивидуальных деталей, то это сразу означает, что у них даже больше имён – и лучше бы держать эти имена короткими, и каждое имя чтобы было понятно, к какой части самолёта относится.

Мы уже знакомились с ситуацией, когда Принц Гамлет и Василий Пупкин могут быть одним человеком, но называться по-разному в зависимости от того, что нам от него нужно – понять, какая фраза будет следующая в его пьесе, когда он планирует выучить новую роль в новом спектакле, или выяснить, есть ли у него дети. То же можно сказать и о системе: «измеритель давления», «манометр KLM-23 завода «Давижмимонтажавтоматика»» и «датчик в пятом ящике на третьей полке склада номер 4» вполне могут оказаться одним и тем же прибором – но разные имена свидетельствуют о том, что мы планируем совершенно разные действия с этим прибором, поэтому для нас один и тот же прибор выступает в разных ипостасях и имеет поэтому разные имена. Имя «Принц Гамлет – Василий Пупкин» вполне осмысленно, хотя на ней приведено сразу два имени отдельных ипостасей актёра: действующего лица и исполнителя роли. Так и имена систем в промышленности часто могут состоять из имён нескольких ипостасей, например, «=S12=16 —M87-K5». Обычно это относится к конкретному проекту, так же, как «Принц Гамлет – Василий Пупкин» относится к одному спектаклю, в другом спектакле распределение ролей будет другое. В силу 4D экстенсионализма все эти имена говорят о каком-то месте в пространстве, так что всегда можно разобраться.

Многерица: единонемыслие единого

Суть системного подхода в том, чтобы ни в один момент времени не забывать про систему в целом – воплощение системы, которое просто по-разному представляется состоящим из разных частей разными стейкхолдерами. Это очень трудно.

В христианстве есть довольно сложно осваиваемое в мышлении понятие троицы: бог представляется одновременно и единым, и существующим в трёх ипостасях (отца, сына и святого духа).

Проблема в том, что думать о боге нужно одновременно и о как едином, и как об отдельных ипостасях – такому мышлению несколько лет обучают в семинариях. Сама идея-то понимается очень легко, но не так легко эта идея осваивается в практике мышления, метанойя происходит медленно:

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

Беглости подобного мышления «единого-ипостасного» тоже довольно долго учат, хотя идея понимается с первого предъявления.

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

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

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

• ISO 15926 – две основных: функциональные объекты, физические объекты. Остальные могут вводиться по потребности.

• IEC 81346 – «по меньшей мере» три (функция, продукт, место)

• Книга Paul Clements at al., Documenting Software Architectures: Views and Beyond (2nd edition), Addison-Wesley Professional, 2010117 – три стиля (компоненты, модули, размещения, и разные варианты внутри каждого стиля). Авторы этой книги тесно связаны с разработчиками ISO 42010, поэтому мы ориентируемся в нашем учебнике именно на эти названия – «компоненты, модули, места/размещения».

• Книга Косяков, Свит, Сеймур: «Системная инженерия. Принципы и практика»118 – функциональный элемент, компонента (в значении «модуль» из предыдущей книги: ровно обратное использование термина!), размещение.

• СМД-методология – «по меньшей мере» пять (процессы, элементы и связи, внешние функции, морфология, материал)119

• … и так далее, в среднем 3—7 основных ипостасей (впрочем, «ипостаси» тоже называются везде по-разному) в разных школах системного мышления.

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

Для разных стейкхолдеров система будет представляться в своих аспектах-ипостасях мышления отдельных дисциплин совершенно по-разному – но при этом в системном мышлении она будет оставаться целостной/холистичной/целокупностью всех своих ипостасей/аспектов.

Многерица холархий

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

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

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

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

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

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

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

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

Заказать можно только модули, а ручка и ножевой блок у ножниц компоненты, а не модули. Модулями в ножницах будут только две половинки ножниц (а ещё винтик).

Если делать ручки и ножевой блок отдельно как модули, а потом их как-то скреплять, то это будет плохое и ненадёжное инженерное решение.

Менеджеры же сначала внимают доводам инженеров, но потом… смотрят на ножницы в сборе, видят в действии (эксплуатации, operations) ручку и ножевой блок – и опять пытаются с ними сделать что-то по отдельности не в момент «спектакля» (когда ножницы в сборе и работают – режут), а в момент изготовления. Например, разделить работы по сборке ручки и ножевого блока, хотя при соединении половинок ножниц винтиком разделить работы по ручке и ножевому блоку принципиально невозможно. Или сделать каталог ручек и каталог ножевых блоков и потом пытаться заставить инженеров выпускать эти якобы «детали ножниц» в виде запчастей. Список ошибок и заблуждений тут бесконечен, и эти ошибки не прекратятся: менеджеры постоянно находят «ножевой блок» и «ручки» в инженерной документации и пытаются поступать с ними как со сборочными единицами.

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

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

В инженерных языках моделирования «железной» архитектуры, равно как и в языках моделирования предприятия, компоненты и модули имеют различные значки.

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

Главное при этом – это решения создателей системы, какие элементы конструкции реализуют какие необходимые для работы системы поведения/функции, так что требуются обычно описывать и компоненты, и модули.

Компонентный анализ и модульный синтез

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

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

На рисунке из стандарта IEC 81346—1 (а этот стандарт взял этот рисунок из более раннего стандарта IEC 1392/09) «объект с функциональным аспектом» это компонента, «объект с продуктным аспектом» это модуль, а «объект как с продуктным, так и функциональным аспектом» – это модуль, сервис которого выполняет функцию компоненты.

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

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

Альфы и рабочие продукты

Стандарт OMG Essence120 предлагает предлагает особый вид компонент – альфа (ALPHA). Альфа – это функциональный объект, контроль за изменением состояния которого позволяет оценивать степень продвижения проекта в работе с этой альфой. Мышление о том, «как проект работает» посвящено альфам, ролевым объектам, они имеют функцию/назначение, вменённые им в проекте человеком.

Этот же стандарт OMG Essence для модулей, физической реализации альф предлагает имя рабочий продукт (work product, иногда используемый синоним – «артефакт», artifact, т.е. предмет искусственного происхождения) – это конструктивный объект: то, над чем работаем, из чего проект «собран», что можно обнаружить в окружающем мире.

Альфа отличается от ранее встречавшихся нам 4D-функциональных объектов тем, что она бывает и абстрактным объектом – каким-то определением системы: требованиями, архитектурой, неархитектурной частью проекта/design. В проекте приходится следить как за функциональной частью разных описаний системы (определениями), так и за функциональной частью воплощения системы (компонентами).

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

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

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

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

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

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

В реальном мире мы видим артефакты «яблоки» и определённые дела с этими артефактами, например, «съесть яблоки», «сосчитать яблоки». Альфы представляют собой те объекты, которые описываются дисциплиной (теорией) – «количество предметов» и «сосчитать предметы», если вернуться к примеру со счётом яблок. Альфа тут – «предмет», а не «яблоко»! Тут нужно привести байку про яблоки из задачи и из жизни, например, в таком варианте121:

Пришла в… школу учительница, которая начиталась работ о дидактической функции наглядных пособий и считала, что надо учить на наглядных пособиях. А проходили они в этот момент задачку на сложение: «3+5». И она принесла три яблока и ещё пять яблок, выложила их на стол и говорит: «Дети, вот вы видите здесь – раз—два—три – три яблока, а здесь вот – раз—два—три—четыре—пять – пять яблок. Вот я их соединяю, сколько получится всего яблок?» Дети пялятся на яблоки, слюни у них текут, но задачи не понимают. Второй день проходит, третий – рекорд: в таком классе обычно за день это проходили. Она приходит в учительскую, жалуется, что вот—де она применяет новые методы, наглядно все, а результата нет. И вот на пятый день с задней парты тянется рука, и ученик говорит: «Мэм, я теперь понял: эти яблоки, которые вы выложили на стол, не настоящие – это яблоки из задачи». – «Да, а что?» – «Ну тогда, мэм, совсем другое дело». И с этого момента, когда класс понял, что это не настоящие яблоки, а яблоки из задачи, все моментально пошло. Почему? Когда вы кладёте реальные яблоки – что с ними надо делать? Их надо есть. А чтобы считать, нужны рисуночки.

Вот ещё про то же самое122:

– Мы займёмся арифметикой… У вас в кармане два яблока…

Буратино хитро подмигнул:

– Врёте, ни одного…

– Я говорю, – терпеливо повторила девочка, – предположим, что у вас в кармане два яблока. Некто взял у вас одно яблоко. Сколько у вас осталось яблок?

– Два.

– Подумайте хорошенько.

Буратиносморщился, – так здорово подумал.

– Два…

– Почему?

– Я же не отдам Некту яблоко, хоть он дерись!

– У вас нет никаких способностей к математике, – с огорчением сказала девочка.

Про физическое тело мы знаем, что при наличии силы тяжести они летят по параболе. Ускорения и масса тоже у физических тел. Если кинуть камень и не суметь соотнести его с физическим телом, то нельзя сказать, что он полетит по параболе! Нет таких учебников, в которых описываются полёты именно камней! Ричард Фейнман в своих заметках по преподаванию физики ровно об этом сожалел: по всему миру ученики физики не могут сопоставить отличные знания из учебника явлениям окружающего мира123.

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

Обычно занимающиеся по нашей книге проходят следующие стадии при изучении системного мышления:

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

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

• Всё понимают и про свои проекты, и про проекты коллег. Но ничего из понимаемого не делают, ибо системное мышление изучается не для того, чтобы его применять, а «для самообразования и развития», «для сдачи зачёта» и т. д. Применять знания мешают начальники, текучка, лень, отсутствие единомышленников, помогать применять знания некому.

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

Альфы

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

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

Альфы (alphas) – это функциональные (выполняющие определённую функцию, играющие определённую роль, идеальные) объекты, по которым мы судим о продвижении (progress, «как много мы уже сделали?») и здоровье (health, «в проекте всё идёт хорошо») проекта.

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

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

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

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

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

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

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

Формально (то есть в стандарте OMG Essence124) ALPHA – это аббревиатура, Abstract-Level Progress Health Attribute, но неформально это просто способ указать на функциональный элемент/компоненту проекта. Аббревиатура про health attribute была для альфы подобрана задним числом, а слово alpha пишут поэтому маленькими буквами.

Альфы – это то, что изменяется в ходе проекта, меняя свои состояния. Альфы – это то, изменения чего в проекте мы хотим понимать, отслеживать, обеспечивать, направлять, контролировать.

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

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

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

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

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

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

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

Описание системы

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

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

Стандарт ISO 42010 даёт рекомендации о том, как думать о (полном) описании системы. Сам стандарт говорит только об архитектурном описании, но его положения вполне применимы к любым описаниям. Вот задающее мышление об описаниях системы диаграмма из этого стандарта, модифицированная с использованием положений OMG Essence (Рис. 3).

Диаграмма начинается с уже знакомого нам различения воплощения (realization) и определения (definition) системы.

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

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

Вот схема на английском языке:

(Полное) описание системы (system description) состоит из частных описаний системы (view) – рабочих продуктов, которые отражают частные определения системы (на диаграмме не показаны).

Частные определения системы – это как раз требования, архитектура, неархитектурные части дизайна, данные об эксплуатации: всё что угодно, что определяет интересные для стейкхолдера ипостаси/аспекты системы. Определения системы – функциональные объекты, описания системы – рабочие продукты.

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

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

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

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

Более того, полное описание системы встречается в жизни довольно редко, много чаще встречаются частные описания системы. Поэтому view обычно переводится как «описание» – и при этом подразумевается его частичность, отражаемая на диаграмме стрелочкой с ромбиком на конце полного описания.

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

Модели и виды моделей

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

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

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

Проще всего считать, что метод описания – это набор условных обозначений для многослойных карт-моделей, которые описывают территорию. Одно из следствий рассматриваемой схемы: нельзя делать описания, если в явном виде не рассматривается метод описания. Нельзя делать карты, если неизвестна легенда карты и методы картографирования. Эти карты потом нельзя сопоставлять друг с другом. Нельзя делать карту, используя слои, подготовленные согласно разным методам картографирования – нельзя брать подготовленную геодезистами карту водных ресурсов города и подготовленную службами метрополитена карту-схему станций метро и просто накладывать их друг на друга. Нельзя брать баланс по РСБУ, а отчёт о прибылях и убытках делать в МСФО. Все модели (models) из описания (view) должны быть подготовлены с использованием видов моделей (model kinds) из одного метода описания (viewpoint).

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

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

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

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

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

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

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

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

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

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

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

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

Да, человек состоит из атомов, это правда – но это неправильный системный уровень для объяснения того, чем человек отличается от роботов и кошек. Если захочется отремонтировать экскаватор, то моделирование экскаватора из атомов для обеспечения этих ремонтных работ будет крайне неверным решением. Модели должны быть удобны для деятельности, а не абстрактно «научно правильными». И их должно быть много, ибо с системами связано множество разных деятельностей.

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

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

Частные описания системы (views) состоят из моделей, определяемых методами описания (viewpoints), в свою очередь состоящих из мета-моделей, задающих виды моделей (model kinds).

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

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

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

Если вы даёте кому-то описание системы, то вы обязаны также сообщить, как вы получили это описание.

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

Компонентные описания: принципиальные схемы

У очень и очень многих стейкхолдеров в проекте есть интерес к тому, как система работает в ходе её эксплуатации.

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

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

Вот несколько типичных примеров принципиальных схем:

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

Компоненты физичны, они выбраны так, чтобы удобно было объяснять работу системы в ходе её эксплуатации/функционирования (run time, operations). Соединения – это логические/ролевые/функциональные связи, но в 4D всегда можно найти физический объект, которые своей темпоральной частью реализует эту связь, через которую компоненты взаимно влияют друг на друга.

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

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

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

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

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

Модульные описания

Когда интерес стейкхолдера относится не ко времени работы системы, а ко времени построения системы – модульного синтеза, закупки модулей, сборки системы из модулей, то он обращается к модульным описаниям.

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

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

А как же соединения, которые нужны для работы – все эти трубы, кабели, волноводы? Это тоже модули, и у них есть свои интерфейсы: они находятся между ними и теми модулями, которые они соединяют. Что проходит через эти интерфейсы и как оно связано с работой всей системы?! Неизвестно, ибо речь идёт о конструктивных единицах: функции тут не определить, для этого нужно выходить за пределы модульного описания. Единственное, что важно, это наличие соединения: монтажник должен убедиться, что соединение установлено, модуль сможет выполнять свой сервис.

Для интерфейсов известны правила, по которым устанавливается соединение через интерфейс, но неизвестно, что именно и зачем передаётся через этот интерфейс – это будет известным только из принципиальной схемы.

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

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

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

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

Платформы и технологические стеки

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

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

Основной вопрос при обсуждении платформ – это так называемая видимость интерфейсов. Интерфейсы какого-то низкого системного уровня не должны быть видны снаружи модуля, то есть невозможно соединение модулей иначе, чем через предусмотренные в нём интерфейсы. Грубо говоря, если у вас коробочка с каким-то разъёмом, то нельзя воткнуть внешнее устройство не в этот разъём, а куда-нибудь внутрь коробочки, мимо этого разъёма. Для обсуждения видимости интерфейсов используется диаграмма модульных уровней, диаграмма холархии системных уровней. Каждый уровень отделён от другого уровня каким-то интерфейсом. Реализации нижестоящих уровней тем самым могут быть сменены так, что использующая система этого не заметит. А итоговую холархию называют платформенным стеком или технологическим стеком (stack, стопка – диаграммы похожи на стопку подносов в столовой или стопку листов бумаги в пачке). Вот пример различных технологических стеков для организации связи126:

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

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

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

Часто оба этих способа перемешивают, получая гибридную диаграмму. Вот, например, модульная диаграмма компилятора искусственных нейронных сетей, где верхние строки – наименования программных модулей-пакетов реализации нейронных сетей (например, пакет MXNet), а нижние – интерфейсных стандартов для какой-то аппаратуры (например, стандарт OpenCL)128:

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

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

Важность функциональных рассмотрений целевой системы

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

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

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

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

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

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

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