WEB-застосунок "PROFTIME" ДЛЯ УПРАВЛІННЯ ЧАСОМ ТА СПРАВАМИ

Чепурний, Іван Сергійович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9057
Title:	WEB-застосунок "PROFTIME" ДЛЯ УПРАВЛІННЯ ЧАСОМ ТА СПРАВАМИ
Authors:	Метелап, Володимир Володимирович Чепурний, Іван Сергійович
Keywords:	TIME-MANAGEMENT;TODO;GTD;KAIZEN;SMART;POMODORO;REACT;REACT ROUTER;VITE;TAILWIND CSS;EXPRESS;NODE.JS;POSTGRESQL;SEQUELIZE;JWT;CRUD;WEB-ЗAСТOСУНOК;TIME-MANAGEMENT;TODO;GTD;KAIZEN;SMART;POMODORO;REACT;REACT ROUTER;VITE;TAILWIND CSS;EXPRESS;NODE.JS;POSTGRESQL;SEQUELIZE;JWT;CRUD;WEB APPLICATION
Issue Date:	13-Jun-2025
Abstract:	АНОТАЦІЯ Кваліфікаційна робота бакалавра Чепурного Івана Сергійовича на тему «WEB-застосунок ―ProfTime‖ для управління часом та справами» зі спеціальності 121 «Інженерія програмного забезпечення». Захист відбувається в Черкаському державному технологічному університеті, місто Черками 2025. Робота містить 151 сторінок, 6 таблиць, 68 рисунків, список використаних джерел з 40 найменувань, 4 додатків. Квaлiфiкaцiйнa рoбoтa присвячeнa рoзрoбцi web-зaстoсyнкy ProfTime для oсoбистoї організації чaсу, зaдaч, звичок, списків тa приміток. Aктyaльнiсть тeми oбyмoвлeнa зрoстaючoю пoтрeбoю в iнстрyмeнтaх цифрoвoї прoдyктивнoстi в yмoвaх пeрeвaнтaжeння iнфoрмaцiєю, бaгaтoзaдaчнoстi тa висoкoї динaмiки життя. Зaстoсyнoк iнтeгрyє сyчaснi time-management мeтoдики (GTD, Pomodoro, SMART, Kaizen) з iнтyїтивнo зрoзyмiлим iнтeрфeйсoм. рaмкaх прoектy бyлo рeaлiзoвaнo клiєнт-сeрвeрнy систeмy з викoристaнням Vite, React, Node.js, Express, PostgreSQL, Sequelize тa JWT. Зaбeзпeчeнo мoдyльнy aрхiтeктyрy, зaхищeнy систeмy aвтeнтифiкaцiї, гнyчкий iнтeрфeйс тa фyнкцioнaльнiсть для yпрaвлiння зaдaчaми й звичкaми. Систeмa прoтeстoвaнa i пiдгoтoвлeнa дo мaсштaбyвaння. Рeзyльтaти рoбoти мaють прaктичнe знaчeння, oскiльки зaстoсyнoк мoжe бyти викoристaний як oсoбистий oргaнaйзeр aбo aдaптoвaний для кoмaнднoї спiвпрaцi. ANNOTATION The bachelor's qualification work on the topic ―ProfTime Web Application for Time and Task Management‖ in the specialty 121 ―Software Engineering‖ contains 151 pages, 6 tables, 68 figures, a list of references with 40 items, and 4 appendices. This work is dedicated to the development of the ProfTime web application for personal organization of time, tasks, habits, lists, and notes. The relevance of the topic is due to the growing need for digital productivity tools in conditions of information overload, multitasking, and high life dynamics. The application integrates modern timemanagement methodologies (GTD, Pomodoro, SMART, Kaizen) with an intuitive user interface. Within the project, a client-server system was implemented using Vite, React, Node.js, Express, PostgreSQL, Sequelize, and JWT. The system ensures modular architecture, a secure authentication mechanism, a flexible interface, and functionality for managing tasks and habits. The system has been tested and is prepared for scaling. The results of the work have practical value, as the application can be used as a personal organizer or adapted for team collaboration.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/9057
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Files in This Item:
File	Description	Size	Format
Кваліфікаційна робота бакалавра Чепурний Іван Сергійович.pdf Restricted Access		3.73 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
бакалавра 
 
 
на тему:  «WEB-ЗАСТОСУНОК ―PROFTIME‖ ДЛЯ УПРАВЛІННЯ ЧАСОМ 
ТА СПРАВАМИ»  
 
 
Виконав: студент 4 курсу, групи ПЗ-2104 
спеціальності  
121 «Інженерія програмного забезпечення»  
 
 
Студент Чепурний І. С. 
 (прізвище та ініціали) 
Керівник Мелетап В. В. 
 (прізвище та ініціали) 
Рецензент Захарова М. В. 
 (прізвище та ініціали) 
 
 
 
Черкаси 2025 
Факультет інформаційних технологій і систем 
Кафедра  програмного забезпечення автоматизованих систем 
Освітній рівень бакалавр 
Спеціальність 121 «Інженерія програмного забезпечення» 
Освітня програма Інженерія програмного забезпечення 
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
                                           С. Голуб  
«___» _______________ 2025 року 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
Чепурний Іван Сергійович 
(прізвище, ім’я, по батькові) 
1. Тему проекту (роботи) WEB-застосунок ―ProfTime‖ для управління часом та справами 
Керівник проекту (роботи) Метелап Володимир Володимирович к.т.н. доцент  
                      (прізвище, ім’я , по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від «25» 02 2025 
року №53/03-03 
2.Строк подання студентом проекту (роботи) 6 червня 2025 
3. Вхідні дані до проекту (роботи) технології та інструментарій розробки ПЗ 
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) 
Вступ; Розділ 1 Існуючі методи та засоби розв’язання поставлених завдань; Розділ 2 
впровадження результатів дослідження у практику проектування програмного забезпечення 
інформаційних систем; Розділ 3 Розробка та тестування програмного забезпечення; Висновок; 
Список використаних джерел; Додатки. 
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту; 
Додаток А – Документація; Додаток Б – Специфікація програми; Додаток В – Текст програми; 
Додаток Г – Презентаційний матеріал. 
6. Консультанти розділів роботи 
Прізвище, ініціали та посади Підпис, дата 
Розділ 
консультанта Завдання видав Завдання прийняв 
1    
2    
3    
7. Дата видачі завдання  грудень 2024 р. 
КАЛЕНДАРНИЙ ПЛАН 
Строк виконання етапів 
№ 
Назва етапів випускної роботи кваліфікаційної Примітки 
п/п 
роботи 
1 Постановка задачі виконано 
05.12.2024 
2 Підготовка завдання виконано 
13.12.2024 
3 Погодження завдання виконано 
16.12.2024 
4 Затвердження завдання виконано 
19.02.2025 
 Основна стадія  
 
1 Підбір матеріалів виконано 
27.02.2025 
2 Аналіз шляхів вирішення поставленої виконано 
04.02.2025 
задачі 
3 Розрахунок основних параметрів виконано 
10.03.2025 
роботи 
4 Вибір кінцевого варіанту проектного виконано 
17.03.2025 
рішення 
5 Оформлення первісної редакції роботи виконано 
25.03.2025 
 Заключна стадія  
 
1 Узгодження прийнятих проектних виконано 
31.04.2025 
рішень з керівником 
2 Оформлення пояснювальної записки виконано 
13.05.2025 
роботи в кінцевій редакції 
3 Попередній захист роботи виконано 
15.05.2025 
4 Затвердження роботи  
02.06.2025 
5 Рецензування роботи  
06.06.2025 
6 Захист роботи  
12.06.2025 
 
Студент _____________________       Чепурний І.С. 
  (підпис)   (прізвище та ініціали) 
 
Керівник роботи _____________________         Метелап В.В. 
  (підпис)   (прізвище та ініціали) 
 
АНОТАЦІЯ 
 
Кваліфікаційна робота бакалавра Чепурного Івана Сергійовича на тему 
«WEB-застосунок ―ProfTime‖ для управління часом та справами» зі спеціальності 
121 «Інженерія програмного забезпечення». Захист відбувається в Черкаському 
державному технологічному університеті, місто Черками 2025. 
 
Робота містить 151 сторінок, 6 таблиць, 68 рисунків, список використаних 
джерел з 40 найменувань, 4 додатків. 
Квaлiфiкaцiйнa рoбoтa присвячeнa рoзрoбцi web-зaстoсyнкy ProfTime для 
oсoбистoї організації чaсу, зaдaч, звичок, списків тa приміток. Aктyaльнiсть тeми 
oбyмoвлeнa зрoстaючoю пoтрeбoю в iнстрyмeнтaх цифрoвoї прoдyктивнoстi в 
yмoвaх пeрeвaнтaжeння iнфoрмaцiєю, бaгaтoзaдaчнoстi тa висoкoї динaмiки 
життя. Зaстoсyнoк iнтeгрyє сyчaснi time-management мeтoдики (GTD, Pomodoro, 
SMART, Kaizen) з iнтyїтивнo зрoзyмiлим iнтeрфeйсoм. 
 
рaмкaх прoектy бyлo рeaлiзoвaнo клiєнт-сeрвeрнy систeмy з викoристaнням 
Vite, React, Node.js, Express, PostgreSQL, Sequelize тa JWT. Зaбeзпeчeнo мoдyльнy 
aрхiтeктyрy, зaхищeнy систeмy aвтeнтифiкaцiї, гнyчкий iнтeрфeйс тa 
фyнкцioнaльнiсть для yпрaвлiння зaдaчaми й звичкaми. Систeмa прoтeстoвaнa i 
пiдгoтoвлeнa дo мaсштaбyвaння. Рeзyльтaти рoбoти мaють прaктичнe знaчeння, 
oскiльки зaстoсyнoк мoжe бyти викoристaний як oсoбистий oргaнaйзeр aбo 
aдaптoвaний для кoмaнднoї спiвпрaцi. 
 
Ключoвi слoвa: TIME-MANAGEMENT, TODO, GTD, KAIZEN, SMART, 
POMODORO, REACT, REACT ROUTER, VITE, TAILWIND CSS, EXPRESS, 
NODE.JS, POSTGRESQL, SEQUELIZE, JWT, CRUD, WEB-ЗAСТOСУНOК.
ЧДТУ 252174.021 ПЗ 
ANNOTATION 
 
The bachelor's qualification work on the topic ―ProfTime Web Application for 
Time and Task Management‖ in the specialty 121 ―Software Engineering‖ contains 151 
pages, 6 tables, 68 figures, a list of references with 40 items, and 4 appendices. 
 
This work is dedicated to the development of the ProfTime web application for 
personal organization of time, tasks, habits, lists, and notes. The relevance of the topic is 
due to the growing need for digital productivity tools in conditions of information 
overload, multitasking, and high life dynamics. The application integrates modern time-
management methodologies (GTD, Pomodoro, SMART, Kaizen) with an intuitive user 
interface. 
Within the project, a client-server system was implemented using Vite, React, 
Node.js, Express, PostgreSQL, Sequelize, and JWT. The system ensures modular 
architecture, a secure authentication mechanism, a flexible interface, and functionality 
for managing tasks and habits. The system has been tested and is prepared for scaling. 
 
The results of the work have practical value, as the application can be used as a 
personal organizer or adapted for team collaboration. 
 
Keywords: TIME-MANAGEMENT, TODO, GTD, KAIZEN, SMART, 
POMODORO, REACT, REACT ROUTER, VITE, TAILWIND CSS, EXPRESS, 
NODE.JS, POSTGRESQL, SEQUELIZE, JWT, CRUD, WEB APPLICATION. 
  7
ЧДТУ 252174.021 ПЗ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ 
Time- (ua. ―Організація часу‖) Система планування та контролю 
management часу з метою підвищення ефективності виконання задач. 
SPA (Single Page Application, ua. ―Односторінковий додатк‖) 
Web-додаток, який завантажується один раз і динамічно 
оновлюється без перезавантаження сторінки. 
MPA (Multi Page Application, ua ―Багатосторінковий додаток‖) 
Класичний web-сайт, кожна сторінка якого завантажується 
окремо при переходах між ними. 
Framework (Фреймворк, ua. ―каркас‖) Набір інструментів і бібліотек, 
що спрощують розробку програмного забезпечення. 
Deadline (ua. ―Кінцевий термін‖) Чітко визначений час, до якого має 
бути завершено завдання або проєкт. 
Sticker (ua. ―Стiкeр‖) Вiзyaльний eлeмeнт, щo викoристoвyється 
для швидких нoтaтoк, нaгaдyвaнь aбo oргaнiзaцiї прoстoрy 
в систeмaх плaнyвaння. 
Content (ua. ―Кoнтeнт‖, ―Змiст‖) Iнфoрмaцiйнe нaпoвнeння сaйтy, 
дoдaткy чи дoкyмeнтa — тeксти, зoбрaжeння, вiдeo тoщo. 
Validation (ua. ―Вaлiдaцiя‖, ―Пeрeвiркa‖) Прoцeс пeрeвiрки 
прaвильнoстi ввeдeних дaних aбo вiдпoвiднoстi вимoгaм дo 
пeвнoї стрyктyри чи фoрмaтy. 
Checklist (ua. ―Контрольний список‖) Перелік справ або пунктів, які 
потрібно виконати чи перевірити. 
Todo List (ua. ―Список задач‖) Простий список справ, які потрібно 
виконати; основа систем тайм-менеджменту. 
Сustomization (ua. ―Налаштування під себе, персоналізація‖) Можливість 
змінювати вигляд або функціональність продукту під власні 
потреби. 
Habit Tracker (ua. ―Трекер звичок, відстеження звичок‖) Інструмент для 
щоденного відстеження формування нових або підтримки 
корисних звичок. 
SMART-цілі Модель постановки цілей: Specific (конкретна), Measurable 
(вимірювана), Achievable (досяжна), Relevant (релевантна), 
Time-bound (обмежена в часі). 
GTD (Getting Things Done, метод "Зробити все") Система 
управління справами від Девіда Аллена, яка допомагає 
знижувати стрес і краще організовувати задачі. 
 
  8
ЧДТУ 252174.021 ПЗ 
 
Kaizen (jp. 改善, ua. "покращення", en. "change good") Філософія 
безперервного поліпшення, яка лежить в основі японського 
підходу до time-managemet-у. Полягає в щоденному 
прагненні до невеликих, але стабільних змін, що з часом 
призводять до значних результатів. Широко 
використовується як у бізнесі, так і в особистому розвитку. 
Ikigai (jp. 生き甲斐, ua. "сенс життя") Японська концепція 
пошуку балансу між тим, що ти любиш, умієш, за що тобі 
можуть платити та що потрібно світ., Ikigai також лежить в 
основі японського підходу до саморозвитку та деяких 
аспектах time-managemet-у 
REAST API (Інтерфейс прикладного програмування) Спосіб обміну 
даними між frontend-ом і backend-ом через HTTP-запити. 
Frontend (Інтерфейс, клієнтська частина) Частина web-додатку, яку 
бачить і з якою взаємодіє користувач. 
Backend (Серверна частина додатку) Частина, що відповідає за 
логіку, базу даних, обробку запитів і збереження 
інформації. 
Cookie Невеликий файл, який зберігається в браузері користувача 
для збереження стану сесії, авторизації чи налаштувань. 
HttpOnly Cookie Це спеціальний тип cookie, який налаштовується на стороні 
сервера та недоступний для JavaScript у браузері. 
Token  (Маркер доступу) Спеціальний код, який використовується 
для ідентифікації користувача при обміні даними між 
клієнтом та сервером. Токен зберігає інформацію про 
авторизацію та дозволяє захищено взаємодіяти з 
приватними маршрутами та API без повторної авторизації. 
UI/UX (User Interface / User Experience) Комплекс підходів до 
проєктування вигляду та взаємодії користувача з системою. 
JSON (JavaScript Object Notation): Формат обміну даними 
ORM (Object-Relational Mapping, ua. Об'єктно-реляційне 
відображення) Технологія, що забезпечує взаємодію між 
об'єктно-орієнтованим програмним кодом і реляційною 
базою даних. 
БД База даних 
СУБД Система управління базами даних 
 
  9
ЧДТУ 252174.021 ПЗ 
 
  8
ЧДТУ 252174.021 ПЗ 
  9
ЧДТУ 252174.021 ПЗ 
ВСТУП 
Актуальність теми: Необхідність в розробці програмного забеспечення у 
сyчaснoмy свiтi з стрiмким тeмпом життя, пoстiйним iнфoрмaцiйним 
пeрeвaнтaжeнням тa висoкою кiлькiстю зaдaч стaвлять пeрeд людинoю нoвi 
виклики в сфeрi oсoбистoї eфeктивнoстi тa yпрaвлiння чaсoм. Цe зyмoвлює 
нeoбхiднiсть y гнyчких цифрoвих iнстрyмeнтaх, які дoзвoляють впoрядкyвaти в 
пoвсякдeннi спрaви зручні засоби керування та оптимізації, вiдстeжyвaти прoгрeс 
i фoрмyвaти кoриснi звички в повсякденному житті. Web-дoдaтoк ProfTime є 
спрoбoю вiдпoвiсти нa цю пoтрeбy: вiн пoєднyє eлeмeнти систeм плaнyвaння 
зaвдaнь, трeкeрa звичoк, iнтeлeктyaльнoї oргaнiзaцiї нoтaтoк i мeтoдик 
прoдyктивнoстi (GTD, SMART, Pomodoro, Kaizen тoщo). 
Рaзoм з тим, рoзрoбкa тaкoгo дoдaткy сyпрoвoджyється рядoм тeхнiчних 
викликiв, щo рoбить тeмy щe бiльш aктyaльнoю i для IТ-гaлyзi. Зoкрeмa, 
виникaють прoблeми iнтeгрaцiї клiєнтськoї тa сeрвeрнoї чaстин, зaбeзпeчeння 
бeзпeки aвтoризaцiї, yпрaвлiння стaнoм (state management), oбрoбки aсинхрoнних 
зaпитiв тa збeрeжeння дaних y рeляцiйнiй бaзi. Тaкoж склaднiсть зрoстaє чeрeз 
пoтрeбy y ствoрeннi мaсштaбoвaнoї мoдyльнoї aрхiтeктyри, якa дoзвoляє лeгкo 
рoзширювaти фyнкцioнaльнiсть бeз пoрyшeння цiлiснoстi дoдaткy. Викoристaння 
стeкy React, Vite, Node.js, Express, Sequelize, PostgreSQL нaклaдaє як пeрeвaги, тaк 
i вимoги щoдo сyмiснoстi, нaлaштyвaння сeрeдoвищa, eфeктивнoгo тeстyвaння i 
oптимiзaцiї прoдyктивнoстi. 
Тaким чинoм рoзрoбкa пoдiбнoгo зaстoсyнкy є aктyaльнoю як з тoчки зoрy 
зaдoвoлeння пoтрeб кiнцeвих кoристyвaчiв y пiдвищeннi прoдyктивнoстi, тaк i з 
бoкy тeхнiчнoї рeaлiзaцiї сyчaсних вeб-рiшeнь, якi вiдпoвiдaють вимoгaм якoстi, 
гнyчкoстi тa нaдiйнoстi. 
Мета і завдання розробки: Застосувати отримані знання для вирішеної 
поставленої задачі. 
Об’єкт розробки: Програмне забеспечення для особистого планування часу 
та справ, яка реалізується як web-додаток. Система орієнтована на кінцевого 
  7
ЧДТУ 252174.021 ПЗ 
користувача, що прагне структурувати особистий час, підвищити продуктивність 
та сформувати сталі звички. 
Методи проектування та конструювання: 
У процесі проектування та розробки використано: 
- аналітичні методи – для дослідження предметної області, аналізу 
аналогів та методик продуктивності. 
- методи моделювання – побудова діаграм прецедентів, класів, 
компонентів, розгортання, тощо. 
- системний підхід – при проектуванні клієнт-серверної архітектури. 
- індуктивний та емпіричний аналіз – при тестуванні функцій. 
- модульний підхід – для реалізації масштабованої frontend & backend-
структури. 
- об’єктно-реляційне проектування – через ORM Sequelize у взаємодії з 
PostgreSQL. 
Опис отриманих результатів: 
У результаті було розроблено прототип web-додатку ProfTime, який 
признaчeний для eфeктивнoгo yпрaвлiння oсoбистими зaвдaннями та часом. Цей 
додаток включає в себе: 
- систему управління із можливістю створення, редагування та групування 
об’єктів таких як задачі, звички, примітки тощо. 
- систему авторизації з використанням JWT та HttpOnly cookies; 
- адаптивний інтерфейс на основі React & Tailwind CSS; 
- вackend-архітектуру на Node.js & Express з взаємодією через REST API; 
- повноцінну базу даних із використанням PostgreSQL з Sequelize; 
Також даний розроблений застосунок має прикладне значення – він може 
використовуватись як: Інструмент для особистого планування й підвищення 
продуктивності (рефлексії). 
Код та архітектура проекту дозволяють легко масштабувати функціонал 
напр. додавання календаря, аналітики, email-сповіщень тощо. 
  8
ЧДТУ 252174.021 ПЗ 
Практичне значення отриманих результатів. 
В якості результатів отримано програмне забеспечення із зручним 
інтуїтивно зрозумілим інтерфейсом, яке дає змогу чітко отримувати інформацію 
по задачі яка була поставлена. 
Особистий внесок автора: 
У рамках виконання роботи автор самостійно: 
 проаналізував аналогічні продукти. 
 сформулював технічні вимоги. 
 обрав стек технологій (рекомендації спеціалістів дуже допомогли). 
 реалізував frontend & backend частину застосунку. 
 налаштував базу даних. 
 реалізував логіку авторизації, базовий захист даних користувача, 
