Максим Пайков,
руководитель отдела разработки
проекта “Гефест”
компании “ПрограмБанк”

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

Помимо представления новой технологии производства “Гефест XD”, в данной статье я буду вести речь и о новом программном продукте, являющемся очередной разработкой компании “ПрограмБанк” и представляющем собой новую подсистему в составе ИБС “Гефест”. Существенное отличие новой подсистемы –“Валютный дилинг” – от остальных модулей и подсистем программного продукта “Гефест” – это использование при ее создании технологии “Гефест XD”, которая была разработана в стенах нашей компании и впервые использовалась нами для создания промышленной версии автоматизированной подсистемы.

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

Важный момент заключается еще и в том, что технология “Гефест XD” не привязана к какому-то конкретному языку программирования, так как благодаря использованию COM спецификаций описания классов, мы получили возможность применять любые современные языки программирования для создания клиентской части приложения.

В своей нынешней работе мы ориентировались, прежде всего, на пользователей ИБС “Гефест”, т.е. на тех многочисленных клиентов компании “ПрограмБанк”, которые, взяв за основу данную систему и используя нашу технологию “Гефест XD” и инструмент прикладного программирования “Гефест XD Studio”, займутся конструированием собственных прикладных решений. Такой вариант использования ИБС – в качестве некоего конструктора, с помощью которого можно моделировать различные банковские системы, – мы считаем одним из важнейших направлений в дальнейшем развитии продукта “Гефест”, поэтому всячески поддерживаем и стимулируем его.

По опыту знаю, сложно описывать такие непростые вещи, как новая технология и созданный на ее основе программный продукт, без предварительного знакомства с основами той методологии производства информационных систем, которой пользуется в своей работе компания-разработчик. Основой методологии, используемой нами в работе над проектом “Гефест”, стала методология RUP (Rational Unified Process) – детище американской компании Rational Software Corporation, получившее сегодня очень широкое распространение во всем мире. Мне могут заметить, что применяемая нами методология базируется не на чем ином, как на общепризнанной, стандартной методологии проектирования программных продуктов, используемой и в нашем отечестве. Но мы не просто “скопировали” ее, а привнесли целый рад изменений, адаптировав “исходный материал” к своим нуждам – производству конкретных банковских систем.

Методология включает в себя анализ, описание и детализацию предметной области, построение задания на программирование и тестирование. Ведь, чтобы начать проектирование модуля системы, сначала необходимо проанализировать предметную область. И здесь для четкого, а главное эффективного проведения данной “операции” необходима правильно подобранная методология. Лучше всего, если это будет, так сказать, “родная” методология, в которой уже учтен целый ряд особенностей, таких как специфика построения ядра системы “Гефест” и особенности позиционирования системы на рынке. В этом случае не придется тратить драгоценное время на оптимизацию среднестатистической методологии моделирования предметной области применительно к банковской системе “Гефест”, для которой программируются модули или связываются приложения. Очень важно правильно подобрать и методологию детализации предметной модели, т.к. важно не только понять, что нужно кодировать, но и правильно описать сам процесс. Хорошим помощником в данном случае могут стать грамотно созданные инструкции, вернее – техническая документация по производству банковских систем, которой мы и предлагаем воспользоваться в качестве приложения к новой технологии “Гефест XD”.

Такое название – “Гефест XD”– было дано технологии не случайно. Аббревиатура XD расшифровывается как XML-документ, поскольку взаимодействие между клиентской и серверной частями в приложениях решено на основе обмена XML-документами и, собственно, само проектирование построено на базе этих сложных иерархических документов.

Новая технология “Гефест XD”, фигурально выражаясь, базируется на трех китах:

• высокопроизводительном сервере базы данных Cache, который позволяет выбирать любое программное и аппаратное обеспечение для ИБС “Гефест” (например, NT и Linux-платформы, 16 диалектов UNIX);
• ядре документооборота ИБС “Гефест”, выполняющем все бизнес-транзакции информационной банковской системы;
• наличии объектного представления модулей системы, которое позволяет использовать ядро документооборота ИБС “Гефест” из любого языка программирования.

Предлагаю вспомнить, что представляет собой, если так можно выразиться, “классическое” построение программного модуля? С одной стороны – это клиентская часть приложения, манипулирующая данными, с другой – серверная часть, на которой эти данные обрабатываются, хранятся и изменяются. При таком подходе поддержка логической целостности и, как таковое, взаимодействие клиента с серверной частью является, в большой степени, “черным ящиком”. Даже если описаны какие-то определенные интерфейсы, применить их для реализации другой задачи на практике крайне сложно, т.к. они могут функционировать только с теми модулями, для которых были изначально реализованы. И в этом я, как разработчик программных продуктов, всегда видел большой минус. Взвесив все “за” и “против”, мы решили попытаться исправить положение. На сегодняшний день мы имеем, с одной стороны, объектное описание базы данных ИБС “Гефест”, с другой – независимого интерфейсного клиента, который работает с данными банковской системы в виде объектов и понятий. Для описания последних мы и используем технологию XML-документа.

