Автоматизированные банковские системы. 2

Содержание

 

 

Введение

4

Глава 1 Автоматизированные банковские системы

 

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

 

6

1.2 Содержательное описание  задачи

9

1.3 Система показателей

13

Глава 2 Моделирование  оценки производительности банковских автоматизированных систем

 

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

 

 

18

2.2 Методы решения задач нелинейного  программирования

 

2.2.1 Постановка задачи НЛП

22

2.2.2 Методы штрафных функций

23

2.2.3 Методы прямого поиска

25

2.2.4 Методы случайного поиска

27

2.2.5 Методы линеаризации

28

2.3 Пути решения проблемы очередей  в системе

29

2.4 Построение имитационной  модели банковской автоматизированной системы

 

2.4.1 Предпосылки построения имитационной  модели

35

2.4.2 Показатели имитационной модели

35

2.4.3 Разработка требований к  концептуальной модели

36

2.4.4 Выбор языка моделирования

37

2.4.5 Построение концептуальной  модели

38

2.4.6 Построение имитационной модели

39

Глава 3 Применение модели и анализ полученных результатов

 

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

 

43

3.2 Решение задачи нахождения  оптимальных временных характеристик  подсистем

 

45

3.3 Анализ полученных результатов

47

Заключение

50

Приложения

52

Список используемой литературы

71


 

Введение

 

В 1975 году фирма Lemming Associates (США) установила систему, работающую в режиме реального  времени и предназначенную для  быстрого формирования ответов на запросы клиентов (в том числе и на поступающие по телефону). Сначала к системе подключили несколько небольших городов и тщательно ее отладили. Затем был подключен Нью-Йорк.

Предполагалось, что подключение  Нью-Йорка увеличит нагрузку на 30%. Управляющий отделом обработки данных полагал, что это приведет к увеличению времени ответа приблизительно на такую же величину. Текущее время ответа системы составляло около 2с, и поэтому причин для беспокойства как будто бы не было, тем более что центральный процессор мог выдержать нагрузку, которая превышала существующую в несколько раз.

Абонентские пункты (АП), установленные  в Нью-Йорке, включились в работу рано утром, и скоро стало ясно, что, вопреки ожиданию, система не справляется с возросшей нагрузкой. Время ответа увеличилось вначале до 4с, а затем и до 6с. Задержки ответов на отдельные заявки достигали 15с.

Была введена в действие аварийная  программа, которая в случае перегрузки удаляла из памяти некоторые заявки и рассылала операторам информационное сообщение о необходимости повторения заявки. Такой метод работы был принят исходя из предположения, что перегрузка не является постоянной, а носит случайный характер и обусловлена тем, что несколько операторов АП одновременно формируют заявки. В итоге перегрузка возросла еще больше. В конечном счете Нью-Йорк пришлось отключить от системы [14].

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

Для систем, работающих в режиме реального  времени, выполняется закон Паркинсона: «Если использование системы  полезно, то степень ее загрузки возрастает до полного исчерпания пропускной способности системы» [14]. Логично сделать вывод, что данных закон справедлив для систем различных типов (экономических, технических и т.д.) и различной структуры. Если система полезна, то на этапе ее проектирования(создания) необходимо предусмотреть возможность повышения ее производительности. Если такой возможности не предусматривалось (как в приведенном примере), то производительность системы необходимо повышать в процессе ее эксплуатации.

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

Учитывая, что ограничений на тип и структуру систем не накладывается, то не накладывается ограничений на характер процессов, протекающих внутри систем: они могут быть как непрерывными, так и стохастическими. Вследствие этого модель должна располагать необходимым аппаратом для оперирования соответствующими величинами.

Говоря об экономической целесообразности разработки данной модели можно выделить несколько немаловажных аспектов:

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

 

Глава 1 Автоматизированные банковские системы

 

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

 

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

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

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

Анализ показывает, что первоочередные возможности автоматизации банковской деятельности связаны с автоматизацией межбанковских расчетов, расчетов банка  со своими клиентами, а также с созданием автоматизированной банковской системы, обслуживающей запросы различных рыночных структур и физических лиц. Целью систем такого класса является реализация высокоэффективной информационной технологии банковского обслуживания юридических и физических лиц и получение на этой основе дохода и прибыли. Под высокоэффективной информационной технологией понимается предоставление пользователям в регламентном режиме и по запросам информационных продуктов, обладающих свойствами полноты, достоверности и надежности, актуальности и оперативности, простоты и удобства использования [18]. Критерием эффективности функционирования таких систем в целом, так и их отдельных составных частей (подсистем) или реализации заданного множества транзакций является отношение чистой прибыли к суммарным затратам за установленный период времени. При этом чистая прибыль представляет собой полученный доход за вычетом всех затрат, связанных с его получением - капитальных, эксплуатационных и т.п.

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

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

