Мобільний застосунок для психологічної допомоги

Ганжа, Поліна Сергіївна

Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/8923

Назва:	Мобільний застосунок для психологічної допомоги
Автори:	Куницька, Світлана Юріївна Ганжа, Поліна Сергіївна
Ключові слова:	ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ;JAVASCRIPT;ПОСЛУГА;NODE.JS;ФІНАНСОВИЙ ЗВІТ;POSTGRESQL
Дата публікації:	7-чер-2025
Короткий огляд (реферат):	АНОТАЦІЯ Ганжа П.С., кваліфікаційна робота на тему «Мобільний застосунок для психологічної допомоги». Напрям підготовки 121 «Інженерія програмного забезпечення», ЧДТУ, Черкаси, 2025. Мета виконання кваліфікаційної роботи бакалавра: проектування та конструювання web-застосунку для зручної автоматизації процесів та забезпечення взаємодії між користувачами. Завдання при проектуванні інформаційної системи: провести аналіз існуючих рішень, визначити їхні переваги та недоліки, а також сформулювати основні вимоги на основі дослідження конкурентного ринку; визначити функціональні та нефункціональні вимоги як замовника, так і розробника; створити діаграми, що відображають архітектуру системи та взаємодію її компонентів; обґрунтувати вибір інструментів розробки; описати додаток за допомогою структурних і функціональних схем; розробити базу даних, інтерфейс користувача та програмні модулі; провести тестування на всіх рівнях; підготувати інструкцію користувача. Об'єкт роботи: процес розробки мобільного застосунку для ведення обліку психологічної допомоги. Предмет розробки: процес розробки програмного забезпечення для ведення обліку пацієнтів психологічної допомоги. Вирішено наступні поставлені задачі: 1. Проаналізувати існуючі аналоги web-застосунку. 2. Розробити взаємопов’язаних елементів мобільного додатку та створити діаграми для представлення архітектури системи та компонентів через їхню взаємодію. 3. Розробити базу даних інформаційної системи. 4. Розробити інтерфейсну частину спроектованого мобільного застосунку. 5. Протестувати та впровадити розроблене програмного забезпечення. Обсяг роботи пояснювальної записки – 117 сторінок, вона містить 3 розділи, 87 рисунків, 15 таблиць, 17 джерел в списку посилань, 4 додатки.
URI (Уніфікований ідентифікатор ресурсу):	https://er.chdtu.edu.ua/handle/ChSTU/8923
Розташовується у зібраннях:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)

Файли цього матеріалу:

Файл	Опис	Розмір	Формат
Кваліфікаційна робота бакалавра Ганжа Ппліна Сергіївна.pdf Restricted Access		4.02 MB	Adobe PDF	Переглянути/Відкрити Запит копії

Показати повний опис матеріалу Перегляд статистики

Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем

ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи бакалавра
на тему: «Мобільний застосунок для психологічної допомоги»

Виконала: студентка 4 курсу, групи ПЗ-2104
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)

Студент Ганжа П. С.
(прізвище та ініціали)
Керівник Куницька С. Ю.
(прізвище та ініціали)
Рецензент Захарова М. В.
(прізвище та ініціали)

Черкаси 2025

Черкаський державний технологічний університет

Факультетінформаційних технологій і систем

Кафедра програмного забезпечення автоматизованих систем

Освітній рівень бакалавр

Спеціальність 121 «Інженерія програмного забезпечення»

Освітня програма Інженерія програмного забезпечення

ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС,
д.т.н., професор
__________________Сергій ГОЛУБ
«___» _______________ 2025 року

З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ

Ганжі Поліні Сергіївні

1. Тема роботи: «Мобільний застосунок для психологічної допомоги»
Керівник роботи к.т.н., доцент Куницька Світлана Юріївна_______________________
Затверджені наказом Черкаського державного технологічного університету №_53/03-03 від
«25» ______02_____ 2025 року
2. Строк подання студентом роботи
_02.06.2025_____________________________________
3. Вхідні дані до роботи: Microsoft Office, Microsoft Word, Windows, Visual Studio Code,
PostgreSQL________________________________________________________________
__
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
1 Існуючі методи та засоби розв’язання поставлених завдань;_
2 Впровадження результатів досліджень у практику проектування програмного
забезпечення інформаційних систем;_
3 Розробка та тестування програмного забезпечення;
Висновки;
Список використаних джерел;
Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;
Додаток А - Специфікація
Додаток Б – Текст програми розробки
Додаток В – Інструкція користувачеві
Додаток Г – Графічні матеріали
6. Консультанти розділів роботи
7. Дата видачі завдання «_02_»_____грудня_____2024р.

КАЛЕНДАРНИЙ ПЛАН

Строк
№ виконання етапів
Назва етапів випускної роботи Примітки
п/п кваліфікаційної
роботи
1 Постановка задачі 03.12.2024 виконано
2 Формування рішень задач 11.12.2024 виконано
3 Погодження завдання 22.12.2024 виконано
Основна стадія
1 Підбір матеріалів 12.02.2025 виконано
2 Аналіз шляхів вирішення 20.02.2025 виконано
поставлених задач
3 Розробка діаграм, як проектного 24.03.2025 виконано
рішення
4 Визначення вимог 30.03.2025 виконано
5 Проектування додатку. Розробка 28.04.2025 виконано
інтерфейсної частини
Заключна стадія
1 Узгодження прийнятих проектних 05.05.2025 виконано
рішень з керівником
2 Оформлення пояснювальної 16.05.2025 виконано
записки роботи в кінцевій редакції
3 Попередній захист роботи 19.05.2025 виконано
4 Затвердження роботи 21.05.2025 виконано
5 Рецензування роботи 25.05.2025 виконано
6 Захист роботи 06.06.2025 виконано

Студент _____________________ Ганжа П.С.

Керівник роботи _____________________ Куницька С. Ю.

АНОТАЦІЯ

Ганжа П.С., кваліфікаційна робота на тему «Мобільний застосунок для
психологічної допомоги». Напрям підготовки 121 «Інженерія програмного
забезпечення», ЧДТУ, Черкаси, 2025.
Мета виконання кваліфікаційної роботи бакалавра: проектування та
конструювання web-застосунку для зручної автоматизації процесів та
забезпечення взаємодії між користувачами.
Завдання при проектуванні інформаційної системи: провести аналіз
існуючих рішень, визначити їхні переваги та недоліки, а також сформулювати
основні вимоги на основі дослідження конкурентного ринку; визначити
функціональні та нефункціональні вимоги як замовника, так і розробника;
створити діаграми, що відображають архітектуру системи та взаємодію її
компонентів; обґрунтувати вибір інструментів розробки; описати додаток за
допомогою структурних і функціональних схем; розробити базу даних,
інтерфейс користувача та програмні модулі; провести тестування на всіх рівнях;
підготувати інструкцію користувача.
Об'єкт роботи: процес розробки мобільного застосунку для ведення обліку
психологічної допомоги.
Предмет розробки: процес розробки програмного забезпечення для
ведення обліку пацієнтів психологічної допомоги.
Вирішено наступні поставлені задачі:
1. Проаналізувати існуючі аналоги web-застосунку.
2. Розробити взаємопов’язаних елементів мобільного додатку та створити
діаграми для представлення архітектури системи та компонентів через
їхню взаємодію.
3. Розробити базу даних інформаційної системи.
4. Розробити інтерфейсну частину спроектованого мобільного застосунку.
5. Протестувати та впровадити розроблене програмного забезпечення.
Обсяг роботи пояснювальної записки – 117 сторінок, вона містить 3
розділи, 87 рисунків, 15 таблиць, 17 джерел в списку посилань, 4 додатки.
Ключові слова: ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ, JAVASCRIPT,
ПОСЛУГА, NODE.JS ФІНАНСОВИЙ ЗВІТ, POSTGRESQL.

ВСТУП………………………………………………………………………………..5
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ………………………………………………………………….…………9
1.1 Існуючі методи до розв’язання поставленого завдання …………….……….9
1.2 Огляд аналогів…………………………………………………………..………10
1.3 Сформовані задачі для проектування……………………………….………...14
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ………………………………….……….17
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ……………………………………………………………..……………..19
2.1 Моделювання предметної області…………………………………………….19
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області…………………………………………………………….…..19
2.1.2 Елементи моделювання предметної області……………………………….22
2.1.3 Робоча область моделювання……………………………………………….23
2.2 Формування та аналіз вимог…………………………………………………..23
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги………………………………………………………………………………24
2.2.2 Формування вимог за діаграмою прецедентів……………………………..28
2.3 Проектування логічної структури…………………………………………….29
2.3.1 Діаграми класів………………………………………………………………30
2.3.2 Діаграми пакетів……………………………………………………………..34
2.4 Архітектурне проектування…………………………………………………...35
2.4.1 Діаграма компонентів………………………………………………………..36

ЧДТУ.252150.003 ПЗ
№ П
Л Л Лист
«Мобільний
3
застосунок для
Н. психологічної допомоги» ФІТІС, кафедра ПЗАС, ПЗ-2104
Голуб С.В. Пояснювальна записка.
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання………………………………………………..……………………….37
2.5 Моделювання поведінки системи………………………………………….....39
2.5.1 Діаграма діяльності………………………………………………………….39
2.5.2 Діаграма послідовності……………………………………………………...46
2.5.3 Діаграма комунікації………………………………………………………...60
2.5.4 Діаграма скінченного автомату……………………………………………..64
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ…………………………………………...66
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ67
3.1 Розробка програмного комплексу…………………………………………….67
3.1.1 Обґрунтування вибору засобів реалізації…………………………………..67
3.1.2 Опис структурної (функціональної) схеми…………………….…………...69
3.1.3 Опис логічної схеми системи…………………………………….………….72
3.1.4 Розробка бази даних…………………………………………….……………73
3.1.5 Розробка інтерфейсу користувача……………………………….…………..79
3.1.6 Опис розробки програмних компонентів…………………….……………..92
3.2 Тестування системи……………………………………….……………………95
3.2.1 Модульне тестування……………………………………….………………..95
3.2.2 Інтеграційне тестування……………………………………………………..97
3.2.3 Системне тестування………………………………………………………...98
3.2.4 Приймальне тестування……………………………………..……………..100
3.3 Приклади впровадженого програмного комплексу………..………………101
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ…………………………..…………….112
ВИСНОВКИ……………………………………………………..………………..113
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ………………………..……………….115
Додаток А……………………………………..…………….…………………….118
Додаток Б………………………………………………………………………....120
Додаток В………………………………………………………….……………...134
Додаток Г……………………………………………………………….………...140

ЧДТУ.252150.003 ПЗ
№ П
ВСТУП

