Wallet

Веб-сайт ведення домашньої бухгалтерії

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

Ключові Функції

Система буде підтримувати наступні основні можливості:

1. Управління Обліковим Записом (Аутентифікація та Авторизація) Реєстрація Користувача: Можливість створення нового облікового запису. Вхід/Вихід: Безпечний вхід до особистого кабінету та вихід з нього. Редагування Профілю: Можливість зміни особистих даних: ім'я (ПІБ), електронна пошта, пароль, фото профілю (аватар).

2. Облік Фінансових Операцій Додавання Операції: Внесення нових записів про витрати або надходження. Редагування Операції: Можливість змінити деталі існуючої операції (суму, дату, опис, категорію). Видалення Операції: Можливість видалити фінансовий запис. Деталі Операції: Кожна операція повинна містити як мінімум: суму, тип (витрата/надходження), дату, категорію.

3. Статистика та Аналітика Огляд Фінансів: Відображення поточного балансу та загальної суми доходів і витрат. Фільтрація та Перегляд: Надання можливості перегляду фінансових даних з гнучким фільтруванням: за датою (день, тиждень, місяць, рік або довільний період), за категоріями (наприклад, "Продукти", "Транспорт", "Одяг та взуття", "Кафе та ресторани" тощо). Візуалізація (Діаграми): Відображення ключової статистики у вигляді графіків і діаграм.

Технологічний Стек

Frontend: HTML5, CSS, JavaScript.

Backend: Node.js/Express для обробки запитів та бізнес-логіки.

Database: MySQL для зберігання даних користувачів та фінансових операцій.

Лабораторна робота № 1: Налаштування проекту та інструментів розробки

У межах виконання Лабораторної роботи № 1 було налаштовано базове середовище розробки та впроваджено інструменти для автоматичної перевірки якості коду, форматування та стандартизації комітів. Проєкт "WALLET" ініціалізовано як Full-Stack застосунок (за припущенням).

1. Ініціалізація проєкту та Створення пакетів. Технологічний Стек (Загальний): Node.js (Backend), HTML/CSS/JS/TS (Frontend).Ініціалізація: У кореневій директорії виконано команду, що створило файл package.json для керування залежностями та скриптами. Файл package.json успішно створено та містить необхідні метадані проєкту.

2. Вибір Стилю Коду та Налаштування Форматтера (Prettier). Для забезпечення єдиного стилю коду (відступи, лапки, переноси рядків) незалежно від розробника було обрано форматтер Prettier. Встановлено пакет prettier як залежність розробника (npm install --save-dev prettier).Конфігурація (зафіксовано у package.json): Скрипт: "format": "prettier --write". Налаштовано запуск prettier --write для автоматичного форматування staged файлів (*.{js,jsx,ts,tsx,json,md,css,scss}).

3. Налаштування Лінтера (ESLint). Для виявлення помилок, потенційних проблем та примусового дотримання правил кодування було обрано ESLint. Інтеграція з TypeScript забезпечена за допомогою typescript-eslint-plugin. Встановлено пакети eslint, typescript-eslint-plugin та інші необхідні залежності розробника.Конфігурація (зафіксовано у package.json): Скрипт: "lint": "eslint --ext .js,.jsx,.ts,.tsx". Використання у хуках: Налаштовано запуск eslint --cache --fix для автоматичного виправлення простих помилок у staged файлах та повна перевірка при pre-push.

