Автоматизированная система обмена информацией

Размещено на http://www.allbest.ru/

Содержание

• Введение
• 1. Патентно-информационный поиск
• 2. Анализ технического задания
• 3. Основная часть
• 3.1 Разработка программы
• 3.2 Работа с базой данных
• 3.3 Описание основных модулей, исполняемых файлов
• 3.4 Внедрение обмена в систему «Бюджет»
• 4. Организационно-экономическая часть
• 4.1 Маркетинговые исследования
• 4.2 Сегментация рынка
• 4.3 Определение себестоимости и цены разработки
• 5. Материалы по охране труда
• 5.1. Анализ условий труда в отделе
• 5.2 Мероприятия по снижению уровня негативных факторов
• Заключение
• Список использованных источников


Введение

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

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

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

Разрабатываемая система автоматизированного обмена в рамках данной дипломной работы обеспечит защищенное взаимодействие между двумя системами. Важное место занимает человеческий фактор. От способностей оператора зависит скорость обмена. Однако автоматизированная система позволяет избавиться от этого фактора.



1. Патентно-информационный поиск

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

- файловый обмен между АИС «Бюджет» и АИС «Государственный заказ»;

- обмен УРМ - смета;

- обмен с УФК;

- обмен с банком УФЭБС;

- обмен с ООС.

Первые два вида обмена разработаны в рамках организации НПИ ИС «Криста» и применяются на текущий момент. Остальные виды обмена утверждены законодательно. Рассмотрим каждый из обменов более подробно.

1.1 Файловый обмен между АИС «Бюджет» и АИС «Государственный заказ»

На интерфейсах системы АИС «Бюджет» и АИС «Государственный заказ» есть специальные кнопки, при нажатии на которые выполняется сценарий выгрузки или загрузки файла. Упрощенная схема обмена представлена на рисунке 1.1.

Пользователь АИС «Бюджет» нажимает на кнопку обмена, появляется диалоговое окно, с помощью которого выбирается выгружаемый файл. Этот файл сохраняется на диске. Далее пользователь АИС «Государственный заказ» нажимает на соответствующую кнопку обмена, появляется диалоговое окно, с помощью которого выбирается загружаемый файл. Обмен осуществляется в XML-формате.



Рисунок 1.1 - Схема обмена между АИС «Бюджет» и АИС «Государственный заказ»

1.2 Обмен УРМ - «Смета»

Обмен, так же как и предыдущий происходит при нажатии на кнопку, но сам обмен построен сложнее. Рассмотрим особенности обмена.

Обмен документами может быть направлен как на экспорт, так и на импорт. В обоих случаях инициатором обмена является АС «Смета».

Упрощенная схема обмена при экспорте документов приведена на рисунке 1.2.

Рисунок 1.2 - Схема экспорта документов при обмене УРМ - «Смета»

Поясним суть обмена. На интерфейсе АС «Смета» есть специальная кнопка «Синхронизация с УРМ». Когда пользователь нажимает на нее, появляется диалоговое окно. В этом окне выбираются ограничения на загружаемые документы (например, тип документов). После выбора ограничений запускается УРМ в виде автообъекта (AutoObject). Затем выполняется метод этого объекта. Под выполнением метода понимается выполнениеAbl-скрипта. На вход скрипту подается коллекция параметров, а на выходе получаем список документов. Особенностью экспорта является то, что обмен проходит через систему отчетов. Созданы специальные шаблоны для каждого типа документов, которыми происходит обмен. В шаблоне находится список полей.

При обмене данных необходимо преобразование данных, пришедших из сметы, в формат, понятный УРМ. Для этого в скрипте используется маппинг полей. Русскоязычные имена полей, понятные АС «Смета», преобразуются в англоязычные имена полей, понятные УРМ.

Данные для передачи выбираются из базы данных. Выборкой этих данных занимается система отчетов.

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

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

На интерфейсе АС «Смета» у каждого документа имеется меню. В этом меню имеется кнопка «Отправлено в УРМ». При нажатии на эту кнопку документ помечается, как отправленный в УРМ, и меняет свое состояние. Отличие от экспорта заключается в том, что здесь процессом импорта управляет не система отчетов, а отдельный скрипт, предназначенный для импорта документов в УРМ. На входе получаем набор данных, которые необходимо перенести в УРМ. Аналогично экспорту происходит преобразование данных в формат, понятный УРМ. Для этого используется соответствующий маппинг полей. Данные также необходимо вставить в базу данных УРМ. Сохранение в базу происходит при выполнении скрипта по сохранению данных.

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

1.3 Обмен с УФК

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

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

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

При формировании файла участником бюджетного процесса для органа Федерального казначейства или органом Федерального казначейства для участника бюджетного процесса имя файла должно иметь следующую структуру:

XXXXXDNN.TTM,

где XXXXX - код организации (отправителя, если документ был создан получателем бюджетных средств для органа Федерального казначейства, и получателя, если документ был создан органом Федерального казначейства). Код должен соответствовать:

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

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

D - дата формирования документов (файла): 1-9, A-V;

NN - порядковый номер файла за дату формирования: каждое из N приводится в 36-ричном формате (0-9, A-Z); если файл формируется в локальной вычислительной сети, номер выгрузки варьируются от 00 до RZ, если файл формируется в выделенной локальной вычислительной сети - от S0 до ZZ;

TT - тип (маркер) документов, содержащихся в файле;

M - месяц формирования документов (файла). Имеет следующие значения:

- значение с 1-9 и с A-C, применяются, если в поле «Код организации» используется код из РУБП;

- значение с D-O, применяются, если в поле «Код организации» используется код, присвоенный органом Федерального казначейства.

При формировании файла органом Федерального казначейства для другого органа Федерального казначейства имя файла должно иметь следующую структуру:

XXXXFDNN.TTM,

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

F - константа, признак того, что обмен ведется органами Федерального казначейства;

D - дата формирования файла; 1-9, A-V;

NN - порядковый номер файла и даты формирования: каждое из N приводится в 36-ричном формате (0 - 9, A - Z); если файл формируется в локальной вычислительной сети, номер выгрузки варьируются от 00 до RZ, если файл формируется в выделенной локальной вычислительной сети - от S0 до ZZ;

TT - тип (маркер) документов, содержащихся в файле;

M - месяц формирования файла; 1-9, A, B, C.

Один файл может содержать данные из произвольного количества документов, если это не запрещено в макете файла. Каждый файл должен содержать данные из документов только того типа, который описан в макете файла. Файл, содержащий данные документов, состоит из служебной части и информационной части.

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

В макете документа определяется:

- количество блоков в документе и их последовательность;

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

1.4 Обмен с банком УФЭБС

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

Основными целями разработки УФЭБС является стандартизация способов и средств взаимодействия между автоматизированными системами различных разработчиков, используемых в расчетной системе Банка России для осуществления безналичных расчетов на территории Российской Федерации и взаимодействия с ней, упрощение существующих форматов электронных сообщений, переход к современным стандартам обмена коммерческой информацией в электронном виде.

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

Стороны обмена электронными документами при осуществлении расчетов через расчетную сеть Банка России приведены в таблице 1.1.

Таблица 1.1

Стороны обмена

Название	Краткая характеристика
УБР (ВЦ)	Обслуживающее учреждение Банка Россия, вычислительный центр.
Участник	Клиент Банка России - кредитная организация (филиал) или другой клиент Банка России, не являющийся кредитной организацией, заключивший с Банком России договор об обмене электронными документами при осуществлении расчетов через расчетную сеть Банка России.

Перевод денежных средств между участниками через расчетную сеть Банка России допускается с использованием электронных платежных документов (ЭПД) двух видов согласно документу:

- полноформатных ЭПД;

- ЭПД сокращенного формата.

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

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

Процедура разрешения разногласий при обмене электронными сообщениями состоит в доказательстве неизменности отправленного сообщения при доставке до получателя, основанном на применении средств контроля целостности и подтверждения авторства сообщений, представленных отправляющей и получающей сторонами в установленном порядке. В связи с этим необходимым требованием при использовании УФЭБС является передача сообщения получателю в том виде, в котором оно было подписано отправителем. Для защиты электронного сообщения с учетом данного требования используется ЭЦП (КА).

Дополнительно электронное сообщение (ЭС (ЭД/пакет ЭД)) может быть защищено на технологическом уровне, для чего в состав реквизитов ЭС (ЭД/пакета ЭД) может быть включен защитный код. В связи с тем, что защита пакета ЭД, а также отдельных электронных документов в составе пакета защитным кодом (ЗК) является элементом технологической защиты, требование передачи ЭС (ЭД/пакета ЭД) получателю в том виде, в котором оно было защищено ЗК отправителем, не является необходимым. Однако алгоритм вычисления защитного кода принимает на вход двоичные данные, следовательно, подписываемое ЭС (ЭД/пакет ЭД) необходимо привести к единому виду, имеющему в любом случае на любой платформе одинаковое двоичное представление. Электронные сообщения представляют собой XML-документы, поэтому для того, чтобы привести подписываемое и проверяемое ЭС (ЭД/пакет ЭД) к одному виду, необходимо использовать алгоритмы, предназначенные для обработки XML-документов. Для приведения XML-документа к единому виду, имеющему в любом случае на любой платформе одинаковое двоичное представление, консорциум W3C рекомендует использовать алгоритм канонизации. Дополнительное преобразование (нормализация), позволяющее удалить лишнюю информацию из XML-документа, позволяет формировать ЗК только по значащим данным, что дает возможность защиты информации без учета особенностей разметки.