Рост числа решаемых в автоматизированных банковских системах задач, их сложности, повышение требований к своевременности, достоверности и полноте предоставляемой информации обуславливает необходимость существенного их совершенствования, которая должна учитывать не только особенности «человеческого» фактора, но и требования по обеспечению максимальной эффективности использования технического, программного и информационного обеспечения. Такое совершенствование представляет собой комплексную проблему, включающую в себя анализ и типизацию информационных требований пользователей, синтез типовой модели диалога для заданного множества пользователей, информационные запросы которых принадлежат к одной предметной области, синтез инфо\рмационного и прикладного модульного программного обеспечения, оптимального по заданному критерию [18].

На пути повышения эффективности  системы существует еще одна проблема, которая требует решения –  проблема очередей внутри системы. Она  возникает в процессе проектирования и эксплуатации систем. Недостаточное изучение проблемы оптимизации очередей данных внутри системы может привести к существенному уменьшению производительности системы в целом. Задача оптимизации состоит в том, чтобы распределить входные данные в соответствии с некоторым критерием оптимальности [7].

Одним из наиболее частых критериев  оптимальности очередей является минимизация  некоторой функции от средних  длин очередей. Данный критерий является основным для разработчиков и администраторов систем. Зная их (средние длины очередей), можно найти и другие характеристики, такие, как среднее время отклика системы, коэффициенты использования подсистем, их пропускную способность и т.д. Но существует еще один универсальный показатель - время обработки данных в подсистемах, который интегрирует такие показатели, как производительность и возникновение очередей в системе.

Целью данной работы является оценка производительности АС «Центр обработки  данных» (АС ЦОД) Сбербанка России при  заданных начальных условиях.

 

 

1.2 Содержательное описание задачи

 

При системном рассмотрении структуры любой банковской автоматизированной системы условно можно выделить следующие компоненты (см. рис. 1):

  • Внешняя среда: представляет собой филиалы банка и АС других банков с интегрированными в них филиалами. В общем случае, рассматриваемые банковские автоматизированные системы используют различные системы автоматизации и транспортные сетевые протоколы (под транспортным протоколом понимается совокупность правил, по которым передаются данные). Таким образом, банковские АС образуют гетерогенную информационную среду [8].
  • Механизм взаимодействия с внешней средой: данный функциональный блок - неотъемлемая составляющая каждой банковской АС, так как через него осуществляется взаимодействие с филиалами банка, а в общем случае - с АС других банков.
  • Согласующий функциональный блок: обеспечение взаимодействия АС различных банков.
  • Маршрутизатор: Выполняет распределение входящих и исходящих данных между прикладными программами и механизмом взаимодействия  с внешней средой. Также в его функции может входить ведение журнала банковских транзакций.
  • Прикладные программы: предназначены для отражения транзакции в ИБД и формирования ответных данных на поступивший от филиала запрос.
  • ИБД: хранение данных по вкладам населения.

Как было сказано выше, совокупность банковских АС представляет собой гетерогенную среду и формулирование выводов, справедливых для всех АС затруднительно. Поэтому оценку эффективности функционирования будет проводится на примере Автоматизированной Системы Центр Обработки Данных (АС ЦОД) Московского Банка Акционерного Коммерческого Сберегательного Банка Российской Федерации.

АС ЦОД представляет собой интегрированную  базу данных (ИБД) под управлением  СУБД UNIFY 2000, реализованную на серверах Sun Sparc 1000 фирмы Sun Microsystems с операционной системой SOLARIS. АС ЦОД соединена при помощи канала связи с АС филиал, что делает возможным их взаимодействие в режиме реального времени (online). Транспортным протоколом является протокол TCP/IP. Описание блоков функциональной схемы (см. рис. 2) АС ЦОД представлено в таблице 1.

                          

