WEB-застосунок ведення бухгалтерського обліку вантажної станції технічного обслуговування

Ніколаєнко, Анна Ігорівна
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9033
Title:	WEB-застосунок ведення бухгалтерського обліку вантажної станції технічного обслуговування
Authors:	Куницька, Світлана Юріївна Ніколаєнко, Анна Ігорівна
Keywords:	ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ;JAVASCRIPT;ПОСЛУГА;NODE.JS;ФІНАНСОВИЙ ЗВІТ;POSTGRESQL;ВАНТАЖНА СТАНЦІЯ ТЕХНІЧНОГО ОБСЛУГОВУВАННЯ;ACCOUNTING;SERVICE;CLIENT;MECHANIC;FINANCIAL REPORT;COST ANALYSIS;TRUCK SERVICE STATION
Issue Date:	7-Jun-2025
Abstract:	АНОТАЦІЯ Ніколаєнко А.І., кваліфікаційна робота на тему «WEB-застосунок ведення бухгалтерського обліку вантажної станції технічного обслуговування». Напрям підготовки 121 «Інженерія програмного забезпечення», ЧДТУ, Черкаси, 2025. Мета виконання кваліфікаційної роботи бакалавра: проектування та конструювання web-застосунку для зручної автоматизації фінансових процесів та забезпечення взаємодії між користувачами. Завдання при проектуванні інформаційної системи: провести аналіз існуючих рішень, визначити їхні переваги та недоліки, а також сформулювати основні вимоги на основі дослідження конкурентного ринку; визначити функціональні та нефункціональні вимоги як замовника, так і розробника; створити діаграми, що відображають архітектуру системи та взаємодію її компонентів; обґрунтувати вибір інструментів розробки; описати додаток за допомогою структурних і функціональних схем; розробити базу даних, інтерфейс користувача та програмні модулі; провести тестування на всіх рівнях; підготувати інструкцію користувача. Об'єкт роботи: процес розробки web-застосунку для ведення бухгалтерського обліку вантажної станції технічного обслуговування. Предмет розробки: процес розробки програмного забезпечення для ведення бухгалтерського обліку вантажної станції технічного обслуговування. Вирішено наступні поставлені задачі: 1. Проаналізувати існуючі аналоги web-застосунку. 2. Розробити взаємопов’язаних елементів web-додатку та створити діаграми для представлення архітектури системи та компонентів через їхню взаємодію. 3. Розробити базу даних інформаційної системи. 4. Розробити інтерфейсну частину спроектованого web-застосунку. 5. Протестувати та впровадити розроблене програмного забезпечення. Обсяг роботи пояснювальної записки – 117 сторінок, вона містить 3 розділи, 87 рисунків, 15 таблиць, 17 джерел в списку посилань, 4 додатки. ANNOTATION Nikolaienko A.I., qualification work on the topic «WEB application for accounting of a freight service station». Study program 121 “Software Engineering”, CSTU, Cherkasy, 2025. The purpose of the bachelor's thesis is to create a web application for convenient automation of financial processes and interaction between users. The main tasks in designing an information system: to analyze existing solutions, identify their advantages and disadvantages, and formulate basic requirements based on competitive market research; identify functional and non-functional requirements of both the customer and the developer; create diagrams that reflect the system architecture and interaction of its components; justify the choice of development tools; describe the application using structural and functional diagrams; develop a database, user interface and program modules; conduct testing at all levels; prepare a user manual; prepare a user guide. The object of work is the process of developing a web application for accounting of a freight service station. The subject of development is software for accounting of a freight service station. The following tasks were solved: 1. Analyze the existing analogues of the web application; 2. Develop interconnected elements of a web application and create diagrams to represent the architecture of the system and components through their interaction; 3. Develop the information system database; 4. Develop the interface part of the designed web application. 5. Test and implement the developed software. The volume of the work is __ pages, it contains 3 chapters, __ images, __ sources in the list of references, 4 appendices.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/9033
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Files in This Item:
File	Description	Size	Format
кваліфікаційна робота бакалавра Ніколаєнко Анна Ігорівна.pdf Restricted Access		4.58 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
бакалавра 
      на тему:  «WEB-застосунок ведення бухгалтерського обліку вантажної 
станції технічного обслуговування» 
 
                                                          Виконала: студентка 4 курсу, групи ПЗ-2104 
                                                          спеціальності  
              121 «Інженерія програмного забезпечення»  
 
Студент Ніколаєнко А. І. 
 (прізвище та ініціали) 
Керівник  Куницька С. Ю. 
 (прізвище та ініціали) 
Рецензент  Захарова М. В. 
 (прізвище та ініціали) 
 
Черкаси 2025 
 482.ЧДТУ.252163 90 01 2 
Черкаський державний технологічний університет 
  
Факультет інформаційних технологій і систем  
Кафедра  програмного забезпечення автоматизованих систем   
Освітній рівень  бакалавр  
Спеціальність 121 «Інженерія програмного забезпечення»  
Освітня програма Інженерія програмного забезпечення  
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС,  
д.т.н., професор 
__________________Сергій  ГОЛУБ 
«___» _______________ 2025 року 
 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
 
Ніколаєнко Анні Ігорівні 
 
1. Тема роботи: «WEB-застосунок ведення бухгалтерського обліку вантажної станції 
технічного обслуговування»____________________________________________________ 
Керівник роботи к.т.н., доцент Куницька Світлана Юріївна________________________________ 
Затверджені наказом Черкаського державного технологічного університету №_53/03-03_______ 
від «25» ______02_____ 2025 року  
2. Строк подання студентом роботи _02.06.2025_____________________________________ 
3. Вхідні дані до роботи: Microsoft Office, Microsoft Word, Windows, Visual Studio Code, 
PostgreSQL__________________________________________________________________ 
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)  
1 Існуючі методи та засоби розв’язання поставлених завдань;______________________________ 
2 Впровадження результатів досліджень у практику проектування програмного забезпечення 
інформаційних систем;______________________________________________________________ 
3 Розробка та тестування програмного забезпечення;____________________________________ 
Висновки;_________________________________________________________________________ 
Список використаних джерел;________________________________________________________ 
Додатки.__________________________________________________________________________ 
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;  
Додаток А – Специфікація_____________________________________________________ 
Додаток Б – Текст програми розробки___________________________________________ 
Додаток В – Інструкція користувачеві___________________________________________ 
141 
 482.ЧДТУ.252163 90 01 2 
Додаток Г – Графічні матеріали________________________________________________ 
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 Рецензування роботи    .05.2025 виконано 
6 Захист роботи 06.06.2025 виконано 
 
 
 
Студент _____________________ Ніколаєнко А. І. 
 
Керівник роботи _____________________ Куницька С. Ю. 
 
 
 
 
 
 
 
142 
 482.ЧДТУ.252163 90 01 2 
АНОТАЦІЯ 
 
Ніколаєнко А.І., кваліфікаційна робота на тему «WEB-застосунок ведення 
бухгалтерського обліку вантажної станції технічного обслуговування». Напрям 
підготовки 121 «Інженерія програмного забезпечення», ЧДТУ, Черкаси, 2025. 
Мета виконання кваліфікаційної роботи бакалавра: проектування та 
конструювання web-застосунку для зручної автоматизації фінансових процесів та 
забезпечення взаємодії між користувачами. 
Завдання при проектуванні інформаційної системи: провести аналіз 
існуючих рішень, визначити їхні переваги та недоліки, а також сформулювати 
основні вимоги на основі дослідження конкурентного ринку; визначити 
функціональні та нефункціональні вимоги як замовника, так і розробника; створити 
діаграми, що відображають архітектуру системи та взаємодію її компонентів ; 
обґрунтувати вибір інструментів розробки; описати додаток за допомогою 
структурних і функціональних схем; розробити базу даних, інтерфейс користувача 
та програмні модулі; провести тестування на всіх рівнях; підготувати інструкцію 
користувача. 
Об'єкт роботи: процес розробки web-застосунку для ведення 
бухгалтерського обліку вантажної станції технічного обслуговування. 
Предмет розробки: процес розробки програмного забезпечення для ведення 
бухгалтерського обліку вантажної станції технічного обслуговування.  
Вирішено наступні поставлені задачі: 
1. Проаналізувати існуючі аналоги web-застосунку. 
2. Розробити взаємопов’язаних елементів web-додатку та створити діаграми 
для представлення архітектури системи та компонентів через їхню 
взаємодію. 
3. Розробити базу даних інформаційної системи. 
4. Розробити інтерфейсну частину спроектованого web-застосунку. 
5. Протестувати та впровадити розроблене програмного забезпечення. 
143 
 482.ЧДТУ.252163 90 01 2 
Обсяг роботи пояснювальної записки – 117 сторінок, вона містить 3 розділи, 
87 рисунків, 15 таблиць,  17 джерел в списку посилань, 4 додатки. 
 
Ключові слова: ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ, JAVASCRIPT, 
ПОСЛУГА, NODE.JS ФІНАНСОВИЙ ЗВІТ, POSTGRESQL, ВАНТАЖНА 
СТАНЦІЯ ТЕХНІЧНОГО ОБСЛУГОВУВАННЯ. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
144 
 482.ЧДТУ.252163 90 01 2 
ANNOTATION 
 
Nikolaienko A.I., qualification work on the topic «WEB application for accounting 
of a freight service station». Study program 121 “Software Engineering”, CSTU, 
Cherkasy, 2025. 
The purpose of the bachelor's thesis is to create a web application for convenient 
automation of financial processes and interaction between users. 
The main tasks in designing an information system: to analyze existing solutions, 
identify their advantages and disadvantages, and formulate basic requirements based on 
competitive market research; identify functional and non-functional requirements of both 
the customer and the developer; create diagrams that reflect the system architecture and 
interaction of its components; justify the choice of development tools; describe the 
application using structural and functional diagrams; develop a database, user interface 
and program modules; conduct testing at all levels; prepare a user manual; prepare a user 
guide. 
The object of work is the process of developing a web application for accounting 
of a freight service station. 
The subject of development is software for accounting of a freight service station. 
The following tasks were solved: 
1. Analyze the existing analogues of the web application; 
2. Develop interconnected elements of a web application and create diagrams to 
represent the architecture of the system and components through their 
interaction; 
3. Develop the information system database; 
4. Develop the interface part of the designed web application. 
5. Test and implement the developed software. 
The volume of the work is __ pages, it contains 3 chapters, __ images, __ sources 
in the list of references, 4 appendices. 
Keywords: ACCOUNTING, SERVICE, CLIENT, MECHANIC, FINANCIAL 
REPORT, COST ANALYSIS, TRUCK SERVICE STATION (TSO). 
145 
 482.ЧДТУ.252163 90 01 2 
 
ЗМІСТ 
 
ВСТУП…………………………………………………………………………..5 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ…………………………………………………………9 
1.1 Існуючі методи до розв’язання поставленого завдання ……………….9 
1.2 Огляд аналогів………………………………………………………..…10 
1.3 Сформовані задачі для проектування…………………………….…...14 
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ……………………………….….17 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ……………………………………………………………………………...19 
2.1 Моделювання предметної області……………………………………..19 
2.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області…………………………………………….……..19 
2.1.2 Елементи моделювання предметної області……………….…….22 
2.1.3 Робоча область моделювання……………………………….…….23 
2.2 Формування та аналіз вимог……………………………………….…..23 
2.2.1 Формування вимог до програмного забезпечення. Первинні і 
детальні вимоги. Вимоги замовника і розробника. Функціональні та 
нефункціональні вимоги……………………………………………………..…24 
2.2.2 Формування вимог за діаграмою прецедентів…………………...28 
2.3 Проектування логічної структури………………………………….….29 
2.3.1 Діаграми класів………………………………………………….…30 
2.3.2 Діаграми пакетів…………………………………………………...34 
2.4 Архітектурне проектування…………………………………………....35 
2.4.1 Діаграма компонентів………………………………………….…..36 
 
 
ЧДТУ.252163.015 ПЗ 
Змн . Арк. № докум. Підпис Дата 
 Розроб.   Ніколаєнко А.І. «Web-застосунок ведення Літ. Лист Листів 
 Перевір.     Куницька С.Ю. бухгалтерського обліку вантажної станції 3  
 Рец ензент Захарова М.В. технічного обслуговування» 
 Н. Контр.   Півень О.Б. ФІТІС, кафедра ПЗАС, ПЗ-2104 
Пояснювальна записка. 
 Затверд.  Голуб С.В. 
146 
 482.ЧДТУ.252163 90 01 2 
 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання…………………………………………………………………….37 
2.5 Моделювання поведінки системи………………………………….....39 
2.5.1 Діаграма діяльності……………………………………………….39 
2.5.2 Діаграма послідовності…………………………………………...46 
2.5.3 Діаграма комунікації……………………………………………...60 
2.5.4 Діаграма скінченного автомату…………………………………..64 
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ…………………………………...66 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ ……………………………………………………………………67 
3.1 Розробка програмного комплексу…………………………………….67 
3.1.1 Обґрунтування вибору засобів реалізації………………………..67 
3.1.2 Опис структурної (функціональної) схеми……………………...69 
3.1.3 Опис логічної схеми системи…………………………………….72 
3.1.4 Розробка бази даних………………………………………………73 
3.1.5 Розробка інтерфейсу користувача………………………………..79 
3.1.6 Опис розробки програмних компонентів………………………..92 
3.2 Тестування системи……………………………………………………95 
3.2.1 Модульне тестування……………………………………………..95 
3.2.2 Інтеграційне тестування…………………………………………..97 
3.2.3 Системне тестування……………………………………………...98 
3.2.4 Приймальне тестування…………………………………………..100 
3.3 Приклади впровадженого програмного комплексу…………………101 
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ………………………………….112 
ВИСНОВКИ…………………………………………………………………..113 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ…………………………………….115 
Додаток А……………………………………..……………………………….118 
Додаток Б……………………………………………………………………....120 
Додаток В……………………………………………………………………...134 
Додаток Г……………………………………………………………………...140 
 
 
ЧДТУ.252163.015 ПЗ 
Змн. Арк. № докум. Підпис Дата 
     147 
 482.ЧДТУ.252163 90 01 2 
ВСТУП 
Актуальність теми. Актуальність теми визначається потребою в розробці 
web-додатку для забезпечення потреб вантажних станцій технічного 
обслуговування (ВСТО), а саме необхідністю автоматизації та оптимізації 
складних бізнес-процесів, таких як облік фінансових потоків і управління 
ремонтами. Створення такого рішення – це складна інженерна задача, яка потребує 
впровадження сучасних технологій для розробки стабільного, масштабованого та 
захищеного програмного продукту, котрий зменшить вірогідність помилок та 
посилить контроль за кожною операцією підприємства. 
Мета і завдання розробки. Метою є проектування та конструювання  
програмного забезпечення, яке забезпечить задоволення потреб користувачів. 
Додаток покликаний мінімізувати ручну обробку даних, підвищити точність 
бухгалтерського обліку та спростити фінансовий контроль на підприємстві. 
Задачі розробки: 
6. Проаналізувати існуючі аналоги web-застосунку. 
7. Розробити взаємопов’язаних елементів web-додатку та створити діаграми 
для представлення архітектури системи та компонентів через їхню 
взаємодію. 
8. Розробити базу даних інформаційної системи. 
9. Розробити інтерфейсну частину спроектованого web-застосунку. 
10. Протестувати та впровадити розроблене програмного забезпечення. 
Об’єкт розробки 
Об'єктом роботи є процес розробки web-застосунку для ведення 
бухгалтерського обліку вантажної станції технічного обслуговування. 
Предмет розробки 
Предметом розробки є процес розробки програмного забезпечення для 
ведення бухгалтерського обліку вантажної станції технічного обслуговування.  
Методи проектування та конструювання. Для проектування web-додатку 
для ведення бухгалтерського обліку вантажної станції технічного обслуговування 
використовувалася ітеративна модель розробки програмного забезпечення [12] з  
148 
 482.ЧДТУ.252163 90 01 2 
функціонально-орієнтованим (структурним) методом проектування. Також для 
побудови використовується архітектурний шаблон MVC (Model-View-Controller) 
[4]. 
Ітеративна модель передбачає розбиття проєкту на цикли (ітерації) та 
проходження етапів життєвого циклу на кожному з них. Після кожної ітерації 
отримується робочий прототип, який може бути протестований та вдосконалений  
[2]. 
Проектування фокусується на розбитті системи на ієрархію модулів з чітко 
визначеними інтерфейсами та контролем потоку даних [3].  
Ключові принципи функціонально-орієнтованого методу включають: 
− розбиття на модулі: система декомпозується на ієрархію невеликих, 
функціонально незалежних модулів. Кожен модуль виконує певну 
визначену задачу; 
− ієрархічна організація: модулі організовуються в ієрархічну структуру, 
що відображає їхні відносини та рівні абстракції; 
− чіткі інтерфейси: кожен модуль має чітко визначені вхідні та вихідні 
параметри, що полегшує його взаємодію з іншими модулями та зменшує 
залежність між ними; 
− контроль потоку даних: увага приділяється тому, як дані передаються між 
модулями; 
− структурне програмування: в межах кожного модуля використовуються  
структурні керуючі конструкції (послідовність, розгалуження, цикли) без 
використання операторів безумовного переходу; 
− зв'язність: структурне проектування прагне до мінімізації зв'язності, щоб 
зміни в одному модулі якомога менше впливали на інші; 
− згуртованість: структурне проектування прагне до високої згуртованості, 
де всі елементи модуля спрямовані на виконання однієї чіткої задачі.  
Для конструювання програмного забезпечення використовувалися такі 
методи: 
149 
 482.ЧДТУ.252163 90 01 2 