В состав реквизитов ЭД может быть включен защитный код. При этом защита пакета ЭД или отдельных электронных документов в составе пакета ЭД защитным кодом является элементом технологической защиты.

Электронные сообщения представляют собой XML-документы, причем требование передачи ЭС (ЭД/пакета ЭД) получателю в том виде, в котором оно было защищено ЗК отправителем, не является необходимым. Однако алгоритм вычисления защитного кода принимает на вход двоичные данные, следовательно, подписываемое ЭС (ЭД/пакет ЭД) необходимо привести к единому виду, имеющему в любом случае на любой платформе одинаковое двоичное представление. Алгоритм канонизации XML-документов приводит XML-документ к форме, позволяющей определить логическую эквивалентность данного XML-документа другому XML-документу в канонической форме. Чтобы определить, являются ли два XML-документа логически эквивалентными, необходимо канонизировать каждый XML-документ согласно правилам канонизации, определенным W3С, и сравнить их канонические формы, сопоставляя байт за байтом. Если обе канонические формы содержат одинаковую последовательность байт, значит, соответствующие XML-документы являются логически эквивалентными.

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

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

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

Служебный конверт не защищается ЭЦП (КА).

1.5 Обмен с ООС

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

В качестве документов в обмене могут быть контракты, договора и др.

Передача информации в электронной форме производится в формате XML. Формат XML-документов, описываемый в настоящих Требованиях, имеет номер версии 2011.01. Передаваемая информация, используя язык разметки XML, преобразуется в электронный документ.

XML-документ состоит из строк, содержащих элементы и атрибуты, а также их значения. Реквизиты XML-документа могут быть элементами или атрибутами.

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

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

Передаваемый XML-документ должен соответствовать XML-схеме, прилагаемой к данным Требованиям в электронной форме.

В XML-документе описывается пролог с указанием кодировки UTF-8:

<?xml version = “1.0” encoding = “UTF-8”?>

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

Для подписания документа используется следующий алгоритм:

- сформированный XML документ преобразовывается с помощью xsl- преобразования для приведения документа к единому виду в соответствии с рекомендациями W3C Canonical XML

- полученная строка преобразуется в массив байт в кодировке UTF-8 и подписывается в формате CAdES-BES

- полученная отсоединенная (detached) цифровая подпись может быть передана на ООС для подтверждения согласованности проекта извещения с Уполномоченным органом, сертификат сотрудника которого был использован при формировании данной подписи.

Передача информации осуществляется по защищенным телекоммуникационным каналам связи по специализированному адресу закрытой части ООС по протоколу HTTPS, используя криптографический протокол TLS.

Информация передается с использованием метода POST, используя следующие параметры:

- login (тип - строка, обязательный) - имя пользователя, осуществляющего загрузку сведений;

- password (тип - строка, обязательный) - пароль пользователя для входа в Личный кабинет ООС;

- doc (тип - строка, обязательный) - передаваемый XML-документ;

- sign (тип - бинарный в формате base64, необязательный) - электронная подпись XML-документа.

Допускается передача XML-документов объемом не более одного гигабайта.

Сравним вышерассмотренные системы обмена.

Таблица 1.2

Сравнение систем обмена

Название	Поддержка ЭЦП	Формат передаваемых данных	Возможность автоматической передачи	Способ передачи
Файловый обмен между АИС «Бюджет» и АИС «ГЗ»	-	XML	-	Файл
Обмен УРМ - «Смета»	-	Бинарный	+	Com, DCOM
Обмен с УФК	+	Текстовый с разделителями	-	Файл
Обмен с банком УФЭБС	+	XML	+	HTTP
Обмен с ООС	+	XML	+	HTTP



2. Анализ технического задания

Разрабатываемая система предназначена для обмена документами АСУБП с АИСГЗ. В качестве входных данных у системы будут являться сведения о контрактах, договорах и документах исполнения. В качестве выходных данных будут являться бюджетные обязательства, принятые по договорам, контрактам и документами исполнения, которые были приняты из АИСГЗ.

Так как обмен происходит электронными сообщения, то необходимо выбрать сервер для обмена этими сообщениями. В качестве такого сервера можно использовать Microsoft Exchange Server. Этот сервер может использоваться в качестве почтового сервера, но его главный недостаток заключается в том, что он платный. В связи с этим будем использовать почтовый сервер hMailServer.

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

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

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

