Программный комплекс обеспечения пропускного режима в организации

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

Министерство образования и науки РФ

ФГБОУ ВПО «Самарский государственный архитектурно-строительный университет»

Факультет информационных систем и технологий

Кафедра прикладной математики и вычислительной техники

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

на тему: Программный комплекс обеспечения пропускного режима в организации

Студента

Афанасьева И.М.

Самара 2013 г



РЕФЕРАТ

Дипломный проект.

Пояснительная записка: 153 с., 69 рис., 27 табл., 15 источников, 5 приложений.

Графическая документация: 9 л. А4.

Программный комплекс, МАГНИТНАЯ КАРТА, СИСТЕМА ДОСТУПА, ЭЛЕКТРОННЫЙ АБОНЕМЕНТ.

Объектом проектирования является информационная система электронного доступа в финтес-центр.

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

Разработана информационная система по методологии UML.

Результатом работы стало коммерческое внедрение системы на реальном объекте - спортивном комплексе «Янтарь».

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



СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ

1.1 Описание и системный анализ эволюции предметной области

1.2 Постановка задачи

1.3 Собираемая информация

1.4 Обзор существующих систем электронного доступа

1.5 Обоснование класса проектируемой системы

1.6 Цели проектирования

1.7 Разработка модели анализа

1.8 Разработка логической структуры базы данных

1.9 Выбор технических средств и ресурсный анализ

2. КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

2.1 Описание программной реализации системы

2.2 Разработка интерфейсов программы

2.3 Диаграмма последовательности (Sequence Diagram)

2.4 Диаграмма компонентов системы (Сomponent Diagram)

2.5 Диаграмма развертывания (Deployment Diagram)

2.6 Программа и методика испытаний

2.7 Информационная безопасность

3. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ РАЗРАБОТКИ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Краткая характеристика работы и ее назначение

3.2 Расчет затрат на разработку информационной системы (ИС)

3.3 Расчет затрат на аренду офисных помещений

3.4 Расчет затрат на покупку основных средств

3.5 Расчет прочих затрат

3.6 Фонд оплаты труда

3.7 Расчет месячной себестоимости разработки системы

3.8 Производственная программа

3.9 Финансовые результаты

3.10 Оценка безубыточности и расчет целесообразного объема продаж

4. РАЗРАБОТКА МЕРОПРИЯТИЙ ПО БЕЗОПАСНЫМ УСЛОВИЯМ ТРУДА

4.1 Общие положения

4.2 Требования к производственным помещениям для работы с ПЭМВ

4.3 Требования к освещению рабочих мест

4.4 Оптимальные параметры микроклимата

4.5 Требования к уровням шума и вибрации

4.6 Требования к уровням электромагнитных полей, создаваемых ПЭВМ на рабочих местах

4.7 Общие требования к организации рабочих мест пользователя

5. ИССЛЕДОВАТЕЛЬСКАЯ ЧАСТЬ

5.1 Возможности для исследований

5.2 Пик дневной посещаемости

5.3 Реклама на дисплеях

5.4 Ре-маркетинг бывших клиентов

5.5 Расчет стоимости привлечения клиентов

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

ПРИЛОЖЕНИЕ



ВВЕДЕНИЕ

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

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

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

- очень высокая скорость аутентификации: в то время как в стандартном случае человеку-контролеру приходится сверять фотографию или паспорт посетителя с бумажными списками, электронная система сделает это моментально - это этого просто нужно провести магнитную карту через считыватель магнитных карт (POS-терминал [1]).

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

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

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

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

В результате данной работы была реализована информационная система электронных карт доступа для коммерческого предприятия - Спортивный Комплекс «Янтарь» (г. Москва). Система позволяет регистрировать новых клиентов, управлять их возможностями, вести справочники площадок, типов абонементов. А также вести статистику по посещениям.



1. СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ

1.1 Описание и системный анализ эволюции предметной области

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

Значительные минусы подхода:

- ошибка оператора

- возможность потери данных при пожаре или наводнении

- невозможность полной систематизации данных

Незначительные минусы:

- большое время внесения 1 человека и выдача пропуска

- требует большие человеческие ресурсы