Актуальність теми. За даними Всесвітньої організації охорони здоров’я,
понад 970 мільйонів людей у світі мають психічні розлади [1]. В Україні лише за
дев’ять місяців 2024 року понад 353 000 громадян звернулися до сімейних
лікарів через тривожні стани, порушення сну, пригнічений настрій тощо [2]. При
цьому лише приблизно 2 % за потреби зверталися до фахівців із психічного
здоров’я.
Стрес, викликаний війною, соціальними змінами та економічною
нестабільністю, є звичною реальністю для багатьох українців. Водночас доступ
до якісної психологічної допомоги обмежений через дефіцит фахівців, фінансові
труднощі, психологічні бар’єри або страх осуду [3]. Враховуючи це, дедалі
важливішою стає можливість отримати підтримку в доступному,
конфіденційному та зручному форматі [4]. І мобільні додатки є чудовим
рішенням для цього. Вони дозволяють надавати психологічну підтримку та
полегшити доступ до онлайн-консультацій, незалежно від місця проживання або
обставин [5].
Таким чином, можна сказати, що тема даної кваліфікаційної роботи є
надзвичайно актуальною, оскільки спрямована на вирішення реально існуючої
проблеми шляхом використання сучасних інформаційних технологій у сфері
охорони психічного здоров’я.
Мета розробки. Метою кваліфікаційної роботи бакалавра є розробка
мобільного застосунку з окремими ролями для пацієнтів і психологів з
відповідним функціоналом.
З боку пацієнта додаток надає доступ до бази психологів, запису на
консультації в залежності від фільтрів та вимог, робота з вправами та статтями
для самодопомоги, перегляд та можливість скасування записів, надсилання
відгуків та редагування власного профіля.
З боку психолога додаток дозволяє формувати та редагувати свій профіль,
бачити список записів та скасовувати їх, переглядати загальну особисту
інформацію про пацієнтів.
Задачі розробки. Для реалізації цієї мети були поставлені такі основні
задачі:
1. Проаналізувати аналоги існуючих додатків.
2. Спроєктувати предметну область.
3. Розробити базу даних.
4. Розробити інтерфейсну частину.
5. Протестувати функціонал та захист даних.
Об'єкт розробки. Об’єктом розробки є процес надання психологічної
підтримки за допомогою мобільного застосунку, що включає взаємодію між
пацієнтами та фахівцями.
Предмет розробки. Предмет розробки – додаток для Android, що
забезпечує взаємодію користувачів двох типів: пацієнтів та психологів, де для
кожного з них реалізовано окремий інтерфейс та функціонал, відповідний їх
ролям у системі.
Методи проєктування. Під час проєктування застосунку були
використані такі підходи:
− об’єктно-орієнтований підхід для структурування компонентів та
розподілу функцій і властивостей [6];
− UML-моделювання для опису взаємодії користувачів із системою,
структури даних, процесів та сценаріїв використання [7];
− UX/UI принципи дизайну для побудови інтуїтивно зрозумілого
інтерфейсу з урахуванням адаптивності та зручності взаємодії [8, 9,
10].
Методи конструювання. Для реалізації застосунку було використано такі
інструменти та технології:
− мова програмування – Java;
− середовище розробки – Android Studio;
− бібліотеки:
− Retrofit для реалізації взаємодії з серверною частиною через
REST API [11];
− Picasso для завантаження зображень [12];
− Toasty для кращого виведення повідомлень з інформацією [13];
− View Binding для безпечної роботи з елементами інтерфейсу
[14].
− SharedPreferences для забезпечення збереження стану авторизації
[15];
− JWT (JSON Web Token) для забезпечення авторизації та підтримки
сесії користувача [16];
− серверна частина:
− мова програмування – PHP;
− фреймворк – PHP Lumen, який використовується для побудови
REST API [17];
− база даних – MySQL, для зберігання користувачів, записів,
відгуків, тестів та іншої інформації [18].
Опис отриманих результатів. У ході роботи було створено мобільний
застосунок з повноцінним функціоналом для двох типів користувачів.
Для пацієнта реалізовані такі можливості:
− створення облікового запису та авторизації;
− редагування профілю;
− перегляд фахівців, детальної інформації про них з можливістю
фільтрації пошуку та залишення відгуків;
− запис на прийом з вибором дати й часу, перегляд записів та
можливість їх скасувати;
− використання тестів та вправ для самодопомоги.
Для психологів було розроблено:
− створення облікового запису та авторизації;
− редагування профілю;
− перегляд записів на консультації та профілів пацієнтів.
Крім того вдалось реалізувати:
− механізм збереження та перевірки ключів доступу;
− обробку помилок і перевірку коректності введених даних;
− механізм зміни дизайну інтерфейсу відповідно до обраних
налаштувань колірної схеми операційної системи Android.
Практичне значення отриманих результатів полягає в тому, що цей
додаток може полегшити людям пошук психолога, зробити допомогу
доступнішою, а також забезпечити корисний інструмент для підтримки
емоційного стану.
Особистий внесок автора полягає в повній реалізації проєкту: від аналізу
вимог і проєктування архітектури до програмування основних функцій,
реалізації клієнт-серверної частини, розробки інтерфейсу та проведення
тестування.

РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ

За даними ВООЗ, у світі понад 970 мільйонів людей мають розлади психіки
або поведінки, і ця цифра зростає щороку [1]. Значна частина населення не
отримує належної психологічної допомоги через нестачу фахівців, географічну
недоступність, психологічні бар’єри або високу вартість послуг [3].
Завдяки цьому всьому все більшої популярності набувають цифрові
рішення, зокрема мобільні застосунки, які дають змогу отримувати психологічну
підтримку дистанційно [4, 5]. У даному розділі представлені аналіз існуючих
аналогів, сучасні методи та засоби розробки таких додатків та сформоване в
результаті дослідження завдання для подальшої розробки.

1.1 Існуючі методи до розв’язання поставленого завдання
Розробка мобільних додатків для психологічної підтримки є комплексним
завданням, що поєднує інформаційні технології, психологію та базові принципи
дизайну інтерфейсів. Для аналізу використано наукові статті, монографії,
технічну документацію та відкриті джерела.
Для додатків психологічної підтримки в різноманітних джерелах
акцентується увага на необхідності інтеграції принципів UX/UI для забезпечення
зручності використання. Зазначаєтсья, що користувачі психологічних додатків
часто перебувають у стані стресу, тому інтерфейс має бути максимально простим
та інтуїтивним [8, 9, 10].
Сучасним підходом у розробці Android-додатків є використання View
Binding, що забезпечує безпечний доступ до елементів інтерфейсу без
використання методу findViewById [14]. Це зменшує кількість помилок та
прискорює розробку, особливо при роботі з фрагментами.
Крім цього, в сучасній мобільній розробці часто застосовуються механізми
збереження стану через SharedPreferences [15]. Це дозволяє полегшити процес
повторної авторизації в додатку та покращує досвід користувача.
Питання безпеки даних є критично важливим. Використання JWT (JSON
Web Token) для авторизації та шифрування даних є поширеним методом захисту
інформації [16]. Це також забезпечує автоматичний вхід користувача без потреби
повторної авторизації та підвищує зручність взаємодії з додатком. Однак
проблема витоку даних залишається актуальною через недостатню увагу до
валідації введених даних та обробки помилок на сервері.
Часто досліджується використання REST API для клієнт-серверної
взаємодії, що є стандартом для більшості сучасних мобільних додатків. У
розробленому застосунку використовується бібліотека Retrofit, яка дозволяє
швидко здійснювати запити до сервера, обробляти відповіді у форматі JSON та
реалізовувати авторизацію користувачів за допомогою JWT. [11]
Окремо слід відзначити, що об'єктно-орієнтований підхід (ООП), який
використовується в розробці, сприяє модульності проєкту, повторному
використанню коду та зручності масштабування системи [6, 19]. Це особливо
важливо у випадках, коли застосунок має декілька типів користувачів (пацієнт і
психолог) з відмінним функціоналом.
Крім того, при реалізації клієнт-серверної взаємодії у багатьох сучасних
мобільних додатках застосовуються легкі мікрофреймворки, зокрема PHP
Lumen, які дозволяють створювати REST API з мінімальними витратами
ресурсів. Такі рішення забезпечують швидку обробку HTTP-запитів, підтримку
авторизації за допомогою JWT, а також ефективну взаємодію з базами даних [20,
21, 22].
У якості сховища часто використовується MySQL –система управління
базами даних, яка надає широкі можливості для організації, пошуку й
збереження структурованої інформації [18]. Такий підхід дозволяє легко
масштабувати систему, забезпечити її продуктивність і безпеку при обробці
запитів користувачів.
Враховуючи наведені дані було вирішено застосувати такі методи
розробки, щоб забезпечити не лише якісну архітектуру додатку, а й підвищити
рівень зручності та безпеки для кінцевого користувача:
1. Об’єктно-орієнтоване програмування (ООП). Забезпечує
модульність і повторне використання коду [6, 19].
2. REST API реалізований на PHP Lumen. Забезпечує швидкий доступ
до інформації [20, 21, 22].
3. UX/UI-дизайн. Ключовий для залучення користувачів [8, 9, 10].
4. View Binding для безпечної роботи з елементами інтерфейсу [14].
5. SharedPreferences для збереження даних авторизації [15].
6. JWT для захищеної авторизації та підтримки сесії користувача [16].
7. База даних MySQL, для зберігання інформації [18].
8. Інструменти розробки включають Android Studio, мова
програмування Java, бібліотеки Retrofit, Picasso та Toasty [11, 12, 13].

1.2 Огляд аналогів
1.2.1 Rozmova [23]
Rozmova – це додаток для підтримки психічного здоров'я, розроблений у
2020 році командою фахівців із психотерапії та IT. Додаток надає користувачам
можливість знайти психологів та записатися на консультації в онлайн-форматі,
обравши зручний спосіб спілкування.
Функціонал. Додаток зосереджений на наданні доступу до консультацій із
психологами в Україні. Rozmova дозволяє користувачам обирати психолога,
переглядати його профіль і записуватись на консультацію в онлайн-режимі.
Додаток також підтримує відео- і текстові сеанси, надаючи гнучкість у форматі
консультацій.
Цільова аудиторія. Люди, які шукають доступну підтримку психологів, особливо
в Україні.
Особливості:
− обрання психолога з переліку, що відповідає певним критеріям
(спеціалізація, досвід, ціна);
− система бронювання, яка дозволяє користувачам записатися на
консультацію в зручний час;
− розширений пошук, що дає змогу обирати фахівців на основі відгуків
клієнтів та рейтингів.
Переваги: можливість вибору конкретного фахівця, який відповідає запиту
клієнта; прозора система оплати та відгуків.
Недоліки: відсутні функції для самодопомоги; орієнтація переважно на
консультації, що може зменшити інтерес користувачів, які шукають
безкоштовний контент.

Рисунок 1.1 – Інтерфейс додатку Rozmova

Рисунок 1.2 – Інтерфейс додатку Rozmova

1.2.2 Mindly [24]
Mindly – це додаток, орієнтований на підтримку психічного здоров'я,
розроблений із метою забезпечення доступу до психологічних послуг в онлайн-
форматі. Додаток створений для того, щоб користувачі могли легко записатися
на консультацію до психолога, зважаючи на його спеціалізацію та досвід.
Функціонал. Mindly пропонує користувачам інструмент для вибору психолога та
організації прийомів в онлайн-форматі. Додаток дозволяє знайти спеціаліста,
ознайомитись із його профілем та записатися на консультацію у зручний час.
Цільова аудиторія. Люди, які потребують психологічної допомоги та шукають
швидкий спосіб знайти фахівця для консультації.
Особливості:
− вибір психолога за різними критеріями (досвід, спеціалізація,
відгуки);
− можливість швидкої організації онлайн-прийому;
− інтегрована система онлайн-запису для зручності користувачів.
Переваги: легкий пошук психолога і запису на консультацію.
Недоліки: немає інструментів для самодопомоги, що може обмежувати
функціонал для користувачів, які прагнуть комплексного підходу до покращення
свого психічного стану.

Рисунок 1.3 – Інтерфейс додатку Mindly

Рисунок 1.4 – Інтерфейс додатку Mindly

