Можно тут обсуждать и цифровых двойников, но основная их роль – это «автоматизированное управление», замена оператора по настройке-подстройке параметров уже работающей целевой системы автоматом или составной конструкцией из человека (который крутит какие-нибудь ручки или меняет ненадёжные элементы конструкции в физическом мире) и информационной управляющей системы (которая говорит, куда какие ручки покрутить, что из элементов конструкции стало настолько ненадёжным, что хорошо бы заменить – софт занят «предиктивной аналитикой», например, для «ремонта по состоянию»). Цифровой двойник работает во время использования, а не во время создания.
Между системами в окружении (целевой, надсистемой, системами в составе надсистемы из ближнего окружения и т. д. – если встретилось слово окружение/среда/environment, надо всегда помнить, что это «операционное окружение»/«operations environment», то есть рассмотрение времени работы) и их создателями тоже отношение создания (development, design, construction, implementation, enabling), когда один создатель::система описывает и/или меняет другую систему. И таких систем можно рассмотреть целую цепочку по отношению создания, а если поглядеть на все такие цепочки, то это будет граф создания: узлы – это системы (целевая и создатели) а рёбра – отношения создания. Внутри одного времени – отношения часть-целое/композиции, через границы времён/realms – отношения создания (X::система создаёт/«изменяет состояние» Y::система).
На диаграмме показан вариант такого графа создания. Для каждого создателя тоже было его создание, и его эксплуатация/использование/работа/operations. Поэтому на диаграмме представлено несколько разных «времён» рассмотрения (realms), и что для создателя будет его ops-time, для целевой системы будет dev-time. А что для создателя его dev-time, то для создателя создателя – ops-time.
Разных создателей может быть много, и сами цепочки могут быть длинными. Можно двигаться по цепочкам создания довольно далеко от целевой системы, ибо каждого создателя тоже надо кому-то создать, и при системном моделировании мы в каждом проекте просто останавливаемся на той длине цепочки создания, которая позволяет более-менее уверенно оценивать успешность целевой системы.
Топ-менеджеры в своих проектах регулярно работают с цепочками создания на шесть-семь звеньев – и когда берут какие-нибудь примеры на три или даже четыре звена, удивляются, что модель плохо соответствует жизни. Скажем, вы рассматриваете продавцов, но не учитываете, что реально вы в ситуации какой-нибудь дилерской сети и ещё с «агентами у клиента», а не прямых продаж – и вы их всех зовёте «продавцами». Всё, вы потеряли одно звено цепочки создания, модель будет плохой.
На диаграмме показан сереньким «создатель создателя создателя целевой системы», чтобы не забыть про наличие именно длинных цепочек создания, а не одного отношения создания между двумя системами. Стрелки направлены в среднем слева направо, это обычное умолчание для показа времени с прошлым слева и будущим справа: сначала как-то появляется создатель, и только потом – создаваемая им система. Вместе же все цепочки создания – граф создания, обычно направленный/directed ациклический граф57.
Отношения создания – это не отношения часть-целое! Enabling/construction это не composition/part_of! Кастрюля, в которой варится борщ – это не кастрюля в составе борща, или борщ в составе кастрюли! Это кастрюля для создания борща!
