Система управления базой данных объектов гражданской обороны для принятия решений в чрезвычайной ситуации (Диплом)



РУБРИКИ	Система управления базой данных объектов гражданской обороны для принятия решений в чрезвычайной ситуации (Диплом)	РЕКОМЕНДУЕМ

Главная

Валютные отношения

Ветеринария

Астрономия и космонавтика

Банковское биржевое дело

Безопасность жизнедеятельности

Биология и естествознание

Бухгалтерский учет и аудит

Военное дело и гражд. оборона

Макроэкономика экономическая

Маркетинг

Международные экономические и

Менеджмент

Микроэкономика экономика

ПОИСК

Система управления базой данных объектов гражданской обороны для принятия решений в чрезвычайной ситуации (Диплом)

| |Служба безопасности: поддерживает электронную подпись|

| |(собственный алгоритм), избирательные права доступа, |

| |шифрацию; не сертифицирована |

| |Простое обслуживание |

| |Хорошо масштабируется |

| |Отличная производительность обмена данными между |

| |серверами, хуже - при обмене сервер-ПК |

|Microsoft |Серверные платформы: компьютеры на базе процессоров |

|Windows NT|Intel, |

|Server |PowerPC, DEC Alpha, MIPS |

|3.51 и 4.0|Клиентские платформы: DOS, OS/2, Windows, Windows for|

| |Workgroups, Macintosh |

| |Организация одноранговой сети возможна с помощью |

| |Windows NT Workstation и Windows for Workgroups |

| |Windows NT Server представляет собой отличный сервер |

| |приложений: он поддерживает вытесняющую |

| |многозадачность, виртуальную память и симметричное |

| |мультипроцессирование, а также прикладные среды DOS, |

| |Windows, OS/2, POSIX |

| |Справочные службы: доменная для управления учетной |

| |информацией пользователей (Windows NT Domain |

| |Directory service), справочные службы имен WINS и DNS|

| | |

| |Хорошая поддержка совместной работы с сетями NetWare:|

| |поставляется клиентская часть (редиректор) для |

| |сервера NetWare (версий 3.х и 4.х в режиме эмуляции |

| |3.х, справочная служба NDS поддерживается, начиная с |

| |версии 4.0), выполненная в виде шлюза в Windows NT |

| |Server или как отдельная компонента для Windows NT |

| |Workstation; недавно Microsoft объявила о выпуске |

| |серверной части NetWare как оболочки для Windows NT |

| |Server |

| |Служба обработки сообщений - Microsoft Mail |

| |NT - Microsoft Message Exchange, интегрированная с |

| |остальными службами Windows NT Server |

| |Поддерживаемые сетевые протоколы: TCP/IP, IPX/SPX, |

| |NetBEUI, Appletalk |

| |Поддержка удаленных пользователей: ISDN, |

| |коммутируемые телефонные линии, frame relay, X.25 - с|

| |помощью встроенной подсистемы Remote Access Server |

| |(RAS) |

| |Служба безопасности: мощная, использует избирательные|

| |права доступа и доверительные отношения между |

| |доменами; узлы сети, основанные на Windows NT Server,|

| |сертифицированы по уровню C2 |

| |Простота установки и обслуживания |

| |Отличная масштабируемость |

|IBM LAN |Серверные платформы: операционные системы MVS и VM |

|Server 4.0|для мейнфреймов; AS/400 с OS/400, рабочие станции |

| |RS/6000 с AIX, серверы Intel 486 или Pentium под OS/2|

| | |

| |Поставляется с оболочками для клиентов: DOS, |

| |Macintosh, OS/2, Windows, Windows NT, Windows for |

| |Workgroups |

| |Серверы приложений могут быть организованы с помощью |

| |LAN Server 4.0 в операционных средах MVS, VM, AIX, |

| |OS/2, OS/400. В среде OS/2 поддерживаются: |

| |вытесняющая многозадачность, виртуальная память и |

| |симметричное мультипроцессирование |

| |Организация одноранговых связей возможна с помощью ОС|

| |Warp Connect |

| |Справочная служба - LAN Server Domain, то есть основа|

| |на доменном подходе |

| |Поддерживаемые сетевые протоколы: TCP/IP, NetBIOS, |

