Систематически проверяя модель проекта по требованиям, процесс разработки включает генерирующиеся тесты для каждого требования. Эти тесты подтверждают модель проекта, которая используется для генерации производственного кода и помогает завоевать доверие, что модель проекта удовлетворяет требованиям. Модель Specification является исполняемой сущностью, которая позволяет вам выполнять основанное на требованиях тестирование путем усиления возможностей Simulink® Design Verifier™.
Если у вас есть набор требований, которые написаны в тексте естественного языка, можно преобразовать их в формальные (исполняемые) технические требования с помощью Simulink. Они затем становятся моделью спецификации. В отличие от модели проекта, модель спецификации только задает то, Что должно быть сделано и не то, как это должно быть сделано. Это получает требования в более высоком уровне и скрывает детали на более низком уровне.
Преимущества использования модели спецификации:
Это подтверждает набор требований систематическим способом.
Это автоматизирует основанное на требованиях тестирование.
Это помогает идентифицировать недостающие требования, ошибки проектирования или несоответствия в ваших требованиях и модели проекта рано в этапе разработки.
Для основанного на требованиях тестирования тесты, сгенерированные из модели спецификации, используются, чтобы проверить модель проекта по требованиям. Выполните эти шаги для основанного на требованиях тестирования с помощью модели спецификации:
Требования автора в Редакторе Требования. Напишите свои требования в тексте естественного языка, который описывает поведение системы в соответствии с проектом.
Создайте модель спецификации. Спроектируйте модель спецификации как исполняемое представление требований. Это действие может показать проблемы, которые приводят к улучшению требований.
Соедините требования. Соедините отдельные требования или подтребования к частям модели спецификации.
Сгенерируйте тесты для модели спецификации. Сгенерируйте по крайней мере один тест на требование, которое демонстрирует его соответствие тому требованию.
Создайте тестовую подсистему преобразования. Спецификация и модели проекта не могут использовать тот же интерфейс ввода-вывода. Преобразуйте тесты, которые были сгенерированы на шаге 4 при помощи тестовой системы преобразования.
Разработайте модель проекта. Разработайте модель проекта независимо при помощи документа требований. Соедините требования с моделью проекта.
Проверьте проект и анализируйте покрытие. Запустите тесты, сгенерированные на шаге 5 на модели проекта, которая была разработана на шаге 6, и проверьте, соглашаются ли результаты с моделью спецификации и требованиями. Сгенерируйте отчет покрытия модели проекта идентифицировать недостающее покрытие и совершенствовать требования при необходимости.
Рабочий процесс модели спецификации
Считайте модели контроллеров автопилота описанными в Использовании Модель Спецификации для Основанного на требованиях Тестирования. Для этой демонстрации требования состоят из логических и временных условий разомкнутого контура.
Выполните эти шаги, чтобы создать модель спецификации для требований:
Используйте высокоуровневое представление для значений сигналов
Идентифицируйте предусловия, эффекты и ожидаемый Выход для каждого требования
Перечислите сигналы ввода и вывода для модели спецификации, которые связаны с требованиями. Можно проигнорировать сигналы, которые не связаны с требованиями под рукой.
Это входные сигналы для контроллера автопилота, которые основаны на требованиях:
Автопилот Затрагивает Переключатель: позвольте/Запретите контроллеру автопилота
Заголовок Затрагивает Переключатель: Когда занятый, включает HDG_HOLD_MODE. В противном случае, ROLL_HOLD_MODE активно
Прокрутите Кнопку Поворота Цели ссылки: набор, который кормит желаемым значением угла вращения контроллер автопилота
Заголовок Ссылочной Кнопки Поворота: Дает заданное значение для заголовка режима
Угол вращения самолета: текущий мгновенный угол вращения самолета
Это выходные сигналы:
Команда элерона: выход на привод элерона
Список Касательно Команды: выход на окне экрана, указывающем на заданное значение для привода элерона
Некоторые сигналы представлены в более высоком уровне в технических требованиях. Рекомендуется представлять сигналы с помощью высокоуровневого представления как области значений в модели спецификации.
Рассмотрите Угол вращения Самолета входного сигнала, который представляет текущий угол вращения самолета и принимает любое значение в интервале-180 до +180 градусов.
Требования описывают поведение контроллера автопилота в терминах зон. Эти зоны моделируются с помощью перечисления Range.
Эти пять зон показывают в следующем рисунке.
Требования задают высокоуровневые режимы AP Controller и их активные условия можно следующим образом:
| Режим автопилота | Автопилот затрагивает переключатель | Заголовок затрагивает переключатель |
|---|---|---|
OFF | Off | Не заботиться |
ROLL_HOLD_MODE | On | Off |
HDG_HOLD_MODE | On | On |
Рассмотрите следующее требование:
"Каждый раз, когда Кнопка Поворота Цели ссылки Списка кнопки поворота кабины (Roll_Ref_TK) управляет в нормальной области значений (между [-30,-3] или [+3, +30] степени), Ссылка Списка (Roll_Ref_Cmd) буду установлен в Roll_Ref_TK."
Идентифицируйте предусловие и эффекты. Указанное выше требование состоит из двух пунктов:
Precondition: Roll_Ref_TK находится любой в отрицательной нормальной области значений, [-30,-3], или в положительной нормальной области значений, [+3, +30].
Это предусловие является простым логическим выражением-OR, таким образом, таблицы истинности используются, чтобы описать логические предусловия.
Эффект: установите Roll_Ref_Cmd к Roll_Ref_TKПункт эффекта.The задает значения выходного сигнала в ожидаемой области значений.
Пункт предусловия требования определяет, когда это становится активным, в то время как пункт эффекта определяет то, что сделает требование после того, как это станет активным.
Указанное выше требование не оказывает влияния на Команду Элерона Ail_Cmd выведите, таким образом, это рассматривается как Range.All который обозначает набор всех возможных значений.
Создайте таблицу истинности для требований
Закодируйте пункт предусловия требования в раздел Condition Table таблицы истинности и пункт эффекта в раздел Action Table.
Чтобы отследить каждое требование индивидуально, установите локальную переменную REQ_ID на соответствующее требование ID 2.1.
Добавьте цель Simulink Design Verifier в Таблице Действия при помощи оператора sldv.test (REQ_ID == 2.1). Simulink Design Verifier находит тест, когда REQ_ID 2.1 удовлетворяют.
Итоговая модель спецификации, полученная при помощи вышеупомянутого рабочего процесса, выглядит так:
Используйте модель спецификации для основанного на требованиях тестирования