− конструювання користувацького інтерфейсу: цей метод включає 
створення простого і зрозумілого представлення системи для взаємодії з 
користувачем; 
− розробка серверної частини: цей метод передбачає створення серверу для 
обробки запитів з клієнтської частини системи до бази даних; 
− інтеграція бази даних: створення пов’язаних таблиць для збереження 
даних замовлень, ресурсів, послуг, користувачів, витрат, звітів та 
підключення до системи, що була розроблена; 
− реалізація функцій: розробка функцій для виконання поставлених вимог 
до web-додатку; 
− тестування: метод передбачає проведення тестування сценаріїв 
використання та оцінку результатів. 
Опис отриманих результатів 
В результаті було розроблено web-застосунок для ведення бухгалтерського 
обліку вантажної станції технічного обслуговування та виконано поставлені задачі: 
проведено дослідження аналогів, створено UML діаграми для відображення 
архітектури системи, розроблено базу даних за допомогою PostgeSQL, створено 
інтерфейсну частину з урахуванням вимог до функціоналу та успішно 
протестовано на всіх рівнях. 
Практичне значення отриманих результатів 
Розроблений web-застосунок для ведення бухгалтерського обліку вантажної 
станції технічного обслуговування надає зручний функціонал для створення 
замовлень, обліку витрат і відслідковування фінансових потоків. Система об’єднує 
процеси обробки замовлень, внесення інформації для створення замовлень, 
відслідковування ресурсів на складі та відстеження витрат. Інтерфейс, розділений 
за типами користувачів, надає можливість швидко опанувати використання 
системи і усунути більшість помилок людського фактору. 
Особистий внесок автора 
Роботу було апробовано на Днях студентської науки ЧДТУ, Черкаси, 2025, 
Україна та на XI Міжнародній науково-практичній конференції «SCIENTIFIC 
150 
 482.ЧДТУ.252163 90 01 2 
ACHIEVEMENTS OF CONTEMPORARY SOCIETY», 29-31 травня 2025, Лондон, 
Великобританія [1]. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
151 
 482.ЧДТУ.252163 90 01 2 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
 
Веб-додаток має забезпечити зручний інструмент для роботи як для 
механіків, бухгалтерів, так і для менеджерів. Основними функціями будуть 
керування доступом користувачів, створення та редагування замовлень, генерація 
звітів про доходи та витрати, можливість друку чека, додавання інформації про 
послуги, що надаються, ресурси, замовників та витрат до системи для збереження 
та обробки.  
Важливим є зберігання великого обсягу даних, зокрема замовлень та 
можливість масштабування додатку у разі збільшення обсягів діяльності станції.  
 
1.1 Існуючі методи до розв’язання поставленого завдання 
В даній роботі буде розглянуто такі методи розв’язання поставленого 
завдання: розробка одно сторінкового додатку з використанням JavaScript-
фреймворків та розробка багато сторінкового додатку з використанням 
традиційних серверних технологій [5]. 
Перевагами розробки одно сторінкового додатку з використанням JavaScript-
фреймворків є: 
− швидка робота користувацького інтерфейсу; 
− модульність та можливість повторного використання компонентів; 
− велика кількість готових бібліотек та широкий вибір технологій для 
організації бекенду. 
Недоліки: 
− складність налаштування; 
− великий розмір початкового завантаження. 
Перевагами розробки багато сторінкового додатку з використанням 
традиційних серверних технологій є: 
− простіша розробка для невеликих та середніх проектів; 
− менший розмір початкового завантаження.  
152 
 482.ЧДТУ.252163 90 01 2 
Недоліки: 
− менш плавна навігація; 
− тісно об’єднана розробка клієнтської та серверної частини; 
− повільніша загальна продуктивність в порівнянні з одно сторінковим 
додатком з використанням фреймворків. 
На основі даної інформації було прийнято рішення поєднати ці два підходи 
таким чином, щоб отримати переваги обох рішень. Для розробки частини web-
додатку з інтерактивними елементами буде використовуватися підхід розробки 
одно сторінкового додатку, а для більш статичних сторінок – розробки багато 
сторінкового додатку. 
 
1.2 Огляд аналогів 
Перш ніж розпочати розробку, потрібно ознайомитись з існуючими на ринку 
рішеннями. Це дозволить визначити сильні та слабкі сторони конкурентів, а також 
виявити ключові функції, які мають бути реалізовані у додатку. 
Одним з таких рішень є SAP Business One ― інтегрована система, розроблена 
для малих і середніх підприємств. Вона здійснює бухгалтерський і фінансовий 
облік, управління ресурсами, складом, продажами, закупівлями та іншими 
операціями. Система надає підприємствам інструменти для підвищення 
ефективності роботи, оптимізації процесів і прийняття обґрунтованих бізнес-
рішень. 
SAP Business One автоматизує такі аспекти фінансового обліку як: ведення 
балансу, управління платежами та формування фінансової звітності. Система 
дозволяє контролювати рух товарів і матеріалів, враховувати рівень запасів, 
планувати постачання та відстежувати витрати на складські операції. Також 
підтримує функціонал для планування та контролю проектів, включаючи 
управління завданнями, моніторинг ресурсів і оцінку витрат.  
Програма доступна у хмарній версії, що забезпечує доступ до системи з будь-
якого пристрою. SAP Business One є доволі складним, з великою кількістю модулів 
та функцій, які не потрібні для сфери діяльності ВСТО. SAP Business One не має 
153 
 482.ЧДТУ.252163 90 01 2 
вбудованих модулів, орієнтованих спеціально на облік послуг технічного 
обслуговування. 
Переваги SAP Business One: 
− автоматизує фінансовий облік (баланс, платежі, звітність); 
− відповідає міжнародним стандартам; 
− контролює рух товарів, запаси, постачання та складські витрати; 
− підтримує управління проектами (завдання, ресурси, витрати); 
− хмарна версія дозволяє доступ з будь-якого пристрою. 
Недоліки SAP Business One: 
− складний інтерфейс та велика кількість зайвих модулів; 
− відсутні вбудовані модулі для обліку послуг технічного обслуговування.  
 
 
Рисунок 1.1 – Інтерфейс SAP Business One 
 
Другим рішенням є AutoCount ― спеціалізована система для підприємств, 
яка забезпечує ефективне ведення бухгалтерського обліку та управління 
операціями. 
Основними можливостями AutoCount є: 
− реєстрація всіх видів робіт, виконаних для кожного клієнта, деталізація 
трудовитрат за кожною операцією; 
154 
 482.ЧДТУ.252163 90 01 2 
− облік надходження, витрачання та наявності запасних частин; 
− формування рахунків-фактур на надані послуги, облік витрат на заробітну 
плату, комунальні послуги, оренду тощо; 
− можливість доступу для співробітників з різними рівнями прав, надійний 
захист даних та безпека авторизації. 
Але модуль AutoCount для підприємств, пов’язаних з наданням послуг СТО, 
орієнтований на обслуговування легкових транспортних засобів. Як спеціалізоване 
рішення, AutoCount має обмежені можливості адаптації під специфічні вимоги 
вантажної станції. Також інтерфейс є застарілим та навантаженим інформацією, що 
перешкоджає опановування програми користувачем. Через розширений 
функціонал, впровадження та освоєння AutoCount потребує більших зусиль. 
Переваги AutoCount: 
− деталізований облік виконаних робіт та трудовитрат; 
− управління запасами, автоматичне замовлення запчастин; 
− відстеження оплат; 
− формування фінансової та управлінської звітності; 
− гнучке налаштування прав доступу, надійний захист даних. 
Недоліки AutoCount: 
− орієнтований на легкові автомобілі, обмежена адаптація для вантажної 
станції; 
− застарілий та перевантажений інтерфейс, складний для освоєння; 
− впровадження та навчання вимагають значних зусиль. 
Інше рішення FreshBooks є хмарною бухгалтерською системою, яка має 
спеціальні модулі та функції, орієнтовані на потреби компаній, що надають 
послуги, включаючи автосервіси. 
 
155 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 1.2 – Інтерфейс AutoCount 
 
Основними можливостями FreshBooks є: 
− зручне створення та відстеження замовлень на ремонт, деталізація 
трудовитрат за кожною операцією, автоматичне нарахування вартості 
робіт на основі тарифів; 
− облік надходження, витрачання та наявності запчастин; 
− автоматичне формування рахунків-фактур на надані послуги; 
− формування базової фінансової та управлінської звітності; 
− зручний веб-інтерфейс, надійний захист даних та безпека авторизації. 
Основними перевагами FreshBooks є простота використання та можливість 
роботи в хмарі. Однак, як універсальне бухгалтерське програмне забезпечення, 
FreshBooks має обмежений функціонал, адаптований саме для потреб автосервісів.  
Переваги FreshBooks: 
− зручне створення та відстеження замовлень на ремонт, автоматичне 
нарахування вартості робіт; 
− управління запасами, інтеграція з постачальниками для замовлень; 
− формування рахунків-фактур; 
− базова фінансова та управлінська звітність; 
− хмарне рішення, доступ із будь-якого пристрою; 
156 
 482.ЧДТУ.252163 90 01 2 
− простий та зручний веб-інтерфейс. 
Недоліки FreshBooks: 
− обмежений функціонал для автосервісів; 
− не повністю покриває специфічні потреби складного технічного 
обслуговування. 
 
 
Рисунок 1.3 – Інтерфейс FreshBooks 
 
1.3 Сформовані задачі для проектування 
На сьогодні, на ринку немає рішень, створених конкретно для обліку 
вантажної станції технічного обслуговування. Тому, для створення web-додатку, 
який буде забезпечувати необхідні функції потрібно поставити задачі для 
виконання. 
Додаток має відповідати таким вимогам: 
− використання бази даних для фіксації та зберігання даних всіх видів робіт, 
виконаних для кожного клієнта, ведення детального обліку використаних 
запчастин та матеріалів; 
− можливість додавання нових послуг, які відповідають вимогам ВСТО; 
− формування рахунків для клієнтів на основі наданих послуг, можливість 
друку чеків; 
157 
 482.ЧДТУ.252163 90 01 2 
− облік ресурсів, матеріалів та повідомлення про закінчення запасів; 
− формування фінансової звітності; 
− додавання витрат по категоріям (заробітна плата, оренда, податки, тощо); 
− забезпечення надійного зберігання великих обсягів даних; 
− гнучкість та можливість масштабування системи при збільшенні обсягів 
діяльності; 
− надійний захист даних та авторизація користувачів з різними ролями 
(менеджер, механік, бухгалтер); 
− web-додаток також повинен бути зручним для використання та 
адаптованим для специфіки обслуговування вантажної станції 
обслуговування. 
Для отримання повного функціоналу роботи проектованого web-додатку 
було виділено п’ять основних задач проектування: 
11. Проаналізувати існуючі аналоги web-застосунку. 
12. Розробити взаємопов’язаних елементів web-додатку та створити 
діаграми для представлення архітектури системи та компонентів через 
їхню взаємодію. 
13. Розробити базу даних інформаційної системи. 
14. Розробити інтерфейсну частину спроектованого web-застосунку. 
15. Протестувати та впровадити розроблене програмного забезпечення. 
Для вирішення першої задачі було проаналізовано три аналоги, які містять 
певні переваги та недоліки функціоналу. 
Переваги SAP Business One: 
− автоматизує фінансовий облік (баланс, платежі, звітність); 
− відповідає міжнародним стандартам; 
− контролює рух товарів, запаси, постачання та складські витрати; 
− підтримує управління проектами (завдання, ресурси, витрати); 
− хмарна версія дозволяє доступ з будь-якого пристрою. 
Недоліки SAP Business One: 
158 
 482.ЧДТУ.252163 90 01 2 
− складний інтерфейс та велика кількість зайвих модулів; 
− відсутні вбудовані модулі для обліку послуг технічного обслуговування.  
Переваги AutoCount: 
− деталізований облік виконаних робіт та трудовитрат; 
− управління запасами, автоматичне замовлення запчастин; 
− відстеження оплат; 
− формування фінансової та управлінської звітності; 
− гнучке налаштування прав доступу, надійний захист даних. 
Недоліки AutoCount: 
− орієнтований на легкові автомобілі, обмежена адаптація для вантажної 
станції; 
− застарілий та перевантажений інтерфейс, складний для освоєння; 
− впровадження та навчання вимагають значних зусиль. 
Переваги FreshBooks: 
− зручне створення та відстеження замовлень на ремонт, автоматичне 
нарахування вартості робіт; 
− управління запасами, інтеграція з постачальниками для замовлень; 
− формування рахунків-фактур; 
− базова фінансова та управлінська звітність; 
− хмарне рішення, доступ із будь-якого пристрою; 
− простий та зручний веб-інтерфейс. 
Недоліки FreshBooks: 
− обмежений функціонал для автосервісів; 
− не повністю покриває специфічні потреби складного технічного 
обслуговування. 
 
 
 
 
159 
 482.ЧДТУ.252163 90 01 2 
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ 
 
У цьому розділі було виконано першу задачу «Проаналізувати існуючі 
аналоги web-застосунку».  Також було проведено дослідження існуючих методів 
до розв’язання поставленого завдання. При дослідженні аналогів спроектованого 
web-додатку було виявлено загальні переваги та недоліки. 
Переваги: 
− надають можливість ведення фінансової та управлінської звітності; 
− мають контроль наявності запчастин, формування замовлень, інтеграцію з 
постачальниками; 
− можливість створення чеків; 
− доступ із будь-якого пристрою; 
− налаштування прав користувачів; 
− мають аналітичні інструменти для контролю діяльності. 
Недоліки: 
− обмежена адаптація для ВСТО; 
− складність інтерфейсу, перевантаженість інформацією, потреба в 
додатковому навчанні персоналу; 
− відсутність модулів для технічного обслуговування або управління 
складними операціями. 
Тому було прийняте рішення в спроектованому додатку реалізувати такі нові 
можливості: 
− адаптація під потреби вантажного СТО, спрощена навігація та швидкий 
доступ до ключових функцій; 
− деталізація витрат підприємства; 
− збереження інформації про замовників для швидкого створення замовлень;  
− ведення історії виконаних замовлень; 
− додатковий функціонал управління складом ресурсів; 
− можливість встановлення індивідуальних розцінок для різних типів робіт; 
160 
 482.ЧДТУ.252163 90 01 2 
− розмежування ролей «Бухгалтер», «Менеджер», «Механік» з обмеженим 
доступом до функцій та можливістю блокування користувача. 
Порівняння розглянутих систем дало змогу виявити характеристики, які можуть 
бути корисними при розробці власного рішення. Було визначено, які функціональні 
можливості є стандартом у подібних продуктах, а які – конкурентною перевагою. 
Це допомогло сформулювати вимоги до майбутньої системи та визначити основні 
напрямки її проектування. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
161 
 482.ЧДТУ.252163 90 01 2 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У 
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ 
 
Для виконання поставлених задач розробки потрібно провести моделювання 
предметної області, сформувати вимоги до програмного забезпечення та описати 
дану систему за допомогою діаграм для точно відображення архітектури web-
додатку та взаємодії його компонентів. 
 
2.1 Моделювання предметної області 
Моделювання предметної області є фундаментальним кроком у процесі 
розробки, оскільки воно дозволяє наглядно відобразити знання у вигляді моделей. 
Цей процес ідентифікує основні елементи, їхні взаємозв’язки та поведінку в межах 
системи, що створюється. У моделюванні використовуються різні підходи: 
графічні діаграми, математичні рівняння, текстові описи та інші форми, що 
допомагають створити просту для сприйняття репрезентацію предметної області. 
 
2.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області 
Предметна область моделювання 
Предметна область моделювання для web-застосунку ведення 
бухгалтерського обліку вантажної станції технічного обслуговування включає в 
себе такі елементи: 
– послуги: завдання які виконують механіки, наприклад ремонт чи заміна 
деталі. 
– призначене замовлення: завдання, призначене для конкретного механіка із 
заданим список матеріалів, необхідним для виконання послуги. 
– замовлення: набір інформації, що включає в себе особу замовника та 
інформацію про нього; послугу, що надається; перелік ресурсів, 
162 
 482.ЧДТУ.252163 90 01 2 
