Репозиторій ЧДТУ

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
Пояснювальна записка 
до кваліфікаційної випускної бакалаврської роботи 
з напрямку підготовки 121 ―Інженерія програмного забезпечення‖ 
(освітньо-кваліфікаційний рівень) 
на тему: «Автоматизована інтерактивна система збору та обробки 
інформації про різні ситуації в місті для покращення роботи служб 
міста Черкаси. Система мікросервісів» 
Виконав: студент 4 курсу, групи ПЗС-1944 
Напряму підготовки  
121 ―Інженерія програмного забезпечення‖   
(шифр і назва напряму підготовки) 
Студент               Білозор Д.О. . 
(прізвище та ініціали) 
Керівник Метелап В.В.     . 
(прізвище та ініціали) 
Рецензент           Захарова М.В.     . 
(прізвище та ініціали) 
Черкаси, 2022 
ЗМІСТ 
Вступ ............................................................................................................................................... 4 
1 ПОСТАНОВКА ЗАДАЧІ ........................................................................................................... 5 
1.1 Актуальність та аналіз предметної області ...................................................................... 5 
1.2 Обгрунтовання вибору технологій розробки ................................................................... 5 
1.3 Моделювання предметної області ..................................................................................... 7 
1.4 Формування ТЗ технічного завнання ................................................................................ 8 
1.4.1 Опис технічних вимог ................................................................................................. 8 
1.4.2 Огляд продукту з точки зору різних типів користувачів ........................................ 9 
1.4.3 Особливості дизайну. .................................................................................................. 9 
2 ПРОЕКТУВАННЯ СИСТЕМИ ............................................................................................... 11 
2.1 План реалізації проекту .................................................................................................... 11 
2.2 Опис головних сутностей ................................................................................................. 13 
2.3 Проектування програмних модулів ................................................................................ 14 
2.4 Проектування дії системи з точки зору різних типів користувачів ............................. 14 
2.5 Проектування інтерфейсу користувача .......................................................................... 17 
2.6 Проектування бази даних ................................................................................................. 21 
2.7 Проектування архітектури ............................................................................................... 24 
2.8 Алгоритм роботи фактичної системи ............................................................................. 26 
3 РОЗРОБКА ТА ТЕСТУВАННЯ СИСТЕМИ ......................................................................... 30 
3.1 Файлова структура проекту ............................................................................................. 30 
3.2 Розробка бази даних ......................................................................................................... 31 
3.3 Опис чат-боту .................................................................................................................... 35 
4 ВИСНОВКИ .............................................................................................................................. 38 
5 СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ .......................................................................... 39 
ЧДТУ 221959.002 
Зм. Лист №документа Підпис Дата 
Розроб. Білозор Д.О. Літ. Лист Листів 
Автоматизована інтерактивна система 
Перев. Метелап В.В. 
збору та обробки інформації про різні Н 3 
ситуації в місті для покращення роботи ФІТІС 
Н.контр. Півень О. Б. служб міста Черкаси. Система 
Первунінський С. М. мікросервісів кафедра ПЗАС, ПЗС-1944 
Затв. 
ПЕРЕЛІК СКОРОЧЕНЬ ТА ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ 
Назва Пояснення 
ТЗ Технічне завдання 
БД База даних 
Front-end Клієнтська частина проекту, яка відображається у браузері 
Серверна частина проекту, яка взаємодіє із даним БД та чат ботом 
Back-end 
Паттерн Набір правил та ресурсів для структуризації розробки 
Ментор Авторизований користувач 
UML Unified Modeling Language 
HTTP Hyper Text Transfer Protocol 
iOS iPhone operating system 
API Application Programming Interface 
UI Інтерфейс користувача 
ВСТУП 
Система збору даних - при обчисленні та аналізі сигналів, перший етап 
обробки даних, який полягає в накопиченні та підготовці даних для 
подальшої обробки та інтерпретації. Як правило, система збору даних 
перетворює сигнали від багатьох датчиків у цифровий код і передає їх на 
мікрокомп’ютер через систему зв’язку.  
Благоустрій населених пунктів - комплекс робіт з інженерного захисту, 
розчищення, осушення та благоустрою, а також соціально-економічних, 
організаційно-правових та природоохоронних заходів щодо покращення 
мікроклімату, санітарії, зниження шуму тощо, які проводяться в с. села до 
його раціонального використання, належного утримання та охорони, 
створення умов для охорони та відновлення сприятливого для життя людини 
середовища. Проект CheClean – це сервіс благоустрою в місті Черкаси, який 
складається з чат-бота в телеграмі, бази даних та веб-сайту, що виконує 
функцію панелі адміністрування. Основна мета сервісу – забезпечити швидку 
та зручну взаємодію із ЗМІ та іншими адміністративними установами для 
вирішення проблеми. Ідея створення такого сервісу народилася через 
відсутність прямого зв’язку з міською адміністрацією. Щоб зв’язатися з 
представниками інспекції міськради в Черкасах, надішліть їм листа у 
Facebook або Instagram. Такий підхід не дуже зручний та ефективний, тому 
для полегшення цієї взаємодії було поставлено завдання створити такий 
сервіс. 
  
 
1 ПОСТАНОВКА ЗАДАЧІ 
1.1 Актуальність та аналіз предметної області 
Після проведення експертизи предметної області ми виявили, що 
аналоги нашому сервісу все ж існують, але ніхто ними не користується.   
Провівши аналіз, ми прийшли до висновку, що людям не зручно 
користуватись додатками з перенавантаженим UI. Тому ми провели декілька 
інтерв’ю з людьми, на предмет вияву недоліків існуючих аналогів, та задля 
вияву найзручнішого формату нашого додатку. 
1.2 Обгрунтовання вибору технологій розробки 
Оцінивши поточний ринок технологій, було вирішено взяти за основу 
мову програмування JavaScript. Ця мова високого рівня дозволяє писати 
дуже гнучкі програми в різних напрямках. Її можна використовувати як для  
написання Backend, так і для Frontend частин. Тому задля економії людського 
ресурсу та часу, було вирішено використовувати спільну мову 
програмування на проекті. 
- Node.js 
Node.js – Open Source платформа з відкритим кодом, яка 
використовується для написання додатків на основі мови програмування 
JavaScript. 
Ця платформа дозволила нам використовувати JavaScript на всіх етапах 
розробки, та не відволікатись на вивчення незнайомих мов. 
- Angular 
Angular – фреймворк Node.js написаний на мові програмування 
TypeScript, який використовується для написання Front-end частини 
застосунку. 
 Зазвичай, додаток написаний на Angular складається з однієї HTML 
сторінки, CSS та скриптів JavaScript. Головний плюс цього фреймворку – це 
доволі розгорнута документація, яка дозволяє вмить почати розробляти 
додаток, а не витрачати час на вирішення незрозумілих проблем. 
 
- Express 
Express – фреймворк Node.js, який використовується для написання 
серверної частини додатку. Головний плюс цього фреймворку в тому, що з 
його допомогою можна будувати сервери з дуже гнучким функціоналом. 
- Telegraf 
Telegraf – бібліотека Node.js побудована на основі мови програмування 
TypeScript, яка використовується для написання чат-боту в месенджері 
Telegram.  
Головним плюсом цієї бібліотеки я б назвав підтримку TypeScript «з 
коробки», що дозволяє писати бота і не боятися зробити помилок, які б 
«дозволив» JavaScript. Але, на мій погляд, у цієї бібліотеки є дуже великий 
мінус – погана документація. 
- Docker 
Docker — програмне забезпечення для автоматизації розгортання та 
керування програмами в середовищах з підтримкою контейнеризації. 
- PostgreSQL 
 PostgreSQL - це вдосконалена реляційна база даних з відкритим кодом 
корпоративного класу, яка підтримує як запити SQL (реляційні), так і JSON 
(нереляційні). 
- ESlint 
 ESlint - це інструмент, який перевіряє стилістику коду, відповідно до 
обраних правил. ESLint статистично аналізує ваш код для швидкого пошуку 
проблем. ESLint вбудований у більшість текстових редакторів, і ви можете 
запускати ESLint як частину конвеєра безперервної інтеграції.[15] 
- Git 
 При створенні проекту на стадії реалізації з’являється необхідність у 
керуванні змінами у коді. Для цього було прийнято рішення, що необхідно 
використовувати технологію для реалізації цієї потреби. Нею є Git. Ця 
система дозволяє фіксувати зміни, тобто робити коміт, надсилати 
зміни(коміти) у репозиторій. Репозиторій - тека із програмним кодом, до 
 
