1

Техническое описание системы «Мебиус-Банк»

1. Архитектура системы

АБС “Мебиус-Банк” представляет собой 3-х уровневую систему (см. рисунок 1).

Рис. 1 Архитектура системы

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

пользователя, т.о. система состоит из:

1-й уровень - клиентское ПО

2-й уровень - уровень сервера приложения (состоит из диспетчера и серверов

приложения)

3-й уровень - Сервер БД, “STAND BY” сервер

Клиентское ПО предназначено для:

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

Запуск банковских операций (открытие депозита, оформление кредита и т.д.)

Отображение результата расчета отчетов (аналитические отчеты, отчетность НБУ)

Печать (выписка, отчеты и т.д.)

Прием/формирование сеансов данных

Важно заметить, что клиентское ПО не работает напрямую с БД, а также не выполняет

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

выполнения, ввод (добавление/редактирование/удаление) информации в соответствии с

правами пользователя и печать полученных результатов.

2

2-й уровень системы «Мебиус-Банк» состоит из 2х прикладных модулей: диспетчер и

сервер.

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

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

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

размещена на нескольких компьютерах сети.

Диспетчер решает следующие задачи:

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

системе

Сервер событий (подробнее см. в разделе «Основные механизмы системы»)

Наблюдение за клиентскими сессиями и эффективная утилизация ресурсов

системы (если на сервере остаются неосвобожденные объекты после нештатного

отключения клиентского приложения – из-за сбоя сети или других ситуаций).

Сервер приложения решает следующие задачи:

Работа с прикладными объектами (обычными и архивными)

Расчет отчетов

Обеспечение доступа к БД для объектов системы

Выполнение TCL-скриптов (TCL – встроенный в систему интерпретируемый язык

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

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

Эффективное управление памятью

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

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

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

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

В качестве среды общения клиентского ПО и сервера используется CORBA.

CORBA является кроссплатформенным решением, т.о. сервер приложения может быть

запущен под UNIX-подобными ОС.

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

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

объемов данных.

3-й уровень представляет собой систему хранения данных. В качестве БД система

«Мебиус-Банк» использует БД Oracle. Данная БД является мировым промышленным

стандартом хранения данных. Повышенная надежность работоспособности БД

обеспечивается дополнительной БД (STAND BY), которая зеркально отображает все

операции по основной БД. В случае выхода оборудования, где запущена основная БД,

можно оперативно переключится на «STAND BY».

3

Почему система 3-х уровневая, а не 2-х уровневая

(преимущества 3-х уровневой системы «МебиусБанк» перед 2-х

уровневыми) Простота установки и администрирования. Для установки или обновления

клиентского рабочего места (исчисляются сотнями) нужно просто выполнить

копирование библиотек. Oracle Client устанавливается только на компьютерах

уровня сервера приложений (исчисляются единицами).

Возможность работы удаленных рабочих мест без дополнительных

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

клиентом и сервером приложений оптимизирован, также этот поток есть

возможность архивировать и шифровать. Таким образом, данные, передаваемые по

сети, оптимизированы, сжаты и защищены.

Повышенный уровень защиты информации. Пользователь не имеет прямого

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

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

сервер БД. На уровне сервера приложений сосредоточена основная логика и ряд

операций выполняется без обращения к БД:

- проверка бизнес-логики, сверка вводимых данных со справочниками

- построение отчетов по выборкам

- выполнение алгоритмов обработки данных

- выполнение банковских операций

Распределение мощностей сервера БД между отделами и направлениями. Количество серверов приложений может быть любым, и на каждом можно

определить количество подключений к БД.

2. Возможности системы, структура и состав.

2.1. Свойства системы

Систему отличают следующие свойства:

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

Гибкость настроек и параметризации

Большие аналитические возможности

Высокий уровень безопасности

Простота администрирования и сопровождения

Открытость, возможность быстрого наращивания функциональности

2.2. Структура системы (основные объекты и их связи)

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

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

Оперативные данные содержат информацию о клиентах, счетах, платежах, договорах и

пр.

Настройки системы охватывают все возможные уровни параметризации: состав

(хранение) данных, поведение объектов и процессов, и их представление.

Центральным объектом настройки для бизнес-продуктов являются „виды (шаблоны)

сделок”, которые максимально гибко описывают все этапы жизни конкретного

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

параметризации следует отметить: схемы поведения, описание объектов (сущностей),

алгоритмы (операций, отчетов и др), образы задач, форм и пр.

4

Рис 2. Упрощенная схема связей сущностей системы (оперативных и настроечных

данных)

2.3. Объекты системы

Основные сведения

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

полностью реализует определенную предметную сущность, какой в АБС являются

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

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

серверный объект, вне зависимости от источника обновления (будь-то клиентская форма,

банковская операция, сеанс загрузки). Со стороны пользователя имеется клиентская

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

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

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

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

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

разработчика. Подробнее см. п. ”Динамические объекты” и ”Основные механизмы

системы. Динамические формы”.

Архивные объекты

Для достаточно большого перечня объектов в системе поддерживается хранение

истории изменений его реквизитов. Такие объекты называют архивными объектами.

Архивный объект - это объект системы, имеющий набор полей, значения которых могут

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

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

5

объекта может служить лицевой счет, реквизиты которого изменяются с течением

времени, но при этом желательно иметь актуальное значение этих реквизитов на любую

дату.

Архивный объект имеет, как правило, две таблицы, одна из которых фиксирует

постоянную часть данных, а другая - историографическую (изменяемую) часть. В

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

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

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

записей для одного дня.

Динамические объекты

В системе присутствует понятие динамического объекта. Объект не статичен.

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

обслуживает) можно расширять. При этом дополнительное поле является полноценным