необхідних для виконання послуги; загальна вартість замовлення; 
призначений виконавець та інше. 
– замовник: особа, яка звертається до ВСТО за послугою. 
– ресурси: перелік матеріалів, деталей, які використовуються для виконання 
замовлення. 
– витрати: сума коштів, що витрачається підприємством, наприклад 
заробітна платня, оренда, податки тощо. 
– звіти: інформація про доходи і витрати за заданий період часу, розбиті по 
категоріям. 
– користувачі: особи з посадами Менеджер, Механік, Бухгалтер, які мають 
доступ до системи та її функцій. 
Модель предметної області 
Модель предметної області для web-застосунку ведення бухгалтерського 
обліку вантажної станції технічного обслуговування складається з таких сутностей:  
Замовлення: 
– ідентифікатор замовлення; 
– дата створення замовлення; 
– опис змісту робіт; 
– ідентифікатор послуги; 
– ідентифікатор клієнта; 
– ідентифікатор механіка, який надавав послугу; 
– загальна ціна послуги та ресурсів. 
Послуги: 
– ідентифікатор послуги; 
– назва послуги; 
– опис послуги; 
– вартість послуги. 
Призначене замовлення: 
– ідентифікатор замовлення; 
– ідентифікатор послуги; 
163 
 482.ЧДТУ.252163 90 01 2 
– ідентифікатор механіка, який надає послугу; 
– статус виконання замовлення. 
Ресурси: 
– ідентифікатор ресурсу; 
– назва ресурсу; 
– кількість ресурсу; 
– ціна ресурсу. 
Замовник: 
– ідентифікатор клієнта; 
– ім’я клієнта; 
– прізвище клієнта; 
– по батькові клієнта; 
– електронна пошта клієнта; 
– номер телефону клієнта. 
Звіти: 
– ідентифікатор звіту; 
– початкова дата періоду для звіту; 
– заключна дата періоду для звіту; 
– витрати за даний період; 
– прибуток за даний період. 
Користувачі: 
– ідентифікатор користувача; 
– ім’я користувача; 
– прізвище користувача; 
– по батькові користувача; 
– пароль користувача; 
– роль користувача (бухгалтер, механік, менеджер); 
– електронна пошта користувача; 
– номер телефону користувача; 
– isBlocked: Boolean – стан користувача (заблокований або ні). 
164 
 482.ЧДТУ.252163 90 01 2 
Витрати: 
– ідентифікатор витрат; 
– дата запису про витрати; 
– кількість витрат; 
– категорія витрат; 
– додатковий опис витрат. 
Словник предметної області 
Словник предметної області – це специфічні поняття, які найчастіше 
з’являються в процесі аналізу та проектування.  
До словника предметної області можна віднести: замовлення, послуги, 
призначене замовлення, ресурси, замовник або клієнт, звіти, користувачі, витрати. 
 
2.1.2 Елементи моделювання предметної області 
Для моделювання предметної області та при проектування всієї системи, в 
даній роботі буде використовуватися мова UML. Далі будуть представлені основні 
елементи моделювання (таблиця 2.1), які можна буде побачити на UML діаграмах 
в наступних пунктах роботи.  
Таблиця 2.1 – Використані графічні символи UML 
Графічний символ Назва елемента 
дійова особа (актор) 
 
варіант використання 
 
клас 
 
компонент 
 
165 
 482.ЧДТУ.252163 90 01 2 
блок 
 
пакет 
 
розгалуження 
 
початковий стан 
 
кінцевий стан 
 
 
2.1.3 Робоча область моделювання 
Робоча область моделювання допомагає зрозуміти всі аспекти системи та 
проаналізувати для подальшого проектування. Робоча область моделювання web-
додатку, що розробляється полягає в тому, що користувач після входу в систему, в 
залежності від його ролі (Менеджер, Бухгалтер, Механік) отримує доступ до 
функцій додатку. Наприклад, менеджер отримує можливість: переглядати 
замовлення, додавати нові, редагувати, скасовувати чи видаляти наявні; додавати, 
редагувати, видаляти послуги з каталогу; додавати, редагувати, видаляти 
інформацію про замовників; додавати, видаляти чи блокувати користувачів та 
редагувати інформацію про них. Бухгалтер переглядає звіти за певний період, 
створює нові звіти або додає, редагує, видаляє інформацію про витрати. Механік 
отримує доступ до перегляду призначених йому замовлень, зміні статусу замовлень 
на «Виконано» та додавання, редагування, видалення інформації про ресурси на 
складі. 
 
2.2 Формування та аналіз вимог 
Формування та аналіз вимог є важливим етапом при розробці системи. Цей 
етап полягає у зборі інформації та узгодженні вимог з розробниками та 
166 
 482.ЧДТУ.252163 90 01 2 
замовниками. Основна мета цього етапу – виявити та зафіксувати реальні потреби 
користувачів і замовника у зрозумілій формі. Цьому має бути приділено достатньо 
часу, щоб в наступних етапах роботи не витрачати час і кошти на виправлення 
помилок, які були допущені через неправильно виявлені та записані вимоги. 
 
2.2.1 Формування вимог до програмного забезпечення. Первинні і 
детальні вимоги. Вимоги замовника і розробника. Функціональні та 
нефункціональні вимоги 
Формування вимог до програмного забезпечення 
Ретельно сформульовані первинні вимоги відображають очікування 
замовника, визначаючи функціональні та нефункціональні характеристики 
системи. Детальні вимоги визначають специфічні деталі реалізації, враховуючи 
технічні аспекти та можливості розробників. 
Первинні і детальні вимоги 
Первинні вимоги – це загальні вимоги до системи, визначення основного 
функціоналу системи. 
Розроблюваний web-додаток для бухгалтерського обліку вантажної станції 
технічного обслуговування є клієнт-серверною системою, що має бути зручним 
інструмент для обліку та аналізу діяльності станції. Система передбачає роботу з 
базою даних, де зберігається інформація про замовників, замовлення, послуги, 
звіти, витрати, ресурси на складі та співробітників.  
Детальні вимоги – це деталізовані вимоги до системи, які включають в себе 
більш точну інформацію про функціонал системи. 
Детальні вимоги до web-застосунку: 
1. Управління замовленнями: 
– створення нових замовлень із зазначенням послуг, виконавця, деталей та 
вартості; 
– редагування існуючих замовлень, додаючи або змінюючи дані про ресурси 
чи виконавця; 
– видалення виконаних або скасованих замовлень із бази даних. 
167 
 482.ЧДТУ.252163 90 01 2 
2. Робота зі складом ресурсів: 
– можливість наповнення інформації про наявні ресурси; 
– додавання нових ресурсів до складу; 
– редагування інформації про запчастини, зокрема їх залишків і цін; 
– повідомляти користувача, якщо ресурси закінчуються. 
3. Додавання інформації про замовників: 
– можливість перегляду інформації про замовників; 
– редагування даних замовника; 
– видалення інформації про замовника. 
4. Фінансовий облік: 
– створення рахунків для клієнтів; 
– можливість створення записів про витрати підприємства за категоріями; 
– автоматичний підрахунок прибутків і витрат на основі виконаних 
замовлень. 
5. Робота зі звітністю: 
– можливість генерації звіту про доходи і витрати за обраний період; 
– можливість видалення непотрібних звітів. 
6. Керування користувачами: 
– додавання користувачів до системи; 
– можливість редагування інформації про користувачів; 
– можливість блокування користувача, якщо його дані потрібно використати 
у звітах, але потрібно закрити доступ користувача до перегляду та 
редагування інформації; 
– видалення користувача. 
7. Керування послугами: 
– можливість додавання послуг та задання вартості виконання; 
– редагування послуги в каталозі; 
– видалення послуги. 
Вимоги замовника і розробника 
168 
 482.ЧДТУ.252163 90 01 2 
Вимоги замовника – вимоги кінцевого користувача системи, зазначення 
результату розробки, який очікують користувачі. 
Вимоги замовника до web-застосунку ведення бухгалтерського обліку: 
– зручне створення замовлень з вибором замовника, послуги, виконавця та 
зазначення ресурсів для виконання ресурсів; 
– можливість редагування замовлення, а саме зміни кількості чи додавання 
або видалення ресурсів, перепризначення замовлення іншому механіку; 
– автоматичний підрахунок вартості замовлення; 
– можливість друку чеку у форматі PDF; 
– можливість скасування та видалення замовлення; 
– додавання, редагування та видалення інформації в каталозі послуг, списку 
замовників, списку витрат, переліку ресурсів на складі; 
– можливість створення звітів за заданий користувачем період часу; 
– забезпечити додавання користувачів через менеджера та можливість 
блокування користувача. 
Вимоги розробника – вимоги розробників до системи для реалізації вимог 
замовника. 
Вимоги розробника до web-застосунку ведення бухгалтерського обліку: 
– зберігання даних у базі даних PostgreSQL; 
– використання JavaScript, Node.js, Express для розробки. 
Функціональні та нефункціональні вимоги 
Функціональні вимоги – це вимоги, що детально описують функції системи, 
що розробляється. 
Функціональні вимоги до web-застосунку ведення бухгалтерського обліку: 
1. Управління замовленнями: 
– створення нових замовлень із зазначенням виконавця, замовника, ресурсів 
та вартістю; 
– редагування існуючих замовлень; 
– видалення виконаних чи скасованих замовлень; 
– автоматичний підрахунок вартості замовлення. 
169 
 482.ЧДТУ.252163 90 01 2 
2. Управління складом: 
– додавання нових ресурсів до складу; 
– редагування даних про ресурс; 
– повідомлення про вичерпання запасу ресурсу; 
– видалення ресурсів за потреби. 
3. Додавання інформації про замовників: 
– додавання нових замовників; 
– редагування даних замовників; 
– видалення даних за потреби. 
4. Фінансовий облік: 
– створення рахунків для клієнтів; 
– перегляд фінансових звітів за обраний період; 
– виведення загальних підсумків доходів та витрат. 
5. Управління користувачами: 
– додавання, редагування та видалення користувачів; 
– різні рівні доступу залежно від ролі (бухгалтер, механік, менеджер); 
– можливість блокування доступу для користувачів. 
6. Звітність та документація: 
– перегляд фінансових звітів за обраний період; 
– виведення загальних підсумків доходів та витрат. 
Нефункціональні вимоги 
Нефункціональні вимоги – це вимоги, що описують такі елементи web-
додатку як безпека, швидкість виконання, зручність користування тощо. 
Нефункціональні вимоги до web-застосунку ведення бухгалтерського обліку: 
1. Безпека: 
– закритий доступ до системи, додавання користувачів здійснює менеджер; 
– захист доступу до системи через автентифікацію (логін та пароль). 
2. Доступність: 
– доступність через браузери на різних пристроях (ПК, планшети); 
– висока стійкість системи (не менше 90% безвідмовної роботи). 
170 
 482.ЧДТУ.252163 90 01 2 
3. Сумісність: 
– підтримка роботи з основними веб-браузерами. 
 
2.2.2 Формування вимог за діаграмою прецедентів 
Діаграма прецедентів призначена для візуалізації взаємодії між акторами та 
системою, описуючи, як система забезпечує виконання певних функцій або послуг 
для задоволення потреб користувачів. 
Базуючись на вимогах до системи, була побудована діаграма прецедентів 
(рисунок  2.1). 
Опис діаграми прецедентів: 
Акторами є Бухгалтер, Менеджер, Механік та Клієнт. Менеджер може 
реєструватися та входити в систему, окрім цього він має доступ до управління 
користувачами, тобто він додає нових користувачів, визначає їхню роль у системі 
та видаляє наявних користувачів чи блокує доступ. Заблоковані користувачі не 
мають доступу до системи, але їхні дані відображаються для створення фінансових 
звітів. 
Окрім цього менеджер може переглядати звіти про надані послуги чи 
скасовані замовлення, додає інформацію про клієнтів та послуги, що надаються . 
Він оформлює замовлення та після його виконання надає Клієнту чек про надані 
послуги. Якщо замовлення було скасовано, він оновлює його статус і потім може 
видалити інформацію про нього.  
Бухгалтер може входити в систему, також він має доступ до керування та 
аналізу фінансів. Він додає записи про витрати підприємства та може генерувати 
та переглядати звіти за періоди часу. Записи про витрати розділяються по 
категоріях, щоб можна було зручно побачити окремі витрати. 
Механік може входити в систему, також він керує складом запчастин та може 
додавати нові до бази даних або редагувати чи видаляти існуючі. Окрім цього, він 
керує станом замовлення, відповідно до його виконання. За потреби, він має доступ 
до редагування замовлення, якщо потрібно змінити кількість деталей для 
171 
 482.ЧДТУ.252163 90 01 2 
виконання замовлення чи прибрати не використані. Клієнт отримує чек на надані 
послуги і не взаємодіє із системою напряму. 
 
 
Рисунок 2.1 – Діаграма прецедентів web-застосунку ведення бухгалтерського 
обліку 
 
 
 
172 
 482.ЧДТУ.252163 90 01 2 
2.3 Проектування логічної структури 
Проектування логічної структури програмного комплексу є важливим етапом 
у розробці програмного забезпечення, який полягає в створенні абстрактної моделі, 
що визначає взаємодію між основними компонентами системи. На цьому етапі 
визначаються ключові модулі, їхні функції та взаємозв'язки, що дозволяє 
забезпечити ефективну організацію даних і процесів. Логічна структура включає в 
себе проектування архітектури програмного комплексу, визначення ролей 
користувачів, бізнес-логіки та механізмів обробки інформації. Основною метою є 
створення зручного та зрозумілого інтерфейсу для розробників та користувачів, а 
також забезпечення гнучкості та масштабованості системи для подальшого 
розвитку та підтримки. 
 
2.3.1 Діаграми класів 
Діаграма класів в UML використовується для моделювання структури 
системи, показуючи класи, їхні атрибути, методи та взаємозв'язки. Основними 
елементами діаграми є класи, які визначають об'єкти з атрибутами та зв'язки між 
класами, які відображають відносини між класами. Загальну діаграму класів бази 
даних системи можна побачити на рисунку 2.2. На рисунку 2.3 зображена повна 
діаграма з відображенням полів та методів класів web-засосунку. 
 
 
Рисунок 2.2 – Діаграма класів web-застосунку ведення бухгалтерського обліку 
173 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.3 – Діаграма класів web-застосунку ведення бухгалтерського обліку 
 
174 
 482.ЧДТУ.252163 90 01 2 
Опис діаграми класів додатку: 
Таблиця FinancialRecord має такі поля та методи: 
1. id: Serial – ідентифікатор фінансового запису; 
2. date: Date – дата створення фінансового запису; 
3. description: String – опис змісту робіт; 
4. serviceId: Int – ідентифікатор послуги; 
5. customerId: Int – ідентифікатор клієнта; 
6. mechanicId: Int – ідентифікатор механіка, який надавав послугу; 
7. overallPrice: numeric – загальна ціна послуги та ресурсів; 
8. getFinancialRecord() – метод для отримання фінансового запису; 
9. getFinancialRecord() – метод для отримання інформації про фінансовий 
запис; 
10. updateFinancialRecord() – метод для оновлення інформації про фінансовий 
запис; 
11. createFinancialRecord() – метод для створення фінансового запису; 
12. deleteFinancialRecord() – метод для видалення інформації про фінансовий 
запис. 
Таблиця Service має такі поля та методи: 
1. id: Serial – ідентифікатор послуги; 
2. name: String – назва послуги; 
3. description: String – опис послуги; 
4. price: Numeric – вартість послуги; 
5. createService() – метод для створення послуги; 
6. getService() – метод для отримання інформації про послугу; 
7. updateService() – метод для оновлення інформації про послугу; 
8. deleteService() – метод для видалення інформації про послугу. 
Таблиця ServiceAssignment має такі поля та методи: 
1. id: Serial – ідентифікатор замовлення; 
2. serviceId: Int – ідентифікатор послуги; 
3. mechanicId: Int – ідентифікатор механіка, який надає послугу; 
175 
 482.ЧДТУ.252163 90 01 2 
4. status: String – статус виконання замовлення; 
5. assignMechanic() – метод для призначення механіка. 
Таблиця Resources має такі поля та методи: 
1. id: Serial – ідентифікатор ресурсу; 
2. name: String – назва ресурсу; 
3. capacity: Double – кількість ресурсу; 
4. price: Numeric – ціна ресурсу; 
5. addResource() – метод для додавання ресурсу; 
6. getResource() – метод для отримання ресурсу; 
7. deleteResource() – метод для видалення ресурсу; 
8. updateResource() – метод для оновлення інформації про ресурс. 
Таблиця Customer має такі поля та методи: 
1. id: Serial – ідентифікатор клієнта; 
2. name: String – ім’я клієнта; 
3. surname: String – прізвище клієнта; 
4. patronimic: String – по батькові клієнта; 
5. email: String – електронна пошта клієнта; 
6. phone: String – номер телефону клієнта; 
7. addCustomer() – метод для додавання інформації про клієнта; 
8. updateCustomer() – метод для оновлення інформації про клієнта; 
9. getCustomer() – метод для отримання інформації про клієнта; 
10. deleteCustomer() – метод для видалення інформації про клієнта. 
Таблиця Report має такі поля та методи: 
1. id: Serial – ідентифікатор звіту; 
2. period_start: Date – початкова дата періоду для звіту; 
3. period_end: Date – заключна дата періоду для звіту; 
4. expenses: Numeric – витрати за даний період; 
5. income: Numeric – прибуток за даний період; 
6. createReport() – метод для створення звіту за період; 
7. getReport() – метод для отримання звіту за період; 
176 
 482.ЧДТУ.252163 90 01 2 
