Язык UML. Руководство пользователя

       

Требования к системе


Требование (Requirement) - это особенность проекта, свойство или поведение системы. Приступая к сбору требований, вы как бы описываете условия контракта, заключаемого между системой и сущностями вне нее, в котором декларируется, что система должна делать. При этом, как правило, вас заботит не то, как именно система будет выполнять поставленные задачи, а только то, что она будет делать. Хорошо спроектированная система должна полностью выполнять все требования, причем делать это предсказуемо и надежно. Ее создание начинается с соглашения о том, каково ее назначение, хотя в ходе разработки понимание требований будет постепенно изменяться. Аналогично при работе с готовой системой понимание того, как она себя ведет, имеет принципиальное значение для ее правильного использования.

Требования можно выразить по-разному, от неструктурированного текста до выражений на формальном языке (или, например, с помощью примечаний, см. главу 6). Большая часть функциональных требований к системе - или даже все они - может быть выражена в виде прецедентов использования, в чем помогают диаграммы прецедентов UML.

Моделирование требований к системе производится следующим образом:

  • Установите контекст системы, идентифицировав окружающие ее актеры.
  • Для каждого актера рассмотрите поведение, которого он ожидает или требу ет от системы.
  • Поименуйте эти общие варианты поведения как прецеденты.
  • Выделите общее поведение в новые прецеденты, которые будут использо ваться другими; выделите вариации поведения в новые прецеденты, расши ряющие основные потоки событий.
  • Смоделируйте эти прецеденты, актеры и отношения между ними на диа грамме прецедентов.
  • Дополните прецеденты примечаниями, описывающими нефункциональные требования; некоторые из таких примечаний можно присоединить к систе ме в целом.

    Рис. 17.3 расширяет предыдущую диаграмму. Хотя отношения между актерами и прецедентами на ней опущены, но присутствуют дополнительные прецеденты, которые описывают важные, пусть и невидимые для обычного пользователя, элементы поведения системы.
    Эта диаграмма удобна, поскольку дает возможность пользователям, экспертам и разработчикам совместно визуализировать, специфицировать, конструировать и документировать свои решения относительно функциональных требований к системе. Например, прецедент Обнаружение фальшивых карточек описывает поведение, важное как для Торговых предприятий, так и для Субсидирующих финансовых институтов. Другой прецедент - Отчет о состоянии счета - также описывает поведение, требуемое от системы различными организациями в своих контекстах.


    Рис. 17.3 Моделирование требований к системе

    Требование, моделируемое прецедентом Управление сбоями в сети, немного отличается от остальных, поскольку представляет вспомогательное поведение системы, необходимое, чтобы гарантировать надежное и непрерывное функционирование (см. главу 23).

    Такая же методика применима и при моделировании требований к подсистеме (см. главу 31).


    Содержание раздела