В качестве базы данных будет использоваться база, разработанная в организации ООО ИС «Криста» под управлением СУБД Oracle. В качестве языка программирования будет выбран Delphi 5.0 и Abl-редактор.



3. Основная часть

3.1 Разработка программы

3.1.1 Краткое описание АС «Бюджет»

Автоматизированная система планирования, бухгалтерского учета и анализа исполнения бюджета в финансовых органах «Бюджет» обеспечивает комплексную автоматизацию финансовых органов субъектов федерации (областных, краевых, республиканских) и финансовых органов муниципальных образований (районов, городов) и обладает следующими функциональными возможностями:

- полная автоматизация работы финансового органа (планирование, уточнение, исполнение, отчеты, анализ по доходам, расходам и штатам);

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

- ведение книг бухгалтерии: книги доходов, книги текущих счетов распорядителей кредитов и кассовых расходов, книги расчетов с другими бюджетами, книги «Журнал-главная» согласно требованиям Министерства Финансов России;

- программное формирование бюджета и анализ его исполнения;

- работа с валютами (в т. ч. курсы валют, доходы от курсовой разницы, оплата услуг дилера);

- операции с векселями (оплата налогов и финансирование);

- работа с взаимозачетами (учет налогов и финансирование);

- работа с ценными бумагами (финансирование, доходы, оплата услуг дилера);

- расширенный формат даты (заключительный месяц, расширенное количество дней в месяце для проведения специальных операций);

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

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

- разграничение доступа к данным и программам;

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

С точки зрения архитектуры система строится как иерархическая и имеет 3 уровня иерархии. Отдельные компоненты системы являются COM-объектами.

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

Второй уровень - это «рабочие места» - набор «страниц», объединенных в группы, с которыми работает пользователь. «Рабочие места» могут произвольно формироваться из «страниц» с целью обеспечения полной функциональности РМ в зависимости от потребностей пользователя.

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

По образу работы с данными страницы делятся на «отчеты» и «интерфейсы ввода данных» (ИВД). Отчеты предназначены исключительно для отображения некоторого набора данных в определенном виде, тогда как ИВД предназначен как для представления данных в удобочитаемом для пользователя виде, так и для манипуляций над ними (добавление новых данных, редактирование существующих, удаление).

Для хранения данных в системе использует СУБД Interbase, но в настоящее время производится переход на трехзвенную архитектуру, обеспечивающую независимость от конкретной СУБД.

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

- время ввода данных;

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

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

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

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

3.1.2 Общая характеристика применения подсистемы в целом

Система информационного взаимодействия автоматизированной системы управления бюджетным процессом Московской области с АИС управления государственными закупками Московской области должна обеспечить полностью автоматизированный обмен данными. Основная задача системы - это обмен электронными сообщениями через почтовый сервер в установленное время.

Существующие на данный момент системы обмена данными между двумя независимыми системами не удовлетворяют требованиям текущей задачи. Основные требования это:

- обмен по протоколу SMTP, POP3;

- обмен осуществляется в xml-формате, ЭЦП помещается внутрь xml файла (используется стандарт XMLDsig);

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

Разработка системы ведется с использованием среды разработки Delphi 5.0.

3.1.3 Основные характеристики вычислительных средств

Требования к ПК:

- операционная система Windows 2000/XP или последующие;

- процессор не ниже Pentium II;

- оперативная память не менее 512 Мбайт;

- минимальное дисковое пространство 500 Мбайт;

- мышь и клавиатура;

- скорость передачи локальной сети 10 Мбит/с и более.

3.1.4 Описание требований к системе

Все требования к системе указаны в техническом задании. Рассмотрим их подробнее.

Протоколы SMTP, POP3 используются при обмене электронными сообщениями. Многие почтовые сервера поддерживают работу с этими протоколами.

ЭЦП необходимо для обеспечения защиты передаваемой информации. ЭЦП помещается внутрь xml файла по стандарту XMLDsig.

XML (eXtensible Markup Language) -- рекомендованный язык разметки, фактически представляющий собой свод общих синтаксических правил. XML предназначен для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML), иногда называемых словарями.

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

Особенности, которые делают XML наиболее подходящим для бизнес-транзакций (например, семантическое богатство и структурированность данных, текстовая основа и удобное для использования в Web представление) предоставляют возможности для операций шифрования и электронной подписи данных в XML-формате. Например, во многих сценариях движения XML-документа между участниками, где цифровая подпись играет роль согласия или отказа, каждый участник может пожелать подписать только ту часть, где у них есть ответственность, и берет на себя эту ответственность. Старые стандарты цифровых подписей не предоставляют ни синтаксиса такой гранулярности подписания, ни механизмов для выражения части, которую есть желание подписать.

