Дипломная (вкр): Информационная система обслуживания клиентов паспортного стола

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

Таблица 2.9 Характеристика оптимизированной СМО у инспектора

Обозначение

Физический смысл

Формула для вычисления

Результат

Размерность

λ

Интенсивность поступления людей

Исходные данные

20

Человек/час

μ

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

μ=12,048Человек /час



tобс

Время обслуживания одной заявки

Исходные данные

0,167

Часы

Ротк

Вероятность отказа обслуживания человека

Исходные данные

0


ρ

Количество обслуженных заявок в единицу времени n каналами

ρ=1,577Человек



χ

Количество обслуженных заявок в единицу времени одним каналом

χ =0,789Человек



n

Количество каналов

Исходные данные

2

Штуки

Р0

Вероятность простоя системы

P0=0,259



t0

Время простоя системы, возникающее с вероятностью Р0

Р0*Т

0,259

Часы

T

Период

Исходные данные

1

Часы

q

Относительная пропускная способность

q = 1 - Pотк

1

Человек

А

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

A = λ*q

20

Человек/час

z

Среднее число занятых каналов

z = A/μ

1,577

Штук

r

Среднее число заявок в очереди

r = 3,671Человек



k

Среднее число заявок в системе

k = r + z

Человек

tож           Среднее время ожидания в очереди           tож =

0,292Часы



 

tсмо

Среднее время пребывания заявки в СМО (включая время ожидания и время обслуживания)

tсмо = tож + tобс

0,381

Часы


Таблица 2.10 Характеристика оптимизированной СМО у Начальника

Обозначение

Физический смысл

Формула для вычисления

Результат

Размерность

λ

Интенсивность поступления людей

Исходные данные

20

Человек/час

μ

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

μ =12,048Человек /час



tобс

Время обслуживания одной заявки

Исходные данные

0,083

Часы

Ротк

Вероятность отказа обслуживания человека

Исходные данные

0


ρ

Количество обслуженных заявок в единицу времени

ρ =0,83Человек



q

Относительная пропускная способность

q = 1 - Pотк

1

Человек

А

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

A = λ*q

20

Человек

r

Среднее число заявок в очереди

r = ρ2/(1 - ρ), при ρ<1 и r = ρ2/(ρ - 1), при ρ>1

4,052

Человек

k

Среднее число заявок в системе

k = r + ρ

4,882

Человек

tож

Среднее время ожидания в очереди

tож = ρ/μ*( ρ - 1) = ρ2/λ*( ρ - 1)

 0,405

Часы

tсмо

Среднее время пребывания заявки в СМО (включая время ожидания и время обслуживания)

tсмо = tож + tобс

0,488

Часы


Произведем сравнительный анализ одноканальной и 2-канальной СМО и представим его в виде таблицы 11.

Таблица 11 Сравнительный анализ одноканальной и двухканальной СМО

Обозначение

Физический смысл

Результат СМО с одним каналом

Результат СМО с двумя каналами

λ

Интенсивность поступления ЛПГ

20

20

tобс

Время обслуживания одной заявки

0,083

0,083

r

Среднее число заявок в очереди

5

3

k

Среднее число заявок в системе

6

5

tож

Среднее время ожидания в очереди

0,416

0,292

tсмо

Среднее время пребывания заявки в СМО (включая время ожидания и время обслуживания)

0,583

0,381


Вывод: Анализируя полученные результаты, видим что среднее время ожидания человеком обслуживания составляет приблизительно 17 минут, среднее время пребывания его в системе равно приблизительно 22 минуты, а количество человек в очереди свелось к 3. Таким образом, делаем вывод, что проведенный реинжиниринг помог достичь поставленной в дипломной работе задачи, т.е. построение оптимальной модели позволяет уменьшить время обслуживания человека инспектором и тем самым сократить время пребывания человека в УФМС, сократить очередь. Также необходимо теперь разработать автоматизированную систему поддерживающую работу инспектора для этого необходимо сформировать функциональные требования к системе.

2.4    Функциональные требования к информационной системе поддержки паспортного контроля на границе


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

.Единое централизованное хранилище всей информации включая:

·        справочники сотрудников;

·        справочники лиц желающих получить обслуживание;

·        справочники лиц, которым запрещено нахождение на территории РФ;

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

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

·        Проверка на разрешения нахождения на территории РФ;

·        Определение вида документа;

·        Фиксация всех необходимых отметок;

·        Занесение информации в центральное хранилище данных.

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

.1      Выбор архитектуры информационной системы в соответствии с выявленными функциональными требованиями

.1.1   Архитектура файл-сервер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: https://www.bibliofond.ru/detail.aspx?id=783958