Файл: Автоматизация продажи билетов в кинотеатре Радуга кино г. Москва.pdf

Для разметки Web-страниц использовался язык гипертекстовой разметки HTML (HyperText Markup Language). Сам язык реализован в виде дескрипторов маркеров, которые описывают размещения элементов страницы, а также дополнительные характеристики каждого элемента.

Источниками информации для задачи, что разрешается, есть: отдел сбыта и бухгалтерия.

Входной информацией для задачи является информация справочников билетов и их описания.

Исходной информацией задачи является реестр подтвержденных заказов на дату, прайс-лист билетов и платежные поручения для клиентов.

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

Построение модели информационной системы начинается с описания функционирования системы в целом в виде контекстной диаграммы.

Рисунок 2 – Контекстная диаграмма «Продажа билетов в кинотеатре »

Взаимодействие системы с окружающей средой описывается с помощью входов («Обращения клиентов», «Репертуар» и «Расписание сеансов»), выходов («Билет», «Возврат билета», «Бронь» и «Снятие брони»), управления («Лицензия», «Нормы» и «Законы РФ»).

Клиенты – люди, создающие спрос на услуги Кинотеатра.

Репертуар – Набор фильмов или других товаров демонстрируемых в Кинотеатре.

Содержит:

- Наименование

- Описание

- Актеров

- Постер (картинка)

Расписание сеансов – Список всех проводимых Кинотеатром сеансов

Содержит:

- Наименование

- Дата и время начала сеанса

- Длительность

- Стоимость билетов класса A, B, C

- Зрительный зал в котором проводится сеанс

Законы РФ – законы по защите прав потребителя, и всероссийские нормы на осуществление коммерческой деятельности.

Билет – право Клиента на посещение конкретного сеанса

Возврат билета – случай, когда Клиент вернул билет Кинотеатру и получил затраченные на него денежные средства обратно

Бронь – закрепление места в зале за Клиентом. Изъятие места из продажи до срока пока оно не будет выкуплено Клиентом, или пока истечет срок бронирования

Снятие брони – освобождение места в зале. Внесение его в продажу.
Кассир – лицо исполняющее обязанности продажи билетов.

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

Рисунок 3 – Диаграмма декомпозиции «Продажа билетов в кинотеатре»

Как видно из диаграммы, весь процесс функционирования Кинотеатра разбивается на шесть блоков:

Предоставление информации - предоставление пользователю всей доступной информации о расписании и сеансах

Создание заказа - сведение всех требований Клиента в один заказ

Приобретение билета - совершение операции купли-продажи между Клиентом и Кассиром и закрепления за Клиентом билета

Проверка билета - операция по подтверждению действительности билета.

Произведем дальнейшее разбиение на подсистемы.

Рисунок 4 – Диаграмма декомпозиции «Предоставление информации»

Опишем процессы, представленные на данной диаграмме декомпозиции.

Получение информации – принятие клиентом решения получить информацию

Покупка билета – принятие клиентом решения приобрести билет на сеанс

Операции с бронью – принятие клиентом решения осуществить операцию с бронью

Вернуть билет - принятие клиентом решения вернуть приобретенный ранее билет

Рисунок 5 – Диаграмма декомпозиции «Создание заказа»

Опишем процесс создания заказа.

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

Требования Клиента – набор, заполненных Клиентом данных о сеансе которые однозначно его (сеанс) позиционирует.

Генерирование заказа – система формирует Заказ исходя из требований Клиента и Норм предприятия.

2.Информационное обеспечение задачи

2.1 Информационная модель и её описание

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

Представление в виде ФОМ удобно и наглядно с точки зрения восприятия общей структуры предприятия, взаимодействия основных его функций (подразделений).

ФОМ работы отдела по работе с клиентами можно представить следующим образом (см. рисунок 5).

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

Для более детального анализа необходима формализация ФОМ. При этом важно выбрать эффективный математический аппарат формализации.

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

Рисунок 7 - Информационная модель кинотеатра «Радуга кино»

2.2 Используемые классификаторы и системы кодирования

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

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

В нашей задачей с помощью кодирования обеспечивается выполнение основных функций, связанных с обработкой информации:

- минимизация объема информации при вводе ее в вычислительную систему;

- сортировка и поиск информации по ключевым признакам;

- разработка сводных отчетов по различным признакам;

- декодирование при переходе от кодов-признаков к их наименованиям при печати сводных отчетов.

В первой задаче, состоящей в вводе и хранении протоколов, отобраны объекты, подлежащие кодированию. Код присваивается таблицам с большим количеством реквизитов и саму протоколу.

Созданным кодам, которые формируются и автоматически соответствуют следующие признаки: обозначенные коды дают своим объектам однозначное обозначение. Если пользователь будет вручную редактировать код и задаст элементу или документу код уже существующего объекта, система не даст сохранить объект и выдаст предупреждение о том, что код занят. Тем самым, исключив потерю и дублирование информации, добившись необходимой идентификации данных (таблица 2):

Таблица 2

Используемые системы кодирования

2.3 Характеристика нормативно-справочной, входной и оперативной информации.

К формированию входных данных так же относится форма поиска (рисунок 8)

Рисунок 8 - Макет формы Поиска

На экранной форме Поиска находит поле ввода текста, куда не обходимо ввести требуемый запрос для поиска и кнопка, при нажатии, осуществляющая поиск в таблице Форумы.

Для ввода прав доступа к документам используется форма Права (рисунок 8 )

Рисунок 3 - Макет формы Права

Рабочая зона разделена на 2 части.

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

Во второй части расположен выбор группы, составляется по справочнику группы, выбор форума и права группы. Сохранение результатов производится по нажатии на кнопку “Применить”.

Для создание более универсальных договоров используется форма Создание шаблона (рисунок 9)

Рисунок 9 - Макет формы Создание шаблона

На форме находится многостраничное поле ввода для введение HMTL кода и кнопки Применить и Отмена.

Для создание договора на утверждение используется форма “Создание задачи и документа” (рисунок 10)

Рисунок 10 - Макет формы Создание задачи и документа

На форме расположено выбор Шаблона, данные берутся из справочника Шаблоны, название шаблона и раздел в котором создаётся задача. При выборе шаблона, он подряжается в серую область на форме.

Для подписание на рассылки необходима форма Подпись на рассылки (рисунок 11)

Рисунок 11 -Макет формы Подпись на рассылки

На ней представлен выбор раздела форума к которому происходит привязка на рассылку, данной формой происходит добавление в справочник Подписка.

Сводная таблица по справочникам приведена в таблице 3

Таблица 3

Параметры справочников

Реквизитный состав справочников следующий:

Справочник шаблоны имеет поле уникального номера, поле для ввода кода шаблонна договора.

Справочник Подписка имеет поле уникального номера, номер пользователя хотящего получать сообщения о изменениях и номер записи в форуме.

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

Справочник Группы имеет поле уникального номера, номер участника и номер его одногруппника.

Основными таблица сохраняющими результат ИС являются таблицы

Форумы и Файлы.

Таблица Форумы имеет следующие реквизиты

1) № Записи – номер уникальной записи в форуме

2) № сообщения – номер сообщения-комментария из таблицы Сообщения

3) Проверен – указывает на статус проверки

4) Согласован - указывает на статус согласования

5) Закрыто - указывает на статус закрытия документа, что запрещает его дальнейшее обсуждении

6) № файла – номер файл из таблицы Файлы