1.2.3 Talkspace [25]
Talkspace – один із найвідоміших додатків для онлайн-терапії, запущений у 2012
році в США. Він пропонує користувачам доступ до ліцензованих психологів
через текстовий, аудіо- та відеочат, забезпечуючи конфіденційність і зручність
онлайн-консультацій.
Функціонал. Додаток для терапії та підтримки психічного здоров'я, що надає
користувачам доступ до психологів у режимі чату, відео- чи телефонних
консультацій. Користувачі можуть вибирати спеціаліста, переглядати його
профіль і отримувати консультації на регулярній основі.
Цільова аудиторія. Люди, які шукають професійну терапевтичну підтримку
через онлайн-формат.
Особливості:
− можливість обрати психолога на основі його кваліфікації та
спеціалізації;
− три формати комунікації (текст, аудіо та відео), що надають
гнучкість у взаємодії;
− секретність та безпека всіх повідомлень і сеансів для збереження
конфіденційності клієнта.
Переваги: широкий вибір фахівців, можливість гнучкого запису, доступ до
послуг у будь-який час.
Недоліки: платна підписка на сервіси обмежує доступ для тих, хто шукає
безкоштовний контент; відсутність вправ для самодопомоги або навчальних
матеріалів для особистісного розвитку, а також відсутня українська локалізація.
1.2.4 Svitlo [26]
Svitlo – додаток, запущений у 2020 році командою фахівців у галузі психічного
здоров’я. Він надає користувачам можливість отримати психологічну підтримку
через медитації, вправи для самодопомоги та інструменти для управління
стресом. Додаток акцентує увагу на доступності та простоті використання,
створюючи комфортне середовище для користувачів, які шукають допомогу у
покращенні свого психічного стану.
Функціонал. Додаток надає доступ до вправ для стабілізації емоційного стану,
медитацій, аудіотреків для заспокоєння, а також статей та корисних матеріалів
для самодопомоги.
Цільова аудиторія. Svitlo розрахований на людей, які переживають стрес,
тривогу чи емоційне виснаження, та шукають засоби для саморегуляції.
Особливості:
− вправи для зниження стресу та заспокоєння, що містять дихальні
техніки, візуалізації та прості методи самодопомоги;
− медитації, які допомагають стабілізувати емоційний стан і
поліпшити фокус;
− статті та матеріали від професійних психологів, що допомагають
користувачам розібратися з емоціями та знайти способи впоратися з
кризою.
Переваги: додаток створений з урахуванням сучасних потреб українців у
психологічній підтримці; доступний інтерфейс і наявність української мови, що
робить його зручним для локальної аудиторії.
Недоліки: наразі відсутня функція запису на консультації з психологом, що
обмежує його до використання лише як інструменту самодопомоги.

Рисунок 1.5 – Інтерфейс додатку Svitlo

Рисунок 1.6 – Інтерфейс додатку Svitlo

1.3 Сформовані задачі для проєктування
На основі проведеного аналізу існуючих програмних рішень і вивчення сучасних
підходів до розробки мобільних застосунків було сформульовано такі задачі, які
необхідно реалізувати в рамках даної кваліфікаційної роботи:
6. Проаналізувати аналоги існуючих додатків.
7. Спроєктувати предметну область.
8. Розробити базу даних.
9. Розробити інтерфейсну частину.
10. Тестування функціоналу та захист даних.
Крім загальних задач, сформовано основну мету розробки, що полгягає в
створенні зручного та інтуїтивно зрозумілого мобільного застосунку для
психологічної підтримки, який передбачає наявність двох типів користувачів
(пацієнта та психолога) з відповідним функціоналом.
Такий розподіл ролей дозволяє забезпечити індивідуалізований підхід до
взаємодії з додатком. Кожен тип користувача отримує інтерфейс і можливості,
адаптовані до його потреб та вимог, а ролі автоматично зберігаються самим
застосунком.
Основні функції для пацієнта, які повинні бути реалізовані у додатку: реєстрація
та авторизація, можливість перегляду профілів психологів, фільтрація за ціною,
форматом консультації (онлайн/офлайн), запис на прийом із вибором дати та
часу, перегляд майбутніх консультацій, можливість скасування запису, перегляд
матеріалів для самодопомоги, можливість залишити відгук, редагування
власного профілю.
Для психолога має бути реалізована можливість реєстрації та авторизації,
редагування даних та фото профілю, перегляд та скасування записів, перегляд
інформації про пацієнта.
Крім функціональних можливостей, для досягнення стабільності, безпеки та
масштабованості системи було визначено низку технічних вимог до архітектури
та реалізації програмного забезпечення.
Застосунок побудований за принципом клієнт-серверної архітектури, де
мобільна частина відповідає за інтерфейс і взаємодію з користувачем, а серверна
частина – за обробку запитів, логіку процесів і роботу з базою даних.
Взаємодія між клієнтом і сервером здійснюється через REST API із
використанням формату JSON. Усі запити передаються по захищеному HTTPS-
з’єднанню, що дозволяє забезпечити конфіденційність та цілісність даних.
Для автентифікації користувачів реалізована авторизація за допомогою JWT
(JSON Web Token). Це дає змогу надійно перевіряти права доступу без
збереження паролів на стороні клієнта або повторної авторизації при кожному
запиті. Сам токен зберігається на пристрої користувача в SharedPreferences, що
дозволяє підтримувати активну сесію.
Для зберігання структурованих даних (користувачі, профілі, записи, відгуки,
статті, тести) використовується централізована реляційна база даних MySQL, до
якої має доступ лише серверна частина системи.
Окрім цього, у клієнтській частині використовується View Binding, що
забезпечує безпечний і зручний доступ до елементів інтерфейсу, а також
реалізовано сучасні принципи UX/UI-дизайну для покращення взаємодії з
користувачем.
Це завдання дозволить реалізувати мобільний застосунок, що буде не лише
функціональним, але й зручним у використанні і корисним для користувачів, які
шукають психологічну підтримку.
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ

Даний розділ включає в себе аналіз існуючих методів розв’язання
поставленого завдання, огляд аналогів та формування задач для проєктування на
основі проведеного аналізу.
Сучасні методи розробки мобільних додатків для психологічної допомоги
часто включають в себе: використання REST API для обміну даними між
клієнтом і сервером, JWT для безпечної авторизації, SharedPreferences для
збереження стану сесії, MySQL для збереження інформації та зручної роботи з
нею, а також принципи зручного UX/UI-дизайну. Такі підходи дозволяють
зробити програму не лише зручною, але й надійною в роботі.
В якості аналогів було розглянути додатки: Rozmova, Mindly, Talkspace та
Svitlo. Усі вони мають певні переваги. Наприклад, більшість з них дає змогу
обрати психолога, переглянути його профіль та записатись на консультацію.
Talkspace також підтримує декілька форматів зв’язку: текст, аудіо, відео.
Проте виявлено і недоліки. Наприклад, деякі додатки, як-от Rozmova та Mindly,
не містять матеріалів для самодопомоги. У Svitlo навпаки є вправи й медитації,
але немає можливості запису до психолога. У Talkspace доступ до послуг
платний і немає української мови.
В розробленому додатку поєднані переваги кожного з аналогів і додано
функціонал, якого їм бракує. Зокрема, реалізовано не тільки пошук і запис до
психолога, а й доступ до матеріалів для самодопомоги. Також додаток підтримує
фільтрацію спеціалістів, залишення відгуків, перегляд майбутніх прийомів і
можливість їх скасування.
Отже, проведений аналітичний огляд дозволив визначити, яких саме
функцій не вистачає в існуючих рішеннях, і на основі цього було сформовано
завдання для розробки власного мобільного додатку з урахуванням потреб
користувачів.

РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ

