Размещено на http://www.allbest.ru/

Оглавление

• Введение
• 1. Предпроектное обследование
• 1.1 Общее описание кинотеатра «Кино-Max»
• 1.2 Проблемы кинотеатра «Кино-Max»
• 1.3 Организационная структура кинотеатра «Кино-Max»
• 1.4 Сценарий работы отдела по работе с клиентами
• 1.5 Функционально ориентированная модель кинотеатра «Кино-Max»
• 1.6 Сравнительный анализ существующих систем бронирования билетов в кинотеатрах
• 2. Математическая формализации, реинжиниринг, формирование требований
• 2.1 Анализ и выбор CASE средств
• 2.2 Математический аппарат систем массового обслуживания как механизм формализации функционально ориентированной модели кинотеатра «Кино-Max»
• 2.3 LabView как инструмент реализации модели системы массового обслуживания
• 2.3.1 Теоретические сведения о программном комплексе LabView
• 2.3.2 Программирование, основанное на потоках данных
• 2.4 Реализация модели системы массового обслуживания в инструментальном средстве LabView
• 2.5 Реинжиниринг модели СМО реализованной в LabView
• 2.6 Оптимизированная функционально ориентированная модель отдела по работе с клиентами кинотеатра «Кино-Max»
• 2.7 Основные требования к информационной системе продажи и бронирования билетов в кинотеатре «Кино-Max»
• 3. Проектирование информационной системы продажи и бронирования билетов в кинотеатре «Кино-Max»
• 3.1 Выбор архитектуры информационной системы
• 3.1.1 Архитектура клиент-сервер
• 3.1.2 Архитектура клиент-сервер
• 3.1.3 Многоуровневая архитектура
• 3.1.4 Архитектура на основе интернет/интранет технологий
• 3.1.5 Сравнительный анализ и выбор архитектуры
• 3.2 Проектирование информационной структуры
• 4. Реализация выбранного варианта решения
• 4.1 Обоснование выбора типа СУБД
• 4.2 Обоснование выбора среды программирования
• 4.3 Обоснование выбора ОС
• 4.4 Описание интерфейса пользователя
• 5. Социальная значимость разработки
• 6. Технико-экономическое обоснование проекта
• 6.1 Расчет затрат на проектирование
• 6.2 Состав эксплуатационных расходов
• 6.3 Расчет экономии от увеличения производительности труда пользователя
• 6.4 Расчет экономического эффекта от использования программы
• 6.5 Сопоставление технико-экономических характеристик разработки с аналогом
• 7. Безопасность и экологичность проекта
• 7.1 Анализ безопасности процесса эксплуатации разрабатываемой ИС
• 7.1.1 Особенности функционального назначения ИС
• 7.1.2 Описание процесса эксплуатации ИС
• 7.1.3 Системный анализ безопасности ИС
• 7.1.4 Оценка напряженности процесса ИС
• 7.2 Анализ экологичности работы
• 7.3 Разработка мер профилактики и повышения безопасности и экологичности разрабатываемой ИС
• Заключение
• Введение
• В наше время, когда бурно развиваются многие направления и отрасли в науке и технике, когда происходят новые открытия, реализуются новейшие разработки и проекты, огромное и значимое место в этом всем развивающемся и совершенствующемся мире выделяется именно информационным технологиям.
• Управление любой системой, в том числе и организацией, можно рассматривать как воздействие субъектов управления на объекты в соответствии с заранее поставленными целями.
• Основные элементы системы управления компанией:
• 1. Цели и стратегии.
• 2. Бизнес-процессы.
• 3. Организационная структура (структура управления).
• 4. Способы взаимодействия (потоки и коммуникации).
• 5. Регламенты и мотивации (сотрудники).
• Это базовые элементы, на которых строится система управления любой компании. В зависимости от стадии развития компании одни элементы являются более значимыми, другие менее. Но при этом, каждый элемент всегда присутствует в компании в той или иной степени.
• Задача развития системы управления или повышения ее эффективности и всего бизнеса направлена, в первую очередь, на проработку и поддержку каждого из элементов в требуемом состоянии.

1. Предпроектное обследование

1.1 Общее описание кинотеатра «Кино-Max»

