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

Новые информационные технологии ДРС

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

Начальник отдела Программной поддержки и Развития ОЮЛ “Депозитарно-расчетный союз”
к.т.н. Ермаков А.Н.
Введение


Многим читателям Вестника уже знакома программа BROLLER по публикациям [5,6] и в связи с ее использованием для организации электронного документооборота в бэк-офисах брокерских компаний. Настало время приоткрыть занавес и рассказать об истории возникновения и технических аспектах создания системы.

Предпосылки

90-ые годы прошедшего века в России были отмечены бурным ростом числа компьютерных программ для информационной поддержки и управления организационно-финансовой деятельностью предприятий. Диапазон возможностей этих программ широк не только по охвату задач, но и по составу, по моделям учета, глубине проработки и по механизмам реализации обмена информацией [1]. Постепенно с развитием компьютерных технологий разработчики приложений мигрировали и еще мигрируют в направлениях DOS => Windows, файловые структуры => базы данных SQL1, двухуровневая => трехуровневая архитектуры приложений клиент/сервер, текстовый => графический интерфейс рабочего стола. (Что касается Запада, то там история компьютеризации побогаче, много приложений на больших универсальных компьютерах для больших БД. Многие системы и не пытаются идти к GUI2).

Напомним, что стандартная архитектура предусматривает, что сложные приложения требуют для реализации двух слоев: один (предварительная обработка) – для приложения рабочего стола, другой (окончательная обработка) – для БД. Однако отметим, вместе с Дэвидом Васкевичем [2], что эта архитектура не располагает к необходимой гибкости и быстроте при сопровождении и перепроектировании сложных приложений: в ней нет выделенного места для правил бизнеса, которые для разных предприятий бывают самыми специфическими.

Новая3трехслойная архитектура приложений [2], в которой специально создается слой для правил бизнеса, представляется более интересной:


Слой
Отвечает за Содержание Функции
Документ

Понятный, эффективный интерфейс

Приложения рабочего стола и Graphical User Interface

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

Правила бизнеса

Политику принятия решений и эвристические процедуры

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

Принятие решений, проведение политики, координация ресурсов и документов

Управление данными

Согласованность и защищенность данных

СУБД (SQL) – хранение и извлечение данных, OLTP

Согласованность, секретность, целостность и безопасность



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

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

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

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

возможность пользователей изменять набор бизнес-правил приложений;

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


В настоящей статье мы описываем наш вклад в реализацию трехслойной архитектуры, предоставив вниманию читателя технологию Fansy [3,4], как основу подхода к комплексной автоматизации профессионального участника РЦБ.

^ Требования (что хотели)

Проект Fansy стартовал в 1995г., когда появление нового средства визуальной разработки Delphi вселяло надежду на технологический прорыв в скорости разработки проектов даже небольшим коллективом разработчиков. В то время широко использовались системы Clipper и X-Base, которые ставили больше задач (ошибки индексов и нарушение целостности данных при сбое вычислительной системы), чем давали решений. К новому проекту мы выдвинули следующие требования4:

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

2. Основа реализации приложений – Delphi, основа реализации отчетов – MSOffice, основа реализации бизнес-правил – Fansy-script, основа хранилища данных - SQL.

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

4. Использование объектно-ориентированного подхода не только в сфере организации приложений, но и в сфере организации хранилища данных: использование единого глобального первичного ключа всех взаимосвязанных таблиц базы данных5 позволит упростить средства анализа данных и унифицировать ядро приложения. Использование объектов для хранения истории изменения реквизитов некоторых наиболее важных таблиц, а так же для расширения классификационных признаков предметных таблиц БД без изменения структуры БД (классификаторы).

5. Реализация высокопроизводительного универсального бухгалтерского ядра, позволяющего в одних и тех же структурах представлять информацию об остатках и оборотах, хранить данные о разнородных ценностях (деньги, ценные бумаги, товары) и поддерживать несколько учетных плоскостей. Реализация А6 и Т7 типов аналитик. Идея метаданных должна позволять пользователю менять и настраивать схемы бухгалтерского учета.

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

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

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

