| Автоматизация продажи билетов в кинотеатре |
|
table> | |
Прецедент: SeeInformation | | ID: 3 | | Краткое описание: Клиент смотрит наиболее полную информацию о сеансах, ценах, расписании сеансов чтобы определиться что именно он хочет от Кинотеатра. | | Главные актеры: Клиент | | Второстепенные актеры: Нет. | | Предусловия: Нет. | | Основной поток: 1. Прецедент начинается, когда Клиент выбирает опцию «Показать информацию». 2. Система выводит окно навигации в которой Клиент может выбрать либо Расписание сеансов и стоимость билетов, либо Информация о сеансах. 3. Если пользователь выбрал Расписание сеансов и стоимость билетов то 3.1 Система предоставляет окно информации в котором находятся данные о всех сеансах: - Наименование - Дата и время начала сеанса - Длительность - Стоимость билетов класса A, B, C - Зрительный зал в котором проводится сеанс 3.2 Система ждет сигнала от пользователя на возврат к выбору операций 4. Если пользователь выбрал Информация о сеансах то 4.1 Система предоставляет окно информации в котором находятся данные о всех сеансах: - Наименование - Описание - Актеров - Постер (картинка) 4.2 Система ждет сигнала от пользователя на возврат к выбору операций 5. Пока Покупатель просматривает информацию. 3.1. Система отображает рекламную информацию в блоках для рекламы. | | Постусловия: 1. Система показала данные о Сеансах. 2. Система показала рекламную информацию. | | Альтернативные потоки: Нет. | | | |
Прецедент: VernutBilet | | ID: 4 | | Краткое описание: Клиент возвращает билет Кассиру с целью возврата денег | | Главные актеры: Клиент. | | Второстепенные актеры: Кассир. | | Предусловия: 1.Клиент обладает билетом 2.До начала данного сеанса более 10 минут | | Основной поток: 1.Прецедент начинается, когда Клиент сообщает Кассиру что хочет вернуть билет. 2. Кассир проверяет билет 2.1.Если билет действительный 2.1.1.Если до начала сеанса более 10 минут 2.1.1.1.Кассир забирает билет 2.1.1.2.Кассир возвращает деньги за билет Клиенту 2.1.1.3.Кассир отправляет отчет в финансовый отдел 2.1.1.4.Кассир отмечает те места что были в билете как Свободные | | Постусловия: 1.Клиет не обладает билетом. 2.В финансовый отдел направлена информация о возврате билета 3.В базу данных занесено что Места снова доступны для продажи | | Альтернативные потоки: Нет. | | |
|
Прецедент: BronirovanieBileta | | ID: 5 | | Краткое описание: Клиент закрепляет за собой право покупки конкретного билета | | Главные актеры: Клиент. | | Второстепенные актеры: Кассир. | | Предусловия: ZapolnenieZakaza | | Основной поток: 1.Прецедент начинается, когда Клиент указал что хочет Забронировать билет. 2.Если данные заданы корректно. 2.1.Если требуемое место свободно. 2.1.1.Кассир закрепляет билет за Клиентом 2.2.2.Кассир отмечает те места, что были в билете как Забронированные | | Постусловия: 1.Клиент обладает Бронью на билет 2.В базу данных занесено, что забронированные Места более недоступны для продажи | | Альтернативные потоки: 1.Cancel | | |
|
Прецедент: 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)Место - Номер места - бронь Д) В ходе анализа выявленно что Клиент и Кассир не являются членами классов, Класс Зрительный_зал необходимо доопределить Названием_зала, Класс Место необходимо допределить добавив параметр куплено и преведя его параметр бронь к тому же виду что и куплено - забронировано. 1)Расписание_сеансов - название_сеанса - время_начала - зрительный_зал - цена А(VIP) Б(Comfort) С(Normal) - длительность_сеанса - описание_сеанса 2)Зрительный_зал - Название_зала - А(VIP) - Б(Comfort) - С(Normal) 3)Место - Номер места - Куплено - Забронировано Для спецификации состояния системы построим диаграмму классов для данной системы. Рисунок 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 Заполнение Заказа |
1 | Клиент | ZapolnenieZakaza | Клиент указывает в билете необходимую информацию, для последующего бронирования билета или его заказа | | |
Основное действующее лицо: Клиент. Другие участники прецедента: нет Связи с другими вариантами использования: отсутствуют Краткое описание. Данный вариант использования позволяет Кассиру осуществить генерирование билета или брони, на основе сформулированных предпочтений Клиента для последующей финансовой операции купли-продажи. Основой для генерирования билета и послужит этот набор предпочтений - заказ, который Клиент составляет сам (для примера - выбирает на какой сеанс пойти, какое место в зале приобрести). Для Атомата-Кассира этот Заказ может представлять собой таблицу с полями, которые заполняются Клиентом на основе имеющихся в ИС предложений. 3.1.2 Продажа Билетов |
2 | Клиент | ProdazhaBiletov | Клиент совершает операцию купли-продажи с целью получения билета на конкретный сеанс | | |
Основное действующее лицо: Клиент. Другие участники прецедента: Кассир Связи с другими вариантами использования: отсутствуют Краткое описание. Клиент обращается к Кассиру с сгенерированным заранее Заказом, с целью приобрести билет на сеанс указанный в Заказе. Происходит беглая проверка корректности Заказа. Кассир принимает платеж от Клиента и генерирует Билет. В случае Автомата-Кассира существенных отличий нет. 3.1.3 Просмотр информации |
3 | Клиент | SeeInformation | Клиент смотрит наиболее полную информацию о сеансах, ценах, расписании сеансов чтобы определиться что именно он хочет от Кинотеатра. | | |
Основное действующее лицо: Клиент. Другие участники прецедента: нет. Связи с другими вариантами использования: отсутствуют Краткое описание. Данный прецедент позволяет Клиенту получить необходимую и достаточную информацию о репертуаре театра для составления Заказа. Клиент смотрит информацию о: Наименование Время начала Длительность Информацию о сеансе Зал проведения Цена билета: Класс A Класс B Класс C 3.1.4 Возврат билета |
4 | Клиент | VernutBilet | Клиент возвращает билет Кассиру с целью возврата денег | | |
Основное действующее лицо: Клиент. Другие участники прецедента: Кассир. Связи с другими вариантами использования: отсутствуют Краткое описание. Данный вариант использования позволяет Клиенту сдать имеющийся у него действительный билет Кассиру и получить обратно средства, затраченные на его покупку. Данная операция действительна не позднее 10 минут до начала сеанса - это необходимо чтобы возвращенные билеты могли быть допущены к продаже до того момента как они станут недействительны. 3.1.5 Бронирование билета |
5 | Клиент | BronirovanieBileta | Клиент закрепляет за собой право покупки конкретного билета | | |
Основное действующее лицо: Клиент. Другие участники прецедента: Кассир Связи с другими вариантами использования: отсутствуют Краткое описание. На основе сгенерированного ранее Заказа Клиет может закрепить за собой право на конкретный билет не совершая финансовую операцию с Кассиром. Бронь осуществляется по желанию Клиента. Бронирование действительно до того момента когда до начала сеанса остается более 20 минут. В случае если билет не выкуплен по истечению этого срока бронь автоматически снимается с целью вернуть билет в оборот купли-продажи. Если билет выкупается до этого срока, то Клиент становится обладателем билета, а Кинотеатр получает деньги. 3.1.6 Снятие Брони |
6 | Клиент | SnyatBron | Клиент снимает бронь с билета | | |
Основное действующее лицо: Клиент. Другие участники прецедента: Кассир Связи с другими вариантами использования: отсутствуют Краткое описание. Клиент обращается к Кассиру с целью снятие с Билета брони. Билет возвращается в оборот купли-продажи. Клиент лишается права на этот Билет(Кроме как в случае если Клиент снова обратиться к Касиру с целью Купить/Забронировать Билет). 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
| 