8. deleteReport() – метод для видалення звіту за період. 
Таблиця User має такі поля та методи: 
1. id: Serial – ідентифікатор користувача; 
2. username: String – ім’я користувача; 
3. usersurname: String – прізвище користувача; 
4. userpatronimic: String – по батькові користувача; 
5. password: String – пароль користувача; 
6. role: String – роль користувача (бухгалтер, механік, менеджер); 
7. email: String – електронна пошта користувача; 
8. phone: String – номер телефону користувача; 
9. isBlocked: Boolean – стан користувача (заблокований або ні); 
10. addUser() – метод для додавання користувача; 
11. updateUser() – метод для оновлення інформації про користувача; 
12. getUser() – метод для отримання інформації про користувача; 
13. blockUser() – метод для блокування користувача; 
14. deleteUser() – метод для видалення користувача. 
Таблиця Expenses має такі поля та методи: 
1. id: Serial – ідентифікатор витрат; 
2. date: Date – дата запису про витрати; 
3. amount: Numeric – кількість витрат; 
4. category: Varchar – категорія витрат; 
5. description: String – додатковий опис витрат; 
6. updateExpenses() – метод для оновлення інформації про витрати; 
7. createExpenses() – метод для створення інформації про витрати; 
8. getExpenses() – метод для отримання інформації про витрати; 
9. deleteExpenses() – метод для видалення інформації про витрати. 
 
2.3.2 Діаграми пакетів 
Діаграма пакетів в UML використовується для організації та структурування 
великих систем, показуючи, як класи та інші елементи згруповані в логічні блоки. 
177 
 482.ЧДТУ.252163 90 01 2 
Основними елементами діаграми є пакети – групи класів, інтерфейсів або інших 
пакетів, що об'єднують елементи за логікою та зв'язки між пакетами, які 
відображають залежності між пакетами. Діаграму пакетів системи можна побачити 
на рисунку 2.4. 
Короткий опис пакетів, що представлені на діаграмі (рисунок 2.4): 
1. інтерфейс користувача: інтерфейс, через який користувач взаємодіє з 
додатком та отримує доступ до функцій; 
2. функції – пакет, який представляє функціонал web-застосунку. Він 
взаємодіє з користувачем та сервером, обробляє запити і відправляє 
відповіді; 
3. серверна частина: обробляє запити користувача та відправляє запити до 
бази даних, отримує відповіді і відправляє результат виконання. 
 
 
Рисунок 2.4 – Діаграма пакетів web-застосунку ведення бухгалтерського обліку 
 
 
 
178 
 482.ЧДТУ.252163 90 01 2 
2.4 Архітектурне проектування 
Архітектурне проектування є ключовим етапом у розробці програмного 
забезпечення, що передбачає визначення загальної структури системи та її 
основних компонентів. На цьому етапі створюється високорівнева модель, яка 
визначає, як різні частини системи будуть взаємодіяти одна з одною та з зовнішнім 
середовищем. Архітектурне проектування включає в себе вибір архітектурного 
стилю, визначення компонентів, що складають систему, а також визначення 
інтерфейсів між цими компонентами. Важливою частиною є також проектування 
масштабованості та надійності системи, забезпечення її ефективної роботи при 
зростанні навантаження. 
Однією з головних задач архітектурного проектування є оптимізація 
структури програмного комплексу для досягнення високої продуктивності та 
зручності в майбутньому обслуговуванні. Це включає вибір технологій, платформ 
і інструментів, які найкраще відповідають вимогам до системи. Крім того, на етапі 
архітектурного проектування враховуються питання безпеки, інтеграції з іншими 
системами, управління конфігурацією та підтримки системи в умовах постійних 
змін. Архітектура має бути гнучкою, дозволяючи легко додавати нові 
функціональності, а також масштабувати систему відповідно до потреб бізнесу та 
технологічних вимог. 
 
2.4.1 Діаграма компонентів 
Діаграма компонентів в UML використовується для моделювання фізичної 
архітектури системи, показуючи, як програмні компоненти та модулі взаємодіють 
один з одним. Основними елементами діаграми є компоненти – окремі частини 
системи, що забезпечують конкретні функції та зв'язки між компонентами, які 
показують, як компоненти залежні один від одного або взаємодіють (рисунок 2.5). 
Опис діаграми компонентів: 
На даній діаграмі відображені основні компоненти системи та їхні 
взаємозв’язки. Є три типи інтерфейсів для: менеджера, механіка та бухгалтера. В 
179 
 482.ЧДТУ.252163 90 01 2 
залежності від інтерфейсу, з яким взаємодіє користувач, відповідно до його ролі, 
отримує доступ до різних частин системи. 
Менеджер має доступ до керування послугами, інформацією про клієнтів, 
користувачами та замовленнями. Механік має доступ до керування складом 
ресурсів та станом замовлення. Бухгалтеру відкритий доступ до генерування 
фінансових звітів та додавання витрат. 
 
 
Рисунок 2.5 – Діаграма компонентів web-застосунку ведення бухгалтерського 
обліку 
180 
 482.ЧДТУ.252163 90 01 2 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання  
Розгортання програмної системи на апаратних засобах 
Розгортання системи є етапом, що передбачає перенесення розробленого 
програмного забезпечення в робоче середовище, де користувачі зможуть 
взаємодіяти з ним. Цей процес включає встановлення необхідного програмного та 
апаратного забезпечення та налаштування конфігурацій.  
Діаграма розгортання 
На етапі розгортання програмної системи на апаратних засобах важливо 
створити візуальну модель, яка відображає розподіл компонентів системи на 
фізичних пристроях. Діаграма розгортання допомагає зрозуміти, як саме програмні 
модулі взаємодіють з апаратним середовищем, і забезпечує уявлення про 
архітектуру системи на фізичному рівні. Завдяки такій моделі можна виявити 
потенційні проблеми інтеграції програмного забезпечення з апаратними засобами, 
що дозволяє мінімізувати ризики та оптимізувати процес розгортання. На рисунку  
2.6 відображена загальна діаграма розгортання додатку. 
 
 
Рисунок 2.6 – Діаграма розгортання web-застосунку ведення бухгалтерського 
обліку 
181 
 482.ЧДТУ.252163 90 01 2 
– Web Server – сервер, на якому розміщено інтерфейс користувача програми. 
На цьому сервері розгорнуто компонент інтерфейсу користувача, який 
відповідає за обробку взаємодії користувачів і представлення 
функціональних можливостей програми кінцевим користувачам. 
– UserClient – сервер, на якому розміщується основна логіка програми та 
служби. На цьому сервері розгорнуто компоненти: автентифікація, 
управління фінансами, керування послугами, керівництво користувачами, 
складом ресурсів та звітування. 
– DB Server – сервер, на якому розміщена база даних програми. На цьому 
сервері розгорнуто компонент бази даних, який відповідає за зберігання та 
керування даними програми, такими як фінансові записи, інформація про 
послуги та дані користувачів. 
 
2.5 Моделювання поведінки системи 
Моделювання поведінки системи є важливим етапом у розробці програмного 
забезпечення, що дозволяє передбачити, як система буде реагувати на різні вхідні 
дані та взаємодії з користувачами або іншими системами. Це процес, який включає 
створення моделей, що відображають динамічні аспекти роботи системи, такі як 
зміни станів, обробка подій та виконання бізнес-логіки. Моделювання поведінки 
допомагає виявити можливі проблеми у роботі системи, зокрема неочікувані або 
некоректні реакції на введені дані, а також дозволяє оптимізувати процеси для 
досягнення високої ефективності. Зазвичай для цього використовуються діаграми 
активності, послідовності або станів, що дозволяють візуалізувати сценарії 
використання та взаємодію компонентів системи в реальному часі. 
 
2.5.1 Діаграма діяльності 
Діаграма діяльності в UML відображає потік робіт або процесів у системі, 
показуючи послідовність виконання дій і подій. Вона підходить для моделювання 
бізнес-процесів, алгоритмів та операцій в системі. Основними елементами діаграми 
є дії – конкретні кроки або операції, які виконує система, потоки – стрілки, що 
182 
 482.ЧДТУ.252163 90 01 2 
вказують послідовність переходів між діями та маркери початку і кінця, які 
позначають початок і завершення процесу (рисунок 2.7-рисунок 2.14). 
Діаграма діяльності для входу/реєстрації показує процес входу або 
реєстрації. Якщо заповнені поля не відповідають певним вимогам, користувач має 
заповнити їх відповідно до цих вимог. 
Діаграма діяльності для бухгалтера показує взаємодію з додатком, а саме 
вхід, перехід на сторінку витрат для додавання, редагування чи видалення 
інформації. Якщо потрібні звіти вже створено, бухгалтер може переглянути 
збережені звіти.  
Діаграма діяльності для менеджера а саме, для керування інформацією про 
замовників в додатку, відображає вхід у систему або реєстрацію, якщо база даних 
не має записів, перехід до сторінки з інформацією про замовників. Далі, якщо 
потрібно додати інформацію, змінити чи видалити, користувач робить відповідні 
дії. В іншому випадку користувач переглядає інформацію про замовників без змін.  
 
 
Рисунок 2.7 – Діаграма діяльності для входу/реєстрації у web-застосунку ведення 
бухгалтерського обліку 
183 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.8 – Діаграма діяльності для бухгалтера web-застосунку ведення 
бухгалтерського обліку 
 
 
Рисунок 2.9 – Діаграма діяльності для менеджера, керування інформацією про 
замовників у web-застосунку ведення бухгалтерського обліку 
184 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.10 – Діаграма діяльності для менеджера, керування замовленнями у 
web-застосунку ведення бухгалтерського обліку 
 
Діаграма діяльності керування замовленнями для менеджера показує 
взаємодію з додатком, а саме вхід чи реєстрацію, перехід до сторінки замовлень, 
звідки менеджер може переглянути звіти по поточних, виконаних чи скасованих 
замовленнях або додати нове. Якщо менеджер створює нове замовлення, йому 
потрібно заповнити форму та призначити виконавця, а потім відстежувати 
виконання замовлення. Після виконання менеджер друкує чек, якщо замовлення не 
було скасоване. 
 
185 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.11 – Діаграма діяльності для менеджера, керування користувачами у 
web-застосунку ведення бухгалтерського обліку 
 
Діаграма діяльності керування користувачами для менеджера відображає 
процес взаємодії користувача з додатком. Спочатку менеджер проходить 
процедуру автентифікації або реєстрацію нового користувача, якщо в базі даних 
немає користувачів. Після успішного входу менеджер переходить до сторінки 
користувачів, яка містить функціональні можливості для адміністрування 
користувачів. 
У межах цієї сторінки менеджер може виконувати додавання нового 
користувача до системи, а також присвоювати відповідну роль, що визначатиме 
рівень його доступу до функцій додатку. Крім того, передбачена можливість 
редагування, видалення користувачів із бази даних або блокування. 
186 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.12 – Діаграма діяльності для менеджера, керування послугами у web-
застосунку ведення бухгалтерського обліку 
 
Діаграма діяльності керування послугами для менеджера відображає процес 
створення, редагування чи видалення інформації про послуги. Спочатку 
користувач проходить процедуру автентифікації або реєстрації. Після успішного 
входу менеджер переходить до сторінки каталогу послуг, яка дає можливість для 
керування інформацією про послуги. 
Діаграма діяльності керування станом замовлення для механіка демонструє 
процес взаємодії користувача із системою на етапах обробки замовлення. Спочатку 
механік проходить процедуру автентифікації. Після успішної авторизації механік 
отримує доступ до основного інтерфейсу додатку, де йому надається можливість 
отримати нове замовлення. 
 
 
187 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.13 – Діаграма діяльності для механіка, керування станом замовлення у 
web-застосунку ведення бухгалтерського обліку 
 
Після цього механік переходить до етапу перегляду його деталей, де може 
ознайомитися з усією необхідною інформацією. Далі він приступає до виконання 
замовлення, виконуючи відповідні ремонтні чи технічні роботи згідно з вказаними 
вимогами, за умови що замовлення не було скасоване. 
Після завершення всіх необхідних дій механік оновлює статус замовлення, 
змінюючи його на «Виконане», що сигналізує про завершення робіт і готовність 
передати замовлення відповідальному менеджеру. 
188 
 482.ЧДТУ.252163 90 01 2 
 
 
Рисунок 2.14 – Діаграма діяльності для механіка, керування складом ресурсів у 
web-застосунку ведення бухгалтерського обліку 
 
Діаграма діяльності керування складом ресурсів для механіка показує 
взаємодію з додатком, а саме вхід, перехід до сторінки складу ресурсів, де він може 
переглянути кількість ресурсів на складі або додати, змінити чи видалити 
інформацію про ресурси. 
 
2.5.2 Діаграма послідовності 
Діаграма послідовності в UML використовується для моделювання порядку 
взаємодій між об'єктами у процесі виконання певної функції або сценарію. 
Основними елементами діаграми є об'єкти – учасники взаємодії, які надсилають і 
отримують повідомлення, повідомлення – взаємодії або виклики методів, що 
передаються між об'єктами, життєві лінії – вертикальні лінії, що показують 
існування об'єкта протягом сценарію та активності – відрізки на життєвих лініях, 
що вказують на виконання дії (рисунки 2.15-2.35). 
189 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.15 – Діаграма послідовності роботи для бухгалтера, додавання витрат у 
web-застосунку ведення бухгалтерського обліку 
 
 
Рисунок 2.16 – Діаграма послідовності роботи для бухгалтера, створення звіту в 
web-застосунку ведення бухгалтерського обліку 
 
190 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.17 – Діаграма послідовності роботи для бухгалтера, видалення звіту в 
web-застосунку ведення бухгалтерського обліку 
 
 
Рисунок 2.18 – Діаграма послідовності роботи для механіка, додавання ресурсів у 
web-застосунку ведення бухгалтерського обліку 
191 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.19 – Діаграма послідовності роботи для механіка, редагування ресурсів 
у web-застосунку ведення бухгалтерського обліку 
 
 
Рисунок 2.20 – Діаграма послідовності роботи для механіка, видалення ресурсів у 
web-застосунку ведення бухгалтерського обліку 
192 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.21 – Діаграма послідовності роботи для механіка, зміна статусу 
замовлення у web-застосунку ведення бухгалтерського обліку 
 
Діаграми послідовності роботи для бухгалтера показують взаємодію 
бухгалтера зі сторінкою витрат та сторінкою створення звітів. За допомогою 
інтерфейсу користувач має змогу звернутися до клієнту JS, а через нього до 
серверу, щоб витягнути інформацію з бази даних для відображення чи редагування. 
А потім, зберегти оновлену інформацію або видалити запис та оновити списки на 
сторінці. 
193 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.22 – Діаграма послідовності роботи для менеджера, додавання послуги 
до каталогу в web-застосунку ведення бухгалтерського обліку 
 
Діаграми послідовності роботи для механіка показують взаємодію механіка 
зі сторінками складу ресурсів та замовлень. На сторінці замовлень відображаються 
замовлення, призначені саме для користувача, що увійшов, а не для всіх механіків . 
Через інтерфейс користувач звертається до клієнту та серверу для зміни інформації 
в базі даних. 
 
194 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.23 – Діаграма послідовності роботи для менеджера, редагування 
послуги в web-застосунку ведення бухгалтерського обліку 
 
 
Рисунок 2.24 – Діаграма послідовності роботи для менеджера, видалення послуги 
у web-застосунку ведення бухгалтерського обліку 
195 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.25 – Діаграма послідовності роботи для менеджера, додавання 
користувача в web-застосунку ведення бухгалтерського обліку 
 
 
Рисунок 2.26 – Діаграма послідовності роботи для менеджера, редагування 
інформації про користувача у web-застосунку ведення бухгалтерського обліку 
196 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.27 – Діаграма послідовності роботи для менеджера, блокування 
користувача у web-застосунку ведення бухгалтерського обліку 
 
 
Рисунок 2.28 – Діаграма послідовності роботи для менеджера, видалення 
користувача у web-застосунку ведення бухгалтерського обліку 
197 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.29 – Діаграма послідовності роботи для менеджера, додавання 
інформації про замовника в web-застосунку ведення бухгалтерського обліку 
 
 
Рисунок 2.30 – Діаграма послідовності роботи для менеджера, редагування 
інформації про замовника в web-застосунку ведення бухгалтерського обліку 
198 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.31 – Діаграма послідовності роботи для менеджера, видалення 
інформації про замовника в web-застосунку ведення бухгалтерського обліку 
 
Діаграми послідовності роботи для механіка показують взаємодію механіка 
зі сторінками складу ресурсів та замовлень. На сторінці замовлень відображається 
лише та інформація, що стосується конкретного механіка, який увійшов у систему . 
Всі дії реалізуються через інтерфейс, який викликає запити до сервера та змінює, 
додає чи видаляє відповідну інформацію в базі даних. Взаємодія включає такі дії, 
як перегляд призначених замовлень, оновлення статусів та зміна деталей 
замовлення. 
 
