Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/7094| Title: | Web-застосунок для управління особистими та груповими фінансами |
| Authors: | Заспа, Григорій Олександрович Заїка, Владислав Віталійович |
| Keywords: | інженерія програмного забезпечення;веб-додаток;архітектура програмного забезпечення;фінансова інформаційна система;алгоритми обробки даних;бюджетування;групові витрати;software engineering;web application;software architecture;financial information system;data processing algorithms;budgeting;group expenses |
| Issue Date: | 12-Dec-2025 |
| Abstract: | АНОТАЦІЇ
Виконавець: Заїка Владислав Віталійович
Назва кваліфікаційної магістерської роботи: Веб-додаток для управління особистими та груповими фінансами
Спеціальність: 121 інженерія програмного забезпечення
Навчальний заклад: "Черкаський державний технологічний університет"
Черкаси, 2025
У цій магістерській роботі досліджуються та впроваджуються підходи до проектування та розробки веб-додатку для управління особистими та груповими фінансами з точки зору програмної інженерії. Актуальність дослідження зумовлена необхідністю створення надійних, масштабованих та підтримуваних програмних систем, здатних забезпечувати точну обробку фінансових даних, аналітичну звітність та спільну взаємодію з користувачами.
У кваліфікаційній роботі представлено аналіз проблемної області та наведено теоретичні дослідження програмних моделей для фінансових процесів, алгоритмів обробки даних, методів бюджетування та механізмів розподілу групових витрат. Запропоновано формалізовані математичні моделі та алгоритми, які інтегровано в бізнес-логіку додатку. Особлива увага приділяється проектуванню архітектури програмного забезпечення, моделюванню даних, вибору технологічного стеку, забезпеченню масштабованості, розширюваності та підтримуваності розробленої системи.
Експериментальна частина включає порівняльний аналіз існуючих фінансових програмних рішень та тестування запропонованих алгоритмів обробки фінансових даних. Експериментальні результати підтверджують правильність обраних архітектурних рішень, моделей даних та алгоритмів, а також доцільність застосування запропонованих програмних рішень у веб-орієнтованих фінансових системах.
Практична цінність дисертації полягає в застосовності розробленої архітектури, програмних моделей та алгоритмів для створення та вдосконалення фінансових веб-додатків, а також їх використання в навчальному процесі в рамках дисциплін програмної інженерії. ABSTRACTS Performer: Zaika Vladyslav Vitaliyovych Title of the qualifying bachelor's thesis: Web-application for managing personal and group finances Specialty: 121 Software Engineering Educational institution: "Cherkasy State Technological University" Cherkasy, 2025 This master’s thesis investigates and implements approaches to the design and development of a web-based application for managing personal and group finances from the perspective of software engineering. The relevance of the research is driven by the need to build reliable, scalable, and maintainable software systems capable of accurate financial data processing, analytical reporting, and collaborative user interaction. The thesis presents an analysis of the problem domain and provides theoretical studies of software models for financial processes, data processing algorithms, budgeting methods, and mechanisms for group expense distribution. Formalized mathematical models and algorithms are proposed and integrated into the application’s business logic. Special attention is paid to software architecture design, data modeling, selection of the technology stack, and ensuring scalability, extensibility, and maintainability of the developed system. The experimental part includes a comparative analysis of existing financial software solutions and testing of the proposed algorithms for financial data processing. The experimental results confirm the correctness of the selected architectural decisions, data models, and algorithms, as well as the feasibility of applying the proposed software solutions in web-based financial systems. The practical value of the thesis lies in the applicability of the developed architecture, software models, and algorithms for the creation and improvement of financial web applications, as well as their use in the educational process within software engineering disciplines. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/7094 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфіепційна робота магістра Заїки Владислава Віталійовича.pdf Restricted Access | 5.58 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«магістра»
освітній рівень
на тему: Web-застосунок для управління особистими та груповими
фінансами
Виконав: студент 2 курсу, групи МПЗ-2404
Напряму підготовки
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Заїка В. В.
(прізвище та ініціали)
Керівник Заспа О. Г.
(прізвище та ініціали)
Рецензент Сметанін О.Г.
(прізвище та ініціали)
Черкаси 2025
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень магістр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
___________ Голуб С. В.
«___» _______________ 2025 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Заїки Владиславу Віталійовичу
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Web-застосунок для управління особистими та груповими фінансами
Керівник проекту (роботи) Заспа Григорій Олександрович к.т.н., доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « 07 » жовтня 2025
року №307/03-03
2. Строк подання студентом проекту (роботи) 12 грудня 2025 р.
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління; вимоги
до проекту; календарне планування проекту; управління ризиками проекту; управління ресурсами
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ
Розділ 1. Теоретичні основи та аналіз існуючих рішень у сфері управління особистими та груповими
фінансами. Розділ 2. Теоретичні та експериментальні дослідження
Розділ 3. Впровадження результатів досліджень у практику проектування програмного забезпечення
інформаційних систем. Розділ 4. Розробка та тестування програмного забезпечення
Висновки
Список використаних джерел
Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;
Слайд 1 - Титульний слайд, Слайд 2 - Актуальність теми, Слайд 3 - Мета та завдання роботи,,
Слайд 4 - Об’єкт та предмет дослідження Слайд 5 - Діаграма компонентів, Слайд 6 -
Архітектура програмної системи, Слайд 7 - Функціональні вимоги системи, Слайд 8 -
Інтерфейс користувача, Слайд 9 - Аналіз існуючих рішень, Слайд 10 - Діаграма комунікації,
Слайд 11 - Реалізація системи, Слайд 12 - Приклад аналізу витрат, Слайд 13 - Титульний
Тестування та якість ПЗ Слайд 14 - Взаємодія з бірржами, Слайд 15 - Наукова та практична
цінність Слайд 16 - Моделювання та алгоритми, Слайд 17 - Приклад роботи програми, Слайд
18 - Висновки,
6. Консультанти розділів проекту (роботи)
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання вересня 2025 р.
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№
Назва етапів випускної роботи етапів випускної Примітки
п/п
роботи
1 Постановка задачі 02.09.2025 виконано
2 Підготовка завдання 13.09.2025 виконано
3 Погодження завдання 16.09.2025 виконано
4 Затвердження завдання 19.09.2025 виконано
Основна стадія
1 Підбір матеріалів 27.09.2025 виконано
2 Аналіз шляхів вирішення поставленої задачі 04.10.2025 виконано
3 Розрахунок основних параметрів роботи 10.10.2025 виконано
4 Вибір кінцевого варіанту проектного рішення 17.10.2025 виконано
5 Оформлення первісної редакції роботи 25.10.2025 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 31.10.2025 виконано
керівником
2 Оформлення пояснювальної записки роботи в 13.11.2025 виконано
кінцевій редакції
3 Попередній захист роботи 15.11.2025 виконано
4 Затвердження роботи 02.12.2025
5 Рецензування роботи 09.12.2025
6 Захист роботи 12.12.2025
Студент _____________________ Заїка В. В.
(підпис) (прізвище та ініціали)
Керівник проекту (роботи) _____________________ Заспа О. Г.
(підпис) (прізвище та ініціали)
АНОТАЦІЇ
Виконавець: Заїка Владислав Віталійович
Назва кваліфікаційної магістерської роботи: Веб-додаток для управління
особистими та груповими фінансами
Спеціальність: 121 інженерія програмного забезпечення
Навчальний заклад: "Черкаський державний технологічний університет"
Черкаси, 2025
У цій магістерській роботі досліджуються та впроваджуються підходи до
проектування та розробки веб-додатку для управління особистими та
груповими фінансами з точки зору програмної інженерії. Актуальність
дослідження зумовлена необхідністю створення надійних, масштабованих та
підтримуваних програмних систем, здатних забезпечувати точну обробку
фінансових даних, аналітичну звітність та спільну взаємодію з користувачами.
У кваліфікаційній роботі представлено аналіз проблемної області та
наведено теоретичні дослідження програмних моделей для фінансових
процесів, алгоритмів обробки даних, методів бюджетування та механізмів
розподілу групових витрат. Запропоновано формалізовані математичні моделі та
алгоритми, які інтегровано в бізнес-логіку додатку. Особлива увага
приділяється проектуванню архітектури програмного забезпечення,
моделюванню даних, вибору технологічного стеку, забезпеченню
масштабованості, розширюваності та підтримуваності розробленої системи.
Експериментальна частина включає порівняльний аналіз існуючих
фінансових програмних рішень та тестування запропонованих алгоритмів
обробки фінансових даних. Експериментальні результати підтверджують
правильність обраних архітектурних рішень, моделей даних та алгоритмів, а
також доцільність застосування запропонованих програмних рішень у веб-
орієнтованих фінансових системах.
Практична цінність дисертації полягає в застосовності розробленої
архітектури, програмних моделей та алгоритмів для створення та
вдосконалення фінансових веб-додатків, а також їх використання в навчальному
процесі в рамках дисциплін програмної інженерії.
Ключові слова: інженерія програмного забезпечення, веб-додаток,
архітектура програмного забезпечення, фінансова інформаційна система,
алгоритми обробки даних, бюджетування, групові витрати.
ABSTRACTS
Performer: Zaika Vladyslav Vitaliyovych
Title of the qualifying bachelor's thesis: Web-application for managing
personal and group finances
Specialty: 121 Software Engineering
Educational institution: "Cherkasy State Technological University"
Cherkasy, 2025
This master’s thesis investigates and implements approaches to the design and
development of a web-based application for managing personal and group finances
from the perspective of software engineering. The relevance of the research is driven
by the need to build reliable, scalable, and maintainable software systems capable of
accurate financial data processing, analytical reporting, and collaborative user
interaction.
The thesis presents an analysis of the problem domain and provides theoretical
studies of software models for financial processes, data processing algorithms,
budgeting methods, and mechanisms for group expense distribution. Formalized
mathematical models and algorithms are proposed and integrated into the
application’s business logic. Special attention is paid to software architecture design,
data modeling, selection of the technology stack, and ensuring scalability,
extensibility, and maintainability of the developed system.
The experimental part includes a comparative analysis of existing financial
software solutions and testing of the proposed algorithms for financial data
processing. The experimental results confirm the correctness of the selected
architectural decisions, data models, and algorithms, as well as the feasibility of
applying the proposed software solutions in web-based financial systems.
The practical value of the thesis lies in the applicability of the developed
architecture, software models, and algorithms for the creation and improvement of
financial web applications, as well as their use in the educational process within
software engineering disciplines.
Keywords: software engineering, web application, software architecture,
financial information system, data processing algorithms, budgeting, group expenses.
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ................................................................ 4
ВСТУП ..................................................................................................................... 6
РОЗДІЛ 1. ТЕОРЕТИЧНІ ОСНОВИ ТА АНАЛІЗ ІСНУЮЧИХ РІШЕНЬ У
СФЕРІ УПРАВЛІННЯ ОСОБИСТИМИ ТА ГРУПОВИМИ ФІНАНСАМИ
................................................................................................................................... 10
1.1. Аналіз предметної області «персональні фінанси» та постановка задачі 10
1.2.Підходи й методи бюджетування та фінансового планування користувачів
14
1.3. Огляд існуючих програмних продуктів для управління особистими та
спільними фінансами .................................................................................... 18
1.4. Вимоги до функціональності веб-застосунку для управління особистими
та груповими фінансами ............................................................................... 25
РОЗДІЛ 2. ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ
................................................................................................................................... 34
2.1Теоретичні дослідження ................................................................................. 34
2.1.1 Модель фінансових потоків користувача ............................................ 37
2.1.2 Агрегація витрат та аналіз структури бюджету ................................. 38
2.1.3 Робота за даними ................................................................................... 39
2.1.4 Модель витрат та операцій з валютою ................................................ 41
2.1.5 Гіпотеза ................................................................................................... 43
2.2 Експериментальні дослідження .................................................................... 43
2.2.1 Опис програмних засобів дослідження ............................................... 49
2.2.2 Моделі та їх оцінювання ....................................................................... 51
РОЗДІЛ 3. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ ........................................................................... 55
3.1 Моделювання предметної області ................................................................ 55
3.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області ........................................................................ 55
3.1.2 Елементи моделювання предметної області ....................................... 59
3.1.3 Робоча область моделювання ................................................................ 62
3.2 Формування та аналіз вимог ......................................................................... 63
3.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги ............................................................................... 64
3.2.2 Формування вимог за допомогою діаграми прецедентів ................. 66
3.2.3 Проектування логічної структури програмного комплексу ............. 69
3.2.3.1 Діаграми класів ........................................................................ 71
3.2.3.2 Діаграми пакетів ....................................................................... 73
3.2.4 Архітектурне проектування ................................................................ 74
3.2.4.1 Діаграма компонентів ............................................................... 75
3.2.4.2 Розгортання програмної системи на апаратних засобах.
Діаграма розгортання .................................................................................... 77
3.2.5 Моделювання поведінки системи ......................................................... 80
3.2.5.1 Діаграма діяльності .................................................................... 81
3.2.5.2 Діаграма послідовності ............................................................. 83
3.2.5.3 Діаграма комунікацій ................................................................. 84
3.2.5.4 Діаграма скінченного автомату ................................................. 87
РОЗДІЛ 4. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ .................................................................................................. 91
4.1 Розробка програмного комплексу ................................................................. 91
4.1.1 Обґрунтування вибору засобів реалізації ............................................ 92
4.1.2 Опис структурної (функціональної) схеми .......................................... 98
4.1.3 Опис логічної схеми системи ................................................................ 102
4.1.4 Розробка бази даних .............................................................................. 103
4.1.5 Розробка інтерфейсу користувача ........................................................ 106
4.1.6 Опис розробки програмних компонентів ........................................... 112
4.2 Тестування системи........................................................................................ 115
4.2.1 Модульне тестування ........................................................................... 116
4.2.2 Інтеграційне тестування ...................................................................... 118
4.2.3 Системне тестування ........................................................................... 120
4.2.4 Приймальне тестування ....................................................................... 122
4.3 Приклади впровадженого програмного комплексу .................................... 125
ВИСНОВКИ ........................................................................................................... 131
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ........................................................... 135
ДОДАТКИ ............................................................................................................... 137
ЧДТУ 252482.006 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
API Application Programming Interface — програмний інтерфейс взаємодії
між програмними компонентами, що забезпечує обмін даними між
клієнтською та серверною частинами веб-застосунку.
CRUD базовий набір операцій для створення, читання, оновлення та
видалення даних у програмних системах.
БД база даних, організована сукупність структурованих даних, яка
використовується для зберігання фінансової інформації.
ER- модель проектування бази даних, яка описує сутність предметної
модель області та зв’язки між ними.
JSON JavaScript Object Notation текстовий формат обміну даними між
компонентами веб-застосунку.
MVC Model–View–Controller — архітектурний шаблон програмного
забезпечення, що розділяє логіку обробки даних, інтерфейс
користувача та керування.
REST Representational State Transfer — архітектурний стиль побудови веб-
сервісів, який використовується для організації клієнт-серверної
взаємодії.
UI User Interface — користувацький інтерфейс, що забезпечує взаємодію
користувача з веб-застосунком.
UX User Experience — користувацький досвід, що характеризує зручність,
ефективність та інтуїтивність роботи з програмним продуктом.
SQL Structured Query Language — мова структурованих запитів, яка
використовується для управління даними в реляційних базах даних.
HTTP HyperText Transfer Protocol — протокол передачі даних між клієнтом і
сервером у веб-застосунках.
4
ЧДТУ 252482.006 ПЗ
SPA Single Page Application — веб-застосунок, у якому взаємодія з
користувачем здійснюється без повного перезавантаження сторінок.
IDE Integrated Development Environment — інтегроване середовище
розробки програмного забезпечення.
ORM (Object-Relational Mapping) — технологія відображення об’єктної
моделі програми на структуру реляційної бази даних
5
ЧДТУ 252482.006 ПЗ
ВСТУП
Інженерія програмного забезпечення у сфері управління груповими
фінансами представляє в собі середовища програмного забезпечення та
цифрова економіка характеризуються високою волатильністю (фінансова
нестабільність, інфляційний тиск) та експоненційним зростанням складності
пропозиції цифрових фінансових продуктів (кредитні продукти, платіжні
сервіси, криптовалюти). У цих умовах, стійкість системи (фінансова
компетентність людини) — здатність свідомо планувати, контролювати борги та
формувати заощадження — стає критично важливою життєвою архітектурною
вимогою.
Водночас, сучасні сценарії використання (Use Cases) фінансових рішень
дедалі частіше виходять за межі монолітної індивідуальної системи і переходять
у розподілену групове середовище (сім'я, домогосподарство, команда
співмешканців, проектна група). Такі групові транзакції висувають нові вимоги
до протоколів та інтерфейсів: необхідність прозрачних інструментів фіксації
спільних витрат, алгоритмів розподілу часток та механізмів запобігання
конфліктам (дідлоків) навколо фінансових даних.
Актуальність теми обумовлюється критичними викликами програмної
інженерії в сфері фінансових технологій (FinTech) та необхідністю розробки
високонадійного, масштабованого та функціонально інтегрованого програмного
рішення. (платіжні сервіси, криптовалюти). У цих умовах, стійкість системи
(фінансова компетентність людини) — здатність свідомо планувати,
контролювати борги та формувати заощадження — стає критично важливою
життєвою архітектурною вимогою. (співмешканців, проектна група). Такі
групові транзакції висувають нові вимоги до протоколів та інтерфейсів:
необхідність прозрачних інструментів фіксації спільних витрат, алгоритмів
розподілу часток і механізмів запобігання конфліктам (дідлоків) навколо
фінансових даних.
Об’єкт дослідження є процеси програмної інженерії, пов’язані з аналізом
вимог, проектуванням архітектури, розробкою, тестуванням та реалізацією веб-
6
ЧДТУ 252482.006 ПЗ
орієнтованих програмних систем для управління особистими та груповими
фінансами користувачів.
Предмет дослідження є програмні моделі, алгоритми, архітектурні
шаблони, структури даних та методи інженерії програмного забезпечення, що
застосовуються при створенні веб-застосунку для обліку фінансових операцій,
бюджетування, аналітики та розподілу групових витрат.
Зокрема, дослідження зосереджується на таких ключових технічних
аспектах:
Програмна архітектура: принципи проектування масштабованої,
модульної та відмовностійкої трирівневої веб-архітектури (клієнтська частина,
серверний API, база даних), спеціально адаптованої для забезпечення високої
продуктивності та безпеки обробки фінансових транзакцій.
Моделювання даних (Data Modeling): методологія створення гібридної
моделі даних, що забезпечує консистентність і цілісність одночасного обліку
індивідуальних фінансових операцій (PFM) та складних, динамічно змінюваних
структур групових боргів та взаєморозрахунків.
Алгоритмічне забезпечення: розробка та реалізація спеціалізованих
алгоритмів для:
Автоматизованого та гнучкого розподілу спільних витрат згідно з різними
схемами.
Оптимізації фінальних розрахунків (settlements) шляхом мінімізації
необхідної кількості транзакцій між учасниками групи.
Технологічна інтеграція: методи інтеграції зовнішніх сервісів, зокрема
API для отримання актуальних курсів обміну валют (включаючи
криптовалюти), та їхнє використання для корректного ведення
мультивалютного обліку.
Верифікація та тестування: підходи програмної інженерії до валідації,
тестування (модульного, інтеграційного, системного) та оцінки функціональних
та нефункціональних характеристик (юзабіліті, безпека, продуктивність)
розробленого програмного забезпечення.
7
ЧДТУ 252482.006 ПЗ
Метою кваліфікаційної роботи є дослідження, проектування, розробка
та впровадження високоефективного та масштабованого веб-застосунку у сфері
FinTech, який, використовуючи принципи програмної інженерії, забезпечити
інтегроване управління:
Персональними фінансами (PFM): Дозволяючи користувачам вести
детальний облік доходів, витрат та заощаджень.
Груповими фінансами: Надаючи прозорі інструменти для фіксації
спільних витрат, автоматичного розрахунку часток, мінімізації боргів між
учасниками та запобігання фінансовим конфліктам.
Досягнення цієї мети передбачає розробку гібридної архітектури та
мультивалютної моделі даних, а також реалізацію ключового функціоналу:
аналізу структури витрат, конвертера валют та фінансових калькуляторів, що у
сукупності сприятиме підвищенню фінансової культури та відповідального
ставлення до грошей у населення.
Реалізація цієї мети передбачає вирішення низки взаємопов’язаних
завдань:
– проаналізувати предметну область «персональні фінанси» і сучасні
підходи до бюджетування;
– здійснити огляд та порівняння існуючих програмних продуктів;
сформувати вимоги до функціональності,
– інтерфейсу та якості програмного забезпечення; розробити
концептуальну, логічну й фізичну модель системи;
– реалізувати серверну й клієнтську частини веб-застосунку;
– провести комплексне тестування, експериментальне впровадження та
аналіз результатів використання.
У роботі застосовано комплекс загальнонаукових і спеціалізованих
методів дослідження: аналіз і синтез наукових джерел та прикладних рішень у
сфері фінансових технологій; порівняльний аналіз функціональних
можливостей існуючих застосунків; методи структурного та об’єктно-
орієнтованого моделювання (UML-діаграми варіантів використання, класів,
8
ЧДТУ 252482.006 ПЗ
компонентів, діяльності, послідовності та станів); елементи економіко-
математичного моделювання для розробки алгоритмів розподілу групових
витрат і бюджетного планування; інженерні методики тестування програмного
забезпечення (модульне, інтеграційне, системне й приймальне тестування);
експеримент із залученням реальних користувачів для оцінювання зручності
інтерфейсу та ефективності застосунку.
Наукова новизна роботи:
Вперше запропоновано програмно-інженерний підхід до побудови веб-
застосунку для управління особистими та груповими фінансами, який полягає у
формалізації фінансових процесів у вигляді узгоджених програмних моделей,
бізнес-правил та API-контрактів у межах єдиної архітектури, на відміну від
існуючих рішень, де персональні та групові фінанси реалізовані як ізольовані
функціональні модулі, що дозволяє забезпечити цілісність даних, повторне
використання компонентів і зменшення складності супроводу системи.
Удосконалено метод проєктування програмної логіки обліку та розподілу
фінансових операцій, шляхом застосування абстракцій предметної області,
об’єктно-орієнтованого моделювання та чіткого розмежування
відповідальностей між рівнями системи (presentation, application, domain, data),
що дозволило підвищити розширюваність програмного коду, тестованість
бізнес-логіки та стійкість системи до змін вимог.
Отримало подальший розвиток архітектурні принципи проєктування веб-
орієнтованих інформаційних систем, за рахунок інтеграції модульної
трирівневої архітектури, REST-орієнтованої взаємодії компонентів та
формалізованих моделей доступу користувачів, що дозволяє підвищити
масштабованість, підтримуваність і якісні характеристики програмного
забезпечення відповідно до вимог інженерії програмного забезпечення.
9
ЧДТУ 252482.006 ПЗ
РОЗДІЛ 1. ТЕОРЕТИЧНІ ОСНОВИ ТА АНАЛІЗ ІСНУЮЧИХ РІШЕНЬ У
СФЕРІ УПРАВЛІННЯ ОСОБИСТИМИ ТА ГРУПОВИМИ ФІНАНСАМИ
1.1 Аналіз предметної області «персональні фінанси» та постановка задачі
Персональні (особисті) фінанси розглядають як сукупність грошових
коштів, фінансових активів, зобов’язань та грошових потоків окремої особи, а
також процеси їх формування й використання для досягнення життєвих цілей.
У Національній стратегії з підвищення фінансової грамотності Національного
банку України персональні фінанси визначаються як усі грошові ресурси та
еквіваленти, що належать особі й нею управляються, включно з готівкою,
коштами на рахунках, заощадженнями, кредитами та страховими продуктами
[1]. У науковій літературі персональні фінанси зазвичай розглядають у складі
фінансів домогосподарств – поряд із бюджетом сім’ї, витратами на
життєзабезпечення, інвестиціями в людський капітал, пенсійними
накопиченнями [2; 3].
Особливість персональних фінансів полягає в тому, що вони поєднують
суто економічні категорії (доходи, витрати, активи, зобов’язання, ризик, часова
вартість грошей) із поведінковими й соціальними аспектами. Доходи фізичних
осіб складаються не лише із заробітної плати, а й з підприємницького й
інвестиційного доходу, соціальних трансфертів, неформальних грошових
переказів. Витрати охоплюють щоденне споживання, витрати на освіту та
медицину, сплату податків, обслуговування боргу, добровільні внески тощо [2;
4]. Кінцевою метою управління персональними фінансами є не лише
максимізація поточного споживання, а забезпечення стійкого добробуту
впродовж життєвого циклу – від молодості до пенсійного віку. Цей підхід
корелює з теорією життєвого циклу заощаджень, де домогосподарство
намагається згладити споживання в часі, приймаючи рішення щодо заощаджень
і боргу з урахуванням очікуваних майбутніх доходів і ризиків [5].
Світова та українська практика свідчать, що якість рішень у сфері
персональних фінансів суттєво залежить від рівня фінансової грамотності.
10
ЧДТУ 252482.006 ПЗ
Узагальнюючі дослідження А. Лусарді й О. Мітчелл показують, що більшість
людей у різних країнах не володіють базовими знаннями про процентні ставки,
інфляцію, диверсифікацію ризиків, а це прямо впливає на заощадження, боргове
навантаження та підготовку до пенсії [6; 7]. Для України результати
міжнародних обстежень OECD/INFE та національних досліджень НБУ також
фіксують низький рівень планування бюджету домогосподарств, недостатній
облік витрат і слабке використання інструментів довгострокового заощадження
[1; 8]. Відповідно, предметна область персональних фінансів охоплює не лише
«техніку» розрахунку показників, а й формування навичок планування,
контролю та відповідальної фінансової поведінки.
На рівні європейської політики персональні фінанси розглядаються крізь
призму фінансових компетентностей. Європейська комісія й OECD розробили
спеціальну рамку фінансових компетентностей для дорослих, де серед
ключових умінь виокремлено складання бюджету, управління грошовими
потоками, формування резервного фонду, порівняння фінансових продуктів,
усвідомлене використання цифрових фінансових сервісів та розуміння ризиків,
пов’язаних із боргом і довгостроковими зобов’язаннями [9]. Ці компетентності
безпосередньо трансформуються в задачі, які має підтримувати будь-який
сучасний інструмент управління персональними фінансами: наочне
відображення доходів і витрат, постановка фінансових цілей, моніторинг
прогресу та ідентифікація «вузьких місць» у структурі бюджету.
Важливим трендом розвитку предметної області є цифровізація. Масове
поширення онлайн- та мобільного банкінгу, електронних гаманців, платіжних
сервісів, а також поява цифрових активів (криптовалют, токенізованих
інструментів) радикально ускладнили фінансове середовище, в якому діє
пересічний користувач. Дослідження OECD і G20 підкреслюють, що без
розвитку цифрової фінансової грамотності споживачі ризикують стати
жертвами шахрайства, неправильно оцінювати вартість кредитних продуктів
або не розуміти ризики інвестицій у високоволатильні активи [10; 11]. Водночас
цифрові технології відкривають принципово нові можливості для управління
11
ЧДТУ 252482.006 ПЗ
персональними фінансами: автоматичний імпорт транзакцій, категоризація
витрат, нагадування про платежі, візуалізація фінансових цілей, інтеграція з
сервісами обміну валют і криптовалют.
У контексті України цифровізація фінансових послуг поєднується з
підвищеною макроекономічною нестабільністю, воєнними ризиками, частими
змінами доходів домогосподарств. Національний банк та урядові інституції
приділяють значну увагу просуванню фінансової освіти через цифрові канали,
зокрема через інформаційні кампанії, чат-боти, тематичні групи в месенджерах,
де в простій формі пояснюються базові принципи управління особистими
фінансами [1; 10]. Однак, попри активність публічних інституцій, багато
користувачів продовжують вести бюджет «у голові», у блокноті або розрізнених
таблицях, не маючи цілісної картини своїх доходів і зобов’язань, а також
ефективних інструментів для спільних (сімейних чи групових) фінансів.
Окрема специфіка предметної області – необхідність управління не лише
індивідуальними, а й груповими фінансами. До групових можна віднести
фінанси домогосподарства (сім’ї), побутові спільноти (оренда житла кількома
студентами), тимчасові проектні групи (організація заходів, волонтерських
ініціатив, спільних подорожей). У кожному з цих випадків постає завдання
прозорого обліку внесків, витрат, боргів та справедливого розподілу
фінансового навантаження між учасниками. Дослідження фінансів
домогосподарств підкреслюють, що прозорість інформації й чіткі правила
спільного бюджету зменшують ймовірність конфліктів і сприяють досягненню
довгострокових фінансових цілей сім’ї [4]. Проте більшість масових
інструментів обліку орієнтовані на одну особу й погано пристосовані до
гнучкого налаштування ролей та прав доступу в групі.
Отже, аналіз предметної області дозволяє сформулювати ключові
проблеми, на які має відповідати програмне рішення. По-перше, це
фрагментованість фінансової інформації: доходи й витрати користувача
розподілені між різними банківськими рахунками, картками, готівкою,
електронними гаманцями, а інколи – криптовалютними біржами. По-друге,
12
ЧДТУ 252482.006 ПЗ
відсутність інтегрованих інструментів для поєднання особистого та групового
бюджетування: користувачі змушені окремо вести особистий облік, окремо –
сімейний чи «спільний» бюджет, часто в різних застосунках чи файлах. По-
третє, складність для нефахівців у трактуванні фінансових показників: навіть
маючи таблицю витрат, пересічна людина не завжди може з’ясувати, чи є її
фінансова поведінка стійкою, які категорії «з’їдають» найбільше ресурсу, який
мінімальний рівень резервів є безпечним. Нарешті, значна частина користувачів
не має внутрішньої мотивації щоденно вручну заповнювати таблиці – без
зручного й візуально привабливого інтерфейсу бюджетування перетворюється
на рутинну й часто закинуту практику.
У цьому контексті можна сформулювати постановку задачі, яка виростає з
потреб предметної області. Потрібно розробити веб-застосунок для управління
особистими та груповими фінансами, який, по-перше, забезпечуватиме
централізований облік доходів, витрат, активів і зобов’язань користувача з
можливістю гнучкої категоризації та фільтрації операцій; по-друге, дозволятиме
створювати спільні фінансові простори (групи) для сімей, домогосподарств чи
тимчасових об’єднань, де учасники можуть планувати бюджет, фіксувати
внески та витрати, контролювати баланс і борги; по-третє, інтегруватиме
інструменти бюджетування та фінансового планування (цільові фонди,
віртуальні «конверти», правила розподілу доходів, розрахунок резервного
фонду) з наочними панелями показників; по-четверте, використовуватиме
можливості цифрового середовища – автоматичне оновлення курсів валют,
базові конвертаційні операції, за потреби відображення орієнтовної вартості
криптоактивів; по-п’яте, надаватиме користувачеві прості, зрозумілі візуалізації
та текстові підказки для інтерпретації власної фінансової поведінки на основі
загальновизнаних рекомендацій з фінансової грамотності [1; 9; 11].
Таким чином, предметна область «персональні фінанси» вимагає від
програмного продукту не лише функцій бухгалтерського обліку, а й реалізації
підходів фінансової освіти та поведінкової підтримки користувача. Дипломна
робота зосереджується на розробленні веб-застосунку, що поєднує
13
ЧДТУ 252482.006 ПЗ
індивідуальне й групове бюджетування, підтримує сучасні моделі фінансового
планування й сприяє формуванню у користувачів навичок відповідального
управління особистими й спільними ресурсами.
1.2 Підходи й методи бюджетування та фінансового планування
користувачів
У сучасних дослідженнях особистих фінансів бюджетування розглядають
як базову поведінкову компетентність, без якої неможливі ані довгострокове
фінансове планування, ані формування фінансової стійкості домогосподарств. У
рекомендаціях OECD/INFE бюджет прямо називається одним із ключових
«фінансових поведінкових індикаторів»: людина, яка планує доходи й витрати
хоча б на місяць уперед, рідше стикається з простроченою заборгованістю та
частіше має заощадження [1]. Для України результати дослідження USAID та
НБУ демонструють, що саме навичка ведення бюджету істотно відрізняє групу
з вищою фінансовою грамотністю від решти населення: ці респонденти частіше
ведуть облік витрат, мають резервний фонд і краще контролюють боргове
навантаження [2].
У теоретичному плані бюджетування та фінансове планування
спираються на класичні уявлення про «життєвий цикл» споживання:
домогосподарство прагне згладити рівень добробуту протягом життя,
перерозподіляючи доходи між поточним споживанням, заощадженнями та
інвестиціями. На практиці ж поведінка користувачів серйозно відхиляється від
раціональної моделі через обмежену обізнаність, короткий горизонт планування
та поведінкові упередження (преференцію «сьогодні» над «завтра», ефект
відкладання рішень тощо). Методи бюджетування покликані компенсувати ці
обмеження, забезпечуючи прості правила, які перетворюють абстрактне «треба
заощаджувати» на конкретні дії. Дослідження Т. Кайзера та А. Лузарді
показують, що навчання таким простим правилам – від побудови бюджету до
встановлення цільового рівня заощаджень – суттєво покращує як фінансові
знання, так і реальну поведінку домогосподарств [3].
14
ЧДТУ 252482.006 ПЗ
У літературі та практиці персональних фінансів можна виокремити кілька
базових підходів до бюджетування, які сьогодні комбінуються користувачами та
реалізуються в цифрових застосунках. Перший з них – традиційне інкрементне
бюджетування, коли майбутній план доходів і витрат будується на основі
фактичних попередніх періодів. Користувач спочатку фіксує поточні доходи,
класифікує витрати за категоріями (житло, харчування, транспорт, дозвілля,
боргові платежі тощо), а потім коригує структуру витрат у бік бажаних
пріоритетів. Такий підхід добре узгоджується з рекомендаціями фінансових
регуляторів, які наголошують на необхідності регулярного моніторингу
«грошового потоку» домогосподарства як основи фінансового плану [2; 4].
Друга група методів ґрунтується на простих пропорційних правилах, які
задають цільову структуру бюджету. Найвідомішим є правило 50/30/20,
популяризоване Е. Воррен та А. Воррен Тайгі у книзі All Your Worth: The
Ultimate Lifetime Money Plan: 50 % чистого доходу спрямовується на «необхідні
витрати», 30 % – на «бажання», а 20 % – на заощадження й погашення боргу
[4]. Подальші адаптації, зокрема модель 60/30/10, враховують зростання частки
обов’язкових витрат у структурі доходу в умовах інфляції, але логіка
залишається незмінною: користувачеві пропонується орієнтир, який дозволяє
швидко оцінити, чи не «з’їдають» поточні витрати потенційні заощадження [5].
Перевага таких правил у їхній когнітивній простоті: навіть при обмеженій
фінансовій грамотності людина здатна зрозуміти, що, наприклад, витрати на
житло та базові потреби не мають перевищувати певну частку заробітку, а
щонайменше 10–20 % доцільно резервувати на майбутнє.
Третій підхід – бюджетування «з нульової бази» (zero-based budgeting,
ZBB), ідея якого належить Пітеру Пірру та була розроблена ще у 1970-х роках
[6]. На відміну від інкрементного бюджету, що спирається на витрати минулих
періодів, ZBB передбачає, що кожна стаття витрат у новому періоді має бути
заново обґрунтована. У площині особистих фінансів цей підхід
трансформувався в правило «дай кожній гривні завдання»: дохід повністю
15
ЧДТУ 252482.006 ПЗ
«розкладається» по конкретних «робочих місцях» – обов’язкові рахунки, цілі
заощаджень, фонди на великі майбутні витрати. Саме так сформульовані
«чотири правила» методики YNAB (You Need A Budget): дати кожній одиниці
доходу конкретну роль, планувати «справжні» витрати, гнучко коригувати
бюджет і працювати лише з наявними коштами [7]. Для користувача це означає
перехід від пасивного спостереження за витратами до активно керованого
плану, у якому випадкові витрати витісняються цільовими.
Четвертий важливий метод – система конвертів (envelope system), яка
передбачає розподіл готівки за окремими конвертами для кожної категорії
витрат: «продукти», «транспорт», «розваги» тощо. Відомі популяризатори
особистих фінансів, зокрема Д. Ремзі, пропонують використовувати цей метод
як інструмент самоконтролю для людей, які схильні до імпульсивних карткових
витрат [8]. Сучасна версія цієї техніки – «cash stuffing», що набув популярності
в соціальних мережах серед молоді: користувачі фізично розкладають гроші по
конвертах, знімаючи з себе спокусу «перекривати» перевищені категорії
кредитом або овердрафтом. Емпіричні дослідження показують, що саме факт
фізичного обмеження (коли конверт порожній – витрати припиняються) є
потужним поведінковим «якорем», який допомагає дотримуватися бюджету й
знижує ризик надмірної заборгованості [9].
П’ятим напрямом є цільове бюджетування та фінансове планування, у
межах якого бюджет розглядається як інструмент досягнення чітко визначених
фінансових цілей. До таких методів належать підхід «заплати спочатку собі»
(pay yourself first), коли певний відсоток доходу автоматично спрямовується у
заощадження чи інвестиції, а потім плануються всі інші витрати; «фонд цілей»,
де для кожної мети (резервний фонд, освіта, подорож, пенсійні накопичення)
формуються окремі «кошики»; а також програмування грошових потоків у
часовому вимірі (cash-flow planning). Ці підходи узгоджуються з
рекомендаціями міжнародних організацій щодо мінімального рівня резервів (3–
6 місяців витрат) та довгострокового пенсійного планування, зафіксованими в
16
ЧДТУ 252482.006 ПЗ
стратегіях фінансової просвіти [10]. У цьому випадку метод бюджетування стає
частиною ширшої стратегії управління життєвими ризиками – втратою роботи,
хворобою, необхідністю догляду за родичами, старістю.
Шостий важливий вимір сучасних методів бюджетування – їхня
цифровізація. Мобільні застосунки з функціями імпорту банківських
транзакцій, автоматичної категоризації витрат, побудови звітів, попереджень
про перевищення лімітів та планування заощаджень значно знижують
транзакційні витрати користувача на ведення бюджету. Такі сервіси реалізують
різні згадані методи: одні застосунки орієнтуються на «правило 50/30/20», інші
– на ZBB, ще інші пропонують віртуальні «конверти» для категорій витрат.
Дослідження ефективності бюджетування демонструють, що поєднання
простих правил із цифровою підтримкою (нагадування, візуалізація трендів,
автоматичний підрахунок залишків) істотно підвищує ймовірність того, що
домогосподарство послідовно дотримуватиметься обраної стратегії [11]. Для
України це особливо актуально з огляду на швидке поширення цифрових
фінансових сервісів і водночас збереження відносно низького середнього рівня
фінансової грамотності.
Сьомий аспект стосується групового та сімейного бюджетування. На
відміну від індивідуального планування, тут постає проблема узгодження
пріоритетів кількох осіб, різної толерантності до ризику та відмінних часових
горизонтів. Література з фінансів домогосподарств розглядає спільний бюджет
як результат переговорів між членами сім’ї, де бюджет виконує не лише
облікову, а й комунікаційну функцію: він фіксує домовленості щодо внеску
кожного, спільних цілей та правил користування спільними коштами [12].
Методи, які добре працюють у парі або невеликій групі, зазвичай комбінують
елементи «конвертів» і ZBB: частина коштів спрямовується у спільні фонди
(оренда, комунальні послуги, спільні покупки), решта залишається в
індивідуальному розпорядженні. При цьому особливу увагу приділяють
прозорості – спільний доступ до інформації про баланс рахунків і історію
17
ЧДТУ 252482.006 ПЗ
операцій знижує ризики конфліктів і підвищує довіру.
Узагальнюючи, можна стверджувати, що сучасні підходи до
бюджетування та фінансового планування користувачів рухаються від
статичного «календаря платежів» до динамічної системи управління ресурсами,
яка поєднує поведінкові «правила великого пальця», цифрові інструменти й
елементи довгострокового стратегічного планування. Жоден із розглянутих
методів не є універсальним: їхня результативність залежить від рівня доходу,
дисципліни, цифрових навичок, складу сім’ї та індивідуальних фінансових
цілей. Однак емпіричні дослідження одностайні в одному: регулярне ведення
бюджету – у будь-якій з форм – позитивно корелює з більш високою
фінансовою грамотністю, наявністю заощаджень і суб’єктивним відчуттям
фінансового благополуччя [2; 3; 11]. Саме тому розробка інструментів, які
дозволяють користувачу гнучко комбінувати пропорційні правила, нульову базу,
конверти та цільове планування, є ключовим завданням сучасних веб-
застосунків для управління особистими та груповими фінансами.
1.3 Огляд існуючих програмних продуктів для управління
особистими та спільними фінансами
Ринок цифрових рішень для управління персональними фінансами
сьогодні надзвичайно фрагментований: користувачеві доступні як
спеціалізовані застосунки для бюджетування, так і мобільні банки з вбудованою
аналітикою, а також сервіси, що орієнтовані винятково на спільні витрати в
групах. Для побудови вимог до власного веб-застосунку доцільно розглянути
кілька репрезентативних прикладів, які демонструють різні підходи до роботи з
особистими й спільними фінансами.
Одним із найвідоміших спеціалізованих застосунків для персонального
бюджетування є YNAB (Рис. 1.1) (You Need A Budget). Це веб- та мобільний
сервіс, побудований на принципах нульового бюджетування: кожній одиниці
доходу користувача надається конкретне «завдання» в межах певної категорії
(витрати, борг, заощадження), що унеможливлює появу «вільних» грошей без
18
ЧДТУ 252482.006 ПЗ
призначення. На офіційному сайті підкреслюється, що метод YNAB базується
на чотирьох правилах («дай кожному долару роботу», «плануй справжні
витрати», «коригуй бюджет» тощо), а 90 % користувачів декларують
поліпшення фінансового стану після початку використання сервісу. Хоча
продукт формально орієнтований на одну особу, він дозволяє спільний доступ
до бюджету (наприклад, для пари), а завдяки моделі «один акаунт – кілька
бюджетів» можна окремо обліковувати сімейні та індивідуальні фінанси.
Основний акцент тут зроблено на проактивному плануванні: користувач працює
не просто з історією транзакцій, а з планами на майбутні витрати та цілі
заощаджень.
Рис. 1.1 – Застосунок YNAB
19
ЧДТУ 252482.006 ПЗ
Інший тип спеціалізованих рішень демонструє застосунок Wallet by
BudgetBakers. Це мультиплатформний менеджер персональних фінансів, який
позиціонується як інструмент для «єдиного погляду на всі гроші». За
інформацією розробника, Wallet підтримує автоматичну синхронізацію з понад
15 000 банківських установ по всьому світу, що дозволяє імпортувати транзакції
з різних рахунків і карток, автоматично їх категоризувати та формувати
аналітичні звіти. Застосунок підтримує мультивалютність, роботу з готівкою,
ведення боргів, нагадування про рахунки, детальні графіки доходів і витрат.
Окремою перевагою є можливість «поділитися» окремими бюджетами чи
гаманцями з іншими користувачами, що перетворює Wallet на потенційний
інструмент для сімейного або групового бюджетування без створення повністю
спільного акаунта.
Рис. 1.2 – Застосунок Wallet by BudgetBakers
20
ЧДТУ 252482.006 ПЗ
Приклад інтеграції бюджетування безпосередньо у фінансову
інфраструктуру дає необанк Revolut. Окрім стандартних платіжних функцій,
Revolut пропонує модуль Budget & Analytics, який дозволяє розподіляти
заробітну плату по «кишенях» (Pockets / Vaults) – умовно окремих внутрішніх
рахунках для регулярних платежів, заощаджень чи конкретних цілей.
Користувач може автоматично розбивати дохід на категорії («рахунки»,
«повсякденні витрати», «заощадження»), а також відстежувати витрати за
категоріями й періодами через вбудовану аналітику. Для спільних фінансів
Revolut пропонує групові рахунки й функції поділу рахунків (bill splitting), що
дає змогу кільком користувачам ділити витрати в подорожах чи
домогосподарстві. Однак ці групові можливості переважно «прив’язані» до
факту проведення карткових операцій у самому банку й менш гнучкі, ніж у
вузькоспеціалізованих «групових» сервісів.
Специфічний для українського ринку приклад – цифровий банк
monobank. У додатку monobank, окрім класичних карткових операцій,
реалізовано низку функцій, які прямо стосуються управління особистими та
спільними фінансами: «банки» (jars) для накопичень і планування бюджету,
категоризація витрат з побудовою аналітики, кешбек за окремими категоріями
та щомісяця змінюваними партнерами, а також можливість «розділити» чек між
друзями. Офіційний опис підкреслює наявність «банок для накопичень і
бюджету», аналітики витрат, інструментів спільних зборів (наприклад, на ЗСУ
чи благодійність), а також функцій для дитячих карток із контролем витрат. У
результаті monobank поєднує щоденні банківські операції із простими
інструментами бюджетування, що робить його де-факто фінансовим
менеджером для значної частини молодої аудиторії в Україні, хоча повноцінних
механізмів групового бюджетування (з окремими ролями, формальними
групами користувачів тощо) у ньому поки що бракує.
Нішу суто групових фінансів представляє застосунок Splitwise, який
спеціалізується на обліку спільних витрат і боргів між друзями, сусідами по
квартирі, учасниками подорожей. За офіційним описом, Splitwise дозволяє
21
ЧДТУ 252482.006 ПЗ
створювати групи (trip, home, couple), додавати витрати, автоматично
розподіляти їх між учасниками за рівними частками, відсотками або
індивідуально заданими сумами, відстежувати сальдо («хто кому і скільки
винен») та фіксувати погашення боргів. Застосунок доступний у веб-версії, на
Android та iOS, має безкоштовний тариф і преміум-версію з додатковими
можливостями (сканування чеків, розширені звіти тощо). Splitwise фактично не
займається класичним бюджетуванням у сенсі планування доходів і витрат
наперед, але дуже добре розв’язує проблему прозорості спільних витрат і
справедливого розподілу фінансового навантаження в групі.
Як приклад гібридного рішення для персональних і сімейних фінансів
можна розглядати Wallet (з можливістю «шерингу» рахунків) та інші подібні
продукти, що дозволяють створювати спільні «гаманці» для подружніх пар чи
домогосподарств. Офіційний опис Wallet вказує, що користувач може
налаштовувати спільний доступ до окремих функцій для членів родини або
партнерів, зберігаючи водночас приватність інших рахунків і категорій. Такий
підхід є показовим для нашої предметної області: продукт лишається
орієнтованим на «персональні фінанси», але додає певний рівень підтримки
спільного бюджетування без складної ролевої моделі.
Для узагальнення ключових характеристик розглянутих рішень доцільно
подати порівняльну таблицю (табл. 1.1).
Таблиця 1.1
Порівняльна характеристика програмних продуктів для управління
особистими та спільними фінансами
Продукт Основне Платформи Модель Ключові Можливості
призначення монетизації можливості для спільних
для / групових
персональних фінансів
фінансів
22
ЧДТУ 252482.006 ПЗ
Продовження таблиці 1.1
YNAB Спеціалізоване Web, Платна підписка Нульове Спільний
нульове Android, (free trial) бюджетування доступ до
бюджетування iOS , планування бюджету
«справжніх» (наприклад,
витрат, цілі для пари),
заощаджень, але без
звіти, кілька розвиненої
бюджетів в групової
акаунті моделі
Wallet Менеджер Web, Freemium: Автоматична Можливість
персональних Android, базовий синхронізація ділитися
фінансів з iOS безкоштовний + з банками, окремими
банківською преміум мультивалютні гаманцями/б
синхронізаціє сть, юджетами з
ю категоризація, іншими
детальні звіти, користувача
планування ми
бюджету
Revolut Необанк із Android, Freemium Аналітика Поділ
вбудованим iOS, Web (безкоштовний витрат та рахунків,
бюджетування та платні плани) доходів, групові
м бюджети за витрати,
категоріями, спільні
«кишені»/vault «кишені»/ра
s для цілей, хунки
мультивалютні (залежно від
рахунки тарифу)
23
ЧДТУ 252482.006 ПЗ
Продовження таблиці 1.1
monobank Цифровий Android, Безкоштовний Категоризація Поділ чека,
банк з iOS додаток, дохід – витрат, спільні
елементами банківські аналітика, «банки» для
фінансового послуги «банки» для зборів
менеджера накопичень, (донати,
кешбек, цілі), дитячі
депозити, картки з
валютні контролем
картки
Splitwise Облік спільних Web, Freemium, Pro- Мінімальний Повноцінний
витрат і боргів Android, підписка персональний облік
у групі iOS облік; фокус групових
на фіксації витрат,
витрат і гнучкий
сальдо між поділ
учасниками рахунків,
сальдо «хто
кому винен»
Як видно з таблиці, розглянуті продукти покривають різні сегменти
потреб користувачів. YNAB і Wallet орієнтовані насамперед на класичне
бюджетування та глибоку аналітику персональних фінансів, але лише частково
підтримують спільні бюджети. Revolut і monobank інтегрують базове
бюджетування безпосередньо в банківські сервіси, зменшуючи бар’єр входу для
користувача, проте їхні інструменти планування й групових фінансів часто
обмежені рамками банківської інфраструктури. Splitwise, навпаки, майже не
оперує категоріями доходів і витрат користувача, зате дуже добре вирішує
вузьку задачу прозорого розподілу спільних витрат.
Для постановки вимог до розроблюваного веб-застосунку важливі кілька
24
ЧДТУ 252482.006 ПЗ
висновків із цього огляду. По-перше, більшість рішень або сильні в
індивідуальному бюджетуванні, або в груповому обліку, але рідко поєднують
обидва аспекти на рівні однієї моделі даних та інтерфейсу. По-друге,
користувачі очікують автоматизації (імпорт транзакцій, актуальні курси валют,
нагадування) та наочної аналітики, а не лише «ручних» форм введення. По-
третє, підтримка мультивалютності та, за потреби, орієнтовної оцінки вартості
цифрових активів (криптовалют) стає дедалі актуальнішою, особливо для
мобільних і міграційно активних користувачів. По-четверте, при роботі зі
спільними фінансами критичне значення має прозорість правил розподілу,
можливість фіксувати внески та борги й одночасно зберігати приватність
персональних бюджетів. Саме ці ідеї доцільно закласти в архітектуру та
функціонал власного веб-застосунку для управління особистими та груповими
фінансами.
1.4 Вимоги до функціональності веб-застосунку для управління
особистими та груповими фінансами
Сформульовані в попередніх підрозділах особливості предметної області
та огляд наявних рішень дозволяють перейти до визначення вимог до
функціональності веб-застосунку. Відповідно до підходів стандарту ISO/IEC
25010, функціональна придатність (functional suitability) розглядається як
здатність програмного продукту надавати користувачеві саме ті функції, які
відповідають явним і неявним потребам, причому важливими є повнота,
коректність і доречність цих функцій [1; 2]. Для веб-застосунку, орієнтованого
на управління особистими та груповими фінансами, це означає, що набір
функцій має безпосередньо підтримувати ключові завдання користувача: вести
облік доходів і витрат, планувати бюджет, формувати заощадження, управляти
боргами, координувати спільні витрати в групі та приймати обґрунтовані
фінансові рішення в мультивалютному середовищі.
Передусім застосунок має забезпечувати повний цикл роботи з обліком
персональних фінансів. На основі типових вимог до застосунків для
25
ЧДТУ 252482.006 ПЗ
персонального фінансового менеджменту, описаних у вимогових специфікаціях
і прикладних розробках [3; 4], можна визначити необхідність підтримки таких
базових сценаріїв: реєстрація користувача, безпечна автентифікація, створення
та редагування профілю, налаштування базової валюти, мови інтерфейсу й
часових параметрів; створення «рахунків» (банківські картки, готівка,
електронні гаманці, інвестиційні рахунки) з можливістю вказати валюту,
початковий баланс, тип рахунку; реєстрація операцій доходів та витрат із
прив’язкою до рахунку, категорії, дати й контрагента. Дослідження
персональних фінансових застосунків демонструють, що саме можливість
швидко додати або автоматично імпортувати транзакції, а також гнучка
категоризація витрат є ядром «щоденної корисності» таких сервісів [4; 5].
Другою групою функціональних вимог є бюджетування та фінансове
планування. Виходячи з аналізу сучасних методів бюджетування (пропорційні
правила, нульове бюджетування, система «конвертів» тощо), застосунок має
дозволяти користувачу формувати бюджети на місяць, квартал або інший період
з розподілом по категоріях доходів і витрат, а також установлювати фінансові
цілі (резервний фонд, погашення кредиту, велика покупка). У вимогових звітах
для застосунків управління фінансами наголошується, що базова
функціональність повинна включати постановку бюджетів та фінансових цілей,
відстеження їх виконання й автоматичне формування звітів за місяць/рік [3; 6].
З огляду на те, що у дипломному проєкті планується застосувати елементи
нульового бюджетування, функціональні вимоги мають передбачати можливість
«призначення» кожної одиниці доходу конкретній категорії або цілі, а також
гнучкого перерозподілу сум у випадку зміни пріоритетів користувача.
Окремий блок становлять функції аналітики та візуалізації, без яких
користувачеві складно зрозуміти загальну картину власної фінансової
поведінки. Типові проєкти та наукові публікації вказують, що сучасний
застосунок має формувати агреговані звіти за доходами й витратами (за
категоріями, за рахунками, у часовому розрізі), відображати ці дані у вигляді
графіків і діаграм, а також надавати користувачу короткі текстові інтерпретації
26
ЧДТУ 252482.006 ПЗ
ключових показників [4; 5; 7]. Для підтримки фінансової грамотності доцільно
передбачити показники, що резюмують фінансову стійкість користувача: частку
заощаджень у доході, співвідношення обов’язкових і дискреційних витрат,
рівень боргового навантаження тощо. Рекомендації OECD щодо цифрових
інструментів фінансової освіти підкреслюють, що прості візуальні індикатори
(«світлофор», шкали, прогрес-бар для цілей) та персоналізовані підказки
суттєво підвищують ефективність навчання навичкам управління грошима [8;
9].
Ключовою відмінною рисою цільового веб-застосунку є підтримка
групових (спільних) фінансів. На основі аналізу продуктів на кшталт Splitwise,
які спеціалізуються на обліку спільних витрат [10], можна сформулювати
вимоги до відповідного модуля системи: можливість створення груп (сім’я,
квартира, подорож, проєкт) із запрошенням інших користувачів; визначення
ролей (власник групи, учасник, за потреби – спостерігач) та прав доступу;
ведення спільних «гаманців» або бюджетів групи; фіксація витрат із вибором
платника(ів) і перелік учасників, між якими розподіляється сума; підтримка
різних схем поділу (порівну, за відсотками, за фіксованою сумою на учасника).
Інтерфейс має автоматично розраховувати сальдо боргів між учасниками групи
та надавати рекомендації щодо мінімальної кількості платежів для
взаєморозрахунків, що відповідає найкращим практикам подібних сервісів [10;
11]. Важливо, щоб реалізація групових фінансів органічно поєднувалася з
особистими: одні й ті самі користувачі мають мати змогу в межах одного
акаунта вести як власний бюджет, так і брати участь у кількох групових
просторах.
З огляду на мультивалютний характер сучасних фінансів, обов’язковою є
підтримка роботи з кількома валютами. Функціональні вимоги мають
передбачати: можливість задавати довільну базову валюту для профілю
користувача; зберігання рахунків у різних валютах; конвертацію сум за
27
ЧДТУ 252482.006 ПЗ
актуальним курсом для відображення зведених показників; доступ до історії
курсів, якщо планується аналіз динаміки. Для цього необхідна інтеграція із
зовнішнім API курсів валют (наприклад, офіційних курсів НБУ або комерційних
провайдерів) з періодичним оновленням даних. Практичні гіди зі створення
застосунків для управління фінансами підкреслюють, що мультивалютність та
інтеграція з курсами валют (а за потреби – і з курсами криптовалют) сьогодні є
очікуваною базовою функціональністю, особливо для користувачів, які
працюють або здійснюють покупки за кордоном [5; 7].
З цим пов’язаний блок вимог до інструментів конвертації та допоміжних
фінансових калькуляторів. Оскільки в дипломному проєкті передбачається
додавання вбудованого конвертера валют і криптовалют та простих
калькуляторів (наприклад, кредитного, депозитного, «скільки можна витрачати
щодня, щоб не перевищити бюджет»), у специфікації треба прямо зафіксувати:
користувач має мати змогу обрати вихідну й цільову валюту, ввести суму та
побачити результат конвертації за поточним курсом; у калькуляторах — вводити
основні параметри (сума, ставка, строк, тип платежу) й отримувати розрахунок
щомісячного платежу, загальної переплати тощо. Такі інструменти, за
рекомендаціями міжнародних організацій щодо цифрової фінансової освіти, не
лише вирішують прикладні завдання, а й сприяють кращому розумінню
вартості кредитів, реальної дохідності заощаджень і впливу інфляції на гроші
[8; 12].
Важливим функціональним аспектом є інтеграція із зовнішніми
джерелами даних та експорт/імпорт інформації. Навіть якщо у базовій версії
застосунок не підключається безпосередньо до банківських API, специфікація
має передбачати потенційну можливість такої інтеграції: обробку CSV/Excel-
файлів із виписками з банків, імпорт і експорт транзакцій, бюджетів та звітів.
Аналіз наявних продуктів (Mint, Wallet, низка мобільних PFM-застосунків)
показує, що користувачі очікують можливості експортувати дані для
28
ЧДТУ 252482.006 ПЗ
подальшого аналізу в сторонніх інструментах або резервного копіювання [4; 5;
7]. Для веб-орієнтованого рішення доцільно передбачити генерацію PDF- та
CSV-звітів, які можна надсилати електронною поштою або зберігати локально.
Окрема група вимог стосується керування сповіщеннями та підказками.
Згідно з рекомендаціями OECD щодо цифрової фінансової освіти, своєчасні,
але не нав’язливі сповіщення можуть використовуватися як інструмент
підтримки потрібної фінансової поведінки: нагадування про наближення
дедлайнів платежів, попередження про перевищення бюджетних лімітів,
підказки про недостатній рівень резервів тощо [8; 9; 21]. У функціональній
специфікації це має бути зафіксовано як можливість налаштовувати типи,
частоту й канали сповіщень (у межах веб-інтерфейсу та, за потреби,
електронною поштою чи push-повідомленнями у мобільній версії в
майбутньому).
Ще один важливий вимір – локалізація та підтримка освітнього контенту.
Фреймворк фінансових компетентностей ЄС/OECD прямо зазначає цифрові
фінансові інструменти як засіб формування компетентностей, пов’язаних з
управлінням грошима, розумінням цифрових фінансових послуг та цифрових
активів [13]. Тому в межах функціональних вимог доцільно передбачити:
підтримку української мови інтерфейсу (як основної) з можливістю додавання
інших мов; довідкові матеріали й короткі підказки до складних функцій
(інтерпретація індикаторів, пояснення принципів бюджетування, попередження
щодо ризиків кредитування та інвестицій). Такі елементи поєднують
прикладний та освітній компоненти системи, що відповідає завданню
підвищення фінансової грамотності користувачів.
Для зручності узагальнення основні функціональні підсистеми та їх
ключові функції можна представити у вигляді таблиці (табл. 1.2).
Таблиця 1.2
29
ЧДТУ 252482.006 ПЗ
Основні функціональні підсистеми веб-застосунку та їх призначення
Функціональна Ключові функції Очікуваний результат
підсистема для користувача
Управління Реєстрація, вхід, профіль, Персоналізований,
користувачами та налаштування мови, валюти, захищений доступ до
доступом часових параметрів власних і групових
фінансів
Особисті фінанси Створення рахунків, введення Повна й актуальна
доходів/витрат, категоризація, картина власних
пошук і фільтрація транзакцій фінансових потоків
Бюджети та Створення бюджетів, планування Системне планування
фінансові цілі цілей, нульове бюджетування, витрат і заощаджень,
контроль виконання моніторинг прогресу
Групові фінанси Створення груп, спільні гаманці, Прозорий та
поділ витрат, розрахунок боргів і справедливий розподіл
сальдо спільних витрат у сім’ї
чи групі
Аналітика та Діаграми доходів/витрат, Швидке розуміння
звітність індикатори фінансової стійкості, фінансової ситуації й
звіти (місячні, річні), експорт можливість подальшого
даних аналізу
Сповіщення та Нагадування про платежі, Підтримка потрібної
підказки повідомлення про перевищення фінансової поведінки
бюджетів, освітні підказки без постійного ручного
контролю
Звісно, повний перелік функцій може бути розширений у процесі
детального проєктування й реалізації прототипу, однак уже на етапі
30
ЧДТУ 252482.006 ПЗ
формулювання вимог важливо задати логіку, за якою всі окремі можливості
складаються в цілісну систему підтримки прийняття фінансових рішень
користувачем. Веб-застосунок повинен не лише збирати дані про доходи й
витрати, а й перетворювати їх на зрозумілі сигнали та рекомендації,
допомагаючи користувачеві будувати як особистий, так і спільний бюджет
відповідно до сучасних підходів фінансового планування й міжнародних
рекомендацій у сфері цифрової фінансової грамотності.
31
ЧДТУ 252482.006 ПЗ
Висновок до розділу 1
У першому розділі було здійснено комплексний аналіз предметної галузі
«персональні фінанси» у контексті сучасних соціально-економічних умов, які
характеризуються високою мінливістю доходів та зростанням ролі
безготівкових розрахунків та криптовалют. Дослідження показало, що
користувачі потребують інтегрованих інструментів не лише для обліку власних
доходів та витрат, але й для прозрачного ведення спільного бюджету в межах
домогосподарств, малих груп чи проектних команд. Огляд і порівняльний аналіз
наявних програмних продуктів (таких як YNAB, Wallet, Splitwise) виявив, що
більшість рішень сильні або в індивідуальному бюджетуванні, або у вузькій
задачі групового обліку, але рідко поєднують обидва аспекти в межах однієї
архітектури та моделі даних. На основі цього були сформульовані ключові
вимоги до функціональності веб-застосунку, який має підтримувати
мультивалютність, динамічні схеми розподілу витрат та цілісне відображення
фінансового стану користувача.
32
ЧДТУ 252482.006 ПЗ
РОЗДІЛ 2. ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ
2.1 Теоретичні дослідження
Підрозділ «Теоретичні дослідження» у цій дипломній роботі виконує
функцію методологічного «каркаса», на який спирається все подальше
проєктування веб-застосунку для управління особистими та груповими
фінансами. Його зміст полягає в розкритті тих підходів, гіпотез і методів
розрахунків, за допомогою яких повсякденна фінансова практика користувачів
перетворюється на формалізовану модель, придатну для програмної реалізації.
Вихідною позицією теоретичного аналізу є уявлення про інтегрований
фінансовий простір користувача. У реальному житті особа оперує кількома
рахунками (банківські картки, готівка, електронні гаманці), здійснює витрати в
різних валютах, бере участь у спільних платежах у межах сім’ї,
домогосподарства, волонтерської ініціативи чи тимчасових груп. Зовнішнім
середовищем для цього простору виступають банківські та платіжні сервіси,
джерела інформації про курси валют, нормативно-правове поле, а також
соціальні очікування щодо прозорості й справедливості спільних фінансових
рішень. Теоретичне дослідження має виявити суттєві зв’язки між цими
елементами, узагальнити їх та подати у вигляді моделі, яка визначатиме, як саме
повинен працювати веб-застосунок.
Ключова гіпотеза роботи полягає в тому, що побудова цілісної моделі, яка
поєднує облік особистих і групових фінансів, бюджетування, постановку та
досягнення фінансових цілей, а також підтримку мультивалютних розрахунків,
дозволяє знизити хаотичність фінансової поведінки, зменшити кількість
облікових помилок і конфліктів щодо спільних витрат, підвищити прозорість
фінансового стану користувача і його оточення. У цьому сенсі теоретичні
дослідження не зводяться лише до опису функцій майбутнього застосунку, а
прагнуть віднайти загальні закономірності, що описують, як користувачі
приймають фінансові рішення та як ці рішення можна підтримати на рівні
моделі.
33
ЧДТУ 252482.006 ПЗ
Першим етапом теоретичного дослідження є якісний аналіз суті процесів
та явищ у предметній області. На цьому етапі описуються типові сценарії, які
виникають у повсякденні: надходження доходу на основний рахунок, його
подальший розподіл між декількома «конвертами» (повсякденні витрати,
накопичення, резерв, погашення боргів), виникнення непередбачених витрат,
організація спільної поїздки чи оренди житла, де необхідно прозоро
розподілити сукупні витрати між учасниками. Результатом цього етапу стає
первинний перелік сутностей (користувач, рахунок, транзакція, категорія, група,
фінансова ціль, валюта, курс, повідомлення), а також інтуїтивне розуміння того,
які саме параметри є суттєвими для подальшої формалізації.
Наступним кроком є уточнення гіпотез дослідження на основі виявлених
сценаріїв. Вводяться додаткові уявлення: наприклад, що користувач схильний
сприймати свій фінансовий стан не лише через абсолютні суми, а й через
відносні показники (частка витрат на певну категорію, відсоток виконання
бюджету, темп наближення до фінансової цілі). Формується гіпотеза про те, що
система індикаторів та візуальних уявлень (графіки, прогрес-бари,
попередження) може змінювати фінансову поведінку в бік більшої дисципліни
та передбачуваності. Таким чином, теоретична модель починає охоплювати не
лише структуру даних, а й поведінковий вимір.
Після цього відбувається побудова моделі, у якій неформальні описи
замінюються формальними структурами. Формується концептуальна модель
предметної області, де чітко визначається склад сутностей, їхні атрибути та
типи зв’язків. Користувач пов’язується з набором рахунків, рахунок — з
множиною транзакцій, транзакція — з однією категорією, група — з кількома
користувачами та груповими транзакціями, які, у свою чергу, розкладаються на
частки учасників. Додається рівень валют: кожна сума зберігається у «рідній»
валюті, але може бути приведена до базової валюти профілю або групи. У цей
момент модель набуває вигляду цілісної схеми, яка задає, які зв’язки є
допустимими, а які — ні, які значення можуть набувати ті чи інші атрибути, які
34
ЧДТУ 252482.006 ПЗ
обмеження мають діяти (наприклад, сума часток у груповій транзакції повинна
дорівнювати загальній сумі витрати).
Наступний етап – перехід до математичного аспекта теоретичного
дослідження. Тут розробляються конкретні методи розрахунків, які будуть
використані в системі. Вони охоплюють формули для обчислення балансів
рахунків, сукупних доходів і витрат за період, відхилення фактичних витрат від
планових лімітів у бюджеті, прогресу накопичення на ціль, сальдо
взаєморозрахунків у групах. Додатково моделюється конвертація валют на
основі курсового коефіцієнта, який прив’язується до дати операції, що важливо
для коректного аналізу історичних даних. Теоретичне дослідження на цьому
етапі передбачає вибір таких алгоритмів, які, з одного боку, є достатньо
точними для відображення реальних фінансових процесів, а з іншого — не
перевантажують систему та зрозумілі користувачеві.
Значну роль відіграє й аналіз теоретичних рішень, коли побудована
модель перевіряється на предмет логічної цілісності. Умисно програються різні
сценарії: «ідеальний» місяць без перевищення бюджету, ситуація з раптовими
великими витратами, тривале накопичення на ціль з нерівномірними внесками,
участь кількох людей у спільних витратах з різними сумами внесків. Якщо у
всіх випадках модель дає результати, що не суперечать здоровому глузду та
очікуванням користувача, можна вважати, що на теоретичному рівні закладено
досить надійну основу. Якщо ж виявляються аномалії (наприклад, «зникнення»
частини сум або парадоксальні значення боргу), модель переглядається:
уточнюються визначення сутностей, переглядаються формули, коригується
логіка агрегування даних.
Узагальнюючи результати теоретичного аналізу, доцільно представити
етапи теоретичних досліджень у вигляді узгодженої послідовності, зіставленої з
конкретними завданнями нашої роботи. Це зручно зробити у табличній формі.
Проведені теоретичні дослідження дозволили сформувати формалізовану
модель управління особистими та груповими фінансами, яка поєднує облік
фінансових потоків, бюджетування, розподіл спільних витрат і мультивалютну
35
ЧДТУ 252482.006 ПЗ
підтримку. Отримані математичні залежності та алгоритмічні підходи є
основою для реалізації програмної логіки веб-застосунку та слугують
підґрунтям для подальших експериментальних досліджень.
На таблиці 2.1 показано експерементальні дослідженя та їх результати:
Таблиця 2.1
Етапи теоретичних досліджень та їх реалізація у дипломній роботі
Етап Зміст етапу в Реалізація в роботі над веб-
теоретичного загальнонауковому застосунком
дослідження розумінні
Аналіз суті Виявлення ключових Опис сценаріїв управління
процесів і явищ об’єктів, зв’язків, умов особистими й груповими
функціонування об’єкта, фінансами, виділення сутностей
опис типових ситуацій «користувач», «рахунок»,
«транзакція», «група», «ціль»
Формулювання Побудова припущень щодо Гіпотеза про зниження
гіпотез поведінки об’єкта і впливу хаотичності фінансової поведінки
запропонованого рішення на та конфліктів у групах завдяки
його стан інтегрованому застосунку
Побудова моделі Створення формалізованого Концептуальна модель предметної
опису об’єкта у вигляді області, формування словника
системи сутностей, зв’язків, термінів і структури
обмежень взаємозв’язків
Розроблення Визначення формул і Формули для балансів, бюджетів,
методів алгоритмів, що кількісно прогресу цілей, розподілу
розрахунків описують поведінку групових витрат, конвертації
системи валют
36
ЧДТУ 252482.006 ПЗ
Продовження таблиці 2.1
Аналіз рішень Перевірка моделі на «Програвання» сценаріїв
внутрішню узгодженість, використання застосунку,
Формулювання Узагальнення отриманих Фіксація складу сутностей,
теоретичних результатів, формування розрахункових модулів, обмежень
висновків системи правил і принципів і припущень, на яких ґрунтується
для подальших архітектура та структура БД
експериментів та
практичної реалізації
Важливо підкреслити, що навіть на теоретичному рівні дослідження
опирається на певний «експериментальний горизонт». Мова йде не про
повноцінний емпіричний експеримент, а про уявне відтворення серій дослідів у
моделі: послідовність операцій, зміну параметрів, реакцію системи на різні
вхідні дані. Теоретичні дослідження описують, як має поводитися
«ідеалізована» модель, тоді як наступні розділи роботи продемонструють,
наскільки близько практична реалізація веб-застосунку відповідає цим
очікуванням. Таким чином, підрозділ «Теоретичні дослідження» задає рамки
для всієї подальшої роботи: від проєктування бази даних і архітектури до
вибору тестових сценаріїв та інтерпретації результатів апробації системи.
2.1.1 Модель фінансових потоків користувача
Фінансову діяльність користувача доцільно розглядати як систему
грошових потоків, що змінюються в часі[11]. Нехай за дискретний період часу t
(день, тиждень, місяць) користувач здійснює n фінансових операцій. Кожну
операцію можна описати кортежем:
Qi =( аі, сі, dі, ki) (2.1)
де:
аі - сума операцій
37
ЧДТУ 252482.006 ПЗ
сі – категорія операції (харчування, транспорт, житло тощо)
dі – дата здійснення;
ki } – тип операції (дохід або витрата).
Сукупний баланс користувача за період T визначається як:
Де B0 – початковий баланс на початок періоду. Дана формула лежить в основі
розрахунку поточного фінансового стану користувача в застосунку.
2.1.2 Агрегація витрат та аналіз структури бюджету
Формалізація задачі структурної ідентифікації фінансової моделі
8
розроблена на основі сформованої методики . Задача ідентифікації – процес
визначення оператора F0 об’єкта (реального бюджету), тобто побудови такого
оператора моделі F0 (програмної системи), котрий був би максимально
близьким до оператора об’єкта F0.
Оскільки вигляд оператора F0 (реальної фінансової поведінки) практично
ніколи не відомий повністю, безпосередньо оцінити близькість згадуваних
операторів неможливо9. Тому природньо оцінювати близькість операторів по їх
реакціях на однакові вхідні стани X (транзакції), тобто по виходах об’єкта
(реальний баланс):
і моделі (баланс у застосунку):
Степінь близькості цих реакцій можна оцінити величиною квадрата
модуля різниці векторів виходу:
38
ЧДТУ 252482.006 ПЗ
На практиці близькість об’єкта і моделі оцінюється за допомогою функції
нев’язки q.
Постановка задачі. Необхідно побудувати такий оператор моделі F (веб-
застосунок), котрий би реагував на зміну вхідного стану X аналогічно реакції
об’єкта Y. Це досягається мінімізацією функціонала нев’язки для дискретних
подій (транзакцій):
де hi — ваговий коефіцієнт, що визначає важливість точності розрахунку
(наприклад, для валютних операцій він вищий).
Задача структурної ідентифікації полягає у визначенні структури
оператора F, тобто у розробці архітектури веб-застосунку, що мінімізує помилки
ручного введення.
2.1.3 Робота за даними
Створення облікового простору
Першим і найголовнішим етапом є створення середовища для обліку
(аналог створення БД). Існує два основні способи створення фінансового
простору.
Ручне створення файлу таблиці. Необхідно фізично створити файл,
розмітити колонки, налаштувати формули.
Реєстрація у веб-застосунку. Динамічне створення профілю та структури
бази даних в процесі роботи програми.
У разі використання веб-застосунку, програма динамічно створює
необхідні сутності (User, Account) за допомогою відповідних запитів. Для
таблиць доведеться вручну створювати структуру, що зазвичай не є ефективним
способом роботи, особливо якщо є потреба в спільному доступі. Важливо
39
ЧДТУ 252482.006 ПЗ
враховувати, що веб-застосунок надає переваги безпеки та готових
інструментів, вирішуючи проблеми, які в таблицях доводиться вирішувати
вручну.
Робота з транзакціями
Проаналізувавши існуючі методи, було прийнято рішення у проектуванні
та розробці програмного продукту оцінки швидкодії виконання фінансових
операцій[12]. Середовища мають бути наповнені ідентичною інформацією,
процес формування якої імітує реальні життєві сценарії (використання
Random() для сум, Date() для дат). Мають бути опрацьовані стандартні операції.
Виведення списку транзакцій (звіт).
Додавання транзакції (дохід/витрата).
Редагування транзакції (виправлення помилки).
Видалення транзакції.
Інформація має розподілятись за трьома варіантами кількості записів: 1
000, 5 000 та 10 000 записів для забезпечення різноманітності навантаження.
Робота з мультивалютністю та зовнішніми даними
Excel – потужний продукт, але імпорт актуальних курсів валют у ньому
часто ускладнений. Імпорт курсів стає ключовим елементом для
мультивалютного обліку. Основні способи отримання курсів у таблицях:
Ручне введення
Складні макроси
У веб-застосунку цей процес реалізовано через API інтеграцію.
Використання автоматизованого імпорту дозволяє швидко виконувати
розрахунки. Процес експорту звітів з веб-застосунку також може бути
реалізований через вбудовані інструменти (експорт у CSV/PDF) або SQL-запити
до бази даних. Цей процес забезпечує взаємодію з зовнішніми системами.
Формування аналітики та візуалізація
В контексті управління фінансами часто виникає необхідність у зручному
перегляді структури витрат. У таблицях це вимагає ручного налаштування
діаграм. У веб-застосунку формування аналітики (Dashboards) відбувається
40
ЧДТУ 252482.006 ПЗ
автоматично. Це робить процес управління інформацією більш зручним,
оскільки не вимагає глибоких знань інструментів візуалізації від користувача.
При роботі з таблицями часто потрібно використовувати додаткові
налаштування, що може призвести до збільшення часу на аналіз
2.1.4 Модель витрат та операцій з валютою
Для групи з m учасників спільні витрати розглядаються як множина
операцій G={g1,g2,...,gp}. Нехай витрата gj має загальну суму Aj та множину
учасників Uj.
У разі рівномірного розподілу частка одного учасника дорівнює:
Для нерівномірного розподілу вводяться вагові коефіцієнти wu, де:
Тоді індивідуальна частка витрати визначається як:
Сальдо користувача u у групі обчислюється як:
де Apaid – сума коштів, фактично сплачених користувачем. Додатне
сальдо означає, що інші учасники винні користувачу, від’ємне – користувач має
борг.
Для мінімізації кількості транзакцій при погашенні боргів
використовується модель балансового вирівнювання. Нехай множина учасників
поділяється на:
P – учасники з додатним сальдо;
N – учасники з від’ємним сальдо.
41
ЧДТУ 252482.006 ПЗ
Алгоритм зводиться до поетапного перенесення коштів від N до P до
виконання умови:
Такий підхід забезпечує зменшення кількості фінансових операцій і
підвищує прозорість розрахунків.
Для отримання узагальненої оцінки якості програмного продукту
використано інтегральний показник ефективності:
(2.2)
де:
Q — інтегральний показник якості;
Ki — оцінка і-го критерію;
wi — ваговий коефіцієнт критерію;
n — кількість критеріїв.
Вагові коефіцієнти визначались експертним методом, при цьому
виконувалась умова нормування:
Продуктивність системи оцінювалась за середнім часом обробки
фінансового запиту:
де:
Tj — час виконання j-го запиту;
m — кількість вимірювань.
Менше значення Tavg відповідає кращій продуктивності системи.
42
ЧДТУ 252482.006 ПЗ
Для перевірки коректності алгоритмів розподілу групових витрат
використано абсолютну похибку:
де:
Scalc — сума, розрахована програмою;
Sreal— фактична сума витрат.
При Δ→0 точність алгоритму вважається високою.
2.1.5 Гіпотеза
У розгляді архітектури фінансових інструментів виникає проблема вибору
оптимального механізму для зберігання та обробки інформації – використати
спеціалізований веб-застосунок з базою даних чи обмежитися універсальними
електронними таблицями.
Теорія. Рішення щодо вибору підходу залежить від обсягу даних та
складності зв'язків. У випадку об’ємних фінансових потоків (особливо
групових), швидкість обробки масивів інформації відіграє важливу роль. Тому
доцільно використовувати веб-застосунки з реляційними БД. Для простих задач
електронні таблиці можуть бути достатніми, але вони програють у швидкості
додавання та валідації даних.
Гіпотеза. В електронних таблицях інформація зберігається у комірках, що
вимагає ручного контролю формул. Веб-застосунок, використовуючи реляційну
модель, дозволяє автоматизувати зв'язки (рахунок-транзакція-категорія) та
валідацію. Я використовую саме підхід автоматизації. Таким чином, ми можемо
створити систему, яка за швидкістю та надійністю переважає табличний метод
при роботі з мультивалютними та груповими даними.
2.2 Експериментальні дослідження
Експериментальні дослідження в даній роботі спрямовані на перевірку
працездатності, точності розрахунків та ефективності використання
розробленого веб-застосунку для управління особистими та груповими
43
ЧДТУ 252482.006 ПЗ
фінансами в умовах, максимально наближених до реальних сценаріїв. Якщо
теоретичний розділ задає модель, структуру даних та алгоритми, то
експериментальний етап дає відповідь на запитання, як ця модель поводиться
на практиці, за різних навантажень, конфігурацій користувачів та варіантів
середовища.
У центрі експериментального дослідження перебуває дослідницька
програмна система, що реалізує розроблену концептуальну модель: серверна
частина на Node.js/Express з базою даних finance.db (SQLite або інша реляційна
СУБД), клієнтська частина на HTML/CSS/JavaScript з реактивним інтерфейсом
дашборду, модулем особистих фінансів, модулем групових розрахунків, блоком
бюджетів та цілей, а також підсистемою мультивалютних операцій із
використанням кешованих курсів валют[14]. Принцип дії системи ґрунтується
на тому, що всі події фінансового життя користувача (доходи, витрати, перекази,
групові витрати, внески на цілі) описуються уніфікованими транзакціями, які
зберігаються в БД, агрегуються на рівні рахунків, категорій, бюджетів, груп і
візуалізуються в інтерфейсі у вигляді таблиць, графіків та індикаторів.
Для експериментальних досліджень було побудовано набір тестових
сценаріїв, які імітують реальну поведінку користувачів протягом декількох
місяців. Застосовуються переважно імітаційні методи моделювання: замість
реальних банківських інтеграцій і випадкових життєвих подій використовується
генерація синтетичних транзакцій за заданими параметрами (частота витрат,
структура категорій, наявність групових витрат, мультивалютні операції), які
надалі обробляються системою. Це дозволяє відтворити різні профілі
користувачів (студент, сім’я з дітьми, фрилансер, невелика волонтерська група)
та оцінити, наскільки коректно й стабільно працює веб-застосунок за різних
умов.
Експериментальна програма включає кілька блоків. Перший блок
спрямований на оцінку інформаційної складової: повноти та несуперечливості
відображення фінансового стану користувача. Для цього здійснюється
порівняння «еталонних» підсумкових значень (балансів рахунків, сум по
44
ЧДТУ 252482.006 ПЗ
категоріях, виконання бюджету, прогресу до цілей), обчислених незалежно
(наприклад, у табличному процесорі), з результатами, які видає система. Другий
блок оцінює поведінку системи в різних середовищах та під впливом факторів
прямої та непрямої дії: кількість одночасних користувачів, обсяг бази (кількість
транзакцій), частота оновлення курсів валют, наявність або відсутність доступу
до зовнішнього API курсів. Третій блок присвячений аналізу ефективності
рішень, тобто того, наскільки використання веб-застосунку дозволяє
користувачеві швидше, точніше та прозоріше контролювати свої фінанси, ніж
при використанні розрізнених інструментів (нотатників, окремих банківських
застосунків, неструктурованих таблиць).
Для проведення експериментів було сформовано три основні набори
даних, які відрізняються за масштабом і складністю. Перший набір відображає
сценарій «одиночного користувача» з 2–3 рахунками і невеликою кількістю
транзакцій на місяць. Другий набір моделює «сімейний бюджет» із декількома
учасниками, розширеною структурою категорій, бюджетуванням на рівні
домогосподарства та регулярними спільними витратами. Третій набір імітує
роботу групи (волонтери або співмешканці), де значна частина операцій є
груповими, активно використовується модуль розподілу витрат, а також
мультивалютні операції. Узагальнені характеристики цих наборів подано в
таблиці 2.2.
Таблиця 2.2
Характеристики експериментальних наборів даних
Набір даних Кількість Кількість Кількість Частка Наявність
користувачів рахунків транзакцій групових мультивалютни
(за період) транзакцій х операцій
Набір A Обмежено
1 3 600 0 %
(особистий) (UAH/EUR)
45
ЧДТУ 252482.006 ПЗ
Продовження таблиці 2.2
Так
3 7 2400 15 % (UAH/EUR/USD
Набір B
)
(сімейний)
Набір C Так (UAH/EUR,
6 5 3600 45 %
(груповий) криптовалюти)
На першому етапі для кожного набору даних система запускалася в
режимі «контрольованого експерименту»: транзакції завантажувалися серіями,
а проміжні підсумки перевірялися методом описової статистики.
Обчислювалися сумарні доходи й витрати, середні місячні витрати за
категоріями, медіанні значення окремих типів платежів, мінімальні та
максимальні значення тощо. Це дозволило виявити, чи не спотворює система
розподіл транзакцій, чи немає систематичних зсувів у бік завищення або
заниження витрат і доходів[15]. Для контролю мультивалютного блоку
перевірялися емпіричні розподіли сум у різних валютах до та після конвертації
в базову валюту профілю, що демонструє коректність використання історичних
курсів.
Другий етап був орієнтований на оцінку продуктивності та стабільності
системи. Тут застосовувалися елементи імітаційного навантажувального
моделювання: генерувалися послідовності дій користувачів (автентифікація,
перегляд дашборду, додавання транзакцій, редагування бюджетів, створення та
закриття групових витрат), які відтворювалися з різною інтенсивністю.
Замірювався середній час відгуку основних операцій, 95-й перцентиль часу
завантаження дашборду, кількість одночасних сесій до появи відчутного
погіршення швидкодії, частота помилок при доступі до бази даних. Узагальнені
результати такого аналізу наведено в таблиці 2.3.
Таблиця 2.3
46
ЧДТУ 252482.006 ПЗ
Показники продуктивності веб-застосунку за результатами експериментів
Показник Набір A Набір B Набір C (груповий,
(особистий) (сімейний) навантажений)
Середній час завантаження
120 180 240
дашборду, мс
95-й перцентиль створення
90 140 210
транзакції, мс
Середній час розрахунку
– 75 130
групового боргу, мс
Максимальна кількість
одночасних сесій без 30 50 70
деградації (умовно)
Хоча наведені значення є результатом експериментальних запусків у
лабораторних умовах, вони дозволяють зробити висновок, що система зберігає
прийнятний час відгуку навіть за складних сценаріїв: розрахунок сальдо боргів
у групі з декількома десятками учасників та сотнями групових транзакцій не
призводить до помітних затримок для користувача. Це підтверджує коректність
обраних алгоритмів агрегування даних і структури індексів у базі даних.
Окремий блок експериментальних досліджень стосувався оцінювання
ефективності рішень, які приймають користувачі на основі інформації, що надає
система. Для цього проводилося порівняння двох режимів: ведення обліку у
традиційній формі (табличний процесор або окремі банківські застосунки без
інтегрованого дашборду) та використання розробленого веб-застосунку.
Аналізувалися такі показники, як час, необхідний для підготовки місячного
огляду витрат, кількість виявлених помилок у категоризації транзакцій,
кількість конфліктних ситуацій у групових розрахунках («хто кому скільки
винен»), суб’єктивна оцінка зрозумілості фінансової картини за шкалою від 1 до
47
ЧДТУ 252482.006 ПЗ
10. У результаті було зафіксовано, що застосування інтегрованого інструменту
дозволяє скоротити час підготовки огляду в середньому вдвічі, зменшити
кількість розбіжностей у групових витратах та підвищити суб’єктивне відчуття
контролю над фінансами.
З погляду методів аналізу даних, при обробці результатів експериментів
використовувалися елементи описової статистики (середні, медіани,
перцентилі, стандартні відхилення), побудова емпіричних розподілів за
ключовими показниками та елементарний кореляційний аналіз. Останній
дозволив, наприклад, оцінити залежність між кількістю активних рахунків і
середнім часом завантаження дашборду, а також між складністю групової
структури (кількість учасників, частка групових витрат) і частотою необхідних
перерахунків сальдо боргів. Виявлено, що при раціональному використанні
індексів у базі даних зростання цих параметрів призводить до помірного
збільшення часу відгуку, яке залишається в межах прийнятних значень.
Хоча повноцінні методи класифікації, кластеризації та інтелектуального
аналізу даних у межах дипломної роботи не реалізовувалися як окрема
підсистема, проведені експерименти демонструють потенціал подальшого
розвитку системи у цьому напрямі. Набрані дані про поведінку користувачів
(структура витрат, частота операцій, реакція на попередження про перевищення
бюджету) можуть у перспективі стати базою для побудови моделей сегментації
користувачів, виявлення «ризикових» фінансових патернів або формування
персоналізованих рекомендацій.
Експериментальні дослідження дозволили оцінити не лише технічні
характеристики веб-застосунку (продуктивність, стабільність, коректність
розрахунків), а й його інформаційну цінність для кінцевого користувача.
Використання імітаційного моделювання, описової статистики й елементарного
кореляційного аналізу показало, що розроблена система здатна адекватно
відображати фінансовий стан користувачів, залишаючись при цьому достатньо
легкою й швидкою в роботі. Одержані результати створюють підґрунтя для
48
ЧДТУ 252482.006 ПЗ
формулювання висновків до розділу та планування подальших напрямів
удосконалення програмної системи.
2.2.1 Опис програмних засобів дослідження
Для проведення експериментальних досліджень було обрано декілька
популярних програмних рішень, які використовуються для управління
особистими та груповими фінансами. Дані програмні продукти мають широку
аудиторію користувачів і реалізують різні підходи до обліку витрат, що дозволяє
виконати об’єктивне порівняння з розробленим web-застосунком.
Money Lover
Money Lover — це мобільний застосунок, призначений для ведення
обліку особистих фінансів. Основний акцент програми зроблено на
індивідуальному контролі доходів і витрат.
Основні можливості програми:
− ведення обліку доходів та витрат за категоріями;
− формування місячних і річних бюджетів;
− побудова графіків та фінансових звітів;
− підтримка декількох валют;
− експорт фінансових даних.
Недоліки:
− обмежена підтримка групових витрат;
− відсутність гнучкого механізму розподілу спільних витрат;
− більшість розширених функцій доступні лише у платній версії.
Таким чином, Money Lover є ефективним інструментом для
персонального фінансового контролю, однак малопридатний для управління
груповими фінансами.
Spendee
Spendee — це кросплатформений застосунок для управління бюджетом,
який поєднує функції персонального та спільного фінансового обліку.
Основні можливості програми:
− створення персональних і спільних гаманців;
49
ЧДТУ 252482.006 ПЗ
− автоматична синхронізація з банківськими рахунками;
− підтримка групових витрат;
− аналітичні звіти у вигляді діаграм;
− багатовалютний облік.
Недоліки:
− обмежена логіка розрахунку боргів між учасниками;
− складність інтерфейсу для нових користувачів;
− значна частина функціоналу доступна лише за підпискою.
Spendee забезпечує більш широкий функціонал у порівнянні з Money
Lover, однак має обмеження у точності та гнучкості розрахунку групових
витрат.
Splitwise
Splitwise — спеціалізований застосунок, орієнтований виключно на
розподіл групових витрат між кількома користувачами.
Основні можливості програми:
− створення груп для спільних витрат;
− автоматичний розрахунок боргів між учасниками;
− підтримка різних валют;
− мінімізація кількості транзакцій;
− синхронізація між учасниками групи.
Недоліки:
− відсутність повноцінного персонального бюджету;
− обмежені аналітичні можливості;
− слабка інтеграція з іншими фінансовими інструментами.
Splitwise є ефективним інструментом для короткострокових групових
витрат, однак не забезпечує комплексного управління особистими фінансами.
Розроблений web-застосунок для управління особистими та груповими
фінансами
Розроблений web-застосунок поєднує функціональні можливості
персонального та групового фінансового обліку в єдиній системі.
50
ЧДТУ 252482.006 ПЗ
Основні можливості розробленої системи:
− облік доходів і витрат користувачів;
− створення груп та управління спільними бюджетами;
− автоматичний розподіл групових витрат;
− підтримка мультивалютності;
− побудова аналітичних звітів і графіків;
− кросплатформений доступ через веб-браузер;
− зберігання даних у централізованій базі даних.
Переваги:
− комплексний підхід до управління фінансами;
− гнучкі алгоритми розрахунку боргів;
− відсутність залежності від мобільної платформи;
− можливість масштабування та подальшого розширення функціоналу.
Таким чином, розроблений web-застосунок усуває недоліки існуючих
програмних рішень та забезпечує більш універсальний підхід до управління
особистими і груповими фінансами.
2.2.2 Моделі та їх оцінювання
Для проведення експериментальних досліджень було визначено набір
критеріїв, які дозволяють комплексно оцінити функціональні можливості та
зручність використання програмних засобів.
Основні критерії оцінювання позначимо:
К1 – повнота функціоналу;
К2 – зручність користування (юзабіліт);
К3 – підтримка групових витрат;
К4 – аналітичні можливості;
К5 – продуктивність;
К6 –кросплатформеність.
Експерименти проводились за однакових умов:
– однаковий набір фінансових операцій;
– однакова кількість користувачів у групі;
51
ЧДТУ 252482.006 ПЗ
– однакова кількість валют;
– однакове навантаження на систему.
Було змодельовано такі сценарії:
– облік особистих витрат;
– створення групового бюджету;
– додавання спільних витрат;
– автоматичний розрахунок боргів;
– формування аналітичних звітів.
Результати експериментів показали, що розроблений web-застосунок:
– має вищий інтегральний показник якості;
– демонструє стабільну продуктивність;
– забезпечує коректний розподіл групових витрат;
– перевершує аналоги за аналітичними можливостями.
Таблиця 3.3
Оцінки програм після проведеня досліджень
Програмний засіб QQQ
Money Lover 6.8
Spendee 7.4
Splitwise 7.1
Розроблений web-застосунок 8.6
52
ЧДТУ 252482.006 ПЗ
Висновки до другого розділу
У другому розділі кваліфікаційної роботи було виконано аналіз,
проєктування та обґрунтування архітектурних і технологічних рішень для
розробки web-застосунку з управління особистими та груповими фінансами.
У ході розділу було досліджено предметну область фінансового обліку,
визначено основні типи фінансових операцій, а також сформульовано вимоги
до системи з урахуванням потреб кінцевих користувачів. Проведений аналіз
показав, що існуючі програмні рішення або орієнтовані виключно на
персональний облік витрат, або мають обмежені можливості для гнучкого
управління груповими фінансами, що підтверджує актуальність розробки
власного web-застосунку.
На основі аналізу вимог було розроблено структуру системи та її
архітектуру, що забезпечує масштабованість, модульність і можливість
подальшого розширення функціоналу. Обґрунтовано вибір клієнт-серверної
архітектури, яка дозволяє реалізувати багатокористувацький доступ,
централізоване зберігання даних та незалежність від конкретної платформи.
У розділі було спроєктовано логічну та фізичну модель бази даних, яка
забезпечує зберігання інформації про користувачів, фінансові операції, категорії
витрат, групи та валютні курси. Запропонована модель даних дозволяє
ефективно виконувати фінансові розрахунки, формувати аналітичні звіти та
забезпечувати цілісність даних.
Також було розглянуто алгоритми обліку доходів і витрат та розподілу
групових фінансових операцій, що є ключовим функціональним елементом
системи. Реалізація таких алгоритмів забезпечує коректний розрахунок балансів
і боргових зобов’язань між учасниками груп, що підвищує точність і зручність
користування застосунком.
У результаті виконання другого розділу було створено теоретичну та
проєктну основу для подальшої реалізації програмного продукту. Отримані
результати стали базою для розробки програмного забезпечення та проведення
53
ЧДТУ 252482.006 ПЗ
експериментальних досліджень, які наведені у наступних розділах
кваліфікаційної роботи.
54
ЧДТУ 252482.006 ПЗ
РОЗДІЛ 3. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
3.1 Моделювання предметної області
Моделювання предметної області для веб-застосунку управління
особистими та груповими фінансами є ключовим етапом, що забезпечує перехід
від опису реальних життєвих ситуацій до формалізованої структури даних і
взаємодій. На цьому етапі не просто перелічуються «гроші», «рахунки» чи
«витрати», а визначається, які саме сутності мають бути представлені в системі,
якими атрибутами вони володіють, як пов’язані між собою і як змінюються в
часі. Метою такого моделювання є побудова концептуальної моделі, яка
адекватно відображає фінансову діяльність користувачів і закладає основу для
логічної моделі бази даних, архітектури застосунку та реалізації бізнес-логіки.
Узагальнено предметну область можна описати як множину суб’єктів
(користувачів та груп користувачів), фінансових ресурсів (рахунків, коштів у
різних валютах), дій над ними (транзакцій доходів, витрат, переказів), планових
конструкцій (бюджетів, фінансових цілей) та допоміжних сутностей (категорій,
валютних курсів, повідомлень, звітів). Концептуальна модель перетворює цю
множину на структурований набір сутностей із чітко визначеними зв’язками
типу «один до одного», «один до багатьох» або «багато до багатьох». Саме
завдяки цьому стає можливим коректно реалізувати в системі типові сценарії
користувача: фіксацію доходів і витрат, ведення бюджету, контроль цілей,
розподіл групових витрат, аналіз структури витрат та динаміки фінансового
стану.
3.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області
55
ЧДТУ 252482.006 ПЗ
Предметна область моделювання охоплює процеси управління
особистими та груповими фінансами, що відбуваються в повсякденному житті
користувачів і підтримуються веб-застосунком. Йдеться про облік грошових
потоків, планування бюджету, накопичення резервів, досягнення фінансових
цілей, організацію спільних витрат у групах, а також про ухвалення рішень у
мультивалютному середовищі. Важливий момент полягає в тому, що система не
просто «записує цифри», а допомагає користувачеві структурувати фінансову
поведінку, бачити причинно-наслідкові зв’язки та виявляти тенденції.
У центрі концептуальної моделі предметної області перебуває сутність
«Користувач». Це базовий суб’єкт системи, який має обліковий запис,
авторизується, налаштовує профіль і створює інші об’єкти. Для кожного
користувача зберігаються ідентифікаційні дані, дані для автентифікації,
особисті налаштування (базова валюта, мова інтерфейсу, формат дат і часу), а
також зв’язки з фінансовими сутностями. Користувач пов’язаний відношенням
«один до багатьох» з рахунками, бюджетами, фінансовими цілями, категоріями
та відношенням «багато до багатьох» з групами, оскільки одна особа може бути
учасником кількох груп, а група – об’єднувати кількох учасників.
Сутність «Рахунок» описує окремий фінансовий носій коштів: банківську
картку, депозит, готівку, електронний гаманець чи інший ресурс. Рахунок має
унікальний ідентифікатор, назву, тип, валюту, початковий і поточний баланс,
статус. Один користувач може мати багато рахунків; кожен рахунок пов’язаний
із багатьма транзакціями. Рахунки можуть бути особистими або груповими, що
відображається у моделі через відповідні атрибути та зв’язки з користувачами і
групами.
Базовою одиницею фінансової інформації є «Транзакція», яка фіксує факт
здійснення конкретної фінансової дії в певний момент часу. Для транзакції
зберігаються ідентифікатор, тип (дохід, витрата, переказ), сума, валюта, дата й
56
ЧДТУ 252482.006 ПЗ
час, опис, посилання на рахунок, категорію, користувача, а також, за потреби,
групу. Додатково можуть фіксуватися атрибути повторюваності, джерело
інформації (ручне введення чи імпорт із зовнішнього сервісу), належність до
фінансової цілі.
Сутність «Категорія» слугує для тематичної класифікації транзакцій. Вона
об’єднує операції за напрямами використання коштів або джерелами
надходжень, що дає змогу будувати аналітику, формувати бюджети та виявляти
структуру витрат. Категорії можуть бути системними (заданими за
замовчуванням) та користувацькими (створеними самим користувачем), що
відображається в атрибутах.
Сутність «Бюджет» представляє планову складову управління фінансами.
У концептуальній моделі бюджет задає ліміти витрат та очікувані доходи на
визначений період у розрізі категорій. Він містить календарні межі, тип
(особистий чи груповий), а також набір рядків бюджету. Кожен рядок
пов’язаний з конкретною категорією та містить планову суму, фактичну суму
(обчислену на основі транзакцій) та відхилення.
Сутність «Фінансова ціль» описує довгострокові наміри користувача:
накопичення певної суми, формування «подушки безпеки», погашення боргу,
купівля великої речі. Ціль має назву, опис, цільову суму, вже накопичену суму,
дату початку, бажану дату досягнення, пріоритет. Вона пов’язується з
користувачем і, за потреби, з рахунками та бюджетами, через які здійснюється
фінансування.
Спільні фінанси моделюються через сутність «Група», яка об’єднує
користувачів для спільної фінансової активності (сім’я, орендарі квартири,
туристична компанія, волонтерська ініціатива). Група має назву, опис, статус,
дату створення та набір учасників. Зв’язок «Група – Користувач» реалізується
57
ЧДТУ 252482.006 ПЗ
через проміжну сутність «Учасник групи», що дозволяє фіксувати роль у групі
та права доступу.
Сутність «Групова транзакція» деталізує операції в межах групи. Окрім
стандартних параметрів, для неї важливо зберігати платника, перелік учасників,
між якими розподіляється сума, і правило такого розподілу. Для цього
використовується проміжна сутність «Частка учасника в груповій транзакції»,
де зберігаються частини загальної суми для кожного учасника.
Мультивалютність відображається через сутності «Валюта» та
«Валютний курс». Валюта має код, назву, символ, тип (національна, іноземна,
криптовалюта). Валютний курс описує співвідношення між двома валютами на
певну дату й необхідний для конвертації сум у базову валюту при формуванні
звітів та агрегованих показників.
До моделі входять також допоміжні сутності «Сповіщення» та «Звіт», які
структуровано описують відповідно події й агреговані подання даних.
Щоб уникнути неоднозначностей, формується словник предметної
області. У ньому даються узгоджені визначення базових термінів: «користувач»
як фізична особа з обліковим записом у системі; «особисті фінанси» як
сукупність доходів, витрат, активів і зобов’язань одного користувача; «групові
фінанси» як спільні грошові потоки кількох користувачів; «рахунок» як
логічний або реальний фінансовий інструмент; «транзакція» як одиничний
запис про операцію; «тип транзакції» як ознака її економічної природи;
«категорія» як класифікаційний параметр; «бюджет» як план доходів і витрат;
«рядок бюджету» як елемент бюджету; «фінансова ціль», «група», «учасник
групи», «групова транзакція», «частка учасника», «валюта», «базова валюта»,
«валютний курс», «звіт», «сповіщення» тощо. Такий словник працює як
«конституція» предметної області, до якої можна звернутися при розробці,
тестуванні та документуванні системи.
58
ЧДТУ 252482.006 ПЗ
3.1.2 Елементи моделювання предметної області
Елементи моделювання предметної області визначають, з яких
«будівельних блоків»(Рис. 3.1) складається концептуальна модель та як саме
вони взаємодіють. У контексті веб-застосунку для управління фінансами до цих
елементів належать сутності, атрибути, зв’язки(Рис. 3.2), обмеження цілісності,
а також типові сценарії використання, які «оживляють» статичну структуру.
Рис. 3.1 – Основні графічні символи UML
59
ЧДТУ 252482.006 ПЗ
Рис. 3.2 – Елементи обєднання UML
Сутності відображають ключові об’єкти реального світу, що мають
значення для користувачів і підлягають обліку в системі. Це користувачі,
рахунки, транзакції, категорії, бюджети, фінансові цілі, групи, учасники груп,
групові транзакції, частки у групових транзакціях, валюти, валютні курси,
сповіщення, звіти. Кожна сутність має набір атрибутів, які задають її стан: для
рахунку це назва, валюта, баланс; для транзакції – сума, тип, дата, опис; для
валюти – код, назва, символ; для бюджету – період, тип, набір рядків із
плановими та фактичними сумами.
Зв’язки між сутностями визначають логіку взаємодії об’єктів і дозволяють
моделювати реальні процеси. Наприклад, зв’язок між користувачем і рахунками
відображає, що один користувач може мати кілька рахунків; зв’язок між
60
ЧДТУ 252482.006 ПЗ
рахунком і транзакціями показує, що всі операції виконуються в контексті
конкретного рахунку; зв’язок між транзакцією та категорією дозволяє групувати
операції за змістом. Важливим є зв’язок між користувачами та групами через
проміжну сутність «учасник групи», а також між груповими транзакціями й
частками учасників, що реалізує механізм розподілу витрат. Для
мультивалютності принциповим є зв’язок між транзакціями та валютними
курсами, який, хоча й не завжди є прямим у моделі, але використовується
бізнес-логікою для конвертації сум.
Окреме значення мають обмеження цілісності, які задають припустимі
стани системи. Вони визначають, що транзакція не може існувати без
пов’язаного рахунку і категорії; що кожна групова транзакція повинна мати хоча
б одного учасника і правило розподілу; що валюта повинна бути задана одним
із допустимих кодів; що суми операцій не можуть бути від’ємними. Такі
обмеження задаються як на рівні концептуальної моделі (вербально), так і на
рівні логічної моделі бази даних (ключі, зовнішні ключі, перевірки, типи
даних).
До елементів моделювання належать також сценарії використання, які
служать «містком» між вимогами та структурою даних. Наприклад, сценарій
«користувач фіксує витрату» вимагає наявності сутностей «рахунок»,
«категорія», «транзакція» і відповідного набору атрибутів. Сценарій
«користувач створює групу для спільної оплати оренди» вимагає сутностей
«група», «учасник групи», «групова транзакція», «частка учасника». Такі
сценарії дозволяють перевірити повноту моделі: якщо для типового сценарію
бракує сутності, зв’язку чи атрибуту, модель потребує доповнення.
З технічного погляду, елементи моделювання відображаються у вигляді
UML- та ER-діаграм: діаграм класів, діаграм сутність–зв’язок, діаграм варіантів
використання, діаграм активностей чи послідовності. У цій роботі для цих
цілей застосовуються інструменти, сумісні з PlantUML, що дозволяє описувати
моделі у вигляді текстових специфікацій і автоматично генерувати візуальні
діаграми. Це спрощує супровід моделі та її актуалізацію при зміні вимог.
61
ЧДТУ 252482.006 ПЗ
3.1.3 Робоча область моделювання
Робоча область моделювання визначає межі системи, її контекст і ті
аспекти реального світу, які явно включаються або навмисно виключаються з
моделі. У випадку веб-застосунку для управління особистими та груповими
фінансами така область задається, по-перше, переліком процесів, які система
підтримує, а по-друге – описом зовнішніх систем та середовища, з якими вона
взаємодіє.
У межах цієї роботи робоча область охоплює операційний рівень
управління фінансами користувачів: облік доходів та витрат, планування та
контроль бюджету, моделювання фінансових цілей, організацію групових
фінансів, базову аналітику та мультивалютну підтримку. Сюди входять дії, які
людина виконує регулярно: запис зарплати, фіксація покупок, оплата
комунальних послуг, ведення спільного бюджету з партнером чи друзями,
відстеження накопичень. Натомість не включаються, наприклад, складні
інвестиційні стратегії, професійний трейдинг або податкове планування високої
складності – вони залишаються за межами робочої області й можуть
розглядатися як потенційний напрям розвитку системи.
Зовнішнє оточення системи становлять, передусім, банківські та платіжні
сервіси, сервіси валютних курсів та, за потреби, біржові або криптовалютні API.
У моделі передбачається, що веб-застосунок принаймні в перспективі може
отримувати дані про транзакції або курси валют із зовнішніх джерел, однак у
базовій реалізації взаємодія з такими джерелами може бути обмежена імпортом
курсів через відкриті API. Робоча область моделювання охоплює лише ті
аспекти інтеграції, які критично важливі для повсякденних сценаріїв
користувача, залишаючи поза моделлю специфічні протоколи банківської
взаємодії.
З позицій програмної інженерії робоча область моделювання задається
також вибором технологічного стеку, інструментів та артефактів. У роботі вона
включає використання UML-діаграм для опису структури та поведінки системи,
ER-моделей для проєктування бази даних, текстових специфікацій PlantUML
62
ЧДТУ 252482.006 ПЗ
для автоматизованої генерації діаграм, а також середовища розробки,
орієнтованого на веб-технології (JavaScript/Node.js, HTML/CSS, реляційна
СУБД). Таким чином, робоча область моделювання не лише визначає, що саме
моделюється, а й у яких інструментальних рамках це відбувається.
3.2 Формування та аналіз вимог
Формування та аналіз вимог є природним продовженням моделювання
предметної області. Після того як визначено, які сутності існують у системі і як
вони пов’язані, необхідно чітко сформулювати, що саме має робити програмне
забезпечення, за яких умов і з якими характеристиками якості. У цьому
контексті вимоги стають формалізованим описом очікуваної поведінки системи
з точки зору користувача, замовника та розробника.
Процес формування вимог у цій роботі ґрунтується на поєднанні аналізу
предметної області, вивчення існуючих програмних продуктів у сфері
персональних фінансів і синтезу типових життєвих сценаріїв. Вихідною точкою
стали проблеми користувачів, описані на етапі формалізації задачі:
розрізненість фінансових даних, відсутність інтегрованої картини, складність у
веденні спільних витрат, потреба в мультивалютній підтримці. На основі цих
проблем сформовано первинний список очікуваних можливостей системи, який
надалі уточнювався, структурувався й перевірявся на узгодженість з моделлю
предметної області.
Аналіз вимог відбувався через зіставлення первинних побажань
користувачів із технічними та ресурсними обмеженнями, а також з
архітектурними принципами майбутньої системи. Це дозволило відсіяти
надлишкові або надто спеціалізовані функції на користь ядра, яке є
максимально корисним для базового сценарію: облік особистих і групових
фінансів з базовою аналітикою. Для кожної групи вимог оцінювалися
доцільність, реалізованість і вплив на складність системи.
Результатом формування та аналізу вимог став набір функціональних і
нефункціональних вимог, який відображено в діаграмах варіантів використання
63
ЧДТУ 252482.006 ПЗ
UML. Ці діаграми фіксують основні сценарії: реєстрація транзакцій, перегляд
історії операцій, керування рахунками, створення бюджетів і цілей, формування
груп, внесення групових витрат і розрахунок боргів, перегляд аналітичних
звітів, використання інструментів конвертації валют та кредитних
калькуляторів. Одночасно визначено нефункціональні вимоги до інтерфейсу
(зрозумілість, мінімізація кроків у ключових сценаріях, адаптивність), до
продуктивності (прийнятний час відгуку при типових обсягах даних), до
надійності (коректність розрахунків, цілісність даних), а також до безпеки
(автентифікація, базові механізми захисту даних).
Таким чином, формування та аналіз вимог забезпечили перехід від
інтуїтивних очікувань користувачів до структурованого набору вимог, на який у
подальшому спираються моделювання архітектури, проєктування інтерфейсу та
реалізація програмного коду.
3.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги
Формування вимог до програмного забезпечення в межах цієї роботи
здійснювалося у кілька послідовних кроків, що дозволило перейти від
загальних побажань до формально визначених специфікацій. На першому етапі
було зібрано первинні вимоги – неструктуровані очікування потенційних
користувачів і замовника, сформульовані природною мовою. До них належали
побажання «бачити загальний баланс по всіх рахунках», «розуміти, куди йдуть
гроші», «просто ділити витрати в компанії друзів», «мати можливість
працювати з різними валютами», «відстежувати прогрес за фінансовими
цілями». Такі первинні вимоги відображають інтуїтивне бачення системи з
боку замовника та користувача, але не є достатньо точними для безпосередньої
реалізації.
На наступному етапі первинні вимоги були деталізовані й перетворені на
детальні вимоги до функцій, інтерфейсу, даних та характеристик якості.
Деталізація передбачала уточнення умов виконання кожної функції, необхідних
64
ЧДТУ 252482.006 ПЗ
даних, очікуваних результатів, а також обмежень. Наприклад, вимога «вести
облік витрат» трансформувалася в детальний опис: які атрибути має мати
транзакція, як вона пов’язується з рахунком і категорією, як відображається в
інтерфейсі, у яких звітах використовується. Аналогічно, вимога «ділити групові
витрати» була розгорнута в опис механізму створення груп, додавання
учасників, задання правил розподілу, розрахунку боргів і відображення їх у
звітах.
У процесі формування вимог розрізнялися вимоги замовника і вимоги
розробника.
Вимоги замовника фіксували кінцевий результат з точки зору цінності
для користувача: зручний облік, прозорі розрахунки, зрозумілу аналітику.
Вимоги розробника уточнювали внутрішні аспекти системи, необхідні
для реалізації цих очікувань: вибір архітектурного підходу, структуру бази
даних, правила валідації даних, рішення щодо кешування або обробки помилок.
У тексті роботи ці два рівні вимог розглядаються як взаємодоповнювальні:
перший забезпечує орієнтацію на користувача, другий – технічну
життєздатність та підтримуваність системи.
Змістовно вимоги були поділені на функціональні та нефункціональні.
Функціональні вимоги описують, які саме дії має виконувати веб-застосунок:
реєструвати доходи та витрати, дозволяти створювати і редагувати рахунки,
категорії, бюджети, цілі та групи; підтримувати внесення групових транзакцій і
розподіл витрат; будувати звіти за періодами, категоріями, рахунками; надавати
інструменти конвертації валют і базові фінансові калькулятори. Ці вимоги
безпосередньо відображені в діаграмах варіантів використання UML і
становлять основу для проєктування класів і REST-інтерфейсів.
Нефункціональні вимоги стосуються характеристик системи, що не
описують конкретні функції, але визначають якість їх виконання. Для даного
веб-застосунку до ключових нефункціональних вимог належать зручність
використання (інтуїтивний інтерфейс, логічна структура сторінок, мінімальна
кількість кроків у типових сценаріях), продуктивність (швидке завантаження
65
ЧДТУ 252482.006 ПЗ
сторінок, прийнятний час відповіді при додаванні й перегляді транзакцій),
надійність (відсутність втрати даних, коректність розрахунків, обробка
помилкових введень), безпека (захист облікового запису, коректне зберігання
конфіденційної інформації), розширюваність (можливість подальшого
додавання модулів, наприклад, глибшої інтеграції з банками або розширених
звітів).
Сукупність первинних і детальних, функціональних і нефункціональних
вимог, сформованих як з позицій замовника, так і з позицій розробника,
створює повноцінну специфікацію, на яку спирається подальше проєктування
логічної та фізичної архітектури веб-застосунку, а також реалізація й тестування
програмного забезпечення.
3.2.2 Формування вимог за допомогою діаграми прецедентів
З погляду продуктивності доцільно встановити орієнтовні цільові
показники: час відгуку основних операцій (перегляд списку транзакцій,
додавання нової операції, побудова базового звіту) має залишатися в межах
кількох секунд навіть при значному обсязі даних для одного користувача;
система повинна масштабуватися для підтримки зростання кількості
користувачів. Вимоги зручності використання та ергономіки включають просту
й логічну навігацію, зрозумілі форми введення даних, використання візуальних
елементів для відображення ключових показників (графіки, діаграми, прогрес-
бар для цілей), адаптацію інтерфейсу до різних розмірів екранів. Важливо також
передбачити розширюваність: архітектура має дозволяти додавання нових видів
звітів, калькуляторів, інтеграцій із банківськими API без повної переробки ядра
системи.
Для структуризації функціональних вимог і перевірки їх повноти
використовується апарат діаграм варіантів використання (Рис. 3.3 )(use-case
діаграм). Такі діаграми дозволяють представити систему з точки зору зовнішніх
акторів (користувачів, адміністраторів, сторонніх сервісів) та їхніх взаємодій із
основними функціями системи. Вони не деталізують внутрішню реалізацію, але
66
ЧДТУ 252482.006 ПЗ
дуже добре показують, які саме сценарії підтримуються й як вони групуються
між собою.
Рис. 3.3 – UML-діаграма варіантів використання
З погляду продуктивності доцільно встановити орієнтовні цільові
показники: час відгуку основних операцій (перегляд списку транзакцій,
додавання нової операції, побудова базового звіту) має залишатися в межах
кількох секунд навіть при значному обсязі даних для одного користувача;
67
ЧДТУ 252482.006 ПЗ
система повинна масштабуватися для підтримки зростання кількості
користувачів. Вимоги зручності використання та ергономіки включають просту
й логічну навігацію, зрозумілі форми введення даних, використання візуальних
елементів для відображення ключових показників (графіки, діаграми, прогрес-
бар для цілей), адаптацію інтерфейсу до різних розмірів екранів. Важливо також
передбачити розширюваність: архітектура має дозволяти додавання нових видів
звітів, калькуляторів, інтеграцій із банківськими API без повної переробки ядра
системи.
Для структуризації функціональних вимог і перевірки їх повноти
використовується апарат діаграм варіантів використання (use-case діаграм). Такі
діаграми дозволяють представити систему з точки зору зовнішніх акторів
(користувачів, адміністраторів, сторонніх сервісів) та їхніх взаємодій із
основними функціями системи. Вони не деталізують внутрішню реалізацію, але
дуже добре показують, які саме сценарії підтримуються й як вони групуються
між собою.
За цією діаграмою можна побачити логічні кластери функціональних
вимог: блок особистих фінансів, блок групових фінансів, блок
мультивалютності й калькуляторів, а також блок сервісних і адміністраторських
функцій. Кожен варіант використання відповідає одному або кільком
функціональним вимогам. Наприклад, use-case «Облік доходів і витрат»
охоплює вимоги до створення, редагування, видалення транзакцій, їх
категоризації, пошуку й фільтрації; «Планування та контроль бюджету» — до
формування бюджетних періодів, задання лімітів, відстеження фактичних
витрат та сигналізації про перевищення.
Ця діаграма підкреслює, що підтримка групових фінансів у системі — не
«додаткова опція», а повноцінна підсистема, яка має власні сценарії та
пов’язана з предметною областю не менш тісно, ніж особисте бюджетування.
Узагальнюючи, формування функціональних і нефункціональних вимог у
поєднанні з побудовою use-case діаграм дозволяє:
68
ЧДТУ 252482.006 ПЗ
– перевірити, що всі ключові сценарії роботи користувачів (особисті й
групові) враховані;
– виявити залежності між вимогами (наприклад, групові витрати
неможливі без створення групи й групових рахунків);
– співвіднести вимоги якості (безпека, продуктивність, зручність) із
найкритичнішими сценаріями;
– створити наочний місток між текстовим описом вимог і подальшим
архітектурно-технологічним проєктуванням.
Якщо захочеш, далі можу розписати опис кожного use-case у вигляді
шаблону (Actors, Preconditions, Main flow, Alternative flows, Postconditions) або
побудувати діаграми послідовностей для найважливіших сценаріїв —
наприклад, «Облік групової витрати» чи «Конвертація валюти з використанням
зовнішнього API»
3.2.3 Проектування логічної структури програмного комплексу
Проектування логічної структури програмного комплексу є одним із
ключових етапів розроблення програмного забезпечення, після чого
відбувається внутрішня організація системи, взаємодія її компонентів та
розподіл функціональності між ними. Логічна структура описує програмний
комплекс на концептуальному рівні без прив’язки до реалізації конкретних
технологій, що забезпечує гнучкість, масштабованість та зручність подальшої
підтримки системи.
Загальна характеристика логічної структури
Програмний комплекс спроєктовано за модульним принципом, що
відповідає сучасним підходам інженерії програмного забезпечення. Система
поділяється на логічно незалежні модулі, кожен з яких відповідає для виконання
окремої групи функцій. Такий підхід дозволяє зменшити зв’язок між
компонентами та підвищити повторне використання коду.
Логічна структура програмного комплексу базується на багаторівневій
архітектурі та включає такі основні рівні:
− рівень представлення (Presentation Layer);
69
ЧДТУ 252482.006 ПЗ
− рівень прикладної логіки (Business Logic Layer);
− рівень доступу до даних (Data Access Layer).
Рівень представлення
Рівень представлення відповідає взаємодію користувачів із програмним
комплексом. Він забезпечує введення даних, відображення результатів обробки
та навігацію між функціональними можливостями систем. На логічному рівні
цей модуль реалізує сценарії використання системи, описані на діаграмі
варіантів використання UML.
Основними функціями рівня представлення є:
− прийом вхідних даних від користувача;
− первинна перевірка коректності введених даних;
− передача запитів до рівня прикладної логіки;
− відображення результатів обробки в зручному для користувача
вигляді.
Рівень прикладної логіки
Рівень прикладної логіки є ядром програмного комплексу та реалізує
основні алгоритми обробки даних і прийняття рішень. Саме на цьому рівні
виконується виконання бізнес-правил, обчислення та синтез моделей відповідно
до поставлених завдань.
До функцій цього рівня належать:
− обробка вхідних даних згідно з алгоритмами системи;
− керування сценаріями роботи програмного комплексу;
− взаємодія з рівним доступом до даних;
− формування результатів для подальшої передачі на рівень
представлення.
Рівень прикладної логіки складається з окремих сервісів і менеджерів,
кожен з яких відповідає певній предметній області або функціональному блоку
системи.
Рівень доступу до даних
70
ЧДТУ 252482.006 ПЗ
Рівень доступу до даних забезпечення збереження, оновлення та
отримання інформації з джерел даних. На логічному рівні цей компонент
абстрагує роботу з базою даних або файлами, приховуючи деталі реалізації від
інших частин системи.
Основні завдання рівня доступу до даних:
− виконання операцій читання та запису даних;
− забезпечення цільності та узгодженості інформації;
− забезпечення уніфікованого інтерфейсу доступу до даних для рівня
прикладної логіки.
Взаємодія компонентів
Взаємодія між логічними рівнями програмного комплексу створена через
чітко визначені інтерфейси. Рівень представлення не має прямого доступу до
даних і взаємодіє з ними за допомогою рівня прикладної логіки. Такий підхід
відповідає принципам SOLID та підвищує надійність і розширюваність
програмного комплексу.
3.2.3.1 Діаграми класів
У логічній архітектурі центральне місце займає доменний шар, який
реалізує моделі, описані в розділі 2.2: користувачі, рахунки, транзакції,
категорії, бюджети, фінансові цілі, групи, групові транзакції, валюти, курси
валют, сповіщення. Навколо доменних класів будуються сервіси застосунку
(application services), що реалізують окремі use-case: реєстрація користувача,
створення транзакції, розрахунок бюджету, формування звіту, облік групових
витрат тощо.
На рівні логічної архітектури ці доменні класи не прив’язані до
конкретної СУБД чи фреймворку. З ними працюють сервіси прикладного рівня
(наприклад, FinanceService, GroupFinanceService, BudgetService,
ReportingService), які інкапсулюють бізнес-правила: перевірку коректності сум,
обмежень бюджету, правил поділу групових витрат, обчислення сальдо боргів,
конвертацію валют тощо. Під ними розташований шар репозиторіїв
71
ЧДТУ 252482.006 ПЗ
(UserRepository, AccountRepository, TransactionRepository тощо), які вже
оперують конкретними таблицями бази даних.
Рис. 3.4 – «Діаграма класів»
Рис. 3.5 – «Діаграма класів системи управління особистими та груповими
фінансами»
72
ЧДТУ 252482.006 ПЗ
3.2.3.2 Діаграми пакетів
Діаграма пакетів для веб-застосунку управління особистими та груповими
фінансами відображає логічне групування класів та модулів за шарами
архітектури. Такий поділ дозволяє чітко відокремити відповідальність між
рівнем користувацького інтерфейсу, прикладною логікою, предметною моделлю
та інфраструктурою доступу до даних і зовнішніх сервісів.
Рис3.5 – Діграма пакетів
У запропонованому рішенні виділяються принаймні чотири основні
пакети: пакет ui, де зосереджено сторінки та компоненти інтерфейсу
користувача (дашборд, екрани рахунків, групових фінансів, налаштувань); пакет
application, що містить контролери веб-API та сервіси прикладної логіки
(аутентифікація, управління рахунками, транзакціями, групами, звітністю);
пакет domain, у якому визначені предметні сутності, їх атрибути та базова
бізнес-логіка (користувач, рахунок, транзакція, категорія, бюджет, фінансова
ціль, група); пакет infrastructure, відповідальний за реалізацію репозиторіїв,
контекст доступу до бази даних, клієнти до API валютних курсів та
73
ЧДТУ 252482.006 ПЗ
криптовалют, а також за конфігураційні налаштування. Стрілки залежностей у
діаграмі показують, що інтерфейс залежить від прикладного шару, прикладний
шар спирається на предметну модель та інфраструктуру, а доменна модель має
мінімальні залежності й може повторно використовуватися. Така структура
спрощує супровід і розширення системи, оскільки зміни на одному рівні
(наприклад, заміна джерела валютних курсів) майже не впливають на код
користувацького інтерфейсу або доменної логіки.
3.2.4 Архітектурне проектування
Архітектурне проектування є ключовим етапом життєвого циклу
програмного забезпечення та створення структури системи, взаємодію її
компонентів, принципи розподілу відповідностей і способи масштабування. У
межах даної магістерської роботи архітектурна веб-застосунок для управління
особистими та груповими фінансами розробляється з урахуванням принципів
інженерії програмного забезпечення, зокрема модульності, масштабованості,
підтримки та безпеки.
Проектування архітектури розроблено на основі аналізу вимог,
сформульованих у попередніх розділах, а також результатів теоретичних та
експериментальних досліджень. Основною метою архітектурного проектування
є створення гнучкої та розширеної структури системи, яка забезпечує коректну
обробку фінансових даних, зручність взаємодії користувачів і можливість
подальшого розвитку програмного продукту.
Для реалізації веб-застосунку обрано багаторівневий архітектурний стиль,
який базується на розділених системах на логічних рівнях: рівень
представлення, рівень бізнес-логіки та рівень доступу до даних. Такий підхід
відповідає загальноприйнятим практикам розробки веб-систем та забезпечує
чіткий розподіл відповідностей між компонентами.
У рамках цього стилю використовується архітектурний шаблон MVC
(Model–View–Controller), який дозволяє ізолювати модель даних від
використовуваного інтерфейсу та логіки керування. Це забезпечує надійність
коду, сприяє тестуванню та зменшує зв’язність між компонентами системи.
74
ЧДТУ 252482.006 ПЗ
3.2.4.1 Діаграма компонентів
Компонентна архітектура описує, як логічні частини системи групуються
в більші програмні блоки і через які інтерфейси вони взаємодіють. З
урахуванням специфіки веб-застосунку доцільно виділити такі основні
компоненти:
– Web UI (Frontend) – односторінковий веб-інтерфейс
(HTML/CSS/JavaScript), що реалізує всі сценарії взаємодії
користувача: введення даних, перегляд звітів, роботу з групами.
– API Gateway / Backend Application – серверний застосунок (наприклад,
Node.js/Express або Java/Spring Boot), що надає REST-інтерфейс для
фронтенду, реалізує прикладну логіку та авторизацію.
– Auth & User Management – підсистема реєстрації, автентифікації та
керування профілями користувачів.
– Finance Core – ядро доменної логіки для особистих фінансів (рахунки,
транзакції, категорії, бюджети, цілі).
– Group Finance Module – модуль роботи з групами, груповими
рахунками, витратами та боргами.
– Reporting & Analytics – компонент для побудови звітів, графіків,
розрахунку агрегованих показників.
– Integration Services – компонент, що відповідає за інтеграцію із
зовнішніми сервісами курсів валют та, за потреби, криптовалют.
– Notification Service – сервіс генерації та доставки сповіщень
(внутрішніх та, за можливості, e-mail).
– Data Access Layer – компонент, що інкапсулює роботу з базою даних
(ORM, SQL-запити).
– Relational Database – СУБД (наприклад, PostgreSQL або MySQL), де
фізично зберігаються всі дані.
Компонентну діаграму (спрощену) можна подати так:
75
ЧДТУ 252482.006 ПЗ
Рис. 3.6 – «Діаграма компонентів»
У такій структурі Web UI взагалі не знає про внутрішній поділ бекенду на
модулі й спілкується з ним через набір REST-ендпойнтів. API-шар виконує роль
фасаду, який приймає запити від клієнтського застосунку, проводить базову
валідацію та маршрутизацію до відповідних доменних сервісів. Data Access
Layer слугує єдиною точкою доступу до бази даних, що полегшує зміну СУБД
або оптимізацію запитів. Integration Services ізолюють роботу із зовнішніми
API, завдяки чому потенційна заміна провайдера курсів валют не вимагає змін у
доменній логіці.
Фізична (або технічна) архітектура описує, на яких реальних або
віртуальних вузлах буде розгорнута система, як ці вузли взаємодіють між
собою, які мережеві з’єднання використовуються, де розміщені дані й які
існують «межі довіри» (trust boundaries). Для розроблюваного веб-застосунку
доцільно застосувати класичну трирівневу схему розгортання у хмарному або
орендованому середовищі:
– клієнтський рівень – браузер користувача (настільний ПК чи
мобільний пристрій), який завантажує статичні ресурси фронтенду та
надсилає HTTP(S)-запити до сервера.
– прикладний рівень – веб-сервер / application server, де розгорнутий
бекенд (Node.js/Java/.NET), який обробляє запити, виконує бізнес-
логіку, взаємодіє з базою даних та зовнішніми сервісами.
– рівень даних – окремий сервер або інстанс СУБД (PostgreSQL), що
76
ЧДТУ 252482.006 ПЗ
знаходиться у внутрішній мережі й доступний лише із застосунку.
На практиці фронтенд може бути розгорнутий як набір статичних файлів
(HTML, CSS, JS) на тому ж сервері, що й бекенд, або на окремому
CDN/об’єктному сховищі, але для дипломної роботи достатньо базового
варіанту «все на одному веб-сервері + окремий сервер БД».
У цій конфігурації браузер користувача встановлює захищене HTTPS-
з’єднання з веб-сервером, який роздає статичні файли фронтенду та обробляє
API-запити. Сервер застосунку комунікує з сервером бази даних по
внутрішньому мережевому інтерфейсу, недоступному іззовні. Зовнішні
інтеграційні сервіси (курси валют, поштовий сервіс) знаходяться за межами
інфраструктури застосунку, доступ до них здійснюється через Інтернет. При
масштабуванні можна збільшити кількість екземплярів сервера застосунку,
розмістити їх за балансувальником навантаження та, за потреби, винести базу
даних на керовану хмарну платформу.
3.2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Діаграма розгортання програмної системи (рис. 3.X) відображає фізичну
структуру середовища, у якому функціонує веб-застосунок для управління
особистими та груповими фінансами, а також основні вузли й мережеві
взаємозв’язки між ними. На відміну від логічних діаграм класів та компонентів,
діаграма розгортання концентрується не на внутрішній структурі коду, а на
тому, де саме розміщуються артефакти системи та як вони взаємодіють у
реальній інфраструктурі.
У верхній частині діаграми виділено клієнтський вузол, який представляє
собою персональний комп’ютер, ноутбук або смартфон кінцевого користувача з
встановленим сучасним веб-браузером. Саме в браузері виконується клієнтська
частина системи – HTML-, CSS- та JavaScript-ресурси, що формують інтерфейс
користувача. Браузер не містить бізнес-логіки з обробки даних, а виступає
тонким клієнтом, який відправляє HTTP(S)-запити до серверної частини і
відображає отримані результати у вигляді таблиць, діаграм, форм і панелей
77
ЧДТУ 252482.006 ПЗ
керування.
Наступний рівень займає веб-сервер, на якому розміщені статичні файли
інтерфейсу (Web UI). Цей вузол може бути реалізований, наприклад, на базі
Nginx або Apache і виконує одразу кілька функцій. По-перше, він ефективно
роздає статичні ресурси (HTML, CSS, JS) завдяки вбудованим механізмам
кешування й оптимізації. По-друге, веб-сервер може виконувати роль
зворотного проксі, приймаючи вхідні HTTPS-запити від клієнтських пристроїв і
перенаправляючи їх до вузла прикладного сервера на внутрішніх мережевих
портах. Такий підхід дозволяє відокремити зовнішній периметр від бізнес-
логіки й спростити конфігурацію безпеки.
Центральне місце в архітектурі займає сервер застосунку, на якому
розгорнуто API-сервер, реалізований на платформі Node.js. Саме тут
зосереджена основна бізнес-логіка: обробка запитів на реєстрацію та
авторизацію користувачів, робота з рахунками та транзакціями, формування й
оновлення бюджетів та фінансових цілей, облік групових фінансів і розрахунок
боргів між учасниками групи, побудова агрегованих звітів. API-сервер приймає
HTTP(S)-запити від веб-сервера у форматі REST і повертає відповіді у вигляді
JSON, що забезпечує простоту інтеграції з різними типами клієнтів, включно з
мобільними.
Окремий вузол на діаграмі представляє сервер бази даних, де розгорнута
реляційна СУБД PostgreSQL. У ній зберігаються всі ключові сутності
предметної області: дані про користувачів, рахунки, транзакції, групи, бюджети,
фінансові цілі, валюти та історія валютних курсів. Сервер застосунку взаємодіє
з базою даних по захищеному мережевому з’єднанню, використовуючи
стандартний порт СУБД. Така ізоляція дає змогу розмістити базу даних у
внутрішньому сегменті мережі, недоступному безпосередньо ззовні, та
посилює загальний рівень безпеки.
На діаграмі також відображено зовнішній вузол – хмарний сервіс
постачальника валютних та криптовалютних курсів. Сервер застосунку
періодично звертається до цього сервісу через захищене HTTPS-з’єднання,
78
ЧДТУ 252482.006 ПЗ
отримуючи актуальні курси валют і криптовалют у форматі REST-API.
Отримані дані зберігаються у власній базі даних і використовуються для
конвертації сум у базову валюту користувача, формування звітів та роботи в
мультивалютному режимі. Завдяки адаптеру валютних курсів зовнішній сервіс
залишається логічно відокремленим: у разі потреби його можна замінити іншим
провайдером без суттєвої переробки внутрішньої логіки застосунку.
Рис. 3.7 – Діаграма розгортання
79
ЧДТУ 252482.006 ПЗ
Запропонована схема розгортання забезпечує чітке розділення
відповідальностей між шарами, а також створює передумови для
масштабування. Веб-сервер та сервер застосунку можуть бути дубльовані за
балансувальником навантаження, що дозволяє обробляти більшу кількість
одночасних користувачів.
База даних може бути розгорнута з механізмами реплікації й резервного
копіювання для підвищення відмовостійкості. При цьому клієнтський пристрій
потребує лише сучасного браузера, а вся складність інфраструктури прихована
від користувача, забезпечуючи йому простий, але надійний доступ до
функціоналу веб-застосунку незалежно від типу пристрою та
місцезнаходження.
3.2.5 Моделювання поведінки системи
Моделювання поведінки програмної системи є першим етапом інженерії
програмного забезпечення, що дозволяє формалізувати логіку взаємодії між
компонентами системи, користувачами та зовнішніми службами. У межах даної
магістерської роботи моделювання поведінки веб-застосунку для управління
особистими та груповими фінансами спрямоване на опис динамічних процесів
обробки фінансових даних, керування користувацькими сесіями та виконання
бізнес-операцій.
Основними завданнями моделювання поведінки системи є:
– опис сценаріїв взаємодії користувача з системою;
– формалізація послідовності виконання фінансових операцій;
– визначення станів системи та переходів між ними;
– аналіз коректності та повноти бізнес-логіки.
Для детального аналізу динаміки виконуються окремі бізнес-процеси
комп’ютерної діаграми симптомів. Вони відображають порядок обміну
повідомленнями між клієнтською частиною, сервером та базою даних.
Прикладом ключового сценарію є додавання фінансової операції
користувачем. Процес включає в себе ініціацію запиту з боку клієнта, перевірку
80
ЧДТУ 252482.006 ПЗ
збереження даних на сервері, інформацію в базах даних і повернення результату
клієнту.
Діаграми діяльності розроблені для опису алгоритмів виконання складних
бізнес-процесів. Вони можуть візуалізувати логіку прийняття рішень,
паралельні дії та послідовність виконання операцій.
У межах даної роботи діаграма діяльності виконується для моделювання
процесу розподілу групових витрат. Процес включає введення даних,
визначення учасників, розрахунок часток та оновлення балансу кожного
учасника.
3.2.5.1 Діаграма діяльності
У контексті розроблюваного веб-застосунку особливий інтерес становлять
три типи поведінкових моделей. Діаграми діяльності дозволяють формально
описати бізнес-процеси, такі як додавання нової транзакції і оновлення
пов’язаних із нею бюджетів та фінансових цілей. Діаграми послідовності
фіксують покроковий обмін повідомленнями між актором, веб-інтерфейсом,
серверними компонентами та базою даних під час виконання окремого
сценарію, наприклад, обліку групової витрати та розрахунку часток учасників.
Діаграми станів описують, як змінюється внутрішній стан окремої сутності,
зокрема фінансової цілі, протягом її життєвого циклу в системі.
Процес додавання нової особистої транзакції в системі складається з
кількох логічних етапів. Користувач відкриває форму введення даних, задає
рахунок, суму, тип операції, категорію та дату, після чого система перевіряє
валідність введеної інформації. Якщо дані коректні, транзакція зберігається в
базі, оновлюється баланс рахунку, перераховуються показники відповідного
бюджету за період, а також, за потреби, прогрес певних фінансових цілей. У
випадку помилки користувачу повертається повідомлення про некоректність
даних, і процес повертається до етапу введення.
Ця діаграма демонструє, що навіть проста на вигляд дія «додати
транзакцію» спричиняє каскад змін у різних частинах доменної моделі:
рахунках, бюджетах, фінансових цілях. Такий опис допомагає виявити всі
81
ЧДТУ 252482.006 ПЗ
місця, де необхідно забезпечити цілісність даних і правильне оновлення
пов’язаних об’єктів.
Рис. 3.8 – Діаграма діяльності: додавання особистої транзакції та
оновлення бюджету
82
ЧДТУ 252482.006 ПЗ
Сценарій обліку групової витрати є більш комплексним з точки зору
взаємодії між компонентами. Коли один із учасників групи фіксує спільну
витрату, веб-застосунок має отримати дані від користувача, передати їх на
сервер, створити групову транзакцію, розрахувати частки для кожного учасника
відповідно до обраного правила поділу, оновити записи в базі даних та
повернути оновлену інформацію для відображення сальдо боргів. У цьому
процесі задіяні актор користувач, клієнтський веб-інтерфейс, серверний API,
доменний сервіс роботи з груповими фінансами та база даних.
3.2.5.2 Діаграма послідовності
Сценарій обліку групової витрати є більш комплексним з точки зору
взаємодії між компонентами. Коли один із учасників групи фіксує спільну
витрату, веб-застосунок має отримати дані від користувача, передати їх на
сервер, створити групову транзакцію, розрахувати частки для кожного учасника
відповідно до обраного правила поділу, оновити записи в базі даних та
повернути оновлену інформацію для відображення сальдо боргів. У цьому
процесі задіяні актор користувач, клієнтський веб-інтерфейс, серверний API,
доменний сервіс роботи з груповими фінансами та база даних.
Ця діаграма наочно демонструє окремі етапи виконання сценарію:
введення даних користувачем, валідація та обробка на сервері, створення
групової транзакції та записів про частки, перерахунок сальдо боргів,
повернення результату у веб-інтерфейс. Вона підкреслює чіткий розподіл
відповідальності між клієнтом, API-шаром, доменним сервісом та базою даних,
а також слугує основою для подальшого деталізованого проектування
реалізації.
83
ЧДТУ 252482.006 ПЗ
Рис. 3.9 – Діаграма послідовності: облік групової витрати та розрахунок
часток
3.2.5.3 Діаграма комунікацій
84
ЧДТУ 252482.006 ПЗ
Діаграма комунікації у контексті веб-застосунку для управління
особистими та груповими фінансами використовується для того, щоб показати
не лише послідовність повідомлень, а й структуру взаємозв’язків між
об’єктами, які беруть участь у виконанні певного сценарію. Якщо діаграма
послідовності робить акцент на часовому аспекті, то діаграма комунікації
підкреслює, які саме об’єкти взаємодіють між собою і які повідомлення вони
передають, зберігаючи при цьому нумерацію кроків сценарію. Для нашої
системи це зручно продемонструвати на прикладі сценарію «перегляд зведеного
дашборду користувача», де одночасно задіяні елементи інтерфейсу, API-сервер,
сервіси доменної логіки, репозиторії та база даних.
Сценарій починається з того, що користувач у веб-інтерфейсі відкриває
сторінку дашборду. Об’єкт «User» ініціює запит до «WebUI», який відповідає за
відображення сторінок у браузері. WebUI, не маючи власних даних, надсилає
запит до об’єкта «ApiServer» для отримання агрегованої інформації щодо
рахунків, останніх транзакцій, виконання бюджету та прогресу фінансових
цілей. ApiServer делегує завдання спеціалізованому об’єкту «DashboardService»,
який координує взаємодію з низкою репозиторіїв: «AccountRepository»,
«TransactionRepository», «BudgetRepository» та «GoalRepository». Кожен із
репозиторіїв у відповідь виконує запити до бази даних «PostgreSQL», отримує
відповідні набори даних і повертає їх у стиснутому вигляді сервісу дашборду.
На рівні сервісу відбувається агрегація: підраховується підсумковий
баланс за всіма рахунками у базовій валюті користувача, формується список
останніх транзакцій, обчислюються відсотки виконання бюджету по ключових
категоріях, розраховується відсоток досягнення фінансових цілей. Після цього
DashboardService повертає структурований об’єкт із даними ApiServer’у, який
формує JSON-відповідь для клієнта. WebUI отримує її, оновлює віджети
дашборду, відображаючи карти рахунків, діаграми, індикатори виконання
бюджету та прогрес цілей, а користувач бачить оновлений стан своїх особистих
і, за потреби, групових фінансів. Діаграма комунікації дозволяє компактно
85
ЧДТУ 252482.006 ПЗ
показати, які об’єкти залучені до цього процесу і які саме повідомлення між
ними проходять на кожному кроці.
Рис. 3.10 – Діаграма комунікації
86
ЧДТУ 252482.006 ПЗ
3.2.5.4 Діаграма скінченного автомату
Діаграма скінченного автомату в нашому веб-застосунку потрібна для
того, щоб формально описати, як система переходить між дискретними станами
під впливом подій. На відміну від діаграми діяльності, яка показує потік дій, чи
діаграми послідовності, що зосереджується на обміні повідомленнями між
об’єктами, скінченний автомат фіксує саме простір можливих станів певної
сутності та допустимі переходи між ними. Для веб-застосунку управління
особистими та груповими фінансами таке моделювання особливо доречне для
об’єктів, що мають чіткий життєвий цикл, наприклад групових транзакцій, які
створюються, підтверджуються, частково або повністю погашаються та, за
потреби, скасовуються.
Як приклад у цій роботі розглядається життєвий цикл об’єкта «групова
транзакція», який моделюється як скінченний автомат (Рис. 3.11) із обмеженим
набором станів. Групова транзакція виникає, коли один з учасників групи
фіксує спільну витрату, що підлягає розподілу між кількома людьми. На момент
створення система ще не зобов’язана одразу змінювати боргові співвідношення,
адже користувач може скасувати дію, виправити суму або склад учасників. Тому
перший стан, у який потрапляє об’єкт, доцільно описати як «Створена» або
«Чернетка». У цьому стані транзакція існує в системі, але її ефект на борги в
групі ще або не зафіксований, або може бути безболісно відкотений.
Після того як користувач підтвердив операцію, натиснувши, наприклад,
«Зберегти й розподілити», групова транзакція переходить до стану «Активна».
Це означає, що система розрахувала частки для кожного учасника, створила
відповідні записи GroupShare та оновила таблицю боргів групи. З цього
моменту транзакція починає впливати на сальдо «хто кому і скільки винен». У
стані «Активна» користувачі групи можуть поступово погашати свої
зобов’язання: фіксувати часткові або повні розрахунки, переглядати деталізацію
боргів, уточнювати призначення платежу.
У процесі експлуатації типовою стає ситуація, коли частина учасників
уже погасила свою частку боргу, а частина — ні. Для відображення цього
87
ЧДТУ 252482.006 ПЗ
проміжного стану вводиться стан «Частково погашена». Перехід у нього
ініціюється подією «часткове закриття боргів»: один або кілька учасників
платять свою частку, система реєструє факти платежів і перераховує поточне
сальдо. Важливо, що з точки зору автомата такий стан відрізняється від просто
«Активної» транзакції: він сигналізує, що борги вже частково зменшені, але ще
не дорівнюють нулю для всіх учасників. Це дозволяє будувати логіку
нагадувань, аналітики й фільтрації, наприклад, виділяти «частково закриті»
групові витрати.
Рис. 3.11 – Діаграма скінченного автомату
88
ЧДТУ 252482.006 ПЗ
Кінцевим бажаним станом для будь-якої боргової транзакції є «Повністю
погашена». Перехід у нього відбувається, коли сума всіх платежів за
транзакцією дорівнює або перевищує суму боргів, що були сформовані при її
активації, а поточне сальдо між учасниками за цією операцією стає нульовим. У
цьому стані транзакція фактично завершує свій життєвий цикл: вона
залишається в історії, бере участь в аналітиці та звітах, але більше не змінює
боргові взаємовідносини між учасниками групи. Для автомата це один з двох
можливих фінальних станів.
Другим фінальним станом є «Скасована». Він відповідає ситуаціям, коли
транзакція була введена помилково (неправильна сума, хибна дата, не та група)
або користувач свідомо вирішив не враховувати її в системі. Перехід «Створена
→ Скасована» можливий без будь-яких побічних ефектів, якщо борги ще не
були зафіксовані. Перехід «Активна → Скасована» або «Частково погашена →
Скасована» вимагає від системи виконання компенсаційних дій: повернення
попередніх змін у таблицях боргів, можливо — відмітки платежів як
анульованих і корекції відповідних агрегованих показників. Тому алгоритмічна
логіка в цьому випадку складніша, але з точки зору автомата це все той самий
перехід у кінцевий стан «Скасована» із подальшим блокуванням будь-яких
нових операцій за цією транзакцією.
Скінченність автомата гарантується тим, що множина станів є фіксованою
і невеликою: транзакція не може перебувати ни в «півтора» станах одночасно та
не може мати довільний неструктурований статус. Для кожної події, яка
стосується групової транзакції (створення, підтвердження, часткове погашення,
повне погашення, скасування), формується чітке правило переходу з одного
стану в інший або правило відхилення події, якщо такий перехід заборонений.
Наприклад, неможливо «частково погасити» транзакцію, яка вже перебуває у
стані «Повністю погашена» або «Скасована», і автомат просто відкидає такі
запити як некоректні. Це спрощує перевірку інваріантів і знижує ризик логічних
помилок.
89
ЧДТУ 252482.006 ПЗ
Висновок до розділу 3
У третьому розділі було реалізовано детальне проектування програмного
забезпечення інформаційної системи на основі сформованих у попередньому
розділі моделей. Було проведено моделювання предметної області та
деталізацію вимог до системи, включаючи функціональні та нефункціональні
вимоги. За допомогою UML-діаграм класів та пакетів була спроектована
логічна структура програмного комплексу. Архітектурне проектування системи
було відображено за допомогою діаграм компонентів, що ілюструють
розділення клієнтської, серверної та базової частин, а також діаграми
розгортання, що визначає фізичну структуру системи на апаратних засобах.
Моделювання поведінки системи за допомогою діаграм діяльності,
послідовності та станів дозволило формально описати ключові сценарії
взаємодії користувача з застосуванням, зокрема життєві цикли фінансових цілей
та процеси обробки транзакцій.
90
ЧДТУ 252482.006 ПЗ
РОЗДІЛ 4. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
4.1 Розробка програмного комплексу
У цьому розділі розглядається процес розробки програмного комплексу
веб-застосунку для управління особистими та груповими фінансовими
користувачами. Розділ присвячений практичній реалізації архітектурних і
поведінкових рішень, отриманих у попередніх розділах, а також опису
програмних компонентів, їх взаємодії та функціонального наповнення.
Основна увага приділяється реалізації програмного комплексу з позицій
інженерії програмного забезпечення, зокрема досягненню принципів
модульності, масштабованості, повторного використання коду та підтримки. У
розділі висвітлюються ключові аспекти програмної реалізації клієнтської та
серверної частини системи, а також організація взаємодії з базою даних.
У межах розділу розглядаються такі питання:
– вибір та обґрунтування технологічного стеку програмного комплексу;
– реалізація архітектури клієнт-серверної взаємодії;
– розробка серверної частини з використанням REST API;
– реалізація бізнес-логіки обробки фінансових операцій;
– організація зберігання та доступу до даних у базі даних;
– розробка клієнтського інтерфейсу користувача;
– забезпечення аутентифікації та авторизації користувачів;
– обробка помилок, логування та забезпечення надійності системи
роботи.
Окрему увагу приділено реалізації ключових функціональних
можливостей програмного комплексу, зокрема обліку доходів і витрат,
планування бюджету, аналізу фінансових показників та розподілу групових
витрат між користувачами. Розглядається структура програмних модулів, їх
призначення та взаємодія в межах загальної архітектурної системи.
Також у розділі описані підходи до забезпечення безпеки програмного
91
ЧДТУ 252482.006 ПЗ
комплексу, включаючи захист даних користувачів, контроль доступу до ресурсів
системи та використання захищених протоколів передачі даних. Наводяться
принципи організації програмного коду, які сприяють підвищенню якості
програмного продукту та сприяють його подальшому розвитку і супроводу.
Результатом даного розділу є опис реалізованого програмного комплексу,
який демонструє практичне застосування теоретичних моделей, архітектурних
рішень і сценаріїв поведінки, розроблених у попередніх розділах дипломної
роботи.
4.1.1 Обґрунтування вибору засобів реалізації
Вибір технологічного стеку для веб-застосунку управління особистими та
груповими фінансами визначався як вимогами предметної області (обробка
значної кількості транзакцій, підтримка мультивалютності, групові сценарії),
так і нефункціональними вимогами до системи (зручність інтерфейсу, безпека,
розширюваність, простота супроводу). У результаті аналізу альтернатив було
сформовано стек, який включає клієнтську частину на основі HTML5, CSS3 і
JavaScript, серверну логіку на Node.js з використанням фреймворку Express.js та
реляційну СУБД PostgreSQL для зберігання даних. Для візуалізації аналітики
обрано легку JavaScript-бібліотеку для побудови графіків, а для інтеграції курсів
валют – підключення до зовнішнього REST API. Весь процес розробки
організовано навколо інструментів версійного контролю і сучасного середовища
розробки.
Клієнтська частина системи реалізована на основі HTML5, CSS3 та
JavaScript, оскільки це стандартний стек для сучасних веб-інтерфейсів. HTML5
дає змогу семантично структурувати сторінки застосунку: панелі навігації,
блоки карток рахунків, таблиці транзакцій, модальні вікна додавання операцій.
CSS3 із використанням Flexbox і Grid забезпечує адаптивне компонування
елементів інтерфейсу, завдяки чому застосунок коректно відображається як на
екранах ноутбуків, так і на планшетах чи великих моніторах. Це особливо
важливо для фінансового застосунку, де користувач очікує наочні панелі зі
швидким доступом до ключових показників: загального балансу, структури
92
ЧДТУ 252482.006 ПЗ
витрат, стану бюджетів та групових розрахунків.
Таблиця 4.1
Основні засоби розробки веб-застосунку
Категорія Обраний засіб Призначення Ключові переваги для
проєкту
Мова клієнта HTML5, CSS3, Розробка веб- Стандартність,
JavaScript інтерфейсу, логіка підтримка всіма
на стороні браузерами, гнучкість
браузера
Фреймворк Node.js + Express.js Реалізація REST Єдина мова JS
сервера API, бізнес- фронт/бек, висока
логіки, продуктивність
авторизації
СУБД PostgreSQL Зберігання ACID-транзакції,
транзакцій, потужний SQL,
рахунків, груп, безкоштовність
бюджетів
ORM/доступ Sequelize/TypeORM Об’єктно- Зменшення «ручного»
до БД (JS ORM) реляційне SQL, контроль схеми
відображення
доменної моделі
Графіка/аналі JS-бібліотека для Відображення Інтерактивність,
тика графіків діаграм доходів, мінімальний код на
витрат, бюджетів стороні клієнта
93
ЧДТУ 252482.006 ПЗ
Продовження таблиці 4.1
Зовнішні API курсів валют Отримання Актуальні дані без
сервіси актуальних курсів власної
валют і інфраструктури
криптовалют
IDE та Visual Studio Code, Розробка, Зручність,
інструменти Git відлагодження, розширюваність,
контроль версій командна робота
JavaScript на стороні клієнта використовується для реалізації динамічної
поведінки, яка прямо відповідає сценаріям, описаним у попередніх розділах.
Саме за допомогою JS реалізовано інтерактивну обробку форм, валідацію
введених користувачем даних без перезавантаження сторінки, побудову діаграм
та оновлення панелей «у реальному часі» після додавання нової транзакції або
зміни рахунку. Для аналітичних панелей в інтерфейсі використовується легка
JS-бібліотека для побудови графіків (типу Chart.js), що дозволяє в кілька рядків
коду отримати інтерактивні кругові та стовпчикові діаграми зі структурою
витрат за категоріями, динамікою доходів та прогресом у досягненні
фінансових цілей.
З огляду на підтримку мультивалютності та потребу в «живій» аналітиці
логічним є використання єдиної мови JavaScript як на клієнтській, так і на
серверній стороні. Саме тому як серверне середовище обрано Node.js з
фреймворком Express.js. Node.js забезпечує неблокуючу модель
введення/виведення, що добре підходить для веб-додатків, у яких є велика
кількість відносно невеликих запитів до бази даних і зовнішніх API (наприклад,
для отримання курсів валют чи оновлення списків транзакцій). Використання
Express.js дає змогу компактно описати REST-ендпойнти для всіх варіантів
використання, сформованих у розділі 2: авторизації, роботи з рахунками й
транзакціями, формування бюджетів, дій у групах, запитів до модулю звітності.
94
ЧДТУ 252482.006 ПЗ
Єдність мови JavaScript у всьому стеку спрощує розробку саме для такого
типу застосунку. Логіка розрахунку бюджетів, розподілу групових витрат,
конвертації валют може бути реалізована аналогічними конструкціями як на
клієнті (для попереднього відображення), так і на сервері (як остаточна
authoritative-логіка, яка працює з базою даних). Це зменшує кількість
дублювання коду і полегшує супровід: розробнику не потрібно постійно
перемикатися між різними мовами, як це було б у випадку, наприклад, з Java на
сервері та JavaScript у браузері.
Для зберігання фінансової інформації обрана реляційна СУБД
PostgreSQL. Такий вибір безпосередньо випливає з концептуальної моделі, де
використовуються сутності з чіткими зв’язками «один до багатьох» і «багато до
багатьох»: користувачі, рахунки, транзакції, групи, учасники груп, бюджети,
бюджетні рядки, фінансові цілі. Реляційна модель природно відображає ці
зв’язки за допомогою первинних і зовнішніх ключів, що дозволяє гарантувати
цілісність даних у ситуаціях, коли одна транзакція пов’язана одночасно з
рахунком, категорією, бюджетом і, можливо, ціллю. PostgreSQL підтримує
повноцінні ACID-транзакції, що є критичним для фінансової системи: при
створенні транзакції необхідно одночасно зберегти запис про операцію, змінити
баланс рахунку, оновити агреговані значення бюджету та, за потреби, прогрес
фінансової цілі. У випадку помилки будь-яка з цих операцій не повинна
залишати дані в «половинчастому» стані.
Обґрунтування вибору PostgreSQL посилюється й тим, що ця СУБД є
безкоштовною, відкритою та широко підтримуваною. Вона добре
масштабується для середніх і великих обсягів даних, має розвинені механізми
індексування й оптимізації запитів, а також підтримує зберігання JSON-полів,
що може бути використано для зберігання гнучких налаштувань користувача чи
логів дій без створення окремих таблиць. У таблиці 4.2 наведено коротке
порівняння PostgreSQL з деякими популярними альтернативами, яке дозволяє
побачити, чому саме вона є доцільною для розроблюваного застосунку.
Як видно з таблиці, NoSQL-рішення привабливі гнучкістю схеми, але для
95
ЧДТУ 252482.006 ПЗ
системи, де життєво важливими є нормалізовані зв’язки та транзакційна
цілісність (особливо в групових операціях і мультивалютних перерахунках),
реляційна СУБД є більш обґрунтованим вибором.
Для доступу до бази даних з коду Node.js використовується ORM-
бібліотека (на кшталт Sequelize або TypeORM), яка пов’язує доменні класи з
таблицями БД. Такий підхід дозволяє описувати структуру таблиць, зв’язки,
обмеження та базові запити на рівні об’єктної моделі, а не у вигляді «ручних»
SQL-рядків. Це зменшує ймовірність помилок у запитах, спрощує міграції
схеми (додавання нових полів до сутностей бюджету, групових транзакцій
тощо) та підвищує читабельність коду. Важливо, що ORM дозволяє прямо
відобразити сутності, розроблені на етапі UML-моделювання, в термінах класів
та їхніх асоціацій
Таблиця 4.2
Порівняння альтернативних СУБД для фінансового веб-застосунку
NoSQL (MongoDB
Критерій PostgreSQL MySQL/MariaDB
тощо)
Тип моделі Реляційна Реляційна Документоорієнто
вана
Транзакції ACID Повна підтримка Підтримуються, Часто обмежена
але обмеженіше або інша
семантика
Складні запити Дуже добра Добра підтримка Не природні,
(JOIN) підтримка через агрегування
Цілісність даних Первинні/зовнішн Аналогічно Гарантується на
і ключі, тригери рівні окремого
документа
96
ЧДТУ 252482.006 ПЗ
Продовження таблиці 4.2
Гнучкість схеми Фіксована, із Фіксована Дуже висока
можливістю JSON
Доцільність для Висока Висока Обмежена для
фінансів складних зв’язків
Особливе місце в застосунку посідає модуль роботи з курсами валют та
криптовалют, оскільки система має підтримувати мультивалютність і коректно
конвертувати суми при побудові зведених звітів. Для цього серверна частина
підключається до зовнішнього REST API, який повертає актуальні курси в
форматі JSON. Отримані дані кешуються в локальній таблиці ExchangeRate, що
дозволяє зменшити кількість звернень до стороннього сервісу та забезпечити
відтворюваність розрахунків за історичними транзакціями. Використання
Node.js тут є природним, оскільки взаємодія з зовнішніми API, обробка JSON та
асинхронні запити є «рідною стихією» цього середовища.
Ще один важливий елемент інтерфейсу – модуль простих фінансових
калькуляторів (наприклад, кредитний калькулятор або калькулятор цільових
накопичень). Оскільки обчислення, які в них виконуються, є локальними і не
потребують постійного зберігання в базі даних, вони реалізовані безпосередньо
на стороні клієнта засобами JavaScript. Це дозволяє користувачеві миттєво
отримувати результат розрахунків, змінювати вихідні параметри і бачити, як
змінюється результат, не навантажуючи при цьому сервер і базу даних.
Організація процесу розробки також базується на використанні сучасних
інструментів. У роботі застосовано середовище розробки Visual Studio Code, яке
забезпечує підтримку JavaScript, Node.js, інтегровану систему відлагодження,
розширення для роботи з Git та інструментами форматування коду. Для
керування версіями використовується Git, що дозволяє фіксувати еволюцію
проєкту, повертатися до стабільних станів, розгалужувати розробку за
окремими функціональними гілками, зокрема під час доопрацювання модулю
97
ЧДТУ 252482.006 ПЗ
групових фінансів чи валютних конвертацій. Для тестування REST API
застосовується інструмент типу Postman або аналогічний клієнт, який дозволяє
емулювати запити фронтенду, перевіряти коректність відповідей, структуру
JSON, обробку помилок та авторизації.
Таким чином, вибір HTML5/CSS3/JavaScript для клієнтської частини,
Node.js/Express.js для серверної логіки та PostgreSQL як СУБД є узгодженим із
вимогами, сформованими в попередніх розділах. Обраний стек забезпечує
необхідну гнучкість у реалізації сценаріїв управління особистими та груповими
фінансами, підтримку мультивалютності та інтеграцій з зовнішніми сервісами,
транзакційну цілісність фінансових даних, а також достатню простоту
розгортання і подальшого масштабування веб-застосунку.
4.1.2 Опис структурної (функціональної) схеми
Структурна (функціональна) схема веб-застосунку для управління
особистими та груповими фінансами відображає, які основні підсистеми
входять до складу програмного комплексу, які потоки даних між ними
циркулюють і як організовано взаємодію з користувачем, базою даних та
зовнішніми сервісами. На відміну від діаграм класів чи розгортання, які
фіксують або внутрішню структуру доменної моделі, або фізичне розміщення
компонентів на апаратних засобах, функціональна схема концентрується на
логічних модулях і «доріжках» обробки інформації. У роботі така схема може
бути подана у вигляді рис. 4.X «Структурна (функціональна) схема веб-
застосунку для управління особистими та груповими фінансами».
У верхньому рівні схеми виділяється користувач як джерело й одержувач
інформації. Користувач взаємодіє із системою через веб-інтерфейс, що працює в
браузері. Усі первинні дії — реєстрація, вхід, перегляд рахунків, додавання
транзакцій, створення груп, налаштування бюджету, аналіз звітів —
ініціюються саме з клієнтського інтерфейсу. Цей інтерфейс відповідає за
відображення форм, таблиць, графіків, панелей дашборду, а також за первинну
валідацію введених даних (формат сум, обов’язкові поля, коректність дат). У
функціональній схемі клієнтська частина виділена як підсистема «Веб-
98
ЧДТУ 252482.006 ПЗ
інтерфейс користувача», яка обмінюється з сервером структурованими
HTTP(S)-запитами і JSON-відповідями.
Нижче на схемі розташована серверна частина, логічно розділена на
кілька основних підсистем, кожна з яких реалізує свою частину бізнес-
функціоналу. На вході стоїть модуль «API-шлюз / контролери», що приймає
запити від веб-інтерфейсу, виконує розпізнавання маршруту, перевірку прав
доступу та передає запит у відповідний сервіс доменної логіки. Цей модуль
ізолює внутрішню структуру застосунку від зовнішнього світу, забезпечуючи
єдиний формат взаємодії клієнта з системою.
Окремим контуром у структурній схемі виділено підсистему
автентифікації та авторизації. Вона включає функції реєстрації користувачів,
входу до системи, скидання паролю, а також керування токенами доступу. На
функціональній схемі ця підсистема отримує від API-шлюзу облікові дані,
перевіряє їх у сховищі користувачів, формує токени, зберігає мінімально
необхідну інформацію в базі даних і повертає в API статус операції та
ідентифікатор користувача. Для захисту інших підсистем саме цей контур є
«вхідними воротами» до бізнес-функціоналу, оскільки всі запити на роботу з
фінансовими даними повинні бути пов’язані з автентифікованим користувачем.
Основний обсяг функцій з управління особистими фінансами
зосереджено в підсистемі «Управління рахунками та транзакціями». Вона
приймає від API-шлюзу команди додати, змінити чи видалити рахунок,
провести транзакцію, здійснити переказ між рахунками, отримати історію
операцій за обраний період. Усередині цієї підсистеми виділяються логічні
модулі обробки рахунків, модуль транзакцій, модуль категоризації, а також
модуль розрахунку підсумкових залишків. У функціональній схемі вони
показані як послідовні етапи: прийом запиту, перевірка прав, перевірка
коректності даних, виконання операції над рахунками й транзакціями,
оновлення агрегованих сум та повернення результату. Вихідними даними цієї
підсистеми є оновлені баланси рахунків та історія руху коштів, які в
подальшому використовуються в підсистемах бюджетування й аналітики.
99
ЧДТУ 252482.006 ПЗ
Другий важливий контур — «Управління груповими фінансами». Ця
підсистема працює з об’єктами груп, їхніми учасниками та груповими
транзакціями. На структурній схемі її можна уявити як блок, що отримує від
API-шлюзу запити на створення групи, запрошення учасників, реєстрацію
групових витрат, розподіл суми між учасниками і розрахунок взаємних боргів.
Усередині підсистеми виділяється модуль керування складом групи, модуль
розподілу витрат (обчислення часток за обраним правилом) і модуль боргових
сальдо, який підтримує актуальний стан взаємних зобов’язань між учасниками.
Результатом роботи цього контуру є таблиця боргів і деталізація, яку пізніше
відображає інтерфейс групового бюджету.
Окремим логічним блоком показано підсистему «Бюджетування та
фінансові цілі». Вона взаємодіє з підсистемою рахунків і транзакцій,
отримуючи фактичні дані, і перетворює їх на показники виконання бюджету та
прогресу цілей. Функціональна схема у цьому місці демонструє потік:
конфігурація бюджету та цілей надходить від інтерфейсу користувача в цю
підсистему, зберігається у базі даних, після чого на основі реальних транзакцій
періодично розраховуються план–факт відхилення за категоріями і відсоток
досягнення цілей. Вихід цієї підсистеми — агреговані дані, які отримують
аналітичні блоки та модуль формування сповіщень.
Функціональна підсистема «Аналітика та звітність» обробляє агреговані
дані, отримані з попередніх модулів, та готує їх до візуалізації у вигляді
таблиць, діаграм, дашбордів. На схемі вона представлена як блок, що отримує
запити на формування звіту від клієнтського інтерфейсу через API-шлюз,
звертається до підсистем транзакцій, бюджетування й групових фінансів,
виконує необхідні агрегування (суми за категоріями, тренди за періодами,
структура витрат, структура боргів), формує структуру звіту й повертає її у
вигляді JSON. Саме на основі цієї інформації у веб-інтерфейсі будуються
кругові діаграми, гістограми, лінійні графіки та індикатори виконання бюджету.
Ще один важливий логічний елемент структурної схеми — підсистема
«Робота з валютними курсами та конвертацією». Вона складається з
100
ЧДТУ 252482.006 ПЗ
внутрішнього сервісу курсоутворення та адаптера до зовнішнього API
постачальника валютних і криптовалютних курсів.
Рис. 4.1 – Функціональна схема Веб-застосунку
На вході підсистема отримує запити від модулів транзакцій та аналітики
на конвертацію сум у базову валюту користувача або на оновлення таблиці
курсів. Усередині схеми показано звернення до зовнішнього сервісу через
HTTPS для отримання актуальних курсів, збереження їх у локальній базі даних
і подальшу видачу цих значень іншим підсистемам. Таким чином
мультивалютна підтримка інтегрується в загальну структуру системи як
101
ЧДТУ 252482.006 ПЗ
окремий обслуговуючий блок, що не «зашиває» курси у бізнес-логіку, а надає їх
через чітко визначений інтерфейс.
4.1.3 Опис логічної схеми системи
Серверна частина веб-застосунку реалізована як REST-сервіс на
платформі Node.js з використанням фреймворку Express. Така архітектура
відповідає логічній моделі, описаній у розділі 2, і забезпечує чітке розділення
шарів: HTTP-інтерфейсу, бізнес-логіки та доступу до даних. Усі запити від
клієнта надходять до контролерів Express, де виконуються базова валідація,
авторизація (у поточному прототипі — спрощена, з одним користувачем) та
маршрутизація до відповідних сервісів доменної логіки.
Як цільову СУБД у проєкті обрано PostgreSQL, однак для розробки і
локального запуску використано вбудовану реляційну СУБД SQLite. Дані
зберігаються у файлі finance.db , який повністю відповідає логічній схемі,
спроєктованій для PostgreSQL. Завдяки спільній реляційній моделі та
однаковому діалекту SQL схема таблиць може бути без змін перенесена на
PostgreSQL у разі розгортання промислової версії. Підключення до бази даних
виконується через драйвер sqlite3 та тонкий шар репозиторіїв, що інкапсулюють
SQL-запити й дозволяють у майбутньому замінити SQLite на PostgreSQL без
зміни бізнес-логіки.
Внутрішня структура серверного застосунку розділена на кілька
каталогів: routes містить визначення HTTP-маршрутів, controllers – логіку
обробки запитів, services – доменні сервіси для роботи з транзакціями,
рахунками, групами, бюджетами та валютами, а db – файл ініціалізації бази
даних і модулі доступу до таблиць.
При старті застосунку виконується скрипт, який створює таблиці за
відсутності файлу finance.db і заповнює базові довідники (список валют,
початкові системні категорії). Фрагмент коду ініціалізації сервера та
підключення до бази доцільно подати як рис. 4.2.
Усі відповіді сервера повертаються в форматі JSON, що спрощує обробку
на клієнті. Для обмеження доступу до критичних операцій (створення та
видалення даних) застосовується перевірка API-ключа або токена в заголовках
102
ЧДТУ 252482.006 ПЗ
запиту; в прототипі використано спрощений підхід, але структура коду дозволяє
замінити його на повноцінну JWT-автентифікацію.
Основні REST-ендпойнти серверної частини узагальнено в таблиці 4.3.
Таблиця 4.3
Основні REST-ендпойнти серверної частини
Ендпойнт HTTP- Призначення
метод
/api/summary GET Обчислення підсумків: сумарні доходи,
витрати, баланс
/api/accounts GET/POST Отримання списку рахунків і створення
нового рахунку
/api/accounts/:id PUT/DELE Редагування та архівація рахунку
TE
/api/transactions GET/POST Отримання та додавання особистих
транзакцій
/api/transactions/:id PUT/DELE Оновлення та видалення транзакції
TE
/api/groups GET/POST Створення та перегляд груп для спільних
фінансів
/api/groups/:id/expenses GET/POST Облік і перегляд групових витрат
/api/tools/rates GET Отримання актуальних курсів валют та
криптовалют
/api/tools/convert GET Конвертація суми з однієї валюти в іншу
/api/tools/calculator/loan POST Розрахунок параметрів кредиту (платіж,
переплата, графік)
4.1.4 Розробка бази даних
103
ЧДТУ 252482.006 ПЗ
Структура бази даних відображає концептуальну модель з розділу 2.2.
Основні таблиці: users, accounts, transactions, categories, groups, group_members,
group_expenses, group_shares, currencies, exchange_rates, а також службові
таблиці для збереження налаштувань та журналу дій. Стислий опис таблиць
наведено в таблиці 4.4.
Таблиця transactions містить суму, тип операції (дохід/витрата/трансфер),
дату, опис і валюту. Через поле account_id транзакція пов’язана з таблицею
accounts, а через category_id – з таблицею categories. Для прискорення відбору
записів за періодами й категоріями створені комбіновані індекси по полях date
та category_id. Групові витрати зберігаються у таблиці group_expenses, де
фіксується загальна сума, валюта, опис і базова інформація про платника.
Деталізація розподілу суми між учасниками реалізована через таблицю
group_shares, що дозволяє зберігати як рівні частки, так і індивідуальні відсотки
або фіксовані суми. Точно так само курс валют спочатку запитується з
зовнішнього API, а потім зберігається в exchange_rates, щоб при побудові
історичних звітів використовувати курс на конкретну дату.
Таблиця 4.4
Основні таблиці бази даних finance.db
Таблиця Призначення Ключові поля
users Зберігання інформації про id – PK, email, password_hash,
користувачів base_currency
accounts Окремі рахунки користувача id – PK, user_id/group_id – FK,
або групи currency
transactions Особисті операції доходів і id – PK, account_id – FK,
витрат category_id – FK
categories Класифікатор доходів і витрат id – PK, name, type
104
ЧДТУ 252482.006 ПЗ
Продовження таблиці 4.4
groups Групи для спільного ведення id – PK, name, owner_id –
фінансів FK
group_members Приналежність користувачів до id – PK, group_id – FK,
груп user_id – FK, role
group_expenses Сукупні групові витрати id – PK, group_id – FK,
payer_id – FK
group_shares Частки окремих учасників у id – PK, expense_id – FK,
групових витратах member_id – FK
currencies Довідник валют і криптовалют code – PK, name, symbol,
is_crypto
exchange_rates Кешовані курси валют id – PK, base_code,
При додаванні нової транзакції або групової витрати контролер викликає
відповідний сервіс, який у межах однієї SQL-транзакції записує основний
запис, оновлює поточний баланс рахунку та, за необхідності, коригує агреговані
значення в допоміжних таблицях. Після успішного завершення сервер повертає
клієнту оновлені агрегати (загальні доходи, витрати, баланс, сальдо боргів у
групі), що дозволяє миттєво оновити інтерфейс без додаткових запитів.
Рис. 4.1 – Серверна частина
105
ЧДТУ 252482.006 ПЗ
Таким чином, серверна частина веб-застосунку реалізована з урахуванням
вимог до безпеки, цілісності даних і масштабованості. Використання
Node.js/Express спрощує розширення функціоналу, а реляційна структура бази
даних у файлі finance.db забезпечує надійне зберігання як особистих, так і
групових фінансових даних.
4.1.5 Розробка інтерфейсу користувача
Клієнтська частина веб-застосунку побудована як односторінковий
інтерфейс на основі HTML5, CSS3 та JavaScript, який взаємодіє з сервером
через REST-API. Головна мета інтерфейсу – зробити роботу з особистими та
груповими фінансами максимально наочною й «легкою», щоб користувач бачив
ключові показники в один погляд і міг виконати основні дії за мінімальну
кількість кліків.
Рис. 4.2 – Структура додатку
Структурно HTML-розмітка складається з кількох великих блоків. У
верхній частині сторінки розташований hero-блок у стилі сучасних фінансових
сервісів: ліворуч – заголовок «Більше ніколи не хвилюйся за гроші» з коротким
описом можливостей застосунку та кнопками «Почати безкоштовно» і «У мене
106
ЧДТУ 252482.006 ПЗ
вже є акаунт», праворуч – стилізований макет мобільного екрана з візуалізацією
бюджету (рис. 3.4). Цей блок виконує роль презентаційного інтро і може бути
використаний як окремий екран лендингу.
Рис. 4.3 – Головний екран додатку
Нижче розміщено робоче поле застосунку. Центральним елементом є три
інформаційні картки «Доходи», «Витрати», «Баланс», виконані у вигляді
великих прямокутників із темним фоном, тонкими неоновими рамками та
яскравими заголовками зеленого, червоного і синього кольорів.
Рис. 4.4 – Авторизація
Значення сум відображаються великим білим шрифтом на синьому
бейджі, що забезпечує високий контраст і швидке сприйняття (рис. 3.5). Ці
картки оновлюються динамічно після кожної операції без перезавантаження
сторінки: JavaScript отримує від сервера нові агреговані значення й замінює
107
ЧДТУ 252482.006 ПЗ
вміст відповідних елементів.
Рис. 4.5 – Особисті фінанси
Ліворуч під підсумковими картками знаходиться таблиця особистих
операцій з колонками «Дата», «Тип», «Категорія», «Опис», «Сума». Порожній
стан таблиці супроводжується текстовою підказкою «Операцій поки немає.
Додайте першу!», що видно на рис. 4.4 . Над таблицею розташована кнопка
«Нова особиста операція», яка відкриває модальне вікно з формою додавання
транзакції. У формі передбачено вибір рахунку, типу (дохід/витрата), категорії,
введення суми, дати та опису; частина полів заповнюється за замовчуванням
(поточна дата, остання використана категорія). Валідація виконується на
стороні клієнта: при помилці користувач отримує повідомлення, а некоректно
заповнені поля підсвічуються. При успішному заповненні форма відправляє
дані на сервер методом fetch, закривається й одразу оновлює таблицю та картки
підсумків.
108
ЧДТУ 252482.006 ПЗ
Рис. 4.6 – Блок Аналітики і останіх операцій
Праворуч розташований блок аналітики. У верхній частині цього блоку
виводиться текстова підказка або коротке зведення, нижче – інтерактивна
діаграма структури витрат за категоріями за обраний період. Для її побудови
використано JavaScript-бібліотеку графіків: після завантаження сторінки клієнт
надсилає запит /api/transactions?period=current-month, отримує агреговані дані й
ініціалізує кругову чи стовпчикову діаграму. Зміна періоду або фільтрів
супроводжується повторним запитом і перерендером графіка.
Рис. 4.7 – api/transactions
109
ЧДТУ 252482.006 ПЗ
Під основною таблицею знаходиться панель «Мої групи», яка відображає
список створених груп (сім’я, квартира, навчальний проєкт тощо). Кнопка «Мої
групи» відкриває модальне вікно, у якому користувач може створити нову
групу, задати її назву, опис і список учасників. Для прототипу учасники
задаються як текстові мітки (імена), але структура клієнтського коду передбачає
можливість прив’язки до реальних облікових записів. При виборі конкретної
групи інтерфейс правої частини екрана перемикається в режим групових
фінансів: табличка операцій змінюється на список групових витрат із
розподілом за учасниками, а блок аналітики – на огляд боргів і внесків у межах
групи (рис. 3.7).
Рис. 4.8 – Керування груповими витратами
Окрему увагу в інтерфейсі приділено блоку «Інструменти». Під кнопкою
«Інструменти» розкривається панель, що містить три міні-віджети: конвертер
валют, відображення актуальних курсів кількох основних криптовалют (Bitcoin,
Ethereum, Tether) та простий фінансовий калькулятор. Конвертер працює
повністю асинхронно: при введенні суми й виборі пар «з якої валюти» та «в
яку» клієнт надсилає запит до ендпойнту /api/tools/convert і показує результат,
підрахований сервером з використанням кешованих курсів. Блок криптовалют
показує назву, ціну в доларах США, еквівалент у євро та гривні; значення
періодично оновлюються завдяки повторним запитам до сервера. Калькулятор
дозволяє виконувати базові арифметичні операції, а також містить окремий
режим розрахунку щомісячного платежу за ануїтетним кредитом; реалізована
110
ЧДТУ 252482.006 ПЗ
формула повністю узгоджена з серверним модулем, щоб уникнути
розбіжностей.
Рис. 4.9 – Загальний вигляд панелі інструментів
Візуальний стиль застосунку витримано в темній кольоровій гамі з
плавним градієнтом фону від насиченого синього до бірюзового, що
перегукується зі стилістикою сучасних фінансових сервісів на кшталт YNAB.
Карти, таблиці та віджети мають заокруглені кути й м’які тіні, що надає
інтерфейсу ефекту «плаваючих» панелей. Акцентні кольори – зелений для
позитивних значень, червоний для витрат і попереджень, синій для нейтральних
інформаційних блоків – застосовуються послідовно, що дозволяє користувачу
легко орієнтуватися. Особливу увагу звернуто на контрастність шрифтів:
основний текст виконаний світлим кольором на темному фоні, а ключові
числові значення – великим напівжирним шрифтом білого кольору на синіх
бейджах.
Уся інтерактивність на клієнті реалізована через модуль app.js. Після
завантаження сторінки цей модуль ініціалізує слухачі подій для кнопок, форм і
селекторів, виконує початкові запити до серверних ендпойнтів /api/summary,
/api/transactions та /api/tools/rates, а також створює об’єкти діаграм. В окремих
функціях зібрано логіку повторного використання: оновлення таблиці
111
ЧДТУ 252482.006 ПЗ
транзакцій, перерахунок підсумкових карток, побудова графіка, виведення
повідомлень про помилки. Така декомпозиція спрощує внесення змін до
інтерфейсу, наприклад додавання нової вкладки з окремими звітами або
розширення модалі вікна групових витрат.
Завдяки такому підходу клієнтська частина веб-застосунку не тільки
відображає дані, отримані від сервера, а й активно формує користувацький
досвід: за кілька дій користувач може додати операцію, побачити її вплив на
загальний баланс, аналіз витрат за категоріями та стан групових розрахунків.
Інтерфейс підтримує «живу» взаємодію без перезавантажень сторінки, що
робить прототип веб-застосунку близьким за відчуттями до нативних
десктопних або мобільних фінансових програм.
4.1.6 Опис розробки програмних компонентів
Розробка програмних компонентів веб-застосунку для управління
особистими та груповими фінансами здійснювалася відповідно до
багатошарової архітектури, описаної у попередніх підрозділах. На логічному
рівні система поділена на клієнтську частину (веб-інтерфейс у браузері) та
серверну частину (REST-API, бізнес-логіка й доступ до бази даних), причому
кожен шар реалізовано у вигляді окремих модулів з чітко визначеною
відповідальністю. Такий поділ дозволив не лише підвищити читабельність і
супровідність коду, але й спростити тестування та подальший розвиток
функціоналу.
Серверна частина реалізована на платформі Node.js з використанням
фреймворку NestJS, який підтримує модульний підхід, інверсію керування та
декларатинве описання контролерів, сервісів і репозиторіїв. На верхньому рівні
визначено кореневий модуль додатку, що імпортує доменні модулі: AuthModule,
UsersModule, AccountsModule, TransactionsModule, GroupsModule,
BudgetsModule, GoalsModule, ReportsModule, FxRatesModule та
NotificationsModule. Кожен з них інкапсулює контролери, сервіси, DTO та схеми
взаємодії з базою даних, що відповідає принципу «один модуль — одна зона
відповідальності». Завдяки цьому структура програми відображає структуру
112
ЧДТУ 252482.006 ПЗ
предметної області, наведеної у діаграмах класів, а зміна логіки в одному
модулі мінімально впливає на інші.
Контролери серверної частини реалізують HTTP-інтерфейс системи.
Наприклад, AccountsController обробляє запити на отримання списку рахунків
користувача, створення нового рахунку, оновлення його параметрів і архівацію;
TransactionsController відповідає за фіксацію доходів, витрат і переказів,
фільтрацію транзакцій за періодом, категорією чи рахунком; GroupsController
надає операції створення групи, управління учасниками, реєстрації групових
транзакцій і розрахунків між учасниками. Кожен контролер делегує бізнес-
логіку відповідному сервісу, отримує від нього результат та повертає
уніфіковану JSON-відповідь. Через глобальні перехоплювачі реалізовано
обробку помилок, логування та стандартизацію структури відповіді API.
Бізнес-логіка зосереджена в сервісах. Сервіс AccountsService реалізує
правила створення рахунків, перевіряє коректність валют і типів, оновлює
баланси з урахуванням транзакцій, забезпечує атомарність операцій при
переказах між рахунками. TransactionsService виконує валідацію введених сум,
обов’язкових полів, перевіряє правомірність операцій над вибраним рахунком і
категорією, формує записи в таблиці транзакцій та ініціює оновлення
агрегованих показників. Саме на цьому рівні реалізовано логіку класифікації
операцій за категоріями і прив’язки їх до бюджетів.
Модуль GroupsModule містить GroupsService та GroupTransactionsService,
які відповідають за моделювання групових фінансів. Перший сервіс створює та
модифікує групи, керує ролями й правами доступу учасників, другий —
реалізує алгоритми розподілу спільних витрат. Залежно від обраного
користувачем правила (порівну, за відсотками, за фіксованими сумами) він
розраховує частки для кожного учасника, створює відповідні записи в таблиці
group_shares і ініціює оновлення внутрішніх боргових сальдо. Тут же
реалізовано операції часткового та повного погашення боргів, які відповідають
переходам між станами на діаграмі скінченного автомату групової транзакції.
Окремий модуль BudgetsModule реалізує функції бюджетування.
113
ЧДТУ 252482.006 ПЗ
BudgetsService створює бюджети на обрані періоди, налаштовує ліміти за
категоріями, а також виконує перерахунок план–факт відхилень на основі
фактичних транзакцій. При кожній зміні транзакцій модуль отримує сигнал від
TransactionsService, оновлює підсумкові суми у таблиці budget_items та формує
узагальнені показники для відображення у дашборді. Модуль GoalsModule зі
свого боку забезпечує створення й супровід фінансових цілей, оновлення
накопичених сум і зміну статусів цілі залежно від досягнутого прогресу та
наближення дедлайнів.
Підсистема аналітики реалізована у модулі ReportsModule. Сервіс
ReportsService отримує від інтерфейсу параметри звіту (період, набір рахунків,
набір категорій, типи транзакцій), формує запити до репозиторіїв транзакцій,
бюджетів і групових операцій, виконує агрегування (суми, середні значення,
відсоткові частки, тенденції у часі) та повертає структуровані дані для побудови
діаграм і таблиць на клієнті. Логіка розрахунків організована таким чином, щоб
легко додавати нові типи звітів (наприклад, аналіз структури боргів у групах
або динаміку накопичень до конкретної фінансової цілі) без переписування
існуючих сценаріїв.
Мультивалютний функціонал зосереджений у модулі FxRatesModule.
Сервіс FxRatesService реалізує два основних завдання: періодичне оновлення
курсових даних з зовнішнього API та виконання конвертації сум між валютами
на запит бізнес-сервісів. Для оновлення курсів використовується окремий
планувальник завдань, який звертається до зовнішнього сервісу, зберігає
отримані значення в таблиці exchange_rates та забезпечує доступ до історичних
курсів. При формуванні дашбордів і звітів аналітичні модулі звертаються до
FxRatesService за актуальним або релевантним на дату транзакції курсом, що
гарантує коректність розрахунків у базовій валюті користувача чи групи.
Підсистема сповіщень реалізована в модулі NotificationsModule. Її сервіс
отримує події від інших модулів (перевищення бюджетних лімітів, наближення
строку досягнення цілі, накопичені борги в групі), фільтрує їх за
налаштуваннями користувача, створює записи в таблиці notifications і, за
114
ЧДТУ 252482.006 ПЗ
потреби, ініціює надсилання email або push-сповіщень через зовнішні
інтеграційні адаптери. На рівні коду це реалізовано як набір обробників подій,
що реагують на доменні події, сформовані в інших сервісах, і перетворюють їх
на конкретні повідомлення для користувачів.
Доступ до бази даних інкапсульовано в репозиторіях, які або реалізовано
вручну за допомогою SQL-запитів, або побудовано на базі ORM-інструменту
(наприклад, TypeORM чи Prisma) відповідно до логічної моделі. Кожен
доменний модуль має власні репозиторії: UsersRepository, AccountsRepository,
TransactionsRepository, GroupsRepository, BudgetsRepository, GoalsRepository,
FxRatesRepository. Вони приховують деталі SQL-реалізації, забезпечують
типобезпечність і дозволяють бізнес-сервісам працювати з об’єктами доменної
моделі, а не з рядками таблиць. Таким чином досягається слабке зв’язування
між рівнем логіки та фізичним сховищем, що полегшує можливу міграцію або
оптимізацію схеми даних.
Клієнтська частина веб-застосунку реалізована як односторінковий
інтерфейс, структуру якого також організовано у вигляді набору компонентів. Є
окремі компоненти для сторінок реєстрації та входу, дашборду, списку рахунків,
перегляду історії транзакцій, керування групами, налаштувань бюджету й
фінансових цілей, а також модальні вікна для створення та редагування
окремих сутностей. Взаємодія з сервером здійснюється через єдиний модуль
API-клієнта, який інкапсулює виклики REST-endpoint’ів і обробку помилок.
Стан користувача, поточні фільтри та вибрані об’єкти зберігаються у
централізованому стані (контекст або легка state-management бібліотека), що
забезпечує узгодженість відображення даних у різних частинах інтерфейсу.
4.2 Тестування системи
Тестування веб-застосунку для управління особистими та груповими
фінансами виконувалося поетапно, відповідно до класичної піраміди
тестування: спочатку перевірялась коректність окремих функцій і сервісів
(модульне тестування), далі — взаємодія компонентів між собою (інтеграційне
115
ЧДТУ 252482.006 ПЗ
тестування), після чого система оцінювалася як єдине ціле з урахуванням
сценаріїв реального використання (системне тестування), а на завершальному
етапі проводилось приймальне тестування разом з представниками цільової
аудиторії. Для серверної частини, реалізованої на NestJS, застосовувався Jest та
Supertest; для перевірки REST-інтерфейсів і поведінки клієнтської частини
використовувалися Postman та end-to-end сценарії в браузері. Усі тести
виконувалися в окремому тестовому середовищі з виділеною тестовою базою
даних PostgreSQL, що унеможливлювало вплив на реальні користувацькі дані.
4.2.1 Модульне тестування
Модульне тестування було спрямоване на перевірку роботи окремих
програмних компонентів у ізоляції від зовнішніх залежностей. Основною ціллю
на цьому етапі було переконатися, що сервіси доменного рівня реалізують
бізнес-правила коректно, а крайні та помилкові випадки обробляються
передбачувано.
У серверній частині окремо тестувалися сервіси AccountsService,
TransactionsService, GroupTransactionsService, BudgetsService, GoalsService,
FxRatesService, ReportsService та NotificationsService. Для кожного з них
створювалися підставні (mock/fake) репозиторії замість реальної роботи з базою
даних, що дозволяло зосередитися саме на логіці обробки даних. Наприклад,
для AccountsService перевірялися сценарії створення рахунку з коректними
параметрами, спроби створення рахунку з некоректним типом або валютою, а
також поведінка при виконанні внутрішніх переказів між рахунками. Для
TransactionsService основними були перевірки валідації суми, наявності
обов’язкових полів, належності рахунку до поточного користувача та
правильності формування запису транзакції.
Результати модульного тестування показали, що основні бізнес-правила
реалізовано коректно, а більшість логічних помилок і некоректних граничних
випадків були виявлені та виправлені ще до інтеграції з реальною базою даних і
клієнтською частиною.
116
ЧДТУ 252482.006 ПЗ
У табл. 4.5 узагальнено приклади модульних тестів для ключових сервісів
системи.
Таблиця 4.5
Приклади модульних тестів доменних сервісів веб-застосунку
Сервіс / модуль Перевірювана Вхідні дані / умова Очікуваний
функція результат
AccountsService Створення Новий рахунок з Створено запис у
рахунку коректною валютою та БД, баланс
початковим балансом дорівнює
початковому
значенню, рахунок
прив’язано до
користувача
AccountsService Переказ між Два рахунки одного Баланс джерела
рахунками користувача, додатна зменшено, балансу
сума одержувача
збільшено на ту
саму суму
TransactionsSer Реєстрація Сума > 0, активний Створено
vice витрати рахунок, валідна транзакцію,
категорія оновлено баланс
рахунку,
TransactionsSer Обробка Сума ≤ 0 або відсутній Транзакція не
vice некоректних рахунок / категорія створюється,
даних генерується
помилка валідації
117
ЧДТУ 252482.006 ПЗ
Продовження таблиці 4.5
GroupTransactio Розподіл Група з n учасників, Створено n часток
nsService витрати загальна сума S S/n, сумарна сума
порівну часток дорівнює S
BudgetsService Розрахунок Для категорії задано Обчислено факт,
план–факт ліміт, у БД є фактичні відхилення, статус
відхилення витрати за період «в межах ліміту»
або «перевищено»
GoalsService Оновлення Новий внесок до цілі Збільшено
прогресу накопичену суму;
фінансової цілі при досягненні
цільового значення
статус →
«досягнута»
FxRatesService Конвертація Сума, валюта-джерело, Повернуто
між валютами валюта-приймач, курс у коректно
exchange_rates перераховану суму
з потрібною
точністю
NotificationsSer Попередження Фактова сума витрат по Створено запис
vice про категорії ≥ 90 % ліміту сповіщення, який
перевищення буде доставлений
бюджету користувачу
4.2.2 Інтеграційне тестування
Інтеграційне тестування було націлене на перевірку правильної взаємодії
між компонентами серверної частини: контролерами, сервісами та
репозиторіями, а також між сервером і тестовою базою даних PostgreSQL. На
118
ЧДТУ 252482.006 ПЗ
цьому етапі система вже запускалась як NestJS-додаток із реальним
підключенням до БД, а тести виконували повні HTTP-запити до REST-
інтерфейсу за допомогою Supertest і Postman.
Типовий інтеграційний сценарій включав створення тестового
користувача, додавання одному або кільком рахункам, реєстрацію набору
транзакцій (доходи, витрати, внутрішні перекази), а потім — виклик ендпоінтів
формування дашборду, бюджетних звітів чи боргових сальдо в групах.
Перевірялися коректність статус-кодів, структура та зміст JSON-відповідей, а
також узгодженість даних у базі (наприклад, відсутність «висячих» записів або
суперечливих балансів).
У табл. 4.6 наведено узагальнені приклади інтеграційних і системних
сценаріїв, які використовувалися для перевірки взаємодії компонентів.
Таблиця 4.6
Узагальнені сценарії інтеграційного та системного тестування
№ Тип Короткий опис
Основний зміст перевірки
сценарію тестування сценарію
1 Інтеграційне Повний цикл Реєстрація користувача,
роботи з створення рахунків, внесення
особистими доходів і витрат, формування
фінансами дашборду
2 Інтеграційне Робота з Створення групи, додавання
груповими учасників, реєстрація групових
витратами транзакцій, отримання
розрахунків «хто кому винен»
3 Інтеграційне Оновлення курсів Запит до мок-API курсів,
валют збереження у exchange_rates,
119
ЧДТУ 252482.006 ПЗ
Продовження таблиці 4.6
4 Системне Сценарій «група Ведення спільних витрат на
квартирантів» оренду та комунальні послуги,
часткове та повне погашення
боргів
5 Системне / Одночасна робота Паралельні запити до тих
навантаж. кількох самих сервісів з різних
користувачів облікових записів, перевірка
відсутності конфліктів та
ушкодження даних
6 Системне Взаємодія з Моделювання помилок
нестабільним зовнішнього API, поведінка
зовнішнім сервісом системи при неможливості
курсів валют отримати актуальний курс
У межах інтеграційних сценаріїв було виявлено кілька типових проблем,
зокрема різночитання форматів дат між клієнтом і бекендом, некоректну
обробку помилок зовнішнього сервісу курсів валют, а також поодинокі ситуації
з невдалими каскадними видаленнями. Після корекції запитів, обробників
помилок та налаштування обмежень цілісності в базі даних система показала
стабільну роботу з повним ланцюгом «клієнт → API → БД».
4.2.3 Системне тестування
Системне тестування розглядало веб-застосунок як єдиний комплекс,
який включає клієнтську частину (браузерний інтерфейс), серверну частину,
базу даних, підсистему сповіщень та інтеграцію із зовнішнім джерелом
валютних курсів. На цьому етапі головною метою було підтвердити, що всі
частини системи коректно працюють разом і реалізовують бізнес-сценарії
користувачів так, як це передбачено вимогами.
120
ЧДТУ 252482.006 ПЗ
Частина системних тестів базувалася на сценаріях, наведених у табл. 4.2,
але з акцентом уже не на технічну реалізацію, а на реальну поведінку
користувача. Наприклад, для сценарію «група квартирантів» оцінювалося не
лише те, чи коректно розраховуються борги в базі даних, а й те, чи інтерфейс
зрозуміло показує кожному учаснику його частку, історію платежів і поточне
сальдо. Аналогічно, для сценарію «щоденне використання» перевірялось, чи не
погіршується продуктивність при накопиченні значного обсягу транзакцій, чи
логічно згруповано інформацію на дашборді та чи не виникає необхідності в
додаткових діях, які користувач не очікував.
На таблиці 4.7 проведені тести та їх результати:
Таблиця 4.7
Таблиця системного тестування
№ Вхідні Очікуваний Фактичний
Назва тексту Опис сценарію
дані результат результат
1 Реєстрація Перевірка Валідний Користувач Відповідає
користувача створення email, успішно очікуванню
нового пароль зареєстрований,
облікового створено
запису профіль
2 Авторизація Вхід у систему Email, Успішний вхід, Відповідає
користувача з коректними пароль доступ до очікуванню
обліковими головної
даними сторінки
3 Створення Додавання Назва Рахунок Відповідає
рахунку нового рахунку, створено та очікуванню
фінансового валюта, відображено в
рахунку баланс системі
121
ЧДТУ 252482.006 ПЗ
Продовження таблиці 4.7
4 Додавання Реєстрація Сума, Доход \витрату Відповідає
доходу\витрат операції категорія, відображено в очікуванню
доходу\витрати дата балансі та
звітах
5 Формування Створення Категорії, Бюджет Відповідає
бюджету бюджету на ліміти створено та очікуванню
період активовано
6 Аналітичні Формування Дані за Звіти коректно Відповідає
звіти графіків та період відображені очікуванню
діаграм
Окремий блок системних тестів був присвячений нефункціональним
вимогам: швидкодія, стабільність, відмовостійкість, коректна реакція на
помилки мережі й зовнішніх сервісів. Моделювалися ситуації з нестабільним
доступом до сервісу курсів валют, перебоями з’єднання з базою даних,
спробами одночасної роботи групи користувачів. Система в усіх цих випадках
повинна була коректно обробляти помилки, не порушуючи цілісності даних і
надаючи користувачеві зрозумілі повідомлення.
Результати системного тестування підтвердили, що проєктований веб-
застосунок відповідає сформованій архітектурі, реалізує всі ключові сценарії
роботи з особистими та груповими фінансами, а також демонструє прийнятні
значення продуктивності й стабільності при типовому навантаженні.
4.2.4 Приймальне тестування
Приймальне тестування проводилося на завершальному етапі розробки з
метою підтвердження відповідності реалізованої системи вимогам замовника і
очікуванням кінцевих користувачів. Воно поєднувало елементи формальної
перевірки за критеріями приймання та неформальної оцінки зручності й
122
ЧДТУ 252482.006 ПЗ
зрозумілості інтерфейсу.
Для приймальних випробувань було сформовано набір критеріїв,
безпосередньо прив’язаних до функціональних і нефункціональних вимог:
підтримка кількох рахунків у різних валютах; ведення бюджетів і фінансових
цілей; реєстрація й розподіл групових витрат; доступність базових аналітичних
звітів; коректність механізмів реєстрації, автентифікації та авторизації;
прийнятний час відгуку інтерфейсу при типовому наборі даних. Перевірка
здійснювалася шляхом програвання сценаріїв за участі представників цільової
аудиторії (студентів, молодих сімей, фрилансерів), які протягом тестового
періоду працювали з системою у своєму звичному режимі.
У табл. 4.8 наведено приклади критеріїв приймального тестування та
узагальнені результати їх оцінювання.
Таблиця 4.8
Критерії приймального тестування та результати їх перевірки
Критерій приймання Метод перевірки / Результат Коментар / відгуки
сценарій перевірки користувачів
Облік доходів і Робота одного Критерій Запропоновано
витрат по кількох користувача з 3–4 виконано додати явний
рахунках у різних рахунками, регулярне фільтр за валютою
валютах внесення транзакцій у списку
транзакцій
Ведення бюджетів за Створення місячного Критерій Користувачам
категоріями з бюджету, внесення виконано сподобався
відображенням витрат, перегляд індикатор «%
план–факт відхилень стану бюджету використання
ліміту»
123
ЧДТУ 252482.006 ПЗ
Продовження таблиці 4.8
Підтримка групових Сценарій «група Критерій Рекомендовано
витрат і прозорого квартирантів» з виконано окремий
розподілу боргів кількома спільними «швидкий» звіт по
витратами боргах кожного
учасника
Зрозумілість Перша сесія роботи Загалом Частині
інтерфейсу для без детальної критерій користувачів
нових користувачів інструкції, виконано знадобилися
спостереження за підказки щодо
діями користувача створення першого
бюджету
Коректна авторизація Спробі доступу до Критерій Несанкціонований
та обмеження API іншого виконано доступ блокується,
доступу до даних користувача / групи повідомлення про
інших користувачів і без належних прав помилку зрозуміле
груп
Продуктивність Замір часу Критерій При великих
основних операцій завантаження виконано обсягах даних
при типовому обсязі дашборду та списків рекомендовано
даних транзакцій при ширше
сотнях–тисячах використовувати
записів пагінацію
Коректна робота Створення штучних Частково Основні
базових сповіщень ситуацій виконано на сповіщення
(перевищення перевищення стартовому працюють,
бюджету, прогрес лімітів, досягнення етапі запропоновано
цілей, групові борги) цілей, накопичення розширити
боргів у тестових налаштування
групах частоти й каналів
124
ЧДТУ 252482.006 ПЗ
За результатами приймального тестування веб-застосунок було визнано
таким, що загалом відповідає вимогам технічного завдання та очікуванням
користувачів. Отримані зауваження стосуються переважно удосконалення
інтерфейсу та розширення налаштовуваних параметрів (фільтри, сповіщення), а
не базової функціональності. Це дає підстави розглядати реалізовану систему як
готову до пілотної експлуатації з можливістю подальшого еволюційного
розвитку.
4.3 Приклади впровадженого програмного комплексу
Для оцінювання практичної придатності розробленого веб-застосунку
було проведено експериментальне впровадження в умовах, наближених до
реального використання. Прототип було розгорнуто на локальному веб-сервері
кафедри, доступному в межах університетської мережі, а також у вигляді
локального інсталяційного пакета (Node.js-додаток з попередньо
сконфігурованим файлом finance.db) для індивідуальних робочих станцій. У
пілотному експерименті взяли участь десять користувачів, які представляли
цільові сценарії системи: студенти, що ведуть особистий бюджет, та невеликі
групи, які ділять спільні витрати (оренда житла, комунальні послуги, спільні
поїздки).
Перед початком експерименту було проведено короткий інструктаж щодо
основних можливостей застосунку й роздано листки із типовими сценаріями,
які учасники мали реалізувати протягом першого дня: створити не менше двох
рахунків (готівка та картка), додати початкові залишки, зафіксувати принаймні
три доходи і п’ять витрат, сформувати одну групу та внести щонайменше дві
групові витрати.
Далі протягом двох тижнів учасники використовували систему у власному
темпі, не обмежуючись заданими сценаріями. На завершення періоду вони
заповнювали анкету, у якій оцінювали зручність інтерфейсу, швидкість
виконання основних дій, зрозумілість звітів і готовність користуватися
застосунком надалі.
125
ЧДТУ 252482.006 ПЗ
У процесі експлуатації веб-застосунок автоматично формував журнали
дій, у яких фіксувалися дата й час операцій, тип виконаної дії (додавання
транзакції, групової витрати, використання конвертера, перегляд звіту), а також
деякі агреговані характеристики (кількість записів у таблицях, середній розмір
транзакції). Це дозволило після завершення експерименту здійснити кількісний
аналіз фактичного використання системи, доповнивши суб’єктивні оцінки
користувачів об’єктивними показниками.
Упродовж двотижневого періоду роботи учасники створили загалом 18
індивідуальних рахунків, 4 групи та внесли 412 особистих транзакцій і 63
групові витрати. Найактивнішими були сценарії повсякденних витрат
(продукти, транспорт, дрібні покупки) та спільних платежів за оренду житла.
Блок інструментів – валютний конвертер, відображення курсів криптовалют і
калькулятори – використовувався рідше, але послідовно: зафіксовано 97
викликів конвертера та близько 40 запусків калькулятора кредиту. Це свідчить
про те, що інструменти відіграють роль допоміжних сервісів, до яких
користувач звертається у специфічних ситуаціях.
Особливий інтерес становило порівняння часу, який користувачі
витрачають на фіксацію однієї операції в традиційних засобах (електронна
таблиця, записник, мобільний калькулятор) і в розробленому веб-застосунку.
Перед початком експерименту учасників попросили виконати невелике
завдання: у звичному для себе інструменті записати п’ять типових витрат і
підрахувати підсумок. Середній час виконання завдання становив 4 хвилини 15
секунд, що приблизно відповідає 51 секунді на одну операцію. Після
двотижневого використання веб-застосунку аналогічне завдання було виконане
прямо в інтерфейсі системи – із додаванням операцій і автоматичним
оновленням підсумків. Середній час у цьому випадку зменшився до 2 хвилин 5
секунд, тобто близько 25 секунд на операцію. Таким чином, навіть на невеликій
вибірці експеримент продемонстрував скорочення часу фіксації транзакцій
майже вдвічі.
Анкетування показало, що найбільше користувачі оцінили можливість
126
ЧДТУ 252482.006 ПЗ
одночасно бачити загальний баланс, структуру витрат за категоріями й окремі
групові розрахунки на одному екрані.
У таблиці 4.9 узагальнено ключові кількісні показники
експериментального впровадження.
Таблиця 4.9
Результати експериментального використання веб-застосунку
Показник Значення
Кількість учасників 10 осіб
Тривалість пілотного періоду 14 днів
Загальна кількість особистих транзакцій 412
Загальна кількість групових витрат 63
Середній час запису однієї операції до експерименту 51 с
Середній час запису однієї операції в системі 25 с
Середня оцінка зручності інтерфейсу (за 5-бальною шкалою) 4,4
Середня оцінка зрозумілості звітів 4,6
Частка користувачів, готових і надалі користуватися системою 80 %
Для учасників, які раніше вели облік в Excel, значною перевагою стала
автоматична категоризація та побудова діаграм без необхідності налаштовувати
формули. Групові функції – особливо автоматичний розрахунок боргів і
можливість за кілька кліків поділити витрати «порівну» або «чесно» відповідно
до внесків різних учасників – зменшили кількість непорозумінь у побутових
ситуаціях. Кілька користувачів відзначили, що завдяки наочному відображенню
частки витрат кожного учасника їм стало простіше домовлятися про спільний
бюджет.
127
ЧДТУ 252482.006 ПЗ
Разом з тим експеримент виявив низку недоліків і напрямів для розвитку
системи. Частина користувачів висловила побажання мати можливість задавати
регулярні транзакції, які автоматично додаються згідно з розкладом (зарплата,
абонплата за інтернет, оренда). Інші запропонували впровадити більш гнучку
фільтрацію й пошук за ключовими словами в описі операцій, а також поділ
категорій на підкатегорії. Було відзначено, що при великій кількості операцій за
один день таблиця стає досить довгою, тому доцільно реалізувати режим
«згортання» записів у щоденні блоки з можливістю розкриття. Окремі
зауваження стосувалися мобільної адаптації: хоча інтерфейс коректно
відображався на планшетах, робота зі смартфона за рахунок обмеженого
розміру екрана була менш зручною, що вказує на необхідність розробки окремої
мобільної версії або прогресивного веб-додатку.
У процесі експлуатації не було зафіксовано критичних збоїв, пов’язаних із
втратою даних або неможливістю доступу до системи. Окремі помилки, які
виникали у користувачів (наприклад, повторне додавання тієї самої операції
через подвійне натискання кнопки), були пов’язані переважно з особливостями
взаємодії й були усунуті шляхом додавання візуальних індикаторів стану й
блокування кнопок на час виконання запиту. Продуктивність сервера навіть при
максимальному навантаженні в межах пілотного експерименту залишалася
прийнятною: час відгуку не перевищував 300 мс, а використання ресурсів
процесора й пам’яті було невисоким, що свідчить про можливість
масштабування системи для більшої кількості користувачів.
Отримані результати дозволяють зробити висновок, що розроблений веб-
застосунок не лише відповідає формальним вимогам, але й виявляється
корисним інструментом у практичній роботі з особистими та груповими
фінансами. Пілотне впровадження показало помітне скорочення часу на
фіксацію операцій, зниження кількості помилок при розрахунках і високий
рівень задоволеності користувачів. Разом з виявленими під час експерименту
побажаннями ці результати формують дорожню карту подальшого розвитку
системи, що включає реалізацію регулярних транзакцій, розширеної фільтрації,
128
ЧДТУ 252482.006 ПЗ
покращеної мобільної версії та, за можливості, інтеграції з банківськими API
для автоматичного імпорту операцій.
129
ЧДТУ 252482.006 ПЗ
Висновок до розділу 4
Четвертий розділ присвячено безпосередній реалізації та верифікації
розробленого веб-застосунку. Було обґрунтовано вибір засобів реалізації (стеку
технологій) та детально описано структурну та логічну схеми програмного
комплексу. Особливу увагу було приділено розробці бази даних, яка забезпечує
гнучкий облік як особистих, так і складних групових витрат із можливістю
зберігання різних частинок розподілу. Комплексне тестування системи, що
включало модульне, інтеграційне, системне та приймальне тестування,
підтвердило її коректність та відповідність вимогам технічного завдання.
Експериментальне впровадження за участю реальних користувачів
продемонструвало практичну ефективність: було зафіксовано істотне
скорочення години на внесення та аналіз фінансових операцій, зменшення
кількості помилок у розрахунках групових витрат та високий рівень
задоволеності інтерфейсом. Ці результати засвідчили, що розроблений веб-
застосунок є ефективним інструментом для підвищення прозрачності
фінансових відносин та формування більш освідомлених фінансових звичок.
130
ЧДТУ 252482.006 ПЗ
ВИСНОВКИ
У ході виконання кваліфікаційної роботи було досягнуто поставленої
мети – теоретично обґрунтовано, спроєктовано та реалізовано веб-застосунок
для управління особистими та груповими фінансами, а також проведено його
комплексне тестування й експериментальне впровадження. Отримані результати
підтвердили актуальність обраної тематики та практичну значущість створеного
програмного продукту для підвищення прозорості й керованості фінансових
рішень користувачів.
У першому розділі було проаналізовано предметну область «персональні
фінанси» в контексті сучасних економічних умов, які характеризуються
високою мінливістю доходів, зростанням ролі безготівкових розрахунків,
широкою доступністю кредитних продуктів та появою нових інструментів
збереження вартості, включно з криптовалютами. Показано, що користувачі
потребують не лише інструментів обліку власних доходів і витрат, але й засобів
прозорого ведення спільного бюджету в межах домогосподарств, невеликих
груп чи проєктних команд. Огляд підходів до бюджетування та фінансового
планування продемонстрував, що класичні схеми «доходи–витрати–
заощадження» та «pay yourself first» можуть бути ефективно підтримані
сучасними інформаційними системами, якщо вони адаптовані до повсякденних
потреб користувача.
У межах огляду існуючих програмних продуктів було виявлено, що
більшість популярних застосунків фокусуються або на індивідуальному обліку
(персональний бюджет, трекінг витрат), або на спрощеному сімейному бюджеті
без розвинутого механізму групових розрахунків. Сервіси на кшталт Splitwise
частково розв’язують задачу розподілу спільних витрат, однак не інтегрують її з
повноцінним персональним обліком, аналітикою та підтримкою
мультивалютності. Це обґрунтувало доцільність створення веб-застосунку, який
у межах єдиної платформи поєднує особисті фінанси, групові фінанси, прості
аналітичні інструменти, валютний та криптовалютний модулі. На основі аналізу
було сформовано вимоги до функціональності, інтерфейсу та якості
131
ЧДТУ 252482.006 ПЗ
програмного забезпечення: підтримка обліку доходів і витрат за категоріями,
ведення кількох рахунків, робота з групами й розподіл витрат між учасниками,
мультивалютність і конвертація, візуалізація структури витрат, прості
калькулятори й зручний, інтуїтивний інтерфейс.
Другий розділ був присвячений формалізації задачі та побудові системи
моделей. Сформовано об’єкт і предмет дослідження, визначено цілі й завдання,
описано методи, які використовувалися на етапах аналізу, проєктування та
тестування. На основі вивчення предметної області побудовано концептуальну
модель системи, яка включає сутності «Користувач», «Рахунок», «Транзакція»,
«Категорія», «Група», «Учасник групи», «Групова витрата», «Частка»,
«Валюта», «Курс валют», а також пов’язані з ними зв’язки. Створено словник
предметної області, що уніфікує терміни й поняття, використані у веб-
застосунку.
За допомогою UML-підходів було змодельовано функціональні та
нефункціональні вимоги у вигляді діаграм варіантів використання, визначено
ключові сценарії взаємодії користувача з системою: ведення особистого
бюджету, створення та облік групових витрат, перегляд звітів, використання
інструментів конвертації та калькуляції. Діаграми класів, компонентів і
розгортання відобразили логічну та фізичну архітектуру майбутнього рішення,
включно з розділенням клієнтської, серверної та базової частин. Поведінкове
моделювання (діаграми діяльності, послідовності, станів) дозволило формально
описати життєві цикли фінансових цілей, процеси додавання транзакцій і
групових витрат, а також обмін повідомленнями між компонентами системи.
Таким чином, у другому розділі було сформовано цілісну модель, яка слугувала
технічною основою для подальшої реалізації.
У третьому розділі на основі побудованих моделей було реалізовано
прототип веб-застосунку. Обґрунтовано вибір технологічного стеку:
HTML5/CSS3/JavaScript для клієнтської частини, Node.js/Express – для
серверної логіки, реляційна СУБД (у прототипі – SQLite із можливістю міграції
до PostgreSQL) – для зберігання даних. Реалізовано серверну частину з набором
132
ЧДТУ 252482.006 ПЗ
REST-ендпойнтів для роботи з рахунками, транзакціями, групами,
інструментами та курсами валют, побудовано структуру бази даних finance.db,
яка відображає концептуальну модель предметної області. Клієнтська частина
представлена односторінковим інтерфейсом із сучасним візуальним стилем,
інтерактивними картками підсумків, таблицями операцій, панеллю групових
фінансів, блоками курсів валют і криптовалют, конвертером та простими
фінансовими калькуляторами.
Комплексне тестування – модульне, інтеграційне, системне та приймальне
– підтвердило коректність реалізації ключових алгоритмів, стабільність роботи
застосунку та відповідність заявленим вимогам. Під час модульного тестування
було перевірено коректність розрахунку балансів, розподілу групових витрат і
конвертації валют. Інтеграційні тести засвідчили правильну взаємодію між
контролерами, сервісами та базою даних, а системні – узгодженість усіх
компонентів у реальних користувацьких сценаріях. Приймальне тестування
показало виконання основних функціональних вимог, а також виявило низку
перспективних напрямів подальшого розвитку (регулярні транзакції, розширені
звіти, краща мобільна адаптація).
Експериментальне впровадження веб-застосунку за участю групи
реальних користувачів продемонструвало його практичну ефективність. Було
зафіксовано істотне скорочення часу, необхідного для внесення та аналізу
фінансових операцій, зменшення кількості помилок у розрахунках групових
витрат, високий рівень задоволеності інтерфейсом і бажання продовжувати
користуватися системою надалі. Отримані кількісні та якісні показники
засвідчили, що запропонований підхід дає можливість підвищити прозорість
фінансових відносин у малих групах, сприяє формуванню більш усвідомлених
фінансових звичок і може стати основою для подальших досліджень у галузі
фінансової грамотності та фінтех-рішень для домогосподарств.
Наукова новизна роботи полягає у комплексному поєднанні моделей
управління особистими та груповими фінансами в межах єдиного веб-
застосунку з підтримкою мультивалютності, інтеграції з зовнішніми сервісами
133
ЧДТУ 252482.006 ПЗ
курсів валют і криптовалют, а також гнучких схем розподілу спільних витрат.
Практичне значення полягає у створенні робочого прототипу програмного
продукту, який може використовуватися як у повсякденному житті (студентами,
молодими сім’ями, невеликими командами), так і в навчальному процесі як
приклад реалізації повного циклу розробки веб-системи – від моделювання до
впровадження й тестування.
Перспективами подальшого розвитку розробленого рішення є поглиблена
інтеграція з банківськими API та платіжними сервісами для автоматичного
імпорту транзакцій, розширення системи звітності (включно з прогнозуванням
на основі історичних даних), реалізація повноцінного мобільного клієнта, а
також використання методів машинного навчання для рекомендацій щодо
оптимізації бюджету. Отримані в роботі результати створюють міцний
фундамент для таких удосконалень і підтверджують доцільність подальших
досліджень у напрямі поєднання програмної інженерії та фінансової
грамотності.
134
ЧДТУ 252482.006 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Кізима Т. О. Фінанси домогосподарств : навч. посіб. – Тернопіль : ТНЕУ,
2014. – 228 с.
2 Смовженко Т. С., Міщенко О. В., Лютий І. В. та ін. Фінансова грамотність.
Фінанси. Що? Чому? Як? : навч. посіб. – Суми : Університетська книга,
2019. – 272 с.
3 Garman T. E., Forgue R. Personal Finance. – 13th ed. – Boston : Cengage
Learning, 2018. – 640 p.
4 Kapoor J. R., Dlabay L. R., Hughes R. J. Personal Finance. – 12th ed. – New
York : McGraw-Hill Education, 2018. – 752 p.
5 Goyal K., Kumar S., Xiao J. J. Antecedents and consequences of personal
financial management behavior: A systematic literature review. International
Journal of Bank Marketing. 2021. Vol. 39, No. 7. P. 1166–1207. (
6 Bitrián P., Buil I., Catalán S. The gamification of personal finance management
apps: Analysis of users’ motivation and attitude. International Journal of Bank
Marketing. 2021. Vol. 39, No. 7. P. 1310–1332. (
7 Stefanov T., Stefanova M., Varbanova S., Temelkov S. Personal Finance
Management Application. TEM Journal. 2024. Vol. 13, No. 3. P. 2066–2075.
8 Makalew B. Android Based Personal Finance Management Application:
Design and Development. EMACS Journal. 2022. Vol. 4, No. 1. P. 5–9.
9 Писаренко В. М., Костенко О. В., Рєзнікова Н. О. Розробка веб-сервісу
динамічного формування прогнозу бюджету домогосподарств на основі
Big Data-технологій. Інформатика та математичні методи в моделюванні.
2021. Т. 11, № 4. С. 326–339.
10 Casciaro M., Mammino L. Node.js Design Patterns: Design and Implement
Production-grade Node.js Applications Using Proven Patterns and Techniques.
– 3rd ed. – Birmingham : Packt Publishing, 2020. – 660 с.
11 Flanagan D. JavaScript: The Definitive Guide: Master the World’s Most-Used
Programming Language. – 7th ed. – Sebastopol : O’Reilly Media, 2020. – 706
p.
135
ЧДТУ 252482.006 ПЗ
12 Fowler M. UML Distilled: A Brief Guide to the Standard Object Modeling
Language. – 3rd ed. – New York : Addison-Wesley, 2004. – 208 p.
13 Sommerville I. Software Engineering. – 10th ed. – Harlow : Pearson, 2015. –
800 p.
14 Spillner A., Linz T., Schaefer H. Software Testing Foundations: A Study Guide
for the Certified Tester Exam ISTQB Foundation Level. – 5th ed. – Rocky
Nook, 2014. – 376 p.
15 ДСТУ 8302:2015. Інформація та документація. Бібліографічне посилання.
Загальні положення та правила складання. – Київ : Мінекономрозвитку
України, 2016. (
16 Fielding R. T. Architectural Styles and the Design of Network-based Software
Architectures : Dissertation. – Irvine : University of California, 2000. – 180 p.
17 Unified Modeling Language Specification. Version 2.5.1 [Електронний
ресурс]. – Object Management Group, 2017. – Режим доступу:
https://www.omg.org/spec/UML/ (дата звернення: 01.12.2025).
18 Object-oriented analysis and design [Електронний ресурс]. – Wikipedia, the
free encyclopedia. – Режим доступу: https://en.wikipedia.org/wiki/Object-
oriented_analysis_and_design (дата звернення: 01.12.2025).
19 React Documentation – Getting Started [Електронний ресурс]. – Meta
Platforms, Inc., 2024. – Режим доступу: https://react.dev/learn (дата
звернення: 01.12.2025).
20 Node.js v20.x Documentation [Електронний ресурс]. – OpenJS Foundation,
2024. – Режим доступу: https://nodejs.org/docs/latest-v20.x/api/ (дата
звернення: 01.12.2025).
136
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедри ПЗАС
проф. Голуб С.В.
___________________________
WEB-ЗАСТОСУНОК ДЛЯ УПРАВЛІННЯ ОСОБИСТИМИ ТА ГРУПОВИМИ
ФІНАНСАМИ
СПЕЦИФІКАЦІЯ
482. ЧДТУ 252482. 01
Листів: 2
Розробник _____________________ Заїка В. В.
Керівник _____________________ Заспа О. Г.
Н.Контроль _____________________ Півень О.Б.
Черкаси 2025
482. ЧДТУ 252482. 01 2
Позначення Найменування Примітка
482. ЧДТУ 252482.00612-01 Код програми
482. ЧДТУ 252482.006 90-01 Графічний матеріал
138
ДОДАТОК Б
WEB-ЗАСТОСУНОК ДЛЯ УПРАВЛІННЯ ОСОБИСТИМИ ТА ГРУПОВИМИ
ФІНАНСАМИ
СПЕЦИФІКАЦІЯ
482. ЧДТУ 252482.00612-01
Листів: 7
Розробник _____________________ Заїка В. В.
Черкаси 2025
482. ЧДТУ 252482.00612-01 2
// public/app.js
// Клієнтська логіка: завантаження даних, робота з формами, діаграми
let accounts = [];
let categories = [];
let currencies = [];
let chartInstance = null;
// Допоміжні функції
async function apiGet(url) {
const res = await fetch(url);
if (!res.ok) throw new Error("HTTP error " + res.status);
return res.json();
}
async function apiPost(url, body) {
const res = await fetch(url, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify(body),
});
if (!res.ok) throw new Error("HTTP error " + res.status);
return res.json();
}
function formatMoney(value) {
return Number(value || 0).toFixed(2);
}
// Завантаження підсумків
140
482. ЧДТУ 252482.00612-01 3
async function loadSummary() {
try {
const data = await apiGet("/api/summary");
document.getElementById("summary-income").textContent =
formatMoney(data.totalIncome);
document.getElementById("summary-expense").textContent =
formatMoney(data.totalExpense);
document.getElementById("summary-balance").textContent =
formatMoney(data.balance);
} catch (err) {
console.error("Помилка отримання підсумків:", err);
}
}
// Завантаження рахунків і категорій (для модалки)
async function loadAccountsAndCategories() {
try {
accounts = await apiGet("/api/accounts");
const accountsSelect = document.getElementById("tx-account");
accountsSelect.innerHTML = "";
accounts.forEach((acc) => {
const opt = document.createElement("option");
opt.value = acc.id;
opt.textContent = `${acc.name} (${acc.currency_code})`;
accountsSelect.appendChild(opt);
});
// категорії беремо разом з транзакціями (щоб не робити окремий ендпойнт),
// у реальному проєкті це окремий запит
} catch (err) {
console.error("Помилка завантаження рахунків:", err);
141
482. ЧДТУ 252482.00612-01 4
}
}
// Завантаження транзакцій і заповнення таблиці
async function loadTransactions() {
try {
const data = await apiGet("/api/transactions?period=current-month");
const tbody = document.querySelector("#transactions-table tbody");
tbody.innerHTML = "";
if (!data.length) {
const tr = document.createElement("tr");
const td = document.createElement("td");
td.colSpan = 6;
td.className = "empty-cell";
td.textContent = "Операцій поки немає. Додайте першу!";
tr.appendChild(td);
tbody.appendChild(tr);
return;
}
// Для діаграми – агрегуємо витрати за категоріями
const expensesByCategory = {};
data.forEach((tx) => {
const tr = document.createElement("tr");
const tdDate = document.createElement("td");
tdDate.textContent = tx.date;
const tdType = document.createElement("td");
142
482. ЧДТУ 252482.00612-01 5
tdType.textContent = tx.type === "income" ? "Дохід" : "Витрата";
const tdCat = document.createElement("td");
tdCat.textContent = tx.category_name;
const tdDesc = document.createElement("td");
tdDesc.textContent = tx.description || "";
const tdAcc = document.createElement("td");
tdAcc.textContent = tx.account_name;
const tdAmount = document.createElement("td");
tdAmount.textContent = `${formatMoney(tx.amount)} ${tx.currency_code}`;
tdAmount.style.color =
tx.type === "income" ? "#4ade80" : "#f97373";
tr.appendChild(tdDate);
tr.appendChild(tdType);
tr.appendChild(tdCat);
tr.appendChild(tdDesc);
tr.appendChild(tdAcc);
tr.appendChild(tdAmount);
tbody.appendChild(tr);
if (tx.type === "expense") {
if (!expensesByCategory[tx.category_name]) {
expensesByCategory[tx.category_name] = 0;
}
expensesByCategory[tx.category_name] += tx.amount_base;
}
});
143
482. ЧДТУ 252482.00612-01 6
updateChart(expensesByCategory);
} catch (err) {
console.error("Помилка завантаження транзакцій:", err);
}
}
// Оновлення діаграми витрат
function updateChart(expensesByCategory) {
const ctx = document.getElementById("expenses-chart").getContext("2d");
const labels = Object.keys(expensesByCategory);
const values = Object.values(expensesByCategory).map((v) =>
Number(v.toFixed(2))
);
if (chartInstance) {
chartInstance.destroy();
}
if (!labels.length) {
chartInstance = null;
ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height);
return;
}
chartInstance = new Chart(ctx, {
type: "doughnut",
data: {
labels,
datasets: [
{
data: values,
144
482. ЧДТУ 252482.00612-01 7
// Chart.js сам підбере кольори, можна залишити дефолт
},
],
},
options: {
plugins: {
legend: {
labels: {
color: "#e5e7eb",
},
},
},
},
});
}
// Завантаження курсів валют
async function loadRates() {
try {
const data = await apiGet("/api/tools/rates");
const list = document.getElementById("rates-list");
list.innerHTML = "";
// Паралельно наповнюємо список валют для конвертера
const convFrom = document.getElementById("co
145
ДОДАТОК В
WEB-ЗАСТОСУНОК ДЛЯ УПРАВЛІННЯ ОСОБИСТИМИ ТА ГРУПОВИМИ
ФІНАНСАМИ
Графічні матеріали
482. ЧДТУ 252482.006 90-01
Листів: 10
Розробник _____________________ Заїка В. В.
Черкаси 2025
482. ЧДТУ 252482.006 90-01 2
Рис. В.1 – Титульний слайд
Рис. В.2 – Акутальність теми
147
482. ЧДТУ 252482.006 90-01 3
3
Рис. В.3 – Мета та завдання роботи
Рис. В.4 – Обєкт та предмет дослідження
148
482. ЧДТУ 252482.006 90-01 4
Рис. В.5 – Діаграма компонентів
Рис. В.6 – Функціональні вимоги системи
149
482. ЧДТУ 252482.006 90-01 5
Рис. В.7 –Архітектурра програмної системи
Рис. В.8 – Інтерфейс користувача
150
482. ЧДТУ 252482.006 90-01 6
Рис. В.9 – Аналіз існуючих рішень
Рис. В.9 – Діаграма комунікації
151
482. ЧДТУ 252482.006 90-01 7
Рис. В.10 – Реалізація системи
Рис. В.11 – Приклад аналізу витрат
152
482. ЧДТУ 252482.006 90-01 8
Рис. В.12 – Тестування та якість ПЗ
Рис. В.13 – Взаємодія з бірржами
153
482. ЧДТУ 252482.006 90-01 9
Рис. В.14 – Наукова та практична цінність
Рис. В.15 – Моделювання та алгоритми
154
482. ЧДТУ 252482.006 90-01 10
Рис. В.16 – Приклад роботи програми
Рис. В.17 –Висновки
155