WEB-застосунок для контролю калорійності харчування

Шевченко, Мирослав Віталійович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/8912
Full metadata record
DC Field	Value	Language
dc.contributor.advisor	Півень, Олександр Борисович	-
dc.contributor.author	Шевченко, Мирослав Віталійович	-
dc.date.accessioned	2026-03-21T15:27:32Z	-
dc.date.available	2026-03-21T15:27:32Z	-
dc.date.issued	2025-06-10	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/8912	-
dc.description.abstract	АНОТАЦІЯ Виконавець: Шевченко Мирослав Віталійович Назва роботи: «WEB-застосунок для контролю калорійності харчування» Спеціальність: 121 Інженерія програмного забезпечення Навчальний заклад: Черкаський державний технологічний університет, м. Черкаси, 2025 рік У кваліфікаційній бакалаврській роботі представлено процес розробки веб-застосунку, що дозволяє користувачам контролювати денну калорійність та вміст нутрієнтів у своєму раціоні. Основною метою створення системи є надання зручного цифрового інструменту для обліку прийомів їжі, аналізу харчових звичок та візуалізації добових показників споживання. У ході виконання проєкту було проведено дослідження потреб кінцевих користувачів, визначено функціональні вимоги до системи, спроєктовано архітектуру застосунку та реалізовано його інтерфейс і серверну логіку. Для розробки застосовувались сучасні технології: React для створення інтерфейсу, Node.js з Express для серверної частини, а MongoDB – як основна база даних. Основні результати розробки охоплюють: – формування вимог: визначено ключові сценарії використання, функціональні модулі та нефункціональні обмеження з урахуванням зручності, продуктивності та безпеки; – моделювання та проектування: створено структурну та логічну схеми системи, розроблено схеми бази даних і взаємодії між компонентами клієнт-серверної архітектури; – реалізація: розроблено повноцінний веб-застосунок, що дозволяє додавати продукти до щоденного раціону, автоматично розраховує сумарні калорії, білки, жири та вуглеводи, а також надає графічну візуалізацію динаміки харчування. Отримані результати демонструють, що система відповідає поставленим вимогам, є стабільною у роботі та готовою до практичного застосування як персональний щоденник харчування.	uk_UA
dc.description.abstract	ANNOTATION Author: Shevchenko Myroslav Vitaliiovych Title of the thesis: “Web Application for Monitoring Food Caloric Content” Specialty: 121 Software Engineering Educational institution: Cherkasy State Technological University, Cherkasy, 2025 The bachelor’s qualification thesis presents the process of developing a web application that allows users to track daily caloric intake and nutrient composition in their diet. The main goal of the system is to provide a convenient digital tool for logging meals, analyzing eating habits, and visualizing daily consumption metrics. During the implementation of the project, an analysis of end-user needs was conducted, functional requirements were defined, the system architecture was designed, and both the user interface and server-side logic were implemented. The development process utilized modern technologies: React for building the interface, Node.js with Express for the backend, and MongoDB as the primary database. The key development outcomes include: – requirements formulation: identification of key usage scenarios, functional modules, and non-functional constraints considering usability, performance, and security; – system modeling and design: creation of structural and logical system diagrams, database schema design, and definition of interactions between components in the client-server architecture; – implementation: development of a fully functional web application enabling users to add meals to their daily intake, automatically calculate total calories, proteins, fats, and carbohydrates, and visualize nutritional trends. The obtained results demonstrate that the system meets the specified requirements, operates reliably, and is ready for real-world deployment as a personal food tracking diary.	uk_UA
dc.language.iso	uk	uk_UA
dc.subject	ВЕБ-ЗАСТОСУНОК	uk_UA
dc.subject	REACT	uk_UA
dc.subject	NODE.JS	uk_UA
dc.subject	MONGODB	uk_UA
dc.subject	КАЛОРІЇ	uk_UA
dc.subject	НУТРІЄНТИ	uk_UA
dc.subject	КОРИСТУВАЦЬКИЙ ІНТЕРФЕЙС	uk_UA
dc.subject	API	uk_UA
dc.subject	ХАРЧОВИЙ ОБЛІК	uk_UA
dc.subject	ВІЗУАЛІЗАЦІЯ	uk_UA
dc.subject	UI/UX	uk_UA
dc.subject	КЛІЄНТ-СЕРВЕРНА АРХІТЕКТУРА	uk_UA
dc.subject	WEB APPLICATION	uk_UA
dc.subject	REACT	uk_UA
dc.subject	NODE.JS	uk_UA
dc.subject	MONGODB	uk_UA
dc.subject	CALORIES	uk_UA
dc.subject	NUTRIENTS	uk_UA
dc.subject	USER INTERFACE	uk_UA
dc.subject	API	uk_UA
dc.subject	MEAL TRACKING	uk_UA
dc.subject	VISUALIZATION	uk_UA
dc.subject	UI/UX	uk_UA
dc.subject	CLIENT-SERVER ARCHITECTURE	uk_UA
dc.title	WEB-застосунок для контролю калорійності харчування	uk_UA
dc.type	Bachelor Thesis	uk_UA
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Files in This Item:
File	Description	Size	Format
Кваліфікаційна робота бакалавра Шевченко Мирослав Віталійович.pdf Restricted Access		9.34 MB	Adobe PDF	View/Open Request a copy
Show simple item record
Extracted text
 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
бакалавра 
 
на тему: «WEB-застосунок для контролю калорійності харчування» 
 
Виконав: студент 4 курсу, групи ПЗ-2104 
спеціальності 
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
 
 
Студент Шевченко М.В. 
 (прізвище та ініціали) 
Керівник  Півень О.Б. 
 (прізвище та ініціали) 
Рецензент  Захарова М.В. 
 (прізвище та ініціали) 
 
 
 
 
Черкаси 2025 
 
Черкаський державний технологічний університет 
повне найменування вищого навчального закладу 
Факультет  інформаційних технологій і систем  
Кафедра   програмного забезпечення автоматизованих систем  
Освітній рівень  бакалавр  
Спеціальність  121 «Інженерія програмного забезпечення»  
Освітня програма Інженерія програмного забезпечення  
 
 
 
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
___________                  Голуб С.В. 
«___» _______________ 2025 року 
 
 
 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
       Шевченко Мирослав Віталійович   
(прізвище, ім’я, по батькові) 
1.Тему проекту (роботи) «WEB-застосунок для контролю калорійності харчування»  
Керівник проекту (роботи) Півень Олександр Борисович кандидат наук, доцент  
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від « 25 » лютого 
2025 року №53/03-03 
2. Строк подання студентом проекту (роботи) 16 червня 2025 р.  
3. Вхідні дані до проекту (роботи) Технічне завдання на розробку, методичні рекомендації до 
виконання бакалаврської роботи, автоматизовані системи, терміни та визначення.  
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)  
Вступ; 
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань;  
Розділ 2. Впровадження результатів досліджень у практику проектування програмного  
забезпечення інформаційних систем;  
Розділ 3. Розробка та тестування програмного забезпечення;  
Висновки;  
Список використаних джерел;  
Додатки.  
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;  
Слайд 1; Слайд 2; Слайд 3; Слайд 4; Слайд 5; Слайд 6; Слайд 7; Слайд 8; Слайд 9; Слайд 10; Слайд 
11; Слайд 12; Слайд 13; Слайд 14; Слайд 15; Слайд 16; Слайд 17; Слайд 18; Слайд 19; Слайд 20; 
Слайд 21 Слайд 22, Слайд 23.  
6. Консультанти розділів проекту (роботи) 
Прізвище, ініціали та посади Підпис, дата 
Розділ 
консультанта Завдання видав Завдання прийняв 
1    
2    
3    
 
7. Дата видачі завдання 02 грудня 2025 р.  
  
 
КАЛЕНДАРНИЙ ПЛАН 
Строк 
виконання 
№ 
Назва етапів випускної роботи етапів Примітки 
п/п 
випускної 
роботи 
1 Постановка задачі 05.12.2024 виконано 
2 Підготовка завдання 13.12.2024 виконано 
3 Погодження завдання 16.12.2024 виконано 
4 Затвердження завдання 19.02.2025 виконано 
 Основна стадія   
1 Підбір матеріалів 27.02.2025 виконано 
2 Аналіз шляхів вирішення поставленої задачі 04.03.2025 виконано 
3 Розрахунок основних параметрів роботи 10.03.2025 виконано 
4 Вибір кінцевого варіанту проектного рішення 17.03.2025 виконано 
5 Оформлення первісної редакції роботи 25.03.2025 виконано 
 Заключна стадія   
1 Узгодження прийнятих проектних рішень з 29.04.2025 виконано 
керівником 
2 Оформлення пояснювальної записки роботи в 04.04.2025 виконано 
кінцевій редакції 
3 Попередній захист роботи 10.05.2025 виконано 
4 Затвердження роботи 13.05.2025 виконано 
5 Рецензування роботи 01.06.2025 виконано 
6 Захист роботи 09.06.2025  
 
Студент _____________________ Шевченко М.В. 
  (підпис)   (прізвище та ініціали) 
 
Керівник проекту (роботи) _____________________ Півень О.Б. 
  (підпис)   (прізвище та ініціали) 
 
АНОТАЦІЯ 
Виконавець: Шевченко Мирослав Віталійович 
Назва роботи: «WEB-застосунок для контролю калорійності харчування» 
Спеціальність: 121 Інженерія програмного забезпечення 
Навчальний заклад: Черкаський державний технологічний університет, м. 
Черкаси, 2025 рік 
У кваліфікаційній бакалаврській роботі представлено процес розробки веб-
застосунку, що дозволяє користувачам контролювати денну калорійність та вміст 
нутрієнтів у своєму раціоні. Основною метою створення системи є надання 
зручного цифрового інструменту для обліку прийомів їжі, аналізу харчових звичок 
та візуалізації добових показників споживання. 
У ході виконання проєкту було проведено дослідження потреб кінцевих 
користувачів, визначено функціональні вимоги до системи, спроєктовано 
архітектуру застосунку та реалізовано його інтерфейс і серверну логіку. Для 
розробки застосовувались сучасні технології: React для створення інтерфейсу, 
Node.js з Express для серверної частини, а MongoDB – як основна база даних. 
Основні результати розробки охоплюють: 
– формування вимог: визначено ключові сценарії використання, 
функціональні модулі та нефункціональні обмеження з урахуванням 
зручності, продуктивності та безпеки; 
– моделювання та проектування: створено структурну та логічну схеми 
системи, розроблено схеми бази даних і взаємодії між компонентами 
клієнт-серверної архітектури; 
– реалізація: розроблено повноцінний веб-застосунок, що дозволяє додавати 
продукти до щоденного раціону, автоматично розраховує сумарні калорії, 
білки, жири та вуглеводи, а також надає графічну візуалізацію динаміки 
харчування. 
Отримані результати демонструють, що система відповідає поставленим 
вимогам, є стабільною у роботі та готовою до практичного застосування як 
персональний щоденник харчування. 
Ключові слова: ВЕБ-ЗАСТОСУНОК, REACT, NODE.JS, MONGODB, 
КАЛОРІЇ, НУТРІЄНТИ, КОРИСТУВАЦЬКИЙ ІНТЕРФЕЙС, API, ХАРЧОВИЙ 
ОБЛІК, ВІЗУАЛІЗАЦІЯ, UI/UX, КЛІЄНТ-СЕРВЕРНА АРХІТЕКТУРА
 
 
ANNOTATION 
Author: Shevchenko Myroslav Vitaliiovych 
Title of the thesis: “Web Application for Monitoring Food Caloric Content” 
Specialty: 121 Software Engineering 
Educational institution: Cherkasy State Technological University, Cherkasy, 2025 
The bachelor’s qualification thesis presents the process of developing a web 
application that allows users to track daily caloric intake and nutrient composition in their 
diet. The main goal of the system is to provide a convenient digital tool for logging meals, 
analyzing eating habits, and visualizing daily consumption metrics. 
During the implementation of the project, an analysis of end-user needs was 
conducted, functional requirements were defined, the system architecture was designed, 
and both the user interface and server-side logic were implemented. The development 
process utilized modern technologies: React for building the interface, Node.js with 
Express for the backend, and MongoDB as the primary database. 
The key development outcomes include: 
– requirements formulation: identification of key usage scenarios, functional 
modules, and non-functional constraints considering usability, performance, and 
security; 
– system modeling and design: creation of structural and logical system diagrams, 
database schema design, and definition of interactions between components in 
the client-server architecture; 
– implementation: development of a fully functional web application enabling 
users to add meals to their daily intake, automatically calculate total calories, 
proteins, fats, and carbohydrates, and visualize nutritional trends. 
The obtained results demonstrate that the system meets the specified requirements, 
operates reliably, and is ready for real-world deployment as a personal food tracking diary. 
Keywords: WEB APPLICATION, REACT, NODE.JS, MONGODB, CALORIES, 
NUTRIENTS, USER INTERFACE, API, MEAL TRACKING, VISUALIZATION, 
UI/UX, CLIENT-SERVER ARCHITECTURE 
ʼ 
ЗМІСТ 
ВСТУП ....................................................................................................................... 6 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ ........................................................................................... 10 
1.1 Огляд сучасних підходів до побудови веб-застосунків у сфері харчового 
моніторингу .................................................................................................................... 11 
1.2 Аналіз та моніторинг сучасних веб застосунків контролю харчування . 11 
1.3 Методи реалізації сучасних веб-застосунків контролю харчування ....... 17 
1.4 Постановка задач ........................................................................................... 18 
ВИСНОВКИ ДО ПЕРШОГО РОЗДІЛУ ............................................................... 21 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ ............................................................................................................................ 22 
2.1 Моделювання предметної області ............................................................... 22 
2.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області .................................................................................... 22 
2.1.2 Елементи моделювання предметної області ....................................... 27 
2.1.3 Робоча область моделювання ............................................................... 29 
2.2 Формування та аналіз вимог ........................................................................ 30 
2.2.1 Формування вимог до програмного забезпечення. Первинні і 
детальні вимоги. Вимоги замовника і розробника. Функціональні та 
нефункціональні вимоги ........................................................................................... 30 
ЧДТУ 252175-022 ПЗ 
Змн. Арк. № докум. Підпис Дата 
Розроб. Шевченко М. В. «WEB -застосунок для контролю Літ. Лист Листів 
Перевір. Півень О. Б. калорійності харчування.» 3  
Рецензент Захарова М.В. Пояснювальна записка. 
Н. Контр. Півень О. Б. ФІТІС, кафедра ПЗАС, ПЗ-2104 
 
Затверд. Голуб С. В. 
 
2.2.2 Формування вимог за допомогою діаграми прецедентів .................. 33 
2.3 Проектування логічної структури програмного комплексу ..................... 35 
2.3.1 Діаграми класів ....................................................................................... 36 
2.3.2 Діаграма пакетів ..................................................................................... 40 
2.4 Архітектурне проектування ......................................................................... 42 
2.4.1 Діаграма компонентів ............................................................................ 43 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання ................................................................................................................ 46 
2.5 Моделювання поведінки системи ............................................................... 48 
2.5.1 Діаграма діяльності ................................................................................ 48 
2.5.2 Діаграма послідовності .......................................................................... 50 
2.5.3 Діаграма комунікації .............................................................................. 52 
2.5.4 Діаграма скінченого автомату .............................................................. 54 
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ ................................................................. 56 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
 ............................................................................................................................................. 58 
3.1 Розробка програмного комплексу ............................................................... 58 
3.1.1 Обґрунтування вибору засобів реалізації ...........................................  58 
3.1.2 Опис структурної та функціональної схеми ......................................  60 
3.1.3 Опис логічної схеми системи ................................................................ 64 
3.1.4 Розробка бази даних ............................................................................... 66 
3.1.5 Розробка інтерфейсу користувача .......................................................  71 
3.1.6 Опис розробки програмних компонентів ...........................................  75 
ЧДТУ 252175-022 ПЗ 
Змн. Арк. № докум. Підпис Дата 
      
 
 
3.2 Тестування системи ...................................................................................... 82 
3.2.1 Модульне тестування ............................................................................. 82 
3.2.2 Інтеграційне тестування ........................................................................ 84 
3.2.3 Системне тестування ............................................................................. 85 
3.2.4 Приймальне тестування ......................................................................... 88 
3.3 Приклади впровадженого програмного комплексу ..................................  90 
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ ............................................................... 94 
ВИСНОВКИ ............................................................................................................. 95 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ............................................................... 96 
ДОДАТОК А ............................................................................................................ 98 
ДОДАТОК Б .......................................................................................................... 102 
ДОДАТОК В .......................................................................................................... 119 
ДОДАТОК Г .......................................................................................................... 125 
 
ЧДТУ 252175-022 ПЗ 
Змн. Арк. № докум. Підпис Дата 
      
6 
ЧДТУ 252175.022 ПЗ 
ВСТУП 
Актуальність теми. Розробка програмного забезпечення у сфері 
інформаційних технологій для контролю здоров’я та харчування стала одним із 
пріоритетних напрямів сучасності. Активний розвиток веб-технологій і зростання 
суспільної уваги до здорового способу життя зумовлюють необхідність створення 
нових програмних рішень, здатних забезпечити зручне, ефективне та 
автоматизоване управління харчовими даними.  
Водночас більшість існуючих веб-застосунків для контролю харчування 
мають недоліки, такі як обмежений функціонал, необхідність платної підписки, 
недостатня адаптація до українського ринку та низький рівень інтеграції з 
користувацькими потребами. Важливими аспектами також є зручність 
використання, інтуїтивність інтерфейсу та наявність детальних статистичних звітів 
для користувачів. 
З огляду на це виникає необхідність розробки зручного та ефективного веб-
застосунку для контролю калорійності харчування, що дозволить автоматизувати 
процес обліку спожитих продуктів, підрахунку калорій і нутрієнтів та надання 
користувачам детальних звітів і візуалізації їхнього харчового прогресу[12]. 
Мета розробки. Метою кваліфікаційної роботи є створення повноцінного 
програмного рішення у вигляді веб-застосунку[26], який забезпечуватиме 
користувачів можливістю легко та зручно вести щоденний облік харчування, 
автоматично розраховувати добову калорійність та нутрієнти[3][12], а також 
візуалізувати ці дані у зрозумілому графічному вигляді. 
Завдання розробки:  
1 Провести аналіз сучасних веб-застосунків для контролю калорійності 
харчування та визначити їхні переваги й недоліки. 
2 Сформулювати та деталізувати вимоги до розроблюваного програмного 
комплексу, враховуючи потреби користувачів. 
3 Розробити модель предметної області, яка враховуватиме специфіку 
контролю харчування. 
6 
ЧДТУ 252175.022 ПЗ 
4 Спроектувати архітектуру веб-застосунку з використанням сучасних 
технологій (React[1], Node.js[4], MongoDB[6]). 
5 Реалізувати серверну та клієнтську частини веб-застосунку. 
6 Розробити та налаштувати інтеграцію з базою даних, забезпечивши 
швидкий доступ та ефективну обробку інформації. 
7 Провести комплексне тестування створеної системи, включаючи модульні, 
інтеграційні та приймальні випробування. 
8 Оцінити практичну ефективність використання веб-застосунку в реальних 
умовах. 
Об’єкт розробки. Об'єктом розробки є процес створення програмного 
забепечення у вигляді веб-застосунку для контролю калорійності харчування, 
призначений для забезпечення ефективного та зручного доступу до інформації про 
спожиті калорії та нутрієнти, створення харчових записів, формування звітності й 
аналізу харчових звичок, а також спрощення процесу контролю раціону 
користувачів. 
Предмет розробки. WEB-застосунок для контролю калорійності харчування. 
Для розробки програмного забезпечення веб-застосунку з обліку харчування 
та контролю калорійності були використані такі методи та інструменти: 
– JavaScript та бібліотека React – використані для створення інтерфейсу 
користувача[1]. React дозволив реалізувати динамічний, компонентний 
підхід до побудови інтерфейсу, що забезпечує зручність використання, 
швидкодію та легкість у підтримці застосунку; 
– Tailwind CSS – утилітарний CSS-фреймворк[29], що був використаний для 
побудови адаптивного дизайну. Tailwind дозволив гнучко та швидко 
оформити інтерфейс без використання зовнішніх шаблонів, зберігаючи при 
цьому легкість у кастомізації; 
– Node.js[4] з фреймворком Express[6] – застосовані для реалізації серверної 
частини застосунку. Express забезпечив гнучкий механізм створення 
маршрутизації, обробки HTTP-запитів та реалізації REST API[18], який 
взаємодіє з базою даних та обслуговує потреби клієнта; 
 7 
