1. Repository at ChSTU
  2. Випускні кваліфікаційні роботи
  3. Бакалавр
  4. 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9092
Title: Програмне забезпечення мобільного додатку для моніторингу минулих та прогнозування майбутніх землетрусів
Authors: Олексюк, Вадим Володимирович
Мірзоєв, Ільяс Азер огли
Keywords: МОБІЛЬНИЙ ДОДАТОК;ЗЕМЛЕТРУС;СЕЙСМІЧНА АКТИВНІСТЬ;iOS, SWIFT, SWIFTUI;REST API;ПРОГНОЗУВАННЯ;КАРТА;ЛОКАЛІЗАЦІЯ;USGS;ПРОДУКТИВНІСТЬ;ПРИКЛАДНЕ ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ
Issue Date: 2025
Abstract: Виконавець: Мірзоєв Ільяс Азер огли Назва роботи: "Програмне забезпечення мобільного додатку для моніторингу минулих та прогнозування майбутніх землетрусів". Спеціальність: 121 Інженерія програмного забезпечення. Навчальний заклад: «Черкаський державний технологічний університет» м. Черкаси, 2025р. У бакалаврській роботі розглядається розробка програмного забезпечення мобільного додатку для платформи iOS, що дозволяє відстежувати минулі та майбутні землетруси. Основною метою розробки є створення інтуїтивно зрозумілого інструменту, який забезпечує користувачів актуальною, достовірною та структурованою сейсмічною інформацією у зручному мобільному форматі. У ході роботи було здійснено аналіз існуючих аналогів, визначено ключові потреби цільової аудиторії (мешканців сейсмонебезпечних регіонів, дослідників, туристів тощо), сформовано функціональні та нефункціональні вимоги до мобільного додатку. Розробка проводилась з урахуванням специфіки iOS-платформи, а також рекомендацій з дизайну та продуктивності Apple. Основні етапи дослідження включають: ‒ формування вимог: проведено збір та аналіз даних щодо потреб користувачів у швидкому доступі до інформації про землетруси. Визначено функції додатку, серед яких – перегляд карти з епіцентрами, список останніх землетрусів, повідомлення про майбутні події (на основі моделей прогнозування), фільтрація за регіонами, магнітудою та датою; ‒ моделювання функціоналу: створено концептуальні та логічні моделі додатку, продумано структуру зберігання даних, інтерфейс користувача, сценарії взаємодії з користувачем, а також архітектуру клієнт-серверної взаємодії для отримання сейсмічних даних з API (наприклад, USGS, EMSC); ‒ реалізація додатку: розробку здійснено з використанням Swift та фреймворку SwiftUI для створення сучасного адаптивного інтерфейсу. Для отримання сейсмічних даних реалізовано інтеграцію з відкритими джерелами через REST API. Забезпечено зберігання локальної історії землетрусів, кешування даних та адаптивне оновлення. Здійснено тестування та оптимізацію продуктивності. Результати роботи демонструють, що розроблене програмне забезпечення ефективно виконує поставлені завдання, надаючи користувачам зручний інструмент для моніторингу сейсмічної активності. Додаток відзначається високою швидкодією, стабільністю роботи та зручністю інтерфейсу, що робить його перспективним для подальшого вдосконалення та розширення функціональності.
URI: https://er.chdtu.edu.ua/handle/ChSTU/9092
Appears in Collections:121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)

Files in This Item:
File Description SizeFormat 
Ilias Mirzoiev.pdf
  Restricted Access		17.1 MBAdobe PDFView/Open Request a copy
Show full item record


Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.

Extracted text 
 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
  
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«бакалавра» 
освітній рівень 
 
на тему «Програмне забезпечення мобільного додатку для моніторингу 
минулих та прогнозування майбутніх землетрусів» 
 
Виконав: студент 4 курсу, групи ПЗ-2104 
Спеціальності 
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
 
Студент Мірзоєв І.А. 
  (прізвище та ініціали) 
Керівник Олексюк В.В. 
  (прізвище та ініціали) 
Рецензент Ільченко І. О. 
  (прізвище та ініціали) 
 
 
 
 
Черкаси 2025 
 
 
                                   Черкаський державний технологічний університет                                       
повне найменування вищого навчального закладу 
Факультет               інформаційних технологій і систем       
Кафедра                  програмного забезпечення автоматизованих систем    
Освітній рівень      бакалавр           
Спеціальність        121 «Інженерія програмного забезпечення»      
Освітня програма  Інженерія програмного забезпечення       
  
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
___________                  Голуб С.В. 
«___» _______________ 2025 року 
  
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
                                                            Мірзоєв Ільяс Азер огли      
(прізвище, ім’я, по батькові) 
1. Тему проекту (роботи) «Програмне забезпечення мобільного додатку для моніторингу минулих та 
прогнозування майбутніх землетрусів»             
Керівник проекту (роботи) Олексюк Вадим Володимирович кандидат наук, доцент   
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від « 25 » лютого 2025 року 
№53/03/03 
2. Строк подання студентом проекту (роботи) 3 червня 2025 р. 
3. Вхідні дані до проекту (роботи) Технічне завдання на розробку, методичні рекомендації до виконання 
бакалаврської роботи, автоматизовані системи, терміни та визначення.   
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) 
Вступ;  
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань;     
Розділ 2. Впровадження результатів досліджень у практику проектування програмного  
забезпечення інформаційних систем;         
Розділ 3. Розробка та тестування програмного забезпечення;      
Висновки;             
Список використаних джерел;          
Додатки.             
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту; 
Слайд 1; Слайд 2; Слайд 3; Слайд 4; Слайд 5; Слайд 6; Слайд 7; Слайд 8; Слайд 9; Слайд 10; Слайд 11; 
Слайд 12; Слайд 13; Слайд 14; Слайд 15; Слайд 16; Слайд 17; Слайд 18; Слайд 19; Слайд 20; Слайд 21; 
Слайд 22; Слайд 23; Слайд 24.      
6. Консультанти розділів проекту (роботи) 
Розділ Прізвище, ініціали та Підпис, дата 
посади консультанта 
Завдання видав Завдання прийняв 
1       
2       
  
7. Дата видачі завдання 02 грудня 2025 р.         
 
  
КАЛЕНДАРНИЙ ПЛАН 
№ Назва етапів випускної роботи Строк Примітки 
п виконання 
/ етапів 
п випускної 
роботи 
1 Постановка задачі 05.12.2024 виконано 
2 Підготовка завдання 13.12.2024 виконано 
3 Погодження завдання 16.12.2024 виконано 
4 Затвердження завдання 19.02.2025 виконано 
  Основна стадія     
1 Підбір матеріалів 27.02.2025 виконано 
2 Аналіз шляхів вирішення поставленої задачі 04.02.2025 виконано 
3 Розрахунок основних параметрів роботи 10.03.2025 виконано 
4 Вибір кінцевого варіанту проектного рішення 17.03.2025 виконано 
5 Оформлення первісної редакції роботи 25.03.2025 виконано 
  Заключна стадія     
1 Узгодження прийнятих проектних рішень з керівником 31.04.2025 виконано 
2 Оформлення пояснювальної записки роботи в кінцевій 13.05.2025 виконано 
редакції 
3 Попередній захист роботи 15.05.2025 виконано 
4 Затвердження роботи 31.05.2025 виконано 
5 Рецензування роботи 20.05.2025 виконано 
6 Захист роботи 6.06.2025   
  
Студент  _____________________ Мірзоєв І.А. 
(підпис)  (прізвище та ініціали) 
Керівник проекту (роботи) _____________________ Олексюк В.В. 
(підпис)  (прізвище та ініціали) 
 
 
 
 
 
 
 
 
 
 
 
АНОТАЦІЇ 
Виконавець: Мірзоєв Ільяс Азер огли 
Назва роботи: "Програмне забезпечення мобільного додатку для 
моніторингу минулих та прогнозування майбутніх землетрусів". 
Спеціальність: 121 Інженерія програмного забезпечення. 
Навчальний заклад: «Черкаський державний технологічний університет» м. 
Черкаси, 2025р. 
У бакалаврській роботі розглядається розробка програмного забезпечення 
мобільного додатку для платформи iOS, що дозволяє відстежувати минулі та 
майбутні землетруси. Основною метою розробки є створення інтуїтивно 
зрозумілого інструменту, який забезпечує користувачів актуальною, достовірною 
та структурованою сейсмічною інформацією у зручному мобільному форматі. 
У ході роботи було здійснено аналіз існуючих аналогів, визначено ключові 
потреби цільової аудиторії (мешканців сейсмонебезпечних регіонів, дослідників, 
туристів тощо), сформовано функціональні та нефункціональні вимоги до 
мобільного додатку. Розробка проводилась з урахуванням специфіки 
iOS-платформи, а також рекомендацій з дизайну та продуктивності Apple. 
Основні етапи дослідження включають: 
‒ формування вимог: проведено збір та аналіз даних щодо потреб 
користувачів у швидкому доступі до інформації про землетруси. Визначено 
функції додатку, серед яких – перегляд карти з епіцентрами, список останніх 
землетрусів, повідомлення про майбутні події (на основі моделей прогнозування), 
фільтрація за регіонами, магнітудою та датою; 
‒ моделювання функціоналу: створено концептуальні та логічні моделі 
додатку, продумано структуру зберігання даних, інтерфейс користувача, сценарії 
взаємодії з користувачем, а також архітектуру клієнт-серверної взаємодії для 
отримання сейсмічних даних з API (наприклад, USGS, EMSC); 
‒ реалізація додатку: розробку здійснено з використанням Swift та 
фреймворку SwiftUI для створення сучасного адаптивного інтерфейсу. Для 
отримання сейсмічних даних реалізовано інтеграцію з відкритими джерелами 
 
через REST API. Забезпечено зберігання локальної історії землетрусів, кешування 
даних та адаптивне оновлення. Здійснено тестування та оптимізацію 
продуктивності. 
Результати роботи демонструють, що розроблене програмне забезпечення 
ефективно виконує поставлені завдання, надаючи користувачам зручний 
інструмент для моніторингу сейсмічної активності. Додаток відзначається 
високою швидкодією, стабільністю роботи та зручністю інтерфейсу, що робить 
його перспективним для подальшого вдосконалення та розширення 
функціональності. 
Ключові слова: МОБІЛЬНИЙ ДОДАТОК, ЗЕМЛЕТРУС, СЕЙСМІЧНА 
АКТИВНІСТЬ, iOS, SWIFT, SWIFTUI, REST API, ПРОГНОЗУВАННЯ, КАРТА, 
ЛОКАЛІЗАЦІЯ, USGS, ПРОДУКТИВНІСТЬ, ПРИКЛАДНЕ ПРОГРАМНЕ 
ЗАБЕЗПЕЧЕННЯ 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ANNOTATIONS 
Performer: Mirzoiev Ilias Azier ogly. 
The title of the work: "Software for a Mobile Application to Track Past and 
Predictions of Upcoming Earthquakes". 
Specialty: 121 Software engineering. 
Educational institution: Cherkasy State Technological University, Cherkasy, 2025. 
The bachelor's thesis explores the development of software for an iOS mobile 
application that allows users to track past and upcoming earthquakes. The main goal of 
the project is to create an intuitive tool that provides users with up-to-date, reliable, and 
well-structured seismic information in a convenient mobile format. 
During the development process, an analysis of existing solutions was conducted, 
key user needs were identified (including residents of seismically active regions, 
researchers, tourists, etc.), and functional and non-functional requirements for the 
mobile application were defined. The development was carried out in accordance with 
the specifics of the iOS platform and Apple’s design and performance guidelines. 
The main stages of the project include: 
‒ Requirements gathering: User needs for quick access to earthquake-related 
information were studied. The application's core features were defined, including map 
visualization of epicenters, a list of recent earthquakes, notifications of potential future 
events (based on predictive models), filtering by region, magnitude, and date; 
‒ Functionality modeling: Conceptual and logical models of the application were 
developed, along with data storage structures, user interface layouts, interaction 
scenarios, and client-server architecture for retrieving seismic data from APIs (e.g., 
USGS, EMSC); 
‒ Implementation: The application was developed using Swift and the SwiftUI 
framework to create a modern, adaptive user interface. Integration with public data 
sources was implemented via REST APIs to fetch seismic information. Local storage of 
earthquake history, data caching, and adaptive updates were also developed. Testing and 
performance optimization were carried out. 
 
The results show that the developed software effectively meets the defined 
objectives by providing users with a convenient tool for monitoring seismic activity. 
The app demonstrates high performance, stability, and a user-friendly interface, making 
it a promising solution for further development and feature expansion. 
Keywords: MOBILE APPLICATION, EARTHQUAKE, SEISMIC ACTIVITY, 
iOS, SWIFT, SWIFTUI, REST API, PREDICTION, MAP, LOCALIZATION, USGS, 
PERFORMANCE, APPLICATION SOFTWARE 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ЗМІСТ 
ВСТУП 5 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ 
ЗАВДАНЬ 11 
1.1 Огляд платформ та фреймворків для розробки iOS-додатків 11 
1.2 Методи аналізу iOS-додатку 13 
1.3 Порівняльний аналіз існуючих аналогів 14 
1.4 Постановка задачі 15 
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ 17 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ 18 
2.1 Моделювання предметної області 18 
2.1.1 Предметна область моделювання. Модель предметної області. Словник 
предметної області. 18 
2.1.2 Елементи моделювання предметної області 20 
2.1.3 Робоча область моделювання 22 
2.2 Формування та аналіз вимог 23 
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні вимоги. 
Вимоги замовника і розробника. Функціональні та нефункціональні вимоги. 23 
2.2.2 Формування вимог за допомогою діаграми прецедентів 27 
2.3 Проектування логічної структури програмного комплексу 28 
2.3.1 Діаграми класів 28 
2.3.2 Діаграма пакетів 31 
2.4 Архітектура проектування 32 
2.4.1 Діаграма компонентів 32 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма розгортання 33 
2.5 Моделювання поведінки системи 35 
2.5.1 Діаграма діяльності 35 
2.5.2 Діаграма послідовності 37 
2.5.3 Діаграма комунікації 38 
2.5.4 Діаграма скінченного автомату 39 
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ 42 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 43 
3.1 Розробка програмного комплексу 43 
3.1.1 Обґрунтування вибору засобів реалізації 43 
3.1.2 Опис структурної (функціональної) схеми 44 
3.1.3 Опис логічної схеми 48 
      
     ЧДТУ 252161.013ПЗ 
Змн. Арк. № докум. Підпис Дата  
Розроб. Мірзоєв І.А.   «Програмне забезпечення Літ. Лист. Листів 
Первір. Олексюк В.В   мобільного додатку для    3  
    моніторингу минулих та  
Н. Контр. прогнозування майбутніх 
Півень О.Б   землетрусів» ФІТІС, кафедра ПЗАС, ПЗ-2104 
Затверд. Голуб С.В.   Пояснювальна записка  
 
 
 
3.1.4 Розробка бази даних 50 
3.1.5 Розробка інтерфейсу користувача 52 
3.1.6 Опис розробки програмних компонентів 68 
3.2 Тестування системи 68 
3.2.1 Модульне тестування 69 
3.2.2 Інтеграційне тестування 70 
3.2.3 Системне тестування 72 
3.2.4 Приймальне тестування 73 
3.3 Приклади впровадженого програмного комплексу 75 
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ 80 
ВИСНОВКИ 81 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 82 
ДОДАТОК А 85 
ДОДАТОК Б 87 
ДОДАТОК В 105 
ДОДАТОК Г 109 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   
  ЧДТУ 252161.013ПЗ 
   
мн. рк. докум. № Підпис р дата  
 
ЧДТУ 252161.013ПЗ 
 
ВСТУП 
Актуальність теми: полягає в необхідності проєктування мобільного 
додатку, який не лише інформує користувачів про минулі землетруси, а й на основі 
цих даних прогнозує ймовірність майбутніх. Такий підхід вимагає застосування 
сучасних методів аналітики та машинного навчання для обробки великих обсягів 
сейсмологічної інформації, побудови моделей прогнозування та їх інтеграції в 
мобільне середовище. З інженерної точки зору, проєкт передбачає вирішення 
складних завдань, зокрема реалізацію архітектури з підтримкою обчислень на 
стороні клієнта або сервера, забезпечення продуктивності й масштабованості, а 
також впровадження ефективної взаємодії між модулями прогнозування, обробки 
даних та користувацьким інтерфейсом [11]. 
1    Проблема та завдання системи 
Мета - створити надійний мобільний клієнт, який: 
–    отримує сейсмологічні дані з зовнішніх API; 
–    забезпечує фільтрацію за геолокацією, магнітудою, глибиною; 
–    зберігає історичні дані для аналітичної обробки [19]. 
2    Цільові користувачі та вимоги до функціональності 
Кінцеві користувачі (End-users) 
–  Вимоги: UX-оптимізований інтерфейс, мінімальні затримки оновлення, 
офлайн-режим з кешуванням останніх подій, адаптивність під мобільні 
форм-фактори. 
–  Функції: геолокаційна фільтрація подій, миттєві сповіщення, перегляд 
інтерактивної мапи з подіями, перегляд прогнозів та історії. 
3    Програмна архітектура та технології: Frontend - SwiftUI (iOS), інтеграція 
з API - RESTful інтеграція з USGS/EMSC, з використанням URLSession, 
зберігання: Core Data для локального збереження історії 
4    Інтеграція з інформаційною екосистемою 
Завдяки підключенню до перевірених джерел сейсмічних даних, 
посередники можуть значно зекономити ресурси на початковому зборі та 
перевірці інформації. Це дозволяє зосередитися на візуалізації даних, покращенні 
5 
ЧДТУ 252161.013ПЗ 
 
взаємодії з користувачем і забезпеченні стабільної передачі інформації. Підхід, що 
базується на принципі «API насамперед», дає змогу легко адаптувати систему до 
змін у зовнішніх сервісах. 
5    Вплив і цінність 
Створення такого додатка полегшує негайне інформування та покращує всю 
культуру безпеки. Програмний каркас може на аналогічний спосіб 
застосовуватись для органів цивільного захисту, шкіл та науково-дослідницьких 
груп. 
Mета і завдання охоплюють весь процес створення мобільних додатків для 
моніторингу сейсмічної активності - від аналізу вимог та розробки архітектури до 
реалізації, інтеграції зі сторонніми сервісами та тестування [1]. Створений код 
повинен надавати користувачам найостаннішу інформацію про землетруси, мати 
стабільність публікації, бути масштабованим для операцій з клієнтом і 
зосереджуватися на інтерфейсі користувача. 
Для виконання цього слід здійснити такі кроки: 
1 Здійснення збору, формалізації та класифікації функціональних та 
нефункціональних вимог до системи з урахуванням очікувань користувачів. 
2 Створення конкретного технічного завдання, яке включатиме мету, 
функції, обмеження, характер оточення додатку, безпеку та джерело даних. 
3  Створіть мобільний додаток з вибраним стеком технологій (Swift iOS) з 
інтерфейсом користувача, картою з епіцентрами землетрусів та списком подій з 
фільтруванням та деталями. 
4   Розробити мобільний додаток з використанням обраного технологічного 
стеку (Swift для iOS), реалізувати інтерфейс користувача, карту з відображенням 
епіцентрів землетрусів, список подій з фільтрацією та деталізацією. 
5  Інтеграція зовнішніх API з іншими сторонами також була важливим 
аспектом. Підключення до сейсмологічного API міжнародних агентств 
(наприклад, USGS або EMSC) для обробки в реальному часі та оновлення даних, з 
управлінням помилками та повторними запитами. 
6 
ЧДТУ 252161.013ПЗ 
 
