Разработка архитектуры системы

Выбор архитектуры Наличие таких требований как:

• — возможность доступа к системе через Интернет;
• — обеспечение одновременной работы большого числа пользователей;
• — наличие удобного пользовательского интерфейса;
• — возможность работы под управлением операционных систем Windows, Unix

делает наиболее приемлемой трехзвенную архитектуру с «тонким клиентом», работающим в среде Web-браузера (Интернет). Так как в противном случае клиенту пришлось бы устанавливать на компьютер большое количество ресурсоемкого программного обеспечения, что доставляло бы пользователям большие неудобства.

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

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

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

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

Обоснование выбора СУБД На самом общем уровне все СУБД можно разделить:

• — на профессиональные (промышленные);
• — персональные (настольные).

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

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

В настоящее время характерными представителями профессиональных СУБД являются такие программные продукты, как Oracle, DB2, Sybase, Informix, Ingres, Progress.

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

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

Среди СУБД, которые, условно говоря, занимают промежуточное положение между настольными и промышленными системами, могут быть названы SQLWindows/ SQLBase фирмы Centura (до 1996 г. Gupta), InterBase (Borland), Microsoft SQL Server. В применении к данной выпускной работе сравним наиболее популярные на сегодняшний день СУБД Oracle, MsAccess, MsSQL. Окончательный вариант сравнения приведен в Таблице 7.

Таблица 7 Критерии выбора СУБД.

<…

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

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

Расчет модели системы Зададим начальные значения:

• — время задержки в канале связи «пользователь — сервер приложений» без учета фонового потока заявок — ;
• — время обработки запроса сервером приложений без учета фонового потока заявок от пользователей системы — ;
• — время задержки в канале связи «сервер приложений — сервер баз данных» без учета фонового потока заявок — ;
• — время обработки запроса сервером баз данных без учета фонового потока заявок — ;
• — среднее значение времени дообработки на рабочей станции сети запроса от этой станции к серверу приложений или серверу баз данных — ;
• — среднее значение времени формирования запроса на рабочей станции сети к серверу приложений или серверу баз данных — ;
• — вероятность обслуживания запроса на сервере баз данных — ;
• — вероятность дообслуживания удаленного запроса на сервере баз данных — ;
• — число параллельно обрабатываемых заявок на сервере приложений — ;
• — число параллельно обрабатываемых заявок на сервере баз данных — ;
• — количество пользователей

.

Используя выражения для основных величин (7) — (12), описанные в пункте 1.2.5.2. настоящего документа, исследуем зависимость времени реакции системы от количества пользователей при заданных начальных условиях. В качестве программного обеспечения для проведения расчетов и построения графиков используем пакет Maple V Release 10.

Результаты проведенных расчетов сведем в Таблицу 12.

Таблица 12 Результаты аналитического моделирования системы, полученные при расчетах с использованием среды Maple V Release 10.

Параметры сравнения.	Варианты сравнения СУБД.
MsSQL.	Oracle.	MsAccess.
Простота организации интерфейса.	Отлично.	Хорошо.	Очень хорошо.
Поддержка серверов.	Удовл.	Отлично.	Отлично.
Безопасность.	Хорошо.	Очень хорошо.	Хорошо.

	0.02.	0.20.	0.10.	0.30.	0.65.
	0.02.	0.20.	0.10.	0.35.	0.7.
	0.02.	0.20.	0.11.	0.49.	0.85.
	0.02.	0.20.	0.11.	2.14.	2.5.
	0.02.	0.20.	0.15.	5.17.	5.57.
	0.02.	0.20.	0.18.	7.52.	7.95.
	0.02.	0.20.	0.18.	11.92.	12.35.
	0.02.	0.20.	0.18.	20.11.	20.54.
	0.02.	0.20.	0.20.	33.39.	33.84.
	0.02.	0.20.	0.20.	48.05.	48.5.

На рисунке 1.2.5.3.1 приведен полученный график зависимости времени реакции от числа пользователей системы.

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

• — увеличение мощности ресурсов (новое оборудование);
• — программная оптимизация приложения (оптимизация запросов, внутрисистемных протоколов и т. п.)