ЧДТУ 252175.022 ПЗ 
– MongoDB[6] – документно-орієнтована NoSQL база даних[8], яка була 
використана для зберігання інформації про користувачів, продукти, 
харчові плани та звіти. MongoDB[6] забезпечила високу швидкість доступу 
до даних та зручність у масштабуванні структури зберігання; 
– Mongoose – бібліотека для моделювання об’єктів MongoDB[7] у 
середовищі Node.js, що надала інструменти для валідації, перетворення та 
зв’язків між даними; 
– Postman – засіб для тестування API[17], який використовувався на етапі 
налагодження серверної частини, для перевірки запитів та отримання 
відповідей у форматі JSON; 
– Git та GitHub[14] – системи контролю версій, що дозволили вести розробку 
поступово, з можливістю відслідковувати зміни, працювати з гілками та 
співпрацювати у хмарному середовищі; 
– Visual Studio Code[21] – основне середовище розробки, яке 
використовувалось для написання як фронтенд-, так і бекенд-коду завдяки 
підтримці великої кількості плагінів та зручного інтерфейсу; 
– JWT (JSON Web Tokens)[9] – технологія для реалізації авторизації та 
автентифікації користувачів, що дозволяє безпечно передавати токени 
доступу між клієнтом і сервером; 
– UML-діаграми[22] – для проєктування структури системи були 
використані діаграми варіантів використання (use case), класів та 
діяльності, які допомогли наочно відобразити логіку роботи застосунку. 
Опис отриманих результатів. 
Розроблено повноцінний веб-застосунок для контролю калорійності 
харчування, що включає основний функціонал для реєстрації, обліку продуктів та 
візуалізації статистики спожитих калорій і макронутрієнтів. Реалізовано інтерфейс 
користувача, який дозволяє зручно додавати продукти до різних прийомів їжі, 
автоматично обчислювати їх калорійність, а також контролювати щоденне 
споживання білків, жирів і вуглеводів. 
 8 
ЧДТУ 252175.022 ПЗ 
Спроєктовано та створено базу даних, яка зберігає інформацію про продукти, 
користувачів, їх харчові записи, категорії прийомів їжі (сніданок, обід, вечеря тощо) 
та згенеровані звіти. Реалізовано RESTful API[18], яке забезпечує взаємодію між 
клієнтською частиною застосунку та сервером. API включає кінцеві точки для 
додавання, редагування, видалення та отримання даних про продукти, прийоми їжі, 
користувача та зведену статистику. 
Серверна частина застосунку успішно інтегрована з базою даних MongoDB[6], 
що дозволяє ефективно обробляти запити на збереження та отримання даних. 
Здійснено тестування ключових функцій застосунку, зокрема механізмів 
авторизації, створення та обробки харчових записів, підрахунку калорій та генерації 
звітів. На основі зібраних даних реалізовано виведення динамічних графіків та 
зведень, що дозволяють користувачеві відслідковувати прогрес у зручному форматі. 
Розроблене програмне забезпечення для контролю калорійності харчування 
надає користувачам зручний і наочний інструмент для щоденного ведення обліку 
спожитої їжі. Застосунок дозволяє формувати прийоми їжі, обирати продукти зі 
збереженої бази або додавати нові, розраховувати загальну кількість калорій, білків, 
жирів і вуглеводів, а також переглядати статистику по днях, тижнях і місяцях. 
Система значно спрощує процес самоконтролю для користувачів, які 
дотримуються дієт, спортивного режиму або проходять лікування, пов’язане з 
харчовими обмеженнями. Завдяки візуалізації даних у вигляді звітів та графіків, 
користувач отримує чітке уявлення про свій прогрес, що сприяє формуванню 
кращих звичок та досягненню особистих цілей у харчуванні. 
Крім цього, інтеграція з базою даних дозволяє зберігати історію прийомів їжі 
та аналізувати динаміку харчування, що робить застосунок корисним не лише для 
звичайних користувачів, а й для дієтологів, тренерів або медичних фахівців, які 
працюють із пацієнтами. 
 
 9 
ЧДТУ 252175.022 ПЗ 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ 
ЗАВДАНЬ 
Веб-застосунки для контролю калорійності харчування набувають дедалі 
більшої популярності в сфері охорони здоров’я, спорту та повсякденного життя. 
Вони дозволяють користувачам ефективно відстежувати споживання калорій, 
нутрієнтів, формувати здорові харчові звички та досягати поставлених цілей. У 
цьому розділі буде розглянуто існуючі методи, технології та підходи до створення 
таких застосунків, а також приклади їх успішної реалізації. 
Веб-застосунки – це інтерактивні програмні рішення, що працюють у браузері 
та забезпечують зручний доступ до функціональності без необхідності встановлення 
додаткового програмного забезпечення. Вони активно використовуються для 
автоматизації повсякденних завдань, обробки та аналізу даних, інтеграції з іншими 
сервісами, формування звітності тощо. Веб-застосунки для контролю харчування 
дозволяють користувачам ефективно управляти своїм раціоном, слідкувати за 
споживаними калоріями та нутрієнтами, що робить їх важливим інструментом у 
підтримці здорового способу життя. 
Ключовими можливостями є: 
– створення та редагування прийомів їжі (наприклад, сніданок, обід, вечеря); 
– вибір продуктів з попередньо доданої бази або створення нових; 
– автоматичне обчислення калорій та нутрієнтів; 
– перегляд добових цілей та прогресу; 
– формування звітів з графіками. 
Також важливою складовою є можливість аналізу харчових звичок на основі 
зібраних даних. Користувач може бачити, які нутрієнти переважають у його раціоні, 
де є надлишок або нестача, що дозволяє коригувати харчування відповідно до 
власних цілей. 
Подібні системи можуть бути інтегровані з іншими сервісами (наприклад, 
фітнес-додатками), а також доповнені алгоритмами рекомендацій або функціями 
формування дієтичних планів. У майбутньому можлива також підтримка з боку 
10 
ЧДТУ 252175.022 ПЗ 
медичних фахівців, які зможуть дистанційно переглядати харчування клієнта та 
давати поради. 
1.1 Огляд сучасних підходів до побудови веб-застосунків у сфері 
харчового моніторингу 
Контроль калорійності харчування є ключовим елементом здорового способу 
життя, і цифрові рішення відіграють важливу роль у впровадженні цього процесу у 
повсякденність. В умовах зростання популярності персоналізованих систем 
відстеження нутрієнтів розробка веб-застосунків стає пріоритетом для створення 
масштабованих, доступних та адаптивних рішень. 
Серед найбільш популярних онлайн-платформ для відстеження харчування 
можна виділити: 
– FatSecret – дозволяє обліковувати прийоми їжі, рахувати КБЖВ(калорії, 
білки, жири, вуглеводи) та переглядати статистику; 
– Lifesum – сервіси, орієнтовані на візуалізацію макронутрієнтів та 
планування дієт. 
1.2 Аналіз та моніторинг сучасних веб застосунків контролю харчування 
1 FatSecret 
У сучасних умовах стрімкого розвитку веб-технологій та зростаючого попиту 
на цифрові інструменти для ведення здорового способу життя, актуальним є 
ретельне дослідження існуючих веб-рішень, які сприяють покращенню взаємодії з 
користувачем та забезпечують зручність у щоденному використанні. У межах даної 
роботи було проаналізовано функціонування веб-застосунку для контролю 
харчування (рис. 1.1, рис. 1.2, рис. 1.3). Основну увагу зосереджено на таких 
характеристиках, як інтуїтивна навігація, швидкодія інтерфейсу, логічність 
структури даних, адаптація до різних пристроїв та ефективність механізмів обліку 
калорійності та нутрієнтів. Якість користувацького досвіду має вирішальне значення 
для залучення та утримання аудиторії, тому поглиблений аналіз дозволяє виявити не 
лише сильні сторони продукту, а й аспекти, що потребують покращення. 
 11 
ЧДТУ 252175.022 ПЗ 
 
Рисунок 1.1 – Головна сторінка сайту fatsecret.com 
 
 
Рисунок 1.2 – Розділ Food Diary для обліку прийомів їжі 
 12 
ЧДТУ 252175.022 ПЗ 
Основний функціонал розташований у розділі Food Diary, де користувач має 
змогу додавати продукти до різних прийомів їжі: сніданку, обіду, вечері та 
перекусів (рис. 1.2). Інтерфейс розроблений таким чином, щоб будь-яка дія 
виконувалась за декілька кліків. 
Система автоматично підраховує загальну кількість спожитих калорій і 
макронутрієнтів на основі введених даних, а також виводить звіт у вигляді графіка 
(рис. 1.3). Це дозволяє користувачеві легко відслідковувати свій денний баланс і 
відповідність рекомендованим нормам. 
 
 
Рисунок 1.3 – Підсумок дня з розподілом калорій за нутрієнтами 
 
Веб-застосунок FatSecret дозволяє користувачам зручно працювати з 
особистим щоденником харчування: додавати продукти, переглядати їхній склад, 
калорійність, а також отримувати детальну інформацію про співвідношення білків, 
жирів і вуглеводів. Крім того, користувачі мають можливість читати відгуки та 
рецепти інших учасників спільноти, ділитись власними враженнями та вести 
харчовий щоденник у реальному часі. 
Застосунок структурує прийоми їжі за категоріями (сніданок, обід, вечеря, 
перекуси), а також дозволяє застосовувати фільтри до пошуку продуктів, наприклад 
за назвою, категорією чи типом страви. Приклад реалізації структури прийомів їжі 
та системи додавання продуктів зображено на рисунках 1.2 та 1.3. 
Перевагами веб-застосунку FatSecret: 
– безкоштовна повноцінна веб-версія без обов’язкової підписки; 
 13 
ЧДТУ 252175.022 ПЗ 
– велика база локалізованих продуктів (українські та міжнародні бренди); 
– простий та швидкий інтерфейс, що не перевантажений; 
– наявність звітів та історії змін у вазі/споживанні; 
– можливість інтеграції з google fit, samsung health, fitbit тощо; 
– підтримка декількох мов, зокрема й української (через автоматичний 
переклад). 
Недоліки веб-застосунку FatSecret: 
– неможливість імпортувати раціони з інших платформ; 
– обмежена персоналізація інтерфейсу в порівнянні з мобільною версією; 
– веб-версія дещо відстає у розвитку порівняно з мобільною; 
– відсутність глибокого планування раціонів наперед (тільки поточний 
день); 
– іноді трапляються дублікати продуктів у базі (неуніфіковані записи). 
FatSecret демонструє приклад ефективної реалізації веб-застосунку для 
контролю харчування. Його інтерфейс інтуїтивно зрозумілий, що робить платформу 
зручною навіть для новачків. Велика база даних, підтримка створення власних 
страв, ведення харчового щоденника та детальні звіти – усе це формує стабільний 
користувацький досвід. Водночас аналіз дозволяє виявити певні обмеження, які 
можуть бути враховані при розробці власного веб-застосунку: важливо надати 
користувачам більше гнучкості у плануванні раціону наперед, кращу організацію 
бази продуктів та повністю адаптивну систему візуалізації даних. 
2 Cronometer 
У сучасних умовах цифрового моніторингу харчування велике значення має 
детальний аналіз як макро-, так і мікронутрієнтів. Для цього розглянемо 
веб-застосунок Cronometer – платформу з акцентом на точність та глибоке харчове 
відстеження (рис. 1.4, рис. 1.5, рис. 1.6). Основна увага приділяється інтуїтивності 
інтерфейсу, рівню деталізації даних, гнучкості налаштувань та адаптивності 
використання.  
 14 
ЧДТУ 252175.022 ПЗ 
 
Рисунок 1.4 – Головна сторінка веб-версії Cronometer 
 
 
Рисунок 1.5 – Консолідований щоденний огляд спожитих нутрієнтів 
 
 
Рисунок 1.6 – Розгорнуті дані за макро- та мікронутрієнтами 
 15 
ЧДТУ 252175.022 ПЗ 
У розділі "Diary" користувач додає продукти за допомогою пошуку або 
сканування штрих-кодів – таким чином формується щоденний звіт (рис. 1.8). 
Особливістю сервісу є відображення поживних речовин (рис. 1.9). 
Система дозволяє створювати власні страви, зберігати рецепти, а також 
інтегрувати дані з Apple Health або фітнес-трекерами для автоматичного 
коригування енергоспоживання 
Переваги веб-застосунку Lifesum: 
– глибокий аналіз мікро- й макронутрієнтів – значно перевищує стандартне 
відстеження калорій; 
– потужна база даних, включаючи штрих-коди та покриття понад 95 % 
вживаних продуктів; 
– інтеграція з мобільними платформами (apple watch, google fit) і 
синхронізація тренувальних даних; 
– безкоштовний доступ до деталей щоденного харчування – преміум-версія 
розширює аналітику, але основний функціонал доступний користувачам 
безкоштовно. 
Недоліки веб-застосунку Lifesum: 
– інтерфейс менш “мобільний” і сучасний, ніж у деяких конкурентів; 
– менш розвинена соціальна складова і мотиваційні функції порівняно з 
myfitnesspal; 
– наявні недоліки у локалізації – акцент на глобальних продуктах, менше 
даних по локальній кухні. 
Cronometer є відмінним прикладом веб-застосунку для точного харчового 
обліку. Його сильні сторони – детальна нутрієнтна аналітика, висока точність даних 
та інтеграція зі сторонніми пристроями. Цей досвід показує, що для власного 
проєкту варто передбачити більше шарів даних (зокрема мікронутрієнтів), 
забезпечити можливість введення штрих-кодів і врахувати налаштування 
 16 
ЧДТУ 252175.022 ПЗ 
інтеграційних можливостей, щоб задовольнити потреби користувачів, що прагнуть 
всебічного моніторингу харчування. 
1.3 Методи реалізації сучасних веб-застосунків контролю харчування 
Розробка сучасних веб-застосунків для контролю калорійності харчування 
виконується із застосуванням широкого спектра технологій, які забезпечують 
зручний інтерфейс, стабільну роботу системи, надійне зберігання даних та швидкий 
обмін інформацією між клієнтом і сервером. 
На рівні клієнтської частини застосовуються JavaScript-бібліотеки, зокрема: 
– React – компонентно-орієнтована бібліотека для створення динамічних і 
адаптивних інтерфейсів. Вона дозволяє швидко реалізовувати змінні стани 
інтерфейсу користувача, забезпечує масштабованість проєкту та повторне 
використання компонентів [1]; 
– Tailwind CSS – утилітарний CSS-фреймворк, що дає змогу створювати 
сучасний адаптивний дизайн без необхідності писати багато кастомного 
CSS. Він пришвидшує процес верстки та забезпечує високу гнучкість у 
стилізації елементів. 
Для серверної частини (backend) було використано: 
– Node.js з фреймворком Express – платформа для створення веб-сервісів, що 
дозволяє будувати RESTful API для взаємодії з клієнтською частиною. 
Express забезпечує зручне управління маршрутами, обробку запитів, 
middleware та логіку авторизації; 
– JWT (JSON Web Token) – для реалізації захищеної аутентифікації та 
передачі токенів доступу, що дозволяє здійснювати запити до серверу у 
безпечному режимі. 
Як систему керування базами даних було обрано: 
– MongoDB[6] – документо-орієнтовану NoSQL базу даних, яка добре 
підходить для гнучкого зберігання харчових записів, продуктів, планів 
харчування та користувацьких звітів. Для зручної взаємодії з нею 
застосовується бібліотека Mongoose, що дозволяє описувати схеми, 
 17 
ЧДТУ 252175.022 ПЗ 
проводити валідацію даних і формувати запити. Завдяки гнучкій структурі 
документів MongoDB легко масштабувати систему в разі зростання 
кількості даних і користувачів. Також MongoDB має вбудовані можливості 
для ефективного пошуку, фільтрації та агрегації даних, що суттєво 
спрощує аналіз і формування звітності в додатку. 
Для забезпечення зручної та організованої розробки також використовувалися: 
– Visual Studio Code[21] (VS Code) – легке, але потужне середовище 
розробки з широким набором розширень, підтримкою підсвітки 
синтаксису, автодоповненням і терміналом; 
– Git та GitHub – системи контролю версій, які дали змогу керувати 
проєктом, зберігати історію змін, створювати окремі гілки для реалізації 
функцій та проводити командну роботу; 
– Postman[16] – інструмент для тестування API-запитів між клієнтською та 
серверною частинами, що використовувався на етапі налагодження REST 
API[18]; 
– UML-діаграми[22] – для моделювання структури системи, включаючи 
діаграми варіантів використання, класів і діяльності. 
Застосування перелічених технологій дозволяє створити надійний, 
функціональний та масштабований веб-застосунок, що задовольняє сучасні вимоги 
до цифрових сервісів у сфері здорового харчування. Забезпечення чіткої 
архітектури, безпеки даних, адаптивності та зручного інтерфейсу – ключові умови, 
що були враховані при реалізації системи. 
1.4 Постановка задач 
За результатами аналізу сучасних веб-застосунків для контролю харчування, 
дослідження їхніх функціональних можливостей, зручності використання, 
ефективності обробки даних та візуалізації, а також порівняння сильних і слабких 
сторін аналогічних рішень, можна сформувати перелік завдань, необхідних для 
досягнення мети розробки власного програмного продукту. 
 18 
ЧДТУ 252175.022 ПЗ 
Розробка веб-застосунку для контролю калорійності харчування потребує 
вирішення низки завдань, які охоплюють етапи аналізу, проектування, реалізації, 
тестування та оцінки системи, з урахуванням потреб користувачів та забезпечення 
зручного й інтуїтивно зрозумілого інтерфейсу. Система має бути стабільною, 
безпечною та легкою у використанні як для звичайного користувача, так і для 
адміністратора. 
Аналіз потреб користувачів: 
– визначення основних сценаріїв використання системи (додавання 
продуктів, перегляд статистики, підрахунок калорійності); 
– вивчення звичних моделей харчування та очікувань користувачів від таких 
сервісів (точність, зручність, мобільність). 
Формування вимог до системи: 
– визначення функціональних вимог: реєстрація, створення харчових 
записів, підрахунок калорій, візуалізація статистики, редагування профілю 
користувача тощо. 
– визначення нефункціональних вимог: простота інтерфейсу, адаптивність 
до мобільних пристроїв, швидкодія, безпека персональних даних. 
Вибір технологій: 
– вибір клієнтської платформи – бібліотека React для створення SPA-
застосунку[1]; 
– вибір серверного середовища – Node.js[4] + Express[5] для реалізації API; 
– вибір бази даних – MongoDB[6] з ORM Mongoose[7] для зберігання 
інформації про користувачів, продукти, записи та налаштування; 
– вибір інструментів для перевірки API – Postman[16], для контролю доступу 
– JWT[9]. 
Проектування та реалізація системи: 
– розробка архітектури системи (структура даних, маршрути, компоненти); 
– реалізація основного функціоналу згідно з технічними та UX-вимогами; 
 19 