6  Додайти кешування, обробку історичних даних за допомогою локальної 
бази даних (SQLite або Core Data) з можливостями карти, пошуку, сортування та 
фільтрації. 
7 Реалізація юніт-тестування додатків, інтеграційного та тестування 
користувачів; оцінка стабільності, продуктивності, функціональних вимог і 
зручності використання для виявлення невідповідностей чи вразливостей. 
Об'єкт розробки. Становить собою процес створення мобільного додатку 
для моніторингу землетрусів у реальному часі та перегляду архівних даних про 
сейсмічні події. 
Предметом розробки є процес розробки програмного забезпечення для 
мобільного додатку моніторингу сейсмічної активності та перегляду прогнозів. 
Методи проєктування та конструювання. Реалізація мобільного додатку 
для моніторингу землетрусів була виконана з використанням ітераційної моделі 
життєвого циклу програмного забезпечення, в якій розробка розподілена на серії 
повторюваних циклів (ітерацій). Працездатний прототип з тестуванням та 
доопрацюванням здійснювався після кожної ітерації, що надавало гнучкість для 
адаптації до змін вимог та покращення користувацького досвіду. 
Основою проєктування стала об'єктно-орієнтована методологія, тобто 
створювалася модель системи так, ніби це об'єкти з атрибутами і поведінкою. 
Елементи організовані у класах і взаємодіють один з одним через чітко визначені 
інтерфейси. Такий метод дозволяє досягти високого ступеня повторного 
використання коду і приховати внутрішні робочі процеси системи за допомогою 
інкапсуляції, спадкування та поліморфізму, що робить обслуговування та 
додавання нових функцій зрозумілим і значно легшим. 
Додаток побудований із використанням шаблону проєктування MVVM 
(Model-View-ViewModel), що дозволяє безперебійний розподіл відповідальності 
між компонентами: 
– модель: класи, які керують доступом до даних і функціями, що стосуються 
сейсмічності; 
7 
ЧДТУ 252161.013ПЗ 
 
– ViewModel використовується як проміжна ланка між моделлю та 
презентацією, забезпечуючи логіку відображення, фільтрацію подій та 
форматування даних користувача; 
–    подання має лише візуальне представлення і відстежує зміни. 
За допомогою дизайну MVVM стало легше забезпечити високу тестованість 
компонентів, і те, що презентація ізольована від бізнес-логіки, дозволило нам 
легше впроваджувати нові функції. 
Під час реалізації використовувалися такі техніки будівництва: 
–  дизайн користувацького інтерфейсу: гнучкий, легкий у використанні 
інтерфейс створено для візуалізації карт землетрусів, фільтрації подій за датою та 
місцем розташування, перегляду історії та статистики; 
– клієнтська сторона: опрацьовувалися відкриті дані про сейсмічну 
активність (як у USGS). Локалізація пошуку здійснювалася без окремого бекенда 
сервера; 
–   інтеграція бази даних: дані користувача та історія переглядів зберігалися 
з використанням хмарного бекенду Firebase та локального кешування; 
–  тестування: Розробка додавання індивідуальних значень, фаза 3. На 
останньому етапі ми провели тестування на рівні модулів та інтеграційне 
тестування, щоб перевірити, чи функціональність, взаємодія компонентів та 
загальний користувацький досвід працюють відповідно до очікувань. 
Таким чином, об'єктно-орієнтований підхід у поєднанні з архітектурою 
MVVM ефективно задовольнив вимоги до легко масштабованого та зручного в 
обслуговуванні впровадження мобільного застосунку для відстежування 
землетрусів. 
Опис отриманих результатів. Реалізація бакалаврського проекту дала 
значні результати, які демонструють ефективність використаної методології 
розробки програмного забезпечення, що відстежує сейсмічні процеси. Було 
сформульовано детальні функціональні та нефункціональні вимоги, а також 
розроблено інформативний інтерфейс на базі відкритих джерел. 
8 
ЧДТУ 252161.013ПЗ 
 
На основі зібраних даних були визначені основні функціональні можливості 
додатку: 
–    деталізоване відображення історії землетрусів у конкретному регіоні; 
–   прямий доступ до інформації про останні зареєстровані сейсмічні події 
по всьому світу; 
– аналітичний прогноз ймовірності повторного виникнення нових 
землетрусів; 
–  удосконалене фільтрування подій за різними параметрами (магнітуда, 
глибина, геолокація); 
–    можливість збереження обраних регіонів для швидкого доступу. 
Структура програмного забезпечення включає побудову трирівневої 
архітектури: 
1  Концептуального - опис основного модуля програмного забезпечення 
(сервісів програми, роботи з сервісом програм). 
2   Логічного - опис взаємозв’язків між модулями та принципів взаємодії 
між програмуванням та користувацькою функціональністю. 
3  Фізичного - побудова фізичної структури бази даних та організаційні 
питання збереження історичних подій, оптимізації мережевих запитів. 
Мобільний додаток було реалізовано на Swift для iOS з використанням 
офіційного API USGS, і підтримується ефективний локальний кеш, навіть при 
з'єднаннях з низькою пропускною здатністю, для безперервного використання. 
Додаток успішно пройшов всі частини систематичних тестувань, таких як 
функціональні, навантажувальні та тести на зручність використання, показав 
хорошу стабільність системи, обробку даних та правильне відображення 
реалізованих геолокаційних подій у різних сценаріях використання додатка. 
На основі результатів проекту були сформовані рекомендації для розвитку: 
– більш масштабна інтеграція з офіційними державними системами 
попередження про небезпеку; 
–    підтримка інтересів користувачів щодо платформи Android; 
9 
ЧДТУ 252161.013ПЗ 
 
–  надання користувачам статистичної інформації у вигляді інтерактивної 
графіки. 
Практичне значення отриманих результатів. Розроблений мобільний 
застосунок має значний прикладний потенціал і може бути ефективно 
використаний для збільшення інформування громадян про випадки сейсмічної 
активності.  
Завдяки продуманій архітектурі він вирізняється гнучкістю та здатністю до 
масштабування, що дозволяє без суттєвих змін у структурі додати підтримку 
нових джерел даних, реалізувати багатомовний інтерфейс та забезпечити 
інтеграцію з локальними системами сповіщення у різних регіонах. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
10 
ЧДТУ 252161.013ПЗ 
 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
Завдяки мобільним додаткам, які забезпечують автоматизацію, доступ до 
даних у потрібний час та інтерфейси, розроблені для високої мобільності й 
зручності використання, була обрана платформа iOS (iPhone та iPad), яка надає 
розширені функції, такі як інтеграція з апаратними датчиками (GPS) та обробка 
складних даних. Вона розроблена мовою програмування Swift, яка показала 
високу продуктивність [17]. 
Основне завдання додатків для попередження про землетруси - повідомити 
вас про можливі загрози, бажано за допомогою надійної інформації і зручним 
способом. Успішні додатки iOS в цьому випадку будуть підключені до 
геолокаційних служб для відстеження місця розташування користувача. У 
додатках для iOS можливо використовувати хмарне зберігання та кешування для 
доступності даних. 
1.1 Огляд платформ та фреймворків для розробки iOS-додатків 
Додатки iOS розробляються на різних платформах і з використанням різних 
фреймворків, які мають різні функціональні можливості. 
SwiftUI - один із найсучасніших способів дизайну користувацьких 
інтерфейсів у світі iOS, що використовує декларативний підхід. Він дозволяє 
створювати гнучкі та адаптивні інтерфейси з меншими зусиллями, які 
автоматично налаштовуватимуться відповідно до різних пристроїв з iOS 13. 
Переваги: 
–   декларативний стиль кодування, що робить ваш код більш організованим 
і зрозумілішим для читання; 
–    автоматична реконфігурація інтерфейсу для різних екранів і режимів; 
–    тісна інтеграція з новими можливостями iOS; 
–    менше коду для досягнення бажаного результату. 
Недоліки: 
–    підтримується лише з iOS 13 і новіших версій; 
–    вимагає освоєння нових концепцій для розробників, які звикли до UIKit; 
11 
ЧДТУ 252161.013ПЗ 
 
–  не такий зрілий, як UIKit - менше прикладів, менше рішень, менше 
документації. 
UIKit: Це імперативний, традиційний спосіб створення інтерфейсів в iOS. 
Він був основним інструментом розробки iOS до SwiftUI. 
Переваги: 
–    багата та стабільна документація; 
–    велика кількість вбудованих UI-компонентів; 
–    перевірена часом технологія з великою базою прикладів; 
–    повна підтримка всіх версій iOS. 
Недоліки: 
–    складніший у реалізації адаптивних та сучасних інтерфейсів; 
–  потребує більше коду для реалізації тих самих функцій, які у SwiftUI 
можна зробити коротше; 
–    менше автоматизації - більше ручного управління поведінкою UI. 
React Native - це фреймворк на основі JavaScript, що дозволяє створити 
мобільні додатки один раз і розгорнути їх на iOS та Android. 
Переваги: 
–    можливість розробки додатків для різних платформ з використанням 
одного коду; 
–    велика спільнота та підтримка Facebook; 
–    активна розробка та безліч готових бібліотек. 
Недоліки: 
–     нижча продуктивність порівняно з нативними рішеннями; 
–  інколи потрібно використовувати довгий функціонал у вигляді 
нативних модулів. 
SignalR - це фреймворк від Microsoft, який дозволяє розробляти 
кросплатформенні додатки, охоплюючи браузери, а також настільні та мобільні 
додатки. Завдяки власному рушію відображення, він має високу продуктивність і 
вирізняється спільним інтерфейсом на різноманітних платформах. 
Переваги: 
12 
ЧДТУ 252161.013ПЗ 
 
–    власний рушій відображення (висока продуктивність) на основі XML; 
–    уніфікований вигляд інтерфейсу на iOS та Android; 
–    багата колекція UI-компонентів та віджетів. 
Недоліки: 
–    потреба вивчення мови Dart; 
–    великі розміри застосунків; 
–   низький рівень інтеграції з рідними API телефону в порівнянні з такими 
на рідних платформах. 
Для створення програми для землетрусів було використано мову Swift у 
поєднанні з фреймворком SwiftUI, щоб відповідати вимогам до продуктивності, 
інтерактивності та налаштовуваності інтерфейсу сьогодення. Цей стек забезпечує 
міцну основу для створення додатку згідно зі стандартами продуктивності, 
гнучкості, масштабованості [17]. 
1.2 Методи аналізу iOS-додатку 
Розробка iOS-додатку потребує комплексного аналізу для забезпечення 
високої ефективності та надійності. 
SWOT-аналіз визначає сильні сторони (SwiftUI для адаптивних 
інтерфейсів, продуктивність Swift), слабкі сторони (вимоги сумісності з різними 
версіями iOS), можливості (інтеграція з Core Location) та загрози (оптимізація для 
старіших пристроїв, конкуренція). 
PEST-аналіз (політичний, економічний, соціальний, технологічний) 
дозволяє оцінити зовнішні фактори впливу на розробку та використання додатку. 
Аналіз даних допомагає визначити ключові функції, виявити слабкі місця 
продуктивності та оптимізувати обробку даних. 
Моделювання процесів використовується для симуляції поведінки 
користувачів, оптимізації ресурсів пристрою та аналізу паралельного виконання 
завдань [2]. 
Аналіз ризиків фокусується на безпеці даних, стабільності при роботі з 
великими обсягами інформації та сумісності з різними версіями ОС. 
13 
ЧДТУ 252161.013ПЗ 
 
Аналіз потреб користувачів виявляє пріоритетні функції: миттєві 
сповіщення про землетруси, зручність інтерфейсу та інтеграцію з картами. 
Застосування цих методів забезпечує створення ефективного додатку, що 
відповідає сучасним вимогам, враховуючи як внутрішні характеристики, так і 
зовнішні фактори впливу. 
Аналіз існуючих рішень охоплює три ключові аналоги. Сайт USGS 
Earthquake Hazards Program пропонує високонадійний інтерфейс з науковою 
структурою даних, потужні інструменти пошуку та доступ до інформації з 
першоджерела, проте має обмежену мобільну адаптацію, залежність від 
інтернет-з'єднання та відсутність персоналізованих сповіщень. 
1.3 Порівняльний аналіз існуючих аналогів 
Ми обговорюємо існуючі роботи в таких трьох аналогах. 
Веб-сайт програми вивчення землетрусів USGS забезпечує дуже якісний 
інтерфейс із науковою структурою даних, ефективний пошуковий інтерфейс, 
можливість витягування даних із джерела запису, але не має портативності на 
мобільні платформи, вимагає підключення до Інтернету (в деяких випадках) і 
наразі не забезпечує можливості персоналізованих сповіщень. 
 
 
Рисунок 1.1 - Сайт USGS Earthquake Hazards Program 
 
Мобільний додаток "My Earthquake Alerts" дозволяє надсилати 
пуш-сповіщення і зберігає налаштування користувача, містить інтерактивну карту, 
має дані навіть про найменші зареєстровані землетруси, не вимагає встановлення, 
не має веб-версії, а доступ до деяких функцій не є безкоштовним. 
14 
ЧДТУ 252161.013ПЗ 
 
 
Рисунок 1.2 - Мобільний додаток Earthquake Alerts 
 
Телеграм-бот "Earthquake Alerts Bot" надається без установки, має легкий 
інтерфейс, і його налаштування сповіщень можуть бути конфігурованими, але він 
має лише мінімальну функціональність, прив'язаний до Telegram і не доступний 
офлайн [10]. 
 
 
Рисунок 1.3 - Телеграм бот Earthquake Alerts Bot 
 
Порівняно з існуючими практиками, додаток для iOS про землетруси має 
великий потенціал, оскільки він надає переваги кожного з них: інформативну 
карту для аналізу і зручність для мобільних користувачів, тому розробка додатку 
для iOS про землетруси є перспективною 
1.4 Постановка задачі 
На основі оцінки платформ, підходів та аналогів були визначені деякі 
завдання для реалізації додатку iOS про землетруси. 
15 
ЧДТУ 252161.013ПЗ 
 
Аналіз вимог користувачів включає дослідження ситуацій і потреб, щоб 
з'ясувати, які є основні вимоги (вчасні сповіщення, інтерактивні карти) та 
дослідження існуючих сервісів. 
Системні вимоги поділяються на функціональні (відображення землетрусів 
на карті, фільтрація, персоналізація профілю користувача) та нефункціональні 
(продуктивність, надійність, масштабованість, безпека даних). 
Технічний стек, що є в основі додатку, включатиме: 
–   Swift та SwiftUI для створення гнучкого інтерфейсу 
–   інтеграцію з MapKit або Google Maps 
–   зберігання глобальних даних за допомогою Core Data або SQLite. 
Дизайн включає проєктування архітектури, інтеграцію API (USGS), 
очищення та створення дійсно інтуїтивного інтерфейсу. 
Останнім кроком є розширене (функціональне і навантажувальне) 
тестування і валідація додатку із залученням кінцевих користувачів для 
подальшого вдосконалення. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
16 
ЧДТУ 252161.013ПЗ 
 
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ 
У першому розділі проведено огляд платформ і фреймворків для розробки 
додатка iOS про землетруси та обрано всі інструменти проєкту. Визначено методи 
аналізу, які забезпечують відповідну оцінку потреб користувачів, вимог системи, 
ризиків і продуктивності додатка. 
Слідом за оглядом і порівнянням аналогічних джерел, а також позитивних і 
негативних аспектів доступних вебсайтів, мобільних додатків та джерел 
інформації про землетруси в Telegram-ботах, це призвело до визначення основних 
функціональних і нефункціональних вимог до нового додатка. 
На основі зібраної інформації було сформульовано постановку задачі, яка 
охоплює всі етапи розробки: від аналізу потреб користувачів і вибору технологій 
до реалізації функціоналу та тестування. 
Таким чином, виконані в першому розділі дослідження забезпечили міцну 
основу для подальшої розробки iOS-додатку, що матиме високу ефективність, 
продуктивність і зручність використання, відповідаючи сучасним потребам 
користувачів. 
 
 
 
 
 
 
 
 
 
 
 
 
17 
ЧДТУ 252161.013ПЗ 
 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У 
ПРАКТИКУ ПРОЕКТУВАННЯ 
2.1 Моделювання предметної області 
Моделювання предметної області є вирішальним етапом при створенні 
iOS-додатку, який відстежує і перераховує минулі землетруси, а також оцінює 
ймовірність нових. Це дозволяє здійснити абстрактну концептуалізацію системи, 
розпізнання важливих компонентів і розуміння їх взаємозв’язків. Завдяки цьому 
можна визначити загальні функціональні вимоги додатку, враховуючи особливості 
обробки просторових і часових даних і спираючись на інтеграцію з зовнішніми 
джерелами даних, такими як API геологічних служб. Цей метод запобігає 
недолікам у дизайні додатку, робить його максимально потужним і зручним для 
користувача. 
2.1.1 Предметна область моделювання. Модель предметної області. Словник 
предметної області. 
Предметна область моделювання для додатку iOS з відстеженням минулих 
землетрусів і прогнозуванням ймовірності нових включає в себе збір, аналіз і 
запити сейсмічних даних. Основні підмодулі включають: 
–   відкриті геологічні служби для отримання інформації про геосервіси для 
певної області; 
– обробку даних для локального зберігання в режимі онлайн та 
прогнозування; 
–   алгоритм для оцінки ймовірності майбутніх подій; 
–   перегляд на картах і функції для користувача з вибору областей. 
Модель предметної області. Користувачі - особи, які взаємодіють із 
додатком. Вони можуть переглядати інформацію про землетруси, налаштовувати 
персональні параметри, зберігати локації тощо. Для кожного користувача є 
окремий профіль та фільтри. 
Дані про землетруси - це набір параметрів, які описують кожен зафіксований 
землетрус: 
–    час - точна дата і час виникнення землетрусу; 
18 
ЧДТУ 252161.013ПЗ 
 
–    координати: епіцентр землетрусу (широта і довгота); 
–    магнітуда: розмір землетрусу, що представляє енергію, яка звільняється; 
–    глибина: глибина, на якій стався землетрус під поверхнею Землі. 
Передвісники - це інформація про дані або моделі, які оцінюють 
ймовірність виникнення землетрусу в певному місці: 
–    ймовірність: міра шансу виникнення землетрусу в даний період. 
–  параметри моделі: умови та вихідні дані математичних/статистичних 
моделей для прогнозування (наприклад, минула сейсмічність, геофізичні 
обставини, частота виникнення землетрусів). 
–  прогнози - дані, що оцінюють ймовірність виникнення землетрусу в 
певному регіоні: 
–    візуалізація - спосіб наочного представлення інформації у вигляді 
Словник предметної області.  iOS-додаток - програмне забезпечення, 
розроблене для мобільної операційної системи iOS (Apple), яке користувач може 
встановити на iPhone або iPad. Щодо теми - це додаток, який відстежує 
землетруси. 
Землетрус - це сила природи, єдина, різко підземна подія, яка відбувається, 
коли тектонічні плити зміщуються або через інший геологічний рух. Вони 
трапляються в різних масштабах, від слабких до руйнівних. 
Магнітуда - це міра відносного розміру енергії, що вивільняється під час 
землетрусу. Зазвичай вона оцінюється за шкалою, відомою як шкала Ріхтера. Чим 
більша магнітуда, тим сильніший землетрус. 
АПІ геологічних служб - АПІ геологічних установ (наприклад, USGS або 
EMSC) для отримання даних про сейсмічну активність (час, місце, магнітуда і т. 
д.). Це АПІ, які можна використовувати для інтеграції даних про землетруси в 
додаток. 
Прогнозування включає оцінку ймовірності майбутніх землетрусів за 
допомогою історичної інформації, моделей сейсмічності та наукових алгоритмів. 
Прогнози не дають нам конкретних дат, але можуть попередити про ризики. 
19 
ЧДТУ 252161.013ПЗ 
 
