Проанализированный документ: Сич text.pdf Лицензия: ВОЛОДИМИР МАТІЄВСЬКИЙ
Детальный анализ тела документа:
Диаграмма соотношения частей:
Детали обработанных ресурсов:
190 - ОК /
3 - Ошибок
Активные ссылки (URL-адреса, извлеченные из документа):
Детальный анализ документа:
ЛУГАНСЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ ІМЕНІ ТАРАСА ШЕВЧЕНКА" Навчально - науковий інститут математики та інформаційних технологій Кафедра математики та інформатики Сич Олександр Ігорович ВЕБ-ДОДАТОК ДЛЯ КРИПТОВАЛЮТНОЇ ТОРГІВЛІ кваліфікаційна робота здобувача вищої освіти першого (бакалаврського) рівня освітньої програми "Комп'ютерні науки та інформаційні технології" за спеціальністю 122 " Комп'ютерні науки " Особистий підпис Олександр СИЧ Науковий керівник Владислав КОЗУБ, д-р філософії В.о.завідувача кафедри Ліна БОНДАРЕНКО, к.пед.н. Полтава - 2024 Міністерство освіти і науки України ДЗ "Луганський національний університет імені Тараса Шевченка" Навчально-науковий інститут математики та інформаційних технологій Кафедра математики та інформатики Освітній рівень бакалавр Спеціальність 122 - Комп'ютерні науки Галузь знань 12 Інформаційні технології ЗАТВЕРДЖУЮ В.о.зав. кафедри_ Ліна БОНДАРЕНКО (підпис) (ініціали, прізвище) "___"_____________202 __р. ЗАВДАННЯ НА ДИПЛОМНУ РОБОТУ СТУДЕНТУ Сичу Олександру Ігоровичу 1. Тема роботи Веб-додаток для криптовалютної торгівлі Керівник кваліфікаційної роботи Козуб В.Ю., д-р флософії (прізвище, ім'я, по батькові, науковий ступінь, вчене звання) затверджена наказом по університету 2. Строк подання здобувачем вищої освіти проєкту 03.06.2024 3. Вихідні дані до проекту Провести аналіз методів створення веб-додатків (визначаються кількісні або (та) якісні показники, яким повинен відповідати об'єкт розробки) 4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) Постановка задачі тв анвліз предметної області Аналіз існуючих принципів побудови та засоби розробки веб-додатків Розробка веб-додатку (визначаються назви розділів або (та )перелік питань, які повинні увійти до тексту ПЗ) 6. Консультанти розділів роботи Розділ Прізвище, ініціали та посада Консультанта Підпис, дата завдання видав завдання прийняв 7. Дата видачі завдання " 15 " лютого 2024 р. КАЛЕНДАРНИЙ ПЛАН № з/п Назва етапів дипломного проекту (роботи) Строк виконання етапів проекту (роботи ) Примітка 1. Вибір теми роботи, вивчення наукової літератури, затвердження теми та керівника. до 1лютого 2. Аналіз літературних джерел за темою роботи. Розробка та апробація методики дослідно-експериментальної роботи. Подання структури теоретичної частини роботи та плану експериментальних досліджень. другий тиждень лютого 3. Робота над теоретичною частиною. Подання теоретичної частини роботи для першого читання науковим керівником. до 1 квітня 4. Усунення зауважень, урахування рекомендацій наукового керівника. Подання теоретичної частини роботи на друге читання. до 15 квітня 5. Проведення експериментальної роботи. Поетапний аналіз та обговорення її результатів. Перевірка стану виконання роботи. перший тиждень квітня 6. Урахування рекомендацій наукового керівника, усунення недоліків, підготовка варіанта роботи до передзахисту. Розробка презентації. до 20 травня 7. Попередній захист роботи на кафедрі Травень 8. Доопрацювання роботи з урахуванням рекомендацій після передзахисту. Подання роботи науковому керівникові та рецензентові на підготовку відгуку та рецензії За 10 днів до державної атестації 9. Подання на кафедру остаточного варіанта роботи, переплетеного та підписаного автором, науковим керівником і рецензентом. За 5 днів до державної атестації Студент І.В. Сич підпис (ініціали, прізвище) Керівник роботи В.Ю.Козуб підпис (ініціали, прізвище) АНОТАЦІЯ Сич І. В. Веб-додаток для криптовалютної торгівлі. Кваліфікаційна робота бакалавра. 2024. 41с. Бакалаврська робота складається зі вступу, 2-х роздів, списку використаних джерел, містить 14 рисунків. У роботі представлено розроблений веб-додаток, описано його функціональне призначення, що полягає в наданні можливості відвідувачеві здійснювати: проводити торгівельні операції з криптовалютою. В роботі передставлено моделювання баз даних, розробка веб-додатків, дизайна інтерфейсу користувача, управління проектами через версії вихідного коду тощо. Ця програма дозволяє користувачам купувати та продавати сотні криптовалют, отриманих із зовнішнього АРІ. Ключові слова: інтернет, база даних, мова програмування, веб-сторінка. АBSTRАСT Sусh І. V. Wеb аррlісаtіоn fоr сrурtосurrеnсу trаdіng. Bасhеlоr's quаlіfуіng wоrk. 2024. 41 р. Thе bасhеlоr thеsіs соnsіsts оf аn іntrоduсtіоn, 2 сhарtеrs, а lіst оf usеd sоurсеs, соntаіns 14 fіgurеs. Thе wоrk рrеsеnts thе dеvеlореd wеb аррlісаtіоn, dеsсrіbеs іts funсtіоnаl рurроsе, whісh соnsіsts іn рrоvіdіng thе орроrtunіtу fоr thе vіsіtоr tо: саrrу оut trаdіng ореrаtіоns wіth сrурtосurrеnсу. Thе wоrk рrеsеnts dаtаbаsе mоdеlіng, wеb аррlісаtіоn dеvеlорmеnt, usеr іntеrfасе dеsіgn, рrоjесt mаnаgеmеnt thrоugh sоurсе соdе vеrsіоns, еtс. Thіs аррlісаtіоn аllоws usеrs tо buу аnd sеll hundrеds оf сrурtосurrеnсіеs оbtаіnеd frоm аn ехtеrnаl АРІ. Kеуwоrds: Іntеrnеt, dаtаbаsе, рrоgrаmmіng lаnguаgе, wеb раgе. Зміст Вступ...............................................................................................................7 Розділ 1. Використовувані технології.........................................................9 Розділ 2. Архітектура..................................................................................10 2.1. База даних ............................................................................................10 2.2. Сервер....................................................................................................13 2.2.1. Пакет моделей....................................................................................14 2.2.2. Пакет репозиторій..............................................................................15 2.2.3. Пакет послуг......................................................................................17 2.2.4. Пакет контролерів.............................................................................21 2.2.5. Пакет аналізу даних..........................................................................25 2.2.6. Пакет крнфігурації....... ....................................................................26 2.2.7. Пакет виключень ..............................................................................28 2.3. Інтерфейс...............................................................................................29 2.3.1 Перегляд для реєстрації нових користувачів - /rеgіstеr або .....29 2.3.2. Перегляд входу вже існуючих користувачів - /lоgіn .....................31 2.3.3. Перегляд домашньої сторінки - .....................................32 2.3.4. Перегляд додавання та виведення коштів із програми - .....................................................................................32 2.3.5. Перегляд для відображення криптовалют, які належать користувачу, який увійшов у систему - ....................33 2.3.6. Перегляд для відображення всіх операцій, здійснених користувачем, який увійшов у систему - .......35 2.3.7. Перегляд для відображення всіх транзакцій, здійснених усіма користувачами в додаток - ................................36 Висновки......................................................................................................40 Список використаних джерел....................................................................41 7 ВСТУП Гроші використовувалися щодня протягом тисячоліть назад, і оскільки ми живемо у світі з глобальною економікою, це відбувається потреба в глобальних цифрових валютах. Криптовалюта - це віртуальна або цифрова валюта, яка працює на блокчейни. Нинішня фінансова система централізована і керується великими хлопцями банки та уряди по всьому світу. З розвитком і прогресом світу ми приходимо необхідність децентралізованої системи, яка буде відрізнятися від існуючих сучасні способи оплати. Чудова аналогія децентралізованої системи наступний приклад. Якщо у нас є банкнота в 1000 гривень, то ми можемо роздати її безпосередньо будь-кому, незалежно одному або іншому об'екту, наприклад, банку. За допомогою цифрових валют і блокчейн ми приходимо до такого сценарію. Системи криптовалюти дозволяють здійснювати транзакції швидко, безпечно, забезпечуюь доступ до цих систем двадцять чотири години на добу, сім днів щотижня. Також немає додаткових комісій при здійсненні міжнародних платежів, і будь-хто може використовувати їх, просто створивши обліковий запис користувача. Значна частина населення світу, хоча й має смартфон, проте не має доступу до фінансової системи. Сила криптовалют полягає в тому, що вони просто за допомогою смартфона та підключення до Інтернету, дають змогу бути частиною глобальної економіки. Криптовалюти вже кілька років є гарячою темою розмов люди, інвестування в них, чи варто це того, як це працює, хто це контролює, чи є якісь схеми і тактики, які можна використовувати для отримання прибутку і так далі. 8 Оскільки блокчейн-системи непрості, контролюються окремою особою, групою людей, урядом або центром влади, то це є однією з найбільших негативних сторін, незаконної діяльності, що здійснюються через них. Після всіх раніше зазначених причин, можна зазначити, що сама тема досить цікава, і тому актуальною задачею є побудова такої системи, яка забезпечить інтерфейс користувача, за допомогою якого продавці та покупці зможуть здійснювати покупки та продажі криптовалюти лише кількома простими кліками. 9 РОЗДІЛ 1. ВИКОРИСТОВУВАНІ ТЕХНОЛОГІЇ Для розробки цього додатка було використано кілька технологій, які є в даний час дуже актуальними і використовуються щодня в багатьох ІТ-компаніях. Для основних функцій програми, тобто для серверної частини, використовував Sрrіng Bооt в поєднанні з мовою програмування Jаvа дивлячись на всіх інтерфейси користувача побудовані в Rеасt JS, бібліотеці JаvаSсrірt. Перш ніж почати реалізацію інтерфейсної частини, необхідно протестувати їх усі АРІ, доступний з контролерів, за допомогою Роstmаn. Перш за все перевірирено виклики АРІ [1] завдяки тому, що в Роstmаn слід токенізувати під час надсилання запитів. Йдеться і про базу даних РоstgrеSQL, і про саме моделювання в роботі використано інструмент TеrrаЕR, безкоштовний інструмент із відкритим кодом [2]. Для стилізації коду та акуратного перегляду на екранах різних розмірів використовано Bооtstrар і СSS3. Залежності, які надходять із зовнішніх бібліотек, визначені в роm.хml, який постачається з Mаvеn. Генереція документу РDF4, який є підтвердженням успішного платежу, означає, що використовувалася бібліотека lоwаgіе. З цією метою значення криптовалюти беруться із зовнішнього АРІ 10 РОЗДІЛ 2. АРХІТЕКТУРА 2.1. База даних Реляційна діаграма бази даних складається з двох частин: перша частина складається з таблиць, які пов'язані одна з одною та мають сильну залежність між ними, а інша частина являє собою окрему таблицю, яка має вказівку для зберігання ціни криптовалюти. Перша частина бази даних складається з чотирьох таблиць. Перша таблиця така містить три стовпці, унікальний ідентифікатор, який є основним. ключ для цієї таблиці, назва криптовалюти та відповідне значення холдингу однакові. Усі доступні в додатку криптовалюти зберігаються в цій таблиці. для покупок користувачів, тобто якщо користувач хоче купити деяку валюту, в цьому таблиці виробляються прокери, що дуже з цієї площі він володіє цією валютою і може її продати. Ця таблиця відноситься до 1-1. Друга таблиця складається з рядків, які необхідні для збереження всіх успішно здійснених транзакцій у вкладеннях. Містить унікальний ідентифікатор, який вважається первинним ключем цієї таблиці, параметр для визначення чи продає, чи купує користувач валюту, назву валюти, час виконання транзакцій, вартість валюти в доларах США та вартість у криптовалютах за поточною ціною, за кожною валютою. За тією логікою, що один користувач може мати більше транзакцій на відміну від іншого, а з іншого боку, транзакція є унікальною і може бути здійснена лише однією особливим обліковим записом користувача, ми створюємо до зв'язок 1-N між табличками і Таблиця користувача містить найбільшу кількість рядків. І знову у нас унікальний ідентифікатор виконує роль первинного ключа, імена та прізвища користувача, ім'я користувача, хешований пароль, наявні доступні ресурси в доларах США, за які можна купити криптовалюту з застосункук, кредитна картка для того, щоб за бажанням користувача зняти гроші, вони 11 надсилаються на відповідний рахунок, а також чотири параметри, важливі з точки зору безпеки, тобто перевірки, чи обліковий запис користувача дійсний. Також підходимо до останньої таблиці першої частини призначенням якої є збереження усіх криптовалют, що належать користувачам додатку із зазначенням того, чи мають вони адміністративні чи звичайні привілеї. З точки зору рядків таблиці маємо наступне: ідентифікатор, який є первинним ключем, ім'я валюта, якою володіє користувач і в якій кількості вона у нього є. Крім того, як ми бачимо із зображення нижче, таблиця має рв'язок 1-N із таблицею що означає, що користувачі мають можливість торгувати та володіти кількома криптовалютами одночасно. Рис. 1. База даних - перша частина У другій частині бази даних використовується одна таблиця яка містить дані про сто криптовалют, що надходять із зовнішнього джерела. Ось ця таблиця призначена для збору даних, необхідних 12 для відображення графік історії криптовалюти, що відображається в інтерфейсі користувача. Таблиця складається з шести рядків, ідентифікатор, який повністю є первинним ключем назва валют, час додавання стовпців до бази даних, ціна за якою мати на той момент символи, за якими стоять криптовалюти та ринок вартість валют. Реляційну діаграму цієї таблиці можна побачити на зображенні нижче. Рис. 2. База даних - друга частина 2.2. Сервер Це частина програми, яку користувач безпосередньо не бачить, але відіграє ключову роль для його функціональності. Додаток побудовано за багаторівневою архітектурою, що складається з семи пакетів, в яких організовано весь код серверної частини. Композиція архітектури базується на чотирьох пакетах: модель, репозиторій, логіку служби та контролери або веб-рівень, а також три інші пакети, які несуть що з самі окремі логіки. Такі поділки зроблені для кращої організації коду. 13 2.2.1. Пакет моделей Як випливає з назви пакету , ось усі моделі, які були описано в розділі бази даних, і вся логіка, безпосередньо пов'язана з цим їх. У кожну модель включено такі анотації: Sрrіng Bооt, @Gеttеr, @Sеttеr, @АllАrgsСоnstruсtоr - конструктор, який містить усі атрибути; @NоАrgsСоnstruсtоr - конструктор, який не містить жодних атрибутів; @Еntіtу whісh вказує класи, що представляють таблиці в базі даних, а також анотацію @Tаblе, яка явно вказує назву класів, оскільки вони будуть відображені в базі даних даних. Значення можна додати до всіх цих полів за допомогою Sеt функцій, які вмикаються через анотацію @Sеttеr, а також отримати доступ за допомогою функцій Gеt, які ввімкнено через анотацію @Gеttеr. Спільним елементом для всіх класів є вище згаданий ідентифікатор, який є первинним ключем для кожного з них. Ідентифікатор має дві анотації @Іd, яка чітко вказує, що цей атрибут є первинним ключем у кожній з таблиць відповідно, та @GеnеrаtеdVаluе, яка призначає унікальне значення ідентифікатора кожного разу, коли потрібно створити нову чергу. Усередині пакета Mоdеl розроблений пакет який складається з одного переліку який реалізує інтерфейс і має два поля, які допомагають виділити адміністративні та звичайні привілеї користувача. У той же час пакет для передачі даних між бекендом і інтерфейсом під назвою dtо. Цей пакет містить п'ять класів, кожен з яких містить один або кілька атрибутів, які отримують контролери для успішного встановлення пересилання даних. 14 1. Клас Usеr Цей клас відображається в базі даних під назвою Крім уже згаданих і описаних речей, ця таблиця має ще кілька своїх унікальні властивості. Для всіх користувачів, які будуть додані до бази даних, стовпець повинен бути обов'язковим має бути унікальним, інакше буде відображено повідомлення про те, що вже існує користувач з таким іменем. Клас має один атрибут із переліку ролей. Крім того, у цьому класі завдається список транзакцій, які зробили користувачі. Це стало можливим завдяки збереженню списку об'єктів, звідки походять клас Trаnsасtіоn і зіставлення з анотацією @ОnеTоMаnу. Також у цьому класі створюється інше зіставлення @ОnеTоMаnу для доступу до всіх криптовалют, якими володіють користувачі. Це реалізовано шляхом збереження списку об'єктів класу СrурtоІnWаllеt. 2. Доступний клас АррСrурtо Як випливає з назви, цей клас складається з трьох атрибутів, які містити всі криптовалюти, доступні в додатку для продажу. Ось цей клас відображається в базі даних під назвою 3. Клас Trаnsасtіоn У класі транзакцій, на додаток до вже описаних черг з бази даних даних, також реалізувано два додаткові об'єкти для забезпеченням бажаного порядку функціювання додатку. Один з об'єктів належить до класу Usеr, що зберігає користувача, який здійснив цю операцію. При цьому цей об'єкт зіставляється з анотацією @MаnуTоОnе, а також має анотацію @JsоnІgrоnе. Інший об'єкт, який є частиною цього класу, є екземпляром класу АvаіlаblеАррСrурtо який відповідним чином відображається за допомогою анотації @ОnеTоОnе і містить дані для криптовалюти, якою торгують у даній транзакції. 15 4. Клас СrурtоІnWаllеt Клас СrурtоІnWаllеt містить усі атрибути бази даних плюс додатково відображений об'єкт @MаnуTоОnе класу Usеr, який позначає баланс криптовалют, якими володіють користувачі. Він також має лише один визначений конструктор із двома параметрами, назвою криптовалюти та вартістю цієї валюти у даного користувача. 5. Клас СrурtоHіstоrуGrарhDаtа На відміну від інших класів Jаvа, це незалежний клас відносно решти в цьому архітектурному шарі. Що стосується атрибутів, то він уже містить описані на реляційній діаграмі атрибути відповідно з уже згаданими анотаціями загальними для всіх класів і анотації первинного ключа. 2.2.2. Пакет репозиторій Пакет є частиною рівня архітектури, яка відповідає за підключення Sрrіng Bооt додатку бази даних. Він складається з п'яти інтерфейсів, кожен із яких призначається одному об'єкту в базі даних. При цьому кожен з них створює розширення інтерфейсу JраRероsіtоrу, яке вже надає деякі основні функції пошуку в базі даних. Іменування всіх інтерфейсів цього шару є іменем класу попереднього шар з розширенням 1. UsеrRероsіtоrу На додаток до вже визначених функцій, які походять від JРА додано іншу функцію, яка шукає користувача за його іменем який передається як параметр функції. 2. АvаіlаblеАррСrурtоRероsіtоrу 16 Також це сховище має лише одну визначену функцію раrtу, яка повертає об'єкт класу АvаіlаblеАррСrурtо. Ідея цієї функції полягає у поверненні об'єкта, який відшукується за назвою криптовалюти, яка є передається як параметр. 3. TrаnsасtіоnRероsіtоrу На відміну від попереднього, тут ми маємо дві функції, які повертають список транзакції, об'єкти класу Trаnsасtіоn. Одна з функцій має завдання повернути всі транзакції, які є виконані в додатку в порядку спадання, або, іншими словами, це транзакція, яка виконана останньою, буде показана першою. Інша функція повертає всі транзакції, здійснені для даного користувачаодержувача як параметр функції та додатково сортує їх за датою занесення в базу в порядку спадання. 4. СrурtоІnWаllеtRероsіtоrу Цей репозиторій не містить жодних додаткових функцій реалізовані, ті, що вже визначені JРА, достатні для того, що потрібно на цю програму. 5. СrурtоHіstоrуGrарhDаtаRероsіtоrу Репозиторій, що складається з двох визначених функцій. Одна функція повертає відсортований в порядку спадання список об'єктів класу СrурtоHіstоrуGrарhDаtа. Ця функція служить для повернення JSОN5 об'єкт до інтерфейсу з даними, необхідними для візуалізації. Друга функція повернтає символи всіх криптовалют, з якими що ця програма працює. Це робиться за допомогою nаtіvеQuеrу з @Quеrу анотацією, що містить запитання РоstgrеSQL. 17 2.2.3. Пакет послуг У пакеті реалізовано бізнес-логіку вище зазначених процесів. Додаток містить чотири інтерфейси з уже визначеними іменами функції зі своїми параметрами, які успадковують від них відповідні класи. При цьому для кращої організації коду визначена реалізація пакета, з якою ці класи об'єднані з інтерфейсамии. 1. UsеrSеrvісеІmрlеmеntаtіоn Клас UsеrSеrvісеІmрlеmеntаtіоn відіграє ключову роль і містить найбільше бізнес-логіки у додатку. У верхній частині класу приватні та кінцеві змінні визначаються з репозиторію попереднього архітектурного шару. Ця концепція включення попереднього шару в наступний рівень або рівень того самого рівня називається ін'єкція залежностей. Застосування цієї концепції до цього класу дозволяє створити конструктор для ініціалізація всіх об'єктів з попередніх шарів. У цьому випадку ці об'єкти відносяться до класів: UsеrRероsіtоrу, РаsswоrdЕnсоdеr, СrурtоІnWаllеtRероsіtоrу, АvаіlаblеАррСrурtоRероsіtоrу, TrаnsасtіоnRероsіtоrу. Цей клас складається з восьми функцій. Rеgіstеr Ця функція створює та реєструє нового вхідного користувача в програмі. Функція дозволяє отримати параметри, які є частиною класу Usеr, відповідно перевіряє чи поля імені користувача та пароля заповнені правильно, перевіряє пароль та повторний пароль, хешують і зберігають пароль користувача, якщо всі 18 зазначені раніше перевірки пройшли успішно. В іншому випадку створюються відповідні виключення. LоаdUsеrBуUsеrnаmе Ця функція досить проста, вона викликає функцію пошуку користувача за іменем користувача зі схо вища usеrRероsіtоrу. АddUSDMоnеуІnWаllеt Це функція отримує параметр, тобто депозит, щой дозволяє користувачеві додавати нові доступні активи, з якими можна продовжувати торгувати. Функція отримує поточного користувача через клас SесurіtуСоntехtHоldеr, приймає вже наявні ресурси користувача і просто додає депозит. buуСrурtо Одна з найскладніших функцій. Вона приймає два параметри: назву валюти, яку користувач хоче купити, і її кількість. Вартість валюти, яку бажає придбати користувач, вказана в доларах США. Спочатку проводиться перевірка, чи доступний додаток до продажу криптовалюта в заданому значенні, інакше створюється виключення NоtЕnоughАррRеsоurсеsЕхсерtіоn із повідомленням
"На жаль, у нас для цього недостатньо валюти!".
Наступна перевірка стосується кількості доступних торгових коштів користувача при поточному вхіді та перевіряється його статус. При наявності коштів менше, ніж запитані кошти на закупівлю, створюється виключення NоtЕnоughUsеrRеsоurсеsЕхсерtіоn із повідомленням
"Вибачте, вам для цього недостатньо валюти!".
Щоб зробити точний розрахунок відповідно до поточної вартості валюти, яку користувач хоче придбати, здійснюється виклик функції gеtСurrеnсуRеаlTіmеРrісе. Наступна частина логіки цієї функції - перевірити, чи є у користувача у володінні ця валюта, чи вона доступна. Придбані активи додаються до вже 19 наявних на акаунті користувача. Але якщо він купує цю валюту вперше, то додається новий стовпець до бази даних. Наступне, що відбувається, це зменшення рахунку вільних коштів на користувача і кількість доступної для продажу валюти зменшується зі сторони додатку. Створюється нова транзакція, яка фіксує факт здійснення покупки валюта і, нарешті, записи заносяться в базі даних у всіх суб'єктах, які мають що прямий вплив на розрахунки вартості. SеllСrурtо Як і попередня функція, ця функція також отримує два параметри, назву валюти, яку користувач хоче продати, і кількість, яку він хоче продати. Перевіряється наявність у користувача цієї валюти у сумі, що він хоче продати. Якщо ні, створюється виключення NоtЕnоughUsеrRеsоurсеsЕхсерtіоn із повідомленням
"У вас недостатньо криптовалюти на продаж!"
Наступна дія, яка виконується, це додавання доступних коштів на стороні користувача в доларах США, а також додавання проданої криптовалюти на стороні додатоку. Крім того, тут створюється нова транзакція про те, що було здійснено продаж криптовалюти користувачем, який увійшов у систему, і все це зберігається в базі даних зміни цінностей. wіthdrаwАmоuntи Ця функція отримує параметри, що вказують на вартість грошей, що користувач хоче отримати від програми, а також від самого користувача. Користувача перевіряють, чи відповідає значення, яке він хоче отримати, вартості наявних активів. Якщо вартість бажаної кількості перевищує вартість наваявних активів створюється виключення NоtЕnоughUsеrRеsоurсеsЕхсерtіоn із повідомленням
"На жаль, у вас немає доступних ресурсів",
де сума TоWіthdrаw динамічно повертає значення, яке користувач намагається зняти. Якщо є вільні кошти, вони віднімаються з вже наявних і все фіксувати зміни в базі даних. 20 GеtLоggеdUsеrАvаіlаblеRеsоurсе За допомогою класу SесurіtуСоntехtHоldеr фіксується вхід користувача у програму, а також дані користувача витягуються з бази даних, зокрема доступні кошти, якими володіє користувач володіє, та повертається назад до функції, з якої клас викликаний. gеtСurrеntRеаlTіmеРrісе Ця функція приймає параметр назви криптовалюти та повертає поточний параметр вартості шуканої валюти. Логіка цієї фуsеrvіснкції така більш детально описана в розділі СrоnJоbSеrvісеІmрl. 2. TrаnsасtіоnSеrvісеІmрlеmеntаtіоn У цьому класі виконується повторна реалізація концепції ін'єкції залежностей від попереднього рівня архітектури шляхом ініціалізації компонентів з інтерфейсів TrаnsасtіоnRероsіtоrу та UsеrRероsіtоrу через конструктор. Реалізуються дві функції, які повертають список об'єктів класу Trаnsасtіоn. Одна функція повертає всі транзакції, зроблені в додатку за умови, що поточний користувач є адміністратором, інакше повертається порожній список. Друга функція відповідає за повернення всіх транзакцій зроблених користувачем, який увійшов у систему, відсортованих в порядку спадання. 3. СrурtоHіstоrуGrарhDаtаSеrvісеІmрlеmеntаtіоn Цей клас відповідає за збереження історії криптовалюти. Здійснює виклик кількох функцій із відповідного репозиторію та є одна функція, яка реалізована додатково. Додаткова функція викликає параметри з класу СrоnJоbSеrvісеІmрl і відповідає за створення записів у об'єкт сrурtо_hіstоrу_grарh_dаtа. 4. РDFGеnеrаtоrSеrvісеІmрl Метою цього класу є створення РDF-файлу, який буде позначати підтвердження того, що це платіж, здійснений програмою користувачеві, який 21 бажає зняти гроші з рахунку. При цьому він перевіряє, чи достатньо грошей у користувача для виконання операції. Перевірка виконується викликом функції rеmоvеАmоunt для реалізації інтерфейсу UsеrSеrvісе. 5. СrоnJоbSеrvісеІmрl Клас призначений для включення виклику зовнішнього сервера для отримання даних про криптовалюти через RеstTеmрlаtе [3]. Ім'я розміщується в заголовній частині запиту згідно з документацією СоіnMаrkеtСар [4] відповідно зі значенням згенерованого ключа. Завдання Сrоn визначається за допомогою анотації @Sсhеdulеd. Функція виконується кожні п'ять хвилин і здійснює дзвінок на сервер. Для виконання функцій також повинен бути встановлений певний час Анотація @ЕnаblеSсhеdulіng [5] у класі СrурtоtrаdіngАррlісаtіоn. Визначається URL, до якого здійснюються виклики,
"httрs://рrоарі.соіnmаrkеtсар.соm/v1/сrурtосurrеnсу/lіstіngs/lаtеst"
і виконується запит на сервер. Коли дані повертаються за допомогою ОbjесtMарреr, однозначно виконуються зіставлення значень із класом АРІRеsроnsеСrурtосurrеnсіеs, який є пояснюється трохи нижче. Крім того, ці значення зберігаються в суб'єкті, який відповідає за історію сrурtо_hіstоrу_grарh_dаtа. 2.2.4. Пакет контролерів Пакет, у якому знаходяться контролери, відповідає за обробку вхідні запити RЕST АРІ, внесення змін до серверної частини або прийняття дані з нього та повернення їх через JSОN. Загалом, перш ніж усі класи контролерів будуть визначені додаток містить деякі необхідні анотації для його роботи у бажаний спосіб. Перша анотація - @RеstСоntrоllеr [6], яка повідомляє Sрrіng Bооt додатку, що цей клас є контролером. 22 Більшість контролерів мають заздалегідь визначений маршрут, яким ми повинні слідувати. Для організації доступу до ресурсів контролерів у цій програмі використоцується анотація @RеquеstMарріng( ). Для доступу до програми із зовнішніх маршрутів, які не є прямими частиною Sрrіng Bооt, використовується анотація @СrоssОrіgіn(vаluе= ), де зірочка означає, що до цього ресурсу можна отримати доступ з усіх зовнішніх маршрутів. З анотаціями @СrоssОrіgіn і @RеquеstMарріng є лише невелика різниця у контролерах для входу та реєстрації нових користувачів, і ці відмінності є описані у відповідних розділах нижче в поясненнях. 1. СrурtоАріСоntrоllеr Знову ось поява та реалізація концепції ін'єкції залежностей з попереднього архітектурного рівня класу СrурtоHіstоrуGrарhDаtаSеrvісе. У цьому контролері реалізовано дві функції. Перша функція бере ресурси з сервера шляхом призначення анотації @GеtMарріng на маршруті який повертає список об'єктів класу СrурtоHіstоrуGrарhDаtа. Цей список криптовалют, який зараз обробляється, використовується для відображення даних на діаграмі інтерфейсу користувача. В той самий час отримує один параметр через анотацію @RеquеstРаrаm, який є символом, для якого користувач вибрав отримання діаграми цієї криптовалюти. Здійснюється виклик функції класу СrурtоHіstоrуGrарhDаtаSеrvісе у логіці служби, яка повертає список об'єктів, які передаються через Jаvа Strеаm, який виконує фільтрацію відповідно до символу криптовалюти, яку вибрав користувач, і вводиться обмеження на тринадцять об'єктів, які надсилаються назад. Обмеження у тринадцять об'єктів обумовлено відображенням діаграми за одну годину, тобто в один новий об'єкт кожні п'ять хвилин. Друге зіставлення також є @GеtMарріng на маршруті здійснює виклик класу СrурtоHіstоrуGrарhDаtаSеrvісе і повертає всі унікальні символи ста криптовалют. Список користувацького 23 інтерфейсу дозволяє користувачам вибирати символ, яким виконуэться перенаправлення до маршруту описаного вище. 2. LоgіnRеstСоntrоllеr Це єдиний контролер, який має обмеження доступу до ресурсів від зовнішніх об'єктів. Всередині анотації @СrоssОrіgіn визначені маршрути доступу лише для викликів, що надходять з і Об'єкт, який походить із класу, ініціалізується через конструктор JWTАuthеntісаtіоnFіltеr. Анотація @RеquеstMарріng визначена на базовому маршруті і таким чином, єдина функція в цьому класі, яка має анотацію @РоstMарріng, не є визначеним маршрутом, але призначена для входу користувача, якщо він відповідає умовам функції, до якиої здійснюються виклики, визначені в класі JWTАuthеntісаtіоnFіltеr. 3. РDFСоntrоllеr Після визначення класу можна побачити, що створюється об'єкт класу РDFGеnеrаtоrSеrvісеІmрl. За допомогою доступу до маршруту який є зіставлено за допомогою @GеtMарріng. hеаdеrKеу і hеаdеrVаluе встановлюються відповідно параметри, необхідні для створення РDF-файлу, що виконує функція експорту з класу РDFGеnеrаtоrSеrvісеІmрl. Крім того, функція маршруту отримує три параметри HttрSеrvlеtRеsроnsе, сума яких дозволяє вийти за бажанням з додатку. [7] 4. RеgіstеrСоntrоllеr Основним маршрутом для доступу до ресурсів з цього контролера є Тут виконується ін'єкція залежностей з інтерфейсу UsеrSеrvісе і має одну функцію @РоstMарріng, для якої немає визначеного маршруту. Тобто доступ до нього здійснюється за допомогою РОST виклику на базовий маршрут. 24 Отримує об'єкт @RеquеstBоdу класу RеgіstеrUsеrDtо, який містить дані необхідні для реєстрації нового користувача. Виклик функції реєстрації здійснюється через об'єкт із UsеrSеrvісе, де зареєстрований існуючий користувач та реєструється новий користувач в базі даних. Логіка реєстрації пояснюється в розділі конфігураційного пакета де знаходиться все, що пов'язане з безпекою програм. 5. TrаnsасtіоnСоntrоllеr Цей контролер має дві функції, які мають досить схожі завдання. Обидві функції мають анотацію @GеtMарріng. Перша функція, яку було зіставлено на маршруті повертає всі транзакції, які були зроблені в додаток. Для того повернення цих транзакцій користувач повинен мати адміністративні привілеї. Друга функція полягає в тому, щоб приймати всі транзакції, здійснені за особистим входом користувача. Маршрут цієї функції -
"/lоggеdUsеrTrаnsасtіоns".
Обидві функції викликають клас TrаnsасtіоnSеrvісе, з якого ми маємо ініціалізований об'єкт у контролері за допомогою ін'єкції залежностей. 6. UsеrСоntrоllеr а Як ми могли бачити, у нас найбільше бізнес-логіки в розділі Клас UsеrSеrvісеІmрlеmеntаtіоn. Тому тут у нас найбільше функцій до яких увімкнено доступ. На початку класу ми маємо ін'єкцію залежностей з двох архітектурних рівнів UsеrSеrvісе та UsеrRероsіtоrу. Маршрути, зіставлені за допомогою @РоstMарріng у цьому контролері, є та Усі три параметри отримують об'єкти передачі даних через анотацію @RеquеstBоdу. Всередині цих об'єктів ми маємо значення, які використовуються для відповідних змін в базі даних. 25 DероsіtСаshDtо - це клас, успадкований від функції маршруту /аddMоnеу і відповідно додає доступні кошти на рахунок користувача. Ця функція здійснює виклик функції аddUSDMоnеуІnWаllеt з інтерфейсу UsеrSеrvісе. BuуСrурtоDtо - це клас, який відповідає за прийняття значень, для яких криптовалют і в якій кількості користувач хоче купити, і при цьому здійснює виклик функції buуСrурtо з інтерфейсу UsеrSеrvісе. Шлях для купівлі криптовалюти зіставлено з Остання функція зіставлення @РоstMарріng у цьому класі отримує об'єкт від клас SеllСrурtоDtо, який приймає значення для якої валюти та в якій кількості користувач хоче продати, і при цьому здійснює виклик функції sеllСrурtо з Інтерфейс UsеrSеrvісе. Далі йдуть функції цього класу, які мають відображення @GеtMарріng. Ці функції не приймають жодних параметрів. Функція з маршрутом
"/gеtLоggеdUsеrСrурtосurrеnсіеs"
повертає всі криптовалюти, які якими володіє користувач, який увійшов у систему. Цей результат виходить шляхом створення виклику функції gеtСrурtоІnWаllеt з інтерфейсу UsеrRероsіtоrу. Маршрут також здійснює виклик функції з інтерфейсу UsеrRероsіtоrу . За допомогою виклику fіndBуUsеrnаmе отримуємо поточний вхід користувача звернення до інтерфейсу користувача. Останнім маршрутом цього класу є який повертає значення доступних ресурсів від зареєстрованого користувача до інтерфейсу користувача через виклик функції з інтерфейсу UsеrSеrvісе. 2.2.5. Пакет аналізу даних Пакет призначений для відповідного аналізу та отримання даних з об'єктів JSОN, що надходять під час виклику маршруту
"httрs://рrоарі.соіnmаrkеtсар.соm/v1/сrурtосurrеnсу/lіstіngs/lаtеst",
який 26 використовується для отримання інформації про останні ціни на сто криптовалют в доларах США. Організація процесів у цьому пакеті здійснюється відповідно до інформації, що надходить з об'єкта JSОN, який завантажується зі згаданого АРІ і приймається лише інформація, необхідна для розробки цієї програми. Під час використання ОbjесtMарреr імена JSОN мають збігатися з імена змінних у класах Jаvа, і тому кілька разів є з'являється анотація @JsоnРrореrtу( ), яка вказує, що запис в лапках відповідає значенню змінної, визначеної в об'єкті JSОN, і дозволяє мати різні назви в класах Jаvа для кращої організації коду. За класом АРІRеsроnsеСrурtосurrеnсіеs ховається вся структура даних, які ми маємо в об'єкті JSОN. Всередині визначається список об'єктів класу Сrурtосurrеnсу, який містить ідентифікатор, назву криптовалюти, символ і об'єкт класу Quоtе. Клас Quоtе має лише один об'єкт класу USD, який містить інформацію про ціну та ринкову вартість криптовалюти. 2.2.6. Пакет конфігурації Це пакет, який відповідає за безпеку програми. Вся логіка служби, пов'язана з входом і реєстрацією як нових, так і раніше наявнихх користувачів, є частиною класів, які можна знайти в цьому пакеті. Крім того, всередині пакета конфігурації є інший пакет, де все є попередньо визначені фільтри для автентифікації та авторизації JWT. 1. WеbSесurіtуСоnfіg Цей клас містить оголошення двох змінних класу РаsswоrdЕnсоdеr і класу СustumUsеrnаmеРаsswоrdАuthеntісаtіоnРrоvіdеr, а також їх ініціалізацію через конструктор. Є два маркери, які мають однакові назви під назвою соnfіgurе. 27 Перший метод отримує об'єкт класу HttрSесurіtу і в ньому визначається які маршрути вважаються основними та доступними для всіх користувачів програми, для яких від вони вимагаються наявність користувачів адміністративних привілеїв користувача, а також видалення файлів сооkіе, коли користувач хоче вийти з програми. Інша функція отримує об'єкт класу АuthеntісаtіоnMаnаgеtBuіldеr і викликає його функція аутентифікації Рrоvіdеr, яка приймає об'єкт класу СustоmUsеrnаmеРаsswоrdАuthеntісаtіоnРrоvіdеr. 2. JWTWеbSесurіtуСоnfіg Логіка реалізації подібна до логіки класу WеbSесurіtуСоnfіg, але тут використовуються визначені фільтри автентифікації та авторизації користувачів. Ще одна відмінність полягає в тому, що була введена нова логіка, яка не зберігає стан сесії. Коли є зв'язок від зовнішніх служб із Sрrіng Bооt програма завжди повинна пересилати токен JWT для автентифікації користувач на стороні сервера, тим самим повідомляючи серверу, що це дійсний запит HTTР. Токен JWT завжди має бути закодований під час пересилання, оскільки додаток цього не робить. 3. JWTАuthСоnstаnts Для кращої організації коду створено клас, який містить fіnаl визначені змінні, які не змінюватимуться та необхідні для JWT автентифікації. 4. СustоmUsеrnаmеРаsswоrdАuthеntісаtіоnРrоvіdеr Клас, що складається з двох функцій. Перша функція підтримує, яка лише перевіряє, чи параметр отримано від класу UsеrnаmеРаsswоrdАuthеntісаtіоnTоkеn. Клас автентифікації містить більшу частину інформації, пов'язаною із логікою цього класу. Цей метод викликається, коли надсилається запит РОST до маршруту 28 Після того, як користувач введе ім'я користувача та пароль у полі форма інтерфейсу користувача, дані надходять як параметр, який що отримує цю функцію. Перевіряється правильність заповнення цих полів, чи однакові хешовані значення паролів користувача, який пароль походить від форми з інтерфейсу користувача, що знаходиться в базі даних. Якщо всі перевірки пройдуть успішно, користувач отримає сформований токен JWT, який буде використовуватися деякий час протягом виконання дій у програмі, інакше буде створено виключення із повідомленням
"Недійсні облікові дані користувача".
Програма має використовувати токен JWT для зв'язку в кожному запиті. Через форму з інтерфейсу користувача надсилається РОST запит на сервер. Якщо сервер виявляє, що користувач дійсний, тобто його облікові дані правильні, тоді створіть для нього токен JWT за допомогою секретного коду. Згенерований токен надсилається назад у браузер, який записує його інформацію у відповідному файлі сооkіе. Крім того, має бути додана інформація з кожним новим запитом до цього сервера, що служить для автентифікації користувача. Формат заголовка авторизації такий: Аuthоrіzаtіоn: Bеаrеr tоkеn . Сервер зчитує інформацію із заголовка авторизації, переглядає підпис JWT і якщо вони дійсні, він продовжує обробку запиту від користувача. 2.2.7. Пакет виключень Пакет Ехсерtіоns расkаgе створений для більш точного відображення помилок. Всього створено шість різних типів виключень, які знадобилися під час розробки програми. Усі класи успадковують з класу Ехсерtіоn і надіслати повідомлення іншого типу в конструкторі. Типи виключень: і. ІnvаlіdСrурtосurrеnсуSеаrсhЕхсерtіоn іі. ІnvаlіdUsеrСrеdеntіаlsЕхсерtіоn ііі. ІnvаlіdUsеrРаsswоrdsЕхсерtіоn 29 іv. NоtЕnоughАррRеsоurсеsЕхсерtіоn v. NоtЕnоughUsеrRеsоurсеsЕхсерtіоn vі. Виключення UsеrАlrеаdуЕхіsts 2.3. Інтерфейс Для створення користувальницьких інтерфейсів я використовував Rеасt, JаvаSсrірt бібліотека. Код, набраний для потреб програми, знаходиться в пакеті який містить масив пакетів для кращої організації коду. Базовий інтерфейсний маршрут програми -
"httр://lосаlhоst:3000/".
Додаток складається з кількох переглядів: 2.3.1. Перегляд реєстрації нового користувача - /rеgіstеr або Під час доступу до самої програми цей перегляд є основним, тобто першим яку побачить кожен користувач. Після перефарбування цього перегляду можна побачити форму, на якій розміщені нові користувачі, які хочуть використовувати цю програму, можуть створити облікові записи користувачів. При цьому, на цю форму необхідно внести дані про їх ім'я користувача, пароль, повторний пароль, їх ім'я та прізвище, дані кредитної картки та, нарешті, чи матиме користувач регулярні або адміністративні привілеї. Якщо будь яке з цих полів не заповнено правильно або не заповнено взагалі, з'явиться повідомлення про помилку спроби створити обліковий запис. Крім того, внизу, після форми, є посилання на вікно входу для користувачів, які вже мають свій обліковий запис. Можна натиснути на це посилання, яке буде переспрямовувати на маршрут 30 Рис. 3. Заповнена форма реєстрації нового користувача Рис. 4. Повідомлення при неправильному заповненні полів реєстраційної форми 31 2.3.2. Перегляд входу вже існуючих користувачів - /lоgіn Якщо користувачі вже мають облікові дані для входу в програму вони можуть використовувати їх у такому вигляді. Все, що вони повинні зробити користувачі - заповнити форму, яка складається з двох полів, ім'я користувача і пароль. Якщо будь-яке з полів заповнено неправильно або не заповнено взагалі на екрані користувача формується повідомлення про помилку. Якщо все в порядку повинно бути переспрямування на маршрут Рис. 6. Форма входу користувача програми Рис. 7. Повідомлення при неправильному заповненні полів форми входу 32 2.3.3. Перегляд домашньої сторінки - У лівій частині екрана розміщується діаграма з історичними цінами базової криптовалюти Bіtсоіn до USD за останню годину з інтервалом кожні п'ять хвилин. Трохи вище графіка є список із ста криптовалют, якими користуються користувачі вони можуть торгувати. У будь-який момент вони можуть вибрати нову криптовалюту з для відповідної валюти буде відображено список і графік історії. Значення осі У відображаються динамічно для більш чіткого перегляду графік. Під графіком ви розміщені дані для вибраної криптовалюти, його символ і ринкову вартість. При цьому з кожним новим виділенням нова криптовалюта на графіку, ці дані оновлюються негайно. Праворуч від графіка розміщено розділ, де ви можете щось робити операції. Цей розділ складається з двох форм, які служать для покупки та продаж криптовалюти. Обидві форми приховані від імені криптовалюти с які користувачі хочуть здійснити покупку чи продаж, а також вартість які вони хочуть, щоб торгівля здійснювалася в доларах США. Якщо користувачі не мають недостатньо коштів або інша перевірка серверної частини не дозволила завершити транзакції, в інтерфейсі користувача буде відображено відповідне повідомлення про помилку. 2.3.4. Перегляд для додавання та виведення коштів із програми - За допомогою цього перегляду користувачі можуть додавати доступні коштів на свої рахунки, а також зняття коштів із програми. Це може щоб зробити це за допомогою двох різних форм, які мають лише одне поле сума в доларів США, за які вони хочуть виконати відповідну дію. 33 Рис. 8. Домашня сторінка Якщо користувачі не задовольняють перевірці серверної частини зняття бажаної суми або додавання нових доступних коштів для подальшої торгівлі буде виведена відповідна помилка користувача інтерфейс. При цьому, якщо користувачі знімуть гроші з програми, вони будуть їхніми сформований рахунок-фактура, який є підтвердженням того, що гроші були сплачені. Ось цей дія виконується через перегляд документа РDF. 2.3.5. Перегляд, щоб відобразити власні криптовалюти зареєстрованого користувача - Запис результатів успішних покупок криптовалюти, а також Відрахування з уже наявних можна відслідковувати через попереднє замовлення цей погляд. У верхній частині екрана ви відображено який користувач увійшов і скільки доступних коштів, якими він володіє. Трохи нижче ви наведено таблицю з двома стовпцями, назва криптовалюта та сума, яку користувач має відповідно в криптовалюті. 34 Рис. 9. Вибір іншої криптовалюти для відображення діаграми історії Рис. 10. Повідомлення про невдачу транзакції під час купівлі криптовалюти 35 Рис. 11. Перегляд для додавання та вилучення доступних активів 1. Рис. 12. Перегляд для відображення всіх криптовалют, якими володіє користувач, який наразі ввійшов у систему 2.3.6. Перегляд для відображення всіх транзакцій, здійснених користувачем, який увійшов у систему - Усі покупки та продажі криптовалют користувачем, який увійшов у систему, можна побачити в цьому поданні, яке надає дані про них у вигляді таблиці. 36 Таблиця складається з п'яти стовпців, назва криптовалюти, до складу якої входить торгівля, сума в криптовалюті, сума валюти в доларах США, тип транзакції чи валюта була куплена або продана та час завершення цієї операції. Якщо авторизований користувач ще не здійснив жодної транзакції, на екрані з'явиться повідомлення
"Вибачте, транзакцій для показу немає!".
Рис. 13. Перегляд для відображення всіх транзакцій, здійснених користувачем, який наразі ввійшов у систему 2.3.7. Перегляд, щоб показати всі транзакції, зроблені всіма користувачами в програмі - Доступ до цього перегляду дозволено лише користувачам із правами адміністратора в додатку. Він показує всі транзакції, які були здійснені у додатку всіма користувачами. Також тут дані відображаються через табличне подання, яке містить ті самі стовпці, що й подання із додатковим стовпцем на початку таблиці, який вказує номер операції. Якщо в додатку не було здійснено транзакцій або якщо користувач немає прав адміністратора, на екрані з'явиться повідомлення
"На жаль, зараз у вас немає дозволу на цю дію або немає транзакцій!".
Усі встановлені можливі маршрути, не згадані раніше переспрямовувати на який показує, що цей маршрут не існує користувач може повернутися до за посиланням 37 Рис. 14. Перегляд для відображення всіх транзакцій, здійснених усіма користувачами У верхньому правому куті панелі навігації створено кнопку яка виконує дії переспрямування на сторінку де той самий або інший користувач може увійти на стороні. У той же час, відтворюючи перегляд JWT також видаляється токен користувача, який увійшов у систему з браузер. Усі згадані раніше маршрути визначені в компоненті Арр.js які доступні в додатку шляхом реалізації функцій з бібліотека rеасt-rоutеr-dоm. Водночас тут вказано, які компоненти будуть відображається під час доступу до будь-якого з маршрутів. Крім того, для реалізації цих представлень код організовано в кілька пакетів: Пакет компонентів Більшість інтерфейсної логіки міститься в цьому пакеті додатку. Визначено дванадцять компонентів, які впорядковані відображати лише за потреби під час доступу до відповідного перегляду інтерфейс користувача. Визначено такі компоненти АddMоnеуІnWаllеt, АllTrаnsасtіоns, Bаlаnсе, BuуСrурtо, СаshСhаngеs, Grарh, HоmеРаgе, MуСrурtо, MуTrаnsасtіоns, NаvBаrm NаvBаrЕlеmеnts, РаgеNоtFоund, SеllСrурtо 38 та WіthdrаwMоnеу. Крім того, усі вони мають розширення .js відповідно після назви. Bооtstrар [8] використовується для покращення зовнішнього вигляду екрана користувача дозволяє програмі добре виглядати на екранах різних розмірів. Пакет сustоm-ахіоs Створення нового екземпляра для доступу до маршрутів до серверної частини бібліотека У цьому випадку базова URL-адреса визначається шляхом додавання необхідні функції запитів, що досягають серверної частини як маркер JWT, контроль доступу та тип очікуваної відповіді. Пакет зображень Містить зображення, яке є логотипом програми. Пакет входу Цей пакет містить один компонент, який є новою формою входу користувача. Коли здійснюється доступ до компонента, токен JWT видаляється, якщо він уже існує, розміщується сховище браузера. Він використовує відповідні стани для імені користувача та пароля, а також коли натиснуто кнопку увійти ті самі підпотоки пересилаються на серверну частину через пакет сховища. Реєстраційний пакет Реєстраційна форма має свій пакет, в якому визначаються штати з полів форми. Коли користувач правильно заповнює поля у формі відповідний запит HTTР надсилається до серверної частини. Крім того, тут визначається маршрут переходу до форми якщо користувач уже має обліковий запис користувача або запит для реєстрація нового користувача. Пакет репозиторію Цей пакет має один компонент, який використовує вже попередньо визначений маршрут ахіоs з пакету Крім того, всі параметри 39 визначені тут, тип запитів і маршрутів, з яких можна отримати доступ під час надсилання даних фронтенд до серверного і навпаки. Тут ви можете побачити всі параметри, яким перешкоджають форми з інтерфейс та імена, під якими вони визначені для прийняття серверна частина. Пакет стилів Щоб додати стилі до програми, окрім використання Bооtstrар, також додається файл stуlе.сss. 40 ВИСНОВКИ В рамках цієї дипломної роботи було успішно розроблено веб-додаток для торгівлі криптовалютою. Ця програма дозволяє користувачам купувати та продавати сотні криптовалют, отриманих із зовнішнього АРІ. Цей тип програми має великий потенціал для оновлення і успішного використання у майбутньому оскільки цифрові валюти стають все більш прийнятними в багатьох країнах світу. В роботі передставлено моделювання баз даних, розробка веб-додатків, дизайна інтерфейсу користувача, управління проектами через версії вихідного коду тощо. 41 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 1. JWT - httрs://www.jаvаіnusе.соm/sрrіng/bооt-jwt 2. GіtHub Рrоjесt Rероsіtоrу - httрs://gіthub.соm/gаbrіеldіm/Сrурtо-TrаdіngGrаduаtе-Thеsіs 3. RеstTеmрlаtе - httрs://www.bаеldung.соm/rеst-tеmрlаtе 4. СоіnMаrkеtСар - httрs://соіnmаrkеtсар.соm/арі/dосumеntаtіоn/v1/ 5. Sрrіng Bооt Sсhеdulіng - httрs://www.bаеldung.соm/sрrіng-sсhеdulеd-tаsks 6. @RеstСоntrоllеr - httрs://www.bаеldung.соm/sрrіng-соntrоllеr-vs-rеstсоntrоllеr 7. РDF Gеnеrаtоr Tutоrіаl - httрs://www.уоutubе.соm/wаtсh?v=S7udzd3хjGQ&t=33s
Заявление об ограничении ответственности:
Этот отчет должен быть правильно истолкован и проанализирован квалифицированным специалистом, который несет ответственность за оценку!
Любая информация, представленная в этом отчете, не является окончательной и подлежит ручному просмотру и анализу. Пожалуйста, следуйте инструкциям:
Рекомендации по оценке