Системный монитор транзакций –  один из наиболее сложных и функциональных узлов любой банковской автоматизированной системы. В следствие большого числа  выполняемых функций и значительного  количества типов обрабатываемой информации большая часть времени обработки транзакции/запроса приходится именно на данный узел. Следовательно, возникает потребность получить статистические характеристики элементов системного монитора транзакций с целью оценки эффективности его функционирования. Функциональная схема системного монитора транзакций представлена на рис. 3. Описание блоков функциональной схемы «Системный монитор транзакций» представлено в таблице 2. Системный монитор транзакций осуществляет маршрутизацию трех типов данных: запросов, команд и операций.

  • Маршрутизация запросов: В следствие того, что количество типов запросов очень ограничено (исчисляется десятками), то для ускорения их обработки маршрутизация осуществляется по диапазону кода запроса. Поступающий в АС ЦОД запросы обрабатываются подсистемой Req, входящей в состав системного монитора транзакций, которая анализирует код запроса и на основании таблицы маршрутов запросов направляет его соответствующему прикладному монитору. Прикладной монитор путем обращения к ИБД формирует ответные данные на запрос, которые направляются в подсистему доставки.
  • Маршрутизация операций и команд: Число возможных операций и команд довольно велико, причем необходимо фиксировать завершение (или сбой) команд и операций. В следствие этих причин маршрутизация этого вида данных усложняется. Поступающая в АС ЦОД команда или операция принимается подсистемой доставки и поступает на обработку подсистемой Jrn, которая отражает их в журнале банковских транзакций и в статусном журнале, в котором фиксируется завершенность команд и операций. Далее поступившая команда(операция) направляется головной подсистеме Mon системного монитора транзакций, которая осуществляет выборку маршрута обработки из таблиц маршрутов команд (операций) и прикладных мониторов из таблицы соответствия, в которые должны обработать поступившую команду(операцию). Далее подсистема Mon направляет согласно маршруту поступившую команду(операцию) прикладным мониторам и анализирует код возврата. Первым в маршруте обработки всегда стоит прикладной монитор «Транзит» (логическая схема п/с «Транзит» представлена на рис. 4), который не допускает дублирования команд(операций) в ИБД. Так например, оператор в филиале Сбербанка может случайно дважды нажать клавишу «Ввод» и в АС ЦОД будет доставлен дубликат команды(операции), который не должен отражаться в ИБД ЦОД. В случае успешной обработки монитором «Транзит», команда(операция) поступает на обработку другими прикладными мониторами согласно маршруту. Подсистема Mon, получив результат(код) обработки команды(операции) маршрутом прикладных мониторов, направляет его подсистеме Ack, которая фиксирует в статусном журнале результат обработки команды(операции).

Функциональная схема  маршрутизации данных системным  монитором транзакций представлена на рис. 5.

 

Схема прохождения  транзакции:

 

Транзакция online-филиала, поступающая  по каналу связи, принимается сетевой  службой оперативного online, которая  отражает ее в журнале банковских транзакций. Системный монитор транзакций (маршрутизатор) считывает транзакцию из журнала и направляет ее (согласно типу) соответствующим прикладным мониторам, которые отражают ее в ИБД ЦОД.

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

Если транзакция содержит вкладную операцию («приход», «расход», «зачисление», «списание»), то она через прикладной монитор поступает в системный  монитор транзакций, который отражает ее в журнале отделения-«хозяина»  филиала. После журналирования сетевая служба доставки в ОСБ считывает транзакцию из журнала и доставляет ее в соответствующее ОСБ для актуализации ИБД отделения.

 

 

Схема прохождения  запроса

 

Если от online-филиала поступает  запрос по счету, то он (минуя процесс журналирования) направляется через системный монитор транзакций в соответствующий прикладной монитор, который путем обращения к ИБД ЦОД формирует ответные данные на запрос.

Сформированный «ответ» через  прикладной монитор и системный  монитор транзакций поступает на «вход» сетевой службы оперативного online, который передает его в филиал-«адресат». В случае образования очереди запросов «ответ» на них может формироваться и отправляться с некоторой задержкой.

 

Требуется найти такие временные  характеристики подсистем АС ЦОД (прикладных мониторов, сетевой службы, системного монитора транзакций и т.п.), которые повысят ее производительность до заданного значения.

 

1.3 Система показателей

 

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

  1. Типизация входных данных, т.е. выделение [k] типов входных данных.
  2. Целевое значение времени обработки очереди входных данных для каждого из k маршрутов.
  3. Наиболее вероятный (или средний) размер очереди каждого типа входных данных.
  4. Среднее время обработки подсистемами данных различных типов.
  5. Среднее время обработки очереди входных данных для каждого маршрута.

 

Введем условные обозначения:

 

k

- число типов (маршрутов) входных  данных.

n

- число  подсистем рассматриваемой системы.

tij

- среднее время обработки единицы  входных данных типа [j]   i-й  подсистемой, 1£j£k, 1£i£n.

Lj

- наиболее вероятный  или средний размер (текущее значение) очереди данных типа [j], 1£j£k.

Tj

- наиболее вероятное  или среднее время (текущее  значение) обработки очереди входных данных размером Lj j-м маршрутом обработки, 1£j£k.

Tj необх.

- целевое (необходимое)  значение времени обработки очереди  входных данных размером Lj j-м маршрутом обработки, 1£j£k.


 

Исходные  данные удобно представлять в следующем  виде:


 

 

 

 

 

 

 

где

 

T(n´k)

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

L  -

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

T1 -

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

T2 -

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


 