Для виконання поставлених задач розробки потрібно провести
моделювання предметної області, сформувати вимоги до програмного
забезпечення та описати систему за допомогою діаграм для відображення
архітектури мобільного додатку та взаємодії його компонентів.
2.1 Моделювання предметної області
Моделювання предметної області є важливим етапом у процесі
проєктування ПЗ. Воно дозволяє наглядно відобразити та описати ключові
об'єкти, визначити їх зв’язки та взаємодію в межах системи. [27, 28]
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області
Предметна область моделювання охоплює процес надання психологічної
допомоги за допомогою мобільного застосунку, що підтримує дві ролі
користувачів: пацієнт та психолог. Кожен з них має доступ до відповідного
функціоналу через інтерфейс Android-додатку, який взаємодіє з базою даних,
розміщеною на сервері, через REST API.
Модель предметної області включає ключові сутності, такі як:
1 Користувач – основна сутність, яка представляє авторизовану особу
в системі. Вона має атрибути, спільні для пацієнта й психолога: логін,
електронна пошта, пароль, а також роль (тип облікового запису). На
основі ролі формується доступ до відповідного функціоналу.
2 Пацієнт – користувач, який шукає психологічну допомогу. Він може
переглядати профілі фахівців, фільтрувати їх за критеріями (ціна, тип
консультації), записуватися на консультації, переглядати свої записи,
скасовувати їх, залишати відгуки, редагувати профіль, а також
переглядати статті й проходити тести для самодопомоги.
3 Психолог – користувач, який надає послуги. Він створює та редагує
власний профіль, вказує спеціалізацію, досвід, ціну, має доступ до
списку своїх записів.
4 Профіль – набір персональних даних користувача, який включає різні
дані в залежності від ролі в системі. Наприклад: ім’я, прізвище,
спеціалізація, опис, формат роботи (онлайн/офлайн), місто, досвід,
ціна за сеанс. Ця інформація відображається іншим користувачам.
5 Запис на консультацію – подія, яка створюється пацієнтом після
вибору психолога, дати й часу. Вона зберігається в системі та
доступна обом сторонам. Містить інформацію про дату, час, статус
(активний, скасований), ідентифікатори обох користувачів.
6 Відгук –оцінка або коментар, залишені пацієнтом після проведеної
консультації. Відгуки зберігаються в системі, можуть переглядатися
іншими пацієнтами та впливають на репутацію фахівця.
7 Матеріали для самодопомоги – окремий функціональний блок
застосунку, який включає психологічні статті та тести. Ці ресурси
доступні для кожного авторизованого пацієнта.
8 Тест – інтерактивний психологічний опитувальник, що дозволяє
пацієнту самостійно оцінити свій психоемоційний стан.
9 Стаття – текстовий матеріал з порадами, поясненнями або
рекомендаціями щодо емоційного здоров’я. Використовуються як
освітній інструмент у рамках функцій самодопомоги.
Словник предметної області включає в себе подані раніше терміни, а
також:
1 Авторизація – механізм доступу до функцій застосунку за допомогою
логіна й пароля. Здійснюється через JWT (JSON Web Token), що
зберігається локально на пристрої.
2 JWT (JSON Web Token) – формат ідентифікатора сесії, який
використовується для безпечної авторизації користувача. Після входу
він зберігається локально та використовується для підтвердження
доступу без повторного введення пароля.
3 SharedPreferences – механізм локального зберігання даних у
мобільному застосунку Android, що дозволяє зберігати ключові пари
значень. У даному застосунку використовується для збереження
стану авторизації (JWT) та інших параметрів користувача, що
забезпечує автоматичний вхід без повторного введення облікових
даних після перезапуску додатку.
4 REST API – інтерфейс, через який мобільний застосунок
обмінюється даними з сервером.
2.1.2 Елементи моделювання предметної області
Моделювання предметної області відіграє важливу роль у розробці
програмного забезпечення, дозволяючи сформувати чітке уявлення про
структуру та взаємодію компонентів системи. Для цього застосовуються різні
елементи, які допомагають візуально та текстово представити об’єкти та їхні
зв’язки в мобільному додатку.
Основними інструментами моделювання в даній роботі є UML-діаграми,
які дають змогу детально описати систему. Окрім графічних засобів,
використано текстові описи, які розкривають функціональне призначення
кожної сутності.
Моделювання також враховує взаємодію між клієнтською та серверною
частинами системи через API, що дозволяє підтримувати актуальність даних,
таких як оновлення профілів чи відгуків. Такий підхід сприяє створенню цілісної
моделі, яка є базою для подальших етапів проєктування.
2.1.3 Робоча область моделювання
У процесі моделювання предметної області було визначено робочу
область, яка відображає ключові аспекти функціонування мобільного додатку
для психологічної підтримки. Ця область охоплює основні компоненти системи,
їхні взаємозв’язки та призначення.
Було вирішено виділити наступні компоненти як основні елементи робочої
області:
1 Користувач – центральна сутність, яка представляє авторизовану
особу в системі. Визначено, що користувач має доступ до функцій
залежно від своєї ролі – пацієнта чи психолога.
2 Пацієнт – компонент, який уособлює особу, що шукає психологічну
підтримку. Передбачено, що пацієнт може переглядати профілі
психологів, записуватися на консультації, залишати відгуки та
використовувати матеріали для самодопомоги, такі як статті та тести.
3 Психолог – компонент, який відображає фахівця, що надає послуги.
Було встановлено, що психолог має можливість редагувати профіль
та переглядати записи.
4 Профіль – набір даних, який характеризує користувача в системі.
Визначено, що профіль містить інформацію, доступну для перегляду
іншими користувачами, і може оновлюватися власником.
5 Запис на консультацію – елемент, який фіксує домовленість між
пацієнтом і психологом. Було передбачено, що запис включає дату,
час та статус, а також може бути скасованим.
6 Відгук – елемент, який відображає оцінку консультації. Було
визначено, що відгуки створюються пацієнтами та впливають на
репутацію психолога.
7 Матеріали для самодопомоги – розділ, що включає статті та тести.
Передбачено, що ці ресурси надаються пацієнтам для підтримки
їхнього емоційного стану.
Робоча область базується на взаємодії цих компонентів через серверну
частину системи за допомогою API. Це дає змогу забезпечити обмін даними,
наприклад, оновлення профілів чи синхронізацію розкладу. Такий підхід
дозволяє створити цілісну модель, яка враховує всі ключові процеси додатку.
2.2 Формування та аналіз вимог
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
У процесі розробки мобільного додатку для психологічної підтримки було
сформовано вимоги до програмного забезпечення [29].
Первинні вимоги включають базові потреби системи, а саме: забезпечення
авторизації користувачів із розмежуванням на пацієнтів і психологів, надання
можливості перегляду профілів, створення записів на консультації, доступ до
матеріалів для самодопомоги (статей і тестів) та базове управління власним
профілем. Детальні вимоги розширюють первинні та охоплюють: можливість
фільтрації психологів за різними спеціалізацією, досвідом чи ціною, підтримку
скасування записів, збереження відгуків із текстовим коментарем і рейтинговою
оцінкою та проходження тестів із відображенням результату.
Вимоги замовника, сформульовані на основі аналізу потреб користувачів,
включають: створення інтуїтивно зрозумілого інтерфейсу з підтримкою
української мови, забезпечення швидкого доступу до консультацій (за 2-3 кліки),
забезпечення конфіденційності даних через безпечну авторизацію, швидкий
доступ до записів на консультації та можливість ефективного пошуку
психологів. Вимоги розробника зосереджуються на технічній реалізації та
передбачають: інтеграцію з сервером через REST API з використанням JWT для
авторизації, оптимізацію додатку для роботи на пристроях із Android 8.0 і вище,
а також реалізацію механізмів синхронізації даних між клієнтом і сервером для
оновлення розкладу та профілів.
Функціональні вимоги деталізовано як конкретні можливості системи. Було
передбачено, що додаток має включати:
− реєстрацію та вхід користувачів із перевіркою логіна та пароля, а
також розмежуванням доступу за ролями (пацієнт/психолог);
− перегляд і редагування профілів із можливістю додавання
фотографії, опису спеціалізації (для психологів), контактної
інформації та інших важливих даних;
− створення, перегляд і скасування записів на консультації з
урахуванням доступного розкладу психолога;
− фільтрація психологів при пошуку за різними критеріями;
− залишення відгуків та їхній перегляд іншими користувачами;
− надання статей і тестів із питаннями та автоматичним підрахунком
результатів для самодопомоги.
Нефункціональні вимоги охоплюють якості, що забезпечують ефективність
системи. Було визначено, що додаток має відповідати таким критеріям:
− надійність – безперервна робота системи при стандартному
навантаженні, що підтримується стабільною роботою API;
− безпека – захист даних через шифрування маркерів авторизації (JWT)
і використання HTTPS [30];
− продуктивність – завантаження списків психологів із фільтрами та
матеріалів за 2-3 секунди при стабільному інтернеті;
− універсальність – сумісність із Android 8.0 і вище;
− зручність – інтуїтивно зрозумілий інтерфейс із підказками.
Такий детальний підхід до формування вимог створив основу для
подальшого проєктування, враховуючи як функціональні можливості, так і
технічні характеристики системи.
2.2.2 Формування вимог за діаграмою прецедентів
Діаграма прецедентів (рисунок 2.1) відображає основні функції додатку та
взаємодію акторів із системою. У додатку передбачено три основні ролі: пацієнт,
психолог та адміністратор.
Пацієнт має змогу реєструватися, проходити авторизацію, заповнювати й
редагувати профіль, переглядати список психологів та фільтрувати їх за ціною,
форматом консультацій та іншими критеріями. Основною функцією є запис на
консультацію, перегляд і скасування власних записів, а також можливість
залишити відгук. Крім цього, пацієнтам доступні тести та статті для
самодопомоги.
Психолог також проходить авторизацію та редагує свій профіль. Він може
створювати та змінювати графік роботи, переглядати записи, залишені про нього
відгуки, а також самостійно скасовувати консультації у разі необхідності.
Адміністратор відповідає за створення, редагування та видалення статей і
тестів для самодопомоги. Сам додаток для користувачів не передбачає прямого
зв’язку з адміністратором.
Ця діаграма дозволила сформулювати ключові вимоги до
функціональності додатку з урахуванням кожної ролі. Вона стала логічною
основою для подальшого проєктування інтерфейсу та взаємодії користувачів із
системою.

Рисунок 2.1 – Діаграма прецендентів
2.3 Проектування логічної структури
2.3.1 Діаграми класів
Для кращого розуміння структури системи та взаємозв’язків між об’єктами
було побудовано UML-діаграму класів (рисунок 2.2). Ця діаграма дозволяє
побачити, які основні сутності існують у додатку, які поля та методи їм належать,
а також як вони пов’язані між собою.
В основі системи знаходиться клас користувач, від якого наслідуються два
основні типи: пацієнт і психолог. Усі користувачі мають спільні атрибути, такі
як електронна пошта, пароль та роль (для розмежування доступу).
Пацієнт має доступ до тестів, статей, може записуватися на консультації,
переглядати список психологів та залишати відгуки. Також він може скасовувати
записи при потребі.
Психолог, зі свого боку, вказує спеціалізацію, ціну, досвід, інформацію про
себе. Йому доступні функції перегляду записів та можливість скасування
прийомів.
Клас запис зберігає інформацію про заплановану консультацію: дату, час,
статус (активний або скасований) та прив’язаний до обох сторін: пацієнта й
психолога.
Клас відгук описує оцінку, яку залишає пацієнт після завершеної
консультації, а розклад відповідає за доступні години, у які психолог може
проводити прийоми.
Класи тест і стаття є частиною функціоналу самодопомоги. Вони доступні
лише пацієнтам і не потребують зворотного зв’язку.
Завдяки діаграмі класів вдалося структурувати логіку даних у системі, що
дозволило сформувати чітку модель для реалізації бази даних та відповідних
API-запитів.

Рисунок 2.2 – Діаграма класів

2.3.2 Діаграми пакетів
Щоб узагальнити структуру додатку, була побудована базова UML-
діаграма пакетів (рисунки 2.3). Вона відображає основні частини проєкту,
згруповані за функціональним призначенням. Такий підхід допомагає краще
зрозуміти архітектуру додатку та логіку його побудови.
У структурі виділено кілька головних модулів:
− features.auth – пакет, що відповідає за авторизацію. Клас AuthGuard
перевіряє стан авторизації, а AppStorage зберігає його локально в
памʼяті пристрою;
− features.patient – містить функціонал для пацієнта. Тут реалізовані
елементи інтерфейсу: список психологів, профіль, особисті записи на
прийом, головна активність;
− features.psychologist – логіка для психолога, яка на цьому етапі
представлена окремою активністю PsychologistMainActivity;
− models – містить обʼєкти, які використовуються для передачі даних
між додатком і сервером. Наприклад, ProfileResponse відповідає за
профіль користувача, VisitResponse – за записи на консультації;
− network – пакет, де описано взаємодію з сервером через REST API.
ApiService описує запити, ApiClient – налаштовує з'єднання;
− utils – допоміжний код, зокрема, JWTUtils використовується для
розшифрування ідентифікатора сесії;
− database – умовне представлення структури бази даних. Тут показані
основні таблиці: users, appointments (записи на прийом) та opinions
(відгуки). Вони повʼязані з моделями, що використовуються у
додатку.
Ця діаграма показує загальну картину архітектури додатку без надмірних
деталей, дозволяючи легко орієнтуватись у його структурі та логіці. Вона є
хорошою основою для розуміння того, як між собою пов’язані компоненти
інтерфейсу, серверна взаємодія, збереження даних і логіка.

Рисунок 2.3 – Діаграма пакетів (1 частина)

Рисунок 2.3 – Діаграма пакетів (2 частина)
2.4 Архітектурне проєктування
2.4.1 Діаграма компонентів
Діаграма компонентів (рисунок 2.4) ілюструє, з яких основних частин
складається система та як між собою взаємодіють компоненти Android-додатку,
сервер і база даних [31].
У клієнтській частині застосунку передбачено окремі активності для
кожної ролі:
− PatientMainActivity – головний екран для пацієнта, з якого
відбувається навігація до фрагментів для перегляду психологів,
запису на консультацію, проходження тестів тощо;
− PsychologistMainActivity – основний компонент для психолога.
Обидві активності взаємодіють із внутрішніми модулями:
− AuthGuard – перевіряє наявність маркера авторизації (JWT);
− AppStorage – відповідає за збереження даних у памʼяті пристрою
(наприклад, стану авторизації);
− ApiService – здійснює запити до сервера через REST API.
Для обміну даними між клієнтом і сервером використовується набір
моделей (Models), які описують структуру переданих і отриманих об’єктів,
зокрема:
− ProfileResponse – дані профілю користувача;
− VisitResponse – інформація про консультації;
− ChangePasswordBody – тіло запиту на зміну пароля;
− JWTUtils – службовий компонент, який використовується для
розшифрування та перевірки маркерів авторизації.
На боці сервера працює REST API, який обробляє всі запити та взаємодіє з
базою даних. У базі зберігаються інформація про користувачів, записи, відгуки,
тести та статті.
Ця діаграма дозволяє побачити, як саме компоненти додатку пов’язані між
собою та як розділено відповідальність між клієнтською, серверною та базовою
частинами системи. Такий поділ дає змогу легше масштабувати додаток,
спрощує підтримку й дозволяє швидко знаходити місця, які потребують змін.

Рисунок 2.4 – Діаграма компонентів

