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/9037| Title: | Програмне забезпечення системи керування замовленнями в закладі харчування |
| Authors: | Метелап, Володимир Володимирович Волосожар, Роман Васильович |
| Issue Date: | 20-Jun-2024 |
| Abstract: | АНОТАЦІЯ Виконавець: Волосожар Роман Васильович Назва роботи: "Програмне забезпечення системи керування замовленнями в закладі харчування". Спеціальність: 121 Інженерія програмного забезпечення. Навчальний заклад: «Черкаський державний технологічний університет» м. Черкаси, 2024р. Бакалаврська робота спрямована на створення web-додатку, який забезпечує ефективне управління замовленнями та покращення обслуговування в ресторанному бізнесі. Додаток розроблено з використанням сучасних технологій, зокрема бази даних PostgreSQL, фреймворка Express.js для створення серверної частини (бекенду), і бібліотеки React.js для клієнтської частини (фронтенду) з Material-UI для створення зручного та естетичного інтерфейсу. В результаті досліджень було сформовано вимоги, реалізовану систему та змодельвано структуру проекта. Було показано підвищення ефективності, покращене обслуговування клієнтів та гнучкість проекта. Задача виконана згідно поставленого завдання. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9037 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Волосожар Роман Васильович.pdf Restricted Access | 1.19 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«бакалавра»
освітній рівень
на тему: «Система керування замовленнями закладу харчування»
Виконав: студент 4 курсу, групи ПЗC-2244
Спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Волосожар Р.В.
(прізвище та ініціали)
Керівник Метелап В.В.
(прізвище та ініціали)
Рецензент
(прізвище та ініціали)
Черкаси 2024
АНОТАЦІЯ
Виконавець: Волосожар Роман Васильович
Назва роботи: "Програмне забезпечення системи керування
замовленнями в закладі харчування".
Спеціальність: 121 Інженерія програмного забезпечення.
Навчальний заклад: «Черкаський державний технологічний університет»
м. Черкаси, 2024р.
Бакалаврська робота спрямована на створення web-додатку, який
забезпечує ефективне управління замовленнями та покращення обслуговування
в ресторанному бізнесі. Додаток розроблено з використанням сучасних
технологій, зокрема бази даних PostgreSQL, фреймворка Express.js для
створення серверної частини (бекенду), і бібліотеки React.js для клієнтської
частини (фронтенду) з Material-UI для створення зручного та естетичного
інтерфейсу.
В результаті досліджень було сформовано вимоги, реалізовану систему та
змодельвано структуру проекта. Було показано підвищення ефективності,
покращене обслуговування клієнтів та гнучкість проекта.
Задача виконана згідно поставленого завдання.
4
Зміст
ВСТУП.........................................................................................................................6
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ...........................................................................8
1.1 Аналіз наукової та технічної інформації.............................................8
1.1.1 Огляд актуальних проблем..........................................................8
1.1.2 Аналіз методів та рішень.............................................................9
1.2 Аналіз існуючих аналогів...................................................................10
1.2.1 Порівняльний огляд програмного забезпечення.....................10
1.2.2 Ідентифікація прогалин та можливостей.................................11
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ.............................................................................13
2.1 Моделювання предметної області.....................................................13
2.1.1 Предметна область моделювання.............................................13
2.1.2 Елементи моделювання предметної області............................15
2.1.3 Робоча область моделювання....................................................16
2.2 Формування та аналіз вимог...............................................................18
2.2.1 Формування вимог до програмного забезпечення..................18
2.2.2 Формування вимог за допомогою діаграми прецедентів.......19
2.3 Проектування логічної структури програмного комплексу............20
2.3.1 Діаграма класів...........................................................................20
2.3.2 Діаграма пакетів.........................................................................22
2.4 Архітектурне проектування................................................................23
2.4.1 Діаграма компонентів................................................................23
2.4.2 Розгортання програмної системи на апаратних засобах.........24
2.5 Моделювання поведінки системи Ошибка! Закладка не определена.
2.5.1 Діаграма діяльності Ошибка! Закладка не определена.
2.5.2 Діаграма послідовності Ошибка! Закладка не определена.
2.5.3 Діаграма комунікації Ошибка! Закладка не определена.
2.5.4 Діаграма скінченного автомата Ошибка! Закладка не определена.
Висновок....................................................................................................................26
РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ....................................................................................................13
3.1 Розробка програмного комплексу Ошибка! Закладка не определена.
3.1.1 Обґрунтування вибору засобів реалізації Ошибка! Закладка не
определена.
3.1.3 Опис логічної схеми системи Ошибка! Закладка не определена.
3.1.4 Розробка бази даних Ошибка! Закладка не определена.
3.1.5 Розробка інтерфейсу користувача Ошибка! Закладка не
определена.
3.1.6 Опис розробки програмних компонентів Ошибка! Закладка не
определена.
3.2 Тестування системи Ошибка! Закладка не определена.
3.2.1 Модульне тестування Ошибка! Закладка не определена.
3.2.2 Інтеграційне тестування Ошибка! Закладка не определена.
3.2.3 Системне тестування Ошибка! Закладка не определена.
3.3 Приклади впровадженого програмного комплексу Ошибка! Закладка
не определена.
ВИСНОВКИ..............................................................................................................47
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ.............................................................48
ДОДАТКИ.................................................................................................................26
4
ВСТУП
Ресторанна справа є важливою складовою глобальної гастрономічної
культури та господарства. Розвиток ресторанної галузі тісно пов'язаний з
економічними, соціокультурними та технологічними тенденціями у всьому
світі. В контексті сучасного світу ресторанний бізнес є галуззю, що динамічно
та невпинно розвивається. Зростання глобалізації, швидке розширення
технологій та зміна у споживчих уподобаннях визначають нові тенденції у цій
сфері.
Актуальність теми: З погляду глобальних тенденцій, ресторанний бізнес
стає складовою частиною глобальної культури. Зростання міжнародного
туризму та мобільності населення призводять до взаємодії різних кулінарних
традицій та впровадження нових смакових вражень. Все це зумовило сферу
програмного забезпечення стати актуальному в полі бізнесів та сфери
обслуговування в цілому.
Мета: Розробка програмного забезпечення для автоматизації керування
замовленнями закладу харчування.
Предмет розробки: програмне забезпечення, здатне для керування
замовленнями, створення звітів та ведення обліку.
Методи проектування та конструювання: Node.js з бібліотекою Express
для розробки серверної частини, база даних PostgreSQL та фреймворк мовою
JavaScript – ReactJs для розробки інтерфейсу користувача.
Опис отриманих результатів: розроблене програмне забезпечення
успішно виконує функції керування замовленнями.
Практичне значення отриманих результатів: розроблена система
прискорює та спрощує роботу фронт-офісу та адміністрації закладу.
Особистий внесок автора: автором був здійснений аналіз сучасних
методів програмного забезпечення у сфері бізнесу та обслуговування та
розроблений власний варіант такого забезпечення.
Споживачі висувають високі вимоги до якості продуктів та
обслуговування. Зростання інтересу до здорового харчування, веганізму та
сталого розвитку підштовхує ресторани до змін у своєму меню та
управлінських практиках. З'являються нові тренди, такі як використання
місцевих та екзотичних інгредієнтів, а також впровадження нових методів
приготування їжі.
Окрім того, рост економіки та зростання середнього класу в різних
частинах світу веде до збільшення попиту на ресторанні послуги. Ресторани
стають не лише місцями для харчування, а й соціальними пунктами, де
проводяться зустрічі, заходи та корпоративні обіди.
Загалом, ресторанний бізнес постійно адаптується до змін у світовому
суспільстві, забезпечуючи якісне харчування та унікальний досвід для своїх
клієнтів, враховуючи при цьому нові технології та культурні тенденції.
Сучасна гастрономічна індустрія потребує ефективних рішень для
забезпечення високої якості обслуговування та задоволення потреб
сьогоденних клієнтів. Система ставить за мету відповісти на ці вимоги та
вдосконалити кожен аспект управління замовленнями в ресторані.
Ресторанна галузь, яка є ключовою складовою сучасного господарства,
піддавалася трансформації під впливом нових технологій та високих стандартів
обслуговування. У контексті швидкого розвитку гастрономічного сегменту,
система керування замовленнями стає необхідністю для ресторанів будь-якого
розміру. Вона об'єднує в собі кращі практики у сферах обліку продуктів,
персоналу, обробки замовлень та аналітики.
Система надає велику кількість переваг для ресторанів і власників
гастрономічних закладів. Вона забезпечує точний та швидкий прийом та
обробку замовлень, що сприяє підвищенню ефективності обслуговування та
задоволенню клієнтів.
Збір та аналіз даних про продажі, популярність страв, та зворотний
зв'язок гостей допомагає приймати обґрунтовані рішення щодо меню та
стратегії розвитку.
Необхідність створення: З урахуванням росту конкуренції в галузі
ресторанного бізнесу, управління замовленнями стає стратегічно важливою
компонентою успіху. Впровадження нашої системи гарантує конкурентні
4
переваги та покращення у всіх аспектах бізнесу, що забезпечує збільшення
задоволеності клієнтів та оптимізацію операцій. Проект націлений на
автоматизацію роботи фронт-офісу ( наприклад: офіціанти, адміністрація)
шляхом надання можливостей ведення звітності та зберігання і передачу
інформації про замовлення для спрощення організації роботи його виконавців.
5
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1 Аналіз наукової та технічної інформації
1.1.1 Огляд актуальних проблем
Однією з актуальних проблем у сфері ресторанного бізнесу та
використання додатків для замовлень і оплати є висока конкуренція. Завдяки
поширенню технологій і зростанню популярності онлайн-замовлень, багато
компаній вже працюють над розробкою власних додатків. Це ставить перед
новими проектами важливе завдання виділення серед інших та створення
унікальних функцій, які привернуть як клієнтів, так і ресторани.
Ще однією проблемою є безпека і конфіденційність даних. Персональна і
фінансова інформація клієнтів та ресторанів повинна бути належним чином
захищеною від можливих кібератак і порушень безпеки. Це особливо важливо,
оскільки додатки для замовлень і оплати працюють із чутливою інформацією.
Ще однією проблемою може бути недостатня інтеграція з іншими
системами. Ресторанні бізнеси часто використовують різні програми для
управління запасами, обліку та бухгалтерії. Якщо додаток не може ефективно
інтегруватися з іншими системами, це може призвести до проблем у веденні
бізнесу та обробці замовлень.
Також, важливо враховувати проблеми, пов'язані із забезпеченням якості
обслуговування та підтримки. Користувачі очікують, що додаток буде
ефективним, швидким і безперервно працюватиме. Проблеми, такі як низька
швидкість роботи, системні збої або недоліки в інтерфейсі, можуть призвести
до негативного досвіду користувачів і зменшення популярності додатка.
1.1.2 Аналіз методів та рішень
На сучасному ринку існує кілька методів та рішень для вирішення
проблем, що виникають у сфері ресторанного бізнесу та використання додатків
для замовлень і оплати. Один із методів - це інноваційний підхід до розробки
додатків, який включає в себе використання передових технологій. Це дозволяє
6
покращити функціональність додатків, забезпечити персоналізацію замовлень
та підвищити зручність використання.
Ще одним методом є акцент на забезпечення високого рівня безпеки та
конфіденційності даних. Розробники можуть використовувати сучасні методи
шифрування та захисту від кібератак, щоб гарантувати безпеку особистої
інформації користувачів і ресторанів. Це важливо для побудови довіри серед
користувачів і забезпечення успіху додатка в довгостроковій перспективі.
Щодо проблем обслуговування та підтримки, ефективність та якість
роботи додатка можна підтримувати за допомогою систем моніторингу та
вдосконалення якості коду. Впровадження методів тестування і регулярне
оновлення можуть забезпечити стабільну роботу додатка та запобігти
системним збоям.
У ході аналізу були досліджені різноманітні методи, фреймворки та
інструменти, використовувані для створення та управління інтернет-
магазинами електроніки. Зокрема, було розглянуто такі як для бекенд частини
Java Spring Boot, Node.js з фреймворком Express.js. А також для фронтенд
частини такі React.js, Vue.js, Angular.
1.2 Аналіз існуючих аналогів
1.2.1 Порівняльний огляд програмного забезпечення
На ринку існує багато програмного забезпечення, спрямованого на
автоматизацію процесів у ресторанному бізнесі та надання зручних
інструментів для замовлень, оплати та обліку. Розглянемо порівняльний огляд
декількох популярних програм:
TouchBistro:
Переваги:
1 Спеціалізована POS-система для ресторанів та кафе.
2 Зручний інтерфейс для замовлень та обслуговування.
3 Широкі можливості налаштувань для різних типів ресторанів.
7
Недоліки:
1 Обмежені можливості для ланцюгів ресторанів.
2 Можливі проблеми зі скасуванням або поверненням замовлень.
Square for Restaurants:
Переваги
o Інтегрована POS-система.
o Зручна система замовлень та оплати.
o Аналітика та звітність для власників бізнесу.
Недоліки:
o Може бути вартістю для невеликих бізнесів.
o Деякі функції можуть виявитися зайвими для менших ресторанів.
OpenTable:
Переваги:
1 Система бронювань та управління столиками.
2 Зручна для клієнтів і ресторанів.
3 Можливість отримання відгуків та оцінок.
Недоліки:
1 Більше спрямована на обслуговування, ніж на оплату.
2 Додаткова плата за кожне бронювання.
Можна зазначити, що кожен із розглянутих продуктів має свої переваги
та обмеження. Вибір оптимального рішення повинен бути здійснений з
урахуванням конкретних потреб бізнесу та його характеристик.
1.2.2 Ідентифікація прогалин та можливостей
Прогалини
Вартість встановлення та обслуговування
Можливість: Розробка більш ефективних стратегій ціноутворення,
враховуючи потреби різних класів ресторанів. Можливість надання пакетів з
послугами залежно від розміру бізнесу.
Обмежені можливості для невеликих бізнесів
Можливість: Створення спрощених версій програмного забезпечення
8
для менших ресторанів з меншим бюджетом та меншими потребами.
Спрямованість на конкретні аспекти бізнесу
Можливість: Інтеграція різних функціональностей в одному рішенні для
надання комплексного підходу до автоматизації всіх аспектів ресторанного
бізнесу.
Складність інтеграції
Можливість: Розробка стандартів інтеграції та сприяння розробникам у
створенні додатків, які легко інтегруються з існуючими системами.
Можливості:
1 Розробка зручних додатків для мобільних пристроїв для полегшення
замовлень, оплати та взаємодії з клієнтами.
2 Вдосконалення систем шифрування, двофакторної автентифікації та
моніторингу для захисту конфіденційності інформації.
3 Розробка систем, які легко налаштовуються та розширюються
відповідно до змін потреб ресторанного бізнесу.
Розпізнавання цих прогалин і можливостей дозволяє розробникам та
підприємцям активно працювати над вдосконаленням програмного
забезпечення для ресторанного сектору та забезпечити більш ефективну та
конкурентоздатну роботу бізнесу.
9
ВИСНОВОК ПЕРШОГО РОЗДІЛУ
У першому розділі був проведений аналіз програмного забезпечення
сфери обслуговування та були оглянуті та аналізовані прямі та непрямі аналоги
проекту. Отримана інформація була використана для формування вимог до
програмного забезпечення. Постановку задачі можна вважати закінченою та
початок розробки додатка схваленим.
10
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ СИСТЕМ
2.1 Моделювання предметної області
2.1.1 Предметна область моделювання.
Ресторанний бізнес та система автоматизації обслуговування клієнтів.
Включає в себе взаємодію ресторану, клієнтів та програмного забезпечення для
автоматизації обслуговування. На основі взаємодії замовлення, оплати та
бронювання формується цілісна система, яка дозволяє ефективно управляти
ресторанним бізнесом та забезпечує зручність як клієнтам, так і персоналу.
Словник предметної області:
1. Ресторан
Означення: Заклад громадського харчування, де надаються послуги
обслуговування страв та напоїв.
2. POS-система
Означення: Точка продажу, система для обробки замовлень та фіксації
оплати.
3. Замовлення
Означення: Вибір та фіксація клієнтом страв і напоїв для подальшого
обслуговування.
4. Бронювання
Означення: Заздалегідь організований запит на резервування столика в
ресторані.
5. Меню
Означення: Перелік доступних страв і напоїв у ресторані.
6. Клієнт
Означення: Особа, яка відвідує ресторан та користується його
послугами.
11
7. Система оплати
Означення: Механізм для проведення фінансових транзакцій за надані
послуги.
8. Позиція
Означення: Страва з меню ресторана, яку гість може замовити.
А зараз поглянемо на модель предметної області:
Модель предметної області
Модель включає в себе взаємодію ресторану, клієнтів та програмного
забезпечення для автоматизації обслуговування. На основі взаємодії
замовлення, оплати та бронювання формується цілісна система, яка дозволяє
ефективно управляти ресторанним бізнесом та забезпечує зручність як
клієнтам, так і персоналу. Розглянемо таблиці бази даних:
1. Таблиця "Страви":
Поля:
o ID (унікальний ідентифікатор)
o Назва
o Ціна
o Фото (шлях до зображення або посилання)
o Тип (наприклад, закуска, основна страва, напої)
2. Таблиця "Замовлення":
Поля:
o ID (унікальний ідентифікатор)
o Офіціант_ID (зв'язок із таблицею "Користувачі")
o Час_відкриття
o Закрито (логічне значення true/false)
o Тип_оплати (готівка/карта)
3. Таблиця "Замовлені страви":
Поля:
o ID (унікальний ідентифікатор)
o Страва_ID (зв'язок із таблицею "Страви")
o Кількість
12
o Замовлення_ID (зв'язок із таблицею "Замовлення")
4. Таблиця "Користувачі":
Поля:
o ID (унікальний ідентифікатор)
o Ім'я
o Пароль (зашифрований або хешований)
o Роль (наприклад, офіціант, адміністратор)
2.1.2 Елементи моделювання предметної області
Елементи, що допомагають описати структуру та взаємодію даних у
ресторанному бізнесі:
1 Таблиця "Страви":
`ID` (унікальний ідентифікатор)
`Назва`
`Ціна`
`Фото`
`Тип`
2 Таблиця "Замовлення":
`ID` (унікальний ідентифікатор)
`Офіціант_ID` (зв'язок із таблицею "Користувачі")
`Час_відкриття`
`Закрито` (логічне значення true/false)
`Тип_оплати`
3. Таблиця "Замовлені страви":
`ID` (унікальний ідентифікатор)
`Страва_ID` (зв'язок із таблицею "Страви")
`Кількість`
`Замовлення_ID` (зв'язок із таблицею "Замовлення")
4. Таблиця "Користувачі":
`ID` (унікальний ідентифікатор)
`Ім'я`
13
`Пароль`
`Роль`
Зв'язки між таблицями
Між таблицею "Замовлення" та "Користувачі" існує зв'язок через поле
`Офіціант_ID`. Цей зв'язок вказує на те, який офіціант обслуговує конкретне
замовлення.
Між таблицею "Замовлені страви" та "Страви" існує зв'язок через поле
`Страва_ID`. Цей зв'язок визначає, які саме страви були додані до конкретного
замовлення.
Між таблицею "Замовлені страви" та "Замовлення" існує зв'язок через поле
`Замовлення_ID`. Цей зв'язок вказує, до якого замовлення відносяться
конкретні страви.
Ці зв'язки дозволяють взаємодіяти з даними між різними таблицями та
виконувати складні запити, такі як отримання списку страв у замовленні або
інформації про офіціанта, що обслуговує певне замовлення. Така структура
даних дозволяє ефективно ведення обліку та аналіз ресторанного бізнесу.
2.1.3 Робоча область моделювання
Робоча область моделювання — це простір, де визначається, як система
буде функціонувати та як будуть взаємодіяти її елементи. Давайте розглянемо
основні елементи та їх функціональність в робочій області для ресторанного
бізнесу:
1 Інтерфейс користувача (UI):
- Опис: Включає в себе всі елементи, з якими користувач може
взаємодіяти, такі як додаток для клієнтів, панель керування для персоналу
ресторану та інші інтерфейси.
Функціональність:
Замовлення страв та напоїв.
Бронювання столиків.
Перегляд меню та акцій.
Оплата рахунку.
14
2 Система оплати:
Опис: Включає в себе механізми для проведення фінансових
транзакцій.
Функціональність:
Приймання оплати за допомогою різних методів (готівка, кредитні
картки, мобільні платежі).
Забезпечення безпеки фінансових операцій.
3 Система управління персоналом:
Опис: Інструмент для керування та взаємодії з персоналом
ресторану.
Функціональність:
Призначення завдань та розподіл обов'язків.
Відстеження працівників та графіків роботи.
Повідомлення та комунікація внутрішньої команди.
4 Система аналітики та звітності:
Опис: Включає в себе інструменти для аналізу даних та створення
звітів.
Функціональність:
Аналіз ефективності продажів та популярності страв.
Створення фінансових звітів та прогнозів.
Моніторинг та аналіз відгуків клієнтів.
2.2 Формування та аналіз вимог
2.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги.
Первинні вимоги
Вимоги замовника:
Зручний інтерфейс користувача: Програмне забезпечення повинно
мати інтуїтивний та зручний інтерфейс для клієнтів та персоналу
ресторану.
15
Швидкість обробки замовлень: Система повинна оперативно
обробляти замовлення та підтримувати швидкість обслуговування
клієнтів.
Надійність: ПЗ повинно працювати стабільно, без збоїв та
перебоїв, щоб уникнути втрати даних чи простою роботи.
Детальні вимоги
Вимоги замовника:
Мобільний додаток: Розробка зручного мобільного додатка для
клієнтів та персоналу з можливістю замовлення, бронювання та
оплати.
Інтеграція з POS: Взаємодія програмного забезпечення з POS-
системою для автоматичного оновлення замовлень та статусів
оплати.
Система аналітики: Включення інструментів аналізу даних для
вивчення відгуків клієнтів, аналізу продажів та інших показників.
1 Функціональні вимоги:
Модуль замовлень: Розробка функціональності для прийому та
обробки замовлень, включаючи внесення змін, видалення та
відстеження стану замовлень.
Система бронювань: Реалізація системи бронювань столиків з
можливістю перегляду доступних часів та вибору оптимального.
Інтеграція платіжних систем: Забезпечення безпечного та
ефективного процесу оплати, включаючи різні методи платежів.
2 Нефункціональні вимоги:
Безпека: Забезпечення захисту конфіденційної інформації,
включаючи дані клієнтів та фінансову інформацію.
Швидкодія: Оптимізація продуктивності системи для швидкого
відгуку та обробки великої кількості замовлень.
Масштабованість: Здатність системи ефективно працювати при
збільшенні обсягів обробки замовлень та збільшенні кількості
користувачів.
16
2.2.2 Формування вимог за допомогою діаграми прецедентів
У випадку програмного забезпечення для ресторану, прецеденти можуть
представляти дії та взаємодії, такі як замовлення їжі, оплата рахунку,
бронювання столиків і т. д.
Основні елементи діаграми
Актори:
1 Клієнт: Основний користувач системи, який може замовляти їжу,
оплачувати рахунок, бронювати столики та переглядати меню.
2 Офіціант: Персонал ресторану, який взаємодіє з системою для
прийняття замовлень, перевірки оплати та підготовки столиків.
3 Адміністратор: Особа, яка відповідає за аналіз замовлень та додавання
нових страв до меню.
Система Ресторану:
Включає в себе прецеденти, які представляють функціональні можливості
системи, такі як замовлення їжі, оплата рахунку, бронювання столика та
перегляд меню.
Взаємодії
Стрілки вказують на взаємодії між акторами та прецедентами. Наприклад,
клієнт може замовити їжу, оплатити рахунок, бронювати столики та
переглядати меню.
17
Рисунок 2.1 – Діаграма прецедентів
Ця діаграма надає візуальне представлення того, як різні користувачі
будуть використовувати систему ресторану та як вони будуть взаємодіяти з
різними її функціональностями.
2.3 Проектування логічної структури програмного комплексу
2.3.1 Діаграма класів
Діаграма класів визначає структуру системи, ілюструючи класи (або
об'єкти) та їхні взаємозв'язки.
1. Клас "Страва"
Містить атрибути ID, Назва, Ціна, Фото та Тип.
Взаємодіє з класом "ЗамовленіСтрави" у відношенні один до
багатьох, оскільки одне замовлення може містити багато страв, і
кожна страва може бути включена в багато замовлень.
2. Клас "Замовлення"
Включає атрибути, такі як ID, Офіціант_ID, Час_відкриття,
Закрито, Тип_оплати.
18
Має взаємодію з класом "ЗамовленіСтрави" у відношенні один до
багатьох, оскільки одне замовлення може містити багато
замовлених страв.
3. Клас "ЗамовленіСтрави"
Включає атрибути ID, Страва_ID, Кількість, Замовлення_ID.
Утворює відношення багато до одного з класами "Страва" та
"Замовлення", оскільки одна страва може бути включена в багато
замовлень, і кожне замовлення може містити багато замовлених
страв.
4. Клас "Користувач"
Містить атрибути ID, Ім'я, Пароль, Роль.
Має взаємодію з класом "Замовлення" у відношенні один до
одного, оскільки одне замовлення пов'язане з одним користувачем.
5. Відношення
Страва та Замовлення взаємодіють через клас "ЗамовленіСтрави",
що дозволяє визначити, які страви включені в кожне замовлення
та які замовлення містять конкретні страви.
Рисунок 2.2 – Діаграма класів
2.3.2 Діаграма пакетів
19
1. Пакет "Головний додаток":
Це головний пакет, який включає в себе всі інші пакети та модулі
додатку.
2. Пакет "Бекенд":
Включає модулі для обробки замовлень, авторизації користувачів
та створення звітності.
3. Пакет "База Даних":
Включає модулі для зберігання даних про замовлення,
користувачів та страв.
4. Пакет "Адміністративний Інтерфейс":
Включає модулі для управління замовленнями та налаштування
системи.
5. Зв'язки:
Модуль "Замовлення" взаємодіє з даними про замовлення в "Базі
Даних".
Модуль "Авторизація" взаємодіє з даними користувачів в "Базі
Даних".
Модуль "Звітність" отримує дані про замовлення з "Бази Даних".
Модуль "Управління Замовленнями" взаємодіє з даними про
замовлення та страви в "Базі Даних".
Модуль "Налаштування" взаємодіє з даними користувачів в "Базі
Даних".
20
Рисунок 2.3 – Діаграма паектів
2.4 Архітектурне проектування
2.4.1 Діаграма компонентів
1. Компонент "Клієнтський Інтерфейс":
Представляє інтерфейс, який взаємодіє з користувачем. Може бути
мобільним додатком чи web-інтерфейсом.
2. Компонент "Бекенд":
21
Організовує бізнес-логіку та обробку запитів від клієнтського
інтерфейсу.
Включає модулі для замовлень, авторизації, звітності та інші.
3. Компонент "База Даних":
Включає базу даних, де зберігаються дані про замовлення,
користувачів та інші потрібні дані.
4. Компонент "Зовнішні Сервіси":
Представляє зовнішні сервіси або API, з якими може взаємодіяти
бекенд (наприклад, платіжні системи чи сервіси для відправки
сповіщень).
5. Зв'язки:
Клієнтський інтерфейс взаємодіє з бекендом для обробки запитів
та отримання даних.
Бекенд взаємодіє з базою даних для отримання та зберігання
інформації.
Бекенд може взаємодіяти з зовнішніми сервісами для реалізації
деяких функціональностей.
Рисунок 2.4 – Діаграма компонентів
22
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Опис схеми розгортання
1. Хмара:
Представляє хмарне середовище, яке може включати в себе
Інтернет і всі необхідні ресурси.
2. Клієнтська Аплікація:
Містить Клієнтський Інтерфейс для взаємодії з користувачем.
3. Сервер:
Включає Web-Сервер для обробки запитів від клієнта.
Має компонент Бекенд для обробки бізнес-логіки та взаємодії з
базою даних.
4. Зовнішні Сервіси:
Представляє зовнішні сервіси, такі як платіжна система, з якою
може взаємодіяти бекенд.
5. Зв'язки:
Клієнт взаємодіє з Web-Сервером через Інтернет.
Web-Сервер передає запити Бекенду для обробки бізнес-логіки та
доступу до бази даних.
Бекенд може взаємодіяти з зовнішніми сервісами, такими як
платіжна система.
23
Рисунок 2.5 – Діаграма розгортання
2.5 Моделювання поведінки системи
2.5.1 Діаграма діяльності
Пояснення діаграми діяльності(рис. 2.6):
Опис діаграми діяльності:
1. Початок процесу
Офіціант ініціює процес входу в систему.
2. Введення пароля:
Офіціант вводить 4-значний пароль.
3. Перевірка пароля
Якщо пароль дійсний, відображається ім'я офіціанта, і він
переходить до головного меню.
24
Якщо пароль недійсний, відображається повідомлення про
помилку, і процес повертається до введення пароля.
4. Вибір дії
Офіціант вибирає дію в головному меню.
5. Створення замовлення
Якщо офіціант вибирає створення замовлення, він вводить номер
столу, додає позиції меню до замовлення та підтверджує
замовлення.
Замовлення створюється.
6. Управління замовленням
Якщо офіціант вибирає управління замовленням, він вибирає
замовлення для оновлення або видалення.
Рисунок 2.6 -Діаграма поведінки системи
25
2.5.2 Діаграма послідовності
Діаграма послідовності - тип діаграми який показує, взаємодію об’єктів між
собою певної послідовності. Відображає об'єкти та повідомлення, надіслані для
виконання процесів та функцій.
Компоненти діаграми: актори, повідомлення, об’єкти.
На діаграмі послідовності проекта (рис. 2.7) відображена послідовність дій
користувача при роботі з додатком.
Рисунок 2.7 – Діаграма послідовності
2.5.3 Діаграма комунікації
Діаграма комунікації (діаграма співпраці) — тип діаграми, що відображає
взаємодію об’єктів у вигляді зв'язків та повідомлень. Вона підкреслює
структуру об'єктів, які беруть участь у взаємодії.
На діаграмі комунікації(рис.2.8) проекта зображений процес комунікації між
модулями системи
26
Рисунок 2.8 – Діаграма комунікації
2.5.4 Діаграма скінченного автомату
Діаграма скінченного автомату (Finite State Machine Diagram) — діаграма,
з допомогою якої можливо відобразити можливі стани об'єкта або системи та
переходи між цими станами у відповідь на події.
На діаграмі скінченного автомату проекта(рис.2.9 – рис.2.10)
відображений процес створення замовлення офіціантом.
Рисунок 2.9 – Діаграма скінченного автомату(ч.1)
27
Рисунок 2.10 – Діаграма скінченного автомата(ч.2)
28
ВИСНОВОК ДРУГОГО РОЗДІЛУ
У другому розділі були проведені моделювання та архітектурне
проектування проекту з допомогою візуального відображення схемами та
діаграмами. Також, були сформовані вимоги до системи, спроектована база
даних та змодельована робота, як окремих модулів, так і усієї системи.
29
РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1 Розробка програмного комплексу
3.1.1 Обґрунтування вибору засобів реалізації
Для реалізації проекту були обрані такі засоби:
PostgreSQL - система керування базами даних, її перевагами є надійність,
підтримка багатьох стандартів та доступність.
ExpressJs – бібліотека JavaScript для створення серверної частини
проекту. Перевагами є доступність, простота у використанні та гнучкість.
ReactJs – фреймворк для створення інтерфейсної частини. Був обраний
для забезпечення реалізації можливості працювати на кількох сенсорних
пристроях з різном розміром екранів одночасно.
3.1.2 Опис структурної (функціональної) схеми
На рисунку 3.1 зображена створена структура функціональної схеми проекту:
Рисунок 3.1 – Структурна схема проекту
30
На схемі зображена структура системи керування замовленнями закладу
харчування.
Пояснення схеми:
Працівник може створити замовлення. Позиції замовлення друкуються на
кухні для кухарів з метою початку готування. Аналогічно позиції, які повинні
виконатися баром, друкуються для працівника бару на іншому пристрої. Сам
офіціант може виконати запит на роздрукування розрахункового чека (пречек).
Адміністративний персонал може виконати друк звіту для отримання звітності
роботи протягом зміни.
3.1.3 Опис логічної схеми системи
Рисунок 3.2 – Логічна схема системи
Усі користувачі починають з головного меню. Кожна з кнопок веде до
авторизації, яку необхідно пройти. Після проходження авторизації, користувач
отримує доступ до бажаного функціоналу, при наявності необхідної ролі для
деяких з них.
31
3.1.4 Розробка бази даних
Було розроблено базу даних, структура якої зображена на рис 3.1. Вона
складається з таких таблиць:
Employees – працівники закладу, які матимуть доступ до системи.
Таблиця призначена для реалізації авторизації в додаток та обмеження функцій
для осіб, які не мають достатньо наданих прав
Службові поля:
id – Первинний ключ таблиці.
role – обмеження для користувачів без необхідних прав
password – необхідне для авторизації користувача
Інформаційні поля:
name – Ім’я працівника, відображається на чеку та вказане в самому
рахунку.
Shifts – Службова таблиця, необхідна для відображення лише актуальних
замовлень.
Службові поля:
id - первинний ключ,
created_at – час початку зміни.
Зв’язки:
employeeId – зв’язок один-до-багатьох з таблицею employees.
Orders – Список активних замовлень.
Службові поля:
id – первинний ключ,
paymentType – тип оплати, необхідне для ведення звітності.
Зв’язки:
orderCreatorId – Для відображення імені працівника, що обслуговує
замовлення.
Інформаційні поля:
orderName – Назва замовлення, чи обслуговуваного стола
orderPrice – Загальна ціна замовлення. Робота система можлива без цього
поля, але поле створене для створення звітів.
32
MenuItems – таблиця зі списком страв, меню. Працівник обирає пункти зі
списку, щоб занести їх до замовлення
Службові поля:
Id – первинний ключ
Created_at – час створення запису
Is_category – чи буде пункт відображатися як страва, чи підменю, в якому
будуть знаходитися ще пункти.
menuItemCategory – категорія, до якої відходить пункт. Необхідне для
відображення пункту у відповідній категорії та для визначення, для кухні чи
для бару призначено замовлення
Інформаційні поля:
menuItemName – Назва позиції
menuItemPrice – Ціна позиції меню
OrderItems – таблиця страв, які входять до замовлень. Необхідна для
відображення пунктів кожного з замовлень.
Рисунок 3.2 – Розроблена структура бази даних
1 3.1.5 Розробка інтерфейсу користувача
Користувач починає з головного меню додатка:
33
Рисунок 3.3 – Головне меню.
З цього меню користувач має доступ до функціоналу проекта. Додаток
також призначений для менших екранів, але з меншим функціоналом. Тому,
при запуску на меншому екрані, кнопки з доступом до адміністративного
функціоналу приховані.
Рисунок 3.4 – Приклад відображення на меншому екрані.
При натисканні будь якої з клавіш відкриється вікно авторизації:
34
Рисунок 3.5 – Вікно авторизації
Для зручності роботи з сенсорним екраном було впроваджено цифрову
панель. При введені чотирьох символів, пароль автоматично перевіриться для
швидкості під час робочого процесу. Після чого відкривається нова сторінка від
імені власника пароля.
35
Рисунок 3.6 – Ескіз сторінки замовлень
На сторінці замовлень можна побачити всі дійсні (не оплачені)
замовлення. Якщо роль учасника, від імені якого запущено сторінку, не
адміністратор, то усі замовлення, окрім його власних, будуть приховані.
Інтерфейс після обирання існуючого, чи створення нового замовлення буде
ідентичний – список страв у замовленні в лівій частині екрану (список буде
порожнім, якщо замовлення тільки що створене), та список позицій меню в
правій частині. При натисканні на позицію, позиція в замовленні з такою ж
назвою добавляється.
2 3.1.6 Опис розробки програмних компонентів
Для реалізації проекту були створені такі компоненти:
Контроллери:
Таблиця Employees:
class EmployeesController {
// Вивести дані про всіх працівників
async getAllEmployees(req, res) {
try {
const employees = await EmployeesModel.getAllEmployees();
res.json(employees);
}
catch (error) {
console.error('Error fetching employees: ', error);
res.status(500).json({ error: 'Internal Server Error'});
}
}
// Вивести дані про працівника з даним паспортом
async getEmployeeByPassword(req, res){
36
try {
const employeePass = req.params.password;
const employee = await EmployeesModel.getEmployeeByPass(employeePass);
res.json(employee)
}
catch (error) {
console.error('Error fetching an employee: ', error);
res.status(500).json({ error: 'Server error'})
}
}
// Оновлення даних працівника
async updateEmployee(req, res){
try {
const employeeId = req.params.id;
const newData = req.body;
const updatedEmployee = await EmployeesModel.alterEmployee(employeeId, newData);
if (updatedEmployee) {
res.json ({ message : 'Employee updated succesfully', updatedEmployee});
} else {
res.status(404).json({ error: 'Employee not found'})
}
}
catch (error){
console.error('Error updating employee:', error);
res.status(500).json({ error: 'Internal Server Error' });
}
}
// Видалення даних про працівника
async deleteEmployee(req, res) {
try {
const employeeId = req.params.id;
const deletedEmployee = await EmployeesModel.deleteEmployeeById(employeeId);
if (deletedEmployee) {
res.json({ message: 'Employee deleted successfully', deletedEmployee });
} else {
res.status(404).json({ error: 'Employee not found' });
}
} catch (error) {
console.error('Error deleting employee:', error);
res.status(500).json({ error: 'Internal Server Error' });
}
}
}
Таблиця menuItems:
class menuItemsController {
//Вивести дані про всі позиції меню
async getAllMenuItems(req, res) {
try {
const menuItems = await menuItemsModel.getAllmenuItems();
res.json(menuItems);
37
}
catch (error) {
console.error('Error fetching menuItems: ', error);
res.status(500).json({ error: 'Internal Server Error'});
}
}
//Вивести дані про пункт меню за його первинним ключем
async getMenuItemById(req, res){
try {
const menuItem = await menuItemsModel.getmenuItemByID();
if (menuItem)
res.json(menuItem);
else
res.status(404).json({ error: 'menuItem not found'});
}
catch (error) {
console.error('Error fetching a menuItem: ', error);
res.status(500).json({ error: 'Server error'})
}
}
// Оновлення даних про позицію меню
async updateMenuItem(req, res){
try {
const menuItemId = req.params.id;
const newData = req.body;
const updatedmenuItem = await menuItemsModel.altermenuItem(menuItemId, newData);
if (updatedmenuItem) {
res.json ({ message : 'menuItem updated succesfully', updatedmenuItem});
} else {
res.status(404).json({ error: 'menuItem not found'})
}
}
catch (error){
console.error('Error updating menuItem:', error);
res.status(500).json({ error: 'Internal Server Error' });
}
}
//Видалення даних про позицію меню
async deleteMenuItem(req, res) {
try {
const menuItemId = req.params.id;
const deletedmenuItem = await menuItemsModel.deletemenuItemById(menuItemId);
if (deletedmenuItem) {
res.json({ message: 'menuItem deleted successfully', deletedmenuItem });
} else {
res.status(404).json({ error: 'menuItem not found' });
}
} catch (error) {
console.error('Error deleting menuItem:', error);
38
res.status(500).json({ error: 'Internal Server Error' });
}
}
}
Таблиця orderItems:
class orderItemsController {
//Вивести всі дані про пункти усіх замовлень
async getAllOrderItems(req, res) {
try {
const orderItems = await orderItemsModel.getAllOrderItems();
res.json(orderItems);
}
catch (error) {
console.error('Error fetching orderItems: ', error);
res.status(500).json({ error: 'Internal Server Error'});
}
}
//Вивести дані пунктів, які належать даному замовленю
async getOrderItemById(req, res){
try {
const orderItemId = req.params.orderItemId
const orderItem = await orderItemsModel.getOrderItemById(orderItemId);
res.json(orderItem)
}
catch (error) {
console.error('Error fetching a orderItem: ', error);
res.status(500).json({ error: 'Server error'});
}
}
//Створити пункт замовлення
async createOrderItem(req, res){
try {
const data = req.body;
const createdOrderItem = await orderItemsModel.createOrderItem(data);
res.json(createdOrderItem)
}
catch(error) {
console.error('Error creating order item:', error);
res.status(500).json({ error: 'Server error'});
}
}
//Оновити дані про пункт замовлення
async updateOrderItem(req, res){
try {
const orderItemId = req.params.id;
const newData = req.body;
39
const updatedorderItem = await orderItemsModel.alterOrderItem(orderItemId,
newData);
if (updatedorderItem) {
res.json ({ message : 'orderItem updated succesfully', updatedorderItem});
} else {
res.status(404).json({ error: 'orderItem not found'})
}
}
catch (error){
console.error('Error updating orderItem:', error);
res.status(500).json({ error: 'Internal Server Error' });
}
}
//Видалити пункт замовлення
async deleteOrderItem(req, res) {
try {
const orderItemId = req.params.id;
const deletedorderItem = await orderItemsModel.deleteorderItemById(orderItemId);
if (deletedorderItem) {
res.json({ message: 'orderItem deleted successfully', deletedorderItem });
} else {
res.status(404).json({ error: 'orderItem not found' });
}
} catch (error) {
console.error('Error deleting orderItem:', error);
res.status(500).json({ error: 'Internal Server Error' });
}
}
}
Таблиця Orders:
//Вивести дані про всі замовлення
async getAllOrders(res) {
try {
const orders = await ordersModel.getAllOrders();
res.json(orders);
}
catch (error) {
console.error('Error fetching orders: ', error);
res.status(500).json({ error: 'Internal Server Error'});
}
}
//Вивести дані про одне замовлення за ідентифікатором
async getOrderById(req, res){
try {
const orderId = req.params.orderId
const order = await ordersModel.getOrderByID(orderId);
if (order)
res.json(order);
40
else
res.status(404).json({ error: 'order not found'})
}
catch (error) {
console.error('Error fetching an order: ', error);
res.status(500).json({ error: 'Server error'});
}
}
//Створити замовлення
async createOrder(req, res){
try {
const data = req.body;
const createdOrder = await ordersModel.createOrder(data);
res.json(createdOrder)
}
catch(error) {
console.error('Error creating order:', error);
res.status(500).json({ error: 'Server error'});
}
}
//Оновити дані про замовлення
async updateOrder(req, res){
try {
const orderId = req.params.id;
const newData = req.body;
const updatedOrder = await ordersModel.alterOrder(orderId, newData);
if (updatedOrder) {
res.json ({ message : 'order updated succesfully', updatedOrder});
} else {
res.status(404).json({ error: 'order not found'})
}
}
catch (error){
console.error('Error updating order:', error);
res.status(500).json({ error: 'Internal Server Error' });
}
}
//Видалити замовлення
async deleteOrder(req, res) {
try {
const OrderId = req.params.id;
const deletedOrder = await ordersModel.deleteOrderById(OrdersId);
if (deletedOrders) {
res.json({ message: 'Order deleted successfully', deletedOrder });
} else {
res.status(404).json({ error: 'Order not found' });
}
} catch (error) {
console.error('Error deleting an order:', error);
41
res.status(500).json({ error: 'Internal Server Error' });
}
}
Модулі – ці компоненти використовуються для визначення полів таблиць
в серверній частині та використовуються контролерами, описаними вище
Таблиця Employees:
class EmployeesModel {
async getAllEmployees() {
const request = 'SELECT * FROM employees';
const { rows } = await pool.query(request);
return rows;
}
async getEmployeeByPass(password) {
const request = 'SELECT * from employees where $1 = password'
const { rows } = await pool.query(request, [password]);
return rows;
}
async createEmployee(role, name, password){
const request = 'INSERT INTO employees (role, name, password) values ($1, $2,
$3)';
const {rows} = await pool.query(request, [role, name, password]);
return rows[0];
}
async alterEmployee(id, role, name, password){
const request = 'update employees set role = $2, name = $3, password = $4 where
id = $1';
const { rows } = await pool.query(request, [id, role, name, password])
return rows[0];
}
async deleteEmployee(id){
const request = 'delete from employees where id = $1 returning *';
const { rows } = await pool.query(request, [id]);
return rows[0];
}
}
Таблиця menuItems:
class menuItemsModel {
async getAllMenuItems() {
const request = "Select * from menuItems";
const { rows } = await pool.query(request);
return rows;
}
42
async getMenuItemById(menuItemId){
const request = "Select * from menuItems where id = $1";
const { rows } = await pool.query(request, [menuItemId]);
return rows[0];
}
async createMenuItem(menuItemName, is_category, menuItemCategory, menuItemPrice,
menuItemPhoto, isMenuItemActive){
const request = "Insert into menuItems (name, is_category, category, price,
photo, is_active) values ($1, $2, $3, $4, $5, $6)";
const { rows } = await pool.query(request, [menuItemName, is_category,
menuItemCategory, menuItemPrice, menuItemPhoto, isMenuItemActive]);
return rows[0];
}
async deleteMenuItem(menuItemId){
const request = "delete from menuItemId where id = $1 returning *";
const { rows } = await pool.query(request, [menuItemId])
return rows[0];
}
async alterMenuItem(menuItemId, menuItemName, is_category, menuItemCategory,
menuItemPrice, menuItemPhoto, isMenuItemActive){
const request = "update menuItems set name = $2, is_category = $3, category = $4,
price = $5, photo = $6, is_active = $7, where id = $1";
const { rows } = await pool.query(request, [menuItemId, menuItemName,
is_category, menuItemCategory, menuItemPrice, menuItemPhoto, isMenuItemActive])
return rows[0];
}
}
Таблиця orderItems:
class OrderItemsModel {
async getAllOrderItems() {
const request = 'SELECT * FROM orderItems';
const { rows } = await pool.query(request);
return rows;
}
async getOrderItemById(orderItemId) {
const request = 'SELECT * from OrderItems where $1 = id'
const { rows } = await pool.query(request, [orderItemId]);
return rows;
}
async createOrderItem(menuItemId, itemAmount, orderId){
const request = 'INSERT INTO OrderItems (menu_item_id, amount, order_id) values
($1, $2, $3)';
const {rows} = await pool.query(request, [menuItemId, itemAmount, orderId]);
return rows[0];
}
43
async alterOrderItem(id, menuItemId, itemAmount, orderId){
const request = 'update OrderItems set menu_item_id = $2, amount = $3, order_id =
$4 where id = $1';
const { rows } = await pool.query(request, [id, menuItemId, itemAmount, orderId])
return rows[0];
}
async deleteOrderItem(id){
const request = 'delete from OrderItems where id = $1 returning *';
const { rows } = await pool.query(request, [id]);
return rows[0];
}
}
Таблиця orders:
const pool = require('../config/db');
class ordersModel {
async getAllOrders() {
const request = 'SELECT * FROM orders';
const { rows } = await pool.query(request);
return rows;
}
async getOrderBydId(orderItemId) {
const request = 'SELECT * from orders where $1 = id'
const { rows } = await pool.query(request, [orderItemId]);
return rows;
}
async createOrder(orderName, orderCreatorId, orderPaymentType, orderPrice){
const request = 'INSERT INTO orders (name, employee_id, payment_type, price)
values ($1, $2, $3, $4)';
const {rows} = await pool.query(request, [orderName, orderCreatorId,
orderPaymentType, orderPrice]);
return rows[0];
}
async alterOrder(orderId, orderName, orderCreatorId, orderPaymentType,
orderPrice){
const request = 'update orders set name = $2, employee_id = $3, payment_type =
$4, price = $5 where id = $1';
const { rows } = await pool.query(request, [orderId, orderName, orderCreatorId,
orderPaymentType, orderPrice])
return rows[0];
}
async deleteOrder(orderId){
const request = 'delete from orders where id = $1 returning *';
const { rows } = await pool.query(request, [orderId]);
44
return rows[0];
}
}
module.exports = new ordersModel();
Таблиця shifts:
const pool = require('../config/db');
class ordersModel {
async getAllOrders() {
const request = 'SELECT * FROM orders';
const { rows } = await pool.query(request);
return rows;
}
async getOrderBydId(orderItemId) {
const request = 'SELECT * from orders where $1 = id'
const { rows } = await pool.query(request, [orderItemId]);
return rows;
}
async createOrder(orderName, orderCreatorId, orderPaymentType, orderPrice){
const request = 'INSERT INTO orders (name, employee_id, payment_type, price)
values ($1, $2, $3, $4)';
const {rows} = await pool.query(request, [orderName, orderCreatorId,
orderPaymentType, orderPrice]);
return rows[0];
}
async alterOrder(orderId, orderName, orderCreatorId, orderPaymentType,
orderPrice){
const request = 'update orders set name = $2, employee_id = $3, payment_type =
$4, price = $5 where id = $1';
const { rows } = await pool.query(request, [orderId, orderName, orderCreatorId,
orderPaymentType, orderPrice])
return rows[0];
}
async deleteOrder(orderId){
const request = 'delete from orders where id = $1 returning *';
const { rows } = await pool.query(request, [orderId]);
return rows[0];
}
}
module.exports = new ordersModel();
React-компонент MainMenuButtons – використано при розробці
45
інтерфейса для відображення кнопок головного меню
import React from 'react';
import Button from '@mui/material/Button';
import '../styles/mainMenuButton.css';
import EditIcon from '@mui/icons-material/EditNote';
function NavigationButton({ label, icon, onClick, buttonColor, hideOnSmallScreen})
{
function isSmallScreen() {
return window.innerWidth <= 768;}
if (hideOnSmallScreen && isSmallScreen())
return null;
else
return (
<Button
className={`navigationButton ${isSmallScreen() ? 'smallScreenButton' :''}`}
onClick = {onClick}
style={{ backgroundColor: buttonColor }}
variant="contained">
{icon && React.createElement(icon, { className: 'icon' })}
<span className='label'> {label} </span>
</Button>
);
}
function AdminPanelButton({ onClick, hideOnSmallScreen }) {
const isSmallScreen = window.innerWidth <= 768;
function isTouchDevice() {
return (('ontouchstart' in window) || (navigator.maxTouchPoints > 0) ||
(navigator.msMaxTouchPoints > 0));
}
if (hideOnSmallScreen && isSmallScreen)
return null;
else
return (
<Button
className={`adminPanelButton ${isTouchDevice() ? 'unclickable' :''}`}
onClick={onClick}
variant="contained"
size='small'
>
<EditIcon />
</Button>
);
}
export {NavigationButton, AdminPanelButton};
46
3.2 Тестування системи
3 3.2.1 Модульне тестування
Модульне тестування являє собою тестування окремих складових
системи та забезпечує перевірку окремих частин коду на правильність роботи.
Інтерфейс
Для тестування фронтової частини будемо використовувати фреймворк
Jest.
Послідовність виконаної роботи:
Установка
1. Встановлюємо необхідні залежності для Jest та React Testing Library.
2. Додаємо конфігурацію Jest у наш package.json для налаштування
середовища тестування.
Створення тестів
1. Створюємо файли з тестами. Файли тестів повинні мати відповідні
назви, наприклад, ComponentName.test.js.
2. Використовуємо React Testing Library для рендерингу компонентів у
тестах та взаємодії з ними. Використовуємо Jest для перевірки очікуваних
результатів.
Серверна частина
Використовуємо Jest, а також Postman для перевірки роботи HTTP-
запитів
Таблиця 3.1
Тести, виконані під час модульного тестування
Модуль Назва тесту Результат
Інтерфейс Рендеринг компонентів Рендеринг компонентів
виконується успішно
47
Авторизація Тестування форми Виявлено помилку в
авторизації автоматичній перевірці
пароля
Керування Перевірка створення та Замовлення створюються
замовленнями оновлення замовлень успішно
База даних Перевірка таблиць та База даних працює
зв’язків бази даних відповідно до вимог
Модульне тестування є необхідною частиною кожного проекту у зв'язку з
його підвищеною надійністю та підтримкою коду проекту в гарному стані.
4 3.2.2 Інтеграційне тестування
Інтеграційне тестування є критично важливим етапом перевірки, що
забезпечує правильну взаємодію між різними компонентами системи. Для
нашого проекту з серверною частиною, інтеграційне тестування забезпечує
перевірку як внутрішньої взаємодії компонентів, так і їх взаємодії з іншими
частинами системи, такими як база даних.
Метою такою тестування є:
1. Перевірка взаємодії між компонентами та модулями
2. Виявлення дефектів у взаємодії модулів
3. Забезпечення цілісності системи
Проведені тести:
Таблиця 3.2
Тести, виконані під час інтеграційного тестування
Назва тесту Опис Результат
Взаємодія компонентів Перевірка взаємодії між Успішно
інтерфейсу компонентами React
Взаємодія інтерфейсу і Перевірка запитів до Успішно
серверної частини сервера та відповіді до
фронтенду
Взаємодія сервера й Перевірка коректності Успішно
бази даних збереження, оновлення
й видалення даних
Виконуючи ретельне інтеграційне тестування, ми можемо забезпечити
коректну взаємодію всіх компонентів нашої системи та виявити помилки, які
можуть виникнути при їх інтеграції.
3.2.3 Системне тестування
Системне тестування є одним із завершальних етапом тестування проекта
48
перед його експлуатацією. Під час такого тестування перевіряється вся система
повністю, тобто усіх інтегрованих модулів разом.
Метою такого тестування є перевірка відповідності системо до
специфікацій, виявлення дефектів, які могли бути не поміченими до цього
етапу та забезпечення готовності до релізу.
Проведемо тестування:
Таблиця 3.3
Тести, виконані під час системного тестування
Назва тесту Опис Результат
Функціональність Виконання всіх бізнес- Успішно
процесів та юзер-кейсів
Продуктивність Перевірка системи на Система витримує
стійкість до навантажень очікувані навантаження
Інтерфейс Перевірка зручності та Успішно
інтуітивності інтерфейса
Тестування документації Оцінка якості технічної Успішно
документації
Таке тестування допомагає забезпечити надійність та якість кінцевого
продукту та є важливою для кожного проекта.
5 3.2.4 Приймальне тестування
Фінальний етап тестування – приймальне тестування. Під час такого
тестування, перевірка відбувається кінцевими користувачами та клієнтами для
певності в тому, що проект відповідає їх вимогам і готовності до реалізації.
Метою є отримання схвалення від клієнтів та безпосередня реалізація проекту.
6 3.2.5 Приклади впровадженого програмного комплексу
Сценарій експлуатації додатку залежить від посади працівника, який наразі ним
користується, в цьому підрозділі буде описаний приклад впровадження для
Офіціанта та Адміністратора.
49
Офіціант
Користувач посади «Офіціант» використовує додаток для керування та
виконання замовлень. Для прикладу допустимо, що користувач уже взяв
замовлення яке с кладається з пунктів: борщ та вода Моршинська.
Рисунок 3.2.1 – Головне меню
Для виконання замовлення користувач обирає в головному меню «Замовлення»
Після чого вводить свій код у відкритому вікні авторизації
Рисунок 3.2.2 – Вікно авторизації користувача
Якщо код правильний, відкривається сторінка з замовленнями від його
імені.
Офіцант побачить усі замовлення створені ним:
50
Рисунок 3.2.3 – Замовлення, створені поточним користувачем
Для створення нового замовлення, потрібно натиснути «+». Після натискання,
необхідно підписати наше замовлення, зазвичай, номером стола.
Рисунок 3.2.3 – Запис підпису замовлення
Після того як замовлення створене, користувача перенесе до вікна з пунктами
меню.
Рисунок 3.2.4 – Навігаційне меню
Почнемо з напою. Навігуємося по меню: Бар – Безалкогольні напої –
Мінеральна вода «Моршинська» 0.5
51
Рисунок 3.2.5 – Позиції в категорії «Безалкогольні напої»
Після натискання на позицію. Вона з’явиться в нашому замовлені
Рисунок 3.2.6 – Замовлення з тільки що добавленим пунктом.
Повертаємося назад за допомогою навігаційного меню та переходимо до
категорії «Кухня»
52
Рисунок 3.2.7 – Позиції в категорії «Кухня»
Переходимо в категорію «Перші страви» та натискаємо «Борщ».
Рисунок 3.2.8 – Замовлення з усіма потрібними нам позиціями.
Натискаємо кнопку «Закрити» та підтверджуємо збереження.
Після цієї дії кухня отримає роздруківку з позицією «Борщ» , та будь які інші
пункти з категорії «Кухня». В свою чергу бар отримає роздруківку
«Моршинська» та зможе видати товар. Надалі працівник очікує на виконання
замовлення та доставляє його на відповідний цьому замовленню стіл.
53
ВИСНОВОК ТРЕТЬОГО РОЗДІЛУ
У останньому розділі було розглянуто та досліджено процес
безпосередньої розробки системи, а саме:
1 Обґрунтування вибору засобів розробки
2 Розробка бази даних та серверної частини
3 Розробка структурної та логічної схем проекту
4 Розробка користувацького інтерфейсу
Також, готовий продукт було було успішно протестовано засобами
модульного, інтеграційного та системного тестування. Тестування
пройшло успішно,а знайдені недоліки виправлені.
54
ВИСНОВКИ
В ході аналізу та проектування системи для ресторанного додатку було
враховано різноманітні аспекти, починаючи від клієнтського інтерфейсу та
закінчуючи архітектурою серверної частини. З урахуванням вимог та
функціональності додатку були визначені ключові компоненти, такі як
замовлення, авторизація, звітність та адміністративний інтерфейс.
Моделювання включало аналіз предметної області, створення сутностей
та зв'язків, розробку діаграм прецедентів та класів, а також визначення вимог
до програмного забезпечення. Важливим етапом було створення схем бази
даних для зберігання інформації про користувачів, замовлення, страви та інше.
Діаграма компонентів та пакетів дозволили визначити структуру
фронтенду та бекенду системи, розкриваючи їхню взаємодію та залежності.
Схема розгортання продемонструвала, як компоненти системи взаємодіють у
реальному середовищі, враховуючи хмарні та локальні ресурси.
У результаті виконання всіх цих кроків була створена концептуальна
модель ресторанного додатку, яка може слугувати основою для подальшої
розробки та впровадження.
Проект був присвячений розробці web-додатку для ресторану, який
допоможе автоматизувати та спростити процес прийняття замовлень та
управління ними. Розглянувши всі аспекти розробки, від створення бази даних
до тестування готової системи, ми досягли розроби бази даних, яка складається
з 5 таблиць, зі зв’язками між ними, засобами PostgreSQL. Було розроблено
серверну частину та робочий інтерфейс.
Етапи проекту були успішно виконані, включно з проведенням
тестування, що забезпечить можливість для подальшого впровадження системи
та її розвитку.
55
ЧДТУ 24 2251.012
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Методи проектування [Електронний ресурс]. – Точка доступу:
https://cpsm.kpi.ua/Doc/konsp_suchasni_metodi.pdf [1]
2 СУБД [Електронний ресурс]. – Точка доступу: URL:
https://www.miyklas.com.ua/p/informatica/9-klas/bazi-danikh-sistemi-keruvannia-
bazami-danikh-361840/sistemi-keruvannia-bazami-danikh-352450/re-b0f14256-7ac2-
4823-9f53-656061b85eaa [2]
3 Інтерфейс користувача [Електронний ресурс]. – Точка доступу: URL:
https://stfalcon.com/uk/blog/post/user-interface-web-design-principles [3]
4 Моделювання предметної області [Електронний ресурс]. – Точка
доступу: URL: https://dou.ua/forums/topic/42366/ [4]
5 Формування та аналіз вимог [Електронний ресурс]. – Точка доступу:
URL:
http://dspace.wunu.edu.ua/retrieve/14135/FCIT_kKN_sPZS_dAVPZ_%20LEC.pdf [5]
6 Ruby [Електронний ресурс]. – Точка доступу: URL:
https://lemon.school/blog/navishho-potribna-mova-programuvannya-ruby [6]
7 Технічне завдання[Електронний ресурс]. – Точка доступу: URL:
https://seo-name.com/ua/info/faq/chto-takoe-tz-i-kak-pravilno-sostavlyaetsya.html [7]
8 UML-діаграми [Електронний ресурс]. – Точка доступу: URL:
https://dou.ua/forums/topic/40575/ [8]
9 Діагарми класів [Електронний ресурс]. – Точка доступу: URL:
https://www.mindonmap.com/uk/blog/what-is-uml-class-diagram/ [9]
10 Діаграма пакетів [Електронний ресурс]. – Точка доступу: URL:
www.wikiwand.com/uk/Діаграма_пакетів [10]
11 VS code [Електронний ресурс]. – Точка доступу: URL:
https://uk.wikipedia.org/wiki/Visual_Studio_Code [11]
12 Understanding the Model-View-Controller (MVC) Architecture in Rails
[Електронний ресурс]. – Точка доступу: URL: https://www.sitepoint.com/model-
viewcontroller-mvc-architecture-rails/ [12]
5
ЧДТУ 24 2251.012
13 Postgresql [Електронний ресурс]. – Точка доступу: URL:
https://foxminded.ua/postgresql-shcho-tse/ [13]
14 Опис структурної схеми та функціональної схеми [Електронний
ресурс]. – Точка доступу: URL: https://studfile.net/preview/9277451/page:3/ [14]
15 Опис логічної схеми системи [Електронний ресурс]. – Точка доступу:
URL: https://ela.kpi.ua/server/api/core/bitstreams/9521e5f9-421a-4874-a17d-
f0853f942856/content [15]
16 Модульне тесування [Електронний ресурс]. – Точка доступу: URL:
https://www.zaptest.com/uk/ [16]
17 Rspec [Електронний ресурс]. – Точка доступу: URL: https://rspec.info/
[17]
18 Інтеграційне тестування [Електронний ресурс]. – Точка доступу: URL:
https://qalight.ua/baza-znaniy/integratsijne-testuvannya/ [18]
19 Системне тестування [Електронний ресурс]. – Точка доступу: URL:
http://surl.li/ywfnzx [19]
6