Материал: Система поддержки принятия инвестиционных решений малого предприятия. Баркалов С.А., Морозов В.П

- невысокими требованиями к аппаратной платформе;

- более эффективной реализацией сетевого обмена данными (применение беспроводной технологии сетевого обмена данными IEEE 802.11).

Учитывая тот факт, что ОС Windows XP в настоящее время не поддерживается, в рамках разработанного прототипа использована Windows 7.

4.2.2. Выбор технологической среды реализации

Важное значение при выборе технологической среды реализации прикладного программного обеспечения имел тот факт, что разрабатываемое АРМ является интегрированной информационной системой. При ее реализации одним из важных вопросов является организация взаимодействия модулей друг с другом и с хранилищами информации. В рамках данной системы реализовано взаимодействие модулей через данные. Результаты работы одного модуля в виде данных записываются в БД. Для другого модуля эти данные являются входными. Взаимодействие через данные требует их унификации (единого формата хранения и языка запросов к БД). Для унификации формата хранения данных использована технология DCOM [101, 126]. Исходным представителем данной технологии является платформа «клиент-сервер» [32, 38, 103, 126]. В рамках данной платформы, на верхнем уровне размещается сервер баз данных. В нем хранятся данные. Нижний уровень представлен клиентскими приложениями, которые используют эти данные в работе. Кроме того, в приложениях реализована бизнес-логика работы с данными, а также проверка их на достоверность и непротиворечивость [28, 126]. Подобные приложения называют «толстыми клиентами» [63]. Реализованное прикладное программное обеспечение базируется на более совершенной платформе - трехуровневой архитектуре «клиент-сервер» [32] (рис. 4.2).

В данной платформе уровни иерархии размещены по схеме: «сервер БД - сервер приложений - клиент». Особенностью данной платформы является тот факт, что процедуры, реализующие доступ к данным и их обработку, перенесены из клиентского приложения в сервер приложений (т. е на отдельный уровень). Данную архитектуру называют «тонкий клиент» [28, 32]. Механизм функционирования данной платформы заключается в следующем. На верхнем уровне находится удаленный сервер баз данных. Он обеспечивает хранение и управление данными. На среднем уровне (middle ware) находится сервер приложений. В сервере приложений содержатся средства и код, общие для всех клиентских приложений, в частности средства доступа к БД. Он обеспечивает соединение клиентов с сервером БД и реализует бизнес-логику. На нижнем уровне находятся клиентские приложения. Пользователь запускает клиентское приложение. Оно соединяется с доступным ему сервером приложений. Затем клиент запрашивает какие-то данные. Этот запрос упаковывается в пакет установленного формата и передается серверу приложений. Там пакет распаковывается и передается серверу БД, который возвращает затребованные данные. Сервер приложений обрабатывает эти данные согласно заложенной в него бизнес-логике, упаковывает и передает этот пакет клиенту. Клиент распаковывает данные и использует их в своей работе. Если данные изменены пользователем, то цепочка их передачи на сервер БД выглядит следующим образом. Клиент упаковывает измененные данные и отправляет пакет на сервер приложений. Тот распаковывает их и отправляет на сервер БД. Если все исправления могут быть без осложнений занесены в БД, то на этом все завершается. Если возникли осложнения (например, сделанные изменения противоречат бизнес-правилам или в результате изменения одних и тех же данных разными пользователями возникли противоречия), то проблемные записи, возвращаются клиенту. Далее пользователь принимает решение, что с ними делать (исправить или отказаться).

Основными достоинствами такой архитектуры являются:

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

- уменьшение размера клиентских приложений за счет разгрузки их от лишнего кода;

- единое поведение всех клиентов;

- упрощение настройки клиентов – при изменении общего кода сервера приложений автоматически изменяется поведение приложений - клиентов.

4.2.3. Выбор среды разработки программного обеспечения

В качестве интегрированной среды разработки специального программного обеспечения использована система визуального объектно-ориентированного программирования Delphi 7 [9, 10, 12, 21, 103, 132]. Borland Delphi — это объектно-ориентированная среда визуального программирования (RAD — Rapid Application Development). Она предназначена для ускоренной разработки высокопроизводительных 32-битных приложений, которые могут работать в среде Windows или Linux. При этом Delphi позволяет свести к минимуму объем вводимого вручную программного кода. В состав Delphi входят средства, необходимые для разработки, тестирования и установки приложений, включая обширную библиотеку компонентов (VCL — Visual Components Library), средства визуального проектирования, шаблоны приложений и форм, а также различные мастера [9, 103, 141].

