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

Как проводить ранние тесты без доступа к оборудованию
Как управлять сложностью инженерных систем
Как снизить риск тестирования непроверенного программного обеспечения на дорогостоящем оборудовании
Как удовлетворить требованиям функциональной безопасности и других стандартов, включая DO-178B/C и ISO 26262

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

Agile и модельно-ориентированное проектирование. Основы

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

Рисунок 1. Agile разработка с использованием фреймворка Scrum.

Модельно-ориентированное проектирование – это подход к разработке систем, основанный на моделях. Вместо того чтобы полагаться на физические прототипы и текстовые спецификации для коммуникации в проекте, модельно-ориентированное проектирование использует модель на протяжении всей разработки. Модель включает в себя все компоненты, имеющие отношение к поведению системы: алгоритмы, логику управления, физические компоненты и окружающую среду. После того как модель разработана, ее можно использовать для создания кода (C/C++, HDL или структурированного текста), отчетов и других видов документации. Основными компонентами модельно-ориентированного проектирования являются проектирование и симуляция на уровне системы и компонентов, автоматическая генерация кода, непрерывное тестирование и верификация.

Сопоставление основных ценностей Agile с модельно-ориентированным проектированием

Agile-манифест определяет четыре основные ценности для разработки программного обеспечения:

Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану

Авторы манифеста подчеркивают, что "важнее" не означает "не". Они расставляют такой акцент: “То есть, не отрицая важности того, что справа (от слова "важнее"), мы всё-таки больше ценим то, что слева.”

Давайте посмотрим, как эти ценности Agile соотносятся с модельно-ориентированным проектированием.

Сосредоточение внимания на людях и взаимодействии

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

Сосредоточение внимания на сотрудничестве с заказчиком

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

Сосредоточение внимания на работающем продукте

Одним из главных преимуществ модельно-ориентированного проектирования для команды, использующей Agile, является возможность разработки работающей версии системы с самых ранних спринтов, даже если целевая встраиваемая система, объект управления, датчики или другое оборудование недоступны. Модель Simulink, проверенная с помощью симуляции, может служить работающим программным обеспечением на протяжении всего проекта. Модель выступает в качестве исполняемой спецификации разрабатываемой системы. В ранних спринтах, когда оборудование может быть недоступно, результаты симуляции могут быть переданы заказчику вместо результатов тестирования на оборудовании и использованы для оценки прогресса, демонстрации прототипа или планирования следующего спринта. Модели также обеспечивают четкий и удобный способ измерения прогресса. По мере разработки модели ее можно использовать для генерации кода для тестов программного обеспечения в контуре (Software-in-the-Loop, SIL), процессора в контуре (Processor-in-the-Loop, PIL) и полунатурного моделирования (Hardware-in-the-Loop, HIL), а также для прототипирования в реальном времени и затем для серийных систем.

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

Сосредоточение внимания на готовности к изменениям

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

Пример использования: Сочетание Agile методов с модельно-ориентированным проектированием для разработки адаптивного круиз-контроля

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

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

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

Рис. 2. Модель Simulink адаптивной системы круиз-контроля со слиянием датчиков.

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

Рис. 3. Результаты симуляции модели адаптивного круиз-контроля.

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

В более поздних спринтах команды включают более строгие мероприятия по верификации и валидации, включая тесты SIL, PIL или HIL, чтобы убедиться, что проект соответствует требованиям. Они также проверяют соответствие моделей и кода установленным стандартам и руководствам, используют статический анализ и формальные методы для доказательства отсутствия критических ошибок времени выполнения, а также создают отчеты и другие артефакты при подготовке к сертификации по стандартам безопасности.

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

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

Роджер Аареструп и Гаурав Томар, компания MathWorks

Фильтрация

Тип

Сортировка

Задача решена !

Теги

Комментарии

Популярные посты

Темы

Популярные теги

Ближайшие события