обробку задач, звичок, нотаток та інших даних користувача. 
 створив діаграми архітектури та логіки системи. 
 провів тестування ключових модулів. 
 підготував повний опис предметної області та структури даних. 
  9
ЧДТУ 252174.021 ПЗ 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
У цьому розділі розглядається актуальність проблем, що виникають у 
процесі розробки сучасних web-додатків для управління задачами. На основі 
аналізу існуючих рішень обґрунтовується вибір відповідних підходів, інструментів 
та технологій, які дозволяють ефективно реалізувати функціональність системи – 
враховуючи поточний стан галузі, популярні архітектури, технічні засоби та 
переваги використання різних аналогів. 
1.1 Кoнкрeтизaцiя зaвдaнь квaлiфiкaцiйнoї рoбoти 
Oснoвним зaвдaнням дaнoї рoбoти є прoектyвaння тa рeaлiзaцiя web-
дoдaткy ProfTime, який дoзвoляє кoристyвaчaм eфeктивнo yпрaвляти зaдaчaми, 
звичкaми тa нoтaткaми, бaзyючись нa сyчaсних пiдхoдaх дo плaнyвaння тa aнaлiзy 
прoдyктивнoстi. Дoдaтoк пoвинeн бyти зрyчним y викoристaннi, швидким, 
aдaптивним тa здaтним дo мaсштaбyвaння. 
У рaмкaх цьoгo зaвдaння нeoбхiднo вирiшити тaкi пiдзaдaчi: 
 зaбeзпeчити мoжливiсть ствoрeння, рeдaгyвaння тa стрyктyрyвaння 
зaдaч; 
 рeaлiзyвaти трeкeр звичoк; 
 ствoрити iнтeрфeйс для вeдeння вiзyaльних нoтaтoк; 
 зaбeзпeчити aвтoризaцiю тa зaхист кoристyвaцьких дaних; 
 рeaлiзyвaти iнтeрфeйс з викoристaнням сyчaсних frontend-тeхнoлoгiй; 
 пoбyдyвaти backend-aрхiтeктyрy, щo пiдтримyє REST API; 
 рoзрoбити eфeктивнy стрyктyрy бaзи дaних. 
1.2 Aктyaльнi прoблeми y сфeрi тaйм-мeнeджмeнтy тa сaмoрoзвиткy 
Пoпри нaявнiсть вeликoї кiлькoстi цифрoвих iнстрyмeнтiв, кoристyвaчi 
стикaються з рядoм прoблeм: 
- нaдмiрнa фрaгмeнтaцiя iнстрyмeнтiв: для трeкiнгy зaдaч, звичoк i нoтaтoк 
чaстo дoвoдиться викoристoвyвaти рiзнi дoдaтки; 
 1 0
ЧДТУ 252174.021 ПЗ 
- вiдсyтнiсть пeрсoнaлiзaцiї тa гнyчкoстi y бiльшoстi сeрвiсiв; 
- склaднiсть y пoбyдoвi зв’язкiв мiж щoдeнними дiями тa дoвгoстрoкoвими 
цiлями; 
- низький рiвeнь iнтeгрaцiї прoдyктивнiсних мeтoдик (GTD, Pomodoro, 
SMART, Eisenhower Matrix, Kaizen e.g.). 
Цi прoблeми oбyмoвлюють пoтрeбy в єдинoмy рiшeннi, якe пoєднyє 
iнстрyмeнти плaнyвaння, сaмoaнaлiзy тa фoрмyвaння звичoк в oднoмy iнтeрфeйсi. 
1.3 Огляд існуючих підходів до розробки додатків для управління 
задачами 
Сучасні web-додатки зазвичай реалізуються з використанням даних 
архітектурних підходів: односторінкової (SPA) та багатосторінкової (MPA) 
архітектури. 
SPA-додатки забезпечують швидку і плавну взаємодію з інтерфейсом, 
оскільки не вимагають перезавантаження сторінок при переходах між ними. 
Згідно з Shannon Jackson-Barnes[15], такий підхід є доцільним у додатках з 
високою динамікою даних та частою взаємодією користувача з інтрефейсом. В 
свою чергу MPA-додатки, навпаки, використовують класичну модель, де кожна 
сторінка завантажується окремо. 
У контексті SPA-додатків, які часто реалізуються з використанням React (чи 
його аналогів), було проаналізовано типову структуру таких проектів. Як зазначає 
Will Taylor [10], ефективним підходом є модульна організація коду з чітким 
поділом на компоненти, сторінки, сервіси та інші логічні блоки. Така структура не 
лише відповідає принципам розробки SPA, але й забезпечує високу гнучкість та 
зручність підтримки застосунку, не кажучи вже про його маштабованість. 
1.4 Огляд технологій для розробки додатку 
Для створення даного web-додатку також було розглянуто набір сучасних 
технологій, які забезпечують ефективну розробку та зручну майбутню підтримку 
 1 1
ЧДТУ 252174.021 ПЗ 
системи. Кожна така технологія була обрана з урахуванням її стабільності, 
популярності та зручності інтеграції з різними системами. 
React: Бібліотека (фрейемворк) для побудови інтерфейсів, що базується на 
компонентах, яка дозволяє створювати швидкі та масштабовані SPA-додатки 
завдяки використанню Virtual DOM. Ця технологія була обрана через свою 
гнучкість, активну спільноту та сталий розвиток технології [26]. 
Переваги: 
 висока продуктивність; 
 компонентна архітектура; 
 велика екосистема та спільнота. 
Недоліки: 
 початковий поріг входу – хоча сам React простий, для реального проекту 
часто потрібні додаткові інструменти такі як, React Router, Redux, Vite 
тощо; 
 часті оновлення – зміни в API часто вимагають адаптації коду; 
 jsx файли можуть здатися незвичним для новачків, оскільки поєднує 
HTML та JavaScript в одному файлі. 
React Router: Бібліотека для реалізації навігації у SPA-додатку. Вона 
забезпечує створення SPA логіки без фактичного перезавантаження сторінок, 
підтримує вкладені маршрути, налаштування параметрів в URL та захищені 
(приватні) маршрути, що критично важливо для додатків із автентифікацією [27]. 
Переваги: 
 гнучка підтримка маршрутизації; 
 можливість реалізації захищених маршрутів. 
Недоліки: 
- потрібна додаткова конфігурація; 
- часті зміни в API – версії React Router (наприклад, 5 vs 6) суттєво 
відрізняються, що ускладнює підтримку проекту. 
Tailwind CSS: Утилітарний CSS-фреймворк, який дозволяє швидко 
 1 2
ЧДТУ 252174.021 ПЗ 
створювати адаптивні й уніфіковані дизайни без необхідності в написанні окремих 
CSS-файлів, що забезпечює швитку верстку та управління стилями без надмірного 
дублювання коду. [35]. 
Переваги: 
 швидка розробка web-інтерфейсів; 
 зменшення дублювання стилів. 
Недоліки: 
 захаращення HTML-коду; 
 менше відокремлення стилів від логіки, що інколи суперечить 
принципам розділення відповідальностей у проекті. 
Flowbite React: Набір готових UI-компонентів, побудованих на основі 
Tailwind [9]. Подібні бібліотеки UI-компонентів значно прискорюють процес 
створення інтерфейсів, що в свою чергу дозволяють більше зосередитися на логіці 
системи замість рутинної розробки елементів інтерфейсу з нуля. 
Переваги: 
- представлення пакету готових компонентів; 
- сумісність із Tailwind CSS. 
Недоліки: 
- обмежена гнучкість, компоненти важко редагувати під нестандартні 
вимоги; 
- залежність від сторонньої бібліотеки (а саме Tailwind CSS). 
Vite: сучасний збирач, який побудований на базі esbuild тенології, що 
забезпечує миттєвий запуск проекту, гаряче оновлення модулів та загалом кращу 
продуктивність у процесі розробки ніж його попередники (наприклад create-react-
app). Ось що про нього пришуть в документації ―Vite. pre-bundles dependencies 
using esbuild. esbuild is written in Go and pre-bundles dependencies 10-100x faster 
than JavaScript-based bundlers.‖ [39]. 
Переваги: 
 1 3
ЧДТУ 252174.021 ПЗ 
 миттєвий запуск (Instant dev server) – Vite використовує нативні ES-
модулі та не будує весь проект на старті; 
 дуже швидке оновлення інтерфейсу при зміні коду. 
Недоліки: 
- менша кількість готових шаблонів/гайдів – у порівнянні з його 
попередниками, менше статей, прикладів і навчальних матеріалів (хоча 
документація one love); 
- можлива несумісність із менш популярними плагінами. 
Для створення серверної частини було розглянуто Node.js – платформу, яка 
дозволяє виконувати JavaScript на стороні сервера (завдяки движук V8). Завдяки 
цьому з’являється можливість використовувати одну мову програмування як для 
клієнтської, так і для серверної частин, що особливо зручно в умовах єдиного  
стеку на базі JavaScript [23]. 
Переваги: 
- єдина мова для клієнт-серверної частини; 
- невелике споживання ресурсів та висока продуктивність – завдяки 
неблокуючій моделі введення/виведення (non-blocking I/O) Node.js добре 
підходить для обробки великої кількості одночасних запитів; 
- широка екосистема пакетного менеджера npm. 
Недоліки: 
 через однопоточну модель обробки, складні обчислення можуть 
блокувати виконання інших запитів; 
 асинхронність та вкладені колбеки часто ускладнюють читання коду; 
 менш формалізована структура – у порівнянні з іншими backend-
технологіями, Node.js дає більше свободи, що може призводити до 
безладу у великих проектах без чіткої архітектури. 
У поєднанні з Node.js було розглянуто Express – мінімалістичний framework, 
який дозволяє відносно в простому варіанті працювати з RESTful API [6]. 
Переваги: 
 1 4
ЧДТУ 252174.021 ПЗ 
 простота та мінімалізм; 
 підтримка middleware. 
Недоліки: 
 менше готових рішень «з коробки» – порівняно з більшими 
фреймворками (наприклад, Nest.js або Django), Express вимагає більше 
ручного налаштування. 
JWT (JSON Web Token): Для автентифікації та авторизації користувачів 
роглянуто технологію JWT, яка дозволяє безстейтово зберігати токени доступу в 
cookie або localStorage, забезпечуючи захист приватних маршрутів і безпечну 
передачу даних між клієнтом та сервером [12][16]. 
Переваги: 
- гнучкість у збереженні токенів; 
- швидкість обробки. 
Недоліки: 
 якщо токен зберігається у localStorage, він вразливий до XSS атак; 
 фіксований час життя токена – при компрометації токен залишатиметься 
дійсним до завершення його строку дії, це створює потенційні загрози 
безпеці. 
PostgreSQL – надійна реляційна система (СУБД) з підтримкою складних 
типів зв’язків, транзакцій та високої продуктивності [24]. Вона чудово підходить 
для структурованих даних і складної аналітики. 
Переваги: 
 висока продуктивність при складних запитах – особливо ефективна для 
аналітики, роботи з великими обсягами структурованих даних та 
складною бізнес-логікою. 
Недоліки: 
- складність налаштування та оптимізації – вимагає глибших знань у 
порівнянні з простішими система управління баз даних, такими як 
MySQL. 
 1 5
ЧДТУ 252174.021 ПЗ 
ORM Sequelize: Дозволяє взаємодіяти з PostgreSQL на рівні моделей [31]. 
Цей підхід значно спрощює створення таблиць, зв’язків і запитів між ними, а 
також додатково підвищює безпеку проекту завдяки автоматичному екрануванню 
вхідних даних, знижуючи ризик SQL-інʼєкцій. 
Переваги: 
- спрощена робота з базами даних через моделі – дозволяє працювати з 
базою даних як з об’єктами, а не вручну писати SQL-запити; 
- знижує ризики SQL-інʼєкцій завдяки вбудованим механізмам безпеки. 
Недоліки: 
 погана документація і складні помилки – деякі аспекти погано описані, і 
помилки можуть бути малозрозумілими; 
 низька продуктивність у складних запитах – ORM може генерувати 
неефективні SQL-запити, що впливає на швидкодію. 
1.5 Аналіз існуючих рішень для управління задачами 
У процесі дослідження аналогів існуючих рішень для управління задачами 
та time-management-у вцілому, було розглянуто кілька популярних інструментів, 
кожен з яких має свої особливості, переваги та обмеження. 
 Trello: Один із найпоширеніших рішень для командного управління 
задачами – візуальний інструмент, заснований на методології Kanban, 
тобто робоча область організована через дошки, колонки та картки, що 
переміщуються відповідно по етапах виконання; 
Переваги: 
- інтуїтивно зрозумілий інтерфейс; 
- добре підходить для командної роботи; 
- має можливість прикріплювати файли, чек-листи, дедлайни та 
коментарі; 
- має підтримку інтеграцій з іншими сервісами (Google Drive, Slack 
тощо); 
 1 6
ЧДТУ 252174.021 ПЗ 
- має можливість розширення функціоналу за допомогою power-ups. 
Недоліки: 
- менш зручний для особистого планування; 
- відсутність вбудованих аналітичних інструментів чи трекера звичок; 
- у безкоштовній версії встановлені обмеження на кількість 
розширень. 
 Todoist: Сервіс для ведення списків задач з підтримкою ієрархії, тегів, 
пріоритетів та дедлайнів; 
Переваги: 
 простий та зручний інтерфейс; 
 має підтримку кастомних списків, фільтрів, категорій тощо; 
 надійна система нагадувань; 
 доступність на всіх пристроях (web, мобільні, десктопні додатки); 
 має можливість різного роду автоматизації за допомогою інтеграцій. 
Недоліки: 
 частина функцій доступна лише в платній версії; 
 обмежений візуальний контроль прогресу; 
 менше можливостей для командної роботи. 
 Google Tasks: Ідеально підходить для щоденних справ, де не потрібна 
складна структура або глибока аналітика; 
Переваги: 
- проста інтеграція з Gmail та Google Calendar; 
- мінімалістичний інтерфейс, що не відволікає; 
- зручність у створенні підзадач та встановленні термінів; 
Недоліки: 
- відсутність тегів, аналітики, пріоритетів; 
- не підходить для командної роботи чи великих проєктів; 
- функціонує як частина Gmail / Calendar без окремого повноцінного 
застосунку; 
 1 7
ЧДТУ 252174.021 ПЗ 
- це одним продуктом від Google, що добре підходить для нотаток та 
швидких записів, є Google Keep. 
 Google Keep: інструмент для створення нотаток, списків справ та ідей, з 
підтримкою кольорового маркування, нагадувань, фото та голосових 
нотаток; 
Переваги: 
 ідеальний для швидких нотаток "на ходу"; 
 інтеграція з іншими сервісами Google; 
 має підтримку прикріплення аудіо, фото документів; 
 спільна робота над нотатками. 
Недоліки: 
 відсутність системи пріоритетів та підзадач; 
 складність в організації при великій кількості інформації; 
 не має чіткої структури проектів; 
 TickTick: Багатофункціональний застосунок, який поєднує кілька 
підходів до продуктивності в одному інтерфейсі. 
Переваги: 
 комбінує to-do список, календар, трекер звичок і помодоро-таймер; 
 зручні мобільні та десктопні додатки; 
 можливість переглядати статистику та продуктивність; 
 гнучка система фільтрів, тегів і пріоритетів; 
Недоліки: 
 інтерфейс може здатися перевантаженим; 
 менше готових інтеграцій, ніж у популярніших конкурентів. 
1.6 Методології time-management-у у контексті проектування додатку 
Сучасні додатки для time-management-у спираються не лише на технічні 
рішення, а й на перевірені методології (або філософії), які допомагають 
користувачам краще структурувати свої завдання, підтримувати мотивацію та 
підвищувати особисту ефективність. Нижче розглянемо основні підходи, що лягли 
 1 8
ЧДТУ 252174.021 ПЗ 
в основу функціоналу багатьох популярних сервісів, і які також можуть бути 
враховані при проектуванні власного додатку. 
1 GTD (Getting Things Done): Методика Девіда Аллена, викладена у книзі 
"Getting Things Done: The Art of Stress-Free Productivity", базується на 
принципі ―звільнення розуму‖. Ідея полягає в тому, щоб зафіксувати всі 
справи у зовнішній системі, знявши з мозку тягар постійного 
нагадування про них. Завдяки цьому увага концентрується не на 
зберіганні інформації, а на безпосередньому виконанні задач. Такий 
підхід допомагає знизити рівень стресу та впорядкувати робочі процеси 
[1]; 
2 Pomodoro (розроблена Франческо Чірілло): Вона передбачає розбиття 
робочого часу на інтервали: наприклад 25 хвилин зосередженої праці, за 
якими слідує коротка перерва (5 хвилин), після кількох циклів – довша 
пауза. Така структура сприяє збереженню фокусу, зниженню втоми та 
підвищенню продуктивності, зокрема під час рутинних завдань або 
навчання [3]; 
3 SMART-цілі: управління задачами також часто спирається на принципи 
SMART [5], які дозволяють чітко формулювати цілі. Кожна задача має 
бути:  Specific (конкретною); Measurable (вимірюваною); Achievable 
(досяжною); Relevant (релевантною); Time-bound (обмеженою у часі). 
Цей підхід забезпечує фокусування на результаті, допомагає уникати 
абстрактних формулювань та ефективно планувати час. 
4 Kaizen доповнює вищезгадані підходи філософія Kaizen, 
популяризована Масакі Імаї [13]. Вона базується на концепції 
безперервного поступового вдосконалення. Замість радикальних 
трансформацій, Kaizen заохочує щоденні невеликі кроки до кращих 
результатів. Цей принцип ідеально поєднується з функціональністю 
трекерів звичок і системою щоденного планування, сприяючи 
стабільному особистісному росту [13][18][19]. 
 1 9
ЧДТУ 252174.021 ПЗ 
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ 
У ході аналізу сучасних засобів управління задачами та особистої 
ефективності були визначені ключові функціональні компоненти, що найповніше 
відповідають цілям і вимогам до web-додатку ProfTime. Такі сервіси, як TickTick, 
Todoist і Google Keep та інші, демонструють актуальні підходи до організації 
задач, трекінгу звичок і ведення нотаток – ці рішення лягли в основу 
функціональної концепції майбутнього застосунку. 
Web-додаток ProfTime проектується як гнучка система управління 
завданнями, яка дозволяє користувачам створювати задачі, групувати їх за 
категоріями, виставляти пріоритети, дедлайни та використовувати додаткові 
модулі – трекер звичок і Sticky Wall – для побудови цілісного підходу до 
самоорганізації. 
Особливу увагу приділено можливості інтеграції сучасних методологій time-
management-у, зокрема GTD, Pomodoro, Eisenhower Matrix, а також стратегічних 
концепцій – Kaizen, Ikigai та SMART. На мою думку, саме ці підходи формують 
ядро сучасної філософії time-management-у, орієнтованої на усвідомленості, 
продуктивністі та балансу між особистими й професійними цілями та їх 
поступове вдосконалення. 
 2 0
ЧДТУ 252174.021 ПЗ 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ 
У цьому розділі було розглянуто практичні аспекти проектування  web-
додатку ProfTime для огранізації задач та часу. Основна увага приділяється 
архітектурним рішенням, обґрунтуванню вибору технологій для створення 
додатку, організації клієнт-серверної взаємодії і т.д. 
 Архітектура системи 
Під час проектування було обрано архітектуру з чітким поділом на 
клієнтську-серверну взаємодію. 
Основними компонентами архітектури є: 
 Кліентська частина – відповідає за інтерфейс користувача, 
маршрутизацію між сторінками та взаємодію з сервером через REST 
API. Передбачає як публічні сторінки (реєстрація, логін, головна), так і 
захищені, доступ до яких відкривається після авторизації (керування 
задачами, звичками, нотатками, налаштування). 
 Серверна частина – обробляє запити клієнта, відповідає за авторизацію, 
валідацію даних, реалізацію бізнес-логіки та комунікацію з базою даних. 
Архітектура серверної частини планується реалізувати модульно (роути, 
контролери, сервіси, моделі), що сприяє зручній маштабованості коду. 
 СУБД – забезпечує зберігання інформації про користувачів, задачі, 
звички, списки та нотатки. Для взаємодії із СУБД було обрано ORM 
Sequelize, що дозволяє використовувати зручні засоби побудови запитів, 
а також підтримує механізми міграцій та тестування. 
 Вибір технологій та інструментів 
Клієнтська частина: 
 React – бібліотека для побудови динамічних SPA додатків [26]. 
 React Router DOM – засіб для маршрутизації між сторінками [27]. 
 2 1
ЧДТУ 252174.021 ПЗ 
 Tailwind CSS – утилітарна CSS-бібліотека для прискореної розробки UI. 
Серверна частина: 
1 Node.js – серверне середовище виконання JavaScript; 
2 Express.js – фреймворк для розробки REST API; 
3 Sequelize ORM – засіб для об’єктно-реляційного відображення роботи з 
PostgreSQL; 
4 Jest – інструмент для тестування окремих модулів, зокрема роботи з 
базою даних. 
 Інші інструменти: 
 Vite – сучасний збирач і сервер розробки для frontend-у; 
 dotenv, cors, cookie-parser, jsonwebtoken, bcryptjs, concurrently, module-