2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Діаграма розгортання (рисунок 2.5) показує, на яких фізичних чи
віртуальних пристроях розміщено компоненти мобільного додатку та серверної
частини, а також, як між ними відбувається обмін даними [32].
Мобільний застосунок встановлюється на Android-пристрій користувача,
який може бути як смартфоном, так і планшетом. Усі дії: авторизація, перегляд
профілів, запис на консультацію, – виконуються через клієнтську частину
додатку. Для зберігання даних авторизації використовується локальне сховище
(AppStorage), доступне лише цьому пристрою.
Обмін даними із сервером відбувається через інтернет за допомогою
HTTPS-запитів у форматі JSON, згідно з принципами REST API. Серверна
частина розгорнута на віддаленому сервері. У серверній логіці реалізовані всі
функції обробки запитів, авторизації, перевірки маркера авторизації та взаємодії
з базою даних.
База даних також розміщена на віддаленому сервері. Вона забезпечує
збереження інформації про користувачів, записи на консультації, відгуки, статті
й тести.
Такий підхід до розгортання дозволяє:
− забезпечити безпеку персональних даних;
− масштабувати систему при зростанні кількості користувачів;
− швидко оновлювати логіку сервера без потреби перевстановлювати
додаток.
Ця архітектура є типовою для сучасних мобільних застосунків і дозволяє
підтримувати злагоджену роботу клієнта й сервера при мінімальних витратах
ресурсів на стороні користувача.

Рисунок 2.5 – Діаграма розгортання

2.5 Моделювання поведінки системи
2.5.1 Діаграма діяльності
Для візуалізації логіки роботи системи були побудовані кілька діаграм
діяльності, кожна з яких описує окрему функціональність, що реалізований у
мобільному застосунку. Діаграми діяльності допомагають послідовно описати
дії користувачів та внутрішню логіку, що відповідає за реалізацію функціоналу.
На основі аналізу сценаріїв використання було виділено для прикладу 4
основних процесів:
− авторизація користувача (рисунок 2.6) – діаграма демонструє
перевірку маркера авторизації в локальному сховищі та, при його
відсутності, введення облікових даних;
− запис пацієнта на консультацію (рисунок 2.7) – діаграма описує
процес від перегляду списку психологів до створення нового запису;
− скасування запису психологом (рисунок 2.8) – демонструється
сценарій, коли спеціаліст змушений скасувати заплановану
консультацію.

Рисунок 2.6 – Діаграма діяльності для авторизації користувача

Рисунок 2.7 – Діаграма діяльності для запису пацієнта на консультацію

Рисунок 2.8 – Діаграма діяльності для скасування запису психологом
2.5.2 Діаграма послідовності
У цьому підрозділі представлено діаграми послідовності, які відображають
логіку обміну повідомленнями між основними компонентами системи під час
виконання важливих функцій мобільного застосунку. Це дозволяє чітко
зрозуміти, у якій послідовності відбуваються взаємодії між користувачем,
клієнтською частиною, сервером та базою даних.
Перша діаграма (рисунок 2.9) ілюструє процес запису пацієнта на
консультацію. Після входу в додаток, пацієнт переглядає список психологів, що
отримується з бази даних через API-сервер. Обравши спеціаліста та відповідний
час, користувач надсилає запит на створення запису, який зберігається в базі
даних. У відповідь система підтверджує успішне створення запису.
Друга діаграма (рисунок 2.10) ілюструє процес залишення відгуку
пацієнтом. Після входу в мобільний застосунок пацієнт обирає психолога та
ініціює перехід до форми залишення відгуку. Після введення тексту та оцінки
користувач надсилає відповідні дані на сервер через авторизований запит. API-
сервер обробляє запит, зберігаючи відгук у базі даних. У відповідь система
надсилає підтвердження успішного додавання відгуку.
Таким чином, діаграми послідовності є важливою частиною моделювання
системи, дозволяючи формалізувати сценарії взаємодії користувачів з додатком
на всіх етапах.

Рисунок 2.9 – Діаграма послідовності для процесу запису пацієнта на
консультацію

Рисунок 2.10 – Діаграма послідовності для процесу залишення відгуку
2.5.3 Діаграма комунікації
Діаграми комунікації дозволяють наочно відобразити процес взаємодії між
об’єктами системи під час виконання основних сценаріїв. Вони фокусуються не
на часовій послідовності, як діаграми послідовності, а саме на структурі обміну
повідомленнями між учасниками комунікації.
У даній роботі було розроблено дві ключові діаграми комунікації:
1. Запис пацієнта на консультацію (рисунок 2.11)
Пацієнт обирає психолога, дату та час консультації. Додаток
надсилає запит на створення запису до сервера, який, у свою чергу,
зберігає відповідну інформацію в базі даних. Після підтвердження,
користувач отримує повідомлення про успішний запис.
2. Додавання відгуку (рисунок 2.12)
Пацієнт обирає психолога, заповнює текстовий відгук і ставить
оцінку. Мобільний застосунок надсилає запит на додавання відгуку
до API-сервера. Сервер обробляє запит, зберігаючи відгук у
відповідній таблиці бази даних. Після успішного збереження система
надсилає підтвердження, і пацієнт отримує повідомлення про
успішне додавання відгуку.

Рисунок 2.11 – Діаграма комунікації для запису пацієнта на консультацію

Рисунок 2.12 – Діаграма комунікації для додавання розкладу психологом

2.5.4 Діаграма скінченного автомату
Діаграми скінченних автоматів є важливим інструментом для
моделювання поведінки системи у відповідь на дії користувача. Вони
дозволяють наочно показати, в яких станах може перебувати система, та як саме
вона реагує на події, що ініціюються в процесі взаємодії. У межах цієї роботи
було створено дві окремі діаграми скінченних автоматів: для користувача з
роллю пацієнта та для користувача з роллю психолога.
Перша діаграма (рисунок 2.13) скінченного автомату описує дії
користувача з роллю психолога. На відміну від пацієнта, психолог не записується
на прийоми, а натомість керує власним профілем, створює графік консультацій,
переглядає записи, залишені пацієнтами, а також знайомиться з відгуками. Така
структура дозволила виокремити основні сценарії роботи для цієї ролі та
відобразити їх у вигляді послідовності станів. Зокрема, було враховано
можливість редагування розкладу, скасування прийомів та оновлення профілю,
що відбувається через відповідні переходи між станами.
У другій діаграмі (рисунок 2.14) відображено поведінку пацієнта, який за
допомогою мобільного застосунку здійснює вхід у систему, шукає психологів,
записується на консультації, переглядає статті та проходить психологічні тести
для самодопомоги. У кожному з цих випадків змінюється поточний стан додатку,
і саме ці переходи були візуалізовані у вигляді скінченного автомату. Кожна дія
призводить до переходу в новий стан, що чітко фіксує логіку роботи застосунку.
Побудова діаграм скінченних автоматів дала змогу не лише впорядкувати
сценарії взаємодії з системою, а й краще зрозуміти її внутрішню логіку. В
подальшому це сприятиме розробці інтуїтивно зрозумілого інтерфейсу, який
відповідатиме очікуванням користувачів кожної з ролей.

Рисунок 2.13 – Діаграма скінченого автомату для психолога

Рисунок 2.14 – Діаграма скінченого автомату для пацієнта
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ

У другому розділі було здійснено практичну реалізацію етапів
проєктування мобільного застосунку для отримання психологічної допомоги.
Було змодельовано предметну область, сформовано функціональні та
нефункціональні вимоги до програмного забезпечення, а також побудовано
UML-діаграми, що відображають архітектуру, логіку взаємодії та поведінку
системи.
На основі аналізу предметної області були визначені ключові сутності:
користувач, психолог, пацієнт, запис на консультацію, профіль, розклад, відгуки,
статті та тести для самодопомоги. Вимоги до системи були розділені на первинні,
детальні, функціональні та нефункціональні, з урахуванням потреб як
користувачів, так і розробників.
За допомогою діаграм класів, компонентів, розгортання, прецедентів,
послідовності, комунікації, діяльності та скінченних автоматів було сформовано
цілісне уявлення про структуру, логіку та основні процеси в межах застосунку.
Окрема увага приділялася ролям пацієнта та психолога, оскільки вони мають
відмінну функціональність.
Виконане моделювання дозволило не лише систематизувати знання про
проєктовану систему, а й створити чітку основу для її подальшої реалізації.
Побудовані діаграми стали ефективним інструментом для візуалізації роботи
застосунку, перевірки коректності логіки взаємодії та прийняття коректних
рішень на наступних етапах розробки.

РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1 Розробка програмного комплексу
3.1.1 Обґрунтування вибору засобів реалізації
У процесі розробки мобільного застосунку для психологічної підтримки
було обрано набір технологій, інструментів та середовищ, які відповідають
вимогам функціональності, продуктивності, масштабованості та зручності
підтримки.
Основною мовою програмування клієнтської частини стала Java, оскільки
вона є стандартом для створення Android-застосунків, підтримується Android
SDK та має велику спільноту [33, 34]. Для розробки інтерфейсу користувача та
логіки взаємодії з користувачем використовувалося середовище Android Studio,
яке надає зручний набір інструментів, емуляторів і засобів налагодження [35].
Для взаємодії з сервером був обраний фреймворк Retrofit, який забезпечує
просту та гнучку роботу з REST API. Він дозволяє реалізовувати HTTP-запити,
обробляти відповіді у форматі JSON та зручно інтегрується з іншими
компонентами програми.
Для відображення зображень у профілях психологів застосовувалась
бібліотека Picasso, яка автоматично зберігає зображення в пам’яті пристрою та
оптимізує їх завантаження. Також для зручного виведення повідомлень про дії
користувача (успішний запис, помилки тощо) було використано бібліотеку
Toasty.
У якості засобу збереження локального стану авторизації (тобто маркера
доступу) використовувалась технологія SharedPreferences, що дозволяє зберігати
невеликі об’єми даних між сесіями користувача.
Серверна частина була реалізована на основі фреймворку PHP Lumen, який
забезпечує швидку обробку REST-запитів і підтримує авторизацію через JWT
(веб-маркер доступу). Такий підхід дозволяє ефективно перевіряти права
доступу без необхідності постійної перевірки в базі даних. Сервер взаємодіє з
MySQL – реляційною базою даних, що використовується для зберігання
інформації про користувачів, записи на консультації, відгуки, тести, статті тощо.
Таким чином, вибрані засоби реалізації дозволили побудувати стабільну,
масштабовану та зручну систему, яка відповідає сучасним вимогам до мобільних
додатків у сфері психічного здоров’я.
3.1.2 Опис структурної (функціональної) схеми
Розроблений мобільний застосунок має клієнт-серверну архітектуру, де
логіка взаємодії між компонентами побудована за принципом REST API.
Структурна схема системи демонструє основні модулі додатку, взаємозв’язки
між ними та обмін даними.
Користувач взаємодіє з додатком через інтерфейс Android-застосунку,
реалізованого на мові Java. Усі дії, пов’язані з отриманням чи передачею даних
(авторизація, перегляд профілів, запис на консультацію тощо), ініціюють HTTP-
запити до серверної частини системи.
Сервер, створений на основі фреймворку PHP Lumen, обробляє запити
клієнта, виконує перевірку маркеру авторизації (JWT) та взаємодіє з базою даних
MySQL для отримання, збереження чи оновлення інформації. JWT-маркер
використовується для того, щоб кожен запит мав підтвердження автентичності
користувача без необхідності повторної авторизації.
База даних містить основні таблиці: користувачі, профілі, записи на
консультації, відгуки, статті, тести, розклади тощо. Клієнтська частина не має
прямого доступу до бази, що підвищує рівень безпеки.
У структурній схемі (рисунок 3.1) умовно виділяються наступні
компоненти:
− користувач (пацієнт або психолог) – ініціатор дій у системі;
− мобільний додаток – інтерфейсна частина, яка взаємодіє з
користувачем та формує запити;
− REST API-сервер – обробляє запити клієнта, перевіряє автентичність
і направляє запити до бази даних;
− база даних – зберігає всю інформацію, необхідну для роботи
застосунку.
Обмін даними між клієнтом і сервером здійснюється у форматі JSON через
захищене HTTPS-з'єднання, що гарантує безпеку переданих даних [36].
Така архітектура дозволяє гнучко розширювати функціонал додатку,
підтримувати масштабованість і забезпечувати зручну підтримку та оновлення
системи.

