Первая десятка рекомендаций по моделированию для системных инженеров: Рекомендация 7. Модели требований помогают избегать дорогостоящих дефектов на ранней стадии

Брюс Дуглас (Bruce Douglass) демонстрирует, как сделать требования более полными, более правильными, более детальными и более точными.

Брюс Дуглас, главный популяризатор Rational, отделение системотехники

Фото автораБрюс Дуглас (Bruce Douglass) имеет более чем 30-летний опыт работы с программным обеспечением и специализируется на разработке систем реального времени и встраиваемых систем. Он автор процесса разработки встраиваемых систем реального времени IBM Rational Harmony™ (Harmony/ERT). Вместе с Питром Хофманом разработал оригинальный процесс Harmony, в котором системотехника и ПО сочетаются с узкоспециализированной автоматизацией для достижения гладкого, комплексного рабочего процесса. В IBM занимается консалтингом и преподаванием UML, SysML и DoDAF не только заказчикам программного обеспечения Rational, но и собственным инженерам, научным сотрудникам и специалистам по маркетингу IBM. Написал более 100 журнальных статей и 15 технических книг, является лектором и членом консультативного совета Конференции встраиваемых систем и Всемирной конференции UML. Его опыт включает в себя гибкую разработку и гибкие методы проектирования систем, а также разработку на основе модели и системы повышенной безопасности.



07.02.2014

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

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

Примечание: Я на самом деле писал стихи с помощью машин состояний языка UML, однако это оказалось, скажем так, не самым лучшим вариантом их применения.

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

Еще труднее продемонстрировать согласованность большого количества требований. Обеспечение согласованности в спецификации объемом в сотни страниц — весьма непростая задача.

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

Проблема состоит в том, что представленные в текстовом виде требования по сути не являются верифицируемыми. Решение состоит в представлении требований в виде модели.

Рассмотрим простой вариант использования под названием Evening Low Volume Mode (вечерний режим со сниженной интенсивностью движения) для системы управления светофорами. Светофор для сквозного движения по главной дороге мигает желтым светом, а светофор для сквозного движения по второстепенной дороге мигает красным светом. На рис. 1 показано, как этот простой набор требований может быть представлен в виде исполняемой машины состояний, которая посылает сообщения следующим акторам (действующим лицам) в своей среде: пешеходы на главной дороге (PP), пешеходы на неглавной дороге (SP), автомобили, осуществляющие сквозное движение по главной дороге (PV), автомобили, осуществляющие поворот на главной дороге (PtV), автомобили, осуществляющие сквозное движение по второстепенной дороге (SV), и автомобили, осуществляющие поворот на второстепенной дороге (STV). Кроме того, на рис. 1 показано, как добавить связи к элементам машины состояний для отображения представленных требований.

Рисунок 1. Простая машина состояний для варианта использования Evening Low Volume Mode
use case state machine

Основное преимущество этой модели состоит в том, что она является исполняемой. Ее можно использовать для исследования различных ситуаций, контекста, значений и порядка поступления событий. Конечно, машина состояний на рис. 1 весьма проста. Теперь рассмотрим несколько более сложный набор требований для режима Fixed cycle mode (режим с фиксированным циклом) в той же системы управления светофорами

  • Вариант использования: Fixed cycle mode (режим с фиксированным циклом)
    • Перекресток имеет главную дорогу и второстепенную дорогу.
    • Каждая дорога имеет полосы сквозного движения и полосы с левым поворотом.
    • Полосы сквозного движения для обоих направлений одной дороги активируются одновременно.
    • Полосы с поворотом для обоих направлений одной дороги активируются одновременно.
    • Полосы сквозного движения активируются без внешнего стимула в соответствии с циклом RED-GREEN-YELLOW-RED (КРАСНЫЙ-ЗЕЛЕНЫЙ-ЖЕЛТЫЙ-КРАСНЫЙ). Остальные светофоры показывают сигнал RED (КРАСНЫЙ) и DON'T WALK (ПЕРЕХОД ЗАПРЕЩЕН), пока движение по дороге разрешено.
    • Полосы с поворотом активируются при въезде автомобиля на полосу поворота; в противном случае они остаются в состоянии RED.
      • В следующий раз, когда полоса сквозного движения в нормальных условиях должна стать активной, сначала активируется полоса с поворотом, а полоса сквозного движения остается в состоянии RED до тех пор, пока цикл поворота не будет завершен.
      • Обе противоположные полосы с поворотом функционируют в соответствии с циклом RED-GREEN-YELLOW-RED. После этого полосе сквозного движения будет разрешено перейти в состояние GREEN
      •  После завершения цикла для полосы с поворотом для его повторной активации необходимо прибытие следующего автомобиля.
    • Сигналы для пешеходов остаются в состоянии DON'T WALK (ПЕРЕХОД ЗАПРЕЩЕН) до тех пор, пока прибывший пешеход не активирует их переключение нажатием кнопки.
      • В следующий раз, когда полоса сквозного движения должна перейти в состояние GREEN, сигналы для пешеходов переключаются согласно следующему циклу:
        • DON'T WALK ("Переход запрещен")
        • WALK ("Идите")
        • Мигающий знак DON'T WALK
        • DON'T WALK
      • Полоса сквозного движения переходит в состояние YELLOW только после того, как сигнал для пешеходов перейдет в состояние DON'T WALK.

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

Рисунок 2. Машина состояний для варианта использования Fixed cycle mode
use case state machine

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

Ресурсы

Научиться

  • Оригинал статьи: Top 10 modeling hints for system engineers: #7 Requirements models help you avoid early expensive defects.
  • Дополнительная информация о продукте Rational System Architect
  • Для получения дополнительной информации об инструменте Rational Rhapsody для коллективной управляемой моделями разработки встроенных систем познакомьтесь с обзором линейки продуктов Rational Rhapsody и посетите страницу Rational Rhapsody на сайте IBM developerWorks. Чтобы получить локальный экземпляр документации, посетите раздел Changing the location of help content в информационном центре по продукту Rational Rhapsody 7.6.
  • Для получения дополнительной информации о возможностях продукта Rational Rhapsody в области управления проектированием ознакомьтесь с инструментом IBM Rational Rhapsody Design Manager, который позволяет всем участникам группы разработки взаимодействовать, совместно использовать ресурсы, просматривать материалы, управлять проектированием и моделями. Кроме того, посетите страницу Design Management на сайте Jazz.net.
  • Посетите раздел по программному обеспечению Rational на сайте developerWorks и ознакомьтесь с техническими материалами, проверенными методиками и информацией по интегрированным решениям Rational для коллективного создания программного обеспечения и систем.
  • Следите на веб-сайте developerWorks за мероприятиями и трансляциями по техническим вопросам, посвященными различным продуктам IBM и актуальным темам ИТ-отрасли.
  • Углубите свои навыки. Ознакомьтесь с каталогом ресурсов для обучения и сертификации по продуктам Rational, который содержит множество курсов различного типа, охватывающих широкий диапазон тем. Некоторые из этих курсов можно пройти в любом месте и в любое время, а многие курсы категории Getting Started являются бесплатными.

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=962100
ArticleTitle=Первая десятка рекомендаций по моделированию для системных инженеров: Рекомендация 7. Модели требований помогают избегать дорогостоящих дефектов на ранней стадии
publish-date=02072014