якого підключений git. Він можу бути як локальним так і віддаленим, тобто 
залитим у хмарне середовище і бути закріпленим за одним із сервісом для 
віддаленого керування репозиторіями такими як: GitLab, GitHub, BitBucket 
тощо. 
- NPM 
NPM - це менеджер пакетів для Node.js. Він був створений у 2009 році 
як проект з відкритим кодом, щоб допомогти розробникам JavaScript легко 
ділитися упакованими модулями коду. 
1.3 Моделювання предметної області 
Було вирішено, що сервіс буде складатись з трьох основних частин: 
телеграм чат-бот, база даних та web-сторінка. Алгоритм користування 
повинен мати наступний вигляд: користувач заходить в чат-бот, заповнює 
заявку, яка включає в себе текстовий опис, фотографію та локацію. Після 
заповнення даних буде можливість редагувати і підтвердити. Далі заявка 
зберігається у базу даних та буде доступна на веб-сайті сервісу. Користувач 
отримує посилання на щойно створену заявку і переходить по ньому для 
перегляду.  
Сайт містить список всіх заявок, для кожної заявки є відповідний 
статус, є можливість фільтрувати заявки в залежності від статусу. Також на 
сайті представлена загальна мапа заявок з інтерактивними точками з різним 
кольором, кожному кольору відповідає свій статус.  
База даних повинна бути завернута в контейнер за допомогою Docker. 
Повинна бути реалізована логіка пагінації для Front-end. За допомогою Knex 
потрібно створювати таблиці в базі даних. Повинні бути створені сервіси: 
geocoder, сервіс для роботи з БД postgres, сервіс заявок. 
Чат-бот повинен мати вимоги до UI. Коли користувач вперше створює 
заявку, йому потрібно надати інструкцію користування додатком. Також, ми 
прийшли до спільної думки щодо процесу створення заявки. Як вже 
говорилось раніше, для створення заявки потрібно 3 речі – опис проблеми, 
фото та локація. Тож, я вирішив, що для користувача буде корисно надати 
 
обмеження під час створення кейсу.  
Всього є 5 етапів створення заявки – привітання, збір тексту, збір фото, 
збір локації та підтвердження. І на кожному із кроків, юзер не може зробити 
щось інше. Тобто на етапі збору тексту, якщо користувач надає фото, тоді чат 
бот надає відповідь про некоректність даних. 
1.4 Формування ТЗ технічного завнання 
 Технічне завдання (ТЗ) - це інструмент, який дозволяє привести 
бажання клієнта у відповідність із можливостями розробника і здатний 
врегулювати всі можливі конфлікти та заощадити час. Безумовно, технічне 
завдання визначає коло завдань, які слід виконати під час створення цього 
веб-сайту. 
Необхідно надати розробникові структуру веб-сайту якомога 
детальніше і пояснити, як повинна виглядати остаточна версія.  
В ідеальному випадку всі деталі роботи та зовнішнього вигляду 
повинні бути зазначені в технічному завданні, таким чином невідповідності 
будуть мінімізовані, а результат відповідатиме вимогам та очікуванням 
замовника. В якості замовника виступає Управління інспектування 
Черкаської міської ради. 
1.4.1 Опис технічних вимог 
Для користувача сервіс повинен включати у себе наступний 
функціонал:  
 можливість правки редагування користувачем;  
 можливість попереднього перегляду;  
 можливість ознайомитись зі всіма заявками; 
 можливість переглядати мапу із заявками. 
Для користувача сервіс повинен включати у себе наступний 
функціонал:  
 реалізації авторизації на сайті; 
 можливість видалення заявки; 
 можливість зміни статусу заявки; 
 
 можливість залишати коментар; 
 можливість переглядати мапу із заявками. 
Функціонал для адміністратору повинен бути доступним лише після 
авторизації. Користувач може лише переглядати сайт і нічого більше.  
 Функціонал сутностей має ґрунтуватися на шаблоні CRUD (Create Read 
Update Delete). CRUD Значення: CRUD - це абревіатура, що походить із світу 
комп’ютерного програмування і стосується чотирьох функцій, які 
вважаються необхідними для реалізації постійного сховища для зберігання 
даних: створення, читання, оновлення та видалення. Постійне сховище - це 
будь-який пристрій зберігання даних, який зберігає живлення після 
вимкнення пристрою, наприклад, жорсткий диск або твердотілий 
накопичувач. Навпаки, оперативна пам’ять та внутрішнє кешування є двома 
прикладами енергонезалежної пам’яті - вони містять дані, які будуть стерті, 
коли вони втратять силу. 
Згідно із переліком пункту 1.2 першого розділу, мають бути 
використані технології: AngularCLI, JavaScript, Node.js, Knex.js, PostgreSQL, 
Docker; та інструменти розробки: ESlint, Git, Husky, npm. 
1.4.2 Огляд продукту з точки зору різних типів користувачів 
 Детальніше про доступний функціонал користувачам дивись у розділі 
другому підпункті №2.4. 
Архітектура має бути розроблена із використанням уже розроблених 
шаблоні спільнотою програмістів або базуватися на них. 
 Для роботи із системою на ПК необхідно мати ОС, яка підтримує 
останню версію Telegram та любий браузер станом на 01.06.22. Для роботи зі 
смартфону на платформі Android чи IOC вимоги аналогічні. Тільки для 
користувачів останніх для використання програми необхідно мати останню 
версію системи, щоб додаток працював коректно. 
1.4.3 Особливості дизайну. 
 Дизайн має бути інтуїтивним і семантичним, відповідати шаблонам UI 
та UX. Елементи інтерфейсу мають повторювати форми логотипу і усі 
 
кольори мають гармонійними. Також мають бути розроблені шаблони усіх 
сторінок та форм під різні розміри екранів, за основу має бути взята ширина 
екрану - 375 пікселів, 640 пікселів, 1024 пікселів та 1440 пікселів. 
Допускаються пропуски на шаблонах офіційного сайту та формах авторизації 
та реєстрації. При реалізації дизайну сторінок допускаються розбіжності. 
  
 
2 ПРОЕКТУВАННЯ СИСТЕМИ 
Проектування складається із послідовних дій: опису головних 
сутностей, формування на їх основі головних та вторинних програмних 
модулів, опис взаємодії різних типів користувачів із системою, проектування 
користувацького інтерфейсу, після розробка архітектури на основі модулів і 
вимог до інтерфейсу користувача відбувається проектування бази даних. Усе 
це включає у себе план реалізації проекту. 
2.1 План реалізації проекту 
Перед тим як почати процес проектування системи, було складено план 
реалізації, який включає у себе дані про дні на виконання, даних початку та 
завершення задач з переліком ресурсів, необхідних у процесі, відповідно до 
можливостей. Оскільки є частини, які не можливо реалізувати, якщо не має 
 
Рисунок 2.1 － Система Trello 
Для простішого сприйняття що за чим має реалізовуватися, було 
обрано систему постановки завдань Trello, де кожен виконував поставлені 
йому завдання. Розроблено схему планування задач із розподілом з 
приблизною кількістю годин на виконання. Задачі були розбиті на 5 
категорій задач (див. рис. 2.2): 
 Info; 
 Backlog; 
 
 In progress; 
 Tech review & Testing; 
 Done. 
 
Рисунок 2.2 － Приклад тікету підзадачі завдання 
Таблиця 2.1 – список задач в системі Trello 
№ Завдання Опис 
1 CC-23 Chat Bot Project Setup Розробка початкової структури проекту 
2 CC-79 add .env-example Створити файл .env-example 
Розробити логіку створення заявки через чат-
3 CC-42 Creating case from bot 
бот 
4 CC-71 Showing "Typing..." status Додати боту статус «Typing…» відразу після 
 
when a created case request is створення заявки 
sending 
Відправка заявки в відповідь для перевірки 
5 CC-83 send user created case 
інформації 
6 CC-75 Ability to delete case Додати можливість видаляти заявку  
Додати скрипт для автоматичного 
7 CC-62 Create a script for the CI 
впровадження в систему GCP 
Розробити функціонал відправки заявки до 
 CC-45 post case info to backend 
API 
 