XML Signatures - цифровые подписи, спроектированные для применения в XML-транзакциях. Стандарт описывает схему для хранения результатов операции цифрового подписания примененного к любым (чаще XML) данным. Подобно другим видам подписей (например, PKCS),XML-подписи поддерживают аутентификацию, целостность данных и неотрекаемость от подписания данных. Однако, в отличие от других видов подписей, XML-подписи были спроектированы для использования в сети Интернет и на основе XML.

Главная особенность XML Signatures - возможность подписания лишь части данных XML вместо всего документа. Это особенно значимо, когда один XML-документ может иметь долгую историю, в которой различные его части оформляются в разное время разными исполнителями, и каждый подписывает лишь важную для себя часть. Эта гибкость также критична в случаях, когда необходимо обеспечить целостность определенных частей XML-документа, но оставить открытой возможность изменения других частей. Представьте, например, подписанную XML-форму, присланную пользователю для заполнения. Если бы подпись была наложена на весь XML, любое изменение пользователем значений формы привело бы к недостоверности подписи.

XML-подпись может подтверждать более одного типа ресурсов. Например, одна XML-подпись может покрывать текстовые данные (HTML), бинарные данные (JPG), XML-шифрованные данные и определенную секцию XML-документа.

Проверка подписи требует доступность подписанного объекта данных. XML-подпись чаще всего сама ссылается на подписанный объект. Эта ссылка может:

- быть URI в XML-подписи;

- находиться внутри того же узла, где находится XML-подпись (на этом же уровне);

- зависеть от подписи (XML-подпись является родителем);

- иметь подпись в качестве потомка (XML-подпись является дочерним узлом).

Компоненты XML-подписи показаны на рисунке 3.1.

Рисунок 3.1 - Компоненты XML-подписи

Каждый подписываемый элемент имеет свой <Reference>-элемент, определяемый атрибутом URI.

Элемент <Transform> определяет упорядоченный список операций, которые были произведены над описываемый ресурсом, прежде чем для него был рассчитан хэш.

Элемент <DigestValue> содержит хэш.

Элемент <SignatureValue> содержит результат криптования хэша.

Элемент <KeyInfo> определяет ключ для проверки подписи. Возможные формы идентификации включают сертификаты, имена ключей, алгоритмы взаимодействия ключей и информацию.

XML-DSIG использует отдельное пространство имен, и мы принимаем, что в наших примерах присутствует следующее объявление:

<<xmlns:ds=http://www.w3.org/2000/09/xmldsig#>>.

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

<element name="Signature" type="ds:SignatureType"/>

<complexType name="SignatureType">

<sequence>

<element ref="ds:SignedInfo"/>

<element ref="ds:SignatureValue"/>

<element ref="ds:KeyInfo" minOccurs="0"/>

<element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/>

</sequence>

<attribute name="Id" type="ID" use="optional"/>

</complexType>

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

3.1.5 Выделение входных и входных данных

Необходимо выделить входные и выходные данные разрабатываемой системы. Для этого рассмотрим суть обмена более детально. В АСУБП в разрезе классификации вводятся бюджетные ассигнования (далее - БА) и лимиты бюджетных обязательств (далее - ЛБО), данная информация передаётся в АИСГЗ. С учётом переданной информации заказчики (получатели средств бюджета Московской области (далее - ПБС), главные распорядители средств бюджета Московской области (далее - ГРБС)) в АИСГЗ вводят сведения о контрактах, договорах и документах исполнения, данные сведения передаются в АСУБП. Заказчики приносят в Министерства финансов Московской области (далее - ФО, МФ) подтверждающие документы к контрактам, договорам и документам исполнения. Ответственный работник ФО находит переданный из АИСГЗ документ, сверяет основные данные документа и принимает бюджетное обязательство (далее - БО) на учёт. Далее заказчики осуществляют оплату по договорам, контрактам, документам исполнения, указывая в платёжных документах БО. Информация о проведении, принятии платёжных документов по БО передаётся в АИСГЗ.

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

3.1.6 Декомпозиция программы

Под декомпозицией понимается последовательное разбиение общей задачи на более простые подзадачи. Задачей дипломного проектирования является разработка автоматизированной системы обмена данными. В предыдущем пункте были выявлены входные и выходные данные для разрабатываемой системы. Изобразим условно разрабатываемую систему в виде «черной сферы».

На первом этапе декомпозиции необходимо разделить всю систему на рабочий и контрольный процесс. Покажем это на рисунке 3.3.



Рисунок 3.2 - Разрабатываемая система в виде «черной сферы»

Рисунок 3.3 - Декомпозиция программы после первого этапа

