7.6. Архітектура системи управління банківською мережею
Система управління банківською мережею, що розглядається нами як приклад, є гібридною системою: це, по-перше, система з інтерактивним інтерфейсом (інтерактивні впливи здійснюються за допомогою касових терміналів та АТМ), а по-друге, це система управління транзакціями, оскільки вона забезпечує виконання проведення, які і є транзакціями.
Архітектура системи управління банківською мережею показана на рис. 75. Система має три основні підсистеми: підсистему обслуговування АТМ, підсистему «консорціум» та підсистему «банк». Система має топологію зірки, в центрі якої — підсистема «консорціум», а на променях підсистеми «АТМ» та «банк» (очевидно, що до складу системи входить одна підсистема «консорціум» та по кілька підсистем «АТМ» і «банк»).
Постійні сховища даних (рахунки клієнтів та банківська звітна документація) є у підсистем «банк», які працюють на комп’ютерах банків. Оскільки важливо зберігати цілісність даних та забезпечити паралельне обслуговування кількох проведень (транзакцій), сховища даних реалізовані на основі баз даних банків (доступ до даних здійснюється через СУБД, яка, зокрема, забезпечує синхронізацію доступу до даних.
Рис. 75. Архітектура системи управління банківською мережею
Асинхронна паралельність виникає у зв’язку з необхідністю паралельного обслуговування кількох незалежно працюючих АТМ та касових терміналів. Кожний термінал може одночасно обслуговувати лише одне проведення (транзакцію), але кожне проведення пов’язане також із центральним комп’ютером консорціуму та комп’ютером одного з банків, які мають одночасно обслуговувати кілька проведень. Як видно з рис. 75 кожне проведення розподілене за трьома пристроями; програмне забезпечення, що керує виконанням проведення, також складається з трьох частин; кожна із цих частин може бути реалізована у вигляді окремого класу.
7.7. Розробка об’єктів
Розробивши архітектуру системи, переходимо до розробки об’єктів (класів), які складають систему. Частина об’єктів була виявлена на етапі аналізу системи, ці об’єкти можуть розглядатися як основа системи. На розглядуваному етапі розробки системи необхідно вибрати спосіб їх реалізації, намагаючись мінімізувати кількість використовуваних ресурсів (час їх виконання, пам’яті, що використовується, і т. ін.). При реалізації об’єктів класи, атрибути та залежності мають бути реалізовані у вигляді відповідних структур даних, операції — у вигляді функцій. При цьому може виникнути необхідність введення нових класів (об’єктів) для проміжних даних.
Розробка об’єктів припускає виконання таких кроків:
Розглядаючи разом три моделі, дістаємо операції над класами.
Розробляємо алгоритми, які реалізують здобуті операції.
Оптимізуємо шляхи доступу до даних.
Реалізуємо управління взаємодіями із зовнішніми об’єктами.
Уточнюємо структуру класів, щоб підвищити ступінь успадкування.
Розроблюємо залежності.
Визначаємо подання об’єктів.
7.7.1. Спільний розгляд трьох моделей
У результаті аналізу ми одержуємо три моделі: об’єктну, динамічну та функціональну. При цьому об’єктна модель складає базу, навколо якої здійснюється подальша розробка. При побудові об’єктної моделі в ній не завжди зазначаються операції над об’єктами, оскільки з погляду об’єктної моделі об’єкти — це насамперед структури даних. Тому розробка інформаційної системи починається з порівняння дій та активностей динамічної моделі, процесів функціональної моделі, операцій і внесення цих операцій в об’єктну модель. Із цього починається процес розробки програми. Він реалізує поведінку, яка описується моделями, що побудовані в результаті аналізу вимог до системи.
Поведінка об’єкта задається його діаграмою станів; кожному переходу на цій діаграмі відповідає застосування до об’єкта однієї з його операцій; можна кожній події, що її дістав об’єкт, поставити у відповідність операцію над цим об’єктом, а кожній події, яку надіслав об’єкт, — операцію над об’єктом, якому подію було надіслано. Активності, які запускаються переходом на діаграмі станів, може відповідати ще одна (укладена) діаграма станів.