Дипломна робота
Розробка програмного забезпечення для системи «Клієнт-Банк»
Анотація
Дипломна робота “Розробка програмного забезпечення для системи «Клієнт-Банк» присв’ячена створенню програмного забезпечення для обміну електронними документами і зв’язку між банком та його клієнтами і забезпечення можливості оперативного управління власними рахунками в банку, мінімізуя час проходження платіжних документів.
В роботі сформульовані вимоги до системи, що розробляється, підібрані необхідні технічні засоби, проведено аналіз інформаційних потоків, алгоритмізацію та програмування програмного забезпечення, що забезпечує функціонування системи.
В дипломній роботі також розглянуті питання економіко–організаційної частини та питання охорони праці.
1.21 Алгоритм RSA
Не дивлячись на досить велике число різних криптосистем, найбільш популярна криптосистема RSA, що розроблена в 1977 році і одержала назву на честь її творців: Рона Рівеста, Аді Шаміра і Леонарда Ейдельмана.
Вони скористалися тим фактом, що знаходження великих простих чисел в обчислювальному відношенні здійснюється легко, але розкладання на множники твору двох таких чисел практично нездійсненно. Доведено (теорема Рабіна), що розкриття шифру RSA еквівалентне такому розкладанню. По цьому для будь-якої довжини ключа можна дати нижню оцінку числа операцій для розкриття шифру, а з урахуванням продуктивності сучасних комп'ютерів оцінити і необхідний на це час.
Можливість гарантовано оцінити захищеність алгоритму RSA стала однією з причин популярності цієї системи на фоні десятків інших схем. Тому алгоритм RSA використовується в банківських комп'ютерних мережах, особливо для роботи з видаленими клієнтами (обслуговування кредитних карток).
В даний час алгоритм RSA використовується в багатьох стандартах, серед яких SSL, S-HHTP, S-MIME, S/WAN, STT і PCT.
Відкритий ключ публікується і доступний кожному, хто бажає послати власнику ключа повідомлення, яке зашифровується вказаним алгоритмом. Після шифрування, повідомлення неможливо розкрити за допомогою відкритого ключа. Власник же закритого ключа без праці може розшифрувати прийняте повідомлення.
1.22 Практична реалізація RSA
В даний час алгоритм RSA активно реалізується як у вигляді самостійних криптографічних продуктів, так і як вбудовані засоби в популярних додатках.
Важлива проблема практичної реалізації - генерація великих простих чисел. Рішення задачі «в лоб» - генерація випадкового великого числа n (непарного) і перевірка його подільності на множники від 3 аж до n0.5. У разі неуспіху слід узяти n+2 і так далі.
У принципі як p і q можна використовувати «майже» прості числа, тобто числа для яких вірогідність того, що вони прості, прагне до 1. Але у випадку, якщо використане складове число, а не просте, криптостойкость RSA падає. Є непогані алгоритми, які дозволяють генерувати «майже» прості числа з рівнем довіри 2-100.
В кінці 1995 року вдалося практично реалізувати розкриття шифру RSA для 500-значного ключа. Для цього за допомогою мережі Інтернет було задіяно 1600 комп'ютерів.
Самі автори RSA рекомендують використовувати наступні розміри модуля n:
768 біт - для приватних осіб;
1024 біт - для комерційної інформації;
2048 біт - для особливо секретної інформації.
Третій важливий аспект реалізації RSA - обчислювальний. Адже доводиться використовувати апарат довгої арифметики. Якщо використовується ключ завдовжки до біт, то для операцій по відкритому ключу потрібен Про(k2) операцій, по закритому ключу - Про(k3) операцій, а для генерації нових ключів потрібен Про(k4) операцій.
Криптографічний пакет BSAFE 3.0 (RSA D.S.) на комп'ютері Pentium-90 здійснює шифрування із швидкістю 21.6 Кбит/c для 512-бітового ключа і із швидкістю 7.4 Кбит/c для 1024 бітового. «Найшвидша» апаратна реалізація забезпечує швидкості в 60 разів більше.
В порівнянні з тим же алгоритмом DES, RSA вимагає в тисячі і десятки тисяч раз більший час.
1.23 Опис алгоритму MD5
Спочатку допускаємо, що маємо на вході повідомлення з b-бит,и що ми бажаємо знайти Message Digest цій послідовності біт.Число b є довільним ненегативним цілим;b може бути рівним нулю, воно не обов'язкове повинне бути множником 8,и воно може бути довільно великим.Представимо послідовність біт повідомлення як:
m_0 m_1 m_2 . . . . . . m{b-1}
Сле дуючі п'ять етапів виконуються для підрахунку Message Digest повідомлення.
Етап 1.Присоединение заповнюючих (додаткових) бітів.
З ообщеніє розширяється так, щоб його довжина (у бітах) співпадала з 448,по модулю 512. Доповнення завжди виконується, навіть якщо довжина повідомлення - вже співпадає з 448 по модулю 512. Доповнення виконується таким чином: одиночний "1" біт додається до повідомлення, і далі "0" біти додаються так що довжина в бітах заповнюваного повідомлення відповідає 448 по модулю 512.В загальному випадку, мінімум один біт і максимум 512 біт додається.
Етап 2. Додавання довжини
64-бітове представлення вхідної послідовності b (довжина повідомлення перед розширенням додатковими бітами) приєднується до результату попереднього етапу. Маловероятно,что довжина b буде більше, ніж 2^64 тому і використовується 64-х розрядна величина для зберігання довжини b.(Ці біти додаються як два 32-і розрядні слова, молодше заноситься першим).У цьому місці остаточне повідомлення(після виконання першого і другого етапів) має довжину, кратну 512 битам,т.е повідомлення має довжину, яка точно кратна 16-ти словам. Послідовність М[0 . . . . N-1] є словами остаточного повідомлення, де N кратно 16.
Етап 3. Ініціалізація MD буфера.
Би уфер на 4-е слова (A,B,C,D) використовується для підрахунку Message Digest.Каждое з A,B,C,D є 32-х бітовим регістром.Ці регістри ініціалізуються наступними шістнадцятковими значеннями, де першим слідує наймолодший байт:
word А: 01 23 45 67word B: 89 ab cd efword З: fe dc ba 98word D: 76 54 32 10
П рограммісти з RSA Data Security,Inc., щоб не утрудняти себе і решти людей з приводу походження цих чисел, просто назвали їх магічними константами.Етап 4.Обработка повідомлення в блоках по 16 слів.
З початку визначаються чотири вспомагательних функції кожна з яких має на вході три 32-бітові слова і виробляє одне 32-бітове слово на виході.
F(X,Y,Z)= XY v not(X) ZG(X,Y,Z)= XZ v У not(Z)H(X,Y,Z)= X xor У xor ZI(X,Y,Z)= У xor (X v not(Z))
У кожній бітовій позиції функція F діє як умовний опреатор : якщо X те У інакше Z. Функція F могла б визначатися з використовуванням операцію + замість v,так як вираз XY and not(X) Z ніколи не матиме 1 в однакових бітових позиціях. Якщо біти X,Y і Z незалежні і незміщені(??),то кожен біт після виконання F(X,Y,Z) буде незалежний і незміщений.Функції G,H і I подібні функції F,они діють в "побітовій відповідності" для знаходження вихідного значення від вхідних бітів X,Y і Z,тем же способом, що якщо біти X,Y і Z незалежні і несмещены,то кожен біт після виконання вищезгаданих функцій буде незалежний і незміщений.Обратите увага, що функція H(X,Y,Z) є порозрядною операцією виключає АБО (тобто функцією контролю парності вхідних значень) .Далее на цьому етапі відбувається чотири цикли, в яких відбувається трансформація бітів повідомлення за допомогою вищезгаданих функцій, функції циклічного зрушення, і таблицю константних значень.Етап 5.Вывод
В результаті виконання попередніх етапів Message Digest виробляє на виході числа A,B,C,D,общая довжина які 128 біт
2. Вибір та обґрунтування структури проектуємої системи, та її компонентів
2.1 Загальні вимоги до програми
Створення незалежної програми у виді файлу, що виконується, працюючого в операційному середовищі Wіndows 9.x ;
Організація FTP доступу до FTP серверу банку;
Орієнтація на "середнього" користувача операційної системі Wіndows 9.x: інтуїтивно зрозумілий інтерфейс, мінімізація кількості дій користувача, наявність розгалуженої системи допомоги, використання стандартних елементів керування;
Орієнтація на користувача-"непрограміста", тобто позбавлення його необхідності вникати в питання, пов'язані зі специфікою роботи з базами даних і особливостямі управління ними;
2.2 Технічні вимоги до системи
Режим роботи розроблювальної автоматизованої системи відправки і обробки платежів є діалоговим. Даний режим визначає собою діалог між комп'ютером і користувачем. Як правило, програма пропонує визначені дії виводячи потрібну інформацію на екран дисплея. Користувач зі своєї сторони спілкується з програмою за допомогою стандартних пристроїв уведення - це клавіатура і миша. Отже, швидкодія розроблювальної системи в основному залежить від швидкості набору вхідної інформації користувачем, від швидкості реакції користувача на діалог з машиною й апаратної частини комп'ютера на якій буде використовуватися дана система. Бажана конфігурація апаратної частини описана в пункті 3.4.1.
2.3 Вимоги до художньо-конструктивного представлення оформлення системи
Перед будь-якою проектованою системою ставляться визначені вимоги в її художнім оформленні. Багато систем клієнт-банк не взяли широкого поширення саме через своє невдале художнє оформлення. У другу чергу рекомендується вибирати не дуже насичену палітру кольорів та написів. Дуже яскраві кольори досить швидко дратують очі, що унеможливлює довгий контакт користувача з програмою. Варто обмежитися постільними тонами в палітрі кольорів. Такі кольори не дратують оболонку ока і забезпечують тривалу роботу користувача з програмним модулем.
Іншою найбільш доладною проблемою є правильність вибору розміру і стилю шрифту. Людіна дуже швідко утомлюється, якщо розмір шрифту в тексті програми дуже малий. Тім більше якщо робота з даним додатком проводитися щодня. Однак занадто великий шрифт теж доставляє масу неприємностей. Він упадає в око і може привести до помилок у введенні інформації користувачем через свою здатність відволікати увагу. Варто використовувати розмір шрифту від 8 до 14.
Варто врахувати і ту проблему, що на користувачів впливають характеристики пристрою відображення, тобто монітори. Головною проблемою тут є вибір дозволу екрана при проектуванні системи. Адже, повно екрана форма роскрита при великому дозволі ніколи не поміститься в доступну для огляду область монітора з меншою здатністю, що дозволяє. На сьогоднішній день оптимальними є дозволи 800х600 і 1024х768 пікселів. Дані дозволи використовуються більшістю користувачів, і тому при проектуванні автоматизованої системи варто обмежитися ними.
Для зручності користування додатком варто уникати великої вкладеності списків підменю. Оптимальне використання іконок із зображенням на них дії яка відбудеться по натиськанню на них. Даний прийом не тільки зручний практично, але і значно збагачує загальний інтерфейс програми.
2.4 Вимоги до замовника
Надання вичерпної інформації про проблему, що постає, під час проектування системи і правильна експлуатація додатка після його створення (по інструкції користувача) і т.д.
Підготовка апаратних засобів для впровадження розроблювального програмного комплексу. Вимоги до апаратної частини описані далі в пункті 3.4.1.
2.5 Спеціальні вимоги
Організація і ведення системи клієнт-банк повинні проводитись з урахуванням зовнішніх взаємозв'язків, забезпечувати надання користувачу всіх необхідних характеристик поточної категорії.
Користувач повинний мати можливість переміщування по записам табліць з використанням стандартних засобів: т. зв. навігатора – набору стандартних кнопок та клавіш управління курсором, за якими історично закріплені певні функції переміщення.
Також користувачу повинна бути надана можливість зміни даних (вставки, редагування, видалення) у тих таблицях, які це передбачують. Для цього виконується розробка форм для введення і редагування даних, що дозволяють однозначно визначити всі характеристики описуваної категорії. Для підвищення зручності використання програмного комплексу користувачу повинні бути надані можливості пошуку і сортування даних.
У зв’язку з тим, що дані можуть змінюватися навіть на протязі учбового процесу, необхідно передбачити можливість повторної зміни введеної інформації.
У зв’язку з тим, що можуть виникнути певні непередбачені обставини щодо подання електроенергії або виходу із строю комп’ютеру, та в зв’язку з тим, що будь-яке програмне забезпечення має певну ступінь надійності, яка не є стовідсотковою, необхідно розробити механізм, який, як мінімум, підвищить ступінь надійності зберігання даних. З цією метою повинне бути організовано покрокове збереження даних у таблицях. Тобто всі зміни у базі даних повинні бути фізично записані на запам’ятовуючому пристрої після кожної, будь якої зміни інформації, а не під час виходу із програми. Це призведе до того, що після непередбаченої обставини користувачу не потрібно буде вводити всю інформацію з початку, а лише продовжити її введення з того самого місця.
3. Основні рішення по реалізації системи в цілому та її окремих компонентів
3.1 Інформаційне забезпечення
3.1.1 Аналіз інформаційних потоків.
Розглянемо всі інформаційні потоки і зв'язки усередині системи розробки і впровадження задач. Вхідними даними для системи клієнт-банк (сервер) є інформація получена від клієнта у вигляді текстового файлу. Входними даними для системи клієнт-банк (клієнт) , є інформація, що вводиться, користувачем про платіж. Також вхідними даними являються текстові файли «виписки», які система одержує при зв'язку з системою клієнт-банк (сервер).

