Если нам потребуется отмоделировать холм около другой деревни, то у нас будет другая мульти-модель, при сохранении всех тех же мета-моделей. Рассматривать же и обсуждать в целом можно будет только мега-модель: без обсуждения видов карт, соглашения об условных обозначениях на этих картах и прочего, относящегося к мета-моделированию, обсуждать карты нельзя.
При обучении моделированию учат не модели (модель будет другая для каждой новой системы!), учат мета-модели, учат методы моделирования – они будут одни и те же для разных систем, они будут помогать учитывать интересы одних и тех же стейкхолдеров (ролей, а играть их будут разные люди в разных проектах – знание мета-моделей помогает переносить опыт из проекта в проект).
Если вы даёте кому-то описание системы, то вы обязаны также сообщить, как вы получили это описание.
Вы должны понимать, что это описание – результат моделирования, то есть оно должно содержать только важные для того стейкхолдера, которому вы даёте это описания факты, и не должно содержать ничего другого, что будет для этого стейкхолдера информационным шумом.Если вы не можете сказать, каким методом вы описали систему, если вы не знаете, оформляет ли этот метод интерес стейкхолдера, вы делаете ошибку.
Компонентные описания: принципиальные схемы
У очень и очень многих стейкхолдеров в проекте есть интерес к тому, как система работает в ходе её эксплуатации.
Объяснить, как система работает, можно только тогда, когда мы объясняем назначение (функцию) каждой части системы и вклад этой части в достижение общего назначения системы, общего поведения системы в её операционном окружении.
Принципиальные схемы – это диаграммы, показывающие соединения компонент друг с другом и удобные для объяснения принципа функционирования системы (отвечающие на вопрос «как работает система» – как взаимодействуют между собой функциональные элементы, чтобы дать требуемую вовне функциональность системы в целом).
Вот несколько типичных примеров принципиальных схем:
В ходе работы системы компоненты взаимодействуют друг другом по соединениям (connectors), которые проходят через порты (ports) компонент. В компонентных диаграммах (принципиальных схемах) компоненты обычно изображаются графическими элементами разной формы, а соединения – линиями между этими графическими элементами. Порт – это место присоединения соединительной линии к графическому элементу компоненты.
Компоненты физичны, они выбраны так, чтобы удобно было объяснять работу системы в ходе её эксплуатации/функционирования (run time, operations). Соединения – это логические/ролевые/функциональные связи, но в 4D всегда можно найти физический объект, которые своей темпоральной частью реализует эту связь, через которую компоненты взаимно влияют друг на друга.
Так, в электрической схеме совершенно необязательно иметь ровно такое же количество проводов, которое изображено на этой схеме. Но между реализующими компоненты модулями ток всё-таки должен иметь возможность течь, чтобы система работала. Но этот ток может течь по шасси, по ножкам элементов, спаянных друг с другом – проводов нет, но «провод» лишь один из вариантов реализации связи. Точно так же «труба» на гидравлической схеме будет только одним из способов реализации связи – модули могут быть соединены друг с другом непосредственно, фланец во фланец, без трубы, или вместо трубы жидкость может идти по какому-нибудь жёлобу, вариантов тут не счесть. Главное, что на схеме изображается то, что компоненты соединены друг с другом и можно отследить их взаимодействие.
Режимы работы какой-то системы обычно рассчитываются именно по компонентным, функциональным описаниям, они ведь привязаны ко времени работы системы, а не ко времени её создания. Мультифизическое моделирование делается именно для компонентных описаний: ищутся оптимальные характеристики компонентов для заданных режимов работы.