9. Принцип мобильности: использование стандарта SQL-92 для написания запросов к данным. Цель – обеспечение независимости системы от SQL-платформы.

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

^ Реализация (что получилось)

В 1997г. реализация проекта была в основном завершена. В качестве SQL – платформы выбрали InterBase9. Реализовали интерпретатор и визуальный отладчик языка Fansy-script. Разработали визуальный редактор базы метаданных (ADMIN) - конструктор финансовых приложений. В итоге:

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

2) база метаданных достигла 40 таблиц, и содержала 300 форм приложений, 450 запросов, 170 отчетов и около 1000 метафункций на языке Fansy-script;

3) база данных содержала 150 таблиц, 50 представлений, 650 триггеров и 150 процедур.

4) утилита ADMIN была разработана как Fansy – приложение (bootstrapping10), что способствовало начальной отладки кода и проверке заложенных идей.

Практически все из задуманного было реализовано. Что не удалось:

1) Не удалось достичь следования исключительно стандарту SQL-92. Мы задействовали мощную возможность InterBase, позволяющую использовать процедуры с параметрами (возвращающими отношение) в запросах к данным (своего рода динамические курсоры11). Эту возможность мы заложили в основу всех средств анализа (аналитика).

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

3) Отсутствие в InterBase ссылок между базами привело к расщеплению метаданных на два вида: метаданные о схемах бухгалтерского учета и сценариях документооборота пришлось разместить в базе данных и написать еще один редактор (BALTUN) – конструктор схем бухгалтерского учета и сценариев документооборота.

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

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


Слой
Функции Инструмент
Документ

Представление – форматированный ввод-вывод данных. Навигация – переход между связанным документам. Манипулирование – возможность создавать и изменять информацию.

Анализ – использование классификаторов.

Графические средства Delphi, Fansy-script –для обработки событий,Visual-Basic – для формирования отчетов

Правила бизнеса

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

Fansy-script

Управление данными

Согласованность (целостность) – защита транзакций, секретность (безопасность) – обеспечение физического и логического уровня защиты данных

Языки SQL, Transact-SQL



^ Наши продукты

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

Fansy-BROKER – модуль Бэк-офисного учета [5,6]. Полный электронный документооборот бэк-офиса компаний, осуществляющих брокерскую, дилерскую деятельность и деятельность по управлению ценными бумагами. Три плана счетов: “Расчеты по деньгам”, “Расчеты по бумагам” и “Технические расчеты”, образуют основу для синтетического и аналитического анализа состояния бэк-офиса. Выбор метода расчета средней себестоимости (метод среднего, ЛИФО, ФИФО). Учет операций с любыми видами ценных бумаг на биржевом и внебиржевом рынке. Учет требований ФКЦБ и НАУФОР. Полный набор требуемой отчетности. Управление собственными инвестиционными портфелями, брокерское обслуживание клиентов, ведение клиентских портфелей ценных бумаг. Система позволяет импортировать/экспортировать данные (в том числе и содержимое документов) произвольных форматов, этот механизм может быть использован для экспорта лимитов во фронт-офис Интернет-Брокера (опробовано на «ИТС-Брокер»). Великолепный пример взвешенного использования А и Т аналитик, мощное применение технологических возможностей по расчету клиентских тарифов: 15 источников данных и 5 расчетных схем, позволяющие получить 75 различных тарифных планов.

Fansy-DEPO – модуль депозитарного учета [7]. Интересный эксперимент по скрещиванию банковского плана счетов (который вслед за ЦБ навязывается12 депозитариям ПАРТАД -ом), с принципиальной необходимостью все-таки связывать Депо-счета владельцев с информацией о месте хранения ценных бумаг13. Отличный пример работы Т-аналитики. Учет требований ПАРТАД, ФКЦБ и ЦБ. Полный набор депозитарной отчетности.

Fansy-BALANCE – модуль бухгалтерского учета для нового плана счетов [7]. Самый молодой и быстроразвивающийся проект. Пока реализован базовый уровень бухгалтерского документооборота, связанный с рутинными процедурами учета брокеров и депозитариев: учет ценных бумаг, ведение книги продаж (покупок), выставление счетов, кассовые операции. Уже сделан расчет зарплаты, за бортом пока учет материалов и товаров. Впрочем, если вы любопытны и у вас есть время - документы можно добавить самостоятельно.

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