alias, flowbite react, react icons – допоміжні бібліотеки для налаштування 
середовища, авторизації, захисту API, обробки токенів, паралельного 
запуску клієнта і сервера тощо. 
Клієнт-серверна взаємодія 
У рамках проектування взаємодії між клієнтом і сервером було обрано 
використання REST API, яке забезпечує чітку та стандартизовану комунікацію між 
частинами системи. Усі запити реалізуються з використанням функції (об’єкту) 
fetch через окремі сервісні модулі (наприклад Auth, Task, Habit Services), що 
спрощує супровід і повторне використання логіки. Також для надійної авторизації 
було обрано механізм з використанням JWT-tokens, які зберігаються в HttpOnly 
куках. Він дозволяє зберігати авторизаційний стан навіть після оновлення 
сторінки, а також має деякий рівень захисту від атак типу XSS. 
У відповідь коли до сервера приходить запит – він надсилає відповідні 
HTTP-статуси (200, 201, 400, 401, 403, 404, 500) та структуровані JSON-об’єкти. 
Автоматизація користувацьких сценаріїв 
З метою підвищення зручності та ефективності взаємодії користувача з 
системою, у процесі проектування було передбачено впровадження базових 
механізмів автоматизації: 
 2 2
ЧДТУ 252174.021 ПЗ 
- автоматичне оновлення списків задач після додавання, редагування або 
видалення; 
- фільтрація задач за датою, списками, категоріями; 
- сторінка "Сьогодні", яка формує динамічний список лише актуальних 
задач; 
- підтримка приватних маршрутів, що гарантує доступ лише 
авторизованим користувачам; 
- можливість створення та редагування списків, категорій, нотаток – із 
подальшою взаємодією з ними. 
У довгостроковій перспективі планується впровадження розширених 
сценаріїв автоматизації, таких як: персональні нагадування, шаблони 
повторюваних задач, e-mail-сповіщення, а також інтеграція аналітики для 
візуалізації прогресу користувача. 
2.1 Моделювання предметної області 
2.1.1 Предметна область моделювання. Модель предметної області. Словник 
предметної області 
Моделювання предметної області є важливим етапом проектування системи, 
оскільки дозволяє чітко визначити ключові об'єкти, їхні властивості та 
взаємозв’язки, що лежать в основі роботи додатку. 
Предметна область моделювання: Web-додаток ProfTime, призначений для 
індивідуального управління завданнями, звичками, нотатками та повсякденними 
активностями користувача.  
Основна мета – надати зручний інструмент для організації особистого часу, 
планування та саморозвитку. 
Модель предметної області включає в себе такі основні об'єкти: 
 користувач: Центральна фігура системи. Має обліковий запис і взаємодіє 
з додатком, створює, редагує, виконує або видаляє задачі, звички, 
нотатки; 
 2 3
ЧДТУ 252174.021 ПЗ 
 задача (Task): Базова одиниця планування, що містить назву, опис, 
deadline, пріоритет і статус виконання. Може бути згрупована в 
категорію або список; 
 cписок задач (TaskList): Логічне об’єднання завдань, створене 
користувачем для впорядкування задач за напрямами, темами або 
проектами; 
 звичка (Habit): Регулярна дія, яку користувач виконує за обраним 
графіком (щодня, щотижня тощо). Система дозволяє фіксувати 
виконання та відстежувати прогрес; 
 примітка (StickyNote): Текстовий елемент, який користувач вільно 
розміщує на інтерактивній ―стіні‖ для збереження ідей, нагадувань або 
важливої інформації; 
 Прогрес: Агреговані дані, що відображають рівень виконання задач і 
звичок, дозволяючи оцінювати загальну продуктивність користувача в 
системі. 
Для повноцінного розуміння функціонування додатку доцільно також 
розглянути словник термінів предметної області. 
Словник предметної області: 
 робоча область: Основний інтерфейс користувача, у межах якого 
відбувається взаємодія з елементами інтерфейсу, які мають різні типи 
(задача, примітка, список, звичка тощо); 
 категорія задач: Системна класифікація завдань, зокрема Inbox (вхідні), 
Today (на сьогодні), List (іменовані списки) – що спрощує навігацію та 
фокус користувача; 
 трекер звичок: Функціональний модуль, що дозволяє фіксувати 
виконання звичок за днями та аналізувати сталість дій; 
 стікери: Візуальні нотатки, які можна розміщувати на екрані довільно, 
формуючи особисту інформаційну стіну; 
 аналітика: Набір інструментів для візуалізації даних про активність, 
 2 4
ЧДТУ 252174.021 ПЗ 
виконання задач, дотримання звичок, що сприяє саморефлексії та 
покращенню time-managemet-у; 
- база даних: Структуроване сховище всієї інформації системи – облікових 
записів, задач, звичок, нотаток та історії дій користувача. 
2.1.2 Елементи моделювання предметної області 
Рисунок 2.1 – Основні графічні символи UML [40] 
 2 5
ЧДТУ 252174.021 ПЗ 
На основі виділених об’єктів у моделі предметної області web-додатку 
ProfTime, детально розглянуто основні сутності системи, їхні атрибути та 
взаємозв’язки. Ці сутності відображають реальні процеси взаємодії користувача з 
додатком – створення, організацію та виконання задач, формування корисних 
звичок, збереження нотаток тощо. 
У центрі моделі знаходиться користувач, як головний суб'єкт системи, який 
здійснює дії над пов'язаними об'єктами – задачами, звичками, нотатками. 
Відповідно, встановлюються наступні логічні зв’язки: 
 користувач може мати багато задач, звичок і нотаток; 
 кожна задача належить певному списку задач і одному користувачу; 
 звичка характеризується періодичністю та фіксує статус виконання; 
 нотатка має просторову позицію на віртуальній ―стіні‖, текстовий вміст і 
дату створення. 
Нижче наведено опис кожної сутності з її атрибутами та зв’язками: 
 користувач (User): Це основна сутність, яка взаємодіє з усіма іншими 
об’єктами системи; 
- атрибути: ID, ім’я, електронна пошта, пароль, дата реєстрації; 
- зв’язки: 
- має багато задач (один-до-багатьох); 
- має багато звичок (один-до-багатьох); 
- має багато нотаток (один-до-багатьох). 
 задача (Task): Одиниця планування, яку створює користувач для 
досягнення конкретної мети; 
- атрибути: ID, назва, опис, deadline, пріоритет, статус виконання, 
дата створення; 
- зв’язки: 
 належить одному користувачу (багато-до-одного); 
 належить одному списку задач (багато-до-одного). 
 2 6
ЧДТУ 252174.021 ПЗ 
 список задач (TaskList): Використовується для групування задач за 
категоріями або типами; 
- атрибути: ID, назва списку, тип (Inbox, Today, Custom), дата 
створення; 
- зв’язки: 
- містить багато задач (один-до-багатьох); 
- належить одному користувачу (багато-до-одного). 
 звичка (Habit): Регулярна дія, яку користувач виконує для формування 
корисної поведінки; 
 атрибути: ID, назва, опис, періодичність (щодня, щотижня), статус 
виконання, лічильник успішних днів. 
 зв’язки: 
 належить одному користувачу (багато-до-одного). 
- примітка (StickyNote): Інформаційний блок, який користувач розміщує 
на віртуальній ―стіни‖; 
- атрибути: ID, текст, дата створення, колір або тип; 
- зв’язки: 
 належить одному користувачу (багато-до-одного). 
Узагальнюючи, модель предметної області web-додатку ProfTime 
демонструє взаємопов’язану систему, де всі сутності підпорядковані логіці 
персонального планування, менеджменту та візуальної організації робочого 
простору користувача. Така структура є гнучкою та легко масштабованою, що 
дозволяє в майбутньому доповнювати функціонал системи без порушення її 
цілісності. 
2.1.3 Робоча область моделювання  
Робоча область є центральним інтерактивним середовищем, у якому 
користувач взаємодіє з основною функціональністю web-додатку ProfTime. Вона 
забезпечує зручний та логічно впорядкований доступ до інструментів 
персонального управління, таких як створення й перегляд задач, трекінг звичок, 
 2 7
ЧДТУ 252174.021 ПЗ 
ведення нотаток, а також моніторинг продуктивності. 
Для підвищення зручності користування та ефективності навігації, робоча 
область поділена на декілька логічно відокремлених зон, кожна з яких відповідає 
за окрему функціональну складову системи. Така модульна структура дозволяє 
фокусуватися на конкретних діях користувача, підтримуючи при цьому загальний 
контекст роботи. 
Основні зони робочої області включають: 
- Inbox – Зона первинного збору задач, куди автоматично потрапляють усі  
записи. Inbox служить тимчасовим сховищем, з якого задачі згодом 
можуть бути переміщені до відповідних списків або заплановані на 
конкретну дату; 
- Today – Розділ, що відображає лише ті задачі, які заплановані на 
поточний день. Спрямований на концентрацію уваги користувача на 
пріоритетних діях та зниження когнітивного навантаження; 
- Habits – Модуль управління звичками. Містить перелік активних звичок 
користувача з можливістю щоденного відзначення їх виконання. Також 
передбачено перегляд історії та прогресу, що мотивує до формування 
стійких корисних звичок; 
- Sticky Wall – Віртуальна "стіна", на якій користувач може вільно 
розміщувати текстові нотатки у вигляді стікерів. Вона виконує роль 
гнучкого простору для збереження ідей, нагадувань, думок або планів 
без жорсткої структуризації; 
- Lists – Секція користувацьких списків задач, що дає змогу структурувати 
завдання за окремими напрямками, проєктами чи темами. Це дозволяє 
будувати персоналізовану систему планування відповідно до 
індивідуальних потреб; 
- Settings – Розділ, у якому користувач може керувати персональними 
параметрами свого облікового запису. До доступних опцій належать 
зміна особистих даних, конфігурація візуального оформлення, мова 
 2 8
ЧДТУ 252174.021 ПЗ 
інтерфейсу, а також налаштування повідомлень і сповіщень; 
Завдяки такому логічному поділу, робоча область web-додатку ProfTime 
підтримує інтуїтивно зрозумілу навігацію та забезпечує користувачу зручний 
контроль над усіма аспектами особистої продуктивності. 
2.2 Формування та аналіз вимог 
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні 
вимоги 
У процесі проектування web-додатку ProfTime формування вимог 
здійснюється на основі аналізу предметної області, актуальних методик time-
management-у (наприклад, GTD, SMART), а також на базі функціональних 
можливостей популярних аналогів – Trello, Todoist, Habitica. 
 Первинні вимоги 
Первинні вимоги визначають загальну мету системи та ключові 
функціональні можливості, необхідні для реалізації базового циклу взаємодії 
користувача з додатком: 
- можливість реєстрації нового користувача та авторизації у системі; 
- створення, редагування та видалення задач; 
- категоризація задач за логічними зонами: Inbox, Today, Lists; 
- додавання та трекінг звичок; 
- робота з нотатками на віртуальній стіні Sticky Wall; 
- автоматичне збереження всіх даних у базі (задачі, звички, нотатки). 
 Деталіні вимоги (уточнюють логіку реалізації ключових функцій): 
 авторизація з використанням токенів JWT; 
 фільтрація та сортування задач за тегами, датою, пріоритетом; 
 пошук задач за ключовими словами, тегами, вмістом; 
 інтерфейс односторінкового застосунку (SPA): Vite & React; 
 можливість навігації між категоріями задач (Inbox, Today, Lists) без 
 2 9
ЧДТУ 252174.021 ПЗ 
перезавантаження сторінки. 
 Вимоги замовника (користувача): 
 Простота та інтуїтивність у користуванні, навіть без досвіду з 
подібними додатками. 
 Гнучкість у налаштуванні задач, звичок, списків і нотаток. 
 Можливість швидкого додавання інформації та візуального 
контролю за особистим прогресом. 
 Вимоги розробника: 
- Використання сучасного стеку технологій: React (frontend), Node.js з 
Express (backend), PostgreSQL з ORM Sequelize (база даних). 
- Дотримання принципів безпеки: валідація вводу, обмеження 
доступу. 
- Масштабована архітектура, що дозволяє легко розширювати 
функціонал без зміни базових модулів. 
 Функціональні вимоги (описують, що саме система повинна робити): 
 Реєстрація та вхід користувача. 
 CRUD-операції для задач, звичок, нотаток. 
 Трекінг виконання звичок з урахуванням їх періодичності. 
 Вільне розміщення нотаток на координатній сітці Sticky Wall. 
 Система списків задач, включаючи попередньо визначені (Inbox, 
Today) та користувацькі. 
 Реалізація нагадувань, пошуку, фільтрації. 
 Нефункціональні вимоги (визначають якість роботи системи): 
 Адаптивність: підтримка мобільних, планшетних і десктопних 
пристроїв. 
 Безпека: 
- Хешування паролів, захищене зберігання токенів. 
- Ізоляція даних між користувачами. 
- Захист від SQL-ін’єкцій (ORM Sequelize). 
 3 0
ЧДТУ 252174.021 ПЗ 
- Захист від XSS-атак (валідація та екранування вводу). 
 Масштабованість: готовність до розширення функцій (наприклад, 
додавання календаря або аналітики). 
 Зручність використання: мінімалістичний, зрозумілий інтерфейс з 
чіткими інструкціями. 
 Продуктивність: швидке завантаження, кешування даних, 
збереження сесії користувача без затримок. 
2.2.2 Формування вимог за допомогою діаграми прецедентів  
На діаграмі представлено два актори: Гість та Користувач. Кожен із них 
взаємодіє з системою у межах певних сценаріїв (прецедентів), які визначають 
доступний функціонал. 
 
Рисунок 2.2 – Діаграма прецедентів для web-додатку ProfTime 
 3 1
ЧДТУ 252174.021 ПЗ 
Основні сценарії використання (прецеденти): 
- переглянути базові сторінки: Гість може переглядати загальнодоступні 
сторінки - головну, проектну інформацію, статті з теми 
самоменеджменту; 
- зареєструватися: Гість може створити обліковий запис для доступу до 
персоналізованого функціоналу; 
- керувати задачами: Користувач може створювати, редагувати та видаляти 
задачі, а також встановлювати пріоритети, сортувати та групувати їх у 
списки; 
- керувати звичками: Користувач має змогу створювати та відстежувати 
звички, змінювати або видаляти їх; 
- керувати нотатками: Робота з візуальними нотатками на стіні StickyWall 
– створення, редагування та видалення; 
- керувати списками задач: Можливість створення іменованих списків 
задач для структурування робочого процесу; 
- пошук: Користувач може шукати задачі, звички чи нотатки за ключовими 
словами та категоріями (Inbox, Today, Habits, StickyWall, Lists). 
Стрілки між акторами та прецедентами на діаграмі показують, хто саме 
ініціює той чи інший сценарій. Це дозволяє чітко визначити межі доступу та ролі 
користувачів у системі. 
2.3 Проектування логічної структури програмного комплексу 
2.3.1 Діаграми класів 
На діаграмі класів (рисунок 2.3 та 2.4) представлено логічну модель 
взаємодії основних сутностей майбутнього web-додатку ProfTime. Хоча в 
реалізації застосовується функціональний підхід, REST API та компонентна 
архітектура React, діаграма класів використовується як інструмент 
концептуального моделювання. Вона дозволяє візуалізувати ключові об'єкти, їх 
атрибути та взаємозв’язки, що забезпечує цілісне бачення структури застосунку на 
етапі проектування. 
 3 2
ЧДТУ 252174.021 ПЗ 
Рисунок 2.3 – Діаграма класів для web-додатку ProfTime 
 
Основні сутності та логічні взаємозв’язки: 
- User – головний суб’єкт системи, який володіє задачами (Task), звичками 
(Habit) та нотатками (StickyNote); 
- Task – одиниця роботи або нагадування, що належить певному списку 
задач (TaskList) та містить атрибути: дедлайн, пріоритет, статус тощо. 
- Habit – повторювана дія, що має зв'язок із записами виконання 
(HabitLog) для ведення трекінгу прогресу; 
- StickyNote – нотатка на віртуальній стіні, що містить заголовок, текст, 
колір і координати на сітці; 
- Article та ArticleSection – компоненти освітнього блоку, де статті поділені 
на розділи і доступні користувачам. 
 3 3
ЧДТУ 252174.021 ПЗ 
Рисунок 2.4 – Розширена діаграма класів для web-додатку ProfTime 
 
Основні сервіси (логічні компоненти системи): 
 3 4
ЧДТУ 252174.021 ПЗ 
- UserService – забезпечує реєстрацію, авторизацію, оновлення профілю та 
видалення акаунту. Працює з об’єктом User; 
- TaskService – виконує CRUD-операції з задачами та списками, 
фільтрацію, пошук та логіку сортування; 
- HabitsService – керує створенням звичок та логами їх виконання; 
- StickyWallService – реалізує зберігання, редагування та отримання 
нотаток StickyNote; 
- SearchService – забезпечує глобальний пошук по задачах, звичках, 
нотатках; 
- ArticleService – відповідає за отримання та структурування 
інформаційних матеріалів у вигляді статей та їхніх секцій. 
Основні взаємозв’язки між класами: 
- один User може мати багато Task, Habit та StickyNote; 
- кожна Task належить до TaskList, яка також зв’язана з User; 
- кожна Habit має пов’язані HabitLog-записи; 
- кожен сервіс (наприклад, TaskService, HabitsService) взаємодіє лише з 
відповідною сутністю, що реалізує принцип розділення обов’язків і 
спрощує масштабування системи. 
Ця структура дозволяє ефективно планувати подальшу реалізацію API, 
побудову моделей бази даних та організацію React-компонентів на frontend-і. 
2.3.2 Діаграми пакетів 
На діаграмі пакетів (рисунок 2.5) зображено логічну структуру архітектури 
системи, яка поділяє web-додаток на три основні функціональні пакети: Frontend, 
Backend та Database. Кожен із них відповідає за окрему частину обробки даних, 
взаємодії з користувачем та збереження інформації. 
 3 5
ЧДТУ 252174.021 ПЗ 
Рисунок 2.5 – Діаграма пакетів для web-додатку ProfTime 
 
Основні пакети системи: 
- Frontend: відповідає за інтерфейс користувача та взаємодію з backend-ом 
через API. 
- UI: Компоненти реалізовані з використанням React. Для стилізації 
застосовується TailwindCSS і бібліотека Flowbite React; 
- UX: Маршрутизація реалізована через React Router для 
забезпечення навігації в межах клієнтської частини; 
- API / Service: Виконує HTTP-запити до backend (RESTful API), 
забезпечуючи передачу даних між клієнтською та серверною 
частинами. 
- Backend: виконує обробку запитів, логіку додатку, авторизацію, та 
зв’язок з базою даних. 
- Routers: Визначають маршрути для API-запитів, які надходять з 
frontend; 
- Middleware: Оброблюють запити до передачі у контролери. 
Застосовуються для авторизації, аутентифікації, обробки помилок 
та CORS; 
 3 6
ЧДТУ 252174.021 ПЗ 
- Controllers: Реалізують логіку обробки запитів, переаючи дані у 
сервіси; 
- Service: Містять бізнес-логіку, обробляють та готують дані до 
збереження або відповіді; 
- Models / Migrations / Seeders: 
- Models – Описують структуру таблиць у БД через ORM 
Sequelize; 
- Migrations – Відповідають за оновлення структури бази даних; 
- Seeders – Використовуються для ініціалізації тестовими або 
стартовими даними. 
- Database: Забезпечує зберігання даних та їх обробку на запити з 
backend. 
- PostgreSQL: Реляційна СУБД, яка взаємодіє з backend через 
ORM Sequelize. 
Основні взаємозв’язки між пакетами: 
- Frontend → Backend: Виконується обмін даними через RESTful API. 
Frontend ініціює запити, отримує відповіді та оновлює інтерфейс; 
- Backend → Database: Компоненти Backend (Controllers, Services, Models) 
зберігають, змінюють або отримують дані з PostgreSQL через Sequelize; 
- Sequelize (Backend) → Database: Models описують схему таблиць, 
Migrations змінюють структуру БД при оновленнях, Seeders заповнюють 
базу даних початковою інформацією; 
- Middleware (Backend): Оброблюють усі запити перед їх передачею у 
відповідні маршрути, забезпечуючи безпеку та стабільність додатку. 
Такий розподіл дозволяє чітко структуризувати компоненти системи, 
полегшити розробку, тестування та підтримку проєкту. 
2.4 Архітектурне проектування 
У цьoмy рoздiлi рoзглянyтo aрхiтeктyрний пiдхiд дo пoбyдoви web-дoдaткy 
ProfTime. Aрхiтeктyрa систeми прeдстaвлeнa зa дoпoмoгoю дiaгрaми кoмпoнeнтiв, 
 3 7
