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

І 
МІНІСТЕРСГВО ОСВІТИ І НАУКИ УКРАЇІ-ІИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факу~ьтет інфор!>tаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
Пояснювальна записка 
до КDаліфіка~rій11ої випускної бакалаврської роботи 
з напрям11.-v підготовки 121 "Інженерія npornar.шoгo забезnе•1ення" 
1 (~а шАш<А ріню.) 
на тему: «Автоматизована інтеракпm,,а система збору та обробки інформації 
про різні ситуації в місті лля покращення роботи служб міста Черкаси. 
Система АРІ.» 
Виконав: студент 4 курсу, групи ПЗС-1944 
Напря.му підготовки 
121 "Інженерія програмного забезпечення" 
(шифр і пюаа u211рю,,у ni..v0101ю1) 
Студент Кретов О.В. 
(nрі,ІІШІ.С та і1Uці.1."tМ) 
Керівник Метелап В.В. 
(прі1•кш.с n iuiцia.-uc) 
Рецензент Захарова М.В. 
(nрізаище n U1іціа.1И) 
Черкаси, 2022 
Форма Nt У-9.01 
Д0даток 2 
ЧЕРКАСЬКИЙ ДЕРЖАВНИй ТЕХНОЛОПЧНИЙ УНІВЕРСИТЕТ 
(11а3ва вузу) 
Факультет ---- ----...:..... __~ і~н~ф~о~р~м~а!!.!ц!!!і~й!,!!Н!;.И! ~х~:т!:е~х~1'І~О~л~о~n~·!!Й__!і~с~и~ст:!!:е~м~- -------­
(пов11а 1111303) 
Кафедра nporpaмнoro забезпечення автоматизованих систем 
(повм 113303) 
Освітньо-кваліфікаційний рівень 
Бакалавр 
(назва) 
Напрям підготовки ______ _ _ l~2:..:І~«~І~н!!.ж~еі!н~е~р~ія!....:п~р~о~rр~а~м~н~о~го~з~а~без~л~е:,:;ч~еі!н~ня~»--,-- ----
(WJ1фр і назва) 
ЗАТВЕРДЖУЮ: 
Зав. кафедри програмного забезпечення 
автоматизованих систем 
Пе'рвунінський С.М. 
«. _ _ __»  ------- --- - 20_р. 
ЗАВДАННЯ 
НАВИПУСКНУБАКАЛАВРСЬКУРОБОТУСТУДЕВТУ 
/(ретову Олексаидру Валеитииовичу 
(прізв11ще, t\l'JJ, по батькові) 
І. Тема проекту (роботи) АатQмсш111зова11а і11терактив11а система збору та обробки і11формації 
про різпі {.:итуації а місті для покраще1111я роботи служб міста Черкаси. Система АРІ. 
. І 
Керівник nроеюу (роботи) · Метелап Волод1ІАmр Володимирович 
(прізвище, ш·я, по батькові, науковий ступіm, вчене ЗВЗJшя) 
Затверджені наказом Черкаського державного технолоrічного університету від 
14.02.2019 №S0/01 
2. Строк подання студентом проеюу (роботи) 
07.06.2022 
3. Вихідні дані до проекту (роботи) ___ __. .;;О..псс.ес,,ра'--ц'-і_й1--'_1а е1_1с_п_1-е'-л' _1_а__-_~__ іп_d_о_w_s;;_::_І_О_ ____  
4. Зміст розрахунково-пояснювальної заrшски (перелік питань, що їх належить розробити) 
Вступ, І. Постаиоока задачі, І. І. Актуальиість та а11аліз предметиої області, 
1.2. Обруитуаа111т аибору тех11011огій, І.З. Модеюова1111я предметиої області, І.З. Формуват,я 
13, 2. Проектуаатщ 2.1. П11а11 реалізації проекту, 2.2. Опис го11ов111tХ сутиостеіі, 
2. З. Опис програлших модуліа, 2.4. Проектува1111я користувацького іитерфеіісу, 
2.5. Проектуаатт бази да,111{ 2.6. Проектува1111я архітектури, З. Розробка системи, 
З. І. Розробка бази даиих, З. 2. Опис системи, З.З. Алгоритм роботи фактич,юї програ,111, 
Висиотш, Список 1111користаиої літератури, Додаток А, Додаток Б, Додаток В, Додаток Г 
S. Перелік графічноr·о матеріалу (з точним зазначенням обов'язкових креслень) 
Слтід І <1Ссраіс дю1 благоустрою міста>>, Слайд 2 «Опис тех11іч11их вимог,,, Слаіід З 
І{/(ому11іка11і11 t)o СІ1еС/еа,щ Слm,д -І «І(омуиікація до СhеС/еа,щ Слайд 5 «Ціль проекту», 
С11аі1д 6 «С11тореи11111(еі1,у,,, Слаіід 7 І{Користуаач», Слайд 8 «Адміиістратор», Слайд 9 
.., .-4,i ,юис.1ь,•. C:mil() J0 «Стру,.·111)'/ХІ бази да1111х1,, СлаіІд І І ((Стек в111шр11спш1111х me.r
11111 110110~11 
( •1mi() J] "І',·-.,_ , ~11,111а11111 pofio,1111 сс!JЮісу,1, С?а11д І З ((О111р11,11а,111я 11однк11 від мера міста ~ 
юбопt) із зазначенням 
Pou i:i Консу;rьr.шт 
7 Дата 011дачі завдання __________ .;І....г:~'Р.,~..:::д.1.1.я:;.:...:2...:О...:І..8::.:.1.[.Ю..:...к: у"'-________ _ -
к ІUІСІІдаРІІІІІ1  r1ла11 
}{~ Тср~Іін ВІfІ(ОІ1анJІJІ сm11ів 
І-Іазо..1 ст:шіо to.-ypcoвoro проекту (роботtt) Пр11міn<а 
з/n nоосктv (ooбont) 
І Підготовча стадія 15.01.22 - 30.01.22 В11ко11а110 
І. І А 11а"із 11оставле11оr зада•1і 03.02.22 - 10.02.22 В11ко11а110 
/.2 Піr)гототю завдатт JJ.02.22 - 15.02.22 В11ко11а110 
І.З Погод.1,се,11111 завдатт 15.02.22 - 16.02.22 811ко11аuо 
І.  ./ Заптерд:>1Сс111т за6()а111т 16.02.22 - 18.02.22 В11ко11а110 
2 Ос11ов11а стадія · ' 19.02.22 - 26.02.22 Вико11а110 
2./ Підбір матеріалів 26.02.22 - 28.02.22 Вико11а110 
2.2 А 1/(ІJІіЗ IIIJ/JL'fi(J а11рі111с111т //QCII/O(JJIЄI/Ot' зада11і 01.03.22 - 15.03.22 Викопа,ю 
2.3 Оr/юр,,,11с11111111сроіс11оt'редаю1іІ'робо11111 16.03.22 - 31.03.22 В11ко11а110 
з Зак11юч11а стадін 01.04.22 - 30.04.22 В11ко11апо 
З.І Оr/юрлшетт 11011с111оваль11оі· за,111ск11 до роботи 04.05.22 - 31.05.22 Викопа,ю 
3.2 Затверд:жетт роботи 15.01.22 В11ко11апо 
З.З Рецетуаатт робоmи 12.05.22 В11ко11а,ю 
Студент-диn;юмник Кретов О.В. 
(11різв11ще та і11іціал11) 
Керівник проекту (роботи) Мtтелап В.В. 
(niдro1c) (прізвище та ініціали) 
ЗМІСТ 
ВСТУП 5 
1. ПОСТАНОВКА ЗАДАЧІ 6 
1.1 Актуальність та аналіз предметної області 6 
1.2 Обrрунтування вибору технологій 6 
1.3 Модеmовання предметної області 8 
1.4 Формування ТЗ 9 
2. ПРОЕКТУВАННЯ СИСТЕМИ 14 
2.1 Опис головних сутностей 14 
2.2 Проектування програмних модулів 14 
2.3 Проектування дії системи з точки зору різних користувачів 15 
2.4 Проектування користувацького інтерфейсу 18 
2.5 Проектування бази даних 21 
2.6 Проектування архітектури 21 
3. РОЗРОБКА СИСТЕМИ ТА ТЕСТУВАННЯ СИСТЕМИ 24 
З .1 Опис серверної частини 24 
3.2 Розробка бази даних 27 
З.З Алгоритм роботи фактичної системи 30 
висновки 33 
СПИСОК ВИКОРИСТАНОЇ illТEPAТ УРИ 34 
Додаток А 36 
Додаток Б 38 
Додаток В 52 
Додаток Г 54 
ЧДТУ.221601.007 ПЗ 
Зw. Лист K,дneyue11r.1 Гli1t111tc Лата 
І'01роб. Кретов О.В. 7/Ь Шr. Лист Листіе 
i,П:.с.:р..е:!о:.. :.::.-1.М:с2::т:с.:л..а::л.. :О:...:.О::..:- -1~.,;.;;:,,::.:...+--i Система збору та обробки інформації І 11 І з 60 
. .•. . . I--JL...;.;.L---L___;_......_-='------1 
про р1з11і с11rуац11 в м1ст~ 
Поясюовальна записка ФІТІС 
Н.ко11тр. ІТо:н.ОІі 
кафедра ПЗАС, ПЗС- 1944 
ГІ:nмiiu,oflCM 
ЧДТУ 22 t 965.007 ПЗ 
ПЕРЕЛІК СКОРОЧЕНЬ ТА ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ 
ТЗ технічне завдання 
Бд база даних 
l7ro11t енd Юlієнтська частина проею-у, яка в~обаржасrься у браузері 
Back епd серверна частина проекту, яка взаємодіє із даним БД та ча:r 
ботом 
Паттерн набір правил та ресурсів для струкrуризації розробки 
UМL Unified Modeliлg Laлguage 
НТТР Hyper Text Transfer -Protocol 
АРІ Application Prograrnпung lnterface 
ЧДТУ 221965.007 ПЗ 
ВСТУП 
Система збору даних - в обчисленні і анатзі сигналів перший етап 
обробки даних, що, полягає у накопиченні та підготовці дан.их для 
подальшої обробки 'т а інтерпретаціі Зазвичай система збору даних 
. 
забезпечує перетворення в цифровий код сигналів, що надХодять вщ 
багатьох датчиків та передачу їх на мікроЕОМ через систему зв'язку. 
Благоустрій населених пу~в - комплекс робіт з інженерного 
захисту, розчищення, осушення та озеленення території, а також 
соціально-економічних, організаційно-правових та екологічних заход1в з 
покращання мікроклімату, санітарного очищення, зниження рівня шуму та 
інше, які здійснюють на території населеного пункrу з метою її 
раціонального використання, належного утрт1ан:ня та охорони, створення 
умов щодо захи~ ~ і відновлення сприятливого для життєдіяльності 
тодини довкілля. 
Проект «СІ1еС\еаn» - це серв1с для благоустрою у місті Черкаси, 
яки.й складається з чат-боту в телеграмі, бази даних та веб-сайту, який 
виконує роль адмі1:-t" панелі. Основна мета сервісу - це забезпечення 
швидкої і зручної взаємодії з комунальними службами, та іншими 
адміністративними закладами для вирішення тієї чи іншої проблеми. Ідея 
створення такого сервісу виникла через відсутність прямої комунікації з 
адміністрацією міста. Для того щоб звернутись до представників 
Управління інспектуврння Черкаської міської ради треба надсилати їм лист 
в мережj Facebook або lnstagram. Такий підХід є не дуже зручним та 
оперативним, тому, для покращ~ння цієї взаємодії і було поставлено 
завдання створення подібного сервісу. 
5 
ЧДТУ 221965.007 ПЗ 
І ПОСТАНОВКА ЗАДЛЧІ 
І. І Актуальність та аналіз предметної області 
Після проведення аналізу предметної .області було виявлено, що 
подібних рішень на момент побудови проекту створено не було.· Даний 
сервіс буде перши~, і ~ікальним у своєму роді на момент створення . . 
1.2 Обrрунтування в11бору технологій 
Оцінивши стек технологій, :rадіяних у конкурентних систе.мах, було 
визначено, що будут~ використані нacтyrrni технології: 
- Angular CLI; 
Інтерфейс командного інтерфейсу Angular - це інструмент 
інтерфейсу командного рядка, який ви використовуєте для ініціаJtізаціІ, 
розробки, побудови ескізів та обслуrовуваНWІ програм Angular 
безпосередньо з командної оболонки. 
- Dockeг•  
Docker - програмне забезпечеmtЯ для автоматизації розгортання та 
керування програмами в середовищах з шдтримкою контейнеризації, 
контейнеризатор додатків. 
- Кnex.js; 
Kнex.js - це конструктор SQL-запитів «в комплекті з батареями» для 
PostgreSQL, CockroachDB, MSSQL, MySQL; MariaDB, SQLiteЗ, Better­
SQLiteЗ, Oracle та Amazon Redshift, розроблений таким чином, щ9б бути 
гнучким і портативним. Він містить як традиційні зворотні виклики в.стилі 
~ 
вузлів, так і інтерфейс обіцянки для більш чіткого керування асинхронним 
потоком, інтерфейс потоку, повнофункціональні конструктори запитів і 
схем, підтримку транзакцій (з то<JКами збереження), об'єднання з'єднань і 
стандартизовані відповіді між різними клієнтами запиnв I д1алектами. 
- Javascript; 
JavaScript - мультипарадиrменна мова програмування. Підтримує 
об'єктно-орієнтований, імперативний та функціональний стил1 . Є 
реал1зац1єю специфікації ECМAScript: JavaScript зазвичай 
6 
ЧДТУ 221965.007 ПЗ 
в11~-ор11с~'Овуєт1,ся як _обудооана мова дл.я програмного доступу до об'єктів 
ІІJ)ОІ"І):lМ . 
- PostgreSQL; 
PostgreSQL - це вдосконалена реляційна база даних з відкритим 
кодом корпоративного класу, яка підтримує~ запити SQL (реляційні), так 
і JSON (нереляцій:ні). 
- ESli11t; • 
ESІi11 t - це інструмент, який перевіряє стилістику коду, відповідно до 
обраних правил . ESLint статнспrчпо аналізує ваш код для. швидкого 
пошуку проблем. ES1:,i11t вбудований у більшість текстових редакторів, і ви 
можете запускати ESLint я.к частину конвеєра безперервної інтеrрації.[15] 
- Git; 
При створенні проекту на стадії реалізації з'являється необхідність У 
керуванні змінами у коді. Для цього було прийнято рішення, що необхідно 
використовувати технологію дпя реалізації цієї потреби. Нею є Git. Ця 
система дозволяє ~іксувати зміни, тобто робити коміт, надсилати 
зміни(коміти) у репозиторій. Реnозиторій - тека із програмним кодом, до 
якого підключений git . Він можу бути як локальним так і віддаленим, 
тобто залитим у хмарне середовище і бути закріпленим за одним із 
сервісом дпя віддаленого керування репозиторіями такими як: GitLab, 
GitHub, BitBucket тощо. 
- Express 
Фрсймворк wеЬ-додаткіn дпя Node.js, · реалізований як вmьне та 
відкрите програмне забезпечення під ліцензією l\1IT. Він спроектований 
. f 
дпя створення веб-додатків та АРІ. Де-факто є стандартним каркасом 
Node.js. 
- Ht1sky; 
Хаскі 11окращує ваш1 зобов'язання та багато ~ншого. Ця бібліотека 
перевіряє код на помилки перед тим як робити фіксацію змін у коді або/та 
при надсиланні комітів на віддалеRИЙ сервер. 
7 
--
ЧДТУ 22 1965.007 ПЗ 
- NPM: 
NJ>t\,t - н..: мс11енжер r~акетіо для Node.js. Він бу~ стоорени~і у 2009 
роні як нро~кт з в ідкр111·11м 1<0дом, щоб допомогrи розробникам JavaScript 
Л~І' Іі:О ДІЛ ІІТ1 1СЯ у1щкочаними МОДУЛЯМИ коду. 
- Trello; 
Trello - хмарна програма для керування проектами невеликих груп, 
розроблена Fog Creek Software. Trello використовує парадигму для 
уnравтння проектами , відому як канбан, метод, який спочатку був 
популяризований Toyota в 1980-х для управління ланцюжками постачання. 
Після опису вимог у ТЗ інс'Ірументи розробки мають працювати 
спільно наступним чином : розробляються завдання у ресурсі TreUo після 
чого WЕВ-розробник має відповідно до · своєї картки реалізувати . 
поставлене в ній зав~ання. Для цього він створює репозиторій у GitНub, 
паралельно із тим створює локально теку для back-end частини, де створює 
необхідну файлову систему, ініцjалізує систему git, після чого створює 
проект АлgнІаr за допомогою команди ng new project-name. Під час 
генерації проекту Javascript та генеруються стандартні ESlint. Після 
розробник додає за допомогою NPM бібліотеки Husky, Кnех, Docker. Після 
підключення всі файли перевіряється на наявність -помилок у синтаксисі. 
Якщо є необхідність, то файли, конс11)укції, тощо регулюються у файлах 
налаштування конфігурації ESlint. Після налаштування залежностей та. 
правил користувач рабить перший коміт і відправляє його набором команд 
у віддалений репозиторій. Перед тим як відправити дані, спрацьовує Hнsky, 
який запускає команду для перевірки стилістичних помилок у _коді . Якщо 
він доступний іншим користувачам, то вони . автоматично можуrь 
відстежувати діяльність власника репозито1ю чи тих, хто також виконує 
зміни у коді на WЕВ-сторінці проекту. 
1.3 Моделювання предметної області 
Було вирішено, що сервіс буде складатись з 11)ЬОХ основних ~астин: 
телеграм чат-бот, база даних та веб-сайт. Алгоритм користування повинен 
8 
ЧДТУ 22 1965 .007 ПЗ 
"а111 11:н:ту111111іі n111·лsщ : І<ор11стуоа•1 заходи·п, в •~ат-бот, заповнює зt1яоку, 
я t-:1 tІІu,ючnс O себе ТСІ<стооий опис, фотографію та гео1юкацію. Після 
JаІІОІІІІt.:ІІІІЯ д;\ІНtх буде можливість редагуват~ і підтвердити. ДалІ заявка 
збері1,н.-ться У базу, да11их та буде доступна на веб-сайті сервісу. 
Корнстуоач отримує rюсилання на щойно створену заявку і переходить по 
ньому для перегJ~яду. Сайт містить с11исок всіх заявок, для кожної заявки є 
відповідний статус, є можливість фільтрувати заявки в залежності від 
статусу. Також на сайті представлена загальна мала заявок з 
інтерактивними точками з різним кольором, кожному кольору відловідає 
свій статус. База даних 110винна бути завернута в контейнер за допомогою 
Docker. Повинна бути реалізована логіка пагінації для фронтенду. За 
допомогою Knex потрібно створювати таблиці в базі даних. Пови1-іні бути 
створені сервіси : rео~дер, постгрес сервіс, сервіс заявок. 
1.4 Формува1111я ТЗ 
Технічне завдання - це інструмент, я.кий дозволяє приоес-_ги бажаІ{НЯ 
КJJієнта У відnовід11іс~1, із можливостями розробника і здатний орегуmовати 
всі можливі конфлі1сти та заощадити час. Безумовно, технічне завдання 
визна•1ає коло завдань, які слід виконати під час створення цього веб-сайту. 
Необхід110 надати розробникові структуру веб-сайту якомоr·а 
дет-альніше і пояснити, як повинна виглядати остаточна ·версія . 
В ідеальному випадку осі деталі роботи та зовнішнього вигляду 
~ . 
ПОВИННІ бути зазначею в технічному завданні, таким чином 
невідповідності будуть мінімізовані, а результат відповідатиме вимогам та 
0•1і1<уванням замовника. В якості замовника виступає УправлінRя 
інспектування Черка<;ької міської ради. 
І Опис технічних вимо1' 
Для користувача серв1с повинен включати у себе наступний 
функціонал: 
можливість правки редагування кориGТувачем; 
можливість попереднього перегляду; 
t 
9 
ЧДТУ 221965.007 ПЗ 
- можл1шіст1, оз1111ііом1,,-11с1, зі uсіма заяоками; 
- мож,111шіст1, 11среrлядап1 ~1апу із заявками. 
Для "ОJ>ІІстуоача сервіс пов~1не11 включати у себе наступний 
ФУ" кuіо1-1ал : 
реалізації авторизації на сайті; 
- можливість видалення заявки; 
можливість змі11и статусу заявки; 
можливість залишати коментар; 
можливіс1·ь Ііереrлядати мапу із заявками. 
Функціонал для адміністратору повинен бути дос1упним лише після 
авторизації. Користува<1 може лище переглядати сайт і нічого б~ьше. 
Функціонал сутностей має rрунтуватися на шаблоні CRUD(Create 
Read Update Delete). CRUD Значення: CRUD _ це абревіатура, що походить 
із світу комп ' ютерного програмування і стосується чотирьох функцій, я:кі 
вважаються необхідними для реалізації постійного сховища для зберігання 
даних: створення , читання, оновлення та видалення. Постійне сховище - це 
будь-який пристрій зберігання даних, який зберігає жи:влення після ­
вимкнення пристрою, наприклад, жорсткий диск або твердотілий 
накопичувач. Навпаки, оперативна пам 'ять та внутрішнє кешування є 
двома прикладами енергонезалежної пам 'яті - вони містять дані, які будуть 
стерт1 , коли вони втр~тять силу. 
Згідно із переліком пункту 1.2 першого роздmу, маJоть бути 
використаю технології: AngularCLI, JavaScript, Node.js, Кnex.js, 
PostgreSQL, Docker; та інструменти розробки: ESlint, Git, Husky; NPM. 
Огляд продукту з точки зору різних типів користувачів 
Детальніше про доступний функціонал користувачам див11сь у 
• • 
розділі другому підпую<Ті №2 .4 . 
Архітектура має бути розроблена із вИІ<ористанням уже розроблених 
шаблонів спільнотою програмістів або базуватися на них. 
10 
ЧДТУ 221965.007 ПЗ 
Для роботи із системою на ПК .необхідно мати ОС, яка підтримує 
ocr.\ІІttIO версію Telegra111 та любий браузер ~ном на 0.1. 06.22. Для роботи 
зі смартфо11у 11а платформі Aлdroid чи ІОС вимоги аналогічні . Тільки для 
кор11стувачів для оикористання програми необхідно мати останюо версію 
системи , щоб додатоr< працював коректно. 
2 Особливості дизайну 
Дизайн має бути інтуїтивним і семантичним, відповідати шаблонам 
UI та UX. Елементи інтерфейсу мають повторювати форми логотипу і усі 
кольори мають гармонійними. Також мають бути розроблені шаблони усіх 
сторінок та форм під різні розміри екранів, за основу має бути взята 
ширина екрану - 375 пікселів 640 пікселів ' 10.2 4 пікселів та 1440 пікселів. 
' 
Допусr<ЗJОТІ,ся пропуски на шаблонах офіційного сайту та формах 
авторизації та реєстrJації. При реалізації дизайну сторінок допускаються 
розбіжності. 
Перед тим як почати процес проектування системи, тр~ба скласти 
план реалізації, яки~ вю1ючає у себе дані про дні на виконання, даних 
початку та завершення задач з переліком ресурсів, необхідних у процесі, 
відповідно до можливостей реалізаторів . Так як є частини, які не можливо 
реал1зувати, якщо не має вже готового функціоналу, то вони будуть 
побудовані із включенням цієї залежності . 
Для простішого сприйня1,·я що за чим має реалізовуватися , було 
обрано систему пості~ювки завдань Trello, де кожен виконував поставлені 
йому завдання. Треба розробити схему планування задач із розподілом з 
приблизною кількістю rоднн на виконання. Задачі будуть розбиті на 5 
категорій підзадач: 
Backlog - задачі, які треба зробити; 
fl) progress - задачі, які виконуються на даний момент; 
ТесІ11·eview & Testiнg - виконані задачі, які проходять оrляд чи 
тестування; 
Done - виконані задачі, які пройшли огляд чи тестування .. 
~ 
11 
ЧДТУ 221965.007 ПЗ 
l11fo - окремі інструкції для ведення розробки (див.рис. І. І)~ 
1:.1 git branch name format 
8 ~•<Р J.::lD 
8,anc.h ro muit 
fo/( t • <Іid«1 _oo-n:,)i("() _b.J9_ d<--',,,a1p;,icn 
rtW..t'/CC- <ti<.i.'tt_frJП'\~) Jt.11V'("_t\i,1,tt·~ 
ь..mр1~ 
T,oUo t.c"-"' CC ·S ,\Ь<Му to 6dd uw и""9"'У 
Сч, Ьr«cl< ft,1turt'./"·S.~(Jd_c.u~_«>t"9"'Y 
Ри~ун6к І .1 - lнрукція щодо форма-rу імен гілок в github 
Карточка із завданням має нас-rупний вигляд (див.рис.1.2): є 
загальний опис завдання, яке цотрібно виконати, якщо си-ууація потребує, 
встановлений дедлайн на виконання цього завдання. Нижче знаходяться 
пункти, які треба виконати, по мірі їх закритrя, прогрес ви1<онан.ня 
збільшується . 
В таблиці 1.1 наведено перелік основної роботи, яку треба в}:іконати 
для реалізації поставленого завдання. 
t 
12 
ЧДТУ 221965.007 ПЗ 
Q СС · 1 o , tJbase Sctup х 
11
• •\І <,•1 • 1 y.'v~\'\J t,JІJr;t"j~~:(pnC\."1,_~~UN11' • fYJ"~tt1.:..ny 
1Ltt,-JJ \_~ .-J,.,..,,"'1 <••т.~ .. ....,,..1,,~ You )toJdtflt 1JfQC.t.,{A..1y.-2a,~ 
S-0.L t 0-1•""--""V, to ~r,t.v,d )1.Q\-. 11 -o,U, 
\ ',1'-1. •• ~'І;)І.J ft<t )V\.,\C- '~"' \\ \L"i U"° <~~; U.:, q".r.,м f.o,_.. 10 с.оrФ~ • dЬ. 
)\),l •h(v 1 Щ•~,.., ncl'W l'fo•Vf (!А~~ wr.h L-'\r.Jl:l,к f)01 t9'~ thr,c. У:., U-.0,UU 
1((U".-' .. . .. t(.\oll).tntl ~ .tU.' . -.-.ttt:$rt с~ d.ti.Ь.и V-• • g0tt \\·"-cny:,u~11 .м. t&. 
tC\fV, f(1 tG ~ c1r,(',f.f d.\:.)h.)~• ffeln \\'nd,;>-.-A,. )'О,І "(J t'tf, ,.:,4у t0 i.ftUP VU,.JI JS 
<.uJ,: 
В Sotup Progross 
~- -1--o;. ..-... 1-""=-r--·-·~-""=-~- ------------ 0 
r'J ,,.. .,  , .........., :Т..."')'°fі,➔ "'-::~ ' , lf'~~t,.-11.rton.\l-f,if(o + Д:,6,,о,,r.""""У 
,.,,...,,.tn,f\-:r--.. 
r:, f-,, vt•-• ,••~t~'--114.otН-&f;--fitiM·e"d~ ;;1► о·..+, · .. 
lj()t_ ftr.:-"t,.: 
12 ~-.)t•-I U~-xt..., en -Jн•,~'ottll"d t,:м,t "'°"~ О l~.tm ~_, t~•twt 
· Риtунок 1.2 - Структура карточки завдання 
Таблиця 1.1 
Налисати міграцію на створення таблиці ЗІ вс1ма необхідними 
командами 
Ство ити сіди для наповнення бази 
ose 
Ство ити логіку озбитrя 
ІЗ 
ЧДТУ 221965.007 113 
2 ПРОЕІ<ТУВАННЯ СИСТЕМИ 
Проектування ~ю1адаєт1,ся із послідовних дій : опису головних 
супюстей, формування на їх основі головних та вторинних nрограмнJіХ 
модул~в, опис взаємодії р1зн11х тишв користувачів 1з системою, 
nросктува,шя користуваць1<ого інтерфейсу, після розробка архjтектури на 
основ, модулів I вимог до інтерфейсу користувача відбувається 
проектування бази даних . Усе це включає у себе план реалізації проекту. 
2.1 Опис головtшх сутностей 
Як було зазначено в пункті ] . І аналогіч~их сервіоів комунікації поки 
11емає. Тому струкrура даних заявки має наступний виrляд: 
id. Обмеже1н11Я: priinary key. Тил даиих int. 
опис. Має буrи ти11у striпg. Обмеження: максимальна кmькість 
символів 500, комірка не може буr-и порожньою (поt щ1ІІ). 
- локація. Тип даних роіпt (latitнde, loogtitнde) . Обмеження : 
максимальна кількісп, символі~ 500, комірка не може бути порожньою (oot 
nнІІ). 
адреса. Має бу1·и типу striпg. Обмеження: максимальна к~л,,кrсть 
символі о 400, 1<омірка не може бути порожньщо (oot ,шІІ). 
- нrІ фотографії. Обмеження: максимальна юльюсть симвотв 500, 
комірr<а не може буrи~порож111,ою (oot пuІІ). 
статус . Має буги І або О. За замовчуванням - О. 
дату і час створе11ю1 заяв1<и формату: DD/:ММ/УУУУ, Н}І:ММ. 
2.2 Проекту~ання програмних модулів 
Опис продукту вюuо•1ає у себе перелік очікуваних до реалізації 
модутв, архітекrурні вимоги, вказшку пріорітетів розробки, опис 
технологій, які знадоблятr,ся при розробці, а ~кож огляд продукту з різних 
точок зору. Всі пункти можуrь включати у себе діаграми та схеми, для 
ліпшого розуміння та уявлення як система має працювати. 
. ' 
Основними програмними модулями є: 
- Веб-сайт, який виконує функцію адмін панеЛІ та набору заявок, 
14 
ЧДТУ 221965.007 ПЗ 
досту111111х ш1я 11сре1·ляду. 
І 
- Чат-бот о телеrрамі, який виконує функцію збору інформації від 
користуоачіо, тобто створення заявок. 
- База дат1х, · в якій зберігається вся інформація, яку надали 
користувачі. 
Сервіс має бути реалізована 1з застосуванням задіяних технологі й 
(див . Таблиця 2. 1) 
Таблиця 2. 1 
п еоел1к заnланова 11их теu1ологій та iнcтnvмeuni до викона1tt1я 
РозробнІіцька Перел ік запланованих технолоrій та інструменти ДО 
часина системи використання 
Сайт (fro11tend) Aлgular CLI, Node.js, JavaScript, NPM, ESli11t, Git, 
Hнsky. 
База даних JavaScript , Node.js, PostgreSQL, Docker, NPM, ESlint, 
(backe11d) Git, Husk.-y, Knex 
Серверна JavaScript, Node.js, Express, ESlint, Git, Husky, 
частина 
• 
2.3 Проек-1ування дії системи з точки зору різн11х типів 
користувачів 
Основними типами користувачів є гість і авторизований користувач, 
тобто адміністратор. Авторизація - перевірка, чи може користувач 
виконувати певн і дjї (їх часто позначають як ресурси). 
15 
ЧДТУ 22 1965.007 ПЗ 
Відкрити чат-бот 
Натиснути на 
створення нової 
заявки 
Надіслаn-, текстовий 14-------, 
опис 
Надіслати фото 
Надіслати 
геолокацію 
Так Ні 
Отримати посилання 
на створену сторінку 
заявки 
Рисунок 2.1 - UМL діаrама діяльності користувача боту 
16 
ЧДТУ 221965.007 ПЗ 
Пtpe:r.;.1. uan11 3 Переrг.:щ cn-,acy 
fіО-\ё'Щ~ 3аРЄО"l ВЩОІQЮІХ 3ilP-SOf. 
Рисунок 2.2 - UМL діаrама діяльності адм_іністратора 
о 
о 
о 
Рисунок 2.3 - UМL діаграма послідовності для користувача 
17 
ЧДТУ 221965.007 ПЗ 
[ ~--~и•~ J [ ._,_,~,;, 1 ( ~о,...., 
t~о.шо· '[] 
а о 
о· о 
Рисунок 2.4 - UML діаграма послідовності для адміністратора 
Як зображено на рисунку 2.3, користувач створює заявку за 
допомогою відправки текстового опису, фотографії та локації. Після того, 
як дані зібрано, у користувача є можливість підтвердити або редаrу,вати їх. 
Після підтвердження,•  він О11)имує посилання на сторінку звернення на • 
сайті, де може її переглянути. 
Авторизований користувач, тобто адм1юстратор, має достуn до 
адмін панел і , де може робити наС'І}'пне: 
міняти статуси заявок; • 
видаляти заявки; 
залишати коментар ПІд заявками; 
2.4 Проектування користувацького їнтерфей_су 
Основними вимогами до проектування ·користувацького інтерфейсу 
є: 
Адаптованість. Це означає, що інтерфейс повинен бути: 
- сумісним з потребами та м~жливостями користувача; 
- забезпечувати простоту переходу від виконання однієї· функції до 
іншої; 
18 
ЧДТУ 221965.007 ПЗ 
І 
- забсз11ечу11nти 1<ористуоача нn високому ріоні вказівками стосовно 
itoi-o можливих дій, а також генерувати належний зворотний зв'язок на 
itoro зап~пи; 
- шщавати 1<0ристуоачу можлиu1сть в1дчувати себе новноnравним 
керівником ситуації при розв'язанні всіх тилів задач, тобто, забезпечувати 
його всією необхідною інформацією; користувач повинен бути впевненим, 
. , 
що в1н сам розв язує поставлену задачу; 
- забезпечувати користувача різними, взаємно доповнюючими 
формами представлечня результатів в залежності від типу запиту або від 
характеру отриманого рішення; 
- враховувати особливості користувачав р1зних равюв; наприклад, 
для керівника підприємства зручнішим є узагальнене графічне ставлення 
результатів роботи ·системи підтримки прийняття рішень+ у вигляді 
діаграм та графіків, а інженеру-економісту потрібні конкретні цифри у їх 
часовій послідовності. 
Достатність інтерфейсу означає таке: 
допустим і запити користувача повинн1 бути ч1ткими 1 
однозначними для. користувачів всіх рівнів, а також для прикладних задач 
. . 
ВСІХ ТИПІВ; 
- реакщя системи 11а в~1 типи запит1в також повинна бути 
. . . . 
однозначною I зрозум~лою 1, по можливост1, простою. 
Дружність інтерфейсу 
Це максимальна простота його використання і готовність в повній 
мірі задовольнити запити користувача при розв'язанні визначеного класу 
задач . 
Гнучкість інтерфейсу 
Гнучкість інтерфейсу - це можлив1сть його адаптування до 
розв'язання кон1<ретної задачі . Якщо розв'язувана задача дуже складна, то 
інтерфейс повинен полегшувати формулювання запитів I видавати 
результати у форм і , яка легко і швидко сприймається користувачем . Тобто 
19 
ЧДТУ 221965.007 ПЗ 
і111-срфсіtс повинен буди макс~1маль110 простим нав1ть у випадку, коли 
розо 'язується дуж~ складна задача . При цьому простота означає таке: · 
• 
- інтерфейс не повинен бути перевантажений деталями щодо 
представлення розв' язку поставленої задачі - користувач може ве охопити 
всіх подробиць (і в цьому, як правило, немає потреби) - тобто нічого 
зайвого, крім того, що необхідно д1ІЯ розуміння результату; 
- в1н не повинен містити зайвих декоративних деталей, ЯКІ 
відволікають від головної задачі ; 
- інтерфейс повинен бути консистентним, тобто, грунтуватись на 
використанні відомих, загальноприйнятих методів і засобів представлеrmя 
інформації; 
t 
- в ідеалі процес взаємодії користувача з системою не повинен 
представляти ніяких труднощів. 
Користувацький інтерфейс має бути розробленим у 
мінімалістичному стилі . В основному будуть використовуватись чорно­
білі та зелені кольори. 
Чорний колір - потрібен для більшості ююпок та тексту на сайті. 
Зелений колір - потрібен для виділення поточного елементу меню. 
Сторінки до реаліазції: головна сторінка, список всих заявок, еїорінка. 
авторизації, мапа · зЩІвок . Всі сторінки повинні бути адаптивними під 
любий екран і виглядати однаково нормально як на екрані смартфону, так і 
. ' 
на екран~ комп ютеру. 
Ни)І,.-че представлені діаграми дій користувачів_ та адміністратора. 
20 
ЧДТУ 221965.007 ПЗ 
Рисунок 2.5 - UМL діаграма д~й користувача 
Аsтор11зація 
В11далення 
Admin~ • заявки 
Залишення 
коментарю 
Рисунок 2.6 UМL діаграма дій адміністратора 
2.5 Проектування бази даних 
Для реалізації бази даних було обрано PostgreSQL. Структурно база 
повинна представляти собою таблицю, в якій зберігаються дані звернення, а 
саме : текстовий опис, url фотографії, адреса, статус, дата та rеолокація. 
Локація представляє собою дані про широту і довготу, на початку 
розробки ці дані зберігались в 01<ремих стовпцях, що є не досить зручно 1 
правил ьно. Після оз1-1айомле1-11-1я з типами даних в SQL, для збереження.локації 
21 
ЧДТУ 22 1965.007 ПЗ 
(іуо обр:1111 1іі п111 дr11 111х роі111 , тому-що оі11 представляє собою структ-уру і.з 
дci-i.tн,i-ox 1юліu і uи1сорнстооуст1,сн д.пя збері 1·а11ня да~н,х широти і довготи . 
Тскстоо11іі опис 11робJІеми має обмеження на 500 символів, тому для 
111,ого слід ви~<ористнти va1·cliar(500). Для url фотографії також буде 
011користовуватись vзrcl1ar(500). Та~<-як дані про адресу не характеризується 
дос11ть довгим описом , .дп, них слід використати varcbar(400) 
Також в таблиці слід зберігати дані про статус звернення, який буде 
представлений у виr·ляді І або О, та дату створення звернення. 
2.6 ПроектуванJІя архітектури 
Усі частини системи повинн1 відповідати певному шаблону 
. проr-рамування. Це типовий спосіб вирішення певної проблеми, що часто 
зус11>1чається при проектуванні архітектури програм, необхідний для 
стандартизації коду, зменшення часу на розробку, полегшення розуміння 
програмного коду. 
На відміну від готооих функцій чи бібліотек, патери не можна просто 
взяти й скопіювати в nро,·раму. Патери являє собою не якийсь конкретний код, 
а загальний принциг, вирішення певної проблеми, який майже завжди ч>еба 
підлаштовувати для потреб тієї чи іншої програми. 
Описи шаблонів зазвичай дуже формальні й найчастіше складаються з 
. таких пункт~ в: 
проблема, яку вирішує naтepн(pattem); 
мотивація щодо вирішення проблеми способом, який пропонує 
патерн; 
Сll)уктура ·клсtсів, складових рішення; 
- приклад однrєю з мов програмування; 
- особливості реалізації в різних контекстах; 
- зв'яз1<и з іншими шаблонами. 
Back-end частина має бути використана вбудована архітектура 
· фреймворку. Дана архітектура підтримує мікросервісний архітектурний стиль 
розробки . 
22 
г ЧДТУ 221965.007 ПЗ 
MICROSERVICt 
І 
' 
~ 
Рисунок 2. 7 - Схема взаємодії мікросервісів 
Програмний код клієнстської •1атин.и повинен відповідати патерну МУС. 
МУС Pattem розшифровується як Model-Vie\v-Cootroller Pat1em. Цей шаблон 
використовується для відокремлс1тя частил програми . 
Модель(МоdеІ) - модель представляє об'єкт або JAV  А POJO, що містить У 
собі опис полів сутності . Він також може 111ати логіку дня оповлен.ня 
контролера, якщо його дані змінюються. 
Перегняд(Vіеw) - подан ня представляє візуалізацію даних, що ·містять 
модель. 
Контролер(СопtгоІІсr) - Контролер діє як на 11юдель, так і на вил1Яд. Він 
контролює потік даних в об'єкт 11юде~ і та оновmоє даю для перегляду, коли 
вони змінюються. Таким чином view та модель відокремлюються . 
Основними заnда_инями бекенд частини сервісу є реалізація серверної 
. частини, конфігураuія бази, докеризація. Потрібно створити postgres сервіс 
який буде керувати отриr.1аними даню.ш для БД, також треба обрати 
конструктор запитів для роботи з базою, в даному проект~ для цього буде 
використовуватись knex.js. За його допомогою потрібно реалізувати всі 
необхідні запити, для · побудови розбиття на сторінки. Всі сервіси повинні 
експортуватись в один файп. Весь проект, не тільки база даних, повинен 
залускатись за допомогою докеру . Дня запуску слід створити команди 1 
протестувати на роботоспособкість на іншому комп'ютері. 
23 
ЧДТУ 221965.007 ПЗ 
3 РОЗР..О БКЛ ТА ТЕСТУВАННЯ СИСТЕМИ . 
3.1 01t11c ccpucp1101 •~аст111111 
Г>уло створе но ОІ<ремі реrюз~~торії дJtя &o11 t епd, back end та телеграм-боту 
, 1 :1ст1111 ссроісу . Вон ~1 були об ' єдна ~, і рамкамJі проекту 8 сервісі для керування 
версіnм11 - GitHнb. 
Gул .1 рсал ізооана 11астуn11а файлова система: 
• 
Рису11ок З. І - Файлова структура back end частини 
24 
... 
ЧДТУ 221965.007 ПЗ 
Таб  лиця 3 .І  
нuзва модvля/mаііла On11c/ ор11з11ачс1111я 
CheClean-\020.png 
Лоrотил CheClean 
20220512183034 create cases table.is Кnех міrрація на створення таблиw 
0l_cases.js Seed файл для наловненНJІ бази 
даних 
case.mocks. is Mock дані звернення 
cases.service.js Головний сервіс для роботи зі 
ЗВеDНСННЯМИ 
Файл експортування сервісів для 
services/index.js подальшоrо їх використання в 
сеDвеDній частині пооrрамв 
postgres.service.js Файл підключення конструктору 
запитів 
index.is Головний <Ьайл проrрам:и 
Файл, який містить інформацuо про 
.dockerignore те, які файли повинні іrноруватись 
контексто~1Dосkеr'у 
.editorconfig Правила узгоджених стилів 
коnvвання 
.env Файл в якому зберіrаються паролі та 
лані для підЮІючення бази 
.eslintrc.js ПDавила стилів коnvвання Eslint 
В цьому файлі знаходиться перелік 
.gitignore файлів, які повинен іrнорувати 
github 
docker-compose. ym1 Файл для налаштування служб 
проrрами 
Dockerfile Конmіrураційний <Ьайл для Docker 
knexfile. і s Конd>іrураційний <Ьайл для Кnех 
Файл, який представляє залежність 
верхнього рівня з інших пакетів за 
package-lock.json 
допомоrою семюпичноrо 
vпщuшіння версіями. 
Містить інформацію про 
package.json 
залежності, метадані та скоиnти 
READМE.md Файл - інстоvкція 
Для реалізації були використані наступні технолu1'ії: JavaScript, Node.js, 
PotgreSQL, Express, Клех, Docker. Окрім цього були застосовані засоби 
розробки : NPM, ESl int, Git, Husky. 
25 
- _ _ _ _ 4 
- - - - - - -
ЧДТУ 221965.007 ПЗ 
Архітектурно, bnck-cnd чnспsна складасться із мікроссроісів, 11кі 
иnходя1uся У д~1рскторії scr-vices. 
Вони використову1оться у всіх модулях, бо кожен модуль мас НТГР запити, 
оні яких мають перевіря1оться uідповідно описаних у попередніх розділах 
бмсжеиь. Такі перевірки даних оідбуоаються при заm1тах нrrР  POST та PUT 
аnитах, оскільки такі зnпити маю тіла із даними, що мають зберігатися •rи 
оновтоватися У базі даних. Длs1 того, щоб сервер не падав від помилок 
взаємодії із базою даних. 
Серверна частина була зроблена за допомогою exprcss: 
Рисунок 3.2 - Реалізація за допомогою Express 
Body-parser - це бібліотека npm, яJ<а використовуєrься для обробки 
даних, надісланих через тіло залиту НТГР. Він надає чотири експрес-проміжні 
програми для аналізу тексту, JSON, закодованих URL-aдpec і необроблених 
даних через тіло запиту Н1ТР. 
CORS - це функція безпеки браузера, ЯJ<а обмежує НТГР-запити м1ж 
джерелами з іншими серверами та визначає, які домени мrооть доступ до ваших 
ресурс~ в. 
26 
ЧДТУ 22 І 965.007 ПЗ 
Р1tсунок З · З - р сал1· зuц1•я  за допомогоІО Exprcss 
детальніше з запитами та  методами можна ознайомитись в додатку Б. 
3.2 Розробка баз11 дn1111х 
База даних представляє собою таблицю cases. Беручи за основу основні 
доні, які надсилатиме користувач, було створено наступну структуру: 
cases 
Іс:І pnmaІY key 
c:Іetails varchar(SOO) 
tocauon point 
a(l(lress varcnar(400) 
image_url vard'lar(S00) 
status int 
createc:І_at timestamp 
Рисунок 3.4 - Структура бази даних 
База даних була створена на основі PostrgeSQL, та контейнеризована за 
допомогою Docker. Всі запити виконувались за допомогою Кnех. Для цьоrо 
треба було ств.орити спеціальний постгрес сервіс та knexfile: 
27 
ЧД'ГУ 221965.007 ПЗ 
Рисунок 3.5 - Постгрес сервіс 
Всі дані для nідкmочення зберіrа.~оться в .env файлі, що ВИКJDочає 
можливість пjдключення зі сторони. 
Рисунок З.б - knexfile 
28 
ЧДТУ 221965.007 ПЗ 
Таблиця 3.2 
Табл11ця заявок (cascs) 
cascs 
НІІ3011 поля Т110 даш1х формату SQL Оrшс r1om1 
id Prirnary key УніІ<аJІЬІ[ИЙ ідс1пифікатор КОЖІІОЇ 
заяоІ<И 
details Varchar(500) Текстовий опис проблеми 
Jocation Point Геолокоція (latitude, longtitudc) 
addrcss Varcltar(400) Адреса локації 
in1agc_url Varcl1ar(500) Посилання на фотографію 
status i11t Статус заявки, І або о, за 
замов•rVІ•а1шям О 
creatcd_at timcstamp Дата створення заяокиіі 
База даних була реалізована за допомогою інструменту Datagrip, де було 
створено окремий сервер для неї та безпосередньо базу даних із таблицями, що 
були описані У попередньому розділі, вкmочно із усіма таблицями. Створення 
бази даних було за допомогою інтерфейсу інструменту. Створення таблиці було 
реалізовано за допомогою Кnех. 
Таким чином було реалізовано наступні таблиці: 
const knex = require('knex'); 
/** 
* @param {knex} knex 
*/ 
exports.up = function(knex) { 
return knex.schema.hasTable('cases').then((exists) => { 
if (lexists) { 
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: 
б }).defaultTo(knex.fn.now(6)); 
} ) ; 
} 
}); 
29 
ЧДТу 221965.007 ПЗ 
}; 
exports.down = function(knex) { 
return knex.schema.dropTabl (' 
}; е cases')•,  
З.2 
3.3 Алгоритм роботи ф ~ 
акт11чно1 системи 
Чорний колір - потрібе . · 
н для бшьшості кнопок та тексту на сайт~. 
ений колір - потрібен для вид· . 
ЗeJJ ІЛення поточного елементу меюо. СторlНКИ до 
еаліазції: головна сторінка'  сnисо..,".Р '  . 
ВСЮ( заявок, стор1нка авторизації, мапа 
3а,твок. Всі сторінки повинні бути адаптивними під любий екран і виглядати 
однаково нормально як на екрані смартфону, так і на екрані комп'ютеру. 
І 
,. ..... " 
- ----- -- о-.- 
3м•у ут~_, смt"ц~ 
· ~ ~:~)~._.___ н~~~и~rме,о,о 
~."'t:»IJt~І•~-
••_--,".-_."."_- -----••~-»-_. 
Рисунок 3.7 - Головна сторінка 
При першому вході на сайт сервісу благоустрою коритсувач потрапляє 
на головну сторінку офіційного сайту. 
Головна сторінка представлена у вигляді списку всіх заявок. Зліва 
представлено меню навігації, де можна перейти на сторінки нових заявок, 
завершених та на мапу заявок, де можна побачити місцезнаходження кожної 
заявки і інтуїтивно зрозуміти її статус. 
зо 
ЧДТУ 221965.007 113 
дня тоt"О щоб озщ1йо11нп11 с~, зі змістом зоер11с111111, трсбu 11nтис11уrи 
110111-у «Дстал~,нішс», після 'ІОго оідt<риється сторінка зш1оки. 
[email protected]о-
..- --~ .. --·-·-·-·-
Q 
.- .. 
..... ... ""'. 
. .. 
Рисунок 3.8 - Сторінка заяв1<и 
Якщо сайтом користується адміністратор, в нього є змінювати статус 
заявки, за допомогою кнопок зверху зправа (див.рис 2.5), та видаляти заяв1<и: 
г.--,-~----·--.-.._-r•;-~.-•--.·-. ._ 
~ - ..... ---• - ·--
.... --- · ­
._.,~-.,-,.м-
1• о~ 
9 ...... ..... .. 
'' ,І   
r . 
j 
1• • ""'"•"••~-
i и , ,· і і 
~ -1~......:... ·• 'ft r~ ..... :r ' • ,f , ..... , ... ,.' ~ 
Рисунок 3.9 - Видалення заявки 
Заявки на карті можна переглянути натиснувши на останній пункт меню 
зліва. Кожна точка на карті є інтерективною, має попередній перегляд, і 
натиснувши на неї, користувач переходить на її сторінку. 
31 
ЧДТУ 221965.007 ПЗ 
фо.оа.о.. 
·- • 
•• - ·· · с:, с:, 
... ,-,.·. ..  С) ..... -... • . ,,, .. ..... Q ' 
Рисунок З .1о  Карта заявок 
Qo..oeon 
Qнv • 
о-.--
" о 
·~..  •1•9 
Qад:.,, 
" 
u 
!•~ ~~~~.:;~t,~j,-~Q 
... ".-~,,..· ·, .._ 
Рисунок З .11 Обрана заявка на карті 
Таким чином було реалізовано базу даних на основі PostgreSQL, серверну 
та клієнтську частини. Кожна із них включає у себе функціонал для авторизації 
користувача. Після чого він переходить на головну панель, де знаходяться 
списки із зверненнями. Далі адміністратор може взаєодіяти із цими звереннями 
відповідно до опису в техінчному завданні . 
32 
\\Jt І У 22 І 965.ОU7 1I J 
ІJИСНОІН<І,,І 
Ut1t>"\:. було рс(U,ізооано ccpuic 011срат1101юrо стооре111 UІ ззяо~-н про 
мя У11раnлі1111я 11 ІСІ Іе І<Т)' 08111 !Я Черкаської міської рал11 . 
)1срLІНІМІІ крок:~м 11 до реа.11ізації бу1111 : 1юшук іс ІІУ'ОЧІL'< рішень, анмі'J 
nредмеmої області, формуо:~1111я в11мог до с11стсм11 та 011бір засо6іо 
рса..1із3uії. На оснооі цих даних було створено пт111 реаліз::~ції npoc"-ry. 
якнй ок;ночао у себе розділен11я побудови на nідзадач_і, яю треба було 
811конуоати до кінця демайну. 
Далі було розроблено користувацький інтерфейс, щоб зрозуміти які 
дані необхідно зберігати, окрім тих, що були описані на попередніх етапах. 
І вже на основі зібраних даних було спроектовано базу даних з оrтисом 
головної таблиці кейсів. Після було спроектовано архітектурні ви-моп1, я1<і 
включають у себе розміщення файлів, файлову систему, представ.лення як 
елементи мають взаємодіяти між собою та опис паттернів програмування, 
я1<і мають бути реаJІізовані. 
Наступним етапом була саме розробка. Так як на попередніх етапах 
усі неточності були описані, то реалізована система відповідає вимогам. 
У ході розробки було виокритсано паттерн мікросерсвісний 
програмування в серверній частині та МVС із мікросервіснами в 
клієнтській . Бекенд реалізований за допомогою технілогі й JavaScript, 
Node.js, PostgreSQL, Docker, Knex. Фронтенд з використанням Angula.rCLI, 
JavaScript, React, Vue.js. Для підтримки коду у єдиному стилі, було 
використано наступні засоби розробки: ESlint, Husky. Для організації 
роботи із пакетами цих бібліотек використовувався NPM, а для організації 
роботи у команді над спільними теками - Git. 
Було реалізовано стоірнки всих заявок, нових, та завершених, 
сторінку з мапою заявок та стоірнки панелі адміністратора. 
33 
ЧДТУ 221965.007 ПЗ 
СПИСОК ВИІ<ОРИСТА НОУ mTEPА ТУРИ 
Документація Node.js. _ [Електронний ресурс]. _ Режим достуrrу: 
https://devdocs.io/node/ 
2 Курс 110 PostgreSQL, YouTube - [ЕлектроІfний ресурс]. - Режим 
доступу: l1ttps :/I \VWW. youtube.com/watch?v=qw--VYLpxG4&t=5682s 
З Туторім по docker compose - YouTube - (Електронний ресурс]. -
Режим доступу: https://www.youtube.com/watch?v=Qw9z1E3t8Ko 
4 Туторіал по docker - YouTube - [Електронний ресурс] . - Режим 
доступу: https://www.youtube.com/watcl1?v=YFl2mCHdv24 
5 Docker and PostgreSQL - YouTube _ [Електронний ресурс). - Режим 
доступу: https://www.youtube.com/watch?v=aНЬE3pTyG-Q 
6 Документація по Docker - [Електронни.й ресурс]. - Режим доступу: 
https ://  docs .docker. сот/g et-started/ 
7 Документація по knex.js - [Електронний ресурс]. - Режим доступу: 
http://knexjs.org/ 
8 Документація по Javasc1·ipt - МDN - [Електронний ресурс]. - Режим 
доступу: https://developer.mozil\a.org/en-US/docs/Learn/JavaScript 
9 CLI Overview and Command Reference - Офіцій:на документація 
фреймворку Angular CLI. [Електронний ресурс]. - Режим доступу: 
https://angular.io/cli 
І О What is Postg1·eSQL? - Інформаційний портал Amazon. [Електронни.й 
ресурс]. - Режим доступу: https://aws.amazon.com/1·ds/postg1·esqVwhat-is­
postgresql/ 
І І : https://webdesign.tutsplus.com/articles/what-is-figma--cms-32272 
12 ESLint Find and fix problems in your JavaScript code - Офіційна 
документація ESLint. [Електронни:й ресурс]. - Режим доступу: 
https://eslint.org/s 
13 Системи контролю версій на прикладі git - Сайт Державного 
університету телекомунікацій. [Електронний ресурс]. - Режим доступу: 
34 
ЧДТУ 221965.007 ПЗ 
http://WWW.dut.edu.ua/ua/news-1-626-9170-sistemi-kontrol yu-versiy-na­
priklad i-git_ kafe dra-kompyuterruh-nauk-ta-info rmaciynih-tehnologiy 
нusky - Сайт налаштувань конфігурацій npm. [Електронний ресурс]. -
14 
режим доступу: https://www.npmjs.com/package/l1usky 
15 льоut npm - Офіційний сайт npm. [Електронний ресурс]. - Режим 
доступу: https ://www.npmjs.com/abouti 
35 
Додаток А 
лвтоматнзована і11теракт11в11а система збору та обробки інформації npo 
різt1і с11туації в І\1істі для покраще11ня роботи служб міста Черкас1t. Система 
АРІ 
Специфікація 
ЧДТУ 221965.007 
Листів2 
Розробник: Кретов О. В. 
КерівН}{к : Метелал В. В. 
Черкаси, 2022 
,..---~П~о;з~н~11~ч~с•;•;н~я~-:--::---::-:-!-с::--~Н~а~r~11\~1е~•~•у~о~а~••:н:я~--t--,П:р_им _іт_ка_ l  
~ДТУ. 221539.007 12 0 1 Текст програми 
~2.чдтУ. 221539.007 34 01 Інструкція користувачев1 
~~8!2_.ч~д~т~~У--~!!22ll!5!3_9~-~0!_07~~930~0:1:j~Г!р!а_ф~іч~ }-•"~R!й~м~а~т-е:!~р-і~ал~_-_-_-_-_-_-_t--~--~---_-_-_-=-=~1 
,---
r-
37 
Додаток Б 
Автоматизована і11терактив1tа система збору та обробюt інформації про 
різні ситуації в місті для покращення роботи служб міста Черкаси. Система 
АРІ 
Текст програми 
482.ЧДТУ. 221539.007 12 01 
Листів 14 
Розробв:и:к: Кретов О. В . 
Черкаси,2022 
482.ЧДТУ. 221539.007 12 01 
= . <l)itiiл 20220512183034 crc1ttc c[1scs tablc.js 
kнех requ1re('kncx')· - - -
сОІ\ St ' • 
r•• 
• @parюn {k nex} knex 
•І 
e:-..-ports.up = function(knex) { 
retu111 ~ex.scl,ema.hasTable('cases').then((exists) => { 
if (!ex1sts) { 
retum ~пex.schem~.createTable('cases', (table) => { 
table.1n~re~ents~'1d').primary(); 
table.strin?( deta1ls', 500).notNullable(); 
table.sp7c1ficType('location', 'POINT').notNullable(); 
table.str~ng(:~ddress', 400).notNullable(); 
table.string( unage_  url', 500).notNullable()· 
table.i ?teger('status').defaultTо (О); ' 
table.t1mestamp('created_ at', { precision: 6 }) .defaultTo(knex.fn.now(6)); 
} ); 
} 
} ); 
}; 
exports.down = function(knex) { 
retum knex.schema.dropTable('cases'); 
}; 
<І>айл Ol_cases.js 
const knex = require('knex'); 
І** 
* @param {k.nex} knex 
*/ 
exports.seed = function(knex) { 
retum knex('cases').del() 
.then(function О { 
const seedCases = [ 
{ .. 
details: 'КИІВ. 26 квітня. УНН. На сьогодні Російська Федерація незаконно 
утримує чи ув'язнює з політичних мотивів близько 120 незгодних громадян 
України. Про це повідомляє УНН з посиланням на пресслужбу МЗС.', 
location: "49.4063358, 32.0539413", 
39 
482.ЧДТУ. 221539.007 12 01 
n~d•·ess: 'Чсуе11аш1<n , В'ячеслава Чорновола вулиWІ, Хімселище, ~еркаси, 
J'Ір1-1д11щровськии район, Чсркасt.ка міська рада Черкаська 0611асть, І 8000-
І 8499, Ущ>аїна', ' 
і111аgе_ш·І : 
·1111ps ://нрІоаd . \vik iincdia.org/,vikipedia/corrunons/d/d7/ lsrael_  3 _ 002.Tras\1.jpg', 
}'  
{ 
details: 'КИЇВ. 26 квітня. УНН. На сьогодні Російська Федерація незакон:но 
утримує ••и ув'язнює з· політичних мотивів близько 120 незгод:н.их громадян 
України . Про це повідомляє УНН 3 посиланням на пресслужбу МЗС.', 
Іосаt іов : "49.4063358, 32.0539413", 
addi-ess: 'Черепашка, В'ячеслава Чорновола вулиця, Хімсел:ище, Черкаси, 
Прид11і11ровський район, Черкаська міська рада, Черкаська область, l 8000-
18499, Україна', 
і111аgе_ш·І : 
'l1t1ps :/ ILІpload . wik itnedia.org/wikipedia/comrnons/d/d7Л srael_З _ 002.Trasl1.jpg', 
status: О, · , 
created_at: knex.selcct(knex.raw('NOW()- INTERVAL '10 DAYS")), 
}'  
]; 
1·etur11 knex('cascs').insert([ 
... seedCases, 
...s eedCases, 
... seedCases, 
...s eedCases, 
... seedCases, 
]); 
} ); 
};  
Файл case.mocks.js 
const пewCaseMock = { 
details: 'мусор' , 
location: { latitude: 49:457857, loпgitude: 32.043704 } , 
ішаgе _ LJrl : 'test-image', 
};  
const casesMock = [ 
{ 
40 
► 
482.ЧДТУ. 221539.007 12 01 
id: І. 
d~t:tils: 'мусор', 
Jосзtіон : { 
\ зtit11de : 49.457857, l oпgitude : 32.043704. addrcss: 'test_address', 
1113p_i111age_url: 'test-ur\ ', 
\'  І 
. 
j 1нnge_url : 'test-iinage', 
staшs : О, 
created_at: '2020-05-ОЗТ14 :09:З8.244Z' , 
}. 
{ 
id: 2, 
details: 'мусор2', 
\ocation : { 
\atitude: 49.457857, longitude: 32.043704, address: 'test_address', 
111ар_ іІТІаgе _ нr\ : ' test-ur\', 
} ' 
image_url : 'test-image', 
statuS : О, . . 
created_at: '2020-05-03T l4:09:38.244Z', 
} ' 
) ; 
inodule.exports = { 
ncwCaseMock, 
casesMock, 
}; 
Файл common.js 
const { casesMock, newCaseMock } = requite('./case.mocks'); 
class CommonMocks { 
static get 11ewCase() { 
return this.getDeepCopy(newCaseMock); 
} 
static get cases() { 
retum this.getDeepCopy(casesMock); 
} 
static getDeepCopy(mock) { 
retum JSON.parse(JSON.stringify(mock)); 
4 1 
► 
482. ЧДТУ. 221539 .007 12 О І 
) 
} 
1110dнle .exports = { 
corninonMocks, 
}:  
Файл cases.service.js 
const { GeocoderServic~. PostgresService } = require('./index'); 
c\ass CasesService { 
/** 
* @para ш { PostgтesService} postgresService 
* @param {G eocoderService) geocoderService 
*І 
constructor(postgresService, geocoderService) { 
this.postgтesService = postgтesService; 
tl1is.geocoderService = geocodcrService; 
t\1is.DEFAUL Т _PARAMS = { 
li111it: 25, 
offset: О, 
} ; 
} 
rernapCase( { . ated at 
id, details, location , address. image_ur\, map_Ш1age_url, status, c re - ' 
} ) { 
retum { 
id, 
details, 
location: { 
\aritude: location.x, 
longitude: location.y, 
address, 
} .m ap_image_url, 
iinage_  url, 
status, 
c reated_at, 
} ; 
} 
42 
482-ЧДТУ. 22 І 539 .007 12 О І 
:,syttc ge1Cnscs(scш·cl1Pa1·aщs) { 
cottsl с111те11tР:н·а111s = { 
... 1l1is.DEFAULТ  _РАН.АМS, 
....s ea1·cl1Pa1·a111s, 
} : 
co11st que1·yPa1·a111sBuildei· = (qнery) => { 
jf ( currentPш·ains.id) { 
que1y. \vl1e1·e('id', ct1rrentParaшs.id); 
} 
if(cш·re11tPa1·ams.statнs) { 
que1y. wl1e1·e('status', cur1·entParams.stan1s) ; 
} 
if(currentPш·a111s.details) { 
que1y. wl1ere('details', 'like', "%${ cuпentParams.details }%"); 
} 
} ; 
co11s t casesResposc = await this.postgresSeгvice 
.knex('cases') 
.orderBy('id', 'desc') 
.liinit(c ш·rentPara111s'. limit) 
.offs et(c urrentPara111s.offset) 
.modify(queryParatnsBt1ilder) ; 
const tota\Count = +(await t.his.postgi·esService 
.kлex('cases') 
.count('id') 
.111odify(CJueryParшnsBuilder))[0].coш1t; 
retun1 { 
liinit : +cttrrentParatns. liшit, 
offset: +cwтentParatns.offset, 
results: casesRespos.e. ш ар( this.remapCase) , 
total -count: tota\.C ount, 
} ; . 
} 
43 
482. ЧJtTY. 22 1539.007 12 О І 
,,:;, 11,; ~~1('11:-.cByltl(itl)'  { 
· ,.:'1н1~1 itl l~c:-puщ;c ~ t\\vait Іl1is.post~rcsScrvicc.k11cx('coscs'). \vl,crc('id', id); 
t'\:І щ,1 і1І l{cspo11sc.1 110µ( 1І1 is.rcщapCnsc ); 
;1:;yi1c c1·~:11eC:1se(11c,vCnsc) { 
..:oiisl d:1tnbuscCasc = { 
11c,vC:1se, 
i~cat іо11 : · $ ( 11e-.vCasc. locut ion.la t itude} $ { ncwCase. l ocat ion .lo11gitudc} · • . 
address: ( awn1·1  t І1 1·s .gcocoderService.rev' erseGeocoding(newCase. І ocat1·o n. lat 1tude • 
lc,vCa sc. locatio11. lo11gitudc )).display 1шinc 
І } - • 
; 
co11st crcatedCase = a-.vait tl1is.postgresService 
.knex('cases') 
.i11 scrt( databaseCasc) 
. rctuл1iпg('•') ; 
rctнm tl1is.re11шpCasc(creutedCasc[O]); 
} 
аsупс resolveCase(id) { 
const 1·esolvedCasc = awuit tl1is.postgresScrvicc 
.knex('cases') 
.w  l1erc('id', id) 
.ttpdate( { s tatus: . І }i  
.rctuming('•'); 
ret11m tl1is .retnapCase(reso lvedCase[0]); 
} 
async unrcsolvcCasc(io) ( . . . 
co11st ur1resolvedCase = awa1t tl11s.postgresServ1ce 
.kлex('cases') 
. wherc('id ', id) 
.update( { s ta tus : О } ) 
. retlІПl ing('• '); 
retum 1\1is.reinapCase(unresolvedCase[0]); 
} 
44 
482 -ЧдТУ. 22 1539.007 12 01 
' . 
Фзііл gcocoder.scrvice.js 
со1 1:іІ Q~c11c = rcq~ir~("quc11c-proinisc'); 
coi1s1 ::ixюs = req111rc( ::ixios'); 
cl:iss GcocodcrScrv ісс { 
co11s1ruc1o r(apikcy. api Url) ( 
1 І1іs. АРІ_КЕУ = apikcy; 
1l1is.API_ URL = apiUrl: 
1І1is . LIM IT = І ; 
1l1is. FORMAT = 'J'son'· 
1І1іs. LANG = '11k'; ' . 
1І1i s.qucL1c = ІІ С\v Qucuc( ( 
СОІІСLІГГСІ11 : І . 
intcrval: 1500, 
stnrt: І ГLІС. 
} ); 
} 
:isy11c revcrscGcocoding(la t itudc. longitudc) ( 
reшm 11e,v Pro1nise((resolve) => ( 
co11st 1,rl = ·${ this.API_ URL} · 
1- ·?kcy=S{tl1is.API_ KEY} . 
+ · &Comiat=$ { tl1is,FORMAТ } . 
➔ • &:iccept- l:ing11:igc=S(tl1is.LANG} . 
+ ·&1i in i1= ${ 1l1is.LI M JT}. 
➔ ·&1ar-S{la1i1ude} · 
+ · &lon=$ { lo11gitudc} · ; 
rcturr1 tl1 is.q11eue .enquc11e(asyn·c () -=> ( 
const address = (:i,vait axios.ge1(url )).dзta ; 
rcsolvc(addrcss); 
І) ; 
}) ; 
} 
45 
482.ЧJ tTY. 22 1539.007 12 01 
,11,нl11k. o.:xpt>1,s .,. І 
Go.:oo.:o<k1·S,:rvicc. 
Фnіі11 i11dex,js 
co11st { CascsSci-vicc } = reqнirc('./c:iscs.scrvicc'); 
co11st { Pos1grcsSc1·vicc } = 1·cq11i1·c('./postвrcs.scrvicc'); 
co11st { GcocodcrSc1·vic~ } = rcqнire('./gcocoder.scrvice'); 
co11st postgrcsSc1-vi~c = 11c,v PostgrcsScrvicc(); 
co11st gcocodc1·Sc1v1ce = пс,v 
Gcocodc1·Scrv icc(proccss .cпv. LOCATIONIQ_API_KЄY, 
pi·occss.e11v .LOCATION ІQ_API_URL); . 
co11st cnscsScrvice = псw CnscsScrvicc(postgresService, gcocodcrScrvice)! 
1110dule.cxports = { 
PostgrcsScrvicc, 
C:iscsScrvice, 
GcocodcrScrvicc, 
postьrrcsScrv icc. 
c:iscsScrvice, 
geocodcrScrv ісс, 
};  
Фnііл pos tgrcs.scrvic:c.js 
co11st Ішех = rcquirc('kпex'); 
cl:iss Postg1·esSc1·vicc { 
coп::;tructor() ( 
11,is.kncx = kпех( ( 
сІіепt : 'pg', 
со11лсс1іо11 : { 
Іюst : proccss.env.PGHOST, 
user: process.env.PGUSER, 
password: process.env.PGP ASSWORO, 
database: proccss.env.PGDAТ  АВАSЕ, 
} ' 
роо І : ( 111in : О, шах: 7 } , 
} ); 
46 
482-ЧДТУ. 221539.007 12 01 
} 
І 
І 
1110d11lc.expo11s = { 
PostgтcsSer·vice, 
І . 
І • 
Файл indcx.js 
co11s~ ex,pr·ess = 1·eqвii-e('express'); 
,·cq111re( exp,·ess-~sync-e,тors'); 
co11s1 co1·s = reqщ1·e('cors'); 
co11st lюdyJ>ai·se,· = ~eqнire('body-parser'); 
co11st dote11v :' 1·e~щ1·c('dote 11v•); 
co11st { casesServ1cc } == •·cq11ire('./services/ i11dex'); 
dote11\1.co11fig(); 
co11st арр = exp1·ess(); 
.-.рр . нsе( bodyP arse1· .j s011()) ; 
ripp.нse( , 
bodyPa1·sc1·.ur·le11coded( { 
cxtc11ded: 11·не, 
}) , 
); 
ripp.11se(co1·s( { 
01·igi11: process.e11v.CORS- Fl~ONTEND- DOMAIN'  
})  ); 
app.get('/ ', (requcst, response) => { 
response.jso11( { info: 'СhеСІем' }) ; 
}) ; 
app.get('/cases', asy1ic (~quest, 1·esponse) => { 
co11st cases = await casesSeгvice.getCases(request.query); 
response.stal11s(200).jso11( cases ); 
}) ; 
app.get('/cases/: id' , async (1·eqнest, response) => { 
co11st caseByld = await casesService.getCaseByld(+reqнest.paraшs.id); 
47 
482.ЧДТУ. 221539.007 12 0 1 
r..:spo11sc .stntus(200 ).j s_on( cnsc\Зy ld); 
1) : 
iiPP·Post('/cases', nsyпc (rc_qucst, rcspol1se) => ( 
co11sl creatcdCasc = awa1t cascsService.crcateCase(request.body); 
respo11sc.s1a1us( 200).jso,1( crcatedCase ); 
} ); 
ІІPP-Patcl1('/cnses/: i~1·cso\~e• , asy11c (rcquest, rcsponse) => ( . . 
co11st rcsolveCasc = awa,t casesService.rcsolvcCase(+request.params.,d), 
,·e spoпse . sta tus(200 ).j s011( resol vcCasc); 
} ); 
app.patcl1('/cases/:id/u11resolve', asyr1c (request, response) => ( . . 
co11st нnresolvcCasc =. await cascsScrvicc. unresolveCase(+ request.params. ,d), 
respo11se.sta tus(200 ).json( t1nresolveCasc ); 
} ); 
app.usc((err, rcqucst, rcspoпsc, ncxt) => { 
coнso lc.er,·or( crr); 
respo11sc.status(500).jsoп( { errorMessagc: eiт.mcssage }) ; 
11cxt(); 
) ); 
app. li s t cn(process.cвv . PORT, () => ( . 
cor1sole.log('Scrvcr startccl оп ро1·1 ${process .eпv .PORT} . ); 
} ); 
Файл .dockєrignorc 
node_п10dulcs 
Файл .editorconfig 
root == true 
[•] 
епd of І іпе = lf 
clia;-sct-= нtf-8 
11·iin trailiнg_ whitespace = 11·ue 
iпsen_fi11al_11ewline = true 
ілdевІ style = space 
iлde11t=s izc = 2 
48 
482-ЧдТУ. 221539.007 12 01 
r•jsl _ 
. ,~11, sty lc - spnce 
111' - • -
. d•• 11І S ІZC - 2 
ІІІ V -
r•.{dirf,111d}] . 
iriнi_ 1rзіІ i11g_ \vl1i tespace :::: fal se 
Файл eslintrc.js 
1110dule.expo11s == { 
c11v: { 
cs6: 1n1e, 
110 de: tп1е, 
} • • & 
extends: ['a1rbnb-base') , 
globals: { 
Ato111ics: 'readonly', 
ShзredAттayBuffer : 'readonly', 
}, 
parse1·Optio 11s: { 
ccшaVersion: 20 18, 
sourceType: 'anodule', 
}, 
rules: { 
"inax-len": (2, 140, 4), 
"no-unused-vars" : "off', 
'camelcasc': 'off', 
'class-metho ds-use-th;s' : 'off', 
'110-console' : 'ofr, 
semi: ['error', 'always1. 
}.  
};  
Файл .gitignore 
node_modules 
.cnv 
.idca 
Файл docker-compose.yml 
vers,.o n: "З" 
se1·v1ces: 
49 
482-ЧдТУ. 221539.007 12 01 
\111ck~11d: 
сонt:1і11с1·_11.нnс : "с<-'4_b ackcпd" 
t,11ild: . 
,,0\шнеs: 
- " ...І  а " 
( рр 
_ "dзta_b acke11d_libs :/app/11ode_ modules" 
port:s: 
_ "3000:3000" 
et1v file: ".env" 
depeнds_on: 
_ postgres 
postgres: 
contai11er_na111e: "cc_postgres" 
image: "postgres: 12' " 
. 
po1·ts: 
- "3300:3300" 
e11v _ fi1l е.· ".env " 
volumes: 
data- backend libs : 
-
driver: \ocal 
Файл Dockerfile 
FROM node : 13-alpineЗ. 10 
WORКDIR /арр 
СОРУ package* .json ./ , 
RUN np1n сі && прш cache сІеап --force 
#СОРУ .. 
EXPOSE 3000 
CMD [ "npm", "start"] 
Файл knexf"ale.js 
require('dotenv').config(); 
50 
482-ЧдТУ. 221 539.007 12 01 
dнl~ -~xpons = ( 
,111) { 
Ji:,·i:lop111c11t : 
1 
·tii:nt : 'postgrcsql', 
І, • { 
~0 1111ect1011 : 
\1ost : process.cнv .PGHosт, 
нser : process.eнv.PGUSER. 
pзss,vord : process.env.PGP ASS WORD 
dзtabase : process .e11v.PGDд т АВАSЕ ' 
І • 
І ' 
рооІ : { 
mi.n : ?- , 
п1ах : І О 
}.  . 
n,igrations: { 
tableName: 'knex_migrations' 
} 
}. 
};  
Файл package.json 
{ tt 11 11 
''name : src , 
"vers1· 0n " : " І •О  •О " , 
"description": "ClteClean", 
0
" mat•n  "·.  "·ш dex· J S" , 
"dependencies": { 
"axios": "лО . 19.2" , 
"body-parser": "л l.19.0", 
"cors": "л2.8.5" , 
"dotenv": "л8.2.О", 
" express".· "Л4 . 17 . І" , 
"express-async-error~J• ..  "ЛЗ . І . І" , 
"k:nex": "лО.2 І. І" , 
"nodemon": "л2 .0.3" , 
"·. Р g" ·.  "Л8 . О . З" , 
"queue-prom1. se " : "Л2 .О . І" 
}'  
"eлgines": { 
"пdо" е· ". ІЗІ. 20. " 
}'  
"d.evDependencies": { 
5 І 
482-ЧДТУ. 221539.007 12 01 
" ,.;ditoГC о 11 І·• g,"  .·  " IVv\ . 15 . З" , 
"..:sl i11 t " : "Л6 ·6  ·О " , 
"..:sl і111-со11 fig-aiгb11b-basc" : 00л 14 .О .О", 
",.;sl інt-соп fig-prcttier" : ""6. 5 .О" , 
"esl i111-plugi11-irnpon": 00л2_ 18.2", 
"csli11t-plt1gin-prcttier": "ЛJ. І . І ", 
"Ішskу " : "ЛJ · О ·9 " 
І • 
"scripts" : { 
"s1,111": "rюdemon src/index.js", 
"dockcr": "docker-compose up", . 
"docker:init": "docker-compose build && npm run docker:пugrate && docker-
cornpose up", · 
"docker:migrate": "docker-compose run --пn backend npm run migrate",,, 
"docker:seed": "docker-compose run -пn backend npm run migrate:seed , 
")іпt" : "npx eslint ./src/** /* .js", 
"liпt:fix": "npx eslint ./src/**/*.js -fix", 
"migrate": "npx knex mjgrate: latest", 
"rnigrate:rollback": "npx knex migrate:rollback", 
"migrate:seed": "npx knex seed:run", 
"test": "есІю \"Error: 110 test specified\" && exit І " 
},  
"autl1or": "Lexander 1108", 
"l1·c er1se " : "ISC" , 
"lшsky": { 
" lюoks" : { 
"pre-co1n1nit": '"', 
" pre-р u sh" .· "" 
} 
} 
} 
52 
Додаток В 
,,\втоматизова11а інтерактивна система збору та обробки і11формаціі про 
piзJfi с1ітуаціі в місті дл_я покращення робот11 служб міста Черкаси. Система 
АРІ 
Специфікація 
482.ЧДТУ. 221539.007 34 01 
Листів 1 
РозробНЮ<: Кретов О. В. 
Черкаси, 2022 
482-чдТУ. 221539.007 34 01 
для запуску проекту необхід11ою вимогою є наявність: 
• node vl3 
• postgres v 12 
• docker 
встановлення: 
npm install 
запуск: 
npm start 
Ви можете використовувати docker desktop для запуску проекту. В 
nерІJJИЙ раз необхідно викопати команду: 
npm run docker:init 
Після першого запуску, в наступні рази слід корис1уватись командою: 
npm run docker 
Для того щоб залустm-и міграцію слід скористатись командою: 
npm run docker:migrate 
Для того щоб вставити мок-дані в базу необхідно використати команду: 
npm run docker:seed 
54 
Додаток r 
лвтомат11зова11а інтсракт11в11а система збору та обробки і11формації r,po 
різІІі cisтynц,і  0 МІ· СТ і для 1•1 окраще1111п роботи служб міста Черкас~~ . С истс ма 
АРІ 
Графічн і матеріали 
482.ЧДТУ. 221539.007 90 01 
Листів 8 
Розробник: КретовО. В . 
Черкаси, 2022 
482. ЧДтУ. 22 1539.007 90 О І 
ЗМІСТ 
, ~су11ок Г. І - СJІ.~іщ <<Сероіс дпя благоустрою міста,> ........................ ,............ 
І І ·········· з 
~нсу, 1ок Г.2 - Слаіщ <<Опис тех11і •1них вимоn>............ ........................................ ....... . 3 
rІ  сунок Г.3 - Слаіщ <<Кому,іікація до Cl1eClean»............................................ ••••.•••••• 4 
р 11 су11ок Г.4 - Слаіщ <<Кому11ікація до CheClean» .............................................. .. ••••••• 4 
r:,у,оок r S - Слайд «ц;пь nроск,у» _______________________________ -------------- -- --- -------- ------ - _::: 5s  
рису11ок Г. 6 - СJІаіщ <<Створення кейсу» .......................... •···· ........... ·············· .. ··· ..... . 6 
рисуt~ок Г. 7 - Слайд <<Корис'І)'вач» .......................................................... .. ••·:·· ........ .... 
Рисунок Г.8 - С11айд «Адміністратор» ..................................................................... •:::: 6 
рисуtюк Г. 9 - Слайд «Адмін панель» ...................................... ........................ 77  
Рисунок Г. І О - Слайд «СтруК'І)'ра бази данюо> ...................................................... ::::: 
рнсу~1ок Г. 1 1 - Стек ви"-ористаних технологій» 8 
................................... :•· ....... ••·::::: ..... 8 
Рисунок Г. 12 - Слайд «Результати роботи сервісу»•····· ........... ·····................... . ..... .. 
Рисуt1ок Г. 13 - Слайд «Отриманw~ подяки від мера міста Черкасю> ............. . 9 
482 .ч дт У. 221539 .0079001 
Бсоиксотлеом1ар ~ько роб 3бор ота на тему: 11Автомо1иювоно ІІ<ТороІ('І'И8"'О 
АЛІІ nокращ У то обробки Інформоuіїnро рІ3ні сшуоuіів мІсtІ 
еннІІ робо,и служб мJс10 Черкаси. Система АР ІІІ. 
QCheOeon 
Студент: І(ретов о.в. 
КерІ1ннк: мотелоn 8.8. 
· Риtунок Г. І - Слайд «Сервіс дr1я блаrоустро10 містз» 
Q o-.. ~~ 
Оnнс: технічних ■имоr 
.Лл• ФР,,сtу~,-ю сср,Іс nое,н.си '""'°"°'" •1 ceGc 
1 юс1ун1н,й ф)1н'.ukнол: 
- ІАО.-<л><аІс:ть с;,юре-.. ,оорнонн,о: 
м())ІІ(Л,tоіс':~~ nonof)(JN ,ьо,о nоrю•млу. 
- .м.Q)of.;'\H!,.ic:ro Q)Щ)ЙОми•ж:ь )І ,с,мо )&OP•WНttJft'J ... 
- ,ло),(,,иt~1 .. •~uлснч, JWi)нe.,.w,; 
- 1лt>X/\иQl':tt. ~л~а c::roтycv 1~срщ:11н.1; 
- •дr;.J<.м•c<::ro JU/l\\•WQ1и 1(0,ЛQНІОР. 
Рисунок Г.2 - Слайд «Опис технічних вимоr» 
482-ЧдтУ. 221539.007 90 01 
Go,,o.o, 
КомунІ1еац1" :i~~h•Clean 
.,, 
Рисунок Г.3 - Слайд «Комунікація до CheClean» 
І 
Рисунок Г.4 - Слайд «Комунікація до CheC\ean» 
482. ЧДТУ. 22 1539.007 90 О І 
Q o.o-
Ціла, nроекту 
. 
~-~-- - .. , 
~. . ' ,. " 
• t.: .. 
- -~ А; 
Про 
Рисунок Г.5 - Слnйд «Ціт, nроск-ту» 
G>o-... ,,,,­
Стаоренн11 кеАсу 
, 
.• " 
• 
.• . і 
. ". '  
' .. - ... 
Рису11ок Г .6 - СJІайд «Створення кейсу» 
- - - ---------
482.ЧДТУ. 221539.007 90 01 
Корис:ту1ач 
, '----"C--;:i' 
--.-'  ... - ' .. 
' ' 
•-•~, -~Ф .• _.::~ °'' ~--·~:j_,;~ :,~~}'~~~~ ~~ ;.- _. 
І) исунок Г.7 - Слайд «Користувач» 
l. 
Рисунок Г.8 - Слайд «Адміністратор» 
482-ЧдТУ. 221539.007 90 01 
'---
•• 
·- -· 
... • 
___ . __ _ 
:---=---
·--·."-1'-1" "-·-♦- ------
•о·-·----
Рисунок Г.9 - Слайд <1Адмін панель» 
/ 
/ ' coscs 
Ііwюnом Тчп д-бн.;х Формо,у SQL Опж: "°"" 
1d Pltnay kcy УнікалN1иМ іА,енn.фікаtОО 
., 
, l(O)o(ld ХІАКИ 
• dolaih . Vorchor(500/ Тскс1оа,"1 опж: nроблсми 
(IOllludC. 
Іо<:оІ-оn Point reo11oкowa 
Іonalilvdol 
c<1drc ss 
- Votct-.ar(400/ Адреса ло,:оuі 
lmago_. ...,  v'orcnot/5001 nocw-OННJ но фОtоrрофЮ 
sto!vs . . С,01ус )0t8ІСМ, І обо о. )О 
. - nt '· - .. Х>д\Ое:?!Оtн!ІМ 0 
СІООІ/Х1_01 Іrne stomp .. . ДО10 СІ ІЮІ)(JНнJІ )ОІОІО• 
'с'...,...._ . 
.'..--~•-•C...-'-"--=.....L.===-~-'"'" """ .•. 
. Рисунок Г. І О - Слайд «С-1рукrура бази даних» 
482-ЧдТУ. 221539.007 90 01 
фо-. 
Стек •икорисмних технолоrІй 
docker *KNEXJS 
JS 
,Рисунок Г. J І - Стек використаних технологій» 
".".-  - ·.. .. -.-, ...... 
Kl'Ь'"J'OUY 
0 1,tCC_.1111.'f'f М·А· )f•ІQ;ІІ ...1 :t 
.. ,_.-,·..•._-•",·"-".... ··--·
 ...'-  ~-·-.-..,.,  ..­.. · 
ti,. ,,.. 
І ~-~ . r,- '-•,.,···••К•--~ 
~ 
,; 'J ~-
-_ ·~ :.-:~·:;::- І 
- ,.. .. , 
о 
Рисунок Г. 12 - Слайд «Результати роботи сервісу» 
-
482-ЧдТУ. 221539.007 90 01 
Рисунок Г. І З - Слайд «Отримання подяки від мера м~·с та Черкаси» 
'