2.2 Опис головних сутностей 
Як було зазначено в пункті 1.1 аналогічних сервісів комунікації поки 
немає. Тому структура даних заявки має наступний вигляд: 
− id. Обмеження: primary key. Тип даних int. 
− опис. Має бути типу string. Обмеження: максимальна кількість 
символів 500, комірка не може бути порожньою (not null).   
− локація. Тип даних point (latitude, longtitude). Обмеження: 
максимальна кількість символів 500, комірка не може бути порожньою (not 
null). 
− адреса. Має бути типу string. Обмеження: максимальна кількість 
символів 400, комірка не може бути порожньою (not null). 
− url фотографії. Обмеження: максимальна кількість символів 500, 
комірка не може бути порожньою (not null). 
− статус. Має бути 1 або 0. За замовчуванням – 0. 
− дату i час створення заявки формату: DD/MM/YYYY, HH:MM;  
 
2.3 Проектування програмних модулів 
Опис продукту включає у себе перелік очікуваних до реалізації 
модулів, які планується розробити, архітектурні вимоги, вказівку пріорітетів 
розробки, опис технологій, які знадобляться при розробці, а також огляд 
продукту з різних точок зору. Всі пункти можуть включати у себе діаграми та 
схеми, для ліпшого розуміння та уявлення як система має працювати. 
Основними програмними модулями які планується розробити є: 
− Веб-сайт, який буде виконувати функцію адмін панелі та набору 
заявок, доступних для перегляду. 
− Чат-бот в телеграмі, який буде виконувати функцію збору інформації 
від користувачів, тобто створення заявок. 
− База даних, в якій буде зберігатись вся інформація, яку надали 
користувачі. 
Сервіс має бути реалізований із застосуванням задіяних технологій (див. 
Таблиця 2.1) 
Таблиця 2.2 Перелік запланованих технологій до виконання 
Розробницька Перелік запланованих технологій та інструменти до 
часина системи використання 
Cайт (frontend) Angular CLI, Node.js, JavaScript, NPM, ESlint, Git, Husky. 
База даних (backend) JavaScript, Node.js, PostgreSQL, Docker, NPM, ESlint, Git, Husky, 
Knex 
Серверна частина JavaScript, Node.js, Express, ESlint, Git, Husky, 
Чат-Бот JavaScript, TypeScript, Telegraf, Axios, Redis, Docker, Inversify, 
GoogleAPI, Nodemon, Telegraf-Session 
2.4 Проектування дії системи з точки зору різних типів користувачів 
Основними типами користувачів є гість і авторизований користувач, 
тобто адміністратор. Авторизація - перевірка, чи може користувач 
виконувати певні дії (їх часто позначають як ресурси). 
 
 
Рисунок  2.3 － UML діаграма діяльності користувача боту 
 
 
Рисунок 2.4 － UML діаграма діяльності адміністратора 
Як зображено на рисунку 2.3, користувач створює заявку за допомогою 
відправки текстового опису, фотографії та локації. Після того, як дані 
зібрано, у користувача є можливість підтвердити або редагувати їх. Після 
підтвердження, він отримує посилання на сторінку звернення на сайті, де 
може її переглянути. 
Авторизований користувач, тобто адміністратор, має доступ до admin 
панелі, де може робити наступне: 
− міняти статуси заявок; 
 
− видаляти заявки; 
− залишати коментар під заявками; 
2.5 Проектування інтерфейсу користувача 
Основними вимогами до проектування користувацького інтерфейсу є:  
Адаптованість означає, що інтерфейс повинен бути:  
– сумісним з потребами та можливостями користувача;  
– забезпечувати простоту переходу від виконання однієї функції до 
іншої;  
– забезпечувати користувача на високому рівні вказівками стосовно 
його можливих дій, а також генерувати належний зворотний зв’язок на його 
запити;  
– надавати користувачу можливість відчувати себе повноправним 
керівником ситуації при розв’язанні всіх типів задач, тобто, забезпечувати 
його всією необхідною інформацією; користувач повинен бути впевненим, 
що він сам розв’язує поставлену задачу; 
– забезпечувати користувача різними, взаємно доповнюючими 
формами представлення результатів в залежності від типу запиту або від 
характеру отриманого рішення;  
– враховувати особливості користувачів різних рівнів; наприклад, для 
керівника підприємства зручнішим є узагальнене графічне ставлення 
результатів роботи системи підтримки і прийняття рішень у вигляді діаграм 
та графіків, а інженеру-економісту потрібні конкретні цифри у їх часовій 
послідовності.  
Достатність інтерфейсу означає таке: 
– допустимі запити користувача повинні бути чіткими і однозначними 
для користувачів всіх рівнів, а також для прикладних задач всіх типів;  
– реакція системи на всі типи запитів також повинна бути однозначною 
і зрозумілою і, по можливості, простою.   
Дружність інтерфейсу  
Це максимальна простота його використання і готовність в повній мірі 
 
задовольнити запити користувача при розв’язанні визначеного класу задач.  
Гнучкість інтерфейсу 
Гнучкість інтерфейсу – це можливість його адаптування до розв’язання 
конкретної задачі. Якщо розв’язувана задача дуже складна, то інтерфейс 
повинен полегшувати формулювання запитів і видавати результати у формі, 
яка легко і швидко сприймається користувачем. Тобто інтерфейс повинен 
буди максимально простим навіть у випадку, коли розв’язується дуже 
складна задача. При цьому простота означає таке:  
– інтерфейс не повинен бути перевантажений деталями щодо 
представлення розв’язку поставленої задачі – користувач може не охопити 
всіх подробиць (і в цьому, як правило, немає потреби) – тобто нічого зайвого, 
крім того, що необхідно для розуміння результату; 
– він не повинен містити зайвих декоративних деталей, які 
відволікають від головної задачі;  
– інтерфейс повинен бути консистентним, тобто, ґрунтуватись на 
використанні відомих, загальноприйнятих методів і засобів представлення 
інформації;  
– в ідеалі процес взаємодії користувача з системою не повинен 
представляти ніяких труднощів. 
Користувацький інтерфейс має бути розробленим у мінімалістичному 
стилі. В основному будуть використовуватись чорно-білі та зелені кольори.   
Чорний колір - потрібен для більшості кнопок та тексту на сайті. 
Зелений колір – потрібен для виділення поточного елементу меню. Сторінки 
до реаліазції: головна сторінка, список всих заявок, сторінка авторизації, 
мапа заявок. Всі сторінки повинні бути адаптивними під любий екран і 
виглядати однаково нормально як на екрані смартфону, так і на екрані 
комп’ютеру. 
 
 
Рисунок 2.5 － Макет головної сторінки 
Головна сторінка буде представлена у вигляді списку всіх заявок. Зліва 
представлено меню навігації, де можна перейти на сторінки нових заявок, 
завершених та на мапу заявок, де можна побачити місцезнаходження кожної 
заявки і інтуїтивно зрозуміти її статус. 
Для того щоб ознайомитись зі змістом звернення, треба натиснути 
кнопку «Детальніше», після чого відкриється сторінка заявки.  
 
Рисунок 2.6 － Макет сторінки заявки 
 
Якщо сайтом користується адміністратор, в нього є змінювати статус 
заявки, за допомогою кнопок зверху справа (див.рис 2.5), та видаляти заявки: 
 
Рисунок 2.7 － Макет pop-up видалення заявки 
Заявки на карті можна буде переглянути натиснувши на останній пункт 
меню зліва. Кожна точка на карті є інтерективною, має попередній перегляд, 
і натиснувши на неї, користувач переходить на її сторінку. 
 
Рисунок 2.8 － Макет мапи заявок 
 
 
Рисунок 2.9 － Макет обраної заявки на карті 
2.6 Проектування бази даних 
База даних представляє собою таблицю 4 таблиці – cases, 
cases_locations, files, users. Беручи за основу дані, які надсилатиме 
користувач, буде створено наступну структуру: 
 
Рисунок 2.10 － таблиця cases 
  
 
 
Рисунок 2.11 – схема таблиці cases_locations 
 
Рисунок 2.12 – схема таблиці files 
 
Рисунок 2.13 – схема таблиці users 
  
 
База даних планується на основі SQL бази PostrgeSQL, та 
контейнеризована за допомогою Docker. Всі запити виконувались за 
допомогою ORM TypeORM. Для цього треба було створити підключення до 
бази даних: 
 
Рисунок 2.14 － підключення до бази даних 
Всі дані для підключення зберігаються в .env файлі, що виключає 
можливість підключення зі сторони.  
 
Рисунок 2.15 － конфігурація чат-боту 
 
 
Рисунок 2.16 – діаграми схеми бази даних 
 
