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

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

Архитектура системы управления банковской сетью показана на рисунке 3.6. Система имеет три основных подсистемы: подсистему обслуживания ATM, подсистему консорциум и подсистему банк. Система имеет топологию звезды, в центре которой – подсистема консорциум, а на лучах – подсистемы ATM и банк (ясно, что в состав системы входит одна подсистема консорциум и по несколько подсистем ATM и банк).

Рис. 3.6. Архитектура системы управления банковской сетью

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

Асинхронная параллельность возникает в связи с необходимостью параллельного обслуживания нескольких независимо работающих ATM и кассовых терминалов. Каждый терминал может одновременно обслуживать только одну проводку (транзакцию), но каждая проводка связана также с центральным компьютером консорциума и компьютером одного из банков, которые должны одновременно обслуживать несколько проводок. Как видно из рисунка 3.6, каждая проводка распределена по трём устройствам, управляющее её выполнением программное обеспечение состоит из трёх частей; каждая из этих частей может быть реализована в виде отдельного класса.

Разработка объектов

Разработав архитектуру системы, переходим к разработке объектов (классов), составляющих систему. Часть объектов была выявлена на этапе анализа системы, эти объекты могут рассматриваться как основа системы. На рассматриваемом этапе разработки системы необходимо выбрать способ их реализации, стремясь минимизировать количество потребляемых ими ресурсов (времени их выполнения, используемой памяти и др.). При реализации объектов классы, атрибуты и зависимости должны быть реализованы в виде соответствующих структур данных, операции – в виде функций. При этом может возникнуть необходимость введения новых классов (объектов) для промежуточных данных.

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

- Рассматривая совместно три модели, получаем операции над классами.

- Разрабатываем алгоритмы, реализующие полученные операции.

- Оптимизируем пути доступа к данным.

- Реализуем управление взаимодействиями с внешними объектами.

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

- Разрабатываем зависимости.

- Определяем представления объектов.

3.3.1. Совместное рассмотрение трёх моделей

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

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

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