В StarUML добавление описания к элементам модели делается следующим образом. Выделите элемент модели, щелкнув по нему мышкой, и откройте редактор Documentation. Если он не отображается справа на одной из вкладок инспектора модели, то откройте его, используя меню View → Documentation. Напротив пункта Documentation должна стоять галочка. Введите описание элемента в окно документирования (рис. 19).

Рис. 19 - Документирование элемента модели в StarUML

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

Пример. Для актеров и прецедентов системы заказов магазина «Style» сделаем краткое описание.

Покупатель – это человек, который может сделать заказ в магазине «Style», с помощью проектируемой системы.

Сотрудник – это все сотрудники магазина «Style», которые могут получать информацию о сделанных заказах и изменять статус заказа в системе в зависимости от того шага, на котором находится обработка данного заказа.

Система Склад – это внешняя система, которая получает информацию о сделанных в магазине «Style» заказах для того, чтобы обеспечить учет наличия товаров на складе и снабжение товарами.

Заказ товаров – этот прецедент запускается покупателем для того, чтобы оформить заказ в магазине «Style». Состоит из просмотра каталога, добавления товаров в корзину, просмотра корзины, изменения содержания корзины и оформления заказа, включая оплату.

Управление статусом заказа – этот прецедент используется сотрудниками магазина для изменения статуса заказа в процессе его обработки.

Получение информации о заказе – прецедент используется всеми актерами для просмотра информации о заказе.

Для того чтобы создать еще одну диаграмму (любого типа), например, детализирующую прецедент, щелкните правой кнопкой мыши по папке Use Case Model и в появившемся контекстном меню выберите Add Diagram, затем выберите из списка диаграмму, которую вы хотите добавить. Например, можно создать дополнительную диаграмму прецедентов, выбрав пункт Use Case Diagram (рис. 20).

Рис. 20 - Создание дополнительной диаграммы прецедентов

Пример. Наиболее значимым для данной системы и ее актеров прецедентом является прецедент Заказ товаров. Для него мы построим дополнительную диаграмму прецедентов, поясняющую этот вариант использования (рис. 21).

Рис. 21 - Диаграмма вариантов использования, поясняющая основной прецедент Заказ товаров

Потоки событий

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

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

Поток событий – это определенная последовательность действий, которая описывает действия актеров и поведение моделируемой системы в форме обычного текста.

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

Потоки событий бывают трех типов: основной, альтернативный и поток ошибок.

Основной (главный) поток описывает наилучший сценарий либо наиболее используемый путь исполнения прецедента.

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

Поток ошибок рассматривается как отклонение от альтернативного или основного, которое порождает условия формирования ошибки.

Пример. Опишем потоки событий прецедента Заказ товаров.

Основной поток событий:

1. Прецедент начинается с выбора покупателем режима показа каталога.

2. Система открывает каталог.

3. Покупатель выбирает режим показа корзины.

А1. Покупатель просматривает каталог и запускает поток «добавление товара в корзину»

4. Система открывает корзину.

5. Покупатель нажимает кнопку «оформить заказ».

А2. Покупатель просматривает корзину и запускает поток «изменение корзины».

А3. Покупатель решает вернуться в каталог.

6. Система переходит к первому шагу оформления заказа: запрашивает у покупателя личные данные и телефон.

7. Покупатель вводит личные данные и телефон.

8. Система переходит ко второму шагу оформления заказа: показывает содержимое заказа и просит подтвердить заказ.

9. Покупатель подтверждает заказ.

А4. Покупатель возвращается в корзину.

10. Система переходит к третьему шагу оформления заказа: запрашивает тип кредитной карты, ее номер, секретный код, имя владельца и дату завершения срока действия.

11. Покупатель вводит тип кредитной карты, ее номер, секретный код, имя владельца и дату завершения срока действия.

12. Система переходит к четвертому шагу оформления заказа: подтверждает оплату.

А5. Счет пользователя не найден.

А6. Недостаточно денег на счете.

Е1. Платежная система недоступна.

13. Система присваивает заказу номер и отправляет его вместе с подтверждением заказа на электронный адрес покупателя.

14. Вариант использования завершается.

Альтернативные потоки: