Что такое модель и для чего она нужна? Зачем нужна среда моделирования и что она может? Как автоматизировать работу над сложным проектом, чтобы всё было на одной волне? Все подробности в статье.
В первой части серии мы познакомились с процессом Systems Engineering и узнали, как разложить сложный проект «по полочкам» (а затем его так же и собрать). В этой части вы узнаете, как с помощью современных инструментов моделирования автоматизировать этот процесс.
Что такое модель?
Все мы часто слышим фразы со словом модель, вроде «модель продаж», «бизнес-модель», «3D-модель». Многие знают их смысл, но немногие задумываются, почему всё это модели?
Итак, модель — это некоторое упрощенное описание реальности, сохраняющее только важные свойства настоящего объекта, системы или процесса.
Можно взять любой предмет и сделать для него модель. Например, ромашка — это жёлтый круг и 7 белых лепестков по периметру (по версии художника), спирт — C2H5OH (со слов химика), машина — это подогрев передних сидений (если верить продавцу), квартира — это ипотека и гречка (как следует из банковской выписки).
Таким образом, настоящий объект может иметь множество упрощенных копий, каждая из которых предназначена для своих нужд.
Для примера рассмотрим мобильный телефон и модели, которые можно сделать на его основе.
- Функциональная модель разбивает устройство на функциональные блоки и взаимодействие между ними. Например, если от телефона требуется делать фотографии, то здесь это требование разбивается на следующие функции: ПолучитьИзображениеСКамеры ➔ ПредобработатьИзображение ➔ СохранитьИзображениеВПамять
- Логическая модель показывает, из каких логических компонентов состоит телефон, и какими данными они обмениваются. Для примера с фотографией это будут: Драйвер камеры, Препроцессор изображения, База данных фотографий и т.д.
- Модель UI содержит в себе пользовательский интерфейс и описывает взаимодействие его элементов друг с другом: какое меню вызывается по этой кнопке, какие действия доступны на том или ином экране и т.д.
- HW-модель описывает «железную» составляющую телефона: какие компоненты доступны, какие у них свойства и интерфейсы, как они связаны друг с другом
- Ну и, наконец, 3D-модель копирует внешний вид и внутреннее наполнение телефона: корпус, экран, порты, кнопки и переключатели.
Для чего они нужны?
Мы все привыкли к коду, который нас окружает: код программного продукта, сборочный код, код автотестов. Модель тоже можно рассматривать как код, но уже графический.
Преимущество моделей в том, что как ни рисуй, но если есть стрелочка из точки А в точку Б, то она сохранит свои свойства независимо от их взаимного расположения. Любой из пунктов можно вытащить на другую диаграмму, спрятать всё лишнее под проекцией и проанализировать лишь самый важный срез модели. Как результат:
-
менеджеры по продажам смогут оценить рыночную стоимость продукта и презентовать его преимущества потенциальным клиентам
-
проектные менеджеры рассчитают предполагаемые сроки разработки, учтут ресурсы и составят планы развития
-
разработчики — продумают архитектуру кода и структуры данных
-
тестировщики — оценят покрытие тестами, разработают тест-планы, подготовят тестовые данные и т.п.
Так что на самом деле стрелки на предыдущей картинке должны быть развёрнуты в обратную сторону:
При создании продукта строится набор его моделей и описывается их взаимодействие. При этом у каждой модели есть свои цели:
- Функциональная модель описывает, что телефон должен делать внутри себя, чтобы покрыть все юз-кейсы, какие данные должны передаваться между функциями, а также все требования к функциям
- Логическая модель говорит, какой из компонентов будет делать те или иные функции, описанные в функциональной модели. Здесь команды разработки компонентов договариваются об интерфейсах и распределении обязанностей
- UI-модель учитывает все элементы интерфейса, необходимые для взаимодействия с пользователем. На базе этой модели проводятся тесты юзабилити интерфейса и собирается фидбек с тестовых пользователей
- HW-модель имеет в себе все планируемые к использованию компоненты и их подключения. Проверяется их совместимость, анализируется энергопотребление и так далее. Также на базе этой модели строится модель печатной платы и расположения компонентов со своими этапами валидации
- 3D-модель устройства создается для тестирования удобства переноски и использования, расположения всех внутренних компонентов, и так далее.
Конечно, все эти модели должны быть взаимосвязаны, иначе мы получим набор несовместимых сущностей. Обычно связь происходит через аллокацию элементов одной модели на элементы другой, а также набор ограничений в обратную сторону.
Например, логические компоненты должны работать на конкретных чипах (аллокация), но при этом чипы не всегда имеют прямой доступ друг к другу или к каким-либо сенсорам (ограничения).
Материнская плата, батарея и экран должны умещаться в корпус устройства (аллокация), но каждый корпус предъявляет требования к размеру и форме элементов (ограничения).
Стоит заметить, что порядок построения моделей может сильно отличаться: зачастую, работа над «железной» частью начинается сильно заранее (потому что цикл занимает много больше времени), либо всё «железо» уже есть. Параллельно идет работа над функциональной моделью, и оба стрима встречаются на этапе логической модели: когда у нас есть понимание, что нужно сделать и куда это уместить.
Как всё это автоматизировать?
Самое главное в данном подходе — это коммуникация с помощью инструментов моделирования, благодаря которой возможно максимально быстро, просто и полно оценить любое изменение без бесконечных совещаний, созвонов и тонн писем коллегам из соседних подразделений.
Просто представьте, насколько сложно было бы спроектировать современные автомобили и сооружения, если бы не было таких программ, как AutoCAD и SolidWorks? В этих средах моделирования механических компонентов можно увидеть все зазоры и пересечения, проанализировать распределение нагрузки и многое другое. Аналогично, для других типов моделей есть свои среды, позволяющие, например, посчитать тепловые или аэродинамические параметры.
Для создания функциональных, логических и HW-моделей используется, например, System Composer от MathWorks. Данная среда позволяет также производить их аллокацию и анализ. Ниже — пример моделей для простого мобильного робота, который умеет ездить и следовать за объектом.
Ещё раз подчеркну, что это не просто картинки с прямоугольниками и стрелками, это набор взаимосвязанных блоков со своими свойствами, интерфейсами и дальнейшей декомпозицией внутри. Модели можно опрашивать, тестировать, сравнивать и анализировать автоматически.
Грамотно подобранный набор инструментов позволяет держать все модели в актуальном состоянии, моментально отслеживая любые изменения и несоответствия.
Модели связывают, и CI/CD проверяет каждый коммит в модель на ее совместимость с окружающими моделями, выстраивая таким образом дерево «что и где нам нужно поменять, чтобы вся система снова сошлась».
Именно через взаимосвязь моделей и автоматический анализ изменений мы и поддерживаем весь проект в актуальном состоянии.
Когда выстроены все процессы и проверки, остается только внедрять изменения и фиксить связанные с ними проблемы до тех пор, пока модели на всех уровнях не сойдутся. Как только все изменения внесены и все модели сошлись, продукт можно запускать в производство.
Всё описанное выше называют Model-based Systems Engineering.
Надеюсь, эта небольшая серия статей помогла разобраться, какими приёмами пользуется человечество для разработки и производства сложных систем. Многие детали опущены, чтобы было менее академично.
Ставьте класс, подписывайтесь на канал, дальше будет много интересного из более привычной всем на VC темы — запуска стартапов!