Реальной альтернативой бумажным пропускам служат приходящие им на смену электронные системы контроля доступа.

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

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

- Высокая скорость обработки данных;

- Ведение статистики посещений;

- Присвоение типа поведения к человеку на основе статистических методов;

- Создание отчетов.

Все эти преимущества можно эффективно использовать в целях развития и роста предприятия. Предприятие может использовать ИТ-технологии в сферах:

Управление предприятием

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

1.2) Статистика посещаемости за день позволяет определить «часы-пик», периоды, когда количество посетителей максимально - таким образом можно сделать планирование инвентаря. Рассчитать оптимальное количество тренажеров, мячей, полотенец и проч.

Маркетинг и продажи

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

2.2) Электронная карта хранит не только ФИО владельца, но и дату его рождения. Это позволяет менеджеру, обслуживающему клиента поздравить человека в день его рождения. Также возможно поздравить его с наступающим днем рождения, либо подготовить небольшой подарок. Такие действия повышают лояльность компании [2]. Создают имидж торговой марке.

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

Финансы и бюджет

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

1.2 Постановка задачи

Была поставлена задача разработать программный комплекс электронного контроля доступа для спортивного комплекса «Янтарь» работающего под торговой маркой «СПОРТИНГ Фитнес».

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

Сразу после входа в центральный манеж находится центральный холл комплекса, в нем расположена рецепция (обозначена буквой «R»), которая служит контрольно-пропускным пунктом (КПП). В зависимости от типа абонемента посетители могут посещать бассейн, тренажерный зал, стадион, который включает футбольное поле и беговые дорожки, а также теннисный корпус, который имеет собственный КПП (рисунок 1.2).

Рисунок 1.1 - Схема спорт-комплекса «Янтарь», цокольный этаж



Рисунок 1.2 - Оборудование рецепции

Каждый КПП оснащен оборудованием, представленным в таблице 1.1.

Таблица 1.1 - Оборудование КПП

Оборудование	Характеристики
1) Компьютер	- Операционная система: Linux; - Процессор: Intel Core2Duo; - ОЗУ: 512 МБ; - Видеокарта: 128 МБ с поддержкой разрешения экрана 1024х768 и выше;
	- Клавиатура, мышь, принтер; - ЖК Монитор; - ИБП.
2) Устройство считывания магнитных карт [1]	Устройство подключено к компьютеру через USB-порт.
3) Модем	ADSL или кабельный модем.

Схема регистрации посещения представлена на рисунке 1.3.

На втором этаже (рисунок 1.4) расположены трибуны для болельщиков, а также кабинеты руководства комплекса: кабинет менеджера (его позиция обозначена буквой «M») и маркетолога, кабинет директора и общий кабинет прочего административного персонала. Менеджер формирует и просматривает отчеты, доступные в системе для решения задач маркетинга и управления.

Рисунок 1.3 - Схема регистрации посещения

Рисунок 1.4 - Схема спорт-комплекса «Янтарь». 2 этаж

1.3 Собираемая информация

Магнитная карта

На магнитной карте [3] используется только 1 слой магнитной полосы - это повышает надежность системы и снижает стоимость производства карт. Карточка содержит в себе идентификационный номер (id) клиента.

Данные пользователя

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

Данные посещения

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

1.4 Обзор существующих систем электронного доступа

Девпарк Фитнес

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

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

Использование продукта «Девпарк Фитнес» совместно с системами контроля управления доступом (СКУД) позволяет владельцам бизнеса и управляющим не только автоматизировать учет в фитнес-клубе, но и планомерно увеличивать прибыль за счет ведения клиентской базы, эффективного управления складом, усиления контроля над работой персонала, в том числе пресечения злоупотреблений служебным положением, и получения в любой момент времени удобных для анализа отчетов. Гибкость систем настроек позволяет адаптировать данный продукт к любой модели бизнеса.

«Девпарк Фитнес» также легко интегрируется в другие продукты линейки «Системы контроля бизнеса Девпарк» для автоматизации бассейнов, банных комплексов, отелей, спа-центров.

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

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

- продажа контрактов, абонементов, клип карт;

- продажа разовых посещений, гостевых визитов, персональных тренировок;

- обслуживание корпоративных контрактов;