Карта ризиків - карта, що ілюструє розподіл ризику по території з різними 
ступенями небезпеки. Такі карти показують, де потужні землетруси більш 
вірогідні, і використовуються для планування безпеки. 
Сейсмограф - це прилад для виявлення та вимірювання треморів у земній 
корі. Він дозволяє дізнатися, коли, де, на якій глибині та наскільки сильним був 
землетрус. Дані сейсмографів є джерелом записів про землетруси. 
Сейсмічна активність відображає кількість і силу землетрусів у певній 
місцевості. Висока активність є ознакою високої ймовірності треморів у 
майбутньому. Дослідження активності сприяють кращому прогнозуванню. 
2.1.2 Елементи моделювання предметної області 
 
 
 
 
Рисунок 2.1 - Основні графічні символи UML 
20 
ЧДТУ 252161.013ПЗ 
 
Для додатку "Відстеження землетрусів" для iOS проводиться моделювання 
UML із використанням загальноприйнятих компонентів: класи (користувачі, 
землетруси, прогнози), атрибути (дата, магнітуда, координати), методи (обробка 
даних, видача прогнозу), асоціації (зв'язки між класами) і об'єкти (екземпляри 
класів). 
Ключові діаграми включають: діаграми класів, для зображення структури 
системи; діаграми варіантів використання, для опису взаємодій; діаграми 
послідовності, для показу послідовних кроків і назв відповідальності; діаграми 
діяльності, для показу потоку даних як функції системи. Основні графічні 
символи UML представлені на рисунку 2.1 
 
 
 
Рисунок 2.2 - Єднальні елементи UML 
 
Використання UML сприяє об'єднаному способу візуалізації проектування 
системи та повному кресленню усіх програмних модулів та їх взаємозв'язків. 
21 
ЧДТУ 252161.013ПЗ 
 
Такий вид візуального моделювання значно покращує ефективність комунікації 
між розробниками, аналітиками та зацікавленими сторонами проекту, а також 
забезпечує спільну мову для обговорення архітектурних рішень та 
функціональних можливостей. Це особливо важливо при створенні мобільних 
додатків, що використовують API та підключаються до інших сервісів. Єднальні 
елементи UML представлені на рисунку 2.2. 
2.1.3 Робоча область моделювання 
Робоча область моделювання додатка iOS “Quake Alert” включає всі 
необхідні частини системи для проектування та реалізації. Він включає 
автоматизацію: збір даних із зовнішніх джерел, аналітику, прогнозування та 
презентацію [18]. 
 
 
Рисунок 2.3 – Модель предметної області для моніторингу минулих та 
прогнозування майбутніх землетрусів 
22 
ЧДТУ 252161.013ПЗ 
 
 
Основні компоненти: 
–    користувачі (отримують інформацію, переглядають прогнози); 
–    дані про землетруси; 
–    мапа (інтерактивний дисплей з можливістю фільтрації); 
–   система з обробленими даними (алгоритми прогнозування та розрахунки 
ризиків); 
–   використання API (отримання даних з USGS/EMSC для додавання точок 
даних, реальні оновлення); 
–  локальна база даних (зберігання інформації для офлайн-використання, 
миттєвий доступ). 
Мета робочої області: забезпечити ефективну комунікацію модулів, обробку 
даних та розробити зручний інтерфейс користувача.  Модель предметної області 
представлені на рисунку 2.3. 
2.2 Формування та аналіз вимог 
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні 
вимоги. 
Формування вимог до програмного забезпечення. Формування вимог для 
впровадження додатка “Програмне забезпечення для мобільного додатка для 
моніторингу минулих та прогнозування майбутніх землетрусів.” включатиме збір 
інформації, аналіз та документацію потреб користувача і технічних вимог. Цей 
процес визначає основні функції системи: збір інформації про сейсмічні події, 
їхнє представлення на карті та прогнозування землетрусів. Добре сформульовані 
вимоги сприятимуть тому, що кінцевий продукт буде відповідати потребам 
користувача, а процес розробки буде оптимізований [9]. 
Первинні та детальні вимоги. 
Первинні вимоги тут представляють загальні функціональні можливості, 
якими мобільний додаток повинен володіти для успішного спостереження та 
прогнозування землетрусів: 
23 
ЧДТУ 252161.013ПЗ 
 
–  створення програми для iOS з метою прогнозування та моніторингу 
землетрусів; 
–   доступ до інформації про минулі землетруси без обов'язкового входу до 
системи; 
–    предбачити реєстрацію та збереження їх особистих даних; 
– додаток повинен містити інформацію про останні землетруси з 
автентичних джерел; 
–  застосунок повинен забезпечити геологічний досвід з використанням карт, 
які відображають сейсмічні події по всьому світу, їхню інтенсивність, природу та 
інші характеристики; 
–   інтерфейс додатка також потребуватиме можливості прогнозувати, коли 
ймовірні землетруси можуть статися в майбутньому, в областях, обраних 
користувачем, на основі минулої історії; 
–   система повинна дозволити фільтрувати дані про землетруси за такими 
параметрами, як магнітуда, регіон, дата або глибина. 
Детальні вимоги описують функціональні та інтерфейсні деталі, а також 
деталі даних та інші характеристики системи. Тут вони далі конкретизують 
загальні вимоги та слугують основою для технічної документації та реалізації 
мобільного додатку для моніторингу землетрусів. 
1    Відображення даних про землетруси: 
–    реалізувати зручний пошук локацій землетрусів; 
– ПЗ повинно містити прогноз ймовірності винекнення нових 
землетрусів; 
–  додаток повинен отримувати та відображати дані з офіційних джерел, 
таких як USGS та EMSC через REST API; 
–  для кожного землетрусу слід відображати дату, час, магнітуду, глибину, 
координати та локацію (назву найближчого населеного пункту); 
–  історична інформація повинна зберігатися в локальній базі даних для 
забезпечення офлайн-доступу. 
2    Візуалізація на інтерактивній карті: 
24 
ЧДТУ 252161.013ПЗ 
 
– карта повинна відображати землетруси у вигляді маркерів із 
кольоровим кодуванням за магнітудою; 
– користувач повинен мати можливість наближати, віддаляти та 
переміщати карту; 
– при натисканні на маркер має відображатися спливаюче вікно з 
основною інформацією про подію; 
– кластеризація маркерів має застосовуватись для оптимізації 
відображення при великій кількості подій. 
3    Система прогнозування: 
–  алгоритми машинного навчання повинні аналізувати історичні дані 
для визначення ймовірності майбутніх землетрусів; 
–  користувач повинен мати можливість обрати конкретний регіон для 
отримання прогнозу; 
– результати прогнозування мають відображатися у вигляді карти 
ризиків та числових значень ймовірностей. 
4    Фільтрація та пошук даних: 
–   інтерфейс повинен включати фільтри за магнітудою; 
–   система повинна забезпечувати фільтрацію за часовим періодом ; 
–  користувач повинен мати можливість обирати конкретні регіони або 
радіус пошуку від вказаної точки; 
–   результати фільтрації мають оновлюватися в режимі реального часу. 
5    Персоналізовані налаштування та сповіщення: 
–  користувач повинен мати можливість створювати обліковий запис для 
збереження персональних налаштувань. 
Вимоги замовника і розробника 
Вимоги замовника Визначаються кінцевими користувачами системи і 
включають як функціональні, так і нефункціональні аспекти, які є важливими для 
задоволення їх очікувань. Такі вимоги виражаються через коментарі до сервісу, 
який повинен бути реалізований: 
25 
ЧДТУ 252161.013ПЗ 
 
–   мобільний додаток повинен швидко відображати інформацію про поточні 
землетруси без значних затримок, щоб користувачі могли бути в курсі оновлень; 
–   система повинна надавати надійні і науково обґрунтовані прогнози про 
ймовірність майбутніх землетрусів, використовуючи історичні дані; 
–   інтерфейс повинен бути зручним для користування з швидким доступом 
до його основних функцій (карта, список, прогнози та налаштування); 
–   повинен працювати офлайн з кешованими даними для ситуацій з низькою 
якістю інтернету; 
– система повинна захищати приватність користувача, а також його 
місцезнаходження і персональні дані. 
Вимоги розробника визначаються командою розробників і стосується 
технічних аспектів системи, таких як архітектура, технології, стандарти та інші 
внутрішні критерії цілісності. Ці потреби допомагають досягти результату, 
реалістичного з огляду на технічні можливості і перешкоди: 
–   мобільний додаток повинен бути розроблений сучасними технологіями; 
–   використоувати фреймворку SwiftUI для створення сучасного інтерфейсу; 
–   для отримання даних необхідно реалізувати інтеграцію з відкритими API; 
–   додаток буде зберігати дані про землетруси та налаштування користувача 
локально з використанням Core Data або SQLite; 
–   алгоритм прогнозування землетрусів побудований на моделях машинного 
навчання з бібліотекою Core ML; 
–   концепція додатку має бути масштабованою та базуватися на синтаксисі 
MVVM для спрощення обслуговування та можливості розширення функцій. 
Функіціональні вимоги 
1    Реєстрація та авторизація: 
–   реєстрація користувача, збереження особистої інформації; 
–   авторизація: можливість вхожу в систему для входу. 
2    Перегляд землетрусів: 
–  пошук та фільтрація землетрусів, можливість швидкого пошуку за 
категоріями, характеристиками, тощо; 
26 
ЧДТУ 252161.013ПЗ 
 
– детальна інформація про землетрус, відображення, фото, опису 
характеристик. 
Нефункціональні вимоги 
3    Безпека 
–  захист особистих даних користувача: забезпечення конфиденціїної 
інформації. 
4     Продуктивнсіть та швидкодія 
–  оптимізувати швидкість завантаженн, швидку реакцію системи на 
операції користувача; 
– масштабованість: врахувати, наскільки добре система може 
масштабуватися, коли більше користувачів починають використовувати систему. 
5    Інтерфейс 
–    легкість у використанні: простий інтерфейс для користувача додатку; 
–    відповідність: добре працює незалежно від пристрою. 
2.2.2 Формування вимог за допомогою діаграми прецедентів 
Діаграма прецедентів (рисунок 2.4) показує, як користувачі будуть 
взаємодіяти з додатком iOS для відстеження землетрусів з точки зору задіяних 
функціональностей. 
 
 
Рисунок 2.4 - Діаграма прецедентів для мобільного додатку для моніторингу 
минулих та прогнозування майбутніх землетрусів 
 
27 
ЧДТУ 252161.013ПЗ 
 
Основні прецеденти: 
1    Перегляд даних про землетруси 
–   Актор: Користувач 
– Опис: Перегляд минулих подій (дата, час, глибина, магнітуда, 
координати) з можливістю фільтрувати за кількома параметрами. 
2    Перегляд прогнозів 
–    Актор: Користувач 
–  Опис: Отримання прогнозу ймовірності землетрусів у конкретному 
регіоні з аналізом ризиків 
3    Візуалізація даних на карті 
–    Актор: Користувач 
–   Опис: Перегляд інформації на інтерактивній карті з масштабуванням, 
накладенням зон ризику та фільтрацією. 
4    Імпорт даних із зовнішніх джерел 
–    Актор: Система 
–   Опис: Автоматичне завантаження даних з USGS, обробка даних та їх 
зберігання. 
Діаграма прецедентів надає огляд функціональності системи і також 
полегшує ефективне планування розробки системи, щоб відповідати вимогам 
користувача. 
2.3 Проектування логічної структури програмного комплексу 
В цьому підрозділі описано створення логічної архітектури додатка для 
пристроїв iOS для моніторингу землетрусів і прогнозування нових. Це передбачає 
розробку діаграм класів для опису, як класи взаємодіють, та діаграму пакетів для 
організації логіки додатка в модулі (пакети). 
2.3.1 Діаграми класів 
Діаграма класів додатка для iOS для землетрусів, що ілюструє структуру 
системи, основні класи та зв'язки між ними (рисунок 2.5). 
Основні класи: 
28 
ЧДТУ 252161.013ПЗ 
 
1    Користувач (User) 
–   Атрибути: userID, name, email, preferences 
–   Методи: register(), viewEarthquakeData(), receiveNotifications() 
2    Землетрус (Earthquake) 
–   Атрибути: eventID, date, magnitude, depth, location 
–   Методи: fetchEarthquakeData(), processEarthquakeData() 
3    Прогноз (Prediction) 
–   Атрибути: predictionID, region, probability 
–   Методи: generatePrediction(), updatePredictionModel() 
4    Карта (Map) 
–   Атрибути: mapID, layers, filters 
–   Методи: renderMap(), updateMapView() 
 
 
Рисунок 2.5 - Діаграма класів без атрибутів та методів для додатку для 
відстеження минулих та прогнозування ймовірності майбутніх землетрусів 
 
Ключові зв'язки: 
–    користувач переглядає дані про землетруси; 
–    користувач отримує інформацію про прогнози; 
–    користувач взаємодіє з картою; 
–    дані про землетруси використовуються для формування прогнозів; 
29 
ЧДТУ 252161.013ПЗ 
 
–    прогнозні зони відображаються на карті. 
Структура дозволяє легко аналізувати взаємодію з компонентами системи і 
допомагає головній функції додатка. Повна діаграма класів зображена на рисунку 
2.6 
 
 
Рисунок 2.6 - Діаграма класів для додатку для відстеження минулих та 
прогнозування ймовірності майбутніх землетрусів 
30 
ЧДТУ 252161.013ПЗ 
 
2.3.2 Діаграма пакетів 
Діаграма пакетів (рисунок 2.7) відображає структуру високого рівня 
iOS-додатку моніторингу землетрусів, демонструючи логічне групування 
компонентів системи.  
Основні пакети включають: 
1    UI Layer - шар інтерфейсу користувача, що містить екрани; 
2    Core Logic - шар бізнес-логіки з моделями даних та контролерами; 
3    Data Layer - шар доступу до даних, що включає сервіси даних; 
4    Database Layer - шар зберігання даних з локальною базою даних; 
5   External Services - зовнішні сервіси, включаючи інтеграцію з API USGS 
та сервіси геолокації. 
 
 
Рисунок 2.7 - Діаграма пакетів для мобільного додатку для моніторингу 
минулих та прогнозування майбутніх землетрусів 
 
Архітектура чітко показує багатошарову структуру, в якій кожен шар має 
чітко визначені ролі і спирається на нижні. Такий спосіб розробки забезпечує 
модульність, підтримку і масштабованість системи. Однак, зовнішні сервіси 
31 
ЧДТУ 252161.013ПЗ 
 
показані як незалежна сутність, що комунікує з шаром даних, полегшуючи 
можливість заміни або додавання нового джерела даних. 
2.4 Архітектура проектування 
У цьому підрозділі буде розглянуто архітектуру iOS-додатку для 
відстеження минулих землетрусів і прогнозування ймовірності нових. Ми 
покажемо діаграму компонентів, яка ілюструє, як різні програмні модулі додатка 
взаємодіють один з одним, їхні інтерфейси та методи комунікації. Також буде 
показана діаграма розгортання, щоб продемонструвати, як програмні компоненти 
розподілені по апаратних вузлах, включаючи мобільні пристрої, сервери та бази 
даних. 
2.4.1 Діаграма компонентів 
Діаграма компонентів (рисунок 2.8) демонструє логічну структуру 
програмного забезпечення, описуючи основні модулі додатку та їхню взаємодію. 
 
 
Рисунок 2.8 - Діаграма компонентів мобільного додатку для моніторингу 
минулих та прогнозування майбутніх землетрусів 
32 
ЧДТУ 252161.013ПЗ 
 
Основні компоненти 
1    UI Layer (Інтерфейс користувача) 
–    MapView - візуалізація даних на карті 
–    UserSettings - налаштування користувача (регіони, сповіщення) 
2    Data Layer (Шар даних) 
–    EarthquakeData - модуль для роботи з історичними даними 
–    PredictionData - модуль для зберігання прогнозів 
–    APIManager - інтеграція із зовнішніми джерелами (USGS, EMSC) 
3    Core Logic (Основна логіка) 
–    PredictionEngine - генерація прогнозів 
–    DataProcessor - обробка даних з API 
4    Database (База даних) 
–    Локальне зберігання історичних даних і прогнозів 
–    APIManager отримує дані із зовнішніх джерел 
–   PredictionEngine використовує дані з EarthquakeData для формування 
прогнозів 
–  UI Layer отримує оброблені дані з Core Logic для відображення 
користувачу 
Діаграма компонентів демонструє логічну структуру програмного 
забезпечення мобільного додатку для відстеження та прогнозування землетрусів, 
описуючи основні модулі системи та їхню взаємодію. Це надає розробникам чітке 
розуміння організації компонентів, їх взаємозв'язків та комунікаційних 
інтерфейсів, що сприяє ефективному плануванню, розробці та подальшій 
підтримці програмного продукту. 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання 
Розгортання програмної системи на апаратних засобах (зображена на 
рисунку 2.9) вимагає розподілу та налаштування всіх компонентів мобільного 
додатка моніторингу минулих та прогнозування майбутніх землетрусів на 
відповідному обладнанні для клієнтських елементів iOS-додатка, які 
33 
ЧДТУ 252161.013ПЗ 
 
розгортаються на мобільному пристрої кінцевого користувача, щоб забезпечити 
інтерактивність з серверною геологічною службою API, а також хмарними 
сервісами для синхронізації даних між пристроями. 
 
 
Рисунок 2.9 - Діаграма розгортання мобільного додатку для моніторингу 
минулих та прогнозування майбутніх землетрусів 
 
Основні вузли 
1    Мобільний пристрій: 
–   iOS-додаток. 
2    Сервер API: 
–   Хостинг сторонніх API (USGS, EMSC) 
–   Надання даних про землетруси в реальному часі 
3    Сховище даних (Cloud Storage): 
–   Резервне зберігання даних 
–   Синхронізація між пристроями 
Архітектура, реалізована в додатку, наголошує на модульності, ефективності 
та масштабованості під час розробки, тестування та розширення системи шляхом 
впровадження гнучкого підходу. 
34 
ЧДТУ 252161.013ПЗ 
 
2.5 Моделювання поведінки системи 
Цей розділ описує динамічну роботу додатка iOS для моніторингу 
землетрусів і оцінки ймовірності майбутніх сейсмічних подій. Динамічне 
моделювання допомагає отримати уявлення про поведінку системи з часом, 
послідовність операцій і взаємодію між компонентами під час виконання системи 
в різних сценаріях використання [4]. 
Деякі діаграми UML застосовуються для пояснення поведінки системи в 
цілому, тоді як інші призначені для опису конкретного вигляду роботи додатку. 
Графіки послідовностей зображають часове логування об’єктів і передачу 
інформації, яка формується через них, оскільки вони виконують певні процедури. 
Блок-схеми активностей зображають робочий процес системи в логіці прийняття 
рішень і формі паралельної обробки. Діаграми станів представляють стан системи 
або компонента системи та переходи між її станами. 
Моделювання не лише статичних аспектів, але й динамічних дій є 
надзвичайно важливим для розуміння того, як система поводиться у різних 
сценаріях використання (наприклад, щоб отримати звіти про землетруси, робити 
прогнози, отримувати доступ до карти, обирати сповіщення). Це дозволяє виявити 
потенційні помилки у логіці застосунку на стадії проектування і коректно 
реалізувати функціональні вимоги. 
Ілюстрації у цьому розділі демонструють основне використання системи та 
показують, як різні частини взаємодіють, щоб надати функціональність, що 
вимагається додатком у реальному середовищі роботи [12]. 
2.5.1 Діаграма діяльності 
Діаграма діяльності (рисунок 2.10) зображає спосіб виконання основних 
функцій у системі. Вона показує, як здійснюються процеси (наприклад, коли ви 
переглядаєте дані про землетруси). 
Основні етапи 
1    Користувач запускає додаток. 
2    Система кешує і завантажує локальні дані про землетруси. 
3    Якщо даних немає, вона викликає API, щоб отримати актуальні дані. 
35 
ЧДТУ 252161.013ПЗ 
 
4 Історичні або прогнозовані зони можуть бути показані на карті 
користувачу. 
5   Додаток відправляє запит на отримання прогнозів. 
6   Система генерує прогноз. 
 
 
Рисунок 2.10 – Діаграма діяльності мобільного додатку для моніторингу 
минулих та прогнозування майбутніх землетрусів 
36 
ЧДТУ 252161.013ПЗ 
 
2.5.2 Діаграма послідовності 
Діаграма послідовності (рисунок 2.11) демонструє, як класи та компоненти 
взаємодіють для виконання конкретної операції [16]. 
 
 
Рисунок 2.11 - Діаграма послідовності мобільного додатку для моніторингу 
минулих та прогнозування майбутніх землетрусів 
 
Приклад сценарію 
1    Користувач відкриває додаток. 
2    UI Service запитує дані з Earthquake Data Service. 
3    Earthquake Data Service перевіряє кеш у Database Service. 
4    Якщо даних немає, API Service звертається до зовнішнього API. 
5    Дані повертаються в UI Service для відображення користувачеві. 
6    UI Service запитує прогноз у Prediction Service. 
7    Prediction Service повертає прогноз. 
37 
ЧДТУ 252161.013ПЗ 
 
2.5.3 Діаграма комунікації 
Діаграма комунікації (рисунок 2.12) демонструє взаємодію між об’єктами 
в системі з акцентом на структурні зв’язки. У додатку для вивчення землетрусів 
діаграма ілюструє взаємодію між компонентами: 
– актор (користувач) взаємодіє з Сервісом інтерфейсу користувача, 
центральним компонентом для комунікації; 
–    UI Service звертається до Earthquake Data Service; 
–   Earthquake Data Service взаємодіє з API Service для отримання даних із 
зовнішніх джерел; 
–     API Service повертає отримані дані назад до Earthquake Data Service; 
–     UI Service також передає дані до Prediction Service для прогнозування; 
–     Prediction Service повертає результати прогнозування до UI Service; 
 
 
Рисунок 2.12 - Діаграма комунікації мобільного додатку для моніторингу 
минулих та прогнозування майбутніх землетрусів 
38 
ЧДТУ 252161.013ПЗ 
 
Діаграма комунікації для сценарію моніторингу землетрусів візуалізує 
взаємодію між різними компонентами системи. Вона показує, як Сервіс 
інтерфейсу користувача (КОРИСТУВАЧ) здійснює комунікацію між різними 
сервісами: Сервісом даних про землетруси, API-сервісом та Сервісом 
прогнозування. 
2.5.4 Діаграма скінченного автомату 
Діаграма скінченного автомату (рисунок 2.13 - 2.14) відображає ключові 
стани системи та переходи між ними. Ця діаграма описує перебіг мобільного 
додатку для відстеження землетрусів від запуску до завершення роботи [11]. 
 
 
Рисунок 2.13 - Діаграма скінченного автомату мобільного додатку для 
моніторингу минулих та прогнозування майбутніх землетрусів ч.1  
39 
ЧДТУ 252161.013ПЗ 
 
 
Рисунок 2.14 - Діаграма скінченного автомату мобільного додатку для 
моніторингу минулих та прогнозування майбутніх землетрусів ч.2 
 
Основні стани системи включають: 
Ініціалізація: 
–    початковий стан додатку, коли він завантажується; 
–   виконується налаштування базових компонентів. 
Готовність до роботи: 
–    основний стан додатку після завантаження; 
–    містить кілька вкладених станів для різних функцій системи. 
Вкладені стани готовності до роботи 
ГоловнеМеню: 
–    основний інтерфейс, що бачить користувач при запуску додатку; 
–   перегляд, де користувач може вибрати один з варіантів: карта, нещодавні 
землетруси, прогноз та налаштування. 
40 
ЧДТУ 252161.013ПЗ 
 
ОтриманняДаних: 
–   стан активного завантаження даних про землетруси; 
–   система звертається до локального сховища або API; 
–  після успішного отримання даних додаток переходить до відображення 
інформації. 
ПереглядКарти: 
–    стан для візуалізації землетрусів на інтерактивній карті; 
–    можливість збільшення або зменшення масштабу карти; 
–    ви можете повернутися до головного меню після перегляду. 
ПереглядСписку: 
–    стан для відображення списку землетрусів; 
–    користувач може фільтрувати і сортувати всі дані за різними критеріями; 
–    після перегляду користувач повертається до головного меню. 
ГенераціяПрогнозу: 
–    стан для створення прогнозу сейсмічної активності; 
–    ПЗ оцінює історичні дані та використовує модель машинного навчання; 
–    після аналізу результати надаються користувачеві. 
Налаштування: 
–    стан для конфігурації параметрів додатку; 
–    можливість користувачів налаштовувати параметри; 
–    після збереження налаштувань користувач повертається. 
Вимкнення: 
–    завершальний стан при закритті додатку; 
–    налаштування зберігаються, а дані кешуються. 
Діаграма скінченного автомату для мобільного додатку відстеження 
землетрусів відображає всі можливі стани системи та переходи між ними в 
залежності від дій користувача та системних подій. Вона допомагає зрозуміти, як 
додаток реагує на події та виконує дії зберігання стану протягом свого життєвого 
циклу. 
 
41 
ЧДТУ 252161.013ПЗ 
 
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ 
У Розділі 2 було проведено детальне дослідження розробки додатка iOS для 
моніторингу після землетрусу, а також складено ключові діаграми: 
–   формулювання розділу з вимогами визначило функціональні (наприклад, 
завантаження даних, передбачення, сповіщення) та нефункціональні (наприклад, 
продуктивність, безпека, масштабованість) характеристики системи; 
–   зв'язок між користувачем і системою був очевидним на прикладі діаграми 
випадків використання: перегляд інформації, планування потреби; 
– структура була представлена як класова діаграма (основні класи: 
користувач, дані про землетрус, прогноз, карта) з їх взаємодією; 
–  діаграма пакетів показала логічну організацію застосунку на високому 
рівні, щоб полегшити обслуговування коду; 
–  діаграма компонентів показала фізичну реалізацію системи, включаючи 
модулі взаємодії з API, обробки даних та генерації прогнозів 
–   діаграма розгортання ілюструвала розподіл компонентів між апаратними 
засобами для ефективного планування ресурсів 
Сформовані діаграми слугували для надання загального огляду архітектури, 
функціональності та потоку застосунку, що є незамінним у процесі успішного 
проєктування, розробки та впровадження системи. 
 
 
 
 
 
 
 
 
 
42 
ЧДТУ 252161.013ПЗ 
 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
3.1 Розробка програмного комплексу 
У цьому підрозділі ми пояснимо, як створити мобільний застосунок для 
прогнозування майбутніх землетрусів за допомогою SwiftUI. Ми обговоримо 
вибір технологій, реалізацію функцій та "клей", що зв'язує все це разом, щоб ми 
всі могли легко слідувати кожній частині проєкту. 
3.1.1 Обґрунтування вибору засобів реалізації 
Коли йдеться про вибір технологій для застосунку прогнозування 
землетрусів, ми розглядаємо стабільність, продуктивність і підтримку спільноти: 
–  Swift надає єдиний код для розробки додатків для обох пристроїв із 
високопродуктивним компілятором LLVM для оптимізованої продуктивності, 
швидке виконання мов, підвищена безпека, покращена продуктивність і багато 
іншого, щоб викликати захоплення; 
– SwiftUI має декларативну парадигму, він використовує реактивну 
властивість @State; 
–   Firebase Firestore пропонує хмарне зберігання даних, масштабованість та 
синхронізацію пристроїв прямо з коробки; 
–   моделі машинного навчання тепер можуть виконуватися на пристрої для 
здійснення прогнозів через Core ML; 
–  API USGS забезпечує доступ до глобальних даних про землетруси в 
реальному часі; 
–   MapKit - це метапакет, призначений виключно для відображення карти з 
маркерами землетрусів, анімації, візуалізації додаткових параметрів (глибина, 
магнітуда, зони ризику). 
43 
ЧДТУ 252161.013ПЗ 
 
Цей пакет технологій (рисунок 3.1) забезпечує ефективну обробку 
інформації, своєчасний зворотний зв'язок і зручний інтерфейс моніторингу для 
гарантованої системи спостереження за сейсмічною активністю [13]. 
 
Рисунок 3.1 - Загальна схема використаних технологій 
 
3.1.2 Опис структурної (функціональної) схеми 
Структурна схема (рисунок 3.2) ідентифікує компоненти, з яких складається 
застосунок для прогнозування землетрусів, та спосіб їх використання. 
Структурна схема описує організацію мобільного застосунку моніторингу 
землетрусів за його основними компонентами та рівнями логічної взаємодії: 
Рівень інтерфейсу користувача: 
–  екрани та Views забезпечують візуальне представлення інформації для 
користувача; 
– контролери огляду відповідають за надання логіки відображення та 
управління взаємодією з користувачами; 
44 
ЧДТУ 252161.013ПЗ 
 
– елементи навігації допомагають здійснювати перехід між різними 
екранами програми; 
–   компоненти інтерфейсу користувача - це основні елементи для взаємодії з 
користувачем у застосунку. 
Рівень бізнес-логіки: 
–    служба користувачів відповідає за облікові записи та налаштування; 
–   завдяки службі фільтрації ви можете шукати і відбирати дані за певними 
критеріями; 
–    служба землетрусів збирає та керує даними про сейсмічні події; 
–    служба прогнозування обробляє історичні даніі; 
– визначення місцезнаходження користувача забезпечується службою 
геолокації. 
Рівень даних: 
–   репозиторії забезпечують абстрактний доступ до даних; 
–  персистентність реалізована через Core Data, User Defaults, Cloud Kit та 
локальний кеш; 
–   мережевий рівень включає API клієнт з підключенням до USGS. 
Рівень машинного навчання: 
–  моделі машинного навчання аналізують історичні дані, щоб виявити 
закономірності в даних; 
–   модуль прогнозування робить прогнози, використовуючи одну або іншу 
модель. 
Структурна схема (рисунок 3.2) ілюструє багаторівневу структуру додатку, 
дотримуючись принципу «відповідальності», що дозволяє кожній частині мати 
настановлену роль, забезпечуючи модульність, масштабованість і низьку 
складність обслуговування. 
45 
ЧДТУ 252161.013ПЗ 
 
 
Рисунок 3.2 - Структурна схема додатка для відстеження минулих та 
прогнозування ймовірності майбутніх землетрусів  
 
Функціональна схема є графічним показником потоків даних і основних 
операцій обробки інформації, вбудованих в систему моніторингу землетрусів: 
Вхідні дані: 
–  дані із сейсмологічних API (USGS) надають актуальну інформацію про 
землетруси; 
–   дані про місцезнаходження користувача отримуються через GPS; 
– користувацький ввід визначає параметри пошуку та відображення 
інформації. 
Процеси обробки: 
–    імпорт даних витягує та передобробляє дані з різних джерел. 
–  обробка даних організовує та форматує інформацію для її подальшого 
використання. 
46 
ЧДТУ 252161.013ПЗ 
 
–    фільтрація даних відбирає дані на основі заданих критеріїв. 
–    географічний фокус підтримується вибором розташування. 
–   обчислення прогнозу використовує історичні дані та модель машинного 
навчання для прогнозування. 
Вихідні дані: 
–    відображення на карті візуалізує географічне розташування землетрусів; 
–    відображення у списку надає хронологічний огляд сейсмічних подій; 
–    відображення прогнозу показує ймовірності майбутніх землетрусів; 
–   локальне зберігання дозволяє вам отримувати доступ до інформації під 
час перебування офлайн. 
Функціональна схема (рисунок - 3.3) демонструє, як дані надходять від 
джерел до користувача та як вони трансформуються у корисну для користувача 
інформацію через операції імпорту, обробки, аналізу та візуалізації, що 
дозволяють моніторити та прогнозувати сейсмічну активність. 
 
 
Рисунок 3.3 - Функціональна схема додатка 
 
47 
ЧДТУ 252161.013ПЗ 
 
3.1.3 Опис логічної схеми 
Логічна схема (рисунок 3.4) мобільного застосунку для моніторингу та 
прогнозування сейсмічних ситуацій представляє собою відношення пріоритетів та 
логіку взаємодії компонентів під час виконання різних сценаріїв. 
 
 
Рисунок 3.4  – Логічна схема додатка 
48 
ЧДТУ 252161.013ПЗ 
 
Опис основної логічної схеми: 
–    ініціація та авторизація. 
Наступні кроки описують цей етап: 
1  користувач відкриває застосунок: відкриття застосунку запускає процес 
верифікації. Користувач перенаправляється на головну сторінку або на сторінку 
входу в залежності від статусу аутентифікації; 
2    застосунок самостійно ініціалізується з локального сховища або сервера; 
3   на головному екрані розміщені різні функціональні модулі, зокрема карта 
землетрусів, список землетрусів, прогнозування та налаштування. Кожен модуль 
містить власну обробку даних і взаємодію з користувачем; 
4 якщо інформація застаріла, запит пересилається на сервер через 
API-клієнт; 
5   оброблені дані зчитуються і відображаються; 
6  користувач обирає прогнозування для певного регіону або використовує 
поточне місцезнаходження. Система перевіряє, чи є доступні потрібні історичні 
дані, і якщо їх немає, завантажує їх; 
7   дані передаються через модель машинного навчання; 
8   згенерований прогноз представляється користувачеві у вигляді карти. 
Управління налаштуваннями: 
– воно підтримує конфігурацію параметрів застосунку, особистих 
налаштувань та параметрів відображення даних; 
–  будь-які зміни зберігаються і застосовуються до відповідних частин 
системи. 
Ключові моменти в логічній схемі: 
–  інтерактивна природа - користувач може безперешкодно переходити з 
одного екрану застосунку на інший; 
–   умовна логіка обробки даних - система приймає рішення в залежності від 
стану даних та дій користувачів; 
–  паралелізм - деякі завдання (такі, як завантаження та обробка даних) 
можуть виконуватись паралельно; 
49 
ЧДТУ 252161.013ПЗ 
 
–   локальний кеш - локальне сховище для роботи в офлайн-режимі повертає 
дані локально для підтримки роботи в автономному режимі; 
–   взаємодія з іншими системами - вона взаємодіє з API сейсмологічних та 
геолокаційних систем. 
Логічна схема забезпечує просте графічне уявлення послідовності 
активностей і процедур прийняття рішень всередині додатка, що полегшує 
відображення логіки системи додатка та взаємодії його компонентів. Це розгляд 
стає ще більш релевантним для реалізації, тестування, а отже, і подальшого 
обслуговування додатка [14]. 
3.1.4 Розробка бази даних 
Конструкція системи зберігання даних є важливою частиною створення 
мобільного додатка для моніторингу землетрусів, яка гарантує зберігання, 
організацію та управління всіма необхідними даними. Для цього проєкту ми 
вирішили використовувати поєднання Core Data для локального зберігання та 
Firebase для синхронізації налаштувань користувача між пристроями, щоб зробити 
їх доступними офлайн. 
1    Аналіз вимог: 
–   визначити перелік головних елементів, які потрібно зберігати; 
–   виявлення асоціацій між об'єктами. 
2    Проектування структури даних: 
–   як створення моделей для кожного типу даних, визначення атрибутів 
та їх типів; 
–  визначення необхідних індексів для оптимізації запитів (наприклад, 
індекси на полях координат для швидкого пошуку землетрусів у заданому регіоні). 
3    Інтерпретація даних і зберігання: 
–  налаштування Core Data для локального зберігання та Firebase для 
обробки даних користувачів; 
–    створення моделей і міграцій для кращої сумісності між версіями; 
–    написання функцій взаємодії з даним. 
4    Тестування та оптимізація: 
50 
ЧДТУ 252161.013ПЗ 
 
– перевірка роботи запитів для забезпечення їх коректності та 
продуктивності; 
– оптимізація структури даних та методів збереження на основі 
результатів тестування. 
Система зберігання даних мобільного додатка прогнозування землетрусів, 
яку ми розробляємо, залучає кілька основних моделей. Нижче наведено еволюцію 
кожної моделі, що використовуються для зберігання різних типів даних: 
Модель Earthquake (Землетрус) 
Процес розробки: 
1    Аналіз вимог: 
–    основні атрибути для зберігання даних про землетруси; 
– вивчення необхідності додавання нових полів для зберігання 
додаткової інформації. 
2    Проектування моделі: 
–   створення параметрів, встановлення типів даних параметрів; 
– введення унікального ID для швидкого пошуку та уникнення 
дублікатів; 
–   додавання заголовка для хорошої підтримки фільтрації та сортування. 
Модель UserPreferences (Налаштування користувача) 
Процес розробки: 
1    Аналіз вимог: 
–  характеристики для зберігання налаштувань користувача, мінімальної 
відповідної величини (для відображення), часового проміжку, вибраних регіонів). 
2    Проектування моделі: 
–   створення атрибутів налаштувань, встановлення їх типу даних; 
–   надання можливості синхронізації з Firebase. 
Модель Region (Регіон) 
Процес розробки: 
1   Аналіз вимог: 
51 
ЧДТУ 252161.013ПЗ 
 
