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

традиционных SQL-приложений.

Таким образом, InterBase 4.0 поддерживает две интерфейсных

операционных среды:

. Технологию Express Link (использующую IDAPI) с поддержкой таких

персональных инструментов, как dBASE, Paradox и другие продукты

Windows на базе IDAPI.

. SQL, позволяющую реализовать доступ на базе статических или

динамических операторов SQL.

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

эти модели.

Для взаимодействия с сервером персональное приложение на PC, включая

Paradox и dBASE, может вызывать администратор IDAPI. Сами функции IDAPI по

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

функции SQL. Вызовы SQL в IDAPI основаны на спецификации X-Open Call Level

Interface, в то время как расширения вызовов персональных приложений IDAPI

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

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

используются совместно как в режиме SQL, так и в режиме перемещения. Режим

взаимодействия приложения с сервером InterBase 4.0 обычно определяется

режимом текущего вызова IDAPI. Использование SQL или режима перемещения

прозрачно для пользователя.

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

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

персонального приложения в команды SQL. Например, чтобы открыть индексный

курсор, транслирующий уровень строит оператор SQL с предложением Order By,

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

Фильтрующие выражения завершаются предложением Where сгенерированного

оператора SQL. Сервер реляционной базы данных эмулирует через SQL семантику

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

что ведет к заметному снижению производительности.

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

операторов SQL, InterBase 4.0 с помощью многопользовательской среды клиент-

сервер обеспечивает производительность, близкую к производительности

локального персонального приложения. Это означает, что когда курсор

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

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

порядке.

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

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

более быстрой выборки записей из таблиц и индексов InterBase 4.0 использует

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

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

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

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

параллельно могут обращаться как пользователи Express Link, так и SQL.

Закладка - это метка записи относительно ее позиции среди других

записей. Механизм InterBase 4.0 поддерживает закладки непосредственно на

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

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

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

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

InterBase 4.0 поддерживает быстрые операции с закладками.

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

транзакции и предполагают обычно, что каждая операция базы данных

выполняется немедленно. Для поддержки такого представления InterBase 4.0

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

интерпретирует каждое обновление как полную транзакцию.

С этой целью в InterBase 4.0 поддерживается сохранение контекста

курсора. Это позволяет поддерживать текущий курсор даже после завершения

транзакции.

Когда сервер использует в качестве своего интерфейса исключительно

SQL, он ограничен налагаемыми SQL правилами блокировок транзакций. В

соответствии с правилами SQL пользователь может определить уровень

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

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

и в общем случае не применяют неявных блокировок. Более того, может

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

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

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

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

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

пользователей SQL.

Персональные приложения часто позволяют пользователю просматривать

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

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

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

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

вынуждено следовать одним из путей:

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

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

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

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

другое приложение изменило данные, и отражает это изменение.

. Блокировать все кэшируемые данные

В InterBase 4.0 предусмотрена специальная технология, которая называется

обновлением кэша. Используя это средство, приложение IDAPI может

идентифицировать диапазон интересующих его записей и регистрирует это на

сервере. Когда в записи из этого диапазона происходит изменение (например,

параллельно работающий пользователь модифицирует запись), сервер инициирует

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

уведомления о событиях - InterBase 4.0 Event Alerters. Клиентское

приложение получает это событие и может либо игнорировать его, либо

запросить изменение записей в данном диапазоне.

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

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

и операций с объектами BLOB поддерживаются как 8-битовые, так и 16-битовые

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

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

помощью предложения Order By в операторе Select. Для спецификации символов

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

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

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

языком в среде Windows.

2.5 Выбор средств разработки

В качестве CASE-средства использован программный продукт ERWin 2.5

фирмы Logic Works. ERwin - средство разработки структуры базы данных. ERwin

сочетает графический интерфейс Windows, инструменты для построения ER-

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

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

данных. С помощью ERwin можно создавать или проводить обратное

проектирование (реинжиниринг) баз данных.

Предыдущие версии ERwin - 1.5 и 2.1 - завоевали все возможные призы

среди программ своего класса, в том числе DBMS Readers' Choice в 1992,

1993, 1994, 1995 годах, Software Development Productivity Award 1993, Data

Based Advisor Readers' choice 1992 и 1994. Текущая версия продукта - 2.6.

