 |
Архитектура системы управления банковской сетью
|
|
|
|
Система управления банковской сетью, рассматриваемая нами в качестве примера, является гибридной системой: это, во-первых, система с интерактивным интерфейсом (интерактивные воздействия осуществляются с помощью кассовых терминалов и ATM), а, во-вторых, это система управления транзакциями, так как она обеспечивает выполнение проводок, которые и есть транзакции.
Архитектура системы управления банковской сетью показана на рис. 3.7. Система имеет три основных подсистемы: подсистему обслуживания ATM, подсистему консорциум и подсистему банк. Система имеет топологию звезды, в центре которой - подсистема консорциум, а на лучах - подсистемы ATM и банк (ясно, что в состав системы входит одна подсистема консорциум и по несколько подсистем ATM и банк).
Рис. 3.7. Архитектура системы управления банковской сетью
Постоянные хранилища данных (счета клиентов и банковская отчетная документация) имеются у подсистем банк, которые работают на компьютерах банков. Поскольку важно сохранять целостность данных и обеспечивать параллельное обслуживание нескольких проводок (транзакций), хранилища данных реализованы на основе БД банков (доступ к данным осуществляется через СУБД, которая, в частности, обеспечивает синхронизацию доступа к данным).
Асинхронная параллельность возникает в связи с необходимостью параллельного обслуживания нескольких независимо работающих ATM и кассовых терминалов. Каждый терминал может одновременно обслуживать только одну проводку (транзакцию), но каждая проводка связана также с центральным компьютером консорциума и компьютером одного из банков, которые должны одновременно обслуживать несколько проводок. Как видно из рисунка 3.7 каждая проводка распределена по трем устройствам, управляющее ее выполнением программное обеспечение состоит из трех частей; каждая из этих частей может быть реализована в виде отдельного класса.
|
|
|
Разработка объектов
Разработав архитектуру системы, переходим к разработке объектов (классов), составляющих систему. Часть объектов была выявлена на этапе анализа системы, эти объекты могут рассматриваться как основа системы. На рассматриваемом этапе разработки системы необходимо выбрать способ их реализации, стремясь минимизировать количество потребляемых ими ресурсов (времени их выполнения, используемой памяти и др.). При реализации объектов классы, атрибуты и зависимости должны быть реализованы в виде соответствующих структур данных, операции - в виде функций. При этом может возникнуть необходимость введения новых классов (объектов) для промежуточных данных.
Разработка объектов предполагает выполнение следующих шагов:
· Рассматривая совместно три модели, получаем операции над классами.
· Разрабатываем алгоритмы, реализующие полученные операции.
· Оптимизируем пути доступа к данным.
· Реализуем управление взаимодействиями с внешними объектами.
· Уточняем структуру классов, чтобы повысить степень наследования.
· Разрабатываем зависимости.
· Определяем представления объектов.
3.3.1. Совместное рассмотрение трех моделей. В результате анализа мы получаем три модели: объектную, динамическую и функциональную. При этом объектная модель составляет базу, вокруг которой осуществляется дальнейшая разработка. При построении объектной модели в ней не всегда указываются операции над объектами, так как с точки зрения объектной модели объекты это, прежде всего, структуры данных. Поэтому разработка системы начинается с сопоставления действиям и активностям динамической модели и процессам функциональной модели операций и внесения этих операций в объектную модель. С этого начинается процесс разработки программы, реализующей поведение, которое описывается моделями, построенными в результате анализа требований к системе.
|
|
|
Поведение объекта задается его диаграммой состояния; каждому переходу на этой диаграмме соответствует применение к объекту одной из его операций; можно каждому событию, полученному объектом, сопоставить операцию над этим объектом, а каждому событию, посланному объектом, сопоставить операцию над объектом, которому событие было послано. Активности, запускаемой переходом на диаграмме состояний, может соответствовать еще одна (вложенная) диаграмма состояний.
Результатом этого этапа проектирования является уточненная объектная модель, содержащая все классы проектируемой ПС, в которых специфицированы все операции над их объектами.
3.3.2. Разработка алгоритмов, реализующих полученные операции. Каждой операции, определенной в уточненной объектной модели, должен быть сопоставлен алгоритм, реализующий эту операцию. При выборе алгоритма можно руководствоваться следующими соображениями:
· вычислительная сложность алгоритма: для алгоритмов, применяемых к достаточно большим массивам данных, важно, чтобы оценка их вычислительной сложности была разумной; например, вряд ли имеет смысл избегать косвенности в ссылках, особенно когда введение косвенности существенно упрощает понимание программы; в то же время замена пузырьковой сортировки с оценкой сложности n2 на алгоритм сортировки с оценкой n´log n всегда резко ускоряет вычисления;
· понятность алгоритма и легкость его реализации: для достижения этого можно даже пойти на небольшое снижение эффективности; например, введение рекурсии всегда снижает скорость выполнения программы, но упрощает ее понимание (рис. 3.8);
· гибкость: большая часть программ рано или поздно должна быть модифицирована; как правило, высокоэффективный алгоритм труден для понимания и модификации; одним из выходов является разработка двух алгоритмов выполнения операции: простого, но не очень эффективного, и эффективного, но сложного; при модификации в этом случае изменяется более простой алгоритм, что обеспечивает работоспособность системы на период разработки более эффективного модифицированного алгоритма.
|
|
|
Рис. 3.8. Сравнение рекурсивного и нерекурсивного алгоритмов вычисления n!
Выбор алгоритмов связан с выбором структур данных, обрабатываемых этими алгоритмами. Удачный выбор структур данных позволяет существенно оптимизировать алгоритм.
Еще одним способом упрощения и оптимизации алгоритмов является введение внутренних (вспомогательных) классов. Эти классы не имеют соответствий в реальном мире; они связаны с реализацией, но могут существенно упростить ее (примеры: класс стек, класс двусвязный список и т.п.).
Наконец, во многих случаях бывает полезным внести некоторые изменения в структуру объектной модели. Эти изменения сводятся к введению дополнительных классов и к перераспределению операций между классами.
При распределении операций по классам руководствуются следующими соображениями:
· если операция выполняется только над одним объектом, то она определяется в классе, экземпляром которого является этот объект;
· если аргументами операции являются объекты разных классов, то ее следует поместить в класс, к которому принадлежит результат операции;
· если аргументами операции являются объекты разных классов, причем изменяется значение только одного объекта, а значения других объектов только читаются, то ее следует поместить в класс, к которому принадлежит изменяемый объект;
· если классы вместе с их зависимостями образуют звезду с центром в одном из классов, то операцию, аргументами которой являются объекты этих классов, следует поместить в центральный класс.
3.3.3. Оптимизация разработки. Объектная модель, построенная на этапе анализа требований к ПС, содержит информацию о логической структуре системы; на этапе разработки объектная модель уточняется и пополняется: в нее добавляются детали, связанные с необходимостью обеспечить более эффективный доступ к информационным структурам во время работы системы. Цель оптимизации разработки - заменить семантически корректную, но недостаточно эффективную модель, построенную на этапе анализа, более эффективной. В процессе оптимизации разработки выполняются следующие преобразования:
|
|
|
· добавляются избыточные зависимости, чтобы минимизировать потери, связанные с доступом к данным, и максимизировать удобство работы с ними;
· изменяется порядок вычислений для достижения большей эффективности;
· сохраняются производные атрибуты, чтобы устранить необходимость перевычисления сложных выражений.
На этапе анализа требований к ПС избыточные зависимости нежелательны, так как они не вносят в модель новой информации. Однако на этапе разработки мы должны приспособить структуру объектной модели к требованиям эффективной реализации системы. Пример использования избыточной (производной) зависимости для повышения эффективности поиска представлен на рис. 3.9: на рис. 3.9(а) показаны зависимости из исходной объектной модели; добавление производной (и, следовательно, избыточной) зависимости (рис. 3.9(б)) позволяет резко ускорить поиск сотрудников, говорящих по-китайски.
Рис. 3.9. Ускорение поиска с помощью производной зависимости
Использование производных атрибутов для исключения повторных вычислений показано на рис. 3.10: запоминание координат однажды найденных атрибутов и операций в специальных списках позволяет избежать повторного поиска.
Рис. 3.10. Использование производных атрибутов для исключения повторных вычислений
Рис. 3.11. Использование производной зависимости
На рис. 3.11 показано, как введение производной зависимости позволяет не перевычислять координаты перекрывающихся элементов окон в оконной системе для графического дисплея.
Производные атрибуты должны изменять свои значения, когда меняются их базовые значения. Для обеспечения этого пользуются одним из трех методов:
· явное перевычисление: каждый производный атрибут определяется с помощью одного или нескольких базовых объектов; когда значения базовых объектов меняются, требуется изменить значения всех производных атрибутов, связанных с ними;
· периодическое перевычисление всех производных атрибутов (в момент изменения базового значения производные атрибуты перевычисляются);
· использование активных значений: активным называется значение, с которым связано некоторое множество зависимых значений; все зависимые значения группируются вокруг определяющих их активных значений и перевычисляются синхронно с ними.
3.3.4. Реализация управления. Реализация управления связана с реализацией динамической модели объектов системы. Известны три подхода к реализации динамической модели:
|
|
|
· процедурное управление: состоянию соответствует определенный фрагмент программы;
· управление через события: явная реализация конечного автомата;
· использование параллельных независимых задач.
Процедурное управление является традиционным способом реализации динамической модели; в этом случае состояние объекта определяется текущим оператором программы, а каждому переходу соответствует оператор ввода: следующее состояние определяется по текущему состоянию и вводимому имени события. Пример практического использования процедурного управления представлен на рис. 3.12.
Рис. 3.12. Псевдокод, соответствующий динамической модели ATM
3.3.5. Уточнение наследования классов. Уточняя определения классов и операций, стараемся увеличить степень наследуемости: чем больше классов находятся в отношении наследования, тем меньше функций, реализующих операции этих классов необходимо будет запрограммировать. Для увеличения степени наследуемости следует:
· Перестроить классы и операции.
· Выявить одинаковые (или взаимно однозначно соответствующие) операции и атрибуты классов и определить для этих классов абстрактный суперкласс.
· Использовать делегирование операций, когда наследование семантически некорректно.
Иногда одна и та же операция бывает определена в нескольких классах, что позволяет ввести общий суперкласс для этих классов, в котором и реализуется эта операция. Но чаще операции в разных классах бывают похожими, но не одинаковыми. В таких случаях нужно попытаться внести несущественные изменения в определения этих операций, чтобы они стали одинаковыми, т.е. имели одинаковый интерфейс и семантику. При этом можно использовать следующие приемы:
· Если операции имеют одинаковую семантику, но разное число формальных параметров, можно добавить отсутствующие параметры, но игнорировать их при выполнении операции; например, операция отрисовки изображения на монохромный монитор не требует параметра цвет, но его можно добавить и не принимать во внимание при выполнении операции.
· Некоторые операции имеют меньше параметров потому, что они являются частными случаями более общих операций; такие операции можно не реализовывать, сведя их к более общим операциям с соответствующими значениями параметров; например, добавление элемента в конец списка есть частный случай вставки элемента в список.
· Одинаковые по смыслу атрибуты или операции разных классов могут иметь разные имена; такие атрибуты (операции) можно переименовать и перенести в класс, являющийся общим предком рассматриваемых классов.
· Операция может быть определена не во всех классах некоторой группы классов; можно тем не менее вынести ее в их общий суперкласс, переопределив ее в подклассах как пустую там, где она не нужна.
Использование делегирования операций можно пояснить на следующем примере (рис. 3.13). Класс стек близок классу список, причем операциям стека push и pop соответствуют очевидные частные случаи операций списка add и remove. Если реализовать класс стек как подкласс класса список, то придется применять вместо операций push и pop более общие операции add и remove, следя за их параметрами, чтобы избежать записи или чтения из середины стека; это неудобно и чревато ошибками. Гораздо лучше объявить класс список телом класса стек (делегирование), обращаясь к операциям списка через операции стека. При этом, не меняя класса список, мы заменяем его интерфейс интерфейсом класса стек.
Рис. 3.13. Реализация стека с использованием наследования(а) и делегирования(б)
3.3.6. Разработка зависимостей. Зависимости - это "клей" объектной модели: именно они позволяют рассматривать модель как нечто целое, а не просто как множество классов.
Односторонние зависимости можно реализовать с помощью ссылок (указателей) (см. рис. 3.14). При этом, если кратность зависимости равна единице, ей соответствует один указатель, если кратность больше единицы, то множество указателей.
Рис. 3.14. Реализация односторонней зависимости
На рис. 3.15 показан способ реализации двусторонней зависимости с помощью указателей.
Рис. 3.15. Реализация двусторонней зависимости
На рис. 3.16 показан способ реализации зависимости с помощью таблицы (как в реляционных БД).
Рис. 3.16. Реализация зависимости с помощью таблицы
При реализации зависимостей с помощью указателей атрибуты зависимостей (связей) переносятся в один из классов, участвующих в зависимости.
|
|
|