Далее необходимо подвергать декомпозиции рабочий процесс. Его необходимо разбить на обработку входной и выходной информации. Далее каждый из полученных процессов разбиваем до тех пор, пока каждый полученный процесс не будет решать одну легкореализуемую подзадачу. Выделим для рассмотрения наиболее важные исполнители. К ним можно отнести: работа с почтовым сервером, работа с ЭЦП по стандарту XMLDsig, взаимодействие с базой данных. Исполнитель «Работа с почтовым сервером» может быть использован как при получении, так и при отправке электронного сообщения.

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

Таким образом, при возникновении ошибки при обработке данных, эти ошибки будут выявлены и обработаны соответствующим образом.

3.1.7 Описание структуры и форматов данных

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

По своей структуре документ в формате XML представляет дерево элементов. Некоторые такие элементы, как и в случае с HTML, имеют свои дополнительные атрибуты и могут содержать какие-то значения. Значение attr это атрибут, а вот attrval - это уже значение вышеописанного атрибута. Ну и последний элемент строки value является содержимым.

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

Для работы с базой данный используется специальный компонент StaticSet. Он является улучшенным аналогом DataSet. С помощью методов этого компонента можно легко сохранить необходимую информацию в базу данных.



3.1.8 Алгоритмизация программы

Рассмотрим алгоритмы основных исполнителей, которые были выявлены на этапе декомпозиции программы.

3.1.8.1 Алгоритм работы с почтовым сервером

Рисунок 3.4 - Алгоритм работы с почтовым сервером

Утилита sgmail.exe позволяет отправлять и получать электронные письма по протоколам SMTP и POP3.

Перед тем как использовать утилиту необходимо задать некоторые настройки в конфигурационном файле sgmail.ini:

- в секции SMTP:

а) server - имя SMTP-сервера, через который будут отправляться письма;

б) port - номер порта для подключения к серверу (по умолчанию 25);

в) authenticate - использовать аутентификацию при подключении к SMTP-серверу;

г) ssl - использовать SSL-соединение при подключении к серверу;

д) user - имя пользователя для подключения к серверу;

е) password - пароль для подключения к серверу;

ж) domain - домен пользователя-отправителя на случай, если он не содержится в имени пользователя;

- в секции POP3:

а) server - имя POP3-сервера, c которого будут получаться письма;

б) port - номер порта для подключения к серверу (по умолчанию 110);

в) user - имя пользователя для подключения к серверу;

г) password - пароль для подключения к серверу;

- в секции Options:

а) recipient - электронный адрес получателя письма;

б) inbox - каталог, куда будут сохраняться вложения входящих писем;

в) admin - электронный адрес администратора.

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

sgmail.exe send [имя файла]...

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

Для проверки почтового ящика необходимо использовать команду sgmail.exe get.

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

После завершения работы утилита сохраняет результат своих действий в лог-файл с именем sgmail.exe.log. В нем содержится подробный лог всех действий утилиты, а также ошибки, которые произошли во время выполнения.



3.1.8.2 Алгоритм работы с базой данных

Рисунок 3.5 - Алгоритм работы с базой данных

StaticSet позволяет осуществить ряд простых операций над данными, которые хранятся в нем. К ним относятся редактирование, удаление, вставка и др. На основе полученных данных о договорах и контрактах из АИСГЗ необходимо завести соответствующие документы в базе АСУБП. Для этого используется процедура вставки. Необходимые поля StaticSet заполняются нужными данными, и изменения сохраняются в базу данных. В случае некорректного завершения транзакции выводится ошибка, и данные не попадают в базу.



3.1.8.3 Работа с ЭЦП по стандарту XMLDsig

Рисунок 3.6 - Алгоритм подписи xml по стандарту XMLDsig

Рассмотрим каждый из операторов подробнее.

Рассмотри элемент ds:SignatureValue.

Этот элемент содержит саму подпись. Поскольку подписи всегда - это двоичные данные, XMLDSIG указывает, что значение подписи - это всегда простой элемент с Base64-кодированным содержимым.

<element name="SignatureValue" type="ds:SignatureValueType"/>

<complexType name="SignatureValueType">

<simpleContent>

<extension base="base64Binary">

<attribute name="Id" type="ID" use="optional"/>

</extension>

</simpleContent>

</complexType>

Чтобы интерпретировать SignatureValue, важно понимать содержимое элемента SignedInfo, который будет обсуждаться далее. Это всего лишь непрозрачная строка байтов.

<SignatureValue>

WvZUJAJ/3QNqzQvwne2vvy7U5Pck8ZZ5UTa6pIwR7GE+PoGi6A1kyw=

=

</SignatureValue>

Рассмотрим элемент ds:Signature/ds:Object.

Элемент всегда сможет существовать самостоятельно, в качествеWeb-страницы или делового XML-документа, но иногда элемент лучше интерпретировать как метаданные для подписанного «настоящего» содержимого. Например, данные могут быть «собственностью» подписи как временная метка создания подписи.

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

