ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9567| Title: | Програмне забезпечення діагностики дидактичної системи |
| Authors: | Немов, Руслан Григорович Дзюндзя, Данило Миколайович |
| Keywords: | ВЕБ-ПЛАТФОРМА;ДІАГНОСТИКА ЗНАНЬ;ДИДАКТИЧНА СИСТЕМА;АВТОМАТИЗАЦІЯ НАВЧАННЯ;NEXT.JS;TYPESCRIPT;POSTGRESQL;PRISMA ORM;ПЕДАГОГІЧНИЙ КОНТРОЛЬ;АНАЛІТИКА УСПІШНОСТІ;WEB PLATFORM;KNOWLEDGE DIAGNOSTICS;DIDACTIC SYSTEM;TEACHING AUTOMATION;NEXT.JS;TYPESCRIPT;POSTGRESQL;PRISMA ORM;PEDAGOGICAL CONTROL;SUCCESS ANALYTICS |
| Issue Date: | 17-Jun-2026 |
| Abstract: | АНОТАЦІЇ
Виконавець: Дзюндзя Данило Миколайович
Назва роботи: «Програмне забезпечення діагностики дидактичної системи»
Спеціальність: 121 Інженерія програмного забезпечення.
Навчальний заклад: «Черкаський державний технологічний університет» м. Черкаси, 2026р.
Основні ідеї – робота присвячена створенню веб-платформи для автоматизації педагогічної діагностики. Проєкт вирішує проблему низької ефективності традиційного контролю знань шляхом впровадження інструментів моніторингу в реальному часі та візуалізації індивідуального прогресу учнів. Основна концепція базується на забезпеченні миттєвого зворотного зв’язку та підвищенні об’єктивності оцінювання.
Результати – спроектовано клієнт-серверну архітектуру на базі Next.js, TypeScript та PostgreSQL (Prisma ORM). Реалізовано візуальний конструктор тестів, систему розмежування прав доступу та аналітичні дашборди на основі Recharts для візуалізації показників успішності. Інтерфейс платформи реалізовано з використанням Tailwind CSS, що забезпечує повну адаптивність для мобільних та десктопних пристроїв.
Висновки – програмний комплекс автоматизує перевірку знань, мінімізуючи людський фактор та суттєво заощаджуючи час викладача. Результати комплексного тестування підтвердили стабільність роботи модулів, безпеку даних та повну готовність системи до практичного впровадження в освітній процес. ANNOTATIONS Performer: Dzyundza Danylo Mykolayovych Title of work: “Didactic system diagnostics software” Specialty: 121 Software Engineering. Institution: Cherkasy State Technological University City, Year: Cherkasy, 2026 Main ideas – work dedicated to the created web platform for the automation of pedagogical diagnostics. The project solves the problem of low efficiency of traditional knowledge control by implementing real-time monitoring tools and visualization of individual student progress. The main concept is based on providing instant feedback and increased objectivity of assessment. Results – a client-server architecture based on Next.js, TypeScript and PostgreSQL (Prisma ORM) was designed. A visual test designer, a system of access rights separation and analytical dashboards based on Recharts were implemented to visualize success indicators. The platform interface was implemented using Tailwind CSS, which provides full adaptability for mobile and desktop devices. Conclusions – the software complex automates knowledge testing, minimizing the human factor and significantly saving the teacher's time. The results of comprehensive testing confirmed the stability of the modules, data security and the full readiness of the system for practical implementation in the educational process. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9567 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Дзюндзя Данило Миколайович.pdf Restricted Access | 7.89 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
бакалавра
на тему: «Програмне забезпечення діагностики дидактичної системи»
Виконав: студент 4 курсу, групи ПЗС-2204
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Дзюндзя Д.М.
(прізвище та ініціали)
Керівник Немов Р.Г.
(прізвище та ініціали)
Рецензент Русалівський Б.В.
(прізвище та ініціали)
Черкаси 2026
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
____________________ С. Голуб
«___» _______________ 2026 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Дзюндзі Данилу Миколайовичу
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Програмне забезпечення діагностики дидактичної системи
Керівник проекту (роботи) Немов Руслан Григорович
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « 13 » березня 2026 року
№333/01
2. Строк подання студентом проекту (роботи) 3 червня 2026 року
3. Вхідні дані до проекту (роботи): Технічне завдання на розробку інтерактивної веб-платформи;
документація до фреймворку Next.js та СУБД PostgreSQL; методичні рекомендації до виконання
бакалаврської кваліфікаційної роботи;
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) Вступ;
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань (аналіз предметної області, огляд
аналогів та обґрунтування технологічного стеку);
Розділ 2. Проектування архітектури та логічної структури системи діагностики;
Розділ 3. Реалізація та тестування програмного комплексу;
Висновки;
Список використаних джерел;
Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту Слайд 1; Слайд 2;
Слайд 3; Слайд 4; Слайд 5; Слайд 6; Слайд 7; Слайд 8; Слайд 9; Слайд 10; Слайд 11; Слайд 12; Слайд 13;
Слайд 14; Слайд 15; Слайд 16; Слайд 17; Слайд 18; Слайд 19; Слайд 20; Слайд 21;
6. Консультанти розділів роботи
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
Дата видачі завдання 13 березня 2026 р.
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№
Назва етапів випускної роботи етапів кваліфікаційної Примітки
п/п
роботи
1 Постановка задачі 05.12.2025 виконано
2 Підготовка завдання 13.12.2025 виконано
3 Погодження завдання 16.12.2025 виконано
4 Затвердження завдання 19.02.2026 виконано
Основна стадія
1 Підбір матеріалів 27.02.2026 виконано
2 Аналіз шляхів вирішення поставленої задачі 04.02.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 Затвердження роботи 19.05.2026 виконано
5 Рецензування роботи 26.05.2026 виконано
6 Захист роботи 03.06.2026
Студент _____________________ Дзюндзя Д.М.
(підпис) (прізвище та ініціали)
Керівник роботи _____________________ Немов Р. Г.
(підпис) (прізвище та ініціали)
АНОТАЦІЇ
Виконавець: Дзюндзя Данило Миколайович
Назва роботи: «Програмне забезпечення діагностики дидактичної системи»
Спеціальність: 121 Інженерія програмного забезпечення.
Навчальний заклад: «Черкаський державний технологічний університет»
м. Черкаси, 2026р.
Основні ідеї – робота присвячена створенню веб-платформи для
автоматизації педагогічної діагностики. Проєкт вирішує проблему низької
ефективності традиційного контролю знань шляхом впровадження інструментів
моніторингу в реальному часі та візуалізації індивідуального прогресу учнів.
Основна концепція базується на забезпеченні миттєвого зворотного зв’язку та
підвищенні об’єктивності оцінювання.
Результати – спроектовано клієнт-серверну архітектуру на базі Next.js,
TypeScript та PostgreSQL (Prisma ORM). Реалізовано візуальний конструктор
тестів, систему розмежування прав доступу та аналітичні дашборди на основі
Recharts для візуалізації показників успішності. Інтерфейс платформи реалізовано
з використанням Tailwind CSS, що забезпечує повну адаптивність для мобільних
та десктопних пристроїв.
Висновки – програмний комплекс автоматизує перевірку знань, мінімізуючи
людський фактор та суттєво заощаджуючи час викладача. Результати
комплексного тестування підтвердили стабільність роботи модулів, безпеку даних
та повну готовність системи до практичного впровадження в освітній процес.
Ключові слова: ВЕБ-ПЛАТФОРМА, ДІАГНОСТИКА ЗНАНЬ,
ДИДАКТИЧНА СИСТЕМА, АВТОМАТИЗАЦІЯ НАВЧАННЯ, NEXT.JS,
TYPESCRIPT, POSTGRESQL, PRISMA ORM, ПЕДАГОГІЧНИЙ КОНТРОЛЬ,
АНАЛІТИКА УСПІШНОСТІ.
ANNOTATIONS
Performer: Dzyundza Danylo Mykolayovych
Title of work: “Didactic system diagnostics software”
Specialty: 121 Software Engineering.
Institution: Cherkasy State Technological University
City, Year: Cherkasy, 2026
Main ideas – work dedicated to the created web platform for the automation of
pedagogical diagnostics. The project solves the problem of low efficiency of traditional
knowledge control by implementing real-time monitoring tools and visualization of
individual student progress. The main concept is based on providing instant feedback
and increased objectivity of assessment.
Results – a client-server architecture based on Next.js, TypeScript and
PostgreSQL (Prisma ORM) was designed. A visual test designer, a system of access
rights separation and analytical dashboards based on Recharts were implemented to
visualize success indicators. The platform interface was implemented using Tailwind
CSS, which provides full adaptability for mobile and desktop devices.
Conclusions – the software complex automates knowledge testing, minimizing the
human factor and significantly saving the teacher's time. The results of comprehensive
testing confirmed the stability of the modules, data security and the full readiness of the
system for practical implementation in the educational process.
Keywords: WEB PLATFORM, KNOWLEDGE DIAGNOSTICS, DIDACTIC
SYSTEM, TEACHING AUTOMATION, NEXT.JS, TYPESCRIPT, POSTGRESQL,
PRISMA ORM, PEDAGOGICAL CONTROL, SUCCESS ANALYTICS.
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ТА СКОРОЧЕНЬ ........................................ 6
ВСТУП ...................................................................................................................... 7
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВЯЗУВАННЯ ПОСТАВЛЕНИХ
ЗАДАЧ ..................................................................................................................... 11
1.1 Актуальні проблеми, що виникають у процесі діагностики знань ............ 11
1.2 Аналіз предметної області ............................................................................ 12
1.3 Аналіз існуючих програмних рішень ........................................................... 14
1.4 Обґрунтування вибору технологій ............................................................... 16
1.4.1 Фреймворк Next.js та мова програмування TypeScript ......................... 16
1.4.2 Система керування базами даних PostgreSQL та Prisma ORM ............ 17
1.4.3 Система авторизації NextAuth.js ............................................................ 18
1.4.4 Tailwind CSS, Lucide React та Recharts .................................................. 18
1.5 Постановка задачі ......................................................................................... 18
ВИСНОВОКИ ДО ПЕРШОГО РОЗДІЛУ ............................................................. 20
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ ................................................................................................................. 21
2.1. Моделювання предметної області ............................................................... 21
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області ........................................................................... 22
2.1.2. Елементи моделювання предментної області ...................................... 23
2.1.3. Робоча область моделювання ................................................................ 25
2.2. Формування та аналіз вимог........................................................................ 25
2.2.1. Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробка. Функціональні і
нефункціональні вимоги. ................................................................................ 26
2.2.2. Формування вимог за допомогою діаграм прецедентів ....................... 29
2.3. Проектування логічної структури програмного комплексу ....................... 33
2.3.1. Діаграма класів ...................................................................................... 33
ЧДТУ 2357.001 ПЗ
Зм Арк. № докум. Підпис Дата
Розроб. Дзюндзя Д.М. «Програмне забезпечення Літ. Арк. Акрушів
Перевір. Немов Р. Г 4 115
діагностики дидактичної
Реценз.
Н. Контр. Немов Р. Г. системи» ФІТІС, кафедра ПЗАС, ПЗС-2204
Затверд. Голуб С.В. Пояснювальна записка.
2.3.2 Діаграма пакетів ...................................................................................... 36
2.4 Архітектурне проектування .......................................................................... 38
2.4.1. Діаграма компонентів та логічна архітектура ...................................... 38
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ...................................................................................................... 39
2.5 Моделювання поведінки системи ................................................................ 41
2.5.1. Діаграма діяльності ............................................................................... 41
2.5.2. Діаграма послідовності ......................................................................... 42
2.5.3. Діаграма комунікації .............................................................................. 44
2.5.4. Діаграма скінченного автомату ............................................................. 45
ВИСНОВОКИ ДО ДРУГОГО РОЗДІЛУ ............................................................... 47
РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ48
3.1 Розробка програмного комплексу ................................................................ 48
3.1.1 Обґрунтування вибору засобів реалізації .............................................. 48
3.1.2 Опис структурної (функціональної) схеми ............................................ 50
3.1.3 Опис логічної схеми системи ................................................................. 53
3.1.4 Розробка бази даних ............................................................................... 54
3.1.5 Розробка інтерфейсу користувача .......................................................... 57
3.1.6 Опис розробки програмних компонентів .............................................. 62
3.2 Тестування системи ...................................................................................... 67
3.2.1 Модульне тестування .............................................................................. 67
3.2.2 Інтеграційне тестування ......................................................................... 69
3.2.3 Системне тестування .............................................................................. 71
3.2.4 Приймальне тестування.......................................................................... 73
3.3 Приклади впровадження програмного комплексу ...................................... 74
ВИСНОВКИ ПО РОЗДІЛУ 3 ................................................................................. 77
ВИСНОВКИ ........................................................................................................... 78
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ............................................................... 79
ДОДАТОК А ........................................................................................................... 81
ДОДАТОК Б............................................................................................................ 83
ДОДАТОК В ......................................................................................................... 102
ДОДАТОК Г.......................................................................................................... 105
ЧДТУ 2357.001 ПЗ
Змн. Арк. № докум. Підпис Дата
ЧДТУ 262357.001 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ТА СКОРОЧЕНЬ
БД База даних
СУБД Система управління базами даних
ACID Atomicity, Consistency, Isolation, Durability (атомарність,
узгодженість, ізольованість, довговічність – властивості
транзакцій бази даних)
API Application Programming Interface (інтерфейс прикладного
програмування)
CDN Content Delivery Network (мережа доставки контенту)
CSS Cascading Style Sheets (каскадні таблиці стилів)
HTML HyperText Markup Language (мова гіпертекстової розмітки)
HTTP HyperText Transfer Protocol (протокол передачі гіпертексту)
HTTPS HyperText Transfer Protocol Secure (захищений протокол передачі
гіпертексту)
JSON JavaScript Object Notation (текстовий формат обміну даними)
JWT JSON Web Token (веб-токен JSON для безпечної передачі даних)
ORM Object-Relational Mapping (об'єктно-реляційне відображення)
RBAC Role-Based Access Control (керування доступом на основі ролей)
SEO Search Engine Optimization (пошукова оптимізація сайту)
SSL Secure Sockets Layer (рівень захищених сокетів для шифрування
зв'язку)
SSR Server-Side Rendering (серверний рендеринг веб-сторінок)
UI User Interface (інтерфейс користувача)
UML Unified Modeling Language (уніфікована мова моделювання)
URL Uniform Resource Locator (адреса ресурсу в мережі Інтернет)
UX User Experience (користувацький досвід)
VPS Virtual Private Server (віртуальний приватний сервер)
6
ЧДТУ 262357.001 ПЗ
ВСТУП
Актуальність теми – стрімкий розвиток інформаційно-комунікаційних
технологій та глобальна цифровізація суспільства докорінно змінюють підходи до
організації освітнього процесу. Сучасна освіта вже не може нормально
функціонувати без впровадження спеціалізованих ІТ-рішень. В умовах стійкого
переходу до змішаних та дистанційних форм навчання, а також через постійне
зростання запитів на персоналізоване навчання та високу якість викладання,
навчальним закладам потрібні принципово оновлені механізми перевірки
успішності.
Звичні традиційні підходи до педагогічної діагностики, такі як робота з
паперовими бланками, виконання стандартних письмових робіт чи усні відповіді
біля дошки, поступово втрачають свою дієвість. Їх головний недолік полягає у
відсутності оперативності: вони вимагають значних витрат часу викладача на
ручну перевірку та не дають можливості миттєво збирати статистику. Внаслідок
цього викладач не може своєчасно бачити масові помилки студентів, виявляти
прогалини у знаннях та оперативно змінювати подачу навчального матеріалу, що
значно знижує ефективність засвоєння дисципліни.
Сучасна педагогіка вимагає переходу від констатуючого контролю до
формувального, де оцінювання є інструментом для безперервної корекції
навчальної траєкторії. Для реалізації такого підходу необхідні системи, здатні
автоматично накопичувати та аналізувати освітні дані. Саме тому розробляти веб-
орієнтовані інтерактивні дидактичні комплекси сьогодні вкрай важливо.
Ці платформи дають змогу не лише формувати тестові завдання різного
рівня складності, а й без участі людини збирати, перевіряти та обробляти
результати у режимі реального часу. Використання веб-додатків докорінно змінює
освітню рутину: учні отримують цілодобовий кросплатформний доступ до
інформації, взаємодіють з різними видами контенту та проходять онлайн-
тестування у комфортному темпі. Педагоги ж мають під рукою зручний засіб
моніторингу та глибокої аналітики. Запровадження таких інновацій усуває
7
ЧДТУ 262357.001 ПЗ
проблему суб'єктивності, гарантує прозорість оцінок, стимулює студентів до
роботи та покращує загальні показники якості освітніх послуг.
Мета розробки цього проєкту – спроєктувати та запустити інтерактивну
освітню веб-платформу. Вона має стати єдиним середовищем для проведення
занять, генерації різних типів вправ та автоматичного визначення рівня підготовки
учнів.
Завдання розробки
Відповідно до поставленої мети, було сформовано такий перелік кроків:
вивчити поточний ринок освітніх систем та виокремити їхні головні
мінуси;
розробити структурну схему веб-додатка, спираючись на актуальні
стандарти програмування;
написати логіку створення акаунтів, входу в систему та поділу прав
(адміністратор, учень, викладач);
створити спеціальний модуль для збірки інтерактивних тестів;
налаштувати процес здачі завдань із подальшим алгоритмічним аналізом
відповідей;
запрограмувати автоматичний підрахунок балів та їх запис у базу;
реалізувати панель керування для завантаження навчального контенту;
зв'язати серверну та клієнтську частини за правилами REST API;
сформувати структуру бази даних для збереження профілів, тестів,
оцінок та лекцій;
перевірити працездатність готової програми шляхом комплексного
тестування.
Об’єкт розробки – процедури перевірки знань та управління освітнім
процесом за допомогою новітніх комп'ютерних технологій.
Предмет розробки – програмні рішення, алгоритми та інструменти, які
застосовуються для побудови інтерактивних веб-систем освітнього призначення.
Методи проєктування та конструювання – під час написання коду
застосовувався такий набір технологій:
8
ЧДТУ 262357.001 ПЗ
Next.js [6] – базовий React-фреймворк, на якому побудовано весь
застосунок;
React [8] – JS-бібліотека, що відповідає за візуальну складову та
інтерфейс;
TypeScript [7] – мова програмування зі строгою типізацією для
зменшення кількості помилок;
Tailwind CSS [13] – набір інструментів для швидкого створення стилів;
PostgreSQL [10] разом із Prisma ORM – для керування таблицями в
реляційній базі даних;
NextAuth.js [17] – для контролю сесій та безпечної авторизації;
bcryptjs – алгоритм для надійного шифрування паролів;
@dnd-kit – плагін для перетягування об'єктів мишкою (drag-and-drop);
Recharts – інструмент для побудови діаграм успішності;
Git та GitHub – система для збереження версій коду;
UML-діаграми [5] – графічне представлення архітектури платформи;
Cloudinary [24], Firebase [25], Vercel Blob – зовнішні хмарні сховища для
фотографій, файлів та іншого медіа.
Опис отриманих результатів – фінальним продуктом стала повністю
робоча навчальна веб-платформа. Програмний комплекс містить систему входу,
редактор тестів, вікно здачі завдань та базу оцінок. Користувачам доступні різні
види інтерактивних вправ, машинний підрахунок результатів та окремі сторінки
профілів (для учня і вчителя). Завдяки універсальній будові коду, цю розробку
можна легко адаптувати під вивчення будь-якої шкільної чи університетської
дисципліни.
Практичне значення отриманих результатів – створений веб-додаток
надає педагогам зручний простір для генерації уроків та миттєвого зрізу знань.
Програма бере на себе рутину з перевірки робіт, що суттєво економить час
викладача та виключає упередженість в оцінках. Накопичена статистична база дає
змогу детально вивчати прогрес групи, швидко знаходити незрозумілі теми та
вчасно змінювати хід навчання.
9
ЧДТУ 262357.001 ПЗ
Особистий внесок автора – вся пророблена робота полягає у самостійній
розробці інтерактивної дидактичної системи діагностики знань: від проведення
аналізу проблем педагогічного контролю та існуючих веб-платформ до повної
програмної реалізації проєкту.
Автором було проведено критичний аналіз аналогів, на основі якого
обґрунтовано вибір сучасного стеку технологій (Next.js, Prisma ORM, PostgreSQL)
та сформовано вимоги до майбутнього продукту. Самостійно спроектовано
логічну та фізичну архітектуру системи, розроблено структуру бази даних та
реалізовано всі ключові функціональні модулі: конструктор інтерактивних тестів,
систему автоматизованої перевірки відповідей та модуль аналітичної звітності.
Автор також здійснив повний цикл тестування програмного комплексу та оформив
результати дослідження згідно з вимогами до кваліфікаційних робіт бакалавра.
10
ЧДТУ 262357.001 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВЯЗУВАННЯ
ПОСТАВЛЕНИХ ЗАДАЧ
1.1. Актуальні проблеми, що виникають у процесі діагностики знань
Сучасна освітня практика стикається з низкою системних труднощів при
організації ефективного контролю та оцінки знань. Традиційні форми перевірки
(усне опитування, письмові контрольні роботи, бланкове тестування) вже не
відповідають швидкості та динаміці сучасного навчального процесу. Основна
проблема полягає в затримці зворотного зв'язку: викладач отримує результати
перевірки тоді, коли можливість оперативно скоригувати навчальний процес або
надати своєчасну індивідуальну допомогу вже фактично втрачена.
Серед найбільш критичних недоліків класичних методів діагностики можна
виділити такі:
непропорційно великі витрати робочого часу – ручна перевірка робіт
унеможливлює миттєвий зворотний зв’язок. Затримка аналізу помилок знижує
ефективність засвоєння матеріалу, оскільки здобувачі освіти отримують свої
результати через кілька днів після тестування;
зниження рівня об’єктивності – ручне оцінювання завжди піддається
впливу суб’єктивних факторів (різні підходи до трактування однакових
відповідей, втома викладача тощо);
неможливість гнучкого структурного аналізу – викладач зазвичай бачить
лише загальну картину успішності (підсумковий бал), але ручними методами
вкрай важко швидко визначити, які саме поняття чи теми викликають масові
труднощі в усій групі;
складність акумулювання статистичних даних: відсутність
централізованої бази даних унеможливлює автоматичне відстеження динаміки
успіхів окремого учня чи групи протягом тривалого періоду;
технічні обмеження щодо варіативності завдань – переважна більшість
класичних тестів зводиться до вибору однієї правильної відповіді через простоту
їх перевірки. При цьому завдання на встановлення послідовності, логічні зв’язки
11
ЧДТУ 262357.001 ПЗ
чи множинний вибір використовуються значно рідше, оскільки їх ручна обробка
є надто трудомісткою.
Варто також відзначити психологічний аспект традиційного контролю.
Сучасне покоління здобувачів освіти, що зростає в умовах швидкого доступу до
цифрової інформації, очікує на миттєву реакцію системи на свої дії. Відсутність
швидкої оцінки після виконання завдання призводить до зниження рівня мотивації
та залученості. З іншого боку, викладачі витрачають левову частку свого робочого
часу на рутинну перевірку бланків та формування бюрократичних звітів, замість
того, щоб приділяти увагу вдосконаленню методики викладання та індивідуальній
роботі зі студентами.
Особливо відчутними ці проблеми стають в умовах дистанційного та
гібридного навчання. Коли комунікація відбувається через цифрові канали, а
кількість учнів у потоці є великою, класичні методи діагностики повністю
втрачають свою ефективність. Перехід до асинхронного навчання вимагає
децентралізованих інструментів, де кожен учень може проходити перевірку в
індивідуальному темпі. Наявні на ринку цифрові платформи частково закривають
ці потреби, проте часто стикаються з проблемою балансу: вони або надто
примітивні для глибокого аналізу, або настільки перевантажені функціоналом, що
вимагають значного часу на їх освоєння.
Через це, виникає об’єктивна потреба у створенні спеціалізованої
інтерактивної дидактичної системи. Вона має взяти на себе рутину автоматичної
перевірки завдань різних типів та забезпечити викладача миттєвою аналітикою,
що дозволить значно підвищити оперативність, об’єктивність та загальну якість
контролю знань.
1.2. Аналіз предметної області
Предметна область діагностики знань учнів охоплює різні методи і форми
контролю, які застосовуються в сучасній педагогіці. Системний підхід до
управління навчальним процесом розглядає діагностику не просто як інструмент
виставлення оцінок, а як складний механізм отримання даних для прийняття
12
ЧДТУ 262357.001 ПЗ
педагогічних рішень. У теорії освіти виділяють три основні види контролю:
формувальний, підсумковий та діагностичний.
Формувальний контроль (formative assessment) спрямований на поточне
відстеження прогресу учнів під час вивчення матеріалу. Він дозволяє викладачеві
оперативно коригувати навчальний процес, а учням – отримувати зворотний
зв’язок. Однак у традиційній формі цей вид контролю вимагає великих витрат часу
викладача і погано масштабується.
Підсумковий контроль (summative assessment) проводиться після
завершення вивчення теми чи розділу і має на меті визначити кінцевий рівень
засвоєння знань. Його основний недолік – відсутність можливості оперативного
втручання в процес навчання, оскільки оцінка виставляється вже після завершення
етапу.
Діагностичний контроль спрямований на виявлення прогалин у знаннях,
типових помилок і причин їх виникнення. Саме цей вид контролю є
найскладнішим для реалізації традиційними методами, оскільки потребує
детального аналізу відповідей учнів за кожним питанням і темою.
Для того щоб дидактична система працювала ефективно, комп'ютерне
тестування, яке є її основою, повинно відповідати трьом ключовим
наукометричним критеріям:
валідність (Validity) – тест має вимірювати саме ті знання і навички, для
перевірки яких він був створений. Забезпечення валідності вимагає можливості
створювати різнопланові типи питань, що виходять за межі простого вгадування;
надійність (Reliability) – результати тестування повинні бути
стабільними і не залежати від зовнішніх технічних факторів. Це накладає суворі
вимоги на програмну архітектуру: система не повинна втрачати дані користувача
у разі розриву з'єднання або випадкового закриття вкладки браузера;
об'єктивність (Objectivity) – мінімізація або повне виключення
людського фактору під час перевірки робіт. Саме комп'ютерна валідація
відповідей гарантує стовідсоткову об'єктивність розрахунку балів.
13
ЧДТУ 262357.001 ПЗ
У сучасних умовах особливого значення набуває інтерактивна діагностика,
яка поєднує елементи всіх трьох видів контролю. Вона базується на принципах
освітньої аналітики (Learning Analytics) [15] – галузі, що займається
вимірюванням, збором, аналізом і поданням даних про учнів та їхній контекст з
метою розуміння та оптимізації навчання. Інтерактивна діагностика передбачає
автоматичну перевірку відповідей, миттєвий зворотний зв’язок, накопичення
статистики та можливість адаптації завдань під рівень підготовки учня. Саме така
форма діагностики, підкріплена математичними алгоритмами збору даних, є
основою предметної області розроблюваної системи.
1.3. Аналіз існуючих програмних рішень
На сьогоднішній день на ринку освітнього програмного забезпечення
(EdTech) існує значна кількість систем управління навчанням (LMS – Learning
Management Systems) та спеціалізованих веб-платформ для діагностики знань. За
типом розгортання їх можна поділити на серверні рішення (Self-hosted), які
потребують власної інфраструктури, та хмарні сервіси (SaaS – Software as a
Service). Найпоширенішими серед них в українському освітньому просторі є
Moodle, Google Classroom та вітчизняний сервіс Naurok.com.ua. Кожна з цих
систем проектувалася під певні завдання і має як сильні сторони, так і суттєві
обмеження.
Moodle [2] – це система управління навчанням з відкритим вихідним кодом
(Open Source), яка є стандартом де-факто для вищої школи. Вона дозволяє
створювати масштабні електронні курси, формувати складні бази тестових
завдань та генерувати детальні звіти. Серед головних переваг – гнучкість
налаштувань та можливість розширення функціоналу через тисячі сторонніх
плагінів. Проте Moodle має низку критичних недоліків для масового використання
в середній школі. З технічної точки зору це монолітна система, побудована на
застарілих патернах розробки. Її архітектурна перевантаженість, неінтуїтивний
інтерфейс користувача (UI) та високий поріг входження створюють бар'єри для
вчителів без технічного бекграунду. Крім того, монолітна архітектура зумовлює
14
ЧДТУ 262357.001 ПЗ
значну вимогливість до ресурсів сервера під час одночасного тестування великих
груп, що часто призводить до збоїв.
Google Classroom [1] – популярна хмарна платформа, яка стала базовим
інструментом для багатьох шкіл завдяки своїй безкоштовності та безшовній
інтеграції з екосистемою Google Workspace. Вона працює за моделлю SaaS і
дозволяє зручно організовувати класи, розсилати завдання та вести комунікацію.
Її головні переваги – мінімалізм, стабільність і швидкість розгортання без
необхідності адміністрування серверів. Водночас Classroom не є повноцінною
системою діагностики знань: інструментарій Google Forms, який
використовується для тестування, має вкрай обмежені можливості для створення
складних інтерактивних завдань (наприклад, завдань на встановлення
відповідності чи хронологічної послідовності), а вбудована аналітика є занадто
поверхневою для прийняття педагогічних рішень і зводиться до простого експорту
даних в електронні таблиці.
Naurok.com.ua [16] – спеціалізований український освітній портал,
орієнтований на вчителів середньої загальноосвітньої школи. Сервіс пропонує
зручний і зрозумілий конструктор тестів, доступ до великої спільної бібліотеки
матеріалів та миттєву автоматичну перевірку. Незважаючи на високу
популярність та адаптованість до вітчизняних реалій, функціонал порталу
обмежений жорсткими рамками стандартизованих тестів. Сервіс не надає
інструментів для глибокого структурного аналізу результатів у розрізі окремих
тем, має обмежену кастомізацію завдань і не підтримує розширене управління
ролями користувачів у межах навчального закладу (наприклад, відсутня роль
адміністратора школи для загального моніторингу).
Для наочного відображення недоліків та переваг існуючих рішень у
порівнянні з вимогами до проектованої системи, проведено їх порівняння за
ключовими критеріями:
сучасний та інтуїтивний UI/UX – високий рівень зручності характерний
для Google Classroom та проектованої системи; середній рівень має Naurok;
низький рівень (через перевантаженість) притаманний Moodle;
15
ЧДТУ 262357.001 ПЗ
складні інтерактивні завдання – повноцінно заплановані в проектованій
системі; присутні в Moodle (але потребують встановлення та налаштування
додаткових плагінів); значно обмежені в платформі Naurok; практично відсутні в
інструментарії Google Classroom;
глибока аналітика результатів – високий та деталізований рівень
пропонує Moodle та майбутня проектована система; середній (базовий) рівень
надає Naurok; низький рівень аналітики має Google Classroom;
легкість розгортання та підтримки – висока легкість у Google Classroom
(хмарний сервіс), Naurok (SaaS) та проектованої системи (використання сучасного
стеку технологій);
низька легкість розгортання у Moodle (потребує виділеного сервера та
системного адміністрування).
Проведений аналіз доводить, що більшість рішень є компромісними. Жодна
з наявних платформ не забезпечує ідеального балансу між простотою
використання (як у Google Classroom), спеціалізованим підходом (як у Naurok) та
потужними діагностичними можливостями, заснованими на сучасній архітектурі.
1.4. Обґрунтування вибору технологій
Вибір технологічного стеку для розробки інтерактивної дидактичної
системи здійснювався з урахуванням ключових вимог: високої продуктивності,
безпеки даних, зручності розробки, масштабованісті та можливості швидкого
створення сучасного адаптивного інтерфейсу. Розробка базується на принципах
клієнт-серверної архітектури (Client-Server Architecture) з використанням підходу
REST API. Було обрано сучасний JavaScript/TypeScript-стек, який на сьогодні є
одним з найефективніших для створення складних веб-додатків освітнього
призначення.
1.4.1. Фреймворк Next.js та мова програмування TypeScript
Next.js обрано як основний фреймворк завдяки поєднанню серверного (SSR)
та клієнтського (CSR) рендерингу, що забезпечує високу швидкодію та
16
ЧДТУ 262357.001 ПЗ
оптимальну SEO-оптимізацію. На відміну від класичних Single Page Applications
(SPA), гібридний рендеринг дозволяє миттєво віддавати користувачеві розмітку
сторінки. Для системи діагностики знань це особливо важливо, оскільки сторінки
проходження тестів та кабінети викладачів повинні завантажуватися максимально
швидко. Архітектура App Router дозволяє чітко розділяти серверні та клієнтські
компоненти. Це критично важливо для модулів автоматичної перевірки відповідей
– вся логіка оцінювання виконується виключно на сервері, що унеможливлює
маніпуляції з результатами з боку клієнта через інструменти розробника в
браузері.
Використання мови TypeScript забезпечує строгу статичну типізацію всього
коду. Це особливо актуально при роботі зі складними деревоподібними
структурами даних, такими як масиви питань тесту, об'єкти варіантів відповідей,
результати спроб та вкладені аналітичні звіти. TypeScript значно знижує кількість
помилок "run-time" на етапі розробки, полегшує рефакторинг та робить код
самодокументованим і підтримуванішим у довгостроковій перспективі.
1.4.2. Система керування базами даних PostgreSQL та Prisma ORM
Оскільки дидактична система генерує велику кількість пов'язаної
інформації, для зберігання даних обрано реляційну базу даних PostgreSQL [10].
Вона забезпечує високу надійність, підтримку транзакцій та відповідність
принципам ACID (атомність, узгодженість, ізольованість, довговічність). Система
дозволяє будувати складні зв’язки між сутностями (User → Test → Question →
Option → Result) та має можливість роботи з JSONB-полями для гнучкого
зберігання специфічної структури відповідей учнів. Це дозволяє ефективно
реалізовувати як прості вибірки, так і надскладну аналітику по всьому
навчальному закладу.
Prisma ORM [9] (Object-Relational Mapping) обрано як інструмент роботи з
базою даних завдяки повній типізації запитів і відповідей на рівні TypeScript. Вона
виступає прошарком між серверним кодом та БД, що дозволяє працювати з
даними на рівні об’єктів, значно прискорюючи розробку аналітичних модулів. Це
17
ЧДТУ 262357.001 ПЗ
суттєво знижує ризик класичних вразливостей (наприклад, SQL-ін’єкцій) та
помилок у запитах. Prisma також автоматично генерує та застосовує міграції, що
спрощує підтримку схеми бази даних на етапі активної розробки архітектури.
1.4.3. Система авторизації NextAuth.js
NextAuth.js забезпечує безпечне управління сесіями користувачів та роботу
з JWT-токенами. Система підтримує розмежування ролей (STUDENT, TEACHER,
ADMIN), що є обов’язковою вимогою для дидактичної платформи. Використання
NextAuth.js дозволяє реалізувати гібридну авторизацію: як для зареєстрованих
користувачів, так і для «гостьового» проходження тестів за кодом доступу. Це
робить платформу максимально гнучкою для використання як у повсякденному
навчальному процесі, так і для швидких зрізів знань.
1.4.4. Tailwind CSS, Lucide React та Recharts
Для створення сучасного адаптивного інтерфейсу обрано Tailwind CSS [18].
Цей утилітарний CSS-фреймворк дозволяє швидко створювати складні
компоненти (конструктор тестів, панелі результатів, аналітичні дашборди) без
написання великих обсягів кастомного CSS-коду. Tailwind забезпечує повний
контроль над дизайном і добре масштабується.
Бібліотека Lucide React використовується для сучасних іконок, а Recharts –
для візуалізації аналітичних даних (діаграми успішності, розподіл балів, динаміка
прогресу учнів). Таке поєднання дозволяє створити інтуїтивно зрозумілий і
приємний інтерфейс, що є важливим фактором для залучення учнів і викладачів
до регулярного використання системи.
1.5. Постановка задачі
Метою даної кваліфікаційної роботи є проектування та розробка
програмного забезпечення для діагностики дидактичної системи у вигляді
сучасної інтерактивної веб-платформи, яка забезпечить повний цикл взаємодії з
18
ЧДТУ 262357.001 ПЗ
тестовими завданнями: від їх створення до комплексного статистичного аналізу
результатів.
Для досягнення поставленої мети визначено наступні ключові завдання
розробки:
1 Провести системний аналіз предметної області та спроектувати логічну
архітектуру бази даних для ефективного збереження зв'язків між
користувачами, тестами та результатами.
2 Розробити серверну частину (API) для безпечної обробки бізнес-логіки
системи.
3 Створити візуальний конструктор завдань із гнучкою підтримкою різних
типів запитань.
4 Імплементувати клієнтський модуль проходження тестування, який
адаптується під різні пристрої.
5 Розробити алгоритми автоматичної оцінки та систему формування
детальної аналітики успішності для викладача.
6 Впровадити надійну систему авторизації та аутентифікації з жорстким
розмежуванням ролей.
7 Провести тестування розробленого програмного забезпечення на
предмет виявлення помилок (багів) та вразливостей.
Вирішення цих завдань дозволить отримати готовий до впровадження
програмний продукт, що оптимізує процеси педагогічного контролю та відповідає
сучасним стандартам веброзробки.
19
ЧДТУ 262357.001 ПЗ
ВИСНОВОКИ ДО ПЕРШОГО РОЗДІЛУ
У першому розділі проведено комплексний аналіз сучасних методів і засобів
діагностики знань учнів. Було встановлено, що традиційні форми контролю (усне
опитування, письмові роботи, бланкове тестування) вже не відповідають вимогам
сучасного освітнього процесу через значні витрати часу викладача, відсутність
оперативного зворотного зв’язку та обмежені аналітичні можливості.
Огляд провідних цифрових платформ (Moodle, Google Classroom та
Naurok.com.ua) показав, що, незважаючи на їх широке використання, жодна з них
не забезпечує оптимального поєднання зручного сучасного інтерфейсу,
потужного конструктора різноманітних інтерактивних завдань та глибокої
аналітики результатів. Кожна система має суттєві обмеження: Moodle – складність
освоєння та застарілий інтерфейс, Google Classroom – поверхнева аналітика та
обмежений набір типів завдань, Naurok.com.ua – недостатні можливості
кастомізації та експорту даних.
Виявлені проблеми та недоліки існуючих рішень обґрунтовують
актуальність створення нової інтерактивної дидактичної системи. На основі
проведеного аналізу сформовано чіткі архітектурні, функціональні та
нефункціональні вимоги до програмного забезпечення. Обґрунтовано вибір
сучасного технологічного стеку (Next.js, TypeScript, PostgreSQL, Prisma ORM,
Tailwind CSS), який повністю відповідає поставленим завданням і забезпечує
необхідний рівень продуктивності, безпеки та зручності розробки.
20
ЧДТУ 262357.001 ПЗ
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
2.1. Моделювання предметної області
Моделювання предметної області є критично важливим етапом життєвого
циклу розробки програмного забезпечення. Воно дозволяє створити абстрактну
схему системи, визначити межі проекту та встановити чіткі зв’язки між реальними
об’єктами навчального процесу та їх програмною реалізацією.
Для проектування інтерактивної дидактичної системи було проведено
декомпозицію освітнього процесу на окремі функціональні блоки. Основна увага
зосереджена на таких аспектах:
конструктивна діяльність викладача: створення структурованого
контенту та налаштування параметрів оцінювання;
навчальна діяльність учня: інтерактивна взаємодія з інтерфейсом
тестування та отримання миттєвого результату;
аналітична складова: автоматична обробка масивів даних для
формування об’єктивної картини успішності.
Наступним кроком у моделюванні є визначення взаємодії між основними
компонентами системи. Першим компонентом є процес створення тесту
викладачем. Важливим аспектом є зручність конструктора питань різних типів
(одна правильна відповідь, кілька правильних відповідей, встановлення
правильної послідовності). Створений тест зберігається в базі даних і отримує
унікальний код доступу.
Після створення тесту учень отримує доступ до нього за допомогою коду.
Система забезпечує динамічне завантаження питань, фіксацію відповідей у
реальному часі, автоматичну перевірку результатів та збереження даних у базі.
Завершальним етапом є формування результатів тестування та їх відображення як
для учня, так і для викладача у вигляді детальних аналітичних звітів.
21
ЧДТУ 262357.001 ПЗ
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області
Сформуємо словник предметної області (табл. 2.1) та опишемо доменні
об’єкти, які будуть використані при створенні моделі предметної області у вигляді
діаграми класів.
Таблиця 2.1
Словник предметної області
№ Назва (укр.) Назва (англ.) Опис
Інтерфейс, через який
відбувається взаємодія
1 Інтерфейс користувача User Interface
викладача та учня з
системою
Компонент, що відповідає
2 Менеджер тестів Test Manager за створення, редагування
та зберігання тестів
Інструмент для створення
3 Конструктор питань Question Constructor
питань різних типів
Компонент для
Модуль проходження динамічного
4 Test Engine
тесту відображення питань та
фіксації відповідей учня
Модуль автоматичної
Система перевірки
5 Answer Checker перевірки відповідей та
відповідей
розрахунку балів
Компонент збереження,
6 Менеджер результатів Result Manager обробки та відображення
результатів тестування
22
ЧДТУ 262357.001 ПЗ
Продоження таблиці 2.1
Компонент управління доступом
Authentication
7 Система авторизації (ролі: викладач, учень,
Manager
адміністратор)
Analytics Модуль формування статистики
8 Аналітичний модуль
Module та звітів для викладача
Модель предметної області представляє структуру веб-додатка для
діагностики знань учнів. Інтерфейс користувача (User Interface) є первинним
входом для взаємодії. Викладач через менеджер тестів (Test Manager) та
конструктор питань (Question Constructor) створює тестові завдання. Після
створення тест отримує унікальний код доступу.
Учень через модуль проходження тесту (Test Engine) отримує питання,
фіксує відповіді, які передаються до системи перевірки відповідей (Answer
Checker). Після завершення тестування результати зберігаються в менеджері
результатів (Result Manager) і стають доступними як для учня, так і для викладача
через аналітичний модуль (Analytics Module). Система авторизації (Authentication
Manager) забезпечує розмежування прав доступу.
Таким чином, додаток інтегрує компоненти для створення, проходження,
автоматичної перевірки та аналізу результатів тестування, забезпечуючи повний
цикл діагностики знань учнів.
2.1.2. Елеманти моделювання предментної області
Словник ключових понять предметної області формалізує термінологію,
необхідну для розуміння процесів інтерактивної дидактичної системи. На відміну
від технічної структури модулів, цей розділ описує концептуальні об’єкти
системи, що визначають її змістовну частину та правила взаємодії користувачів із
контентом. Він слугує основою для проєктування бази даних та діаграми класів.
Таблиця 2.2
23
ЧДТУ 262357.001 ПЗ
Словник основних понять предметної області
№ Назва (укр.) Назва (англ.) Опис об’єкта
Особа, зареєстрована в системі
1 Користувач User
(викладач, учень або адміністратор)
Автор контенту, який створює та
2 Викладач Teacher редагує тести, генерує коди доступу
та аналізує результати
Здобувач освіти, який проходить
3 Учень Student тести за кодом доступу та переглядає
свої результати
Логічно об’єднаний набір питань з
4 Тест Test
налаштуваннями оцінювання
Атомарна одиниця тесту (одна
правильна відповідь, множинний
5 Питання Question
вибір, встановлення послідовності
тощо)
Унікальний ідентифікатор, за
6 Код доступу Access Code допомогою якого учень отримує
доступ до тесту
Один сеанс проходження тесту
7 Спроба Attempt
конкретним учнем
Підсумковий бал та деталізація
8 Результат Result
помилок після завершення спроби
Для глибшого розуміння моделі розглянемо логіку взаємодії цих сутностей.
Рольова модель – система чітко розмежовує права доступу залежно від ролі
користувача. Викладач має можливість створювати та редагувати тести, тоді як
учень може лише проходити їх через створення спроби.
Структура контенту – кожен тест виступає контейнером для питань.
Питання не існують поза контекстом тесту і містять варіанти відповідей. Для
24
ЧДТУ 262357.001 ПЗ
початку роботи учня система генерує унікальний код доступу, який прив’язує
конкретного учня до певної версії тесту.
Процес діагностики – під час проходження тесту система фіксує спробу.
Після її завершення об’єкт спроби перетворюється на результат, який містить
розрахункові бали та метадані (час проходження, кількість помилок). Ці дані
стають основою для роботи аналітичного модуля системи.
Таким чином, словник предметної області визначає логічну структуру
інформації, яка зберігатиметься в базі даних, і описує правила функціонування
всієї інтерактивної платформи.
2.1.3. Робоча область моделювання
Робоча область моделювання відображає реальне середовище, в якому
працюватиме розроблювана система. У даному випадку це сучасний веб-додаток,
реалізований на базі Next.js з використанням TypeScript, Prisma ORM та
PostgreSQL.
Після авторизації викладач потрапляє до особистого кабінету, де може
створювати тести. За допомогою зручного конструктора він формує питання
різних типів, збирає їх у тест і отримує унікальний код доступу.
Учень, отримавши цей код, заходить на сторінку проходження тесту.
Система динамічно завантажує питання, фіксує відповіді в реальному часі та після
завершення автоматично перевіряє результат. Викладач у своєму кабінеті може
переглядати детальну статистику по кожному тесту та учню.
Також, користувачі мають можливість змінювати налаштування профілю,
переглядати історію тестування та аналізувати ефективність навчального процесу.
Таким чином, робоча область моделювання охоплює повний цикл створення,
проходження та аналізу результатів тестування в єдиному сучасному веб-
середовищі.
2.2. Формування та аналіз вимог
Процес формування вимог є одним із найвідповідальніших етапів
25
ЧДТУ 262357.001 ПЗ
проектування, оскільки саме на цьому етапі закладається функціональний
фундамент майбутньої системи. Чітке визначення потреб замовника та технічних
можливостей розробника дозволяє уникнути логічних помилок при
архітектурному проектуванні бази даних та програмних модулів. Аналіз вимог до
інтерактивної дидактичної системи проводився з урахуванням специфіки
освітнього процесу, де ключовими факторами є простота використання для
вчителя та надійність фіксації результатів для учня.
2.2.1. Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробка. Функціональні і нефункціональні вимоги.
Формування вимог до програмного забезпечення. Для початку було
сформовано первинні вимоги, які описують загальне бачення продукту.
Інтерактивна дидактична система призначена для функціонування у веб-
середовищі та повинна пропонувати комплексний інструментарій, орієнтований
на створення, проходження та глибокий аналіз результатів навчальних завдань.
Основний акцент ставиться на автоматизації рутинних процесів перевірки знань
та забезпеченні оперативного доступу до навчального контенту.
Первинні і детальні вимоги. Наступним кроком стало визначення вимог
замовника. У контексті дидактичної системи замовником виступає освітня
установа або безпосередньо викладач. Головна вимога полягає в тому, щоб веб-
платформа забезпечувала повний і замкнений цикл діагностики знань: від
проектування тестових завдань різного ступеня складності до автоматичної
обробки статистичних даних. Система має бути автономною, не потребувати
встановлення сторонніх плагінів чи специфічного програмного забезпечення на
стороні клієнта, а також бути доступною з будь-якої точки світу, де є підключення
до мережі Інтернет.
Вимоги замовника і розробка. Вимоги розробника є технічною
деталізацією очікувань замовника. Вони включають опис внутрішніх механізмів
системи:
26
ЧДТУ 262357.001 ПЗ
– реалізація надійної схеми авторизації з чітким розмежуванням ролей
(Role-Based Access Control) [19];
– створення гнучкого конструктора питань, що дозволяє працювати з
різними типами даних;
– забезпечення цілісності даних при великій кількості одночасних запитів
до бази даних PostgreSQL;
– гарантування сумісності з сучасними браузерами та захист від
несанкціонованого доступу до відповідей тестів.
Функціональні вимоги.
Функціональні вимоги визначають безпосередні дії, які користувачі можуть
виконувати в системі. Для деталізації логіки роботи та структурування
архітектури, розіб’ємо їх на спеціалізовані модулі:
1 Модуль керування контентом та адміністрування (для Викладача):
– система авторизації та профілів: можливість створення облікового
запису та входу через захищені канали зв'язку;
– інтерактивний конструктор тестів: надання викладачеві
інструментарію для створення нових дидактичних одиниць, додавання назв,
описів та встановлення часових обмежень;
– підтримка типів питань: реалізація логіки для питань з однією
правильною відповіддю (Single Choice), декількома варіантами (Multiple Choice)
та завданнями на встановлення логічної послідовності (Order);
– керування доступом: генерація унікальних шестизначних кодів
доступу для кожного тесту, що дозволяє швидко ділитися завданням без
необхідності додавати учнів у базу вручну.
2 Модуль тестування та клієнтської взаємодії (для Учня):
– анонімний та ідентифікований доступ: можливість входу в тест за
кодом, що мінімізує бар’єр для початку діагностики;
– динамічний інтерфейс тестування: відображення питань у
покроковому режимі, що дозволяє учню зосередитися на конкретному завданні, та
наявність індикатора прогресу;
27
ЧДТУ 262357.001 ПЗ
– серверна валідація: автоматичне надсилання відповідей на сервер для
миттєвого підрахунку балів після завершення сесії.
3 Модуль аналітики та візуалізації даних:
– централізований журнал оцінок: відображення всіх спроб
проходження тесту в єдиній таблиці з можливістю фільтрації за датою чи іменем
учня;
– графічна звітність: візуалізація успішності групи за допомогою
діаграм, що демонструють розподіл оцінок та найбільш проблемні питання, де
було допущено найбільше помилок.
Нефункціональні вимоги.
Нефункціональні вимоги описують якісні характеристики системи, її
надійність, продуктивність та обмеження, в яких вона повинна стабільно
працювати:
1 Продуктивність та швидкість відгуку: система повинна забезпечувати
високу швидкість завантаження сторінок (час відповіді сервера не більше 2
секунд). Перехід між питаннями під час тестування має бути миттєвим завдяки
клієнтському рендерингу.
2 Надійність та збереження даних: платформа повинна автоматично
зберігати стан проходження тесту. У разі раптового розриву інтернет-з'єднання
або випадкового оновлення сторінки, учень повинен мати змогу продовжити з
того місця, де він зупинився.
3 Кросбраузерність та адаптивність: платформа має бути повністю сумісна
з сучасними веб-браузерами (Google Chrome, Mozilla Firefox, Microsoft Edge,
Apple Safari). Інтерфейс повинен бути адаптивним (Responsive Design),
забезпечуючи коректне відображення та зручну роботу як на стаціонарних
комп’ютерах, так і на планшетах чи смартфонах.
4 Безпека та захист інформації: усі персональні дані користувачів,
включаючи паролі, мають зберігатися у зашифрованому вигляді (використання
алгоритму bcrypt) [20]. Класифікація та перевірка відповідей повинна відбуватися
28
ЧДТУ 262357.001 ПЗ
виключно на стороні сервера (Backend), щоб унеможливити маніпуляції з кодом
на стороні клієнта для штучного завищення балів.
5 Масштабованість: архітектура системи повинна дозволяти легке
додавання нових типів завдань (наприклад, відкриті питання або drag-and-drop)
без глобальної зміни структури бази даних.
2.2.2. Формування вимог за допомогою діаграм прецедентів
Одним із ефективних підходів до формування вимог є побудова діаграм
прецедентів (Use Case Diagrams). Декомпозиція функціональності системи за
ролями користувачів дозволяє чітко визначити основні сценарії взаємодії та
розподілити обов’язки між акторами.
На рисунку 2.1 наведено загальну діаграму прецедентів інтерактивної
дидактичної системи, яка відображає три основні ролі: вчитель, учень та
адміністратор.
Система має три основні актори, кожен з яких виконує чітко визначені
функції.
Вчитель є ключовим користувачем, відповідальним за створення та
управління навчальним контентом. Він може:
створювати нові тести з підтримкою різних типів питань (одна правильна
відповідь, кілька правильних відповідей, встановлення хронологічної
послідовності);
редагувати профіль викладача;
додавати власні навчальні матеріали;
експортувати результати тестування;
редагувати та видаляти тести;
переглядати навчальні матеріали;
переглядати результати учнів.
Учень орієнтований на самостійне навчання та самоперевірку знань. Його
основні прецеденти включають:
перегляд навчальних матеріалів;
29
ЧДТУ 262357.001 ПЗ
Рисунок 2.1 – Діаграма прецедентів інтерактивної дидактичної системи
30
ЧДТУ 262357.001 ПЗ
проходження тестів;
перегляд власних результатів і прогресу;
редагування профілю;
зміну мови інтерфейсу сайту.
Адміністратор має найвищий рівень доступу та відповідає за загальне
управління системою. До його функцій належать:
додавання офіційних навчальних матеріалів;
модерація тестів і матеріалів, створених викладачами;
призначення ролей викладачам;
керування акаунтами користувачів;
перегляд загальної аналітики сайту;
налаштування інтерфейсу та дизайну;
керування структурою розділів і тем відповідно до освітніх стандартів;
забезпечення безпеки та стабільності платформи.
Такий розподіл прецедентів забезпечує чітке розмежування прав доступу та
функціональних обов’язків. Учень отримує комфортне середовище для
самостійного навчання та самоконтролю, викладач – потужні інструменти для
створення контенту та моніторингу навчального процесу, а адміністратор – повний
контроль над якістю, актуальністю та безпекою всієї системи.
Для кращої структуризації системи було також використано пакети
(Packages). На рисунку 2.2 наведено діаграму прецедентів з пакетами.
Система розділена на чотири основні пакети:
навчальний контент – робота з текстами, хронологією, інфографікою,
відео та результатами;
тестування – створення, редагування та проходження тестів;
адміністрування – модерація, керування користувачами, налаштування
системи;
інтерфейс – UI-компоненти, зміна мови, прогрес навчання.
Використання пакетів дозволяє логічно групувати прецеденти, спрощує
розуміння системи та полегшує подальше проєктування та розробку.
31
ЧДТУ 262357.001 ПЗ
Рисунок 2.2 – Діаграма прецедентів інтерактивної дидактичної системи (з
пакетами)
32
ЧДТУ 262357.001 ПЗ
2.3. Проектування логічної структури програмного комплексу
2.3.1. Діаграма класів
Наступним етапом проєктування є побудова діаграми класів, яка відображає
основні сутності системи, їхній внутрішній вміст та логічні зв’язки між ними. Для
кращого розуміння архітектури та деталізації розробки цей процес було розділено
на два етапи: проектування концептуальної моделі (без атрибутів) та проектування
детальної інженерної моделі (з атрибутами та методами).
На рисунку 2.3 представлено діаграму класів інтерактивної дидактичної
системи без атрибутів, яка демонструє загальний каркас платформи та типи
відносин між сутностями.
Рисунок 2.3 – Діаграма класів інтерактивної дидактичної системи без атрибутів
На концептуальному рівні виділено такі основні класи системи:
користувач – базовий абстрактний клас, який об'єднує спільні логічні
ознаки всіх суб'єктів системи;
учень – підклас, що представляє користувача, який проходить
тестування та вивчає контент;
33
ЧДТУ 262357.001 ПЗ
вчитель – підклас, який наділений функціями створення та перевірки
дидактичних одиниць;
адміністратор – підклас із найвищим рівнем доступу для модерації та
конфігурації платформи;
навчальний матеріал – сутність, що відповідає за збереження та
структурування лекційних або допоміжних файлів;
тест – центральний модуль діагностики знань, призначений для
перевірки успішності;
питання – атомарний компонент, з якого формується кожен окремий
іспит або опитування;
результат тесту – сутність, що фіксує метрику успішності та відповіді
учня.
На діаграмі класів без атрибутів чітко вказано архітектурні зв’язки:
наслідування (від класу Користувач до класів Учень, Вчитель та Адміністратор),
композиція (Тест містить у собі класи Питання, які не можуть існувати окремо від
самого тесту), а також асоціації та агрегації, що відображають взаємодію
користувачів із навчальним контентом.
Для детального опису логіки, визначення типів змінних та методів обробки
даних було розроблено розширену схему. На рисунку 2.4 представлено діаграму
класів з атрибутами та методами.
Опис внутрішньої структури та функціональної поведінки об'єктів системи:
користувач містить базові змінні id (ідентифікатор), ім'я, email,
зашифрований пароль, посилання на аватар профілю та мову інтерфейсу системи.
Клас оперує методами аутентифікації користувача, редагування даних профілю та
динамічної зміни мови;
учень наслідує властивості базового користувача, додаючи специфічні
змінні класу, назви навчального закладу та загального відсотка прогресу
успішності. Містить методи для перегляду призначених матеріалів,
безпосереднього проходження тестів та моніторингу власного прогресу;
34
ЧДТУ 262357.001 ПЗ
Рисунок 2.4 – Діаграма класів інтерактивної дидактичної системи
35
ЧДТУ 262357.001 ПЗ
вчитель розширює базовий клас атрибутами викладацького предмета та
масивом підконтрольних класів. Реалізує методи створення й редагування тестів,
призначення завдань на класи, додавання нових дидактичних матеріалів, а також
перегляду й каскадного експорту результатів учнів;
адміністратор володіє методами глобального адміністрування системи,
такими як керування акаунтами, модерація всього створеного контенту, додавання
офіційних навчальних планів, перегляд системної аналітики сайту та
налаштування графічного інтерфейсу платформи;
навчальний матеріал описується унікальним id, темою, цільовим класом,
вмістом та типом матеріалу (текст, відео, інфографіка). Має методи для
відображення учням та редагування вчителем;
тест зберігає назву іспиту, тему, дедлайн для проходження та посилання
на автора (вчителя). Підтримує методи ініціалізації, редагування та призначення
для перевірки знань;
питання містить текст завдання, масив варіантів відповідей (або
правильну відповідь для автоматичної перевірки), пояснення до помилок та тип
питання (одиночний вибір, відповідність, хронологія тощо);
результат тесту акумулює підсумкову оцінку, масив наданих відповідей
учня та часову мітку виконання сесії, що дозволяє формувати індивідуальні звіти
успішності.
Використання двоекранного підходу до проєктування (розділення на
концептуальну модель та модель з атрибутами) дозволило спочатку зафіксувати
логіку взаємодії без перевантаження деталями, а потім сформувати точну
інженерну специфікацію для генерації моделей даних і міграцій через Prisma
ORM, що усунуло архітектурні помилки на етапі написання коду.
2.3.2. Діаграма пакетів
Для високорівневого структурування архітектури освітньої платформи та
організації її модулів було розроблено діаграму пакетів, зображено на рисунку 2.5.
Вона дозволяє згрупувати логічно пов’язані елементи системи, мінімізувати
36
ЧДТУ 262357.001 ПЗ
зв'язність між підсистемами та визначити зони відповідальності для кожного
функціонального блоку.
Рисунок 2.5 – Діаграма пакетів
Логічна структура системи розподілена на чотири основні пакети:
навчальний контент – об'єднує модулі, що відповідають за збереження,
структурування та відображення теоретичної бази знань. Сюди входять
підкомпоненти для роботи з текстовими розділами, хронологічними картами,
інфографікою та відеоуроками, а також підсистеми відображення поточних
результатів та призначених для класів тестів;
тестування – є центральним ядром діагностичного середовища. Пакет
містить підмодулі генерації тестів та логіку обробки запитань різних дидактичних
типів (вибір однієї або кількох правильних відповідей, встановлення
відповідностей, відкриті текстові питання, завдання на визначення хронологічної
послідовності та вставку пропущених слів);
адміністрування – відповідає за глобальне керування платформою та
безпеку даних. Охоплює функціонал моніторингу та налаштування системи,
37
ЧДТУ 262357.001 ПЗ
модерацію створеного контенту, збір аналітичних даних роботи сайту, а також
модуль керування обліковими записами користувачів із гнучким розподілом ролей;
інтерфейс – представляє клієнтський рівень взаємодії користувача з
системою. Містить набір перевикористовуваних UI-компонентів, логіку
динамічної зміни мови інтерфейсу для забезпечення локалізації, а також віджети
для візуалізації прогресу навчання студентів.
Взаємозв'язки між пакетами відображають архітектурні потоки керування та
передачі даних. Пакет адміністрування здійснює конфігурацію інтерфейсних
компонентів та глобальний контроль за процесами тестування, тоді як результати
взаємодії користувачів із навчальним контентом безпосередньо впливають на
діагностичні алгоритми модуля тестування.
Таке пакетне групування забезпечує високу модульність програмного
продукту, спрощує розробку окремих сервісів та гарантує легкість підтримки і
масштабування системи при додаванні нових дидактичних інструментів.
2.4. Архітектурне проектування
2.4.1. Діаграма компонентів та логічна архітектура
Одним із ключових етапів проектування веб-додатку є формування його
високорівневої архітектури, яка визначає взаємодію основних вузлів системи. На
рисунку 2.6 зображено базову архітектуру взаємодії компонентів.
Основні елементи архітектури:
клієнтський пристрій (Frontend-компонент) – представлений браузером
(HTML, CSS, JS), через який користувач взаємодіє з системою. Відповідає за
рендеринг інтерфейсу та валідацію даних на стороні клієнта;
сервер застосунку (Backend-компонент) – реалізований на базі Node.js +
Express.js (або Next.js API). Цей компонент є ядром системи: він обробляє HTTP-
запити від клієнта, реалізує бізнес-логіку перевірки тестів, управляє сесіями та
авторизацією (через JWT) ;
38
ЧДТУ 262357.001 ПЗ
сервер бази даних – представлений реляційною СУБД PostgreSQL.
Відповідає за надійне зберігання інформації про користувачів, структуру тестів,
навчальні матеріали та результати проходження.
Рисунок 2.6 – Діаграма компонентів
Такий розподіл на незалежні рівні (клієнт, сервер, база даних) забезпечує
гнучкість розробки. Якщо в майбутньому виникне потреба змінити дизайн
інтерфейсу, це не вплине на логіку роботи бази даних чи серверного API.
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Для забезпечення стабільної роботи системи в мережі Інтернет необхідно
спроектувати фізичну топологію розгортання програмних вузлів. На рисунку 2.7
наведено діаграму розгортання платформи.
39
ЧДТУ 262357.001 ПЗ
Рисунок 2.7 – Діаграма розгортання
Опис вузлів (Nodes) та компонентів розгортання:
користувацький пристрій – апаратний засіб (ПК, планшет або смартфон),
на якому виконується Web-браузер. Зв'язок із сервером відбувається через
безпечний протокол HTTPS, що гарантує шифрування даних (наприклад, паролів
та результатів тестів);
хмарний сервер (AWS / Hetzner / VPS) – головний фізичний або
віртуальний вузол, на якому розгортається інфраструктура проекту. Операційною
системою виступає Ubuntu 22.04 або Debian;
веб-сервер Nginx [21]: виконує роль "reverse proxy" (зворотного проксі).
Він приймає всі зовнішні запити, забезпечує SSL-шифрування (за допомогою
сертифікатів Let's Encrypt) і перенаправляє динамічні запити до Node.js процесу, а
також безпосередньо віддає статичні файли для прискорення завантаження;
node.js процес – середовище виконання бекенду. Для підтримки
безперебійної роботи та автоматичного перезапуску у разі збоїв використовується
менеджер процесів PM2 [22];
postgreSQL – сервер бази даних, розгорнутий у захищеному контурі
хмарного сервера;
40
ЧДТУ 262357.001 ПЗ
файлове сховище / CDN: компоненти для зберігання та швидкої доставки
"важкого" контенту (відеоматеріалів, PDF-документів, зображень для завдань).
Така конфігурація є стандартом для сучасних веб-додатків. Вона дозволяє
легко масштабувати систему при збільшенні кількості одночасних підключень
учнів під час масових тестувань.
2.5. Моделювання поведінки системи
2.5.1. Діаграма діяльності
Діаграма діяльності дозволяє візуалізувати алгоритм роботи системи з точки
зору конкретного бізнес-процесу. На рисунку 2.8 змодельовано процес
проходження тесту учнем.
Рисунок 2.8 – Діаграма діяльності
41
ЧДТУ 262357.001 ПЗ
Опис алгоритму (потоку дій):
1 Учень заходить на сайт та проходить процес авторизації.
2 Після успішного входу користувач переходить до розділу «Тести» та
обирає призначений йому тест.
3 Система приймає рішення (Decision node), перевіряючи дедлайн. Якщо
час виконання вичерпано, виводиться повідомлення "Тест недоступний", і процес
завершується.
4 Якщо тест доступний, відкривається сторінка тестування. Учень
послідовно читає питання та обов'язково обирає відповіді.
5 Після натискання кнопки «Здати тест» потік розгалужується на
паралельні процеси (Fork node):
система миттєво та автоматично перевіряє питання закритого типу;
відкриті питання (якщо вони є) акумулюються та відправляються
вчителю на ручну перевірку.
6 Потоки об'єднуються (Join node), після чого формується фінальний
результат (бали та відсоток успішності).
7 Дані зберігаються в базу, після чого учень бачить свою оцінку та розбір
помилок. Цикл завершується поверненням до списку тестів.
Ця діаграма критично важлива для розробки Frontend-частини, оскільки
вона чітко визначає, які екрани (UI-стани) мають послідовно змінюватися в
процесі взаємодії.
2.5.2. Діаграма послідовності
Для детального розуміння обміну повідомленнями між об'єктами системи в
часі було розроблено дві діаграми послідовності.
Перша діаграма на рисунку 2.9 описує життєвий цикл сесії учня: від логіну
до збереження результатів.
42
ЧДТУ 262357.001 ПЗ
Рисунок 2.9 – Діаграма послідовності «Учень»
авторизація: клієнт відправляє POST-запит на маршрут /auth/login.
Бекенд перевіряє дані в БД і, у разі успіху, JWT Service генерує токен доступу;
отримання тестів: frontend робить GET-запит /tests/available,
прикріплюючи JWT-токен у заголовки. База даних повертає масив призначених
тестів;
збереження результату: після завершення тесту Frontend надсилає POST-
запит на /tests/:id/submit із масивом відповідей. Бекенд проводить розрахунок балів
і записує результат у БД, повертаючи клієнту оброблений об'єкт результату.
Друга діаграма на рисунку 2.9 описує життєвий цикл сесії вчителя
43
ЧДТУ 262357.001 ПЗ
Рисунок 2.10 – Діаграма послідовності «Вчитель»
вчитель ініціює подію через форму на Frontend. Відправляється запит до
TestController;
контролер викликає бізнес-логіку через TestService (метод assignTest);
сервіс тестів звертається до UserService, щоб отримати список учнів
конкретного класу (getStudentsByClass);
після отримання списку, в БД створюються відповідні записи про
призначення. За ланцюжком об'єктів на Frontend повертається статус "200 OK" із
повідомленням "Тест успішно призначено X учням".
Таке моделювання дозволяє ізолювати логіку контролерів від сервісів, що
спрощує подальше написання автоматизованих тестів для бекенду.
2.5.3. Діаграма комунікації
Оскільки діаграма послідовності та діаграма комунікації є семантично
еквівалентними в UML (обидві належать до діаграм взаємодії), при проектуванні
веб-додатка основний акцент було зроблено саме на діаграмах послідовності.
Вони краще відображають асинхронну природу HTTP-запитів та часову
послідовність виконання функцій між клієнтом, сервером і базою даних, що є
особливо важливим для REST API архітектури.
44
ЧДТУ 262357.001 ПЗ
У зв’язку з цим окрема діаграма комунікації в даній роботі не розроблялася,
оскільки не несла суттєвої додаткової інформації порівняно з уже наявними
діаграмами послідовності.
2.5.4. Діаграма скінченного автомату
Складовою частиною проектування бізнес-логіки є визначення станів
ключових сутностей. Для дидактичної системи найскладнішим об'єктом є «Тест».
На рисунку 2.11 показана діаграма станів для цієї сутності.
Рисунок 2.11 – Життєвий цикл тесту
45
ЧДТУ 262357.001 ПЗ
Життєвий цикл тесту включає наступні стани:
створений (Created): початковий стан. Тест існує в базі, але не має
призначень;
призначений (Assigned): вчитель прив'язав тест до конкретних учнів або
класу. У цьому стані вчитель ще може редагувати контент або відкликати
призначення;
доступний (Available): настає час початку тестування (якщо встановлено
таймер) або тест просто стає видимим для учня;
в процесі (In Progress): учень відкрив тест і почав надсилати відповіді. У
цьому стані система активно контролює дедлайн та фіксує проміжні результати;
завершений (Completed): учень натиснув кнопку здачі, або вийшов час;
оцінений (Graded): система (або вчитель вручну) розрахувала бали. Стає
доступним детальний розбір помилок;
архівний (Archived): кінцевий стан. Результат закріплено в прогресі учня,
тест більше не доступний для проходження в рамках поточної сесії.
Чітке визначення цих станів на етапі проектування унеможливлює
виникнення логічних помилок (наприклад, ситуації, коли учень намагається
змінити відповіді в "Оціненому" тесті).
46
ЧДТУ 262357.001 ПЗ
ВИСНОВОКИ ДО ДРУГОГО РОЗДІЛУ
В процесі об'єктно-орієнтованого аналізу та проектування інтерактивної
дидактичної системи було побудовано комплекс UML-моделей. Моделювання
предметної області (діаграма класів) дозволило спроектувати майбутню структуру
реляційної бази даних PostgreSQL. Побудова діаграм прецедентів допомогла чітко
розмежувати ролі (Вчитель, Учень, Адміністратор) та їхні права.
Розроблені діаграми розгортання та компонентів підтвердили можливість
реалізації системи за допомогою сучасного стеку технологій (Next.js, Node.js), а
діаграми поведінки (діяльності, послідовності та станів) деталізували алгоритми
роботи найскладніших модулів – авторизації (через JWT) та процесу тестування.
Проведений етап проектування доводить, що закладена архітектура є
масштабованою, надійною та повністю готовою до етапу безпосереднього
кодування (імплементації), що суттєво знизить ризик виникнення архітектурних
помилок під час розробки.
47
ЧДТУ 262357.001 ПЗ
РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
У цьому розділі розглядається процес практичної реалізації та верифікації
програмного забезпечення для діагностики дидактичної системи. Розробка
охоплює обґрунтування вибору технологічного стеку, проєктування архітектури
бази даних, побудову клієнт-серверної логіки та створення інтерфейсу
користувача. Окрему увагу приділено методам тестування системи для
забезпечення надійності та коректності аналізу результатів навчання.
3.1. Розробка програмного комплексу
Процес розробки платформи базується на створенні гнучкого середовища,
яке дозволяє викладачам керувати навчальним контентом, а студентам –
проходити діагностику знань. Основний акцент зроблено на швидкодії інтерфейсу
та цілісності даних при обробці великої кількості запитів.
3.1.1. Обґрунтування вибору засобів реалізації
Для реалізації проєкту було обрано сучасний стек технологій, що забезпечує
високу продуктивність та типізацію на всіх рівнях розробки:
1 Next.js (React Framework) – обраний як основний фреймворк для
розробки full-stack застосунку. Він дозволяє поєднувати серверний рендеринг для
оптимізації швидкості та клієнтську інтерактивність. Використання App Router
дозволяє ефективно структурувати складну логіку платформи.
2 TypeScript – забезпечує статичну типізацію коду, що критично важливо
для освітньої платформи, де помилки в типах даних (наприклад, балах або ID
користувачів) можуть призвести до некоректної діагностики.
3 Prisma ORM – використана як інструмент для взаємодії з базою даних.
Вона забезпечує безпеку запитів та автоматичну генерацію типів на основі схеми
БД, що пришвидшує розробку модулів управління тестами.
48
ЧДТУ 262357.001 ПЗ
4 PostgreSQL – потужна реляційна СУБД, обрана за її надійність та
підтримку складних зв'язків між сутностями (користувачі, тести, запитання,
результати).
5 Tailwind CSS – фреймворк для стилізації, який дозволив створити
адаптивний інтерфейс панелі адміністратора та кабінетів користувачів без
написання громіздкого CSS-коду.
6 Firebase / Cloudinary – інтегровані для забезпечення хмарного зберігання
медіафайлів (зображень до тестів) та надійної аутентифікації користувачів.
Вибір Visual Studio Code як основного інструменту розробки зумовлений
його високою продуктивністю та широкою екосистемою розширень, що критично
важливо для роботи з TypeScript та Next.js. Використання даного середовища
сприяло значному прискоренню процесу написання коду завдяки вбудованим
інструментам інтелектуального аналізу (IntelliSense), автоматичного доповнення
та миттєвої перевірки синтаксичних помилок. Інтегрований термінал та вбудована
підтримка систем контролю версій (Git) дозволили ефективно керувати життєвим
циклом розробки без перемикання між різними прикладними програмами.
Гнучкість налаштування робочого простору та велика кількість доступних
плагінів (зокрема для Prisma ORM та Tailwind CSS) забезпечили створення
комфортного та ергономічного середовища для реалізації складних архітектурних
рішень.
Для надійного збереження та структурованого керування даними в проєкті
було використано базу даних PostgreSQL. Вона є потужною об'єктно-реляційною
системою керування базами даних (СКБД) з відкритим вихідним кодом, що
зарекомендувала себе як еталон надійності та відповідності стандартам ACID
(атомарність, узгодженість, ізольованість, довговічність).
Використання PostgreSQL дозволило ефективно організувати складну
структуру даних освітньої платформи, включаючи профілі користувачів,
деревоподібні структури дидактичних матеріалів, результати тестувань та
системні логи. Завдяки надійній та масштабованій архітектурі, дана СКБД
49
ЧДТУ 262357.001 ПЗ
забезпечує стабільну роботу системи навіть за умов значного зростання обсягів
інформації та великої кількості одночасних запитів від користувачів.
За допомогою PostgreSQL реалізовано широкий спектр операцій з даними,
що включає не лише стандартні CRUD-запити, а й складні агрегації для побудови
аналітичних звітів успішності. Особлива увага була приділена механізмам
забезпечення цілісності даних на рівні зовнішніх ключів та обмежень (constraints).
Система також підтримує сучасні протоколи безпеки та гнучкі механізми
автентифікації, що гарантує захист конфіденційної інформації учнів та викладачів
від несанкціонованого доступу.
Узагальнюючи вищесказане, поєднання сучасного середовища розробки
Visual Studio Code та потужної СКБД PostgreSQL дозволило створити
технологічно зрілий програмний продукт. Обраний інструментарій повністю
відповідає функціональним вимогам проєкту, забезпечуючи високу швидкість
відгуку веб-сайту, відмовостійкість збереження даних та зручність подальшої
підтримки і модернізації системи.
3.1.2. Опис структурної (функціональної) схеми
Структурна схема на рисунку 3.1 відображає ієрархію модулів та технічний
стек, що забезпечує роботу системи. Вона базується на трирівневій архітектурі:
рівень представлення (Frontend), рівень бізнес-логіки (Backend) та рівень
збереження даних (Database).
Опис компонентів схеми:
frontend (Рівень представлення) – реалізований на базі React та Next.js.
Включає клієнтські компоненти для взаємодії з користувачем: форми
аутентифікації, конструктор тестів, інтерактивні дашборди та адаптивні
інтерфейси, стилізовані за допомогою Tailwind CSS;
backend (Рівень логіки) – серверна частина системи, що використовує
Server Actions та API Routes фреймворку Next.js. Відповідає за обробку запитів,
валідацію даних, перевірку прав доступу (RBAC) та взаємодію з хмарними
сервісами Firebase та Cloudinary;
50
ЧДТУ 262357.001 ПЗ
Рисунок 3.1 – Структурна схема додатку
database (Рівень даних) – об’єктно-реляційна база даних PostgreSQL, що
працює через прошарок Prisma ORM. Містить структуровані таблиці для
зберігання профілів, дидактичного контенту та результатів діагностики.
Функціональна схема на рисунку 3.2 ілюструє динаміку процесів у системі:
від моменту введення даних користувачем до їх обробки та збереження. Вона
фокусується на методах та функціях, що забезпечують працездатність платформи.
Логіка функціональної схеми:
1 Frontend (Взаємодія та подання):
renderUI() – відображення інтерфейсу відповідно до ролі
(Student/Teacher/Admin);
handleUserInput() – збір даних з полів вводу (відповіді на тести,
налаштування модерації);
sendRequest() – надсилання запитів до сервера через захищені канали.
2 Backend (Обробка та координація):
51
ЧДТУ 262357.001 ПЗ
validateSession() – перевірка токена користувача через Firebase Auth;
processBusinessLogic() – виконання алгоритмів оцінювання
відповідей або логіки каскадного видалення;
prismaClientInterface() – формування SQL-запитів до бази даних у
безпечному режимі.
3 Database (Збереження та цілісність):
crud operations – виконання операцій створення, читання, оновлення
та видалення даних;
enforceConstraints – автоматична перевірка цілісності даних.
Рисунок 3.2 – Функціональна схема додатку
52
ЧДТУ 262357.001 ПЗ
3.1.3. Опис логічної схеми системи
Для опису логічної схеми системи на рисунку 3.3 програмного забезпечення
діагностики дидактичної системи використано алгоритмічний опис та блок-схему
маршрутизації запитів і розподілу прав доступу.
Рисунок 3.3 – Блок-схема логіки роботи платформи діагностики знань
Логічна схема системи описує основні інформаційні процеси та алгоритми
доступу, які відбуваються на платформі залежно від статусу користувача:
отримання запиту на взаємодію: система отримує HTTP-запит від
клієнта (користувача) на доступ до певного маршруту або виконання дії на
платформі;
автентифікація та перевірка ролі: система перевіряє наявність валідного
токена сесії. Якщо користувач авторизований, визначається його рівень доступу
(Admin, Teacher або Student);
53
ЧДТУ 262357.001 ПЗ
обробка запитів адміністратора: якщо ідентифіковано адміністратора,
система надає доступ до захищених маршрутів: панелі управління профілями,
зміни прав доступу, а також загального моніторингу та видалення будь-яких тестів
у системі;
обробка запитів викладача: якщо користувач є викладачем, система
завантажує інтерфейс конструктора дидактичних матеріалів (тестів) та відкриває
доступ до аналітичних дашбордів для відстеження успішності учнів;
обробка запитів студента: якщо користувач має роль учня, система
відкриває доступ до списку доступних діагностичних завдань та інтерфейсу
проходження тестування з механізмом фіксації результатів;
виконання транзакцій бази даних: залежно від гілки логіки, система
виконує відповідні звернення до PostgreSQL через Prisma ORM (збереження
відповідей, розрахунок балів, або каскадне видалення пов'язаних даних);
відображення сторінки авторизації (Fallback): якщо користувач не
авторизований або запитує інформацію, яка не відповідає його ролі (наприклад,
студент намагається зайти в панель адміністратора), система блокує запит і
перенаправляє на сторінку входу або головну сторінку.
Ця логічна схема дозволяє чітко розуміти алгоритм розподілу прав доступу
та послідовність дій, які виконує бекенд для забезпечення безпеки даних та
коректної роботи освітнього процесу.
3.1.4. Розробка бази даних
Для забезпечення надійної роботи системи було спроєктовано реляційну
базу даних на базі PostgreSQL. Проєктування здійснювалося з урахуванням
специфіки дидактичної діагностики, де ключовими сутностями є не лише
користувачі та тести, а й навчальні матеріали та категорії.
Основними завданнями бази даних системи є:
управління профілями – зберігання даних користувачів із підтримкою
ролей (student, teacher, admin) та прив'язкою до навчальних класів (grade);
54
ЧДТУ 262357.001 ПЗ
гнучка система тестування: реалізація тестів із унікальними кодами
доступу та різними типами запитань;
зберігання контенту – організація бази знань через ресурси та матеріали,
інтегровані з хмарним сховищем Cloudinary;
цілісність даних – використання механізму onDelete: Cascade для
автоматичного очищення пов'язаних записів (наприклад, видалення всіх запитань
та результатів при видаленні тесту).
База даних складається з 8 взаємопов'язаних таблиць. Їх опис наведено в
таблиці 3.1.
Таблиця 3.1
Опис таблиць бази даних
Назва таблиці Призначення Ключові поля
id, email, password, role,
User Дані користувачів та їх ролі
grade, image
Параметри діагностичних id, title, code, timeLimit,
Test
тестів passScore, teacherId
id, text, type, correct
Question Питання тестів різних типів
(Json), testId
Option Варіанти відповідей до питань id, text, questionId
id, score, passed, duration,
Result Статистика проходження тестів
answers (Json)
Тематична класифікація
Category id, name, slug
контенту
Навчальні матеріали id, title, type, url,
Material
(посилання/файли) categoryId
id, title, content, fileUrl,
Resource Додаткові дидактичні ресурси
grade
На рисунку 3.4 показана схема зв'язків бази даних (ER-діаграма).
55
ЧДТУ 262357.001 ПЗ
Рисунок 3.4 – Схема зв'язків бази даних (ER-діаграма)
Детальний опис атрибутів основних сутностей:
user – крім стандартних полів, містить атрибут image для зберігання
посилань на аватар у Cloudinary та grade для ідентифікації класу учня (наприклад,
"9-А");
56
ЧДТУ 262357.001 ПЗ
test – використовує поле code (unique) для швидкого доступу студентів
до тесту за коротким ідентифікатором. Поле passScore визначає поріг успішного
проходження (за замовчуванням 70%);
question & Option – реалізовано зв'язок "один-до-багатьох". Поле correct
у таблиці Question має тип Json, що дозволяє гнучко зберігати правильні відповіді
для різних типів запитань;
result – зберігає детальний звіт про спробу, включаючи duration (час у
секундах) та повний зліпок відповідей користувача у форматі Json для подальшого
аналізу викладачем.
3.1.5. Розробка інтерфейсу користувача
Під час розробки освітньої платформи «SmartSchool» виникла потреба
створити сучасний та інтуїтивно зрозумілий інтерфейс для взаємодії учнів та
вчителів із системою. Візуальне представлення головної сторінки додатка
наведено на рисунку 3.5.
Рисунок 3.5 – Головна сторінка платформи SmartSchool
57
ЧДТУ 262357.001 ПЗ
Головна сторінка спроєктована як основна «точка входу» для
неавторизованих користувачів та включає такі функціональні особливості:
механізм швидкого доступу: центральним елементом є інтерактивний
рядок пошуку тесту. Система автоматично валідує введений код та перенаправляє
учня на сторінку тестування. Це реалізовано за допомогою клієнтського роутингу
Next.js, що дозволяє уникнути зайвих кроків навігації;
інформаційна архітектура: блоки категорій розподілені за віковими
групами (класами), що дозволяє структурувати навчальні матеріали. Кожна
категорія є динамічним об’єктом, що підтягується з бази даних PostgreSQL через
Prisma ORM.
Для отримання персоналізованого доступу до функцій системи реалізовано
систему безпеки на базі NextAuth.js. Форма входу зображена на рисунку 3.6.
Рисунок 3.6 – Модальне вікно авторизації
Процес ідентифікації та автентифікації: система використовує стратегію
JWT [25] (JSON Web Token) для збереження сесій. При введенні даних бекенд
перевіряє наявність користувача та валідність пароля за допомогою бібліотеки
58
ЧДТУ 262357.001 ПЗ
bcrypt. Після успішної перевірки формується захищений токен, який визначає
права доступу користувача (Role-Based Access Control).
Якщо користувач вперше відвідує платформу, він має зареєструватися,
обравши свою роль у системі. Візуальне представлення форми реєстрації наведено
на рисунку 3.7.
Рисунок 3.7 – Модальне вікно реєстрації
Особливістю реєстрації є диференціація ролей. Вибір ролі («Учень» або
«Вчитель») критично впливає на інтерфейс, який побачить користувач після
входу, оскільки для кожної ролі розроблені окремі високорівневі компоненти.
На рисунку 3.8 представлено особистий кабінет учня, який виконує роль
його індивідуального освітнього середовища.
59
ЧДТУ 262357.001 ПЗ
Рисунок 3.8 – Особистий кабінет учня
Функціонал особистого кабінету учня:
візуалізація прогресу – використання інтерактивних графіків дозволяє
учню миттєво оцінити свою активність. Дані розраховуються динамічно як
співвідношення виконаних завдань до загальної кількості;
історія успішності – цей блок реалізує запит до бази даних, фільтруючи
записи за ID студента. Учень може бачити динаміку своїх оцінок у
хронологічному порядку;
доступ до контенту – картки навчальних матеріалів містять інформацію
про тему, предмет та клас, надаючи швидкий доступ до теоретичної бази.
Для викладачів розроблено аналітичну панель (Teacher Dashboard), яка
зображена на рисунку 3.9.
60
ЧДТУ 262357.001 ПЗ
Рисунок 3.9 – Панель викладача (Teacher Dashboard)
Панель викладача інтегрує в собі наступні функціональні блоки:
1 Статистика та загальний огляд (Header Stats) – у верхній частині сторінки
розміщено віджети для миттєвого моніторингу ключових показників
системи: загальна кількість активних тестів, кількість зареєстрованих
учнів у підпорядкованих класах, сумарна кількість пройдених тестів та
середній бал успішності.
2 Модуль керування тестами. Цей розділ є основним робочим простором
для роботи з діагностичними матеріалами та дозволяє вчителю
виконувати такі дії:
конструктор тестів – дозволяє створювати нові завдання,
налаштовувати назву, опис, цільовий клас та поріг проходження;
61
ЧДТУ 262357.001 ПЗ
унікальні коди (Unique Codes) – для кожного тесту система генерує
ідентифікатор, який викладач передає учням для швидкого доступу
до завдання;
редагування та типи питань – інтерфейс підтримує гнучке
налаштування запитань різних типів;
каскадне керування – можливість повного видалення тесту разом із
пов’язаними результатами для підтримки актуальності бази даних.
3 Модуль аналітики та результатів. Даний інструмент призначений для
глибокого аналізу ефективності навчання та включає наступні
функціональні можливості:
журнал результатів – містить детальну таблицю з даними про час
проходження та отримані бали;
кольорова індикація – автоматичне позначення успішності
(зелений/червоний колір) залежно від подолання студентом
встановленого порогу балів;
діагностика помилок – функція детального перегляду кожної спроби
дозволяє вчителю проаналізувати масив відповідей учня та виявити
конкретні теми, які викликали труднощі.
4 Керування навчальними матеріалами (блок для формування теоретичної
бази платформи) – викладач може створювати тематичні розділи
(категорії) та наповнювати їх контентом (відеолекції, PDF-конспекти,
зовнішні ресурси), чітко розмежовуючи доступ до матеріалів між
різними класами.
3.1.6 Опис розробки програмних компонентів
Архітектура платформи «SmartSchool» побудована за принципом
розподілених обов'язків. Нижче наведено опис ключових програмних
компонентів, що забезпечують функціонування системи:
1 app/page.tsx (Головна сторінка / Landing Page) Головна точка входу для
всіх типів користувачів, що має наступні характеристики:
62
ЧДТУ 262357.001 ПЗ
призначення: презентація платформи та забезпечення швидкого
доступу до функціоналу;
зв'язки: взаємодіє з хуком useSession для визначення статусу
авторизації;
особливості реалізації: містить логіку швидкого переходу до тестів
через унікальний код та динамічні блоки категорій навчання.
2 app/api/auth/[...nextauth]/route.ts (Ядро автентифікації) Центральний
модуль управління сесіями та безпекою додатка:
призначення – ідентифікація користувачів та контроль доступу;
зв'язки – взаємодіє з моделлю User через Prisma та бібліотекою
bcryptjs для перевірки хешованих паролів;
особливості реалізації – налаштовує стратегію JWT, інтегрує
додаткові поля (role, grade, id) у токен сесії.
3 app/api/register/route.ts (Контролер реєстрації):
призначення – створення нових профілів у системі;
зв'язки – приймає дані від RegisterForm.tsx;
особливості реалізації – включає валідацію унікальності email,
хешування паролів та автоматичне призначення початкових
метаданих користувача залежно від обраної ролі.
4 app/api/code/[code]/route.ts (Обробник унікальних кодів):
призначення – пошук та валідація тестів за коротким
ідентифікатором;
зв'язки – зв’язує головну сторінку з модулем проходження тесту;
особливості реалізації – динамічний маршрут, що перевіряє
існування тесту в базі за полем code та повертає його метадані для
ініціалізації сесії тестування.
5 app/api/tests/submit/route.ts (Модуль оцінювання):
призначення – обробка завершених спроб тестування;
зв'язки – взаємодіє з таблицями Test та Result;
63
ЧДТУ 262357.001 ПЗ
особливості реалізації – містить серверний алгоритм порівняння
відповідей учня з еталонними значеннями, розраховує відсоток
успішності та фіксує результат у базі даних.
6 app/api/teacher/dashboard/route.ts (Агрегатор статистики вчителя):
призначення – підготовка аналітичних даних для панелі керування;
зв'язки – виконує агрегуючі запити до таблиць User (студенти) та
Result;
особливості реалізації – розраховує середні бали по класах, кількість
активних тестів та динаміку успішності за останні періоди.
7 app/api/upload/route.ts (Сервіс обробки мультимедіа):
призначення – управління завантаженням зображень та файлів;
зв'язки – взаємодіє з Cloudinary API;
особливості реалізації – забезпечує безпечну передачу файлів на
хмарне сховище та повертає оптимізовані URL-адреси для
відображення в контенті тестів.
8 app/admin/ (Адміністративний модуль):
призначення – глобальне управління користувачами та системним
контентом;
зв'язки – має доступ до всіх таблиць бази даних;
особливості реалізації – окремий захищений розділ для модерації
облікових записів, скидання паролів та видалення некоректного
контенту.
9 app/teacher/tests/ (Конструктор тестів):
призначення – інтерфейс для створення та редагування
діагностичних робіт;
зв'язки – взаємодіє з api/tests/create;
особливості реалізації – реалізує складну форму з динамічним
додаванням питань різних типів та валідацією наявності правильної
відповіді.
64
ЧДТУ 262357.001 ПЗ
10 app/student/grades/page.tsx (Електронний щоденник):
призначення – відображення детальної історії успішності учня;
зв'язки – отримує дані з api/results/[id];
особливості реалізації – візуалізує результати за допомогою таблиць
та кольорових індикаторів, дозволяючи учню аналізувати свої
помилки.
11 app/components/RegisterForm.tsx (Клієнтський UI реєстрації):
призначення – забезпечення взаємодії користувача з процесом
створення акаунта;
зв'язки – передає стан форми на бекенд;
особливості реалізації – включає клієнтську валідацію (довжина
пароля, формат пошти) та обробку помилок сервера в реальному часі.
12 lib/prisma.ts (Клієнт бази даних):
призначення – забезпечення стабільного зв'язку з СУБД PostgreSQL;
зв'язки – використовується у всіх серверних компонентах (API
Routes);
особливості реалізації – реалізований як Singleton-об'єкт для
запобігання надмірному створенню підключень до бази даних.
13 app/student/dashboard/page.tsx (Головний екран учня):
призначення – персоналізована робоча область учня;
зв'язки – взаємодіє з API результатів (/api/results) та навчальних
матеріалів;
особливості реалізації – виконує роль агрегатора навчальної
діяльності. Відображає статистику успішності у вигляді
інтерактивних віджетів, список останніх активностей та забезпечує
швидкий перехід до рекомендованих матеріалів за рівнем класу учня.
14 app/teacher/dashboard/page.tsx (Панель моніторингу вчителя):
призначення – центральний інтерфейс викладача для контролю
освітнього процесу;
65
ЧДТУ 262357.001 ПЗ
зв'язки – отримує дані від спеціалізованого ендпоінту статистики
(/api/teacher/dashboard);
особливості реалізації – реалізує високорівневу аналітику успішності
всіх груп учнів. Дозволяє вчителю бачити загальну картину (середній
бал, активність) без необхідності переглядати кожен результат
окремо.
15 app/tests/[id]/page.tsx (Модуль проходження тесту):
призначення – інтерфейс безпосередньої взаємодії учня з тестовим
контентом;
зв'язки – завантажує дані через /api/tests/[id] та відправляє відповіді
на /api/tests/submit;
особливості реалізації – динамічно рендерить питання різних типів,
реалізує таймер зворотного відліку (якщо передбачено) та керує
станом вибору відповідей до моменту фінальної відправки на сервер.
16 app/api/users/[id]/route.ts (Контролер профілю користувача):
призначення – управління персональними даними та
налаштуваннями;
зв'язки – взаємодіє з моделлю User у базі даних;
особливості реалізації – дозволяє користувачу оновлювати аватар,
змінювати пароль або коригувати інформацію про клас.
Використовує серверні перевірки сесії для гарантування того, що
користувач може змінювати лише власні дані.
17 prisma/schema.prisma (Опис об'єктної моделі даних):
призначення – декларативний опис структури бази даних та зв'язків
між сутностями;
зв'язки є фундаментом для генерації клієнта Prisma, що
використовується в усіх API-маршрутах;
66
ЧДТУ 262357.001 ПЗ
особливості реалізації – визначає типи даних, обмеження цілісності
(Unique, Not Null) та логіку каскадних операцій (наприклад,
автоматичне видалення результатів при видаленні тесту).
18 app/layout.tsx (Кореневий макет додатка):
призначення – визначення глобальної структури та підключення
провайдерів стану;
зв'язки – огортає всі сторінки додатка, підключає SessionProvider
(NextAuth) та глобальні стилі;
особливості реалізації – забезпечує сталість навігаційного меню та
футера при переходах між сторінками, а також відповідає за
ініціалізацію шрифтів та метаданих для SEO.
3.2. Тестування системи
Тестування системи SmartSchool є етапом верифікації, що дозволяє
переконатися у відповідності реалізованого функціоналу технічному завданню.
Оскільки система побудована на базі сучасного JavaScript-стеку (Next.js,
TypeScript, Prisma), для перевірки надійності було обрано стратегію поєднання
автоматизованого модульного тестування та ручного функціонального аналізу.
3.2.1 Модульне тестування
На рисунку 3.10 модульне тестування спрямоване на перевірку ізольованих
компонентів інтерфейсу та окремих серверних функцій (API Routes). Основний
інструмент – бібліотека Jest [11] у поєднанні з React Testing Library [26].
Об'єкти модульного тестування:
1 Компонент RegisterForm – перевірка стану вибору ролі та валідація полів
(email, довжина пароля).
2 API Route /api/code/[code] – перевірка коректності пошуку тесту за кодом
та обробка ситуації, коли код не існує.
3 Компонент StudentDashboard – контроль рендерингу графіків успішності
на основі вхідних масивів даних про результати.
67
ЧДТУ 262357.001 ПЗ
4 Модуль Prisma Client – перевірка коректності запитів до бази даних
PostgreSQL у середовищі розробки.
Рисунок 3.10 – Результат успішного виконання набору модульних тестів у
консолі розробника
Таблиця 3.2
Результати модульного тестування компонентів SmartSchool
Компонент Опис тесту Очікуваний результат Статус
Валідація JWT- Отримання сесії
AuthModule Успішно
токена користувача після входу
Коректне збереження
TestConstructor Створення питання JSON-структури Успішно
питання
Правильне порівняння
ResultController Розрахунок балів відповідей учня з Успішно
еталоном
Динамічна зміна графіка
Відображення
Dashboard при отриманні нових Успішно
прогресу
даних
68
ЧДТУ 262357.001 ПЗ
Продовження таблиці 3.2
Відображення контенту
Materials Фільтрація за класом лише для обраного 8 чи 9 Успішно
класу
Кожен модуль було протестовано на відповідність функціональним
вимогам. Окрім позитивних сценаріїв, проводилися негативні тести: наприклад,
спроба реєстрації з уже існуючою поштою або вхід до панелі вчителя з акаунту
учня. Виявлені на цьому етапі помилки (наприклад, неправильне відображення
статусів у папках матеріалів) були оперативно виправлені, що забезпечило
стабільну основу для наступного етапу – інтеграційного тестування.
3.2.2. Інтеграційне тестування
Інтеграційне тестування є наступним етапом після модульного і спрямоване
на перевірку коректної взаємодії між різними модулями системи SmartSchool. На
цьому етапі основна увага приділялася тому, як фронтенд-компоненти
взаємодіють з API-маршрутами, та як бекенд обмінюється даними з базою даних
через Prisma ORM.
Для інтеграційного тестування використовувалися такі методи:
тестування взаємодії API та БД. Перевірка того, чи правильно запити від
клієнта (наприклад, реєстрація або відправка тесту) зберігаються в PostgreSQL;
тестування маршрутизації Next.js. Перевірка перенаправлень
користувача залежно від його ролі (Admin/Teacher/Student) після проходження
автентифікації;
тестування потоку даних (Data Flow). Перевірка ланцюжка: «Створення
тесту вчителем – Збереження в БД – Отримання тесту учнем за кодом –
Збереження результату».
Нижче в таблиця 3.3 наведено результати використання методів для
проходження інтеграційних тестів для основних сценаріїв системи.
69
ЧДТУ 262357.001 ПЗ
Таблиця 3.3
Результати інтеграційного тестування системи SmartSchool
Результат
Компонент Опис тесту Очікуваний результат
виконання
Взаємодія форми Користувач
API
входу з NextAuth та авторизований, сесія Успішно
Автентифікації
Prisma створена у базі даних
Надсилання Дані коректно оброблені
Модуль
результатів тесту та зафіксовані у таблиці Успішно
Тестування
через /api/tests/submit Result
API повертає об'єкт
Пошук тесту за
Інтерфейс тесту, фронтенд
унікальним кодом Успішно
Доступу відкриває сторінку
через /api/code/[code]
проходження
Агрегація даних для Коректне відображення
Панель Вчителя дашборду з таблиць статистики успішності Успішно
User та Result учнів на графіках
При видаленні тесту
Перевірка цілісності автоматично
База даних
даних при видаленні видаляються всі Успішно
(PostgreSQL)
тесту пов'язані результати
(Cascade)
Повний цикл: Вхід -> Дані безперешкодно
Загальна
Проходження тесту - передаються між усіма Успішно
інтеграція
> Перегляд оцінки рівнями системи
Після успішного інтеграційного тестування було підтверджено, що всі
компоненти системи SmartSchool працюють як єдине ціле. Взаємодія між
клієнтською частиною на Next.js та серверною логікою з базою даних є стабільною
та відповідає логіці навчального процесу.
70
ЧДТУ 262357.001 ПЗ
3.2.3 Системне тестування
Системне тестування є завершальним етапом перевірки перед
впровадженням SmartSchool у реальну експлуатацію. Його мета – підтвердити, що
інформаційна система функціонує як цілісний механізм, відповідає технічним
вимогам та задовольняє потреби основних груп користувачів: учнів та вчителів.
Під час системного тестування було проведено комплексні перевірки за
кількома напрямками:
функціональне тестування – перевірка повного життєвого циклу
навчання від створення контенту вчителем до отримання оцінки учнем.
тестування продуктивності – оцінка швидкості завантаження навчальних
матеріалів та стабільності роботи API при одночасних запитах.
тестування безпеки – перевірка механізмів автентифікації на базі JWT та
розмежування прав доступу між ролями «Вчитель» та «Учень».
Таблиця 3.4
Результати системного тестування SmartSchool
Компонент Опис тесту Очікуваний результат Статус
Управління Коректна реєстрація та вхід
Функціональність Успішно
користувачами через AuthController
Вчитель може створювати,
Конструктор
редагувати та видаляти тести; Успішно
тестів
дані синхронізуються з базою
Учень може знайти тест за
Проходження
кодом, надати відповіді та Успішно
тестування
миттєво отримати результат
Завантаження PDF-файлів та
Бібліотека
статей; коректне Успішно
матеріалів
відображення у кабінеті учня
71
ЧДТУ 262357.001 ПЗ
Продовження таблиці 3.4
Стабільна робота системи
Навантажувальне при одночасному
Продуктивність Успішно
тестування проходженні тестів групою з
30+ учнів
Генерація сторінки дашборду
Час відгуку та завантаження списку тестів Успішно
триває менше 1.5 сек
Учень не має доступу до
Рольова модель
Безпека teacher/dashboard та API Успішно
(RBAC)
створення тестів
Паролі користувачів
хешуються; API захищено від
Захист даних Успішно
SQL-ін'єкцій засобами Prisma
ORM
Ідентичне відображення
Сумісність Кросбраузерність інтерфейсу в Chrome, Firefox, Успішно
Safari та Edge
Коректна робота та зручне
Адаптивність
проходження тестів на Успішно
(Mobile)
смартфонах (iOS/Android)
Інтуїтивно зрозумілий
Інтерфейс перехід між дашбордом,
Навігація Успішно
(UI/UX) списком оцінок та
матеріалами
Після успішного завершення системного тестування було підтверджено, що
SmartSchool забезпечує необхідну надійність та функціональність. Система
демонструє стабільну роботу всіх модулів та готова до використання в освітньому
процесі.
72
ЧДТУ 262357.001 ПЗ
3.2.4 Приймальне тестування
Приймальне тестування є фінальним етапом верифікації системи
SmartSchool перед її офіційним впровадженням в освітній процес. Основна мета
цього етапу – підтвердити, що реалізований функціонал повністю відповідає
запитам кінцевих користувачів: адміністраторів, викладачів та учнів.
На відміну від системного тестування, UAT зосереджується не на технічній
бездоганності коду, а на зручності бізнес-процесів: наскільки легко вчителю
створити новий тест та наскільки зрозуміло учню, де шукати свої результати.
Процес приймального тестування включав наступні кроки:
планування – визначення ключових сценаріїв, таких як «повний цикл
проходження тесту» та «керування базою учнів»;
підготовка сценаріїв – формування набору кроків для перевірки кожної
ролі (адміністратор, вчитель, учень);
виконання – тестування інтерфейсу на реальних даних у браузері;
аналіз – оцінка відповідності інтерфейсу очікуванням (наприклад, чи
помітна кнопка «Завершити тест»).
Таблиця 3.5
Проходження приймальних тестів системи SmartSchool
Компонент Опис тесту Очікуваний результат Статус
Користувачі можуть
Реєстрація та
Функціональність безперешкодно створити акаунт Успішно
вхід
та увійти до системи
Вчитель може створювати нові
Управління
тести, редагувати питання та Успішно
тестами
встановлювати коди доступу
Учні можуть переглядати свої
Оцінювання та
оцінки в особистому кабінеті; Успішно
успішність
вчителі бачать зведений звіт
73
ЧДТУ 262357.001 ПЗ
Продовження таблиці 3.5
Можливість успішного перегляду
Навчальні
завантажених PDF-конспектів та Успішно
матеріали
статей
Сторінки з великою кількістю
Швидкість
Продуктивність питань завантажуються без Успішно
завантаження
затримок
Учень не може отримати доступ
Розмежування
Безпека до розділу редагування тестів або Успішно
прав
списків інших користувачів
Вхід до системи можливий лише
Захист даних за наявності валідних облікових Успішно
даних
Коректна робота системи в
Кросплатформ
Сумісність браузерах Chrome та Safari на Успішно
еність
мобільних пристроях і ПК
Користувачі легко знаходять
Навігація та
UI/UX потрібні розділи завдяки Успішно
дизайн
інтуїтивній бічній панелі
Елементи інтерфейсу (кнопки,
Адаптивність таблиці) зручні для використання Успішно
на малих екранах
Приймальне тестування підтвердило, що інформаційна система SmartSchool
готова до реальної експлуатації. Всі виявлені дрібні недоліки інтерфейсу були
усунені, що гарантує комфортну роботу користувачів у межах навчального
закладу.
3.3. Приклади впровадження програмного комплексу
74
ЧДТУ 262357.001 ПЗ
Впровадження програмного комплексу SmartSchool в освітній процес
навчального закладу передбачає кілька послідовних етапів. Метою впровадження
є автоматизація контролю знань, централізація навчальних матеріалів та
створення єдиного цифрового простору для взаємодії вчителів та учнів.
Етапи впровадження
1 Підготовка інфраструктури:
оцінка технічної бази – аналіз наявного обладнання навчального
закладу (сервери або хмарні потужності) для розгортання
платформи;
налаштування середовища – конфігурація WEB-сервера для Node.js
та розгортання бази даних PostgreSQL. Налаштування безпечного
з'єднання для захисту персональних даних учнів.
2 Міграція та підготовка даних:
аудит даних – формування списків учнів, класів та вчителів для
початкового завантаження;
імпорт сутностей – перенесення існуючих навчальних планів,
переліку предметів та бази тестових питань у нову систему через
Prisma ORM;
верифікація – перевірка цілісності зв'язків між учнями та їхніми
класами.
3 Навчання користувачів:
інструкції для вчителів – розробка методичних рекомендацій щодо
створення інтерактивних тестів та керування бібліотекою матеріалів;
ознайомлення учнів – проведення коротких сесій для демонстрації
кабінету учня, процесу проходження тестів та моніторингу власної
успішності.
4 Дослідна експлуатація:
апробація – запуск системи для одного-двох пілотних класів для
перевірки навантаження та зручності інтерфейсу;
75
ЧДТУ 262357.001 ПЗ
коригування – збір відгуків та адаптація елементів керування (UI) під
потреби конкретного закладу.
5 Повномасштабний запуск:
перехід на нову систему – офіційне використання SmartSchool як
основного інструменту для проведення тестувань;
підтримка – моніторинг роботи бази даних та надання консультацій
користувачам.
Основні функціональні компоненти системи:
1 Панель керування вчителя (Teacher Dashboard): забезпечення викладача
інструментами для створення тестів, генерації унікальних кодів доступу та аналізу
статистики успішності класів у реальному часі.
2 Особистий кабінет учня (Student Dashboard): візуалізація прогресу
навчання, перегляд останніх оцінок та швидкий доступ до призначених тестів і
навчальних матеріалів.
3 Система автентифікації та авторизації: безпечний вхід на основі ролей
(учень/вчитель), що гарантує доступ лише до дозволеного контенту та функцій.
4 Конструктор та менеджер тестів: модуль для створення питань різних
типів, збереження їх у форматі JSON у базі даних та керування часом доступу до
тестування.
5 Цифрова бібліотека матеріалів: централізоване сховище для навчальних
статей та PDF-конспектів, структуроване за класами та темами.
6 Аналітичний модуль: автоматичний розрахунок результатів,
формування рейтингів та візуалізація динаміки навчання за допомогою графіків.
Впровадження інформаційної системи SmartSchool дозволить суттєво
знизити навантаження на викладачів завдяки автоматичній перевірці робіт,
забезпечить прозорість оцінювання для учнів та підвищить загальний рівень
цифровізації навчального закладу. Успіх впровадження базується на зручності
інтерфейсу Next.js та надійності збереження даних у PostgreSQL.
76
ЧДТУ 262357.001 ПЗ
ВИСНОВКИ ПО РОЗДІЛУ 3
У третьому розділі проведено комплексний опис процесу проектування,
програмної реалізації та тестування інформаційної системи SmartSchool. На
початковому етапі було обґрунтовано вибір технологічного стеку, де
використання фреймворку Next.js та мови TypeScript дозволило забезпечити
високу швидкість рендерингу інтерфейсу та строгу типізацію даних, що суттєво
мінімізує кількість помилок на етапі розробки та подальшої підтримки продукту.
Розроблені структурна та логічна схеми системи наочно відображають
взаємодію між основними модулями та кабінетами вчителя й учня. Логіка
функціонування платформи побудована на забезпеченні безперервного циклу
освітнього процесу, який включає створення навчального контенту, проходження
тестування та автоматизовану перевірку результатів із миттєвим зворотним
зв’язком.
Особливу увагу приділено архітектурі бази даних, реалізованій за
допомогою PostgreSQL та Prisma ORM. Спроектована структура таблиць
забезпечує цілісність інформації про користувачів, тести та результати навчання,
дозволяючи оперативно виконувати запити та зберігати складні зв'язки між
сутностями. Створений інтерфейс користувача вирізняється інтуїтивністю, що
гарантує комфортну роботу з системою.
Процес розробки програмних компонентів включав створення надійних
серверних контролерів (API Routes), які відповідають за безпечну автентифікацію
через JWT та обробку бізнес-логіки системи. Проведене багаторівневе тестування,
що охопило модульний, інтеграційний, системний та приймальний етапи,
підтвердило повну відповідність розробленого програмного забезпечення
технічним вимогам та очікуванням кінцевих користувачів.
Завершальним етапом розділу став опис стратегії впровадження SmartSchool
в освітнє середовище. Визначені кроки з підготовки інфраструктури та навчання
персоналу дозволяють забезпечити плавний перехід до використання цифрової
платформи, мінімізуючи ризики виникнення технічних збоїв.
77
ЧДТУ 262357.001 ПЗ
ВИСНОВКИ
У результаті виконання кваліфікаційної роботи бакалавра було досягнуто
поставлену мету – розроблено інформаційну систему освітньої платформи
SmartSchool.
Дана система дозволяє зручно взаємодіяти вчителям та учням, забезпечуючи
доступ до навчальних матеріалів, створення інтерактивних тестів, автоматизоване
оцінювання та відстеження успішності навчання в єдиному цифровому
середовищі.
У ході роботи були повністю вирішені задачі, які були поставлені в завданні
на виконання кваліфікаційної роботи бакалавра: проведено огляд систем-аналогів
платформ для дистанційного навчання та управління освітнім процесом.
проаналізовано переваги і недоліки існуючих систем-аналогів. Обрано сучасні
мови програмування, фреймворки та середовища розробки. Розроблено
програмний продукт з детальним описом архітектури та алгоритмів взаємодії
клієнт-сервер. Описано результати розробки та структуру бази даних. Проведено
комплексне тестування розробленої системи. Сформовано план впровадження
програмного комплексу в освітній процес навчального закладу.
Інформаційна система була розроблена з використанням фреймворку
Next.js, мови програмування TypeScript, бібліотеки React, інструментів HTML та
CSS, ORM-модуля Prisma, а також реляційної бази даних PostgreSQL.
Всі тестування були пройдені успішно, і тому розроблений WEB-додаток є
повністю працездатним і готовим до впровадження та використання для
цифровізації освітнього процесу в сучасному навчальному закладі.
78
ЧДТУ 262357.001 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Розглянутий аналог Google Classroom [Електронний ресурс]. – Режим
доступу: https://classroom.google.com/.
2 Розглянутий аналог Moodle [Електронний ресурс]. – Режим доступу:
https://moodle.org/.
3 Розглянутий аналог Canvas LMS [Електронний ресурс]. – Режим
доступу: https://www.instructure.com/canvas.
4 Розглянутий аналог Kahoot! [Електронний ресурс]. – Режим доступу:
https://kahoot.com/.
5 Сайт для розробки UML діаграм PlantUML [Електронний ресурс]. –
Режим доступу: https://plantuml.com/.
6 Next.js Documentation [Електронний ресурс]. – Режим доступу:
https://nextjs.org/docs.
7 TypeScript Documentation [Електронний ресурс]. – Режим доступу:
https://www.typescriptlang.org/docs/.
8 React Reference Documentation [Електронний ресурс]. – Режим
доступу: https://react.dev/reference/react.
9 Prisma ORM Documentation [Електронний ресурс]. – Режим доступу:
https://www.prisma.io/docs/.
10 PostgreSQL Documentation [Електронний ресурс]. – Режим доступу:
https://www.postgresql.org/docs/.
11 Jest: Getting Started [Електронний ресурс]. – Режим доступу:
https://jestjs.io/docs/getting-started.
12 MDN Web Docs: HTML [Електронний ресурс]. – Режим доступу:
https://developer.mozilla.org/en-US/docs/Web/HTML.
13 MDN Web Docs: CSS [Електронний ресурс]. – Режим доступу:
https://developer.mozilla.org/en-US/docs/Web/CSS.
14 Visual Studio Code Documentation [Електронний ресурс]. – Режим
доступу: https://code.visualstudio.com/docs.
79
ЧДТУ 262357.001 ПЗ
15 Learning analytics – Wikipedia [Електронний ресурс]. – Режим
доступу: https://en.wikipedia.org/wiki/Learning_analytics.
16 Освітній портал «На Урок» [Електронний ресурс]. – Режим доступу:
https://naurok.com.ua/.
17 NextAuth.js Documentation [Електронний ресурс]. – Режим доступу:
https://next-auth.js.org/.
18 Tailwind CSS Documentation [Електронний ресурс]. – Режим доступу:
https://tailwindcss.com/docs.
19 Role-based access control – Wikipedia [Електронний ресурс]. – Режим
доступу: https://en.wikipedia.org/wiki/Role-based_access_control.
20 Алгоритм хешування bcrypt [Електронний ресурс]. – Режим доступу:
https://uk.wikipedia.org/wiki/Bcrypt.
21 Nginx Documentation [Електронний ресурс]. – Режим доступу:
https://nginx.org/en/docs/.
22 PM2 Process Manager Documentation [Електронний ресурс]. – Режим
доступу: https://pm2.keymetrics.io/docs/usage/quick-start/.
23 Firebase Documentation [Електронний ресурс]. – Режим доступу:
https://firebase.google.com/docs.
24 Cloudinary Programmable Media Documentation [Електронний ресурс].
– Режим доступу: https://cloudinary.com/documentation.
25 JSON Web Token (JWT) Специфікація [Електронний ресурс]. –
Режим доступу: https://jwt.io/introduction.
26 React Testing Library Documentation [Електронний ресурс]. – Режим
доступу: https://testing-library.com/docs/react-testing-library/intro/.
80
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_________________ Голуб С.В.
„____” ______________ 2025 р.
Програмне забезпечення діагностики дидактичної системи
Специфікація
482 ЧДТУ. 262357-001
Листів 1
Розробник ________________ Дзюндзя Д.М.
Керівник ________________ Немов Р.Г.
Черкаси 2026
482 ЧДТУ 262357 17 2
Позначення Найменування Примітки
482 ЧДТУ 262357 12 01 Текст програми
482 ЧДТУ 262357 34 01 Інструкція користувачеві
482 ЧДТУ 262357 90 01 Графічні матеріали
82
ДОДАТОК Б
Програмне забезпечення діагностики дидактичної системи
Текст програми
482 ЧДТУ 262357 12 01
Листів 20
Розробник ________________ Дзюндзя Д.М.
Черкаси 2026
482 ЧДТУ 262357 12 01 2
App/page.tsx
"use client";
import React, { useState } from "react";
import { useSession, signOut } from "next-auth/react";
import { useRouter } from "next/navigation";
import AuthModal from "./components/AuthModal";
export default function HomePage() {
const { data: session } = useSession();
const [isAuthOpen, setIsAuthOpen] = useState(false);
const [testCode, setTestCode] = useState("");
const [loading, setLoading] = useState(false);
const router = useRouter();
const userRole = session?.user?.role?.toLowerCase();
const handleJoinTest = async (e: React.FormEvent) => {
e.preventDefault();
if (!testCode) return;
setLoading(true);
try {
const res = await fetch(`/api/code/${testCode}`);
if (res.ok) {
router.push(`/student/tests/${testCode}`);
} else {
console.log("Код не знайдено");
}
} catch (err) {
console.error("Помилка з'єднання");
} finally {
setLoading(false);
}
};
const sections = [
{
title: "Початкова база",
classes: [5, 6, 7],
desc: "Фундаментальні знання та перші кроки у предметах",
gradient: "bg-gradient-to-br from-emerald-500 to-teal-700",
icon: "��"
},
{
title: "Середня школа",
classes: [8, 9],
desc: "Поглиблене вивчення та підготовка до вибору профілю",
gradient: "bg-gradient-to-br from-indigo-600 to-blue-800",
icon: "��"
},
{
title: "Старша школа",
classes: [10, 11],
desc: "Професійна орієнтація та підготовка до іспитів",
gradient: "bg-gradient-to-br from-slate-800 to-slate-950",
icon: "��"
}
];
return (
<div className="min-h-screen bg-white font-sans text-slate-900">
84
482 ЧДТУ 262357 12 01 3
<nav className="sticky top-0 z-50 bg-white/80 backdrop-blur-md py-4 px-6
border-b border-slate-100">
<div className="max-w-7xl mx-auto flex justify-between items-center">
<div className="flex items-center gap-3 cursor-pointer group"
onClick={() => router.push('/')}>
<div className="bg-indigo-600 text-white w-10 h-10 rounded-xl flex
items-center justify-center font-black shadow-lg shadow-indigo-100 group-
hover:scale-110 transition-transform">
S
</div>
<span className="text-xl font-bold tracking-tight text-slate-
800">SmartSchool</span>
</div>
<div className="flex items-center gap-4">
{!session ? (
<button
onClick={() => setIsAuthOpen(true)}
className="bg-slate-900 text-white px-6 py-2.5 rounded-xl font-
bold text-sm hover:bg-slate-800 transition-all active:scale-95 shadow-sm"
>
Увійти
</button>
) : (
<div className="flex items-center gap-4">
<button
onClick={() => {
// Логіка перенаправлення залежно від ролі
if (userRole === "teacher") {
router.push("/teacher/dashboard");
} else if (userRole === "admin") {
router.push("/admin/users");
} else {
router.push("/student/dashboard");
}
}}
className="bg-indigo-600 text-white px-6 py-2.5 rounded-xl
font-bold text-sm hover:bg-indigo-700 transition-all shadow-lg shadow-indigo-100
active:scale-95 flex items-center gap-2"
>
<span>
{userRole === "teacher" ? "Панель вчителя" :
userRole === "admin" ? "Панель адміна" : "Мій кабінет"}
</span>
<span className="opacity-50">→</span>
</button>
<div className="h-6 w-[1px] bg-slate-200 mx-2"></div>
<button
onClick={() => signOut()}
className="text-slate-400 text-sm font-bold hover:text-red-500
transition-colors"
>
Вийти
</button>
</div>
)}
</div>
</div>
</nav>
<main className="max-w-7xl mx-auto px-6">
85
482 ЧДТУ 262357 12 01 4
<div className="text-center py-20 space-y-8">
<div className="inline-flex items-center gap-2 px-3 py-1 bg-indigo-50
text-indigo-600 rounded-full text-[11px] font-black uppercase tracking-wider">
Освітня екосистема
</div>
<h1 className="text-5xl md:text-7xl font-black text-slate-900 leading-
[1.1] tracking-tight">
Твій шлях до <br />
<span className="text-indigo-600">сучасних знань</span>
</h1>
<p className="text-slate-400 text-lg max-w-2xl mx-auto font-medium">
Виконуй тести, навчайся та відстежуй свій прогрес на єдиній платформі
для всієї школи.
</p>
<form onSubmit={handleJoinTest} className="max-w-lg mx-auto relative
mt-12">
<div className="absolute -inset-4 bg-indigo-500/5 rounded-[2.5rem]
blur-2xl"></div>
<div className="relative">
<input
type="text"
placeholder="Введи код завдання..."
value={testCode}
onChange={(e) => setTestCode(e.target.value)}
className="w-full px-8 py-5 rounded-2xl border-2 border-slate-100
text-lg focus:border-indigo-500 outline-none transition-all pr-40 shadow-xl
shadow-slate-200/50 font-medium"
/>
<button
type="submit"
disabled={loading}
className="absolute right-2 top-2 bottom-2 bg-indigo-600 text-
white px-8 rounded-xl font-bold hover:bg-indigo-700 transition-all
disabled:opacity-50 shadow-lg shadow-indigo-200"
>
{loading ? "..." : "Почати"}
</button>
</div>
</form>
</div>
<div className="grid md:grid-cols-3 gap-8 py-16">
{sections.map((section, idx) => (
<div key={idx} className={`relative overflow-hidden rounded-[3rem] p-
10 text-white ${section.gradient} shadow-2xl transition-all duration-500 hover:-
translate-y-3 group`}>
<div className="relative z-10">
<div className="text-5xl mb-6 group-hover:scale-110 transition-
transform duration-500 inline-block">{section.icon}</div>
<h3 className="text-2xl font-black mb-3">{section.title}</h3>
<p className="text-white/70 text-sm mb-10 leading-relaxed font-
medium">{section.desc}</p>
<div className="flex flex-wrap gap-3">
{section.classes.map(c => (
<button
key={c}
onClick={() => router.push(`/student/grades/${c}`)}
86
482 ЧДТУ 262357 12 01 5
className="bg-white/15 hover:bg-white text-white
hover:text-slate-900 backdrop-blur-md px-5 py-3 rounded-2xl text-sm font-black
transition-all border border-white/10 active:scale-90"
>
{c} клас
</button>
))}
</div>
</div>
<div className="absolute -right-8 -bottom-8 opacity-10 text-[12rem]
font-black pointer-events-none group-hover:scale-110 transition-transform
duration-700">
{section.classes[0]}
</div>
</div>
))}
</div>
</main>
<footer className="py-16 text-center border-t border-slate-50 mt-12">
<div className="flex flex-col items-center gap-4">
<div className="flex items-center gap-2 opacity-50">
<div className="bg-slate-900 text-white w-5 h-5 rounded flex items-
center justify-center font-bold text-[8px]">S</div>
<span className="font-bold text-xs tracking-tight text-slate-800
uppercase">SmartSchool 2026</span>
</div>
<p className="text-slate-300 text-[10px] font-bold uppercase tracking-
[0.3em]">Майбутнє освіти вже тут</p>
</div>
</footer>
{isAuthOpen && <AuthModal isOpen={isAuthOpen} onClose={() =>
setIsAuthOpen(false)} />}
</div>
);
}
App/teacher/dashboard/page.tsx
"use client";
import React, { useState, useEffect, useMemo } from 'react';
import { useSession } from "next-auth/react";
import { useRouter } from "next/navigation";
import {
Users, Search, BarChart3, Clock, Trophy, Trash2, Edit3,
ChevronDown, ChevronUp, X, Target, BookOpen, FolderOpen
} from 'lucide-react';
const App = () => {
const { data: session } = useSession();
const router = useRouter();
const [tests, setTests] = useState([]);
const [loading, setLoading] = useState(true);
const [searchTerm, setSearchTerm] = useState("");
const [expandedTestId, setExpandedTestId] = useState(null);
const [selectedTestStats, setSelectedTestStats] = useState(null);
const [deletingId, setDeletingId] = useState(null);
useEffect(() => {
if (session?.user) {
87
482 ЧДТУ 262357 12 01 6
fetchTests();
} else {
setLoading(false);
}
}, [session]);
const fetchTests = async () => {
try {
const teacherId = session?.user?.id;
const url = teacherId ? `/api/tests?teacherId=${teacherId}` : "/api/tests";
const res = await fetch(url);
if (res.ok) {
const data = await res.json();
setTests(data);
}
} catch (error) {
console.error("Fetch error:", error);
} finally {
setLoading(false);
}
};
const globalStats = useMemo(() => {
const totalTests = tests.length;
const totalAttempts = tests.reduce((acc, t) => acc + (t._count?.results ||
0), 0);
const allScores = [];
const allDurations = [];
tests.forEach(t => {
t.results?.forEach(r => {
allScores.push((r.score / (r.total || 1)) * 100);
allDurations.push(r.duration);
});
});
const avgScore = allScores.length ? Math.round(allScores.reduce((a, b) => a +
b, 0) / allScores.length) : 0;
const avgDuration = allDurations.length ? Math.round(allDurations.reduce((a,
b) => a + b, 0) / allDurations.length) : 0;
return { totalTests, totalAttempts, avgScore, avgDuration };
}, [tests]);
const filteredTests = useMemo(() => {
return tests.filter(test =>
test.title.toLowerCase().includes(searchTerm.toLowerCase()) ||
test.topic.toLowerCase().includes(searchTerm.toLowerCase()) ||
test.code.toLowerCase().includes(searchTerm.toLowerCase())
);
}, [tests, searchTerm]);
const openStatsModal = (e, test) => {
e.stopPropagation();
const results = test.results || [];
const count = results.length;
const scores = results.map(r => (r.score / (r.total || 1)) * 100);
const avgScore = count ? Math.round(scores.reduce((a, b) => a + b, 0) /
count) : 0;
const totalTime = results.reduce((acc, r) => acc + r.duration, 0);
const avgTime = count ? Math.round(totalTime / count) : 0;
const passedCount = results.filter(r => r.passed).length;
88
482 ЧДТУ 262357 12 01 7
const distribution = [0, 0, 0, 0, 0];
scores.forEach((score) => {
if (score <= 20) distribution[0]++;
else if (score <= 40) distribution[1]++;
else if (score <= 60) distribution[2]++;
else if (score <= 80) distribution[3]++;
else distribution[4]++;
});
setSelectedTestStats({
...test,
avgScore,
avgTime,
count,
passedCount,
distribution
});
};
const handleDelete = async (e, id) => {
e.stopPropagation();
if (!confirm("Ви впевнені?")) return;
setDeletingId(id);
try {
const res = await fetch(`/api/tests?id=${id}`, { method: "DELETE" });
if (res.ok) setTests(prev => prev.filter(t => t.id !== id));
} catch (error) {
console.error("Delete error:", error);
} finally {
setDeletingId(null);
}
};
const formatTime = (seconds) => {
const m = Math.floor(seconds / 60);
const s = seconds % 60;
return `${m}хв ${s}с`;
};
if (loading) return (
<div className="flex items-center justify-center min-h-screen bg-slate-50
text-slate-500 font-medium">
Завантаження...
</div>
);
return (
<div className="min-h-screen bg-[#F8FAFC] text-slate-900 pb-20">
<div className="bg-white border-b border-slate-200 sticky top-0 z-10">
<div className="max-w-7xl mx-auto px-4 h-20 flex flex-col md:flex-row
items-center justify-between gap-4">
<div className="flex items-center gap-3 w-full md:w-auto mt-2 md:mt-0">
<div className="bg-blue-600 p-2 rounded-xl text-white">
<BarChart3 className="w-6 h-6" />
</div>
<h1 className="text-xl font-bold tracking-tight">Панель
викладача</h1>
</div>
<div className="flex items-center gap-2 w-full md:w-auto overflow-x-
auto pb-2 md:pb-0 no-scrollbar">
<button
onClick={() => router.push("/teacher/materials")}
89
482 ЧДТУ 262357 12 01 8
className="flex items-center gap-2 bg-slate-100 hover:bg-slate-200
text-slate-700 px-4 py-2.5 rounded-xl font-semibold transition-all whitespace-
nowrap"
>
<BookOpen className="w-4 h-4" /> Матеріали
</button>
<button
onClick={() => router.push("/teacher/materials/categories")}
className="flex items-center gap-2 bg-slate-100 hover:bg-slate-200
text-slate-700 px-4 py-2.5 rounded-xl font-semibold transition-all whitespace-
nowrap"
>
<FolderOpen className="w-4 h-4" /> Розділи
</button>
<button
onClick={() => router.push("/teacher/tests/create")}
className="bg-blue-600 hover:bg-blue-700 text-white px-5 py-2.5
rounded-xl font-semibold transition-all shadow-lg shadow-blue-200 whitespace-
nowrap ml-2"
>
+ Створити тест
</button>
</div>
</div>
</div>
<main className="max-w-7xl mx-auto px-4 py-8">
<div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-4 gap-6 mb-
10">
<StatCard title="Тестів" value={globalStats.totalTests} icon={<Target
className="w-5 h-5 text-blue-600" />} color="bg-blue-50" />
<StatCard title="Спроб" value={globalStats.totalAttempts} icon={<Users
className="w-5 h-5 text-purple-600" />} color="bg-purple-50" />
<StatCard title="Сер. бал" value={`${globalStats.avgScore}%`}
icon={<Trophy className="w-5 h-5 text-amber-600" />} color="bg-amber-50" />
<StatCard title="Сер. час" value={formatTime(globalStats.avgDuration)}
icon={<Clock className="w-5 h-5 text-emerald-600" />} color="bg-emerald-50" />
</div>
<div className="relative mb-8">
<Search className="absolute left-4 top-1/2 -translate-y-1/2 text-slate-
400 w-5 h-5" />
<input
type="text"
placeholder="Пошук тестів за назвою, темою або кодом..."
className="w-full pl-12 pr-4 py-4 bg-white border border-slate-200
rounded-2xl focus:outline-none focus:ring-4 focus:ring-blue-500/5 transition-all
shadow-sm"
value={searchTerm}
onChange={(e) => setSearchTerm(e.target.value)}
/>
</div>
<div className="space-y-4">
{filteredTests.map((test) => (
<div key={test.id} className={`bg-white rounded-3xl border
transition-all ${expandedTestId === test.id ? 'border-blue-500 shadow-xl' :
'border-slate-200 hover:border-slate-300'}`}>
<div
className="p-6 flex flex-col md:flex-row items-center gap-6
cursor-pointer"
onClick={() => setExpandedTestId(expandedTestId === test.id ?
null : test.id)}
90
482 ЧДТУ 262357 12 01 9
>
<div className="w-14 h-14 bg-slate-100 rounded-2xl flex items-
center justify-center font-bold text-slate-700 shrink-0">
{test.grade} кл.
</div>
<div className="flex-1 text-center md:text-left">
<div className="flex flex-col md:flex-row md:items-center gap-2
mb-1">
<h3 className="text-lg font-bold text-slate-
900">{test.title}</h3>
<span className="inline-flex justify-center text-[10px]
uppercase font-bold bg-slate-100 text-slate-500 px-2 py-0.5 rounded w-fit mx-auto
md:mx-0">
{test.topic}
</span>
</div>
<div className="flex flex-wrap justify-center md:justify-start
items-center gap-4 text-sm text-slate-500 font-medium">
<span className="font-mono bg-blue-50 text-blue-600 px-2
rounded font-bold">{test.code}</span>
<span className="flex items-center gap-1"><Users
className="w-4 h-4" /> {test._count?.results || 0}</span>
<span className="flex items-center gap-1"><Clock
className="w-4 h-4" /> {test.timeLimit || '∞'} хв</span>
</div>
</div>
<div className="flex items-center gap-2">
<button
onClick={(e) => { e.stopPropagation();
router.push(`/teacher/tests/${test.id}/results`); }}
className="p-3 text-slate-400 hover:text-blue-600 hover:bg-
blue-50 rounded-xl transition-all"
title="Всі результати"
>
<Users className="w-5 h-5" />
</button>
<button onClick={(e) => openStatsModal(e, test)} className="p-3
text-blue-600 hover:bg-blue-50 rounded-xl transition-colors"><BarChart3
className="w-5 h-5" /></button>
<button onClick={(e) => { e.stopPropagation();
router.push(`/teacher/tests/${test.id}/edit`); }} className="p-3 text-slate-400
hover:text-slate-600 rounded-xl"><Edit3 className="w-5 h-5" /></button>
<button onClick={(e) => handleDelete(e, test.id)}
disabled={deletingId === test.id} className="p-3 text-slate-400 hover:text-red-
500 rounded-xl"><Trash2 className="w-5 h-5" /></button>
<div className="ml-2 text-slate-300 hidden
md:block">{expandedTestId === test.id ? <ChevronUp /> : <ChevronDown />}</div>
</div>
</div>
{expandedTestId === test.id && (
<div className="px-6 pb-6 pt-2 border-t border-slate-100 animate-
in fade-in slide-in-from-top-2 duration-200 overflow-x-auto">
<table className="w-full text-left text-sm">
<thead className="bg-slate-50 text-[10px] uppercase font-bold
text-slate-400">
<tr>
<th className="px-4 py-3">Студент</th>
<th className="px-4 py-3 text-center">Результат</th>
<th className="px-4 py-3 text-center">Час</th>
<th className="px-4 py-3 text-center">Статус</th>
91
482 ЧДТУ 262357 12 01 10
<th className="px-4 py-3 text-right">Дата</th>
</tr>
</thead>
<tbody className="divide-y divide-slate-50">
{test.results?.length > 0 ? test.results.map(r => (
<tr
key={r.id}
className="hover:bg-blue-50/30 cursor-pointer
transition-colors"
onClick={() =>
router.push(`/teacher/tests/${test.id}/results/${r.id}`)}
>
<td className="px-4 py-3">
<div className="font-bold">{r.student?.name ||
"Анонім"}</div>
<div className="text-[10px] text-slate-
400">{r.student?.email}</div>
</td>
<td className="px-4 py-3 text-center font-mono font-
bold">{r.score}/{r.total}</td>
<td className="px-4 py-3 text-center text-slate-500
font-mono">{formatTime(r.duration)}</td>
<td className="px-4 py-3 text-center">
<span className={`px-2 py-0.5 rounded-full text-
[10px] font-bold uppercase ${r.passed ? 'bg-green-100 text-green-700' : 'bg-red-
100 text-red-700'}`}>
{r.passed ? 'Пройшов' : 'Невдача'}
</span>
</td>
<td className="px-4 py-3 text-right text-slate-400
text-xs">
{new Date(r.createdAt).toLocaleDateString()}
</td>
</tr>
)) : (
<tr><td colSpan={5} className="px-4 py-8 text-center
text-slate-400 italic">Спроб ще не було</td></tr>
)}
</tbody>
</table>
</div>
)}
</div>
))}
</div>
</main>
{selectedTestStats && (
<div className="fixed inset-0 z-50 flex items-center justify-center p-4
bg-slate-900/60 backdrop-blur-sm animate-in fade-in duration-300">
<div className="bg-white w-full max-w-2xl rounded-[2.5rem] shadow-2xl
overflow-hidden animate-in zoom-in-95 duration-300">
<div className="p-8 border-b border-slate-100 flex justify-between
items-start">
<div>
<h2 className="text-2xl font-bold text-slate-900 mb-
1">{selectedTestStats.title}</h2>
<p className="text-slate-500 text-sm">Аналітика тестів •
{selectedTestStats.code}</p>
</div>
<button onClick={() => setSelectedTestStats(null)} className="p-2
hover:bg-slate-100 rounded-full"><X className="w-6 h-6 text-slate-400"
/></button>
92
482 ЧДТУ 262357 12 01 11
</div>
<div className="p-8 space-y-8">
<div className="grid grid-cols-3 gap-4">
<div className="bg-slate-50 p-4 rounded-2xl text-center">
<div className="text-slate-400 text-[10px] uppercase font-bold
mb-1">Середній бал</div>
<div className="text-2xl font-black text-blue-
600">{selectedTestStats.avgScore}%</div>
</div>
<div className="bg-slate-50 p-4 rounded-2xl text-center">
<div className="text-slate-400 text-[10px] uppercase font-bold
mb-1">Успішність</div>
<div className="text-2xl font-black text-emerald-
600">{selectedTestStats.passedCount}/{selectedTestStats.count}</div>
</div>
<div className="bg-slate-50 p-4 rounded-2xl text-center">
<div className="text-slate-400 text-[10px] uppercase font-bold
mb-1">Сер. час</div>
<div className="text-2xl font-black text-purple-
600">{Math.round(selectedTestStats.avgTime/60)}хв</div>
</div>
</div>
<div>
<h4 className="font-bold text-slate-800 mb-4 flex items-center
gap-2">Розподіл результатів</h4>
<div className="flex items-end justify-between h-44 gap-3 px-2
border-b border-slate-100 pb-2">
{(() => {
const maxValue = Math.max(...selectedTestStats.distribution,
1);
return selectedTestStats.distribution.map((val, i) => {
const height = (val / maxValue) * 100;
return (
<div key={i} className="flex-1 flex flex-col items-center
justify-end h-full">
<div className="w-full flex flex-col items-center gap-1
h-full justify-end">
<span className="text-xs font-bold text-blue-
600">{val > 0 ? val : ''}</span>
<div
className="w-full bg-blue-500 rounded-t-lg
transition-all duration-700 ease-out"
style={{ height: `${val > 0 ? Math.max(height, 5) :
2}%`, opacity: val > 0 ? 1 : 0.2 }}
></div>
</div>
<span className="text-[10px] font-bold text-slate-400
mt-2 whitespace-nowrap">
{i * 20}-{(i + 1) * 20}%
</span>
</div>
);
});
})()}
</div>
</div>
</div>
<div className="p-6 bg-slate-50 border-t border-slate-100 flex
justify-end">
93
482 ЧДТУ 262357 12 01 12
<button onClick={() => setSelectedTestStats(null)} className="bg-
slate-900 text-white px-8 py-3 rounded-2xl font-bold hover:bg-slate-800
transition-colors">Закрити</button>
</div>
</div>
</div>
)}
</div>
);
};
const StatCard = ({ title, value, icon, color }) => (
<div className="bg-white p-6 rounded-3xl border border-slate-200 flex items-
start justify-between shadow-sm hover:shadow-md transition-shadow">
<div>
<p className="text-slate-500 text-sm font-medium mb-1">{title}</p>
<div className="text-2xl font-black text-slate-900">{value}</div>
</div>
<div className={`p-3 ${color} rounded-2xl`}>{icon}</div>
</div>
);
export default App;
app/student/dashboard/page.tsx
"use client";
import React, { useState, useEffect, useMemo } from 'react';
import {
CheckCircle2, Star, Search, Loader2, History, Target, Camera, X, Save,
ExternalLink
} from 'lucide-react';
import { useSession } from "next-auth/react";
import Link from 'next/link';
import { PieChart, Pie, Cell, ResponsiveContainer } from 'recharts';
export default function StudentDashboard() {
const { data: session, update, status } = useSession();
const [materials, setMaterials] = useState<any[]>([]);
const [testResults, setTestResults] = useState<any[]>([]);
const [loading, setLoading] = useState(true);
const [searchQuery, setSearchQuery] = useState('');
const [user, setUser] = useState({
id: null as string | null,
name: '',
initials: 'ST',
grade: '8',
avatar: null as string | null,
});
const [isProfileModalOpen, setIsProfileModalOpen] = useState(false);
const [editName, setEditName] = useState("");
const [editGrade, setEditGrade] = useState("");
94
482 ЧДТУ 262357 12 01 13
const [avatarFile, setAvatarFile] = useState<File | null>(null);
const [avatarPreview, setAvatarPreview] = useState<string | null>(null);
const [isSavingProfile, setIsSavingProfile] = useState(false);
useEffect(() => {
if (status === "authenticated" && session?.user) {
const u = session.user;
setUser({
id: (u as any).id || null,
name: u.name || "Студент",
initials: (u.name || "ST").split(' ').filter(Boolean).map(n =>
n[0]).join('').toUpperCase().substring(0, 2),
grade: (u as any).grade || '8',
avatar: u.image || null
});
}
}, [session, status]);
useEffect(() => {
async function fetchData() {
try {
console.log("Завантаження даних для дашборду...");
const [mRes, rRes] = await Promise.all([
fetch('/api/materials'),
fetch('/api/results')
]);
if (mRes?.ok) {
const materialsData = await mRes.json();
console.log("Отримано materials:", materialsData.length);
setMaterials(materialsData);
}
if (rRes?.ok) {
const resultsData = await rRes.json();
console.log("Отримано результати в дашборді:", resultsData);
setTestResults(resultsData);
} else {
console.log("Помилка при завантаженні результатів:", rRes?.status);
}
} catch (err) {
console.error("Помилка завантаження даних:", err);
} finally {
setLoading(false);
}
}
fetchData();
}, []);
95
482 ЧДТУ 262357 12 01 14
const stats = useMemo(() => {
const gradeItems = materials.filter(m => String(m.grade) ===
String(user.grade));
const done = gradeItems.filter(m => m.is_completed).length;
const total = gradeItems.length || 1;
return {
percent: Math.round((done / total) * 100),
chartData: [{ value: done }, { value: Math.max(0, total – done) }]
};
}, [materials, user.grade]);
const toggleStatus = async (id: string, field: string, currentValue: boolean)
=> {
setMaterials(prev => prev.map(m => m.id === id ? { ...m, [field]:
!currentValue } : m));
await fetch(`/api/materials/${id}`, {
method: 'PATCH',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ [field]: !currentValue })
});
};
const handleSaveProfile = async (e: React.FormEvent) => {
e.preventDefault();
if (!user.id || isSavingProfile) return;
setIsSavingProfile(true);
try {
let finalImageUrl = user.avatar;
if (avatarFile) {
const formData = new FormData();
formData.append("file", avatarFile);
const uploadRes = await fetch("/api/upload", { method: "POST", body:
formData });
const uploadData = await uploadRes.json();
finalImageUrl = uploadData.url;
}
const res = await fetch(`/api/users/${user.id}`, {
method: 'PATCH',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ name: editName, grade: editGrade, image:
finalImageUrl }),
});
if (res.ok) {
await update({ ...session, user: { ...session?.user, name: editName,
image: finalImageUrl, grade: editGrade } });
setIsProfileModalOpen(false);
}
} catch (err) { alert("Помилка збереження"); }
finally { setIsSavingProfile(false); }
};
96
482 ЧДТУ 262357 12 01 15
if (loading) return <div className="min-h-screen flex items-center justify-
center bg-white font-black italic uppercase tracking-tighter">Loading...</div>;
return (
<div className="min-h-screen bg-[#fcfcfd] text-slate-900 pb-20">
{/* HEADER */}
<header className="bg-white border-b border-slate-100 sticky top-0 z-40">
<div className="max-w-7xl mx-auto px-6 h-20 flex justify-between items-
center">
<Link href="/" className="flex items-center gap-2 group">
<div className="w-8 h-8 bg-indigo-600 rounded rotate-45 group-
hover:rotate-0 transition-transform" />
<span className="font-black italic text-2xl tracking-tighter
uppercase">School</span>
</Link>
<button
onClick={() => { setEditName(user.name); setEditGrade(user.grade);
setAvatarPreview(user.avatar); setIsProfileModalOpen(true); }}
className="flex items-center gap-4 hover:opacity-70 transition-
opacity"
>
<div className="text-right hidden sm:block leading-none">
<p className="text-[10px] font-black uppercase tracking-
tighter">{user.name}</p>
<p className="text-[8px] text-indigo-600 font-black uppercase
tracking-[0.2em] mt-1">{user.grade} КЛАС</p>
</div>
<div className="w-12 h-12 rounded-full bg-slate-100 border border-
slate-200 overflow-hidden flex items-center justify-center">
{user.avatar ? <img src={user.avatar} className="w-full h-full
object-cover" /> : <span className="font-black text-
[10px]">{user.initials}</span>}
</div>
</button>
</div>
</header>
<main className="max-w-7xl mx-auto px-6 pt-12 space-y-12">
{/* STATS SECTION */}
<div className="grid grid-cols-1 lg:grid-cols-12 gap-8">
{/* КІЛЬЦЕ УСПІШНОСТІ */}
<div className="lg:col-span-4 bg-white border border-slate-100 rounded-
[3rem] p-10 shadow-sm flex flex-col items-center">
<div className="w-48 h-48 relative">
<ResponsiveContainer width="100%" height="100%">
<PieChart>
<Pie data={stats.chartData} innerRadius={65} outerRadius={85}
paddingAngle={5} dataKey="value" startAngle={90} endAngle={-270}>
97
482 ЧДТУ 262357 12 01 16
<Cell fill="#4F46E5" stroke="none" />
<Cell fill="#F1F5F9" stroke="none" />
</Pie>
</PieChart>
</ResponsiveContainer>
<div className="absolute inset-0 flex flex-col items-center
justify-center leading-none">
<span className="text-5xl font-black italic tracking-
tighter">{stats.percent}%</span>
<span className="text-[8px] font-black uppercase text-slate-400
tracking-widest mt-1">Done</span>
</div>
</div>
<h3 className="mt-6 text-[10px] font-black uppercase tracking-[0.3em]
text-slate-400">Навчальний прогрес</h3>
</div>
{/* TIMELINE ІСТОРІЇ */}
<div className="lg:col-span-8 bg-white border border-slate-100 rounded-
[3rem] p-10 shadow-sm">
<div className="flex items-center gap-3 mb-10">
<History className="w-4 h-4 text-indigo-600" />
<h3 className="text-[10px] font-black uppercase tracking-
widest">Останні результати</h3>
</div>
<div className="space-y-6 relative before:absolute before:left-[15px]
before:top-2 before:bottom-2 before:w-[2px] before:bg-slate-50">
{testResults.length > 0 ? testResults.slice(0, 3).map((res, i) => (
<div key={i} className="flex gap-6 items-center relative pl-10">
<div className="absolute left-0 w-8 h-8 rounded-xl bg-white
border-2 border-slate-100 flex items-center justify-center z-10">
<Target size={14} className="text-indigo-600" />
</div>
<div className="flex-1 p-5 bg-slate-50 rounded-[2rem] flex
justify-between items-center group hover:bg-slate-900 transition-colors">
<div>
<p className="text-[10px] font-black uppercase italic text-
slate-800 group-hover:text-white">{res.testTitle}</p>
<p className="text-[8px] font-bold text-slate-400 uppercase
mt-1">{new Date(res.createdAt).toLocaleDateString()}</p>
</div>
<span className="text-xs font-black italic text-indigo-600
bg-white px-4 py-1 rounded-full border border-slate-100">
{res.score}/{res.total}
</span>
</div>
</div>
)) : (
<p className="text-[9px] font-black uppercase text-slate-300 py-
10 text-center">Історія активності порожня</p>
98
482 ЧДТУ 262357 12 01 17
)}
</div>
</div>
</div>
{/* SEARCH */}
<div className="relative">
<Search className="absolute left-8 top-1/2 -translate-y-1/2 text-slate-
300 w-5 h-5" />
<input
type="text" placeholder="ШУКАТИ ТЕМУ..."
className="w-full pl-16 pr-8 py-7 bg-white border border-slate-100
rounded-[2.5rem] outline-none font-black text-[11px] uppercase tracking-[0.2em]
shadow-sm focus:border-indigo-600 transition-all"
value={searchQuery} onChange={(e) => setSearchQuery(e.target.value)}
/>
</div>
{/* MATERIALS LIST */}
<div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-8">
{materials
.filter(m => String(m.grade) === String(user.grade) &&
m.title?.toLowerCase().includes(searchQuery.toLowerCase()))
.map((item) => (
<div key={item.id} className="bg-white p-10 rounded-[3rem] border
border-slate-100 shadow-sm hover:shadow-xl transition-all group overflow-hidden">
<div className="flex justify-between items-start mb-10">
<span className="text-[8px] font-black text-slate-300 uppercase
tracking-widest px-3 py-1 bg-slate-50 rounded-lg">
{item.category?.name || "Topic"}
</span>
<div className="flex gap-2">
<button onClick={() => toggleStatus(item.id, 'is_favorite',
!!item.is_favorite)}>
<Star className={`w-5 h-5 ${item.is_favorite ? 'text-amber-
400 fill-current' : 'text-slate-100 hover:text-slate-200'}`} />
</button>
<button onClick={() => toggleStatus(item.id, 'is_completed',
!!item.is_completed)}>
<CheckCircle2 className={`w-5 h-5 ${item.is_completed ?
'text-green-500 fill-current' : 'text-slate-100 hover:text-slate-200'}`} />
</button>
</div>
</div>
<h3 className={`font-black text-2xl mb-12 uppercase italic leading-
[0.9] tracking-tighter ${item.is_completed ? 'text-slate-200 line-through' :
'text-slate-800'}`}>
{item.title}
</h3>
99
482 ЧДТУ 262357 12 01 18
<a href={item.url} target="_blank" className="flex items-center
justify-between w-full p-5 bg-slate-50 rounded-2xl group-hover:bg-indigo-600
group-hover:text-white transition-all text-[10px] font-black uppercase tracking-
widest">
Відкрити <ExternalLink className="w-4 h-4" />
</a>
</div>
))}
</div>
</main>
{/* PROFILE MODAL */}
{isProfileModalOpen && (
<div className="fixed inset-0 z-50 flex items-center justify-center p-4">
<div className="absolute inset-0 bg-slate-900/60 backdrop-blur-sm"
onClick={() => !isSavingProfile && setIsProfileModalOpen(false)}></div>
<div className="bg-white rounded-[2.5rem] shadow-2xl w-full max-w-md
relative z-10 overflow-hidden">
<div className="bg-slate-900 p-4 flex justify-end">
<button type="button" onClick={() => !isSavingProfile &&
setIsProfileModalOpen(false)} className="text-slate-400 hover:text-white"><X
className="w-6 h-6" /></button>
</div>
<form onSubmit={handleSaveProfile} className="p-8 space-y-6">
<div className="flex flex-col items-center">
<div className="relative group -mt-16">
<div className="w-28 h-28 rounded-full border-4 border-white
shadow-xl overflow-hidden bg-slate-100 flex items-center justify-center text-3xl
font-black text-slate-400">
{avatarPreview ? <img src={avatarPreview} className="w-full
h-full object-cover" /> : user.initials}
</div>
<label className="absolute inset-0 bg-slate-900/60 rounded-full
flex items-center justify-center opacity-0 group-hover:opacity-100 cursor-pointer
transition-opacity">
<Camera className="w-6 h-6 text-white" />
<input type="file" accept="image/*" className="hidden"
onChange={(e) => {
const file = e.target.files?.[0];
if (file) { setAvatarFile(file);
setAvatarPreview(URL.createObjectURL(file)); }
}} />
</label>
</div>
</div>
<div className="space-y-4 font-black uppercase text-[10px]
tracking-widest text-slate-400">
<label className="block">Ім'я
<input type="text" value={editName} onChange={(e) =>
setEditName(e.target.value)} className="w-full mt-2 bg-slate-50 border p-4
100
482 ЧДТУ 262357 12 01 19
rounded-xl font-bold text-slate-900 outline-none focus:border-indigo-600
uppercase" required />
</label>
<label className="block">Клас
<select value={editGrade} onChange={(e) =>
setEditGrade(e.target.value)} className="w-full mt-2 bg-slate-50 border p-4
rounded-xl font-bold text-slate-900 outline-none appearance-none focus:border-
indigo-600">
{[5,6,7,8,9,10,11].map(g => <option key={g}
value={String(g)}>{g} клас</option>)}
</select>
</label>
</div>
<button type="submit" disabled={isSavingProfile} className="w-full
py-5 bg-indigo-600 text-white rounded-xl font-black uppercase text-xs tracking-
widest flex items-center justify-center gap-2 hover:bg-indigo-700 transition-
all">
{isSavingProfile ? <Loader2 className="animate-spin w-4 h-4" /> :
<Save className="w-4 h-4" />}
{isSavingProfile ? "Зберігаємо..." : "Зберегти зміни"}
</button>
</form>
</div>
</div>
)}
</div>
);
}
101
ДОДАТОК В
Програмне забезпечення діагностики дидактичної системи
Інструкція користувачеві
482 ЧДТУ 262357 34 01
Листів 3
Розробник ________________ Дзюндзя Д.М.
Черкаси 2025
482 ЧДТУ. 262357 34 01 2
1. Порядок реєстрації та входу в систему
Для початку роботи необхідно пройти процедуру ідентифікації. Система
розмежовує права доступу на етапі створення облікового запису.
Процедура реєстрації нового користувача:
1. Відкрийте браузер та перейдіть за посиланням на головну сторінку
платформи.
2. Знайдіть у верхньому меню, праворуч кнопку «Реєстрація» та
натисніть її.
3. Заповніть реєстраційну форму, вказавши наступні дані:
прізвище та ім’я (використовується для відображення в журналах);
електронну пошту (ваш майбутній логін);
пароль (мінімум 6 символів);
тип облікового запису (вчитель або учень).
4. Завершіть процедуру натисканням кнопки «Створити акаунт».
Процедура авторизації (Вхід):
на головній сторінці оберіть пункт «вхід»;
введіть вашу пошту та пароль у відповідні поля;
натисніть «увійти». після успішної перевірки даних ви потрапите на
головну панель (dashboard).
2. Робоче місце викладача (teacher module)
Панель вчителя призначена для повного циклу управління навчальним
процесом: від створення контенту до аналізу статистики.
Функціональні блоки головної панелі вчителя:
статистика активності: кількість створених тестів та завантажених
матеріалів;
моніторинг: відображення останніх результатів учнів у реальному часі;
швидкий доступ: кнопки миттєвого переходу до конструктора тестів.
Алгоритм створення нового тесту:
1. Натисніть кнопку «Створити новий тест».
2. У полі заголовка вкажіть назву теми, клас і час на проходження
102
482 ЧДТУ 262357 34 01 3
3. Скористайтеся формою додавання питань. Для кожного питання
необхідно:
написати зміст завдання;
додати варіанти відповідей;
поставити відмітку біля правильного варіанту.
4. Натисніть «Зберегти тест». Після цього система видасть унікальний
код (наприклад, XJ-452), який потрібно повідомити учням.
Робота з цифровою бібліотекою матеріалів:
1. Відкрийте вкладку «Матеріали».
2. Оберіть дію «Додати матеріал».
3. Вкажіть категорію (клас або предмет) та завантажте файл
(підтримується формат PDF та посилання на зовнішні ресурси).
3. Робоче місце учня (student module)
Інтерфейс учня спрощений для того, щоб максимально зосередити увагу на
вивченні матеріалів та тестуванні.
Елементи кабінету учня:
дашборд: візуальний прогрес навчання (діаграми успішності);
журнал оцінок: список усіх пройдених тестів з деталізацією балів;
база знань: доступ до всіх матеріалів, наданих викладачами.
Порядок проходження тесту за кодом:
1. Отримайте від вчителя 6-значний код доступу.
2. На головній сторінці учня введіть код у поле «Код тесту».
3. Натисніть «Почати». На екрані з’являться питання по черзі або
списком.
4. Оберіть правильні, на вашу думку, варіанти відповідей.
5. Використовуйте кнопку «Надіслати результат» для завершення.
Система автоматично перевірить роботу та оновить вашу статистику.
104
ДОДАТОК Г
Програмне забезпечення діагностики дидактичної системи
Графічні матеріали
482 ЧДТУ 262357 90 01
Листів 12
Розробник ________________ Дзюндзя Д.М.
Черкаси 2025
482 ЧДТУ 262357 90 01 2
Рисунок Г.1 – Слайд 1
Рисунок Г.2 – Слайд 2
105
482 ЧДТУ 262357 90 01 3
Рисунок Г.3 – Слайд 3
Рисунок Г.4 – Слайд 4
106
482 ЧДТУ 262357 90 01 4
Рисунок Г.5 – Слайд 5
Рисунок Г.6 – Слайд 6
107
482 ЧДТУ 262357 90 01 5
Рисунок Г.7 – Слайд 7
Рисунок Г.8 – Слайд 8
108
482 ЧДТУ 262357 90 01 6
Рисунок Г.9 – Слайд 9
Рисунок Г.10 – Слайд 10
109
482 ЧДТУ 262357 90 01 7
Рисунок Г.11 – Слайд 11
Рисунок Г.12 – Слайд 12
110
482 ЧДТУ 262357 90 01 8
Рисунок Г.13 – Слайд 13
Рисунок Г.14 – Слайд 14
111
482 ЧДТУ 262357 90 01 9
Рисунок Г.15 – Слайд 15
Рисунок Г.16 – Слайд 16
112
482 ЧДТУ 262357 90 01 10
Рисунок Г.17 – Слайд 17
Рисунок Г.18 – Слайд 18
113
482 ЧДТУ 262357 90 01 11
Рисунок Г.19 – Слайд 19
Рисунок Г.20 – Слайд 20
114
482 ЧДТУ 262357 90 01 12
Рисунок Г.21 – Слайд 21
115