Любой серверный объект, с которым взаимодействует клиентская часть, по сути дела, представляет собой не таблицу, а многомерный, сложный зависимый объект. С помощью XML-документов мы можем осуществлять обмен данными между клиентом и сервером. Чем это выгодно? Тем, что данные всегда находятся в одном едином месте. Например, когда пользователь работает с данными конкретного клиента банка, он всегда имеет под рукой не только его характеристики, но и необходимую дополнительную информацию, которая связывает “начальную” информацию о клиенте с теми документами и операциями, которые были порождены в процессе деятельности кредитной организации. Что касается самих документов и непосредственно их хранения, то они, в данном случае, не будут разрозненны, а будут представлять собой единый логический объект со сложной иерархической структурой. К тому же, и “обрабатывать” такой объект, как с точки зрения программиста, так и с точки зрения проектировщика, становится значительно проще. Для этих объектов базы данных мы создали стандартный интерфейс, который будет доступен пользователю и из Visual Basic (одного из самых распространенных средств программирования клиентской части), и из web. Можно также применять и любые другие современные языки программирования, например, С++ и Delphi. Иными словами, мы сделали все, чтобы банковский автоматизатор, вооружившись набором определенных программных средств, мог использовать функционал системы “Гефест” в привычной для него среде разработки.

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

Всем известно, что каждый второй документ имеет сложную структуру, так как состоит минимум из двух частей – “шапки” (заголовка) и основной части. Если взять реляционную модель данных, то там подобный документ будет описываться минимум 2 таблицами (первая таблица – для “шапки”, вторая – для основной части). Но реальный документ представляет собой единый объект, который нельзя поделить на части, не потеряв при этом его общий смысл. Вот здесь-то и приходят на помощь средства ХML, которые позволяют нам описывать документ единым понятием и, соответственно, работать с ним как с единой сущностью.

Любой ХML-документ обмена представлен двумя частями: одна из них отвечает за запрос данных, другая – за ответ. На серверной части для каждого такого ХML-документа предусмотрена соответствующая процедура, которая работает непосредственно с базой данных системы. С точки зрения программиста клиентской части, сложное ядро ИБС “Гефест” представлено в виде понятных сущностей, выраженных ХML-документом обмена. Что касается непосредственной реализации, то любой XML-документ обмена выражается в виде COM-объекта. Такие объекты, реализующие COM-интерфейсы, как я уже говорил, доступны в любых современных программных оболочках, поэтому никакой проблемы с использованием таких COM-объектов не существует.

“Гефест XD Studio” представляет собой не что иное, как набор инструментов, куда входят скрипты для Rational Rose – гибкого инструмента, отличительной особенностью которого является возможность “дорабатывать” самого себя. Все инструменты находятся в тесном взаимодействии с нашей методологией и распределены таким образом, что на каждом этапе описанного нами процесса производства прикладных систем, пользователь должны просто периодически выбирать используемые средства, обращаясь все к тому же набору “Гефест XD Studio”.

К сожалению, рамки журнальной статьи не позволяют мне подробно представить первую версию новой подсистемы “Валютный дилинг”, основанную на ядре документооборота системы “Гефест”. Придется ограничиться лишь кратким описанием. Начну с того, что подсистема способна автоматизировать все операции, связанные с дилинговым подразделением кредитного учреждения, в рамках единой системы. Она была разработана с использованием Интернет-технологий, что было уместно и своевременно для решения задачи автоматизации работы дилингового подразделения банка, где зачастую бывают территориально удалены рабочие места дилеров.

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

В подсистеме “Валютный дилинг” реализованы следующие функциональные возможности:

• Оформление сделок в бэк-офисе:
• регистрация сделок и оперативное представление информации по ним,
• подготовка подтверждений сделок, платежных документов, распоряжений на перевод средств по корр.счетам,
• получение от контрагентов подтверждений и платежных документов, включая их проверку и учет.
• Хранение оперативной и справочной информации;
• Контроль разнообразных позиций и лимитов;
• Прием и квитовка платежей контрагентов по сделкам;
• Оперативный бухгалтерский учет сделок и многое другое.

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

Пытаясь обустроиться собственными силами, подавляющее большинство отечественных банков создало мощные подразделения автоматизации, в обязанности которых вменяется удовлетворение все новых и новых пожеланий не только целых отделов, но и отдельных сотрудников банка. Опережающие возможности, если так можно выразиться, интегрированных АБС нового поколения, представленных сегодня на рынке, к числу которых относится и система “Гефест”, плюс наличие квалифицированного штата программистов в банке – такой “тандем” вполне способен справиться с текущими задачами автоматизации в конкретном финансовом институте. Без привлечения помощи со стороны, в лице сотрудников компаний-разработчиков программного обеспечения. Тем более что банковское руководство, знаю это по личному опыту, зачастую посещают сомнения по поводу рациональности “содержания” собственных автоматизаторов, если за любой “мелочью” в процессе доработки системы все равно нужно обращаться к компании-разработчику. Хотя банковских автоматизаторов можно понять: развивать собственными силами ядро сложной интегрированной системы, не имея под рукой четких инструкций, необходимых инструментов и схем – дело не из легких.

Предлагаемая нами технология “Гефест XD”, представляющая, еще раз повторюсь, законченный цикл создания программного продукта любой степени сложности, является логическим продолжением концепции нашей работы по усовершенствованию системы “Гефест”, итогом которой должно быть создание универсального конструктора автоматизированных систем. Нам не довелось быть пионерами в данной сфере, но мы смогли добиться конкретного результата, который, фигурально выражаясь, можно “взять в руки”. Я имею в виду промышленную версию подсистемы “Валютный дилинг”, созданную по новой технологии производства прикладных систем “Гефест XD”.

Дополнительную информацию Вы можете получить в компании Interface Ltd.

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