2.7 Проектування архітектури 
Усі частини системи повинні відповідати певному шаблону 
програмування. Це типовий спосіб вирішення певної проблеми, що часто 
зустрічається при проектуванні архітектури програм, необхідний для 
стандартизації коду, зменшення часу на розробку, полегшення розуміння 
програмного коду. 
На відміну від готових функцій чи бібліотек, патерн не можна просто 
взяти й скопіювати в програму. Патерн являє собою не якийсь конкретний 
код, а загальний принцип вирішення певної проблеми, який майже завжди 
треба підлаштовувати для потреб тієї чи іншої програми. 
Описи шаблонів зазвичай дуже формальні й найчастіше складаються з 
таких пунктів: 
− проблема, яку вирішує патерн(pattern); 
− мотивація щодо вирішення проблеми способом, який пропонує 
патерн; 
− структура класів, складових рішення; 
 
− приклад однією з мов програмування; 
− особливості реалізації в різних контекстах; 
− зв’язки з іншими шаблонами. 
Back-end частина має бути використана вбудована архітектура 
фреймворку. Дана архітектура підтримує мікросервісний архітектурний 
стиль розробки. 
 
Рисунок 2.19 － Схема взаємодії мікросервісів 
Згідно цієї концепції архітектури, back-end частина повинна складатися 
із мікросервісів. 
Програмний код клієнстської чатини повинен відповідати патерну 
MVC. MVC Pattern розшифровується як Model-View-Controller Pattern. Цей 
шаблон використовується для відокремлення частин програми. 
Модель(Model) - модель представляє об'єкт або JAVA POJO, що 
містить у собі опис полів сутності. Він також може мати логіку для 
оновлення контролера, якщо його дані змінюються. 
Перегляд(View) - подання представляє візуалізацію даних, що містять 
 
модель. 
Контролер(Controller) - Контролер діє як на модель, так і на вигляд. Він 
контролює потік даних в об'єкт моделі та оновлює дані для перегляду, коли 
вони змінюються. Таким чином view та модель відокремлюються. 
На основі проектування проекту, буде розроблено наступну схему 
компонентів за МVC: 
 .idea – папка з налаштуванням для середовища розробки 
 docs – містить в собі всі статичні файли, які потрібні для документації 
проекту 
 src – містить всю основну логіку проекту 
 config – налаштування та секретні змінні для проекту 
 constants – константи, які я виніс в окремі файли 
 controllers – контролери, які необхідні для обробки логіки чат-боту 
 helpers – невеликі функції, які допомагають в розробці 
 services – всі сервіси проекту 
 types – інтерфейси, створені для типизації проекту 
2.8 Алгоритм роботи фактичної системи 
При першому вході на сайт сервісу благоустрою користувач потрапляє 
на головну сторінку офіційного сайту. 
 
Рисунок 3.6 － Реалізована головна сторінка 
 
Далі користувач може перейти за вибором посилання в меню зліва  на 
сторінку нових заявок, завершених заявок та мапу заявок, де він може 
побачити інформацію про кожне звернення. 
 
Рисунок 3.7 － UML діаграма дій користувача 
 
 
Рисунок 3.8 － Карта заявок 
 
 
 
Рисунок 3.9 － Обрана заявка на мапі 
Простий користувач має можливість лише переглядати заявки, для 
того, аби була можливість взаємодіяти з ними, потрібно пройти авторизацію 
для отримання прав адміністратора, який має право змінювати статус, 
залишати коментар та видаляти звернення (див.рис. 3.10).  
 
Рисунок 3.10 － UML діаграма дій адміністратора 
 
 
 
 
Рисунок 3.11 － Видалення звернення 
 
 
3 РОЗРОБКА ТА ТЕСТУВАННЯ СИСТЕМИ 
3.1 Файлова структура проекту 
Файлова структура чат-боту має наступний вигляд: 
│   .dockerignore 
│   .editorconfig 
│   .env-example 
│   .eslintignore 
│   .eslintrc.json 
│   .gitignore 
│   docker-compose.yml 
│   Dockerfile 
│   nodemon.json 
│   package-lock.json 
│   package.json 
│   Readme.md 
│   tsconfig.json 
│ 
├───.idea 
│       .gitignore 
│       CheCleanTelegram-bot.iml 
│       modules.xml 
│       vcs.xml 
│       webResources.xml 
│ 
├───docs 
│       CheClean-logo.png 
│ 
└───src 
    │   app.ts 
    │   index.ts 
    │ 
    ├───config 
    │       envConfig.ts 
    │       index.ts 
    │       inversifyConfig.ts 
    │       redisConfig.ts 
    │       telegrafStageConfig.ts 
    │       telegrafWizardConfig.ts 
    │ 
    ├───constants 
    │       botTexts.ts 
    │       index.ts 
    │       keyboards.ts 
    │       types.ts 
    │ 
    ├───controllers 
    │       index.ts 
    │       telegrafController.ts 
 
    │ 
    ├───helpers 
    │       createTelegrafKeyboard.ts 
    │       index.ts 
    │       telegrafHelper.ts 
    │ 
    ├───interfaces 
    │       apiServiceInterface.ts 
    │       envConfigInterface.ts 
    │       geocoderServiceInterface.ts 
    │       index.ts 
    │       index.ts 
    │ 
    ├───services 
    │       api.service.ts 
    │       geocoder.service.ts 
    │       index.ts 
    │       telegraf.service.ts 
    │ 
    └───types 
            index.ts 
            telegrafComposer.ts 
            telegrafKeyboard.ts 
 
Таблиця 3.1 Опис файлів 
№ Назва файлу Опис 
Містить в собі основні налаштування 
1 env.config.ts 
проекту 
Містить в собі налаштування залежностей 
2 inversify.config.ts 
проекту 
Містить в собі налаштування для бази 
3 redis.config.ts 
даних Redis 
Містить в собі налаштування для кроків 
4 telegrafStage.config.ts 
при створенні заявки 
Містить в собі всі тексти які необхідні чат-
5 botTexts.ts 
боту 
Містить в собі шаблон для створення 
6 keyboard.ts 
кнопок в чаті 
Містить в собі логіку для обробки 
7 telegraf.controller.ts 
створення заявки на всіх етапах 
8 createTelegrafKeyboard.ts Функція для створення кнопок 
9 telegrafHelper.ts Обробка створення заявки та відміни 
10 api.service.ts Сервіс для взаємодії з API 
11 geocoder.service.ts Сервіс для роботи з координатами заявки 
12 telegraf.service.ts Сервіс для роботи з бібліотекою Telegraf 
3.2 Розробка бази даних 
База даних була реалізована за допомогою Docker, де було створено 
окремий екземпляр сервера PostgreSQL, та безпосередньо базу даних із 
таблицями, що були описані у попередньому розділі, включно із усіма 
 
таблицями. Створення бази даних було за допомогою інтерфейсу 
інструменту. Створення таблиці було реалізовано за допомогою міграцій, які 
було створені вручну. 
Таким чином було реалізовано наступні міграції: 
cases.ts 
 import { 
  MigrationInterface, 
   QueryRunner, 
   Table, 
 } from 'typeorm'; 
  
 
 export class cases1621845429629 implements 
MigrationInterface { 
   public async up(queryRunner: QueryRunner): 
Promise<void> { 
     await queryRunner.createTable(new Table({ 
       name: 'cases', 
       columns: [ 
         { 
           name: 'id', 
           type: 'serial', 
           isPrimary: true, 
         }, 
         { 
           name: 'details', 
           type: 'varchar', 
           length: '128', 
           isNullable: false, 
         }, 
         { 
           name: 'status', 
           type: 'enum', 
           enum: [ 
             'NEW', 
             'PROCESSING', 
             'DONE', 
           ], 
           default: '\'NEW\'', 
         }, 
         { 
           name: 'createdAt', 
           type: 'timestamp with time zone', 
           default: 'NOW()', 
         }, 
         { 
           name: 'updatedAt', 
           type: 'timestamp with time zone', 
           default: 'NOW()', 
         }, 
         { 
           name: 'deletedAt', 
           type: 'timestamp with time zone', 
           isNullable: true, 
           default: null, 
         }, 
 
       ], 
     }), true); 
   } 
  
 
   public async down(queryRunner: QueryRunner): 
Promise<void> { 
     await queryRunner.dropTable('cases', true); 
   } 
 } 
Як можна бачити, таблиця cases складається з наступних колонок: 
 id primary key – унікальний ідентифікатор кожного запису в БД 
 details varchar(512) - опис створеної проблеми 
 status enum(‘NEW’, ‘PROCESSING’, ‘DONE’) – статус заявки 
 createdAt, updatedAt, deletedAt – автоматично сгенеровані дати 
 