Кинотеатр - это общественное учреждение для публичного показа кинофильмов. Главное помещение кинотеатра - зрительный зал со специальным широким экраном размером до 30 метров и акустической системой. В современных кинотеатрах часто имеется несколько зрительных залов, обязательна система кондиционирования воздуха, а современные акустические системы состоят из множества раздельных звуковых каналов. Для высококачественного кинотеатра характерны акустически приспособленные стены и потолок, декоративное освещение. В кинотеатрах обычно также имеются фойе для зрителей, гардероб, буфет, служебные помещения. Ранее кинотеатры СССР были довольно крупными и вмещали до 2500-4000 зрителей единовременно. Более современные кинотеатры рассчитаны на меньшее количество зрителей, обычно по 200-300 посадочных мест в одном кинозале. Кинопроекционный комплекс кинотеатра зачастую состоит из одного или нескольких кинопроекторов для демонстрации фильмов с кинопленки шириной 35 мм, но есть и специальные кинотеатры, приспособленные для демонстрации трехмерного кино.

Кинотеатр «Кино-Max» - это современный кинотеатр оборудованный по последнему слову техники. Он имеет 5 прекрасно оформленных залов, каждый из которых оборудован на 85 посадочных мест. Здесь впервые использован новый стандарт кинопоказа: новый сеанс - каждые 15 минут.

Их «фишек» в кинотеатре «Кино-Max» присутствуют: кресла с качающейся спинкой, цифровой звук DolbyDigitalSurroundEX, система вентиляции и кондиционирования. Кинотеатр располагает большой охраняемой парковкой.

С каждым днем кинотеатры все больше и больше становятся неотъемлемой частью современного общества. Практически в каждом городе существует по несколько кинотеатров, которые вынуждены конкурировать как друг с другом, так и с другими развлекательными учреждениями. Не секрет, что каждый стремится привлечь к себе как можно больше посетителей - кинотеатр «Кино-Max» не исключение. А это достигается за счет таких факторов как:

· Правильно проведенная маркетинг компания:

ь Теле- и радио- реклама;

ь Банеры;

ь Листовки;

ь СМС рассылки и т.д.

· Качество и скорость обслуживания.

В данном дипломном проекте будет рассматриваться такой аспект как качество и скорость обслуживания клиентов.

1.2 Проблемы кинотеатра «Кино-Max»

Загруженность билетных касс имеет, как правило, пиковый характер. Т.е. очередь образуется за 10-15 минут перед началом фильма. Даже в небольших региональных кинотеатрах, например, на фильмы "9 РОТА" и "Дневной Дозор" были аншлаги, однако современный зритель, не любит стоять в очередях и может просто развернуться и уйти.

На что же тратит кассир время, продавая билеты? По опыту известно, что дольше всего кассир подбирает места устраивающие гостя, например, пришла компания из 4-х студентов, которые хотят сидеть рядом, при этом на не дорогих местах и желательно по центру зала. Вот здесь и начинается диалог.

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



Рис. 1.1 Этапы решения проблемы кинотеатра «Кино-Max»

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

1.3 Организационная структура кинотеатра «Кино-Max»

В ходе проведения предпроектного обследования было собрано достаточно данных, для построения развернутой организационной структуры кинотеатра «Кино-Max», которая представлена на рисунке 1.2.

Вся организационная структура кинотеатра условно делится на четыре отдела:

1. Управленческий отдел. Данный отдел необходим для контроля и управления непосредственной работой кинотеатра, а так же для управления финансовыми делами. Генеральный директор является вершиной в иерархии управленческого состава. Финансовый директор контролирует все финансовые дела и работу бухгалтеров.

2. Отдел по работе с клиентами включает кассиров и работников справочных служб кинотеатра.



Рис. 1.2 Организационная структура кинотеатра «Кино-Max»

3. Технический отдел состоит из киномехаников; тех персонала, отвечающего за чистоту в здании; и нескольких ремонтных бригад, одни из которых специализируется на ремонте мебели и прочего инвентаря кинотеатра, а другая специализируется на ремонте технического оборудования. Техническая бригада так же включает в себя администраторов ИС кинотеатра и системных администраторов.

4. Отдел безопасности отвечает за порядок в кинотеатре.

Далее в соответствии с этапами решения проблем кинотеатра (см. Рис. 1.3), перейдем к построению функциональной модели предприятия.

Так, как проблема у кинотеатра «Кино-Max» имеется с очередями далее в дипломной работе будем рассматривать отдел по работе с клиентами. Для более подробного и детализированного рассмотрения отдела по работе с клиентами необходимо построить типовой сценарий его работы.



Рис. 1.3 Функциональная модель предприятия

1.4 Сценарий работы отдела по работе с клиентами

Типовой сценарий работы отдела по работе с клиентами представлен на рисунке 1.4.

Рис. 1.4 Сценарий работы отдела по работе с клиентами

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

1.5 Функционально ориентированная модель кинотеатра «Кино-Max»

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

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

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

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

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

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



Рис. 1.5 Функционально ориентированная модель кинотеатра «Кино-Max»

1.6 Сравнительный анализ существующих систем бронирования билетов в кинотеатрах

