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/9752| Title: | Web-застосунок для інтерактивного вивчення мов програмування |
| Authors: | Заспа, Григорій Олександрович Мамчич, Дмитро Анатолійович |
| Keywords: | ІНЖЕНЕРІЯ ПРОГРАМНОГО ЗАБЕСПЕЧЕННЯ;NESTJS;TYPESCRIPT;REACT;PRISMA ORM;POSTGRESQL;DOCKER;MONACO EDITOR;ZUSTAND;TAILWIND CSS;JWT;REST API;SINGLE PAGE APPLICATION (SPA).;SOFTWARE ENGINEERING;NESTJS;TYPESCRIPT;REACT;PRISMA ORM;POSTGRESQL;DOCKER;MONACO EDITOR;ZUSTAND;TAILWIND CSS;JWT;REST API;SINGLE PAGE APPLICATION (SPA). |
| Issue Date: | 17-Jun-2026 |
| Abstract: | АНОТАЦІЯ
Кваліфікаційна бакалаврська робота Мамчича Дмитра Анатолійовича на тему «Web-застосунок для інтерактивного вивчення мов програмування» зі спеціальності 121 «Інженерія програмного забезпечення». Захист відбувається в Черкаському державному технологічному університеті (ЧДТУ), місто Черкаси, 2026 рік.
Робота містить 108 сторінок, 19 таблиць, 18 рисунків, список використаних джерел з 21 найменувань, 4 додатків.
Робота присвячена проектуванню та реалізації освітньої веб-платформи
«LearnTech» для інтерактивного вивчення програмування з автоматизованим оцінюванням рішень. Актуальність теми зумовлена високим попитом на IT-фахівців та необхідністю впровадження інструментів навчання, які забезпечують студентів миттєвим зворотним зв'язком і усувають потребу розгортання локального середовища розробки. Основна ідея проєкту полягає у створенні захищеного ізольованого серверного ядра (Multi-language Sandbox) для безпечного виконання стороннього коду мовами Python, C++ та JavaScript.
У рамках проєкту розроблено клієнт-серверну систему на базі стеку NestJS, TypeScript, React, Prisma ORM, PostgreSQL та Docker Compose. Реалізовано адаптивний інтерфейс на основі Split-view Layout з інтеграцією редактора коду Monaco Editor, таблиці лідерів (Leaderboard) та керування станом за допомогою Zustand. Автоматизована перевірка рішень базується на динамічному компонуванні коду студента з тест-кейсами (Assertions), а ресурси сервера захищені лімітами контейнеризації та механізмом Timeout Watchdog. Програмний комплекс пройшов тестування за допомогою Jest, Supertest та k6. ANNOTATION Bachelor's qualification thesis by Dmytro Anatoliyovych Mamchych on the topic "Web application for interactive learning of programming languages" in the specialty 121 "Software Engineering". The defense takes place at Cherkasy State Technological University (ChSTU), Cherkasy, 2026. The thesis contains 108 pages, 19 tables, 18 figures, a list of references with 21 items, and 4 appendices. The thesis is devoted to the design and implementation of the educational web platform "LearnTech" for interactive programming learning with automated assessment of solutions. The relevance of the topic is driven by the high demand for IT specialists and the need for educational automation tools that provide students with immediate feedback and eliminate the need for local development environment setup. The core idea lies in creating a secure, isolated server-side execution core (Multi-language Sandbox) for safe execution of third-party code in Python, C++, and JavaScript. Within the framework of the project, a client-server system was developed based on NestJS, TypeScript, React, Prisma ORM, PostgreSQL, and Docker Compose stack. An adaptive user interface based on a Split-view Layout has been implemented, integrating Monaco Editor, a Leaderboard, and state management using Zustand. Automated verification of solutions is based on the dynamic composition of student code with test cases (Assertions), while server resources are protected by containerization limits and a Timeout Watchdog. The software complex was tested using Jest, Supertest, and k6. The information system is fault-tolerant and ready for practical implementation in higher education institutions. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9752 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Мамчич Дмитро Анатолійович.pdf Restricted Access | 4.16 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи бакалавра
на тему: «Web-застосунок для інтерактивного вивчення мов програмування»
Виконав: студент 4 курсу, групи ПЗ-2204
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Мамчич Д. А.
(прізвище та ініціали)
Керівник Заспа Г. О.
(прізвище та ініціали)
Рецензент Левченко С. П.
(прізвище та ініціали)
Черкаси 2026
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
С. Голуб
« » 2026 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Мамчич Дмитро Анатолійович
(прізвище, ім’я, по батькові)
1. Тема роботи: «Web-застосунок для інтерактивного вивчення мов програмування»
Керівник роботи к.т.н., доцент Заспа Григорій Олександрович,
Затверджені наказом Черкаського державного технологічного університету №56/03/03
від «12» березня 2026 року
2. Строк подання студентом роботи 5 червня 2026
3. Вхідні дані до роботи: застосунок для вивчення мов програмування, індивідуальне
налаштування відображення даних.
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань
Розділ 2. Впровадження результату дослідження у практику проектування програмного
забезпечення інформаційних систем
Розділ 3 Розробка та тестування програмного забезпечення
Висновки;
Список використаних джерел;
Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;
Слайди презентації кваліфікаційної роботи
6. Консультанти розділів роботи
7. Дата видачі завдання 12 грудня 2025 року
КАЛЕНДАРНИЙ ПЛАН
Строк
виконання
№
Назва етапів випускної роботи етапів Примітки
п/п випускної
роботи
1 Постановка задачі 15.10.2025 виконано
2 Підготовка завдання 16.10.2025 виконано
3 Погодження завдання 20.10.2025 виконано
4 Затвердження завдання 20.10.2025 виконано
Основна стадія
1 Підбір матеріалів 20.12.2025 виконано
2 Аналіз шляхів вирішення поставленої задачі 21.12.2025 виконано
3 Розрахунок основних параметрів роботи 05.01.2026 виконано
4 Вибір кінцевого варіанту проектного рішення 10.01.2026 виконано
5 Оформлення первісної редакції роботи 15.01.2026 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 12.03.2026 виконано
керівником
2 Оформлення пояснювальної записки роботи в 12.04.2026 виконано
кінцевій редакції
3 Попередній захист роботи 25.05.2026 виконано
4 Затвердження роботи 26.05.2026 виконано
5 Рецензування роботи 27.05.2026 виконано
6 Захист роботи 03.06.2026
Студент Мамчич Д.А.
(підпис) (прізвище та ініціали)
Керівник роботи Заспа Г.О.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Кваліфікаційна бакалаврська робота Мамчича Дмитра Анатолійовича на
тему «Web-застосунок для інтерактивного вивчення мов програмування» зі
спеціальності 121 «Інженерія програмного забезпечення». Захист відбувається в
Черкаському державному технологічному університеті (ЧДТУ), місто Черкаси,
2026 рік.
Робота містить 108 сторінок, 19 таблиць, 18 рисунків, список використаних
джерел з 21 найменувань, 4 додатків.
Робота присвячена проектуванню та реалізації освітньої веб-платформи
«LearnTech» для інтерактивного вивчення програмування з автоматизованим
оцінюванням рішень. Актуальність теми зумовлена високим попитом на IT-
фахівців та необхідністю впровадження інструментів навчання, які забезпечують
студентів миттєвим зворотним зв'язком і усувають потребу розгортання
локального середовища розробки. Основна ідея проєкту полягає у створенні
захищеного ізольованого серверного ядра (Multi-language Sandbox) для
безпечного виконання стороннього коду мовами Python, C++ та JavaScript.
У рамках проєкту розроблено клієнт-серверну систему на базі стеку NestJS,
TypeScript, React, Prisma ORM, PostgreSQL та Docker Compose. Реалізовано
адаптивний інтерфейс на основі Split-view Layout з інтеграцією редактора коду
Monaco Editor, таблиці лідерів (Leaderboard) та керування станом за допомогою
Zustand. Автоматизована перевірка рішень базується на динамічному
компонуванні коду студента з тест-кейсами (Assertions), а ресурси сервера
захищені лімітами контейнеризації та механізмом Timeout Watchdog.
Програмний комплекс пройшов тестування за допомогою Jest, Supertest та k6.
Ключові слова: ІНЖЕНЕРІЯ ПРОГРАМНОГО ЗАБЕСПЕЧЕННЯ,
NESTJS, TYPESCRIPT, REACT, PRISMA ORM, POSTGRESQL, DOCKER,
MONACO EDITOR, ZUSTAND, TAILWIND CSS, JWT, REST API, SINGLE
PAGE APPLICATION (SPA).
ANNOTATION
Bachelor's qualification thesis by Dmytro Anatoliyovych Mamchych on the
topic "Web application for interactive learning of programming languages" in the
specialty 121 "Software Engineering". The defense takes place at Cherkasy State
Technological University (ChSTU), Cherkasy, 2026.
The thesis contains 108 pages, 19 tables, 18 figures, a list of references with 21
items, and 4 appendices.
The thesis is devoted to the design and implementation of the educational web
platform "LearnTech" for interactive programming learning with automated
assessment of solutions. The relevance of the topic is driven by the high demand for IT
specialists and the need for educational automation tools that provide students with
immediate feedback and eliminate the need for local development environment setup.
The core idea lies in creating a secure, isolated server-side execution core (Multi-
language Sandbox) for safe execution of third-party code in Python, C++, and
JavaScript.
Within the framework of the project, a client-server system was developed based
on NestJS, TypeScript, React, Prisma ORM, PostgreSQL, and Docker Compose stack.
An adaptive user interface based on a Split-view Layout has been implemented,
integrating Monaco Editor, a Leaderboard, and state management using Zustand.
Automated verification of solutions is based on the dynamic composition of student
code with test cases (Assertions), while server resources are protected by
containerization limits and a Timeout Watchdog. The software complex was tested
using Jest, Supertest, and k6. The information system is fault-tolerant and ready for
practical implementation in higher education institutions.
Keywords: SOFTWARE ENGINEERING, NESTJS, TYPESCRIPT, REACT,
PRISMA ORM, POSTGRESQL, DOCKER, MONACO EDITOR, ZUSTAND,
TAILWIND CSS, JWT, REST API, SINGLE PAGE APPLICATION (SPA).
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ................................................................ 6
ВСТУП ...................................................................................................................... 8
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ ............................................................................... 12
1.1. Аналіз технічної інформації ....................................................................... 12
1.2. Актуальність задачі ..................................................................................... 12
1.3. Аналіз існуючих програмних засобів ....................................................... 13
1.4. Аналіз способів вирішення задачі ............................................................. 14
1.5. Постановка задачі ........................................................................................ 17
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕСПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ ................................................................................................................. 20
2.1. Моделювання предметної області ............................................................. 20
2.1.1. Предметна область моделювання. Модель предметної області. Словник
предметної області ....................................................................................... 20
2.1.2. Елементи моделювання предметної області ................................... 21
2.1.3. Робоча область моделювання ........................................................... 24
2.2. Формування та аналіз вимог ...................................................................... 25
2.2.1. Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги ........................................................................................................... 25
2.2.2. Формування вимог за допомогою діаграми прецедентів ............... 27
2.3. Проектування логічної структури програмного комплексу ................... 28
2.3.1. Діаграми класів .................................................................................. 28
2.3.2. Діаграми пакетів ................................................................................. 29
2.4. Архітектурне проектування ....................................................................... 31
ЧДТУ 262250.012 ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб. Мамчич Д. А. Літ. Лист Листів
«Web-застосунок для
Перевір. Заспа Г. О. 4
інтерактивного вивчення мов
Н. Контр. Півень О. Б.
програмування»
Затверд. Голуб С. В.
Пояснювальна записка.
2.4.1. Діаграма компонентів ........................................................................ 31
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ................................................................................................... 34
2.5. Моделювання поведінки системи .............................................................. 36
2.5.1. Діаграма діяльності ............................................................................ 36
2.5.2. Діаграма послідовності ...................................................................... 37
2.5.3. Діаграма комунікації.......................................................................... 39
2.5.4. Діаграма скінченного автомату ........................................................ 40
РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ ................................................................................................ 42
3.1. Розробка програмного комплексу ............................................................. 42
3.1.1. Обґрунтування вибору засобів реалізації ........................................ 42
3.1.2. Опис структурної (функціональної) схеми ...................................... 44
3.1.3. Опис логічної схеми системи ............................................................ 46
3.1.4. Розробка бази даних ........................................................................... 48
3.1.5. Розробка інтерфейсу користувача .................................................... 51
3.1.6. Опис розробки програмних компонентів ........................................ 55
3.2. Тестування системи .................................................................................... 57
3.2.1. Модульне тестування ......................................................................... 57
3.2.2. Інтеграційне тестування .................................................................... 59
3.2.3. Системне тестування ......................................................................... 62
3.2.4. Приймальне тестування ..................................................................... 65
3.3. Приклади впровадження програмного комплексу ................................... 68
ВИСНОВКИ .......................................................................................................... 72
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ...........................................................75
ДОДАТОК А .......................................................................................................... 77
ДОДАТОК Б .......................................................................................................... 79
ДОДАТОК В .......................................................................................................... 87
ДОДАТОК Г .......................................................................................................... 95
ЧДТУ 262250.012 ПЗ
Змн. Арк. № докум. Підпис Дата
ЧДТУ 262250.012 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
Shared Types (Спільні типи даних) Концепція використання спільних
інтерфейсів та типів даних TypeScript між фронтендом та бекендом для
забезпечення наскрізної типізації.
DTO (Data Transfer Object, ua. Об'єкт передання даних) Об'єкт, що визначає
структуру даних для пересилання між клієнтом та сервером, а також
використовується для їх валідації.
Sandbox (Пісочниця, ua. Ізольоване середовище) Захищене та обмежене
середовище операційної системи для безпечного виконання стороннього
неперевіреного програмного коду.
Assertion (Логічне твердження, порівняння) Програмний метод автоматичної
перевірки, який порівнює фактичний результат виконання коду студента з
очікуваним еталонним значенням.
Unit Testing (Модульне тестування) Ізольована перевірка коректності
функціонування мінімальних автономних одиниць програмного коду (методів,
сервісів) у відриві від зовнішніх залежностей.
Integration Testing (Інтеграційне тестування) Перевірка коректності взаємодії та
обміну даними між декількома модулями, архітектурними шарами додатка чи
зовнішньою базою даних.
System Testing (Системне тестування) Дослідження поведінки всього
інтегрованого програмного комплексу в умовах, максимально наближених до
реальної промислової експлуатації.
Load Testing (Навантажувальное тестування) Випробування системи з метою
оцінки її пропускної здатності та часу відповіді при масовому паралельному
надсиланні запитів.
Stress Testing (Стрес-тестування) Тестування системи на межі відмови для
визначення її поведінки, точки деградації та характеру виникнення помилок при
екстремальних навантаженнях.
6
ЧДТУ 262250.012 ПЗ
Acceptance Testing (Приймальне тестування) Завершальний етап верифікації
системи за методологією «чорної скриньки» для оцінки її відповідності бізнес-
вимогам та технічному завданню.
Persist Middleware (Проміжне програмне забезпечення збереження стану)
Механізм, що забезпечує автоматичне дублювання та відновлення стану
клієнтського сховища з локальної пам'яті браузера.
Docker-контейнеризація Технологія інкапсуляції програмних компонентів
разом із їхнім середовищем виконання в ізольовані контейнери для забезпечення
портативності розгортання.
API (Application Programming Interface, ua. Інтерфейс прикладного
програмування) Набір готових правил, маршрутів та методів, що надаються
сервером для взаємодії з клієнтською частиною.
Frontend (Клієнтська частина) Візуальна та інтерактивна частина веб-додатка, з
якою безпосередньо взаємодіє користувач у браузері.
Backend (Серверна часть) Внутрішня частина програмного комплексу, що
відповідає за логіку обчислень, обробку запитів, безпеку та взаємодію з бд.
Token (Маркер доступу, JWT) Спеціальний зашифрований код, який
використовується для безсесійної ідентифікації та авторизації користувача при
взаємодії з приватними маршрутами API.
UI/UX (User Interface / User Experience) Комплекс підходів до проектування
зовнішнього вигляду, адаптивності та зручності взаємодії користувача з
інтерфейсом системи.
JSON (JavaScript Object Notation) Текстовий формат обміну даними між
компонентами розподілених систем, побудований на структурі пар ключ-
значення.
ORM (Object-Relational Mapping, ua. Об'єктно-реляційне відображення)
Технологія, що забезпечує автоматичну взаємодію та маніпулювання даними
між об'єктним кодом програми та реляційною базою даних.
БД База даних.
СУБД Система управління базами даних.
7
ЧДТУ 262250.012 ПЗ
ВСТУП
Актуальність теми
Актуальність теми з інженерії програмного забезпечення визначається
потребою у розробці сучасного програмного забезпечення для дистанційної
освіти (E-learning) та забезпечення потреби користувачів у зручному сервісі для
вивчення мов програмування. Такими сервісами виступають LMS-платформи
(Learning Management Systems), які мають функціонал для забезпечення
можливості перегляду теоретичних матеріалів, виконання практичних завдань
безпосередньо у браузері, відстеження власного прогресу та отримання
миттєвого зворотного зв'язку.
У свою чергу, ключовим інструментом для підготовки кваліфікованих IT-
фахівців є практика. Онлайн-платформи дозволяють студентам отримувати
доступ до знань з будь-якої точки світу, знижуючи бар'єр входу в професію.
Можливість автоматизувати процеси перевірки коду, тестування знань та
надання доступу до курсів дозволяють освітнім організаціям збільшувати
ефективність навчання. Більше того, інтерактивні системи відкривають нові
можливості для аналізу успішності студентів, збираючи аналітичні дані в
автоматичному режимі, що дозволяє викладачам та авторам курсів краще
розуміти потреби аудиторії та адаптувати навчальні програми.
Мета розробки
Метою розробки є забезпечення потреб користувачів у якісній технічній
освіті шляхом розробки програмного забезпечення для інтерактивного вивчення
програмування, яке поєднує теоретичну базу та практичне середовище
виконання коду.
Завдання розробки
Завданням є розробка програмного забезпечення та його архітектури, яка
буде відповідати сучасним стандартам веб-розробки.
1 Розробка системи каталогів курсів з фільтрацією по рівню складності
та мовах програмування.
8
ЧДТУ 262250.012 ПЗ
2 Розробка модуля ізольованого виконання коду («пісочниці»), яка
дозволить користувачам писати та запускати програми безпосередньо на сайті.
Програмна реалізація системи забезпечить можливість користувачам
реєструватися, проходити уроки, зберігати свій прогрес та переглядати
статистику навчання.
Об’єкт розробки
Об’єктом розробки є процеси створення програмного забезпечення та
інфраструктури, що забезпечують ефективну та зручну організацію
дистанційного навчального процесу.
Предмет розробки
Предметом розробки є процеси побудови програмного забезпечення для
створення інтерактивної LMS-платформи з підтримкою компіляції коду.
Методи проєктування та конструювання
Для розробки програмного забезпечення були використані наступні
методи та засоби:
1 NestJS – фреймворк для Node.js, був обраний як основна технологія
для реалізації бізнес-логіки серверної частини. NestJS надає модульну
архітектуру, потужний механізм ін'єкції залежностей (Dependency Injection) та
вбудовану підтримку TypeScript, що дозволяє створювати надійні та
масштабовані серверні додатки;
2 React – бібліотека JavaScript/TypeScript для розробки динамічних
інтерфейсів користувача, дозволяє створювати ефективні односторінкові веб-
додатки (SPA). React забезпечує швидкий рендеринг завдяки Virtual DOM та
дозволяє використовувати компонентний підхід для створення складних
елементів інтерфейсу, таких як редактор коду;
3 Zustand – бібліотека для управління станом додатку, яка є легкою та
швидкою альтернативою Redux. Вона допомагає зберігати стан авторизації
користувача та прогрес виконання завдань, спрощуючи взаємодію між
компонентами;
9
ЧДТУ 262250.012 ПЗ
4 PostgreSQL – надійна об'єктно-реляційна система управління
базами даних, була використана для зберігання інформації про користувачів,
курси, уроки та історію проходження завдань;
5 Prisma ORM – інструмент для взаємодії з базою даних, що дозволяє
описувати схему даних у декларативному стилі та забезпечує сувору типізацію
запитів, зменшуючи кількість помилок при роботі з даними;
6 Monaco Editor – бібліотека, що лежить в основі VS Code,
використана для інтеграції повноцінного редактора коду в веб-інтерфейс
платформи;
7 Docker – платформа для контейнеризації, що використовувалася для
розгортання ізольованого середовища бази даних та забезпечення ідентичності
оточення розробки;
8 Git та GitHub – системи контролю версій, які дозволяють
відстежувати зміни в коді та керувати етапами розробки проекту;
9 Postman – інструмент для тестування API, що використовувався для
перевірки коректності роботи серверних ендпоінтів;
10 Об'єктно-орієнтоване програмування (ООП) - Базова парадигма
конструювання, на якій ґрунтується вся логіка системи. Використання ключових
принципів ООП (абстракції, інкапсуляції, успадкування та поліморфізму)
дозволило представити сутності предметної області (користувач, курс, урок,
запуск коду) у вигляді взаємопов'язаних класів, забезпечуючи гнучкість та
повторне використання коду.
11 Концепція Чистої архітектури (Clean Architecture) - Метод
розділення коду на автономні шари (контролери, бізнес-логіка, доступ до даних),
що дозволило повністю ізолювати ядро платформи та логіку перевірки завдань
від особливостей конкретних фреймворків чи СКБД.
Для проектування також були використанні різні UML діаграми (діаграма
прецедентів, діаграма класів, ER-діаграма), що допомагають візуалізувати
структуру та поведінку системи, що розробляється.
Опис отриманих результатів
10
ЧДТУ 262250.012 ПЗ
Розроблено комплексне програмне забезпечення для онлайн-навчання, яке
включає в себе весь необхідний функціонал: систему авторизації, каталог курсів,
інтерактивний редактор коду та модуль перевірки рішень. Спроектовано та
створено реляційну базу даних, яка забезпечує швидкий доступ до інформації
про навчальні матеріали та досягнення студентів. Розроблено програмне
забезпечення, яке відповідає архітектурному стилю RESTful API, що забезпечує
інтерфейс для взаємодії між клієнтом (React-додатком) та сервером. API включає
в себе кінцеві точки для обробки запитів на виконання коду, отримання контенту
уроків та оновлення прогресу користувача. Сервер було успішно інтегровано з
базою даних PostgreSQL, що дозволяє ефективно обробляти велику кількість
одночасних запитів. Також було проведено тестування модуля виконання коду
для забезпечення його безпеки та ізоляції від основної системи.
Практичне значення отриманих результатів
Розроблене програмне забезпечення для вивчення програмування надає
користувачам зручний та ефективний спосіб здобуття нових технічних навичок
без необхідності встановлення складного ПЗ на власний комп'ютер. Система
також автоматизує процес перевірки практичних завдань, що зменшує
навантаження на викладачів або менторів. Завдяки інтеграції з базою даних,
система може збирати корисні дані про успішність студентів та складність
окремих тем. Це дозволяє оптимізувати навчальний процес та підвищити якість
освіти.
Особистий внесок автора: у процесі виконання роботи автор самостійно
спроектував, реалізував та протестував серверну та клієнтську частину
програмного забезпечення. Зокрема, було розроблено архітектуру веб-
застосунку, спроектовано реляційну модель бази даних та реалізовано бізнес-
логіку обробки запитів. Також автором особисто виконано програмну реалізацію
модуля ізольованого виконання коду та інтерактивного клієнтського інтерфейсу.
11
ЧДТУ 262250.012 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1. Аналіз технічної інформації
Стрімкий розвиток цифрових технологій та глобальна трансформація
світової економіки зумовили безпрецедентне зростання попиту на
кваліфікованих фахівців у галузі інженерії програмного забезпечення. Сучасний
ринок праці висуває жорсткі вимоги до розробників, що змушує профільні
навчальні заклади та комерційні освітні центри постійно модернізувати
методики підготовки кадрів. Аналіз технічної інформації у сфері IT-освіти
показує, що традиційні підходи до навчання, які базуються на пасивному
вивченні теоретичного матеріалу або перегляді статичних відеолекцій,
демонструють низьку ефективність. Найбільш критичними проблемами під час
підготовки майбутніх програмістів є тривалий час очікування на перевірку
практичних завдань викладачем, відсутність персоналізації навчання та
складність первинного налаштування локального робочого середовища (IDE,
компіляторів, інтерпретаторів, систем залежностей) на комп'ютерах студентів-
новачків. Для подолання цих бар'єрів сучасні інформаційні системи навчання
(LMS) мають інтегрувати передові вебтехнології, які дозволяють автоматизувати
рутинні процеси контролю знань, переносячи весь цикл написання та компіляції
програмного коду безпосередньо у вікно веббраузера.
1.2. Актуальність задачі
Актуальність розробки інтерактивної інформаційної системи вивчення
програмування «LearnTech» обумовлена необхідністю створення якісного,
відмовостійкого та повністю локалізованого вітчизняного продукту для
підготовки IT-фахівців. На сьогоднішній день більшість глобальних лідерів у
сфері онлайн-освіти або повністю ігнорують український ринок, не надаючи
україномовного інтерфейсу та контенту, або мають занадто високу вартість
комерційних підписок, що робить їх недоступними для масового використання
12
ЧДТУ 262250.012 ПЗ
студентами українських ЗВО. Окрім того, задача автоматизованої та безпечної
перевірки програмного коду мовами C++, Python та JavaScript у режимі
реального часу є технічно складною та вимагає проектування захищених
ізольованих середовищ виконання. Впровадження системи, що поєднує
гейміфікований підхід (накопичення досвіду, глобальні таблиці лідерів), гнучке
мікронавчання у вигляді модульних уроків та миттєву верифікацію рішень у
безпечній «пісочниці» (Sandbox), дозволить суттєво підвищити рівень
залученості студентів, знизити навантаження на професорсько-викладацький
склад та забезпечити якісну підготовку кадрів відповідно до вимог сучасної
індустрії розробки програмного забезпечення.
1.3. Аналіз існуючих програмних засобів
Для визначення функціональних вимог до розроблюваної системи та
виявлення вільних ринкових ніш було проведено детальний порівняльний аналіз
популярних комерційних та некомерційних платформ, що використовуються для
вивчення програмування та підготовки до технічних інтерв'ю. У межах цього
дослідження розглянуто такі відомі програмні засоби, як:
1 Codecademy: Одна з найвідоміших платформ, що пропонує
інтерактивні курси. Її перевагами є вбудований редактор коду, широкий вибір
мов та інтерактивність. Проте недоліками виступають висока вартість підписки,
відсутність української локалізації та закритість платформи.
2 Udemy: Маркетплейс курсів, де кожен може опублікувати свій
контент. Перевагами є величезна кількість курсів, система рейтингів та відгуків.
Головний недолік — формат навчання переважно базується на відео, що вимагає
від студента налаштування локального середовища розробки.
3 LeetCode / Codewars: Платформи для розв'язання алгоритмічних
задач. Вони мають чудову систему перевірки коду, підтримку багатьох мов та
змагальний ефект. Недоліком є відсутність структурованої теоретичної бази,
тому вони підходять для тренування, але не для вивчення мови "з нуля".
13
ЧДТУ 262250.012 ПЗ
Результати порівняльного аналізу існуючих програмних засобів наведено
в таблиці 1.1.
Таблиця 1.1
Порівняльна характеристика аналогів системи
Критерій Codecademy Udemy LeetCode Розроблювана
порівняння система
Вбудований Є Немає Є Є (Monaco Editor)
IDE (рідко)
Теоретична Сильна Сильна Слабка Структурована
база
Локалізація Ні Частково Ні Так (Повна)
(UA)
Вартість Висока Покупка Freemium Безкоштовна/Доступна
($200+/рік) курсів
Гейміфікація Базова Слабко Висока Висока (Leaderboard)
виражена
Підтримка Так Залежить Так Так
C++/Python від відео
1.4. Аналіз способів вирішення задачі
Реалізація сучасної інформаційної системи навчання потребує
обґрунтованого вибору архітектурних паттернів, технологічного стеку та
інструментальних програмних засобів розробки для фронтенд- і бекенд-частин
додатка, а також систем керування базами даних. Для створення гнучкого та
адаптивного інтерфейсу користувача було проаналізовано архітектурний підхід
SPA (Single Page Application) на основі провідних Frontend-фреймворків та
14
ЧДТУ 262250.012 ПЗ
бібліотек: React, Angular та Vue.js. Детальні характеристики та порівняння цих
інструментів наведено в таблиці 1.2.
Таблиця 1.2
Порівняння Frontend-фреймворків
Характеристика React Angular Vue.js
Тип Бібліотека Повноцінний Прогресивний
фреймворк фреймворк
Мова JavaScript/JSX TypeScript JavaScript (TS)
(TS)
Продуктивність Висока (Virtual Середня Висока
DOM)
Крива навчання Середня Висока Низька
(складний)
Екосистема Величезна Велика Зростаюча
На основі проведеного аналізу для реалізації клієнтської частини було
обрано бібліотеку React, оскільки використання Virtual DOM забезпечує високу
швидкість динамічного оновлення вебсторінок, що є критичним для стабільної
інтеграції професійного редактора коду Monaco Editor.
Додаткові інструменти Frontend:
1 Vite: Використовується замість Webpack через значно вищу швидкість
"холодного" запуску та HMR (Hot Module Replacement).
2 Tailwind CSS: Дозволяє прискорити верстку завдяки використанню
утилітарних класів, а також має вбудовану підтримку темної теми (dark mode).
3 Zustand: Легковаговий менеджер стану, який простіший та швидший за
Redux, і ідеально підходить для зберігання даних сесії користувача.
15
ЧДТУ 262250.012 ПЗ
Для серверної частини (Backend) розглядалися платформи Node.js, Python
(Django) та Java (Spring), порівняльна характеристика яких наведена в таблиці
1.3.
Таблиця 1.3
Порівняння Backend-технологій
Характеристика Node.js Python (Django) Java (Spring)
Модель I/O Асинхронна (Non- Синхронна Багатопотокова
blocking) (переважно)
Швидкість Висока Висока Середня
розробки
Продуктивність Висока для I/O задач Середня Висока
Типізація TypeScript Dynamic Static
(опціонально)
Оптимальним засобом розробки серверної частини інформаційної системи
було обрано програмну платформу Node.js у поєднанні з прогресивним
фреймворком NestJS. NestJS є інноваційним інструментом для побудови
ефективних, надійних та масштабованих серверних додатків корпоративного
рівня на мові TypeScript. Головна перевага цього фреймворка полягає в тому, що
він «з коробки» надає строгу, детерміновану архітектуру додатка, яка базується
на чіткому розподілі відповідальності між компонентами. Це дозволяє
розробнику створювати чистий, легко підтримуваний та тестований код (Clean
Code), що повністю відповідає сучасним канонам архітектурного патерну SOLID
та концепціям чистої архітектури Роберта Мартіна. Доцільність вибору NestJS як
базового бекенд-інструменту для платформи «LearnTech» була повноцінно
обрана для організації та збереження інформації, було проведено порівняльний
аналіз між реляційними та нереляційними системами керування базами даних
16
ЧДТУ 262250.012 ПЗ
(СКБД), обґрунтовується такими ключовими технічними факторами та
функціональними перевагами результати якого зведено в таблиці 1.4.
Таблиця 1.4
Порівняння SQL та NoSQL для LMS системи
Критерій Реляційні (PostgreSQL, Нереляційні (MongoDB)
MySQL)
Структура даних Строга, таблична (Schema- Гнучка (Schema-less),
based). Ідеально для чітких документи JSON. Підходить
зв'язків (Студент -> Курс -> для неструктурованих даних.
Урок).
Зв'язки Потужна підтримка JOIN- Реалізується програмно, що
(Relations) запитів. може бути повільним.
Транзакції Повна підтримка. Гарантує Підтримка обмежена (хоча
(ACID) цілісність (якщо урок покращилась у нових
пройдено — прогрес версіях).
записано).
Масштабованість Вертикальна (потужніший Горизонтальна (шардінг).
сервер).
За результатами аналізу обґрунтовано використання реляційної СКБД
PostgreSQL, оскільки структура даних навчальної платформи вимагає підтримки
строгих зв'язків між сутностями користувачів, курсів, модулів та транзакційного
збереження метрик прогресу.
1.5. Постановка задачі
На основі комплексного аналізу аналогів, інструментальних засобів та
оцінки потенційних ризиків за допомогою методології SWOT-аналізу
17
ЧДТУ 262250.012 ПЗ
(результати якого наведено в таблиці 1.5), було сформульовано чітку постановку
задачі та конкретизовано вимоги до розробки системи.
Таблиця 1.5
SWOT-аналіз розроблюваної системи «LearnTech»
Сильні сторони (Strengths) Слабкі сторони (Weaknesses)
1. Локалізація: Повна підтримка 1. Обмежений контент: На етапі
української мови, що є унікальною запуску кількість курсів менша, ніж
перевагою на національному ринку. у гігантів ринку (Udemy).
2. Доступність: Безкоштовна модель 2. Відсутність мобільного додатку:
розповсюдження (Open Source / Система працює лише як веб-версія
Freemium). (хоча й адаптивна).
3. Технологічність: Використання 3. Залежність від сервера:
сучасного стеку (NestJS, React), що Виконання коду потребує
забезпечує швидкодію. постійного інтернет-з'єднання.
Можливості (Opportunities) Загрози (Threats)
1. Масштабування: Додавання нових мов 1. Конкуренція: Поява української
(Java, Go, Rust). локалізації у Codecademy або
Coursera.
2. B2B сектор: Впровадження системи в
навчальні заклади (університети, 2. DDoS-атаки: Ризик атак на сервер
школи). виконання коду.
3. Спільнота: Створення форуму та 3. Зміна технологій: Швидке
системи менторства. застарівання обраних фреймворків.
Метою кваліфікаційної роботи є проектування та програмна реалізація
веб-орієнтованої інформаційної системи «LearnTech» для інтерактивного
навчання та автоматизованої перевірки знань з програмування. Для досягнення
поставленої мети необхідно вирішити такі основні завдання:
18
ЧДТУ 262250.012 ПЗ
Функціональні завдання:
1 Для неавторизованого користувача (Гостя): Перегляд головної
сторінки, каталогу доступних курсів, таблиці лідерів (Leaderboard) та можливість
реєстрації/входу в систему.
2 Для авторизованого користувача (Студента): Вхід в особистий
кабінет, редагування профілю, запис на курс.
3 Модуль проходження уроку: Забезпечення читання теоретичного
матеріалу з підсвіткою синтаксису, написання коду безпосередньо в браузері,
його запуск (Run) та відправка на автоматичну перевірку (Submit).
4 Інтерфейсні завдання: Перегляд власного прогресу, перемикання
тем інтерфейсу (Dark/Light Mode) та мови.
Нефункціональні та безпекові завдання:
1 Надійність та Продуктивність: Система повинна коректно
обробляти помилки в коді користувача (наприклад, нескінченні цикли) і не
припиняти роботу. Час завантаження сторінок не повинен перевищувати 2-3
секунди, а час виконання простого коду — не більше 1-2 секунд.
2 Ергономічність та Масштабованість: Інтерфейс повинен бути
інтуїтивно зрозумілим і адаптивним. Архітектура має дозволяти інтеграцію
нових мов програмування без зміни ядра.
3 Безпека (OWASP): Код користувача повинен виконуватися в
ізольованому середовищі (Sandbox) для унеможливлення доступу до файлової
системи сервера чи мережі:
1 Реалізація захисту від ін'єкцій за допомогою Prisma ORM.
2 Забезпечення безпечної автентифікації за допомогою JWT (JSON
Web Tokens).
3 Захист конфіденційних даних шляхом хешування паролів за
алгоритмом Bcrypt із сіллю не менше 10 раундів.
19
ЧДТУ 262250.012 ПЗ
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ
ДОСЛІДЖЕНЬ У ПРАКТИКУ ПРОЕКТУВАННЯ
ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ
2.1. Моделювання предметної області
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметною областю даного дослідження є сфера дистанційної ІТ-освіти
(E-learning), зокрема процеси автоматизованого навчання основам
програмування за допомогою веб-технологій. Модель предметної області
відображає ключові бізнес-процеси, які відбуваються під час взаємодії
користувача з освітньою платформою: реєстрацію здобувачів освіти, управління
доступом до навчальних матеріалів, процес безпосереднього написання
програмного коду та його автоматичну верифікацію на віддаленому сервері.
Для забезпечення однозначного розуміння термінології під час
проектування та розробки програмного продукту, було сформовано розширений
словник предметної області:
1 LMS (Learning Management System) – система управління навчанням,
що забезпечує доставку освітнього контенту, адміністрування навчального
процесу та відстеження академічного прогресу студентів.
2 Студент (Користувач) – зареєстрований учасник системи, який
проходить навчальні курси, має власний профіль та накопичує статистику
успішності.
3 Курс – базова навчальна одиниця, що становить собою сукупність
тематично пов'язаних уроків, об'єднаних спільною метою (наприклад, вивчення
мови JavaScript).
4 Урок – структурний елемент курсу, що містить теоретичний матеріал у
форматі Markdown та практичне завдання, яке вимагає написання коду.
20
ЧДТУ 262250.012 ПЗ
5 Executor (Модуль виконання коду) – ізольоване серверне середовище
(Sandbox), яке забезпечує безпечний запуск, компіляцію (за потреби) та
перевірку програмного коду, написаного невідомим користувачем, без ризику
пошкодження основної операційної системи сервера.
6 IDE (Integrated Development Environment) – інтегроване середовище
розробки; у контексті даної кваліфікаційної роботи – браузерний редактор коду
(інтегрована бібліотека Monaco Editor), що підтримує підсвічування синтаксису
та автодоповнення.
7 JWT (JSON Web Token) – відкритий стандарт (RFC 7519) для
створення токенів доступу, який використовується для безпечної автентифікації
користувачів у системі без необхідності зберігання стану сесії на сервері
(Stateless).
8 REST API (Representational State Transfer) – архітектурний стиль
взаємодії компонентів розподіленого додатку в мережі, який використовується
для обміну даними між клієнтською (Frontend) та серверною (Backend)
частинами платформи.
2.1.2 Елементи моделювання предметної області
На основі глибокого аналізу предметної області було виділено ключові
елементи (інформаційні сутності), які циркулюють у системі, зберігаються в базі
даних та підлягають обробці:
1 Сутність User (Користувач): Відображає обліковий запис студента.
Містить ідентифікаційні дані та облікові дані для входу.
2 Сутність Course (Курс): Описує навчальну дисципліну, її метадані,
рівень складності та загальний опис для відображення в каталозі.
3 Сутність Lesson (Урок): Деталізує конкретний крок навчання.
Містить не лише текстову інформацію, а й програмні шаблони (startCode) та
тестові сценарії (testCode).
4 Сутність UserProgress (Прогрес користувача): Зв'язуюча сутність,
яка фіксує факт успішного виконання певного уроку конкретним користувачем.
21
ЧДТУ 262250.012 ПЗ
Використовується для розрахунку загальної успішності та формування таблиці
лідерів.
Ці елементи формують реляційну модель бази даних. Для уникнення
надлишковості інформації та аномалій при оновленні, схема бази даних була
спроектована з дотриманням правил нормалізації та приведена до Третьої
нормальної форми (3NF). Нижче наведено детальні специфікації основних
елементів предметної області.
Таблиця 2.1
Специфікація елемента (таблиці) User
Атрибут Тип даних Обмеження Опис
Unique, Not Електронна пошта, що використовується
email String
Null як логін.
Ім'я користувача, що відображається в
name String Not Null
профілі та рейтингах.
Хеш пароля користувача (у відкритому
password String Not Null
вигляді не зберігається).
Відносний або абсолютний шлях до
avatar String Nullable
файлу зображення профілю.
Системна відмітка часу дати реєстрації
createdAt DateTime Default(Now)
облікового запису.
22
ЧДТУ 262250.012 ПЗ
Таблиця 2.2
Специфікація елемента (таблиці) Course
Атрибут Тип даних Обмеження Опис
slug String Unique, Not URL-сумісна назва для формування
Null SEO-friendly посилань (напр. js-
basics).
title String Not Null Назва курсу українською мовою.
description Text Not Null Короткий опис курсу для сторінки
каталогу.
level String Default('Beginn Рівень складності матеріалу
er') (Beginner, Intermediate, Advanced).
Таблиця 2.3
Специфікація елемента (таблиці) Lesson
Тип
Атрибут Обмеження Опис
даних
FK (Ref: Зовнішній ключ, що вказує на
courseId Integer
Course) приналежність до курсу.
23
ЧДТУ 262250.012 ПЗ
Продовження таблиці 2.3
title String Not Null Заголовок конкретного уроку.
Теоретичний матеріал, відформатований
content Text Not Null
мовою розмітки Markdown.
Початковий шаблон коду, який
startCode Text Not Null
завантажується в редактор користувача.
Прихований код для автоматичної перевірки
testCode Text Nullable
правильності рішення студента.
2.1.3. Робоча область моделювання
Робоча область моделювання (System Boundary) визначає межі системи,
що проектується. Вона чітко розмежовує процеси, які автоматизуються в рамках
даної дипломної роботи, від зовнішніх факторів та систем.
Робоча область охоплює взаємодію кінцевого користувача з клієнтським
веб-інтерфейсом (вибір навчального курсу, читання теоретичного матеріалу,
безпосереднє написання коду в браузері), передачу цих даних через мережу
Інтернет за допомогою API-запитів, обробку складної бізнес-логіки на сервері
(маршрутизація, компіляція, тестування коду) та збереження результатів
успішності у реляційній базі даних. Процеси створення контенту (повноцінна
панель адміністратора для завантаження нових курсів), а також процеси
фінансового білінгу (оплата за курси) на даному етапі винесені за межі робочої
області базового моделювання, оскільки система розглядається як безкоштовний
освітній інструмент.
24
ЧДТУ 262250.012 ПЗ
2.2. Формування та аналіз вимог
2.2.1. Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника та розробника. Функціональні та
нефункціональні вимоги
Первинною (глобальною) вимогою до проекту є створення єдиного,
відмовостійкого освітнього веб-середовища, яке здатне об'єднати теорію та
практику програмування в єдиному інтерфейсі без необхідності встановлення
додаткового програмного забезпечення на комп'ютер клієнта.
Детальні вимоги формуються на основі декомпозиції первинної вимоги і
включають:
1 Реалізацію високопродуктивного інтерактивного редактора коду
безпосередньо в браузері.
2 Забезпечення підтримки виконання та компіляції декількох мов
програмування з різними парадигмами (зокрема інтерпретованих JavaScript,
Python та компільованої C++).
3 Впровадження підсистеми гейміфікації (нарахування балів,
формування глобального рейтингу лідерів) для стимулювання безперервного
навчання студентів.
4 Створення системи безперебійної автоматичної перевірки синтаксису
та логіки написаного коду.
Усі зібрані вимоги до інформаційної системи класифікуються на дві великі
категорії: функціональні (описують, що саме система повинна робити) та
нефункціональні (описують атрибути якості, тобто як система повинна
працювати).
Функціональні вимоги:
1 Управління доступом: Система повинна підтримувати реєстрацію,
авторизацію та автентифікацію користувачів за допомогою сучасних методів
криптографічного захисту (JWT).
25
ЧДТУ 262250.012 ПЗ
2 Навігація та контент: Система повинна надавати публічний доступ до
каталогу курсів. Авторизовані користувачі повинні мати змогу записуватися на
курси.
3 Виконання коду: Платформа повинна приймати фрагменти коду від
клієнта, виконувати їх на сервері, перехоплювати стандартні потоки виводу
(stdout, stderr) і повертати результати клієнту в режимі реального часу.
4 Аналітика прогресу: Система зобов'язана автоматично зберігати
статус проходження кожного уроку та виводити загальний відсоток завершення
курсу.
Нефункціональні вимоги:
1 Безпека (Security): Найкритичніша вимога системи. Оскільки
платформа виконує код користувачів, цей процес повинен відбуватися в суворо
ізольованому середовищі (Sandbox) для запобігання атакам типу Remote Code
Execution (RCE). Крім того, паролі користувачів заборонено зберігати у
відкритому вигляді; вони повинні хешуватися алгоритмом Bcrypt із
використанням солі ("salt").
2 Швидкодія та продуктивність (Performance): Час реакції
клієнтського інтерфейсу на дії користувача не повинен перевищувати 200 мс.
Процес компіляції та виконання коду (за винятком "холодного старту"
контейнерів) повинен займати не більше 2-3 секунд.
3 Надійність (Reliability): Модуль виконання коду повинен вміти
примусово переривати процеси (Timeout Exception), якщо користувач написав
нескінченний цикл (while(true)), тим самим запобігаючи перевантаженню
процесора сервера (захист від DoS-атак).
4 Ергономічність (Usability): Інтерфейс користувача повинен бути
адаптивним (Responsive Web Design), підтримувати зміну кольорових тем
(Світла/Темна) для зниження навантаження на зір користувача під час тривалого
написання коду.
26
ЧДТУ 262250.012 ПЗ
2.2.2. Формування вимог за допомогою діаграми прецедентів
Діаграма прецедентів (Use Case Diagram) є базовим інструментом
візуального моделювання UML, який використовується для відображення
функціональних вимог системи з точки зору кінцевого користувача.
Для розроблюваної системи виділено два основні актори: «Гість»
(неавторизований відвідувач сайту) та «Студент» (авторизований користувач).
1 Актор «Гість» взаємодіє з прецедентами загального доступу: перегляд
каталогу курсів, ознайомлення з таблицею лідерів, а також ініціювання
процедури створення нового облікового запису (реєстрація).
2 Актор «Студент» є спадкоємцем актора «Гість» і отримує розширений
доступ до прецедентів: запис на курс, доступ до навчальних матеріалів уроку,
редагування програмного коду в IDE, запуск коду на виконання та відправка його
на автоматичну перевірку. Прецедент перевірки коду включає (через зв'язок
<<include>>) приховані системні прецеденти компіляції та збереження
результатів.
Рисунок 2.1 – Діаграма прецедентів (Use Case Diagram)
27
ЧДТУ 262250.012 ПЗ
2.3. Проектування логічної структури програмного комплексу
2.3.1. Діаграми класів
Діаграма класів (Class Diagram) відіграє ключову роль в об'єктно-
орієнтованому проектуванні. Вона демонструє статичну структуру системи,
відображаючи класи, їх атрибути, методи та взаємозв'язки між ними. У контексті
сучасних веб-фреймворків (наприклад, NestJS) класи часто відповідають
моделям даних бази даних або DTO (Data Transfer Objects).
На діаграмі класів розроблюваної системи чітко виділено основні класи
моделей: User, Course, Lesson та UserProgress. Наприклад, між класом Course та
Lesson існує зв'язок типу композиція (або агрегація), де один об'єкт курсу (1)
може містити безліч об'єктів уроків (0..*). Між User та Lesson зв'язок набагато
складніший: один студент може пройти багато уроків, а один урок можуть
пройти багато студентів. Для вирішення цього відношення багато-до-багатьох
(*..*) вводиться клас-асоціація UserProgress, який містить додаткові атрибути,
такі як дата успішного завершення завдання.
Окрім сутностей збереження даних, діаграма класів візуалізує внутрішню
логіку ядра обробки та перевірки рішень. Ключовим у цій структурі є клас
`ExecutorService`, який агрегує спеціалізовані класи ізольованих компіляторів та
інтерпретаторів, відповідальних за запуск стороннього неперевіреного коду.
Взаємодія між `ExecutorService` та об'єктами мовних середовищ реалізована на
основі принципу інверсії управління (IoC), де загальний інтерфейс верифікації
гарантує однакову поведінку для обробників кодів Python, C++ та JavaScript.
Метод валідації всередині сервісу приймає об'єкт класу-контейнера запиту, що
містить вихідний код студента та масив логічних тверджень (Assertions), після
чого ініціює асинхронне виконання у дочірньому підпроцесі операційної
системи. Для зв'язку з базою даних сервіси використовують клас-посередник
`PrismaService`, який забезпечує атомарність транзакцій під час оновлення
об'єктів досвіду (XP) користувача, гарантуючи високу консистентність,
відмовостійкість та масштабованість архітектури вебдодатка.
28
ЧДТУ 262250.012 ПЗ
Рисунок 2.2 – Діаграма класів (Class Diagram)
2.3.2. Діаграми пакетів
Оскільки система проектується на базі сучасного фреймворку NestJS,
архітектура додатку є суворо модульною. Діаграма пакетів (Package Diagram)
візуалізує спосіб організації коду у великі логічні блоки (пакети або модулі) та
залежності між ними. Це дозволяє уникнути сильної зв'язності коду (Tight
Coupling) та підвищити його придатність до повторного використання
(Reusability).
Архітектура серверної частини системи поділяється на наступні ключові
пакети:
1 AppModule: Головний (кореневий) пакет, який агрегує всі інші
модулі та відповідає за ініціалізацію додатку, підключення до бази даних та
глобальні налаштування.
29
ЧДТУ 262250.012 ПЗ
2 AuthModule: Пакет, що інкапсулює логіку безпеки. Він містить
сервіси для валідації паролів та контролери для видачі JWT-токенів. Цей модуль
має пряму залежність від UsersModule для перевірки існування користувача.
3 UsersModule: Пакет управління профілями. Забезпечує CRUD-
операції (створення, читання, оновлення, видалення) для сутності користувача.
4 CoursesModule: Найбільший інформаційний пакет, що відповідає за
надання навчального контенту, обробку запитів щодо прогресу навчання та
генерацію рейтингових таблиць.
5 ExecutorModule: Найбільш ізольований технічний пакет. Його
єдина відповідальність — приймати текстовий рядок з кодом, взаємодіяти з
дочірніми процесами операційної системи (child_process) та повертати результат
виконання. Він не залежить від жодного іншого бізнес-модуля системи.
Рисунок 2.3 – Діаграма пакетів (Package Diagram)
30
ЧДТУ 262250.012 ПЗ
2.4. Архітектурне проектування
2.4.1. Діаграма компонентів
Діаграма компонентів (Component Diagram) показує, як система
розбивається на фізичні або логічні компоненти з високим рівнем абстракції, а
також визначає інтерфейси (API), через які ці компоненти обмінюються
інформацією.
Основними компонентами системи є:
1 Клієнтський SPA-додаток (React UI Component): Відповідає за
відображення інтерфейсу та управління станом на стороні браузера
(використовуючи Zustand).
2 API Gateway / Backend Application (NestJS): Центральний компонент
обробки бізнес-логіки. Він надає REST-інтерфейси для клієнта.
3 Database Component (PostgreSQL): Компонент зберігання
персистентних даних. Зв'язок із ним відбувається через об'єктно-реляційне
відображення (Prisma ORM Component).
4 Code Execution Engine: Компонент середовища виконання, який може
бути реалізований як набір Docker-контейнерів або пулу ізольованих процесів
ОС.
Для забезпечення безперебійної взаємодії клієнтського компонента з
сервером було розроблено специфікацію інтерфейсів у стилі REST. Кожен запит
містить HTTP-метод, шлях (URL) та стандартизоване тіло запиту у форматі
JSON. Взаємодія між компонентами побудована на основі чітко визначених
інтерфейсів (Provided/Required Interfaces), що ізолює бізнес-логіку від
інфраструктурних шарів. NestJS асинхронно делегує туди завдання на
компіляцію у вигляді JSON-об'єктів, приймаючи назад стандартизовані
результати виконання (stdout, stderr та ліміти часу). Такий підхід гарантує
безпеку системи та спрощує її масштабування.
31
ЧДТУ 262250.012 ПЗ
Таблиця 2.4
Інтерфейси компонента автентифікації (Auth Component API)
Метод URL Формат тіла запиту
Опис операції
HTTP Ендпоінту (Request Body)
Вхід існуючого { "email":
POST /api/auth/login користувача та генерація "[email protected]",
токена доступу "password": "123" }
Створення нового { "email": "...",
POST /api/auth/register профілю користувача в "password": "...", "name":
базі даних "..." }
Отримання даних Відсутнє (дані
GET /api/users/me власного профілю передаються в HTTP
(потребує JWT токен) Headers)
Таблиця 2.5
Інтерфейси компонента курсів та виконання (Courses Component
API)
Метод URL
Опис операції Примітки до реалізації
HTTP Ендпоінту
Отримання списку всіх Публічний доступ.
GET /api/courses
доступних курсів Повертає масив об'єктів.
32
ЧДТУ 262250.012 ПЗ
Продовження таблиці 2.5
Отримання детальної Включає вкладені
GET /api/courses/:slug інформації про курс та масиви даних про
його уроки контент уроку.
Відправка написаного Потребує токен. Тіло: {
POST /api/courses/:id/check коду на серверну "userCode": "...", "lang":
перевірку "js" }
Рисунок 2.4 – Діаграма компонентів (Component Diagram)
33
ЧДТУ 262250.012 ПЗ
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Діаграма розгортання (Deployment Diagram) візуалізує топологію
апаратних засобів, на яких буде розгорнута система, та розподіл програмних
компонентів по цих вузлах. Для реалізації платформи обрано класичну
трирівневу архітектуру (Three-Tier Architecture), яка дозволяє масштабувати
кожен рівень незалежно від інших.
Фізична або віртуальна інфраструктура складається з наступних вузлів:
1 Вузол клієнта (Client Device / Browser Node): Робоче місце студента.
Це може бути персональний комп'ютер, ноутбук або планшет. Основним
програмним забезпеченням тут є сучасний веб-браузер (Chrome, Safari, Firefox),
всередині якого виконується завантажений JavaScript-код клієнтського React-
застосунку.
2 Вузол веб-сервера (Application Server Node): Сервер (або хмарна
віртуальна машина VPS), що працює під управлінням ОС Linux. На цьому вузлі
запущено середовище Node.js, яке виконує код серверної частини NestJS. Цей
вузол безпосередньо приймає HTTP-запити від клієнтів.
3 Вузол виконання коду (Execution Environment Node): Для
забезпечення безпеки цей вузол може бути логічно виділений у вигляді
ізольованих Docker-контейнерів, розміщених на тому ж або окремому фізичному
сервері. Тут знаходяться компілятори GCC для C++, інтерпретатори Python та
ізольовані середовища Node.js для перевірки коду користувача.
4 Вузол бази даних (Database Server Node): Виділений сервер або
окремий контейнер, на якому працює СКБД PostgreSQL. Доступ до цього вузла
ззовні (з Інтернету) суворо заборонений брандмауером (Firewall); взаємодія
відбувається виключно через внутрішню мережу із сервером додатків. Для
забезпечення максимальної ізоляції в межах Docker-інфраструктури цей вузол
розміщується всередині приватної віртуальної підмережі, що унеможливлює
пряме сканування портів або спроби несанкціонованого підключення до
34
ЧДТУ 262250.012 ПЗ
стандартного порту 5432. Сервер додатків NestJS здійснює автентифікацію та
маніпулювання даними через технологічний шар Prisma ORM, використовуючи
оптимізований пул з'єднань (Connection Pooling), що запобігає вичерпанню
лімітів оперативної пам'яті вузла при пікових навантаженнях під час сесій
тестування. На рівні конфігурації СКБД застосовано суворі правила авторизації
з обмеженими правами доступу для системного користувача додатка, а також
активовано механізми автоматичного логування транзакцій та збереження
консистентності даних. Таке архітектурне рішення гарантує абсолютну безпеку
конфіденційної інформації користувачів, контенту багатомовних курсів та
метрик прогресу, ізолюючи сховище від будь-яких зовнішніх векторів атак та
вразливостей.
Рисунок 2.5 – Діаграма розгортання (Deployment Diagram)
35
ЧДТУ 262250.012 ПЗ
2.5. Моделювання поведінки системи
Моделювання поведінки є надзвичайно важливим етапом для розуміння
того, як система функціонує в динаміці, як змінюються стани об'єктів та які
алгоритми лежать в основі бізнес-процесів.
2.5.1. Діаграма діяльності
Діаграма діяльності (Activity Diagram) найкраще підходить для
моделювання складних алгоритмічних процесів з розгалуженнями. Найбільш
критичним та алгоритмічно складним процесом у даній розробці є процес
компіляції та виконання недовіреного користувацького коду на сервері.
Алгоритм процесу, описаний діаграмою діяльності, включає наступні
кроки:
1 Початок процесу: сервер приймає запит із рядком вихідного коду та
мовою програмування.
2 Система генерує унікальне ім'я та створює тимчасовий файл на диску
сервера у директорії /temp/.
3 Відбувається розгалуження (Умова: яка мова обрана?):
1 Якщо мова інтерпретована (JavaScript, Python), алгоритм одразу
переходить до етапу запуску відповідного інтерпретатора.
2 Якщо мова компільована (C++), алгоритм спочатку запускає
процес компіляції (g++ source.cpp -o exec). Якщо під час компіляції
виявлено синтаксичну помилку, процес переривається, і помилка
повертається користувачу.
4 Запуск коду: система виконує файл, встановлюючи таймер обмеження
часу (наприклад, 2 секунди).
5 Зчитування даних: система перехоплює стандартні потоки виводу
консолі (стандартний вивід stdout та потік помилок stderr).
6 Сміттєзбирання (Garbage Collection): усі тимчасові файли та
скомпільовані бінарні файли примусово видаляються з диска.
36
ЧДТУ 262250.012 ПЗ
7 Формування результату: система аналізує отриманий вивід, порівнює
його з еталонним результатом (якщо це перевірка завдання) і формує фінальний
статус, який відправляється на клієнт.
Рисунок 2.6 – Діаграма діяльності (Activity Diagram)
2.5.2. Діаграма послідовності
Діаграма послідовності (Sequence Diagram) розкриває часову динаміку та
порядок взаємодії між різними об'єктами або підсистемами під час виконання
37
ЧДТУ 262250.012 ПЗ
одного конкретного сценарію. Розглянемо сценарій «Відправка коду на
перевірку та збереження прогресу».
Життєвий цикл сценарію виглядає так:
1 Студент натискає кнопку "Run" в інтерфейсі (React UI).
2 Клієнтський додаток формує POST-запит і відправляє його на сервер.
3 На сервері запит спочатку потрапляє до компонента AuthGuard
(Охоронець), який перевіряє валідність переданого JWT-токена та ідентифікує
студента.
4 У разі успіху, запит передається до LessonsController. Контролер
валідує вхідні дані (чи не пустий код) і викликає ExecutorService.
5 ExecutorService взаємодіє з операційною системою, створює дочірній
процес (child_process.spawn) і чекає його завершення асинхронно.
6 Отримавши успішний результат виконання, контролер звертається до
PrismaClient (ORM) із вказівкою оновити таблицю UserProgress (записати, що
цей студент пройшов цей урок).
7 База даних PostgreSQL підтверджує запис транзакції.
8 Контролер формує об'єкт JSON з повідомленням про успіх і повертає
його клієнту.
9 React UI отримує відповідь і оновлює інтерфейс (змінює колір
індикатора уроку на зелений).
Описана послідовність кроків чітко демонструє асинхронну природу
обробки запитів, де кожна ланка ланцюга виконує строго визначену функцію без
блокування основного потоку подій. Таке проектування взаємодії дозволяє
ізолювати етап виконання коду від шару персистенції даних, забезпечуючи
високу відмовоустійкість та цілісність системи навіть у разі виникнення помилок
на стороні компілятора.
38
ЧДТУ 262250.012 ПЗ
Рисунок 2.7 – Діаграма послідовності (Sequence Diagram)
2.5.3. Діаграма комунікації
Діаграма комунікації (Communication Diagram, раніше відома як
Collaboration Diagram) показує не стільки час взаємодії (як діаграма
послідовності), скільки структурні зв'язки між об'єктами, які обмінюються
повідомленнями. Вона ілюструє, як об'єкти співпрацюють для досягнення певної
мети.
Розглянемо процес формування таблиці лідерів (Leaderboard). Цей процес
вимагає ефективної комунікації між об'єктами доступу до даних:
1 Клієнт звертається до об'єкта LeaderboardController.
2 Контролер комунікує із сервісом AnalyticsService.
3 AnalyticsService не має власних даних, тому він відправляє складний
агрегаційний запит до об'єкта PrismaClient.
4 PrismaClient ініціює з'єднання з Database, виконує SQL-запит з
використанням операторів GROUP BY, COUNT та ORDER BY DESC, щоб
обчислити сумарний прогрес кожного користувача.
5 Відсортовані дані у вигляді масиву об'єктів (Топ-10 студентів)
повертаються назад через сервіс до контролера і далі на клієнт для рендерингу
компонента рейтингу.
39
ЧДТУ 262250.012 ПЗ
Рисунок 2.8 – Діаграма комунікації (Communication Diagram)
2.5.4. Діаграма скінченного автомату
Поведінка окремих складних об'єктів у системі моделюється за допомогою
діаграми скінченного автомату (State Machine Diagram). Вона показує всі
можливі стани, в яких може перебувати об'єкт, і події, що викликають перехід з
одного стану в інший. Найбільш показовим у розроблюваній системі є життєвий
цикл задачі на виконання користувацького скрипта (об'єкт типу Code Execution
Job).
Процес (Job) може перебувати у таких станах:
1 Pending (Очікування): Початковий стан. Запит надійшов на сервер,
відбувається валідація даних, виділення пам'яті та створення тимчасових файлів
на файловій системі.
2 Compiling (Компіляція): Специфічний стан виключно для
компільованих мов (C++). Код перетворюється компілятором g++ на машинний
бінарний файл.
3 Running (Виконання): Активна фаза. Скомпільована програма або
інтерпретований скрипт (Node.js/Python) безпосередньо виконується в
оперативній пам'яті сервера (або в межах Sandbox-контейнера).
4 Success (Успішне завершення): Кінцевий стан. Програма
відпрацювала коректно, повернула код виходу 0 (Exit Code 0), і система успішно
зчитала стандартний потік виводу.
40
ЧДТУ 262250.012 ПЗ
5 Failed (Завершення з помилкою): Кінцевий стан. Виникла
синтаксична помилка, помилка компіляції або помилка виконання в самій
програмі користувача (Runtime Error). Потік помилок stderr записується в лог.
6 Terminated (Примусово перервано): Критичний кінцевий стан.
Процес був примусово зупинений (вбитий) операційною системою за сигналом
SIGTERM або SIGKILL через перевищення ліміту часу виконання (Timeout),
щоб захистити сервер від нескінченних циклів.
Рисунок 2.9 – Діаграма скінченного автомату (State Machine Diagram)
41
ЧДТУ 262250.012 ПЗ
РОЗДІЛ 3. ПРОГРАМНА РЕАЛІЗАЦІЯ ТА ТЕСТУВАННЯ
ІНФОРМАЦІЙНОЇ СИСТЕМИ
3.1. Розробка програмного комплексу
3.1.1. Обґрунтування вибору засобів реалізації
Проектування та розробка сучасної інтерактивної навчальної платформи з
автоматизованою перевіркою вихідного коду користувачів вимагає застосування
технологічного стеку, здатного забезпечити високу швидкість обробки
асинхронних запитів, масштабованість інфраструктури, строгу типізацію даних
та безпеку виконання користувацьких скриптів. В основі програмного комплексу
"LearnTech" лежить архітектурний шаблон рознесення обов’язків між
клієнтською частиною (Frontend) та серверною частиною (Backend), які
організовані в межах єдиного монорепозиторію (Monorepo). Вибір підходу
Monorepo обґрунтований необхідністю забезпечення наскрізної типізації,
синхронного ведення протоколів взаємодії та спрощення процесів безперервної
інтеграції та розгортання системи.
Серверна частина системи функціонує в середовищі виконання Node.js і
побудована на базі прогресивного фреймворку NestJS. Вибір NestJS зумовлений
його строгою архітектурною моделлю, яка за замовчуванням реалізує патерни
проектування Dependency Injection (впровадження залежностей) та Inversion of
Control (інверсія управління). Це дозволяє створювати ізольовані,
слабкопов'язані модулі, які легко піддаються тестуванню та модифікації.
Використання мови TypeScript на бекенді забезпечує виявлення помилок
невідповідності типів ще на етапі компіляції, що критично важливо при обробці
комплексних структур даних, таких як абстрактні синтаксичні дерева або об'єкти
конфігурації Sandbox-середовища. Завдяки асинхронній неблокуючій моделі
введення-виведення Node.js, сервер здатний ефективно керувати великою
кількістю паралельних мережевих з'єднань, що виникають під час активної
роботи студентів з інтерактивними завданнями.
42
ЧДТУ 262250.012 ПЗ
Для взаємодії з реляційною базою даних було обрано систему керування
базами даних (СКБД) PostgreSQL у поєднанні з сучасною ORM Prisma.
PostgreSQL є промисловим стандартом для систем, що потребують суворої
відповідності принципам ACID (атомарність, узгодженість, ізольованість,
довговічність), та забезпечує високу швидкість виконання складних реляційних
вибірок. Prisma виступає в ролі декларативного інструменту моделювання, який
автоматично генерує типизований клієнт бази даних на основі централізованої
схеми. Це повністю усуває людський фактор при написанні сирих SQL-запитів,
мінімізує ризики виникнення синтаксичних помилок та захищає додаток від
уразливостей типу SQL-ін'єкцій.
Клієнтська частина платформи розроблена як односторінковий застосунок
(SPA) на базі бібліотеки React 18 з використанням інструменту збирання Vite.
React надає компонентно-орієнтований підхід до побудови користувацьких
інтерфейсів, що дозволяє перевикористовувати елементи керування та
динамічно оновлювати стан сторінки без її повного перезавантаження.
Інструмент Vite обрано замість традиційного Webpack завдяки використанню
нативних ECMAScript-модулів (ESM), що забезпечує миттєвий запуск сервера
розробки та надшвидке гаряче перезавантаження модулів (HMR).
Для реалізації інтерактивного тренажера програмування в інтерфейс
системи вбудовано професійний редактор коду Monaco Editor, який є ядром
середовища VS Code. Він надає повноцінний функціонал розробки
безпосередньо у веб-браузері: підсвітку синтаксису, автоматичне закриття
дужок, індексацію та інтелектуальне автодоповнення коду (IntelliSense).
Менеджмент стану клієнтського додатка реалізовано за допомогою бібліотеки
Zustand. Вона забезпечує мінімалістичний, продуктивний та децентралізований
підхід до управління глобальними даними через React-хуки, а вбудований
модуль розширення Persist Middleware дозволяє автоматично синхронізувати
стан авторизації та локальні чернетки написаного студентом коду з локальним
сховищем браузера (LocalStorage). Стилізація інтерфейсу виконана за
допомогою утилітарного CSS-фреймворку Tailwind CSS, що дозволяє гнучко
43
ЧДТУ 262250.012 ПЗ
адаптувати відображення під будь-які розширення екранів без написання
громіздких медіа-запитів.
Ядро автоматичної перевірки рішень реалізовано на рівні операційної
системи сервера за допомогою вбудованого модуля Node.js child_process. Замість
використання важких сторонніх хмарних компіляторів, система динамічно
створює ізольовані підпроцеси для інтерпретації та тестування надісланого коду
мовою Python. Такий підхід забезпечує мінімальний рівень накладних витрат
(Overhead) на створення кожної окремої "пісочниці", дозволяючи жорстко
контролювати виділені системні ресурси (процесорний час та оперативну
пам'ять) для захисту від шкідливого або зацикленого коду.
3.1.2. Опис структурної (функціональної) схеми
Структурна схема інформаційної системи "LearnTech" базується на
класичній триланковій архітектурі (Three-Tier Architecture), яка логічно та
фізично розділяє рівень представлення даних, рівень обробки бізнес-логіки та
рівень персистентного збереження інформації. Кожен рівень ізольований від
інших, а взаємодія між ними регламентується суворими інтерфейсами та
протоколами передачі даних.
На першому рівні (Client Layer) знаходиться веб-додаток, який функціонує
в браузері користувача. Клієнтська архітектура розділена на модулі
відображення сторінок (Pages), багаторазові інтерфейсні компоненти
(Components) та сервісний шар взаємодії з API (API Layer). Клієнтський шар
відправляє асинхронні HTTP-запити на сервер за допомогою екземпляра Axios.
Безпека передачі даних та ідентифікація сесій забезпечується механізмом Axios
Interceptors, який автоматично перехоплює кожен вихідний запит та імплантує в
заголовок Authorization криптографічний токен JWT (JSON Web Token),
отриманий після успішної автентифікації.
Другий рівень (Application Server Layer) представляє собою модульний
моноліт під управлінням NestJS. Архітектура сервера побудована навколо
концепції контекстних модулів. Вхідні запити спочатку потрапляють на рівень
маршрутизації та глобальних перехоплювачів (Guards / Pipes). Валідаційні пайпи
44
ЧДТУ 262250.012 ПЗ
перевіряють структуру вхідних пакетів даних на відповідність встановленим
об'єктам перенесення даних (DTO). Авторизаційні гварди декодують і
верифікують цифрові підписи токенів. Після успішного проходження первинних
фільтрів запит спрямовується у відповідний контролер, який викликає
обчислювальні методи бізнес-сервісів. Головною особливістю архітектури є
виділений сервіс ExecutorService, який взаємодіє з підсистемою введення-
виведення ОС для розгортання короткоживучих обчислювальних ізольованих
контейнерів розробки.
Третій рівень (Database Layer) відповідає за надійне збереження та
забезпечення цілісності інформації. Рівень складається з сервера СКБД
PostgreSQL та прошарку абстракції Prisma ORM. Prisma генерує оптимізовані
SQL-запити на основі викликів методів у сервісах бекенду, транслюючи
реляційні рядки таблиць у строго типізовані об'єкти TypeScript-класів.
Для детальної візуалізації взаємодії компонентів системи нижче наведено
структурну схему в нотації UML:
Фрагмент кода
@startuml
package "Client Layer (React SPA)" {
component [Monaco Editor Component] as Monaco
component [Zustand State Store] as Store
component [Axios API Client] as Axios
component [UI Views (Pages/Components)] as UI
}
package "Application Server Layer (NestJS)" {
component [Auth Guard & Validation Pipe] as Gate
component [App Controllers Routing] as Controllers
component [Business Logic Services] as Services
component [Executor Sandbox Core] as Executor
}
45
ЧДТУ 262250.012 ПЗ
package "Data Layer" {
component [Prisma ORM Client] as Prisma
database "PostgreSQL Database" as DB
}
UI --> Store : Оновлення стану
Monaco --> UI : Передача коду
UI --> Axios : Ініціація дій
Axios --> Gate : HTTP REST API (JWT)
Gate --> Controllers : Валідований запит
Controllers --> Services : Виклик бізнес-методу
Services --> Executor : Запуск коду на перевірку
Services --> Prisma : Робота з моделями даних
Prisma --> DB : Нативні SQL-запити
@endum
Вся взаємодія здійснюється за асинхронним принципом. Клієнт ніколи не
блокує інтерфейс користувача під час очікування відповіді від сервера,
відображаючи інтерактивні індикатори завантаження контенту.
3.1.3. Опис логічної схеми системи
Логічна схема відображає внутрішні інформаційні потоки, динаміку
взаємодії об'єктів та послідовність зміни станів компонентів системи під час
виконання ключових операцій користувача. Найбільш критичним та логічно
складним процесом у системі "LearnTech" є надсилання написаного студентом
вихідного коду на автоматизовану системну перевірку. Цей процес вимагає
координації декількох підсистем, забезпечення безпеки операцій та обробки
різноманітних виняткових ситуацій.
Логіка виконання процесу перевірки рішення складається з таких
послідовних кроків:
46
ЧДТУ 262250.012 ПЗ
1 Ініціація на клієнті: Студент завершує редагування програмного
коду в інтерфейсі Monaco Editor і натискає кнопку «Відправити на перевірку».
Клієнтський додаток зчитує текстовий масив із редактора, формує DTO запиту
(що містить lessonId та текстове поле code) та відправляє POST-запит на ендпоінт
/courses/submit.
2 Автентифікація та перевірка прав доступу: Глобальний
AuthGuard сервера перехоплює запит, вилучає JWT-токен із заголовків,
розшифровує його за допомогою секретного ключа і перевіряє роль користувача.
Доступ надається лише у випадку, якщо токен є валідним, а роль користувача
відповідає значенню STUDENT.
3 Валідація структури: ValidationPipe аналізує тіло запиту. Якщо
поле code порожнє або перевищує максимально допустимий розмір символів,
запит негайно відхиляється з поверненням HTTP-статусу 400 Bad Request.
4 Збір метаданих з БД: Контролер передає керування у
CoursesService. Сервіс через Prisma ORM робить запит до бази даних для
отримання інформації про поточний урок (Lesson). З таблиці вилучається
приховане поле testCode — набір системних юніт-тестів (Assertion-перевірок),
створених автором курсу для даного завдання.
5 Формування виконуваного пакета: Об'єкт передається в
ExecutorService. Сервіс генерує унікальний ідентифікатор сесії (UUID) та
створює тимчасову ізольовану директорію на диску сервера. У цю директорію
записується файл скрипту, який містить об’єднаний код: спочатку імпортується
або вставляється код студента, а після нього додається код системних тестів.
6 Ізольоване виконання: Сервіс запускає асинхронний дочірній
процес інтерпретатора Python за допомогою функції exec. Процесу передаються
жорсткі обмеження операційної системи. Запускається таймер контролю
(Timeout Watchdog).
7 Аналіз результатів обчислень: Після завершення роботи
підпроцесу аналізується код повернення (Exit Code):
47
ЧДТУ 262250.012 ПЗ
- Якщо Exit Code дорівнює 0, це означає, що код
скомпілювався/інтерпретувався успішно і всі вбудовані тести пройдено. Статус
рішення встановлюється як SUCCESS.
- Якщо Exit Code не дорівнює 0, аналізується потік помилок stderr.
Статус встановлюється як FAILED із фіксацією тексту помилки.
- Якщо спрацював таймер тайм-ауту, підпроцес примусово
знищується сигналом SIGKILL. Статус встановлюється як TIMEOUT.
8 Фіналізація та збереження прогресу: Якщо статус успішний,
CoursesService ініціює транзакцію в базі даних через Prisma: створюється або
оновлюється запис у таблиці UserProgress, користувачу нараховуються бали
досвіду (XP). Тимчасові файли на диску повністю видаляються за допомогою
асинхронних методів модуля fs/promises.
9 Повернення відповіді: Сервер формує об'єкт відповіді з детальними
результатами (статус, системний вивід stdout, помилки stderr, нараховані бали)
та повертає його клієнту з HTTP-статусом 200 OK для візуалізації в терміналі
користувача. Нижче наведено діаграму послідовності (Sequence Diagram), яка
деталізує часову шкалу та взаємодію об'єктів під час цього логічного процесу:
Рисунок 3.1 – Діаграма послідовності
3.1.4. Розробка бази даних
48
ЧДТУ 262250.012 ПЗ
Проектування реляційної моделі бази даних для інформаційної системи
"LearnTech" здійснювалося на основі детального аналізу сутностей предметної
області та зв'язків між ними. Для запобігання надликовості даних, усунення
потенційних аномалій модифікації та забезпечення максимальної швидкодії під
час виконання операцій зчитування й запису, схему бази даних було приведено
до вимог третьої нормальної форми (3НФ).
Основними сутностями системи є:
1 User — зберігає облікові та авторизаційні дані користувачів, а також
визначає їхні системні ролі.
2 Course — описує навчальні курси, доступні на платформі.
3 Module — представляє собою логічний тематичний розділ
конкретного курсу.
4 Lesson — безпосередній практичний або теоретичний урок, який
містить контент завдання та системні скрипти валідації коду.
5 UserProgress — проміжна суตність, яка фіксує історію взаємодії
студентів із навчальними матеріалами та прогрес виконання практичних завдань.
Для реалізації декларативного опису моделей даних, управління
міграціями та забезпечення строгової типізації об'єктів на рівні додатка
застосовано інструментарій Prisma ORM. Використання схеми schema.prisma
дозволило централізовано спроектувати реляційну структуру, де зв'язки між
сутностями User, Course, Module та Lesson описані на рівні декларативних
директив @relation. Завдяки впровадженню концепції наскрізної типізації,
автоматично згенерований клієнт Prisma Client експортує строго типізовані
об'єкти та моделі безпосередньо у загальний простір монорепозиторію (Shared
Types). Це гарантує, що будь-які зміни в структурі таблиць бази даних
PostgreSQL автоматично валідуються комбілятором TypeScript як на стороні
сервера NestJS при обробці бізнес-логіки, так і на стороні клієнта React під час
відображення інтерфейсу.
49
ЧДТУ 262250.012 ПЗ
Рисунок 3.2 – ER-модель
Рисунок 3.3 – PrismaORM
Зв'язки між сутностями спроектовані за такими правилами реляційної
цілісності:
1 Каскадне видалення (ON DELETE CASCADE): Накладено на
зв'язки Course -> Module, Module -> Lesson, а також на зовнішні ключі таблиці
UserProgress. Це гарантує, що при видаленні навчального курсу або облікового
запису користувача, всі пов'язані з ними дочірні записи та логи прогресу будуть
50
ЧДТУ 262250.012 ПЗ
автоматично зачищені базою даних, запобігаючи появі "загублених" рядків
(Orphaned Rows) та порушенню посилальної цілісності.
2 Індексація даних: Поля email у таблиці User та slug у таблиці Course
мають атрибут @unique. Це автоматично створює унікальні B-Tree індекси на
рівні PostgreSQL, забезпечуючи швидкість виконання операцій пошуку записів
за цими полями за константний або логарифмічний час $O(1) / O(\log N)$ замість
повного сканування всієї таблиці (Full Table Scan).
3 Складений унікальний індекс: У моделі UserProgress директива
@@unique([userId, lessonId]) створює унікальний складений індекс. Це логічне
обмеження унеможливлює створення дублюючих записів прогресу для однієї й
тієї ж пари студент-урок, захищаючи систему від повторного несанкціонованого
нарахування балів досвіду за одне й те саме завдання.
3.1.5. Розробка інтерфейсу користувача
Інтерфейс користувача інформаційного комплексу "LearnTech"
спроектовано відповідно до сучасних стандартів UX/UI дизайну, з орієнтацією
на максимальну простоту навігації, мінімізацію когнітивного навантаження та
швидку візуальну відповідь системи на дії користувача. Весь дизайн системи
підтримує концепцію чуйності (Responsive Design) та адаптований для
комфортної роботи як на великих моніторах стаціонарних комп'ютерів, так і на
ноутбуках з обмеженою робочою областю екрана (аж до ширини 1024px, що є
нижнім лімітом для зручного написання програмного коду).
Головна сторінка каталогу курсів реалізована за допомогою гнучкої сітки
CSS Grid. Кожна картка курсу містить назву, текстовий опис, індикатор
складності (Beginner, Intermediate, Advanced) та кнопку переходу. Для
запобігання ефекту Layout Shift (різкого зміщення елементів сторінки під час
асинхронного завантаження даних із сервера) розроблено спеціальні
компоненти-скелетони (Skeleton Loaders). Вони імітують геометричну форму
карток курсів за допомогою сірих блоків з ефектом пульсуючої CSS-анімації,
забезпечуючи плавний візуальний перехід від стану завантаження до
відображення реального контенту.
51
ЧДТУ 262250.012 ПЗ
Рисунок 3.4 – Головна сторінка додатку
Основне робоче середовище студента — сторінка проходження
практичного заняття (LessonPage) — використовує дворівневу вертикально
розділену блочну модель (Split-view Layout). Ліва частина екрана займає 40%
загальної ширини і призначена для вивчення теорії. Текст лекції зберігається в
базі даних у форматі Markdown та динамічно рендериться на клієнті в чистий
HTML за допомогою безпечного парсера з підключенням плагіна підсвічування
синтаксису для фрагментів коду, що зустрічаються в теорії. Це дозволяє авторам
курсів гнучко форматувати тексти, додавати таблиці, списки та виділення
важливих концепцій. Технічно цей процес забезпечується використанням
бібліотеки ̀ react-markdown` у поєднанні з інструментом ̀ rehype-highlight` на базі
`highlight.js`, що гарантує коректне відображення конструкцій мов C++, Python
та JavaScript. Такий підхід повністю усуває вразливості типу XSS (Cross-Site
Scripting), оскільки будь-які сторонні шкідливі HTML-теги автоматично
екрануються під час парсингу. Окрім цього, інтегрований компонент
розділювача меж (Resizer) надає користувачеві можливість індивідуально
налаштовувати ширину робочих областей за допомогою перетягування мишкою,
забезпечуючи високий рівень ергономіки, фокусування на навчальному
52
ЧДТУ 262250.012 ПЗ
матеріалі та адаптивності інтерфейсу під монітори з різною роздільною
здатністю.
Рисунок 3.5 – Робоча зона
Права частина робочої області (60% ширини екрана) містить інтегровану
середу розробки. В її основі лежить компонент Monaco Editor, обернений у React-
контейнер для управління життєвим циклом вихідного коду. Редактор
синхронізований із локальним станом Zustand. Коли студент змінює символи в
редакторі, дані оновлюються в пам'яті додатка. Під областю редактора
розташована панель управління, що містить кнопки «Запустити код» (для
локального тестування виводу) та «Відправити на перевірку».
Нижню частину правої панелі займає кастомний емулятор терміналу. Він
стилізований під класичну консоль розробника (чорний фон, моноширинний
шрифт JetBrains Mono). Термінал динамічно виводить інформацію, що
надходить від сервера після виконання скриптів. Повідомлення
диференціюються за кольором для швидкого зчитування інформації: успішне
53
ЧДТУ 262250.012 ПЗ
виконання та проходження тестів підсвічується зеленим кольором, помилки
синтаксису або невдалі Assertion-тести — яскраво-червоним із виведенням
детального трасування логів (Stack Trace), а системні повідомлення — жовтим
або білим кольорами.
Рисунок 3.6 – Термінал та робоче середовище
Сторінка особистого профілю студента містить аналітичні віджети.
Поточний прогрес вивчення курсів візуалізується у вигляді графічних смуг
прогресу (Progress Bars), які обчислюють відсоткове співвідношення виконаних
уроків до їхньої загальної кількості в курсі. Таблиця лідерів (Leaderboard)
представляє собою строго структурований табличний елемент, де впорядковано
відображаються аватари, імена студентів та обсяг накопичених балів XP. Дані
таблиці лідерів оновлюються асинхронно, підтримуючи змагальний елемент у
навчальному процесі. Для забезпечення високої продуктивності інтерфейсу та
виключення зайвих повторних запитів до API бекенду під час перемикання між
віджетами, керування даними профілю та рейтингу реалізовано на стороні
клієнта за допомогою менеджера стану Zustand. Використання спеціалізованого
проміжного програмного забезпечення Persist Middleware дозволяє автоматично
кешувати поточний стан прогресу та профілю користувача у локальному
сховищі браузера (LocalStorage), що гарантує миттєве відображення аналітики
54
ЧДТУ 262250.012 ПЗ
навіть при нестабільному мережевому з'єднанні. Асинхронне оновлення таблиці
лідерів базується на оптимізованих HTTP-запитах, які фоново актуалізують
лише змінені позиції студентів у масиві рейтингу.
Рисунок 3.7 – Профіль
3.1.6. Опис розробки програмних компонентів
55
ЧДТУ 262250.012 ПЗ
Програмна архітектура компонентів бекенду платформи "LearnTech"
базується на принципах модульної декомпозиції, високої когезії (High Cohesion)
та слабкого зв'язку (Loose Coupling) між сервісами. Основним обчислювальним
компонентом системи, який відповідає за автоматизовану перевірку рішень
користувачів, є сервіс ExecutorService, що входить до складу модуля виконання.
Для управління навчальним процесом та маршрутизації запитів
розроблено контролер CoursesController, який приймає дані від клієнта.
Опис взаємодії розроблених серверних компонентів:
1 Інкапсуляція логіки: CoursesController не містить жодного рядка
коду, що відповідає за роботу з файлами чи процесами ОС. Його єдиний
обов'язок — прийняти HTTP-запит, довірити JwtAuthGuard перевірку токена
сесії, розпарсити вхідне DTO та передати чисті параметри далі за архітектурним
ланцюжком.
2 Забезпечення безпеки (Sandbox-ізоляція): ExecutorService
інкапсулює унікальну логіку створення захищеного оточення. Використання
генератора uuidv4() повністю виключає колізії імен файлів при одночасному
надсиланні запитів від сотень різних студентів. Створення окремої вкладеної
папки для кожної сесії гарантує, що один процес виконання Python жодним
чином не зможе отримати доступ, прочитати чи модифікувати файли сусіднього
паралельного процесу перевірки.
3 Контроль витоку ресурсів (Watchdog та ulimit): Встановлення
параметра timeout: 3000 на рівні системного виклику exec гарантує, що
операційна система автоматично надішле сигнал SIGTERM/SIGKILL
дочірньому процесу, якщо він не завершиться самостійно протягом 3 секунд. Це
повністю нівелює загрозу відмови в обслуговуванні (DoS-атаки) через запуск
нескінченних циклів типу while True: pass. Додаткове каскадування через
системну утиліту ulimit -v обмежує віртуальну пам'ять підпроцесу, захищаючи
оперативну пам'ять основного сервера від переповнення при спробах виділення
гігантських масивів даних у студентському коді.
56
ЧДТУ 262250.012 ПЗ
4 Гарантоване вивільнення ресурсів: Блок finally в методі
runValidation виконується завжди, незалежно від того, чи завершився код
успішно, чи впав із критичною помилкою, чи був убитий за тайм-аутом. Це
ліквідує ризики накопичення "сміттєвих" файлів на жорсткому диску сервера,
запобігаючи переповненню дискового простору при тривалій експлуатації
інформаційного комплексу.
3.2. Тестування системи
Етап верифікації та валідації розробленого програмного комплексу є
критично важливою складовою забезпечення надійності, відмовостійкості та
безпеки інформаційної системи «LearnTech». Специфіка платформи, яка полягає
в динамічному отриманні, компонуванні та виконанні стороннього
неперевіреного програмного коду користувачів, вимагає впровадження
комплексної багаторівневої стратегії тестування.
Для гарантування стабільності архітектурних шарів та відповідності
системи вимогам міжнародного стандарту якості програмного забезпечення
ISO/IEC 25010, було застосовано класичну модель піраміди тестування (Testing
Pyramid). Цей підхід дозволяє диференціювати перевірки за рівнями ізоляції та
деталізації: від автономного тестування окремих функцій до комплексного
аналізу поведінки системи під критичним навантаженням та оцінки
користувацького інтерфейсу.
3.2.1. Модульне тестування
Модульне тестування (Unit Testing) спрямоване на ізольовану перевірку
коректності функціонування мінімальних автономних одиниць програмного
коду, таких як окремі класи, методи та сервіси бізнес-логіки, у повністю
відірваному від зовнішніх залежностей середовищі. Головним інструментом для
проектування, автоматизації та виконання модульних тестів у межах серверної
частини NestJS було обрано фреймворк Jest.
Основний фокус модульного тестування було зосереджено на аналізі
надійності ядра системи — класу ExecutorService, оскільки саме цей
57
ЧДТУ 262250.012 ПЗ
компонент безпосередньо взаємодіє з операційною системою сервера через
підпроцеси. Для забезпечення детермінованості тестів та унеможливлення
впливу стану файлової системи чи бази даних на результати перевірки, суміжні
модулі, зокрема вбудовані функції fs/promises та метод exec модуля
child_process, були замінені на фіктивні аналоги (Mocks).
Таблиця 3.1
Тест-кейс TC-UT-001: Модульна перевірка валідного коду рішення
Параметр тест-
Опис та вміст параметра
кейсу
ID тест-кейсу TC-UT-001
Модуль системи Ядро виконання коду (ExecutorService)
Верифікація обробки логічно та синтаксично коректного
Назва / Мета
Python-коду.
Сервіс ініціалізований. Зовнішні модулі ОС fs та
Початкові умови
child_process зафіксовані у стані Mock.
studentCode = "def core(): return True", testCode = "assert
Вхідні дані
core() == True"
1. Викликати метод runValidation з вказаними
параметрами коду.
Кроки виконання
2. Перехопити об'єкт відповіді сервісу.
3. Перевірити виклики методів очищення диска.
Очікуваний Метод повертає об'єкт зі статусом SUCCESS. Метод fs.rm
результат викликаний для поточної папки.
Фактичний Повернуто статус SUCCESS. Об'єкт відповіді містить
результат чистий потік stdout. Папку видалено.
58
ЧДТУ 262250.012 ПЗ
Таблиця 3.2
Тест-кейс TC-UT-002: Модульна перевірка обробки синтаксичної
помилки
Параметр тест-
Опис та вміст параметра
кейсу
ID тест-кейсу TC-UT-002
Модуль системи Ядро виконання коду (ExecutorService)
Перевірка перехоплення помилок компіляції/інтерпретації
Назва / Мета
з потоку stderr.
Дочірній процес налаштований на повернення коду
Початкові умови
помилки Exit Code = 1.
studentCode = "def broken_func(" (незакрита дужка,
Вхідні дані
синтаксичний збій).
1. Передати некоректний рядок у метод runValidation.
Кроки виконання
2. Оцінити прапорець статусу обробки помилки.
Очікуваний Метод повертає об'єкт зі статусом FAILED. Рядок error
результат містить текст SyntaxError.
Фактичний Статус встановлено в FAILED. Опис помилки синтаксису
результат успішно зчитано з stderr.
Статус Пройдено (PASSED)
3.2.2. Інтеграційне тестування
Метою інтеграційного тестування (Integration Testing) є перевірка
коректності взаємодії між декількома програмними модулями, різними
архітектурними шарами додатка та зовнішніми інфраструктурними
59
ЧДТУ 262250.012 ПЗ
компонентами, такими як реальна база даних PostgreSQL. На відміну від
модульних випробувань, інтеграційні тести не ізолюють залежності, а
досліджують правильність проходження інформаційного пакета крізь увесь стек.
Для проектування та автоматизації інтеграційних сценаріїв було
застосовано повністю програмний, кодоцентричний підхід на основі пакета
@nestjs/testing та спеціалізованої бібліотеки supertest. Це дозволило
повністю відмовитися від сторонніх графічних клієнтів (таких як Postman),
реалізувавши концепцію «Тестування як код» (Testing as Code). Тести
виконуються в ізольованому тестовому оточенні, яке перед початком кожного
циклу автоматично скидає стан таблиць бази даних за допомогою вбудованих
механізмів Prisma ORM.
Таблиця 3.3
Тест-кейс TC-IT-001: Контроль доступу до захищених ендпоінтів API
Параметр тест-
Опис та вміст параметра
кейсу
ID тест-кейсу TC-IT-001
Модуль системи Шар безпеки та маршрутизації (Guards / Маршрути)
Перевірка блокування неавторизованих спроб надсилання
Назва / Мета
запитів до приватного API.
Початкові умови Запит відправляється без заголовка Authorization.
HTTP POST-пакет на адресу /courses/submit з довільним
Вхідні дані
тілом.
1. Сформувати HTTP-запит без JWT-токена.
Кроки
2. Надіслати запит на сервер за допомогою supertest.
виконання
3. Перевірити HTTP-код статусу.
60
ЧДТУ 262250.012 ПЗ
Продовження таблиці 3.3
Очікуваний Глобальний JwtAuthGuard перехоплює запит і повертає
результат HTTP 401 Unauthorized.
Фактичний Отримано HTTP-статус 401. Доступ закритий, бізнес-
результат сервіси не викликалися.
Статус Пройдено (PASSED)
Таблиця 3.4
Тест-кейс TC-IT-002: Валідація структури вхідних об'єктів (DTO)
Парамет тест-кейсу Опис та вміст параметра
ID тест-кейсу TC-IT-002
Модуль системи Компонент валідації (ValidationPipe / DTO)
Верифікація відсікання пакетів з відсутніми або
Назва / Мета
пошкодженими обов'язковими полями.
Користувач авторизований (JWT надано), але передає
Початкові умови
неповну структуру даних.
Вхідні дані JSON: { "lessonId": 1 } (поле code повністю пропущене).
1. Сформувати POST-запит із пошкодженим JSON-тілом.
Кроки виконання 2. Передати валідний токен у заголовку.
3. Зафіксувати відповідь валідатора екосистеми NestJS.
Очікуваний Сервер повертає кодову відповідь HTTP 400 Bad Request
результат з описом пропущеного поля.
61
ЧДТУ 262250.012 ПЗ
Продовження таблиці 3.4
Фактичний Повернуто статус 400. Масив помилок містить чітку
результат вказівку на те, що поле code обов'язкове.
Статус Пройдено (PASSED)
3.2.3. Системне тестування
Системне тестування (System Testing) передбачає дослідження поведінки
всього інтегрованого програмного комплексу в умовах, максимально
наближених до реальної експлуатації. Ключовим завданням цього етапу стало
проведення навантажувальних випробувань (Load & Stress Testing) для оцінки
пропускної здатності сервера, виявлення «вузьких місць» (Bottlenecks) та
визначення лімітів стабільності системи. Оскільки ізольований запуск
стороннього коду є ресурсомістким процесом (CPU-bound), критично важливо
було перевірити стійкість пулу Docker-контейнерів бекенду при пікових
навантаженнях, що виникають під час одночасного виконання лабораторних
робіт групою студентів.
Навантажувальне тестування було реалізовано за допомогою
продуктивного інструменту k6 від Grafana. Написаний скрипт імітував поведінку
віртуальних користувачів (VUs), які одночасно авторизувалися, завантажували
теорію та масово відправляли код на перевірку через API. Аналіз отриманих
метрик дозволив оцінити межі масштабованості системи та визначити
оптимальні ліміти контейнеризації для стабільної обробки запитів. Отримані
дані підтвердили, що розроблена архітектура зберігає високу відмовоустійкість
та нормативний час відгуку навіть за умов критичного зростання інтенсивності
навантаження.
Зведені аналітичні результати навантажувальних випробувань для різних
конфігурацій інтенсивності запитів зафіксовані в таблиці 3.5:
62
ЧДТУ 262250.012 ПЗ
Таблиця 3.5
Результати навантажувальних випробувань системи
Середній Коефіцієнт
Кількість Загальна Споживання
час Пікове успішних
віртуальних кількість RAM
відповіді завантаження відповідей
користувачів виконаних інстансом
(p90 CPU сервера (HTTP
(VUs) запитів Node.js
Latency) 200)
10 VUs 480 0.12 сек 12.4 % 84 МБ 100.0 %
25 VUs 1120 0.85 сек 34.1 % 112 МБ 100.0 %
50 VUs (Пік) 2240 3.82 сек 87.6 % 145 МБ 100.0 %
100 VUs 94.2 %
4110 7.14 сек 98.2 % 190 МБ
(Стрес) (Timeout)
Нижче наведено специфікації системних тест-кейсів, що описують
критерії стабільності під інфраструктурним тиском.
Таблиця 3.6
Тест-кейс TC-ST-001: Системне тестування номінального пікового
навантаження
Параметр тест-
Опис та вміст параметра
кейсу
ID тест-кейсу TC-ST-001
Модуль
Весь програмний комплекс (Інфраструктурний шар)
системи
Оцінка стабільності при паралельній роботі 50 користувачів
Назва / Мета
(еквівалент академічного потоку).
63
ЧДТУ 262250.012 ПЗ
Продовження таблиці 3.6
Запущено серверні докер-контейнери додатка та БД. k6
Початкові умови
скрипт сконфігурований на 50 VUs.
Потік конкурентних запитів обсягом 2240 ітерацій
Вхідні дані
тривалістю 60 секунд.
1. Запустити утиліту k6 із цільовим сценарієм.
2. Знімати метрики утилітою docker stats щодо
Кроки виконання
споживання CPU/RAM.
3. Зафіксувати частку помилок.
Очікуваний Коефіцієнт успішних відповідей складає 100%. Час
результат відповіді не перевищує 4 сек.
Фактичний Всі запити оброблені успішно (100.0%). Сервер витримав
результат навантаження без падінь.
Статус Пройдено (PASSED)
Таблиця 3.7
Тест-кейс TC-ST-002: Стрес-тестування системи на межі відмови
Параметр тест-кейсу Опис та вміст параметра
ID тест-кейсу TC-ST-002
Модуль системи Весь програмний комплекс (Інфраструктурний шар)
64
ЧДТУ 262250.012 ПЗ
Продовження таблиці 3.7
Визначення поведінки системи при екстремальному
Назва / Мета
навантаженні (100 VUs).
Навантаження подвоюється порівняно з номінальним піком
Початкові умови
системи.
Кроки 1. Ініціювати k6 стрес-тест.
виконання 2. Зафіксувати точку деградації та характер відмов системи.
Очікуваний При завантаженні CPU > 95% система не повинна падати, а
результат має відхиляти запити за таймаутом.
Фактичний Процесор завантажено на 98.2%. Частина запитів (5.8%)
результат відхилена за таймаутом безпеки (Timeout).
Статус Пройдено (PASSED)
3.2.4. Приймальне тестування
Приймальне тестування (Acceptance Testing) є завершальним етапом
процесу верифікації системи та виконується за методологією «чорної скриньки»
(Black-Box Testing) для оцінки відповідності розробленого програмного
комплексу бізнес-вимогам кінцевих користувачів, критеріям зручності
інтерфейсу (Usability) та параметрам технічного завдання.
Важливою складовою став аналіз кросбраузерної сумісності клієнтського
React-застосунку та адаптивності його інтерфейсу. Перевірка здійснювалася в
усіх поширених сучасних веб-рушіях: Chromium Engine (Google Chrome, Edge),
Gecko Engine (Mozilla Firefox) та WebKit Engine (Apple Safari). Додатково було
проведено ручне тестування за участю реальних користувачів (студентів та
65
ЧДТУ 262250.012 ПЗ
викладачів) для оцінки реальної зручності інтерфейсу та швидкості адаптації до
розділеного екрана. У ході перевірок окремо аналізувалася стійкість системи до
відмов у нестандартних ситуаціях.Повна специфікація приймальних перевірок
зафіксована у тест-кейсах нижче. Повна специфікація приймальних перевірок
зафіксована у тест-кейсах нижче.
Таблиця 3.8
Тест-кейс TC-AT-001: Перевірка адаптивності інтерфейсу Split-view
Layout
Параметр тест-
Опис та вміст параметра
кейсу
ID тест-кейсу TC-AT-001
Модуль
Клієнтська частина (Frontend UI / Tailwind CSS)
системи
Верифікація коректності рендерингу робочої області
Назва / Мета
студента на екранах ноутбуків (1024px).
Початкові Користувач відкриває сторінку практичного уроку. Браузер
умови переведено в режим емуляції екрана 1024px.
Сторінка з великим обсягом Markdown-тексту теорії та
Вхідні дані
інтегрованим Monaco Editor.
1. Зменшити ширину вікна перегляду до 1024 пікселів.
Кроки
2. Перевірити наявність накладання блоків чи появи
виконання
горизонтального скролу.
66
ЧДТУ 262250.012 ПЗ
Продовження таблиці 3.8
Інтерфейс адаптується: внутрішні відступи зменшуються,
Очікуваний
блок теорії отримує індивідуальний вертикальний скрол,
результат
горизонтальна прокрутка сторінки відсутня.
Фактичний Компоненти перебудувалися згідно з медіа-запитами Tailwind
результат CSS. Layout Shift відсутній.
Статус Пройдено (PASSED)
Таблиця 3.9
Тест-кейс TC-AT-002: Перевірка інтеграції Monaco Editor та Zustand
Параметр тест-
Опис та вміст параметра
кейсу
ID тест-кейсу TC-AT-002
Модуль системи Клієнтська частина (Компонент IDE та Zustand сховище)
Верифікація збереження чернетки введеного студентом
Назва / Мета
коду при випадковому перезавантаженні.
Студент авторизований, знаходиться на сторінці
Початкові умови
виконання.
Вхідні дані Введення тексту програми: print("Hello World").
1. Ввести код у вікно Monaco Editor.
Кроки
2. Виконати примусове оновлення сторінки браузера.
виконання
3. Проаналізувати вміст редактора після оновлення.
67
ЧДТУ 262250.012 ПЗ
Продовження таблиці 3.9
Очікуваний Zustand-сховище за допомогою Persist Middleware
результат відновлює стан коду з LocalStorage. Текст не втрачено.
Фактичний Після оновлення сторінки код успішно підтягнувся у вікно
результат редактора з локального сховища.
Статус Пройдено (PASSED)
За результатами проведення повного циклу верифікації за допомогою
розроблених тест-кейсів, інформаційна система «LearnTech» продемонструвала
високий рівень стійкості, стабільності та повну відповідність усім закладеним
бізнес-вимогам.
3.3. Приклади впровадження програмного комплексу
Фінальний етап реалізації інформаційної системи «LearnTech» охоплює
розгортання розробленої інфраструктури в продуктивному середовищі та
практичну валідацію користувацьких сценаріїв взаємодії з платформою. Процес
впровадження орієнтований на забезпечення максимальної портативності
програмного комплексу, автоматизацію розгортання та створення
безперебійного циклу роботи як для адміністраторів (викладачів), так і для
кінцевих користувачів (студентів).
Для усунення поширеної проблеми десинхронізації середовищ виконання
між локальними машинами розробників та цільовим сервером було застосовано
сучасні DevOps-практики, зокрема технологію контейнеризації на базі
платформи Docker. Весь програмний комплекс, що складається з клієнтського
додатка React, серверного API NestJS та реляційної бази даних PostgreSQL, було
інкапсульовано в ізольовані контейнери, які функціонують у межах єдиної
віртуальної мережі Docker.
68
ЧДТУ 262250.012 ПЗ
Центральним елементом автоматизації розгортання інфраструктури є
конфігураційний файл оркестрації docker-compose.yml. Цей файл декларативно
описує взаємозв'язки між сервісами, ліміти ресурсів, мережеві мости (Networks)
та постійні сховища даних (Volumes). Важливою архітектурною особливістю
збірки контейнера backend_api є те, що в його базовий Dockerfile, заснований на
легкому образі node:18-alpine, на етапі ініціалізації примусово встановлюється
інтерпретатор мови Python (python3). Це необхідно для забезпечення
працездатності модуля ізольованого виконання коду ExecutorService, який
викликає системні підпроцеси ОС всередині цього ж контейнера для валідації
студентських рішень. База даних postgres_db повністю ізольована від прямого
доступу із зовнішньої глобальної мережі інтернет, а взаємодія з нею дозволена
виключно для контейнера бекенду через внутрішній міст learntech_network, що
суттєво підвищує загальний рівень безпеки системи. Для систематизації
параметрів конфігурації інфраструктури, всі конфіденційні змінні оточення та
системні порти винесені в захищений файл .env.
Після успішного запуску контейнерів автоматично ініціюється внутрішній
тригер життєвого циклу NestJS додатка, який виконує команду npx prisma migrate
deploy для розгортання еволюційних міграцій структури таблиць у базі даних.
Одразу після цього запускається підготовлений TypeScript-скрипт наповнення
бази даних початковими даними seed.ts. Цей процес автоматично створює
профілі адміністраторів, базову структуру ієрархічних курсів та практичні
завдання з Markdown-описами й еталонними тестами перевірки, що робить
систему повністю готовою до експлуатації без необхідності налаштування.
Першим кроком сценарію є проходження процесу автентифікації.
Користувач вводить облікові дані у форму на клієнтській стороні React. Запит
обробляється сервером за допомогою бібліотеки bcrypt, яка порівнює хеш пароля
з даними в PostgreSQL. Після успішного підтвердження особи сервер генерує
токен JWT, який передається клієнту і перехоплюється глобальним сховищем
Zustand. Завдяки використанню Persist Middleware у Zustand, цей токен
автоматично дублюється в LocalStorage браузера, гарантуючи збереження
69
ЧДТУ 262250.012 ПЗ
активної сесії при випадкових оновленнях сторінки. Наступні мережеві HTTP-
запити через Axios автоматично модифікуються перехоплювачами (Interceptors),
які підставляють токен у заголовок Authorization, відкриваючи доступ до
захищеного контенту.
Рисунок 3.8 – Реєстрація
Другим кроком є робота з каталогом навчальних матеріалів. Після авторизації
студент потрапляє на сторінку курсу, де інтерфейс побудований за принципом
Split-view Layout за допомогою Tailwind CSS. У лівій частині екрана
відображається ієрархічна структура модулів та уроків, яка підтягується з бази
даних одним оптимізованим JOIN-запитом через Prisma ORM завдяки механізму
жадібного завантаження (Eager Loading). У правій частині відображається
інтерактивна зона: текстовий блок із теоретичним матеріалом, відрендерений з
Markdown, та вбудоване вікно редактора Microsoft Monaco Editor. Редактор
забезпечує студенту звичний функціонал професійного середовища VS Code —
від підсвічування синтаксису до інтелектуального автодоповнення коду, а класи
70
ЧДТУ 262250.012 ПЗ
Tailwind CSS гарантують плавну адаптацію обох робочих зон під будь-яку
роздільну здатність екрана.
Рисунок 3.9 – Каталог курсів
У випадку, якщо студент припустився синтаксичної або логічної помилки,
дочірній процес Python завершується з кодом Exit Code = 1, перехоплюючи потік
stderr. Система моментально обробляє цей негативний сценарій і через систему
централізованого логування та клієнтських нотифікацій react-hot-toast виводить
точний текст помилки інтерпретатора прямо в інтерактивний консольний блок
під редактором коду. Якщо ж у коді утворився нескінченний цикл, у гру вступає
внутрішній Timeout Watchdog, який через 3000 мілісекунд надсилає системний
сигнал SIGKILL, примусово знищуючи процес і видаляючи тимчасові файли
через підсистему збирання сміття fs.promises.unlink, повертаючи студенту статус
TIMEOUT.
При успішному проходженні всіх внутрішніх тест-кейсів (Assertion
Passed), сервер фіксує статус SUCCESS, Prisma ORM вносить запит на оновлення
прогресу студента, додаючи дату завершення completedAt та нараховані бали
score у відповідну таблицю. На клієнтській стороні елемент поточного уроку в
навігаційній панелі миттєво змінює свій візуальний статус на утилітарний
зелений маркер успішності, відкриваючи доступ до наступного кроку курсу.
71
ЧДТУ 262250.012 ПЗ
ВИСНОВКИ
У кваліфікаційній роботі успішно вирішено актуальне науково-практичне
завдання з проектування, розробки та впровадження інтерактивної багатомовної
інформаційної системи «LearnTech», призначеної для автоматизованого
навчання та верифікації навичок програмування мовами Python, C++ та
JavaScript. У ході виконання дослідження було проведено детальний аналіз
сучасних тенденцій у сфері електронної освіти, який виявив гостру потребу у
створенні гнучких, безпечних та високопродуктивних інструментів для
перевірки коду в реальному часі без безпосереднього залучення людського
ресурсу викладача. На основі проведеного аналізу аналогів обґрунтовано вибір
сучасного технологічного стеку, що включає серверний фреймворк NestJS,
клієнтську бібліотеку React з інтегрованим редактором Monaco Editor, об'єктно-
реляційне відображення Prisma ORM та реляційну базу даних PostgreSQL.
Проектування архітектури системи здійснювалося із застосуванням підходу
монорепозиторію, що дозволило забезпечити надійну наскрізну типізацію між
клієнтською та серверною частинами додатка, а також суттєво спростити
процеси синхронізації версій API та управління вихідним кодом.
Особливу увагу в роботі приділено розробці та безпеці центрального ядра
системи — ізольованого середовища виконання стороннього неперевіреного
коду студентів для трьох різних мовних середовищ. Реалізований сервіс
виконання рішень динамічно адаптується під тип завдання: виконує
інтерпретацію скриптів через підпроцеси Python, здійснює попередню
компиляцію вихідного коду C++ за допомогою утиліти g++ з наступним
запуском бінарних файлів, а також виконує код JavaScript на базі ізольованого
Node.js оточення. Для нейтралізації потенційних інфраструктурних загроз та
запобігання DoS-атакам було спроектовано та впроваджено багаторівневу
систему обмеження ресурсів, яка включає жорстку лімітацію адресного простору
віртуальної пам'яті для кожного підпроцесу, а також механізм примусового
знищення зациклених скриптів за внутрішнім тайм-аутом безпеки, що повністю
72
ЧДТУ 262250.012 ПЗ
гарантує стабільність хост-машини сервера за будь-яких умов користувацького
введення та типів програм. Зберігання та маніпулювання даними прогресу
користувачів, структури багатомовних курсів та нарахованого досвіду
реалізовано за допомогою оптимізованих Prisma-транзакцій, що забезпечує
високу цілісність, консистентність та захищеність інформаційного простору
платформи.
Етап комплексного тестування підтвердив високу якість написання
програмного коду, стабільність міжкомпонентних контрактів та загальну
відмовостійкість системи. Проведені модульні та інтеграційні випробування із
застосуванням інструментів Jest та Supertest продемонстрували повне покриття
ключових гілок бізнес-логики, безпомилкову фільтрацію некоректних вхідних
даних на рівні глобальних валідаторів DTO та стабільність обробки помилок
компіляції і синтаксису для кожної з трьох підтримуваних мов. Результати
системного навантажувального тестування за допомогою високопродуктивної
утиліти k6 підтвердили здатність платформи стабільно обробляти великі потоки
конкурентних запитів від значної кількості паралельних користувачів, своєчасно
квантувати ресурси процесора під час ресурсомісткої компіляції C++ та
ізолювати критичні збої обчислень без падіння веб-сервера додатка. Приймальні
випробування інтерфейсу засвідчили бездоганну кросбраузерну сумісність
клієнтської частини, гнучку адаптивність Split-view макету під різні роздільні
здатності екранів ПК та ноутбуків, а також стовідсоткову локалізацію всіх
текстових, навчальних та інфраструктурних елементів системи українською
мовою.
Практична цінність та готовність інформаційної системи «LearnTech» до
промислової експлуатації підтверджується її успішною контейнеризацією за
допомогою Docker Compose, де в образ бекенду на етапі збірки інтегруються всі
необхідні компілятори та інтерпретатори. Створена інфраструктура забезпечує
миттєве розгортання всього комплексу разом із автоматичним накатуванням
еволюційних міграцій бази даних та первинним наповненням структури курсів
контентом за допомогою спеціалізованих скриптів. Спроектовані безшовні
73
ЧДТУ 262250.012 ПЗ
користувацькі сценарії взаємодії дозволяють студентам обирати мову
програмування та отримувати миттєвий об'єктивний зворотний зв'язок і лог
помилок у процесі написання програм, що значно підвищує ефективність
засвоєння матеріалу. Розроблений програмний комплекс є завершеним, цілісним
та захищеним інженерним продуктом, який повністю задовольняє вимогам
технічного завдання і готовий до практичного інтегрування в освітній процес
вищих навчальних закладів для підвищення якості підготовки ІТ-фахівців.
74
ЧДТУ 262250.012 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Мартін Р. Чиста архітектура. Мистецтво розроблення програмного забезпечення
/ Роберт Мартін. – Київ : Фабула, 2019. – 368 с.
2 Клеппман М. Високонавантажені додатки. Програмування, масштабування,
підтримка / Мартін Клеппман. – Санкт-Петербург : Пітер, 2018. – 640 с.
3 Гама Е. Патерни об'єктно-орієнтованого проектування / Еріх Гама, Річард Хелм,
Ральф Джонсон, Джон Вліссідес. – Санкт-Петербург : Пітер, 2020. – 368 с.
4 Фрімен Е. Патерни проектування / Ерік Фрімен, Елізабет Робсон. – Київ : Фабула,
2021. – 656 с.
5 Майєрс Г. Мистецтво тестування програмного забезпечення / Гленфорд Майєрс,
Корі Сандлер, Том Баджетт. – Нью-Йорк : John Wiley & Sons, 2012. – 256 с.
6 ISO/IEC 19505-1:2012. Information technology — Object Management Group
Unified Modeling Language (OMG UML) — Part 1: Infrastructure [Electronic
resource]. – URL: https://www.iso.org/standard/32620.html.
7 Node.js Documentation [Електронний ресурс] / OpenJS Foundation. – Режим
доступу: https://nodejs.org/en/docs/ (дата звернення: 10.05.2026).
8 TypeScript: Typed JavaScript at Any Scale [Електронний ресурс] / Microsoft. –
Режим доступу: https://www.typescriptlang.org/docs/ (дата звернення: 11.05.2026).
9 NestJS - A progressive Node.js framework [Електронний ресурс]. – Режим доступу:
https://docs.nestjs.com/ (дата звернення: 12.05.2026).
10 React – A JavaScript library for building user interfaces [Електронний ресурс] / Meta.
– Режим доступу: https://react.dev/ (дата звернення: 12.05.2026).
11 Vite: Next Generation Frontend Tooling [Електронний ресурс]. – Режим доступу:
https://vitejs.dev/ guide/ (дата звернення: 12.05.2026).
12 PostgreSQL: The World's Most Advanced Open Source Relational Database
[Електронний ресурс]. – Режим доступу: https://www.postgresql.org/docs/ (дата
звернення: 13.05.2026).
13 Prisma: Next-generation ORM for Node.js & TypeScript [Електронний ресурс]. –
Режим доступу: https://www.prisma.io/docs/ (дата звернення: 13.05.2026).
75
ЧДТУ 262250.012 ПЗ
14 Docker Documentation [Електронний ресурс] / Docker Inc. – Режим доступу:
https://docs.docker.com/ (дата звернення: 14.05.2026).
15 Jones M. JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants / M. Jones, J. Bradley, N. Sakimura // Internet Engineering Task
Force (IETF) RFC 7523. – 2015. – Режим доступу:
https://datatracker.ietf.org/doc/html/rfc7519.
16 Zustand: Bear necessities for state management in React [Електронний ресурс]. –
Режим доступу: https://docs.pmnd.rs/zustand/ (дата звернення: 14.05.2026).
17 Monaco Editor: The code editor that powers VS Code [Електронний ресурс] /
Microsoft. – Режим доступу: https://microsoft.github.io/monaco-editor/ (дата
звернення: 15.05.2026).
18 Tailwind CSS - Rapidly build modern websites without ever leaving your HTML
[Електронний ресурс]. – Режим доступу: https://tailwindcss.com/docs (дата
звернення: 15.05.2026).
19 GitHub - Webhooks and Markdown API [Електронний ресурс] / GitHub, Inc. —
Режим доступу: https://docs.github.com/en/builders/apps (дата звернення:
15.05.2026).
20 Jest: Delightful JavaScript Testing [Електронний ресурс]. – Режим доступу:
https://jestjs.io/docs/getting-started (дата звернення: 16.05.2026).
21 k6: Open source load testing tool and SaaS for engineering teams [Електронний
ресурс] / Grafana Labs. – Режим доступу: https://k6.io/docs/ (дата звернення:
16.05.2026).
22 SuperTest: Super-agent driven library for testing node.js HTTP servers [Електронний
ресурс]. – Режим доступу: https://github.com/ladjs/supertest (дата звернення:
16.05.2026).
23 Python 3 Documentation [Електронний ресурс] / Python Software Foundation. –
Режим доступу: https://docs.python.org/3/ (дата звернення: 17.05.2026).
24 GCC, the GNU Compiler Collection [Електронний ресурс] / Free Software
Foundation. – Режим доступу: https://gcc.gnu.org/onlinedocs/ (дата звернення:
17.05.2026).
76
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедри ПЗАС, професор
Голуб С.В.
“ ” 2026 р.
«Web-застосунок для інтерактивного вивчення мов програмування»
Специфікація
482.ЧДТУ 262250.012
Листів 2
Розробник Мамчич Д. А.
Керівник Заспа Г. О.
2026
482.ЧДТУ 262250.012 2
Позначення Найменування Примітка
Документація
482.ЧДТУ 262250 12 01 Текст програми
482.ЧДТУ 262250 34 01 Інструкція користувачеві
482.ЧДТУ 262250 90 01 Графічні матеріали
78
ДОДАТОК Б
«Web-застосунок для інтерактивного вивчення мов програмування»
Текст програми
482.ЧДТУ 262250 12 01
Листів 8
Розробник Мамчич Д. А.
2026
482.ЧДТУ 262250 12 01 2
#Schema.prisma
generator client {
provider = "prisma-client-js"
}
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
model Course {
id Int @id @default(autoincrement())
slug String @unique
// UA (Default)
title String
description String
detailedDescription String?
whatYouWillLearn String?
outcomes String?
// EN (New)
titleEn String?
descriptionEn String?
detailedDescriptionEn String?
whatYouWillLearnEn String?
outcomesEn String?
level String @default("Beginner")
duration String @default("2 години")
lessons Lesson[]
}
model User {
id Int @id @default(autoincrement())
email String @unique
password String
name String?
avatar String?
createdAt DateTime @default(now())
progress UserProgress[]
}
model Lesson {
id Int @id @default(autoincrement())
// UA
title String
content String
// EN
titleEn String?
contentEn String?
80
482.ЧДТУ 262250 12 01 3
startCode String
testCode String?
expectedOutput String?
courseId Int
course Course @relation(fields: [courseId], references: [id])
progress UserProgress[]
}
model UserProgress {
id Int @id @default(autoincrement())
userId Int
lessonId Int
isCompleted Boolean @default(false)
completedAt DateTime @default(now())
user User @relation(fields: [userId], references: [id])
lesson Lesson @relation(fields: [lessonId], references: [id])
@@unique([userId, lessonId]) // Юзер не може мати два записи для одного уроку
}
#Auth.service.ts
import { Injectable, UnauthorizedException } from '@nestjs/common';
import { PrismaService } from '../prisma/prisma.service';
import { JwtService } from '@nestjs/jwt';
import * as bcrypt from 'bcrypt';
@Injectable()
export class AuthService {
constructor(
private prisma: PrismaService,
private jwtService: JwtService
) {}
// 1. Логіка входу (Login)
async login(email: string, pass: string) {
// Шукаємо юзера
const user = await this.prisma.user.findUnique({ where: { email } });
if (!user) {
throw new UnauthorizedException('Користувача не знайдено');
}
// Перевіряємо пароль
const isMatch = await bcrypt.compare(pass, user.password);
if (!isMatch) {
throw new UnauthorizedException('Невірний пароль');
}
// Генеруємо токен
const payload = { sub: user.id, email: user.email };
return {
access_token: await this.jwtService.signAsync(payload),
user: {
id: user.id,
81
482.ЧДТУ 262250 12 01 4
email: user.email,
name: user.name,
avatar: user.avatar
}
};
}
// 2. Логіка реєстрації (Register)
async register(email: string, pass: string, name: string) {
const existing = await this.prisma.user.findUnique({ where: { email } });
if (existing) throw new UnauthorizedException('Email вже зайнятий');
const hashedPassword = await bcrypt.hash(pass, 10);
await this.prisma.user.create({
data: {
email,
password: hashedPassword,
name
}
});
return this.login(email, pass);
}
}
#Courses.controller.ts
import { Controller, Get, Post, Body, Param, UseGuards, Request } from '@nestjs/common';
import { CoursesService } from './courses.service';
import { AuthGuard } from '@nestjs/passport';
@Controller('courses')
export class CoursesController {
constructor(
private readonly coursesService: CoursesService
) {}
@Get()
findAll() {
return this.coursesService.findAll();
}
@Get('leaderboard')
async getLeaderboard() {
return this.coursesService.getLeaderboards();
}
@UseGuards(AuthGuard('jwt'))
@Get('my')
async getUserCourses(@Request() req) {
return this.coursesService.findUserCourses(req.user.id);
}
@Get(':slug')
findOne(@Param('slug') slug: string) {
return this.coursesService.findOne(slug);
82
482.ЧДТУ 262250 12 01 5
}
// Перевірка завдання
@Post(':lessonId/check')
async checkLesson(
@Param('lessonId') lessonId: string,
@Body() body: { userCode: string; language?: string } // Приймаємо і код, і мову
) {
return this.coursesService.checkLesson(
+lessonId,
body.userCode,
body.language
);
}
}
#Lessonpage.ts
import { useParams, Link } from 'react-router-dom';
import { useEffect, useState } from 'react';
import api from '../api/axios';
import Editor from "@monaco-editor/react";
import ReactMarkdown from 'react-markdown';
import { Play, CheckCircle, Terminal, Loader2, AlertCircle, ArrowRight, LogIn } from 'lucide-
react';
import Sidebar from '../components/Sidebar';
import { useAuthStore } from '../store/useAuthStore';
import { useTranslation } from '../hooks/useTranslation';
import { getLocalized } from '../utils/localize';
interface Lesson {
id: number;
title: string;
titleEn?: string;
content: string;
contentEn?: string;
startCode: string;
}
interface Course {
title: string;
titleEn?: string;
lessons: Lesson[];
}
export default function LessonPage() {
const { slug } = useParams();
const { user, theme, language } = useAuthStore();
const { t } = useTranslation();
// СТАНИ
const [course, setCourse] = useState<Course | null>(null);
const [completedIds, setCompletedIds] = useState<number[]>([]);
83
482.ЧДТУ 262250 12 01 6
const [activeLessonIndex, setActiveLessonIndex] = useState(0);
const [code, setCode] = useState("// Loading...");
const [output, setOutput] = useState<string | null>(null);
// СТАНИ ЗАВАНТАЖЕННЯ
const [isLoading, setIsLoading] = useState(false);
const [isError, setIsError] = useState(false);
const [isSuccess, setIsSuccess] = useState(false);
// 1. визначаємо мову за посиланням
const getLanguage = () => {
if (slug?.includes('python')) return 'python';
if (slug?.includes('cpp')) return 'cpp';
return 'javascript';
};
const currentLanguage = getLanguage();
// ЗАВАНТАЖЕННЯ ДАНИХ
useEffect(() => {
const fetchData = async () => {
try {
const courseRes = await api.get(`/courses/${slug}`);
setCourse(courseRes.data);
// Встановлюємо код першого уроку
if (courseRes.data.lessons?.length > 0) {
setCode(courseRes.data.lessons[0].startCode);
}
// Завантажуємо прогрес, якщо юзер залогінений
if (user) {
const progressRes = await api.get(`/progress/${user.id}`);
const ids = progressRes.data.map((p: any) => p.lessonId);
setCompletedIds(ids);
}
} catch (err) {
console.error("Error loading data", err);
}
};
fetchData();
}, [slug, user]);
// ПЕРЕМИКАННЯ УРОКУ
const handleSelectLesson = (index: number) => {
if (!course) return;
setActiveLessonIndex(index);
setCode(course.lessons[index].startCode);
setOutput(null);
setIsSuccess(false);
setIsError(false);
};
// ЗАПУСК КОДУ (RUN)
84
482.ЧДТУ 262250 12 01 7
const handleRunCode = async () => {
setIsLoading(true);
setOutput(null);
setIsError(false);
setIsSuccess(false)
try {
const response = await api.post('/execute', {
code,
language: currentLanguage
});
const result = response.data;
if (result.stderr) {
setOutput(result.stderr);
setIsError(true);
} else {
setOutput(result.stdout);
}
} catch (error) {
setOutput("Connection error");
setIsError(true);
} finally {
setIsLoading(false);
}
};
// ПЕРЕВІРКА ЗАВДАННЯ (SUBMIT)
const handleCheckCode = async () => {
if (!course) return;
if (!user) {
setOutput(t('alertLogin'));
setIsError(true);
return;
}
setIsLoading(true);
setOutput(null);
setIsError(false);
setIsSuccess(false)
try {
const currentLesson = course.lessons[activeLessonIndex];
const response = await api.post(`/courses/${currentLesson.id}/check`, {
userCode: code,
language: currentLanguage
});
const result = response.data
if (result.success) {
setOutput(result.message);
setIsSuccess(true);
85
482.ЧДТУ 262250 12 01 8
// Зберігаємо прогрес
await api.post('/progress/complete', {
lessonId: currentLesson.id
});
if (!completedIds.includes(currentLesson.id)) {
setCompletedIds([...completedIds, currentLesson.id]);
}
} else {
setOutput(result.message);
setIsError(true);
}
} catch (error) {
setOutput("Error checking code");
setIsError(true);
} finally {
setIsLoading(false);
}
};
if (!course) return (
<div className="flex h-screen items-center justify-center transition-colors duration-300 bg-
white dark:bg-[#0d1117] text-gray-900 dark:text-white">
<Loader2 className="animate-spin mr-2" /> {t('loading')}
</div>
);
const currentLesson = course.lessons[activeLessonIndex];
// ОТРИМУЄМО ЛОКАЛІЗОВАНІ ТЕКСТИ
const localizedCourseTitle = getLocalized(course, language, 'title');
const localizedLessonTitle = getLocalized(currentLesson, language, 'title');
const localizedLessonContent = getLocalized(currentLesson, language, 'content');
86
ДОДАТОК В
«Web-застосунок для інтерактивного вивчення мов програмування»
Інструкція користувачеві
482.ЧДТУ 262250 34 01
Листів 8
Розробник Мамчич Д. А.
2026
482.ЧДТУ 262250 34 01 2
При заході на сайт користувач може вибрати, чи хоче він зареєструватися та
почати проходження будь-якого курсу, чи знаходитися у ролі «Гість» та мати
можливість лише почитати про курси та оглянути сайт. При першому відвідуванні
головної сторінки додатка система відображає стартовий екран із можливістю
переходу до форми реєстрації(рис В.1). У цій формі користувач має коректно
заповнити кілька обов'язкових полів, серед яких власне ім'я та прізвище для
подальшої ідентифікації в загальносистемному рейтингу, діюча адреса електронної
пошти, яка буде слугувати унікальним логіном, та пароль, що за вимогами безпеки
повинен складатися щонайменше з восьми символів і містити комбінацію літер та
цифр(рис В.2).
Рисунок В.1 – Головна сторінка додатку
88
482.ЧДТУ 262250 34 01 3
Рисунок В.2 – Інформативна форма реєстрації
Одразу після успішного збереження даних у базі, інтерфейс автоматично
перенаправляє користувача на сторінку автентифікації(рис В.3). Тут необхідно ввести
щойно зареєстровану електронну пошту та пароль, після чого система згенерує
унікальний токен доступу, який інтегрується в локальну пам'ять браузера і дозволяє
вебдодатку підтримувати активну сесію користувача навіть при випадковому
оновленні сторінок чи короткочасному зникненні мережевого з'єднання.
Рисунок В.3 – Форма автентифікації
89
482.ЧДТУ 262250 34 01 4
Після успішного проходження авторизації користувач потрапляє на головну
сторінку. На цьому екрані візуалізуються всі доступні на даний момент освітні курси,
розділені за технологічними стеками(рис В.4) . Кожен курс представлений у вигляді
інтерактивної графічної картки, яка містить унікальний логотип мови програмування,
офіційну назву програми, короткий опис цільової аудиторії. Клік на картку обраного
курсу відкриває користувачеві детальну деревоподібну структуру модулів і
дозволяючи перейти до першого доступного теоретичного або практичного
уроку(рис В.5) .
Рисунок В.4 – Каталог доступних курсів
90
482.ЧДТУ 262250 34 01 5
Рисунок В.5 – Детальна інформація про курс та модулі
Основним робочим простором студента є інтерактивна сторінка уроку, яка
спроектована за принципом розділеного екрана, за допомогою сучасних стилів(рис
В.6). Ліва частина екрана повністю відведена під відображення структурованого
теоретичного матеріалу. Текст теорії динамічно рендериться з формату, що дозволяє
викладачеві інтегрувати в тіло уроку наочні таблиці, підсвічені блоки з прикладами
«чистого» коду, графічні схеми та важливі текстові акценти. Права частина екрана
являє собою повноцінне інтегроване середовище розробки (IDE), центральним
елементом якого є вбудований професійний редактор коду. Цей редактор повністю
повторює функціонал сучасних десктопних систем розробки, забезпечуючи
користувача автоматичним підсвічуванням синтаксису обраної мови,
інтелектуальним автодоповненням коду при введенні стандартних функцій та
конструкцій, а також підсвічуванням парних дужок і вирівнюванням відступів.
Безпосередньо під вікном редактора розташована інтерактивна область чорного
кольору, яка виконує роль системної консолі (терміналу) для виведення результатів
компіляції та інтерпретації.
91
482.ЧДТУ 262250 34 01 6
Рисунок В.6 – Робоча зона для вивчення матеріалу та виконання завдань
Процес безпосереднього виконання практичного завдання та взаємодії з ядром
автоматизованої перевірки є чітко детермінованим та лінійним. Ознайомившись із
теоретичним матеріалом та технічними вимогами задачі, студент пише розв'язок у
вікні редактора, використовуючи наданий початковий шаблон функції. На панелі
управління під редактором доступні дві основні дії: запуск коду та перевірка рішення.
При натисканні кнопки запуску код відправляється на сервер для швидкого холостого
виконання, і користувач просто бачить у консолі стандартний вивід своєї програми.
Якщо ж користувач натискає головну кнопку перевірки, система ініціює складний
алгоритм тестування: сервер створює тимчасовий ізольований файл, компонує код
студента із прихованими еталонними тест-кейсами автора курсу (Assertions) та
запускає цей скрипт у дочірньому підпроцесі операційної системи(рис В.7).
Рисунок В.7 – Автоматична перевірка коду користувача
92
482.ЧДТУ 262250 34 01 7
Для детального аналізу власної успішності та контролю динаміки навчання
користувачеві доступний персональний кабінет, який відкривається через натискання
на вкладку профілю в головному меню системи(рис В.8) . Та відповідно у цьому вікні
користувач має можливість редагувати власні налаштування персоналізації,
змінювати відображуване ім'я, зміну коліру фону, мови або оновити аватар профілю.
Рисунок В.8 – Вікно профілю користувача
Важливим елементом гейміфікації та підвищення мотивації студентів на
платформі «LearnTech» є глобальна таблиця лідерів (Leaderboard), доступ до якої
здійснюється через однойменний пункт навігаційного меню(рис В.9). Цей інтерфейс
являє собою велику інтерактивну таблицю, де в режимі реального часу відсортовано
профілі всіх зареєстрованих у системі студентів за спаданням кількості набраних
ними балів досвіду. Таблиця лідерів чітко підсвічує перші три призові місця
спеціальними графічними маркерами, а також автоматично фокусує екран на
поточному користувачеві, показуючи його точну позицію в загальному рейтингу
93
482.ЧДТУ 262250 34 01 8
серед інших учнів. Це дозволяє студентам порівнювати власні досягнення з успіхами
одногрупників, стимулюючи здорове змагання та регулярне проходження нових
практичних блоків.
Рисунок В.9 – Таблиця лідерів серед студентів курсу
Після завершення роботи з платформою, для запобігання несанкціонованому
доступу до облікового запису з чужих пристроїв, користувачеві рекомендується
скористатися кнопкою виходу зверху бічної панелі, що повністю анулює токен
авторизації та закриє поточну робочу сесію.
94
ДОДАТОК Г
«Web-застосунок для інтерактивного вивчення мов програмування»
Графічні матеріали
482.ЧДТУ 262250 90 01
Листів 12
Розробник Мамчич Д. А.
2026
482.ЧДТУ 262250 90 01 2
Рисунок Г.1 – Тема роботи
Рисунок Г.2 – Актуальність досладження
96
482.ЧДТУ 262250 90 01 3
Рисунок Г.3 – Мета роботи
Рисунок Г.4 – Функціональні вімоги
97
482.ЧДТУ 262250 90 01 4
Рисунок Г.5 – Нефункціональні вимоги
Рисунок Г.6 – Порівняння аналогів
98
482.ЧДТУ 262250 90 01 5
Рисунок Г.7 – Моделювання та проектування
Рисунок Г.8 – Технологічний стек: клієнтська частина
99
482.ЧДТУ 262250 90 01 6
Рисунок Г.9 – Технологічний стек: серверна частина
Рисунок Г.10 – Діаграма прецедентів
100
482.ЧДТУ 262250 90 01 7
Рисунок Г.11 – Діаграма класів
Рисунок Г.12 – Діграма пакетів данних
101
482.ЧДТУ 262250 90 01 8
Рисунок Г.13 – Діграма компонентів
Рисунок Г.14 – Діграма розгортання
102
482.ЧДТУ 262250 90 01 9
Рисунок Г.15 – Діаграма діяльності
Рисунок Г.16 – Діаграма послідовності
103
482.ЧДТУ 262250 90 01 10
Рисунок Г.17 – Діаграма комунікації
Рисунок Г.18 – Діаграма скінченного автомату
104
482.ЧДТУ 262250 90 01 11
Рисунок Г.19 – Структурна схема застосунку
Рисунок Г.20 – Тестування
105
482.ЧДТУ 262250 90 01 12
Рисунок Г.21 – Висновки
Рисунок Г.22 – Дякую за увагу!
106