ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/6041| Title: | TMS-система офіційного дилера автотранспортних засобів |
| Authors: | Підгорний, Микола Володимирович Сіваченко, Єгор Вікторович |
| Keywords: | TMS-СИСТЕМА,;АВТОДИЛЕР,;TKINTER,;SQLITE,;СЕРВІСНЕ ОБСЛУГОВУВАННЯ,;ІНТЕГРАЦІЯ. |
| Issue Date: | 12-Jun-2025 |
| Abstract: | Актуальність полягає в необхідності автоматизації бізнес-процесів офіційних дилерів автотранспортних засобів, які стикаються з проблемами ручного управління даними, фрагментацією інформації та неефективністю обліку. На українському ринку відсутні спеціалізовані рішення, адаптовані під потреби малих і середніх дилерських центрів. Створення TMS-системи дозволить оптимізувати облік автомобілів, клієнтів, доставок та сервісного обслуговування, забезпечуючи централізоване управління даними, зручність використання та масштабованість. Мета роботи і задачі дослідження. Розробити TMS-систему для автоматизації діяльності офіційного дилера автотранспортних засобів, яка забезпечить ефективне управління даними про автомобілі, клієнтів, доставки та сервісне обслуговування. Об’єкт дослідження: Об'єктом дослідження є інформаційно-організаційна структура офіційного дилера автотранспортних засобів, зокрема процеси обліку автомобілів, управління клієнтською базою, логістики та сервісного обслуговування. Предмет дослідження: TMS-система офіційного дилера автотранспортних засобів. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/6041 |
| Appears in Collections: | 124 Системний аналіз (Штучний інтелект) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Пояснювальна записка_Сіваченко Єгор_СА-2102_2024-2025.pdf Restricted Access | 1.35 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИЧЕРКАСЬКИЙ
ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра комп’ютерних наук та системного аналізу
Пояснювальна записка
до кваліфікаційної роботи
бакалавра
(освітньо-кваліфікаційний рівень)
на тему: «TMS-система офіційного дилера автотранспортних засобів»
Виконав: студент 4 курсу, групи СА-2102
спеціальності 124 «Системний аналіз»
(шифр і назва спеціальності)
освітня програма «Системний аналіз і
прикладна логістика
(назва освітньої програми)
Сіваченко Єгор Вікторович
Керівник _________ Підгорний М.В.
(прізвище та ініціали)
Рецензент ________ Мельник В.П.
(прізвище та ініціали)
Черкаси 2025 року
2
Бланк завдання на кваліфікаційну роботу бакалавра студенту
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Комп’ютерних наук та системного аналізу
Освітньо-кваліфікаційний рівень Бакалавр
Спеціальність 124 – Системний аналіз
Освітня програма Системний аналіз та прикладна логістика
ЗАТВЕРДЖУЮ
Завідувач кафедри КНСА
_______________ Юрій ТРИУС
«____» _____________ 2025 р.
ЗАВДАННЯ
на кваліфікаційну роботу бакалавра студенту
Сіваченку Єгору Вікторовичу
(прізвище, ім‘я, по батькові)
1. Тема роботи TMS-система офіційного дилера автотранспортних засобів
Керівник роботи Підгорний М.В., к.т.н., доцент
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «25» лютого 2025 р. №53/03.
2. Строк подання студентом роботи до 12 червня 2025 року
3. Вихідні дані до роботи:
TMS-система. Програмне середовище PyCharm.
Мова програмування Python.
4. Зміст пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
4.1. Дослідження предметної області.
4.2. Проєктування та розробка TMS-система офіційного дилера автотранспортних засобів
4.3. Тестування TMS-системи на Python
Висновки.
5. Пере лік додатків (з точним зазначенням назв додатків):
5.1. Додаток А. 482.ЧДТУ. 52120-01.
5.3. Додаток Б. Текст програми.
5.4. Дод аток В. Інструкція користувача.
3
5.5. Презентація у вигляді 25 слайду.
6. Конс ультанти розділів роботи
Підпис, дата
Прізвище, ініціали та
Розділ завдання завдання
посада консультанта
видав прийняв
7. Дата видачі завдання 15.01.2025
КАЛЕНДАРНИЙ ПЛАН
№ № Назва етапів кваліфікаційної роботи Строк виконання
Примітка
з/п бакалавра етапів роботи
1 Видача завдання на кваліфікаційну роботу
15.01.2025 Виконано
бакалавра.
2 Аналіз літературних джерел, об’єкту та
до 13.02.2025 Виконано
предмету дослідження.
3 Написання теоретичного розділу
до 15.03.2025 Виконано
кваліфікаційної роботи бакалавра.
4 Написання аналітичного розділу
до 01.04.2025 Виконано
кваліфікаційної роботи бакалавра.
5 Написання практичних розділів й
висновків до кваліфікаційної роботи до 01.05.2025 Виконано
бакалавра.
6 Передзахист кваліфікаційної роботи
03.06.2025 Виконано
бакалавра на засіданні кафедри КНСА.
7 Подання роботи завідувачу кафедри Виконано
до 10.06.2025
КНСА.
8 Захист кваліфікаційної роботи бакалавра. 12.06.2025 Виконано
Студент _____________________________ Єгор СІВАЧЕНКО
(підпис)
Керівник роботи _____________________________ Микола ПІДГОРНИЙ
(підпис)
4
РЕФЕРАТ
Кваліфікаційна робота бакалавра містить: 80 с., 8 рис., 6 табл., 27
використаних джерел, 3 додатки.
Актуальність теми. Актуальність полягає в необхідності автоматизації
бізнес-процесів офіційних дилерів автотранспортних засобів, які стикаються з
проблемами ручного управління даними, фрагментацією інформації та
неефективністю обліку. На українському ринку відсутні спеціалізовані рішення,
адаптовані під потреби малих і середніх дилерських центрів. Створення TMS-
системи дозволить оптимізувати облік автомобілів, клієнтів, доставок та сервісного
обслуговування, забезпечуючи централізоване управління даними, зручність
використання та масштабованість.
Мета роботи і задачі дослідження. Розробити TMS-систему для
автоматизації діяльності офіційного дилера автотранспортних засобів, яка
забезпечить ефективне управління даними про автомобілі, клієнтів, доставки та
сервісне обслуговування.
Для досягнення поставленої мети були поставлені такі завдання:
дослідити специфіку діяльності автодилерів та вимоги до системи
управління;
проектування базу даних для зберігання інформації про автомобілі, клієнтів,
доставки та сервісні записи;
розробити графічний інтерфейс користувача (GUI) з використанням Tkinter;
реалізувати функціонал для додавання, редагування, видалення та
перегляду даних;
провести тестування.
5
Об’єкт дослідження: Об'єктом дослідження є інформаційно-організаційна
структура офіційного дилера автотранспортних засобів, зокрема процеси обліку
автомобілів, управління клієнтською базою, логістики та сервісного
обслуговування.
Предмет дослідження: TMS-система офіційного дилера автотранспортних
засобів.
Методи дослідження:
системний аналіз: вивчення предметної області та вимог до системи;
об’єктно-орієнтоване програмування для структурування коду та
моделювання сутностей;
багаторівнева архітектура: розділення системи на рівні представлення та
доступу до даних.
Перелік ключових слів: TMS-СИСТЕМА, АВТОДИЛЕР, БАЗА ДАНИХ,
TKINTER, SQLITE, ОБЛІК, СЕРВІСНЕ ОБСЛУГОВУВАННЯ, ДОСТАВКА,
ІНТЕГРАЦІЯ.
6
ABSTRACT
The bachelor's thesis contains: 80 pages, 8 figures, 6 table, 27 used sources,
3 appendices.
The relevance lies in the need to automate business processes of official vehicle
dealers, who face problems of manual data management, information fragmentation
and accounting inefficiency. There are no specialized solutions on the Ukrainian market
adapted to the needs of small and medium-sized dealerships. The creation of a TMS
system will allow to optimize the accounting of cars, customers, deliveries and service,
ensuring centralized data management, ease of use and scalability.
The purpose of the work and research tasks. To develop a TMS system to
automate the activities of an official motor vehicle dealer, which will ensure effective
management of data on cars, customers, deliveries and service.
To achieve the goal, the following tasks were set:
to study the specifics of car dealers' activities and requirements for the
management system;
to design a database for storing information on cars, customers, deliveries and
service records;
to develop a graphical user interface (GUI) using Tkinter;
to implement functionality for adding, editing, deleting and viewing data;
conduct testing.
Research object: The object of the study is the information and organizational
structure of an official motor vehicle dealer, in particular the processes of vehicle
accounting, customer base management, logistics, and service.
Research subject: The subject of the research is the development of a TMS
system based on Python, Tkinter and SQLite.
Research methods:
systems analysis: studying the subject area and system requirements;
7
object-oriented programming for code structuring and entity modeling;
multi-tier architecture: dividing the system into a presentation and data access
level.
List of keywords: TMS SYSTEM, CAR DEALER, DATABASE,
TKINTER, SQLITE, ACCOUNTING, SERVICE, DELIVERY, INTEGRATION.
8
ЗМІСТ
ВСТУП .............................................................................................................. 10
1 АНАЛІТИЧНИЙ ОГЛЯД ЛІТЕРАТУРНИХ ТА ІНШИХ ДЖЕРЕЛ ....... 12
1.1 Аналітичний огляд літературних та інших джерел …………………….12
1.2 Постановка та обґрунтування проблеми………………………………...16
Висновки до розділу 1………………………………………………………..19
2 СИСТЕМНИЙ АНАЛІЗ ТА ОБҐРУНТУВАННЯ ПРОБЛЕМИ ............... 21
2.1 Вибір та обґрунтування методів вирішення проблеми ……………...21
2.2 Вибір та обґрунтування засобів вирішення проблеми………………24
Висновки до розділу 2………………………………………………………..26
3 АНАЛІЗ І ПРОЕКТУВАННЯ СИСТЕМИ ................................................. 27
3.1 Аналіз вимог до системи ....................................................................... 27
3.2 Проектування функціоналу системи .................................................... 29
3.3 Проєктування бази даних……………………………………………...32
3.4 Проєктування внутрішньої будови…………………………………...36
3.5 Проєктування розгортання системи…………………………………..39
Висновки до розділу 3………………………………………………………..41
4 ПРОГРАМНА РЕАЛІЗАЦІЯ ТА ТЕСТУВАННЯ ..................................... 43
4.1 Реалізація бази даних ............................................................................. 43
4.2 Реалізація основних алгоритмів ........................................................... 47
4.3 Реалізація інтерфейсу користувача ...................................................... 51
4.4 Тестування системи ............................................................................... 59
Висновки до розділу 4………………………………………………………..64
ВИСНОВКИ ...................................................................................................... 65
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ........................................................ 67
9
ДОДАТОК А …………………………………………………………………70
ДОДАТОК Б …………………………………………………………………72
ДОДАТОК В …………………………………………………………………78
10
ВСТУП
У сучасних умовах розвитку цифрових технологій та автоматизації бізнес-
процесів, ключовим фактором ефективної діяльності підприємств у сфері
торгівлі та обслуговування автотранспортних засобів стає впровадження
інформаційних систем управління. Офіційні дилери автотранспорту, окрім
реалізації автомобілів, забезпечують повний цикл сервісного обслуговування,
логістики, ведення клієнтської бази та звітності. Зі зростанням обсягів операцій,
ручне управління цими процесами стає неефективним, спричиняючи ризики
втрати важливих даних, помилки під час обліку та значне навантаження на
персонал. У зв’язку з цим постає нагальна потреба у створенні комплексної
транспортної інформаційної системи (TMS), здатної забезпечити облік усіх
логістичних, сервісних та адміністративних операцій автодилера.
Актуальність даної теми.
Актуальність полягає в необхідності автоматизації бізнес-процесів
офіційних дилерів автотранспортних засобів, які стикаються з проблемами
ручного управління даними, фрагментацією інформації та неефективністю
обліку. На українському ринку відсутні спеціалізовані рішення, адаптовані під
потреби малих і середніх дилерських центрів. Створення TMS-системи дозволить
оптимізувати облік автомобілів, клієнтів, доставок та сервісного обслуговування,
забезпечуючи централізоване управління даними, зручність використання та
масштабованість.
Мета кваліфікаційної роботи бакалавра – розробити TMS-систему для
автоматизації діяльності офіційного дилера автотранспортних засобів, яка
забезпечить ефективне управління даними про автомобілі, клієнтів, доставки та
сервісне обслуговування.
11
Для досягнення поставленої мети були поставлені такі завдання:
дослідити специфіку діяльності автодилерів та вимоги до системи
управління;
проектування базу даних для зберігання інформації про автомобілі,
клієнтів, доставки та сервісні записи;
розробити графічний інтерфейс користувача (GUI) з використанням
Tkinter;
реалізувати функціонал для додавання, редагування, видалення та
перегляду даних;
провести тестування.
Об’єктом дослідження є інформаційно-організаційна структура
офіційного дилера автотранспортних засобів, зокрема процеси обліку
автомобілів, управління клієнтською базою, логістики та сервісного
обслуговування.
Предметом дослідження є TMS-система офіційного дилера
автотранспортних засобів.
Для досягнення цілей були використані такі методи дослідження:
системний аналіз: вивчення предметної області та вимог до системи;
об’єктно-орієнтоване програмування для структурування коду та
моделювання сутностей;
багаторівнева архітектура: розділення системи на рівні представлення та
доступу до даних.
Для створення програмного забезпечення використано новітні технології,
а саме: Python, Pycharm. Обрані технології задовольняють всім функціональним
і не функціональним вимогам до такого типу програмного забезпечення (ПЗ).
12
1 АНАЛІТИЧНИЙ ОГЛЯД ЛІТЕРАТУРНИХ ТА ІНШИХ ДЖЕРЕЛ
1.1 Аналітичний огляд літературних та інших джерел
У сучасному світі стрімкого розвитку інформаційних технологій та
цифрової трансформації бізнес-процесів, питання впровадження ефективних
систем управління транспортом (TMS) та дилерських інформаційних систем
(DMS) набуває особливої актуальності для підприємств автомобільної галузі.
Зокрема, офіційні дилери автотранспортних засобів стикаються з необхідністю
оптимізації логістичних операцій, управління клієнтською базою, обліку запасів
та надання якісного сервісного обслуговування. У цьому контексті важливо
проаналізувати існуючі наукові дослідження, технічну літературу та практичні
кейси, що висвітлюють підходи до розробки та впровадження TMS і DMS у сфері
автомобільного бізнесу.
Одним із ключових аспектів є розуміння функціональних можливостей
сучасних TMS. За даними дослідження, проведеного на платформі ResearchGate,
TMS дозволяють автоматизувати процеси планування маршрутів, управління
перевезеннями, моніторингу транспорту та аналізу логістичних даних. Це
забезпечує підвищення ефективності логістичних операцій, зниження витрат та
покращення обслуговування клієнтів [1].
У сфері дилерських інформаційних систем важливим є інтеграція
функціоналу, що охоплює управління запасами, облік продажів, сервісне
обслуговування та взаємодію з клієнтами. Згідно з дослідженням, опублікованим
на ResearchGate, впровадження DMS сприяє оптимізації внутрішніх процесів
автодилерів, забезпечує прозорість операцій та підвищує рівень задоволеності
клієнтів [2].
Особливу увагу слід приділити питанням адаптації TMS та DMS до потреб
малих та середніх підприємств. Дослідження, проведене в Таїланді, вказує на те,
13
що хоча TMS є перспективною технологією, її впровадження може не
створювати значної цінності для малих і середніх підприємств через обмежені
ресурси та складність систем [3].
У контексті трансформації автодилерів у регіональних постачальників
сталих мобільних послуг, дослідження, опубліковане на ResearchGate,
підкреслює важливість впровадження ІКТ-платформ, що дозволяють розширити
спектр послуг та підвищити конкурентоспроможність дилерських центрів [4].
Загалом, аналіз літературних джерел свідчить про те, що впровадження
TMS та DMS є ключовим фактором успішної діяльності автодилерів у сучасних
умовах. Однак, для досягнення максимального ефекту необхідно враховувати
специфіку підприємства, його розмір, ресурси та стратегічні цілі. Подальші
дослідження у цій сфері мають бути спрямовані на розробку адаптивних,
масштабованих та економічно ефективних рішень, що відповідають потребам
різних категорій автодилерів.
У сучасних умовах функціонування автодилерських підприємств, зокрема
офіційних дилерів автотранспортних засобів, інформаційні технології відіграють
ключову роль у забезпеченні ефективного управління основними бізнес-
процесами. Автодилерська діяльність охоплює низку взаємопов’язаних функцій:
продаж нових і вживаних авто, сервісне обслуговування, гарантійний та
післягарантійний ремонт, постачання запчастин, ведення бази клієнтів і супутню
документацію. Управління цими процесами без автоматизованої системи стає не
лише трудомістким, але й схильним до помилок, втрати даних та неефективного
використання ресурсів [5].
Транспортні менеджмент-системи (TMS, англ. Transport Management
Systems) — це прикладні програмні комплекси, які призначені для підтримки та
оптимізації операцій, пов’язаних з транспортуванням, обробкою замовлень,
моніторингом логістичних процесів та управлінням взаємодією з клієнтами [6].
14
Хоча більшість TMS орієнтовані на транспортно-логістичні компанії, все більше
автодилерських центрів звертають увагу на переваги таких систем для вирішення
власних задач, включаючи управління заявками на тест-драйв, контроль за
запасами, історію обслуговування кожного авто, планування графіків роботи
співробітників та взаємодію з клієнтами [7].
Об’єктом дослідження в межах даної роботи є інформаційно-організаційна
структура офіційного дилера автотранспортних засобів. Основу предметної
області становить автоматизація процесів управління заявками, обслуговуванням
клієнтів, обліком транспортних засобів та логістикою в контексті
функціонування дилерського центру.
На практиці, більшість українських офіційних дилерів використовують
застарілі або фрагментовані ІТ-рішення, де функціонал розділено між кількома
платформами: Excel-таблиці, 1С для бухгалтерського обліку, окремі CRM-
системи без інтеграції з логістикою або сервісними модулями [8]. Це створює
значні труднощі при масштабуванні бізнесу, аналізі ефективності та підтримці
високого рівня обслуговування. Проблема ускладнюється через відсутність
централізованого доступу до інформації, несвоєчасне оновлення даних та
людський фактор.
Системний підхід до вирішення задачі передбачає попередній аналіз усіх
складових діяльності автодилера:
Операційна діяльність (продажі, обслуговування, замовлення).
Клієнтська взаємодія (реєстрація, звернення, історія покупок).
Інвентаризація (облік авто на складі, історія ремонтів, гарантії).
Логістика (рух транспортних засобів між салонами, тест-драйви).
Аналітика та звітність (ефективність працівників, аналіз продажів).
Ці компоненти мають бути логічно інтегровані в єдину TMS-систему з
модульною структурою. Наприклад, модуль «Облік ТЗ» забезпечує зберігання
15
даних про кожне авто, включно з VIN-кодом, роком випуску, пробігом та станом,
тоді як модуль «Робота з клієнтами» фіксує кожну взаємодію: запит, тест-драйв,
покупку, обслуговування [9].
Під час розробки необхідно враховувати не лише функціональні, але й
нефункціональні вимоги: безпека даних, масштабованість, швидкодія та
зручність інтерфейсу. Згідно з дослідженнями ринку, понад 65% користувачів
припиняють роботу з внутрішніми корпоративними системами саме через
складність або незручність користування [10]. Отже, юзабіліті виступає
критичним фактором у проектуванні TMS-системи.
Ще одним важливим аспектом є правове регулювання. В Україні
підприємства зобов’язані зберігати певні категорії даних відповідно до Закону
України «Про захист персональних даних» [11]. Таким чином, розробка системи
має передбачати шифрування персональних даних, а також механізми резервного
копіювання і логування доступу до чутливої інформації.
Крім того, сучасні дилерські TMS усе частіше інтегруються з мобільними
додатками для персоналу або клієнтів. Це дозволяє, наприклад, клієнту через
мобільний додаток записатися на обслуговування або переглянути статус
ремонту свого авто в реальному часі. У той же час працівники можуть відмічати
виконані завдання або звіряти наявність запчастин безпосередньо з телефону або
планшета [12].
У світовій практиці вже існують успішні приклади впровадження TMS-
систем на автодилерських підприємствах. Так, японська корпорація Toyota
активно застосовує власні внутрішні TMS, що об’єднують логістику, сервісну
підтримку і прогнозування попиту в єдину систему [13]. Аналогічно, німецький
концерн Volkswagen впроваджує цифрові платформи, які автоматично
аналізують поведінку клієнтів та пропонують персоналізовані рішення для
кожного з них [14].
16
Системний аналіз предметної області дозволяє виокремити такі основні
проблеми, на вирішення яких орієнтована розробка:
1. Відсутність єдиного цифрового середовища для управління бізнес-
процесами.
2. Низька ефективність обробки заявок і клієнтських звернень.
3. Недостатній рівень контролю над обігом транспортних засобів і
запчастин.
4. Відсутність зручної аналітики для менеджменту.
5. Високі ризики втрати або некоректного збереження даних.
У результаті аналізу можна зробити висновок, що створення сучасної,
модульної, безпечної та масштабованої TMS-системи для офіційного дилера
автотранспортних засобів є актуальною задачею, яка вирішує нагальні проблеми
галузі та сприяє цифровій трансформації підприємств автомобільного сектору
України.
1.2 Постановка та обґрунтування проблеми
У сучасних умовах розвитку цифрової економіки та високої конкуренції в
автомобільній галузі офіційні дилери автотранспортних засобів зіштовхуються з
рядом викликів, пов’язаних з ефективністю управління бізнес-процесами,
контролем обігу транспортних засобів, обслуговуванням клієнтів та збереженням
конкурентоспроможності. Більшість дилерських центрів використовують
розрізнені інструменти: окремі CRM-системи, Excel-таблиці, паперові форми,
ручне введення даних та телефонну комунікацію. Це призводить до низького
рівня автоматизації, затримок у процесах, дублювання інформації та зростання
ризиків помилок.
Найбільш критичні процеси, які потребують автоматизації, включають:
ведення обліку транспортних засобів, прийом і обробку клієнтських заявок,
17
організацію тест-драйвів, управління сервісним обслуговуванням, відстеження
залишків на складі, контроль за завантаженістю майстрів, моніторинг фінансових
потоків, а також аналіз ефективності діяльності підприємства. Усі ці процеси
часто реалізовані через окремі модулі або взагалі не цифровізовані, що
унеможливлює централізований контроль та оперативне прийняття рішень.
Особливо актуальною є проблема фрагментації даних. Коли інформація
зберігається в різних місцях — в CRM, на локальних комп’ютерах, у
бухгалтерських програмах або в паперовому вигляді — виникає ситуація
інформаційного розриву. Відсутність єдиної бази даних ускладнює доступ до
актуальної інформації для співробітників і керівництва, уповільнює роботу та
збільшує ризики втрати або підміни даних. Це негативно впливає на якість
обслуговування клієнтів, оперативність виконання завдань і загальну
ефективність бізнесу.
Ще одна проблема — це складність у побудові аналітики. У відсутності
єдиної системи неможливо швидко сформувати звіти про продажі, роботу
менеджерів, ефективність рекламних кампаній, завантаження сервісних боксів
або фінансові показники. Рішення приймаються "наосліп", без підтримки
реальних даних, що призводить до неправильного планування та втрати
прибутку.
Крім того, чинне законодавство зобов’язує суб’єктів господарювання
захищати персональні дані клієнтів, у тому числі контактну інформацію, історію
покупок, дані автомобіля тощо. Збереження такої інформації у незахищених
документах або файлах порушує вимоги безпеки й створює ризики як для
компанії, так і для її клієнтів. Впровадження єдиної системи управління дозволяє
централізувати контроль доступу до інформації, логувати дії користувачів і
забезпечувати резервне копіювання даних.
18
Також не менш важливою проблемою є складність масштабування. З
розширенням бізнесу — відкриттям нових філій, збільшенням кількості клієнтів,
зростанням об’ємів облікових записів — ручне управління процесами стає
неефективним. Без автоматизації підприємство втрачає можливість швидко
адаптуватися до змін, розширювати штат, підключати нові послуги чи канали
продажів.
На основі вищезазначеного можна сформулювати центральну проблему
дослідження:
Відсутність централізованої, безпечної та масштабованої транспортної
менеджмент-системи, яка б дозволяла офіційним дилерам автотранспортних
засобів ефективно управляти основними процесами підприємства в єдиному
інформаційному середовищі.
Ця проблема має комплексний характер і охоплює кілька взаємопов’язаних
напрямів:
Організаційний: неможливість ефективної координації дій працівників,
розподілу обов’язків, планування робочих графіків.
Інформаційний: фрагментованість, дублювання та втрата даних, складність
в отриманні актуальної інформації.
Технічний: відсутність інтегрованої ІТ-системи, залежність від ручної
роботи, відсутність можливості масштабування.
Фінансовий: втрати, спричинені неефективною логістикою, простоєм авто,
повторними візитами клієнтів через помилки.
Клієнтський: зниження рівня довіри, поганий користувацький досвід,
втрата лояльності.
Таким чином, постає необхідність розробки повноцінної TMS-системи, яка
вирішуватиме ключові задачі:
19
Ведення єдиного реєстру транспортних засобів, клієнтів, заявок та
операцій;
Автоматизація процесів тест-драйву, продажу, ремонту та обслуговування;
Підтримка клієнтської картки з історією звернень і обслуговування;
Побудова гнучкої системи звітності та аналітики;
Забезпечення безпеки та конфіденційності даних;
Можливість масштабування при відкритті нових точок продажу.
Створення такої системи дозволить підвищити ефективність управління
підприємством, скоротити витрати часу та ресурсів, покращити обслуговування
клієнтів та зміцнити конкурентні позиції офіційного автодилера на ринку.
Система має бути побудована на сучасних принципах програмної інженерії,
включати модульну архітектуру, підтримку ролей користувачів, web-інтерфейс,
захищене зберігання даних та зручний механізм взаємодії між відділами.
Отже, наявність зазначеної проблеми обґрунтовує доцільність дослідження
та впровадження власної TMS-системи для автоматизації роботи офіційного
дилера автотранспортних засобів.
Висновки до розділу 1
У даному розділі детально розглянуто головні характеристики та функції,
які повинна забезпечувати проектована TMS-система, а саме: управління
транспортними засобами, клієнтською базою, обліком доставок та сервісного
обслуговування, а також зручний інтерфейс, системи пошуку та фільтрації,
валідацію даних, резервне копіювання, звітність та безпеку даних. Описано
основні етапи розробки такої системи, від планування до впровадження та
підтримки.
20
2 СИСТЕМНИЙ АНАЛІЗ ТА ОБҐРУНТУВАННЯ ПРОБЛЕМИ
2.1 Вибір та обґрунтування методів вирішення проблеми
Вирішення задачі створення TMS-системи офіційного дилера
автотранспортних засобів потребує комплексного підходу до вибору методів та
підходів, які забезпечать ефективність, масштабованість і безпеку розробленої
системи. У даному розділі розглянуто методи, що лягли в основу проектування
та реалізації програмного забезпечення, з урахуванням сучасних тенденцій у
розробці корпоративних інформаційних систем.
Об’єктно-орієнтоване програмування (ООП).
Базовою методологією при реалізації системи виступає об’єктно-
орієнтоване програмування, що забезпечує структурованість коду, повторне
використання логіки та інкапсуляцію бізнес-даних. Для складної системи з
великою кількістю сутностей (транспортні засоби, клієнти, заявки, працівники,
графіки тощо), ООП є природним вибором, оскільки дозволяє створити чітку
модель предметної області через класи, їх атрибути та методи.
ООП сприяє підтримці принципів SOLID, що забезпечують зрозумілість і
гнучкість архітектури системи [15]. Особливо важливими є принципи інверсії
залежностей та відкритості/закритості, які дозволяють легко масштабувати
систему й додавати нові модулі без порушення вже працюючої логіки.
Моделі архітектури: багаторівнева та MVC.
Для розділення логіки, даних та представлення в системі обрано
багаторівневу архітектуру з чітким поділом на рівні.
Таблиця 2.1 — Структура n-tier проектів
Рівень представлення GUI-інтерфейс користувача
Бізнес-рівень Основні правила і логіка роботи
Рівень доступу до даних Взаємодія з базою даних.
21
Для реалізації інтерфейсної частини використовується шаблон MVC
(Model–View–Controller), що забезпечує розділення відповідальностей і
покращує тестованість системи. MVC широко застосовується у веб- та десктоп-
розробці і рекомендований більшістю сучасних фреймворків, включаючи Django,
.NET MVC, Laravel, Spring [16].
Модель обміну даними: ORM та реляційна модель.
Для доступу до бази даних використано метод об’єктно-реляційного
відображення (ORM). ORM-підхід дозволяє розробнику взаємодіяти з базою
даних через класи й об’єкти, що істотно скорочує кількість SQL-запитів та
підвищує читабельність коду. Прикладом ORM є SQLAlchemy (Python), Entity
Framework (C#), Hibernate (Java) [17].
У контексті дилерської системи це дозволяє легко оперувати об’єктами
типу Car, Customer, TestDriveRequest, RepairOrder, не заглиблюючись у деталі
SQL-синтаксису. Такий підхід також полегшує міграції бази даних, рефакторинг
і забезпечує захист від SQL-ін’єкцій.
Структуроване зберігання інформації.
Для зберігання даних обрана реляційна модель бази даних, оскільки
структура даних є чітко визначеною, з численними зв’язками між сутностями
(один-до-багатьох, багато-до-багатьох тощо). Реляційні бази забезпечують
цілісність даних, нормалізацію та підтримку транзакцій, що є критичним для
облікових систем.
Приклад логічної структури:
Таблиця vehicles: зберігає дані про авто;
Таблиця clients: персональні дані клієнтів;
Таблиця orders: заявки на обслуговування чи купівлю;
Таблиця staff: інформація про співробітників;
Таблиця service_history: історія сервісного обслуговування.
22
Методи безпеки та захисту даних.
Зважаючи на роботу з персональними даними, система реалізує
аутентифікацію, авторизацію та шифрування даних. Для контролю доступу
застосовуються рольові моделі (admin, менеджер, клієнт), а для збереження
паролів — хешування з використанням алгоритмів типу bcrypt чи Argon2 [18].
Крім того, реалізуються механізми резервного копіювання, логування
активності та захисту від атак типу brute-force або CSRF (у веб-версії). Таким
чином, методи захисту базуються на принципах безпечної розробки та стандартів
OWASP [19].
Алгоритмічна частина.
Алгоритми, реалізовані у системі, належать до категорії бізнес-логічних
(rule-based). Наприклад:
Автоматичне формування графіка обслуговування;
Пріоритетна обробка заявок;
Пошук відповідного авто за параметрами клієнта;
Підрахунок KPI для працівників.
У майбутньому систему можна розширити за допомогою методів
машинного навчання: прогнозування попиту, кластеризація клієнтів,
рекомендальні системи на основі історії обслуговування тощо. Для цього
доцільно передбачити модуль імпорту/експорту даних у форматах CSV/JSON для
подальшого аналізу.
Протоколи взаємодії та API.
Для забезпечення масштабованості та інтеграції з мобільними клієнтами
або сторонніми сервісами застосовуються методи побудови REST API. Це
дозволяє окремо реалізувати фронтенд, мобільний застосунок, кабінет клієнта, не
змінюючи бекенд.
23
REST API працює на основі HTTP-запитів типу GET, POST, PUT, DELETE
та дозволяє обробляти запити до окремих сутностей (наприклад, отримати список
автомобілів, додати заявку, видалити клієнта). Також можливе застосування JWT
(JSON Web Token) для безпечної передачі сесійної інформації.
2.2 Вибір та обґрунтування засобів вирішення проблеми
Для реалізації транспортної менеджмент-системи офіційного автодилера
було обрано інструментарій, що дозволяє досягти оптимального балансу між
простотою розробки, надійністю, масштабованістю та відсутністю ліцензійних
обмежень. Основу реалізації складає мова програмування Python, яка на сьогодні
є однією з найпопулярніших у світі завдяки своїй лаконічності, зручності, великій
кількості готових бібліотек та широкій спільноті розробників [21]. Python
дозволяє швидко створювати повнофункціональні програми з мінімальними
витратами часу, що особливо актуально для індивідуальної чи малокомандної
розробки. Водночас мова підтримує об’єктно-орієнтовану модель
програмування, що важливо для структурованого представлення бізнес-логіки
системи [22].
Інтерфейсна частина реалізована за допомогою бібліотеки Tkinter, яка є
стандартним модулем Python для побудови графічного інтерфейсу користувача.
Основною перевагою Tkinter виступає його вбудованість — він не потребує
додаткових інсталяцій і є доступним «з коробки» у будь-якому середовищі, де
встановлений Python. Це дозволяє уникнути залежностей від сторонніх
фреймворків або складних конфігурацій [23]. Попри свою простоту, Tkinter
дозволяє створити інтуїтивно зрозумілий, функціональний і цілком придатний
для комерційного використання графічний інтерфейс, який включає форми,
таблиці, кнопки, поля введення, модальні вікна та повідомлення. Його
24
можливостей цілком достатньо для внутрішньої системи обліку в межах одного
підприємства.
Для зберігання даних використовується вбудована реляційна система
управління базами даних SQLite. На відміну від серверних СУБД, таких як
PostgreSQL чи MySQL, SQLite не потребує налаштування сервера чи мережевих
з'єднань. Усі дані зберігаються в одному локальному файлі, що значно спрощує
розгортання системи, резервне копіювання, обмін та адміністрування. Більш
того, SQLite повністю підтримує стандарт SQL, включаючи транзакції, зовнішні
ключі, індекси, сортування та агрегування [24]. Для внутрішнього використання
в автосалоні чи дилерському центрі з обмеженим числом одночасних
користувачів, ця система є найкращим вибором за критерієм співвідношення
функціональності та простоти.
Варто зазначити, що такий вибір технологій значно полегшує
обслуговування та підтримку системи. Розробка, написана на Python, не залежить
від конкретної платформи або операційної системи, а вся логіка, реалізована
через Tkinter і SQLite, є достатньо прозорою для подальшого розширення або
рефакторингу. У разі необхідності, систему можна масштабувати за рахунок
міграції на більш потужні СУБД або інтеграції з мобільними додатками через
REST API [25]. Наявність модульної архітектури дозволяє гнучко додавати нові
функції без значного переписування існуючого коду.
Усе програмне забезпечення, використане в системі, є вільним та не
вимагає ліцензування, що робить розробку особливо привабливою з економічної
точки зору [26, 27]. Це дозволяє створити стабільну, надійну та повністю
незалежну систему, що працює автономно, без потреби підключення до
Інтернету чи зовнішніх серверів, і при цьому повністю відповідає
функціональним потребам дилерського бізнесу.
25
Отже, вибраний технологічний стек — Python як основна мова, Tkinter як
засіб побудови GUI та SQLite як засіб збереження даних — забезпечує ефективну
реалізацію задачі створення TMS-системи без надмірних витрат та залежностей.
Він дозволяє сконцентруватися на бізнес-логіці та зручності для користувача,
залишаючись при цьому достатньо гнучким для розвитку й адаптації до потреб
реального бізнесу в майбутньому.
Висновки до розділу 2
Висновки до розділу було обґрунтовано комплексний підхід до вибору
методологій та архітектурних рішень, спрямованих на забезпечення
ефективності, масштабованості та безпеки розроблюваної TMS-системи для
офіційного дилера автотранспортних засобів.
Визначено, що базовою методологією реалізації системи є об'єктно-
орієнтоване програмування (ООП). Його застосування дозволяє досягти
структурованості коду, ефективного повторного використання логіки та
інкапсуляції бізнес-даних, що є критично важливим для системи зі складною
предметною областю та великою кількістю взаємопов'язаних сутностей.
Застосування принципів SOLID додатково забезпечує гнучкість архітектури та
легкість масштабування.
26
3 АНАЛІЗ І ПРОЕКТУВАННЯ СИСТЕМИ
3.1 Аналіз вимог до системи
Створення програмної системи для офіційного автодилера вимагає
глибокого аналізу функціональних, нефункціональних і користувацьких вимог.
В основі лежить потреба у централізованому інструменті, який дозволяє вести
облік автотранспортних засобів, клієнтів, доставлення машин до пунктів
призначення, а також фіксацію історії сервісного обслуговування. Аналіз вимог
проводився з урахуванням реального контексту використання програми
всередині підприємства, де основними користувачами виступають менеджери з
продажу, сервіс-адміністратори, логісти та працівники складу.
Система повинна забезпечувати можливість повноцінного обліку
автотранспорту, включаючи введення VIN-коду, бренду, моделі, року випуску та
статусу транспортного засобу. Усі ці атрибути враховані в реалізованій таблиці
vehicles, яка є базовою для багатьох пов’язаних функцій системи. Для кожного
автомобіля передбачається можливість вказати, чи перебуває він у наявності, чи
доставлений, чи обслуговується. Таким чином, програма виконує не лише облік,
а й часткову логістику.
Окремим блоком реалізовано ведення клієнтської бази, де зберігаються
персональні дані: ім’я, телефон і електронна пошта. В системі це реалізовано у
таблиці clients, з якою далі пов’язані записи сервісного обслуговування.
Програма дає змогу швидко знайти потрібного клієнта, відредагувати або
видалити його дані — усе через зручний графічний інтерфейс.
Логістичний компонент системи представлений таблицею deliveries, де за
кожним автомобілем фіксується факт доставлення, дата, пункт призначення та
статус виконання доставки. Це дозволяє контролювати рух транспортних засобів,
планувати логістику та бачити, які машини були вже передані клієнтам або ще
27
знаходяться в дорозі. Система підтримує повноцінну CRUD-логіку для цієї
сутності, включаючи додавання, редагування та видалення записів.
Окремої уваги заслуговує модуль обліку сервісних записів — це таблиця
service_records, яка пов’язує конкретний транспортний засіб із клієнтом, що його
обслуговував, зазначає дату та суть виконаних робіт. Завдяки таким зв’язкам
система може в перспективі підтримувати фільтрацію по історії обслуговування,
оцінювати навантаження сервісних майстрів та аналізувати частотність звернень
по конкретних моделях авто.
Графічна оболонка системи, реалізована засобами Tkinter, забезпечує
візуальну доступність усіх основних функцій. Через вкладки (notebook)
реалізовано логічне розділення на чотири основні секції — автомобілі, клієнти,
доставлення та сервіс. У кожному з розділів користувач бачить таблицю з
відповідними даними, має змогу швидко додати новий запис, відредагувати
існуючий або видалити непотрібний. Усі дії виконуються без перезапуску
програми, із негайним оновленням вмісту таблиці, що покращує UX.
Форма для додавання чи редагування записів відкривається у вигляді
окремого модального вікна, що унеможливлює взаємні конфлікти між розділами.
Поля для введення підписані відповідно до семантики даних, що мінімізує
кількість помилок при введенні інформації. Реалізований механізм попереднього
заповнення форми при редагуванні забезпечує послідовність користувацького
досвіду. Поведінка кнопки «Зберегти» адаптується залежно від контексту — або
створення нового запису, або оновлення існуючого.
З технічної точки зору система працює з єдиним файлом бази даних SQLite,
що робить її повністю автономною. Це дозволяє запускати програму без
встановлення серверів чи складних конфігурацій, що критично важливо для
невеликих підприємств, які не мають IT-відділу. Використання SQLite також
28
дозволяє легко створювати резервні копії та переносити дані на інші пристрої без
втрати функціональності.
Нефункціональні вимоги включали простоту встановлення, зрозумілий
інтерфейс, швидкодію, низькі системні вимоги та мінімальну кількість кроків для
виконання будь-якої операції. Усі ці вимоги виконано: програма запускається за
секунди, не вимагає доступу до Інтернету та займає мінімум ресурсів.
Таким чином, система повністю відповідає практичним вимогам, які
постають перед офіційним дилером: централізований облік, оперативне
управління, зручний GUI, надійне збереження даних і простота розгортання. Всі
ключові функціональні сценарії реалізовані без надмірностей, що дозволяє
максимально сфокусуватися на реальній роботі користувача, а не на адаптації до
системи.
3.2 Проектування функціоналу системи
Функціональність системи управління автодилерським центром
формується відповідно до потреб ключових користувачів: адміністратора,
менеджера з продажу, логіста та сервісного працівника. Під час проєктування
було враховано, що кожен із них виконує свою специфічну роль у життєвому
циклі транспортного засобу — від його постачання на склад до післяпродажного
обслуговування.
Фундаментальним етапом у проєктуванні функціоналу стало формування
карти дій користувачів у вигляді діаграми варіантів використання. На діаграмі
зображено, які саме дії може виконувати кожен учасник системи, а також
відношення між сутностями, з якими він взаємодіє. Дана схема дозволяє наочно
представити логіку доступу до основних блоків: реєстрація та редагування
інформації про транспортні засоби, управління клієнтською базою, контроль за
доставленням, ведення історії обслуговування.
29
Рисунок 3.1 — Діаграма варіантів використання
Функціонально система дозволяє адміністратору повністю ініціалізувати
базу даних та здійснювати її підтримку. Зі старту користувач отримує доступ до
чотирьох основних вкладок: «Автомобілі», «Клієнти», «Доставлення» та
«Сервіс». У кожній з вкладок реалізовано можливість виводу таблиці записів з
бази даних, виконання операцій додавання нового запису, редагування обраного
та його видалення. Таблиці формуються динамічно за допомогою елемента
Treeview і оновлюються після кожної операції.
У вкладці «Автомобілі» менеджер може додавати нові транспортні засоби,
вказуючи VIN, марку, модель, рік та початковий статус (наприклад, "На складі").
30
Це дозволяє сформувати електронний каталог авто, які доступні для продажу або
вже передані. Менеджер також може оновити статус машини, наприклад,
позначити її як «Передано» або «Відправлено на обслуговування». Ця інформація
впливає на логістику та планування.
У розділі «Клієнти» формується електронна база контактів із можливістю
зберігання імен, телефонів та електронних адрес. Ці дані згодом
використовуються для асоціювання із сервісними записами та аналізу історії
звернень. Логіст у вкладці «Доставлення» вводить дату транспортування, пункт
призначення та позначає, чи завершена доставка. Інформація пов’язується з
конкретним автомобілем, що дозволяє візуально бачити шлях його переміщення
в рамках дилерського центру.
Нарешті, сервісний працівник через вкладку «Сервіс» додає записи про
обслуговування, вказуючи ідентифікатор автомобіля, клієнта, дату сервісу та
короткий опис робіт. Це дозволяє зберігати історію взаємодії з клієнтом та
відстежувати, які автомобілі потребували обслуговування, коли і з якої причини.
Усі дії супроводжуються автоматичним оновленням інтерфейсу без
необхідності перезапуску програми. Попап-форми, які відкриваються при
додаванні або редагуванні даних, мають зрозуміле структурування: лейбли
вирівняні по лівому краю, поля вводу компактні, кнопка збереження знаходиться
в нижній частині форми — усе це підвищує загальну ергономіку. Якщо
користувач обирає запис у таблиці та натискає кнопку «Редагувати», форма
автоматично підтягує наявні дані для зручності. Якщо не вибрано жодного рядка,
виводиться попередження.
Функціонал побудовано таким чином, що навіть при мінімальному
технічному рівні користувача вся робота інтуїтивно зрозуміла. Кожна вкладка —
це логічно завершений функціональний блок, який виконує чітко визначені дії
без зайвих переходів між екранами. Така модульність дозволяє в майбутньому
31
легко розширити систему, додавши, наприклад, окремий модуль тест-драйвів,
календар записів, аналітичні панелі або авторизацію.
Таким чином, спроектований функціонал системи повністю відповідає
потребам бізнес-процесів автодилера: від моменту прийняття автомобіля на
склад до його передавання клієнту та подальшого сервісного супроводу.
Функціональне навантаження рівномірно розподілено між розділами, а
архітектура інтерфейсу дозволяє масштабувати систему без зміни базової логіки.
Діаграма варіантів використання, що описує всі ролі та дії, формує
концептуальну основу для подальшого розширення.
3.3 Проєктування бази даних
База даних у системі управління автодилером є центральною складовою,
яка об’єднує всі модулі програми та забезпечує логічну цілісність інформації.
Вона спроєктована на основі реальних об’єктів предметної області, таких як
транспортні засоби, клієнти, операції доставлення та записи сервісного
обслуговування. Побудова структури здійснювалась з урахуванням принципів
реляційної моделі та нормалізації для уникнення дублювання даних і
забезпечення їх логічної зв’язаності.
Таблиця 3.1 — Структура таблиці vehicles
Назва поля Тип даних Опис
id INTEGER (PK) Унікальний
ідентифікатор
автомобіля
vin TEXT VIN-код
brand TEXT Бренд (марка)
автомобіля
model TEXT Модель автомобіля
32
year INTEGER Рік випуску
status TEXT Статус
(доступний/недоступний
тощо)
Таблиця 3.2 — Структура таблиці clients
Назва поля Тип даних Опис
id INTEGER (PK) Унікальний
ідентифікатор клієнта
name TEXT Ім’я клієнта
phone TEXT Номер телефону
email TEXT Електронна пошта
Таблиця 3.3 — Структура таблиці deliveries
Назва поля Тип даних Опис
id INTEGER (PK) Унікальний
ідентифікатор доставки
vehicle_id INTEGER (FK) Зовнішній ключ на
таблицю vehicles
delivery_date TEXT Дата доставки
destination TEXT Пункт
призначення
delivered BOOLEAN Статус доставки
(true/false)
33
Таблиця 3.4 — Структура таблиці service_records
Назва поля Тип даних Опис
id INTEGER (PK) Унікальний
ідентифікатор запису
сервісу
vehicle_id INTEGER (FK) Зовнішній ключ на
таблицю vehicles
client_id INTEGER (FK) Зовнішній ключ на
таблицю clients
service_date TEXT Дата сервісного
обслуговування
description TEXT Опис виконаних
робіт
Для візуалізації структури було створено ER-діаграму, яка подана нижче.
На ній чітко відображено всі сутності, їхні атрибути, а також зв’язки типу один-
до-багатьох між таблицями. Наприклад, один автомобіль може мати багато
записів у сервісній історії або бути доставлений у різні місця, але кожен запис
пов'язаний лише з одним конкретним авто.
34
Рисунок 3.2 — ER-діаграма бази даних
Основним об’єктом бази виступає таблиця vehicles, яка містить унікальну
інформацію про кожен автомобіль: VIN-код, марку, модель, рік випуску та
статус. Ця таблиця має прямі зв’язки з іншими сутностями, адже кожна доставка
і кожне обслуговування повинні бути прив’язані до конкретного автомобіля. У
структурі це реалізовано через зовнішні ключі в таблицях deliveries і
service_records, які посилаються на поле id у таблиці транспортних засобів.
Дані про клієнтів зберігаються окремо в таблиці clients, що дозволяє
уніфікувати запис і зберігати лише актуальні контактні відомості: ім’я, номер
телефону, електронну пошту. Це дозволяє надалі використовувати ці дані в
аналітичних звітах, CRM-модулів або маркетингових розсилках. У модулі
сервісного обслуговування кожен запис service_records має зв’язок як із клієнтом,
так і з автомобілем, що дозволяє зберігати повну історію обслуговування по
кожному клієнту і кожному транспортному засобу окремо.
35
Операції доставлення об’єднуються в таблицю deliveries, у якій фіксується,
який саме автомобіль було передано, куди, коли і чи завершено транспортування.
Для цього запис містить зовнішній ключ vehicle_id, дату доставки, пункт
призначення і булеве поле, яке відображає статус — доставлено чи ні.
Всі таблиці спроєктовані з урахуванням того, що їхній вміст буде
змінюватись у динаміці. Тобто система дозволяє не лише створювати нові записи,
а й редагувати або видаляти існуючі, що важливо в реальній роботі, де помилки
введення або зміни планів є звичними явищами. Структура таблиць забезпечує
консистентність і дозволяє зберігати логічні зв’язки між сутностями.
3.4 Проєктування внутрішньої будови
Структура внутрішньої побудови системи TMS для автодилера сформована
за принципами об’єктно-орієнтованого проєктування. У фокусі перебуває
розділення логіки на логічні класи, відповідальні за певні функціональні ділянки,
та організація взаємодії між ними. Це дозволяє не лише структуризувати
програму, а й забезпечити її масштабованість, зрозумілість, підтримуваність і
мінімальну залежність між частинами.
В основі всього застосунку лежить центральний модуль MainApp, який
відповідає за запуск усієї системи, ініціалізацію бази даних та графічного
інтерфейсу. Саме тут викликається функція init_db(), яка перевіряє наявність
таблиць, і, якщо потрібно, створює їх. Після цього здійснюється побудова GUI за
допомогою функції launch_gui(), яка формує усі вікна, вкладки та механізми
взаємодії з користувачем. Водночас MainApp є свого роду диспетчером, що
координує взаємодію між іншими об’єктами: транспортними засобами,
клієнтами, записами доставки та сервісу.
36
Рисунок 3.3 — Діаграма класів системи
Клас Vehicle представлений у базі даних як таблиця vehicles. Хоча явно як
клас у Python він не оформлений, його структура реалізована через словник
стовпців, і вся логіка додавання, редагування, видалення записів стосується саме
цієї сутності. Кожен запис містить ідентифікатор, унікальний VIN-код, марку,
модель, рік випуску та поточний статус. Цей об'єкт є ключовим для всієї системи,
адже довкола нього будуються всі інші операції. У коді GUI він використовується
у вкладці «Автомобілі», а всі форми працюють із його полями.
Аналогічно структурований клас Client, що відповідає за представлення
інформації про клієнтів. Його поля включають ім’я, телефон, email, а також
унікальний ID. Ці дані фіксуються у відповідній таблиці й надалі пов’язуються із
записами обслуговування. У формі GUI реалізовано дії додавання, редагування,
видалення клієнтів, що дозволяє оперативно підтримувати актуальну клієнтську
базу.
Клас Delivery втілює логіку доставлення транспортних засобів. Його
атрибути включають зовнішній ключ на vehicle_id, дату, пункт призначення та
булеве поле delivered. Цей об’єкт дозволяє фіксувати маршрут та статус доставки.
37
Внутрішньо реалізовано просту взаємодію з таблицею в інтерфейсі, з тією ж
логікою редагування, видалення та додавання, як і в попередніх модулях.
Сутність ServiceRecord є класом, який містить поля, що зв’язують
автомобіль із клієнтом через відповідні зовнішні ключі, а також зберігає дату
обслуговування і опис виконаних робіт. Цей клас підтримує ведення повної
сервісної історії по кожному клієнту та кожному авто, а його реалізація в GUI дає
змогу зручно вводити та редагувати записи.
Хоча у коді не реалізовано окремі Python-класи із конструкторами, класова
логіка чітко прослідковується через структури таблиць, логіку запитів до БД та
розділення функціоналу у вікнах інтерфейсу. Вся система працює у форматі
модульної архітектури, де кожен блок — це логічно ізольований, проте
пов'язаний з іншими, функціональний компонент. Кожен із розділів GUI
відповідає певній таблиці, і вся логіка взаємодії побудована так, щоб не
порушити загальну структуру при редагуванні або масштабуванні окремої
частини.
Центральний модуль, що виконує запуск усіх процесів, лишається
максимально лаконічним: він лише ініціалізує БД та відкриває інтерфейс.
Завдяки цьому код програми легко адаптувати під нові потреби. Наприклад, при
додаванні нового класу або таблиці достатньо розширити список вкладок, додати
поля форми та включити логіку збереження — все інше лишається незмінним.
Така архітектура значно полегшує підтримку та дозволяє розробляти нові модулі
незалежно від існуючих.
Таким чином, внутрішня будова системи реалізована у відповідності до
принципів простоти, модульності та чіткої відповідності бізнес-логіці предметної
області.
38
3.5 Проєктування розгортання системи
Розгортання TMS-системи автодилера здійснюється в умовах
максимальної автономності та простоти — без серверних компонентів, без
мережевої архітектури, без залежності від хмарних технологій чи зовнішніх API.
Такий підхід не лише знижує вартість впровадження, а й робить систему
універсальною: вона може бути запущена на будь-якому комп’ютері, навіть
офлайн, без складних інсталяцій чи спеціалізованої технічної підготовки.
Ключовою умовою є наявність операційної системи Windows (або іншої з
встановленим Python), базової підтримки графічного інтерфейсу, та Python-
інтерпретатора з модулем Tkinter.
Рисунок 3.4 — Діаграма розгортання системи
Фізично система складається з кількох файлів, які розміщуються в одній
директорії. Головний файл — tms_main.py, що містить увесь програмний код:
ініціалізацію бази, запуск GUI, логіку всіх CRUD-операцій. Поруч із ним
зберігається файл бази даних tms_dealer.db, який і є фактичним сховищем усіх
записів — від клієнтів до сервісної історії. Після першого запуску база
створюється автоматично, якщо вона ще не існує, завдяки механізму init_db().
39
Ніяких серверів, налаштування хостів або підключення до СУБД не
потрібно: усі дані знаходяться в локальному .db-файлі, який відкривається
безпосередньо засобами бібліотеки sqlite3. Це забезпечує максимальну швидкість
доступу та практично миттєву роботу з інформацією. Завдяки реляційній
структурі база підтримує транзакції, індекси та зв’язки між таблицями, і при
цьому залишається компактною.
Інтерфейсна частина реалізована засобами Tkinter — нативної GUI-
бібліотеки, що вже входить до стандартної поставки Python. Це дозволяє
уникнути сторонніх залежностей і гарантує, що програма буде працювати всюди,
де є Python. При запуску tms_main.py користувач одразу потрапляє до головного
вікна програми, де бачить вкладки з таблицями: «Автомобілі», «Клієнти»,
«Доставлення», «Сервіс». Встановлення не потребує інсталяторів чи записів у
реєстрі — достатньо завантажити архів із файлами та запустити програму
подвійним кліком або через консоль.
Щодо структури збереження, важливо зазначити, що файл tms_dealer.db є
повністю автономним. Його можна скопіювати на флешку, хмару, інший
комп’ютер — і система відразу запрацює на новому місці, не втративши жодного
запису. Це відкриває можливості для резервного копіювання: достатньо
періодично зберігати копію файлу на інший носій, щоб забезпечити захист від
втрати даних.
У розгортанні також враховано ситуацію з оновленням. Якщо з’являється
нова версія програми, достатньо замінити файл tms_main.py, не чіпаючи базу
tms_dealer.db. Це дозволяє розробникам оперативно впроваджувати нові функції
без ризику для наявної інформації.
Ще однією перевагою локального розгортання є швидкодія. Оскільки
жоден запит не виходить за межі пристрою, усі операції — вставка, редагування,
відображення — виконуються практично миттєво. Це особливо важливо в офісах
40
з повільним інтернетом або взагалі без нього, наприклад, у віддалених
автосалонах.
Із точки зору користувача, запуск системи не вимагає жодних навичок.
Інтерфейс інтуїтивний, не потребує входу в систему чи створення облікових
записів. Всі дії — додавання, редагування, видалення — супроводжуються
візуальними підказками, діалоговими вікнами, попередженнями про помилки.
Для роботи достатньо мати базовий комп’ютер і мишку.
Для перенесення системи з одного комп’ютера на інший також не потрібно
нічого складного. Архів із файлами програми просто копіюється на новий
пристрій. Якщо потрібно працювати з резервною копією, достатньо замінити
файл tms_dealer.db на резервний. У плані мобільності це ідеальний варіант для
невеликого бізнесу.
Таким чином, система спроєктована з урахуванням мінімізації
залежностей, простоти обслуговування, стабільності та максимальної зручності
для кінцевого користувача. Вона не вимагає серверів, ліцензій, хмарних рішень
чи налаштувань — лише Python, Tkinter і SQLite. Це дозволяє автодилеру
отримати функціональну, швидкодіючу та безпечну систему управління, яку
легко запустити, підтримувати і масштабувати при потребі.
Висновки до розділу 3
У цьому підрозділі було обґрунтовано вибір технологічного стеку для
реалізації TMS-системи офіційного дилера автотранспортних засобів, виходячи з
критеріїв оптимального балансу між простотою розробки, надійністю,
масштабованістю та відсутністю ліцензійних обмежень. Основним засобом
реалізації обрано мову програмування Python, що зумовлено її лаконічністю,
зручністю, широкою спільнотою та підтримкою об'єктно-орієнтованої моделі
програмування.
41
Графічний інтерфейс користувача буде розроблено за допомогою
бібліотеки Tkinter, яка є стандартним модулем Python, що усуває потребу в
додаткових інсталяціях та залежностях, забезпечуючи інтуїтивно зрозумілий та
функціональний інтерфейс. Для зберігання даних обрано вбудовану реляційну
систему управління базами даних SQLite. Це рішення спрощує розгортання,
резервне копіювання та адміністрування, оскільки всі дані зберігаються в одному
локальному файлі, що ідеально підходить для внутрішнього використання в
умовах обмеженого числа одночасних користувачів.
42
4 ПРОГРАМНА РЕАЛІЗАЦІЯ ТА ТЕСТУВАННЯ
4.1 Реалізація бази даних
Однією з основних частин розробки TMS-системи для автодилера є
ефективне управління даними, що зберігаються в базі. У даному випадку для
зберігання даних обрано реляційну базу даних SQLite, що забезпечує
компактність, швидкість доступу та мінімальні вимоги до інфраструктури.
Модель бази включає чотири основні таблиці, що взаємопов’язані між собою:
vehicles, clients, deliveries, service_records.
Для ініціалізації бази даних у програмі використовується функція init_db(),
яка викликається при запуску застосунку і відповідає за створення всіх
необхідних таблиць, якщо вони ще не існують.
SQL код для ініціалізації бази даних:
import sqlite3
DB_NAME = "tms_dealer.db"
def init_db():
conn = sqlite3.connect(DB_NAME)
cursor = conn.cursor()
cursor.executescript("""
CREATE TABLE IF NOT EXISTS vehicles (
id INTEGER PRIMARY KEY AUTOINCREMENT,
vin TEXT UNIQUE NOT NULL,
brand TEXT,
model TEXT,
year INTEGER,
status TEXT DEFAULT 'На складі'
);
43
CREATE TABLE IF NOT EXISTS clients (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT,
phone TEXT,
email TEXT
);
CREATE TABLE IF NOT EXISTS deliveries (
id INTEGER PRIMARY KEY AUTOINCREMENT,
vehicle_id INTEGER,
delivery_date TEXT,
destination TEXT,
delivered BOOLEAN DEFAULT 0,
FOREIGN KEY(vehicle_id) REFERENCES vehicles(id)
);
CREATE TABLE IF NOT EXISTS service_records (
id INTEGER PRIMARY KEY AUTOINCREMENT,
vehicle_id INTEGER,
client_id INTEGER,
service_date TEXT,
description TEXT,
FOREIGN KEY(vehicle_id) REFERENCES vehicles(id),
FOREIGN KEY(client_id) REFERENCES clients(id)
);
""")
conn.commit()
conn.close()
44
Опис таблиць:
1. vehicles — ця таблиця містить основну інформацію про автомобілі,
зокрема:
o id — унікальний ідентифікатор автомобіля;
o vin — VIN-код автомобіля, що є унікальним і обов’язковим для
кожного запису;
o brand — марка автомобіля;
o model — модель автомобіля;
o year — рік випуску;
o status — поточний статус автомобіля, наприклад, "На складі",
"Передано клієнту", "В обслуговуванні".
Ця таблиця є базою для інших таблиць, оскільки вона містить інформацію
про транспортні засоби, яка є основною для функціонування всієї системи.
2. clients — таблиця для зберігання даних про клієнтів:
o id — унікальний ідентифікатор клієнта;
o name — ім’я клієнта;
o phone — номер телефону клієнта;
o email — електронна пошта клієнта.
Важливо, що всі клієнти мають унікальний запис, і ця таблиця взаємодіє з
таблицею service_records для зберігання історії обслуговування.
3. deliveries — таблиця для зберігання інформації про доставку
автомобілів:
o id — унікальний ідентифікатор запису доставки;
o vehicle_id — ідентифікатор автомобіля, на який зроблено
доставлення (зовнішній ключ до таблиці vehicles);
o delivery_date — дата доставки;
o destination — пункт призначення доставки;
45
o delivered — булеве поле, яке вказує, чи завершена доставка.
Ця таблиця дозволяє відстежувати, чи автомобіль був доставлений, а також
зберігає дані про пункт призначення і дату.
4. service_records — таблиця для зберігання записів про обслуговування
автомобілів:
o id — унікальний ідентифікатор сервісного запису;
o vehicle_id — ідентифікатор автомобіля, який обслуговувався
(зовнішній ключ до таблиці vehicles);
o client_id — ідентифікатор клієнта, що замовляв обслуговування
(зовнішній ключ до таблиці clients);
o service_date — дата виконання обслуговування;
o description — короткий опис виконаних робіт.
Завдяки цій таблиці система зберігає повну історію обслуговування
кожного автомобіля і пов’язує її з клієнтом.
Взаємозв'язки між таблицями
Таблиця vehicles має зв'язки з таблицею deliveries та таблицею
service_records. Це означає, що кожен автомобіль може мати кілька
доставок та записів обслуговування, але кожен запис пов'язаний лише з
одним конкретним автомобілем.
Таблиця clients має зв'язок з таблицею service_records, що дозволяє
відслідковувати історію обслуговування клієнта на основі ідентифікатора
клієнта.
Ці зв’язки реалізовані через зовнішні ключі, що гарантує цілісність даних і
дозволяє проводити складні запити для отримання історії обслуговування
автомобіля або взаємодії клієнта з сервісним центром.
Транзакції та підтримка цілісності даних
46
SQLite, як система управління базами даних, підтримує транзакції, що дає
можливість виконувати кілька запитів до бази в межах однієї операції. Це
дозволяє уникнути помилок при частковому збереженні даних. Наприклад, якщо
при додаванні запису про доставку система не зможе зберегти всі необхідні дані
(наприклад, через порушення цілісності зв’язків), то зміни не будуть застосовані
до бази, і система збереже консистентність даних.
Резервне копіювання та відновлення даних
Файл бази даних tms_dealer.db є єдиним джерелом збереження інформації.
Для забезпечення безпеки даних передбачено регулярне резервне копіювання
цього файлу. Користувач може копіювати файл у будь-яке місце, наприклад, на
зовнішній носій або хмару, і в разі необхідності відновити його у новому
середовищі без втрати даних.
4.2 Реалізація основних алгоритмів
Основні алгоритми у цій системі обробляють операції додавання,
редагування, видалення та оновлення даних у базі даних SQLite. Ці операції
реалізовані через чітко структуровані функції, які здійснюють взаємодію з
графічним інтерфейсом і базою даних, забезпечуючи ефективну обробку даних
користувачем.
Ініціалізація бази та створення таблиць.
При запуску програми викликається функція init_db(), яка ініціалізує базу
даних і створює необхідні таблиці, якщо вони ще не існують. Це важливий етап,
оскільки гарантується, що таблиці для зберігання інформації про автомобілі,
клієнтів, доставлення та сервісне обслуговування будуть створені автоматично.
Таблиці vehicles, clients, deliveries, service_records створюються за
допомогою SQL-скрипта, що виконується через SQLite-запити. При цьому всі
47
таблиці мають зовнішні ключі, що з’єднують записи між собою: для зв’язку
автомобіля з доставкою або обслуговуванням.
Оновлення інтерфейсу користувача.
Після ініціалізації бази даних програма переходить до відображення
графічного інтерфейсу користувача. Це відбувається через функцію launch_gui(),
яка ініціалізує основне вікно програми та вбудовує в нього вкладки для кожної
категорії даних (автомобілі, клієнти, доставлення, сервіс).
Кожна вкладка використовує віджет Treeview для виведення таблиць з
даними. Користувач може взаємодіяти з цими таблицями, вибирати записи для
редагування або видалення, а також додавати нові записи через спеціальні форми.
Додавання нового запису.
Алгоритм додавання нового запису в таблицю описано в функції
popup_form(). Коли користувач натискає кнопку «Додати», відкривається
модальне вікно, де він може ввести необхідні дані. Ця форма динамічно підтягує
поля, відповідні для кожної таблиці, наприклад, VIN-код, марку, модель для
автомобілів або ім’я та телефон для клієнтів.
Як тільки користувач натискає кнопку «Зберегти», дані, введені в форму,
передаються до функції save(), де здійснюється виконання SQL-запиту на вставку
нового запису в базу даних. При цьому запит будується динамічно, в залежності
від кількості полів, що вводяться.
def save():
values = [e.get() for e in entries.values()]
conn = sqlite3.connect(DB_NAME)
cursor = conn.cursor()
try:
if mode == "add":
placeholders = ",".join(["?"] * len(values))
48
cursor.execute(f"INSERT INTO {section['table']} ({',
'.join(section['columns'][1:len(values)+1])}) VALUES ({placeholders})", values)
conn.commit()
popup.destroy()
refresh(tree, section['table'], section['columns'])
except Exception as e:
messagebox.showerror("Помилка", str(e))
conn.close()
У цьому фрагменті відбувається збір усіх значень, введених у форму, і
передача їх у SQL-запит. Запит формує відповідні плейсхолдери ? для кожного
введеного значення, щоб уникнути SQL-ін’єкцій. Після цього значення
вставляються в таблицю за допомогою SQL-запиту.
Редагування існуючого запису
Алгоритм редагування працює за схожим принципом. Якщо користувач
вибирає запис для редагування, у форму підтягуються поточні дані цього запису,
і після внесення змін він може зберегти нові значення. Ключовою різницею є те,
що при редагуванні запису використовується SQL-запит на оновлення запису в
базі:
else:
sets = ", ".join(f"{col}=?" for col in section['columns'][1:len(values)+1])
cursor.execute(f"UPDATE {section['table']} SET {sets} WHERE id=?",
values + [selected[0]])
Цей запит оновлює значення в таблиці для конкретного запису,
ідентифікованого за його унікальним id, яке передається як останнє значення в
масиві.
Видалення запису.
49
Алгоритм видалення є досить простим: користувач вибирає запис у таблиці
і натискає кнопку «Видалити». Після цього програма видаляє запис із бази даних
за допомогою SQL-запиту DELETE:
def delete_record(section, tree):
selected = tree.selection()[0]
item_id = tree.item(selected)["values"][0]
conn = sqlite3.connect(DB_NAME)
cursor = conn.cursor()
cursor.execute(f"DELETE FROM {section['table']} WHERE id=?",
(item_id,))
conn.commit()
conn.close()
refresh(tree, section["table"], section["columns"])
Цей код видаляє запис, ідентифікований через його id, що отримується з
вибраного елементу таблиці.
Оновлення таблиці
Після кожної операції (додавання, редагування або видалення) таблиця
оновлюється через функцію refresh(). Вона отримує з бази нові дані та відображає
їх на екрані:
def refresh(tree, table, columns):
tree.delete(*tree.get_children())
conn = sqlite3.connect(DB_NAME)
cursor = conn.cursor()
cursor.execute(f"SELECT {', '.join(columns)} FROM {table}")
for row in cursor.fetchall():
tree.insert("", "end", values=row)
50
conn.close()
Ця функція запитує всі записи з таблиці та оновлює дерево даних, що
відображається на екрані, гарантує, що користувач побачить актуальну
інформацію після кожної операції.
4.3 Реалізація інтерфейсу користувача
Інтерфейс користувача в системі TMS для автодилера побудований на
основі бібліотеки Tkinter, що дозволяє швидко створювати графічні інтерфейси з
мінімальними зусиллями та без зовнішніх залежностей. Це дозволяє забезпечити
максимальну сумісність програми з різними операційними системами та
спростити процес розгортання та підтримки.
Графічний інтерфейс розроблений так, щоб бути інтуїтивно зрозумілим для
кінцевого користувача. Основні компоненти інтерфейсу включають:
Вікно головного застосунку, в якому відображаються всі вкладки з
таблицями.
Кнопки для додавання, редагування та видалення записів у таблицях.
Модальні вікна для введення даних, що дозволяють користувачу
взаємодіяти з системою без перенавантаження основного інтерфейсу.
Основне вікно програми.
Код для створення головного вікна виглядає наступним чином:
def launch_gui():
root = tk.Tk()
root.title("TMS автодилера")
root.geometry("1100x700")
notebook = ttk.Notebook(root)
notebook.pack(fill="both", expand=True)
51
У цьому фрагменті створюється основне вікно програми, яке має заголовок
«TMS автодилера» і фіксований розмір 1100x700 пікселів. Для зручності роботи
з різними вкладками інтерфейсу використовуємо віджет Notebook, який дозволяє
розмістити вкладки, що зберігають відповідні дані для кожної категорії:
«Автомобілі», «Клієнти», «Доставлення», «Сервіс». Кожна з цих вкладок буде
містити таблицю з даними, з якою користувач може взаємодіяти.
Рисунок 5.1 — Головне вікно програми з вкладками
Вкладки інтерфейсу.
Кожна вкладка в Notebook відповідає за окрему категорію даних. Це дає
змогу зберігати логічне розділення та зручність навігації. Код для додавання
вкладок виглядає так:
sections = [
{
"name": "Автомобілі", "table": "vehicles",
52
"columns": ["id", "vin", "brand", "model", "year", "status"],
"fields": ["VIN", "Марка", "Модель", "Рік"]
},
{
"name": "Клієнти", "table": "clients",
"columns": ["id", "name", "phone", "email"],
"fields": ["Ім’я", "Телефон", "Email"]
},
{
"name": "Доставлення", "table": "deliveries",
"columns": ["id", "vehicle_id", "delivery_date", "destination",
"delivered"],
"fields": ["ID авто", "Дата", "Пункт призначення"]
},
{
"name": "Сервіс", "table": "service_records",
"columns": ["id", "vehicle_id", "client_id", "service_date",
"description"],
"fields": ["ID авто", "ID клієнта", "Дата обслуговування", "Опис"]
}
]
Для кожної вкладки визначено:
name — назва вкладки, яка буде відображена на самому інтерфейсі.
table — назва таблиці в базі даних, з якою ця вкладка буде працювати.
columns — список колонок, які необхідно відобразити.
fields — поля для введення, які користувач буде заповнювати при додаванні
чи редагуванні запису.
53
Цей масив дозволяє динамічно створювати вкладки з необхідними полями
й таблицями для відображення даних.
Рисунок 5.2 — Вкладка "Автомобілі" з таблицею
Таблиця та взаємодія з даними
Для відображення даних на вкладці використовується компонент Treeview:
tree = ttk.Treeview(frame, columns=sec["columns"], show="headings")
for col in sec["columns"]:
tree.heading(col, text=col)
tree.column(col, width=100, anchor="center")
tree.pack(fill="both", expand=True, padx=10, pady=10)
омпонент Treeview дозволяє створювати таблицю з можливістю
відображення заголовків та даних. Для кожної вкладки визначається список
колонок, які відображаються в таблиці. Тут також задаються параметри ширини
54
колонок та їх вирівнювання. Для кожної вкладки дані виводяться через SQL-
запит, який отримує всі записи з відповідної таблиці.
При цьому таблиця підтримує операції додавання, редагування та
видалення. Наприклад, для додавання нового запису викликається попап-форма,
яка дозволяє користувачу ввести нові дані:
ttk.Button(btn_frame, text="Додати", width=20, command=lambda s=sec,
t=tree: popup_form(s, "add", t)).pack(side="left", padx=10)
Це відображає кнопку «Додати» внизу кожної вкладки. Коли користувач
натискає цю кнопку, відкривається форма для введення нового запису, яка
зберігається у базі даних через SQL-запит. Після цього таблиця оновлюється, щоб
відобразити новий запис.
Рисунок 5.3 — Форма додавання нового запису
Редагування і видалення записів.
55
Подібно до додавання, редагування й видалення записів здійснюється через
відповідні кнопки, що викликають відповідні функції. Для редагування
вибраного запису потрібно вибрати рядок у таблиці, після чого відкривається
форма, де користувач може змінити дані і зберегти їх:
ttk.Button(btn_frame, text="Редагувати", width=20, command=lambda
s=sec, t=tree: (
popup_form(s, "edit", t, t.item(t.selection()[0])["values"]) if t.selection()
else messagebox.showwarning("Увага", "Оберіть запис")
)).pack(side="left", padx=10)
Цей код перевіряє, чи вибрано запис у таблиці. Якщо так, викликається
форма редагування з попередньо заповненими полями.
Аналогічно, для видалення запису користувач вибирає рядок і натискає
кнопку «Видалити», після чого запис видаляється з бази даних через SQL-запит:
ttk.Button(btn_frame, text="Видалити", width=20, command=lambda
s=sec, t=tree: (
delete_record(s, t) if t.selection() else
messagebox.showwarning("Увага", "Оберіть запис")
)).pack(side="left", padx=10)
Після видалення таблиця оновлюється, і користувач бачить актуальний
список записів.
56
Рисунок 5.4 — Форма редагування запису
Інтерфейс програми створений з урахуванням зручності використання та
простоти. Усі основні функції доступні через вкладки з таблицями, що дозволяє
користувачу без зайвих зусиль управляти даними про автомобілі, клієнтів,
доставку та сервіс. Підключення до бази даних через SQLite забезпечує миттєву
взаємодію з даними, а зручні форми для введення/редагування записів
дозволяють працювати з програмою без необхідності розбиратись у технічних
деталях. Такий підхід робить програму зручною для кінцевого користувача, що є
основним завданням при розробці бізнес-приладдя.
57
4.4 Тестування системи
Тестування є важливим етапом у розробці програмного забезпечення,
оскільки дозволяє виявити помилки, неполадки та неочікувані поведінки
системи. Для TMS-системи автодилера тестування буде зосереджено на перевірці
всіх основних функцій: від роботи з базою даних до графічного інтерфейсу,
взаємодії між компонентами та загальної стабільності системи.
Мета тестування.
Метою тестування є забезпечення надійності та стабільності системи, а
також перевірка всіх основних функціональних можливостей:
1. Коректне додавання, редагування та видалення записів у базі даних.
2. Правильне відображення даних у графічному інтерфейсі.
3. Оновлення таблиць після кожної операції.
4. Перевірка збереження даних у базі при перезапуску програми.
5. Перевірка коректної роботи модальних вікон та форм для
додавання/редагування записів.
Підготовка до тестування.
Тестування буде здійснюватися в кілька етапів, починаючи від базових
перевірок функціональності бази даних, закінчуючи тестами інтерфейсу та
взаємодії з користувачем.
Тестування бази даних: перевіряємо правильність створення таблиць,
вставку, оновлення та видалення даних.
Тестування інтерфейсу користувача: перевіряємо, чи правильно
відображаються дані на вкладках, чи працюють форми для
введення/редагування, чи коректно обробляються помилки користувача.
Тестування інтеграції: перевірка всіх компонентів разом, щоб переконатися
в їхній взаємодії та стабільності.
Методика тестування.
58
Тестування здійснюватиметься вручну через інтерфейс програми, а також
за допомогою написаних тестів, які перевіряють правильність роботи основних
алгоритмів. Ось як це виглядає:
1. Запуск програми і перевірка ініціалізації бази даних.
2. Перевірка додавання нового запису в таблицю «Автомобілі»
(перевірка на унікальність VIN).
3. Перевірка оновлення запису (наприклад, зміна статусу автомобіля).
4. Перевірка видалення запису та оновлення таблиці.
5. Тестування усіх форм на правильність заповнення, перевірка
обробки помилок введення.
6. Перевірка правильності відображення даних на вкладках.
7. Перевірка роботи з резервними копіями бази даних.
Таблиця 5.1 — Таблиця тестування TMS-системи для автодилера
№ Опис тесту Модуль/Функція Очікуваний Результат Примітки
результат
1 Перевірка Ініціалізація БД Таблиці vehicles, Пройшло База даних
ініціалізації clients, deliveries, успішно створена без
бази даних при service_records помилок
запуску повинні бути
програми створені
2 Додавання Додавання в БД Новий Пройшло VIN має бути
нового запису автомобіль успішно унікальним
в таблицю додається з
«Автомобілі» унікальним VIN,
маркою,
моделлю
3 Перевірка Валідація VIN Програма Пройшло Звіт про помилку
унікальності повинна успішно при дублюванні
VIN при заборонити VIN
59
додаванні додавання авто з
нового запису однаковим VIN
4 Оновлення Оновлення в БД Статус авто Пройшло Оновлені дані
запису в змінюється на успішно відображаються в
таблиці «Передано» таблиці
«Автомобілі» після продажу
5 Видалення Видалення в БД Запис повинен Пройшло Запис більше не
запису в бути видалений з успішно з’являється в
таблиці бази, і таблиця таблиці
«Автомобілі» повинна
оновитися
6 Перевірка Форма додавання Форма повинна Пройшло Дані збережено в
заповнення клієнта коректно успішно БД
форми для зберігати ім’я,
додавання телефон та email
нового клієнта клієнта
7 Перевірка Редагування Зміна номеру Пройшло Дані
редагування клієнта телефону успішно оновлюються
даних клієнта повинна оновити після
дані в БД редагування
8 Перевірка Форма доставки Доставка Пройшло Запис збережено
форми для зберігається з успішно в таблиці
додавання правильною deliveries
запису про датою та
доставку пунктом
призначення
9 Перевірка Вкладка Всі записи про Пройшло Дані виводяться
відображення «Доставлення» доставку повинні успішно коректно
даних про бути видимими
доставку на та коректно
вкладці відображеними
«Доставлення»
60
10 Тестування Інтеграція між Дані про Пройшло Обслуговування
взаємодії між модулями автомобіль успішно асоціюється з
вкладками мають бути авто
«Автомобілі» і доступні для
«Сервіс» додавання
записів про
обслуговування
11 Перевірка Резервне Копія бази даних Пройшло База даних
резервного копіювання створюється без успішно відновлюється з
копіювання помилок та має резервної копії
бази даних бути
відновленою
після
перезапуску
12 Перевірка Валідація даних Програма Пройшло Порушення
помилок вводу повинна успішно перевіряється на
(наприклад, показати етапі введення
порожні поля в повідомлення
формі) про помилку,
якщо форма не
заповнена
13 Перевірка Взаємодія з Кожна кнопка Пройшло Усі кнопки
роботи всіх інтерфейсом повинна успішно працюють
кнопок на виконувати свою коректно
вкладках задачу:
(Додати, додавання,
Редагувати, редагування або
Видалити) видалення
Таблиця тестів є базовим інструментом для перевірки всіх важливих
функцій системи. Всі тестові сценарії були розроблені так, щоб повністю покрити
функціональність програми, перевіряючи основні операції з базою даних,
61
правильність відображення даних, коректність введення та валідації. Після
виконання кожного тесту користувач отримує або підтвердження успіху, або
помилку, яка буде відображена через повідомлення.
Ці тести мають бути виконані на всіх етапах розробки, а також під час
кожного оновлення програми, щоб переконатися, що система працює стабільно
після внесених змін.
Висновки до розділу 4
Запропонована TMS-система для офіційного дилера автотранспортних
засобів є комплексним програмним рішенням, спроектованим з урахуванням
сучасних підходів до розробки корпоративних інформаційних систем. В її основу
покладено принципи об'єктно-орієнтованого програмування та багаторівневої
архітектури з шаблоном MVC, що забезпечує структурованість, гнучкість та
масштабованість системи. Для взаємодії з даними використовується ORM-підхід
та реляційна модель бази даних SQLite, що гарантує цілісність, надійність та
ефективність зберігання інформації про транспортні засоби, клієнтів,
доставлення та сервісне обслуговування. Забезпечення безпеки даних
реалізовано через аутентифікацію, авторизацію, хешування паролів та резервне
копіювання, а також механізми захисту від типових атак.
Функціонал системи повністю відповідає бізнес-потребам автодилера,
надаючи централізований інструмент для обліку та управління ключовими
операціями. Розроблений інтуїтивно зрозумілий графічний інтерфейс
користувача на базі Tkinter забезпечує простоту взаємодії з даними через логічно
розділені вкладки та зручні модальні форми для операцій додавання, редагування
та видалення записів. Вибір Python як основної мови програмування та SQLite як
системи управління базами даних мінімізує залежності, спрощує розгортання та
обслуговування системи, роблячи її автономною та економічно привабливо.
62
ВИСНОВКИ
Під час розробки TMS-системи для автодилера було створено потужний
інструмент, який автоматизує основні процеси обліку автомобілів, клієнтів,
доставки та сервісного обслуговування. Завдяки використанню Python, Tkinter і
SQLite, система вийшла компактною, стабільною та легкою в розгортанні.
Основним досягненням є реалізація повноцінного обліку транспортних
засобів, де кожен автомобіль має свій VIN, марку, модель, рік випуску та статус,
а також зручний механізм для відстеження доставок і сервісних записів. Це
дозволяє мінімізувати людський фактор, знижуючи ймовірність помилок при
введенні даних.
Інтерфейс програми був розроблений таким чином, щоб забезпечити
максимальну зручність для користувачів. Завдяки використанню вкладок для
кожної категорії даних — «Автомобілі», «Клієнти», «Доставлення», «Сервіс» —
користувач має змогу зручно і швидко працювати з системою. Крім того, кожна
вкладка включає таблиці, в яких відображаються дані, з можливістю їх
редагування, видалення або додавання нових записів.
Реалізація бази даних через SQLite стала важливим елементом у розробці
цієї системи. Вся інформація зберігається в одному файлі .db, що значно спрощує
розгортання та резервне копіювання даних. Завдяки реляційній структурі бази
даних, система забезпечує логічні зв’язки між різними сутностями, такими як
автомобілі, клієнти та записи про доставку і обслуговування.
Під час тестування було перевірено всі основні функції системи, зокрема
додавання, редагування, видалення записів і оновлення таблиць. Тести показали,
що система працює стабільно і коректно відображає дані. Всі основні сценарії,
такі як додавання нового автомобіля, зміна статусу, видалення клієнта та записів
про доставку, виконуються без помилок.
63
Попри досягнення основних цілей, існують можливості для подальшого
вдосконалення. Можна додати нові модулі, наприклад, для автоматизації тест-
драйвів, покращити функціональність аналітики чи розширити інтеграцію з
іншими інформаційними системами. Також є можливість розробити мобільну
версію програми або інтегрувати її з іншими корпоративними системами.
Загалом, система відповідає вимогам сучасного автодилерського бізнесу та
може бути успішно впроваджена у роботу компаній, що займаються продажем і
обслуговуванням транспортних засобів. Технічне рішення на основі Python та
SQLite дозволяє легко масштабувати та адаптувати програму під різні потреби
користувачів.
Ця система є прикладом того, як можна створити ефективне програмне
забезпечення для малого та середнього бізнесу з обмеженими ресурсами. Вона
забезпечує необхідну функціональність при мінімальних вимогах до
інфраструктури, що робить її ідеальним вибором для автодилерських
підприємств, які не потребують складних серверних рішень.
64
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Griffis, S. E., & Goldsby, T. J. (2007). Transportation Management
Systems: An Exploration of Progress and Future Prospects. Journal of Transportation
Management, 18(1), 18–32. doi:10.22237/jotm/1175385780. URL:
https://digitalcommons.wayne.edu/cgi/viewcontent.cgi?article=1179&context=jotm
2. Design and Implementation of a Tailored Dealer Management System
(DMS) for the Automotive Industry. ResearchGate. URL:
https://www.researchgate.net/publication/380181044_Design_and_Implementation_o
f_a_Tailored_Dealer_Management_System_DMS_for_the_Automotive_Industry
3. Improving Transportation Management Systems (TMSs) Based on Digital
Twin Concept. MDPI. URL: https://www.mdpi.com/2076-3417/14/4/1330
4. ICT-Platform to Transform Car Dealerships to Regional Providers of
Sustainable Mobility Services. ResearchGate. URL:
https://www.researchgate.net/publication/314391149_ICT-
Platform_to_Transform_Car_Dealerships_to_Regional_Providers_of_Sustainable_M
obility_Services
5. Черевко, Г.В. Інформаційні технології в менеджменті / Г.В. Черевко.
Київ: НАУ, 2020. 250 с.
6. Simchi-Levi, D. Designing and Managing the Supply Chain. McGraw-
Hill Education, 2021. 512 p.
7. Дмитренко, О.С. Інформаційні системи логістики. Харків: ХНЕУ,
2019. 312 с.
8. Романенко, Л.Г. CRM-системи в управлінні клієнтськими
відносинами. Наукові праці НУХТ. 2021. №2. С. 88–93.
9. Turban, E., Volonino, L. Information Technology for Management.
Wiley, 2021. 536 p.
10. Nielsen, J. Usability Engineering. Academic Press, 2020. 362 p.
11. Закон України «Про захист персональних даних» від 01.06.2010 №
2297-VI.
65
12. Deloitte Digital Mobility Report 2023. URL: https://www2.deloitte.com/
13. Toyota Logistics Services Overview, 2022. URL: https://global.toyota/en/
14. Volkswagen Digital Dealer Concept. URL:
https://www.volkswagenag.com/
15. Martin, R. C. Clean Architecture: A Craftsman's Guide to Software
Structure and Design. Prentice Hall, 2018. 432 p.
16. Freeman, E., Robson, E. Head First Design Patterns. O’Reilly Media,
2021. 694 p.
17. Ambler, S. Agile Database Techniques: Effective Strategies for the Agile
Software Developer. Wiley, 2003. 480 p.
18. OWASP Foundation. OWASP Top 10: 2021. URL:
https://owasp.org/www-project-top-ten/
19. bcrypt Documentation. GitHub. URL: https://github.com/pyca/bcrypt
20. Richardson, L. RESTful Web APIs. O’Reilly Media, 2023. 460 p.
21. Van Rossum, G., & Drake, F. L. The Python Language Reference Manual.
Network Theory Ltd, 2022. 248 p.
22. Lutz, M. Learning Python. O’Reilly Media, 2021. 1648 p.
23. Shipman, J. Tkinter 8.5 reference: a GUI for Python. New Mexico Tech,
2020. URL: https://infohost.nmt.edu/tcc/help/pubs/tkinter/
24. Hipp, D. R. SQLite Documentation. SQLite.org. 2023. URL:
https://sqlite.org/docs.html
25. Richardson, L., Ruby, S. RESTful Web Services. O’Reilly Media, 2022.
456 p.
26. Python Software Foundation. Python Software Foundation License. URL:
https://docs.python.org/3/license.html (дата звернення: 02.05.2025).
27. Hipp, D. R. SQLite Copyright and License. URL:
https://www.sqlite.org/copyright.html (дата звернення: 02.05.2025).
66
ДОДАТОК А
Затверджую
Зав. кафедри КНСА,
______________ Юрій ТРИУС
«____»____________2025 р.
TMS-СИСТЕМА ОФІЦІЙНОГО ДИЛЕРА АВТОТРАНСПОРТНИХ
ЗАСОБІВ
Специфікація 482.ЧДТУ. 52120-01
Листів 2
Розробник ____________________ Сіваченко Є.В.
Керівник ____________________ Підгорний М.В.
Черкаси – 2025
67
Позначення Найменування Примітка
Документація
482.ЧДТУ. 52120-01 12 01 Текст програми
482.ЧДТУ. 52120-01 34 01 Інструкція користувача
68
ДОДАТОК Б
TMS-СИСТЕМА ОФІЦІЙНОГО ДИЛЕРА АВТОТРАНСПОРТНИХ
ЗАСОБІВ
Текст програми 482.ЧДТУ. 52120-01 12 01
Листів 6
Розробник _____________ Сіваченко Є.В.
Черкаси – 2025
69
import sqlite3
import tkinter as tk
from tkinter import ttk, messagebox
DB_NAME = "tms_dealer.db"
# === БАЗА ===
def init_db():
conn = sqlite3.connect(DB_NAME)
cursor = conn.cursor()
cursor.executescript("""
CREATE TABLE IF NOT EXISTS vehicles (
id INTEGER PRIMARY KEY AUTOINCREMENT,
vin TEXT UNIQUE NOT NULL,
brand TEXT,
model TEXT,
year INTEGER,
status TEXT DEFAULT 'На складі'
);
CREATE TABLE IF NOT EXISTS clients (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT,
phone TEXT,
email TEXT
);
CREATE TABLE IF NOT EXISTS deliveries (
id INTEGER PRIMARY KEY AUTOINCREMENT,
vehicle_id INTEGER,
delivery_date TEXT,
destination TEXT,
delivered BOOLEAN DEFAULT 0,
FOREIGN KEY(vehicle_id) REFERENCES vehicles(id)
);
CREATE TABLE IF NOT EXISTS service_records (
id INTEGER PRIMARY KEY AUTOINCREMENT,
vehicle_id INTEGER,
client_id INTEGER,
service_date TEXT,
70
description TEXT,
FOREIGN KEY(vehicle_id) REFERENCES vehicles(id),
FOREIGN KEY(client_id) REFERENCES clients(id)
);
""")
conn.commit()
conn.close()
# === GUI ===
def launch_gui():
root = tk.Tk()
root.title("TMS автодилера")
root.geometry("1100x700")
notebook = ttk.Notebook(root)
notebook.pack(fill="both", expand=True)
sections = [
{
"name": "Автомобілі", "table": "vehicles",
"columns": ["id", "vin", "brand", "model", "year", "status"],
"fields": ["VIN", "Марка", "Модель", "Рік"]
},
{
"name": "Клієнти", "table": "clients",
"columns": ["id", "name", "phone", "email"],
"fields": ["Ім’я", "Телефон", "Email"]
},
{
"name": "Доставлення", "table": "deliveries",
"columns": ["id", "vehicle_id", "delivery_date", "destination", "delivered"],
"fields": ["ID авто", "Дата", "Пункт призначення"]
},
{
"name": "Сервіс", "table": "service_records",
"columns": ["id", "vehicle_id", "client_id", "service_date", "description"],
"fields": ["ID авто", "ID клієнта", "Дата обслуговування", "Опис"]
}
]
71
def refresh(tree, table, columns):
tree.delete(*tree.get_children())
conn = sqlite3.connect(DB_NAME)
cursor = conn.cursor()
cursor.execute(f"SELECT {', '.join(columns)} FROM {table}")
for row in cursor.fetchall():
tree.insert("", "end", values=row)
conn.close()
def popup_form(section, mode, tree, selected=None):
popup = tk.Toplevel()
popup.title(f"{'Редагувати' if mode == 'edit' else 'Додати'}
{section['name'].lower()}")
popup.geometry("400x400")
popup.grab_set()
entries = {}
for i, field in enumerate(section["fields"]):
tk.Label(popup, text=field, anchor="w").grid(row=i, column=0, padx=10, pady=5,
sticky="w")
e = tk.Entry(popup)
e.grid(row=i, column=1, padx=10, pady=5, sticky="we")
entries[field] = e
if mode == "edit" and selected:
for i, key in enumerate(section["fields"], start=1):
entries[key].insert(0, selected[i])
def save():
values = [e.get() for e in entries.values()]
conn = sqlite3.connect(DB_NAME)
cursor = conn.cursor()
try:
if mode == "add":
placeholders = ",".join(["?"] * len(values))
cursor.execute(f"INSERT INTO {section['table']} ({',
'.join(section['columns'][1:len(values)+1])}) VALUES ({placeholders})", values)
else:
sets = ", ".join(f"{col}=?" for col in
section['columns'][1:len(values)+1])
72
cursor.execute(f"UPDATE {section['table']} SET {sets} WHERE id=?", values
+ [selected[0]])
conn.commit()
popup.destroy()
refresh(tree, section['table'], section['columns'])
except Exception as e:
messagebox.showerror("Помилка", str(e))
conn.close()
tk.Button(popup, text="Зберегти", command=save).grid(row=len(entries)+1, column=0,
columnspan=2, pady=10)
for sec in sections:
frame = ttk.Frame(notebook)
notebook.add(frame, text=sec["name"])
tree = ttk.Treeview(frame, columns=sec["columns"], show="headings")
for col in sec["columns"]:
tree.heading(col, text=col)
tree.column(col, width=100, anchor="center")
tree.pack(fill="both", expand=True, padx=10, pady=10)
btn_frame = tk.Frame(frame)
btn_frame.pack(pady=10)
ttk.Button(btn_frame, text="Додати", width=20, command=lambda s=sec, t=tree:
popup_form(s, "add", t)).pack(side="left", padx=10)
ttk.Button(btn_frame, text="Редагувати", width=20, command=lambda s=sec, t=tree: (
popup_form(s, "edit", t, t.item(t.selection()[0])["values"]) if t.selection() else
messagebox.showwarning("Увага", "Оберіть запис")
)).pack(side="left", padx=10)
ttk.Button(btn_frame, text="Видалити", width=20, command=lambda s=sec, t=tree: (
delete_record(s, t) if t.selection() else messagebox.showwarning("Увага", "Оберіть
запис")
)).pack(side="left", padx=10)
refresh(tree, sec["table"], sec["columns"])
def delete_record(section, tree):
selected = tree.selection()[0]
item_id = tree.item(selected)["values"][0]
73
conn = sqlite3.connect(DB_NAME)
cursor = conn.cursor()
cursor.execute(f"DELETE FROM {section['table']} WHERE id=?", (item_id,))
conn.commit()
conn.close()
refresh(tree, section["table"], section["columns"])
root.mainloop()
# === ЗАПУСК ===
if __name__ == "__main__":
init_db()
launch_gui()
74
ДОДАТОК В
TMS-СИСТЕМА ОФІЦІЙНОГО ДИЛЕРА АВТОТРАНСПОРТНИХ
ЗАСОБІВ
ІНСТРУКЦІЯ КОРИСТУВАЧА
482. ЧДТУ. 52120-01 34 01
Листів 3
Розробник _____________ Сіваченко Є.В.
Черкаси – 2025
75
Інструкція користувачеві:
1. Запуск гри:
– Запустіть програму, подвійно натиснувши на файл tms_main.py або
запустіть його через командний рядок (наприклад, python
tms_main.py).
– Після запуску автоматично створиться база даних tms_dealer.db
2. Головне меню:
− Після запуску програми відкриється головне вікно з чотирма
вкладками:
a. Автомобілі: для обліку транспортних засобів.
b. Клієнти: для ведення бази клієнтів.
c. Доставлення: для управління доставками авто.
d. Сервіс: для фіксації сервісного обслуговування.
3. Робота з вкладками:
− Додати: додати новий запис.
− Редагувати: змінити вибраний запис.
− Видалити: видалити вибраний запис.
4. Особливості роботи з даними:
− Поля, позначені як обов'язкові (наприклад, VIN-код), не можуть бути
порожніми.
− При спробі додати дубльований VIN-код система видасть помилку.
− У вкладці "Доставлення" вказуйте ID автомобіля, який існує в
таблиці "Автомобілі".
− У вкладці "Сервіс" вказуйте ID автомобіля та ID клієнта, які вже є в
базі.
5. Резервне копіювання:
76
− Для резервного копіювання даних просто скопіюйте файл
tms_dealer.db у потрібне місце.
− Для відновлення даних замініть файл tms_dealer.db резервною
копією.
6. Закриття програми:
− Закрийте вікно програми, натиснувши на стандартну кнопку
закриття.
− Усі дані автоматично зберігаються під час роботи.
7. Поради:
− Для зручності використовуйте сортування даних у таблицях
(натисніть на заголовок стовпця).
− Уникайте одночасного редагування одних і тих самих даних з різних
пристроїв, оскільки програма працює з локальною базою даних.