Достоинствами среды Delphi являются [10, 53, 141]:

- оперативность и простота разработки программ и оконного интерфейса;

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

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

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

- возможность формирования и печати отчётов на основе специализированных шаблонов;

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

4.3. Выбор системы управления базой данных автоматизированного рабочего места

Система управления базами данных (Database Management System — DBMS) представляет собой программное обеспечение, которое управляет доступом к соответствующей базе данных [52, 125, 134].

При выборе СУБД сравнивались следующие характеристики:

- оперативность;

- отказоустойчивость;

- требования к аппаратной платформе;

- переносимость;

- масштабируемость;

- наличие ODBC драйверов;

- простота администрирования СУБД.

При выборе сравнивались следующие СУБД: MS SQL Server 2000; Oracle 9i; Paradox; Access.

Microsoft SQL Server 2000 – система управления базами данных, способная, как и Oracle, эксплуатироваться в условиях большого количества активных сессий и открытых курсоров [24, 69, 71]. Она обладает возможностью работать с большими объёмами данных. Среди сравниваемых СУБД, ее оперативность занимает среднее положение. Данная СУБД обладает достаточно высокой отказоустойчивостью. MS SQL Server также обладает всеми необходимыми инструментами администрирования СУБД [8, 111]. При этом, непосредственно процедура администрирования является сложной. Недостатком СУБД MS SQL Server является ее привязанность к операционной системе и аппаратной платформе. У данной СУБД достаточно высокие требования к аппаратным ресурсам и низкая переносимость. ODBC драйверы имеются [2].

Oracle 9i – подходит для решения практически любых поставленных задач в области разработки и эксплуатации информационных систем [82, 128, 142]. Она одна из наиболее мощных существующих на сегодняшний день промышленных СУБД. У нее богатый набор инструментальных средств администрирования СУБД и оптимизации физической и логической структур баз данных [82]. Обладает возможностью работать с большими объёмами данных с приемлемой оперативностью [142]. В плане отказоустойчивости данная СУБД занимает достойное место. Недостатки Oracle 9i: высокие требования, предъявляемые к администратору баз данных как в части общетехнической подготовки, так и в части глубокого знания принципов функционирования СУБД Oracle; требовательность к аппаратным ресурсам; сложность в реализации и ресурсоемкость; низкая переносимость.

Paradox – достаточно оперативная и простая в использовании СУБД. Она обладает невысокими требованиями к аппаратной платформе и достаточно высокой отказоустойчивостью [51]. Набор ODBC драйверов имеется. Даная СУБД широко используется в небольших информационных системах Недостаток - работает оперативно лишь с небольшими объемами данных.

4.4. Алгоритм обмена данными между бд

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

Блоки 1,8 используются для пуска и остановки процесса обмена данными.

В блоке 2 реализован ввод исходных данных, таких как значение верхнего уровня объема данных ОБД; значение нижнего уровня объема данных ОБД. Запуск и остановка процедуры перемещения данных реализуется в соответствии со следующими критериями:

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

• система перемещения данных из ОБД в ДБД прекращает работу, когда

общий объем хранимых в ОБД данных становится меньшим, чем нижний допустимый уровень.

Блок 3 используется для проверки состояния загруженности ОБД. Если ОБД не загружено, то осуществляется переход к блоку 5. В противном случае управление переходит к блоку 4.

Блок 4 реализует архивацию и перемещение данных из ОБД в ДБД.

В блоке 5 реализован поиск данных, запрашиваемых пользователем. Если они содержатся в ОБД, то осуществляется их непосредственная загрузка и дальнейшая работа с ними. В случае их размещения в ДБД управление передается блоку 6.

Блок 6 используется для поиска запрашиваемых данных в ДБД. В случае их наличия, последние перемещаются из ДБД в ОБД, распаковываются (разархивируются) и предоставляются пользователю для дальнейшей работы.

Блок 7 реализует запись полученных оперативных данных в ОБД.

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

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

, (4.1)

где Nⁱ - полное количество запросов на i - й набор данных, - время поступления данных в архив, - время поступления Nⁱ -го запроса. Вероятность поступления запроса на i - й набор данных при интенсивности потока заказов в момент времени определяется выражением (вероятность единичного события на интервале ) [1]