Блок-схема алгоритму обміну даними з банком

3.1.2 Структура таблиці.
Таблиця 3.1.2.1
“OPL.DB” – платежі.
Поле
Тип
Опіс

ID
AUTOINC
Перемінна ідентифікатор. Повинна бути унікальної і завжди мати значення. Це унікальний номер платіжного доручення.

DATE
DATE
Дата платежу.

KON
STRING(255)
Назва контрагента.

‘B_MFO’
STRING (9)
МФО банку одержувача.

B_NAME
STRING (40)
Назва банку одержувача.

PC
STRING (255)
Номер розрахункового рахунку, в банку одержувачі.

SUM
FLOAT
Сума платежу.

STAT
STRING (3)
Статус платежу.

DK
BOOLEAN
Прихід/Витрата

FILE_N
STRING (21)
Ім’я текстого файлу платіжного доручення.

3.2 Програмне забезпечення
3.2.1 Обґрунтування вибору мови і системи програмування
У даний час все частіше використовуються візуальні мови програмування. Дані мови програмування зручні через досить багаті бібліотеки, що накопичувалися роками. Вони дають можливість досить швидко і без особливих зусиль створити робочий додаток зі звичним для користувачів інтерфейсом. Візуальні компоненти звільняють програміста від довгострокової роботи над інтерфейсом програми і дають можливість цілком зосередитися на поставленій задачі.
Тепер на ринку ПО пропонується кілька систем візуального програмування. У першу чергу це Delphi, C++ Builder, Visual Basic, Visual C++. Найбільш повними, універсальними і часто використовуваними системами є Delphi і Builder C++ від Borland. Ці мови мають найбільшу і наймогутнішу бібліотеку візуальних компонентів. Крім того, ця бібліотека постійно поповнюється за рахунок інших компаній, що створюють програмне забезпечення. Безліч нових компонентів можна знайті у всесвітній мережі Internet. Система Delphi є ще й однією з найпростіших у вивченні, що дає їй перевагу над іншими візуальними мовами. Delphi має прекрасні засоби для обробки і збереження як локальних так і мережевих баз даних. Виходячи із цього зупиняємо вибір на системі Delphi-7.0. Ця версія продукту фірми Borland є однією з розповсюджених розробок і має всі необхідні компоненти для розробки автоматизованої системи формування довідників.
Як операційне середовище для функціонування програмного комплексу була обрана платформа wіn32 (їй відповідають операційні системі Wіndows95, Wіndows98 і т.д.), що обумовлено наступними її особливостями:
орієнтація ВНЗ на цю платформу;
розвинені засоби створення користувальніцького інтерфейсу;
достатня масштабуємість, тобто здатність працювати на широкому діапазоні комп'ютерного устаткування, починаючи від машин початкового рівня Pentium до багатопроцесорніх систем;
наявність драйверів для підтримки широкого спектру периферійних пристроїв (відеоадаптерів, мережніх адаптерів, принтерів, дисководів CD-ROM і ін.);
надзвичайно широке поширення цієї платформи;
Вибір пакету Borland Delphі 7.0 обумовленій наступними його особливостями:
можливість повторного використання готових програмних компонентів;
наявність великої кількості стандартних компонентів, а також достатня кількість бібліотек компонент від сторонніх фірм, що розширюють і доповнюють можливості стандартних;
можливість генерації коду під платформу wіn32;
підтримка технологій ActіveX, OLE, COM, ІnterNet-технологій;
досить висока швидкість і надійність роботи скомпільованих