– визначення необхідних атрибутів для зберігання інформації про 
географічні регіони (назва, координати центру, радіус). 
2   Проектування моделі: 
–  створення функцій для рішень через параметри та вказуючи їх тип 
даних; 
–   встановлення зв'язку з моделлю UserPreferences. 
Модель Prediction (Прогноз) 
Процес розробки: 
1    Аналіз вимог: 
– прогнози сейсмічної активності (зона, ймовірність виникнення та 
часова рамка). 
2    Проектування моделі: 
–   створення атрибутів для кожного параметру; 
– забезпечення зв'язку з моделлю Region для асоціації прогнозів з 
конкретними регіонами. 
Вибрані моделі є універсальними та ефективними для управління даними, 
які будуть зберігатися та оброблятися, як це потрібно для функціонування 
системи. 
Core Data, як фреймворк для управління об'єктно-реляційними моделями, 
сприяє ефективному управлінню даними в режимі офлайн, що є критично 
важливим у випадку додатку моніторингу землетрусів [7]. 
3.1.5 Розробка інтерфейсу користувача 
Якість та регулятивна зручність інтерфейсу визначають найбільш 
ефективну взаємодію між користувачами та системою. Дизайн користувацького 
інтерфейсу - це комплексний процес, який дотримується для проектування 
інтерфейсу програмного забезпечення та використовує багато важливих практик 
проектування, таких як аналіз вимог, проектування основних модулів, 
тестування та оптимізація [6]. 
Вимоги до користувацького інтерфейсу: 
52 
ЧДТУ 252161.013ПЗ 
 
