На этом шаге рассмотрим типичные приемы моделирования требований к системе в UML.
Требование определяет функцию, свойство или поведение системы. Формулируя требования к системе, вы составляете контракт между ней и теми сущностями, которые находятся вне ее. Этот контракт декларирует то, что система должна делать. Большей частью вас не заботит то, как она это будет делать – важно, чтобы она отвечала заявленным требованиям. Хорошая система выполняет требования точно, предсказуемо и надежно. Приступая к построению системы, важно начать с соглашений о том, что она должна делать, хотя, скорее всего, в процессе ее реализации вы будете не раз уточнять эти требования. Аналогичным образом, когда вы вводите систему в эксплуатацию, знание ее поведения весьма существенно для ее правильного использования.
Требования могут быть выражены в различных формах – от неструктурированного текста до выражений формального языка. Большинство функциональных требований к системе, если не все они, могут быть выражены в виде вариантов использования, а потому для управления этими требованиями важны диаграммы вариантов использования UML.
Чтобы смоделировать требования к системе, необходимо:
- установить контекст системы, идентифицируя действующие лица, окружающие ее;
- рассмотреть поведение системы, которого от нее ожидает или требует каждое действующее лицо;
- обобщить это поведение в виде вариантов использования;
- выделить общее поведение в новые варианты использования, на которые ссылаются другие варианты; выделить разновидности поведения в новые варианты использования, расширяющие основные потоки;
- смоделировать эти варианты использования, действующие лица и их связи на диаграмме вариантов использования;
- снабдить варианты использования примечаниями или ограничениями, которые задают нефункциональные требования; возможно, некоторые из них вы присоедините ко всей системе.
Рис. 1 дополняет диаграмму вариантов использования, показанную на рисунке 1 в шаге 153.
Рис.1. Моделирование требований к системе
Здесь скрыты связи между действующими лицами и вариантами использования, но зато вводятся дополнительные варианты использования, которые не видимы обычному пользователю, хотя и представляют важные аспекты поведения системы. Диаграмма полезна тем, что может послужить для конечных пользователей, экспертов в предметной области и разработчиков общей отправной точкой в процессе визуализации, специфицирования, конструирования и документирования их совместных решений, касающихся функциональных требований к системе. Например, Detect card fraud (Обнаружение мошенничеств) – это поведение, которое важно как для предприятий розничной торговли, так и для институтов финансового спонсирования. Report on account status (Отчет о состоянии счета) – еще одно поведение, требуемое от системы различными учреждениями в ее контексте.
Требование, которое моделируется вариантом использования Manage network outage (Управление сетевыми потоками), несколько отлично от всех остальных, поскольку описывает вторичное поведение системы, необходимое для обеспечения ее надежной непрерывной работы.
Определив структуру варианта использования, вы должны описать поведение каждого из них. Обычно нужно составить одну или несколько диаграмм последовательности для каждого основного сценария, затем – диаграммы последовательности для вариаций сценариев и, наконец, хотя бы одну диаграмму последовательности, иллюстрирующую каждый из возможных типов ошибок или исключений. Обработка ошибок – часть варианта использования, поэтому она должна быть запланирована наряду с нормальным поведением.
Те же приемы применяются при моделировании подсистем.
На следующем шаге рассмотрим прямое и обратное проектирование диаграмм вариантов использования в UML.
