Сейчас уже существуют инструментальные средства для создания информационных систем, построенных по компонентным технологиям такого типа. Примерами их в России могут служить система Miracle фирмы И.В.А. и “Элит – технология” фирмы “Открытые системы”. В первой из них диспетчером компонент является отдельный процесс, функционирующий на выделенном управляющем сервере. Вторая технология отличается тем, что в ней могут одновременно существовать несколько диспетчеров компонент.
Архитектура АБС нового поколения
На нынешнем этапе развития отечественной банковской системы определились основные задачи для систем автоматизации банков. К ним относятся, в частности, проведение финансового анализа, прогнозирование финансового положения банка, сбор и подготовка комплексных данных для принятия управляющих решений. В модели реализованы принципиально новые приемы концептуального построения АБС, которые предполагают отказаться от чисто “бухгалтерского” подхода и ориентировать систему на обработку документов, что, в свою очередь, не может не отразиться на организации интерфейса и на основных алгоритмах обработки. В ходе разработки новой автоматизированной банковской системы была поставлена и успешно решена задача “обособления” технологического ядра системы, в котором на этапе анализа реализуются определенные обобщенные абстрактные механизмы “прикладной функциональности”, что позволило оптимизировать работу системы.
В основе архитектуры новой модификации АБС лежит схема Клиент – Сервер (клиентская часть + сервер данных и хранимых процедур). Но в отличие от типовой в ней есть выделенный сервер приложений. (Рис. 1. Архитектура построения системы. Приложение № 1).
Рассмотрим элементы этой архитектуры.
Клиент
Программные модули клиентской части можно разделить на две группы:
Функциональные модули, обеспечивающие взаимодействие пользователя с системой, графический интерфейс, ввод запросов и данных, предоставление результатов по выполнению запросов;
Модули оболочки для связи с сервером данных.
Инрерфейс пользователя включает также окна с системными сообщениями о таких происходящих в АБС событиях, как поступление документа, возникновение “красного” сальдо на счете и др.
Сервер данных
· это SQL – сервер, который хранит все таблицы данных и процедуры системы. Все функции клиентской части реализуются только на основе вызова хранимых процедур (что очень важно для системы защиты).
В процессе функционирования системы хранимые процедуры подготавливают для клиентской части результаты своей работы. Эти процедуры могут вызывать другие хранимые процедуры, а так же обращаться к серверу приложений, активизируя его модули на выполнение.
исполняет специальные алгоритмы, которые неэффективно реализуются средствами сервера данных. Этот сервер может функционировать на том же компьютере, что и сервер данных, но его можно организовать и на другом компьютере. Модули сервера приложений обеспечивают функционирование системы безопасности и управления доступом, расчет процентов, формирование и обработку извещений. Все эти модули вызываются исключительно по запросам от хранимых процедур. Последние могут обращаться к серверу данных как напрямую, так и через внутренние хранимые процедуры.
Во “внутренней организации” системы можно выделить три основные составляющие: систему защиты информации и управления доступом, систему учета и систему обеспечения документооборота (Рис.2. Технологическая структура. Приложение №1).
В рамках перечисленных подсистем реализуются определенные абстрактные механизмы, которые вполне самодостаточны в том смысле, что их функционирование не зависит от работы системы.
является обособленной системой (ей все равно, какую прикладную систему защищать). На этом этапе разработки все объекты регистрируются в системе безопасности, после чего с учетом конкретных требований по защите от несанкционированного доступа “прописываются” процедуры прикладных систем (в основном они представляют собой вызов из прикладных процедур соответствующих им процедур системы безопасности). В результате создается некая матрица системы защиты, устанавливающая взаимосвязь между базовыми объектами и базовыми операциями. Базовый объект - это абстрактное понятие, опосредованно отражающее суть происходящего в системе. Примерами базовых объектов являются “документ” и “картотека”. Под базовой операцией понимается операция проблемной области, реализованная как целостный (неделимый) набор определенных технологических действий и описанная в терминах предметной области. Примерами базовых операций могут служить “проверка”, “проводка”, “откат”.
При эксплуатации системы технологу (или офицеру безопасности) предоставляется возможность по своему усмотрению группировать базовые операции и базовые объекты (Рис. 3. Группировка базовых объектов и операций. Приложение №1), формировать оргштатную структуру и расставлять отметки, регламентирующие доступ представителей оргштатной структуры к обобщенным объектам и операциям.
Все настройки хранятся и подвергаются корректуре в таблицах сервера данных. При работе системы информация из этих таблиц (в матрице доступа) переносится на сервер защиты (т.е. на сервер приложений). Таким образом в процессе функционирования осуществляется контроль за доступом.
обеспечивает фактический и позиционный учет банковских операций. В ее основе - абстрактная модель бухгалтерского учета (она разработана А. Екушовым, ведущим специалистом аналитического отдела компании R-StyleSoftwareLab.), оперирующая такими понятиями, как “конто”, “показатель” и “проводка”. Конто - это элементарная единица аналитического учетного регистра для однородных банковских операций. На внешнем (прикладном) уровне конто соответствуют лицевые счета (балансовые, внебалансовые, депо) и кассовые символы. Показатель относится к области синтетического учета, он предназначен для группировки аналитических объектов при формировании отчетности и проведения анализа. На внешнем уровне показателям соответствуют счета I-II порядков, разделы плана счетов ЦБ, символы отчетности различных форм. В терминах бухгалтерской модели конто и показатели являются абстрактными счетами учетной системы. Структура показателей и конто строится на основе иерархии неограниченного уровня вложенности. И наконец, проводки формируют состояния конто - хранящиеся в системе обороты по дебету и кредиту, а также остаток. Состояния показателей рассчитываются на основе состояний иерархически подчиненных конто при помощи правил простой интеграции. При выполнении проводок фиксируется время ввода, планирования, подтверждения планирования и фактического учета.
Система учета позволяет вводить ограничения на выполнение операций над конто. На прикладном уровне такие ограничения соответствуют овердрафту, лимитам на обороты и величину остатка (как “сверху”, так и “снизу”), различным видам блокировки (вплоть до ареста) и бронированию средств на счете. Когда ограничения “включены”, учетная система проверяет, допустимо ли выполнить операцию и - в зависимости от результатов проверки - либо выполняет ее, либо предоставляет соответствующие коды возврата.
Важной особенностью учетной системы стал отказ от использования “внутреннего” понятия “операционный день”. Фактическое и планируемое состояния конто формируются в соответствии с “линейками времени”, которых в системе три: дневная, месячная и годовая. При любом текущем изменении конто анализируется дата проводки (фактическая или плановая), а также изменяются дневное, месячное и годовое состояния, соответствующие этой дате. Если при этом в системе имеются дневные состояния данного конто с более поздними датами, то эти состояния автоматически пересчитываются.
Для реализации алгоритмов учетной системы используются процедуры и таблицы сервера данных. В состав модулей системы учета входят модули клиентской части, которые обеспечивают диалоговый режим при создании счетов и работы с ними. В подавляющем большинстве случаев это - модули технолога системы, которые позволяют поддерживать структуру показателей и конто, а также организуют доступ для аудита ко всем счетам и проводкам системы учета независимо от их прикладного применения.
Поскольку учетная система в структуре АБС достаточно обособлена, взаимодействие с ней осуществляется через интерфейс прикладного программирования API (ApplicationProgrammingInterfase), который состоит из двух частей: интерфейса операционного сервиса и интерфейса информационного сервиса. Соответственным образом разделяются интерфейсные модули клиентской части.
самая важная составляющая с точки зрения выполнения прикладных функций. Основными объектами системы являются документ и картотека. Картотеки характеризуются следующими свойствами:
их количество в системе конечно;
пользователи системы не могут создавать и уничтожать их;
разрешенные перемещения документа из одной картотеки в другую заранее предусматриваются технологом системы;
обращение к учетной системе для инициирования проводок происходит при перемещении документа из одной картотеки в другую.