–  зручність у використанні: користувач має інтуїтивно розуміти, як 
використовувати інтерфейс, незалежно від їх типу, і доступ до основних 
функцій має бути швидким; 
–   доступність: інтерфейс має бути гнучким для користувачів з різними 
можливостями, темний режим, зміна масштабу тексту та VoiceOver; 
– функціональність: Додаток дозволяє отримати доступ до всіх 
відповідних функцій, таких як прогнози землетрусів, історичні дані та особисті 
налаштування. 
Екран входу це перший контактний пункт для користувачів. Він містить 
місця для введення авторизації та для опцій, які є гостями або реєстрації нового 
облікового запису  (рисунок 3.5). 
 
 
Рисунок 3.5 – Екран входу в мобільний додаток 
 
Екран входу складається з полів для електронної пошти та пароля, кнопки 
«Увійти» для входу до системи, кнопки «Продовжити як гість» для входу без 
реєстрації, посилання «Забули пароль?» для відновлення пароля та посилання для 
реєстрації нового облікового запису. 
Є три поля для введення електронної пошти, пароля та поле «введіть пароль 
повторно» для повторного введення пароля, кнопка «Зареєструватися» для 
53 
ЧДТУ 252161.013ПЗ 
 
завершення реєстрації та кнопка «Скасувати» для скасування і повернення до 
екрану входу. 
Форма відновлення паролю надає можливість користувачам скинути забутий 
пароль (рисунок 3.6). 
 
 
Рисунок 3.6 – Форма відновлення паролю в мобільному додатку 
 
Форма відновлення пароля складається з інформаційного тексту з 
інструкціями, поля для електронної пошти та кнопки «Надіслати посилання для 
скидання», яка надсилає посилання для відновлення пароля на дану електронну 
адресу. 
Знаходиться у вступному потоці програми для допомоги користувачам 
ознайомитися з основними функціями та можливостями додатку QuakeAlert. 
(рисунок 3.7). 
Включає символ у формі земної кулі, назву додатку «Ласкаво просимо до 
QuakeAlert», його однорядкову мету, індикатор прогресу інтро, а також навігацію 
по інтро з кнопкою «Далі» для переходу до наступного екрану. У верхньому 
правому куті є кнопка для закриття потоку інтро. 
Подальші екрани онбордингу виглядають аналогічну до першого. 
Останній екран містить значок галочки, заголовок "Початок роботи", 
повідомлення про завершення налаштування, індикатор прогресу, а також 
54 
ЧДТУ 252161.013ПЗ 
 
кнопку "Початок роботи" для переходу до головного екрану додатку. Вгорі в 
куті знаходиться кнопка для закриття ознайомлення. 
 
 
Рисунок 3.7 – Привітальний екран онбордингу додатку QuakeAlert 
 
Екран списку глобальних землетрусів відображає актуальну інформацію про 
сейсмічну активність у різних регіонах світу (рисунок 3.8). 
Верхня частина екрану містить заголовок "Global Earthquakes", інформацію 
про час останнього оновлення даних, кнопки фільтрації та оновлення. Під 
заголовком розташовані активні фільтри "Mag: 4.5+" та "Last 7d" з кнопкою "Edit" 
для їх редагування. Екран списку землетрусів у світі. Цей екран показує список 
нещодавніх землетрусів по всьому світу (рисунок 3.9). У центрі знаходиться число 
виявлених землетрусів (105). Основний вміст екрана — це список землетрусів, 
кожен з яких має свою магнітуду (кольорові кола та цифри зліва), місце, дату та 
час. Деякі записи мають додаткову інформацію: зелене коло означає, що є ще для 
55 
ЧДТУ 252161.013ПЗ 
 
читання; хвиляста лінія означає, що може бути попередження про цунамі. Записи 
про землетруси впорядковані за тимчасовою послідовністю від нових до старих. 
 
 
Рисунок 3.8 – Екран списку глобальних землетрусів 
 
Він має три вкладки для різних категорій фільтрів (рисунок 3.9). 
Фільтрація подій. На екранах зліва можна запитати скріншот з різним 
рівнем деталізації. Верхня частина екрана містить наступне: заголовок 
"Фільтри землетрусів", кнопку скасування для скасування змін та меню 
навігації з трьома вкладками: "Основні", "Місце розташування" та 
"Розширені". 
У основних фільтрах є "Мінімальна магнітуда" (повзунок 
встановлений на 4.5) та "Період часу" (повзунок встановлений на 7 днів) як 
основні фільтри. Обидва параметри описані з допомогою пояснювальних 
56 
ЧДТУ 252161.013ПЗ 
 
текстів. У нижній частині панелі є кнопки для скидання фільтрів та 
застосування вибраних налаштувань. 
 
 
Рисунок 3.9 – Екран базових фільтрів землетрусів 
 
На екрані фільтра місця розташування ви можете обмежити область, в 
якій відображаються землетруси. Вкладка "Місце розташування" містить дві 
опції: "Регіон" зі значенням "Всі регіони" та "Максимальна глибина" з 
перемикачем "Обмежити глибину" (зараз вимкнено). Обидва значення 
мають описи значень. Внизу також є кнопки "Скинути" та "Застосувати". 
Екран картографічного відображення землетрусів надає користувачам 
візуальну інформацію про географічне розташування сейсмічних подій на світовій 
карті (рисунок 3.10). 
57 
ЧДТУ 252161.013ПЗ 
 
 
Рисунок 3.10 – Екран картографічного відображення землетрусів 
 
Верхня частина екрану містить заголовок "Earthquake Map", інформацію про 
час останнього оновлення даних та кнопки фільтрації й оновлення. Під заголовком 
відображаються активні фільтри "Mag: 4.5+" та "Last 7d" з кнопкою "Edit" для їх 
редагування. 
Центром дисплею є інтерактивна карта світу на екрані, на якій землетруси 
позначені різнокольоровими маркерами. Кожен маркер має номер, що відповідає 
магнітуді події. Інтенсивність події закодована в кольорах маркерів: 
помаранчевий, якщо магнітуда становить середній діапазон, червоний — якщо у 
високому діапазоні. Деякі маркери згруповані разом з примітками про кількість 
додаткових подій у цьому регіоні (наприклад, "+2 ще", "+3 ще"). 
Вони показують вам детальну інформацію про конкретний землетрус 
(рисунок 3.11). 
«ДЕТАЛІ ЗЕМЛЕТРУСУ» — це заголовок зверху, а кнопка «Назад» 
розташована у верхньому лівому куті. На карті вказано епіцентр землетрусу, 
позначений помаранчевою позначкою і словами «М 4.7 - 44 км 
58 
ЧДТУ 252161.013ПЗ 
 
південно-південно-схід від Кусіма, Японія». Карту також доповнюють найближчі 
цікаві місця: Фукуока, Осака, Чеджу, Йосу та інші. 
 
 
Рисунок 3.11 – Екран детальної інформації про землетрус 
 
Центральна частина екрану містить блок з основною інформацією про 
землетрус: магнітуда 4.7 (відображена у помаранчевому колі), повна назва події 
"M 4.7 - 44 km SSE of Kushima, Japan" та точна дата і час події "Thursday, 3 April 
2025 at 00:42:51". 
Нижче розміщена таблиця з детальними параметрами події: 
–    Location: 44 km SSE of Kushima, Japan; 
–    Coordinates: Lat: 31.1273, Long: 131.4441; 
–    Depth: 25.73 km. 
Кнопка «Переглянути на сайті USGS» під інформацією перенаправить вас 
на сайт USGS для отримання більш детальної інформації. 
59 
ЧДТУ 252161.013ПЗ 
 
На екрані деталей кластера показана низка землетрусів, що відбулися в тій 
самій області. Слова «Деталі Кластера» та кнопка «Готово» у верхній частині 
екрану для закриття екрану і повернення до попереднього екрану. Під заголовком 
міститься інформаційний блок із повідомленням «4 землетруси в цій області», що 
представляє кількість землетрусів у тому самому кластері. 
Центральна частина екрану заповнена переліком з чотирьох землетрусів, які 
відбулися в регіоні "Центральний Серединно-Атлантичний хребет". Для двох 
найсильніших (6,6 і 6,1) землетрусів відображається зелений індикатор для 
отримання додаткової інформації зі стрілкою для відображення детального 
інформаційного звіту про цю подію: 
– кольоровий індикатор магнітуди (червоний для найсильніших, 
помаранчевий для середніх); 
–     числове значення магнітуди (від 5.2 до 6.6); 
–     назву місця події "central Mid-Atlantic Ridge"; 
–     дату та час події; 
–   зелений індикатор для двох найсильніших землетрусів (6.6 та 6.1), що 
вказує на наявність додаткової інформації; 
–    стрілку для переходу до детальної інформації про конкретну подію. 
Землетруси у списку відображаються у порядку магнітуди: від найбільшого 
(6,6) до найменшого (5,2), щоб допомогти вам побачити загальний масштаб 
сейсмічних подій у цьому регіоні. 
Екран прогнозування землетрусів надає користувачам можливість отримати 
прогноз сейсмічної активності для конкретного регіону (рисунок 3.12). 
Основну частину екрану займає детальна карта регіону Токіо та прилеглих 
територій Японії. На карті відображені назви міст (Tokyo, Yokohama, Chiba, 
Saitama та інші), дорожня мережа, водні об'єкти (Токійська затока) та рельєф 
місцевості. Червоний маркер на карті позначає точку, для якої буде згенеровано 
прогноз землетрусу. У правому верхньому куті карти розміщена кнопка навігації з 
індикатором поточного місцезнаходження. 
60 
ЧДТУ 252161.013ПЗ 
 
 
Рисунок 3.12 – Екран прогнозування землетрусів 
 
Під картою розташоване поле пошуку з текстом "Search for location", що 
дозволяє користувачам знаходити та вибирати конкретні місця для прогнозування. 
Помаранчева кнопка "Згенерувати прогноз землетрусу" внизу екрана 
дозволяє користувачам зробити прогноз землетрусу в певному місці або 
натиснути на карту. 
Користувачі можуть шукати місця для перегляду сейсмічної активності на 
екрані пошуку місць (рисунок 3.13). 
Верхня частина екрана містить поле для введення пошукового запиту, що 
включає текст "Ank", і кнопку "Скасувати", яка скасовує пошук і повертає вас до 
попереднього екрана. 
Усі результати показані в помаранчевому кольорі для назв та сірому для 
адрес (що відповідає схемі кольорів додатка). Кожен результат є активним 
пунктом, і якщо натиснути на нього, можна вибрати відповідне місце, щоб 
проаналізувати там сейсмічність. 
61 
ЧДТУ 252161.013ПЗ 
 
 
Рисунок 3.13 – Екран пошуку місць 
 
Функція пошуку дуже корисна і дозволяє користувачам карти легко 
знаходити бажане місце, не потрібно прокручувати до вибраного місця, особливо 
у випадку з віддаленими або невідомими місцями. 
Панель прогнозування сейсмічної активності надає повну інформацію про 
очікувані землетруси в обраному користувачем місці (рисунок 3.14). 
Заголовок говорить "Поточне місце". Є кнопка "Повернутися до карти", і 
оцінка сейсмічного ризику "Ризик землетрусу: Дуже низький" (на зеленому фоні). 
Логотип машинного навчання надає додаткове свідчення точності прогнозу 
"Довіра МЛ: 100%". 
По центру, "Карта сейсмічних ризиків", пов'язана з "Регіональні рівні ризику 
на основі аналізу МЛ", є інтерактивною картою сейсмічних ризиків регіону. Карта 
Токіо, Йокогами, Тіби та найближчих територій з кольоровими маркерами, що 
вказують рівні ризику: зелений (Дуже низький) є найбільш поширеним відтінком, 
тоді як червоний (Високий) переважає біля гори Фудзі та Сідзуоки. Під картою 
знаходиться легенда, що описує кольори: Дуже низький, Низький, Середній та 
Високий. 
Частота основних землетрусів (магнітуда 5+): 1 за рік Орієнтовна ймовірна 
магнітуда: 4.0-4.9 Максимально можлива магнітуда: 5.0-5.9. 
62 
ЧДТУ 252161.013ПЗ 
 
 
Рисунок 3.14 – Екран прогнозу сейсмічної активності для поточної локації 
 
Нижня частина екрану містить розділ "Prediction Summary" з детальними 
статистичними даними: 
–    річна частота землетрусів: 14 подій на рік; 
–    частота значних землетрусів (магнітуда 5+): 1 подія на рік; 
–    найбільш імовірна магнітуда: 4.0-4.9; 
–    найвища потенційна магнітуда: 5.0-5.9. 
Екран продовження прогнозу сейсмічної активності надає додаткову 
деталізовану інформацію (рисунок 3.15). 
63 
ЧДТУ 252161.013ПЗ 
 
 
Рисунок 3.15 – Екран з детальним прогнозом сейсмічної активності 
 
Верхня частина екрану продовжує розділ "Prediction Summary" з 
додатковими параметрами: 
–    ймовірність цунамі: 0.0%; 
–    оцінка ризику за ML: Very Low; 
–    найближча тектонічна плита: Pacific Plate Boundary. 
У середній частині розташований розділ "Magnitude Probabilities" з 
графічним відображенням ймовірностей різних магнітуд: 
64 
ЧДТУ 252161.013ПЗ 
 
–    магнітуда 5.0-5.9: 7.1% (жовтий індикатор); 
–    магнітуда 4.0-4.9: 92.9% (синій індикатор); 
Далі слідує розділ "Nearby Fault Lines" з інформацією про найближчі 
розломи: 
–    Median Tectonic Line (Transform Strike-Slip): 182 км від локації; 
–    Japan Trench (Subduction Zone): 288 км від локації. 
У додатку навіть надається дата останнього оновлення та точність моделі 
машинного навчання: "Останнє оновлення: 3 квітня 2025 о 19:52. Точність моделі 
МЛ: 100%." 
Екран налаштувань дозволяє користувачам оновити обліковий запис, 
налаштувати уподобання даних та переглянути загальну інформацію про додаток 
(рисунок 3.16). 
 
 
Рисунок 3.16 – Екран налаштувань додатку 
 
Екран налаштувань структурований у три основні розділи. У верхній 
частині, з заголовком "Налаштування", розміщені секції з різними категоріями 
налаштувань. 
65 
ЧДТУ 252161.013ПЗ 
 
Розділ "ОБЛІКОВИЙ ЗАПИС" має першу частину, яка містить пункт 
"Вийти", що включає значок виходу, який символізує кнопку виходу, яка слугує 
для сигналізації користувачу для виходу з сеансу користувача або облікового 
запису. 
Другий розділ "DATA SETTINGS" включає дві опції налаштування даних: 
–  "Data refresh interval" зі значенням "6 hours", що визначає частоту 
оновлення даних про землетруси; 
–     "Auto-fetch on start" з перемикачем, встановленим "увімкнено". 
Третій розділ "ABOUT" містить інформацію про додаток: 
–    "Version" зі значенням "1.0.0", що вказує на поточну версію програми; 
–    "Data Source" зі значенням "USGS" та іконкою зовнішнього посилання. 
Екран управління даними надає користувачам можливість контролювати та 
налаштовувати зберігання даних та функції машинного навчання (рисунок 3.17). 
Верхня частина екрану містить навігаційний елемент з кнопкою "Settings" 
для повернення до загальних налаштувань та заголовок "Data Management". 
Екран поділений на чотири тематичні розділи. Перший розділ "DATA 
STATISTICS" відображає інформацію про збережені дані: 
–    "Stored earthquakes": 10 008 записів; 
–    "Estimated storage usage": 2.4 MB; 
–    кнопка "Refresh Statistics" з іконкою оновлення для актуалізації даних. 
Другий розділ "MACHINE LEARNING" містить інформацію про стан 
моделі прогнозування: 
–    "Model Status": Not Trained (помаранчевим кольором); 
–    статус: Not Started; 
–    кнопка "Train Model" з іконкою для запуску навчання моделі; 
–  пояснювальний текст: "Training the model requires historical earthquake 
data. Ensure you have collected sufficient data first.". 
Третій розділ "HISTORICAL DATA COLLECTION" надає можливість 
завантажити додаткові історичні дані: 
–    кнопка "Fetch 5 Years of Historical Data" з іконкою завантаження; 
66 
ЧДТУ 252161.013ПЗ 
 
–   пояснення: "This will download up to 5 years of earthquake data for ML 
training. Requires significant data and storage.". 
 
 
Рисунок 3.17 – Екран управління даними додатку 
 
Останній розділ "DATA MANAGEMENT" містить функцію оптимізації: 
–  кнопка "Optimize Storage" з іконкою налаштувань для оптимізації 
використання пам'яті пристрою. 
Розробка інтерфейсу користувача для SwiftUI-додатку з прогнозування 
землетрусів включає визначення вимог, проєктування основних компонентів, 
тестування та оптимізацію. 
Інтерфейс повинен бути: 
67 
ЧДТУ 252161.013ПЗ 
 
–  зручним – інтуїтивно зрозумілим, забезпечуючи швидкий доступ до 
основних функцій, таких як перегляд прогнозів, історії землетрусів і 
сповіщень; 
–   доступним – адаптованим для різних категорій користувачів, включаючи 
людей з особливими потребами; 
–   функціональним – містити всі необхідні можливості, такі як отримання 
реальних даних про землетруси, налаштування параметрів сповіщень та 
інтеграція з картами. 
Тестування та оптимізація інтерфейсу допоможуть забезпечити його 
коректну роботу в різних умовах використання, включаючи слабке 
інтернет-з'єднання та різні типи пристроїв. 
3.1.6 Опис розробки програмних компонентів 
Розробка додатку QuakeAlert для прогнозування землетрусів включає 
створення взаємопов'язаних програмних модулів: 
Основні компоненти: 
–  користувач: охоплює авторизацію, реєстрацію та відновлення пароля 
через Firebase Authentication; 
–   onboarding: представляє нових користувачів функціоналу додатка через 
інтерактивні екрани; 
–    візуалізація сейсмічних подій: отримує дані через API USGS; 
–    фільтрація даних: надає налаштування для фільтрації подій; 
–    детальна інформація: надає більше деталей про окремі сейсмічні події; 
–    прогнозування: використання моделей машинного навчання; 
–    пошук локацій: інтегрується з MapKit для визначення локації [15]. 
–   управління даними: відповідальне за збереження даних, оновлення даних 
та оптимізацію даних. 
Ці компоненти пов’язані між собою для забезпечення повного функціоналу 
додатку та показують, що застосовано модульний підхід до розробки, який 
гарантує масштабованість та підтримку системи [8]. 
3.2 Тестування системи 
68 
ЧДТУ 252161.013ПЗ 
 
Цей розділ надає детальне пояснення підходу до тестування мобільного 
додатка QuakeAlert на різних рівнях, щоб підтвердити його правильну поведінку 
відповідно до специфікацій. 
Спочатку використовувалися різні методи тестування, такі як класична 
багаторівнева модель тестування (модульне тестування, інтеграційне тестування, 
системне тестування і приймальне тестування) [12]. 
3.2.1 Модульне тестування 
Модульне тестування це рання фаза забезпечення якості програмного 
забезпечення, коли тестуються окремі одиниці/модулі/компоненти програмного 
забезпечення. Мета будь-якого модульного тестування - виявити помилки у 
функціонуванні модуля до того, як ці помилки зможуть поширитися в системі. 
Модульне тестування мобільного додатку QuakeAlert проводилося з 
використанням інструменту XCTest, який є нативною тестовою базою в 
середовищі Swift та Xcode. 
Основні кроки: 
1    Налаштування середовища тестування: 
–    інтеграція XCTest в проєкт; 
–    створення тестових цільових файлів (test targets); 
–    налаштування симуляторів для різних версій iOS. 
2    Написання тестів: 
–  тестові випадки для випробування функцій і/або методів для кожної 
інфраструктури; 
– використання макетних об'єктів для моделювання залежностей 
компонентів. 
3    Виконання тестів: 
–    запуск тестів через Xcode Test Navigator; 
–    аналіз результатів та покриття коду. 
Результати модульного тестування підтверджують, що всі основні частини 
додатку SwiftUI для прогнозування землетрусів працюють добре в порівнянні з 
очікуванням. 
69 
ЧДТУ 252161.013ПЗ 
 