199 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.32 – Діаграма послідовності роботи для менеджера, друк чека в web-
застосунку ведення бухгалтерського обліку 
 
Діаграми послідовності роботи для менеджера показують взаємодію 
менеджера зі сторінками замовлень, замовників, каталогу послуг та сторінки 
користувачів. Через інтерфейс користувач звертається до клієнту та серверу для 
зміни інформації в базі даних. 
На сторінці замовлень менеджер переглядає поточні, скасовані та виконані 
замовлення. За допомогою модальних вікон він може дізнатися детальну 
інформацію про замовлення, а також редагувати його. В нього є можливість 
змінити виконавця, змінити кількість наявних ресурсів, видалити або додати нові. 
Вартість замовлення обраховується автоматично з урахуванням кількості деталей.  
 
200 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.33 – Діаграма послідовності роботи для менеджера, створення 
замовлення у web-застосунку ведення бухгалтерського обліку 
201 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.34 – Діаграма послідовності роботи для менеджера, редагування 
замовлення у web-застосунку ведення бухгалтерського обліку 
202 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.35 – Діаграма послідовності роботи для менеджера, скасування та 
видалення замовлення в web-застосунку ведення бухгалтерського обліку 
 
2.5.3 Діаграма комунікації 
Діаграма комунікації в UML моделює взаємодію між об'єктами, акцентуючи 
увагу на структурі зв'язків між ними під час виконання певного сценарію. 
Основними елементами діаграми є актори – учасники взаємодії, які обмінюються 
повідомленнями, повідомлення – зв'язки між об'єктами, що показують порядок і 
напрямок обміну інформацією та зв'язки – лінії між об'єктами, що вказують на 
асоціації, через які передаються повідомлення (рисунки 2.36-2.39). 
203 
 482.ЧДТУ.252163 90 01 2 
Для зручності на діаграмах 2.37 та 2.39 актором буде Користувач, оскільки 
дані діаграми актуальні для всіх ролей в даній системі.  
Діаграма комунікації для процесу реєстрації менеджера відображає 
взаємодію між основними компонентами системи під час створення нового 
облікового запису. Процес починається з того, що менеджер відправляє 
відповідний запит через інтерфейс додатку.  
Отриманий запит передається до сервісу реєстрації, який виконує перевірку 
наявності користувача з введеним ім’ям або електронною поштою в базі даних. 
Якщо такий користувач уже існує, система формує відповідне повідомлення про 
помилку та повертає його користувачу, пропонуючи змінити ім’я або вибрати інші 
реєстраційні дані. 
 
 
Рисунок 2.36 – Діаграма комунікації для процесу реєстрації менеджера у web-
застосунку ведення бухгалтерського обліку 
 
 
204 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.37 – Діаграма комунікації для процесу автентифікації користувача у 
web-застосунку ведення бухгалтерського обліку 
 
Якщо ж введене ім’я є унікальним, сервіс реєстрації зберігає введені дані в 
базі та створює новий обліковий запис. Після успішного внесення інформації 
система відправляє користувачеві підтвердження успішної реєстрації та 
перенаправляє на сторінку замовлень. 
Діаграма комунікації для процесу автентифікації користувача показує як 
користувач робить запит на вхід, а сервіс автентифікації в свою чергу перевіряє 
введені дані. Якщо дані введені вірно, то повертає відповідний результат. 
Діаграма комунікації для процесу обробки замовлення показує як менеджер 
запускає процес створюючи нове замовлення за допомогою форми замовлення, яке 
зберігається у базі даних та надсилається механіку на виконання. Після виконання  
механік оновлює стан замовлення та чек за виконані послуги надсилається 
клієнтові. 
Діаграма комунікації для процесу додавання чи оновлення інформації 
показує як користувач за допомогою форм змінює чи додає нову інформацію. Після 
введення дані зберігаються в базі даних та повертається результат. 
 
205 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.38 – Діаграма комунікації для процесу обробки замовлення в web-
застосунку ведення бухгалтерського обліку 
 
 
Рисунок 2.39 – Діаграма комунікації для процесу додавання чи оновлення 
інформації у web-застосунку ведення бухгалтерського обліку 
 
206 
 482.ЧДТУ.252163 90 01 2 
2.5.4 Діаграма скінченного автомату 
Діаграма скінченного автомату в UML описує можливі стани об'єкта та 
переходи між ними на основі подій або умов. Вона використовується для 
моделювання поведінки об’єкта впродовж його життєвого циклу. Основними 
елементами діаграми є стани – різні етапи або умови, у яких може перебувати 
об'єкт, переходи – стрілки, що з'єднують стани та показують зміну стану при певній 
події та початковий та кінцевий стани, які позначають початок і завершення 
життєвого циклу об'єкта (рисунок 2.40). 
Діаграма скінченного автомату web-додатку описує можливі стани 
застосунку. Після запуску web-застосунку користувач входить в обліковий запис і, 
в залежності від його ролі, він має доступ до деяких станів. 
Для користувача з роллю менеджера початковим станом є "Перегляд 
замовлень". З цього стану менеджер має можливість переміщуватися до інших 
ключових станів: "Перегляд каталогу послуг", де він може переглядати та керувати 
переліком доступних послуг; "Перегляд інформації про замовників", що надає 
доступ до даних клієнтів; а також "Перегляд користувачів", що дозволяє управляти 
обліковими записами інших користувачів системи. Всі ці стани, доступні 
менеджеру, взаємопов'язані таким чином, що з будь-якого з них можна перейти до 
будь-якого іншого, забезпечуючи максимальну гнучкість у роботі. 
Користувач з роллю бухгалтера переходить у стан Перегляд звітів, звідки 
може перейти до стану перегляд витрат. Користувач з роллю механік переходить 
до стану Перегляд замовлень, призначених для механіка, звідки він може перейти 
до стану Перегляд складу ресурсів. 
Кожен стан на діаграмі також відображає доступні функції, які користувач 
може виконувати. Загалом, це стандартні операції, такі як додавання, редагування 
та видалення інформації. Для стану "Перегляд користувачів" для менеджера, 
додатково передбачена функція блокування облікових записів. Ці функції 
дозволяють користувачам ефективно взаємодіяти з даними в межах свого 
функціоналу. 
207 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 2.40 – Діаграма скінченного автомату web-застосунку ведення 
бухгалтерського обліку 
208 
 482.ЧДТУ.252163 90 01 2 
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ 
 
У даному розділі було виконано другу задачу «Розробити взаємопов’язаних 
елементів web-додатку та створити діаграми для представлення архітектури 
системи та компонентів через їхню взаємодію».  
Зокрема, було розроблено діаграму прецедентів, яка допомогла визначити 
взаємодії між користувачами і системою, відображаючи функціональні вимоги і 
прецеденти використання системи. Діаграма класів надала структуру об'єктів 
системи, відображаючи класи, їх атрибути, методи та зв'язки між ними. Діаграма 
пакетів допомогла організувати систему в окремі частини для полегшення роботи. 
Діаграма компонентів показала архітектуру, зображаючи компоненти, їхні 
залежності та взаємодії між собою. За допомогою діаграми розгортання було 
описано фізичну інфраструктуру системи, зображаючи вузли та їхні зв'язки. 
Було розроблено діаграми діяльності, що демонструють послідовність 
виконання операцій у системі та відображають логіку роботи процесів, таких як 
управління користувачами, обробка замовлень і керування ресурсами. Також було 
створено діаграми послідовності, які деталізують порядок обміну повідомленнями 
між об’єктами системи під час виконання певних операцій. Окрім цього, було 
розроблено діаграми комунікації, що акцентують увагу на структурі зв’язків між 
об’єктами. А також, діаграму скінченного автомату, що описує життєвий цикл 
ключових об’єктів системи. 
Створені діаграми забезпечують наочне представлення архітектури системи, що 
дозволяє зрозуміти її структуру, оптимізувати логіку роботи та підготуватися для 
подальшої розробки та впровадження програмного забезпечення. 
 
 
 
 
209 
 482.ЧДТУ.252163 90 01 2 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
 
3.1 Розробка програмного комплексу 
3.1.1 Обґрунтування вибору засобів реалізації  
В якості засобів реалізації було обрано: JavaScript, Node.js, Express та  
PostgreSQL. JavaScript працює у всіх сучасних браузерах без необхідності 
встановлення додаткового програмного забезпечення. Також використання 
JavaScript у фронтенді та бекенді полегшує роботу розробнику. Він є швидким, 
оскільки виконується безпосередньо в браузері без необхідності компіляції. 
Node.js та Express дозволяють обробляти одночасно багато запитів, що 
дозволяє швидко обробляти запити до бази даних. Це дозволяє створити систему, 
стійку до відмов та великого навантаження. Також фреймворк Express є простим у 
використанні та гнучким, що підходить для розділення бізнес-логіки на модулі як  
керування користувачами, складом та замовленнями. Express дозволяє легко 
розгорнути сервер на популярних платформах як AWS, Heroku та Vercel. В свою 
чергу Node.js має багато бібліотек та готових рішень для полегшення розробки. 
Перевагами PostgreSQL є підтримка транзакцій, гнучкі запити та аналітика, 
розширення та масштабованість. PostgreSQL дозволяє зручно генерувати звіти та 
аналізувати дані для графічного представлення. 
Підтримка транзакцій базується на принципах ACID (Atomicity, Consistency, 
Isolation, Durability), які гарантують надійність та узгодженість даних у базі.  
Atomicity, тобто атомарність означає, що транзакція є неподільною: або вона 
виконується повністю, або не виконується взагалі. Це забезпечується за допомогою 
команд BEGIN, COMMIT, ROLLBACK. Транзакція завершується командою 
COMMIT і усі її зміни стають постійними, а якщо виникає помилка або виконується 
ROLLBACK, зміни, внесені транзакцією, скасовуються. 
Consistency, тобто узгодженість означає, що після завершення транзакції база 
залишається в узгодженому стані. PostgreSQL забезпечує цілісність даних через 
210 
 482.ЧДТУ.252163 90 01 2 
обмеження (CHECK, UNIQUE, NOT NULL, FOREIGN KEY), тригери та виконання 
всіх змін у межах єдиної транзакції. 
Isolation, тобто ізоляція гарантує, що паралельні транзакції не впливають 
одна на одну некоректним чином. PostgreSQL підтримує декілька рівнів ізоляції, 
що дозволяє зменшити кількість помилок у базі даних. 
Durability, тобто довговічність означає, що після успішного виконання дані 
збережуться навіть у разі збою. PostgreSQL надає можливість зберігати дані 
автоматично, а також робити резервні копії і запобігти втраті важливої інформації.  
Також PostgreSQL дозволяє розподіляти навантаження при зростанні обсягів 
фінансових операцій між кількома базами даних. Це відповідає вимогам до системи 
та дозволить заздалегідь підготувати систему до зростання та розширення. 
Також для створення PDF документів буде використовуватися бібліотека 
pdfmake. pdfmake – це бібліотека JavaScript для створення PDF-документів як на 
стороні клієнта, так і на стороні сервера. 
pdfmake має такі переваги: 
– використовує JSON-об'єкти для визначення структури документа, що 
робить його досить інтуїтивно зрозумілим для розробників, які звикли 
до JavaScript. Це дає високий рівень контролю над розташуванням 
елементів; 
– підтримує різні шрифти, кольори, стилі, відступи, вирівнювання, 
таблиці тощо; 
– дозволяє створювати PDF безпосередньо в браузері, що знижує 
навантаження на сервер і забезпечує швидке створення документів для 
користувача; 
– дозволяє генерувати PDF-документи з динамічними даними, що 
ідеально підходить для звітів, рахунків-фактур, квитанцій та інших 
документів, що створюються на основі даних з бази або 
користувацького вводу. 
Окрім даних засобів буде використано середовище розробки Visual Studio 
Code. На відміну від важких IDE, таких як WebStorm, Visual Studio Code є легким, 
211 
 482.ЧДТУ.252163 90 01 2 
працює швидко і не навантажує систему. VS Code за замовчуванням підтримує всі 
основні можливості, необхідні для веб-розробки: підсвічування синтаксису для 
HTML, CSS та JavaScript, автодоповнення коду завдяки IntelliSense, перевірка 
синтаксису та підказки, а також форматування коду для покращення читабельності.  
 
3.1.2 Опис структурної (функціональної) схеми 
Структурна схема програмної системи (рисунок 3.1) стисло демонструє 
основну будову програмного додатку, його компоненти та підсистеми.  
Система для ведення бухгалтерського обліку ВСТО поділяється на: 
– підсистему керування користувачами, яка відповідає за додавання нових 
користувачів та редагування, блокування чи видалення наявних; 
– підсистему керування замовленнями, яка відповідає за створення 
замовлення, зміну статусу та редагування замовлення (редагування 
замовника, ресурсів та їх кількість, а також опис до замовлення); 
– підсистему керування складом ресурсів, яка відповідає за додавання 
ресурсів до бази даних, зміну інформації про них, видалення з бази даних; 
– підсистему створення звітів, яка відповідає за підрахунок прибутків та  
витрат за заданий період; 
– підсистему керування послугами, яка відповідає за додавання нових 
послуг, редагування та видалення наявних; 
– підсистему керування витратами, яка відповідає за додавання нових 
витрат, редагування та видалення наявних; 
– підсистему реєстрації та автентифікації, яка відповідає за реєстрацію нових 
користувачів та можливість входу користувачам, що вже зареєструвалися; 
– підсистему керування інформацією замовників, яка відповідає за 
додавання нових замовників, редагування та видалення інформації про 
них. 
 
 
 
212 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.1 – Структурна схема web-застосунку ведення бухгалтерського обліку 
 
Функціональна схема програмної системи (рисунок 3.2) описує підсистеми 
детальніше, з урахуванням потоків даних. На схемі можна побачити основні модулі 
або компоненти програмної системи: користувацький інтерфейс, бізнес-логіка, 
база даних. Структурна схема дозволяє побачити, як всі частини системи працюють 
разом і дозволяє зрозуміти загальну структуру програми та її функціонування. 
 
213 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.2 – Функціональна схема web-застосунку ведення бухгалтерського 
обліку 
214 
 482.ЧДТУ.252163 90 01 2 
На даній схемі зображено такі потоки: 
– за допомогою підсистем керування користувачами, замовленнями, складу 
ресурсів, керування інформацією про замовників, керуванням витрат, 
послуг користувач вводить дані, вони зберігаються у базі даних, а потім 
виводяться в інтерфейсі користувача; 
– за допомогою підсистеми реєстрації та автентифікації користувачі 
зберігають дані у базі даних та в подальшому мають доступ до них; 
– за допомогою підсистеми створення звітів користувач створює запит і на 
основі інформації, що знаходиться у базі даних отримує звіт як у 
друкованій, так і в цифровій формах. 
 
3.1.3 Опис логічної схеми системи 
Система складається з декількох модулів, створених для кожного типу 
користувача. Сценарії використання для менеджера, бухгалтера та механіка 
суттєво відрізняються. Відокремлення модулів для різних користувачів допомагає 
запобігти плутанині та спрощує користування системою. Такий підхід зменшить 
час на навчання та адаптацію до системи для користувачів з різними навичками 
володіння технологіями. 
Менеджер реєструється у системі і з цього моменту він має доступ до 
керування користувачами, замовленнями, каталогом послуг та інформацією про 
клієнтів. Керування являє собою панель з наявними користувачами та кнопками 
керування. Він може додавати нових користувачів та присвоювати їм ролі, а також  
блокувати чи видаляти їх в подальшому у разі звільнення персоналу. Він напряму 
взаємодіє з базою даних.  
Після спілкування із замовником менеджер заповнює форму замовлення 
необхідною інформацією (клієнт, види послуг, ресурси на виконання послуги, 
виконавець). За допомогою цієї форми створюється запис у базі даних про дане 
замовлення. Якщо клієнт вперше звертається по послуги, то також створюється 
запис з інформацією про клієнта. Тепер інформація про замовлення доступна 
механіку, якого менеджер призначив як виконавця. На панелі з’являється 
215 
 482.ЧДТУ.252163 90 01 2 
замовлення, інформація витягується з бази даних. Механік після виконання 
замовлення має змінити його статус, щоб клієнт отримав чек (в цифровій чи 
друкованій формі). Чек відправляється автоматично на електронну пошту, що 
залишив клієнт при оформленні замовлення та за потреби друкується чек. Після 
оплати наданих послуг замовлення буде позначене як виконане. Тепер дохід за 
виконане замовлення буде доступний для статистики та аналізу. 
В свою чергу бухгалтер має доступ до аналізу витрат та доходів. Він може 
переглядати звіти за заданий період та отримувати статистику за даний період. 
Інформація обробляється за допомогою запитів та складається у статистику.  
Окрім керування станом замовлення механік керує даними про ресурси на 
складі. Він може змінювати дані про них, додавати нові ресурси чи видаляти 
неактуальні. Він також напряму взаємодіє з базою даних та змінює її за допомогою 
запитів. 
 