files.ts 
   public async up(queryRunner: QueryRunner): Promise<void> { 
     await queryRunner.createTable(new Table({ 
       name: 'files', 
       columns: [ 
         { 
           name: 'id', 
           type: 'serial', 
          isPrimary: true, 
 
        }, 
 
        { 
 
          name: 'gcUrl', 
 
          type: 'varchar', 
 
          length: '256', 
 
          isNullable: false, 
 
          isUnique: true, 
 
        }, 
 
        { 
 
          name: 'caseId', 
 
          type: 'integer', 
 
        }, 
 
      ], 
 
    }), true); 
 
 
 
 
    await queryRunner.createForeignKey('files', new TableForeignKey({ 
 
      columnNames: ['caseId'], 
 
      referencedColumnNames: ['id'], 
 
      referencedTableName: 'cases', 
 
    })); 
 
  } 
 
 
 
 
  public async down(queryRunner: QueryRunner): Promise<void> { 
 
    await queryRunner.dropTable('files', true); 
 
  } 
 
} 
 
 
 
 Таблиця files була створена для того, щоб до кожної заявки можна було 
додати фото для візуального відображення проблеми. Структура таблиці 
наступна: 
 
 id primary key – унікальний ідентифікатор кожного запису в БД 
 gcUrl varchar(512) – посилання на файл в сервісі Google Cloud 
Platform 
 caseId foreign key – ідентифікатор запису із таблиці cases 
 
casesLocation.ts 
   public async up(queryRunner: QueryRunner): Promise<void> { 
     await queryRunner.createTable(new Table({ 
       name: 'casesLocation', 
       columns: [ 
         { 
           name: 'id', 
           type: 'serial', 
           isPrimary: true, 
         }, 
         { 
           name: 'longitude', 
           type: 'numeric', 
           isNullable: false, 
         }, 
         { 
           name: 'latitude', 
           type: 'numeric', 
           isNullable: false, 
         }, 
         { 
           name: 'address', 
           type: 'varchar', 
           length: '128', 
           isNullable: false, 
         }, 
         { 
           name: 'caseId', 
           type: 'integer', 
         }, 
       ], 
     }), true); 
  
 
 
     await queryRunner.createForeignKey('casesLocation', new TableForeignKey({ 
       columnNames: ['caseId'], 
       referencedColumnNames: ['id'], 
       referencedTableName: 'cases', 
     })); 
   } 
  
 
   public async down(queryRunner: QueryRunner): Promise<void> { 
     await queryRunner.dropTable('casesLocation', true); 
   } 
 } 
 
Таблиця casesLocation була створеня для того щоб не зберігати локацію 
заявки в таблиці cases. Має наступну структуру: 
 id primary key – унікальний ідентифікатор кожного запису в БД 
 longitude, latitude varchar(512) – координати (широта та довгота) 
 address varchar(512) – адреса по координатам 
 caseId foreign key – ідентифікатор запису із таблиці cases 
3.3 Опис чат-боту 
Було створено окремі репозиторії для front-end, back-end та телеграм-
боту частин сервісу. Вони були об’єднані рамками проекту в сервісі для 
керування версіями - GitHub. Таким чином ми реалізували проект з 
мікросервісною архітектурою. 
 Файлова система була реалізована відповідною до тої, що була описана 
у другому розділі (див. рис. 3.5). 
 
 
 
Рисунок 3.5 － Файлова структура чат-боту 
 
Для реалізації були використані наступні технології: JavaScript, Node.js, 
TypeScript, Telegraf, Redis, Docker, Axios, GoogleAPI. Окрім цього були 
застосовані засоби розробки: NPM, ESlint, Git, Husky. 
Архітектурно, частина чат-боту складається із мікросервісів, які 
знаходяться у директорії services. Вони використовуються у всіх модулях, бо 
кожен модуль має HTTP запити, дані яких мають перевіряються відповідно 
описаних у попередніх розділах обмежень. Такі перевірки даних 
відбуваються при запитах HTTP POST та PUT запитах, оскільки такі запити 
маю тіла із даними, що мають зберігатися чи оновлюватися у базі даних. Для 
того, щоб сервер не падав від помилок взаємодії із базою даних. 
 
4 ВИСНОВКИ 
Отже, було реалізовано сервіс оперативного створення заявки про 
проблему для Управління інспектування Черкаської міської ради. Першими 
кроками до реалізації були: пошук існуючих рішень, аналіз предметної 
області, формування вимог до системи та вибір засобів реалізації. На основі 
цих даних було створено план реалізації проекту, який включав у себе 
розділення побудови на підзадачі, які треба було виконувати до кінця 
дедлайну.  
Далі було розроблено користувацький інтерфейс, щоб зрозуміти які 
дані необхідно зберігати, окрім тих, що були описані на попередніх етапах. І 
вже на основі зібраних даних було спроектовано базу даних з описом 
головної таблиці кейсів. Після було спроектовано архітектурні вимоги, які 
включають у себе розміщення файлів, файлову систему, представлення як 
елементи мають взаємодіяти між собою та опис паттернів програмування, які 
мають бути реалізовані. 
Наступним етапом була саме розробка. Так як на попередніх етапах усі 
неточності були описані, то реалізована система відповідає вимогам.  
У ході розробки було використано паттерн мікросерсвісний 
програмування в серверній частині та MVC із мікросервісами в клієнтській. 
Backend реалізований за допомогою технологій JavaScript, Node.js, 
PostgreSQL, Docker, Knex. Frontend з використанням AngularCLI, JavaScript, 
React, Vue.js. Для підтримки коду у єдиному стилі, було використано 
наступні засоби розробки:  ESlint, Husky. Для організації роботи із пакетами 
цих бібліотек використовувався NPM, а для організації роботи у команді над 
спільними теками - Git. 
 Було реалізовано сторінки всіх заявок, нових, та завершених, сторінку з 
мапою заявок та сторінки панелі адміністратора. 
 
5 СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ 
1 Chatbot: What is a Chatbot? Why are Chatbots Important? -Інформаційний 
портал expert.ai. [Електронний ресурс]. - Режим доступу: 
https://www.expert.ai/blog/chatbot/ 
2 CLI Overview and Command Reference - Офіційна документація 
фреймворку Angular CLI. [Електронний ресурс]. - Режим доступу: 
https://angular.io/cli 
3 What is TypeScript? - Офіційний сайт Typescript. [Електронний ресурс]. - 
Режим доступу: https://www.typescriptlang.org/ 
4 Hello, nest! - Офіційний сайт фреймворку NestJS. [Електронний ресурс]. - 
Режим доступу: https://nestjs.org/ 
5 What is PostgreSQL? - Інформаційний портал Amazon. [Електронний 
ресурс]. - Режим доступу: https://aws.amazon.com/rds/postgresql/what-is-
postgresql/ 
6 WebSockets for fun and profit - Стаття блогу компанії Stackoverflow. 
[Електронний ресурс]. - Режим доступу: 
https://stackoverflow.blog/2019/12/18/websockets-for-fun-and-profit/ 
7 Documentation - Офіційна документація препроцесору Sass. [Електронний 
ресурс]. - Режим доступу: https://sass-lang.com/documentation 
8 ESLint Find and fix problems in your JavaScript code  - Офіційна 
документація ESLint. [Електронний ресурс]. - Режим доступу: 
https://eslint.org/ 
9 TSLint An extensible linter for the TypeScript language. - Офіційна 
документація TSLint. [Електронний ресурс]. - Режим доступу:  
https://palantir.github.io/tslint/ 
10 Системи контролю версій на прикладі git - Сайт Державного університету 
телекомунікацій. [Електронний ресурс]. - Режим доступу: 
http://www.dut.edu.ua/ua/news-1-626-9170-sistemi-kontrolyu-versiy-na-
prikladi-git_kafedra-kompyuternih-nauk-ta-informaciynih-tehnologiy 
 