Решением задачи минимизации общего времени обработки системой очереди  входных данных является матрица Tмод(n´k), компоненты которой обеспечивают обработку очередей различных типов данных (компоненты вектора L) за целевое время (компоненты вектора T2). Структура матрицы Tмод(n´k) аналогична структуре матрицы T (n´k).

Нахождение матрицы Tмод(n´k) возможно воздействием неизвестного оператора на исходную матрицу T(n´k) или решением семейства из [k] задач, решения которых представляют собой соответствующие столбцы матрицы Tмод(n´k). В обоих случаях необходима формулировка правила заполнения матрицы T(n´k): если  i-я подсистема не осуществляет обработку j-го типа входной информации, то элемент tij считается равным нулю и в дальнейшем не оказывает влияния на получение матрицы Tмод(n´k).

 

Рекомендации к получению  исходных данных:

  1. Элементы матрицы T(n´k) – текущие параметры подсистем рассматриваемой системы (среднее время, которое затрачивает i-я подсистема на обработку j-го типа входных данных) должны быть получены путем усреднения имеющихся статистических данных по соответствующим подсистемам.
  2. Элементы вектора L – текущие средние (наиболее вероятные) размеры очередей входных данных различных типов, поэтому они могут быть получены следующими способами:
      • Усреднением имеющихся статистических данных.
      • Заданы из расчета частоты поступления входных данных: если входные данные типа [j] поступают в систему с частотой [x] ед./с, то j-я компонента вектора L считается равной [x], а соответствующая компонента вектора T2 равной 1 с.
  1. Элементы вектора T1 - наиболее вероятное или среднее время (текущее значение) обработки очереди входных данных размером Lj j-м маршрутом обработки могут быть получены как усреднением имеющихся статистических данных, так и рассчитаны по формуле:


 

 

 

  1. Компоненты вектора T2 - целевые (необходимые) значения времени обработки очереди входных данных размером Lj   j-м маршрутом обработки в общем случае задаются экспертно или заданы из расчета частоты поступления входных данных: если входные данные типа [j] поступают в систему с частотой [x] ед./c, то j-я компонента вектора T2 считается равной 1c, а соответствующая компонента вектора L считается равной [x].

 

Такая система показателей обеспечивает поиск необходимых временных  характеристик подсистем рассматриваемой  АБС с использованием аналитической  модели. Однако, аналитическая модель не учитывает стохастические характеристики системы и прочие факторы:

  1. Сложность структуры и стохастичность связей между элементами.
  2. Неоднозначность алгоритмов поведения при различных условиях.
  3. Большое число параметров и переменных.
  4. Неполноту и недетерминированность исходной информации.
  5. Разнообразие и вероятностный характер воздействий внешней среды.

Это приводит к необходимости сочетания  аналитических и имитационных методов  при исследования сложных систем.

Имитационное  моделирование позволяет достаточно просто учитывать такие факторы, как наличие стохастических и детерминированных процессов, нелинейность их характеристик, многочисленные случайные воздействия и другие явления [1]. Имитационное моделирование включает в себя ряд основных этапов, последовательность которых показана на рис. 6.

Система показателей имитационной модели системы в общем случае может быть представлена в виде множества  величин, описывающих процесс ее функционирования [2]:

  1. Совокупность входных воздействий на систему:
  2. Совокупность воздействий внешней среды:
  3. Совокупность внутренних параметров системы:
  4. Совокупность выходных характеристик:

Входные воздействия, воздействия внешней среды, внутренние параметры системы являются зависимыми (экзогенными) переменными:

Выходные характеристики являются зависимыми (эндогенными) переменными:

При синтезе структур сложных систем необходимо обеспечить в процессе моделирования  выбор не просто приемлемого, а оптимального варианта системы. Очевидно, что простым перебором такая задача не может быть решена. Учет динамических и стохастических аспектов функционирования сложных систем приводит к необходимости совместного использования оптимизационных и имитационных моделей. При этом возникает проблема рационального сочетания таких моделей для синтеза структуры сложных систем. Это приводит к специфическим итерационным процедурам поиска рациональных вариантов структуры системы путем направленного варьирования входных параметров на некотором множестве реализаций [17].

Задача синтеза структуры  сложной системы формализуется  следующим образом:

, где

F(x) - критерий  оптимальности (значение функционала  эффективности работы системы  при заданном наборе параметров X).

X=(x1, ... , xn) - вектор управляемых параметров.

gj(x), hs(x) - функциональные ограничения.

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

 

В большинстве случаев  возникает необходимость получить наилучшие значения для некоторых  характеристик объектов оптимизации, то есть требуется определить такие значения управляемых переменных XÎD, которые обеспечивают минимум или максимум по нескольким критериям оптимальности. В этом случае идет речь о многокритериальной оптимизации. Схема оптимизации сложной системы на имитационной модели приведена на рис. 7.

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