<ds:Object Id="ts-bin"

Encoding="http://www.w3.org/2000/09/xmldsig#base64">

V2VkIEp1biAgNCAxMjoxMTowMyBFRFQgMjAwMwo

</ds:Object>

<ds:Object Id="ts-text">

Wed Jun 4 12:11:06 EDT

</ds:Object>

Encoding определяет, как подготовить содержимое к обработке.

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

Рассмотрим элемент ds:SignedInfo.

Содержимое ds:SignedInfo может быть разделено на две части: информация о SignatureValue и информация о содержимом приложения.

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

Чтобы это обработать, содержимое должно быть канонизировано (canonicalized). Канонизация или C14N - это процесс выбора одного пути из всех возможных вариантов выхода так, чтобы отправитель и получатель могли формировать именно такое же байтовое значение. То, какое промежуточное программное обеспечение XML может быть вовлечено в это, значения не имеет.

Элемент ds:SignedInfo/ds:CanonicalizationMethod определяет то, как точно воспроизводить поток байтов. Элемент ds:SignedInfo/ds:SignatureMethod определяет, какой тип подписи - например, Kerberos или RSA - используется для создания подписи. Вместе эти два элемента указывают нам, как создать хэш и как защитить его от изменений.

<ds:SignedInfo>

<ds:CanonicalizationMethod

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n"/>

<ds:SignatureMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

Рассмотрим элемент ds:Reference

Элемент ds:SignatureValue содержит подпись, которая охватывает только элемент ds:SignedInfo: в хэш подписи включено только содержимое ds:SignedInfo.

Из описания схемы элемента ds:SignedInfoType, приведенного выше, подпись может иметь множество ссылок. Это позволяет одной XMLDSIG охватывать множество объектов: все части MIME-сообщения, XML-файл и XSLT-сценарий, который преобразовывает его в HTML, и т. д.

Элемент ds:Reference ссылается на другое содержимое. Он включает хэш содержимого, свидетельство того, что хеш был создан (например, SHA1), и определение того, как содержимое должно бы трансформировано перед генерированием хеша. Трансформации обеспечивают поразительную гибкость XMLDSIG.

Рассмотрим элемент ds:KeyInfo

На данный момент мы знаем, как сослаться на содержимое, преобразовать и хэшировать его, а также создать подпись, которая покрывает (защищает) это содержимое. Оно защищено от обратного преобразования: ds:SignatureValue включает ds:SignedInfo, который содержит ds:References, в котором находятся значения хэшей данных приложения. Изменение любого из этих элементов влечет за собой разрушение цепочки математических вычислений, и подпись не будет достоверной.

Единственное, что осталось сделать - идентифицировать подписавшую сторону или, по крайней мере, ключ, который сгенерировал подпись (или, говоря на языке криптографии, ключ, который защищает хэш от изменений). Это делает элемент ds:KeyInfo.

За проецирование имени во внутреннее хранилище и выбор подходящего ключа отвечает процесс, проверяющий достоверность подписи. К обычным значениям ds:KeyName относится адрес электронной почты или элемент справочника. Сертификаты X.509 поддерживаются элементом ds:X509Data. Этот элемент позволяет подписывающей стороне встраивать свой сертификат (в Base64) или любую из нескольких альтернативных форм идентификации сертификата: имя субъекта, имя пользователя и серийный номер, идентификатор ключа или что-либо другое. Подписывающая сторона также может включить текущую копию Списка отзыва сертификата (Certificate Revocation List - CRL), чтобы показать, что идентификатор подписывающей стороны был действителен в момент подписания документа.

3.2 Работа с базой данных

3.2.1 Описание СУБД Oracle

СУБД Oracle - ветеран рынка реляционных СУБД. Разработка этой системы была начата практически в то же время, что и IBM DB2, и по настоящее время эти системы остаются основными конкурентами.

Oracle занимает лидирующие позиции на рынке СУБД и, что особенно важно, лидирует на платформах Unix и Windows. В России также обозначилось лидерство Oracle, особенно в области крупномасштабных информационных систем. Фактически в нашей стране СУБД Oracle стала стандартом государственных информационных систем.

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

Служба технической поддержки Oracle построена на профессиональной основе. Служба технической поддержки в России сертифицирована по стандарту ISO 9000.

Кроме того, ведущие компании - партнеры Oracle, такие как FORS, RDTex имеют собственные центры технической поддержки.

Важным является и то, что наряду с СУБД компания Oracle поставляет центральный инфраструктурный продукт - Internet Application Server, сервер приложений, функционирующих в среде Internet/Intranet, а такжеCASE-средства, средства быстрой разработки приложений, средства построения хранилищ данных, оперативного анализа данных, выявления сложных зависимостей в данных (Data Mining), что позволяет поставлять не отдельные продукты, но комплексные технологические решения для заказчиков.

