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