| |Appletalk |

| |Безопасность - избирательные права доступа, система |

| |не сертифицирована |

| |Служба обработки сообщений - отсутствует |

| |Высокая производительность |

| |Недостаточная масштабируемость |

3. ВЫБОР БАЗЫ ДАННЫХ

3.1. Определение СУБД

Традиционных возможностей файловых систем недостаточно для построения

даже простых информационных систем из-за возникающих потребностей, которые

не покрываются возможностями систем управления файлами:

. поддержание логически согласованного набора файлов;

. обеспечение языка манипулирования данными;

. восстановление информации после разного рода сбоев;

. реально параллельная работа нескольких пользователей.

Можно считать, что если прикладная информационная система опирается на

некоторую систему управления данными, обладающую этими свойствами, то эта

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

(СУБД).

3.2. Основные функции СУБД

Более точно, к числу функций СУБД принято относить следующие:

3.2.1. Непосредственное управление данными во внешней памяти

Эта функция включает обеспечение необходимых структур внешней памяти

как для хранения данных, непосредственно входящих в БД, так и для служебных

целей, например, для убыстрения доступа к данным в некоторых случаях

(обычно для этого используются индексы). В некоторых реализациях СУБД

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

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

СУБД пользователи в любом случае не обязаны знать, использует ли СУБД

файловую систему, и если использует, то как организованы файлы. В

частности, СУБД поддерживает собственную систему именования объектов БД.

3.2.2. Управление буферами оперативной памяти

СУБД обычно работают с БД значительного размера; по крайней мере этот

размер обычно существенно больше доступного объема оперативной памяти.

Понятно, что если при обращении к любому элементу данных будет

производиться обмен с внешней памятью, то вся система будет работать со

скоростью устройства внешней памяти. Практически единственным способом

реального увеличения этой скорости является буферизация данных в

оперативной памяти. При этом, даже если операционная система производит

общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для

целей СУБД, которая располагает гораздо большей информацией о полезности

буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается

собственный набор буферов оперативной памяти с собственной дисциплиной

замены буферов.

3.2.3. Управление транзакциями

Транзакция - это последовательность операций над БД, рассматриваемых

СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД

фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней

памяти, либо ни одно из этих изменений никак не отражается на состоянии БД.

Понятие транзакции необходимо для поддержания логической целостности БД.

Таким образом, поддержание механизма транзакций является обязательным

условием даже однопользовательских СУБД (если, конечно, такая система

заслуживает названия СУБД). Но понятие транзакции гораздо более важно в

многопользовательских СУБД.

То свойство, что каждая транзакция начинается при целостном состоянии

БД и оставляет это состояние целостным после своего завершения, делает

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

пользователя по отношению к БД. При соответствующем управлении параллельно

выполняющимися транзакциями со стороны СУБД каждый из пользователей может в

принципе ощущать себя единственным пользователем СУБД (на самом деле, это

несколько идеализированное представление, поскольку в некоторых случаях

пользователи многопользовательских СУБД могут ощутить присутствие своих

коллег).

С управлением транзакциями в многопользовательской СУБД связаны важные

понятия сериализации транзакций и сериального плана выполнения смеси

транзакций. Под сериализаций параллельно выполняющихся транзакций

понимается такой порядок планирования их работы, при котором суммарный

эффект смеси транзакций эквивалентен эффекту их некоторого

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

это такой план, который приводит к сериализации транзакций. Понятно, что

если удается добиться действительно сериального выполнения смеси

транзакций, то для каждого пользователя, по инициативе которого образована