ЧДТУ 252175.022 ПЗ 
– інтеграція клієнтської та серверної частин, організація роботи з базою 
даних. 
Тестування та валідація: 
– проведення модульного та інтеграційного тестування для перевірки 
стабільності системи; 
– функціональне тестування базових сценаріїв: створення, редагування та 
видалення записів, перегляд статистики; 
– валідація системи шляхом імітації реального використання та отримання 
зворотного зв’язку. 
Підсумовуючи, можна зазначити, що розробка веб-застосунку для контролю 
калорійності харчування є комплексним завданням, яке вимагає багаторівневого 
підходу – від аналізу цільової аудиторії до тестування готового продукту. 
Виконання цих етапів дозволить створити зручний, адаптивний і ефективний 
інструмент для щоденного контролю раціону, що сприятиме формуванню здорових 
харчових звичок користувачів. 
  
 20 
ЧДТУ 252175.022 ПЗ 
ВИСНОВКИ ДО ПЕРШОГО РОЗДІЛУ 
У першому розділі було проведено огляд сучасних веб-застосунків для 
контролю калорійності харчування, що дало змогу визначити актуальні підходи до 
побудови подібних систем, а також дослідити переваги та недоліки популярних 
платформ, таких як FatSecret, Cronometer.  
Проаналізовано методи розробки веб-застосунків, архітектурні принципи та 
технології, що використовуються у цій сфері. На основі вивченого матеріалу 
сформовано перелік завдань, необхідних для реалізації власного веб-застосунку, 
адаптованого під потреби користувачів, з урахуванням функціональності, зручності 
інтерфейсу та ефективності обробки даних.  
 
 21 
ЧДТУ 252175.022 ПЗ 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ 
2.1 Моделювання предметної області 
Моделювання предметної області[28] є важливим етапом розробки 
інформаційної системи, оскільки дозволяє глибше зрозуміти реальні процеси, які 
повинні бути автоматизовані. Це створює основу для подальшого проєктування 
структури програмного забезпечення, визначення зв’язків між сутностями, а також 
формування вимог до системи. 
У цьому підпункті буде розглянуто ключові складові моделювання предметної 
області[28] веб-застосунку для контролю калорійності харчування, а саме: 
предметна область моделювання, модель предметної області, словник основних 
понять, опис логіки взаємодії між об’єктами в межах системи. 
Загальне уявлення про функціонування системи на цьому етапі дозволить 
ефективно перейти до визначення вимог і побудови логічної структури програмного 
комплексу. Тепер розглянемо кожен із зазначених аспектів більш детально. 
2.1.1 Предметна область моделювання. Модель предметної області. Словник 
предметної області 
Предметна область моделювання. Моделювання предметної області[28] для 
веб-застосунку з контролю калорійності харчування охоплює всі аспекти процесу 
відстеження споживання їжі, підрахунку калорій та аналізу нутрієнтів з метою 
формування здорового раціону. Система має на меті забезпечити зручний і 
ефективний спосіб фіксації харчових звичок користувачів та обробки введених 
даних, 
Основні компоненти предметної області включають: 
– реєстрація та авторизація користувачів: процес створення особистого 
профілю із введенням таких даних, як ім’я, email та пароль. це дозволяє 
системі  зберігати історію активності користувача; 
22 
ЧДТУ 252175.022 ПЗ 
– створення харчових записів: користувач має можливість додавати до свого 
щоденника продукти харчування, обираючи з бази або додаючи власні. 
кожен запис містить інформацію про продукт, кількість, калорійність та 
співвідношення макронутрієнтів (білків, жирів, вуглеводів); 
– автоматичний підрахунок калорій та нутрієнтів: система на основі 
введених даних обчислює загальну кількість спожитих калорій за день, а 
також надає деталізовану інформацію щодо споживання білків, жирів і 
вуглеводів у вигляді діаграми; 
– перегляд статистики та аналітики: користувач може переглядати динаміку 
свого харчування, аналізувати середні показники, стежити за відхиленнями 
від рекомендованої норми та візуально оцінювати прогрес у досягненні 
поставленої мети. 
Моделювання предметної області[28] дозволяє чітко визначити структуру 
системи, функціональні модулі та логіку взаємодії між ними. Це є основою для 
ефективного проєктування архітектури веб-застосунку, мінімізації ризиків на етапі 
реалізації та забезпечення відповідності системи очікуванням користувачів. 
Модель предметної області. Моделювання предметної області[28] для веб-
застосунку контролю калорійності харчування охоплює процеси взаємодії 
користувача із системою для фіксації харчових прийомів, підрахунку калорій та 
перегляду історії харчування. Основна мета – надати користувачу інструмент для 
ведення харчового щоденника з мінімальним бар’єром входу, простим 
функціоналом і базовою аналітикою. 
Основні компоненти предметної області. 
1 Реєстрація та авторизація користувачів 
Користувач створює обліковий запис із введенням базових даних: 
– email – унікальний ідентифікатор; 
– пароль – зашифрований та зберігається у базі; 
– ім’я користувача – для відображення у профілі. 
Ці дані дозволяють авторизуватися в системі та персоналізувати контент. 
2 Продукти 
 23 
ЧДТУ 252175.022 ПЗ 
Продукти – основна одиниця даних, яку додає користувач до свого 
щоденника, для того, щоб мати змогу у створювати та змінювати свій раціон  
Кожен продукт містить: 
– назву; 
– калорійність (в ккал); 
– співвідношення білків, жирів, вуглеводів (БЖВ); 
– вагу (в грамах); 
– дату створення/додавання. 
Продукти можуть бути додані вручну користувачем або обрані зі збережених. 
3 Прийоми їжі (харчові записи) 
Користувач має змогу формувати щоденні прийоми їжі шляхом додавання 
одного або кількох продуктів: 
– категорії прийомів їжі: сніданок, обід, вечеря, перекус; 
– кожен запис містить список продуктів та їхню кількість; 
– автоматично розраховується загальна калорійність та сумарне БЖВ. 
4 Журнал харчування 
Усі записи зберігаються у вигляді журналу: 
– за датою; 
– з розподілом за прийомами їжі; 
– з автоматичним підсумком денного споживання калорій і нутрієнтів. 
5 Візуалізація статистики 
На основі збережених записів система формує графік або таблицю зі 
статистикою: 
– щоденне споживання калорій; 
– структура БЖВ. 
Схематична модель предметної області: 
1 Користувачі: 
– email; 
– пароль; 
– список записів за днями. 
 24 
ЧДТУ 252175.022 ПЗ 
2 Продукти: 
– назва; 
– калорії; 
– білки, жири, вуглеводи; 
– вага. 
3 Записи: 
– дата; 
– прийом їжі (тип); 
– список продуктів; 
– розрахована сумарна калорійність і БЖВ. 
Моделювання предметної області[28] дозволяє: 
– чітко структурувати логіку збереження та обробки даних; 
– ефективно організувати взаємодію між клієнтською та серверною 
частинами; 
– сформувати основу для розширення функціоналу, наприклад, додавання 
системи рекомендацій або графіків прогресу. 
Таким чином, побудова моделі предметної області є необхідним етапом, що 
гарантує цілісність структури даних, простоту використання та подальшу підтримку 
проєкту. 
Словник предметної області 
Веб-застосунок – програмне забезпечення, що працює у браузері без 
необхідності встановлення на пристрій. Дозволяє користувачам взаємодіяти із 
системою в режимі реального часу через інтерфейс, доступний з будь-якого 
пристрою з доступом до Інтернету. 
Користувач – зареєстрована особа, яка взаємодіє з веб-застосунком. Має 
персональний обліковий запис і може додавати харчові записи, переглядати 
статистику та керувати своїми даними. 
Продукт харчування – одиниця обліку в системі, що містить інформацію про 
назву, калорійність, вміст білків, жирів і вуглеводів (БЖВ), а також масу (в грамах). 
 25 
ЧДТУ 252175.022 ПЗ 
Прийом їжі – група продуктів, доданих користувачем у певний момент доби 
(наприклад, сніданок, обід, вечеря або перекус), що зберігається у системі з датою. 
Харчовий щоденник – набір записів користувача, які містять інформацію про 
спожиті продукти за певний день. Формується автоматично на основі прийомів їжі. 
Статистика – аналітична інформація про калорійність та склад харчування, 
сформована за записами користувача. Може бути подана у вигляді числових значень 
або графіків. 
Реєстрація – процес створення нового облікового запису, який включає 
введення email та паролю. Після реєстрації користувач отримує доступ до 
персонального харчового щоденника. 
Авторизація – процедура входу до системи з використанням наданих під час 
реєстрації облікових даних. 
Node.js[4] – серверна платформа для виконання JavaScript-коду поза межами 
браузера, що використовується для створення бекенд-частини застосунку. 
Express[5] – фреймворк для Node.js[4], який спрощує створення REST API[18] 
та обробку HTTP-запитів. 
MongoDB[6] – документно-орієнтована NoSQL база даних, яка 
використовується для зберігання інформації про користувачів, продукти, записи та 
інші сутності системи. 
Mongoose[7] – бібліотека для Node.js[4], яка забезпечує об’єктно-документне 
моделювання (ODM) даних у MongoDB та спрощує роботу з базою даних. 
React[1] – JavaScript-бібліотека для створення інтерфейсів користувача, що 
дозволяє будувати адаптивні та масштабовані односторінкові застосунки (SPA)[1]. 
Tailwind CSS – CSS-фреймворк, що забезпечує швидку та адаптивну верстку 
інтерфейсів шляхом використання утилітарних класів. 
JWT (JSON Web Token) – стандарт токенів для передачі зашифрованої 
інформації між клієнтом і сервером, який використовується для реалізації 
аутентифікації користувачів. 
 26 
ЧДТУ 252175.022 ПЗ 
Цей словник дозволяє чітко визначити ключові поняття, що використовуються 
у процесі розробки та впровадження веб-застосунку для контролю калорійності 
харчування, та слугує основою для кращого розуміння структури та логіки системи. 
2.1.2 Елементи моделювання предметної області 
У процесі моделювання предметної області[28] для веб-застосунку контролю 
калорійності харчування використовуються різні елементи мови моделювання 
UML[23] (Unified Modeling Language), що дозволяють наочно представити 
структуру системи, її логіку та взаємозв’язки між об’єктами. Це забезпечує 
зручність у проєктуванні, реалізації та подальшому вдосконаленні системи. 
 
 
Рисунок 2.1 – Основні графічні позначення UML для WEB застосунку контролю 
калорійності харчування 
 
 27 
ЧДТУ 252175.022 ПЗ 
Для побудови моделі предметної області даного веб-застосунку 
використовуються діаграми UML[22] як універсальний інструмент для візуалізації, 
документування та проектування програмних систем. UML-нотація[24] дозволяє 
структурувати дані, описати функціональність системи та відобразити динаміку 
взаємодії між основними компонентами. 
До основних елементів, які використовуються при моделюванні предметної 
області, належать: 
– класи – логічні сутності, що описують основні об’єкти системи, такі як 
user, product, meal, stats; 
– об’єкти – конкретні екземпляри класів, що представляють індивідуальні 
одиниці з реальними значеннями атрибутів; 
– атрибути – характеристики класів, що зберігають дані про об’єкти 
(наприклад: calories, name, weight, email); 
– методи – дії, які можуть виконувати об’єкти (наприклад: addproduct(), 
calculatetotalcalories()); 
– асоціації – зв’язки між класами, які показують відношення між об’єктами 
системи (наприклад, один користувач може мати багато харчових записів). 
 
 
Рисунок 2.2 – Приклади UML-зв’язків та асоціацій для WEB застосунку контролю 
калорійності харчування 
 28 
ЧДТУ 252175.022 ПЗ 
 
Застосування UML діаграм[22] дозволяє формалізувати вимоги до системи, 
створити наочну модель її структури, а також полегшує комунікацію між 
розробниками, замовником і тестувальниками. Це важливий етап у процесі 
побудови якісного, надійного та підтримуваного веб-застосунку. 
2.1.3 Робоча область моделювання 
Робоча область моделювання охоплює всі ключові компоненти системи, що 
підлягають візуалізації, аналізу та подальшому проектуванню. У контексті розробки 
веб-застосунку для контролю калорійності харчування ця область включає всі 
сутності, функції та взаємозв’язки, які необхідні для реалізації основного 
функціоналу системи – обліку продуктів, ведення харчового щоденника, розрахунку 
калорійності та формування звітності. 
Робоча область моделювання визначає структуру інформаційної системи, 
включаючи опис сутностей, їх атрибутів, взаємодій між об'єктами та 
функціональних процесів, що підлягають автоматизації. Це дозволяє забезпечити 
узгодженість проєктних рішень, сформувати логіку взаємодії між клієнтською і 
серверною частинами, а також мінімізувати ризики помилок під час реалізації. 
 
 
Рисунок 2.3 – Модель предметної області для WEB застосунку контролю 
калорійності харчування 
 29 
ЧДТУ 252175.022 ПЗ 
Основні компоненти: 
1 Користувачі (Users). 
2 Продукти (Products). 
3 Прийоми їжі (Meals). 
4 Щоденник харчування (Food Diary). 
5 Статистика (Statistics). 
6 Звіти (Reports). 
2.2 Формування та аналіз вимог 
Ретельне формування та аналіз вимог є ключовим етапом у процесі розробки 
будь-якого програмного забезпечення. Цей підрозділ містить опис основних 
очікувань від системи з боку кінцевих користувачів та інших зацікавлених сторін, а 
також аналізує, яким чином ці вимоги впливають на архітектуру і функціонал 
майбутнього застосунку. 
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні вимоги 
Первинні й детальні вимоги. Вимоги замовника та розробника. Функціональні 
та нефункціональні вимоги. 
Формування вимог до програмного забезпечення є критично важливим 
етапом у процесі створення будь-якої інформаційної системи, зокрема веб-
застосунку для контролю калорійності харчування. Цей процес включає збір, аналіз, 
документування та узгодження очікувань користувачів із можливостями реалізації. 
Чітко сформульовані вимоги слугують основою для розробки технічного завдання, 
проектування архітектури, реалізації та тестування системи. 
Первинні вимоги. Ці вимоги описують основні можливості, які має надати 
система користувачу, без заглиблення в технічні деталі. Вони слугують орієнтиром 
для формування більш конкретних функціональних сценаріїв у наступних етапах 
розробки та визначають загальну функціональність системи: 
– веб-застосунок повинен забезпечувати реєстрацію та авторизацію 
користувачів за email та паролем; 
 30 
ЧДТУ 252175.022 ПЗ 
– користувачі повинні мати можливість додавати продукти з вказанням 
назви, калорійності, білків, жирів, вуглеводів та ваги; 
– система повинна дозволяти формувати прийоми їжі та обраховувати 
сумарну калорійність та БЖВ; 
– користувачі повинні мати доступ до щоденника харчування з історією 
споживання; 
– застосунок повинен формувати статистику та графіки за день або обраний 
період. 
Детальні вимоги розкривають конкретні умови реалізації кожної з функцій, 
визначених у первинних вимогах. Вони описують структуру інтерфейсів, логіку 
обробки даних, формат взаємодії користувача із застосунком та інші технічні 
аспекти, які мають бути враховані під час розробки. Ці вимоги служать 
безпосереднім джерелом для створення технічного завдання та програмної реалізації 
включають конкретні її умови: 
1 Реєстрація та авторизація: 
‒ форма повинна мати валідацію полів email і пароля; 
‒ після успішної реєстрації – автоматичне перенаправлення до профілю. 
2 Додавання продуктів: 
‒ користувач має ввести назву, калорійність, білки, жири, вуглеводи та 
вагу продукту; 
‒ підтримка редагування або видалення продуктів зі списку. 
3 Формування прийомів їжі: 
‒ можливість обрати продукти та додати до категорій: сніданок, обід, 
вечеря, перекус; 
‒ автоматичний розрахунок підсумкової калорійності та БЖВ. 
4 Ведення щоденника: 
‒ збереження харчових записів за датою; 
‒ можливість перегляду та редагування записів за минулі дні. 
5 Статистика та звіти: 
‒ виведення графіків на основі спожитих калорій; 
 31 
ЧДТУ 252175.022 ПЗ 
‒ аналітична інформація про середнє споживання БЖВ. 
Вимоги замовника визначають очікування кінцевих користувачів – простота 
використання, зручний інтерфейс, стабільна робота та конфіденційність даних: 
– зручний, інтуїтивно зрозумілий інтерфейс; 
– доступ до щоденної статистики; 
– можливість вручну додавати власні продукти; 
– швидке додавання їжі та перегляд історії споживання; 
– конфіденційність даних. 
Вимоги розробника описують технічні засоби реалізації системи, зокрема 
обрану архітектуру, стек технологій, принципи масштабованості та підтримуваності. 
Формування обох типів вимог дозволяє узгодити бачення функціоналу з точки зору 
користувача та з технічної сторони: 
– клієнтська частина: React + Tailwind CSS[29]; 
– серверна частина: Node.js[4] + Express[5]; 
– база даних: MongoDB[6] з використанням бібліотеки Mongoose; 
– авторизація: JWT; 
– REST API для обміну даними між клієнтом і сервером[18]; 
– модульна архітектура для зручності підтримки та масштабування. 
Функціональні вимоги деталізують, які конкретні дії повинна виконувати 
система, зокрема: додавання продуктів, створення прийомів їжі, обчислення 
калорійності, відображення щоденника та формування статистики. Вони визначають 
взаємодію між користувачем і програмою, логіку роботи окремих компонентів та 
результати цих взаємодій: 
– реєстрація та авторизація користувачів; 
– додавання та редагування продуктів; 
– створення прийомів їжі з продуктів; 
– автоматичний розрахунок калорій та БЖВ; 
– збереження та перегляд щоденника харчування; 
– візуалізація статистики та звітів. 
 32 
ЧДТУ 252175.022 ПЗ 
Нефункціональні вимоги визначають якісні характеристики системи, які не 
залежать від конкретного функціоналу, але мають суттєвий вплив на досвід 
використання. Сюди належать продуктивність, безпека, доступність, 
масштабованість, зручність інтерфейсу тощо. Вони є критично важливими для 
забезпечення стабільної та ефективної роботи застосунку: 
– продуктивність: час відповіді системи на запити користувача – не більше 
1–2 секунд; 
– безпека: шифрування паролів, захист даних через jwt; 
– інтерфейсність: spa-застосунок з адаптивним дизайном; 
– надійність: стабільна робота без критичних помилок, збереження даних без 
втрат; 
– масштабованість: система має підтримувати розширення функціоналу без 
суттєвої перебудови архітектури. 
Формування вимог є важливим етапом, що впливає на всю подальшу розробку 
веб-застосунку. Коректно сформульовані вимоги дозволяють створити зручний, 
стабільний і функціонально повний продукт, який задовольняє потреби кінцевого 
користувача та відповідає технічним можливостям розробки. 
2.2.2 Формування вимог за допомогою діаграми прецедентів 
Діаграма прецедентів ілюструє взаємодію користувачів (акторів) із системою 
через функціональні сценарії використання (прецеденти). Вона дозволяє наочно 
відобразити, які дії може виконувати користувач у межах веб-застосунку, що 
допомагає у плануванні, реалізації та тестуванні системи. 
У випадку з веб-застосунком контролю харчування, єдиним актором є 
користувач, який взаємодіє з системою для реєстрації, ведення щоденника 
харчування, перегляду статистики та керування власним раціоном. 
 33 
ЧДТУ 252175.022 ПЗ 
 
Рисунок 2.4 – Діаграма прецедентів для WEB застосунку контролю калорійності 
харчування 
 
Опис Прецедентів: 
1 Реєстрація користувача: 
– актор: користувач; 
– опис: користувач заповнює форму реєстрації, вводячи email та пароль. 
Після підтвердження даних обліковий запис створюється, і користувач 
отримує доступ до персонального кабінету. 
2 Авторизація користувача: 
– актор: користувач; 
– опис: користувач вводить свої облікові дані (email і пароль) для входу в 
систему. У разі успішного входу відкривається головна сторінка 
застосунку. 
3 Додавання продукту: 
– актор: користувач; 
 34 