С технической точки зрения важно то, что Oracle функционирует практически на всех существующих компьютерных платформах, в том числе и на больших ЭВМ (OS/390), и на еще сохраняющих популярность системах Vax VMS, не говоря уже о Windows NT и различных разновидностях Unix, в том числе Solaris, HP-UX, AIX, Linux, SCO Unix и т. д.

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

Ядром СУБД Oracle является сервер базы данных, который поставляется в одном из четырех вариантов в зависимости от масштаба информационной системы, в рамках которой предполагается его применение. Для систем масштаба крупной организации предлагается продукт Oracle Database Enterprise Edition (корпоративная редакция), для которого имеется целый набор опций, архитектурно и функционально расширяющих возможности сервера. Именно Oracle Database Enterprise Edition устанавливается на кластерах (с опцией Parallel Server, по версию 8i включительно или RAC - Real Application Cluster, начиная с версии 9i и старше), позволяя создавать системы высокой готовности. Продукт Oracle Database Standard Edition (стандартная редакция) ориентирован на организации среднего масштаба или подразделения в составе крупной организации. Для персонального использования предназначен продукт Oracle Database Personal Edition (персональная редакция).

Важнейшим преимуществом Oracle перед конкурентами (прежде всего перед DB2) является идентичность кода различных версий сервера баз данных Oracle для всех платформ, гарантирующая идентичность и предсказуемость работы Oracle на всех типах компьютеров, какие бы ни входили в ее состав. Все варианты сервера Oracle имеют в своей основе один и тот же исходный программный код и функционально идентичны, за исключением некоторых опций, которые, например, могут быть добавлены к Oracle Database Enterprise Edition и не могут - к Oracle Database Standard Edition.

Таким образом, для всех платформ существует единая СУБД в различных версиях, которая ведет себя одинаково и предоставляет одинаковую функциональность вне зависимости от платформы, на которой она установлена. Разработку серверных продуктов в составе СУБД выполняет единое подразделение корпорации Oracle, изменения вносятся централизовано, после этого подвергаются тщательному тестированию в базовом варианте, а затем переносятся на все платформы, где также детально проверяются. Возможность переноса Oracle обеспечивается специфической структурой исходного программного кода сервера. Приблизительно 80% программного кода Oracle - это программы на языке программирования C, который (с известными ограничениями) является платформо-независимым. Примерно 20% кода, представляющее собой ядро сервера, реализовано на машинно-зависимых языках и эта часть кода, разумеется, переписывается для различных платформ.

Жесткая технологическая схема разработки Oracle, опирающаяся на принципы идентичности исходного программного кода для различных версий и платформ, контрастирует со схемами других компаний. Так, СУБД DB/2 представляет собой семейство продуктов, но не единый продукт. Функционально версия DB2 для IBM S/390 столь существенно отличается от DB2 для платформ UNIX и NT, что позволяет говорить вообще о разных продуктах.

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

3.2.2 Описание используемых таблиц

Каждая таблица в базе данных имеет свое уникальное. Таблицы, которые используются при разработке системы: Agreements (договора и контракты), Payment Schedule (Бюджетное обязательство), Facial Fin Caption, Facial Fin Detail, Budget Data, Bud Notify, KESR, KCSR, KVSR, KVR.

Рассмотрим каждую из этих таблиц.

В таблице Agreements содержится информация о договорах и контрактах. Для того, чтобы отличить информацию о договоре от информации о контракте используется специальное поле ProgIndex. Если значение то этого поля равно 305, то это контракт, если значение поля равно 304, то это договор.

Таблица содержит 89 полей, на ряд из которых наложены ограничения типа not null, size, domain. Ключевым полем является поле ID. Для каждой строки таблицы, значение этого поля уникально. Также таблица имеет ряд внешних ключей, обеспечивающих связь с другими таблицами базы данных.

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

Таблица содержит 93 поля, на ряд из которых наложены ограничения типа not null, size, domain. Ключевым полем является поле ID.

Таблица PaymentSchedule имеет связи с таблицами Agreements и ExecutionDocumentsCaption. Связь с Agreements осуществляется по полю AgreementRef, а связь с ExecutionDocumentsCaption по полю ExecutionRef.

В таблицах FacialFinCaption и FacialFinDetail содержится информация о платежных поручениях. Таблица FacialFinCaption содержит 70 полей. Таблица FacialFinDetail содержит 85 полей. Связь между таблицами осуществляется по RecordIndex от таблицы FacialFinDetail и ID от FacialFinCaption.

...