ERWin позволяет проводить анализ системы как в стандарте IDEF1X, так и

в стандарте IE, что увеличивает удобство работы с продуктом. ERwin

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

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

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

продукт. Выбор этого продукта обусловлен также возможностью легкого

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

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

разработчика Borland Delphi C/S 2.01. Delphi относится к средствам быстрой

разработки приложений (RAD - Rapid Applications Development). Определяющим

фактором при выборе Delphi в качестве средства разработки клиентской части

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

приложений, работающих с базами данных. Кроме того, Delphi поддерживает

интерфейс PVCS, что позволяет вести параллельную разработку проекта

несколькими программистами.

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

использована среде разработки Microsoft Visual C 4.2 из пакета Microsoft

Developer Studio. Эта среда сочетает в себе мощь языка C++, удобные

средства отладки программ и навигации по тексту. Кроме того, она позволяет

использовать в программах все возможности операционной системы (RPC, RAS,

TAPI, сервисы Windows NT).

2.6 Организация взаимодействия между серверами

2.6.1 Выбор модели распределенной базы данных

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

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

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

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

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

2.6.2 Модель взаимодействия

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

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

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

следующие компоненты системы:

. Процесс-клиент (сервер 1)

. Среда передачи данных

. Процесс-сервер (сервер 2)

В этой схеме в каждый конкретный момент времени в качестве клиента

выступает один из взаимодействующих серверов. Таким образом, на каждом из

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

взаимодействие с удаленным узлом сети. В Windows NT в качестве такого

процесса может выступать специально разработанный сервис операционной

системы (system service). Он должен «уметь» обслуживать подключения

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

Кроме того, на него можно возложить функции удаленного администрирования и

резервного копирования данных.

Для организации обмена информацией в общем случае необходимо

разработать протокол этого обмена, что само по себе является достаточно

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

различных транспортных протоколов (TCP/IP, NetBIOS, IPX/SPX), что

выливается в многократное дублирование программного кода. Для решения этой

задачи использован слой вызова удаленных процедур Microsoft RPC (Microsoft

Remote Procedure Call).

2.6.3 Использование слоя RPC для распределенной обработки данных на

платформе Windows NT

В соответствие с моделью RPC любой сервер может рассматриваться как

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

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

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

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

процессор с другими компьютерами в сети.

Слой Microsoft RPC - только часть стандарта среды для распределенных

вычислений, названной OSF (Open Software Foundation), разработанной группой

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

распределенные вычисления.

2.6.4 Компоненты Microsoft RPC

Microsoft RPC включает следующие основные компоненты:

. Компилятор MIDL (Microsoft IDL)

. Библиотеки времени выполнения и заголовочные файлы.

. Модули транспортного интерфейса

. Сервис разрешения имен

. Сервис поддержки конечной точки

В модели PRC можно формально определить интерфейс для удаленной

процедуры, используя язык, специально разработанный для этой цели. Этот

язык – IDL (Interface Definition Language - язык определения интерфейсов).

Диалект языка, реализованный фирмой Microsoft, назван MIDL (Microsoft IDL).

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

MIDL. MIDL компилятор генерирует «заглушки» (stubs), которые транслируют

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

«Заглушка» -- это процедура-заполнитель, которая делает вызовы библиотечных

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

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

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

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

компилятором и невидим для разработчика.

2.6.5 Механизм работы RPC

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

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

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

распределены данные, используемые процедурами. Следующий рисунок

иллюстрирует архитектуру RPC:

[pic]

Рис.2.3. Механизм работы RPC.

Как показано на рис.2.3, клиентское приложение вызывает локальную

заглушку вместо кода, непосредственно реализующего необходимую процедуру.

Заглушка компилируется и линкуется с клиентским приложением. Заглушка

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

. Запрашивает необходимые параметры из адресного пространства клиента

. Переводит параметры в стандартную форму представления данных в сети

(NDR - standard network data representation)

. Вызывает необходимые функции из библиотеки времени выполнения RPC

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

Заглушка сервера выполняет следующие шаги:

. Библиотека времени выполнения RPC принимает запрос и вызывает

процедуру заглушки сервера

. Заглушка сервера принимает параметра из буфера и конвертирует их из