Рисунок 3.1 – Функціональна схема
3.1.3 Опис логічної схеми системи
Логічна схема (рисунок 3.2) системи описує основні компоненти
програмного забезпечення та зв’язки між ними з точки зору обробки даних і
логіки взаємодії. У розробленому мобільному додатку для психологічної
допомоги система реалізована за принципом клієнт-серверної архітектури, де
Android-додаток виступає клієнтом, а сервер – постачальником даних та логіки
обробки запитів.
Основні логічні компоненти системи:
1 Мобільний клієнт (Android-додаток):
− відповідає за взаємодію з користувачем (пацієнтом або
психологом);
− надсилає запити до серверу через REST API;
− зберігає маркер авторизації у SharedPreferences;
− візуалізує дані, отримані від API, та дозволяє
створювати/редагувати інформацію (записи, профілі, відгуки,
результати тестів).
2 Серверна частина (PHP Lumen):
− реалізує REST API, до якого надходять HTTP-запити;
− перевіряє маркер авторизації (JWT) при запиті;
− виконує перевірку даних, обробку помилок, фільтрацію тощо;
− взаємодіє з базою даних, зчитуючи та записуючи потрібну
інформацію.
3 База даних (MySQL):
− містить таблиці користувачів, профілів, записів на
консультацію, розкладу, відгуків, тестів, статей тощо;
− серверна частина звертається до БД за допомогою SQL-
запитів.
Взаємозв’язок компонентів:
− користувач взаємодіє з інтерфейсом мобільного застосунку;
− при виконанні дій (наприклад, авторизація, створення запису на
консультацію) додаток надсилає відповідний HTTP-запит у форматі
JSON до REST API;
− сервер обробляє запит, перевіряє авторизацію, взаємодіє з БД і
формує відповідь;
− відповідь у форматі JSON надходить клієнту, де вона обробляється і
відображається користувачеві.

Рисунок 3.2 – Логічна схема
3.1.4 Розробка бази даних
Для зберігання даних цього проєкту було розроблено реляційну базу даних
MySQL, яка забезпечує збереження, пошук, фільтрацію й обробку інформації,
пов’язаної з користувачами, записами на консультації, тестуванням, відгуками
та статтями [37]. Структура бази даних була створена з урахуванням нормалізації
до третьої нормальної форми (3НФ), що дозволило усунути надмірність даних і
забезпечити логічну цілісність.
Таблиці бази даних:
1 users
Містить інформацію про зареєстрованих користувачів (пацієнтів і
психологів). Поле account_type визначає тип користувача.
Первинний ключ: id
Поля: id (bigint unsigned); email (varchar(255)); password
(varchar(255)); account_type (enum('patient','psychologist')); details
(json); created_at (timestamp); updated_at (timestamp);
password_reset_token (mediumtext); token_expiry (timestamp);
profile_picture (longtext); activeCode (char(150))
2 appointments
Зберігає записи на консультації між пацієнтом і психологом.
Первинний ключ: id
Поля: id (bigint unsigned); patient_id (bigint unsigned);
psychologist_id (bigint unsigned); appointment_date (date);
appointment_time (time); cancellation_time (timestamp); created_at
(timestamp); updated_at (timestamp)
3 opinions
Містить відгуки пацієнтів про психологів.
Первинний ключ: id
Поля: id (bigint unsigned); user_id (bigint unsigned); psychologist_id
(bigint unsigned); stars (tinyint); content (text); created_at
(timestamp); updated_at (timestamp)
4 articles
Містить текстові матеріали для самодопомоги.
Первинний ключ: id
Поля: id (int); title (varchar(255)); content (text)
5 tests
Містить інформацію про психологічні тести.
Первинний ключ: id
Поля: id (int); name (varchar(255)); description (text)
6 questions
Питання, що входять до тестів.
Первинний ключ: id
Поля: id (int); test_id (int); question (text)
Зовнішній ключ: test_id → tests(id)
7 answers
Містить варіанти відповідей до питань тестів.
Первинний ключ: id
Поля: id (int); question_id (int); answer_text (text); is_correct
(tinyint(1))
8 migrations
Службова таблиця фреймворку для зберігання інформації про
виконані міграції.
Первинний ключ: id
Поля: id (int); migration (varchar(255)); batch (int)
Зв’язки між таблицями (основні):
− users.id ← appointments.patient_id
− users.id ← appointments.psychologist_id
− users.id ← opinions.user_id
− users.id ← opinions.psychologist_id
− tests.id ← questions.test_id
− questions.id ← answers.question_id

Рисунок 3.3 – Структура бази даних

3.1.5 Розробка інтерфейсу користувача
Інтерфейс користувача відіграє ключову роль у забезпеченні зручної,
зрозумілої та привабливої взаємодії з мобільним додатком [38]. Візуальне
оформлення, структура екранів та інтуїтивність навігації безпосередньо
впливають на користувацький досвід, особливо в сфері психологічної допомоги,
де важливо створити відчуття комфорту, довіри й доступності.
Додаток був реалізований у середовищі Android Studio із застосуванням
інструментів View Binding, ConstraintLayout та кастомних компонентів
відповідно до сучасних принципів UX/UI дизайну для Android-застосунків.
Після встановлення додатку користувач потрапляє на екран входу
(рисунок 3.4), де йому пропонується авторизуватись або створити новий
обліковий запис. Інтерфейс авторизації реалізовано у вигляді простої форми з
полями для введення електронної пошти та пароля.

Рисунок 3.4 – Сторінка авторизації в додатку

У випадку, якщо користувач не має облікового запису, він натискає кнопку
«Зареєструватися», після чого переходить до відповідної форми реєстрації. Після
заповнення полів і надсилання форми, на електронну пошту надсилається лист із
кодом активації. Перейшовши за посиланням з листа, користувач бачить
повідомлення про успішне підтвердження облікового запису. У випадку, якщо
код вже був використаний або недійсний, відображається відповідне
повідомлення про помилку. Даний процес зображено на рисунках 3.5-3.8.

Рисунок 3.5 – Сторінка реєстрації

Рисунок 3.6 – Лист на пошті

Рисунок 3.7 – Сторінка підтвердження реєстрації

Рисунок 3.8 – Сторінка, якщо код вже не дйсний

У додатку передбачена можливість відновлення пароля у випадку його
втрати. Для цього на екрані авторизації розміщено кнопку «Забули пароль?»,
після натискання на яку відкривається модальне вікно (рисунок 3.9). У цьому
вікні користувач вводить свою електронну пошту, новий пароль та підтверджує
його повторним введенням.
Після заповнення форми та натискання кнопки «Змінити пароль», на
електронну адресу надсилається лист (рисунок 3.10) із посиланням для
підтвердження зміни пароля. У тілі листа пояснюється, що запит було
ініційовано користувачем, і вказано, що посилання дійсне протягом 1 години.
У випадку, якщо користувач переходить за посиланням у межах терміну
дії, на сторінці відображається повідомлення «Ваш пароль було успішно
змінено», після чого він може авторизуватися з новими даними (рисунок 3.11).
Якщо ж посилання застаріло або вже було використано, система виводить
відповідне повідомлення (рисунок 3.12).

Рисунок 3.9 – Вікно зміни паролю при авторизації

Рисунок 3.10 – Лист зміни паролю

Рисунок 3.11 – Сторінка підтвердження зміни паролю

Рисунок 3.12 – Сторінка, якщо код не дійсний або використаний вже

Після авторизації користувач потрапляє до головного інтерфейсу додатку,
функціональність якого залежить від обраної ролі. Для пацієнтів реалізовано
окрему навігаційну структуру з доступом до психологів, записів, матеріалів для
самодопомоги, особистого кабінету та інструментів зворотного зв’язку. Дизайн
побудовано таким чином, щоб забезпечити простоту використання, швидкий
доступ до потрібної інформації та послуг, а також інтуїтивну взаємодію на
кожному етапі.
Інтерфейс для пацієнта містить:
1 Список психологів (рисунок 3.13)
Користувач бачить картки спеціалістів зі зображенням, ім’ям,
досвідом, ціною, кількістю відгуків та короткою інформацією про
напрямки роботи. Передбачено фільтр для пошуку за форматом
консультацій (онлайн/офлайн) та діапазоном ціни.

Рисунок 3.13 – Пошук психолога пацієнтом та фільтри

2 Повна картка психолога (рисунок 3.14)
Натиснувши на картку, відкривається діалогове вікно з детальною
інформацією: повний опис психолога та досвіду, інформація про
мови, формат роботи, вартість, спеціалізацію,перелік відгуків
пацієнтів.
У нижній частині вікна розташована кнопка “Записатися”.

Рисунок 3.14 – Повна картка психолога

3 Форма запису на консультацію (рисунок 3.15)
Інтерфейс реалізовано у вигляді календаря з можливістю вибору дати
та години. Перед бронюванням користувач підтверджує згоду з
умовами договору, після чого доступна кнопка “Зарезервувати”.

Рисунок 3.15 – Форма запису на консультацію

4 Розділ «Мої записи» (рисунок 3.16)
Тут користувач бачить список своїх бронювань. Кожен запис
відображає ім’я психолога, фото, дату консультації та статус
(активний або скасований). Доступна функція скасування. При
натисканні на запис, відображаються контакти психолога для
подальшого зв’язку.

Рисунок 3.16 – Форма записів

5 Залишення відгуку (рисунок 3.17)
Через окреме вікно користувач може поставити оцінку (від 1 до 5
зірок) та написати текстовий відгук. Всі відгуки зберігаються і
публікуються на сторінці психолога.

Рисунок 3.17 – Форма залишення відгуку

6 Особистий кабінет пацієнта (рисунок 3.18)
Містить поля для перегляду та редагування інформації: ім’я,
прізвище, email, дата народження. Реалізована можливість зміни
пароля (рисунок 3.19) та виходу з облікового запису. Користувач
також може змінити фото профілю.

Рисунок 3.18 – Сторінка особистого кабінету

Рисунок 3.19 – Зміна паролю в особистому кабінеті
7 Розділ «Самодопомога» (рисунок 3.20-3.21)
Складається з двох блоків:
− список статей, які розміщує адміністратор. Кожна стаття має
назву та зміст;
− список тестів, які пацієнт може пройти.

Рисунок 3.20 – Розділ «Самодопомога»

Рисунок 3.21 – Вигляд статей та тестів

Управління статтями та тестами здійснюється через окремий веб-сайт
(рисунок 3.22-3.23). Для тестів є панель, що відображає список уже
опублікованих матеріалів. Для кожної статті виводиться тема та короткий зміст.
Поруч із кожною публікацією передбачено кнопки «Оновити» та «Видалити»,
що дозволяють редагувати або повністю вилучити матеріал. Для створення нової
статті використовується кнопка «Нова стаття», яка відкриває відповідну форму з
полями «Назва статті» та «Контент статті» (рисунок 3.24).
Аналогічно реалізовано інтерфейс для додавання та редагування тестів. На
головній сторінці блоку тестування адміністратор бачить список наявних тестів
із коротким описом формату. При переході до редагування відкривається форма
з назвою тесту, описом та переліком запитань. Кожне запитання містить варіанти
відповідей, з яких можна обрати правильну за допомогою перемикача. Також
передбачені кнопки «Додати питання», «Видалити питання» та «Зберегти» зміни
(рисунок 3.25-3.26).
Уся інформація, додана через веб-інтерфейс, зберігається в базі даних та
автоматично відображається в мобільному застосунку пацієнтів у відповідному
розділі. Таким чином, адміністратор має зручний інструмент для постійного
оновлення освітніх і діагностичних матеріалів, що забезпечує актуальність і
корисність контенту в межах платформи.