- продажа товаров и дополнительных услуг (массаж, сауна, солярий и т.д.);

- фитнес-бар;

- продажа заморозок абонемента;

- продление контрактов.

Возможности для привлечения клиентов:

- гибкая система скидок;

- возможность автоматических и ручных скидок;

- проведение акций;

- поддержка дисконтных и бонусных карт, , подарочных сертификатов;

- поддержка депозитов клиентов;

- поддержка различных видов абонементов (разовых, по времени, по количеству посещений);

- ведение клиентской базы;

- CRM-система. Настройка оповещений для менеджера по различным параметрам;

- e-mail и SMS-рассылка;

- печатные формы расписаний.

Управление работой персонала:

- отдельные учетные записи для каждого сотрудника с различными уровнями доступа;

- составление графика работы инструкторов и административного персонала;

- формирование электронного расписания занятий;

- учет фактически отработанного времени;

- расчет заработной платы инструкторов;

- разграничение контроля доступа в различные помещения, учет посещения данных помещений;

- оценка популярности занятий различных инструкторов;

- управление мотивацией с помощью КПИ модуля и системы начислений бонусов;

- система напоминаний и уведомлений;

- невозможность что-либо изменить в системе «задним числом».

Удобство использования:

- интуитивно понятный интерфейс рабочего места сотрудника ресепшн/бармена, возможность использования обычного и сенсорного экрана;

- современный наглядный интерфейс программы для управляющего/менеджера;

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

- прикрепление к каждой личной карточке (сотрудника или клиента) фото с веб-камеры;

- dashboard интерфейс - возможность собрать на одном экране сразу несколько ключевых отчетов по работе клуба для отслеживания показателей в реальном времени;

- контроль товарных и денежных потоков в реальном времени;

- учет выручки по клиенту, организации, персоналу, сменам, кассовым отделам;

- возможность просмотреть баланс по каждой кассе в реальном времени с историей формирования остатка;

- отчеты по движению товарных и денежных потоков с отображением остатка по складу или кассе после каждого движения - набегающий итог;

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

- учет каждой продажи с сохранением детализированной информации;

- полный складской учет;

- готовые печатные формы накладных, ордеров, прайсов, ценников, актов инвентаризации;

- управление закупочными и розничными ценами.

Оборудование:

- биометрическая система;

- бюджетные турникеты;

- ККМ;

- принтеры чеков;

- системы контроля доступа;

- сканеры штрих-кодов;

- считыватели карт;

- электромеханические замки[4].

UNIVERSE-СКУД

Компания «Юниверс-софт» предлагает вашему вниманию передовое техническое и компьютерное оснащение спортивных комплексов различной функциональной специфики для реализации проектов по cозданию эффективных систем контроля и управления доступом. Модуль «Universe-СКУД» проектируется индивидуально под каждого заказчика, учитывая индивидуальные особенности его предприятия. Основой системы СКУД служат контроллеры марки «Sphinx», производимые российским предприятием "ПромАвтоматика". Данные контролеры позволяют управлять электронными турникетами, электромагнитными замками, шлагбаумами и воротами самых известных производителей: PERСo, ОМА, Ростов-Дон, Трио, Форма. В качестве системы управления таким комплексом используется программа «Universe-Фитнес», многократно доказавшая на практике свою результативность в автоматизации менеджмента и маркетинга предприятий индустрии спорта и здоровья. Через программный модуль «Universe-СКУД» система «Universe-Фитнес» фиксирует все проходы через соответсвующие точки доступа, предоставляя доступ в зависимости от контрактов клиента.

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

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

Пример

Задача: организовать вход в зону 1 (бассейн) только для тех клиентов, которые имеют на это доступ.

Реализация: при входе в зону 1 устанавливается турникет, который через специальный контроллер подключается к компьютеру. Для идентификации клиентов на вход/выход, рядом с турникетом устанавливаются два считывателя смарт карт, которые также могут принимать сигнал с электронных браслетов и брелков. Система контроля доступа управляется через дополнительный модуль «Universe-СКУД», встроенный в систему управления предприятием «Universe-Фитнес». Данный модуль позволяет настроить связь между системой «Universe-Фитнес» и контроллером системы СКУД, обрабатывающим сигналы с смарт считывателей и управляющим турникетом. При считывании номера карты клиента, информация передается в систему UNIVERSE, в которой обрабатывается информация по клиенту и выдается положительный или отрицательный сигнал на открытие турникета.