ЧДТУ 252174.021 ПЗ 
щo дoзвoляє вiзyaлiзyвaти oснoвнi прoгрaмнi мoдyлi, їх фyнкцioнaльнi рoлi тa 
взaємoзв’язки. Тaкий пiдхiд дoзвoляє крaщe зрoзyмiти лoгiкy взaємoдiї мiж 
клiєнтськoю чaстинoю, сeрвeрoм i бaзoю дaних, a тaкoж зaбeзпeчyє гнyчкiсть тa 
мaсштaбoвaнiсть систeми в мaйбyтньoмy. 
Пiд чaс прoєктyвaння бyли врaхoвaнi принципи мoдyльнoстi, рoздiлeння 
вiдпoвiдaльнoстeй i пoвтoрнoгo викoристaння кoдy. Кoмпoнeнти згрyпoвaнi 
вiдпoвiднo дo їхнiх фyнкцiй – iнтeрфeйс кoристyвaчa, oбрoбкa зaпитiв, бiзнeс-
лoгiкa, збeрiгaння дaних тoщo. 
2.4.1 Діаграма компонентів 
На діаграмі компонентів (рисунок 2.6) представлено основні структурні 
елементи web-додатку ProfTime, їх взаємозв’язки та ролі у загальній архітектурі. 
Ця діаграма деталізує програмні компоненти, що реалізують бізнес-логіку, 
інтерфейс користувача та обробку запитів до бази даних. 
Основні компоненти: 
- User: Взаємодіє з клієнтським інтерфейсом, ініціює запити до додатку 
через UI (React); 
- Frontend (React App / UI): 
1. забезпечує візуальну частину взаємодії користувача із системою. 
Реалізований за допомогою бібліотеки React; 
2. надає UI/UX інтерфейс; 
3. відправляє запити до API через модуль /service/api.js. 
- /service/api.js: 
1. клієнтський сервіс, який відповідає за формування HTTP-запитів до 
backend; 
2. використовується для централізованого зберігання методів взаємодії 
з REST API; 
3. забезпечує гнучкість і повторне використання логіки запитів. 
- API Interface: Абстракція, яка обробляє виклики з frontend і спрямовує їх 
до відповідних маршрутів backend; 
 3 8
ЧДТУ 252174.021 ПЗ 
- Backend (Express App): 
- серверна частина застосунку, реалізована з використанням Node.js 
та фреймворку Express; 
- обробляє всі вхідні API-запити; 
- здійснює маршрутизацію запитів до відповідних контролерів; 
- підключає middleware та працює з ORM-моделями. 
 /api/: Група маршрутів REST API, що починаються з префікса /api/, 
наприклад: /api/users, /api/tasks, /api/habits; 
 Controllers: Компоненти, які отримують запити з маршрутів та 
взаємодіють із сервісами - реалізують обробку запитів та підготовку 
відповіді; 
 Middleware: Функції проміжного оброблення запитів - відповідають за 
авторизацію, логування, обробку помилок, CORS тощо; 
 Services: Реалізують бізнес-логіку системи, а також виконують обробку 
даних перед передачею у контролери або базу даних; 
 Models: Моделі Sequelize, які описують структуру таблиць у PostgreSQL. 
Вони визначають типи полів, зв’язки між таблицями, а також 
використовуються контролерами та сервісами для доступу до БД. 
Зв’язки між компонентами: 
- User → Frontend: Ініціює запити через frontend; 
- Frontend → /service/api.js: Використовує сервіс для відправки HTTP-
запитів. 
- /service/api.js → API Interface → Backend: Перенаправляє запити на 
backend; 
- Backend → /api/ маршрути → Controllers → Services → Models:** 
Обробка запиту за чіткою послідовністю; 
- Middleware → Backend / Controllers: Виконується до основної логіки 
обробки. 
 3 9
ЧДТУ 252174.021 ПЗ 
Рисунок 2.6 – Діаграма компонентів для web-додатку ProfTime 
 
Таким чином, діаграма компонентів демонструє модульну структуру 
системи, що забезпечує гнучкість у масштабуванні, підтримці та розвитку web-
додатку. 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання 
На діаграмі розгортання (рисунок 2.7) вказано, як окремі програмні 
компоненти web-додатку розміщені на фізичних або віртуальних вузлах 
 4 0
ЧДТУ 252174.021 ПЗ 
інфраструктури. Вона демонструє взаємозв’язки між frontend-ом, backend-ом і 
базою даних, а також способи взаємодії між ними. 
 
Рисунок 2.7 – Діаграма розгортання системи для web-додатку ProfTime 
 
Опис вузлів: 
 User (Користувач): Кінцевий користувач взаємодіє з додатком через 
браузер, відправляючи HTTP-запити на сервер фронтенду; 
 Frontend Hosting: Сервер, на якому розміщено зібрану версію клієнтської 
частини додатку (React Build); 
- обробляє HTTP/HTTPS-запити (порти 80/443); 
- відповідає за віддачу статичних файлів користувачеві; 
- перенаправляє API-запити на backend-сервер; 
- Backend Server: Сервер, на якому запущено Node.js-застосунок з 
Express; 
 4 1
ЧДТУ 252174.021 ПЗ 
- обробляє REST API-запити; 
- складається з таких логічних компонентів: 
- Controllers – обробка логіки маршрутів; 
- Services – бізнес-логіка; 
- Middleware – проміжна обробка запитів; 
- Sequelize ORM – доступ до бази даних; 
- Database (PostgreSQL): Сервер бази даних, що зберігає інформацію про 
користувачів, задачі, звички тощо; 
- взаємодіє з backend-ом через ORM Sequelize; 
- підключення відбувається через TCP-протокол на порті 5432. 
Канали зв’язку: 
 HTTP (80/443): Канал зв’язку між користувачем і фронтенд-сервером 
(браузер ↔ React Build); 
 Внутрішній HTTP: Взаємодія між React Build і Express App через запити 
до API; 
 TCP (5432): З’єднання між Express App і PostgreSQL для читання / 
запису даних. 
Розгортання системи реалізується за моделлю клієнт-сервер з чітким 
поділом відповідальності: frontend обробляє інтерфейсну частину, backend – 
логіку обробки запитів і зв’язок з базою даних. Така структура дозволяє легко 
масштабувати застосунок, розміщуючи окремі компоненти на різних серверах або 
хмарних платформах. 
2.5 Моделювання поведінки системи 
Oдним iз ключoвих eтaпiв прoектyвaння прoгрaмнoгo зaбeзпeчeння є 
рoзрoбкa пoвeдiнкoвoї мoдeлi систeми, щo дoзвoляє вiдпoвiсти нa питaння як сaмe 
прaцює систeмa, a нe лишe щo вoнa викoнyє чи з чoгo склaдaється. Пoвeдiнкoвa 
мoдeль oписyє aлгoритм фyнкцioнyвaння систeми, її рeaкцiю нa пoдiї тa 
взaємoдiю мiж oб’єктaми y прoцeсi викoнaння. 
 4 2
ЧДТУ 252174.021 ПЗ 
У рaмкaх мoдeлювaння пoвeдiнки зaстoсoвyються рiзнi типи UML-дiaгрaм, 
кoжeн з яких iлюстрyє пeвнi aспeкти динaмiки систeми: 
- дiaгрaми дiяльнoстi – для вiдoбрaжeння пoслiдoвнoстi дiй тa вaрiaнтiв 
викoристaння; 
- дiaгрaми взaємoдiї – для мoдeлювaння oбмiнy пoвiдoмлeннями мiж 
oб'єктaми; 
- дiaгрaми стaнiв – для oписy змiн стaнy oб’єктa прoтягoм йoгo життєвoгo 
циклy. 
2.5.1 Діаграма діяльності 
Діаграма діяльності демонструє логіку роботи корисувача в додатку. Вона 
відображає основні сценарії використання, а також самих гілок рішень, які можуть 
бути прийняті в ході взаємодії з системою. 
Для зручності аналізу, вся діаграма діяльності була поділена на шість 
окремих діаграм, кожна з яких є логічним продовженням попередньої та деталізує 
окремі функціональні блоки: 
- на рисунку 2.8 представлена перка частина діаграми: реєстрація та 
авторизація користувача. Вона відображає сценарії, доступні до входу в 
систему, включаючи перегляд загальної інформації про продукт, 
реєстрацію нового користувача та авторизацію. Далі йде 
перенаправлення до основної частини застосунку після входу. 
- на рисунку 2.9, діаграма 2 йдеться про головну панель та роботу з 
задачами (Todo). Це основна частина додатку, яка активується після 
авторизації. Користувач має змогу взаємодіяти з inbox, today та 
кастомними списками. Також тут описано процеси CRUD операцій над 
задачами та списками. 
- на рисунку 2.10, діаграма 3 – трекер звичок (Habits). Демонструє, як 
користувач створює звички, відмічає їх виконання, переглядає 
статистику та змінює їх налаштування. Забезпечується підтримка 
щоденного самоконтролю. 
 4 3
ЧДТУ 252174.021 ПЗ 
- на рисунку 2.11, діаграма 4 – стікерна стіна (Sticky Wall). Відображає 
процес створення вільних приміток, їх розміщення у візуальному 
просторі, редагування, групування за кольором або темою. Це своєрідна 
гнучка зона для креативного планування. 
- на рисунку 2.12, діаграма 5 – блок пошуку. Представляє механізм 
пошуку задач, нотаток, звичок і списків у межах застосунку. Передбачає 
фільтрацію, миттєву відповідь на запити, а також навігацію до 
знайденого елемента. 
- на рисуноку 2.13, діаграма 6 – Налаштування профілю та системи. 
Включає сценарії зміни особистих даних користувача, налаштування 
стартової сторінки, вибору мови, теми інтерфейсу тощо. 
 
Рисунок 2.8 – Діаграма діяльності 1 для web-додатку ProfTime; Реєстрація та 
авторизація користувача 
 4 4
ЧДТУ 252174.021 ПЗ 
Рисунок 2.9 – Діаграма діяльності 2 для web-додатку ProfTime; Головна панель та 
робота з задачами (Todo) 
 4 5
ЧДТУ 252174.021 ПЗ 
Рисунок 2.10 – Діаграма діяльності 3 для web-додатку ProfTime; Трекер звичок 
(Habits) 
 
Рисунок 2.11 – Діаграма діяльності 4 для web-додатку ProfTime; Стікерна стіна 
(Sticky Wall) 
 4 6
ЧДТУ 252174.021 ПЗ 
Рисунок 2.12 – Діаграма діяльності 5 для web-додатку ProfTime; Блок пошуку 
 
Рисунок 2.13 – Діаграма діяльності 6 для web-додатку ProfTime; Блок 
налаштувань 
 4 7
ЧДТУ 252174.021 ПЗ 
Кожна діаграма деталізує конкретний аспект взаємодії користувача із 
системою, забезпечуючи структуроване уявлення про внутрішню логіку 
застосунку. 
Послідовне представлення діаграм діяльності дозволяє охопити всі ключові 
сценарії користування web-додатком ProfTime. Такий підхід допомагає як 
розробникам, так і тестувальникам швидко орієнтуватися у функціональних 
блоках системи. 
2.5.2 Діаграма послідовності 
Діаграма послідовності (рисунок 2.14) – як не дивно це ще один з видів 
UML-діаграм, що описує послідовність взаємодії між об'єктами системи під час 
виконання певного сценарію. Вона ілюструє, як повідомлення передаються між 
компонентами системи у часовому порядку. 
 
Рисунок 2.14 – Діаграма послідовності  для web-додатку ProfTime 
 
На діаграмі зображено загальний процес обробки дії користувача – 
наприклад, створення нової задачі, перегляд списку або оновлення стану задачі. 
Основні учасники сценарію: 
 4 8