реквизитом объекта: оно может участвовать в фильтрации, сортировке, отчетах и

печатных формах, влиять на логику операций с объектом. Добавляемое поле может быть

ссылкой на другой объект системы (например, справочник).

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

входит в набор задач по администрированию системы.

Рис 3. Добавление нового поля в объект

Состояния объектов.

Состояния - базовые точки функциональности объекта.

Каждый объект имеет набор состояний, в которых он может находиться в течение

времени своего существования. Например, для объекта “счет” возможны состояния:

“введен”, “действующий”, “закрыт”. Одним из состояний объекта может быть "удален".

6

При переводе объекта в состояние удален, физически данные объектов из базы данных

не удаляются, а только отмечаются в состоянии "удален", с сохранением всей истории

изменения объекта.

Модель поведения.

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

процесс, происходящий с объектом. Все возможные переходы между состояниями

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

реализуют соответствующие функции самого объекта.

Рис.4 Модель поведения объекта «Лицевой счет»

Разновидности объектов

Для объекта существует понятие разновидности объекта - более детальная его

характеристика, конкретизирующая функциональность. Например, для объекта счет

существуют разновидности "расчетный счет", "кассовый счет", "ссудный счет" и т.д.

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

визуального отображения конкретной разновидности возможен свой макет экранной

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

”Основные механизмы, Динамические формы”).

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

от модели основного объекта (может не быть некоторых состояний и некоторых

переходов). В принципе, можно переопределить и реакцию разновидности объекта на

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

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

определяется разновидностью, к которой он относится.

7

Журналирование объектов В системе имеется системный журнал, в который фиксируется изменение любого

реквизита объекта. В журнале отражаются реальные дата и время изменения, дата ОДБ,

пользователь, действие над объектом, сообщение, сопровождающее это действие. В

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

реквизиты объекта и их значения.

Просмотр журнала возможен как за период по всем объектам системы, так и из

клиентских форм ведения объектов по конкретному объекту.

2.4. Основные механизмы системы

Списки

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

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