Другим примером использования системы СКУД в фитнес клубе является установка турникетов на входе в клуб. Проход в клуб организовывается по пластиковым картам, клиент проводит картой по считывателю, обрабатывается информация по активности контракта клиента. Если у клиента есть хотя бы один действующий контракт, то идет сигнал на открытие турникета, а клиент автоматически получает статус посетителя (в форме «Обслуживаются» переносится в правую часть). Если за проходом клиентов нужен дополнительный контроль, то информацию по посетителям можно вывести на экран монитора, задав время отображения информационного окна. Выход их клуба может также быть организован на базе пластиковой карт - клиент при выходе считывает карту для открытия турникета и автоматически покидает клуб в системе «Universe-Фитнес» [5].

Сравнение систем

В таблице 1.2 представлено сравнение разработанной мной системы, UPG Automatic, с аналогами.



Таблица 1.2 - Сравнение систем электронного доступа в фитнес-центр

ИС	UPG Automatic Sport (разработанная мной система)	Девпарк Фитнес	UNIVERSE-СКУД
Система POS-терминалов и автоматического доступа	+	+	+
Клиентская база	+	+	+
База сотрудников	+	+	+
Терминал и учет	+	+	+
Система статистики	+	+	+
Расширенная статистика	+	-	-
Тип поведения и внештатные ситуации	+	-	-
Ведение кассы	-	+	+
Доступность и простота внедрения	+	-	-
Онлайн сервис	+	-	-
Итого плюсов	9/10	6/10	6/10
Итоговый рейтинг	90%	60%	60%

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

1.5 Обоснование класса проектируемой системы

Разработанная система относится к классу программных комплексов, так как она позволяет:

- Вести автоматический учет посещений клиентов;

- Формировать отчеты о посещаемости и выводить статистику.



1.6 Цели проектирования

Разработка программного комплекса, реализующего:

1) ведение справочной информации:

- пользователи;

- клиенты;

- площадки;

- типы абонементов.

2) ввод и редактирование исходных данных:

- пользователи;

- клиенты;

- площадки;

- типы абонементов.

3) авторизация пользователя, определение его прав;

4) автоматический учет посещений клиентов;

5) формирование отчетов:

- о посещаемости на выбранную дату;

- сводный отчет;

- отчет о внештатных ситуациях.

1.7 Разработка модели анализа

Краткое описание методологии UML

Унифицированный язык моделирования (UML) является стандартным инструментом для создания «чертежей» программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать артефакты программных систем [6].

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

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

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

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

- модель вариантов использования;

- модель анализа;

- модель проектирования;

- модель развертывания;

- модель реализации.

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

Полный комплект диаграмм UML находится в приложении В.

Диаграмма вариантов использования

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

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

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

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

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

Каждому актанту на схеме соответствуют возможности, доступные при использовании системы.

Например, актант «Администратор», при работе с системой, имеет следующие возможности:

ведение справочников.

Актанта «Менеджер» имеет следующие возможности:

формирование отчетов.

Рисунок 1.5 - Диаграмма вариантов использования

Сценарии вариантов использования

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

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

Вариант использования: Редактирование записи справочника

Краткое описание: Позволяет Администратору БД редактировать записи в справочнике площадок.

Актант: Администратор БД.

Предусловия. Выполнен вариант использования «Ведение справочников» до точки расширения, соответствующей началу редактирования справочника площадок, в режиме Администратора БД. На экране - главное меню системы, настроенное на права Администратора БД.

Основной поток событий.

1. Администратор БД выбирает пункт меню «Справочники» и далее подпункт «Справочник площадок».

2. Система выводит страницу справочника объектов с таблицей со столбцами: «Название площадки», «Код площадки». На странице расположены кнопки «Добавить», «Изменить», «Удалить», «Вернуться на главную». Таблица заполнена записями о площадках, имеющихся в БД, упорядоченными по возрастанию кодов площадок. По умолчанию курсор расположен в первом поле в первой записи.