3.1.4 Розробка бази даних 
База даних в даному додатку використовується для збереження: інформації 
про облікові записи, включаючи імена, контактні дані, ролі та рівні доступу; списку 
доступних послуг, їхніх характеристик, вартість; інформація про клієнтів ; 
замовлень, включаючи статус, дату створення та відповідальних осіб; інформації 
про доступні матеріали та інші ресурси для виконання послуг; обліку фінансових 
операцій, включаючи витрати та доходи; створених звітів за певні періоди часу, що 
дозволяє аналізувати фінансову діяльність, продуктивність роботи. 
Щоб забезпечити цілісність даних та створити ефективну базу даних, 
потрібно дотримуватися основних принципів нормалізації: 
– кожен атрибут повинен містити лише одне значення, і таблиця не повинна 
мати повторюваних колонок, що зберігають схожі дані; 
– кожен запис у таблиці повинен мати унікальний ідентифікатор (id). Всі 
інші атрибути мають залежати виключно від цього ключа; 
– атрибути таблиці повинні залежати тільки від первинного ключа, а не від 
інших неключових атрибутів. 
216 
 482.ЧДТУ.252163 90 01 2 
Також забезпечення нормалізації здійснюється за допомогою нормальних 
форм. Всього існує п’ять нормальних форм: 
– Перша: всі атрибути містять тільки атомарні (неподільні) значення; в  
таблиці немає повторюваних груп даних; 
– Друга: виконується перша нормальна форма; всі неключові атрибути 
залежать повністю від первинного ключа; 
– Третя: виконується друга нормальна форма; в таблиці немає транзитивних 
залежностей; 
– Четверта та п’ята: використовуються для усунення багатозначних 
залежностей і забезпечення коректної декомпозиції складних відносин. 
Таблиці бази даних наведені в таблицях 3.1-3.10. 
Таблиця 3.1 – Сутність «service» 
№ Назва Тип даних Обмеження Опис 
1 service_id serial Первинний ключ ID послуги 
2 service_name text Унікальний ключ Назва послуги 
3 service_description text  Опис послуги 
4 service_price numeric  Вартість послуги 
 
Таблиця 3.2 – Сутність «financialRecord» 
№ Назва Тип даних Обмеження Опис 
1 fr_id serial Первинний ключ ID запису 
fr_date date  Дата створення 
2 
запису 
fr_description text  Опис наданих 
3 
послуг 
fr_serviceId bigint Зовнішній ключ Ідентифікатор 
4 
послуги 
fr_customerId bigint Зовнішній ключ Ідентифікатор 
5 
клієнта 
217 
 482.ЧДТУ.252163 90 01 2 
fr_resourceId bigint Зовнішній ключ Ідентифікатор 
6 
ресурсу 
fr_mechanicId bigint Зовнішній ключ Ідентифікатор 
7 
механіка 
fr_overallPrice numeric  Вартість виконання 
8 послуги, включно з 
ресурсами 
 
Таблиця 3.3 – Сутність «serviceAssignment» 
№ Назва Тип даних Обмеження Опис 
1 s_id serial Первинний ключ ID призначення 
s_serviceId bigint Зовнішній ключ Ідентифікатор 
2 
послуги 
s_mechanicId bigint Зовнішній ключ Ідентифікатор 
3 
механіка 
s_status text  Статус виконання 
4 
послуги 
s_order bigint Зовнішній ключ Ідентифікатор 
5 
замовлення 
 
Таблиця 3.4 – Сутність «customer» 
№ Назва Тип даних Обмеження Опис 
1 c_id serial Первинний ключ ID клієнта 
2 c_name text  Ім’я клієнта 
3 c_surname text  Прізвище клієнта 
4 c_patronimic text  По батькові клієнта 
c_email text Унікальний ключ Адреса електронної 
5 
скриньки клієнта 
218 
 482.ЧДТУ.252163 90 01 2 
c_phone text Унікальний ключ Номер телефону 
6 
клієнта 
 
Таблиця 3.5 – Сутність «resources» 
№ Назва Тип даних Обмеження Опис 
1 r_id serial Первинний ключ ID ресурсу 
2 r_name text  Назва ресурсу 
r_capacity double  Кількість ресурсу 
3 
на складі 
4 r_price numeric  Ціна ресурсу 
 
Таблиця 3.6 – Сутність «user» 
№ Назва Тип даних Обмеження Опис 
1 u_id serial Первинний ключ ID користувача 
2 u_username text  Ім’я користувача 
u_user_surname text  Прізвище 
3 
користувача 
u_user_patronimic text  По батькові 
4 
користувача 
u_password text  Пароль 
5 
користувача 
6 u_role text  Роль користувача 
u_email text Унікальний ключ Адреса поштової 
7 скриньки 
користувача 
u_phone text Унікальний ключ Номер телефону 
8 
користувача 
isBlocked boolean  Чи заблокований 
9 
користувач 
Таблиця 3.7 – Сутність «report» 
219 
 482.ЧДТУ.252163 90 01 2 
№ Назва Тип даних Обмеження Опис 
1 report_id serial Первинний ключ ID звіту 
report_date_start date  Дата початку 
2 
періоду 
3 report_date_end date  Дата кінця періоду 
4 report_income numeric  Витрати за період 
5 report_expenses numeric  Дохід за період 
 
Таблиця 3.8 – Сутність «expenses» 
№ Назва Тип даних Обмеження Опис 
e_id serial Первинний ключ ID запису про 
1 
витрати 
e_date date  Дата створення 
2 
запису про витрати 
3 e_amount date  Сума витрат 
4 e_category numeric  Категорія витрат 
5 e_description numeric  Додатковий опис 
 
Таблиця 3.9 – Сутність «orderDetails» 
№ Назва Тип даних Обмеження Опис 
1 od_id serial Первинний ключ ID запису 
od_order_id bigint  Ідентифікатор 
2 
замовлення 
od_detail_id bigint  Ідентифікатор 
3 
ресурсу 
4 od_capacity double  Кількість ресурсів 
 
 
Таблиця 3.10 – Сутність «reportDetails» 
220 
 482.ЧДТУ.252163 90 01 2 
№ Назва Тип даних Обмеження Опис 
1 rdetail_id serial Первинний ключ ID запису 
2 rdetail_report_id bigint  Ідентифікатор звіту 
3 rdetail_category text  Категорія витрат 
4 rdetail_amount numeric  Кількість витрат 
 
Для полів, що позначають грошові дані використовується тип даних numeric. 
Numeric дозволяє задавати фіксовану кількість знаків після коми, що усуває 
проблему округлення, яка часто виникає при використанні типів float або double. 
На відміну від float, який використовує плаваючу кому і може бути неточним, 
numeric гарантує точність навіть у складних фінансових операціях. 
На рисунку 3.3 зображено схему бази даних web-застосунку, яка є графічним 
представленням структури бази даних, яке показує сутності, їх атрибути та зв’язки 
між ними. 
Дана схема показує, що між сутностями існує один тип зв’язку: «один до нуля 
або багатьох». Тобто, один екземпляр сутності А може бути пов'язаний з нулем, 
одним або багатьма екземплярами сутності Б, тоді як кожен екземпляр сутності Б 
пов'язаний щонайбільше з одним екземпляром сутності А.  
Сутність orderDetails призначена для деталізації кожного замовлення. Вона 
дозволяє зберігати множинні деталі для одного замовлення, якщо до одного 
замовлення необхідно прив'язати більше одного ресурсу або послуги. Це 
забезпечує гнучкість та точність у відображенні складових частин кожного 
замовлення. 
Сутність reportDetails відповідає за агрегацію та зберігання інформації про 
витрати, розбитих за категоріями. Ці дані є основою для формування 
користувацьких звітів, надаючи деталізований огляд фінансових показників та 
дозволяючи ефективно аналізувати структуру витрат. 
221 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.3 – Схема бази даних web-застосунку ведення бухгалтерського обліку 
 
3.1.5 Розробка інтерфейсу користувача 
Розробка інтерфейсу користувача є важливим компонентом розробки web-
додатку, оскільки інтерфейс користувача є перехідною ланкою між користувачем і 
системою. Тому, одним із головних завдань розробника є забезпечення зручного та 
інтуїтивно зрозумілого представлення системи. 
222 
 482.ЧДТУ.252163 90 01 2 
Якщо в базі даних немає користувачів, то першою сторінкою буде сторінка 
реєстрації менеджера (рисунки 3.4-3.5). На ній розташовані поля, які необхідно 
заповнити для подальшого входу в систему. 
 
 
Рисунок 3.4 – Сторінка реєстрації менеджера у web-застосунку ведення 
бухгалтерського обліку 
 
Якщо в базі даних є зареєстровані користувачі, то першою сторінкою буде 
відкриватися сторінка входу до системи (рисунок 3.6). Користувач, незалежно від 
ролі, вводить пошту та пароль, а потім переходить на першу сторінку інтерфейсу 
для його ролі. 
Першою сторінкою для менеджера є сторінка замовлень (рисунок 3.7), де 
відображаються поточні (активні), виконані та скасовані замовлення. За 
допомогою поля для фільтрації користувач може обирати замовлення по 
замовникам чи виконавцям. Після натискання на картку зі знаком «+» 
відкривається модальне вікно створення замовлення (рисунок 3.8). 
 
223 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.5 – Сторінка реєстрації менеджера у web-застосунку ведення 
бухгалтерського обліку 
 
 
Рисунок 3.6 – Сторінка входу до web-застосунку ведення бухгалтерського обліку 
 
У модальному вікні створення замовлення менеджер вводить опис до 
замовлення, призначає виконавця, обирає послугу, задає ресурси, які необхідні для 
виконання замовлення та обирає клієнта зі списку. Вартість замовлення 
224 
 482.ЧДТУ.252163 90 01 2 
обчислюється автоматично. У вартість входить вартість виконання послуги та 
ресурсів, що використовуються. 
 
 
Рисунок 3.7 – Сторінка замовлень, роль менеджера у web-застосунку ведення 
бухгалтерського обліку 
 
 
Рисунок 3.8 – Сторінка замовлень, створення замовлення, роль менеджера у web-
застосунку ведення бухгалтерського обліку 
225 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.9 – Сторінка замовлень, деталі про замовлення, роль менеджера у web-
застосунку ведення бухгалтерського обліку 
 
 
Рисунок 3.10 – Сторінка замовлень, деталі про замовлення, редагування 
замовлення, роль менеджера у web-застосунку ведення бухгалтерського обліку 
 
Після натискання на кнопку «Деталі» на картці замовлення, з’являється 
модальне вікно з детальною інформацією про замовлення (рисунок 3.9). Після 
натискання на кнопку «Редагувати» менеджер має змогу редагувати опис 
замовлення (рисунок 3.10), призначити замовлення іншому виконавцю, змінити 
226 
 482.ЧДТУ.252163 90 01 2 
кількість ресурсів, додати ресурси або видалити їх. Після натискання на кнопку 
«Зберегти» модальне вікно закривається, а оновлена інформація зберігається у базі 
даних та відображається на сторінці. 
Після натискання на кнопку «Друкувати чек» у модальному вікні детальної 
інформації про замовлення буде створено чек з інформацією про замовлення, який 
можна роздрукувати чи відправити замовнику по електронній пошті (рисунок 
3.11). 
 
 
Рисунок 3.11 – Чек замовлення, роль менеджера у web-застосунку ведення 
бухгалтерського обліку 
 
Після натискання на бічній панелі кнопки «Каталог послуг» користувач 
переходить до сторінки послуг (рисунок 3.12), де він може додати нову послугу, 
редагувати чи видалити існуючі. За допомогою поля пошуку він може швидко 
знайти послугу для перегляду, редагування чи видалення. Також він може 
перегортати список за допомогою кнопок в нижній частині сторінки, якщо в списку 
більше 10 записів. 
Після натискання на кнопку «Додати» відкривається модальне вікно з полями 
для вводу та кнопкою збереження нового запису (рисунок 3.13). 
227 
 482.ЧДТУ.252163 90 01 2 
Після вибору у списку за допомогою чекбоксу та натискання на кнопку 
«Редагувати» відкривається модальне вікно з полями для редагування інформації 
та кнопкою збереження оновленого запису (рисунок 3.14). 
 
 
Рисунок 3.12 – Каталог послуг, роль менеджера у web-застосунку ведення 
бухгалтерського обліку 
 
 
Рисунок 3.13 – Каталог послуг, додавання нової послуги, роль менеджера у web-
застосунку ведення бухгалтерського обліку 
 
228 
 482.ЧДТУ.252163 90 01 2 
Після натискання на бічній панелі кнопки «Клієнти» користувач переходить 
до сторінки клієнтів (рисунок 3.15), де він може додати інформацію про нового 
замовника, редагувати чи видалити інформацію вже існуючих у базі даних. За 
допомогою поля пошуку він може швидко знайти замовника за іменем та 
редагувати чи видалити. Також він може перегортати список за допомогою кнопок 
в нижній частині сторінки, якщо в списку більше 10 записів. 
Додавання, редагування та видалення записів про клієнтів відбувається 
аналогічно сторінці послуг, розглянутої вище. 
 
 
Рисунок 3.14 – Каталог послуг, редагування послуги, роль менеджера у web-
застосунку ведення бухгалтерського обліку 
 
 
Рисунок 3.15 – Сторінка клієнтів, роль менеджера у web-застосунку ведення 
бухгалтерського обліку 
229 
 482.ЧДТУ.252163 90 01 2 
Після натискання на бічній панелі кнопки «Співробітники» користувач 
переходить до сторінки користувачів (рисунок 3.16), де він може додати 
інформацію про нового, редагувати чи видалити інформацію вже існуючих у базі 
даних. На сторінці можна переглянути інформацію про механіків, бухгалтерів та 
менеджерів. Щоб редагувати інформацію про співробітника, потрібно натиснути 
на кнопку «Редагувати» на картці співробітника (рисунок 3.17). 
 
 
Рисунок 3.16 – Сторінка співробітників, роль менеджера у web-застосунку 
ведення бухгалтерського обліку 
 
 
Рисунок 3.17 – Сторінка співробітників, редагування інформації, роль менеджера 
у web-застосунку ведення бухгалтерського обліку 
230 
 482.ЧДТУ.252163 90 01 2 
Щоб додати нового співробітника, потрібно натиснути на кнопку «+» біля 
певної групи співробітників (рисунок 3.18). Після додавання співробітнику 
надається пароль до системи і він може увійти за допомогою сторінки входу.  
Також менеджер може заблокувати або видалити користувача, натиснувши 
на відповідні кнопки на картці співробітника. 
 
 
Рисунок 3.18 – Сторінка співробітників, додавання нового користувача, роль 
менеджера у web-застосунку ведення бухгалтерського обліку 
 
Першою сторінкою для бухгалтера є сторінка звітів (рисунок 3.19), де 
відображаються створені звіти та є можливість їх переглянути або створити нові. 
За допомогою поля для фільтрації користувач може фільтрувати записи за датою. 
Після натискання на кнопку «Створити» відкривається модальне вікно створення 
звіту. 
У модальному вікні обирається початкова та кінцева дата періоду для 
обрахунку і після створення у списку на сторінці буде додано новий звіт з 
інформацією про доходи, витрати по категоріям та статус періоду: «Прибутковий», 
«Збитковий», «Нейтральний» та загальний прибуток. Якщо витрати перевищують 
доходи, то загальний прибуток буде мати мінусове значення. 
231 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.19 – Сторінка звітів, роль бухгалтера у web-застосунку ведення 
бухгалтерського обліку 
 
Після натискання на бічній панелі кнопки «Витрати» користувач переходить 
до сторінки витрат (рисунок 3.20), де він може додати інформацію про витрати, 
редагувати чи видалити інформацію у базі даних. За допомогою поля пошуку він 
може знайти витрати по категоріям. Також він може перегортати список за 
допомогою кнопок в нижній частині сторінки, якщо в списку більше 10 записів. 
Після натискання на кнопку «Додати» відкривається модальне вікно 
додавання (рисунок 3.21), де бухгалтер вводить дату витрат, суму, обирає 
категорію та, за необхідності, вводить опис. Після збереження модальне вікно 
закривається і список на сторінці оновлюється. 
Після вибору елементу в списку за допомогою чекбоксу та натискання на 
кнопку «Редагувати» відкривається модальне вікно редагування (рисунок 3.22), де 
бухгалтер може змінити значення полів. 
Після вибору елементу чи елементів у списку та натискання на кнопку 
«Видалити» відкривається вікно попередження користувача про видалення записів 
і якщо користувач погоджується, обрані записи видаляються з бази даних і більше 
не відображаються на сторінці. 
 
232 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.20 – Сторінка витрат, роль бухгалтера у web-застосунку ведення 
бухгалтерського обліку 
 
 
Рисунок 3.21 – Сторінка витрат, додавання нового запису, роль бухгалтера у web-
застосунку ведення бухгалтерського обліку 
 
 
Рисунок 3.22 – Сторінка витрат, редагування запису, роль бухгалтера у web-
застосунку ведення бухгалтерського обліку 
233 
 482.ЧДТУ.252163 90 01 2 
