Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/9072
Назва: Автоматизоване робоче місце пожежного
Автори: Голуб, Сергій Васильович
Андрійчук, В'ячеслав Ігорович
Ключові слова: автоматизоване робоче місце;веб-додаток;пожежний;клієнт-сервер;automated workplace;web application;firefighter;client-server
Дата публікації: 20-чер-2023
Короткий огляд (реферат): АНОТАЦІЯ Андрійчук В'ячеслав Ігорович Автоматизоване робоче місце пожежного 121 - Інженерія програмного забезпечення Черкаський державний технологічний університет Черкаси , 2023 Кваліфікаційна робота присвячена розробці веб-додатку для автоматизації робочого місця пожежного. Метою дипломної роботи є створення зручного та ефективного інструменту, який допоможе диспетчерам пожежної частини у керуванні та моніторингу пожежної діяльності . Додаток надасть диспетчерам можливість фіксувати інформацію про виникнення пожеж, стан пожежної техніки та розташування пожежних бригад. Він також забезпечить функціонал для реєстрації викликів, планування та координації роботи пожежних бригад, а також зберігатиме арх1в даних про . . попередні пожежі та виконання задач по їх гасінню. У роботі використовуються сучасні технології веб-розробки, таю як HTML, CSS, Python, Django та база даних PostgreSQL для зберігання інформації. Додаток розроблений з урахуванням принцип зручност1 використання, безпеки даних та швидкості реакції на події. Очікується, що розроблений веб-додаток значно полегшить роботу працівників пожежної частини, шляхом зменшення часу реакції на пожежні випадки та сприятиме кращій координації пожежних бригад. Такий інструмент є особливо важливим у вимогливому середовищі пожежної діяльності, де швидка реакція та ефективне керування мають вирішальне значення.
ANNOTATION Andriychuk Vyaches]av Automated workplace of а fiгefigl1teг 121 - Softwaгe engiпeei·ing Cherkasy State Tecl111ological Uпiveгsity Cherkasy, 2023 The qualification woгk is devoted to the development of а web application for the automation of а fiгefighter's woгkplace. The aim of the thesis is to create а conveпient and effective tool that will help fire department dispatchers in managing and 111onitoring fire activity. The application will provide dispatchers with the opportunity to record information about the occurrence of fires, the state of fire equipment and the location of fire brigades. lt will also provide functionality for registering calls, planning and coordinating the work of fire brigades, as well as keeping an archive of data оп previous fires and their extinguishing tasks. The work uses modern web development technologies such as НТМL, CSS, Python, Django and the PostgreSQL database for information storage. The application was developed taking into account the principles of ease of use, data security and speed of reaction to events. It is expected that the developed web application will significantly facilitate the work of fire department employees bу reducing the response time to fire incidents and contribute to better coordination of fire brigades. Such а tool is especially important in the demanding firefighting environment, where quick response and effective control are critical.
URI (Уніфікований ідентифікатор ресурсу): https://er.chdtu.edu.ua/handle/ChSTU/9072
Розташовується у зібраннях:121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)

Файли цього матеріалу:
Файл Опис РозмірФормат 
Кваліфікаційна робота бакалавра Андрійчук В'ячеслав Ігорович.pdf
  Restricted Access
26.87 MBAdobe PDFПереглянути/Відкрити    Запит копії


Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.