Рисунок 3.22 – Сторінка з статтями та тестами

Рисунок 3.23 – Сторінка з статтями та тестами

Рисунок 3.24 – Редагування статей

Рисунок 3.25 – Редагування тестів

Рисунок 3.26 – Редагування тестів

Окрім пацієнтів, у системі MentalAid передбачено роль психолога, для якої
реалізовано окремий інтерфейс із відповідною функціональністю. Після
авторизації користувач із типом облікового запису «психолог» отримує доступ
до особистого кабінету, де може керувати своїми записами, переглядати
інформацію про пацієнтів, а також редагувати власні дані. Нижче описано
основні елементи інтерфейсу психолога та реалізовану взаємодію в межах його
функціоналу.
Інтерфейс для психолога
1 Особистий кабінет психолога (рисунок 3.27)
Містить розширену форму редагування інформації: контактні дані,
вік, досвід, мови, вартість сеансу, спеціалізацію, напрямки роботи,
місто, формат (онлайн/офлайн), опис про себе. Також передбачено
зміну фотографії та пароля (вигляд як і в пацієнта).

Рисунок 3.27 – Особистий кабінет психолога (1 частина)

Рисунок 3.27 – Особистий кабінет психолога (2 частина)

2 Список записів
Тут користувач бачить список записів. Кожен з них відображає ім’я
пацієта, фото, дату консультації та статус (активний або скасований).
Доступна функція скасування. При натисканні на запис,
відображаються контакти клієнта для подальшого зв’язку. Інтерфейс
аналогічний інтерфейсу в пацієнта.
Також в додатку передбачена зміна стилю інтерфейсу, якщо в
налаштуваннях пристрою обрана інша тема інтерфейсу [39]. Приклад цього
показано на рисунку 3.28.

Рисунок 3.28 – Дизайн додатку при виборі темного режиму в
налаштуваннях пристрою

3.1.6 Опис розробки програмних компонентів
У процесі реалізації мобільного додатку для психологічної підтримки було
створено набір програмних компонентів, які взаємодіють між собою у межах
клієнт-серверної архітектури. Усі компоненти умовно поділяються на клієнтську
(Android) та серверну частину. Нижче наведено опис ключових клієнтських
програмних компонентів:
1 MainActivity.java
Це основна активність, з якої починається робота додатку. Вона
відповідає за ініціалізацію теми, кольорової гами інтерфейсу, а також
виконує перевірку токена авторизації. У разі успішної авторизації
користувача система перенаправляє його до відповідного інтерфейсу
(пацієнта або психолога).
2 MyApplication.java
Клас, що наслідує Application, використовується для глобальних
налаштувань, зокрема для ініціалізації бібліотеки Toasty з
нестандартним розміщенням повідомлень на екрані.
3 AppStorage.java
Singleton-компонент, що реалізує механізм збереження та отримання
токена авторизації (JWT) через SharedPreferences. Також зберігає
вибраний час і день для запису на консультацію.
4 AuthGuard.java
Допоміжний клас, який відповідає за перевірку дійсності токена JWT. У
разі, якщо токен недійсний або завершився його строк, користувача
перенаправляє на екран авторизації.
5 PatientMainActivity.java
Це головна активність для користувача з роллю "пацієнт". Вона реалізує
навігацію між фрагментами, які відповідають за функціонал
користувача: перегляд списку психологів, записів, особистого кабінету,
тестів і статей.
6 PatientAccountFragment.java
Фрагмент особистого кабінету пацієнта. Містить форму для
редагування даних профілю (ім’я, прізвище, дата народження, email), а
також кнопки для виходу з облікового запису та зміни пароля. Дані
надсилаються на сервер через API, і користувач отримує зворотній
зв'язок у вигляді повідомлень Toasty.
7 PatientChangePasswordFragment.java
Діалоговий фрагмент, що відповідає за зміну пароля. Забезпечує
валідацію введених даних (перевірка на відповідність і довжину
паролів) та надсилає запит на зміну пароля через API.
8 PatientListOfPsychologistsFragment.java
Фрагмент, який відображає список психологів з можливістю фільтрації
за ціною та форматом консультацій (онлайн/офлайн). Використовує
RecyclerView для відображення списку та адаптер PsychologistAdapter
для заповнення даних.
9 PatientPsychologistFilterDialog.java
Діалогове вікно фільтрації психологів. Користувач може задати
мінімальну та максимальну вартість консультації, а також обрати
формат (онлайн/офлайн/обидва). Дані фільтрації передаються до
основного фрагмента через механізм Fragment Result API.
10 LabelValueItem.java та LabelValueView.java
Кастомні компоненти інтерфейсу, що використовуються для
відображення пар "мітка–значення" у профілях користувачів або
інформаційних блоках. Динамічно формують інтерфейс на основі
переданих даних.
11 ItemSpacingDecoration.java
Допоміжний клас для візуального оформлення списків у RecyclerView,
що додає відступи між елементами для покращення читабельності
інтерфейсу.
У межах серверної частини було створено набір компонентів, які
реалізують логіку обробки запитів, авторизацію, роботу з базою даних та
маршрутизацію. Сервер обробляє запити клієнта, перевіряє права доступу за
допомогою JWT, взаємодіє з MySQL і повертає відповіді у форматі JSON.
Основні компоненти:
1 routes/web.php
Файл, у якому описано всі маршрути REST API. Кожен маршрут
відповідає певному методу контролера. Тут визначено публічні шляхи
(реєстрація, авторизація, скидання пароля) та захищені (отримання
профілю, запис на консультацію, робота з відгуками тощо).
2 AuthController.php
Контролер, що відповідає за реєстрацію та авторизацію користувачів.
Під час логіну створює JWT-токен із зашифрованими даними
користувача. Забезпечує валідацію email, паролів, ролей, а також
надсилає листи з кодом активації.
3 UserController.php
Реалізує логіку перегляду та оновлення профілю. Дає змогу змінювати
особисті дані, завантажувати фото профілю, змінювати пароль, а також
надсилати листи зі скиданням пароля. Профілі зберігаються у вигляді
JSON-структур у БД.
4 PatientController.php
Контролер, який надає пацієнту доступ до списку психологів, дозволяє
здійснювати запис на консультацію, переглядати майбутні візити, а
також залишати відгуки. Реалізує перевірку зайнятості часу, формат
запису та скасування візитів.
5 PsychologistController.php
Надає психологу можливість переглядати майбутні консультації та
отримувати список вільних часових слотів на 30 днів вперед. Слоти
розраховуються динамічно з урахуванням уже запланованих візитів.
6 User.php (модель)
Модель, що описує таблицю користувачів. Визначає ролі (patient,
psychologist), зв’язки з записами (appointments) та відгуками. Також
містить функції для доступу до JSON-профілю та перевірки активності
акаунта.
7 Appointment.php (модель)
Модель для роботи з таблицею записів на консультації. Описує зв’язки
між пацієнтом і психологом, зберігає дату, час, статус запису
(активний/скасований).
8 Opinion.php (модель)
Модель для зберігання відгуків пацієнтів. Містить текст коментаря,
рейтинг (1–5 зірок), дату публікації та зв’язки з відповідними
користувачами.
9 AuthenticateJWT.php (middleware)
Посередник, який перевіряє наявність та дійсність JWT-токена в
заголовку запиту. Розшифровує токен, перевіряє тип користувача та
прикріплює його до поточного запиту. У разі помилки повертає
відповідь з кодом 401.
10 JWT (токени доступу)
Авторизація в системі реалізована через бібліотеку firebase/php-jwt.
Токени містять user_id, account_type та термін дії (5 місяців) [40]. Усі
запити до захищених маршрутів мають включати токен у заголовку
Authorization.
11 Обробка фото профілю
Фото завантажується у форматі base64, стискається та обрізається до
квадратного формату 700x700. Зберігається у базі даних як шифрований
рядок. При запиті автоматично декодується і повертається в API.
12 Обробка помилок і валідація
Усі контролери виконують перевірку введених даних (email, паролі,
формат часу тощо). У разі помилки повертається відповідь з
повідомленням та кодом помилки (422, 401, 404). Успішні запити
повертають 200 OK або 201 Created.
3.2 Тестування системи
Тестування є одним з найважливіших етапів життєвого циклу розробки
програмного забезпечення. Його метою є виявлення дефектів, перевірка
функціональності, надійності, сумісності та відповідності реалізованої системи
заданим вимогам. Тестування розробленого мобільного додатку охоплювало як
клієнтську, так і серверну частину, реалізовану на основі PHP-фреймворку
Lumen з використанням JWT-авторизації та REST API.
Об’єктом тестування виступала інформаційна система, що включає
мобільний застосунок для пацієнтів і психологів, серверну частину з обробкою
даних та авторизацією, а також адмін-панель для керування розділом
«Самодопомога». Метою тестування було підтвердження правильності роботи
системи, її стабільності, відсутності критичних помилок та відповідності
функціональних можливостей технічному завданню.
У межах проєкту було застосовано ручне тестування без використання
автоматизованих інструментів. Під час тестування перевірялась коректність
роботи окремих модулів (авторизації, реєстрації, форми запису, додавання
відгуку, тощо), а також взаємодія між ними. Наприклад, після додавання відгуку
система коректно оновлювала профіль психолога, а після скасування запису
відображався відповідний статус. Було змодельовано повний цикл користувача
– від реєстрації до перегляду результатів проходження тесту в розділі
«Самодопомога».
На заключному етапі було проведено приймальне тестування, під час якого
оцінювалася відповідність системи заявленим функціональним вимогам, її
зручність та стабільність. Була перевірена логіка сценаріїв, зокрема запис на
консультацію, керування особистим кабінетом, взаємодію з психологами та
роботу матеріалів для самодопомоги.
Нижче наведено зведену таблицю виконаних тестів:

Таблиця 1
Результати тестування
Тестовий Очікуваний
№ Вхідні дані Результат Статус
сценарій результат
Авторизація Успішний вхід Вхід
1 Email, пароль Пройдено
користувача до додатку виконано
Продовження таблиці 1
Невірна Email, хибний Повідомлення Повідомленн
2 Пройдено
авторизація пароль про помилку я виведено
Реєстрація Створення
Ім’я, Email, Реєстрація
3 нового облікового Пройдено
пароль успішна
користувача запису
Старий
Пароль
4 Зміна пароля пароль, новий Пароль змінено Пройдено
оновлено
пароль
Додавання Відгук Відгук
5 Текст, оцінка Пройдено
відгуку збережено додано
Створення Обраний Запис Запис
6 Пройдено
запису психолог, час збережено створено
Скасування Обраний Статус: Статус
7 Пройдено
запису запис скасовано оновлено
Відображен Список статей Статті
8 — Пройдено
ня статей завантажено показано
Проходженн Обраний тест, Результат Працює
9 Пройдено
я тесту відповіді показано коректно
Відкрито
Перегляд Натиснення
розгорнуту Дані
10 профілю на картку Пройдено
інформацію про завантажено
психолога психолога
психолога
Обрані
Пошук Виведено
фільтри Фільтрація
11 психолога за відфільтровани Пройдено
(онлайн, ціна працює
фільтром й список
тощо)