Таблиця 3.1 
Результат модульного тестування 
Модуль Тестовий Очікуваний Фактичний Статус 
випадок результат результат 
Автентифікація Реєстрація Створення Створення Пройдено 
користувачів нового облікового облікового 
 облікового запису, запису, 
запису автоматичний автоматичний 
вхід вхід 
Вхід Користувача Користувача Пройдено 
користувача з авторизовано, авторизовано, 
валідними перехід на перехід на 
даними головний екран головний екран 
Компонент Завантаження Дані успішно Дані успішно Пройдено 
прогнозування даних з API отримані та отримані та 
декодовані декодовані 
Обробка Відображення Відображення Пройдено 
помилки повідомлення повідомлення 
мережі про помилку про помилку 
Обчислення Обчислення Обчислення Пройдено 
ймовірності відповідає відповідає 
землетрусу очікуваним очікуваним 
даним даним 
Аналіз Коректний Коректний Пройдено 
історичних аналіз тестових аналіз тестових 
даних наборів даних наборів даних 
 
3.2.2 Інтеграційне тестування 
70 
ЧДТУ 252161.013ПЗ 
 
Інтеграційне тестування додатку QuakeAlert перевіряє взаємодію між 
різними модулями системи для забезпечення коректної роботи. 
Основні етапи: 
– підготовка середовища: налаштування тестової бази Firebase, 
підключення до USGS API, ініціалізація тестових даних та створення облікових 
записів; 
–  визначення тестових сценаріїв: розробка випадків, що охоплюють 
взаємодію між модулями (авторизація-налаштування, фільтри-дані, 
карта-прогнозування); 
–  написання тестів: створення автоматизованих тестів для перевірки 
обробки даних та проведення ручного тестування інтерфейсу; 
–    виконання та аналіз: запуск тестів на різних версіях iOS та пристроях з 
подальшим аналізом результатів. 
Тестування підтвердило стабільність взаємодії між компонентами 
автентифікації, відображення землетрусів, фільтрації, прогнозування та 
управління даними. Особливу увагу приділено взаємодії з зовнішніми API та 
Firebase. Виявлені незначні проблеми з швидкодією при генерації прогнозів були 
вирішені оптимізацією алгоритмів. 
Наступний етап - системне тестування всього додатку в умовах, наближених 
до реального використання. 
 
Таблиця 3.2 
Результат інтеграційного тестування 
Модуль Тестовий випадок Очікуваний Фактичинй Статус 
результат результат 
Авторизація та Компонент Після авторизації Налаштування Пройдено 
завантаження автентифікації, завантажуються успішно 
налаштувань компонент персоналізовані завантажені 
налаштувань налаштування  
71 
ЧДТУ 252161.013ПЗ 
 
Продовження таблиці 3.2 
Застосування Компонент Відображення Дані Пройдено 
фільтрів до даних фільтрації, даних про відфільтровані 
про землетруси компонент землетруси, що коректно 
відображення відповідають 
землетрусів, заданим фільтрам 
USGS API 
Генерація Компонент Створення Прогноз Пройдено з 
прогнозу для пошуку місць, прогнозу генерується зауваження
обраної локації компонент сейсмічної коректно ми* 
прогнозування активності для 
обраної на карті 
локації 
 
*Зауваження: При генерації прогнозу для віддалених регіонів з малою 
кількістю історичних даних спостерігалась затримка в обробці. Проблему усунено 
шляхом оптимізації алгоритму прогнозування та додавання індикатора 
завантаження. 
3.2.3 Системне тестування 
Системне тестування додатку QuakeAlert перевіряє роботу всієї системи як 
єдиного цілого, оцінюючи відповідність встановленим вимогам і стабільність у 
реальних умовах. 
Етапи тестування: 
–  підготовка середовища: налаштування умов, максимально наближених 
до реальних, з включенням усіх компонентів системи (додаток, Firebase, USGS 
API, Core ML); 
–  розробка тестових сценаріїв: створення випадків, що охоплюють всі 
функціональні можливості (авторизація, карта землетрусів, фільтрація, 
прогнозування) та нефункціональні вимоги (продуктивність, безпека); 
72 
ЧДТУ 252161.013ПЗ 
 
–  написання тестів: підготовка детальних сценаріїв та автоматизованих 
UI-тестів для ключових користувацьких шляхів; 
– виконання: запуск тестів на різних моделях iOS-пристроїв, збір 
результатів та моніторинг продуктивності; 
–  аналіз і виправлення: обробка звітів про помилки, оптимізація ресурсів 
та повторне тестування після виправлень. 
Цей етап забезпечує комплексну перевірку додатку перед випуском, 
гарантуючи якість та надійність системи прогнозування землетрусів. 
 
Таблиця 3.3 
Результат системного тестування 
Модуль Тестовий Очікуваний Фактичний Статус 
випадок результат результат 
Автентифікація Реєстрація Користувача Користувача Пройдено 
користувача нового створено, створено, 
користувача доступ до доступ до 
та доступ до функцій функцій надано 
функцій надано 
Прогнозування Генерація Система Прогноз Пройдено 
прогнозу для аналізує дані генерується з 
обраної та надає очікуваною 
локації статистичний точністю 
прогноз для 
обраного 
регіону 
3.2.4 Приймальне тестування 
Приймальне тестування додатку QuakeAlert є заключним етапом перед 
випуском, який підтверджує відповідність системи очікуванням кінцевих 
73 
ЧДТУ 252161.013ПЗ 
 
користувачів. Процес залучає реальних мешканців сейсмоактивних регіонів, 
геологів та сейсмологів. 
Основні етапи: 
Підготовка: визначення реалістичних сценаріїв використання та 
формування тестової групи користувачів. 
– проведення: організація тестових сесій, під час яких користувачі 
виконують реальні завдання (реєстрація, перегляд карти, налаштування фільтрів, 
отримання прогнозів) та надають зворотний зв'язок; 
–   аналіз: оцінка результатів на основі відгуків користувачів; 
–   фіналізація: виправлення виявлених помилок. 
Цей підхід забезпечує оптимальну якість та корисність додатку 
прогнозування землетрусів для цільової аудиторії перед його публічним випуском. 
 
Таблиця 3.4 
Результат приймального тестування 
Модуль Тестовий випадок Очікуваний Фактичний Статус 
результат результат 
Автентифікація Реєстрація нового Користувача Користувача Пройдено 
користувача користувача та створено, створено, 
перевірка доступу доступ до доступ до 
функцій надано функцій надано 
Карта Перегляд карти Карта з Карта з Пройдено 
землетрусів активних маркерами маркерами 
землетрусів відображена відображена 
коректно коректно 
Прогнозування Генерація прогнозу Прогноз Прогноз Пройдено 
для  локації створено створено 
 
74 
ЧДТУ 252161.013ПЗ 
 
За результатами приймального тестування користувачі відзначили, що 
функціональність QuakeAlert потужна й корисна, але новачкам складно швидко 
освоїти всі можливості. У відповідь на цей відгук було впроваджено систему 
онбордингу – вступну послідовність із чотирьох екранів: 
–   привітальний екран із загальним призначенням додатку; 
–   особливості відстеження глобальних землетрусів; 
–   можливості налаштування персоналізованих фільтрів; 
–   завершальний екран із закликом розпочати роботу з системою. 
Додаткове тестування підтвердило значне покращення у розумінні 
функціональності новими користувачами та підвищення загальної зручності 
використання. Це рішення отримало високу оцінку учасників тестування і стало 
важливим доповненням до інтерфейсу додатку. 
3.3 Приклади впровадженого програмного комплексу 
У мобільному додатку QuakeAlert реалізовано комплекс функцій для 
моніторингу та прогнозування землетрусів: 
1   авторизація та реєстрація - вхід через існуючий обліковий запис або 
створення нового для доступу до всіх функцій; 
2   онбординг - послідовність екранів для нових користувачів, що знайомить 
з основними можливостями додатку; 
3   інтерактивна карта землетрусів - відображення сейсмічних подій з 
кольоровими маркерами, що відповідають магнітуді, та доступом до детальної 
інформації; 
4   система фільтрації - гнучке налаштування відображення подій за 
магнітудою, часом, розташуванням, глибиною та додатковими параметрами; 
5   прогнозування сейсмічної активності - генерація прогнозів для обраної 
локації на основі історичних даних та моделей машинного навчання; 
6   налаштування та управління даними - контроль частоти оновлення, 
автоматичного завантаження, навчання моделі та оптимізації пам'яті. 
75 
ЧДТУ 252161.013ПЗ 
 
Впроваджений комплекс забезпечує ефективний доступ до інформації про 
сейсмічну активність, допомагаючи користувачам бути краще підготовленими до 
потенційних землетрусів. 
 
 
Рисунок 3.18 - Авторизація користувача 
 
 
Рисунок 3.19 - Користувач отримав доступ до додатку 
76 
ЧДТУ 252161.013ПЗ 
 
 
 
Рисунок 3.20 - Привітальний екран 
 
 
Рисунок 3.21 - Карта з маркерами землетрусів 
77 
ЧДТУ 252161.013ПЗ 
 
 
Рисунок 3.22 - Пошук локації 
 
 
Рисунок 3.23 - Прогноз (частина 1) 
 
78 
ЧДТУ 252161.013ПЗ 
 
 
Рисунок 3.24 - Прогноз (частина 2) 
 
 
Рисунок 3.25 - Налаштування 
 
79 
ЧДТУ 252161.013ПЗ 
 
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ 
У третьому розділі розглянуто повний цикл розробки, тестування та 
впровадження мобільного додатку QuakeAlert для прогнозування землетрусів. 
Розробка програмного комплексу включала обґрунтування технологічного 
стеку (Swift, SwiftUI, Firebase, Core ML, USGS API, MapKit), створення 
структурної та логічної схеми системи, проектування системи збереження даних 
та розробку інтуїтивного інтерфейсу. 
Тестування системи проведено на всіх рівнях: модульному (перевірка 
окремих компонентів), інтеграційному (взаємодія між модулями), системному 
(функціонування на різних пристроях) та приймальному (з реальними 
користувачами), що виявило необхідність додавання онбордингу. 
Впроваджений програмний комплекс демонструє успішну реалізацію 
функцій авторизації, перегляду карт, налаштування фільтрів та генерації прогнозів 
сейсмічної активності. 
Створений додаток QuakeAlert надає користувачам потужний інструмент 
моніторингу та прогнозування землетрусів з використанням сучасних технологій 
машинного навчання та аналізу даних. Система відповідає всім поставленим 
вимогам і готова до впровадження для мешканців сейсмонебезпечних регіонів. 
 
 
 
 
 
 
 
 
 
 
 
 
80 
ЧДТУ 252161.013ПЗ 
 
ВИСНОВКИ 
Кваліфікаційна робота присвячена створенню мобільного додатку для 
моніторингу сейсмічної активності з комплексним підходом до розробки. 
У першому розділі проведено аналіз наукових публікацій та технічної 
документації щодо систем моніторингу землетрусів. Досліджено технологічні 
стеки, API сейсмологічних станцій та сховища геоданих, здійснено порівняльний 
аналіз існуючих рішень для визначення оптимальної платформи розробки. 
Другий розділ охоплював практичне проектування системи: формування 
вимог, моделювання функціональних компонентів та розробку архітектури. 
Створено концептуальні, логічні та фізичні моделі, описано механізми локального 
кешування даних, проектування інтерфейсу та розробки функціональних модулів 
з урахуванням продуктивності та роботи при обмеженому доступі до мережі. 
Третій розділ присвячено технічній реалізації та тестуванню додатку: 
вибору інструментів, деталізації архітектури, створенню бази даних, 
проектуванню адаптивного інтерфейсу та реалізації алгоритмів обробки 
сейсмічних даних. Всі рівні тестування підтвердили надійність системи та її 
відповідність критеріям якості. 
Результатом роботи став повнофункціональний додаток для моніторингу 
землетрусів, що надає актуальну інформацію в реальному часі та прогнози 
сейсмічної активності, забезпечуючи різні категорії користувачів зручним 
доступом до даних та підвищуючи рівень готовності до потенційних природних 
катаклізмів [3].   
 
 
 
 
 
 
 
 
 
81 
ЧДТУ 252161.013ПЗ 
 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1   Архітектура пз для моніторингу активності [Електронний ресурс]. - 
Точка доступу: https://www.researchgate.net/figure/Architecture-of-the-monitoring- 
system_fig1_2802302 [1]. 
2    Мобільні додатки для аналізу геофізичних даних [Електронний ресурс]. - 
Точка доступу: https://www.dynamicsgex.com.au/learning_hub/18-mobile-apps-for- 
the-tech-savvy-geologist [2]. 
3  Методи обробки та аналізу сейсмічних даних у реальному часі 
[Електронний ресурс]. - Точка доступу: https://www.dremio.com/wiki/real-time- 
processing/#:~:text=Real%2DTime%20Processing%20represents%20a,%2C%20and%2
0real%2Dtime%20analytics [3]. 
4     Прогнозування землетрусів: сучасні підходи та технології [Електронний 
ресурс]. - Точка доступу: https://uk.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80 
%D0%B5%D0%B4%D0%B1%D0%B0%D1%87%D0%B5%D0%BD%D0%BD%D1
%8F_%D0%B7%D0%B5%D0%BC%D0%BB%D0%B5%D1%82%D1%80%D1%83
%D1%81%D1%96%D0%B2 [4]. 
5   Геоінформаційні системи та технології [Електронний ресурс]. - Точка 
доступу: https://uk.wikipedia.org/wiki/%D0%93%D0%B5%D0%BE%D1%96%D0%B 
D%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D1%96%D0%B9%D0
%BD%D0%B0_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0 
[5]. 
6 Проектування інтерфейсу користувача для мобільних додатків 
моніторингу [Електронний ресурс]. - Точка доступу: https://dribbble.com/tags 
/emergency-app [6]. 
7    Геопросторові бази даних: проектування та використання [Електронний 
ресурс]. - Точка доступу: https://postgis.net/workshops/postgis-intro/ [7]. 
8  Методи формування сповіщень у мобільних додатках [Електронний 
ресурс]. - Точка доступу: https://developer.apple.com/documentation/usernotifications 
[8]. 
82 
ЧДТУ 252161.013ПЗ 
 
9  Основи розробки програмного забезпечення для систем моніторингу 
[Електронний ресурс]. - Точка доступу: https://www.codecademy.com/learn/ 
emergency-monitoring-systems [9]. 
10 Мобільні технології для відстеження природних катаклізмів 
[Електронний ресурс]. - Точка доступу: https://www.researchgate.net/publication/ 
301408347_Mobile_application_design_of_disaster_rescue_team_tracking [10]. 
11  Сучасні методи передбачення землетрусів з використанням нейронних 
мереж [Електронний ресурс]. - Точка доступу: https://academic.oup.com/gji/article/ 
240/1/81/7826790 [11]. 
12 Сучасні технології та стандарти розробки мобільних додатків 
[Електронний ресурс]. - Точка доступу: https://developer.android.com/guide/topics/ui 
[12]. 
13 Алгоритми визначення епіцентру та сили землетрусів [Електронний 
ресурс]. - Точка доступу: https://idl.iscram.org/files/chanthujanchandrakumar/2023/ 
2488_ChanthujanChandrakumar_etal2023.pdf [13]. 
14 Інтелектуальний аналіз сейсмічних даних: методи та інструменти 
[Електронний ресурс]. - Точка доступу: https://www.kaggle.com/datasets/usgs 
/earthquake-database [14]. 
15 Розробка кросплатформних мобільних додатків з використанням 
сучасних фреймворків [Електронний ресурс]. - Точка доступу: 
https://flutter.dev/docs/development/ui/widgets [15]. 
16 Управління даними у системах моніторингу надзвичайних ситуацій 
[Електронний ресурс]. - Точка доступу: https://en.wikipedia.org/wiki/Disaster_ 
response [16]. 
17 Mobile Application Development for Natural Disaster Monitoring 
[Електронний ресурс]. - Точка доступу: https://developer.apple.com/design/human- 
interface-guidelines [17]. 
18  Розробка мобільних додатків з використанням мови Swift [Електронний 
ресурс]. - Точка доступу: https://developer.apple.com/tutorials/swiftui/ [18]. 
83 
ЧДТУ 252161.013ПЗ 
 
19  Swift Programming Documentation [Електронний ресурс]. - Точка доступу: 
https://docs.swift.org/swift-book/ [19]. 
84 
 
ДОДАТОК А 
  
ЗАТВЕРДЖЕНО: 
Зав. кафедрою ПЗАС, професор 
_________________ Голуб С.В. 
„____” ______________ 2025 р. 
 
Програмне забезпечення мобільного додатку для моніторингу минулих та 
прогнозування майбутніх землетрусів. 
  
Специфікація 
482. ЧДТУ 252161.013 
Листів 1  
 
Розробник ________________ Мірзоєв І.А. 
Керівник ________________ Олексюк В.В. 
 
Черкаси 2025 
 
482. ЧДТУ 252161.013                                          2 
 
Позначення Найменування Примітки 
  Документація   
482.ЧДТУ. 252161 12 01 Текст програми   
482.ЧДТУ. 252161 34 01 Інструкція користувачеві   
482.ЧДТУ. 252161 90 01 Графічні матеріали   
   
   
   
   
   
   
   
   
   
   
   
   
 
86 
 
ДОДАТОК Б 
  
 
 
 
 
Програмне забезпечення мобільного додатку для моніторингу минулих та 
прогнозування майбутніх землетрусів. 
  
Текст програми 
482.ЧДТУ. 252161 12 01 
Листів 18 
  
Розробник ________________ Мірзоєв І.А. 
  
  
  
  Черкаси 2025 
 
482.ЧДТУ. 252161 12 01                                           2 
Лістинг файлу Core/Services/EarthquakeMLService.swift: 
class EarthquakeMLService: ObservableObject { 
    @Published var isModelTrained = false 
    @Published var modelAccuracy: Double = 0.0 
    @Published var trainingStatus: String = "Not Started" 
    @Published var lastTrainingDate: Date? 
    @Published var regionalRiskLevels: [CLLocation: RiskLevel] = [:] 
     
    static let shared = EarthquakeMLService() 
     
    private let userDefaults = UserDefaults.standard 
    private let modelFileKey = "EarthquakeMLModelPath" 
    private let lastTrainingDateKey = "LastMLModelTrainingDate" 
    private let modelAccuracyKey = "MLModelAccuracy" 
    private let regionalDataKey = "RegionalEarthquakeData" 
     
    private let dataManager = DataManagementService.shared 
    private let earthquakeService = EarthquakeService() 
    private var cancellables = Set<AnyCancellable>() 
     
    private let radiusInKilometers: Double = 300 
    private let gridPrecision: Double = 0.5 
    private let timeWindowYears: Int = 5 
     
    init() { 
        loadModelMetadata() 
        checkIfModelExists() 
        loadRegionalData() 
    } 
     
    struct DecisionNode: Codable { 
        let feature: String 
        let threshold: Double 
        let leftChild: DecisionTreeComponent 
        let rightChild: DecisionTreeComponent 
    } 
     
