ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9067Full metadata record
| DC Field | Value | Language |
|---|---|---|
| dc.contributor.advisor | Немченко , Вадим В'ячеславович | - |
| dc.contributor.author | Бершадський, Вадим Анатолійович | - |
| dc.date.accessioned | 2026-03-24T17:10:36Z | - |
| dc.date.available | 2026-03-24T17:10:36Z | - |
| dc.date.issued | 2025-06-21 | - |
| dc.identifier.uri | https://er.chdtu.edu.ua/handle/ChSTU/9067 | - |
| dc.description.abstract | АНОТАЦІЇ Виконавець: Бершадський Вадим Анатолійович. Назва роботи: «Розробка мобільного додатку для трекінгу звичок». Спеціальність: 121 Інженерія програмного забезпечення. Навчальний заклад: «Черкаський державний технологічний університет» м. Черкаси, 2025р. У бакалаврській роботі розглядається розробка мобільного додатку трекінгу звичок для користувачів, які прагнуть покращити особисту продуктивність та впровадити корисні щоденні практики. Основною метою проєкту є створення інструменту, який дозволяє користувачам фіксувати, відстежувати та аналізувати свої звички з метою формування сталих поведінкових патернів. Додаток має відповідати вимогам щодо функціональності, зручності використання, інтуїтивного інтерфейсу та продуктивності. У процесі роботи було проведено аналіз потреб цільової аудиторії, сформульовано вимоги до мобільного застосунку, спроєктовано ключовий функціонал і реалізовано систему на платформі Android з використанням мови програмування Kotlin. Основні ідеї та результати дослідження включають: ‒ формування вимог: були визначені як первинні, так і детальні вимоги до додатку. Особливу увагу приділено зручності для кінцевого користувача, мотивації до регулярного використання та адаптивності функціоналу під різні сценарії використання. Визначено функціональні та нефункціональні характеристики системи; ‒ моделювання функціоналу: було розроблено концептуальну, логічну та фізичну моделі додатку. Визначено основні функції, такі як додавання нової звички, відмітка про її виконання, перегляд статистики, використання нагадувань і фільтрація звичок за категоріями; ‒ реалізація системи: мобільний додаток реалізовано на основі Android SDK із використанням мови програмування Kotlin, бібліотек Room для локального зберігання даних, а також Jetpack-компонентів для управління станом і життєвим циклом. Також описано архітектуру додатку, включаючи використання шаблону MVVM (Model–View–ViewModel). У підсумку, розроблений додаток для трекінгу звичок забезпечує користувачів інтуїтивним інструментом для моніторингу щоденних активностей і сприяє формуванню продуктивної поведінки. Система відповідає поставленим вимогам і демонструє високу надійність у практичному використанні. | uk_UA |
| dc.description.abstract | ANNOTATIONS Performer: Bershadskyi Vadim Anatoliovich The title of the work: " Development of a mobile application for habit tracking". Specialty: 121 Software engineering. Educational institution: Cherkasy State Technological University, Cherkasy, 2025. The bachelor's thesis examines the development of a mobile habit tracking application for users seeking to improve personal productivity and implement useful daily practices. The main goal of the project is to create a tool that allows users to record, track, and analyze their habits in order to form sustainable behavioral patterns. The application must meet the requirements for functionality, usability, intuitive interface, and performance. In the course of the work, we analyzed the needs of the target audience, formulated requirements for the mobile application, designed the key functionality, and implemented the system on the Android platform using the Kotlin programming language. The main ideas and results of the study include: - Formation of requirements: both primary and detailed requirements for the application were identified. Particular attention is paid to the convenience of the end user, motivation for regular use, and adaptability of the functionality to different use cases. Functional and non-functional characteristics of the system were identified; - Functional modeling: conceptual, logical and physical models of the application were developed. The main functions were identified, such as adding a new habit, marking its completion, viewing statistics, using reminders, and filtering habits by category; - system implementation: the mobile application is implemented on the basis of the Android SDK using the Kotlin programming language, Room libraries for local data storage, and Jetpack components for state and life cycle management. The architecture of the application is also described, including the use of the MVVM (Model-View-ViewModel) pattern. As a result, the developed habit tracking application provides users with an intuitive tool for monitoring daily activities and promotes productive behavior. The system meets the requirements and demonstrates high reliability in practical use. | uk_UA |
| dc.language.iso | uk | uk_UA |
| dc.subject | МОБІЛЬНИЙ ДОДАТОК | uk_UA |
| dc.subject | ТРЕКІНГ ЗВИЧОК | uk_UA |
| dc.subject | ANDROID | uk_UA |
| dc.subject | KOTLIN | uk_UA |
| dc.subject | ROOM | uk_UA |
| dc.subject | MVVM | uk_UA |
| dc.subject | ЛОКАЛЬНА БАЗА ДАНИХ | uk_UA |
| dc.subject | ІНТЕРФЕЙС КОРИСТУВАЧА | uk_UA |
| dc.subject | ПРОДУКТИВНІСТЬ | uk_UA |
| dc.title | Розробка мобільного додатку для трекінгу звичок | uk_UA |
| dc.type | Bachelor Thesis | uk_UA |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) | |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Бершадський Вадим Анатолійович.pdf Restricted Access | 4.69 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«бакалавра»
освітній рівень
на тему: «Розробка мобільного додатку для трекінгу звичок»
Виконав: студент 4 курсу, групи ПЗ-2104
Спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Бершадський В. А.
(прізвище та ініціали)
Керівник Немченко В. В.
(прізвище та ініціали)
Рецензент Кисельов В. С.
(прізвище та ініціали)
Черкаси 2025
1
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
___________ Голуб С.В.
«___» _______________ 2025 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Бершадський Вадим Анатолійович
(прізвище, ім’я, по батькові)
1.Тему проекту (роботи) «Розробка мобільного додатку для трекінгу звичок»
Керівник проекту (роботи) Немченко Вадим В’ячеславович кандидат технічних наук, доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « 26 » лютого
2025 року №60/04
2. Строк подання студентом проекту (роботи) 20 травня 2025 р.
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління;
вимоги до проекту; календарне планування проекту; управління ризиками проекту;
управління ресурсами
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ;
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань;
Розділ 2. Впровадження результатів досліджень у практику проектування програмного
забезпечення інформаційних систем;
Розділ 3. Розробка та тестування програмного забезпечення;
Висновки;
Список використаних джерел;
Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;
2
Слайд 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
3
7. Дата видачі завдання 02 грудня 2025 р.
КАЛЕНДАРНИЙ ПЛАН
Строк
№ виконання
Назва етапів випускної роботи Примітки
п/п етапів випускної
роботи
1 Постановка задачі 05.12.2023 виконано
2 Підготовка завдання 13.12.2023 виконано
3 Погодження завдання 16.12.2023 виконано
4 Затвердження завдання 19.02.2024 виконано
Основна стадія
1 Підбір матеріалів 27.02.2024 виконано
2 Аналіз шляхів вирішення поставленої задачі 04.02.2024 виконано
3 Розрахунок основних параметрів роботи 10.03.2024 виконано
4 Вибір кінцевого варіанту проектного рішення 17.03.2024 виконано
5 Оформлення первісної редакції роботи 25.03.2024 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 31.04.2024 виконано
керівником
2 Оформлення пояснювальної записки роботи в 10.05.2024 виконано
кінцевій редакції
3 Попередній захист роботи 13.05.2024
4 Затвердження роботи 14.05.2024
5 Рецензування роботи 15.05.2024
6 Захист роботи 20.06.2024
Студент _____________________ Бершадський В. А.
(підпис) (прізвище та ініціали)
Керівник проекту (роботи) _____________________ Немченко В. В.
(підпис) (прізвище та ініціали)
3
АНОТАЦІЇ
Виконавець: Бершадський Вадим Анатолійович.
Назва роботи: «Розробка мобільного додатку для трекінгу звичок».
Спеціальність: 121 Інженерія програмного забезпечення.
Навчальний заклад: «Черкаський державний технологічний університет»
м. Черкаси, 2025р.
У бакалаврській роботі розглядається розробка мобільного додатку
трекінгу звичок для користувачів, які прагнуть покращити особисту
продуктивність та впровадити корисні щоденні практики. Основною метою
проєкту є створення інструменту, який дозволяє користувачам фіксувати,
відстежувати та аналізувати свої звички з метою формування сталих
поведінкових патернів. Додаток має відповідати вимогам щодо
функціональності, зручності використання, інтуїтивного інтерфейсу та
продуктивності.
У процесі роботи було проведено аналіз потреб цільової аудиторії,
сформульовано вимоги до мобільного застосунку, спроєктовано ключовий
функціонал і реалізовано систему на платформі Android з використанням мови
програмування Kotlin. Основні ідеї та результати дослідження включають:
‒ формування вимог: були визначені як первинні, так і детальні вимоги
до додатку. Особливу увагу приділено зручності для кінцевого користувача,
мотивації до регулярного використання та адаптивності функціоналу під різні
сценарії використання. Визначено функціональні та нефункціональні
характеристики системи;
‒ моделювання функціоналу: було розроблено концептуальну, логічну та
фізичну моделі додатку. Визначено основні функції, такі як додавання нової
звички, відмітка про її виконання, перегляд статистики, використання
нагадувань і фільтрація звичок за категоріями;
‒ реалізація системи: мобільний додаток реалізовано на основі Android
SDK із використанням мови програмування Kotlin, бібліотек Room для
локального зберігання даних, а також Jetpack-компонентів для управління
4
станом і життєвим циклом. Також описано архітектуру додатку, включаючи
використання шаблону MVVM (Model–View–ViewModel).
У підсумку, розроблений додаток для трекінгу звичок забезпечує
користувачів інтуїтивним інструментом для моніторингу щоденних активностей
і сприяє формуванню продуктивної поведінки. Система відповідає поставленим
вимогам і демонструє високу надійність у практичному використанні.
Ключові слова. МОБІЛЬНИЙ ДОДАТОК, ТРЕКІНГ ЗВИЧОК,
ANDROID, KOTLIN, ROOM, MVVM, ЛОКАЛЬНА БАЗА ДАНИХ, ІНТЕРФЕЙС
КОРИСТУВАЧА, ПРОДУКТИВНІСТЬ.
5
ANNOTATIONS
Performer: Bershadskyi Vadim Anatoliovich
The title of the work: " Development of a mobile application for habit tracking".
Specialty: 121 Software engineering.
Educational institution: Cherkasy State Technological University, Cherkasy,
2025.
The bachelor's thesis examines the development of a mobile habit tracking
application for users seeking to improve personal productivity and implement useful
daily practices. The main goal of the project is to create a tool that allows users to
record, track, and analyze their habits in order to form sustainable behavioral patterns.
The application must meet the requirements for functionality, usability, intuitive
interface, and performance.
In the course of the work, we analyzed the needs of the target audience,
formulated requirements for the mobile application, designed the key functionality, and
implemented the system on the Android platform using the Kotlin programming
language. The main ideas and results of the study include:
- Formation of requirements: both primary and detailed requirements for the
application were identified. Particular attention is paid to the convenience of the end
user, motivation for regular use, and adaptability of the functionality to different use
cases. Functional and non-functional characteristics of the system were identified;
- Functional modeling: conceptual, logical and physical models of the
application were developed. The main functions were identified, such as adding a new
habit, marking its completion, viewing statistics, using reminders, and filtering habits
by category;
- system implementation: the mobile application is implemented on the basis of
the Android SDK using the Kotlin programming language, Room libraries for local
data storage, and Jetpack components for state and life cycle management. The
architecture of the application is also described, including the use of the MVVM
(Model-View-ViewModel) pattern.
6
As a result, the developed habit tracking application provides users with an
intuitive tool for monitoring daily activities and promotes productive behavior. The
system meets the requirements and demonstrates high reliability in practical use.
ЗМІСТ
................................................................................................................................ 7
ВСТУП .................................................................................................................. 7
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ ....................................................................................... 15
1.1 Огляд платформ та фреймворків для розробки мобільного додатку для
трекінгу звичок ......................................................................................................... 15
1.2 Методи розробки мобільних додатків .................................................... 16
1.3 Порівняльний аналіз існуючих аналогів ................................................ 17
1.4 Постановка задачі ..................................................................................... 18
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ ....................................................... 20
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ................................................................................. 21
ФІТІС, кафедра ПЗАС, ПЗ-2104
2.1 Моделювання предметної області .......................................................... 21
2.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області ................................................................................ 22
2.1.2 Елементи моделювання предметної області ................................... 25
2.1.3 Робоча область моделювання ........................................................... 27
2.2 Формування та аналіз вимог .................................................................... 28
2.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги ...................................................................................... 28
2.2.2 Формування вимог за допомогою діаграми прецедентів .............. 30
2.3 Проектування логічної структури програмного комплексу ................. 32
2.3.1 Діаграми класів .................................................................................. 33
7
ЧДТУ 252149.001ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб. Бершадський В. А. «Розробка мобільного додатку для Літ. Лист Листів
ЧДТУ 252149.001ПЗ
2.4 Архітектура проектування ....................................................................... 39
2.4.1 Діаграма компонентів ....................................................................... 39
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ........................................................................................................... 42
2.5 Моделювання поведінки системи ........................................................... 44
2.5.1 Діаграма діяльності ........................................................................... 44
2.5.2 Діаграма послідовності ..................................................................... 46
2.5.3 Діаграма комунікації ......................................................................... 49
2.5.4 Діаграма скінченного автомату ........................................................ 51
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ ........................................................ 53
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ .......................................................................................................... 55
3.1 Розробка програмного комплексу ........................................................... 55
3.1.1 Обґрунтування вибору засобів реалізації ....................................... 55
3.1.2 Опис структурної (функціональної) схеми ..................................... 56
3.1.3 Опис логічної схеми .......................................................................... 58
3.1.4 Розробка бази даних .......................................................................... 60
3.1.5 Розробка інтерфейсу користувача ................................................... 61
3.1.6 Опис розробки програмних компонентів ........................................ 63
3.2 Тестування системи .................................................................................. 65
3.2.1 Модульне тестування ........................................................................ 65
3.2.2 Інтеграційне тестування.................................................................... 67
3.2.3 Системне тестування ......................................................................... 69
3.2.4 Приймальне тестування .................................................................... 71
3.3 Приклади впровадженого програмного комплексу .............................. 73
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ ....................................................... 75
ВИСНОВКИ ........................................................................................................ 77
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .......................................................... 79
Додаток А ............................................................................................................ 80
Додаток Б ............................................................................................................. 81
Додаток В ............................................................................................................ 84
Додаток Г............................................................................................................. 87
6
ЧДТУ 252149.001ПЗ
ВСТУП
Актуальність теми
У сучасному світі, де високий темп життя, велика кількість інформації та
стресові фактори суттєво впливають на продуктивність і самопочуття людини,
зростає інтерес до методів самоменеджменту та особистісного розвитку. Одним з
ефективних підходів до підвищення особистої ефективності є формування та
підтримка корисних звичок. Ведення обліку виконання щоденних звичок
допомагає людям досягати поставлених цілей, покращувати фізичне та психічне
здоров’я, а також підвищувати рівень організованості.
Зважаючи на широке розповсюдження смартфонів і мобільних технологій,
мобільні додатки стали основним інструментом для щоденного управління
особистими завданнями та активностями. Проте більшість існуючих додатків для
трекінгу звичок або мають обмежений функціонал, або не враховують
індивідуальні потреби користувачів. Це створює потребу в розробці зручного,
гнучкого й ефективного інструменту, який дозволить користувачам не лише
відстежувати звички, але й аналізувати власні досягнення та зберігати мотивацію.
Таким чином, розробка мобільного додатку трекінгу звичок є актуальною
задачею, що поєднує в собі потреби користувачів у самоконтролі, інструменти
цифрових технологій і принципи UX-дизайну для досягнення максимальної
ефективності у повсякденному житті.
Мета і завдання розробки
Мета розробки. Метою даної бакалаврської роботи є створення мобільного
додатку для трекінгу звичок, який забезпечує користувачам зручний інтерфейс для
фіксації, відстеження та аналізу виконання щоденних звичок з метою підвищення
особистої продуктивності та підтримки сталих позитивних змін у поведінці.
Розроблений додаток має забезпечувати:
− інтуїтивно зрозуміле додавання нових звичок;
− можливість щоденного відзначення виконання;
− перегляд статистики прогресу;
− використання нагадувань для підтримки регулярності;
7
ЧДТУ 252149.001ПЗ
− зберігання даних на локальному пристрої без потреби у підключенні до
інтернету.
Для досягнення цієї мети реалізація повинна враховувати вимоги
користувачів до функціональності, зручності, стабільності роботи та
розширюваності системи.
Завдання розробки
Завдання розробки мобільного додатку трекінгу звичок:
1. Аналіз вимог до мобільного додатку:
– визначити ключові функції, необхідні користувачам для ефективного
відстеження звичок;
– зібрати та впорядкувати вимоги цільової аудиторії щодо функціональності,
інтерфейсу та зручності використання.
2. Огляд існуючих рішень:
– дослідити популярні додатки для трекінгу звичок;
– оцінити їхні сильні та слабкі сторони, а також можливості для вдосконалення.
3. Розробка архітектури мобільного додатку:
– створити концептуальну модель системи;
– визначити основні компоненти додатку та їхню взаємодію;
– спроєктувати структуру локальної бази даних для зберігання інформації про
звички та прогрес користувача.
4. Реалізація додатку:
– реалізувати інтерфейс користувача з урахуванням принципів зручності та
доступності;
– впровадити функції створення, редагування та відстеження звичок, а також
систему нагадувань і перегляду статистики;
– провести тестування програмного продукту для виявлення помилок і
забезпечення його стабільної роботи.
5. Інтеграція та розгортання:
– підготувати додаток до публікації в Google Play (або для локального
використання);
– створити документацію та інструкції для користувачів.
8
ЧДТУ 252149.001ПЗ
6. Оцінка ефективності:
– проаналізувати потенційні переваги використання додатку для цільової аудиторії;
– оцінити вплив розробленої системи на підвищення продуктивності та
формування корисних звичок.
Ці завдання забезпечують комплексний підхід до розробки мобільного
додатку трекінгу звичок, орієнтований на задоволення потреб користувачів і
досягнення високої якості програмного продукту.
Предмет розробки
Об'єкт розробки. Об’єктом розробки є мобільний додаток для трекінгу
звичок. Цей додаток покликаний забезпечити ефективний та зручний інструмент
для формування, підтримки та аналізу корисних звичок користувача. Система
дозволяє щоденно відстежувати виконання звичок, отримувати нагадування,
переглядати статистику прогресу та мотивувати користувача до
самовдосконалення шляхом системного підходу до розвитку звичок.
Методи проектування та конструювання
Методи проектування. Проєктування мобільного додатку для трекінгу
звичок передбачає використання кількох методів, що забезпечують ефективність,
зручність використання, надійність і масштабованість розроблюваної системи. У
даній бакалаврській роботі застосовувалися такі методи проєктування [1]:
Об’єктно-орієнтоване проєктування (ООП)
Основним методом, який застосовувався під час розробки додатку, є
об’єктно-орієнтоване проєктування. ООП дозволяє структурувати програмний код
у вигляді об’єктів, що моделюють реальні сутності та їх взаємодії.
Основні принципи ООП включають:
– інкапсуляцію: приховування внутрішньої реалізації об’єктів і взаємодія з ними
через публічні методи;
– наслідування: можливість створювати нові класи на основі вже існуючих, що
сприяє повторному використанню коду;
– поліморфізм: здатність об’єктів відповідати на однакові методи по-різному,
залежно від конкретної реалізації;
9
ЧДТУ 252149.001ПЗ
– абстракцію: виділення загальних характеристик та поведінки для спрощення
побудови складних систем.
Моделювання за допомогою UML
Для візуального представлення логіки роботи додатку та структури його
компонентів застосовувалось моделювання з використанням UML (Unified
Modeling Language). Основні типи діаграм, що використовувалися:
– діаграми прецедентів: відображають основні сценарії взаємодії користувача з
додатком (наприклад, додавання звички, перегляд статистики);
– класові діаграми: описують структуру об’єктів, їх властивості, методи та зв’язки
між ними;
– діаграми послідовностей: ілюструють порядок виконання операцій між об’єктами
при реалізації певного функціоналу;
– діаграми станів: демонструють зміни стану об’єкта залежно від дій користувача
(наприклад, статус звички: запланована, виконана, пропущена).
Використання шаблонів проєктування
Шаблони проєктування допомагають вирішити типові задачі ефективним і
перевіреним способом. У межах проєкту використовувалися такі шаблони:
– Singleton: для створення єдиного екземпляра об’єкта, наприклад, для зберігання
глобальних налаштувань користувача;
– Factory Method: для гнучкого створення об’єктів різних типів (наприклад, різні
типи звичок або категорії);
– Observer: для оновлення інтерфейсу користувача у відповідь на зміну стану
звичок або появу нових записів у базі даних.
Застосування зазначених методів дозволило створити масштабовану,
підтримувану та зручну у використанні мобільну систему для трекінгу звичок.
Методи конструювання
Розробка користувацького інтерфейсу
Цей метод охоплює проєктування та реалізацію зручного і інтуїтивно зрозумілого
інтерфейсу для мобільного додатку. Він включає визначення основного
функціоналу, розміщення елементів керування, кольорову гаму та адаптацію
інтерфейсу під різні розміри екранів. Головна мета — забезпечити позитивний
10
ЧДТУ 252149.001ПЗ
досвід взаємодії користувача з додатком, спростити додавання, відстеження й
аналіз звичок.
Розробка логіки додатку (серверна частина або внутрішня бізнес-логіка)
Для забезпечення роботи мобільного додатку розробляється логіка, що обробляє
введені дані, зберігає інформацію про звички, генерує статистику та надсилає
нагадування. Якщо застосовується клієнт-серверна архітектура, реалізовується
серверна частина, що відповідає за обробку запитів та синхронізацію даних між
пристроями.
Інтеграція з базою даних. Для збереження інформації про користувачів,
звички, дати виконання, статуси та нагадування використовується база даних. На
цьому етапі проєктується схема бази даних, створюються таблиці та реалізуються
запити для читання, запису та оновлення інформації.
Реалізація функціональності. Цей метод включає програмування основних
модулів додатку: створення та редагування звичок, календар виконання, система
нагадувань, візуалізація статистики, підтримка категорій звичок тощо. Усі функції
мають бути реалізовані відповідно до вимог користувача та протестовані на
стабільність.
Тестування та відлагодження. На завершальному етапі проводиться
тестування функціональних можливостей додатку, щоб переконатися в їхній
стабільній та коректній роботі. Тестуються різні сценарії взаємодії, перевіряється
інтерфейс, продуктивність та відповідність очікуванням. Виявлені помилки
усуваються, після чого повторно перевіряється результат.
Опис отриманих результатів. У результаті виконання бакалаврської роботи
були досягнуті наступні результати.
Аналіз потреб користувачів. Було проведено детальний аналіз потреб
цільової аудиторії, яка включає користувачів, зацікавлених у покращенні особистої
продуктивності та формуванні корисних звичок. На основі опитувань і вивчення
поведінки користувачів визначено основні функціональні та нефункціональні
вимоги до мобільного додатку для трекінгу звичок. Зібрані дані дозволили
створити систему, яка відповідає очікуванням і потребам кінцевих користувачів.
Формування вимог
11
ЧДТУ 252149.001ПЗ
На основі аналізу було сформовано перелік основних функцій додатку,
зокрема:
– відстеження виконання щоденних звичок;
– створення власних звичок із зазначенням часу, повторень, пріоритету;
– візуалізація прогресу у вигляді календаря або графіків;
– система нагадувань і мотиваційних повідомлень.
Моделювання системи
Було створено концептуальну, логічну та фізичну моделі мобільного
додатку:
– концептуальна модель: визначає загальну структуру додатку та ключові модулі
(інтерфейс, логіка, база даних);
– логічна модель: описує зв’язки між сутностями (користувач, звичка, запис,
статистика), а також сценарії взаємодії користувача з додатком;
– фізична модель: визначає технічні рішення для реалізації зберігання даних,
взаємодії з інтерфейсом і генерації нагадувань.
Реалізація системи
Мобільний додаток був реалізований на базі Android із використанням мови
програмування Kotlin у середовищі Android Studio. Було реалізовано основний
функціонал згідно із сформованими вимогами, включаючи інтерфейс для
керування звичками, систему збереження прогресу та сповіщення.
Оцінка та тестування
Проведене тестування показало стабільну роботу додатку, коректність
обробки введених даних та відповідність очікуванням користувачів. Додаток
продемонстрував високу продуктивність, зручність використання та ефективність
у формуванні звичок.
Висновки та рекомендації
Результати роботи підтверджують, що створений мобільний додаток
задовольняє потреби користувачів у сфері саморозвитку та тайм-менеджменту.
Запропоновано рекомендації для подальшого розвитку: синхронізація з хмарними
сервісами, додавання соціальних функцій (спільні звички, челенджі) та розширення
аналітичних можливостей.
12
ЧДТУ 252149.001ПЗ
Ці результати демонструють ефективність підходу до розробки мобільного
додатку трекінгу звичок і його практичну цінність для широкої аудиторії
користувачів.
Практичне значення отриманих результатів
Результати дослідження та розробки мобільного додатку для трекінгу звичок
мають значне практичне значення, що виявляється в таких аспектах:
Покращення самоменеджменту користувачів.
Додаток сприяє формуванню корисних звичок і підвищенню особистої
продуктивності користувачів. Завдяки можливості створювати власні звички,
отримувати нагадування та візуалізувати прогрес, користувачі отримують
ефективний інструмент для організації повсякденного життя, покращення здоров’я
та досягнення особистих цілей.
Готовність до використання.
Розроблений мобільний додаток повністю готовий до впровадження.
Проведене тестування підтвердило стабільну роботу, зручний інтерфейс і
відповідність очікуванням користувачів. Додаток може бути використаний без
необхідності додаткових технічних доопрацювань.
Масштабність та універсальність.
Додаток може бути використаний широким колом користувачів незалежно
від віку, професії чи способу життя. Його архітектура дозволяє легко адаптувати
систему для нових функцій або інтегрувати її з іншими сервісами, такими як хмарні
платформи, фітнес-додатки чи соціальні мережі.
Рекомендації щодо використання.
Рекомендовано забезпечити регулярне оновлення додатку відповідно до
нових запитів користувачів, додавати додаткові можливості (аналітика звичок,
соціальні функції, челенджі), а також впровадити систему збору зворотного зв’язку
для покращення користувацького досвіду. Для популяризації додатку доцільно
провести рекламну кампанію серед цільової аудиторії.
Ці результати свідчать про високу практичну цінність розробленого
мобільного додатку, його готовність до масштабного впровадження та значний
потенціал для позитивного впливу на повсякденне життя користувачів.
13
ЧДТУ 252149.001ПЗ
Особистий внесок автора. У процесі виконання бакалаврської роботи автор
зробив значний внесок на всіх етапах розробки мобільного додатку для трекінгу
звичок. Особисто було проведено детальний аналіз потреб користувачів, зокрема
вивчення особливостей формування звичок та методів підтримки мотивації. На
основі зібраних даних були сформульовані чіткі функціональні та нефункціональні
вимоги до системи.
Автор самостійно розробив концептуальну, логічну та фізичну моделі
додатку, визначив структуру інтерфейсу та внутрішню архітектуру. Реалізація
додатку була виконана з використанням мови програмування Kotlin для платформи
Android, що забезпечило нативну продуктивність, швидкодію та сучасний дизайн
інтерфейсу.
Особливу увагу приділено тестуванню функціональності, виправленню
помилок та оптимізації продуктивності додатку на різних пристроях. Це дозволило
створити надійний, зручний і ефективний інструмент для щоденного використання.
14
ЧДТУ 252149.001ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
Мобільні додатки для трекінгу звичок стали популярним інструментом у
сфері особистої ефективності, охорони здоров’я та саморозвитку. Вони
допомагають користувачам формувати, відслідковувати та підтримувати корисні
звички, сприяючи досягненню особистих цілей. У цьому розділі здійснюється
аналіз наукової та технічної інформації щодо створення трекерів звичок,
зосереджуючись на існуючих методах, технологіях та прикладах успішних
реалізацій.
Трекери звичок — це спеціалізовані мобільні додатки, які дозволяють
користувачам реєструвати виконання щоденних дій, візуалізувати прогрес та
отримувати мотиваційні нагадування. Вони можуть включати функції аналітики,
гейміфікації, інтеграцію з календарем або нагадуваннями, що робить їх
ефективним інструментом для побудови сталих звичок. Завдяки широкому
розповсюдженню мобільних пристроїв та зростанню інтересу до теми особистого
розвитку, трекери звичок набули широкого застосування у повсякденному житті.
1.1 Огляд платформ та фреймворків для розробки мобільного додатку
для трекінгу звичок
Розробка мобільних додатків є однією з найдинамічніших галузей сучасного
програмного забезпечення. Існує велика кількість інструментів, фреймворків та
мов програмування, які дозволяють створювати мобільні застосунки як для однієї,
так і для декількох платформ одночасно. Найпоширенішими мобільними
операційними системами є Android та iOS.
Для розробки Android-додатків використовується мова програмування
Kotlin, яка є офіційною мовою від Google та активно підтримується спільнотою.
Kotlin забезпечує лаконічний, безпечний і сучасний синтаксис, що значно підвищує
продуктивність розробників.
Однією з ключових бібліотек, що використовується при роботі з базами
даних в Android, є Room — абстрактний рівень над SQLite, який полегшує роботу
15
ЧДТУ 252149.001ПЗ
з локальним сховищем даних, забезпечуючи перевірку SQL-запитів під час
компіляції, автоматичне створення об'єктів доступу до даних (DAO) та підтримку
міграцій.
Для архітектурного поділу проєкту часто використовується патерн MVVM
(Model-View-ViewModel), що дозволяє розділити логіку представлення, бізнес-
логіку та обробку даних. Це полегшує масштабування, тестування і супровід
додатку.
У процесі впровадження залежностей ефективним інструментом є бібліотека
Inject — сучасний засіб для реалізації інверсії управління, що дозволяє зменшити
зв'язність між компонентами системи.
Щодо реалізації системи нагадувань, у мобільних додатках для Android часто
застосовується механізм push-сповіщень, що дозволяє інформувати користувача
про заплановану дію або подію навіть тоді, коли додаток неактивний.
Таким чином, сучасні інструменти для розробки мобільних додатків
забезпечують розробнику потужний набір засобів для створення ефективного,
надійного та зручного у використанні застосунку.
1.2 Методи розробки мобільних додатків
Процес розробки мобільних додатків включає в себе низку методів і підходів,
які забезпечують ефективне створення якісного програмного продукту. Вибір
методів залежить від цілей проєкту, цільової платформи, вимог до
функціональності та масштабованості додатку.
Одним з найпоширеніших підходів є нативна розробка, при якій
використовується мова та інструменти, офіційно підтримувані платформою. У
випадку Android-додатків — це мова Kotlin та середовище Android Studio. Нативна
розробка дозволяє повністю використовувати можливості пристрою, оптимізувати
продуктивність та створити інтерфейс, максимально адаптований до стандартів
платформи.
Іншим підходом є кросплатформна розробка, яка дозволяє створювати один
код для декількох платформ (наприклад, Android та iOS). Серед популярних
інструментів для цього — Flutter, React Native, Xamarin. Проте цей підхід частіше
16
ЧДТУ 252149.001ПЗ
використовується для додатків з простішим функціоналом або коли важливо
скоротити час і вартість розробки.
Щодо архітектурних підходів, в сучасній Android-розробці широке
застосування має архітектура MVVM (Model-View-ViewModel). Вона дозволяє
чітко розділити логіку взаємодії з даними, логіку відображення та представлення
інтерфейсу. Такий підхід підвищує гнучкість і тестованість коду.
Для локального зберігання даних використовуються реляційні бази даних,
зокрема Room, яка є частиною Android Jetpack. Вона дозволяє легко зберігати
об'єкти Kotlin у вигляді таблиць SQLite без необхідності написання великої
кількості шаблонного коду.
Управління залежностями реалізується за допомогою бібліотек на кшталт
Inject, що підтримує принцип інверсії управління (IoC) та дозволяє зменшити
зв’язаність компонентів, підвищуючи масштабованість і зручність супроводу коду.
Для реалізації сповіщень та нагадувань у додатку використовуються Push-
повідомлення, які можуть бути реалізовані через Notification API Android або
сторонні сервіси, такі як Firebase Cloud Messaging (FCM), залежно від вимог
проєкту.
Таким чином, вибір методу розробки залежить від технічних вимог і бізнес-
цілей. У даній роботі було обрано нативну розробку з використанням Kotlin, Room,
MVVM та Inject як оптимальне рішення для реалізації мобільного додатку для
трекінгу звичок.
1.3 Порівняльний аналіз існуючих аналогів
Для створення ефективного та конкурентоспроможного мобільного трекера
звичок було проведено аналіз популярних додатків, які вже існують на ринку. Це
дозволяє визначити сильні сторони, виявити недоліки та сформувати вимоги до
власного продукту.
17
ЧДТУ 252149.001ПЗ
Таблиця 1.1
Порівняння існуючич рішень
Назва
Платформа Основні функції Переваги Недоліки
додатку
Надлишкова
Гейміфікація звичок, складність
Android, iOS, Висока мотивація,
Habitica система нагород, інтерфейсу, не
Web цікаве оформлення
соціальна взаємодія підходить для
мінімалістів
Відсутність
Відстеження звичок, Простість,
Loop Habit нагадувань та
Android графіки, статистика, без відкритий код,
Tracker синхронізації між
реклами офлайн-режим
пристроями
Персоналізовані плани, Психологічно Частина функцій —
Fabulous Android, iOS
поради, красивий дизайн мотивуючий підхід лише в платній версії
Календар, категорії Гнучкі Деякі функції
HabitNow Android звичок, нагадування, налаштування, доступні лише у Pro-
статистика нагадування версії
Встановлення цілей,
Тільки для iOS,
кольорові графіки, Інтуїтивний
Done iOS обмеження у
підтримка декількох інтерфейс
безкоштовній версії
цілей
На основі проведеного аналізу можна зробити наступні висновки:
Користувачі цінують простоту, гнучкість налаштувань, наявність нагадувань
та зрозумілу статистику.
Додатки з гейміфікацією (наприклад, Habitica) можуть мотивувати, але
підходять не всім через складність.
Більшість аналогів мають обмеження у функціональності без підписки або
платної версії.
У зв’язку з цим, розроблений трекер звичок орієнтується на інтуїтивний
інтерфейс, базову функціональність без реклами, можливість відстеження
декількох звичок одночасно, а також підтримку нагадувань і зручну візуалізацію
прогресу. Основний акцент зроблено на ефективності та простоті використання, що
робить додаток привабливим для широкого кола користувачів.
1.4 Постановка задачі
18
ЧДТУ 252149.001ПЗ
У сучасному ритмі життя дедалі більшої актуальності набуває питання
особистої ефективності та саморозвитку. Формування та підтримка корисних
звичок є важливою складовою цього процесу. Однак без належного інструменту
для контролю та моніторингу звичок досягнення поставлених цілей може бути
складним. У зв’язку з цим виникає потреба у створенні зручного, надійного та
функціонального мобільного додатку для трекінгу звичок.
Метою даної бакалаврської роботи є розробка мобільного додатку для
Android, який дозволяє користувачам створювати, редагувати, видаляти та
переглядати звички, а також отримувати push-нагадування та переглядати
статистику виконання. Додаток має бути інтуїтивно зрозумілим, з локальним
зберіганням даних та реалізованим за допомогою сучасних технологій.
Для досягнення поставленої мети необхідно розв’язати наступні задачі:
− провести аналіз існуючих мобільних додатків для трекінгу звичок;
− обґрунтувати вибір мови програмування, архітектури та бібліотек;
− сформувати вимоги до функціональності та інтерфейсу додатку;
− змоделювати предметну область та побудувати архітектуру програмного
забезпечення;
− реалізувати мобільний додаток з використанням Kotlin, архітектури MVVM,
бібліотек Room та Inject;
− забезпечити механізм push-нагадувань для користувача;
− протестувати систему відповідно до основних рівнів: модульного,
інтеграційного та системного тестування;
− надати приклади роботи програмного комплексу.
Результатом виконання роботи має стати повнофункціональний мобільний
додаток, готовий до використання кінцевим користувачем для ефективного
формування та підтримки корисних звичок.
19
ЧДТУ 252149.001ПЗ
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ
У першому розділі було проведено аналіз сучасних платформ та фреймворків
для розробки мобільних додатків, розглянуто основні методи створення
застосунків, зокрема нативний підхід з використанням мови Kotlin, архітектури
MVVM та бібліотек Room і Inject. Здійснено порівняльний аналіз популярних
аналогів мобільних додатків для трекінгу звичок, таких як Habitica, Loop, Fabulous
та HabitBull.
На основі аналізу сформульовано основну мету та задачі дослідження, а
також обґрунтовано доцільність розробки власного рішення — мінімалістичного та
зручного мобільного додатку, орієнтованого на користувача, з базовими функціями
керування звичками, нагадуваннями та переглядом статистики. Одержані
результати покладено в основу наступного етапу — моделювання, проєктування та
реалізації програмного забезпечення.
20
ЧДТУ 252149.001ПЗ
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ
2.1 Моделювання предметної області
Моделювання предметної області ґрунтується на виділенні ключових
елементів, що відображають структуру і логіку роботи мобільного додатку для
трекінгу звичок. До основних елементів моделі належать об'єкти, їхні атрибути,
взаємозв’язки та функції, які вони виконують у системі.
Основні елементи моделі предметної області:
1 Користувач
Атрибути: ID (внутрішній ідентифікатор), ім’я (опціонально).
Функції: створює, редагує, видаляє звички; переглядає статистику; отримує
нагадування.
2 Звичка
Атрибути: ID, назва, опис, дата створення, періодичність (щоденно, через
день, у певні дні), пріоритет, колір/іконка, статус (активна/неактивна).
Функції: створення, редагування, видалення, відмітка про виконання.
3 Виконання звички
Атрибути: ID, дата виконання, звичка_ID.
Функції: фіксація дати виконання звички користувачем.
4 Нагадування
Атрибути: ID, час нагадування, звичка_ID, активність (увімкнено/вимкнено).
Функції: надсилання push-повідомлень у зазначений час.
5 Статистика
Атрибути: кількість виконань, кількість пропусків, відсоток успішності, серії
днів поспіль.
Функції: надання користувачу візуального аналізу прогресу у вигляді
графіків або списків.
6 Локальна база даних (Room)
− Служить для збереження усіх об’єктів: звичок, виконань, нагадувань.
21
ЧДТУ 252149.001ПЗ
− Забезпечує цілісність та доступність даних у режимі офлайн.
Зв’язки між елементами:
− Один користувач має багато звичок.
− Одна звичка може мати кілька виконань та нагадувань.
− Кожне нагадування належить до однієї звички.
− Статистика генерується на основі виконань звичок.
Таким чином, усі елементи моделі предметної області тісно пов’язані між
собою та утворюють логічну основу, що забезпечує повноцінну функціональність
додатку.
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області
Предметна область моделювання охоплює процеси, пов’язані з
формуванням, збереженням, аналізом і вдосконаленням щоденних звичок
користувача за допомогою мобільного додатку. Основна мета системи —
забезпечити користувача інструментом, який дозволяє створювати список звичок,
щодня відмічати їх виконання, переглядати статистику та отримувати нагадування
для підвищення самодисципліни.
− реєстрація користувачів: процес, що передбачає введення таких даних, як
ім'я, електронна адреса, пароль та, за бажанням, цілі користувача. Це забезпечує
створення унікального профілю для кожного користувача в системі;
− створення звичок: функція, що дозволяє користувачам додавати нові
звички, вказуючи їхню назву, частоту, час виконання та нагадування. Це допомагає
структурувати цілі користувача;
− відстеження прогресу: можливість для користувачів відзначати виконані
звички, переглядати статистику, графіки прогресу та аналізувати виконання за
днями, тижнями чи місяцями;
− нагадування та мотивація: функція, яка надсилає нагадування про звички
та надає мотиваційні повідомлення для підтримки активності користувача;
22
ЧДТУ 252149.001ПЗ
− соціальна інтеграція: можливість ділитися прогресом із друзями чи в
соціальних мережах, що сприяє соціальній підтримці та взаємній мотивації.
Модель предметної області
Моделювання предметної області для мобільного додатка для трекінгу
звичок охоплює всі аспекти, що сприяють формуванню та підтримці корисних
звичок, з метою покращення організації часу та мотивації користувачів. Основні
компоненти предметної області включають:
1 Створення звичок
Функція, що дозволяє користувачам додавати нові звички, включає:
− Назву звички: коротке визначення.
− Частоту: щодня, щотижня тощо.
− Час виконання: конкретний час для нагадування.
− Нотатки: додаткова інформація щодо звички.
2 Відстеження прогресу
Ця функція дозволяє користувачам моніторити свої досягнення,
включаючи:
− Динаміка виконання: графіки та статистика.
− Історія: виконані та пропущені дні.
3 Нагадування
Функція, що забезпечує своєчасне інформування користувача, включає:
− Налаштовувані сповіщення: нагадування про виконання звичок.
Схема моделі предметної області
1 Дані про звички:
− Назва.
− Частота.
− Час виконання.
− Статус виконання (завершено/пропущено).
2 Дані про прогрес:
− Статистика успішності.
− Графіки та звіти.
23
ЧДТУ 252149.001ПЗ
3 Сповіщення:
− Нагадування.
Переваги моделювання предметної області
− Відповідність потребам користувачів: урахування всіх необхідних
функцій для зручності роботи з додатком.
− Оптимізація розробки: чітке розуміння структури дозволяє уникати
помилок і спрощує реалізацію.
− Можливість розширення: моделі забезпечують гнучкість для подальшого
вдосконалення додатка.
Словник предметної області:
1 Користувач - фізична особа, яка використовує додаток для
створення, відстеження та аналізу звичок.
2 Звичка - дія або діяльність, яку користувач прагне регулярно
виконувати для досягнення особистих цілей.
3 Сповіщення (нагадування) - повідомлення, що надсилається
додатком, щоб нагадати користувачу про виконання запланованої звички.
4 Прогрес звички - дані про виконання або невиконання звички
за певний період, представлені у вигляді статистики чи графіків.
5 Частота виконання - встановлений інтервал часу (щодня,
щотижня, тощо), з яким користувач планує виконувати звичку.
6 Статистика - аналітичні дані про ефективність виконання
звичок, представлені у вигляді таблиць, графіків або відсотків.
7 Чекін (відмітка) - процес підтвердження виконання звички в
додатку.
8 Історія звичок - архів виконаних та пропущених звичок
користувача за весь час використання додатка.
9 Мета - глобальна ціль, досягнення якої сприяють регулярні
виконання звичок.
10 Календар виконання - візуальне представлення графіка
виконання звичок за місяць чи інший обраний період.
24
ЧДТУ 252149.001ПЗ
11 Налаштування звички - процес редагування параметрів
звички, таких як назва, частота, час, нагадування та примітки.
12 Додаток - програмне забезпечення для мобільних пристроїв,
призначене для автоматизації процесу трекінгу звичок.
2.1.2 Елементи моделювання предметної області
У процесі моделювання предметної області для мобільного додатку для
трекінгу звичок ми будемо використовувати різні елементи UML (Unified Modeling
Language), які допоможуть наочно представити структуру та функціональність
системи. Основні елементи UML, які ми будемо використовувати, включають
класи, атрибути, операції, асоціації та діаграми класів [16].
Рисунок 2.1 – Основні графічні символи UML
25
ЧДТУ 252149.001ПЗ
Для моделювання предметної області додатку для трекінгу звичок ми будемо
використовувати діаграми UML (Unified Modeling Language), які є стандартним
засобом для візуалізації, специфікації, конструювання та документування
артефактів програмних систем. Основні елементи моделювання UML, що
використовуються для опису предметної області, включають класи, об'єкти,
атрибути, методи, асоціації, та різні типи діаграм.
Рисунок 2.2 – Єднальні елементи UML
Елементи моделювання предметної області за допомогою UML включають
класи, об'єкти, атрибути, методи, асоціації та різні типи діаграм. Використання
UML для моделювання системи дозволяє створити наочну та зрозумілу структуру
системи, що забезпечує ефективну комунікацію між розробниками та іншими
зацікавленими сторонами проекту, а також полегшує процес проектування,
реалізації та тестування програмного забезпечення [17].
26
ЧДТУ 252149.001ПЗ
2.1.3 Робоча область моделювання
Робоча область моделювання охоплює процеси, методи та інструменти, які
використовуються для побудови логічної та функціональної структури системи, а
також візуалізації її основних компонентів. У рамках створення мобільного
додатку для трекінгу звичок основну увагу було зосереджено на точному
формуванні взаємозв’язків між об’єктами системи та забезпеченні зручної і
масштабованої архітектури.
Для моделювання було використано наступні підходи:
− Об’єктно-орієнтоване моделювання, яке дозволяє подати систему як
сукупність об’єктів із певними атрибутами та методами.
− UML-діаграми, зокрема: діаграма класів, прецедентів, діяльності,
послідовності, компонентів та інші, що надають різні точки зору на систему
(структурну, функціональну, динамічну).
− Використання архітектурного патерна MVVM, що чітко розділяє рівні
представлення (View), логіки (ViewModel) і даних (Model), забезпечуючи гнучкість
і розширюваність коду.
− Інструменти моделювання, як-от StarUML або аналогічні засоби, що
використовуються для побудови UML-діаграм та структурування інформації.
У межах робочої області було також сформовано та задокументовано:
− основні сутності (звичка, нагадування, виконання, користувач);
− їх атрибути, методи та зв’язки;
− сценарії взаємодії користувача із системою;
− підходи до обробки даних (локальне зберігання за допомогою Room).
Робоча область моделювання заклала фундамент для проектування і
реалізації програмного забезпечення, а також сприяла зниженню ризиків у процесі
розробки завдяки наочному представленню структури та поведінки майбутньої
системи.
27
ЧДТУ 252149.001ПЗ
Рисунок 2.3 – Модель предметної області
Основні компоненти
1 Користувач:
2 Звичка:
3 Виконання звички:
4 Статистика:
5 Нагадування
2.2 Формування та аналіз вимог
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
Формування вимог — один із ключових етапів проєктування програмного
забезпечення, який визначає основні очікування користувачів, замовників і
розробників щодо функціональності, надійності та зручності продукту. У контексті
мобільного додатку для трекінгу звичок були виділені первинні, детальні,
функціональні та нефункціональні вимоги.
1 Первинні вимоги (на рівні замовника):
28
ЧДТУ 252149.001ПЗ
− Можливість створення, редагування та видалення звичок;
− Функція щоденного відмічання виконаних звичок;
− Нагадування про виконання звичок;
− Відображення статистики успішності;
− Робота додатку в офлайн-режимі.
2 Детальні вимоги (на рівні розробника):
− Реалізація локальної бази даних Room для зберігання інформації про звички
та їх виконання;
− Структурування додатку за архітектурною моделлю MVVM;
− Використання бібліотеки Inject для впровадження залежностей;
− Забезпечення роботи push-нагадувань на основі системного планувальника
Android;
− Реалізація зручного інтерфейсу користувача згідно з принципами Material
Design.
3 Вимоги замовника:
− Простота використання;
− Стабільна робота без підключення до Інтернету;
− Мінімалістичний інтерфейс;
− Збереження конфіденційності користувацьких даних.
4 Вимоги розробника:
− Модульність і розширюваність коду;
− Застосування сучасних практик Android-розробки;
− Можливість масштабування функціоналу в майбутньому (наприклад, хмарна
синхронізація).
5 Функціональні вимоги:
− Створення, редагування, видалення звичок;
− Додавання часу для нагадування;
− Відмітка про виконання звички;
− Перегляд історії виконання;
− Генерація статистики у вигляді графіків або списків;
29
ЧДТУ 252149.001ПЗ
− Відображення push-нагадувань.
6 Нефункціональні вимоги:
− Зручний, інтуїтивно зрозумілий інтерфейс;
− Висока продуктивність на середньостатистичних Android-пристроях;
− Сумісність з Android версії 8.0 (Oreo) і вище;
− Низьке споживання ресурсів (батареї та пам’яті);
− Захищене збереження локальних даних.
Таким чином, чітке визначення вимог забезпечує узгоджене бачення між
розробником і користувачем, та є основою для подальшого моделювання, реалізації
і тестування додатку.
2.2.2 Формування вимог за допомогою діаграми прецедентів
Діаграма прецедентів (Use Case Diagram) дозволяє візуалізувати взаємодію
користувача з основними функціями системи. Вона демонструє, які дії доступні
користувачу та як система реагує на запити. Це допомагає краще структурувати
функціональні вимоги.
У випадку мобільного додатку для трекінгу звичок ключовим актором є
Користувач, який взаємодіє з наступними прецедентами:
− Створити звичку
− Редагувати звичку
− Видалити звичку
− Відмітити виконання звички
− Переглянути історію
− Отримати нагадування
− Переглянути статистику
30
ЧДТУ 252149.001ПЗ
Рисунок 2.4 – Діаграма прецедентів для додатку для трекінгу звичок
1 Створення нового користувача:
− Актор: користувач;
− Опис: користувач відкриває додаток та проходить первинну реєстрацію або
авторизацію. Він вводить своє ім’я, електронну адресу та пароль. Дані зберігаються
в локальній базі (Room) для подальшої ідентифікації. Після реєстрації система
переходить до головного екрану трекінгу звичок.
2 Додавання нової звички:
− Актор: користувач;
− Опис: користувач натискає кнопку "Додати звичку" та заповнює форму:
назва звички, опис, час для нагадування, повторюваність (щодня/тиждень тощо). За
31
ЧДТУ 252149.001ПЗ
потреби активується push-нагадування через вбудований сервіс. Звичка
зберігається в локальну базу через ViewModel → Repository → Room.
3 Відмітка виконання звички:
− Актор: користувач;
− Опис: щодня користувач відкриває додаток і відмічає виконання звички за
поточну дату. Система оновлює статистику (поточна серія, відсоток виконання,
загальна кількість виконань) у відповідному екрані або віджеті.
4 Перегляд статистики:
− Актор: користувач;
− Опис: користувач може переглядати детальну статистику по кожній звичці:
графік виконань, кількість пропусків, поточна та максимальна серія, успішність.
Дані формуються в реальному часі на основі локальної бази даних.
5 Налаштування нагадувань:
− Актор: користувач;
− Опис: при редагуванні або створенні звички користувач може активувати
push-нагадування, які будуть надходити у встановлений час. Нагадування
реалізуються через службу Android NotificationManager.
Діаграма прецедентів допомагає візуалізувати основні функціональні
можливості мобільного додатку та взаємодію користувача з системою. Вона
відображає ключові сценарії використання, полегшуючи подальше проектування,
розробку та тестування додатку відповідно до потреб користувача.
2.3 Проектування логічної структури програмного комплексу
У цьому підрозділі буде розглянуто проектування логічної архітектури
мобільного додатку для трекінгу звичок. Зараз ми розглянемо діаграми класів, які
показують взаємодію між різними класами та їхніми характеристиками та
методами, що дозволить нам зрозуміти структуру та поведінку об’єктів у системі.
Далі ми розглянемо діаграму пакетів, яка показує організацію класів у логічні
групи, також відомі як пакети. Це робить це, щоб визначити залежності між цими
групами, а також зробити більш простим керувати складністю системи.
32
ЧДТУ 252149.001ПЗ
2.3.1 Діаграми класів
Діаграма класів — це один з основних інструментів об’єктно-орієнтованого
моделювання, що дозволяє зобразити структуру програмного забезпечення у
вигляді класів, їх атрибутів, методів та взаємозв’язків між ними. У рамках розробки
мобільного додатку для трекінгу звичок було виділено ключові сутності системи,
що реалізовані у вигляді класів.
Основні класи:
− Habit: містить інформацію про назву, опис, колір, частоту, активність.
− HabitExecution: зберігає дати виконання звички.
− Reminder: відповідає за налаштування push-нагадувань.
− Statistics: генерує дані про виконання для графіків.
− HabitRepository: забезпечує доступ до даних через Room.
− HabitViewModel: логіка обробки даних та взаємодії з UI.
− MainActivity, HabitListFragment, HabitDetailFragment: компоненти
інтерфейсу.
Зв’язки класів:
− MainActivity -> HabitViewModel: викликає методи для отримання та
оновлення даних про звички.
− CreateHabitScreen -> HabitViewModel: передає дані для створення нової
звички.
− StatisticsScreen -> StatisticsViewModel: запитує дані статистики звичок.
− HabitViewModel -> HabitRepository: здійснює CRUD (створення, читання,
оновлення, видалення) операції.
− StatisticsViewModel -> StatisticsUseCase: звертається до класу для обчислення
статистичних показників.
− HabitRepository -> HabitDao: використовує DAO для доступу до локальної
бази даних (Room).
− HabitRepository -> ReminderManager: контролює налаштування push-
нагадувань для звичок.
33
ЧДТУ 252149.001ПЗ
− HabitDao -> Room Database: виконує операції читання/запису даних у базі.
− ReminderManager -> PushNotificationService: формує та надсилає push-
нагадування.
− Habit -> HabitHistory: містить історію виконання звички (записи про дні, коли
звичку виконували).
− StatisticsUseCase -> HabitRepository: отримує дані для розрахунку статистики.
Рисунок 2.5 – Діаграма класів без атрибутів та методів для мобільного додатку
для трекінгу звичок
Заповнимо кожен з класів необхідними атрибутами та методами (рисунок
2.6), посилаючись на нижчеописані властивості класів.
Звичка (Habit):
− зберігає назву, опис, періодичність, час нагадування, статус (активна,
виконана, пропущена);
− може бути створена, оновлена, видалена;
− методи: createHabit(), editHabit(), deleteHabit(), markAsDone().
Історія звички (HabitHistory):
− зберігає дату, статус (виконано / пропущено), пов’язана зі звичкою;
− використовується для формування статистики;
− методи: recordCompletion(), getByDate(), getCurrentStreak().
− Нагадування (Reminder):
− зберігає час і тип нагадування, пов’язане зі звичкою;
− використовується для ініціації push-сповіщень;
34
ЧДТУ 252149.001ПЗ
− методи: scheduleReminder(), cancelReminder().
Статистика (Statistics):
− обчислює відсоток виконання звичок, поточну та максимальну серію;
− отримує дані з історії виконань;
− методи: calculateStreak(), calculateCompletionRate(), generateChartData().
Рисунок 2.6 – Діаграма класів для додатку для трекінгу звичок
В результаті маємо повну діаграму класів з наступними атрибутами, та
методами.
Клас Звичка
Атрибути:
− назва: String;
− опис: String;
− часНагадування: Time;
− періодичність: String;
− статус: String; // активна, виконана, пропущена
Методи:
− створити(): void;
− редагувати(): void;
− видалити(): void;
− відмітитиЯкВиконану(): void.
Клас ІсторіяЗвички
Атрибути:
35
ЧДТУ 252149.001ПЗ
− дата: Date;
− статус: String; // виконано, пропущено
− звичка: Звичка.
Методи:
− записатиВиконання(): void;
− отриматиПоДаті(дата: Date): ІсторіяЗвички.
Клас Нагадування
Атрибути:
− час: Time;
− тип: String; // push
− звичка: Звичка.
Методи:
− запланувати(): void;
− скасувати(): void.
Клас Статистика
Атрибути:
− звичка: Звичка;
− кількістьВиконань: Number;
− кількістьПропусків: Number;
Методи:
− розрахуватиПоточнуСерію(): Number;
− розрахуватиВідсотокВиконання(): Number;
− генеруватиДіаграму(): void.
Ця діаграма класів відображає об'єктно-орієнтовану модель додатку,
визначаючи сутності, їх атрибути та основні методи. Такий підхід допомагає
візуалізувати структуру мобільного додатку, спростити проєктування архітектури
системи, покращити розуміння логіки взаємодії компонентів, а також є основою
для реалізації функціональності згідно з принципами MVVM та використанням
Room бази даних.
2.3.2 Діаграма пакетів
36
ЧДТУ 252149.001ПЗ
Діаграма пакетів (Package Diagram) в UML використовується для візуалізації
модульної структури системи на високому рівні. Вона дозволяє побачити, як різні
функціональні частини системи організовані у вигляді логічних модулів (пакетів) і
як ці модулі взаємодіють один з одним.
Для мобільного додатку трекінгу звичок логічно виділити наступні основні
пакети:
− User Management: керування обліковими записами користувачів,
автентифікація, збереження профільної інформації.
− Habit Management: створення, редагування, видалення та перегляд звичок,
управління статусом виконання.
− Reminder System: створення, оновлення та видалення push-нагадувань,
інтеграція з NotificationManager.
− Statistics Module: обробка історії виконання звичок, обчислення прогресу,
поточних і максимальних серій.
− Data Access: реалізація локальної бази даних за допомогою Room, збереження
об’єктів звичок, нагадувань та історії.
37
ЧДТУ 252149.001ПЗ
Рисунок 2.7 – Діаграма пакетів для мобільного додатку для трекінгу звичок
Нижче розберемо кожний пакет діаграми пакетів (рисунок 2.7) більш
детально.
User Management
− користувач: ім’я, email, пароль, унікальний ідентифікатор;
− функціональність: реєстрація користувачів, авторизація, оновлення
профільної інформації.
Habit Management
− Звичка: назва, опис, періодичність, статус, час нагадування
− Функціональність: створення, редагування, видалення звичок, відмітка про
виконання
Reminder System
− Нагадування: тип, час, звичка
38
ЧДТУ 252149.001ПЗ
− Функціональність: створення та скасування push-нагадувань
Statistics
− Історія звички: дата, статус виконання
− Статистика: поточна серія, максимальна серія, відсоток виконання
− Функціональність: обчислення показників, генерація статистичних даних
Data Access
− HabitDao, HabitHistoryDao, ReminderDao
− Функціональність: доступ до локальної бази даних через Room
UI
− Інтерфейси для введення звичок, перегляду статистики, головного екрана
− Функціональність: взаємодія користувача з функціональністю додатку через
ViewModel
Діаграма пакетів допомагає візуалізувати організацію системи на високому
рівні, показуючи, як різні компоненти системи згруповані в логічні модулі та як
вони взаємодіють між собою. Це сприяє кращому розумінню архітектури системи
та полегшує її підтримку та розвиток.
2.4 Архітектура проектування
У цьому підрозділі ми зосередимося на вивченні архітектури мобільного
додатку для трекінгу звичок. Буде представлена діаграма компонентів, яка показує,
як різні програмні компоненти взаємодіють між собою, які інтерфейси вони
використовують та як організована їхня взаємодія. Далі буде розглянуто процес
розгортання програмної системи на апаратних засобах, що буде проілюстровано
діаграмою розгортання. Ця діаграма допоможе зрозуміти, як програмні компоненти
розміщуються на фізичних пристроях, сервери, бази даних та інші апаратні засоби,
що використовуються для підтримки функціонування системи.
2.4.1 Діаграма компонентів
Діаграма компонентів (Component Diagram) в UML використовується для
відображення структури фізичної реалізації системи. Вона показує різні
39
ЧДТУ 252149.001ПЗ
компоненти системи, їх взаємозв'язки та залежності. Компоненти можуть бути як
програмними модулями, так і апаратними елементами.
Рисунок 2.8 – Діаграма компонентів мобільного додатку для трекінгу звичок
Діаграма компонентів (рисунок 2.8) представлена нижчеописаними
компонентами, з відповідними функціями та залежностями.
Habit Management Service
Функції:
− створення, редагування, видалення та перегляд звичок;
40
ЧДТУ 252149.001ПЗ
− відмітка про виконання звички.
Залежності:
− Database Service: зберігання даних про звички.
− User Interface: для відображення звичок користувачу.
Reminder System
Функції:
− налаштування push-нагадувань для звичок;
− скасування та оновлення нагадувань.
Залежності:
− Database Service: зберігання даних нагадувань;
− User Interface: для налаштування нагадувань.
Statistics Service
Функції:
− розрахунок статистики виконання звичок (поточна та максимальна серія,
відсоток виконання);
− генерація звітів та графіків.
Залежності:
− Database Service: для зберігання історії виконання звичок та статистичних
даних;
− User Interface: для відображення статистики користувачу.
Database Service
Функції:
− зберігання всіх даних системи: користувачів, звичок, історії виконань,
нагадувань, статистики.
Залежності:
− використовується всіма сервісами для зберігання та отримання даних.
User Interface
Функції:
− взаємодія користувача з додатком, відображення інтерфейсу для створення,
редагування звичок, налаштування нагадувань, перегляду статистики.
41
ЧДТУ 252149.001ПЗ
Залежності:
− взаємодіє з усіма сервісами для отримання та відображення даних.
Notification Service
Функції:
− надсилання push-сповіщень користувачу.
Залежності:
− використовує Reminder System для активації сповіщень.
Діаграма компонентів забезпечує високорівневе представлення архітектури
мобільного додатку для трекінгу звичок, відображаючи основні функціональні
частини системи та взаємозв’язки між ними. Вона дозволяє чітко уявити, які
компоненти відповідають за окремі задачі, як, наприклад, керування звичками,
обробка нагадувань, розрахунок статистики чи зберігання даних. Такий підхід
допомагає розробникам краще зрозуміти структуру додатку, спростити розробку,
забезпечити модульність системи та полегшити її супровід і масштабування.
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Розгортання програмної системи мобільного додатку для трекінгу звичок
передбачає налаштування всіх її складових на відповідних апаратних платформах
з урахуванням продуктивності, надійності та масштабованості. Основні
компоненти системи розміщуються на клієнтських пристроях користувачів та, за
потреби, на серверній інфраструктурі.
Клієнтський пристрій
− Забезпечує інтерфейс взаємодії з користувачем, обробку локальних даних та
відображення інформації про звички, нагадування й статистику. Додаток працює
автономно з локальною базою даних Room.
Push Notification Service
− Забезпечує доставку нагадувань користувачеві. Для реалізації
використовується Android Notification Manager з WorkManager/AlarmManager.
На основі зазначених компонентів формується діаграма розгортання
(рисунок 2.9), яка відображає розміщення програмних модулів на фізичних та
42
ЧДТУ 252149.001ПЗ
віртуальних пристроях, а також взаємозв’язки між ними. Це дозволяє наочно
уявити інфраструктуру додатку для трекінгу звичок та забезпечити ефективну
підтримку і розвиток системи.
Рисунок 2.9 – Діаграма розгортання для додатку для трекінгу звичок
Діаграма розгортання (рисунок 2.9) ілюструє фізичну структуру мобільного
додатку для трекінгу звичок на Android-пристрої. Уся логіка системи реалізована в
межах мобільного застосунку, що працює локально на пристрої користувача.
Усередині додатку основну функціональність забезпечують компоненти:
− MainActivity — головний екран додатку, з якого здійснюється навігація до
інших модулів.
− HabitRepository — центральний компонент, що забезпечує доступ до даних
звичок. Взаємодіє з локальною базою даних (Room) для читання та запису
інформації.
− StatisticsActivity — екран зі статистикою, що використовує бізнес-логіку з
StatisticsUseCase.
− HabitViewModel і StatisticsViewModel — компоненти архітектури MVVM,
що відповідають за передачу даних між інтерфейсом та логікою додатку.
− Для зберігання даних використовується Room Database, а саме компонент
Habit Database, який взаємодіє з HabitRepository.
43
ЧДТУ 252149.001ПЗ
− Для реалізації системи нагадувань використовується Push Notification
Service. Повідомлення надсилаються користувачу у визначений час згідно з
графіком звичок.
Ця діаграма демонструє автономну роботу додатку без зовнішнього сервера,
з використанням локальної бази даних, що дозволяє забезпечити високу
продуктивність, незалежність від інтернет-з’єднання та зручність у користуванні.
2.5 Моделювання поведінки системи
У цьому підрозділі розглянуто динамічні аспекти функціонування
мобільного додатку для трекінгу звичок. Спочатку представлено діаграму
діяльності, яка ілюструє загальний потік виконання дій у процесі використання
додатку — від запуску інтерфейсу до запису результатів звичок та надсилання
нагадувань. Далі розглянуто діаграму послідовності, що демонструє взаємодію
об’єктів додатку в часовій послідовності під час виконання окремих сценаріїв,
таких як створення або редагування звички. Наступною представлено діаграму
комунікації, яка підкреслює структурні зв’язки між об’єктами під час виконання
конкретної функції. Завершує підрозділ діаграма скінченного автомату, яка описує
можливі стани інтерфейсу або сутності (наприклад, звички) та умови переходу між
цими станами залежно від дій користувача або внутрішніх подій. Ці діаграми
дозволяють комплексно описати поведінку системи та забезпечують основу для
реалізації й тестування логіки додатку.
2.5.1 Діаграма діяльності
Діаграма діяльності моделює алгоритм взаємодії користувача з додатком у
вигляді послідовності дій та умов. Вона дозволяє візуалізувати основний сценарій
використання додатку для трекінгу звичок — від запуску до додавання або
редагування звички.
Основна логіка:
1 Користувач відкриває додаток.
2 Відображається список звичок.
3 Користувач може:
44
ЧДТУ 252149.001ПЗ
− Додати нову звичку.
− Редагувати/видалити існуючу.
− Переглянути статистику.
4 Якщо додано або змінено звичку — оновлюється база даних.
5 При потребі — встановлюється нагадування.
Рисунок 2.10 – Діаграма діяльності для мобільного додатку для трекінгу звичок
Опис кроків діяльності, зображених на діаграмі діяльності для мобільного
додатку трекінгу звичок:
Запуск додатку:
− користувач відкриває мобільний додаток.
Перевірка збережених звичок:
− система перевіряє, чи є у користувача збережені звички.
Виведення списку звичок (якщо звички існують):
45
ЧДТУ 252149.001ПЗ
− користувач бачить список своїх звичок.
Створення нової звички (якщо звичок немає):
− користувачеві пропонується створити нову звичку;
− система переходить до екрана створення звички.
Вибір дії користувачем:
− користувач обирає одну з наступних дій: додати нову звичку, позначити
звичку як виконану, переглянути статистику або активувати нагадування.
Додавання звички:
− користувач заповнює форму створення звички;
− дані зберігаються в базі даних.
Позначення звички як виконаної:
− оновлюється статистика користувача;
− оновлюється загальний прогрес виконання звички.
Перегляд статистики:
− генерується актуальна статистика звичок;
− система відображає згенеровані статистичні дані.
Отримання нагадувань:
− запускається служба нагадувань, яка надсилає push-повідомлення у
встановлений час.
Діаграма діяльності ілюструє повний цикл взаємодії користувача з додатком
для трекінгу звичок: від запуску програми до перегляду статистики та роботи
нагадувань, що дозволяє чітко уявити логіку роботи системи.
2.5.2 Діаграма послідовності
Діаграма послідовності (рисунок 2.11) відображає типовий сценарій
використання мобільного додатку для трекінгу звичок. Вона ілюструє
послідовність взаємодії між основними компонентами системи під час виконання
таких дій користувача: запуск додатку, перевірка звичок, створення нової звички,
позначення звички як виконаної, оновлення статистики та перегляд статистичних
даних.
Опис кроків, зображених на діаграмі:
46
ЧДТУ 252149.001ПЗ
Запуск додатку
− Користувач відкриває мобільний додаток.
− MainActivity ініціалізує завантаження збережених звичок.
− HabitRepository звертається до Room Database для отримання списку звичок.
Обробка результату перевірки звичок
− Якщо звички знайдено, вони відображаються користувачу у відповідному
інтерфейсі.
− Якщо звичок немає, система пропонує створити нову звичку.
− Користувач переходить до форми створення звички.
Створення звички
− Користувач заповнює необхідні поля (назва, опис, частота, нагадування).
− Дані передаються до HabitRepository.
− HabitRepository зберігає нову звичку до Room Database.
Позначення звички як виконаної
− Користувач обирає звичку зі списку та позначає її як виконану.
− HabitRepository оновлює відповідний запис у Room Database.
− Після оновлення даних викликається StatisticsUseCase для генерації нової
статистики.
Оновлення статистики
− StatisticsUseCase обробляє нові дані та генерує статистичну інформацію.
− Отримані результати передаються до StatisticsViewModel.
− StatisticsViewModel оновлює інтерфейс StatisticsActivity, де відображається
актуальна статистика користувачу.
Виведення нагадувань
− Якщо користувач активував нагадування, Push Notification Service надсилає
відповідні сповіщення на пристрій користувача.
Узагальнена діаграма послідовності дозволяє простежити логіку виконання
основних дій в додатку, розкриваючи ключові взаємодії між компонентами та
послідовність обміну даними. Це сприяє кращому розумінню функціональної
архітектури системи та служить основою для її подальшої реалізації й підтримки.
47
ЧДТУ 252149.001ПЗ
Рисунок 2.11 – Діаграма послідовності за сценарієм «Створення нової звички» для
мобільного додатку для трекінгу звичок
Діаграма послідовності для сценарію редагування звичок допомагає
візуалізувати послідовність взаємодій між користувачем та програмою. Вона
показує, як дані передаються між різними компонентами системи під час
надсилання оголошення, що є важливим для забезпечення чіткого розуміння
процесу та успішної реалізації функціональності.
48
ЧДТУ 252149.001ПЗ
Рисунок 2.12 – Діаграма послідовності за сценарієм «Редагування наявної звички»
для мобільного додатку для трекінгу звичок
2.5.3 Діаграма комунікації
Діаграма комунікації описує поведінку системи як взаємодію об'єктів у
певному контексті, показуючи відносини між об'єктами та використовуючи
нумерацію для представлення послідовності повідомлень [24].
Опишемо послідовність дій зображених на діаграмі комунікації (рисунок
2.13) у відповідності їх нумерації для сценарію надсилання викладачем оголошень
студентам
49
ЧДТУ 252149.001ПЗ
Рисунок 2.13 – Діаграма комунікації для мобільного додатку для трекінгу звичок
Діаграма комунікації описує поведінку мобільного додатку для трекінгу
звичок як взаємодію між його основними компонентами в контексті певного
сценарію. Вона демонструє структурні зв’язки між об’єктами та використовує
нумерацію для фіксації послідовності викликів методів і обміну повідомленнями.
Опишемо послідовність дій, зображених на діаграмі комунікації (рисунок
2.13), відповідно до їхньої нумерації для сценарію оновлення даних про звичку та
створення статистики:
1 MainActivity викликає HabitRepository для оновлення даних звички,
позначеної як виконана.
50
ЧДТУ 252149.001ПЗ
2 HabitRepository зберігає нові дані до Room Database.
3 Після оновлення даних HabitRepository викликає StatisticsUseCase для
обробки статистики.
4 StatisticsUseCase формує оновлену статистику на основі даних з Room
Database.
5 Згенеровані статистичні дані передаються до StatisticsViewModel.
6 StatisticsViewModel ініціює оновлення інтерфейсу у StatisticsActivity
для відображення результатів користувачу.
7 Паралельно, якщо активовані нагадування, MainActivity активує Push
Notification для надсилання повідомлень користувачу.
Діаграма комунікації дозволяє простежити взаємозв’язки між об’єктами
мобільного додатку та визначити точний порядок взаємодії між ними в рамках
реалізації конкретної функціональності системи.
2.5.4 Діаграма скінченного автомату
Діаграма скінченного автомату (діаграма станів) використовується для
моделювання поведінки мобільного додатку для трекінгу звичок, що змінює свій
стан у відповідь на дії користувача або внутрішні події системи. Нижче наведено
діаграму станів (рисунок 2.14), яка відображає переходи між основними станами
інтерфейсу додатку залежно від взаємодії користувача.
Рисунок 2.14 – Діаграма скінченного автомату для мобільного додатку для
трекінгу звичок
51
ЧДТУ 252149.001ПЗ
Опис станів діаграми скінченного автомату, що зображує життєвий цикл
звички в мобільному додатку для трекінгу звичок:
Нова_звичка
− початковий стан, в якому перебуває нова звичка до моменту її збереження
− користувач вводить необхідні дані
Активна
− основний стан звички після її створення
− в цьому стані можливі переходи до інших станів залежно від дій користувача
або подій системи
Виконана
− звичка переходить у цей стан, коли користувач позначає її як виконану за
поточний день
− можливий повернення до стану Активна, якщо користувач скасовує відмітку
про виконання
Пропущена
− звичка вважається пропущеною, якщо день завершився, а звичка не була
позначена як виконана
− після настання нового дня звичка автоматично переходить назад у стан
Активна
Редагується
− тимчасовий стан, у який переходить звичка при зміні її параметрів
− після збереження змін повертається в стан Активна
Видалена
− кінцевий стан, у який переходить звичка, якщо користувач її видаляє з
додатку
− з цього стану повернення до інших не передбачено
Ця діаграма відображає логіку зміни станів звички у додатку, демонструючи,
як події (виконання, пропуск, редагування, видалення) впливають на життєвий
цикл звички, забезпечуючи контроль, гнучкість та зручність для користувача.
52
ЧДТУ 252149.001ПЗ
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ
У даному розділі проведено комплексний аналіз методів та засобів реалізації
мобільного додатку для трекінгу звичок, створеного в межах кваліфікаційної
роботи. На основі аналізу було сформовано низку діаграм, що відображають
архітектуру, логіку, функціональність і поведінку системи.
Сформовано функціональні та нефункціональні вимоги, що визначили цілі
додатку — забезпечити зручне створення, відстеження та статистичний аналіз
звичок користувача із підтримкою локального зберігання та нагадувань.
Діаграма прецедентів відобразила основні сценарії взаємодії користувача з
додатком: створення звички, відзначення виконання, перегляд статистики,
отримання нагадувань.
Діаграма класів продемонструвала структуру додатку, включаючи сутності
Habit, Statistics, Reminder, їх атрибути та зв’язки між ними, що стало основою для
реалізації в моделі Room database.
Діаграма пакетів дозволила побачити розподіл логіки на функціональні
модулі — збереження даних, взаємодія з користувачем, генерація статистики,
нагадування — та їх організацію в межах архітектури MVVM.
Діаграма компонентів деталізувала, як окремі компоненти додатку
(MainActivity, ViewModel, UseCase, Repository, Room database) взаємодіють між
собою, забезпечуючи виконання функцій додатку.
Діаграма розгортання показала розміщення логіки додатку на Android-
пристрої, окреме підключення до Firebase для надсилання push-нотифікацій та
локальне збереження даних у Room Database.
Діаграма діяльності ілюструвала логіку роботи користувача з додатком —
починаючи з перевірки збережених звичок, створення нових, відзначення
виконання, перегляду статистики, до запуску нагадувань.
Діаграма послідовності об’єднала сценарії взаємодії користувача з додатком:
додавання нової звички, її виконання, та запит статистики, демонструючи порядок
обміну повідомленнями між компонентами.
53
ЧДТУ 252149.001ПЗ
Діаграма комунікації показала взаємодію основних компонентів додатку у
контексті запиту статистики користувачем, включаючи виклики методів між
об’єктами ViewModel, UseCase, Repository та базою даних.
Діаграма станів описала життєвий цикл звички — від створення до
завершення чи видалення, включаючи проміжні стани: активна, виконана,
пропущена, редагується.
У сукупності, ці діаграми дозволили повно і послідовно відобразити
архітектуру, логіку та поведінку мобільного додатку для трекінгу звичок, що
забезпечує підґрунтя для його подальшої підтримки, тестування та розширення.
54
ЧДТУ 252149.001ПЗ
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1 Розробка програмного комплексу
У цьому підрозділі ми детально опишемо процес створення додатку для
трекінгу звичок. Тим самим створимо повне уявлення про процес розробки
додатку, від вибору технологій до реалізації функціональності та інтеграції
компонентів, забезпечуючи чітке розуміння кожного етапу розробки.
3.1.1 Обґрунтування вибору засобів реалізації
Для реалізації мобільного додатку для трекінгу звичок було обрано
платформу Android та мову програмування Kotlin, що є офіційною мовою розробки
Android-додатків та підтримується безпосередньо компанією Google. Kotlin
забезпечує лаконічний синтаксис, високу безпеку типів та зручну інтеграцію з
бібліотеками Android Jetpack.
У якості архітектурного підходу застосовано MVVM (Model-View-
ViewModel), що дозволяє чітко розділити відповідальність між інтерфейсом
користувача, логікою та джерелами даних, підвищуючи масштабованість та
тестованість додатку.
Для реалізації роботи з базою даних використано бібліотеку Room, яка
забезпечує зручну підтримку потоків, LiveData та автоматичну генерацію запитів,
що підвищує продуктивність розробки.
Бібліотека Inject використовується для реалізації впровадження залежностей
(Dependency Injection), що дозволяє уникати жорстких зв’язків між класами та
сприяє легшому тестуванню та масштабуванню коду.
Для реалізації нагадувань застосовано push-повідомлення з використанням
стандартного механізму Android Notification Manager, що дозволяє інформувати
користувача про необхідність виконання звички у визначений час.
Такий набір технологій та бібліотек було обрано з урахуванням їхньої
популярності, підтримки, активного розвитку та відповідності завданням проєкту.
55
ЧДТУ 252149.001ПЗ
3.1.2 Опис структурної (функціональної) схеми
Структурна (функціональна) схема мобільного додатку для трекінгу звичок
відображає основні компоненти системи та взаємозв’язки між ними. Вона дозволяє
візуалізувати функціональні блоки додатку та процеси, що виконуються при роботі
користувача з системою.
56
ЧДТУ 252149.001ПЗ
Рисунок 3.1 – Структурна (функціональна) схема для мобільного додатку
для трекінгу звичок
Основні функціональні блоки:
Інтерфейс користувача (UI)
− Забезпечує взаємодію з користувачем: створення, перегляд, редагування та
видалення звичок, перегляд статистики, налаштування нагадувань.
ViewModel
− Проміжна ланка між UI та бізнес-логікою. Обробляє події інтерфейсу,
формує стани для відображення, взаємодіє з репозиторіями.
Бізнес-логіка (Use Cases / Interactors)
− Містить логіку обробки даних — створення звички, підрахунок статистики,
генерація сповіщень, визначення статусу звички (виконано/пропущено).
Репозиторії (Repositories)
− Служать для абстрагування джерела даних: локальна база даних (Room),
системні API, ресурси.
База даних (Room)
− Зберігає інформацію про звички, історію відміток, параметри користувача
тощо.
Менеджер сповіщень (Notification Manager)
− Відповідає за створення та показ push-нагадувань у відповідний час згідно з
розкладом.
Взаємодія між компонентами:
1 Користувач виконує дію в UI (наприклад, додає звичку).
2 ViewModel передає запит у бізнес-логіку.
3 Бізнес-логіка звертається до репозиторію для збереження даних у базі.
4 Після збереження оновлена інформація повертається до ViewModel.
5 ViewModel оновлює UI.
6 Паралельно налаштовується сповіщення через Notification Manager.
Ця схема реалізована з дотриманням принципів чистої архітектури, що
забезпечує модульність, гнучкість та можливість масштабування проєкту.
57
ЧДТУ 252149.001ПЗ
3.1.3 Опис логічної схеми
Логічна схема мобільного додатку для трекінгу звичок відображає
внутрішню структуру даних та взаємозв’язки між основними сутностями, які
використовуються у програмному забезпеченні. Вона є основою для проєктування
бази даних та формування бізнес-логіки.
Рисунок 3.2 – Логічна схема для мобільного додатку для трекінгу звичок
Алгоритм функціонування мобільного додатку для трекінгу звичок
Запуск додатку:
− користувач відкриває мобільний застосунок
58
ЧДТУ 252149.001ПЗ
− додаток перевіряє наявність збережених звичок у локальній базі даних
Room Database
− виводиться список звичок
Створення нової звички:
− користувач переходить до форми створення звички
− заповнює необхідні дані назва частота виконання час нагадування
− натискає кнопку збереження
− звичка зберігається у локальній базі даних
Відображення та взаємодія з наявними звичками:
− користувачу на головному екрані виводиться список активних звичок
− додати нову звичку
− позначити звичку як виконану
− переглянути статистику
− редагувати або видалити звичку
Позначення звички як виконаної:
− користувач відзначає виконання звички за поточний день
− оновлюється відповідна інформація у локальній базі даних
− обчислюється та оновлюється статистика виконання
Перегляд статистики
− користувач обирає опцію перегляду статистики
− додаток викликає відповідний use case що зчитує дані з бази
− генерується зведена інформація про дні виконання або пропуску
− статистика відображається у вигляді графіка або текстової інформації
Нагадування:
− після створення звички з часом виконання запускається служба
нагадувань
− користувач отримує сповіщення у визначений час
Редагування або видалення звички
− користувач переходить до редагування певної звички
− змінює параметри або видаляє її повністю
59
ЧДТУ 252149.001ПЗ
− зміни зберігаються у базі або запис видаляється
Алгоритм функціонування мобільного застосунку для трекінгу звичок
охоплює ключові взаємодії користувача з системою створення виконання
відстеження та управління звичками Логіка реалізована відповідно до архітектури
MVVM із використанням Room для збереження даних і Firebase для надсилання
нагадувань Блок схема яка відображає ці етапи забезпечує наочне розуміння логіки
функціонування застосунку та послідовності виконання дій
3.1.4 Розробка бази даних
Для зберігання даних у мобільному додатку для трекінгу звичок було
використано Room — офіційну бібліотеку Android Jetpack для роботи з базами
даних. Вона забезпечує зручний інтерфейс доступу до SQLite через анотації та
дозволяє автоматично генерувати SQL-запити, значно спрощуючи розробку.
DAO-інтерфейси
Для кожної сутності створено DAO (Data Access Object), що дозволяє
виконувати запити до відповідної таблиці:
‒ HabitDao — створення, оновлення, видалення звичок, отримання активних
звичок.
‒ HabitCheckDao — додавання відміток виконання, отримання статистики за
звичкою.
‒ UserSettingsDao — зчитування та оновлення налаштувань користувача.
Таким чином, реалізована база даних забезпечує надійне та ефективне
зберігання інформації, з можливістю масштабування та інтеграції з іншими
компонентами програми.
60
ЧДТУ 252149.001ПЗ
Рисунок 3.4 – Схема бази даних мобільного додатку для трекінгу звичок
3.1.5 Розробка інтерфейсу користувача
Розробка інтерфейсу користувача мобільного додатку для трекінгу звичок є
важливим етапом реалізації системи, оскільки саме через інтерфейс відбувається
взаємодія користувача з основними функціями додатку. Ефективність
використання додатку напряму залежить від логіки, доступності та простоти
побудови меню, повідомлень і взаємодій.
Вимоги до інтерфейсу користувача:
1 Зручність використання.
Користувач повинен мати змогу швидко зорієнтуватися в функціях додатку
без потреби в додатковому навчанні. Меню та команди повинні бути
згруповані логічно, а повідомлення додатку — чіткими та зрозумілими.
2 Доступність.
Інтерфейс має бути доступним на різних пристроях і не містити складних
елементів, які не підтримуються на платформі. Всі функції повинні бути
однаково зручними для користувачів з різним рівнем технічної підготовки,
забезпечуючи універсальний досвід.
61
ЧДТУ 252149.001ПЗ
3 Функціональність.
Інтерфейс повинен надавати доступ до основних функцій системи:
реєстрація користувачів, створення та відстеження звичок, налаштування
нагадувань, перегляд прогресу. Кожна з цих функцій повинна мати окремі
екрани або розділи з чіткими інструкціями та кроками введення даних.
Проектування інтерфейсу включає:
‒ Структуру головного меню. Головне меню повинно бути простим і
інтуїтивно зрозумілим, дозволяючи користувачу легко переходити до
основних функцій додатку, таких як створення звичок, перегляд
статистики, налаштування профілю.
‒ Команди користувача. Всі команди повинні бути чітко визначені і
легко доступні. Наприклад, кнопки для додавання нових звичок,
налаштування нагадувань або перегляду звітів.
‒ Послідовності діалогів та формат повідомлень. Діалоги повинні бути
простими і лаконічними, кожен крок — зрозумілим для користувача.
Наприклад, при створенні звички користувачеві потрібно буде лише
ввести її назву, вибрати тип (наприклад, щодня, щотижня) та час
нагадування.
Було враховано потребу в однаковій логіці побудови сценаріїв як для
новачків, так і для досвідчених користувачів, що забезпечує уніфікований підхід до
навігації в додатку.
62
ЧДТУ 252149.001ПЗ
Рисунок 3.5 – Головний екран додатку
У результаті розроблено інтерфейс для мобільного додатку для трекінгу
звичок, який використовує стандартні елементи користувацького інтерфейсу:
текстові повідомлення, кнопки швидкого вибору, спливаючі підказки та запити для
підтвердження або повторного введення даних. Це дозволяє значно скоротити
кількість помилок при використанні та полегшує взаємодію з додатком.
3.1.6 Опис розробки програмних компонентів
Розробка програмних компонентів мобільного додатка для трекінгу звичок,
створеного в межах дипломної роботи на тему «Мобільний додаток для трекінгу
звичок», передбачає проєктування модулів, кожен з яких реалізує окрему
функціональність системи. Компоненти реалізовані з урахуванням архітектурного
підходу MVVM, що забезпечує чітке розділення відповідальностей,
підтримуваність та зручність розширення проєкту. Нижче наведено опис основних
компонентів мобільного застосунку.
1 Компонент створення та реєстрації звичок
‒ Призначення: забезпечує можливість користувачу створювати нові звички з
визначенням їх назви, опису, частоти повторення, часу нагадування.
63
ЧДТУ 252149.001ПЗ
‒ Реалізація: у ViewModel обробляється логіка створення звички, дані
зберігаються у локальну базу даних Room за допомогою відповідного DAO-
інтерфейсу та entity-моделі HabitEntity.
2 Компонент перегляду та редагування звичок
‒ Призначення: дозволяє користувачу переглядати список наявних звичок,
змінювати їх або видаляти.
‒ Реалізація: реалізовано адаптер для RecyclerView, що відображає список
звичок, кожен елемент має доступ до функцій редагування. ViewModel
забезпечує доступ до бази даних та оновлення UI.
3 Компонент нагадувань
‒ Призначення: реалізує нагадування користувачу про необхідність виконання
звички у встановлений час.
‒ Реалізація: використано Android AlarmManager для планування сповіщень.
Повідомлення формуються системою через NotificationManager у
встановлений час, відповідно до параметрів, заданих при створенні звички.
4 Компонент статистики та відстеження прогресу
‒ Призначення: показує користувачу динаміку виконання звичок за обраний
період.
‒ Реалізація: збір інформації про виконання фіксується у базі даних. Дані
аналізуються у ViewModel і відображаються через графічні елементи
(наприклад, гістограми або лінійні графіки).
5 Компонент керування базою даних
‒ Призначення: забезпечує взаємодію між ViewModel та локальним сховищем
(Room).
‒ Реалізація: реалізовано Room Database, DAO-інтерфейси для кожного типу
даних (звички, виконання, налаштування). Схеми таблиць створені у вигляді
Kotlin data-класів з анотаціями Room.
6 Компонент інтерфейсу користувача
‒ Призначення: надає доступ до всіх функцій додатку через зручний UI.
‒ Реалізація: для кожного фрагменту (створення звички, список звичок,
налаштування, статистика) створено окремий layout-файл.
64
ЧДТУ 252149.001ПЗ
Усі компоненти взаємодіють через ViewModel та LiveData, що дозволяє
забезпечити реактивну взаємодію між шаром UI та логікою програми. Така
структура реалізації забезпечує модульність, зручність масштабування та
підтримки мобільного додатку.
3.2 Тестування системи
У цьому розділі буде описано процес перевірки мобільного додатку для
трекінгу звичок на різних рівнях для забезпечення його коректної роботи та
відповідності вимогам. Модульне тестування включатиме перевірку окремих
функцій та методів кожного компонента додатку в ізоляції. Інтеграційне
тестування зосереджуватиметься на взаємодії між модулями, щоб переконатися,
що всі частини системи працюють разом належним чином. Системне тестування
охоплюватиме перевірку всієї системи як єдиного цілого, включаючи всі
функціональні можливості додатку, щоб забезпечити стабільність і відповідність
вимогам. Нарешті, приймальне тестування буде проведено для підтвердження того,
що додаток відповідає очікуванням кінцевих користувачів і готовий до
впровадження.
3.2.1 Модульне тестування
Модульне тестування є першим етапом тестування в процесі забезпечення
якості програмного забезпечення, під час якого перевіряються окремі компоненти
системи в ізоляції. Метою модульного тестування є виявлення помилок у
функціональності окремих модулів до їх інтеграції в загальну систему. Для
мобільного додатку для трекінгу звичок буде проведено модульне тестування з
використанням інструментів JUnit та Mockito для середовища Android, що
забезпечує зручне середовище для написання і виконання тестів.
Основні кроки:
1 Налаштування середовища тестування:
‒ Встановлення JUnit та Mockito для тестування компонентів додатку.
‒ Створення тестових файлів та налаштування проекту для запуску
тестів.
65
ЧДТУ 252149.001ПЗ
2 Написання тестів:
‒ Створення тестових сценаріїв для перевірки функцій та методів
модулів, таких як реєстрація користувача, створення звичок, оновлення
прогресу, отримання нагадувань.
3 Виконання тестів:
‒ Запуск тестів у середовищі Android Studio та аналіз результатів.
‒ Виправлення знайдених помилок і повторне тестування до досягнення
стабільних результатів.
Ці кроки дозволяють забезпечити високу якість додатку, виявити потенційні
помилки на ранніх етапах розробки та підготувати систему до інтеграційного
тестування.
Результат модульного тестування
Таблиця 3.1
Тестовий Очікуваний Фактичний
Модуль Статус
випадок результат результат
Звичка Звичка
Перевірка успішно успішно
створення нової створена, створена, Успішно
звички відображаєтьс відображаєтьс
Створення
я в базі даних я в базі даних
звички
Повідомлення Повідомлення
Перевірка
про помилку, про помилку,
створення звички
назва не може назва не може Успішно
з порожнім полем
бути бути
назви
порожньою порожньою
Продовження таблиці 3.1
66
ЧДТУ 252149.001ПЗ
Перевірка Назва звички Назва звички
оновлення назви оновлюється оновлюється Успішно
звички на "Плавати" на "Плавати"
Перевірка Опис звички Опис звички
Оновлення оновлення опису оновлюється оновлюється Успішно
звички звички на новий на новий
Перевірка Повідомлення Повідомлення
оновлення звички про помилку, про помилку,
Успішно
з порожнім опис не може опис не може
значенням бути порожнім бути порожнім
Результати модульного тестування показують, що всі ключові функції
мобільного додатку для трекінгу звичок працюють коректно згідно з очікуваними
результатами. Всі тестові випадки були успішно пройдені, що свідчить про
надійність і правильність реалізації окремих модулів системи. Це забезпечує
впевненість у коректній роботі додатку при інтеграції його компонентів і
подальшому тестуванні.
3.2.2 Інтеграційне тестування
Інтеграційне тестування є наступним етапом після модульного тестування і
має на меті перевірку взаємодії між різними модулями мобільного додатку для
трекінгу звичок. У процесі інтеграційного тестування буде перевірено, як окремі
компоненти додатку працюють разом для забезпечення коректної
функціональності. Це включає перевірку взаємодії між додатком, сервісами та
базою даних.
Основні кроки інтеграційного тестування:
1 Підготовка середовища тестування:
67
ЧДТУ 252149.001ПЗ
‒ Налаштування тестового середовища, включаючи тестову базу даних
та підключення до сервісів.
‒ Ініціалізація тестових даних у базі даних для імітації реальних
сценаріїв використання додатку.
2 Визначення інтеграційних тестових сценаріїв:
Визначення сценаріїв, що включають взаємодію між різними модулями,
наприклад:
‒ Реєстрація користувача та перевірка даних у базі (коректність
збереження інформації про користувача).
‒ Створення звички і перевірка її відображення в базі даних.
‒ Взаємодія між різними частинами додатку при відображенні прогресу
користувача, синхронізація між інтерфейсом та базою даних.
3 Написання інтеграційних тестів:
‒ Написання тестів для перевірки коректності обробки даних при
взаємодії між модулями. Це включає перевірку:
‒ Синхронізації між даними, що зберігаються в локальній базі та в
інтерфейсі користувача.
‒ Перевірку на коректність відправки та отримання нагадувань.
‒ Тестування стабільності при підключенні до зовнішніх сервісів для
отримання статистики чи збереження прогресу.
4 Виконання тестів та аналіз результатів:
‒ Запуск інтеграційних тестів на різних етапах розробки додатку.
‒ Аналіз результатів тестування, виправлення помилок та повторне
тестування для забезпечення правильної інтеграції компонентів.
Ці кроки дозволяють переконатися, що всі компоненти додатку для трекінгу
звичок працюють належним чином при їх взаємодії, що сприяє успішному
функціонуванню додатку в реальних умовах.
Таблиця 3.2
Результат інтеграційного тестування
68
ЧДТУ 252149.001ПЗ
Тестовий Очікуваний Фактичний
Модуль Статус
випадок результат результат
Перевірка
Звичка
створення Звичка успішно
Створення створена та
нової звички і створена та Успішно
звички збережена в
її збереження в збережена в базі
базі даних
базі даних
Перевірка
Повідомлення Повідомлення
створення
Створення про помилку, про помилку,
звички з Успішно
звички звичка не звичка не
порожнім
створена створена
полем назви
Результати інтеграційного тестування показують, що основні функції
мобільного додатку для трекінгу звичок працюють коректно при взаємодії між
різними модулями. Всі тестові випадки були успішно пройдені, що свідчить про
правильну інтеграцію компонентів системи та їхню здатність працювати разом без
помилок. Наступним етапом буде проведення системного тестування для перевірки
всієї системи як єдиного цілого, що дозволить оцінити її стабільність та
відповідність вимогам.
3.2.3 Системне тестування
Системне тестування є наступним етапом після інтеграційного тестування і
включає перевірку всієї системи мобільного додатку для трекінгу звичок як
єдиного цілого. Метою системного тестування є перевірка того, чи відповідає
система встановленим вимогам і працює стабільно в реальних умовах експлуатації.
У процесі системного тестування будуть перевірені всі функціональні і
нефункціональні вимоги додатку, зокрема тестування на відповідність вимогам
користувачів, продуктивність, безпеку та інші важливі аспекти.
Основні кроки системного тестування:
69
ЧДТУ 252149.001ПЗ
1 Підготовка тестового середовища:
‒ Налаштування середовища, яке максимально наближене до реального,
включаючи всі компоненти системи (мобільний додаток, база даних,
зовнішні сервіси);
‒ Ініціалізація реальних даних або використання тестових даних, що
відображають реальні сценарії використання.
2 Визначення системних тестових сценаріїв:
‒ Створення та відстеження звичок;
‒ Перегляд прогресу;
‒ Отримання нагадувань.
‒ Включення нефункціональних вимог, таких як продуктивність, безпека
та масштабованість.
3 Написання тестів:
‒ Написання детальних тестових сценаріїв для перевірки коректності
виконання всіх функцій системи, включаючи взаємодію між
компонентами та роботу з базою даних.
4 Виконання тестів:
‒ Запуск тестових сценаріїв та збір результатів;
‒ Виявлення та документування помилок, аналіз результатів для
забезпечення стабільної роботи додатку в реальних умовах.
5 Аналіз результатів і виправлення помилок:
‒ Аналіз звітів про помилки, виявлених під час тестування;
‒ Виправлення помилок та повторне тестування до досягнення успішних
результатів.
Системне тестування підтверджує, що всі компоненти мобільного додатку
працюють коректно як єдине ціле, забезпечуючи відповідність системи вимогам та
її стабільну роботу. Всі тестові випадки були успішно пройдені, що свідчить про
готовність системи до експлуатації. Наступним етапом буде проведення
приймального тестування для підтвердження відповідності системи очікуванням
кінцевих користувачів.
70
ЧДТУ 252149.001ПЗ
Таблиця 3.3
Результат системного тестування
Тестовий Очікуваний Фактичний
Модуль Статус
випадок результат результат
Інтерфейс
Перевірка простий для
Інтерфейс
Інтерфейс зручності та користування,
зручний та Успішно
користувача інтуїтивності зручний та
інтуїтивний
інтерфейсу інтуїтивний
Перевірка
Нагадування
відправки Нагадування
відправляється
Нагадування нагадування відправляється в Успішно
в зазначений
про виконання зазначений час
час
звички
3.2.4 Приймальне тестування
Приймальне тестування (Acceptance Testing) є заключним етапом тестування
перед впровадженням мобільного додатку для трекінгу звичок у реальну
експлуатацію. Метою цього тестування є підтвердження того, що система
відповідає очікуванням кінцевих користувачів та всім вимогам, визначеним на
етапі проектування. Приймальне тестування здійснюється з залученням реальних
користувачів, таких як студенти і викладачі, і охоплює перевірку всіх ключових
функцій додатку.
Основні кроки приймального тестування:
1 Підготовка до тестування:
71
ЧДТУ 252149.001ПЗ
‒ Визначення тестових сценаріїв, які включають реальні сценарії
використання системи, такі як створення та відстеження звичок,
отримання нагадувань, перевірка прогресу.
‒ Вибір групи користувачів для проведення тестування (наприклад,
студенти та викладачі, що будуть використовувати додаток для своїх
звичок).
2 Проведення тестування:
‒ Організація тестової сесії з користувачами.
‒ Користувачі виконують реальні завдання, використовуючи додаток,
такі як реєстрація в системі, створення звичок, перегляд прогресу,
отримання нагадувань.
‒ Збір зворотного зв'язку від користувачів щодо зручності використання
та функціональності системи, а також оцінка інтерфейсу та
продуктивності.
3 Аналіз результатів:
‒ Оцінка результатів тестування на основі зворотного зв'язку та
виконання тестових сценаріїв.
‒ Виявлення та документування будь-яких проблем або помилок, які
виникли під час тестування, таких як незручність інтерфейсу або
несправність певних функцій.
4 Виправлення помилок і остаточне тестування:
Виправлення виявлених помилок та повторне тестування для підтвердження
їх усунення.
‒ Остаточна перевірка системи для забезпечення повної готовності до
впровадження.
‒ Оцінка готовності до впровадження:
Приймальне тестування підтверджує, що мобільний додаток для трекінгу
звичок відповідає всім вимогам кінцевих користувачів, а також функціональним і
нефункціональним вимогам, таким як зручність користування, продуктивність і
безпека. Всі ключові функції працюють коректно, а користувачі задоволені
72
ЧДТУ 252149.001ПЗ
зручністю використання системи. Після успішного проходження приймального
тестування, система готова до впровадження в реальну експлуатацію.
Таблиця 3.4
Результат приймального тестування
Тестовий Очікуваний Фактичний
Модуль Статус
випадок результат результат
Перевірка
Звичка
створення Звичка успішно
Створення створена та
нової звички і створена та Успішно
звички збережена в
її збереження в збережена в базі
базі даних
базі даних
Перевірка
Редагування Звичку можна Звичка успішно
редагування Успішно
звички редагувати відредагована
звички
Продовження таблиці 3.4
Інтерфейс
Перевірка
простий для Інтерфейс
Інтерфейс зручності та
користування, зручний та Успішно
користувача інтуїтивності
зручний та інтуїтивний
інтерфейсу
інтуїтивний
Перевірка
Нагадування
відправки Нагадування
відправляється
Нагадування нагадування відправляється в Успішно
в зазначений
про виконання зазначений час
час
звички
3.3 Приклади впровадженого програмного комплексу
73
ЧДТУ 252149.001ПЗ
У цьому підрозділі наведено приклади реалізованих функцій та можливостей
мобільного додатку для трекінгу звичок. Ці приклади демонструють, як розроблені
програмні компоненти працюють у реальному середовищі, забезпечуючи
користувачам доступ до необхідної інформації та сервісів.
1 Створення та відстеження звичок
Користувачі можуть створювати нові звички, вибираючи зручний опис та
частоту виконання. Після створення звички вони можуть відстежувати свій
прогрес, переглядаючи кількість виконаних днів і загальний прогрес у вигляді
графіків або списків.
2 Отримання нагадувань
Додаток надає користувачам нагадування про виконання звичок у вказаний
час. Користувач може налаштувати нагадування для кожної звички, щоб не забути
виконати її, навіть якщо він займається іншими справами.
3 Перегляд статистики та прогресу
Користувачі можуть переглядати статистику своїх звичок і оцінювати свій
прогрес за певний період. Вони можуть бачити, скільки днів поспіль виконували
звичку, а також загальний відсоток виконання для кожної звички.
4 Модифікація звичок
Якщо користувач хоче змінити частоту або опис звички, він може редагувати
вже створену звичку, змінюючи параметри або додавши нові.
Ці приклади демонструють основні функції та можливості мобільного
додатку для трекінгу звичок, які були впроваджені та успішно працюють у
реальному середовищі. Розроблений програмний комплекс забезпечує зручний і
ефективний доступ до управління звичками, допомагаючи користувачам зберігати
дисципліну і досягати поставлених цілей.
74
ЧДТУ 252149.001ПЗ
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ
У третьому розділі було розглянуто процес реалізації мобільного додатку для
трекінгу звичок, починаючи з обґрунтування вибору технологій і закінчуючи
тестуванням програмного комплексу в умовах, наближених до реального
використання.
Було описано структуру додатку, логіку його роботи, реалізацію бази даних
з використанням Room, архітектуру MVVM, застосування бібліотеки Inject для
залежностей, а також механізм push-нагадувань. Також проведено повний цикл
тестування: модульне, інтеграційне, системне й приймальне, що дозволило
переконатися у стабільній та ефективній роботі всіх компонентів додатку.
На завершення розділу наведено приклади впровадження, що демонструють
функціональність і зручність використання додатку у повсякденному житті.
Програмний продукт показав високу стабільність, продуктивність і відповідність
заявленим вимогам, що свідчить про його готовність до подальшого розвитку та
масштабування.
Основні етапи розробки мобільного додатку для трекінгу звичок:
1 Розробка програмного комплексу:
‒ Ми обґрунтували вибір засобів реалізації, таких як Kotlin, фреймворк
MVVM, база даних Room та інструмент для зберігання локальних
даних;
‒ Була розроблена структурна та логічна схема додатку, а також база
даних для зберігання інформації про користувачів, їх звички, прогрес
та статистику;
‒ Розроблено інтерфейс користувача, що забезпечує зручний доступ до
всіх необхідних функцій, таких як створення звичок, перегляд прогресу
та отримання нагадувань.
2 Тестування системи:
‒ На етапі модульного тестування ми перевірили окремі компоненти
додатку, що дозволило виявити та виправити помилки на ранніх етапах
розробки;
75
ЧДТУ 252149.001ПЗ
‒ Інтеграційне тестування забезпечило перевірку взаємодії між різними
модулями додатку, що гарантує їх коректну спільну роботу;
‒ Системне тестування підтвердило, що всі компоненти працюють разом
як єдине ціле, забезпечуючи стабільну роботу додатку;
‒ Приймальне тестування залучило кінцевих користувачів, які
підтвердили, що додаток відповідає їхнім вимогам і готовий до
впровадження.
3 Приклади впровадженого програмного комплексу:
‒ Ми навели приклади основних функцій додатку, таких як створення та
відстеження звичок, отримання нагадувань, перегляд статистики
прогресу, що демонструють успішне впровадження системи в
реальному середовищі.
В результаті проведеної роботи було створено мобільний додаток для
трекінгу звичок, який значно полегшує відслідковування і досягнення особистих
цілей. Всі етапи розробки та тестування були виконані успішно, що підтверджує
високу якість та надійність системи. Додаток повністю відповідає поставленим
вимогам і готовий до впровадження в повсякденне використання користувачами.
76
ЧДТУ 252149.001ПЗ
ВИСНОВКИ
Кваліфікаційна робота була спрямована на розробку мобільного додатку для
трекінгу звичок. Метою роботи було створення ефективного інструменту, який
дозволяє користувачам формувати та підтримувати корисні звички, відстежувати
прогрес та отримувати мотивацію через зручний мобільний інтерфейс. Робота
охоплювала аналіз сучасних технологій, проектування, розробку програмного
забезпечення та його тестування.
У першому розділі було проведено ґрунтовний аналіз наукових і технічних
джерел, що стосуються мобільних додатків для трекінгу звичок. Розглянуто різні
підходи до реалізації подібних систем, порівняно функціональність існуючих
аналогів, виділено їх сильні та слабкі сторони. Було обґрунтовано вибір
відповідних технологій та платформ для реалізації проєкту, а також сформульовано
основні завдання, що мають бути вирішені у процесі розробки.
Другий розділ присвячений безпосередньо процесу проектування системи.
Було сформовано функціональні та нефункціональні вимоги до додатку на основі
аналізу потреб цільової аудиторії. Описано архітектуру мобільного додатку,
визначено ключові компоненти системи, а також розроблено логічні моделі та
дизайн інтерфейсу. Обрано технології, серед яких: фреймворк для
кросплатформенної розробки (наприклад, Flutter або React Native), база даних для
зберігання інформації про звички користувача (наприклад, SQLite або Firebase), а
також сервіси для реалізації push-сповіщень.
У третьому розділі було описано процес реалізації та тестування додатку.
Розробка охоплювала створення інтерфейсу користувача, реалізацію основного
функціоналу додатку (створення, редагування, трекінг звичок, генерація
статистики), а також інтеграцію з зовнішніми сервісами. Було проведено модульне,
інтеграційне та системне тестування з метою перевірки стабільності,
продуктивності та зручності користування. За результатами тестування було
підтверджено відповідність додатку сформованим вимогам, а також отримано
позитивні відгуки від тестових користувачів.
77
ЧДТУ 252149.001ПЗ
Результати виконаної кваліфікаційної роботи свідчать про успішну
реалізацію мобільного додатку для трекінгу звичок, який може ефективно
застосовуватися для підтримки особистої мотивації користувачів, організації їх
повсякденного життя та покращення самоорганізації. Розроблене рішення
вирізняється зручним інтерфейсом, гнучкістю налаштувань, стабільною роботою
та відповідністю сучасним стандартам мобільної розробки.
78
ЧДТУ 252149.001ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Методи проектування [Електронний ресурс]. – Точка доступу:
https://cpsm.kpi.ua/Doc/konsp_suchasni_metodi.pdf
2 Масштабованість в програмуванні [Електронний ресурс]. – Точка
доступу: URL: https://uk.itpedia.nl/2021/07/20/schaalbaarheid-als-software-
requirement-betekenis-en-definitie/
3 Аналіз ризиків [Електронний ресурс]. – Точка доступу: URL:
https://skillsetter.io/blog/risk-management-ua
4 Моделювання предметної області [Електронний ресурс]. – Точка
доступу: URL: https://dou.ua/forums/topic/42366/
5 Мова UML [Електронний ресурс]. – Точка доступу: URL:
https://docs.kde.org/trunk5/uk/umbrello/umbrello/uml-basics.html [5]
6 Все про UML [Електронний ресурс]. – Точка доступу: URL:
http://www.znannya.org/?view=uml
7 Аналіз вимог до ПЗ [Електронний ресурс]. – Точка доступу: URL:
http://dspace.wunu.edu.ua/retrieve/14135/FCIT_kKN_sPZS_dAVPZ_%20LE
C.pdf
8 Функціональні та нефункціональні вимоги [Електронний ресурс]. – Точка
доступу: URL: https://www.guru99.com/uk/functional-vs-non-functional-
requirements.html
9 Діаграма пакетів [Електронний ресурс]. – Точка доступу: URL:
www.wikiwand.com/uk/Діаграма_пакетів
10 Діаграма компонентів [Електронний ресурс]. – Точка доступу: URL:
https://www.mindonmap.com/uk/blog/uml-component-diagram/
11 Діаграма послідовності [Електронний ресурс]. – Точка доступу: URL:
https://www.maxzosim.com/sequence-diagrams/
12 Актуальність діаграми послідовності [Електронний ресурс]. – Точка
доступу: URL: https://e5.ua/uk/blogpost-2/sequence-diagram-dosi-zhiva/
13 Діаграма комунікації [Електронний ресурс]. – Точка доступу: URL:
https://www.youtube.com/watch?v=xthCbxOENjE
79
ЧДТУ 252149.001ПЗ
14 Діаграма скінченного автомату [Електронний ресурс]. – Точка доступу:
URL: https://www.guru99.com/uk/state-machine-transition-diagram.html
15
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_________________ Голуб С.В.
„____” ______________ 2025 р.
Мобільний додаток для трекінгу звичок
Черкаського державного технологічного університету
Специфікація
482. ЧДТУ 252149.001
Листів 1
Розробник ________________ Бершадський В. А
Керівник ________________ Немченко В. В.
80
482. ЧДТУ 252149.001 2
Черкаси 2024
Позначення Найменування Примітки
Документація
482.ЧДТУ. 252149 12 01 Текст програми
482.ЧДТУ. 252149 34 01 Інструкція користувачеві
482.ЧДТУ. 252149 90 01 Графічні матеріали
ДОДАТОК Б
81
482. ЧДТУ 252149 12 01 2
Мобільний додаток для трекінгу звичок
Черкаського державного технологічного університету
Текст програми
482. ЧДТУ. 252149 12 01
Листів 21
Розробник ________________ Бершадський В. А.
Черкаси 2024
Лістинг файлу CoreApplication.kt
package com.bershadskyi.habits.core
import android.app.Application
import com.bershadskyi.habits.core.in_app_bus.GlobalBus
import dagger.hilt.android.HiltAndroidApp
82
482. ЧДТУ 252149 12 01 2
@HiltAndroidApp
class CoreApplication : Application() {
override fun onTerminate() {
super.onTerminate()
GlobalBus.onDestroy()
}
}
83
ДОДАТОК В
Мобільний додаток для трекінгу звичок
Черкаського державного технологічного університету
Інструкція користувачеві
482. ЧДТУ. 252149 34 01
Листів 3
Розробник ________________ Бершадський В. А.
Черкаси 2024
84
482. ЧДТУ. 252149 90 01 2
Цей мобільний додаток розроблений для формування та підтримки корисних
звичок користувача. Додаток дозволяє створювати, редагувати та видаляти
звички, отримувати щоденні нагадування, відстежувати прогрес і
переглядати статистику виконання.
1 Створення нової звички
− Додавання звички:
− Натисніть кнопку "+" на головному екрані;
− Введіть назву звички (наприклад: "Пити воду", "Читати книжку");
− Виберіть іконку та колір (опційно);
− Вкажіть частоту (щодня / певні дні тижня);
− Установіть час нагадування (наприклад: 09:00 ранку);
− Натисніть "Зберегти" — звичка з'явиться в списку.
2 Редагування та видалення звички
− Щоб змінити звичку:
− Натисніть на звичку у списку;
− Оберіть кнопку "Редагувати";
− Внесіть необхідні зміни;
− Натисніть "Оновити".
− Щоб видалити звичку:
− Затисніть звичку в списку;
− Виберіть "Видалити";
− Підтвердіть дію.
3 Відмітка виконання
− Щоденне виконання;
− У головному списку звичок натисніть чекбокс біля звички;
− Якщо звичку виконано — відмітка збережеться автоматично;
− Скасування відмітки можливе повторним натисканням.
4 Нагадування
− Push-нагадування:
85
482. ЧДТУ. 252149 90 01 2
− Автоматично активуються при створенні звички з часом;
− Ви отримаєте повідомлення у вказаний час;
− Для зміни часу — відредагуйте відповідну звичку.
5 Перегляд статистики
− Перегляд прогресу:
− У меню натисніть "Статистика";
− Оберіть звичку;
− Перегляньте:
− Кількість днів виконання;
6 Додаткові можливості
− Зміна теми
− Посилання на мій телеграм для зв’язку
− Зміна мови
− Експорт статистики
86
482. ЧДТУ. 252149 90 01 2
ДОДАТОК Г
Мобільний додаток для трекінгу звичок
Черкаського державного технологічного університету
Графічні матеріали
482. ЧДТУ. 252149 90 01
Листів 12
Розробник ________________ Бершадський В. А.
Черкаси 2024
87
482. ЧДТУ. 252149 90 01 2
Рисунок Г1 – Слайд 1
Рисунок Г2 – Слайд 2
88
482. ЧДТУ. 252149 90 01 3
Рисунок Г3 – Слайд 3
Рисунок Г4 – Слайд 4
89
482. ЧДТУ. 252149 90 01 4
Рисунок Г5 – Слайд 5
Рисунок Г6 – Слайд 6
90
482. ЧДТУ. 252149 90 01 5
Рисунок Г7 – Слайд 7
Рисунок Г8 – Слайд 8
91
482. ЧДТУ. 252149 90 01 6
Рисунок Г9 – Слайд 9
Рисунок Г10 – Слайд 10
92
482. ЧДТУ. 252149 90 01 7
Рисунок Г11 – Слайд 11
Рисунок Г12 – Слайд 12
93
482. ЧДТУ. 252149 90 01 8
Рисунок Г13 – Слайд 13
Рисунок Г14 – Слайд 14
94
482. ЧДТУ. 252149 90 01 9
Рисунок Г15 – Слайд 15
Рисунок Г16 – Слайд 16
95
482. ЧДТУ. 252149 90 01 10
Рисунок Г17 – Слайд 17
Рисунок Г18 – Слайд 18
96
482. ЧДТУ. 252149 90 01 11
Рисунок Г19 – Слайд 19
Рисунок Г20 – Слайд 20
97
482. ЧДТУ. 252149 90 01 12
Рисунок Г21 – Слайд 21
Рисунок Г22 – Слайд 22
98
482. ЧДТУ. 252149 90 01 13
Рисунок Г23 – Слайд 23
Рисунок Г24 – Слайд 24
99