Першою сторінкою для механіка є сторінка замовлень (рисунок 3.23), де 
відображаються поточні (активні), виконані та скасовані замовлення, призначені 
механіку, що увійшов до системи. За допомогою поля для фільтрації користувач 
може фільтрувати записи за ім’ям замовника. Після натискання на кнопку «Деталі» 
на картці замовлення відкривається модальне вікно з детальною інформацією про 
замовлення (рисунок 3.24). 
У модальному вікні відображається інформація про послугу, опис 
замовлення, ресурси, які необхідні для виконання замовлення та інформація про 
замовника. Після натискання на кнопку «Позначити як виконане» у замовлення 
змінюється статус на «Виконано», модальне вікно закривається і список замовлень 
на сторінці оновлюється. 
 
 
Рисунок 3.23 – Сторінка замовлень, роль механіка у web-застосунку ведення 
бухгалтерського обліку 
 
Після натискання на бічній панелі кнопки «Склад ресурсів» користувач 
переходить до сторінки ресурсів (рисунок 3.25), де він може додати інформацію 
про ресурси, редагувати чи видалити у базі даних. За допомогою поля пошуку він 
може знайти ресурси за назвою. Якщо кількість ресурсу вичерпалася, то на сторінці 
з’являється повідомлення з назвою вичерпаних матеріалів. 
Додавання, редагування та видалення записів про ресурси відбувається 
аналогічно інших сторінок, розглянутих вище. 
234 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.24 – Сторінка замовлень, деталі про замовлення, роль механіка у web-
застосунку ведення бухгалтерського обліку 
 
 
Рисунок 3.25 – Сторінка складу ресурсів, роль механіка у web-застосунку ведення 
бухгалтерського обліку 
 
3.1.6 Опис розробки програмних компонентів   
Розробка web-застосунку ведення бухгалтерського обліку вантажної станції 
технічного обслуговування включає в себе перелік програмних компонентів, 
поділених за функціоналом, що вони реалізують. 
Програмні компоненти web-застосунку ведення бухгалтерського обліку: 
1. Компонент реєстрації/входу користувачів 
235 
 482.ЧДТУ.252163 90 01 2 
− призначення: забезпечує реєстрацію менеджера та вхід для користувачів 
системи; 
− реалізація: обробляє натискання на "показати пароль", валідацію паролів 
при реєстрації, відправляє дані реєстрації/входу на сервер через POST 
запити, обробляє відповіді та визначає URL перенаправлення залежно 
від ролі користувача після успішного входу. 
2. Компонент інформації про замовлення 
− призначення: забезпечує перегляд інформації про замовлення, 
створення, редагування, скасування, видалення замовлення; 
− реалізація: забезпечує функції для скасування, видалення та редагування 
замовлень. Користувач може скасовувати замовлення, підтверджуючи 
дію, видалення замовлення вимагає підтвердження. Редагування активує 
режим, де поля стають доступними для змін, з можливістю додавання та 
видалення деталей замовлення (ресурс, кількість). Збереження змін 
відправляє оновлені дані на сервер, включно з інформацією про 
виконавця, опис, ціну та деталі замовлення. Також є можливість 
додавати нові замовлення через модальне вікно з полями для введення 
інформації про замовлення та деталі. Друк чеку відбувається за 
допомогою бібліотеки pdfmake. 
3. Компонент каталогу послуг 
– призначення: відображає список послуг та дає можливість додавати 
нові, редагувати чи видаляти існуючі; 
– реалізація: компонент відображає таблицю послуг з пагінацією та 
можливістю пошуку. Дані про послуги завантажуються з API, а дії 
додавання, редагування та видалення також взаємодіють з API. Стан 
кнопок редагування та видалення залежить від кількості вибраних 
рядків. 
4. Компонент інформації про замовників 
– призначення: відображає інформацію про замовників із можливістю 
додати нову чи редагувати, видалити наявну; 
236 
 482.ЧДТУ.252163 90 01 2 
– реалізація: дані клієнтів завантажуються з API, а дії додавання, 
редагування та видалення також взаємодіють з API. Стан кнопок 
редагування та видалення залежить від кількості вибраних рядків. 
5. Компонент керування інформацією про користувачів 
– призначення: відображає інформацію про користувачів, дозволяє 
додавати нових користувачів до системи, змінювати інформацію про 
них, блокувати доступ або видаляти за потреби; 
– реалізація: для кожної ролі є кнопка «Додати», яка відкриває модальне 
вікно з формою для введення даних нового користувача або редагування 
існуючого. Кожна картка користувача має кнопки «Редагувати», 
«Заблокувати/Розблокувати» та «Видалити», які взаємодіють з сервером 
через відповідні API-запити. 
6. Компонент інформації про звіти 
– призначення: відображає звіти та дозволяє створити нові за проміжок 
часу, вказаний користувачем; 
– реалізація: компонент завантажує, відображає та пагінує звіти з API. 
Користувач може створювати нові звіти через модальне вікно, вказуючи 
період, а пошук дозволяє фільтрувати звіти за датою. Натискаючи на звіт 
його можна вибрати для видалення. Видалення відбувається через 
DELETE-запит до API. 
7. Компонент інформації про витрати 
– призначення: відображає інформацію про витрати і дозволяє додати 
нову або редагувати чи видалити наявні записи; 
– реалізація: дані витрат завантажуються з API, а дії додавання, 
редагування та видалення також взаємодіють з API. Стан кнопок 
редагування та видалення залежить від кількості вибраних рядків. 
8. Компонент складу ресурсів 
– призначення: відображає інформацію про запаси на складі і дозволяє 
додати нову або редагувати чи видалити наявні записи; 
237 
 482.ЧДТУ.252163 90 01 2 
– реалізація: дозволяє додавати нові ресурси, редагувати існуючі через 
модальні вікна та API-запити. Відображає попередження про ресурси з 
нульовою кількістю. Стан кнопок редагування/видалення залежить від 
вибору рядків. 
 
3.2 Тестування системи 
Тестування системи покликане знайти дефекти у системі, що розробляється, 
а також підтвердити відповідність даної системи вимогам. Тестування проводиться 
на різних рівнях системи: 
– модульне тестування перевіряє окремі, найдрібніші компоненти програми 
ізольовано, щоб переконатися, що кожен з них працює правильно; 
– інтеграційне тестування перевіряє взаємодію між різними інтегрованими 
модулями або компонентами системи; 
– системне тестування перевіряє повністю інтегровану систему як єдине 
ціле. Оцінює відповідність системи заданим вимогам, функціональності та 
нефункціональним характеристикам; 
– приймальне тестування проводиться кінцевими користувачами або 
замовниками для визначення, чи відповідає розроблена система їхнім 
потребам та очікуванням.  
 
3.2.1 Модульне тестування  
Для проведення модульного тестування буде використано Jest.  
Jest – багатофункціональний фреймворк для тестування JavaScript. Він 
спеціалізується на простоті використання і розроблений з акцентом на 
продуктивність і легкість налаштування, надаючи розробникам комплексний 
інструментарій для модульного та інтеграційного тестування. 
 
 
 
Особливості Jest: 
238 
 482.ЧДТУ.252163 90 01 2 
– мінімальна конфігурація: Jest часто працює "з коробки" для багатьох 
JavaScript-проєктів, вимагаючи мінімальних налаштувань; 
– швидкість: розроблений для швидкого виконання тестів, зокрема 
завдяки паралельному виконанню тестів та використанню кешування  
для тестування лише змінених файлів; 
– JSDOM: вбудована імплементація DOM, що дозволяє тестувати 
фронтенд-код, який взаємодіє з браузерним середовищем, без 
необхідності фактично запускати браузер; 
– покриття коду: вбудована підтримка для генерації звітів про покриття 
коду тестами. 
Для модульного тестування буде проведено перевірку компонентів системи, 
а саме: 
1. Компонент реєстрації/входу користувачів: чи правильно зберігаються дані 
зареєстрованих користувачів та обробляється вхід користувача. 
2. Компонент інформації про замовлення: чи правильно відбувається 
створення замовлення, додавання ресурсів, обчислення вартості, 
скасування замовлення, видалення замовлення, друк чеку; 
3. Компонент каталогу послуг: чи правильно відображаються, редагуються 
та зберігаються дані про послуги; 
4. Компонент інформації про замовників: чи правильно відображаються, 
редагуються та зберігаються дані про замовників; 
5. Компонент керування інформацією про користувачів: чи правильно 
відображаються, редагуються та зберігаються дані про користувачів, 
блокування користувачів; 
6. Компонент інформації про звіти: чи правильно створюються та 
видаляються звіти; 
7. Компонент інформації про витрати: чи правильно відображаються, 
редагуються та зберігаються дані про витрати; 
8. Компонент складу ресурсів: чи правильно відображаються, редагуються та 
зберігаються дані про ресурси. 
239 
 482.ЧДТУ.252163 90 01 2 
 
Таблиця 3.11 – Результати модульного тестування 
Компонент Результат 
Компонент реєстрації/входу користувачів Виконання успішне 
Компонент інформації про замовлення Виконання успішне 
Компонент каталогу послуг Виконання успішне 
Компонент інформації про замовників Виконання успішне 
Компонент керування інформацією Виконання успішне 
користувачів 
Компонент інформації про звіти Виконання успішне 
Компонент інформації про витрати Виконання успішне 
Компонент складу ресурсів Виконання успішне 
 
3.2.2 Інтеграційне тестування  
Для інтеграційного тестування буде проведено перевірку взаємодії 
компонентів системи, а саме: 
1. взаємодія компонентів інформації про замовлення та інформації про 
послуги, інформації про замовників, інформації про ресурси, інформації 
про користувачів: чи правильно відображаються дані, які були збережені 
за допомогою інших компонентів в модулі Інформації про замовлення для 
створення чи редагування замовлення. 
2. взаємодія компонентів інформації про звіти та інформації про замовлення, 
інформації про звіти: чи правильно відображаються дані, які були 
збережені за допомогою інших компонентів в модулі інформації про звіти 
для створення звітів за вказаний період часу. 
3. взаємодія компонентів реєстрації/входу користувачів та інформації про 
користувачів: чи правильно зберігаються дані про блокування чи 
розблокування користувача, а також чи правильно відбувається додавання 
та видалення користувачів з бази даних. 
 
240 
 482.ЧДТУ.252163 90 01 2 
Таблиця 3.12 – Результати інтеграційного тестування 
Інтегровані компоненти Результат 
Взаємодія компонентів інформації про Виконання успішне 
замовлення та інформації про послуги, 
інформації про замовників, інформації 
про ресурси, інформації про користувачів 
Взаємодія компонентів інформації про Виконання успішне 
звіти та інформації про замовлення, 
інформації про звіти 
Взаємодія компонентів реєстрації/входу Виконання успішне 
користувачів та інформації про 
користувачів 
 
3.2.3 Системне тестування  
Для проведення системного тестування потрібно перевірити роботу web-
додатку як єдиний цілий компонент та оцінити відповідність функціональним або 
нефункціональним вимогам. 
Система буде перевірена на відповідність таким вимогам: 
6. Управління замовленнями: 
– створення нових замовлень із зазначенням виконавця, замовника, ресурсів 
та вартістю; 
– редагування існуючих замовлень; 
– видалення виконаних чи скасованих замовлень; 
– автоматичний підрахунок вартості замовлення. 
7. Управління складом: 
– додавання нових ресурсів до складу; 
– редагування даних про ресурс; 
– повідомлення про вичерпання запасу ресурсу; 
– видалення ресурсів за потреби. 
8. Додавання інформації про замовників: 
241 
 482.ЧДТУ.252163 90 01 2 
– додавання нових замовників; 
– редагування даних замовників; 
– видалення даних за потреби. 
9. Фінансовий облік: 
– створення рахунків для клієнтів; 
– перегляд фінансових звітів за обраний період; 
– виведення загальних підсумків доходів та витрат. 
10. Управління користувачами: 
– додавання, редагування та видалення користувачів; 
– різні рівні доступу залежно від ролі (бухгалтер, механік, менеджер); 
– можливість блокування доступу для користувачів. 
6. Звітність та документація: 
– перегляд фінансових звітів за обраний період; 
– виведення загальних підсумків доходів та витрат. 
7. Безпека: 
– закритий доступ до системи, додавання користувачів здійснює менеджер; 
– захист доступу до системи через автентифікацію (логін та пароль). 
8. Доступність: 
– доступність через браузери на різних пристроях (ПК, планшети); 
– висока стійкість системи (не менше 90% безвідмовної роботи). 
9. Сумісність: 
– підтримка роботи з основними веб-браузерами. 
 
Таблиця 3.13 – Результати системного тестування 
Інтегровані компоненти Результат 
Управління замовленнями Виконання успішне 
Управління складом Виконання успішне 
Додавання інформації про замовників Виконання успішне 
Фінансовий облік Виконання успішне 
Управління користувачами Виконання успішне 
242 
 482.ЧДТУ.252163 90 01 2 
Звітність та документація Виконання успішне 
Безпека Виконання успішне 
Доступність Виконання успішне 
Сумісність Виконання успішне 
 
3.2.4 Приймальне тестування  
Приймальне тестування призначене для перевірки відповідності системи 
вимогам безпосередньо кінцевими користувачами або замовниками. Цей етап є 
заключним і визначає готовність системи до впровадження. 
Під час приймального тестування виконується перевірка відповідності 
функціональних, нефункціональних вимог розробника та замовника, включаючи 
продуктивність та стабільність роботи системи. Користувачі проходять сценарії 
використання і тестують відповідність очікуваних результатів тому, що було 
отримано фактично. 
Приймальне тестування web-застосунку ведення бухгалтерського обліку 
вантажної станції технічного обслуговування показало, що розроблений додаток 
відповідає всім поставленим вимогам і готовий до впровадження. 
 
Таблиця 3.14 – Результати приймального тестування 
Система Результат 
Відповідність вимогам Виконання успішне 
Стабільність Виконання успішне 
Продуктивність Виконання успішне 
Відповідність очікуваних результатів Виконання успішне 
фактичним 
 
3.3 Приклади впровадженого програмного комплексу   
У цьому розділі буде розглянуто практичне застосування програмного 
комплексу, демонструючи його функціональні можливості для різних категорій 
користувачів. Буде поетапно пройдено по сценаріях використання, починаючи з 
243 
 482.ЧДТУ.252163 90 01 2 
менеджера, потім функціоналу, розробленого для бухгалтера, і завершено оглядом 
можливостей для механіка. Такий підхід дозволить повною мірою висвітлити 
гнучкість системи та її адаптивність до специфічних потреб кожного типу 
користувача, показати, як вона допомагає оптимізувати робочі процеси та 
підвищити ефективність. 
Функціонал для менеджера: 
– реєструється в системі; 
– входить у додаток (рисунок 3.28); 
– переходить до сторінки замовлень (рисунок 3.29); 
– на сторінці замовлень він може відкривати замовлення, редагувати 
інформацію, друкувати чеки, скасовувати чи видаляти замовлення 
(рисунок 3.30-3.32); 
– переходить до сторінки каталогу послуг (рисунок 3.33); 
– на сторінці каталогу послуг він може додавати нову інформацію 
(рисунок 3.34), редагувати (рисунок 3.35) чи видаляти наявну; 
– переходить до сторінки клієнтів (рисунок 3.36), де він аналогічно 
попередньому додає редагує чи видаляє інформацію; 
– переходить до сторінки співробітників (рисунок 3.37), де він може 
редагувати інформацію наявного (рисунок 3.38), блокувати чи 
видалити користувача, додавати нового користувача (рисунок 3.39) за 
роллю для його подальшого доступу до системи. 
Функціонал для бухгалтера: 
– входить у додаток (рисунок 3.28); 
– переходить до сторінки звітів (рисунок 3.40), де він може створювати 
звіти за визначений період часу; 
– переходить до сторінки витрат (рисунок 3.41); 
– на сторінці витрат він може додавати нову інформацію про витрати 
(рисунок 3.42), редагувати (рисунок 3.43) чи видаляти наявну. 
Функціонал для механіка: 
– входить у додаток (рисунок 3.28); 
244 
 482.ЧДТУ.252163 90 01 2 
– переходить до сторінки замовлень, де відображаються виключно 
замовлення для даного механіка (рисунок 3.44), де він може 
переглядати детальну інформацію про звіти та змінювати статус 
замовлення на «Виконано» (рисунок 3.45); 
– переходить до сторінки складу ресурсів (рисунок 3.46), де він може 
переглядати ресурси, додавати інформацію про нові, редагувати та 
видаляти наявні аналогічно функціоналу описаному вище. Також на 
сторінці виводиться повідомлення, якщо запас певних матеріалів 
вичерпано. 
 
 
Рисунок 3.28 – Сторінка входу до web-застосунку ведення бухгалтерського обліку 
 