Extracted text
MlHl' TE1JCTBO ОСВІТИ 1 НЛ VКИ УКРАЇНИ 
ЧЕРКА ЬКН1::\ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факуль,, r інформанійни tехнолоrій і систєм 
Кзфе.11.1,а nро1,рамноt'О аб зт1~"tt нн>'\' аnтом(\:rи1оеаних систем 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«бакалавра» 
освітній рівень 
на тему: Автоматизоване робоче місце пожежного 
Виконав: студент 4 курсу, групи ПЗС-2O44 
Сп~ціальності 
121 «Інженерія програмного з.абезпечення» 
(шифр і назва напряму підготовки) 
Студент Андрійчук В.І. 
(прізвище та ініціали) 
Керівник Голуб С.В. 
(прізвищ(' та ініціали) 
Рецензент Шульrа О. Г. 
(прізвище та ініціали) 
Черкаси 2023 
___________ :Ч:!,Sе,.1р~к~аС~.о_Ь~К!1И!!Й.J,д.!Sе~р1)1[~(:а!_!ВІ~-:!.!ІИ21Й!2....!.Т.sнех~~ол:!.!:о~гі~t)!_!Н:!ІJ::!ИU:ЙLУУ:І!·:І!.і!_!:В~е12р~с.!:!И.!.ТеsтL_ _______  
ПОНІІС 11аНмс1 1 уnа111111 вищого ІІШ3ЧаJІІ,І-ІОГО Jnf(JlllдY 
факультет інформаційних технологі й і систем 
Кафедра програмного забезпечення автоматизованих систем 
освітній рівень бакалав 
спеціальність 12 І «Інженерія програмного забезпечення» 
освітня програма Інженерія програмного забезпечення 
~-w--.,_wи ПЗАС, професор 
бС.В. 
ЗАВДАННЯ 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
Андрійчук В'ячеслав Ігорович 
(нрізвище. ім·я. 110 батькові) 
1 .Тему проекту (роботи) Автомати-зоване робоче місце пожежного 
Керівник проекту (роботи) Голуб Сергій Васи пьовнч д.т.н .. професор 
( І Іf)Ї 'JІ111ІІ(С. Ї~І. 11 • 110 бut 1,І<оІJЇ. 1111) ІЮІІНіі С'Г) І І і НІ,·. В'ІСfІС JIIШ /1-fll) 
Затверджені нака:юм Чер1<ас1>кого д~ржав11ого технологічного університету від « 24 » лютого 
2023 року М!43/04 
2. Строк подання студентом проекту (робот11 ~6:..t:1~с::,1;~р в~11~я!...;2:::.~;02::.:З~р~.-------------
3. Вхідні да ні до 11рое 1<"1·у (роботи) стан,1.ар111 проІ)Jам11 r·o 1абсзпечеш1я; процеси управління; 
вимоги до 11рое1,т ; кш1~11л,nр11е 11ла1-1 . вання просктv; vправління ризиками проекту; управлін­
ня рес,,рсами 
4. Зм іст р<НІ НХ)їІ1,ово-11ояснювальної записки (перелік питань, які 11отріб110 розробити) 
ВСТУП· 
ІСН) \ОЧІ І\•Н :ТОДИ ТА ЗЛ ОБИ РОЗВ'ЯЗАННЯ ПОСТАВЛЕНИХ ЗАВДАНЬ; 
НРОСКТУВ. НІ ІЯ ПРОІ РАІ\1ІНОГО ЗАБЕЗПЕЧЕННЯ СИСТЕМИ: 
РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ВИСІІОВКИ: 
Сннсок в11 корнставих джерел: 
о.:. аткн. 
5. П~р ':1ік графічно~ о \tатеріалу (з точю1с'-1 зазначення..~~ обов· язкових робіт проекту; 
Діагра\1а к:шсів: 
Діаг1 а.\1 \ дія:н,ності: 
~ 
't~1 
~·( 
б. Консультанти розд іл і rз 11роскту (робт~--
Лілп ис, дата ---:--. 
Прі ·шн111с. і11і11іш1и пt ,нн.:алн --
Розліл ~1ШІ) ІJІІІІІЯ пилав Завдання при~ 
1(()1 І С)'JІІ,Т<і І -ІПІ 
- --- --,..:.,,,. 
. l. 
І -- --- ----- ---.... 
') --. 
.., 
_) -
7. Дата ви;1.ачі заnлання 24 січня 2023 R· ' 
і 
КАЛЕНДАІ'Н ИЙ ПЛАН 
І 
Строк виконан-
№ ПриміТІ(] 
Назва етапів випускної роботи ня етапів витту-
п/п скноїроботи 
05.12.2022 виконан, 
1 Постановка задачі 
виконан, 
? Підготовка завдання 13. 12.2022 
,., І 6.12.2022 виконанd 
.) Погодження завдання 1 
4 Затвердження завдання 24.02.2023 виконан~ 
Основна стадія 
1 Підбір матеріалів 27.02.2023 викою~н, 
2 / Аналіз шляхів вирішення поставленої задачі 04.02.2023 виконан 
,., 
.) / Розрахунок основних параметрів роботи 10.03.2023 виконав 
4 / Вибір кінцевого варіанту проектного рішення 17.03.2023 виконав 
5 Оформлення первісної редакції роботи 25.04.2023 ВИКОНШІj 
Заключна стадія 
1 Узгодження прийнятих проектних рішень з кері- І 0.05.2023 виконан 
вником 
2 Оформлення пояснювальної записки роботи в 19.05.2023 виконав 
кінцевій редакції 
3 J 
Попередній захист роботи 22.05.2023 І 
виконан: 
4 Затвердження роботи 29.06.2023 виконан~ 
5 Рецензування роботи 01.06.2023 виконан~ 
б Захист роботи 
Студент # ----. АнJ:!g ійчvк В.І. І 
~и (ІІрізrи11це та і11ініа:1и) , 
Керівник проекту (роботи) - ·/--~v 
t_ ~ІІ <: ) Голуб С.В. 
( п Р j зви ще І а ш.11.1 1а.-rи) 
АНОТАЦІЯ 
Андрійчук В'ячеслав Ігорович 
Автоматизоване робоче місце пожежного 
121 - Інженерія програмного забезпечення 
Черкаський державний технологічний університет 
Черкаси, 2023 
Кваліфікаційна робота присвячена розробці веб-додатку для 
автоматизації робочого місця пожежного. Метою дипломної роботи є 
створення зручного та ефективного інструменту, який допоможе диспетчерам 
пожежної частини У керуванні та моніторингу пожежної діяльності . 
Додаток надасть диспетчерам можливість фіксувати інформацію про 
виникнення пожеж, стан пожежної техніки та розташування пожежних бригад. 
Він також забезпечить функціонал для реєстрації викликів, планування та 
координації роботи пожежних бригад, а також зберігатиме арх1в даних про 
. . 
попередю пожеж~ та виконання задач по їх гасінню. 
У роботі використовуються сучасні технології веб-розробки, таю як 
HTML, CSS, Python, Django та база даних PostgreSQL для зберігання 
інформації. Додаток розроблений з урахуванням принципш зручност1 
використання, безпеки даних та швидкості реакції на події. 
Очікується, що розроблений веб-додаток значно полегшить роботу 
працівників пожежної частини, шляхом зменшення часу реакції на пожежні 
випадки та сприятиме кращій координації пожежних бригад. Такий інструмент 
є особливо важливим у вимогливому середовищі пожежної діяльності, де 
швидка реакція та ефективне керування мають вирішальне значення. 
Ключові слова: автоматизоване робоче місце, веб-додаток, пожежний, 
клієнт-сервер. 
ANNOTATION 
Andriychuk Vyaches]av 
Automated workplace of а fiгefigl1teг 
121 - Softwaгe engiпeei·ing 
Cherkasy State Tecl111ological Uпiveгsity 
Cherkasy, 2023 
The qualification woгk is devoted to the development of а web application for 
the automation of а fiгefighter's woгkplace. The aim of the thesis is to create а 
conveпient and effective tool that will help fire department dispatchers in managing 
and 111onitoring fire activity. 
The application will provide dispatchers with the opportunity to record 
information about the occurrence of fires, the state of fire equipment and the location 
of fire brigades. lt will also provide functionality for registering calls, planning and 
coordinating the work of fire brigades, as well as keeping an archive of data оп 
previous fires and their extinguishing tasks. 
The work uses modem web development technologies such as НТМL, CSS, 
Python, Django and the PostgreSQL database for information storage. The 
application was developed taking into account the principles of ease of use, data 
security and speed of reaction to events. 
It is expected that the developed web application will significantly facilitate the 
work of fire department employees Ьу reducing the response time to fire incidents 
and contribute to better coordination of fire brigades. Such а tool is especially 
important in the demanding firefighting environment, where quick response and 
effective control are critical. 
Keywords: automated workplace, web application, firefighter, client-server. 
ЗМІСТ 
ПЕРЕЛІК УМОВНИХ П.ОЗНА 1.ffіНЬ ... .... ... ..... ...... ............................................ 5 
ВСТУП .... ... ... .... ....... ..... ................................... .... .............................. .................... б 
1 ІСНУЮЧІ МЕТОДИ ТА ЗА ОБИ РОЗВ 'ЯЗАННЯ ПОСТАВЛЕНИХ 
ЗАВДАНЬ ........................................... ........ ......................... ...................... ............ 8 
1.1 Опис предметної області ................................ .......................................... 8 
1.2 Опис аналогів ........................................................................................... 1О  
1.3 Актуальні проблеми, що виникають в процесі розробки АРМ .......... 13 
1.4 Методи та засоби, які вже використовуються для розробки АРМ .... 14 
1.5 Конкретизація завдань роботи ............................................................... 15 
2 ПРОЕКТУВАННЯ ПРО ГР АМН ОГО ЗАБЕЗПЕЧЕННЯ СИСТЕМИ ....... 19 
2.1 Предметна область моделювання ............................................... ....... .... 19 
2.1.1 Модель предметної області ......................................................... 19 
2.1.2 Словник предметної області ............. .......................................... 19 
2.1.3 Елементи моделювання предметної області ................. ... ... ...... 21 
2.1.4 Робоча область моделювання ..................................................... 22 
2.2 Формування та аналіз вимог до програмного забезпечення .. ......... ... 23 
2.2.1 Первинні і детальні вимоги ................................. .. ................. ... .. 23 
2.2.2 Вимоги замовника і розробника ....................................... .......... 24 
2.2.З Функціональні та нефункціональні вимоги ............... .. ............. 26 
2.2.4 Формування вимог за допомогою діаграми прецедентів ......... 27 
2.3 Проектування логічної структури програмного комплексу ............... 28 
2.3.1 Діаграми класів ............... ....... ... .................................................... 28 
2.3.2 Діаграма пакетів ....... ...................................... .. ... ........... .............. 29 
2.4 Арютектурне проектування ................................................................... 30 
2.4.1 Діаграма компонентів ..................... .......... ..... .......... .................... 30 
2.4.2 Розгортання програмної системи на апаратних засобах. 
ЧДТУ.232097.001 ПЗ 
Зм Арк №докvм. 3п~~і~І .-J, ~ ~Л~а~та~-----------1-Л;и-т:. :-г-Л;и~с:т, ---;;;::::-, Розnоб. Анnnійчvк в. Листів 
""r'-,'-1----t АВТОМАТИЗОВАНЕ І І 
Пров. Голуб с.в. І rЛ~ ✓ РОБОЧЕ МІСЦЕ 3 102 
'-~ 1-1 ПОЖЕЖНОГО ФІТІС, 
Н .контр, Півень О.Б. ~ ~ - група ПЗС-2044 
ГолvбС.В. ~~ ./ 
~ 
Діаграма розгортання ......... ................ .. ............. ............................................... з 1 
2.4 Моделювання поведінки системи ... ............ ............ ..... .. .. .. ............ ........ 34 
2.4.1 Діаграма діяльності ... ....... ........... ............ .... .. .... ... ........... .. ............ 34 
2.4.2 Діаграма посл ідовності ...... ................... ................ ............. .......... 35 
2.4.3 Діаграми комунікації ............................................... : .... .. ... .. .. .. ..... 37 
2.4.4 Діаграма скінченого автомата ........ .. .. ........ ...... .. ....... .. ................ 37 
З К ОІ~СТ. РУІОВАІ, 1-ІЯ ПРОГРАМНО!..  СИСТЕМИ ...... ... .... ..... ......... .. ........ .. 39 
3.1 Розробка програмного комплексу .............. .. ..... ..... .... .... ... .. ... ................ 39 
З .1 .1 Обrрунтування вибору засобів реалізації ....... ..... ....... ........ ........ 39 
З .1.2 Опис структурної ( функціональної) схеми ...... .... ... .................. .46 
З .1.3 Опис логічної схеми системи ............................ ... ............ ......... . .47  
3.1.4 Розробка бази даних ................ ........... ..... ............... ..... ................. 50 
3.1.5 Розробка інтерфейсу користувача ................... ............................ 52 
3.1.6 Опис розробки програмних компонентів ......... .... :. .... ......... .. ..... 54 
3.2 Тестування програмної системи ............................. ................................ 56 
3.2.1 Модульне тестування ................................................................... 56 
3.2.2 Інтеграційне тестування ..... .. ............................ .... ._ . ........... .. ......... 59 
3 .2.3 Системне тестування .................................................................... 60 
3.2.4 Приймальне тестування ................................................ ........ ....... 61 
висновки ....................................................................................... .. .. ........ ...... 63 
СГІИСОК ВИК ОРИСТАНИХ ДЖЕРЕЛ ········· ····················· ····· ·· ··········· ··· ········64 
ДОДАТКИ ....................................... .... ....................................... ........................ 65 
Лист 
ЧДТУ.232097.001 ПЗ 4 
,..., _~ , ,. Пата 
ЧДТУ.232097.001 ПЗ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ 
АРІ - Application Pгog1·aшming Interface 
CSS - Cascading Style Sheets 
HTML - Hypeгtext Maгkllp Laпguage 
РК - Р1·і111агу Кеу - первинний ключ таблиці 
FK - Foreign Кеу - зовнішній ключ 
SQL - Stгuctured Query Language 
АРМ - Автоматизоване робоче місце 
БД - Базаданих 
ос - Операційна система 
ПЗ - Програмне забезпечення 
ПК - Персональний комп'ютер 
СКБД - Система керування базами даних 
5 
ЧДТУ.232097.001 ПЗ 
ВСТУП 
Актуальність теми. Дана кваліфікаційна робота присвячена розробці 
автоматизованого робочого м1сця для пожежного, яке дозволяє спростити та 
покращити процес ведення документації та управління пожежною безпекою. Дане 
програмне забезпечення було розроблене з метою полегшення організації роботи 
nожежниюв. 
У роботі з перспективи інженерії програмного забезпечення розглядаються 
основні проблеми, з якими стикаються пожежні служби при виконанні своїх 
обов'язків, а саме неефективне ведення документації, ускладнений доступ до 
необхідної інформації та складність управління в разі виникнення пожежі. 
Мета і завдання розробки. Метою бакалаврської роботи являється 
розробка програмного забезпечення для автоматизації робочого місця пожежного, 
що дозволяє спрощувати процеси ведення документації та управління пожежною 
безпекою. 
Об'єкт розробки процеси обробки даних в пожежних службах. 
Методи проектування та конструювання . 
У роботі розглядалися основні етапи розробки веб-додатку, таю як 
формалізація вимог, моделювання предметної області , об'єктна-орієнтоване 
проектування та тестування і верифікація. В процесі розробки бу ли використані 
сучасні технології, такі як HT:tv1L, CSS, Python, Django, PostgreSQL та інші. 
Опис отриманих результат1в. У ход~ розробки був проведений 
порівняльний аналіз існуючих програмних систем, що автоматизують робоче 
місце пожежного. Це дозволило побачити переваги та недоліки інших рішень та 
врахувати їх при розробці власного програмного продукту. 
Основні функціональні можливості розробленого ПЗ автоматизованого 
робочого місця для пожежного, включають у себе: збір та обробку інформації про 
об'єкти, що підлягають пожежному контролю, зберігання та аналіз даних, а також 
планування роботи пожежних команд під час виникнення пожежі. 
6 
ЧДТУ.232097.001 ПЗ 
Практичне значення отриманих резуJJьтатів. 
Отримані результати дозволиJщ розробити ефеІ(тивний та функціональний 
програмний продукт, який може бути використаний пожежними службами як 
основа для подальшого розвитку та вдосконалення системи пожежної безпеки 
населеного пункту. 
7 
ЧДТУ.232097.001 ЛЗ 
1 ІСНУЮЧІМ ТОДИ ТЛ ЗЛ ОГИ РОЗО'ЯЗЛЕJНЯ ПО ТАВЛЕНИХ 
ЗЛU/\Л І 11 
І . І Опис пре;,мсттюї області 
Розглянемо преJ,"' М ',".' 'ТІ---.'  о бJ 1асть з перспективи ·1 нженерl·Ї  програмного 
забезпечення . Пожежна область охоплює всі аспекти, пов'язані з попередженням, 
гасінням та управлінням наслідками пожеж. Дана область дослідження має 
важливе значення для забезпечення безпеки життя та майна людей, а також для 
збереження екологічної рівноваги. 
Основні завдання пожежної області - забезпечення безпеки людей та їх 
майна, попередження виникнення пожеж та мінімізація їх наслідків. Для 
досягнення цих цілей використовуються різноманітні засоби та методи, які мають 
на меті запобігання виникненню пожеж, раннє виявлення та локалізацію вогню, 
ефективне гасіння та управління наслідками пожеж. 
Основні завдання пожежної області можна розбити на декілька категорій: 
1 попередження виникнення пожежі. Попередження пожеж пов'язане з 
розробкою та впровадженням систем пожежної безпеки, які мають на меті 
запобігання виникненню пожеж та зменшення їх наслідків. 
2 раннє виявлення та локалізація пожежі. Передбачає використання 
спеціального обладнання та технологій для виявлення пожежі на ранній стадії, а 
також швидке реагування та локалізація вогню. До складу систем пожежно~ 
безпеки входять різноманітні пристрої, такі як детектори вогню, пожежна 
сигналізація, реле автоматичного вимкнення електропостачання, газу та ін .. Вони 
дозволяють автоматично виявляти пожежу, та реагувати на неї системами 
автоматичного вимкнення електроенергії та газу, а також системами оповіщення 
для евакуації людей. 
З ефективне гасіння пожеж~. Передбачає використання різноманітних 
методів та засобів для припинення поширення вогню та ло.калізації пожежі. 
Гасіння пожеж _ це процес виявлення, локалізації та припинення поширення 
вогню. Для цього використовують різноманітні засоби, такі як пожежні машини, 
8 
ЧДТУ.232097.001 ПЗ 
пожежні рукави та інші пристрої. Гасіння пожеж потребує великої кваліфікації та 
досвіду, тому пожежні служби проводять регулярні навчання та тренування . 
4 управління наслідками пожежі . Передбачає оцінку шкоди, завданої 
вогнем, та відновлення пошкодженого майна, а також надання допомоги 
постраждалим. У цьому процесі беруть участь різноманітні служби та організації, 
які забезпеч ють безпеку та допомагають постраждалим. 
Розвиток пожежної області тісно пов'язаний з розвитком технологій та 
науки , що дозволяє створювати більш ефективні методи та засоби управління під 
час пожежогасіння. Розроблене програмне забезпечення (ПЗ) автоматизованого 
робочого місця (АРМ) пожежного має супроводжувати його, на протязі рішення 
всіх вище перерахованих задач по забезпеченню безпеки людей та майна в разі 
виникнення пожежі. А тому АРМ повинно відповідати ряду вимог, яю 
забезпечують безпеку та ефективність роботи пожежного рятувальника. До 
основних вимог можна віднести: 
1 надійність. ПЗ АРМ повинно бути стійким до умов та забезпечувати 
безперебійну роботу під час надзвичайних ситуацій як з персонального 
комп'ютера так і з мобільного пристрою; 
2 легкість у використанні та інтуїтивно зрозумілий інтерфейс. Пожежники 
зазвичай працюють в умовах стресу та під час обставин, що швидко змінюються. 
Тому важливо, щоб інтерфейс АРМ був простим та зрозумілим, а функціонал -
максимально зручним для використання в умовах надзвичайних ситуацій; 
З можливість швидкої та ефективної обробки інформації. У разі пожеж~ 
кожна секунда має значення. АРМ повинно забезпечувати можливість швидкого 
доступу до потрібної інформації та її ефективної обробки; 
4 інтеграцію з іншими системами та технологіями. Автоматизоване робоче 
місце повинно бути інтегроване з іншими системами та технологіями, яю 
використовуються пожежними рятувальниками. Наприклад, системою 
моніторингу пожеж, мережею зв'язку та іншими; 
5 безпеку використання та відповідність нормам та стандартам; 
ЧДТУ.232097.001 ПЗ 
На сьогоднішній день практично кожна державна організація має власне 
програмне забезпечення, що аnтоматиз с робоче місце його працівників. А в 
сучасних умовах зв' я · ани, L1,и сІ> 1юві1а1_ 1,  ·1 ,. · 1с1 
~ використання сучасних 
·нформаційних техно лоп·н v  є нео б х·щ 1 ' , ним чинником ефективного функціонування. 
L. 2 Опис аналогів 
І н 'С кшька Р алізацій ПЗ ЛРМ диспетчера пожежних частин, яю 
викори т вують я для ефективного керування та координації пожежно­
рятувальними діями. Наведемо декілька прикладів таких реалізацій : 
І FiгeServiceRota; 
2 FireDispatch; 
3 FireincidentTracke1·. 
Детальніше опишемо кожну із наведених вище систем: 
Програ.мне забезпечення FireServiceRota 
Це інформаційна система управління графіками роботи пожежних членів, 
яка надає різноманітні можливості для ефективного планування та координації 
графіків роботи в пожежній частині. До функціональних можливостей відносять: 
планування графіків роботи: Система дозволяє диспетчерам планувати 
графіки роботи пожежних членів, включаючи розподіл змін та робочих годин. 
Вона надає інтерактивний інтерфейс для внесення та зміни графіків роботи; 
розподіл ресурсів: FireServiceRota допомагає визначити оптимальний 
розподіл ресурсів, таких як пожежна техніка та персонал, відповідно до потреб та 
вимог пожежної частини. Вона забезпечує можливість визначати належюсть 
пожежників до конкретних змін та робочих груп; 
керування графіками замін: Система дозволяє ефективно керувати 
замінами пожежних членів. Вона може автоматично розподіляти заміни на основі 
зазначених правил та обмежень. Диспетчер може внести зміни до графіків замін у 
режимі реального часу; 
календарні функції: FireServiceRota може м1стити календарю функції, 
10 
ЧЛТУ.232097 .00 І І ІЗ 
що дозволяють вщстежуnати свята , nих ію1і Jщ і та i 11rrri rюл11 , яю впливають на 
графіки роботи nожежних. Це доnомш·ас уникнути конфліктів та забезпечити 
належну організацію графіків роботи ; 
- звітність і аналітика : Система може надавати звпи та аналітику про 
графіки роботи, працездатність персоналу , навантаження та інші важливі 
показники . Це допомагає диспетчерам зрозуміти ефективність та продуктивність 
роботи пожежної частини· 
Програмне забезпечення Fi,·eDispatch 
Дана інформаційна система забезпечує швидку та ефективну передачу 
викликш пожежно-рятувальним одиницям. Вона надає інтерфейс для отримання 
викликів в реальному часі , пріоритизації та розподілу їх між різними одиницями. 
До функціональних можливостей системи відносять : 
прийом та реєстрація викликів: Система дозволяє диспетчерам приймати 
виклики про небезпеку пожежі або інших пожежних подій. Вона реєструє 
інформацію про виклик, включаючи місцезнаходження, тип події та інші важливі 
деташ; 
кваліфікація виклику: FireDispatch допомагає диспетчерам ощнити 
серйозність та пріоритетність кожного виклику. Вона використовує задаю 
протоколи та алгоритми для визначення необхідного ршня реагування та 
ВІДПОВІДНОГО ресурсу; 
направлення ресурсш: Система дозволяє диспетчерам ефективно 
направляти пожежно-рятувальні одиниці до місця події. Вона враховує доступні 
ресурси, розташування та навантаження різних одиниць, щоб забезпечити 
оптимальне розподілення ресурсів; 
комерційний моніторинг: FireDispatch може бути штегрована з 
системами моніторингу пожежних сигналів та протипожежної сигналізації. Вона 
автоматично отримує та обробляє сигнали, що надходять в реальному час1 , та 
ідентифікує важливі пожежні події; 
комунікація та взаємодія: Система надає засоби комунікації м1ж 
11 
ЧДТУ.232097.001 ПЗ 
диспетчерами та пожежними Ц 
. одиницями . е можуть бути радіозв'язок, текстові 
повщомлення або інші к · . .., · 
. . омуншащин1 канали . Вона також забезпечує можливість 
обмшу шформацією 3 іншими супутніми системами, такими як АРМ пожежного 
диспетчера або сист ми сліл вання пожежним відл.ілам . 
ПрограJІ,rн забезп ?че ,-тя Pi1·el,1cident1'1-·acker 
Це ін форма щ·н"н а система в~· дстеження пожежних rюдjй, яка призлачена для 
ефективного керування та контролю над пожежами та інцидентами. До 
функціональних можливостей системи: відносять : 
реєстрація подій: Система дозволяє з б ер1· гати та в·щ стежувати 
інформацію про пожежні події, включаючи деталі про місцезнаходження, час 
виникнення, тип події, обсяг пошкоджень та інші важливі параметри; 
сповІщення та повідомлення: FireincidentTracker надає можливІсть 
автоматичного сповіщення відповідальних осіб про нові пожежні події або зміни 
статусу Існуючих подій. Це допомагає забезпечити швидку реакцію та 
координацію дій; 
моніторинг та візуалізація: Система забезпечує можливість візуального 
відображення пожежних подій на карті або графіках. Це дозволяє операторам 
швидко ор1єнтуватися у ситуації та вживати н~обхідні заходи для управшння 
ПОДІЯМИ; 
зберігання даних та аналпика: FirelncidentTracker забезпечує 
централізоване зберігання даних про пожежні події, що дозволяє проводити 
аналіз та генерацію звітів . Це допомагає здійснювати оцінку ефективності, 
виявляти тенденції та покращувати стратегію реагування; 
інтеграція з іншими системами: FirelncidentTracker може бути 
інтегрована 3 іншими системами безпеки та рятування, такими як система 
моніторингу пожежної сигналізації, системи відеоспостереження або система 
автоматичного сповіщення. Це дозволяє отримувати зв'язані дані та забезпечувати 
єдиний інформаційний простір для управління екстреними ситуаціями. 
можливосп приведених вище інформаційних систем, 
Підсумовуючи 
12 
ЧДТУ.232097.001 ПЗ 
11редставимо порівняльну таблицю 1.1 з характеристиками АРМ систем 
fireServiceRota, FireDispatch, Fireincide11tT1·acker. 
Таблиця 1.1 
Аналіз можливостей програмних систем 
№ 
J FireServiceRota Планування + Ефективне + $99.00/міс. 
графіків планування 
роботи графіків та 
пожежних ресурсш 
членів 
2 FireDispatch Передача + Швидка + н/з 
викликів передача 
пожежно­ ВИКЛИКІВ 
рятувальним пожежно­
ОДИНИЦЯМ рятувальним 
одиницям 
З FirelncidentTracker Відстеження + Швидке + н/з 
та керування вщстеження 
пожежними та обробка 
ПОДІЯМИ пожежних 
подій 
1.3 Актуальні проблеми, що виникають в процесі розробки АРМ 
Розробка ПЗ автоматизован01 робочої м1сця пожежного має свої 
особливості та потенційні проблеми, які можуть виникнути під час процесу 
розробки. Перерахуємо декілька актуальних проблем, які можуть виникнути: 
1 відповідність нормативним вимогам: АРМ пожежного повинно 
відповідати ряду нормативних вимог 1 стандарпв безпеки, яю встановлею 
органами, відповідальними за пожежну безпеку. Проблема полягає у впевненості, 
13 
ЧДТУ.232097.ООІ ПЗ 
що розроблене АРМ відповідає всім необх ідним вимогам та нормам ; 
2 інтеграція з існуючою інфраструктурою : У багатьох випадках АРМ 
пожежного повинно бути інтегроване з існуючою інфраструктурою, такою як 
системи спостереження, пожежна сигналізація, тощо. Це може становити 
проблему через різноманітність технологій та стандартів, використовуваних у 
різних системах; 
З забезпечення надійності та стійкості : АРМ пожежного є критично 
важливою системою, і вона повинна працювати надійно та без збоїв у будь-який 
час. Проблеми можуть виникати з причин непередбачуваних ситуацій, помилок 
програмного забезпечення або нестабільного обладнання; 
4 захист від кібератак: З огляду на зростання кіберзагроз та кібератак, 
важливо забезпечити високий р1вень захисту АРМ пожежного вщ 
несанкцюнованого доступу та зловживання. Проблеми безпеки можуть виникати 
через вразливості в програмному забезпеченні, недостатні заходи безпеки мережі 
або недостатню кваліфікацію персоналу; 
5 навчання та тренування персоналу: Ефективне використання АРМ 
пожежного вимагає належного навчання та тренування персоналу. Проблеми 
можуть виникати, якщо навчання не відповідає потребам персоналу або якщо 
немає належних засобів тренування; 
6 сумісність з різними пристроями та платформами: АРМ пожежного 
може використовуватися на різних пристроях та платформах, таких як 
комп'ютери, смартфони, планшети тощо. Проблеми можуть виникати через різні 
операційні системи, версії програмного забезпечення та обмеження ресурсів на 
р1зних пристроях. 
Ці проблеми є лише загальними прикладами того, з чим можуть зіткнутися 
розробники програмного забезпечення АРМ пожежного. Розуміння цих проблем і 
прийняття необхідних заходів для їх вирішення є важливим етапом у розробці 
ефективного та надійного програмного продукту. 
1.4 Методи та засоби, які вже використовуються для розробки АРМ 
14 
ЧДТУ.232097.00 J ЛЗ 
Для розробки АРМ 
пожежного ни1юри ·тову,оться рі 1 ні методи та засоби, 
що дозволяють забезпечити ефективну та 1 щ,,ій 11у rо·:1робку. Перерахуємо 
декілька з них: 
1 проектування. jнтерфсйсу тшристувача (анпr . User lnterface, UJ): Дпя 
створення зр чного та інт)1їтивно зрозум·1лоrо · h V 
1нтер(l'еису користувача 
використовуються методи та засоби, такі як прототипування, візуалізація, 
взаємод~я 3 кори тувачем. Це дозволяє розробникам визначити потреби та 
очjкування користувачів та врахувати їх під час розробки АРМ пожежного; 
2 моделювання та симуляція [ 1] : Для аналізу та валідації різних аспектів 
АРМ пожежного використовуються методи та засоби моделювання та симуляції. 
Наприклад, вони можуть використовуватися для перев1рки ефективності 
. . 
алгоритмш розп1знавання пожежі, моделювання поведінки системи пожежної 
сигналізації тощо; 
3 розробка програмного забезпечення: Для програмної розробки АРМ 
пожежного використовуються різні методи та засоби, такі як розробка на основі 
вимог, методології Agile [З] або DevOps, тестування та валідація програмного 
забезпечення. Також можуть використовуватися спеціальні середовища розробки, 
інс'І])ументи для контроmо версій, автоматизації процесу розробки та тестування; 
4 інтеграція з існуючими системами: Для успішної інтеграції АРМ 
пожежного з існуючими системами, такими як пожежна сигналізація, системи 
спостереження, використовуються методи та засоби, такі як стандарти комунікації 
(наприклад, Modbus), програмні інтерфейси (АРІ), протоколи обміну даними; 
5 контроль якості та тестування: Для забезпечення високої якості АРМ 
пожежного використовуються методи та засоби контролю якості та тестування, 
такі як функціональне тестування, тестування продуктивності , безпеки та 
стійкості. Це дозволяє виявляти та виправляти помилки та проблеми перед 
впровадженням системи в експлуатац1ю. 
1.5 Конкретизація завдань роботи 
Приведемо загальні вимоги до автоматизованого робочого місця 
15 
ЧДТУ.232097.00] ПЗ 
пожежного [4]: 
автоматизоване робоче місце (ЛРМ) tюжежного є програмним засобом 
створеним з метено антомати1~щїї роботи л.ан ого фахівця задт 
підвищення рез ю,тативно ·ті та ефективності його роботи . APN 
призначеннй для фуню,іонування у комп 'ютерній мережі ; 
звтомзтизовані робочі м1сця створюють для їх застосуваню 
працшниками пожежної служби, а також для його використання 1 
навчальному процесі; 
АРМ повинен мати належний науково-методичний рівень, він має бути 
написаний в доступній формі. Інформація, що в ньому міститься, має 
бути систематизована, пов'язана з практичними завданнями, що стоять 
перед фахівцем; 
автоматизоване робоче м1сце не має м1сити інформації з обмеженим 
доступом, а також орфографічних та друкарських помилок; 
АРМ має містити інформацію, що є необхідною для виконання фахівцем 
пожежної служби покладених на нього функцій. 
Процес створення і розробки АРМ включає в себе: 
- затвердження первинного технічного завдання на розробку АРМ; 
- аналіз сфери застосування; 
- розробка архітектури ПЗ; 
- вибір методу проектування, програмних засобів реалізації ПЗ; 
- розробка структури бази даних для зберігання інформації; 
- розташування інформаційних розділів, контенту і навігації; 
- дизайн, створення графічних елементів макету системи, стилів і елементів 
навігації; 
- розробка алгоритмів розв'язання задач ; 
- верифікація та тестування системи; 
- розгортання системи в мереж~; 
- розробка інструкції користувача; 
16 
ЧДТУ.232097.001 ПЗ 
І Після аналізу існуючих аналогів на ринку ПЗ було виявлено їхні переваги та 
недоліки і на основі отриманих потреб замовників, виникла наступна постановка 
задачі - розробити ефективне та надійне програмне забезпечення «автоматизоване 
робоче місце пожежного», я1<:е швидко завантажуєтьс5І та не містить надлишкової 
інформації. Система матиме наступні функціоналм-1 і можливості: 
1 авторизація користувача; 
На формі авторизації повинні бути поля для введення лопну, парою та 
кнопка яка здійснює вхід . Всього в користувачів системи буде три ролі: 
Адміністратор, Оператор та Пожежний. 
2 монпоринг звернень; 
Система міститиме журнал звернень для збереження інформації про 
надходження викликів до пожежної частини про надзвичайні ситуації. 
Адміністратор та Оператор (диспетчер) мають змогу створити нове 
звернення, деактивувати існуюче. А також всі користувачі системи мають змогу 
. . 
переглядати 1стор1ю звернень населення. 
З мон~торинг задач; 
АРМ має містити журнал виконання завдань черговими командами яю 
вирушили на виклик. Адміністратор може виконувати створення нових та 
анулювання 1снуючих задач. Переглядати задачі можуть всі користувачі. 
Змінювати статус задачі, лише пожежники. 
4 управління автопарком та командами; 
Адміністратор має змогу формувати та реструктурувати команди, 
перевіряючи статус їхньої зайнятості а також виконувати моніторинг інформацію 
про автомобілі, що закріпленні за пожежною частиною із позначенням статусу 
зайнятості. 
Для представлених завдань повинні бути розроблені: 
- архітектура ПЗ; 
- реляційна база даних; 
- користувацький інтерфейс; 
17 
ЧДТУ.232097.001 ПЗ 
- функціонал авторизації та реєстрації користувачjв; 
- передачу та зберігання конфjденційних даних в зашифрованому вигляді . 
Технічні характеристики 
Сервер на якому встановлена система повинен волод1ти наступними 
мінімальними характеристиками: 
- CPU: 2х Intel Xeon 2Ghz· 
' 
- RAM 4096 МЬ; 
LAN: І ОО Mbps; 
встановлений: сервер додатків Apache Tomcat, та БД: Postgres. 
Для відображення АРМ пожежного необхідний ПК, планшет або телефон з 
роздільною здатністю екрану 1280х720 і більше, наявність браузера з оновленням 
до останньої версії. 
АРМ пожежного відкритий 1з мобільного пристрою повинен бути 
адаптивним та сумісним зі смартфонами сімейства Apple (починаючи з: iPhone5s 
+; іРаdЗ+) та Android (починаючи з Android 4.0+) . 
Для запуску розробленої системи, кшєнт повинен мати наступн1 
характеристики: 
CPU: 2xCore 1Ghz; 
- RAM 10 24 МЬ; 
- ОС: Windows, Linux, MacOS, IOS, Android; 
браузер з підтримкою НТМL5, CSSЗ, JS. 
ЧДТУ.232097 .001 ПЗ 
2 ПРОЕКТУВАННЯ ПРОІ РЛМНОJ О ЗЛGЕЗПЕЧЕННЯ СИСТЕМИ 
2.1 Прс;~метна область М<mелrоватrя 
2·1·1 Модель nредм~тної облс'Істі 
Модель предметно·•· ()6J1a,,,,·, ЛJ>М · б 
"' ПОЖЄЖНОГ'О В І !~О ражає структуру та 
функціональність. системи.. в 
она допомагає розробникам та защкавленим 
сторонам зроз міти як1· су,-пос,, • ... · · 
· , .-, 1, взаємодн та процеси присутн1 в систем1 . 
Основні компоненти :моделі предметної області для ПЗ АРМ пожежного можуть 
включати: 
1 пожежні об'єкти: Це можуть бути будівлі, споруди, прим1щення або 
території, які підлягають пожежному контролю та нагляду. Кожен пожежний 
об'єкт може мати свої характеристики, такі як адреса, тип будівлі, площа та інші 
важлив1 в1домості; 
2 пожежна інфраструктура: Це включає системи та пристрої, що 
використовуються для пожежного контролю, виявлення та попередження. Сюди 
входять пожежна сигналізація, автоматичні спринклерні системи, системи 
димових і теплових датчиків, пожежні гідранти тощо; 
З ресурси та обладнання: що включає ресурси, доступні для використання 
при пожежному втручанні, такі як пожежні автомобілі, засоби пожежогасіння 
(вогнегасники, п1но-генератори тощо), рятувальне обладнання, засоби 
індивідуального захисту (шоломи, костюми тощо); 
. . . 
4 корисrувачі системи: включає пожежний персонал, адм1н1страторш 
системи, операторів та інших осіб, які працюють з АРМ пожежного. Кожен 
користувач може мати свої ролі, права доступу та обов'язки; 
5 процеси та функції: включає різні процеси та функції, які здійснюються 
в АРМ пожежного, наприклад, моніторинг пожежних об'єктів, реагування на 
пожежі, розподіл пожежних ресурсів, навчання персоналу, створення звітів тощо. 
2.1.2 Словник предметної області 
Перерахуємо терміни, які можуть бути включею в словник предметно~ 
19 
ЧДТУ.232097 . 001 ПЗ 
області пожежної частини : 
1 АРМ (Автоматизов0а. 1-·1 а J> )с\:Ю 4а м1· ( сце ) 11ожежног·о : програмна система, 
яка надає функціональність ,,1_1,л я ес/>с1<·1 ·и1зt101 ·<> · б 
управт ння пожежною езпекою, 
включаючи моніто.р ин1~ \ виявлення пожеж, реагування на них , керування 
пожежною інфрас1 Р кт рою, збір та а.наліз даних; 
2 пожежний персонал: Кваліфіковані фахівці, яю виконують завдання 
п ожежного контрол ю, розсл·щ ування пожеж, рятування та надання першої 
допомоги; 
3 пожежна рятувальна бригада: Група пожежних, яю відповідають за 
боротьбу з пожежами 
' рятування людей та надання допомоги шд час 
надзвичайних ситуацій; 
4 пожежний автомобіль: Автомобіль, оснащений спец~альним 
обладнанням для боротьби з пожежами, включаючи водяні насоси, вогнегасники, 
рятувальні пристрої тощо; 
5 диспетчер пожежної частини: Особа, відповідальна за керування та 
координацію діяльності пожежної частини, включаючи прийом і обробку 
пожежних викликів та надання відповідних вказівок пожежному персоналу; 
6 пожежний виклик: Сигнал, що надходить до пожежної частини вщ 
особи або організації, яка повідомляє про наявність пожежі або іншої 
надзвичайної ситуації, яка потребує пожежного втручання; 
7 розташування пожежі: Інформація про місце, де відбувається пожежа, 
включаючи адресу, орієнтири або географічні координати; 
8 керування пожежними ресурсами: Процес розподілу та використання 
пожежних автомобілів, обладнання та персоналу для ефективного реагування на 
пожежні виклики; 
9 комунікації та зв'язок: Системи та протоколи комунікації, 
використовувані для передачі інформації між диспетчером пожежної частини, 
пожежним персоналом та іншими структурами надзвичайних ситуацій; 
1о  пожежні протоколи та процедури: Інструкції та стандарти, що 
20 
ЧДТУ.232097.ООJ ПЗ 
р еrулюють дїї пожежн·  ого персоналу ш·д  час реагування на пожеж~,·  включаючи 
nроцедури евакуацїї, використання пожежних засобів, координацію рятувальних 
оnерацій тощо; 
11 журнал ложежни, вию1иІ(ів: Документація , яка ведеться диспетчером 
nожежної частини і м · , , · ф · . . 
· 1с1и1 ь 11-1 ормац~ю про вс 1 пожежн, виклики, включаючи 
дату, час, розташування, вид надзвичайної ситуації та відповідь пожежного 
персоналу; 
12 екстрена медична допомога: Надання першої допомоги постраждалим 
особам під час пожежі або надзвичайної ситуації до прибуття медичних служб. 
2.1.3 Елементи моделювання предметної області 
Елементи моделювання предметної області включають в себе [ 1О ] : 
Сутності - це об'єкти або концепції, які існують в предметній області . У 
нашому проекті можуть бути наступні сутності: Користувач (Адміністратор, 
Оператор, Пожежний), База даних, Виклики, Задачі, Команди, Автомобілі . 
Атрибути - це характеристики сутностей, які мають значення і дозволяють 
ідентифікувати та описувати сутності. У нашому проекті можуть бути наступні 
атрибути: для сутності Користувач - ім'я, прізвище, логін та пароль, для сутності 
Виклик - адреса, опис, статус, час створення, для сутності Задача - адреса, опис, 
команда, автомобіль та ін.с, Для сутності Автомобіль - статус, місткість баку з 
водою, місткість баку з піною, витрати пального та ін .. 
Відносини - це зв'язки між сутностями. У нашому проект~ можуть бути 
наступні відносини: Адміністратор може додавати, редагувати та видаляти 
Виклики та Задачі в базі даних, переглядати історію викликів. Пожежний може 
зходити в систему для перегляду назначених задач, змінювати їх статус 
1иконання. 
Асоціації - це відносини між сутностями, що показують, як вони пов'язані 
tіж собою. у нашому проекті можуть бути наступні асоціації: Адміністратор та 
)ператор мають доступ до всіх викликів. Для одного Виклику створюється одна 
Іадача. В одній задачі задіяна одна Команда та Автомобіль. Команда може 
21 
ЧДТУ.232097.001 ПЗ 
містити багато пожежних. В один момент часу може бути задіяні багато Команд. 
При nроектуванні системи та моделюванні предметної області ми будемо 
використовувати мов UMC. ) \ля створення д1аграм в мов1 UМL 
використовуються трн типи ві ·з алмн~х пu·тачень: графічні символи , зв'язки, що 
об'єднують елементи., тз теt<ст. 
2.] .4 Робоча область моделювання 
Робоча обла ть моделювання АРМ пожежної частини включає широкий 
спектр функцій та процесів, пов'язаних з керуванням та координацією роботи 
пожежної частини. Деякі з ключових елементів робочої області моделювання 
мож.,-уть включати: 
Відображення карт: Робоче місце диспетчера пожежної частини часто має 
відображення карт, на яких відображаються місцезнаходження пожеж, адреси 
об'єктів, стан пожежних розташувань та інша важлива інформація. Моделювання 
такого відображення карт може включати створення інтерфейсу для навігації по 
карті, позначення різних об'єктів та відображення їх стану. 
Сповіщення та комунікація: АРМ диспетчера пожежної частини повинна 
забезпечувати ефективну комунікацію між диспетчером та пожежною бригадою. 
Це може включати моделювання функціоналу для прийому та розсилки екстрених 
повідомлень, виклику пожежних машин, взаємодії з іншими службами екстреної 
допомоги тощо. 
Управління ресурсами: ,для ефективного управління пожежною частиною, 
АРМ диспетчера повинна забезпечувати функціонал для контролю та розподілу 
ресурсів, таких як пожежні машини, обладнання, персонал тощо~ Моделювання 
цього аспекту може включати створення інтерфейсу для відстеження доступних 
ресурсів, планування їх використання та призначення на конкретні завдання. 
Обробка інформації: АРМ диспетчера повинна мати можлив1сть 
отримувати, обробляти та аналізувати різноманітну інформацію, таку як даних з 
датчиків, даних про пожежні розташування, інформацію про об'єкти тощо. 
Моделювання цього аспекту може включати створення алгоритмів для обробки та 
22 
ІДТУ.232097 .001 ПЗ 
аналізу даних, відображення результатів та прий1-1яття рішень на основі отриманої 
інформації. 
Запис звітність: АРМ диспетчера повинна забезпечувати можлив1сть 
записувати інформацію про події, здійснювати звітність та архівування даних для 
подальшого аналізу. Моделювання цього аспекту може включати розробку 
функцюналу для запису подій, генерації звітів та управління архівними даними. 
2.2 Формування та аналіз вимог до програмного забезпечення 
2.2.1 Первинні і детальні вимоги 
Формування загальних вимог до ПЗ складається з формування первинних і 
детальних вимог, які ми перерахуємо нижче. При розробці АРМ важливо 
визначити І сформулювати первиню вимоги, яю відображають основн1 
функціональні та нефункціональні вимоги проекту. Перарахуємо загалью 
первинні вимоги, які виникають при створенні АРМ: 
І прийом та обробка пожежних викликів: Система повинна забезпечувати 
прийом і реєстрацію пожежних викликів, а також ефективну обробку цих 
викликів диспетчером. Це включає реєстрацію деталей виклику, встановлення 
пріоритету, відстеження стану та виклику необхідних пожежних ресурсів; 
Z моніторинг та координація пожежного персоналу: АРМ повинна 
забезпечувати відстеження розташування пожежного персоналу та пожежних 
одиниць на мапі або плані району обслуговування. Диспетчер повинен мати 
можливість надсилати вказшки та інформацію пожежному персоналу, 
встановлювати комунікацію та координувати їхні дії; 
З зберігання та доступ до інформації: АРМ повинна мати систему 
зберігання та доступу до різних типів інформації, такої як контактні дані осіб, 
пов'язаних з пожежною частиною, плани будівель, мапи району, інструкції та 
процедури реагування на пожежу, журнали пожежних виклиюв тощо; 
4 комунікація та зв'язок: АРМ повинна мати засоби для ефективної 
комунікації з пожежним персоналом, іншими диспетчерськими центрами, 
23 
ЧДТУ.232097 .00 1 ПЗ 
медичними службами та jншими струю·урами надзвичайних ситуацій. Це може 
вкл10чати систему радіозв'язку , інтерком або систему передачі повідомлень; 
5 моніторинг систем безпеки: АРМ може включати функції моніторингу 
систем безпеки , таких як пожежна сигналізація, системи контролю доступу, 
відеоспостереження тощо . Диспетчер повинен мати можливість отримувати 
сповіщення про виникнення пожеж або інших надзвичайних ситуацій та вживати 
відповідних заходів; 
6 забезпечення резервування та надійності: АРМ повинна мати системи 
резервного живлення та резервного зберігання даних для забезпечення 
безперебійної роботи в разі відключення основних джерел живлення або випадку 
відмови обладнання. 
2.2.2 Вимоги замовника і розробника 
До вимог розробника відносимо наступні: 
... 
Реєстрація та авторизація: Забезпечення можливосп реєстрацн та 
авторизац11 користувачів пожежної частини для доступу до системи з 
використанням безпечних механізмів автентифікації. 
Відображення інформації: Забезпечення зручного та інтуїтивно зрозумілого 
інтерфейсу, який дозволяє користувачам системи відображати та переглядати 
інформацію про пожежі, об'єкти, пожежні машини, команди тощо. 
Система сповіщення: Можливість отримувати сповіщення про пожеж~, 
аварії та інші події з допомогою різних каналів зв'язку, таких як телефон, 
електронна пошта або месенджери. 
Управління ресурсами; Забезпечення функціоналу для керування 
розподілом та використанням ресурсів, таких як пожежні машини, обладнання, 
персонал тощо. Включає можливість створення та призначення завдань, 
відстеження доступності ресурсів та оптимізацію їх використання. 
Керування подіями : Забезпечення можливості записувати та відстежувати 
події, що відбуваються в системі, такі як реєстрація пожеж, взаємодія з 
пожежними бригадами, відправка ресурсів тощо. 
24 
ЧДТУ.232097.ООJ 113 
Забезпечення безпеки: Забезпечення заходів безпеки та конфіденційностj 
даних, включаю-qи ЗЗ)<ист від несанкціонованого доступу, резервне копіювання 
даних та захист від втрати jнформації. 
Інтеграція з іншими система . М . . ... . 
ми. ожливJсть штеграцн з шшими системами, 
такими як системи виклику екстрен01··  допомо. ги, системи моют· орингу пожеж та 
інші, для обміну даними та спільної роботи. 
Підтримка та супровід: Забезпечення підтримки та супроводу програмного 
забезпечення, включаючи надання документації, навчання користувачів та 
вирішення можливих проблем. 
Вимоги розробника програмного забезпечення АРМ пожежного включають 
наступю аспекти: 
1 Функціональні вимоги: 
розробка інтерфейсу користувача, що забезпечує зручний та 
ефективний доступ до всіх необхідних функцій та операцій; 
реалізс;1ція механізмів авторизації та автентифікації для забезпечення 
безпеки та конфіденційності даних; 
розробка функціоналу для відображення та навігації по карт~ з 
можливістю позначення об'єктів, місцезнаходження пожеж, ресурсів 
тощо; 
реалізація системи сповіщення та комунікації для ефективного обміну 
повідомленнями між диспетчером та пожежною бригадою; 
розробка функціоналу для управління ресурсами, включаючи розподіл 
та призначення пожежних машин, обладнання та персоналу на 
завдання; 
реалізація алгоритмів для обробки та аналізу інформації про пожежі, 
розташування, стан об'єктів та інші важливі дані. 
2 Нефункціональні вимоги: 
Забезпечення швидкодії та ефективної роботи системи, зокрема в умовах 
исо.кого навантаження та великої кількості одночасних користувачів. 
25 
ЧДТУ.232097. 00 І ПЗ 
Забезпечення високої надійності та стабільності системи, включаючи 
обробку помилок, відновлення після збоїв та запобігання втрати даних. 
Забезпечення безпеки даних та захисту від несанкціонованого доступу до 
системи та інформації. 
Врахування інтерфейсних стандартів та дизайну для забезпечення зручного 
та інтуУтивно зрозумілого інтерфейсу користувача. 
Реалізація системи резервного кошювання та вщновлення даних для 
запобігання втрати інформації. 
2.2.3 Функціональні та нефункціональні вимоги 
Функціональні вимоги визначають функції та задачі, які АРМ пожежного 
повинен виконувати. Основні функціональні вимоги до АРМ включають: 
1 прийом та обробка пожежних викликів: Забезпечення можливості 
прийому, реєстрації та обробки пожежних викликів, включаючи отримання 
. інформації про м1сцезнаходження події, опис події та встановлення пріоритету 
виклику; 
2 керування пожежними ресурсами: Забезпечення ефективного розподілу 
пожежного персоналу, пожежних автомобілів та обладнання для в1дпов1д1 на 
пожежн1 виклики залежно від їх типу, місця розташування та ступеня 
. . 
вевщкладносп; 
З моюторинг та координац1я: Забезпечення можливосп вщстеження 
юзташування пожежного персоналу та пожежних одиниць на мапі або плані 
1айону, надання вказівок та інструкцій пожежному персоналу, координація дій та 
заємодія з іншими службами; 
4 зберігання та обробка інформації: Забезпечення системи зберігання та 
оступу до різних типів інформації, таких як контактні дані осіб, пов'язаних з 
[)Жежною частиною, плани будівель, мапи району, журнали пожежних викликів 
1 інша документація; 
5 комунікація та зв'язок: Забезпечення засобів комунікації з пожежним 
:рсоналом, іншими диспетчерськими центрами, медичними службами та іншими 
26 
ЧДТУ.232097 .ОО J ПЗ 
структурами надзвичайних ситуацій , включаючи системи радіозв'язку, інтерком 
та системи передачі повідомлень. 
Нефункціональні вимоги стосуються якості та характеристик системи, які 
визначаються не самими функціями, а їх виконанням. Основні нефункціональні 
вимоги до АРМ пожежного включають : 
1 надійність: Забезпечення стаб1·льно·1· та б езпере б.ш~н о1··  ро б оти системи, 
відсутність випадків відмов та помилок, відновлення роботи після 
випадків відмов; 
2 безпека: Забезпечення захисту даних, конфіденційності, цілісності та 
доступності інформації, а також захисту від несанкціонованого доступу 
до системи; 
З швидкодія: Забезпечення швидкої реакції системи на пожежні виклики 
та інші події, швидке відображення інформації та взаємодія з системою; 
4 зручюсть використання : Забезпечення простоти та зручносп 
використання інтерфейсу АРМ, зрозумілості та легкості навігації для 
диспетчера; 
5 сумісність: Забезпечення можливості інтеграції з існуючими системами 
та обладнанням пожежної частини. 
2.2.4 Формування вимог за допомогою діаграми прецедентів 
Діаграма прецедентів відображає функціональність системи з точки зору 
користувачів, і дозволяє аналізувати взаємодію між користувачами та системою. 
В результаті проведення моделювання предметної області, формуванню словника 
та представлення вимог до системи, ми сформуємо наступну д~аграму 
використання веб-додатку АРМ пожежного. 
На діаграмі (рисунок 2.1) відображенні основю вар~анти використання 
системи з розподілом функціональності по ролям користувачів які зареєстровані в 
даній системі. 
27 
097.001 11 і 
АдмІн1стр~о 
.... ... . 
indude , extend 
~ :'  extend 
~ 
extend 
~ - Зверн-ення 
оператор 
Рисунок 2.1 - Діаграма прецедентів 
2.3 Проектування логічної структури програмного комплексу 
2.3 .1 Діаграми класів 
Діаграма класів є одним із видів діаграм в рамках мови моделювання UМL 
Вона використовується для відображення класів, їх взаємодій та залежностей між 
ними в об'єктно-орієнтованому програмуванні. Діаграма класів містить класи, 
атрибути, методи, асоціації, спадкування та інші відношення між класами, що 
дозволяє проектувати та аналізувати архітектуру програмного забезпечення. 
Діаrрама класів розробленого веб-додатку АРМ пожежного представлена на 
рисунок 2.2. Реалізація виконана на мові програмування Python. 
28 
ЧДТУ.232097.00 І ПЗ 
--- --- ------------------
<: Model 
·---_.,__  ___,l'--~------- - . 
users.models.User t app.mo'de ls.Тask 
" app.models.Proposal 
с. app.models.Car 
rё app.models.Тe am 
Рисунок 2.2-Діаграма класів 
Дана діаграма (рисунок 2.2) описує основні класи, що використовуються в 
системі. Клас User (користувач) описує користувачів нашої АРМ. Клас Model є 
базовим для всіх класів моделі. Клас Proposal (виклик) описує виклики, що 
надходять до пожежної частини про надзвичайні ситуації. Клас Task (задача) 
описує завдання для чергової бригади (команди), яка вирушила на виклик. Клас 
Team (чергова бригада) описує чергові команди для виконання завдань. Клас Car 
(черговий автомобіль) описує автомобілі пожежної частини. 
2.3 .2 Діаграма пакетів 
На рисунку 2.3 представлена діаграма пакепв розробленого веб-додатку. 
Головний контролер django перенаправляє НТТР запити на відповідне 
представлення (пакет view) яке містять бізнес логіку додатку. Представлення в 
свою чергу які в свою чергу імпортують постачальників даних (пакет шodels) з 
бази даних проекту та управляють шаблонами (пакет teшplates) відображення 
29 
І 1 .2 О 7.00 І 11 
Views Models ---~---. 
«tn1port>) Proposal 
Task 
Team 
_ а9е Саг 
s_ ~9е 
reate_cai:_ age TaskStatus 
d.н:_с r_page 
«merge» 
Template 
cars-page.html 
create-car-page.html 
create-task-page.html 
create-team-page.html 
edit-car-page.html 
edit-team-page.html 
main-page.html 
proposal- page.html 
tasks-page.html 
te.,ms-page.html 
Рисунок 2.3 - Діаграма пакетів 
2.4 Архітектурне проектування 
2.4.1 Діаграма компонентів 
Діаграма компонентів - це вид діаграми, що використовуєть я в розробці 
програмного забезпечення для відображення архітектури сист ми та зал жність 
між її компонентами. Діаграма компонентів зображує окрем1 компоненти 
програмної системи, їх інтерфейси та залежно ті між ними. Ця д~агр 1а 
допомагає у розумінні, як окремі компоненти системи взаємодіють між об ю та 
як вони розподілені між фізичними або логічними областями. 
На діаграмі компонентів (рисунок 2. 4) нашої и т ми, о раж н взає юд1ю 
компонентів які відповідають за створення задач і (Та k) на о нові звернення 
зо 
ЧДТУ.232097.001 ПЗ 
(Proposal) використовуючи ресурси тюманд (Теат), та необхідне авто (Car). 
е] 
Опис звернення Proposal 
Task 
Кількість учасників команди 
Вирішення 
поставленої 
задачі 
.+. Team 
------------------
Характеристики 
автомобіля 
Саг 
Рисунок 2.4 - Діаграма компонентів 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання 
Васkеnd-частина 
На сервері перед тим повинен бути попередньо встановлений PostgreSQL. 
Далі нам потрібно створити базу даних «fire» за допомогою SQL-команди: 
create database fire; Наступним кроком ми описуємо конфігурацію з' єднання з 
базою даних у файлі settings.py 
import pydantic авр 
Jrom psthl.ib im.port Path 
31 
ЧДТУ.232097 .00] ПЗ 
.DA TAВASES = { 
'default': { 
'ENGINE•: 'd.ia ngo. d/J. backends.po,9t:g1·osq}._psycopl(2; 
'NАМЕ•: e11v_setti11g'S.lJB_NAМE, 
'USER': env_setti11gs.ПB_ USER, 
'PASSU10RD•: env_set-tings.DB_PASSWORD, 
'НОSТ': env_settings.DB_HOSТ, 
1
'PORT : env_,9ettings.DB_PORТ, 
} 
} 
Для зручності значення змінних які містять назву бази даних, користувача 
та пароль винесенні у файл .env: 
.DB_ USER=postgres 
DB_PASSWORD=. .. 
DB_NAМE=fire 
DB_PORТ=5102 
DB_HOSТ=localhost 
В даному проекті використовується Gitlab СІ, Gitlab runner DIND ( docker in 
docker) та сервер з ОС unbuntu 22.04. Для розгортання (deploy) системи на сервері 
необхідно виконати наступні дії: 
1 push робочої вітки коду на gitlab; 
2 запуск стадій описаних в gitlab-ci.yml; 
З gitlab-runner на сервері виконує команди задані в стадії описаної в gitlab­
ci.yml. 
Нижче описані конфігурації файлів для розгортання (deploy) системи. 
gitlab-ci.yml - файл який описує стадії deploy процесу, та які команди на 
кожній стадії бу демо виконувати. 
include: 
- template-: 'Workfl.owв/МergeRequest· Pipelines.gitlab·ci.yml' 
32 
ЧДТУ.232097 . 001 ПЗ 
services: 
· docker:23.0.5 
i.roage: docker/compose: 1.29.2 
stages: 
· deploy 
deploy: 
stage: deploy 
script: 
· docker·compose up •d •·build 
after_script: 
· docker system prune ·f 
dockeгfile - файл , що описує як відбуватиметься збірка backend додатку, яку 
версію pytl1on використовуємо, звщки кошюємо файли, яю бібліотеки 
встановлюємо, 1 також якою командою його запустити . 
FR0M python:з. 11 ·slim 
ENV PYТHOND0NТWRITEBYТECODE 1 
ENVPYТH0NUNВUFFEREDl 
СОРУ ./requirements.txt requirements.txt 
RUN рір install ·r requirements.txt 
СОРУ. арр/ 
СОРУ .env_ prod app/.env 
WORКDIRapp 
ENV РУТНОNРАТН=. 
СМD ["python", "manage.py", "runserver", "O.o.o.o:sooo"] 
На рисунку 2.5 представлена дшграма розгортання АРМ системи. 
Розгортання включає в себе наступні етапи: 
1 Підготовка серверного середовище для розгортання додатку; 
2 Встановлення залежностей ( сервер додатків, сервер баз даних); 
З Конфігурація бази даних; 
4 Розгортання веб-додатку (розміщення файлу на веб-сервері); 
33 
ЧДТУ .232097 .ОО І 113 
---5 -На-л-ашт-ув-ан-н-я ~тт·а1J--~-ам е1· 1J--1· 1 ,•  ( iy·, І . ... ...) 
<' ·сптщm<ац11 та автоrизаrш 
Робоче станція 
ВЕБ-браузер 
Користувач 
HTTP/HTTPS 
Сервер Бази Даних 
Презентаційний рівень 
(ВЕБ-інтерфейс) 
ТСР/ІР 
База даних r ІосаІ socke Інтерфейс для роботи з 
Postgres (Firel Log file 
базою даних 
Рисунок 2.5 - Діаграма розгортання системи 
2.5 Моделювання поведінки системи 
2.5.1 Діаграма діяльності 
Діаграма діяльності (англ. activity diagram) - це графічний інструмент 
моделювання, який використовується для представлення послідовності дій або 
операцій у системі або процесі. На рисунку 2.6 представлений загальний алгоритм 
використання системи у вигляді діаграми діяльності . 
34 
ЧДТУ.232097.ОО 1 ПЗ 
з11"1с• дrм 
~о••"І• ечно"о 
r-----➔ 
еєстраu,я адреса 
on1,c надз1н1uаі,но1 
с1,туаці1 
НІ 
так іlошук ко~.1ан.о,и1аsто 
Створення задач, 
призначення У.оманди 
та аs-то~,1ооrля 
Мочг,ор11нг та 
КООР;:\Инац,я 
Взаємодія з ІНШИМИ 
служба-., и 
t,\ 
За1(риття задач~ 
Рисунок 2.6 - Діаграма діяльності 
2.5.2 Діаграма послідовності 
Діаграма послідовності - це uml д~аграма, що відображає послідовність 
виконання повідомлень між об'єктами в рамках конкретного сценарію взаємодії. 
35 
Ч) ~ТУ .23 2097.ОО І ПЗ 
во11а дозволяє ~люструват-и , я1< 06'с 1<т11 trшсмо;\ і нп1, між собою в певному порядку 
чаСО·В ОМ)' ПрОМЇЖ'І('\., 1 ,Р' ЛЯ ; , ) • о • .. ·• h ... 
та ~ 1.:,. \ нення псщю, м ти або nико1 1а1111я певно~ <,-,ункцн. 
J-{a рис нк 2·7 бра>1 ена J\ ia 1·pa 1t111po1\~ рссстрtщії нопоп, -шернення . 
І<ористуовч 
ІІеб інторфе~с 
АРМ сороіс бвза Д8НИХ 
СТ'І!Ор(!ННR ~МрненнR : 
заповнює і вІдсмnє форм 
РОSТзвлит 
додав!І+4ня новоrо рАдку 
отриманнR результату створення 
запит всіх рядків з табnицІ 
нова сторінка зі ЗВВРНВННRМИ отриманнR всіх рядків 
proposal-page.html proposa/List 
Рисунок 2.7 - Діаграма послідовності (реєстрація нового звернення) 
На рисунку 2.8 зображена діаграма процесу створення нового завдання для 
команди ряrувальників на основі звернення населення. 
користувач ввб Інтерфейс сервіс база даних 
Адміністратор створення задачі 
- -~ ,.. 
' 
' 
заповнює і відсилає форму 
- ''  
' 
РОSТзапит ''  :'  
'' '  
' 
'
'' 
 
 
додаваннR ноаоrо рядку 
отриманнR результату створення 1l 
-
' 
запит всІх РАдКІВ з таблиці ' 
отриманнR всіх рядків 11 
- нова сторінка Із задачами 
- -
Рисунок 2.8 _ Діаграма послідовності ( створення нового завдання) 
36 
ЧД1 ,?1'>097.001 ІІ "J 
2.5 .3 Діаrрамн 1 0 1 ні~ ,щі't' 
Діаграма \(( 1, н · ... 
. . ' 1 щщ ю )1 НЖІ.'lШ на ри 'уtшу 2.9, 011ису ' fЮСЛІ/{()ВНЇСТЬ 
JCOM нікації нж к)(1 \tllOl\ H1 '111t •' lt '· ... 
• " 1. 1 ·мн, ттри ре< с r рШ(І І но1юrо ·шсрнення та 
...-r~рення ноRс..ЇЇ 1адачі і ·{ и , , , . 
'-•"'~ • 1 н.: t-тям н ·06'<1;~вих рссурсіrз . 
б: ,е,,~'Че1111я 
:Автомобіль J S:_,:sа11уче11ня 
:Чергова команда - :Задачі -
4:стаорення 1 
:Канал зв'язку 2:Запуск 
j :АРМ 1• ••шр•~:_ 
:Звернення 
1:Запит 
Рисунок 2.9 -Діаграма комунікацій (реєстрація звернення) 
2.5 .4 Діаграма скінченого автомата 
Діаграма скінченого автомата (ДСА) - це графічне представлення поведінки 
системи з обмеженою кількістю станів та переходів між ними (рисунок 2.1 О). У 
розробці програмного забезпечення (ПЗ) дана діаграма використовується для 
моделювання р1зних сценаріїв та керування програмою. ДСА допомагає 
визначити реакц1ю системи на події, планувати тестування та аналізувати 
помилки. Вона забезпечує краще розуміння та управління послідовністю подій у 
програмі для покращення її якості та надійності. 
Розробка ПЗ з використанням ДСА має кшька переваг. По-перше, вона 
допомагає визначити реакцію системи на різні вхідні події. Це дозволяє точно 
визначити функціональні вимоги до програми та її поведінку в різни сценарія . 
По-друге, ДСА допомагає у плануванні тестування. Використовуючи 
діаграму, розробник може створити тестові сценарії, які охоплюють р1зн1 
переходи та стани системи. Це сприяє виявленню помилок та некоректної роботи 
програми на ранніх етапах розробки. 
37 
ІД 1 · 12097.ОО І 113 
!Невірні дані) 
Ав ор11заutя 
(Успішна авторизація) 
еєстраu я адреса 
on11c надзви а11но1 
ситуаці 
ri o,uyк кома..щи/авто 
Створення задач, 
призначеннF команди 
та автомобіля 
Мочrторинг та 
координація 
Виконання ВзаЄМО,J,ІF з іН..lJИМИ 
задачі сrужба,.,и 
Закриття задачі 
Рисунок 2.1 О - Діаграма скінченого автомата 
38 
ЧДТУ.2320()7 .ОО І 1 І З 
} 011 ТР l013Лl 11 lЯ 1 ІРОІ 'J>ЛМІ ІО'і 'И 'ТІ ~МИ 
3· 1 }>о -~ро6 ~<н 11ро1·рам11оrо ком 1шеr<су 
3.1. 1 6,р,,н,-,, 133 1_,,..,я в .; .) · ,,-, 11 6ю ру '3а~обів реалjза,~ії 
З;)со6~ м н розробки 6 . ) . . _ 
ули обраю І yt\1on [2] з 1 DJ ango Framework [8] на 
бе1'енді та НТМL.5 «а tt>po 1 , . , 
't пенд1, системою керування базою даних було обрано 
P0stgt·eSQL. Загальна схема ви1<ористаних технологій та засобів показана на 
рнсуно-к З . l . 
BackEnd АРМ 
пожежного FrontEnd 
Ojongo Framework PostgreSqL HTMLS cssз 
Python 
JavaScript 
Рисунок З .1 - Загальна схема використаних технологій 
Python - високоврівнева, інтерпретована, об'єктно-орієнтована, імперативна, 
строго типізована мова програмування загального призначення, що має динамічну 
тишзац~ю. 
До переваг Python відносять: 
- Інтроспекція: здатність програми отримувати р1зну інформацію про 
об'єкти в режимі RunTime. Це дає можливість дізнатися якому класу належить 
об'єкт, з яким типом даних ви працюєте в даний момент (так як Python має 
динамічну типізацію) або список атрибутів і методів, доступних для зазначеного 
об'єкта. 
- Кросплатформовий: підходить для різних платформ: UNIX та Windows. 
39 
ЧДІ 'J l 'J097,00I 111 
- Вбїї)овані namc,,,,11 111 ое, 111_1 · rю1111н Py tl1011 іс r,ую r ь сної вбудовані 
паrерни про ю _н ання , 1щ J\011< 1ш шо1 ,, 11rи об'< ю но opif rпоианому 
nроп1а t) взнні. 
в ' ~ 
' mh·uu наоі1 <'mащ>щ 1111ш\ f>if> 1irmи!1<. І Іри використанні Core Python, 
мн t)тt"IH 10 
t) ,'1.ос, 11 \О вслнкоr о набору корисних стандартних бібліотек. 
J1рнк.11 а..10'1 ,-1ожс- бутн )ібліотска для робо, и з БД Q ite, а також json, math, re, 
randoн1. ""' . l1tшl та багато інши, . 
тр,·  'I011•1 'JJO ваю·с ть коду. Форматування тексту в Python є частиною його 
си.п.•~..к. сис) включаючи вщступи (пробіли, табуляція), яю дозволяють 
підвищувати стр кт ровані сть коду. 
Django Framefork 
Django (Джанго) вільний фреймворк [9] для веб-застосунків мовою 
Python. що використовує шаблон проектування МУС. Проект шдтримується 
організацією Django Software Foundation. 
Система на Django будується з одного або декількох додатюв, яю 
рекомендується робити модульними та такими, що можуть встановлювати 
з'єднання між собою. Це одна із суттєвих архітектурних відмінностей 
фреймворку від деяких інших (таких як, Ruby on Rails). Один з основних 
принципів фреймворку-DRУ[12] (англ. Don't repeat yourself). Ряд сайтів таких як: 
Instagram, Disqus, Mozilla, Washington Times, Pinterest, У ouTube, Google та ін. 
використовують веб-фреймворк Django. 
Архітектура Django схожа на «Модель-Представлення-Контролер» (Model­
View-Contro4 МУС). Контролер класичної моделі МУС приблизно відповідає 
рівню, який у Django називається Представлення (англ. View), а презентаційна 
логіка Представлення реалізується у Django рівнем Шаблонів (англ. Template). 
Через це багаторівневу архітектуру Django (рисунок 3.1) часто називають 
"Модель-Шаблон-Представлення" (Model-Template-View, МТ ). 
До основних можливостей Django, можна віднести: 
- ОRМ, АРІ доступу до БД із підтримкою транзакцій; 
40 
rд І ?32097.ОО І ІІ З 
- вбудований ін1 '1 ф ·іі ,щ 1іні · 1 1щ,орн ,1 нж, 11шшними 11срекладами на 
багато мов; 
ди 11 'lЧ 'J t І І на о нові І ~улярн11х вираJін; 
J о ~mнрюнан..~ ·н t " ta таЬлонін з 1 cr ами 1 а успадкуванням; 
- снст -ta к '111 вання; 
- ін1 "рнаціоналізація; 
ар,·іт"ктура додатків, які можна встановлювати на будь-які Django-
generic views - шаблони функцій контролерів; 
авторизац1я та аутентифікація, шдключення зовнішніх модушв 
аутентифікації: LDAP, OpenID та ін.; 
- система фільтрів (middleware) для побудови додаткових обробників 
запитів, як наприклад включені в дистрибутив фільтри для кешування, стиснення, 
нормалізації URL і підтримки анонімних сесій; 
- бібліотека для роботи з формами (успадкування, побудова форм за 
існуючою моделлю БД); 
- вбудована автоматична документація за тегами шаблонів та моделями 
даних, доступна через адм1н1стративний додаток. 
Model 
User django 
.... _ .... ', ··•-··'··..-.··,~ 
' url ) -- View 
~ - -- --. 
Template 
Рисунок З .2 - Архітектуру Django Framework 
41 
ЧДТУ.232097 .ОО І ПЗ 
НТМL, CSS та .lзva ci·ipt 
Також дJlS\ peaJ1 · ··· 
' ащ1 \ Jt1· r1 -1тc1,1«н..  сторони J\ощ.1·п<у nи1<ористано rг1 TMLS та 
cssз. Даними засо6амн в 1tро~1<ті реалі ·юш11ю а1(ш1·1 ·ивнісТF, інтерфейсу 
користувач з . 
HT~!I.L (знтл. Hy pe1·Text Ma1·kt1p Laпgt1age - мова розмітки гіпертексту) - це 
де1'лttратнвна мова, якою пишуться rіnерте1<стові документи для мережі Інтернет. 
Веб-браузери відображають НТМL-документи з веб-сервера або з локальної 
ла.м'яті персонального комп 'ютера. HTML описує структуру веб-сторінки 
семантично 1 спочатку включені сигнали для зовнішнього вигляду документа. 
єлементи НТМL окреслені тегами, написаними з використанням кутових дужок. 
теги НТМL є будівельними блоками сторінок НТМL (рисунок З.З). 
<header> 
<nav> 
<section> <aside> 
<;artfcle);' 
<агtісІе> 
<article> 
<footer> 
Рисунок З .З - Блочна розмітка сторінки (НТМL 5) 
За допомогою конструкц~· и~ НТМL зображення ' аудіо, відео, і·н терактивних 
форми і т.п. можуть бути вбудовані у візуалізовану інтернет-сторінку. НТМL 
надає засо б и для створе ння структурованих документів, позначаючи структурну 
42 
ЧJ~ТУ.232097 .00 І ПЗ 
.,антику тексту, нап1 ИІ<ла;\ . . 
ceiv• 1~Н 'ОJ101)1(И, нб1tщи, СІІИСІ(И, ІІОС ИШ\ІfІІЯ , нитати та ІНШІ 
менти. Браузери н Щ) 1 , . , • •. 
еле <а1 ю11, т ,, ·и І 11 МС, але оикоrистовують 1х для 
. ерпретації вмі т ~то1 і1- ІІ< ІІ . 11 · 1 ·м1 . 
11-tT · , може вбу;юнугзати програми , написан1 на 
r,foвi сценаріїв, наприклад Ja,,aScгipt, що nплива па поведінr<у та вміст веб-
сторінок. Включення ви · нача вигляд і компонування вмісту. 
С (англ. d. 
asca tng Sty le Sl1eets, укр. Каскадні таблиці стилів) - це 
cn еuізльнз ,юва стилю стор· •· 
~нок, що використовується для опису ~хнього 
зовнішнього вигляду. Самі ж сторінки написані мовами розмітки даних (НТМL). 
CSS є основною технологією всесвітньої павутини ( world wide web) , поряд із 
,r1r мi та JavaScript Наи~част· CSS · ·· ... 
п • rше використовують для вrзуальн01 презентацн 
сторінок, написаних НТМL та ХНТМL, але формат CSS може застосовуватися до 
інПІИХ видів ХМL-документів. Специфікації CSS були створені та розвиваються 
Консорціумом Всесвітньої мережі. CSS має різні рівні та профілі. Наступний 
рівень CSS створюється на основі попередніх, додаючи нову функціональність 
або розширюючи вже наявні функції. Рівні позначаються як CSSl, CSS2 та CSSЗ . 
в даному проекті було використано CSS З. 
JavaScript (JS) динамічна, об'єктна-орієнтована прототипна мова 
програмування, яка є однією з основних технологій всесвітньої мережі, поряд з 
НТМL і CSS (11]. Понад 97% веб-сайтів використовують JavaScript на стороні 
клієнта для поведінки веб-сторінок, часто включають сторонні бібліотеки. У сі 
основні веб-браузери мають спеціальний механізм JavaScript для виконання коду 
на пристроях користувач1в. 
Програми цією мовою називаються скриптами. Вони можуть вбудовуватися 
в НТМL і виконуватися автоматично під час завантаження веб-сторінки. 
Сучасний JavaScript - це «безпечна» мова програмування. Він не надає 
низькорівневий доступ до пам'яті або процесора, тому що спочатку був створений 
для браузерів, які цього не вимагають. 
У браузері для JavaScript доступне все, що пов'язане з маніпулюванням веб­
сторінками, взаємодією з користувачем та веб-сервером. Для прикладу, у браузері 
43 
--
ЧДТУ.232097 .00 І ПЗ 
JavaSaipt може: 
- додавати новий НТМL-код на сторінку, '3Мінювати наявний BMlCT, 
:модифікувати стилі; 
- реагувати на дії кор~А·, с•rувач . . . . 
а, натискання миш1 , перемндення вказ1вника, 
:натискання клав1ш; 
- надсилати мережеві запити на в1'ддалеtr1· сервери, завантажувати та 
завантажувати файли ( технології AJА Х та СО МЕТ); 
- отримувати та встановлювати coockies, ставити запитання відвідувачу, 
показувати поВІдомлення; 
- запам'ятовувати дані на стороні клієнта ("local storage"). 
В якості системи керування базами даних (СКБД) ми обрали PostgreSQL. 
PostgreSQL [10] вважається найсучаснішою реляційною системою керування 
базами даних у світі з відкритим кодом. 
Дійсно, PostgreSQL - це потужна об'єктно-реляційна база даних із 
:відкритим кодом, яка використовує та розширює мову SQL у поєднаню з 
багатьма функціями, які безпечно зберігають та масштабують найскладніші 
навантаження даних. Витоки PostgreSQL відносяться до 1986 року в рамках 
проекту POSTGRES в Каліфорнійському університеті в Берклі і мають більш ніж 
30 років активного розвитку на основній платформі, мільйони користувачів у 
всьому світі. 
PostgreSQL заслужив добру репутащю за свою перев1рену архпектуру 
(рисунок 3.5), надійність, цілісність даних, надійний набір функцій, 
. розширюваність та відданість спільноті з відкритим кодом, що стоїть за цим 
.nрограмним забезпеченням, щоб посшдовно пропонувати ефективні та 
інноваційні рішення. PostgreSQL працює на всіх основних операційних системах, 
-сумісний 3 ACID з 2001 року і має потужні додатки . PostgeeSQL є основною 
Реляційною базою даних 3 відкритим кодом для багатьох проект.ів і організацій, в 
тому числі дуже відомих. 
До основних переваг PostgreSQL можна віднести : 
44 
ЧДТУ.232097 .ОО І ПЗ 
- високопродуктивні і надійні механізми транзакцій і реплікації; 
_ спадкування ; 
- можливість індексування геометричних (зокрема, географічних) об'єктів 
і Іfаявність базується на ній розширення PostGIS; 
- вбудована підтримка слабоструктурованих даних в форматі JSON з 
можливістю їх індексації; 
- розширюваність (можливість створювати нові типи даних, типи індексів, 
мови програмування, модулі розширення, підключати будь-які зовнішні джерела 
даних). 
- сумісність з ANSI SQL; 
- безкоштовна в більшості випадків; 
хороша підтримка з боку провайдерів послуг хостингу; 
- швидка підтримка транзакцій через механізм InnoDB. 
Frontend (PostgreSQL APls, JDBC, cmd tools) 
Process manager 
Connection 
manager .... . 
Query processor Utility Processes 
WALFlles LОІ ГІІе5 
Oata Flles 
Storage manager 
Рисунок з •4  _ Архітектура PostgreSQL 
45 
Ч)\ТУ .232097 .001 І І З 
З. І .2 Опис структурної (фу1-шціо11ат"ної) схеми 
Для побудови АРМ пож "Жного можливістю віллаленої організаuії роботи 
:вuкористов ються Т<лієнт-серверна архітектура та широко поширені архітектурні 
wаблони Model-View- 011tго1lег (МУС). 
Архітектура клієнт-сервер (рисунок 3.5) є одним із архітектурних шаблонів 
nРотрамного забезпечення та є домінуючою концепцією у створенні розподілених 
мережних застосунків і передбачає взаємодію та обмін даними між ними [7] . Дана 
архіте1'."Т)'Ра дозволяє відокремлювати питання побудови користувальницького 
інтерфейсу від питань зберігання даних в результаті чого покращується 
nортативюсть користувальницького інтерфейсу на кількох платформах та 
масштабованість системи, спрощуючи серверні компоненти. 
□ 
lnternet 
Clients 
Server 
Рисунок 3.5 _ Архітектура клієнт-сервер 
Model-View-Controller (МУС) - це архітектурний шаблон, який роздшя 
д · ·чні компоненти : модель, вигляд та контролер. Це 
одаток на три основНІ лоп 
р б . внутрішніх представлень інформації від пособів 
о иться для в~докремлення 
подаю-Ія та прийнятrя н• 1ч,1_ >орм,а 1 ~ії вjд користувача. Традиційно використовувалась 
46 
--
чд, 'У .232097 .00 1 І JЗ 
ДJJ.я декстоnних додатків, але nот· 
rtOдa1'1<.1 B. С ьогодн.1  майже . ІМ модель стала популярною з появою веб-
,,. вс1 nопулярні 
(рµсунок 3.6). мови підтримують цю архітектуру 
І Control er 
І 
І 
View МоОеІ 
Рисунок З .б - Схема архітектурного шаблону Model-View-Controlleг (МУС) 
3.1 .З Опис логічної схеми системи 
47 
ЧДТУ.232097.ОО J ПЗ 
Архітектура додат1<у І~редста 
. 'влено на рисунку 3.7. Модулі нашого додатку 
можна nодшити на З основні функціо~-,аль . 
' 1-11 частини: 
te111plate, представлення ... 
. , для взаємод11 користувача з на_шим додатком; 
- v1ew, контролер служит 
' ь для обробки подій які приходять від взаємодії 
користувача з представленням; 
- 111odel, модель, призначе б 
на за з ереження, вибірки, запису даних в БД. 
• Proposal • Team 
• Task • Car 
User django 
url View 
- ~ 
Template 
Dockel' 
FRONTEND BACКEND 
Рисунок З . 7 - Структура модулів системи 
Система автоматизованого робочого м1сця розроблена з допомогою 
інтегрованого середовища розробки PyCharm. Структура проекту представлена на 
рисунку 3.8. В структурі проекту можна помітити відповідні директорії для 
зберігання елементів які зображені в структурі модулів системи (рисунок 3.7). А 
саме: templates, urls, views в яких розміщенні конфігурація та бізнес логіка 
проекту. 
48 
--- І 
члт . 3 ()97.0011 11 
Pгoject ... ·' ....  
' fire proje t 
t11 igratio11s 
ter11plates 
.- _ ir1it_.py 
admi11 .py 
111 apps.py 
Р helpers.py 
n1odels.py 
tests.py 
~ urls.py 
validators.py 
" v1ews.py 
> fire 
> templates 
> users 
- .env 
- .env_prod 
е .gitignore 
mL .gitfab-ci.ymf 
11& docker-compose.yml 
Dockerfi/e 
=' id_rsa_do 
_ id_rsa_do.pub 
" manage.py 
:= requirements.txt 
І t External Libraries 
Scratches and С onsoles 
Рисунок 3.8 - Структура проекту 
49 
ЧДТУ .232097.ОО І І І З 
З. 1. 4 Розробка бази даних 
Спроектована база J\ai-mx· 
C!(J 1t:1щ1r·1 ·1~c11 ·i 5 Jюr ·i,1110 гrон ' я1ані між собою 
блиць (рисунок 3.9). Табщ,щі 11 . , • • 
rз ризначснщ юн, 1бсрежс11тr J\аних необх1ю,-1их JІJІЯ 
конання фахівцем пожежно" , б . .., 
ви I служ и nокла~е11их на 1-н,ого функщи а саме: 
блиuя реєстрації звернень які н , .. . 
та адходя1ь до пожежно, частини, чергов, команди, 
томобільний парк ' задачі приз · . 
зв начен1 командам та користувач, системи . 
\~ Р"ЬІ1( 
<+ р,1 1,1,с 
EJ .•Р D.ІОІ~ г,~ арр_р, оро1~І 
,о 
~ St.'Щt\ fi ,1...iu, 9 oas,:1?1d 
с 
(tt.11tO_ ,H 
О created_c,І fl 1'1f_l0 Q n 
ft Jddreи F1 ,,_,uceri,s!, 
f1 <1tscr,c1,on tJ CleSCfl;)l1on '1J usernaмe 
Е corsumcr :il"IJ)t r_f"tur.1rr c 
-'"' 11 r,,,t_r.ame 
~ n11rn~ f} 1,s1_nane 
j em.i,1 
{j 1s_staf"' 
~ ' С)UЬІІС tl оа1е_,о ned 
Е epp_team tJ ~ser_І:,ce 
,ф ttam_JC1_1CІ 
Рисунок 3.9-Модель бази даних 
Детально опишемо призначення і структуру таблиць. Таблиця арр _ car 
(автомобільний парк) містить в собі інформацію про автомобілі, що закріпленні за 
пожежною частиною із позначенням статусу зайнятості. Структура таблиці бази 
даних наведена в таблиці З .1 
Таблиця З.І 
Структура таблиці Автомобільний парк (app_car) 
№п/п Назва поля Тип поля Ключ Опис 
1 id bigint РК Ідентифікатор 
2 status varying(50) Статус зайнятості 
з water tank capacity double Місткість води 
4 foam tank capacity double Місткість піни 
І 5 fuel tank capacity double Місткість баку 
б consumption per hundred km double Витрати пального 
7 name vai-viпg( l ОО) 
L_ Назва 
50 
ЧДТУ.232097.001 ПЗ 
Таблиця app_ team (чергові 1<ома1щи) 11ри ·mачена ;~ш1 збері гання інформації 
JJPO черrовt команди які доступні для 1JИІ<о11шшя · а13;_щ11 ь, згідно нових викликів. 
структура даної сутності бази даних наrзелс11а в таблиці 3.2. 
Таблиця 3.2 
труктура таблиці Чергові команди (app_team) 
No Назва поля 
n/n Тип поля Ключ Опис 
І id 
РК Іден 
2 status 50 Ста СТІ 
з nаше V 255 Назва 
Таблиця Задачі (арр _ t as k) являється журналом виконання завдань 
черговими командами які вирушили на виклик. Її структура наведена в 
таблиці З .З. 
Таблиця З.З 
Структура таблиці Журнал завдань (app_task) 
№ 
Назва поля Тип поля Опис 
п/п Ключ 
І id Bigint РК Ідентифікатор 
2 status varviшr(50) Статус виконання 
з address varyin~(500) Адреса викликv 
4 created at Timestamp Дата та час створення 
5 description varving(500) Опис завдання 
б car id Bigint FK Автомобіль 
7 team id Bigint FK Команда 
8 user id Bigint FK Користувач системи 
9 proposal id Bigint FK Ідентифікатор запиту 
Таблиця жу р нал ВИКЛИКІВ ( арр _proposal) зберігає інформацію про 
надходження виклиюв до пожежної частини про надзвичайні ситуації 
(таблиця З .4 ). 
51 
-
ЧДТУ.232097.ОО І ПЗ 
Таблиця 3.4 
Структура тнбJНtці )Kyp1HtJ1 ниюtикін (яpp_proposa l) 
No Нззва поля 
11/n ТИІ1 поля Ключ Опис 
1 id 
РК 
2 status 
Стат с виконання 
3 add1·ess va Ад еса викли 
4 cгeated at Ті та час с ення 
5 descгi tіоп va Опис викли 
6 useг id Ві FK Ко ист вач системи 
Таблиця Користувачі системи (useгs_useг) зберігає інформацію про всіх 
користувачів даної системи із зазначенням їх ролі (таблиця 3.5). 
Таблиця 3.5 
Структура таблиці Користувачів системи (users_user) 
-
№ Назва поля 
п/п Тип поля Ключ Опис 
1 id Bigint РК Ідентифікатор 
2 password varving( 128) Пароль 
з last login Timestamp Останній вхід 
4 is superuser Boolean Адміністратор 
5 usemame varyiшr(l 50) Логін 
6 first name varying(150) Ім'я 
7 last name varving(l 50) Прізвище 
8 emai1 varving(254) Електронна пошта 
9 is staff Boolean Достvп до адмін. панел 
10 is active Boolean Статус 
11 data joined Timestamp Дата реєстрації в сис. 
12 user type varving(50) Роль користувача 
13 team id Bigint Належність команді 
З .1.5 Розробка інтерфейсу користувача 
На рисуноку З .1 О зображена форма авторизації користувача, де розміщені 
обов'язкові для заповнення поля: електронна пошта та пароль зареєстрованого 
користувача. 
52 
ЧДТУ.232097 .ОО І ЛЗ 
{) flflE 
8 \1/\ А ( 11( 1t'М\І 
Рисунок З .1О  - Форма авторизації 
на головній стор1·нц1·  ( рисунок З. І l) пtсля успішної авторизаш1 
адміністратора відображається списо1< запитів на виклик командної групи для 
усунення надзвичайної ситуації. У лівій верхній частині меню можемо бачити 
логотип додаТ1'.')' та список категорій які доступні адміністратору для перегляду та 
~-ерування. Праворуч знаходиться кнопка «вихід». 
(!) ~ 1ІКJfНІІН1 IИt'pHt'ttHA 
ЗЗПИТ #1 8 nрочксІ 
JIAP'Кli: І!)',  Гер:)іе Дн,nр~ 1 
оnкс: Згоріла х.а·а 1t-ne-p rорить ліс осе, nо;ано 
Е•іііІІР•А &ИА4Л>m< 
Рисунок 3.11 -Головне вікно 
Для реєстрації нового звернення, необхідно натиснути на кнопку «створити 
звернення» та заповнити два необхідних поля (рисунок 3.12): адреси та опис 
надзвичайної ситуації. 
Виит11 , 
Нове звернення 
... pt ,J 
r ; 
Рисунок З .12 - Вікно реєстрації нового звернення 
53 
> 
ЧДТУ.232097.ООІ ПЗ 
Після чого необхідно " 
,атиснути на кнопку «створити». Звернення буде 
орено та відображено в сист · • 
сrв ем~ для вс1х чергових ряті вних команд. 
Натиснувши на пункт 
головного меню «Задачі», перед корисrувачем 
відображається сторінка із назначеними задачами, в якій назначається для 
кожного звернення, команда рятувальників та автомобіль (рисунок 3.13). Під 
J<ожною задачею є дві кнопки: 
«вирішено» , яка змінює ст атус виклику на виконании~  та кнопка 
«видалити», яка видаляє обрану задачу. 
sадача #1 с,еорено 
~ , "І" ГероІ• Д"іnре 1 
ом&е: По•е-., nepeйw/18 s буаіее1'ь нь J\ЇС s сухою 1н4стао,о 
~ : Тунrи Юнrм 
МІІІМММІ: MiWИt41 1 
- 8ИААJІИТИ 
Рисунок 3.13 - Вікно створення та моніторингу задач 
З .1.6 Опис розробки програмних компонентів 
Програмний компонент головної сторінки описаний нижче: 
~ ~~ r· requi. red 
def main_page (request) : 
ret urn render ( r e ques t , ' app/main- page. html ' ) 
Анотацією @login_ required описує, що виклик методу відбувається лише 
авторизованими користувачами системи. Результатом виконання буде повернена 
головна сторінка main-page.l1tml на якій користувачу доступне головне меню. 
Програмний компонент викликів, має наступний вигляд: 
54 
ЧДТУ.232097.001 ПЗ 
• ' t І 1 \ '>\ 1 
t' , . .. , ,, ,,,:,,1 · 1' 1,1,' (r qu st ): 
1
,іс1 ~ ,ntext е ( } 
і 1 1:equest. POST : 
1 t request.POST.get(' de]ete jd '): 
models . Proposal . objects- f' . 
elS(" : · 1.lter( td=request.POST[' rJc, J,- • "! irJ ' ]) .delete() 
new- prop_o sal = models • Р roposal( 
add~ess=~equest.POST [ ' address ') , 
desLr1.pt1.on=request POST[' . . 
· descr1.pt1.on ') 
new_propo sal.save() 
proposals = models . Proposa l . objects . order Ь ( 
helpers . get_ sta tus_order( ) , - У 
' - id ' 
) .all () 
context('proposals ' J proposals 
retur n render ( 
request , 
'app/ proposal- page . html ', 
c ontext=context 
Анотацією @login_required описує, що виклик методу відбувається лише 
авторизованими користувачами системи. Далі описується бізнес лопк~ 
оброблюючи дані які були надіслані методом POST. Результатом виконання буде 
повернена головна сторінка proposal-page.html. 
Програмний компонент задачі, має наступний вигляд: 
@_ og.:. ~._ required 
def create_task page (request) : 
context = (} 
cars = model s.Car. o b jects. f i lter() . al l () 
teams = models . Tea m. ob jects . filter () .al l() 
context( ' cars ' ] = cars 
context ( ' teams ' ) = teams 
i f request . POST and val i dators . validate_task( request) : 
propos a l_id = request.GET . get( ' proposal_ id ' ) 
proposal = None 
if proposal id : . . . . ( 'd)) f ' () 
proposa l = mo dels . Proposal · obJects . f1.lter( 1. 1=1.nt proposa 1 _ 1. . 1.rst 
if proposal . tasks.all(): _ 
messages . error(request , f ' Задача на цеи ~апит вже створена! ') 
return redirect ( ' tasks page ' , permanenl=l r ue ) 
models.Team . o b J· ects • filter( i =request . POST[ ' Leam _ id ' ]) . first() 
team 
55 
ЧДТУ.232097.001 ПЗ 
ar = models.Car . obJ' ects · f l'. l ter ( 1· і 
• <""request . POS'l'[' r·,Jr i rl 'J ) .fJrst ( ) 
ne1~_tas k "" models . тask( 
д,ki1·Qs~=request . Pos~• [ , 
~:! "~'L' 11· pL1.. on•request.' Posadтt .i r, es.s. ' J ~ 
use t =r. equest . user , ( descrl.ptJon ' J , 
LP~m_1 d•request . POST [' . , 
·d= request POST ( , team- 1.d '] 
са1· - 1. · car i d • ] , 
propo s~l_ id=int(proposal- id) ~ f 
- 1. . proposal_id P l se proposal_id 
helpers . create t ask set st t 
- - - а us(team, car , proposal) 
new_task . save() 
team . save () 
ca r . save () 
if proposal : 
p roposal .save() 
messages .success(request, f ' З 
адача успішно створена! ' ) 
r eturn redirect(' tasks_page ', permanent=True ) 
return render ( 
reques t , 
' app/create-task- page . html ', 
context=context 
В середин~ методу описується бізнес лопка, оброблюючи дані які були 
надіслані методом POST. Потім відбувається створення нового об'єкту Task та 
збереження його в базі даних. Після успішного збереження користувача 
переадресовує на сторінку задач, де буде відображена ново створена задача. 
З .2 Тестування програмної системи 
3.2.1 Модульне тестування 
Модульне тестування передбачає перев1рку окремих модушв або 
компонентів системи на коректність їх роботи. Основна мета модульного 
тестування полягає в тому, щоб переконатись, що кожен модуль працює 
правильно і відповідає вимогам специфікації. 
Проведемо тестування модуля, зв'язаного з керуванням черговими 
командами, перевіривши його основні функції. На рисунку 3.14 зображений 
Інтерфейс модуля. 
56 
ЧДТУ.232097.ООІ ПЗ 
-І(ОМІІНАІІ "Автом11тиsов11н11 бриr11д11 " a::.:r::::=,.,.... 
@ 11dn,in Ф operJ tot , @ m,юlll gt, 1 
- @Q-f■ii •ИАми,., 
коман,q11 "Придніпровські" 
коман,qа "Рятівник-Черкаси" 
@ ,ь.ng• @ gngory @ ogok 
-4-Иііі •ИАалиrи 
Рисунок 3.14 - Модуль чергові бригади 
Для створення нової чергової команди, натиснемо кнопку «створити 
команду». Після чого буде відкрито вікно створення нової команди (рисунок 3.15) 
де необхідно вказати назву команди та заповнити місця новими членами команди. 
Максимальна кількість мі сть в команді - 5. Після заповнення всіх полів необхідно 
перев1рити кнопку «створити». В разі успішного відпрацювання команда буде 
додана до бази даних системи та користувача перенаправить на стор1нку 
«чергових команд» де відобразится нова команда із перерахованими учасниками 
команди (рисунок 3.16) та статусом щойно створеної команди. 
8 FIRE Зе~р11ення Задачі Ко~tанди Маwими Алміr1 nанt11ь 
SиИrи 
с творення команди 
Нова l(Ot.tattдa 
■"6ерІт~ nюд•іІ • ко...,НАУ' 
new_user1 
new_user1 
І new_userl 
-. - ••. .Z":... . -
Рисунок 3.15 _ Модуль чергові бригади: створення нової команди 
57 
ЧJТГУ.232097.ООІ ПЗ 
І(ОМ8НА8 "Но1111 КОМІІНАІІ " 
КОМ8НА8 "АІІТОМ8'n1JОІІІНІ 6риrедв" 
ф r,ptr.-1011 ф П"І!negt1 1 
4 & 
КОМІІfАІ "Пр..,цнІnро11ськ1· 
ком•КА• "Р11ті11ник-Чrрк•см· 
@ ...~ . ф 9,,go,y ф •9•• 
Рисунок З .16 - Модуль чергові бригади 
Перевіримо можливість видалення, натиснувши відповідну кнопку 
навпроти команди, що видаляється. В разі успішного відпрацювання сцинарію, 
команда буд е видалена 1з бази даних а користувач отримає відповідне 
повідомлення (рисунок З .1 7). 
8 FIRE Зnер"е""я Задачі Ко\Іанди Maw,нi, А.амін панель 
команда "Автомати3ована бриrада" 
@ оре,а10,1 ® managerl ® adn>rn 
4%ііі&&& ■а.;;;ц е~АVИfМ 
@ •ndi.t ® a111on ® а, 1u1 ® "tal,k 
lf• •• •l&fl• вид~иrм 
команда "Рятівник-Черкаси" 
@ aluнga ® 9119о,у ® agak 
1411&-НS .;;;;;; ВИДІЛИТИ 
Рисунок З .17 - Видалення чергової бригади 
58 
.... 
,.. 
Ч) t1 . 212097.ООІ І ІЗ 
-~' . .2 Інт "І рrщіннс тсс1 вання 
н~1 ·т~ nннм "Tano і після модульного тестування , інтеграційне тестування, 
IJl{) nc.,: rо е;о с прийняттю системи в експлуатацію. Його мета полягає у перевірці 
IJ38f,•t oJ.iї між різними модулями або компонентами системи ' щоб впевнитись в їх 
f1Г8Іmльній інтеграції та спільно 1:у функціонуванні. 
для інтеграційного тестування між декількома модулями, зареєструємо 
tfOBr,•~ й авто,юбіль та нову задачу, в якій буде використаний даний автомобіль. Для 
uьaro перейдемо до модуля «Автомобілі» та натиснемо кнопку «додати» 
(Р»сунок З .1 ). 
д. ,давання машини 
Рисунок З .18 - Діалогове вікно реєстрації нового автомобіля 
Заповнимо необхідні поля, шсля чого натиснемо на кнопку «створити» 
(рисунок 3.1 9). 
-.~-..,....-.,._•.н...,о,...м, •--· --
.........,. ..,._..-_.... .,,... , .,,,_ 
,,....___. ...._ ,с..а. 
~~_.-.. .--..-. -•-)I-J-l ,-1- .J:1. ' ---
.-.-.,-.-_-_- .-...8.( _ІС.­.. .. . 
..........,.,...,. -nи_.· 
............... 
.............. ., ._  
,..........,.._. - .. ,._. .....  
з . 19 _ Сторінка автопарк пожежної частини 
Рисунок 
59 
ЧДТУ.232097.ООІ ПЗ 
успішне виконання сцинарію приведе до додавання нового автомобіля в 
. даннх та відображення його на сторінці автопарку пожежної частини. 
61'13) 
J.2.3 Системне тестування 
[Іерейшовши на вкладку «Задачі» та натиснувши створити, нам необхідно 
anо внити поля та вибрати зареєстрований нами в системі автомобіль . 
3
~ fІ RЕ Звер ення Зацачі Команди Машини Ад~1ін панель 
створення задач, 
вул. Благовісна, 333 
onvic задач~ 
Автоматизована бриrада 
(оберіть машину 
, оберіть машину 
1 
ЗІЛ-131 
І 
І ПЗБ б 
Рисунок З .20 - Сторінка створення нової задачі 
Коли були заповненні всі поля та натистенена кнопка «створити», 
ІСористувач побачить список задач із новою створеною задачею (рисунок З .2 1) . 
60 
ЧДl'У .232097.оо 1 ПЗ 
,м11ч11 #3 <'1•nr•н" 
..-r1<•: ~.,., F.,~toe•"'4~ 3,\ 
Of!Іtr. rt~ip<3 О~'()."ТІІІ 
_.~t4A•: А!!~\t І'ІТ\•31,)М••І\ 6p1trMll 
м.uittнi: ..,с е,,,, Arнc:voN.nь 
... ~811нn1 
,адачІІ #2 ,.., •., r,"0 
~•: ~У" n,-o"f')•"n-.. ;A ) 
"ttr. 1.1юt1..мдко ntpteipиrи A:-:('J)tno д~щу, 
0
wом1...-•: РйТ1fІн~~.. •Чtрк~см 
tt,&8UJMNa: П3б-6 
- 8~8АИ1М 
sадача # 1 С'tоор,но 
,w,oca: , yr Гtро111 Дніпр• 1 
оnмс noxtжa ntpt~,w11a з 6у.аіаt11ь на .nic 1 сухою ІІист-еою 
.._ .~а: Ряr1СtНtІС· Чtрк.1си 
м,aWt4MI: ПЗб-6 
- 8Кд&/ІИТ"И 
Рисунок З .21 - Сторінка задачі 
3.2.4 Приймальне тестування 
Після завантаження розробленого додатку на сервер, проведемо останній 
етап приймального тестування. Перед використанням додатку, користувачу 
необхідно авторизуватися, заповнивши поля ло гін та пароль (рисунок З .22). 
... • J( -+ • 
♦ -:: Н \ 0.. \І □ о •• .- ,.., " ._. 
6 FIRE 
вх,д в систему 
/IQf,Іt 
Рисунок 3.22 - Форма авторизації 
В разі успішної авторизацн, користувачу будуть відображені сторшку 
відпов~· ~ доступу • Для а·д міністратора сторінка бу де мати вигляд дно до иого прав 
зображений на рисунок З .23. 
61 
ЧДТУ.232097 .ООt ПЗ 
,-аnит #1 ,...,.... ... 
~a: t)- l'l rf'PO'"-д. .. ~ , 
о,,..,с: !tOP"-3 vJta. t l':t~ t'op""'1 ,ж. е<о ncr,чo 
81'\IIW•nt 
Рисунок 3.23 - Зовнішній 
вигляд системи (режим адміністратора) 
Опрератор системи побачит . 
ь наступнне предствалення вщображене на 
рисунку 3.24. 
...,,, 
J.8ПИТ 112 Стео;,..о 
.,,_.: • 11- nит~•~ 2 
~ь.:,0-:, ~,1"') 
,.nит•1 •~ 
~-r,._ r~ІJ.~• 
Рисунок 3.24 - Зовнішній вигляд системи (режим оператора) 
Самі члени пожежної бригади, при авторизації можуть побачити форму 
(рисунок 3.25). 
І& ... ~ ' 
('- , С ,, , і І Q · ~- ~ -· 
sадач. #3 (°"І•ор•мо 
~ · •У"' ь.r~ое-<"• ))3 
оn.к. '1~p,t,-.p<a оо t.l(,• 
--.ом.~ А•1ощ, ..ю ••н• ()рмr•д., t,Ц,w•1o:•1 ~о, .. ~ .., 0 1,,1o(t\111t 
hА,аче #2 , , осч ... ,,u 
~І 8)'.11 n~~l,W~1to(• 2 
•Nою .,.~Амо NPf8.;p..tr.,. А)«~по AJl""Y 
-~Р•••"-м · Ч.,r,р~ 
.....,. .. ~., n:ц; 6 
Рисунок 3 .25 _ Зовнішній вигляд системи (режим пожежного) 
62 
ЧДТУ.232097.00 І ЛЗ 
висновки 
Після аналізу аналогів на ринку програмного забезпеt1ення було виявлено 
їхні переваги та недоліки . Також були розроблені вимоги до веб-додатку 
автоматизації робочого місця пожежного . 
У результаті розробки було успішно створено веб-додаток АРМ пожежного, 
який забезпечує ефективний моніторинг та керування пожежними подіями. 
Додаток надає диспетчерам та адміністратору зручний інтерфейс та набір функцій 
для ефективного ведення журналу подій, координації роботи пожежних бригад, 
розподіл ресурсів інші корисні функції. 
Розроблений веб-додаток забезпечує централізовану систему збору, обробки 
та аналізу інформації про пожежні події. Він дозволяє диспетчерам оперативно 
отримувати інформацію про події, вести журнал, виконувати аналіз та статистику, 
що допомагає в прийнятrі обrрунтованих рішень та покращенні реаrування на 
пожежю випадки. 
Веб-додаток реалізований з використанням сучасних технологій та 
фреймворків, таких як Python, Django, HTl\1L та CSS. Це дозволяє забезпечити 
швидку та надійну роботу додатку, його сумісність з різними пристроями та 
операційними системами. 
Розроблений веб-додаток пройшов усшшне тестування, включаючи 
модульні, інтеграційні та системні тести. Тестування підтвердило коректну 
роботу функціональності додатку, його надійність та відповідність поставленим 
вимогам. 
Веб-додаток АРМ пожежного є важливим rnструментом для покращення 
реагування на пожежні випадки та забезпечення безпеки населення. Він сприяє 
покращенню координації роботи диспетчерів та пожежних бригад, збільшує 
швидкість реаrування та зменшує можливість виникнення небезпеки. 
Створена програмна система автоматизації робочого місця пожежного 
готова для використання, є достатньо гнучкою для подальшого супроводу та 
уд осконалення. 
63 
члт .2J20t>7.001 111 
"11ИС'ОК ВИКUРИСТЛІ 1И Х ) ~)KEPEJJ 
1 Вікі11едія. Моделювання ,·а симуляція [Еле,пrонний ресурс І . - Режим 
доступу: 1,tt-p ://uk.,,1іkіреdіа .о,·g/,vіkі/Моделюван11я_і_симуля1\ія 
- Лутц r--1.. Вивчаємо Руtlюп / Марк Лутц. , 2022. - 832 с. - (5-е видання) . 
З Коул Р. Блискучий Agile. Практичний посібник для проєкт-менеджерів 
із в1п~ори тання Agile, Sс1·щп, КапЬал / Р. Коул, Е. Скотчер. - Харьків: Фабула, 
2020. - 192 с. 
4 Вимоги до оформлення автоматизованих робочих місць. [Електронний 
ресурс]. - Режим доступу: https://www.naiau.kiev.ua/files/naukova­
diya1nist/intelektualпa-vlasnist/vumogu2.pdf 
5 Мартін, Р. Чистий код: створення, анашз, рефакторинг [Текст] І Р. 
Мартін-. , 2019 -464 с. 
6 Система питань і відповідей про програмування [Електронний ресурс]. -
Режим доступу: http://stackoverflow.com/ 
7 Клієнт-серверна архітектура [Електронний ресурс]. - Режим доступу: 
https:/ /uk. wik:i реdіа.оrg/wіkі/клієнт-серверна_  архітектура 
8 Django Framework [Електронний ресурс]. - Режим доступу: 
https://tproger.ru/articles/pochemu-vam-stoit-vybrat-frejmvork-django-dlja-svoego­
sledujushhego-proek:ta/ 
9 Django [Електронний ресурс] - Документація по фреймворку: 
https://www. djangoproject.com 
1О  PostgreSQL [Електронний ресурс] Кращі практики: 
https://www.e2enetworks.com/blog/best-practices-for-postgresql-database 
11 GitLab СІ [Електронний ресурс] - Документація як побудувати ci/cd: 
https://docs.gitlab.com/ee/ci/ 
12 Don't repeat yourself (DRY) [Електронний ресурс]. - Режим доступу: 
https://uk.wikipedia.org/wiki/Don%27t_repeat_yourself 
1З  Система питань і відповідей про програмування [Електронний ресурс]. -
Режим доступу : http://stackoverflow.com/ 
64 
лоллток л 
ЗАТ В ЕР Д)КЕН О: 
Зав. к · ед о , п2фесор 
-+-l----,,,,ч~,1-- Голуб С. В . 
АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ ПОЖЕЖНОГО 
Специфікація 
482. ЧДТУ .23 2097 -О 1 
Листів 2 
Розробник: Андрійчук В.І. 
Керівник: Голуб С.В. 
Норма контроль: Півень О.Б. 
Черкаси 2023 
482.ЧДТУ.232097-01 
2 
~ Позначення -
І Інйменупн111н1 Примітка 
k48ч2д, тУ.232097-0] 12-01 
Текст 11ршрами 
~~82, У.232097-01 34-01 -
І 11 стру1щіr1 r<ористувачеоі 
k48ч2 ,, дТУ.232097-01 90-01 
1 рафічні матеріали 
~ 
~ 
~ 
~ 
;----
~ 
:.-----
~ 
-
r--
,----
,--
І 
І 
І 
' 
'І  
l 
І 
~ 
-
~ 
ДО)JЛТОК І, 
АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ ПОЖЕЖНОГО 
Текст програми 
482.ЧДТУ.232097-01 12-01 
Листів 17 
Розробник Андрійчук В.І. 
Черкаси 2023 
4R1.1 1)\l \ 1. 1)()97 01 1) 01 2 
· ~м1с г 
в .~ск.1::1 L) ч ,л.. с·1,1 11~ 1\ ............................................................ .. .................................. з 
1.1 Фаі':\ .11 1ode!s.py ... .... ........ ... ...................................... ...... ...... .......... ..... ......... .......... 3 
1.~ Ф·анл \ їе,,·~ .ру .. .. ..... .... ........ ............................ ....................................................... 4 
FRO JТЕ Ч , с1~111--1А .... ... ................ ............ ... ......... .. ............................................ І() 
:::. 1 Базова сторінка (base.l1t1111) ......... .. ........ ....... ...... .... ... ..... ... ........ .. ....... ................. І О 
2.- Сторінка журналу реєстрацїї викликів (proposal-page.html) ... ... ................... .. 15 
2.3 Сторінка чергових команд (teams-page.html) .... ........... .... ... ... ...... ... .................. І б 
67 
482 · ЧДТУ .23 2097-0 І 12-0 І з 
І ВА K END ЧЛ ТИНА 
І. l Файл Models.py 
from datetime i mpor t datetime 
f r om django.db i mport models 
from users . models impo r t User 
ciass тaskStatus(models.TextChoices). 
CREATED = (' CREATED' , ' Створено ') 
IN_PROGRESS = ('IN PROGRESS ' ' В . , 
SOLVED = ('SOLVED' -, ' В · ' процесс~ ) 
ир~шено ') 
c l ass TeamSt~tus (models.TextChoices) : 
BUSY = ( BUSY ', ' Зайняті •) 
READY = (' READY ', ' Готові до завдань ') 
cl ass CarStatus (models .TextChoices) : 
BUSY = ( ' BUSY ', ' Зайнята • ) 
READY = ('READY', ' Готова до завдань ') 
class Proposal (models.Model): 
status = models.CharField(max_length=50 , choices=TaskStatus.choices, 
defaul t=TaskStatus.CREATEO) 
user = models.ForeignKey(User, on_delete=models.SET NULL, 
rel ated_name="proposals", null=True) -
created_at = models.DateTimeField(default=datetime.now) 
address = models.CharField(max length=500 ) 
description = models.CharField(max_length=500 ) 
cla s s Task (models .Model): 
status = models.CharField(max length= 50 , c hoices=TaskStatus. choices , 
de f ault=Tas kStatus.CREATED) -
user = models . ForeignKey (Use r, on_delete=models . SET_ NULL, 
related_ name= " tasks " , null=True ) 
created at = model s.DateTimeField(defaul t=datetime . now) 
address- = models . CharField(max_ length=500 ) 
description = models. CharField(max_ leng th=500 ) 
team = models . ForeignKey( ' Team', o n_ d e l e t e=models . SET_NULL , 
re l ated name= " tas ks ", null=Tr ue ) 
car- = models,ForeignKey( ' Ca r ', re lated_ name= ' tas ks ', 
on_delete=models .SET NULL , null=True ) 
proposal = models . ForeignKey(' Prop o s a l ', r elat ed_ name= ' tasks ', 
on_delete=models . SET_ NULL, nu l l =True ) 
class Team(models . Model): 
status = models.CharField(max_ length=50 , c hoices=TeamStatus . cho ices , 
default=TeamStatus . READY) 
name = models . CharField(ma x_ l e ngth=255 , null=True ) 
' 097-01 12-01 4 
наn, = mo1..iels. 'l1a1• Fie ld(mнx ]c,nqt!,- ioo , rн1 J \-1'r 11,,) 
,.ater_ ta 11 k_capa ?ity = models . Floa t Fie J d (rJP.fAt1 I г- І (1 111 ) 
foam_ tank_ capac~ty = пюdels . FloatField (de fa1J L t_ = г,r,r1 ) 
fuel_ tan ~_c apacity = models.FloatField(default=JП~ ) 
consumpt ion_per_ hundred km = models . FloatField(default=) 
class Meta : 
constraint s = [ 
models.CheckConstraint ( 
name="min_max_water_ tank_capacity", 
check=models . Q(water_tank capac ity gt e =l ) & 
model s.Q (water_tank_capacity_lte=SOOOO ) , - -
) ' 
models . CheckConstraint( 
name= "min_max_foam tank capacity", 
check=models.Q(foam tank capacity gte=l ) & 
model s.Q (foam_tank_capacity lte=SOOOO ) , - -
), -
models. CheckConstra int( 
name="min_max_fuel_tank_capacity" , 
check=models.Q(fuel tank capacity gte= l ) & 
models . Q(fuel_tank_capacity_lte=SOOOO ),- -
) ' 
models. CheckConstraint( 
name= "min_max_consumption_per hundred km", 
check=mode l s.Q (consumption_per_hundred_km_gte=l ) & 
models .Q (consumption_per_ hundred_km_lte=SOO ) , 
) ' 
1.2 Файл Views.py 
from арр i mport validators 
from django .shortcuts import render , redirect 
from арр import models 
from users i mport models as user_models 
from django . contrib import messages 
from арр import helpers 
frorn dj ango. contrib. auth . decorators impor t login_  required 
@.Lv9in .ceчuired 
def ПІain_page (request): 
return render(request , ' app/main-page . htюl ' ) 
@l<:;,:Jj r,_г?:gІJj r<;;d 
def proposa 1_page (request ): 
context = {} 
i f request.POST: 
if request . POST , get( ' dele t e_id '): 
models . Proposal.objects.filter (id=request . POST[ ' de l ete_ id ' ]) .delete( ) 
else : 
new_propo~~l - modelв,Propoeal( 
addresswrequeвt,POST[' ~ddroнв 'J, 
б9 
48 . Ч)ТГ . З 097-0 І 12-0 І 5 
prop ~aJs s m d~ J ~ . rroposa l .objec ts. o rder Ьу( 
help~rs . get_ s atus_order( ), 
'-j .j 1 
) . а ll () 
co11text [ ' p1·oposa J. - • J proposals 
1·E>tu1·n r e11der ( 
request, 
' app / proposal-page . html ', 
contex t =context 
~: ..:- _і :-1_ required 
def tasks_page (request): 
context = { } 
if request.POST: 
delete_id = request.POST . get('delete id ') 
tas k_ready_id = request.POST.get('task_ready_id ') 
if task_ready_id: 
task = models . Task.objects.filter(id=task_ready id) . first () 
proposal = task.proposal 
team = task.team 
car = task.car 
helpers.ready_task_set status(team, car , task , proposal ) 
task . save () 
team. save () 
car . save () 
i f proposal: 
proposal. save () 
messages .success(request, f' Задача відмічена як вирішена! ' ) 
if delete id : 
task ~ models . Task.objects . filter (id=delete_ id) . first() 
proposal = task.proposal 
team = task.team 
car = t ask . car 
helpers .delete_ task_ set_ status(team, c ar , t ask . proposa l ) 
proposal . save () 
task . delete() 
team. save () 
c a r . save () 
messages.success (request , f ' Задача ус11 іш110 видалена !') 
70 
482.ЧДТУ.232097-01 12-01 б 
1і J ter_ l ~am_ i d - r e quest . GET . get_ ( • (і lt ~r ':~-з і ,J · ) 
[). lters = І } 
if filter_ team id : 
f i lters[ ' t~am_id ' ] = filter team id 
tasks = models . Tas k. objects . o rder Ьу( 
helpers . get_status_order() , -
' - i d ' 
) . filter( H filters) .all () 
context [ ' t asks ' ] = tasks 
return render ( 
reguest , 
' app/tasks -page . html ', 
context=context 
@l ogin_regui red 
def create_task_page (request) : 
context = {} 
cars = models.Car . objects . filter() .all() 
teams = models.Team.objects.filter() .all() 
context [' cars ' ] = cars 
context['teams '] = teams 
if request . POST and validators.validate task(request) : 
proposal_ id = request . GET . get( ' proposal_id ' ) 
proposal = None 
if proposal_id : 
proposal = models.Proposal . objects . filter( id=int(proposal _ id)) . first () 
if proposal.tasks . all(): 
messages . error(request, f ' Задача на цей запит вже створена!') 
return redirect( ' tasks_ page ', p ermanent=True ) 
team = models . Team.objects.fil t er(id=request.POST[ 'team_id ' ]) . first() 
car = models . Car . objects . filter( id=request . POST[' ca r id '] ) . first() 
new_task = models . Task( 
address=request . POST[ ' address '], 
description=request . POST[ ' d escription ' ] , 
user=request.user , 
team_ id=r equest.POST [ ' team_ id ' ] , 
car_ id=request . POST[ ' car_ id '], 
proposal_ id=int (proposal_ id) if proposa l id else proposal id 
hel pers . c reate_task_ set_ status( team, car , proposal) 
new task . save () 
team . sav e () 
car. save () 
if proposa l : 
71 
482 чдт 
. У.232097-О І 12-0 І 
7 
propos a l . s ave () 
messages.success (re 
quest ' f ' З 
адача у • 
return redi rect( ' t ask сп~шно створена! ' ) 
s_page • , permane t -
return render( n -True ) 
request , 
' app/create - tas k- а 
context=context Р ge . html • 
@jorJ, r, ruq,;ired 
def tei:Jrns_ page (request): 
contex t -= {} 
if request.POST : 
delete_ i d с request Р 
i f delete id : . OST.get('delete_id ' ) 
team : 
models . Team . obj ects .filter (id=re 
, quest .POST[ ' delete_id ' ]) . first() 
if team.status == mod 
messages error( els.TeamStatus.BUSY: 
else .· · reque5t , ' Неможливо видалити к оманду яка працює.,  , ) 
messages . success( 
team . delete() requeзt , f ' Команда успішно видалена! ' ) 
teams = models . Team.objects d 
id ' ) . all () · O r er_by(helpers.get_ team_status_order(), ' 
context f ' teams ') = teams 
return render ( 
reques t , 
' app/teams -page .h tml ', 
contex t • cont ext 
@Joчir11 (/Uirc 
def rQJte_ t т_ ge (request): 
context • {} 
if request . POST : 
mates_ i d: Ji s request . POST.getlist('mate id ' ) 
mates_ id • {int(mate_ id) for mate id in mates id if mate id != ' one ' J 
.і f no n,ates id : 
messages . error(request, ' В команді повинено не менше 1 JL~дини! ' ) 
mates ~ user_ models.User . objects . filter( i d_in=mates id) . all () 
new team = models.Team . objects.create( name=request.POST [ ' name ') ) 
ne \_.- team. teammates . set (mates) 
ne\,, team . save () 
щessa es . su cess(request, f ' Команда " {request.POST [ "name " ] J " успішно 
~et urn redirect(' teams_page ', permanentdTrue) 
72 
482 1 
. ЧДТУ .23 2097-0 І 12-0 І 
8 
fire man s = user m d 
team- id=No ne,- о els . Use r . ob jec •'--··s . f', J \~r( 
ІІ 11 '; <' І t ) •І  ,, , 11 • , . 
' • , І 1 НІі ~, ;', \ І 
) . all ( ) . . , "i 'І\ї , ,. " І· ·, ІІ 
context[ ' fir - ma n s ') ~ 
fi. 1• _aian s 
r etu r 1  r nd - r ( 
r qu st , 
' ,з ~ / _1> t "-t п,-раg 
1 t x t= ~0 11t xt · h l:ml ' , 
, ; ~',l .~ іІ 1· ,'чU і 1:ed 
def edit_ _ team_page (request , t 
coпtext = {} eam_ id: in t ) : 
team = models .Team.objects f'l . 
context( ' team ') = team · l ter(id=team_id) . first() 
if request . POST : 
mates id: list = 
mates-id = (int( requ~st.POST.getlist(' mate id ' ) 
mate_id) for mate id in mates id if mate id != ' None ' ] 
if not mates id : 
messages.error(request, ' В команді повинено не менше 1 людини! ' ) 
else : 
mates = user_models.User.objects.filter(id_in=mates_id) .all ( ) 
team.teammates.set(mates) 
team. save () 
team.refresh_from_db() 
messages.success(request, f ' Зміни успішно застосовані!') 
teammates = team.teammates.all() 
context( ' fire_mans ') = 
user_models.User .objects.filter(user_type=user_models . UserTypes . МANAGER) . all() 
context( ' teammates ') = teammates 
if len(teammates) < 5 : 
context( ' mates_range ') range( 5 - len(teammates)) 
return render( 
request , 
' app/edit-team-page.html ', 
context=context 
@l,..;~i n required 
def car s _page (request) : 
context = {} 
if request.POST : Т t( ' d e 1e te id ') 
delete id = request . POS . ge -
if delete_id: . t filter( id=request . POST[' delete_ i d '] ) . fi rst() 
car = models.Car . obJec s . 
;з 
4R .Ч J\Т . · ' 0(>7-01 12-01 9 
І 1 ,, • , --, І/ 1 1r 1 .,. , 1 , , 
П1t'1Ч< ,,qt':~ . ~ , н - ,-,.,:а::: ( , rч111Г'~f 
<'•'! 1 • ti C' l с-1 (' () f ' ~' 1 1\Т • f І \ 
І1 ' 1f lf t 1 
') 
,-_,1-нп1 ге11dе · ( 
г~quest, 
' а "~' ca1· :.=:: - 1"aq ,, . !Yl ml. •, 
,'ontext=c1::п t x t 
{ :. ........ ~- ·-:__:.-\.....,~Ui ::-1..:::i,i 
de :f .::: :.:eats:_'-'a1-_p a-;;e ( r e ques t ) 
.::: пt ext = { } 
іі r equest .POST : 
n ew_c ar = models.Car( 
n ame=request .POST[' name '], 
water_ t ank_capacity=request.POST['water tank c apacity '] , 
foa m_ t ank_capacity=request.POST['foam tank capacity '], 
fue l _tank_capacity=request.POST[' fuel-tank-capacity '], 
con sti.L~ption_per_hundred_km=request.POST[' consumption_per_hundred_,<ш' ] 
new_car.save() 
шessages.success(request, f'Нова машина " {request .POST["name"] } " додана ! ' ) 
retu rn redirect('cars_page', permanent=True) 
:-etur n render( 
request , 
' app/ create-car-page.html', 
context =context 
l?:'. ug .::.. ,. _ .cequi rєd 
def e di t _ c a r _page ( request, car id: int) : 
context = {} 
car = models.Car . objects.filter( id=car_ id) .first() 
context[' car '] = car 
if request.POST : 
models.Car.objects . filter( i d =car_ id) .update( 
name = request.POST[ ' name '], 
wat er tank capaci t y=request . POST ['wate r _ t a nk_ capaci t y ' ] , 
f o am iank ~ apacit y=reques t .POST [' f oam_ tan k_ capac i ty '], 
fue l-tank-capa c i t y =r e que st.POST[ ' fue l_taпk_capacit. y '], 
c onsurnptio n_ per - hundre d _ km=reque st. POST [ ' COJ1S LШІptioп_per·_ hLшctred_ km ' ] 
messages. success ( request , f ' Змі ни ус п:l 1ш 10 за с•r·осо о а н і ! ') 
return redirect(' ca r s _ p a ge ', permanen t =T r u e ) 
74 
4R' . Ч )\ТУ .21 097-01 12-01 10 
,·C't \1J 11 1'("1К1(' 1 ' ( 
1· q 1H"$l , 
'•Ч"'Р / ( ti"i t -l',11·-11,,(11'. \)І 11, І 1 
~~nt~x\econt e xt , 
2 Fl~ONTEND ЧАСТИНА 
2.1 Базова сторінка (base.html) 
, 1 D СТУРЕ html> 
'<h·~.m  l lanq. = " en " > 
<head> 
<meta name= "viewport " content=" wi dth=device- width , initial-sc a le=l " > 
<meta charset=" UTF- 8 " > 
<link 
href= "https : //cdn . jsdelivr . net/npm/bootstrap@S . 0 . 2/dist/css/bootstrap . min.csв " 
rel="stylesheet " 
- integrity="sha384 -
E\'STQN3/azprG1Anm3QDgpJLim9Nao0YzlztcQTwFspd3yD65VohhpuuCOmLASjC " 
crossorigin= " anonymous " > 
<script 
src="https : //cdn . jsdelivr .net/npm/bootstrap@S . 0 . 2/dist/js/bootstrap . bundle . min . js '' 
integrity=" sha384-
MrcW6ZMFYlzcLA8Nl+NtUVF0sA7MsXsP1UyJoMp4YLEuNSfAP+JcXn /tWtiaxVXM" 
c r ossorigin= " anonymous " > 
</script> 
<link rel=" stylesheet " 
href="https : //fonts . googleapis . com/css2?family=Material+Symhols+Outlined:opsz ,wght 
, FI LL , GRAD@ 2 О .. 4 8 , 1 О О .. 7 О О , О .. 1, - 5 О .. 2 О О " / > 
<title>fire</title> 
<style> 
. page- content 
padding : 20рх ; 
. error 
background : rgb (251 , 111 , 111 ); 
padding : 10рх ; 
border-radius : l0px ; 
color : rgb( б0 , 14 , 14 ) ; 
. success 
background  : rgb (]ll , 2 ~,; 1 , 131 ) ,· 
padding : l0px ; 
border-radius : l0px ; 
color : rgb ( lS , 60 , 1'1 ) ; 
, messages 
margin-bottomt 20рх / 
75 
4H2. 'l ) t'l'Y .21 0()7-01 12-01 І 1 
• \' 1 \'n1<'111 
1,.,,-1..,11 ,'1111,1 : '\11' ( 'І І ) ; 
\'-~,і,іі1,1 : 1 ] ' ,; 
\','1 ,1,'1 1.~,і111~: : '(1 } 'Х ; 
1н.11 ,1111-t •'!' : І 11 ~,х ; 
• І? l c""111c'1'1t - 1 1. t l 
І,'І1t-~і.-\' : ':,рх ; 
t,':1t-1,·1:'i,1!1t : l~o lti; 
. statt1s 
paddin~ : 2рх l0px 2рх l0px ; 
width : fit -content ; 
bvrder-radius : l0px ; 
font -weight : bold ; 
margin- left : l0px ; 
. status - READY 
background : rgb (lll , 251 , 131 ) ; 
color : rgb( 15 , 60 , 14 ) ; 
. status - CREATED 
color : gray ; 
. status-BUSY 
background : rgb (251 , 111 , 111 ); 
color : rgb( б0 , 14 , 14 ); 
. status - IN PROGRESS { 
color : color (srgb 0 . 29 0 . 2778 0 . 1146 ); 
background : rgb( 255 , 243 , 85 ) ; 
. status- SOLVED 
background : rgb ( lll , 251 , 131 ); 
color : rgb (15 , 60 , 14 ); 
. element-header 
displa y : flex ; 
align- items : center ; 
. element - controls 
margin- top : J0px ; 
display : fJ.ex ; 
f lez-vJrap : wrap ; 
. button-control 
border-radiu s : J0px ; 
border : none ; 
padding : 5рх J Орх '1р.х 1 O[ JX І 
76 
. , ---
4R .... ЧЛТ . 1 0(.) 7-01 І -О І 12 
ti"i~t'l,,y : 11,,х; 
і'! 1 і 1)!)-і 1 <'ІН ,< : І'<'І)І 1 , 1 ; 
. l,t 11-,·1·,,ёtt <'' { 
,-,,1,,1 : 1,·І1і1 ,, ; 
l,.1,·1',1 ·,,1111,і : l ' Lll ( ,І' , •1.' , 1 ' ); 
. ttп-,io.:-11:::te { 
',-'ICl...1:)J','ltn,i : 0101: (c::t·qb l) . 7',,'t1 О . 1',,'(J О . 7r, J ) ; 
. btn-maпager-icon 
fort - si~e : :орх ; 
m~r9in-right : Spx ; 
. custom- modal - con tent 
Ь rder : попе ; 
border-radius : 20рх ; 
. modal - inp u t 
border : n one ; 
border- radius : 15рх ; 
background : rgb( 224 , 224 , 224 ) ; 
padding- top : Spx ; 
padding- right : lOpx ; 
padding- bottom : Spx ; 
padding- left : lOpx !important ; 
. lis t - bubbl es 
display : flex ; 
flex- wrap : wrap ; 
margin- top : lOpx ; 
. bubb le 
background : wh i te ; 
padding : 2рх lOpx 2рх lOpx ; 
border-radius : lOpx ; 
display : flex ; 
align-i~ems : cente r ; 
margin : 5рх 5рх Орх Орх ; 
. bubble span { 
margin- right : Spx ; 
fon~-size : 20рх ; 
. defaul t - forrn 
background : white ; 
padding : 20рх ; 
border-radius : 25рх ; 
width : ВООрх ; 
margin : a uto ; 
display : grid; 
border : 4 рх solid i 
77 
4R ... чл 1 · . . 2l ) ()t 7 01 І ) 01 11 
І f' І 11 1 ~ , ,, 
1 
} ... ; 
. ,k 1 ., 11 l t 1 ,, 11 ~l' 1 < ,' j 
\\\ \' 1., І 11 І '1' 1 І (' • 1 ( '\ 1) .., ; 
. d~fau t-form button 
-.Ll~~ ity-'-~('11t ~1t : с nter ; 
1,· i-.i~h : :('Jp x; 
. form-title { 
:::ont-si;:e : 20рх ; 
marg~n-bottom: 15рх ; 
@media (max- width : lOOOpx) { 
. element-contro ls . button- control 
margin - top : lOpx ; 
. si::atus 
margin- le f t : Орх ; 
. el e ment - header { 
display : block; 
. default-fo rm 
width : 95 %; 
. default-for m button 
justify-content : cen ter ; 
width : 100%; 
{% block st yle %} 
{ % ,::ndbl ock % } 
</ st y le> 
</head> 
<body> 
<nav class= " n a vbar navbar-expand-J g navbc:;1[-1 і (Jht bg- l igl1t і u~L і. ty -cLЧ1t-=nt-center " > 
<div class= " con tainer-fluid " > 
<а class= " navbar-brand " hre J ~ " JI " > 
t <b>FIRE</b> 
78 
14 
І І " 
'\°1\"' ! t"' 11.1 \ і 1..l \~ t 1 ('•11 ", 1 'І і •· " І ,. І , І 
tl ... , 
, ё'~','!і1 '1 1:s., " 111\ t, '1 -1 
І 'tlt11f'1 
" ~ 1 І ... ' І f r, ' ' 1Г 1 
j r. 
<li class="nav-item" > 
<а class=" nav- link active" href=" {% url ' tasks_page ' 
/а> 
</li> 
{% endif %} 
{%_if request.user . is_manager %} 
<li class="nav- item"> 
<а class=" nav- link a ctive " href= " {% url ' teams_page ' 
~: ">Комаnди</а> 
</li> 
{% endif %} 
{% if request . u s er.is manager %} 
<li c l ass="nav-item">-
<a class= "nav-link a c tive " href= " {% url ' cars_page' 
%;  ">Mamv.c.1-lli< І а> 
</li> 
{% endif %} 
{% if request.user . is_ superuser %} 
<li class="nav-item" > 
<а class="nav-link active" href=" {% url ' admin:index' 
~J " >J!..дмін панель</а> 
</li> 
{% endif %} 
</ul> 
<ul class="navbar-nav ml-a ut o " > 
{% if use r.is_ authenticated %} 
<li class=" nav-item" > 
<а class="nav-link act .i ve " l1re [ =" { % LJrl ' LJSer _l o90L1t ' 
%} " >Вийти< /а> 
</ li> 
{% else %} 
<li class= "nav-ite rn " > 
<а class="nav-J ink act .i ve " І,геf= " { І, LJr.l ' LІS<:H 1 <.)() L11 ' 
%І  " >Увійти</ а> 
</ li> 
{% endif %} 
</ ul> 
</ div> 
<: / ctiv> 
19 
1 
15 
~~· ... '' 1'·" ~1 '-" , .. , ..,п t t'11 t " ' 
і 1 l'nt~!';Si'\<)i:'s . ) 
І І 11 / ; lf 
11 І 1 І 
{i tlock ontent %} 
1 ~ endblo k %}  
.... О і , . .... 
.... ' і:'~ ..і. у> 
..... h~ml ' 
2·2 Сторінка журналу реєстрації викликів (proposal-page.html) 
,~ extends ' base.html ' %} 
, ~ block style %} 
{ % endЬlock %}  
1% block content %} 
<d:..v> 
<div class= "modal fade " id= " exampleModal " tabindex="-1 " aria ­
::._abe ~l e db y="exampleModalLabel " aria- hidden=" true"> 
<div class="modal - dialog" > 
<div class="modal - content custom-modal-content " > 
<div class= "modal - header" > 
<hS class="modal - title" id= "exampleModalLabel " >Hoвe 
звернення</h5> 
<button type= "button" class="btn-close" data-bs­
cis rr.:..ss= "modal " aria-label=" Close "></button> 
</div> 
<form method= "post " > 
<div class="modal-body" style="display : grid ; margin-bot~om: 
2 0рх;"> 
{% csrf_token %} 
<input class="modal-input " style="margin-bottom: l Opx ;" 
name ="address " placeholder="aдpeca " required> 
<textarea class= "modal-input " name =" description " 
placeholder= " oлиc " required></textarea> 
< / div> 
<div class="modal-footer " > 
<button type=" submit " c l ass= "button-control btn­
creat e ">cтвopити</button> 
< / div> 
</form> 
< /div> 
< / div> 
</ div> 
<div> 
{% if request.user . is_ operator %} 
<button t ype= "button" data-b s-togg.Le=" modal " с !а ta- l)::;­
targe t = "#exampleModaJ. " c J ass= " b u t ton -r.:onl: r o l btn-c~e a te " > 
<span class =: " 11 0Lrз ri о] - s yн1l )u l o- uІJL L Ltю ti l) l 11 - 111 .:1 11 , нJО І -
icon ">add circle</span> 
80 
Іб 
l' 'l' t,opи•1' 11 
· / l,11t 1 о1,, ·,н <' l 'H r- 11 111 1 
{ % (:"l)d; f , ) 
._: / (!і ,• ' 
,.J1 і , . .... 
{: 1°01 · 1'1 ' t"'Ір ~813 l , 
' . l t'\ Pl' ()t ) 
, .:11. , • , - l ,:, ,., , • " 1 r \ ч.; ,~ 1 \ 
. 1 
і. . ,, l' l'ПН"І) І 11 ...._ 
, 1.t ,· 1'l ,1c::.<.1 - ''(,,J 
'-, <~. >.l \І Р1111' 1, І - ] 
1'] 1 , (' 1 1f' i\ (1f'1"' 
1.:· : ..... ~ .... н 
Lii , , \'l ,~c:: '- " ('П!~'ІlІ - 1 і t 1 f'" 
.,1·,'}''" sзJ .g·et_s t atus_display .} :}.; <. s: ,1i11R R1n111~ - ( nr1и•r lf[ [ pr(Jp"J'1.:Іl.irl ff " /І ,,, 
} </с!і ,;> · / d tv { r, rop r1r,.:i\. " t;:il iJ'1 }} " .., [! 
ddii  ,·> .Ь > адреса : < /Ь' {{ 
<Ь>оnис : </Ь> { -{ proposal.addr e ss І І </ r:І' 
di \ r clasf  - " 
' % . s- elerneпt-copnrotprools al d . І v > 
". escriptio n 11 </rJ j ?> 
І l request.use . s > 
- "_ . , <button t - ~ - is_ manager %} 
·,  ... ,,- .,:., .. .:.. --"= 1, 1nd o1,1. location= , { %·  u r l у' рcеr-eabteu ttt on" c l as·  s-- "Ь u tton- control b t r1- ,:: r ,q -:1 ':."' " 
:, , - ask_page' %}?proposa l_ld=({ propo s,:1 l . id 
</ь створити задачу utton> 
{ % endif %} 
{% if requ est . 
<form rneth~~=~-is_operator %} 
{ - post " style="margin-le f t : lOpx ·" > 
0~  csrf_toke n %} ' 
<input type-- "hi' dd en " name= "delet e id" value= " {{ 
;::,::cposa l .id }} "> 
<button class="button-control Ьtn­
ое.:.е ::е">видалити</Ьuttоn> 
< / form> 
{% endif %} 
</div> 
</div> 
{% endfor %} 
</di v> 
</div> 
{ % endЬlock %}  
2.3 Сторінка чергових команд (teams-page.html) 
{% extends ' base . html ' %} 
{ % block content %}  
<di·v> 
<div> 
_ <button onc1ick= "window . locat ion= ' { % url ' create team page' ·;;) '" 
Cl-3 s s= "butto n - c ontrol btn-c reat e " > - -
. <span class= "rna teria1-symbo l s-outl i n e d btn- ma na gei::·-
icon " >add_  circle< / span> 
створити команду 
</ button> 
</ div> 
{% for team in teams %} 
<di v cla ss=" e l e me n1: " > 
<div class
<d iv c=la"sesle=m" eenlte-rnheenat-det..ri "t>1  e " >кoмaндa " ( ( t e a tn. n ше } ) "</di v> 
1 І L t )) " > {{ 
<div cJ.ass"" " s t a tus s t.: a t: u s- { , : eam. s с1 t1s 
team . get status display }} </ di.v > 
< / div> 
81 
482. ЧДТУ .232097-0 І 12-0 І 
17 
<div> 
<div l 
{ ass"" " lis• t-b bbl 
% for tearnmat u . e-s " > 
<div clas : .. .1.n team . teammates.all %} 
le"" nr;iargin- right : lOpx · " (~ 5
-:- bubble " { 'І- і[ forLoop.r;rJ1Jri'~r != 1 
ctY ' , e nd.1 f %}  > 
· ined ". >account _circle</ spa<ns>p an class-- " 
,_1  mater.•1 al-symbols-
otJ1. 
< І d.1. .v{>{  tearnmate . username }} 
{% endfor %} 
</div> 
</div> 
<div class=" element-controls "> 
<but ton class= "b tt . . 
11 • _ 11 • • u on- control btn- create " style="margin- right : 
:срх ; oncl.1.ck- w.1ndow . locat.1on= ' {% url 'tasks_page ' %}?filter_team_id={{ team . id 
І І '" > 
переглянути задачі 
< / button> 
. _:ь~tton style=:= "margin- right : lOpx;" class="button-control btn­
create " onclз.c 'k- wз.ndow . locatз.on= ' { % url 'edit team page ' team. id %} '"> 
редагувати - -
< / button> 
<form method= "post "> 
{% cs r f_toke n %} 
<input type= "hidden " name="delete_id" value= " {{ team . id }} "> 
<button class="button-control btn-delete " >видaлити</button> 
< / form> 
</div> 
</di v> 
{% endfor %} 
</div> 
{ % endЬlock %}  
.АВТОМАТИЗОВАНЕ РОБОЧЕ МІСЦЕ ПОЖЕ)КНОГО 
Інструкція користувачеві 
482.ЧДТУ.232097-01 34-01 
Листів 8 
L_ Андрійчук В.І . 
Розробник 
Черкаси 2023 
482 .ЧJ\Т . l (N7-01 2 
14-01 
1 Авторизац1я корн(:тунач а .. .. ....................... ...................................................... -~ 
Головна сторін1'а ........ .......... ..................................... ................ ......... ................ l 
2 
. 4 
реєстраu1я новог'- ·~всрнсння ... ... ..................................................... .... .. ........... . 
3 
..... 4 
моніторинг адач ................ ..... .... ............ ..... .... .. ....... ... ............ .... ................ . 
4 
. 5 · ..... 5 
обл1к нового автомо ~ля пожежної чйсти11и ........ .... ... ..... ........... .. ...... ..... . . 
5 .. .. б ..... .... 6 
створення ново~ пожежно~ ригад~,-1. .. .... .. .. .. .. .. .. .. .. .. .... .. .... ..................... . 
6 
84 
з 
Л \31'Ор11 ·щ1\іл 
корне, уна ча 
На µне. В. І зо6ражt'н а ф . 
орма HlЗTOJ)HlaPiї 
ннення поля: , користущІ'rа, ле або я· 5П І<оRі л.л я 
,,~по 
J 
1) е.1е""тронна пошта приз на чене для nведення · 1 
снстемі користувача · e- 111 ai алрес и зареєстрованого 
8 , 
_) пароль зареєстрованого користувача. 
для входу користувачу слід зап 
овнити поля та натиснути кнопку «Увійти». 
FtRE 
Уs1?т,1 
вхід в систему 
Рисунок В.1 - Форма авторизації 
Кожен користувач системи має власну роль та відповідні можливості: 
1 Менеджер - може переглядати запити, створювати, змінювати та 
видаляти задачі, може створювати і редагувати команди, може також створювати, 
редагувати 1 видаляти машини; 
2 Оператор - має можливість створювати та видаляти запити; 
З Пожежник - має право переглядати задачі та ставити своїй задачі статус 
«Виконано»; 
4 Адміністратор - має доступ до всіх вище перерахованих можливостей та 
доступ до адміністративної панелі, в якій можна створювати користувачів. 
2 Головна сторінка 
На головній сторінці (рис. В .З ) після успішної авторизації адміністратора 
відображається список запитів на виклик командної групи для усунення 
надзвичайної ситуації. у лівій верхній частині меню можемо бачити логотип 
додатку та список категорій які доступні адм іністратору для перегляду та 
Керування . Праворуч знаходиться кнопка «вихщ». 
85 
4R2. Ч)ТJ 'У. 23 2097-0 І J4-0 І 4 
,#.. . '•'' •· ! І"'',, 
Рисунок В.З - Головне вікно 
3 Реєстрація нового звернення 
Для реєстрації нового звернення, необхідно натиснути на кнопку «створити 
зверненню> та заповнити два необхідних поля (рисунок В.4 ): 
1) адреса призначене для введення адреси де трапилася надзвичайна ситуація; 
2) опис надзвичайної ситуації. 
Нове звернення 
Рисунок В.4 - Вікно реєстрації нового звернення 
Після чого необхідно натиснути на кнопку «створити». Звернення буде 
створено та відображено в системі для всіх чергових рятівних команд. 
4 Моніторинг задач 
Натискаємо на пункт головного меню «Задачі», перед користувачем 
відображається сторінка із назначеними задачами, в які й назначається для 
кожного звернення, команда рятувальників та автомобіль (рисунок 8.5). Під 
кожною задачею є дві кнопки: 
«вирішено», яка змінює статус виклику на виконаний та кнопка 
«видалити», яка видаляє обрану задачу. 
86 
482. Ч/(ТУ.2з2097_() І l 
34-О І 
5 
Рисунок В 5 М . 
Для т·д твердження зада . · - он~торинг задач 
ч1 командою одно . . 
бу т и авторизованим на 
13 
саиv т1• . П1• сля успіщ ' му члеюв команди необхідно 
. 
буде вщ. о 6 раженииv  новий статус ного пщтвердження задачі користувачу 
. ( ' 
3 адач~ рисунок В.б). 
задача #1 .Вирfщено 
адреса: вул Героїв Дніпра 1 
опис: Пожежа перейш б . 
. ла з уд,вель на ліс з сухою листвою 
команда: Ряпвник-Черкаси 
маwина: ПЗБ-6 
видалити 
Рисунок В.5 - Статус вирішеної задачі 
5 Облік нового автомобіля пожежної частини 
Для взяття на облік до пожежної частини нового автомобіля перейдемо до 
-1одуля «Автомобілі» та натиснемо кнопку «додати». 
Ви.lrи 
додавання машини 
Нови~ аеrомобиІь 
Рисунок В.6 - д~. а.л о гове вікно реєстр1щії нового автомобіля 
87 
(j 
заповнимо необхідні 
Іlол я , . 
п1сля чо, , ) 
( натиснемо 
на КНОГІІ<у «СТRорнтн» 
11,tаwина "Новий автомобіпь .. ~-­
м~ 6an ао,qи: 110 Ол 
М~ 6-о nІни: 11 1. О,, 
м;,nп"" 6-о томим: 1 1 2.Ол 
р,,о:Ід томим шt fOO І<М: .?О.Ол 
.,. 8иА4ЛИТИ 
маwина "ЗІЛ-131 " (!і!!!і~~!ііі;} 
м,cndcn. 6на ■о,11и: 200.Ол 
м~ 6на nltм: 300.Ол 
мimlicn. 6au томмаа: 100.Ол 
РоСХіА тоn,,им на f ОО км: 1 О.Ол 
машина "ПЗБ-6" 
Micn<Jcn, 6на ао,qм: 100.Ол 
Мicn<icn. 6au nінм: 1 35.Ол 
Micnlkп, 6-u томи-■: 100.Ол 
Росхід тоnпм-■ на fOO км: 20.Ол 
МИЧ е~итм 
Рисунок В. 7 - Сторінка автопарк пожежної частини 
У спішне виконання сцинарію приведе до додавання нового автомобіля в 
базу даних та відображення його на сторінці автопарку пожежної частини . 
6 Створення нової пожежної бригади 
Проведемо до моду ля з черговими командами, вибравши в головному меню 
пункт «Команди». Для користувача АРМ будуть відображені вс і команди які є на 
обліку в даній пожежній частині. На рисунку 8.8 зображений інтерфейс модуля . 
Для створення нової чергової команди, натиснемо кнопку «створити 
Команду». Після чого буде відкрито вікно створення нової команди (рис . 8.9) де 
Ііеобхідно вказати назву команди та заповнити місця новими членами команди. 
Макси . . • J<омандj - 5. Після заловнен1-н~ вс і х пол і в необх ідно 
мальна КІЛЬКІСТЬ м1сть в 
11ер ев·1 рити кнопку «створити» . 
88 
l 
482 ЧДТу 
. . 232097-ОІ 34-01 7 
"0,_.анда "Автоматизована бригада" n.-..,.,...._.. 
@ ,._i.,;n @ n pt'r, tor1 ® nмnagp,1 
- ■@:Q\іш• 8•\далитм 
"0манда "Придніпровські" ..._,,. 
@ andre}' ® anton @ artur @ vitalik 
■ fl .РІііі •ІJі(ЩІ!І4 емдалити 
команда ··рятівник-Черкаси" 
@ aЬanga ® grigory ® agak 
ІіНИІЧР •IQfijjp ви.цалити 
Рисунок B.S - Модуль чергові бригади 
8 FIRE Зs2рненн• Задачі Команди Машини Адмін nанель 
створення команди 
Нова команда 
•и~ріт" пюд•й • команду: 
new_user1 
nt>W_user1 
new_user2 
Рисунок В.9 - Модуль чергові бригади: створення нової команди 
В разі успішного відпрацювання команди «створити», нова бригада буде 
додана до бази даних системи та користувача перенаправить на сторінку 
<<чергових команд» де відобразится нова команда з перерахованими учасниками 
І<оманди (рис.В. І О) та статусом щойно створеної команди. 
89 
"ом•НА• "Нова кома"да" 
-ф ,,,_,. • ~ r1 @ n•e\\•-_usfer-2 4 еим~ит~. 
І(оманда "Автомати,ована бриrада" 
ф op,rator1 @ manager1 ® admin 
- •fflflQ 8~~ити 
І(оманда "Придніпровські" 
@ andrey @ anton @ artur (8) vitalik 
- видалити 
команда "Рятівник-Черкаси" 
@ aЬanga ® grigory ® agak 
- видалити 
Рисунок В.10-Модуль чергові бригади 
90 
АВТОМ тнз в н . р Боч МІ ЦЕ ПОЖЕЖНОГО 
Графічні матеріали 
482.ЧДТУ.232097-01 90-01 
Листів 12 
Розробник Андрійчук В.І. 
Черкаси 2023 
4 1
R . Ч)\ l ' .1 097 О 1 90-0 І 2 
Квалі ік ційн Р f1 кал АР 
Автоматизоване робоче місце пожежноrо 
Пtдг 
Рисунок Г.1 - Слайд презентації №1 
Автоматизоване робоче місце 
пожежного 
• Метою кваліфікаційної роботи являється 
підвищення ефективності управління 
процесами пожежної частини за рахунок 
створення автоматизованого робочого 
місця 
• Об'Ектом розробки є організаційні 
робочі процеси пожежної частини . 
Рисунок Г.2 - Слайд презентації No2 
92 
482 .ЧДТУ.232097-01 90-01 
з 
Задачі проектування: 
_ Предметна облаегь моделювання 
Формування та аналіз вимог до ПЗ 
_ Проектування логічної структури 
_ АрхітектУРне проектування 
_ Моделювання поведінки системи 
Реалізувати програмні модулі. 
_ Провести тестування мобільного додатку. 
Рисунок Г.З - Слайд презентації №3 
Варіант використання системи 
АРМ nО11Се)І(МОІО 
~~ 
Є) 
-- .... end : 
_ 
eЯ•nd 
Ред.,rу"нн• · ·· 
••Р•,..рнстнк extend ~ 
менерер 
ЄS?. . ~ •~-tend : oxtond 
extand ••.. ••. . • .... . ...•. 
~ --,----, 
КnІснт ~ 
lnclude : ~~ Ад"ІнІстротор 
 
a11end 
~ - ~ 4 
Ontp•тop 
Рисунок Г.4 - Слайд презентації No4 
93 
482 . ЧДТУ .232097-0) 90-0) 4 
Діаграма класі в 
<. Model 
t u~rs.models.User с app.models. Тa sk 
с ар p.models.Proposal 
" app.models.Car 
с app.models.Team 
Рисунок Г.5 - Слайд презентації №5 
ё] 
Proposal 
Task 
Вирішення 
поставленої 
задачі Team 
,+. 
І 
І 
І Діаграма 
,І _ -----------------
компонентів 
Характеристики 
автомобіля 
Car 6 
Рисунок г _ Слайд презентації №6 
·6  
94 
.. ---- ._,,,: ;; 
І 
482.ЧДТУ .232097-О І 90-U І 5 
• Діаграма 
скінченого 
автомата 
Єuct.to.:.1.112,,.ш•v.c 
СІ\~ІV,• 
Рисунок Г.7 - Слайд презентації №7 
Діаграма розгортання АРМ Пожежного 
adeVICe• в, 
Database Setver 
django.db.backends. • ll/tlfAC!Jo 
posrgr•sql/stocker SQldataЬaи 
«de~;,1 
W.ЬS.,W, 
6f't\d:,ttч 
в.сьnсІ 
СІdеVМ:0~ 
АРІ Uaar 
~ае!» port 8000 adevк:c ,;t 
Froncand Wab Brows8f 
ua/tlfЗClfll 
HTML5 CSS3 
8 
Рисунок Г.8 _ Слайд презентації №8 
95 
4 2. Ч)~Т 
.~ 1  09 І О І 90 О І 
r, 
Струнтура сист ми 
r------
User ...d.'8n.go ... ..... 
ВАСКЕND 
□- lnternet 
9 
Рисунок Г.9 - Слайд презентації №9 
Використані технології 
• Gitlab СІ 
• Docker Compose reuІS Gitlab СІ 
• Django " 
• Django ORM ~ + 
• Postgresql .,,. • '""У " PostgreSOL 
• DJango Template 
Language dJango ·===· 
Celery Django ORM 
Redls 
г 1О  - Слайд презентації № І О 
Рисунок • 
96 
482. ЧдТУ.2з2097_О І 
7 
Струнтvра бази 
даних 
.. 
• •• ,, ,,,; .t•t.-: tl ttft_UttІ 
1, 
1 <•с•с :1 , ~l!.L' t~_J \ ,1,11.,,, 
'- , • .,,., • • .,.
:t\t11:1c, 
~:•l!tt ,, ~ .... _.,,. 
• ~~,<Wv. •е.::1ен 
1
r, Q 
с,,_~ ee,t,,;.tc,r, 1 l t _l tl~ N ltf 
--Е ;.,.  ....... ~ ~ \;.lf,_to J (І ) lltt1n,,... 
., ~111.r-,l"'t 
t.1e,.~ 
;; l>t'~..<.,.,_.., ~ l.ttl_,,,,-., 
, Іt.ttJІ, 
Ч tt_t:Іиt 
.. "" d,tltjn:tO 
-
----------------------~..: , \/ltt. J1i;t 
l:' 1t.aм_io_r0 
11 
Рисунок Г. 11 - Слайд презентації №11 
Тестування : Авторизація 
8 FIR[ 
8 FIR[ 
sаnмт •2 ,,• .. ,...., 
~ .., . , , ru.--..,.,ci,,,,. 1 
~ ~-~.-~\ 
~ ..: f І ~',,"' ..:, ... ~~ І 
~ 1 {, ~, ~ .. , • .._ •-t •,,,...--. .., •• •. е ~r-.: • 
с и~д презентації №12 
Рисунок Г.12- ла 
97 
r 482-ЧДТУ .232097-0 І 90-0 І 8 
'l"l'"''f' •. ,. " ... ff 
f еt:.ту нн в pti tіНЯ Hrl /8 І 
~аnмт N2 '""'"<\••", ·•-, 
..,,....: q -' п.,~-~-,~,., ·' 
OIW'f: f.•, .-•C"' 41"'\І\ 
,аnмт#1 е.,,...-, 
~"'І, r~r,ч1 д .. ,nf'-,, 
Нове звернення 
х 
;;;;;;;;;:; 
Рисунок Г.13 - Слайд презентації №13 
Тестування : Задачі 
,адеча #2 (ІІІОр('Іф 
~.а: CJ)JI 11.t<,cp,OC-.~ 2 
-ІІІОМ8МА•: ti_.fi1)t1._,1.: 4(.•р,..-с..•• 
.... ....-: ~01..1,-t.~w ,1l f)I 
J8А8Ч8 •1 , .••, ,. •• 
~.,.,. г~еДн"Ір.)1 
-...ct no.-:tJo..l n~pe;,,tІ,L;I'• , O,.:.~r.1 ,ц м ',,..с..:, ,..ц:, а.:>-о 
г.14 - Слайд презентації № 14 
Рисунок 
98 
r 482. ЧДТУ.23 2097-О І 90-О І 
9 
сту ання: Створення команд 
Рисунок Г.15 - Слайд презентації № 15 
Тестування : Команди 
-· "'··· 
коман,qа •двтомаrмювана бриrада" 
~ m.1~:Jc,: (v cprr•tl)r1 @ ,>C-n"' 
А l'W@ll'W _,_,. 
коман,qа "ПриАніпроесІ,Кі" 
Рисунок Г.16 _ Слайд презентації No І 6 
99 
10 
Тестування: Реєстр автомобіJї 1 · 
8 fl/1( 
- - - Рису-но-к Г- •1 7  - Слай. д п. ре.з ентац11" '№-17 
Панель адміністрат"о.,_р.. _ а_~. .. , , ,,..-с;, ,...,,...:,,.,;;.;.,, (J 
DJa"9oa dmini~tra tюn 
, . 
,., 
; . .,  . 
, - . 
. .. .N], І 8 
лайд пр езент ацс ІІ -
Рисунок.  Г . l 8 -
100 
482.Ч)1ТУ .2  2097-О І 90-0 І І І 
r~стування: Мобільна в рсія до/І, к 
О А 64.225 97 219/users, + Q • М 1)4, 1111? Г"''Іr,А + 0 
,\ FIRE ,\ FIRE 
WIMI 
вхід в систему запит 112 
Creгfl(NO 
лnnн •NJ«.•: eyn 0.JCltJ)'8tbl!3 1 
м.с: Ьеrаrо лмщ 
naponь 
Іі&ІІНІІ- ,_,. 
запит 111 
в_,, 
nora,ю 
••·•-
Рисунок Г.19 - Слайд презентації № 19 
Мобільна версія додатку 
+ О А 64.225.97.219/tasks + @ 
О А 64.225.97.219/propo @ 
~ FIRE 
~ FIRE 
Звернення 
Задач і 
задача #2 
Команди 
стоорсно 
Мошини адреса: оул. Пастерівська, 2 
опис: необхідно перевірити джерело 
АдмІн панель 
диму. 
11оманда: РяrІвник-Черкаси 
Вийти 
машина: ПЗБ-6 
dliiiiiiil 8ИД8ЛИТИ 
г 0 _ Слайд презентації N!.!20 
Рисунок •2 
101 
І 
482.ЧДТУ .232097-0 І 90-0 І 12 
Висновки 
• Отже, в ході виконання кваліфікаційної роботи 
було продемонстровано практичні навички 
проєктування та розробки wеЬ-застосунку. 
Завдяки використанню сучасних технології, 
вдалося оптимізувати та покращити процес 
розр~бки програмного забезпечення в даній 
галуз,. 
• Застосунок для автоматизації роботи 
пожежного готовий для використання, є 
достатньо гнучким для подальшого супроводу 
та удосконалення. 
Рисунок Г .21 - Слайд презентації №21 
дякую за yвarv! 
~ д презентації М!22 
рисунок r.-?2 -слаи 
102