ЧДТУ 252175.022 ПЗ 
– опис: користувач створює продукт із вказанням назви, калорійності, 
БЖВ та ваги. Продукт додається до бази користувача для подальшого 
використання. 
4 Створення прийому їжі: 
– актор: користувач; 
– опис: користувач обирає продукти та формує прийом їжі (сніданок, 
обід, вечеря або перекус). Система автоматично підраховує сумарну 
калорійність та БЖВ. 
5 Перегляд щоденника харчування: 
– актор: користувач; 
– опис: користувач переглядає записи про харчування за конкретну дату, 
з розподілом по прийомах їжі та підсумковими показниками. 
6 Перегляд статистики: 
– актор: користувач; 
– опис: система генерує статистику на основі записів у щоденнику – 
загальна кількість калорій, співвідношення білків, жирів і вуглеводів, 
динаміка споживання за день або тиждень. 
7 Формування звітів: 
– актор: користувач; 
– опис: користувач обирає часовий період (день, тиждень, місяць), і 
система формує відповідний звіт зі зведеною інформацією про 
споживання калорій і нутрієнтів. 
Діаграма прецедентів допомагає узагальнити ключові функції системи та 
встановити логічні зв’язки між потребами користувача та реалізованими 
можливостями. Вона формує основу для модульної реалізації функціоналу веб-
застосунку відповідно до очікувань цільової аудиторії. 
2.3 Проектування логічної структури програмного комплексу  
У цьому підрозділі буде розглянуто логічну архітектуру веб-застосунку для 
контролю харчування. Спочатку представлено діаграму класів, що відображає 
 35 
ЧДТУ 252175.022 ПЗ 
взаємозв’язки між ключовими об’єктами системи, їхні методи та атрибути. Далі 
розглянуто діаграму пакетів, що групує компоненти системи в логічні модулі – це 
спрощує управління складністю програмного коду та його підтримку. 
2.3.1 Діаграми класів 
Для відображення логічної структури веб-застосунку побудовано діаграму 
класів, яка складається з шести основних сутностей: 
– користувач (user); 
– продукт (product); 
– прийом їжі (meal); 
– щоденник харчування (fooddiary); 
– статистика (statistics); 
– звіт (report). 
Основні зв’язки: 
– користувач → щоденник харчування: створює, переглядає; 
– щоденник → прийом їжі: містить записи; 
– прийом їжі → продукт: складається з продуктів; 
– користувач → статистика: отримує дані; 
– користувач → звіт: формує за обраний період. 
 
 
Рисунок 2.5 – Діаграма класів без атрибутів та методів для WEB застосунку 
контролю калорійності харчування 
 
 36 
ЧДТУ 252175.022 ПЗ 
Всі класи потрібно заповнити необхідними атрибутами та методами 
(рисунок 2.6), посилаючись на їх ключову функціональність у системі: 
Користувач: 
– реєструєтся в системі, вказавши електронну пошту та пароль; 
– авторизується для доступу до персонального щоденника харчування; 
– створює прийоми їжі, переглядати статистику та формувати звіти. 
Прийом їжі: 
– зберігає інформацію про дату, тип прийому (сніданок, обід, вечеря 
тощо);може включати кілька продуктів; 
– використовується для підрахунку калорій і нутрієнтів. 
Запис продукту в прийомі їжі: 
– зберігає інформацію про продукт, його вагу та розраховані нутрієнти; 
– є частиною конкретного прийому їжі. 
Продукт: 
– зберігає основну інформацію про продукт харчування; 
включає поживну цінність на 100 грамів. 
Звіт: 
– зберігає підсумкову інформацію про споживання калорій та нутрієнтів за 
вибраний період; 
– може бути сформований на вимогу користувача. 
 
 
Рисунок 2.6 – Діаграма класів для WEB застосунку контролю калорійності 
харчування 
 37 
ЧДТУ 252175.022 ПЗ 
1 Клас User 
Атрибути: 
– id: String; 
– email: String; 
– password: String; 
– createdAt: Date. 
Методи: 
– register(): void; 
– login(): void; 
– getDiary(): FoodDiary; 
– viewStatistics(): Statistics; 
– generateReport(period: String): Report. 
2 Клас Meal 
Атрибути: 
– id: String; 
– userId: String; 
– type: String; 
– date: Date. 
Методи: 
– addProduct(product: Product): void; 
– calculateTotals(): Object. 
3 Клас MealItem 
Атрибути: 
– id: String; 
– mealId: String; 
 38 
ЧДТУ 252175.022 ПЗ 
– foodId: String; 
– weightGrams: Number. 
Методи: 
– linkToMeal(mealId): void; 
– recalculateNutrition(): void. 
4 Клас FoodItem 
Атрибути: 
– id: String; 
– name: String; 
– caloriesPer100g: Number; 
– proteinPer100g: Number; 
– fatPer100g: Number; 
– carbsPer100g: Number. 
Методи: 
– create(): void; 
– update(): void; 
– delete(): void. 
5 Клас Report 
Атрибути: 
– id: String; 
– userId: String; 
– date: Date; 
– totalCalories: Number; 
– totalProteins: Number; 
– totalFats: Number; 
– totalCarbs: Number. 
Методи: 
– generate(): Object; 
 39 
ЧДТУ 252175.022 ПЗ 
– export(format: String): File. 
Ця діаграма класів відображає логіку та взаємодію основних об’єктів веб-
застосунку контролю харчування. Вона допомагає розробнику зрозуміти структуру 
системи, визначити перелік необхідних методів та атрибутів, а також побудувати 
ефективну та масштабовану архітектуру. 
2.3.2 Діаграма пакетів 
Діаграма пакетів в UML[22] використовується для представлення 
високорівневої структури програмної системи, де компоненти згруповані у логічні 
модулі (пакети). Це дозволяє зрозуміти архітектуру системи, спростити її аналіз, 
проєктування та майбутнє масштабування: 
– user management – управління користувачами та їх авторизацією; 
– meal management – керування прийомами їжі та доданими продуктами; 
– food management – робота з базою продуктів та поживними значеннями; 
–  reports – генерація аналітики та звітів на основі харчового щоденника. 
Опис пакетів: 
1 User Management 
Сутності: 
– User (користувач). 
Функціональність: 
– реєстрація та авторизація користувача; 
– зберігання базових облікових даних; 
– взаємодія з персональним харчовим щоденником, статистикою та 
звітами. 
2 Meal Managemen 
Сутності: 
– Meal (Прийом їжі); 
 40 
ЧДТУ 252175.022 ПЗ 
– MealItem (Продукт у прийомі їжі). 
Функціональність: 
– створення та редагування прийомів їжі; 
– розрахунок калорійності та БЖВ; 
– облік харчування за типами прийомів (сніданок, обід тощо); 
– прив’язка продуктів до прийому їжі. 
3 Food Management 
Сутності: 
– FoodItem (Продукт харчування). 
Функціональність: 
– створення продуктів із зазначенням калорійності та нутрієнтів; 
– зберігання користувацької бази харчових продуктів; 
– повторне використання збережених продуктів у прийомах їжі. 
4 Statistics & Reports 
Сутності: 
– Statistics; 
– Report. 
Функціональність: 
– формування аналітичної інформації про споживання калорій та БЖВ; 
– виведення щоденної, тижневої та місячної статистики; 
– генерація звітів за обраний період; 
– візуалізація даних у вигляді таблиць і графіків. 
Діаграма пакетів допомагає візуалізувати загальну архітектуру веб-застосунку, 
визначити логічні зони відповідальності в системі та спростити розділення проєкту 
на модулі під час розробки. Така структура покращує читабельність коду, сприяє  
 41 
ЧДТУ 252175.022 ПЗ 
зручній підтримці та гнучкому розширенню функціоналу. 
 
 
Рисунок 2.7 – Діаграма пакетів для WEB застосунку контролю калорійності 
харчування 
 
2.4 Архітектурне проектування 
 42 
ЧДТУ 252175.022 ПЗ 
Діаграма компонентів в UML[22] застосовується для моделювання структури 
фізичної реалізації системи. Вона дозволяє наочно відобразити ключові програмні 
компоненти, способи їхньої взаємодії, залежності між модулями, а також 
використані інтерфейси та сервіси. 
2.4.1 Діаграма компонентів 
Компоненти системи: 
1 User Interface 
Функції: 
– інтерфейс користувача для взаємодії з системою (реєстрація, перегляд 
щоденника, додавання прийомів їжі, статистика); 
– реалізований на основі React[1]. 
Залежності: 
– звертається до REST API для отримання та надсилання даних[18]; 
– взаємодіє з Meal, Food, User, Statistics сервісами через бекенд; 
– Authentication Service. 
2 Register Interface 
Функції: 
– обробка реєстрації та входу користувачів; 
– перевірка токенів доступу; 
– забезпечення безпеки сесій. 
Залежності: 
– працює з User Database; 
– генерує/перевіряє JWT токени. 
3 User Service 
Функції: 
– зберігання профілю користувача; 
– взаємодія з харчовим щоденником та звітами. 
Залежності: 
– Database Service; 
– Authentication Service. 
 43 
ЧДТУ 252175.022 ПЗ 
4 Meal Service 
Функції: 
– створення та зберігання прийомів їжі; 
– розрахунок підсумкової калорійності та БЖВ. 
Залежності: 
– Food Service (для складу продуктів); 
– Database. 
5 Food Service 
Функції: 
– створення і редагування продуктів харчування; 
– розрахунок поживної цінності. 
Залежності: 
– зберігає дані в Food Database; 
– використовується Meal Service. 
6 Statistics & Reporting Service 
Функції: 
– збір даних із щоденника; 
– побудова графіків та звітів; 
– аналіз споживання по калоріях та нутрієнтах. 
Залежності: 
– звертається до Meal Service і User Service; 
– надає результати через API до інтерфейсу. 
7 Database Service 
Функції: 
– централізоване зберігання інформації про користувачів, продукти, 
прийоми їжі, статистику та звіти; 
– побудована на базі MongoDB[6]. 
Залежності: 
– використовується всіма сервісами; 
– доступ через Mongoose ODM. 
 44 
ЧДТУ 252175.022 ПЗ 
8 REST API (Backend Controller Layer) 
Функції: 
– координація запитів від фронтенду; 
– реалізовано з використанням Node.js[4] + Express[5]. 
Залежності: 
– зв'язує всі сервіси через маршрути та контролери. 
 
 
Рисунок 2.8 – Діаграма компонентів для WEB застосунку контролю калорійності 
харчування 
 45 
ЧДТУ 252175.022 ПЗ 
Діаграма компонентів допомагає сформувати загальне уявлення про фізичну 
архітектуру системи. Вона чітко показує, які програмні частини відповідають за ту 
чи іншу логіку, як вони пов’язані між собою, та які канали комунікації між 
компонентами забезпечують цілісну роботу веб-застосунку Calorie Tracker. 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання 
Розгортання веб-застосунку для контрольню харчування включає розміщення 
ключових програмних компонентів на відповідних апаратних засобах або хмарній 
інфраструктурі. Архітектура базується на клієнт-серверній моделі, яка передбачає 
окремі середовища для фронтенду, бекенду та бази даних. 
Система включає такі основні елементи: клієнтський інтерфейс (React[1]), 
сервер додатку (Node.js[4] + Express[5]) з реалізацією REST API та сервер бази 
даних MongoDB[6]. Для автентифікації використовується JWT (JSON Web 
Token)[9], який передається у заголовках HTTP-запитів для доступу до захищених 
маршрутів. 
 
 
Рисунок 2.9 – Діаграма розгортання для WEB застосунку контролю калорійності 
харчування 
 46 
ЧДТУ 252175.022 ПЗ 
Основні компоненти розгортання: 
1. Клієнтський браузер: 
– завантажує інтерфейс застосунку, реалізований на react[1]; 
– надсилає http-запити до api-сервера, включаючи jwt-токен у заголовку 
authorization[9]. 
2. Frontend Server: 
– містить збірку react-застосунку (npm run dev); 
– розміщується власному сервері; 
– відповідає за взаємодію з користувачем. 
3. Backend Server: 
– реалізований на node.js[4] із використанням express[5]; 
– обробляє rest-запити, реалізує логіку роботи сервісів: 
– Authentication Service – обробка реєстрації, входу та генерація JWT[9]; 
– User Service – збереження облікових даних; 
– Meal Service – облік прийомів їжі; 
– Food Service – керування продуктами; 
– Report Service – розрахунок БЖВ, формування звітів; 
– має доступ до бази даних mongodb[6]. 
4. Database Server: 
– зберігає всі дані користувачів, продуктів, прийомів їжі, а також звітів; 
– реалізований на mongodb[6] (локально або в хмарному сервісі, 
наприклад, MongoDB Atlas[7]); 
– доступний лише для backend-сервера. 
Загальний процес взаємодії: 
1 Користувач відкриває React-застосунок у браузері (через Frontend 
Server). 
2 Після автентифікації за допомогою Authentication Service користувач 
отримує JWT[9]. 
3 Усі наступні API-запити надсилаються з токеном у заголовку 
Authorization. 
 47 
ЧДТУ 252175.022 ПЗ 
4 Backend обробляє запити, взаємодіє з базою даних і повертає відповідь 
клієнту. 
Діаграма розгортання дозволяє візуально уявити фізичну структуру системи, 
визначити основні вузли розміщення програмних компонентів і їхню взаємодію. 
Такий підхід забезпечує гнучке масштабування, безпечну автентифікацію, а також 
чітке розділення відповідальності між частинами системи. Завдяки цьому 
підвищується надійність, продуктивність і розширюваність веб-застосунку. 
2.5 Моделювання поведінки системи 
У цьому підрозділі буде проаналізовано динамічну поведінку веб-застосунку 
контролю калорійності харчування. Моделювання поведінки дає змогу описати, 
яким чином користувач взаємодіє з системою, як система реагує на дії користувача, 
та які стани вона проходить у процесі функціонування. 
Розгляд включає такі діаграми: 
– діаграму діяльності, яка відображає послідовність основних дій 
користувача в системі; 
– діаграму послідовності, що показує обмін повідомленнями між об’єктами в 
часовому порядку; 
– діаграму комунікації, яка підкреслює структурні зв’язки між об’єктами під 
час виконання певного сценарію; 
– діаграму станів, яка відображає зміни стану об’єктів залежно від 
внутрішніх або зовнішніх подій. 
Ці діаграми дозволяють краще зрозуміти логіку роботи застосунку, знизити 
ризики проектування і забезпечити передбачувану поведінку системи під час 
розробки та тестування. 
2.5.1 Діаграма діяльності 
Діаграма діяльності використовується для моделювання послідовності дій 
користувача під час взаємодії з веб-застосунком для контролю калорійності 
харчування. 
 48 
ЧДТУ 252175.022 ПЗ 
 
Рисунок 2.10 – Діаграмі діяльності для WEB застосунку контролю калорійності 
харчування 
 
Основні кроки: 
– запускає веб-застосунок у браузері; 
– проходить реєстрацію або вхід в обліковий запис; 
– потрапляє на головну сторінку з поточним щоденником; 
– додає новий прийом їжі, вибирає продукти зі списку; 
– система розраховує калорії, білки, жири, вуглеводи; 
– користувач може переглянути статистику споживання за день/тиждень; 
– оновлює цілі у профілі (наприклад, бажану кількість калорій/бжв). 
 49 
ЧДТУ 252175.022 ПЗ 
2.5.2 Діаграма послідовності 
Діаграма послідовності ілюструє послідовну взаємодію між основними 
об'єктами системи (користувач, клієнтський інтерфейс, сервер, база даних) під час 
виконання базових дій. У цьому випадку описано ключові сценарії використання 
додатку: авторизація, додавання прийому їжі, редагування, видалення, вихід із 
системи. 
Основні сценарії взаємодії: 
1. Авторизація користувача: 
– користувач відкриває вебзастосунок у браузері; 
– вводить логін та пароль; 
– дані передаються на сервер для перевірки; 
– у разі успіху повертається токен автентифікації та відкривається 
інтерфейс додатку. 
2 Додавання прийому їжі: 
– користувач натискає кнопку "додати прийом їжі"; 
– обирає тип (сніданок/обід/вечеря), додає продукти, вводить їх вагу; 
– дані надсилаються на сервер; 
– сервер обробляє запит та зберігає прийом їжі у базу даних; 
– повертається оновлений список, прогрес-бари змінюються у реальному 
часі. 
3 Редагування прийому їжі: 
– користувач відкриває запис з прийомом їжі; 
– отримує дані з сервера; 
– вносить зміни (наприклад, змінює кількість продукту); 
– зміни надсилаються на сервер; 
– дані оновлюються в базі та відображаються оновленими в ui. 
4 Видалення прийому їжі: 
– користувач натискає “видалити”; 
– система запитує підтвердження; 
– після підтвердження сервер видаляє запис із бази; 
 50 
ЧДТУ 252175.022 ПЗ 
– інтерфейс оновлюється, запис зникає зі списку. 
5 Вихід із системи: 
– користувач натискає “вийти”; 
– токен видаляється, сесія завершується. 
 
 
Рисунок 2.11 – Діаграма послідовності для WEB застосунку контролю калорійності 
харчування 
 51 
ЧДТУ 252175.022 ПЗ 
2.5.3 Діаграма комунікації 
Діаграма комунікації описує взаємодію між об'єктами системи під час 
виконання ключових сценаріїв використання додатку. Вона фокусується на обміні 
повідомленнями між клієнтом, сервером та базою даних, відображаючи порядок і 
напрямок передачі даних. 
 
 
Рисунок 2.12 – Діаграма комунікації для WEB застосунку контролю калорійності 
харчування 
 
Основні сценарії взаємодії: 
1. Авторизація користувача: 
– мета: надати доступ до функціоналу системи лише автентифікованим 
користувачам; 
Ключові кроки: 
1 Користувач вводить email і пароль у формі логіну; 
2 Клієнт надсилає запит до AuthController; 
3 Контролер звертається до бази даних і перевіряє облікові дані; 
4 У разі успіху база повертає токен автентифікації; 
 52 
ЧДТУ 252175.022 ПЗ 
5 Токен зберігається на клієнті, відкривається головний інтерфейс. 
2. Додавання прийому їжі: 
– мета: зафіксувати прийом їжі та розрахувати його КБЖВ. 
Ключові кроки: 
1 Користувач обирає категорію (сніданок, обід тощо) та вводить дані про 
продукт і вагу; 
2 Клієнт надсилає ці дані до MealsController; 
3 Контролер обробляє інформацію через сервіс і виконує збереження в 
MongoDB[6]; 
4 Після збереження сервер повертає оновлені дані; 
5 Інтерфейс оновлює прогрес-бари та відображає прийом у списку. 
3. Редагування прийому їжі: 
– мета: змінити дані раніше доданого прийому. 
Ключові кроки: 
1 Користувач відкриває потрібний прийом; 
2 Клієнт надсилає запит на отримання даних з MealsController; 
3 Користувач вносить зміни; 
4 Клієнт надсилає оновлення на сервер; 
5 Контролер оновлює запис у базі даних; 
6 Користувач бачить оновлені значення на екрані. 
4. Видалення прийому їжі: 
– мета: прибрати непотрібний або помилковий запис. 
Ключові кроки: 
1 Користувач натискає кнопку “Видалити”; 
2 Клієнт надсилає DELETE-запит до MealsController; 
 53 
ЧДТУ 252175.022 ПЗ 
3 Контролер видаляє відповідний документ з бази даних; 
4 Повертається статус виконання; 
5 Клієнт видаляє запис з інтерфейсу. 
2.5.4 Діаграма скінченого автомату 
Діаграма скінченного автомату демонструє зміну станів додатку залежно від 
дій користувача. Кожна дія викликає перехід системи з одного стану до іншого. Це 
дозволяє формалізувати поведінку програми, забезпечити передбачуваність 
взаємодії та уникнути логічних помилок у бізнес-логіці. 
 
 
Рисунок 2.13 – Діаграма скінченного автомату для WEB застосунку контролю 
калорійності харчування 
 