11 Husky - Сайт налаштувань конфігурацій npm . [Електронний ресурс]. - 
Режим доступу: https://www.npmjs.com/package/husky 
12 About npm - Офіційний сайт npm. [Електронний ресурс]. - Режим доступу: 
https://www.npmjs.com/about 
13 Головна сторінка офіційного сайту JWT. [Електронний ресурс]. - Режим 
доступу: https://jwt.io/ 
14 Token - Інформаційний портал WhatIs.com. [Електронний ресурс].  
15 What Is Token-Based Authentication? - Інформаційний портал okta. 
[Електронний ресурс]. - Режим доступу: https://www.okta.com/identity-
101/what-is-token-based-
authentication/#:~:text=Auth%20tokens%20work%20like%20a,or%20server%
2Dbased%20authentication%20techniques.- Режим доступу: 
https://whatis.techtarget.com/definition/token 
16 How to write technical task - Encomage [Електронний ресурс]. - Режим 
доступу:  https://encomage.com/2020/04/27/how-to-write-technical-task/ 
17 CRUD - [Електронний ресурс]. - Режим доступу: 
https://www.sumologic.com/glossary/crud/ 
18 Менторство в компаніях: як і навіщо впроваджувати - Матеріал 
електронної системи «Безпека». [Електронний ресурс]. - Режим доступу: - 
https://bezpeka.isu.net.ua/sites/default/files/pdf/mentorstvo_v_kompaniyakh_y
ak_i_n-1831-501340.pdf 
19 Аутентифікація і авторизація - Повний посібник по Yii 1.1 [Електронний 
ресурс]. - Режим доступу: 
https://www.yiiframework.com/doc/guide/1.1/uk/topics.auth 
20 Що таке Патерн? - https://refactoring.guru/uk/design-patterns/what-is-pattern 
21 Overview [Електронний ресурс]. - Режим доступу:  
https://docs.nestjs.com/microservices/basics 
22 Документація Node.js. - [Електронний ресурс]. - Режим доступу: 
https://devdocs.io/node/ 
23 Курс по PostgreSQL, YouTube - [Електронний ресурс]. -  Режим доступу: 
 
https://www.youtube.com/watch?v=qw--VYLpxG4&t=5682s 
24 Туторіал по docker compose - YouTube - [Електронний ресурс]. -  Режим 
доступу: https://www.youtube.com/watch?v=Qw9zlE3t8Ko 
25 Туторіал по docker - YouTube - [Електронний ресурс]. -  Режим доступу: 
https://www.youtube.com/watch?v=YFl2mCHdv24 
26 Docker and PostgreSQL - YouTube - [Електронний ресурс]. -  Режим 
доступу: https://www.youtube.com/watch?v=aHbE3pTyG-Q 
27 Документація по Docker - [Електронний ресурс]. - Режим доступу: 
https://docs.docker.com/get-started/ 
28 Документація по knex.js - [Електронний ресурс]. - Режим доступу: 
http://knexjs.org/ 
29 Документація по Javascript - MDN - [Електронний ресурс]. - Режим 
доступу: https://developer.mozilla.org/en-US/docs/Learn/JavaScript 
30 ESLint Find and fix problems in your JavaScript code - Офіційна 
документація ESLint. [Електронний ресурс]. - Режим доступу: 
https://eslint.org/ 
31 Системи контролю версій на прикладі git - Сайт Державного університету 
телекомунікацій. [Електронний ресурс]. - Режим доступу: 
http://www.dut.edu.ua/ua/news-1-626-9170-sistemi-kontrolyu-versiy-na-
prikladi-git_kafedra-kompyuternih-nauk-ta-informaciynih-tehnologiy 
32 Providers [Електронний ресурс]. - Режим доступу:  
https://docs.nestjs.com/providers 
33 Overview [Електронний ресурс]. - Режим доступу:  
https://docs.nestjs.com/microservices/basics 
34 Design Patterns - MVC Pattern. [Електронний ресурс]. - Режим доступу: 
https://www.tutorialspoint.com/design_pattern/mvc_pattern.htm#:~:text=MVC
%20Pattern%20stands%20for%20Model,the%20data%20that%20model%20co
ntains. 
35 Pipes - Документація Nest.JS. [Електронний ресурс]. - Режим доступу: 
https://docs.nestjs.com/pipes 
 
36 What Is Swagger? - Документація Swagger. [Електронний ресурс]. - Режим 
доступу: https://swagger.io/docs/specification/2-0/what-is-swagger/ 
37 Telegraf Docs – документація Telegraf [Електронний ресурс]. – Режим 
доступу: https://telegraf.js.org/ 
38 Redis Docs – документація Redis [Електронний ресурс]. – Режим доступу: 
https://redis.io/ 
 
Додаток А 
Автоматизована інтерактивна система збору та обробки інформації 
про різні ситуації в місті для покращення роботи служб міста Черкаси. 
Система мікросервісів
Специфікація 
ЧДТУ 221959.02 
Листів 2 
Розробник:   ________________________    Білозор Д.О. 
Керівник:     ________________________    Метелап В.В. 
Черкаси, 2022 
Позначення Найменування Примітка 
482.ЧДТУ. 221959.02 12 01 Текст програми 
482.ЧДТУ. 221959.02 34 01 Інструкція користувачеві 
482.ЧДТУ. 221959.02 90 01 Графічний матеріал 
47 
Додаток Б 
Автоматизована інтерактивна система збору та обробки інформації 
про різні ситуації в місті для покращення роботи служб міста Черкаси. 
Система мікросервісів 
Текст програми 
ЧДТУ 221959.02 
Листів 11 
Розробник:   ________________________    Білозор Д. О. 
Керівник:     ________________________    Метелап В. В. 
Черкаси, 2022 
ЧДТУ 221959.02 
Файл 20220512183034_create_cases_table.js 
const knex = require('knex'); 
/** 
* @param {knex} knex
*/
exports.up = function(knex) { 
  return knex.schema.hasTable('cases').then((exists) => { 
    if (!exists) { 
return knex.schema.createTable('cases', (table) => { 
table.increments('id').primary(); 
table.string('details', 500).notNullable(); 
table.specificType('location', 'POINT').notNullable(); 
table.string('address', 400).notNullable(); 
table.string('image_url', 500).notNullable(); 
table.integer('status').defaultTo(0); 
table.timestamp('created_at', { precision: 6 
}).defaultTo(knex.fn.now(6)); 
}); 
    } 
  }); 
}; 
exports.down = function(knex) { 
  return knex.schema.dropTable('cases'); 
}; 
Файл 01_cases.js  
const knex = require('knex'); 
/** 
* @param {knex} knex
*/
exports.seed = function(knex) { 
  return knex('cases').del() 
    .then(function () { 
const seedCases = [
{ 
   details: 'КИЇВ. 26 квітня. УНН. На сьогодні Російська 
Федерація незаконно утримує чи ув’язнює з політичних мотивів близько 
120 незгодних громадян України. Про це повідомляє УНН з посиланням на 
пресслужбу МЗС.', 
location : "49.4063358, 32.0539413", 
address: 'Черепашка, В’ячеслава Чорновола вулиця, Хімселище, 
Черкаси, Придніпровський район, Черкаська міська рада, Черкаська 
область, 18000-18499, Україна', 
image_url: 
'https://upload.wikimedia.org/wikipedia/commons/d/d7/Israel_3_002.Tras
h.jpg',
}, 
{ 
49 
ЧДТУ 221959.02 
          details: 'КИЇВ. 26 квітня. УНН. На сьогодні Російська 
Федерація незаконно утримує чи ув’язнює з політичних мотивів близько 
120 незгодних громадян України. Про це повідомляє УНН з посиланням на 
пресслужбу МЗС.', 
          location : "49.4063358, 32.0539413", 
          address: 'Черепашка, В’ячеслава Чорновола вулиця, Хімселище, 
Черкаси, Придніпровський район, Черкаська міська рада, Черкаська 
область, 18000-18499, Україна', 
          image_url: 
'https://upload.wikimedia.org/wikipedia/commons/d/d7/Israel_3_002.Tras
h.jpg', 
          status: 0, 
          created_at: knex.select(knex.raw(`NOW() - INTERVAL '10 
DAYS'`)), 
        }, 
        ]; 
 
      return knex('cases').insert([ 
        ...seedCases, 
        ...seedCases, 
        ...seedCases, 
        ...seedCases, 
        ...seedCases, 
      ]); 
    }); 
}; 
 
Файл case.mocks.js 
 
const newCaseMock = { 
  details: 'мусор', 
  location: { latitude: 49.457857, longitude: 32.043704 }, 
  image_url: 'test-image', 
}; 
 
const casesMock = [ 
  { 
    id: 1, 
    details: 'мусор', 
    location: { 
      latitude: 49.457857, longitude: 32.043704, address: 
'test_address', map_image_url: 'test-url', 
    }, 
    image_url: 'test-image', 
    status: 0, 
    created_at: '2020-05-03T14:09:38.244Z', 
  }, 
  { 
    id: 2, 
    details: 'мусор2', 
    location: { 
50 
ЧДТУ 221959.02 
      latitude: 49.457857, longitude: 32.043704, address: 
'test_address', map_image_url: 'test-url', 
    }, 
    image_url: 'test-image', 
    status: 0, 
    created_at: '2020-05-03T14:09:38.244Z', 
  }, 
]; 
 
