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

Роль информационно-вычислительных систем в жизни человека.

На современном этапе развития человеческого общества информационно-вычислительные системы (ИВС) играют важную роль в самых разнообразных сферах деятельности. Это геоинформационные и метеорологические, транспортные и финансовые, а также многие другие системы. По количеству работающих крупных программно/аппаратных комплексов Россия значительно отстает от западных стран, но в течение нескольких последних лет этот разрыв начал сокращаться.

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

Типичный пример: в последнее время в средствах массовой информации все чаще появляются статьи, посвященные так называемой «проблеме 2000 года». Проблема заключается в некорректной работе компьютерных программ, использующих двузначный способ хранения года, после 31 декабря 1999.

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

Проблема 2000 года" является на данный момент наиболее актуальной для множества ИБС, однако это частная проблема. Ее можно было бы легко избежать, если бы на этапе проектирования соответствующих систем было учтено то, что они могут продолжать работать в следующем столетии, и определены необходимые требования к программному обеспечению (ПО). Сложившаяся ситуация, при которой на решение «проблемы 2000 года» тратится огромное количество человеко-часов показывает, насколько важно правильно спроектировать ИБС, обеспечить достаточную гибкость и настраиваемость ПО.

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

Программные комплексы сбора, хранения и обработки информации.

Далее в работе речь будет идти о подмножестве информационно-вычислительных систем — распределенных программных комплексах сбора, хранения и обработки информации. Общая схема такого комплекса изображена на Рис. 1.

Рис. 1. Уровни иерархии программного комплекса сбора, хранения и обработки информации.

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

— большое количество рабочих мест, на которых выполняются различные функции-, .

— типичный набор функций следующий:

— получение первичной информации в электронном виде (ручной ввод, снятие показаний приборов и т. д);

— передача информации на вышестоящий уровень (через определенные интервалы времени или по запросу, при этом интервалы времени достаточно велики1);

— обработка полученной информации (проверка, преобразование, загрузка в БД, консолидация, анализ, формирование выходных документов и т. д.)2;

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

— рабочие места могут находиться на значительном удалении друг от ДРУга;

— условия эксплуатации программных компонент на различных рабочих местах могут отличаться очень значительно.

Под «значительно отличающимися условиями эксплуатации» в последнем пункте подразумевается следующее.

Как правило, при создании крупных программных комплексов, разработчики по очевидным причинам стараются в максимальной степени унифицировать способы хранения информации (БД) и работающие с ней программные компоненты [34, 35, 36, 37, 54, 57, 58, 62, 65, 69, 70, 79, 80].

Выбирается одна хорошо масштабируемая СУБД. К примеру, компания Oracle предлагает широкий спектр полностью совместимых снизу вверх вариантов своей СУБД: Personal Oracle Lite, Personal Oracle, Oracle Workgroup Server, Oracle Server Enterprise Edition. Каждый вариант предназначен для вычислительной техники определенного класса. И если программа работает, к.

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

2 Если уровней иерархии много, то циклы создания (консолидации) / передачи / обработки информации повторяются несколько раз. примеру, с Personal Oracle, то она будет точно так же работать с Workgroup Server [61, 71, 72].

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

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

— Установке мощной СУБД на удаленных объектах мешает отсутствие квалифицированного персонала, который необходим для ее администрирования.

— На большом количестве объектов автоматизации программно-аппаратная база не позволяет установить сервер СУБД, при этом ее обновление заказчиком не предусматривается.

— Заказчик хочет сэкономить средства на лицензиях на СУБД. Как уже говорилось, ввиду особенностей архитектуры распределенных программных комплексов сбора, хранения и обработки информации, количество территориально распределенных рабочих мест растет по мере перехода на все более удаленные от «вершины» уровни системы. Если учесть, что на каждом пункте обработки информации должен быть установлен сервер СУБД, то становится ясно, что начиная с некоторого уровня иерархии системы, затраты на серверные лицензии станут чрезмерными.

В подобных случаях автором предлагается следующий компромиссный подход: на объектах автоматизации с мощной программно-аппаратной базой и квалифицированным персоналом, устанавливается промышленная реляционная СУБД, поддерживающая стандарты DML (Data Manipulation Language) и DDL (Data Definition Language), а в прочих местах — используются простые БД файлового типа (напр., Paradox или DBase).

Далее для краткости будем употреблять термины, соответственно, СУБД и БД файлового типа. Вариант ПО, использующий СУБД, будем называть «полным», а вариант, использующий БД файлового типа — «облегченным» .

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

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

1. В странах с развитыми информационными технологиями, стоимость создания ПО намного выше стоимости аппаратного обеспечения. Поэтому при создании крупных вычислительных комплексов обычно аппаратные платформы подстраиваются под выбранную архитектуру программных решений. Таким образом, необходимость в «компромиссных» программных решениях отпадает. В России ситуация обратная — ПО создается с учетом того, что оно будет работать в рамках существующей инфраструктуры аппаратных средств.