Основні стани та переходи: 
1 Початковий стан: 
– користувач відкриває додаток через веббраузер; 
– відображається форма авторизації або реєстрації. 
2 Авторизований користувач: 
– після успішного входу користувач потрапляє на головну сторінку; 
 54 
ЧДТУ 252175.022 ПЗ 
– відображаються прогрес-бари та статистика за день. 
3 Додавання прийому їжі: 
– користувач переходить у розділ “додати їжу”; 
– вибирає категорію (сніданок/обід/вечеря); 
– вводить дані (продукт, кількість, тощо); 
– система переходить у стан "очікування збереження". 
4 Прийом збережено: 
– після успішного запиту до сервера і відповіді – система оновлює 
інтерфейс і переходить у стан "прийом додано"; 
5 Редагування або видалення прийому: 
– користувач відкриває існуючий запис і змінює його або видаляє; 
– система переходить у стан "редагування/видалення в процесі"; 
– після відповіді сервера повертається до стану "дані оновлено". 
6 Перехід до звітів: 
– користувач переходить до вкладки “звіти”; 
– система змінює стан на "візуалізація даних". 
7 Редагування цілей: 
– перехід у профіль, зміна добових норм; 
– стан змінюється на "налаштування цілей". 
8 Завершення сесії: 
– користувач натискає “вийти”; 
– система повертається у "початковий стан", обнуляється токен і 
припиняється сесія. 
  
 55 
ЧДТУ 252175.022 ПЗ 
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ 
У другому розділі було здійснено системне моделювання програмного 
забезпечення вебзастосунку для контролю калорійності харчування. Проведено 
аналіз предметної області, визначено її межі, сформовано ключові поняття та 
створено модель предметної області, яка включає сутності, атрибути та 
взаємозв’язки між ними. Сформовано словник основних термінів, які 
використовуються в системі, що дозволяє однозначно трактувати всі поняття на 
етапі проєктування та розробки. 
На основі сформульованих цілей і задач було визначено первинні та 
деталізовані вимоги до функціональності системи з урахуванням очікувань 
кінцевого користувача та технічних особливостей реалізації. Виокремлено 
функціональні та нефункціональні вимоги, що стали основою для побудови UML-
діаграм[22] і архітектурного планування. 
Побудовано діаграму прецедентів, яка демонструє основні сценарії взаємодії 
користувача з системою: авторизація, додавання прийомів їжі, перегляд звітів, 
редагування або видалення записів тощо. На її основі розроблено діаграму класів, 
яка відображає структуру даних та об’єктно-орієнтовану модель застосунку: класи, 
їх атрибути, методи та зв’язки. Основними класами є: User, Meal, Product, Goal, 
Report. Визначено їхню взаємодію, що дозволяє побудувати логічну структуру 
застосунку, зручно масштабовану та підтримувану. 
Діаграма пакетів відображає логічну структуру додатку, що складається з 
окремих модулів – клієнтської частини, серверної логіки, контролерів, сервісів, DTO 
та репозиторіїв, що полегшує тестування та підтримку коду. 
В межах архітектурного проєктування побудовано діаграму компонентів, яка 
описує логічні частини системи: інтерфейс користувача, backend API, бізнес-логіку 
та базу даних. Діаграма розгортання описує, як ці компоненти функціонують у 
реальному середовищі на різних пристроях користувача та серверній 
інфраструктурі. 
У розділі також побудовано поведінкові UML-діаграми[22]. Діаграма 
діяльності описує покроковий алгоритм взаємодії користувача з системою. Діаграма 
 56 
ЧДТУ 252175.022 ПЗ 
послідовності фіксує порядок обміну повідомленнями між компонентами під час 
виконання ключових сценаріїв. Діаграма комунікації акцентує на структурі 
взаємозв’язків між об'єктами в процесі виконання сценаріїв. Діаграма скінченного 
автомату демонструє зміну станів системи залежно від дій користувача (наприклад, 
логін, створення або видалення прийому їжі, перегляд статистики). 
Таким чином, другий розділ сформував чітке уявлення про структуру, логіку 
та поведінку системи, що забезпечило основу для ефективного і цілісного процесу 
реалізації вебзастосунку на наступних етапах розробки. 
 
 57 
ЧДТУ 252175.022 ПЗ 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
3.1 Розробка програмного комплексу 
У цьому підрозділі описано процес розробки веб-застосунку для контролю 
калорійності харчування – від обґрунтування вибору технологій до реалізації 
функціональності та інтеграції компонентів. Детально розглянуто технічні засоби, 
що використовувалися для створення клієнтської та серверної частин системи, а 
також бази даних, яка забезпечує зберігання користувацької інформації. 
3.1.1 Обґрунтування вибору засобів реалізації 
Розробка веб-застосунку вимагала вибору надійних, продуктивних та 
сучасних інструментів, які дозволяють швидко створювати масштабовані рішення з 
інтуїтивним інтерфейсом. При виборі стеку технологій враховувалися такі критерії: 
швидкодія, активна підтримка спільноти, наявність екосистеми бібліотек, 
можливість розгортання як на локальному сервері, так і в хмарному середовищі. 
1 Мова програмування JavaScript 
JavaScript було обрано як основну мову розробки як для фронтенд, так і для 
бекенд частини через такі переваги: 
– мова має велику спільноту розробників, що забезпечує постійну 
підтримку та активне оновлення інструментів; 
– можливість використовувати одну мову як на клієнті, так і на сервері 
зменшує складність проєкту; 
– мова підтримує асинхронне програмування (через async/await), що 
дозволяє обробляти запити без блокування основного потоку. 
2 React – бібліотека для створення інтерфейсу користувача 
React обрано як основу для побудови фронтенд-частини застосунку 
завдяки[1]: 
– компонентній архітектурі, яка дозволяє створювати повторно 
використовувані елементи; 
58 
ЧДТУ 252175.022 ПЗ 
– підтримці хуків, що спрощують керування станом і життєвим циклом 
компонентів; 
– великій екосистемі: можливість швидкої інтеграції з tailwind css[29], 
react[1] router, zustand, chart.js та іншими інструментами; 
– продуктивності: завдяки віртуальному dom інтерфейс працює швидко 
навіть на слабших пристроях. 
3 Node.js[4] та Express[5] для створення серверної частини 
Node.js[4] – асинхронне серверне середовище, яке забезпечує високу 
продуктивність і масштабованість. Express.js[5] обрано як легковаговий фреймворк 
для побудови RESTful API. 
Переваги цього стеку: 
– гнучка структура проекту з можливістю створення окремих модулів 
(контролери, маршрути, middleware); 
– широка підтримка пакетів через npm, таких як cors, jsonwebtoken, 
dotenv, mongoose та інші; 
– простота налаштування та розгортання на більшості серверів. 
4 MongoDB[6] – база даних 
MongoDB[6] обрана як база даних через: 
– гнучкий формат документів (json-подібна структура), який дозволяє 
легко працювати з різнорідними та вкладеними об'єктами (наприклад, 
харчовими записами, користувацькими налаштуваннями); 
– масштабованість та високу продуктивність під час роботи з великими 
обсягами даних; 
– підтримку індексів для пришвидшення запитів; 
– інтеграцію з mongoose – orm-бібліотекою, яка спрощує створення 
моделей та валідацію даних. 
5 Додаткові інструменти: 
– Zustand – мінімалістичне сховище стану для React[1], що  
 59 
ЧДТУ 252175.022 ПЗ 
використовується для збереження глобального стану (наприклад, 
авторизація користувача, добовий калораж); 
– Tailwind CSS – утилітарний CSS-фреймворк, який дозволяє швидко 
створювати адаптивні, сучасні інтерфейси без необхідності писати 
багато кастомного CSS-коду; 
– Chart.js – бібліотека для побудови графіків, використовується у 
візуалізації статистики калорій та макронутрієнтів; 
– JWT (JSON Web Tokens) – технологія для реалізації безпечної 
аутентифікації. 
3.1.2 Опис структурної та функціональної схеми 
Функціональна схема (рисунок 3.1) веб-застосунку для контролю калорійності 
харчування демонструє основні компоненти системи та принципи їх взаємодії. 
Схема дозволяє візуально уявити архітектуру застосунку та логіку взаємозв’язків 
між клієнтською частиною, серверною логікою та базою даних. 
 
 
Рисунок 3.1 – Функціональна схема WEB застосунку контролю калорійності 
харчування 
 60 
ЧДТУ 252175.022 ПЗ 
Система умовно поділяється на три основні частини 
1. Клієнтська частина (frontend, React): 
– головна сторінка – доступ до загального інтерфейсу, навігація між 
розділами; 
– форма реєстрації та авторизації – забезпечує доступ до особистого 
кабінету користувача за допомогою jwt; 
– харчовий щоденник – інтерфейс для додавання продуктів до прийомів 
їжі (сніданок, обід, вечеря, перекус); 
– статистика та графіки – візуалізація добових результатів у вигляді 
діаграм (калорії, білки, жири, вуглеводи); 
– налаштування профілю – встановлення добової норми КБЖВ 
відповідно до параметрів користувача. 
2. Серверна частина (backend, Node.js[4] + Express[5]): 
– сервіс аутентифікації – обробка реєстрації, логіну, генерація та 
перевірка jwt-токенів; 
– сервіс продуктів – управління базою харчових продуктів, підрахунок 
калорійності та нутрієнтів; 
– сервіс харчових записів – обробка додавання, редагування, видалення 
записів прийомів їжі; 
– сервіс аналітики – підрахунок статистики, формування звітів і графіків 
по днях; 
– сервіс користувачів – зберігання та оновлення даних користувача, 
добової норми, цілей тощо. 
3. База даних (MongoDB[6]): 
– колекція users – зберігає дані користувачів: логін, хеш паролю, ціль, 
добова норма КБЖВ; 
– колекція products – список доступних продуктів з інформацією про 
калорійність і нутрієнти; 
– колекція entries – записи прийомів їжі з датами, типами прийомів 
(сніданок, обід тощо), продуктами, їх кількістю та підсумковою  
 61 
ЧДТУ 252175.022 ПЗ 
калорійністю; 
– колекція statistics – агреговані значення для побудови графіків. 
Структурна схема веб-застосунку відображає узгоджену роботу всіх його 
частин. Користувач взаємодіє з інтерфейсом у браузері, який через REST API 
надсилає запити на сервер. Сервер обробляє запити, звертається до відповідних 
колекцій бази даних, обчислює підсумки та повертає результат клієнту для 
відображення у вигляді діаграм і списків. 
Такий підхід дозволяє створити модульну, масштабовану та зручну у 
використанні систему, що охоплює всі ключові потреби користувача щодо обліку 
харчування та аналізу його ефективності. 
Структурна схема (рисунок 3.2) веб-застосунку для контролю калорійності 
харчування демонструє ключові компоненти системи та їхню взаємодію. Схема дає 
змогу наочно зрозуміти архітектуру проєкту та логіку передачі даних між клієнтом, 
сервером і базою даних. 
 
 
Рисунок 3.2 – Структурна схема WEB застосунку контролю калорійності 
харчування 
 
1 Клієнтська частина (frontend, React): 
 62 
ЧДТУ 252175.022 ПЗ 
– головна сторінка – слугує навігаційним центром між розділами 
системи; 
– форма реєстрації та входу – надає доступ до облікового запису через 
авторизацію за jwt-токеном; 
– сторінка додавання прийомів їжі – інтерфейс для внесення даних про 
прийоми їжі з розрахунком калорій; 
– сторінка “статистика” – візуалізує результати у вигляді графіків 
(калорії, білки, жири, вуглеводи); 
– сторінка “профіль” – дозволяє редагувати індивідуальні цілі: добову 
норму калорій і нутрієнтів. 
2 Серверна частина (backend, node.js + express): 
– сервіс аутентифікації – обробляє логін, реєстрацію, генерацію токенів 
доступу; 
– сервіс продуктів – crud-операції з продуктами, включно з розрахунком 
калорійності; 
– сервіс прийомів їжі – збереження записів (дата, тип, продукти, 
кількість, сумарна калорійність); 
– сервіс аналітики – агрегує дані за днями для формування звітів і 
графіків; 
– сервіс користувачів – зберігає і оновлює параметри профілю, цілі та 
налаштування. 
3 База даних (MongoDB): 
– колекція users – облікові записи: ім’я, email, хеш паролю, добові цілі; 
– колекція products – база продуктів з нутрієнтними властивостями; 
– колекція meals (entries) – список прийомів їжі з датами, продуктами та 
обсягами; 
– колекція goals – цілі користувача щодо калорійності, білків, жирів, 
вуглеводів. 
Структурна схема відображає єдину логіку роботи веб-застосунку: користувач 
взаємодіє з React-інтерфейсом у браузері, який надсилає запити через REST API до 
 63 
ЧДТУ 252175.022 ПЗ 
серверу. Сервер, обробляючи запити, звертається до відповідних колекцій у 
MongoDB, обчислює необхідні дані (калорійність, статистику тощо) і повертає 
результат користувачеві у зручному вигляді. 
Такий підхід дозволяє реалізувати гнучку, масштабовану та модульну 
систему, яка ефективно вирішує завдання обліку харчування та надає користувачам 
зручний інструмент для відстеження динаміки особистих харчових звичок. Це 
сприяє формуванню здорового способу життя шляхом підвищення обізнаності про 
власне харчування. 
3.1.3 Опис логічної схеми системи 
Логічна схема веб-застосунку (рисунок 3.3) для контролю калорійності 
харчування побудована на взаємодії клієнтської частини, серверної логіки та бази 
даних. 
 
 
Рисунок 3.3 – Логічна схема роботи WEB застосунку контролю калорійності 
харчування 
 64 
ЧДТУ 252175.022 ПЗ 
Вона включає основні операції: додавання продуктів харчування, створення 
прийомів їжі, розрахунок калорійності та макронутрієнтів, перегляд звітів і 
оновлення даних користувача. 
Послідовність роботи системи наступна: 
1. Запуск веб-застосунку: 
– користувач відкриває веб-застосунок у браузері; 
– завантажується головна сторінка з можливістю входу або реєстрації. 
2. Реєстрація користувача: 
– користувач переходить до форми реєстрації; 
– вводить ім’я, email та пароль; 
– дані надсилаються на сервер; 
– сервер перевіряє email, хешує пароль, створює обліковий запис у базі 
users; 
– користувач автоматично входить у систему після реєстрації. 
3. Додавання прийому їжі: 
– користувач відкриває розділ "meals"; 
– обирає тип прийому їжі (сніданок, обід, вечеря, перекус); 
– додає продукт, вказує кількість; 
– система автоматично підраховує калорійність та нутрієнти; 
– інформація зберігається у колекції entries. 
4. Перегляд статистики: 
– користувач переходить у розділ “reports”; 
– застосунок надсилає запит на сервер; 
– сервер агрегує дані з entries та формує звіт; 
– звіт виводиться у вигляді діаграм (калорії, білки, жири, вуглеводи). 
5. Оновлення цілей: 
– користувач переходить до розділу “goals”; 
– вводить бажані добові норми калорій, білків, жирів, вуглеводів; 
– дані надсилаються до api (put /goals); 
 65 
ЧДТУ 252175.022 ПЗ 
– сервер оновлює або створює документ у колекції goals, пов’язаний із 
 користувачем. 
