Таблица 2.9 Характеристика оптимизированной СМО у инспектора
|
Обозначение |
Физический смысл |
Формула для вычисления |
Результат |
Размерность |
|
λ |
Интенсивность поступления людей |
Исходные данные |
20 |
Человек/час |
|
μ |
Интенсивность обслуживания |
μ= |
|
|
|
tобс |
Время обслуживания одной заявки |
Исходные данные |
0,167 |
Часы |
|
Ротк |
Вероятность отказа обслуживания человека |
Исходные данные |
0 |
|
|
ρ |
Количество обслуженных заявок в единицу времени n каналами |
ρ= |
|
|
|
χ |
Количество обслуженных заявок в единицу времени одним каналом |
χ
= |
|
|
|
n |
Количество каналов |
Исходные данные |
2 |
Штуки |
|
Р0 |
Вероятность простоя системы |
P0= |
|
|
|
t0 |
Время простоя системы, возникающее с вероятностью Р0 |
Р0*Т |
0,259 |
Часы |
|
T |
Период |
Исходные данные |
1 |
Часы |
|
q |
Относительная пропускная способность |
q = 1 - Pотк |
1 |
Человек |
|
А |
Абсолютная пропускная способность - среднее число заявок, которое может обслужить система в единицу времени |
A = λ*q |
20 |
Человек/час |
|
z |
Среднее число занятых каналов |
z = A/μ |
1,577 |
Штук |
|
r |
Среднее число заявок в очереди |
r = |
|
|
|
k |
Среднее число заявок в системе |
k = r + z |
Человек |
tож Среднее
время ожидания в очереди tож = ![]()
|
0,292Часы |
|
|
|
|
|
tсмо |
Среднее время пребывания заявки в СМО (включая время ожидания и время обслуживания) |
tсмо = tож + tобс |
0,381 |
Часы |
Таблица 2.10 Характеристика оптимизированной СМО у Начальника
|
Обозначение |
Физический смысл |
Формула для вычисления |
Результат |
Размерность |
|
λ |
Интенсивность поступления людей |
Исходные данные |
20 |
Человек/час |
|
μ |
Интенсивность обслуживания |
μ = |
|
|
|
tобс |
Время обслуживания одной заявки |
Исходные данные |
0,083 |
Часы |
|
Ротк |
Вероятность отказа обслуживания человека |
Исходные данные |
0 |
|
|
ρ |
Количество обслуженных заявок в единицу времени |
ρ = |
|
|
|
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. Таким образом, делаем вывод, что проведенный реинжиниринг
помог достичь поставленной в дипломной работе задачи, т.е. построение
оптимальной модели позволяет уменьшить время обслуживания человека инспектором
и тем самым сократить время пребывания человека в УФМС, сократить очередь.
Также необходимо теперь разработать автоматизированную систему поддерживающую
работу инспектора для этого необходимо сформировать функциональные требования к
системе.
В соответствии с проведенным анализом предметной области и построенным моделям автоматизированная информационная система обслуживания клиентов паспортного стола должна обладать следующими возможностями:
.Единое централизованное хранилище всей информации включая:
· справочники сотрудников;
· справочники лиц желающих получить обслуживание;
· справочники лиц, которым запрещено нахождение на территории РФ;
· справочник возможных документов;
.Автоматизированное рабочее место инспектора с возможностью внесения информации в единое централизованное хранилище информации, должно реализовывать следующие функции:
· Проверка на разрешения нахождения на территории РФ;
· Определение вида документа;
· Фиксация всех необходимых отметок;
· Занесение информации в центральное хранилище данных.
Архитектура файл-сервер не имеет сетевого разделения компонентов и использует клиентский компьютер для выполнения функций диалога и обработки данных, что облегчает построение графического интерфейса. Файл-сервер только извлекает данные из файлов, так что дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на центральный процессор. Каждый новый клиент добавляет вычислительную мощность к вычислительной сети.
Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логики обработки BLи управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интерпретации.
Однако такая архитектура имеет существенный недостаток: при выполнении
некоторых запросов к базе данных клиенту могут передаваться большие объемы
данных, которые загружают сеть и приводят к непредсказуемому времени реакции.
Значительный сетевой трафик особенно сильно сказывается при организации
удаленного доступа к базам данных на файл-сервере через низкоскоростные каналы
связи. Одним из вариантов устранения данного недостатка является удаленное
управление файл-серверным приложением в сети. При этом в локальной сети
размещается сервер приложений, совмещенный с телекоммуникационным сервером
(обычно называемым сервером доступа), в среде которого выполняются обычные
файл-серверные приложения. Особенность такой организации состоит в том, что
диалоговый ввод-вывод поступает от удаленных клиентов через телекоммуникации.
Приложения не должны быть слишком сложными, иначе велика вероятность перегрузки
сервера, или же нужна очень мощная платформа для сервера приложений.
Архитектура клиент-сервер предназначена для разрешения проблем файл-серверной архитектуры путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (StructuredQueryLanguage) и выполняющих поиск, сортировку и агрегирование информации. Отличительная черта серверов БД - наличие справочника данных, в котором записана структура БД, ограничения целостности данных, форматы и даже серверные процедуры обработки данных по вызову или по событиям в программе. Объектами разработки в таких приложениях помимо диалога и логики обработки являются, прежде всего, реляционная модель данных и связанный с ней набор SQL-операторов для типовых запросов к базе данных.
Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логики BL и DL - на клиенте. Двухуровневая архитектура клиент-сервер использует именно этот вариант: приложение работает на клиенте, СУБД - на сервере (см. рис. 3.1).
Рис.
3.1 Классический вариант клиент-серверной информационной системы
Поскольку эта архитектура предъявляет наименьшие требования к серверу, она обладает наилучшей масштабируемостью. Однако сложные приложения, вызывающие большое взаимодействие с БД, могут жестко загрузить как клиента, так и сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, потому что там находится логика принятия решения. Такая схема приводит к дополнительному усложнению администрирования приложений, разбросанных по различным клиентским узлам.
Для сокращения нагрузки на сеть и упрощения администрирования приложений компонент BL можно разместить на сервере. При этом вся логика принятия решений оформляется в виде хранимых процедур и выполняется на сервере БД. Хранимая процедура - процедура с операторами SQL для доступа к БД, вызываемая по имени с передачей требуемых параметров и выполняемая на сервере БД. Хранимые процедуры могут компилироваться, что повышает скорость их выполнения и сокращает нагрузку на сервер.
Хранимые процедуры улучшают целостность приложений и БД, гарантируют актуальность коллективно используемых операций и вычислений. Улучшается сопровождение таких процедур, а также безопасность данных (нет прямого доступа к данным).
Создание архитектуры клиент-сервер возможно и на основе многотерминальной системы. В этом случае в многозадачной среде сервера приложений выполняются программы пользователей, а клиентские узлы вырождены и представлены терминалами. Подобная схема информационной системы характерна для UNIX. В настоящее время архитектура клиент-сервер получила признание и широкое распространение как способ организации приложений для рабочих групп и информационных систем корпоративного уровня. Подобная организация работы повышает эффективность выполнения приложений за счет использования возможностей сервера БД, разгрузки сети и обеспечения контроля целостности данных.
Двухуровневые схемы архитектуры клиент-сервер могут привести к некоторым
проблемам в сложных информационных приложениях с множеством пользователей и
запутанной логикой. Решением этих проблем может стать использование
многоуровневой архитектуры.
Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в классической форме состоит из трех уровней (см. рис. 3.2)
- нижний уровень представляет собой приложения клиентов, выделенные для выполнения функций и логики представлений PS и PL и имеющие программный интерфейс для вызова приложения на среднем уровне;
- средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика BL и с которого логика обработки данных DL вызывает операции с базой данных DS;
- верхний уровень представляет собой удаленный специализированный сервер базы данных, выделенный для услуг обработки данных DS и файловых операций FS(без использования хранимых процедур).