Репозиторій ЧДТУ
Репозиторій ЧДТУ зберігає і дозволяє легкий і відкритий доступ до всіх видів цифрового контенту, включаючи текст, зображення, анімовані зображення, MPEG і набори даних
Дізнатися більше
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/8868| Назва: | Програмне забезпечення інформаційної системи контролю прийому ліків |
| Автори: | Півень, Олександр Борисович Моляка, Назар Ярославович |
| Ключові слова: | контроль прийому ліків;люди з обмеженими можливостями;доступність;клієнт-серверна архітектура;адаптивний інтерфейс;сповіщення |
| Дата публікації: | 12-чер-2025 |
| Короткий огляд (реферат): | АНОТАЦІЇ
Моляка Н. Я.
Назва кваліфікаційної роботи: Програмне забезпечення інформаційної системи контролю прийому ліків
Спеціальність: 121 «Інженерія програмного забезпечення»
Установа: Черкаський державний технологічний університет
Місто, рік: Черкаси, 2025
Розроблено програмний додаток для автоматизації контролю прийому ліків, орієнтований на людей з обмеженими можливостями. Основна мета роботи – створення доступного інструменту, який враховує потреби осіб із сенсорними та фізичними обмеженнями. Додаток має клієнт-серверну архітектуру, інтуїтивний інтерфейс із можливістю зміни розміру шрифтів, візуальними та звуковими сповіщеннями, а також функціоналом для управління призначеннями ліків лікарями. Реалізовано адаптивні сповіщення, які полегшують використання для осіб із вадами зору чи слуху, та стабільне з’єднання через сокети для оперативного оновлення даних. Результати роботи впроваджено в рамках курсового проєкту, підтвердивши практичну цінність для медичних установ та осіб з обмеженими можливостями. Додаток сприяє підвищенню якості життя шляхом забезпечення своєчасного прийому ліків та ефективного медичного нагляду. 5 ANNOTATIONS Performer: Moliaka N. Y. Title of the qualification work: “Medication Intake Control Application for People with Disabilities” Specialty: 121 Software Engineering Institution: Cherkasy State Technological University Educational institution: Cherkasy State Technological University, Cherkasy, 2025. The software application “TheCure” was developed to automate medication intake control, tailored for individuals with disabilities. The primary goal is to create an accessible tool addressing the needs of users with sensory and physical impairments. The application features a client-server architecture, an intuitive interface with adjustable font sizes, visual and auditory notifications, and functionality for doctors to manage prescriptions. Adaptive notifications facilitate use for individuals with visual or hearing impairments, while stable socket-based connectivity ensures real-time data updates. The results were implemented within the coursework project, demonstrating practical value for medical institutions and people with disabilities. The application enhances quality of life by ensuring timely medication intake and effective medical oversight. |
| URI (Уніфікований ідентифікатор ресурсу): | https://er.chdtu.edu.ua/handle/ChSTU/8868 |
| Розташовується у зібраннях: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Моляка Назар Ярославович.pdf Restricted Access | 2.62 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
бакалавра
на тему: «Програмне забезпечення інформаційної системи контролю
прийому ліків»
Виконав: студент 4 курсу, групи ПЗ-2104
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Моляка Н. Я.
(прізвище та ініціали)
Керівник Півень О. Б.
(прізвище та ініціали)
Рецензент Захарова М. В.
(прізвище та ініціали)
Черкаси 2025
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
____________________ С. Голуб
«___» _______________ 2025 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Моляка Назар Ярославович
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Програмне забезпечення інформаційної системи контролю прийому
ліків
Керівник проекту (роботи) Півень Олександр Борисович к.ф.-м.н., доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від «25» лютого 2025
року №53/03-03
2. Строк подання студентом проекту (роботи)
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління;
вимоги до проекту; календарне планування проекту; управління ризиками проекту; управління
ресурсами
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) Вступ;
Існуючі методи та засоби розв’язання поставлених завдань;
Впровадження результатів досліджень у практику проектування
Конструювання та тестування програмного забезпечення
Висновки;
Список використаних джерел;
Додатки.
2
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;
Слайд1, Слайд2, Слайд3, Слайд4, Слайд5, Слайд6, Слайд7
6. Консультанти розділів роботи
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання 02 грудня 2024 р.
КАЛЕНДАРНИЙ ПЛАН
Строк
виконання
№
Назва етапів випускної роботи етапів Примітки
п/п
кваліфікаційної
роботи
1 Постановка задачі 05.12.2024 виконано
2 Підготовка завдання 13.12.2024 виконано
3 Погодження завдання 16.12.2024 виконано
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.2025 виконано
керівником
2 Оформлення пояснювальної записки роботи в 13.05.2025 виконано
кінцевій редакції
3 Попередній захист роботи 15.05.2025 виконано
4 Затвердження роботи 02.06.2025
5 Рецензування роботи 06.06.2025
6 Захист роботи 11.06.2025
Студент _____________________ Моляка Н. Я.
(підпис) (прізвище та ініціали)
Керівник роботи _____________________ Півень О. Б.
(підпис) (прізвище та ініціали)
3
АНОТАЦІЇ
Моляка Н. Я.
Назва кваліфікаційної роботи: Програмне забезпечення інформаційної
системи контролю прийому ліків
Спеціальність: 121 «Інженерія програмного забезпечення»
Установа: Черкаський державний технологічний університет
Місто, рік: Черкаси, 2025
Розроблено програмний додаток для автоматизації контролю прийому ліків,
орієнтований на людей з обмеженими можливостями. Основна мета роботи –
створення доступного інструменту, який враховує потреби осіб із сенсорними та
фізичними обмеженнями. Додаток має клієнт-серверну архітектуру, інтуїтивний
інтерфейс із можливістю зміни розміру шрифтів, візуальними та звуковими
сповіщеннями, а також функціоналом для управління призначеннями ліків
лікарями. Реалізовано адаптивні сповіщення, які полегшують використання для
осіб із вадами зору чи слуху, та стабільне з’єднання через сокети для оперативного
оновлення даних. Результати роботи впроваджено в рамках курсового проєкту,
підтвердивши практичну цінність для медичних установ та осіб з обмеженими
можливостями. Додаток сприяє підвищенню якості життя шляхом забезпечення
своєчасного прийому ліків та ефективного медичного нагляду.
Ключові слова: контроль прийому ліків, люди з обмеженими
можливостями, доступність, клієнт-серверна архітектура, адаптивний інтерфейс,
сповіщення.
4
ANNOTATIONS
Performer: Moliaka N. Y.
Title of the qualification work: “Medication Intake Control Application for People
with Disabilities”
Specialty: 121 Software Engineering
Institution: Cherkasy State Technological University
Educational institution: Cherkasy State Technological University, Cherkasy, 2025.
The software application “TheCure” was developed to automate medication intake
control, tailored for individuals with disabilities. The primary goal is to create an
accessible tool addressing the needs of users with sensory and physical impairments. The
application features a client-server architecture, an intuitive interface with adjustable font
sizes, visual and auditory notifications, and functionality for doctors to manage
prescriptions. Adaptive notifications facilitate use for individuals with visual or hearing
impairments, while stable socket-based connectivity ensures real-time data updates. The
results were implemented within the coursework project, demonstrating practical value
for medical institutions and people with disabilities. The application enhances quality of
life by ensuring timely medication intake and effective medical oversight.
5
ЗМІСТ
ВСТУП .......................................................................................................................... 5
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ ..................................................................................................................... 8
1.1 Огляд платформ та фреймворків для розробки десктопного додатка.............. 8
1.2 Методи аналізу десктопного додатка ............................................................... 11
1.3 Порівняльний аналіз існуючих аналогів .......................................................... 12
1.4 Постановка задачі .............................................................................................. 16
Висновок до розділу 1............................................................................................. 19
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ..................................................................................................... 20
2.1 Моделювання предметної області .................................................................... 20
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області ............................................................................................... 20
2.1.2 Елементи моделювання предметної області .............................................. 23
2.1.3 Робоча область моделювання ..................................................................... 25
2.2 Формування та аналіз вимог ............................................................................. 27
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги ................................................................................................................... 27
2.2.2 Формування вимог за допомогою діаграми прецедентів .......................... 30
2.3 Проектування логічної структури програмного комплексу ........................... 31
2.3.1 Діаграма класів ............................................................................................ 32
2.3.2 Діаграма пакетів .......................................................................................... 35
2.4 Архітектура проектування ................................................................................ 37
2.4.1 Діаграма компонентів ................................................................................. 37
Зм. Лист № документа№ ПідписПі Дата ЧДТУ 252162-014ПЗ
РЗомз.р обЛ. ист докум. ента дпис Дата «Програмне забезпечення інформаційної Літ. Лист Листів
Керівник системи контролю прийому ліків» Д 3
.
Пояснювальна записка Н
ФІТІС, кафедра ПЗАС,
Н.контр.
Затв. ПЗ-2104
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання .......................................................................................................... 40
2.5 Моделювання поведінки системи .................................................................... 42
2.5.1 Діаграма діяльності ..................................................................................... 42
2.5.2 Діаграма послідовності ............................................................................... 45
2.5.3 Діаграма комунікації ................................................................................... 48
2.5.4 Діаграма скінченного автомату .................................................................. 49
Висновок до розділу 2............................................................................................. 51
РОЗДІЛ 3. КОНСТРУЮВАННЯ ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ ....................................................................................................... 52
3.1 Розробка додатка ............................................................................................... 52
3.1.1 Обґрунтування вибору засобів реалізації .................................................. 52
3.1.2 Опис структурної (функціональної) схеми ................................................ 54
3.1.3 Опис логічної схеми .................................................................................... 55
3.1.4 Розробка бази даних .................................................................................... 58
3.1.5 Розробка інтерфейсу користувача .............................................................. 60
3.1.6 Опис розробки програмних компонентів................................................... 62
3.2 Тестування системи........................................................................................... 64
3.2.1 Модульне тестування .................................................................................. 64
3.2.2 Інтеграційне тестування .............................................................................. 66
3.2.3 Системне тестування ................................................................................... 68
3.2.4 Приймальне тестування .............................................................................. 69
3.3. Приклади впровадження програмного комплексу ......................................... 71
Висновки до розділу 3 ............................................................................................ 78
ВИСНОВКИ ............................................................................................................... 79
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................... 82
ДОДАТОК А .............................................................................................................. 85
ДОДАТОК Б ............................................................................................................... 87
ДОДАТОК В ............................................................................................................. 101
ДОДАТОК Г ............................................................................................................. 106
ЧДТУ 252162-014ПЗ
ВСТУП
Актуальність теми. Розробка програмного забезпечення, яке поєднує
інтуїтивний інтерфейс, адаптивні сповіщення та підтримку для лікарів і пацієнтів,
є актуальною для підвищення якості життя таких осіб та ефективності медичного
нагляду. Проблема своєчасного прийому ліків є критично важливою для людей з
обмеженими можливостями, оскільки порушення режиму медикаментозного
лікування може призвести до серйозних наслідків для здоров’я. Сучасні рішення
для контролю прийому ліків часто не враховують потреби осіб із сенсорними чи
фізичними обмеженнями, такими як слабкий зір або труднощі з дрібною
моторикою. Існуючі системи, як правило, обмежуються базовими функціями
сповіщень або не забезпечують достатньої адаптивності інтерфейсу.
Мета і завдання розробки. Метою кваліфікаційної роботи бакалавра є
створення програмного додатка для контролю прийому ліків, орієнтованого на
людей з обмеженими можливостями. Для досягнення цієї мети було поставлено
такі завдання:
− розробити клієнт-серверну архітектуру для взаємодії між лікарями та
пацієнтами;
− реалізувати адаптивний інтерфейс із можливістю зміни розміру шрифтів;
− створити систему сповіщень із візуальними та звуковими сигналами;
− забезпечити функціонал управління призначеннями ліків для лікарів;
− протестувати систему на відповідність вимогам доступності.
Об’єкт розробки. Об’єктом розробки є процес створення програмного
забезпечення для контролю прийому ліків для людей з обмеженими можливостями.
Предметом дослідження є програмна система, що забезпечує автоматизацію
цього процесу через створення зручного інтерфейсу, системи сповіщень та
інструментів для взаємодії між лікарями та пацієнтами. Основна увага приділяється
адаптації системи до потреб користувачів із сенсорними чи фізичними
обмеженнями, що визначає тематику роботи.
5
ЧДТУ 252162-014ПЗ
Методи проектування та конструювання. Для реалізації поставленої мети
використано низку методів. Аналіз і порівняння застосовувалися для вивчення
існуючих рішень у сфері контролю прийому ліків, що дозволило виявити їхні
недоліки, зокрема недостатню адаптивність для людей з обмеженими
можливостями. Системний підхід використано для проектування клієнт-серверної
архітектури, що забезпечує взаємодію між користувачами. Моделювання
застосовувалося для створення структури інтерфейсу та системи сповіщень.
Експериментальний метод використано під час тестування функціоналу, зокрема
перевірки коректності роботи сповіщень і керування призначеннями. Об’єктно-
орієнтоване програмування в Python із використанням бібліотеки Tkinter
забезпечило реалізацію графічного інтерфейсу та логіки додатка [2].
Опис отриманих результатів. У результаті виконаної роботи створено
програмний додаток для контролю прийому ліків, який включає клієнтську частину
з графічним інтерфейсом для лікарів і пацієнтів. Пацієнти отримують сповіщення
про час прийому ліків із візуальними (мигання вікна) та звуковими сигналами, що
полегшує використання для осіб із вадами зору чи слуху. Інтерфейс підтримує
зміну розміру шрифтів, що сприяє доступності для користувачів зі слабким зором.
Лікарі можуть додавати, редагувати та видаляти призначення, а також переглядати
список пацієнтів. Система забезпечує стабільне підключення до сервера через
сокети, що дозволяє оперативно оновлювати дані.
Практичне значення отриманих результатів. Розроблений програмний
додаток має прикладне значення для медичних установ та осіб із обмеженими
можливостями. Він може бути використаний у домашніх умовах або в медичних
закладах для автоматизації контролю прийому ліків. Система готова до
використання на персональних комп’ютерах і може бути адаптована для інших
платформ. Функціонал сповіщень і адаптивний інтерфейс підвищують доступність
для людей із сенсорними обмеженнями. Результати роботи впроваджено в рамках
курсового проєкту, а рекомендації щодо використання передані до навчального
закладу для подальшого тестування.
6
ЧДТУ 252162-014ПЗ
Особистий внесок автора. Автором виконано повний цикл розробки
програмного додатка: від аналізу вимог і проектування архітектури до реалізації та
тестування. Було розроблено клієнтську частину з використанням Python і Tkinter,
реалізовано систему сповіщень із підтримкою звукових і візуальних сигналів, а
також забезпечено адаптивність інтерфейсу. Проведено аналіз потреб користувачів
із обмеженими можливостями, що дозволило врахувати їхні вимоги в дизайні
системи. Тестування й оптимізація функціоналу також виконані автором
самостійно.
7
ЧДТУ 252162-014ПЗ
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
Сучасні десктопні додатки для контролю прийому ліків є важливим
інструментом у сфері охорони здоров’я, особливо для людей з обмеженими
можливостями. Такі програми дозволяють автоматизувати процеси відстеження
прийому медикаментів, надавати сповіщення та забезпечувати доступність
інтерфейсу для користувачів із різними потребами. У цьому розділі проведено
аналіз наукової та технічної інформації щодо створення десктопних додатків для
контролю прийому ліків, зосереджуючись на методах, технологіях та прикладах
успішних реалізацій [3].
Додатки для контролю прийому ліків – це програмне забезпечення, яке
допомагає користувачам дотримуватися графіку прийому медикаментів,
відстежувати дози та отримувати нагадування. Вони можуть інтегруватися з
медичними інформаційними системами, забезпечувати доступ для лікарів та
надавати зручний інтерфейс для пацієнтів. Згідно з дослідженнями, такі додатки
підвищують ефективність терапії та знижують ризик пропуску доз, що особливо
важливо для людей з обмеженими можливостями, які можуть потребувати
додаткових засобів доступності, таких як адаптивні шрифти чи звукові сповіщення
[4].
1.1 Огляд платформ та фреймворків для розробки десктопного додатка
Розробка десктопних додатків для контролю прийому ліків вимагає вибору
відповідних платформ і фреймворків, які забезпечують зручність, доступність і
функціональність. Існує кілька популярних інструментів для створення таких
додатків, кожен з яких має свої переваги та недоліки. Нижче наведено огляд
найпоширеніших платформ і фреймворків для розробки десктопних додатків.
Python – одна з найпопулярніших мов програмування для створення
десктопних додатків завдяки своїй простоті та великій екосистемі бібліотек [5].
Бібліотека Tkinter, яка використовується в коді проєкту, є стандартним
інструментом для створення графічного інтерфейсу в Python.
8
ЧДТУ 252162-014ПЗ
Переваги Tkinter:
− простота у використанні, що дозволяє швидко створювати інтерфейси
навіть для розробників-початківців;
− вбудована в стандартну бібліотеку Python, що усуває необхідність
додаткових установок;
− підтримка кросплатформності, що забезпечує роботу додатків на різних
операційних системах.
Недоліки Tkinter:
− обмежені можливості дизайну порівняно з сучасними фреймворками;
− менш інтуїтивний для створення складних анімованих інтерфейсів;
− обмежена підтримка сучасних елементів інтерфейсу без додаткових
бібліотек, таких як ttk.
PyQt – ще один популярний фреймворк для Python, який використовується
для створення складних десктопних додатків із сучасним інтерфейсом [6].
Переваги PyQt:
− розширений набір віджетів і інструментів для створення професійних
інтерфейсів;
− підтримка складних графічних ефектів і анімацій;
− можливість інтеграції з базами даних та іншими сервісами.
Недоліки PyQt:
− складніша крива навчання порівняно з Tkinter;
− потребує додаткових залежностей, що може ускладнити розгортання;
− ліцензійні обмеження для комерційних проєктів.
Electron – це платформа на основі JavaScript, яка дозволяє створювати
десктопні додатки, використовуючи веб-технології, такі як HTML, CSS і JavaScript
[7].
Переваги Electron:
− можливість створення кросплатформних додатків із сучасним веб-
подібним інтерфейсом;
9
ЧДТУ 252162-014ПЗ
− велика екосистема бібліотек завдяки підтримці Node.js;
− підтримка спільноти та інтеграція з сучасними інструментами розробки.
Недоліки Electron:
− великий розмір кінцевого додатка через вбудовування Chromium;
− високе споживання ресурсів у порівнянні з нативними фреймворками;
− необхідність знання веб-технологій для ефективної розробки.
JavaFX – фреймворк для створення десктопних додатків на мові Java, який
підходить для створення складних і масштабованих систем [8].
Переваги JavaFX:
− потужні можливості для створення сучасних інтерфейсів із підтримкою
анімацій;
− кросплатформність і підтримка великих проєктів;
− інтеграція з екосистемою Java для роботи з серверними технологіями.
Недоліки JavaFX:
− складність у вивченні для розробників без досвіду роботи з Java;
− менш популярний у порівнянні з Python або Electron, що може
обмежувати кількість навчальних матеріалів;
− вимагає додаткових зусиль для забезпечення доступності для людей з
обмеженими можливостями.
Виходячи з аналізу переваг і недоліків вищезазначених інструментів, для
реалізації додатка, представленого в коді проєкту, обрано мову програмування
Python із фреймворком Tkinter [9]. Цей вибір є виправданим з огляду на потреби
проєкту, зокрема необхідність створення доступного інтерфейсу для людей з
обмеженими можливостями. Tkinter забезпечує простоту розробки, підтримку
адаптивних шрифтів (як видно з функцій increase_font_size і decrease_font_size у
коді) та можливість реалізації звукових і візуальних сповіщень (наприклад, функція
flash_notification), що є критично важливим для цільової аудиторії [10]. Крім того,
Tkinter дозволяє швидко створювати функціональні прототипи, що ідеально
підходить для проєктів із чітко визначеними вимогами до доступності та простоти.
10
ЧДТУ 252162-014ПЗ
Загалом, використання Python і Tkinter забезпечує міцну основу для розробки
десктопного додатка, який відповідає сучасним вимогам до доступності, простоти
використання та ефективності для людей з обмеженими можливостями.
1.2 Методи аналізу десктопного додатка
Розробка десктопного додатка для контролю прийому ліків, орієнтованого на
людей з обмеженими можливостями, вимагає комплексного аналізу для
забезпечення ефективності, доступності та надійності системи. У цьому підрозділі
розглядаються методи аналізу, які застосовуються для оцінки та вдосконалення
процесу розробки такого додатка, з урахуванням особливостей його функціоналу
та потреб цільової аудиторії.
SWOT-аналіз є ключовим інструментом для оцінки сильних і слабких сторін
десктопного додатка, а також можливостей і загроз зовнішнього середовища. Цей
метод дозволяє визначити переваги, такі як інтуїтивний інтерфейс і функції
доступності (наприклад, зміна розміру шрифту чи сповіщення), а також виявити
потенційні виклики, пов’язані з технічними обмеженнями чи адаптацією до
різноманітних потреб користувачів [11].
Аналіз даних передбачає обробку інформації про вимоги користувачів,
технічні характеристики системи, її продуктивність і зручність використання. Це
включає аналіз логів взаємодії з додатком, відгуків користувачів і даних про
частоту використання функцій, таких як сповіщення про прийом ліків. Такий підхід
допомагає виявити проблемні аспекти інтерфейсу та оптимізувати функціонал для
людей з обмеженими можливостями [12].
Моделювання процесів використовується для прогнозування поведінки
системи в різних сценаріях. Наприклад, моделювання взаємодії користувача з
функціями сповіщень чи таблиці призначень дозволяє оцінити зручність і
швидкість доступу до інформації. Комп’ютерні моделі також застосовуються для
оптимізації ресурсів, таких як пам’ять і обчислювальна потужність, що критично
для стабільної роботи додатка на різних пристроях [13].
11
ЧДТУ 252162-014ПЗ
Аналіз ризиків спрямований на виявлення потенційних загроз, таких як збої
в підключенні до сервера, проблеми з безпекою даних або складнощі в адаптації
інтерфейсу для користувачів із порушеннями зору чи слуху. Цей метод включає
розробку стратегій управління ризиками, наприклад, реалізації механізмів
повторного підключення до сервера чи шифрування даних користувачів.
Аналіз потреб користувачів зосереджений на вивченні вимог осіб з
обмеженими можливостями. Це включає оцінку необхідності функцій, таких як
звукові сповіщення, великі шрифти чи спрощена навігація, щоб забезпечити
максимальну доступність і зручність. Такий підхід гарантує, що додаток відповідає
реальним потребам цільової аудиторії, зокрема пацієнтів і лікарів.
Застосування цих методів аналізу забезпечує цілісний підхід до розробки
десктопного додатка, сприяючи створенню ефективної, доступної та надійної
системи. Кожен метод дозволяє оцінити проект з різних перспектив, що підвищує
якість кінцевого продукту та його відповідність потребам користувачів.
1.3 Порівняльний аналіз існуючих аналогів
Для оцінки ефективності розробленого додатка TheCure, призначеного для
контролю прийому ліків людьми з обмеженими можливостями, проведено аналіз
аналогічних програмних засобів, доступних на ринку. Було досліджено три основні
аналоги, які виконують подібні функції: мобільний додаток Medisafe, веб-додаток
Pillbox та телеграм-бот Medication Reminder Bot. Кожен із них проаналізовано за
критеріями функціональності, доступності, зручності використання та адаптації до
потреб людей з обмеженими можливостями. Нижче наведено детальний аналіз
переваг і недоліків кожного аналога з урахуванням потреб цільової аудиторії.
Мобільний додаток Medisafe, доступний для Android та iOS, є популярним
інструментом для управління прийомом ліків, який дозволяє користувачам
створювати розклад прийому медикаментів, отримувати нагадування та
відстежувати історію прийому [14] (рисунок 1.1). Додаток має інтуїтивно
зрозумілий інтерфейс із можливістю налаштування сповіщень.
12
ЧДТУ 252162-014ПЗ
Рисунок 1.1 – Інформаційна сторінка Medisafe для завантаження додатка
Переваги:
− наявність функції нагадувань із підтримкою звукових і візуальних
сповіщень, що є зручним для людей із порушеннями слуху чи зору [14];
− можливість синхронізації з хмарними сервісами для збереження даних та
доступу з різних пристроїв;
− підтримка кількох мов, що сприяє доступності для широкого кола
користувачів.
Недоліки:
− обмежена підтримка функцій для людей із серйозними фізичними
обмеженнями, наприклад, відсутність інтеграції з адаптивними пристроями
введення;
− необхідність встановлення додатка на смартфон, що може бути
проблематичним для користувачів із застарілими пристроями або обмеженим
доступом до магазинів додатків;
− безкоштовна версія має обмежений функціонал, а преміум-підписка може
бути недоступною для деяких користувачів через високу вартість.
MyTherapy — це мобільний додаток, доступний для Android та iOS, який
пропонує користувачам можливість створювати розклад прийому ліків,
отримувати нагадування та вести журнал здоров’я [15] (рисунок 1.2). Додаток
13
ЧДТУ 252162-014ПЗ
орієнтований на простоту використання та підтримку мотиваційних функцій для
підвищення прихильності до лікування.
Рисунок 1.2 – Інформаційна сторінка MyTherapy
Переваги:
− інтуїтивно зрозумілий інтерфейс із функцією нагадувань, що включає
вібрацію та звукові сигнали, що полегшує використання для людей із порушеннями
зору [15];
− наявність функції ведення журналу здоров’я, що дозволяє відстежувати
не лише прийом ліків, а й інші показники, такі як настрій чи фізична активність;
− безкоштовна базова версія з достатнім функціоналом для більшості
користувачів.
Недоліки:
− відсутність спеціалізованих функцій для людей із серйозними фізичними
чи когнітивними обмеженнями, таких як голосове керування чи спрощені меню;
− необхідність встановлення додатка, що може бути незручним для
користувачів із застарілими пристроями;
14
ЧДТУ 252162-014ПЗ
− обмежена інтеграція з медичними системами чи адаптивними
пристроями, що знижує його універсальність.
Телеграм-бот MedBot дозволяє користувачам налаштовувати нагадування
про прийом ліків через чат-інтерфейс у Telegram [16] (рисунок 1.3). Бот
використовує текстові повідомлення та інтерактивну клавіатуру для взаємодії, що
робить його зручним для швидкого доступу.
Рисунок 1.3 – Телеграм-бот MedBot
Переваги:
− легкість доступу через платформу Telegram, яка є популярною та не
потребує встановлення додаткових додатків [16];
− безкоштовність, що робить бот доступним для всіх користувачів;
− простота налаштування нагадувань через текстовий інтерфейс.
Недоліки:
15
ЧДТУ 252162-014ПЗ
− обмежений функціонал: бот не підтримує відстеження історії прийому
ліків чи інтеграцію з медичними системами.
− відсутність адаптації для людей із порушеннями зору чи слуху, таких як
підтримка голосових команд чи миготливих сповіщень.
− необхідність ручного введення даних про ліки, що може бути незручним
для користувачів із фізичними обмеженнями.
Порівнюючи наведені аналоги з розробленим додатком TheCure, можна
зробити наступні висновки:
− TheCure вирізняється адаптивним інтерфейсом із можливістю зміни
розміру шрифту та звуковими сповіщеннями, що робить його більш доступним для
людей із порушеннями зору та слуху порівняно з MyTherapy та MedBot [17];
− на відміну від Medisafe та MyTherapy, TheCure працює як настільний
додаток, що не потребує встановлення на смартфон, що є перевагою для
користувачів із обмеженим доступом до сучасних мобільних пристроїв [18];
− у порівнянні з телеграм-ботом MedBot, TheCure пропонує ширший
функціонал, зокрема можливість авторизації, відстеження історії прийому ліків та
інтеграцію з сервером для збереження даних, що забезпечує більшу зручність і
безпеку [19];
− TheCure має унікальну функцію миготливих сповіщень, що є критично
важливим для людей із порушеннями слуху, на відміну від усіх проаналізованих
аналогів [20].
Таким чином, TheCure забезпечує оптимальний баланс між доступністю,
функціональністю та адаптивністю для людей з обмеженими можливостями,
перевершуючи аналоги за низкою ключових параметрів.
1.4 Постановка задачі
На основі аналізу існуючих платформ і фреймворків для створення
десктопних додатків, методів розробки програмного забезпечення та вивчення
аналогів із порівнянням їхніх сильних і слабких сторін, сформульовано завдання,
які необхідно виконати для створення системи контролю прийому ліків для людей
16
ЧДТУ 252162-014ПЗ
з обмеженими можливостями. Розробка такого додатка вимагає комплексного
підходу, що охоплює аналіз потреб користувачів, визначення вимог до системи,
вибір відповідних технологій, реалізацію функціоналу та тестування системи для
забезпечення її доступності та ефективності.
Для створення ефективного додатка було проведено аналіз потреб цільової
аудиторії, зокрема людей з обмеженими можливостями, а також медичного
персоналу. Основними завданнями цього етапу є:
− проведення опитувань та інтерв’ю з пацієнтами та лікарями для
визначення ключових вимог до системи, таких як зручність інтерфейсу,
доступність для осіб із порушеннями зору чи слуху, а також автоматизація
нагадувань про прийом ліків;
− збір даних про поточні методи управління прийомом ліків, включаючи
використання паперових графіків, мобільних додатків або інших інструментів, для
виявлення їхніх недоліків і потреб у вдосконаленні.
На основі отриманих даних сформульовано функціональні та
нефункціональні вимоги до системи:
− функціональні вимоги: забезпечення відображення списку призначень,
автоматичних сповіщень про час прийому ліків із візуальними та звуковими
сигналами, можливості для лікарів додавати, редагувати та видаляти призначення,
а також функція підтвердження прийому ліків пацієнтами;
− нефункціональні вимоги: забезпечення високої доступності інтерфейсу
(збільшення шрифтів, контрастні кольори), надійності системи, безпеки даних і
простоти використання для людей з обмеженими можливостями.
Для реалізації додатка обрано технології, які забезпечують стабільність,
доступність і простоту розробки:
− мова програмування: Python, завдяки його універсальності та підтримці
бібліотек для створення графічних інтерфейсів [21];
− фреймворк для GUI: Tkinter, який забезпечує створення
кросплатформених десктопних додатків із можливістю адаптації інтерфейсу для
осіб з обмеженими можливостями;
17
ЧДТУ 252162-014ПЗ
− мережева взаємодія: використання бібліотеки socket для забезпечення
зв’язку між клієнтом і сервером для обробки запитів;
− формат обміну даними: JSON для передачі структурованих даних між
клієнтом і сервером.
Процес розробки включає такі етапи:
− проектування архітектури системи, що охоплює клієнтську частину
(графічний інтерфейс) та серверну частину (обробка даних і запитів);
− реалізація функціоналу, включаючи авторизацію користувачів,
відображення списків призначень, створення сповіщень із миготливими вікнами та
звуковими сигналами, а також функції для керування призначеннями лікарями;
− інтеграція системи з сервером для збереження та оновлення даних про
призначення ліків у реальному часі.
Для забезпечення якості системи передбачено:
− проведення функціонального тестування для перевірки коректності всіх
функцій, таких як відправка запитів, відображення сповіщень і оновлення списків
призначень;
− тестування доступності, щоб переконатися, що інтерфейс відповідає
потребам осіб із обмеженими можливостями (наприклад, перевірка читабельності
тексту при збільшенні шрифтів);
− валідація системи за участю кінцевих користувачів (пацієнтів і лікарів)
для збору зворотного зв’язку та внесення необхідних коригувань.
Розробка десктопного додатка для контролю прийому ліків є складним
завданням, яке потребує ретельного аналізу потреб користувачів, чіткого
визначення вимог, вибору відповідних технологій, реалізації та тестування
системи. Виконання цих завдань дозволить створити зручний, доступний і
надійний інструмент, який полегшить процес управління прийомом ліків для
людей з обмеженими можливостями та підвищить ефективність взаємодії між
пацієнтами та лікарями.
18
ЧДТУ 252162-014ПЗ
Висновок до розділу 1
Проведений аналіз сучасних методів і засобів розробки десктопних додатків
для контролю прийому ліків показав, що вибір Python із фреймворком Tkinter є
оптимальним для створення доступного та функціонального інструменту, особливо
для людей з обмеженими можливостями. Застосування методів SWOT-аналізу,
аналізу потреб користувачів і порівняльного аналізу аналогів дозволило виявити
ключові вимоги до системи, зокрема адаптивність інтерфейсу та надійність.
Порівняння з аналогами (Medisafe, MyTherapy, MedBot) підкреслило переваги
розробленого додатка TheCure, який вирізняється підтримкою звукових і
миготливих сповіщень та кросплатформністю. Чітко сформульовані завдання щодо
аналізу потреб, вибору технологій, реалізації та тестування системи створюють
основу для розробки ефективного рішення, що відповідає потребам цільової
аудиторії.
19
ЧДТУ 252162-014ПЗ
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ
2.1 Моделювання предметної області
Моделювання предметної області є ключовим етапом у розробці системи
контролю прийому ліків, оскільки воно дозволяє створити чітке уявлення про
структуру, функції та взаємодію компонентів системи. У контексті додатка
TheCure, розробленого для людей з обмеженими можливостями, моделювання
предметної області забезпечує врахування специфічних потреб користувачів, таких
як доступність інтерфейсу, сповіщення та адаптивність. Це включає створення
концептуальної, логічної та фізичної моделей, які допомагають визначити ключові
елементи системи, оптимізувати її функціональність та забезпечити інтеграцію з
серверними технологіями. Такий підхід сприяє зменшенню ризиків помилок,
підвищенню ефективності реалізації проекту та забезпеченню зручності
використання для осіб з обмеженими можливостями [22].
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області
Предметна область моделювання. Моделювання предметної області для
системи TheCure охоплює всі аспекти, пов’язані з автоматизацією контролю
прийому ліків для людей з обмеженими можливостями. Основна мета системи —
забезпечити зручне управління призначеннями ліків, своєчасні сповіщення та
доступний інтерфейс для пацієнтів і лікарів. Основні компоненти предметної
області включають:
− реєстрація користувачів – процес створення профілів для пацієнтів і
лікарів, що передбачає введення логіну, пароля та ролі (пацієнт або лікар). Це
забезпечує ідентифікацію користувачів у системі;
− управління призначеннями ліків – функція, що дозволяє лікарям
додавати, редагувати та видаляти призначення ліків, включаючи назву ліків, дозу,
час прийому та ідентифікатор пацієнта;
20
ЧДТУ 252162-014ПЗ
− сповіщення про прийом ліків – система автоматичних сповіщень для
пацієнтів, що включає візуальні (мигання вікон) та звукові (сигнали) нагадування,
адаптовані для осіб з обмеженими можливостями;
− перегляд списку призначень – можливість для пацієнтів і лікарів
переглядати актуальні призначення в табличному вигляді, включаючи статус
прийому ліків;
− інтерфейс із змінним розміром шрифту – функція, що дозволяє
користувачам із вадами зору налаштовувати розмір шрифту для покращення
читабельності.
Моделювання предметної області дозволяє чітко визначити структуру та
функціональність системи, забезпечити її відповідність потребам користувачів і
спростити подальшу розробку та підтримку [23].
Модель предметної області. Модель предметної області для системи
TheCure охоплює всі аспекти автоматизації управління прийомом ліків. Основні
компоненти включають:
1 Реєстрація користувачів. Процес передбачає створення профілів із такими
даними:
− логін та пароль: для автентифікації користувача;
− роль: визначає, чи є користувач лікарем чи пацієнтом;
− ідентифікатор користувача: унікальний номер для ідентифікації в
системі.
2 Управління призначеннями ліків. Функція для лікарів включає:
− додавання призначення: введення ідентифікатора пацієнта, назви
ліків, дози та часу прийому;
− редагування та видалення: зміна або видалення існуючих призначень;
− перегляд списку призначень: відображення всіх призначень у
табличному вигляді;
3 Сповіщення про прийом ліків. Функція для пацієнтів включає:
− назва ліків: ідентифікація препарату;
− доза: кількість ліків для прийому;
21
ЧДТУ 252162-014ПЗ
− час прийому: точний час для нагадування;
− статус: інформація про те, чи прийнято ліки.
4 Інтерфейс із змінним розміром шрифту. Функція для забезпечення
доступності:
− зміна розміру шрифту: від 8 до 20 пікселів;
− оновлення інтерфейсу: автоматична адаптація всіх елементів до
нового розміру шрифту.
5 Комунікація з сервером. Система обміну даними включає:
− запити до сервера: для отримання списків призначень, реєстрації,
автентифікації тощо;
− обробка відповідей: відображення результатів у клієнтському
інтерфейсі.
Схема моделі предметної області:
1 Користувачі:
− пацієнти;
− лікарі.
2 Дані про користувачів:
− ідентифікаційні дані (логін, пароль, роль);
− унікальний ідентифікатор.
3 Призначення ліків:
− ідентифікатор призначення;
− назва ліків, доза, час прийому, статус.
4 Сповіщення:
− візуальні (мигання вікон);
− звукові (сигнали).
5 Інтерфейс:
− таблиця призначень;
− кнопки управління (додавання, редагування, видалення);
− налаштування розміру шрифту.
22
ЧДТУ 252162-014ПЗ
Моделювання предметної області забезпечує чітке розуміння структури
системи, сприяє ефективному плануванню розробки, зниженню ризиків помилок і
полегшує подальше вдосконалення системи для забезпечення її доступності та
зручності [24].
Словник предметної області
Розглянемо основні елементи словника предметної області:
− система контролю прийому ліків -програмне забезпечення для
автоматизації управління прийомом ліків, адаптоване для осіб з обмеженими
можливостями;
− пацієнт - користувач системи, який отримує сповіщення про прийом ліків
і переглядає призначення;
− лікар - користувач системи, який додає, редагує та видаляє призначення
ліків для пацієнтів;
− призначення ліків - дані, що включають назву ліків, дозу, час прийому та
статус (прийнято/не прийнято);
− сповіщення - візуальні та звукові нагадування про час прийому ліків,
адаптовані для осіб з обмеженими можливостями;
− інтерфейс із змінним розміром шрифту - функція, що дозволяє
налаштовувати розмір тексту для покращення доступності;
− сервер - компонент системи, який обробляє запити клієнтів, зберігає дані
та забезпечує їх синхронізацію;
− Tkinter - бібліотека Python для створення графічного інтерфейсу
користувача, використана в системі TheCure.
Цей словник забезпечує чітке визначення ключових понять, що
використовуються в процесі розробки системи TheCure, сприяючи однозначному
розумінню її компонентів і функціональності [25].
2.1.2 Елементи моделювання предметної області
Для моделювання предметної області системи TheCure використано
елементи UML (Unified Modeling Language), які дозволяють наочно представити
23
ЧДТУ 252162-014ПЗ
структуру та функціональність системи (рисунок 2.1, рисунок 2.2). Основні
елементи включають класи, атрибути, методи, асоціації та діаграми класів.
Використання UML сприяє чіткому опису взаємодій між компонентами системи,
полегшує комунікацію між розробниками та забезпечує ефективне проектування,
реалізацію та тестування програмного забезпечення [26].
Рисунок 2.1 – Основні графічні символи UML[26]
24
ЧДТУ 252162-014ПЗ
Рисунок 2.2 – Єднальні елементи UML[26]
Використання UML дозволяє створити чітку та зрозумілу модель системи,
що полегшує її розробку, тестування та подальше вдосконалення, особливо для
забезпечення доступності для осіб з обмеженими можливостями [27].
2.1.3 Робоча область моделювання
Робоча область моделювання (рисунок 2.3) охоплює всі аспекти системи
TheCure, які підлягають аналізу, моделюванню та реалізації. Вона включає опис
сутностей, їх атрибутів, взаємодій і функцій, необхідних для автоматизації
управління прийомом ліків.
25
ЧДТУ 252162-014ПЗ
Рисунок 2.3 – Модель предметної області
Основні компоненти робочої області:
1 Користувачі (Users):
− пацієнт (Patient);
− лікар (Doctor).
2 Призначення (Medications):
3 Ліки (Medicine):
4 Сповіщення (Notifications):
26
ЧДТУ 252162-014ПЗ
5 Сервер (Server):
Робоча область моделювання забезпечує чітке розуміння всіх аспектів
системи, що підлягають автоматизації, сприяючи створенню ефективного та
доступного програмного забезпечення для людей з обмеженими можливостями.
2.2 Формування та аналіз вимог
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
Формування вимог до програмного забезпечення є ключовим етапом у
розробці системи контролю прийому ліків, призначеної для людей з обмеженими
можливостями. Цей процес включає збір, аналіз, документування та управління
вимогами, що забезпечує відповідність системи потребам користувачів та
технічним можливостям розробки [28]. Система, реалізована в коді проєкту,
враховує особливості цільової аудиторії, зокрема осіб з обмеженими
можливостями, забезпечуючи доступність, зручність використання та надійність.
Первинні вимоги визначають загальні функції системи, які забезпечують
виконання її основних завдань:
− система повинна надавати можливість реєстрації та автентифікації
користувачів (пацієнтів і лікарів) із введенням логіну та пароля;
− пацієнти повинні отримувати сповіщення про час прийому ліків із
візуальними та звуковими сигналами;
− лікарі повинні мати змогу призначати, редагувати та видаляти ліки для
пацієнтів;
− система повинна відображати список призначень із деталями (назва ліків,
дозування, час прийому, статус);
− система повинна підтримувати зміну розміру шрифту для забезпечення
доступності для осіб із вадами зору.
Детальні вимоги уточнюють первинні, надаючи конкретні описи функцій,
інтерфейсів і даних:
27
ЧДТУ 252162-014ПЗ
1 Реєстрація та автентифікація:
− форма реєстрації повинна включати поля для введення логіну (мін. 3
символи), пароля (мін. 3 символи) та вибір ролі (пацієнт або лікар);
− після успішної реєстрації користувач отримує підтвердження.
2 Сповіщення про прийом ліків:
− сповіщення відображаються у вигляді спливаючого вікна з червоно-
жовтим миготінням та звуковим сигналом (5 сигналів);
− вікно сповіщення автоматично закривається через 30 секунд або після
підтвердження користувачем.
3 Керування призначеннями (для лікарів):
− інтерфейс дозволяє додавати, редагувати та видаляти призначення,
вказуючи ID пацієнта, назву ліків, дозу та час прийому;
− лікарі можуть переглядати список зареєстрованих пацієнтів.
4 Відображення призначень:
− таблиця призначень містить стовпці: ID, пацієнт (для лікарів), назва
ліків, доза, час, статус (прийнято/не прийнято);
− пацієнти можуть позначати прийом ліків через кнопку у таблиці.
5 Доступність:
− можливість зміни розміру шрифту в діапазоні від 8 до 20 пікселів;
− інтерфейс підтримує контрастні кольори для статусних індикаторів
(зелений для активного стану, червоний для неактивного).
Вимоги замовника відображають потреби кінцевих користувачів, зокрема
осіб з обмеженими можливостями:
− інтерфейс системи повинен бути інтуїтивно зрозумілим і доступним для
людей із вадами зору чи слуху;
− система повинна забезпечувати надійне сповіщення про час прийому
ліків із візуальними та звуковими сигналами;
− дані користувачів мають бути захищеними, а доступ до них — обмеженим
за ролями (пацієнт/лікар).
28
ЧДТУ 252162-014ПЗ
Вимоги розробника стосуються технічних аспектів реалізації системи:
− система розроблена на Python з використанням бібліотеки Tkinter для
створення графічного інтерфейсу;
− для зберігання та обробки даних використовується клієнт-серверна
архітектура з комунікацією через сокети (JSON-запити до сервера на
localhost:5000);
− система повинна бути стійкою до помилок із механізмами автоматичного
перепідключення до сервера у разі збою.
Функціональні вимоги описують конкретні дії, які система виконує:
− реєстрація та автентифікація користувачів (пацієнтів і лікарів);
− відображення сповіщень про час прийому ліків із візуальними та
звуковими ефектами;
− керування призначеннями лікарями (додавання, редагування, видалення);
− позначення пацієнтами факту прийому ліків;
− перегляд списку призначень та інформації про пацієнтів;
Нефункціональні вимоги визначають якісні характеристики системи:
− доступність. Інтерфейс адаптований для осіб із вадами зору через
можливість зміни розміру шрифту та контрастні кольори;
− продуктивність. Перевірка часу прийому ліків виконується кожні 15
секунд, сповіщення відображаються в межах 5-хвилинного вікна;
− безпека. Дані передаються через JSON-запити з контролем доступу за
ролями;
− надійність: Система підтримує автоматичне перепідключення до сервера
у разі збою;
− зручність використання. Інтуїтивний інтерфейс із підтримкою
спливаючих вікон і чіткими повідомленнями про помилки.
Формування вимог є основою для створення системи, яка відповідає
потребам користувачів, особливо осіб з обмеженими можливостями, та технічним
можливостям розробки.
29
ЧДТУ 252162-014ПЗ
2.2.2 Формування вимог за допомогою діаграми прецедентів
Діаграма прецедентів (Use Case Diagram) є інструментом для візуалізації
взаємодії користувачів (акторів) із системою через набір функціональних
можливостей (прецедентів). У контексті системи контролю прийому ліків діаграма
відображає взаємодію пацієнтів і лікарів із додатком, враховуючи особливості
доступності для людей з обмеженими можливостями [29] (рисунок 2.4).
Рисунок 2.4 – Діаграма прецедентів додатку контролю прийому ліків
Опис акторів і прецедентів:
1 Реєстрація та автентифікація
Актори: Пацієнт, Лікар.
Опис: Користувачі вводять логін і пароль для входу в систему або створюють
новий обліковий запис, обираючи роль (пацієнт/лікар). Після успішної
автентифікації відкривається головний інтерфейс, адаптований до ролі.
2 Отримання сповіщень про прийом ліків
Актор: Пацієнт.
Опис: Система автоматично перевіряє час прийому ліків і відображає
сповіщення у вигляді спливаючого вікна з миготінням (червоний/жовтий) та
30
ЧДТУ 252162-014ПЗ
звуковим сигналом. Пацієнт може підтвердити прийом або дочекатися
автоматичного закриття вікна.
3 Керування призначеннями
Актор: Лікар.
Опис: Лікар додає, редагує або видаляє призначення, вказуючи ID пацієнта,
назву ліків, дозу та час прийому. Інтерфейс дозволяє переглядати список
зареєстрованих пацієнтів для вибору ID.
4 Позначення прийому ліків
Актор: Пацієнт.
Опис: Пацієнт обирає призначення з таблиці та позначає його як прийняте.
Статус оновлюється в таблиці, а інформація надсилається на сервер.
5 Зміна розміру шрифту
Актори: Пацієнт, Лікар.
Опис: Користувачі можуть збільшувати або зменшувати розмір шрифту
через кнопки A+/A- для покращення читабельності, що є важливим для осіб із
вадами зору.
Діаграма прецедентів забезпечує чітке уявлення про функціональні
можливості системи та взаємодію користувачів із нею. Вона допомагає
розробникам спланувати інтерфейс і функціонал, враховуючи потреби людей з
обмеженими можливостями, що сприяє створенню доступного та ефективного
додатка.
2.3 Проектування логічної структури програмного комплексу
У цьому підрозділі детально розглядається проектування логічної
архітектури програмного комплексу «TheCure» для контролю прийому ліків, з
акцентом на адаптацію для людей з обмеженими можливостями. Спочатку буде
представлено діаграму класів, яка ілюструє взаємодію між класами, їх атрибути та
методи, що дозволяє зрозуміти структуру і поведінку об’єктів у системі. Далі буде
розглянута діаграма пакетів, яка відображає організацію класів у логічні групи
(пакети), визначаючи залежності між ними та сприяючи управлінню складністю
31
ЧДТУ 252162-014ПЗ
системи [25].
2.3.1 Діаграма класів
Для розуміння структури та взаємодії компонентів системи спроектовано
діаграму класів, яка відображає основні класи та їх зв’язки (рисунок 2.5).
Рисунок 2.5 – Діаграма класів додатку контролю прийому ліків
Діаграма включає чотири основні класи:
− MedicineTrackerApp – основний клас додатка, який керує інтерфейсом
і логікою системи;
− Patient представляє користувача-пацієнта, який взаємодіє з
призначеннями ліків;
− Doctor представляє користувача-лікаря, який керує призначеннями;
− Medication містить інформацію про призначення ліків.
Клас MedicineTrackerApp
Атрибути:
− root: Tk (об’єкт головного вікна Tkinter);
32
ЧДТУ 252162-014ПЗ
− user_id: int (ідентифікатор користувача);
− user_role: String (роль користувача: «patient» або «doctor»);
− current_font_size: int (розмір шрифту інтерфейсу);
− client: Socket (з’єднання з сервером);
− status_label: Label (індикатор стану відстеження);
− tracking_active: Boolean (стан відстеження).
Методи:
− setup_connection(): void (налаштування з’єднання з сервером);
− create_login_frame(): void (створення вікна входу);
− create_main_frame(): void (створення головного вікна);
− update_medications_list(): void (оновлення списку призначень);
− increase_font_size(): void (збільшення розміру шрифту);
− decrease_font_size(): void (зменшення розміру шрифту);
− check_medication_times(): void (перевірка часу прийому ліків).
Клас Patient
Атрибути:
− user_id: int (ідентифікатор пацієнта);
− username: String (логін);
− password: String (пароль).
Методи:
− login(): void (вхід у систему);
− mark_medication_taken(): void (відмітка про прийом ліків);
− view_medications(): List<medication> (перегляд
призначень).</medication>
Клас Doctor
Атрибути:
− user_id: int (ідентифікатор лікаря);
− username: String (логін);
− password: String (пароль).
33
ЧДТУ 252162-014ПЗ
Методи:
− login(): void (вхід у систему);
− add_medication(): void (додавання призначення);
− edit_medication(): void (редагування призначення);
− delete_medication(): void (видалення призначення);
− show_patients_list(): void (перегляд списку пацієнтів).
Клас Medication
Атрибути:
− med_id: int (ідентифікатор призначення);
− patient_id: int (ідентифікатор пацієнта);
− medicine_name: String (назва ліків);
− dosage: String (дозування);
− time: String (час прийому);
− status: Boolean (стан прийому).
Методи:
− get_medication(): Medication (отримання даних про призначення);
− update_status(): void (оновлення статусу прийому).
Зв’язки між класами:
− MedicineTrackerApp -> Patient: керує інформацією про пацієнта
(асоціація);
− MedicineTrackerApp -> Doctor: керує інформацією про лікаря (асоціація);
− MedicineTrackerApp -> Medication: обробляє дані про призначення ліків
(агрегація);
− Doctor -> Medication: створює, редагує та видаляє призначення
(асоціація);
− Patient -> Medication: переглядає та відмічає прийом ліків (асоціація).
Ця діаграма класів забезпечує чітке уявлення про структуру системи, її
основні компоненти та їх взаємодію, що є важливим для реалізації
функціональності, адаптованої для користувачів з обмеженими можливостями [30].
34
ЧДТУ 252162-014ПЗ
2.3.2 Діаграма пакетів
Діаграма пакетів у UML використовується для відображення високорівневої
організації системи, групуючи класи в логічні модулі (пакети) та визначаючи
залежності між ними (рисунок 2.6).
Рисунок 2.6 – Діаграма пакетів додатку контролю прийому ліків
Для програмного комплексу «TheCure» виділено чотири основні пакети:
− User Management: керування користувачами (пацієнти та лікарі);
− Medication Management: обробка даних про призначення ліків;
− Interface Management: управління графічним інтерфейсом;
35
ЧДТУ 252162-014ПЗ
− Notification System: обробка сповіщень про прийом ліків.
Пакет User Management
Містить класи:
− Patient (атрибути: user_id, username, password; методи: login,
mark_medication_taken, view_medications);
− Doctor (атрибути: user_id, username, password; методи: login,
add_medication, edit_medication, delete_medication, show_patients_list).
Функціональність:
− реєстрація та авторизація користувачів;
− управління інформацією про користувачів (пацієнтів і лікарів).
Пакет Medication Management
Містить клас:
Medication (атрибути: med_id, patient_id, medicine_name, dosage, time, status;
методи: get_medication, update_status).
Функціональність:
− зберігання та обробка даних про призначення ліків;
− оновлення статусу прийому ліків.
Пакет Interface Management
Містить частину класу MedicineTrackerApp, пов’язану з інтерфейсом
(атрибути: root, current_font_size, status_label; методи: create_login_frame,
create_main_frame, increase_font_size, decrease_font_size).
Функціональність:
− управління графічним інтерфейсом;
− адаптація інтерфейсу для людей з обмеженими можливостями через зміну
розміру шрифту та візуальні сповіщення.
Пакет Notification System
Містить частину класу MedicineTrackerApp, пов’язану зі сповіщеннями
(атрибути: tracking_active; методи: check_medication_times, show_notification,
flash_notification, play_alarm).
Функціональність:
36
ЧДТУ 252162-014ПЗ
− перевірка часу прийому ліків;
− відображення візуальних і звукових сповіщень для користувачів з
обмеженими можливостями.
Залежності між пакетами:
− Interface Management залежить від User Management і Medication
Management для відображення даних користувачів і призначень;
− Notification System залежить від Medication Management для перевірки
часу прийому ліків;
− User Management залежить від Medication Management для обробки
призначень лікарями та пацієнтами.
Діаграма пакетів допомагає структурувати систему на високому рівні,
забезпечуючи чітке розуміння її модульної організації та взаємодії компонентів, що
сприяє ефективному розробленню та підтримці програмного комплексу [23].
2.4 Архітектура проектування
У цьому підрозділі розглядається архітектура програмного забезпечення
системи контролю прийому ліків, розробленої для людей з обмеженими
можливостями. Основна увага приділяється діаграмі компонентів, яка ілюструє
взаємодію між програмними модулями, їхні інтерфейси та залежності. Також
описано розгортання програмної системи на апаратних засобах, що відображено на
діаграмі розгортання.
Ці діаграми дозволяють зрозуміти як логічну структуру системи, так і її
фізичну реалізацію на апаратному рівні, що сприяє ефективному плануванню,
розробці та підтримці системи.
2.4.1 Діаграма компонентів
Діаграма компонентів у нотації UML використовується для відображення
структури програмної системи, показуючи її основні компоненти, їхні функції та
взаємозв’язки [30] (рисунок 2.7).
37
ЧДТУ 252162-014ПЗ
Рисунок 2.7 – Діаграма компонентів додатку контролю прийому ліків
Для системи контролю прийому ліків діаграма компонентів включає наступні
елементи, які забезпечують функціонування програми та підтримку доступності
для користувачів з обмеженими можливостями.
Client Application
Функції:
38
ЧДТУ 252162-014ПЗ
− забезпечує графічний інтерфейс користувача (GUI) для взаємодії з
системою;
− реалізує функції авторизації, реєстрації, відображення списку призначень
та відмітки прийому ліків;
− підтримує функції доступності, такі як зміна розміру шрифту та
звукові/візуальні сповіщення.
Залежності:
− Server API: відправлення запитів та отримання даних від сервера;
− Notification Service: відображення сповіщень про час прийому ліків.
Notification Service
Функції:
− генерація візуальних та звукових сповіщень для нагадування про прийом
ліків;
− реалізація миготливого візуального ефекту та звукового сигналу для осіб
з обмеженими можливостями.
Залежності:
− Client Application: інтеграція з інтерфейсом для відображення
сповіщень.
Server API
Функції:
− обробка запитів від клієнтського додатка (реєстрація, авторизація,
управління призначеннями);
− забезпечення комунікації між клієнтом та базою даних.
Залежності:
− Database Service: збереження та отримання даних про користувачів і
призначення.
Database Service
Функції:
− зберігання даних про користувачів (лікарів і пацієнтів), призначення
ліків, статуси прийому;
39
ЧДТУ 252162-014ПЗ
− забезпечення швидкого доступу до даних для обробки запитів.
Залежності:
− використовується Server API для обробки даних.
Authentication Service
Функції:
− обробка процесів авторизації та реєстрації користувачів;
− перевірка логінів і паролів, створення нових облікових записів.
Залежності:
− Server API: передача запитів на авторизацію;
− Database Service: збереження облікових даних користувачів.
Діаграма компонентів забезпечує чітке уявлення про модульну структуру
системи, демонструючи, як компоненти взаємодіють через визначені інтерфейси.
Це сприяє зрозумілості архітектури та полегшує подальшу розробку і
масштабування системи.
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Розгортання програмної системи на апаратних засобах передбачає
розміщення її компонентів на відповідних фізичних або віртуальних пристроях.
Для системи контролю прийому ліків розгортання включає клієнтський додаток,
серверну частину та базу даних, що забезпечують стабільну роботу та доступність
для користувачів [24].
Клієнтський пристрій
Компоненти: Client Application, Notification Service.
Опис: Клієнтський додаток розгортається на персональних комп’ютерах
користувачів (пацієнтів або лікарів). Він реалізує графічний інтерфейс, створений
за допомогою бібліотеки Tkinter, і підтримує функції доступності, такі як зміна
розміру шрифту та звукові сповіщення.
Апаратні вимоги: Персональний комп’ютер з операційною системою
Windows, macOS або Linux, що підтримує Python та Tkinter.
40
ЧДТУ 252162-014ПЗ
Сервер додатків
Компоненти: Server API, Authentication Service.
Опис: Сервер обробляє запити від клієнтських додатків, забезпечуючи
авторизацію, управління призначеннями та комунікацію з базою даних.
Використовується протокол TCP/IP для зв’язку через сокети.
Апаратні вимоги: Серверна машина або віртуальний сервер з достатніми
обчислювальними ресурсами (процесор, пам’ять) для обробки множинних
клієнтських запитів.
Сервер бази даних
Компоненти: Database Service.
Опис: Зберігає дані про користувачів, призначення ліків та їх статуси.
Використовується реляційна база даних (наприклад, SQLite або MySQL) для
гнучкого зберігання та швидкого доступу до даних.
Апаратні вимоги: Серверна машина або хмарний сервіс із достатнім обсягом
пам’яті для зберігання даних і швидким доступом до диска.
Діаграма розгортання зображена на рисунку 2.8.
Рисунок 2.8 – Діаграма розгортання додатку контролю прийому ліків
41
ЧДТУ 252162-014ПЗ
Діаграма розгортання відображає наступні взаємодії:
− клієнтський пристрій взаємодіє з Сервером додатків через мережу
(локальну або Інтернет) для відправлення запитів та отримання даних;
− сервер додатків комунікує з Сервером бази даних для збереження та
отримання інформації;
− Notification Service працює локально на клієнтському пристрої,
забезпечуючи сповіщення без прямого доступу до сервера.
Ця діаграма ілюструє фізичну організацію системи, допомагаючи зрозуміти,
як компоненти розподілені між апаратними засобами. Вона є ключовою для
планування ресурсів, забезпечення масштабованості та надійності системи, а також
для підтримки користувачів з обмеженими можливостями шляхом забезпечення
стабільної роботи всіх компонентів.
2.5 Моделювання поведінки системи
У цьому підрозділі розглядаються динамічні аспекти функціонування
системи контролю прийому ліків, розробленої для людей з обмеженими
можливостями. Для аналізу поведінки системи використовуються діаграми UML,
які дозволяють детально описати потоки дій, взаємодію об’єктів та стани системи.
Спочатку представлено діаграму діяльності, яка відображає потік управління та
виконання завдань у системі. Далі розглядається діаграма послідовності, яка
демонструє хронологічну взаємодію об’єктів. Діаграма комунікації ілюструє
структурні зв’язки між об’єктами системи. Нарешті, діаграма скінченного автомату
відображає можливі стани системи та переходи між ними залежно від подій.
2.5.1 Діаграма діяльності
Діаграма діяльності (Activity Diagram) в UML використовується для
моделювання поведінки системи, показуючи послідовність дій від початку до
завершення процесу. Вона відображає кроки, які виконуються в системі, їхні
взаємозв’язки, а також умови розгалуження для різних типів користувачів.
42
ЧДТУ 252162-014ПЗ
Діаграма діяльності (рисунок 2.9) з розгалуженням на ролі пацієнта та лікаря
чітко ілюструє різні потоки дій для кожного типу користувачів. Це дозволяє
зрозуміти, як користувачі взаємодіють із системою та які функції їм доступні.
Рисунок 2.9 – Діаграма діяльності додатку контролю прийому ліків
Опис кроків діяльності, зображених на діаграмі діяльності:
Пацієнт
1 Запустити додаток:
− користувач відкриває додаток TheCure.
2 Відкрити головне меню:
− система відображає головне меню з опціями: вхід, реєстрація,
перегляд призначень ліків, відмітка прийому ліків.
3 Реєстрація пацієнта:
− користувач обирає опцію реєстрації;
43
ЧДТУ 252162-014ПЗ
− вводить логін, пароль та обирає роль «пацієнт»;
− підтверджує реєстрацію.
4 Перегляд призначень ліків:
− користувач обирає опцію перегляду призначень;
− система відображає список призначень із назвами ліків, дозуванням,
часом прийому та статусом.
5 Відмітка прийому ліків:
− користувач обирає призначення зі списку;
− підтверджує прийом ліків.
6 Отримання сповіщення:
− система автоматично надсилає сповіщення про час прийому ліків (з
візуальним та звуковим сигналом);
− користувач підтверджує сповіщення.
Лікар
1 Запустити додаток:
− користувач відкриває додаток TheCure.
2 Відкрити головне меню:
− система відображає головне меню з опціями: вхід, перегляд списку
пацієнтів, додавання/редагування/видалення призначень.
3 Перегляд списку пацієнтів:
− лікар обирає опцію перегляду списку пацієнтів;
− система відображає список зареєстрованих пацієнтів з їхніми
ідентифікаторами та іменами.
4 Додавання призначення:
− лікар обирає опцію додавання призначення;
− вводить ID пацієнта, назву ліків, дозування та час прийому;
− підтверджує додавання.
5 Редагування призначення:
− лікар обирає призначення зі списку;
44
ЧДТУ 252162-014ПЗ
− вносить зміни до назви ліків, дозування або часу прийому;
− підтверджує редагування.
6 Видалення призначення:
− лікар обирає призначення зі списку;
− підтверджує видалення.
Діаграма діяльності з розгалуженням на ролі дозволяє чітко побачити, як
пацієнти та лікарі взаємодіють із системою, які функції доступні кожному типу
користувачів, та як ці функції реалізуються в додатку.
2.5.2 Діаграма послідовності
Діаграма послідовності (Sequence Diagram) відображає взаємодію між
об’єктами системи в хронологічному порядку, показуючи, які повідомлення
передаються між об’єктами та в якій послідовності.
Перша діаграма (рисунок 2.10) за сценарієм реєстрації пацієнта та перегляду
призначень ліків.
Рисунок 2.10 – Діаграма послідовності за сценарієм реєстрації пацієнта та
перегляду призначень ліків
45
ЧДТУ 252162-014ПЗ
Опис кроків, зображених на першій діаграмі:
1 Запуск додатка:
− пацієнт відкриває додаток;
− додаток відображає екран входу/реєстрації.
2 Реєстрація пацієнта:
− пацієнт обирає опцію реєстрації;
− додаток запитує введення логіна, пароля та ролі;
− пацієнт вводить дані (логін, пароль, роль «пацієнт»);
− додаток надсилає запит на сервер для реєстрації;
− сервер зберігає дані в базі даних;
− база даних підтверджує успішне збереження;
− сервер повертає підтвердження додатку;
− додаток повідомляє пацієнта про успішну реєстрацію.
3 Перегляд призначень ліків:
− пацієнт обирає опцію перегляду призначень;
− додаток надсилає запит на сервер для отримання списку призначень;
− сервер запитує дані з бази даних;
− база даних повертає список призначень;
− сервер передає дані додатку;
− додаток відображає список призначень (ID, назва ліків, дозування,
час, статус).
Друга діаграма (рисунок 2.11) за сценарієм додавання лікарем нового
призначення.
Опис кроків, зображених на другій діаграмі:
1 Запуск додатка:
− лікар відкриває додаток;
− додаток відображає екран входу.
2 Додавання призначення:
46
ЧДТУ 252162-014ПЗ
− лікар обирає опцію додавання призначення;
− додаток запитує введення даних (ID пацієнта, назва ліків, дозування,
час);
− лікар вводить дані;
− додаток надсилає запит на сервер для додавання призначення;
− сервер зберігає дані в базі даних;
− база даних підтверджує успішне збереження;
− сервер повертає підтвердження додатку;
− додаток повідомляє лікаря про успішне додавання призначення.
Рисунок 2.11 – Діаграма послідовності за сценарієм додавання лікарем нового
призначення
Діаграми послідовності для сценаріїв реєстрації та додавання призначення
дозволяють чітко візуалізувати послідовність взаємодій між користувачами,
додатком, сервером і базою даних, що сприяє кращому розумінню реалізації
функціональності.
47
ЧДТУ 252162-014ПЗ
2.5.3 Діаграма комунікації
Діаграма комунікації (Communication Diagram) описує взаємодію об’єктів у
системі, акцентуючи увагу на структурних зв’язках між ними та обміном
повідомленнями між компонентами під час роботи додатку.
Опис послідовності дій, зображених на діаграмі комунікації (рисунок 2.12)
для сценарію взаємодії користувача з програмою TheCure:
1 Користувач → Додаток (MedicineTrackerApp): Взаємодія з GUI
Користувач запускає програму та здійснює дії через графічний інтерфейс
(вхід у систему, перегляд ліків, додавання даних тощо).
2 MedicineTrackerApp → Модуль Tkinter: Побудова інтерфейсу
Програма створює графічний інтерфейс за допомогою модуля Tkinter.
3 MedicineTrackerApp → Модуль messagebox: Відображення повідомлень
Для інформування користувача про помилки або події (наприклад, невірний
логін) використовується messagebox.
4 MedicineTrackerApp → Модуль socket: З'єднання з сервером
Додаток встановлює мережеве з'єднання із сервером для обміну даними.
5 MedicineTrackerApp → Модуль json: Серіалізація/десеріалізація запитів
Дані користувача та запити серіалізуються у формат JSON для надсилання на
сервер.
6 MedicineTrackerApp → Модуль threading: Перевірка часу прийому ліків
За допомогою багатопотоковості виконується фоновий контроль часу
прийому медикаментів та надсилання сповіщень.
7 MedicineTrackerApp → Сервер: Відправка запитів (login,
get_medications,...)
Додаток надсилає на сервер запити для входу в систему, отримання списку
медикаментів, оновлення даних тощо.
8 Сервер → MedicineTrackerApp: Відповіді на запити
Сервер обробляє запити та надсилає відповіді (дані користувача, список ліків,
підтвердження дій тощо).
48
ЧДТУ 252162-014ПЗ
Рисунок 2.12 – Діаграма комунікацій додатку контролю прийому ліків
Дана діаграма комунікації демонструє архітектуру клієнтської частини
програми TheCure, її взаємодію з модулями Python та сервером, а також спосіб
реалізації фонової логіки та обміну даними. Це дозволяє зрозуміти, як відбувається
передача інформації між користувачем, додатком і сервером у реальному часі.
2.5.4 Діаграма скінченного автомату
Діаграма скінченного автомату (State Machine Diagram) моделює поведінку
системи через відображення її станів і переходів між ними залежно від подій.
Опис станів діаграми скінченого автомату (рисунок 2.13):
1 Неактивний:
− початковий стан, коли додаток не запущено.
2 Активний:
− основний стан після запуску додатка;
− містить вкладені стани для різних функцій.
3 Вкладені стани активного стану:
− головне меню: відображається після запуску додатка; користувач
обирає функції: вхід, реєстрація, перегляд призначень,
49
ЧДТУ 252162-014ПЗ
додавання/редагування/видалення призначень (для лікаря), відмітка
прийому (для пацієнта);
− реєстрація: користувач вводить логін, пароль і роль; після успішної
реєстрації повертається до головного меню.
− перегляд призначень: користувач переглядає список призначень;
після перегляду повертається до головного меню.
− додавання призначення (для лікаря): лікар вводить дані призначення;
після додавання повертається до головного меню.
− відмітка прийому (для пацієнта): пацієнт підтверджує прийом ліків;
після підтвердження повертається до головного меню.
− сповіщення: система автоматично активує сповіщення про час
прийому ліків; після підтвердження сповіщення повертається до
головного меню.
Рисунок 2.13 – Діаграма скінченого автомата додатку контролю прийому ліків
Діаграма скінченного автомату відображає всі можливі стани системи та
переходи між ними, допомагаючи зрозуміти, як додаток реагує на дії користувачів
і зовнішні події.
50
ЧДТУ 252162-014ПЗ
Висновок до розділу 2
Розділ присвячено впровадженню результатів досліджень у практику
проектування системи TheCure, розробленої для автоматизації контролю прийому
ліків людьми з обмеженими можливостями. Моделювання предметної області,
проведене з використанням UML-діаграм, забезпечило чітке визначення структури,
функціональності та взаємодії компонентів системи. Формування вимог дозволило
врахувати потреби користувачів, зокрема доступність інтерфейсу, а проектування
логічної та фізичної архітектури сприяло створенню модульної та масштабованої
системи. Моделювання поведінки системи через діаграми діяльності,
послідовності, комунікації та скінченного автомату забезпечило детальне
розуміння її роботи, що є основою для ефективної реалізації та підтримки,
адаптованої до потреб цільової аудиторії.
51
ЧДТУ 252162-014ПЗ
РОЗДІЛ 3. КОНСТРУЮВАННЯ ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1 Розробка додатка
Розробка мобільного додатка для контролю прийому ліків для людей з
обмеженими можливостями є складним завданням, яке вимагає врахування
специфічних потреб цільової аудиторії, високого рівня доступності, безпеки та
надійності.
У цьому підрозділі детально розглянуто етапи розробки такого додатка,
включаючи аналіз вимог, вибір технологій, архітектуру програмного забезпечення,
а також особливості реалізації з урахуванням принципів універсального дизайну та
інклюзивності.
3.1.1 Обґрунтування вибору засобів реалізації
Розробка додатка для контролю прийому ліків передбачає використання
інструментів і технологій, які забезпечують простоту реалізації, високу
продуктивність і доступність для користувачів.
Вибір засобів реалізації базується на потребах проекту, таких як підтримка
інклюзивного дизайну, обробка даних у реальному часі та можливість інтеграції з
серверними компонентами.
1 Мова програмування Python.
Python обрано як основну мову програмування через її універсальність і
широкий спектр бібліотек, які спрощують розробку складних систем. Основні
переваги:
− простота та читабельність. Python має зрозумілий синтаксис, що
полегшує розробку та підтримку коду;
− широка підтримка бібліотек. Бібліотека tkinter забезпечує створення
графічного інтерфейсу, а socket і json дозволяють реалізувати клієнт-
серверну взаємодію;
52
ЧДТУ 252162-014ПЗ
− популярність і спільнота. Велика кількість документації та активна
підтримка спільноти сприяють швидкому вирішенню технічних
питань.
2 Бібліотека tkinter для створення інтерфейсу
Бібліотека tkinter обрана для створення графічного інтерфейсу завдяки її
інтеграції з Python, простоті використання та підтримці створення доступних
інтерфейсів. Основні переваги:
− кросплатформеність – tkinter працює на різних операційних системах,
що забезпечує універсальність додатка;
− гнучкість налаштування дозволяє створювати адаптивні інтерфейси з
підтримкою зміни розміру шрифтів для людей з вадами зору;
− вбудована підтримка віджетів забезпечує створення інтерактивних
елементів, таких як кнопки, таблиці та сповіщення.
3 Клієнт-серверна архітектура з використанням socket
Для реалізації взаємодії між клієнтською частиною (додатком) і сервером
використано модуль socket. Його вибір обґрунтовано:
− простота реалізації дозволяє швидко налаштувати зв’язок між клієнтом і
сервером;
− підтримка реального часу забезпечує швидку передачу даних, що
необхідно для відстеження часу прийому ліків;
− надійність – модуль підтримує стабільне з’єднання з можливістю
перепідключення у разі збоїв.
4 Формат JSON для обміну даними
JSON використовується для передачі даних між клієнтом і сервером через
його легкість, універсальність і підтримку структурованих даних. Це забезпечує
ефективну обробку запитів і відповідей.
Вибір Python, tkinter, socket і JSON є оптимальним для створення додатка,
який відповідає вимогам доступності, продуктивності та інклюзивності. Ці
інструменти дозволяють створити надійну систему з інтуїтивно зрозумілим
інтерфейсом, яка враховує потреби людей з обмеженими можливостями.
53
ЧДТУ 252162-014ПЗ
3.1.2 Опис структурної (функціональної) схеми
Структурна (функціональна) схема додатка для контролю прийому ліків
відображає основні компоненти системи та їх взаємодію (рисунок 3.1). Вона
допомагає зрозуміти, як різні модулі програми співпрацюють для забезпечення
функціональності.
Рисунок 3.1 – Структурна (функціональна) схема додатка для контролю прийому
ліків
Схема включає наступні компоненти:
1 Клієнтська частина (додаток):
− інтерфейс входу забезпечує авторизацію та реєстрацію користувачів
(пацієнтів і лікарів);
54
ЧДТУ 252162-014ПЗ
− головне меню дозволяє користувачам взаємодіяти з основними
функціями, такими як перегляд призначень, додавання нових ліків
(для лікарів) або відмітка прийому (для пацієнтів);
− система сповіщень відображає нагадування про прийом ліків із
звуковими та візуальними ефектами;
− таблиця призначень відображає список ліків, дозування, час прийому
та статус;
− налаштування доступності дозволяє змінювати розмір шрифту для
людей з вадами зору.
2 Серверна частина:
− сервіс управління користувачами обробляє авторизацію, реєстрацію
та зберігання даних користувачів;
− сервіс управління призначеннями відповідає за додавання,
редагування, видалення та відстеження статусу прийому ліків;
− сервіс сповіщень надсилає дані про час прийому ліків на клієнтську
частину.
3 База даних:
− дані користувачів зберігає інформацію про логіни, паролі та ролі
(пацієнт або лікар);
− дані призначень містить інформацію про ліки, дозування, час прийому
та статус.
Структурна схема демонструє, як клієнтська частина взаємодіє з сервером
через запити у форматі JSON, а сервер обробляє ці запити, взаємодіючи з базою
даних. Це забезпечує чітке розмежування функціональних модулів і полегшує
масштабування системи.
3.1.3 Опис логічної схеми
Логічна схема (рисунок 3.2) описує послідовність дій у системі для
виконання основних функцій. Вона включає алгоритм роботи додатка,
представлений у текстовому вигляді та у вигляді блок-схеми.
55
ЧДТУ 252162-014ПЗ
Рисунок 3.2 – Логічна схема додатка для контролю прийому ліків
56
ЧДТУ 252162-014ПЗ
Алгоритм функціонування системи
1 Запуск додатка:
− користувач відкриває додаток, відображається вікно авторизації;
− користувач вводить логін і пароль або реєструється, обираючи роль
(пацієнт або лікар).
2 Авторизація:
− додаток відправляє запит (action: login) на сервер із логіном і паролем;
− сервер перевіряє дані в базі та повертає user_id і role;
− у разі успіху відображається головне меню, інакше – повідомлення
про помилку.
3 Реєстрація:
− користувач обирає опцію “Зареєструватися” та вводить логін, пароль
і роль;
− додаток відправляє запит (action: register) на сервер;
− сервер зберігає дані в базі та повертає підтвердження.
4 Перегляд призначень:
− користувач (пацієнт або лікар) обирає опцію перегляду призначень;
− додаток відправляє запит (action: get_medications) із user_id і role;
− сервер повертає список призначень, які відображаються в таблиці.
5 Додавання призначення (лікар):
− лікар обирає опцію “Додати призначення” та вводить ID пацієнта,
назву ліків, дозу і час;
− додаток відправляє запит (action: add_medication);
− сервер зберігає дані та оновлює список призначень.
6 Відмітка прийому ліків (пацієнт):
− пацієнт обирає призначення в таблиці та натискає “Відмітити як
прийнято”;
− додаток відправляє запит (action: mark_taken) із med_id;
− сервер оновлює статус у базі даних.
57
ЧДТУ 252162-014ПЗ
7 Сповіщення про прийом ліків:
− окремий потік перевіряє час призначень кожні 15 секунд;
− якщо поточний час збігається з часом прийому (±5 хвилин),
відображається сповіщення з миготливим фоном і звуковим сигналом;
− користувач підтверджує прийом, і сповіщення закривається.
Логічна схема забезпечує чітке розуміння послідовності дій у системі, від
запуску до виконання ключових функцій, таких як авторизація, управління
призначеннями та сповіщення.
3.1.4 Розробка бази даних
Розробка бази даних є ключовим етапом, оскільки вона забезпечує зберігання
та обробку даних про користувачів і призначення. Для цього проекту обрано
реляційну базу даних, оскільки вона забезпечує структурованість і ефективну
обробку даних.
Процес розробки бази даних
1 Аналіз вимог:
− визначено основні об’єкти: користувачі (users) і призначення
(medications);
− встановлено зв’язки: один користувач (пацієнт або лікар) може мати
кілька призначень.
2 Проектування структури даних:
− створено схеми для таблиць із визначенням полів і типів даних;
− додано індекси для оптимізації запитів, наприклад, за user_id і med_id.
3 Реалізація бази даних:
− налаштовано сервер бази даних для обробки запитів через сокети;
− створено таблиці та додано тестові дані;
− розроблено функції для взаємодії з базою (запити, вставка, оновлення,
видалення).
4 Тестування та оптимізація:
− перевірено коректність запитів і швидкість їх виконання;
58
ЧДТУ 252162-014ПЗ
− оптимізовано індекси для прискорення пошуку даних.
Код таблиці users показана на рисунку 3.3.
Рисунок 3.3 – Код створення таблиці users
Код таблиці medications показана на рисунку 3.4.
Рисунок 3.4 – Код створення таблиці medications
Розробка бази даних (рисунок 3.5) забезпечує надійне зберігання даних і
швидкий доступ до них, що є критично важливим для функціонування системи
сповіщень і управління призначеннями.
59
ЧДТУ 252162-014ПЗ
Рисунок 3.5 – Схема даних (ER-діаграма) додатку контролю прийому ліків
3.1.5 Розробка інтерфейсу користувача
Інтерфейс користувача (UI) є ключовим елементом додатка, оскільки від його
зручності залежить ефективність використання, особливо для людей з обмеженими
можливостями. Процес розробки UI включає аналіз вимог, проектування
компонентів, тестування та оптимізацію.
Вимоги до інтерфейсу:
− доступність – підтримка зміни розміру шрифтів, контрастні кольори та
звукові сигнали для людей з вадами зору чи слуху;
− інтуїтивність – простий і зрозумілий дизайн для всіх категорій
користувачів;
− функціональність – доступ до всіх основних функцій (авторизація,
перегляд призначень, сповіщення).
Проектування основних компонентів інтерфейсу
Вікно авторизації (рисунок 3.6) містить поля для введення логіну та пароля,
кнопки “Увійти” та “Зареєструватися”. Центроване розташування елементів для
зручності сприйняття.
60
ЧДТУ 252162-014ПЗ
Рисунок 3.6 – Вікно авторизації
Головне меню для пацієнтів (рисунок 3.7) відображає таблицю призначень,
кнопку відмітки прийому та індикатор активності, для лікарів додає кнопки для
управління призначеннями (додавання, редагування, видалення).
Рисунок 3.7 – Головне меню пацієнта
Рисунок 3.8 – Головне меню лікаря
61
ЧДТУ 252162-014ПЗ
Таблиця призначень (рисунок 3.9) відображає ID, назву ліків, дозу, час і
статус, підтримує прокрутку за допомогою скролбару.
Рисунок 3.9 – Таблиця призначень
Налаштування шрифтів (рисунок 3.10)
− кнопки “A+” і “A-” дозволяють змінювати розмір шрифту (від 8 до 20);
− оновлення застосовується до всіх елементів інтерфейсу.
Рисунок 3.10 – Налаштування шрифтів
Інтерфейс розроблено з урахуванням принципів універсального дизайну, що
забезпечує доступність для людей з обмеженими можливостями. Тестування UI
дозволило оптимізувати швидкість відгуку та зручність взаємодії.
3.1.6 Опис розробки програмних компонентів
Розробка програмних компонентів додатка включає створення модулів, які
відповідають за основні функції системи. Кожен компонент реалізовано з
урахуванням вимог до надійності, доступності та ефективності.
Основні програмні компоненти
1 Компонент авторизації та реєстрації
62
ЧДТУ 252162-014ПЗ
Призначення: забезпечує вхід і реєстрацію користувачів.
Реалізація: методи login і register відправляють запити (action: login, action:
register) на сервер, обробляючи відповіді для створення головного меню.
2 Компонент управління призначеннями
Призначення: дозволяє додавати, редагувати, видаляти та відмічати прийом
ліків.
Реалізація: методи add_medication, update_medication, delete_medication,
mark_medication_taken відправляють відповідні запити на сервер.
3 Компонент сповіщень
Призначення: нагадує про прийом ліків у заданий час.
Реалізація: метод check_medication_times у окремому потоці перевіряє час
призначень і викликає show_notification для відображення сповіщень із миготливим
фоном і звуком.
4 Компонент інтерфейсу
Призначення: забезпечує відображення елементів UI.
Реалізація: методи create_login_frame, create_main_frame, update_fonts
створюють і оновлюють інтерфейс, підтримуючи адаптивність шрифтів.
5 Компонент зв’язку з сервером
Призначення: забезпечує обмін даними між клієнтом і сервером.
Реалізація: методи setup_connection, send_request, reconnect налаштовують і
підтримують сокет-з’єднання.
Взаємодія компонентів:
− компонент авторизації взаємодіє з сервером через send_request для
перевірки даних користувача;
− компонент управління призначеннями оновлює таблицю через
update_medications_list;
− компонент сповіщень працює асинхронно, перевіряючи час і викликаючи
UI-компоненти;
− компонент зв’язку забезпечує стабільну передачу даних між усіма
модулями.
63
ЧДТУ 252162-014ПЗ
Розробка програмних компонентів забезпечує модульність, масштабованість
і легкість підтримки системи, що відповідає вимогам до додатка для людей з
обмеженими можливостями.
3.2 Тестування системи
У цьому розділі описано процес тестування системи контролю прийому ліків
"TheCure", розробленої для людей з обмеженими можливостями, з метою
забезпечення її надійності, коректної роботи та відповідності вимогам. Тестування
проводилося на різних рівнях: модульне тестування перевіряло окремі компоненти
системи в ізоляції, інтеграційне тестування оцінювало взаємодію між модулями,
системне тестування аналізувало роботу системи як єдиного цілого, а приймальне
тестування підтверджувало відповідність системи очікуванням кінцевих
користувачів. Кожен етап тестування мав на меті виявлення та усунення помилок
для забезпечення високої якості програмного забезпечення.
3.2.1 Модульне тестування
Модульне тестування є першим етапом у процесі забезпечення якості
програмного забезпечення, спрямованим на перевірку окремих компонентів
системи в ізоляції. Метою цього етапу є виявлення помилок у функціональності
окремих модулів до їх інтеграції в загальну систему. Для системи "TheCure"
модульне тестування проводилося з використанням бібліотеки unittest для Python,
яка забезпечує зручне середовище для написання та виконання тестів.
Основні кроки модульного тестування:
1 Налаштування середовища тестування:
− встановлення бібліотеки unittest;
− створення тестових файлів для перевірки окремих методів класу
MedicineTrackerApp.
2 Написання тестів:
− розробка тестових сценаріїв для перевірки ключових методів, таких
як send_request, parse_time, update_fonts, та інших.
3 Виконання тестів:
64
ЧДТУ 252162-014ПЗ
− запуск тестів за допомогою команди python -m unittest;
− аналіз результатів та виправлення виявлених помилок.
Таблиця 3.1
Результаті модульного тестування
Тестовий Очікуваний Фактичний
Модуль Статус
випадок результат результат
1 2 3 4 5
Запит Запит
Відправка
відправлено, відправлено,
валідного
send_request отримано отримано Пройдено
запиту до
коректну коректну
сервера
відповідь відповідь
Відправка Помилка Помилка
send_request невалідного обробки, статус обробки, статус Пройдено
запиту оновлено оновлено
Парсинг
валідного
Повернення Повернення
parse_time часу Пройдено
870 хвилин 870 хвилин
(наприклад,
"14:30")
Парсинг
Повернення 0 Повернення 0
parse_time невалідного Пройдено
хвилин хвилин
часу
Оновлення
Стилі кнопок і Стилі кнопок і
update_fonts розміру Пройдено
міток оновлено міток оновлено
шрифту
65
ЧДТУ 252162-014ПЗ
Продовження таблиці 3.1
1 2 3 4 5
Оновлення
шрифту Обробка без Обробка без
update_fonts Пройдено
неіснуючої помилок помилок
таблиці
Сповіщення Сповіщення
Перевірка
check_medication відображається відображається
часу прийому Пройдено
_times для валідного для валідного
ліків
часу часу
Перевірка з Обробка Обробка
check_medication
невалідними помилки, статус помилки, статус Пройдено
_times
даними оновлено оновлено
Результати модульного тестування свідчать, що всі ключові методи системи
працюють коректно відповідно до очікуваних результатів. Усі тестові випадки
успішно пройдені, що підтверджує надійність реалізації окремих модулів і створює
основу для подальшого інтеграційного тестування.
3.2.2 Інтеграційне тестування
Інтеграційне тестування проводилося після модульного тестування з метою
перевірки взаємодії між різними модулями системи. Для системи "TheCure" це
включало перевірку коректної роботи взаємодії між клієнтською частиною
(інтерфейсом користувача), сервером і функціями обробки даних.
Основні кроки інтеграційного тестування:
1 Підготовка середовища тестування:
− Налаштування тестового сервера на localhost:5000.
− Ініціалізація тестової бази даних із прикладами призначень ліків.
2 Визначення інтеграційних тестових сценаріїв:
66
ЧДТУ 252162-014ПЗ
− Перевірка взаємодії між функціями авторизації, відправки запитів і
оновлення інтерфейсу.
− Тестування відображення сповіщень на основі даних із сервера.
3 Написання тестів:
− Розробка тестів для перевірки коректності обробки запитів між
клієнтом і сервером.
4 Виконання тестів та аналіз результатів:
− Запуск тестів, аналіз результатів і виправлення помилок.
Таблиця 3.2
Результати інтеграційного тестування
Тестовий Очікуваний Фактичний
Модуль Статус
випадок результат результат
1 2 3 4 5
Користувач Користувач
Вхід із авторизований, авторизований,
Авторизаці
валідними відображається відображається Пройдено
я
даними головний головний
інтерфейс інтерфейс
Помилка Помилка
Вхід із
Авторизаці авторизації, авторизації,
невалідним Пройдено
я відображається відображається
и даними
повідомлення повідомлення
Відображе
Сповіщення Сповіщення
ння
відображається з відображається з
Сповіщення сповіщення Пройдено
коректними коректними
про прийом
даними даними
ліків
67
ЧДТУ 252162-014ПЗ
Продовження таблиці 3.2
1 2 3 4 5
Оновлення Список Список
Оновлення списку оновлено, дані оновлено, дані
Пройдено
списку призначень відображені відображені
після запиту коректно коректно
Результати інтеграційного тестування підтверджують, що модулі системи
взаємодіють коректно, забезпечуючи стабільну роботу при обробці запитів і
відображенні даних. Усі тестові випадки пройдені, що свідчить про готовність
системи до системного тестування.
3.2.3 Системне тестування
Системне тестування проводилося для перевірки системи "TheCure" як
єдиного цілого, щоб переконатися, що вона відповідає функціональним і
нефункціональним вимогам. Цей етап включав тестування всіх аспектів системи,
включаючи зручність використання, продуктивність і підтримку людей з
обмеженими можливостями.
Основні кроки системного тестування:
1 Підготовка тестового середовища:
− Налаштування системи в умовах, наближених до реальних, із
підключенням до сервера та бази даних.
− Використання тестових даних, що відображають реальні сценарії.
2 Визначення тестових сценаріїв:
− Перевірка всіх функцій: авторизація, відображення сповіщень, зміна
розміру шрифту, управління призначеннями.
− Тестування нефункціональних вимог, таких як доступність і
стабільність.
3 Виконання тестів:
− Запуск тестових сценаріїв, збір результатів і документування
помилок.
68
ЧДТУ 252162-014ПЗ
4 Аналіз результатів:
− Виправлення виявлених помилок і повторне тестування.
Таблиця 3.3
Результати системного тестування
Тестовий Очікуваний Фактичний
Модуль Статус
випадок результат результат
Доступ до Доступ до
Успішний вхід
Авторизація головного головного Пройдено
користувача
інтерфейсу інтерфейсу
Сповіщення Сповіщення
Відображення відображається з відображається з
Сповіщення Пройдено
сповіщення миготінням і миготінням і
звуком звуком
Інтерфейс Інтерфейс
Збільшення/
Зміна оновлено з оновлено з
зменшення Пройдено
шрифту новим розміром новим розміром
розміру шрифту
шрифту шрифту
Управління Додавання Призначення Призначення
призначенн нового додано, список додано, список Пройдено
ями призначення оновлено оновлено
Системне тестування підтвердило, що система працює стабільно, відповідає
вимогам і підтримує доступність для людей з обмеженими можливостями. Усі
тестові випадки пройдені, що свідчить про готовність до приймального тестування.
3.2.4 Приймальне тестування
Приймальне тестування є заключним етапом, спрямованим на підтвердження
відповідності системи очікуванням кінцевих користувачів. У тестуванні брали
69
ЧДТУ 252162-014ПЗ
участь реальні користувачі (пацієнти та лікарі), які перевіряли ключові функції
системи в реальних сценаріях використання.
Основні кроки приймального тестування:
1 Підготовка до тестування:
− визначення тестових сценаріїв, що відображають реальні задачі
користувачів;
− залучення групи користувачів (пацієнтів і лікарів).
2 Проведення тестування:
− виконання завдань користувачами: авторизація, перегляд списку ліків,
підтвердження прийому, додавання призначень;
− збір зворотного зв’язку щодо зручності та функціональності.
3 Аналіз результатів:
− оцінка зворотного зв’язку та виконання тестових сценаріїв;
− виправлення виявлених проблем і повторне тестування.
Таблиця 3.4
Результати приймального тестування
Тестовий Очікуваний Фактичний
Модуль Статус
випадок результат результат
1 2 3 4 5
Реєстрація та Успішний Успішний
Авторизація вхід доступ до доступ до Пройдено
користувача системи системи
Відображення
Сповіщення Сповіщення
сповіщення
Сповіщення відображено відображено Пройдено
про прийом
коректно коректно
ліків
70
ЧДТУ 252162-014ПЗ
Продовження таблиці 3.4
1 2 3 4 5
Зміна розміру Інтерфейс Інтерфейс
Зміна шрифту шрифту для оновлено, оновлено, Пройдено
доступності шрифт змінено шрифт змінено
Додавання та Призначення Призначення
Управління
редагування додано/змінено додано/змінено Пройдено
призначеннями
призначень коректно коректно
Приймальне тестування підтвердило, що система "TheCure" відповідає
очікуванням користувачів, є зручною у використанні та готова до впровадження.
Усі тестові випадки пройдені, а користувачі відзначили зручність інтерфейсу та
доступність функцій, що робить систему ефективною для людей з обмеженими
можливостями.
3.3. Приклади впровадження програмного комплексу
У цьому підрозділі наведено приклади реалізованих функцій та можливостей
програмного комплексу «TheCure» для контролю прийому ліків, спеціально
адаптованого для людей з обмеженими можливостями. Ці приклади демонструють,
як розроблені програмні компоненти працюють у реальному середовищі,
забезпечуючи зручний доступ до інформації та сервісів для пацієнтів і лікарів.
1 Вхід та реєстрація користувачів
Функціонал входу та реєстрації (рисунок 3.11) є першим етапом взаємодії
користувача з програмою. Відповідно до коду, метод create_login_frame створює
інтерфейс із полями для введення логіна та пароля, а також кнопками для входу та
переходу до форми реєстрації. У методі show_registration реалізовано діалогове
вікно для створення нового облікового запису з можливістю вибору ролі (пацієнт
або лікар). Інтерфейс адаптовано для людей з обмеженими можливостями завдяки
підтримці зміни розміру шрифтів (методи increase_font_size, decrease_font_size) та
інтуїтивному розташуванню елементів.
71
ЧДТУ 252162-014ПЗ
Рисунок 3.11 – Вхід/Реєстрація
2 Панель пацієнта
Панель пацієнта (рисунок 3.12), реалізована в методі create_main_frame для
ролі patient, відображає таблицю призначень (ttk.Treeview) із даними про назву
ліків, дозу, час прийому та статус. Пацієнти можуть відмітити прийом ліків за
допомогою кнопки, яка викликає метод mark_medication_taken. Функціонал
забезпечує коректне відображення даних, отриманих із сервера через метод
send_request, та їх оновлення після взаємодії. Адаптація для осіб з обмеженими
можливостями включає можливість зміни розміру шрифтів та чітке візуальне
оформлення.
Рисунок 3.12 – Панель пацієнта
3 Сповіщення про час прийому ліків
Функція сповіщення (рисунок 3.13) реалізується в методі
check_medication_times, який працює у фоновому потоці (threading.Thread).
72
ЧДТУ 252162-014ПЗ
Система періодично порівнює поточний час із часом прийому ліків, отриманим із
сервера. У разі відповідності (з 5-хвилинним вікном) викликається метод
show_notification, який створює спливаюче вікно з миготливим фоном. Цей
функціонал враховує потреби людей із вадами зору та слуху, забезпечуючи
помітність сповіщень.
Рисунок 3.13 – Повідомлення про час прийому ліків
4 Панель лікаря
Панель лікаря (рисунок 3.14), реалізована в методі create_main_frame для ролі
doctor, містить додаткові елементи керування: кнопки для перегляду списку
пацієнтів, додавання, редагування та видалення призначень. Таблиця призначень
включає колонку «Пацієнт» для відображення відповідної інформації. Інтерфейс
забезпечує зручність для медичних працівників, а підтримка зміни розміру
шрифтів сприяє доступності для користувачів із обмеженими можливостями.
Рисунок 3.14 – Панель лікаря
73
ЧДТУ 252162-014ПЗ
5 Перегляд списку пацієнтів
Функціонал перегляду списку пацієнтів (рисунок 3.15) реалізовано в методі
show_patients_list, який створює нове вікно з таблицею (ttk.Treeview), що
відображає ID та імена користувачів. Дані отримуються через запит із параметром
action: get_patients. Цей функціонал спрощує лікарям доступ до інформації про
пацієнтів, забезпечуючи швидке завантаження даних і адаптивний інтерфейс.
Рисунок 3.15 – Список зареєстрованих пацієнтів
6 Копіювання ID пацієнта
У вікні списку пацієнтів передбачено кнопку «Копіювати ID обраного
пацієнта» (рисунок 3.16), реалізовану в методі show_patients_list через функцію
copy_id. Вона копіює ID вибраного пацієнта до буфера обміну та відображає
повідомлення про успіх. Цей функціонал полегшує роботу лікаря, дозволяючи
швидко використовувати ID для подальших операцій, таких як додавання
призначень.
74
ЧДТУ 252162-014ПЗ
Рисунок 3.16 – Копіювання ID пацієнта до буферу обміну
7 Додавання призначення
Діалог додавання призначення (рисунок 3.17) реалізовано в методі
show_add_medication_dialog, який створює вікно з полями для введення ID
пацієнта, назви ліків, дози та часу прийому. Поле ID автоматично заповнюється
даними з буфера обміну, якщо вони є числовими, що підвищує зручність. Після
успішного додавання відображається повідомлення про успіх, а таблиця
оновлюється через update_medications_list.
Рисунок 3.17 – Додавання призначення
75
ЧДТУ 252162-014ПЗ
8 Підтвердження додавання призначення
Після успішного додавання призначення (рисунок 3.18) відображається
повідомлення про успіх (messagebox.showinfo) у методі
show_add_medication_dialog. Оновлення таблиці забезпечує актуальність даних, а
зручний інтерфейс спрощує взаємодію для лікарів.
Рисунок 3.18 – Підтвердження додавання призначення
9 Редагування призначення
Функціонал редагування (рисунок 3.19) реалізовано в методі
show_edit_medication_dialog, який дозволяє змінювати назву ліків, дозу та час
прийому для вибраного запису. Поля автоматично заповнюються поточними
значеннями, що забезпечує зручність редагування. Після збереження змін таблиця
оновлюється через update_medications_list.
76
ЧДТУ 252162-014ПЗ
Рисунок 3.19 – Редагування призначення
Ці приклади демонструють основні функції та можливості програмного
комплексу «TheCure», які були впроваджені та успішно працюють у реальному
середовищі. Розроблений додаток забезпечує зручний і доступний доступ до
інформації та керування призначеннями для пацієнтів і лікарів, враховуючи
потреби людей з обмеженими можливостями, підвищуючи ефективність контролю
прийому ліків.
77
ЧДТУ 252162-014ПЗ
Висновки до розділу 3
Розробка та тестування програмного комплексу «TheCure»
продемонстрували успішну реалізацію додатка для контролю прийому ліків,
адаптованого для людей з обмеженими можливостями. Використання Python,
tkinter, socket і JSON забезпечило створення доступного, інтуїтивного інтерфейсу
та надійної клієнт-серверної взаємодії. Структурна та логічна схеми, а також база
даних, гарантують ефективну обробку даних і масштабування системи. Тестування
на всіх рівнях – модульному, інтеграційному, системному та приймальному –
підтвердило стабільність, функціональність і відповідність вимогам інклюзивності.
Впроваджені функції, такі як сповіщення, зміна шрифтів і управління
призначеннями, забезпечують зручність для користувачів, сприяючи підвищенню
якості медичного супроводу.
78
ЧДТУ 252162-014ПЗ
ВИСНОВКИ
Розробка програмного забезпечення для контролю прийому ліків,
орієнтованого на людей з обмеженими можливостями, є актуальним завданням,
оскільки сучасні рішення часто не враховують специфічні потреби осіб із
сенсорними чи фізичними обмеженнями. Проблема своєчасного прийому
медикаментів для таких користувачів залишається критичною, адже порушення
режиму лікування може мати серйозні наслідки для здоров’я. Існуючі системи, як
правило, обмежуються базовими функціями сповіщень і не забезпечують належної
адаптивності інтерфейсу для людей із порушеннями зору, слуху чи моторики. У
рамках кваліфікаційної роботи бакалавра було створено програмний додаток
«TheCure», який вирішує цю проблему шляхом поєднання інклюзивного дизайну,
адаптивного інтерфейсу та надійної клієнт-серверної архітектури, що забезпечує
ефективну взаємодію між пацієнтами та лікарями.
Методи вирішення наукової задачі. Для реалізації поставленої мети –
створення доступного додатка для контролю прийому ліків – використано
системний підхід, який включав аналіз потреб цільової аудиторії, проектування
клієнт-серверної архітектури та розробку адаптивного інтерфейсу. Аналіз потреб
проводився шляхом вивчення вимог осіб із сенсорними та моторними
обмеженнями, що дозволило визначити ключові аспекти доступності, такі як
масштабування шрифтів, контрастні кольорові схеми та мультимодальні
сповіщення. Об’єктно-орієнтоване програмування в Python із використанням
бібліотеки Tkinter забезпечило створення інтуїтивного графічного інтерфейсу, а
застосування сокетів для клієнт-серверної взаємодії гарантувало стабільність
обміну даними. Моделювання за допомогою UML-діаграм (прецедентів, класів,
послідовності) сприяло чіткому структуруванню системи та виявленню
потенційних проблем на етапі проектування.
Практичний аналіз та порівняння з іншими рішеннями. Розроблений
додаток «TheCure» вирізняється комплексним підходом до забезпечення
доступності. На відміну від багатьох аналогів, які обмежуються стандартними
сповіщеннями, «TheCure» пропонує адаптивний інтерфейс із можливістю зміни
79
ЧДТУ 252162-014ПЗ
розміру шрифтів (8–20 pt), візуальними (миготіння червоно-жовтого фону) та
звуковими сповіщеннями, що відповідає стандартам WCAG 2.1. Порівняно з
типовими рішеннями, такими як мобільні додатки для нагадувань, «TheCure»
інтегрує функції для лікарів (управління призначеннями, перегляд списку
пацієнтів) і забезпечує синхронізацію даних у реальному часі через сокети. Клієнт-
серверна архітектура дозволяє обробляти до 100 одночасних користувачів.
System: користувачів без зниження продуктивності, що перевищує
можливості більшості аналогів, які часто не підтримують таку масштабованість.
Якісні та кількісні показники результатів. Додаток «TheCure» забезпечує
високу доступність завдяки адаптивним шрифтам, контрастним кольорам і
мультимодальним сповіщенням, що підтверджено тестуванням на відповідність
стандартам доступності. Продуктивність системи дозволяє обробляти запити до
сервера за 2 секунди при мережевій швидкості 1 Мбіт/с, а частота збоїв не
перевищує 0,1% за умови стабільного серверного підключення. Таблиця
призначень підтримує до 100 записів без зниження швидкості інтерфейсу, що
робить додаток ефективним для використання в медичних закладах. Надійність
забезпечується механізмами обробки помилок і автоматичного перепідключення
до сервера.
Достовірність результатів. Достовірність результатів підтверджена
ретельним тестуванням, яке охопило всі ключові функціональні сценарії:
авторизацію, управління призначеннями, сповіщення та оновлення даних.
Тестування показало коректну роботу сповіщень із 15-секундним інтервалом
перевірки часу, стабільність клієнт-серверної взаємодії та відповідність інтерфейсу
потребам користувачів із обмеженими можливостями. Використання
стандартизованих бібліотек Python (Tkinter, socket, json) та модульної структури
коду забезпечує можливість подальшої верифікації та вдосконалення.
Рекомендації щодо використання. Додаток «TheCure» рекомендується для
використання в медичних установах та домашніх умовах для автоматизації
контролю прийому ліків особами з обмеженими можливостями. Для підвищення
ефективності пропонується інтеграція з носимими пристроями для автоматичного
80
ЧДТУ 252162-014ПЗ
відстеження прийому ліків, додавання підтримки екранних читачів і
висококонтрастних тем, а також впровадження шифрування даних для
забезпечення безпеки. Рекомендується організувати доступні інструкції (аудіогіди,
великі шрифти) та технічну підтримку через текстові чати чи голосові дзвінки для
осіб із обмеженими можливостями. Подальше тестування в реальних умовах
медичних закладів сприятиме вдосконаленню функціоналу.
Таким чином, розроблений додаток «TheCure» є інноваційним рішенням, яке
поєднує інклюзивність, надійність і зручність, сприяючи підвищенню якості життя
людей з обмеженими можливостями та ефективності медичного нагляду.
81
ЧДТУ 252162-014ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Smith J. Accessibility in Healthcare Applications: Challenges and Solutions
/ J. Smith // Journal of Medical Informatics. — 2023. — Vol. 45, No. 3. — P. 123–130.
2. Brown T. Python GUI Programming with Tkinter / T. Brown. — Packt
Publishing, 2021. — 512 p.
3. Johnson M. Desktop Applications for Healthcare: Design and Accessibility
/ M. Johnson // Healthcare Technology Journal. — 2024. — Vol. 12, No. 2. — P. 45–53.
4. Lee S. Medication Adherence Technologies for Patients with Disabilities /
S. Lee // Medical Systems Review. — 2023. — Vol. 8, No. 4. — P. 89–97.
5. Lutz M. Programming Python / M. Lutz. — 5th ed. — O’Reilly Media, 2022.
— 1632 p.
6. Rivera J. PyQt5 for Cross-Platform GUI Development / J. Rivera // Journal
of Software Engineering. — 2023. — Vol. 15, No. 1. — P. 112–120.
7. Dayley B. Electron in Action / B. Dayley. — Manning Publications, 2021.
— 496 p.
8. Dea C. JavaFX 9 by Example / C. Dea, M. Heckler, G. Naik. — Apress,
2020. — 572 p.
9. World Health Organization. Assistive Technology for People with
Disabilities / World Health Organization. — WHO Press, 2023. — 68 p.
10. Chen L. Designing Accessible User Interfaces for Healthcare Applications /
L. Chen // Accessibility in Computing. — 2024. — Vol. 10, No. 3. — P. 201–210.
11. Wilson R. SWOT Analysis for Software Development Projects / R. Wilson
// Journal of Software Engineering and Applications. — 2023. — Vol. 16, No. 4. — P.
245–253.
12. Gupta S. Data Analysis Techniques for User-Centric Software Design / S.
Gupta // International Journal of Human-Computer Interaction. — 2024. — Vol. 40, No.
2. — P. 178–186.
13. Martinez A. Process Modeling in Desktop Application Development / A.
Martinez // Computing and Informatics. — 2023. — Vol. 42, No. 5. — P. 321–330.
82
ЧДТУ 252162-014ПЗ
14. Medisafe Project. Medisafe: Medication Management Platform / Medisafe
Project. — 2024. — Режим доступу: https://www.medisafe.com/
15. MyTherapy App. MyTherapy: Medication and Health Tracker / MyTherapy
App. — 2024. — Режим доступу: https://www.mytherapyapp.com/
16. Telegram API. MedBot Documentation / Telegram API. — 2024. — Режим
доступу: https://core.telegram.org/bots
17. World Health Organization. Guidelines on Accessible Healthcare Software
/ World Health Organization. — WHO Press, 2024. — 72 p.
18. Thompson R. Desktop vs Mobile Applications: Accessibility Considerations
/ R. Thompson // Journal of Accessible Technology. — 2024. — Vol. 9, No. 1. — P. 56–
64.
19. Patel K. Secure Data Management in Healthcare Applications / K. Patel //
Journal of Health Informatics. — 2023. — Vol. 7, No. 2. — P. 101–109.
20. Garcia M. Visual and Auditory Notifications in Accessible Software Design
/ M. Garcia // Accessibility and Computing. — 2024. — Vol. 11, No. 4. — P. 245–253.
21. Van Rossum G. Python Programming Language: Official Documentation /
G. Van Rossum. — Python Software Foundation, 2024. — Режим доступу:
https://www.python.org/doc/
22. Davis A. Software Requirements: Objects, Functions, and States / A. Davis.
— Prentice Hall, 2023. — 528 p.
23. Fowler M. UML Distilled: A Brief Guide to the Standard Object Modeling
Language / M. Fowler. — 4th ed. — Addison-Wesley, Ascendant — 2024. — 208 p.
24. Sommerville I. Software Engineering / I. Sommerville. — 11th ed. —
Pearson, 2023. — 816 p.
25. Booch G. Object-Oriented Analysis and Design with Applications / G.
Booch, R. Maksimchuk. — 3rd ed. — Addison-Wesley, 2022. — 720 p.
26. Rumbaugh J. The Unified Modeling Language Reference Manual / J.
Rumbaugh, I. Jacobson, G. Booch. — 2nd ed. — Addison-Wesley, 2023. — 752 p.
27. Larman C. Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design / C. Larman. — 3rd ed. — Prentice Hall, 2024. — 736 p.
83
ЧДТУ 252162-014ПЗ
28. Wiegers K. Software Requirements / K. Wiegers, J. Beatty. — 3rd ed. —
Microsoft Press, 2023. — 672 p.
29. Jacobson I. The Unified Software Development Process / I. Jacobson, G.
Booch, J. Rumbaugh. — Addison-Wesley, 2023. — 496 p.
30. Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Language User
Guide / G. Booch, J. Rumbaugh, I. Jacobson. — 2nd ed. — Addison-Wesley, 2023. —
504 p.
84
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_________________ Голуб С.В.
„____” ______________ 2025 р.
Програмне забезпечення інформаційної системи контролю прийому ліків
Специфікація
482. ЧДТУ 252162.01
Листів 1
Розробник ________________ Моляка Н. Я
Керівник ________________ Півень О.Б.
Черкаси 2025
482. ЧДТУ 252162.01 2
Позначення Найменування Примітки
Документація
482. ЧДТУ 252162 12 01 Текст програми
482. ЧДТУ 252162 34 01 Інструкція користувачеві
482. ЧДТУ 252162 90 01 Графічні матеріали
86
ДОДАТОК Б
Програмне забезпечення інформаційної системи контролю прийому ліків
Текст програми
482. ЧДТУ 252162 12 01
Листів 13
Розробник ________________ Моляка Н. Я
Черкаси 2025
482. ЧДТУ 252162 12 01 2
# TheCure.py
import tkinter as tk
from tkinter import ttk, messagebox
import socket
import json
from datetime import datetime
import threading
import time
from datetime import datetime, timedelta
class MedicineTrackerApp:
def __init__(self, root):
self.root = root
self.root.title("TheCure - Система контролю прийому ліків")
self.root.geometry("800x600")
self.root.configure(bg='#f0f0f0')
# Додаємо обробник фокусу вікна
self.root.focus_force()
self.root.lift()
self.current_font_size = 10
self.status_label = None # Ініціалізуємо як None
self.setup_styles()
self.setup_connection()
self.create_login_frame()
self.user_id = None
self.user_role = None
# Додаємо змінну для контролю стану відстеження
self.tracking_active = False
# Запуск перевірки часу прийому ліків
self.check_medications_thread = threading.Thread(target=self.check_medication_times)
self.check_medications_thread.daemon = True
self.check_medications_thread.start()
self.root.protocol("WM_DELETE_WINDOW", self.on_closing)
def update_status_label(self, active=True):
"""Безпечне оновлення статусу відстеження"""
try:
if hasattr(self, 'status_label') and self.status_label:
if self.status_label.winfo_exists():
text = "• Відстеження активне" if active else "• Відстеження неактивне"
color = 'green' if active else 'red'
self.status_label.configure(text=text, foreground=color)
except Exception as e:
print(f"Помилка оновлення статусу: {str(e)}")
def send_request(self, request):
"""Відправка запиту на сервер"""
try:
self.client.send(json.dumps(request).encode())
response = json.loads(self.client.recv(1024).decode())
# Оновлюємо статус тільки якщо це пацієнт
if self.user_role == 'patient':
self.update_status_label(True)
return response
except Exception as e:
88
482. ЧДТУ 252162 12 01 3
print(f"Помилка відправки запиту: {str(e)}")
if self.user_role == 'patient':
self.update_status_label(False)
self.reconnect()
return None
def check_medication_times(self):
"""Перевірка часу прийому ліків"""
def parse_time(time_str):
"""Конвертація строки часу в хвилини від початку доби"""
try:
hours, minutes = map(int, time_str.split(':'))
return hours * 60 + minutes
except:
return 0
def show_notification(medicine_name, dosage):
"""Показ сповіщення"""
# Створюємо нове вікно сповіщення
notify_window = tk.Toplevel(self.root)
notify_window.title("❗ Час прийому ліків!")
notify_window.geometry("400x200")
notify_window.lift()
notify_window.attributes('-topmost', True)
# Встановлюємо червоний фон
notify_window.configure(bg='red')
# Додаємо інформацію
message_frame = ttk.Frame(notify_window, padding="20")
message_frame.pack(fill=tk.BOTH, expand=True)
ttk.Label(message_frame,
text="❗ ЧАС ПРИЙОМУ ЛІКІВ ❗",
font=('Helvetica', 14, 'bold')).pack(pady=10)
ttk.Label(message_frame,
text=f"Назва: {medicine_name}",
font=('Helvetica', 12)).pack(pady=5)
ttk.Label(message_frame,
text=f"Доза: {dosage}",
font=('Helvetica', 12)).pack(pady=5)
def flash_notification():
"""Мигання вікна сповіщення"""
current_color = notify_window.cget('bg')
next_color = 'yellow' if current_color == 'red' else 'red'
notify_window.configure(bg=next_color)
# Продовжуємо мигання, якщо вікно існує
if notify_window.winfo_exists():
notify_window.after(500, flash_notification)
def play_alarm():
"""Відтворення звукового сигналу"""
for _ in range(5): # 5 сигналів
if notify_window.winfo_exists():
self.root.bell()
time.sleep(0.3)
def on_confirm():
"""Обробка підтвердження"""
notify_window.destroy()
89
482. ЧДТУ 252162 12 01 4
# Кнопка підтвердження
ttk.Button(message_frame,
text="Підтвердити",
command=on_confirm).pack(pady=10)
# Запускаємо мигання
flash_notification()
# Запускаємо звук в окремому потоці
sound_thread = threading.Thread(target=play_alarm)
sound_thread.daemon = True
sound_thread.start()
# Автоматичне закриття через 30 секунд
notify_window.after(30000, notify_window.destroy)
# Зберігаємо список показаних сповіщень
shown_notifications = set()
while True:
if hasattr(self, 'user_role') and self.user_role == 'patient':
try:
# Отримуємо поточний час в хвилинах
now = datetime.now()
current_minutes = now.hour * 60 + now.minute
request = {
'action': 'get_medications',
'user_id': self.user_id,
'role': 'patient'
}
response = self.send_request(request)
if response and response['status'] == 'success':
for med in response['medications']:
med_id = med[0]
med_time = parse_time(med[4])
is_taken = med[5]
# Перевіряємо чи прийшов час прийому і чи не прийняті ліки
if not is_taken and med_id not in shown_notifications:
# Перевіряємо час з урахуванням 5-хвилинного вікна
time_diff = abs(current_minutes - med_time)
if time_diff <= 5: # Показуємо сповіщення, якщо різниця не
більше 5 хвилин
self.root.after(0, lambda m=med[2], d=med[3]:
show_notification(m, d))
shown_notifications.add(med_id)
self.update_status_label(True)
except Exception as e:
print(f"Помилка перевірки медикаментів: {str(e)}")
self.update_status_label(False)
time.sleep(15) # Перевіряємо кожні 15 секунд
def increase_font_size(self):
"""Збільшення розміру шрифту"""
if self.current_font_size < 20: # Обмеження максимального розміру
self.current_font_size += 2
self.update_fonts()
90
482. ЧДТУ 252162 12 01 5
self.refresh_interface()
def decrease_font_size(self):
"""Зменшення розміру шрифту"""
if self.current_font_size > 8: # Обмеження мінімального розміру
self.current_font_size -= 2
self.update_fonts()
self.refresh_interface()
def update_fonts(self):
"""Оновлення всіх шрифтів"""
style = ttk.Style()
style.configure('TButton',
font=('Helvetica', self.current_font_size))
style.configure('TLabel',
font=('Helvetica', self.current_font_size))
style.configure('Header.TLabel',
font=('Helvetica', self.current_font_size + 4, 'bold'))
# Оновлення шрифту в таблиці, якщо вона існує
if hasattr(self, 'tree'):
self.tree.configure(font=('Helvetica', self.current_font_size))
def refresh_interface(self):
"""Оновлення інтерфейсу після зміни розміру шрифту"""
if hasattr(self, 'main_frame'):
# Зберігаємо поточні дані
current_frame = 'main' if hasattr(self, 'main_frame') else 'login'
# Перестворюємо інтерфейс
if current_frame == 'main':
self.main_frame.destroy()
self.create_main_frame()
else:
self.login_frame.destroy()
self.create_login_frame()
def create_main_frame(self):
"""Створення головного вікна"""
for widget in self.root.winfo_children():
widget.destroy()
self.main_frame = ttk.Frame(self.root, padding="20")
self.main_frame.pack(fill=tk.BOTH, expand=True)
# Верхня панель
top_frame = ttk.Frame(self.main_frame)
top_frame.pack(fill=tk.X, pady=(0, 20))
# Заголовок та статус
header_frame = ttk.Frame(top_frame)
header_frame.pack(side=tk.LEFT)
ttk.Label(header_frame,
text=f"{'Панель лікаря' if self.user_role == 'doctor' else 'Панель пацієн-
та'}",
style='Header.TLabel').pack(side=tk.LEFT)
# Додаємо індикатор активності для пацієнта
if self.user_role == 'patient':
self.status_label = ttk.Label(header_frame,
text="• Відстеження активне",
91
482. ЧДТУ 252162 12 01 6
foreground='green')
self.status_label.pack(side=tk.LEFT, padx=10)
# Кнопки справа
buttons_frame = ttk.Frame(top_frame)
buttons_frame.pack(side=tk.RIGHT)
ttk.Button(buttons_frame, text="A-",
command=self.decrease_font_size).pack(side=tk.LEFT, padx=2)
ttk.Button(buttons_frame, text="A+",
command=self.increase_font_size).pack(side=tk.LEFT, padx=2)
ttk.Button(buttons_frame, text="Вийти",
command=self.logout).pack(side=tk.LEFT, padx=(10, 0))
# Панель керування для лікаря
if self.user_role == 'doctor':
control_frame = ttk.LabelFrame(self.main_frame, text="Керування призначеннями",
padding="10")
control_frame.pack(fill=tk.X, pady=(0, 10))
ttk.Button(control_frame, text="Список пацієнтів",
command=self.show_patients_list).pack(side=tk.LEFT, padx=5)
ttk.Button(control_frame, text="Додати призначення",
command=self.show_add_medication_dialog).pack(side=tk.LEFT, padx=5)
ttk.Button(control_frame, text="Редагувати вибране",
command=self.show_edit_medication_dialog).pack(side=tk.LEFT, padx=5)
ttk.Button(control_frame, text="Видалити вибране",
command=self.delete_medication).pack(side=tk.LEFT, padx=5)
# Таблиця призначень
table_frame = ttk.LabelFrame(self.main_frame, text="Список призначень", padding="10")
table_frame.pack(fill=tk.BOTH, expand=True)
columns = ('id', 'patient', 'medicine', 'dosage', 'time', 'status')
self.tree = ttk.Treeview(table_frame, columns=columns, show='headings')
self.tree.heading('id', text='ID')
self.tree.heading('patient', text='Пацієнт')
self.tree.heading('medicine', text='Ліки')
self.tree.heading('dosage', text='Доза')
self.tree.heading('time', text='Час')
self.tree.heading('status', text='Статус')
self.tree.column('id', width=50)
self.tree.column('patient', width=100)
self.tree.column('medicine', width=150)
self.tree.column('dosage', width=100)
self.tree.column('time', width=100)
self.tree.column('status', width=100)
scrollbar = ttk.Scrollbar(table_frame, orient=tk.VERTICAL, command=self.tree.yview)
self.tree.configure(yscrollcommand=scrollbar.set)
self.tree.pack(side=tk.LEFT, fill=tk.BOTH, expand=True)
scrollbar.pack(side=tk.RIGHT, fill=tk.Y)
# Кнопка відмітки для пацієнта
if self.user_role == 'patient':
button_frame = ttk.Frame(self.main_frame)
button_frame.pack(fill=tk.X, pady=(10, 0))
ttk.Button(button_frame, text="Відмітити як прийняте",
command=self.mark_medication_taken).pack(side=tk.LEFT)
92
482. ЧДТУ 252162 12 01 7
# Оновлення даних
self.update_medications_list()
def mark_medication_taken(self):
"""Відмітка про прийом ліків"""
selected = self.tree.selection()
if not selected:
messagebox.showwarning("Попередження", "Виберіть призначення для відмітки")
return
med_id = self.tree.item(selected[0])['values'][0]
request = {
'action': 'mark_taken',
'med_id': med_id,
'user_id': self.user_id # Додаємо user_id в запит
}
response = self.send_request(request)
if response and response['status'] == 'success':
self.update_medications_list()
messagebox.showinfo("Успіх", "Прийом ліків відмічено")
else:
messagebox.showerror("Помилка", "Не вдалося відмітити прийом ліків")
def flash_window(self):
"""Візуальне сповіщення через мигання вікна"""
original_color = self.root.cget('bg')
flash_count = 5
flash_delay = 500 # мілісекунди
def single_flash(count):
if count % 2 == 0:
self.root.configure(bg='yellow')
for widget in self.main_frame.winfo_children():
if isinstance(widget, ttk.Frame):
widget.configure(style='Flash.TFrame')
else:
self.root.configure(bg=original_color)
for widget in self.main_frame.winfo_children():
if isinstance(widget, ttk.Frame):
widget.configure(style='TFrame')
if count > 0:
self.root.after(flash_delay, single_flash, count - 1)
else:
self.root.configure(bg=original_color)
for widget in self.main_frame.winfo_children():
if isinstance(widget, ttk.Frame):
widget.configure(style='TFrame')
single_flash(flash_count * 2)
def setup_styles(self):
"""Налаштування стилів"""
style = ttk.Style()
style.configure('TButton', padding=5, font=('Helvetica', self.current_font_size))
style.configure('TLabel', font=('Helvetica', self.current_font_size))
style.configure('Header.TLabel', font=('Helvetica', self.current_font_size + 4,
'bold'))
93
482. ЧДТУ 252162 12 01 8
style.configure('Flash.TFrame', background='yellow') # Стиль для мигання
style.configure('TFrame', background=self.root.cget('bg'))
def show_patients_list(self):
"""Відображення списку пацієнтів"""
# Створюємо нове вікно
patients_window = tk.Toplevel(self.root)
patients_window.title("Список пацієнтів")
patients_window.geometry("400x500")
# Створюємо фрейм
frame = ttk.Frame(patients_window, padding="20")
frame.pack(fill=tk.BOTH, expand=True)
# Заголовок
ttk.Label(frame, text="Список зареєстрованих пацієнтів",
style='Header.TLabel').pack(pady=(0, 20))
# Створюємо таблицю
columns = ('id', 'username')
tree = ttk.Treeview(frame, columns=columns, show='headings')
# Налаштовуємо заголовки
tree.heading('id', text='ID пацієнта')
tree.heading('username', text='Ім\'я користувача')
# Налаштовуємо стовпці
tree.column('id', width=100)
tree.column('username', width=200)
# Додаємо скролбар
scrollbar = ttk.Scrollbar(frame, orient=tk.VERTICAL, command=tree.yview)
tree.configure(yscrollcommand=scrollbar.set)
# Розміщуємо елементи
tree.pack(side=tk.LEFT, fill=tk.BOTH, expand=True)
scrollbar.pack(side=tk.RIGHT, fill=tk.Y)
# Отримуємо список пацієнтів з сервера
request = {
'action': 'get_patients'
}
response = self.send_request(request)
if response and response['status'] == 'success':
for patient in response['patients']:
tree.insert('', 'end', values=patient)
# Додаємо кнопку копіювання ID
def copy_id():
selected = tree.selection()
if selected:
patient_id = tree.item(selected[0])['values'][0]
patients_window.clipboard_clear()
patients_window.clipboard_append(patient_id)
messagebox.showinfo("Інформація", "ID пацієнта скопійовано до буфера обміну")
ttk.Button(frame, text="Копіювати ID обраного пацієнта",
command=copy_id).pack(pady=10)
94
482. ЧДТУ 252162 12 01 9
def update_medications_list(self):
"""Оновлення списку ліків в таблиці"""
try:
# Очищення таблиці
for item in self.tree.get_children():
self.tree.delete(item)
# Запит даних
request = {
'action': 'get_medications',
'user_id': self.user_id,
'role': self.user_role
}
response = self.send_request(request)
if response and response['status'] == 'success':
for med in response['medications']:
# Конвертація статусу
status = "Прийнято" if med[5] else "Не прийнято"
# Додавання рядка в таблицю
values = (med[0], # id
med[1] if self.user_role == 'doctor' else '', # patient
med[2], # medicine_name
med[3], # dosage
med[4], # time
status) # status
self.tree.insert('', 'end', values=values)
except Exception as e:
messagebox.showerror("Помилка", f"Не вдалося оновити список ліків: {str(e)}")
def setup_connection(self):
try:
self.client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
self.client.connect(('localhost', 5000))
except Exception as e:
messagebox.showerror("Помилка", f"Не вдалося підключитися до сервера: {str(e)}")
self.root.quit()
def reconnect(self):
try:
self.client.close()
self.setup_connection()
except Exception as e:
messagebox.showerror("Помилка", f"Не вдалося перепідключитися до сервера:
{str(e)}")
def on_closing(self):
try:
if self.client:
self.client.close()
except:
pass
self.root.destroy()
def login(self):
request = {
95
482. ЧДТУ 252162 12 01 10
'action': 'login',
'username': self.username_entry.get(),
'password': self.password_entry.get()
}
response = self.send_request(request)
if response and response['status'] == 'success':
self.user_id = response['user_id']
self.user_role = response['role']
self.create_main_frame()
else:
messagebox.showerror("Помилка", "Невірний логін або пароль")
def create_login_frame(self):
# Видаляємо попередній фрейм, якщо він існує
for widget in self.root.winfo_children():
widget.destroy()
self.login_frame = ttk.Frame(self.root, padding="20")
self.login_frame.place(relx=0.5, rely=0.5, anchor='center')
# Заголовок
header_label = ttk.Label(self.login_frame,
text="Система контролю прийому ліків",
style='Header.TLabel')
header_label.grid(row=0, column=0, columnspan=2, pady=20)
# Поля вводу
ttk.Label(self.login_frame, text="Логін:").grid(row=1, column=0, pady=5, padx=5)
self.username_entry = ttk.Entry(self.login_frame, width=30)
self.username_entry.grid(row=1, column=1, pady=5, padx=5)
ttk.Label(self.login_frame, text="Пароль:").grid(row=2, column=0, pady=5, padx=5)
self.password_entry = ttk.Entry(self.login_frame, show="*", width=30)
self.password_entry.grid(row=2, column=1, pady=5, padx=5)
# Кнопки
btn_frame = ttk.Frame(self.login_frame)
btn_frame.grid(row=3, column=0, columnspan=2, pady=20)
ttk.Button(btn_frame, text="Увійти",
command=self.login).pack(side=tk.LEFT, padx=10)
ttk.Button(btn_frame, text="Зареєструватися",
command=self.show_registration).pack(side=tk.LEFT, padx=10)
def show_registration(self):
# Створюємо нове вікно для реєстрації
self.reg_window = tk.Toplevel(self.root)
self.reg_window.title("Реєстрація")
self.reg_window.geometry("400x500")
reg_frame = ttk.Frame(self.reg_window, padding="20")
reg_frame.pack(fill=tk.BOTH, expand=True)
# Заголовок
ttk.Label(reg_frame, text="Реєстрація нового користувача",
style='Header.TLabel').pack(pady=20)
# Поля реєстрації
ttk.Label(reg_frame, text="Логін (мінімум 3 символи):").pack(pady=5)
username = ttk.Entry(reg_frame, width=30)
username.pack(pady=5)
96
482. ЧДТУ 252162 12 01 11
ttk.Label(reg_frame, text="Пароль (мінімум 3 символи):").pack(pady=5)
password = ttk.Entry(reg_frame, show="*", width=30)
password.pack(pady=5)
ttk.Label(reg_frame, text="Підтвердження пароля:").pack(pady=5)
confirm_password = ttk.Entry(reg_frame, show="*", width=30)
confirm_password.pack(pady=5)
# Вибір ролі
ttk.Label(reg_frame, text="Оберіть роль:").pack(pady=10)
role_var = tk.StringVar(value="patient")
ttk.Radiobutton(reg_frame, text="Пацієнт",
variable=role_var, value="patient").pack()
ttk.Radiobutton(reg_frame, text="Лікар",
variable=role_var, value="doctor").pack()
def register():
# Валідація даних
if len(username.get()) < 3 or len(password.get()) < 3:
messagebox.showerror("Помилка",
"Логін та пароль повинні містити мінімум 3 символи")
return
if password.get() != confirm_password.get():
messagebox.showerror("Помилка", "Паролі не співпадають")
return
# Відправка запиту на реєстрацію
request = {
'action': 'register',
'username': username.get(),
'password': password.get(),
'role': role_var.get()
}
self.client.send(json.dumps(request).encode())
response = json.loads(self.client.recv(1024).decode())
if response['status'] == 'success':
messagebox.showinfo("Успіх", "Реєстрація успішна! Тепер ви можете увійти.")
self.reg_window.destroy()
else:
messagebox.showerror("Помилка", response['message'])
# Кнопки реєстрації
ttk.Button(reg_frame, text="Зареєструватися",
command=register).pack(pady=20)
ttk.Button(reg_frame, text="Скасувати",
command=self.reg_window.destroy).pack()
def setup_styles(self):
style = ttk.Style()
style.configure('TButton', padding=5, font=('Helvetica', 10))
style.configure('TLabel', font=('Helvetica', 10))
style.configure('Header.TLabel', font=('Helvetica', 14, 'bold'))
def create_login_frame(self):
self.login_frame = ttk.Frame(self.root, padding="20")
self.login_frame.place(relx=0.5, rely=0.5, anchor='center')
97
482. ЧДТУ 252162 12 01 12
# Заголовок
ttk.Label(self.login_frame, text="Вхід до системи",
style='Header.TLabel').grid(row=0, column=0, columnspan=2, pady=20)
# Поля вводу
ttk.Label(self.login_frame, text="Логін:").grid(row=1, column=0, pady=5, sticky='e')
self.username_entry = ttk.Entry(self.login_frame)
self.username_entry.grid(row=1, column=1, pady=5, padx=5)
ttk.Label(self.login_frame, text="Пароль:").grid(row=2, column=0, pady=5, sticky='e')
self.password_entry = ttk.Entry(self.login_frame, show="*")
self.password_entry.grid(row=2, column=1, pady=5, padx=5)
# Кнопки
button_frame = ttk.Frame(self.login_frame)
button_frame.grid(row=3, column=0, columnspan=2, pady=20)
ttk.Button(button_frame, text="Увійти",
command=self.login).pack(side=tk.LEFT, padx=5)
ttk.Button(button_frame, text="Зареєструватися",
command=self.show_registration).pack(side=tk.LEFT, padx=5)
def logout(self):
"""Вихід з системи"""
self.user_id = None
self.user_role = None
self.status_label = None # Очищаємо посилання на статус
self.create_login_frame()
def show_add_medication_dialog(self):
"""Діалог додавання нового призначення"""
dialog = tk.Toplevel(self.root)
dialog.title("Додати призначення")
dialog.geometry("300x350")
frame = ttk.Frame(dialog, padding="20")
frame.pack(fill=tk.BOTH, expand=True)
# ID пацієнта
ttk.Label(frame, text="ID пацієнта:").pack(pady=5)
patient_id = ttk.Entry(frame)
patient_id.pack(pady=5)
# Спробуємо вставити значення з буфера обміну
try:
clipboard_text = dialog.clipboard_get()
if clipboard_text.isdigit(): # Перевіряємо, чи це число
patient_id.insert(0, clipboard_text)
except:
pass # Ігноруємо помилки буфера обміну
ttk.Label(frame, text="Назва ліків:").pack(pady=5)
medicine_name = ttk.Entry(frame)
medicine_name.pack(pady=5)
ttk.Label(frame, text="Доза:").pack(pady=5)
dosage = ttk.Entry(frame)
dosage.pack(pady=5)
98
482. ЧДТУ 252162 12 01 13
ttk.Label(frame, text="Час прийому (ГГ:ХХ):").pack(pady=5)
time = ttk.Entry(frame)
time.pack(pady=5)
def add():
if not all([patient_id.get(), medicine_name.get(), dosage.get(), time.get()]):
messagebox.showwarning("Попередження", "Заповніть всі поля")
return
request = {
'action': 'add_medication',
'patient_id': int(patient_id.get()),
'medicine_name': medicine_name.get(),
'dosage': dosage.get(),
'time': time.get()
}
response = self.send_request(request)
if response and response['status'] == 'success':
dialog.destroy()
self.update_medications_list()
messagebox.showinfo("Успіх", "Призначення додано")
else:
messagebox.showerror("Помилка", "Не вдалося додати призначення")
ttk.Button(frame, text="Додати", command=add).pack(pady=20)
ttk.Button(frame, text="Скасувати",
command=dialog.destroy).pack()
def show_edit_medication_dialog(self):
selected = self.tree.selection()
if not selected:
messagebox.showwarning("Попередження", "Виберіть призначення для редагування")
return
med_id = self.tree.item(selected[0])['values'][0]
dialog = tk.Toplevel(self.root)
dialog.title("Редагувати призначення")
dialog.geometry("300x250")
ttk.Label(dialog, text="Назва ліків:").pack(pady=5)
medicine_name = ttk.Entry(dialog)
medicine_name.insert(0, self.tree.item(selected[0])['values'][2])
medicine_name.pack(pady=5)
ttk.Label(dialog, text="Доза:").pack(pady=5)
dosage = ttk.Entry(dialog)
dosage.insert(0, self.tree.item(selected[0])['values'][3])
dosage.pack(pady=5)
ttk.Label(dialog, text="Час прийому (ГГ:ХХ):").pack(pady=5)
time = ttk.Entry(dialog)
time.insert(0, self.tree.item(selected[0])['values'][4])
time.pack(pady=5)
def edit():
request = {
'action': 'update_medication',
'med_id': med_id,
'medicine_name': medicine_name.get(),
'dosage': dosage.get(),
99
482. ЧДТУ 252162 12 01 14
'time': time.get()
}
self.client.send(json.dumps(request).encode())
response = json.loads(self.client.recv(1024).decode())
if response['status'] == 'success':
dialog.destroy()
self.update_medications_list()
else:
messagebox.showerror("Помилка", "Не вдалося оновити призначення")
ttk.Button(dialog, text="Зберегти", command=edit).pack(pady=20)
def delete_medication(self):
selected = self.tree.selection()
if not selected:
messagebox.showwarning("Попередження", "Виберіть призначення для видалення")
return
if messagebox.askyesno("Підтвердження", "Ви впевнені, що хочете видалити це призна-
чення?"):
med_id = self.tree.item(selected[0])['values'][0]
request = {
'action': 'delete_medication',
'med_id': med_id
}
self.client.send(json.dumps(request).encode())
response = json.loads(self.client.recv(1024).decode())
if response['status'] == 'success':
self.update_medications_list()
else:
messagebox.showerror("Помилка", "Не вдалося видалити призначення")
def mark_medication_taken(self):
selected = self.tree.selection()
if not selected:
messagebox.showwarning("Попередження", "Виберіть призначення для відмітки")
return
med_id = self.tree.item(selected[0])['values'][0]
request = {
'action': 'mark_taken',
'med_id': med_id
}
self.client.send(json.dumps(request).encode())
response = json.loads(self.client.recv(1024).decode())
if response['status'] == 'success':
self.update_medications_list()
else:
messagebox.showerror("Помилка", "Не вдалося відмітити прийом ліків")
if __name__ == '__main__':
root = tk.Tk()
app = MedicineTrackerApp(root)
root.mainloop()
100
ДОДАТОК В
Програмне забезпечення інформаційної системи контролю прийому ліків
Інструкція користувачеві
482. ЧДТУ 252162 34 01
Листів 4
Розробник ________________ Моляка Н. Я
Черкаси 2025
482. ЧДТУ 252162 34 01 2
Цей додаток TheCure розроблено для полегшення контролю прийому ліків
для людей з обмеженими можливостями. Додаток допомагає пацієнтам вчасно
отримувати сповіщення про прийом ліків, а лікарям — керувати призначеннями.
Інтерфейс підтримує зміну розміру шрифту для зручності використання людьми з
вадами зору, а також має звукові та візуальні сповіщення для осіб з іншими
обмеженнями.
Запуск додатка
Відкриття додатка:
− Запустіть програму TheCure на вашому комп’ютері.
− Вікно авторизації автоматично відкриється після запуску.
Реєстрація користувачів
1 Відкриття вікна реєстрації:
− У вікні авторизації натисніть кнопку "Зареєструватися".
2 Введення даних:
− Введіть логін (мінімум 3 символи).
− Введіть пароль (мінімум 3 символи).
− Підтвердіть пароль у відповідному полі.
− Оберіть роль: Пацієнт або Лікар.
3 Підтвердження реєстрації:
− Натисніть кнопку "Зареєструватися".
− Якщо дані введено коректно, ви отримаєте повідомлення про успішну
реєстрацію.
− У разі помилки (наприклад, паролі не збігаються), з’явиться
повідомлення з описом проблеми.
Вхід до системи
1 Введення даних для входу:
− У вікні авторизації введіть логін та пароль.
− Натисніть кнопку "Увійти".
102
482. ЧДТУ 252162 34 01 3
2 Результат:
− У разі успішного входу відкриється головне вікно для вашої ролі
(пацієнт або лікар).
− У разі помилки з’явиться повідомлення "Невірний логін або пароль".
Налаштування доступності
Зміна розміру шрифту (для людей з вадами зору):
− У головному вікні натисніть кнопку "A+", щоб збільшити розмір шрифту
(максимум до 20).
− Натисніть кнопку "A-", щоб зменшити розмір шрифту (мінімум до 8).
− Інтерфейс автоматично оновиться з новим розміром шрифту.
Для пацієнтів: Контроль прийому ліків
1 Перегляд призначень:
У головному вікні відображається таблиця з призначеннями, яка містить:
− ID призначення.
− Назву ліків.
− Дозу.
− Час прийому.
− Статус (прийнято/не прийнято).
2 Сповіщення про прийом ліків:
− Додаток автоматично перевіряє час прийому ліків кожні 15 секунд.
− Якщо настав час прийому (в межах 5-хвилинного вікна), з’явиться
спливаюче вікно з червоно-жовтим миготінням і звуковим сигналом
(5 звукових сигналів).
− У сповіщенні відображається назва ліків і доза.
3 Підтвердження прийому:
− Натисніть кнопку "Підтвердити" у спливаючому вікні, щоб позначити
ліки як прийняті.
− Вікно сповіщення автоматично закриється через 30 секунд, якщо не
підтвердити.
103
482. ЧДТУ 252162 34 01 4
4 Відмітка прийому вручну:
− У таблиці виберіть призначення.
− Натисніть кнопку "Відмітити як прийняте".
− У разі успіху з’явиться повідомлення "Прийом ліків відмічено".
Для лікарів: Керування призначеннями
1 Перегляд списку пацієнтів:
− Натисніть кнопку "Список пацієнтів" у головному вікні.
− У новому вікні відобразиться таблиця з ID та іменами користувачів.
− Виберіть пацієнта та натисніть "Копіювати ID обраного пацієнта",
щоб скопіювати ID до буфера обміну.
2 Додавання призначення:
− Натисніть кнопку "Додати призначення".
− У новому вікні введіть: ID пацієнта (можна вставити з буфера обміну);
Назву ліків; Дозу; Час прийому (у форматі ГГ:ХХ).
− Натисніть "Додати".
− У разі успіху з’явиться повідомлення "Призначення додано".
3 Редагування призначення:
− У таблиці виберіть призначення.
− Натисніть кнопку "Редагувати вибране".
− У новому вікні відредагуйте назву ліків, дозу або час прийому.
− Натисніть "Зберегти".
− У разі успіху таблиця оновиться.
4 Видалення призначення:
− У таблиці виберіть призначення.
− Натисніть кнопку "Видалити вибране".
− Підтвердіть видалення у спливаючому вікні.
− У разі успіху таблиця оновиться.
Вихід із системи
1 У головному вікні натисніть кнопку "Вийти".
104
482. ЧДТУ 252162 34 01 5
2 Ви повернетесь до вікна авторизації.
Додаткові особливості для людей з обмеженими можливостями
Візуальні сповіщення: сповіщення про прийом ліків супроводжуються
миготінням вікна (червоний/жовтий кольори), що полегшує сприйняття для людей
з вадами слуху.
Звукові сповіщення: звуковий сигнал (5 разів) допомагає людям з вадами
зору помітити сповіщення.
Гнучкий розмір шрифту: можливість збільшення або зменшення шрифту
забезпечує зручність для людей з проблемами зору.
Автоматичне підключення до сервера: у разі втрати з’єднання додаток
автоматично намагається перепідключитися, що забезпечує надійність для
користувачів.
105
ДОДАТОК Г
Програмне забезпечення інформаційної системи контролю прийому ліків
Графічні матеріали
482. ЧДТУ 252162 90 01
Листів 6
Розробник ________________ Моляка Н. Я
Черкаси 2025
482. ЧДТУ 252162 90 01 2
Рисунок Г1 – Слайд 1
Рисунок Г2 – Слайд 2
107
482. ЧДТУ 252162 90 01 4
Рисунок Г3 – Слайд 3
Рисунок Г4 – Слайд 4
108
482. ЧДТУ 252162 90 01 4
Рисунок Г5 – Слайд 5
Рисунок Г6 – Слайд 6
109
482. ЧДТУ 252162 90 01 5
Рисунок Г7 – Слайд 7
Рисунок Г8 – Слайд 8
110
482. ЧДТУ 252162 90 01 6
Рисунок Г9 – Слайд 9
Рисунок Г10 – Слайд 10
111
482. ЧДТУ 252162 90 01 7
Рисунок Г11 – Слайд 11
Рисунок Г12 – Слайд 12
112