Сценарии использования программного обеспечения в предметной среде

Клиент (далее — страхователь) обращается в страховую компанию за соответствующими услугами. Он может выбрать тип услуги из некоторого списка наименований, по которым компания выдает страховки.

Работник страховой компании (далее — страховщик), авторизовавшись в приложении, развернутом внутри корпоративной среды, заполняет входные данные нового контракта, основываясь на пожеланиях клиента. Ключевые параметры договорасохраняются в базе данных, и договор переходит в статус «черновик». Затем, менеджер по продажам просматривает сохраненный договор, и принимает решение — либо продать контракт, либо вернуть на корректировку. В первом случае договору выставляется статус «продан», страхователю распечатывается полис, автоматически сгенерированный системой с реквизитами, по которым осуществляется оплата. Во втором случае договор переходит в статус «необходима корректировка», и страхователю необходимо внести корректировки в контракт, а затем снова передать менеджеру по продажам для рассмотрения.

Менеджеру по продажам также доступен дополнительный функционал просмотра статистических данных по проданным договорам.

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

Под актором (действующее лицо, actor) понимают любой объект, субъект или система, взаимодействующая с моделируемой системой или программным обеспечением извне.

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

Вариант использования (прецедент, usecase) — описание множества последовательности действий (включая варианты), выполняемых системой для того, чтобы актор мог получить определенный результат [1,2].

На основании анализа предметной среды были определеныследующие компоненты системы. Акторами разрабатываемого сервиса являются:

• · страхователь
• · страховщик
• · менеджер по продажам

Прецедентамисервиса являются:

• 1. Посмотреть статистику продаж;
• 2. Авторизация;
• 3. Просмотреть список предыдущих контрактов;
• 4. Создать новый контракт;
• 5. Сохранить контракт в БД;
• 6. Вернуть на корректировку;
• 7. Открыть сохраненный контракт;
• 8. Удалить контракт;
• 9. Редактировать контракт;
• 10. Обновить данные в БД;
• 11. Продать контракт;
• 12. Распечатать договор;
• 13. Внести данные для сбора статистики.

Диаграмма вариантов использования разрабатываемой системы представлена на рисунке 1.1.

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

1. Прецендент начинается с авторизации страховщика.

Е1. Неверно указан пароль или логин страховщика.

А1. Страховщик проходит регистрацию.

2. Страховщик создает новый контракт, заполняет все его формы.

Е2. Заполнены не все ключевые поля контракта.

3. Данные контракта сохраняется в БД, сам контракт переходит в статус «черновик». Необходимый тариф рассчитывается автоматически.

А2. Данные контракта нуждаются в уточнении, либо статистические показатели указывают на то, что контракт необходимо поменять.

А3. Статистика показывает, что страховой случай весьма вероятно принесет убыток компании. Договор удаляется.

4. Менеджер по продажам, сверившись со статистикой, продает контракт, присваивая ему статус «продан».

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

А1. Страховщик проходит регистрацию.

• 1. Новый сотрудник проходит регистрацию, используя специальный код, выданный менеджером по продажам. Без кода регистрация невозможна.
• 2. Поток возвращается к шагу 1.

А2. Данные контракта нуждаются в уточнении, либо статистические показатели указывают на то, что контракт необходимо поменять.

• 1. Менеджер по продажам переводит контракт в статус «нуждается в корректировке», указывается причина невозможности его продажи.
• 2. Страховщик уточняет данные, звоня страхователю для уточнения.
• 3. Страховщик вносит правки в контракт, сохраняет его, снова присваивая ему статус «черновик».

Потоки ошибок:

Е1. Неверно указан пароль или логин страховщика.

• 1. Система просит пользователя заново ввести пароль и повторный пароль.
• 2. Поток возвращается к шагу 1.

Е2. Заполнены не все ключевые поля контракта.

• 1. Сервис выводит на экран сообщение о необходимости заполнить поля.
• 2. Поток возвращается к шагу 2.

Рисунок 1.1 — Диаграмма вариантов использования.