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/9091| Title: | Android-додаток для пошуку місця відпочинку в Україні |
| Authors: | Олексюк, Вадим Володимирович Кавун, Дмитро Романович |
| Keywords: | БД, API, ПЗ, СКБД, CRUD, IDE, JSON, UI/UX, REST;HTTPS/HTTPS, SQL, DTO, JWT, XML |
| Issue Date: | 2025 |
| Abstract: | Кваліфікаційна робота магістра містить: 81 с., 38 рис., 1 таблицю, 20 використаних джерел, 3 додатки. Актуальність теми. Активний розвиток мобільних технологій та зростання попиту на цифрові інформаційні сервіси зумовлюють необхідність створення зручних мобільних застосунків для пошуку та перегляду інформації про місця відпочинку. Користувачі все частіше очікують отримувати структуровані, актуальні та доступні дані про культурні й туристичні об’єкти без використання кількох окремих сервісів. В умовах відсутності єдиного комплексного мобільного рішення, яке об’єднує різні типи місць відпочинку в межах одного застосунку, розробка Android-додатку для пошуку місць відпочинку в Україні є актуальним завданням з погляду сучасних інформаційних технологій та потреб користувачів. Мета КРМ. Метою кваліфікаційної роботи магістра є розробка Android-додатку довідкового типу для пошуку місць відпочинку в Україні з використанням клієнт-серверної архітектури та сучасних засобів мобільної і серверної розробки. Завдання КРМ. Для досягнення поставленої мети в роботі передбачено розв’язання таких завдань: проаналізувати предметну область та існуючі мобільні додатки для пошуку місць відпочинку; здійснити порівняльний аналіз аналогічних застосунків та визначити їх переваги і недоліки; обґрунтувати вибір архітектури та технологічного стеку для реалізації системи; спроєктувати інформаційну модель та структуру бази даних; реалізувати серверну частину у вигляді REST API; розробити Android-додаток із зручним інтерфейсом користувача; провести тестування працездатності та коректності функціонування розробленої системи. Об’єкт дослідження. Об’єктом дослідження є процеси пошуку та отримання довідкової інформації про місця відпочинку з використанням мобільних застосунків. Предмет дослідження. Предметом дослідження є Android-додаток для пошуку місць відпочинку в Україні. Інструментарій. Під час виконання кваліфікаційної роботи використано такі програмні засоби та технології: мову програмування Kotlin для розробки Android-додатку; Android SDK та середовище Android Studio; архітектурний підхід MVVM; REST API для взаємодії клієнта і сервера; Java та Spring Boot для реалізації серверної частини; систему керування базами даних PostgreSQL; JSON для обміну даними; JWT для реалізації механізмів авторизації. Сформульовані результати досліджень. У результаті виконання кваліфікаційної роботи розроблено функціональний Android-додаток для пошуку місць відпочинку в Україні та серверну частину, що забезпечує зберігання й обробку даних. Запропоноване рішення дозволяє здійснювати зручний пошук місць відпочинку за категоріями та містами, перегляд детальної інформації про об’єкти та взаємодію із зовнішніми ресурсами. Отримані результати підтверджують доцільність використання обраної архітектури та технологічного стеку для створення інформаційних мобільних систем довідкового типу. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9091 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кавун_Магістерська_робота_МПЗ_2404.pdf Restricted Access | 7.02 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«магістра»
освітній рівень
на тему: «Android-додаток для пошуку місць відпочинку в Україні»
Виконав: студент 2 курсу, групи МПЗ-2404
Напряму підготовки
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Кавун Д.Р.
(прізвище та ініціали)
Керівник Олексюк В.В.
(прізвище та ініціали)
Рецензент
(прізвище та ініціали)
Черкаси 2025
ЧДТУ 252483.008 ПЗ
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень магістр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
___________ Голуб С.В.
«___» _______________ 2025 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Кавун Дмитро Романович
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Android-додаток для пошуку місця відпочинку в Україні
Керівник проекту (роботи) Олексюк Вадим Володимирович к.т.н.,доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « 07 » жовтня 2025
року №307/03-03
2. Строк подання студентом проекту (роботи) 2 грудня 2025 р.
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління;
вимоги до проекту; календарне планування проекту; управління ризиками проекту; управління
ресурсами
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ;
Існуючі методи та засоби розв’язання поставлених задач;
Теоретичні та експериментальні дослідження;
Проєктування та реалізація android-додатку для пошуку місць відпочинку в Україні
Тестування програмного продукту;
Висновки;
Список використаних джерел;
Додатки.
5. Перелік додатків (з точним зазначенням назв додатків)
Додаток А. Специфікація 482.ЧДТУ.252483-01;
Додаток Б. Текст програми;
Додаток Г. Графічні матеріали;
2
ЧДТУ 252483.008 ПЗ
6. Консультанти розділів проекту (роботи)
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання 02 вересня 2025 р.
КАЛЕНДАРНИЙ ПЛАН
Строк
№ виконання
Назва етапів випускної роботи етапів Примітки
п/п
випускної
роботи
1 Постановка задачі 04.09.2025 виконано
2 Підготовка завдання 15.09.2025 виконано
3 Погодження завдання 16.09.2025 виконано
4 Затвердження завдання 22.09.2025 виконано
Основна стадія
1 Підбір матеріалів 29.09.2025 виконано
2 Аналіз шляхів вирішення поставленої задачі 06.10.2025 виконано
3 Розрахунок основних параметрів роботи 10.10.2025 виконано
4 Вибір кінцевого варіанту проектного рішення 20.10.2025 виконано
5 Оформлення первісної редакції роботи 27.10.2025 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 31.10.2025 виконано
керівником
2 Оформлення пояснювальної записки роботи в 13.11.2025 виконано
кінцевій редакції
3 Попередній захист роботи 09.12.2025 виконано
4 Затвердження роботи 15.12.2025
5 Рецензування роботи 16.12.2025
6 Захист роботи 19.12.2025
Студент _____________________ Кавун Д.Р.
(підпис) (прізвище та ініціали)
Керівник проекту (роботи) _____________________ Олексюк В.В.
(підпис) (прізвище та ініціали)
3
ЧДТУ 252483.008 ПЗ
АНОТАЦІЯ
Кваліфікаційна робота магістра містить: 81 с., 38 рис., 1 таблицю, 20
використаних джерел, 3 додатки.
Актуальність теми. Активний розвиток мобільних технологій та зростання
попиту на цифрові інформаційні сервіси зумовлюють необхідність створення
зручних мобільних застосунків для пошуку та перегляду інформації про місця
відпочинку. Користувачі все частіше очікують отримувати структуровані, актуальні
та доступні дані про культурні й туристичні об’єкти без використання кількох
окремих сервісів. В умовах відсутності єдиного комплексного мобільного рішення,
яке об’єднує різні типи місць відпочинку в межах одного застосунку, розробка
Android-додатку для пошуку місць відпочинку в Україні є актуальним завданням з
погляду сучасних інформаційних технологій та потреб користувачів.
Мета КРМ. Метою кваліфікаційної роботи магістра є розробка
Android-додатку довідкового типу для пошуку місць відпочинку в Україні з
використанням клієнт-серверної архітектури та сучасних засобів мобільної і
серверної розробки.
Завдання КРМ. Для досягнення поставленої мети в роботі передбачено
розв’язання таких завдань:
− проаналізувати предметну область та існуючі мобільні додатки для пошуку
місць відпочинку;
− здійснити порівняльний аналіз аналогічних застосунків та визначити їх
переваги і недоліки;
− обґрунтувати вибір архітектури та технологічного стеку для реалізації
системи;
− спроєктувати інформаційну модель та структуру бази даних;
− реалізувати серверну частину у вигляді REST API;
− розробити Android-додаток із зручним інтерфейсом користувача;
− провести тестування працездатності та коректності функціонування
розробленої системи.
4
ЧДТУ 252483.008 ПЗ
Об’єкт дослідження. Об’єктом дослідження є процеси пошуку та отримання
довідкової інформації про місця відпочинку з використанням мобільних застосунків.
Предмет дослідження. Предметом дослідження є Android-додаток для пошуку
місць відпочинку в Україні.
Інструментарій. Під час виконання кваліфікаційної роботи використано такі
програмні засоби та технології: мову програмування Kotlin для розробки
Android-додатку; Android SDK та середовище Android Studio; архітектурний підхід
MVVM; REST API для взаємодії клієнта і сервера; Java та Spring Boot для реалізації
серверної частини; систему керування базами даних PostgreSQL; JSON для обміну
даними; JWT для реалізації механізмів авторизації.
Сформульовані результати досліджень. У результаті виконання
кваліфікаційної роботи розроблено функціональний Android-додаток для пошуку
місць відпочинку в Україні та серверну частину, що забезпечує зберігання й обробку
даних. Запропоноване рішення дозволяє здійснювати зручний пошук місць
відпочинку за категоріями та містами, перегляд детальної інформації про об’єкти та
взаємодію із зовнішніми ресурсами. Отримані результати підтверджують
доцільність використання обраної архітектури та технологічного стеку для
створення інформаційних мобільних систем довідкового типу.
Перелік ключових слів: БД, API, ПЗ, СКБД, CRUD, IDE, JSON, UI/UX, REST,
HTTPS/HTTPS, SQL, DTO, JWT, XML.
5
ЧДТУ 252483.008 ПЗ
ABSTRACT
Master’s work contains: 81 pages, 37 figures, 1 table, 20 sources used, 3
attachments.
Actuality of the topic. The active development of mobile technologies and the
growing demand for digital information services necessitate the creation of convenient
mobile applications for searching and viewing information about recreational facilities.
Users increasingly expect to receive structured, up-to-date, and accessible data about
cultural and tourist attractions without having to use several separate services. In the
absence of a single comprehensive mobile solution that combines different types of
recreational facilities within a single application, the development of an Android
application for searching for recreational facilities in Ukraine is a relevant task from the
point of view of modern information technologies and user needs.
Purpose of the thesis. The purpose of the master's thesis is to develop an Android
reference application for searching for vacation spots in Ukraine using client-server
architecture and modern mobile and server development tools.
Tasks of the thesis. To achieve the set goal, the following tasks are to be completed:
− analyze the subject area and existing mobile services for searching for vacation
spots;
− conduct a comparative analysis of similar applications and identify their advantages
and disadvantages;
− justify the choice of architecture and technology stack for the implementation of the
system;
− design an information model and database structure;
− implement the server part in the form of a REST API;
− develop an Android application with a user-friendly interface;
− test the performance and correct functioning of the developed system.
Object of research. The research subject is the processes of searching for and
obtaining reference information about vacation destinations using mobile applications.
6
ЧДТУ 252483.008 ПЗ
Subject of research. The subject of research is methods, models, and software tools
for designing and implementing an Android application for searching for vacation spots in
Ukraine based on client-server interaction.
Tools. The following software tools and technologies were used during the
qualification work: Kotlin programming language for Android application development;
Android SDK and Android Studio environment; MVVM architectural approach; REST
API for client-server interaction; Java and Spring Boot for server implementation; the
PostgreSQL database management system; JSON for data exchange; JWT for
authorization mechanisms.
Formulated research results. As a result of the qualification work, a functional
Android application for searching for vacation spots in Ukraine and a server part that
provides data storage and processing were developed. The proposed solution allows users
to conveniently search for vacation spots by category and city, view detailed information
about objects, and interact with external resources. The results confirm the feasibility of
using the selected architecture and technology stack to create informational mobile
reference systems.
List of keywords: DB, API, SW, DBMS, CRUD, IDE, JSON, UI/UX, REST,
HTTPS/HTTPS, SQL, DTO, JWT, XML.
7
ЧДТУ 252483.008 ПЗ
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ 10
ВСТУП 11
1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ ЗАВДАНЬ 14
1.1. Аналіз наукової та технічної інформації щодо теми дослідження 14
1.2. Аналіз існуючих аналогів 16
1.3. Пошук методів та засобів для вирішення поставлених завдань 21
1.4. Актуальні проблеми, що виникають при створенні інформаційних мобільних
систем 25
1.5. Конкретизація завдання магістерської роботи 30
1.6. Формулювання місця автора в розв’язанні задачі 34
1.7. Висновки до розділу 1 37
2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ 39
2.1. Теоретичні основи побудови інформаційних мобільних систем 39
2.2. Експериментальна оцінка та дослідження продуктивності системи 49
2.3. Висновки до розділу 2 52
3 ПРОЄКТУВАННЯ ТА РЕАЛІЗАЦІЯ ANDROID-ДОДАТКУ ДЛЯ ПОШУКУ
МІСЦЬ ВІДПОЧИНКУ В УКРАЇНІ 54
3.1. Загальна архітектура програмної системи 54
3.2. Проєктування бази даних системи 59
3.3. Проєктування та реалізація серверної частини системи 65
3.4. Реалізація клієнтської частини Android-додатку 69
3.5. Тестування та налагодження програмної системи 74
3.6. Висновки до розділу 3 77
4 ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 79
4.1. Мета та завдання тестування програмного забезпечення 79
4.2. Тестування серверної частини системи 81
4.3. Тестування клієнтської частини Android-додатку 85
4.4. Тестування продуктивності та надійності програмного забезпечення 87
8
ЧДТУ 252483.008 ПЗ
4.5. Аналіз результатів тестування 89
4.6. Висновки до розділу 4 91
ВИСНОВКИ 92
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 94
ДОДАТОК А 96
ДОДАТОК Б 98
ДОДАТОК Г 121
9
ЧДТУ 252483.008 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ, СИМВОЛІВ, СКОРОЧЕНЬ І ТЕРМІНІВ
БД – база даних;
API – прикладний програмний інтерфейс;
ПЗ – програмне забезпечення;
CRUD-операції – акронім, який означає чотири основні операції при роботі з
БД: створення (Create), читання (Read), оновлення (Update), видалення (Delete);
IDE – комплексне програмне рішення для розробки програмного забезпечення;
JSON – запис об’єктів JavaScript;
СКБД – система керування базами даних;
UI/UX – User Interface (Інтерфейс користувача)/User Experience (Досвід
користувача);
REST – Representational State Transfer, архітектурний стиль для створення
веб-сервісів;
HTTP/HTTPS – протоколи для передачі даних в Інтернеті;
SQL – Structured Query Language, мова запитів для керування та роботи з
реляційними базами даних;
DTO – Data Transfer Object, об'єкт-контейнер для передачі даних між різними
частинами сервісу;
JWT – JSON Web Token, стандарт для безпечного передавання інформації;
XML – eXtensible Markup Language, розширювана мова розмітки для
структурованого зберігання, передачі та обміну даними.
10
ЧДТУ 252483.008 ПЗ
ВСТУП
Актуальність теми
Сучасна сфера туризму, готельно-ресторанного бізнесу та культурного
дозвілля активно розвивається під впливом цифрових технологій і мобільних
сервісів. Користувачі дедалі частіше отримують інформацію про місця відпочинку за
допомогою смартфонів, очікуючи швидкого доступу до актуальних та
структурованих даних. Водночас на ринку відсутні комплексні мобільні рішення, які
б об’єднували інформацію про різні типи культурно-туристичних локацій у межах
єдиного довідкового застосунку. Існуючі сервіси зазвичай спеціалізуються лише на
окремих видах відпочинку або мають комерційну спрямованість. Тому розробка
інформаційного Android-додатку для пошуку місць відпочинку в Україні є
актуальним і доцільним завданням з погляду сучасних інформаційних технологій.
Зв’язок роботи з науковими програмами, планами, темами
Магістерська робота виконана відповідно до освітньо-наукової програми
підготовки магістрів за спеціальністю галузі інформаційних технологій та відповідає
планам навчального процесу кафедри. Тематика роботи узгоджується з напрямами
наукових досліджень у сфері розробки інформаційних систем, мобільних
застосунків та клієнт-серверних архітектур. Результати дослідження можуть бути
використані під час виконання науково-дослідних робіт, пов’язаних зі створенням та
впровадженням інформаційних мобільних систем довідкового типу.
Мета і завдання дослідження
Метою магістерської роботи є створення інформаційного Android-додатку для
пошуку місць відпочинку в Україні на основі клієнт-серверної архітектури, який
забезпечує зручний доступ до структурованої довідкової інформації про готелі,
кінотеатри та театри.
Для досягнення поставленої мети у роботі необхідно розв’язати такі завдання:
− проаналізувати існуючі мобільні застосунки та підходи до організації
інформаційних систем у сфері туризму та культурного дозвілля;
11
ЧДТУ 252483.008 ПЗ
− обґрунтувати вибір архітектури та технологічного стеку для реалізації
мобільного застосунку і серверної частини;
− спроєктувати інформаційну модель системи та структуру бази даних;
− реалізувати серверну частину у вигляді REST API з підтримкою авторизації;
− розробити Android-додаток з використанням сучасних підходів до UI/UX та
архітектури MVVM;
− забезпечити взаємодію клієнта і сервера та перевірити працездатність системи
експериментальним шляхом.
Об’єкт дослідження
Об’єктом дослідження є процеси пошуку місць відпочинку через
android-додатки.
Предмет дослідження
Предметом дослідження є методи та засоби проєктування і реалізації
клієнт-серверної інформаційної мобільної системи для пошуку місць відпочинку в
Україні.
Методи дослідження
Для досягнення поставленої мети у магістерській роботі використано такі
методи дослідження: аналіз і порівняння – під час вивчення наукових джерел та
існуючих мобільних застосунків-аналогів; системний підхід і моделювання – при
проєктуванні архітектури програмної системи та інформаційної моделі;
формалізація – під час побудови математичних моделей процесів фільтрації,
авторизації та навігації; експеримент і тестування – для перевірки працездатності та
продуктивності реалізованого програмного забезпечення.
Наукова новизна одержаних результатів
У магістерській роботі отримано такі наукові результати:
1. Вперше запропоновано модель інформаційного мобільного застосунку
довідкового типу, яка поєднує різні категорії місць відпочинку (готелі,
кінотеатри, театри) в межах єдиної клієнт-серверної системи з
уніфікованою структурою даних.
12
ЧДТУ 252483.008 ПЗ
2. Удосконалено підхід до організації навігації та фільтрації довідкової
інформації у мобільному застосунку шляхом використання багаторівневої
схеми «категорія – місто – локація», що зменшує кількість дій користувача
для отримання результату.
3. Набуло подальшого розвитку застосування REST-архітектури та
токен-базованої авторизації в інформаційних мобільних системах
довідкового призначення.
Практичне значення одержаних результатів
Практичне значення роботи полягає у створенні функціонального
Android-додатку та серверної частини, які можуть бути використані як готовий
програмний продукт або як основа для подальшого розширення. Розроблену систему
можна застосовувати для надання довідкової інформації про місця відпочинку, а
також адаптувати для інших регіонів чи категорій локацій. Отримані результати
можуть бути використані у навчальному процесі та при розробці інформаційних
мобільних систем.
Особистий внесок автора
Усі результати, викладені в магістерській роботі, отримані автором особисто.
Автором виконано аналіз предметної області, спроєктовано архітектуру програмної
системи, розроблено серверну частину та Android-додаток, побудовано
UML-діаграми, реалізовано механізми авторизації та фільтрації даних, а також
проведено експериментальне тестування системи.
13
ЧДТУ 252483.008 ПЗ
1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ
1.1. Аналіз наукової та технічної інформації щодо теми дослідження
Сфера туризму, готельно-ресторанного бізнесу та культурних послуг стрімко
трансформується під впливом цифровізації. Мобільні додатки стали ключовим
інструментом для пошуку інформації про місця відпочинку, культурні заходи, готелі
та інші локації дозвілля. Дослідження останніх років підкреслюють, що кінцеві
користувачі дедалі частіше віддають перевагу мобільним сервісам, які забезпечують
швидкий доступ до повної, актуальної та структурованої інформації про місця
відпочинку.
У наукових джерелах відзначається, що інформаційні мобільні системи
відіграють важливу роль у формуванні споживчої поведінки туристів та місцевих
мешканців. Згідно з аналітичними дослідженнями Європейської комісії з цифрового
суспільства, тенденція до створення універсальних інформаційних платформ
продовжує зростати: користувачі прагнуть мати в одному додатку усю довідкову
інформацію щодо відпочинку у певному регіоні або країні. Це повністю корелює з
метою даного дослідження: створити Android-додаток, який агрегує інформацію про
готелі, театри й кінотеатри України та полегшує пошук культурно-туристичної
активності.
У науковій літературі останніх років виокремлюються такі ключові напрями
розвитку інформаційних мобільних систем у сфері туризму та дозвілля [1]:
− Геолокаційні сервіси – забезпечують рекомендації залежно від
місцеположення користувача.
− Каталогізація об’єктів із багаторівневою фільтрацією – сортування за містом,
категорією, популярністю тощо.
− Персоналізація контенту – обрані місця, персональні добірки, рейтинги.
− Інтеграція з зовнішніми сервісами – системами продажу квитків, бронювання
номерів, маркетинговими платформами.
14
ЧДТУ 252483.008 ПЗ
− Підвищена увага до UX/UI – логічна структура навігації, адаптивний дизайн,
мінімалізм інтерфейсу.
З огляду на це, сучасні довідкові мобільні додатки характеризуються високими
вимогами до швидкості обробки даних, актуальності інформації, інтерактивності та
безпеки [3]. Значна частина наукових робіт, присвячених мобільним інформаційним
системам, підкреслює важливість оптимальної архітектури клієнт-серверної
взаємодії. У цьому контексті використання Android (Kotlin), Spring Boot та
PostgreSQL у розробці пропонованого додатку є технічно обґрунтованим рішенням,
що відповідає сучасним стандартам побудови мобільних систем.
Серед питань, які активно досліджуються, варто відокремити:
− ефективні підходи до побудови REST-архітектури для мобільних клієнтів;
− застосування OpenAPI-специфікацій для автоматизації генерації серверного та
клієнтського коду;
− методи оптимізації баз даних у системах з великим обсягом довідкової
інформації;
− підвищення надійності мобільних сервісів через багаторівневу аутентифікацію
та захист REST-запитів;
− застосування моделей машинного аналізу даних у туристичних додатках.
Аналізуючи праці українських і зарубіжних дослідників, можна зробити
висновок, що індустрія мобільних інформаційних систем у сфері туризму та
культурних послуг активно розвивається, проте в Україні все ще залишається
проблема відсутності єдиної довідкової системи, яка б об’єднувала різні типи
локацій відпочинку та надавала можливість пошуку по містах і категоріях. Наявні
сервіси переважно орієнтовані або на бронювання (Booking.com), або виключно на
один тип діяльності (кінотеатри, театри), або є локальними додатками окремих
закладів.
Відповідно, розробка комплексного Android-додатку, здатного поєднати різні
види місць відпочинку та забезпечити зручний пошук, є актуальною задачею як з
точки зору інформаційних технологій, так і з точки зору потреб користувачів.
15
ЧДТУ 252483.008 ПЗ
1.2. Аналіз існуючих аналогів
Для побудови якісної інформаційної системи необхідно дослідити мобільні
сервіси зі схожою функціональністю. У межах роботи проаналізовано п’ять
популярних застосунків, кожен з яких представляє певний тип інформаційних або
культурних платформ.
1.2.1 Аналіз додатку «Multiplex»
Першим прикладом аналогів розглямено додаток «Multiplex» [15]. Сторінки
додатку представлені на рис. 1.1. Даний додаток дозволяє переглядати розклад
фільмів, купувати квитки, переглядати трейлери та акції.
Розглянемо його переваги і недоліки:
Переваги додатку «Multiplex»:
− зручна покупка квитків онлайн;
− актуальний розклад усіх кінотеатрів мережі;
− пуш-сповіщення про акції та прем’єри;
− інтуїтивний та сучасний інтерфейс.
Недоліки додатку «Multiplex»:
− працює лише з кінотеатрами Multiplex, немає даних про інші;
− немає загального каталогу закладів чи інших видів відпочинку;
− обмежений функціонал (тільки кіно).
Рисунок 1.1 – Сторінки додаку «Multiplex»
16
ЧДТУ 252483.008 ПЗ
1.2.2 Аналіз додатку «Booking.com»
Другим додатком в роботі проаналізовано додаток «Booking.com» [14].
Booking.com – це додаток для пошуку, порівняння та бронювання готелів,
апартаментів та інших місць для проживання. Сторінки додатку «Booking.com»
представлено на рис 1.2.
Переваги додатку «Booking.com»:
− величезна база готелів у всьому світі;
− зручні фільтри та сортування;
− відгуки від реальних користувачів;
− можливість бронювання без передоплати (у багатьох випадках).
Недоліки додатку «Booking.com»:
− сильна конкуренція серед закладів, що ускладнює вибір;
− не всі фото відповідають реальності (залежить від власників);
− комісії можуть впливати на кінцеву вартість;
− сфокусований лише на проживанні – немає інших видів відпочинку.
Рисунок 1.2 – Сторінки додатку «Booking.com»
17
ЧДТУ 252483.008 ПЗ
1.2.3 Аналіз додатку «SmartCinema»
Наступним в роботі проаналізовано додаток «SmartCinema» [16]. SmartCinema
– додаток для покупки квитків у різних кінотеатрах, зазвичай агрегатор кількох
мереж. Сторінки додатку зображені на рис. 1.3.
Переваги додатку «SmartCinema»:
− можливість переглядати розклади різних кінотеатрів в одному місці;
− зручний пошук за містом, фільмом, часом сеансу;
− онлайн-покупка квитків без черг.
Недоліки додатку «SmartCinema»:
− залежність від того, чи підтримує кінотеатр сервіс;
− обмежений тип контенту – лише кіно;
− інформація про кінотеатри надається по обмеженій кількості міст;
− інколи можливі затримки актуалізації розкладу.
Рисунок 1.3 – Сторінки додатку «SmartCinema»
18
ЧДТУ 252483.008 ПЗ
1.2.4 Аналіз додатку «Контрамарка»
Наступним в роботі проаналізовано додаток «Контрамарка» [17]. Цей додаток
дозволяє шукати, переглядати та купувати квитки на концерти, театри, фестивалі,
спортивні та інші події. У додатку зібрано великий каталог розважальних,
культурних та спортивних заходів. Сторінки додаку зображені на рис. 1.4.
Переваги додатку «Контрамарка»:
− широкий вибір подій: концерти, вистави, шоу, спортивні події, фестивалі,
майстер-класи – усе зібрано в одному додатку;
− зручність і швидкість: пошук, фільтри, купівля квитків прямо з телефону –
кілька кліків замість довгого пошуку;
− електронні квитки: не треба фізичних носіїв – квиток завжди з вами у
смартфоні;
− мобільність: можна купити та переглянути квитки будь-де – на дорозі, в
дорозі, на відпочинку;
− оновлення й актуальність: афіша подій регулярно оновлюється, видно
майбутні концерти, вистави та інші заходи.
Недоліки додатку «Контрамарка»:
− залежність від організаторів: додаток – просто посередник: якщо організатор
закладу має помилки або затримки, це може вплинути на покупку або доставку
квитків;
− не завжди гарантія сервісу: є скарги, що іноді після оплати квитків – затримки
з підтвердженням або відсутність квитків;
− обмежений спектр – лише події: додаток не охоплює інші види відпочинку
(готелі, ресторани, відпустки тощо), лише концерти/вистави/спортивні події;
− потреба перевіряти надійність заходів: у разі скасування чи переносу –
відповідальність за сам захід лежить на організаторах, а не на додатку.
19
ЧДТУ 252483.008 ПЗ
Рисунок 1.4 – Сторінки додатку «Контрамарка»
1.2.5 Аналіз додатку «Hotel Ukraina»
Наступним в роботі додаток «Hotel Ukraina» [18]. Даний додаток представляє
інформацію про готель або мережа готелів (залежно від міста), які пропонують
проживання, бронювання номерів та перегляд інформації про послуги. Сторінки
додатку зображені на рис. 1.5.
Переваги додатку «Hotel Ukraina»:
− простий і зрозумілий сервіс для бронювання конкретного готелю;
− детальна інформація про доступні номери;
− актуальні ціни та фото без посередників;
− можливість прямого контакту з адміністрацією готелю.
Недоліки додатку «Hotel Ukraina»:
− це локальний сервіс, не агрегатор – охоплює лише один готель;
− обмежений функціонал порівняно з глобальними платформами;
− немає різноманітних можливостей або оглядів інших закладів;
20
ЧДТУ 252483.008 ПЗ
− відсутність універсального пошуку інших місць для проживання.
Рисунок 1.5 – Сторінки додатку «Hotel Ukraina»
1.3. Пошук методів та засобів для вирішення поставлених завдань
Створення мобільного Android-додатку, який виконує функції довідкової
системи для пошуку місць відпочинку в Україні, потребує вибору оптимальних
методів, технологій і підходів. Завданням цього підрозділу є обґрунтування
використаних засобів розробки та аналіз можливих альтернатив.
1.3.1. Вибір архітектурного підходу для мобільного додатку
У сучасній розробці Android-додатків пріоритетним є використання
архітектурних патернів, які забезпечують [1; 11]:
− розподіл відповідальностей;
21
ЧДТУ 252483.008 ПЗ
− просте тестування;
− масштабованість;
− легкість підтримки;
− можливість розширення функціональності.
Найпоширенішими архітектурними підходами є:
1. MVC (Model–View–Controller).
Історично перший підхід, який сьогодні майже не застосовується в Android
через надмірно навантажений контролер та складність підтримки великих проєктів.
2. MVP (Model–View–Presenter).
Популярний у минулому підхід, розвинувся у відповідь на недоліки MVC.
Проте Presenter з часом стає перевантаженим, і підхід втрачає актуальність.
3. MVVM (Model–View–ViewModel).
Наразі є стандартом де-факто в Android-розробці. Переваги:
− розділення UI та бізнес-логіки;
− реактивність через LiveData/StateFlow;
− відсутність прямої залежності View від Model;
− полегшені UI-тести;
− менше дублювання коду.
MVVM було обрано для розробки даного мобільного додатку, оскільки він
забезпечує стабільну, передбачувану та гнучку архітектуру, що відповідає сучасним
вимогам Android-додатків.
1.3.2. Вибір клієнт-серверної взаємодії
Для обміну інформацією між мобільним клієнтом і сервером
використовуються такі популярні підходи:
− REST API – найбільш поширений, легкий та універсальний підхід, що
використовує HTTP-протокол.
− GraphQL – більш гнучкий, але складніший у реалізації; використовується
переважно у великих комерційних сервісах із високою варіативністю даних.
22
ЧДТУ 252483.008 ПЗ
− gRPC – високошвидкісний RPC-протокол, який застосовують у
високонавантажених мікросервісах, але не є оптимальним для стандартних
мобільних каталогів.
Для реалізації серверної частини було обрано REST API [10], оскільки:
− він повністю відповідає задачам довідкової системи;
− є найпростішим для інтеграції в Android (через Retrofit);
− дозволяє легко документувати ендпоінти;
− забезпечує зрозумілу взаємодію з користувачем;
− повністю сумісний із OpenAPI.
1.3.3. Документування API через OpenAPI.yaml
OpenAPI – формат, який дозволяє описати структуру API:
− HTTP-методи;
− маршрути;
− параметри запитів;
− моделі даних;
− типи відповідей;
− коди помилок.
Переваги використання OpenAPI у цьому проєкті:
1. Автоматична генерація серверного коду на Spring Boot.
2. Генерація DTO та Retrofit-клієнтів для Android.
3. Зменшення кількості ручної роботи та помилок.
4. Єдина точка документації для всієї команди/проєкту.
1.3.4. Вибір технологій для бекенду
У сучасному серверному програмуванні для побудови REST-додатків
найефективнішими є такі фреймворки:
− Spring Boot (Java);
− Node.js + Express;
23
ЧДТУ 252483.008 ПЗ
− Django / FastAPI (Python);
− Go Fiber;
− ASP.NET Core.
Spring Boot було обрано через такі переваги:
− надійність та масштабованість;
− величезна екосистема;
− підтримка Spring Security для авторизації;
− готовність до інтеграції з PostgreSQL;
− безкоштовність та відкритість;
− підтримка OpenAPI через springdoc-openapi.
Ключові модулі, застосовані в роботі:
− Spring Web – для REST API;
− Spring Data JPA – для роботи з базою;
− Spring Security + JWT – для авторизації;
− Liquibase – для міграцій;
− ModelMapper або аналог – для конвертації моделей.
1.3.5. Вибір СКБД
Розглядалися такі системи управління базами даних:
Таблиця 1.1
СКБД Переваги Недоліки
MySQL швидка, популярна слабший синтаксис для
складних запитів
SQLite вбудована у Android, проста не підходить для
централізованих систем
надлишкова для
MongoDB гнучка структура структурованих
довідкових даних
PostgreSQL потужна, підтримує складні вимагає серверного
зв’язки, надійна оточення
PostgreSQL було обрано, оскільки додаток працює з чітко структурованими
сутностями.
24
ЧДТУ 252483.008 ПЗ
1.3.6. Технології та бібліотеки для Android [4; 5].
У розробці мобільного застосунку доцільно використовувати:
− Kotlin – сучасна мова Android;
− XML layout – для верстки;
− Retrofit – для роботи з REST API;
− Gson/Moshi – для серіалізації моделей;
− ViewModel + LiveData/StateFlow;
− Navigation Component;
− Coil/Glide – для зображень;
− RecyclerView – для списків.
Обраний технологічний стек забезпечує:
− швидкість розробки;
− читабельність коду;
− готовність до розширення;
− стандартність архітектури.
1.3.7. Підсумок підрозділу
Обрані методи та засоби забезпечують [2]:
− стабільну та масштабовану клієнт-серверну архітектуру;
− швидкий обмін даними між Android-додатком і бекендом;
− можливість подальшого розширення додатку;
− відповідність сучасним тенденціям мобільної індустрії.
1.4. Актуальні проблеми, що виникають при створенні інформаційних
мобільних систем
Розробка мобільних інформаційних систем, орієнтованих на каталогізацію та
надання довідкових даних, має ряд особливостей і викликів [2]. Ці проблеми
стосуються як мобільної частини, так і серверної інфраструктури, а також організації
контенту, масштабованості та забезпечення безпеки користувачів.
25
ЧДТУ 252483.008 ПЗ
1.4.1. Актуальність та достовірність інформації
Для довідкових систем, що містять інформацію про місця відпочинку, важливо
забезпечити:
− оперативне оновлення даних,
− достовірність інформації (адреси, графіки роботи, описи),
− відсутність застарілих даних, які можуть ввести користувача в оману.
Особливо це критично для культурних закладів, де програми, репертуари та
події змінюються часто. Системи без регулярного оновлення швидко втрачають
цінність.
1.4.2. Масштабованість і продуктивність
Навіть довідкова система може мати значне навантаження, якщо:
− кількість користувачів зросте;
− каталог локацій розшириться;
− будуть додані нові фільтри, категорії або атрибути;
− система почне обробляти зображення або інші медіа.
Проблеми масштабованості проявляються у:
− збільшенні часу відповіді сервера;
− зростанні навантаження на базу даних;
− складності кешування.
Бекенд повинен бути готовий до горизонтального та вертикального
масштабування. Використання Spring Boot у поєднанні з PostgreSQL допомагає
подолати ці виклики.
1.4.3. Проблеми з класифікацією даних та фільтрами
У мобільних довідкових системах важливо правильно організувати структуру
даних:
− визначити категорії локацій;
26
ЧДТУ 252483.008 ПЗ
− побудувати ієрархію міст → категорій → списків місць;
− забезпечити однозначність даних (наприклад, уникнути дублювання локацій).
Невдала структура каталогу призводить до:
− складності або повільності пошуку;
− незадоволення користувача через складну навігацію;
− поганої «знаходженості» об’єктів.
1.4.4. Забезпечення швидкодії мобільного інтерфейсу
Мобільний застосунок часто працює в умовах обмеженої продуктивності
пристроїв та нестабільного інтернет-з’єднання. Основні проблеми, які потрібно
враховувати:
− оптимізація списків (RecyclerView) при великій кількості елементів;
− використання кешування зображень (Coil/Glide);
− мінімізація кількості REST-запитів (наприклад, отримання даних по категоріях
пакетно);
− уникнення надмірної кількості анімацій;
− обробка помилок мережі.
UX також суттєво впливає на користувацький досвід. Навіть за ідеального
бекенду погано оптимізований UI зменшує задоволеність користувача [6].
1.4.5. Розмежування доступу і безпека
Додаток містить авторизацію, що автоматично накладає такі вимоги:
− безпечне зберігання токенів (SharedPreferences або
EncryptedSharedPreferences);
− шифрування конфіденційних даних;
− захист API через JWT;
− обмеження доступу до ендпоінтів, що управляють "Обраним".
Проблеми безпеки включають:
1. Перехоплення даних при незахищених запитах (HTTP → потрібно HTTPS)
27
ЧДТУ 252483.008 ПЗ
2. Уразливості, пов’язані з неправильним зберіганням токенів
3. Ін'єкції (SQL, JSON) на стороні сервера
4. XSS або CSRF для веб-частин (неактуально для Android, але актуально для
бекенду)
Spring Security та JWT токени дозволяють ефективно розв’язати ці проблеми.
1.4.6. Проблеми з інтеграцією зі сторонніми ресурсами
В даній системі не реалізовано покупки всередині додатку – користувач
переходить на зовнішнє посилання.
Можливі проблеми:
− сторонній сервіс може змінити URL;
− сервіс може бути недоступний;
− може змінитися модель інтеграції (параметри, токени).
Це потребує регулярного моніторингу актуальності зовнішніх посилань, що
також стосується готелів, театрів і кінотеатрів.
1.4.7. Уніфікація даних різних типів локацій
Оскільки додаток містить три категорії локацій:
1. готелі,
2. кінотеатри,
3. театри,
то проблемами стають:
− уніфікація описів;
− уніфікація структури зображень;
− стандартизація атрибутів;
− організація спільних полів та унікальних для кожної категорії.
Погано спроєктована модель даних згодом ускладнило б розвиток додатку.
28
ЧДТУ 252483.008 ПЗ
1.4.8. Забезпечення зручності користування (UX-проблеми)
Серед поширених UX-проблем в інформаційних мобільних системах:
− надто багато кроків для пошуку;
− занадто довгі списки, які не групуються;
− перевантажений інтерфейс;
− незрозумілі елементи навігації;
− повільне завантаження зображень;
− відсутність «Обраного».
Розроблений додаток вирішує ці проблеми завдяки:
− простому трирівневому фільтру (категорія → місто → список місць);
− особистому кабінету;
− оптимізованій структурі навігації;
− лаконічному UI.
До ключових проблем, які необхідно врахувати при створенні такої
інформаційної системи, належать:
− актуальність і повнота даних;
− швидкодія клієнта та сервера;
− оптимізація моделі даних;
− безпека та авторизація;
− уніфікація структури даних;
− зручність навігації;
− інтерактивність та стабільність роботи.
Проєктований мобільний додаток вирішує більшість цих проблем за рахунок
продуманої архітектури, сучасного технологічного стеку та структурованої моделі
даних.
29
ЧДТУ 252483.008 ПЗ
1.5. Конкретизація завдання магістерської роботи
Розробка мобільного Android-додатку для пошуку місць відпочинку в Україні є
багатокомпонентним завданням, яке включає проєктування інтерфейсу, побудову
серверної частини, формування бази даних, організацію взаємодії клієнта та сервера,
а також створення довідкової моделі для категоризації локацій. У цьому підрозділі
визначено конкретні задачі, які вирішуються в межах магістерської роботи, та
обґрунтовано їх необхідність.
1.5.1. Загальна мета розробки
Метою даної магістерської роботи є створення інформаційного мобільного
застосунку, який:
− надає користувачам структуровану та актуальну інформацію про місця
відпочинку в Україні;
− об’єднує готелі, кінотеатри та театри в одному зручному інтерфейсі;
− дозволяє здійснювати пошук по категоріях і містах;
− забезпечує перегляд детального опису кожного місця;
− дозволяє авторизованим користувачам додавати локації до «Обраного»;
− надає можливість переходу до зовнішніх ресурсів для бронювання чи купівлі
квитків.
Таким чином, додаток виступає єдиним інформаційним довідником
культурно-туристичних місць, доступних користувачам в Україні.
1.5.2. Постановка задачі для мобільного застосунку
Для досягнення мети необхідно реалізувати такі функції мобільного клієнта:
1. Реалізація механізму авторизації та аутентифікації
− вхід за email та паролем,
− отримання JWT-токена,
− безпечне зберігання токена на пристрої,
30
ЧДТУ 252483.008 ПЗ
− можливість перегляду особистого кабінету.
2. Каталогізація місць відпочинку
− три основні категорії: готелі, кінотеатри, театри;
− розподіл локацій по містах;
− формування списку доступних міст у межах вибраної категорії.
3. Пошук локацій по фільтрам
− вибір категорії → вибір міста → отримання списку локацій;
− оптимізація запитів до сервера з урахуванням архітектури та швидкодії.
4. Перегляд детальної інформації про місце
− опис, адреса, контактні дані, список додаткових атрибутів;
− зовнішнє посилання на сайт закладу.
5. Робота з обраними локаціями
− додавання/видалення місць у «Обране»;
− зберігання обраного на сервері, а не локально;
− перегляд обраних локацій у особистому кабінеті.
6. Інтеграція з серверною частиною (REST API)
− використання Retrofit;
− моделювання DTO-класів;
− обробка можливих помилок (timeout, no internet, server error).
1.5.3. Постановка задачі для бекенд-системи
Бекенд для Android-додатку виконує ключові функції, пов’язані зі зберіганням
даних, обробкою запитів і забезпеченням авторизації. Система повинна
підтримувати:
1. Реалізацію REST API згідно з OpenAPI.yaml
− автоматичну генерацію контролерів та моделей;
− впровадження валідації та обробки помилок;
− розмежування доступу за ролями.
2. Побудову бази даних PostgreSQL
31
ЧДТУ 252483.008 ПЗ
− проєктування таблиць для:
● користувачів,
● категорій,
● міст,
● локацій (готелі/театри/кінотеатри),
● обраних місць;
− визначення зв’язків між таблицями (One-to-Many, Many-to-Many).
3. Забезпечення безпеки системи
− використання Spring Security;
− реалізацію JWT-фільтрів;
− шифрування паролів через BCryptPasswordEncoder.
4. Організацію роботи з даними
− використання JPA-репозиторіїв;
− інкапсуляцію бізнес-логіки в сервісах;
− міграції через Liquibase.
5. Інтеграцію з мобільною частиною
− повернення даних у форматі JSON;
− підтримку коректних кодів відповідей (200, 201, 400, 401, 403, 404, 500);
− оптимізацію кількості запитів.
1.5.4. Функціональні вимоги до системи
Основні функції користувача:
− Перегляд каталогу місць відпочинку.
− Вибір категорії місця.
− Вибір міста.
− Перегляд списку локацій.
− Перегляд детальної інформації.
− Перехід за зовнішнім посиланням.
− Авторизація.
32
ЧДТУ 252483.008 ПЗ
− Додавання місць до «Обраного» (авторизованим користувачем).
− Перегляд списку обраних місць.
Адміністративні функції:
− додавання нових даних;
− оновлення інформації;
− видалення старих записів.
1.5.5. Нефункціональні вимоги [3].
1. Продуктивність:
− час відповіді сервера – не більше 200–300 мс;
− завантаження списку локацій – < 1 секунди при стабільному інтернеті.
2. Зручність користування [13]:
− інтерфейс повинен бути інтуїтивно зрозумілим;
− кількість кроків до знаходження об’єкта – мінімальна [13].
3. Надійність:
− система повинна коректно працювати при нестабільному інтернеті;
− сервіси мають автоматично відновлюватися після збою.
4. Безпека:
− використання HTTPS;
− стійке шифрування токенів;
− захист REST API.
5. Масштабованість:
− можливість розширення каталогу;
− можливість додавання нових категорій у майбутньому.
1.5.6. Програмна реалізація як результат магістерської роботи
Магістерська робота повинна включати:
− спроєктований та реалізований Android-додаток;
− бекенд-сервер, реалізований на Spring Boot [7];
33
ЧДТУ 252483.008 ПЗ
− документовані ендпоінти (OpenAPI.yaml) [8];
− підготовлену базу даних PostgreSQL [9];
− тестування ключових функцій [19];
− оформлені UML-діаграми, що описують систему;
− аналіз ефективності та обґрунтування вибору технологій.
1.5.7. Висновки щодо задачі
Таким чином, конкретизація завдання дозволяє системно визначити
функціонал мобільного додатку, структуру серверної частини, вимоги до бази даних
та архітектури програмного забезпечення. Це створює основу для побудови
подальших теоретичних і практичних розробок у наступних розділах.
1.6. Формулювання місця автора в розв’язанні задачі
Цей підрозділ визначає, який саме внесок виконав автор роботи у створення
інформаційної системи, які завдання були виконані самостійно, а які – використані в
готовому вигляді або на основі існуючих технологічних рішень. Згідно з вимогами
методичних вказівок, важливо чітко окреслити межі індивідуальної роботи та
частину, що була реалізована автором під час розробки мобільного застосунку та
серверної частини [12].
1.6.1. Внесок автора у концепцію та постановку завдання
Було сформувано:
− концепцію єдиного мобільного довідника культурно-туристичних локацій;
− підхід до структури навігації: категорія → місто → список місць;
− визначення основних функціональних вимог;
− постановку задачі перед системою both на клієнтському, і на серверному рівні;
− вибір сценаріїв взаємодії користувача із системою.
34
ЧДТУ 252483.008 ПЗ
Особливістю авторського бачення є відмова від комерційної функціональності
всередині додатку (бронювання, купівля квитків) та фокусування на довідковому
контенті – це принципово формує специфіку проєктованої архітектури.
1.6.2. Внесок автора у проєктування мобільного додатку
При проєктування мобільного додатку було виконано:
1. Проєктування структури інтерфейсу Android-додатку:
− головний екран;
− екран вибору категорій;
− екран вибору міста;
− екран списку локацій;
− екран детального перегляду місця;
− екран авторизації;
− особистий кабінет користувача.
2. Розробка макетів.
Було створено основні XML-файли інтерфейсу з дотриманням логіки
користувацького досвіду (UX), включаючи застосування [4]:
− ConstraintLayout;
− RecyclerView;
− Toolbar;
− поля вводу та кнопки;
− екрани порожнього стану.
3. Проєктування навігації.
Було визначено структуру переходів між екранами, що забезпечує інтуїтивну
взаємодію користувача з системою.
4. Реалізація архітектури MVVM [5].
Було побудувано ключові компоненти:
− ViewModel-и для кожного функціонального екрану;
− репозиторії для роботи з API;
35
ЧДТУ 252483.008 ПЗ
− data-класи для моделювання відповідей сервера;
− менеджер авторизації для роботи з JWT.
5. Інтеграція з REST API
Було виконано налаштування клієнта Retrofit, моделювання DTO та інтеграцію
всіх основних серверних ендпоінтів.
1.6.3. Внесок автора у розробку серверної частини
При розробці серверної частини було реалізовано:
1. Проєктування структури бази даних PostgreSQL:
− таблиці місць (локацій),
− таблиці міст,
− таблиці категорій,
− таблиці користувачів,
− зв’язувальні таблиці для «Обраного».
2. Роботу над OpenAPI-специфікацією.
Було підготував openapi.yaml, на основі якої здійснювалася генерація
контролерів та моделей.
3. Реалізацію CRUD-операцій.
Для основних сутностей — міста, категорії, локації, користувачі, обране.
4. Імплементацію Spring Security + JWT.
Включаючи:
− фільтри JWT;
− налаштування безпеки;
− ролі користувачів;
− захист POST-запитів на створення обраних місць.
5. Забезпечення взаємодії з мобільним застосунком.
Реалізувано логіку:
− формування відповідей;
− обробки виключень;
36
ЧДТУ 252483.008 ПЗ
− логування;
− налаштування CORS.
1.6.4. Внесок автора у дослідження аналогів та моделювання системи.
Під час роботи було:
− проведено аналіз п’яти мобільних додатків-аналогів;
− визначено сильні та слабкі сторони аналогів;
− обґрунтувано потребу в комплексному застосунку, який поєднує кілька типів
локацій;
− побудувано UML-діаграми, необхідні для структурного аналізу (Use Case,
Activity, Class, Sequence, Deployment).
1.6.5. Формування авторського бачення системи:
Було розроблено ключову концепцію додатку, яка полягає у:
− поєднанні різних типів локацій;
− поділі інформації по містах;
− мінімалістичній логіці пошуку;
− доступності довідкової інформації без зайвих дій;
− зручній роботі з «Обраним»;
− можливості швидкого переходу до зовнішніх сервісів.
Завдяки поєднанню цих ідей створено унікальний формат мобільного
довідника, який не має прямих аналогів на ринку.
1.7. Висновки до розділу 1
У першому розділі магістерської роботи було проведено всебічний
теоретичний та аналітичний огляд предметної області, технологій, підходів і
існуючих розв’язань, що мають відношення до створення мобільної інформаційної
системи для пошуку місць відпочинку в Україні.
37
ЧДТУ 252483.008 ПЗ
На основі аналізу наукової і технічної літератури встановлено, що
цифровізація туристичної та культурної сфер є одним із ключових напрямів розвитку
інформаційних технологій. Сучасні мобільні застосунки активно використовуються
як основне джерело інформації для користувачів, які шукають культурні події, місця
проживання та можливості дозвілля. Проте ринок не має єдиного рішення, яке
поєднувало б кілька типів локацій, зручні фільтри, роботу з особистим кабінетом і
функцію «Обране» у рамках одного додатку.
Було детально проаналізовано п’ять існуючих аналогів — Booking.com,
Multiplex, SmartCinema, Контрамарка та Hotel Ukraina. На основі порівняння
встановлено, що:
− кожен з них охоплює лише окремий сегмент ринку;
− жоден застосунок не об'єднує готелі, кінотеатри і театри;
− відсутні системи, які дозволяють здійснювати пошук виключно на довідковому
рівні без бронювання;
− користувачеві часто доводиться використовувати декілька окремих додатків,
що знижує зручність і швидкість взаємодії.
Таким чином, перший розділ формує основу для подальших досліджень та
розробки програмної системи. Він демонструє актуальність проєкту, обґрунтовує
його необхідність та показує комплексний підхід до розв’язання поставлених задач.
38
ЧДТУ 252483.008 ПЗ
2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ
2.1. Теоретичні основи побудови інформаційних мобільних систем
Створення інформаційних мобільних систем є однією з ключових тенденцій
сучасної індустрії програмного забезпечення. Такі системи виступають
інструментами, що забезпечують доступ до структурованої інформації, яка може
містити геодані, описи об’єктів, рейтинги, мультимедійні матеріали, параметри
фільтрації тощо. Зокрема, у сфері культурного та туристичного дозвілля мобільні
системи інтегрують довідковий контент з можливостями пошуку, персоналізації та
рекомендацій.
Сутність інформаційної мобільної системи полягає у забезпеченні
оперативного доступу до інформації, незалежно від місця та часу, за допомогою
смартфона чи планшета. Основними характеристиками таких систем є мобільність,
автономність, адаптивність та інтерактивність. Вони повинні працювати ефективно у
змінних умовах якості інтернет-з’єднання, обмежених ресурсах пристрою та
різноманітних сценаріях взаємодії користувача.
2.1.1. Архітектурні принципи побудови мобільних інформаційних систем
Мобільні додатки довідкового типу можуть будуватися на різних
архітектурних моделях [1]. Найпоширеніші:
1. Клієнт-серверна архітектура.
Класичний підхід, у якому мобільний додаток виступає клієнтом, а сервер –
постачальником даних.
Переваги:
− простота оновлення серверної частини;
− централізоване зберігання даних;
− можливість масштабування;
− незалежність клієнта від внутрішньої структури БД.
Недоліки:
39
ЧДТУ 252483.008 ПЗ
− залежність від якості мережі;
− необхідність адміністрування серверної інфраструктури.
2. Хмарні серверні рішення (Backend-as-a-Service).
Приклади: Firebase, Supabase.
Зменшують витрати на серверну частину, але мають обмеження в кастомізації
логіки.
3. Локальні гібридні системи.
Дані зберігаються частково на пристрої (кеш), частково – на сервері.
Це підвищує відмовостійкість, але ускладнює синхронізацію даних.
Для розроблюваної системи оптимальною є класична клієнт-серверна
архітектура.
2.1.2. Інформаційна модель мобільної системи
Інформаційна модель описує, які дані зберігає система та як вони пов’язані
між собою. Для задачі, що розглядається, ключовими елементами моделі є:
− Місто, у якому розташована локація;
− Локація – для кожної з категорій окрема сутність, що містить опис місця
відпочинку;
− Користувач – містить аутентифікаційні дані;
− Обране – зв’язок між користувачем і локацією.
Таким чином формується базова сутнісно-зв’язкова структура.
2.1.3. Принципи організації даних у довідкових системах
Теоретичною основою побудови інформаційних систем є:
1. Структурованість.
Дані повинні мати чітко визначені атрибути (назва, місто, опис, категорія,
URL).
2. Нормалізація.
40
ЧДТУ 252483.008 ПЗ
База даних має уникати дублювання інформації та забезпечувати логічність
побудови зв’язків.
3. Уніфікація формату даних.
Кожен об’єкт має мати однакову структуру незалежно від категорії.
У нашому проєкті це реалізується через універсальну модель Location, що має
базові поля:
− назва;
− опис;
− адреса;
− місто;
− категорія;
− зображення;
− зовнішнє посилання.
4. Мінімізація надлишковості.
Міста, категорії та користувачі зберігаються окремими таблицями.
5. Фільтрація і сортування.
Теоретично основою фільтрації є побудова SQL-запитів із параметрами
(city_id, category_id).
Це спрощує механізм пошуку.
2.1.4. Теоретичні аспекти REST-архітектури
REST (Representational State Transfer) – архітектурний стиль, що визначає
правила побудови клієнт-серверної взаємодії [10]. Основні принципи REST:
− клієнт-сервер – поділ відповідальності;
− безстанова взаємодія – кожен запит містить всю інформацію;
− кешування – оптимізація швидкості;
− уніфікований інтерфейс – стандартні HTTP-методи (GET, POST, PUT,
DELETE);
− ієрархічні ресурси – URL відображає структуру даних (/cities, /locations/{id});
41
ЧДТУ 252483.008 ПЗ
− підтримка різних форматів – у нашому проєкті використовується JSON.
Дотримання REST-стандартів забезпечує:
− зручність у підтримці;
− легкість інтеграції;
− масштабованість;
− можливість автоматичної генерації документації.
2.1.5. Моделювання користувацької взаємодії
Для довідкових систем ключовим є прогнозований і оптимізований шлях
користувача (user flow). Теоретично він визначається як мінімальна кількість
переходів до отримання результату.
Для нашої системи базовий користувацький шлях:
− Відкрити додаток;
− Вибрати категорію;
− Вибрати місто;
− Отримати список локацій;
− Перейти до детальної картки місця;
− За потреби додати до «Обраного» або перейти за зовнішнім посиланням.
2.1.6. Принципи забезпечення безпеки в мобільних системах
Безпека є важливою складовою теоретичних засад розробки будь-якої
інформаційної системи. Основні теоретичні аспекти:
1. Аутентифікація та авторизація.
У проєкті використовується JWT, що базується на криптографічних
алгоритмах.
2. Шифрування даних.
Рекомендовано використовувати HTTPS.
3. Захист локального сховища.
42
ЧДТУ 252483.008 ПЗ
На стороні мобільного клієнта токен зберігається у захищеному контейнері
(SharedPreferences або EncryptedSharedPreferences).
4. Логування і моніторинг.
Сервер повинен реєструвати всі важливі операції.
Теоретичні основи побудови інформаційних мобільних систем визначають:
− принципи організації даних,
− архітектури клієнт-серверної взаємодії,
− моделі користувацьких сценаріїв,
− вимоги до безпеки,
− підходи до фільтрації та структурування інформації.
Ці положення формують методологічний фундамент подальшої розробки
системи, яка буде розглянута в контексті практичної реалізації у наступних
підрозділах.
2.1.7. Теорія та гіпотеза дослідження
2.1.7.1. Теорія дослідження:
Android-додаток для пошуку місць відпочинку в Україні розробляється із
застосуванням сучасних технологій мобільної розробки та підходів до створення
інформаційних систем довідкового типу. Основна увага зосереджена на
використанні клієнт-серверної архітектури, що дозволяє забезпечити ефективну
взаємодію між мобільним застосунком та серверною частиною, а також
централізоване зберігання та обробку даних про місця відпочинку.
Теоретичну основу дослідження становлять принципи проєктування
мобільних інформаційних систем, методи організації та подання довідкової
інформації, а також підходи до забезпечення зручності використання
Android-додатків. Використання категоризації місць відпочинку (готелі, кінотеатри,
театри) та фільтрації за містами відповідає загальноприйнятим теоретичним
43
ЧДТУ 252483.008 ПЗ
моделям структурування інформації, орієнтованим на спрощення пошуку та
підвищення ефективності взаємодії користувача з системою.
Крім того, у межах теорії дослідження враховуються принципи побудови
RESTful-сервісів, що забезпечують стандартизований доступ до даних, а також
концепції користувацького досвіду, які передбачають мінімізацію кількості дій,
необхідних для отримання потрібної інформації, та забезпечення інтуїтивно
зрозумілого інтерфейсу мобільного застосунку.
2.1.7.2. Гіпотеза дослідження:
Експериментальна гіпотеза
«Розробка Android-додатку довідкового типу для пошуку місць відпочинку в
Україні на основі клієнт-серверної архітектури, з використанням сучасних
технологій мобільної та серверної розробки, сприятиме підвищенню зручності та
ефективності отримання користувачами інформації про культурні та туристичні
об’єкти, а також створить передумови для подальшого розвитку інформаційної
системи.»
Предметне визначення понять
Android-додаток для пошуку місць відпочинку.
Мобільний програмний продукт, призначений для перегляду довідкової
інформації про готелі, кінотеатри та театри з можливістю фільтрації за категоріями
та містами.
Клієнт-серверна архітектура.
Підхід до побудови інформаційної системи, за якого клієнтська частина
(Android-додаток) відповідає за взаємодію з користувачем, а серверна частина — за
обробку запитів, бізнес-логіку та доступ до бази даних.
Категоризація та фільтрація даних.
Механізм організації інформації про місця відпочинку, що передбачає поділ
об’єктів за типами та подальший відбір за географічною ознакою з метою
спрощення пошуку.
44
ЧДТУ 252483.008 ПЗ
Зручність використання мобільного застосунку.
Характеристика інформаційної системи, що визначає легкість навігації,
зрозумілість інтерфейсу та мінімальну кількість дій, необхідних користувачу для
отримання потрібної інформації.
Розвиток інформаційної системи.
Можливість подальшого розширення функціональних можливостей
Android-додатку, зокрема додавання нових категорій місць, міст або інтеграції з
зовнішніми сервісами без суттєвої перебудови архітектури.
2.1.8. Математичні моделі і формалізація задачі
Створення інформаційної мобільної системи для пошуку місць відпочинку в
Україні потребує формалізованого опису процесів, що забезпечують функціонування
системи. Математичні моделі дозволяють:
− формально визначити структуру даних;
− описати логіку фільтрації та пошуку;
− змоделювати взаємодію користувача з системою;
− визначити критерії ефективності роботи.
Наведемо теоретичні моделі, які відображають основні процеси у системі.
2.1.8.1 Формальна модель інформаційної структури
У загальному випадку система містить множину локацій:
L={l1,l2,...,ln} (2.1)
Кожна локація є структурованим об’єктом, що описується кортежем:
li=(uuidi, ci, mi, namei, desci, addri, urli, longi, lati, imgi) (2.2)
де:
− ���� – ідентифікатор локації;
��
− �� – категорія (hotel, cinema, theatre);
��
− �� – місто;
��
45
ЧДТУ 252483.008 ПЗ
− �������� – назва;
��
− �������� – опис;
��
− �������� – адреса;
��
− ������ – зовнішнє посилання;
��
− longi, lati – координати;
− imgi – посилання на зображення.
Категорії утворюють множину:
�� = {ℎ��������, ������������, ��ℎ����������} (2.3)
Міста:
�� = {�� , �� ,..., �� } (2.4)
1 2 ��
Таким чином, система є відображенням:
��: ��×��→2�� (2.5)
яке повертає множину локацій, що належать вибраній категорії і місту.
2.1.8.2. Математична модель фільтрації даних
Пошук локацій за категорією та містом описується як операція фільтрації:
Lfiltered ={l∈L∣c(l)=c∗, m(l)=m∗}, (2.6)
де:
с* – вибрана категорія,
m* – вибране місто.
Це відповідає SQL-запиту формату:
SELECT * FROM locations
WHERE category_id = c* AND city_id = m*;
Оскільки категорій і міст небагато, операція фільтрації має складність:
O(n), (2.7)
де n – кількість локацій.
Для оптимізації у практичній реалізації використовується індексація по полях
category_id та city_id, що дозволяє зменшити складність до:
46
ЧДТУ 252483.008 ПЗ
O(logn) (2.8)
2.1.8.3. Формальна модель авторизації
Процес авторизації користувача базується на криптографічній моделі JSON
Web Token (JWT).
Функція аутентифікації визначається як:
auth:U×P→T, (2.9)
де:
− U – множина користувачів;
− P – множина паролів;
− T – множина токенів, що видаються сервером.
Сервер виконує перевірку:
valid=check(u,p) (2.10)
Якщо умова істинна, то:
T=JWT(u) (2.11)
JWT-токен математично:
token=Base64(header)+Base64(payload)+HMAC(secret)
Цей токен зберігається в клієнті й надсилається у заголовках запитів.
2.1.8.4. Модель додавання до «Обраного».
Кожен користувач має множину обраних локацій:
Fu = {li1,li2,...,lim} (2.12)
Функція додавання до обраного визначається як:
add(li,u) : Fu = Fu ∪ {li} (2.13)
Функція видалення:
remove(li,u) : Fu = Fu ∖ {li} (2.14)
Залежно від реалізації, зв’язок між користувачем і локацією описується в базі
даних через таблицю:
47
ЧДТУ 252483.008 ПЗ
Favorites(user_id,location_id)
що відповідає моделі Many-to-Many.
2.1.8.5. Математична модель навігаційного графа.
Навігація у мобільному додатку може бути представлена як орієнтований граф:
G=(V,E), (2.15)
де:
− V – множина екранів;
− Е – множина переходів між екранами.
Набір вершин:
V={Home, Categories, Cities, LocationsList, LocationDetails, Login, Profile}
Переходи:
(Home → Categories), (Categories → Cities), (Cities → LocationsList), ...
Граф є орієнтованим, а шляхи є детермінованими.
Короткість шляху до інформації є ключовим фактором UX [13]:
path_length=|steps| (2.16)
У розробленій системі:
path_length=3 (2.17)
що відповідає оптимальній моделі «три кліки до результату».
2.1.8.6. Критерії ефективності системи [3].
Ефективність роботи можна формалізувати через такі критерії:
1. Час відповіді сервера:
Tresp ≤ 300 ms (2.18)
2. Час завантаження списку локацій:
Tload ≤ 1 s (2.19)
3. Продуктивність БД:
Оцінюється як середній час виконання запиту:
48
ЧДТУ 252483.008 ПЗ
��
�� = 1
�� ∑ ��(�� ) (2.20)
ⅆ�� ��
��=1
4. Надійність авторизації:
Ймовірність компрометації токена:
Pcompromise → 0 (2.21)
5. Кількість кроків до інформації:
steps ≤ 3, (2.22)
що є показником зручності.
2.2. Експериментальна оцінка та дослідження продуктивності системи
Експериментальна частина дослідження спрямована на перевірку
працездатності та ефективності розробленої інформаційної мобільної системи. У
цьому підрозділі описано методику проведення експериментів, середовище
тестування, сценарії використання та результати оцінки продуктивності клієнтської
та серверної частин.
2.2.1. Мета та завдання експериментальних досліджень
Метою експериментальних досліджень є підтвердження того, що розроблений
Android-додаток і серверна частина:
− коректно реалізують функціональні вимоги;
− забезпечують швидкий доступ до довідкової інформації;
− витримують типове навантаження користувачів;
− відповідають встановленим нефункціональним вимогам.
Основні завдання експерименту:
− виміряти час відповіді серверних ендпоінтів;
− оцінити швидкість завантаження списків локацій у мобільному застосунку;
− перевірити стабільність авторизації;
− оцінити швидкодію при роботі з «Обраним»;
49
ЧДТУ 252483.008 ПЗ
− перевірити коректність фільтрації за категоріями та містами.
2.2.2. Середовище проведення експериментів.
Серверна частина:
− Мова програмування: Java;
− Фреймворк: Spring Boot;
− СУБД: PostgreSQL;
− Протокол: HTTPS;
− Документування API: OpenAPI.yaml.
Клієнтська частина:
− Платформа: Android;
− Мова програмування: Kotlin;
− Верстка: XML;
− Архітектура: MVVM;
− Мережеві запити: Retrofit.
Тестові пристрої:
− Android-смартфон середнього класу (Android 11+);
− Android Emulator (Pixel-серія);
− Стабільне та нестабільне інтернет-з’єднання (Wi-Fi, Mobile LTE).
2.2.3. Методика тестування
Для оцінки ефективності системи застосовано такі методи [2]:
1. Функціональне тестування.
Перевірка відповідності реалізованого функціоналу вимогам.
2. Навантаження тестування (Load testing).
Імітація одночасних запитів до серверних ендпоінтів.
3. Тестування продуктивності.
Вимірювання часу відповіді та завантаження контенту.
4. Тестування стабільності.
50
ЧДТУ 252483.008 ПЗ
Перевірка коректної роботи при втраті мережі та повторному підключенні.
2.2.4. Сценарії експериментів
Сценарій 1. Отримання списку категорій:
− Тип запиту: [GET] /categories;
− Очікуваний результат: список з 3 категорій;
− Кількість запитів: 100;
− Середній час відповіді: ≤ 100 мс.
Сценарій 2. Отримання списку міст за категорією:
− Тип запиту: [GET] /cities?categoryId=X;
− Очікуваний результат: перелік міст;
− Середній час відповіді: ≤ 150 мс.
Сценарій 3. Отримання списку локацій;
− Тип запиту: [GET] /locations?categoryId=X&cityId=Y;
− Обсяг даних: 10–50 записів;
− Середній час відповіді: ≤ 250 мс.
Сценарій 4. Авторизація користувача:
− Тип запиту: [POST] /auth/login;
− Очікуваний результат: JWT-токен;
− Середній час відповіді: ≤ 200 мс.
Сценарій 5. Робота з «Обраним»:
− Додавання локації;
− Видалення локації;
− Отримання списку обраних;
− Середній час відповіді: ≤ 300 мс.
2.2.5. Аналіз отриманих результатів
Результати експериментів демонструють, що:
− система відповідає встановленим нефункціональним вимогам;
51
ЧДТУ 252483.008 ПЗ
− середній час відповіді сервера не перевищує допустимі значення;
− клієнтська частина працює стабільно на пристроях середнього класу;
− логіка фільтрації виконується коректно;
− авторизація і робота з «Обраним» реалізовані надійно.
Отримані показники свідчать про ефективність обраної архітектури та
технологічного стеку.
2.2.6. Обмеження експериментального дослідження.
Слід зазначити, що:
− тестування проводилося в умовах обмеженого навантаження;
− не враховано пікові сценарії з тисячами одночасних користувачів;
− не досліджувалась робота CDN для зображень.
Ці аспекти можуть бути розглянуті у подальших дослідженнях або при
комерційному впровадженні.
Експериментальні дослідження підтвердили працездатність і ефективність
розробленої системи. Показники продуктивності відповідають заданим вимогам, а
архітектура забезпечує стабільну роботу додатку при типових сценаріях
використання.
2.3. Висновки до розділу 2
У другому розділі магістерської роботи було проведено теоретичні та
експериментальні дослідження, спрямовані на обґрунтування архітектурних,
алгоритмічних і технологічних рішень для розробки Android-додатку з пошуку місць
відпочинку в Україні.
Було розглянуто теоретичні основи побудови інформаційних мобільних
систем. Проаналізовано сучасні архітектурні підходи до розробки мобільних
застосунків, визначено доцільність використання клієнт-серверної архітектури з
REST-взаємодією. Обґрунтовано принципи структуризації довідкової інформації,
формування інформаційної моделі та організації користувацьких сценаріїв. Значну
52
ЧДТУ 252483.008 ПЗ
увагу приділено питанням безпеки, зокрема використанню токен-базованої
авторизації.
Також виконано формалізацію задачі та побудову математичних моделей
основних процесів системи. Запропоновано формальні описи структури даних,
алгоритмів фільтрації локацій за категоріями та містами, механізмів авторизації
користувачів і роботи з обраними місцями. Також змодельовано навігаційну
структуру мобільного додатку у вигляді орієнтованого графа та визначено ключові
критерії ефективності системи.
На останок проведено експериментальну оцінку продуктивності та
стабільності розробленої системи. Описано середовище тестування, методику
проведення експериментів і типові сценарії використання. Отримані результати
підтвердили відповідність розробленого програмного забезпечення функціональним
і нефункціональним вимогам, зокрема щодо швидкодії, зручності використання та
надійності авторизації.
Узагальнюючи результати другого розділу, можна стверджувати, що обрані
теоретичні підходи, математичні моделі та практичні рішення є обґрунтованими і
створюють надійну основу для реалізації програмного продукту. Отримані висновки
дозволяють перейти до детального розгляду процесу проєктування та реалізації
Android-додатку, що буде здійснено у наступному розділі.
53
ЧДТУ 252483.008 ПЗ
3 ПРОЄКТУВАННЯ ТА РЕАЛІЗАЦІЯ ANDROID-ДОДАТКУ ДЛЯ
ПОШУКУ МІСЦЬ ВІДПОЧИНКУ В УКРАЇНІ
3.1. Загальна архітектура програмної системи
Проєктування програмної системи є критично важливим етапом розробки,
оскільки саме на цьому етапі визначається структура компонентів, спосіб їх
взаємодії, розподіл відповідальності та масштабованість рішення. Для реалізації
Android-додатку з пошуку місць відпочинку в Україні було обрано багаторівневу
клієнт-серверну архітектуру, яка забезпечує гнучкість, розширюваність і зручність
супроводу.
3.1.1. Загальний опис архітектури
Розроблювана система складається з таких основних компонентів:
1. Мобільний клієнт (Android-додаток).
Забезпечує взаємодію користувача з системою, відображення довідкової
інформації, навігацію між екранами, а також обробку подій користувача.
Рисунок 3.1 – Діаграма використання
54
ЧДТУ 252483.008 ПЗ
2. Серверна частина (Backend API).
Відповідає за зберігання, обробку та надання даних мобільному клієнту,
реалізує бізнес-логіку, авторизацію та доступ до бази даних.
3. База даних.
Призначена для збереження структурованої інформації про користувачів, місця
відпочинку, категорії, міста та обрані локації.
Взаємодія між компонентами здійснюється за допомогою REST API через
захищений протокол HTTPS.
Рисунок 3.2 – Діаграма розгортання
3.1.2. Клієнт-серверна взаємодія
Клієнт-серверна взаємодія побудована відповідно до принципів
REST-архітектури. Android-додаток виконує роль клієнта, який ініціює HTTP-запити
до серверної частини, а сервер повертає відповіді у форматі JSON.
Основні типи запитів:
− GET – отримання інформації (категорії, міста, локації);
− POST – авторизація користувача, додавання до обраного;
− PUT – оновлення інформації;
55
ЧДТУ 252483.008 ПЗ
− DELETE – видалення інформації.
Для захищених операцій в деяких запитах використовується токен JWT, який
передається в заголовку: Authorization: Bearer <token>.
3.1.3. Архітектура клієнтської частини
Android-додаток реалізований з використанням архітектурного патерну
MVVM (Model-View-ViewModel) [11], що дозволяє чітко розмежувати
відповідальність між компонентами та спростити тестування [4].
Компоненти MVVM:
− Model – класи даних, що відповідають JSON-моделям серверних відповідей;
− View – Activity та Fragment, які відповідають за відображення інтерфейсу;
− ViewModel – проміжний шар, що містить логіку обробки даних і взаємодії з
API.
Переваги використання MVVM:
− зменшення залежності між UI та логікою;
− зручність підтримки та масштабування;
− підвищення читабельності коду.
3.1.4. Серверна архітектура
Серверна частина реалізована на базі фреймворку Spring Boot, який
забезпечує:
− швидку конфігурацію REST-сервісів;
− інтеграцію з PostgreSQL;
− підтримку безпеки (Spring Security);
− зручну роботу з OpenAPI.
Архітектура серверної частини побудована за багатошаровою моделю [12]:
1. Controller layer.
Обробляє HTTP-запити та формує відповіді.
2. Service layer.
56
ЧДТУ 252483.008 ПЗ
Реалізує бізнес-логіку системи.
3. Repository layer.
Забезпечує доступ до бази даних через JPA.
4. Security layer.
Реалізує механізми авторизації та перевірки JWT.
Рисунок 3.3 – Діаграма послідовності отримання списку готелів
3.1.5. Документування API за допомогою OpenAPI.
Для формалізації та документування REST-ендпоінтів використовується файл
open-api.yaml, у якому описані:
− маршрути API;
− параметри запитів;
− структури відповідей;
− статус-коди.
На основі цього файлу здійснюється автоматична генерація частини
серверного коду, що зменшує кількість помилок і підвищує узгодженість між
клієнтом і сервером.
Нижче на рис. 3.3 зображено приклад документації руту для отримання списку
театрів.
57
ЧДТУ 252483.008 ПЗ
Рисунок 3.4 – Документація руту для отримання списку театрів
3.1.6. Потоки даних у системі.
Потік даних при типовому сценарії використання:
1. Користувач відкриває додаток.
2. Клієнт надсилає запит до API для отримання категорій.
3. Сервер звертається до бази даних.
4. Дані повертаються клієнту.
5. Користувач обирає категорію, місто.
6. Отримується список локацій.
7. За потреби виконується авторизація для роботи з «Обраним».
58
ЧДТУ 252483.008 ПЗ
Рисунок 3.5 – Діаграма активностей
3.2. Проєктування бази даних системи
База даних є центральним елементом серверної частини програмної системи,
оскільки саме вона забезпечує збереження, цілісність та доступність довідкової
інформації про місця відпочинку, а також даних про користувачів і їх персональні
налаштування. Для реалізації системи обрано реляційну систему керування базами
даних PostgreSQL, яка характеризується високою надійністю, продуктивністю та
підтримкою складних зв’язків між даними [9].
3.2.1. Вимоги до бази даних
До бази даних висувалися такі основні вимоги:
− зберігання інформації про місця відпочинку різних категорій;
59
ЧДТУ 252483.008 ПЗ
− підтримка фільтрації за категоріями та містами;
− забезпечення збереження користувацьких обраних локацій;
− підтримка механізму авторизації;
− забезпечення цілісності та узгодженості даних;
− можливість масштабування структури даних у майбутньому.
3.2.2. Концептуальна модель даних
Концептуальна модель даних базується на виділенні основних сутностей
предметної області:
− Користувач (User) – таблиця з користувачами;
− Місто (City) – таблиця з містами;
− Місце відпочинку (Location) – окремі таблиці з місцями кожної з категорій;
− Обране (Favorite) – окремі таблиці з обраними місцями кожної з категорій.
Між цими сутностями встановлено такі зв’язки:
− одне місто може містити багато локацій;
− один користувач може додати багато локацій до обраного;
− одна локація може бути додана до обраного багатьма користувачами.
60
ЧДТУ 252483.008 ПЗ
Рисунок 3.6 – Діаграма класів
3.2.3. Логічна структура бази даних
На основі концептуальної моделі сформовано логічну структуру бази даних,
що складається з кількох взаємопов’язаних таблиць.
Таблиця user – містить дані про зареєстрованих користувачів.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
− last_name – прізвище;
− first_name – ім’я;
− email – електронна пошта;
− password – хешований пароль;
− role – роль коростувача.
Таблиця city – містить дані про міста.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
61
ЧДТУ 252483.008 ПЗ
− name – назва міста;
− image_url – посилання на зображення.
Таблиця hotel – містить дані про готелі.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
− name – назва;
− address – адреса;
− latitude – широта;
− longitude – довгота;
− id_city – id міста;
− link – посилання на сторінку для бронювання;
− description – опис;
− image_url – посилання на зображення;
− phone_numbers – контактні номери телефону;
− email – контактна електронна пошта;
− services – перелічення послуг;
− meals_information – інформація про харчування;
− rooms_amount – кількість кімнат;
− min_price – мінімальна ціна.
Таблиця cinema – містить дані про кінотеатри.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
− name – назва;
− address – адреса;
− latitude – широта;
− longitude – довгота;
− id_city – id міста;
− link – посилання на сторінку для купівлі білетів;
62
ЧДТУ 252483.008 ПЗ
− description – опис;
− image_url – посилання на зображення;
− phone_numbers – контактні номери телефону.
Таблиця theater – містить дані про театри.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
− name – назва;
− address – адреса;
− latitude – широта;
− longitude – довгота;
− id_city – id міста;
− link – посилання на сторінку для купівлі білетів;
− description – опис;
− image_url – посилання на зображення;
− email – контактна електронна пошта;
− phone_numbers – контактні номери телефону.
Таблиця favourite_cinema – реалізує зв’язок «багато-до-багатьох» між
користувачами та обраними кінотеатрами.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
− id_user – id користувача;
− id_cinema – id обраного кінотеатра.
Таблиця favourite_hotel – реалізує зв’язок «багато-до-багатьох» між
користувачами та обраними готелями.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
− id_user – id користувача;
63
ЧДТУ 252483.008 ПЗ
− id_hotel – id обраного готеля.
Таблиця favourite_theater – реалізує зв’язок «багато-до-багатьох» між
користувачами та обраними театрами.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
− id_user – id користувача;
− id_theater – id обраного театра.
3.2.4. Забезпечення цілісності даних
Для підтримки цілісності використовуються:
− первинні та зовнішні ключі;
− обмеження NOT NULL;
− унікальні індекси для email користувачів;
− каскадне видалення у таблиці favorites.
Такі механізми дозволяють уникнути логічних помилок та неконсистентних
даних.
3.2.5. Оптимізація доступу до даних
Для підвищення продуктивності бази даних застосовуються:
− індексація поля user_id у таблиці favorites;
− оптимізація SQL-запитів для фільтрації.
Завдяки цьому середній час виконання запитів залишається в межах
допустимих значень.
3.2.6. Взаємодія з базою даних у Spring Boot
Доступ до бази даних реалізується за допомогою Spring Data JPA, що дозволяє:
− автоматично генерувати SQL-запити;
64
ЧДТУ 252483.008 ПЗ
− працювати з об’єктною моделлю;
− мінімізувати обсяг шаблонного коду.
Нижче на рис. 3.7 наведено приклад репозиторію, який використовується для
взаємодії з БД.
Рисунок 3.7 – Репозиторій кінотеатрів
3.3. Проєктування та реалізація серверної частини системи
Серверна частина системи відіграє ключову роль у забезпеченні
функціонування Android-додатку, оскільки саме вона відповідає за обробку запитів
клієнта, реалізацію бізнес-логіки, доступ до бази даних та забезпечення безпеки.
Для реалізації серверної частини використано фреймворк Spring Boot, який є
стандартом де-факто для створення RESTful вебсервісів на мові Java [7].
3.3.1. Загальна структура серверного застосунку
Серверний застосунок побудований за класичною багатошаровою
архітектурою, що забезпечує чіткий розподіл відповідальності між компонентами
[12]. Основні пакети серверного проєкту:
− controller – REST-контролери;
− service – бізнес-логіка;
− repository – доступ до бази даних;
− model – сутності бази даних;
65
ЧДТУ 252483.008 ПЗ
− security – компоненти безпеки та авторизації;
− config – конфігураційні файли.
Такий підхід забезпечує високу підтримуваність і розширюваність системи.
3.3.2. Реалізація REST-контролерів
REST-контролери відповідають за прийом HTTP-запитів і повернення
відповідей клієнту [10]. Кожен контролер обслуговує окрему групу ресурсів.
Основні контролери системи:
− контролер міст;
− контролер пошуку;
− контролери локацій (для кожної з категорій окремий контролер);
− контролер користувача;
− контролери обраних локацій (для кожної з категорій окремий контролер).
Для прикладу нижче показано контролер, який відповідає за роботу з
запитами, пов’язаними з готелями.
66
ЧДТУ 252483.008 ПЗ
Рисунок 3.8 – Контролер готелів
Контролери реалізують стандартні HTTP-методи:
− GET – отримання даних;
− POST – створення або обробка дій користувача;
− PUT – оновлення існуючих даних;
− DELETE – видалення з обраного.
3.3.3. Реалізація бізнес-логіки (Service layer)
Бізнес-логіка винесена в окремий шар сервісів, що дозволяє:
67
ЧДТУ 252483.008 ПЗ
− ізолювати контролери від логіки обробки даних;
− повторно використовувати функціонал;
− полегшити тестування.
Наприклад, сервіс локацій відповідає за:
− отримання списків локацій за категорією та містом;
− пошук локацій;
− підготовку DTO для відповіді клієнту.
Рисунок 3.9 – Сервіс пошуку
3.3.4. Робота з базою даних
Взаємодія з базою даних здійснюється через репозиторії Spring Data JPA, які
дозволяють описувати методи доступу до даних декларативно.
Типові запити:
− пошук локацій за uuid;
68
ЧДТУ 252483.008 ПЗ
− отримання списків;
− перевірка існування записів.
Такий підхід значно скорочує обсяг SQL-коду та зменшує ймовірність
помилок.
3.3.5. Реалізація механізму авторизації
Для забезпечення доступу до персоналізованих функцій реалізовано механізм
авторизації на основі JWT.
Основні етапи:
1. Користувач надсилає логін і пароль.
2. Сервер перевіряє коректність облікових даних.
3. У разі успіху генерується JWT-токен.
4. Токен передається клієнту та використовується для доступу до захищених
ресурсів.
Для реалізації безпеки використано Spring Security, який дозволяє:
− обмежувати доступ до ендпоінтів;
− перевіряти валідність токенів;
− захищати систему від несанкціонованого доступу.
3.3.6. Документування API за допомогою OpenAPI
REST-ендпоінти задокументовані за допомогою OpenAPI [8], що дозволяє:
− автоматично створювати документацію;
− генерувати клієнтські бібліотеки;
− зменшити кількість помилок у взаємодії клієнта і сервера.
Файл open-api.yaml містить:
− опис маршрутів;
− параметри запитів;
− схеми відповідей;
− коди помилок.
69
ЧДТУ 252483.008 ПЗ
3.3.7. Обробка помилок і винятків
Для коректної роботи системи реалізовано глобальний механізм обробки
винятків, який:
− перехоплює помилки;
− повертає зрозумілі повідомлення клієнту;
− забезпечує єдиний формат помилок.
Це покращує користувацький досвід і спрощує налагодження системи.
3.4. Реалізація клієнтської частини Android-додатку
Клієнтська частина системи реалізована у вигляді Android-додатку, який
забезпечує зручний доступ користувачів до довідкової інформації про місця
відпочинку в Україні. Основною метою клієнтської частини є відображення
структурованих даних, реалізація логіки пошуку та фільтрації, а також надання
персоналізованих можливостей авторизованим користувачам.
3.4.1. Загальна структура Android-додатку
Android-додаток розроблено з використанням мови програмування Kotlin та
XML-лейаутів. Проєкт має багатомодульну структуру, що сприяє зручності розробки
та супроводу.
Основні пакети клієнтського проєкту:
− view/fragment – екрани та фрагменти;
− viewmodel – ViewModel для кожного екрану (якщо необхідно);
− model – моделі даних;
− api – робота з REST API;
− adapter – адаптери для списків;
− repository – абстракція доступу до даних;
− utils – допоміжні класи.
70
ЧДТУ 252483.008 ПЗ
3.4.2. Реалізація навігації між екранами
Навігація між екранами реалізована з використанням Android Navigation
Component, що дозволяє:
− централізовано керувати переходами;
− передавати параметри між фрагментами;
− обробляти кнопку «Назад»;
− забезпечити узгоджену навігацію.
Основні екрани додатку:
− екран вибору категорії;
− екран вибору міста;
− екран списку локацій;
− екран детальної інформації про локацію;
− екран авторизації;
− особистий кабінет з обраними місцями.
71
ЧДТУ 252483.008 ПЗ
Рисунок 3.10 – Навігація в додатку
3.4.3. Реалізація логіки фільтрації
Логіка фільтрації побудована відповідно до послідовності дій користувача:
1. Вибір категорії місця.
2. Вибір міста.
3. Отримання списку відповідних локацій.
Після вибору параметрів клієнт надсилає запит до серверу з відповідними
параметрами фільтрації. Отриманий список локацій відображається у вигляді
прокручуваного списку.
72
ЧДТУ 252483.008 ПЗ
3.4.4. Відображення списків та деталей локацій
Для відображення списків використовується компонент RecyclerView, який
забезпечує:
− ефективне відображення великої кількості елементів;
− можливість повторного використання View;
− плавну прокрутку.
Картка локації містить:
− назву;
− зображення.
Екран детальної інформації містить:
− повний опис місця;
− основну інформацію;
− зовнішнє посилання;
− кнопку додавання до «Обраного» (для авторизованих користувачів).
3.4.5. Робота з «Обраним»
Функціонал «Обране» доступний лише авторизованим користувачам. Основні
можливості:
− додавання локації до обраного;
− перегляд списку обраних локацій;
− швидкий перехід до деталей локації;
− видалення з обраного.
При взаємодії з сервером використовується JWT-токен, який передається в
заголовку запиту.
73
ЧДТУ 252483.008 ПЗ
Рисунок 3.11 – Додавання/видалення обраного
3.4.6. Реалізація авторизації користувача
Для доступу до персоналізованих функцій реалізовано екран авторизації, який
дозволяє:
− вводити email і пароль;
− надсилати дані на сервер;
− обробляти успішну та неуспішну авторизацію;
− зберігати токен авторизації.
Токен зберігається у локальному сховищі та використовується для подальших
запитів.
74
ЧДТУ 252483.008 ПЗ
Рисунок 3.12 – Авторизація користувача
3.5. Тестування та налагодження програмної системи
Тестування є невід’ємною складовою процесу розробки програмного
забезпечення, оскільки дозволяє виявити помилки, перевірити відповідність
реалізації вимогам та оцінити якість функціонування системи. У межах даної
магістерської роботи тестування Android-додатку для пошуку місць відпочинку в
Україні проводилось на всіх етапах розробки.
75
ЧДТУ 252483.008 ПЗ
3.5.1. Мета та завдання тестування
Метою тестування є забезпечення коректної та стабільної роботи програмної
системи в різних умовах використання.
Основні завдання тестування:
− перевірка відповідності функціоналу технічному завданню;
− виявлення логічних і програмних помилок;
− оцінка стабільності клієнтської та серверної частин;
− перевірка коректності авторизації;
− тестування роботи з базою даних.
3.5.2. Види тестування
У процесі розробки було застосовано такі види тестування:
1. Функціональне тестування.
Перевірка реалізації основних функцій:
− перегляд категорій;
− фільтрація за містами;
− відображення списків локацій;
− перегляд детальної інформації;
− робота з «Обраним»;
− авторизація користувача.
2. Інтеграційне тестування.
Перевірка коректної взаємодії між:
− клієнтською та серверною частинами;
− сервером і базою даних;
− сервісами безпеки.
3. Тестування продуктивності.
Оцінка:
− часу відповіді серверних запитів;
76
ЧДТУ 252483.008 ПЗ
− швидкості завантаження даних у клієнтському додатку;
− стабільності роботи при багаторазових запитах.
4. Тестування надійності.
Перевірка роботи системи при:
− нестабільному інтернет-з’єднанні;
− втраті мережі;
− повторній авторизації;
− помилкових даних користувача.
3.5.3. Тестування серверної частини
Серверна частина тестувалась за допомогою:
− логування запитів;
− ручного тестування ендпоінтів;
− перевірки коректності відповідей API.
Перевірялись такі аспекти:
− коректність обробки HTTP-запитів;
− валідність JWT-токенів;
− контроль доступу до захищених ресурсів;
− стабільність роботи при паралельних запитах.
Рисунок 3.13 – Тестування серверної частини
77
ЧДТУ 252483.008 ПЗ
3.5.4. Тестування клієнтської частини
Клієнтський додаток тестувався на реальних пристроях і емуляторах. Основна
увага приділялась:
− коректності навігації між екранами;
− відображенню даних;
− обробці помилок;
− стабільності UI;
− правильності роботи з токенами.
Тестування проводилось у різних сценаріях використання, що дозволило
забезпечити надійну роботу додатку.
3.5.5. Виявлені проблеми та їх усунення
У процесі тестування було виявлено такі типові проблеми:
− затримки при першому завантаженні списків;
− некоректна обробка помилок мережі;
− повторні запити при швидких натисканнях.
Для усунення проблем:
− оптимізовано запити до бази даних;
− додано індикатори завантаження;
− впроваджено блокування повторних дій користувача.
Результати тестування підтвердили коректність роботи розробленої програмної
системи. Виявлені недоліки були усунуті на етапі налагодження, що забезпечило
стабільну, швидку та зручну роботу Android-додатку. Проведені тести засвідчили
готовність програмного продукту до практичного використання.
3.6. Висновки до розділу 3
У третьому розділі магістерської роботи було детально розглянуто процес
проєктування та реалізації Android-додатку для пошуку місць відпочинку в Україні.
78
ЧДТУ 252483.008 ПЗ
Описано архітектуру програмної системи, структуру бази даних, реалізацію
серверної та клієнтської частин, а також процес тестування і налагодження.
Застосування сучасних технологій, таких як Kotlin, Spring Boot, PostgreSQL та
OpenAPI, дозволило створити стабільний, масштабований та безпечний програмний
продукт. Реалізовані рішення повністю відповідають поставленим функціональним
вимогам і забезпечують зручний доступ користувачів до довідкової інформації про
місця відпочинку.
79
ЧДТУ 252483.008 ПЗ
4 ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
4.1. Мета та завдання тестування програмного забезпечення
Тестування програмного забезпечення є обов’язковим етапом життєвого циклу
програмного продукту, який спрямований на забезпечення його якості, надійності та
відповідності функціональним і нефункціональним вимогам. У межах даної
магістерської роботи тестування розглядається як системний процес перевірки
коректності роботи Android-додатку для пошуку місць відпочинку в Україні та його
серверної частини [19].
Основною метою тестування є виявлення помилок і недоліків у програмній
системі до її практичного використання, а також підтвердження того, що
розроблений програмний продукт коректно реалізує поставлені вимоги та забезпечує
стабільну роботу в реальних умовах експлуатації.
З огляду на те, що розроблений додаток має довідковий характер і передбачає
взаємодію клієнтської та серверної частин, процес тестування охоплює перевірку як
Android-клієнта, так і REST API серверної частини.
Основні цілі тестування
До основних цілей тестування програмного забезпечення в межах даного
дослідження належать:
− перевірка коректності реалізації функціональних можливостей додатку;
− забезпечення стабільної роботи клієнтської та серверної частин;
− перевірка правильності взаємодії між компонентами системи;
− виявлення та усунення помилок, що виникають під час виконання типових
сценаріїв використання;
− оцінка продуктивності та швидкодії системи;
− перевірка надійності механізмів авторизації та захисту даних.
Завдання тестування.
Для досягнення поставленої мети в процесі тестування було визначено такі
основні завдання:
80
ЧДТУ 252483.008 ПЗ
1. Перевірка функціональних вимог.
Забезпечити коректну роботу таких функцій:
− перегляд категорій місць відпочинку;
− вибір міста;
− фільтрація та відображення списку локацій;
− перегляд детальної інформації про місце;
− перехід за зовнішнім посиланням;
− додавання та видалення місць з «Обраного»;
− авторизація користувача.
2. Тестування взаємодії клієнта і сервера.
Перевірити коректність REST-запитів, формат відповідей сервера та обробку
помилок на стороні клієнта.
3. Перевірка коректності роботи з базою даних.
Переконатися у правильності збереження, оновлення та отримання даних з
бази даних PostgreSQL.
4. Оцінка продуктивності системи.
Виміряти час відповіді серверних ендпоінтів та швидкість завантаження даних
у клієнтському додатку.
5. Перевірка надійності та стабільності.
Оцінити поведінку системи при нестабільному інтернет-з’єднанні, повторних
запитах та помилкових діях користувача.
6. Перевірка механізмів безпеки.
Переконатися у правильності реалізації авторизації на основі JWT та
обмеження доступу до захищених функцій.
Об’єкт і предмет тестування.
Об’єктом тестування є програмна система, що складається з:
− Android-додатку для пошуку місць відпочинку;
− серверної частини, реалізованої за допомогою Spring Boot;
− бази даних PostgreSQL.
Предметом тестування є:
81
ЧДТУ 252483.008 ПЗ
− функціональні та нефункціональні характеристики програмного забезпечення;
− коректність реалізації бізнес-логіки;
− якість взаємодії між компонентами системи.
Роль тестування у забезпеченні якості ПЗ.
Тестування у даній роботі розглядається як інструмент забезпечення якості
програмного забезпечення, що дозволяє:
− мінімізувати кількість помилок;
− підвищити стабільність роботи додатку;
− забезпечити позитивний користувацький досвід;
− підготувати програмний продукт до практичного впровадження.
4.2. Тестування серверної частини системи
Серверна частина Android-додатку для пошуку місць відпочинку в Україні
реалізована на основі фреймворку Spring Boot і забезпечує обробку клієнтських
запитів, доступ до бази даних, реалізацію бізнес-логіки та механізмів авторизації.
Тестування серверної частини є критично важливим, оскільки від її стабільності та
коректності залежить робота всієї системи [19].
4.2.1. Мета тестування серверної частини
Метою тестування серверної частини є перевірка:
− коректності реалізації REST API;
− правильності обробки HTTP-запитів і відповідей;
− коректності роботи з базою даних PostgreSQL;
− надійності механізму авторизації;
− стабільності роботи при одночасних запитах.
82
ЧДТУ 252483.008 ПЗ
4.2.2. Тестування REST-ендпоінтів
Ключовим аспектом тестування серверної частини є перевірка
REST-ендпоінтів, що забезпечують взаємодію з клієнтським додатком.
Тестування отримання списку міст.
− Тип запиту: GET
− Параметри: відсутні.
− Очікуваний результат: список міст.
− Фактичний результат: відповідь сервера відповідає вимогам.
Рисунок 4.1 – Тестування запиту отримання списку міст
Тестування отримання списку локацій.
− Тип запиту: GET
83
ЧДТУ 252483.008 ПЗ
− Параметри: ідентифікатор міста
− Очікуваний результат: перелік відповідних локацій
− Фактичний результат: дані повертаються коректно.
Рисунок 4.2 – Тестування отримання списку театрів
4.2.3. Тестування механізму авторизації
Окрему увагу було приділено тестуванню механізму авторизації на основі
JWT.
Перевірялися такі сценарії:
− авторизація з коректними обліковими даними;
− авторизація з некоректними даними;
− доступ до захищених ендпоінтів без токена;
84
ЧДТУ 252483.008 ПЗ
− доступ до захищених ендпоінтів з простроченим токеном.
У результаті тестування підтверджено, що:
− токени генеруються коректно;
− неавторизований доступ блокується;
− помилки авторизації обробляються коректно.
Рисунок 4.3 – Тестування авторизації
4.2.4. Тестування роботи з базою даних
Тестування роботи з базою даних включало перевірку:
− коректності збереження даних;
− правильності вибірок;
− коректності зв’язків між таблицями;
− обробки випадків відсутності даних.
85
ЧДТУ 252483.008 ПЗ
Особлива увага приділялася таблиці «обраних локацій», оскільки вона реалізує
зв’язок між користувачами та локаціями.
4.2.5. Тестування обробки помилок
Також особливу увагу при тестуванні необхідно приділяти тестуванню
обробки помилок, оскільки це дозволяє перевірити правильність її реалізації.
Для цього перевірялися такі сценарії:
− передача некоректних параметрів;
− відсутність обов’язкових параметрів;
− звернення до неіснуючих ресурсів.
Сервер коректно повертав повідомлення про помилки з відповідними
HTTP-кодами, що забезпечує коректну обробку помилок на стороні клієнта.
Проведені тести підтвердили коректність реалізації REST API, стабільну
роботу механізмів авторизації та правильну взаємодію з базою даних. Серверна
частина відповідає встановленим вимогам і забезпечує надійну роботу мобільного
додатку.
4.3. Тестування клієнтської частини Android-додатку
Клієнтська частина Android-додатку є основним інтерфейсом взаємодії
користувача з програмною системою, тому її тестування має на меті перевірку
коректності відображення інформації, зручності навігації та стабільності роботи у
різних сценаріях використання [19]. У межах даної магістерської роботи тестування
клієнтської частини проводилося з урахуванням особливостей мобільної платформи
Android.
4.3.1. Мета тестування клієнтської частини
Метою тестування клієнтської частини є:
− перевірка коректності роботи користувацького інтерфейсу;
86
ЧДТУ 252483.008 ПЗ
− забезпечення правильного відображення довідкової інформації;
− перевірка навігації між екранами;
− оцінка стабільності додатку;
− перевірка коректності взаємодії з серверною частиною.
4.3.2. Тестування навігації та користувацьких сценаріїв
Перевірялися основні сценарії використання додатку:
− запуск додатку та відображення стартового екрану;
− вибір категорії місця відпочинку;
− вибір міста;
− перегляд списку локацій;
− перехід до детальної інформації;
− повернення до попередніх екранів.
Усі переходи між екранами відбувалися коректно, без помилок або зависань.
4.3.3. Тестування відображення даних
Тестування відображення даних
Особливу увагу було приділено перевірці коректності відображення даних:
− назв локацій;
− зображень;
− зовнішніх посилань.
Перевірялося також відображення порожніх списків і повідомлень про
відсутність даних.
4.3.4. Тестування функціоналу «Обране»
Функціонал «Обране» тестувався лише для авторизованих користувачів.
Перевірялися такі сценарії:
− додавання локації до обраного;
87
ЧДТУ 252483.008 ПЗ
− відображення списку обраних локацій;
− перехід до детальної інформації;
− видалення локації з обраного.
У результаті тестування підтверджено коректну роботу всіх операцій з
обраними локаціями.
4.3.5. Тестування авторизації користувача
Тестування авторизації включало:
− перевірку введення коректних облікових даних;
− перевірку обробки помилкових даних;
− збереження токена авторизації;
− повторний вхід користувача.
Механізм авторизації працює стабільно та забезпечує доступ до
персоналізованих функцій.
4.3.6. Тестування стабільності та обробки помилок
Перевірялися такі сценарії:
− втрата інтернет-з’єднання;
− повторне підключення до мережі;
− спроби виконання дій без авторизації;
− швидкі повторні натискання на елементи інтерфейсу.
Додаток коректно обробляє зазначені ситуації та не завершується аварійно.
Проведені тести підтвердили коректність роботи інтерфейсу, стабільність
навігації, правильне відображення даних і надійну взаємодію з серверною частиною
системи.
88
ЧДТУ 252483.008 ПЗ
4.4. Тестування продуктивності та надійності програмного забезпечення
Тестування продуктивності та надійності є важливим етапом оцінювання
якості програмного забезпечення, оскільки дозволяє визначити здатність системи
стабільно працювати в умовах реального використання. Для Android-додатку з
пошуку місць відпочинку в Україні такі характеристики є особливо важливими,
оскільки користувачі очікують швидкого доступу до інформації та безперебійної
роботи додатку.
4.4.1. Мета тестування продуктивності та надійності
Основною метою тестування продуктивності та надійності є:
− оцінка швидкодії клієнтської та серверної частин;
− визначення часу відповіді серверних ендпоінтів;
− перевірка стабільності роботи додатку при багаторазових запитах;
− оцінка поведінки системи при несприятливих умовах.
4.4.2. Тестування продуктивності серверної частини
Тестування продуктивності серверної частини проводилося шляхом
багаторазового виконання типових REST-запитів:
− отримання списку категорій;
− отримання списку міст;
− отримання списку локацій;
− отримання обраних локацій користувача.
У процесі тестування оцінювався:
− середній час відповіді;
− стабільність обробки запитів;
− відсутність помилок при навантаженні.
Результати показали, що серверна частина забезпечує стабільну обробку
запитів у межах допустимих часових показників.
89
ЧДТУ 252483.008 ПЗ
4.4.3. Тестування продуктивності клієнтської частини
Продуктивність клієнтської частини оцінювалася за такими показниками:
− час запуску додатку;
− швидкість завантаження списків локацій;
− плавність навігації між екранами.
Тестування показало, що Android-додаток швидко реагує на дії користувача та
забезпечує комфортний користувацький досвід.
4.4.4. Тестування надійності
Тестування надійності включало перевірку стабільності роботи додатку в
умовах:
− нестабільного інтернет-з’єднання;
− повторних запитів до сервера;
− тривалого використання додатку;
− помилкових дій користувача.
Усі зазначені сценарії були коректно оброблені, що свідчить про високу
надійність програмного продукту.
4.4.5. Тестування безпеки
У межах тестування безпеки перевірялися:
− захист доступу до персональних даних;
− коректність роботи авторизації;
− обмеження доступу до захищених функцій.
Результати тестування підтвердили коректність реалізації базових механізмів
безпеки [19]. Отримані результати підтвердили, що розроблена система забезпечує
швидку реакцію, стабільну роботу та відповідає вимогам до якості мобільних
додатків.
90
ЧДТУ 252483.008 ПЗ
4.5. Аналіз результатів тестування
Проведене тестування Android-додатку для пошуку місць відпочинку в Україні
дозволило комплексно оцінити якість програмного забезпечення та ступінь
відповідності реалізованого функціоналу поставленим вимогам. Аналіз результатів
тестування здійснювався на основі отриманих даних під час модульного,
інтеграційного, системного та нефункціонального тестування.
4.5.1. Аналіз результатів функціонального тестування
Результати функціонального тестування свідчать про коректну реалізацію
основних функцій програмного продукту. Зокрема, підтверджено:
− правильність вибору категорій місць відпочинку;
− коректну фільтрацію локацій за містами;
− стабільне відображення списків та детальної інформації;
− коректну роботу функціоналу «Обране»;
− надійну реалізацію авторизації користувача.
Виявлені незначні недоліки мали косметичний характер і були усунені в
процесі доопрацювання додатку.
4.5.2. Аналіз результатів інтеграційного тестування
Інтеграційне тестування підтвердило коректну взаємодію між клієнтською та
серверною частинами системи. REST API забезпечує стабільний обмін даними у
форматі JSON, а клієнтський додаток коректно обробляє отримані відповіді.
Проблем, пов’язаних із передачею даних, втратами інформації або
некоректною обробкою помилок, у процесі тестування не виявлено.
4.5.3. Аналіз результатів тестування продуктивності
Результати тестування продуктивності показали, що:
91
ЧДТУ 252483.008 ПЗ
− середній час відповіді сервера знаходиться в межах допустимих значень;
− завантаження списків локацій відбувається без затримок;
− навігація між екранами клієнтського додатку є плавною.
Це свідчить про оптимальну архітектуру системи та ефективну реалізацію
бізнес-логіки.
4.5.4. Аналіз результатів тестування надійності та безпеки
Тестування надійності підтвердило стабільну роботу додатку в умовах
нестабільного мережевого з’єднання та при багаторазових запитах. Додаток
коректно обробляє помилкові дії користувача та не завершується аварійно.
Результати тестування безпеки підтвердили коректність реалізації механізмів
авторизації та обмеження доступу до захищених функцій.
4.5.5. Загальна оцінка якості програмного забезпечення
На основі проведеного тестування можна зробити висновок, що розроблений
Android-додаток відповідає вимогам до функціональності, надійності та зручності
використання. Програмний продукт готовий до практичного використання та
подальшого розвитку.
4.6. Висновки до розділу 4
У розділі 4 було розглянуто процес тестування програмного забезпечення
Android-додатку для пошуку місць відпочинку в Україні. Проведено аналіз видів і
рівнів тестування, перевірено роботу серверної та клієнтської частин, а також
оцінено продуктивність, надійність і безпеку системи.
Результати тестування підтвердили, що програмний продукт є стабільним,
функціонально повним і відповідає вимогам, визначеним на етапі проєктування.
Реалізовані механізми тестування забезпечують високу якість програмного
забезпечення та можливість його подальшого вдосконалення.
92
ЧДТУ 252483.008 ПЗ
93
ЧДТУ 252483.008 ПЗ
ВИСНОВКИ
У магістерській роботі було розглянуто процес проєктування, розробки та
тестування Android-додатку для пошуку місць відпочинку в Україні. Актуальність
обраної теми зумовлена зростанням попиту на мобільні інформаційні сервіси,
орієнтовані на внутрішній туризм, культурний відпочинок та швидкий доступ до
довідкової інформації про різноманітні локації.
У першому розділі виконано аналіз предметної області та досліджено
сучасний стан ринку мобільних додатків для пошуку місць відпочинку. Розглянуто
функціональні можливості існуючих аналогів, зокрема таких Android-додатків, як
Multiplex, Booking.com, SmartCinema, Контрамарка та Hotel Ukraina. Проведений
аналіз дозволив визначити їх переваги та недоліки, а також сформувати перелік
вимог до розроблюваного програмного продукту. Встановлено, що більшість
існуючих рішень орієнтовані на окремі типи локацій або комерційні операції, що
обґрунтовує доцільність створення універсального довідкового сервісу.
У другому розділі виконано проєктування архітектури програмної системи.
Визначено загальну структуру клієнт-серверної взаємодії, обґрунтовано вибір
технологій та інструментів розробки. Клієнтська частина реалізована у вигляді
Android-додатку з використанням мови програмування Kotlin та XML-лейаутів,
серверна частина — на основі фреймворку Spring Boot з використанням OpenAPI
для опису REST-ендпоінтів. Для зберігання даних обрано систему керування базами
даних PostgreSQL. Проєктування передбачає поділ місць відпочинку за категоріями
та містами, що спрощує навігацію і пошук інформації.
У третьому розділі описано процес реалізації програмного забезпечення.
Розглянуто основні функціональні можливості Android-додатку, зокрема перегляд
списків локацій, відображення детальної інформації, роботу з категоріями та
містами, реалізацію авторизації користувача та функціоналу «Обране». Особливу
увагу приділено взаємодії клієнтської та серверної частин, а також реалізації
безпечного доступу до персоналізованих функцій. Додаток не передбачає здійснення
94
ЧДТУ 252483.008 ПЗ
купівлі чи бронювання безпосередньо в системі, а забезпечує перехід до зовнішніх
сервісів, що відповідає поставленій меті довідкового ресурсу.
У четвертому розділі проведено комплексне тестування програмного
забезпечення. Розглянуто види та рівні тестування, виконано перевірку серверної і
клієнтської частин, а також оцінено продуктивність, надійність і безпеку системи.
Результати тестування підтвердили коректність реалізації функціональних
можливостей, стабільну роботу додатку та відповідність програмного продукту
вимогам якості.
У результаті виконання магістерської роботи досягнуто поставленої мети –
розроблено Android-додаток для пошуку місць відпочинку в Україні, який забезпечує
користувачів зручною та структурованою довідковою інформацією про готелі,
кінотеатри та театри. Розроблений програмний продукт може бути використаний
туристами, студентами, молоддю та всіма, хто зацікавлений у пошуку культурного та
рекреаційного відпочинку.
Практичне значення роботи полягає у можливості подальшого розвитку
системи, зокрема розширення переліку категорій локацій, інтеграції додаткових
інформаційних сервісів та впровадження нових функціональних можливостей.
95
ЧДТУ 252483.008 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Sommerville I. Software engineering. 10th ed. Boston : Pearson Education, 2016.
816 p. (дата звернення: 16.09.2025).
2. Pressman R. S., Maxim B. R. Software engineering: a practitioner’s approach.
9th ed. New York : McGraw-Hill Education, 2020. 976 p. (дата звернення:
20.09.2025).
3. Systems and software engineering – Systems and software Quality Requirements
and Evaluation (SQuaRE) – System and software quality models. (дата
звернення: 06.12.2025).
4. Документація Android Developers [Електронний ресурс]. URL:
https://developer.android.com (дата звернення: 22.11.2025).
5. Документація Kotlin Programming Language [Електронний ресурс]. URL:
https://kotlinlang.org/docs/home.html (дата звернення: 23.11.2025).
6. Рекомендації по роботі з Material Design [Електронний ресурс]. URL:
https://m3.material.io (дата звернення: 23.11.2025).
7. Документація Spring Boot [Електронний ресурс]. URL:
https://docs.spring.io/spring-boot/docs/current/reference/html/ (дата звернення:
20.10.2025).
8. Специфікації OpenAPI [Електронний ресурс]. URL:
https://swagger.io/specification/ (дата звернення: 20.10.2025).
9. Документація PostgreSQL [Електронний ресурс]. URL:
https://www.postgresql.org/docs/ (дата звернення: 20.10.2025).
10. Fielding R. T. Architectural styles and the design of network-based software
architectures (дата звернення: 01.11.2025).
11. Gamma E., Helm R., Johnson R., Vlissides J. Design patterns: elements of
reusable object-oriented software. Boston : Addison-Wesley, 1994. (дата
звернення: 02.11.2025).
12. Fowler M. Patterns of enterprise application architecture. Boston :
Addison-Wesley, 2003. (дата звернення: 26.10.2025).
96
ЧДТУ 252483.008 ПЗ
13. Nielsen J. Usability engineering. San Diego : Academic Press, 1994. (дата
звернення: 29.11.2025).
14. Android-додаток «Booking.com» [Електронний ресурс]. URL:
https://play.google.com/store/apps/details?id=com.booking (дата звернення:
25.09.2025).
15. Android-додаток «Multiplex» [Електронний ресурс]. URL:
https://play.google.com/store/apps/details?id=com.multiplex (дата звернення:
25.09.2025).
16. Android-додаток «SmartCinema» [Електронний ресурс]. URL:
https://play.google.com/store/apps/details?id=ua.smartcinema (дата звернення:
25.09.2025).
17. Android-додаток «Контрамарка» [Електронний ресурс]. URL:
https://play.google.com/store/apps/details?id=com.kontramarka (дата звернення:
25.09.2025).
18. Android-додаток «Hotel Ukraina» [Електронний ресурс]. URL:
https://play.google.com/store/apps/details?id=com.loyaltyplant.partner.hotelukrai
na (дата звернення: 25.09.2025).
19. Myers G. J., Sandler C., Badgett T. The art of software testing. 3rd ed. Hoboken
: Wiley, 2011. (дата звернення: 03.12.2025).
97
ЧДТУ 252483.008 ПЗ
ДОДАТОК А
Затверджую
Зав. кафедри ПЗАС,
______________ Сергій ГОЛУБ
«____»____________2025 р.
ANDROID-ДОДАТОК ДЛЯ ПОШУКУ МІСЦЬ ВІДПОЧИНКУ В УКРАЇНІ
Специфікація
482.ЧДТУ.252483 ПЗ
Листів 2
Розробник ____________________ Кавун Д.Р.
Керівник ____________________ Олексюк В.В.
Черкаси – 2025
98
ЧДТУ 252483.008 ПЗ
482.ЧДТУ. 42291-01
Позначення Найменування Примітка
482.ЧДТУ.252483 1201 Лістинг програми
482.ЧДТУ.252483 9001 Графічні матеріали
99
ЧДТУ 252483.008 ПЗ
ДОДАТОК Б
ANDROID-ДОДАТОК ДЛЯ ПОШУКУ МІСЦЬ ВІДПОЧИНКУ В УКРАЇНІ
ТЕКСТ ПРОГРАМИ
482.ЧДТУ.252483 1201
Листів 27
Розробник _____________ Кавун Д.Р.
Черкаси – 2025
100
ЧДТУ 252483.008 ПЗ
Фрагмент програми
Клас UserController:
@RestController
@CrossOrigin(origins = "http://localhost:3000")
@RequiredArgsConstructor
public class UserController implements UserApi {
private final UserService userService;
@Override
public UserDto addUser(UserDto userDto) {
return userService.add(userDto);
}
@Override
@PreAuthorize("hasAnyAuthority('ADMIN')")
public Void deleteUserByUuid(String uuid) {
userService.delete(uuid);
return null;
}
@Override
public UserDto getUserByEmail(String email) {
return userService.getByEmail(email);
}
@Override
public UserDto getUserByUuid(String uuid) {
return userService.get(uuid);
}
@Override
@PreAuthorize("hasAnyAuthority('ADMIN')")
public List<UserDto> getUsers(Integer page, Integer limit) {
return userService.getAllPages(page, limit);
}
@Override
public JwtDto login(UserDto userDto) {
return userService.login(userDto);
}
@Override
public UserDto updateUser(String uuid, UserDto userDto) {
return userService.updateByUuid(uuid, userDto);
}
@Override
@PreAuthorize("hasAnyAuthority('ADMIN')")
public List<UserDto> usersAllGet() {
return userService.getAll();
}
}
Клас HotelController:
@RestController
@CrossOrigin
101
ЧДТУ 252483.008 ПЗ
@RequiredArgsConstructor
public class HotelController implements HotelApi {
private final HotelService hotelService;
@Override
@PreAuthorize("hasAnyAuthority('ADMIN')")
public HotelDto addHotel(HotelDto hotelDto) {
return hotelService.add(hotelDto);
}
@Override
@PreAuthorize("hasAnyAuthority('ADMIN')")
public Void deleteHotelByUuid(String uuid) {
hotelService.delete(uuid);
return null;
}
@Override
public HotelDto getHotelByUuid(String uuid) {
return hotelService.getByUuid(uuid);
}
@Override
public List<HotelDto> getHotels(Integer page, Integer limit) {
return hotelService.getHotels(page, limit);
}
@Override
public List<HotelDto> getAllHotelsByCityUuid(String uuid) {
return hotelService.getAllHotelsByCityUuid(uuid);
}
@Override
public List<HotelDto> getAllHotelsInDB() {
return hotelService.getAllHotelsInDB();
}
@Override
public List<HotelDto> getHotelsByCityUuid(String uuid, Integer page, Integer limit) {
return hotelService.getHotelsByCityUuid(uuid, page, limit);
}
@Override
@PreAuthorize("hasAnyAuthority('ADMIN')")
public HotelDto updateHotelByUuid(String uuid, HotelDto hotelDto) {
return hotelService.update(uuid, hotelDto);
}
}
Клас TheaterController:
@RestController
@CrossOrigin
@RequiredArgsConstructor
public class TheaterController implements TheaterApi {
private final TheaterService theaterService;
@Override
@PreAuthorize("hasAnyAuthority('ADMIN')")
102
ЧДТУ 252483.008 ПЗ
public TheaterDto addTheater(TheaterDto theaterDto) {
return theaterService.add(theaterDto);
}
@Override
@PreAuthorize("hasAnyAuthority('ADMIN')")
public Void deleteTheaterByUuid(String uuid) {
theaterService.delete(uuid);
return null;
}
@Override
public List<TheaterDto> getAllTheatersByCityUuid(String uuid) {
return theaterService.getAllTheatersByCityUuid(uuid);
}
@Override
public List<TheaterDto> getAllTheatersInDB() {
return theaterService.getAllTheatersInDB();
}
@Override
public TheaterDto getTheaterByUuid(String uuid) {
return theaterService.getByUuid(uuid);
}
@Override
public List<TheaterDto> getTheaters(Integer page, Integer limit) {
return theaterService.getTheaters(page, limit);
}
@Override
public List<TheaterDto> getTheatersByCityUuid(String uuid, Integer page, Integer limit)
{
return theaterService.getTheatersByCityUuid(uuid, page, limit);
}
@Override
@PreAuthorize("hasAnyAuthority('ADMIN')")
public TheaterDto updateTheaterByUuid(String uuid, TheaterDto theaterDto) {
return theaterService.update(uuid, theaterDto);
}
}
Клас CinemaController:
@RestController
@CrossOrigin
@RequiredArgsConstructor
public class CinemaController implements CinemaApi {
private final CinemaService cinemaService;
@Override
@PreAuthorize("hasAnyAuthority('ADMIN')")
public CinemaDto addCinema(CinemaDto cinemaDto) {
return cinemaService.add(cinemaDto);
}
@Override
103
ЧДТУ 252483.008 ПЗ
@PreAuthorize("hasAnyAuthority('ADMIN')")
public Void deleteCinemaByUuid(String uuid) {
cinemaService.delete(uuid);
return null;
}
@Override
public List<CinemaDto> getAllCinemasByCityUuid(String uuid) {
return cinemaService.getAllCinemasByCityUuid(uuid);
}
@Override
public List<CinemaDto> getAllCinemasInDB() throws Exception {
return cinemaService.getAllCinemasInDB();
}
@Override
public CinemaDto getCinemaByUuid(String uuid) {
return cinemaService.getByUuid(uuid);
}
@Override
public List<CinemaDto> getCinemas(Integer page, Integer limit) {
return cinemaService.getCinemas(page, limit);
}
@Override
public List<CinemaDto> getCinemasByCityUuid(String uuid, Integer page, Integer limit) {
return cinemaService.getCinemasByCityUuid(uuid, page, limit);
}
@Override
@PreAuthorize("hasAnyAuthority('ADMIN')")
public CinemaDto updateCinemaByUuid(String uuid, CinemaDto cinemaDto) {
return cinemaService.update(uuid, cinemaDto);
}
}
Клас UserMapper:
@Mapper(componentModel = "spring")
public interface UserMapper {
List<UserDto> toDtos(List<User> entities);
UserDto toDto(User entity);
User toEntity(UserDto userDto);
}
Клас HotelMapper:
@Mapper(componentModel = "spring")
public abstract class HotelMapper {
@Autowired
protected CityRepository cityRepository;
public abstract List<HotelDto> toDtos(List<Hotel> entities);
104
ЧДТУ 252483.008 ПЗ
@Mapping(target = "uuidCity", expression =
"java(cityRepository.findById(entity.getIdCity()).map(city->city.getUuid()).orElse(null))")
public abstract HotelDto toDto(Hotel entity);
@Mapping(target = "idCity", expression =
"java(cityRepository.findFirstByUuid(hotelDto.getUuidCity()).map(city->city.getId()).orElse(
null))")
public abstract Hotel toEntity(HotelDto hotelDto);
}
Клас TheaterMapper:
@Mapper(componentModel = "spring")
public abstract class TheaterMapper {
@Autowired
protected CityRepository cityRepository;
public abstract List<TheaterDto> toDtos(List<Theater> entities);
@Mapping(target = "uuidCity", expression =
"java(cityRepository.findById(entity.getIdCity()).map(city->city.getUuid()).orElse(null))")
public abstract TheaterDto toDto(Theater entity);
@Mapping(target = "idCity", expression =
"java(cityRepository.findFirstByUuid(theaterDto.getUuidCity()).map(city->city.getId()).orEls
eThrow(()->new IllegalArgumentException(\"Not found hotel by uuid:
%s\".formatted(theaterDto.getUuidCity()))))")
public abstract Theater toEntity(TheaterDto theaterDto);
}
Клас CinemaMapper:
@Mapper(componentModel = "spring")
public abstract class CinemaMapper {
@Autowired
protected CityRepository cityRepository;
public abstract List<CinemaDto> toDtos(List<Cinema> entities);
@Mapping(target = "uuidCity", expression =
"java(cityRepository.findById(entity.getIdCity()).map(city->city.getUuid()).orElse(null))")
public abstract CinemaDto toDto(Cinema entity);
@Mapping(target = "idCity", expression =
"java(cityRepository.findFirstByUuid(cinemaDto.getUuidCity()).map(city->city.getId()).orElse
(null))")
public abstract Cinema toEntity(CinemaDto cinemaDto);
}
Клас UserRepository:
105
ЧДТУ 252483.008 ПЗ
@Repository
public interface UserRepository extends PagingAndSortingRepository<User, Long>,
CrudRepository<User, Long> {
Optional<User> findFirstByUuid(String uuid);
Optional<User> findFirstByEmail(String email);
void deleteById(long id);
}
Клас HotelRepository:
@Repository
public interface HotelRepository extends PagingAndSortingRepository<Hotel, Long>,
CrudRepository<Hotel, Long> {
Optional<Hotel> findFirstByUuid(String uuid);
Optional<Hotel> findFirstById(Long id);
Optional<List<Hotel>> findHotelsByIdCity(long id);
void deleteById(long id);
List<Hotel> findAllByIdCity(Pageable pageable, long id);
}
Клас CinemaRepository:
@Repository
public interface CinemaRepository extends PagingAndSortingRepository<Cinema, Long>,
CrudRepository<Cinema, Long> {
Optional<Cinema> findFirstByUuid(String uuid);
Optional<Cinema> findFirstById(Long id);
Optional<List<Cinema>> findCinemasByIdCity(long id);
void deleteById(long id);
List<Cinema> findAllByIdCity(Pageable pageable, long id);
}
Клас TheaterRepository:
@Repository
public interface TheaterRepository extends PagingAndSortingRepository<Theater, Long>,
CrudRepository<Theater, Long> {
Optional<Theater> findFirstByUuid(String uuid);
Optional<Theater> findFirstById(Long id);
Optional<List<Theater>> findTheatersByIdCity(long id);
void deleteById(long id);
106
ЧДТУ 252483.008 ПЗ
List<Theater> findAllByIdCity(Pageable pageable, long id);
}
Клас UserService:
@Service
@RequiredArgsConstructor
@Slf4j
public class UserService {
private final UserRepository userRepository;
private final UserMapper userMapper;
private final PasswordEncoder passwordEncoder;
private final AuthenticationManager authenticationManager;
private final JwtService jwtService;
private final UserDetailsServiceImpl userDetailsService;
public List<UserDto> getAllPages(int page, int limit) {
Pageable pageable = PageRequest.of(page, limit);
List<User> users = userRepository.findAll(pageable)
.stream()
.toList();
return userMapper.toDtos(users);
}
public List<UserDto> getAll() {
List<User> users = (List<User>) userRepository.findAll();
return userMapper.toDtos(users);
}
public UserDto getByEmail(String email) {
Optional<User> optionalUser = userRepository.findFirstByEmail(email);
if (optionalUser.isPresent()) {
return userMapper.toDto(optionalUser.get());
} else {
throw new IllegalArgumentException("User not found by email");
}
}
public UserDto add(UserDto userDto) {
User user = userMapper.toEntity(userDto);
Optional<User> optionalUser = userRepository.findFirstByEmail(user.getEmail());
if (optionalUser.isPresent()) {
throw new IllegalArgumentException("User already exists");
}
user.setUuid(UUID.randomUUID().toString());
user.setPassword(passwordEncoder.encode(user.getPassword()));
user.setRole(Role.USER);
return userMapper.toDto(
userRepository.save(user)
);
}
107
ЧДТУ 252483.008 ПЗ
public UserDto get(String uuid) {
User user = userRepository.findFirstByUuid(uuid).get();
return userMapper.toDto(user);
}
public void delete(String uuid) {
Optional<User> user = userRepository.findFirstByUuid(uuid);
if (user.isEmpty()) {
throw new IllegalArgumentException("User not found by uuid: " + uuid);
}
userRepository.deleteById(user.get().getId());
}
@Transactional
public UserDto updateByUuid(String uuid, UserDto userDto) {
Optional<User> userOptional = userRepository.findFirstByUuid(uuid);
Optional<User> optionalUserEmail =
userRepository.findFirstByEmail(userDto.getEmail());
if (optionalUserEmail.isPresent() && userOptional.isPresent() &&
!userOptional.get().getUuid().equals(optionalUserEmail.get().getUuid())) {
throw new IllegalArgumentException("Email error");
}
if (userOptional.isEmpty()) {
throw new IllegalArgumentException("User not found by uuid: " + uuid);
} else {
User updated = userMapper.toEntity(userDto);
User userToUpdate = userOptional.get();
if (updated.getFirstName() != null) {
userToUpdate.setFirstName(updated.getFirstName());
}
if (updated.getLastName() != null) {
userToUpdate.setLastName(updated.getLastName());
}
if (updated.getEmail() != null) {
userToUpdate.setEmail(updated.getEmail());
}
if (updated.getPassword() != null) {
userToUpdate.setPassword(passwordEncoder.encode(updated.getPassword()));
}
if (updated.getRole() != null) {
userToUpdate.setRole(updated.getRole());
}
return userMapper.toDto(
userRepository.save(userToUpdate)
);
}
}
public JwtDto login(UserDto userDto) {
Optional<User> optionalUser = userRepository.findFirstByEmail(userDto.getEmail());
if (optionalUser.isPresent()) {
User user = optionalUser.get();
108
ЧДТУ 252483.008 ПЗ
if (!passwordEncoder.matches(userDto.getPassword(), user.getPassword())) {
throw new IllegalArgumentException("Wrong password");
}
} else {
throw new IllegalArgumentException("User not found");
}
authenticate(userDto.getEmail(), userDto.getPassword());
final UserDetails userDetails =
userDetailsService.loadUserByUsername(userDto.getEmail());
final String token = jwtService.generateToken(userDetails);
JwtDto jwtDto = new JwtDto();
jwtDto.jwtToken(token);
return jwtDto;
}
private void authenticate(
String username,
String password
) throws DisabledException, BadCredentialsException {
authenticationManager.authenticate(
new UsernamePasswordAuthenticationToken(username, password)
);
}
}
Клас TheaterService:
@Service
@RequiredArgsConstructor
public class TheaterService {
private final TheaterMapper theaterMapper;
private final TheaterRepository theaterRepository;
private final CityRepository cityRepository;
public TheaterDto add(TheaterDto theaterDto) {
Theater theater = theaterMapper.toEntity(theaterDto);
theater.setUuid(UUID.randomUUID().toString());
return theaterMapper.toDto(
theaterRepository.save(theater)
);
}
public List<TheaterDto> getTheaters(int page, int limit) {
Pageable pageable = PageRequest.of(page, limit);
List<Theater> theaters = theaterRepository.findAll(pageable)
.stream().toList();
return theaterMapper.toDtos(theaters);
}
public List<TheaterDto> getTheatersByCityUuid(String uuid, int page, int limit) {
Optional<City> optionalCity = cityRepository.findFirstByUuid(uuid);
109
ЧДТУ 252483.008 ПЗ
if (optionalCity.isEmpty()) {
throw new IllegalArgumentException("City not found by uuid: " + uuid);
}
City city = optionalCity.get();
Pageable pageable = PageRequest.of(page, limit);
List<Theater> theaters = theaterRepository.findAllByIdCity(pageable, city.getId());
return theaterMapper.toDtos(theaters);
}
public List<TheaterDto> getAllTheatersInDB() {
List<Theater> theaters = (List<Theater>) theaterRepository.findAll();
return theaterMapper.toDtos(theaters);
}
public List<TheaterDto> getAllTheatersByCityUuid(String uuid) {
Optional<City> optionalCity = cityRepository.findFirstByUuid(uuid);
if (optionalCity.isEmpty()) {
throw new IllegalArgumentException("City not found by uuid: " + uuid);
}
City city = optionalCity.get();
Optional<List<Theater>> optionalTheaters =
theaterRepository.findTheatersByIdCity(city.getId());
List<Theater> theaters = optionalTheaters.get();
return theaterMapper.toDtos(theaters);
}
public TheaterDto getByUuid(String uuid) {
Optional<Theater> optionalTheater = theaterRepository.findFirstByUuid(uuid);
if (optionalTheater.isEmpty()) {
throw new IllegalArgumentException("Theater not found by uuid: " + uuid);
}
Theater theater = optionalTheater.get();
return theaterMapper.toDto(theater);
}
@Transactional
public TheaterDto update(String uuid, TheaterDto theaterDto) {
Optional<Theater> optionalTheater = theaterRepository.findFirstByUuid(uuid);
if (optionalTheater.isEmpty()) {
throw new IllegalArgumentException("Theater not found by uuid: " + uuid);
} else {
Theater updated = theaterMapper.toEntity(theaterDto);
Theater theater = TheaterInspector.checkUpdatedTheater(optionalTheater,
updated);
return theaterMapper.toDto(
theaterRepository.save(theater)
);
}
}
110
ЧДТУ 252483.008 ПЗ
public void delete(String uuid) {
Optional<Theater> optionalTheater = theaterRepository.findFirstByUuid(uuid);
if (optionalTheater.isEmpty()) {
throw new IllegalArgumentException("Theater not found by uuid: " + uuid);
}
theaterRepository.deleteById(optionalTheater.get().getId());
}
}
Клас HotelService:
@Service
@RequiredArgsConstructor
public class HotelService {
private final HotelRepository hotelRepository;
private final HotelMapper hotelMapper;
private final CityRepository cityRepository;
public HotelDto add(HotelDto hotelDto) {
Hotel hotel = hotelMapper.toEntity(hotelDto);
hotel.setUuid(UUID.randomUUID().toString());
return hotelMapper.toDto(
hotelRepository.save(hotel)
);
}
public List<HotelDto> getHotels(int page, int limit) {
Pageable pageable = PageRequest.of(page, limit);
List<Hotel> hotels = hotelRepository.findAll(pageable)
.stream()
.toList();
return hotelMapper.toDtos(hotels);
}
public List<HotelDto> getHotelsByCityUuid(String uuid, int page, int limit) {
Optional<City> optionalCity = cityRepository.findFirstByUuid(uuid);
if (optionalCity.isEmpty()) {
throw new IllegalArgumentException("City not found by uuid: " + uuid);
}
City city = optionalCity.get();
Pageable pageable = PageRequest.of(page, limit);
List<Hotel> hotels = hotelRepository.findAllByIdCity(pageable, city.getId());
return hotelMapper.toDtos(hotels);
}
public List<HotelDto> getAllHotelsInDB() {
List<Hotel> hotels = (List<Hotel>) hotelRepository.findAll();
return hotelMapper.toDtos(hotels);
111
ЧДТУ 252483.008 ПЗ
}
public List<HotelDto> getAllHotelsByCityUuid(String uuid) {
Optional<City> optionalCity = cityRepository.findFirstByUuid(uuid);
if (optionalCity.isEmpty()) {
throw new IllegalArgumentException("City not found by uuid: " + uuid);
}
City city = optionalCity.get();
Optional<List<Hotel>> optionalHotels =
hotelRepository.findHotelsByIdCity(city.getId());
List<Hotel> hotels = optionalHotels.get();
return hotelMapper.toDtos(hotels);
}
public HotelDto getByUuid(String uuid) {
Optional<Hotel> optionalHotel = hotelRepository.findFirstByUuid(uuid);
if (optionalHotel.isEmpty()) {
throw new IllegalArgumentException("Hotel not found by uuid: " + uuid);
}
Hotel hotel = optionalHotel.get();
return hotelMapper.toDto(hotel);
}
public HotelDto update(String uuid, HotelDto hotelDto) {
Optional<Hotel> optionalHotel = hotelRepository.findFirstByUuid(uuid);
if (optionalHotel.isEmpty()) {
throw new IllegalArgumentException("Hotel not found by uuid: " + uuid);
} else {
Hotel updated = hotelMapper.toEntity(hotelDto);
Hotel hotelToUpdate = HotelInspector.checkUpdatedHotel(optionalHotel, updated);
return hotelMapper.toDto(
hotelRepository.save(hotelToUpdate)
);
}
}
public void delete(String uuid) {
Optional<Hotel> optionalHotel = hotelRepository.findFirstByUuid(uuid);
if (optionalHotel.isEmpty()) {
throw new IllegalArgumentException("Hotel not found by uuid: " + uuid);
}
hotelRepository.deleteById(optionalHotel.get().getId());
}
}
Клас CinemaService:
@Service
@RequiredArgsConstructor
112
ЧДТУ 252483.008 ПЗ
public class CinemaService {
private final CinemaMapper cinemaMapper;
private final CinemaRepository cinemaRepository;
private final CityRepository cityRepository;
public CinemaDto add(CinemaDto cinemaDto) {
Cinema cinema = cinemaMapper.toEntity(cinemaDto);
cinema.setUuid(UUID.randomUUID().toString());
return cinemaMapper.toDto(
cinemaRepository.save(cinema)
);
}
public List<CinemaDto> getCinemas(int page, int limit) {
Pageable pageable = PageRequest.of(page, limit);
List<Cinema> cinemas = cinemaRepository.findAll(pageable)
.stream().toList();
return cinemaMapper.toDtos(cinemas);
}
public List<CinemaDto> getCinemasByCityUuid(String uuid, int page, int limit) {
Optional<City> optionalCity = cityRepository.findFirstByUuid(uuid);
if (optionalCity.isEmpty()) {
throw new IllegalArgumentException("City not found by uuid: " + uuid);
}
City city = optionalCity.get();
Pageable pageable = PageRequest.of(page, limit);
List<Cinema> cinemas = cinemaRepository.findAllByIdCity(pageable, city.getId());
return cinemaMapper.toDtos(cinemas);
}
public List<CinemaDto> getAllCinemasInDB() {
List<Cinema> cinemas = (List<Cinema>) cinemaRepository.findAll();
return cinemaMapper.toDtos(cinemas);
}
public List<CinemaDto> getAllCinemasByCityUuid(String uuid) {
Optional<City> optionalCity = cityRepository.findFirstByUuid(uuid);
if (optionalCity.isEmpty()) {
throw new IllegalArgumentException("City not found by uuid: " + uuid);
}
City city = optionalCity.get();
Optional<List<Cinema>> optionalCinemas =
cinemaRepository.findCinemasByIdCity(city.getId());
List<Cinema> cinemas = optionalCinemas.get();
return cinemaMapper.toDtos(cinemas);
}
public CinemaDto getByUuid(String uuid) {
113
ЧДТУ 252483.008 ПЗ
Optional<Cinema> optionalCinema = cinemaRepository.findFirstByUuid(uuid);
if (optionalCinema.isEmpty()) {
throw new IllegalArgumentException("Cinema not found by uuid: " + uuid);
}
Cinema cinema = optionalCinema.get();
return cinemaMapper.toDto(cinema);
}
@Transactional
public CinemaDto update(String uuid, CinemaDto cinemaDto) {
Optional<Cinema> optionalCinema = cinemaRepository.findFirstByUuid(uuid);
if (optionalCinema.isEmpty()) {
throw new IllegalArgumentException("Cinema not found by uuid: " + uuid);
} else {
Cinema updated = cinemaMapper.toEntity(cinemaDto);
Cinema cinemaToUpdate = CinemaInspector.checkUpdatedCinema(optionalCinema,
updated);
return cinemaMapper.toDto(
cinemaRepository.save(cinemaToUpdate)
);
}
}
public void delete(String uuid) {
Optional<Cinema> optionalCinema = cinemaRepository.findFirstByUuid(uuid);
if (optionalCinema.isEmpty()) {
throw new IllegalArgumentException("Cinema not found by uuid: " + uuid);
}
cinemaRepository.deleteById(optionalCinema.get().getId());
}
}
Клас User:
@NoArgsConstructor
@Builder
@Getter
@Setter
@AllArgsConstructor
@EqualsAndHashCode
@ToString
public class User {
@Id
private long id;
private String uuid;
private String lastName;
private String firstName;
private String email;
private String password;
private Role role;
@CreatedDate
@InsertOnlyProperty
private OffsetDateTime createdAt;
114
ЧДТУ 252483.008 ПЗ
@LastModifiedDate
private OffsetDateTime updatedAt;
}
Клас Theater:
@NoArgsConstructor
@Builder
@Getter
@Setter
@AllArgsConstructor
@EqualsAndHashCode
@ToString
public class Theater {
@Id
private long id;
private String uuid;
private String name;
private String imageUrl;
private String address;
private Double latitude;
private Double longitude;
private Long idCity;
private String description;
private String phoneNumbers;
private String socialLink;
private String email;
@CreatedDate
@InsertOnlyProperty
private OffsetDateTime createdAt;
@LastModifiedDate
private OffsetDateTime updatedAt;
}
Клас Hotel:
@NoArgsConstructor
@Builder
@Getter
@Setter
@AllArgsConstructor
@EqualsAndHashCode
@ToString
public class Hotel {
@Id
private long id;
private String uuid;
private String name;
private String imageUrl;
private String address;
private Double latitude;
private Double longitude;
private Long idCity;
private String socialLink;
private String phoneNumbers;
private String email;
private String description;
private String services;
private String mealsInformation;
115
ЧДТУ 252483.008 ПЗ
private Integer roomsAmount;
private Integer minPrice;
@CreatedDate
@InsertOnlyProperty
private OffsetDateTime createdAt;
@LastModifiedDate
private OffsetDateTime updatedAt;
}
Клас Cinema:
@NoArgsConstructor
@Builder
@Getter
@Setter
@AllArgsConstructor
@EqualsAndHashCode
@ToString
public class Cinema {
@Id
private long id;
private String uuid;
private String name;
private String imageUrl;
private String address;
private Double latitude;
private Double longitude;
private String description;
private Long idCity;
private String socialLink;
private String phoneNumbers;
@CreatedDate
@InsertOnlyProperty
private OffsetDateTime createdAt;
@LastModifiedDate
private OffsetDateTime updatedAt;
}
Клас TheaterInspector:
public class TheaterInspector {
public static Theater checkUpdatedTheater(Optional<Theater> optionalTheater, Theater
updated) {
Theater theater = optionalTheater.get();
if (updated.getName() != null) {
theater.setName(updated.getName());
}
if (updated.getLatitude() != null) {
theater.setLatitude(updated.getLatitude());
}
if (updated.getLongitude() != null) {
theater.setLongitude(updated.getLongitude());
}
if (updated.getAddress() != null) {
theater.setAddress(updated.getAddress());
}
if (updated.getIdCity() != null) {
theater.setIdCity(updated.getIdCity());
116
ЧДТУ 252483.008 ПЗ
}
if (updated.getDescription() != null) {
theater.setDescription(updated.getDescription());
}
if (updated.getPhoneNumbers() != null) {
theater.setPhoneNumbers(updated.getPhoneNumbers());
}
if (updated.getEmail() != null) {
theater.setEmail(updated.getEmail());
}
if (updated.getSocialLink() != null) {
theater.setSocialLink(updated.getSocialLink());
}
return theater;
}
}
Клас HotelInspector:
public class HotelInspector {
public static Hotel checkUpdatedHotel(Optional<Hotel> optionalHotel, Hotel updated) {
Hotel hotel = optionalHotel.get();
if (updated.getName() != null) {
hotel.setName(updated.getName());
}
if (updated.getAddress() != null) {
hotel.setAddress(updated.getAddress());
}
if (updated.getLatitude() != null) {
hotel.setLatitude(updated.getLatitude());
}
if (updated.getLongitude() != null) {
hotel.setLongitude(updated.getLongitude());
}
if (updated.getIdCity() != null) {
hotel.setIdCity(updated.getIdCity());
}
if (updated.getSocialLink() != null) {
hotel.setSocialLink(updated.getSocialLink());
}
if (updated.getPhoneNumbers() != null) {
hotel.setPhoneNumbers(updated.getPhoneNumbers());
}
if (updated.getEmail() != null) {
hotel.setEmail(updated.getEmail());
}
if (updated.getDescription() != null) {
hotel.setDescription(updated.getDescription());
}
if (updated.getServices() != null) {
hotel.setServices(updated.getServices());
}
if (updated.getMealsInformation() != null) {
hotel.setMealsInformation(updated.getMealsInformation());
}
if (updated.getRoomsAmount() != null) {
hotel.setRoomsAmount(updated.getRoomsAmount());
}
117
ЧДТУ 252483.008 ПЗ
if (updated.getMinPrice() != null) {
hotel.setMinPrice(updated.getMinPrice());
}
return hotel;
}
}
Клас CinemaInspector:
public class CinemaInspector {
public static Cinema checkUpdatedCinema(Optional<Cinema> optionalCinema, Cinema updated)
{
Cinema cinema = optionalCinema.get();
if (updated.getName() != null) {
cinema.setName(updated.getName());
}
if (updated.getLatitude() != null) {
cinema.setLatitude(updated.getLatitude());
}
if (updated.getLongitude() != null) {
cinema.setLongitude(updated.getLongitude());
}
if (updated.getAddress() != null) {
cinema.setAddress(updated.getAddress());
}
if (updated.getDescription() != null) {
cinema.setDescription(updated.getDescription());
}
if (updated.getIdCity() != null) {
cinema.setIdCity(updated.getIdCity());
}
if (updated.getPhoneNumbers() != null) {
cinema.setPhoneNumbers(updated.getPhoneNumbers());
}
if (updated.getSocialLink() != null) {
cinema.setSocialLink(updated.getSocialLink());
}
return cinema;
}
}
Фрагмент входу користувача:
class LoginFragment : Fragment() {
private lateinit var binding: FragmentLoginBinding
private lateinit var viewModel: LoginViewModel
private var user: User? = null
override fun onCreateView(
inflater: LayoutInflater, container: ViewGroup?,
savedInstanceState: Bundle?
): View? {
binding = FragmentLoginBinding.inflate(inflater, container, false)
return binding.root
}
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
118
ЧДТУ 252483.008 ПЗ
super.onViewCreated(view, savedInstanceState)
initViewModel()
binding.cbLoginPassword.setOnCheckedChangeListener { chb, isChecked ->
if (isChecked) {
binding.evLoginPassword.inputType =
InputType.TYPE_CLASS_TEXT or InputType.TYPE_TEXT_VARIATION_VISIBLE_PASSWORD
} else {
binding.evLoginPassword.inputType =
InputType.TYPE_CLASS_TEXT or InputType.TYPE_TEXT_VARIATION_PASSWORD
}
binding.evLoginPassword.setSelection(binding.evLoginPassword.text!!.length)
}
binding.tvLoginRegistration.setOnClickListener {
changeFragment(RegistrationFragment())
}
binding.btnLoginSubmit.setOnClickListener { loginUser() }
}
private fun initViewModel() {
if (!isAdded) return
val userRepository = UserRepository(RetrofitClient.apiService, requireContext())
viewModel = ViewModelProvider(
this,
LoginViewModelFactory(userRepository)
)[LoginViewModel::class.java]
viewModel.loginResult.observe(viewLifecycleOwner) { result ->
result.onSuccess { token ->
Log.i("MYLOG", "User login success. Token: $token")
val email = binding.evLoginEmail.text.toString()
this.user = runBlocking { RetrofitClient.apiService.getUserByEmail(email) }
saveUserInfo(token, user?.uuid.toString(), user?.role.toString())
changeFragment(ProfileFragment())
}
.onFailure { error ->
Log.e("MYLOG", "Login error: ${error.message}")
handleLoginError(error)
}
}
}
private fun loginUser() {
val email = binding.evLoginEmail.text.toString()
val password = binding.evLoginPassword.text.toString()
when {
email.isEmpty() -> {
binding.evLoginEmail.error = "Введіть email"
return
}
password.isEmpty() -> {
binding.evLoginPassword.error = "Введіть пароль"
return
}
}
val user = User(
email = email,
password = password
)
119
ЧДТУ 252483.008 ПЗ
viewModel.loginUser(user)
}
private fun saveUserInfo(token: String, uuid: String, role: String) {
val sharedPreferences =
requireContext().getSharedPreferences("AppPrefs", Context.MODE_PRIVATE)
sharedPreferences.edit {
putString("Authorization", "Bearer $token")
putString("Token", token)
putString("UserUuid", uuid)
putString("UserRole", role)
apply()
}
}
private fun handleLoginError(error: Throwable) {
when (error.message) {
"User not found" -> binding.evLoginEmail.error =
"Неправильний email"
"User not found by email" -> binding.evLoginEmail.error =
"Користувач не існує"
"Wrong password" -> binding.evLoginPassword.error = "Неправильний пароль"
else -> Toast.makeText(
requireContext(),
"Помилка входу: ${error.message}",
Toast.LENGTH_SHORT
).show()
}
}
private fun changeFragment(fragment: Fragment) {
parentFragmentManager.beginTransaction()
.replace(R.id.flFragments, fragment)
.addToBackStack(null)
.commit()
}
}
Фрагмент реєстрації користувача:
class RegistrationFragment : Fragment() {
private lateinit var binding: FragmentRegistrationBinding
private lateinit var viewModel: RegistrationViewModel
override fun onCreateView(
inflater: LayoutInflater, container: ViewGroup?,
savedInstanceState: Bundle?
): View? {
binding = FragmentRegistrationBinding.inflate(inflater, container, false)
return binding.root
}
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
initViewModel()
binding.cbRegistrationPassword.setOnCheckedChangeListener { chb, isChecked ->
if (isChecked) {
binding.evRegistrationPassword.inputType =
InputType.TYPE_CLASS_TEXT or InputType.TYPE_TEXT_VARIATION_VISIBLE_PASSWORD
} else {
binding.evRegistrationPassword.inputType =
InputType.TYPE_CLASS_TEXT or InputType.TYPE_TEXT_VARIATION_PASSWORD
}
120
ЧДТУ 252483.008 ПЗ
binding.evRegistrationPassword.setSelection(binding.evRegistrationPassword.text!!.length)
}
setSpannable()
binding.btnRegistrationSubmit.setOnClickListener { registerUser() }
}
private fun initViewModel() {
if (!isAdded) return
val userRepository = UserRepository(RetrofitClient.apiService, requireContext())
viewModel = ViewModelProvider(
this,
RegistrationViewModelFactory(userRepository)
)[RegistrationViewModel::class.java]
viewModel.registrationResult.observe(viewLifecycleOwner) { result ->
result.onSuccess {
Log.i("MYLOG", "User registration success")
changeFragment(LoginRegisterFragment())
}
.onFailure { error ->
if (error.message == "User already exists") {
binding.evRegistrationEmail.error =
"Користувач з даним email вже існує. Введіть інший email"
} else {
Log.e("MYLOG", error.message.toString())
Toast.makeText(
requireContext(),
"ERROR: ${error.message}",
Toast.LENGTH_SHORT
).show()
}
}
}
}
private fun setSpannable() {
val text = getString(R.string.RegistrationLogin)
val spannable = SpannableString(text)
val startIndex = text.indexOf("увійдіть")
val endIndex = startIndex + "увійдіть".length
val clickableSpan = object : ClickableSpan() {
override fun onClick(widget: View) {
changeFragment(LoginFragment())
}
override fun updateDrawState(ds: TextPaint) {
super.updateDrawState(ds)
ds.color = Color.BLUE
ds.isUnderlineText = true
}
}
spannable.setSpan(clickableSpan, startIndex, endIndex,
Spanned.SPAN_EXCLUSIVE_EXCLUSIVE)
binding.tvRegistrationLogin.text = spannable
binding.tvRegistrationLogin.movementMethod = LinkMovementMethod.getInstance()
binding.tvRegistrationLogin.highlightColor = Color.TRANSPARENT
}
private fun registerUser() {
val lastName = binding.evRegistrationLastName.text.toString()
val firstName = binding.evRegistrationFirstName.text.toString()
val email = binding.evRegistrationEmail.text.toString()
121
ЧДТУ 252483.008 ПЗ
val password = binding.evRegistrationPassword.text.toString()
when {
lastName.isEmpty() -> {
binding.evRegistrationLastName.error = "Введіть прізвище"
return
}
firstName.isEmpty() -> {
binding.evRegistrationFirstName.error = "Введіть ім'я"
return
}
email.isEmpty() -> {
binding.evRegistrationEmail.error = "Введіть email"
return
}
password.isEmpty() -> {
binding.evRegistrationPassword.error = "Введіть пароль"
return
}
}
val user = User(
lastName = lastName,
firstName = firstName,
email = email,
password = password
)
viewModel.registerUser(user)
}
private fun changeFragment(fragment: Fragment) {
parentFragmentManager.beginTransaction()
.replace(R.id.flFragments, fragment)
.addToBackStack(null)
.commit()
}
}
122
ЧДТУ 252483.008 ПЗ
ДОДАТОК Г
ANDROID-ДОДАТОК ДЛЯ ПОШУКУ МІСЦЬ ВІДПОЧИНКУ В УКРАЇНІ
ГРАФІЧНІ МАТЕРІАЛИ
482.ЧДТУ.252483 9001
Листів
Розробник _____________ Кавун Д.Р.
Черкаси – 2025
123
ЧДТУ 252483.008 ПЗ
Рисунок Г.1 – Слайд 1
Рисунок Г.2 – Слайд 2
124
ЧДТУ 252483.008 ПЗ
Рисунок Г.3 – Слайд 3
Рисунок Г.4 – Слайд 4
125
ЧДТУ 252483.008 ПЗ
Рисунок Г.5 – Слайд 5
Рисунок Г.6 – Слайд 6
126
ЧДТУ 252483.008 ПЗ
Рисунок Г.7 – Слайд 7
Рисунок Г.8 – Слайд 8
127
ЧДТУ 252483.008 ПЗ
Рисунок Г.9 – Слайд 9
Рисунок Г.10 – Слайд 10
128
ЧДТУ 252483.008 ПЗ
Рисунок Г.11 – Слайд 11
Рисунок Г.12 – Слайд 12
129
ЧДТУ 252483.008 ПЗ
Рисунок Г.13 – Слайд 13
Рисунок Г.14 – Слайд 14
130
ЧДТУ 252483.008 ПЗ
Рисунок Г.15 – Слайд15
Рисунок Г.16 – Слайд 16
131
ЧДТУ 252483.008 ПЗ
Рисунок Г.17 – Слайд 17
132