формата NDR в формат, процедуры сервера.

. Заглушка вызывает необходимую процедуру на сервере.

Удаленная процедура выполняется, генерирует выходные параметры и

возвращаемое значение. Когда процедура завершена, следующие шаги возвращают

данные клиенту:

. Удаленная процедура возвращает данные заглушке сервера

. Заглушка сервера конвертирует возвращаемые параметры в формат NDR и

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

. Библиотечные функции передают данные через сеть на клиентский

компьютер

Клиент завершает процесс принятием данных из сети и их возвратом

вызывающей функции:

. Клиентская библиотека времени выполнения RPC принимает значения,

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

. Заглушка клиента конвертирует данные из формата NDR в формат,

используемый клиентским приложением

. Приложение клиента продолжает свою работу.

Для Microsoft Windows и Windows NT библиотеки времени выполнения

используются двумя путями: как статическая библиотека, линкуемая в

приложение; и библиотека, реализованная как DLL.

Серверное приложение содержит вызовы библиотеки времени выполнения

сервера, которая регистрирует интерфейсы сервера и позволяет серверу

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

специфичные для каждого приложения процедуры, которые вызываются с клиента.

Таким образом, реализовав коммуникационный сервис на базе слоя RPC,

можно существенно сэкономить время на разработке протоколов обмена

информацией, а также получить систему, работающую по любым транспортным

протоколам.

2.6.6 Организация логического канала передачи данных

Другой компонент модели - среда передачи данных может быть

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

построена на базе асинхронных каналов связи с использованием протоколов PPP

(Point to Point Protocol), а также на базе существующих сетей X.25. На

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

логического канала между серверами.

В случае каналов X.25 для установления соединения используется

специальная каналообразующая аппаратура (коммутаторы X.25).

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

PPP (Point to Point Protocol). Организация удаленного доступа по

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

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

2.7.1 Необходимость удаленного доступа

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

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

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

решением является использование сервера баз данных ближайшего РУС. Для

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

серверу. Средой передачи данных в этом случае являются телефонные линии,

протоколом передачи на сетевом уровне - PPP (или SLIP).

2.7.2 Использование слоя RAS для удаленного доступа на платформе

Windows NT

На платформе Windows NT задача удаленного доступа по протоколу PPP

решается с помощью сервера RAS (Remote Access Server - сервер удаленного

доступа). Сервер RAS - это процесс, который принимает и обрабатывает

запросы клиентов на подключение через асинхронные линии и передачу данных.

Схема взаимодействия удаленного клиента с сервером RAS приведена на

рис.2.4.

[pic]

Рис.2.4. Схема удаленного доступа с использованием RAS.

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

TCP/IP, IPX/SPX, NetBIOS. Подключение клиента через сервер удаленного

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

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

В системе Windows NT существует программный интерфейс приложений

(Application Program Interface), который позволяет установить логический

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

API (Remote Access Service API).

Сервис удаленного доступа (RAS) позволяет удаленным пользователям

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

локальной сети.

Win32 RAS позволяет RAS-клиенту установить соединение, получить

информацию о существующих соединениях и завершить соединение. Связь

осуществляется по протоколам PPP или SLIP. В качестве транспортного

протокола могут быть использованы стеки TCP/IP, IPX/SPX и NetBIOS.

В Windows существуют стандартные программы для связи через RAS, таким

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

средства Windows.

2.7.3 Обеспечение информационной безопасности при удаленном доступе

Учитывая то, что информация на серверах баз данных носит коммерческий

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

доступа. Система Windows NT имеет сертификат соответствия уровню

безопасности C2 Министерства обороны США. Данный уровень безопасности

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

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

сеть также требует соответствующих привилегий, кроме того, все попытки

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

Windows NT встроена возможность шифрования трафика в каналах передачи

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

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

пользователей, финансовая информация).

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

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