Для решения поставленной задачи по созданию информационной системы бронирования билетов кинотеатре «Кино-Max»был проведен анализ работы отдела по работе с клиентами, в который и будет внедряться разрабатываемая ИС. В процессе анализа были выявлены существующие проблемы, на основании которых и были получены требования и специфика разрабатываемой ИС, формальная оценка существующих бизнес процессов и проведение их реинжиниринга будет произведено в разделе 2, а пока рассмотрим существующие решения в данной предметной области.

Выбор системы с помощью метода анализа иерархий:

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

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

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

Иерархия строится с вершины - цели анализа, через промежуточные уровни (критерии, по которым производится сравнение вариантов) к нижнему уровню (который является перечислением альтернатив).

Имеются три информационные системы: ИС «БроньМастер», ИС «Эверест» и «Разрабатываемая информационная система».

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

Для достижения цели произвем сравнение каждого критерия из альтернативных вариантов попарно. [12].

Сравнительный анализ программ-аналогов и разрабатываемой информационной системы сведены в таблицу 1.1.

Таблица 1.1 - Сравнительный анализ программ-аналогов и разрабатываемой информационной системы.

Функции	ИС «БроньМастер»	ИС «Эверест»	Разрабатываемая система
Удобство интерфейса	среднее	низкое	высокое
Скорость обработки запросов	низкая	средняя	высокая
Требования к аппаратным средствам	средние	высокие	низкое
Уровень защищенности	средний	низкий	высокий
Надежность	высокая	средняя	высокая

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

Таблица 1. 2 - Относительные веса критериев.

Заполнив Таблицу 1. 2, сначала определяю оценки компонент собственного вектора, которые получаются как произведение относительных весов критерия по горизонтали, возведенного в степень 1/5 (где 5 - количество критериев). Например, рассчитаю оценку собственного вектора для критерия «Удобство интерфейса»:

(1*1/3*1/5*1/5*1/8*)^1/5 = 0,278208

Аналогично определяю остальные критерии.

Для того же критерия «Удобство интерфейса» вычисляю нормализованные оценки вектора приоритета, разделив оценки собственного вектора на их сумму, равную 8,003038.

0,278208/ 8,003038= 0,034763

Так же рассчитываю остальные критерии.

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

22*0,034763= 0,764782

Просуммировав, получаем максимальное собственное значение матрицы (лmax), л max = 5,121036

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

Таблица 1.3 - Сравнение критериев информационных систем.

Сравнивая нормализованные оценки вектора приоритета можно сделать вывод, что наибольшее значение я придаю критерию «Надежность».

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

ИС = (л _max - n)/(n - 1),

где лmax - максимальное собственное значение матрицы (л _max? n),

n-размерность матрицы

ИС = (5,121036- 5)/ (5-1) = 0,030259

Разделив ИС на число, соответствующее случайной согласованности матрицы пятого порядка, равного 1,12, получим отношение согласованности (ОС). Величина ОС должна быть порядка 10% или менее, чтобы быть приемлемой. В некоторых случаях допускается ОС до 20%, но не более, иначе надо проверить свои суждения.

ОС = 0,030259 / 1,12 = 2,7% < 10%, т.е. пересматривать свои суждения нет нужды.

Следующим шагом выполняется сравнение информационных систем по каждому критерию отдельно. Данные об информационных системах по перечисленным выше критериям представлены в таблице 1.1.

Построю матрицу сравнений, сравнивая попарно альтернативу из строки с альтернативой из столбца по отношению к критерию «Удобство интерфейса». Сравнительные оценки систем по критерию «Удобство интерфейса» сведены в таблицу 1.4. Никакие другие критерии при этом не учитываю.

Значения из шкалы относительной важности вписываю в ячейки, образованные пересечением соответствующей строки и столбца. Диагональ этой матрицы заполняю значением «1», а ячейки, лежащие ниже диагонали - обратными значениями.

Относительная согласованность матрицы равна 7,4%, т.е. <10%.

Далее так же построю матрицу сравнений, сравнивая попарно альтернативу из строки с альтернативой из столбца по отношению к критерию «Скорость обработки запросов». Сравнительные оценки систем по критерию «Скорость обработки запросов» сведены в таблицу 1.5. Никакие другие критерии при этом не учитываю.

Таблица 1.4 - Сравнительные оценки систем по критерию «Удобство интерфейса».

Таблица 1.5 - Сравнительные оценки систем по критерию «Скорость обработки запросов».

Относительная согласованность матрицы равна 0,32%, т.е. <10%.

Далее так же построю матрицу сравнений по отношению к критерию «Требования к аппаратным средствам». Сравнительные оценки систем по критерию «Требования к аппаратным средствам» сведены в таблицу 1.6.