транзакция, присутствие других транзакций будет незаметно (если не считать

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

Существует несколько базовых алгоритмов сериализации транзакций. В

централизованных СУБД наиболее распространены алгоритмы, основанные на

синхронизационных захватах объектов БД. При использовании любого алгоритма

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

транзакциями по доступу к объектам БД. В этом случае для поддержания

сериализации необходимо выполнить откат (ликвидировать все изменения,

произведенные в БД) одной или более транзакций. Это один из случаев, когда

пользователь многопользовательской СУБД может реально (и достаточно

неприятно) ощутить присутствие в системе транзакций других пользователей.

3.2.4. Журнализация

Одним из основных требований к СУБД является надежность хранения

данных во внешней памяти. Под надежностью хранения понимается то, что СУБД

должна быть в состоянии восстановить последнее согласованное состояние БД

после любого аппаратного или программного сбоя. Обычно рассматриваются два

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

трактовать как внезапную остановку работы компьютера (например, аварийное

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

носителях внешней памяти. Примерами программных сбоев могут быть: аварийное

завершение работы СУБД (по причине ошибки в программе или в результате

некоторого аппаратного сбоя) или аварийное завершение пользовательской

программы, в результате чего некоторая транзакция остается незавершенной.

Первую ситуацию можно рассматривать как особый вид мягкого аппаратного

сбоя; при возникновении последней требуется ликвидировать последствия

только одной транзакции.

Понятно, что в любом случае для восстановления БД нужно располагать

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

надежности хранения данных в БД требует избыточности хранения данных,

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

храниться особо надежно. Наиболее распространенным методом поддержания

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

Журнал - это особая часть БД, недоступная пользователям СУБД и

поддерживаемая с особой тщательностью (иногда поддерживаются две копии

журнала, располагаемые на разных физических дисках), в которую поступают

записи обо всех изменениях основной части БД. В разных СУБД изменения БД

журнализуются на разных уровнях: иногда запись в журнале соответствует

некоторой логической операции изменения БД (например, операции удаления

строки из таблицы реляционной БД), иногда - минимальной внутренней операции

модификации страницы внешней памяти; в некоторых системах одновременно

используются оба подхода.

Во всех случаях придерживаются стратегии "упреждающей" записи в журнал

(так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта

стратегия заключается в том, что запись об изменении любого объекта БД

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

попадет во внешнюю память основной части БД. Известно, что если в СУБД

корректно соблюдается протокол WAL, то с помощью журнала можно решить все

проблемы восстановления БД после любого сбоя.

Самая простая ситуация восстановления - индивидуальный откат

транзакции. Строго говоря, для этого не требуется общесистемный журнал

изменений БД. Достаточно для каждой транзакции поддерживать локальный

журнал операций модификации БД, выполненных в этой транзакции, и

производить откат транзакции путем выполнения обратных операций, следуя от

конца локального журнала. В некоторых СУБД так и делают, но в большинстве

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

выполняют по общесистемному журналу, для чего все записи от одной

транзакции связывают обратным списком (от конца к началу).

При мягком сбое во внешней памяти основной части БД могут находиться

объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и

могут отсутствовать объекты, модифицированные транзакциями, которые к

моменту сбоя успешно завершились (по причине использования буферов

оперативной памяти, содержимое которых при мягком сбое пропадает). При

соблюдении протокола WAL во внешней памяти журнала должны гарантированно

находиться записи, относящиеся к операциям модификации обоих видов

объектов. Целью процесса восстановления после мягкого сбоя является

состояние внешней памяти основной части БД, которое возникло бы при

фиксации во внешней памяти изменений всех завершившихся транзакций и

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

чтобы этого добиться, сначала производят откат незавершенных транзакций

(undo), а потом повторно воспроизводят (redo) те операции завершенных

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

Для восстановления БД после жесткого сбоя используют журнал и архивную

копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту

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

смысла архивной копии). Конечно, для нормального восстановления БД после

жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к

сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные

требования. Тогда восстановление БД состоит в том, что исходя из архивной

копии по журналу воспроизводится работа всех транзакций, которые

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

незавершенных транзакций и продолжить их работу после завершения

восстановления. Однако в реальных системах это обычно не делается,

поскольку процесс восстановления после жесткого сбоя является достаточно

длительным.

3.2.5. Поддержка языков БД

Для работы с базами данных используются специальные языки, в целом

называемые языками баз данных. В ранних СУБД поддерживалось несколько

специализированных по своим функциям языков. Чаще всего выделялись два

языка - язык определения схемы БД (SDL - Schema Definition Language) и язык

манипулирования данными (DML - Data Manipulation Language). SDL служил

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

БД, какой она представляется пользователям. DML содержал набор операторов

манипулирования данными, т.е. операторов, позволяющих заносить данные в БД,

удалять, модифицировать или выбирать существующие данные.

В современных СУБД обычно поддерживается единый интегрированный язык,

содержащий все необходимые средства для работы с БД, начиная от ее

создания, и обеспечивающий базовый пользовательский интерфейс с базами

данных. Стандартным языком наиболее распространенных в настоящее время

реляционных СУБД является язык SQL (Structured Query Language).

Прежде всего, язык SQL сочетает средства SDL и DML, т.е. позволяет

определять схему реляционной БД и манипулировать данными. При этом

именование объектов БД (для реляционной БД - именование таблиц и их

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

языка SQL производит преобразование имен объектов в их внутренние

идентификаторы на основании специально поддерживаемых служебных таблиц-

каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц

и их столбцов.

Язык SQL содержит специальные средства определения ограничений

целостности БД. Опять же, ограничения целостности хранятся в специальных

таблицах-каталогах, и обеспечение контроля целостности БД производится на

языковом уровне, т.е. при компиляции операторов модификации БД компилятор

SQL на основании имеющихся в БД ограничений целостности генерирует

соответствующий программный код.

Специальные операторы языка SQL позволяют определять так называемые

представления БД, фактически являющиеся хранимыми в БД запросами

(результатом любого запроса к реляционной БД является таблица) с

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

таблицей, как любая базовая таблица, хранимая в БД, но с помощью

представлений можно ограничить или наоборот расширить видимость БД для

конкретного пользователя. Поддержание представлений производится также на

языковом уровне.

Наконец, авторизация доступа к объектам БД производится также на

основе специального набора операторов SQL. Идея состоит в том, что для

выполнения операторов SQL разного вида пользователь должен обладать

различными полномочиями. Пользователь, создавший таблицу БД, обладает

полным набором полномочий для работы с этой таблицей. В число этих

полномочий входит полномочие на передачу всех или части полномочий другим

пользователям, включая полномочие на передачу полномочий. Полномочия

пользователей описываются в специальных таблицах-каталогах, контроль

полномочий поддерживается на языковом уровне.

3.3. Варианты построения информационных приложений с использованием СУБД

Групповые и корпоративные информационные системы и соответствующие

приложения могут строиться различными способами:

. многотерминальные централизованные вычислительные системы;

. системы на основе локальной сети ПК (файл-серверные приложения);

. системы с архитектурой клиент-сервер;

Для лучшего понимания ограничений различных архитектур информационных

систем, разделим приложения на типовые.

Типовые компоненты информационных приложений

Выделим в информационном приложении типовые функциональные компоненты,

достаточные для формирования любого приложения на основе БД.

PS (Presentation Services) - средства представления. Обеспечиваются

устройствами, принимающими ввод от пользователя и отображающим то, что

сообщает ему компонент логики представления PL, плюс соответствующая

программная поддержка. Может быть текстовым терминалом или Х-терминалом, а

также ПК или рабочей станцией в режиме программной эмуляции терминала или Х-

терминала.

PL (Presentation Logic) - логика представления. Управляет

взаимодействием между пользователем и ЭВМ. Обрабатывает действия

пользователя по выбору альтернативы меню, по нажатию кнопки или при выборе

элемента из списка.

BL (Business or Application Logic) - прикладная логика. Набор правил

для принятия решений, вычислений и операций, которые должно выполнить

приложение.

DL (Data Logic) - логика управления данными. Операции с базой данных

(SQL-операторы SELECT, UPDATE и INSERT), которые нужно выполнить для

реализации прикладной логики управления данными.

DS (Data Services) - операции с базой данных. Действия СУБД,

вызываемые для выполнения логики управления данными, такие как

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

и т. п. СУБД обычно компилирует SQL - предложения.

FS (File Services) - файловые операции. Дисковые операции чтения и

записи данных для СУБД и других компонент. Обычно являются функциями ОС.

Можно привести несколько схем построения информационных систем (таблица

3.1.) в зависимости от размещения типовых компонентов приложения по узлам

сети.

Таблица 3.1. Схем построения информационных систем

| |с использованием |DL |FS |клиент-сервер, доступ|

3.3.1. Централизованные многотерминальные системы

В централизованной системе, характерной для Unix, терминал реализует

лишь функции представления данных PS, тогда как остальные функции

обеспечивает центральный узел. Центр должен реагировать на каждый запрос

пользователя (PL), выполнять логику приложения (BL, DL) и извлекать данные

из БД (DS, FS). Имеются две серьезные проблемы для централизованной схемы:

трудно обеспечить графический интерфейс; каждый дополнительный пользователь

и приложение вносят существенную нагрузку на сервер, теряется

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

3.3.2. Файл-серверные приложения

В отличии от централизованной системы архитектура "файл-сервер"

(таблица 3.1 и рисунок 3.1) не имеет сетевого разделения компонентов

диалога PS и PL, использует ПК для функций отображения, что облегчает

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

файлов, так что дополнительные пользователи и приложения добавляют лишь

незначительную нагрузку на ЦП. Каждый новый клиент добавляет вычислительную

мощность к сети.

[pic]

Рисунок 3.1.

Варианты построения файл-серверных приложений.

Объектами разработки в файл-серверном приложении являются компоненты

приложения, определяющие логику диалога PL, а также логику обработки BL и

управления данными DL. Разработанное приложение реализуется либо в виде

законченного загрузочного модуля или в виде специального кода для

интерпретации.

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

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

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

график, а также возникающая проблема "толстого клиента" - Windows-

интерфейс, коды приложения и СУБД могут перегрузить даже мощный ПК.

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

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

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

практически неработоспособной. В данным случае единственное решение -

удаленное управление файл-серверным приложением в сети (таблица 3.1 и

рисунок 3.1). В локальной сети ставится сервер приложений, совмещенный с

телекоммуникационным сервером (сервер доступа). В многозадачной среде этого

сервера выполняются обычные файл-серверные приложения. Особенность состоит

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

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

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

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

управления или эмуляции терминалов, которые передают сигналы от клавиатуры

и мыши серверу приложений, а в ответ получают копии экранов и отображают их

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

многие "настольные СУБД", как традиционные инструменты файл-серверных

приложений, не отвечают требованиям сохранности данных, в частности не

поддерживают транзакции. Однако СУБД для ПК привлекают простотой

использования и доступностью, поэтому файл-серверные приложения еще будут

использоваться для рабочих групп.

3.3.3.Приложения клиент-сервер

Архитектура клиент-сервер предназначена для разрешения проблем файл-

серверных приложений путем разделения компонентов приложения и размещение

их там, где они будут функционировать более эффективно. Особенностью

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

данных, понимающих запросы на языке структурированных запросов SQL и

выполняющих поиск, сортировку и агрегирование информации на месте без

излишней перекачки данных на рабочие станции.

Другая отличительная черта серверов БД - наличие словарьа данных, в

котором записаны структура БД, ограничения целостности данных, форматы и

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

программе. Объектами разработки в таких приложениях помимо диалога и логики

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

набор SQL-операторов для типовых запросов для этой БД.

Большинство конфигураций клиент-сервер использует двухзвенную модель,

состоящую из клиента, который обращается к услугам сервера (сх. 3-5 в

таблице 3.1, рисунок 3.2). Для эффективной реализации такой схемы часто

применяют неоднородную сеть. Как минимум, предполагается, что диалоговые

компоненты PS и PL размещаются на клиенте, что позволяет обеспечить

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

данными DS и FS на сервере, а диалог (PS, PL), логику BL и DL на клиенте -

сх. 3 в таблице 3.1). Типовое определение архитектуры клиент-сервер -

приложение на клиенте, СУБД - на сервере - использует эту схему.

[pic]

Рисунок 3.2.

Варианты построения приложений клиент-сервер.

Поскольку эта схема предъявляет наименьшие требования к серверу, она

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

большое взаимодействие с БД, могут жестко загрузить как клиента, так и

сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, потому

что там находится логика принятия решения. Такая схема возлагает

дополнительное бремя администрирования приложений, разбросанных по

различным клиентским узлам.

Можно сократить нагрузку на клиента и сеть, переместив целиком

компонент BL на сервер, при этом вся логика принятия решений оформлена в

виде хранимых процедур и выполняется на сервере БД. Хранимая процедура -

процедура с операторами SQL для доступа к БД, вызываемая по имени с

передачей требуемых параметров и выполняемая на сервере БД. Компиляция

повышает скорость исполнения хранимых процедур и сокращает нагрузку на

сервер. Но, перегрузив хранимые процедуры прикладной логикой, можно

потерять преимущества по производительности. Хранимые процедуры улучшают

целостность приложений и БД, гарантируют актуальность коллективно

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

процедур, а также безопасность (нет прямого доступа к данным).

Переместив с клиента часть логики приложения на сервер, получим

систему клиент-сервер с разделенной логикой. Часть прикладной логики может

быть реализована на клиенте, а другая часть логики - в виде обработчиков

событий (триггеров) и хранимых процедур на сервере БД. Такая схема при

удачном разделении логики приводит к сбалансированной загрузке клиентов и

сервера, но при этом затрудняется сопровождение приложений.

[pic]

Рисунок 3.3.

Приложения клиент-сервер на основе многотерминальной системы.

На основе многотерминальной системы в качестве сервера приложений

также возможно создание архитектуры клиент-сервер (рисунок 3.3.). В этом

случае в многозадачной среде сервера приложений выполняются программы

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

4. ВЫБОР ЯЗЫКА ПРОГРАММИРОВАНИЯ

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

Среди средств разработки информационных приложений можно выделить

следующие основные группы:

. традиционные системы программирования;

. инструменты для создания файл-серверных приложений;

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

Рассмотрим кратко отличительные черты и область применения каждой

группы инструментальных средств создания информационных приложений.

4.1.Традиционные системы программирования

Традиционные системы программирования представлены средствами создания

приложений на языках третьего поколения 3GL: C, Pascal, Basic и др. Среди

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

системы компилирующего и интерпретирующего типа. Инструментальные средства

программирования могут быть представлены набором отдельных утилит (редактор

текстов, компилятор, компоновщик и отладчик) или интегрированной средой

программирования.

Процедурные языки программирования являются традиционными, они лишь

претерпели изменения от неструктурных до структурных языков

программирования. Объектно-ориентированное программирование - сравнительно

новое направление, однако оно в концептуальном плане более привлекательно,

позволяет рассматривать и реализовывать информационные и функциональные

свойства объектов в неразрывной связи.

Свойствами объектно-ориентированных языков, обуславливающими их

преимущества, являются сокрытие деталей реализации объекта (инкапсуляция),

наследование процедурных и информационных частей от объектов-родителей,

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

Примерами объектно-ориентированных систем программирования являются C++ и

Object Pascal.

Системы программирования 3GL нужны для организации специальных модулей

в информационных приложениях, для создания эффективных по быстродействию

программ обработки данных. Для создания с помощью систем программирования

полноценных информационных приложений необходимо расширить их за счет

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

макросредств встроенного языка структурированных запросов Embeded SQL.

Систему программирования Visual Basic можно использовать для создания

простых автономных приложений и компонентов VBX и OCX, для расширения и

интеграции функциональных пакетов (Word, Excel, Access), а также как

средство программирования для расширения систем документооборота и для

создания утилит администрирования.

С момента выхода продано существенно больше копий Delphi, чем Visual

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

программ, для разработки DLL, для сопровождения и развития разработок,

выполненных на Turbo и Borland Pascal, а также для быстрого

прототипирования будущих приложений. В ряде случаев решающим для выбора

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

обеспечению.

С++ применяется для расширения системного программного обеспечения,

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

и классов для предметной области, разработки динамических библиотек DLL,

создания программного обеспечения для серверов приложений, разработки ОСХ,

использования совместно с CASE-системами, обеспечения многоплатформенности

и переносимости (по стандарту ANSI).

4.2. Инструменты для создания файл-серверных приложений

Основой разработки файл-серверных приложений для локальных сетей ПК

является инструментальное окружение различных "персональных" СУБД: FoxPro,

Clipper, Paradox, Clarion, Paradox, dBase и т.п. Такие средства, как

правило, реализованы в виде диалоговой интегрированной среды,

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

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

языка 3GL с некоторыми возможностями языков четвертого поколения 4GL;

. создание и ведение структуры БД и индексов, а также интерактивная

генерация макетного приложения и его компонентов (меню, форм или окон,

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

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

создания, ведения и просмотра БД, а также формирования несложных запросов

и отчетов.

Диалоговые среды поддерживают как текстовой для DOS, так и графический

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

привело к развитию объектных свойств инструментов, средств визуальной

генерации программ и событийного механизма приложений.

База данных для этих СУБД представляет собой совокупность файлов БД и

индексов, а не единое информационное пространство, что усложняет ее

сопровождение. Ни одна из традиционных СУБД для ПК не имеет средств

ограничения целостности. Среди инструментальных средств СУБД для ПК

преобладают интерпретирующие системы, хотя многие предоставляют и

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

СУБД для ПК MS Access может использоваться для создания масштабируемых

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

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

делопроизводства в составе MS-Office.

Традиционные инструментальные средства класса xBase (такие как FoxPro,

Clipper, dBase и др.) теряют рынок (число их продаж значительно

сокращается) из-за несоответствия современным требованиям. По мере того,

как предприятия все шире используют СУБД MS Access и новые средства

разработки, такие как Visual Basic и Delphi, популярность среды Xbase

уменьшается. Более того, Microsoft может прекратить поддержку FoxPro, так

как эта СУБД с устаревшим языком и сокращающейся рыночной долей не

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

Microsoft строит вокруг Visual Basic и Access. Новые "визуальные"

инструменты этого класса (Visual FoxPro, CA-Visual Objects, Visual dBase)

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

для сопровождения и развития прежних xBase-разработок, для создания

масштабируемых одиночных и групповых файл-серверных приложений и для

переноса и адаптации приложений в архитектуру клиент-сервер с

использованием интерфейса ODBC. Но нужно четко осознавать, что при

применении нового инструментария для создания диалога и с переходом на SQL-

операторы от прежних xBase-приложений остается ничтожно мало, а, кроме

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

будут востребованы.

Инструментальное средство MS Access хорошо зарекомендовало себя в

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

как оно имеет удобные средства визуального конструирования, отладки и

возможности использования как Access Basic, так и SQL. Интерфейс ODBC

открывает широкие возможности интероперабельности с различными СУБД. В 1995

г. на долю MS Access пришлось 57% рынка настольных баз данных, а FoxPro и

dBase - 9% и 2%, соответственно

4.3. Средства разработки приложений клиент-сервер

Группу инструментальных средств для создания информационных приложений

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

. среды разработки приложений для серверов баз данных, независимые от СУБД

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

. средства поддержки распределенных информационных приложений.

4.3.1. Среды разработки приложений для серверов баз данных

Среды разработки приложений для серверов БД представляют собой системы

программирования четвертого поколения 4GL или инструментальные средства

быстрой разработки приложений RAD (Rapid Application Development).

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

доступа к СУБД по двухзвенной схеме клиент-сервер; связь клиентских

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

запросов SQL (кроме серверов Btrieve); обеспечение целостности БД, включая

целостность транзакций; поддержка хранимых процедур на серверах БД;

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

диалогового интерфейса и отчетов.

В качестве примера можно назвать инструменты Informix/4GL,

Oracle*Forms и др. Сейчас новые среды разработки SQL-серверов БД (Informix

NewEra и Oracle Power Objects) развиваются в сторону независимых от СУБД

инструментов. Независимые инструментальные средства, ориентированные на

многие платформы СУБД, представлены в виде средств быстрой разработки

приложений RAD. Для таких средств создания приложений клиент-сервер

характерны: возможность распределения приложения на клиентах и/или

серверах; создание приложений для разных серверов БД; поддержка

спецификации ODBC для доступа к различным серверам БД, включая СУБД для ПК;

связь с мониторами транзакций для организации трехзвенной архитектуры

приложений клиент-сервер; объектно-ориентированное программирование

приложений; визуальный характер генерации приложения; ведение репозитария

объектов и их свойств, что облегчает интеграцию со средствами автоматизации

проектирования программ CASE; управление проектами и версиями приложений;

интеграция приложения с электронной почтой и средствами офисной

автоматизации.

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

являются: ErWin, SQLWindows, PowerBuilder, JAM и Uniface.

4.3.2. Средства поддержки распределенных информационных приложений

Средства поддержки распределенных приложений относятся к категории

промежуточного программного обеспечения middleware для организации серверов

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

средств: интерфейсы доступа к базам данных ODBC и IDAPI; шлюзы для систем

управления базами данных; протоколы и команды мониторов обработки

транзакций; почтовые интерфейсы MAPI, VIM, MHS, X.400 и EDI; средства

обмена сообщениями MOM; протоколы связывания и включения объектов OLE и

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

и именованных конвейеров Named Pipes, средства коммуникационного ввода-

вывода BSD Sockets и WinSock.

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

необходимо выбирать, исходя из следующих критериев (см. таблицу 4.1):

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

приложений между клиентом и сервером, обеспечена ли поддержка мониторов

транзакций, доступность CASE-репозитария, возможность переноса приложений и

контроль версий. При этом следует выяснить, насколько опыт разработчиков

предприятия соответствует требованиям продукта, важна ли переносимость

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

интеграции приложений устроит заказчика и нужно ли будет в дальнейшем

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

Таблица 4.1. Инструментальные наборы для разработки приложений клиент-

сервер

| |ра |клиентом | | | |

| | |и | | | |

|JAM |нет |да |да |нет |нет |

|New Era |да |нет |нет |да |да |

|Developer |нет |да |да |да |да |

|2000 | | | | | |

|Power |да |нет |да |да |да |

|Delphi |да |нет |да |да |да |

|MS-Access |нет |нет |нет |нет |нет |

|Oracle |да |нет |нет |нет |да |

Кроме того, развитие современных программных средств приводит к

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

обеспечения разных типов конкурируют друг с другом. Так, продукт Borland

C++ Builder превращающий компилятор Borland Visual C++ в полноценную среду

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

дополняет C++ визуальными "дизайнерами", интуитивными "мастерами" и

средствами доступа к объектно-ориентированным данным, сохраняя знакомое

окружение Visual C++.

Мощное средство Oracle Forms из набора Developer/2000 предназначено для

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

перенесены на платформы с различными графическими и символьными

пользовательскими интерфейсами. Oracle Forms является частью

Developer/2000, который поддерживает разработку приложений во время всего

жизненного цикла. Приложения, созданные с помощью Developer/2000, полностью

масштабируемы и применимы на любом уровне: от систем поддержки принятия

решений для небольших рабочих групп до проектов с большим объемом

транзакций, которые поддерживают сотни пользователей. Приложения, созданные

с помощью Developer/2000, оптимизированы с целью использования всех

преимуществ сервера Oracle7, поэтому они должны быть основными средствами

при разработке приложений в среде Oracle7.

Инструментальная среда NewEra для СУБД Informix обладает всеми

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

Дополнительные преимущества - возможность интеграции с программами на С и

многоплатформенность - делают ее пригодной не только при разработке

приложений для СУБД Informix, но и для других систем. Следует заметить, что

вопрос интероперабельности Informix-Oracle решен неудовлетворительно.

Uniface поддерживает интерфейс практически со всеми известными

программно-аппаратными платформами, протоколами, СУБД и мониторами

транзакций. Это средство необходимо использовать при разработке и

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

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

Анализ и апробация возможностей MS Access показал, что это

инструментальное средство хорошо зарекомендовало себя как в разработке файл-

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

архитектуре клиент/сервер, наличие поддержки языка SQL и интерфейса ODBC

открывает доступ к SQL-серверам БД. Имеется средство для миграции

приложений MS Access в среду MS SQL Server. К достоинствам Access следует

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

пакета ориентированы лишь на офисную автоматизацию и не содержат runtime-

компонент для создания законченного информационного приложения.

Средство JAM имеет недостаточную разрядность и может быть использовано

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

аналитических систем. Но его отличает многоплатформенность и поддержка

мониторов транзакций.

Пакет Oracle Power Object предназначен для разработчиков, впервые

приступающих к разработке приложений клиент-сервер и переходящих от таких

систем, как FoxPro или Clipper, и наиболее пригоден для создания прототипов

Страницы: 1, 2, 3, 4, 5