module.exports = { 
  newCaseMock, 
  casesMock, 
}; 
 
Файл common.js 
const { casesMock, newCaseMock } = require('./case.mocks'); 
 
class CommonMocks { 
  static get newCase() { 
    return this.getDeepCopy(newCaseMock); 
  } 
 
  static get cases() { 
    return this.getDeepCopy(casesMock); 
  } 
 
  static getDeepCopy(mock) { 
    return JSON.parse(JSON.stringify(mock)); 
  } 
} 
 
module.exports = { 
  CommonMocks, 
}; 
 
Файл cases.service.js 
const { GeocoderService, PostgresService } = require('./index'); 
 
class CasesService { 
  /** 
   * @param {PostgresService} postgresService 
   * @param {GeocoderService} geocoderService 
   */ 
  constructor(postgresService, geocoderService) { 
    this.postgresService = postgresService; 
    this.geocoderService = geocoderService; 
    this.DEFAULT_PARAMS = { 
      limit: 25, 
      offset: 0, 
    }; 
  } 
51 
ЧДТУ 221959.02 
 
  remapCase({ 
    id, details, location, address, image_url, map_image_url, status, 
created_at, 
  }) { 
    return { 
      id, 
      details, 
      location: { 
        latitude: location.x, 
        longitude: location.y, 
        address, 
        map_image_url, 
      }, 
      image_url, 
      status, 
      created_at, 
    }; 
  } 
 
  async getCases(searchParams) { 
    const currentParams = { 
      ...this.DEFAULT_PARAMS, 
      ...searchParams, 
    }; 
 
    const queryParamsBuilder = (query) => { 
      if (currentParams.id) { 
        query.where('id', currentParams.id); 
      } 
 
      if (currentParams.status) { 
        query.where('status', currentParams.status); 
      } 
 
      if (currentParams.details) { 
        query.where('details', 'like', `%${currentParams.details}%`); 
      } 
    }; 
 
    const casesRespose = await this.postgresService 
      .knex('cases') 
      .orderBy('id', 'desc') 
      .limit(currentParams.limit) 
      .offset(currentParams.offset) 
      .modify(queryParamsBuilder); 
 
    const totalCount = +(await this.postgresService 
      .knex('cases') 
      .count('id') 
      .modify(queryParamsBuilder))[0].count; 
52 
ЧДТУ 221959.02 
 
    return { 
      limit: +currentParams.limit, 
      offset: +currentParams.offset, 
      results: casesRespose.map(this.remapCase), 
      total_count: totalCount, 
    }; 
  } 
 
  async getCaseById(id) { 
    const idResponse = await 
this.postgresService.knex('cases').where('id', id); 
 
    return idResponse.map(this.remapCase); 
  } 
 
  async createCase(newCase) { 
    const databaseCase = { 
      ...newCase, 
      location: `${newCase.location.latitude}, 
${newCase.location.longitude}`, 
      address: (await 
this.geocoderService.reverseGeocoding(newCase.location.latitude, 
newCase.location.longitude)).display_name, 
    }; 
 
    const createdCase = await this.postgresService 
      .knex('cases') 
      .insert(databaseCase) 
      .returning('*'); 
 
    return this.remapCase(createdCase[0]); 
  } 
 
  async resolveCase(id) { 
    const resolvedCase = await this.postgresService 
      .knex('cases') 
      .where('id', id) 
      .update({ status: 1 }) 
      .returning('*'); 
 
    return this.remapCase(resolvedCase[0]); 
  } 
 
  async unresolveCase(id) { 
    const unresolvedCase = await this.postgresService 
      .knex('cases') 
      .where('id', id) 
      .update({ status: 0 }) 
      .returning('*'); 
 
53 
ЧДТУ 221959.02 
    return this.remapCase(unresolvedCase[0]); 
  } 
} 
 
module.exports = { 
  CasesService, 
}; 
 
Файл geocoder.service.js 
const Queue = require('queue-promise'); 
const axios = require('axios'); 
 
class GeocoderService { 
  constructor(apikey, apiUrl) { 
    this.API_KEY = apikey; 
    this.API_URL = apiUrl; 
    this.LIMIT = 1; 
    this.FORMAT = 'json'; 
    this.LANG = 'uk'; 
 
    this.queue = new Queue({ 
      concurrent: 1, 
      interval: 1500, 
      start: true, 
    }); 
  } 
 
  async reverseGeocoding(latitude, longitude) { 
    return new Promise((resolve) => { 
      const url = `${this.API_URL}` 
        + `?key=${this.API_KEY}` 
        + `&format=${this.FORMAT}` 
        + `&accept-language=${this.LANG}` 
        + `&limit=${this.LIMIT}` 
        + `&lat=${latitude}` 
        + `&lon=${longitude}`; 
 
      return this.queue.enqueue(async () => { 
        const address = (await axios.get(url)).data; 
        resolve(address); 
      }); 
    }); 
  } 
} 
 
module.exports = { 
  GeocoderService, 
}; 
 
Файл index.js 
const { CasesService } = require('./cases.service'); 
54 
ЧДТУ 221959.02 
const { PostgresService } = require('./postgres.service'); 
const { GeocoderService } = require('./geocoder.service'); 
 
const postgresService = new PostgresService(); 
const geocoderService = new 
GeocoderService(process.env.LOCATIONIQ_API_KEY, 
process.env.LOCATIONIQ_API_URL); 
const casesService = new CasesService(postgresService, 
geocoderService); 
 
module.exports = { 
  PostgresService, 
  CasesService, 
  GeocoderService, 
  postgresService, 
  casesService, 
  geocoderService, 
}; 
 
Файл postgres.service.js 
const knex = require('knex'); 
 
class PostgresService { 
  constructor() { 
    this.knex = knex({ 
      client: 'pg', 
      connection: { 
        host: process.env.PGHOST, 
        user: process.env.PGUSER, 
        password: process.env.PGPASSWORD, 
        database: process.env.PGDATABASE, 
      }, 
      pool: { min: 0, max: 7 }, 
    }); 
  } 
} 
 
module.exports = { 
  PostgresService, 
}; 
 
Файл index.js 
const express = require('express'); 
require('express-async-errors'); 
const cors = require('cors'); 
const bodyParser = require('body-parser'); 
const dotenv = require('dotenv'); 
const { casesService } = require('./services/index'); 
 
dotenv.config(); 
 
55 
ЧДТУ 221959.02 
const app = express(); 
 
app.use(bodyParser.json()); 
app.use( 
  bodyParser.urlencoded({ 
    extended: true, 
  }), 
); 
 
app.use(cors({ 
  origin: process.env.CORS_FRONTEND_DOMAIN, 
})); 
 
app.get('/', (request, response) => { 
  response.json({ info: 'CheClean' }); 
}); 
 
app.get('/cases', async (request, response) => { 
  const cases = await casesService.getCases(request.query); 
  response.status(200).json(cases); 
}); 
 
app.get('/cases/:id', async (request, response) => { 
  const caseById = await casesService.getCaseById(+request.params.id); 
  response.status(200).json(caseById); 
}); 
 
app.post('/cases', async (request, response) => { 
  const createdCase = await casesService.createCase(request.body); 
  response.status(200).json(createdCase); 
}); 
 
app.patch('/cases/:id/resolve', async (request, response) => { 
  const resolveCase = await 
casesService.resolveCase(+request.params.id); 
  response.status(200).json(resolveCase); 
}); 
 
app.patch('/cases/:id/unresolve', async (request, response) => { 
  const unresolveCase = await 
casesService.unresolveCase(+request.params.id); 
  response.status(200).json(unresolveCase); 
}); 
 
app.use((err, request, response, next) => { 
  console.error(err); 
  response.status(500).json({ errorMessage: err.message }); 
  next(); 
}); 
 
app.listen(process.env.PORT, () => { 
56 
ЧДТУ 221959.02 
  console.log(`Server started on port ${process.env.PORT}.`); 
}); 
 
Файл .dockerignore 
node_modules 
 
Файл .editorconfig 
root = true 
 
[*] 
end_of_line = lf 
charset = utf-8 
trim_trailing_whitespace = true 
insert_final_newline = true 
indent_style = space 
indent_size = 2 
 
[*js] 
indent_style = space 
indent_size = 2 
 
[*.{diff,md}] 
trim_trailing_whitespace = false 
 
