Пример проектирования информационной системы «стол заказов»

4.1. Представление Вариантов Использования

4.1.1. Диаграмма Вариантов Использования

В качестве действующих лиц (актёров) информационной системы «Стол заказов» могут выступать два субъекта, один из которых является оператором, а другой – клиентом.

Определим варианты использования системы оператором. Для этого обратимся к функциям оператора, описанным в Постановке задачи. Это регистрация пользователей, пополнение счетов клиентов, редактирование ассортимента и корректирование состояния заказа. Оформим их в качестве прецедентов, дав соответственно названия: «Зарегистрировать пользователя», «Пополнить баланс», «Изменить ассортимент» и «Изменить состояние заказа». Кроме того, оператор при каждом входе в систему должен пройти процедуру аутентификации (предоставить свои логин и пароль) для подтверждения прав доступа. «Аутентификация» - ещё один вариант использования системы оператором.

Другой пользователь системы – клиент – также может инициировать этот вариант использования («Аутентификация») для входа в систему, предъявив свои логин и пароль.

После входа в систему клиент может просмотреть ассортимент продукции, оформить новый заказ, изменить или отменить оформленный, но ещё не выполненный заказ. На основе этого можно выделить два варианта использования: «Просмотреть ассортимент» и «Управление заказом». Прецедент «Управление заказом» включает в себя оформление, изменение и отмену заказов. Эти функции работы с заказом целесообразно объединить для избежания загромождения диаграммы и учитывая их общую направленность.

Для удобства оформления нового заказа добавим в систему функцию копирования клиентом своего ранее оформленного заказа. Это будет абстрактный вариант использования «Копировать заказ», расширяющий прецедент «Управление заказом».

Чтобы осуществить функции копирования, редактирования и отмены заказа понадобится вариант использования «Найти заказ», который будет инициироваться пользователем.

При оформлении и редактировании заказов появляется необходимость обращаться к прецеденту «Просмотреть ассортимент». Следовательно, этот вариант использования может инициироваться не только клиентом, но и прецедентом «Управление заказом», поэтому между ними существует связь использования (от прецедента «Управление заказом» к прецеденту «Просмотреть ассортимент»).

Вариант использования «Просмотреть ассортимент» должен предоставлять клиенту возможность просмотра списка продукции, имеющейся в данный момент на складе. При оформлении, редактировании и отмене любого заказа количество товара на складе (а, возможно, и сам факт наличия) меняется. Исходя из этого, необходимо создать ещё один абстрактный вариант использования – «Учёт товаров на складе». Он будет использоваться прецедентами «Просмотреть ассортимент» и «Управление заказами».

П остроенная согласно этим рассуждениям диаграмма Вариантов Использования представлена на рисунке 68.

Рис.68. Диаграмма Вариантов Использования.

Базовые сценарии всех вариантов использования приведены в приложении А.

4.1.2. Диаграммы Взаимодействия

4.1.2.1. Диаграммы Последовательности

Диаграмма Последовательности – это упорядоченная по времени диаграмма Взаимодействия, читать её надо сверху вниз. У каждого варианта использования имеется большое количество альтернативных потоков. Каждая диаграмма Последовательности описывает один из потоков варианта использования.

Зарегистрировать пользователя

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

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

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

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

Диаграмма последовательности для варианта использования «Зарегистрировать пользователя» представлена на рисунке 69.

Остальные диаграммы последовательности приведены в приложении Б.