Что такое Модель Спецификации?

Систематически проверяя модель проекта по требованиям, процесс разработки включает генерирующиеся тесты для каждого требования. Эти тесты подтверждают модель проекта, которая используется для генерации производственного кода и помогает завоевать доверие, что модель проекта удовлетворяет требованиям. Модель 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 удовлетворяют.

Итоговая модель спецификации

Итоговая модель спецификации, полученная при помощи вышеупомянутого рабочего процесса, выглядит так:

Документация