Таблица 1.6 - Сравнительные оценки систем по критерию «Требования к аппаратным средствам».

Относительная согласованность матрицы равна 1,58%, т.е. <10%.

Далее построю матрицу сравнений по отношению к критерию «Уровень защиты». Сравнительные оценки систем по критерию «критерию «Уровень защиты» сведены в таблицу 1.7.

Таблица 1.7 - Сравнительные оценки систем по критерию «критерию «Уровень защиты».

Относительная согласованность матрицы равна 1,22%, т.е. <10%.

Так же построю матрицу сравнений по отношению к критерию «Надежность».

Сравнительные оценки систем по критерию «Надежность» сведены в таблицу 1.8.

Таблица 1.8 - Сравнительные оценки систем по критерию «Надежность».

Относительная согласованность матрицы равна 0%, т.е. <10%.

Результаты оценок информационных систем по всем критериям сведены в таблицу 1.9,т.е. в самую верхнюю строку перенесу из таблицы 1.2 значения вектора приоритета для каждого критерия.

Для каждой из альтернатив заполняю столбцы критериев значениями локальных векторов приоритета, полученных соответственно в таблицах 1.4; 1.5; 1.6; 1.7; 1.8.

Далее подсчитываю значения глобального приоритета для каждой из альтернатив как сумму произведений значения вектора приоритета для критерия и значения вектора локального приоритета этой альтернативы в отношении данного критерия, т.е. для альтернативы ИС «БроньМастер» это будет:

0,034763 * 0,0,108836 + 0,061367* 0,12202+ 0,138393* 0,34037+ 0,214765* 0,333216+ 0,480398* 0,20000 = 0,226019027

Аналогично определяю остальные альтернативы.

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

Таблица 1.9 - Сравнительные оценки систем по всем критериям.

Таблица 1.10- Сравнение информационных систем

В данном случае это «Разрабатываемая система», на которой следует остановить свой выбор.

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

2. Математическая формализации, реинжиниринг, формирование требований

2.1 Анализ и выбор CASEсредств

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

Первый и основополагающим требованием к CASE-средству должна быть поддержка нотации UML версии 2.0 и свободное встраивание в модели произвольных графических объектов. Вторым немаловажным требованием является удобство применения CASE-средства.

На следующем этапе выберем несколько CASE-средств, среди которых будет производиться выбор. В данной работе в процессе анализа будут представлены следующие CASE-средства: BorlandTogether,MSVisio 2007,RationalRose. Все эти продукты поддерживают нотацию UML 2.0.

Достоинством MSVisio 2007является тот факт, что данный продукт распространяется как надстройка к MSOffice 2007. Размер дистрибутива у данного продукта не очень большой, что позволяет скачать его с сайта разработчика без каких-либо серьезных затрат.

Недостатком в данномCASE-средстве является тот факт, что оно поддерживает не все диаграммы нотации UML 2.0. Еще один минус - это отсутствие технической поддержки пользователей.Но! Большим плюсом является тот факт, что имеется возможность использовать не стандартные графические примитивы.

CASE-средство RationalRose является коммерческой разработкой компании IBM.Последняя 2007 версия данного продукта поддерживает нотацию UML 2.0 в полном объеме. При инсталляции пакета разработчику предоставляется множество утилит и сопутствующих продуктов, облегчающих разработку систем. Также в пакете присутствует возможность генерации исходного кода приложения на основе моделей. Среди достоинств еще можно выделить очень красивый интуитивно понятный и эргономичный интерфейс продукта.

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

CASE-средство BorlandTogether поставляется в комплекте с пакетом BorlandDeveloperStudio.Данный пакет ориентирован на разработку приложений на языках Delphi, C++ и Java. ВстроенноеCASE-средство в данный пакет позволяет создавать модели и генерировать исходный код из диаграммы классов. Данный пакет изначально ориентирован на написание исходного кода приложения, его компиляцию и отладку. Функции разработки моделей в данном пакете являются дополнительными.

Стоимость данного пакета является высокой. Но возможность приобрести лицензионную версию доступна более широкому кругу разработчиков.

В идеальном случае для создания моделей и проведения моделирования предметной области необходимо использовать CASE-средство от компании IBM - RationalRose7.0. Но ввиду высокой стоимости и недоступности данного средства, в данной работе будет использовано CASE-средство MSVisio 2007. Оно в данном случае удовлетворяет всем требованиям и является доступным.

CASE-средство BPwinподдерживающее методологии IDEF0, DFD, IDEF3 и CASE-средство ERwinподдерживающее методологию IDEF1x,являются безальтернативными в плане выбора. Проводить сравнение между средствами, поддерживающими нотацию UML 2.0 и методологии IDEF0, DFD, IDEF3 и IDEF1x считаю нецелесообразным, так как данные средства нацелены на решение различного круга задач, причем средства с поддержкой UML 2.0 способны решать задачи, решаемые средствами BPwin и ERwin.