(FireWalls) на стыке внутренней и внешней (какой в данном случае является

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

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

Кроме того, серверы-барьеры скрывают топологию сети от внешнего

пользователя. На платформе Windows NT функции сервера-барьера выполняет

продукт Microsoft Proxy Server. Одним из побочных эффектов использования

этого класса продуктов является экономия IP-адресов.

2.8 Проектирование структуры базы данных

Построим информационную модель системы расчета с абонентами.

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

основные сущности:

. Клиент (абонент, владелец телефона)

. Услуга

. Подразделение

. Начисление

. Телефонный разговор, подлежащий повременной тарификации

. Начисление за повременные разговоры (за один день)

. Оплата

. Категория клиента

. Проведенные расчеты

IDEF1X-диаграмма взаимодействия между этими сущностями представлена в

Приложении 6.

После нормализации данных и разрешения связей «многие ко многим» путем

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

Приложении 6. Кроме того, для сущностей «Подразделение» и «Категория

абонента» введена обратная неидентифицирующая связь для иерархического

представления данных.

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

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

поддерживаться механизм регистрации изменений относятся:

. Клиент (владелец телефона)

. Услуга

. Подразделение

. Начисление

. Постоянное начисление

. Категория клиента

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

представленная на рис.2.5.

[pic]

Рис.2.5. Структура данных для поддержки механизма регистрации изменений

Суть данной модели такова:

1. Каждая сущность характеризуется набором состояний, изменяющихся во

времени.

2. Каждое состояние характеризуется набором атрибутов сущности, а также

датой начала и датой окончания состояния.

3. Сущность однозначно идентифицируется своим внешним ключом и

актуальной датой.

4. Дочерние таблицы ссылаются на сущность по её внешнему ключу.

5. При смене состояния внешний ключ не меняется.

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

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

подсистем:

. Картотека абонентов

. Начисления

. Повременный учет

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

поддержки истории принимает вид, приведенный в Приложении 6.

SQL-скрипт для генерации базы данных представлен в Приложении 1.

2.9 Схема репликации данных

Тиражирование данных в системе построено по схеме с одним сервером

подписки (центральный сервер) и множеством серверов репликации (районы).

[pic]

Рис.2.6. Организация репликации данных.

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

избежать конфликтов по модификации записи.

[pic]

Рис.2.7. Подробная схема репликации данных.

Схема репликации приведена на рис.2.7. Рассмотрим процесс передачи

изменений подробнее:

1. При изменении данных в реплицируемой таблице новые данные через

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

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

записи.

2. При возникновении в базе определенного события (например при большом

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

времени коммуникационный сервис запускает процесс репликации.

3. Процесс репликации устанавливает соединение с сервером подписки и

начинает синхронизацию данных.

4. Сервер подписки принимает измененную запись и модифицирует

соответствующим образом таблицу на своей стороне.

5. Если в процессе изменения записи был сгенерирован новый ключ, то он

передается на сервер репликации.

6. Сервер репликации заменяет первичный ключ реплицируемой записи на

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

запись из журнала изменений.

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

протокол двухфазной фиксации транзакций (Two-phase commit transactions),

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

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

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

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

очень плохих каналах связи.

2.10 Проектирование коммуникационного сервера

2.10.1 Постановка задачи

Для решения задач репликации, резервного копирования, удаленного

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

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

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

серверу таковы:

1. Так как информационная система носит распределенный характер, а

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

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

конфигурирования системы.

2. Для облегчения задач администрирования необходимо как можно более

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

задач, таких как резервное копирование данных и репликация.

3. Учитывая необходимость дальнейшего расширения системы необходимо

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

коммуникационного сервера.

4. Учитывая разнородность сети необходимо обеспечить возможность

подключения пользователей по нескольким протоколам: TCP/IP, Named

Pipes, IPX/SPX, NetBIOS.

2.10.2 Архитектура коммуникационного сервера

Учитывая специфику платформы Windows NT коммуникационный сервер

построен по архитектуре системного сервиса (System Service). Для разработки

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

Developer Studio 4.2/Visual C++ Enterprise Edition.

Архитектура сервера представлена в Приложении 2.

Для обеспечения наращиваемости системы проведено разделение

функциональности сервера на две части:

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

планирует запуск пользовательских задач а также обеспечивает

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

. Пользовательские задачи - обеспечивают реплицирование, резервное

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

повременного учета.

Пользовательские задачи реализованы в виде многопоточных DLL. Каждая

пользовательская задача должна обеспечивать две точки входа:

. void TaskProc(void) - основной поток - реализует необходимую

функциональность.

. void Terminate(void) - функция для принудительного останова задачи

(например при останове сервера)

Информация о пользовательских задачах хранится в реестре Windows NT

(ключ HKEY_LOCAL_MACHINE\SOFTWARE\Svyazinform\CommService\Tasks, рис.2.8).

[pic]

Рис.2.8. Конфигурация задач коммуникационного сервера в реестре

Windows NT.

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

следующие модули:

. Модуль инициализации - основная точка входа сервиса - регистрирует

сервис в диспетчере сервисов.

. Модуль управления сервисом - реализует функции запуска и останова

сервера.

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

заданное время.

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

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

системы.

. Модуль регистрации событий - записывает информацию о состоянии

сервера в системный журнал событий.

2.10.3 Вспомогательное программное обеспечение

Для установки коммуникационного сервиса разработана программа,

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

Windows NT. Исходный код программы представлен в Приложении 4.

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

системного реестра. Исходный текст программы представлен в Приложении 5.

Для удаленного конфигурирования пользовательских задач разработано

клиентское приложение «Менеджер задач коммуникационного сервера».

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

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

на рис.2.9.

[pic]

Рис.2.9. Главное окно программы конфигурирования коммуникационного сервера.

Разработка программы велась с помощью пакета Microsoft Visual C++ 4.2.

Механизм реализации этой программы выходит за рамки данного дипломного

проекта.

3. Технико-экономическое обоснование

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

автоматизации расчетов с абонентами АО «Связьинформ» РМ.

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

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

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

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

3.1 План выполнения дипломного проекта

В соответствие с темой дипломного проекта определяются этапы НИР и их

содержание. Этапы НИР необходимо максимально детализировать.

Таб.4.1. Этапы НИР.

|1 |2 |3 |4 |5 |

|1 |Постановка задачи и |5 |3,1 |И1, Р, Д |

|2 |Составление плана и |1 |0,7 |Д, Р |

|3 |Подбор и изучение |14 |10,55 |Д, Р |

|4 |Написание вводной части и |5 |4,35 |Д |

|5 |Информационное |28 |20,25 |Д, Р |

|6 |Разработка |12 |6,28 |Д |

|7 |Отладка коммуникационного |18 |8,35 |Д, Р |

|1 |2 |3 |4 |5 |

|8 |Написание теоретической |15 |14,07 |Д, Р |

|9 |Выводы по теоретической |2 |2,1 |Д, Р |

|10 |Подбор данных и расчет |4 |2,85 |Д, К1 |

|11 |Анализ проделанной работы |2 |1,65 |Д |

|12 |Составление пояснительной |12 |8,4 |Д |

|13 |Оформление графической |12 |10,75 |Д |

|14 |Оформление приложений к |5 |3,025 |Д |

|15 |Сдача работы на отзыв |2 |1,65 |Д |

|16 |Сдача работы на |2 |1,2 |Д |

|17 |Сдача дипломного проекта на|1 |0,725 |Д |

| |ИТОГО: |140 |100 | |

Примечание: Д-дипломник;

И1-инженер-консультант

Р-руководитель

К1-консультант по экономической части

Трудоемкость выполнения НИР определяется по сумме этапов и видов

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

характер, так как зависит от множества трудно учитываемых факторов.

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

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

[pic]

где Tmin - оптимистическая оценка времени разработки, исходящая из

наиболее благоприятных условий её выполнения;

Т н.в. - наиболее вероятная продолжительность выполнения

работы при

нормальных, чаще всего встречающихся условиях;

Т max - максимальное время выполнения работы при наиболее

неблагоприятных условиях её выполнения;

Одновременно с расчетом величины Тож. Определяют дисперсию (разброс)

по формуле:

[pic]

Дисперсия определяет степень неопределенности выполнения работы за

ожидаемое время Тож.

Расчеты ожидаемой продолжительности работ сведены в таблицу.

Таб.4.2. Продолжительность работ.

|№ |Этап и содержание работы |Tmin |Tн.в.|Tmax |Tож |Di |

|n/n| | | | | | |

|1 |2 |3 |4 |5 |6 |7 |

|1 |Постановка задачи и |3 |5 |7 |5 |0,44 |

|2 |Составление плана и |1 |1 |2 |1,167 |0,03 |

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

Рефераты

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