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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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