3. Администратор БД выбирает строку с информацией о какой-либо площадке и щелкает кнопку «Редактировать»

А1: Нажатие «Вернуться на главную».

4. Администратор БД вводит необходимую информацию в поле «Название площадки» и нажимает кнопку «Сохранить».

5. Система проверяет правильность введенных данных.

А2: Дублирование названия площадки.

А2.1: Система выводит сообщение об ошибке «Площадка с таким названием уже существует» и устанавливает курсор в поле «Название площадки».

А2.2: Администратор БД редактирует поле «Название площадки».

А2.3: Выполняется пункт 5 основной последовательности.

6. Система сохраняет запись в БД. Вариант использования завершается успешно.

Вариант использования: Формирование отчета о посещаемости на выбранную дату.

Краткое описание: Позволяет Менеджеру системы создавать и просматривать отчеты.

Актант: Менеджер.

Предусловия. Выполнен вариант использования «Создание отчетов» до точки расширения, соответствующей началу создания отчета о посещаемости, в режиме Менеджера. На экране - главное меню системы, настроенное на права Менеджера.

Основной поток событий.

1. Менеджер выбирает подпункт «Отчет о посещаемости».

2. Система выводит страницу для формирования «Отчета о посещаемости». На странице расположены поля «Дата начала», «Дата окончания», кнопка «Сформировать отчет» и кнопка «Вернуться на главную». По умолчанию курсор расположен в первом редактируемом поле.

3. Менеджер заполняет поля «Дата начала», «Дата окончания» и нажимает кнопку «Сформировать отчет».

А1: Нажатие «Вернуться на главную».

4. Система проверяет правильность введенных данных и отправляет запрос. На экране появляется таблица отчета.

А2: Некорректная дата начала и дата окончания.

5. Менеджер просматривает отчет и нажимает кнопку « Вернуться на главную».

6. Система закрывает страницу и переходит на главную страницу. Вариант использования завершается успешно.

Диаграммы классов (class diagram)

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

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

На рисунке 1.6 представлена диаграмма сущностных классов.

На диаграмме классов управления (рисунок 1.7) отображается взаимодействие основных менеджеров, используемых в системе. В данном случае это менеджер приложения и менеджер СУБД.

Рисунок 1.6 - Диаграмма сущностных классов

В ней отражены:

- форма авторизации, позволяющая настроить интерфейс всей системы в соответствии с правами пользователя;

- главная страница приложения, которая даёт пользователю доступ к пунктам меню программного комплекса;

- страницы для редактирования справочников и таблиц;

- страницы отчетов обеспечивает работу системы отчетов программного комплекса;

- форма сообщения об ошибке.

В системе предусмотрены отчеты:

- отчет о посещаемости на выбранную дату.

Рисунок 1.7 - Диаграмма классов управления

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

1.8 Разработка логической структуры базы данных

Уровни представления данных

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

Существует три уровня представления данных:

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

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

3-ий уровень - физический (внутренний), связан со способом фактического хранения данных в физической памяти ЭВМ.

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

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

Выбор модели данных

По способу установления связей между данными СУБД основывается на использовании трёх основных видов модели: иерархической, сетевой или реляционной; на комбинации этих моделей или на некотором их подмножестве. Однако различия между этими моделями постепенно стираются.

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

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

Иерархическая модель данных

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

Сетевая модель данных

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

Рисунок 1.8 - Диаграмма граничных классов

Реляционная модель данных

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

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

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

Работа с базой данных начинается с построения модели. Наиболее распространенной является ER-модель (entity-relationship model). Она удобна при прототипировании (проектировании) информационных систем, баз данных, архитектур компьютерных приложений, и других систем (далее, моделей). С её помощью можно выделить ключевые сущности, присутствующие в модели, и обозначить отношения, которые могут устанавливаться между этими сущностями. Важно отметить что сами отношения также являются сущностями (выделяются в отдельные графические блоки), что позволяет устанавливать отношения на множестве самих отношений. ER-модель является одной из самых простых визуальных моделей данных (графических нотаций).

На рисунке 1.9 представлена логическая структура БД [8] программного комплекса, которая является реализацией диаграммы сущностных классов, представленных на рисунке 1.6.



