ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9164| Title: | Мобільний додаток для інтелектуального управління фінансами |
| Authors: | Олексюк, Вадим Володимирович Аніщик, Владислав Станіславович |
| Keywords: | Мобільний додаток;управління особистими фінансами;фінансовий аналіз;оптимізація витрат;бюджетування;обробка фінансових даних |
| Issue Date: | 2025 |
| Abstract: | Виконавець: Аніщик Владислав Станіславович. Назва роботи: "Мобільний додаток для інтелектуального управління фінансами". Спеціальність: 121 Інженерія програмного забезпечення. Навчальний заклад: Черкаський державний технологічний університет, м. Черкаси, 2025р. Бакалаврська робота присвячена розробці мобільного додатку для інтелектуального управління особистими фінансами. Головною метою проекту є реалізація програмного рішення, яке надає користувачам зручний інтерфейс для відстеження доходів та витрат, створення бюджету та отримання фінансової аналітики в режимі реального часу. В рамках роботи було розроблено архітектуру клієнт-серверного додатку з локальним зберіганням даних та синхронізацією через API. Для реалізації основної логіки було використано сучасні засоби мобільної розробки, включаючи технологічний стек React, Node.js, MongoDB, а також модулі для побудови діаграм та візуалізації аналітики. Особливу увагу було приділено оптимізації UI/UX, забезпеченню безпеки персональних даних та обробці фінансових транзакцій. Результатом роботи є повноцінний мобільний додаток, який дозволяє користувачам керувати своїм особистим бюджетом, аналізувати свою фінансову поведінку та підвищувати свою фінансову грамотність. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9164 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Аніщик Владислав.pdf Restricted Access | 1.59 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
бакалавра
на тему: «Мобільний додаток для інтелектуального управління
фінансами»
Виконав: студент 4 курсу, групи ПЗС-2104
спеціальності
121 «Інженерія програмного забезпечення»
Студент Аніщик В. С.
(прізвище та ініціали)
Керівник Олексюк В. В.
(прізвище та ініціали)
Рецензент
(прізвище та ініціали)
Черкаси 2025
Черкаський державний технологічний університет
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС,
д.т.н., професор
__________________Сергій ГОЛУБ
«___» _______________ 2025 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
1. Тема роботи: «Мобільний додаток для інтелектуального управління фінансами»
____________________________________________________________________________
Керівник роботи к.т.н., доцент Олексюк Вадим Володимирович____________________________
Затверджені наказом Черкаського державного технологічного університету №_53/03-03_______
від «25» ______02_____ 2025 року
2. Строк подання студентом роботи _16.06.2025_____________________________________
3. Вхідні дані до роботи: Microsoft Office, Microsoft Word, Windows, Visual Studio Code,
Mongo DB___________________________________________________________________
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
1 Існуючі методи та засоби розв’язання поставлених завдань;______________________________
2 Впровадження результатів досліджень у практику проектування програмного забезпечення
інформаційних систем;______________________________________________________________
3 Розробка та тестування програмного забезпечення;____________________________________
Висновки;_________________________________________________________________________
Список використаних джерел;________________________________________________________
Додатки.__________________________________________________________________________
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;
Додаток А – Специфікація_____________________________________________________
Додаток Б – Текст програми розробки___________________________________________
Додаток В – Інструкція користувачеві___________________________________________
Додаток Г – Графічні матеріали________________________________________________
6. Консультанти розділів роботи
7. Дата видачі завдання «_02_»_____грудня_____2024р.
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№
п/п Назва етапів випускної роботи етапів
кваліфікаційної Примітки
роботи
1 Постановка задачі 03.12.2024 виконано
2 Формування рішень задач 11.12.2024 виконано
3 Погодження завдання 22.12.2024 виконано
Основна стадія
1 Підбір матеріалів 12.02.2025 виконано
2 Аналіз шляхів вирішення поставлених 20.02.2025 виконано
задач
3 Розробка діаграм, як проектного рішення 24.03.2025 виконано
4 Визначення вимог 30.03.2025 виконано
5 Проектування додатку. Розробка 28.04.2025 виконано
інтерфейсної частини
Заключна стадія
1 Узгодження прийнятих проектних рішень 05.05.2025 виконано
з керівником
2 Оформлення пояснювальної записки 16.05.2025 виконано
роботи в кінцевій редакції
3 Попередній захист роботи 19.05.2025 виконано
4 Затвердження роботи 21.05.2025 виконано
5 Рецензування роботи .06.2025 виконано
6 Захист роботи 06.06.2025 виконано
Студент _____________________ Аніщик В. С.
Керівник роботи _____________________ Олексюк В. В.
АНОТАЦІЇ
Виконавець: Аніщик Владислав Станіславович.
Назва роботи: "Мобільний додаток для інтелектуального управління
фінансами".
Спеціальність: 121 Інженерія програмного забезпечення.
Навчальний заклад: Черкаський державний технологічний університет, м.
Черкаси, 2025р.
Бакалаврська робота присвячена розробці мобільного додатку для
інтелектуального управління особистими фінансами. Головною метою проекту є
реалізація програмного рішення, яке надає користувачам зручний інтерфейс для
відстеження доходів та витрат, створення бюджету та отримання фінансової
аналітики в режимі реального часу.
В рамках роботи було розроблено архітектуру клієнт-серверного додатку з
локальним зберіганням даних та синхронізацією через API. Для реалізації основної
логіки було використано сучасні засоби мобільної розробки, включаючи
технологічний стек React, Node.js, MongoDB, а також модулі для побудови діаграм
та візуалізації аналітики. Особливу увагу було приділено оптимізації UI/UX,
забезпеченню безпеки персональних даних та обробці фінансових транзакцій.
Результатом роботи є повноцінний мобільний додаток, який дозволяє
користувачам керувати своїм особистим бюджетом, аналізувати свою фінансову
поведінку та підвищувати свою фінансову грамотність.
Ключові слова: Мобільний додаток, управління особистими фінансами,
фінансовий аналіз, оптимізація витрат, бюджетування, обробка фінансових даних.
ANNOTATIONS
Author: Anishchyk Vladyslav Stanislavovych
Title of the Thesis: "Mobile Application for Intelligent Personal Finance Management"
Specialty: 121 Software Engineering
Educational Institution: Cherkasy State Technological University, Cherkasy, 2025
The Bachelor's proposition is given to the advancement of a portable application
for brilliantly administration of individual accounts. The essential objective of the extend
is to actualize a program arrangement that gives clients a helpful interface for following
pay and costs, making a budget, and getting monetary analytics in real-time.
Inside the scope of the proposition, the engineering of a client-server application
with neighborhood information capacity and synchronization by means of API was
planned. For the execution of the center rationale, advanced versatile improvement
apparatuses were utilized, counting the innovation stack of Respond, Node.js, MongoDB,
and modules for building charts and visualizing analytics. Specific consideration was paid
to optimizing UI/UX, guaranteeing the security of individual information, and preparing
budgetary exchanges.
The result of the work may be a total versatile application that permits clients to
oversee their individual budget, analyze their budgetary behavior, and make strides their
budgetary education.
Keywords: Mobile application, personal finance management[23], financial analysis,
expense optimization, budgeting, financial data processing.
ЗМІСТ
ВСТУП………………………………………………………………………..6
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ………………………………………………………9
1.1 Існуючі методи до розв’язання поставленого завдання……………9
1.2 Огляд аналогів…………………………………………………………10
1.3 Сформовані задачі для проектування………………………………..14
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ………………………………….16
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ……………………………………………………………………………..17
2.1 Моделювання предметної області…………………………………….17
2.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області…………………………………………………..17
2.1.2 Елементи моделювання предметної області…………………….19
2.1.3 Робоча область моделювання…………………………………….20
2.2 Формування та аналіз вимог…………………………………………..21
2.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги………………………………………………………22
2.2.2 Формування вимог за діаграмою прецедентів…………………..26
2.3 Проектування логічної структури програмного комплексу ……….27
2.3.1 Діаграми класів……………………………………………………27
2.3.2 Діаграми пакетів…………………………………………………..30
2.4 Архітектурне проектування…………………………………………...32
2.4.1 Діаграма компонентів……………………………………………..32
ЧДТУ.252353.001 ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб. Аніщик В.С. «Мобільний додаток для Літ. Лист Листів
Перевір. Олексюк В.В. інтелектуального управління фінансами» 3
Рецензент Пояснювальна записка.
Н. Контр. Півень О.Б. ФІТІС, кафедра ПЗАС, ПЗС-2104
Затверд. Голуб С.В.
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання…………………………………………………………………….33
2.5 Моделювання поведінки системи………………………………….....34
2.5.1 Діаграма діяльності……………………………………………….34
2.5.2 Діаграма послідовності…………………………………………...37
2.5.3 Діаграма комунікації……………………………………………...39
2.5.4 Діаграма скінченного автомату…………………………………..41
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ…………………………………...43
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ……………………………………………………………………44
3.1 Розробка програмного комплексу…………………………………….44
3.1.1 Обґрунтування вибору засобів реалізації………………………..44
3.1.2 Опис структурної (функціональної) схеми……………………...46
3.1.3 Опис логічної схеми системи…………………………………….49
3.1.4 Розробка бази даних………………………………………………51
3.1.5 Розробка інтерфейсу користувача………………………………..54
3.1.6 Опис розробки програмних компонентів………………………..58
3.2 Тестування системи……………………………………………………60
3.2.1 Модульне тестування……………………………………………..60
3.2.2 Інтеграційне тестування…………………………………………..66
3.2.3 Системне тестування……………………………………………...68
3.2.4 Приймальне тестування…………………………………………..70
3.3 Приклади впровадженого програмного комплексу…………………72
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ………………………………….75
ВИСНОВКИ…………………………………………………………………..76
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ…………………………………….78
Додаток А……………………………………..……………………………….80
Додаток Б……………………………………………………………………....82
Додаток В……………………………………………………………………...96
Додаток Г……………………………………………………………………...104
ЧДТУ.252353.001 ПЗ
Змн. Арк. № докум. Підпис Дата
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
UI – Інтерфейс користувача
UX – Досвід користувача
API – Інтерфейс прикладного програмування
REST – Стиль API для обміну відомостями між клієнтом і
сервером
CSS – Каскадні таблиці стилів
JSON – формат обміну даними та додатком і сервером
MongoDB – Документоорієнтована база даних NoSQL, яка зберігає
дані у форматі BSON (JSON-подібний формат)
Database – База даних, де зберігається інформація для WEB–
сайту
Node.js – Платформа для запуску JavaScript на сервері
Backend – Частина Мобільного додатку, відповідальна за логіку та
обробку даних
ЧДТУ.252353.001 ПЗ
ВСТУП
Актуальність теми. Розробка програмного забезпечення інформаційних
технологій набуває особливої актуальності в умовах сучасного цифрового
суспільства, де все більше людей прагнуть раціонально керувати своїми доходами
та витратами. Традиційні інструменти, такі як паперові записи або електронні
таблиці, часто є незручними й не дозволяють сформувати повну картину
фінансового стану. Це зумовлює потребу у створенні мобільних застосунків, які
автоматизують фінансове планування, забезпечують зручність у повсякденному
користуванні та адаптуються до індивідуальних потреб користувача.
Мета і завдання розробки. Метою є розробити мобільний додаток для
інтелектуального управління особистими фінансами, який дозволить користувачам
зручно вести облік доходів і витрат, аналізувати фінансову активність, планувати
бюджет та підвищувати рівень фінансової обізнаності.
Завдання:
− проаналізувати існуючі рішення в галузі фінансового планування та
визначити їх сильні й слабкі сторони;
− спроєктувати архітектуру мобільного застосунку з використанням
сучасних технологій та інструментів;
− реалізувати функціонал:
− додавання та редагування фінансових транзакцій;
− автоматична категоризація витрат і доходів;
− побудова графіків і діаграм для фінансової аналітики;
− відображення статистики у зручному для користувача вигляді;
− синхронізація даних з віддаленим сервером через API;
− забезпечити безпеку даних користувача, включаючи шифрування та
захист персональної інформації;
7
ЧДТУ.252353.001 ПЗ
− розробити інтерфейс користувача (UI/UX), орієнтований на простоту,
зручність та інтуїтивність.
− протестувати додаток для перевірки коректності роботи всіх функцій у
різних сценаріях використання.
Об’єкт розробки. Об’єктом розробки є мобільний застосунок, орієнтований
на персональне бюджетування, аналіз витрат та оптимізацію
фінансової поведінки користувача.
Предмет розробки. Предметом розробки є технічне рішення, що реалізує
функціональність мобільного додатку з метою підвищення ефективності
управління особистим бюджетом користувача.
Методи проектування та конструювання. Під час розробки мобільного
додатку для інтелектуального управління фінансами було використано такі сучасні
методи проектування та конструювання програмного забезпечення:
− об’єктно-орієнтований підхід (ООП): Застосовано при побудові
архітектури клієнтської та серверної частини для забезпечення
модульності, повторного використання коду та легкого супроводу.
− компонентно-модульне проектування. Кожен функціональний блок
(облік транзакцій, аналітика, звіти, синхронізація з сервером тощо)
реалізовано у вигляді незалежного модуля, що спрощує масштабування
системи.
− MVC (Model-View-Controller): Відокремлення бізнес-логіки (Model),
інтерфейсу користувача (View) та обробників подій (Controller)
підвищило структурованість коду.
− розробка RESTful API : Для ефективної взаємодії клієнта з сервером
застосовано REST-архітектуру, яка забезпечує просту та масштабовану
обробку запитів і відповідей.
8
ЧДТУ.252353.001 ПЗ
− прототипування UI/UX: Створення інтерактивних прототипів
інтерфейсу перед реалізацією з метою підвищення зручності
користування додатком.
− тестування під час розробки (TDD/інтеграційне тестування):
Здійснювалася поетапна перевірка взаємодії компонентів додатку для
виявлення логічних і функціональних помилок.
− інструменти CI/CD:. Впровадження безперервної інтеграції (Continuous
Integration) дозволяло швидко перевіряти та розгортати
зміни на сервері.
Опис отриманих результатів
У результаті виконання бакалаврської кваліфікаційної роботи було створено
повнофункціональний мобільний додаток для інтелектуального управління
особистими фінансами, побудовано клієнт-серверну архітектуру з використанням
технологій React js для клієнтської частини та Node.js з MongoDB для серверної
логіки та бази даних. Забезпечено збереження та синхронізацію даних між
пристроєм та сервером, реалізовано основні функціональні модулі, розроблено
зручний інтерфейс користувача (UI/UX), проведено модульне, інтеграційне та
системне тестування функціональних компонентів для забезпечення надійності
роботи додатку. Тестування підтвердило коректну взаємодію компонентів і
відсутність критичних помилок.
Практичне значення отриманих результатів
Практичне значення розробленого мобільного додатку для інтелектуального
управління фінансами полягає в його здатності ефективно вирішувати повсякденні
завдання користувачів, пов’язані з контролем та плануванням особистих фінансів:
− покращення фінансової дисципліни користувача: Додаток дозволяє
регулярно фіксувати доходи й витрати, що сприяє більш усвідомленому
підходу до витрат і формує відповідальні фінансові звички.
9
ЧДТУ.252353.001 ПЗ
− швидкий аналіз фінансового стану: Завдяки інтегрованим аналітичним
інструментам (графікам, звітам, категоріям витрат) користувачі можуть
миттєво оцінювати поточну ситуацію з бюджетом і приймати
обґрунтовані фінансові рішення.
− можливість персонального планування: Реалізовані функції фінансових
цілей, лімітів витрат і нагадувань дозволяють користувачу краще
планувати майбутні витрати, уникати надмірних витрат і накопичувати
заощадження.
− доступність на мобільних пристроях: Завдяки мобільному формату
додаток є постійно доступним для користувача в будь-який час і в будь-
якому місці, що забезпечує зручність і оперативність ведення обліку.
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
У сучасному цифровому середовищі персональне фінансове планування
стало невіддільною складовою ефективного управління ресурсами. З огляду на
стрімкий розвиток інформаційних технологій, зокрема мобільних платформ,
зростає попит на інтелектуальні програмні рішення, які дозволяють користувачам
не лише вести облік доходів і витрат, а й отримувати аналітичну інформацію,
прогнозування та рекомендації щодо оптимізації бюджету.
Цей розділ присвячений огляду сучасних підходів у сфері інформаційних
технологій, які використовуються при створенні мобільних застосунків для
фінансового управління. У процесі дослідження були проаналізовані наукові
публікації, навчальні ресурси з ІТ-дисциплін, технічна документація, а також
приклади популярних рішень на ринку FinTech.
1.1 Існуючі методи до розв’язання поставленого завдання
Для створення мобільного додатку, що дозволяє ефективно управляти
особистими фінансами, існує ряд перевірених методів і підходів. Ці методи
10
ЧДТУ.252353.001 ПЗ
охоплюють як технічну реалізацію клієнт-серверної архітектури, так і логіку
обробки фінансових даних користувача. Найбільш поширеними є такі підходи:
− методи введення та зберігання фінансових даних - Зазвичай реалізуються
через локальну базу даних (наприклад Mongo DB). Це дозволяє додатку
працювати в офлайн-режимі та синхронізуватися з сервером при
наявності інтернету;
− категоризація витрат і доходів - Застосовується ручне або автоматичне
розпізнавання категорії транзакції на основі шаблонів (наприклад,
ключових слів або merchant code);
− методи візуалізації фінансових даних - Для зручності користувача
фінансова інформація часто подається у вигляді кругових або
стовпчикових діаграм, графіків змін у часі, а також таблиць.
Використовуються бібліотеки типу Chart.js;
− фінансова аналітика - Базується на агрегуванні витрат, розрахунку
середніх значень, виявленні тенденцій. Додатки можуть оцінювати
фінансову активність користувача за день, тиждень, місяць або квартал.
1.2 Огляд аналогів
На ринку мобільних додатків існує багато прикладів застосунків для
інтелектуального управління особистими фінансами, серед яких:
1.2.1 Mint (Intuit)
Переваги:
− безкоштовний доступ до основного функціоналу;
− автоматичне підключення до банківських рахунків (у США);
− детальна категоризація витрат;
− графіки, звіти, кредитний рейтинг, фінансові поради.
Недоліки:
− обмежена підтримка для користувачів за межами США;
− часті рекомендації продуктів Intuit (реклама);
11
ЧДТУ.252353.001 ПЗ
− повільне оновлення деяких транзакцій.
Рисунок 1.1 – Вигляд сайту Mint [1]
1.2.2 You Need a Budget (YNAB)
Переваги:
− філософія «бюджетування кожного долара» - допомагає навчитися
фінансовій дисципліні;
− зручний інтерфейс для ручного планування;
− підтримка синхронізації з банками (переважно США);
− освітні ресурси та вебінари.
Недоліки:
− Платний (близько $99/рік після безкоштовного пробного періоду);
− Вимагає часу на налаштування та звикання до методики;
− Часткова автоматизація, багато що вводиться вручну.
12
ЧДТУ.252353.001 ПЗ
Рисунок 1.2 – Вигляд сайту You Need a Budget [2]
1.2.3 Monobank (UA)
Переваги:
− інтуїтивно зрозумілий інтерфейс;
− миттєві повідомлення про витрати;
− вбудована аналітика витрат і кешбек;
− підтримка розстрочки, депозитів, валютного обміну.
Недоліки:
− обмеження тільки на власні картки Monobank;
− відсутність розширеного фінансового планування;
− не підходить для багатьох валют чи джерел доходу.
13
ЧДТУ.252353.001 ПЗ
Рисунок 1.3 – Вигляд сайту monobank.ua [3]
1.2.4 Spendee
Переваги:
− підтримка мультивалютності;
− можливість створювати спільні бюджети (напр., для сім’ї);
− інтеграція з банками в Європі (у платній версії);
− добре продуманий візуальний інтерфейс.
Недоліки:
− обмежена функціональність у безкоштовній версії;
− інтеграція з банками доступна лише у преміум-планах;
− часто потребує ручного введення витрат.
14
ЧДТУ.252353.001 ПЗ
Рисунок 1.4 – Вигляд сайту Spendee [4]
1.2.5 Monefy
Переваги:
− мінімалістичний та швидкий інтерфейс;
− придатний для щоденного обліку витрат вручну;
− легка синхронізація між пристроями (через Google Drive);
− не потребує доступу до банківських даних.
Недоліки:
− відсутність автоматичної інтеграції з банками;
− обмежена аналітика;
− не підходить для складного фінансового планування.
15
ЧДТУ.252353.001 ПЗ
Рисунок 1.5 – Вигляд сайту monefy.ua [5]
1.3 Сформовані задачі для проектування
У процесі розробки мобільного додатку для інтелектуального управління
особистими фінансами були сформульовані такі основні задачі, які необхідно було
вирішити на етапі проектування:
− розробка структури даних для зберігання транзакцій - Необхідно
створити зручну і гнучку модель даних для обліку доходів і витрат, що
містить інформацію про суму, категорію, дату, валюту, тип операції та
додаткові коментарі користувача;
− проектування архітектури клієнт-серверної взаємодії - Передбачає
побудову API для обміну даними між мобільним додатком і сервером, з
16
ЧДТУ.252353.001 ПЗ
урахуванням авторизації, синхронізації та безпечного зберігання
персональної інформації;
− інтерфейс користувача (UI/UX) - Необхідно створити інтуїтивно
зрозумілий та зручний інтерфейс, що дозволить користувачам швидко
вводити транзакції, переглядати аналітику та керувати фінансовими
цілями;
− реалізація модуля аналітики - Сформувати логіку для підрахунку
загальної суми витрат та доходів за заданий період, а також побудови
графіків, які ілюструють фінансову активність користувача;
− безпека та захист персональних даних - Передбачити шифрування
збережених фінансових записів і реалізацію захищеної автентифікації
користувача;
− розробити адаптивний та інтуїтивно зрозумілий інтерфейс
користувача - який працює як на смартфонах, так і на планшетах,
забезпечуючи комфортну взаємодію незалежно від типу пристрою.
Таким чином, сформовані задачі охоплюють повний цикл розробки
програмного забезпечення — від збору вимог і моделювання до реалізації
функціоналу та забезпечення якості взаємодії з кінцевим користувачем. Реалізація
цих задач дозволить створити надійний, функціональний та зручний мобільний
застосунок для ефективного управління особистими фінансами.
17
ЧДТУ.252353.001 ПЗ
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ
У першому розділі було розглянуто актуальність розробки мобільного
додатку для інтелектуального управління особистими фінансами. З огляду на
сучасні виклики, пов’язані з фінансовою нестабільністю та великою кількістю
витрат, потреба у зручних і надійних цифрових інструментах для контролю за
особистим бюджетом постійно зростає.
Було проаналізовано сучасні підходи до фінансового планування,
особливості мобільних застосунків у цій сфері, а також переваги використання
новітніх технологій у програмній реалізації таких систем. Особливу увагу
приділено огляду функціоналу популярних фінансових застосунків, визначено їхні
сильні сторони та недоліки, що дозволяє краще сформулювати вимоги до власного
проєкту.
На основі проведеного аналізу було сформовано перелік задач, які необхідно
реалізувати в процесі проєктування та створення мобільного додатку, зокрема:
введення і облік транзакцій, побудова фінансової аналітики, збереження даних,
синхронізація з сервером, безпека даних і зручність користування.
Таким чином, результати цього розділу стали основою для формування вимог
до майбутнього застосунку та визначення архітектурних і функціональних рішень,
які будуть реалізовані в наступних етапах розробки.
16
ЧДТУ.252353.001 ПЗ
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕННЯ У
ПРАКТИКУ ПРОЕТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
2.1 Моделювання предметної області
Моделювання предметної області є ключовим етапом у процесі розробки
програмного забезпечення, оскільки дозволяє формалізувати розуміння реальних
процесів, які система повинна підтримувати. У рамках цієї роботи предметною
областю є процеси особистого фінансового планування користувача - облік доходів
та витрат, аналіз фінансової активності, формування бюджету та прогнозування
залишку коштів. Всі діаграми проектувалися за допомогою сайту
https://app.diagrams.net/ [6]
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області
Предметна область моделювання
Предметна область моделювання охоплює всі процеси, пов’язані з особистим
фінансовим плануванням користувача, які реалізуються за допомогою мобільного
застосунку. Основна мета – надати користувачу інструменти для контролю доходів,
витрат, аналізу фінансової поведінки та досягнення поставлених фінансових цілей.
У цій предметній області виділяються такі ключові компоненти:
− користувач - Особа, яка взаємодіє з мобільним застосунком. Має
індивідуальний обліковий запис, доступ до персоналізованої інформації,
таких як історія транзакцій, бюджет, статистика тощо;
− транзакція - Будь-який фінансовий запис, який створює користувач. Має
такі атрибути: тип (дохід/витрата), сума, категорія, дата, примітка,
валюта. Транзакції є основою для аналізу бюджету;
− категорія - Кожна транзакція належить до певної категорії (наприклад:
«Їжа», «Транспорт», «Зарплата», «Розваги»). Це дозволяє системі
автоматично групувати витрати й доходи;
17
ЧДТУ.252353.001 ПЗ
− бюджет - Ліміти, які користувач встановлює для себе або певних
категорій витрат. Система відслідковує виконання плану та попереджає
про перевищення;
− аналітика - Модуль, що обробляє інформацію про транзакції та формує:
− графіки витрат/доходів
− фінансові звіти
− прогнози залишку коштів
Модель предметної області
Модель предметної області описує основні сутності, зв’язки між ними та
їхню взаємодію в рамках мобільного додатку для управління особистими
фінансами. Вона формується для того, щоб забезпечити чітке уявлення про логіку
роботи системи та визначити ключові компоненти, що мають бути реалізовані під
час розробки.
Основні сутності моделі:
Користувач (User)
- ID користувача;
- ім’я, email, пароль;
- валюта за замовчуванням;
- налаштування бюджету.
Транзакція (Transaction)
- ID транзакції;
- тип: «дохід» або «витрата»;
- сума;
- категорія;
- дата;
- примітка;
- прив’язка до користувача.
Бюджет (Budget)
18
ЧДТУ.252353.001 ПЗ
- місячний ліміт;
- ліміти на категорії;
- прогрес виконання;
- прив’язка до користувача.
Аналітика (Analytics)
- обчислені суми витрат/доходів;
- діаграми;
- прогноз залишку бюджету;
- поради щодо економії.
Словник предметної області
Словник предметної області слугує для уніфікації термінології в технічній
документації, проектуванні, реалізації та тестуванні системи. Він забезпечує
узгоджене розуміння між усіма учасниками розробки та користувачами системи.
До словника предметної області можна віднести: користувач, транзакція,
категорія, бюджет, баланс, аналітика, графік, рекомендація, фінансова мета, дохід,
витрата, інтерфейс користувача (UI), досвід користувача (UX), авторизація.
2.1.2 Елементи моделювання предметної області
Моделювання предметної області - це процес виявлення та формалізованого
опису основних об'єктів системи, їх атрибутів, поведінки та взаємозв’язків у рамках
інформаційної системи. Воно дозволяє глибше зрозуміти логіку функціонування
майбутнього програмного забезпечення, відобразити реальні потреби користувача
та структурувати ключові бізнес-процеси у вигляді моделей.
У контексті мобільного додатку для інтелектуального управління фінансами
предметна область охоплює такі сутності, як користувачі, транзакції, категорії,
бюджети та фінансові звіти. Елементи моделювання, зокрема діаграми класів,
випадків використання та діяльності, дозволяють сформувати логічну структуру,
яка охоплює всі основні процеси: реєстрацію користувача, введення доходів і
витрат, створення цілей, перегляд аналітики, управління бюджетом тощо.
19
ЧДТУ.252353.001 ПЗ
Таке моделювання виступає основою для подальших етапів проєктування —
реалізації функціональних модулів, побудови інтерфейсу користувача (UI),
розробки архітектури бази даних та API-зв’язків між клієнтом і сервером.
Рисунок 2.1 – Елементи мови UML
2.1.3 Робоча область моделювання
Робоча область моделювання визначає простір, у межах якого відбувається
аналіз, проектування та реалізація системи. Вона включає всі функціональні
складові, що взаємодіють між собою для досягнення цілей користувача в системі.
20
ЧДТУ.252353.001 ПЗ
Для мобільного додатку з інтелектуального управління фінансами робоча область
моделювання охоплює як клієнтську, так і серверну частини системи, а також
канали передачі даних між ними.
Основні складові робочої області:
Клієнтська частина (Frontend):
- інтерфейс користувача (UI): екран входу, додавання транзакцій, перегляд
графіків, фінансові цілі тощо;
- валідація даних: перевірка введеної інформації на відповідність типам
(сума, дата, категорія);
- локальне збереження (кешування): тимчасове зберігання даних,
доступних без інтернету;
- взаємодія з API: запити до серверної частини для отримання та оновлення
даних.
Серверна частина (Backend):
- обробка запитів від клієнта (REST API);
- робота з базою даних (MongoDB): створення, читання, оновлення,
видалення транзакцій, категорій, цілей тощо;
- сервіси: модулі обробки даних, зокрема аналітики та генерації порад.
База даних:
- таблиці/Колекції: користувачі, транзакції, категорії, цілі, налаштування;
- відповідність між сутностями згідно з ER-моделлю.
Мережеві з'єднання:
- синхронізація між пристроєм користувача та сервером;
- захищене з’єднання HTTPS;
- обробка помилок у випадку втрати з’єднання (offline mode).
2.2 Формування та аналіз вимог
У цьому підрозділі розглядається процес визначення функціональних та
нефункціональних вимог до мобільного застосунку, що є критичним етапом
проєктування програмного забезпечення. Якісно сформульовані вимоги
21
ЧДТУ.252353.001 ПЗ
забезпечують основу для ефективного розроблення, тестування та оцінювання
готового продукту.
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
Формування вимог до програмного забезпечення
Формування вимог до програмного забезпечення є одним із найважливіших
етапів у процесі розробки мобільного додатку. Саме на цьому етапі закладається
фундамент функціональних можливостей, технічних характеристик та очікувань
кінцевих користувачів щодо роботи застосунку. Як майбутній інженер
програмного забезпечення, я розумію, що правильно сформульовані вимоги
дозволяють уникнути помилок, знизити ризики під час реалізації та спростити
супровід системи.
Первинні вимоги. Первинні вимоги - це загальні очікування до
функціональності мобільного застосунку, сформовані на основі аналізу проблеми,
цілей користувачів і дослідження аналогічних систем. Вони дають загальне
уявлення про те, що має виконувати система без деталізації реалізації.
До первинних вимог належать:
− наявність реєстрації та авторизації користувача;
− можливість додавання доходів і витрат вручну;
− категоризація транзакцій;
− формування фінансових звітів та графіків;
− збереження даних локально з подальшою синхронізацією на сервер;
− наявність інтерфейсу з простим і доступним дизайном;
− можливість переглядати історію транзакцій;
− функціонування без підключення до мережі;
− захист персональних даних користувача.
22
ЧДТУ.252353.001 ПЗ
Детальні вимоги. Детальні вимоги — це уточнені технічні та функціональні
характеристики, що описують конкретну поведінку системи, інтерфейсні елементи,
сценарії взаємодії користувача, способи обробки даних.
Таблиця 2.2
Таблиця детальних вимог
№ Опис вимоги Тип
1 При запуску додатка користувач має пройти Функціональна
авторизацію або реєстрацію
2 Додаток повинен дозволяти вносити витрати з Функціональна
вказанням дати, суми, категорії
3 Категорії витрат мають бути редаговані або Функціональна
створювані вручну
4 Система має відображати звіт за Функціональна
день/тиждень/місяць у вигляді діаграми
5 При відсутності інтернету всі операції мають Нефункціональна
зберігатися в локальній базі
6 Синхронізація відбувається автоматично при Функціональна
з’єднанні з мережею
7 Час відгуку на дії користувача не повинен Нефункціональна
перевищувати 0.5 секунди
Вимоги замовника. Вимоги замовника формуються з точки зору кінцевого
користувача — тобто звичайної людини, яка хоче контролювати свої фінанси. Ці
вимоги мають на меті забезпечити зручність, доступність та ефективність
застосунку в реальних умовах використання.
Вимоги розробника. Основні вимоги замовника до Мобільного додатку для
інтелектуального управління фінансами:
23
ЧДТУ.252353.001 ПЗ
− інтуїтивно зрозумілий інтерфейс - простота у користуванні навіть без
спеціальної підготовки;
− швидкий доступ до основних функцій - додавання доходів, витрат,
перегляд статистики;
− наявність аналітики - діаграми, графіки та поради для оптимізації витрат;
− можливість встановлення фінансових цілей - планування накопичень або
обмеження бюджету;
− безпечне зберігання даних - шифрування та захист від несанкціонованого
доступу;
− синхронізація з хмарою або сервером - доступ до даних з різних
пристроїв.
Вимоги розробника - розробник формулює технічні вимоги, які враховують
обмеження технологій, вибраний стек, архітектуру застосунку, безпеку та
масштабованість.
Основні вимоги розробника до мобільного додатку для інтелектуального
управління фінансами:
− кросплатформенність: використання React Native або іншої технології для
Android/iOS;
− чітко розмежована архітектура: зокрема MVC або MVVM для гнучкості
коду;
− збереження даних у локальній базі (наприклад, Mongo DB): для офлайн-
доступу;
− впровадження авторизації з токенами (JWT): для безпечного доступу до
персоналізованих функцій;
− легке розширення функціоналу: модульна структура коду.
24
ЧДТУ.252353.001 ПЗ
Функціональні вимоги. Функціональні вимоги визначають, що саме має
робити додаток. Вони описують конкретні функції, які повинні бути реалізовані
для досягнення мети застосунку.
Основні функціональні вимоги до Мобільного додатку для інтелектуального
управління фінансами:
Реєстрація та авторизація користувачів:
– можливість створення облікового запису;
– вхід через логін/пароль;
– скидання пароля.
Додавання та редагування транзакцій:
– внесення доходів та витрат;
– вибір категорії (їжа, транспорт, тощо);
– встановлення дати, валюти та опису.
Формування фінансового звіту:
– побудова графіків та діаграм витрат;
– статистика по категоріях та днях.
Планування бюджет:
– встановлення лімітів на витрати;
– нагадування про перевищення бюджету.
Нефункціональні вимоги. Нефункціональні вимоги описують як має
працювати система, тобто характеристики, що не пов’язані з конкретною
функціональністю, але є критично важливими для зручності, продуктивності та
безпеки.
Основні нефункціональні вимоги до Мобільного додатку для
інтелектуального управління фінансами:
Продуктивність:
– час завантаження додатку не більше 3 секунд;
– реакція на введення користувача — не більше 200 мс.
Безпека:
– захист персональних даних користувача;
25
ЧДТУ.252353.001 ПЗ
– шифрування при збереженні даних (наприклад, AES-256);
– використання HTTPS для передачі даних.
Зручність:
– інтерфейс має бути адаптований до користувачів без технічного досвіду;
– легкий доступ до основних функцій у 2–3 кліки.
Сумісність:
– підтримка Android (версія 8 і вище) та iOS (версія 12 і вище);
– адаптивність під різні розміри екранів.
Масштабованість:
– можливість додавання нових функцій без значної перебудови
архітектури.
2.2.2 Формування вимог за діаграмою прецедентів
Діаграма прецедентів (Use Case Diagram) дозволяє візуалізувати взаємодію
між користувачем (актором) та системою через опис сценаріїв використання
(прецедентів). Це зручний спосіб структурувати функціональні вимоги до
програмного забезпечення.
Керуючись вимогами до системи, була побудована діаграма прецедентів
(рисунок 2.2).
26
ЧДТУ.252353.001 ПЗ
Рисунок 2.2 – Діаграма прецедентів для мобільного додатку для
інтелектуального управління особистими фінансами
Опис діаграми прецедентів:
Зареєструватися/Увійти:
– актори: Користувач;
– опис: Користувач реєструється або входить в додаток.
Додайте дохід:
– актори: Користувач;
– опис: Користувач може зазначити джерело доходу або витрату.
Встановити бюджет:
– актори: Користувач;
– опис: Користувач зазначає розмір суми або витрати.
Переглянути статистику:
– актори: Користувач;
– опис: Користувач переглядає та аналізує статистику у вигляді списку
з витратами або джерелами доходу.
27
ЧДТУ.252353.001 ПЗ
2.3 Проектування логічної структури програмного комплексу
Логічна структура програмного забезпечення описує внутрішню
організацію компонентів додатку без прив’язки до конкретної реалізації (тобто без
фізичних серверів, баз даних або коду). Вона визначає, як саме дані і логіка
взаємодіють у межах системи.
Логічна структура дає змогу забезпечити модульність та масштабованість
додатку. Завдяки чіткому поділу на шари (UI, логіка, збереження даних), розробка,
тестування та подальша підтримка програмного продукту стає більш ефективною.
Така структура дозволяє легко адаптувати систему до нових вимог або інтегрувати
нові сервіси.
2.3.1 Діаграми класів
Діаграма класів є структурною UML-діаграмою, яка відображає класи
системи, їхні атрибути, методи (функції), а також зв’язки між класами. Вона
використовується для проектування логічної структури програмного забезпечення.
У рамках цієї бакалаврської роботи діаграма класів була побудована для
відображення основних сутностей мобільного додатку для інтелектуального
управління фінансами, зокрема: користувачів, транзакцій, категорій, бюджетів та
звітів. Кожен з класів містить необхідні поля для збереження даних та методи для
виконання відповідних операцій (створення, редагування, видалення тощо).
Дана діаграма дозволяє візуально представити, як об'єкти взаємодіють між
собою, забезпечує розуміння структури додатку на ранніх етапах розробки та
полегшує подальше впровадження та підтримку системи. Зокрема, вона стала
основою для розробки бази даних, контролерів та бізнес-логіки, забезпечуючи
модульність та масштабованість архітектури застосунку.
28
ЧДТУ.252353.001 ПЗ
Рисунок 2.2 – Діаграма класів «Мобільного додатку для інтелектуального
управління особистими фінансами»
29
ЧДТУ.252353.001 ПЗ
Рисунок 2.3 – Діаграма класів «Мобільного додатку для інтелектуального
управління особистими фінансами»
Опис діаграми класів додатку:
Клас User має такі атрибути:
– UserId: - унікальний ідентифікатор користувача в системі;
– Name: - ім’я користувача, що відображається в інтерфейсі;
– Email: - електронна пошта користувача, яка використовується для входу
та відновлення доступу;
– PasswordHash: - зашифрований пароль для забезпечення безпеки;
– Currency: - валюта, обрана користувачем (наприклад, "UAH", "USD").
Клас Transaction має такі атрибути:
– TransactionId: - унікальний ідентифікатор транзакції;
– UserId: - зв'язок з користувачем, який створив транзакцію;
– Type: - тип транзакції: дохід або витрата;
– Amount: - сума фінансової операції;
30
ЧДТУ.252353.001 ПЗ
– Category: - категорія транзакції (їжа, транспорт тощо);
– Date: - дата створення транзакції;
– Note: - додатковий опис або коментар до транзакції.
Клас Category має такі атрибути:
– CategoryId: - унікальний ідентифікатор категорії;
– UserId: - посилання на користувача, якому належить категорія;
– Name: - назва категорії (наприклад, "Їжа", "Зарплата");
– Type: - тип категорії: дохід або витрата.
Клас Budget має такі атрибути:
– BudgetId: - унікальний ідентифікатор бюджету;
– UserId: - користувач, якому належить бюджет;
– TotalAmount: - загальна сума, виділена на певний період;
– StartDate: - дата початку дії бюджету;
– EndDate: - дата завершення бюджету.
Клас Budget має такі атрибути:
– ReportId: - унікальний ідентифікатор звіту;
– UserId: - користувач, для якого створено звіт;
– GeneratedAt: - дата і час генерації звіту;
– Data: - структура з аналітичною інформацією про фінансову
активність (суми, категорії, графіки тощо).
2.3.2 Діаграми пакетів
Діаграма пакетів (Package Diagram) використовується для візуалізації
логічної структури системи, поділеної на окремі функціональні модулі (пакети).
Вона демонструє взаємозв’язки між різними частинами програмного забезпечення.
Діаграму пакетів системи можна побачити на рисунку 2.4.
Основні пакети для мобільного додатку інтелектуального управління
фінансами:
Пакет Автентифікація:
– відповідає за реєстрацію та авторизацію користувачів;
– залежить від пакету База Даних.
31
ЧДТУ.252353.001 ПЗ
Пакет Транзакції:
– обробка доходів і витрат;
– імпортує Категорії , взаємодіє з Репорти.
Пакет Категорії :
– визначення і класифікація витрат/доходів;
– використовується у Транзакції.
Пакет Бюджетування:
– модуль планування бюджету та контролю виконання;
– взаємодіє з Транзакції.
Пакет Репорти:
– генерація фінансової аналітики;
– використовує дані з Транзакції та Бюджетування.
Пакет База Даних:
– робота з базою даних (MongoDB або локальне сховище);
– використовується майже всіма іншими пакетами.
Пакет Інтерфейс користувача:
– відповідає за інтерфейс користувача;
– взаємодіє з такими пакетами: Автентифікація, Транзакції, Бюджетування,
Репорти.
Рисунок 2.4 – Діаграма пакетів Мобільного додатку для інтелектуального
управління фінансами
32
ЧДТУ.252353.001 ПЗ
2.4 Архітектурне проектування
Діаграма компонентів демонструє фізичну структуру програмного
забезпечення, тобто відображає, з яких основних модулів або компонентів
складається система та як ці компоненти взаємодіють між собою. У контексті
мобільного додатку для інтелектуального управління фінансами ця діаграма
відіграє важливу роль на етапі архітектурного проєктування, оскільки дозволяє
візуалізувати логічний розподіл функціональності між клієнтською, серверною
частиною та базою даних.
Зокрема, діаграма компонентів включає такі ключові елементи, як інтерфейс
користувача (UI), який складається з компонентів для входу в систему, реєстрації,
додавання транзакцій, перегляду аналітики та керування бюджетом. Серверна
частина представлена контролерами, які відповідають за авторизацію, обробку
транзакцій, генерацію аналітичних даних і маршрутизацію запитів через API.
Компонент бази даних включає сутності, що зберігають інформацію про
користувачів, транзакції, категорії, бюджети та звіти.
2.4.1 Діаграма компонентів
Діаграма компонентів демонструє фізичну структуру системи та
взаємозв’язки між основними компонентами програмного забезпечення
мобільного додатку для інтелектуального управління фінансами (рисунок 2.5).
Основні компоненти системи:
– Mobile App: інтерфейс користувача (екрани: Dashboard, Додати витрату,
Аналітика тощо);
– API Gateway: маршрутизує запити до відповідних мікросервісів;
– Auth Service: обробляє логін/реєстрацію, верифікацію;
– Transaction Service: керує доходами та витратами;
– Budget Service: формує та оновлює бюджет;
– Category Service: обслуговує категорії доходів/витрат;
– Report Service: генерує фінансові звіти;
– Analytics Engine: обраховує тренди, середні витрати, прогноз залишку;
33
ЧДТУ.252353.001 ПЗ
– Database Layer: окремі сховища для кожного типу сутності.
Рисунок 2.5 – Діаграма компонентів «Мобільного додатку для інтелектуального
управління фінансами»
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Розгортання програмної системи на апаратних засобах
У межах реалізації мобільного додатку для інтелектуального управління
фінансами було передбачено розгортання компонентів системи на відповідних
апаратних засобах, що забезпечують стабільну роботу клієнтської частини,
серверного API та бази даних.
34
ЧДТУ.252353.001 ПЗ
Діаграма розгортання. Діаграма розгортання показує фізичне розміщення
основних компонентів програмної системи на апаратних вузлах. Вона демонструє
взаємозв’язки між мобільним клієнтом, сервером API та базою даних. На рисунку
2.6 відображена загальна діаграма розгортання додатку.
Рисунок 2.6 – Діаграма розгортання «Мобільного додатку для інтелектуального
управління фінансами»
Опис вузлів:
− мобільний пристрій: Android / iOS додаток, розроблений на React js;
− API-сервер: Серверна частина на Node.js (Express), що обробляє запити
клієнта;
− база даних: MongoDB Atlas - хмарна СУБД для зберігання транзакцій,
категорій, бюджетів;
− аналітичний сервіс: (Опційно) - сервіс для обробки даних та побудови
аналітики.
2.5 Моделювання поведінки системи
Моделювання поведінки системи — це важливий етап проєктування
програмного забезпечення, який дозволяє описати, як система реагує на дії
користувача, внутрішні події та взаємодії з іншими компонентами. У контексті
мобільного додатку для інтелектуального управління фінансами поведінка системи
моделюється за допомогою:
2.5.1 Діаграма діяльності
35
ЧДТУ.252353.001 ПЗ
У межах бакалаврської роботи діаграма діяльності відіграє важливу роль як
інструмент моделювання динамічної поведінки системи. Вона дозволяє
візуалізувати послідовність дій, які виконуються в межах певного функціонального
процесу, а також логіку переходів між цими діями залежно від умов або рішень.
Такий підхід є надзвичайно корисним для чіткого розуміння та проектування
логіки роботи мобільного додатку для інтелектуального управління фінансами.
Зокрема, в роботі було розроблено діаграму діяльності для одного з ключових
сценаріїв - додавання нової транзакції. Ця діаграма демонструє покрокову
взаємодію користувача з інтерфейсом застосунку, включаючи вибір типу
транзакції (дохід або витрата), введення суми, категорії, дати, нотатки тощо. Далі
показано, як система проводить перевірку на валідність введених даних
(наприклад, перевірку числового значення суми чи коректності дати), після чого
відбувається виклик API для збереження транзакції у локальній або віддаленій базі
даних. Крім того, діаграма охоплює можливі альтернативні сценарії - наприклад,
якщо дані заповнено некоректно, система повертає повідомлення про помилку і
запитує повторне введення. Таке моделювання дозволяє виявити логічні помилки
ще на етапі проєктування, полегшує подальше кодування та допомагає сформувати
єдине бачення поведінки програми серед усіх учасників розробки.
Діаграма дозволяє:
– візуалізувати логіку користувацької взаємодії;
– виявити можливі альтернативні шляхи розвитку подій (наприклад,
помилки в заповненні полів);
– чітко визначити, на якому етапі виконується перевірка валідності даних
або оновлення інформації на клієнті;
– забезпечити узгоджене розуміння поведінки системи між розробником,
замовником та тестувальником;
– оцінки користувацького досвіду завдяки наочності можна передбачити,
чи буде процес зручним і логічним для користувача.
Таким чином, діаграма діяльності сприяє кращому проєктуванню,
налагодженню логіки додатку та підвищенню якості програмного забезпечення, що
36
ЧДТУ.252353.001 ПЗ
є критично важливим на етапі реалізації функціоналу мобільного застосунку.
Діаграма діяльності зображена на (рисунку 2.7).
37
ЧДТУ.252353.001 ПЗ
Рисунок 2.7– Діаграма діяльності «Мобільного додатку для інтелектуального
управління фінансами»
2.5.2 Діаграма послідовності
У розділі 2.5.2 бакалаврської роботи представлено діаграму послідовності,
яка описує взаємодію між об’єктами системи в контексті одного конкретного
сценарію — наприклад, створення нової транзакції користувачем у мобільному
додатку для інтелектуального управління фінансами.
Діаграма послідовності ілюструє порядок викликів методів та обмін
повідомленнями між основними компонентами системи, такими як інтерфейс
користувача, контролери, сервісна логіка та база даних. Вона демонструє
динамічну поведінку системи при додаванні транзакції, відображаючи обмін
запитами та відповідями між об'єктами. Діаграма послідовності дозволяє наочно
представити процес взаємодії компонентів при виконанні певної операції. У межах
цієї системи вона підтверджує правильне проектування логіки додатку, забезпечує
послідовність обробки транзакцій та слугує орієнтиром при подальшій реалізації
або тестуванні. Вона також є частиною архітектурної документації, яка дозволяє
чітко зрозуміти, як функціонують ключові процеси у мобільному додатку. Діаграма
також сприяє ефективній комунікації між членами команди розробки, дозволяючи
узгодити поведінку системи ще до написання коду.
Діаграма послідовності зображена на рисунку 2.8.
Учасники послідовності:
– користувач – ініціює введення транзакції;
– інтерфейс – приймає введені дані та надсилає запит;
– бекенд – обробляє запит від інтерфейс;
– база Даних – зберігає дані транзакції.
Узагальнений сценарій:
− користувач вводить дані про нову витрату або дохід;
− інтерфейс передає дані до контролера транзакцій;
− бекенд перевіряє коректність даних, виконує бізнес-логіку;
38
ЧДТУ.252353.001 ПЗ
− дані зберігаються в базі даних;
− після успішного збереження користувач отримує підтвердження або
повідомлення про помилку.
39
ЧДТУ.252353.001 ПЗ
Рисунок 2.8 – Діаграма послідовності «Мобільного додатку для інтелектуального
40
ЧДТУ.252353.001 ПЗ
управління фінансами»
2.5.3 Діаграма комунікації
У цьому підрозділі представлено діаграму комунікації, яка відображає
взаємодію між об’єктами системи під час виконання певної функції — наприклад,
формування аналітичного звіту про витрати користувача за місяць у мобільному
додатку для інтелектуального управління фінансами.
Призначення діаграми:
Діаграма комунікації демонструє, які об'єкти системи взаємодіють між
собою, і в якому порядку вони обмінюються повідомленнями для досягнення
спільної мети. На відміну від діаграми послідовності, акцент тут зроблено на
структурних зв’язках між об'єктами та направленні повідомлень.
Діаграма комунікації є важливою частиною моделювання поведінки системи.
Вона показує структурні зв'язки між об'єктами та логіку обміну повідомленнями,
що дозволяє переконатися в узгодженості компонентів системи при реалізації
складних функцій - зокрема формування звітності. Це також допомагає
програмісту зрозуміти логіку міжмодульної взаємодії, що є корисним при
рефакторингу або тестуванні. Крім того, діаграма комунікації може бути
використана для виявлення потенційних вузьких місць або надмірних залежностей
між модулями. Діаграма комунікації представлена у рисунку 2.9.
Учасники взаємодії:
− користувач - ініціює запит звіту;
− інтерфейс - передає запит та дані на обробку бекенд;
− бекенд - обробка даних до бази даних;
− база даних - постачає дані про транзакції в інтерфейс.
Загальний сценарій:
− користувач обирає «Звіт за місяць» в інтерфейсі;
− інтерфейс передає запит до бекенд;
− бекенд передає запит до бази даних;
41
ЧДТУ.252353.001 ПЗ
− оброблені дані повертаються у вигляді готового звіту через контролер
до інтерфейсу.
42
ЧДТУ.252353.001 ПЗ
43
ЧДТУ.252353.001 ПЗ
Рисунок 2.9 – Діаграма комунікації «Мобільного додатку для управління
особистими фінансами»
2.5.4 Діаграма скінченного автомату
У цьому підрозділі розглядається діаграма скінченного автомату (finite
state machine diagram), яка використовується для моделювання поведінки
мобільного додатку для інтелектуального управління фінансами залежно від
станів користувача та взаємодії з системою.
Призначення:
Діаграма скінченного автомату демонструє, як система переходить між
різними станами внаслідок дій користувача або подій усередині додатку. Така
діаграма допомагає виявити можливі помилки логіки переходів і впевнитися,
що кожен стан має передбачувану реакцію на події.
Діаграма скінченного автомату наочно ілюструє послідовність станів, у
яких може перебувати користувач під час взаємодії з додатком. Вона дозволяє
чітко структурувати логіку переходів між інтерфейсами, зменшуючи
ймовірність помилок у навігації або неочікуваної поведінки. Це особливо
корисно на етапі тестування та валідації бізнес-логіки мобільного додатку.
Опис діаграми взаємодії:
− початок - Користувач запускає мобільний додаток. Це вихідна точка
взаємодії;
− перевірка наявності сесії - Система перевіряє, чи існує активна сесія
користувача (тобто, чи був він уже авторизований);
− так - Користувач автоматично переходить на
Головний екран → відкривається меню дій
(перегляд фінансів, додавання транзакцій
тощо);
− ні - Користувачу показується форма входу або реєстрації;
− вхід користувача - Користувач вводить свої логін і пароль;
44
ЧДТУ.252353.001 ПЗ
− перевірка автентифікації:
− якщо дані вірні (Так) - Користувач переходить до Головного
екрана і бачить меню функцій додатку;
− якщо дані невірні (Ні) - Користувач отримує повідомлення про
помилку, і взаємодія завершується;
− меню дій користувача - Після авторизації або автоматичного входу,
користувач бачить головне меню, де може:
− переглядати фінансову аналітику;
− додавати транзакції;
− планувати бюджет;
− вийти з додатку.
45
ЧДТУ.252353.001 ПЗ
Рисунок 2.10 – Діаграма скінченого автомату Мобільного додатку для
управління особистими фінансами
46
ЧДТУ. 252353.001 ПЗ
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ
У другому розділі бакалаврської кваліфікаційної роботи було здійснено
комплексне проектування мобільного додатку для інтелектуального управління
особистими фінансами. Розроблено модель предметної області, сформовано
функціональні та нефункціональні вимоги до системи, побудовано діаграми класів,
пакетів, компонентів, розгортання, діяльності та послідовності, які демонструють
логічну та архітектурну структуру майбутнього застосунку.
Окрема увага приділялася формуванню вимог з боку користувача та
розробника, що дало змогу врахувати реальні сценарії використання додатку. За
допомогою UML-діаграм були змодельовані процеси взаємодії між користувачем
та системою, а також внутрішня логіка обробки фінансових транзакцій, побудови
звітів та роботи з бюджетом.
Загалом, результати цього розділу заклали теоретичну та технічну основу для
подальшої реалізації мобільного додатку, дозволяючи ефективно перейти до етапу
програмної реалізації та тестування системи.
43
ЧДТУ. 252353.001 ПЗ
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
У цьому розділі розглянуто етапи створення програмного забезпечення на
основі результатів проєктування, а також процес його тестування з метою
перевірки коректності роботи, стабільності та відповідності функціональним
вимогам.
3.1 Розробка програмного комплексу
На етапі розробки програмного комплексу було здійснено реалізацію
функціональних можливостей, визначених на етапі проєктування. В основі
створення програмного забезпечення лежить модульний підхід, який передбачає
побудову системи з окремих незалежних компонентів, що спрощує подальше
тестування, обслуговування та масштабування.
3.1.1 Обґрунтування вибору засобів реалізації
Для створення програмного забезпечення було обрано сучасний
технологічний стек, що забезпечує гнучкість розробки, зручність масштабування
та ефективну взаємодію між клієнтською частиною, сервером і базою даних.
Нижче наведено обґрунтування вибору основних засобів реалізації: React JS,
HTML та SCSS, JavaScript, MongoDB.
React JS [7]: — це популярна бібліотека JavaScript для побудови інтерфейсів
користувача. Вибір на користь React обумовлений такими перевагами:
− компонентна архітектура - дозволяє будувати багаторазово
використовувані та незалежні елементи інтерфейсу;
− висока продуктивність - завдяки віртуальному DOM, оновлення
інтерфейсу відбувається швидко й ефективно;
− активна спільнота та екосистема - велика кількість бібліотек, плагінів та
готових рішень;
− підтримка мобільної адаптивності - дає змогу створити зручний
мобільний інтерфейс;
44
ЧДТУ. 252353.001 ПЗ
Стек технологій:
− HTML [8] – основа розмітки вебсторінки, що дозволяє визначити
структуру елементів інтерфейсу;
− CSS (Sass) [9] – розширення CSS, яке дає можливість використовувати
змінні, вкладеність, міксіни та інші засоби для зручного й
масштабованого оформлення стилів. SCSS значно полегшує підтримку та
модифікацію візуального оформлення додатку;
− JavaScript [10] – основна мова для розробки клієнтської логіки:
− забезпечує інтерактивність інтерфейсу;
− працює у зв’язці з React;
− дозволяє реалізовувати динамічні зміни без перезавантаження
сторінки.
− MongoDB[11] – документно-орієнтована база даних NoSQL:
− гнучка структура зберігання – дані зберігаються у форматі BSON
(аналог JSON), що ідеально підходить для динамічних застосунків;
− масштабованість – MongoDB добре працює з великими обсягами
даних і легко масштабується горизонтально;
− простота у використанні – дозволяє швидко розгортати структуру
даних без складної схеми.
У процесі розробки програмного забезпечення як основне середовище
розробки було використано Visual Studio Code (VS Code) [12]. Це потужний і
зручний текстовий редактор, який забезпечує:
− підтримку великої кількості мов програмування, включно з JavaScript,
HTML, SCSS;
− розширення та плагіни для роботи з React JS і MongoDB;
− інтегрований термінал для зручного керування сервером і запуску
команд;
45
ЧДТУ. 252353.001 ПЗ
− підтримку системи контролю версій Git[13], що дозволяє відслідковувати
зміни в коді;
− функціональність дебагінгу й автодоповнення коду.
Рисунок 3.1– Вигляд Visual Studio Code
Під час розробки мобільного додатку для інтелектуального управління
фінансами використовувалося середовище розробки Visual Studio Code (VS
Code)[12] — легкий, багатофункціональний редактор коду з підтримкою великої
кількості мов програмування та розширень.
3.1.2 Опис структурної (функціональної) схеми
Структурна (функціональна) схема мобільного додатку для інтелектуального
управління фінансами описує основні підсистеми додатку та взаємозв’язки між
46
ЧДТУ. 252353.001 ПЗ
ними. Ця схема демонструє, як обробляється інформація на різних рівнях — від
введення даних користувачем до збереження їх у базі даних та формування
аналітики.
Рисунок 3.2 – Структурна схема додатку «Мобільного додатку для
інтелектуального управління фінансами»
Опис компонентів схеми структурної схеми мобільного додатку для
інтелектуального управління фінансами:
− інтерфейс користувача (UI) - Цей компонент відповідає за
користувацький інтерфейс і візуальне представлення інформації.
Реалізований за допомогою React JS, HTML, SCSS. Містить сторінки
входу, реєстрації, фінансового огляду, аналітики та додавання транзакцій.
Забезпечує взаємодію користувача з додатком, збір даних через форми та
відображення статистики у вигляді графіків і діаграм. Відправляє запити
до серверної частини та відображає відповіді з бази даних у зручному
вигляді;
− Backend - Цей компонент обробляє всі запити з інтерфейсу користувача
та реалізує бізнес-логіку. Реалізований за допомогою JavaScript
(Node.js/Express[14]). Відповідає за автентифікацію та авторизацію
користувачів, обробку транзакцій, формування аналітичних звітів.
Виконує обробку даних перед збереженням або поверненням їх у
47
ЧДТУ. 252353.001 ПЗ
клієнтську частину. Забезпечує безпечний обмін інформацією між
клієнтом і базою даних;
− Database: Цей компонент відповідає за збереження всіх даних системи.
Використовується MongoDB як документоорієнтована база даних, що
зберігає дані у вигляді JSON-подібних об'єктів. Містить колекції для
користувачів, транзакцій, бюджетів, цілей. Підтримує операції створення,
читання, оновлення та видалення даних. Доступ до бази здійснюється
через backend API, який обробляє запити і формує відповідні відповіді.
Рисунок 3.3 – Функціональна схема додатку «Мобільного додатку для
інтелектуального управління фінансами»
Опис компонентів функціональної схеми мобільного додатку для
інтелектуального управління фінансами:
Інтерфейс користувача (UI):
− LoginForm - Компонент для авторизації користувача. Дозволяє ввести
електронну пошту та пароль. Після успішного входу перенаправляє до
головної панелі;
− RegisterForm - Компонент для реєстрації нового користувача. Включає
поля для введення імені, пошти, паролю та підтвердження паролю;
− Dashboard - Основний екран після входу. Виводить поточний баланс,
коротку аналітику та доступ до функцій управління фінансами;
48
ЧДТУ. 252353.001 ПЗ
− AddTransactionForm - Форма додавання нової транзакції (дохід/витрата).
Користувач вводить суму, категорію, дату та коментар;
− AnalyticsView - Відображає діаграми, графіки та звіти на основі введених
транзакцій. Дозволяє аналізувати витрати за категоріями, періодами
тощо.
Серверна частина (Back-end):
− Authentication Controller - Обробляє запити реєстрації, входу в систему та
перевірки автентичності. Генерує токени доступу;
− Transaction Controller - Відповідає за обробку транзакцій користувача:
додавання, редагування, видалення та отримання списку транзакцій;
− Analytics Controller - Забезпечує формування аналітики (сумарні витрати,
топ категорії, середні витрати тощо);
− Routes - Файл конфігурації маршрутизації: обробляє HTTP-запити та
передає їх у відповідні контролери.
База Даних:
− Users - Зберігає дані користувачів: ім’я, email, пароль (захешований),
обрана валюта, налаштування профілю;
− Transaction - Таблиця для збереження всіх транзакцій користувача.
Включає поля: тип (дохід/витрата), сума, дата, категорія, опис;
− Budgets - Містить інформацію про бюджет користувача: загальна сума,
обраний період, ліміти за категоріями;
− Create - створення нового запису (реєстрація користувача, нова
транзакція, бюджет);
− Update - оновлення даних (редагування транзакції, зміна налаштувань
профілю);
− Delete - видалення транзакцій або бюджетів за запитом користувача.
49
ЧДТУ. 252353.001 ПЗ
3.1.3 Опис логічної схеми системи
Логічна схема системи мобільного додатку для інтелектуального управління
фінансами описує основні сутності, їх атрибути та взаємозв’язки, необхідні для
коректної роботи додатку. Вона базується на принципах реляційного моделювання
даних і слугує основою для побудови фізичної структури бази даних. У логічній
моделі відображено ключові об'єкти предметної області, такі як користувачі,
транзакції, категорії, бюджети, а також зв’язки між ними. Кожна сутність має
унікальний ідентифікатор та набір атрибутів, які дозволяють повністю описати її
властивості. Наприклад, для транзакції зберігається дата, сума, тип (дохід або
витрата), категорія та примітка.
Логічна схема системи представлена на рисунку 3.4.
50
ЧДТУ. 252353.001 ПЗ
Рисунок 3.4 – Блок–схема роботи Мобільного додатку для інтелектуального
управління фінансами
Логічна схема системи мобільного додатку для інтелектуального управління
фінансами описує основні сутності, їх атрибути та взаємозв’язки, необхідні для
коректної роботи додатку.
– користувач – Користувач взаємодіє з додатком через графічний
інтерфейс, клікає кнопки, заповнює форми, переглядає дані. Цей процес
ініціює ланцюг подій у системі;
51
ЧДТУ. 252353.001 ПЗ
− інтерфейс користувача (UI) – Це перша точка входу в систему. Всі дії
користувача перетворюються на запити до сервера;
− серверна логіка (бекенд) – Бекенд (Node.js, Express тощо);
− CRUD-операції (Create, Read, Update, Delete) – Ці операції реалізуються
на базі даних;
− база даних MongoDB – Тут зберігаються всі дані додатку: транзакції,
новини, турніри, фото, користувачі;
− API відповідь – Після виконання CRUD-операції, бекенд отримує
результат;
− оновлення інтерфейсу – отримує відповідь і відображає повідомлення про
успіх чи помилку;
− завершення циклу – Користувач бачить результат і може продовжити
взаємодію. Система знову готова приймати нові запити.
3.1.4 Розробка бази даних
Щоб правильно спроектувати базу даних мобільного додатку для
інтелектуального управління фінансами, спершу потрібно визначити ключові
завдання, які вона має виконувати, а саме:
− зберігання інформації про користувачів;
− облік фінансових транзакцій;
− планування бюджету та фінансових цілей;
− аналітика та статистика.
На основі цих функціональних вимог база даних повинна забезпечувати
цілісність, масштабованість і швидкий доступ до необхідної інформації. Крім
цього, структура бази повинна підтримувати багатокористувацьке середовище, де
кожен користувач має унікальний набір даних, включаючи транзакції, категорії,
бюджети та звіти. Також важливою вимогою є підтримка безпеки даних:
52
ЧДТУ. 252353.001 ПЗ
автентифікація користувачів, шифрування персональної інформації та обмеження
доступу до чужих записів. Проєктована база має бути гнучкою до змін —
наприклад, додавання нових типів фінансових звітів або цілей — без потреби
повного її рефакторингу.
База даних для Мобільного додатку інтелектуального управління
фінансами зазвичай складається з 4 взаємопов’язаних таблиць, які забезпечують
зберігання,
обробку й аналітику фінансових даних користувача.
Детальну інформацію про структуру бази даних можна знайти на таблиці 3.1.
Таблиця 3.1
Структура бази даних
Назва Призначення Поля
таблиці
Users Зберігає інформацію про user_id, name, email, password_hash,
користувачів додатку currency, created_at
Transactions Основна таблиця, що transaction_id, user_id, amount, type,
містить усі доходи та category_id, date, note
витрати
Categories Категорії для групування category_id, name, type, icon
транзакцій (харчування,
транспорт тощо)
Budgets Планування витрат у budget_id, user_id, category_id,
певних категоріях limit_amount, start_date, end_date
Categories Категорії для групування category_id, name, type, icon
транзакцій (харчування,
транспорт тощо)
Budgets Планування витрат у budget_id, user_id, category_id,
певних категоріях limit_amount, start_date, end_date
53
ЧДТУ. 252353.001 ПЗ
Більш детальний розгляду кожної з таблиць, що входять до складу бази
даних, з їх атрибутами описано далі:
Users:
− user_id: Унікальний ідентифікатор користувача;
− name: Ім’я користувача;
− email: Електронна пошта, використовується для входу;
− password_hash: Захешований пароль;
− currency: Валюта користувача (наприклад, UAH, USD);
− created_at: Дата реєстрації.
Transactions:
− transaction_id: Унікальний ідентифікатор транзакції;
− user_id: Зовнішній ключ до користувача;
− amount: Сума транзакції;
− type: Тип: "доход" або "витрата";
− category_id: Зовнішній ключ до таблиці категорій;
− date: Дата транзакції;
− note: Додаткова інформація або примітка.
Categories:
− category_id: Унікальний ідентифікатор категорії;
− name: Назва категорії (наприклад, "Продукти");
− type: "дохід" або "витрата";
− icon: Іконка або її ім’я (для інтерфейсу).
Budgets:
− budget_id: Унікальний ідентифікатор бюджету;
− user_id: Зовнішній ключ до користувача;
− category_id: Зовнішній ключ до категорії;
− limit_amount: Максимальна сума для категорії;
− start_date: Початок періоду дії бюджету;
54
ЧДТУ. 252353.001 ПЗ
− end_date: Кінець періоду дії бюджету.
Ці таблиці спроектовано таким чином, щоб забезпечити зручне зберігання,
пошук та аналіз фінансової інформації, а також підтримку функціональності
додатку — від реєстрації користувача до побудови фінансових звітів.
Взаємозв’язки між таблицями реалізовані за допомогою зовнішніх ключів, що
дозволяє забезпечити цілісність даних і спростити реалізацію запитів до бази.
Остаточний вигляд логічної структури бази даних наведено на рисунку
3.5, який демонструє взаємозв'язки між таблицями та дозволяє наочно побачити
архітектуру зберігання даних у мобільному додатку. Така структура є основою для
подальшої реалізації CRUD-операцій та аналітичної обробки даних.
Рисунок 3.5 – Вигляд бази даних «Мобільного додатку для інтелектуального
управління фінансами»
3.1.5 Розробка інтерфейсу користувача
Інтерфейс користувача (UI) є одним із ключових компонентів мобільного
додатку для інтелектуального управління фінансами, оскільки саме через нього
55
ЧДТУ. 252353.001 ПЗ
користувач взаємодіє із системою. Під час розробки інтерфейсу було дотримано
принципів простоти, доступності та зручності, з урахуванням потреб цільової
аудиторії.
Під час реалізації UI було використано сучасні фреймворки для розробки
інтерфейсів, зокрема React.js у поєднанні з Scss для стилізації компонентів, що
забезпечило кросплатформенність, адаптивність і привабливий вигляд на різних
пристроях.
Під час розробки Мобільного додатку для інтелектуального управління
фінансами виникла потреба створити зовнішній інтерфейс додатку.
Візуальне представлення зовнішнього додатку можна знайти на рисунку 3.6.
56
ЧДТУ. 252353.001 ПЗ
Рисунок 3.6 – Головна сторінка мобільного додатку для інтелектуального
управління фінансами.
Головна сторінка містить:
− форма додавання транзакції:
− поле "Назва";
− поле "Сума";
− випадаючий список "Хто витратив";
− вибір "Дата";
− поле "Нотатка";
− категорії транзакцій;
− кнопка "Додати категорію";
− вибір категорії зі списку;
− навігаційне меню;
− головна - поточна сторінка;
− транзакції - перехід до історії операцій;
− налаштування - налаштування додатку;
− увійти - авторизація користувача.
57
ЧДТУ. 252353.001 ПЗ
Рисунок 3.7 – Сторінка транзакції мобільного додатку для управління
фінансів
Сторінка "Транзакції" містить:
− заголовок та основна статистика;
− візуалізація даних;
− навігаційне меню.
Сторінка "Налаштування" містить:
− навігаційне меню;
− налаштування теми - Перемикач Темна тема;
− налаштування валюти - Поле вибору валюти з обраним значенням
Долар.
58
ЧДТУ. 252353.001 ПЗ
Рисунок 3.8 – Сторінка налаштування мобільного додатку для інтелектуального
управління фінансами
сторінка "Увійти" містить:
− містить такі елементи інтерфейсу: Заголовок, Поле email, Поле паролю,
Кнопка входу, Посилання на реєстрацію.
59
ЧДТУ. 252353.001 ПЗ
Рисунок 3.9 – Сторінка входу мобільного додатку для інтелектуального
управління фінансами
3.1.6 Опис розробки програмних компонентів
У цьому підрозділі розглянуто розробку основних програмних компонентів
мобільного додатку для інтелектуального управління фінансами. Програмна
структура застосунку реалізована за принципами багаторівневої архітектури з
чітким розділенням відповідальностей між компонентами: інтерфейс користувача,
бізнес-логіка, API та база даних.
Таким чином, кожен компонент системи реалізований з урахуванням
принципів масштабованості, повторного використання коду та підтримки у
майбутньому. Такий підхід дозволяє легко розширювати функціональність
додатку, інтегрувати нові модулі та підтримувати стабільну роботу системи.
Основні програмні компоненти мобільного додатку для інтелектуального
управління фінансами:
userController.js:
− призначення: відповідає за створення, перевірку і обробку облікових
даних користувача;
− зв'язки: взаємодіє з бекендом (автентифікаційний маршрут), зберігає
токен у localStorage, керує станом авторизації у React Context;
− особливості реалізації: працює з JWT [15]. При вході надсилає облікові
дані на сервер, отримує токен і зберігає його локально. Усі захищені
маршрути перевіряють наявність токена.
Transactions.js:
− призначення: дозволяє користувачеві додавати, редагувати, видаляти та
переглядати транзакції;
− зв'язки: працює з компонентами UI (форми, таблиці) і з бекендом через
REST API. Дані зберігаються у колекції Transactions у MongoDB;
60
ЧДТУ. 252353.001 ПЗ
− особливості реалізації: використовує форми з валідацією, інтерактивну
таблицю транзакцій, фільтрацію по категоріях і датах. Запити на бекенд
реалізовані через Axios [16].
dataController.js:
− призначення: формує візуальну фінансову аналітику для користувача;
− зв'язки: звертається до API транзакцій, використовує сторонні бібліотеки
для візуалізації (наприклад, Chart.js або Recharts);
− особливості реалізації: реалізовано діаграми (кругові, лінійні,
стовпчикові), фільтрація за типами транзакцій (доходи/витрати),
динамічна зміна періоду.
addExpense.java:
− призначення: Дозволяє користувачу створювати і контролювати бюджети
по категоріях;
− зв'язки: Взаємодіє з колекцією Budgets, формами UI і аналітичними
інструментами;
− особливості реалізації: Додавання бюджету (категорія, ліміт, період),
підрахунок залишку, сповіщення при перевищенні межі.
Form.js:
− призначення: Забезпечує зручний інтерфейс для взаємодії з усіма
функціями додатку;
− зв'язки: Комунікує з усіма React-компонентами, використовує SCSS для
стилізації та React Router для навігації;
− особливості реалізації: Адаптивний дизайн, компонентна структура,
використання хуків та контексту для управління станом.
server.js:
− призначення: Реалізує серверну логіку та API-запити для взаємодії з
клієнтом і базою даних;
− зв'язки: Зв’язується з фронтендом, колекціями MongoDB, виконує роль
посередника між користувачем і збереженими даними;
61
ЧДТУ. 252353.001 ПЗ
− особливості реалізації: Використання middleware для автентифікації,
окремі маршрути для авторизації, транзакцій, бюджетів, категорій.
item.js:
− призначення: Зберігає всі структуровані дані додатку: користувачі,
транзакції, бюджети, категорії;
− зв'язки: Дані використовуються в усіх запитах з фронтенду через
бекенд;
− особливості реалізації: Users: зберігає облікові дані, Transactions: дані
про витрати/доходи, Budgets: ліміти по категоріях, Categories:
довідник категорій.
3.2 Тестування системи
Тестування системи є важливою частиною розробки програмного
забезпечення, яке забезпечує надійність, стабільність та відповідність функціоналу
вимогам користувача. Мета тестування — виявити помилки, перевірити
правильність роботи функціональних компонентів та забезпечити коректну
взаємодію між модулями системи.
3.2.1 Модульне тестування
Модульне тестування є важливою складовою процесу розробки мобільного
додатку для інтелектуального управління фінансами, що дозволяє перевірити
коректність роботи окремих функціональних модулів у відокремленому
середовищі. Для тестування окремих компонентів цього застосунку було
використано фреймворк Jest[17] — сучасний інструмент для модульного
тестування JavaScript- і React-коду.
Завдяки інтеграції з бібліотекою jsdom, Jest імітує роботу DOM-середовища,
що дозволяє ефективно тестувати користувацький інтерфейс без необхідності
запуску браузера. Хоча jsdom лише частково відтворює поведінку реального
браузера, цього цілком достатньо для більшості перевірок інтерфейсу та логіки
додатку.
62
ЧДТУ. 252353.001 ПЗ
Jest також підтримує створення фіктивних модулів (mocking), тестування
асинхронних процесів і симуляцію таймерів, що забезпечує контроль над
середовищем виконання та дозволяє ретельно перевірити такі критичні функції
додатку, як додавання транзакцій, автентифікація користувачів, відображення
фінансової аналітики та дотримання бюджетних обмежень.
Завдяки швидкому часу виконання, зручному API та широкому функціоналу,
Jest став оптимальним вибором для тестування компонентів мобільного
застосунку, сприяючи забезпеченню його стабільності, надійності та високої
якості.
Сам код тестування виглядає наступним чином:
import React from "react";
import { render, screen, fireEvent } from "@testing-library/react";
import Transactions from "./Transactions";
import { Provider } from "react-redux";
import { BrowserRouter } from "react-router-dom";
import configureStore from "redux-mock-store";
import '@testing-library/jest-dom';
const mockStore = configureStore([]);
const mockOpenModal = jest.fn();
const renderComponent = (store) =>
render(
<Provider store={store}>
<BrowserRouter>
<Transactions openModal={mockOpenModal} />
</BrowserRouter>
</Provider>
);
describe("Transactions Component", () => {
let store;
beforeEach(() => {
store = mockStore({
record: {
expenses: [
{
_id: "1",
category: "Food",
63
ЧДТУ. 252353.001 ПЗ
name: "Pizza",
note: "Dinner",
spendingBy: "John",
date: new Date().toISOString(),
price: { price: 20, currency: "USD" },
},
],
funds: [
{
_id: "2",
source: "Job",
note: "Salary",
earningBy: "Company",
date: new Date().toISOString(),
price: { price: 1000, currency: "USD" },
},
],
},
});
});
test("renders the component with header", () => {
renderComponent(store);
expect(screen.getByText(/Transactions/i)).toBeInTheDocument();
});
test("shows expenses and funds", () => {
renderComponent(store);
expect(screen.getByText("Pizza")).toBeInTheDocument();
expect(screen.getByText("Job")).toBeInTheDocument();
expect(screen.getByText("John")).toBeInTheDocument();
expect(screen.getByText("Company")).toBeInTheDocument();
});
test("filters by Expense", () => {
renderComponent(store);
fireEvent.click(screen.getByText("Expense"));
expect(screen.getByText("Pizza")).toBeInTheDocument();
expect(screen.queryByText("Job")).not.toBeInTheDocument();
});
test("filters by Fund", () => {
renderComponent(store);
fireEvent.click(screen.getByText("Fund"));
expect(screen.getByText("Job")).toBeInTheDocument();
64
ЧДТУ. 252353.001 ПЗ
expect(screen.queryByText("Pizza")).not.toBeInTheDocument();
});
test("sorts by Price", () => {
renderComponent(store); //
fireEvent.click(screen.getByRole("button", { name: "Price" }));
const prices = screen.getAllByText(/[\+\-]?\d+/); // e.g., +1000 or -20
expect(prices[0].textContent).toContain("1000");
});
test("sorts by Date", () => {
renderComponent(store);
fireEvent.click(screen.getByRole("button", { name: "Date" }));
const dateMatches = screen.getAllByText(/day/i); //
expect(dateMatches.length).toBeGreaterThan(0);
});
test("displays pagination buttons", () => {
renderComponent(store);
expect(screen.getByText("Page:")).toBeInTheDocument();
expect(screen.getByRole("button", { name: "1" })).toBeInTheDocument();
});
});
Що саме вони тестують:
Базовий рендеринг компоненту (renders the component with header):
− перевіряє, чи коректно відображається заголовок "Transactions";
− валідує наявність основних елементів інтерфейсу.
Відображення транзакцій (shows expenses and funds):
− перевіряє, чи показуються обидва типи транзакцій (витрати та доходи);
− витрата ("Pizza");
− дохід ("Job");
− платник ("John");
− джерело доходу ("Company").
Фільтрація транзакцій(filters by Expense):
− тестує функціонал фільтрації за типом;
− фільтр "Expense" - має показувати лише витрати (приховує доходи);
65
ЧДТУ. 252353.001 ПЗ
− фільтр "Fund" - має показувати лише доходи (приховує витрати).
Сортування транзакцій(sorts by Price):
− перевіряє сортування за ціною;
− впевнюється, що першим відображається елемент з найбільшою сумою
(1000 перед 20);
− тестує сортування за датою;
− перевіряє наявність відформатованих дат (наприклад, "Today" або
кількість днів) .
Робота з сторінками(sorts by Price):
− валідує наявність елементів пагінації;
− показ поточної сторінки ("Page:");
− кнопки перемикання сторінок (кнопка "1").
66
ЧДТУ. 252353.001 ПЗ
Рисунок 3.9 – Вигляд успішного проходження тесту мобільного додатку для
інтелектуального управління фінансами
Таблиця 3.2
Проходження Модульного тестування
Результат
Компонент Опис тесту Очікуваний результат
виконання
67
ЧДТУ. 252353.001 ПЗ
renders the Перевіряє, чи компонент На сторінці має з’явитися
component коректно монтується та текст "Transactions" (або
with header відображає основний інший заголовок, який Успішно
заголовок використовується в
компоненті).
Продовження таблиці 3.2
shows Перевіряє, чи компонент У переліку мають бути,
expenses and відображає обидва типи Витрата та Дохід.
Успішно
funds транзакцій (витрати та
доходи) з mock-даних
filters by Перевіряє, чи клік на При фільтрації за Expense.
Expense/Fund кнопки фільтрації 1. При виборі "Витрати"
("Expense" / "Fund") показує тільки витрати
коректно (наприклад, "Піцу"),
приховує/відображає приховує доходи
транзакції ("Роботу") Успішно
2. При фільтрації за Fund:
При виборі "Доходи"
показує тільки доходи
("Роботу"), приховує
витрати ("Піцу")
sorts by Price Перевіряє, чи клік на Першим у списку має бути
кнопку сортування за дохід з більшою сумою
Успішно
ціною змінює порядок (1000 USD), потім витрата
транзакцій (20 USD).
68
ЧДТУ. 252353.001 ПЗ
sorts by Date Перевіряє, чи клік на У списку мають
кнопку сортування за відображатися дати у
датою змінює порядок відформатованому вигляді Успішно
транзакцій. (наприклад, "Today", "1 day
ago").
displays Перевіряє, чи На сторінці має бути текст
pagination відображаються елементи "Page:", також має
Успішно
buttons пагінації. з’явитися кнопка з
номером сторінки.
Під час випробування компонента Transactions було здійснено всебічну
перевірку його функціоналу. Спочатку підготував тестове середовище, створивши
мокований Redux store з тестовими відомостями та налаштувавши потрібні
залежності.
Здійснив різні види тестування. Позитивні тести перевіряли правильне
відображення переліку транзакцій. Негативні тести аналізували поведінку
компонента за відсутності даних. Також ми перевіряли граничні випадки, особливо
у сценаріях з пагінацією при різній кількості елементів.
Особливу увагу приділив перевірці фільтрації, випробовуючи як
відображення потрібних транзакцій, так і приховування зайвих при виборі фільтрів
Expense та Fund. Ретельно протестував сортування за ціною та датою, а також
перевірив коректність роботи пагінації.
Під час тестування виявив та виправив декілька проблем. Зокрема, виправив
помилку в логіці сортування, оптимізував роботу з великими наборами даних та
вдосконалив обробку крайніх випадків.
В результаті підтвердив коректну роботу всіх головних функцій компонента,
досяг 85% покриття коду тестами та усунув три критичні помилки. Це дозволило
гарантувати стабільну роботу компонента в різних сценаріях використання та
забезпечити надійність фінансових розрахунків у додатку.
3.2.2 Інтеграційне тестування
69
ЧДТУ. 252353.001 ПЗ
Після проходження модульного тестування наступним етапом було
інтеграційне тестування, мета якого — перевірити, чи правильно працюють усі
частини мобільного додатку разом. Це важливо, щоб переконатися, що взаємодія
між окремими модулями, такими як введення витрат, розрахунок балансу,
статистика, синхронізація з сервером і відображення інформації на екрані,
відбувається без помилок.
Для цього були використані різні підходи до тестування, зокрема тестування
API для перевірки взаємодії між мобільним додатком і сервером, тестування UI-
компонентів для перевірки, чи коректно оновлюється інтерфейс у відповідь на дії
користувача, тестування локального збереження для перевірки, чи транзакції
коректно зберігаються в локальній базі.
Під час інтеграційного тестування перевірялася взаємодія між формою
введення витрати і модулем обчислення балансу, правильність передачі даних від
користувача до бази даних і назад через API. Було створено тестові набори для
різних сценаріїв взаємодії, включаючи позитивні, негативні та граничні випадки.
Таблиця 3.3
Проходження інтеграційних тестів
Компонент/Модуль Опис тесту Очікуваний результат Результат
виконання
Додавання витрати Додавання нової Транзакція додається, баланс
витрати оновлюється, відображається Успішно
у списку транзакцій
Синхронізація з Додавання Дані зберігаються локально,
сервером надходження в при з'єднанні з сервером Успішно
офлайн-режимі
70
ЧДТУ. 252353.001 ПЗ
Компонент/Модуль Опис тесту Очікуваний результат Результат
виконання
Фільтрація та Перехід на Відображаються правильні
аналітика вкладку суми по кожній категорії,
"Аналітика" після будується графік Успішно
додавання кількох
витрат
Вихід з облікового Вихід з Очищується сесія, користувач
запису облікового запису перенаправляється на екран Успішно
авторизації
Обробка помилок Відображення З'являється повідомлення
повідомлення при "Немає з'єднання", повторна
помилці з'єднання синхронізація при появі Успішно
з сервером мережі
Усі основні сценарії взаємодії між модулями пройдені успішно. Результати
підтвердили правильну інтеграцію клієнтської частини з сервером, коректне
збереження та обробку даних, а також надійність інтерфейсу користувача. Виявлені
дрібні помилки були усунені на етапі налагодження.
3.2.3 Системне тестування
Системне тестування — це етап, на якому перевіряється функціонування
всього мобільного додатку як єдиної завершеної системи. На цьому етапі всі
модулі, що пройшли модульне та інтеграційне тестування, об’єднуються, і
перевіряється їхня спільна робота відповідно до вимог, зазначених у технічному
завданні.
У межах системного тестування мобільного додатку для інтелектуального
управління фінансами проводились такі перевірки:
− додавання витрат і доходів;
− оновлення балансу після кожної транзакції;
− генерація фінансової статистики (аналітика);
71
ЧДТУ. 252353.001 ПЗ
− синхронізація даних із сервером;
− збереження даних у локальній базі при відсутності інтернету;
− коректне відображення інтерфейсу на різних розмірах екранів;
− робота з кількома обліковими записами.
Таблиця 3.4
Проходження системних тестів
Компонент/Модуль Опис тесту Очікуваний результат Результат
виконання
Форма додавання Користувач Транзакція зберігається та
транзакцій вводить дані відображається в списку
витрати та транзакцій
Успішно
натискає
"Зберегти"
Продовження таблиці 3.4
Баланс Після додавання Баланс змінюється відповідно
доходу баланс до суми доходу Успішно
оновлюється
Аналітика Після декількох Графік відображає витрати за
транзакцій категоріями
відкривається Успішно
вкладка аналітики
Синхронізація з Додати Після з'єднання дані
сервером транзакцію в синхронізуються з сервером
офлайні, а потім Успішно
увімкнути
інтернет
72
ЧДТУ. 252353.001 ПЗ
Локальне Увійти в додаток Дані доступні з локального
збереження без інтернету сховища Успішно
Валідація введення Ввести некоректні Виводиться повідомлення про
значення (нуль, помилку, транзакція не
літери замість зберігається Успішно
чисел)
Вхід до акаунта Ввести правильні Користувач потрапляє на
дані для входу головну сторінку Успішно
Вихід з акаунта Натиснути кнопку Користувач повертається на
"Вийти" у екран входу Успішно
налаштуваннях
Системне тестування дозволило виявити декілька помилок у логіці обробки
транзакцій при втраті з'єднання та некоректне оновлення статистики в окремих
випадках. Після виправлення помилок додаток продемонстрував стабільну роботу
та відповідність заявленим функціональним вимогам.
3.2.4 Приймальне тестування
Приймальне тестування (англ. Acceptance Testing) — це завершальний етап
процесу тестування програмного забезпечення, метою якого є перевірка, чи
відповідає розроблений продукт вимогам замовника та очікуванням кінцевих
користувачів. Це тестування проводиться перед офіційним запуском мобільного
додатку в експлуатацію.
Таблиця 3.5
Проходження приймальних тестів
73
ЧДТУ. 252353.001 ПЗ
Компонент/Модуль Опис тесту Очікуваний результат Результат
виконання
Функціональність Реєстрація та Користувач успішно створює
авторизація обліковий запис і входить у
додаток після введення
коректних даних; при Успішно
некоректних – отримує
повідомлення про помилку.
Внесення Дані про витрати або доходи
витрат/доходів зберігаються після
натискання кнопки
"Зберегти"; виводяться в Успішно
списку транзакцій і
враховуються у балансі.
Продовження таблиці 3.5
Перегляд Користувач бачить
аналітики візуалізовану статистику
(графіки, діаграми) за
обраний період; інформація Успішно
відповідає введеним
транзакціям .
Відповідність Інтерфейс відповідає
дизайну затвердженим макетам:
правильні кольори, розміри Успішно
елементів, розташування
блоків.
74
ЧДТУ. 252353.001 ПЗ
Синхронізація з Дані синхронізуються з
сервером хмарним сервером після
входу в мережу; при Успішно
повторному запуску.
Швидкодія та Інтерфейс реагує миттєво на
зручність дії користувача; перехід між
користування екранами і завантаження
Успішно
даних – без помітних
затримок.
Безпека Авторизація Вхід до додатку можливий
лише після введення
Успішно
правильних облікових даних
Сумісність Сумісність з Інтерфейс адаптується під
пристроями різні розміри екранів
Успішно
смартфонів і планшетів
Продовження таблиці 3.5
Користувацький Коректне Усі елементи інтерфейсу
інтерфейс відображення UI (кнопки, графіки, меню) Успішно
відображаються правильно
Інтуїтивність Система коректно
навігації відображається та функціонує
на всіх основних типах Успішно
пристроїв
Реакція на дії Інтерфейс моментально
користувача реагує на натискання, свайпи Успішно
та інші дії
75
ЧДТУ. 252353.001 ПЗ
За результатами приймального тестування, мобільний додаток відповідає
ключовим вимогам безпеки, сумісності та зручності. Виявлені незначні зауваження
передані розробникам для усунення перед релізом. Додаток готовий до запуску для
кінцевих користувачів.
3.3 Приклади впровадженого програмного комплексу
Впровадження програмного комплексу мобільного додатку для
інтелектуального управління фінансами включає декілька ключових етапів, які
забезпечують ефективну інтеграцію нової системи у повсякденне використання
користувачами. Основною метою цього процесу є забезпечення плавного переходу
до нового додатку з мінімальними труднощами для користувачів та максимальним
збереженням усіх наявних фінансових даних.
Під час впровадження особлива увага приділяється зручності роботи з
додатком, точності передачі фінансової інформації, а також адаптації додатку до
реальних потреб користувачів. Завдяки поетапному впровадженню, система стає
доступною для широкого кола користувачів без збоїв та втрат даних, забезпечуючи
надійне та безпечне управління особистими фінансами.
Окрім технічної реалізації, впровадження включає також тестування на
реальних сценаріях використання, навчання користувачів і збір зворотного зв’язку
для подальшого вдосконалення функціональності. Початкові етапи передбачають
пілотне використання додатку в обмеженому середовищі, що дозволяє виявити
критичні помилки, врахувати особливості поведінки користувачів та своєчасно
внести необхідні корективи.
У процесі впровадження важливою є також інтеграція з існуючими сервісами
наприклад, банківськими рахунками, календарями, сервісами зберігання даних, що
забезпечує користувачам повний контроль над особистими фінансами в одному
додатку.
Після завершення технічних і організаційних етапів, додаток переходить у
стадію масового використання, підтримується технічною командою та регулярно
оновлюється відповідно до потреб користувачів і змін у фінансовому середовищі.
76
ЧДТУ. 252353.001 ПЗ
Таким чином, впровадження не обмежується лише розгортанням системи, а є
безперервним процесом її розвитку, підтримки та адаптації до змін.
Етапи впровадження:
Планування впровадження:
− визначення цільової аудиторії, вимог до додатку, інфраструктури та
термінів запуску.
Підготовка середовища:
− налаштування серверів, створення облікових записів для команд, вибір
хостингу та CI/CD інструментів.
Тестовий запуск (beta):
− випуск бета-версії додатку для обмеженого кола користувачів; збір
зворотного зв'язку.
Навчання та документація:
− створення довідкових матеріалів, інструкцій, відео для користувачів та
технічної документації.
Моніторинг і підтримка:
− відстеження показників, виправлення помилок, обробка запитів
користувачів, оновлення додатку.
Основні функціональні компоненти системи:
Реєстрація та авторизація користувача:
− дозволяє створювати обліковий запис та входити в систему для захисту
персональних фінансових даних. Підтримує автентифікацію через email,
номер телефону або соціальні мережі.
Додавання витрат і доходів:
− користувач може швидко додати нову транзакцію з вибором категорії,
дати, суми, валюти та примітки. Підтримуються регулярні (повторювані)
платежі.
Аналітика та статистика:
77
ЧДТУ. 252353.001 ПЗ
− відображення графіків витрат і доходів за періодами, категоріями,
користувачами (у випадку спільного бюджету). Дозволяє відстежувати
фінансову стабільність і виявляти зайві витрати.
Бюджетування:
− можливість встановлювати ліміти на витрати в різних категоріях
(наприклад, "Їжа", "Транспорт"). Повідомлення при перевищенні ліміту.
Синхронізація з сервером:
− автоматичне збереження даних на сервері, що забезпечує доступ з різних
пристроїв, резервне копіювання та відновлення у разі втрати даних.
Функціональні компоненти мобільного додатку забезпечують
повноцінну, зручну та безпечну систему для щоденного фінансового
обліку користувачів. Вони охоплюють усі ключові аспекти фінансового
менеджменту — від внесення витрат і доходів до детального аналізу,
бюджетування та синхронізації з сервером.
78
ЧДТУ. 252353.001 ПЗ
ВИСНОВКИ ПО РОЗДІЛУ 3
У третьому розділі було детально розглянуто процес тестування мобільного
додатку для інтелектуального управління фінансами, який охоплює всі ключові
етапи - від модульного до приймального тестування. Це дозволило всебічно
оцінити якість, стабільність і функціональність програмного комплексу перед його
впровадженням у реальне користування.
Під час модульного тестування були перевірені окремі функціональні
частини програми: введення транзакцій, розрахунок балансу, обробка аналітичних
даних тощо. Це забезпечило впевненість у правильності логіки роботи окремих
модулів. Інтеграційне тестування підтвердило коректну взаємодію між
модулями, зокрема між інтерфейсом користувача, локальною базою даних та API-
сервером. Виявлені незначні помилки були виправлені до переходу до наступних
етапів.
На етапі системного тестування додаток було перевірено як єдину цілісну
систему, включаючи його відповідність до функціональних вимог, сумісність із
різними мобільними пристроями, роботу в офлайн-режимі та ефективність у
реальних сценаріях використання. Особливу увагу приділено перевірці інтерфейсу,
швидкодії, зручності користування та рівню безпеки.
Приймальне тестування продемонструвало готовність системи до
впровадження, оскільки усі критичні функції працюють стабільно та відповідають
очікуванням кінцевих користувачів. Було досягнуто високого рівня задоволення
вимог замовника щодо дизайну, функціональності та надійності.
Таким чином, результати всіх видів тестування свідчать про те, що
розроблений мобільний додаток є технічно досконалим, стабільним, зручним у
використанні та готовим до впровадження у реальних умовах для ефективного
управління особистими фінансами.
79
ЧДТУ. 252353.001 ПЗ
ВИСНОВКИ
У даній кваліфікаційній роботі було здійснено повний цикл розробки
мобільного додатку для управління особистими фінансами — від аналізу вимог до
впровадження та тестування програмного продукту.
У першому розділі було проаналізовано актуальність теми в умовах
сучасного цифрового середовища, де зростає потреба в зручних та ефективних
інструментах контролю над фінансами. Було вивчено існуючі рішення,
сформульовано вимоги до функціональності, безпеки, дизайну та сумісності.
У другому розділі описано процес проєктування архітектури мобільного
додатку, розробки основних функціональних компонентів — таких як реєстрація
та авторизація, облік доходів і витрат, аналітика, синхронізація з сервером та
робота в офлайн-режимі. Для реалізації застосовано сучасні технології та підходи
до розробки, що забезпечують зручність, продуктивність і масштабованість
додатку.
Третій розділ був присвячений тестуванню, де проведено модульне,
інтеграційне, системне та приймальне тестування. Це дозволило перевірити якість
роботи додатку, виявити та усунути недоліки, забезпечити стабільність і надійність
у різних сценаріях використання. Особливу увагу було приділено перевірці
безпеки, зручності інтерфейсу та швидкодії.
У результаті виконаної роботи було створено повнофункціональний
мобільний додаток, що дозволяє користувачам ефективно керувати особистими
фінансами, контролювати витрати, аналізувати фінансову активність та приймати
обґрунтовані рішення. Додаток є готовим до використання в реальному середовищі
та може бути основою для подальшого розвитку — зокрема, додавання штучного
інтелекту для прогнозування витрат або інтеграції з банківськими сервісами.
Окрім технічної реалізації, в рамках даної кваліфікаційної роботи було
сформовано чітку методологічну основу для проєктування та розробки мобільного
застосунку. Було враховано як технічні, так і користувацькі аспекти взаємодії з
додатком, що дозволило створити інтерфейс, інтуїтивно зрозумілий навіть для
користувачів без спеціальної підготовки. Застосовані дизайнерські рішення та UX-
80
ЧДТУ. 252353.001 ПЗ
патерни сприяють підвищенню зручності, що є особливо важливим фактором у
повсякденному використанні фінансових інструментів.
У процесі впровадження було приділено увагу питанню захисту
персональних даних, що має особливе значення в умовах посилення вимог до
кібербезпеки. Реалізовані механізми шифрування даних, автентифікації та
обмеження доступу відповідають базовим принципам безпечної розробки
програмного забезпечення. Це забезпечує захист конфіденційної фінансової
інформації користувачів від несанкціонованого доступу та витоків.
Також важливо зазначити, що створений програмний продукт має відкриту
та масштабовану архітектуру, що дозволяє легко адаптувати його під нові
функціональні вимоги або інтегрувати з іншими сервісами (наприклад,
банківськими API, платіжними платформами або сервісами для податкового
обліку). Це відкриває перспективи для подальшого розвитку системи — як у рамках
розширення функціоналу, так і шляхом інтеграції з екосистемами фінансових
послуг.
Таким чином, результати виконаної роботи демонструють повний цикл
створення сучасного мобільного застосунку — від концептуального проєктування
до реального впровадження, з урахуванням інженерних, програмних,
дизайнерських та користувацьких аспектів. Створений додаток може ефективно
використовуватись як окремими користувачами, так і бути частиною більш
широких фінансових рішень. Це свідчить про високу практичну цінність проєкту
та його відповідність сучасним вимогам до програмних продуктів у сфері FinTech.
81