Файл eslintrc.js 
module.exports = { 
  env: { 
    es6: true, 
    node: true, 
  }, 
  extends: ['airbnb-base'], 
  globals: { 
    Atomics: 'readonly', 
    SharedArrayBuffer: 'readonly', 
  }, 
  parserOptions: { 
    ecmaVersion: 2018, 
    sourceType: 'module', 
  }, 
  rules: { 
    "max-len": [2, 140, 4], 
    "no-unused-vars": "off", 
    'camelcase': 'off', 
    'class-methods-use-this': 'off', 
    'no-console': 'off', 
    semi: ['error', 'always'], 
  }, 
}; 
 
Файл .gitignore 
57 
ЧДТУ 221959.02 
node_modules 
.env 
.idea 
Файл docker-compose.yml 
version: "3" 
services: 
    backend: 
container_name: "cc_backend" 
build: . 
volumes: 
- ".:/app"
- "data_backend_libs:/app/node_modules"
ports: 
- "3000:3000"
env_file: ".env" 
depends_on: 
- postgres
    postgres: 
container_name: "cc_postgres" 
image: "postgres:12" 
ports: 
- "3300:3300"
env_file: ".env" 
volumes: 
    data_backend_libs: 
driver: local 
Файл Dockerfile 
FROM node:13-alpine3.10 
WORKDIR /app 
COPY package*.json ./ 
RUN npm ci && npm cache clean --force 
#COPY . . 
EXPOSE 3000 
CMD [ "npm", "start" ] 
Файл knexfile.js 
require('dotenv').config(); 
module.exports = { 
  development: { 
    client: 'postgresql', 
58 
ЧДТУ 221959.02 
    connection: { 
host : process.env.PGHOST, 
user : process.env.PGUSER, 
password : process.env.PGPASSWORD, 
database: process.env.PGDATABASE, 
    }, 
    pool: { 
min: 2, 
max: 10 
    }, 
    migrations: { 
   tableName: 'knex_migrations' 
    } 
  }, 
}; 
Файл package.json 
{ 
  "name": "src", 
  "version": "1.0.0", 
  "description": "CheClean", 
  "main": "index.js", 
  "dependencies": { 
    "axios": "^0.19.2", 
    "body-parser": "^1.19.0", 
    "cors": "^2.8.5", 
    "dotenv": "^8.2.0", 
    "express": "^4.17.1", 
    "express-async-errors": "^3.1.1", 
    "knex": "^0.21.1", 
    "nodemon": "^2.0.3", 
    "pg": "^8.0.3", 
    "queue-promise": "^2.0.1" 
  }, 
  "engines": { 
    "node": "13.12.0" 
  }, 
  "devDependencies": { 
    "editorconfig": "^0.15.3", 
    "eslint": "^6.6.0", 
    "eslint-config-airbnb-base": "^14.0.0", 
    "eslint-config-prettier": "^6.5.0", 
    "eslint-plugin-import": "^2.18.2", 
    "eslint-plugin-prettier": "^3.1.1", 
    "husky": "^3.0.9" 
  }, 
  "scripts": { 
    "start": "nodemon src/index.js", 
    "docker": "docker-compose up", 
    "docker:init": "docker-compose build && npm run docker:migrate && 
docker-compose up", 
59 
ЧДТУ 221959.02 
    "docker:migrate": "docker-compose run --rm backend npm run 
migrate", 
    "docker:seed": "docker-compose run --rm backend npm run 
migrate:seed", 
    "lint": "npx eslint ./src/**/*.js", 
    "lint:fix": "npx eslint ./src/**/*.js --fix", 
    "migrate": "npx knex migrate:latest", 
    "migrate:rollback": "npx knex migrate:rollback", 
    "migrate:seed": "npx knex seed:run", 
    "test": "echo \"Error: no test specified\" && exit 1" 
  }, 
  "author": "Lexander1108", 
  "license": "ISC", 
  "husky": { 
    "hooks": { 
      "pre-commit": "", 
      "pre-push": "" 
    } 
  } 
} 
 
60 
Додаток В 
Автоматизована інтерактивна система збору та обробки інформації 
про різні ситуації в місті для покращення роботи служб міста Черкаси. 
Система мікросервісів
Специфікація 
ЧДТУ 221959.02 
Листів 1 
Розробник:   ________________________    Білозор Д. О. 
Керівник:     ________________________    Метелап В. В. 
Черкаси, 2022 
ЧДТУ 221959.02 
Інструкція користувачеві 
Для запуску проекту необхідною вимогою є наявність: 
• node v13
• postgres v12
• docker
Встановлення: 
npm install 
Запуск: 
npm start 
Ви можете використовувати docker desktop для запуску проекту. В 
перший раз необхідно виконати команду: 
npm run docker:init 
Після першого запуску, в наступні рази слід користуватись командою: 
npm run docker 
Для того щоб запустити міграцію слід скористатись командою: 
npm run docker:migrate 
Для того щоб вставити мок-дані в базу необхідно використати команду: 
npm run docker:seed 
62 
Додаток Г 
Автоматизована інтерактивна система збору та обробки інформації 
про різні ситуації в місті для покращення роботи служб міста Черкаси. 
Система мікросервісів
Графічні матеріали 
ЧДТУ 221959.02 
Листів 8 
Розробник:   ________________________    Білозор Д. О. 
Керівник:     ________________________    Метелап В. В. 
Черкаси, 2022 
ЧДТУ 221959.002 
ЗМІСТ 
Г.1 – Слайд «Сервіс для благоустрою міста» ................................................... 3 
Г.2 – Слайд «Комунікація до CheClean» ........................................................... 3 
Г.3 – Слайд «Комунікація до CheClean» ........................................................... 4 
Г.4 – Слайд «Ціль проекту» ................................................................................ 4 
Г.5 – Слайд «Створення кейсу» ............. Ошибка! Закладка не определена. 
Г.6 – Слайд «Користувач» ...................... Ошибка! Закладка не определена. 
Г.7 – Слайд «Адміністратор» ............................................................................. 6 
Г.8 – Слайд «Адмін панель» ............................................................................... 6 
Г.9 – Слайд «Структура бази даних» ................................................................ 7 
Г.10 – Слайд «Результати роботи сервісу» ....................................................... 7 
Г.11 – Слайд «Отримання подяки від мера м. Черкаси» ................................. 8 
Г.12 – Слайд «Подяка від мера м. Черкаси» ..................................................... 8 
64 
ЧДТУ 221959.002  
Сервіс  для благоустрою міста  Черкаси
 
Рисунок Г.1 – Слайд «Сервіс для благоустрою міста» 
Комунікація до CheClean
 
Рисунок Г.2 – Слайд «Комунікація до CheClean» 
65 
ЧДТУ 221959.002  
Як повідомити про проблему до CheClean
 
Рисунок Г.3 – Слайд «Як повідомити про проблему до CheClean» 
Мета  проекту
Проблема Рішення
 
Рисунок Г.4 – Слайд «Мета проекту» 
66 
ЧДТУ 221959.002  
Як  це працює?
Проблема Чат-бот Адміністратор
 
Рисунок Г.5 – Слайд «Як це працює» 
Модель проекту
 
Рисунок Г.6 – Слайд «Модель проекту» 
67 
ЧДТУ 221959.002  
                 Як користуватись чат-ботом?
 
Рисунок Г.7 – Слайд «Як користуватись чат-ботом» 
 
Рисунок Г.8 – Слайд «Адмін панель» 
68 
ЧДТУ 221959.002  
                 Проблеми реалізації
Chat-bot Backend Hosting Frontend
● Вибір ● Освоєння ● Вибір сервісу ● Архітектура 
фреймворку PostgreSQL для хостингу та дизайн
● Staging ● Докеризація ● Відсутніть ● Освоєння 
● Session бази даних автодеплою Angular
● Зміна ● Робота з ● Стилізація 
фреймворку knex Angular 
● Підключення Material
бекенду до 
боту і 
фронтенду
 
Рисунок Г.9 – Слайд «Проблеми реалізації» 
                 Результати роботи проекту “CheClean”
 
Рисунок Г.10 – Слайд «Результати роботи проекту ―CheClean‖» 
  
69 
ЧДТУ 221959.002  
                 Отримання подяки від мера  м. Черкаси
 
Рисунок Г.11 – Слайд «Отримання подяки від мера м. Черкаси» 
                 Подяка  від мера  м. Черкаси
 
Рисунок Г.12 – Слайд «Подяка від мера м. Черкаси» 
 
 
70