Рисунок 1.9 - Логическая структура БД

1.9 Выбор технических средств и ресурсный анализ

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

Расчет необходимого объема внешней памяти

Для расчета внешней памяти воспользуемся формулой (1):

, Мбайт

- общий объём внешней памяти;

- объём внешней памяти, требуемый для хранения файлов операционной системы и её нормальной работы;

- объём внешней памяти, требуемый для хранения файлов СУБД;

- объём внешней памяти, требуемый для хранения записей БД и результатов выполнения функций;

- объём внешней памяти, необходимый для хранения информации.

Система работает под управлением операционной системы Linux с использованием MySQL.

= 1500 Мбайт; = 10 Мбайт.

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

Таблица 1.3 - Расчет объёма данных

Таблица БД	Размер записи, байт	Max количество записей	Размер индекса, байт	Итого, байт
Account	88	10000	101	1010000
Area	12	10	14	65000
Subscription	56	100	65	6500
Attendance	56	1000000	65	650000000
Account-Subscription	12	10000	14	140000
Area-Subscription	12	10000	14	140000
Account_Type	12	10000	14	140000
Продолжение таблицы 1.3
User	56	10	65	650
User_Group	12	10	14	140
Итого:	650492290



= 620,35 Мбайт;

= 14 Мбайт.

Сложив данные, получим:

= 1500+10+620,35+14= 2144,35 Мбайт.

Таким образом, для сервера нам потребуется жесткий диск объемом 40 Гб.

Расчет необходимого объема оперативной памяти

Формула, используемая для расчета требуемой оперативной памяти, аналогична формуле (1). Результаты расчета объема кэша для хранения данных в оперативной памяти приведены в таблице 1.4.

Таблица 1.4 - Расчет объема буферизации

Таблица БД	Размер записи, байт	Мах количество записей	Размер индекса, байт	Итого, байт
Account	88	100	101	10100
Area	12	1	14	14
Subscription	56	1	65	65
Attendance	56	1000	65	65000
Account-Subscription	12	1000	14	14000
Area-Subscription	12	1000	14	14000
Account_Type	12	1000	14	14000
User	56	10	65	650
User_Group	12	1	14	14
			Итого:	117843

= 14 Мбайт;

= 0,11 Мбайт;



= 256+10+14+0,11=280,11 Мбайт.

Поскольку оперативная память комплектуется модулями стандартного размера от 128 Мбайт до 4 Гбайт, мы выбираем один модуль на 512 Мбайт для сервера.

Расчеты характеристик для клиента:

= 0 Мбайт;

= 0,11 Мбайт;

= 256+10+0+0,11=264,11 Мбайт.

Поскольку оперативная память комплектуется модулями стандартного размера от 128 Мбайт до 4 Гбайт, мы выбираем один модуль на 512 Мбайт для клиента.

Расчет времени реакции системы

Расчет времени реакции системы должен дать оценку быстродействия системы. Временем реакции системы по какой-либо функции называется время от момента начала запроса на выполнение этой функции от внешнего источника запросов до момента окончания формирования результата по данной функции.

Общее время реакции системы на выполнение запроса рассчитывается по формуле (2):

,

,

,



,

.

- время на ввод входных данных запроса;

- коэффициент ошибок при вводе, для расчетов можно принять равным 1,5;

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

- время ввода одного символа, при ручном вводе с клавиатуры в некоторую экранную форму можно принять в среднем равным 2 с;

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

- количество считываемых физических блоков, зависит от количества обрабатываемых таблиц (файлов) и объема таблиц (файлов);

=0,006 сек - время позиционирования головок дискового накопителя;

=0,001 сек - время считывания физического блока в дисковом накопителе;

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

= 1000 - количество операций высокого уровня, необходимых для формирования результата;

- среднее количество тактов машинных команд на одну операцию, для большинства случаев можно принять = 60;

= 1600*106 - тактовая частота процессора, Гц;

= cредний объем таблицы, байт;

= 5 - количество таблиц, обрабатываемых в запросе;

= 512 байт - объем физического блока носителя, байт;

- время на вывод результата на устройство вывода или отображения, для принтера оценивается отдельно. Для дисплея можно принять 0,5 с. (зависит от видеокарты и дисплея).