    indirect enum DecisionTreeComponent: Codable { 
        case node(DecisionNode) 
        case leaf(String) 
         
        private enum CodingKeys: String, CodingKey { 
            case type, value, node 
        } 
         
        init(from decoder: Decoder) throws { 
            let container = try decoder.container(keyedBy: CodingKeys.self) 
            let type = try container.decode(String.self, forKey: .type) 
             
            switch type { 
            case "leaf": 
                let value = try container.decode(String.self, forKey: .value) 
                self = .leaf(value) 
            case "node": 
                let node = try container.decode(DecisionNode.self, forKey: .node) 
                self = .node(node) 
88 
482.ЧДТУ. 252161 12 01                                           3 
            default: 
                throw DecodingError.dataCorruptedError( 
                    forKey: .type, 
                    in: container, 
                    debugDescription: "Invalid type: \(type)" 
                ) 
            } 
        } 
         
        func encode(to encoder: Encoder) throws { 
            var container = encoder.container(keyedBy: CodingKeys.self) 
             
            switch self { 
            case .leaf(let value): 
                try container.encode("leaf", forKey: .type) 
                try container.encode(value, forKey: .value) 
            case .node(let node): 
                try container.encode("node", forKey: .type) 
                try container.encode(node, forKey: .node) 
            } 
        } 
    } 
     
    typealias DecisionTree = DecisionTreeComponent 
     
    private func predict(with tree: DecisionTree, features: [String: Any]) -> String { 
        switch tree { 
        case .leaf(let prediction): 
            return prediction 
        case .node(let node): 
            guard let featureValue = features[node.feature] as? Double else { 
                return "none" 
            } 
             
            if featureValue < node.threshold { 
                return predict(with: node.leftChild, features: features) 
            } else { 
                return predict(with: node.rightChild, features: features) 
            } 
        } 
    } 
     
    private func evaluateModel(_ tree: DecisionTree, on testData: [[String: Any]]) -> Double { 
        var correctPredictions = 0 
         
        for sample in testData { 
            guard let trueLabel = sample["alertLevel"] as? String else { continue } 
             
            let prediction = predict(with: tree, features: sample) 
             
            if prediction == trueLabel { 
                correctPredictions += 1 
            } 
        } 
         
        return Double(correctPredictions) / Double(testData.count) 
    } 
    
89 
482.ЧДТУ. 252161 12 01                                           4 
 
    private func loadRegionalData() { 
        guard let data = userDefaults.data(forKey: regionalDataKey) else { return } 
         
        do { 
            let decoder = JSONDecoder() 
            let regionalData = try decoder.decode([RegionalEarthquakeData].self, from: data) 
             
            for region in regionalData { 
                let location = CLLocation(latitude: region.latitude, longitude: region.longitude) 
                regionalRiskLevels[location] = region.riskLevel 
            } 
        } catch { 
            print("Error loading regional data: \(error.localizedDescription)") 
        } 
    } 
     
    private func saveRegionalData() { 
        var regionalData: [RegionalEarthquakeData] = [] 
         
        for (location, riskLevel) in regionalRiskLevels { 
            regionalData.append(RegionalEarthquakeData( 
                latitude: location.coordinate.latitude, 
                longitude: location.coordinate.longitude, 
                riskLevel: riskLevel 
            )) 
        } 
         
        do { 
            let encoder = JSONEncoder() 
            let data = try encoder.encode(regionalData) 
            userDefaults.set(data, forKey: regionalDataKey) 
        } catch { 
            print("Error saving regional data: \(error.localizedDescription)") 
        } 
    } 
     
    private func loadModelMetadata() { 
        if let date = userDefaults.object(forKey: lastTrainingDateKey) as? Date { 
            lastTrainingDate = date 
        } 
         
        modelAccuracy = userDefaults.double(forKey: modelAccuracyKey) 
    } 
     
    private func saveModelMetadata(accuracy: Double) { 
        let now = Date() 
        userDefaults.set(now, forKey: lastTrainingDateKey) 
        userDefaults.set(accuracy, forKey: modelAccuracyKey) 
         
        lastTrainingDate = now 
        modelAccuracy = accuracy 
    } 
     
    private func checkIfModelExists() { 
        guard let modelPath = userDefaults.string(forKey: modelFileKey), 
              let modelURL = URL(string: modelPath) else { 
            isModelTrained = false 
90 
482.ЧДТУ. 252161 12 01                                           5 
            return 
        } 
         
        isModelTrained = FileManager.default.fileExists(atPath: modelURL.path) 
    } 
     
    func trainModel(forceRetrain: Bool = false, completion: ((Bool) -> Void)? = nil) { 
        if isModelTrained && !forceRetrain { 
            if let lastDate = lastTrainingDate, 
               Date().timeIntervalSince(lastDate) < 30 * 24 * 3600 { 
                trainingStatus = "Using existing model (trained \(formatDate(lastDate)))" 
                completion?(true) 
                return 
            } 
        } 
         
        trainingStatus = "Preparing training data..." 
         
        earthquakeService.checkAndFetchEarthquakes() 
         
        let mlDataset = dataManager.prepareMLDataset() 
         
        if mlDataset.isEmpty { 
            trainingStatus = "Error: No training data available" 
            completion?(false) 
            return 
        } 
         
        trainingStatus = "Training model with \(mlDataset.count) earthquake records... 0%" 
         
        DispatchQueue.global(qos: .userInitiated).async { [weak self] in 
            guard let self = self else { return } 
             
            do { 
                let (modelURL, accuracy) = try self.createAndTrainModelWithProgress(with: mlDataset) 
                 
                self.userDefaults.set(modelURL.absoluteString, forKey: self.modelFileKey) 
                self.saveModelMetadata(accuracy: accuracy) 
                 
                self.analyzeRegionalRiskPatterns(from: mlDataset) 
                 
                DispatchQueue.main.async { 
                    self.isModelTrained = true 
                    self.trainingStatus = "Model trained successfully with \(Int(accuracy * 100))% accuracy" 
                    completion?(true) 
                } 
            } catch { 
                DispatchQueue.main.async { 
                    self.trainingStatus = "Error training model: \(error.localizedDescription)" 
                    completion?(false) 
                } 
            } 
        } 
    } 
     
    private func analyzeRegionalRiskPatterns(from dataset: [MLEarthquakeData]) { 
        DispatchQueue.main.async { 
            self.trainingStatus = "Analyzing regional risk patterns..." 
91 
482.ЧДТУ. 252161 12 01                                           6 
 
        } 
         
        let regions = groupEarthquakesByRegion(dataset) 
         
        var riskLevels: [CLLocation: RiskLevel] = [:] 
         
        for (key, earthquakes) in regions { 
            let components = key.split(separator: ",") 
            guard components.count == 2, 
                  let latitude = Double(components[0]), 
                  let longitude = Double(components[1]) else { 
                continue 
            } 
             
            let location = CLLocation(latitude: latitude, longitude: longitude) 
            let riskLevel = calculateRegionalRiskLevel(earthquakes) 
            riskLevels[location] = riskLevel 
        } 
         
        DispatchQueue.main.async { 
            self.regionalRiskLevels = riskLevels 
            self.saveRegionalData() 
        } 
    } 
     
    private func groupEarthquakesByRegion(_ dataset: [MLEarthquakeData]) -> [String: [MLEarthquakeData]] { 
        var regions: [String: [MLEarthquakeData]] = [:] 
         
        for earthquake in dataset { 
            let latitudeGrid = round(earthquake.latitude / gridPrecision) * gridPrecision 
            let longitudeGrid = round(earthquake.longitude / gridPrecision) * gridPrecision 
             
            let regionKey = "\(latitudeGrid),\(longitudeGrid)" 
             
            if regions[regionKey] == nil { 
                regions[regionKey] = [] 
            } 
             
            regions[regionKey]?.append(earthquake) 
        } 
         
        return regions 
    } 
     
    private func calculateRegionalRiskLevel(_ earthquakes: [MLEarthquakeData]) -> RiskLevel { 
        let totalQuakes = earthquakes.count 
         
        if totalQuakes == 0 { 
            return .veryLow 
        } 
         
        let significantQuakes = earthquakes.filter { $0.magnitude >= 5.0 }.count 
        let significantRatio = Double(significantQuakes) / Double(totalQuakes) 
         
        let highMagQuakes = earthquakes.filter { $0.magnitude >= 6.5 }.count 
        let highMagRatio = Double(highMagQuakes) / Double(totalQuakes) 
         
92 
482.ЧДТУ. 252161 12 01                                           7 
        let tsunamiQuakes = earthquakes.filter { $0.hasTsunami }.count 
        let tsunamiRatio = Double(tsunamiQuakes) / Double(totalQuakes) 
         
        if highMagRatio > 0.1 || tsunamiRatio > 0.05 { 
            return .high 
        } else if significantRatio > 0.2 || highMagRatio > 0.02 { 
            return .medium 
        } else if significantRatio > 0.05 { 
            return .low 
        } else { 
            return .veryLow 
        } 
    } 
     
    private func createAndTrainModelWithProgress(with mlDataset: [MLEarthquakeData]) throws -> (URL, Double) { 
        var trainingData = [[String: Any]]() 
         
        DispatchQueue.main.async { 
            self.trainingStatus = "Preparing data for training... 5%" 
        } 
         
        for quakeData in mlDataset { 
            guard quakeData.hasAlerts else { continue } 
             
            let alertLevel: String 
            if quakeData.magnitude >= 7.0 || (quakeData.magnitude >= 6.0 && quakeData.hasTsunami) { 
                alertLevel = "red" 
            } else if quakeData.magnitude >= 5.5 { 
                alertLevel = "orange" 
            } else if quakeData.magnitude >= 4.5 { 
                alertLevel = "yellow" 
            } else if quakeData.magnitude >= 3.5 { 
                alertLevel = "green" 
            } else { 
                alertLevel = "none" 
            } 
             
            let latitudeBin = floor(quakeData.latitude / 10) * 10 
            let longitudeBin = floor(quakeData.longitude / 10) * 10 
            let plateDistance = estimatePlateDistance(latitude: quakeData.latitude, longitude: quakeData.longitude) 
            let regionRisk = getRegionalRiskValue(latitude: quakeData.latitude, longitude: quakeData.longitude) 
             
            trainingData.append([ 
                "magnitude": quakeData.magnitude, 
                "depth": quakeData.depth, 
                "hasTsunami": quakeData.hasTsunami ? 1.0 : 0.0, 
                "latitude": quakeData.latitude, 
                "longitude": quakeData.longitude, 
                "latitudeBin": latitudeBin, 
                "longitudeBin": longitudeBin, 
                "plateDistance": plateDistance, 
                "regionRisk": regionRisk, 
                "hourOfDay": Double(quakeData.hourOfDay), 
                "dayOfWeek": Double(quakeData.dayOfWeek), 
                "month": Double(quakeData.month), 
                "alertLevel": alertLevel 
            ]) 
         
93 
482.ЧДТУ. 252161 12 01                                           8 
 
         
        guard trainingData.count >= 50 else { 
            throw NSError(domain: "com.quakealert.ml", code: 100, userInfo: [ 
                NSLocalizedDescriptionKey: "Insufficient labeled data for training (need at least 50 samples)" 
            ]) 
        } 
         
        DispatchQueue.main.async { 
            self.trainingStatus = "Splitting data into training/validation sets... 15%" 
        } 
         
        trainingData.shuffle() 
        let splitIndex = Int(Double(trainingData.count) * 0.8) 
        let trainingSet = Array(trainingData[0..<splitIndex]) 
        let validationSet = Array(trainingData[splitIndex..<trainingData.count]) 
         
        DispatchQueue.main.async { 
            self.trainingStatus = "Building decision tree model... 25%" 
        } 
         
        let featureNames = [ 
            "magnitude", "depth", "hasTsunami", "latitude", "longitude", 
            "latitudeBin", "longitudeBin", "plateDistance", "regionRisk", 
            "hourOfDay", "dayOfWeek", "month" 
        ] 
         
        let progressCallback: (Double) -> Void = { [weak self] progress in 
            guard let self = self else { return } 
             
            let scaledProgress = 25.0 + (progress * 60.0) 
            DispatchQueue.main.async { 
                self.trainingStatus = "Building decision tree model... \(Int(scaledProgress))%" 
            } 
        } 
         
        let decisionTree = buildDecisionTreeWithProgress( 
            from: trainingSet, 
            features: featureNames, 
            targetAttribute: "alertLevel", 
            maxDepth: 8, 
            progressCallback: progressCallback 
        ) 
         
        DispatchQueue.main.async { 
            self.trainingStatus = "Saving trained model... 90%" 
        } 
         
        let documentsDirectory = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first! 
        let modelURL = documentsDirectory.appendingPathComponent("EnhancedEarthquakeDecisionTree.json") 
         
        let jsonEncoder = JSONEncoder() 
        jsonEncoder.outputFormatting = .prettyPrinted 
        let treeData = try jsonEncoder.encode(decisionTree) 
        try treeData.write(to: modelURL) 
         
        DispatchQueue.main.async { 
            self.trainingStatus = "Evaluating model performance... 95%" 
94 
482.ЧДТУ. 252161 12 01                                           9 
        } 
         
        let accuracy = evaluateModel(decisionTree, on: validationSet) 
         
        return (modelURL, accuracy) 
    } 
     
    func estimatePlateDistance(latitude: Double, longitude: Double) -> Double { 
        let inRingOfFire = ( 
            (longitude < -110 && longitude > -180 && latitude > -60 && latitude < 60) || 
            (longitude > 120 && longitude < 180 && latitude > -50 && latitude < 60) || 
            (latitude > 45 && latitude < 75 && longitude > 160 && longitude < -140) 
        ) 
         
        let inMediterraneanBelt = ( 
            longitude > -10 && longitude < 100 && latitude > 10 && latitude < 50 
        ) 
         
        if inRingOfFire || inMediterraneanBelt { 
            return 0.0 
        } 
         
        let ringOfFireDist = distanceToRingOfFire(latitude: latitude, longitude: longitude) 
        let medBeltDist = distanceToMediterraneanBelt(latitude: latitude, longitude: longitude) 
         
        return min(ringOfFireDist, medBeltDist) 
    } 
    private func distanceToRingOfFire(latitude: Double, longitude: Double) -> Double { 
        let distances: [Double] = [ 
            abs(longitude - -120) + abs(latitude - 40), 
            abs(longitude - 140) + abs(latitude - 35), 
            abs(longitude - -75) + abs(latitude - -15), 
            abs(longitude - 170) + abs(latitude - -40) 
        ] 
         
        return distances.min() ?? 100 
    } 
     
    private func distanceToMediterraneanBelt(latitude: Double, longitude: Double) -> Double { 
        let distances: [Double] = [ 
            abs(longitude - 30) + abs(latitude - 35), 
            abs(longitude - 60) + abs(latitude - 30), 
            abs(longitude - 80) + abs(latitude - 35) 
        ] 
         
        return distances.min() ?? 100 
    } 
     
    private func getRegionalRiskValue(latitude: Double, longitude: Double) -> Double { 
        var closestDistance = Double.greatestFiniteMagnitude 
        var closestRiskValue = 0.0 
         
        for (location, riskLevel) in regionalRiskLevels { 
            let latDiff = location.coordinate.latitude - latitude 
            let lonDiff = location.coordinate.longitude - longitude 
            let distance = sqrt(latDiff * latDiff + lonDiff * lonDiff) 
             
            if distance < closestDistance { 
95 
482.ЧДТУ. 252161 12 01                                           10 
 
                closestDistance = distance 
                closestRiskValue = riskLevelToValue(riskLevel) 
            } 
        } 
         
        if closestDistance > 10 { 
            let plateDistance = estimatePlateDistance(latitude: latitude, longitude: longitude) 
             
            if plateDistance < 10 { 
                return 3.0 
            } else if plateDistance < 30 { 
                return 2.0 
            } else if plateDistance < 100 { 
                return 1.0 
            } else { 
                return 0.0 
            } 
        } 
         
        return closestRiskValue 
    } 
     
    private func riskLevelToValue(_ riskLevel: RiskLevel) -> Double { 
        switch riskLevel { 
        case .high: return 3.0 
        case .medium: return 2.0 
        case .low: return 1.0 
        case .veryLow: return 0.0 
        } 
    } 
     
    private func buildDecisionTreeWithProgress( 
        from data: [[String: Any]], 
        features: [String], 
        targetAttribute: String, 
        maxDepth: Int = 10, 
        currentDepth: Int = 0, 
        progressCallback: (Double) -> Void 
    ) -> DecisionTreeComponent { 
        if currentDepth == 0 { 
            progressCallback(0.0) 
        } else { 
            let progress = Double(currentDepth) / Double(maxDepth) 
            progressCallback(progress) 
        } 
         
        if let sameClass = allSameClass(data, targetAttribute: targetAttribute) { 
            return .leaf(sameClass) 
        } 
         
        if currentDepth >= maxDepth || features.isEmpty { 
            return .leaf(majorityClass(data, targetAttribute: targetAttribute)) 
        } 
         
        let (bestFeature, bestThreshold) = findBestSplit(data, features: features, targetAttribute: targetAttribute) 
         
        let (leftData, rightData) = splitData(data, feature: bestFeature, threshold: bestThreshold) 
96 
482.ЧДТУ. 252161 12 01                                           11 
         
        if leftData.isEmpty || rightData.isEmpty { 
            return .leaf(majorityClass(data, targetAttribute: targetAttribute)) 
        } 
         
        let leftChild = buildDecisionTreeWithProgress( 
            from: leftData, 
            features: features, 
            targetAttribute: targetAttribute, 
            maxDepth: maxDepth, 
            currentDepth: currentDepth + 1, 
            progressCallback: progressCallback 
        ) 
         
        let rightChild = buildDecisionTreeWithProgress( 
            from: rightData, 
            features: features, 
            targetAttribute: targetAttribute, 
            maxDepth: maxDepth, 
            currentDepth: currentDepth + 1, 
            progressCallback: progressCallback 
        ) 
         
        return .node(DecisionNode( 
            feature: bestFeature, 
            threshold: bestThreshold, 
            leftChild: leftChild, 
            rightChild: rightChild 
        )) 
    } 
     
    private func allSameClass(_ data: [[String: Any]], targetAttribute: String) -> String? { 
        guard let firstItem = data.first, 
              let firstClass = firstItem[targetAttribute] as? String else { 
            return nil 
        } 
         
        for item in data.dropFirst() { 
            if let itemClass = item[targetAttribute] as? String, itemClass != firstClass { 
                return nil 
            } 
        } 
         
        return firstClass 
    } 
     
    private func majorityClass(_ data: [[String: Any]], targetAttribute: String) -> String { 
        var classCounts: [String: Int] = [:] 
         
        for item in data { 
            if let itemClass = item[targetAttribute] as? String { 
                classCounts[itemClass, default: 0] += 1 
            } 
        } 
         
        let sortedClasses = classCounts.sorted { $0.value > $1.value } 
        return sortedClasses.first?.key ?? "none" 
    } 
97 
482.ЧДТУ. 252161 12 01                                           12 
 
     
    private func findBestSplit(_ data: [[String: Any]], features: [String], targetAttribute: String) -> (feature: String, 
threshold: Double) { 
        var bestFeature = features.first ?? "magnitude" 
        var bestThreshold = 0.0 
        var bestInformationGain = -Double.infinity 
         
        for feature in features { 
            let (threshold, gain) = findBestThresholdForFeature(data, feature: feature, targetAttribute: targetAttribute) 
             
            if gain > bestInformationGain { 
                bestInformationGain = gain 
                bestFeature = feature 
                bestThreshold = threshold 
            } 
        } 
         
        return (bestFeature, bestThreshold) 
    } 
     
    private func findBestThresholdForFeature(_ data: [[String: Any]], feature: String, targetAttribute: String) -> (threshold: 
Double, gain: Double) { 
        var values: [Double] = [] 
        for item in data { 
            if let value = item[feature] as? Double { 
                values.append(value) 
            } 
        } 
         
        values = Array(Set(values)).sorted() 
         
        if values.count <= 1 { 
            return (values.first ?? 0.0, 0.0) 
        } 
         
        var thresholds: [Double] = [] 
        for i in 0..<values.count-1 { 
            thresholds.append((values[i] + values[i+1]) / 2.0) 
        } 
         
        var bestThreshold = thresholds.first ?? 0.0 
        var bestGain = -Double.infinity 
         
        for threshold in thresholds { 
            let (leftData, rightData) = splitData(data, feature: feature, threshold: threshold) 
             
            if leftData.isEmpty || rightData.isEmpty { 
                continue 
            } 
             
            let gain = calculateInformationGain(data, leftData: leftData, rightData: rightData, targetAttribute: targetAttribute) 
             
            if gain > bestGain { 
                bestGain = gain 
                bestThreshold = threshold 
            } 
        } 
98 
482.ЧДТУ. 252161 12 01                                           13 
         
        return (bestThreshold, bestGain) 
    } 
     
    private func splitData(_ data: [[String: Any]], feature: String, threshold: Double) -> (left: [[String: Any]], right: 
[[String: Any]]) { 
        var leftData: [[String: Any]] = [] 
        var rightData: [[String: Any]] = [] 
         
        for item in data { 
            if let value = item[feature] as? Double { 
                if value < threshold { 
                    leftData.append(item) 
                } else { 
                    rightData.append(item) 
                } 
            } 
        } 
         
        return (leftData, rightData) 
    } 
     
    private func calculateInformationGain(_ parentData: [[String: Any]], leftData: [[String: Any]], rightData: [[String: 
Any]], targetAttribute: String) -> Double { 
        let parentEntropy = calculateEntropy(parentData, targetAttribute: targetAttribute) 
        let leftWeight = Double(leftData.count) / Double(parentData.count) 
        let rightWeight = Double(rightData.count) / Double(parentData.count) 
         
        let leftEntropy = calculateEntropy(leftData, targetAttribute: targetAttribute) 
        let rightEntropy = calculateEntropy(rightData, targetAttribute: targetAttribute) 
         
        let weightedChildEntropy = (leftWeight * leftEntropy) + (rightWeight * rightEntropy) 
         
        return parentEntropy - weightedChildEntropy 
    } 
     
    private func calculateEntropy(_ data: [[String: Any]], targetAttribute: String) -> Double { 
        var classCounts: [String: Int] = [:] 
        let totalCount = data.count 
         
        for item in data { 
            if let itemClass = item[targetAttribute] as? String { 
                classCounts[itemClass, default: 0] += 1 
            } 
        } 
         
        var entropy = 0.0 
        for (_, count) in classCounts { 
            let probability = Double(count) / Double(totalCount) 
            entropy -= probability * log2(probability) 
        } 
         
        return entropy 
    } 
     
    func predictAlertLevel(for earthquake: Earthquake) -> AlertLevel { 
        guard isModelTrained, 
              let modelPathString = userDefaults.string(forKey: modelFileKey), 
99 
482.ЧДТУ. 252161 12 01                                           14 
 
              let modelURL = URL(string: modelPathString), 
              FileManager.default.fileExists(atPath: modelURL.path) else { 
            return predictAlertLevelHeuristic(for: earthquake) 
        } 
         
        do { 
            let data = try Data(contentsOf: modelURL) 
            let decoder = JSONDecoder() 
            let decisionTree = try decoder.decode(DecisionTree.self, from: data) 
             
            let latitude = earthquake.coordinate.latitude 
            let longitude = earthquake.coordinate.longitude 
            let latitudeBin = floor(latitude / 10) * 10 
            let longitudeBin = floor(longitude / 10) * 10 
            let plateDistance = estimatePlateDistance(latitude: latitude, longitude: longitude) 
            let regionRisk = getRegionalRiskValue(latitude: latitude, longitude: longitude) 
             
            let features: [String: Any] = [ 
                "magnitude": earthquake.magnitude, 
                "depth": earthquake.depth, 
                "hasTsunami": earthquake.hasTsunami ? 1.0 : 0.0, 
                "latitude": latitude, 
                "longitude": longitude, 
                "latitudeBin": latitudeBin, 
                "longitudeBin": longitudeBin, 
                "plateDistance": plateDistance, 
                "regionRisk": regionRisk, 
                "hourOfDay": Double(Calendar.current.component(.hour, from: earthquake.date)), 
                "dayOfWeek": Double(Calendar.current.component(.weekday, from: earthquake.date)), 
                "month": Double(Calendar.current.component(.month, from: earthquake.date)) 
            ] 
             
            let prediction = predict(with: decisionTree, features: features) 
             
            if let alertLevel = AlertLevel(rawValue: prediction) { 
                return alertLevel 
            } 
             
            return predictAlertLevelHeuristic(for: earthquake) 
             
        } catch { 
            print("Prediction error: \(error.localizedDescription)") 
            return predictAlertLevelHeuristic(for: earthquake) 
        } 
    } 
     
    private func predictAlertLevelHeuristic(for earthquake: Earthquake) -> AlertLevel { 
        if earthquake.magnitude >= 7.0 || (earthquake.magnitude >= 6.0 && earthquake.hasTsunami) { 
            return .red 
        } else if earthquake.magnitude >= 5.5 { 
            return .orange 
        } else if earthquake.magnitude >= 4.5 { 
            return .yellow 
        } else if earthquake.magnitude >= 3.5 { 
            return .green 
        } else { 
            return .none 
100 
482.ЧДТУ. 252161 12 01                                           15 
        } 
    } 
     
    func getRegionalRiskLevel(for location: CLLocation) -> RiskLevel { 
        var nearestRegion: CLLocation? 
        var nearestDistance = Double.greatestFiniteMagnitude 
         
        for (regionLocation, _) in regionalRiskLevels { 
            let distance = location.distance(from: regionLocation) 
            if distance < nearestDistance { 
                nearestDistance = distance 
                nearestRegion = regionLocation 
            } 
        } 
         
        if let region = nearestRegion, nearestDistance < 100_000 { 
            return regionalRiskLevels[region] ?? .veryLow 
        } 
         
        let plateDistance = estimatePlateDistance( 
            latitude: location.coordinate.latitude, 
            longitude: location.coordinate.longitude 
        ) 
         
        if plateDistance < 10 { 
            return .high 
        } else if plateDistance < 30 { 
            return .medium 
        } else if plateDistance < 100 { 
            return .low 
        } else { 
            return .veryLow 
        } 
    } 
     
    func getRiskMap(centerLocation: CLLocation, radiusKm: Double = 500, gridSize: Double = 0.5) -> [CLLocation: 
RiskLevel] { 
        var riskMap: [CLLocation: RiskLevel] = [:] 
         
        let latRangeDegrees = radiusKm / 111.0 
        let lonRangeDegrees = radiusKm / (111.0 * cos(centerLocation.coordinate.latitude * .pi / 180.0)) 
         
        let minLat = centerLocation.coordinate.latitude - latRangeDegrees 
        let maxLat = centerLocation.coordinate.latitude + latRangeDegrees 
        let minLon = centerLocation.coordinate.longitude - lonRangeDegrees 
        let maxLon = centerLocation.coordinate.longitude + lonRangeDegrees 
         
        var latStep = gridSize 
        var lonStep = gridSize 
         
        for lat in stride(from: minLat, through: maxLat, by: latStep) { 
            for lon in stride(from: minLon, through: maxLon, by: lonStep) { 
                let location = CLLocation(latitude: lat, longitude: lon) 
                 
                if centerLocation.distance(from: location) / 1000.0 <= radiusKm { 
                    let riskLevel = getRegionalRiskLevel(for: location) 
                    riskMap[location] = riskLevel 
                } 
101 
482.ЧДТУ. 252161 12 01                                           16 
 
            } 
        } 
         
        return riskMap 
    } 
     
    // MARK: - Batch Prediction with Location Context 
     
    func predictAlertLevels(for earthquakes: [Earthquake]) -> [String: AlertLevel] { 
        var predictions = [String: AlertLevel]() 
         
        for earthquake in earthquakes { 
            let alertLevel = predictAlertLevel(for: earthquake) 
            predictions[earthquake.id] = alertLevel 
        } 
         
        return predictions 
    } 
     
    func predictForSyntheticEarthquakes(at location: CLLocation, magnitudes: [Double] = [4.0, 5.0, 6.0, 7.0]) -> [Double: 
AlertLevel] { 
        var predictions: [Double: AlertLevel] = [:] 
         
        for magnitude in magnitudes { 
            let syntheticQuake = createSyntheticEarthquake( 
                at: location, 
                magnitude: magnitude, 
                depth: 10.0, 
                hasTsunami: magnitude >= 6.5 
            ) 
             
            let alertLevel = predictAlertLevel(for: syntheticQuake) 
            predictions[magnitude] = alertLevel 
        } 
         
        return predictions 
    } 
     
    func createSyntheticEarthquake(at location: CLLocation, magnitude: Double, depth: Double, hasTsunami: Bool) -> 
Earthquake { 
        return Earthquake( 
            id: UUID().uuidString, 
            properties: Earthquake.Properties( 
                mag: magnitude, 
                place: "Synthetic Location", 
                time: Date().timeIntervalSince1970 * 1000, 
                url: "", 
                code: "synthetic", 
                title: "Synthetic Earthquake Prediction", 
                alert: nil, 
                tsunami: hasTsunami ? 1 : 0 
            ), 
            geometry: Earthquake.Geometry( 
                type: "Point", 
                coordinates: [location.coordinate.longitude, location.coordinate.latitude, depth] 
            ) 
        ) 
102 
482.ЧДТУ. 252161 12 01                                           17 
    } 
     
    // MARK: - Utilities 
     
    private func formatDate(_ date: Date) -> String { 
        let formatter = RelativeDateTimeFormatter() 
        formatter.unitsStyle = .full 
        return formatter.localizedString(for: date, relativeTo: Date()) 
    } 
} 
// MARK: - Supporting Structures 
struct RegionalEarthquakeData: Codable { 
    let latitude: Double 
    let longitude: Double 
    let riskLevel: RiskLevel 
     