Продовження таблиці 1
Лист на пошту з
Відновлення Email Отримано
12 посиланням для Пройдено
пароля користувача лист
відновлення
Вихід з Натиснення
Повернення на Користувача
13 облікового кнопки Пройдено
екран входу розлогінено
запису “Вийти”
Додавання
Обране Фото оновлено
14 та зміна Фото змінено Пройдено
зображення в профілі
аватару
Недопустим Порожнє або Відображення
Повідомленн
15 е поле при некоректне повідомлення Пройдено
я виведено
реєстрації значення про помилку
Відмова в
Повторна
Існуючий реєстрації, Помилку
16 реєстрація з Пройдено
email повідомлення показано
тим же email
про дубль
Некоректни
Відображення Валідація
17 й формат email без @ Пройдено
помилки спрацювала
email
Перегляд Натиснення Відображено
Інформацію
18 особистої на особистий особисті дані Пройдено
показано
інформації кабінет користувача
Редаговані
Оновлення
ім’я, email, Зміни Інформацію
19 даних Пройдено
дата збережено оновлено
профілю
народження

Продовження таблиці 1
Статтю
Додавання Назва, текст збережено та Статтю
20 Пройдено
статті статті показано у додано
списку
Новий текст
Редагування Зміни Статтю
21 для наявної Пройдено
статті збережено оновлено
статті
Статтю
Видалення Статтю
22 Обрана стаття видалено зі Пройдено
статті видалено
списку
Тест збережено
Додавання Назва, список
23 та Тест додано Пройдено
тесту питань
відображається
Зміни в
Редагування Зміни
24 питаннях/назв Тест оновлено Пройдено
тесту застосовано
і
Тест
Видалення
25 Обраний тест Тест видалено видалено зі Пройдено
тесту
списку

ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ

У третьому розділі було детально описано процес розробки та тестування
мобільного застосунку для отримання психологічної допомоги. Зокрема,
обґрунтовано вибір технологій, інструментів і середовищ розробки, що
забезпечили ефективну реалізацію функціоналу додатку відповідно до сучасних
вимог до мобільного програмного забезпечення.
Було представлено функціональну та логічну схеми системи, описано
структуру бази даних та призначення основних таблиць, що забезпечують
зберігання інформації про користувачів, консультації, відгуки, статті та тести.
Детально розглянуто інтерфейс користувача, включаючи всі ключові елементи
як для пацієнтів, так і для психологів, а також механізми авторизації, реєстрації,
зміни пароля й інші взаємодії з системою.
Окрему увагу приділено опису реалізованих програмних компонентів
клієнтської та серверної частини. Зокрема, показано, як організовано обробку
HTTP-запитів, авторизацію через JWT, зберігання даних у MySQL, а також
взаємодію з REST API.
Завершальним етапом було тестування системи, яке охопило всі основні
сценарії використання додатку. Проведене ручне тестування підтвердило
стабільність роботи, коректність реалізації заявленого функціоналу та
відповідність системи поставленим вимогам. Всі протестовані сценарії
завершились успішно, що свідчить про високу якість програмного продукту та
готовність до подальшого використання.

ВИСНОВКИ

У межах виконання кваліфікаційної роботи було розроблено
повнофункціональний мобільний застосунок для надання психологічної
підтримки, що враховує потреби двох категорій користувачів. Система
реалізована за принципом клієнт-серверної архітектури з використанням
сучасних технологій: Java для Android-застосунку, PHP Lumen для серверної
частини, MySQL для зберігання даних, а також різних бібліотек.
У першому розділі було проведено детальний аналіз сучасних рішень у
галузі мобільних додатків для психологічної допомоги, визначено сильні та
слабкі сторони існуючих аналогів (Rozmova, Mindly, Talkspace, Svitlo), що
дозволило сформувати вимоги до власного продукту.
Другий розділ містив етапи моделювання предметної області, формування
вимог до ПЗ, побудову UML-діаграм (класів, прецедентів, компонентів,
розгортання тощо), що дало змогу сформувати цілісну архітектуру майбутнього
програмного продукту.
У третьому розділі було реалізовано сам застосунок: створено базу даних,
реалізовано інтерфейс користувача з урахуванням UX/UI-принципів, виконано
зв’язок між клієнтом і сервером, розроблено функціонал для авторизації,
реєстрації, запису на консультації, редагування профілю, перегляду статей і
проходження тестів. Особливу увагу приділено безпеці (використання JWT),
зручності збереження сесій (SharedPreferences), а також адаптивності дизайну
(врахування темної/світлої теми системи).
Проведене тестування показало стабільну роботу застосунку, відповідність
заявленим вимогам і високий рівень зручності у використанні.
Результати цієї роботи мають практичне значення, оскільки запропоноване
рішення може бути використане як повноцінна платформа для пошуку
психологічної допомоги, що є особливо актуальним у сучасних умовах, а також
легко допрацьовуватись та масштабуватись далі для підтримки актуальності.

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Всесвітня організація охорони здоров’я. Психічне здоров’я [Електронний
ресурс]. – 2021. – Режим доступу: https://www.who.int/news-room/fact-
sheets/detail/mental-health-strengthening-our-response
2. UNN. About 300,000 Ukrainians filed mental health complaints with primary
care doctors in the first seven months of 2024 [Електронний ресурс]. –
UNN.ua, 2024. – Режим доступу: https://unn.ua/en/news/300-thousand-
ukrainians-consulted-doctors-for-mental-health-problems-what-they-complain-
about-most-often
3. Patel, V., Saxena, S., Lund, C. та ін. The Lancet Commission on global mental
health and sustainable development // The Lancet. – 2018. – Vol. 392, №10157.
– P. 1553–1598. – DOI: https://doi.org/10.1016/S0140-6736(18)31612-X
4. Bakker, D., Kazantzis, N., Rickwood, D., & Rickard, N. (2016). Mental health
smartphone apps: Review and evidence-based recommendations for future
developments. JMIR Mental Health, 3(1), e7.
https://doi.org/10.2196/mental.4984
5. Torous, J., Roberts, L. W. The Ethical Use of Mobile Health Technology in
Clinical Psychiatry // Journal of Nervous and Mental Disease. – 2017. – Vol.
205(1). – P. 4–8. – DOI: https://doi.org/10.1097/NMD.0000000000000666
6. Booch, G. Object-Oriented Analysis and Design with Applications. – 3rd ed. –
Addison-Wesley, 2007.
7. Fowler, M. UML Distilled: A Brief Guide to the Standard Object Modeling
Language. – 3rd ed. – Addison-Wesley, 2003.
8. Hassenzahl, M. User experience (UX): Towards an experiential perspective on
product quality // Proc. of the 20th Conf. on l'Interaction Homme-Machine. –
2008. – P. 11–15.
9. Firth, J., Torous, J., Nicholas, J., Carney, R., Rosenbaum, S., Sarris, J. The
efficacy of smartphone-based mental health interventions // World Psychiatry. –
2017. – Vol. 16(3). – P. 287–298. – DOI: https://doi.org/10.1002/wps.20472
10. Klasnja, P., & Pratt, W. (2012). Healthcare in the pocket: Mapping the space of
mobile-phone health interventions. Journal of Biomedical Informatics, 45(1),
184–198.
11. Square Inc. Retrofit Documentation [Електронний ресурс]. – 2022. – Режим
доступу: https://square.github.io/retrofit/
12. Square Inc. Picasso: Image Loading Library for Android [Електронний
ресурс]. – 2021. – Режим доступу: https://square.github.io/picasso/
13. GrenderG. Toasty GitHub Repository [Електронний ресурс]. – 2022. – Режим
доступу: https://github.com/GrenderG/Toasty
14. Google Developers. View Binding [Електронний ресурс]. – 2020. – Режим
доступу: https://developer.android.com/topic/libraries/view-binding
15. Android Developers. Data Storage Using SharedPreferences [Електронний
ресурс]. – 2021. – Режим доступу:
https://developer.android.com/training/data-storage/shared-preferences
16. Jones, M., Bradley, J., Sakimura, N. JSON Web Token (JWT) // RFC 7519. –
Internet Engineering Task Force, 2015.
17. Nielsen, J. Ten Usability Heuristics [Електронний ресурс]. – Nielsen Norman
Group, 2005. – Режим доступу: https://www.nngroup.com/articles/ten-
usability-heuristics/
18. Dubois, P. MySQL. – 5th ed. – Addison-Wesley Professional, 2008.
19. Freeman, E., Robson, E., Bates, B., & Sierra, K. (2020). Head First Design
Patterns: Building Extensible and Maintainable Object-Oriented Software (2nd
ed.). O’Reilly Media.
20. Fielding, R. T. Architectural Styles and the Design of Network-based Software
Architectures: Doctoral dissertation. – University of California, Irvine, 2000.
21. Sarkar, S. et al. (2018). Comparative analysis of PHP frameworks for web
applications. Int. J. Web & Grid Services, 14(4), 367–386.
22. Kumar, A., & Singh, D. (2021). Comparative analysis of PHP frameworks for
RESTful API development. International Journal of Advanced Research in
Computer Science, 12(4), 45–50.
23. Rozmova. Про додаток [Електронний ресурс]. – 2023. – Режим доступу:
https://rozmova.app
24. Mindly. Про платформу [Електронний ресурс]. – 2023. – Режим доступу:
https://mindly.space
25. Talkspace. Clinical Efficacy and Outcomes Report [Електронний ресурс]. –
2022. – Режим доступу: https://www.talkspace.com
26. Svitlo. Психологічна підтримка онлайн [Електронний ресурс]. – 2023. –
Режим доступу: https://svitloapp.com.ua
27. Pressman, R. S., Maxim, B. R. Software Engineering: A Practitioner’s Approach.
– 8th ed. – McGraw-Hill, 2014.
28. Sommerville, I. Software Engineering. – 9th ed. – Addison-Wesley, 2010.
29. Pohl, K., & Rupp, C. (2015). Requirements Engineering Fundamentals: A Study
Guide for the Certified Professional for Requirements Engineering Exam -
Foundation Level – IREB compliant. Rocky Nook.
30. European Union. General Data Protection Regulation (GDPR) [Електронний
ресурс]. – 2016. – Режим доступу: https://eur-
lex.europa.eu/eli/reg/2016/679/oj
31. Richards, M., & Ford, N. (2020). Fundamentals of Software Architecture: An
Engineering Approach. O’Reilly Media.
32. Tanenbaum, A. S., Steen, M. V. Distributed Systems: Principles and Paradigms.
– 2nd ed. – Pearson Prentice Hall, 2007.
33. Horstmann, C. S. Core Java Volume I–Fundamentals. – 10th ed. – Pearson, 2016.
34. Sillars, M. Professional Android. – 4th ed. – Wrox, 2018.
35. Meier, R., Lake, B. The Android Developer's Cookbook. – 2nd ed. – Addison-
Wesley, 2020.
36. Rescorla, E. HTTP Over TLS // RFC 2818. – Internet Engineering Task Force,
2000.
37. Date, C. J. An Introduction to Database Systems. – 8th ed. – Pearson Education,
2003.
38. Tuch, A. N., Roth, S. P., Hornbæk, K., Opwis, K., Bargas-Avila, J. A. The Role
of Visual Aesthetics in User Experience // Human–Computer Interaction. –
2012. – Vol. 27(1). – P. 1–23.
39. Android Developers. Dark theme [Електронний ресурс]. – 2023. – Режим
доступу: https://developer.android.com/guide/topics/ui/look-and-
feel/darktheme
40. Hardt, D. The OAuth 2.0 Authorization Framework // RFC 6749. – Internet
Engineering Task Force, 2012.

Репозиторій ЧДТУ