"Счета кассы" (список), "Пользователи подразделения Х" (группа).

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

временные интервалы.

Список может конфигурироваться по любому реквизиту объекта, включая

дополнительные (см. п. ”Объекты системы, Динамические объекты”). Он может

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

счетов по списку клиентов).

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

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

Использование списков в системе многообразно - для фильтрации данных, для

организации доступа (проверки прав), для аналитических расчетов и т.д.

Динамические визуальные формы

В системе реализован механизм динамических визуальных форм. Этот механизм

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

компоненты отображения/редактирования для параметров объектов) и создавать новые.

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

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

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

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

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

форма журнала операции, форма для запроса параметров операции).

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

и редактирования форм любой сложности: присутствуют "закладки" (PageControl),

“списки выбора” (ComboBox), простые компоненты ввода, таблицы (Grid), элементы для

группирования, “переключатели” (CheckBox, RadioButton) и др.

На базе этого механизма также конструируются макеты экранных форм

разновидностей объектов (карточки Счетов, Договоров, Проводок и др.). Базовый

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

корректировки на местах.

С помощью данного механизма возможна визуализация и редактирование полей,

добавляемых пользователями (см. “Объекты системы. Динамический объект.”). При этом

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

8

Рис.5 Редактор форм. Редактирование формы ведения лицевых счетов.

Базовые формы

В системе предусмотрено единообразие клиентского интерфейса с конечным

Пользователем АБС. Для этого работа с объектом со стороны клиента производится через

клиентскую форму, в большинстве случаев созданной на основе разработанной базовой

формы.

В системе имеется несколько видов базовых форм – базовая форма описи, архивной

описи, базовая форма отчета, базовая форма журнала операции. Каждая из них реализует

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

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

алгоритма. Тем самым ускоряется разработка новой клиентской формы, снижается время

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

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

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

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

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

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

Сортировка данных для объекта возможна по любому полю или комбинации полей

(вложенная сортировка данных). Реквизиты, добавленные Пользователями (см. “Объекты

системы. Динамический объект”), также могут быть включены в сортировку.

9

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

реквизитов, на которые устанавливается фильтр, практически не ограничен. При большом

наборе реквизитов панель фильтра разбивается на несколько подзакладок.

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

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

набор логических действий, выполняемых фильтром: “>”,“<”,“=”,“>=”,“<=”,“между”,“по

маске”,“есть”,“не есть”.

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

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

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

вспомогательного окна со списком объектов (счетов, клиентов) содержащим фильтр по

этому объекту.

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

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

фильтру на объект.

Списки также могут быть одним из полей фильтра. Таким образом, можно, например,

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

инсайдеров.

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

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

TCL-интерпретатор

В АБС имеется встроенный интерпретатор на основе стандартного языка Tcl/Tk.

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

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

платформах.

Интерпретатор Tcl, взятый за основу, был расширен функциями доступа к элементам

системы (прикладным объектам, объектам аналитики, работа с БД), работы с внешними

источниками данных (dbf, текстовые файлы).

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

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

исполнять TCL-скрипт «по-шагам», использовать точки останова, просматривать значения

переменных и наборов данных (блоков), изменять значений переменных и выполнять

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

На языке tcl в системе описываются алгоритмы расчета аналитических отчетов,

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

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

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

Процессор Банковских Операций

Основой ядра системы является Процессор Банковских Операций (ПБО).

Банковская операция – последовательность действий (вычислений, манипуляций над

объектами системы, диалогов с пользователем), результатом которой может быть

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

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

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

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

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

10

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

поэтому для каждой операции можно проследить в каком состоянии она находится

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

пройдены, какие объекты обработаны или созданы.

Результат выполнения конкретной БО можно просмотреть в специальной задаче-

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

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

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

фиксированный набор платежей) предусмотрен механизм «простых типовых операций

(схем)». Механизм позволяет легко настраивать подобные операции без задания блок-

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

Экспорт/импорт данных