Таблица 2.1Анализ CASE средств

	MS Visio 2007	RationalRose 7.0	BorlandTogether
Поддержка UML 2.0 и выше	+	+	+
Генерация кода программы	+	+	+
Работа в комплексе	-	+	+
Поддержка	-	+	+
Экспертная оценка	Удовлетворительно	Отлично	Хорошо
Размер дистрибутива	350 Мбайт	8 400 Мбайт	4 500 Мбайт
Аппаратные требования	512 Мб оперативной памяти, 400 Мб свободного места на HDD.	Минимум 1 Гб оперативной памяти, от 1200 Мб свободного места на HDD.	Минимум 1 Гб оперативной памяти (рекомендуется больший объем), 700 Мб свободного места HDD
Стоимость	Бесплатно, при условии покупки MsOffice	> 130 000 рублей	>55 000 рублей

Проведя анализ достоинств и недостатков, представленных CASEсредств, можно сделать выбор какое средство необходимо использовать в данном случае. Я склоняюсь к использованию для создания модели работы объекта исследования и модели разрабатываемой системы CASEсредства MSVisio2007, так как оно удовлетворяет требованиям по использованию нотации UML 2.0 в создаваемых моделях.

2.2 Математический аппарат систем массового обслуживания как механизм формализации функционально ориентированной модели кинотеатра «Кино-Max»