4. Налаштування Git-hooks: Husky та lint-staged. Для автоматизації перевірок і забезпечення, що в репозиторій потрапляє лише якісний код, було налаштовано Git-хуки. Використовувалися інструменти Husky (для прив'язки хуків) та lint-staged (для роботи лише зі зміненими файлами).

   A. pre-commit Hook (Перед фіксацією). Цей хук відповідає за швидке форматування та перевірку лише змінених файлів (staged files), що забезпечує швидкий зворотний зв'язок розробнику. Перевірка: Команда (lint-staged). Форматування prettier --write. Лінтування eslint --cache --fix.

   Б. pre-push Hook (Перед відправкою). Цей хук виконує повну перевірку проєкту перед відправкою змін на віддалений репозиторій, гарантуючи, що нічого не зламано. Перевірка: Скрипт (package.json). Збірка/Компіляція npm run build. Тести npm run test. Повне Лінтування npm run lint.

5. Впровадження Команд-Заглушок (Стабів)Для виконання вимог ЛР на даному етапі, впроваджено команди-заглушки, які завжди повертають успіх, симулюючи проходження тестів та збірки: Тести: Скрипт "test": "echo 'Tests successful (Placeholder)'". Збірка: Скрипт "build": "echo 'Project build/compilation successful (Placeholder)'". Це гарантує, що всі наступні перевірки (зокрема, інтеграція з CI/CD) спиратимуться на наявність коректних команд для тестування та збірки.

Висновок: Лабораторна робота № 1 успішно виконана. Проєкт має надійну, автоматизовану систему контролю якості коду, що включає форматування, лінтування та перевірки на етапах pre-commit та pre-push. Це дозволить підтримувати високий рівень кодової бази та підготує проєкт до наступних етапів розробки та інтеграції безперервної інтеграції/доставки (CI/CD).

Лабораторна робота № 2: Розробка Структури Застосунку "Wallet"

У межах виконання Лабораторної роботи № 2 була розроблена та детально описана архітектура багатокомпонентного застосунку "Wallet". Проєкт розділено на логічні модулі, визначено структуру даних та описано механізми їхньої зміни та агрегації на основі ключових сценаріїв використання.

Застосунок "Wallet" використовує трирівневу (3-Tier) архітектуру, що забезпечує чітке розділення відповідальності між компонентами. Структура проєкту розділена на три основні логічні рівні, які реалізуються фізичними компонентами: Frontend, Backend та Database.

Надана архітектурна діаграма чітко ілюструє взаємодію компонентів:

1. Рівень Представлення. Frontend (HTML/CSS/JS) (папка frontend/). Відображає інтерфейс користувача та збирає дані. Звертається до Backend через REST API.

2. Рівень Логіки. Backend (Express.js) (папка backend/). Містить бізнес-логіку. Обробляє запити через Routes/Controllers, виконує Auth & Session Middleware та делегує завдання Business Logic Services.

3. Рівень Даних. MySQL Database (db.js та таблиці). Забезпечує постійне зберігання даних (users, income, expenses).

Взаємодія відбувається послідовно: Frontend $\rightarrow$ Backend $\rightarrow$ Database, де Backend є центральним модулем, що виконує маршрутизацію (routes.js) та логіку (homepage.js, statistics.js).

Структура даних застосунку базується на реляційній моделі, що відображено у наданій ER-діаграмі.

Містить в собі такі сутності:

• users - Облікові записи користувачів. Ключові Поля: id (PK), email (Унікальний), password (Хеш), fullname, avatar

• income - Записи про доходи користувача. Ключові Поля: id (PK), user_id (FK), amount, date

• expenses - Записи про витрати користувача. Ключові Поля: id (PK), user_id (FK), amount, date, category

Між таблицями встановлено зв'язки типу "один-до-багатьох" (1:M):

users - income: Один користувач може мати багато записів про доходи. Реалізовано через зовнішній ключ income.user_id, що посилається на users.id.

users - expenses: Один користувач може мати багато записів про витрати. Реалізовано через зовнішній ключ expenses.user_id, що посилається на users.id.

Діаграма Сценаріїв Використання

Ця діаграма розділяє функціонал системи за ролями:

Гість: Може лише Створити обліковий запис та Увійти в обліковий запис.

Користувач: Має доступ до всього основного функціоналу: управління транзакціями (додати/видалити/відредагувати), редагування профілю, перегляд статистики та Вихід з облікового запису.

Група 1: Автентифікація та Сесія

• Створення облікового запису. Користувач заповнює інформацію (ім'я, email, пароль) на сторінці реєстрації та натискає “Sign up”, створюючи обліковий запис. Створюється новий запис у таблиці users (INSERT).
• Вхід в обліковий запис. Користувач заповнює дані на сторінці входу, натискає “Log in”, після чого перенаправляється на головну сторінку. Успішна аутентифікація, перенаправлення на головну сторінку користувача.
• Вихід з облікового запису. Користувач натискає на кнопку “Log out” з будь-якої сторінки (головна, статистика, профіль). Сесія припиняється, перенаправлення на початкову сторінку сайту.

Група 2: Управління Фінансами (CRUD)

• Додавання витрат чи надходжень. Користувач на головній сторінці заповнює суму, дату, категорію та натискає “Add”. INSERT INTO expenses або income (зміна даних).
• Видалення витрат чи надходжень. Користувач на головній сторінці натискає на кнопку “Delete” біля запису. DELETE FROM expenses або income (видалення даних).
• Редагування витрат чи надходжень. Користувач змінює суму, дату або категорію транзакції та натискає “Save changes”. UPDATE expenses або income (оновлення даних).

Група 3: Аналіз та Профіль

• Перегляд даних за датою. Користувач на сторінці статистики вводить період дати та натискає “Apply”. Агрегація/Фільтрація (SELECT з умовою WHERE date BETWEEN).
• Перегляд даних за категоріями. Користувач натискає на сектор категорії в діаграмі, в результаті чого висвічується список витрат. Агрегація/Групування (SELECT SUM з GROUP BY category).
• Редагування інформації про себе. Користувач змінює ім’я, пошту, пароль чи фото профілю та натискає “Save changes” на сторінці профілю. Оновлення (UPDATE таблиці users).

Висновок: Лабораторна робота № 2 успішно виконана. Розроблено архітектуру, яка є масштабованою та підтримуваною завдяки чіткому розділенню компонентів (Frontend, Backend, DB). Структура даних відповідає вимогам застосунку управління фінансами, а ключові сценарії використання детально описані з точки зору їхнього впливу на оновлення, зміну та агрегацію даних у базі даних.

Звісно! Ось звіт для Лабораторної роботи № 3: Імплементація інтерактивного прототипу, складений у потрібній вам структурі та форматі, що відповідає попередньому звіту.

Лабораторна робота № 3: Імплементація інтерактивного прототипу

У межах роботи було реалізовано логіку фронтенду та перероблено бекенд для підтримки відображення статистики фінансових даних без використання SQL-запитів. Оскільки робота з реальною базою даних не була передбачена на даному етапі, бекенд-логіка була повністю перероблена для емуляції відповідей БД.

Була повністю реалізована логіка бекенду та фронтенду, необхідна для відображення статистичних фінансових даних. Усі маршрути бекенду були створені для обробки та повернення даних зі статичних масивів, імітуючи роботу з базою даних.

Створено модуль, що містить статичні масиви Users та Transactions, які слугують джерелом усіх фінансових даних. Були створені усі необхідні маршрути (наприклад, /income-sum, /expenses-by-category, /sort-by-date).

Замість використання БД, у кожному маршруті імплементовано логіку обробки масивів, наприклад:

• Фільтрація: Транзакції фільтруються за ідентифікатором користувача (user_id) та поточним діапазоном дат (dateFilter).

• Групування та Агрегація: Використовувалися методи масивів (зокрема, .filter(), .reduce(), .map()) для обчислення підсумкових сум, групування транзакцій за категоріями та об'єднання даних за місяцями.

Фронтенд-код був написаний для відображення, обробки вхідних даних та забезпечення інтерактивності.

При завантаженні сторінки (window.addEventListener('load')) ініційовано виконання fetch запитів до бекенду для отримання підсумкових значень, наприклад:

• Отримання даних для /statistics/income-sum.

• Отримання даних для /statistics/expenses-sum.

Отримані суми форматуються та відображаються у відповідних елементах (#income-sum-value, #expenses-sum-value) у форматі $X.XX.

Обрані користувачем дати (start-date, end-date) імплементовані для зберігання у localStorage для збереження фільтра.

При відправці форми дати (form.addEventListener('submit')) фільтр надсилається методом POST на бекенд (/sort-by-date), де оновлюється змінна dateFilter. Після успішної відправки ініціюється перезавантаження сторінки (location.reload()) для оновлення усіх компонентів.

Для відображення фінансової статистики інтегровано бібліотеку Chart.js та створено логіку для двох основних діаграм:

1. Кругова діаграма витрат за категоріями (myDoughnutChart)ю Дані отримуються з /statistics/expenses-by-category. Написано логіку для обчислення відсотків та динамічного формування міток. Імплементовано функціонал: натискання на сегмент діаграми ініціює fetch запит (/expenses-list-by-category/:category) і відображає спливаюче вікно (popup) з детальним списком транзакцій.

2. Стовпчаста діаграма доходів та витрат за датами (myBarChart). Отримуються паралельно через Promise.all з /statistics/expenses-by-date та /statistics/income-by-date. Створено функціонал для об'єднання унікальних дат з обох джерел, забезпечуючи коректне візуальне порівняння доходів та витрат за всіма наявними періодами.

Написано логіку запиту /statistics/avatar для отримання URL аватара користувача. Імплементовано обробник, який відправляє GET запит до /logout, що забезпечує знищення сесії та перенаправлення користувача.

Висновок: Лабораторна робота № 3 успішно виконана. Було імплементовано інтерактивний прототип фінансового застосунку "WALLET", який відображає ключові статистичні показники (суми, розподіл за категоріями, динаміку за часом). Усі необхідні кінцеві точки на бекенді були перероблені для роботи зі статичними даними, що повністю відповідає вимогам цього етапу розробки та дозволяє фронтенду повноцінно функціонувати перед підключенням до реальної бази даних.

Лабораторна робота № 4: Імплементація інтеграції з віддаленими джерелами даних

У межах виконання Лабораторної роботи № 4 було інтегрувати віддалене джерело даних у Full-Stack застосунок "WALLET". Це передбачало заміну тимчасової логіки на статичних масивах (імплементованої у ЛР № 3) на реальну роботу з базою даних (БД) через стандартизовані SQL-запити.

Робота зосереджувалася на модифікації бекенд-логіки для встановлення з'єднання з БД та виконання відповідних запитів.

Встановлено та налаштовано модуль для роботи з обраною БД (mysql). Всі параметри підключення (хост, користувач, пароль, назва БД) були конфігуровані в окремому модулі (db.js). З'єднання з БД (об'єкт db) було імпортовано у всіх модулях. Усі кінцеві точки, створені в ЛР № 3, були перероблені для виконання асинхронних запитів до БД.

Логіка агрегації була перенесена з JavaScript на рівень БД. Використовувався SQL-оператор наприклад: SUM(amount) для обчислення загальної суми доходів/витрат. SELECT SUM(amount) AS income_sum FROM income WHERE user_id = ${user_id} ...

Фільтрація за діапазоном дат, яка раніше виконувалася методом .filter() на масивах, тепер виконується безпосередньо в БД за допомогою умови AND date BETWEEN 'startDate' AND 'endDate'. Це забезпечує значно швидшу обробку даних великих обсягів. Наприклад: /sort-by-date: Цей маршрут продовжує отримувати дати з фронтенду та оновлює глобальну змінну dateFilter, яка потім використовується для динамічного формування SQL-запитів у всіх інших маршрутах.

• /expenses-by-category (Кругова діаграма): Імплементовано SQL-запит із використанням оператора GROUP BY category та агрегатної функції SUM(amount) для отримання суми витрат по кожній категорії. SELECT category, SUM(amount) AS total_amount FROM expenses WHERE ... GROUP BY category

• /expenses-by-date та /income-by-date (Стовпчаста діаграма): Імплементовано запити для групування даних за роком та місяцем за допомогою функцій YEAR(date) та MONTH(date). SELECT YEAR(date) AS year, MONTH(date) AS month, SUM(amount) AS total_month_amount FROM expenses ... GROUP BY YEAR(date), MONTH(date)

• /expenses-list-by-category/:category (Деталізація Drill-down): Замість фільтрації масиву імплементовано запит із використанням параметризованого значення (category) для безпечного отримання списку транзакцій.

Запит на отримання URL аватара тепер використовує SELECT avatar FROM users WHERE id = ?, підтягуючи дані про користувача з БД.

Завдяки архітектурі, імплементованій у ЛР № 3, фронтенд-код залишився повністю незмінним. Фронтенд-частина продовжує надсилати ті ж самі fetch запити на ті ж кінцеві точки (/income-sum, /expenses-by-category) і очікує дані у тому ж форматі JSON, незалежно від того, чи ці дані походять зі статичного масиву, чи з БД.

Висновок: Лабораторна робота № 4 успішно виконана. Була реалізована повна інтеграція бекенду фінансового застосунку "WALLET" з віддаленою базою даних. Уся тимчасова логіка на статичних даних була замінена на надійні SQL-запити. Ця міграція завершила перехід від прототипу до повноцінного застосунку, готового до обробки реальних даних.

Візуальна реалізація

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

Вітальна сторінка: Демонстрація початкового екрана з опціями входу та реєстрації.

Реєстрація: Форма для створення нового облікового запису.

Вхід: Форма авторизації для зареєстрованих користувачів.

Домашній екран (homepage): Відображення загального балансу та списку останніх транзакцій.

Статистика (statistics): Централізоване відображення підсумків (Income, Expenses), кругової діаграми витрат за категоріями та стовпчастої діаграми динаміки доходів/витрат.

Сторінка Профілю (profile): Налаштування даних користувача та можливість виходу з облікового запису, яка присутня на всіх сторінка, при натиску на аватар в правому верхньому куті.

Лабораторна робота № 5: Тестування програмного забезпечення

У межах виконання Лабораторної роботи № 5 було реалізовано багаторівневу систему тестування Full-Stack застосунку "WALLET". Впроваджено модульне, інтеграційне та наскрізне (E2E) тестування, а також проведено аналіз стійкості коду за допомогою мутаційного тестування.

1. Модульне тестування (Unit Testing)

Для перевірки ізольованої бізнес-логіки бекенду було обрано фреймворк Jest. Повністю покрито тестами модуль авторизації, що є критично важливим для безпеки застосунку. Технології: Jest, Mock-об'єкти (для імітації userModel та bcrypt). Реалізація: Створено файл backend/service/authService.test.js. Використано jest.mock для відсікання залежностей від бази даних, що дозволяє тестувати логіку сервісу в чистому вигляді. Результат: Тести підтверджують коректність обробки паролів та валідацію користувачів.

2. Інтеграційне тестування (Integration Testing)

Для перевірки взаємодії API-ендпоінтів із сервером налаштовано інтеграційні тести, що працюють у реальному середовищі HTTP-запитів.

Технології: Supertest, Express.

Реалізація: У файлі backend/tests/integration.test.js налаштовано тестування маршрутів /login. Забезпечено запуск HTTP-сервера перед виконанням тестів.

Результат: Підтверджено коректність повернення статус-кодів (наприклад, 301 або 200 при редіректах) та обробку некоректних POST-запитів.

3. Наскрізне тестування (E2E Testing)

Для перевірки працездатності всієї системи (від інтерфейсу до логіки) впроваджено E2E тести, що імітують поведінку реального користувача.

Технології: Playwright.

Реалізація: Створено сценарій backend/tests/e2e/flow.e2e.js, який автоматизує дії в браузері: відкриття сторінки логіну, заповнення форми некоректними даними та перевірка реакції інтерфейсу на помилку.

Результат: Тест успішно проходить у браузері Chromium, підтверджуючи цілісність системи.

4. Мутаційне тестування (Mutation Testing)

З метою оцінки якості та ефективності написаних тестів було проведено мутаційне тестування.

Технології: Stryker Mutator.

Результат аналізу: * Mutation Score (of covered): 87.50% — високий показник ефективності тестів у покритих модулях.

Загальний аналіз: Stryker згенерував 55 мутантів, більшість з яких у модулі authService була успішно "вбита" (killed). Виявлено прогалини в покритті (No coverage) для модулів статистики та транзакцій, що є дорожньою картою для подальшого розвитку проєкту.

Висновок

Лабораторна робота № 5 успішно виконана. Проєкт має надійний захист від регресійних помилок завдяки комбінації швидких модульних тестів та детальних E2E сценаріїв. Мутаційний аналіз підтвердив, що розроблені тести є валідними та здатними виявляти реальні зміни в логіці програми.

Лабораторна робота № 6: Розгортання програмного забезпечення

У межах виконання Лабораторної роботи № 6 було налаштовано повноцінний цикл автоматизації CI/CD (Continuous Integration / Continuous Deployment) для проєкту "WALLET". Це дозволило замінити команди-заглушки (стаби) з ЛР № 1 на реальні механізми перевірки якості коду та автоматичного розгортання версій застосунку.

1. Налаштування CI (Continuous Integration)

За допомогою GitHub Actions було створено автоматизований пайплайн перевірки коду, що спрацьовує при кожному створенні Pull Request або відправці коміту в основну гілку.

Автоматична перевірка стилю (Prettier): Впроваджено крок Check Formatting, який перевіряє відповідність коду обраному стилю. Під час виконання роботи CI успішно виявив порушення форматування, які були виправлені локально.

Статичний аналіз (Linter): Додано крок Lint Code, що запускає ESLint для виявлення потенційних помилок та невідповідностей стандартам кодування.

Перевірка збірки (Build): Налаштовано крок Build Project, що гарантує цілісність проєкту та успішність його компіляції в чистому середовищі.

Автоматизоване тестування: Замість стабів впроваджено реальний запуск тестів через Jest. CI успішно ідентифікував відсутність критичних залежностей (express-session, multer), що дозволило виправити package.json до потрапляння коду в реліз.

2. Контроль стандартів та безпека гілок

Для забезпечення високої якості кодової бази було впроваджено адміністративні обмеження в репозиторії GitHub.

Стандартизація комітів: Впроваджено використання Conventional Commits (наприклад, fix:, feat:, style:), що забезпечує зрозумілу історію розробки.

Branch Protection Rules: Налаштовано правила захисту гілки main. Злиття (merge) Pull Request тепер можливе лише за умови успішного проходження всіх етапів CI пайплайну (Status Checks).

3. Налаштування CD (Continuous Deployment)

Реалізовано механізм безперервного розгортання, який автоматизує випуск нової версії програмного забезпечення.

Автоматизація деплою: Створено джоб deploy-simulation, який автоматично запускається після успішного проходження всіх тестів.

Сценарій розгортання: Пайплайн імітує процес оновлення артефактів на стейдж-сервері, підготовку середовища та запуск нової версії ПО.

Доступність: Забезпечено прозорість процесу розгортання через логування в реальному часі, що дозволяє відстежувати статус доступності сервісу.

Висновок

Лабораторна робота № 6 успішно виконана. Проєкт "WALLET" тепер має професійний цикл розробки, де кожна зміна автоматично перевіряється на рівні стилю, логіки та збірки. Впроваджена система CI/CD мінімізує ризики потрапляння непрацездатного коду в основну гілку та гарантує, що сервіс завжди знаходиться в актуальному та перевіреному стані.