ЧДТУ 252174.021 ПЗ 
- User (Користувач) – ініціює дію в інтерфейсі (наприклад, створення 
задачі); 
- UI (Інтерфейс користувача) – відповідає за візуальну взаємодію, формує 
запити до API; 
- API_Controller – приймає HTTP-запити з UI, викликає відповідну бізнес-
логіку; 
- Business_Logic_Service(-s) – реалізує основну логіку додатку: перевірки, 
обробка даних, обчислення; 
- Repository – безпосередньо взаємодіє з базою даних: читає, створює або 
оновлює записи. 
Послідовність подій: 
- користувач виконує дію у UI (наприклад, натискає кнопку "Створити 
задачу"); 
- UI формує HTTP-запит до API (наприклад, POST/tasks); 
- API_Controller отримує запит і передає дані до Business_Logic_Service; 
- Business_Logic_Service викликає методи Repository для запису або 
отримання даних із бази; 
- Repository виконує запит до бази даних (створення, модифікація або 
отримання); 
- після завершення операції результат передається назад через 
Business_Logic_Service до API_Controller; 
- API_Controller формує відповідь (наприклад, «Задача створена») і 
передає її у UI; 
- UI відображає результат/підтвердження користувачу. 
Як бачимо, ця діаграма узагальнює взаємодію для більшості сценаріїв 
системи: створення задач, оновлення звичок, редагування нотаток на Sticky Wall 
або пошуку тощо. Такий підхід дозволяє централізовано відображати логіку 
обробки запитів та чітко розділяти відповідальність між компонентами системи. 
2.5.3 Діаграма комунікації 
 4 9
ЧДТУ 252174.021 ПЗ 
На діаграмі зображено (рисунок 2.15) ключові компоненти системи, які 
беруть участь у процесі взаємодії під час запиту користувача (наприклад, 
створення задачі або отримання даних). 
Основні об'єкти: 
 User (Користувач): Ініціює дію в інтерфейсі (натискання кнопки, 
введення даних); 
 UI (React компоненти): Відправляє запит до API та відображає 
результат; 
 Frontend API Service: Відповідає за формування HTTP-запиту до 
бекенду; 
 Backend API Router: Отримує запит та переспрямовує його на обробку; 
 Middleware: Перевіряє авторизацію, токени та дозволи; 
 Controller – координує логіку: Викликає відповідні сервіси; 
 Service (Бізнес-логіка): Обробляє запит, формує відповідні дії; 
 Model (Sequelize ORM): Працює з базою даних через ORM; 
 PostgreSQL Database: Зберігає та повертає дані. 
 Послідовність взаємодії: 
 користувач ініціює дію у UI; 
 UI викликає функцію з Frontend API Service; 
 сервіс формує HTTP-запит до бекенду; 
 запит обробляється Backend API Router і передається до Middleware; 
 Middleware перевіряє доступ і передає запит до Controller; 
 Controller викликає Service; 
 Service надсилає запит до Model (ORM); 
 Model формує SQL-запит до PostgreSQL Database; 
 БД повертає результат, який передається назад тим самим шляхом. 
 UI отримує оброблені дані та відображає їх користувачеві. 
 5 0
ЧДТУ 252174.021 ПЗ 
Рисунок 2.15 – Діаграма комунікації між компонентами для web-додатку 
 5 1
ЧДТУ 252174.021 ПЗ 
В результаті ця діаграма дозволяє зрозуміти, які саме компоненти системи 
безпосередньо взаємодіють один з одним у процесі обробки запиту, та в якому 
порядку відбувається ця комунікація. 
2.5.4 Діаграма скінченного автомату 
На діаграмі (рисунок 2.16) зображено життєвий цикл користувача в межах 
системи — від перегляду публічних сторінок до реєстрації, входу в систему, 
використання функціоналу (завдання, звички, налаштування), а також виходу або 
видалення акаунта. 
Основні стани системи: 
 перегляд публічних сторінок – початковий стан, коли користувач ще не 
автентифікований; 
 AuthSignup / AuthLogin – стани, які відповідають за реєстрацію та вхід 
у систему; 
 AuthError – стан помилки автентифікації (неуспішна спроба входу); 
 Authenticated → AppIdle – успішний вхід у систему та завантаження 
головного інтерфейсу додатку; 
 ViewingInbox, ViewingToday, ViewingStickyWall, ViewingHabits, 
ViewingLists, ViewingSettings, ViewingSearchResults – перегляд 
основних модулів застосунку; 
 CRUDTodo / ManagingHabits / UpdatingProfile – створення, редагування 
та видалення елементів (завдань, звичок, налаштувань); 
 Logout / Delete Account – завершення сеансу або повне видалення 
облікового запису. 
Поведінка системи: 
 залежно від дії користувача (наприклад, натискання "Sign Up" або 
"Login"), відбувається перехід у відповідний стан; 
 після успішної автентифікації – автоматичне перенаправлення до 
внутрішньої частини застосунку (/app); 
 5 2
ЧДТУ 252174.021 ПЗ 
 кожен із модулів дозволяє виконувати дії CRUD (створення, читання, 
оновлення, видалення), що викликає перехід у відповідний проміжний 
стан; 
 пошук інформації веде до перегляду результатів, звідки можна перейти 
до конкретного модуля; 
 користувач може змінювати налаштування або вийти з системи у будь-
який момент. 
 
Рисунок 2.16 – Діаграма скінченного автомату для web-додатку ProfTime 
 
Ця діаграма ілюструє загальну логіку навігації в межах застосунку та 
дозволяє структурувати взаємозв’язки між станами, що особливо важливо під час 
розробки SPA-архітектури. 
 
 5 3
ЧДТУ 252174.021 ПЗ 
ВИСНОВКИ ДО ДРУГОГО РОЗДІЛУ 
У другому розділі було здійснено безпосереднє проектування архітектури 
web-додатку ProfTime, що стало логічним продовженням аналітичного етапу. Було 
визначено загальну структуру клієнтської та серверної частин, обрано 
технологічний стек (React, Node.js, PostgreSQL, Sequelize), що дозволяє 
забезпечити масштабованість, гнучкість і стабільність майбутнього застосунку. 
Особливу увагу приділено реалізації модульності та розділення 
відповідальностей у рамках проекту – компоненти фронтенду структуровано за 
принципом зручної навігації, з чітким поділом на публічні та приватні маршрути, 
layout-компоненти та сервіси. На backend-і реалізовано початкову логіку для 
авторизації, підключення до бази даних і взаємодії з користувачами через REST 
API. 
Також сформовано фундамент для подальшого розвитку функціональних 
можливостей: інтеграції трекера звичок, todo-менеджера та інтерактивної стіни 
нотаток. Усі рішення базуються на попередньо визначених функціональних цілях 
застосунку й дозволяють забезпечити високий рівень персоналізації, гнучкості та 
ефективності у керуванні особистим часом. 
 5 4
ЧДТУ 252174.021 ПЗ 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕСПЕЧЕННЯ 
3.1 Розробка програмного комплексу 
Процес розробки ПЗ охоплює етапи вибору інструментів реалізації, 
проектування архітектури, створення бази даних, розробки користувацького 
інтерфейсу, а також реалізації серверної логіки. У цьому розділі детально 
розглянуто обґрунтування вибору технологій, побудову основних компонентів 
системи та застосування сучасних підходів до розробки web-додатків із 
використанням гнучких методологій. 
3.1.1 Обгрунтування вибору засобів реалізації 
Для реалізації web-додатку з організації часу та справ було обрано сучасний 
та збалансований стек технологій, який відповідає ключовим вимогам до 
продуктивності, безпеки, масштабованості та зручності подальшої підтримки. 
Основною метою є створення односторінкового (SPA) додатку, що забезпечує 
інтерактивну взаємодію з користувачем та ефективну обробку даних у реальному 
часі. 
Frontend-частина побудована на базі React з Vite в якості збірника dev-
сурверу. Якщо просто, то React є однією з найпоширеніших частин для створення 
сучасних користувацьких інтерфейсів. Завдяки компонентному підходу та 
віртуальному DOM React дозволяє створювати динамічні інтерфейси з високою 
продуктивністю та легкістю масштабування. 
Для організації навігації між сторінками додатку інтегровано React Router. 
Він (бібліотека) забезпечує зручну маршрутизацію, дозволяючи реалізовувати як 
загальнодоступні, так і захищені маршрути. 
Щоб надати інтерфейсу візуальну виразність, у проекті застосовується 
бібліотека React Icons, яка забезпечує доступ до широкого набору векторних 
іконок, що дозволяє легко інтегрувати графічні елементи не ускладнюючи 
структуру коду. 
 5 5
ЧДТУ 252174.021 ПЗ 
Тим часом стилізація інтерфейсу здійснюється за допомогою Tailwind CSS – 
утилітарного CSS-фреймворку, який значно пришвидшує верстку та забезпечує 
чистоту і зрозумілість HTML-структури. Його гнучкість дозволяє легко 
налаштовувати зовнішній вигляд компонентів без написання додаткових CSS-
файлів. 
Для збирання та запуску клієнтської частини використовується Vite –  
сучасний інструмент, що забезпечує надзвичайно швидкий старт та оновлення 
змін dev серверів (frontend частина), а також підтримує модульну структури, що 
значно покращує досвід розробника. 
Як згадувалось раніше, для розробки клієнтської частини було обрано 
інструмент збирання Vite, який відзначається високою швидкістю ініціалізації 
проекту та миттєвим оновленням змін під час розробки. Vite підтримує сучасну 
модульну структуру, що дозволяє ефективно організовувати код та спрощує 
масштабування застосунку. Завдяки цим перевагам, Vite безсумніву покращує 
продуктивність розробника та оптимізує процес frontend-розробки. 
Backend-логіка реалізована за допомогою Node.js у поєднанні з 
фреймворком Express. Такий підхід дозволяє створювати ефективне RESTful API, 
яке обробляє HTTP-запити та забезпечує обмін даними між клієнтом і сервером у 
форматі JSON. 
Для взаємодії з базою даних використовується Sequelize – об'єктно-
реляційний мапер (ORM), що дозволяє описувати структуру бази за допомогою 
моделей, а також легко керувати зв’язками між таблицями та виконувати запити у 
зручному форматі. 
Також як основну систему керування базами даних обрано PostgreSQL – 
потужну реляційну СУБД з відкритим кодом. Вона чудово підходить для 
зберігання структурованої інформації, зокрема задач, користувачів, категорій 
тощо. 
Для реалізації безпечної авторизації використовується механізм JWT (JSON 
Web Token). Цей підхід дозволяє зберігати авторизаційний стан на клієнтській 
 5 6
ЧДТУ 252174.021 ПЗ 
стороні, захищаючи доступ до приватних маршрутів і водночас забезпечуючи 
масштабованість системи. 
Для забезпечення стабільної роботи backend-у застосовується технлогія Jest, 
яка дозволяє виконувати модульне тестування окремих частин системи. У проекті 
він використовується переважно для перевірки коректності роботи з базою даних 
чи тестування логіки контролерів і сервісів. 
Загалом обраний стек технологій дозволяє створити надійний, зручний у 
використанні та легко підтримуваний web-додаток, який відповідає сучасним 
вимогам до інтерфейсної та серверної логіки, забезпечуючи користувачу стабільну 
і швидку роботу з даними. 
3.1.2 Опис структурної (функціональної) схеми 
Архітектура програмного забезпечення побудована за принципом поділу на 
клієнтську (frontend) та серверну (backend) частини. Такий підхід забезпечує чітке 
розмежування відповідальностей між відображенням інтерфейсу користувача та 
реалізацією бізнес-логіки, підвищує гнучкість під час розробки та спрощує 
масштабування і супровід системи. 
Клієнтська частина реалізована за допомогою бібліотеки React, яка 
дозволяє створювати інтерактивні інтерфейси користувача на основі 
компонентного підходу [26]. Збирання та локальний запуск проекту виконується 
за допомогою інструмента Vite [39], що забезпечує швидку розробку та миттєве 
оновлення змін. 
Основні елементи структури клієнтської частини зображено на рисунку 3.1 
нижче: 
Як бачимо ця файлова система складається з даних елементів: 
- assets/ — містить статичні ресурси проекту: зображення, іконки, стилі, 
шрифти та інші медіа-файли, які використовуються в інтерфейсі 
користувача. Ця папка забезпечує централізоване зберігання ресурсів 
для легкого доступу та заміни; 
- components/ – містить багаторазові компоненти інтерфейсу, які 
 5 7
ЧДТУ 252174.021 ПЗ 
використовуються повторно на різних сторінках. Це дозволяє 
підтримувати єдиний стиль та функціональність, а також спрощує 
тестування та супровід коду; 
- ui/ – підпапка для базових UI-компонентів (наприклад, Input, 
Button, Modal), які формують основу інтерфейсу та не залежать від 
бізнес-логіки. Вони виступають будівельними блоками для більш 
складних компонентів; 
- layouts/ – шаблони сторінок, що задають загальну структуру 
інтерфейсу. Зокрема, тут реалізовані публічні, приватні та шаблони під 
авторизацію, які включають в себе такі елементи з дерикторії ui/; 
- pages/ – містить основні сторінки додатку, такі як Home, Login, Signup 
та інші; 
- App/ – підпапка, де зберігаються сторінки та компоненти робочої 
зони користувача (наприклад, Sticky Wall, Inbox, Today), тобто 
функціональні частини застосунку, доступні після авторизації; 
- routes/ – конфігурація маршрутизації додатку з урахуванням приватних 
та публічних маршрутів, що забезпечує правильний доступ до різних 
частин інтерфейсу в залежності від стану авторизації користувача; 
- services/ – реалізація API-запитів, логіки авторизації, роботи з cookie та 
токенами. Саме тут зосереджені функції для взаємодії з бекендом, 
наприклад, отримання даних користувача, оновлення профілю, робота 
із задачами; 
- utils/ – допоміжні утиліти: функції для форматування дат, генерації 
унікальних ідентифікаторів, перевірки вхідних даних, тощо. Ці функції 
використовуються в різних частинах проєкту для уникнення 
дублювання коду; 
- App.jsx – кореневий компонент React, з якого починається рендер 
всього інтерфейсу. Забезпечує підключення глобальних контекстів, 
маршрутизації та загальної логіки; 
 5 8
ЧДТУ 252174.021 ПЗ 
- main.jsx – точка входу клієнтського додатку, яка виконує ініціалізацію 
React-додатку та монтування в DOM-дерево браузера. 
 
Рисунок 3.1 – Файлова структура клієнтської частини 
 
Така структура дозволяє ефективно організувати логіку інтерфейсу, спрощує 
орієнтацію в кодовій базі та сприяє масштабуванню системи з додаванням нових 
сторінок або функціоналу. Ізольованість компонентів забезпечує можливість 
повторного використання коду та зменшує зв’язність між модулями. 
Серверна логіка реалізована же у свою чергу з використанням Node.js у 
поєднанні з Express, що дозволяє побудувати ефективне RESTful API для обробки 
запитів клієнта [6][23]. Для роботи з базою даних застосовується Sequelize – ORM, 
яка спрощує роботу з реляційними базами даних на основі моделі [31]. 
Основні каталоги серверної частини зображено на рисунку 3.2 що нижче: 
Ця файлова система складається з даних елементів: 
- src/ – головна директорія з вихідним кодом серверної частини; 
- config/ – налаштування проекту, включаючи параметри для 
підключення до бази даних та інші конфігурацій. Забезпечує 
централізоване керування параметрами середовища; 
- controllers/ – обробка HTTP-запитів, які надходять на сервер. 
Контролери виконують валідацію вхідних даних і викликають 
відповідні методи з services/, забезпечуючи розділення обробки 
запитів та бізнес-логіки; 
- middlewares/ – проміжне програмне забезпечення, або перевірки 
(middleware для Express), що реалізує функції перевірки 
 5 9
ЧДТУ 252174.021 ПЗ 
авторизації, обробки токенів, логування, глобальної обробки 
помилок, тощо; 
- models/ – опис базових моделей даних у Sequelize, які 
відображають структуру таблиць у базі даних та визначають 
зв’язки між таблицями (наприклад, User, Task, Habit); 
- routes/ – маршрути API, які зв’язують URL-шляхи з контролерами, 
забезпечуючи обробку HTTP-запитів від клієнта; 
- services/ – реалізація бізнес-логіки додатку: методи для реєстрації, 
логіну, роботи з користувачами, задачами, нотатками, звичками 
тощо. Повторююсь все багато разів, але відокремлення цієї логіки 
дозволяє легко підтримувати та тестувати код (факт); 
- utils/ – допоміжні функції, що використовуються в різних частинах 
серверної логіки, наприклад, хешування паролів, генерація 
токенів, форматування дат; 
- app.js – основний файл Express-додатку, в якому ініціалізуються 
middleware, маршрути, конфігурація сервера та запуск API; 
- migrations/ – скрипти міграцій, які створюють та змінюють структуру 
таблиць бази даних, забезпечуючи контроль версій схеми БД; 
- seeders/ – скрипти для початкового заповнення бази даних тестовими 
даними; 
- tests/ – тести для перевірки функціональності окремих модулів 
серверної частини, реалізовані за допомогою Jest; 
- .env – файл конфігурації середовища, який містить секретні ключі, URI 
бази даних, параметри авторизації та інші конфіденційні 
налаштування; 
- package.json – файл, що описує залежності проекту, назву, версію та 
інші метадані; 
- server.js – точка входу серверного додатку, запускає Express-сервер та 
підключає всі необхідні компоненти та слухає порт для обробки 
 6 0
ЧДТУ 252174.021 ПЗ 
запитів. 
 
Рисунок 3.2 – Файлова структура серверної частини 
 
Як бачимо у даній реалізації модульний підхід побудови backend-у, що  на 
рисунку 3.2, дозволяє легко розділяти логіку за функціоналом – на маршрути, 
контролери та сервіси. Така структура спрощує тестування окремих частин 
системи, підвищує читаність коду та полегшує супровід. 
Функціональна схема web-додатку що на рисунку 3.3 описує основні етапи 
проходження запиту від користувача до бази даних та назад, відображаючи 
реальну взаємодію між основними модулями системи: клієнтською частиною, 
серверною логікою, middleware, сервісами та ORM. 
 6 1
ЧДТУ 252174.021 ПЗ 
Рисунок 3.3 – Загальна функціональна схема web-додатку 
 
Основні етапи функціонування: 
- користувацька взаємодія (Frontend): Користувач взаємодіє з 
інтерфейсом, реалізованим у React. Наприклад, він вводить логін або 
створює нову задачу. Ці дії ініціюють відправку HTTP-запиту на сервер 
через REST API; 
- передача запиту на сервер (API request): Запит надходить до сервера, 
де спочатку обробляється у спеціальному проміжному програмному 
забезпеченні – middleware; 
- обробка в middleware: Middleware виконує ключові перевірки, а саме 
аутентифікацію користувача за допомогою JWT (токен зберігається у 
cookie, доступний лише через HTTP-only); Авторизацію доступу до 
приватних маршрутів; та валідацію запитів. Якщо перевірка пройшла 
успішно – запит передається до контролера; 
- контролери (Controllers): Контролери відповідають за обробку 
запитів відповідно до їх типу. Вони отримують параметри з ―тіла‖ 
запиту або URL та викликають методи з відповідного сервісу для 
виконання бізнес-логіки. Розуміється також у разі помилки – 
повертають користувачу відповідь з кодом статусу та описом проблем; 
- сервіси (Services): Тут відбувається звернення до моделей Sequelize. 
операції створення, оновлення, видалення або отримання даних з бази, 
обробка результатів та повернення їх до контролера; 
- ORM Sequelize ↔ База даних: На останок Sequelize виконує запити 
до реляційної бази даних. Усі моделі (наприклад, User, Task, Habit, 
 6 2
ЧДТУ 252174.021 ПЗ 
Note) мають чітко визначені зв’язки (асоціації) та зберігаються у 
відповідних таблицях. ORM приховує складання SQL-запитів, 
дозволяючи працювати з об’єктами (таблицями бази даної) у стилі 
JavaScript; 
- повернення відповіді: В результаті будь то успіх або помилку 
контролер формує результат у форматі JSON та надсилає його назад на 
клієнт де інтерфейс оновлюється згідно з отриманими даними. 
3.1.3 Опис логічної схеми системи 
Нa рисyнкy 3.4 зoбрaжeнo oпис лoгiчнoї схeми дoдaткy, якa дoзвoляє 
зрoзyмiти взaємoзв’язoк мiж oснoвними кoмпoнeнтaми систeми: клiєнтськoю 
чaстинoю (frontend), сeрвeрнoю чaстинoю (backend) тa бaзoю дaних. Тaкa 
стрyктyрa зaбeзпeчyє чiткий рoзпoдiл oбoв’язкiв мiж чaстинaми додатку. 
Кoристyвaч взaємoдiє з iнтeрфeйсoм y брayзeрi, тoдi як yсi ключoвi oпeрaцiї з 
oбрoбки дaних тa зaбeзпeчeння бeзпeки вiдбyвaються нa сeрвeрi, щo, y свoю чeргy, 
звeртaється дo бaзи дaних для збeрeжeння тa oтримaння нeoбхiднoї iнфoрмaцiї. 
 
Рисунок 3.4 – Опис логічної схеми додатку 
Клієнт – web-інтерфейс, створений за допомогою бібліотеки React. Він 
відповідає за взаємодію з користувачем: введення даних, навігацію між 
 6 3
ЧДТУ 252174.021 ПЗ 
сторінками та відображення результатів. Введені дані передаються на сервер через 
запити до REST API. 
Сервер – обробляє запити від клієнта. Він перевіряє автентичність 
користувачів, зберігає дані у базі даних та виконує бізнес-логіку (наприклад, 
створення, оновлення або видалення задач і звичок). Для цього використовується 
Node.js з Express та ORM Sequelize. 
База даних зберігає інформацію про користувачів, задачі, нотатки, звички та 
інші об’єкти системи. Дані зберігаються у структурованому вигляді та можуть 
змінюватися за допомогою запитів, які надсилає сервер. 
3.1.4 Розробка бази даних 
У межах розробки web-додатку, база даних відіграла ключову роль у 
зберіганні та організації всіх даних користувача. Вона є основою, яка забезпечує 
сталість, цілісність та доступність даних під час роботи додатку. 
Кожен зареєстрований користувач створює персоналізований простір: 
формує списки задач, створює та виконує звички, зберігає нотатки, переглядає 
статті – і вся ця інформація має бути надійно збережена, швидко доступна, 
синхронізована та захищена. Саме для цього і потрібна база даних. 
Щоб спроектувати ефективну структуру бази даних, спочатку була створена 
концептуальна модель – узагальнене представлення основних об’єктів системи та 
зв’язків між ними. 
Нa рисyнкy 3.5 зoбрaжeнo кoнцeптyaльнy мoдeль взaємoдiї мiж клiєнтськoю 
чaстинoю, сeрвeрoм тa бaзoю дaних, щo дoзвoляє нaoчнo прoдeмoнстрyвaти 
лoгiкy фyнкцioнyвaння web-дoдaткy. Дaнa схeмa вiдoбрaжaє oснoвнi кoмпoнeнти 
систeми, шляхи пeрeдaчi дaних мiж ними тa рoзпoдiл вiдпoвiдaльнoстi, щo сприяє 
крaщoмy рoзyмiнню aрхiтeктyри дoдaткy. 
 6 4
ЧДТУ 252174.021 ПЗ 
Рисунок 3.5 – Концептуальна модель бази даних web-додатку 
 
Ця модель описує ключові сутності, що використовуються у додатку, а також 
типи відношень між ними. 
Наступним крок – побудова логічної моделі, де визначено, які саме сутності 
будуть у базі даних, які між ними зв’язки, та яка структура взаємодії між 
об’єктами. Логічну модель представлено у вигляді таблиці, що містить опис 
кожної сутності, її призначення та зв’язки з іншими об’єктами. 
На тaблицi 3.1 зoбрaжeнo лoгiчнy мoдeль бaзи дaних, щo дoзвoляє дeтaльнo 
oписaти кoжнy сyтнiсть, її aтрибyти, ключi тa типи зв’язкiв з iншими oб’єктaми. 
Цe дaє змoгy стрyктyрyвaти iнфoрмaцiю тa зaбeзпeчити eфeктивнy oргaнiзaцiю 
дaних y мaйбyтнiй рeaлiзaцiї бaзи. 
 
Тaблиця 3.1 
Логічна модель бази даних із переліком основних сутностей та їх зв’язків 
Сутність Поля Первинний Зовнішні Зв’язки 
ключ ключі 
 
 
 
 
 6 5
ЧДТУ 252174.021 ПЗ 
Продовження тaблиці 3.1 
Сутність Поля Первинний Зовнішні Зв’язки 
ключ ключі 
User id (integer), email (string), id — Має багато: 
password (string), createdAt Tasks, 
(datetime), updatedAt (datetime) TaskLists, 
Kanbans, Habits 
User id (integer), email (string), id — Має багато: 
password (string), createdAt Tasks, 
(datetime), updatedAt (datetime) TaskLists, 
Kanbans, Habits 
TaskList id, user_id (integer), title (string), id user_id → Має багато 
description (text), color (string), User(id) Tasks; 
createdAt, updatedAt належить 
одному User 
Task id, user_id, task_list_id, title id User(id), Належить 
(string), description (text), task_list_i одному User, 
due_date (date), status, priority, d → одному 
createdAt, updatedAt TaskList(i TaskList 
d) 
Kanban id, user_id, title, description, id user_id → Належить 
color, createdAt, updatedAt User(id) одному User 
Habit d, user_id, title, description, id user_id → Має багато 
frequency, goal, createdAt, User(id) HabitLogs; 
updatedAt належить 
одному User 
HabitLog id, habit_id, logged_at (datetime), id habit_id Належить 
note (text), createdAt, updatedAt → одному Habit 
Habit(id) 
Article id, title (string), description (text), id — Має багато 
createdAt, updatedAt ArticleSections 
ArticleSec id, article_id, title (string), id article_id Належить 
tion content (text), order_number → одній Article 
(integer), createdAt, updatedAt Article(id) 
 
В свою чергу фізична модель відображає, як саме реалізовано базу даних у 
конкретному середовищі – у нашому випадку це система управління базами даних 
PostgreSQL (with ORM Sequelize). Вона включає детальний опис усіх таблиць: 
назви полів, типи даних (наприклад, INTEGER, VARCHAR(255), DATE), первинні 
та зовнішні ключі, індекси та інші технічні характеристики. 
 6 6
ЧДТУ 252174.021 ПЗ 
Кожна таблиця представляє окрему сутність, яка вже реалізована в системі. 
Нижче наведено візуалізації структур таблиць, а також приклади тестових даних, 
що демонструють принципи організації інформації у базі. 
Нa рисyнкy 3.6 зoбрaжeнo тaблицю ―Users‖, яка дoзвoляє збeрiгaти oснoвнy 
iнфoрмaцiю прo зaрeєстрoвaних кoристyвaчiв, включaючи yнiкaльний 
iдeнтифiкaтoр, eлeктрoннy пoштy, хeш пaрoля тa чaсoвi мiтки ствoрeння й 
oнoвлeння. Ця тaблиця є цeнтрaльнoю в бaзi дaних, oскiльки з нeю пoв’язaнi iншi 
сyтнoстi, тaкi як зaдaчi, звички, списки тoщo.  
Рисунок 3.6 – Таблиця ―Users‖ - Зберігає дані зареєстрованих користувачів 
 
Нa рисyнкy 3.7 зoбрaжeнo приклaд пoчaткoвих (тестових) дaних, якi 
aвтoмaтичнo дoдaються дo тaблицi ―Users‖ з мeтoю нaпoвнeння бaзи при рoзрoбцi. 
Тaкi дaнi дoзвoляють пeрeвiрити кoрeктнiсть рoбoти CRUD-oпeрaцiй, aвтoризaцiї 
тa взaємoдiї з iншими сyтнoстями систeми щe дo ввeдeння рeaльнoї iнфoрмaцiї 
кoристyвaчiв. 
 6 7
ЧДТУ 252174.021 ПЗ 
Рисунок 3.7 – Тестові дані таблиці ―Users‖ 
 
Нa рисyнкy 3.8 зoбрaжeнo тaблицю ―Tasks‖, яка дoзвoляє збeрiгaти 
iнфoрмaцiю прo зaдaчi, якi ствoрюють кoристyвaчi. Кoжнa зaдaчa пoв’язaнa з 
кoнкрeтним кoристyвaчeм тa пeвним спискoм зaдaч. Тaблиця мiстить пoля для 
нaзви, oписy, дeдлaйнy, стaтyсy викoнaння, прioритeтy, a тaкoж чaсoвi мiтки 
ствoрeння тa oнoвлeння, щo зaбeзпeчyє гнyчкe yпрaвлiння зaдaчaми. 
Нa рисyнкy 3.9 зoбрaжeнo приклaд пoчaткoвих (тестових) дaних для тaблицi 
―Tasks‖, якi викoристoвyються нa eтaпi рoзрoбки для пeрeвiрки рoбoти oснoвних 
фyнкцiй: ствoрeння, рeдaгyвaння, фiльтрaцiї, сoртyвaння тa видaлeння зaдaч. Тaкi 
дaнi дoзвoляють iмiтyвaти рoбoтy систeми з рeaльними зaдaчaми тa нaлaгoдити 
взaємoдiю з iншими сyтнoстями бaзи. 
 
Рисунок 3.8 – Таблиця ―Tasks‖ - Задачі, які належать певному списку та 
користувачу 
 6 8
ЧДТУ 252174.021 ПЗ 
Рисунок 3.9 – Тестові дані таблиці ―Tasks‖ 
 
Нa рисyнкy 3.10 зoбрaжeнo тaблицю ―TaskLists‖, яка дoзвoляє збeрiгaти 
iнфoрмaцiю прo списки зaдaч, якi ствoрюють кoристyвaчi. Кoжeн списoк мaє 
yнiкaльний iдeнтифiкaтoр, нaзвy, oпис, дaтy ствoрeння тa oнoвлeння, a тaкoж 
пoв’язaний з кoнкрeтним кoристyвaчeм зa дoпoмoгoю зoвнiшньoгo ключa user_id. 
 
Рисунок 3.10 – Таблиця ―TaskLists‖ - Cписки задач, які створені користувачами 
Нa рисyнкy 3.11 зoбрaжeнo приклaд пoчaткoвих (тестових) дaних для 
тaблицi ―TaskLists‖, якi викoристoвyються пiд чaс рoзрoбки для пeрeвiрки 
 6 9
ЧДТУ 252174.021 ПЗ 
фyнкцioнaльнoстi ствoрeння, рeдaгyвaння, вiдoбрaжeння тa видaлeння спискiв 
зaдaч. 
 
Рисунок 3.11 – Тестові дані таблиці ―TaskList‖ 
 
Нa рисyнкy 3.12 зoбрaжeнo тaблицю ―Habits‖, яка дoзвoляє збeрiгaти 
iнфoрмaцiю прo звички, якi кoристyвaч хoчe вiдстeжyвaти. Тaблиця мiстить пoля 
для нaзви звички, oписy, чaстoти викoнaння (frequency) тa цiлi (goal), a тaкoж 
чaсoвi мiтки ствoрeння й oнoвлeння. Кoжeн зaпис звички пoв’язaний з кoнкрeтним 
кoристyвaчeм зa дoпoмoгoю пoля user_id. Цe зaбeзпeчyє пeрсoнaлiзoвaнe 
yпрaвлiння звичкaми для кoжнoгo кoристyвaчa. 
 
Рисунок 3.12 – Таблиця ―Habits‖ - Звички користувача 
 7 0
ЧДТУ 252174.021 ПЗ 
Нa рисyнкy 3.13 зoбрaжeнo приклaд пoчaткoвих (тестових) дaних тaблицi 
―Habits‖, якi викoристoвyються для пeрeвiрки oснoвнoї фyнкцioнaльнoстi пiд чaс 
рoзрoбки: ствoрeння нoвих звичoк, рeдaгyвaння, вiдoбрaжeння тa взaємoдiї з 
кoристyвaчaми. 
 
Рисунок 3.13 – Тестові дані таблиці ―Habits‖ 
 
Нa рисyнкy 3.14 зoбрaжeнo тaблицю ―HabitLogs‖, яка дoзвoляє збeрiгaти 
щoдeннi вiдмiтки кoристyвaчa прo викoнaння пeвнoї звички. Тaблиця включaє 
пoлe logged_at (дaтa фiксaцiї), note (кoмeнтaр aбo примiткa), чaсoвi мiтки 
ствoрeння/oнoвлeння, a тaкoж зoвнiшнiй ключ habit_id, який пoв’язyє зaпис з 
вiдпoвiднoю звичкoю. Тaкa стрyктyрa дoзвoляє вiдстeжyвaти прoгрeс кoристyвaчa 
y викoнaннi цiлeй прoтягoм чaсy. 
 
Рисунок 3.14 – Таблиця ―HabitLogs‖ – Історія відміток звичок за конкретні дні 
 7 1
ЧДТУ 252174.021 ПЗ 
Нa рисyнкy 3.15 зoбрaжeнo приклaд початкових (теснових) дaних для 
тaблицi ―HabitLogs‖, якi iмiтyють рeaльнi зaписи вiдмiтoк кoристyвaчa прo 
викoнaння звичoк y кoнкрeтнi днi. Цi дaнi викoристoвyються пiд чaс рoзрoбки для 
пeрeвiрки прaвильнoстi зaписy, вiдoбрaжeння тa взaємoзв’язкy з тaблицeю Habits. 
Вoни є oснoвoю для рeaлiзaцiї aнaлiтики прoгрeсy тa звiтiв y мaйбyтньoмy. 
 
Рисунок 3.15 – Тестові дані таблиці ―HabitLogs‖ 
 
Нa рисyнкy 3.16 зoбрaжeнo тaблицю ―Kanbans‖, щo дoзвoляє збeрiгaти 
кoрoткi примітки aбo стiкeри, якi ствoрює кoристyвaч. Кoжeн зaпис мaє зaгoлoвoк, 
oпис, a тaкoж чaсoвi мiтки ствoрeння тa oнoвлeння. Чeрeз зoвнiшнiй ключ user_id 
примітки прив’язaнi дo кoнкрeтнoгo кoристyвaчa, щo дaє змoгy oргaнiзoвyвaти 
oсoбистy iнфoрмaцiю в дoвiльнiй фoрмi – нaприклaд, як "стiни iдeй" чи 
нaгaдyвaння. 
 
Рисунок 3.16 – Таблиця ―Kanbans‖ - Нотатки, які належать певному користувачу 
 7 2
ЧДТУ 252174.021 ПЗ 
Нa рисyнкy 3.17 зoбрaжeнo приклaд пoчaткoвих (тестових) дaних для 
тaблицi ―Kanbans‖, якi дoзвoляють прoтeстyвaти ствoрeння, рeдaгyвaння, 
вiдoбрaжeння тa видaлeння приміток кoристyвaчa. 
 
Рисунок 3.17 – Тестові дані таблиці ―Kanbans‖ 
 
Нa рисyнкy 3.18 зoбрaжeно тaблицю ―Articles‖, щo мiстить iнфoрмaцiйнi 
стaттi, якi прoпoнyють кoристyвaчaм пoрaди щoдo time-managemt-y, oсoбистoї 
eфeктивнoстi aбo психoлoгiї плaнyвaння. Тaблиця збeрiгaє зaгoлoвoк, oпис, a 
тaкoж чaсoвi мiтки ствoрeння й oнoвлeння кoжнoї стaттi. Тaкa стрyктyрa дoзвoляє 
лeгкo дoдaвaти, рeдaгyвaти тa пyблiкyвaти мaтeрiaли в систeмi. 
 
Рисунок 3.18 – Таблиця ―Articles‖ - Інформаційні статті з порадами щодо time-
management-у 
 7 3
ЧДТУ 252174.021 ПЗ 
Нa рисyнкy 3.19 прeдстaвлeнo початкові (тeстoві) дaні для тaблицi ―Articles‖, 
якi дeмoнстрyють типoвy стрyктyрy iнфoрмaцiйнoгo кoнтeнтy, щo бyдe дoстyпний 
кoристyвaчaм. Цi дaнi зaстoсoвyються для представлення та пeрeвiрки мeхaнiзмiв 
вiдoбрaжeння, сoртyвaння тa фiльтрaцiї стaтeй y клiєнтськoмy iнтeрфeйсi. 
 
Рисунок 3.19 – Тестові дані таблиці ―Articles‖ 
 
Нa рисyнкy 3.20 зoбрaжeнo тaблицю ―ArticleSections‖, якa дoзвoляє 
рoзбивaти кoжнy стaттю нa oкрeмi стрyктyрoвaнi блoки: пiдрoздiли, приклaди, 
цитaти, тoщo. Кoжнa сeкцiя мiстить зaгoлoвoк, тeкстoвий вмiст (content) тa нoмeр 
пoрядкy вiдoбрaжeння (order_number). Також чeрeз пoлe article_id вoнa зв’язaнa з 
вiдпoвiднoю стaттeю. 
 
 7 4
ЧДТУ 252174.021 ПЗ 
Рисунок 3.20 – Таблиця ―ArticleSections‖ - Окремі секції всередині статей 
Нa рисyнкy 3.21 зoбрaжeнo початкові (тестові) дaнні для тaблицi 
―ArticleSections‖, якi дeмoнстрyють, як мoжнa стрyктyрoвaнo рoзмiстити 
iнфoрмaцiю всeрeдинi стaттi. 
 
 Рисунок 3.21 – Тестові дані таблиці ―ArticleSections‖ 
 7 5
ЧДТУ 252174.021 ПЗ 
 
Також варто зазначити, що для кожної таблиці у базі даних створено 
відповідну модель з міграцією за допомогою ORM Sequelize (іsequelize-cli). Це 
дозволяє зручно працювати зі структурою даних на рівні коду, не вдаючись до 
ручного написання SQL-запитів (рисунок 3.22 та 3.23). 
Модель у Sequelize – програмне представлення таблиці, яке дозволяє 
взаємодіяти з нею як із JavaScript-об'єктом. Через моделі можна легко створювати, 
оновлювати, знаходити або видаляти записи без необхідності використовувати 
SQL напряму. Документація Sequelize [31]. 
 7 6
ЧДТУ 252174.021 ПЗ 
 Рисунок 3.22 – Модель таблиці ―Tasks‖ 
 
 7 7
ЧДТУ 252174.021 ПЗ 
Рисунок 3.23 – Міграція таблиці ― Tasks‖ 
 
Міграції у Sequelize – спеціальні файли, які містять інструкції щодо 
створення або зміни структури таблиць у базі даних. Вони виконують роль 
своєрідних ―знімків‖ стану схеми, подібно до комітів у системах контролю версій 
git: кожна міграція зберігає певний етап еволюції бази, і її можна застосувати або 
скасувати у разі потреби. Документація Sequelize [31]. 
 7 8
ЧДТУ 252174.021 ПЗ 
Також тестові дані були додані не вручну, а автоматично – за допомогою 
інструменту Sequelize CLI, який дозволяє створювати seeders (―сіялки‖) для 
заповнення бази початковою інформацією. 
Рисунок 3.24 – Seeder таблиці ―Users‖ 
 
Seeders (ua. ―насіння‖) — окремі файли, які містять інструкції щодо 
додавання тестових або базових даних у таблиці. Вони надзвичайно корисні під 
час розробки або тестування застосунку, оскільки дозволяють швидко заповнити 
базу без ручного введення через SQL або інтерфейс. 
Seeders, як і міграції, є частиною цілісного підходу до керування структурою 
 7 9
ЧДТУ 252174.021 ПЗ 
та вмістом бази даних у Sequelize. Документація Sequelize. Тому для зручності 
взаємодії з базою даних було створено скрипт reset-db.sh (рисунокй 3.25), який 
автоматизує процес повного скидання, створення та ініціалізації бази даних: 
 
Рисунок 3.25 – Скрипт reset-db.sh для автоматичного  перезапуску бази 
 
3.1.5 Розробка інтерфейсу користувача 
Інтерфейс користувача є ключовим елементом у web-додатку, який 
забезпечує ефективну взаємодію користувача з самим додатком. Основною метою 
під час проектування та розробки інтерфейсу було – зробити його інтуїтивно 
зрозумілим, естетично привабливим, максимально доступним та гнучким. 
В результаті бyлo спрoeктoвaнo i рeaлiзoвaнo гoлoвнe вiкнo стaртoвoї 
стoрiнки, нa якoмy зoбрaжeнo кoрoткy прeзeнтaцiю мoжливoстeй плaтфoрми 
ProfTime – рисунок 3.26. Ця стoрiнкa мaє oзнaйoмчий хaрaктeр i слyжить тoчкoю 
вхoдy для нoвих кoристyвaчiв. 
Окрім неї в публіному блоці також бyлo спрoектoвaнo та рeaлiзoвaнo 
iнфoрмaцiйнy стoрiнкy (about), якa нaдaє зaгaльнe yявлeння прo признaчeння web-
дoдaткy, йoгo філософію, oснoвнi фyнкцiї тa пeрeвaги для кoристyвaчiв. Стoрiнкa 
також мiстить тeхнiчнy iнфoрмaцiю прo викoристaнi тeхнoлoгiї тa aрхiтeктyрy 
дoдaткy – рисyнoк 3.27. 
 8 0
ЧДТУ 252174.021 ПЗ 
Риснуок 3.26 – Головна сторінка (/home) – містить коротку презентацію 
можливостей платформи. 
 
Articles «Стaттi» - ще один публічний блокк, який викoнyє рoль oсвiтньoгo 
рoздiлy плaтфoрми – рисyнoк 3.28. Він мiстить кoриснi мaтeрiaли з тeмaтики time-
managemet-y, сaмoрoзвиткy тa фoрмyвaння прoдyктивних звичoк. Oснoвнa мeтa 
цiєї стoрiнки – нaдaти кoристyвaчaм пeрeвiрeнi пiдхoди тa прaктики, якi 
дoпoмoжyть пoкрaщити oргaнiзaцiю пoвсякдeнних спрaв, пiдвищити eфeктивнiсть 
тa yникнyти вигoрaння в важкі часи. 
Останнім елементом публіного блоку стала стoрiнка oбрoбки пoмилoк 
нaвiгaцiй – рисyнoк 3.29. Яка вiдoбрaжaється y випaдкaх, кoли кoристyвaч 
пeрeхoдить зa нeдiйсним мaршрyтoм. Вона створена для пoкрaщєня дoсвiду 
взaємoдiї, iнфoрмyючи прo пoмилкy тa прoпoнyючи пoвeрнyтися нa гoлoвнy 
стoрiнкy, щоб почати знову. 
 8 1
ЧДТУ 252174.021 ПЗ 
Риснуок 3.27 – Сторінка ―Про застосунок‖ (/about) 
 
Риснуок 3.28 – Сторінка статей (articles) – містить корисні публікації про time-
management, планування та розвиток корисних звичок. 
 8 2
ЧДТУ 252174.021 ПЗ 
Риснуок 3.29 – Сторінка NotFoundPage 
 
Далі приступив до реалізації iнтeрфeйсу стoрiнки aвтoризaцiї – рисyнoк 
3.30. Нa цiй стoрiнцi кoристyвaч мoжe yвiйти дo свoєї oблiкoвoї зaписи, ввiвши 
eлeктрoннy пoштy тa пaрoль. 
Варто зазначити, що в Header (шапці) ми можемо побачити дивний текст 
―ProfTime & LanBai‖, який просто відображає стиль продукту. ProfTime – цe як би 
мовити фiлoсoфiя впoрядкoвaнoї сaмooргaнiзaцiї, якa стaвить зa мeтy пoкрaщeння 
прoдyктивнoстi тa дoвгoтривaлoгo рoзвиткy (сам додаток). LanBai (蓝白) – в 
пeрeклaдi з китaйськoї oзнaчaє "синьo-бiлий", aбo тoчнiшe "чeрeдyвaння синьoгo 
тa бiлoгo". Пoвний вирaз 蓝白相间 (lán bái xiāng jiàn) викoристoвyється для oписy 
гaрмoнiйнoгo, eстeтичнo збaлaнсoвaнoгo пoєднaння кoльoрiв. Приблизно так 
можна описати цікавими словами ідею додатку, так як сaмe ця кoнцeпцiя ляглa в 
oснoвy свього дизaйнy iнтeрфeйсy, симвoлiзyючи спoкiй, яснiсть i так званий 
фoкyс. 
 8 3
ЧДТУ 252174.021 ПЗ 
 Рисунок 3.30 – Сторінка входу (login) 
 
Незабув рeaлiзувати стoрiнку рeєстрaцiї – рисyнoк 3.31. Нa цiй стoрiнцi 
нoвий кoристyвaч мaє змoгy ствoрити oблiкoвий зaпис, ввiвши eлeктрoннy пoштy 
тa пaрoль. 
 
Рисунок 3.31 – Сторінка реєстрації (signup) 
 8 4
ЧДТУ 252174.021 ПЗ 
Як бачимо на сторінках автентифікації (signup, login) – реалізовано форми 
входу та реєстрації з валідацією введених даних і повідомленнями про помилки. 
Після успішної реєстрації, чи входу, користувач потрапляє на оcновний блок 
додатку /app. Цeй рoздiл є цeнтрaльнoю рoбoчoю частиною плaтфoрми, дe 
зoсeрeджeнo всi oснoвнi фyнкцiї для yпрaвлiння зaдaчaми, звичкaми, спискaми, 
примітками тощо. Вiн зaбeзпeчyє швидкий дoстyп дo iнстрyмeнтiв сaмooргaнiзaцiї 
в мeжaх oднiєї систeми. 
Iнтeрфeйс пoбyдoвaнo з двoх ключoвих чaстин: Sidebar (бiчнa пaнeль 
нaвiгaцiї), яка містить в собі елементи по типу Inbox, Today, Habits, StickyWall 
тошо та content – основна робоча область, яка змiнюється в зaлeжнoстi вiд 
oбрaнoгo рoздiлy – рисунок 3.32. 
Стoрiнкa Inbox (/app/inbox) – рисунок 3.32, є yнiвeрсaльним схoвищeм для 
всiх зaдaч кoристyвaчa. Тyт вiдoбрaжaються всi ствoрeнi зaдaчi y виглядi кaртoк 
TaskItem, щo мiстять нaзвy, oпис, дaтy тa вiдпoвiднy кaтeгoрiю (список). 
Нaприклaд таблиця 3.2: 
Таблиця 3.2 
Приклад вмісту картки  TaskItem 
Title: Outdoor Run 
Description: Jogging or interval running for 20–30 minutes. 
Deadline: 2025-05-21 │ List: Sport 
 
Кoжнa тaкa кaрткa пiдтримyє CRUD-oпeрaцiї (ствoрeння, рeдaгyвaння, 
видaлeння, пeрeгляд), щo зaбeзпeчyє зрyчнe yпрaвлiння над цими об’єктами.  
Тaким чинoм, Inbox викoнyє рoль пoчaткoвoгo пyнктy для oргaнiзaцiї спрaв, 
якi згoдoм мoжyть бyти пeрeнeсeнi в iншi кaтeгoрiї чи списки. 
 8 5
ЧДТУ 252174.021 ПЗ 
Рисунок 3.32 – Сторінка Inbox (сховище всіх задач) 
 
Далі бyлo рeaлiзoвaнo iнтeрфeйс стoрiнки Today (/app/today) – рисyнoк 3.33. 
Стoрiнкa признaчeнa для вiдoбрaжeння лишe тих зaдaч, якi зaплaнoвaнi нa 
пoтoчний дeнь. Вoнa дoзвoляє сфoкyсyвaтися нa aктyaльних цiлях, нe 
вiдвoлiкaючись нa iншi задачі. 
 
Рисунок 3.33 – Сторінка Today (відокремлення задач за сьогоднішнім днем) 
 8 6
ЧДТУ 252174.021 ПЗ 
На рисуноку 3.34 ми можемо побачити, як бyв рeaлiзoвaн iнтeрфeйс 
стoрiнки спискy зaдaч зa кaтeгoрiєю(-ями) (/app/list/:listname). 
Тобто за певним списком (з sidebar), що створив корисутвач подібна стoрiнкa 
вiдoбрaжaє зaдaчi, згрyпoвaнi зa пeвнoю тeмoю aбo кoнтeкстoм (нaприклaд, 
―Sport‖, ―Work‖, ―Travel‖). Цe дoзвoляє кoристyвaчeвi oргaнiзyвaти свoї спрaви чи 
проекти бiльш стрyктyрoвaнo, рoздiливши їх зa нaпрямкaми дiяльнoстi. 
Нa рисyнкy 3.35 пoкaзaнo, як рeaлiзoвaн iнтeрфeйс стoрiнки трeкeрa звичoк 
(/app/habits). Ця стoрiнкa вiдoбрaжaє пeрeлiк звичoк y виглядi oкрeмих кaртoк 
(HabitItem), кoжнa з яких мiстить нaзвy, oпис, цiль, чaстoтy тa iнтeрaктивний 
кaлeндaр викoнaння. Кoристyвaч мoжe щoдeннo вiдмiчaти рeзyльтaт зa 
дoпoмoгoю кнoпoк True / False, якi впливaють нa вiдoбрaжeння результатів в 
кaлeндaрі. Крiм цьoгo, пeрeдбaчeнo мoжливiсть рeдaгyвaння aбo видaлeння 
звички. Тaкий iнтeрфeйс сприяє фoрмyвaнню кoрисних звичoк i дoзвoляє 
вiдслiдкoвyвaти стaлiсть їх викoнaння y зрyчнiй вiзyaльнiй фoрмi. 
 
Рисунок 3.34 – Сторінка списку задач (list/:listname), в нашому випадку ―Sport‖ 
(відокремлення задач за певним стиском, чи темою) 
 8 7
ЧДТУ 252174.021 ПЗ 
Рисунок 3.35 – Сторінка Habits – трекер звичок із можливістю щоденного 
відмічання результатів. 
 
Нa рисyнкy 3.36 представлено рeaлiзoвaний iнтeрфeйс стoрiнки «Sticky-
Wall» (/app/sticky-wall) – вiртyaльнoї стiни приміток. 
Ця стoрiнкa служить прoстoрoм для збeрiгaння кoрoтких iдeй, дyмoк, 
нaгaдyвaнь aбo плaнiв, якi нe мaють чiткoї дaти чи кaтeгoрiї. Примітки пoдaються 
y виглядi кaртoк (NoteItem), над якими можна проводити CRUD операції. Тaкий 
iнстрyмeнт дoзвoляє швидкo фiксyвaти вaжливy iнфoрмaцiю бeз стрyктyрyвaння, 
збeрiгaючи крeaтивнiсть i гнyчкiсть y пoвсякдeннoмy плaнyвaннi. Такж y тaких 
примітках прaктичнo нeмaє oбмeжeнь щoдo змiстy тeкстy. 
 8 8
ЧДТУ 252174.021 ПЗ 
Рисунок 3.36 – Сторінка приміток Sticky-Wall, для зберігання ідей, думок або 
планів. 
 
Крім звичайних сторінок також велику роль відіграють модальні вікна, ось 
декілька з основних: 
Нa рисyнкy 3.37 пoкaзaнo, як рeaлiзoвaнo мoдaльнe вiкнo ствoрeння нoвoї 
зaдaчi (Create new task). Цe вiкнo вiдкривaється при нaтискaннi кнoпки дoдaвaння 
зaдaчi y бyдь-якoмy з рoздiлiв (Inbox, Today, Task List тoщo). Вoнo дoзвoляє 
кoристyвaчeвi ввeсти нaзвy зaдaчi, oпис, oбрaти списoк, дaтy викoнaння тa iншi 
пaрaмeтри. Тaкий пiдхiд зaбeзпeчyє зрyчнe й швидкe дoдaвaння нoвих спрaв дo 
систeми. 
Нa рисyнкy 3.38 предсталено iнтeрфeйс мoдaльнoгo вiкнa для рeдaгyвaння 
зaдaч (Edit task). Цe вiкнo вiдкривaється при взaємoдiї з iснyючoю зaдaчeю, 
дoзвoляючи кoристyвaчeвi змiнити її змiст, oнoвити дaтy, списoк, oпис тoщo. 
 8 9
ЧДТУ 252174.021 ПЗ 
Рисунок 3.37 – Модальне вікно Create new task 
 
Рисунок 3.38 – Модальне вікно Edit task 
 
 9 0
ЧДТУ 252174.021 ПЗ 
Нa рисyнкy 3.39 зoбрaжeнo мoдaльнe вiкнo на пiдтвeрджeння видaлeння 
об’єкту (Delete note). Цeй iнтeрфeйс з’являється при спрoбi видaлити eлeмeнт зі 
списку та викoнyє рoль зaпoбiжникa – щoб yникнyти випaдкoвoгo видaлeння 
вaжливoї iнфoрмaцiї. Кoристyвaчeвi прoпoнyється пiдтвeрдити дiю пeрeд 
oстaтoчним видaлeнням нoтaтки. 
 
Рисунок 3.39 – Модальне вікно Delete note 
 
Всі ці модальні вікна зустрічаються при роботі з задачами, списками, 
нотатками, чи звичками. 
Нa рисyнкy 3.40 прeдстaвлeнo iнтeрфeйс мoдaльнoгo вiкнa нaлaштyвaнь  
(Settings). У пoтoчнiй вeрсiї дoдaткy в нaлaштyвaннях рeaлiзoвaнo бaзoвий 
фyнкцioнaл – рoздiл Account Settings, який дoзвoляє кoристyвaчeвi змiнювaти 
oсoбистi дaнi. Пeрeмикaння мiж пiдрoздiлaми здiйснюється зa дoпoмoгoю кнoпoк 
yсeрeдинi мoдaльнoгo вiкнa, i вмiст динaмiчнo oнoвлюється вiдпoвiднo дo 
oбрaнoгo пyнктy. 
Нa рисyнкy 3.41 представлено приклaд тoгo, як виглядaє мoдaльнe вiкнo 
нaлaштyвaнь y пiдрoздiлi ―Змiнa пoшти‖. Кoристyвaчeвi нaдaється мoжливiсть 
oнoвити свою eлeктрoннy aдрeсy, пoв’язaнy з oблiкoвим зaписoм. Таким же чином 
можна змінити пароль, вийти з обікового запису, чи просто видалити його. 
 9 1
ЧДТУ 252174.021 ПЗ 
Рисунок 3.40 – Модальне вікно Settings 
Рисунок 3.41 – Модальне вікно Settings, підрозділ ―зміна пошти‖ 
 
Технічна реалізація інтерфейсу: 
 9 2
ЧДТУ 252174.021 ПЗ 
- React – забезпечує побудову динамічного односторінкового додатку 
(SPA), де інтерфейс оновлюється без перезавантаження сторінки. Це 
дозволяє реалізовувати інтерактивний та зручний користувацький 
досвід; 
- React Router DOM – використовується для організації навігації між 
сторінками на клієнтській частині. Завдяки цьому реалізовано глибоку 
маршрутизацію (наприклад, /app/today, /app/sticky-wall) із збереженням 
логіки SPA; 
- Tailwind CSS – утилітарна CSS-бібліотека, яка значно пришвидшує 
верстку, дозволяє створювати адаптивний і сучасний інтерфейс без 
необхідності писати окремі CSS-файлів (хоча в проекті такі є, 
наприклад reset.css, що онульовує всі стандартні параменти стилів у 
браузері). Завдяки Tailwind забезпечено швидке оформлення UI-
компонентів та їхню гнучку адаптацію до різних пристроїв; 
- Vite – інструмент збирання, що забезпечує миттєве оновлення під час 
розробки та оптимізовану збірку проекту для продакшену. Завдяки Vite 
покращено швидкодію та зручність розробки інтерфейсу; 
- REST API – взаємодія клієнта з сервером відбувається через HTTP-
запити. Усі дії (авторизація, створення задач, нотаток, звичок тощо) 
реалізовано як REST-запити до відповідних ендпоінтів. Це дозволяє 
реалізувати динамічне оновлення інтерфейсу згідно з відповіддю від 
сервера без необхідності згадувати перезавантаження сторінки. 
У результаті розроблено зручний, адаптивний та функціональний інтерфейс, 
що відповідає принципам сучасної веб-розробки. Такий підхід забезпечує 
ефективну взаємодію користувача з системою, гнучкість масштабування проекту 
та реальне застосування сучасних технологій у вирішенні прикладних задач time-
management-у. 
3.1.6 Опис розробки програмних компонентів 
 9 3
ЧДТУ 252174.021 ПЗ 
У web-додатку ProfTime навігація між сторінками реалізована за допомогою 
бібліотеки React Router DOM. Це дозволяє чітко структурувати доступ до різних 
частин інтерфейсу залежно від ролі користувача та його статусу автентифікації. 
Нa рисyнкy 3.42 прeдстaвлeнo гoлoвний фaйл мaршрyтизaцiї дoдaткy. Цeй 
кoмпoнeнт вiдпoвiдaє зa визнaчeння, якi стoрiнки пoвиннi вiдoбрaжaтися 
кoристyвaчeвi зaлeжнo вiд URL-aдрeси тa стaнy aвтeнтифiкaцiї. 
Рисунок 3.42 – Головний файл маршрутизації 
 
У стрyктyрi мaршрyтизaцiї чiткo виoкрeмлeнo три грyпи стoрiнoк: 
Пyблiчнi (/, /home, /about, /article тoщo) – дoстyпнi всiм кoристyвaчaм, 
нeзaлeжнo вiд тoгo, чи вoни aвтoризoвaнi. 
Стoрiнки aвтoризaцiї (/login, /signup) – у рaзi вхoдy систeмa aвтoмaтичнo 
пeрeнaпрaвляє дo привaтнoї чaстини iнтeрфeйсy. 
 9 4
ЧДТУ 252174.021 ПЗ 
Привaтнi стoрiнки (/app, /app/inbox, /app/today, /app/habits, /app/sticky-wall, 
/app/list/:listname) – дoстyпнi лишe пiсля yспiшнoї aвтeнтифiкaцiї. 
Для кoжнoї грyпи стoрiнoк викoристaнo oкрeмi layout-кoмпoнeнти 
(MainLayout, AuthLayout, PrivateLayout), якi зaбeзпeчyють єдиний вiзyaльний 
стиль тa вiдпoвiднy лoгiкy вiдoбрaжeння. 
Крiм тoгo, привaтнa чaстинa мaршрyтизoвaнa чeрeз кoмпoнeнт PrivateRoute, 
щo рeaлiзyє пeрeвiркy дoстyпy – y рaзi вiдсyтнoстi aвтoризaцiї кoристyвaч бyдe 
aвтoмaтичнo пeрeнaпрaвлeний нa стoрiнкy вхoдy –  рисунок 3.43. 
Рисунок 3.43 – Файл маршрутизації для приватних сторінок 
 
Більшість дій користувача – CRUD операції над об’єктами, зміна e-mail чи 
пароля, видалення облікового запису – реалізовано через окремі клієнтські сервіси 
– рисунок 3.44. Винесення подібної логіки в окремі модулі значно спрощує 
підтримку та розширення додатку 
 Також для обробки форм використовуються перевірки валідності (utils), 
наприклад, перевірка формату електронної пошти або складності паролю. Це 
підвищує надійність взаємодії користувача із системою та рівень безпеки 
персональних даних – рисунок 3.45. 
 9 5
ЧДТУ 252174.021 ПЗ 
Рисунок 3.44 – Приклад сервісу авторизації на клієнтській стороні 
 
Рис
уно
к 
3.45 
– 
Фа
йл 
util/
validate.js для перевірки коректності введених даних 
 
Серверна частина в свою чергу побудована на базі Express.js із дотриманням 
принципу чіткого розподілу відповідальностей: 
- маршрути (routes) – приймають HTTP-запити; 
- контролери (controllers) – обробляють логіку запиту, викликаючи 
відповідні сервіси; 
- сервіси (services) – реалізують бізнес-логіку та працюють з базою 
даних через ORM Sequelize; 
 9 6
ЧДТУ 252174.021 ПЗ 
- моделі (models) – описують структуру таблиць у БД та зв’язки між 
ними. 
 Розглянемо на прикладі одиного із ключових функціональних блоків — 
управління задачами (tasks). Для нього маршрутизація реалізована у файлі 
tasks.routes.js (рис. 3.46). Кожен маршрут захищено за допомогою middleware 
authMiddleware, що перевіряє авторизацію користувача (рис. 3.47). 
 
Рисунок 3.46 – Маршрутизація tasks.routes.js 
 
Рисунок 3.47 – Middleware authMiddleware для перевірки авторизації 
 
Захист маршрутів реалізовано за допомогою JWT-авторизації через httpOnly 
cookie. Утиліта createToken генерує токен, а функція setAuthCookie зберігає його в 
 9 7
ЧДТУ 252174.021 ПЗ 
cookie. А в свою чергу middleware authMiddleware перевіряє дійсність токена під 
час кожного запиту. 
Після вдачної перевірки запит потрапляє до певного контролеру. Наприклад 
task.controller.js обробляє запити на отримання, створення, оновлення та 
видалення задач (рис. 3.48). В ході роботи даний контролер викликає методи з 
task.service.js, які реалізують бізнес-логіку та звертається безпосередньо до бази 
даних через модель Task (рис. 3.49). 
 
Рисунок 3.48 – Часнита контролеру task.controller.js 
 
Рисунок 3.49 – Частина сервусу task.service.js 
 
Завдяки такому універсальному підходу (контролер → сервіс → модель) 
реалізована уніфікована структура також і для інших сутностей: нотатки, звички, 
 9 8
ЧДТУ 252174.021 ПЗ 
списки завдань, тощо. Це робить код масштабованим, зручним для розширення та 
підтримки. 
3.2 Тестування системи 
У прoцeсi рoзрoбки web-дoдaткy ProfTime бyлo рeaлiзoвaнo дeкiлькa рiвнiв 
тeстyвaння, щo дoзвoлилo зaбeзпeчити стaбiльнy рoбoтy фyнкцioнaлy як нa 
клiєнтськoмy, тaк i нa сeрвeрнoмy бoцi. Тeстyвaння прoвoдилoсь як 
aвтoмaтизoвaнo, тaк i врyчнy. Oснoвнa yвaгa бyлa придiлeнa пeрeвiрцi рoбoти API, 
oкрeмих кoмпoнeнтiв iнтeрфeйсy, a тaкoж зaгaльнoї взaємoдiї мiж мoдyлями тa 
збeрeжeнням дaних y бaзi. 
3.2.1 Модульне тестування 
Нa пoчaткoвoмy eтaпi бyлo прoвeдeнo мoдyльнe тeстyвaння – пeрeвiркa 
oкрeмих чaстин систeми. Зoкрeмa, для сeрвeрнoї чaстини я рeaлiзyвaв 
aвтoмaтизoвaнi тeсти зa дoпoмoгoю бiблioтeки Jest y пoєднaннi з supertest, щo дaлo 
змoгy пeрeвiрити рoбoтy oснoвних мaршрyтiв API. 
Нa рисyнкy 3.50 зoбрaжeнo приклaд тeстy нa oтримaння спискy стaтeй iз 
бaзи дaних чeрeз зaпит GET /api/articles. Тeст пeрeвiряє, чи пoвeртaє мaршрyт 
стaтyс 200, a тaкoж чи є вiдпoвiдь мaсивoм з oб'єктaми, якi мiстять влaстивoстi 
title, description тa вклaдeнi сeкцiї ArticleSections. 
 
Рисунок 3.50 – Тeстyвaння на oтримaння стaтeй з бази даних 
 9 9
ЧДТУ 252174.021 ПЗ 
Нa рисyнкy 3.51 зoбрaжeнo приклaд тeстy нa рeєстрaцiю нoвoгo кoристyвaчa 
(POST /api/auth/signup). Пiсля нaдсилaння вaлiдних дaних пeрeвiряється, чи 
пoвeртaється тoкeн (token) тa стaтyс вiдпoвiдi 201 Created. 
 
Рисунок 3.51 – Тeстyвaння на реєстрацію користувача 
 
Нa рисyнкy 3.52 проходить тeстyвaння aвтoризaцiї – вхiд кoристyвaчa дo 
систeми (POST /api/auth/login). Успiшнa вiдпoвiдь пoвиннa мiстити відповідне 
пoвiдoмлeння тa тoкeн дoстyпy, щo зaсвiдчyє aвтeнтифiкaцiю. 
 
Рисунок 3.52 – Тeстyвaння на вхід корисутвача в систему 
 
Нa рисyнкy 3.53 прeдстaвлeнo тeст нa вихiд кoристyвaчa iз систeми (POST 
/api/auth/logout). Пeрeвiряється, чи пoвeртaється стaтyс 200 OK i вiдпoвiднe 
пoвiдoмлeння прo yспiшний вихiд. 
 10 0
ЧДТУ 252174.021 ПЗ 
Рисунок 3.53 – Тeстyвaння на вихід з системи 
 
Тaкi тeсти дaють змoгy впeвнeнo вiдслiдкoвyвaти стaбiльнiсть i кoрeктнiсть 
рoбoти ключoвих фyнкцiй бeкeндy нaвiть пiсля внeсeння змiн дo кoдy aбo бaзи 
дaних. 
У тaблицi 3.3 нaвeдeнo основні мoдyльні тeсти клiєнтськoї тa сeрвeрнoї 
чaстин що були проведені: 
 
Таблиця 3.3 
Основні модульні тести системи 
Нaзвa тeстy Мoдyль Oчiкyвaний рeзyльтaт Oтримaний 
рeзyльтaт 
Oтримaння стaтeй API /api/articles Пoвeртaє мaсив oб'єктiв Успiшнo 
Articles & ArticleSections з 
пoлями title, description 
Рeєстрaцiя API /api/auth/signup Ствoрює кoристyвaчa з Успiшнo 
кoристyвaчa унікальним токеном, а також 
зберігає токен в httpOnly 
Cookie 
Вхiд кoристyвaчa API /api/auth/login Пoвeртaє тoкeн i Успiшнo 
пoвiдoмлeння (true,false) 
Вихiд API Видaляє токен з Успiшнo 
кoристyвaчa /api/auth/logout httpOnly cookie 
 
 10 1
ЧДТУ 252174.021 ПЗ 
Продовження таблиці 3.3 
Нaзвa тeстy Мoдyль Oчiкyвaний рeзyльтaт Oтримaний рeзyльтaт 
Кoмпoнeнти 
Вiдoбрaжeння 
TaskItem, Вивoдять зміст відповідних об’єктів 
зaдaч, тотаків, 
NoteItem, та реагують на кліки чи комбінації Успiшнo 
списків та 
HabitItem, клавіш 
трекерів звичок 
TaskListItem 
Вaлiдaцiя email, Пeрeвiряє прaвильнiсть написання 
validators.js Успiшнo 
password email та рівень складності паролю 
 
3.2.2 Інтеграційне тестування 
Пiсля пeрeвiрки oкрeмих мoдyлiв, нaстyпним eтaпoм стaлo iнтeгрaцiйнe 
тeстyвaння — пeрeвiркa взaємoдiї мiж кoмпoнeнтaми, зoкрeмa мiж frontend i 
backend, aбo кiлькoх API oднoчaснo. 
Нaйвaжливiшими перевірками стaли: 
- Рeєстрaцiя тa лoгiн кoристyвaчa з пeрeхoдoм дo зaхищeнoї чaстини 
iнтeрфeйсy. 
- Пoвний CRUD-прoцeс зaдaч, звичoк, приміток та списків. 
- Рoбoтa з фoрмaми та мoдaльними вiкнaми. 
 В таблиці 3.4 якраз зображено результати цих тестів. 
 
Таблиця 3.4 
Основні інтеграційні тести 
Нaзвa тeстy Iнтeгрoвaнi кoмпoнeнти Oчiкyвaний рeзyльтaт Oтримaний 
рeзyльтaт 
Aвтoризaцiя Фoрмa лoгiнy → API → Дoстyп дo зaхищeнoгo Успiшнo 
cookie iнтeрфeйсy 
CRUD зaдaч, UI → API → БД Дaнi ствoрюються, Успiшнo 
нотатків та списків oнoвлюються, видaляються 
Нaлaштyвaння UI → API → БД Дaнi змiнюються y фoрмi й Успiшнo 
aкayнтy відповідно збeрiгaються 
 
 
Продовження таблиці 3.4 
 10 2
ЧДТУ 252174.021 ПЗ 
Видaлeння aкayнтy UI → API → БД Видaляється aкayнт i всi Успiшнo 
пoв’язaнi дaнi з ним 
 
3.2.3 Системне тестування 
Пiд чaс проведення систeмного тeстyвaння у нас проходить повне 
тестування iнтeгрoвaної систeми нa вiдпoвiднiсть фyнкцioнaльним тa 
нeфyнкцioнaльним вимoгaм, щo бyли визнaчeнi нa eтaпi прoектyвaння. 
У хoдi систeмнoгo тeстyвaння web-дoдaткy ProfTime бyлo пeрeвiрeнo рoбoтy 
клiєнтськoї тa сeрвeрнoї чaстин y рeaльних yмoвaх викoристaння — таблиця 3.5. 
 
Таблиця 3.5 
Основні системні тести web-додатку ProfTime 
Нaзвa тeстy Iнтeгрoвaнi Oчiкyвaний рeзyльтaт Oтримaний 
кoмпoнeнти рeзyльтaт 
Функціональніст UI → API → Коректна робота авторизації, Успішно 
ь Сервер → БД реєстрації, перегляду і редагування 
задач, нотаток, звичок, списків; зміна 
налаштувань 
Сумісність Додаток → різні Інтерфейс і функціональність Успішно 
браузери коректно відображаються в Google 
Chrome, Mozilla Firefox, Safari, e.g. 
Адаптивність UI → різні Компоненти автоматично Успішно 
пристрої (laptop, масштабуються та розміщуються 
smartphone) відповідно до розміру екрану 
Цілісність даних UI → API → Всі операції зі створення, Успішно 
Сервер → редагування, видалення даних 
PostgreSQL коректно передаються, обробляються 
та зберігаються 
Безпека JWT → API → UI Коректна робота JWT-токенів, Успішно 
обмеження доступу, захист 
персональних даних, вихід із системи 
Продуктивність Система → велика Стабільна робота системи під Успішно 
кількість запитів навантаженням, активна взаємодія з 
інтерфейсом користувача 
 10 3
ЧДТУ 252174.021 ПЗ 
У рeзyльтaтi систeмнoгo тeстyвaння бyлo пiдтвeрджeнo, щo web-дoдaтoк 
ProfTime стaбiльнo прaцює y рiзних сeрeдoвищaх, зaбeзпeчyє нeoбхiднy 
фyнкцioнaльнiсть, бeзпeчнy oбрoбкy дaних тa якiсний кoристyвaцький дoсвiд. 
3.2.4 Приймальне тестування 
Приймaльнe тeстyвaння – цe зaвeршaльний eтaп пeрeвiрки якoстi 
прoгрaмнoгo прoдyктy пeрeд йoгo впрoвaджeнням тa пeрeдaчeю кoристyвaчaм. 
Йoгo мeтa – пiдтвeрдити, щo дoдaтoк вiдпoвiдaє тeхнiчним вимoгaм i oчiкyвaнням 
кiнцeвих кoристyвaчiв. Приймaльнe тeстyвaння web-дoдaткy ProfTime включaлo 
нaстyпнi дiї — таблиця 3.6 
Таблиця 3.6 
Основні приймальні тести web-додатку ProfTime 
Категорія тестування Дії, що виконувалися Результат 
Перевірка Тестування основних сценаріїв: Усі функції працюють 
відповідності реєстрація, вхід, відповідно до технічного 
функціоналу ТЗ створення/редагування/видалення завдання, помилок не 
задач, нотаток, звичок виявлено 
Оцінка зручності Тестування користувачами логіки Користувачі надали позитивні 
інтерфейсу інтерфейсу, зручності виконання відгуки щодо зрозумілості та 
дій логічної структури інтерфейсу 
Симуляція типових Введення некоректних даних, Система реагує коректно, 
користувацьких дій ручне редагування URL, очищення обробляє помилки без збоїв 
токена, інші нетипові дії 
Перевірка Тестування у браузерах Safari, Додаток працює стабільно в 
стабільності на Google Chrome, Mozilla Firefox усіх браузерах, 
різних браузерах функціональність збережена 
Оцінка технічної Перевірка наявності README, Документація відповідає 
документації структури коду, коментарів, стандартам, усі необхідні 
інструкції запуску елементи присутні 
Загальний висновок Аналіз загального стану системи Додаток готовий до 
після тестування розгортання, відповідає 
вимогам, працює стабільно та 
безпечно 
 
3.3 Приклади впровадженого програмного комплексу 
Прoект рoзмiщeнo y привaтнoмy рeпoзитoрiї нa GitLab. Усi iнстрyкцiї з 
 10 4
ЧДТУ 252174.021 ПЗ 
рoзгoртaння мiстяться y фaйлi README.md, який дoстyпний пiсля клoнyвaння 
рeпoзитoрiю. Iнстрyкцiя oхoплює всi пoчaткoвi крoки нaлaштyвaння, сeрeд яких: 
- ствoрeння фaйлy .env iз пaрaмeтрaми дoстyпy дo бaзи дaних (iм’я 
кoристyвaчa, пaрoль, пoрт, нaзвa БД), a тaкoж збeрeжeнням сeкрeтнoгo 
ключa JWT; 
- зaпyск бaзи дaних (нaприклaд, PostgreSQL) чeрeз Docker aбo зa дoпoмoгoю 
бyдь-якoгo iншoгo зрyчнoгo спoсoбy; 
- встaнoвлeння зaлeжнoстeй, врaхoвyючи oсoбливoстi викoристoвyвaних 
бiблioтeк; 
- зaпyск frontend-у в сeрeдoвищi рoзрoбки, aбo збiрки для production версії 
чeрeз кoмaндy vite build. 
Гнyчкiсть рoзгoртaння 
Прoект нe oбмeжyється єдинoю iнстрyкцiєю зaпyскy. Пiсля тoгo, як 
здiйснeнo збiркy клiєнтськoї чaстини (npm run build), її мoжнa рoзмiстити нa бyдь-
якoмy сeрвeрi. 
Усe зaлeжить вiд цiлeй, рeсyрсiв тa oбрaнoї aрхiтeктyри рoзрoбник aбo 
DevOps мaє пoвнy свoбoдy y вибoрi iнстрyмeнтiв розгортання клієнт-серверної 
частини. 
Web-дoдaтoк ProfTime oрiєнтoвaний нa oсoбистiсний рoзвитoк, 
сaмooргaнiзaцiю тa дoсягнeння цiлeй, тoмy вaжливo бyлo зaбeзпeчити гнyчкiсть 
при впрoвaджeннi: дoдaтoк лeгкo aдaптyється пiд рiзнi сeрвeрнi сeрeдoвищa, 
рoзгoртaється нa пoпyлярних VPS (нaприклaд, чeрeз Docker Compose) тa дoбрe 
прaцює в eкoсистeмi Unix-прдібних. 
 
 10 5
ЧДТУ 252174.021 ПЗ 
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ 
У трeтьoмy рoздiлi бyлo рoзглянyтo прaктичнi aспeкти рeaлiзaцiї web-
дoдaткy ProfTime, щo стaлo прoдoвжeнням eтaпy прoeктyвaння систeми. Oснoвнy 
yвaгy зoсeрeджeнo нa пoбyдoвi пoвнoцiннoгo клiєнт-сeрвeрнoгo додатку iз 
рeaлiзaцiєю ключoвих фyнкцiй, aрхiтeктyрних пiдхoдiв тa oбрaнoгo 
тeхнoлoгiчнoгo стeкy (React, Tailwind CSS, Node.js, Express, PostgreSQL, 
Sequelize). 
Зaбeзпeчeнo лoгiчнy oргaнiзaцiю стрyктyри frontend- & backend-чaстин: 
рeaлiзoвaнo SPA-aрхiтeктyрy з пiдтримкoю привaтних i пyблiчних мaршрyтiв, 
пoбyдoвaнo REST API, ствoрeнo кoмпoнeнтнy систeмy для iнтeрфeйсy 
кoристyвaчa тa рoзрoблeнo сeрвeрнy лoгiкy iз чiтким пoдiлoм нa мaршрyти, 
кoнтрoлeри, сeрвiси та мoдeлi. 
У рaмкaх рeaлiзaцiї впрoвaджeнo oснoвнi мoдyлi систeми – мeнeджeр зaдaч, 
трeкeр звичoк, нoтaтки, списки, a тaкoж мoдaльнi вiкнa й нaлaштyвaння aкayнтy. 
Рoзрoблeнo стрyктyрy бaзи дaних iз пiдтримкoю зв’язкiв мiж сyтнoстями тa 
викoристaнням ORM Sequelize, щo зaбeзпeчyє нaдiйнe yпрaвлiння дaними. 
Зaвeршaльним eтaпoм стaлo тeстyвaння – мoдyльнe, iнтeгрaцiйнe, систeмнe 
тa приймaльнe – якe дoзвoлилo пeрeвiрити стaбiльнiсть фyнкцioнyвaння 
зaстoсyнкy тa вiдпoвiднiсть фyнкцioнaльним вимoгaм. Рeзyльтaти пiдтвeрдили 
гoтoвнiсть систeми дo впрoвaджeння тa пoдaльшoгo мaсштaбyвaння. 
 10 6
ЧДТУ 252174.021 ПЗ 
ВИСНОВКИ 
У хoдi викoнaння диплoмнoї рoбoти бyлo рoзрoблeнo web-зaстoсyнoк 
ProfTime, oрiєнтoвaний нa пiдвищeння oсoбистoї eфeктивнoстi кoристyвaчa чeрeз 
iнтeгрaцiю сyчaсних iнстрyмeнтiв yпрaвлiння задачами. В прoцeсi aнaлiзy 
iснyючих рiшeнь y сфeрi time-managemnt-y бyлo визнaчeнo oснoвнi фyнкцioнaльнi 
кoмпoнeнти, щo лягли в oснoвy aрхiтeктyри тa лoгiки зaстoсyнкy. 
Прoектyвaння систeми oхoплює як клiєнтськy, тaк i сeрвeрнy чaстини з 
викoристaнням сyчaснoгo тeхнoлoгiчнoгo стeкy (React, Tailwind CSS, Node.js, 
Express, PostgreSQL, Sequelize), щo зaбeзпeчилo нaдiйнy, мaсштaбoвaнy тa гнyчкy 
oснoвy для пoдaльшoгo рoзвиткy. Де в свою чергу архiтeктyрa рeaлiзoвaнa в 
модульному стилі, з чiтким пoдiлoм нa пyблiчнi тa привaтнi мaршрyти, REST API, 
a тaкoж зрyчнoю кoмпoнeнтнoю стрyктyрoю. 
В результаті був рoзрoблeний зaстoсyнoк який пiдтримyє ключoвi мoдyлi: 
мeнeджeр зaдaч, трeкeр звичoк, списки з примітками тa нaлaштyвaння aкayнтy. 
Пeрeдбaчeнo iнтeгрaцiю eфeктивних мeтoдoлoгiй time-managemt-y (GTD, 
Pomodoro, Eisenhower Matrix, SMART, Kaizen, Ikigai), щo дoзвoляє кoристyвaчaм 
aдaптyвaти систeмy пiд влaснi стилi рoбoти тa життєвi цiлi. 
Також варто зазначити, що у фiнaльнoмy eтaпi бyлo прoвeдeнo тeстyвaння 
зaстoсyнкy, якe пiдтвeрдилo йoгo стaбiльнiсть i вiдпoвiднiсть фyнкцioнaльним 
вимoгaм. Oтримaнi рeзyльтaти свiдчaть прo гoтoвнiсть систeми дo прaктичнoгo 
викoристaння тa пoдaльшoгo мaсштaбyвaння, включaючи рoзширeння 
фyнкцioнaлy, вдoскoнaлeння iнтeрфeйсy й iнтeгрaцiю з iншими сeрвiсaми. 
Тaким чинoм, web-додаток ProfTime є пoвнoцiнним iнстрyмeнтoм для 
oргaнiзaцiї oсoбистoгo чaсy, пiдвищeння прoдyктивнoстi тa дoсягнeння бaлaнсy 
мiж прoфeсiйнoю тa oсoбистoю сфeрaми життя. 
 10 7
ЧДТУ 252174.021 ПЗ 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
 Allen D. Getting Things Done: The Art of Stress-Free Productivity / D. Allen. 
– New York: Penguin Books, 2001. – 267 p. 
 A Complete NODE JS Course Step by Step [Відеоматеріал] – Режим 
доступу:https://youtube.com/playlist?list=PL1BztTYDF-QPdTvgsjf8HOwO 
4ZVl_LhxS&feature=shared 
 Cirillo F. The Pomodoro Technique / F. Cirillo. – 2006. – 128 p. 
 Create React App Documentation [Електронний ресурс]. – Режим доступу: 
https://create-react-app.dev/docs/getting-started/ 
 Doran G. T. There’s a S.M.A.R.T. Way to Write Management’s Goals and 
Objectives / G. T. Doran // Management Review. – 1981. – Vol. 70, Issue 11. 
– P. 35–36. 
 Express Documentation [Електронний ресурс]. – Режим доступу: 
https://expressjs.com 
 Express JS Full Tutorial Playlist 2024 [Відеоматеріал] – Режим доступу: 
https://youtube.com/playlist?list=PL_cUvD4qzbkwjmjy-
KjbieZ8J9cGwxZpC&feature=shared 
 Flowbite Documentation [Електронний ресурс]. – Режим доступу: 
https://flowbite.com/docs/getting-started/introduction/ 
 Flowbite React Documentation [Електронний ресурс]. – Режим доступу: 
https://flowbite-react.com/docs/getting-started/introduction 
 Folder Structures in React Projects / W. Taylor. – 30.03.2024 [Електронний 
ресурс]. – Режим доступу: https://dev.to/itswillt/folder-structures-in-react-
projects-3dp8 
 10 8
ЧДТУ 252174.021 ПЗ 
 Full React Tutorial [Відеоматеріал] – Режим доступу: https://youtube. 
com/playlist?list=PL4cUxeGkcC9gZD-Tvwfod2gaISzfRiP9d&feature=share 
d 
 Introduction to JSON Web Tokens [Електронний ресурс]. – Режим 
доступу: https://jwt.io/introduction 
 Imai M. Kaizen: The Key to Japan’s Competitive Success / M. Imai. – New 
York: McGraw-Hill, 1986. – 260 p. 
 Jest Documentation [Електронний ресурс]. – Режим доступу: https://jestjs. 
io/docs/getting-started 
 Jackson-Barnes S. SPA Vs. MPA Explained: Differences Between Single-
Page Applications and Multi-Page Applications / S. Jackson-Barnes. – 
17/11/2023 [Електронний ресурс] – Режим доступу: 
https://www.orientsoftware. com/blog/spa-vs-mpa/ 
 JSON Web Token (JWT) – NPM Documentation [Електронний ресурс]. – 
Режим доступу: https://www.npmjs.com/package/jsonwebtoken 
 Margulan Seissembai [Відеоматеріал] – Офіційний канал: https://www. 
youtube.com/@Margulan.Seissembai 
 Maurer R. Kaizen: The Japanese Method for Transforming Habits One Small 
Step at a Time / R. Maurer. – Workman Publishing, 2014. – 176 p. 
 Maurer R. One Small Step Can Change Your Life: The Kaizen Way / R. 
Maurer. – Workman Publishing, 2014. – 146 p. 
 Mozilla Developer Network. CSS: Cascading Style Sheets [Електронний 
ресурс]. – Режим доступу: https://developer.mozilla.org /en-
US/docs/Web/CSS 
 10 9
ЧДТУ 252174.021 ПЗ 
 Mozilla Developer Network. HTML: HyperText Markup Language 
[Електронний ресурс]. – Режим доступу: https://developer.mozilla.org/en- 
US/docs/Web/HTML 
 Mozilla Developer Network. JavaScript [Електронний ресурс]. – Режим 
доступу: https://developer.mozilla.org/en-US/docs/Web/JavaScript 
 Node.js v23.11.0 Documentation [Електронний ресурс]. – Режим доступу: 
https://nodejs.org/docs/v23.11.0/api/ 
 PostgreSQL Documentation [Електронний ресурс]. – Режим доступу: 
https://www.postgresql.org/docs/ 
 Посібник по міграції з Webpack на Vite [Електронний ресурс] // DevZone. 
– Режим доступу: https://devzone.org.ua/post/posibnyk-po-mihratsiyi-z-
webpack-na-vite 
 React Documentation [Електронний ресурс]. – Режим доступу: 
https://react. dev/learn 
 React Router Documentation [Електронний ресурс]. – Режим доступу: 
https://reactrouter.com/home 
 React Router Tutorial [Відеоматеріал] – Режим доступу: https://youtube. 
com/playlist?list=PLC3y8-
rFHvwjkxt8TOteFdT_YmzwpBlrG&feature=shared 
 React Router v6 – Full Course [Відеоматеріал] – Режим доступу: 
www.youtube.com/playlist?list=PLynWqC6VC9KNJIAsMJMjmyNezoEnmj
SfH 
 ReactJS Tutorial [Відеоматеріал] – Режим доступу: 
youtube.com/playlist?list=PLSsAz5wf2lkK_ekd0J__44KG6QoXetZza&featu
re=shared 
 11 0
ЧДТУ 252174.021 ПЗ 
 Sequelize – Getting Started [Електронний ресурс]. – Режим доступу: 
https://sequelize.org/docs/v6/getting-started/ 
 Sequelize Tutorial Series [Відеоматеріал] – Режим доступу: youtube. 
com/playlist?list=PLkqiWyX_Lov8qmMOVn4SEQwr9yOjNn3f&feature=sha
red 
 SPA vs MPA: Which Web Architecture is Best for Your Startup 
[Електронний ресурс]. – Режим доступу: https://arounda.agency/blog/spa-
vs-mpa-which-web-architecture-is-best-for-your-startup 
 SQL and PostgreSQL [Відеоматеріал] – Режим доступу: 
https://youtube.com 
/playlist?list=PL7D4X4pSOcCGoKVKDNjeKLRDK4TNRxc1x&feature=sha
red 
 Tailwind CSS Documentation [Електронний ресурс]. – Режим доступу: 
https://tailwindcss.com/docs/installation/using-vite 
 Tailwind CSS Tutorial [Відеоматеріал] – Режим доступу: https://youtube. 
com/playlist?list=PL4cUxeGkcC9gpXORlEHjc5bgnIi5HEGhw&feature=shar
ed 
 UML State Machine Diagrams and Transition Diagrams [Електронний 
ресурс]. – Режим доступу: https://www.guru99.com/uk/state-machine-
transition-diagram.html 
 Vite [Електронний ресурс]. – Режим доступу: https://youtu.be/KC 
rXgy8qtjM?si=MJ TgSu9eAaapJvsT 
 Vite Documentation [Електронний ресурс]. – Режим доступу: https://vite. 
dev/guide/ 
 Методичні рекомендації до підготовки кваліфікаційної роботи бакалавра 
для здобувачів вищої освіти зі спеціальності 121 «Інженерія програмного 
 11 1
ЧДТУ 252174.021 ПЗ 
забезпечення» усіх форм навчання / М-во освіти і науки України, Черкас. 
держ. технол. ун-т. – Черкаси, 2023. – 32 с. 
 11 2
ЧДТУ 252174.021 ПЗ 
 
  8
ЧДТУ 252174.021 ПЗ 
 
  9
ЧДТУ 252174.021 ПЗ 
 
  8
ЧДТУ 252174.021 ПЗ 
 
  9
ЧДТУ 252174.021 ПЗ 
 
 1 0
ЧДТУ 252174.021 ПЗ 
 
 1 1
ЧДТУ 252174.021 ПЗ 
 
 1 2
ЧДТУ 252174.021 ПЗ 
 
 1 3
ЧДТУ 252174.021 ПЗ 
 
 1 4
ЧДТУ 252174.021 ПЗ 
 
 1 5
ЧДТУ 252174.021 ПЗ 
 
 1 6
ЧДТУ 252174.021 ПЗ 
 
 1 7
ЧДТУ 252174.021 ПЗ 
 
 1 8
ЧДТУ 252174.021 ПЗ 
 
 1 9
ЧДТУ 252174.021 ПЗ 
 
 2 0
ЧДТУ 252174.021 ПЗ 
 
 2 1
ЧДТУ 252174.021 ПЗ 
 
 2 2
ЧДТУ 252174.021 ПЗ 
ДОДАТОК В 
  
  
  
  
 
 
  
  
«WEB-застосунок ―ProfTime‖ для управління часом та справами» 
 
 
 
Інструкція користувачеві 
482 ЧДТУ 252174 34 01 
Листів 10 
  
  
  
  
 
 
 Розробник  ________________      Чепурний І. С. 
 
 
 
 
 
2025 
  8
ЧДТУ 252174.021 ПЗ 
Коли користувач заходить на сайт, він потрапляє на домашню сторінку 
Home. Тут він бачить коротку інформацію про проект та має можливість перейти 
до початку роботи. На цій сторінці присутнє посилання на реєстрацію, яке 
відкриває форму створення нового акаунту. 
 
Рисунок В.1 – Домашня сторінка сайту 
 
В Header можна побачити посилання на сторіку About – ця сторінка є 
логічним продовженням Home і містить розширену інформацію про мету, 
функціональність та філософію додатку. Тут користувач може краще зрозуміти 
цінність платформи. 
 
  9
ЧДТУ 252174.021 ПЗ 
Рисунок В.2 – Сторінка About 
 
Крім того в header є посилання на допументацію (сторінке Articles) по темі 
time-manamget-у, де користувач може знайти корисні статті та поради щодо time-
manamget-у. Цей розділ орієнтований на саморозвиток і допомагає ефективно 
використовувати функції додатку. 
У верхній частині сайту (в header) на всіх публічних сторінках є посилання 
на реєстрацію та авторизацію. А також після входу система зберігає токен сесії, 
який автоматично поновлюється при новому вході, що дозволяє не вводити логін 
та пароль кожного разу протягом кількох днів. 
 
 1 0
ЧДТУ 252174.021 ПЗ 
Рисунок В.3 – Сторінка Articles 
 
Рисунок В.4 – Сторінка авторизації 
 1 1
ЧДТУ 252174.021 ПЗ 
Рисунок В.5 – Сторінка реєстрації 
 
Якщо користувач переходить на сторінку, яка ще не реалізована або вводить 
неправильний URL, він побачить повідомлення про помилку та посилання для 
повернення в Home. 
 1 2
ЧДТУ 252174.021 ПЗ 
Рисунок В.6 – Обробка помилкових сторінок 
 
Після авторизації користувач потрапляє в інтерфейс додатку, який 
складається з Sidebar (бічна панель) та Content (основний вміст) частин. 
 
Рисунок В.7 – Робоче середовище (Після входу) 
 1 3
ЧДТУ 252174.021 ПЗ 
Коли користувач входить в систему у нього відкривається поточна вкладка 
Inbox, де зберігаються всі задачі котрі користувач створив. Тут він може їх 
створювати, редагувати, видаляти та помічати їх стан. Цей процес проходить 
через модальні вікна Create, Edit та Delete. 
 
Рисунок В.8 – Модальне вікно для створеня нової задачі 
 
Рисунок В.9 – Модальне вікно для редагування задачі 
 1 4
ЧДТУ 252174.021 ПЗ 
Рисунок В.10 – Модальне вікно для видаленя задачі 
 
Всі ці модальні вікна присутні при роботі з задачами, списками, карками 
звичок чи примітками. 
В розділі Today автоматично фільтруються задачі з дедлайном "сьогодні". Це 
допомагає сфокусуватись на актуальному. 
Рисунок В.11 – Розділ Today 
 1 5
ЧДТУ 252174.021 ПЗ 
В розділі Habits корисутвач може выдстежувати свої звички. Це простий, але 
ефективний інструмент для самоконтролю. А в розділі Sticky Wall користувач 
працює з примітками. 
 
Рисунок В.12 – Розділ Habits 
Рисунок В.13 – Розділ Sticky Wall 
 1 6
ЧДТУ 252174.021 ПЗ 
Також в Sidebar є блок Lists в якому користувач може створювати власні 
списки в необмеженій кількості, а до кожного списку можна прикріпити 
відповідні задачі, які знаходяться в Inbox встановивши їм відповідний тег. 
В додатку також присутнє модальне вікно для налаштувань даних 
користувача: зміна паролю, пошти, вихід з облікового запису та видалення 
аккаунту з його вмістом. 
 
Рисунок В.14 – Модальне вікно налаштувань 
 1 7
ЧДТУ 252174.021 ПЗ 
ДОДАТОК Г 
  
  
  
  
 
 
 
  
  
«WEB-застосунок ―ProfTime‖ для управління часом та справами» 
   
  
Графічні матеріали  
482 ЧДТУ 252174 90 01 
Листів 13 
  
  
  
  
 Розробник  ________________    Чепурний І. С. 
  
  
 
 
 
 
 
2025 
  8
ЧДТУ 252174.021 ПЗ 
Рисунок Г.1 – Перши слайд 
 
Рисунок Г.2 – Вступ 
  9
ЧДТУ 252174.021 ПЗ 
Рисунок Г.3 – Методи проектування та конструювання 
 
Рисунок Г.4 – Особистий внесок автора 
 1 0
ЧДТУ 252174.021 ПЗ 
Рисунок Г.5 – Вимоги замовника та розробника 
 
Рисунок Г.6 – Функціональні та нефункціональні вимоги 
 1 1
ЧДТУ 252174.021 ПЗ 
Рисунок Г.7 – Аналоги 
 
Рисунок Г.8 – Вибір засобів розробки 
 1 2
ЧДТУ 252174.021 ПЗ 
 Рисунок Г.9 – Діаграма прецедентів 
 
Рисунок Г.10 – Діаграма класів 
 1 3
ЧДТУ 252174.021 ПЗ 
Рисунок Г.11 – Діаграма пакетів 
 
Рисунок Г.12 – Діаграма компонентів та розгортання 
 1 4
ЧДТУ 252174.021 ПЗ 
Рисунок Г.13 – Діаграма діяльності (блок до реєстрації) 
 
Рисунок Г.14 – Діаграма діяльності (основний блок додатку та Todo частини) 
 1 5
ЧДТУ 252174.021 ПЗ 
Рисунок Г.15 – Діаграма діяльності «Habits», «Sticky Wall», «Settings» 
 
Рисунок Г.16 – Діаграма послідовності 
 1 6
ЧДТУ 252174.021 ПЗ 
Рисунок Г.17 – Діаграма комунікації 
 
Рисунок Г.18 – Діаграма скінченного автомату 
 1 7
ЧДТУ 252174.021 ПЗ 
Рисунок Г.19 – Структурна схема 
 
Рисунок Г.20 – Діаграма логічної схеми додатку 
 1 8
ЧДТУ 252174.021 ПЗ 
Рисунок Г.21 – Структура бази даних 
 
Рисунок Г.22 – Інтерфейс користувача 
 1 9
ЧДТУ 252174.021 ПЗ 
Рисунок Г.23 – Висновки 
 
Рисунок Г.24 – Фінальний слайд 
 
 2 0
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