245 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.29 – Сторінка замовлень, роль менеджера у web-застосунку ведення 
бухгалтерського обліку 
 
 
Рисунок 3.30 – Вікно перегляду замовлення, роль менеджера у web-застосунку 
ведення бухгалтерського обліку 
246 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.31 – Вікно перегляду замовлення, режим редагування, роль менеджера 
у web-застосунку ведення бухгалтерського обліку 
 
 
Рисунок 3.32 – Чек замовлення, роль менеджера у web-застосунку ведення 
бухгалтерського обліку 
247 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.33 – Каталог послуг, роль менеджера у web-застосунку ведення 
бухгалтерського обліку 
 
 
Рисунок 3.34 – Каталог послуг, додавання нової послуги, роль менеджера у web-
застосунку ведення бухгалтерського обліку 
248 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.35 – Каталог послуг, редагування послуги, роль менеджера у web-
застосунку ведення бухгалтерського обліку 
 
 
Рисунок 3.36 – Сторінка клієнтів, роль менеджера у web-застосунку ведення 
бухгалтерського обліку 
 
249 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.37 – Сторінка співробітників, роль менеджера у web-застосунку 
ведення бухгалтерського обліку 
 
 
Рисунок 3.38 – Сторінка співробітників, редагування інформації, роль менеджера 
у web-застосунку ведення бухгалтерського обліку 
250 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.39 – Сторінка співробітників, додавання нового користувача, роль 
менеджера у web-застосунку ведення бухгалтерського обліку 
 
 
Рисунок 3.40 – Сторінка звітів, роль бухгалтера у web-застосунку ведення 
бухгалтерського обліку 
 
251 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.41 – Сторінка витрат, роль бухгалтера у web-застосунку ведення 
бухгалтерського обліку 
 
 
Рисунок 3.42 – Сторінка витрат, додавання нового запису, роль бухгалтера у web-
застосунку ведення бухгалтерського обліку 
252 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.43 – Сторінка витрат, редагування запису, роль бухгалтера у web-
застосунку ведення бухгалтерського обліку 
 
 
Рисунок 3.44 – Сторінка замовлень, роль механіка у web-застосунку ведення 
бухгалтерського обліку 
 
253 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок 3.45 – Сторінка замовлень, деталі про замовлення, роль механіка у web-
застосунку ведення бухгалтерського обліку 
 
 
Рисунок 3.46 – Сторінка складу ресурсів, роль механіка у web-застосунку ведення 
бухгалтерського обліку 
  
254 
 482.ЧДТУ.252163 90 01 2 
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ 
 
В даному розділі було виконано решту поставлених задач, а саме: «Розробити 
базу даних інформаційної системи», «Розробити інтерфейсну частину 
спроектованого web-застосунку», «Протестувати та впровадити розроблене 
програмного забезпечення». 
Було надано обґрунтування вибору засобів реалізації JavaScript, Node.js, 
Express, PostgreSQL та pdfmake, а також розглянуто середовище розробки Visual 
Studio Code. 
Також було створено та описано структурну та функціональну схеми 
додатку, які включають в себе всі підсистеми web-застосунку ведення 
бухгалтерського обліку. 
Було виконано третю поставлену задачу «Розробити базу даних 
інформаційної системи» шляхом створення схеми бази даних та представлення 
записів у вигляді таблиць з назвами комірок, обмеженнями та типами даних. 
Потім було виконано четверту поставлену задачу «Розробити інтерфейсну 
частину спроектованого web-застосунку», а саме описано та представлено 
створений інтерфейс користувача з показом функціоналу для менеджера, 
бухгалтера та механіка. 
Було виконано п’яту задачу «Протестувати та впровадити розроблене 
програмного забезпечення» шляхом тестування створеного web-застосунку на всіх 
рівнях. Було проведено успішне модульне, інтеграційне, системне та програмне 
тестування. 
Також було наведено приклади використання готової системи шляхом показу 
кроків відтворення функцій web-застосунку для всіх типів користувачів. 
В результаті створена система задовольняє вимоги користувачів та 
замовників і є готовою до експлуатації. 
 
 
255 
 482.ЧДТУ.252163 90 01 2 
ВИСНОВКИ 
 
Кваліфікаційна робота була спрямована на розробку web-додатку ведення 
бухгалтерського обліку вантажної станції технічного обслуговування. Робота 
охоплювала ретельне дослідження сучасних методів і технологій, що 
застосовуються для вирішення цих проблем. Це включало переведення результатів 
досліджень у практичне застосування для розробки програмного забезпечення. 
Крім того, невід'ємними компонентами загальної роботи були створення 
програмного забезпечення та його ретельне тестування. 
В першому розділі було виконано першу задачу «Проаналізувати існуючі 
аналоги web-застосунку».  Також було проведено дослідження існуючих методів 
до розв’язання поставленого завдання. При дослідженні аналогів спроектованого 
web-додатку було виявлено загальні переваги та недоліки. Було визначено, які 
функціональні можливості є стандартом у подібних продуктах, а які – 
конкурентною перевагою, що допомогло сформулювати вимоги до майбутньої 
системи та визначити основні напрямки її проектування. 
В другому розділі було виконано другу задачу «Розробити взаємопов’язаних 
елементів web-додатку та створити діаграми для представлення архітектури 
системи та компонентів через їхню взаємодію». Для візуалізації системи було 
розроблено низку UML-діаграм: діаграми прецедентів, класів, пакетів, компонентів 
та розгортання для визначення функціональних вимог, структури об'єктів та 
архітектури системи. Додатково створено діаграми діяльності, послідовності, 
комунікації та скінченного автомату для демонстрації логіки роботи процесів, 
взаємодії об'єктів та їх життєвого циклу. Діаграми забезпечили наочне 
представлення архітектури системи, що полегшило розуміння її структури, 
оптимізацію логіки та подальшу розробку програмного забезпечення. 
В третьому розділі було виконано решту поставлених задач, а саме: 
«Розробити базу даних інформаційної системи», «Розробити інтерфейсну частину 
спроектованого web-застосунку», «Протестувати та впровадити розроблене 
програмного забезпечення». 
256 
 482.ЧДТУ.252163 90 01 2 
Було виконано третю поставлену задачу «Розробити базу даних 
інформаційної системи» шляхом створення схеми бази даних та представлення 
записів у вигляді таблиць з назвами комірок, обмеженнями та типами даних. 
Було виконано четверту поставлену задачу «Розробити інтерфейсну частину 
спроектованого web-застосунку», а саме описано та представлено створений 
інтерфейс користувача з показом функціоналу для менеджера, бухгалтера та 
механіка. 
Було виконано п’яту задачу «Протестувати та впровадити розроблене 
програмного забезпечення» шляхом тестування створеного web-застосунку на всіх 
рівнях. Було проведено успішне модульне, інтеграційне, системне та програмне 
тестування. 
В результаті було виконано всі поставлені задачі та створено web-застосунок, 
який відповідає всім поставленим вимогам та був успішно протестований. 
 
 
 
 
 
 
 
 
 
 
 
 
 
257 
 482.ЧДТУ.252163 90 01 2 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
 
1. Куницька С.Ю., Ніколаєнко А.І. WEB-ЗАСТОСУНОК ВЕДЕННЯ 
БУХГАЛТЕРСЬКОГО ОБЛІКУ ВАНТАЖНОЇ СТАНЦІЇ 
ТЕХНІЧНОГО ОБСЛУГОВУВАННЯ. XI Міжнародна науково-
практична конференція «SCIENTIFIC ACHIEVEMENTS OF 
CONTEMPORARY SOCIETY». 
2. Вавіленкова A. Аналіз гнучких методологій розробки програмного 
забезпечення для реалізації у командних проєктах. Вісник 
Національного технічного університету «ХПІ». Серія: Нові рішення у 
сучасних технологіях, 2021, 1 (7): С. 39-46. 
3. Говорущенко, Т.О., Талайло С.І. Класифікація проектів програмного 
забезпечення. 2012. 
4. Філімончук Т. В., Настенко, О. С. Аналіз актуальності використання 
шаблону MVC при розробці сучасних веб-застосунків. 2021. 
5. Плоха О. Б., Верещака, А. Ю. ОСНОВНІ ПЕРЕВАГИ ТА НЕДОЛІКИ 
ОДНОСТОРІНКОВИХ ТА БАГАТОСТОРІНКОВИХ ВЕБ-
ДОДАТКІВ. Тези доповідей, 2020, С. 8. 
6. Рисований О. М, Жорняк В. Р. Переваги Node. js в розробці сайтів та їх 
серверної частини. 2021. PhD Thesis.  
7. Лабораторний практикум з дисципліни «БАЗИ ДАНИХ» для 
здобувачів освітнього ступеня «бакалавр» за спеціальністю 121 –
Інженерія програмного забезпечення, освітня програма «Інженерія  
програмного забезпечення» галузі знань 12 - Інформаційні технології 
усіх форм навчання [Електронний ресурс] / [упоряд. С.Ю. Куницька,  
С.В. Голуб, В.В. Метелап] ; М-во освіти і науки України, Черкас. держ. 
технол. ун-т. – Черкаси : ЧДТУ, 2024. – 57 с. 
https://er.chdtu.edu.ua/handle/ChSTU/5608. 
8. Глинка Ю. Р., Вовк Р. Б. МЕХАНІЗМИ ЗАБЕЗПЕЧЕННЯ 
НАДІЙНОСТІ ТРАНЗАКЦІЙ У СИСТЕМІ КЕРУВАННЯ БАЗАМИ 
258 
 482.ЧДТУ.252163 90 01 2 
ДАНИХ POSTGRESQL. Інформаційні технології і автоматизація–
2024/Матеріали XVII міжнародної науково-практичної конференції. 
Одеса, 31 жовтня-1 листопада 2024 р.-Одеса, Видавництво ОНТУ, 2024 
р.–847 с. Збірник включає матеріали доповідей учасників конференції , 
які об'єднані за тематичними напрямками конференції., 2024, С. 178. 
9. Буй Д. Б., Пузікова А. В. Теорія нормалізації в реляційних базах даних: 
сучасний стан. НАУКОВІ ЗАПИСКИ. Том 177. Комп’ютерні науки 
2015. 
10. Тестування програмного забезпечення. Навчальний посібник. – 
Черкаси: ЧНУ імені Богдана Хмельницького, 2017. – 284 с. 
11. Яковлєва, А. І., Cугоняк, І. І. АВТОМАТИЗОВАНЕ ТЕСТУВАННЯ. 
UNIT-ТЕСТУВАННЯ. ВИКОРИСТАННЯ ФРЕЙМВОРКУ JEST. ББК 
32.973. 202 К60, C. 59. 
12. Лега Ю. Г. Управління якістю в проектах: навч. посіб. / Ю. Г. Лега, О. 
М. Донець, С. Ю. Куницька; М-во освіти і науки, молоді та спорту 
України, Черкас. держ. технол. ун-т. – Черкаси: Черкас. держ. технол. 
ун-т, 2013. – 356 с., ISBN 978-966-402-114-9. 
https://er.chdtu.edu.ua/handle/ChSTU/5541. 
13. Методичні вказівки до виконання лабораторних робіт з дисципліни  
«Управління проектами» для студентів спеціальностей 7.03050401 і  
8.03050401 - “Економіка підприємства” усіх форм навчання / Укл. 
Донець О.М., Куницька С.Ю. – Черкаси: ЧДТУ, 2011. – 62 с. 
https://er.chdtu.edu.ua/handle/ChSTU/5546. 
14. Методичні рекомендації до виконання лабораторних робіт з 
дисципліни «WEB-ПРОГРАМУВАННЯ» частина 1 для здобувачів 
освітнього ступеня «бакалавр» за спеціальністю 121 – Інженерія 
програмного забезпечення, освітня програма «Інженерія програмного 
забезпечення» галузі знань 12 - Інформаційні технології усіх форм 
навчання [Електронний ресурс] / [упорядники: С.Ю. Куницька, В.В. 
259 
 482.ЧДТУ.252163 90 01 2 
Метелап, В.В. Немченко] ; М-во освіти і науки України, Черкас. держ. 
технол. ун-т. Черкаси : ЧДТУ, 2024. - 96 с. 
15. Методичні рекомендації до підготовки кваліфікаційної роботи 
бакалавра для здобувачів вищої освіти зі спеціальності 121 «Інженерія 
програмного забезпечення» усіх форм навчання [Текст] /Упорядники: 
Голуб С.В., Заспа Г.О., Куницька С.Ю., Півень О.Б. Катаєва Є.Ю., 
Салапатов В.І., Метелап В.В., Олексюк В.В.; М-во освіти і науки 
України, Черкас, держ. технол. ун-т. Черкаси: ЧДТУ, 2023. 130 с.  
https://er.chdtu.edu.ua/handle/ChSTU/5607. 
16. Мова UML [Електронний ресурс]. – Точка доступу: URL 
https://dou.ua/forums/topic/40575/. 
17. Фреймворк pdfmake [Електронний ресурс]. – Точка доступу: URL 
https://dev.to/handdot/generate-a-pdf-in-js-summary-and-comparison-of-
libraries-3k0p. 
 
 
 
 
 
 
 
 
 
 
 
 
260 
 482.ЧДТУ.252163 90 01 2 
ДОДАТОК А 
 
 
      ЗАТВЕРДЖЕНО: 
Зав. кафедрою ПЗАС, професор 
_________________ Голуб С.В. 
„____” ______________ 2025 р. 
 
 
 
 
WEB-застосунок ведення бухгалтерського обліку вантажної станції 
технічного обслуговування 
 
Специфікація 
482.ЧДТУ.252163.015 
Листів 2 
 
 
 
Розробник ________________ Ніколаєнко А.І. 
Керівник ________________ Куницька С.Ю. 
 
 
 
 
 
 
Черкаси 2025 
261 
 482.ЧДТУ.252163 90 01 2 
Позначення Найменування Примітки 
 Документація  
482.ЧДТУ.252163 12 01 Текст програми  
482.ЧДТУ.252163 34 01 Інструкція користувачеві  
482.ЧДТУ.252163 90 01 Графічні матеріали  
   
   
   
   
   
   
   
   
   
   
   
   
 
 
 
 
 
 
 
 
 
262 
 482.ЧДТУ.252163 90 01 2 
ДОДАТОК Г 
 
 
 
 
 
 
 
 
 
 
WEB-застосунок ведення бухгалтерського обліку вантажної станції 
технічного обслуговування 
 
Графічні матеріали 
482.ЧДТУ.252163 90 01 
Листів 18 
 
 
 
 
Розробник ________________ Ніколаєнко А.І. 
 
 
 
 
 
 
 
Черкаси 2025 
263 
 482.ЧДТУ.252163 90 01 2 
 
Рисунок Г1 – Слайд 1 
 
 
Рисунок Г2 – Слайд 2 
264 
 482.ЧДТУ.252163 90 01 3 
 
 
Рисунок Г3 – Слайд 3 
 
 
Рисунок Г4 – Слайд 4 
142 
 482.ЧДТУ.252163 90 01 4 
 
 
Рисунок Г5 – Слайд 5 
 
 
Рисунок Г6 – Слайд 6
143 
 482.ЧДТУ.252163 90 01 5 
 
 
Рисунок Г7 – Слайд 7 
 
 
Рисунок Г8 – Слайд 8 
144 
 482.ЧДТУ.252163 90 01 6 
 
 
Рисунок Г9 – Слайд 9 
 
 
Рисунок Г10 – Слайд 10 
145 
 482.ЧДТУ.252163 90 01 7 
 
 
Рисунок Г11 – Слайд 11 
 
 
Рисунок Г12 – Слайд 12 
146 
 482.ЧДТУ.252163 90 01 8 
 
 
Рисунок Г13 – Слайд 13 
 
 
Рисунок Г14 – Слайд 14 
147 
 482.ЧДТУ.252163 90 01 9 
 
 
Рисунок Г15 – Слайд 15 
 
 
Рисунок Г16 – Слайд 16 
148 
 482.ЧДТУ.252163 90 01 10 
 
 
Рисунок Г17 – Слайд 17 
 
 
Рисунок Г18 – Слайд 18 
149 
 482.ЧДТУ.252163 90 01 11 
 
 
Рисунок Г19 – Слайд 19 
 
 
Рисунок Г20 – Слайд 20 
150 
 482.ЧДТУ.252163 90 01 12 
 
 
Рисунок Г21 – Слайд 21 
 
 
Рисунок Г22 – Слайд 22 
151 
 482.ЧДТУ.252163 90 01 13 
 
 
Рисунок Г23 – Слайд 23 
 
 
Рисунок Г24 – Слайд 24 
152 
 482.ЧДТУ.252163 90 01 14 
 
 
Рисунок Г25 – Слайд 25 
 
 
Рисунок Г26 – Слайд 26 
153 
 482.ЧДТУ.252163 90 01 15 
 
 
Рисунок Г27 – Слайд 27 
 
 
Рисунок Г28 – Слайд 28 
154 
 482.ЧДТУ.252163 90 01 16 
 
 
Рисунок Г29 – Слайд 29 
 
 
Рисунок Г30 – Слайд 30 
155 
 482.ЧДТУ.252163 90 01 17 
 
 
Рисунок Г31 – Слайд 31 
 
 
Рисунок Г32 – Слайд 32 
156 
 482.ЧДТУ.252163 90 01 2 
 
 
Рисунок Г33 – Слайд 33 
 
 
 
 
1
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
