Основною  платформою для роботи системи вибрана  платформа Microsoft Framework 2.0. Як сервер баз даних використовується Microsoft SQL Server 2005.

     Платформа .NET Framework представляє нову комп'ютерну платформу, спрощуючу розробку додатків в розподіленому середовищі Інтернету.

     Таким чином, можна зробити висновок, що новітня платформа .NET Framework надає готові механізми та методи для швидкої та зручної розробки додатків. Бібліотека класів містить усі необхідні типи даних для побудови клієнт-серверних додатків, а технологія ADO .NET дозволяє розробляти швидкий та ефективний доступ до джерела даних у окремому прошарку. Загальномовне середовище виконання здійснює автоматичне управління пам’яттю, що полегшує розробку в цілому та дозволяє зосередити увагу на більш високорівневих алгоритмах та архітектурі і не звертати увагу на низькорівневу роботу додатку.

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

 

     Процес проектування даних можна умовно розділити на два етапи: логічне моделювання і фізичне проектування. Результатом першого з них є так звана логічна (або концептуальна) модель даних, виражена звичайно діаграмою «сутність-зв'язок або ER (Entity-Relationship) діаграмою, яка представлена в одній із стандартних нотацій, прийнятих для відображення подібних діаграм. Результатом другого етапу є готова база даних або SQL-скрипт для її створення.

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

     З логічної точки зору сутність є сукупністю однотипних об'єктів або фактів, називаних екземплярами цієї сутності. Фізичним аналогом екземпляра звичайно є запис в таблиці бази даних. Як і записи в таблиці реляційної СУБД, екземпляри сутності повинні бути унікальними, тобто повний набір значень їх атрибутів не повинен дублюватися [52].

     На  етапі логічного проектування для  кожного атрибута звичайно визначається зразковий тип даних (рядковий, числовий, BLOB та ін.). Конкретизація відбувається на етапі фізичного проектування, оскільки різні СУБД підтримують різні типи даних і обмеження на їх довжину або точність.

     Розглянемо  необхідні об'єкти для системи  обліку пластикових карт. Їх можна розбити на три групи за змістом реальних об'єктів наочної області: об'єкти рахунків, об'єкти карт, об'єкти заявок клієнтів. Зв'язуючою ланкою між ними є сам клієнт. Визначимо необхідні об'єкти і їх атрибути.

     Для представлення клієнта, а також  інформації про клієнта, як про користувача системи, достатньо таблиці Clients. В ній зберігаються основні дані по клієнту, а також його унікальний логін і пароль. У клієнта може бути один або декілька карткових рахунків, відображених в таблиці Accounts. Для зберігання історії залишків клієнта по рахунку служить таблиця AccountRests. На кожному рахунку, у свою чергу, може бути одна або декілька карт. Інформація про карти зберігається в таблиці Cards. По кожній карті можуть відбуватися ті або інші події (карта може бути заблокована, пере випущена і т.д.), що також повинне бути відображене для показу користувачу. Ця інформація зберігається в таблиці CardEvents. Для ідентифікації подій служить довідник подій CardEventKinds. Для забезпечення можливості користувача якось управляти своїми рахунками і картками, передбачені таблиці ClientRequests для зберігання запитаних клієнтом транзакцій і таблиця RequestReplys для можливості надати відповідь. Транзакції, які користувач може виконати on-line, строго обмежені довідником RequestKinds. Об'єкти, над якими ці транзакції можуть відбуватися обмежені довідником RequestTargets.

     При логічному проектуванні була побудована наступна концептуальна модель бази даних, представлена на рис. 2.6. 

     Рисунок 2.6 – Концептуальна модель БД 

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

     В процесі фізичного проектування слід визначити найменування і типи даних для всіх полів. Якщо необхідно, на цьому ж етапі описуються представлення (Views), якщо такі створюватимуться і може бути створений код збережених процедур [51].

     При проектуванні полів таблиці використовувалися  призначені для користувача типи даних, представлені в таблиці 2.1. Користування такими типами даних полегшують розробку бази та дозволяють обмежити використання вбудованих типів для уникнення непередбаченого їх використання. 

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

 

     Для побудови БД використовувалася СУБД Microsoft SQL Server 2005. В ній були створені всі необхідні таблиці, зв'язки, бережені процедури і ін. об'єкти. Створення  всіх об'єктів виконувалося написанням SQL запитів. Фізичне представлення БД представлено на рис. 2.6.

     Усі таблиці спроектовані з використанням  реляційного підходу до проектування  баз даних та дотримуванням стандарту T-SQL (див. додаток А).

     Структура таблиць, створених на підставі описаних вище призначених для користувача типів, виглядає таким чином (табл. 2.2 – 2.7).  

 

     Рисунок 2.6 – Фізичне представлення БД 

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

     2.3 Проектування веб-додатку системи обліку пластикових карток

 

     Проектування  бізнес-логіки. Виконання всієї бізнес-логіки системи здійснюється на веб-сервері під управлінням ASP .NET 2.0. Тому самим виправданим типовим рішенням для організації логіки домена є типове рішення модуль таблиці.

     Об'єкт DataSet з типом є похідним класом від DataSet. Він успадковує всі методи, події і властивості об'єкту DataSet. Окрім цього, об'єкт DataSet з типом підтримує методи, події і властивості із строгими типами. Це означає, що доступ до таблиць і стовпців можливий по іменах і не вимагає використовування методів, заснованих на колекціях. Використовування об'єкту DataSet з певним типом не тільки підвищує легкість коду для читання, але і дозволяє редактору коду Visual Studio .NET автоматично завершувати рядки, що вводяться [55].

     Об'єктна  модель класу DataSet показана на рис. 2.7. 

     

 

     Рисунок 2.7 – Об'єктна модель класу DataSet 

     Логіка  роботи системи, як і будь-якого веб-додатку  побудована за принципом «запит-відповідь», тобто система чекає від користувача запит на виконання дії з даними. У відповідь на цей запит користувачу приходить або набір даних, або підтвердження про те, що зміна даних виконана (або не виконано із якихось причин). Технічно запит користувача є викликом збереженої процедури на сервері баз даних. Відповідь системи є один або декілько об'єктів DataSet як результату виконання збереженої процедури.

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

     Типи  полів класів DataSet еквівалентні відповідним  їм полям в таблицях бази даних. 

     Таблиця 2.9 Структура типізованих таблиць  даних класів  DataSet

 

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

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

 

     3 РОЗРАХУНОК ЕКОНОМІЧНОГО ЕФЕКТУ ВПРОВАДЖЕННЯ СИСТЕМИ ОБЛІКУ ПЛАТІЖНИХ КАРТОК

 
 

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

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

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

     В розрахунку вартості експлуатації системи  розглядаються такі економічні показники  ефективності розробки і упровадження системи, як вартість розробки програмного продукту і вартість її експлуатації.

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

     Дані  для розрахунку вартості створення  і експлуатації системи приведені у табл. 3.1. 
 
 
 

     Таблиця 3.1 – Дані для розрахунку вартості створення ПЗ