Результаты расчета времени реакции системы приведены в таблице 1.5.

Таблица 1.5 - Расчет времени реакции системы

Параметр	Значение
Vтабл=	2048
Nбл=	1600
tввода= (секунд)	5
tсчитыв= (секунд)	11,2
tвычисл= (секунд)	0,00002667
tреакции=(секунд)	16,7

Таким образом, в худшем случае, для полной подготовки и вывода на экран отчета может потребоваться 16,7 секунды, причем основная часть этого времени будет тратиться на работу с запоминающим устройством (итоговое время реакции). В будущем, возможно повысить скорость работы системы за счет оснащения компьютеров новыми дисками SSD.

Скорость передачи данных

7п= Vд / Vпр,

где 7п - скорость передачи данных;

Vд - объем данных;

Vпр - пропускная способность;

Vпр = 56 Кбит/с (как наихудшее соединение);

Vд = 30 символов*2 бита=60бит = 0,06 Кбит;

7п = 0,06 Кбит / 56 Кбит/с = 0,001071 c.

Скорость передачи данных при наихудшем соединении [9] составит 0,001071 c.

Требования к комплексу технических средств

Сервер:

- процессор класса Core2Duo с тактовой частотой 1,8 ГГц и выше;

- рекомендуемый объем оперативного запоминающего устройства (ОЗУ) 512 Мбайт;

- жесткий диск емкостью не менее 40 Гбайт;

- нет требований к производительности графического адаптера.

Клиент:

- процессор класса Core2Duo с тактовой частотой 1,4 ГГц и выше;

- рекомендуемый объем оперативного запоминающего устройства (ОЗУ) 512 Мбайт;

- жесткий диск емкостью не менее 40 Гбайт;

- любой видеоадаптер с возможностью вывода комфортного разрешения для пользования системой - 1024х768.



2. КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

2.1 Описание программной реализации системы

Описание структуры программного обеспечения

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

Рисунок 2.1 - Структура программного обеспечения

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

Описание используемых классов и методов

Используемые классы и методы [11] представлены в таблице 2.1.

Таблица 2.1 - Классы и методы

Модуль	Класс	Описание	Методы класса
fitness	fitnessAccountActions	Страница управления аккаунтами посетителей клуба	actionDefault() actionAdd() actionEdit() actionDelete()
	fitnessAreaActions	Страница управления площадками клуба	actionDefault() actionAdd() actionEdit() actionDelete()
	fitnessReportActions	Страница вывода отчетов	actionDefault() actionVisit()
	fitnessSeasonActions	Страница управления типами абонементов клуба	actionDefault() actionAdd() actionEdit() actionDelete()
	fitnessVisitActions	Страница терминала - вывода и поиска информации о посещении клуба	actionDefault() actionAdd() actionClose()
system	noxModel	Базовый класс для работы с базой данных. Обеспечивает взаимодействие с БД, интуитивно понятный построитель sql-запросов и выборку данных	select() updateByField() deleteByField() where() limit() order() fetch() castFieldValue() getEmptyFields() count() exec()
	noxApplication	Выполняет всю работу по маршрутизации и запуску действий	run() runAction() runRouting()
	noxSystem	Основной класс всей системы, запускает работу всех нужных модулей (подробный листинг модуля представлен в приложении Б)	run() location() autorization() getUser() haveRight() getStatistic()
	noxDbConnector	Класс соединения с базой данных	getConnection() closeAll()
	noxThemeAction	Класс работы с шаблоном и темой оформления. Отвечает за формирование веб-документа	run() addMeta() addMetaKeywords() addMetaDescription() AddJs() AddCss() setTheme()

Физическая схема базы данных

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

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

Таблицы, изображенные на физической схеме:

- Пользователь (содержит данные об аккаунтах пользователей);

- Группа пользователей (содержит связи между пользователями и их правами доступа);

- Посещение (содержит данные о посещении клуба);

- Площадка (содержит название доступных площадок клуба);

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

- Клиент (содержит данные о посетителях клуба);

- Тип_абонемента_Площадка (содержит связи между типами абонементов и доступных для них площадок);

