Прецедент: SnyatBron
ID: 6
Краткое описание:
Клиент снимает бронь с билета
Главные актеры:
Клиент.
Второстепенные актеры:
Кассир.
Предусловия:
1.Клиент обладает бронью на билет
2.До начала данного сеанса более 20 минут
Основной поток:
1.Прецедент начинается, когда Клиент сообщает Кассиру что хочет снять бронь.
2.Если бронь действительна
2.1.Если до начала сеанса более 20 минут
2.1.1.Кассир снимает бронь
2.1.2.Кассир отмечает те места, что были в билете как Свободные
Постусловия:
Нет.
Альтернативные потоки:
4.3 Диаграмма деятельности системы
Рисунок 8 - Диаграмма деятельности «Продажа билетов»
Данная диаграмма описывает поток событий, происходящий в системе при выполнении клиентом запроса на Приобретение билета.
5. Спецификация состояния проектируемого ПО
Проведем выявление классов в нашей системе для этого:
А) Выпишем все существительные:
Кинотеатр
сеанс
кассир
билет
зрительный_зал
цена
название_сеанса
Время_начала
Место
описание_сеанса
Длительность_сеанса
А(VIP)
Б(Comfort)
С(Normal)
Бронь
Номер_места
расписание_сеансов
Б) Выделим кандидатов в классы:
Расписание_сеансов
Зрительный_зал
С) Определим атрибуты каждого класса
1)Расписание_сеансов
-название_сеанса
-время_начала
-зрительный_зал
-цена А(VIP) Б(Comfort) С(Normal)
-длительность_сеанса
-описание_сеанса
2)Зрительный_зал
- А(VIP)
- Б(Comfort)
- С(Normal)
3)Место
- Номер места
- бронь
Д) В ходе анализа выявленно что Клиент и Кассир не являются членами классов, Класс Зрительный_зал необходимо доопределить Названием_зала, Класс Место необходимо допределить добавив параметр куплено и преведя его параметр бронь к тому же виду что и куплено - забронировано.
- название_сеанса
- время_начала
- зрительный_зал
- цена А(VIP) Б(Comfort) С(Normal)
- длительность_сеанса
- описание_сеанса
- Название_зала
- Куплено
- Забронировано
Для спецификации состояния системы построим диаграмму классов для данной системы.
Рисунок 9 - Диаграмма классов для системы «Продажи билетов в кинотеатре»
Получившиеся классы не относятся к системе продажи билетов, а относятся к внешним базам данных: База данных Репертуара и База данных сеансов. А это означает, что создание собственной базы данных для реализации системы продажи билетов в кинотеатре не требуется.
Приложение А
Спецификация требований к информационной системе «ПРОДАЖА БИЛЕТОВ В КИНОТЕАТРЕ»
1. Введение
1.1 Цель
Цель этого документа - в том, чтобы сформулировать требования к разрабатываемой АИС Продажи билетов в кинотеатре. Данные требования описаны в форме прецедентов, кратких описаний функциональных требований и описаний нефункциональных требований.
1.2 Определения, акронимы и сокращения
Основные определения приведены в документе Glossary.doc.
1.3 Ссылки
Сопутствующая информация представлена в следующих документах:
требованиях совладельцев (Пользовательские требования.doc);
глоссарии (Glossary.doc).
2. Обзор системы
2.1 Обзор прецедентов
Краткое представление актеров представлено в таблице 1.
Табл. 1. Актеры системы
Актер
Краткое описание
Кассир
Служащий Кинотеатра осуществляющий денежные операции с Клиентом. Занимается продажей билетов, установкой/снятием брони. Предназначено для обслуживания Клиента и является представителем Кинотеатра для Клиента. Построение ИС подразумевает возможную замену человека-Кассира на Автомат-Кассир.
Клиент
Лицо являющееся потребителем. В функции Клиента входит все что касается выбора сеанса из доступных предложений. Может покупать, возвращать, бронировать и осуществлять все допустимые операции с билетом при обращении к Кассиру
Список вариантов использования показан в таблице 2.
Табл. 2. Реестр вариантов использования.
Код
Основной автор
Наименование
Формулировка
1
ZapolnenieZakaza
Клиент указывает в билете необходимую информацию, для последующего бронирования билета или его заказа
2
ProdazhaBiletov
Клиент совершает операцию купли-продажи с целью получения билета на конкретный сеанс
3
SeeInformation
Клиент смотрит наиболее полную информацию о сеансах, ценах, расписании сеансов чтобы определиться что именно он хочет от Кинотеатра.
4
VernutBilet
Клиент возвращает билет Кассиру с целью возврата денег
5
BronirovanieBileta
Клиент закрепляет за собой право покупки конкретного билета
6
SnyatBron
2.2 Предположения и зависимости
Система будет использоваться на территориально сосредоточенном (без внешних филиалов) предприятии.
В случае изменений в формах документов АИС должна претерпеть малосущественные изменения (нужно будет модифицировать отчётные формы).
В случае приобретения или разработки информационных систем, автоматизирующих смежные участки, будет необходимо разработать соответствующие средства импорта-экспорта информации.
3. Описание требований
3.1 Краткие описания вариантов использования
3.1.1 Заполнение Заказа
Основное действующее лицо: Клиент.
Другие участники прецедента: нет
Связи с другими вариантами использования: отсутствуют
Краткое описание.
Данный вариант использования позволяет Кассиру осуществить генерирование билета или брони, на основе сформулированных предпочтений Клиента для последующей финансовой операции купли-продажи.
Основой для генерирования билета и послужит этот набор предпочтений - заказ, который Клиент составляет сам (для примера - выбирает на какой сеанс пойти, какое место в зале приобрести).
Для Атомата-Кассира этот Заказ может представлять собой таблицу с полями, которые заполняются Клиентом на основе имеющихся в ИС предложений.
3.1.2 Продажа Билетов
Другие участники прецедента: Кассир
Клиент обращается к Кассиру с сгенерированным заранее Заказом, с целью приобрести билет на сеанс указанный в Заказе. Происходит беглая проверка корректности Заказа. Кассир принимает платеж от Клиента и генерирует Билет. В случае Автомата-Кассира существенных отличий нет.
3.1.3 Просмотр информации
Другие участники прецедента: нет.
Данный прецедент позволяет Клиенту получить необходимую и достаточную информацию о репертуаре театра для составления Заказа. Клиент смотрит информацию о:
Время начала
Длительность
Информацию о сеансе
Зал проведения
Цена билета:
Класс A
Класс B
Класс C
3.1.4 Возврат билета
Другие участники прецедента: Кассир.
Данный вариант использования позволяет Клиенту сдать имеющийся у него действительный билет Кассиру и получить обратно средства, затраченные на его покупку. Данная операция действительна не позднее 10 минут до начала сеанса - это необходимо чтобы возвращенные билеты могли быть допущены к продаже до того момента как они станут недействительны.
3.1.5 Бронирование билета
На основе сгенерированного ранее Заказа Клиет может закрепить за собой право на конкретный билет не совершая финансовую операцию с Кассиром. Бронь осуществляется по желанию Клиента. Бронирование действительно до того момента когда до начала сеанса остается более 20 минут. В случае если билет не выкуплен по истечению этого срока бронь автоматически снимается с целью вернуть билет в оборот купли-продажи. Если билет выкупается до этого срока, то Клиент становится обладателем билета, а Кинотеатр получает деньги.
3.1.6 Снятие Брони
Клиент обращается к Кассиру с целью снятие с Билета брони. Билет возвращается в оборот купли-продажи. Клиент лишается права на этот Билет(Кроме как в случае если Клиент снова обратиться к Касиру с целью Купить/Забронировать Билет).
3.2 Специальные требования
3.2.1 Функциональность
3.2.1.1F1. Авторизация и аутентификация пользователей в системе
В АИС должны быть представлены справочник ролей пользователей (Клиент, Кассир) и справочник пользователей. Должна быть возможность регистрации пользователя и назначения пользователю роли.
3.2.1.3F2. Ведение расписания
В АИС должны быть представлены средства управления расписание сеансов и информации о сеансах.
3.2.2Применимость
3.2.2.1U1. Удобство использования
Интерфейс АРМ «Клиент» и «Кассир» должен быть обладать свойствами удобства и интуитивной ясности и не требовать дополнительной подготовки пользователей.
3.2.2.2U2. Помощь в режиме online
Все АРМ должны поддерживать контекстную справку в форме стандартного help операционной системы.
3.2.3Надежность
3.2.3.1R1. Доступность
АРМ Клиента, Кассира быть доступны в рабочие дни в рабочее время (как правило, с 8 до 18, если иное не указано распоряжением по предприятию).
3.2.3.2R2. Наработка на отказ
Среднее время безотказной работы - 10 рабочих дней.
3.2.3.3R3. Норма дефектов
Максимальная норма ошибок или дефектов - 1 ошибка на десять тысяч строк кода.
3.2.4Производительность
3.2.4.1P1. Одновременно работающие пользователи
Система должна быть способна поддерживать минимум 100 одновременно работающих пользователей, связанных с общей базой данных.
3.2.4.2P2. Время отклика
Время отклика для типичных задач - не более 2 секунд, для сложных задач - не более 5 секунд.
3.2.5Пригодность к эксплуатации
3.2.5.1S1. Масштабируемость
Система должна быть способна поддерживать минимум 100 одновременно работающих пользователей, связанных с общей базой данных и иметь возможность увеличить их количество на случай увеличения штата сотрудников предприятия.
3.2.5.2S2. Обновление версий
Обновление версий должно осуществляться в автоматизированном режиме на основе системы контроля версий и системы (сервера) обновления версий на рабочих местах пользователей.
3.2.6Ограничения проектирования
3.2.6.1X1. Применяемые стандарты
Система должна соответствовать всем стандартам интерфейса пользователя Microsoft® Windows®, Internet Explorer®.
3.2.6.2X2. Требования к среде выполнения
Система должна удовлетворять вышеуказанным требованиям на компьютере в следующей минимальной комплектации:
*64 Mb памяти
*3 Mb свободного дискового пространства
*процессор с тактовой частотой 850 MHz
*Операционная система Windows ХР и выше.
3.2.6.3X3. Требования к СУБД и доступу к данным.
В ядре системы должна быть представлена промышленная СУБД реляционного доступа.
Все обращения к информации должны осуществляться через драйвер ODBC.
4.Вспомогательная информация
Перечень вспомогательной информации представлен в п. 1.3.
Страницы: 1, 2, 3, 4
