Сценарии использования в динамике

Когда я формировал модель сценариев использования, я в описании использовал диаграмму прецедентов. Каждый прецедент содержит один или несколько сценариев использования.

Однако диаграмма прецедентов статична. Сформированная на её основе модель предметной области тоже статична: она содержит только сущности и связи. 

Но нам теперь нужно показать, как прецеденты реально работают в отношении сущностей и их связей. Для этого я использую диаграммы последовательностей.

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

Итак, самый сложный прецедент в нашей модели связан с редактированием заявки на обслуживание автомобиля. Базовый сценарий использования этого прецедента предполагает, что авторизованный пользователь может вызвать форму заявки, заполнить её, затем подписать данные заявки и сохранить заявку. 

При этом есть три нюанса. 

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

Во-вторых, пользователь может подписать заявку, а может этого не делать. Это опциональный прецедент, который связан с редактированием заявки связью "extend".

В-третьих, пользователь должен сохранить изменения, но в связи с нетривиальной логикой я ранее создал отдельный прецедент для сохранения заявки, который связан с рассматриваемым прецедентом связью "include".

При этом мы в рамках прецедента работаем с агрегатом, включающим в себя одну сущность - заявку Request.

Вся описанная логика выражается в виде диаграммы последовательности, как показано на рисунке выше.

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

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

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

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

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