Механизм экспорта/импорта данных из других источников (dbf-файл, текстовый файл

и др.) предназначен для приема в систему информации из сторонних источников

(информация из других систем, справочники НБУ, курсы валют), а также выдачи из

системы информации в определенном формате.

Система имеет возможностью гибкой настройки принимаемых и выводимых данных

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

экспорта/импорта и соответствующего объекта системы.

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

поэтому принимаемые данные проходят дополнительную обработку и контроль на уровне

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

отличается от их пользовательского ввода.

Генератор печатных форм

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

генератор печатных форм "FastReport", который позволяет конечному пользователю:

создавать новые и модифицировать существующие шаблоны отчетов;

создавать диалоговые формы для запроса параметров отчета у пользователя;

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

логикой работы диалоговых окон.

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

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

Шаблоны сделок

Работа банковских операций в рамках конкретных подсистем (кредиты, депозиты, РКО

и др.) опирается на шаблоны сделок. Шаблон сделки – это широкий перечень правил,

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

при последующих операциях над договором (пролонгация, пополнение, выдача или

погашение процентов, вынос на просрочку и др.). Параметры, задаваемые в шаблоне

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

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

или методолог непосредственно в банке.

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

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

проверяет их на ограничения, контролирует полноту заполнения всех реквизитов. В

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

платежи, дает возможность печати пакета документов. Использование БО ускоряет

11

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

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

Рис.6 Настройка шаблона кредитной сделки

Построитель аналитических запросов

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

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

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

данных и языка SQL. Построитель опирается на экономические показатели (остаток,

балансовый счет, код валюты, срок договора и т.д.). Все экономические показатели

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

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

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

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

параметра: что нужно выбрать и по каким условиям. На базе перечня экономических

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

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

12

Рис. 7 Пример использования построителя запроса – команда для Tcl-алгоритма

(EFBlock R020,R030,S180,T010 R020(2062:2065),T010(#0)), сформированный запрос,

результирующая выборка (активные остатки на балансовых 2062-2065 в разрезе

балансовых счетов, валюты и срочности).

Проверки

Проверка - выполнение алгоритма, проверяющего соответствие данных каким либо

критериям. Этот алгоритм представляет собой TCL-скрипт, возвращающий значения “да”

или “нет”. Для проверок, как правило, описывается и дополнительный TCL-скрипт,

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

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

процедуры открытия/закрытия дня, вызывать перед формированием отчетов (например,

сверка параметров клиентов согласно справочников НБУ), при импорте данных,

использовать автономно и т.д.

Лимиты

Механизм Лимитов или Условий выполнения (Бизнес правил), применим к любым

объектам системы. Денежные потоки контролируются системой лимитов, которые могут

задаваться на разном уровне – от Проводок до Операций и Кредитных сделок. Лимиты

задаются на остатки и обороты в разрезе параметров объектов (Операций, Проводок и

т.д.) и реагируют на откаты и обратные операции. Лимиты можно задать также на группы

объектов. Лимитируются даже состояния объектов. Для Бизнес-правил задаются периоды

накопления и активности.

13

Согласования

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

системы (Договор, Счет, Платеж и пр.) на любом этапе своего существования. Обычно

согласования предшествуют переходу объекта из одного состояния в другое (открытие

счета, проведение проводки, отправка отчета в НБУ). Перечень согласований и

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

Набор согласований и перечень Исполнителей, имеющих право их выполнять,

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

положительным (разрешить) и отрицательным (запретить или отложить по каким либо

причинам). При согласовании возможно заполнение резолюции, мотивирующей

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

Напоминания

Механизм напоминаний – это удобный сервис, предоставляемый Пользователю,

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

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

т.д.

Базовый набор напоминаний поставляется с системой. Этот набор может быть

расширен новыми типами напоминаний непосредственно в банке без участия

Разработчика.

События

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

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

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

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

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

оповещение о нем.