Комплекс приложений BROKER+DEPO+BALANCE представляет достаточно полный набор средств автоматизации деятельности профессионального участника рынка ценных бумаг. Важной особенностью является возможность всех приложений работать с единым хранилищем данных (работает идея раздельных учетных плоскостей). Это дает весомые преимущества: 1) автоматическое заполнение аналитических плоскостей всех приложений при изменениях в данных в любом из них (субъекты, ценные бумаги, сделки, контрагенты); 2) общие документы могут порождаться в одном приложении, а использоваться в другом (счета, поручения, приказы, распоряжения, классификаторы).

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

Заключение

Демо-версии наших продуктов доступны на сайте www.drs.ru (раздел Software) и записаны на прилагаемый к журналу компакт-диск. Все приложения в демо-исполнении являются полнофункциональными, т.е. не имеют функциональных ограничений по сравнению с промышленными приложениями. Начав работать с демо-версией приложения, не бойтесь потери данных в дальнейшем. При переходе к промышленной версии системы мы гарантируем сохранность и переносимость ваших данных. Если вы решили начать с более “легкой” СУБД InterBase, то вы не теряете возможность в любой момент перенести базы данных приложений в MSSQL.

Литература



Компьютерные программы для бухгалтеров и бизнесменов: Каталог фирмы “Бизнес-Программы-Сервис”. М.: 1993.

Д. Васкевич. Стратегии клиент/сервер. Руководство по выживанию для специалистов по реорганизации бизнеса. К.: “Диалектика”, 1996.

Технология построения приложений FANSY. Ермаков А.Н., Вязьмин Д.С., Крылов С.Н., Тюфягин В.А. Тезисы докладов “Научная сессии МИФИ-99”, М.:1999. Том 7 с.256-257

Технология документооборота распределенного офиса. Ермаков А.Н., Вязьмин Д.С., Тюфягин В.А. Тезисы докладов “Научная сессии МИФИ-99”, М.:1999, Том 7.

Учетная политика и план счетов бэк-офиса брокера. Вестник НАУФОР №1 (33) 2000, стр.40-44

Документы+Проводки+Аналитика= Бэк-офис. Вестник НАУФОР №7 2000, стр.58-62.

Новые SQL решения для малого и среднего бизнеса. Вестник НАУФОР №7 2000, стр.3 обложки.

1 SQL – структурированный язык запросов в реляционных СУБД, SQL база - средство надежного хранения данных и структурного подхода к запросам.

2 Graphical User Interface – графический интерфейс пользователя.

3 В то время даже флагманы российского программирования (DiaSoft и R-Style) предлагали решения в двухслойной архитектуре.

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

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

6 А аналитика (от слова account) используется, например, в 1С Бухгалтерии под названием «субконто».

7 T аналитика (от слова transaction) используется, например, в Турбо-Бухгалтере.

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

9 InterBase - достаточно простая и надежная СУБД, работающая на любых платформах (Windows, Unix, Novell), распространяется производителем бесплатно, не требует трудоемкого сопровождения. Идеальное решение для малого и среднего бизнеса.

10 Процедура реализации системы средствами самой системы, в буквальном переводе – “вытаскивание себя за шнурки собственных ботинок”.

11 Честно говоря, мы думали, что так сделано во всех SQL-базах, впрочем, эффективность и простота данного механизма позволяет верить, что вскоре это станет стандартом.

12 Это неявно следует из требований по раздельному учету бумаг по депо счетам мест хранения и депо счетам владельцев.

13 Эта связь важна в двух аспектах: 1) для брокеров принципиальное значение имеет знание и местонахождении ценных бумаг конкретного инвестора; 2) эта информация существенно влияет на тарифы конкретного инвестора за хранение бумаг.

14 MSSQL – высокопроизводительная, мощная СУБД. Требует квалифицированного сопровождения. Работает только в Windows NT. Приемлемое решение для среднего и крупного бизнеса.