- Клиент_Тип_абонемента(содержит связи между клиентами клуба и привязанными к ним типами абонемента, а также дату приобретения абонемента и время его валидности).

Рисунок 1.2 -Физическая модель БД

Модуль работы с базой данных

Взаимодействие с базой данных осуществляется с помощью встроенных в PHP средств работы с базами данных MySql и встроеннего приложения phpMyAdmin [12]. К преимуществам phpMyAdmin можно отнести свободное распространение, кросс-платформенность (поскольку она устанавливается на веб-сервер, где установлена база данных, то для доступа достаточно иметь браузер), работу с любым количеством баз данных, удобный графический интерфейс для создания и редактирования таблиц, их связей и запросов на выборку, изменение и удаление элементов [13].

2.2 Разработка интерфейсов программы

Вход в систему

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

В зависимости от того, под какими правами вы авторизуетесь:

- администратор;

- менеджер;

вы попадёте в тот или иной интерфейс системы.

Работа с интерфейсом администратора

Рисунок 2.3 - Страница авторизации системы

Интерфейс администратора изображён на рисунке 2.4. В его рамки входит редактирование справочников: абонементов, типов абонементов, площадок. Работа по настройке системы. На странице имеется главное меню с пунктами «Файловый менеджер», «Справочники», «Система», «Пользователи», «Выйти».

Рисунок 2.4 - Интерфейс администратора



Работа со справочниками

Администратору открыт доступ для редактирования всех справочников системы: справочник аккаунтов, справочник типов аккаунтов, справочник площадок.

Для просмотра списка типов абонементов нужно выбрать пункт меню «Справочники > Справочник типов абонементов» (рисунок 2.5). В списке показаны все типы абонементов в системе.

Рисунок 2.5 - Список типов абонементов

Чтобы добавить новый тип абонемента в систему требуется нажать кнопку «Добавить». Далее откроется форма добавления нового типа абонемента (рисунок 2.6).

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

Работа с пользователями



Рисунок 2.6 - Форма добавления нового типа абонемента

Администратор также имеет возможность работать с пользователями системы. Ему доступен список пользователей (рисунок 2.7), форма добавления и редактирования новых пользователей (рисунок 2.8), а также работа с группами пользователей (рисунок 2.9).

Рисунок 2.7 - Список пользователей системы



Рисунок 2.8 - Форма добавления нового пользователя

Рисунок 2.9 - Список типов пользователей

Работа с интерфейсом менеджера

Интерфейс менеджера изображён на рисунке 2.10. В нем имеется доступ к разделам: «Терминал» и «Отчеты».



Рисунок 2.10 - Интерфейс менеджера

Работа с терминалом

Терминал - это система, фиксирующая все посещения финтес-центра. Для управления посещаемостью менеджер выбирает пункт меню «Терминал» (рисунок 2.11).

Рисунок 2.11 - Терминал посещений

Далее администратор нажимает кнопку «Добавить посещение» и попадает на страницу добавления посещения (рисунок 2.12). Система изначально настроена на реальную работу в спортивном центре, поэтому при добавлении посещения автоматически берется текущая дата и время. Это нужно для того, чтобы отслеживать точное время входа посетителя в фитнес-центр.

С помощью кнопки «Закрыть» администратор может закрывать посещения. При этом будет установлена текущая точная дата выхода человека из фитнес-центра.

Рисунок 2.12 - Форма добавления посещения

Регистрация новых клиентов

Менеджер также может регистрировать в базу новых клиентов. На рисунке 2.13 показан список текущих клиентов фитнес-центра. Нажав кнопку «Добавить» менеджер переходит к форме добавления нового клиента (рисунок 2.14), заносит все необходимые данные о клиенте (ФИО, пол, дату рождения, паспортные данные и фотографию). После нажатия кнопки «Добавить» создается новый клиент, которому сразу же присваивается номер ID магнитной карты и выдается реальная пластиковая карточка.



Рисунок 2.13 - Список клиентов фитнес-центра

Рисунок 2.14 - Форма регистрации нового клиента

Отчеты

Менеджеру доступен ряд отчетов, в том числе отчет о посещаемости за месяц (рисунок 2.15), отчет о распределении клиентов по группам в виде диаграммы (рисунок 2.16)...