Логічна схема веб-застосунку для контролю калорійності харчування детально 
описує послідовність дій, що виконуються користувачем під час взаємодії із 
системою – від реєстрації до додавання харчових записів, перегляду статистики та 
оновлення добових цілей. У схемі відображено основні етапи, починаючи із запуску 
застосунку та завершуючи обробкою і збереженням даних у базі. Графічна 
інтерпретація у вигляді блок-схеми алгоритму дозволяє наочно побачити логіку 
роботи системи та взаємодію між її ключовими компонентами. 
3.1.4 Розробка бази даних 
Розробка бази даних є ключовим етапом створення веб-застосунку для 
контролю калорійності харчування, оскільки вона забезпечує надійне зберігання, 
структурування та ефективну обробку даних користувачів, прийомів їжі, продуктів 
та цілей. У цьому проєкті використано MongoDB[6] – документно-орієнтовану 
NoSQL базу даних, що дозволяє зберігати дані у форматі JSON-подібних 
документів. Це забезпечує гнучкість моделювання та простоту масштабування. 
1 Аналіз вимог: 
– визначення основних сутностей: користувачі, продукти, прийоми їжі, 
індивідуальні цілі. 
– встановлення зв’язків між колекціями: усі сутності пов’язані через 
userid. 
2 Проєктування структури даних: 
– для кожної сутності створено окрему схему mongoose; 
– поля обрано згідно з функціональністю застосунку (наприклад, білки, 
жири, вуглеводи – обов'язкові поля у продуктах і прийомах їжі); 
– індекси створено на полях userid, email, date тощо для оптимізації 
запитів. 
3 Реалізація: 
– створено 4 основні колекції: users, products, meals, goals; 
 66 
ЧДТУ 252175.022 ПЗ 
– усі взаємодії реалізовано через api-запити на сервер, який обробляє 
crud-операції з цими колекціями; 
– для взаємодії з mongodb[6] використано бібліотеку mongoose. 
4 Тестування: 
– проведено модульне тестування api-запитів до кожної колекції; 
– тестовано поведінку при некоректних даних (наприклад, негативні 
значення калорій); 
– перевірено продуктивність запитів до індексованих полів. 
Структура основних колекцій. 
1. Колекція users 
Зберігає основну інформацію про користувачів: 
– name – ім’я користувача; 
– email – унікальна адреса електронної пошти; 
– password – хешований пароль; 
– Автоматичне збереження дати створення (timestamps). 
Індексовано по email для швидкого пошуку при автентифікації. 
 
 
Рисунок 3.4 - Схема колекції `users` WEB застосунку контролю калорійності 
харчування 
 67 
ЧДТУ 252175.022 ПЗ 
2. Колекція goals 
Містить добові цілі по нутрієнтах для кожного користувача: 
– calories, protein, fat, carbs – числові значення; 
– userId – посилання на користувача; 
– гарантується унікальність userId для одного набору цілей. 
Використовується у формуванні рекомендацій у статистиці. 
 
 
Рисунок 3.5 - Схема колекції `goals` WEB застосунку контролю калорійності 
харчування 
 68 
ЧДТУ 252175.022 ПЗ 
3. Колекція products 
Містить список харчових продуктів, доданих користувачем: 
– name – назва продукту; 
– calories, protein, fat, carbs – нутрієнти; 
– userId – зв’язок із користувачем; 
– дата створення (timestamps). 
 Індекс по userId + name для унікальності продуктів у межах одного 
користувача. 
 
 
Рисунок 3.6 - Схема колекції `products` WEB застосунку контролю калорійності 
харчування 
 69 
ЧДТУ 252175.022 ПЗ 
4. Колекція meals 
Зберігає інформацію про прийоми їжі: 
– name – назва прийому (наприклад, "Обід"); 
– category – тип (breakfast/lunch/dinner/snack); 
– date – дата прийому; 
– products – масив продуктів з кількістю та розрахованими КБЖВ; 
– userId – зв'язок із користувачем. 
 Індекс по userId + date для оптимізації перегляду за датами. 
 
 
Рисунок 3.7 - Схема колекції `meals` WEB застосунку контролю калорійності 
харчування 
 70 
ЧДТУ 252175.022 ПЗ 
База даних спроєктована з урахуванням масштабованості та гнучкості. 
Завдяки використанню MongoDB[6] та Mongoose[7] забезпечено простоту інтеграції 
з сервером на Node.js[4], ефективну обробку даних та збереження індивідуальних 
параметрів кожного користувача. Такий підхід дає змогу розширювати систему без 
необхідності складних міграцій у майбутньому. 
3.1.5 Розробка інтерфейсу користувача 
Розробка інтерфейсу користувача (UI) є ключовим етапом створення веб-
застосунку для контролю калорійності харчування. Від зручності та логічності 
інтерфейсу значною мірою залежить ефективність взаємодії користувача з 
системою, а також загальний досвід використання. Інтерфейс має бути інтуїтивним, 
візуально зрозумілим і відповідати потребам користувачів із різними рівнями 
технічної підготовки. 
Процес створення UI включає визначення вимог до інтерфейсу, розробку 
ключових елементів взаємодії, тестування на зручність і подальшу оптимізацію. 
Основні вимоги до інтерфейсу користувача: 
– інтуїтивність та простота: застосунок має легко сприйматись навіть 
новими користувачами без необхідності навчання; 
– доступність: інтерфейс повинен бути адаптивним до різних типів 
пристроїв (десктоп, мобільний), підтримувати читабельність і зручність 
керування; 
– функціональна повнота: інтерфейс повинен забезпечувати простий доступ 
до ключових функцій: реєстрації, ведення харчового щоденника, перегляду 
статистики та керування добовими цілями. 
Проектування основних компонентів інтерфейсу: 
– головна сторінка(рис 3.8), що відображає загальний огляд щоденного 
споживання калорій і макронутрієнтів у вигляді прогрес-барів та 
статистичних показників; 
– секції прийомів їжі знаходится на головеній сторінці, де користувач може 
додавати, або видаляти прийоми їжі (сніданок, обід, вечеря та перекуси) з  
 71 
ЧДТУ 252175.022 ПЗ 
деталізацією продуктів. 
 
 
Рисунок 3.8 – Головна сторінка WEB застосунку контролю калорійності харчування 
 
Список продуктів харчування(рис. 3.9), що містить базу доступних продуктів 
із можливістю пошуку та додавання у прийоми їжі. 
 
 
Рисунок 3.9 – Форма додавання продуктів до раціону 
 72 
ЧДТУ 252175.022 ПЗ 
Форма додавання нових  продуктів(рис 3.10) оснащена валідацією для 
контролю правильності введених даних. 
 
 
Рисунок 3.10 – Форма додавання нових продуктів 
 
Збережені продукти(рис. 3.11) де зібрані усі додані продукти користувача 
 
 
Рисунок 3.11 – Секція збережених продуктів 
 73 
ЧДТУ 252175.022 ПЗ 
Профіль користувача має вкладку Nutrition Goals(рис. 3.12), де користувач сам 
може ставити цілі споживання калорій і макронутрієнтів на день.  
 
 
Рисунок 3.12 – Сторінка редагування споживання калорій і макронутрієнтів 
 
Звіт(рис. 3.13) це частина веб інтерфейсу, де користувач може переглянути 
свій прогрес споживання споживання калорій і макронутрієнтів за певний відрізок 
часу.  
 
 74 
ЧДТУ 252175.022 ПЗ 
 
Рисунок 3.13 – Сторінка звіту 
 
Розробка інтерфейсу користувача для веб-застосунку контролю калорійності 
харчування охоплює етапи визначення вимог до зручності та логіки взаємодії, 
проєктування основних екранів, а також тестування і подальшу оптимізацію. 
Інтерфейс повинен бути інтуїтивним, функціональним і доступним для широкого 
кола користувачів[2][10]. Проведення тестування на різних пристроях дозволяє 
переконатися у стабільності та ефективності роботи системи за різних сценаріїв 
використання. 
3.1.6 Опис розробки програмних компонентів 
Розробка програмних компонентів веб-застосунку для контролю калорійності 
харчування передбачає створення окремих модулів, кожен з яких відповідає за 
реалізацію певної функціональності системи. Компоненти реалізовано з 
урахуванням вимог до продуктивності, надійності та простоти масштабування. Всі 
 75 
ЧДТУ 252175.022 ПЗ 
основні функції системи побудовані як незалежні логічні частини, що взаємодіють із 
базою даних MongoDB[6] через відповідні схеми.  
Основні програмні компоненти: 
1 Компонент автентифікації та реєстрації: 
– обробка запитів на створення облікового запису та вхід до системи; 
– використовується модель User, яка зберігає ім’я, email і хешований 
пароль[8][9]; 
– валідація та автентифікація реалізовані через JWT-токени[9]. Дані 
користувача зберігаються у колекції users. 
 
 
Рисунок 3.14 – Компонент реєстрації у WEB застосунку контролю калорійності 
харчування 
 76 
ЧДТУ 252175.022 ПЗ 
 
Рисунок 3.15 - Компонент автентифікації у WEB застосунку контролю калорійності 
харчування 
 
2 Компонент додавання прийомів їжі: 
– дає змогу користувачу створювати прийоми їжі (сніданок, обід тощо) з 
переліком продуктів; 
– використовується модель Meal, яка включає дату, категорію (тип 
прийому) та масив продуктів із вказаною кількістю. Кожен запис 
 77 
ЧДТУ 252175.022 ПЗ 
зберігається прив’язкою до userId у базі meals. WEB застосунку 
контролю калорійності харчування. 
 
 
Рисунок 3.16 - Компонент додавання прийомів їжі у WEB застосунку контролю 
калорійності харчування 
 
3 Компонент керування продуктами: 
– дозволяє додавати, редагувати або видаляти продукти зі своєї бази; 
– використовується модель Product, яка зберігає назву, нутрієнти 
(калорії, білки, жири, вуглеводи) та користувача, якому належить 
запис. Зберігається у колекції products; 
– обчислює загальну кількість спожитих калорій і нутрієнтів на день або 
інший обраний період; 
– сервер виконує агрегаційні запити до колекції meals[6], формує звіт та 
повертає його клієнту для візуалізації за допомогою бібліотеки Chart.js. 
 78 
ЧДТУ 252175.022 ПЗ 
 
Рисунок 3.17 - Компонент керування продуктами у WEB застосунку контролю 
калорійності харчуванняʼ 
 
4 Компонент керування цілями: 
– забезпечує збереження та оновлення персональних цілей користувача 
(щоденна норма калорій і нутрієнтів); 
 79 
ЧДТУ 252175.022 ПЗ 
– за допомогою моделі Goals зберігаються індивідуальні цілі кожного 
користувача (калорії, білки, жири, вуглеводи) у колекції goals. 
 
 
Рисунок 3.18 - Компонент керування цілями у WEB застосунку контролю 
калорійності харчування 
 
5 Компонент звітів: 
– забезпечує графічне відображення статистики споживаних нутрієнтів 
(калорій, білків, жирів, вуглеводів) за обраний період часу; 
– використовує модель Meal, яка зберігає прийоми їжі користувача із 
зазначенням продуктів, кількості та часу вживання. Дані зберігаються в 
колекції meals; 
 80 
ЧДТУ 252175.022 ПЗ 
– здійснює підрахунок загальних показників КБЖВ за вказаний інтервал 
(наприклад, за 7 днів), агрегуючи значення із записів прийомів їжі. 
 
 
Рисунок 3.19 - Компонент статистики у WEB застосунку контролю калорійності 
харчування 
 
Взаємодія компонентів: 
– компонент реєстрації створює новий запис у колекції users, 
використовуючи jwt для подальшої авторизації; 
– компонент прийомів їжі взаємодіє з колекцією meals, підраховує суму 
КБЖВ на основі внесених продуктів; 
– компонент продуктів дозволяє користувачу зберігати власну базу харчових 
елементів для швидкого повторного використання; 
– компонент цілей формує основу для аналітики, порівнюючи рекомендовані 
значення з фактичними; 
 81 
ЧДТУ 252175.022 ПЗ 
– компонент статистики агрегує усі записи прийомів їжі по датах і видає 
підсумки. 
Структура програмних компонентів у веб-застосунку побудована за 
принципом модульності. Кожна функціональність ізольована в окремий контролер 
або сервіс, що взаємодіє з відповідною колекцією в базі даних. Це забезпечує 
зручність підтримки, можливість масштабування та повторного використання коду. 
3.2 Тестування системи 
У цьому розділі розглянуто процес тестування веб-застосунку для контролю 
калорійності харчування на різних рівнях: модульному, інтеграційному, системному 
та приймальному. Мета тестування – виявлення та усунення помилок, перевірка 
відповідності реалізації функціональним вимогам, а також забезпечення стабільної 
та коректної роботи всієї системи. 
3.2.1 Модульне тестування 
Модульне тестування проводилось на рівні окремих функцій і сервісів, 
реалізованих у backend-частині застосунку (Node.js[4] + MongoDB[6]). Тестування 
здійснювалося за допомогою фреймворків Mocha та Chai[13][14], що забезпечують 
написання та виконання тестів у середовищі JavaScript. 
Основні кроки: 
1 Налаштування середовища тестування: 
– встановлено пакети mocha, chai, supertest[15]; 
– створено окремі тестові файли у папці /tests. 
2 Написання тестів: 
– перевірено модулі реєстрації, додавання прийомів їжі, створення цілей 
та роботи з продуктами; 
– тестувались як позитивні, так і негативні сценарії (з валідними та 
невалідними даними). 
3 Виконання тестів: 
– запущено команди npm test, результати виведено у консоль; 
– пройдено всі основні гілки логіки. 
 82 
ЧДТУ 252175.022 ПЗ 
Таблиця 3.1  
Результати модульного тестування 
Очікуваний Фактичний 
Модуль Тестовий випадок Статус 
результат результат 
Користувач Користувач 
Реєстрація 
Валідні дані створений, дані створений, дані Пройдено 
користувача 
збережено збережено 
Помилка Помилка 
Не валідні дані створення, створення, 
Пройдено 
 (без email) користувача не користувача не 
додано додано 
Додавання Валідна дата + Прийом додано до Прийом додано до 
Пройдено 
прийому їжі продукти колекції meals колекції meals 
Помилка: список Помилка: список 
Відсутні продукти продуктів продуктів Пройдено 
 
порожній порожній 
Валідне 
Оновлення Дані оновлено у Дані оновлено у 
оновлення (нові Пройдено 
цілей goals goals 
КБЖВ) 
Невірний формат 
даних (негативне Помилка валідації Помилка валідації Пройдено 
 
значення) 
Робота з Додавання Продукт додано в Продукт додано в 
Пройдено 
продуктами продукту колекцію products колекцію products 
Створення 
Дублювання Помилка: запис 
дублікату (одна Пройдено 
 заборонено вже існує 
назва) 
 
 83 
ЧДТУ 252175.022 ПЗ 
Результати модульного тестування підтверджують коректну роботу основних 
програмних компонентів веб-застосунку. Усі функції, що відповідають за облік 
харчування, створення прийомів їжі, управління продуктами та персональними 
цілями, успішно пройшли перевірку. Це створює основу для подальшого 
інтеграційного та системного тестування. 
3.2.2 Інтеграційне тестування 
Інтеграційне тестування є наступним етапом після модульного та має на меті 
перевірку взаємодії між окремими модулями системи. Для веб-застосунку контролю 
калорійності харчування інтеграційне тестування дозволяє переконатися, що 
компоненти, такі як API-ендпоїнти, сервіси бази даних та логіка автентифікації, 
працюють разом коректно. 
Під час тестування перевіряється повна послідовність дій – від запиту 
користувача на frontend до запису або отримання даних з бази через backend, із 
подальшою відповіддю назад. 
Основні кроки інтеграційного тестування: 
1 Підготовка середовища: 
– створено окрему тестову mongodb-базу[6]; 
– ініціалізовано базові тестові дані (users, goals, products); 
– запущено backend у тестовому режимі. 
2 Визначення сценаріїв: 
– перевірка взаємодії реєстрації користувача з базою users; 
– створення прийому їжі з прив’язкою до продуктів та перевіркою 
збереження в meals; 
– встановлення добових цілей і перевірка відповідності при побудові 
статистики. 
3 Написання тестів: 
– тести створено за допомогою supertest, що дозволяє емулювати http-
запити до api[15]; 
– враховано як позитивні, так і негативні сценарії. 
 84 
ЧДТУ 252175.022 ПЗ 
4 Виконання тестів та аналіз: 
– тестові запити виконано за допомогою npm test; 
– усі тести успішно пройдені, а виявлені незначні логічні помилки були 
усунені в процесі. 
 
Таблиця 3.2 
Результати інтеграційного тестування 
Очікуваний Фактичний 
Модуль Тестовий випадок Статус 
результат результат 
POST 
Користувача Дані записано, 
Реєстрація /api/auth/register → 
створено, токен токен Пройдено 
користувача перевірка запису у 
повернуто згенеровано 
базі users 
Продукт 
Додавання POST /api/products → Продукт додано 
збережено у базі Пройдено 
продукту створення продукту без помилок 
products 
Дані збережено у Структура 
Створення POST /api/meals → 
meals, правильна відповідає схемі, Пройдено 
прийому їжі прив’язка продуктів 
агрегація все збережено 
PUT /api/goals → Цілі збережено та 
Встановлення Дані оновлено у 
оновлення добових доступні для Пройдено 
цілей колекції goals 
цілей статистики 
 
Інтеграційне тестування підтвердило, що всі ключові компоненти системи 
успішно взаємодіють між собою. Дані коректно проходять через весь ланцюг: 
користувач → інтерфейс → API → база даних → зворотна відповідь[4][6][16]. Це 
забезпечує впевненість у стабільності та цілісності архітектури системи перед 
повним системним тестуванням. 
3.2.3 Системне тестування 
 85 
ЧДТУ 252175.022 ПЗ 
Системне тестування є завершальним етапом функціонального тестування, що 
передує впровадженню продукту. Його мета – перевірка роботи веб-застосунку для 
контролю калорійності харчування як цілісної системи, з усіма активними 
модулями, сервісами та базами даних. Тестування проводиться в умовах, 
максимально наближених до реального використання, з урахуванням навантаження, 
стабільності, безпеки та відповідності очікуванням користувача. 
Основні кроки системного тестування: 
1. Підготовка середовища: 
– розгорнуто повноцінне середовище (frontend + backend + mongodb[6]); 
– застосовано тестові облікові записи та підготовлено реалістичні дані 
(прийоми їжі, продукти, цілі). 
2. Формування системних сценаріїв: 
– реєстрація нового користувача та подальший вхід; 
– додавання продукту й створення прийому їжі; 
– встановлення персональних добових цілей; 
– генерація статистики на основі щоденника; 
– валідація доступу до захищених ресурсів (перевірка авторизації)[9]. 
3. Тестування нефункціональних характеристик: 
– продуктивність: перевірено час відповіді при запитах до meals, 
products, goals; 
– безпека: перевірено захист маршрутів без токена авторизації; 
– масштабованість: проведено імітацію кількох сесій з різними 
користувачами. 
4. Виконання та аналіз: 
– усі сценарії виконано вручну через ui та автоматизовано через supertest; 
– усі запити повернули очікувані статуси та відповіді. 
 
Таблиця 3.3 
Результати системного тестування 
 86 
ЧДТУ 252175.022 ПЗ 
Очікуваний Фактичний 
Модуль Тестовий випадок Статус 
результат результат 
Створення Користувача Користувача 
Реєстрація 
облікового запису і створено, доступ створено, Пройдено 
користувача 
доступ до функцій підтверджено функції доступні 
Продукт 
Додавання Створення нового Продукт з’явився в 
успішно Пройдено 
продукту продукту через UI базі products 
збережено 
Додавання прийому Прийом збережено Прийом додано, 
Створення 
з обраними в meals, статистика Пройдено 
прийому їжі 
продуктами підраховано КБЖВ оновлена 
Цілі оновлено в 
Оновлення добових Цілі збережено, 
Встановлення goals, дані 
цілей (калорії, білки графіки Пройдено 
цілей враховано в 
тощо) оновились 
статистиці 
Запит до розділу 
Відображено 
Генерація “Статистика” після Дані агреговано 
графіки на основі Пройдено 
статистики кількох днів і показано 
записів 
введення 
Запит до 
Доступ без захищеного 
401 Unauthorized Отримано 401 Пройдено 
авторизації маршруту без 
токена 
 
Системне тестування показало, що всі компоненти веб-застосунку працюють 
як єдине ціле – злагоджено, без помилок та згідно з функціональними і 
нефункціональними вимогами. Користувачі можуть реєструватись, вести щоденник 
харчування, змінювати цілі та переглядати статистику. Застосунок демонструє 
 87 
ЧДТУ 252175.022 ПЗ 
стабільність і готовність до реального використання. Наступним етапом є 
приймальне тестування. 
3.2.4 Приймальне тестування 
Приймальне тестування є завершальним етапом тестування перед передачею 
веб-застосунку до реальної експлуатації. Основною метою є перевірка відповідності 
функціональності очікуванням кінцевих користувачів та вимогам, сформульованим 
під час проєктування. У цьому випадку тестування охоплювало реальні сценарії 
взаємодії з системою для обліку харчування, в яких брали участь звичайні 
користувачі. 
Основні етапи приймального тестування: 
1 Підготовка до тестування: 
– складено перелік сценаріїв, що імітують повсякденне використання 
(реєстрація, додавання продуктів, статистика); 
– сбрано групу користувачів (3 тестувальники з різним рівнем технічної 
підготовки); 
– застосунок розгорнуто на реальному сервері для перевірки у 
природному середовищі. 
2 Проведення тестування: 
– користувачі виконували реальні дії: створення облікового запису, 
ведення харчового щоденника, перегляд статистики, зміна цілей; 
– збирався зворотний зв’язок про інтерфейс, зручність та стабільність 
роботи. 
3 Аналіз результатів: 
– на основі поведінки користувачів було зафіксовано час на виконання 
базових дій; 
– зареєстровано лише одну незначну проблему (застарілий токен при 
неактивності понад 15 хвилин). 
4 Усунення недоліків та повторна перевірка: 
 88 
ЧДТУ 252175.022 ПЗ 
– проблему з токеном авторизації усунуто шляхом оновлення механізму 
перевірки jwt; 
– повторна сесія показала, що всі функції працюють стабільно. 
 
Таблиця 3.4 
Результати приймального тестування 
Фактичний 
Модуль Тестовий випадок Очікуваний результат Статус 
результат 
Реєстрація 
Створення Користувача 
Реєстрація успішна, 
облікового запису створено, доступ Пройдено 
користувача користувач 
і вхід до системи відкрито 
увійшов 
Додавання Продукт 
Додавання Продукт додано і 
власного відображається Пройдено 
продукту збережено 
продукту до бази у списку 
Додавання 
Прийом 
Створення прийому з Прийом створено, 
відображено в Пройдено 
прийому їжі обраними дані збережено у базі 
історії 
продуктами 
Графіки 
Відображення 
Дані коректно відображаються 
Перегляд графіків на основі 
агреговано і згідно з Пройдено 
статистики збережених 
візуалізовано внесеними 
записів 
даними 
Встановлення Цілі оновлено, 
Оновлення Дані збережено у базі 
нових добових статистика Пройдено 
цілей goals 
норм підлаштована 
 
 89 
ЧДТУ 252175.022 ПЗ 
Приймальне тестування підтвердило, що система повністю відповідає 
функціональним очікуванням користувачів. Інтерфейс визнано зручним і 
зрозумілим, а всі ключові функції працюють стабільно. Це свідчить про готовність 
веб-застосунку до впровадження у реальне середовище та подальшого 
використання. 
3.3 Приклади впровадженого програмного комплексу 
У цьому підрозділі наведено приклади реалізованої функціональності веб-
застосунку для контролю калорійності харчування. Вони демонструють, як 
програмні компоненти працюють у реальному середовищі, забезпечуючи 
користувачам інструменти для ведення харчового щоденника, обліку нутрієнтів і 
перегляду статистики. 
Реєстрація користувача 
Користувачі можуть створити обліковий запис через сторінку реєстрації, 
ввівши ім’я, email та пароль. Після успішної реєстрації їм надається доступ до 
персонального кабінету, де вони можуть додавати прийоми їжі, продукти, 
встановлювати добові цілі (рис. 3.20). 
 
 
Рисунок 3.20 – Реєстрація користувача у WEB застосунку контролю калорійності 
харчування 
 90 
ЧДТУ 252175.022 ПЗ 
Додавання продукту 
На сторінці "Продукти" користувач може створити власний список продуктів, 
зазначивши назву та нутрієнтний склад: калорії, білки, жири, вуглеводи. Додані 
продукти використовуються при формуванні прийомів їжі (рис. 3.21). 
Створення прийомів їжі 
На головній панелі доступна функція створення прийому їжі (наприклад, 
сніданку). Користувач обирає продукти зі свого списку. Система автоматично 
підраховує загальну калорійність (рис. 3.22). 
 
Рисунок 3.21 – Сторінка продуктів у WEB застосунку контролю калорійності 
харчування 
 91 
ЧДТУ 252175.022 ПЗ 
 
Рисунок 3.22 – Вікно створення прийому їжі у WEB застосунку контролю 
калорійності харчування 
 
Встановлення добових цілей 
У розділі “Цілі” користувач може встановити свої добові норми калорій та 
нутрієнтів, які надалі використовуються для порівняння з фактичними показниками. 
Ця інформація впливає на формування щоденної статистики (рис. 3.23). 
 
Рисунок 3.23 – Сторінка встановлення цілей користувача у WEB застосунку 
контролю калорійності харчування 
 92 
ЧДТУ 252175.022 ПЗ 
Перегляд статистики 
У вкладці “Звіти” користувачі можуть переглядати діаграми споживання 
калорій, білків, жирів і вуглеводів. Графіки формуються на основі внесених даних за 
день або тиждень, що дозволяє контролювати дотримання цілей (рис. 3.24). 
 
 
Рисунок 3.24 – Сторінка звіту у WEB застосунку контролю калорійності 
харчування 
 
Ці приклади відображають базову функціональність веб-застосунку, яка вже 
впроваджена та активно працює в тестовому середовищі. Реалізовані компоненти 
забезпечують користувачам повний цикл взаємодії з харчовими записами – від 
створення продуктів і прийомів їжі до перегляду підсумкової статистики, що робить 
систему ефективною у підтримці здорового способу життя. 
  
 93 
ЧДТУ 252175.022 ПЗ 
ВИСНОВКИ ДО ТРЕТЬОГО РОЗДІЛУ 
У третьому розділі було всебічно розглянуто процес розробки, тестування та 
впровадження веб-застосунку для контролю калорійності харчування. Розділ 
охоплює ключові етапи створення програмного забезпечення – від вибору 
інструментів до перевірки його працездатності в реальному середовищі. 
Основні етапи розробки 
Розробка програмного комплексу: 
– обґрунтовано вибір технологій, зокрема: javascript, node.js[4], mongodb[6], 
а також react[1] для створення інтерфейсу користувача; 
– побудовано структурну та логічну схему, яка відображає зв’язки між 
модулями системи; 
– реалізовано базу даних для зберігання користувацьких записів, харчових 
прийомів, продуктів і добових цілей; 
– розроблено зручний, адаптивний інтерфейс користувача з логічною 
навігацією. 
Тестування системи: 
– проведено модульне тестування окремих функцій для виявлення й 
усунення помилок на ранніх етапах; 
– інтеграційне тестування забезпечило перевірку взаємодії між backend-
сервісами та базою даних; 
– системне тестування підтвердило коректну роботу всіх компонентів у 
єдиній архітектурі; 
– під час приймального тестування реальні користувачі оцінили стабільність, 
інтуїтивність інтерфейсу та повноту функціональності системи. 
Приклади впровадженого програмного комплексу: 
– було продемонстровано реалізацію ключових можливостей, таких як 
реєстрація користувача, створення продуктів, додавання прийомів їжі, 
встановлення цілей і перегляд статистики, що підтверджує практичну 
придатність системи до щоденного використання. 
 94 
ЧДТУ 252175.022 ПЗ 
У результаті було створено повноцінний веб-застосунок, що дозволяє 
користувачам зручно контролювати своє харчування та досягати особистих цілей у 
сфері здоров’я. Усі етапи розробки реалізовано успішно, а система 
продемонструвала надійність, стабільність і відповідність вимогам, що ставилися на 
початку роботи. Веб-застосунок готовий до реального впровадження й 
використання широким колом користувачів. 
 95 
ЧДТУ 252175.022 ПЗ 
ВИСНОВКИ 
У ході виконання кваліфікаційної роботи бакалавра було розроблено 
повноцінний веб-застосунок для контролю калорійності харчування, який дозволяє 
користувачам вести особистий харчовий щоденник, обирати продукти з власної 
бази, додавати прийоми їжі, встановлювати індивідуальні цілі та відстежувати 
прогрес за допомогою графіків. 
На етапі проєктування було обґрунтовано вибір сучасного технологічного 
стеку: React[1] для побудови клієнтської частини, Node.js[4] з Express[5] – для 
серверної логіки, а також MongoDB[6] – як гнучкої NoSQL бази даних. Архітектура 
системи забезпечує її масштабованість, модульність і простоту підтримки. 
У процесі реалізації створено окремі програмні компоненти, які відповідають 
за реєстрацію та авторизацію користувачів, керування продуктами, додавання 
прийомів їжі, облік добових норм КБЖВ, а також генерацію статистики. Усі модулі 
пройшли багаторівневе тестування: модульне, інтеграційне, системне та 
приймальне, що підтвердило надійність і стабільність їхньої роботи. 
Впроваджений програмний комплекс є зручним інструментом для людей, які 
ведуть здоровий спосіб життя або потребують контролю харчування. Розроблений 
застосунок повністю відповідає поставленим вимогам та продемонстрував свою 
практичну ефективність під час тестування з реальними користувачами. 
Таким чином, цілі, поставлені на початку роботи, були досягнуті, а створена 
система є готовим рішенням для подальшого використання, масштабування та 
вдосконаленн 
95 
ДОДАТОК А 
 
 
 ЗАТВЕРДЖЕНО: 
Зав. кафедрою ПЗАС, професор 
_________________ Голуб С.В. 
„____” ______________ 2025 р. 
 
 
 
 
«WEB-застосунок для контролю калорійності харчування» 
 
 
 
Специфікація 
482.ЧДТУ.252175.022 
Листів 2 
 
 
Розробник ________________ Шевченко М.В. 
Керівник ________________ Півень О. Б. 
 
 
 
 
 
 
 
Черкаси 2025
482.ЧДТУ.252175.022 2 
‘Позначення Найменування Примітка 
Документація 
482.ЧДТУ 252160 12 01 Текст програми 
482.ЧДТУ 252160 34 01 Інструкція користувачеві 
482.ЧДТУ 252160 90 01 Графічні матеріали 
98 
ДОДАТОК Б 
«WEB-застосунок для контролю калорійності харчування» 
Текст програми 
482.ЧДТУ 252160 12 01
Листів 20 
Розробник ________________ Шевченко М.В. 
Черкаси 2025 
 
482.ЧДТУ 252160 12 01
FrontEnd 
Лістинг Layout.tsx 
import { Outlet } from 'react-router-dom'; 
import Navbar from './Navbar'; 
import { HomeIcon, CubeIcon, ChartBarIcon, UserIcon } from 
'@heroicons/react/24/outline'; 
const navigation = [ 
  { name: 'Dashboard', href: '/', icon: HomeIcon }, 
  { name: 'Products', href: '/products', icon: CubeIcon }, 
  { name: 'Reports', href: '/reports', icon: ChartBarIcon }, 
  { name: 'Profile', href: '/profile', icon: UserIcon }, 
]; 
const Layout = () => { 
  return ( 
<div className="min-h-screen bg-gray-50"> 
<Navbar /> 
<main className="py-8"> 
<div className="max-w-7xl mx-auto px-4 sm:px-6 lg:px-8"> 
<Outlet /> 
</div> 
</main> 
</div> 
  ); 
}; 
export default Layout; 
Лістинг AddMeal.tsx 
import { useState } from 'react'; 
import type { FormEvent } from 'react'; 
import { getAuthHeaders } from '../utils/auth'; 
interface AddMealProps { 
  onMealAdded: () => void; 
} 
const AddMeal = ({ onMealAdded }: AddMealProps) => { 
  const [formData, setFormData] = useState({ 
name: '', 
calories: '', 
date: new Date().toISOString().slice(0, 10), 
time: new Date().toLocaleTimeString('en-US', { hour12: false }).slice(0, 5) 
  }); 
  const [error, setError] = useState(''); 
  const [isLoading, setIsLoading] = useState(false); 
  const handleSubmit = async (e: FormEvent) => { 
100 
482.ЧДТУ 252160 12 01
e.preventDefault() setError(''); 
setIsLoading(true); 
try { 
const response = await fetch('http://localhost:5001/api/meals', { 
method: 'POST', 
headers: getAuthHeaders(), 
body: JSON.stringify({ 
name: formData.name, 
calories: Number(formData.calories), 
date: `${formData.date}T${formData.time}:00` 
}) 
}); 
if (!response.ok) { 
const data = await response.json(); 
throw new Error(data.message || 'Failed to add meal'); 
} 
setFormData({ 
name: '', 
calories: '', 
date: formData.date, 
time: formData.time 
}); 
onMealAdded(); 
} catch (err) { 
setError(err instanceof Error ? err.message : 'Failed to add meal'); 
} finally { 
setIsLoading(false); 
} 
  }; 
  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => { 
const { name, value } = e.target; 
setFormData(prev => ({ 
...prev, 
[name]: value 
})); 
  }; 
  return ( 
<div className="bg-white shadow sm:rounded-lg"> 
<div className="px-4 py-5 sm:p-6"> 
<h3 className="text-lg font-medium leading-6 text-gray-900">Add New Meal</h3> 
<form onSubmit={handleSubmit} className="mt-5 space-y-4"> 
{error && (
<div className="rounded-md bg-red-50 p-4"> 
<div className="text-sm text-red-700">{error}</div> 
</div>)} 
101 
482.ЧДТУ 252160 12 01
<div className="grid grid-cols-1 gap-4 sm:grid-cols-2"> 
<div> 
<label htmlFor="name" className="block text-sm font-medium text-gray-
700"> 
Meal Name 
</label> 
<input 
type="text" 
name="name" 
id="name" 
required 
value={formData.name} 
onChange={handleChange} 
className="mt-1 block w-full rounded-md border-gray-300 shadow-sm 
focus:border-indigo-500 focus:ring-indigo-500 sm:text-sm" 
placeholder="e.g., Chicken Salad" 
/> 
</div> 
<div> 
<label htmlFor="calories" className="block text-sm font-medium text-
gray-700"> 
Calories 
</label> 
<input 
type="number" 
name="calories" 
id="calories" 
required 
min="0" 
value={formData.calories} 
onChange={handleChange} 
className="mt-1 block w-full rounded-md border-gray-300 shadow-sm 
focus:border-indigo-500 focus:ring-indigo-500 sm:text-sm" 
placeholder="e.g., 400" 
/> 
</div> 
<div> 
<label htmlFor="date" className="block text-sm font-medium text-gray-
700"> 
Date 
</label> 
<input 
type="date" 
name="date" 
id="date" 
required 
value={formData.date} 
onChange={handleChange} 
className="mt-1 block w-full rounded-md border-gray-300 shadow-sm 
focus:border-indigo-500 focus:ring-indigo-500 sm:text-sm" 
/> 
</div>  <div>
102 
482.ЧДТУ 252160 12 01
<label htmlFor="time" className="block text-sm font-medium text-gray-
700"> 
Time 
</label> 
<input 
type="time" 
name="time" 
id="time" 
required 
value={formData.time} 
onChange={handleChange} 
className="mt-1 block w-full rounded-md border-gray-300 shadow-sm 
focus:border-indigo-500 focus:ring-indigo-500 sm:text-sm" 
/> 
</div> 
</div> 
<div className="flex justify-end"> 
<button 
type="submit" 
disabled={isLoading} 
className={`inline-flex items-center px-4 py-2 border border-transparent 
rounded-md shadow-sm text-sm font-medium text-white bg-indigo-600 hover:bg-indigo-700 
focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-indigo-500 ${ 
isLoading ? 'opacity-75 cursor-not-allowed' : '' 
}`} 
> 
{isLoading ? 'Adding...' : 'Add Meal'} 
</button> 
</div> 
</form> 
</div> 
</div> 
  ); 
}; 
export default AddMe 
Лістинг Login.tsx 
import { useState } from 'react'; 
import type { FormEvent } from 'react'; 
import { useNavigate, Link } from 'react-router-dom'; 
import { login } from '../utils/auth'; 
const Login = () => { 
  const navigate = useNavigate(); 
  const [formData, setFormData] = useState({ 
email: '', 
password: '' 
  }); 
  const [error, setError] = useState(''); 
  const [isLoading, setIsLoading] = useState(false); 
103 
482.ЧДТУ 252160 12 01
  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => { 
const { name, value } = e.target; 
setFormData(prev => ({ 
...prev, 
[name]: value 
})); 
  }; 
  const handleSubmit = async (e: FormEvent) => {
e.preventDefault(); 
setError(''); 
setIsLoading(true); 
try { 
await login(formData.email, formData.password); 
navigate('/home'); 
} catch (err) { 
setError('Failed to login. Please check your credentials.'); 
} finally { 
setIsLoading(false); 
} 
  }; 
  return ( 
<div className="min-h-screen flex items-center justify-center bg-gray-50 py-12 px-
4 sm:px-6 lg:px-8"> 
<div className="max-w-md w-full space-y-8"> 
<div> 
<h2 className="mt-6 text-center text-3xl font-extrabold text-gray-900"> 
Sign in to your account 
</h2> 
<p className="mt-2 text-center text-sm text-gray-600"> 
Or{' '} 
<Link to="/register" className="font-medium text-indigo-600 hover:text-
indigo-500"> 
create a new account 
</Link> 
</p> 
</div> 
<form className="mt-8 space-y-6" onSubmit={handleSubmit}> 
{error && (
<div className="rounded-md bg-red-50 p-4"> 
<div className="text-sm text-red-700">{error}</div> 
</div> 
)} 
<div className="rounded-md shadow-sm -space-y-px"> 
<div> 
<label htmlFor="email" className="sr-only">Email address</label> 
<input 
id="email" 
name="email" 
104 
482.ЧДТУ 252160 12 01
type="email" 
required 
value={formData.email} 
onChange={handleChange} 
className="appearance-none rounded-none relative block w-full px-3 py-
2 border border-gray-300 placeholder-gray-500 text-gray-900 rounded-t-md 
focus:outline-none focus:ring-indigo-500 focus:border-indigo-500 focus:z-10 sm:text-
sm" 
placeholder="Email address" 
/> 
</div> 
<div> 
<label htmlFor="password" className="sr-only">Password</label> 
<input 
id="password" 
name="password" 
type="password" 
required 
value={formData.password} 
onChange={handleChange} 
className="appearance-none rounded-none relative block w-full px-3 py-
2 border border-gray-300 placeholder-gray-500 text-gray-900 rounded-b-md 
focus:outline-none focus:ring-indigo-500 focus:border-indigo-500 focus:z-10 sm:text-
sm" 
placeholder="Password" 
/> 
</div> 
</div> 
<div className="flex items-center justify-between"> 
<div className="flex items-center"> 
<input 
id="remember-me" 
name="remember-me" 
type="checkbox" 
className="h-4 w-4 text-indigo-600 focus:ring-indigo-500 border-gray-
300 rounded" 
/> 
<label htmlFor="remember-me" className="ml-2 block text-sm text-gray-
900"> Remember me 
</label> 
</div> 
<div className="text-sm"> 
<a href="#" className="font-medium text-indigo-600 hover:text-indigo-
500"> 
Forgot your password? 
</a> 
</div> 
</div> 
<div> 
<button 
105 
482.ЧДТУ 252160 12 01
type="submit" 
disabled={isLoading} 
className={`group relative w-full flex justify-center py-2 px-4 border 
border-transparent text-sm font-medium rounded-md text-white bg-indigo-600 hover:bg-
indigo-700 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-indigo-500 
${ 
isLoading ? 'opacity-75 cursor-not-allowed' : '' 
}`} 
> 
{isLoading ? (
<span className="absolute left-0 inset-y-0 flex items-center pl-3"> 
<svg className="animate-spin h-5 w-5 text-white" 
xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24"> 
<circle className="opacity-25" cx="12" cy="12" r="10" 
stroke="currentColor" strokeWidth="4"></circle> 
<path className="opacity-75" fill="currentColor" d="M4 12a8 8 0 
018-8V0C5.373 0 0 5.373 0 12h4zm2 5.291A7.962 7.962 0 014 12H0c0 3.042 1.135 5.824 3
7.938l3-2.647z"></path> 
</svg> 
</span> 
) : null} 
{isLoading ? 'Signing in...' : 'Sign in'} 
</button> 
</div> 
</form> 
</div> 
</div> 
  ); 
}; 
export default Login; 
Лістинг Products.tsx 
import { useState, useEffect } from 'react'; 
import type { FormEvent } from 'react'; 
import { useNavigate } from 'react-router-dom'; 
import { isLoggedIn, getUser, getAuthHeaders } from '../utils/auth'; 
import { FormInput } from '../components/ui/FormInput'; 
interface Product { 
  _id: string; 
  name: string; 
  calories: number; 
  protein: number; 
  fat: number; 
  carbs: number; 
  userId: string; 
} 
interface FormData { 
  name: string; 
  calories: string; 
106 
482.ЧДТУ 252160 12 01
  protein: string; 
  fat: string; 
  carbs: string; 
} 
const Products = () => { 
  const navigate = useNavigate(); 
  const [isLoading, setIsLoading] = useState(false); 
  useEffect(() => { 
if (!isLoggedIn()) { 
navigate('/login', { replace: true }); 
} 
  }, [navigate]); 
  const [products, setProducts] = useState<Product[]>([]); 
  const [formData, setFormData] = useState<FormData>({ 
name: '', 
calories: '', 
protein: '', 
fat: '', 
carbs: '' 
  }); 
  const [error, setError] = useState(''); 
  const handleAuthError = (status: number) => { 
if (status === 401) { 
if (!isLoggedIn()) { 
navigate('/login', { replace: true }); 
} 
setError('Authentication failed. Please try again.'); 
} 
  }; 
  const fetchProducts = async () => { 
try { 
const headers = getAuthHeaders(true); 
const response = await fetch('http://localhost:5001/api/products', {   
headers 
}); 
if (!response.ok) { 
handleAuthError(response.status); 
throw new Error('Failed to fetch products'); 
} 
const data = await response.json(); 
setProducts(data); 
} catch (err) { 
if (err instanceof Error && err.message === 'Authentication required') { 
navigate('/login', { replace: true }); 
107 
482.ЧДТУ 252160 12 01
return; 
} 
console.error('Error fetching products:', err); 
setError('Failed to load products'); 
} 
  }; 
  useEffect(() => { 
fetchProducts(); 
  }, []); 
  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => { 
const { name, value } = e.target; 
setFormData(prev => ({ 
...prev, 
[name]: value 
})); 
  }; 
  const handleSubmit = async (e: FormEvent) => {
e.preventDefault(); 
setError(''); 
setIsLoading(true); 
try { 
const currentUser = getUser(); 
if (!currentUser) { 
navigate('/login', { replace: true }); 
return; 
} 
const numericFields = ['calories', 'protein', 'fat', 'carbs']; 
const validationErrors = []; 
for (const field of numericFields) { 
const value = parseFloat(formData[field as keyof FormData]); 
if (isNaN(value) || value < 0) { 
validationErrors.push(`${field} must be a valid non-negative number`); 
} 
} 
if (!formData.name.trim()) { 
validationErrors.push('Name is required'); 
} 
if (validationErrors.length > 0) { 
setError(validationErrors.join(', ')); 
setIsLoading(false); 
return; 
} 
const productData = { 
name: formData.name.trim(), 
calories: parseFloat(formData.calories), 
protein: parseFloat(formData.protein), 
fat: parseFloat(formData.fat), 
108 
482.ЧДТУ 252160 12 01
carbs: parseFloat(formData.carbs) 
}; 
console.log('Sending product data:', productData); 
const headers = getAuthHeaders(true); 
const response = await fetch('http://localhost:5001/api/products', { 
method: 'POST', 
headers, 
body: JSON.stringify(productData) 
}); 
const data = await response.json(); 
if (!response.ok) { 
handleAuthError(response.status); 
console.error('Server validation errors:', data); 
if (data.errors) { 
setError(Array.isArray(data.errors) ? data.errors.join(', ') : 
data.message); 
} else { 
setError(data.message || 'Failed to add product'); 
} 
return; 
} 
setFormData({ 
name: '', 
calories: '', 
protein: '', 
fat: '', 
carbs: '' 
}); 
await fetchProducts(); 
} catch (err) { 
if (err instanceof Error && err.message === 'Authentication required') { 
navigate('/login', { replace: true }); 
return; 
} 
console.error('Error adding product:', err); 
setError('Failed to add product. Please try again.'); 
} finally { 
setIsLoading(false); 
} 
  }; 
  const handleDelete = async (id: string) => { 
try { 
const headers = getAuthHeaders(true); 
const response = await fetch(`http://localhost:5001/api/products/${id}`, { 
method: 'DELETE', 
109 
482.ЧДТУ 252160 12 01
headers 
}); 
if (!response.ok) { 
handleAuthError(response.status); 
throw new Error('Failed to delete product'); 
} 
await fetchProducts(); 
} catch (err) { 
if (err instanceof Error && err.message === 'Authentication required') { 
navigate('/login', { replace: true }); 
return; 
} 
console.error('Error deleting product:', err); 
setError('Failed to delete product'); 
} 
  }; 
  return ( 
<div className="min-h-screen bg-gray-50 py-8"> 
<div className="max-w-7xl mx-auto px-4 sm:px-6 lg:px-8"> 
<div className="space-y-8"> 
<div> 
<h1 className="text-3xl font-bold text-gray-900">Products</h1> 
<p className="mt-2 text-sm text-gray-600"> 
Add and manage your food products database 
</p> 
</div> 
<div className="bg-white shadow sm:rounded-lg"> 
<div className="px-4 py-5 sm:p-6"> 
<h2 className="text-lg font-medium text-gray-900">Add New Product</h2> 
<form onSubmit={handleSubmit} className="mt-5 space-y-6"> 
{error && (
<div className="rounded-md bg-red-50 p-4"> 
<div className="text-sm text-red-700">{error}</div> 
</div> 
)} 
<div className="grid grid-cols-1 gap-6 sm:grid-cols-2"> 
<FormInput 
label="Product Name" 
type="text" 
name="name" 
id="name" 
required 
value={formData.name} 
onChange={handleChange} 
placeholder="e.g., Chicken Breast" 
/> 
<FormInput 
label="Calories (per 100g)" 
type="number" 
110 
482.ЧДТУ 252160 12 01
name="calories" 
id="calories" 
required 
min="0" 
step="0.1" 
value={formData.calories} 
onChange={handleChange} 
placeholder="e.g., 165" 
/> 
<FormInput 
label="Protein (g)" 
type="number" 
name="protein" 
id="protein" 
required 
min="0" 
step="0.1" 
value={formData.protein} 
onChange={handleChange} 
placeholder="e.g., 31" 
/> 
<FormInput 
label="Fat (g)" 
type="number" 
name="fat" 
id="fat" 
required 
min="0" 
step="0.1" 
value={formData.fat} 
onChange={handleChange} 
placeholder="e.g., 3.6" 
/> 
<FormInput 
label="Carbs (g)" 
type="number" 
name="carbs" 
id="carbs" 
required 
min="0" 
step="0.1" 
value={formData.carbs} 
onChange={handleChange} 
placeholder="e.g., 0" 
/> 
</div> 
<div className="flex justify-end"> 
<button 
type="submit" 
disabled={isLoading} 
111 
482.ЧДТУ 252160 12 01
className="inline-flex justify-center px-4 py-2.5 border border-
transparent rounded-lg text-sm font-medium text-white bg-violet-600 hover:bg-violet-
700 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-violet-500 
transition-colors duration-200 disabled:opacity-50 disabled:cursor-not-allowed" 
> 
{isLoading ? 'Adding...' : 'Add Product'} 
</button> 
</div> 
</form> 
</div> 
</div> 
<div className="bg-white shadow sm:rounded-lg"> 
<div className="px-4 py-5 sm:p-6"> 
<h2 className="text-lg font-medium text-gray-900">Saved Products</h2> 
<div className="mt-4"> 
<div className="overflow-x-auto"> 
<table className="min-w-full divide-y divide-gray-200"> 
<thead className="bg-gray-50"> 
<tr> 
<th className="px-6 py-3 text-left text-xs font-medium text-
gray-500 uppercase tracking-wider">Name</th> 
<th className="px-6 py-3 text-left text-xs font-medium text-
gray-500 uppercase tracking-wider">Calories</th> 
<th className="px-6 py-3 text-left text-xs font-medium text-
gray-500 uppercase tracking-wider">Protein</th> 
<th className="px-6 py-3 text-left text-xs font-medium text-
gray-500 uppercase tracking-wider">Fat</th> 
<th className="px-6 py-3 text-left text-xs font-medium text-
gray-500 uppercase tracking-wider">Carbs</th> 
<th className="px-6 py-3 text-right text-xs font-medium text-
gray-500 uppercase tracking-wider">Actions</th> 
</tr> 
</thead> 
<tbody className="bg-white divide-y divide-gray-200"> 
{products.map((product) => ( 
<tr key={product._id}> 
<td className="px-6 py-4 whitespace-nowrap text-sm font-
medium text-gray-900">{product.name}</td> 
<td className="px-6 py-4 whitespace-nowrap text-sm text-
gray-500">{product.calories}</td> 
<td className="px-6 py-4 whitespace-nowrap text-sm text-
gray-500">{product.protein}g</td> 
<td className="px-6 py-4 whitespace-nowrap text-sm text-
gray-500">{product.fat}g</td> 
<td className="px-6 py-4 whitespace-nowrap text-sm text-
gray-500">{product.carbs}g</td> 
<td className="px-6 py-4 whitespace-nowrap text-right text-
sm font-medium"> 
<button 
onClick={() => handleDelete(product._id)} 
className="text-red-600 hover:text-red-900" 
>
112 
482.ЧДТУ 252160 12 01
Delete 
</button> 
</td> 
</tr> 
))} 
{products.length === 0 && (
<tr> 
<td colSpan={6} className="px-6 py-4 text-center text-sm 
text-gray-500"> 
No products added yet 
</td> 
</tr> 
)} 
</tbody> 
</table> 
</div> 
</div> 
</div> 
</div> 
</div> 
</div> 
</div> 
  ); 
}; 
export default Products; 
Backend. 
Лістинг Products.js 
const express = require('express'); 
const router = express.Router(); 
const Product = require('../models/Product'); 
const verifyToken = require('../middleware/verifyToken'); 
router.use(verifyToken); 
router.get('/', async (req, res) => { 
  try { 
const products = await Product.find({ userId: req.user.id }) 
.sort({ name: 1 }); 
res.json(products); 
  } catch (err) { 
console.error('Error fetching products:', err); 
res.status(500).json({ message: 'Error fetching products' }); 
  } 
}); 
router.post('/', async (req, res) => { 
  try { 
console.log('Received product data:', req.body); 
const { name, calories, protein, fat, carbs } = req.body; 
const validationErrors = []; 
113 
482.ЧДТУ 252160 12 01
if (!name || typeof name !== 'string' || name.trim().length === 0) { 
validationErrors.push('Name is required and must be a non-empty string'); 
} 
const numericFields = { 
calories: calories, 
protein: protein, 
fat: fat, 
carbs: carbs 
}; 
for (const [field, value] of Object.entries(numericFields)) { 
if (value == null || value === '') { 
validationErrors.push(`${field} is required`); 
} else if (isNaN(value) || value < 0) { 
validationErrors.push(`${field} must be a non-negative number`); 
} 
} 
if (validationErrors.length > 0) { 
console.log('Validation errors:', validationErrors); 
return res.status(400).json({ 
message: 'Validation failed', 
errors: validationErrors 
}); 
} 
const userId = req.user.id; 
const existingProduct = await Product.findOne({ 
userId: userId, 
name: name.trim() 
}); 
if (existingProduct) { 
return res.status(400).json({ 
message: 'A product with this name already exists' 
}); 
} 
const product = new Product({ 
name: name.trim(), 
calories: parseFloat(calories), 
protein: parseFloat(protein), 
fat: parseFloat(fat), 
carbs: parseFloat(carbs), 
userId: userId 
}); 
console.log('Saving product:', product); 
const savedProduct = await product.save(); 
console.log('Product saved successfully:', savedProduct); 
114 
482.ЧДТУ 252160 12 01
res.status(201).json(savedProduct); 
  } catch (err) { 
console.error('Error creating product:', err); 
if (err.name === 'ValidationError') { 
return res.status(400).json({ 
message: 'Validation error', 
errors: Object.values(err.errors).map(e => e.message) 
}); 
} 
res.status(500).json({ message: 'Error creating product' }); 
  } 
}); 
router.put('/:id', async (req, res) => { 
  try { 
const { id } = req.params; 
const { name, calories, protein, fat, carbs } = req.body; 
if (calories < 0 || protein < 0 || fat < 0 || carbs < 0) { 
return res.status(400).json({ 
message: 'Nutritional values must be non-negative numbers.' 
}); 
} 
const product = await Product.findOneAndUpdate( 
{ _id: id, userId: req.user.id }, 
{ name: name.trim(), calories, protein, fat, carbs }, 
{ new: true } 
); 
if (!product) { 
return res.status(404).json({ message: 'Product not found' }); 
} 
res.json(product); 
  } catch (err) { 
console.error('Error updating product:', err); 
res.status(500).json({ message: 'Error updating product' }); 
  } 
}); 
router.delete('/:id', async (req, res) => { 
  try { 
const { id } = req.params; 
const product = await Product.findOneAndDelete({ 
_id: id, 
userId: req.user.id 
}); 
if (!product) { 
return res.status(404).json({ message: 'Product not found' }); 
} 
res.json({ message: 'Product deleted successfully' }); 
  } catch (err) { 
console.error('Error deleting product:', err); 
115 
482.ЧДТУ 252160 12 01
res.status(500).json({ message: 'Error deleting product' }); 
  } 
}); 
module.exports = router; 
Лістинг Auth.js 
const express = require('express'); 
const router = express.Router(); 
const bcrypt = require('bcryptjs'); 
const jwt = require('jsonwebtoken'); 
const User = require('../models/User'); 
const JWT_SECRET = process.env.JWT_SECRET || 'your-secret-key'; 
router.post('/register', async (req, res) => { 
  try { 
const { name, email, password } = req.body; 
if (!email || !password || !name) { 
console.log('fields') 
return res.status(400).json({ message: 'Please provide all required fields' }); 
} 
const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; 
if (!emailRegex.test(email)) { 
console.log('email') 
return res.status(400).json({ message: 'Please provide a valid email address' 
}); 
} 
if (password.length < 6) { 
console.log('password') 
return res.status(400).json({ message: 'Password must be at least 6 characters 
long' }); 
} 
let user = await User.findOne({ email }); 
if (user) { 
console.log('user exists') 
return res.status(400).json({ message: 'User already exists' }); 
} 
user = new User({ 
name, 
email, 
password 
}); 
116 
482.ЧДТУ 252160 12 01
const salt = await bcrypt.genSalt(10); 
user.password = await bcrypt.hash(password, salt); 
console.log('@user reg', user) 
await user.save(); 
const payload = { 
userId: user.id 
}; 
const token = jwt.sign(payload, JWT_SECRET, { expiresIn: '24h' }); 
res.status(201).json({ 
token, 
user: { 
id: user.id, 
name: user.name, 
email: user.email 
} 
}); 
  } catch (err) { 
console.error('Registration error:', err); 
if (err.code === 11000) { 
return res.status(400).json({ message: 'User already exists' }); 
} 
res.status(500).json({ message: 'Server error during registration' }); 
  } 
}); 
router.post('/login', async (req, res) => { 
  try 
const { email, password } = req.body; 
const user = await User.findOne({ email }); 
console.log('@user', user) 
if (!user) { 
return res.status(400).json({ message: 'Invalid credentials' }); 
} 
const isMatch = await bcrypt.compare(password, user.password); 
if (!isMatch) { 
return res.status(400).json({ message: 'Invalid credentials' }); 
} 
const payload = { 
userId: user.id 
}; 
const token = jwt.sign(payload, JWT_SECRET, { expiresIn: '24h' }); 
117 
482.ЧДТУ 252160 12 01
res.json({ 
token, 
user: { 
id: user.id, 
name: user.name, 
email: user.email 
} 
}); 
  } catch (err) { 
console.error('Login error:', err); 
res.status(500).json({ message: 'Server error during login' }); 
  } 
}); 
router.get('/me', async (req, res) => { 
  try { 
const token = req.header('Authorization')?.replace('Bearer ', ''); 
if (!token) { 
return res.status(401).json({ message: 'No token, authorization denied' }); 
} 
const decoded = jwt.verify(token, JWT_SECRET); 
const user = await User.findById(decoded.userId).select('-password'); 
if (!user) { 
return res.status(404).json({ message: 'User not found' }); 
} 
res.json(user); 
  } catch (err) { 
console.error('Auth error:', err); 
res.status(401).json({ message: 'Token is not valid' });  } 
} 
118 
ДОДАТОК В 
«WEB-застосунок для контролю калорійності харчування» 
Інструкція користувачеві 
482.ЧДТУ 252160 34 01
Листів 6 
Розробник ________________ Шевченко М.В. 
Черкаси 2025
482.ЧДТУ 252160 34 01 2 
Головна сторінка системи слугує стартовим центром взаємодії 
користувача з веб-застосунком. Звідси відкривається доступ до ключових 
можливостей — додавання харчових записів, перегляду щоденного раціону, 
переходу до аналітики та керування персональними налаштуваннями. 
Інтерфейс орієнтований на швидкий доступ і простоту навігації. 
Рисунок В.1 – Головна сторінка WEB застосунку контролю калорійності 
харчування 
У розділі «Products» відображається список усіх доданих користувачем 
продуктів. Таблиця дозволяє зручно переглядати інформацію про назву, 
нутрієнтний склад, а також виконувати базові дії. Для кращої зручності 
додано пагінацію та механізм швидких дій. 
Також зручна форма додавання продкутів дозволне користувачеві 
додати продукти враховуючи їх поживну цінність(калоріі, жири, білки, 
вуглеводи)
120 
482.ЧДТУ 252160 34 01 3 
Рисунок В.2 – Форма додавання продуктів у WEB застосунку контролю 
калорійності харчування 
Рисунок В.2 – Виведення продуктів у табличному форматі 
Однією з ключових функцій системи є можливість користувача 
додавати прийоми їжі до свого щоденного харчового щоденника. 
На сторінці додавання їжі користувач виконує такі дії: 
Вибір типу прийому їжі 
– користувач обирає категорію: сніданок, обід, вечеря або перекус.
Вказання кількості продукту 
– вводиться кількість у грамах, на основі якої система автоматично
розраховує калорійність та нутрієнти відповідно до заданого
продукту.
121 
482.ЧДТУ 252160 34 01 4 
Підтвердження запису 
– після заповнення усіх полів, користувач натискає кнопку «додати».
запис зберігається у базі даних та відображається у поточному
щоденнику.
Рисунок В.11 – Форма додавання прийому їжі у веб-застосунку 
Рисунок В.4 – Список прийомів їжі після додавання 
На сторінці «Profile», у вкладці «Nutrition Goals» користувач може 
встановлювати власні добові цілі у вигляді норми калорій, білків, жирів та 
вуглеводів, які будуть відображатися на головну екрані веб застосунку.
122
482.ЧДТУ 252160 34 01 5 
Рисунок B.5 – Встановлення цілей добової норми поживних цінностей 
Усі додані прийоми їжі сортуються за датою та категорією. Система 
також автоматично підраховує загальні добові значення калорій, білків, 
жирів і вуглеводів, що відображаються у відповідній секції інтерфейсу або на 
сторінці «Repots» 
Окремий розділ інтерфейсу присвячений візуалізації харчової 
активності користувача у вигляді інтерактивних звітів. На сторінці 
статистики відображаються графіки змін добового споживання калорій та 
нутрієнтів (білків, жирів, вуглеводів) за обраний часовий проміжок. 
Після відкриття сторінки користувач має змогу: 
Вибрати діапазон дат 
– За допомогою календаря або попередньо заданих фільтрів
(наприклад, тиждень / місяць / довільний період), можна встановити
часові рамки для побудови аналітики.
Оцінити графік споживання 
– Основна частина сторінки містить графік лінійного або
стовпчастого типу, побудований за допомогою бібліотеки Chart.js.
123 
482.ЧДТУ 252160 34 01 6
На ньому відображаються денні значення калорій або 
макронутрієнтів. 
Перемикатись між показниками 
– За допомогою навігації користувач може змінити тип звіту:
перегляд лише калорій, або ж окремо по білках, жирах, вуглеводах.
Аналізувати ефективність раціону 
– Завдяки графічному представленню користувач бачить, як його
щоденне споживання співвідноситься з встановленими особистими
цілями (нормами КБЖВ).
Рисунок В.12 – Діаграма калорійності споживаних продуктів 
124 
 ДОДАТОК Г
«WEB-застосунок для контролю калорійності харчування» 
Текст програми 
482.ЧДТУ 252160 90 01
Листів 13 
Розробник ________________ Шевченко М.В. 
Черкаси 2025
 
482.ЧДТУ 252160 90 01
Рисунок Г1 – Слайд 1 
Рисунок Г2 – Слайд 2 
126 
482.ЧДТУ 252160 90 01 3 
Рисунок Г3 – Слайд 3 
Рисунок Г4 – Слайд 4 
127 
482.ЧДТУ 252160 90 01 4 
Рисунок Г5 – Слайд 5 
Рисунок Г6 – Слайд 6 
128 
482.ЧДТУ 252160 90 01 5 
Рисунок Г7 – Слайд 7 
Рисунок Г8 – Слайд 8 
129 
482.ЧДТУ 252160 90 01 6 
Рисунок Г9 – Слайд 9 
Рисунок Г10 – Слайд 10 
130 
482.ЧДТУ 252160 90 01 7 
Рисунок Г11 – Слайд 11 
Рисунок Г12 – Слайд 12 
131 
482.ЧДТУ 252160 90 01 8 
Рисунок Г13 – Слайд 13 
Рисунок Г14 – Слайд 14 
132 
482.ЧДТУ 252160 90 01 9 
Рисунок Г15 – Слайд 15 
Рисунок Г16 – Слайд 16 
133 
482.ЧДТУ 252160 90 01 10 
Рисунок Г16 – Слайд 16 
Рисунок Г17 – Слайд 17 
134 
482.ЧДТУ 252160 90 01 11 
Рисунок Г18 – Слайд 18 
Рисунок Г19 – Слайд 19 
135 
482.ЧДТУ 252160 90 01 12 
Рисунок Г20 – Слайд 20 
Рисунок Г21 – Слайд 21 
136 
482.ЧДТУ 252160 90 01 13 
Рисунок Г22 – Слайд 22 
Рисунок Г23 – Слайд 23 
137
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
