Виконання еквайєрами своїх функцій спричиняє за собою розрахунки з емітентами. Кожний банк-еквайєр здійснює перерахування коштів точкам обслуговування по платежах утримувачів карток банків-емітентів, що входять в дану платіжну систему. Тому відповідні засоби (а також, можливо, засоби, що відшкодовують видану готівку) повинні бути потім перераховані еквайєру цими емітентами. Оперативне проведення взаєморозрахунків між еквайєрами і емітентами забезпечується наявністю в платіжній системі розрахункового банку (одного або декількох), в якому банки – члени системи відкривають кореспондентські рахунки. Загальна схема взаємодії емітентів та екваєрів показана щодо обслуговування платіжних карток показана рис. 1.1. 

     Рисунок 1.1 – Взаємодія емітентів та екваєрів

     1.2 Методи моделювання банківських систем

 

     Моделювання – це заміщення одного об'єкту (оригіналу) іншим (моделлю), а також і фіксація і вивчення властивостей моделі. Заміщення  проводиться з метою спрощення, здешевлення, прискорення вивчення властивостей  
оригіналу [18].

     В загальному випадку об'єктом-оригіналом може бути природна або штучна, реальна або уявна система. Вона має множину параметрів S₀ і характеризується певними властивостями. Кількісною мірою властивостей системи служить множина характеристик Y₀, система проявляє свої властивості під впливом зовнішніх дій Х.

     Множина параметрів S₀ і їх значень відображає її внутрішній зміст – структуру і принципи функціонування. Характеристики системи S – це в основному її зовнішні ознаки, які важливі при взаємодії з іншими системами.

     Характеристики  системи знаходяться у  функціональній залежності від її параметрів. Кожна  характеристика системи y₀ Ì Y₀ визначається в основному обмеженим числом параметрів {S_0k} Ì S₀. Решта параметрів не впливає на значення даної характеристики системи S. При дослідженні цікаві, як правило, тільки деякі характеристики S: {y} Ì Y₀ при конкретних діях на систему {x_mn}ÌX.

     Модель  – це система зі своєю безліччю параметрів S_m і характеристик Y_m. Оригінал і модель схожі по одних параметрах і різні по інших. Заміщення одного об'єкту іншим правомірні, якщо цікавлячі дослідника характеристики оригінала і моделі визначаються однотипними підмножинами параметрів і зв'язані однаковою залежністю з цими параметрами: 

                            y_mn = f({S_mi}, {x_mn}, T_m);       (1.1) 

     де y_mn – к-а характеристика моделі, y_mn Ì Y_m;

         x_mn – зовнішня дія на модель, x_mn Ì X;

         T_m – модельний час.

     1.3 Технологія безготівкових розрахунків на основі пластикових карток

 

     Розглянувши методи моделювання складних систем перейдемо до розгляду основних компонент  системи, що є можливими кандидатами  у підсистеми створюваної інформаційної системи обліку платіжних карток. Для їх виділення розглянемо основні процеси, які відбуваються при проведенні безготівкових розрахунків пластиковими картками.

     Цикл операцій при обслуговуванні картки виглядає наступним чином. Послідовності операцій, виконуваних при розрахунках за товари і послуги за допомогою кредитної і дебетової карток, вельми близькі. Вся послідовність для карток показана на діаграмі послідовності нижче (рис. 1.7). 

     Рисунок 1.7 – Обслуговування платіжних карт 

     Розглянемо  докладніше основні стани діаграми.

1. Бажаючи зробити покупку (або отримати послугу), утримувач картки пред'являє її продавцю.
2. Продавець здійснює перевірку автентичності картки і, при необхідності, правомочність розпорядження нею покупцем. Потім продавець проводить або голосову авторизацію по телефону, або електронну за допомогою POS-терміналу.

     1.4 Побудова моделі системи 

     Найістотнішим моментом побудови моделі є розгляд початкової проблеми по різних аспектах, виявлення різних підсистем, міні-проблем, і т.д. До числа самих загальних підходів до побудови таких підсистем є виявлення зовнішніх і внутрішніх чинників впливу для даного об'єкту, аналіз існуючих джерел зовнішніх і внутрішніх інформаційних потоків, умови взаємодії об'єкту із зовнішнім середовищем, початковий стан об'єкту і його динаміка, керованість тощо [33].

     Розглядаючи існуючі моделі обліку платіжних  карт фізичних осіб і основні способи  взаєморозрахунків між учасниками платіжної системи, була побудована узагальнена інформаційна модель системи обліку платіжних карток банком що містить проблему (рис. 1.10). 

 

     Рисунок 1.10 – Модель системи що містить проблему  

     Зображені у моделі підсистеми вже детально були розглянуті. Але основною проблемою залишається доступ клієнтів до своїй карткових рахунків без відвідування банку. Це надає клієнтам утримувачам карток більш широкі можливості при користуванні карткою, насамперед можливість слідкувати та умова роботи – це безпека конфіденційних даних користувача.

     Зробимо висновок з розглянутих нами процесів користування пластиковими картками для  здійснення безготівкових платежів. Наочна область бізнесу платіжних карток у банківській сфері є досить складною та розгалуженою. Для його ефективної роботи потрібно багато учасників процесу – банки-емітенти та екваєри, процесингові  центри, точки обслуговування тощо. Щоб побудувати ефективну модель для імітації роботи такої системи недостатньо лише детального опису усіх дій, а потрібні математичні методи систем масового обслуговування, які дозволяють отримувати систематизовані алгоритми для моделювання та обробки отриманих результатів. При аналізі майбутньої системи були виділені головні підсистеми модельованої системи, а саме підсистеми авторизації, управління лімітами, та проведення розрахунків. Був зроблений висновок, що весь процес користування пластиковими картками с точки зору утримувача картки (клієнта банку) ускладнюється неможливістю або недосконалістю інтерфейсів послуг щодо управління клієнтами станом своїх карткових рахунків. Тому найбільш доцільною часткою усієї системи обліку платіжних карток, що підлягає автоматизації, вважатимемо систему надання клієнтам простого та зручного доступу до своїх коштів засобами новітніх технологій, а саме через Інтернет. Така система буде найбільш затребуваною та відповідатиме сучасним тенденціям розвитку банківського бізнесу. 
 

 

     

     

2 РЕАЛІЗАЦІЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ДЛЯ МОДЕЛЮВАННЯ СИСТЕМИ ОБЛІКУ ПЛАТИКОВИХ КАРТОК

 

     2.1 Побудова архітектури програмного забезпечення системи обліку 

     Для програмної реалізації моделі системи  масового обслуговування обліку пластикових  карток була вибрана архітектура  клієнт-сервер (Client Server Architecture, CSA). У такій архітектурі клієнти виконуватимуть роль випадкових заявок на обслуговування сервером.

     Архітектура CSA визначає два типи взаємодіючих в  мережі компонентів: сервери і клієнти. Кожний з них визначається комплексом взаємозв'язаних прикладних програм. Сервери надають ресурси, необхідні багатьом користувачам. В число цих ресурсів входять бази даних, файли, пам'ять. Клієнти використовують ці ресурси і надають зручні інтерфейси користувача.

     В сучасній архітектурі виділяють  чотири групи об'єктів:

• клієнти;
• сервери;
• дані;
• прикладні служби.

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

     Сервер  додатків призначений для виконання  прикладних процесів і вирішує наступні задачі:

• адміністративного управління;
• забезпечення безпеки даних;
• підтримка стійкості до збоїв;
• вирівнювання навантаження.

     Сервер  бази даних забезпечує зберігання, пошук і видачу даних прикладним програмам.

     Для реалізації архітектури клієнт-сервер використовуватимемо тришарову  модель побудови корпоративного додатку, що включає три основні шари: представлення (presentation), домен (наочна область, бізнес-логіка) (domain) і джерело даних (data source).

     Шар представлення охоплює задачі, що мають відношення до спілкування користувача з системою. Він буде представлений web-інтерфейсом. До головних функцій шару представлення відносяться відображення інформації і інтерпретація команд, що вводяться користувачем, з перетворенням їх у відповідні операції в контексті домена (бізнес-логіки) і джерела даних.

     Джерело даних – це підмножина функцій, що забезпечують взаємодію із сторонніми системами, які виконують завдання, ініційовані додатком. Код цієї категорії несе відповідальність за моніторинг транзакцій, управління іншими додатками, обмін повідомленнями і т.д.

     Логіка  домена (бізнес-логіка або логіка предметної області) описує основні функції додатку, призначені для досягнення поставленої перед ним мети. До таких функцій відносяться обчислення на основі даних, що вводяться і зберігаються, перевірка всіх елементів даних і обробка команд, що поступають від шару представлення, а також передача інформації шару джерела даних.

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

     Визначившись  з основними поняттями моделі і архітектурними елементами системи, розглянемо методи, якими можливий розв’язок проблем, поставлених у моделі, що містить проблему, з оглядом на проблеми доступу клієнтів до своїх рахунків (рис. 2.1).

     Основним  методом розв’язку поставлених  проблем є надання користувачам можливості перегляду та управління своїми рахунками та картками. Для  цього повинен бути простий та зручний інтерфейс для перегляду даних та для виконання дозволених операцій.  

 

     Рисунок 2.1 – Модель системи що містить розв’язок проблеми  

     Основним  методом розв’язку поставлених  проблем є надання користувачам можливості перегляду та управління своїми рахунками та картками. Для цього повинен бути простий та зручний інтерфейс для перегляду даних та для виконання дозволених операцій.

     Модель системи, що містить розв’язок проблеми описує ті продукти і технології, а також методи, за допомогою яких планується реалізація системи  по описаній вище архітектурі зображені на рис. 2.2.