Репозиторій ЧДТУ
Репозиторій ЧДТУ зберігає і дозволяє легкий і відкритий доступ до всіх видів цифрового контенту, включаючи текст, зображення, анімовані зображення, MPEG і набори даних
Дізнатися більше
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/9788Повний запис метаданих
| Поле DC | Значення | Мова |
|---|---|---|
| dc.contributor.advisor | Немченко , Вадим В’ячеславович | - |
| dc.contributor.author | Кравченко, Андрій Русланович | - |
| dc.date.accessioned | 2026-07-03T06:23:17Z | - |
| dc.date.available | 2026-07-03T06:23:17Z | - |
| dc.date.issued | 2026-06-17 | - |
| dc.identifier.uri | https://er.chdtu.edu.ua/handle/ChSTU/9788 | - |
| dc.description.abstract | АНОТАЦІЯ У кваліфікаційній роботі розглянуто розробку програмного забезпечення автоматизованої системи онлайн-прокторингу, призначеної для організації дистанційного тестування з контролем поведінки користувачів. Проведено аналіз предметної області, визначено основні проблеми дистанційного оцінювання знань та досліджено існуючі підходи до їх вирішення. У роботі сформульовано вимоги до програмного забезпечення, розроблено модель предметної області та побудовано UML-діаграми, що відображають структуру та поведінку системи. Виконано проєктування архітектури програмного забезпечення, бази даних та інтерфейсу користувача. Реалізовано програмний комплекс на основі сучасних веб-технологій із використанням клієнт-серверної архітектури. Особливу увагу приділено реалізації підсистеми онлайн-прокторингу, яка забезпечує моніторинг поведінки користувача під час проходження тестування. Проведено модульне, інтеграційне, системне та приймальне тестування програмного забезпечення. Результати тестування підтвердили коректність роботи системи та її відповідність встановленим вимогам. Розроблена система може бути використана для організації дистанційного контролю знань у навчальних закладах та інших організаціях. | uk_UA |
| dc.description.abstract | ANNOTATION The qualification work is devoted to the development of software for an automated online proctoring system designed to organize remote testing with user behavior monitoring. The subject area is analyzed, the main problems of distance assessment are identified, and existing approaches to solving these problems are studied. The requirements for the software are defined, the domain model is developed, and UML diagrams are created to represent the structure and behavior of the system. The architecture of the software, database, and user interface is designed. The software system is implemented using modern web technologies based on a client-server architecture. Special attention is paid to the implementation of the online proctoring subsystem, which ensures monitoring of user behavior during testing. Unit, integration, system, and acceptance testing of the software are carried out. The testing results confirm the correctness of the system operation and its compliance with the specified requirements. The developed system can be used for organizing remote knowledge assessment in educational institutions and other organizations. | uk_UA |
| dc.language.iso | uk | uk_UA |
| dc.subject | онлайн-прокторинг | uk_UA |
| dc.subject | дистанційне тестування | uk_UA |
| dc.subject | веб-застосунок | uk_UA |
| dc.subject | клієнт-серверна архітектура | uk_UA |
| dc.subject | UML | uk_UA |
| dc.subject | база даних | uk_UA |
| dc.subject | тестування програмного забезпечення | uk_UA |
| dc.subject | online proctoring | uk_UA |
| dc.subject | remote testing | uk_UA |
| dc.subject | web application | uk_UA |
| dc.subject | client-server architecture | uk_UA |
| dc.subject | UML | uk_UA |
| dc.subject | database | uk_UA |
| dc.subject | software testing | uk_UA |
| dc.title | Програмне забезпечення автоматизованої системи онлайн-прокторингу | uk_UA |
| dc.type | Bachelor Thesis | uk_UA |
| Розташовується у зібраннях: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) | |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Кравченко Андрій Русланович.pdf Restricted Access | 7.34 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«бакалавра»
освітній рівень
на тему: Програмне забезпечення автоматизованої системи онлайн-
прокторингу
Виконав: студент 4 курсу, групи ПЗ-2204
Спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Кравченко А. Р.
(прізвище та ініціали)
Керівник Немченко В. В.
(прізвище та ініціали)
Рецензент Слюсар А.А.
(прізвище та ініціали)
Черкаси 2026
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
С. Голуб
«___» _______________ 2026 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Кравченко Андрій Русланович
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Програмне забезпечення автоматизованої системи онлайн-
прокторингу
Керівник проекту (роботи) Немченко Вадим В’ячеславович к.т.н доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від «12» березня
26 року № 56/03-03
2.Строк подання студентом проекту (роботи) 09.06.2026
3. Вхідні дані до проекту (роботи) 1) Платформа x86-64,
2) Мова програмування JavaScript
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань
Розділ 2. Впровадження результатів досліджень у практику проектування програмного
забезпечення інформаційних систем
Розділ 3. Розробка та тестування програмного забезпечення
Висновки;
Список використаних джерел;
Додатки А, Додатки Б, Додатки В.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту);
Додаток Г - Графічний матеріал.
6. Консультанти розділів роботи
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання грудень 2026 р.
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ етапів
Назва етапів випускної роботи Примітки
п/п кваліфікаційної
роботи
1 Постановка задачі 05.12.2025 виконано
2 Підготовка завдання 13.12.2025 виконано
3 Погодження завдання 16.12.2025 виконано
4 Затвердження завдання 12.03.2026 виконано
Основна стадія
1 Підбір матеріалів 27.03.2026 виконано
2 Аналіз шляхів вирішення поставленої задачі 04.03.2026 виконано
3 Розрахунок основних параметрів роботи 10.03.2026 виконано
4 Вибір кінцевого варіанту проектного рішення 17.03.2026 виконано
5 Оформлення первісної редакції роботи 25.03.2026 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 31.04.2026 виконано
керівником
2 Оформлення пояснювальної записки роботи в 13.05.2026 виконано
кінцевій редакції
3 Попередній захист роботи 19.05.2026 виконано
4 Затвердження роботи 23.05.2026 виконано
5 Рецензування роботи 01.06.2026 виконано
6 Захист роботи
Студент _____________________ Кравченко А.Р.
(підпис) (прізвище та ініціали)
Керівник роботи _____________________ Немченко В.В.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
У кваліфікаційній роботі розглянуто розробку програмного забезпечення
автоматизованої системи онлайн-прокторингу, призначеної для організації
дистанційного тестування з контролем поведінки користувачів. Проведено аналіз
предметної області, визначено основні проблеми дистанційного оцінювання
знань та досліджено існуючі підходи до їх вирішення.
У роботі сформульовано вимоги до програмного забезпечення, розроблено
модель предметної області та побудовано UML-діаграми, що відображають
структуру та поведінку системи. Виконано проєктування архітектури
програмного забезпечення, бази даних та інтерфейсу користувача.
Реалізовано програмний комплекс на основі сучасних веб-технологій із
використанням клієнт-серверної архітектури. Особливу увагу приділено
реалізації підсистеми онлайн-прокторингу, яка забезпечує моніторинг поведінки
користувача під час проходження тестування.
Проведено модульне, інтеграційне, системне та приймальне тестування
програмного забезпечення. Результати тестування підтвердили коректність
роботи системи та її відповідність встановленим вимогам.
Розроблена система може бути використана для організації дистанційного
контролю знань у навчальних закладах та інших організаціях.
Ключові слова: онлайн-прокторинг, дистанційне тестування, веб-
застосунок, клієнт-серверна архітектура, UML, база даних, тестування
програмного забезпечення.
ANNOTATION
The qualification work is devoted to the development of software for an
automated online proctoring system designed to organize remote testing with user
behavior monitoring. The subject area is analyzed, the main problems of distance
assessment are identified, and existing approaches to solving these problems are
studied.
The requirements for the software are defined, the domain model is developed,
and UML diagrams are created to represent the structure and behavior of the system.
The architecture of the software, database, and user interface is designed.
The software system is implemented using modern web technologies based on a
client-server architecture. Special attention is paid to the implementation of the online
proctoring subsystem, which ensures monitoring of user behavior during testing.
Unit, integration, system, and acceptance testing of the software are carried out.
The testing results confirm the correctness of the system operation and its compliance
with the specified requirements.
The developed system can be used for organizing remote knowledge assessment
in educational institutions and other organizations.
Keywords: online proctoring, remote testing, web application, client-server
architecture, UML, database, software testing.
ВСТУП .......................................................................................................................... 6
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАДАЧ ........................................................................................................................ 10
1.1 Опис існуючих методів на засобів використаних при розробці ................ 10
1.2 Аналіз існуючих аналогів програми.............................................................. 11
1.3 Постановка задач ............................................................................................. 14
Висновки до розділу 1 .............................................................................................. 17
РОЗДІЛ 2 ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ СИСТЕМИ 18
2.1 Моделювання предметної області ................................................................. 18
2.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області ................................................................ 18
2.1.2 Елементи моделювання предметної області ....................................... 21
2.1.3 Робоча область моделювання ............................................................... 25
2.2 Формування та аналіз вимог .......................................................................... 28
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги ...................................................................... 28
2.2.2 Формування вимог за допомогою діаграми прецедентів .................. 31
2.3 Проектування логічної структури програмного комплексу ....................... 33
2.3.1 Діаграми класів ....................................................................................... 33
2.3.2 Діаграми пакетів ..................................................................................... 38
2.4 Архітектурне проектування ........................................................................... 40
2.4.1 Діаграма компонентів ............................................................................ 40
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ........................................................................................... .42
ЧДТУ 26 2245.01 2 ПЗ
З м. Лист № Докум. Підпис Дата
Розроб. Кравченко А.Р. Листів
«Програмне забезпечення автоматизованої Л іт. Лист
К ері вник Н емченко В.В
системи онлайн-прокторингу» 4
(Пояснювальна записка) ФІТІС, Кафедра ПЗАС, ПЗ-
Н .контр.
Півень О.Б.
2204
З атв.
Голуб С.В.
А
2.5 Моделювання поведінки системи ........................................................... 44
2.5.1 Діаграма діяльності ................................................................................ 44
2.5.2 Діаграма послідовності .......................................................................... 48
2.5.3 Діаграма комунікації .............................................................................. 50
2.5.4 Діаграма скінченного автомату ............................................................ 42
Висновки до розділу 2 .............................................................................................. 55
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ56
3.1 Розробка програмного комплексу ..................................................................... 56
3.1.1 Обґрунтування вибору засобів реалізації ............................................ 56
3.1.2 Опис структурної (функціональної) схеми ......................................... 57
3.1.3 Опис логічної схеми системи ................................................................ 59
3.1.4 Розробка бази даних............................................................................... 62
3.1.5 Розробка інтерфейсу користувача ........................................................ 66
3.1.6 Опис розробки програмних компонентів ............................................ 72
3.2 Тестування системи ............................................................................................ 74
3.2.1 Модульне тестування ............................................................................ .74
3.2.2 Інтеграційне тестування ........................................................................ 77
3.2.3 Системне тестування ............................................................................. 79
3.2.4 Приймальне тестування ......................................................................... 81
3.3 Приклади впровадженого програмного комплексу ......................................... 83
Виснвоки до розділу 3 .............................................................................................. 86
ВИСНОВКИ ............................................................................................................... 88
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................. 90
ДОДАТКИ .................................................................................................................. 92
Лист
ЧДТУ ПЗ 262245.012 ПЗ
З
м. Лист № док. Підпис Дата
ЧДТУ.262245 007 ПЗ
ВСТУП
Актуальність теми. У сучасних умовах стрімкого розвитку інформаційних
технологій та широкого впровадження дистанційної освіти особливої
актуальності набуває забезпечення контролю знань здобувачів освіти в онлайн-
середовищі. Однією з ключових проблем є забезпечення об’єктивності та
прозорості оцінювання під час дистанційного тестування й екзаменування.
Традиційні методи контролю знань в умовах онлайн-навчання є недостатньо
ефективними через можливість порушення академічної доброчесності. У зв’язку
з цим актуальною є розробка програмного забезпечення автоматизованих систем
онлайн-прокторингу, які дозволяють здійснювати моніторинг поведінки
користувачів під час проходження тестування, фіксувати потенційні порушення
та забезпечувати підвищення достовірності результатів оцінювання.
Системи онлайн-прокторингу дозволяють автоматизувати процес контролю
за поведінкою користувача під час проходження тестування, використовуючи
засоби відеоспостереження, аналізу поведінки, розпізнавання обличчя та інші
сучасні технології. Проте існуючі рішення часто мають обмеження щодо
точності, вартості впровадження, масштабованості або захисту персональних
даних.
Таким чином, розробка програмного забезпечення автоматизованої системи
онлайн-прокторингу є актуальною задачею в галузі інженерії програмного
забезпечення та інформаційних технологій.
Мета і завдання розробки. Метою кваліфікаційної роботи є розробка
програмного забезпечення автоматизованої системи онлайн-прокторингу для
забезпечення контролю процесу дистанційного тестування та підвищення рівня
академічної доброчесності.
Для досягнення поставленої мети необхідно вирішити такі завдання:
провести аналіз існуючих програмних засобів і систем онлайн-
прокторингу, визначити їх переваги та недоліки для обґрунтування
розробки власного програмного забезпечення;
6
ЧДТУ.262245 007 ПЗ
сформувати вимоги до програмного забезпечення системи;
виконати моделювання предметної області;
розробити архітектуру програмної системи;
реалізувати основні функціональні модулі системи;
провести тестування програмного забезпечення;
оцінити ефективність розробленого рішення.
Об’єктом розробки є процес автоматизації дистанційного контролю знань
користувачів у середовищі онлайн-навчання за допомогою програмного
забезпечення.
Предметом методи, моделі, архітектурні рішення та програмне
забезпечення автоматизованої системи онлайн-прокторингу для забезпечення
контролю доброчесності під час дистанційного тестування.
Методи проектування та конструювання. Для досягнення поставленої
мети використано такі методи:
методи аналізу та порівняння — для дослідження існуючих рішень;
об’єктно-орієнтований підхід — при проектуванні системи;
моделювання з використанням UML — для побудови моделей
предметної області та архітектури;
методи програмної інженерії — для розробки та тестування
програмного забезпечення;
Опис отриманих результатів. У результаті виконання кваліфікаційної
роботи розроблено програмне забезпечення автоматизованої системи онлайн-
прокторингу, яке забезпечує моніторинг користувача під час проходження
тестування, фіксацію підозрілої поведінки та формування відповідних звітів.
Побудовано моделі предметної області, спроєктовано архітектуру системи та
реалізовано її основні компоненти.
Практичне значення отриманих результатів. Практична цінність роботи
полягає у можливості використання розробленої системи в закладах освіти для
організації дистанційного контролю знань. Запропоноване рішення може бути
7
ЧДТУ.262245 007 ПЗ
впроваджене в навчальні платформи для підвищення ефективності оцінювання та
забезпечення академічної доброчесності.
Особистий внесок автора. Усі результати, представлені у кваліфікаційній
роботі, отримані автором самостійно. Автором проведено аналіз предметної
області, сформовано вимоги до системи, виконано проектування, реалізацію та
тестування програмного забезпечення автоматизованої системи онлайн-
прокторингу.
8
ЧДТУ.262245 007 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1. Актуальні проблеми, що виникають в процесі виконання завдань
У процесі організації дистанційного контролю знань із використанням
систем онлайн-прокторингу виникає низка актуальних проблем, що
ускладнюють забезпечення ефективності, надійності та об’єктивності
оцінювання.
Перш за все, однією з ключових проблем є забезпечення академічної
доброчесності. В умовах відсутності фізичного контролю з боку викладача
користувачі можуть використовувати сторонні джерела інформації, допомогу
інших осіб або технічні засоби для отримання неправомірних переваг. Існуючі
підходи не завжди дозволяють повною мірою виявити такі порушення.
Іншою важливою проблемою є точність і надійність автоматичного
моніторингу поведінки користувача. Системи прокторингу часто базуються на
аналізі відео- та аудіопотоків, що потребує використання складних алгоритмів
комп’ютерного зору та обробки сигналів. При цьому можливі помилки
розпізнавання, хибні спрацювання або, навпаки, пропуск підозрілих дій, що
негативно впливає на достовірність результатів.
Суттєвою проблемою є також забезпечення захисту персональних даних
користувачів. Системи онлайн-прокторингу обробляють конфіденційну
інформацію, зокрема відеозаписи, аудіодані та біометричні характеристики. Це
вимагає дотримання сучасних стандартів інформаційної безпеки, а також
відповідності законодавчим вимогам щодо захисту даних.
Ще одним викликом є забезпечення стабільності роботи системи в умовах
різної якості інтернет-з’єднання та апаратного забезпечення користувачів.
Нестабільний зв’язок може призводити до втрати даних, переривання сесій
тестування або некоректної роботи алгоритмів моніторингу.
Окремо слід відзначити проблему масштабованості системи. У випадку
проведення масових онлайн-екзаменів система повинна обробляти значну
10
ЧДТУ.262245 007 ПЗ
кількість одночасних підключень, що потребує оптимізації ресурсів та
ефективної архітектури програмного забезпечення.
Також важливою є проблема зручності використання (юзабіліті). Надмірно
складний інтерфейс або велика кількість обмежень можуть ускладнювати роботу
користувачів та викликати негативне сприйняття системи.
Таким чином, розробка ефективної автоматизованої системи онлайн-
прокторингу потребує комплексного підходу до вирішення зазначених проблем,
що включає використання сучасних методів аналізу даних, забезпечення безпеки
інформації, оптимізацію продуктивності та орієнтацію на потреби користувачів.
1.2. Методи та засоби, які вже використовуються для усунення
проблем та виконання завдань
У сучасних умовах розвитку дистанційної освіти значна увага приділяється
розробці ефективних методів і програмних засобів, спрямованих на забезпечення
об’єктивного контролю знань здобувачів освіти. Для усунення проблем,
пов’язаних із порушенням академічної доброчесності, нестачею контролю та
складністю ідентифікації користувачів, застосовуються комплексні підходи, що
поєднують сучасні інформаційні технології.
Основу більшості систем онлайн-прокторингу становлять методи
відеоспостереження та аналізу поведінки користувача. Зокрема, активно
використовуються алгоритми комп’ютерного зору для розпізнавання обличчя,
визначення напрямку погляду, а також виявлення сторонніх осіб у кадрі. Поряд
із цим застосовуються методи обробки аудіосигналів, які дозволяють виявляти
сторонні шуми або голоси. Важливим аспектом є також контроль робочого
середовища користувача, що передбачає обмеження доступу до інших програм,
вкладок браузера або зовнішніх ресурсів. Для підвищення ефективності
виявлення порушень дедалі частіше використовуються алгоритми штучного
інтелекту, які аналізують поведінкові патерни та формують відповідні висновки.
Одним із найбільш відомих програмних рішень у сфері онлайн-
прокторингу є Proctorio [1]. Дана система реалізує повністю автоматизований
11
ЧДТУ.262245 007 ПЗ
підхід до контролю користувача під час проходження тестування. Вона
функціонує у вигляді розширення для веб-браузера та інтегрується з
поширеними системами дистанційного навчання (рис. 1.1). У процесі роботи
здійснюється запис відео та аудіо, а також аналіз поведінки користувача,
включаючи рухи голови та напрямок погляду. Особливістю системи є
використання алгоритмів штучного інтелекту для автоматичного виявлення
підозрілих дій. Результати аналізу подаються у вигляді звітів, які можуть бути
використані викладачем для оцінювання. Незважаючи на високий рівень
автоматизації, дана система має певні обмеження, пов’язані з можливими
помилками розпізнавання та залежністю від технічних умов використання. Окрім
того, дискусійним залишається питання забезпечення конфіденційності
персональних даних користувачів.
Рисунок 1.1 – Розширення Proctorio для Chrome [1]
Іншим поширеним рішенням є Examity, яке відрізняється використанням
комбінованого підходу до прокторингу [2]. На відміну від автоматизованих
систем, у даному випадку значну роль відіграють живі проктори, які здійснюють
контроль у режимі реального часу (рис. 1.2). Такий підхід дозволяє значно
підвищити точність виявлення порушень, оскільки людина здатна краще
інтерпретувати поведінку користувача у складних або неоднозначних ситуаціях.
12
ЧДТУ.262245 007 ПЗ
Система також передбачає ідентифікацію особи перед початком тестування,
запис сесії та аналіз середовища користувача. Водночас використання людського
ресурсу суттєво впливає на вартість послуг та обмежує можливості
масштабування. Крім того, присутність проктора може створювати додатковий
психологічний дискомфорт для користувачів.
Рисунок 1.2 – Головна сторінка системи Examity [2]
Ще одним прикладом сучасного програмного забезпечення є Respondus
Monitor, який працює у поєднанні зі спеціалізованим браузером, що обмежує
доступ до сторонніх ресурсів під час тестування. Система забезпечує запис відео
з веб-камери та автоматичний аналіз поведінки користувача (рис 1.3).
Особливістю даного рішення є акцент на контролі робочого середовища, що
дозволяє мінімізувати можливість використання сторонніх джерел інформації
[3]. Отримані дані обробляються та подаються у вигляді звітів із позначенням
потенційно підозрілих моментів. Попри відносну простоту впровадження,
функціональні можливості цієї системи є дещо обмеженими порівняно з більш
складними рішеннями, а її ефективність значною мірою залежить від технічних
13
ЧДТУ.262245 007 ПЗ
характеристик пристрою користувача.
Рисунок 1.3 – Демонстрація роботи Respondus LockDown Browser [3]
Таким чином, аналіз існуючих методів і засобів показує, що сучасні
системи онлайн-прокторингу базуються на поєднанні автоматизованих
алгоритмів та, у деяких випадках, участі людини у процесі контролю. Кожен із
розглянутих підходів має свої переваги та недоліки, що проявляються у точності
роботи, вартості впровадження, рівні масштабованості та забезпеченні захисту
персональних даних. Це свідчить про необхідність подальшого розвитку
програмного забезпечення у даній галузі з метою досягнення оптимального
балансу між ефективністю, доступністю та безпекою.
1.3. Конкретизація завдань роботи
На основі проведеного аналізу предметної області, виявлених проблем та
існуючих засобів їх вирішення сформульовано конкретні завдання, реалізація
яких забезпечить досягнення мети кваліфікаційної роботи.
14
ЧДТУ.262245 007 ПЗ
Метою роботи є розробка програмного забезпечення автоматизованої
системи онлайн-прокторингу, що забезпечує контроль процесу дистанційного
тестування та підвищення рівня академічної доброчесності.
Для досягнення поставленої мети необхідно вирішити такі завдання:
− провести аналіз предметної області дистанційного тестування та
визначити основні загрози порушення академічної доброчесності;
− виконати аналіз існуючих систем онлайн-прокторингу та визначити їх
переваги та недоліки;
− сформувати функціональні та нефункціональні вимоги до програмного
забезпечення системи;
− розробити загальну архітектуру програмного забезпечення
автоматизованої системи онлайн-прокторингу;
− спроєктувати структуру бази даних для збереження інформації про
користувачів, тести, результати та зафіксовані порушення;
− реалізувати підсистему керування користувачами, що забезпечує
реєстрацію, автентифікацію, авторизацію та розмежування прав
доступу;
− реалізувати підсистему керування тестуванням, яка включає створення,
редагування та проходження тестів;
− розробити підсистему онлайн-прокторингу, що забезпечує моніторинг
дій користувача під час проходження тестування та фіксацію
підозрілих подій;
− реалізувати механізм логування та збереження інформації про
порушення під час тестування;
− забезпечити збереження та обробку результатів тестування з
можливістю їх подальшого аналізу;
− реалізувати взаємодію між клієнтською та серверною частинами
системи;
− провести тестування розробленого програмного забезпечення з метою
перевірки його працездатності та відповідності поставленим вимогам.
15
ЧДТУ.262245 007 ПЗ
Таким чином, конкретизація завдань дозволяє визначити основні етапи
розробки програмного забезпечення автоматизованої системи онлайн-
прокторингу та забезпечує системний підхід до реалізації поставленої мети.
16
ЧДТУ.262245 007 ПЗ
Висновки до розділу 1
Проведено аналіз предметної області автоматизованих систем онлайн-
прокторингу та визначено основні проблеми, що виникають у процесі
дистанційного контролю знань. Встановлено, що ключовими труднощами є
забезпечення академічної доброчесності, надійність і точність моніторингу
поведінки користувачів, а також захист персональних даних і стабільність
роботи системи в умовах різного технічного середовища.
У ході роботи розглянуто сучасні методи та засоби, що застосовуються для
вирішення зазначених проблем. Визначено, що найбільш ефективними є підходи,
які базуються на використанні технологій комп’ютерного зору, аналізу поведінки
та штучного інтелекту. Проведено аналіз існуючих програмних рішень у сфері
онлайн-прокторингу, що дозволило виявити їхні переваги та недоліки, зокрема в
аспектах точності, вартості впровадження, масштабованості та забезпечення
конфіденційності.
На основі проведеного аналізу сформульовано мету та конкретизовано
основні завдання кваліфікаційної роботи, які охоплюють етапи проєктування,
розробки та тестування програмного забезпечення автоматизованої системи
онлайн-прокторингу.
Таким чином, результати створюють теоретичну та методичну основу для
подальшого проєктування і реалізації програмного забезпечення, що
розглядається у наступних розділах роботи.
17
ЧДТУ.262245 007 ПЗ
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
2.1. Моделювання предметної області
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметна область моделювання. Розробка програмного забезпечення
автоматизованої системи онлайн-прокторингу потребує попереднього детального
аналізу предметної області, що дозволяє визначити основні об’єкти, їх
властивості та взаємозв’язки. Предметна область у даному випадку охоплює
процес дистанційного контролю знань користувачів із використанням
інформаційних технологій.
До предметної області входять усі сутності та процеси, пов’язані з
організацією та проведенням онлайн-тестування, а також моніторингом
поведінки користувачів під час його проходження. Основними учасниками цієї
області є користувачі системи (студенти, адміністратори), програмні
компоненти, що забезпечують проведення тестування, а також засоби фіксації та
аналізу дій користувача.
Модель предметної області являє собою концептуальне відображення
структури системи у вигляді сукупності класів та зв’язків між ними [4]. Вона
дозволяє сформувати цілісне уявлення про систему ще до етапу програмної
реалізації та слугує основою для подальшого проєктування. У контексті даної
роботи модель предметної області відображає основні сутності, такі як
користувач, тест, питання, відповідь, результат тестування, сесія тестування та
подія прокторингу.
Користувач системи є центральним об’єктом, який взаємодіє з іншими
компонентами. Він може мати різні ролі, зокрема студент або адміністратор, що
визначає його права доступу до функціоналу системи. Тест представляє собою
18
ЧДТУ.262245 007 ПЗ
сукупність питань, які формуються адміністратором і призначені для оцінювання
знань користувача. Питання містять набір можливих відповідей, серед яких
визначається правильна.
Сесія тестування описує процес проходження тесту конкретним
користувачем у визначений проміжок часу. У межах цієї сесії фіксуються
відповіді користувача, а також здійснюється моніторинг його поведінки.
Результат тестування формується на основі аналізу відповідей користувача та
відображає рівень засвоєння матеріалу.
Особливе місце в моделі предметної області займає подія прокторингу, яка
фіксує підозрілі дії користувача під час тестування. До таких подій можуть
належати відсутність обличчя у кадрі, поява сторонніх осіб, зміна активного
вікна або інші дії, що можуть свідчити про порушення правил проходження
тесту.
Для забезпечення однозначного розуміння термінів, що використовуються
в процесі моделювання, формується словник предметної області. Він містить
визначення основних понять, які застосовуються у даній роботі.
Основними термінами словника предметної області є:
Користувач — особа, яка взаємодіє із системою та має відповідні права
доступу.
− студент — користувач, який проходить тестування;
− адміністратор — користувач, який керує системою, створює тести та
аналізує результати;
− тест — структурований набір питань, призначений для перевірки знань;
− питання — елемент тесту, що містить формулювання завдання та
варіанти відповідей;
− відповідь — варіант реакції користувача на поставлене питання;
− сесія тестування — процес проходження тесту користувачем у
визначений час;
− результат тестування — підсумкова оцінка, отримана користувачем;
− подія прокторингу — зафіксована дія користувача, яка може свідчити
19
ЧДТУ.262245 007 ПЗ
про порушення правил.
Таким чином, визначення предметної області, побудова її моделі та
формування словника термінів створюють основу для подальшого етапу
проєктування програмного забезпечення автоматизованої системи онлайн-
прокторингу.
На рисунку 2.1 подано діаграма класів автоматизованої системи онлайн
прокторингу.
Рисунок 2.1 - Діаграма класів автоматизованої системи онлайн прокторингу
20
ЧДТУ.262245 007 ПЗ
2.1.2. Елементи моделювання предметної області
Для якісного проєктування програмного забезпечення автоматизованої
системи онлайн-прокторингу необхідно виконати формалізований опис
предметної області з використанням уніфікованої мови моделювання UML.
Застосування UML дає змогу подати структуру системи, її складові,
взаємозв’язки між об’єктами, а також особливості поведінки системи у
стандартній графічній формі [5]. Це спрощує аналіз предметної області,
забезпечує однозначне розуміння архітектури системи та створює основу для
подальшого логічного і фізичного проєктування.
Мова UML є універсальним засобом моделювання програмних систем, що
дозволяє описувати як статичні, так і динамічні аспекти системи [5]. У межах
даної роботи UML використовується для побудови моделей предметної області,
формування та аналізу вимог, проєктування логічної структури, архітектурного
подання та моделювання поведінки автоматизованої системи онлайн-
прокторингу. Це дає змогу перейти від словесного опису предметної області до її
формалізованого графічного представлення.
Під час моделювання предметної області ключовим елементом є клас.
Саме класи відображають основні сутності системи, які мають значення для
розв’язання поставленого завдання. У контексті автоматизованої системи
онлайн-прокторингу такими сутностями є користувач, іспит, запитання,
відповідь, результат тестування, подія прокторингу та інші об’єкти, що беруть
участь у функціонуванні системи. Кожен клас у UML задає узагальнений опис
групи об’єктів, які мають спільні характеристики, поведінку та зв’язки з іншими
сутностями [5].
Наступним важливим елементом є атрибути класу, які визначають
властивості відповідних сутностей. Атрибути дозволяють описати стан об’єкта
та зберігати дані, що характеризують його в межах системи. Наприклад, для
класу користувача це можуть бути ім’я, електронна адреса, пароль, роль у
системі, а для класу іспиту — назва, тривалість, дата початку та дата завершення.
Саме атрибути є основою для подальшого проєктування структури даних та бази
21
ЧДТУ.262245 007 ПЗ
даних системи.
Не менш важливими є операції класу, які відображають можливу поведінку
об’єктів. Операції задають перелік дій, що можуть бути виконані над даними
класу або ініційовані самим об’єктом. У предметній області онлайн-прокторингу
це можуть бути операції автентифікації користувача, створення іспиту,
додавання запитань, збереження результатів тестування, фіксації порушень та
формування звітів. Використання операцій дозволяє наблизити модель
предметної області до реальної логіки функціонування системи.
Для встановлення взаємозв’язків між сутностями предметної області
використовуються асоціації (рис. 2.2). Асоціація в UML показує наявність
логічного зв’язку між двома класами. Наприклад, один іспит містить множину
запитань, один користувач може мати кілька результатів тестування, а одна сесія
проходження іспиту може бути пов’язана з декількома подіями прокторингу.
Асоціації є базовим елементом при побудові діаграми класів, оскільки вони
дозволяють відобразити структуру предметної області як систему пов’язаних між
собою об’єктів.
Для точнішого опису таких зв’язків застосовується поняття кратності.
Кратність визначає, скільки екземплярів одного класу може бути пов’язано з
екземпляром іншого класу. Наприклад, один іспит може містити багато запитань,
а одне запитання може мати декілька варіантів відповідей. Використання
кратностей дає змогу формально задати обмеження предметної області й
уникнути неоднозначностей при подальшому проєктуванні програмної системи.
У моделюванні також важливе значення мають відношення агрегації та
композиції. Вони застосовуються у випадках, коли один об’єкт складається з
інших або логічно включає їх у свою структуру. Для автоматизованої системи
онлайн-прокторингу композиція може використовуватись для подання зв’язку
між іспитом і запитаннями або між запитанням і варіантами відповідей, коли
існування залежного об’єкта без основного є недоцільним. Такі відношення
дозволяють точніше подати внутрішню структуру системи.
Окремо слід виділити відношення узагальнення, яке використовується для
22
ЧДТУ.262245 007 ПЗ
подання спадкування між класами. Це відношення доцільно застосовувати у
випадках, коли деякі сутності мають спільні властивості, але відрізняються
певними спеціалізованими характеристиками. Наприклад, базовий клас
користувача може бути узагальненням для ролей студента та адміністратора.
Використання узагальнення дозволяє уникнути дублювання властивостей і
поведінки та підвищує логічність побудови моделі.
Під час подальшого моделювання системи важливе місце займають актори,
які використовуються на діаграмах варіантів використання. Актор у UML
відображає роль зовнішнього об’єкта, що взаємодіє із системою (рис. 2.3). У
даній роботі такими акторами виступають студент та адміністратор. Студент
проходить тестування, переглядає результати та взаємодіє з підсистемою онлайн-
прокторингу, а адміністратор створює іспити, налаштовує систему та аналізує
підсумки проходження тестів. Виділення акторів є необхідним для формування
функціональних вимог до системи.
Ще одним важливим елементом UML є варіант використання. Він
відображає окремий завершений сценарій взаємодії користувача із системою,
який має певну мету. Для системи онлайн-прокторингу такими варіантами
використання є реєстрація та вхід до системи, створення іспиту, проходження
тестування, збереження результату, фіксація порушення, перегляд звіту та інші
функціональні сценарії. Варіанти використання надалі будуть використані для
побудови діаграми прецедентів, яка дозволить формалізувати функціональні
можливості системи з точки зору користувача.
Для опису динаміки процесів у системі застосовуються діаграми
діяльності, діаграми послідовності та діаграми комунікації (рис. 2.4). У зв’язку з
цим уже на етапі моделювання предметної області доцільно виділити основні
процеси, які надалі будуть деталізовані. До таких процесів належать авторизація
користувача, запуск іспиту, проходження тестування, обробка відповідей,
реєстрація подій прокторингу та формування результатів. Виділення цих
процесів на ранньому етапі забезпечує цілісність усієї моделі системи.
Для архітектурного проєктування будуть також використовуватися
23
ЧДТУ.262245 007 ПЗ
компоненти та вузли розгортання. Компоненти дозволять подати систему як
сукупність програмних модулів, наприклад клієнтської частини, серверної
частини, модуля автентифікації, модуля керування іспитами, модуля збереження
результатів та модуля фіксації порушень. Вузли розгортання дадуть змогу
відобразити фізичне розміщення цих компонентів на сервері, клієнтському
пристрої та в середовищі збереження даних.
Отже, у процесі побудови моделі предметної області автоматизованої
системи онлайн-прокторингу доцільно використовувати такі елементи UML, як
класи, атрибути, операції, асоціації, кратності, агрегації, композиції,
узагальнення, актори, варіанти використання, а також елементи, необхідні для
побудови поведінкових та архітектурних діаграм. Використання зазначених
елементів забезпечує формалізований опис предметної області та створює основу
для побудови наступних діаграм, що будуть використані в подальших
підрозділах кваліфікаційної роботи.
Рисунок 2.2 – Елементи єднання UML [6]
24
ЧДТУ.262245 007 ПЗ
Рисунок 2.3 - Основні графічні позначення UML[6]
Рисунок 2.4 - Основні діаграми UML [6]
2.1.3. Робоча область моделювання
Робоча область моделювання автоматизованої системи онлайн-прокторингу
охоплює сукупність об’єктів, процесів і взаємозв’язків, що виникають під час
організації, проведення та контролю дистанційного тестування. Її формування є
25
ЧДТУ.262245 007 ПЗ
необхідним етапом проєктування, оскільки дозволяє визначити основні сутності
предметної області, встановити логічні зв’язки між ними та створити основу для
подальшої побудови UML-діаграм.
У межах даної роботи робоча область моделювання включає процес
взаємодії користувача із системою під час проходження онлайн-іспиту.
Центральним об’єктом є користувач, який після автентифікації отримує доступ
до функціональних можливостей системи відповідно до своєї ролі. У системі
передбачено дві основні ролі: студент та адміністратор. Студент взаємодіє із
підсистемою проходження тестування, отримує доступ до екзаменів, відповідає
на поставлені запитання та отримує результати. Адміністратор, у свою чергу,
виконує функції створення і редагування екзаменів, наповнення їх запитаннями,
перегляду результатів тестування та аналізу зафіксованих порушень.
Одним із ключових об’єктів робочої області є екзамен. Він містить
загальну інформацію про тестування, зокрема назву, часові межі проведення,
тривалість та набір запитань. Кожен екзамен складається з множини запитань, а
кожне запитання може містити декілька варіантів відповідей. Така структура
дозволяє організувати процес контролю знань у формалізованому вигляді та
забезпечує можливість автоматизованого оцінювання результатів.
Під час проходження тестування формується сесія екзамену, в межах якої
користувач послідовно надає відповіді на запитання. Відповіді зберігаються у
системі та використовуються для обчислення підсумкового результату. Результат
тестування є окремою сутністю, яка характеризує успішність проходження
екзамену конкретним користувачем, містить кількість правильних відповідей,
підсумковий бал та інші показники, необхідні для аналізу.
Особливістю автоматизованої системи онлайн-прокторингу є наявність
підсистеми моніторингу поведінки користувача. У процесі проходження
екзамену система фіксує потенційно підозрілі події, які можуть свідчити про
порушення правил тестування. До таких подій належать відсутність обличчя у
кадрі, наявність кількох осіб, повороти голови, використання сторонніх
предметів або інші нетипові дії. Інформація про такі випадки накопичується у
26
ЧДТУ.262245 007 ПЗ
журналі порушень і надалі може аналізуватися адміністратором.
Таким чином, робоча область моделювання охоплює не лише об’єкти,
пов’язані безпосередньо з проведенням тестування, а й сутності, які
забезпечують контроль академічної доброчесності. Модель робочої області
повинна відображати зв’язки між користувачами, екзаменами, запитаннями,
варіантами відповідей, результатами тестування та журналом порушень. Саме
така модель дозволяє сформувати цілісне уявлення про функціонування системи
та слугує підґрунтям для подальшого проєктування логічної структури
програмного забезпечення.
Нижче на рисунку 2.5 наведено побудовану графічну модель робочої
області автоматизованої системи онлайн-прокторингу.
Рисунок 2.5 Модель робочої області автоматизованої системи онлайн-
прокторингу
27
ЧДТУ.262245 007 ПЗ
2.2. Формування та аналіз вимог
2.2.1. Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
Формування вимог до програмного забезпечення. Процес формування
вимог є одним із ключових етапів розробки програмного забезпечення, оскільки
саме на цьому етапі визначаються функціональні можливості системи, її
обмеження та основні характеристики [7]. Вимоги відображають очікування
замовника щодо роботи системи та слугують основою для подальшого
проєктування і реалізації.
Під вимогами до програмного забезпечення розуміють сукупність умов і
характеристик, яким повинна відповідати система. Вони визначають, що саме
повинна робити система, не описуючи безпосередньо способів реалізації.
Формування вимог здійснюється на основі аналізу предметної області,
визначення потреб користувачів та дослідження існуючих рішень.
У процесі розробки розрізняють первинні та детальні вимоги. Первинні
вимоги формуються на початковому етапі і відображають потреби замовника у
загальному вигляді. Вони описуються природною мовою та є зрозумілими для
користувачів, які не мають технічної підготовки:
1 Реєстрація та авторизація користувачів.
2 Розмежування ролей студента та викладача.
3 Проведення онлайн-тестування через веб-інтерфейс.
4 Збереження результатів проходження тестів.
5 Реалізація автоматизованого онлайн-прокторингу.
6 Формування журналу порушень під час тестування.
Детальні вимоги, у свою чергу, є результатом аналізу первинних вимог і
подаються у формалізованому вигляді, що є зрозумілим для розробників. Вони
деталізують функціональність системи та визначають її внутрішню структуру:
1 Створення, редагування та видалення іспитів.
28
ЧДТУ.262245 007 ПЗ
2 Додавання запитань і варіантів відповідей.
3 Проходження тестування студентами.
4 Автоматичне обчислення результатів тестування.
5 Перегляд результатів студентами та викладачами.
6 Виявлення відсутності обличчя в кадрі.
7 Фіксація поворотів голови та сторонніх об'єктів.
8 Збереження подій прокторингу в базі даних.
9 Перегляд журналу прокторингу викладачем.
10 Захист даних користувачів та контроль доступу.
11 Підтримка одночасної роботи кількох користувачів.
12 Забезпечення стабільної роботи веб-застосунку.
Вимоги замовника відображають очікувану поведінку системи з точки
зору користувача [7]. Для автоматизованої системи онлайн-прокторингу до таких
вимог належать:
− система повинна забезпечувати реєстрацію та автентифікацію
користувачів;
− система повинна надавати можливість створення та редагування
екзаменів;
− система повинна забезпечувати проходження тестування у
дистанційному режимі;
− система повинна здійснювати моніторинг поведінки користувача під
час тестування;
− система повинна фіксувати підозрілі дії та формувати звіти;
− система повинна зберігати результати тестування та надавати доступ до
них.
Вимоги розробника є деталізованим відображенням вимог замовника та
описують конкретні функції системи у структурованому вигляді [7]. Вони
формулюються з урахуванням технічних аспектів реалізації. Наприклад:
− система повинна забезпечувати збереження даних користувачів у базі
даних із використанням механізмів шифрування паролів;
29
ЧДТУ.262245 007 ПЗ
− система повинна реалізовувати рольову модель доступу (студент,
адміністратор);
− система повинна забезпечувати створення екзаменів із можливістю
додавання запитань і варіантів відповідей;
− система повинна зберігати відповіді користувача та обчислювати
результат тестування;
− система повинна реалізовувати механізм збору даних про поведінку
користувача під час тестування;
− система повинна зберігати інформацію про порушення у відповідному
журналі;
− система повинна забезпечувати взаємодію клієнтської та серверної
частин через API.
У межах розробки програмного забезпечення автоматизованої системи
онлайн-прокторингу вимоги поділяються на функціональні та нефункціональні.
Функціональні вимоги визначають основні можливості системи та
описують її поведінку [7]. До функціональних вимог належать:
− реєстрація, автентифікація та авторизація користувачів;
− створення, редагування та видалення екзаменів;
− додавання та редагування запитань і варіантів відповідей;
− проходження тестування користувачем;
− автоматичне оцінювання результатів тестування;
− моніторинг поведінки користувача під час проходження тесту;
− фіксація подій прокторингу та збереження журналу порушень;
− перегляд результатів тестування та аналітики.
Нефункціональні вимоги визначають характеристики системи, що не
пов’язані безпосередньо з її функціональністю, але впливають на якість її
роботи. До них належать:
− вимоги до продуктивності, що передбачають обробку великої кількості
одночасних користувачів;
− вимоги до надійності, що забезпечують стабільну роботу системи без
30
ЧДТУ.262245 007 ПЗ
збоїв;
− вимоги до безпеки, що включають захист персональних даних
користувачів;
− вимоги до масштабованості, що дозволяють розширювати систему при
зростанні навантаження;
− вимоги до зручності використання, що забезпечують інтуїтивно
зрозумілий інтерфейс;
− вимоги до сумісності, що передбачають роботу системи на різних
пристроях і платформах.
Таким чином, формування вимог до програмного забезпечення дозволяє
визначити функціональні можливості та обмеження автоматизованої системи
онлайн-прокторингу, забезпечує узгодження між замовником і розробником та
створює основу для подальшого проєктування і реалізації системи.
2.2.2. Формування вимог за допомогою діаграми прецедентів
Для формалізації функціональних вимог до програмного забезпечення
автоматизованої системи онлайн-прокторингу доцільно використовувати
діаграми прецедентів (Use Case), які є одним із основних інструментів мови
UML. Діаграма прецедентів дозволяє представити систему з точки зору
користувача та відобразити основні сценарії взаємодії між зовнішніми акторами
та системою [8].
Основною метою побудови діаграми прецедентів є визначення
функціональних можливостей системи та уточнення вимог замовника у вигляді
конкретних сценаріїв використання. Такий підхід дозволяє краще зрозуміти, які
дії повинна виконувати система, а також забезпечує узгодження між
користувачами та розробниками.
У межах даної роботи виділено основних акторів системи, які взаємодіють
із програмним забезпеченням. Головними акторами є студент та адміністратор.
Студент є користувачем системи, який проходить тестування, взаємодіє з
інтерфейсом системи, надає відповіді на запитання та отримує результати.
Адміністратор виконує функції керування системою, зокрема створення та
31
ЧДТУ.262245 007 ПЗ
редагування екзаменів, додавання запитань, перегляд результатів тестування та
аналіз зафіксованих порушень.
На основі аналізу предметної області визначено основні прецеденти
системи. До них належать процеси реєстрації та входу до системи, створення
екзамену, додавання запитань, проходження тестування, збереження результатів,
моніторинг поведінки користувача, фіксація порушень та перегляд результатів.
Кожен із цих прецедентів описує завершений сценарій взаємодії користувача із
системою та відображає її функціональні можливості.
На рисунку 2.7 наведено побудовану діаграму прецедентів автоматизованої
системи онлайн-прокторингу.
Рис 2.7 - Діаграма прецендентів автоматизованої системи прокторингу
32
ЧДТУ.262245 007 ПЗ
Прецедент «Проходження тестування» є центральним для даної системи,
оскільки саме він визначає основний процес взаємодії студента із системою. У
межах цього прецеденту користувач обирає екзамен, відповідає на запитання та
отримує результат. Даний процес супроводжується виконанням додаткових
прецедентів, таких як моніторинг поведінки та фіксація подій прокторингу.
Прецедент «Моніторинг поведінки користувача» реалізується паралельно з
процесом проходження тестування та передбачає аналіз дій користувача з метою
виявлення можливих порушень. У разі виявлення підозрілої активності
виконується прецедент «Фіксація порушення», який забезпечує збереження
відповідної інформації у системі.
Прецеденти, пов’язані з адміністратором, включають створення екзаменів,
додавання та редагування запитань, а також перегляд результатів тестування і
журналу порушень. Ці сценарії забезпечують управління системою та контроль її
функціонування.
Застосування діаграми прецедентів дозволяє структурувати функціональні
вимоги системи та представити їх у наочному вигляді. Вона є відправною
точкою для подальшого проєктування та деталізації системи, зокрема для
побудови діаграм діяльності, послідовності та класів.
2.3. Проектування логічної структури програмного комплексу
2.3.1. Діаграми класів
Діаграми класів є основним інструментом логічного проєктування
програмного забезпечення, оскільки вони відображають статичну структуру
системи, її складові елементи та зв’язки між ними [9]. У межах даної роботи
діаграма класів використовується для формалізованого представлення
архітектури автоматизованої системи онлайн-прокторингу, що дозволяє
визначити склад програмних компонентів, їх властивості та взаємодію.
З огляду на клієнт-серверну архітектуру розроблюваної системи, доцільно
розділити діаграми класів на дві частини: серверну (бекенд) та клієнтську
(фронтенд). Такий підхід дозволяє чітко відобразити розподіл відповідальності
33
ЧДТУ.262245 007 ПЗ
між компонентами системи та забезпечує кращу структуризацію програмного
забезпечення.
Серверна частина системи відповідає за обробку даних, реалізацію бізнес-
логіки, збереження інформації та забезпечення взаємодії з клієнтською частиною
через API. Основними елементами діаграми класів бекенду є моделі даних,
контролери та допоміжні компоненти (рис. 2.8).
Центральне місце у серверній частині займає клас користувача, який
містить основні атрибути, такі як ім’я, електронна адреса, пароль та роль. Даний
клас використовується для реалізації механізмів автентифікації та авторизації.
Рисунок 2.8 – Діаграмма класів серверної частини
34
ЧДТУ.262245 007 ПЗ
Клас екзамену описує структуру тестування та містить інформацію про
назву, тривалість, часові межі проведення та ідентифікатор екзамену. Він
пов’язаний із класом запитання, який визначає зміст тестових завдань. Кожне
запитання, у свою чергу, має набір варіантів відповідей, що представлені
окремим класом.
Клас результату тестування використовується для збереження інформації
про проходження екзамену користувачем. Він містить дані про кількість
правильних відповідей, підсумковий бал та інші показники. Додатково
використовується клас відповіді користувача, який фіксує вибрані варіанти
відповідей та їх правильність.
Особливе значення має клас журналу порушень, який забезпечує
збереження інформації про підозрілі дії користувача під час тестування. Цей клас
містить агреговані показники різних типів порушень, що дозволяє аналізувати
поведінку користувача.
Контролери виступають як проміжна ланка між клієнтською частиною та
моделями даних. Вони обробляють запити, викликають відповідні методи
моделей та повертають результати у вигляді відповідей API. Таким чином,
серверна частина реалізує повний цикл обробки даних — від отримання запиту
до формування відповіді.
Клієнтська частина системи відповідає за взаємодію з користувачем,
відображення інформації та передачу даних на сервер. Вона реалізує інтерфейс
користувача та забезпечує зручний доступ до функціональних можливостей
системи.
Основними елементами діаграми класів фронтенду є компоненти
інтерфейсу, сервіси для роботи з API та моделі даних, що використовуються на
клієнтській стороні. Користувацький інтерфейс представлений компонентами,
які відповідають за різні функціональні частини системи, зокрема сторінки
авторизації, проходження тестування, перегляду результатів та адміністративної
панелі (рис. 2.9, рис. 2.10).
35
ЧДТУ.262245 007 ПЗ
Рисунок 2.9 – Діаграма класів серверної частини з атрибутами
36
ЧДТУ.262245 007 ПЗ
Рисунок 2.10 – Діаграмма класів клієнтської частини
Сервіси виконують роль посередника між компонентами інтерфейсу та
серверною частиною. Вони здійснюють відправлення HTTP-запитів до API,
обробку отриманих даних та передачу їх у компоненти для відображення.
Моделі даних на клієнтській стороні дублюють основні сутності серверної
частини, що дозволяє забезпечити узгодженість структури даних. Це спрощує
обмін інформацією між клієнтом і сервером та підвищує ефективність роботи
37
ЧДТУ.262245 007 ПЗ
системи.
Окрему роль відіграють компоненти, що забезпечують моніторинг
поведінки користувача під час тестування. Вони відповідають за отримання
даних з веб-камери, аналіз дій користувача та передачу інформації про підозрілі
події на сервер.
Таким чином, побудова діаграм класів дозволяє формалізувати структуру
програмного забезпечення автоматизованої системи онлайн-прокторингу,
визначити основні компоненти системи та встановити зв’язки між ними.
Розподіл діаграми на серверну та клієнтську частини забезпечує чітке
розмежування функціональності та сприяє ефективній реалізації клієнт-серверної
архітектури.
2.3.2. Діаграми пакетів
Діаграми пакетів у мові UML використовуються для представлення
структурної організації програмного забезпечення на більш високому рівні
абстракції. Вони дозволяють згрупувати пов’язані елементи системи у логічні
модулі (пакети) та відобразити залежності між ними [10]. Такий підхід сприяє
кращому розумінню архітектури системи, підвищує її модульність і спрощує
процес супроводу та розширення.
У межах розробки автоматизованої системи онлайн-прокторингу діаграми
пакетів застосовуються для відображення структури програмного забезпечення
як сукупності взаємопов’язаних компонентів. З урахуванням клієнт-серверної
архітектури система поділяється на два основні рівні: серверну частину (бекенд)
та клієнтську частину (фронтенд). Кожен із цих рівнів, у свою чергу, складається
з окремих пакетів, що виконують визначені функції.
Серверна частина системи включає пакети, що відповідають за обробку
запитів, реалізацію бізнес-логіки та роботу з даними. Основними пакетами є
пакет моделей, пакет контролерів, пакет маршрутів (роутів) та пакет проміжного
програмного забезпечення (middleware). Пакет моделей містить класи, що
описують структуру даних, зокрема користувачів, екзамени, запитання,
результати тестування та журнал порушень. Пакет контролерів реалізує логіку
38
ЧДТУ.262245 007 ПЗ
обробки запитів і взаємодії між клієнтом та сервером. Пакет маршрутів визначає
точки входу до системи через API, а пакет middleware забезпечує виконання
допоміжних функцій, таких як автентифікація та перевірка прав доступу.
На рисунку 2.11 наведено побудовано діаграму пакетів автоматизованої
системи онлайн-прокторингу.
Рисунок 2.11 – Діаграма пакетів системи онлайн-прокторингу
Клієнтська частина системи також має модульну структуру і включає
пакети сторінок, компонентів, сервісів та моделей даних. Пакет сторінок містить
основні інтерфейси користувача, такі як сторінка авторизації, сторінка
тестування, панель адміністратора та сторінка результатів. Пакет компонентів
включає повторно використовувані елементи інтерфейсу, наприклад блоки
запитань, панелі навігації та елементи відображення результатів. Пакет сервісів
забезпечує взаємодію з серверною частиною через API, а пакет моделей даних
визначає структуру об’єктів, що використовуються у клієнтському додатку.
39
ЧДТУ.262245 007 ПЗ
Взаємодія між пакетами здійснюється через залежності, які відображають
використання одного пакета іншим. Наприклад, пакет контролерів залежить від
пакета моделей, оскільки використовує їх для обробки даних. У клієнтській
частині пакети сторінок і компонентів залежать від сервісів, які забезпечують
доступ до серверного API. Таким чином, діаграма пакетів дозволяє відобразити
загальну архітектуру системи та взаємозв’язки між її складовими.
Використання діаграм пакетів забезпечує структуризацію програмного
забезпечення, сприяє зменшенню складності системи та дозволяє ефективно
організувати процес розробки. Вони є важливим етапом проєктування, що
передує деталізації структури системи за допомогою діаграм класів і
компонентів.
2.4. Архітектурне проектування
2.4.1. Діаграма компонентів
Діаграма компонентів є одним із основних інструментів архітектурного
проєктування програмного забезпечення, що використовується для відображення
фізичної структури системи у вигляді взаємопов’язаних програмних
компонентів. Вона дозволяє представити систему як сукупність модулів, кожен з
яких виконує певні функції та взаємодіє з іншими компонентами через визначені
інтерфейси [11].
У межах даної роботи діаграма компонентів використовується для
відображення архітектури автоматизованої системи онлайн-прокторингу, що
реалізована за клієнт-серверною моделлю. Такий підхід передбачає розподіл
системи на дві основні частини: клієнтську (frontend) та серверну (backend), які
взаємодіють між собою через програмний інтерфейс прикладного програмування
(API).
Клієнтська частина системи включає компоненти, що відповідають за
взаємодію з користувачем. До них належать інтерфейс користувача, модулі
авторизації, проходження тестування, відображення результатів та
адміністративна панель. Важливим компонентом є модуль прокторингу, який
40
ЧДТУ.262245 007 ПЗ
забезпечує отримання даних із веб-камери та передачу інформації про поведінку
користувача на сервер.
Нижче наведено діаграму компонентів автоматизованої системи онлайн-
прокторингу (рис 2.12).
Рис 2.12 - Діаграма компонентів автоматизованої системи прокторингу
Серверна частина системи складається з компонентів, що реалізують
бізнес-логіку, обробку запитів і збереження даних. До основних компонентів
41
ЧДТУ.262245 007 ПЗ
належать модуль автентифікації користувачів, модуль керування екзаменами,
модуль обробки результатів тестування та модуль фіксації порушень. Ці
компоненти взаємодіють із базою даних, у якій зберігається вся необхідна
інформація.
Взаємодія між клієнтською та серверною частинами здійснюється через
API, який виступає як посередник для передачі даних. Клієнт формує HTTP-
запити до серверу, а сервер обробляє ці запити та повертає результати у
відповідному форматі. Така організація забезпечує незалежність компонентів і
дозволяє масштабувати систему.
Діаграма компонентів дозволяє наочно представити структуру системи,
визначити основні модулі та їх взаємозв’язки, а також спростити процес
подальшої реалізації та супроводу програмного забезпечення.
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Діаграма розгортання є одним із засобів архітектурного проєктування, який
використовується для відображення фізичної структури програмної системи та її
розміщення на апаратних засобах. Вона дозволяє представити, на яких пристроях
або вузлах виконується програмне забезпечення [12], а також показати
взаємозв’язки між цими вузлами (рис. 2.13).
У межах розробки автоматизованої системи онлайн-прокторингу
розгортання реалізується відповідно до клієнт-серверної архітектури. Основними
вузлами системи є клієнтський пристрій користувача, сервер додатку та сервер
бази даних. Кожен із цих вузлів виконує визначені функції та взаємодіє з іншими
через мережу.
Клієнтський вузол представлений персональним комп’ютером або
мобільним пристроєм користувача, на якому виконується веб-браузер. Саме
через браузер здійснюється доступ до системи онлайн-прокторингу. Клієнтська
частина забезпечує відображення інтерфейсу користувача, обробку введених
даних та передачу запитів на сервер. Крім того, клієнтський пристрій
використовує веб-камеру та інші сенсори для збору інформації про поведінку
42
ЧДТУ.262245 007 ПЗ
користувача під час тестування.
Рисунок 2.13 – Діаграма розгортання системи онлайн-прокторингу
Сервер додатку є центральним елементом системи, який відповідає за
обробку запитів, реалізацію бізнес-логіки та координацію взаємодії між
компонентами. На сервері виконуються програмні модулі, що забезпечують
автентифікацію користувачів, управління екзаменами, обробку результатів
тестування та фіксацію порушень. Сервер приймає HTTP-запити від клієнта,
обробляє їх і повертає відповідні результати.
Сервер бази даних забезпечує збереження всієї інформації, що
використовується системою. До цієї інформації належать дані про користувачів,
43
ЧДТУ.262245 007 ПЗ
екзамени, запитання, результати тестування та журнали порушень. Взаємодія
між сервером додатку та базою даних здійснюється через відповідні механізми
доступу до даних.
Взаємодія між клієнтським вузлом і сервером додатку здійснюється через
мережу Інтернет із використанням протоколу HTTP або HTTPS. Це дозволяє
забезпечити доступ до системи з будь-якого пристрою, підключеного до мережі.
Використання захищеного протоколу HTTPS забезпечує конфіденційність і
цілісність переданих даних.
Таким чином, діаграма розгортання відображає фізичну архітектуру
системи онлайн-прокторингу, демонструє розподіл компонентів між апаратними
вузлами та дозволяє оцінити особливості взаємодії між ними. Це є важливим
етапом проєктування, що забезпечує ефективне розгортання та подальшу
експлуатацію системи.
2.5. Моделювання поведінки системи
2.5.1. Діаграма діяльності
Діаграми діяльності в мові UML використовуються для моделювання
динамічних аспектів системи та відображення послідовності виконання дій у
межах певного процесу. Вони дозволяють представити логіку роботи системи у
вигляді потоків керування, що включають дії, умови переходів та паралельні
процеси.
У межах розробки автоматизованої системи онлайн-прокторингу діаграми
діяльності застосовуються для опису основних сценаріїв функціонування
системи. Це дозволяє деталізувати процеси взаємодії користувача із системою, а
також визначити послідовність виконання операцій під час обробки даних [13].
Розглянуто три основні процеси: авторизація користувача, проходження
тестування та фіксація порушень під час онлайн-прокторингу.
Діаграма діяльності процесу авторизації користувача – даний процес
описує взаємодію користувача із системою під час входу. Користувач вводить
свої облікові дані, після чого система виконує їх перевірку. У разі успішної
44
ЧДТУ.262245 007 ПЗ
автентифікації користувач отримує доступ до системи, інакше — отримує
повідомлення про помилку (рис 2.14).
Рисунок 2.14 – Діаграма діяльності процесу авторизації користувача
Діаграма діяльності процесу проходження тестування – даний процес є
основним у системі та описує послідовність дій користувача під час виконання
тесту. Він включає вибір екзамену, проходження запитань, збереження
відповідей та формування результату (рис 2.15).
45
ЧДТУ.262245 007 ПЗ
Рисунок 2.15 – Діаграма діяльності процесу проходження тестування
Діаграма діяльності процесу онлайн-прокторингу – даний процес описує
моніторинг поведінки користувача під час проходження тестування. Система
аналізує дані з камери, визначає наявність підозрілих дій та у разі їх виявлення
фіксує порушення (рис 2.16).
46
ЧДТУ.262245 007 ПЗ
Рисунок 2.16 – Діаграма діяльності процесу онлайн-прокторингу
47
ЧДТУ.262245 007 ПЗ
Таким чином, використання діаграм діяльності дозволяє детально описати
логіку функціонування автоматизованої системи онлайн-прокторингу, визначити
послідовність виконання основних процесів та забезпечити їх формалізоване
представлення. Побудовані діаграми є основою для подальшого моделювання
поведінки системи та реалізації програмного забезпечення.
2.5.2. Діаграма послідовності
Діаграма послідовності в мові UML використовується для моделювання
динамічної поведінки системи шляхом відображення взаємодії між її об’єктами у
часі. Вона дозволяє показати порядок передавання повідомлень між учасниками
процесу, визначити логіку виконання сценаріїв та деталізувати механізми
взаємодії між окремими компонентами програмного забезпечення [14].
У межах розробки автоматизованої системи онлайн-прокторингу діаграми
послідовності застосовуються для формалізованого опису основних сценаріїв
функціонування системи. Побудова таких діаграм дає можливість детально
відобразити взаємодію між користувачем, клієнтською частиною, сервером,
базою даних та підсистемою прокторингу. Це є важливим етапом проєктування,
оскільки дозволяє уточнити порядок виконання операцій та перевірити
узгодженість архітектурних рішень.
Розглянуто дві діаграми послідовності, що описують ключові процеси
системи: авторизацію користувача та проходження тестування з фіксацією
результатів і подій прокторингу.
Процес авторизації є одним із базових сценаріїв взаємодії користувача із
системою. У цьому процесі користувач вводить облікові дані у клієнтському
інтерфейсі, після чого ці дані передаються на сервер. Серверна частина виконує
перевірку введеної інформації, звертається до бази даних для пошуку
користувача та, у разі успішної автентифікації, повертає результат клієнтському
застосунку. Після цього користувач отримує доступ до функціональних
можливостей системи відповідно до своєї ролі.
На рисунку 2.17 наведено діаграму послідовності процесу авторизації
користувача.
48
ЧДТУ.262245 007 ПЗ
Рисунок 2.17 – Діаграма послідовності процесу авторизації користувача
Отже, наведена діаграма відображає стандартний процес взаємодії між
користувачем, клієнтською та серверною частинами системи під час входу. Вона
дозволяє побачити послідовність перевірки облікових даних та підтверджує, що
механізм автентифікації реалізується через взаємодію інтерфейсу, контролера
авторизації та бази даних.
Другим ключовим сценарієм є процес проходження тестування, який
супроводжується моніторингом поведінки користувача. Після вибору екзамену
клієнтська частина надсилає запит на отримання списку запитань. Сервер
обробляє цей запит, звертається до бази даних та повертає необхідні дані.
Користувач проходить тестування, послідовно надаючи відповіді, які
зберігаються у системі. Паралельно модуль прокторингу аналізує поведінку
користувача та, у разі виявлення підозрілих дій, передає інформацію на сервер
для фіксації у журналі порушень. Після завершення тестування система
обчислює підсумковий результат, зберігає його в базі даних та повертає
користувачу.
49
ЧДТУ.262245 007 ПЗ
Нижче наведено побудовану діаграму послідовності процесу проходження
тестування (рис 2.18).
Рисунок 2.18 – Діаграма послідовності процесу проходження тестування
Наведена діаграма відображає один із найважливіших сценаріїв роботи
системи, у якому поєднуються одразу два процеси: виконання тестових завдань
та паралельний моніторинг поведінки користувача. Завдяки цьому
забезпечується не лише автоматизоване оцінювання знань, а й фіксація
потенційних порушень академічної доброчесності.
Таким чином, діаграми послідовності дозволяють деталізувати основні
сценарії взаємодії в автоматизованій системі онлайн-прокторингу та відобразити
порядок обміну повідомленнями між її компонентами. Побудовані діаграми
підтверджують логічну узгодженість архітектури системи та створюють основу
для її подальшої реалізації.
2.5.3. Діаграма комунікації
50
ЧДТУ.262245 007 ПЗ
Діаграма комунікації в мові UML використовується для моделювання
взаємодії між об’єктами системи та відображення обміну повідомленнями між
ними. На відміну від діаграми послідовності, де основна увага приділяється
часовому порядку виконання операцій, діаграма комунікації акцентує увагу на
структурних зв’язках між учасниками взаємодії. Це дозволяє наочно показати,
які саме компоненти беруть участь у виконанні певного сценарію та яким чином
вони обмінюються повідомленнями (рис 2.19).
У межах автоматизованої системи онлайн-прокторингу діаграма
комунікації доцільно використовується для опису взаємодії між користувачем,
клієнтською частиною, серверними контролерами, модулем прокторингу та
базою даних у процесі проходження тестування. Такий підхід дозволяє
відобразити не лише порядок виконання дій, а й логічні зв’язки між основними
компонентами системи.
У даній роботі діаграма комунікації побудована для сценарію проходження
тестування з одночасною фіксацією результатів і можливих порушень. У межах
цього сценарію студент через клієнтський інтерфейс ініціює вибір екзамену. Далі
клієнтська частина звертається до контролера екзаменів для отримання запитань,
які вибираються з бази даних. Після цього запитання передаються користувачу
для проходження тестування.
Під час проходження тесту клієнтська частина забезпечує збереження
відповідей користувача, а також взаємодіє з модулем прокторингу, який виконує
аналіз поведінки. У разі виявлення підозрілих дій модуль прокторингу передає
дані контролеру журналу порушень, а той, у свою чергу, зберігає відповідну
інформацію в базі даних. Після завершення тестування відповіді передаються до
контролера результатів, який обчислює та зберігає підсумковий результат. Після
цього клієнтський застосунок отримує результат і відображає його користувачу.
Таким чином, діаграма комунікації дозволяє відобразити логічну структуру
взаємодії між об’єктами системи та показати основні інформаційні потоки, що
виникають під час виконання ключового сценарію роботи системи онлайн-
51
ЧДТУ.262245 007 ПЗ
прокторингу. Вона доповнює діаграми послідовності та діяльності, забезпечуючи
більш повне уявлення про поведінку системи.
Рисунок 2.19 – Діаграма комунікації процесу проходження тестування
2.5.4. Діаграма скінченного автомату
Діаграма скінченного автомату в мові UML використовується для
моделювання станів об’єкта та переходів між ними в процесі його
52
ЧДТУ.262245 007 ПЗ
функціонування. Вона дозволяє відобразити зміну стану системи або окремої її
сутності залежно від подій, що відбуваються під час роботи [15]. Такий тип
діаграм є особливо корисним у випадках, коли поведінка об’єкта визначається
послідовністю станів і умовами переходу між ними.
У межах автоматизованої системи онлайн-прокторингу доцільно
використати діаграму скінченного автомату для моделювання життєвого циклу
процесу проходження тестування (рис. 2.20). Це зумовлено тим, що сесія
тестування є об’єктом, який послідовно переходить між кількома чітко
визначеними станами: від моменту створення або ініціалізації до завершення,
оцінювання та збереження результатів. Крім того, в процесі виконання тесту
можуть виникати додаткові події, пов’язані з фіксацією порушень, що також
впливають на загальний стан системи.
Початковим станом є очікування входу користувача до системи. Після
успішної авторизації користувач переходить до стану вибору екзамену. Далі,
після запуску тестування, формується активна сесія, в межах якої відбувається
відображення запитань, надання відповідей та одночасний моніторинг поведінки
користувача. У процесі тестування система може фіксувати події прокторингу,
проте це не обов’язково змінює основний стан сесії, а лише супроводжує її
виконання.
Після завершення відповіді на всі запитання або після закінчення
відведеного часу система переходить до стану завершення тестування. У цьому
стані виконується обчислення результату, його збереження в базі даних і
формування підсумкової інформації для користувача. Завершальним станом є
відображення результату, після чого сесія тестування вважається завершеною.
Використання діаграми скінченного автомату дозволяє формалізувати
зміну станів сесії тестування, виявити ключові події, що ініціюють переходи, а
також забезпечити цілісне уявлення про поведінку системи в процесі її
функціонування. Це дає змогу краще зрозуміти логіку роботи програмного
забезпечення та спрощує його подальшу реалізацію.
53
ЧДТУ.262245 007 ПЗ
Рисунок 2.20 – Діаграма скінченного автомату сесії тестування
54
ЧДТУ.262245 007 ПЗ
Висновки до розділу 2
У другому розділі кваліфікаційної роботи виконано проєктування
програмного забезпечення автоматизованої системи онлайн-прокторингу із
застосуванням сучасних методів моделювання. Проведено формалізацію
предметної області, визначено її основні сутності, їх властивості та
взаємозв’язки, а також сформовано словник предметної області, що забезпечує
однозначність трактування основних термінів.
У ході роботи використано уніфіковану мову моделювання UML, що
дозволило представити систему на різних рівнях абстракції. Зокрема, побудовано
діаграми класів, які відображають структуру програмного забезпечення та
взаємозв’язки між його компонентами, а також діаграми пакетів, що
демонструють модульну організацію системи. Діаграма компонентів дозволила
відобразити архітектуру програмного забезпечення, а діаграма розгортання —
фізичне розміщення системи на апаратних засобах.
Особливу увагу приділено моделюванню поведінки системи. Для цього
побудовано діаграми діяльності, що відображають послідовність виконання
основних процесів, діаграми послідовності, які деталізують взаємодію між
компонентами системи у часі, а також діаграму комунікації, яка показує
структуру зв’язків між об’єктами під час виконання ключових сценаріїв.
Додатково розроблено діаграму скінченного автомату, що дозволяє описати
зміну станів системи в процесі проходження тестування.
У результаті виконаного моделювання сформовано цілісне уявлення про
архітектуру та функціонування автоматизованої системи онлайн-прокторингу.
Отримані результати забезпечують обґрунтовану основу для подальшої
реалізації програмного забезпечення, визначають структуру системи, її
компоненти та механізми взаємодії між ними.
Таким чином, проведене моделювання дозволило деталізувати вимоги до
системи, обґрунтувати вибір архітектурних рішень та створити основу для
переходу до етапу програмної реалізації автоматизованої системи онлайн-
прокторингу.
55
ЧДТУ.262245 007 ПЗ
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1. Розробка програмного комплексу
3.1.1. Обґрунтування вибору засобів реалізації
Вибір засобів реалізації є важливим етапом розробки програмного
забезпечення, оскільки він безпосередньо впливає на ефективність,
продуктивність, масштабованість та зручність супроводу системи. У межах
розробки автоматизованої системи онлайн-прокторингу було обрано сучасний
стек технологій, що забезпечує реалізацію клієнт-серверної архітектури,
підтримує обробку даних у режимі реального часу та дозволяє ефективно
працювати з веб-інтерфейсом.
Для реалізації серверної частини системи обрано платформу Node.js, яка
забезпечує виконання JavaScript на стороні сервера та дозволяє ефективно
обробляти велику кількість одночасних запитів завдяки асинхронній моделі
виконання. Використання Node.js є доцільним у задачах, пов’язаних із веб-
додатками, оскільки воно забезпечує високу продуктивність і добре підходить
для реалізації API [16].
У якості фреймворку для розробки серверної частини використано
Express.js. Даний фреймворк є легковаговим і зручним у використанні, що
дозволяє швидко створювати REST API, організовувати маршрутизацію запитів
та структурувати проєкт. Express.js також має широку екосистему бібліотек, що
спрощує реалізацію додаткового функціоналу, зокрема автентифікації, обробки
запитів та роботи з базою даних [17].
Для збереження даних обрано нереляційну базу даних MongoDB. Такий
вибір обумовлений тим, що структура даних у системі онлайн-прокторингу є
гнучкою та може змінюватися залежно від вимог. MongoDB дозволяє зберігати
дані у форматі документів, що добре відповідає об’єктно-орієнтованій моделі
системи. Крім того, ця база даних забезпечує високу продуктивність та
можливість масштабування [18].
56
ЧДТУ.262245 007 ПЗ
Для взаємодії з базою даних використано бібліотеку Mongoose, яка надає
зручний інтерфейс для роботи з MongoDB, дозволяє визначати схеми даних та
забезпечує валідацію інформації. Це спрощує розробку та підвищує надійність
системи.
Клієнтська частина системи реалізована з використанням бібліотеки React,
яка дозволяє створювати сучасні інтерактивні інтерфейси користувача. React
базується на компонентному підході, що забезпечує повторне використання
елементів інтерфейсу та спрощує підтримку коду. Використання цієї бібліотеки
дозволяє ефективно організувати взаємодію користувача із системою та
забезпечити швидке оновлення інтерфейсу без перезавантаження сторінки.
Для організації обміну даними між клієнтською та серверною частинами
використовується REST API, що базується на протоколі HTTP. Такий підхід є
стандартним для веб-додатків і забезпечує простоту інтеграції, масштабованість
та незалежність компонентів системи.
У реалізації підсистеми онлайн-прокторингу використано можливості
браузера для роботи з веб-камерою, зокрема API доступу до медіапристроїв. Це
дозволяє отримувати відеопотік без використання додаткового програмного
забезпечення та передавати дані для подальшого аналізу. Для обробки інформації
про поведінку користувача можуть використовуватися алгоритми аналізу подій
або зовнішні бібліотеки.
Таким чином, обрані засоби реалізації забезпечують ефективну розробку
автоматизованої системи онлайн-прокторингу, відповідають сучасним вимогам
до веб-додатків та дозволяють створити масштабовану, продуктивну та зручну у
використанні систему. Вибраний технологічний стек є обґрунтованим і
забезпечує можливість подальшого розвитку та вдосконалення програмного
забезпечення.
3.1.2. Опис структурної (функціональної) схеми
Структурна (функціональна) схема програмного забезпечення відображає
загальну організацію системи, її основні компоненти та взаємозв’язки між ними.
Вона дозволяє представити систему як сукупність функціональних блоків, кожен
57
ЧДТУ.262245 007 ПЗ
з яких виконує визначені задачі та взаємодіє з іншими компонентами для
досягнення загальної мети [19].
Автоматизована система онлайн-прокторингу реалізована за клієнт-
серверною архітектурою, що передбачає розподіл функціональності між
клієнтською та серверною частинами (рис. 3.1). Такий підхід забезпечує
гнучкість, масштабованість та можливість незалежного розвитку окремих
компонентів системи.
Клієнтська частина системи відповідає за взаємодію з користувачем та
включає інтерфейс користувача, який реалізований у вигляді веб-додатку.
Основними функціональними модулями клієнтської частини є модуль
автентифікації, модуль проходження тестування, модуль відображення
результатів та адміністративний модуль. Через ці компоненти користувач
здійснює взаємодію із системою, вводить дані, отримує результати та виконує
необхідні дії відповідно до своєї ролі.
Окремим важливим елементом клієнтської частини є модуль онлайн-
прокторингу, який забезпечує збір інформації про поведінку користувача під час
проходження тестування. Він використовує можливості веб-браузера для доступу
до камери та інших пристроїв і передає отримані дані на сервер для подальшої
обробки.
Серверна частина системи виконує функції обробки запитів, реалізації
бізнес-логіки та управління даними. Вона складається з кількох взаємопов’язаних
модулів. Модуль автентифікації забезпечує перевірку облікових даних
користувачів і контроль доступу до системи. Модуль керування екзаменами
відповідає за створення, редагування та зберігання тестів і запитань. Модуль
обробки результатів забезпечує обчислення підсумкових оцінок і збереження
результатів тестування. Модуль фіксації порушень здійснює обробку даних,
отриманих від підсистеми прокторингу, та формує журнал підозрілих дій.
Взаємодія між клієнтською та серверною частинами реалізується через
програмний інтерфейс (API), який забезпечує обмін даними за допомогою HTTP-
запитів. Клієнт надсилає запити до серверу, а сервер обробляє їх і повертає
58
ЧДТУ.262245 007 ПЗ
відповідні результати у стандартизованому форматі. Такий механізм забезпечує
чітке розмежування відповідальності між компонентами системи.
Усі дані системи зберігаються у базі даних, яка є окремим компонентом
структурної схеми. Вона забезпечує централізоване збереження інформації про
користувачів, екзамени, запитання, результати тестування та журнали порушень.
Серверна частина здійснює доступ до бази даних для читання та запису
інформації.
Таким чином, структурна (функціональна) схема програмного забезпечення
відображає взаємодію між основними компонентами системи онлайн-
прокторингу, визначає їх функціональне призначення та забезпечує цілісне
уявлення про організацію програмного забезпечення. Вона є основою для
реалізації системи та дозволяє забезпечити узгоджену роботу всіх її складових.
Рисунок 3.1 – Структурна (функціональна) схема автоматизованої системи
онлайн-прокторингу
3.1.3. Опис логічної схеми системи
Логічна схема системи відображає внутрішню організацію програмного
59
ЧДТУ.262245 007 ПЗ
забезпечення, логіку взаємодії між основними модулями та послідовність
обробки даних у межах автоматизованої системи онлайн-прокторингу. На відміну
від структурної схеми, яка акцентує увагу на загальному складі компонентів,
логічна схема дає змогу описати принцип функціонування системи, її
інформаційні потоки та порядок виконання основних операцій.
Автоматизована система онлайн-прокторингу реалізована як
багатокомпонентна інформаційна система, у якій усі функціональні елементи
взаємодіють між собою в межах клієнт-серверної архітектури. Логіка роботи
системи базується на розмежуванні функцій між клієнтською частиною, сервером
прикладної логіки та сховищем даних (рис. 3.2). Така організація дозволяє
забезпечити централізовану обробку запитів, надійне збереження інформації та
зручний доступ користувачів до функціональних можливостей системи.
Початковим етапом роботи системи є автентифікація користувача. Після
введення облікових даних клієнтська частина формує запит до серверної частини,
де виконується перевірка коректності введеної інформації. У разі успішної
перевірки система визначає роль користувача та надає доступ до відповідного
набору функцій. Для студента основними функціями є перегляд доступних
екзаменів, проходження тестування та перегляд результатів. Для адміністратора
передбачено створення і редагування екзаменів, керування запитаннями,
перегляд підсумків тестування та аналіз журналів порушень.
Після авторизації студент отримує доступ до списку доступних екзаменів.
Під час вибору конкретного екзамену клієнтський застосунок надсилає запит до
сервера, який отримує відповідні дані з бази даних і повертає їх користувачу.
Після запуску тестування формується активна сесія, у межах якої система
послідовно відображає запитання, приймає відповіді користувача та тимчасово
накопичує їх для подальшої обробки.
Паралельно з процесом проходження тестування функціонує підсистема
онлайн-прокторингу. Вона забезпечує збір інформації про поведінку користувача
під час екзамену за допомогою веб-камери та інших доступних засобів
спостереження. Отримані дані аналізуються та, у разі виявлення підозрілих дій,
60
ЧДТУ.262245 007 ПЗ
передаються до серверної частини для фіксації. Сервер обробляє ці дані та
зберігає їх у журналі порушень, що дає можливість здійснювати подальший
аналіз поведінки користувача під час тестування.
Рисунок 3.2 – Логічна схема системи онлайн-прокторингу
61
ЧДТУ.262245 007 ПЗ
Після завершення екзамену клієнтська частина передає всі відповіді
користувача на сервер для обробки. Серверна частина виконує порівняння
наданих відповідей із правильними варіантами, обчислює кількість правильних
відповідей, формує підсумковий бал і зберігає результат у базі даних. Після цього
результат передається назад до клієнтської частини та відображається
користувачу.
Для адміністратора логічна схема системи передбачає окремий набір
операцій. Адміністратор може створювати нові екзамени, задавати їх параметри,
додавати запитання та варіанти відповідей. Усі ці дії виконуються через
клієнтський інтерфейс і передаються на сервер, де відповідні зміни фіксуються у
базі даних. Крім того, адміністратор може отримувати інформацію про
результати тестування та переглядати дані журналу порушень для оцінювання
доброчесності проходження екзамену.
Таким чином, логічна схема системи охоплює процеси автентифікації
користувачів, керування екзаменами, проходження тестування, фіксації подій
прокторингу, обчислення результатів та збереження інформації у базі даних.
Вона відображає взаємозв’язок між функціональними модулями системи та
дозволяє сформувати цілісне уявлення про логіку її роботи. Побудова логічної
схеми є важливим етапом проєктування, оскільки вона забезпечує обґрунтований
перехід від моделі системи до її програмної реалізації.
3.1.4. Розробка бази даних
База даних є одним із ключових компонентів автоматизованої системи
онлайн-прокторингу, оскільки саме вона забезпечує централізоване збереження
інформації про користувачів, екзамени, запитання, результати тестування та
зафіксовані порушення. У межах розробки системи для зберігання даних
використано MongoDB, яка належить до класу нереляційних документно-
орієнтованих систем керування базами даних. Такий вибір зумовлений гнучкістю
структури даних, простотою масштабування та зручністю інтеграції з серверною
частиною, реалізованою на Node.js.
Незважаючи на те, що MongoDB оперує поняттями колекцій і документів,
62
ЧДТУ.262245 007 ПЗ
при проєктуванні бази даних доцільно розглядати її структуру у вигляді логічних
таблиць, оскільки це спрощує опис сутностей, їх атрибутів і зв’язків між ними
[18]. У розробленій системі основними логічними таблицями (колекціями) є User,
Exam, Question, TestResult та CheatingLog.
На рисуку 3.3 наведено ERD-діаграму, яка відображає основні логічні
таблиці бази даних та зв’язки між ними
Рисунок 3.3 – ERD бази даних автоматизованої системи онлайн-прокторингу
Таблиця User призначена для збереження даних про всіх користувачів
63
ЧДТУ.262245 007 ПЗ
системи. Вона містить реєстраційну інформацію та дані, необхідні для
автентифікації й авторизації. Основними атрибутами є унікальний ідентифікатор
запису, ім’я користувача, електронна адреса, пароль і роль у системі. Електронна
адреса є унікальною, що дозволяє однозначно ідентифікувати користувача.
Пароль зберігається в зашифрованому вигляді, що забезпечує підвищення рівня
безпеки. Поле ролі визначає права доступу користувача і дозволяє розмежовувати
функціональні можливості студента та адміністратора.
Таблиця також містить службові поля часу створення та оновлення запису.
Вони формуються автоматично та використовуються для аудиту й відстеження
змін.
Таблиця Exam містить інформацію про всі екзамени, доступні в системі.
Кожний запис описує окремий тест і включає назву екзамену, кількість запитань,
тривалість проходження, дату початку доступності, дату завершення та
унікальний ідентифікатор екзамену examId. Саме поле examId використовується
для зв’язування екзамену з іншими сутностями системи.
Наявність окремого поля examId, яке є унікальним, дозволяє не залежати
безпосередньо від внутрішнього ідентифікатора MongoDB _id при побудові
зв’язків між колекціями. Це спрощує обробку даних у клієнтській та серверній
частинах системи.
Таблиця Question призначена для збереження запитань, які належать до
певного екзамену. Кожен запис містить текст запитання, масив варіантів
відповідей та посилання на екзамен через поле examId. Таким чином реалізується
зв’язок між екзаменом і його запитаннями.
Особливістю цієї таблиці є вкладена структура варіантів відповідей. Кожне
запитання містить масив об’єктів options, де для кожного варіанта зберігається
текст відповіді та ознака правильності. Такий підхід є доцільним, оскільки
варіанти відповідей логічно належать конкретному запитанню і не
використовуються окремо поза його межами.
Між таблицями Exam і Question існує зв’язок типу один-до-багатьох,
оскільки один екзамен може містити багато запитань, але кожне запитання
64
ЧДТУ.262245 007 ПЗ
належить лише одному екзамену.
Таблиця TestResult використовується для збереження результатів
проходження екзаменів користувачами. Один запис у цій таблиці відповідає
одному завершеному проходженню тесту конкретним користувачем. У записі
зберігається ідентифікатор екзамену, ім’я користувача, електронна адреса,
кількість набраних балів, загальна кількість запитань, відсоток правильних
відповідей, а також масив відповідей користувача.
Вкладений масив answers містить інформацію про кожну відповідь, надану
користувачем під час проходження тесту. Для кожного елемента цього масиву
зберігається ідентифікатор запитання, ідентифікатор обраного варіанта відповіді
та ознака правильності. Така структура дозволяє не лише визначати підсумковий
результат, а й виконувати детальніший аналіз проходження тестування.
Між таблицями User і TestResult існує зв’язок типу один-до-багатьох,
оскільки один користувач може пройти багато екзаменів, а кожен результат
належить одному користувачу. Аналогічно між таблицями Exam і TestResult
також реалізується зв’язок один-до-багатьох, оскільки один екзамен може мати
багато результатів проходження.
Таблиця CheatingLog призначена для збереження агрегованої інформації
про порушення, зафіксовані під час проходження тестування. У ній містяться
числові показники різних типів підозрілої поведінки, зокрема відсутність обличчя
в кадрі, наявність кількох осіб, повороти голови, нахили голови вниз або вгору,
виявлення мобільного телефону та сторонніх предметів. Також зберігаються
examId, електронна адреса та ім’я користувача.
Ця таблиця використовується для аналізу доброчесності проходження
тестування. Один запис зазвичай відповідає одному користувачу в межах одного
екзамену, хоча логічно система допускає наявність кількох журналів для одного
користувача за різні сесії або різні екзамени.
Між таблицями User і CheatingLog реалізується зв’язок один-до-багатьох,
оскільки один користувач може мати кілька записів журналу порушень.
Аналогічно між таблицями Exam і CheatingLog також існує зв’язок один-до-
65
ЧДТУ.262245 007 ПЗ
багатьох.
Таким чином, центральними сутностями бази даних є користувач і екзамен.
Користувач взаємодіє з екзаменами через результати тестування та журнали
порушень. Екзамен, у свою чергу, пов’язаний із запитаннями, а запитання містять
вкладені варіанти відповідей. Результати тестування зберігають фактичні
відповіді користувача, що дозволяє аналізувати як підсумкові оцінки, так і процес
проходження тесту. Журнал порушень накопичує інформацію, що характеризує
поведінку користувача під час виконання екзамену.
Така структура бази даних є достатньо гнучкою для подальшого
розширення функціональності системи. За потреби вона може бути доповнена
новими сутностями, наприклад окремими таблицями для сесій тестування,
журналів подій або історії дій адміністратора.
3.1.5. Розробка інтерфейсу користувача
Розробка інтерфейсу користувача є важливим етапом створення
програмного забезпечення, оскільки саме через інтерфейс забезпечується
взаємодія користувача із системою. Від якості побудови інтерфейсу залежать
зручність використання програмного продукту, швидкість виконання основних
операцій, доступність функціональних можливостей системи та загальна
ефективність роботи користувачів.
У межах розробки автоматизованої системи онлайн-прокторингу інтерфейс
користувача реалізовано у вигляді веб-застосунку. Такий підхід забезпечує
доступ до системи через стандартний веб-браузер без необхідності встановлення
додаткового програмного забезпечення на пристрій користувача. Це є особливо
важливим для систем дистанційного тестування, оскільки користувачі можуть
працювати з різних пристроїв і з різних місць, маючи лише доступ до мережі
Інтернет.
Інтерфейс системи розроблено з урахуванням принципів простоти,
логічності, функціональної завершеності та зручності навігації. Основна увага
приділялася тому, щоб користувач міг швидко орієнтуватися у структурі системи,
легко виконувати необхідні дії та отримувати зрозумілий зворотний зв’язок у
66
ЧДТУ.262245 007 ПЗ
відповідь на свої запити. Важливим аспектом стала мінімізація кількості зайвих
дій, необхідних для виконання основних операцій.
Інтерфейс користувача побудований з урахуванням ролей, передбачених у
системі. Для студента реалізовано засоби входу до системи, перегляду доступних
екзаменів, запуску тестування, надання відповідей на запитання та перегляду
отриманих результатів. Для адміністратора передбачено можливості керування
екзаменами, додавання та редагування запитань, перегляду результатів
тестування та аналізу журналів порушень. Такий підхід забезпечує розмежування
доступу до функціональних можливостей системи та підвищує зручність її
використання.
Початковою точкою взаємодії користувача із системою є сторінка
авторизації. На ній розміщено поля для введення електронної адреси та пароля, а
також елементи керування для входу до системи або переходу до реєстрації.
Сторінка має просту структуру та забезпечує зручне введення облікових даних. У
разі помилкового введення даних система відображає відповідне повідомлення,
що сприяє кращій взаємодії з користувачем.
Після успішної авторизації користувач потрапляє до основного інтерфейсу
системи. Для студента цей інтерфейс містить перелік доступних екзаменів із
короткою інформацією про кожен з них, зокрема назву, тривалість і часові межі
доступності. Такий спосіб подання інформації дозволяє користувачу швидко
обрати потрібний екзамен і перейти до його проходження.
Інтерфейс проходження тестування розроблено з урахуванням необхідності
зосередження уваги користувача на основному завданні. На сторінці
відображаються запитання, варіанти відповідей, елементи навігації між
завданнями та засоби завершення тестування. Під час проходження екзамену
інтерфейс не повинен містити надлишкових елементів, які можуть відволікати
користувача. Одночасно він має забезпечувати зрозуміле відображення
поточного стану тестування, наприклад кількості виконаних запитань або часу,
що залишився до завершення екзамену.
Особливе місце в розробці інтерфейсу посідає інтеграція підсистеми
67
ЧДТУ.262245 007 ПЗ
онлайн-прокторингу. Користувачеві має бути зрозуміло, що під час проходження
тестування здійснюється моніторинг його поведінки. Для цього в інтерфейсі
можуть використовуватися відповідні повідомлення, індикатори активності
камери або інші елементи, які інформують про роботу підсистеми прокторингу.
При цьому важливо забезпечити баланс між інформативністю та ненав’язливістю
таких елементів.
Після завершення тестування користувач отримує доступ до сторінки
результатів, де відображається підсумкова інформація про проходження
екзамену. Інтерфейс результатів повинен бути зрозумілим, містити основні
показники успішності та забезпечувати можливість швидкого ознайомлення з
підсумками тестування. У разі необхідності система може відображати
детальнішу інформацію щодо правильності відповідей або загальної статистики
проходження.
Для адміністратора реалізовано окремий інтерфейс керування системою.
Він включає сторінки створення та редагування екзаменів, введення запитань і
варіантів відповідей, перегляду результатів студентів та аналізу журналів
порушень. При проєктуванні адміністративної частини особливу увагу приділено
зручності введення та редагування даних, оскільки саме ці дії є ключовими для
налаштування системи та забезпечення її працездатності.
Важливим принципом розробки інтерфейсу є адаптивність. Оскільки
система повинна працювати на різних пристроях, інтерфейс має коректно
відображатися на екранах різних розмірів. Це особливо актуально для веб-
застосунків, які можуть використовуватися як на персональних комп’ютерах, так
і на ноутбуках чи планшетах.
Таким чином, інтерфейс користувача автоматизованої системи онлайн-
прокторингу розроблено з урахуванням особливостей предметної області, ролей
користувачів та функціональних вимог до системи. Він забезпечує зручну та
зрозумілу взаємодію із програмним забезпеченням, підтримує основні сценарії
роботи користувачів та сприяє ефективному використанню системи в умовах
дистанційного контролю знань.
68
ЧДТУ.262245 007 ПЗ
На рисунках 3.4 – 3.9 висвітлено розроблений інтерфейс автоматизованої
системи прокторингу.
Рисунок 3.4 – Сторінка реєстрації реєстрації
Рисунок 3.5 – Сторінка авторизації
69
ЧДТУ.262245 007 ПЗ
Рисунок 3.6 – Головна сторінка студента
Рисунок 3.7 – Головна сторінка викладача
70
ЧДТУ.262245 007 ПЗ
Рисунок 3.8 – Журнал з результатами прокторингу
Рисунок 3.9 – Сторінка створення іспиту
71
ЧДТУ.262245 007 ПЗ
3.1.6. Опис розробки програмних компонентів
Розробка програмних компонентів є завершальним етапом проєктування
рограммного забезпечення, на якому здійснюється реалізація визначеної
архітектури системи та функціональних можливостей. У межах автоматизованої
системи онлайн-прокторингу програмні компоненти реалізовано відповідно до
клієнт-серверної моделі, що передбачає поділ системи на клієнтську (frontend) та
серверну (backend) частини.
Кожен програмний компонент виконує визначену функцію та взаємодіє з
іншими компонентами через чітко визначені інтерфейси. Такий підхід забезпечує
модульність системи, спрощує її розробку, тестування та подальший супровід.
Серверна частина системи реалізує основну бізнес-логіку, забезпечує
обробку запитів від клієнта та взаємодію з базою даних. Основними
компонентами серверної частини є моделі даних, контролери, маршрути та
проміжне програмне забезпечення.
Моделі даних визначають структуру інформації, що зберігається в базі
даних. Для кожної сутності предметної області створено відповідну модель,
зокрема для користувачів, екзаменів, запитань, результатів тестування та
журналів порушень. Моделі описують атрибути сутностей, їх рогр даних, а
також обмеження, що накладаються на ці дані.
Контролери реалізують логіку обробки запитів. Вони отримують дані від
клієнтської частини, виконують необхідні операції, звертаються до моделей для
рограмм базою даних та формують відповідь, яка повертається клієнту.
Наприклад, контролер автентифікації забезпечує перевірку облікових даних
користувача, контролер екзаменів відповідає за створення та отримання
екзаменів, а контролер результатів — за обчислення та збереження результатів
тестування.
Маршрути визначають точки входу до серверної частини системи. Вони
пов’язують HTTP-запити з відповідними методами контролерів, що забезпечує
чітку організацію API. Кожен маршрут відповідає за виконання конкретної
72
ЧДТУ.262245 007 ПЗ
операції, наприклад отримання списку екзаменів або збереження результатів
тестування.
Проміжне програмне забезпечення (middleware) використовується для
реалізації додаткових функцій, таких як автентифікація користувачів, перевірка
прав доступу та обробка помилок. Воно виконується до або після основної
обробки запиту та забезпечує підвищення безпеки й надійності системи.
Окремим компонентом серверної частини є модуль обробки подій
прокторингу. Він приймає дані від клієнтської частини, аналізує їх та зберігає
інформацію про виявлені порушення у відповідному журналі. Це дозволяє
здійснювати контроль доброчесності проходження тестування.
Клієнтська частина системи реалізує інтерфейс користувача та забезпечує
взаємодію з серверною частиною. Вона побудована за компонентним підходом,
що дозволяє розділити інтерфейс на окремі незалежні елементи.
Основними компонентами клієнтської частини є сторінки, компоненти
інтерфейсу та сервіси. Сторінки відповідають за відображення основних
функціональних розділів системи, таких як авторизація, список екзаменів,
проходження тестування, перегляд результатів та адміністративна панель.
Компоненти інтерфейсу є повторно використовуваними елементами, які
застосовуються у різних частинах системи. До них належать елементи навігації,
блоки відображення запитань, таблиці результатів та інші інтерфейсні елементи.
Використання компонентного підходу дозволяє підвищити зручність розробки та
забезпечити узгодженість інтерфейсу.
Сервіси клієнтської частини відповідають за взаємодію з сервером. Вони
формують HTTP-запити до API, обробляють отримані відповіді та передають дані
у відповідні компоненти для відображення. Такий підхід дозволяє відокремити
логіку рограмм даними від логіки відображення інтерфейсу.
Особливе місце серед компонентів клієнтської частини займає модуль
онлайн-прокторингу. Він забезпечує отримання даних із веб-камери користувача,
їх первинну обробку та передачу на сервер. Цей компонент працює рограммног
73
ЧДТУ.262245 007 ПЗ
з основним рограммн тестування та забезпечує моніторинг поведінки
користувача в режимі реального часу.
Взаємодія між клієнтською та серверною частинами здійснюється через
REST API, що базується на протоколі HTTP. Клієнтська частина ініціює запити
до серверу, а сервер обробляє їх і повертає результати. Такий підхід забезпечує
незалежність компонентів та дозволяє масштабувати систему.
Усі програмні компоненти системи взаємодіють між собою у межах
визначеної архітектури, що забезпечує узгоджене функціонування системи в
цілому. Кожен компонент виконує свою функцію, а їх взаємодія дозволяє
реалізувати всі необхідні можливості автоматизованої системи онлайн-
прокторингу.
Таким чином, розробка програмних компонентів забезпечує реалізацію
функціональних вимог системи, визначених на попередніх етапах проєктування,
та створює основу для ефективної роботи рограммного забезпечення.
3.2. Тестування системи
Тестування програмного забезпечення є важливим етапом розробки, який
спрямований на перевірку відповідності системи встановленим вимогам,
виявлення помилок та забезпечення стабільної роботи програмного продукту. У
межах розробки автоматизованої системи онлайн-прокторингу тестування
проводилося з метою перевірки коректності реалізації функціональних
можливостей, надійності обробки даних та стабільності роботи системи в різних
умовах.
Процес тестування включає кілька рівнів, серед яких важливе місце займає
модульне тестування, що дозволяє перевірити окремі компоненти системи
незалежно один від одного. Це дає змогу своєчасно виявляти помилки на ранніх
етапах розробки та спрощує процес їх усунення.
3.2.1. Модульне тестування
Модульне тестування передбачає перевірку окремих програмних
компонентів (модулів) системи з метою підтвердження їх коректної роботи [20].
74
ЧДТУ.262245 007 ПЗ
У межах даної роботи модульне тестування застосовувалося для перевірки
серверної частини системи, зокрема контролерів, функцій обробки даних та
логіки обчислення результатів тестування.
Основною метою модульного тестування є перевірка того, що кожен
окремий модуль системи виконує свої функції відповідно до заданих вимог. Це
дозволяє локалізувати помилки та уникнути їх поширення на інші частини
системи.
Для реалізації модульного тестування використовувалися сучасні засоби
тестування JavaScript-застосунків, зокрема бібліотека Jest. Вона дозволяє
створювати автоматизовані тести, виконувати їх та отримувати результати у
зручному вигляді.
У межах тестування перевірялися такі основні функції:
− коректність автентифікації користувача;
− створення та отримання екзаменів;
− обчислення результатів тестування;
− збереження даних у базі даних;
− обробка подій прокторингу.
Нижче наведено приклад модульного тесту для перевірки функції
обчислення результату тестування.
const calculateResult = (answers) => {
let correct = 0;
answers.forEach(a => {
if (a.isCorrect) correct++;
});
const total = answers.length;
const percentage = (correct / total) * 100;
return { correct, total, percentage };
};
test("Коректне обчислення результату тесту", () => {
75
ЧДТУ.262245 007 ПЗ
const answers = [
{ isCorrect: true },
{ isCorrect: false },
{ isCorrect: true },
{ isCorrect: true }
];
const result = calculateResult(answers);
expect(result.correct).toBe(3);
expect(result.total).toBe(4);
expect(result.percentage).toBe(75);
});
Даний тест перевіряє правильність підрахунку кількості правильних
відповідей, загальної кількості запитань та відсотка правильних відповідей.
Результати проведеного моудльного тестування наведено у таблиці 3.1.
Таблиця 3.1
Резльтати модульного тестування
№ Назва модуля Опис тесту Очікуваний Фактичний Статус
результат результат
1 Модуль Вхід з Успішна Успішна Пройдено
автентифікації коректними авторизація авторизація
даними
2 Модуль Вхід з Помилка Помилка Пройдено
автентифікації неправильним авторизації відображена
паролем
76
ЧДТУ.262245 007 ПЗ
Продовження таблиці 3.1
3 Модуль Створення нового Екзамен Екзамен Пройдено
екзаменів екзамену створено створено
4 Модуль Отримання Повертається Дані Пройдено
тестування списку запитань список отримано
5 Модуль Обчислення Коректний Результат Пройдено
результатів результату результат правильний
6 Модуль Збереження Дані Дані Пройдено
результатів результату збережено збережено
7 Модуль Фіксація Запис у Запис Пройдено
прокторингу порушення журнал створено
8 Модуль бази Збереження Дані Дані Пройдено
даних користувача збережено збережено
3.2.2. Інтеграційне тестування
Інтеграційне тестування є важливим етапом перевірки програмного
забезпечення, який спрямований на оцінку коректності взаємодії між окремими
модулями системи [21]. На відміну від модульного тестування, де перевіряються
окремі компоненти ізольовано, інтеграційне тестування дозволяє виявити
помилки, що виникають під час обміну даними між різними частинами системи.
У межах автоматизованої системи онлайн-прокторингу інтеграційне
тестування проводилося для перевірки взаємодії між клієнтською та серверною
частинами, а також між окремими модулями серверної частини. Основна увага
приділялася перевірці правильності обробки запитів, передачі даних через API та
взаємодії з базою даних.
Одним із ключових аспектів інтеграційного тестування є перевірка
коректності роботи REST API. У процесі тестування здійснювалася перевірка
запитів на авторизацію, отримання списку екзаменів, завантаження запитань,
збереження результатів тестування та передачі даних прокторингу. Особливу
77
ЧДТУ.262245 007 ПЗ
увагу було приділено перевірці обробки помилкових ситуацій, зокрема
некоректних запитів, відсутності необхідних даних або порушення прав доступу.
Під час інтеграційного тестування також перевірялася взаємодія між
модулем тестування та модулем обробки результатів. Було підтверджено, що
після завершення тестування всі відповіді користувача коректно передаються на
сервер, обробляються та зберігаються в базі даних, а результати повертаються
клієнтській частині для відображення.
Окремо було протестовано взаємодію підсистеми онлайн-прокторингу з
серверною частиною. У процесі тестування перевірялася передача даних про
поведінку користувача, їх обробка та збереження у журналі порушень. Було
встановлено, що система коректно фіксує події та забезпечує їх подальший
аналіз.
Інтеграційне тестування також охоплювало перевірку взаємодії з базою
даних. Було перевірено коректність операцій читання та запису даних,
узгодженість інформації між різними колекціями та відсутність втрати даних під
час виконання операцій.
Таким чином, інтеграційне тестування дозволило перевірити цілісність
системи, правильність взаємодії між її компонентами та відповідність
реалізованого програмного забезпечення встановленим вимогам.
Результати проведеного інтеграційного тестування наведено у таблиці 3.2.
Таблиця 3.2
Результати інтеграційного тестування
№ Сценарій Опис перевірки Очікуваний Фактичний Статус
тестування результат результат
1 Авторизація Взаємодія Frontend → Успішна Авторизація Пройдено
через API Backend → Database авторизація виконана
78
ЧДТУ.262245 007 ПЗ
Продовження таблиці 3.2
2 Отримання Запит списку екзаменів Повертається Дані Пройдено
екзаменів через API список отримано
екзаменів
3 Отримання Завантаження запитань Повертається Дані Пройдено
запитань для обраного екзамену список отримано
запитань
4 Проходженн Передача відповідей Дані передані Дані Пройдено
я тесту користувача без помилок передано
5 Обчислення Взаємодія модулів Коректний Результат Пройдено
результату тестування і результатів результат правильний
6 Збереження Запис результату у базу Дані Дані Пройдено
результату даних збережено збережено
7 Прокторинг Передача даних про Дані передані Дані Пройдено
порушення та оброблені збережено
8 Журнал Збереження інформації Запис Запис Пройдено
порушень про порушення створено створено
9 Обробка Невалідний API-запит Повертається Помилка Пройдено
помилкового повідомлення оброблена
запиту про помилку
3.2.3. Системне тестування
Системне тестування є етапом перевірки програмного забезпечення, який
спрямований на оцінку роботи системи в цілому. На цьому етапі система
розглядається як єдиний комплекс, що включає всі програмні компоненти,
взаємодію між ними, а також взаємодію з користувачем. Основною метою
79
ЧДТУ.262245 007 ПЗ
системного тестування є перевірка відповідності розробленого програмного
забезпечення функціональним і нефункціональним вимогам [22].
У межах автоматизованої системи онлайн-прокторингу системне
тестування проводилося шляхом виконання повних сценаріїв роботи
користувачів. Перевірялися як функціональні можливості системи, так і її
поведінка в реальних умовах використання. Особлива увага приділялася
перевірці стабільності роботи, зручності інтерфейсу та коректності обробки
даних.
Одним із ключових сценаріїв системного тестування є повний цикл роботи
студента: реєстрація або вхід до системи, вибір екзамену, проходження
тестування, отримання результатів та завершення сесії. У процесі тестування
було встановлено, що всі етапи цього сценарію виконуються коректно, а система
забезпечує безперервну взаємодію користувача з програмним забезпеченням.
Також було перевірено сценарії роботи адміністратора, які включають
створення екзаменів, додавання запитань, редагування даних, перегляд
результатів та аналіз журналів порушень. Результати тестування показали, що
адміністративна частина системи функціонує стабільно та забезпечує повний
контроль над процесом тестування.
Окремо було проведено перевірку роботи підсистеми онлайн-прокторингу.
У процесі тестування система коректно фіксувала події, пов’язані з поведінкою
користувача, та зберігала їх у журналі порушень. Це підтверджує ефективність
реалізації механізмів контролю доброчесності.
У межах нефункціонального тестування було оцінено продуктивність
системи, її стабільність та зручність використання. Було встановлено, що система
забезпечує швидку обробку запитів, коректно працює при одночасній роботі
кількох користувачів та має інтуїтивно зрозумілий інтерфейс.
Таким чином, системне тестування дозволило підтвердити, що розроблена
автоматизована система онлайн-прокторингу відповідає поставленим вимогам та
готова до використання в реальних умовах.
Результати проведеного системного тестування наведено у таблиці 3.3.
80
ЧДТУ.262245 007 ПЗ
Таблиця 3.3
Результати системного тестування
№ Сценарій Опис перевірки Очікуваний Фактичний Статус
тестування результат результат
1 Реєстрація Створення Користувач Реєстрація Пройдено
користувача нового зареєстрований виконана
облікового
запису
2 Авторизація Вхід у систему Успішний вхід Вхід виконано Пройдено
3 Перегляд Отримання Відображення Дані відображено Пройдено
екзаменів списку списку
екзаменів
4 Проходження Повний цикл Тест виконано Тест завершено Пройдено
тестування виконання тесту без помилок
5 Отримання Відображення Коректний Результат Пройдено
результатів результату після результат відображено
тесту
6 Робота Фіксація Події Події записано Пройдено
прокторингу підозрілих дій зафіксовано
7 Робота Створення та Дані змінено Дані збережено Пройдено
адміністратора редагування
екзамену
8 Перегляд Отримання Відображення Дані відображено Пройдено
журналу даних про журналу
порушень порушення
3.2.4. Приймальне тестування
Інтеграційне тестування є важливим етапом перевірки програмного
забезпечення, який спрямований на оцінку коректності взаємодії між окремими
81
ЧДТУ.262245 007 ПЗ
модулями системи. На відміну від модульного тестування, де перевіряються
окремі компоненти ізольовано, інтеграційне тестування дозволяє виявити
помилки, що виникають під час обміну даними між різними частинами системи
[23].
У межах автоматизованої системи онлайн-прокторингу інтеграційне
тестування проводилося для перевірки взаємодії між клієнтською та серверною
частинами, а також між окремими модулями серверної частини. Основна увага
приділялася перевірці правильності обробки запитів, передачі даних через API та
взаємодії з базою даних.
Одним із ключових аспектів інтеграційного тестування є перевірка
коректності роботи REST API. У процесі тестування здійснювалася перевірка
запитів на авторизацію, отримання списку екзаменів, завантаження запитань,
збереження результатів тестування та передачі даних прокторингу. Особливу
увагу було приділено перевірці обробки помилкових ситуацій, зокрема
некоректних запитів, відсутності необхідних даних або порушення прав доступу.
Під час інтеграційного тестування також перевірялася взаємодія між
модулем тестування та модулем обробки результатів. Було підтверджено, що
після завершення тестування всі відповіді користувача коректно передаються на
сервер, обробляються та зберігаються в базі даних, а результати повертаються
клієнтській частині для відображення.
Окремо було протестовано взаємодію підсистеми онлайн-прокторингу з
серверною частиною. У процесі тестування перевірялася передача даних про
поведінку користувача, їх обробка та збереження у журналі порушень. Було
встановлено, що система коректно фіксує події та забезпечує їх подальший
аналіз.
Інтеграційне тестування також охоплювало перевірку взаємодії з базою
даних. Було перевірено коректність операцій читання та запису даних,
узгодженість інформації між різними колекціями та відсутність втрати даних під
час виконання операцій.
Таким чином, інтеграційне тестування дозволило перевірити цілісність
82
ЧДТУ.262245 007 ПЗ
системи, правильність взаємодії між її компонентами та відповідність
реалізованого програмного забезпечення встановленим вимогам.
Результати проведеного інтеграційного тестування наведено у таблиці 3.4.
Таблиці 3.4
Результати інтеграційного тестування
№ Сценарій Опис перевірки Очікуваний Фактичний Статус
тестування результат результат
1 Авторизація Взаємодія Frontend → Успішна Авторизація Пройдено
через API Backend → Database авторизація виконана
2 Отримання Запит списку екзаменів Повертається Дані Пройдено
екзаменів через API список отримано
екзаменів
3 Отримання Завантаження запитань Повертається Дані Пройдено
запитань для обраного екзамену список отримано
запитань
4 Проходження Передача відповідей Дані передані Дані Пройдено
тесту користувача без помилок передано
5 Обчислення Взаємодія модулів Коректний Результат Пройдено
результату тестування результат правильний
6 Збереження Запис результату у базу Дані Дані Пройдено
результату даних збережено збережено
7 Прокторинг Передача даних про Дані передані Дані Пройдено
порушення та оброблені збережено
8 Журнал Збереження інформації Запис Запис Пройдено
порушень про порушення створено створено
3.3. Приклади впровадженого програмного комплексу
83
ЧДТУ.262245 007 ПЗ
Розроблений програмний комплекс автоматизованої системи онлайн-
прокторингу було впроваджено у вигляді веб-застосунку, що забезпечує
можливість організації дистанційного тестування з контролем поведінки
користувача. У даному підрозділі наведено приклади використання системи, які
демонструють її основні функціональні можливості та підтверджують
ефективність реалізованих рішень.
Першим прикладом використання є процес реєстрації та авторизації
користувача. Користувач отримує доступ до системи через веб-інтерфейс, де
вводить свої облікові дані. Після успішної перевірки інформації система надає
доступ до функціональних можливостей відповідно до ролі користувача. Це
забезпечує контроль доступу та захист персональних даних.
Наступним прикладом є створення екзамену адміністратором.
Адміністратор через інтерфейс системи вводить основні параметри тесту, такі як
назва, тривалість, дата проведення, а також додає запитання та варіанти
відповідей. Усі введені дані передаються на сервер і зберігаються у базі даних,
що дозволяє забезпечити подальше використання екзамену.
Одним із ключових прикладів є процес проходження тестування студентом.
Користувач обирає доступний екзамен, після чого система відображає запитання
та варіанти відповідей. У процесі виконання тесту відповіді користувача
зберігаються, а після завершення тестування система автоматично обчислює
результат та відображає його користувачу. Це дозволяє забезпечити швидке та
об’єктивне оцінювання знань.
Важливою особливістю впровадженого програмного комплексу є робота
підсистеми онлайн-прокторингу. Під час проходження тестування система
здійснює моніторинг поведінки користувача за допомогою веб-камери. У разі
виявлення підозрілих дій, таких як відсутність обличчя у кадрі або наявність
сторонніх осіб, відповідна інформація передається на сервер і зберігається у
журналі порушень. Це дозволяє підвищити рівень достовірності результатів
тестування.
Ще одним прикладом використання системи є перегляд результатів
84
ЧДТУ.262245 007 ПЗ
тестування. Користувач має можливість ознайомитися зі своїми результатами
після завершення екзамену, а адміністратор — переглянути результати всіх
користувачів та проаналізувати їх. Така функціональність забезпечує прозорість
процесу оцінювання.
Крім того, адміністратор може переглядати журнал порушень, який містить
інформацію про всі зафіксовані підозрілі дії під час тестування. Це дозволяє
оцінити доброчесність проходження екзамену та, у разі необхідності, прийняти
відповідні рішення.
Таким чином, наведені приклади впровадження програмного комплексу
демонструють його здатність забезпечувати повний цикл дистанційного
тестування — від створення екзамену до отримання результатів і контролю
поведінки користувача. Реалізована система є ефективним інструментом для
організації онлайн-оцінювання знань та може бути використана у навчальних
закладах або інших організаціях, що потребують проведення дистанційного
контролю знань.
85
ЧДТУ.262245 007 ПЗ
Висновки до розділу 3
Було розглянуто процес реалізації автоматизованої системи онлайн-
прокторингу, а також проведено її комплексне тестування та аналіз результатів
впровадження. Обґрунтовано вибір сучасних засобів розробки, які забезпечують
ефективну реалізацію клієнт-серверної архітектури та відповідають вимогам до
продуктивності, масштабованості та зручності використання.
У ході роботи було описано структурну та логічну організацію
програмного забезпечення, визначено основні функціональні компоненти
системи та принципи їх взаємодії. Особливу увагу приділено розробці бази
даних, яка забезпечує збереження інформації про користувачів, екзамени,
результати тестування та журнали порушень. Запропонована структура бази
даних є гнучкою та придатною до подальшого розширення.
Розроблено інтерфейс користувача, який забезпечує зручну взаємодію з
системою та підтримує основні сценарії роботи як для студентів, так і для
адміністраторів. Описано програмні компоненти клієнтської та серверної частин,
що реалізують функціональні можливості системи та забезпечують її цілісну
роботу.
У межах розділу проведено тестування програмного забезпечення на різних
рівнях. Модульне тестування дозволило перевірити коректність роботи окремих
компонентів, інтеграційне тестування — оцінити взаємодію між модулями, а
системне тестування — підтвердити працездатність системи в цілому.
Приймальне тестування продемонструвало відповідність системи вимогам
замовника та її готовність до практичного використання.
Наведені приклади впровадження програмного комплексу підтверджують
ефективність розробленої системи та її здатність забезпечувати повний цикл
дистанційного тестування з контролем доброчесності. Система успішно реалізує
функції створення екзаменів, проходження тестування, обчислення результатів та
моніторингу поведінки користувачів.
Таким чином, у результаті виконання третього розділу було реалізовано
86
ЧДТУ.262245 007 ПЗ
програмне забезпечення автоматизованої системи онлайн-прокторингу,
підтверджено його працездатність та відповідність встановленим вимогам.
Отримані результати свідчать про доцільність використання розробленого
програмного комплексу для організації дистанційного контролю знань.
87
ЧДТУ.262245 007 ПЗ
ВИСНОВКИ
У результаті виконання кваліфікаційної роботи було розроблено програмне
забезпечення автоматизованої системи онлайн-прокторингу, призначене для
організації дистанційного тестування з контролем поведінки користувачів.
Актуальність роботи зумовлена зростанням потреби у проведенні онлайн-
оцінювання знань та забезпеченні академічної доброчесності в умовах
дистанційного навчання.
У ході виконання роботи було проведено аналіз предметної області,
визначено основні проблеми, що виникають під час дистанційного тестування, та
досліджено існуючі підходи до їх вирішення. На основі цього було сформовано
вимоги до програмного забезпечення та визначено ключові функціональні
можливості системи.
У процесі проєктування системи застосовано уніфіковану мову
моделювання UML, що дозволило формалізувати структуру та поведінку
програмного забезпечення. Побудовано діаграми класів, пакетів, компонентів,
розгортання, діяльності, послідовності, комунікації та скінченного автомату, що
забезпечило комплексне представлення архітектури системи та її
функціонування.
На етапі реалізації було обґрунтовано вибір технологічного стеку, який
включає сучасні засоби розробки веб-застосунків. Розроблено структурну та
логічну схеми системи, спроєктовано базу даних, реалізовано інтерфейс
користувача та програмні компоненти клієнтської і серверної частин. Особливу
увагу приділено реалізації підсистеми онлайн-прокторингу, що забезпечує
моніторинг поведінки користувачів під час тестування.
Проведено комплексне тестування програмного забезпечення, яке включає
модульне, інтеграційне, системне та приймальне тестування. Результати
тестування підтвердили коректність роботи системи, узгодженість взаємодії її
компонентів та відповідність встановленим вимогам.
88
ЧДТУ.262245 007 ПЗ
Розроблений програмний комплекс забезпечує повний цикл дистанційного
тестування: від створення екзаменів до отримання результатів і контролю
доброчесності. Система є зручною у використанні, має зрозумілий інтерфейс,
забезпечує надійне збереження даних та може бути застосована у навчальних
закладах або інших організаціях, що потребують проведення онлайн-оцінювання
знань.
Таким чином, поставлену мету роботи досягнуто, а всі визначені завдання
виконано. Отримані результати можуть бути використані для подальшого
розвитку системи, зокрема розширення функціональності, вдосконалення
алгоритмів прокторингу та інтеграції з іншими освітніми платформами.
89
ЧДТУ.262245 007 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Proctorio - [Електронний ресурс] - Режим доступу: https://
https://proctorio.com/
2 Examity - [Електронний ресурс] - Режим доступу: https://prod.examity.com/
3 Respondus - [Електронний ресурс] - Режим доступу:
https://web.respondus.com/
4 Модель предметної області - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Модель_предметної_області
5 UML - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Unified_Modeling_Language
6 Методичні рекомендації до підготовки кваліфікаційної роботи бакалавра
для здобувачів вищої освіти зі спеціальності 121 «Інженерія програмного
забезпечення» усіх форм навчання [Текст] /Укл.: Голуб С.В., Заспа Г.О.,
Півень О.Б. Катаєва Є.Ю., Салапатов В.І., Метелап В.В., Олексюк В.В.; М-
во освіти і науки України.
7 Аналіз вимог - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Аналіз_вимог
8 Діаграма прецендентів - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Діаграма_прецедентів
9 Діаграма класів - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Діаграма_класів
10 Діаграма пакетів – [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Діаграма_пакетів
11 Діаграма компонентів - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Діаграма_компонентів
12 Діаграма розгортання - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Діаграма_розгортання
13 Діаграма діяльності - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Діаграма_діяльності
90
ЧДТУ.262245 007 ПЗ
14 Діаграма послідовності (UML) - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Діаграма_послідовності
15 Діаграма станів (UML) - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Діаграма_станів_(UML)
16 Node.js Documentation - [Електронний ресурс] - Режим доступу:
https://nodejs.org/docs/latest/api/
17 Express.js - [Електронний ресурс] - Режим доступу:
https://expressjs.com/en/guide/
18 MongoDB Documentation - [Електронний ресурс] - Режим доступу:
https://www.mongodb.com/docs/
19 Структурна схема - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Структурна_схема
20 Модульне тестування - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Модульне_тестування
21 Інтеграційне тестування - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Інтеграційне_тестування
22 Системне тестування - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Системне_тестування
23 Приймальне тестування - [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/Приймальне_тестування
24 Sommerville I. Software Engineering. – 10th ed. – Boston: Pearson, 2016. – 816
p.
25 Pressman R. S., Maxim B. R. Software Engineering: A Practitioner’s Approach.
– 8th ed. – New York: McGraw-Hill, 2014. – 970 p.
26 Gamma E., Helm R., Johnson R., Vlissides J. Design Patterns: Elements of
Reusable Object-Oriented Software. – Boston: Addison-Wesley, 1994. – 395 p.
27 Fowler M. UML Distilled: A Brief Guide to the Standard Object Modeling
Language. – 3rd ed. – Boston: Addison-Wesley, 2004. – 208 p.
28 Atoum Y., Chen L., Liu A. X., Hsu S. D., Liu X. Automated Online Exam
Proctoring. – IEEE Transactions on Multimedia, 2017.
91
ЧДТУ.262245 007 ПЗ
29 D’Souza D. F., Wills A. C. Objects, Components, and Frameworks with UML:
The Catalysis Approach. – Addison-Wesley, 1999.
30 ISO/IEC 25010:2011. Systems and software engineering – Systems and software
Quality Requirements and Evaluation (SQuaRE).
92
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедри ПЗАС
проф. Голуб С. В.
___________________________
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ АВТОМАТИЗОВАНОЇ СИСТЕМИ
ОНЛАЙН-ПРОКТОРИНГУ
Специфікація
482.ЧДТУ.262245 007
Листів 1
Розробник ________________ Кравченко А.Р.
Керівник ________________ Немченко В.В.
Н. Контроль ________________ Півень О.Б.
Черкаси 2026
ЧДТУ.262245 007 2
Позначення Найменування Примітка
482.ЧДТУ.262245 12-01 Лістинг програми
482.ЧДТУ.262245 34-01 Інструкція користувача
482.ЧДТУ.262245 90-01 Графічні матеріали
94
ДОДАТОК Б
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ АВТОМАТИЗОВАНОЇ СИСТЕМИ
ОНЛАЙН-ПРОКТОРИНГУ
Лістинг програми
482.ЧДТУ.262245 12 01
Листів 50
Розробник ________________ Кравченко А.Р.
Черкаси 2026
482.ЧДТУ.262245 12 01 2
cheatingLogController.js
import asyncHandler from "express-async-handler";
import CheatingLog from "../models/cheatingLogModel.js";
// @desc Save cheating log data
// @route POST /api/cheatingLogs
// @access Private
const saveCheatingLog = asyncHandler(async (req, res) => {
const {
noFaceCount,
multipleFaceCount,
headTurnedCount,
headDownCount,
headUpCount,
cellPhoneCount,
prohibitedObjectCount,
examId,
username,
email,
} = req.body;
const cheatingLog = new CheatingLog({
noFaceCount,
multipleFaceCount,
headTurnedCount,
headDownCount,
headUpCount,
cellPhoneCount,
prohibitedObjectCount,
examId,
96
482.ЧДТУ.262245 12 01 3
username,
email,
});
const savedLog = await cheatingLog.save();
if (savedLog) {
res.status(201).json(savedLog);
} else {
res.status(400);
throw new Error("Invalid Cheating Log Data");
}
});
// @desc Get all cheating log data for a specific exam
// @route GET /api/cheatingLogs/:examId
// @access Private
const getCheatingLogsByExamId = asyncHandler(async (req, res) => {
const examId = req.params.examId;
const cheatingLogs = await CheatingLog.find({ examId });
res.status(200).json(cheatingLogs);
});
export { saveCheatingLog, getCheatingLogsByExamId };
cheatingLogModel.js
import mongoose from "mongoose";
// Define a schema for the cheating log
97
482.ЧДТУ.262245 12 01 4
const cheatingLogSchema = new mongoose.Schema(
{
noFaceCount: { type: Number, default: 0 },
multipleFaceCount: { type: Number, default: 0 },
headTurnedCount: { type: Number, default: 0 },
headDownCount: { type: Number, default: 0 },
headUpCount: { type: Number, default: 0 },
cellPhoneCount: { type: Number, default: 0 },
prohibitedObjectCount: { type: Number, default: 0 },
examId: { type: String, required: true },
email: { type: String, required: true },
username: { type: String, required: true },
},
{
timestamps: true,
}
);
// Create a model using the schema
const CheatingLog = mongoose.model("CheatingLog", cheatingLogSchema);
export default CheatingLog;
examController.js
import asyncHandler from "express-async-handler";
import Exam from "./../models/examModel.js";
const getExams = asyncHandler(async (req, res) => {
const exams = await Exam.find();
res.status(200).json(exams);
98
482.ЧДТУ.262245 12 01 5
});
const createExam = asyncHandler(async (req, res) => {
const { examName, totalQuestions, duration, liveDate, deadDate } = req.body;
const exam = new Exam({
examName,
totalQuestions,
duration,
liveDate: liveDate || null,
deadDate: deadDate || null,
});
const createdExam = await exam.save();
if (createdExam) {
res.status(201).json(createdExam);
} else {
res.status(400);
throw new Error("Invalid Exam Data");
}
});
export { getExams, createExam };
examModel.js
import mongoose from "mongoose";
import { v4 as uuidv4 } from "uuid";
const examSchema = mongoose.Schema(
99
482.ЧДТУ.262245 12 01 6
{
examName: {
type: String,
required: true,
},
totalQuestions: {
type: Number,
required: true,
},
duration: {
type: Number,
required: true,
},
liveDate: {
type: Date,
default: null,
},
deadDate: {
type: Date,
default: null,
},
examId: {
type: String,
default: uuidv4,
unique: true,
},
},
{
timestamps: true,
}
100
482.ЧДТУ.262245 12 01 7
);
const Exam = mongoose.model("Exam", examSchema);
export default Exam;
Exams.js
import React from 'react';
import { Grid, Alert, CircularProgress, Box } from '@mui/material';
import ExamCard from './ExamCard';
import { useGetExamsQuery } from 'src/slices/examApiSlice';
const Exams = () => {
const { data: userExams, isLoading, isError } = useGetExamsQuery();
if (isLoading) {
return (
<Box sx={{ display: 'flex', justifyContent: 'center', py: 6 }}>
<CircularProgress />
</Box>
);
}
if (isError) {
return <Alert severity="error">Не вдалося завантажити список
іспитів.</Alert>;
}
if (!userExams?.length) {
return <Alert severity="info">Наразі немає доступних іспитів.</Alert>;
101
482.ЧДТУ.262245 12 01 8
}
return (
<Grid container spacing={3}>
{userExams.map((exam) => (
<Grid item xs={12} sm={6} xl={4} key={exam._id}>
<ExamCard exam={exam} />
</Grid>
))}
</Grid>
);
};
export default Exams;
quesController.js
import asyncHandler from "express-async-handler";
import Question from "../models/quesModel.js";
const getQuestionsByExamId = asyncHandler(async (req, res) => {
const { examId } = req.params;
console.log("Question Exam id ", examId);
if (!examId) {
return res.status(400).json({ error: "examId is missing or invalid" });
}
const questions = await Question.find({ examId });
console.log("Question Exam ", questions);
102
482.ЧДТУ.262245 12 01 9
res.status(200).json(questions);
});
const createQuestion = asyncHandler(async (req, res) => {
const { question, options, examId } = req.body;
if (!examId) {
return res.status(400).json({ error: "examId is missing or invalid" });
}
const newQuestion = new Question({
question,
options,
examId,
});
const createdQuestion = await newQuestion.save();
if (createdQuestion) {
res.status(201).json(createdQuestion);
} else {
res.status(400);
throw new Error("Invalid Question Data");
}
});
export { getQuestionsByExamId, createQuestion };
quesModel.js
import mongoose from "mongoose";
103
482.ЧДТУ.262245 12 01 10
const questionSchema = mongoose.Schema(
{
question: {
type: String,
required: true,
},
options: [
{
optionText: {
type: String,
required: true,
},
isCorrect: {
type: Boolean,
required: true,
},
},
],
examId: {
type: String, // Use the same data type (String) as in the exam model
required: true, // You can make examId required if it's always present
},
},
{
timestamps: true,
}
);
const Question = mongoose.model("Question", questionSchema);
104
482.ЧДТУ.262245 12 01 11
export default Question;
testResultController.js
import asyncHandler from "express-async-handler";
import TestResult from "../models/testResultModel.js";
const saveTestResult = asyncHandler(async (req, res) => {
const { examId, username, email, score, totalQuestions, percentage, answers } =
req.body;
if (!examId || !username || !email) {
res.status(400);
throw new Error("Missing required test result data");
}
const testResult = new TestResult({
examId,
username,
email,
score,
totalQuestions,
percentage,
answers: Array.isArray(answers) ? answers : [],
});
const savedResult = await testResult.save();
if (savedResult) {
res.status(201).json(savedResult);
105
482.ЧДТУ.262245 12 01 12
} else {
res.status(400);
throw new Error("Invalid test result data");
}
});
const getTestResultsByExamId = asyncHandler(async (req, res) => {
const { examId } = req.params;
const testResults = await TestResult.find({ examId }).sort({ createdAt: -1 });
res.status(200).json(testResults);
});
const getMyTestResults = asyncHandler(async (req, res) => {
const testResults = await TestResult.find({ email: req.user.email }).sort({
createdAt: -1 });
res.status(200).json(testResults);
});
export { saveTestResult, getTestResultsByExamId, getMyTestResults };
testResultModel.js
import mongoose from "mongoose";
const testResultSchema = new mongoose.Schema(
{
examId: { type: String, required: true },
username: { type: String, required: true },
106
482.ЧДТУ.262245 12 01 13
email: { type: String, required: true },
score: { type: Number, required: true, default: 0 },
totalQuestions: { type: Number, required: true, default: 0 },
percentage: { type: Number, required: true, default: 0 },
answers: [
{
questionId: { type: String, required: true },
selectedOptionId: { type: String, default: null },
isCorrect: { type: Boolean, required: true, default: false },
},
],
},
{
timestamps: true,
}
);
const TestResult = mongoose.model("TestResult", testResultSchema);
export default TestResult;
userController.js
import asyncHandler from "express-async-handler";
import User from "./../models/userModel.js";
import generateToken from "../utils/generateToken.js";
const authUser = asyncHandler(async (req, res) => {
const { email, password } = req.body;
const user = await User.findOne({ email });
107
482.ЧДТУ.262245 12 01 14
if (user && (await user.matchPassword(password))) {
generateToken(res, user._id);
res.status(201).json({
_id: user._id,
name: user.name,
email: user.email,
role: user.role,
password_encrypted: user.password,
message: "User Successfully login with role: " + user.role,
});
} else {
res.status(401);
throw new Error("Invalid User email or password ");
}
});
const registerUser = asyncHandler(async (req, res) => {
const { name, email, password, role } = req.body;
const userExist = await User.findOne({ email });
if (userExist) {
res.status(400);
throw new Error("User Already Exists");
}
const user = await User.create({
name,
email,
108
482.ЧДТУ.262245 12 01 15
password,
role,
});
if (user) {
generateToken(res, user._id);
res.status(201).json({
_id: user._id,
name: user.name,
email: user.email,
role: user.role,
password_encrypted: user.password,
message: "User Successfully created with role: " + user.role,
});
} else {
res.status(400);
throw new Error("Invalid User Data");
}
});
const logoutUser = asyncHandler(async (req, res) => {
res.cookie("jwt", "", {
httpOnly: true,
expires: new Date(0),
});
res.status(200).json({ message: " User logout User" });
});
const getUserProfile = asyncHandler(async (req, res) => {
109
482.ЧДТУ.262245 12 01 16
const user = {
_id: req.user._id,
name: req.user.name,
email: req.user.email,
role: req.user.role,
};
res.status(200).json(user);
});
const updateUserProfile = asyncHandler(async (req, res) => {
const user = await User.findById(req.user._id);
if (user) {
user.name = req.body.name || user.name;
user.email = req.body.email || user.email;
user.role = req.body.role || user.role;
if (req.body.password) {
user.password = req.body.password;
}
const updatedUser = await user.save();
res.status(200).json({
_id: updatedUser._id,
name: updatedUser.name,
email: updatedUser.email,
role: updatedUser.role,
});
} else {
res.status(404);
110
482.ЧДТУ.262245 12 01 17
throw new Error("User Not Found");
}
});
export {
authUser,
registerUser,
logoutUser,
getUserProfile,
updateUserProfile,
};
111
ДОДАТОК В
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ АВТОМАТИЗОВАНОЇ СИСТЕМИ
ОНЛАЙН-ПРОКТОРИНГУ
Інструкція користувача
482.ЧДТУ 262245 34 01
Листів 8
Розробник ________________ Кравченко А.Р.
Черкаси 2026
482.ЧДТУ 262245 34 01 2
Інструкція користувача призначена для ознайомлення з функціональними
можливостями автоматизованої системи онлайн-прокторингу та порядком її
використання. Система реалізована у вигляді веб-застосунку, що забезпечує
доступ до основних функцій через браузер без необхідності встановлення
додаткового програмного забезпечення.
Робота з системою починається зі сторінки входу, яка зображена на
рисунку В.1.
Рисунок В.1 – Сторінка входу
Для авторизації користувач вводить електронну пошту та пароль, після
чого натискає кнопку входу. У разі успішної перевірки даних користувач отримує
доступ до функціоналу системи відповідно до своєї ролі. Якщо користувач не має
облікового запису, він може перейти до сторінки реєстрації.
Сторінка реєстрації представлена на рисунку В.2. Для створення нового
облікового запису користувач вводить ім’я, електронну пошту, пароль та
підтвердження пароля, а також обирає роль у системі. Після заповнення всіх
полів необхідно підтвердити створення акаунта. Після цього користувач може
виконати вхід до системи.
113
482.ЧДТУ 262245 34 01 3
Рисунок В.2 – Сторінка реєстрації
Після авторизації студент потрапляє до головної сторінки зі списком
доступних іспитів, яка показана на рисунку В.3. На цій сторінці відображається
перелік тестів із короткою інформацією про кожен із них. Користувач має
можливість обрати необхідний іспит та перейти до його проходження.
Рисунок В.3 – Головна сторінка
114
482.ЧДТУ 262245 34 01 4
Перед початком тестування студент ознайомлюється з правилами
проходження іспиту, що зображені на рисунку В.4. На цій сторінці міститься
інформація про умови тестування, вимоги до середовища та особливості роботи
системи прокторингу. Для початку тесту користувач повинен підтвердити свою
згоду з правилами.
Рисунок В.4 – Правила проходження іспиту
Процес проходження тестування представлений на рисунку В.5.
Користувач послідовно відповідає на запитання, обираючи один правильний
варіант відповіді. Система відображає прогрес проходження тесту, що дозволяє
контролювати кількість виконаних завдань. Після завершення тестування
результати автоматично обчислюються та зберігаються.
Під час проходження тестування активується модуль онлайн-прокторингу,
який показано на рисунку В.6. Система використовує веб-камеру для відстеження
обличчя користувача та аналізу його поведінки. У разі виявлення підозрілих дій,
таких як відсутність обличчя в кадрі або значні рухи голови, відповідні події
фіксуються та зберігаються для подальшого аналізу.
Після завершення тестування студент має можливість переглянути
результати, що відображено на рисунку В.7. На цій сторінці міститься інформація
про кількість правильних відповідей, відсоток виконання та дата проходження
115
482.ЧДТУ 262245 34 01 5
тесту. Це дозволяє користувачу оцінити рівень своїх знань.
Рисунок В.5 – Сторінка проходження іспиту
Рисунок В.6 – Вікно прокторингу
116
482.ЧДТУ 262245 34 01 6
Рисунок В.7 – Сторінка результатів проходження тестувань
Функціональні можливості викладача включають створення іспитів,
додавання запитань, перегляд результатів та аналіз порушень. Сторінка
створення іспиту представлена на рисунку В.8. Викладач вводить основні
параметри тесту, після чого може перейти до додавання запитань.
Рисунок В.8 – Сторінка створення іспиту
117
482.ЧДТУ 262245 34 01 7
Інтерфейс додавання запитань зображено на рисунку В.9. На цій сторінці
викладач формує запитання, додає варіанти відповідей та визначає правильний
варіант. Після цього запитання зберігаються у системі та стають доступними для
проходження студентами.
Рисунок В.9 – Сторінка додаваня питань до іспитів
Журнал прокторингу, представлений на рисунку В.10, дозволяє викладачу
аналізувати поведінку студентів під час тестування. У журналі відображаються
всі зафіксовані події, що дозволяє оцінити доброчесність проходження іспиту.
Рисунок В.10 – Журнал прокторингу
118
482.ЧДТУ 262245 34 01 8
Користувач також має можливість редагувати свої облікові дані, що
показано на рисунку В.11. На цій сторінці можна змінити ім’я, електронну пошту
та пароль, після чого зберегти внесені зміни.
Рисунок В.11 – Сторінка оновлення даних облікового запису
Таким чином, система онлайн-прокторингу забезпечує повний цикл роботи
з дистанційним тестуванням, включаючи реєстрацію користувачів, проходження
тестів, контроль поведінки та аналіз результатів. Інтерфейс системи є зрозумілим
та зручним у використанні, що дозволяє ефективно застосовувати її у
навчальному процесі.
119
ДОДАТОК Г
ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ АВТОМАТИЗОВАНОЇ СИСТЕМИ
ОНЛАЙН-ПРОКТОРИНГУ
Графічні матеріали
482.ЧДТУ.262245 90 01
Листів 7
Розробник ________________ Кравченко А.Р.
Черкаси 2026
482.ЧДТУ.262245 90 01 2
Рисунок Г.1 – Слайд 1
Рисунок Г.2 – Слайд 2
121
482.ЧДТУ.262245 90 01 3
Рисунок Г.3 – Слайд 3
Рисунок Г.4 – Слайд 4
122
482.ЧДТУ 262245 90 01 4
Рисунок Г.5 – Слайд 5
Рисунок Г.6 – Слайд 6
123
482.ЧДТУ 262245 90 01 5
Рисунок Г.7 – Слайд 7
Рисунок Г.8 – Слайд 8
124
482.ЧДТУ 262245 90 01 6
Рисунок Г.9 – Слайд 9
Рисунок Г.10 – Слайд 10
125
482.ЧДТУ.262245 90 01 7
Рисунок Г.11 – Слайд 11
Рисунок Г.12 – Слайд 12
126
482.ЧДТУ 262245 90 01 8
Рисунок Г.13 – Слайд 13
127