Рассмотрим простейшую СМО с ожиданием -- одноканальную систему (n - 1), в которую поступает поток заявок с интенсивностью л; интенсивность обслуживания µ (т.е. в среднем непрерывно занятый канал будет выдавать обслуженных заявок в единицу времени. Заявка, поступившая в момент, когда канал занят, становится в очередь и ожидает обслуживания.

Система с ограниченной длиной очереди. Предположим сначала, что количество мест в очереди ограничено числом m, т.е. если заявка пришла в момент, когда в очереди уже стоят m-заявок, она покидает систему не обслуженной. В дальнейшем, устремив m к бесконечности, мы получим характеристики одноканальной СМО без ограничений длины очереди.

Построим граф состояний исходя из приведенных выше данных представленный на рисунке 2.1.

Рис. 2.1 Граф состояний

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

Задаем число человек в очереди:

Интенсивность потока будет равна:

т.е приходит один человек в минуту.

Интенсивность обслуживания буде:

т.е. обслуживается один человек в три минуты.

Тогда:

Видим, что вероятность отказа сведена к 0. Определим относительную пропускную способность:

Абсолютная пропускная способность:

.

Средняя длина очереди:

Видим, что при обслуживании 50 человек средняя длина очереди составляет 49 человек.

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

Если же k=m+1, т.е. когда вновь приходящая заявка застает канал обслуживания занятым и m-заявок в очереди (вероятность этого ), то в этом случае заявка не становится в очередь (и не обслуживается), поэтому время ожидания равно нулю. Среднее время ожидания будет равно:

,

если подставить сюда выражения для вероятностей, получим:

Среднее время ожидания равно среднему числу заявок в очереди, деленному на интенсивность потока заявок.

Среднее время пребывания заявки в системе. Обозначим - матожидание случайной величины -- время пребывания заявки в СМО, которое складывается из среднего времени ожидания в очереди и среднего времени обслуживания . Если загрузка системы составляет 100%, очевидно, , в противном же случае:

.

Отсюда:

.

Тогда получаем среднее время, которое проводит человек у касс в кинотеатре:

Общее время работы системы составит:

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

2.3 LabViewкак инструмент реализации модели системы массового обслуживания

2.3.1 Теоретические сведения о программном комплексе LabView

LabVIEW (Laboratory Virtual Instrumentation Engineering Workbench) -- этосредаразработкииплатформадлявыполненияпрограмм, созданныхнаграфическомязыкепрограммирования «G» фирмы National Instruments (США).Первая версия LabVIEW была выпущена в 1986 году для Apple Macintosh, в настоящее время существуют версии для UNIX, GNU/Linux, Mac OS и пр., а наиболее развитыми и популярными являются версии для MicrosoftWindows.

LabVIEW используется в системах сбора и обработки данных, а также для управления техническими объектами и технологическими процессами. Идеологически LabVIEW очень близка к SCADA-системам, но в отличие от них в большей степени ориентирована на решение задач не столько в области АСУ ТП, сколько в области АСНИ.

2.3.2 Программирование, основанное на потоках данных

Графический язык программирования «G», используемый в LabVIEW, основан на архитектуре потоков данных. Последовательность выполнения операторов в таких языках определяется не порядком их следования (как в императивных языках программирования), а наличием данных на входах этих операторов. Операторы, не связанные по данным, выполняются параллельно в произвольном порядке.

В основе программирования в LabVIEW лежит понятие Виртуальных приборов (VirtualInstruments, VI). На лицевой панели, как и положено, располагаются элементы управления программой -- кнопки, графики, выключатели и тому подобное. Блок-схема -- это, по сути, и есть сама программа. При создании программы используется такое понятие, как «поток данных» (DataFlow). Суть его в том, что все элементы программы (которые представлены графически) связываются между собой связями по которым и происходит передача данных. На рисунке 6 представлен простейший прибор, созданный в среде LabView.

Цифрами обозначены:

· 1- точки, элементы программы (Nodes);

· 2 - терминалы индикаторов (IndicatorTerminals);

· 3 - связи (Wires);

· 4 - терминалы управляющих элементов (ControlTerminals)

Итак, в LabVIEW создается пользовательский интерфейс (лицевая панель), с управляющими элементами и индикаторами. Управляющие элементы -- это тумблеры, кнопки, поля ввода и прочие устройства ввода.

Рис. 2.2 Простейший прибор.

Индикаторы -- это графики, шкалы, лампочки, текстовые поля и тому подобное. После создания пользовательского интерфейса, добавляется программный код, который управляет объектами на лицевой панели. Этот код содержится в схеме (blockdiagram). Этот код чем-то напоминает собой блок-схему, хотя отличий много.

LabVIEW можно использовать для того, чтобы управлять различным оборудованием, таким, как, устройства сбора данных, различные датчики, устройства наблюдения, двигательные устройства (например, шаговые моторы) и тому подобное, а так же GPIB, PXI, VXI, RS-232 b RS-484 устройства. Также в LabVIEW имеются встроенные средства для подключения созданных программ к сети, используя LabVIEWWebServer и различные стандартные протоколы и средства, такие как TCP/IP и ActiveX.

Используя LabVIEW, можно создавать приложения для тестирования и измерений, сбора данных, управления различными внешними устройствами, генерации отчетов. Так же можно создать независимые исполняемые файлы и библиотеки функций, такие как DLL, так как LabVIEW -- это полноценный 32-битный компилятор.

Достоинства LabVIEW:

· полноценный язык программирования;

· интуитивно понятный процесс графического программирования;

· широкие возможности сбора, обработки и анализа данных, управления приборами, генерации отчетов и обмена данных через сетевые интерфейсы;

· драйверная поддержка более 2000 приборов;

· возможности интерактивной генерации кода;

· шаблоны приложений, тысячи примеров;

· высокая скорость выполнения откомпилированных программ;

· совместимость с операционными системами Windows2000/NT/XP/Vista, Mac OS X, Linux и Solaris.

LabVIEW поддерживает огромный спектр оборудования различных производителей и имеет в своём составе (либо позволяет добавлять к базовому пакету) многочисленные библиотеки компонентов:

· для подключения внешнего оборудования по наиболее распространённым интерфейсам и протоколам (RS-232, GPIB 488, TCP/IP и пр.);

· для удалённого управления ходом эксперимента;

· для управления роботами и системами машинного зрения;

· для генерации и цифровой обработки сигналов;

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

· для визуализации данных и результатов их обработки (включая 3D-модели);

· для моделирования сложных систем;

· для хранения информации в базах данных и генерации отчетов;

· для взаимодействия с другими приложениями в рамках концепции COM/DCOM/OLE и пр.

Вместе с тем LabVIEW -- очень простая и интуитивно понятная система. Неискушённый пользователь, не являясь программистом, за сравнительно короткое время (от нескольких минут до нескольких часов) способен создать сложную программу для сбора данных и управления объектами, обладающую красивым и удобным человеко-машинным интерфейсом. Например, средствами LabVIEW можно быстро превратить старый компьютер, снабжённый звуковой картой, в мощную измерительную лабораторию.

Специальный компонент LabVIEW -- ApplicationBuilder, позволяет выполнять LabVIEW-программы на тех компьютерах, на которых не установлена полная среда разработки.

2.4 Реализация модели системы массового обслуживания в инструментальном средстве LabView

Модель СМО, построенная в LabViewбудет иметь следующий вид.

Рис. 2.3 Модель СМО реализованная в LabView



Рис. 2.4 Блок диаграмма СМО

Описание элементов диаграммы:

- реализует очередь, которая задается числовым значением.

- реализует ввод числовых данных (количество человек, количество касс и т.д.).

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

- таймер. С его помощью реализуются временные задержки в программе.

- операция умножения.

Исходя из приведенных выше данных и вычислений, время обслуживания одного клиента составляет 1 минуту, время на подбор мест - 2 минуты. Смоделируем данную ситуацию при потоке посетителей в 50 человек. Из приведенных выше вычислений следует, что время обслуживания всей очереди составляет 150 минут.



Рис. 2.5 Время обслуживания всей очереди.

Видим, что данная модель соответствует математической модели, значит, в дальнейшем для большей наглядности будем использовать LabView.

Рассмотрим подробно последовательность действий. В поле «Количество клиентов» задаем число посетителей кинотеатра. Далее задаем «Время становления клиента в очередь», «Время, которое тратится на выбор места» и «Время, в течении которого обслуживается клиент». После запуска система начинает моделировать процесс обслуживания посетителей. Всем посетителям присваиваются номера в порядке их поступления. В полях «Очередь» отображаются номера посетителей, находящихся в очереди. Порядок их обслуживания -FIFO. В поле «Клиентов в очереди» отображается общее количество человек в очереди, а в поле «Обслужено клиентов» - сколько посетителей уже обслужено.

Видно, что с учетом всех затрат времени, которых можно избежать, не очень большое количество в 50 человек обслуживается больше часа.

2.5 Реинжиниринг модели СМО реализованной в LabView

Время обслуживания как таковое изменить нельзя, можно только увеличить количество одновременно обслуживаемых потоков за счет:

ь увеличения количества касс;

ь установки терминалов покупки билетов;

ь применения интернет технологий, для заказа билетов.

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

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



Рис. 2.6 Состояние очереди после введения средств автоматизации.

Рис. 2.7 Время обслуживания после введения средств автоматизации.

Как было выше доказано использование мониторов с онлайн информированием посетителей о наличии мест эффективно сказывается на уменьшении очереди. Но для того чтобы окончательно избавиться от очереди необходимо увеличить и количество касс. Для сформировавшейся очереди необходимо найти такое количество касс, при котором каждый человек будет находиться в очереди не более 10 минут. После внесения всех изменений диаграмма СМО примет следующий вид.

Рис. 2.8 Блок-диаграмма СМО

Видно, что было добавлено условие «forloop», которое и будет задавать, сколько человек одновременно покидает очередь в зависимости от количества касс. Мною рассматривается «идеальная ситуация», при которой время обслуживания клиентов во всех кассах одинаковое.

Будем проводить расчеты до тех пор пока все условия не будут выполнены.

Моделирую данную ситуацию, каждый раз увеличивая количество касс, до тех пор, пока время работы системы не будет меньше 10. Как видно на приведенном выше скриншоте, чтобы 50 человек не стояли в очереди больше 10 минут, необходимо наличие 9 касс, при условии, что время обслуживания клиента составляет 2 минуты, и при этом кассир не тратит время на подбор мест.

Рис. 2.9 Оптимальные условия, для решения задачи.

С учетом проведенных исследований и выдвинутых предложений построим оптимизированную функционально ориентированную модель работы отдела по работе с клиентами, кинотеатра «Кино-Max» под которую и будет проектироваться информационная система.

2.6 Оптимизированная функционально ориентированная модель отдела по работе с клиентами кинотеатра «Кино-Max»

Оптимизированная функционально ориентированная модель отдела по работе с клиентами представлена на рисунке 2.10.

Вывод: Из ФОМ, видно, что чем меньше функций возлагается на кассира, тем быстрее он работает. В данном разделе было наглядно показано, как производить подбор количества касс в зависимости от величины потока посетителей.

Рис. 2.10 Оптимизированная функционально ориентированная модель отдела по работе с клиентами

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

2.7 Основные требования к информационной системе продажи и бронирования билетов в кинотеатре «Кино-Max»

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

· Централизованное хранилище информации о сеансах, свободных местах в залах, количестве проданных билетов;

· Возможность отображать информацию о состоянии свободных мест в различных кинозалах на информирующие билеты;

· Возможность продавать билеты через электронные киоски;

· Возможность продавать билеты через интернет.

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

· АРМ администратора;

· АРМ кассира;

· АРМ управляющего;

· АРМ электронные киоски;

· АРМ интернет клиент.

3. Проектирование информационной системы продажи и бронирования билетов в кинотеатре «Кино-Max»

3.1 Выбор архитектуры информационной системы

По способу организации групповые и корпоративные информационные системы разделяются на следующие архитектуры:

· системы на основе архитектуры файл-сервер;

· системы на основе архитектуры клиент-сервер;

· системы на основе многоуровневой архитектуры;

· системы на основе Интернет/интранет-технологий.

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

Таблица 3.1 Типовые функциональные компоненты информационной системы

Обозн.	Наименование	Характеристика
PS	Presentation Services (средства представления)	Обеспечиваются устройствами, принимающими ввод от пользователя и отображающими то, что сообщает ему компонент логики представления PL, с использованием соответствующей программной поддержки
PL	PresentationLogic (логика представления)	Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя при выборе команды в меню, нажатии кнопки или выборе элемента из списка
BL	Business or Application Logic (прикладная логика)	Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение
DL	DataLogic (логика управления данными)	Операции с базой данных (SQL-операторы), которые нужно выполнить для реализации прикладной логики управления данными
DS	DataServices (операции с базой данных)	Действия СУБД, вызываемые для выполнения логики управления данными, такие как манипулирование данными, определения данных, фиксация или откаттранзакций и т. п. СУБД обычно компилирует SQL-предложения
FS	FileServices (файловые операции)	Дисковые операции чтения и записи данных для СУБД и других компонентов. Обычно являются функциями операционной системы (ОС)

3.1.1 Архитектура клиент-сервер

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

Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логику обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интерпретации.

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

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

3.1.2 Архитектура клиент-сервер

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

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

Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логика BL и DL -- на клиенте. Двухуровневое определение архитектуры клиент-сервер использует именно этот вариант: приложение работает у клиента, СУБД -- на сервере (рис. 1.5).

Поскольку эта схема предъявляет наименьшие требования к серверу, она обладает наилучшей масштабируемостью. Однако сложные приложения, вызывающие большое взаимодействие с БД, могут жестко загрузить как клиента, так и сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, потому что там находится логика принятия решения. Такая схема приводит к дополнительному усложнению администрирования приложений, разбросанных по различным клиентским узлам.

Рис. 3.1 Классический вариант клиент-серверной информационной системы

Для сокращения нагрузки на сеть и упрощения администрирования приложений компонент BL можно разместить на сервере. При этом вся логика принятия решений оформляется в виде хранимых процедур и выполняется на сервере БД.

Хранимая процедура -- процедура с операторами SQL для доступа к БД, вызываемая по имени с передачей требуемых параметров и выполняемая на сервере БД. Хранимые процедуры могут компилироваться, что повышает скорость их выполнения и сокращает нагрузку на сервер.

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

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

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

3.1.3 Многоуровневая архитектура

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в своей классической форме состоит из трех уровней:

· нижний уровень представляет собой приложения клиентов, выделенные для выполнения функций и логики представлений PS и PL и имеющие программный интерфейс для вызова приложения на среднем уровне;

· средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика BL и с которого логика обработки данных DL вызывает операции с базой данных DS;

· верхний уровень представляет собой удаленный специализированный сервер базы данных, выделенный для услуг обработки данных DS и файловых операций FS (без риска использования хранимых процедур).

Подобную концепцию обработки данных пропагандируют, в частности, фирмы Oracle, Sun, Inprise и др.

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

Централизация логики приложения упрощает администрирование и сопровождение. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их специалистам узкого профиля. Наконец, изменения прикладной логики не затрагивают интерфейса, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может появиться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов.

С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной. Продукты для трехзвенной архитектуры, так называемые мониторы транзакций, являются относительно новыми. Эти инструменты в основном ориентированы на среду UNIX, однако прикладные серверы можно строить на базе MicrosoftWindows NT с использованием вызова удаленных процедур для организации связи клиентов с сервером приложений. На практике в локальной сети могут использоваться смешанные архитектуры (двухуровневые и трехуровневые) с одним и тем же сервером базы данных. С учетом глобальных связей архитектура может иметь больше трех звеньев. В настоящее время появились новые инструментальные средства для гибкой сегментации приложений клиент-сервер по различным узлам сети.

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

3.1.4 Архитектура на основе интернет/интранет технологий

Интернет/интранет-технологии. В развитии технологии Интернет/интранет основной акцент пока что делается на разработке инструментальных программных средств. В то же время наблюдается отсутствие развитых средств разработки приложений, работающих с базами данных. Компромиссным решением для создания удобных и простых в использовании и сопровождении информационных систем, эффективно работающих с базами данных, стало объединение Интернет/интранет-технологии с многоуровневой архитектурой. При этом структура информационного приложения приобретает следующий вид: браузер -- сервер приложений -- сервер баз данных -- сервер динамических страниц -- web-сервер.

Благодаря интеграции Интернет/интранет-технологии и архитектуры клиент-сервер процесс внедрения и сопровождения корпоративной информационной системы существенно упрощается при сохранении достаточно высокой эффективности и простоты совместного использования информации.

3.1.5 Сравнительный анализ и выбор архитектуры

Определим наиболее важные критерии для разрабатываемой ИС.