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/7099| Title: | Android-додаток для пошуку місця відпочинку в Україні |
| Authors: | Олексюк, Вадим Володимирович Кавун, Дмитро Романович |
| Keywords: | МОБІЛЬНИЙ ДОДАТОК;ANDROID;МІСЦЯ ВІДПОЧИНКУ;ІНФОРМАЦІЙНА СИСТЕМА;ІНЖЕНЕРІЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ;ПРОЄКТУВАННЯ;ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ;MOBILE APPLICATION;ANDROID;RECREATIONAL PLACES;INFORMATION SYSTEM;SOFTWARE ENGINEERING;SOFTWARE DESIGN;SOFTWARE TESTING |
| Issue Date: | 16-Dec-2025 |
| Abstract: | АНОТАЦІЯ
Кавун Д.Р. Магістерська кваліфікаційна робота на тему «Android-додаток для пошуку місць відпочинку в Україні». Спеціальність 121 «Інженерія програмного забезпечення». Захист роботи відбудеться у Черкаському державному технологічному університеті. Черкаси, 2025.
Магістерська кваліфікаційна робота присвячена проєктуванню та розробці мобільного Android-додатку для пошуку місць відпочинку в Україні. У роботі виконано аналіз предметної області та існуючих аналогів програмних рішень, визначено функціональні та нефункціональні вимоги до програмного забезпечення. Проведено моделювання предметної області з використанням UML-діаграм. Запропоновано архітектуру програмного комплексу, описано структуру бази даних та інтерфейс користувача. Реалізовано механізм вибору категорії місць відпочинку та міста з подальшим формуванням відповідного списку локацій. Окрему увагу приділено тестуванню програмного забезпечення, включаючи модульне, інтеграційне, системне та приймальне тестування. Отримані результати підтверджують доцільність використання розробленого додатку для підвищення зручності доступу користувачів до інформації про місця відпочинку. ABSTRACT Kavun D.R. Master’s Qualification Thesis entitled «Android application for finding vacation spots in Ukraine». Specialty 121 “Software Engineering”. The defense will take place at Cherkasy State Technological University. Cherkasy, 2025. The master’s qualification thesis is devoted to the design and development of an Android mobile application intended for searching, filtering, and viewing recreational places. The paper analyzes the subject domain and existing software analogues and defines functional and non-functional requirements for the software system. The subject domain is modeled using UML diagrams, including use case, class, activity, sequence, component, and deployment diagrams. The architecture of the software system is proposed, and the database structure and user interface are described. A mechanism for selecting a category of recreational places and a city with subsequent generation of a relevant list of locations is implemented. Special attention is paid to software testing, including unit, integration, system, and acceptance testing. The obtained results confirm the feasibility of using the developed application to improve user access to information about recreational places. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/7099 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота магістра Кавун Дмитра Романовича.pdf Restricted Access | 6.57 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
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень магістр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
___________ Голуб С.В.
«___» _______________ 2025 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Кавун Дмитро Романович
(прізвище, ім’я, по батькові)
1.Тему проекту (роботи) Android-додаток для пошуку місця відпочинку в Україні
Керівник проекту (роботи) Олексюк Вадим Володимирович к.т.н., доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « 07 » жовтня
2025 року №307/03-03
2. Строк подання студентом проекту (роботи) 2 грудня 2025 р.
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління;
вимоги до проекту; календарне планування проекту; управління ризиками проекту; управління
ресурсами
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ;
Існуючі методи та засоби розв’язання поставлених задач;
Теоретичні та експериментальні дослідження;
Впровадження результатів досліджень у практику проектування програмного забезпечення
інформаційних систем;
Розробка та тестування програмного забезпечення;
Висновки;
Список використаних джерел;
Додатки.
5. Перелік додатків (з точним зазначенням назв додатків)
Додаток А. Специфікація
Додаток Б. Текст програми;
Додаток Г. Графічні матеріали;
6. Консультанти розділів проекту (роботи)
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання вересень 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
Студент _____________________ Кавун Д.Р.
(підпис) (прізвище та ініціали)
Керівник проекту (роботи) _____________________ Олексюк В.В.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Кавун Д.Р. Магістерська кваліфікаційна робота на тему «Android-додаток
для пошуку місць відпочинку в Україні». Спеціальність 121 «Інженерія
програмного забезпечення». Захист роботи відбудеться у Черкаському
державному технологічному університеті. Черкаси, 2025.
Магістерська кваліфікаційна робота присвячена проєктуванню та розробці
мобільного Android-додатку для пошуку місць відпочинку в Україні. У роботі
виконано аналіз предметної області та існуючих аналогів програмних рішень,
визначено функціональні та нефункціональні вимоги до програмного
забезпечення. Проведено моделювання предметної області з використанням
UML-діаграм. Запропоновано архітектуру програмного комплексу, описано
структуру бази даних та інтерфейс користувача. Реалізовано механізм вибору
категорії місць відпочинку та міста з подальшим формуванням відповідного
списку локацій. Окрему увагу приділено тестуванню програмного забезпечення,
включаючи модульне, інтеграційне, системне та приймальне тестування.
Отримані результати підтверджують доцільність використання розробленого
додатку для підвищення зручності доступу користувачів до інформації про місця
відпочинку.
Ключові слова: МОБІЛЬНИЙ ДОДАТОК, ANDROID, МІСЦЯ
ВІДПОЧИНКУ, ІНФОРМАЦІЙНА СИСТЕМА, ІНЖЕНЕРІЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ, ПРОЄКТУВАННЯ, ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
ABSTRACT
Kavun D.R. Master’s Qualification Thesis entitled «Android application for
finding vacation spots in Ukraine». Specialty 121 “Software Engineering”. The defense
will take place at Cherkasy State Technological University. Cherkasy, 2025.
The master’s qualification thesis is devoted to the design and development of an
Android mobile application intended for searching, filtering, and viewing recreational
places. The paper analyzes the subject domain and existing software analogues and
defines functional and non-functional requirements for the software system. The subject
domain is modeled using UML diagrams, including use case, class, activity, sequence,
component, and deployment diagrams. The architecture of the software system is
proposed, and the database structure and user interface are described. A mechanism for
selecting a category of recreational places and a city with subsequent generation of a
relevant list of locations is implemented. Special attention is paid to software testing,
including unit, integration, system, and acceptance testing. The obtained results confirm
the feasibility of using the developed application to improve user access to information
about recreational places.
Keywords: MOBILE APPLICATION, ANDROID, RECREATIONAL
PLACES, INFORMATION SYSTEM, SOFTWARE ENGINEERING, SOFTWARE
DESIGN, SOFTWARE TESTING.
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПРЗНАЧЕНЬ .......................................................................... 4
ВСТУП ............................................................................................................................ 5
1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ ....................................................................................................................... 8
1.1 Аналіз наукової та технічної інформації щодо теми дослідження .............. 8
1.2 Аналіз існуючих аналогів ................................................................................. 10
1.2.1 Аналіз додатку «Multiplex» ..................................................................... 10
1.2.2 Аналіз додатку «Booking.com» ............................................................... 11
1.2.3 Аналіз додатку «SmartCinema» .............................................................. 12
1.2.4 Аналіз додатку «Контрамарка» .............................................................. 13
1.2.5 Аналіз додатку «Hotel Ukraine» .............................................................. 15
1.3 Пошук методів та засобів для вирішення поставлених завдань .................. 16
1.3.1 Вибір архітектурного підходу для мобільного додатку ...................... 16
1.3.2 Вибір клієнт-серверної взаємодії ........................................................... 17
1.3.3 Документування API через OpenAPI.yaml ............................................ 17
1.3.4 Вибір технологій для бекенду ................................................................ 18
1.3.5 Вибір СКБД .............................................................................................. 19
1.3.6 Технології та бібліотеки для Android ..................................................... 19
1.3.7 Підсумок підрозділу ................................................................................ 20
1.4 Актуальні проблеми, що виникають при створенні інформаційних
мобільних систем .......................................................................................................... 20
1.4.1 Актуальність та достовірність інформації ............................................ 20
1.4.2 Масштабованість і продуктивність ........................................................ 20
1.4.3 Проблеми з класифікацією даних та фільтрами ................................... 21
1.4.4 Забезпечення швидкодії мобільного інтерфейсу .................................. 21
1.4.5 Розмежування доступу і безпека ............................................................ 22
1.4.6 Проблеми з інтеграцією зі сторонніми ресурсами ............................... 22
1.4.7 Уніфікація даних різних типів локацій .................................................. 22
1.4.8 Забезпечення зручності користування (UX-проблеми) ....................... 23
1.5. Конкретизація завдання магістерської роботи .............................................. 24
1.5.1 Загальна мета розробки ........................................................................... 24
1.5.2 Постановка задачі для мобільного застосунку ..................................... 24
1.5.3 Постановка задачі для бекенд-системи ................................................. 25
1.5.4 Функціональні вимоги до системи ......................................................... 26
1.5.5 Нефункціональні вимоги ......................................................................... 27
1.5.6 Програмна реалізація як результат магістерської роботи ................... 27
1.6 Формулювання місця автора в розв’язанні задачі ......................................... 28
1.6.1 Внесок автора у концепцію та постановку завдання ........................... 28
1.6.2 Внесок автора у проектування мобільного додатку ............................. 28
1.6.3 Внесок автора у розробку серверної частини ....................................... 29
1.6.4 Внесок автора у дослідження аналогів та моделювання системи ...... 30
1.6.5 Формування авторського бачення системи ........................................... 31
Висновки до розділу 1 .................................................................................................. 32
2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ ............................. 33
2.1 Теоретичні дослідження ................................................................................. 33
2.1.1 Архітектурні принципи побудови мобільних інформаційних систем 33
2.1.2 Інформаційна модель мобільної системи .............................................. 34
2.1.3 Принципи організації даних у довідкових системах ............................ 34
2.1.4 Теоретичні аспекти REST-архітектури .................................................. 35
2.1.5 Моделювання користувацької взаємодії ............................................... 36
2.1.6 Принципи забезпечення безпеки в мобільних системах ..................... 36
2.1.7 Математичні моделі і формалізація задачі ............................................ 37
2.1.7.1 Формальна модель інформаційної структури .......................... 37
2.1.7.2 Математична модель фільтрації даних ..................................... 39
2.1.7.3 Формальна модель авторизації .................................................. 40
2.1.7.4 Модель додавання до «Обраного» ............................................ 40
2.1.7.5 Математична модель навігаційного графа ............................... 41
2.1.7.6 Критерії ефективності системи ................................................. 42
2.1.8 Теорія та гіпотеза дослідження .............................................................. 42
2.1.8.1 Теорія дослідження ..................................................................... 42
2.1.8.2 Гіпотеза дослідження ................................................................. 43
2.2 Експериментальні дослідження ....................................................................... 44
2.2.1 Мета та завдання експериментальних досліджень ............................... 44
2.2.2 Середовище проведення експериментів ................................................ 45
2.2.3 Методика тестування ............................................................................... 45
2.2.4 Сценарії експериментів ........................................................................... 46
2.2.5 Аналіз отриманих результатів ................................................................ 47
2.2.6 Обмеження експериментального дослідження ..................................... 47
Висновки до розділу 2 .................................................................................................. 48
3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ ........................................................................................................................ 49
3.1 Моделювання предметної області ................................................................... 49
3.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області .................................................................. 50
3.1.2 Елементи моделювання предметної області ......................................... 52
3.1.3 Робоча область моделювання ................................................................. 53
3.2 Формування та аналіз вимог ............................................................................ 54
3.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні
та нефункціональні вимоги .................................................................... 55
3.2.2 Формування вимог за допомогою діаграми прецендентів .................. 58
3.2.3 Проектування логічної структури програмного комплексу ............... 60
3.2.3.1 Діаграма класів ......................................................................... 60
3.2.3.2 Діаграма пакетів .......................................................................... 65
3.2.4 Архітектурне проектування .................................................................... 67
3.2.4.1 Діаграма компонентів ................................................................. 68
3.2.4.2 Розгортання програмної системи на апаратних засобах.
Діаграма розгортання ................................................................ 69
3.2.5 Моделювання поведінки системи .......................................................... 70
3.2.5.1 Діаграма діяльності ..................................................................... 70
3.2.5.2 Діаграма послідовності .............................................................. 71
3.2.5.3 Діаграма комунікації .................................................................. 73
3.2.5.4 Діаграма скінченного автомату ................................................. 74
Висновки до розділу 3 .................................................................................................. 77
4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ................. 78
4.1 Розробка програмного комплексу ................................................................... 78
4.1.2 Опис структурної (функціональної) схеми .......................................... 79
4.1.3 Опис логічної схеми системи ................................................................. 81
4.1.4 Розробка бази даних системи ................................................................. 82
4.1.5 Розробка інтерфейсу користувача ......................................................... 83
4.1.6 Опис розробки програмних компонентів ............................................. 85
4.2 Тестування системи .......................................................................................... 88
4.2.1 Модульне тестування ............................................................................ 89
4.2.2 Інтеграційне тестування ........................................................................ 91
4.2.3 Системне тестування ............................................................................. 93
4.2.4 Приймальне тестування......................................................................... 94
4.3 Приклади впровадженого програмного комплексу....................................... 96
Висновки до розділу 4 .................................................................................................. 99
ВИСНОВКИ ................................................................................................................... 100
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ..................................................................... 102
ДОДОТКИ ...................................................................................................................... 104
ЧДТУ 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, розширювана мова розмітки для
структурованого зберігання, передачі та обміну даними.
4
ЧДТУ 252483.008 ПЗ
ВСТУП
Актуальність теми
Тема даної магістерської кваліфікаційної роботи належить до галузі
інженерії програмного забезпечення, оскільки передбачає проєктування, розробку
та тестування програмної інформаційної системи у вигляді мобільного Android-
додатку. У межах роботи застосовуються сучасні підходи до аналізу вимог,
архітектурного проєктування, моделювання програмних систем та забезпечення
якості програмного забезпечення.
Сучасна сфера туризму, готельно-ресторанного бізнесу та культурного
дозвілля активно розвивається під впливом цифрових технологій і мобільних
сервісів. Користувачі дедалі частіше отримують інформацію про місця
відпочинку за допомогою смартфонів, очікуючи швидкого доступу до актуальних
та структурованих даних. Водночас на ринку відсутні комплексні мобільні
рішення, які б об’єднували інформацію про різні типи культурно-туристичних
локацій у межах єдиного довідкового застосунку. Існуючі сервіси зазвичай
спеціалізуються лише на окремих видах відпочинку або мають комерційну
спрямованість. Тому розробка інформаційного Android-додатку для пошуку місць
відпочинку в Україні є актуальним і доцільним завданням з погляду сучасних
інформаційних технологій.
Зв’язок роботи з науковими програмами, планами, темами
Магістерська робота виконана відповідно до освітньо-наукової програми
підготовки магістрів за спеціальністю галузі інформаційних технологій та
відповідає планам навчального процесу кафедри. Тематика роботи узгоджується з
напрямами наукових досліджень у сфері розробки інформаційних систем,
мобільних застосунків та клієнт-серверних архітектур. Результати дослідження
можуть бути використані під час виконання науково-дослідних робіт, пов’язаних
зі створенням та впровадженням інформаційних мобільних систем довідкового
типу.
Мета і завдання дослідження
5
ЧДТУ 252483.008 ПЗ
Метою магістерської роботи є вдосконалення методів побудови
програмного забезпечення інформаційної системи пошуку місць відпочинку в
Україні шляхом проєктування та реалізації інформаційного Android-додатку на
основі клієнт-серверної архітектури, який забезпечує зручний доступ
користувачів до структурованої довідкової інформації про місця відпочинку в
Україні.
Для досягнення поставленої мети у роботі необхідно розв’язати такі
завдання:
− проаналізувати існуючі мобільні застосунки та підходи до організації
інформаційних систем у сфері туризму та культурного дозвілля;
− обґрунтувати вибір архітектури та технологічного стеку для реалізації
мобільного застосунку і серверної частини;
− спроєктувати інформаційну модель системи та структуру бази даних;
− реалізувати серверну частину у вигляді REST API з підтримкою
авторизації;
− розробити Android-додаток з використанням сучасних підходів до
UI/UX та архітектури MVVM;
− забезпечити взаємодію клієнта і сервера та перевірити працездатність
системи експериментальним шляхом.
Об’єкт дослідження
Об’єктом дослідження є процеси проєктування, розробки та
функціонування Android-додатку для пошуку місць відпочинку в Україні.
Предмет дослідження
Предметом дослідження є методи та засоби проєктування і реалізації клієнт-
серверної інформаційної мобільної системи для пошуку місць відпочинку в
Україні.
Методи дослідження
Для досягнення поставленої мети у магістерській роботі використано такі
методи дослідження: аналіз і порівняння – під час вивчення наукових джерел та
існуючих мобільних застосунків-аналогів; системний підхід і моделювання – при
6
ЧДТУ 252483.008 ПЗ
проєктуванні архітектури програмної системи та інформаційної моделі;
формалізація – під час побудови математичних моделей процесів фільтрації,
авторизації та навігації; експеримент і тестування – для перевірки працездатності
та продуктивності реалізованого програмного забезпечення.
Наукова новизна одержаних результатів
У магістерській роботі отримано наукові результати, що полягають у
розробці інформаційного мобільного застосунку довідкового типу, який поєднує
різні категорії місць відпочинку (готелі, кінотеатри, театри) в межах єдиної
клієнт-серверної системи з уніфікованою структурою даних, удосконалено
проєктування програмної системи та користувацької навігації, а також підхід до
організації пошуку й фільтрації довідкової інформації шляхом використання
багаторівневої схеми «категорія – місто – локація», що дало змогу зменшити
кількість дій користувача для отримання необхідного результату та підвищити
зручність взаємодії з інформаційною системою.
Практичне значення одержаних результатів
Практичне значення роботи полягає у створенні функціонального Android-
додатку та серверної частини, які можуть бути використані як готовий
програмний продукт або як основа для подальшого розширення. Розроблену
систему можна застосовувати для надання довідкової інформації про місця
відпочинку, а також адаптувати для інших регіонів чи категорій локацій.
Отримані результати можуть бути використані у навчальному процесі та при
розробці інформаційних мобільних систем.
Особистий внесок автора
Усі результати, викладені в магістерській роботі, отримані автором
особисто. Автором виконано аналіз предметної області, спроєктовано архітектуру
програмної системи, розроблено серверну частину та Android-додаток,
побудовано UML-діаграми, реалізовано механізми авторизації та фільтрації
даних, а також проведено експериментальне тестування системи.
7
ЧДТУ 252483.008 ПЗ
1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ
1.1 Аналіз наукової та технічної інформації щодо теми дослідження
Сучасна інженерія програмного забезпечення зосереджується на
проєктуванні, розробці та супроводі складних інформаційних систем,
орієнтованих на кінцевого користувача. Особливе місце в цій галузі посідають
мобільні інформаційні системи, які потребують застосування формалізованих
підходів до проєктування, забезпечення якості та масштабованості програмного
забезпечення. Розробка Android-додатків довідкового типу є актуальним
напрямом інженерії програмного забезпечення, оскільки поєднує задачі клієнт-
серверної взаємодії, управління даними, користувацького інтерфейсу та безпеки.
Сфера туризму, готельно-ресторанного бізнесу та культурних послуг
стрімко трансформується під впливом цифровізації. Мобільні додатки стали
ключовим інструментом для пошуку інформації про місця відпочинку, культурні
заходи, готелі та інші локації дозвілля. Дослідження останніх років підкреслюють,
що кінцеві користувачі дедалі частіше віддають перевагу мобільним сервісам, які
забезпечують швидкий доступ до повної, актуальної та структурованої інформації
про місця відпочинку.
У наукових джерелах відзначається, що інформаційні мобільні системи
відіграють важливу роль у формуванні споживчої поведінки туристів та місцевих
мешканців. Згідно з аналітичними дослідженнями Європейської комісії з
цифрового суспільства, тенденція до створення універсальних інформаційних
платформ продовжує зростати: користувачі прагнуть мати в одному додатку усю
довідкову інформацію щодо відпочинку у певному регіоні або країні. Це повністю
корелює з метою даного дослідження: створити Android-додаток, який агрегує
інформацію про готелі, театри й кінотеатри України та полегшує пошук
культурно-туристичної активності.
У науковій літературі останніх років виокремлюються такі ключові напрями
розвитку інформаційних мобільних систем у сфері туризму та дозвілля [1]:
8
ЧДТУ 252483.008 ПЗ
− геолокаційні сервіси – забезпечують рекомендації залежно від
місцеположення користувача;
− каталогізація об’єктів із багаторівневою фільтрацією – сортування за
містом, категорією, популярністю тощо;
− персоналізація контенту – обрані місця, персональні добірки, рейтинги.
− інтеграція з зовнішніми сервісами – системами продажу квитків,
бронювання номерів, маркетинговими платформами;
− підвищена увага до UX/UI – логічна структура навігації, адаптивний
дизайн, мінімалізм інтерфейсу.
З огляду на це, сучасні довідкові мобільні додатки характеризуються
високими вимогами до швидкості обробки даних, актуальності інформації,
інтерактивності та безпеки [3]. Значна частина наукових робіт, присвячених
мобільним інформаційним системам, підкреслює важливість оптимальної
архітектури клієнт-серверної взаємодії. У цьому контексті використання Android
(Kotlin), Spring Boot та PostgreSQL у розробці пропонованого додатку є технічно
обґрунтованим рішенням, що відповідає сучасним стандартам побудови
мобільних систем.
Серед питань, які активно досліджуються, варто відокремити:
− ефективні підходи до побудови REST-архітектури для мобільних
клієнтів;
− застосування OpenAPI-специфікацій для автоматизації генерації
серверного та клієнтського коду;
− методи оптимізації баз даних у системах з великим обсягом довідкової
інформації;
− підвищення надійності мобільних сервісів через багаторівневу
аутентифікацію та захист REST-запитів;
− застосування моделей машинного аналізу даних у туристичних
додатках.
Аналізуючи праці українських і зарубіжних дослідників, можна зробити
висновок, що індустрія мобільних інформаційних систем у сфері туризму та
9
ЧДТУ 252483.008 ПЗ
культурних послуг активно розвивається, проте в Україні все ще залишається
проблема відсутності єдиної довідкової системи, яка б об’єднувала різні типи
локацій відпочинку та надавала можливість пошуку по містах і категоріях. Наявні
сервіси переважно орієнтовані або на бронювання (Booking.com), або виключно
на один тип діяльності (кінотеатри, театри), або є локальними додатками окремих
закладів.
Відповідно, розробка комплексного Android-додатку, здатного поєднати
різні види місць відпочинку та забезпечити зручний пошук, є актуальною задачею
як з точки зору інформаційних технологій, так і з точки зору потреб користувачів.
1.2 Аналіз існуючих аналогів
Для побудови якісної інформаційної системи необхідно дослідити мобільні
сервіси зі схожою функціональністю. У межах роботи проаналізовано п’ять
популярних застосунків, кожен з яких представляє певний тип інформаційних або
культурних платформ.
1.2.1 Аналіз додатку «Multiplex»
Першим прикладом аналогів розглямено додаток «Multiplex» [15]. Сторінки
додатку представлені на рис. 1.1. Даний додаток дозволяє переглядати розклад
фільмів, купувати квитки, переглядати трейлери та акції.
Розглянемо його переваги і недоліки:
Переваги додатку «Multiplex»:
− зручна покупка квитків онлайн;
− актуальний розклад усіх кінотеатрів мережі;
− пуш-сповіщення про акції та прем’єри;
− інтуїтивний та сучасний інтерфейс.
Недоліки додатку «Multiplex»:
− працює лише з кінотеатрами Multiplex, немає даних про інші;
− немає загального каталогу закладів чи інших видів відпочинку;
− обмежений функціонал (тільки кіно).
10
ЧДТУ 252483.008 ПЗ
Рисунок 1.1 – Сторінки додаку «Multiplex»
1.2.2 Аналіз додатку «Booking.com»
Другим додатком в роботі проаналізовано додаток «Booking.com» [14].
Booking.com – це додаток для пошуку, порівняння та бронювання готелів,
апартаментів та інших місць для проживання. Сторінки додатку «Booking.com»
представлено на рис 1.2.
Переваги додатку «Booking.com»:
− величезна база готелів у всьому світі;
− зручні фільтри та сортування;
− відгуки від реальних користувачів;
− можливість бронювання без передоплати (у багатьох випадках).
Недоліки додатку «Booking.com»:
− сильна конкуренція серед закладів, що ускладнює вибір;
− не всі фото відповідають реальності (залежить від власників);
− комісії можуть впливати на кінцеву вартість;
− сфокусований лише на проживанні – немає інших видів відпочинку.
11
ЧДТУ 252483.008 ПЗ
Рисунок 1.2 – Сторінки додатку «Booking.com»
1.2.3 Аналіз додатку «SmartCinema»
Наступним в роботі проаналізовано додаток «SmartCinema» [16].
SmartCinema – додаток для покупки квитків у різних кінотеатрах, зазвичай
агрегатор кількох мереж. Сторінки додатку зображені на рис. 1.3.
Переваги додатку «SmartCinema»:
− можливість переглядати розклади різних кінотеатрів в одному місці;
− зручний пошук за містом, фільмом, часом сеансу;
− онлайн-покупка квитків без черг.
Недоліки додатку «SmartCinema»:
− залежність від того, чи підтримує кінотеатр сервіс;
− обмежений тип контенту – лише кіно;
− інформація про кінотеатри надається по обмеженій кількості міст;
− інколи можливі затримки актуалізації розкладу.
12
ЧДТУ 252483.008 ПЗ
Рисунок 1.3 – Сторінки додатку «SmartCinema»
1.2.4 Аналіз додатку «Контрамарка»
Наступним в роботі проаналізовано додаток «Контрамарка» [17]. Цей
додаток дозволяє шукати, переглядати та купувати квитки на концерти, театри,
фестивалі, спортивні та інші події. У додатку зібрано великий каталог
розважальних, культурних та спортивних заходів. Сторінки додаку зображені на
рис. 1.4.
Переваги додатку «Контрамарка»:
− широкий вибір подій: концерти, вистави, шоу, спортивні події,
фестивалі, майстер-класи – усе зібрано в одному додатку;
− зручність і швидкість: пошук, фільтри, купівля квитків прямо з телефону
– кілька кліків замість довгого пошуку;
− електронні квитки: не треба фізичних носіїв – квиток завжди з вами у
смартфоні;
13
ЧДТУ 252483.008 ПЗ
− мобільність: можна купити та переглянути квитки будь-де – на дорозі, в
дорозі, на відпочинку;
− оновлення й актуальність: афіша подій регулярно оновлюється, видно
майбутні концерти, вистави та інші заходи.
Недоліки додатку «Контрамарка»:
− залежність від організаторів: додаток – просто посередник: якщо
організатор закладу має помилки або затримки, це може вплинути на
покупку або доставку квитків;
− не завжди гарантія сервісу: є скарги, що іноді після оплати квитків –
затримки з підтвердженням або відсутність квитків;
− обмежений спектр – лише події: додаток не охоплює інші види
відпочинку (готелі, ресторани, відпустки тощо), лише
концерти/вистави/спортивні події;
− потреба перевіряти надійність заходів: у разі скасування чи переносу –
відповідальність за сам захід лежить на організаторах, а не на додатку.
Рисунок 1.4 – Сторінки додатку «Контрамарка»
14
ЧДТУ 252483.008 ПЗ
1.2.5 Аналіз додатку «Hotel Ukraina»
Наступним в роботі додаток «Hotel Ukraina» [18]. Даний додаток
представляє інформацію про готель або мережа готелів (залежно від міста), які
пропонують проживання, бронювання номерів та перегляд інформації про
послуги. Сторінки додатку зображені на рис. 1.5.
Рисунок 1.5 – Сторінки додатку «Hotel Ukraina»
Переваги додатку «Hotel Ukraina»:
− простий і зрозумілий сервіс для бронювання конкретного готелю;
− детальна інформація про доступні номери;
− актуальні ціни та фото без посередників;
− можливість прямого контакту з адміністрацією готелю.
15
ЧДТУ 252483.008 ПЗ
Недоліки додатку «Hotel Ukraina»:
− це локальний сервіс, не агрегатор – охоплює лише один готель;
− обмежений функціонал порівняно з глобальними платформами;
− немає різноманітних можливостей або оглядів інших закладів;
− відсутність універсального пошуку інших місць для проживання.
1.3 Пошук методів та засобів для вирішення поставлених завдань
Створення мобільного Android-додатку, який виконує функції довідкової
системи для пошуку місць відпочинку в Україні, потребує вибору оптимальних
методів, технологій і підходів. Завданням цього підрозділу є обґрунтування
використаних засобів розробки та аналіз можливих альтернатив.
1.3.1 Вибір архітектурного підходу для мобільного додатку
У сучасній розробці Android-додатків пріоритетним є використання
архітектурних патернів, які забезпечують [1; 11]:
− розподіл відповідальностей;
− просте тестування;
− масштабованість;
− легкість підтримки;
− можливість розширення функціональності.
Найпоширенішими архітектурними підходами є:
1 MVC (Model–View–Controller).
Історично перший підхід, який сьогодні майже не застосовується в Android
через надмірно навантажений контролер та складність підтримки великих
проєктів.
2 MVP (Model–View–Presenter).
Популярний у минулому підхід, розвинувся у відповідь на недоліки MVC.
Проте Presenter з часом стає перевантаженим, і підхід втрачає актуальність.
3 MVVM (Model–View–ViewModel).
Наразі є стандартом де-факто в Android-розробці. Переваги:
− розділення UI та бізнес-логіки;
16
ЧДТУ 252483.008 ПЗ
− реактивність через LiveData/StateFlow;
− відсутність прямої залежності View від Model;
− полегшені UI-тести;
− менше дублювання коду.
MVVM було обрано для розробки даного мобільного додатку, оскільки він
забезпечує стабільну, передбачувану та гнучку архітектуру, що відповідає
сучасним вимогам Android-додатків.
1.3.2 Вибір клієнт-серверної взаємодії
Для обміну інформацією між мобільним клієнтом і сервером
використовуються такі популярні підходи:
− REST API – найбільш поширений, легкий та універсальний підхід, що
використовує HTTP-протокол;
− GraphQL – більш гнучкий, але складніший у реалізації;
використовується переважно у великих комерційних сервісах із високою
варіативністю даних;
− gRPC – високошвидкісний RPC-протокол, який застосовують у
високонавантажених мікросервісах, але не є оптимальним для
стандартних мобільних каталогів.
Для реалізації серверної частини було обрано REST API [10], оскільки:
− він повністю відповідає задачам довідкової системи;
− є найпростішим для інтеграції в Android (через Retrofit);
− дозволяє легко документувати ендпоінти;
− забезпечує зрозумілу взаємодію з користувачем;
− повністю сумісний із OpenAPI.
1.3.3 Документування API через OpenAPI.yaml
OpenAPI – формат, який дозволяє описати структуру API:
− HTTP-методи;
− маршрути;
− параметри запитів;
17
ЧДТУ 252483.008 ПЗ
− моделі даних;
− типи відповідей;
− коди помилок.
Переваги використання OpenAPI у цьому проєкті:
1 Автоматична генерація серверного коду на Spring Boot.
2 Генерація DTO та Retrofit-клієнтів для Android.
3 Зменшення кількості ручної роботи та помилок.
4 Єдина точка документації для всієї команди/проєкту.
1.3.4 Вибір технологій для бекенду
У сучасному серверному програмуванні для побудови REST-додатків
найефективнішими є такі фреймворки:
− Spring Boot (Java);
− Node.js + Express;
− 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 або аналог – для конвертації моделей.
18
ЧДТУ 252483.008 ПЗ
1.3.5 Вибір СКБД
Розглядалися такі системи управління базами даних:
Таблиця 1.1
Таблиця порівняння СКБД
СКБД Переваги Недоліки
слабший синтаксис для
MySQL швидка, популярна
складних запитів
не підходить для
SQLite вбудована у Android, проста
централізованих систем
надлишкова для
MongoDB гнучка структура структурованих
довідкових даних
потужна, підтримує складні вимагає серверного
PostgreSQL
зв’язки, надійна оточення
PostgreSQL було обрано, оскільки додаток працює з чітко структурованими
сутностями.
1.3.6 Технології та бібліотеки для Android [4; 5]
У розробці мобільного застосунку доцільно використовувати:
− Kotlin – сучасна мова Android;
− XML layout – для верстки;
− Retrofit – для роботи з REST API;
− Gson/Moshi – для серіалізації моделей;
− ViewModel + LiveData/StateFlow;
− Navigation Component;
− Coil/Glide – для зображень;
− RecyclerView – для списків.
Обраний технологічний стек забезпечує:
− швидкість розробки;
− читабельність коду;
− готовність до розширення;
− стандартність архітектури.
19
ЧДТУ 252483.008 ПЗ
1.3.7 Підсумок підрозділу
Обрані методи та засоби забезпечують [2]:
− стабільну та масштабовану клієнт-серверну архітектуру;
− швидкий обмін даними між Android-додатком і бекендом;
− можливість подальшого розширення додатку;
− відповідність сучасним тенденціям мобільної індустрії.
1.4 Актуальні проблеми, що виникають при створенні інформаційних
мобільних систем
Розробка мобільних інформаційних систем, орієнтованих на каталогізацію
та надання довідкових даних, має ряд особливостей і викликів [2]. Ці проблеми
стосуються як мобільної частини, так і серверної інфраструктури, а також
організації контенту, масштабованості та забезпечення безпеки користувачів.
1.4.1 Актуальність та достовірність інформації
Для довідкових систем, що містять інформацію про місця відпочинку,
важливо забезпечити:
− оперативне оновлення даних;
− достовірність інформації (адреси, графіки роботи, описи);
− відсутність застарілих даних, які можуть ввести користувача в оману.
Особливо це критично для культурних закладів, де програми, репертуари та
події змінюються часто. Системи без регулярного оновлення швидко втрачають
цінність.
1.4.2 Масштабованість і продуктивність
Навіть довідкова система може мати значне навантаження, якщо:
− кількість користувачів зросте;
− каталог локацій розшириться;
− будуть додані нові фільтри, категорії або атрибути;
− система почне обробляти зображення або інші медіа.
Проблеми масштабованості проявляються у:
20
ЧДТУ 252483.008 ПЗ
− збільшенні часу відповіді сервера;
− зростанні навантаження на базу даних;
− складності кешування.
Бекенд повинен бути готовий до горизонтального та вертикального
масштабування. Використання Spring Boot у поєднанні з PostgreSQL допомагає
подолати ці виклики.
1.4.3 Проблеми з класифікацією даних та фільтрами
У мобільних довідкових системах важливо правильно організувати
структуру даних:
− визначити категорії локацій;
− побудувати ієрархію місто → категорія → список місць;
− забезпечити однозначність даних (наприклад, уникнути дублювання
локацій).
Невдала структура каталогу призводить до:
− складності або повільності пошуку;
− незадоволення користувача через складну навігацію;
− поганої «знаходженості» об’єктів.
1.4.4 Забезпечення швидкодії мобільного інтерфейсу
Мобільний застосунок часто працює в умовах обмеженої продуктивності
пристроїв та нестабільного інтернет-з’єднання. Основні проблеми, які потрібно
враховувати:
− оптимізація списків (RecyclerView) при великій кількості елементів;
− використання кешування зображень (Coil/Glide);
− мінімізація кількості REST-запитів (наприклад, отримання даних по
категоріях пакетно);
− уникнення надмірної кількості анімацій;
− обробка помилок мережі.
UX також суттєво впливає на користувацький досвід. Навіть за ідеального
бекенду погано оптимізований UI зменшує задоволеність користувача [6].
21
ЧДТУ 252483.008 ПЗ
1.4.5 Розмежування доступу і безпека
Додаток містить авторизацію, що автоматично накладає такі вимоги:
− безпечне зберігання токенів (SharedPreferences або
EncryptedSharedPreferences);
− шифрування конфіденційних даних;
− захист API через JWT;
− обмеження доступу до ендпоінтів, що управляють "Обраним".
Проблеми безпеки включають:
1 Перехоплення даних при незахищених запитах (HTTP → потрібно
HTTPS).
2 Уразливості, пов’язані з неправильним зберіганням токенів.
3 Ін'єкції (SQL, JSON) на стороні сервера.
4 XSS або CSRF для веб-частин (неактуально для Android, але актуально
для бекенду).
Spring Security та JWT токени дозволяють ефективно розв’язати ці
проблеми.
1.4.6 Проблеми з інтеграцією зі сторонніми ресурсами
В даній системі не реалізовано покупки всередині додатку – користувач
переходить на зовнішнє посилання.
Можливі проблеми:
− сторонній сервіс може змінити URL;
− сервіс може бути недоступний;
− може змінитися модель інтеграції (параметри, токени).
Це потребує регулярного моніторингу актуальності зовнішніх посилань, що
також стосується готелів, театрів і кінотеатрів.
1.4.7 Уніфікація даних різних типів локацій
Оскільки додаток містить три категорії локацій:
1 готелі,
2 кінотеатри,
22
ЧДТУ 252483.008 ПЗ
3 театри,
то проблемами стають:
− уніфікація описів;
− уніфікація структури зображень;
− стандартизація атрибутів;
− організація спільних полів та унікальних для кожної категорії.
Погано спроєктована модель даних згодом ускладнило б розвиток додатку.
1.4.8 Забезпечення зручності користування (UX-проблеми)
Серед поширених UX-проблем в інформаційних мобільних системах:
− надто багато кроків для пошуку;
− занадто довгі списки, які не групуються;
− перевантажений інтерфейс;
− незрозумілі елементи навігації;
− повільне завантаження зображень;
− відсутність «Обраного».
Розроблений додаток вирішує ці проблеми завдяки:
− простому трирівневому фільтру (категорія → місто → список місць);
− особистому кабінету;
− оптимізованій структурі навігації;
− лаконічному UI.
До ключових проблем, які необхідно врахувати при створенні такої
інформаційної системи, належать:
− актуальність і повнота даних;
− швидкодія клієнта та сервера;
− оптимізація моделі даних;
− безпека та авторизація;
− уніфікація структури даних;
− зручність навігації;
− інтерактивність та стабільність роботи.
23
ЧДТУ 252483.008 ПЗ
Проєктований мобільний додаток вирішує більшість цих проблем за
рахунок продуманої архітектури, сучасного технологічного стеку та
структурованої моделі даних.
1.5 Конкретизація завдання магістерської роботи
Розробка мобільного Android-додатку для пошуку місць відпочинку в
Україні є багатокомпонентним завданням, яке включає проєктування інтерфейсу,
побудову серверної частини, формування бази даних, організацію взаємодії
клієнта та сервера, а також створення довідкової моделі для категоризації локацій.
У цьому підрозділі визначено конкретні задачі, які вирішуються в межах
магістерської роботи, та обґрунтовано їх необхідність.
1.5.1 Загальна мета розробки
Метою даної магістерської роботи є створення інформаційного мобільного
застосунку, який:
− надає користувачам структуровану та актуальну інформацію про місця
відпочинку в Україні;
− об’єднує готелі, кінотеатри та театри в одному зручному інтерфейсі;
− дозволяє здійснювати пошук по категоріях і містах;
− забезпечує перегляд детального опису кожного місця;
− дозволяє авторизованим користувачам додавати локації до «Обраного»;
− надає можливість переходу до зовнішніх ресурсів для бронювання чи
купівлі квитків.
Таким чином, додаток виступає єдиним інформаційним довідником
культурно-туристичних місць, доступних користувачам в Україні.
1.5.2 Постановка задачі для мобільного застосунку
Для досягнення мети необхідно реалізувати такі функції мобільного клієнта:
1 Реалізація механізму авторизації та аутентифікації:
− вхід за email та паролем;
− отримання JWT-токена;
24
ЧДТУ 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:
25
ЧДТУ 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 Функціональні вимоги до системи
Основні функції користувача:
1 Перегляд каталогу місць відпочинку.
2 Вибір категорії місця.
3 Вибір міста.
4 Перегляд списку локацій.
5 Перегляд детальної інформації.
6 Перехід за зовнішнім посиланням.
7 Авторизація.
8 Додавання місць до «Обраного» (авторизованим користувачем).
26
ЧДТУ 252483.008 ПЗ
9 Перегляд списку обраних місць.
Адміністративні функції:
− додавання нових даних;
− оновлення інформації;
− видалення старих записів.
1.5.5 Нефункціональні вимоги [3]
1 Продуктивність:
− час відповіді сервера – не більше 200–300 мс;
− завантаження списку локацій – < 1 секунди при стабільному
інтернеті.
2 Зручність користування [13]:
− інтерфейс повинен бути інтуїтивно зрозумілим;
− кількість кроків до знаходження об’єкта – мінімальна [13].
3 Надійність:
− система повинна коректно працювати при нестабільному інтернеті;
− сервіси мають автоматично відновлюватися після збою.
4 Безпека:
− використання HTTPS;
− стійке шифрування токенів;
− захист REST API.
5 Масштабованість:
− можливість розширення каталогу;
− можливість додавання нових категорій у майбутньому.
1.5.6 Програмна реалізація як результат магістерської роботи
Магістерська робота повинна включати:
− спроєктований та реалізований Android-додаток;
− бекенд-сервер, реалізований на Spring Boot [7];
− документовані ендпоінти (OpenAPI.yaml) [8];
− підготовлену базу даних PostgreSQL [9];
27
ЧДТУ 252483.008 ПЗ
− тестування ключових функцій [19];
− оформлені UML-діаграми, що описують систему;
− аналіз ефективності та обґрунтування вибору технологій.
Таким чином, конкретизація завдання дозволяє системно визначити
функціонал мобільного додатку, структуру серверної частини, вимоги до бази
даних та архітектури програмного забезпечення. Це створює основу для побудови
подальших теоретичних і практичних розробок у наступних розділах.
1.6 Формулювання місця автора в розв’язанні задачі
Цей підрозділ визначає, який саме внесок виконав автор роботи у створення
інформаційної системи, які завдання були виконані самостійно, а які –
використані в готовому вигляді або на основі існуючих технологічних рішень.
Згідно з вимогами методичних вказівок, важливо чітко окреслити межі
індивідуальної роботи та частину, що була реалізована автором під час розробки
мобільного застосунку та серверної частини [12].
1.6.1 Внесок автора у концепцію та постановку завдання
Було сформувано:
− концепцію єдиного мобільного довідника культурно-туристичних
локацій;
− підхід до структури навігації: категорія → місто → список місць;
− визначення основних функціональних вимог;
− постановку задачі перед системою both на клієнтському, і на серверному
рівні;
− вибір сценаріїв взаємодії користувача із системою.
Особливістю авторського бачення є відмова від комерційної
функціональності всередині додатку (бронювання, купівля квитків) та
фокусування на довідковому контенті – це принципово формує специфіку
проєктованої архітектури.
1.6.2 Внесок автора у проєктування мобільного додатку
28
ЧДТУ 252483.008 ПЗ
При проєктування мобільного додатку було виконано:
1 Проєктування структури інтерфейсу Android-додатку:
− головний екран;
− екран вибору категорій;
− екран вибору міста;
− екран списку локацій;
− екран детального перегляду місця;
− екран авторизації;
− особистий кабінет користувача.
2 Розробка макетів.
Було створено основні XML-файли інтерфейсу з дотриманням логіки
користувацького досвіду (UX), включаючи застосування [4]:
− ConstraintLayout;
− RecyclerView;
− Toolbar;
− поля вводу та кнопки;
− екрани порожнього стану.
3 Проєктування навігації.
Було визначено структуру переходів між екранами, що забезпечує
інтуїтивну взаємодію користувача з системою.
4 Реалізація архітектури MVVM [5].
Було побудувано ключові компоненти:
− ViewModel-и для кожного функціонального екрану;
− репозиторії для роботи з API;
− data-класи для моделювання відповідей сервера;
− менеджер авторизації для роботи з JWT.
5 Інтеграція з REST API.
Було виконано налаштування клієнта Retrofit, моделювання DTO та
інтеграцію всіх основних серверних ендпоінтів.
1.6.3 Внесок автора у розробку серверної частини
29
ЧДТУ 252483.008 ПЗ
При розробці серверної частини було реалізовано:
1 Проєктування структури бази даних PostgreSQL:
− таблиці місць (локацій),
− таблиці міст,
− таблиці категорій,
− таблиці користувачів,
− зв’язувальні таблиці для «Обраного».
2 Роботу над OpenAPI-специфікацією.
Було підготував openapi.yaml, на основі якої здійснювалася генерація
контролерів та моделей.
3 Реалізацію CRUD-операцій.
Для основних сутностей — міста, категорії, локації, користувачі, обране.
4 Імплементацію Spring Security + JWT.
Включаючи:
− фільтри JWT;
− налаштування безпеки;
− ролі користувачів;
− захист POST-запитів на створення обраних місць.
5 Забезпечення взаємодії з мобільним застосунком.
Реалізувано логіку:
− формування відповідей;
− обробки виключень;
− логування;
− налаштування CORS.
1.6.4 Внесок автора у дослідження аналогів та моделювання системи
Під час роботи було:
− проведено аналіз п’яти мобільних додатків-аналогів;
− визначено сильні та слабкі сторони аналогів;
− обґрунтувано потребу в комплексному застосунку, який поєднує кілька
типів локацій;
30
ЧДТУ 252483.008 ПЗ
− побудувано UML-діаграми, необхідні для структурного аналізу (Use
Case, Activity, Class, Sequence, Deployment).
1.6.5 Формування авторського бачення системи
Було розроблено ключову концепцію додатку, яка полягає у:
− поєднанні різних типів локацій;
− поділі інформації по містах;
− мінімалістичній логіці пошуку;
− доступності довідкової інформації без зайвих дій;
− зручній роботі з «Обраним»;
− можливості швидкого переходу до зовнішніх сервісів.
Завдяки поєднанню цих ідей створено унікальний формат мобільного
довідника, який не має прямих аналогів на ринку.
31
ЧДТУ 252483.008 ПЗ
Висновки до розділу 1
У першому розділі магістерської роботи було проведено всебічний
теоретичний та аналітичний огляд предметної області, технологій, підходів і
існуючих розв’язань, що мають відношення до створення мобільної
інформаційної системи для пошуку місць відпочинку в Україні.
На основі аналізу наукової і технічної літератури встановлено, що
цифровізація туристичної та культурної сфер є одним із ключових напрямів
розвитку інформаційних технологій. Сучасні мобільні застосунки активно
використовуються як основне джерело інформації для користувачів, які шукають
культурні події, місця проживання та можливості дозвілля. Проте ринок не має
єдиного рішення, яке поєднувало б кілька типів локацій, зручні фільтри, роботу з
особистим кабінетом і функцію «Обране» у рамках одного додатку.
Було детально проаналізовано п’ять існуючих аналогів: Booking.com,
Multiplex, SmartCinema, Контрамарка та Hotel Ukraina. На основі порівняння
встановлено, що:
− кожен з них охоплює лише окремий сегмент ринку;
− жоден застосунок не об'єднує готелі, кінотеатри і театри;
− відсутні системи, які дозволяють здійснювати пошук виключно на
довідковому рівні без бронювання;
− користувачеві часто доводиться використовувати декілька окремих
додатків, що знижує зручність і швидкість взаємодії.
Таким чином, перший розділ формує основу для подальших досліджень та
розробки програмної системи. Він демонструє актуальність проєкту, обґрунтовує
його необхідність та показує комплексний підхід до розв’язання поставлених
задач.
32
ЧДТУ 252483.008 ПЗ
2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ
2.1 Теоретичні дослідження
Створення інформаційних мобільних систем є однією з ключових тенденцій
сучасної індустрії програмного забезпечення. Такі системи виступають
інструментами, що забезпечують доступ до структурованої інформації, яка може
містити геодані, описи об’єктів, рейтинги, мультимедійні матеріали, параметри
фільтрації тощо. Зокрема, у сфері культурного та туристичного дозвілля мобільні
системи інтегрують довідковий контент з можливостями пошуку, персоналізації
та рекомендацій.
Сутність інформаційної мобільної системи полягає у забезпеченні
оперативного доступу до інформації, незалежно від місця та часу, за допомогою
смартфона чи планшета. Основними характеристиками таких систем є
мобільність, автономність, адаптивність та інтерактивність. Вони повинні
працювати ефективно у змінних умовах якості інтернет-з’єднання, обмежених
ресурсах пристрою та різноманітних сценаріях взаємодії користувача.
2.1.1 Архітектурні принципи побудови мобільних інформаційних систем
Мобільні додатки довідкового типу можуть будуватися на різних
архітектурних моделях [1]. Найпоширеніші:
1 Клієнт-серверна архітектура.
Класичний підхід, у якому мобільний додаток виступає клієнтом, а сервер –
постачальником даних.
Переваги:
− простота оновлення серверної частини;
− централізоване зберігання даних;
− можливість масштабування;
− незалежність клієнта від внутрішньої структури БД.
Недоліки:
− залежність від якості мережі;
− необхідність адміністрування серверної інфраструктури.
33
ЧДТУ 252483.008 ПЗ
2 Хмарні серверні рішення (Backend-as-a-Service).
Приклади: Firebase, Supabase.
Зменшують витрати на серверну частину, але мають обмеження в
кастомізації логіки.
3 Локальні гібридні системи.
Дані зберігаються частково на пристрої (кеш), частково – на сервері.
Це підвищує відмовостійкість, але ускладнює синхронізацію даних.
Для розроблюваної системи оптимальною є класична клієнт-серверна
архітектура.
2.1.2 Інформаційна модель мобільної системи
Інформаційна модель описує, які дані зберігає система та як вони пов’язані
між собою. Для задачі, що розглядається, ключовими елементами моделі є:
− місто, у якому розташована локація;
− локація – для кожної з категорій окрема сутність, що містить опис місця
відпочинку;
− користувач – містить аутентифікаційні дані;
− обране – зв’язок між користувачем і локацією.
Таким чином формується базова сутнісно-зв’язкова структура.
2.1.3 Принципи організації даних у довідкових системах
Теоретичною основою побудови інформаційних систем є:
1 Структурованість.
Дані повинні мати чітко визначені атрибути (назва, місто, опис, категорія,
URL).
2 Нормалізація.
База даних має уникати дублювання інформації та забезпечувати логічність
побудови зв’язків.
3 Уніфікація формату даних.
Кожен об’єкт має мати однакову структуру незалежно від категорії.
34
ЧДТУ 252483.008 ПЗ
У нашому проєкті це реалізується через універсальну модель 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});
− підтримка різних форматів – у нашому проєкті використовується JSON.
Дотримання REST-стандартів забезпечує:
− зручність у підтримці;
− легкість інтеграції;
− масштабованість;
35
ЧДТУ 252483.008 ПЗ
− можливість автоматичної генерації документації.
2.1.5 Моделювання користувацької взаємодії
Для довідкових систем ключовим є прогнозований і оптимізований шлях
користувача (user flow). Теоретично він визначається як мінімальна кількість
переходів до отримання результату.
Для нашої системи базовий користувацький шлях:
− відкрити додаток;
− вибрати категорію;
− вибрати місто;
− отримати список локацій;
− перейти до детальної картки місця;
− за потреби додати до «Обраного» або перейти за зовнішнім посиланням.
2.1.6 Принципи забезпечення безпеки в мобільних системах
Безпека є важливою складовою теоретичних засад розробки будь-якої
інформаційної системи. Основні теоретичні аспекти:
1 Аутентифікація та авторизація.
У проєкті використовується JWT, що базується на криптографічних
алгоритмах.
2 Шифрування даних.
Рекомендовано використовувати HTTPS.
3 Захист локального сховища.
На стороні мобільного клієнта токен зберігається у захищеному контейнері
(SharedPreferences або EncryptedSharedPreferences).
4 Логування і моніторинг.
Сервер повинен реєструвати всі важливі операції.
Теоретичні основи побудови інформаційних мобільних систем визначають:
− принципи організації даних;
− архітектури клієнт-серверної взаємодії;
− моделі користувацьких сценаріїв;
36
ЧДТУ 252483.008 ПЗ
− вимоги до безпеки;
− підходи до фільтрації та структурування інформації.
Ці положення формують методологічний фундамент подальшої розробки
системи, яка буде розглянута в контексті практичної реалізації у наступних
підрозділах.
2.1.7 Математичні моделі і формалізація задачі
Створення інформаційної мобільної системи для пошуку місць відпочинку в
Україні потребує формалізованого опису процесів, що забезпечують
функціонування системи. Математичні моделі дозволяють:
− формально визначити структуру даних;
− описати логіку фільтрації та пошуку;
− змоделювати взаємодію користувача з системою;
− визначити критерії ефективності роботи.
Наведемо теоретичні моделі, які відображають основні процеси у системі.
2.1.7.1 Формальна модель інформаційної структури
У загальному випадку система містить множину локацій:
L={l1,l2,...,ln} (2.1)
де:
− L – це множина всіх місць відпочинку, представлених у системі Android-
додатку для пошуку місць відпочинку в Україні;
− l1,l2,...,ln – окремі елементи множини L, де кожен елемент lᵢ відповідає
одному конкретному місцю відпочинку (наприклад, готелю, кінотеатру
або театру).
Кожна локація є структурованим об’єктом, що описується кортежем:
li=(uuidi, ci, mi, namei, desci, addri, urli, longi, lati, imgi) (2.2)
37
ЧДТУ 252483.008 ПЗ
де:
− – ідентифікатор локації;
− – категорія (hotel, cinema, theatre);
− – місто;
− – назва;
− – опис;
− – адреса;
− – зовнішнє посилання;
− longi, lati – координати;
− imgi – посилання на зображення.
Категорії утворюють множину:
(2.3)
де:
− C – множина можливих категорій місць відпочинку, за якими
здійснюється класифікація об’єктів у системі;
− hotel – категорія, що об’єднує готелі;
− cinema – категорія, що включає кінотеатри;
− theater – категорія, що охоплює театри.
Міста:
(2.4)
де:
− М – множина міст, інформація про які використовується в інформаційній
системі для групування та фільтрації місць відпочинку за географічною
ознакою;
− m1,m2,...,mk – окремі елементи множини M, де кожен елемент mk
відповідає одному конкретному місту України, в якому знаходяться
місця відпочинку.
Таким чином, система є відображенням:
38
ЧДТУ 252483.008 ПЗ
(2.5)
де:
− f – функція фільтрації (відбору) місць відпочинку, що реалізує логіку
пошуку в Android-додатку;
− C × M – декартовий добуток множини категорій C та множини міст M,
який представляє всі можливі пари виду;
− L – множина всіх місць відпочинку, представлених у системі;
− L
2 – число множини L, тобто множина всіх підмножин L.
Функція повертає множину локацій, що належать вибраній категорії і місту.
2.1.7.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, що дозволяє зменшити складність до:
O(logn) (2.8)
39
ЧДТУ 252483.008 ПЗ
2.1.7.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.7.4 Модель додавання до «Обраного»
Кожен користувач має множину обраних локацій:
Fu = {li1,li2,...,lim} (2.12)
Функція додавання до обраного визначається як:
40
ЧДТУ 252483.008 ПЗ
add(li,u) : Fu = Fu ∪ {li} (2.13)
Функція видалення:
remove(li,u) : Fu = Fu ∖ {li} (2.14)
Залежно від реалізації, зв’язок між користувачем і локацією описується в
базі даних через таблицю:
Favorites(user_id,location_id)
що відповідає моделі Many-to-Many.
2.1.7.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)
У розробленій системі:
41
ЧДТУ 252483.008 ПЗ
path_length=3 (2.17)
що відповідає оптимальній моделі «три кліки до результату».
2.1.7.6 Критерії ефективності системи [3]
Ефективність роботи можна формалізувати через такі критерії:
1 Час відповіді сервера:
Tresp ≤ 300 ms (2.18)
2 Час завантаження списку локацій:
Tload ≤ 1 s (2.19)
3 Продуктивність БД:
Оцінюється як середній час виконання запиту:
(2.20)
4 Надійність авторизації:
Ймовірність компрометації токена:
Pcompromise → 0 (2.21)
5 Кількість кроків до інформації:
steps ≤ 3, (2.22)
що є показником зручності.
2.1.8 Теорія та гіпотеза дослідження
2.1.8.1 Теорія дослідження
42
ЧДТУ 252483.008 ПЗ
Android-додаток для пошуку місць відпочинку в Україні розробляється із
застосуванням сучасних технологій мобільної розробки та підходів до створення
інформаційних систем довідкового типу. Основна увага зосереджена на
використанні клієнт-серверної архітектури, що дозволяє забезпечити ефективну
взаємодію між мобільним застосунком та серверною частиною, а також
централізоване зберігання та обробку даних про місця відпочинку.
Теоретичну основу дослідження становлять принципи проєктування
мобільних інформаційних систем, методи організації та подання довідкової
інформації, а також підходи до забезпечення зручності використання Android-
додатків. Використання категоризації місць відпочинку (готелі, кінотеатри,
театри) та фільтрації за містами відповідає загальноприйнятим теоретичним
моделям структурування інформації, орієнтованим на спрощення пошуку та
підвищення ефективності взаємодії користувача з системою.
Крім того, у межах теорії дослідження враховуються принципи побудови
RESTful-сервісів, що забезпечують стандартизований доступ до даних, а також
концепції користувацького досвіду, які передбачають мінімізацію кількості дій,
необхідних для отримання потрібної інформації, та забезпечення інтуїтивно
зрозумілого інтерфейсу мобільного застосунку.
2.1.8.2 Гіпотеза дослідження
Гіпотезою дослідження є припущення, що застосування інженерних
підходів до проєктування та розробки програмного забезпечення під час
створення Android-додатку довідкового типу для пошуку місць відпочинку в
Україні на основі клієнт-серверної архітектури та сучасних технологій мобільної і
серверної розробки забезпечить підвищення зручності та ефективності доступу
користувачів до інформації про культурні й туристичні об’єкти, а також створить
передумови для подальшого масштабування та розвитку даної інформаційної
системи.
Предметне визначення понять.
Android-додаток для пошуку місць відпочинку.
43
ЧДТУ 252483.008 ПЗ
Мобільний програмний продукт, призначений для перегляду довідкової
інформації про готелі, кінотеатри та театри з можливістю фільтрації за
категоріями та містами.
Клієнт-серверна архітектура.
Підхід до побудови інформаційної системи, за якого клієнтська частина
(Android-додаток) відповідає за взаємодію з користувачем, а серверна частина —
за обробку запитів, бізнес-логіку та доступ до бази даних.
Категоризація та фільтрація даних.
Механізм організації інформації про місця відпочинку, що передбачає поділ
об’єктів за типами та подальший відбір за географічною ознакою з метою
спрощення пошуку.
Зручність використання мобільного застосунку.
Характеристика інформаційної системи, що визначає легкість навігації,
зрозумілість інтерфейсу та мінімальну кількість дій, необхідних користувачу для
отримання потрібної інформації.
Розвиток інформаційної системи.
Можливість подальшого розширення функціональних можливостей
Android-додатку, зокрема додавання нових категорій місць, міст або інтеграції з
зовнішніми сервісами без суттєвої перебудови архітектури.
2.2 Експериментальні дослідження
Експериментальна частина дослідження спрямована на перевірку
працездатності та ефективності розробленої інформаційної мобільної системи. У
цьому підрозділі описано методику проведення експериментів, середовище
тестування, сценарії використання та результати оцінки продуктивності
клієнтської та серверної частин.
2.2.1 Мета та завдання експериментальних досліджень
Метою експериментальних досліджень є підтвердження того, що
розроблений Android-додаток і серверна частина:
− коректно реалізують функціональні вимоги;
44
ЧДТУ 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]:
45
ЧДТУ 252483.008 ПЗ
1 Функціональне тестування.
Перевірка відповідності реалізованого функціоналу вимогам.
2 Навантаження тестування (Load testing).
Імітація одночасних запитів до серверних ендпоінтів.
3 Тестування продуктивності.
Вимірювання часу відповіді та завантаження контенту.
4 Тестування стабільності.
Перевірка коректної роботи при втраті мережі та повторному підключенні.
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. Робота з «Обраним»:
− додавання локації;
− видалення локації;
− отримання списку обраних;
46
ЧДТУ 252483.008 ПЗ
− середній час відповіді: ≤ 300 мс.
2.2.5 Аналіз отриманих результатів
Результати експериментів демонструють, що:
− система відповідає встановленим нефункціональним вимогам;
− середній час відповіді сервера не перевищує допустимі значення;
− клієнтська частина працює стабільно на пристроях середнього класу;
− логіка фільтрації виконується коректно;
− авторизація і робота з «Обраним» реалізовані надійно.
Отримані показники свідчать про ефективність обраної архітектури та
технологічного стеку.
2.2.6 Обмеження експериментального дослідження
Слід зазначити, що:
− тестування проводилося в умовах обмеженого навантаження;
− не враховано пікові сценарії з тисячами одночасних користувачів;
− не досліджувалась робота CDN для зображень.
Ці аспекти можуть бути розглянуті у подальших дослідженнях або при
комерційному впровадженні.
Експериментальні дослідження підтвердили працездатність і ефективність
розробленої системи. Показники продуктивності відповідають заданим вимогам, а
архітектура забезпечує стабільну роботу додатку при типових сценаріях
використання.
47
ЧДТУ 252483.008 ПЗ
Висновки до розділу 2
У другому розділі магістерської роботи було проведено теоретичні та
експериментальні дослідження, спрямовані на обґрунтування архітектурних,
алгоритмічних і технологічних рішень для розробки Android-додатку з пошуку
місць відпочинку в Україні.
Було розглянуто теоретичні основи побудови інформаційних мобільних
систем. Проаналізовано сучасні архітектурні підходи до розробки мобільних
застосунків, визначено доцільність використання клієнт-серверної архітектури з
REST-взаємодією. Обґрунтовано принципи структуризації довідкової інформації,
формування інформаційної моделі та організації користувацьких сценаріїв.
Значну увагу приділено питанням безпеки, зокрема використанню токен-
базованої авторизації.
Також виконано формалізацію задачі та побудову математичних моделей
основних процесів системи. Запропоновано формальні описи структури даних,
алгоритмів фільтрації локацій за категоріями та містами, механізмів авторизації
користувачів і роботи з обраними місцями. Також змодельовано навігаційну
структуру мобільного додатку у вигляді орієнтованого графа та визначено
ключові критерії ефективності системи.
На останок проведено експериментальну оцінку продуктивності та
стабільності розробленої системи. Описано середовище тестування, методику
проведення експериментів і типові сценарії використання. Отримані результати
підтвердили відповідність розробленого програмного забезпечення
функціональним і нефункціональним вимогам, зокрема щодо швидкодії,
зручності використання та надійності авторизації.
Узагальнюючи результати другого розділу, можна стверджувати, що обрані
теоретичні підходи, математичні моделі та практичні рішення є обґрунтованими і
створюють надійну основу для реалізації програмного продукту. Отримані
висновки дозволяють перейти до детального розгляду процесу проєктування та
реалізації Android-додатку, що буде здійснено у наступному розділі.
48
ЧДТУ 252483.008 ПЗ
3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ
3.1 Моделювання предметної області
Моделювання предметної області є критично важливим етапом розробки,
оскільки саме на цьому етапі визначається структура компонентів, спосіб їх
взаємодії, розподіл відповідальності та масштабованість рішення. Для реалізації
Android-додатку з пошуку місць відпочинку в Україні було обрано багаторівневу
клієнт-серверну архітектуру, яка забезпечує гнучкість, розширюваність і
зручність супроводу.
Розроблювана система призначена для надання користувачам довідкової
інформації про місця відпочинку в Україні. Основною метою системи є
спрощення процесу пошуку культурного та туристичного відпочинку шляхом
об’єднання різних типів локацій в одному мобільному застосунку. Система
орієнтована на туристів та користувачів, які шукають місця для дозвілля у різних
містах України.
Загальний функціонал програмної системи передбачає можливість
перегляду інформації про місця відпочинку без здійснення бронювання або
купівлі квитків. Користувачі можуть ознайомлюватися з описом локацій,
переглядати зображення, отримувати основну довідкову інформацію та
переходити за зовнішніми посиланнями для здійснення бронювання або купівлі
квитків на сторонніх сервісах.
Основними типами місць відпочинку, що підтримуються системою на
даний момент, є готелі, кінотеатри та театри. Для зручності користувачів
реалізовано поділ локацій за категоріями та можливість фільтрації за містами.
Такий підхід дозволяє швидко отримувати релевантну інформацію відповідно до
потреб користувача.
Система підтримує механізм авторизації користувачів, який дозволяє
отримати доступ до персоналізованих функцій. Авторизований користувач має
49
ЧДТУ 252483.008 ПЗ
можливість додавати локації до списку «Обране» та надалі швидко переходити до
збережених місць через особистий кабінет. Функціонал «Обране» доступний
виключно для авторизованих користувачів.
Загальний процес взаємодії користувача з системою включає запуск
мобільного додатку, вибір категорії місця відпочинку, вибір міста та перегляд
відповідного списку локацій. За необхідності користувач проходить процедуру
авторизації для роботи з персоналізованими функціями. Взаємодія між
клієнтською та серверною частинами здійснюється через REST API з
використанням захищеного протоколу HTTPS.
Таким чином, предметна область розроблюваної програмної системи
охоплює процеси пошуку, перегляду та збереження довідкової інформації про
місця відпочинку різних категорій, забезпечуючи зручний доступ до актуальної
інформації для широкого кола користувачів.
3.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області
Предметна область розроблюваної програмної системи охоплює процеси
зберігання, обробки та надання довідкової інформації про місця відпочинку в
Україні, а також взаємодію користувачів з мобільним Android-додатком для
отримання цієї інформації. Основна увага зосереджена на організації даних про
локації різних категорій, міста, користувачів і персоналізовані налаштування.
База даних є центральним елементом серверної частини програмної
системи, оскільки саме вона забезпечує збереження, цілісність та доступність
довідкової інформації про місця відпочинку, а також даних про користувачів і їх
персональні налаштування. Для реалізації системи обрано реляційну систему
керування базами даних PostgreSQL, яка характеризується високою надійністю,
продуктивністю та підтримкою складних зв’язків між даними.
До бази даних висувалися такі основні вимоги: зберігання інформації про
місця відпочинку різних категорій; підтримка фільтрації за категоріями та
містами; забезпечення збереження користувацьких обраних локацій; підтримка
50
ЧДТУ 252483.008 ПЗ
механізму авторизації; забезпечення цілісності та узгодженості даних; можливість
масштабування структури даних у майбутньому.
Модель предметної області розроблюваної інформаційної системи
відображає основні сутності, їхні атрибути та взаємозв’язки, які характеризують
функціонування додатку на логічному рівні без урахування деталей програмної
реалізації. Побудова моделі предметної області дозволяє формалізувати структуру
даних, визначити ключові об’єкти системи та забезпечити узгодженість між
вимогами замовника і подальшими етапами проєктування програмного
забезпечення.
До основних сутностей предметної області належать: користувач, місто,
місце відпочинку та обране. Користувач представлений таблицею з даними про
зареєстрованих осіб. Місто описує адміністративну одиницю, до якої належать
місця відпочинку. Місця відпочинку представлені окремими таблицями для
кожної категорії. Обране використовується для збереження персоналізованих
списків локацій користувачів.
Між сутностями предметної області встановлено такі зв’язки: одне місто
може містити багато локацій; один користувач може додати багато локацій до
обраного; одна локація може бути додана до обраного багатьма користувачами.
Така структура забезпечує гнучкість моделі та відповідає вимогам предметної
області.
Словник предметної області
В межах предметної області виділяються такі основні поняття:
− користувач – особа, яка використовує мобільний додаток для перегляду
інформації та, у разі авторизації, для роботи з персоналізованими
функціями;
− місто – географічна одиниця, що використовується для групування місць
відпочинку;
− місце відпочинку – об’єкт довідкової інформації, що належить до певної
категорії та міста;
− категорія – тип місця відпочинку (готель, кінотеатр, театр);
51
ЧДТУ 252483.008 ПЗ
− обране – персоналізований список локацій, збережених користувачем.
Таким чином, модель предметної області дозволяє формалізувати основні
об’єкти системи, їх властивості та взаємозв’язки, що є основою для подальшого
проєктування логічної структури програмного комплексу та реалізації його
функціоналу.
3.1.2 Елементи моделювання предметної області
Для формалізації предметної області розроблюваної програмної системи
було використано об’єктно-орієнтований підхід до моделювання, який дозволяє
описати структуру системи у вигляді взаємопов’язаних сутностей та визначити їх
основні характеристики. Моделювання предметної області спрямоване на
відображення ключових об’єктів системи та зв’язків між ними з метою
подальшого проєктування логічної структури програмного комплексу.
Основними елементами моделювання предметної області є сутності, що
відповідають об’єктам реального світу, з якими працює система. До таких
сутностей належать користувачі, місця відпочинку, категорії місць, міста, а також
об’єкти, пов’язані з персоналізованими налаштуваннями користувачів. Кожна
сутність характеризується набором атрибутів, що описують її властивості, та
визначеним набором зв’язків з іншими сутностями.
Для відображення елементів предметної області та зв’язків між ними
використовуються засоби UML-моделювання, представлені в таблиці 3.1.
Таблиця 3.1
Елементи моделювання предметної області
Графічний Назва елемента
символ
Дійова особа (актор)
Варіант використання
Пакет
Клас
Об’єкт
52
ЧДТУ 252483.008 ПЗ
Продовження таблиці 3.1
Компонент
Діяльність
Лінія життя, фокус управління
Логічний з’єднувач, розгалужувач
Початковий і кінцевий стани
Відношення асоціації
Виклик
Таким чином, визначені елементи моделювання предметної області
забезпечують цілісне уявлення про структуру програмної системи та створюють
основу для подальшого архітектурного проєктування і реалізації функціональних
можливостей Android-додатку.
3.1.3 Робоча область моделювання
Робоча область моделювання визначає межі програмної системи та описує
основні компоненти, що беруть участь у її функціонуванні, а також характер
взаємодії між ними. У межах даної області розглядається Android-додаток для
пошуку місць відпочинку, серверна частина інформаційної системи та база даних,
які разом утворюють єдиний програмний комплекс.
Мобільний застосунок реалізує користувацький інтерфейс та забезпечує
взаємодію користувача з інформаційною системою. За допомогою застосунку
користувач отримує доступ до довідкової інформації про місця відпочинку,
здійснює вибір категорії та міста, переглядає детальну інформацію про об’єкти та,
у разі авторизації, формує перелік обраних місць.
Серверна частина програмної системи відповідає за обробку запитів, що
надходять від мобільного застосунку, та реалізацію бізнес-логіки. Вона
забезпечує взаємодію з базою даних, обробку авторизації користувачів, а також
надання структурованих даних у відповідь на запити клієнтської частини.
База даних використовується для зберігання інформації про місця
53
ЧДТУ 252483.008 ПЗ
відпочинку, їх категорії, міста, а також даних про користувачів і їх обрані локації.
Взаємодія серверної частини з базою даних здійснюється з використанням
стандартних механізмів доступу до даних, що забезпечує цілісність та
актуальність інформації.
На рисунку 3.1 представлена модель предметної області .
Рисунок 3.1 – Модель предметної області
Таким чином, робоча область моделювання охоплює всі ключові
компоненти програмного комплексу та визначає межі їх відповідальності. Це
створює основу для подальшого проєктування архітектури системи, деталізації
логічної структури та реалізації програмних компонентів.
3.2 Формування та аналіз вимог
Формування та аналіз вимог є одним із ключових етапів проєктування
програмного забезпечення, оскільки саме на цьому етапі визначається, якою має
бути інформаційна система та які функції вона повинна виконувати. Процес
аналізу вимог передбачає виявлення, уточнення та документування очікувань
54
ЧДТУ 252483.008 ПЗ
користувачів і обмежень, що накладаються на систему, у формі, зрозумілій як для
замовника, так і для розробника.
Основною метою формування вимог є визначення функціональних
можливостей Android-додатку для пошуку місць відпочинку в Україні, а також
встановлення нефункціональних характеристик, що впливають на зручність
використання, надійність та ефективність роботи системи. Чітке формалізування
вимог дозволяє забезпечити відповідність розроблюваного програмного
комплексу поставленим цілям та створює основу для подальшого проєктування,
реалізації і тестування програмного забезпечення.
3.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
Формування вимог до програмного забезпечення
На етапі формування вимог до програмного забезпечення визначається
перелік характеристик та функцій, якими повинна володіти розроблювана
інформаційна система. Вимоги формуються на основі аналізу предметної області,
цільової аудиторії та основної мети створення продукту. Результатом даного
етапу є структурований опис очікуваної поведінки системи та обмежень, яких
необхідно дотримуватися під час її проєктування і реалізації.
Первинні і детальні вимоги
Первинні вимоги формулюються на основі потреб кінцевих користувачів і
відображають загальні очікування від програмного забезпечення. Детальні вимоги
є результатом первинних вимог та уточнюють поведінку системи з позиції
розробника.
Первинні вимоги:
− система повинна забезпечувати користувачеві доступ до довідкової
інформації про місця відпочинку в Україні;
− користувач повинен мати можливість здійснювати пошук місць
відпочинку за категоріями;
− системи повинна підтримувати пошук місць відпочинку за містами;
55
ЧДТУ 252483.008 ПЗ
− користувач повинен мати можливість переглядати детальну інформацію
про обране місце для відпочинку;
− система повинна забезпечувати можливість авторизації користувачів;
− авторищований користувач повинен мати можливість формувати списки
обраних місць відпочинку.
Детальні вимоги:
− система повинна надавати користувачеві перелік доступних категорій
місць відпочинку для вибору;
− після вибору категорії система повинна забезпечувати можливість
вибору міста;
− система повинна формувати список місць відпочинку відповідно до
обраних параметрів;
− для кожного місця відпочинку система повинна відображати основну та
розширену довідкову інформацію;
− система повинна забезпечувати перевірку коректності даних під час
авторизації користувача;
− система повинна зберігати перелік обраних місць відпочинку для
авторизованих користувачів;
− система повинна надавати користувачеві доступ до раніше збережених
обраних локацій.
ВИМОГИ ЗАМОВНИКА
Замовник очікує створення мобільного програмного забезпечення
довідкового типу призначеного для пошуку та перегляду інформації про місця
відпочинку в Україні. Система повинна надавати користувачам можливість
швидко отримувати структуровану та зрозумілу інформацію про різні локації,
зокрема готелі, театри та кінотеатри без необхідності використання сторонніх
інформаційних ресурсів.
Особлива увага з боку замовника приділяється зручності взаємодії з
програмною системою. Навігація в мобільному додатку повинна бути логічною та
інтуїтивно зрозумілою, а процес пошуку – простим і послідовним. Користувач
56
ЧДТУ 252483.008 ПЗ
повинен мати можливість за мінімальну кількість дій отримати перелік
релевантних місць відпочинку відповідно до обраної категорії та міста.
Крім того, замовник зацікавлений у наявності можливості збереження
обраних місць у відповідних списках. Система повинна бути орієнтована на
широке коло користувачів, працювати стабільно та забезпечувати актуальність
довідкової інформації. Замовник також розглядає програмний продукт як такий,
що може бути розширений у найбутньому за рахунок додавання нових категорій
та функціональних можливостей.
ВИМОГИ РОЗРОБНИКА
Вимоги розробника формуються на основі аналізу первинних вимог і вимог
замовника та спрямовані на забезпечення логічної узгодженості, цілісності та
керованості програмної системи на всіх етапах її життєвого циклу. Розробник
розглядає систему як комплекс взаємопов’язаних програмних компонентів, які
повинні функціонувати в межах визначеної робочої області моделювання.
З позиції розробника програмне забезпечення повинне мати чітко визначені
межі відповідальності між клієнтською та серверною частинами, а також
забезпечувати коректну обробку запитів користувача. Поведінка системи має бути
формалізована у вигляді моделей, що дозволяє застосувати діаграми
прецендентів, діяльності та взаємодії під час проєктування.
Окрему увагу розробник приділяє можливості подальшого розвитку
програмного забезпечення без необхідності суттєвих змін існуючої логіки.
Система повинна підтримувати масштабування, розширення довідкової
інформації та адаптацію до нових вимог замовника. Вимоги розробника також
передбачають забезпечення узгодженості між вимогами, моделями та
реалізованими програмними компонентами, що є важливою умовою якісної
інженерії програмного забезпечення.
Функціональні та нефункціональні вимоги
Функціональні вимоги описують сервіси та поведінку системи під час
взаємодії з користувачем. Нефункціональні вимоги визначають характеристики
якості програмного забезпечення та умови його функціонування.
57
ЧДТУ 252483.008 ПЗ
Функціональні вимоги:
− система повинна забезпечувати перегляд списку місць відпочинку;
− система повинна підтримувати фільтрацію місць відпочинку за
категоріями;
− система повинна підтримувати фільтрацію місць відпочинку за містами;
− система повинна забезпечувати перегляд детальної інформації про місце
відпочинку;
− система повинна підтримувати авторизацію користувачів;
− система повинна забезпечувати додавання та збереження обраних місць
відпочинку.
Нефункціональні вимоги:
− система повинна бути зручною і зрозумілою для користувача;
− інтерфейс користувача повинен бути інтуїтивно доступним;
− система повинна забезпечувати прийнятний час відгуку на дії
користувача;
− програмне забезпечення повинне забезпечувати стабільну роботу;
− система повинна забезпечувати захист даних користувачів;
− програмне забезпечення повинне бути придатним до подальшого
розширення.
Таким чином, поділ вимог на первинні та детальні, а також на
функціональні та нефункціональні, дозволяє чітко структурувати очікування
замовника і технічні рішення розробника, що є основою для подальшого
моделювання та проєктування програмного комплексу.
3.2.2 Формування вимог за допомогою діаграми прецендентів
Для наочного подання функціональних вимог до програмного забезпечення
використовується діаграма прецедентів UML (Use Case Diagram). Дана діаграма
дозволяє формалізувати взаємодію користувачів із системою, визначити основні
сценарії використання та встановити межі відповідальності програмного
комплексу. Використання діаграми прецедентів сприяє кращому розумінню
58
ЧДТУ 252483.008 ПЗ
функціональних можливостей системи як з боку замовника, так і з боку
розробника.
У межах розроблюваного Android-додатку для пошуку місць відпочинку
основним актором є користувач, який взаємодіє з інформаційною системою через
мобільний застосунок. Залежно від стану авторизації користувача визначається
набір доступних йому прецедентів. Неавторизований користувач має доступ до
перегляду довідкової інформації, тоді як авторизований користувач отримує
можливість використання персоналізованих функцій. Користувач з правами
адміністратора має доступ до сторінки адміністратора для управління даними в
БД. Взаємодія користувача з системою зображено за допомогою діаграми
прецендентів на рисунку 3.2.
Рисунок 3.2 – Діаграма прецендентів
До основних прецедентів використання системи належать вибір категорії
місця відпочинку, вибір міста, перегляд списку доступних локацій, перегляд
детальної інформації про обране місце, а також перехід за зовнішнім посиланням
для бронювання або придбання квитків. Дані прецеденти відображають базовий
функціонал застосунку та доступні всім користувачам незалежно від авторизації.
59
ЧДТУ 252483.008 ПЗ
Другу групу прецедентів становлять сценарії, доступні лише авторизованим
користувачам. До них належать авторизація в системі, додавання місць
відпочинку до списку обраних, перегляд списку обраних локацій у персональному
кабінеті та швидкий доступ до раніше збережених місць. Таке розмежування
дозволяє чітко визначити функціональні межі системи та реалізувати
персоналізовану взаємодію з користувачем.
До окремої групи прецедентів відносяться додавання нових даних,
редагування та видалення вже існуючих даних. Ці дії доступні лише
користувачам з правами адміністратора.
Таким чином, використання діаграми прецедентів дозволяє систематизувати
функціональні вимоги, визначити основні сценарії роботи з Android-додатком та
створити основу для подальшого проєктування логічної структури програмного
комплексу і моделювання поведінки системи.
3.2.3 Проєктування логічної структури програмного комплексу
Проєктування логічної структури програмного комплексу є важливим
етапом розробки інформаційної системи, на якому визначається внутрішня
організація програмних компонентів та їх взаємозв’язки. На цьому етапі
результати аналізу вимог і моделювання предметної області формалізуються у
вигляді логічних моделей, що описують структуру системи незалежно від
конкретних засобів реалізації.
Логічна структура Android-додатку для пошуку місць відпочинку
відображає основні сутності предметної області, їх атрибути та взаємодію між
ними. Такий підхід дозволяє забезпечити цілісність програмного комплексу,
спростити процес подальшої реалізації та підвищити зрозумілість архітектурних
рішень.
3.2.3.1 Діаграма класів
Діаграма класів використовується для опису статичної структури
програмної системи та відображає основні класи, їх властивості, методи та зв’язки
між ними. У контексті розроблюваного застосунку діаграма класів відображає
60
ЧДТУ 252483.008 ПЗ
логічну модель предметної області, сформовану на попередніх етапах, та є
основою для проєктування бази даних і серверної логіки.
На діаграмі класів представлені ключові сутності системи, такі як
користувач, місце відпочинку, категорія, місто та об’єкти, що забезпечують
збереження персоналізованих даних. Взаємозв’язки між класами відображають
логіку предметної області та визначають правила взаємодії між елементами
системи. Використання діаграми класів дозволяє формалізувати структуру даних і
забезпечити узгодженість між різними компонентами програмного комплексу.
Початкова діаграма клалів зображена на рисунку 3.3.
Рисунок 3.3 – Початкова діаграма класів
Початкова діаграма класів має такі сутності:
− user – користувач, що взаємодіє з системою;
− city – міста, в яких знаходяться місця відпочинку;
− cinema – кінотеатр;
− hotel – готель;
− theater – театр;
61
ЧДТУ 252483.008 ПЗ
− favourite_cinema – суміжна сутність, яка зв’язує собою користувача і
улюблений кінотеатр;
− favourire_hotel – суміжна сутність, яка зв’язує собою користувача і
улюблений готель;
− favorite_theater – суміжна сутність, яка зв’язує собою користувача і
улюблений театр.
На рисунку 3.4 зображено діаграму класів з їх полями.
Рисунок 3.4 – Діаграма класів
Опис діаграми класів:
1 Таблиця user – містить дані про зареєстрованих користувачів.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
− last_name – прізвище;
− first_name – ім’я;
62
ЧДТУ 252483.008 ПЗ
− email – електронна пошта;
− password – хешований пароль;
− role – роль коростувача.
2 Таблиця city – містить дані про міста.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
− name – назва міста;
− image_url – посилання на зображення.
3 Таблиця hotel – містить дані про готелі.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
− name – назва;
− address – адреса;
− latitude – широта;
− longitude – довгота;
− id_city – id міста;
− link – посилання на сторінку для бронювання;
− description – опис;
− image_url – посилання на зображення;
− phone_numbers – контактні номери телефону;
− email – контактна електронна пошта;
− services – перелічення послуг;
− meals_information – інформація про харчування;
− rooms_amount – кількість кімнат;
− min_price – мінімальна ціна.
4 Таблиця cinema – містить дані про кінотеатри.
Основні поля:
− id – первинний ключ;
63
ЧДТУ 252483.008 ПЗ
− uuid – унікальний ідентифікатор;
− name – назва;
− address – адреса;
− latitude – широта;
− longitude – довгота;
− id_city – id міста;
− link – посилання на сторінку для купівлі білетів;
− description – опис;
− image_url – посилання на зображення;
− phone_numbers – контактні номери телефону.
5 Таблиця theater – містить дані про театри.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
− name – назва;
− address – адреса;
− latitude – широта;
− longitude – довгота;
− id_city – id міста;
− link – посилання на сторінку для купівлі білетів;
− description – опис;
− image_url – посилання на зображення;
− email – контактна електронна пошта;
− phone_numbers – контактні номери телефону.
6 Таблиця favourite_cinema – реалізує зв’язок «багато-до-багатьох» між
користувачами та обраними кінотеатрами.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
− id_user – id користувача;
64
ЧДТУ 252483.008 ПЗ
− id_cinema – id обраного кінотеатра.
7 Таблиця favourite_hotel – реалізує зв’язок «багато-до-багатьох» між
користувачами та обраними готелями.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
− id_user – id користувача;
− id_hotel – id обраного готеля.
8 Таблиця favourite_theater – реалізує зв’язок «багато-до-багатьох» між
користувачами та обраними театрами.
Основні поля:
− id – первинний ключ;
− uuid – унікальний ідентифікатор;
− id_user – id користувача;
− id_theater – id обраного театра.
3.2.3.2 Діаграма пакетів
Діаграма пакетів застосовується для групування класів за функціональним
призначенням та відображення високорівневої структури програмного комплексу.
Вона дозволяє логічно розподілити елементи системи на окремі модулі, що
спрощує навігацію по проєкту та підвищує підтримуваність програмного
забезпечення.
Діаграма пакетів зображена на рисунку 3.5.
Опис діаграми пакетів:
До складу клієнтської частини системи (Android Application) входять такі
пакети:
− ui – відповідає за реалізацію користувацького інтерфейсу мобільного
застосунку та взаємодію з користувачем;
− viewmodel – забезпечує обробку даних та підготовку їх для
відображення в інтерфейсі користувача;
65
ЧДТУ 252483.008 ПЗ
− network – реалізує обмін даними з серверною частиною системи за
допомогою REST API;
− model – містить моделі даних, що використовуються для передавання
інформації між компонентами застосунку;
− utils – включає допоміжні компоненти, що забезпечують збереження
сесії користувача та загальні налаштування застосунку.
Рисунок 3.5 – Діаграма пакетів
Серверна частина програмного комплексу (Backend Application) складається
з таких пакетів:
− controller – відповідає за обробку HTTP-запитів, що надходять від
клієнтської частини;
− service – реалізує бізнес-логіку системи та обробку даних;
66
ЧДТУ 252483.008 ПЗ
− repository – забезпечує доступ до бази даних і виконання операцій
збереження та отримання даних;
− model – містить сутності, що відповідають таблицям бази даних;
− config – використовується для налаштування параметрів безпеки та
опису API за допомогою OpenAPI.
Окремим компонентом системи є база даних PostgreSQL, яка:
− зберігає інформацію про користувачів;
− містить дані про місця відпочинку;
− забезпечує збереження категорій і міст;
− використовується для збереження списків обраних місць користувачів.
Взаємодія між клієнтською та серверною частинами системи:
− здійснюється за допомогою REST-запитів у форматі HTTP/JSON;
− забезпечує передачу довідкових та персоналізованих даних;
− підтримує авторизацію користувачів і роботу з обраними локаціями.
Таким чином, проєктування логічної структури програмного комплексу з
використанням діаграм класів і пакетів створює чітку модель внутрішньої
організації системи та є основою для подальшого архітектурного проєктування і
моделювання поведінки програмного забезпечення.
3.2.4 Архітектурне проєктування
Архітектурне проєктування програмного комплексу спрямоване на
визначення високорівневої структури системи, її основних компонентів та
способів їх взаємодії. На даному етапі логічна модель системи доповнюється
архітектурними рішеннями, що враховують розподіл функцій між клієнтською та
серверною частинами, а також особливості розгортання програмного
забезпечення.
Розроблювана інформаційна система має клієнт-серверну архітектуру, у
межах якої мобільний Android-додаток виступає клієнтською частиною, а
серверна частина забезпечує обробку запитів, реалізацію бізнес-логіки та доступ
до бази даних. Такий підхід дозволяє забезпечити масштабованість системи,
67
ЧДТУ 252483.008 ПЗ
централізоване зберігання даних та можливість подальшого розширення
функціональних можливостей.
3.2.4.1 Діаграма компонентів
Діаграма компонентів використовується для відображення основних
програмних компонентів системи та залежностей між ними. Вона дозволяє
наочно представити структуру програмного комплексу на високому рівні
абстракції та визначити відповідальність кожного компонента. Діаграма
компонентів представлена на рисунку 3.6.
На діаграмі компонентів відображено клієнтську частину у вигляді
мобільного застосунку, серверну частину у вигляді веб-застосунку та компонент
бази даних. Взаємодія між компонентами здійснюється за допомогою мережевих
запитів, що забезпечує обмін даними між клієнтом і сервером та доступ до
централізованого сховища інформації.
Рисунок 3.6 – Діаграма компонентів
68
ЧДТУ 252483.008 ПЗ
Опис діаграми компонентів:
1 Android Client:
− реалізує користувацький інтерфейс мобільного застосунку;
− забезпечує взаємодію користувача з інформаційною системою;
− надсилає запити до серверної частини та обробляє отримані
відповіді.
2 Backend Server:
− обробляє запити, що надходять від клієнтської частини;
− реалізує бізнес-логіку системи;
− забезпечує авторизацію користувачів;
− здійснює доступ до бази даних.
3 Database:
− зберігає інформацію про користувачів;
− містить довідкові дані про місця відпочинку;
− забезпечує збереження категорій, міст та обраних локацій;
− підтримує цілісність даних.
3.2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Діаграма розгортання використовується для відображення фізичного
розміщення компонентів програмної системи на апаратних засобах та визначення
середовищ їх функціонування. Вона дозволяє описати, на яких пристроях і
платформах розміщуються окремі частини програмного комплексу та як між
ними здійснюється взаємодія. Діаграма розгортання представлена на рисунку 3.7
У межах розроблюваної системи мобільний застосунок функціонує на
пристроях з операційною системою Android, серверна частина розгортається на
серверному обладнанні або у хмарному середовищі, а база даних розміщується на
окремому сервері або в межах серверної інфраструктури. Така схема розгортання
забезпечує надійну роботу системи та можливість її масштабування.
Таким чином, архітектурне проєктування з використанням діаграми
компонентів та діаграми розгортання дозволяє визначити загальну структуру
69
ЧДТУ 252483.008 ПЗ
програмного комплексу, встановити взаємозв’язки між його складовими та
підготувати основу для подальшого моделювання поведінки системи.
Рисунок 3.7 – Діаграма розгортання
3.2.5 Моделювання поведінки системи
Моделювання поведінки системи дозволяє описати динамічні аспекти
функціонування програмного комплексу та відобразити послідовність виконання
дій під час взаємодії користувача із системою. На даному етапі розглядаються
сценарії роботи Android-додатку для пошуку місць відпочинку, а також логіка
взаємодії між окремими компонентами програмного забезпечення.
Для опису поведінки системи використовуються UML-діаграми, які
дозволяють наочно представити процеси, що відбуваються під час виконання
основних сценаріїв використання, та взаємодію між об’єктами системи.
Застосування таких діаграм сприяє кращому розумінню логіки роботи
програмного комплексу та підготовці до етапу реалізації.
3.2.5.1 Діаграма діяльності
70
ЧДТУ 252483.008 ПЗ
Діаграма діяльності використовується для відображення послідовності дій,
що виконуються користувачем та системою під час реалізації певного сценарію. У
межах розроблюваного застосунку така діаграма описує процес вибору категорії
місця відпочинку, вибору міста, перегляду списку доступних локацій, переходу до
детальної інформації про обране місце та за необхідності додавання місця до
обраного.
Використання діаграми діяльності дозволяє відобразити логіку переходів
між окремими етапами взаємодії користувача з додатком та визначити можливі
альтернативні шляхи виконання сценарію.
Діаграма діяльності представлена на рисунку 3.8.
Рисунок 3.8 – Діаграма діяльності
3.2.5.2 Діаграма послідовності
71
ЧДТУ 252483.008 ПЗ
Діаграма послідовності застосовується для моделювання взаємодії між
об’єктами системи у часовому вимірі. Вона дозволяє показати порядок обміну
повідомленнями між користувачем, клієнтською частиною застосунку, серверною
частиною та базою даних під час виконання певного сценарію.
Застосування діаграми послідовності дає змогу формалізувати логіку
взаємодії між компонентами системи та забезпечити узгодженість дій на різних
рівнях архітектури.
На рисунку 3.9 представлена діаграма послідовності для сценарію
отримання списку готелів.
Рисунок 3.9 – Діаграма послідовності отримання списку готелів
Опис діаграми послідовності:
1 Користувач вибирає категорію локацій і місто.
2 Додаток посилає на сервер запит для отримання списку локацій.
3 На сервері контролер викликає сервіс з відповідним запитом.
4 Сервіс викликає репозиторій з відповідним запитом.
5 Репозиторій звертається до БД.
6 БД повертає список об’єктів готелів до репозиторію.
7 Репозиторій передає список сервісу.
72
ЧДТУ 252483.008 ПЗ
8 Сервіс перетворює список об’єктів у список DTO і передає їх
контролеру.
9 Контролер перетворює список в JSON і відправляє в додаток.
10 Додаток отримує JSON з сервера та відображає дані у вигляді списку.
3.2.5.3 Діаграма комунікації
Діаграма комунікації використовується для відображення взаємодії між
об’єктами системи з акцентом на структуру зв’язків між ними. Вона демонструє,
які об’єкти беруть участь у виконанні сценарію та яким чином між ними
передаються повідомлення.
Використання діаграми комунікації дозволяє доповнити діаграму
послідовності та надати альтернативне уявлення про взаємодію між елементами
програмного комплексу.
Діаграма комунікації представлена на рисунку 3.10.
Рисунок 3.10 – Діаграма комунікації
73
ЧДТУ 252483.008 ПЗ
Опис діаграми комунікації:
У даній діаграмі беруть участь такі об’єкти:
− User – ініціює взаємодію з системою;
− MobileApp – клієнтська частина, що обробляє дії користувача;
− ApiService – модуль мережевої взаємодії мобільного застосунку;
− BackendController – обробляє HTTP-запити від клієнта;
− PlaceService / FavoritesService – реалізують бізнес-логіку системи;
− Repository – забезпечують доступ до даних;
− PostgreSQL – зберігає інформацію про місця відпочинку та обрані
локації.
Основні повідомлення, відображені на діаграмі:
− вибір категорії та міста користувачем;
− формування та надсилання запиту на отримання списку місць;
− обробка запиту серверною частиною;
− отримання даних з бази даних;
− передавання результату клієнтській частині;
− додавання вибраного місця до списку обраних авторизованим
користувачем.
Використання діаграми комунікації дозволяє:
− наочно показати взаємодію між об’єктами системи;
− визначити послідовність і напрямок обміну повідомленнями;
− доповнити діаграму послідовності альтернативним представленням
поведінки системи.
3.2.5.4 Діаграма скінченного автомату
Діаграма скінченного автомату застосовується для опису можливих станів
системи або окремих її компонентів та переходів між цими станами. У межах
розроблюваного Android-додатку така діаграма може використовуватися для
моделювання станів користувача, зокрема неавторизованого та авторизованого, а
також переходів між ними.
74
ЧДТУ 252483.008 ПЗ
Діаграма скінченного автомату представлена на рисунку 3.11.
Рисунок 3.11 – Діаграма скінченного автомату
Опис діаграми скінченного автормату:
1 Початковий стан – початок роботи користувача з мобільним додатком.
2 Запуск додатку – ініціалізація програмного середовища та завантаження
основних компонентів.
3 Перевірка авторизації – визначення статусу користувача (авторизований
або гість).
4 Гостьовий режим – користувач може переглядати каталог і інформацію
про місця відпочинку без збереження обраного.
5 Авторизований режим – користувач отримує доступ до
персоналізованого функціоналу.
6 Вибір категорії – вибір типу місця відпочинку (готель, кінотеатр, театр).
7 Вибір міста – уточнення географічного розташування.
8 Список місць – відображення результатів фільтрації.
9 Перегляд інформації про місце – ознайомлення з описом, адресою,
зображеннями та посиланням.
10 Додати в обране – збереження місця для швидкого доступу.
75
ЧДТУ 252483.008 ПЗ
11 Особистий кабінет – перегляд і керування списком обраних місць.
12 Перехід за зовнішнім посиланням – відкриття стороннього ресурсу для
бронювання або купівлі квитків.
13 Вихід з акаунту – повернення користувача до гостьового режиму.
14 Завершення роботи додатку – закриття програми.
Переходи між станами здійснюються у відповідь на такі події:
− запуск застосунку;
− вибір категорії та міста;
− вибір конкретного місця відпочинку;
− успішна авторизація користувача;
− додавання місця до списку обраних;
− повернення до каталогу;
− вихід з облікового запису.
Таким чином, моделювання поведінки системи з використанням UML-
діаграм діяльності, послідовності, комунікації та скінченного автомату дозволяє
комплексно описати динамічні аспекти роботи програмного комплексу та
створює основу для подальшої реалізації і тестування програмного забезпечення.
76
ЧДТУ 252483.008 ПЗ
Висновки до розділу 3
У третьому розділі магістерської роботи було виконано впровадження
результатів досліджень у практику проєктування програмного забезпечення
інформаційних систем. На початковому етапі здійснено моделювання предметної
області, у межах якого визначено призначення розроблюваної системи, основних
користувачів, типи місць відпочинку та загальну логіку функціонування Android-
додатку для пошуку місць відпочинку в Україні.
У подальшому було сформовано та проаналізовано вимоги до програмного
забезпечення, зокрема виділено первинні та детальні вимоги, а також
функціональні й нефункціональні характеристики системи. Для формалізації
вимог використано діаграму прецедентів, що дозволило наочно представити
основні сценарії взаємодії користувачів із системою.
У розділі також виконано проєктування логічної структури програмного
комплексу та архітектури системи із застосуванням UML-діаграм, зокрема
діаграм класів, пакетів, компонентів і розгортання. Для опису поведінки системи
використано діаграми діяльності, послідовності, комунікації та скінченного
автомату, що дозволило комплексно відобразити динамічні аспекти роботи
програмного комплексу.
Таким чином, результати третього розділу створюють повну концептуальну
та проєктну основу для реалізації Android-додатку, визначають структуру
системи, її функціональні можливості та логіку взаємодії компонентів, що
забезпечує коректний перехід до етапу розробки та тестування програмного
забезпечення.
77
ЧДТУ 252483.008 ПЗ
4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
4.1 Розробка програмного комплексу
Розробка програмного комплексу є критично важливим етапом розробки,
оскільки саме на цьому етапі визначається структура компонентів, спосіб їх
взаємодії, розподіл відповідальності та масштабованість рішення. Для реалізації
Android-додатку з пошуку місць відпочинку в Україні було обрано багаторівневу
клієнт-серверну архітектуру, яка забезпечує гнучкість, розширюваність і
зручність супроводу.
Розроблювана система складається з таких основних компонентів:
1 Мобільний клієнт (Android-додаток).
Забезпечує взаємодію користувача з системою, відображення довідкової
інформації, навігацію між екранами, а також обробку подій користувача [4].
2 Серверна частина (Backend API).
Відповідає за зберігання, обробку та надання даних мобільному клієнту,
реалізує бізнес-логіку, авторизацію та доступ до бази даних.
3 База даних.
Призначена для збереження структурованої інформації про користувачів,
місця відпочинку, категорії, міста та обрані локації.
Взаємодія між компонентами здійснюється за допомогою REST API через
захищений протокол HTTPS.
4.1.1 Обгрунтування вибору засобів реалізації
Для реалізації програмного комплексу було обрано сучасні засоби та
технології розробки, які забезпечують стабільність роботи, масштабованість
системи та зручність подальшого супроводу. Вибір інструментів реалізації
обумовлений вимогами до функціональності програмного забезпечення,
специфікою мобільної платформи Android, а також необхідністю забезпечення
взаємодії з серверною частиною інформаційної системи.
Розробка клієнтської частини програмного комплексу здійснюється у
вигляді Android-додатку, який забезпечує користувачам доступ до довідкової
78
ЧДТУ 252483.008 ПЗ
інформації про місця відпочинку, структурованої за категоріями та географічною
ознакою. Такий підхід дозволяє реалізувати зручний користувацький інтерфейс та
забезпечити ефективну взаємодію з функціональними можливостями системи.
Серверна частина програмного комплексу реалізується у вигляді веб-
застосунку, який виконує обробку запитів клієнта, керування даними та бізнес-
логікою системи. Використання клієнт-серверної архітектури дозволяє розділити
відповідальність між компонентами системи та забезпечити можливість її
подальшого розширення.
Для зберігання та обробки даних використовується система керування
базами даних, що забезпечує надійність зберігання інформації, цілісність даних та
підтримку багатокористувацького доступу. Вибір реляційної моделі даних
дозволяє ефективно працювати з інформацією про користувачів, категорії місць
відпочинку, міста та об’єкти відпочинку.
Засоби реалізації програмного комплексу були підібрані з урахуванням їх
поширеності, наявності документації та підтримки, а також можливості інтеграції
між окремими компонентами системи. Це забезпечує зручність розробки,
тестування та впровадження програмного забезпечення у практичну діяльність.
4.1.2 Опис структурної (функціональної) схеми
Структурна (функціональна) схема програмного комплексу відображає
склад основних компонентів системи та взаємозв’язки між ними у процесі
функціонування Android-додатку для пошуку місць відпочинку в Україні. Схема
демонструє розподіл програмного комплексу на клієнтську та серверну частини, а
також механізм їх взаємодії з базою даних.
Структурна схема системи зображена на рисунку 4.1.
Клієнтська частина реалізована у вигляді Android-додатку та відповідає за
взаємодію з користувачем. Вона забезпечує відображення інформації про місця
відпочинку, вибір категорії об’єктів, фільтрацію за містами, перегляд детальної
інформації, а також роботу з обраними місцями для авторизованих користувачів.
Усі запити до даних здійснюються через звернення до серверної частини системи.
79
ЧДТУ 252483.008 ПЗ
Рисунок 4.1 – Структурна схема системи
Серверна частина програмного комплексу виконує обробку запитів, що
надходять від мобільного додатку, та реалізує бізнес-логіку системи [7]. Вона
забезпечує отримання, збереження та передачу даних, а також контроль доступу
до функціональних можливостей системи залежно від статусу користувача.
Серверна частина взаємодіє з базою даних, у якій зберігається інформація про
користувачів, категорії, міста та місця відпочинку.
Функціональна схема системи зображена на рисунку 4.2.
Рисунок 4.2 – Функціональна схема системи
База даних є окремим структурним елементом системи та використовується
для централізованого зберігання інформації. Вона забезпечує цілісність і
80
ЧДТУ 252483.008 ПЗ
актуальність даних, а також можливість їх багаторазового використання різними
компонентами програмного комплексу.
Таким чином, структурна схема відображає загальну організацію
програмного комплексу, визначає межі відповідальності окремих компонентів та
дозволяє оцінити логіку взаємодії між клієнтською, серверною частинами та
базою даних.
4.1.3 Опис логічної схеми системи
Логічна схема системи відображає внутрішню організацію програмного
комплексу з точки зору взаємодії основних логічних компонентів та потоків
даних між ними. На відміну від структурної схеми, логічна схема зосереджується
не на фізичному розміщенні компонентів, а на логіці обробки інформації та
послідовності виконання основних операцій у системі.
У логічній схемі Android-додатку для пошуку місць відпочинку в Україні
відображено взаємодію між користувацьким інтерфейсом, серверною частиною
системи та базою даних. Користувач ініціює запити через інтерфейс мобільного
додатку, обираючи категорію місць відпочинку, місто або конкретний об’єкт.
Сформовані запити передаються до серверної частини, де здійснюється їх обробка
відповідно до бізнес-логіки системи.
Серверна частина виконує перевірку коректності запитів, обробку даних та
формування відповідей, які повертаються клієнтській частині у вигляді
структурованої інформації. У разі необхідності сервер здійснює звернення до бази
даних для отримання або оновлення інформації, зокрема даних про користувачів
та обрані місця відпочинку.
База даних у логічній схемі розглядається як джерело та сховище
інформації, з яким взаємодіє серверна частина системи. Такий підхід дозволяє
забезпечити цілісність даних та контроль доступу до них, а також оптимізувати
процес обробки запитів.
Отже, логічна схема системи відображає послідовність взаємодії між
основними логічними компонентами програмного комплексу та дозволяє
81
ЧДТУ 252483.008 ПЗ
зрозуміти принципи обробки інформації у межах розроблюваного програмного
забезпечення.
4.1.4 Розробка бази даних системи
Розробка бази даних є важливим етапом створення програмного комплексу,
оскільки саме база даних забезпечує збереження, обробку та актуальність
інформації, що використовується Android-додатком для пошуку місць відпочинку
в Україні. Структура бази даних була сформована з урахуванням функціональних
можливостей системи та вимог до зберігання довідкової інформації.
У базі даних зберігається інформація про місця відпочинку, що поділяються
за категоріями, а також дані про міста, у яких ці об’єкти розташовані. Окремо
зберігаються відомості про користувачів системи, зокрема дані, необхідні для
авторизації та формування списку обраних місць відпочинку. Такий підхід
дозволяє забезпечити логічну структурованість даних та спростити процес їх
обробки [9].
Для організації даних використовується реляційна модель, яка передбачає
зберігання інформації у вигляді взаємопов’язаних таблиць. Між таблицями
встановлюються логічні зв’язки, що забезпечують цілісність даних та виключають
дублювання інформації. Це дозволяє ефективно виконувати запити до бази даних
та підтримувати узгодженість інформації. На рисунку 4.3 представлена ER-схема
бази даних.
Проєктування бази даних виконано таким чином, щоб забезпечити
можливість подальшого розширення системи, зокрема додавання нових категорій
місць відпочинку або розширення інформації про існуючі об’єкти. Структура бази
даних підтримує багатокористувацький режим роботи та забезпечує надійне
збереження даних.
Таким чином, розроблена база даних є основою для функціонування
програмного комплексу та забезпечує ефективну роботу серверної частини і
клієнтського додатку.
82
ЧДТУ 252483.008 ПЗ
Рисунок 4.3 – ER-схема БД
4.1.5 Розробка інтерфейсу користувача
Розробка інтерфейсу користувача є важливим етапом створення Android-
додатку для пошуку місць відпочинку в Україні, оскільки саме інтерфейс
забезпечує взаємодію користувача з функціональними можливостями системи.
Під час проєктування інтерфейсу основна увага приділялася зручності
83
ЧДТУ 252483.008 ПЗ
використання, наочності подання інформації та логічній структурі елементів
управління.
Інтерфейс мобільного додатку побудований з урахуванням сценаріїв
використання системи. Користувач має можливість обрати категорію місць
відпочинку, після чого здійснити вибір міста, зображено на рисунку 4.4, та
переглянути відповідний список об’єктів. Для кожного місця відпочинку
передбачено окремий екран з детальною інформацією, що дозволяє ознайомитися
з описом та перейти за зовнішнім посиланням для здійснення бронювання або
придбання квитків.
Рисунок 4.4 – Екрани вибору категорії та міста
84
ЧДТУ 252483.008 ПЗ
Окрему увагу приділено реалізації механізму авторизації користувачів,
зображено на рисунку 4.5. Авторизований користувач отримує доступ до функції
додавання місць відпочинку до списку обраних, що забезпечує швидкий доступ
до збереженої інформації через особистий кабінет. Такий підхід підвищує
зручність використання додатку та покращує користувацький досвід.
Рисунок 4.5 – Екрани входу та реєстрації
Проєктування інтерфейсу виконано відповідно до принципів побудови
мобільних застосунків, що передбачає використання стандартних елементів
управління та адаптацію інтерфейсу до різних розмірів екранів мобільних
пристроїв. Це забезпечує коректне відображення інформації та стабільну роботу
додатку на різних моделях пристроїв.
Таким чином, розроблений інтерфейс користувача забезпечує інтуїтивно
зрозумілу взаємодію з системою та дозволяє ефективно реалізувати основні
функціональні можливості програмного комплексу.
4.1.6 Опис розробки програмних компонентів
85
ЧДТУ 252483.008 ПЗ
Розробка програмних компонентів програмного комплексу здійснювалась із
використанням модульного підходу, що дозволяє розділити функціональність
системи на окремі логічно пов’язані частини. Такий підхід спрощує процес
розробки, тестування та подальшого супроводу програмного забезпечення [12].
Клієнтська частина системи реалізована у вигляді Android-додатку та
складається з компонентів, що відповідають за відображення інтерфейсу
користувача, обробку введених даних та взаємодію з серверною частиною.
Основні програмні компоненти клієнтської частини забезпечують навігацію між
екранами, формування запитів до серверу та обробку отриманих відповідей. На
рисунку 4.6 представлено фрагмент коду з авторизацією користувача.
Рисунок 4.6 – Авторизація користувача
86
ЧДТУ 252483.008 ПЗ
Серверна частина програмного комплексу реалізує бізнес-логіку системи та
забезпечує доступ до даних. Вона складається з програмних компонентів, що
відповідають за обробку HTTP-запитів, перевірку прав доступу користувачів, а
також взаємодію з базою даних [10]. Для опису інтерфейсів взаємодії між
клієнтом і сервером використовується специфікація API, що дозволяє
формалізувати структуру запитів і відповідей.
Окремі програмні компоненти відповідають за роботу з базою даних,
зокрема виконання операцій отримання та збереження інформації. Використання
таких компонентів забезпечує централізовану роботу з даними та знижує
залежність між окремими частинами системи.
Рисунок 4.7 – Сервіс пошуку
87
ЧДТУ 252483.008 ПЗ
Рисунок 4.8 – Репозиторій кінотеатрів
Таким чином, розробка програмних компонентів забезпечує реалізацію
основних функціональних можливостей Android-додатку для пошуку місць
відпочинку та створює основу для стабільної і масштабованої роботи
програмного комплексу.
4.2 Тестування системи
Тестування програмного забезпечення є завершальним та обов’язковим
етапом розробки програмного комплексу, який спрямований на перевірку
коректності роботи системи, відповідності реалізованого функціоналу
сформованим вимогам, а також на виявлення можливих помилок і недоліків [19].
У межах даного етапу здійснюється оцінка стабільності роботи Android-додатку
для пошуку місць відпочинку в Україні та його серверної частини.
Основною метою тестування є підтвердження того, що програмний
комплекс коректно виконує свої функції, забезпечує правильну обробку даних та
стабільну взаємодію між клієнтською і серверною частинами. Особлива увага
приділяється перевірці роботи основних сценаріїв використання системи, таких як
перегляд інформації про місця відпочинку, вибір категорії та міста, авторизація
користувачів і формування списку обраних місць.
Процес тестування охоплює перевірку окремих програмних компонентів,
88
ЧДТУ 252483.008 ПЗ
взаємодії між ними, а також функціонування системи в цілому. Це дозволяє
своєчасно виявити помилки реалізації, логічні неточності та проблеми взаємодії
компонентів, що можуть впливати на зручність використання або надійність
роботи системи.
Тестування програмного комплексу здійснюється поетапно та включає
модульне, інтеграційне, системне та приймальне тестування. Такий підхід
дозволяє комплексно оцінити якість програмного забезпечення та забезпечити
його відповідність поставленим вимогам і очікуванням користувачів.
4.2.1 Модульне тестування
Модульне тестування спрямоване на перевірку коректності роботи окремих
програмних модулів програмного комплексу без урахування взаємодії з іншими
компонентами системи. На цьому етапі кожен модуль розглядається як незалежна
одиниця, що дозволяє виявити помилки на ранніх стадіях та зменшити ризик їх
поширення на інші частини системи.
У межах Android-додатку модульному тестуванню підлягають компоненти,
що відповідають за обробку даних, логіку вибору категорій місць відпочинку,
фільтрацію за містами, а також роботу механізмів авторизації та формування
списку обраних місць. Перевіряється коректність виконання окремих функцій і
методів, а також правильність обробки вхідних даних [19].
Для серверної частини системи модульне тестування охоплює перевірку
програмних компонентів, що реалізують бізнес-логіку, обробку запитів та
взаємодію з базою даних. Особлива увага приділяється коректності виконання
операцій отримання даних, перевірці прав доступу користувачів та формуванню
відповідей, що передаються клієнтській частині.
Результати модульного тестування дозволяють виявити логічні помилки,
некоректну обробку даних та потенційні збої у роботі окремих компонентів.
Успішне проходження даного етапу створює основу для подальшого
інтеграційного тестування та забезпечує підвищення загальної надійності
програмного комплексу.
У таблиці 4.1 наведено приклади модульного тестування сервісів додатку.
89
ЧДТУ 252483.008 ПЗ
Таблиця 4.1
Приклади модульного тестування
Сервіс / модуль Перевірювана Вхідні дані Очікувані
функція результати
UserService Реєстрація Реєстраційні дані У БД створено
нового новий запис
користувача користувача з
його даними
UserService Авторизація Електронна Дані вірні, з
пошта для входу сервера
та пароль повертається
користувача jwt-токен
HotelService Отримання Uuid міста Список готелів
каталогу готелів у вибраному
у вибраному місті місті
CinemaService Отримання Uuid міста Список
каталогу кінотеатрів у
кінотеатрів у вибраному
вибраному місті місті
TheaterService Отримання Uuid міста Список театрів
каталогу театрів у вибраному
у вибраному місті місті
SearchService Пошук місця по Назва місця Списки
назві готелів,
кінотеатрів та
театрів, які
вдалось знайти
за введеною
назвою
90
ЧДТУ 252483.008 ПЗ
Продовження таблиці 4.1
FavouriteHotelService Додавання Uuid користувача У БД створено
готелю до і готеля новий запис в
обраного таблиці з
обраними
готелями
FavouriteHotelService Видалення Uuid користувача Видалено
готелю з і готеля запис з таблиці
обраного з обраними
готелями
FavouriteCinemaService Додавання Uuid користувача У БД створено
кінотеатру до і кінотеатра новий запис в
обраного таблиці з
обраними
кінотеатрами
FavouriteCinemaService Видалення Uuid користувача Видалено
кінотеатру з і кінотеатра запис з таблиці
обраного з обраними
кінотеатрами
FavouriteTheaterService Додавання театру Uuid користувача У БД створено
до обраного і театра новий запис в
таблиці з
обраними
готелями
FavouriteTheaterService Видалення театру Uuid користувача Видалено
з обраного і театра запис з таблиці
з обраними
театрами
4.2.2 Інтеграційне тестування
91
ЧДТУ 252483.008 ПЗ
Інтеграційне тестування спрямоване на перевірку коректності взаємодії між
окремими програмними модулями, які були попередньо перевірені на етапі
модульного тестування. Метою даного етапу є виявлення помилок, що можуть
виникати під час обміну даними між компонентами системи та виконання
спільних сценаріїв роботи.
У межах розроблюваного програмного комплексу інтеграційне тестування
охоплює перевірку взаємодії між клієнтською та серверною частинами системи.
Особлива увага приділяється коректності обробки запитів, що надходять від
Android-додатку до серверної частини, а також правильності формування та
передачі відповідей з боку серверу.
Також у процесі інтеграційного тестування перевіряється взаємодія
серверної частини з базою даних. Тестується коректність отримання даних про
місця відпочинку, категорії та міста, а також правильність збереження інформації,
пов’язаної з авторизованими користувачами та списками обраних місць.
Інтеграційне тестування дозволяє виявити проблеми, пов’язані з
несумісністю інтерфейсів, помилками передачі даних або некоректною
реалізацією бізнес-логіки при спільній роботі модулів. Успішне проходження
даного етапу є необхідною умовою для переходу до системного тестування
програмного комплексу.
У табличкі 4.2 наведено приклади інтеграційного тестування.
Таблиця 4.2
Приклади інтеграційного тестування
№ сценарію Короткий опис сценарію Основний зміст перевірки
1 Повний цикл реєстрації Отримання даних для реєстрації,
користувача перевірка чи існує запис про
користувача в БД, створення та
збереження даних нового
користувача або повернення
помилки реєстрації
92
ЧДТУ 252483.008 ПЗ
Продовження таблиці 4.2
2 Повний цикл авторизації Отримання даних авторизації,
користувача перевірка чи існує даний
користувач в БД, повернення jwt-
токену або помилки авторизації
3 Оновлення даних про місце Перевірка чи права адміністратора,
відпочинку перевірка чи існує в БД запис з
відповідним uuid, оновлення та
збереження даних або поверення
помилки
4.2.3 Системне тестування
Системне тестування є етапом перевірки програмного комплексу в цілому
та спрямоване на оцінку його відповідності визначеним вимогам і очікуваним
сценаріям використання. На даному етапі система розглядається як єдине ціле, у
якому всі компоненти вже інтегровані та взаємодіють між собою.
У процесі системного тестування перевіряється коректність виконання
основних функцій Android-додатку для пошуку місць відпочинку в Україні [19].
Зокрема, тестуються сценарії перегляду інформації про місця відпочинку, вибору
категорії та міста, перегляду детальної інформації про об’єкти, а також переходу
за зовнішніми посиланнями для здійснення бронювання або придбання квитків.
Окрема увага приділяється перевірці роботи механізмів авторизації
користувачів та функціоналу додавання місць відпочинку до списку обраних.
Перевіряється коректність відображення збережених даних в особистому кабінеті
користувача, а також стабільність роботи системи при виконанні типових
користувацьких дій.
Системне тестування також дозволяє оцінити загальну стабільність роботи
програмного комплексу, коректність обробки помилкових ситуацій та
відповідність реалізованого функціоналу нефункціональним вимогам, зокрема
93
ЧДТУ 252483.008 ПЗ
зручності використання та надійності. Успішне проходження даного етапу
підтверджує готовність системи до приймального тестування.
У табличкі 4.3 наведено приклади системного тестування.
Таблиця 4.3
Приклади системного тестування
№ сценарію Короткий опис сценарію Основний зміст перевірки
1 Одночасна роботи кількох Одночасні запити до тих самих та
користувачів різних сервісів з різних пристроїв,
перевірка наявності помилок та
невиконаних запитів
2 Пошук місць відпочинку за Перевірка коректності
категорією та містом відображення списку локацій після
вибору категорії та міста
3 Відновлення роботи після Перевірка коректності роботи
збою додатку після примусового
закриття або повторного запуску
4.2.4 Приймальне тестування
Приймальне тестування є завершальним етапом перевірки програмного
комплексу та проводиться з метою підтвердження відповідності розробленої
системи поставленим вимогам і очікуванням замовника. На цьому етапі
оцінюється готовність Android-додатку для пошуку місць відпочинку в Україні до
практичного використання.
У процесі приймального тестування перевіряється виконання основних
функціональних можливостей системи відповідно до сформованих вимог [19].
Зокрема, оцінюється коректність роботи сценаріїв перегляду інформації про місця
відпочинку, вибору категорій і міст, авторизації користувачів, а також
функціонування механізму додавання об’єктів до списку обраних.
94
ЧДТУ 252483.008 ПЗ
Особлива увага приділяється зручності використання системи, логічності
інтерфейсу та стабільності роботи програмного комплексу під час виконання
типових користувацьких дій. Також перевіряється коректність взаємодії між
клієнтською та серверною частинами системи в умовах реальної експлуатації.
Результати приймального тестування дозволяють зробити висновок про
відповідність програмного комплексу вимогам технічного завдання та можливість
його впровадження у практичну діяльність. Успішне проходження даного етапу
підтверджує готовність системи до використання кінцевими користувачами.
У табличкі 4.4 наведено приклади приймального тестування.
Таблиця 4.4
Критерій Метод перевірки / Результат Коментар
приймання сценарій перевірки
Коректність Запуск додатку на Успішно Додаток
запуску додатку різних Android- запускається без
пристроях та затримок та
версіях ОС аварійних
завершень
Доступність Перегляд каталогу Успішно Відзначено
основного місць відпочинку зручність
функціоналу без без входу в швидкого доступу
авторизації систему до інформації
Коректність Вхід користувача Успішно Процес
процесу з валідними та авторизації
авторизації невалідними зрозумілий та
обліковими інтуїтивний
даними
Пошук за Вибір категорії та Успішно Логіка фільтрації
категоріями та міста з подальшим інтуїтивно
містами переглядом зрозуміла
списку локацій
95
ЧДТУ 252483.008 ПЗ
Продовження таблиці 4.4
Перегляд Відкриття Успішно Інформація
детальної сторінки подається
інформації конкретної локації структуровано та
читабельно
4.3 Приклади впровадженого програмного комплексу
У межах даної роботи було реалізовано Android-додаток для пошуку місць
відпочинку в Україні, який забезпечує користувачам доступ до довідкової
інформації про театри, кінотеатри та готелі. Реалізований програмний комплекс
дозволяє наочно продемонструвати результати розробки та підтвердити
працездатність основних функціональних можливостей системи.
На головному екрані додатку користувачеві надається можливість обрати
категорію місць відпочинку. Після вибору категорії користувач переходить до
етапу вибору міста, представлено на рисунку 4.9, що дозволяє здійснювати пошук
об’єктів відповідно до географічного розташування. Такий підхід спрощує
навігацію та забезпечує зручний доступ до необхідної інформації.
Рисунок 4.9 – Екрани вибору категорії та міста
96
ЧДТУ 252483.008 ПЗ
Після вибору категорії та міста користувач отримує список відповідних
місць відпочинку. Для кожного об’єкта передбачена можливість перегляду
детальної інформації, яка містить опис місця та додаткові відомості. Також
реалізовано перехід за зовнішнім посиланням для здійснення бронювання або
придбання квитків, що дозволяє інтегрувати додаток з існуючими сервісами без
реалізації власної платіжної функціональності. Сторінку з інформацією про місце
та зовнішнім посиланням представлено на рисунку 4.10
Рисунок 4.10 – Екрани основної інформації та зовнішнього посилання
Окремо реалізовано механізм авторизації користувачів, який відкриває
доступ до додаткового функціоналу. Авторизований користувач має можливість
додавати місця відпочинку до списку обраних, а також переглядати збережені
об’єкти в особистому кабінеті. Це забезпечує швидкий доступ до вибраної
97
ЧДТУ 252483.008 ПЗ
інформації та підвищує зручність використання додатку. Сторінка авторизації та
списку обраного представлено на рисунку 4.11.
Рисунок 4.11 – Екрани авторизації та списку обраного
Таким чином, приклади впровадженого програмного комплексу
демонструють практичну реалізацію розробленого Android-додатку та
підтверджують можливість його використання для надання довідкової інформації
про місця відпочинку в Україні.
98
ЧДТУ 252483.008 ПЗ
Висновки до розділу 4
У четвертому розділі магістерської роботи було розглянуто процес розробки
та тестування програмного забезпечення Android-додатку для пошуку місць
відпочинку в Україні. На початковому етапі обґрунтовано вибір засобів реалізації
програмного комплексу та описано структурну і логічну схеми системи, що
дозволило визначити взаємодію між клієнтською частиною, сервером і базою
даних.
У межах розділу виконано опис розробки бази даних та інтерфейсу
користувача, що забезпечує зручну навігацію, доступ до довідкової інформації та
реалізацію основних функціональних можливостей системи. Окрему увагу
приділено опису розробки програмних компонентів клієнтської та серверної
частин, що забезпечують обробку запитів, роботу з даними та реалізацію бізнес-
логіки.
Значну частину розділу присвячено тестуванню програмного комплексу.
Розглянуто основні види тестування, зокрема модульне, інтеграційне, системне та
приймальне тестування, що дозволило оцінити коректність роботи окремих
компонентів, їх взаємодію та функціонування системи в цілому. Проведення
тестування підтвердило відповідність реалізованого програмного забезпечення
поставленим вимогам.
У завершальній частині розділу наведено приклади впровадженого
програмного комплексу, які демонструють практичну реалізацію розробленого
Android-додатку та підтверджують можливість його використання для надання
довідкової інформації про місця відпочинку в Україні.
Таким чином, у четвертому розділі підтверджено працездатність,
стабільність та готовність розробленого програмного комплексу до використання,
що свідчить про досягнення поставленої мети дослідження.
99
ЧДТУ 252483.008 ПЗ
ВИСНОВКИ
У магістерській роботі було розглянуто процес проєктування, розробки та
тестування Android-додатку для пошуку місць відпочинку в Україні. Актуальність
обраної теми зумовлена зростанням попиту на мобільні інформаційні сервіси,
орієнтовані на внутрішній туризм, культурний відпочинок та швидкий доступ до
довідкової інформації про різноманітні локації.
У першому розділі виконано аналіз предметної області та досліджено
сучасний стан ринку мобільних додатків для пошуку місць відпочинку.
Розглянуто функціональні можливості існуючих аналогів, зокрема таких Android-
додатків, як Multiplex, Booking.com, SmartCinema, Контрамарка та Hotel Ukraina.
Проведений аналіз дозволив визначити їх переваги та недоліки, а також
сформувати перелік вимог до розроблюваного програмного продукту.
Встановлено, що більшість існуючих рішень орієнтовані на окремі типи локацій
або комерційні операції, що обґрунтовує доцільність створення універсального
довідкового сервісу.
У другому розділі виконано проєктування архітектури програмної системи.
Визначено загальну структуру клієнт-серверної взаємодії, обґрунтовано вибір
технологій та інструментів розробки. Клієнтська частина реалізована у вигляді
Android-додатку з використанням мови програмування Kotlin та XML-лейаутів,
серверна частина — на основі фреймворку Spring Boot з використанням OpenAPI
для опису REST-ендпоінтів. Для зберігання даних обрано систему керування
базами даних PostgreSQL. Проєктування передбачає поділ місць відпочинку за
категоріями та містами, що спрощує навігацію і пошук інформації.
У третьому розділі описано процес реалізації програмного забезпечення.
Розглянуто основні функціональні можливості Android-додатку, зокрема перегляд
списків локацій, відображення детальної інформації, роботу з категоріями та
містами, реалізацію авторизації користувача та функціоналу «Обране». Особливу
увагу приділено взаємодії клієнтської та серверної частин, а також реалізації
безпечного доступу до персоналізованих функцій. Додаток не передбачає
100
ЧДТУ 252483.008 ПЗ
здійснення купівлі чи бронювання безпосередньо в системі, а забезпечує перехід
до зовнішніх сервісів, що відповідає поставленій меті довідкового ресурсу.
У четвертому розділі проведено комплексне тестування програмного
забезпечення. Розглянуто види та рівні тестування, виконано перевірку серверної
і клієнтської частин, а також оцінено продуктивність, надійність і безпеку
системи. Результати тестування підтвердили коректність реалізації
функціональних можливостей, стабільну роботу додатку та відповідність
програмного продукту вимогам якості.
У результаті виконання магістерської роботи досягнуто поставленої мети –
розроблено Android-додаток для пошуку місць відпочинку в Україні, який
забезпечує користувачів зручною та структурованою довідковою інформацією
про готелі, кінотеатри та театри. Розроблений програмний продукт може бути
використаний туристами, студентами, молоддю та всіма, хто зацікавлений у
пошуку культурного та рекреаційного відпочинку.
Практичне значення роботи полягає у можливості подальшого розвитку
системи, зокрема розширення переліку категорій локацій, інтеграції додаткових
інформаційних сервісів та впровадження нових функціональних можливостей.
101
ЧДТУ 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).
102
ЧДТУ 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.hoteluk
raina (дата звернення: 25.09.2025).
19 Myers G. J., Sandler C., Badgett T. The art of software testing. 3rd ed.
Hoboken : Wiley, 2011. (дата звернення: 03.12.2025).
103
ДОДАТОК А
Затверджую
Зав. кафедри ПЗАС,
______________ Сергій ГОЛУБ
«____»____________2025 р.
ANDROID-ДОДАТОК ДЛЯ ПОШУКУ МІСЦЬ ВІДПОЧИНКУ В УКРАЇНІ
Специфікація
482.ЧДТУ.252483 01
Листів 2
Розробник ____________________ Кавун Д.Р.
Керівник ____________________ Олексюк В.В.
Черкаси – 2025
482.ЧДТУ.252483 01
Позначення Найменування Примітка
482.ЧДТУ.252483 1201 Лістинг програми
482.ЧДТУ.252483 9001 Графічні матеріали
105
ДОДАТОК Б
ANDROID-ДОДАТОК ДЛЯ ПОШУКУ МІСЦЬ ВІДПОЧИНКУ В УКРАЇНІ
ТЕКСТ ПРОГРАМИ
482.ЧДТУ.252483 12-01
Листів 27
Розробник _____________ Кавун Д.Р.
Черкаси – 2025
482.ЧДТУ.252483 12-01
Фрагмент програми
Клас 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
@RequiredArgsConstructor
107
482.ЧДТУ.252483 12-01
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')")
public TheaterDto addTheater(TheaterDto theaterDto) {
return theaterService.add(theaterDto);
108
482.ЧДТУ.252483 12-01
}
@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
@PreAuthorize("hasAnyAuthority('ADMIN')")
public Void deleteCinemaByUuid(String uuid) {
cinemaService.delete(uuid);
109
482.ЧДТУ.252483 12-01
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);
@Mapping(target = "uuidCity", expression =
110
482.ЧДТУ.252483 12-01
"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()).orElseThrow(()->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:
@Repository
public interface UserRepository extends PagingAndSortingRepository<User, Long>,
CrudRepository<User, Long> {
Optional<User> findFirstByUuid(String uuid);
111
482.ЧДТУ.252483 12-01
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);
List<Theater> findAllByIdCity(Pageable pageable, long id);
}
Клас UserService:
@Service
112
482.ЧДТУ.252483 12-01
@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)
);
}
public UserDto get(String uuid) {
User user = userRepository.findFirstByUuid(uuid).get();
return userMapper.toDto(user);
}
public void delete(String uuid) {
113
482.ЧДТУ.252483 12-01
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();
if (!passwordEncoder.matches(userDto.getPassword(), user.getPassword())) {
throw new IllegalArgumentException("Wrong password");
}
} else {
throw new IllegalArgumentException("User not found");
}
authenticate(userDto.getEmail(), userDto.getPassword());
114
482.ЧДТУ.252483 12-01
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);
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());
115
482.ЧДТУ.252483 12-01
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)
);
}
}
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());
}
116
482.ЧДТУ.252483 12-01
}
Клас 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);
}
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();
117
482.ЧДТУ.252483 12-01
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
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());
118
482.ЧДТУ.252483 12-01
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) {
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
119
482.ЧДТУ.252483 12-01
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;
@LastModifiedDate
private OffsetDateTime updatedAt;
}
Клас Theater:
@NoArgsConstructor
@Builder
@Getter
@Setter
@AllArgsConstructor
120
482.ЧДТУ.252483 12-01
@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;
private Integer roomsAmount;
private Integer minPrice;
@CreatedDate
@InsertOnlyProperty
private OffsetDateTime createdAt;
@LastModifiedDate
private OffsetDateTime updatedAt;
}
Клас Cinema:
121
482.ЧДТУ.252483 12-01
@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());
}
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());
}
122
482.ЧДТУ.252483 12-01
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());
}
if (updated.getMinPrice() != null) {
hotel.setMinPrice(updated.getMinPrice());
}
return hotel;
}
}
Клас CinemaInspector:
public class CinemaInspector {
123
482.ЧДТУ.252483 12-01
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?) {
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)
124
482.ЧДТУ.252483 12-01
}
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
)
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()
}
}
125
482.ЧДТУ.252483 12-01
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
}
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]
126
482.ЧДТУ.252483 12-01
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()
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() -> {
127
482.ЧДТУ.252483 12-01
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()
}
}
128
ДОДАТОК В
ANDROID-ДОДАТОК ДЛЯ ПОШУКУ МІСЦЬ ВІДПОЧИНКУ В УКРАЇНІ
ГРАФІЧНІ МАТЕРІАЛИ
482.ЧДТУ.252483 90-01
Листів 10
Розробник _____________ Кавун Д.Р.
Черкаси – 2025
482.ЧДТУ.252483 90-01
Рисунок В.1 – Слайд 1
Рисунок В.2 – Слайд 2
130
482.ЧДТУ.252483 90-01
Рисунок В.3 – Слайд 3
Рисунок В.4 – Слайд 4
131
482.ЧДТУ.252483 90-01
Рисунок В.5 – Слайд 5
Рисунок В.6 – Слайд 6
132
482.ЧДТУ.252483 90-01
Рисунок В.7 – Слайд 7
Рисунок В.8 – Слайд 8
133
482.ЧДТУ.252483 90-01
Рисунок В.9 – Слайд 9
Рисунок В.10 – Слайд 10
134
482.ЧДТУ.252483 90-01
Рисунок В.11 – Слайд 11
Рисунок В.12 – Слайд 12
135
482.ЧДТУ.252483 90-01
Рисунок В.13 – Слайд 13
Рисунок В.14 – Слайд 14
136
482.ЧДТУ.252483 90-01
Рисунок В.15 – Слайд15
Рисунок В.16 – Слайд 16
137
482.ЧДТУ.252483 90-01
Рисунок В.17 – Слайд 17
138