2. Большая часть книг, посвященных средствам быстрой разработки приложений (RAD), имеет своей целью охватить как можно шире функциональные возможности этих средств, не рассматривая подробно механизмы функционирования отдельных их частей [9, 17, 18, 49, 51, 62,66, 81].

3. В качестве примеров в таких книгах приводятся демонстрационные программы, работающие с небольшими объемами данных, для которых вопрос производительности несущественен [17, 18, 51].

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

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

Как выяснилось при разработке реальной системы, работающей с большими объемами данных (порядка гигабайт), незнание механизмов этого обмена может легко привести к тяжелым последствиям. Такие средства как Borland Delphi обладают огромной гибкостью и позволяют быстро и легко реализовать на первый взгляд красивые идеи, оказывающиеся в будущем совершенно неработоспособными.

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

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

Практически любая ИВС состоит из компонент. Компоненты можно разделить на 2 класса: «заказные» и «универсальные» .

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

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

Соотношение заказных и универсальных компонент в различных проектах может быть самым разным. Например, в сложных расчетных системах обычно присутствуют в основном заказные компоненты.

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

Цели и содержание работы.

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

— мощность вычислительной техники и квалификация персонала в центрах обработки информации (ЦОИ) разных структурных подразделений сильно отличаются (во многих ЦОИ установка или администрирование промышленной СУБД невозможны). Также значительно отличаются объемы обрабатываемой информации;

— результирующая мощность и стоимость комплекса определяется заказчиком;

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

Для достижения поставленной цели были определены и успешно решены следующие задачи:

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

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

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

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

— проектирование комплекса;

— реализация программных компонент комплекса:

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

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

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

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

— разработка модуля раскрытия информации;

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

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

В ходе работ над проектом АС ДКДКОФР были применены современные методы проектирования и разработки. Это:

— Быстрая разработка приложений (RAD-rapid application development)3;

— Реляционное проектирование с использованием CASE-средств;

— Разработка приложений клиент/сервер.

Литература

использовавшаяся в ходе работы, представляет из себя большой набор узкоспециализированных изданий по различным технологиям, средствам и направлениям деятельности в рамках разработки ИБС. Это литература по современным методам проектирования и создания информационно-вычислительных систем, CASE-средствам, базам данных, средствам разработки ПО. Также анализировалась периодическая литература и материалы технических конференций в области информационных технологий. Большая часть литературы была получена в электронном виде из сети Internet.

3 Методология RAD описана в п. 3.2.

Выводы по главе 4.

1. На базе предложенного в работе подхода спроектирован, разработан и внедрен распределенный программный комплекс сбора, хранения и обработки отчетности кредитных организаций-эмитентов ценных бумаг ДКДКОФР ЦБ РФ. Таким образом, целесообразность применения данного подхода полностью подтверждена практически.

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

3. Показано, что программные модули в полной мере используют преимущества интерфейса Windows95/NT4, являются в большой степени настраиваемыми. Активно используется взаимодействие с современными офисными средствами (Winword, Excel). Обеспечивается высокий уровень быстродействия при работе как с таблицами Paradox, так и с СУБД Oracle.

Заключение

.

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

— мощность вычислительной техники и квалификация персонала в центрах обработки информации (ЦОИ) разных структурных подразделений сильно отличаются (во многих ЦОИ установка или администрирование промышленной СУБД невозможны). Также значительно отличаются объемы обрабатываемой информации;

— результирующая мощность и стоимость комплекса определяется заказчиком;

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

В работе получены следующие основные результаты:

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

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

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

4. Рассмотрен рынок современного программного обеспечения для проектирования и реализации программных систем. Обоснован выбор программных средств, которые целесообразно использовать в рамках предложенного подхода. Проведен анализ влияния типа БД на принципы и механизмы функционирования ПО. Проанализированы особенности разработки ПО. Разработаны принципы рационального построения системы в рамках предложенного подхода.

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

6. В работе разработаны универсальные модели, позволившие создать компоненты «Конвертер данных» и «Генератор отчетов», которые могут работать как на различных уровнях иерархии сбора и обработки информации созданного комплекса, так и в других комплексах подобного типа без изменения кода.

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

Перечень использованных сокращений.

АС Автоматизированная система.

БД База данных.

ДКДКОФР Департамент контроля за деятельностью кредитных организаций на финансовых рынках.

ЖЦ Жизненный цикл иве Информационно-вычислительная система ко Кредитная организация.

ОС Операционная система по Программное обеспечение.

СУБД Система управления базами данных.

ТУ ЦБ РФ Территориальное учреждение Банка России.

ЦА Центральный аппарат (Банка России).

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