    enum CodingKeys: String, CodingKey { 
        case latitude, longitude, riskLevel 
    } 
     
    init(latitude: Double, longitude: Double, riskLevel: RiskLevel) { 
        self.latitude = latitude 
        self.longitude = longitude 
        self.riskLevel = riskLevel 
    } 
     
    init(from decoder: Decoder) throws { 
        let container = try decoder.container(keyedBy: CodingKeys.self) 
        latitude = try container.decode(Double.self, forKey: .latitude) 
        longitude = try container.decode(Double.self, forKey: .longitude) 
         
        let riskLevelString = try container.decode(String.self, forKey: .riskLevel) 
        switch riskLevelString { 
        case "high": 
            riskLevel = .high 
        case "medium": 
            riskLevel = .medium 
        case "low": 
            riskLevel = .low 
        default: 
            riskLevel = .veryLow 
        } 
    } 
     
    func encode(to encoder: Encoder) throws { 
        var container = encoder.container(keyedBy: CodingKeys.self) 
        try container.encode(latitude, forKey: .latitude) 
        try container.encode(longitude, forKey: .longitude) 
         
        let riskLevelString: String 
        switch riskLevel { 
        case .high: 
            riskLevelString = "high" 
        case .medium: 
            riskLevelString = "medium" 
        case .low: 
            riskLevelString = "low" 
        case .veryLow: 
103 
482.ЧДТУ. 252161 12 01                                           18 
 
 
            riskLevelString = "veryLow" 
        } 
        try container.encode(riskLevelString, forKey: .riskLevel) 
    } 
} 
// MARK: - Earthquake Extension for ML Integration 
extension Earthquake { 
    func predictAlertLevel() -> AlertLevel { 
        return EarthquakeMLService.shared.predictAlertLevel(for: self) 
    } 
     
    func getLocationRiskLevel() -> RiskLevel { 
        let location = CLLocation(latitude: coordinate.latitude, longitude: coordinate.longitude) 
        return EarthquakeMLService.shared.getRegionalRiskLevel(for: location) 
    } 
} 
104 
 
ДОДАТОК В 
 
 
 
 
 
Програмне забезпечення мобільного додатку для моніторингу минулих та 
прогнозування майбутніх землетрусів. 
  
  
Інструкція користувачеві 
482.ЧДТУ. 252161 34 01 
Листів 4 
  
  
Розробник ________________ Мірзоєв І.А. 
  
 Черкаси 2025 
 
482.ЧДТУ. 252161 34 01                                           2 
Цей мобільний додаток розроблено для забезпечення користувачів 
актуальною інформацією про сейсмічну активність у різних регіонах світу. 
QuakeAlert надає зручний доступ до даних про минулі землетруси, можливість 
прогнозувати майбутні події та отримувати сповіщення про потенційні загрози. 
Реєстрація користувачів 
Запуск додатку: 
–     Завантажте додаток QuakeAlert з App Store; 
–     Відкрийте додаток на вашому пристрої iOS; 
Реєстрація нового облікового запису: 
–     На екрані входу оберіть опцію "Create Account"; 
–     Введіть вашу електронну адресу у відповідне поле; 
–     Створіть надійний пароль (щонайменше 8 символів); 
–     Підтвердіть пароль, ввівши його повторно; 
–     Натисніть кнопку "Create Account"; 
–   Підтвердіть свою електронну адресу через посилання, надіслане на 
вказану пошту; 
–     Після успішної реєстрації додаток автоматично увійде до системи. 
Вхід у існуючий обліковий запис: 
–     Введіть вашу електронну адресу; 
–     Введіть ваш пароль; 
–     Натисніть кнопку "Log in"; 
–  Альтернативно, можете обрати "Log in as guest" для обмеженого 
доступу без реєстрації. 
Перегляд даних про землетруси 
Використання списку землетрусів: 
–    Після входу в систему відкривається екран "Global Earthquakes"; 
–    Перегляньте список останніх землетрусів з вказанням магнітуди, місця 
та часу події; 
10
482.ЧДТУ. 252161 34 01                                           3 
–  Використовуйте кнопку фільтрації для налаштування відображення 
даних; 
–    Натисніть на будь-який землетрус для перегляду детальної інформації. 
Використання карти землетрусів: 
–    Натисніть пункт "Map" у нижньому меню навігації; 
–    Перегляньте інтерактивну карту з маркерами землетрусів; 
–    Маркери різних кольорів вказують на інтенсивність події (зелений - 
слабка, помаранчевий - середня, червоний - сильна); 
–    Натисніть на будь-який маркер для перегляду стислої інформації; 
–    Для перегляду детальної інформації, натисніть на спливаюче вікно 
маркера. 
Налаштування фільтрів: 
–    Натисніть кнопку фільтрації на екрані списку або карти; 
–    У вкладці "General" встановіть мінімальну магнітуду та часовий 
період; 
–    У вкладці "Location" виберіть регіон та за потреби обмежте глибину; 
–    У вкладці "Additional" виберіть опціональні налаштування 
(відображення подій, що спричинили цунамі, тощо); 
–    Натисніть "Apply" для збереження налаштувань. 
Прогнозування майбутніх землетрусів 
Створення прогнозу: 
–    Натисніть пункт "Prediction" у нижньому меню навігації; 
–    Перегляньте карту для вибору локації; 
–    Використовуйте поле пошуку для знаходження конкретного місця; 
–    Після вибору локації натисніть кнопку "Create Earthquake Prediction"; 
–    Система проаналізує історичні дані та відобразить статистичні 
прогнози. 
Інтерпретація прогнозу: 
107 
482.ЧДТУ. 252161 34 01                                           4 
 
–    Перегляньте рівень ризику (дуже низький, низький, середній, 
високий); 
–    Ознайомтеся з картою сейсмічних ризиків регіону; 
–    Проаналізуйте статистичну інформацію (річна частота землетрусів, 
ймовірність різних магнітуд); 
–    Перегляньте інформацію про найближчі розломи та тектонічні плити. 
Управління налаштуваннями 
Налаштування додатку: 
–    Натисніть пункт "Settings" у нижньому меню навігації; 
–    У розділі "ACCOUNT" можете вийти з облікового запису; 
–    У розділі "DATA SETTINGS" налаштуйте інтервал оновлення даних та 
автоматичне завантаження; 
–    У розділі "ABOUT" перегляньте інформацію про версію додатку та 
джерело даних. 
Управління даними: 
–    Натисніть "Data Management" у розділі налаштувань; 
–    Перегляньте статистику збережених даних; 
–    За потреби запустіть навчання моделі машинного навчання; 
–    Завантажте додаткові історичні дані для підвищення точності 
прогнозування; 
–    Оптимізуйте використання пам'яті пристрою. 
Додаток QuakeAlert регулярно оновлює дані з надійних джерел, таких як 
Геологічна служба США (USGS), для забезпечення користувачів актуальною 
інформацією про сейсмічну активність у всьому світі. Використовуйте цей 
інструмент для підвищення вашої обізнаності та готовності до потенційних 
природних катаклізмів. 
10
 
ДОДАТОК Г 
  
  
  
  
  
   
Програмне забезпечення мобільного додатку для моніторингу минулих та 
прогнозування майбутніх землетрусів. 
   
Графічні матеріали 
482.ЧДТУ. 252161 90 01 
Листів 12 
   
Розробник ________________ Мірзоєв. І.А. 
  
 
Черкаси 2025 
 
482.ЧДТУ. 252161 90 01                                          2 
Рисунок Г1 – Слайд 1 
 
Рисунок Г2 – Слайд 2 
110 
482.ЧДТУ. 252161 90 01                                          3 
 
Рисунок Г3 – Слайд 3 
 
Рисунок Г4 - Слайд 4 
111 
482.ЧДТУ. 252161 90 01                                          4 
 
 
Рисунок Г5 - Слайд 5 
 
Рисунок Г6 – Слайд 6 
112 
482.ЧДТУ. 252161 90 01                                          5 
Рисунок Г7 – Слайд 7 
 
Рисунок Г8 – Слайд 8 
113 
482.ЧДТУ. 252161 90 01                                          6 
 
 
Рисунок Г9 – Слайд 9 
 
Рисунок Г10 – Слайд 10 
114 
482.ЧДТУ. 252161 90 01                                          7 
 
Рисунок Г11 – Слайд 11 
 
Рисунок Г12 – Слайд 12 
115 
482.ЧДТУ. 252161 90 01                                          8 
 
 
Рисунок Г13 - Слайд 13 
 
Рисунок Г14 - Слайд 14 
116 
482.ЧДТУ. 252161 90 01                                          9 
 
Рисунок Г15 - Слайд 15 
 
Рисунок Г16 - Слайд 16 
117 
482.ЧДТУ. 252161 90 01                                          10 
 
 
Рисунок Г17 - Слайд 17 
 
Рисунок Г18 - Слайд 18 
118 
482.ЧДТУ. 252161 90 01                                          11 
 
Рисунок Г19 - Слайд 19 
 
Рисунок Г20 – Слайд 20 
119 
482.ЧДТУ. 252161 90 01                                          12 
 
 
Рисунок Г21 – Слайд 21
 
Рисунок Г22 – Слайд 22 
120