ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9086| Title: | Веб-застосунок «Географічний тренажер» |
| Authors: | Немченко, Вадим Вячеславович Лебеденко, Андрій Михайлович |
| Keywords: | ГЕОГРАФІЧНИЙ ТРЕНАЖЕР;ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ;REACT;NODE.JS;JAVASCRIPT;EXPRESS;БАЗА ДАНИХ;POSTGRESQL;ТЕСТИ;ЗМАГАННЯ;КОРИСТЬ;ГЕОГРАФІЯ |
| Issue Date: | 2025 |
| Abstract: | Виконавець: Лебеденко Андрій Михайлович. Назва роботи: "Веб-застосунок «Географічний тренажер»". Спеціальність: 121 Інженерія програмного забезпечення. Навчальний заклад: «Черкаський державний технологічний університет» м. Черкаси, 2025р. У бакалаврській роботі розглядається розробка веб-застосунок «Географічний тренажер». Основною метою розробки є створення сайту , який допомагатиме користувачам навчатися географії ефективно, вивчаючи прапори та столиці країн. У ході роботи було проведено детальний аналіз потреб цільової аудиторії, сформовано вимоги до географічного тренажера, виконано моделювання ключових функцій та реалізовано систему на основі Node.js з використанням мови програмування JavaScript на бекенді та React TS на фронтенді. Основні ідеї та результати досліджень включають: ‒ формування вимог: були визначені первинні та детальні вимоги до системи. Враховано потреби студентів і викладачів, розроблені функціональні та нефункціональні вимоги. Цей процес забезпечив чітке розуміння цілей і функцій, які повинні бути реалізовані; ‒ моделювання функціоналу: було створено концептуальну, логічну та фізичну моделі системи. Визначено основні функції бота, такі як відображення розкладу занять, нагадування про розклад, відслідковування його змін, можливість надсилати повідомлення обраній категорії студентів від викладачів; ‒ реалізація системи: було розроблено веб-застосунок «Географічний тренажер» на основі Node.js та React TS, що забезпечує його гнучкість і можливість масштабування. Використання мови програмування JavaScript дозволило ефективно реалізувати необхідний функціонал. Описана архітектура системи та використані технології. Висновки роботи показують, що створений веб-застосунок «Географічний тренажер» успішно задовольняє потреби людей будь-якого віку, покращуючи ефективність вивчення географії. Система відповідає вимогам користувачів та демонструє високу продуктивність і надійність у практичному використанні |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9086 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра 2025 - Лебеденко.pdf Restricted Access | 5.73 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«бакалавра»
на тему: Веб-застосунок «Географічний тренажер»
Виконав: студент 4 курсу, групи ПЗ-2104
Напряму підготовки
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Лебеденко А.М.
(прізвище та ініціали)
Керівник Немченко В.В .
(прізвище та ініціали)
Рецензент Пасько О.М.
(прізвище та ініціали)
Черкаси 2025
ЧДТУ. 252157 009 ПЗ
Черкаський державний технологічний університет
Факультет інформаційних технологій і систем _____________________________________
(повна назва)
Кафедра програмного забезпечення автоматизованих систем _________________________
(повна назва)
Напрям підготовки 121 ІНЖЕНЕРІЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ _______________________
(код, назва)
Спеціальність 121 «ІНЖЕНЕРІЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ» ________________________
(код, назва)
ЗАТВЕРДЖУЮ:
Зав. кафедри Голуб С.В.
“_____” __________2025р.
ЗАВДАННЯ
на кваліфікаційну роботу
“_____Бакалавра___”
(назва рівня)
студенту Лебеденко Андрій Михайлович
(прізвище, ім’я, по батькові)
1.Тема проекту (роботи) Веб-застосунок «Географічний тренажер»
затверджена наказом по університету від “25”02 2025р. №53/03-03
2. Термін здачі студентом закінченого проекту (роботи) “02”__06__2025р.
3. Вихідні дані до проекту (роботи); ______________________________________________
(визначаються кількісні або (та) якісні показники, яким повинен відповідати об’єкт
проектування наукового дослідження)
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити):
Вступ;
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань; __________________
Розділ 2. Впровадження результатів досліджень у практику проектування програмного
забезпечення інформаційних систем;
Розділ 3. Розробка та тестування програмного забезпечення;
Висновки; ____________________________________________________________________
Список використаних джерел;
Додатки; _____________________________________________________________________
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;
Слайд 1; Слайд 2; Слайд 3; Слайд 4; Слайд 5; Слайд 6; Слайд 7; Слайд 8; Слайд 9; Слайд 10;
Слайд 11; Слайд 12; Слайд 13; Слайд 14; Слайд 15; Слайд 16; Слайд 17; Слайд 18; Слайд 19;
Слайд 20; Слайд 21; Слайд 22; Слайд 23; Слайд 24.
6. Дата видачі завдання грудень 2024_____________________________________________
Прізвище, Підпис, дата
Назва розділ ініціали та посади Завдання Завдання
консультанта видав прийняв
2
ЧДТУ. 252157 009 ПЗ
Календарний план
Строк
№ Назва етапів випускної бакалаврської виконання
Примітка
з/п роботи етапів проекту
(роботи)
1 ПІДГОТОВЧА СТАДІЯ ВЕРЕСЕНЬ ВИКОНАНО
1.1 ПОСТАНОВКА ЗАДАЧІ ВЕРЕСЕНЬ ВИКОНАНО
1.2 ПІДГОТОВКА ЗАВДАННЯ ВЕРЕСЕНЬ ВИКОНАНО
1.3 ПОГОДЖЕННЯ ЗАВДАННЯ ЖОВТЕНЬ ВИКОНАНО
1.4 ЗАТВЕРДЖЕННЯ ЗАВДАННЯ ЖОВТЕНЬ ВИКОНАНО
2 ОСНОВНА СТАДІЯ ЖОВТЕНЬ ВИКОНАНО
2.1 ПІДБІР МАТЕРІАЛІВ ЛИСТОПАД ВИКОНАНО
2.2 АНАЛІЗ ШЛЯХІВ РІШЕННЯ ПОСТАВЛЕНОЇ ЗАДАЧІ ЛИСТОПАД ВИКОНАНО
2.3 ОФОРМЛЕННЯ ПЕРВІСНОЇ РЕДАКЦІЇ РОБОТИ СІЧЕНЬ ВИКОНАНО
3 ЗАКЛЮЧНА СТАДІЯ СІЧЕНЬ ВИКОНАНО
ОФОРМЛЕННЯ ПОЯСНЮВАЛЬНОЇ ЗАПИСКИ
3.1 РОБОТИ БЕРЕЗЕНЬ ВИКОНАНО
3.2 ЗАТВЕРДЖЕННЯ РОБОТИ ТРАВЕНЬ ВИКОНАНО
3.3 РЕЦЕНЗУВАННЯ РОБОТИ ТРАВЕНЬ ВИКОНАНО
Студент Лебеденко А.М. ____________________
(прізвище та ініціали) (підпис)
Керівник проєкту Немченко В.В. _____________________
(прізвище та ініціали) (підпис)
3
ЧДТУ. 252157 009 ПЗ
АНОТАЦІЇ
Виконавець: Лебеденко Андрій Михайлович.
Назва роботи: "Веб-застосунок «Географічний тренажер»".
Спеціальність: 121 Інженерія програмного забезпечення.
Навчальний заклад: «Черкаський державний технологічний університет» м.
Черкаси, 2025р.
У бакалаврській роботі розглядається розробка веб-застосунок
«Географічний тренажер». Основною метою розробки є створення сайту , який
допомагатиме користувачам навчатися географії ефективно, вивчаючи прапори та
столиці країн.
У ході роботи було проведено детальний аналіз потреб цільової аудиторії,
сформовано вимоги до географічного тренажера, виконано моделювання ключових
функцій та реалізовано систему на основі Node.js з використанням мови
програмування JavaScript на бекенді та React TS на фронтенді. Основні ідеї та
результати досліджень включають:
‒ формування вимог: були визначені первинні та детальні вимоги до
системи. Враховано потреби студентів і викладачів, розроблені функціональні та
нефункціональні вимоги. Цей процес забезпечив чітке розуміння цілей і функцій,
які повинні бути реалізовані;
‒ моделювання функціоналу: було створено концептуальну, логічну та
фізичну моделі системи. Визначено основні функції бота, такі як відображення
розкладу занять, нагадування про розклад, відслідковування його змін, можливість
надсилати повідомлення обраній категорії студентів від викладачів;
‒ реалізація системи: було розроблено веб-застосунок «Географічний
тренажер» на основі Node.js та React TS, що забезпечує його гнучкість і можливість
масштабування. Використання мови програмування JavaScript дозволило
ефективно реалізувати необхідний функціонал. Описана архітектура системи та
використані технології.
4
ЧДТУ. 252157 009 ПЗ
Висновки роботи показують, що створений веб-застосунок «Географічний
тренажер» успішно задовольняє потреби людей будь-якого віку, покращуючи
ефективність вивчення географії. Система відповідає вимогам користувачів та
демонструє високу продуктивність і надійність у практичному використанні.
Ключові слова. ГЕОГРАФІЧНИЙ ТРЕНАЖЕР, ПРОГРАМНЕ
ЗАБЕЗПЕЧЕННЯ, REACT, NODE.JS, JAVASCRIPT, EXPRESS, БАЗА ДАНИХ,
POSTGRESQL, ТЕСТИ, ЗМАГАННЯ, КОРИСТЬ, ГЕОГРАФІЯ
5
ЧДТУ. 252157 009 ПЗ
ANNOTATIONS
Performer: Lebedenko Andrii Mykhailovych.
Title of the work: “Web application “Geographic simulator””.
Specialty: 121 Software engineering.
Educational institution: “Cherkasy State Technological University”, Cherkasy.
Cherkasy, 2025.
The bachelor's thesis deals with the development of the web application
“Geographic Simulator”. The main goal of the development is to create a website that
will help users learn geography effectively by studying flags and capitals of countries.
In the course of the work, we conducted a detailed analysis of the needs of the
target audience, formed the requirements for the geographic simulator, modeled the key
functions, and implemented the system based on Node.js using the JavaScript
programming language on the backend and React TS on the frontend. The main ideas and
results of the research include:
− requirements generation: primary and detailed requirements for the system
were identified. The needs of students and teachers were taken into account, and
functional and non-functional requirements were developed. This process provided a
clear understanding of the goals and functions to be realized;
− functional modeling: conceptual, logical, and physical models of the system
were created. The main functions of the bot were defined, such as displaying the class
schedule, reminding about the schedule, tracking its changes, and the ability to send
messages to the selected category of students from teachers;
− implementation of the system: a web application “Geographic Simulator”
based on Node.js and React TS was developed, which ensures its flexibility and
scalability.
6
ЧДТУ. 252157 009 ПЗ
ЗМІСТ
Вступ............................................................................................................................................... 9
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ ЗАВДАНЬ16
1.1 Огляд платформ та фреймворків для розробки веб-сайту ......................................................... 16
1.2 Методи аналізу та оптимізації веб-сайтів.................................................................................... 17
1.3 Порівняльний аналіз існуючих аналогів...................................................................................... 18
1.4 Постановка задачі .......................................................................................................................... 20
Висновки до першого розділу .................................................................................................... 23
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ ПРОЕКТУВАННЯ
....................................................................................................................................................... 24
2.1 Моделювання предметної області ................................................................................................ 24
2.1.1 Предметна область моделювання. Модель предметної області. Словник предметної області
............................................................................................................................................................. 24
2.1.2 Елементи моделювання предметної області .......................................................................... 28
2.1.3 Робоча область моделювання .................................................................................................. 31
2.2 Формування та аналіз вимог ......................................................................................................... 34
2.2.1 Формування вимог до програмного забезпечення ................................................................ 35
2.2.2 Формування вимог за допомогою діаграми прецедентів ..................................................... 36
2.3 Проєктування логічної структури програмного комплексу ...................................................... 38
2.3.1 Діаграма класів ......................................................................................................................... 39
2.3.2 Діаграма пакетів ....................................................................................................................... 40
2.4 Архітектурне проектування .......................................................................................................... 41
2.4.1 Діаграма компонентів .............................................................................................................. 42
2.4.2 Діаграма розгортання ............................................................................................................... 42
2.5 Діаграма діяльності ........................................................................................................................ 44
2.6 Діаграма використання .................................................................................................................. 46
2.7 Діаграма клієнт-серверної архітектури........................................................................................ 46
ЧДТУ. 252157 009 ПЗ
Зм Лис № Підпис Дат
Розроб. документа№
. Веб-застосунок «Географічний Літ. Лист Листів
Керівни тренажер» Д 4
.
Н.контр. Пояснювальна записка ФІТІС, кафедра
ПЗАС,
Затв.
ПЗ-2104 7
ЧДТУ. 252157 009 ПЗ
2.8 Діаграма потоків даних (Data Flow Diagram, DFD) .................................................................... 48
2.9 ER-діаграма бази даних (Entity-Relationship Diagram, ERD) ..................................................... 50
2.10 Діаграма послідовностей ............................................................................................................. 52
2.11 Діаграма скінченного автомату .................................................................................................. 53
Висновки до другого розділу ..................................................................................................... 55
Розділ 3 Розробка та тестування програмного забезпечення .................................................. 56
3.1. Розробка програмного комплексу ............................................................................................... 56
3.1.1 Обґрунтування вибору засобів реалізації .............................................................................. 56
3.1.2 Опис структурної (функціональної) схеми ............................................................................ 70
3.1.3 Опис логічної схеми системи .................................................................................................. 72
3.1.4 Розробка бази даних ................................................................................................................. 74
3.1.5 Розробка інтерфейсу користувача .......................................................................................... 76
3.1.6 Опис розробки програмних компонентів............................................................................... 86
3.2 Тестування системи ..................................................................................................................... 107
3.2.1 Модульне тестування ............................................................................................................. 107
3.2.2 Інтеграційне тестування ........................................................................................................ 110
3.2.3 Системне тестування .............................................................................................................. 112
3.2.4 Приймальне тестування ......................................................................................................... 115
Висновки до третього розділу .................................................................................................. 116
Висновки .................................................................................................................................... 118
Список використаних джерел .................................................................................................. 121
Додаток А ................................................................................................................................... 122
Додаток Б ................................................................................................................................... 142
Додаток В ................................................................................................................................... 145
ЧДТУ. 252157 009 ПЗ
8
ЧДТУ. 252157 009 ПЗ
ВСТУП
Актуальність теми «Географічний тренажер» обумовлена зростаючою
потребою у сучасних інструментах для інтерактивного навчання географії, які
можуть ефективно допомагати користувачам будь-якого віку покращувати знання
з географії в зручній і доступній формі. В умовах стрімкого розвитку
інформаційних технологій та глобалізації освіти, традиційні методи вивчення
географії часто виявляються недостатньо ефективними, особливо для молоді, яка
звикла до інтерактивних ігрових форм навчання.
По-перше, сучасні учні та студенти стикаються з необхідністю швидко
опановувати великий обсяг інформації про країни, їх столиці, прапори та
географічні особливості. Застосування веб-додатка з інтерактивними
тренуваннями та тестами допомагає не лише підвищити мотивацію до навчання, а
й покращити запам’ятовування та закріплення знань.
По-друге, для освітніх закладів і викладачів актуальним є створення
ефективних онлайн-платформ, які дозволяють відстежувати прогрес учнів,
організовувати індивідуальні та групові заняття, а також збирати статистику
результатів для подальшого аналізу та оптимізації навчального процесу.
«Географічний тренажер» пропонує такі можливості, сприяючи підвищенню якості
освіти та персоналізації навчання.
По-третє, інтерактивні веб-додатки в галузі освіти сприяють формуванню
сучасної академічної спільноти, об’єднуючи користувачів із різних регіонів для
змагань, обміну досвідом і мотивації до подальшого розвитку. Можливість
змагатися, порівнювати результати та аналізувати свої помилки створює додаткові
стимули для поглибленого вивчення географії.
По-четверте, розвиток цифрових технологій в освітній сфері є важливим
чинником адаптації навчальних процесів до сучасних вимог ринку праці, де висока
географічна компетентність стає ключовою для роботи в міжнародних компаніях,
сфері туризму, логістики та інших галузях. Впровадження таких тренажерів
підвищує загальний рівень підготовки майбутніх фахівців.
9
ЧДТУ. 252157 009 ПЗ
Отже, розробка «Географічного тренажера» є актуальним завданням, яке
сприяє підвищенню ефективності навчання географії за допомогою інформаційних
технологій, стимулює інтерес до предмету та розвиває критичне мислення, що
відповідає сучасним освітнім стандартам та вимогам інформаційного суспільства.
Метою створення веб-додатку «Географічний тренажер» є розробка
інтерактивної платформи для покращення знань користувачів з географії через
ефективні інструменти навчання та перевірки знань. Додаток забезпечить доступ
до тестів, тренувань зі столиць, прапорів, та інших географічних даних, а також
дозволить відстежувати прогрес, змагатися з іншими користувачами і підвищувати
мотивацію до навчання.
Завдання розробки:
Аналіз вимог:
− визначити основні потреби цільової аудиторії – користувачів різного віку
і рівня знань у географії;
− зібрати та структурувати функціональні і нефункціональні вимоги до
додатку.
Огляд існуючих рішень:
− проаналізувати популярні географічні навчальні платформи та
тренажери;
− визначити їх сильні сторони та недоліки для покращення власного
продукту.
Проєктування архітектури системи:
− розробити концептуальну модель додатку з урахуванням модулів
тренувань, тестування, збереження даних;
− визначити структуру бази даних для збереження інформації про
користувачів та користувацькі результати;
− спроектувати інтерфейс користувача, що буде простим, інтуїтивним і
адаптивним.
Реалізація:
10
ЧДТУ. 252157 009 ПЗ
− впровадити основний функціонал – інтерфейс для тренувань і тестів,
систему реєстрації і авторизації;
− забезпечити можливість відображення статистики, порівняння
результатів і участі у змаганнях;
− провести тестування для виявлення і усунення помилок та покращення
зручності використання.
Інтеграція та впровадження:
− забезпечити сумісність додатку з популярними браузерами;
− підготувати інструкції і навчальні матеріали для користувачів.
Оцінка ефективності:
− провести аналіз результатів використання тренажера в освітньому
процесі;
− визначити вплив застосування додатку на рівень знань і мотивацію
користувачів;
− оцінити потенційні напрямки подальшого удосконалення і
масштабування проекту.
Об'єктом розробки є веб-застосунок «Географічний тренажер»,
призначений для інтерактивного навчання та перевірки знань з географії. Метою
створення цього застосунку є забезпечення зручного та ефективного інструменту
для вивчення столиць, прапорів, країн, а також проведення тренувальних тестів і
змагань між користувачами. Застосунок сприяє підвищенню мотивації,
покращенню засвоєння матеріалу та оптимізації навчального процесу для
користувачів різного віку і рівня знань.
Методи проектування
Для розробки веб-застосунку «Географічний тренажер» застосовано
комплекс методів, що забезпечують ефективність, зручність використання та
масштабованість системи:
Функціональний підхід
11
ЧДТУ. 252157 009 ПЗ
Використано функціональний підхід, який полягає у розділенні логіки на
чисті функції, що приймають вхідні дані і повертають результат без побічних
ефектів. Це підвищує надійність системи, спрощує тестування та налагодження.
Модульність
Код організовано у вигляді окремих модулів, кожен із яких відповідає за
певний функціональний блок – логіку тестування знань, управління
користувачами, відображення статистики, роботу з інтерфейсом тощо.
Модульність сприяє кращій організації коду, повторному використанню
компонентів і спрощує внесення змін.
Архітектура клієнт-сервер
Система побудована за архітектурою клієнт-сервер, де фронтенд на React.js
взаємодіє із серверною частиною, реалізованою на Node.js. Сервер обробляє
запити, керує базою даних та формує відповіді клієнту. Такий підхід забезпечує
централізоване управління логікою і даними, а також масштабованість і гнучкість
системи.
Моделювання за допомогою UML
Для візуалізації структури та поведінки системи використано:
− діаграми прецедентів для опису взаємодії користувачів із системою;
− класові діаграми для моделювання структури та зв’язків між
компонентами;
− діаграми послідовностей для відображення послідовності операцій у
сценаріях використання;
− діаграми станів - для моделювання змін станів об’єктів під час роботи
застосунку.
Використання шаблонів проектування
Застосовано такі шаблони проектування:
У процесі конструювання веб-застосунку «Географічний тренажер» були
застосовані такі принципи та практики, що сприяють підтримуваності,
масштабованості та ефективності коду:
Принципи SOLID
12
ЧДТУ. 252157 009 ПЗ
Дотримання принципів SOLID забезпечило гнучку та стабільну архітектуру
системи:
− S (Single Responsibility Principle) – кожен модуль або компонент має чітко
визначену зону відповідальності (наприклад, окремо логіка перевірки відповідей,
робота з API, обробка користувацьких сесій);
− O (Open/Closed Principle) – код легко розширюється новими функціями
(наприклад, додавання нових типів тренувань) без зміни існуючої логіки;
− L (Liskov Substitution Principle) – забезпечено коректну роботу з
інтерфейсами та абстракціями (наприклад, для компонентів UI або обробників
подій);
− I (Interface Segregation Principle) – інтерфейси або API компонентів не
перевантажені зайвими методами;
− D (Dependency Inversion Principle) – високорівневі модулі не залежать
напряму від низькорівневих, а взаємодіють через абстракції (наприклад, при роботі
з базою даних чи логікою гри).
Принцип DRY (Don’t Repeat Yourself)
Повторення коду мінімізовано за допомогою винесення спільної логіки в
окремі функції, хелпери та утиліти (наприклад, функція перевірки правильної
відповіді, обробка результатів, форматування тексту тощо).
Принцип KISS (Keep It Simple, Stupid)
Рішення реалізовані максимально просто й очевидно, без зайвої складності,
що полегшує читання, тестування та підтримку коду.
Компонентний підхід
Інтерфейс побудований за компонентною моделлю (React), де кожен
компонент відповідає за окремий фрагмент UI (наприклад, компонент для вибору
прапора, відображення статистики, інтерфейс тестування).
Система управління станом
Для забезпечення узгодженості даних у застосунку використано Redux, що
дозволяє централізовано зберігати та оновлювати стан (результати тренувань,
обрані режими, налаштування користувача тощо).
13
ЧДТУ. 252157 009 ПЗ
Розробка користувацького інтерфейсу. Проектування зручного та
інтуїтивного інтерфейсу на React.js для користувачів різного рівня знань.
Розробка серверної частини
Створення серверного додатку на Node.js для обробки запитів, управління
базою даних PostgreSQL, авторизації користувачів та логіки тестування.
Інтеграція з базою даних
Розробка структури бази даних для зберігання інформації про країни,
столиці, прапори, результати тестів та профілі користувачів.
Реалізація функціональності
Програмування ключових функцій: проведення тестів, відображення
результатів, збереження прогресу, формування таблиці лідерів.
Тестування та відлагодження
Перевірка роботи застосунку в різних сценаріях, виявлення та усунення
помилок, покращення користувацького досвіду.
Опис отриманих результатів
У результаті виконання бакалаврської роботи були досягнуті наступні
результати:
Аналіз потреб користувачів
Проведено детальний аналіз цільової аудиторії – користувачів різного віку та
рівня знань, сформовано функціональні та нефункціональні вимоги.
Формування вимог
Визначено основні функції: інтерактивні тести, таблиця лідерів, особистий
кабінет, статистика результатів.
Моделювання системи
Створено концептуальні, логічні та фізичні моделі, які описують структуру
та поведінку застосунку.
Реалізація системи
Розроблено повнофункціональний веб-застосунок на React.js (TypeScript) із
серверною частиною на Node.js, реалізовано всі функції відповідно до вимог.
Оцінка та тестування
14
ЧДТУ. 252157 009 ПЗ
Проведено комплексне тестування, що підтвердило стабільність і
ефективність роботи системи, її користь для навчального процесу.
Практичне значення отриманих результатів та рекомендації
Розроблений «Географічний тренажер» повністю задовольняє потреби
цільової аудиторії, демонструє високу продуктивність і зручність у використанні.
Рекомендовано подальше розширення функціоналу (наприклад, додавання нових
тем та режимів тренування) і регулярну підтримку системи.
Практичне значення отриманих результатів
Покращення навчального процесу
Застосунок підвищує мотивацію та ефективність вивчення географії,
забезпечує інтерактивну перевірку знань і розвиток пам’яті.
Готовність до впровадження
Проєкт є готовим до впровадження в навчальний процес закладів освіти,
підтверджений успішним тестуванням.
Масштабність використання
Система може бути адаптована для різних вікових категорій, навчальних
програм та інших предметів.
Рекомендації щодо подальшого розвитку
Рекомендується регулярне оновлення бази даних, розширення функціоналу,
а також проведення навчальних заходів для користувачів.
Особистий внесок автора
Автор бакалаврської роботи провів глибокий аналіз вимог та потреб
користувачів, самостійно розробив концептуальну, логічну та фізичну моделі
системи, реалізував клієнтську частину на React.js з TypeScript та серверну частину
на Node.js, забезпечив інтеграцію з PostgreSQL, оптимізував роботу застосунку,
виконав комплексне тестування і відлагодження, забезпечив стабільну роботу
системи в реальних умовах.
15
ЧДТУ. 252157 009 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1 Огляд платформ та фреймворків для розробки веб-сайту
Розробка веб-додатка "Географічний тренажер" здійснюється на основі
сучасної клієнт-серверної архітектури. Для її реалізації були обрані наступні
платформи та фреймворки:
1. React.js - JavaScript-бібліотека для створення інтерфейсів користувача.
Основні переваги:
− компонентний підхід, що дозволяє повторно використовувати код;
− висока продуктивність завдяки віртуальному DOM;
− активна спільнота розробників і великий набір додаткових бібліотек.
2. Tailwind CSS - CSS-фреймворк для швидкої та адаптивної розробки
інтерфейсів. Його переваги:
− зручність у використанні завдяки утилітарним класам;
− мінімізація написання власного CSS-коду;
− можливість створення унікального дизайну без потреби в готових
шаблонах.
3. Node.js та Express.js - платформа для серверного програмування та
фреймворк для побудови серверів. Основні переваги:
− асинхронність, що дозволяє обробляти велику кількість запитів;
− легкість у налаштуванні API;
− широкі можливості для інтеграції з базами даних.
4. PostgreSQL - реляційна база даних, яка забезпечує стабільність, безпеку та
швидкість. Її функціонал дозволяє працювати з великим обсягом даних,
необхідних для збереження інформації про користувачів, результати
тестувань і статистику.
5. Figma - інструмент для створення UX/UI-дизайну. Дозволяє працювати над
дизайном інтерфейсу з урахуванням зручності використання, адаптивності та
сучасних трендів.
16
ЧДТУ. 252157 009 ПЗ
Вибір цих інструментів базується на їхній популярності, продуктивності,
зручності у використанні та відповідності потребам проекту.
1.2 Методи аналізу та оптимізації веб-сайтів
Аналіз та оптимізація веб-сайтів є ключовими етапами в процесі їх
оновлення, що спрямовані на забезпечення ефективності, зручності використання
та відповідності сучасним вимогам. У цьому підрозділі розглядаються основні
методи, які дозволяють оцінити якість веб-сайту та покращити його
функціональність і продуктивність.
Аналіз ефективності веб-сайту. Для аналізу ефективності веб-сайтів
використовуються такі інструменти, як Google Analytics та Hotjar. Вони дозволяють
оцінити поведінку користувачів, зокрема тривалість перебування на сайті, кількість
переглянутих сторінок, показник відмов і географічну інформацію про
відвідувачів. Ці дані допомагають виявити слабкі сторони сайту, такі як нецікаві
сторінки або складна структура навігації, та прийняти рішення щодо їх оптимізації.
Аналіз зручності користування (UI/UX). Зручність використання відіграє
важливу роль у залученні й утриманні користувачів. Методи оцінки UI/UX
включають юзабіліті-тестування за допомогою групи користувачів, які
перевіряють, наскільки просто виконувати ключові завдання на сайті. Крім того,
аналіз доступності інтерфейсу забезпечує відповідність веб-сайту стандартам
WCAG, що особливо важливо для розширення аудиторії.
Аналіз швидкості завантаження. Швидкість завантаження є одним із
найважливіших показників якості веб-сайту, адже повільний сайт негативно
впливає на користувацький досвід і рейтинг у пошукових системах. Інструменти,
як-от PageSpeed Insights та Lighthouse, дозволяють виміряти швидкість
завантаження сторінок і надати рекомендації щодо її покращення. Серед типових
рекомендацій – оптимізація розмірів зображень, використання кешування
браузера, мінімізація коду CSS, HTML та JavaScript.
SWOT-аналіз веб-сайту. SWOT-аналіз допомагає визначити сильні та слабкі
сторони сайту, а також можливості й загрози зовнішнього середовища. Наприклад,
17
ЧДТУ. 252157 009 ПЗ
до сильних сторін можна віднести зручний інтерфейс і сучасний дизайн, а до загроз
– високий рівень конкуренції у веб-просторі. Цей метод дозволяє виявити напрями,
які потребують вдосконалення, і спланувати подальші дії.
Використання цих методів аналізу дозволяє комплексно оцінити стан веб-
сайту, виявити проблемні аспекти та забезпечити їх усунення. Завдяки цьому
можна досягти оптимального рівня ефективності, зручності користування та
адаптивності веб-застосунка, що сприятиме покращенню навчання.
1.3 Порівняльний аналіз існуючих аналогів
1. GeoGuessr
Формат: інтерактивна гра, в якій користувачеві пропонується вгадати місце на
карті на основі наданих зображень і підказок.
Переваги:
− унікальний гейміфікований підхід: гра побудована у форматі пригоди,
що робить процес навчання цікавим і захоплюючим;
− реалістичні зображення: використання реальних панорам із Google
Street View занурює користувачів у віртуальні подорожі;
− підтримка багатьох мов: дозволяє користувачам з різних країн
комфортно використовувати платформу;
− соціальна складова: можливість змагатися з друзями або іншими
користувачами у режимі реального часу.
Недоліки:
− відсутність персоналізованого аналізу прогресу: платформа не
відображає детальну статистику навчання, не фіксує помилки або прогрес
користувача;
− обмежені функції навчання: акцент на гейміфікації може знижувати
ефективність навчання для тих, хто хоче детально вивчити теорію;
− платність: доступ до більшості функцій є платним, що може обмежувати
використання.
2. Seterra
18
ЧДТУ. 252157 009 ПЗ
Формат: платформа, яка пропонує інтерактивні карти, тести та вікторини для
вивчення географії.
Переваги:
− широкий вибір навчальних матеріалів: користувачам доступні карти,
столиці, регіони, прапори, географічні об’єкти;
− різноманітність режимів навчання: передбачено як тренувальні
режими, так і тести для перевірки знань;
− доступність: є як веб-версія, так і мобільні додатки, що дозволяє
користувачам навчатися в будь-якому місці;
− підходить для різного рівня знань: матеріали адаптовані для
початківців і просунутих користувачів.
Недоліки:
− обмежена інтерактивна взаємодія: платформа не передбачає змагань
між користувачами або спільнот для обміну результатами;
− відсутність особистого кабінету: користувачі не можуть зберігати свій
прогрес або переглядати історію виконаних тестів;
− застарілий інтерфейс: у порівнянні з сучасними додатками, дизайн
виглядає менш привабливим і може бути незручним для молодших користувачів.
3. World Geography Games
Формат: веб-ресурс із набором міні-ігор для вивчення географічних об’єктів,
таких як столиці, прапори, регіони тощо.
Переваги:
− доступність: платформа безкоштовна та не вимагає реєстрації, що
дозволяє швидко розпочати навчання;
− простота використання: інтуїтивно зрозумілий інтерфейс, який
підходить для всіх вікових категорій;
− різноманітність ігор: широкий вибір інтерактивних завдань, які
охоплюють різні аспекти географії (столиці, прапори, річки тощо).
Недоліки:
19
ЧДТУ. 252157 009 ПЗ
− відсутність функцій персоналізації: платформа не дозволяє зберігати
прогрес або відстежувати результати навчання;
− обмежена гейміфікація: відсутні змагання з іншими користувачами або
соціальні функції, що можуть зробити процес навчання менш цікавим;
− низький рівень інтерактивності: платформа більше орієнтована на
прості навчальні завдання, ніж на інтерактивні модулі чи змагання.
Переваги «Географічного тренажера»
Відносно цих аналогів, веб-додаток "Географічний тренажер" має такі переваги:
Особистий кабінет: кожен користувач може зберігати свій прогрес,
переглядати статистику та аналізувати результати.
Модуль статистики: система показує сильні й слабкі сторони
користувача, допомагаючи визначити теми, які потребують додаткового
опрацювання.
Таблиця лідерів: користувачі можуть змагатися з іншими, що стимулює
мотивацію до навчання.
Сучасний UX/UI: дизайн, створений у Figma, забезпечує зручність і
привабливість інтерфейсу.
Ці переваги забезпечують "Географічному тренажеру" конкурентну
перевагу, об’єднуючи ефективне навчання та гейміфікацію.
1.4 Постановка задачі
На основі аналізу існуючих веб-платформ і фреймворків для створення
навчальних застосунків, визначення методів оцінювання знань користувачів, а
також дослідження наявних аналогічних рішень із порівнянням їх
функціональності, були виявлені їхні переваги та недоліки. Це дало змогу
сформулювати перелік завдань, необхідних для досягнення поставленої мети, та
зробити відповідні висновки щодо напрямів реалізації.
Розробка веб-застосунку "Географічний тренажер" потребує вирішення
комплексу завдань, серед яких: аналіз потреб цільової аудиторії, визначення
20
ЧДТУ. 252157 009 ПЗ
функціональних і нефункціональних вимог, вибір технологічного стеку, реалізація
клієнтської та серверної частин, а також тестування працездатності системи.
Розробка модулів тестування
Модулі тестування є центральним елементом функціоналу, який забезпечує
користувачам можливість ефективного навчання.
Тести для вивчення столиць і прапорів країн:
Містять завдання, які допомагають закріпити знання користувачів. Для
столиць передбачено завдання на відповідність столиці до країни, а для прапорів –
визначення країни за прапором.
Система підказок і повторів:
− повторення пройдених тестів для закріплення матеріалу. Це особливо
корисно для користувачів із різним рівнем знань.
Система збереження прогресу
Ця система надає користувачам можливість відстежувати свої досягнення.
Збереження результатів у базі даних:
− усі результати тестів автоматично фіксуються в базі даних. Це дозволяє
користувачам зберігати прогрес навіть після виходу з системи;
− інформація включає успішно завершені тести, відсоток правильних
відповідей та час виконання.
таблиця лідерів
Система рейтингу додає елемент мотивації для користувачів через змагання.
Мотивація через змагання:
− користувачі можуть бачити свої результати у порівнянні з іншими;
− таблиця лідерів стимулює користувачів покращувати свої знання, щоб
піднятися вище в рейтингу.
Оновлення в реальному часі:
− результати користувачів автоматично оновлюються після завершення
тесту.
Аналіз результатів.
Модуль статистики є важливим інструментом для самонавчання та вдосконалення.
21
ЧДТУ. 252157 009 ПЗ
Сильні й слабкі сторони:
− інструмент допомагає виявляти прогалини у знаннях і вибирати напрямок
для подальшого навчання.
Графічне відображення:
− використання графіків (наприклад, кругових діаграм або гістограм) для
візуалізації результатів;
− це робить аналіз зрозумілим навіть для користувачів без технічного
бекграунду.
5. Авторизація
Система входу до додатка забезпечує безпеку та зручність для користувачів.
Простий процес входу:
− реєстрація за допомогою email.
Ці завдання забезпечують не лише навчання, а й підтримують інтерес
користувачів через інтерактивність, зручність та персоналізований підхід.
22
ЧДТУ. 252157 009 ПЗ
ВИСНОВКИ ДО ПЕРШОГО РОЗДІЛУ
У першому розділі було проведено аналіз сучасних методів та інструментів,
які застосовуються для розробки веб-застосунків освітнього спрямування. На
основі аналізу технологій було обґрунтовано вибір ефективного стеку, що включає:
React.js для створення інтерфейсу користувача, Tailwind CSS для швидкої
адаптивної верстки, Node.js з Express.js для реалізації серверної логіки, PostgreSQL
для організації надійного зберігання даних та Figma для створення сучасного
дизайну.
Проведений аналіз платформ-аналогів, таких як GeoGuessr, Seterra та World
Geography Games, дозволив визначити їхні сильні та слабкі сторони. Це дало змогу
виокремити унікальні переваги розроблюваного додатка «Географічний
тренажер», серед яких: персоналізація, збереження прогресу, аналітика результатів
та змагальність.
Також у розділі описано ключові методи аналізу та оптимізації веб-додатків,
які забезпечують ефективність, зручність та відповідність сучасним вимогам: від
аналізу UI/UX і швидкості завантаження до проведення SWOT-аналізу.
Постановка задачі, що завершила розділ, визначає чіткий набір
функціональних модулів, які мають бути реалізовані для досягнення мети проєкту.
Таким чином, підґрунтя для технічної реалізації веб-застосунку повністю
сформоване, що створює логічний перехід до наступного етапу – проєктування
системи.
23
ЧДТУ. 252157 009 ПЗ
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ
2.1 Моделювання предметної області
Моделювання предметної області є ключовим етапом у розробці веб-
застосунку, оскільки воно дозволяє сформувати абстрактне уявлення про систему,
що сприяє визначенню основних функціональних компонентів та їх взаємодії. У
контексті створення "Географічного тренажера" моделювання забезпечує чітке
розуміння внутрішньої структури застосунку та логіки його роботи.
Цей процес включає побудову концептуальної, логічної та фізичної моделей,
що дає змогу виявити критично важливі елементи системи, оптимізувати її
архітектуру та забезпечити можливість інтеграції з іншими інформаційними
ресурсами за потреби. Такий підхід дозволяє знизити ризики проєктних помилок і
підвищити ефективність розробки та впровадження веб-застосунку.
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області
Предметна область моделювання
Моделювання предметної області для веб-застосунку «Географічний
тренажер» включає всі аспекти діяльності, що підлягають автоматизації, з метою
забезпечення ефективного вивчення географії, самоперевірки знань та підвищення
мотивації користувачів до навчання через ігрові та змагальні елементи. Основні
компоненти предметної області для даного застосунку включають:
− реєстрація користувачів: процес, що передбачає введення таких даних,
як ім’я користувача, електронна пошта, пароль (із подальшим хешуванням),
псевдонім. Це забезпечує створення унікального профілю користувача, завдяки
якому система може зберігати індивідуальні результати, статистику та рейтинг;
− режими навчання та тестування: функціональність, яка дозволяє
користувачам обирати один із тематичних напрямків (вивчення столиць,
24
ЧДТУ. 252157 009 ПЗ
прапорів),а також проходити тестувальних сесії з можливістю перевірки відповідей
та отримання пояснень. Це сприяє кращому засвоєнню матеріалу;
− змагальний режим: дозволяє користувачам брати участь у змаганнях на
кількість правильних відповідей, формує елемент суперництва та підвищує
зацікавленість у регулярному використанні тренажера;
− перегляд статистики та результатів: функція, яка надає користувачам
доступ до власної навчальної статистики (кількість правильних відповідей,
середній час тестування тощо), що дозволяє самостійно оцінювати рівень знань і
ставити навчальні цілі;
− таблиця лідерів: інструмент, який ранжує користувачів за результатами
тестувань і змагань, відображаючи прізвища/нікнейми, правильні відповіді,
покращення. Це мотивує користувачів до активної участі в навчальному процесі та
дозволяє порівнювати свої результати з іншими;
− інтерфейс користувача: веб-інтерфейс, що забезпечує інтуїтивну
навігацію між модулями, швидкий доступ до вибраного контенту, зручне
проходження тестів, перегляд результатів та спілкування з системою.
Моделювання предметної області дозволяє створити чітке уявлення про
структуру та функціональність веб-застосунку «Географічний тренажер»,
визначити ключові елементи системи та їх взаємозв’язки. Це допомагає
забезпечити ефективний процес проєктування, розробки та впровадження
застосунку, мінімізувати ризики помилок і забезпечити відповідність системи
освітнім потребам користувачів різного віку.
Модель предметної області
Моделювання предметної області є одним з найважливіших етапів
проєктування веб-застосунку «Географічний тренажер», оскільки воно дозволяє
сформувати цілісне уявлення про структуру системи, її основні компоненти та
взаємозв’язки між ними. Такий підхід забезпечує ефективну розробку програмного
забезпечення відповідно до вимог користувачів.
Метою веб-застосунку є створення інтерактивного середовища для вивчення
географії - зокрема столиць, прапорів, форм правління та розташування країн на
25
ЧДТУ. 252157 009 ПЗ
карті. Цільова аудиторія охоплює широке коло користувачів: від школярів до
дорослих, які прагнуть удосконалити свої знання з географії.
У результаті аналізу функціональних вимог до системи було виділено такі
основні аспекти предметної області:
Користувачі
Застосунок передбачає два основних типи користувачів:
− Гості (неавторизовані користувачі), які мають доступ до базового
функціоналу: перегляд прапорів та столиць, тестування без збереження статистики;
− Зареєстровані користувачі, яким доступні додаткові функції, зокрема:
− збереження статистики проходження тестів;
− персональний кабінет;
− участь у змаганнях та перегляд таблиці лідерів.
Для кожного зареєстрованого користувача зберігається:
− логін (електронна адреса або нікнейм);
− хешований пароль;
− ім’я або псевдонім;
− результат проходження тестів;
− позиція у рейтингу.
2. Тематичні модулі
Система поділяється на кілька окремих тренажерів:
− столиці країн світу - визначення столиці за назвою країни;
− прапори країн - візуальне розпізнавання прапора;
Кожен модуль містить власну локальну базу даних запитань, яка може
оновлюватися або доповнюватися. Запитання генеруються динамічно.
3. Тестування та таблиця лідерів
Застосунок реалізує функцію тестування, у межах якої користувач може
проходити набір завдань. За результатами тестування обчислюється рейтинг у
таблиці лідерів.
У таблиці лідерів зберігається:
− ім’я користувача;
26
ЧДТУ. 252157 009 ПЗ
− кількість правильних відповідей;
− загальна кількість ігор;
− Нещодавний прогрес у тестуванні.
Ця інформація дозволяє створити здорову конкуренцію серед користувачів і
мотивує їх до вдосконалення знань.
4. Статистика та аналітика
Кожен зареєстрований користувач має доступ до персональної статистики:
− дата реєстрації;
− нещодавний прогрес в тестуваннях;
− загальна кількість ігор;
− місце у таблиці лідерів;
− успішність за темами;
− кількість правильних відповідей;
− кількість неправильних відповідей;
− середня тривалість проходження тестування.
Цей функціонал сприяє самоаналізу й дозволяє сконцентрувати увагу на
слабких місцях у знаннях.
Схема предметної області
Узагальнено модель предметної області можна представити як взаємодію
таких основних сутностей:
Користувачі
− зареєстровані
− неавторизовані
Тренажери
− модуль запитань
− генератор відповідей
− перевірка результатів
Результати
− статистика
− рейтинг
27
ЧДТУ. 252157 009 ПЗ
− збереження прогресу
Інтерфейс
− особистий кабінет;
− таблиця лідерів;
− вибір режиму гри;
− вивчення прапорів та столиць.
Моделювання предметної області веб-застосунку «Географічний тренажер»
дало змогу сформувати структурований опис функціоналу системи, визначити її
логічні компоненти та взаємозв’язки. Це стало основою для побудови архітектури,
розробки бази даних, інтерфейсу та реалізації програмної логіки. Завдяки чітко
спроєктованій предметній області забезпечується масштабованість, підтримка та
можливість подальшого розвитку застосунку.
Словник предметної області
Таблиця 2.1
Словник предметної області
Термін Опис
Гість Неавторизованаа особа, яка має базовий функціонал.
Користувач Авторизована особа, яка проходить тести у веб-додатку
Тест Набір питань на знання столиць або прапорів
Питання Один елемент тесту, має варіанти відповідей
Відповідь Варіант відповіді на запитання
Результат Інформація про правильні/неправильні відповіді
користувача
Прогрес Дані про результати навчання користувача
Таблиця лідерів Рейтинг користувачів за результатами тестування
2.1.2 Елементи моделювання предметної області
У процесі моделювання предметної області для веб-застосунку
«Географічний тренажер» будуть використовуватись різні елементи UML (Unified
Modeling Language), які допомагають наочно представити структуру, логіку та
28
ЧДТУ. 252157 009 ПЗ
функціональність майбутньої системи. UML є стандартним засобом для
візуалізації, специфікації, конструювання та документування програмного
забезпечення.
Основні елементи UML, які будуть застосовуватись у межах проєкту:
− класи – відображають логічні одиниці системи, зокрема користувача,
сесію тестування, питання, результат, статистику;
− атрибути – характеристики класів, наприклад: ім’я користувача, email,
тип запитання, правильна відповідь, кількість балів;
− операції (методи) – дії, які можуть виконуватись об’єктами, наприклад:
авторизація, запуск тесту, перевірка відповіді, обчислення результату;
− асоціації – логічні зв’язки між класами, наприклад: один користувач
може проходити багато тестів, один тест містить багато питань;
− діаграми класів – основний інструмент представлення структури
системи, що показує класи, атрибути, методи та зв’язки між ними.
29
ЧДТУ. 252157 009 ПЗ
Рисунок 2.1 – Основні графічні символи UML
Для моделювання предметної області веб-застосунку «Географічний
тренажер» буде використано діаграми класів UML, які надають розробникам чітке
уявлення про структуру даних та взаємодію об’єктів у системі. Також можлива
побудова додаткових діаграм, таких як:
− діаграми випадків використання (Use Case Diagram) – для опису взаємодії
користувача з системою;
− діаграми послідовностей (Sequence Diagram) – для моделювання взаємодії
між об’єктами у часі.
30
ЧДТУ. 252157 009 ПЗ
Рисунок 2.2 – Єднальні елементи UML
Застосування UML у процесі моделювання веб-застосунку «Географічний
тренажер» дозволяє сформувати логічну, зрозумілу та наочну структуру системи,
що значно полегшує процеси аналізу, проєктування, розробки та подальшого
супроводу. Крім того, UML діаграми сприяють ефективній комунікації між
розробниками, користувачами та іншими зацікавленими сторонами проєкту.
2.1.3 Робоча область моделювання
Моделювання здійснювалося з використанням UML-нотації, у середовищі
Figma (для прототипів), dbdiagram.io (для ER-діаграм) та draw.io для побудови
DFD, діаграм послідовності та класів. Основною робочою платформою став
редактор Visual Studio Code.
31
ЧДТУ. 252157 009 ПЗ
Рисунок 2.3 – Модель предметної області
Основні компоненти
Користувачі (Users):
− гість (Guest);
− зареєстрований користувач (User).
Тестування (Test):
− прапори/столиці (Flags/capitals)
Вивчення (Learning)
− прапори/столиці (Flags/capitals)
таблиця лідерів
результати в профілі
32
ЧДТУ. 252157 009 ПЗ
Для створення дизайну використовується популярний інструмент Figma,
який забезпечує:
− інтерактивне прототипування;
− спільну роботу над проєктом (за необхідності);
− зручний інтерфейс для створення UX/UI-дизайну;
− інтеграцію з розробницькими інструментами через плагіни (наприклад,
експортування CSS стилів).
Прототипування в Figma
Розробка дизайну включала створення:
Прототипів основних екранів:
− головна сторінка;
− сторінка тестування знань (питання та варіанти відповідей);
− результати тестування з аналізом статистики;
− особистий кабінет користувача;
− таблиця лідерів.
Дизайну з акцентом на UX: Усі елементи навігації спроєктовані так, щоб
користувач легко знаходив потрібний функціонал. Наприклад:
− меню навігації у хедері;
− чітка візуальна структура тестів;
− підказки для користувача в особистому кабінеті.
UX/UI-особливості
Колірна палітра та стиль:
Використовувати слід сучасний мінімалістичний підхід. Основні кольори
- білий та зелений, які асоціюються з природою та навчанням. Додаткові акценти
створено за допомогою контрастних відтінків для виділення важливих елементів.
Простота навігації:
− хедер із логотипом, основними розділами та кнопкою авторизації;
− логічно структуровані блоки інформації на кожній сторінці.
Дизайн у Figma допомагає не лише створити візуально привабливий продукт,
але й забезпечити зручність використання для різних категорій користувачів.
33
ЧДТУ. 252157 009 ПЗ
Розширення для Visual Studio Code
Для підвищення продуктивності та покращення якості коду під час розробки
вебзастосунку було використано низку розширень для середовища Visual Studio
Code. Серед найважливіших - Auto Import та Prettier - Code Formatter.
Auto Import
Розширення Auto Import автоматизує процес додавання імпортів у файли
JavaScript та TypeScript. Під час написання коду плагін автоматично підказує, які
модулі або функції доступні для імпорту, й одразу додає відповідний рядок import
у верхній частині файлу.
Це значно спрощує роботу з великими проєктами, де багато компонентів і
утиліт розміщено в окремих модулях. Auto Import також зменшує ймовірність
помилок, пов’язаних із неправильними шляхами або дублюванням імпортів.
Наприклад, при використанні функції useState із React, плагін автоматично
додасть рядок import { useState } from 'react';.
Prettier – Code Formatter
Prettier
Це розширення для автоматичного форматування коду відповідно до єдиних
стилістичних правил. Після встановлення та налаштування, Prettier забезпечує
однаковий стиль коду по всьому проєкту: правильні відступи, лапки, дужки,
порядок елементів тощо.
Плагін може працювати автоматично при збереженні файлу або вручну за
командою. Це дозволяє зосередитися на логіці коду, а не на його оформленні, а
також полегшує читання та супровід проєкту іншими розробниками.
Prettier особливо корисний у командній роботі та при використанні систем
контролю версій (наприклад, Git), оскільки мінімізує конфлікти, пов’язані з
форматуванням.
2.2 Формування та аналіз вимог
Формування та аналіз вимог містить опис процесу виявлення та
систематизації функціональних і нефункціональних вимог до веб-застосунку
34
ЧДТУ. 252157 009 ПЗ
«Географічний тренажер». На цьому етапі було визначено основні потреби
користувачів, зокрема можливість проходження інтерактивних тестів на знання
столиць, прапорів і географічного розташування країн, перегляд статистики,
збереження результатів, а також забезпечення авторизації, персоналізації досвіду
та участі в рейтинговій системі. Окрема увага приділялася нефункціональним
вимогам, які стосуються зручності інтерфейсу, адаптивності, безпеки, швидкодії та
масштабованості системи. Формування вимог базувалося на аналізі потреб цільової
аудиторії та врахуванні сучасних підходів до розробки освітніх веб-застосунків, що
дозволило створити чітке технічне бачення проєкту та закласти основу для
подальшого моделювання і реалізації.
2.2.1 Формування вимог до програмного забезпечення
Формування вимог до програмного забезпечення є ключовим етапом у
розробці будь-якої інформаційної системи, зокрема й веб-застосунку
«Географічний тренажер». Цей процес охоплює збір, аналіз, документування та
управління вимогами, що дозволяє чітко визначити потреби кінцевих користувачів
— осіб, які бажають вдосконалити свої знання з географії. Завдяки формалізації
вимог до функціональності, інтерфейсу, продуктивності та безпеки, розробник
отримує узгоджене уявлення про очікувану поведінку системи, що, своєю чергою,
забезпечує ефективне планування та реалізацію всіх етапів життєвого циклу веб-
застосунку.
Функціональні вимоги:
− реєстрація та авторизація користувачів;
− проходження тестів на знання столиць і прапорів;
− автоматичне збереження результатів;
− відображення статистики у профілі;
− таблиця лідерів;
− можливість повторного проходження тестів.
Нефункціональні вимоги:
− надійність збереження даних (база PostgreSQL);
35
ЧДТУ. 252157 009 ПЗ
− захист персональних даних (хешування паролів);
− інтуїтивно зрозумілий інтерфейс;
− висока продуктивність фронтенду (React.js).
2.2.2 Формування вимог за допомогою діаграми прецедентів
Рисунок 2.4 – Діаграма прецедентів веб-застосунку «Географічний
тренажер»
Пояснення до діаграми прецедентів:
Актор: Користувач
Це основна роль, яка взаємодіє із системою. Користувач може бути як
авторизованим, так і неавторизованим (у деяких випадках).
Прецеденти (use cases) та їх опис:
Реєстрація:
Призначення: Надання користувачу можливості створити обліковий запис.
Передумови: Користувач ще не має облікового запису.
Результат: Збереження даних у базі, доступ до особистого кабінету.
Вхід (авторизація)
36
ЧДТУ. 252157 009 ПЗ
Призначення: Доступ до персоналізованих функцій (статистика, змагання
тощо).
Передумови: Обліковий запис уже створено.
Результат: Аутентифікація користувача.
Проходження тесту
Призначення: Можливість перевірити знання користувача з географії (
столиці, прапори ).
Передумови: Авторизація обов’язкова.
Результат: Збереження результатів, перехід до аналізу.
Перегляд правильних/неправильних відповідей
Призначення: Надати користувачу зворотній зв’язок після проходження
тесту.
Залежить від: Прецеденту "Проходження тесту".
Результат: Покращення знань завдяки перегляду помилок.
Перегляд статистики
Призначення: Користувач бачить загальні результати своєї активності:
кількість відповідей/питань, правильні та неправильні відповіді, тощо.
Залежить від: Наявності даних про проходження тестів.
Результат: Мотивація до навчання, самоконтроль.
Аналіз результатів
Призначення: Глибше дослідження своїх сильних/слабких сторін.
Залежить від: "Перегляд статистики".
Результат: Рекомендації щодо вдосконалення.
Участь у змаганні
Призначення: Дозволяє користувачу брати участь у змаганнях з іншими
гравцями асинхронно.
Передумови: Авторизація.
Результат: Генерація рейтингу.
Таблиця лідерів
Призначення: Відображення найкращих гравців системи.
37
ЧДТУ. 252157 009 ПЗ
Залежить від: Прецеденту "Участь у змаганні".
Результат: Соціальна мотивація, змагальний ефект.
2.3 Проєктування логічної структури програмного комплексу
У цьому підрозділі розглядається логічне проектування архітектури веб-
застосунку «Географічний тренажер». Спочатку буде подано діаграми класів, які
ілюструють основні компоненти системи, їх властивості, функції та взаємозв’язки,
що дає змогу глибше зрозуміти логіку функціонування застосунку. Після цього
буде проаналізовано діаграму пакетів, яка показує, як елементи системи
структуровано за функціональними модулями, забезпечуючи зручність в
організації коду, спрощення супроводу та можливість подальшого розширення
системи. Такий підхід до моделювання сприяє створенню ефективної та стабільної
архітектури програмного забезпечення.
38
ЧДТУ. 252157 009 ПЗ
2.3.1 Діаграма класів
Рисунок 2.5 – Діаграма класів веб-додатка «Географічний тренажер»
Пояснення:
− Trainer: Головний клас тренажера, що відповідає за ігровий процес,
обчислення результатів і керування рівнем.
− Question: Клас для створення і перевірки запитань, які задаються
користувачеві.
− Answer: Клас, який містить відповіді та визначає, чи є вони правильними.
− Category: Клас для організації питань за категоріями, з можливістю
фільтрувати їх за рівнем складності.
39
ЧДТУ. 252157 009 ПЗ
2.3.2 Діаграма пакетів
Діаграма пакетів (Package Diagram) – це структурна діаграма, яка показує,
як система розділена на логічні блоки (пакети) та як ці блоки взаємодіють між
собою.
Вона допомагає:
− логічно структурувати код;
− визначити залежності між модулями;
− спростити підтримку та масштабування проєкту;
− спланувати архітектуру перед реалізацією.
Рисунок 2.6 - Діаграма пакетів веб-додатка «Географічний тренажер»
Пояснення діаграми пакетів:
Пояснення пакетів:
UI (User Interface) – Інтерфейс користувача
Містить компоненти, що відповідають за візуальну частину:
− HomePage, ChallengePage, StatsPage, Leaderboard – сторінки, з якими
взаємодіє користувач.
Цей пакет залежить від логіки з пакетів Challenge, User, Auth.
Auth (Аутентифікація)
40
ЧДТУ. 252157 009 ПЗ
Модулі, відповідальні за:
− RegisterService – логіка реєстрації;
− LoginService – логіка входу.
Використовується з пакетом User і взаємодіє з базою даних.
Challenge (Тести)
Відповідає за:
− проведення тестів (ChallengeService);
− перевірку відповідей (AnswerChecker);
− повернення результатів у UI;
− отримання/збереження питань у базі даних.
User (Користувач)
Містить моделі користувача та статистики:
− UserModel, UserGamesModel.
− взаємодіє з Auth, Challenge, і Database.
Database
Представлення бази даних, включає таблиці:
− UserTable – дані користувачів;
− UserGamesResults – результати тестів;
− Questions – питання для тренувань та змагань ( локально ).
Призначення діаграми пакетів
2.4 Архітектурне проектування
У цьому підрозділі буде розглянуто архітектуру веб-застосунку
«Географічний тренажер». Спершу буде проаналізовано діаграму компонентів, яка
відображає взаємодію між окремими частинами програмної системи, способи
їхньої інтеграції через інтерфейси, а також логіку обміну даними між ними. Це
дозволить краще зрозуміти модульну структуру застосунку. Далі увага
зосередиться на діаграмі розгортання, яка демонструє, як елементи системи
розміщуються на фізичних чи віртуальних пристроях, таких як сервери, клієнтські
41
ЧДТУ. 252157 009 ПЗ
пристрої та бази даних. Такий підхід дозволяє оцінити технічну інфраструктуру,
необхідну для ефективної роботи веб-застосунку.
2.4.1 Діаграма компонентів
Діаграма компонентів (Component Diagram) в UML слугує для візуалізації
фізичної структури програмної системи, демонструючи, з яких окремих частин
вона складається та як ці частини взаємодіють між собою. Вона відображає
компоненти, які можуть представляти програмні модулі, бібліотеки, сервіси або
інші сутності, що реалізують певний функціонал, а також показує залежності між
ними. Така діаграма є корисною для розуміння архітектури системи на етапі
розробки, розгортання або підтримки.
Рисунок 2.7 - Діаграма компонентів веб-додатка «Географічний тренажер»
Пояснення до діаграми компонентів:
− Frontend – React/TypeScript-інтерфейс.
− API – проміжна ланка для HTTP-запитів.
− Backend – логіка на Node.js / Express.
− DB – зберігає дані користувачів, результатів тощо.
− Зовнішні бібліотеки – використовуються як у фронтенді, так і бекенді.
2.4.2 Діаграма розгортання
Діаграма розгортання (Deployment Diagram) в UML використовується для
моделювання фізичного розміщення програмних компонентів системи на
апаратних засобах. Вона відображає вузли (сервери, клієнтські пристрої, бази
42
ЧДТУ. 252157 009 ПЗ
даних тощо) та програмні артефакти, які на них розміщені, а також зв’язки між
вузлами. Така діаграма дозволяє візуалізувати, як саме система буде працювати в
реальному середовищі, які компоненти де будуть встановлені та як
відбуватиметься обмін даними між ними. Вона є важливою для розробників і
DevOps-фахівців, оскільки допомагає планувати інфраструктуру, оптимізувати
розміщення сервісів і забезпечити ефективну взаємодію між частинами системи.
Рисунок 2.8 – Діаграма розгортання веб-додатка «Географічний тренажер»
Пояснення діаграми розгортання:
− Користувач відкриває сайт у браузері.
− Логіка обробляється у Node.js-сервері.
− Дані зберігаються у PostgreSQL.
43
ЧДТУ. 252157 009 ПЗ
2.5 Діаграма діяльності
Діаграма діяльності – це поведінкова UML-діаграма, яка моделює
послідовність дій, що відбуваються у системі у відповідь на певні події. Вона
ідеально підходить для опису логіки виконання процесу або сценарію взаємодії
користувача із системою.
Рисунок 2.9 – Діаграма діяльності веб-додатка «Географічний тренажер»
44
ЧДТУ. 252157 009 ПЗ
Пояснення діаграми діяльності:
Початок
− початкова точка діаграми;
− відображає старт сесії користувача або завантаження сайту.
Вхід або Реєстрація
− користувач може зареєструватися або авторизуватися;
− якщо не виконує цю дію – далі не матиме доступу до персональних
результатів або змагань.
Вибір режиму
Після входу, користувач обирає дію:
− звичайне проходження тесту.
Проходження тесту
− користувач починає тестування (питання, варіанти відповідей);
− відповіді передаються на сервер.
Перегляд результатів
− користувач отримує оцінку своїх відповідей;
− виводиться персональний результат.
Збереження статистики
− результати зберігаються в базі даних:
− кількість правильних відповідей;
− час проходження;
− рейтинг у змаганні тощо.
Перегляд статистики
− користувач може переглянути свою особисту статистику в профілі
Перегляд таблиці лідерів (за бажанням)
Таблиця лідерів відображає статистику усіх гравців, кожний користувач
залежно від статистики має своє місце у таблиці.
Кінець
45
ЧДТУ. 252157 009 ПЗ
− завершення процесу: користувач може повернутися до вибору режиму
або вийти з профілю.
2.6 Діаграма використання
Діаграма використання (Use Case Diagram) в UML призначена для
моделювання функціональності системи з точки зору її взаємодії з зовнішніми
користувачами (актор(ами)). Вона показує, які саме дії (випадки використання)
може виконувати система у відповідь на запити користувачів. Основними
елементами цієї діаграми є актори, випадки використання (use cases) та зв’язки між
ними. Діаграма використання дозволяє наочно уявити, які функції повинна
підтримувати система, хто ними користуватиметься і як ці функції пов’язані між
собою. Вона особливо корисна на початкових етапах розробки, оскільки допомагає
узгодити вимоги з замовником і сформувати загальне бачення майбутньої системи.
Рисунок 2.10 – Діаграма використання гри веб-додатка «Географічний тренажер»
2.7 Діаграма клієнт-серверної архітектури
Діаграма клієнт-серверної архітектури ілюструє структуру системи,
побудованої за моделлю клієнт-сервер, де взаємодія відбувається між клієнтськими
застосунками і серверними компонентами. Вона показує, які частини системи
46
ЧДТУ. 252157 009 ПЗ
виконують функції клієнта (інтерфейс користувача, запити до сервера) і які
відповідають за обробку даних, зберігання і надання сервісів на боці сервера. Така
діаграма допомагає чітко розмежувати ролі різних компонентів, зрозуміти, як
відбувається обмін інформацією між клієнтом і сервером, а також спрощує
планування розподілених систем, їх розгортання та масштабування. Вона є
важливою частиною документування архітектури програмного забезпечення,
особливо в системах із складною взаємодією користувачів і сервісів.
Пояснення:
− клієнтська частина (Frontend): Інтерфейс, який відображається
користувачам. Виконує роль запитів до серверу та обробки отриманих даних;
− серверна частина (Backend): Основна логіка додатка. Сервер обробляє
запити клієнта, працює з базою даних і повертає результати;
− база даних: Сховище інформації, яке використовується для зберігання
користувацьких даних, прогресу в навчанні, статистики тощо.
Рисунок 2.11 – Діаграма клієнт-серверної архітектури веб-додатка «Географічний
тренажер»
Елементи діаграми:
47
ЧДТУ. 252157 009 ПЗ
Клієнт:
− використовує браузер (Chrome, Firefox) для доступу до веб-додатка;
− інтерактивна частина: React.js (TypeScript) + Tailwind CSS;
− відправляє HTTP-запити (REST API або GraphQL).
Сервер:
− node.js із фреймворком Express.js;
− відповідає за маршрутизацію, обробку запитів та взаємодію з базою
даних;
− відправляє відповіді клієнту у вигляді JSON або HTML.
База даних:
− postgreSQL - реляційна база даних для зберігання структурованих
даних (користувачі, результати, дані тренувань тощо);
− сервер взаємодіє з базою даних через SQL-запити.
Взаємодія:
− клієнт -> запит (GET/POST) до сервера;
− сервер -> обробляє запит -> запит до бази даних -> повернення
результату клієнту.
Як виглядає діаграма:
Блок «Клієнт» з'єднаний стрілкою з блоком «Сервер».
Блок «Сервер» з'єднаний стрілкою з блоком «База даних».
Стрілки вказують напрямок передачі даних:
− від клієнта до сервера – запити (наприклад, HTTP GET/POST);
− від сервера до бази даних – SQL-запити;
− від бази даних до сервера – відповіді з даними;
− від сервера до клієнта – дані для відображення.
2.8 Діаграма потоків даних (Data Flow Diagram, DFD)
Діаграма потоків даних (DFD) показує, як інформація проходить через
систему: джерела та приймачі даних, обробку даних у процесах і їхнє збереження
48
ЧДТУ. 252157 009 ПЗ
в сховищах. DFD зосереджується на потоках даних між компонентами без
деталізації їхньої реалізації.
Рисунок 2.12 – Діаграма потоків даних інформації про користувача веб-
застосунка «Географічний тренажер»
Рівні DFD:
Контекстна діаграма (Рівень 0):
− найвищий рівень DFD, що показує систему як один процес;
− відображає взаємодію між зовнішніми сутностями (акторами) та
системою.
49
ЧДТУ. 252157 009 ПЗ
Рівень 1 (Decomposition Diagram):
− розбиває головний процес на підпроцеси;
− деталізує внутрішні потоки даних.
Елементи DFD:
Зовнішні сутності (External Entities):
− джерела або отримувачі даних поза системою;
− наприклад: Користувачі, Адміністратори;
Процеси (Processes):
− дії, які обробляють дані;
− наприклад: Авторизація, Збереження результатів, Надсилання
статистики.
Сховища даних (Data Stores):
− бази даних або файли, де зберігаються дані;
− наприклад: PostgreSQL (таблиці для користувачів, тестів, результатів).
Потоки даних (Data Flows):
− лінії, що показують рух даних між сутностями, процесами та
сховищами;
− дані передаються у вигляді запитів, відповідей або інформації.
2.9 ER-діаграма бази даних (Entity-Relationship Diagram, ERD)
ER-діаграма використовується для моделювання структури бази даних. Вона
показує сутності (таблиці), їхні атрибути (колонки) і зв’язки між ними. Також
позначаються первинні та зовнішні ключі, які забезпечують інтеграцію даних між
таблицями.
50
ЧДТУ. 252157 009 ПЗ
Рисунок 2.13 – ER-діаграма бази даних веб-додатка «Географічний тренажер»
Основні елементи ERD:
Сутності (Entities):
− об’єкти, які відображаються у вигляді таблиць;
− наприклад: Користувачі, Тести, Результати.
Атрибути (Attributes):
Включають:
− первинний ключ (PK): Унікальний ідентифікатор запису (наприклад,
user_id);
− зовнішній ключ (FK): Посилається на первинний ключ іншої таблиці
для встановлення зв’язку.
Зв’язки (Relationships):
Відображають взаємозв’язки між сутностями:
− 1:1: Один до одного;
− 1:N: Один до багатьох;
− M:N: Багато до багатьох.
51
ЧДТУ. 252157 009 ПЗ
2.10 Діаграма послідовностей
Діаграма послідовностей (Sequence Diagram) в UML використовується для
моделювання взаємодії між об’єктами або компонентами системи у вигляді
послідовності повідомлень у часі. Вона показує, які саме об’єкти беруть участь у
процесі, які повідомлення (виклики методів, обміни даними) вони надсилають один
одному і в якій послідовності це відбувається. Це допомагає зрозуміти динамічну
поведінку системи, послідовність операцій для виконання конкретних функцій або
сценаріїв, а також виявити можливі проблеми в логіці взаємодії. Діаграми
послідовностей особливо корисні для аналізу та проектування складних бізнес-
процесів і технічних сценаріїв взаємодії компонентів.
Пояснення:
Запит на старт
− користувач надсилає запит на початок тренування (натискає
«Почати»);
− webApp надсилає запит до локального JSON, щоб отримати дані про
країни.
Отримання даних про країни
− webApp звертається до Database;
− database повертає набір країн зі столицями;
− webApp готує інтерфейс для тренування.
Loop: для кожної країни
− webApp показує країну користувачу (наприклад: "Яка столиця
Франції?");
− користувач вибирає столицю зі списку або вводить її.
Альтернативні сценарії (alt):
Якщо відповідь правильна:
− webApp повідомляє: «Відповідь правильна»;
− якщо відповідь неправильна - webApp повідомляє: «Відповідь
неправильна».
52
ЧДТУ. 252157 009 ПЗ
Рисунок 2.14 – Діаграма послідовностей веб-додатка «Географічний
тренажер»
2.11 Діаграма скінченного автомату
Діаграма скінченного автомата (або діаграма станів) використовується для
моделювання поведінки об’єктів веб-застосунку «Географічний тренажер», які
змінюють свої стани у відповідь на різні події та дії користувачів. Нижче наведено
діаграму станів (рисунок 2.12), що ілюструє основні переходи між станами у
процесі взаємодії користувача з тренажером.
53
ЧДТУ. 252157 009 ПЗ
Рисунок 2.15 – Діаграма скінченного автомату веб-застосунка «Географічний
тренажер»
54
ЧДТУ. 252157 009 ПЗ
ВИСНОВКИ ДО ДРУГОГО РОЗДІЛУ
У другому розділі було розглянуто процес проектування веб-додатка
"Географічний тренажер" з акцентом на основні функціональні вимоги та
інструменти, що використовуються для створення і дизайну цього продукту. Ми
визначили ключові функції додатка, такі як тестування знань, збереження
результатів, таблиця лідерів та аналіз результатів користувачів через статистику.
Також було окреслено основні напрямки роботи з цільовою аудиторією та UX/UI-
особливості, що сприяють створенню зручного та інтуїтивно зрозумілого
інтерфейсу.
У розділі був детально розглянутий процес розробки проекту, починаючи від
архітектури додатка та діаграм до розробки функціональних модулів.
Використання діаграм класів, використання та послідовностей допомогло краще
зрозуміти взаємодію компонентів системи та їх зв’язки. Окрему увагу було
приділено процесу створення ER-діаграми та діаграм потоків даних, що дозволило
візуалізувати структуру даних і взаємодію між ними.
Розробка та впровадження результатів досліджень у практичну частину
проектування підтвердили важливість комплексного підходу до створення веб-
додатків. Це дозволило не тільки спростити подальшу розробку, але й зробити
продукт більш адаптивним і зручним для користувачів. В результаті, другий розділ
демонструє глибоке розуміння принципів проектування веб-додатків та важливість
застосування сучасних методів і технологій для створення ефективних рішень.
55
ЧДТУ. 252157 009 ПЗ
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1. Розробка програмного комплексу
В цьому підрозділі буде детально описано процес розробки веб-застосунку
«Географічний тренажер». Розглянуться ключові етапи створення системи — від
вибору технологій і проектування архітектури до реалізації основного
функціоналу, такого як інтерактивне навчання, тестування знань, збереження
результатів та аналіз прогресу користувачів. Це допоможе сформувати повне
уявлення про процес розробки застосунку та забезпечить чітке розуміння кожного
його етапу.
3.1.1 Обґрунтування вибору засобів реалізації
Розробка здійснюється з використанням:
React.js + TypeScript
У межах розробки вебзастосунку "Географічний тренажер" було обрано стек
React.js + TypeScript для створення інтерфейсу користувача. Такий вибір є
обґрунтованим із кількох технічних та практичних причин:
React.js – компонентно-орієнтований підхід
Модульність і повторне використання коду:
React дозволяє будувати інтерфейс із окремих компонентів (наприклад,
FlagCard, TestResult, CustomButton), що спрощує розробку, підтримку і
масштабування.
Висока продуктивність:
Завдяки використанню віртуального DOM React ефективно оновлює лише ті
частини сторінки, які змінилися, що забезпечує швидку реакцію інтерфейсу на дії
користувача.
Велика спільнота та підтримка:
56
ЧДТУ. 252157 009 ПЗ
React має широку екосистему (наприклад, Redux, React Router, React Query),
багато готових бібліотек і активну підтримку спільноти, що полегшує розробку та
вирішення типових задач.
TypeScript – строгість і безпека
Статична типізація:
TypeScript дозволяє уникати помилок, пов’язаних із типами даних
(наприклад, неправильне використання об'єктів країни, столиць тощо), ще на етапі
написання коду.
Автодоповнення та покращена навігація в коді:
Типи допомагають редактору коду (VS Code) краще аналізувати структуру
проєкту, підказувати назви функцій, властивостей тощо. Це підвищує швидкість
розробки та знижує кількість багів.
Краща масштабованість:
Завдяки явному опису типів і контрактів між модулями, проєкт легше
підтримувати в майбутньому, особливо в командній розробці.
Синергія React + TypeScript
Комбінація React і TypeScript є сучасним стандартом фронтенд-розробки,
оскільки забезпечує:
− гнучкість у проєктуванні інтерфейсу;
− типову безпеку та передбачуваність логіки;
− ефективну розробку та дебаг.
Це дає змогу створити надійний, розширюваний та зрозумілий
вебзастосунок, адаптований до майбутніх змін або нових функцій.
Tailwind CSS
У межах реалізації користувацького інтерфейсу вебзастосунку
"Географічний тренажер" для стилізації було обрано Tailwind CSS – утилітарну
CSS-фреймворк-бібліотеку, яка дозволяє швидко створювати сучасний,
адаптивний і мінімалістичний дизайн.
Причини вибору Tailwind CSS:
Утилітарний підхід до стилізації
57
ЧДТУ. 252157 009 ПЗ
Tailwind надає набір класів (утиліт), які описують окремі стилі: відступи,
кольори, розміри, шрифти тощо. Це дозволяє:
− створювати макети без написання власного CSS;
− чітко бачити стилі компонента прямо в JSX/TSX-коді;
− швидко змінювати зовнішній вигляд без переходу до окремих CSS-
файлів.
Адаптивність та мобільна оптимізація
Tailwind має вбудовану підтримку адаптивного дизайну (через брейкпойнти:
sm, md, lg, xl), що дозволило реалізувати повноцінну підтримку на мобільних
пристроях без зайвих зусиль.
Простота кастомізації
Завдяки tailwind.config.js можна:
− створювати власні кольори, шрифти, розміри;
− централізовано змінювати теми;
− легко підлаштовувати дизайн під бренд або загальну естетику
застосунку.
Висока швидкість розробки
Tailwind значно прискорює верстку інтерфейсу:
− не потрібно вигадувати назви класів;
− швидкий результат без попередньої побудови CSS-архітектури;
− чудова інтеграція з VS Code через автодоповнення Tailwind IntelliSense.
Мала вага кінцевого CSS
Після білду (завдяки PurgeCSS, вбудованому в Tailwind) до фінального CSS
потрапляють лише ті класи, що реально використовуються, що зменшує розмір
файлу стилів.
Узагальнення Tailwind CSS
Tailwind CSS чудово інтегрується з React і TypeScript, доповнюючи
компонентну структуру. Це дозволило створити стильний, легкий у підтримці і
гнучкий інтерфейс без зайвого перевантаження власним CSS-кодом. Tailwind є
58
ЧДТУ. 252157 009 ПЗ
сучасним підходом до фронтенд-розробки, що підтримується в багатьох
комерційних і open-source проєктах.
Node.js + Express.js
У дипломному проєкті "Географічний тренажер" для створення серверної
частини було обрано зв’язку Node.js як середовище виконання JavaScript на сервері,
та Express.js як веб-фреймворк.
Причини вибору Node.js
JavaScript – єдина мова для клієнта й сервера
Завдяки Node.js можна використовувати одну мову програмування як для
фронтенду (React + TypeScript), так і для бекенду. Це:
− спрощує підтримку проєкту;
− дозволяє використовувати один стек технологій;
− полегшує комунікацію між компонентами (наприклад, обмін JSON-
даними).
Асинхронність і висока продуктивність
Node.js працює на асинхронній неблокуючій моделі, що робить його
ідеальним для вебзастосунків із високою кількістю одночасних запитів, наприклад:
− обробка відповідей користувача під час проходження тестів;
− отримання даних з бази без блокування інших запитів.
Активна екосистема
Через npm можна легко підключати готові бібліотеки (наприклад,
jsonwebtoken, bcrypt, sequelize, cors, dotenv, pg, тощо), що прискорює розробку і
зменшує ризики.
Простота та мінімалізм
Express є мінімалістичним фреймворком, який не нав’язує жорсткої
структури, але дозволяє легко:
− налаштовувати маршрути;
− обробляти запити GET, POST, PUT, DELETE;
− додавати middleware.
Швидке створення REST API
59
ЧДТУ. 252157 009 ПЗ
Express ідеально підходить для розробки RESTful API, які:
− обслуговують клієнтський застосунок;
− дозволяють зберігати / отримувати дані (наприклад, результати
тестування, статистику, облікові записи користувачів).
Широка підтримка спільноти
У разі потреби легко знайти документацію, приклади, рішення на Stack
Overflow, завдяки чому легше долати технічні труднощі під час реалізації проєкту.
Узагальнення
Зв’язка Node.js + Express.js ідеально підходить для сучасного вебзастосунку,
особливо якщо фронтенд реалізовано на React. Ця комбінація забезпечує:
− швидкість;
− гнучкість;
− ефективну взаємодію з базою даних (через ORM або безпосередньо);
− та зручну побудову API для обробки даних у застосунку.
PostgreSQL
У рамках дипломного проєкту "Географічний тренажер", що має
функціональність авторизації, збереження результатів, статистики та обробки
географічних даних (країни, столиці, прапори), було обрано PostgreSQL як основну
СКБД.
Чому саме PostgreSQL?
Реляційна модель даних
PostgreSQL – це реляційна СКБД, що ідеально підходить для структурованих
даних, які використовуються в проєкті:
− таблиці Users, Users_games;
− чіткі зв’язки між ними (наприклад, user_id у результатах);
− необхідність у JOIN-запитах, фільтрації, сортуванні.
Надійність і відповідність стандартам SQL
PostgreSQL:
− дотримується стандарту SQL;
− має розширені можливості транзакційності, цілісності та безпеки;
60
ЧДТУ. 252157 009 ПЗ
− підходить для довготривалого зберігання даних та точного
відновлення.
Інтеграція з ORM (Sequelize)
У Node.js застосовано ORM-бібліотеку Sequelize, яка має повну підтримку
PostgreSQL:
− зручна міграція схем;
− зв’язки між моделями (hasMany, belongsTo);
− підтримка валідацій, кастомних запитів тощо.
Безкоштовність і відкритий код
PostgreSQL – повністю відкрита та безкоштовна СКБД, без ліцензійних
обмежень, що особливо важливо для навчального та дипломного проєкту.
Масштабованість
Навіть попри те, що застосунок створено як навчальний, у майбутньому
PostgreSQL дозволить:
− масштабувати систему;
− реалізовувати складніші звіти, фільтри;
− під’єднати сторонні BI-системи чи аналітику.
Узагальнення
PostgreSQL був обраний як СКБД у проєкті завдяки:
− стабільності та надійності;
− потужній підтримці SQL;
− простій інтеграції з Node.js через ORM;
− безкоштовності;
− гнучкості в роботі з великим обсягом даних.
Цей вибір гарантує надійну роботу системи, просту підтримку і можливість
масштабування в майбутньому.
Sequelize
Для реалізації взаємодії між серверною частиною (Node.js + Express) і базою
даних (PostgreSQL) у дипломному проєкті "Географічний тренажер" було
використано Sequelize – популярну ORM-бібліотеку для Node.js.
61
ЧДТУ. 252157 009 ПЗ
Причини вибору Sequelize:
ORM – зручна абстракція над SQL
Sequelize дозволяє:
− описувати структуру таблиць у вигляді моделей JavaScript/TypeScript;
− працювати з базою даних через об’єкти, методи та асоціації;
− уникати написання сирого SQL на кожному кроці.
− Це значно полегшує розробку і підвищує читабельність коду.
Підтримка PostgreSQL
− Sequelize має офіційну та стабільну підтримку PostgreSQL, включно з:
− транзакціями;
− валідацією;
− асинхронними операціями;
− повноцінними зв’язками між таблицями (1:1, 1:N, N:M).
Швидка генерація моделей і міграцій
У проєкті активно використовуються CLI-інструменти Sequelize для:
− генерації моделей (sequelize model:generate);
− створення та керування міграціями (sequelize db:migrate);
− синхронізації структури БД без ручного створення SQL-запитів.
Асоціації між моделями
Для збереження статистики, результатів, зв'язку користувачів і тестів
використовуються:
hasMany, belongsTo, belongsToMany – Sequelize дозволяє явно та легко
визначити ці зв’язки між таблицями/моделями.
Підтримка TypeScript
Sequelize має офіційні типи і підтримку TS, що дозволяє:
− уникати помилок під час доступу до полів моделі;
− отримувати підказки під час розробки;
− підвищити безпеку та стабільність застосунку.
Масштабованість
Sequelize дозволяє:
62
ЧДТУ. 252157 009 ПЗ
− легко додавати нові таблиці або змінювати структуру БД;
− створювати складні запити, фільтри, сортування;
− повторно використовувати логіку без дублювання SQL.
Узагальнення
Sequelize був обраний через:
− гнучку й зручну роботу з БД;
− скорочення часу на розробку;
− чудову інтеграцію з Node.js, PostgreSQL та TypeScript.
Це дозволило реалізувати ефективну та стабільну серверну частину проєкту,
яка легко підтримується та розширюється.
Figma
Для розробки макетів інтерфейсу та візуального дизайну вебзастосунку було
використано Figma – сучасний хмарний інструмент для UI/UX-дизайну.
Причини вибору Figma:
Хмарність і доступність
Figma працює прямо в браузері:
− не потребує встановлення;
− доступна з будь-якого пристрою;
− дозволяє зберігати проєкти в хмарі.
Інтуїтивний інтерфейс
Інтерфейс Figma простий у використанні навіть для тих, хто не є професійним
дизайнером:
− створення фреймів (екранів) як сторінок вебдодатку;
− просте додавання тексту, кнопок, форм;
− підтримка вирівнювання, автолейаутів, адаптивності.
Можливість створення інтерактивних прототипів
У Figma можна:
− пов’язати елементи між екранами;
− створити клікабельні прототипи;
63
ЧДТУ. 252157 009 ПЗ
− протестувати логіку навігації (перехід між екранами, натискання
кнопок тощо).
Це дозволяє ще до початку розробки перевірити зручність інтерфейсу.
Зручність для Frontend-розробника
Figma генерує CSS-стилі, кольори, шрифти, відступи – це спрощує реалізацію
інтерфейсу у коді (наприклад, з використанням Tailwind CSS).
Також підтримуються експорти в SVG/PNG для вставки іконок, прапорів
тощо.
Безкоштовний план з усіма потрібними функціями
Для одного користувача Figma пропонує повноцінний безкоштовний
функціонал:
− збереження кількох макетів;
− коментарі до елементів;
− зручний перегляд навіть без встановлення додатка.
Як використовувалася Figma у проєкті:
− Створено макети основних сторінок: головна, тестування, змагання,
особистий кабінет, статистика.
− Визначено кольорову палітру, шрифт, компоненти (кнопки, інпути).
− Макети стали основою верстки в React + Tailwind CSS.
Узагальнення
Figma була обрана як основний інструмент дизайну завдяки:
− простоті використання;
− інтерактивним прототипам;
− зручності для верстки;
− хмарному доступу;
− безкоштовності.
Вона допомогла створити логічну, привабливу і зручну структуру
інтерфейсу, що відповідає сучасним вимогам до вебзастосунків.
Vite
64
ЧДТУ. 252157 009 ПЗ
Для реалізації клієнтської частини вебзастосунку був обраний інструмент
збирання Vite, який забезпечив сучасний, швидкий і зручний процес розробки. На
відміну від традиційних збирачів, таких як Webpack, Vite працює за принципом
попередньої обробки лише тих модулів, які реально використовуються, що
дозволяє майже миттєво запускати застосунок у режимі розробки. Це значно
прискорило написання та перевірку коду, особливо на початкових етапах.
Vite ідеально поєднується з обраним стеком технологій – React і TypeScript,
пропонуючи офіційні шаблони та зручну інтеграцію з Tailwind CSS. Завдяки
гарячому перезапуску модулів (HMR) зміни у компонентах відображаються в
браузері миттєво, без перезавантаження всієї сторінки, що підвищує
продуктивність розробника.
Конфігурація Vite досить проста, але при цьому достатньо гнучка для
масштабування. При фінальному збиранні застосунку Vite використовує Rollup, що
гарантує ефективну оптимізацію та мінімальний розмір продакшн-бандлів. Саме
завдяки цим перевагам було вирішено використовувати Vite як основу для
збирання фронтенд-частини проєкту.
Бібліотеки для клієнтської частини
65
ЧДТУ. 252157 009 ПЗ
Рисунок 3.1 – Бібліотеки для клієнтської частини
@reduxjs/toolkit
Призначення: Спрощує роботу з Redux - управління глобальним станом
застосунку.
Функції: Має зручні утиліти для створення сторів (store), редьюсерів
(reducers), асинхронних дій (thunks).
Переваги: Менше шаблонного коду, краще налаштована під TypeScript,
включає createSlice, configureStore тощо.
autoprefixer
Призначення: Постпроцесор CSS, який автоматично додає вендорні префікси
(наприклад, -webkit-, -moz-) для сумісності з різними браузерами.
Використання: Працює з PostCSS і Tailwind CSS для кращої
кросбраузерності стилів.
i18next
Призначення: Бібліотека для реалізації багатомовності (інтернаціоналізації).
66
ЧДТУ. 252157 009 ПЗ
Функції: Дозволяє динамічно перемикати мови інтерфейсу, використовує
JSON-файли для збереження перекладів.
i18next-browser-languagedetector
Призначення: Додаток до i18next для автоматичного визначення мови
браузера користувача.
Функції: Допомагає показувати інтерфейс одразу зрозумілою користувачеві
мовою без ручного вибору.
md5
Призначення: Генерація MD5-хешів.
Використання: У твоєму випадку – для хешування паролів перед відправкою
на сервер.
moment
Призначення: Працює з датами та часом.
Функції: Форматування, обчислення різниці, конвертація між часовими
зонами тощо.
Примітка: Moment вважається "застарілим" у нових проєктах – краще date-
fns або Day.js. Але все ще працює стабільно.
postcss
Призначення: Інструмент для трансформації CSS з використанням JavaScript-
плагінів.
Використання: Зазвичай у зв’язці з Tailwind CSS та Autoprefixer. Обробляє
стилі перед остаточним створенням CSS.
react
Призначення: Головна бібліотека для побудови інтерфейсу користувача.
Функції: Компонентний підхід, віртуальний DOM, хуки (useState, useEffect
тощо).
Центральна частина будь-якого React-застосунку.
react-dom
Призначення: Пакет, який відповідає за рендеринг React-компонентів у DOM
браузера.
67
ЧДТУ. 252157 009 ПЗ
Функції: Метод createRoot() для початкового рендерингу додатку.
react-i18next
Призначення: Зв'язує i18next з React.
Функції: Додає React-хуки та провайдери для зручного використання
багатомовності прямо в компонентах.
react-redux
Призначення: Дозволяє React-компонентам взаємодіяти зі сховищем Redux.
Функції: Провайдер Provider, хуки useSelector, useDispatch.
Зв’язок: Необхідна для повноцінної роботи з Redux Toolkit.
react-router-dom
Призначення: Клієнтський роутер для SPA (Single Page Applications).
Функції: Створення навігації, маршрутизація сторінок (<Routes>, <Route>),
навігаційні компоненти (<Link>, useNavigate).
recharts
Призначення: Бібліотека для побудови графіків і діаграм у React.
Використання: У твоєму випадку - для візуалізації прогресу користувача.
Функції: Лінійні, кругові, гістограми тощо. Простий API, інтегрується з JSX.
Бібліотеки для backend
68
ЧДТУ. 252157 009 ПЗ
Рисунок 3.2 – Бібліотеки для backend
bcrypt
Призначення: Хешування паролів для зберігання в базі даних.
Функції: Створення захищених хешів (bcrypt.hash), перевірка пароля з хешем
(bcrypt.compare).
Перевага: Має вбудований механізм "сольової" безпеки, захищає від атак
типу rainbow tables.
cors
Призначення: Дозволяє обробляти CORS-запити між фронтендом і бекендом.
Функції: Визначає, які домени мають право звертатися до API. Наприклад,
дозволяє http://localhost:3000 робити запити до http://localhost:5000.
express
Призначення: Головний веб-фреймворк для Node.js.
Функції: Обробка маршрутів (GET, POST), middleware, маршрутизація,
робота з запитами і відповідями.
Центральна частина серверної логіки.
express-validator
69
ЧДТУ. 252157 009 ПЗ
Призначення: Валідація та санітарна обробка вхідних даних у запитах.
Функції: Перевірка, чи поле email справжнє, чи password не надто короткий
тощо.
Приклад: check('email').isEmail()
jsonwebtoken (JWT)
Призначення: Генерація та перевірка токенів доступу для авторизації.
Функції: jwt.sign створює токен після логіну, jwt.verify перевіряє його при
кожному захищеному запиті.
Використовується у модулі авторизації.
pg
Призначення: Клієнт для підключення до PostgreSQL.
Функції: Встановлення з’єднання з базою даних, виконання SQL-запитів.
Використовується разом із Sequelize.
pg-hstore
Призначення: Допоміжна бібліотека для роботи з типом даних hstore у
PostgreSQL.
Функції: Серіалізація/десеріалізація об'єктів для зберігання у hstore-полях
(рідко використовується напряму, але потрібна для Sequelize).
sequelize
Призначення: ORM (Object-Relational Mapping) для роботи з PostgreSQL
через JavaScript/TypeScript.
Функції: Створення моделей таблиць, асоціацій, автоматичне створення
запитів без написання SQL.
Переваги: Підтримка асоціацій (hasOne, hasMany, belongsTo), валідацій,
транзакцій тощо.
3.1.2 Опис структурної (функціональної) схеми
Основні модулі системи:
Auth
70
ЧДТУ. 252157 009 ПЗ
Модуль Auth відповідає за процеси реєстрації та входу користувачів у
систему. Він забезпечує безпеку шляхом хешування паролів перед їх збереженням
у базі даних. Основні функції модуля:
− прийом даних від користувача для створення нового акаунту
(реєстрація);
− перевірка введених користувачем даних при вході (логін);
− хешування паролів для захисту від несанкціонованого доступу;
− видача токена або сесії після успішної аутентифікації для подальшої
взаємодії з системою.
Challenge
Модуль Challenge відповідає за тестування користувачів. Він реалізує
завантаження тестових питань, їх відображення та обробку відповідей
користувачів. Основні функції:
− отримання списку питань із локального JSON;
− відображення питань користувачу у вигляді тесту;
− прийом і перевірка відповідей, визначення правильності;
− надання зворотного зв’язку користувачу щодо результатів тесту.
Progress
Модуль Progress відповідає за збереження і аналіз результатів проходження
тестів користувачами. Основні задачі:
− збереження даних про результати тестування (кількість правильних
відповідей, час проходження, тощо);
− аналіз прогресу користувача, відображення статистики в профілі.
Leaderboard
Модуль Leaderboard відповідає за формування і збереження рейтингу
користувачів на основі їх результатів тестування. Основні функції:
− отримання і оновлення даних про результати користувачів;
− формування таблиці лідерів за різними критеріями (наприклад, за
кількістю балів або за швидкістю проходження);
− відображення рейтингу для користувачів.
71
ЧДТУ. 252157 009 ПЗ
FlagsView
Модуль FlagsView реалізує функціонал відображення прапорів країн.
Основні функції:
− завантаження даних про прапори;
− відображення зображень прапорів у вигляді сітки;
− можливе додаткове сортування, фільтрація чи пошук по прапорах.
CapitalsView
Модуль CapitalsView відповідає за показ столиць країн. Основні задачі:
− отримання даних про столиці країн;
− відображення інформації про столиці у вигляді картки;
− забезпечення зручної навігації та інтерфейсу для користувача.
3.1.3 Опис логічної схеми системи
Логічна схема системи включає взаємодію між основними модулями, які
відповідають за авторизацію користувачів, проведення тестування, збереження
прогресу, управління рейтингами та відображення навчального контенту (прапорів
і столиць). Система побудована за клієнт-серверною архітектурою, де клієнтська
частина (фронтенд) обробляє взаємодію з користувачем, а серверна частина
(бекенд) - обробку даних і доступ до бази даних.
Основні логічні зв’язки виглядають наступним чином:
Модуль Auth
− отримує дані від користувача (логін, пароль);
− передає запит на сервер для реєстрації або авторизації;
− у разі успішного входу – повертає токен доступу, який зберігається на
клієнті для подальшої взаємодії з системою.
Модуль Challenge
− запитує на локальну бд список запитань (для столиць або прапорів);
− після відповіді користувача – локально визначає правильність або
відправляє результати на сервер для перевірки;
− передає результати до модуля Progress.
72
ЧДТУ. 252157 009 ПЗ
Модуль Progress
− приймає результати проходження тестів;
− зберігає дані в базу даних (час, кількість правильних відповідей тощо);
− аналізує динаміку навчання користувача (наприклад, покращення
результатів);
− надає доступ до статистики для відображення в особистому кабінеті
користувача.
Модуль Leaderboard
− отримує оновлені результати користувачів від модуля Progress;
− підраховує рейтинг на основі кількості правильних відповідей, швидкості
тощо;
− повертає дані у вигляді таблиці лідерів, яку бачать усі користувачі.
Модуль FlagsView
− завантажує дані про прапори з локального JSON;
− відображає їх у візуальному форматі для ознайомлення або навчання.
Модуль CapitalsView
− працює аналогічно до FlagsView, але з даними про столиці країн;
− взаємодія між модулями відбувається через API-запити (у разі роботи з
сервером) та спільний доступ до контексту користувача, токенів, або глобального
стану додатку (наприклад, через Redux).
73
ЧДТУ. 252157 009 ПЗ
Рисунок 3.3 – Структурна (функціональна) схема для веб-застосунка
«Географічний тренажер»
3.1.4 Розробка бази даних
Використано PostgreSQL. Основні таблиці:
Users: інформація про користувачів
Users_games: результати ігор користувачів
74
ЧДТУ. 252157 009 ПЗ
Рисунок 3.4 – ER-діаграма
На рисунку показано таблиці та їх відношення один між одним, відношення
було обрано один до багатьої, тобто один користувач може мати багато ігор, але не
навпаки.
У таблиці Users присутні такі стовбці:
Рисунок 3.5 – Таблиця “Users”
75
ЧДТУ. 252157 009 ПЗ
У таблиці User_games присутні такі стовбці:
Рисунок 3.6 – Таблиця “User_games”
3.1.5 Розробка інтерфейсу користувача
Інтерфейс розроблено з акцентом на простоту:
Головна сторінка
76
ЧДТУ. 252157 009 ПЗ
Рисунок 3.7 – Головний екран
Опис дизайну головної сторінки застосунку GeoSimulator:
Головна сторінка має просту та зручну структуру, що дозволяє користувачу
швидко зорієнтуватися у функціоналі застосунку. У верхній частині розташовано
хедер, який містить логотип "GeoSimulator" із піктограмою глобуса та основні
пункти навігації: Flags, Capitals, Challenge, Leaderboard. Для неавторизованих
користувачів також відображаються кнопки входу та швидкого переходу до гри.
Якщо користувач увійшов, замість кнопки входу з’являється його ім’я.
Одразу під хедером розташований банер із зеленим фоном, який заохочує
користувача почати взаємодію з платформою. Основний заклик – "Test your
77
ЧДТУ. 252157 009 ПЗ
knowledge now" – дублюється в кількох місцях, акцентуючи увагу на можливості
одразу перейти до навчання.
У центральній частині сторінки знаходиться головний блок з великою
зіркою, що символізує досягнення, а також текстовим закликом: "Improve your
geography skills and have fun!". Під ним розташована зелена кнопка "Start now", яка
є головною дією на сторінці.
Далі йде блок із перевагами платформи. На зеленому фоні зображено три
картки з піктограмами, які коротко описують ключові мотиватори користувача:
цікаве навчання, баланс між розвагами і користю, підтримка мотивації для
щоденного розвитку.
Нижче розташований блок із двома основними режимами взаємодії. Лівий
блок представляє режим навчання – користувач вивчає прапори та столиці,
запам’ятовує їх та перевіряє знання в тестах. Правий блок акцентує на режимі
змагання, де користувач може брати участь у челенджах, заробляти бали та
підніматися в таблиці лідерів. Обидва блоки оформлені як картки зі світлим фоном
і тінню, що візуально розділяє функціональні напрямки.
У футері повторюється логотип GeoSimulator, вказано авторське право (©
2024 created by Lebedenko Andrii. All rights reserved), а також розміщено посилання
на соціальні мережі та контактний email.
Загальний стиль сторінки сучасний, з акцентом на зелений як головний колір.
Шрифти прості й легко читабельні, всі елементи мають чітку ієрархію. Дизайн
орієнтований на швидкий старт і мотивацію користувача до взаємодії із
застосунком.
Екран тестування
Сторінка з тестуванням прапорів (Flags challenge page)
На цій сторінці реалізований один із ключових режимів тренувань –
перевірка знань користувача щодо прапорів країн.
У центрі екрана розміщене зображення прапора. Над ним є текстове
запрошення: "Guess the country by the flag". Під прапором розташовані шість
варіантів відповідей (Name 1 – Name 6), які реалізовані у вигляді кнопок.
78
ЧДТУ. 252157 009 ПЗ
Користувач має натиснути на ту кнопку, яка, на його думку, відповідає країні
зображеного прапора.
Інтерфейс підтримує зворотний зв'язок – після вибору відображається
результат: правильна чи неправильна відповідь.
Рисунок 3.8 – Сторінка з тестуванням прапорів
Сторінка з тестуванням столиць (Capitals challenge page)
Ця сторінка аналогічна за структурою до попередньої, але замість
зображення прапора в центрі подається назва столиці (у прикладі - "Country:
France"), і користувач має вибрати правильну країну серед шести запропонованих
варіантів.
Тут реалізується перевірка знань зі столиць країн у форматі multiple-choice.
Принцип роботи та інтерфейс взаємодії ідентичний до режиму з прапорами.
Іконки зворотного зв'язку (правильна / неправильна відповідь)
Третє зображення демонструє елементи, які з'являються після відповіді
користувача:
− зелене коло з білою галочкою - індикатор правильної відповіді;
− червоне коло з хрестиком - індикатор неправильної відповіді.
79
ЧДТУ. 252157 009 ПЗ
Ці іконки дають миттєвий візуальний зворотний зв’язок, покращуючи
інтуїтивність інтерфейсу й підтримуючи процес навчання.
Загалом, обидві сторінки мають схожий зовнішній вигляд і структуру, що
сприяє зручності використання. Інтерфейс чистий, простий і зосереджений на
основному – перевірці знань.
Рисунок 3.9 – Сторінка з тестуванням столиць
Рисунок 3.10 – Варіанти картинок при виборі відповіді
Особистий кабінет
80
ЧДТУ. 252157 009 ПЗ
Дизайн сторінки GeoSimulator виконаний у мінімалістичному стилі з
акцентом на функціональність. Основний фон – світло-сірий, що створює чистий і
ненав’язливий вигляд.
Секція "User profile" займає верхню частину сторінки. Зліва – кругле фото
користувача (з опціями "Change picture" та "Delete" зеленим і сірим кольорами
відповідно), поруч поля для "Nickname", "Email address" і "Current location". Справа
– велика порожня область "About me".
Нижче розташований графік (лінійний, сірий) без даних, а під ним – секція
"Statistics". Вона складається з трьох основних показників у верхньому рядку:
"Recent improvement", "Registered". Далі – дві категорії: "Flags" і "Capitals". Для
кожної вказано "Max correct answers", "Total answers", "Total mistakes" та "Average
response time".
Рисунок 3.11 – Сторінка особистого кабінету користувача
81
ЧДТУ. 252157 009 ПЗ
Таблиця лідерів
Дизайн основної частини сторінки Leaderboard у GeoSimulator виконаний у
простому та функціональному стилі. Центральна секція займає більшу частину
екрану і складається з таблиці з п’ятьма колонками: "#", "Nickname", "Total games",
"Correct answers" та "Recent imp". Таблиця має світло-сірий фон із тонкими сірими
лініями, що розділяють рядки та стовпці, створюючи чітку сітку. Заголовки
колонок написані чорним текстом, а сама таблиця на момент зображення порожня,
без даних. Дизайн мінімалістичний, без зайвих декоративних елементів, що
підкреслює її практичне призначення для відображення рейтингу гравців.
Рисунок 3.12 – Сторінка з таблицею лідерів
82
ЧДТУ. 252157 009 ПЗ
Сторінка з прапорами або столицями
Дизайн сторінок "Flags" та "Capitals" у GeoSimulator виконаний у схожому
стилі з акцентом на простоту та інтуїтивність.
На сторінці "Flags" центральна частина містить сітку з 12 прямокутних блоків
замість яких будуть виведені країни з JSON. У верхній частині сітки – зелена панель
із написом "Type a country", де, ймовірно, розташована пошукова строка. Під
сіткою – пагінація (1 2 3 ... 5).
Сторінка "Capitals" має аналогічну структуру з сіткою з 15 блоків. Блоки
вказують на відображення столиць і відповідних країн. Верхня зелена панель
містить напис "Capital comes from Country", а під сіткою – пагінація (1 2 3 ... 5).
Обидві сторінки мають мінімалістичний дизайн із чітким поділом на секції та
інтерактивними елементами.
Рисунок 3.13 – Сторінка з столицями
83
ЧДТУ. 252157 009 ПЗ
Рисунок 3.14 – Сторінка з прапорами
Модальні вікна реєстрації та входу
Дизайн модальних вікон "Registration" та "Login" у GeoSimulator виконаний
у єдиному стилі з акцентом на простоту та зручність. Обидві сторінки мають світло-
сірий фон із зеленим заголовком, де "Registration" та "Login" виділені великим
шрифтом. У верхньому лівому куті кожної сторінки розміщена стрілка "back" для
повернення.
На сторінці "Registration" форма включає поля: "First name" і "Last name" для
введення імені та прізвища, "Nickname" для створення псевдоніма, "Email" для
введення електронної пошти, а також "Password" і "Confirmpassword" для
створення та підтвердження пароля. Кожен рядок має сірі підказки ("Your first
name", "Your last name" тощо). Унизу – зелена кнопка "Sign up".
84
ЧДТУ. 252157 009 ПЗ
Сторінка "Login" має спрощену форму з полями "Email" для введення
електронної пошти, "Password" і "Confirmpassword" для створення та
підтвердження пароля з підказками ("Your email", "Create the password", "Write
password again"). Унизу – зелена кнопка "Sign in".
Дизайн мінімалістичний, із закругленими кутами форм та зеленими
акцентами, що забезпечують інтуїтивне заповнення даних.
Рисунок 3.15 – Модальні вікна реєстрації та входу
Сторінка вибору тестування
Дизайн сторінки "Play page" у GeoSimulator виконаний у легкому та
інтуїтивному стилі. Центральна частина сторінки має світло-сірий фон із зеленим
заголовком "Welcome to GeoSimulator" та підзаголовком "Discover the world through
fun and interactive geography games".
Основний вміст представлений двома прямокутними блоками з
закругленими кутами. Лівий блок містить зображення глобуса з прапорами різних
країн і кнопку "Flags mode" зеленого кольору. Правий блок показує карту з піном і
кнопку "Capitals mode" того ж стилю. Обидва блоки мають білий фон із легким
градієнтом і чітко виділені на тлі сторінки.
Навігаційне меню вгорі включає пункти "Flags", "Capitals", "Challenge" і
кнопки "Sign in" та "Play" праворуч, усі з зеленими акцентами. У футері – логотип
85
ЧДТУ. 252157 009 ПЗ
GeoSimulator, копірайт та контакти (Telegram, Instagram, email). Дизайн
мінімалістичний, із зеленими акцентами, що створюють дружню атмосферу.
Рисунок 3.16 - Сторінка вибору тестування
Важливо знати що фінальний вигляд сайту після розробки буде відрізнятися
від приблизного дизайну
3.1.6 Опис розробки програмних компонентів
Фронтенд-компоненти:
Home.tsx
Компонент Home є головною сторінкою застосунку й виконує функцію
привітального екрану для користувача. Його структура чітко поділена на дві
частини – header і main.
У заголовку розташовано стилізоване привітання, велике зображення з
іконкою star і основний заклик до дії – кнопка, яка веде до сторінки з описом
режимів гри. Це створює емоційний перший контакт і стимулює користувача
одразу розпочати взаємодію.
86
ЧДТУ. 252157 009 ПЗ
У секції main спершу йде яскравий блок із трьома інформаційними
елементами (RowItem), які мотивують та підкреслюють переваги використання
застосунку: навчання з позитивними емоціями, гнучкість у часі та підтримання
мотивації.
Далі відображено дві інформаційні картки (CardInfo). Вони презентують
ключові функції застосунку – режими тренувань і можливість змагатися з іншими.
Ілюстрації, заголовки й перелік можливостей кожного модуля подані у вигляді
списків, що допомагає користувачу швидко зрозуміти цінність функціоналу.
Загалом компонент створює позитивне перше враження, візуально
привабливий і водночас інформативний, плавно направляє користувача до
подальшої взаємодії з застосунком.
Рисунок 3.17 – Домашня сторінка (1)
87
ЧДТУ. 252157 009 ПЗ
Рисунок 3.18 – Домашня сторінка (2)
Рисунок 3.19 – Домашня сторінка (3)
Також ось як виглядають модальні вікна входу та реєстрації:
Рисунок 3.20 – Модальне вікно реєстрації
88
ЧДТУ. 252157 009 ПЗ
Рисунок 3.21 – Модальне вікно входу
Flags.tsx
Компонент Flags відповідає за відображення прапорів країн, реалізуючи
пошук і сортування. Його мета - допомогти користувачу знайомитися з прапорами
у зручному, інтерактивному форматі. В основі лежить масив даних країн, який
містить назви різними мовами та зображення прапорів. Усі назви динамічно
підтягуються відповідно до обраної мови інтерфейсу за допомогою бібліотеки
react-i18next.
Користувач може шукати країни за назвою, вводячи текст у спеціальне поле,
а також змінювати порядок сортування - за алфавітом або за замовчуванням. Після
обробки введених даних масив фільтрується та сортується. Готовий список
виводиться у вигляді сітки карток, кожна з яких містить прапор та назву країни.
Інтерфейс побудований на основі React-компонентів і стилізований через
Tailwind CSS. Для роботи з даними використовується файл countries.json, що
містить інформацію про всі країни. Компонент FlagCard, який використовується
для виводу однієї країни, приймає назву й зображення прапора.
Функціонал реалізований за допомогою хуків useState для стану пошуку та
сортування, а також useTranslation для підтримки локалізації. Це один із
навчальних розділів застосунку, що входить до модуля FlagsView.
89
ЧДТУ. 252157 009 ПЗ
Рисунок 3.22 – Сторінка вивчення прапорів (1)
Рисунок 3.23 – Сторінка вивчення прапорів (2)
Capitals.tsx
Цей компонент Capitals реалізує функціонал навчального розділу для
ознайомлення з країнами та їхніми столицями. Його головне завдання – дати змогу
користувачу шукати країни за назвою, сортувати список і переглядати столиці
разом із прапорами.
Компонент використовує React-хуки для збереження стану пошукового
запиту та вибраного варіанту сортування. За допомогою useTranslation він
90
ЧДТУ. 252157 009 ПЗ
підтримує багатомовність, а назви країн і столиць виводяться тією мовою, яку
обрав користувач.
У логіці фільтрації враховується тільки назва країни. При введенні тексту в
поле пошуку список країн автоматично оновлюється відповідно до запиту. Крім
того, є можливість сортування алфавітно в прямому або зворотному порядку.
Оброблений список передається в компонент CapitalCard, який відображає картку
з прапором, назвою країни та її столицею.
Уся стилізація реалізована через Tailwind CSS, а для візуального оформлення
елементів пошуку і сортування використовуються іконки. Компонент є важливою
частиною модуля вивчення столиць у вебзастосунку.
Рисунок 3.24 – Сторінка вивчення столиць (1)
91
ЧДТУ. 252157 009 ПЗ
Рисунок 3.25 – Сторінка вивчення столиць (2)
GameFlags.tsx
Цей компонент GameFlags реалізує гру, у якій користувач повинен
вгадати країну за прапором. Ось як працює логіка:
На початку компонент скидає стан гри і генерує новий набір питань, якщо їх
ще немає. Для кожного питання випадково обирається одна країна (її прапор буде
показано), а також п’ять інших варіантів назв країн. Серед них додається правильна
відповідь, і всі варіанти перемішуються.
При виборі відповіді перевіряється, чи вона правильна. Відповідь
записується в Redux-сховище за допомогою answerQuestion, а також локально
оновлюється стан для показу анімації та ведення обліку помилок. Якщо це останнє
питання, через секунду відкривається модальне вікно з результатами гри.
Угорі відображається заголовок, нижче - прапор країни, під яким показується
коротка анімація про правильність відповіді. Варіанти відповідей відображаються
у вигляді інтерактивних карток. Правильна і неправильна відповіді мають
візуальну індикацію через іконки.
Паралельно запускається таймер, який фіксує тривалість гри в секундах.
Після завершення гри, якщо користувач авторизований, дані про результат (час,
92
ЧДТУ. 252157 009 ПЗ
кількість правильних/неправильних відповідей тощо) надсилаються на сервер
через функцію postUserGame.
Компонент також містить SideWindow, який показує додаткову інформацію:
кількість питань, правильні/неправильні відповіді, час та хронологію відповідей.
Якщо гра завершена, з’являється компонент GameResult, що дозволяє побачити
підсумки та перезапустити гру.
Загалом, це інтерактивна освітня міні-гра, що поєднує вивчення прапорів із
гейміфікованим підходом і відстеженням прогресу.
Рисунок 3.26 – Сторінка тестування прапорів
Рисунок 3.27 – Сторінка тестування прапорів (екран завершення тесту)
93
ЧДТУ. 252157 009 ПЗ
GameCapitals.tsx
Компонент GameCapitals реалізує ігровий режим для вивчення столиць
країн. Його основна мета - створити інтерактивний тест, у якому користувач має
вгадати столицю країни, обираючи з кількох варіантів.
При завантаженні компонента гра автоматично генерується з 30 випадкових
питань на основі даних з countries.json. Кожне питання складається з назви країни,
прапора та набору відповідей, де одна правильна, а решта - випадкові столиці з
інших країн.
Після натискання на варіант відповіді система одразу визначає її
правильність. Якщо відповідь правильна, виводиться іконка correct; якщо ні –
incorrect. Анімація триває короткий час, після чого показується наступне питання.
Також фіксуються правильні й неправильні відповіді та час, витрачений на гру. Усе
це виводиться збоку через компонент SideWindow.
Якщо користувач авторизований, після завершення гри статистика
надсилається на сервер. Результати також можна переглянути у вигляді модального
вікна (GameResult).
Компонент використовує Redux для збереження стану гри, зокрема: списку
питань, поточного питання, кількості правильних і неправильних відповідей, а
також для управління завершенням гри. Завдяки інтеграції з i18next підтримується
перемикання мов - української та англійської.
У підсумку GameCapitals - це повноцінна навчальна гра, яка поєднує
інтерактивність, відстеження прогресу та зручний інтерфейс.
94
ЧДТУ. 252157 009 ПЗ
Рисунок 3.28 – Сторінка тестування столиць
Рисунок 3.29 – Сторінка тестування столиць (екран завершення тесту)
Profile.tsx
Компонент Profile є сторінкою профілю користувача у вебзастосунку, яка
відображає його особисту інформацію, статистику і динаміку ігрових результатів.
Спочатку імпортуються допоміжні компоненти (наприклад, InputBorder, StatsItem,
Avatar, IPInfo, LastGamesChart) і функції з Redux (useSelector, useDispatch), а також
утиліти для обробки дати (moment), перекладу (useTranslation) та завантаження
даних (fetchUserGames, fetchleaderboard, getLastGames).
95
ЧДТУ. 252157 009 ПЗ
У тілі компонента за допомогою useSelector отримуються дані про поточного
користувача, помилку, ігри користувача та лідерборд. Ідентифікатор користувача
використовується для визначення його місця в таблиці лідерів.
Локальний стан stats зберігає загальні та специфічні для кожного режиму
(прапори, столиці) статистичні показники: кількість правильних відповідей,
помилок, середній час відповіді, загальна кількість відповідей тощо. Стан games
містить останні ігри користувача, які завантажуються асинхронно при монтуванні
компонента.
За допомогою useEffect виконується кілька дій: при наявності user.id
завантажуються останні ігри, статистика ігор користувача та таблиця лідерів. У ще
одному ефекті обчислюються всі статистичні показники на основі даних про ігри.
Розраховується прогрес у правильності відповідей за останні і попередні 3 гри,
середній час відповіді для кожного режиму, кількість ігор, максимальні результати,
тощо. Статистика оновлюється в стані stats.
Інтерфейс компонента включає: аватар користувача, можливість змінити
зображення через Gravatar, інфо про email, нікнейм, IP-локацію. Відображається
загальна статистика (дата реєстрації, останній прогрес, місце в лідерборді, кількість
зіграних ігор), графік останніх ігор, а також окремі секції зі статистикою по
режимах "прапори" і "столиці". Всі текстові елементи підтримують багатомовність
завдяки useTranslation.
Таким чином, Profile є центральним компонентом особистого кабінету
користувача, який поєднує особисту інформацію з аналітикою прогресу в
навчальних іграх.
96
ЧДТУ. 252157 009 ПЗ
Рисунок 3.30 – Сторінка особистого кабінету користувача (1)
Рисунок 3.31 – Сторінка особистого кабінету користувача (2)
Рисунок 3.32 – Сторінка особистого кабінету користувача (3)
97
ЧДТУ. 252157 009 ПЗ
Leaderboard.tsx
Компонент Leaderboard відповідає за відображення таблиці лідерів на
основі ігрової статистики користувачів. Він використовує React, Redux і i18next для
підтримки багатомовності. Після монтування компонента за допомогою useEffect
ініціюється завантаження даних з Redux-стану шляхом виклику
dispatch(fetchleaderboard()).
За допомогою useSelector отримуються три частини стану з leaderboardSlice:
масив даних таблиці, стан завантаження та можливі помилки. Поки дані ще не
надійшли або виникла помилка, на екрані виводиться відповідне повідомлення.
Після успішного отримання даних рендериться таблиця з учасниками. У
таблиці відображається порядковий номер (місце у списку), ім’я користувача,
кількість правильних і неправильних відповідей, кількість ігор та відсоток
успішності. Успішність розраховується як відношення правильних відповідей до
загальної кількості відповідей, помножене на 100. Якщо певне значення дорівнює
нулю або не є числом, замість нього виводиться текст, що вказує на відсутність
даних.
Компонент має адаптивну верстку з прокруткою по горизонталі на випадок
вузьких екранів, візуально оформлений з використанням Tailwind CSS, що
забезпечує читабельність і сучасний вигляд таблиці. Усі текстові поля підтримують
переклад через useTranslation, що дозволяє використовувати компонент в
багатомовному застосунку.
98
ЧДТУ. 252157 009 ПЗ
Рисунок 3.33 – Сторінка з таблицею лідерів
Challenge.tsx
Компонент Challenge є вітальною сторінкою для вибору режиму гри в
додатку GeoSimulator. Його завдання - запропонувати користувачу вибрати один із
двох ігрових режимів: вивчення прапорів або столиць.
На початку компонента використовується хук useTranslation для
забезпечення підтримки перекладів. У центрі екрана відображається заголовок із
привітанням та назвою застосунку, виділеною зеленим кольором, а також
підзаголовок із коротким описом.
Нижче розташовані дві великі інтерактивні картки, оформлені у вигляді
блоків з білим фоном, заокругленими кутами та адаптивними розмірами. Кожна з
них містить зображення - глобус для режиму прапорів і мапу для режиму столиць
– та кнопку-посилання, що веде на відповідну сторінку гри. Посилання реалізоване
через компонент CustomLink, який приймає шлях та назву кнопки, узяту з
перекладу.
Обидві картки розміщені горизонтально з однаковими розмірами та
внутрішніми відступами, що забезпечує симетричний та естетичний вигляд.
Завдяки Tailwind CSS розмітка легко адаптується, зберігаючи зрозумілу структуру
та зручність для користувача.
99
ЧДТУ. 252157 009 ПЗ
Рисунок 3.34 – Сторінка з вибором тестування
PagesRouters.tsx
Компонент PagesRoutes відповідає за маршрутизацію сторінок у застосунку.
Він використовує компонент Routes із бібліотеки react-router-dom, щоб задати
шляхи та відповідні їм компоненти. Кожен маршрут відповідає за певну сторінку
додатку, забезпечуючи логічну навігацію між ними.
Головна сторінка доступна за шляхом / і відображає компонент Home.
Сторінки з режимами вивчення – прапори та столиці – доступні за шляхами /flags
та /capitals відповідно. Інформаційна сторінка про виклик (режим гри) розміщена
за адресою /challenge-info.
Деякі маршрути захищені компонентом ProtectedRoute, що означає:
користувач має бути авторизований, аби потрапити на ці сторінки. Це стосується,
зокрема, профілю (/profile) і обох ігрових режимів виклику - /challenge-flags та
/challenge-capitals. Якщо користувач не авторизований, ProtectedRoute
перенаправляє його на сторінку входу.
Окремий маршрут веде на сторінку лідерів – /leaderboard, де можна
переглянути таблицю результатів інших гравців. На випадок, якщо введено
неіснуючий шлях, передбачено маршрут з маскою /*, що відображає компонент
NotFound, реалізуючи обробку 404-сторінок.
Загалом цей компонент є центральною частиною системи маршрутизації
додатку, що логічно структурує його вміст і забезпечує захист окремих сторінок.
100
ЧДТУ. 252157 009 ПЗ
Рисунок 3.35 – Компонент із шляхами
ProtectedRoute.tsx
Компонент ProtectedRoute виконує роль захисного шару, що обмежує
доступ до певних сторінок для неавторизованих користувачів. Він перевіряє
наявність токена у localStorage – якщо токен є, користувач вважається
авторизованим, і компонент повертає дочірній елемент, тобто дозволяє доступ до
захищеної сторінки.
Якщо токену немає, відбувається відкриття модального вікна авторизації
(LoginModal). Це відображення здійснюється лише один раз: за допомогою стану
isLoginModalOpen гарантується, що модальне вікно не відкриється повторно при
кожному ререндері. Функція onClose, передана в LoginModal, викликає navigate(-
1), що повертає користувача на попередню сторінку, якщо той закриє модальне
вікно без входу.
101
ЧДТУ. 252157 009 ПЗ
Таким чином, компонент не тільки захищає маршрути, а й пропонує зручну
взаємодію - замість переадресації одразу відкривається модальне вікно входу,
зберігаючи контекст, у якому користувач хотів отримати доступ до сторінки.
Рисунок 3.36 – Компонент із захистом шляхів
Backend:
Бекенд вебзастосунку реалізовано за допомогою Node.js та фреймворку
Express.js, що дозволяє побудувати масштабований та гнучкий серверний додаток.
Для взаємодії з базою даних використовується PostgreSQL у поєднанні з ORM
Sequelize, що полегшує опис моделей даних і забезпечує прозору роботу з
реляційною базою.
Архітектурно бекенд складається з трьох основних шарів: моделей, сервісів і
контролерів, які організовані за принципом розділення відповідальностей. Моделі,
зокрема User та UserGames, описують структуру таблиць у базі даних, визначають
поля та типи даних, а також встановлюють зв’язки між сутностями. Ці моделі
використовуються у сервісах, де реалізується логіка роботи з даними - створення,
102
ЧДТУ. 252157 009 ПЗ
отримання, оновлення і видалення записів у базі. Контролери ж відповідають за
прийом HTTP-запитів, виклик відповідних сервісів та формування відповіді для
клієнта. Така організація дозволяє зберегти код чистим і модульним, що спрощує
підтримку та розвиток проекту.
Для маршрутизації API створено кілька основних роутерів, які групують
логіку за функціональними напрямками. Так, authRouter обробляє запити, пов’язані
з реєстрацією користувачів, їх авторизацією та генерацією JWT-токенів. Роутер
leaderboardRouter відповідає за роботу з таблицею лідерів, де зберігаються
результати гравців для відображення у рейтингах. Загальний роутер router
використовується для роботи з даними користувачів, тоді як userGamesRouter
обробляє інформацію про ігрові сесії користувачів.
Вхідною точкою бекенд-застосунку є файл api.js. У ньому виконується
ініціалізація сервера, підключення до бази даних та налаштування середовища.
Перед запуском сервера відбувається підключення до бази даних за допомогою
функції connectDB(), яка встановлює зв’язок із PostgreSQL, а також синхронізація
моделей з базою через функцію syncModels(). Сервер налаштовано для прийому
запитів з фронтенд-додатку, що працює на адресі http://localhost:5173, за
допомогою middleware cors, який забезпечує безпечний обмін даними між різними
доменами.
Для обробки вхідних HTTP-запитів використовується express.json(), що
дозволяє працювати з JSON-форматом у тілі запитів. Кожен з основних роутерів
підключено до сервера за своїм шляхом: /api для загальних користувацьких дій,
/auth - для авторизації, /games - для операцій з ігровими сесіями та /leaderboard - для
роботи з таблицею лідерів. Така організація дозволяє чітко розділити функціонал і
полегшує масштабування додатку.
Важливою складовою безпеки бекенду є middleware для авторизації -
authMiddleware. Він перевіряє наявність у заголовках запиту токена JWT і його
валідність за допомогою секретного ключа. Якщо токен відсутній або недійсний,
сервер повертає помилку доступу (401 або 403). У випадку успішної перевірки
інформація про користувача додається до об’єкта запиту (req.user), що дозволяє
103
ЧДТУ. 252157 009 ПЗ
контролерам і сервісам ідентифікувати користувача та контролювати доступ до
захищених ресурсів.
Таким чином, бекенд-сервер забезпечує стабільну та безпечну роботу
вебзастосунку, підтримуючи всі необхідні функції для аутентифікації, збереження
даних користувачів, ведення ігрової активності та формування таблиць лідерів.
Водночас архітектура з розподілом на моделі, сервіси та контролери робить код
легко підтримуваним і розширюваним.
Рисунок 3.39 – Дані з API /api/users/current_user
104
ЧДТУ. 252157 009 ПЗ
Рисунок 3.37 – Дані з API /leaderboard
105
ЧДТУ. 252157 009 ПЗ
Рисунок 3.38 – Дані з API /api/users/*current user*/last_games
Якщо токен буде не дійсний, коли користувач запросить дані, то зі сторони
сервера прийде таке повідомлення:
Рисунок 3.40 – Робота middleware (auth)
106
ЧДТУ. 252157 009 ПЗ
3.2 Тестування системи
Після реалізації основного функціоналу було проведено всебічне тестування
вебзастосунку «Географічний тренажер». Метою тестування стало виявлення та
усунення помилок на різних рівнях взаємодії компонентів системи: від окремих
функцій до повної роботи системи в умовах, наближених до реального
користування.
3.2.1 Модульне тестування
Для тестування знадобилась бібліотека jest.
Модульне тестування передбачає перевірку окремих функцій застосунку
незалежно від інших частин системи. Це дозволило переконатися у правильності
логіки на рівні окремих модулів бекенду та фронтенду.
Особливу увагу було приділено таким компонентам:
− генерація питань - перевірено, чи правильно формуються питання на
основі JSON-даних про країни, столиці та прапори. Тестування включало
випадковий вибір питань та відповідність правильних відповідей;
− перевірка правильності відповіді - протестовано функцію, яка зіставляє
обрану відповідь користувача з правильною відповіддю. Враховано також випадки
неправильного формату або відсутності відповіді.
107
ЧДТУ. 252157 009 ПЗ
Рисунок 3.41 – Тестування перевірки відповідей
Рисунок 3.42 – Тестування перевірки генерації питань
108
ЧДТУ. 252157 009 ПЗ
Рисунок 3.43 – Результати тестування
Для ілюстрації результатів модульного тестування наведено приклад
роботи функції перевірки відповідей та генерації питань:
Таблиця 3.1
Результат модульного тестування
Модуль Тестовий випадок Очікуваний Фактичний Статус
результат результат
Реєстрація нового Користувача Користувача Пройдено
користувача з створено, дані створено, дані
валідними даними успішно успішно
збережено збережено
Реєстрація
користувача
Реєстрація Помилка Помилка Пройдено
користувача з валідації, валідації,
некоректними користувача не користувача не
даними створено створено
109
ЧДТУ. 252157 009 ПЗ
Відповідь на Система Система Пройдено
правильне зараховує зараховує
запитання правильну правильну
Тестування відповідь, відповідь,
знань оновлює прогрес оновлює прогрес
Відповідь на Система відмічає Система відмічає Пройдено
неправильне відповідь як відповідь як
запитання неправильну, не неправильну, не
оновлює прогрес оновлює прогрес
Перегляд Коректне Коректне Пройдено
статистики відображення відображення
користувача з статистики, статистики,
Відображення наявними графіків та графіків та
статистики результатами таблиць таблиць
Перегляд Відображається Відображається Пройдено
статистики повідомлення повідомлення
користувача без про відсутність про відсутність
результатів даних даних
3.2.2 Інтеграційне тестування
На етапі інтеграційного тестування здійснювалася перевірка коректної
взаємодії між фронтендом і бекендом системи. Зокрема, було протестовано:
Отримання результатів - після завершення тестування користувач отримує
підсумкову оцінку, яка відповідає кількості правильних відповідей.
Авторизація - протестовано обробку логіну та реєстрації через /auth-роут.
Після авторизації користувач отримує токен, що дає змогу здійснювати запити до
захищених ресурсів.
На наступному рисунку наведено фрагменти комунікації між фронтендом і
бекендом у Postman та отримання результатів тесту:
110
ЧДТУ. 252157 009 ПЗ
Рисунок 3.44 – Тестування авторизації через Postman
Рисунок 3.45 – Тестування отримання відповідей
111
ЧДТУ. 252157 009 ПЗ
Таблиця 3.2
Результат інтеграційного тестування
Модуль Тестовий випадок Очікуваний результатФ актичний результат Статус
Користувача Користувача Пройдено
Реєстрація нового створено, дані створено, дані
Реєстрація користувача та успішно збережено у успішно збережено
користувача валідація даних базі у базі
Відповідь
Надсилання та Відповідь збережена,
збережена, прогрес
Обробка перевірка відповіді прогрес оновлено,
оновлено, Пройдено
відповідей на тестове користувач отримує
користувач
запитання фідбек
отримує фідбек
3.2.3 Системне тестування
Системне тестування охоплює перевірку всього застосунку в цілому,
включаючи всі його модулі та функції, що взаємодіють між собою. Було перевірено
повний життєвий цикл користувача:
Створення акаунта - користувач успішно реєструється через інтерфейс
застосунку, що підтверджується відповіддю сервера та автоматичним збереженням
облікових даних.
Проходження тесту - забезпечено коректне завантаження питань, вибір
варіантів відповідей, перехід між питаннями, підрахунок результатів.
Збереження статистики - після завершення тесту результати зберігаються в
базу даних для подальшого аналізу користувачем.
Таблиця лідерів - користувач має змогу переглянути загальний рейтинг
серед усіх користувачів.
112
ЧДТУ. 252157 009 ПЗ
Рисунок 3.46 – Заповнювання форми реєстрації користувача
Рисунок 3.47 – Користувача зареєстровано успішно
113
ЧДТУ. 252157 009 ПЗ
Рисунок 3.48 – Проходження тесту
Рисунок 3.49 - Результат проходження тесту
Рисунок 3.50 – Перевірка надсилання даних гри у бд
114
ЧДТУ. 252157 009 ПЗ
Рисунок 3.51 – Тестування перегляду таблиці лідерів
Таблиця 3.3
Результат системного тестування
Очікуваний Фактичний
Модуль Тестовий випадок Статус
результат результат
Реєстрація Реєстрація Користувача Користувача Пройдено
користувача користувача та створено, доступ до створено, доступ до
доступ до функцій функцій надано функцій надано
Відповіді на Надсилання Відповідь Відповідь збережена, Пройдено
питання відповіді на збережена, прогрес прогрес користувача
питання та користувача оновлено
збереження оновлено
результату
Надсилання Надсилання Результат прийде Результат прийшов Пройдено
даних на бд результату гри на успішно успішно та зберігся в
бд бд
3.2.4 Приймальне тестування
Приймальне тестування проводилось відповідно до затверджених сценаріїв.
Основна мета цього етапу – перевірити, чи відповідає система очікуванням
замовника та технічному завданню.
У рамках цього тестування виконувались:
− перевірка поведінки системи при типових сценаріях користування;
115
ЧДТУ. 252157 009 ПЗ
− перевірка реакції на неочікувані або граничні введення (наприклад,
порожні поля, помилкові відповіді);
− оцінка стабільності та швидкості реакції системи під час одночасного
використання кількома користувачами.
За результатами приймального тестування всі ключові функції працюють
коректно. Система показала високу стабільність, а інтерфейс – зручність у
користуванні.
Таблиця 3.4
Приймальне тестування
Сценарій Очікувана Фактичний Статус
№
тестування поведінка результат (Успішно/Неуспішно)
Показати
підсумковий Підсумковий
Проходження тесту з
результат з результат
1 правильними Успішно
кількістю коректно
відповідями
правильних відображений
відповідей
Повідомлення
Відображення
з’явилось,
Відправка порожніх повідомлення про
2 відмова Успішно
відповідей необхідність
відправити
відповіді
відповіді
Система коректно Помилки
Введення
обробляє показані, форма
3 некоректних даних у Успішно
помилки і не приймає
поля форми
показує підказки неправильні дані
Авторизація
Користувач
користувача з Вхід пройшов
4 успішно входить Успішно
правильними успішно
у систему
даними
Авторизація з Відображається
Помилка
5 неправильними повідомлення про Успішно
відображена
даними помилку
Тест
Перезавантаження Дані збережено,
продовжується
6 сторінки під час тест Успішно
або дані не
проходження тесту продовжується
втрачаються
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ
У цьому розділі детально описано процес розробки веб-додатку, починаючи
з вибору архітектури та основних технологій і закінчуючи реалізацією ключових
116
ЧДТУ. 252157 009 ПЗ
функціональних модулів. Для створення фронтенд-частини було обрано бібліотеку
React.js із використанням мови TypeScript, що забезпечило типізацію та підвищило
надійність коду. Для стилізації інтерфейсу користувача застосовано фреймворк
Tailwind CSS, що дозволило швидко створити адаптивний та сучасний дизайн.
На стороні сервера реалізовано бекенд на Node.js із використанням Express –
легкого веб-фреймворка, який забезпечує ефективну обробку HTTP-запитів і
взаємодію з клієнтом. Для збереження даних обрана реляційна база даних
PostgreSQL, яка гарантовано забезпечує цілісність і надійність інформації.
Структура бази даних була ретельно спроектована відповідно до вимог системи, з
урахуванням збереження інформації про користувачів, результати тестів та історію
їх проходження.
Інтерфейс користувача спроектовано з урахуванням принципів зручності та
інтуїтивної навігації, що забезпечує комфортну роботу з додатком для користувачів
різного віку та рівня підготовки. Реалізовані основні функції включають
можливість проходження тестів, отримання зворотного зв’язку у вигляді оцінок та
статистики, а також участь у змаганнях між користувачами з автоматичним
веденням таблиці лідерів.
Для перевірки коректності роботи системи проведено комплексне
тестування, що включало модульні, інтеграційні та приймальні тести. Модульні
тести підтвердили правильність функціонування окремих компонентів,
інтеграційні – належну взаємодію між фронтендом і бекендом, а приймальні –
відповідність розробленої системи початковим технічним вимогам та очікуванням
замовника. Результати тестування засвідчили стабільність роботи додатку, швидку
реакцію на дії користувача і коректне збереження статистичних даних у базі.
Загалом, реалізація проекту дозволила створити повноцінний веб-додаток,
який успішно виконує поставлені завдання навчання, аналізу знань та організації
змагань між користувачами. Система має потенціал для подальшого розширення
функціональності та інтеграції з іншими сервісами, що робить її корисним
інструментом для розвитку і перевірки географічних знань.
117
ЧДТУ. 252157 009 ПЗ
ВИСНОВКИ
Кваліфікаційна робота була присвячена розробці веб-застосунку
«Географічний тренажер» для ефективного вивчення та перевірки знань з географії.
У роботі проведено аналіз існуючих підходів і технологій для реалізації навчальних
систем, впроваджено отримані результати досліджень у процес розробки
програмного забезпечення, а також здійснено розробку і тестування веб-застосунку
для забезпечення якісного та зручного користувацького досвіду.
У цьому розділі було розглянуто актуальність розробки веб-додатка
"Географічний тренажер" і проведено аналіз сучасних платформ, методів аналізу
сайту та аналогічних сервісів.
Обрані технології, такі як React.js, Node.js і PostgreSQL, повністю
відповідають вимогам проекту. Здійснено порівняння з конкурентами, що
підтвердило унікальність "Географічного тренажера". Основні завдання розробки
визначено й структуровано для досягнення мети створення якісного інструменту
для вивчення географії.
У другому розділі було розглянуто процес проектування веб-додатка
"Географічний тренажер" з акцентом на основні функціональні вимоги та
інструменти, що використовуються для створення і дизайну цього продукту. Ми
визначили ключові функції додатка, такі як тестування знань, збереження
результатів, таблиця лідерів та аналіз результатів користувачів через статистику.
Також було окреслено основні напрямки роботи з цільовою аудиторією та UX/UI-
особливості, що сприяють створенню зручного та інтуїтивно зрозумілого
інтерфейсу.
Також був детально розглянутий процес розробки проекту, починаючи від
архітектури додатка та діаграм до розробки функціональних модулів.
Використання діаграм класів, використання та послідовностей допомогло краще
зрозуміти взаємодію компонентів системи та їх зв’язки. Окрему увагу було
приділено процесу створення ER-діаграми та діаграм потоків даних, що дозволило
візуалізувати структуру даних і взаємодію між ними.
118
ЧДТУ. 252157 009 ПЗ
Розробка та впровадження результатів досліджень у практичну частину
проектування підтвердили важливість комплексного підходу до створення веб-
додатків. Це дозволило не тільки спростити подальшу розробку, але й зробити
продукт більш адаптивним і зручним для користувачів. В результаті, другий розділ
демонструє глибоке розуміння принципів проектування веб-додатків та важливість
застосування сучасних методів і технологій для створення ефективних рішень.
У третьому цьому розділі детально описано процес розробки веб-додатку,
починаючи з вибору архітектури та основних технологій і закінчуючи реалізацією
ключових функціональних модулів. Для створення фронтенд-частини було обрано
бібліотеку React.js із використанням мови TypeScript, що забезпечило типізацію та
підвищило надійність коду. Для стилізації інтерфейсу користувача застосовано
фреймворк Tailwind CSS, що дозволило швидко створити адаптивний та сучасний
дизайн.
На стороні сервера реалізовано бекенд на Node.js із використанням Express –
легкого веб-фреймворка, який забезпечує ефективну обробку HTTP-запитів і
взаємодію з клієнтом. Для збереження даних обрана реляційна база даних
PostgreSQL, яка гарантовано забезпечує цілісність і надійність інформації.
Структура бази даних була ретельно спроектована відповідно до вимог системи, з
урахуванням збереження інформації про користувачів, результати тестів та історію
їх проходження.
Інтерфейс користувача спроектовано з урахуванням принципів зручності та
інтуїтивної навігації, що забезпечує комфортну роботу з додатком для користувачів
різного віку та рівня підготовки. Реалізовані основні функції включають
можливість проходження тестів, отримання зворотного зв’язку у вигляді оцінок та
статистики, а також участь у змаганнях між користувачами з автоматичним
веденням таблиці лідерів.
Для перевірки коректності роботи системи проведено комплексне
тестування, що включало модульні, інтеграційні та приймальні тести. Модульні
тести підтвердили правильність функціонування окремих компонентів,
інтеграційні – належну взаємодію між фронтендом і бекендом, а приймальні –
119
ЧДТУ. 252157 009 ПЗ
відповідність розробленої системи початковим технічним вимогам та очікуванням
замовника. Результати тестування засвідчили стабільність роботи додатку, швидку
реакцію на дії користувача і коректне збереження статистичних даних у базі.
Загалом, реалізація проекту дозволила створити повноцінний веб-додаток,
який успішно виконує поставлені завдання навчання, аналізу знань та організації
змагань між користувачами. Система має потенціал для подальшого розширення
функціональності та інтеграції з іншими сервісами, що робить її корисним
інструментом для розвитку і перевірки географічних знань.
120
ЧДТУ. 252157 009 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
ReactJS Documentation [Електронний ресурс]. – Точка доступу:
https://reactjs.org/docs/getting-started.html [1]
TypeScript Handbook [Електронний ресурс]. – Точка доступу:
https://www.typescriptlang.org/docs/ [2]
Tailwind CSS Documentation [Електронний ресурс]. – Точка доступу:
https://tailwindcss.com/docs [3]
Redux Documentation [Електронний ресурс]. – Точка доступу:
https://redux.js.org/introduction/getting-started [4]
Node.js Documentation [Електронний ресурс]. – Точка доступу:
https://nodejs.org/en/docs/ [5]
Express.js Documentation [Електронний ресурс]. – Точка доступу:
https://expressjs.com/ [6]
PostgreSQL Documentation [Електронний ресурс]. – Точка доступу:
https://www.postgresql.org/docs/ [7]
Jest Documentation [Електронний ресурс]. – Точка доступу:
https://jestjs.io/docs/getting-started [8]
Postman Learning Center [Електронний ресурс]. – Точка доступу:
https://learning.postman.com/docs/getting-started/introduction/ [9]
Книга: Фронтенд розробка з React та TypeScript / Іван Петренко. – Київ: IT
Books, 2023. [10]
Книга: Тестування веб-додатків за допомогою Jest / Олександр Ковальчук. –
Харків: Software Testing Press, 2022. [11]
Стаття: Основи інтеграційного тестування у веб-розробці [Електронний
ресурс]. – Точка доступу: https://webdevjournal.ua/articles/integration-testing
[12]
Український інститут географії [Електронний ресурс]. – Точка доступу:
https://geography.org.ua/ [13]
121
ЧДТУ. 252157 009 ПЗ
ДОДАТОК А
Веб-застосунок «Географічний тренажер»
Текст програми
252157 009 ПЗ
Розробник Лебеденко А.М
Черкаси 2025
122
ЧДТУ. 252157 009 ПЗ
ЛІСТИНГ
Через великий обсяг коду веб-застосунка «Географічний тренажер» було
вирішено вставити лише основні частини коду:
GameFlag.tsx:
import { useEffect, useState } from "react";
import { useDispatch, useSelector } from "react-redux";
import { answerQuestion, startGame, resetGame } from "../store/gameSlice";
import countries from "../data/countries.json";
import { RootState } from "../store/store";
import GameResult from "../components/GameResult";
import SideWindow from "../components/SideWindow";
import { correct } from "../assets/icons";
import { incorrect } from "../assets/icons";
import postUserGame from "../services/postUserGame";
import { useTranslation } from "react-i18next";
interface Country {
id: number;
country: {
en: string;
ua: string;
};
capital: {
en: string;
ua: string;
};
flag: string;
}
const GameFlags = () => {
123
ЧДТУ. 252157 009 ПЗ
const [isModalOpen, setIsModalOpen] = useState(false);
const [selectedAnswer, setSelectedAnswer] = useState<string | null>(null);
const [isAnswerCorrect, setIsAnswerCorrect] = useState<boolean | null>(null);
const [animationKey, setAnimationKey] = useState(0);
const [hasSentData, setHasSentData] = useState(false);
const [mistakes, setMistakes] = useState(0);
const [previousAnswers, setPreviousAnswers] = useState<("C" | "M")[]>([]);
const [elapsedTime, setElapsedTime] = useState(0);
const { t, i18n } = useTranslation();
const currentLang = i18n.language as "en" | "ua";
const dispatch = useDispatch();
const {
currentQuestion,
questions,
isGameOver,
correctAnswers,
incorrectAnswers,
} = useSelector((state: RootState) => state.game);
const userId = useSelector((state: RootState) => state.user.user?.id);
useEffect(() => {
dispatch(resetGame());
}, [dispatch]);
useEffect(() => {
if (!questions.length) {
const shuffledCountries = [...countries].sort(() => 0.5 - Math.random());
124
ЧДТУ. 252157 009 ПЗ
const newQuestions = shuffledCountries
.slice(0, 30)
.map((country: Country) => {
const options = [...countries]
.filter((c) => c.id !== country.id)
.sort(() => 0.5 - Math.random())
.slice(0, 5)
.map((c) => c.country);
options.push(country.country);
return {
id: country.id,
question: country.flag,
correctAnswer: country.country,
options: options.sort(() => 0.5 - Math.random()),
};
});
dispatch(startGame({ mode: "flags", questions: newQuestions }));
}
}, [dispatch, questions]);
useEffect(() => {
let isMounted = true;
if (isGameOver && !hasSentData) {
const isoDate = new Date().toISOString();
console.log(isoDate);
if (!userId) {
console.log("User is not logged in. Game data will not be sent.");
return;
125
ЧДТУ. 252157 009 ПЗ
}
const gameData = {
mode: "flags",
correct_answers: correctAnswers,
incorrect_answers: incorrectAnswers,
total_questions: questions.length,
user_id: userId || 0,
game_date: isoDate,
elapsed_time: elapsedTime,
};
const sendGameData = async () => {
try {
await postUserGame(gameData);
console.log("Game data sent");
} catch (error) {
console.error("Error sending game data", error);
} finally {
setHasSentData(true);
}
};
sendGameData();
}
return () => {
isMounted = false;
};
}, [
isGameOver,
hasSentData,
126
ЧДТУ. 252157 009 ПЗ
correctAnswers,
incorrectAnswers,
questions.length,
userId,
elapsedTime,
]);
// side window
const handleAnswer = (selected: string) => {
const current = questions[currentQuestion];
if (!current) return;
const isCorrect = selected === current.correctAnswer[currentLang];
setIsAnswerCorrect(isCorrect);
dispatch(answerQuestion({ questionId: current.id, isCorrect }));
setSelectedAnswer(selected);
if (currentQuestion + 1 === questions.length) {
setTimeout(() => setIsModalOpen(true), 1000);
}
const answer: "C" | "M" = isCorrect ? "C" : "M";
setPreviousAnswers((prev) => [...prev, answer]);
if (!isCorrect) {
setMistakes((prev) => prev + 1);
}
};
useEffect(() => {
const timer = setInterval(() => {
127
ЧДТУ. 252157 009 ПЗ
setElapsedTime((prev) => prev + 1);
}, 1000);
return () => clearInterval(timer);
}, []);
//
const handleCloseModal = () => {
setIsModalOpen(false);
dispatch(resetGame());
setHasSentData(false);
setPreviousAnswers([]);
setMistakes(0);
setElapsedTime(0);
};
const handleSwitch = () => {
setAnimationKey((prevKey) => prevKey + 1);
};
if (!questions.length || !questions[currentQuestion]) {
return <p>Завантаження гри...</p>;
}
if (isGameOver) {
return (
<GameResult
isOpen={isModalOpen}
onClose={handleCloseModal}
correctAnswers={correctAnswers}
incorrectAnswers={incorrectAnswers}
128
ЧДТУ. 252157 009 ПЗ
totalQuestions={questions.length}
/>
);
}
const current = questions[currentQuestion];
return (
<div className="w-full h-fit flex flex-col gap-6 items-center justify-center">
<h2 className="text-2xl font-bold">
{t("flagGame.title")}{" "}
<span className="underline">{t("flagGame.subtitle")}</span>{" "}
</h2>
<div className="flex justify-center items-center relative">
<img
src={current.question}
alt="flag"
style={{ width: 250, height: 170 }}
/>
{selectedAnswer !== null && (
<div className="font-bold mt-4 absolute">
{isAnswerCorrect ? (
<img
key={animationKey}
className="w-[150px] animate-fadeOut"
src={correct}
alt={t("flagGame.correctAlt")}
/>
) : (
129
ЧДТУ. 252157 009 ПЗ
<img
key={animationKey}
className="w-[150px] animate-fadeOut"
src={incorrect}
alt={t("flagGame.incorrectAlt")}
/>
)}
</div>
)}
</div>
<ul className="grid grid-cols-3 gap-x-10 gap-y-4 place-items-center mt-4">
{current.options.map((option) => (
<li
key={option[currentLang]}
onClick={() => {
handleAnswer(option[currentLang]), handleSwitch();
}}
className="h-[10vh] w-[10vw] bg-slate-300 shadow-card font-bold
rounded-lg text-center grid place-items-center cursor-pointer p-2 hover:bg-slate-400
transition"
>
{option[currentLang]}
</li>
))}
</ul>
<SideWindow
currentQuestion={currentQuestion}
questions={questions}
correctAnswers={correctAnswers}
130
ЧДТУ. 252157 009 ПЗ
incorrectAnswers={incorrectAnswers}
elapsedTime={elapsedTime}
previousAnswers={previousAnswers}
/>
</div>
);
};
export default GameFlags;
Profile.tsx:
import InputBorder from "../components/InputBorder";
import StatsItem from "../components/StatsItem";
import Avatar from "../components/Avatar";
import IPInfo from "../components/IPInfo";
import { useSelector, useDispatch } from "react-redux";
import { AppDispatch, RootState } from "../store/store";
import moment from "moment";
import { useEffect, useState } from "react";
import { fetchUserGames } from "../store/userGamesSlice";
import { fetchleaderboard } from "../store/leaderboardSlice";
import { useTranslation } from "react-i18next";
import LastGamesChart from "../components/LastGamesChart";
import getLastGames from "../services/getLastGames";
interface GameModeStats {
maxCorrectAnswers: number;
totalAnswers: number;
totalMistakes: number;
avgResponseTime: number;
131
ЧДТУ. 252157 009 ПЗ
}
interface StatsProps {
recentImprovement: string;
maxCorrectAnswers: number;
totalAnswers: number;
totalMistakes: number;
totalGames: number;
flagStats: GameModeStats;
capitalStats: GameModeStats;
}
const Profile = () => {
const user = useSelector((state: RootState) => state.user.user);
const error = useSelector((state: RootState) => state.user.error);
const userGames = useSelector(
(state: RootState) => state.userGames.userGames
);
const leaderboard = useSelector((state: RootState) => state.leaderboard.data);
const { t } = useTranslation();
const userPlace =
leaderboard.findIndex((entry) => entry.id === user?.id) + 1 || null;
const [stats, setStats] = useState<StatsProps>({
recentImprovement: "-",
maxCorrectAnswers: 0,
totalAnswers: 0,
totalMistakes: 0,
totalGames: 0,
flagStats: {
132
ЧДТУ. 252157 009 ПЗ
maxCorrectAnswers: 0,
totalAnswers: 0,
totalMistakes: 0,
avgResponseTime: 0,
},
capitalStats: {
maxCorrectAnswers: 0,
totalAnswers: 0,
totalMistakes: 0,
avgResponseTime: 0,
},
});
const [games, setGames] = useState([]);
const dispatch = useDispatch<AppDispatch>();
const formattedDate = moment(user?.createdAt).format("MM/DD/YYYY,
hh:mm A");
useEffect(() => {
if (!user?.id) return;
getLastGames(user.id)
.then((data) => setGames(data))
.catch((err) => console.error("Error games loading:", err));
}, [user?.id]);
useEffect(() => {
if (user) {
dispatch(fetchUserGames(user.id));
133
ЧДТУ. 252157 009 ПЗ
dispatch(fetchleaderboard());
}
}, [user, dispatch]);
useEffect(() => {
if (userGames) {
let totalAnswers = 0;
let totalCorrectAnswers = 0;
let totalMistakes = 0;
let maxCorrectAnswers = 0;
let totalGames = 0;
let flagAnswers = 0;
let flagCorrectAnswers = 0;
let flagMaxCorrectAnswers = 0;
let flagMistakes = 0;
let flagGamesCount = 0;
let flagElapsedTimeSum = 0;
let capitalAnswers = 0;
let capitalMaxCorrectAnswers = 0;
let capitalCorrectAnswers = 0;
let capitalMistakes = 0;
let capitalGamesCount = 0;
let capitalElapsedTimeSum = 0;
userGames.forEach((game) => {
totalAnswers += game.total_questions;
totalCorrectAnswers += game.correct_answers;
totalMistakes += game.incorrect_answers;
totalGames += 1;
134
ЧДТУ. 252157 009 ПЗ
if (game.mode === "flags") {
flagMaxCorrectAnswers = Math.max(
flagMaxCorrectAnswers,
game.correct_answers
);
flagAnswers += game.total_questions;
flagCorrectAnswers += game.correct_answers;
flagMistakes += game.incorrect_answers;
flagElapsedTimeSum += game.elapsed_time;
flagGamesCount += 1;
} else if (game.mode === "capitals") {
capitalMaxCorrectAnswers = Math.max(
capitalMaxCorrectAnswers,
game.correct_answers
);
capitalAnswers += game.total_questions;
capitalCorrectAnswers += game.correct_answers;
capitalMistakes += game.incorrect_answers;
capitalElapsedTimeSum += game.elapsed_time;
capitalGamesCount += 1;
}
});
const flagAverageResponseTime =
flagGamesCount > 0
? Math.round(flagElapsedTimeSum / flagGamesCount)
: 0;
const capitalAverageResponseTime =
135
ЧДТУ. 252157 009 ПЗ
capitalGamesCount > 0
? Math.round(capitalElapsedTimeSum / capitalGamesCount)
: 0;
const sortedGames = [...userGames].sort((a, b) => b.id - a.id);
const avgCorrect = (games: typeof userGames) => {
const correct = games.reduce((sum, g) => sum + g.correct_answers, 0);
const total = games.reduce((sum, g) => sum + g.total_questions, 0);
return total === 0 ? 0 : (correct / total) * 100;
};
let recentImprovement = "";
if (sortedGames.length >= 6) {
const last3Games = sortedGames.slice(0, 3);
const prev3Games = sortedGames.slice(3, 6);
const recentAvg = avgCorrect(last3Games);
const previousAvg = avgCorrect(prev3Games);
const improvement = Math.round(recentAvg - previousAvg);
recentImprovement =
improvement >= 0 ? `+${improvement}%` : `${improvement}%`;
}
setStats({
recentImprovement,
maxCorrectAnswers,
totalAnswers,
totalMistakes,
totalGames,
flagStats: {
136
ЧДТУ. 252157 009 ПЗ
maxCorrectAnswers: flagMaxCorrectAnswers,
totalAnswers: flagAnswers,
totalMistakes: flagMistakes,
avgResponseTime: flagAverageResponseTime,
},
capitalStats: {
maxCorrectAnswers: capitalMaxCorrectAnswers,
totalAnswers: capitalAnswers,
totalMistakes: capitalMistakes,
avgResponseTime: capitalAverageResponseTime,
},
});
}
}, [userGames]);
if (!user) {
return <p className="pl-32 text-3xl text-red-500">{error}</p>;
}
return (
<div className="px-14 flex flex-col items-center gap-14">
<h2 className="text-2xl font-bold">
{t("profile.title", { nickname: user.nickname })}{" "}
</h2>
<div className="w-[90%] h-fit flex flex-col m-auto gap-10 ">
<div className="w-full h-fit flex justify-center gap-12">
<div className="w-fit h-fit flex flex-col gap-4 justify-center items-center
m-auto">
<Avatar email={user.email} size={200} />
<a
137
ЧДТУ. 252157 009 ПЗ
href="https://gravatar.com/"
target="_blank"
className="w-[13vw] h-[2.5vw] bg-green text-[1.2vw] text-primary font-
bold rounded-2xl grid place-items-center m-auto"
>
{t("profile.changePicture")}
</a>
</div>
<div className="w-full flex flex-row gap-4 items-center">
<InputBorder
id="profile_nickname"
title={t("profile.nickname")}
name="nickname"
type="text"
placeholder="Your nickname"
value={user.nickname}
onChange={() => {}}
style="w-full"
/>
<InputBorder
id="profile_email"
title={t("profile.email")}
name="email"
type="text"
placeholder="Your email"
value={user.email}
onChange={() => {}}
style="w-full"
/>
138
ЧДТУ. 252157 009 ПЗ
<div className="w-full h-fit flex flex-col gap-2">
<p className="text-green text-[1.2vw] font-bold ">
{t("profile.location")}
</p>
<IPInfo />
</div>
</div>
</div>
</div>
<h2 className="text-2xl font-bold">{t("profile.statistic")}</h2>
<div className="w-3/4 flex flex-col gap-6">
<div className="w-full flex flex-col gap-6">
<h2 className="m-auto text-xl font-bold">Last 10 games:</h2>
<LastGamesChart games={games} />
<h3 className="text-xl font-bold pl-10">{t("profile.general")}</h3>
<div className="flex justify-around gap-20">
<StatsItem
title={t("profile.recentImprovement")}
value={
stats.recentImprovement
? stats.recentImprovement
: t("profile.playMore")
}
/>
<StatsItem title={t("profile.registered")} value={formattedDate} />
<StatsItem
title={t("profile.place")}
value={userPlace ? userPlace : t("profile.playMore")}
/>
139
ЧДТУ. 252157 009 ПЗ
<StatsItem
title={t("profile.totalGames")}
value={stats.totalGames}
/>
</div>
</div>
<div className="w-full flex flex-col gap-6">
<h3 className="text-xl font-bold pl-10">{t("profile.flags")}</h3>
<div className="flex justify-around gap-20">
<StatsItem
title={t("profile.maxCorrectAnswers")}
value={stats.flagStats.maxCorrectAnswers}
/>
<StatsItem
title={t("profile.totalAnswers")}
value={stats.flagStats.totalAnswers}
/>
<StatsItem
title={t("profile.totalMistakes")}
value={stats.flagStats.totalMistakes}
/>
<StatsItem
title={t("profile.art")}
tip={t("profile.artTip")}
value={stats.flagStats.avgResponseTime}
/>
</div>
</div>
<div className="w-full flex flex-col gap-6">
<h3 className="text-xl font-bold pl-10">{t("profile.capitals")}</h3>
140
ЧДТУ. 252157 009 ПЗ
<div className="flex justify-around gap-20">
<StatsItem
title={t("profile.maxCorrectAnswers")}
value={stats.capitalStats.maxCorrectAnswers}
/>
<StatsItem
title={t("profile.totalAnswers")}
value={stats.capitalStats.totalAnswers}
/>
<StatsItem
title={t("profile.totalMistakes")}
value={stats.capitalStats.totalMistakes}
/>
<StatsItem
title={t("profile.art")}
tip={t("profile.artTip")}
value={stats.capitalStats.avgResponseTime}
/>
</div>
</div>
</div>
</div>
);
};
export default Profile;
141
ЧДТУ. 252157 009 ПЗ
ДОДАТОК Б
Веб-застосунок «Географічний тренажер»
Інструкція користувачеві
252157 009 ПЗ
Листів 2
Розробник Лебеденко А.М
Черкаси 2025
142
ЧДТУ. 252157 009 ПЗ
Веб-застосунок «Географічний тренажер» створено для зручного вивчення
географії, тренування знань про столиці, прапори країн та інших географічних
об’єктів. Застосунок допомагає користувачам перевірити свої знання шляхом
проходження тестів та отримання підсумкових оцінок.
Реєстрація користувача
Початок роботи:
− Відкрийте веб-застосунок у браузері.
− Натисніть кнопку Реєстрація.
− Введіть своє ім’я у відповідне поле.
− Введіть електронну адресу.
− Введіть псевдонім.
− Створіть пароль.
− Підтвердіть пароль.
− Натисніть кнопку Зареєструватися.
− Після активації увійдіть у систему, ввівши логін (електронну пошту) та
пароль.
Авторизація:
− Для входу в систему відкрийте сторінку входу.
− Введіть логін та пароль.
− Натисніть кнопку Увійти.
− У разі успішної авторизації ви потрапите до особистого кабінету.
Проходження тестування
Початок тесту:
− У головному меню виберіть розділ Тести.
− Оберіть категорію тестування: столиці, прапори, країни тощо.
− Для початку тесту натисніть кнопку відповідного тесту.
Процес тестування:
− Кожне питання містить кілька варіантів відповіді.
− Виберіть один правильний варіант.
− Натисніть на правильну відповідь для переходу до наступного завдання.
143
ЧДТУ. 252157 009 ПЗ
− Після відповіді на всі питання з’явиться вікно з результатами.
Отримання результатів:
− Після завершення тесту застосунок відобразить вашу підсумкову оцінку.
− Ви побачите кількість правильних та неправильних відповідей.
Перегляд статистики
− У особистому кабінеті перейдіть до розділу Статистика.
− Тут можна переглянути результати усіх пройдених тестів.
− Відображається прогрес та загальний рівень знань.
Налаштування профілю
− У особистому кабінеті виберіть розділ Профіль.
− Ви можете змінити особисті дані фото профілю.
Вийти з системи:
− Для виходу з системи натисніть кнопку Вийти у верхньому меню.
144
ЧДТУ. 252157 009 ПЗ
ДОДАТОК В
Веб-застосунок «Географічний тренажер»
Графічні матеріали
252157 009 ПЗ
Листів 12
Розробник ________________ Лебеденко А.М
Черкаси 2025
145
ЧДТУ. 252157 009 ПЗ
Рисунок Г1 – Слайд 1
Рисунок Г2 – Слайд 2
146
482. ЧДТУ. 242239 90 01 3
Рисунок Г3 – Слайд 3
Рисунок Г4 – Слайд 4
482. ЧДТУ. 242239 90 01 4
Рисунок Г5 – Слайд 5
Рисунок Г6 – Слайд 6
482. ЧДТУ. 242239 90 01 5
Рисунок Г7 – Слайд 7
Рисунок Г8 – Слайд 8
482. ЧДТУ. 242239 90 01 6
Рисунок Г9 – Слайд 9
Рисунок Г10 – Слайд 10
482. ЧДТУ. 242239 90 01 7
Рисунок Г11 – Слайд 11
Рисунок Г12 – Слайд 12
482. ЧДТУ. 242239 90 01 8
Рисунок Г13 – Слайд 13
Рисунок Г14 – Слайд 14
482. ЧДТУ. 242239 90 01 9
Рисунок Г15 – Слайд 15
Рисунок Г16 – Слайд 16
482. ЧДТУ. 242239 90 01 10
Рисунок Г17 – Слайд 17
Рисунок Г18 – Слайд 18
482. ЧДТУ. 242239 90 01 11
Рисунок Г19 – Слайд 19
Рисунок Г20 – Слайд 20
482. ЧДТУ. 242239 90 01 12
Рисунок Г21 – Слайд 21
Рисунок Г22 – Слайд 22
482. ЧДТУ. 242239 90 01 12
Рисунок Г23 – Слайд 23
Рисунок Г24 – Слайд 24