Репозиторій ЧДТУ
Репозиторій ЧДТУ зберігає і дозволяє легкий і відкритий доступ до всіх видів цифрового контенту, включаючи текст, зображення, анімовані зображення, MPEG і набори даних
Дізнатися більше
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/9754Повний запис метаданих
| Поле DC | Значення | Мова |
|---|---|---|
| dc.contributor.advisor | Салапатов , Володимир Іванович | - |
| dc.contributor.author | Сергієнко, Назар Сергійович | - |
| dc.date.accessioned | 2026-06-29T05:26:16Z | - |
| dc.date.available | 2026-06-29T05:26:16Z | - |
| dc.date.issued | 2026-06-17 | - |
| dc.identifier.uri | https://er.chdtu.edu.ua/handle/ChSTU/9754 | - |
| dc.description.abstract | АНОТАЦІЯ Виконавець: Сергієнко Назар Сергійович. Назва кваліфікаційної бакалаврської роботи: «Web-система формування робочих програм кафедри ПЗАС ЧДТУ» Спеціальність: 121 «Інженерія програмного забезпечення». Установа: Черкаський державний технологічний університет (ЧДТУ). Місто, рік: Черкаси, 2026 рік. Метою виконання кваліфікаційної роботи бакалавра є проектування та розробка веб-орієнтованого програмного комплексу для структурованого введення, перевірки, збереження та експорту даних робочих програм кафедри ПЗАС ЧДТУ. Об’єктом роботи є процес інженерного проектування, реалізації та тестування web-системи з клієнт-серверною архітектурою. Предметом розробки є програмні моделі, архітектурні рішення, структура бази даних, API, клієнтські та серверні компоненти, засоби валідації і модуль генерації PDF для автоматизації роботи зі структурованими даними робочої програми. У роботі виконано аналіз вимог до програмного забезпечення, побудовано UML-моделі, спроектовано архітектуру системи, реалізовано клієнтську і серверну частини, базу даних, модуль перевірки введених даних та модуль генерації PDF. Результатом роботи є програмний комплекс, що демонструє повний цикл розробки прикладної web-системи: від аналізу вимог і проектування архітектури до реалізації, розгортання та тестування основних сценаріїв. | uk_UA |
| dc.description.abstract | ABSTRACT Executor: Serhiienko Nazar Serhiiovych. Title of the bachelor’s qualification work: “Web System for Forming Working Programs of the Department of PZAS of ChSTU” Specialty: 121 “Software Engineering”. Institution: Cherkasy State Technological University (ChSTU). City, year: Cherkasy, 2026. The purpose of the bachelor’s qualification work is to design and develop a web-oriented software complex for structured entry, validation, storage, and export of working program data for the Department of PZAS of ChSTU. The object of the work is the software engineering process of designing, implementing, and testing a client-server web system. The subject of the development is software models, architectural decisions, database structure, API, client-side and server-side components, validation tools, and a PDF generation module for automated processing of structured working program data. The work includes software requirements analysis, UML modeling, system architecture design, implementation of the client and server parts, database, validation module, and PDF generation module. The result of the work is a software complex that demonstrates a complete development cycle of an applied web system: from requirements analysis and architectural design to implementation, deployment, and testing of the main scenarios. | uk_UA |
| dc.language.iso | uk | uk_UA |
| dc.subject | Робоча програма | uk_UA |
| dc.subject | WEB-система | uk_UA |
| dc.subject | Кафедра ПЗАС | uk_UA |
| dc.subject | ЧДТУ | uk_UA |
| dc.subject | REACT | uk_UA |
| dc.subject | NODE.JS | uk_UA |
| dc.subject | EXPRESS | uk_UA |
| dc.subject | POSTGRESQL | uk_UA |
| dc.subject | uk_UA | |
| dc.subject | UML | uk_UA |
| dc.subject | Working program | uk_UA |
| dc.subject | WEB-system | uk_UA |
| dc.subject | Department of PZAS | uk_UA |
| dc.subject | ChDTU | uk_UA |
| dc.subject | REACT | uk_UA |
| dc.subject | NODE.JS | uk_UA |
| dc.subject | EXPRESS | uk_UA |
| dc.subject | POSTGRESQL | uk_UA |
| dc.subject | uk_UA | |
| dc.subject | UML | uk_UA |
| dc.title | Web-система формування робочих програм кафедри ПЗАС ЧДТУ | uk_UA |
| dc.type | Bachelor Thesis | uk_UA |
| Розташовується у зібраннях: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) | |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Сергієнко Назар Сергійович.pdf Restricted Access | 4.7 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи бакалавра
на тему: «Web-система формування робочих
програм кафедри ПЗАС ЧДТУ»
Виконав: студент 4 курсу, групи ПЗ-2204
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Сергієнко Н.С.
(прізвище та ініціали)
Керівник Салапатов В.І.
(прізвище та ініціали)
Рецензент Феленко А.О.
(прізвище та ініціали)
Черкаси 2026
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
____________________ С. Голуб
«___» _______________ 2026 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Сергієнко Назар Сергійович
(прізвище, ім’я, по батькові)
1. Тема роботи «Web-система формування робочих програм кафедри ПЗАС ЧДТУ»
Керівник проекту (роботи) Салапатов Володимир Іванович, к.т.н., доцент
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від «12»
березня 2026 року №56/03-03
2. Строк подання студентом проекту (роботи) « 5 » червня 2026 року
3. Вхідні дані до проекту (роботи) методичні рекомендації до підготовки кваліфікаційної
роботи бакалавра; вимоги до структури робочої програми навчальної дисципліни; дані
кафедри ПЗАС ЧДТУ; шаблон робочої програми; засоби React, Node.js, Express,
PostgreSQL, Joi, Handlebars та Puppeteer.
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ; Існуючі методи та засоби розв’язання поставлених завдань. Впровадження
результату дослідження у практику проектування програмного забезпечення
інформаційних систем. Розробка та тестування програмного забезпечення. Висновки;
Список використаних джерел; Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту):
модель предметної області; робоча область моделювання; діаграма варіантів
використання; діаграма класів; діаграма пакетів; діаграма компонентів; діаграма
розгортання; діаграма діяльності; діаграма послідовності; діаграма комунікації; діаграма
скінченного автомату; структурна схема; логічна схема; фізична модель бази даних;
скріншоти інтерфейсу та формування PDF.
6. Консультанти розділів роботи.
Дата видачі завдання грудень 2025 року
Прізвище, ініціали та посади
Розділ Підпис, дата Підпис, дата
консультанта
Завдання видав Завдання прийняв
1
2
3
КАЛЕНДАРНИЙ ПЛАН
Строк
виконання
№
Назва етапів випускної роботи етапів Примітки
п/п
кваліфікаційної
роботи
1 Постановка задачі 15.12.2025 виконано
2 Підготовка завдання 18.12.2025 виконано
3 Погодження завдання 20.12.2025 виконано
4 Затвердження завдання 25.12.2025 виконано
Основна стадія
1 Підбір матеріалів 01.01.2026 виконано
2 Аналіз шляхів вирішення поставленої задачі 20.01.2026 виконано
3 Проектування програмного комплексу 03.02.2026 виконано
4 Реалізація основних програмних компонентів 20.03.2026 виконано
5 Оформлення первісної редакції роботи 05.04.2026 виконано
Заключна стадія
Узгодження прийнятих проектних рішень з
1 15.04.2026 виконано
керівником
2 Оформлення пояснювальної записки роботи 30.04.2026 виконано
3 Попередній захист роботи 20.05.2026 виконано
4 Затвердження роботи 25.05.2026 виконано
5 Рецензування роботи 30.05.2026 виконано
6 Захист роботи
____________________
Студент Сергієнко Н.С.
(підпис)
____________________
Керівник роботи Салапатов В.І.
(підпис)
АНОТАЦІЯ
Виконавець: Сергієнко Назар Сергійович.
Назва кваліфікаційної бакалаврської роботи: «Web-система формування
робочих програм кафедри ПЗАС ЧДТУ»
Спеціальність: 121 «Інженерія програмного забезпечення».
Установа: Черкаський державний технологічний університет (ЧДТУ).
Місто, рік: Черкаси, 2026 рік.
Метою виконання кваліфікаційної роботи бакалавра є проектування та
розробка веб-орієнтованого програмного комплексу для структурованого
введення, перевірки, збереження та експорту даних робочих програм кафедри
ПЗАС ЧДТУ. Об’єктом роботи є процес інженерного проектування, реалізації та
тестування web-системи з клієнт-серверною архітектурою.
Предметом розробки є програмні моделі, архітектурні рішення, структура
бази даних, API, клієнтські та серверні компоненти, засоби валідації і модуль
генерації PDF для автоматизації роботи зі структурованими даними робочої
програми.
У роботі виконано аналіз вимог до програмного забезпечення, побудовано
UML-моделі, спроектовано архітектуру системи, реалізовано клієнтську і
серверну частини, базу даних, модуль перевірки введених даних та модуль
генерації PDF.
Результатом роботи є програмний комплекс, що демонструє повний цикл
розробки прикладної web-системи: від аналізу вимог і проектування архітектури
до реалізації, розгортання та тестування основних сценаріїв.
Ключові слова: Робоча програма, WEB-система, Кафедра ПЗАС, ЧДТУ, REACT,
NODE.JS, EXPRESS, POSTGRESQL, PDF, UML.
ABSTRACT
Executor: Serhiienko Nazar Serhiiovych.
Title of the bachelor’s qualification work: “Web System for Forming Working
Programs of the Department of PZAS of ChSTU”
Specialty: 121 “Software Engineering”.
Institution: Cherkasy State Technological University (ChSTU).
City, year: Cherkasy, 2026.
The purpose of the bachelor’s qualification work is to design and develop a web-
oriented software complex for structured entry, validation, storage, and export of
working program data for the Department of PZAS of ChSTU. The object of the work is
the software engineering process of designing, implementing, and testing a client-server
web system.
The subject of the development is software models, architectural decisions,
database structure, API, client-side and server-side components, validation tools, and a
PDF generation module for automated processing of structured working program data.
The work includes software requirements analysis, UML modeling, system architecture
design, implementation of the client and server parts, database, validation module, and
PDF generation module.
The result of the work is a software complex that demonstrates a complete
development cycle of an applied web system: from requirements analysis and
architectural design to implementation, deployment, and testing of the main scenarios.
Keywords: Working program, WEB-system, Department of PZAS, ChDTU, REACT,
NODE.JS, EXPRESS, POSTGRESQL, PDF, UML.
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ....................................................................9
ВСТУП....................................................................................................................10
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ...............................................................................................................13
1.1. Аналіз технічної інформації..................................................................13
1.2. Актуальність задачі................................................................................16
1.3. Аналіз існуючих програмних засобів...................................................17
1.4. Аналіз способів вирішення задачі.........................................................20
1.5. Постановка задачі...................................................................................22
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ..............................................................24
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ.................................................................................................................25
2.1. Моделювання предметної області........................................................26
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області.................................................................26
2.1.2. Елементи моделювання предметної області.............................30
2.1.3. Робоча область моделювання.....................................................31
2.2. Формування та аналіз вимог..................................................................33
2.2.1. Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги.......................................................................33
2.2.2. Формування вимог за допомогою діаграми прецедентів........37
2.3. Проектування логічної структури програмного комплексу...............40
2.3.1. Діаграми класів............................................................................40
2.3.2. Діаграми пакетів.......................................................................... 43
ЧДТУ 262261.022 ПЗ
Змн. Арк. № докум. Підпис Дата
2.4. Архітектурне проектування...................................................................44
2.4.1. Діаграма компонентів.................................................................44
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання............................................................................................46
2.5. Моделювання поведінки системи.........................................................47
2.5.1. Діаграма діяльності.....................................................................48
2.5.2. Діаграма послідовності...............................................................49
2.5.3. Діаграма комунікації...................................................................50
2.5.4. Діаграма скінченного автомату..................................................51
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ...............................................................53
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
................................................................................................................................. 54
3.1. Розробка програмного комплексу.........................................................54
3.1.1. Обґрунтування вибору засобів реалізації.................................55
3.1.2. Опис структурної (функціональної) схеми...............................56
3.1.3. Опис логічної схеми системи.....................................................58
3.1.4. Розробка бази даних....................................................................59
3.1.5. Розробка інтерфейсу користувача.............................................61
3.1.6. Опис розробки програмних компонентів..................................65
3.2. Тестування системи................................................................................68
3.2.1. Модульне тестування..................................................................69
3.2.2. Інтеграційне тестування.............................................................70
3.2.3. Системне тестування...................................................................71
3.2.4. Приймальне тестування..............................................................72
3.3. Приклади впровадженого програмного комплексу............................72
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ..............................................................75
ВИСНОВКИ........................................................................................................... 76
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ..............................................................78
ДОДАТКИ.............................................................................................................. 81
ЧДТУ 262261.022 ПЗ
Змн. Арк. № докум. Підпис Дата
ЧДТУ 262261.022 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
Application Programming Interface, програмний інтерфейс взаємодії
API
компонентів
CSS Cascading Style Sheets, каскадні таблиці стилів
HTML HyperText Markup Language, мова розмітки гіпертексту
HTTP HyperText Transfer Protocol, протокол передавання гіпертексту
JavaScript Object Notation, текстовий формат обміну структурованими
JSON
даними
JWT JSON Web Token, токен авторизації користувача
PDF Portable Document Format, формат електронного документа
SQL Structured Query Language, мова запитів до бази даних
UI User Interface, користувацький інтерфейс
UML Unified Modeling Language, уніфікована мова моделювання
БД база даних
ПЗ програмне забезпечення
ПЗАС програмне забезпечення автоматизованих систем
ЧДТУ Черкаський державний технологічний університет
9
ЧДТУ 262261.022 ПЗ
ВСТУП
Актуальність теми. Дана кваліфікаційна робота бакалавра розглядається за
спеціальністю «Інженерія програмного забезпечення». Вона зумовлена потребою
створення спеціалізованого web-застосунку, який перетворює регламентовану
предметну інформацію на структуровані дані, забезпечує їх перевірку, збереження
у базі даних та формування PDF-результату. У межах спеціальності 121
«Інженерія програмного забезпечення» основний акцент роботи зроблено на
інженерних рішеннях: вимогах до програмного забезпечення, моделях даних,
клієнт-серверній архітектурі, API, модулях валідації, генерації PDF та тестуванні.
Ручне заповнення шаблонів у прикладній області розглядається не як
педагогічна проблема, а як джерело вимог до майбутнього програмного продукту.
Воно виявляє типові для інформаційних систем задачі: усунення дублювання
даних, формалізацію структури, перевірку обов’язкових полів, централізоване
збереження записів, контроль помилок і автоматизоване формування вихідного
файлу.
Для Черкаського державного технологічного університету практична задача
полягає у розробці прикладного програмного комплексу, який підтримує локальну
структуру даних робочої програми, надає зручний web-інтерфейс, забезпечує
серверну перевірку, роботу з PostgreSQL і генерацію PDF. Отже, предметна
область використовується як основа для проектування програмної системи, а не як
окремий напрям аналізу поза розробкою ПЗ.
Об’єктом дослідження є процес проектування, реалізації та тестування
web-орієнтованої інформаційної системи для автоматизованої обробки
структурованих даних робочих програм.
Предметом дослідження є методи, моделі та програмні компоненти web-
системи: клієнтський інтерфейс, серверний API, структура бази даних, модуль
валідації, механізм збереження даних і модуль генерації PDF.
10
ЧДТУ 262261.022 ПЗ
Метою роботи є розробка web-орієнтованого програмного комплексу
формування робочих програм кафедри ПЗАС ЧДТУ на основі аналізу вимог,
проектування архітектури, реалізації клієнтської та серверної частин і перевірки
працездатності системи.
Для досягнення поставленої мети необхідно виконати такі завдання:
проаналізувати предметну область як джерело вимог до програмного
забезпечення; сформувати функціональні та нефункціональні вимоги; побудувати
UML-моделі вимог, структури, архітектури та поведінки системи; спроектувати
базу даних, API та модулі програмного комплексу; обґрунтувати вибір засобів
реалізації; розробити клієнтську і серверну частини; реалізувати авторизацію,
перевірку введених даних, збереження у PostgreSQL і генерацію PDF; виконати
модульне, інтеграційне, системне та приймальне тестування.
Серед методів проектування та конструювання у роботі
використовуються методи системного аналізу, моделювання предметної області,
UML-моделювання, клієнт-серверного проектування, проектування баз даних,
компонентної декомпозиції програмного забезпечення та практичного тестування
веб-застосунку. Такий набір методів дає змогу перейти від аналізу проблеми до
конкретної архітектури й реалізації програмного комплексу.
Практичне значення роботи полягає в отриманні прикладного web-
застосунку, що демонструє програмну реалізацію структурованого введення
даних, їх перевірки, збереження в базі даних і генерації PDF. Розроблене рішення
може використовуватися як приклад інженерного проектування клієнт-серверної
інформаційної системи для конкретної предметної області.
Архітектура системи передбачає можливість подальшого розвитку до
універсального застосунку для керування шаблонами, формами введення,
правилами валідації та модулями експорту різних типів структурованих
документів.
Особистий внесок автора полягає у:
11
ЧДТУ 262261.022 ПЗ
- аналізі предметної області як джерела вимог до програмної системи та
аналізі існуючих програмних засобів автоматизації структурованого
введення і генерації документів;
- обґрунтуванні актуальності задачі розробки web-орієнтованого
програмного комплексу кафедри ПЗАС ЧДТУ;
- формуванні первинних і детальних вимог до web-системи;
- розробці моделей предметної області, логічної структури, архітектури та
поведінки програмної системи;
- проектуванні архітектури програмного забезпечення та структури бази
даних;
- реалізації серверної частини програмного забезпечення з використанням
Node.js, Express та PostgreSQL;
- реалізації клієнтської частини програмного забезпечення з
використанням React, Vite та JavaScript;
- розробці модуля перевірки введених даних із використанням Joi;
- реалізації модуля формування PDF-документа з використанням
Handlebars та Puppeteer;
- розробці користувацького інтерфейсу для створення, редагування,
збереження та експорту робочих програм;
- проведенні тестування розробленої системи та перевірці коректності її
основних функцій.
12
ЧДТУ 262261.022 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
Перший розділ кваліфікаційної роботи бакалавра відповідно до методичних
рекомендацій Черкаського державного технологічного університету містить аналіз
наукової та технічної інформації щодо теми розробки, огляд існуючих аналогів,
систематизацію отриманих даних і конкретизацію задач, які потребують
подальшого розв’язання [1]. Розділ має передпроєктний характер: він визначає,
чому задача є актуальною, які інструменти вже використовуються на ринку та яку
прогалину має закрити майбутня розробка.
Предметом аналізу є програмна задача створення web-системи, що працює зі
структурованими даними робочої програми, виконує їх перевірку, зберігає у базі
даних і формує PDF-результат за заданим шаблоном. Робоча програма у цій роботі
розглядається як складний інформаційний об’єкт із реквізитами, вкладеними
розділами, таблицями, списками та правилами заповнення.
Університетський контекст у роботі використовується як прикладна область
для розробки програмного забезпечення. Він задає структуру даних, ролі
користувачів і вимоги до вихідного файлу, але основний зміст кваліфікаційної
роботи становлять інженерні рішення: проектування моделей, API, бази даних,
модулів валідації, інтерфейсу та генерації PDF.
1.1. Аналіз технічної інформації
З погляду розробки програмного забезпечення робоча програма є складним
структурованим об’єктом, який повторюється для різних дисциплін,
спеціальностей і навчальних років. Такий об’єкт містить реквізити, текстові блоки,
таблиці, списки, оцінювання та джерела, тому потребує не лише текстового
редагування, а й формальної моделі даних, правил перевірки та механізму
експорту.
13
ЧДТУ 262261.022 ПЗ
Першою інженерною проблемою є дублювання даних. Назва дисципліни,
навчальний рік, спеціальність, освітня програма, освітній рівень, кафедра та дані
викладача можуть повторюватися у різних розділах і представленнях. У
програмній системі ці значення доцільно зберігати один раз і повторно
використовувати під час відображення, редагування та генерації PDF.
Другою інженерною проблемою є складність структури даних. Робоча
програма містить різнорідні типи інформації: короткі реквізити, великі текстові
поля, багаторядкові таблиці, списки, критерії, шкали і джерела. Така структура
погано підтримується лінійною моделлю редагування, тому для програмної
реалізації потрібна секційна форма введення та вкладений об’єкт даних.
Третьою інженерною проблемою є ризик помилок у числових і форматних
полях. У робочих програмах використовуються навчальні роки, кількість кредитів,
години аудиторної та самостійної роботи, шкали оцінювання, URL-адреси,
електронні адреси і дати. Для таких значень потрібні клієнтська та серверна
валідація, оскільки звичайний текстовий редактор не контролює предметну логіку
полів.
Четвертою інженерною проблемою є керування станом і версіями даних.
Якщо результат існує лише як набір файлів, виникають дублікати, паралельні
редакції та невідомий актуальний стан. Програмна система має зберігати записи
централізовано, підтримувати оновлення через API і створювати основу для
подальшого розширення механізмів статусів або історії змін.
П’ятою інженерною проблемою є різниця між універсальними цифровими
інструментами та локальною структурою даних конкретного закладу. Багато
платформ уміють створювати документи, збирати відповіді або керувати курсами,
але вони не містять готової моделі робочої програми ЧДТУ. Через це користувачі
все одно змушені вручну переносити дані у затверджений формат.
Шостою інженерною проблемою є потреба у стабільному результаті для
різних ролей користувачів. Викладачеві потрібне редагування, відповідальній
14
ЧДТУ 262261.022 ПЗ
особі - перевірка повноти, адміністратору - керування довідниками, а система
повинна забезпечити однаковий вихідний PDF незалежно від робочого місця
користувача.
Узагальнення технічної інформації перед таблицею 1.1 дає змогу показати,
що основною проблемою є не сам факт підготовки підсумкового файла, а
відсутність спеціалізованого програмного забезпечення, яке працює зі
структурованими даними. Для web-системи важливо заздалегідь визначити, які
дані повинні вводитися один раз, які значення мають повторно використовуватися
в різних розділах, а які поля потребують автоматичної перевірки.
З інженерної точки зору така задача потребує поєднання кількох програмних
механізмів: зручного клієнтського інтерфейсу для введення даних, серверної
логіки для оброблення запитів, бази даних для збереження інформації, модуля
валідації для контролю коректності введення та модуля експорту для формування
стабільного PDF-результату. Саме взаємодія цих частин визначає майбутню
архітектуру системи.
У таблиці 1.1 узагальнено основні проблеми, встановлені під час аналізу
технічної інформації, та наведено їхній вплив на вимоги до майбутнього
програмного комплексу.
Таблиця 1.1
Основні проблеми, що визначають вимоги до програмної системи
Наслідок для майбутнього
Проблема Прояв у прикладній області
програмного рішення
Потрібна єдина структурована
Дублювання Однакові дані вводяться у
модель даних і автоматичне
реквізитів кількох частинах документа.
повторне використання значень.
15
ЧДТУ 262261.022 ПЗ
Продовження таблиці 1.1
Документ поєднує текст, Потрібне секційне введення з
Складність
таблиці, списки, шкали, подальшою генерацією цілісного
структури даних
джерела і погоджувальні блоки. PDF.
Години, бали, дати, URL і
Потрібна автоматична валідація
Формальні помилки електронні адреси
полів і підказки для користувача.
перевіряються вручну.
Файли надсилаються між Потрібне централізоване
Паралельні версії учасниками процесу і можуть зберігання, статуси або журнал
дублюватися. змін.
Локальні вимоги до Універсальні інструменти не Потрібні модель даних і шаблон
структури даних мають готової форми робочої експорту, адаптовані до
ЧДТУ програми. локальної структури.
Потреба в Після заповнення дані мають Потрібен експорт у стабільний
офіційному стати охайним документом для друкований формат, наприклад
результаті друку або архіву. PDF або DOCX.
Отже, головна інженерна проблема полягає не у відсутності текстового
редактора або електронної таблиці, а у відсутності програмної системи, яка
поєднує структуроване введення, перевірку, централізоване збереження та
генерацію PDF. Саме ця прогалина визначає напрям подальшого проектування і
розробки.
1.2. Актуальність задачі
Отже, актуальність розробки визначається практичною потребою у
спеціалізованій web-системі, яка поєднує структуроване введення даних,
попередню перевірку, централізоване збереження та формування готового PDF-
16
ЧДТУ 262261.022 ПЗ
файлу. Такий підхід відповідає сучасній тенденції переходу від ручного
редагування файлів до предметно орієнтованих інформаційних систем.
Задача є актуальною також через необхідність проектування єдиної моделі
даних. Назва дисципліни, інформація про викладача, тематичний план, критерії
оцінювання та перелік літератури повинні зберігатися в узгодженому вигляді й
використовуватися різними модулями системи без дублювання та розбіжностей.
Для кафедри ПЗАС ЧДТУ така система є прикладом прикладного
програмного забезпечення, орієнтованого на конкретну предметну область. Вона
повинна забезпечити web-інтерфейс, серверну логіку, базу даних, перевірку
введених значень і генерацію PDF, тобто охопити повний цикл розробки
інформаційної системи.
1.3. Аналіз існуючих програмних засобів
Найпростішим і найпоширенішим методом є використання шаблонів
Microsoft Word або LibreOffice Writer. Microsoft Word підтримує створення
власних шаблонів документів, збереження їх у форматах шаблонів і повторне
використання структури [2]. Для роботи з правками доступний механізм
відстеження змін, що дозволяє бачити редагування різних учасників [3]. Такий
підхід є доступним і зрозумілим, але він не вирішує проблему предметної
валідації, не усуває дублювання даних і не гарантує, що всі робочі програми
будуть заповнені однаково.
Другим підходом є використання хмарних документів, електронних таблиць
і форм. Google Forms дозволяє збирати відповіді та пов’язувати їх із таблицями
для подальшої обробки [4]. У практиці університетів це може бути зручним для
збирання окремих реквізитів, списків тем або заявок. Проте форма або таблиця не
створює автоматично повноцінну робочу програму з титульними сторінками,
таблицями, погодженням і друкованим виглядом. Після збирання даних
залишається окремий етап перенесення у документ.
17
ЧДТУ 262261.022 ПЗ
Третім підходом є використання систем електронного документообігу та
платформ Microsoft 365. SharePoint у поєднанні з Power Automate може
використовуватися для автоматизації погодження документів, зокрема для
маршрутизації файлів на затвердження [5]. Такий інструмент добре підходить для
контролю процесу, але сам по собі не створює предметну структуру робочої
програми. Його доводиться поєднувати з формами, шаблонами або додатковими
налаштуваннями.
Четвертим підходом є використання систем управління навчанням, зокрема
Moodle. Moodle підтримує різні формати курсів, поділ курсу на секції, додавання
ресурсів, активностей, тестів і навчальних матеріалів [6]. Це важливий інструмент
для організації навчального процесу, однак його основне призначення полягає у
супроводі курсу, а не у формуванні офіційної робочої програми у локальному
форматі закладу вищої освіти.
П’ятим підходом є спеціалізовані закордонні платформи для керування
силабусами, каталогами і навчальними програмами. Simple Syllabus
позиціонується як централізована платформа для шаблонного створення й
публікації інтерактивних силабусів із інтеграцією в LMS [7]. CourseLeaf CIM
пропонує динамічні форми, інтелектуальні workflow, інтеграцію з
інформаційними системами закладу та історію змін для управління навчальними
курсами і програмами [8]. Coursedog описує себе як академічну операційну
платформу, що поєднує планування, каталоги, curriculum management, assessment
та інші процеси [9].
Такі системи демонструють, що на світовому ринку вже є попит на
структуроване управління освітніми документами. Проте вони орієнтовані
переважно на англомовний ринок, інші моделі навчальної документації та
комплексне управління академічними процесами. Для задачі формування робочих
програм ЧДТУ вони можуть бути функціонально надмірними, дорогими або
складними для локалізації.
18
ЧДТУ 262261.022 ПЗ
Таблиця 1.2
Порівняння наявних груп інструментів
Група Що залишається
Що вирішує
інструментів невирішеним
Не забезпечують предметної
Дають знайомий спосіб
Word/LibreOffice валідації, централізації даних і
оформлення документа і ручне
шаблони захисту від розбіжностей у
редагування тексту.
реквізитах.
Полегшують спільну роботу та Не формують автоматично
Хмарні документи,
збирання структурованих повний офіційний документ за
форми і таблиці
відповідей. локальною структурою.
Не містять готової моделі
SharePoint та Power Підтримують зберігання файлів і робочої програми, потребують
Automate маршрути погодження. налаштування й
адміністрування.
Організують навчальний курс, Не призначені для генерації
Moodle та інші LMS матеріали, активності та робочих програм у вигляді
комунікацію. методичного документа.
Орієнтована на формат
Централізує створення силабусів і syllabus, який не тотожний
Simple Syllabus
їх публікацію через LMS. українській робочій програмі
дисципліни.
Є комплексними академічними
Підтримують curriculum
CourseLeaf CIM, платформами, що можуть бути
management, workflow, каталоги,
Coursedog надмірними для вузької задачі
інтеграції та історію змін.
ЧДТУ.
19
ЧДТУ 262261.022 ПЗ
Порівняння показує, що ринок має багато суміжних інструментів, але
більшість із них вирішує лише частину програмної задачі. Одні засоби сильні у
текстовому редагуванні, інші - у спільній роботі, ще інші - у погодженні або
керуванні навчальним процесом. Проте для проектованої web-системи потрібне
поєднання структурованої моделі даних, перевірки, збереження та генерації
результату.
1.4. Аналіз способів вирішення задачі
Для конкретизації майбутньої задачі доцільно окремо розглянути аналоги,
які найближче підходять до предметної області. Першим таким аналогом є Simple
Syllabus. Його сильна сторона полягає у централізації шаблонів силабусів і
зменшенні ручного дублювання інформації між курсами. Платформа також
орієнтується на інтеграцію з LMS, що зручно для закладів, де силабус повинен
бути доступним студентам у середовищі навчання [7].
Разом з тим силабус і робоча програма навчальної дисципліни не є повністю
однаковими документами. Українська робоча програма має іншу нормативну
традицію, службові блоки, таблиці навантаження, погодження, структуру розділів
і вимоги до оформлення. Тому готова платформа силабусів не усуває потребу в
локальному рішенні, яке враховує форму ЧДТУ.
Другим аналогом є CourseLeaf CIM. Ця система орієнтована на управління
навчальними курсами і програмами через динамічні форми, workflow, інтеграцію з
інформаційними системами та архів змін [8]. Такий підхід важливий для великих
університетів, де багато погоджень, каталогів, програм і залежностей між курсами.
Він показує, що формалізовані освітні документи краще обробляти не як окремі
файли, а як структуровані дані з керованими процесами.
Однак CourseLeaf CIM більше стосується пропозицій щодо курсів, програм і
каталогів, а не автоматичного формування робочих програм у конкретному
українському шаблоні. Для використання подібної системи потрібна інтеграція з
20
ЧДТУ 262261.022 ПЗ
інфраструктурою університету, ліцензування, налаштування форм і адаптація до
локального документообігу. Для бакалаврської інженерної задачі це радше
орієнтир, ніж готове рішення.
Третім аналогом є Coursedog. Платформа об’єднує академічні операції,
зокрема curriculum, catalogs, scheduling, assessment та інші процеси [9]. Її перевага
полягає у широкому охопленні академічного управління. Проте така широта
водночас є обмеженням для локальної задачі: якщо потрібно автоматизувати саме
створення робочої програми дисципліни, комплексна платформа може бути
надмірною за функціями, складністю і вартістю впровадження.
Четвертим аналогом є Moodle як найпоширеніший клас систем управління
навчанням. Moodle дозволяє структурувати курс за темами або тижнями, додавати
ресурси, активності та інші елементи навчального процесу [6].
П’ятим класом аналогів є системи документообігу і low-code платформи.
Вони можуть забезпечити маршрути погодження, ролі, статуси, повідомлення і
зберігання файлів.
Таблиця 1.3
Аналіз найближчих аналогів
Аналог Сильні сторони Обмеження для задачі ЧДТУ
Формат силабусу не збігається
Централізовані шаблони
з українською робочою
Simple Syllabus силабусів, публікація в LMS,
програмою навчальної
зменшення ручного дублювання.
дисципліни.
Орієнтація на curriculum
Динамічні форми, workflow,
proposals і каталоги; потрібні
CourseLeaf CIM інтеграція з SIS, історія змін,
ліцензування та глибока
робота з курсами і програмами.
локалізація.
21
ЧДТУ 262261.022 ПЗ
Продовження таблиці 1.3
Широка академічна платформа Надмірна для вузької задачі
Coursedog для розкладів, каталогів, створення робочої програми за
curriculum і assessment. формою конкретного ЗВО.
Керування навчальним курсом, Не є генератором офіційних
Moodle темами, матеріалами, робочих програм і не містить
активностями і тестами. локального шаблону ЧДТУ.
Потребує предметних форм і
SharePoint/Power Документообіг, погодження,
додаткової логіки для генерації
Automate статуси, бібліотеки файлів.
робочої програми.
Немає автоматичного
Швидке збирання відповідей,
Google/Microsoft створення повного документа з
експорт у таблиці, простота
форми і таблиці потрібною версткою і
використання.
структурою.
Отже, аналіз аналогів показує наявність ринкової ніші між універсальними
офісними інструментами і великими академічними платформами. Для потреб
ЧДТУ потрібен не повний аналог CourseLeaf або Coursedog, а легший
спеціалізований програмний засіб, який фокусується на сценарії створення,
редагування, збереження та експорту робочої програми у потрібній структурі.
1.5. Постановка задачі
Проведений аналіз показує, що наявні інструменти частково закривають
потреби прикладної області, але не забезпечують комплексного програмного
рішення. Найбільш помітним невирішеним питанням є відсутність web-системи,
яка поєднує структуроване введення даних, перевірку коректності реквізитів,
збереження у базі даних і генерацію PDF за локальним шаблоном.
Окремою проблемою залишається адаптація програмної системи до
внутрішньої структури даних конкретного закладу. Універсальні офісні редактори,
22
ЧДТУ 262261.022 ПЗ
хмарні документи, LMS і системи документообігу не містять предметної моделі
робочої програми ЧДТУ. Через це користувачеві доводиться самостійно
контролювати повторюваність даних, логіку розподілу годин, повноту розділів і
відповідність вихідного файлу шаблону.
Також невирішеним залишається питання зменшення ручних операцій без
переходу до надмірно складних корпоративних платформ. Великі системи
академічного управління мають широку функціональність, але їх упровадження
потребує значних організаційних, фінансових і технічних ресурсів. Для
бакалаврської роботи зі спеціальності «Інженерія програмного забезпечення»
доцільним є проектування компактного прикладного web-застосунку з чітко
визначеними межами.
Отже, ринкова ніша полягає у потребі спеціалізованого програмного засобу
для підтримки конкретного набору сценаріїв: введення структурованих даних, їх
перевірки, збереження, пошуку та експорту у PDF. Такий висновок не описує
навчальний процес, а фіксує програмну проблему, яку не повністю розв’язують
наявні аналоги.
23
ЧДТУ 262261.022 ПЗ
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ
У першому розділі було розглянуто технічні передумови створення
програмного комплексу, обґрунтовано актуальність задачі, проаналізовано
існуючі програмні засоби та способи вирішення поставленої задачі. Визначено, що
проблема полягає не у створенні текстового документа, а у потребі спроектувати
систему зі структурованою моделлю даних, перевіркою введення,
централізованим збереженням і стабільною генерацією PDF.
Аналіз поширених методів і засобів показав, що універсальні текстові
редактори, електронні таблиці, хмарні документи, LMS і системи документообігу
розв’язують лише окремі частини задачі. Вони можуть допомагати з
редагуванням, зберіганням або погодженням, але не забезпечують повного
програмного циклу: від структурованого введення і валідації до збереження в базі
даних та автоматичного експорту результату.
Порівняння спеціалізованих рішень, зокрема Simple Syllabus, CourseLeaf
CIM і Coursedog, показало, що на ринку існує попит на предметно орієнтовані
інформаційні системи. Водночас такі рішення здебільшого орієнтовані на інші
організаційні моделі, мають ширший масштаб або потребують складного
впровадження. Для локальної задачі ЧДТУ залишається актуальною потреба у
простішому спеціалізованому програмному підході.
Таким чином, за результатами аналізу обґрунтовано потребу в розробці web-
орієнтованого програмного комплексу. Подальша робота спирається на висновок
про необхідність системи, здатної зменшити ручне дублювання даних, підвищити
контроль коректності, забезпечити збереження структурованої інформації та
формування PDF-результату.
24
ЧДТУ 262261.022 ПЗ
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ
Другий розділ присвячено проектуванню програмного комплексу
формування робочих програм кафедри ПЗАС ЧДТУ [1]. У межах розділу
визначаються межі предметної області як джерела вимог до програмного
забезпечення, основні об’єкти даних, функціональні та нефункціональні вимоги,
логічна структура, архітектура та поведінкові моделі системи.
Проектування виконується як перехід від загальної постановки задачі до
формального опису майбутньої програмної системи. Такий підхід відповідає
загальним принципам інженерії вимог, за якими перед реалізацією необхідно
визначити межі системи, склад користувацьких сценаріїв, структуру даних,
архітектурні компоненти та поведінку системи в основних процесах [11; 14].
Особливість проектованої web-системи полягає в тому, що вона працює не з
короткою формою введення, а зі складним структурованим об’єктом. Тому під час
проектування потрібно врахувати послідовність заповнення розділів, контроль
повноти даних, повторне редагування, збереження проміжного результату та
формування кінцевого PDF-файлу у сталому вигляді.
Проектована система призначена для програмної підтримки введення
реквізитів дисципліни, даних викладача, структури змістових розділів,
тематичного плану, лабораторних робіт, самостійної роботи, оцінювання,
літератури та інформаційних ресурсів із подальшим збереженням даних і
формуванням PDF-документа встановленої структури.
У межах проектування система розглядається як клієнт-серверний
програмний комплекс, у якому користувацький інтерфейс відповідає за введення і
перегляд даних, серверна частина - за перевірку, збереження та підготовку
документа, а база даних - за довготривале зберігання структурованої інформації.
25
ЧДТУ 262261.022 ПЗ
Такий розподіл відповідальності спрощує подальшу підтримку системи та дає
змогу окремо розвивати інтерфейс, бізнес-логіку і рівень даних [12; 15].
2.1. Моделювання предметної області
Предметна область у межах проектування визначає дані, ролі та сценарії, які
повинна підтримувати програмна система. Основними ролями є користувач,
викладач, методист та адміністратор, а основними інформаційними об’єктами -
робоча програма, викладач, користувач, PDF-документ і структуровані вкладені
дані програми.
Для моделювання предметної області важливо відокремити зміст робочої
програми від технічних дій користувача. У web-системі робоча програма повинна
бути представлена як набір взаємопов’язаних даних, придатних для перевірки,
редагування, повторного використання і перетворення у друкований формат.
Модель предметної області також дає змогу визначити, які поняття є
стабільними для системи. Наприклад, викладач, дисципліна, тематичний план,
критерії оцінювання та список літератури не є випадковими полями форми, а
складають змістові частини робочої програми. Саме тому вони виділяються
окремо у словнику та подальших UML-моделях [13; 16].
Центральним об’єктом предметної області є робоча програма як сутність
даних. Вона об’єднує загальні реквізити дисципліни, інформацію про викладача,
мету і завдання, результати навчання, програму дисципліни, тематичний план,
лабораторні роботи, самостійну роботу, систему оцінювання, екзаменаційні
питання, літературу та інформаційні ресурси.
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметна область моделювання охоплює дані та сценарії, які повинна
підтримувати web-система формування робочих програм кафедри ПЗАС ЧДТУ. У
межах цієї області розглядаються основні ролі користувачів, зокрема викладач,
26
ЧДТУ 262261.022 ПЗ
методист та адміністратор, а також інформаційні об’єкти, з якими працює система:
робоча програма, дисципліна, дані викладача, тематичний план, система
оцінювання, список літератури та сформований PDF-документ. Це створює основу
для подальшого формування вимог, побудови UML-діаграм і проектування
логічної структури web-системи.
Модель предметної області визначає поняття, якими оперує програмна
система під час створення робочої програми. Для проектованої системи важливо
розділити дані, що зберігаються як окремі сутності, та вкладені структурні
частини робочої програми, які утворюють єдиний об’єкт експорту.
Словник предметної області використовується як основа для однакового
розуміння термінів у всіх наступних моделях. Якщо на етапі вимог не зафіксувати
значення основних понять, у подальшому можуть виникати неоднозначності між
інтерфейсом, структурою бази даних і шаблоном PDF-документа.
У таблиці наведено не лише назви понять, а й їх зміст саме в контексті
проектованої системи. Це важливо, оскільки ті самі терміни в організаційному
процесі можуть мати ширше значення, тоді як у програмному забезпеченні вони
повинні мати чіткі межі та передбачувану структуру.
Таблиця 2.1
Словник предметної області
Термін Зміст у межах предметної області
Особа, яка працює з веб-інтерфейсом системи та виконує дії відповідно
Користувач
до своєї ролі.
Користувач або відповідальна особа, дані якої можуть використовуватися
Викладач
під час заповнення робочої програми.
Роль користувача, що може переглядати або перевіряти повноту
Методист
введених даних.
27
ЧДТУ 262261.022 ПЗ
Продовження таблиці 2.1
Основна предметна сутність, що містить реквізити дисципліни,
Робоча програма
структуровані розділи, оцінювання та джерела.
Навчальний компонент освітньої програми, для якого створюється
Дисципліна
робоча програма.
Початкова структура документа, що містить набір розділів і типових
Шаблон програми
полів для заповнення.
Логічна частина документа: опис дисципліни, результати навчання,
Розділ програми
тематичний план, оцінювання тощо.
Навчальне Сукупність годин, кредитів, видів занять і форми підсумкового
навантаження контролю.
Перелік тем дисципліни з розподілом лекційних, лабораторних,
Тематичний план
практичних і самостійних годин.
Фінальне подання робочої програми, сформоване системою за даними
PDF-документ
збереженої програми.
На рисунку 2.1 подано модель предметної області системи. У центрі моделі
розташована робоча програма, яка пов’язана з дисципліною, викладачем,
шаблоном, навчальним навантаженням, тематичним планом, оцінюванням та
джерелами.
Зв’язки між сутностями показують, що одна робоча програма формується
для конкретної дисципліни, належить певному користувачу або викладачу та
містить набір структурних розділів. Окреме виділення PDF-документа
пояснюється тим, що він є результатом перетворення структурованих даних у
кінцеву форму подання, а не первинним джерелом інформації.
28
ЧДТУ 262261.022 ПЗ
Рисунок 2.1 - Модель предметної області системи формування робочих програм
29
ЧДТУ 262261.022 ПЗ
2.1.2. Елементи моделювання предметної області
Для подальшого проектування об’єкти предметної області доцільно
поділити на сутності, граничні елементи та керуючі елементи. Сутності описують
дані, що мають зберігатися або бути включені до документа. Граничні елементи
забезпечують взаємодію користувача з системою. Керуючі елементи відповідають
за обробку запитів, перевірку даних, збереження та формування вихідного
документа.
Такий поділ відповідає поширеному підходу boundary-control-entity, який
дає змогу розмежувати інтерфейс користувача, керування сценаріями та сталі дані
предметної області [15; 16]. Для даної системи це особливо зручно, оскільки один
і той самий набір даних робочої програми використовується у різних сценаріях:
редагуванні, збереженні, перегляді та експорті у PDF.
Граничні елементи не повинні містити складної бізнес-логіки, адже їх
основне призначення полягає у відображенні даних і прийнятті дій користувача.
Керуючі елементи координують виконання сценарію, а сутності зберігають
змістові дані, які мають значення незалежно від конкретного екрана або кнопки
інтерфейсу.
Таблиця 2.2
Елементи моделювання предметної області
Група елементів Елементи системи Призначення
Зберігання користувачів,
User, Teacher, WorkingProgram, довідника викладачів та
Сутності
WorkingProgramData структурованих даних робочої
програми.
Введення, редагування, пошук,
AuthModal, ProgramEditor,
Граничні елементи вибір розділів, запуск
TeacherDrawer, форми розділів
збереження та відкриття PDF.
30
ЧДТУ 262261.022 ПЗ
Продовження таблиці 2.2
AuthController, Прийняття HTTP-запитів,
Керуючі елементи WorkingProgramController, передавання даних у сервіси,
TeacherController формування відповідей клієнту.
AuthService, Бізнес-логіка авторизації, роботи
Сервіси WorkingProgramService, з програмами, викладачами та
TeacherService, PdfService генерації PDF.
2.1.3. Робоча область моделювання
Робоча область моделювання охоплює взаємодію користувача з веб-
інтерфейсом, передавання даних до серверної частини, перевірку запитів, роботу з
базою даних і формування PDF-документа. До меж системи включено клієнтський
застосунок, серверний API, модуль генерації PDF, HTML-шаблон та базу даних.
Межі системи встановлюють, які процеси автоматизуються програмним
комплексом, а які залишаються зовнішніми. До внутрішніх процесів належать
введення даних, перевірка структури, збереження, пошук, експорт і генерація PDF.
До зовнішніх процесів належать організаційне погодження, нормативне
затвердження та використання сформованого результату поза системою.
Таке розмежування необхідне для коректного формування вимог: система не
підміняє адміністративні процедури кафедри, але забезпечує програмну обробку
даних і формування результату у передбачуваному форматі.
Поза межами системи залишаються організаційні рішення кафедри, зовнішні
навчальні платформи та ручне погодження підписів. У межах системи
реалізуються лише програмні функції: введення, перевірка, збереження, пошук і
експорт даних.(див. Рисунок 2.2)
31
ЧДТУ 262261.022 ПЗ
Рисунок 2.2 - Робоча область моделювання системи
32
ЧДТУ 262261.022 ПЗ
2.2. Формування та аналіз вимог
Вимоги до проектованої системи сформовано на основі задачі розробки web-
застосунку для обробки структурованих даних робочої програми. Вони
визначають, які функції повинна виконувати система, які дані мають оброблятися,
які обмеження накладаються на введення, збереження та експорт результату.
Формування вимог є ключовим етапом проектування, оскільки саме вимоги
визначають майбутню поведінку системи та критерії її придатності до
використання. Відповідно до підходів інженерії вимог, функції системи мають
бути описані не лише як побажання користувача, а як перевірювані твердження,
які можна зіставити з реалізованими можливостями [11; 14].
Для системи формування робочих програм вимоги мають враховувати як
структуру предметних даних, так і технічні аспекти роботи web-застосунку.
Користувачу важливо швидко вводити дані, бачити помилки, зберігати результат і
формувати PDF, а розробнику необхідно забезпечити структуровану передачу
даних, авторизацію, надійне зберігання та підтримуваність коду.
2.2.1. Формування вимог до програмного забезпечення. Вимоги замовника
і розробника. Функціональні та нефункціональні вимоги
Формування вимог до програмного забезпечення.
Для системи формування робочих програм можна виділити первинні
вимоги, що описують очікування користувача, та детальні вимоги, які уточнюють
ці очікування з позиції розробника програмного забезпечення.
Первинні вимоги відображають очікуваний результат з позиції
користувача: створити програму, заповнити розділи, зберегти дані, сформувати
документ.
Детальні вимоги переводять ці очікування у конкретні технічні рішення:
поля форми, формат JSON-даних, серверні маршрути, перевірку обов’язкових
значень і відповідь API.
33
ЧДТУ 262261.022 ПЗ
Таблиця 2.3
Первинні та детальні вимоги до системи
Первинна вимога Деталізація для розробника
Система повинна надавати форму створення
Користувач повинен мати змогу
програми з обов’язковими полями: назва
створити робочу програму дисципліни.
документа, назва дисципліни, навчальний рік.
Клієнтський інтерфейс повинен містити окремі
Користувач повинен заповнювати всі розділи для титулу, погодження, викладача, опису
основні розділи програми. дисципліни, мети, програми, плану, оцінювання та
ресурсів.
Інтерфейс повинен містити список програм і пошук
Користувач повинен швидко знаходити
за назвою, дисципліною, навчальним роком,
потрібну програму.
спеціальністю або викладачем.
Сервер повинен генерувати PDF на основі HTML-
Система повинна формувати офіційний
шаблону робочої програми та даних збереженого
результат.
запису.
Авторизація повинна використовувати парольний
Доступ до облікового запису повинен
хеш і JWT-токен; реєстрація має приймати
бути захищений.
корпоративну адресу @chdtu.edu.ua.
Вимоги замовника відображають очікування користувачів до майбутньої
системи з погляду практичного використання програмного продукту. Система
повинна забезпечувати створення робочої програми, заповнення основних
розділів, збереження введених даних і формування готового PDF-файлу
відповідно до прийнятої структури. Для користувача важливо, щоб web-інтерфейс
був зрозумілим, не вимагав спеціальних технічних знань і зменшував кількість
ручних дій. Також система має допомагати уникати помилок у заповненні
34
ЧДТУ 262261.022 ПЗ
обов’язкових полів і забезпечувати повторне використання вже внесеної
інформації.
Вимоги розробника деталізують технічні умови реалізації системи та
визначають, якими засобами повинна бути забезпечена її працездатність.
Програмне забезпечення має мати поділ на клієнтську і серверну частини,
підтримувати обмін даними через API, зберігати інформацію у базі даних та
виконувати перевірку коректності введених даних. Необхідно передбачити
структуру даних для робочих програм, викладачів, користувачів і документів, а
також реалізувати механізм генерації PDF на основі шаблону. Система повинна
бути придатною до подальшого розширення, тестування та супроводу, тому
важливими є зрозуміла архітектура, модульність програмних компонентів і
надійна обробка помилок.
Функціональні вимоги описують поведінку системи під час роботи
користувача з робочими програмами. Нефункціональні вимоги визначають
обмеження щодо безпеки, зручності, надійності, продуктивності та
підтримуваності.
Вони визначають набір дій, які система повинна виконувати у відповідь на
запити користувача. Вони безпосередньо пов’язані з варіантами використання,
оскільки кожний важливий сценарій має завершуватися конкретним результатом:
створенням запису, оновленням даних, видаленням програми або отриманням
PDF-файлу.
Нефункціональні вимоги мають не менше значення, оскільки вони
визначають якість роботи системи. Для даного програмного комплексу важливими
є зрозумілість інтерфейсу, безпечне зберігання паролів, коректна обробка
помилок, стабільність генерації PDF та можливість подальшого розширення
структури даних [11; 15].
Таблиця 2.4
35
ЧДТУ 262261.022 ПЗ
Функціональні вимоги
Код Вимога
Система повинна забезпечувати реєстрацію та вхід користувача за корпоративною
F1
поштою ЧДТУ.
Система повинна зберігати токен авторизації у сеансовому або постійному
F2
сховищі браузера відповідно до вибору користувача.
Система повинна надавати список створених робочих програм із можливістю
F3
пошуку.
Система повинна створювати нову робочу програму на основі типового шаблону
F4
даних.
Система повинна редагувати загальні реквізити програми та вкладені розділи
F5
документа.
Система повинна додавати, змінювати та видаляти елементи масивів: теми,
F6
результати навчання, лабораторні роботи, літературу, критерії оцінювання.
Система повинна виконувати клієнтську та серверну перевірку обов’язкових і
F7
форматних полів.
Система повинна зберігати робочу програму в базі даних і повертати оновлений
F8
запис.
F9 Система повинна формувати PDF-документ для збереженої робочої програми.
Система повинна дозволяти видалення робочої програми та власного облікового
F10
запису.
Система повинна підтримувати довідник викладачів і підставляти дані викладача
F11
до робочої програми.
36
ЧДТУ 262261.022 ПЗ
Таблиця 2.5
Нефункціональні вимоги
Код Вимога
Інтерфейс повинен бути придатним для послідовного заповнення великого
NF1
документа без перевантаження користувача.
Дані повинні передаватися між клієнтом і сервером у структурованому JSON-
NF2
форматі.
NF3 Паролі користувачів повинні зберігатися тільки у вигляді хешу.
NF4 Сервер повинен повертати зрозумілі повідомлення про помилки валідації.
Структура даних робочої програми повинна допускати розширення без зміни всіх
NF5
таблиць бази даних.
Формування PDF повинно виконуватися на сервері, щоб результат не залежав від
NF6
налаштувань браузера користувача.
Система повинна бути розділена на клієнтську, серверну та базову частини для
NF7
спрощення супроводу.
Застосунок повинен працювати через веб-браузер без встановлення окремої
NF8
клієнтської програми.
2.2.2. Формування вимог за допомогою діаграми прецедентів
Діаграма прецедентів відображає функції системи з погляду зовнішніх
учасників. Основним актором є користувач ЧДТУ, який реєструється, входить у
систему, створює та редагує робочу програму, працює з довідником викладачів і
формує PDF. Методист розглядається як роль, що використовує ті самі функції
перегляду та перевірки повноти введених даних.
Варіанти використання дають змогу описати систему мовою цілей
користувача, а не внутрішніх класів чи таблиць. Це важливо на етапі аналізу
37
ЧДТУ 262261.022 ПЗ
вимог, оскільки користувач взаємодіє з системою через зрозумілі дії:
зареєструватися, увійти, створити програму, відредагувати розділи, зберегти
результат і сформувати PDF [13; 16].
У межах діаграми прецедентів не деталізуються алгоритми, структура бази
даних або внутрішні виклики серверних модулів. Її призначення полягає у фіксації
функціонального охоплення системи та перевірці того, що всі ключові потреби
користувача представлені у моделі.
Таблиця 2.6
Основні варіанти використання
Прецедент Актор Результат
Створено обліковий запис і
Зареєструватися в системі Користувач ЧДТУ
видано токен доступу.
Користувач отримує доступ
Увійти в систему Користувач ЧДТУ
до робочої області.
Сформовано нову програму
Створити робочу програму Викладач
на основі шаблону.
Оновлено структуровані дані
Редагувати розділи програми Викладач
робочої програми.
Довідник викладачів
Додати викладача Викладач або адміністратор
поповнено новим записом.
Дані записано або оновлено в
Зберегти робочу програму Викладач
базі даних.
Система повертає
Відкрити PDF Викладач або методист
сформований PDF-документ.
Запис робочої програми
Видалити робочу програму Викладач
вилучено з бази даних.
38
ЧДТУ 262261.022 ПЗ
Продовження таблиці 2.6
Система показує помилки
Перевірити заповнення Викладач або методист обов’язкових або форматних
полів.
На рисунку 2.3 показана діаграма варіантів використання системи.
Рисунок 2.3 - Діаграма варіантів використання системи
39
ЧДТУ 262261.022 ПЗ
2.3. Проектування логічної структури програмного комплексу
Логічна структура програмного комплексу відображає основні програмні
сутності та зв’язки між ними. Для проектованої системи логічна модель
складається з клієнтських форм, серверних контролерів, сервісів бізнес-логіки,
валідаторів, шаблонів документа та сутностей бази даних.
Логічне проектування перетворює вимоги на набір програмних елементів,
які мають чіткі відповідальності. На цьому рівні ще не розглядаються деталі
фізичного розгортання, проте вже визначається, які класи, модулі та пакети будуть
потрібні для підтримки основних сценаріїв роботи.
Для проектованої системи логічна структура повинна бути достатньо
простою для реалізації, але водночас придатною для розширення. Наприклад, у
майбутньому можуть змінюватися розділи робочої програми або правила
перевірки, тому відповідні елементи доцільно відокремити від загального
інтерфейсу і від механізму збереження.
2.3.1. Діаграми класів
Діаграма класів повинна показувати сутності, які зберігають дані, керуючі
класи серверної частини та граничні класи клієнтського інтерфейсу. Така модель
дозволяє простежити шлях даних від форми введення до таблиці бази даних і
сформованого PDF.
Класи на діаграмі поділяються за роллю у системі. Boundary-класи
представляють екрани, форми та панелі інтерфейсу. Control-класи описують
керування сценаріями, зокрема прийняття запитів і виклик сервісів. Entity-класи
відповідають за дані предметної області, які мають зберігатися або передаватися
між рівнями системи [13; 16].
Такий підхід дозволяє уникнути змішування відповідальностей. Наприклад,
форма редагування не повинна напряму виконувати SQL-запити, а сутність
40
ЧДТУ 262261.022 ПЗ
робочої програми не повинна знати про спосіб відображення у браузері. Взаємодія
між цими частинами здійснюється через контролери та сервіси.
Таблиця 2.7
Основні класи логічної структури
Клас або модуль Тип Відповідальність
Надає користувачу робочу область редагування
ProgramEditor boundary
програми та перемикання розділів.
AuthModal boundary Забезпечує реєстрацію та вхід користувача.
TeacherDrawer boundary Дає змогу додати викладача до довідника.
Обробляє HTTP-запити створення, читання,
WorkingProgramController control
оновлення, видалення та експорту PDF.
Обробляє реєстрацію, вхід, отримання поточного
AuthController control
користувача та видалення облікового запису.
Формує дані робочої програми, поєднує шаблон,
WorkingProgramService control
введені дані та дані викладача.
Готує HTML-представлення і запускає
PdfService control
формування PDF-документа.
Містить облікові дані користувача, роль,
User entity
активність і службові дати.
Містить довідкові дані викладача для
Teacher entity
підстановки в робочу програму.
Містить загальні реквізити програми та вкладені
WorkingProgram entity
дані документа у JSONB.
Описує внутрішню структуру розділів робочої
WorkingProgramData entity
програми.
41
ЧДТУ 262261.022 ПЗ
На рисунку 2.4 показано діаграму класів системи без атрибутів. Опис класів
показано в таблиці 2.7. На рисунку 2.4.1 показано діаграму класів з їх атрибутами.
Рисунок 2.4 - Діаграма класів системи без атрибутів
Рисунок 2.4.1 - Діаграма класів системи з атрибутами
42
ЧДТУ 262261.022 ПЗ
2.3.2. Діаграми пакетів
Пакетна структура відображає розподіл програмного комплексу на частини.
Клієнтський пакет містить React-застосунок, API-клієнт і стилі. Серверний пакет
містить маршрути, контролери, сервіси, валідатори, middleware, шаблони PDF та
підключення до бази даних.
Діаграма пакетів узагальнює класову структуру і показує систему на рівні
великих частин. Для веб-застосунку природним є поділ на frontend, backend і
database, оскільки ці частини мають різне призначення, різні технології виконання
та різні типи відповідальності.
Пакети frontend відповідають за взаємодію з користувачем, відображення
форм і виклики API. Пакети backend зосереджують маршрути, контролери, бізнес-
логіку, валідацію та доступ до бази даних. Пакети бази даних відображають групи
збережених даних, пов’язаних з користувачами, викладачами і робочими
програмами.(див. Рисунок 2.5)
Рисунок 2.5 - Діаграма пакетів системи
43
ЧДТУ 262261.022 ПЗ
2.4. Архітектурне проектування
Архітектура системи має клієнт-серверний характер. Користувач працює з
React-інтерфейсом у браузері. Клієнтський застосунок надсилає HTTP-запити до
Express API. Сервер виконує валідацію, бізнес-логіку, звертається до PostgreSQL і
за потреби формує PDF через HTML-шаблон та headless-браузер.
Клієнт-серверна архітектура є доцільною для цієї задачі, оскільки вона
дозволяє користувачу працювати через браузер без встановлення окремого
настільного застосунку. Серверна частина централізує перевірку даних, доступ до
бази та генерацію PDF, що зменшує дублювання логіки на клієнтській стороні [12;
15].
Архітектурно система орієнтована на розділення рівнів: рівень подання,
рівень API, рівень бізнес-логіки, рівень доступу до даних і рівень зберігання.
Кожний рівень виконує свою роль і взаємодіє з іншими через визначені
інтерфейси, що підвищує керованість програмного комплексу.
2.4.1. Діаграма компонентів
Компонентна модель показує основні виконувані частини системи та
залежності між ними. Найбільш важливими компонентами є веб-інтерфейс, API-
клієнт, маршрути Express, контролери, сервіси, валідатори, модуль генерації PDF,
шаблон робочої програми та база даних.
Компонентна діаграма деталізує архітектуру з погляду виконуваних або
логічно самостійних частин. Вона показує, що запит користувача проходить через
веб-інтерфейс та API-клієнт до серверних маршрутів, після чого обробляється
контролерами, сервісами і допоміжними модулями.
Окреме виділення валідаторів і модуля генерації PDF пояснюється тим, що
ці компоненти мають самостійну відповідальність. Валідатори забезпечують
контроль структури вхідних даних, а генератор PDF перетворює збережену робочу
44
ЧДТУ 262261.022 ПЗ
програму на документ, придатний для перегляду, друку або подальшого
погодження [12; 19].(див. Рисунок 2.6, Таблиця 2.8)
Рисунок 2.6 - Діаграма компонентів системи
45
ЧДТУ 262261.022 ПЗ
Таблиця 2.8
Компоненти системи
Компонент Призначення
Відображення списку програм, форм розділів, повідомлень, авторизації та
React UI
керування діями користувача.
Єдина точка виконання HTTP-запитів з клієнтської частини до серверного
API client
API.
Express routes Розподіл запитів між модулями auth, teachers, working-programs і documents.
Controllers Прийняття запитів, виклик сервісів і формування HTTP-відповідей.
Бізнес-логіка авторизації, роботи з викладачами, робочими програмами та
Services
PDF.
Validators Перевірка тіла запиту, параметрів маршруту та структури вкладених даних.
PDF generator Формування PDF-документа з HTML-шаблону та CSS-стилів.
PostgreSQL
Постійне збереження користувачів, викладачів і робочих програм.
database
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання.
Діаграма розгортання відображає фізичне розміщення частин системи.
Клієнтська частина виконується у браузері користувача. Серверна частина працює
в середовищі Node.js. База даних розміщується в PostgreSQL. Формування PDF
виконується на сервері за допомогою headless-браузера, що забезпечує однаковий
результат незалежно від робочого місця користувача.
Розгортання показує, у яких середовищах виконуються частини системи.
Користувач взаємодіє з системою на робочій станції через веб-браузер. Сервер
46
ЧДТУ 262261.022 ПЗ
застосунку виконує frontend-ресурси, API, валідацію, доступ до даних і генерацію
PDF. Сервер бази даних забезпечує зберігання структурованої інформації.
Виділення окремого сервера бази даних є логічним навіть тоді, коли на етапі
навчального прототипу всі частини можуть виконуватися на одному комп’ютері.
Така модель відображає цільову архітектуру і показує, що рівень зберігання даних
має бути ізольований від клієнтського середовища та доступний лише через
серверну частину [12; 17].(див. Рисунок 2.7)
Рисунок 2.7 - Діаграма розгортання системи
2.5. Моделювання поведінки системи
Поведінкові діаграми описують послідовність дій у типових сценаріях
роботи з системою. Для проектованої системи ключовим є сценарій створення
робочої програми, її збереження та формування PDF-документа.
Якщо структурні діаграми відповідають на питання, з яких частин
складається система, то поведінкові діаграми показують, як ці частини
взаємодіють у часі. Для системи формування робочих програм важливо описати
не лише зберігання даних, а й послідовність дій користувача, повторну перевірку,
формування документа та повернення результату.
47
ЧДТУ 262261.022 ПЗ
Поведінкове моделювання дає змогу перевірити повноту проекту: кожна дія
користувача повинна мати реакцію системи, а кожний важливий стан робочої
програми - зрозумілу умову переходу. Це зменшує ризик пропуску проміжних
сценаріїв під час реалізації [13; 16].
2.5.1. Діаграма діяльності
Діаграма діяльності відображає загальний алгоритм створення робочої
програми. Процес починається з авторизації користувача, завантаження списку
програм, створення або відкриття запису, заповнення розділів, перевірки даних,
збереження та відкриття сформованого PDF.(див. Рисунок 2.8)
Рисунок 2.8 - Діаграма діяльності процесу створення робочої програми
48
ЧДТУ 262261.022 ПЗ
Процес створення робочої програми має ітераційний характер. Користувач
може неодноразово змінювати розділи, повертатися до попередніх даних,
виправляти помилки та повторно запускати збереження. Саме тому на діаграмі
діяльності доцільно показувати перевірку даних і повернення до редагування у
разі виявлення некоректних або неповних полів.
Діаграма діяльності також демонструє розподіл відповідальності між
користувачем і системою. Користувач виконує дії з даними у web-інтерфейсі, а
система забезпечує технічні операції: завантаження шаблону, перевірку,
збереження, генерацію PDF і повідомлення про результат.
2.5.2. Діаграма послідовності
Діаграма послідовності відображає порядок взаємодії основних частин
системи під час формування PDF-документа робочої програми. Користувач
ініціює формування PDF через веб-інтерфейс, після чого запит передається на
API-сервер. Сервер отримує дані робочої програми з бази даних, передає їх до
модуля генерації PDF та повертає сформований документ користувачу для
перегляду або завантаження [13; 16].(див. Рисунок 2.9)
Рисунок 2.9 - Діаграма послідовності процесу формування PDF робочої програми
49
ЧДТУ 262261.022 ПЗ
2.5.3. Діаграма комунікації
Діаграма комунікації показує ті самі об’єкти, що і діаграма послідовності,
але акцентує увагу на зв’язках між ними. Для системи доцільно показати
взаємодію клієнта, API, сервісів, бази даних і генератора PDF під час збереження
та експорту робочої програми.(див. Рисунок 2.10)
На відміну від діаграми послідовності, діаграма комунікації більше акцентує
увагу на зв’язках між об’єктами та нумерації повідомлень. Для процесу
збереження та експорту це зручно, оскільки в одному сценарії поєднуються
перевірка введених даних, запис до бази даних і формування PDF-документа.
Нумерація повідомлень задає порядок виконання операцій: спочатку дані
надходять від користувача до API-сервера, потім перевіряються, після успішної
перевірки зберігаються, а вже після цього можуть бути передані до модуля
генерації PDF. Такий порядок запобігає формуванню документа на основі
неповних або некоректних даних.
Рисунок 2.10 - Діаграма комунікації процесу збереження та експорту робочої
програми
50
ЧДТУ 262261.022 ПЗ
2.5.4. Діаграма скінченного автомату
Діаграма скінченного автомату відображає життєвий цикл робочої програми
з погляду користувацьких дій. Стан програми визначається не окремою колонкою
статусу в базі даних, а результатом створення чернетки, перевірки, збереження,
редагування, формування PDF або видалення.(див. Рисунок 2.11)
Рисунок 2.11 - Діаграма скінченного автомату станів робочої програми
51
ЧДТУ 262261.022 ПЗ
Станова модель потрібна для опису життєвого циклу робочої програми.
Один і той самий документ може перебувати у стані чернетки, очікувати
перевірки, містити помилки валідації, бути збереженим, експортованим у PDF або
видаленим. Кожний стан визначається результатом попередньої дії та умовами
переходу до наступного стану.
Наявність циклу між перевіркою, помилкою валідації та редагуванням є
нормальною для такої системи. Він означає, що користувач може виправити
некоректні дані й повторити збереження, доки робоча програма не відповідатиме
встановленій структурі. Це робить модель ближчою до реального процесу роботи
з великим документом.
Таблиця 2.9
Стани робочої програми
Стан Умова переходу до стану
Користувач створив нову програму на основі шаблону, але ще не
Чернетка
зберіг її в базі даних.
Користувач натиснув збереження, система перевіряє обов’язкові та
Очікує перевірки
форматні поля.
Помилка валідації Виявлено порожні або некоректні поля, збереження не виконується.
Збережена Дані успішно записано до таблиці working_programs.
Редагується Користувач відкрив збережену програму та змінив її дані.
Система отримала збережену програму, згенерувала PDF і
PDF сформовано
повернула документ користувачу.
Видалена Користувач підтвердив видалення, запис вилучено з бази даних.
52
ЧДТУ 262261.022 ПЗ
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ
У другому розділі виконано проектування інформаційної системи
формування робочих програм навчальних дисциплін. Визначено основні поняття
предметної області, сформовано словник термінів і встановлено межі системи, до
яких належать клієнтський інтерфейс, серверний API, модуль роботи з даними,
модуль генерації PDF та база даних.
Отримані проектні моделі формують основу для подальшої реалізації
програмного забезпечення. Вони визначають не лише склад майбутніх модулів, а
й порядок їх взаємодії, межі відповідальності та вимоги до збереження даних.
Завдяки цьому розроблення може виконуватися послідовно: від інтерфейсу
користувача до серверної логіки, бази даних і механізму формування PDF.
Сформовано первинні та детальні вимоги до програмного забезпечення, а
також визначено функціональні й нефункціональні вимоги. На основі вимог
описано варіанти використання системи, що відображають основні дії
користувача: авторизацію, створення, редагування, збереження, видалення та
експорт робочої програми.
Побудована проектна структура передбачає поділ системи на клієнтську
частину, серверні маршрути, контролери, сервіси, валідатори, шаблони документа
і базу даних. Такий поділ забезпечує логічне розмежування відповідальностей та
створює основу для подальшого опису реалізації й тестування програмного
забезпечення.
53
ЧДТУ 262261.022 ПЗ
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
Третій розділ присвячено реалізації програмного комплексу формування
робочих програм навчальних дисциплін Черкаського державного технологічного
університету та перевірці його працездатності. У розділі розглянуто вибір засобів
реалізації, структуру клієнтської та серверної частин, організацію бази даних,
побудову користувацького інтерфейсу, склад програмних компонентів і
результати тестування.
Розроблений програмний комплекс реалізує клієнт-серверну модель.
Користувач працює з веб-інтерфейсом, серверна частина приймає запити,
перевіряє дані, виконує операції з базою даних та формує PDF-документ робочої
програми. Такий підхід відповідає проектним рішенням, визначеним у другому
розділі, і забезпечує логічне розділення рівня подання, бізнес-логіки та
збереження даних.
3.1. Розробка програмного комплексу
Розробка програмного комплексу виконувалася з урахуванням вимог до
зручного введення великої кількості предметних даних, повторного редагування,
збереження структурованої інформації та формування кінцевого PDF-документа.
Система повинна підтримувати роботу з типовими розділами робочої програми,
довідником викладачів, авторизацією користувача та експортом результату.
Основною ідеєю реалізації є збереження робочої програми не як статичного
файлу, а як структурованого запису, який можна багаторазово відкривати,
редагувати та перетворювати у документ. Завдяки цьому система не обмежується
одноразовим створенням PDF, а підтримує повний цикл роботи з навчальною
програмою.
54
ЧДТУ 262261.022 ПЗ
3.1.1. Обґрунтування вибору засобів реалізації
Для реалізації клієнтської частини обрано React, оскільки він дає змогу
будувати інтерфейс із незалежних компонентів, використовувати локальний стан і
повторно застосовувати елементи форм [20]. Для запуску та збірки frontend-
частини використано Vite, який забезпечує швидку розробку, роботу з ES-
модулями та формування production-збірки [21].
Серверна частина реалізована на Node.js та Express. Node.js
використовується як середовище виконання JavaScript на сервері, а Express
забезпечує маршрутизацію HTTP-запитів, підключення middleware та формування
відповідей API [22; 18]. Для збереження даних обрано PostgreSQL, оскільки ця
СКБД підтримує реляційну модель, індекси та тип JSONB, що є зручним для
збереження вкладеної структури робочої програми [17].
Перевірка вхідних даних реалізована за допомогою Joi, що дозволяє
описувати схеми запитів у зрозумілому вигляді [23]. Для авторизації застосовано
JWT-токени та хешування паролів за допомогою bcrypt [24; 25]. Формування PDF-
документа виконується на основі HTML-шаблону Handlebars і headless-браузера
Puppeteer [19; 26].
Таблиця 3.1
Засоби реалізації програмного комплексу
Засіб Призначення Обґрунтування вибору
Зменшує технологічну різнорідність
Єдина мова для клієнтської та
JavaScript системи та спрощує обмін JSON-
серверної частин
даними.
Дозволяє створювати редактор із
Побудова користувацького
React повторно використовуваних
інтерфейсу
компонентів форм.
55
ЧДТУ 262261.022 ПЗ
Продовження таблиці 3.1
Забезпечує швидкий запуск,
Vite Розробка та збірка frontend оновлення під час розробки та
production-збірку.
Середовище виконання Підходить для побудови API, що
Node.js
серверної частини обробляє JSON-запити.
Дає просту структуру для auth,
Express Маршрутизація та middleware teachers, documents і working-
programs маршрутів.
Підтримує реляційні таблиці та
PostgreSQL Збереження даних JSONB для великої структури
робочої програми.
Дає змогу формально описати
Joi Валідація запитів
допустиму структуру body та params.
Handlebars і HTML-шаблон перетворюється у
Генерація PDF
Puppeteer друкований PDF формату A4.
3.1.2. Опис структурної (функціональної) схеми
Структурна схема реалізованої системи відображає основні частини
програмного комплексу та напрям передавання даних між ними. Користувач
працює у браузері з React-інтерфейсом. API-клієнт виконує HTTP-запити до
серверної частини, де Express передає запит на відповідний маршрут, контролер
викликає сервіс, а сервіс виконує бізнес-логіку та звертається до PostgreSQL. (див.
Рисунок 3.1)
Окремим функціональним напрямом є формування PDF. Після збереження
або відкриття робочої програми користувач може ініціювати експорт. Сервер
отримує запис робочої програми, будує HTML-представлення на основі
56
ЧДТУ 262261.022 ПЗ
Handlebars-шаблону, після чого Puppeteer формує PDF-файл і повертає його у
браузер.
Рисунок 3.1 - Структурна схема реалізованої системи
Функціонально система підтримує кілька основних потоків: авторизацію,
завантаження початкових даних, створення та редагування робочої програми,
збереження, роботу з довідником викладачів і формування PDF. Кожний потік
проходить через API-сервер, що забезпечує єдину точку контролю даних.
57
ЧДТУ 262261.022 ПЗ
Таблиця 3.2
Основні функціональні потоки системи
Потік Вхідні дані Результат
Створений або підтверджений
Авторизація ПІБ, email ЧДТУ, пароль
обліковий запис, JWT-токен.
Назва документа, дисципліна, Новий запис робочої програми
Створення програми
навчальний рік, спеціальність на основі типового шаблону.
Оновлений JSONB-об'єкт у
Редагування розділів Структуровані дані форми
складі робочої програми.
Запис у довіднику викладачів,
ПІБ, науковий ступінь, посада,
Додавання викладача який може бути використаний
email
у програмі.
PDF-документ для перегляду
Формування PDF Ідентифікатор робочої програми
або завантаження.
3.1.3. Опис логічної схеми системи
Логіка роботи системи побудована навколо об'єкта робочої програми. Під
час створення нового запису frontend отримує типовий шаблон, заповнює його
початковими значеннями і передає на сервер разом із загальними реквізитами.
Сервер перевіряє обов'язкові поля, формує повну структуру даних і зберігає її у
таблиці working_programs. (див. Рисунок 3.2)
Під час редагування користувач працює з окремими розділами, однак на
рівні збереження вони перетворюються в один структурований об'єкт data. Для
оновлення вкладених полів застосовується об'єднання наявних даних із новими
значеннями. Це дає змогу змінювати окремі частини робочої програми без втрати
сусідніх розділів.
58
ЧДТУ 262261.022 ПЗ
Рисунок 3.2 - Логічна схема створення та експорту робочої програми
У разі некоректних даних логіка системи повертає користувача до етапу
редагування. Такий цикл є важливим для роботи з великим документом, оскільки
користувач може неодноразово уточнювати реквізити, години, результати
навчання, критерії оцінювання та список літератури перед остаточним
збереженням або експортом.
3.1.4. Розробка бази даних
База даних реалізована в PostgreSQL і складається з таблиць teachers, users,
documents та working_programs. Основною таблицею для дипломного проєкту є
working_programs, у якій зберігаються загальні реквізити програми та поле data
типу JSONB. Таке рішення поєднує переваги реляційної моделі та гнучкість
вкладених структур.
59
ЧДТУ 262261.022 ПЗ
Загальні поля, такі як назва дисципліни, навчальний рік, код спеціальності та
освітній рівень, винесені в окремі колонки, оскільки вони потрібні для списку,
пошуку та фільтрації. Повний зміст документа зберігається у data JSONB, тому
може містити титульні дані, погодження, опис дисципліни, тематичний план,
лабораторні роботи, самостійну роботу, оцінювання, питання, літературу та
інформаційні ресурси.
Рисунок 3.3 - Фізична модель бази даних системи
60
ЧДТУ 262261.022 ПЗ
Для прискорення пошуку в таблиці working_programs передбачено індекси
за навчальним роком, назвою дисципліни та кодом спеціальності. У таблиці users
додатково використовується унікальний індекс за email у нижньому регістрі, що
запобігає дублюванню облікових записів.
3.1.5. Розробка інтерфейсу користувача
Користувацький інтерфейс реалізовано як односторінковий веб-застосунок.
Основний екран містить список робочих програм, пошук, область редагування та
панель дій. Такий підхід дозволяє користувачу швидко перемикатися між
створеними програмами, відкривати потрібний запис і послідовно заповнювати
його розділи. (див. Рисунок 3.4)
Редактор поділено на тематичні розділи: загальні реквізити, титул,
погодження, викладач, опис дисципліни, мета і результати, програма, тематичний
план, лабораторні роботи, самостійна робота, оцінювання, питання та ресурси.
Поділ великого документа на розділи зменшує перевантаження інтерфейсу і
робить заповнення більш керованим.
Рисунок 3.4 - Структура користувацького інтерфейсу
61
ЧДТУ 262261.022 ПЗ
Для наочного підтвердження реалізації інтерфейсу доцільно додати
скріншоти основних екранів системи. Вони мають показувати не лише зовнішній
вигляд застосунку, а й практичну відповідність інтерфейсу розділам робочої
програми. На рисунках 3.5-3.9 показані основні етапи.
Рисунок 3.5 - Головний екран системи формування робочих програм
Рисунок 3.6 - Форма авторизації користувача системи
62
ЧДТУ 262261.022 ПЗ
Рисунок 3.7 - Редактор розділів робочої програми
Рисунок 3.8 - Вікно додавання викладача до довідника
63
ЧДТУ 262261.022 ПЗ
Рисунок 3.9 - Перегляд сформованого PDF-документа робочої програми
Таблиця 3.4
Основні розділи інтерфейсу
Розділ Призначення
Введення назви документа, дисципліни, навчального року, спеціальності
Загальне
та освітнього рівня.
Титул Заповнення даних титульної сторінки робочої програми.
Погодження Внесення протоколів, відповідальних осіб і даних погодження.
Викладач Вибір викладача з довідника або додавання нового запису.
64
ЧДТУ 262261.022 ПЗ
Продовження таблиці 3.4
Введення кредитів, годин, семестрів, мови викладання та форми
Опис
контролю.
Мета і
Формування предмета, мети, завдань та результатів навчання.
результати
Програма і
Опис змістових модулів, тем і розподілу навчального часу.
план
Оцінювання
Внесення шкали, критеріїв, питань, літератури та інформаційних ресурсів.
і ресурси
У frontend-частині реалізовано клієнтську перевірку даних. Перевіряються
формат навчального року, коректність email, числові значення годин і балів, а
також наявність обов'язкових полів. Якщо виявлено помилки, система не надсилає
дані на збереження і показує користувачу повідомлення з переліком проблем.
3.1.6. Опис розробки програмних компонентів
Програмні компоненти реалізовано з урахуванням розподілу
відповідальності між клієнтською та серверною частинами. На клієнті головним
компонентом є App, який зберігає стан редактора, список програм, список
викладачів, активний розділ, стан авторизації та повідомлення. Окремі
компоненти відповідають за авторизацію, додавання викладача, рендеринг
розділів і динамічні списки.
На сервері застосовано поділ на маршрути, контролери, сервіси, валідатори
та допоміжні модулі. Маршрути описують доступні HTTP-адреси, контролери
приймають запити та формують відповіді, сервіси виконують бізнес-логіку і SQL-
запити, валідатори перевіряють структуру даних, а middleware забезпечує обробку
помилок та авторизацію.
65
ЧДТУ 262261.022 ПЗ
Рисунки 3.10-12 показують фрагменти, що стосуються реалізації самої
системи. На них можна побачити вище згадані методи та інструменти, що були
використані під час програмування наявної web-системи.
Рисунок 3.10 - Фрагмент реалізації API-клієнта
Рисунок 3.11 - Фрагмент реалізації маршруту та контролера робочих програм
66
ЧДТУ 262261.022 ПЗ
Рисунок 3.12 - Фрагмент реалізації сервісу генерації PDF
Таблиця 3.5
Основні програмні компоненти
Компонент Рівень Відповідальність
Керує станом застосунку, відкритою програмою,
App.jsx Frontend
авторизацією, списками і діями користувача.
Містить Axios-клієнт і методи звернення до auth,
api.js Frontend
teachers та working-programs API.
Відображає активний розділ редактора залежно
SectionRenderer Frontend
від вибору користувача.
67
ЧДТУ 262261.022 ПЗ
Продовження таблиці 3.5
AuthModal Frontend Забезпечує реєстрацію та вхід користувача.
Використовується для додавання викладача без
TeacherDrawer Frontend
виходу з редактора програми.
Підключає JSON-обробку, маршрути та
app.js Backend
middleware помилок.
workingProgramCo Обробляє створення, читання, оновлення,
Backend
ntroller видалення і експорт PDF.
workingProgramSer Формує структуру data JSONB, виконує SQL-
Backend
vice запити та оновлення програми.
pdfService Backend Рендерить HTML-шаблон і формує PDF-документ.
Перевіряють auth-запити, параметри id і структуру
validators Backend
робочої програми.
db.js Backend Створює єдиний pool підключень до PostgreSQL.
Для обробки помилок використано клас AppError, який дає змогу передавати
HTTP-статус і деталі помилки. Центральний errorHandler повертає клієнту
уніфіковану JSON-відповідь, що спрощує показ повідомлень у frontend-частині.
3.2. Тестування системи
Тестування програмного комплексу спрямоване на перевірку коректності
окремих модулів, взаємодії між частинами системи, виконання основних
користувацьких сценаріїв і відповідності системи вимогам. Для перевірки
використано модульне, інтеграційне, системне та приймальне тестування.
Технічна перевірка показала, що production-збірка клієнтської частини
засобами Vite виконується успішно. Також виконано синтаксичну перевірку
68
ЧДТУ 262261.022 ПЗ
серверних JavaScript-файлів командою node --check, що підтвердило відсутність
синтаксичних помилок у backend-модулях.
3.2.1. Модульне тестування
Модульне тестування охоплює окремі функції та модулі, які мають
самостійну відповідальність. Для даної системи найбільш важливими є перевірка
форматів даних, формування payload для збереження, валідація запитів, робота з
вкладеними полями та підготовка даних для PDF.
Таблиця 3.6
Результати модульного тестування
Модуль Очікуваний результат Отриманий результат
Приймає формат YYYY-
Формат навчального року
validateAcademicYear YYYY і відхиляє некоректні
перевіряється коректно.
роки.
Некоректні адреси
Дозволяє email лише з відхиляються,
validateChdtuEmail
доменом @chdtu.edu.ua. корпоративний домен
приймається.
Перевіряє число або
Некоректні діапазони не
validateScoreRange діапазон балів у межах 0-
проходять перевірку.
100.
Payload містить загальні
Формує об'єкт для
buildPayload поля та data робочої
create/update запиту.
програми.
Схема обмежує верхній
Приймає дозволені розділи
workingProgramDataSchema рівень структури робочої
data та відхиляє зайві поля.
програми.
69
ЧДТУ 262261.022 ПЗ
Продовження таблиці 3.6
Перетворює дані програми у HTML формується на основі
renderWorkingProgramHtml
HTML. шаблону та стилів.
3.2.2. Інтеграційне тестування
Інтеграційне тестування перевіряє взаємодію кількох компонентів у межах
одного сценарію. Основну увагу приділено передачі даних між frontend і backend,
роботі контролерів із сервісами, збереженню у PostgreSQL та генерації PDF.
Таблиця 3.7
Результати інтеграційного тестування
Сценарій Очікуваний результат Отриманий результат
React UI - API client - Дані форми передаються на API-клієнт формує запити
Express сервер у JSON-форматі. до відповідних маршрутів.
Route - validator - Некоректні дані зупиняються Joi-валидація повертає
controller до виконання бізнес-логіки. помилки з деталями полів.
Після успішної перевірки дані Сервіс виконує INSERT
Controller - service -
зберігаються в таблиці /UPDATE/SELECT/DELETE
PostgreSQL
working_programs. запити.
Teacher service - working Вибраний викладач додається Дані викладача потрапляють
program до snapshot робочої програми. у teacherInfo.primaryTeacher.
PDF-сервіс повертає Buffer,
PDF service - template - HTML-шаблон перетворюється
який надсилається як
browser у PDF формату A4.
application/pdf.
70
ЧДТУ 262261.022 ПЗ
3.2.3. Системне тестування
Системне тестування розглядає програмний комплекс як єдину систему.
Перевірялися сценарії, які відображають реальну роботу користувача: авторизація,
створення програми, редагування розділів, збереження, пошук, експорт PDF і
видалення запису.
Таблиця 3.8
Результати системного тестування
Функціональність Очікуваний результат Результат
Користувач із поштою
Сценарій підтримано через
Реєстрація користувача ЧДТУ отримує доступ до
auth/register.
системи.
Після введення email і
Сценарій підтримано через
Вхід у систему пароля користувач отримує
auth/login.
токен.
Нова програма створюється Створення виконується через
Створення програми
на основі шаблону. POST /working-programs.
Дані змінюються без втрати Вкладені поля оновлюються
Редагування розділів
інших частин документа. через data JSONB.
Збереження виконується після
Коректні дані записуються
Збереження клієнтської та серверної
до бази даних.
перевірки.
Користувач отримує PDF- Експорт виконується через
Формування PDF
документ робочої програми. GET/working-programs/:id/pdf.
Запис програми Видалення виконується через
Видалення
видаляється зі списку. DELETE /working-programs/:id.
71
ЧДТУ 262261.022 ПЗ
3.2.4. Приймальне тестування
Приймальне тестування визначає, чи відповідає система початковим
вимогам. Для оцінювання використано критерії, пов'язані з основними задачами
дипломного проєкту: підтримка структури робочої програми, збереження даних,
робота з викладачами, безпечна авторизація та формування PDF.
Таблиця 3.9
Результати приймального тестування
Критерій Умова приймання Стан
Система дозволяє роботу користувачів із
Авторизація Виконано.
корпоративною поштою ЧДТУ.
Підтримано основні розділи робочої програми
Структура програми Виконано.
навчальної дисципліни.
Збереження Дані робочої програми зберігаються у PostgreSQL. Виконано.
Користувач може повторно відкривати та змінювати
Редагування Виконано.
запис.
Система повідомляє про некоректні або неповні
Валідація Виконано.
поля.
Сформований документ відкривається у браузері або
PDF Виконано.
завантажується.
Архітектура поділена на frontend, backend, сервіси та
Супровід Виконано.
базу даних.
3.3. Приклади впровадженого програмного комплексу
Впровадження програмного комплексу передбачає підготовку серверного
середовища, бази даних, залежностей клієнтської та серверної частин, а також
72
ЧДТУ 262261.022 ПЗ
налаштування змінних середовища. Система може працювати локально під час
розробки або бути розгорнута на сервері застосунку з окремим сервером
PostgreSQL.
Після розгортання користувач відкриває веб-застосунок у браузері,
проходить авторизацію, створює нову робочу програму або відкриває наявну,
заповнює розділи, зберігає результат і формує PDF. Такий сценарій демонструє
роботу програмного комплексу у прикладній області та перевіряє взаємодію
інтерфейсу, API, бази даних і модуля генерації PDF.
Для розгортання системи системи потрібні Node.js, npm і PostgreSQL.
Серверна частина використовує змінні середовища для підключення до бази даних
і налаштування JWT-секрету. Після встановлення залежностей створюється
структура таблиць за SQL-схемою, запускається backend API, а frontend-
застосунок збирається або запускається у режимі розробки.
Таблиця 3.10
Основні параметри розгортання
Параметр Призначення
DB_USER Ім'я користувача PostgreSQL.
DB_PASSWORD Пароль користувача бази даних.
DB_HOST Адреса сервера PostgreSQL.
DB_PORT Порт підключення до PostgreSQL.
DB_NAME Назва бази даних системи.
JWT_SECRET Секретний ключ для підпису JWT-токенів.
VITE_API_URL Адреса backend API для frontend-застосунку.
73
ЧДТУ 262261.022 ПЗ
Контрольний сценарій впровадження складається з кількох послідовних дій:
створення бази даних, виконання SQL-схеми, встановлення залежностей backend і
frontend, запуск серверної частини, перевірка доступності API, запуск клієнтської
частини, створення тестової робочої програми та формування PDF-документа.
Для production-використання доцільно розміщувати frontend як статичні
файли, а backend запускати як окремий серверний процес. База даних повинна
бути доступною лише серверній частині.
Під час підготовки програмного комплексу до практичного використання
важливо враховувати не лише запуск окремих частин, а й контроль їх узгодженої
роботи. Після старту серверної частини перевіряється доступність основних
маршрутів API, правильність підключення до PostgreSQL, наявність необхідних
змінних середовища та коректність відповіді модуля генерації PDF. Такий порядок
дозволяє швидко виявити помилки конфігурації ще до початку роботи
користувача із системою.
Окрему увагу доцільно приділяти супроводу програмного забезпечення. У
разі зміни структури робочої програми достатньо оновити відповідні JSONB-
блоки, серверні схеми перевірки та HTML-шаблон документа, не змінюючи
загальну архітектуру застосунку. Завдяки цьому система залишається придатною
до розвитку: нові поля, розділи, ролі користувачів або варіанти експорту можуть
додаватися поступово, без повного переписування клієнтської та серверної частин.
З погляду експлуатації важливо, що frontend, backend і база даних мають
чітко розділені зони відповідальності. Клієнтська частина відповідає за зручне
введення й відображення даних, API-сервер виконує перевірку та обробку запитів,
а база даних забезпечує довготривале збереження інформації. Такий підхід
спрощує діагностику помилок, тестування окремих компонентів і подальше
масштабування програмного комплексу.
74
ЧДТУ 262261.022 ПЗ
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ
У третьому розділі описано реалізацію web-орієнтованого програмного
комплексу формування робочих програм. Обґрунтовано вибір React, Vite, Node.js,
Express, PostgreSQL, Joi, Handlebars і Puppeteer як основних засобів розробки.
Розглянуто структурну та логічну схеми роботи системи, фізичну модель бази
даних, структуру користувацького інтерфейсу та склад програмних компонентів.
Реалізована система підтримує авторизацію користувача, створення і
редагування робочих програм, роботу з довідником викладачів, перевірку
введених даних, збереження структурованого JSONB-об'єкта та формування PDF-
документа. Поділ на клієнтську частину, API, контролери, сервіси, валідатори,
шаблони та базу даних забезпечує підтримуваність і можливість подальшого
розвитку системи.
Проведене тестування охопило модульні, інтеграційні, системні та
приймальні перевірки. Результати підтвердили, що програмний комплекс
відповідає основним функціональним вимогам, коректно обробляє ключові
сценарії роботи та може використовуватися як приклад прикладного програмного
забезпечення для автоматизації структурованого введення, перевірки, збереження
й експорту даних.
75
ЧДТУ 262261.022 ПЗ
ВИСНОВКИ
У кваліфікаційній роботі розглянуто задачу проектування та розробки web-
орієнтованого програмного комплексу для формування робочих програм кафедри
ПЗАС ЧДТУ. На основі аналізу предметної області встановлено вимоги до
системи, яка повинна підтримувати структуроване введення даних, перевірку
обов’язкових і форматних полів, повторне використання інформації, збереження у
базі даних та генерацію PDF.
У першому розділі визначено технічні передумови розробки, розглянуто
наявні методи та програмні засоби часткового вирішення задачі, а також
проаналізовано спеціалізовані аналоги. За результатами аналізу обґрунтовано
потребу у легшому спеціалізованому web-застосунку, орієнтованому на конкретну
модель даних і набір користувацьких сценаріїв.
У другому розділі виконано проектування програмного комплексу.
Сформовано модель предметної області як основу вимог до ПЗ, словник термінів,
функціональні та нефункціональні вимоги, діаграми варіантів використання,
класів, пакетів, компонентів, розгортання, діяльності, послідовності, комунікації
та станів. Побудовані моделі визначили межі системи, основні модулі,
відповідальність компонентів і порядок взаємодії між користувацьким
інтерфейсом, API-сервером, модулями перевірки, збереження та генерації PDF.
У третьому розділі описано реалізацію web-орієнтованої системи. Для
клієнтської частини використано React і Vite, для серверної частини - Node.js та
Express, для збереження даних - PostgreSQL, для перевірки вхідних даних - Joi, для
авторизації - JWT і bcrypt, для формування PDF-документа - Handlebars та
Puppeteer. Такий набір засобів забезпечує розподіл відповідальностей між
інтерфейсом, серверною логікою, базою даних і модулем генерації документа.
Реалізована система підтримує основні сценарії роботи користувача:
реєстрацію та вхід, створення робочої програми, редагування її розділів,
збереження даних, роботу з викладачами, перевірку введеної інформації та
76
ЧДТУ 262261.022 ПЗ
експорт результату у PDF. Застосування структурованого збереження даних дає
змогу працювати з робочою програмою як з інформаційним об’єктом, а не лише
як з текстовим файлом.
Тестування охопило модульні, інтеграційні, системні та приймальні
перевірки. Особлива увага приділялася правильності обробки API-запитів,
коректності валідації, збереженню структурованих даних, стабільності генерації
PDF і придатності інтерфейсу до виконання типових дій. Результати перевірок
підтвердили працездатність основних функцій і відповідність реалізації
сформованим вимогам.
Важливим результатом роботи є те, що реалізований програмний комплекс
не обмежується створенням окремого електронного документа, а формує
повноцінну модель обробки даних: введення, перевірка, збереження, повторне
використання і експорт. Саме така послідовність відповідає задачам інженерії
програмного забезпечення, оскільки акцент зроблено на архітектурі системи,
структурі даних, взаємодії компонентів і контрольованій поведінці програмного
продукту.
Розроблена система може бути використана як базова версія для подальшого
вдосконалення. До можливих напрямів розвитку належать журналювання змін,
розширення ролей користувачів, додавання механізмів погодження, підтримка
кількох шаблонів експорту, покращення адміністративної частини та інтеграція з
іншими інформаційними ресурсами. При цьому вже реалізована структура
frontend, backend і database дозволяє виконувати такі зміни поетапно.
Отже, мету роботи досягнуто: виконано аналіз вимог, спроектовано
архітектуру і моделі системи, реалізовано програмний комплекс та проведено його
тестування. Подальший розвиток системи може передбачати розширення ролей,
підтримку історії змін, додавання статусів, інтеграцію з університетськими
інформаційними ресурсами та підтримку кількох варіантів шаблонів експорту.
77
ЧДТУ 262261.022 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Методичні рекомендації до підготовки кваліфікаційної роботи бакалавра
для здобувачів вищої освіти зі спеціальності 121 «Інженерія програмного
забезпечення» усіх форм навчання. Черкаси: ЧДТУ, 2023. 96 с.
2 Save a Word document as a template. Microsoft Support. URL:
https://support.microsoft.com/en-gb/office/save-a-word-document-as-a-
template-cb17846d-ecec-49d4-82ea-a6f5e3e8b9ae
3 Track changes in Word. Microsoft Support. URL: https://
support.microsoft.com/en-gb/office/track-changes-in-word-197ba630-
0f5f-4a8e-9a77-3712475e806a
4 View & manage form responses. Google Docs Editors Help. URL:
https://support.google.com/docs/answer/139706?hl=en-en
5 Require approval of documents in SharePoint using Power Automate.
Microsoft Learn. URL: https://learn.microsoft.com/en-us/sharepoint/
dev/business-apps/power-automate/guidance/require-doc-approval
6 Course formats. MoodleDocs. URL: https://docs.moodle.org/en/
Course_formats
7 Syllabus Management System. Simple Syllabus. URL:
https://simplesyllabus.com/
8 Curriculum Management. CourseLeaf CIM. URL: https://
www .courseleaf .com/ software/cim/
9 The Intelligent Academic Operations Platform. Coursedog. URL:
https://www.coursedog.com/products/platform
10 OWASP Top 10:2021. OWASP Foundation. URL: https://owasp.org/Top10/
11 ISO/IEC/IEEE 29148:2018. Systems and software engineering - Life cycle
processes - Requirements engineering. Geneva: ISO, 2018.
12 ISO/IEC/IEEE 42010:2022. Software, systems and enterprise - Architecture
description. Geneva: ISO, 2022.
78
ЧДТУ 262261.022 ПЗ
13 Object Management Group. Unified Modeling Language, Version 2.5.1.
OMG, 2017.
14 Sommerville I. Software Engineering. 10th ed. Boston: Pearson, 2016. 816 p.
15 Pressman R. S., Maxim B. R. Software Engineering: A Practitioner’s
Approach. 9th ed. New York: McGraw-Hill Education, 2019. 672 p.
16 Fowler M. UML Distilled: A Brief Guide to the Standard Object Modeling
Language. 3rd ed. Boston: Addison-Wesley, 2003. 208 p.
17 PostgreSQL Global Development Group. PostgreSQL Documentation. URL:
https://www.postgresql.org/docs/ (дата звернення: 15.05.2026)
18 Express.js. Express - Node.js web application framework. URL:
https://expressjs.com/ (дата звернення: 15.05.2026)
19 Puppeteer. Puppeteer Documentation. URL: https://pptr.dev/ (дата звернення:
15.05.2026)
20 React Documentation. URL: https://react.dev/reference/react (дата звернення:
15.05.2026)
21 Vite Documentation. Getting Started. URL: https://vite.dev/guide/ (дата
звернення: 15.05.2026)
22 Node.js Documentation. URL: https://nodejs.org/api/ (дата звернення:
15.05.2026)
23 Joi API Documentation. URL: https://joi.dev/api/18.x.x (дата звернення:
15.05.2026)
24 Jones M., Bradley J., Sakimura N. JSON Web Token (JWT). RFC 7519. URL:
https://www.rfc-editor.org/rfc/rfc7519 (дата звернення: 15.05.2026)
25 bcrypt - npm package. URL: https://www.npmjs.com/package/bcrypt (дата
звернення: 15.05.2026)
26 Handlebars Documentation. URL: https://handlebarsjs.com/guide/ (дата
звернення: 15.05.2026)
79
ЧДТУ 262261.022 ПЗ
27 Axios Documentation. URL: https://axios-http.com/ (дата звернення:
15.05.2026)
80
ДОДАТОК А
«Web-система формування робочих програм кафедри ПЗАС ЧДТУ»
Специфікація
482 ЧДТУ 262261.022
Листів 2
Розробник ________________ Сергієнко Н. С.
Керівник ________________ Салапатов В.І.
Черкаси 2026
482 ЧДТУ 262261.022 2
Позначення Найменування Примітка
Документація
482 ЧДТУ 262261 12.01 Текст програми
482 ЧДТУ 262261 34.01 Інструкція користувачеві
482 ЧДТУ 262261 90.01 Презентація
82
ДОДАТОК Б
«Web-система формування робочих програм кафедри ПЗАС ЧДТУ»
Текст програми
482 ЧДТУ 262261 12 01
Розробник ________________ Сергієнко Н. С.
Черкаси 2026
482 ЧДТУ 262261 12.01 2
Основні фрагменти програмного коду
У додатку наведено ключові файли програмної реалізації: клієнтський
застосунок, API, сервіси, валідатори, схему бази даних і шаблон формування PDF.
Файл package.json
1 {
2 "name": "dyplom2026",
3 "version": "1.0.0",
4 "private": true,
5 "description": "Web system for generating ChDTU working programs",
6 "scripts": {
7 "dev:backend": "npm --prefix backend run dev",
8 "start:backend": "npm --prefix backend start",
9 "dev:frontend": "npm --prefix frontend run dev",
10 "build:frontend": "npm --prefix frontend run build",
11 "preview:frontend": "npm --prefix frontend run preview",
12 "install:backend": "npm --prefix backend install",
13 "install:frontend": "npm --prefix frontend install",
14 "install:all": "npm install && npm run install:backend && npm run install:frontend"
15 },
16 "keywords": [],
17 "author": "",
18 "license": "ISC",
19 "type": "commonjs"
20 }
Файл frontend/src/main.jsx
1 import React from 'react';
2 import { createRoot } from 'react-dom/client';
3 import App from './App.jsx';
4 import './styles.css';
5
6 createRoot(document.getElementById('root')).render(
7 <React.StrictMode>
8 <App />
9 </React.StrictMode>,
10 );
Файл frontend/src/api.js
1 import axios from 'axios';
2
3 export const API_BASE_URL = import.meta.env.VITE_API_URL || '/api';
4
5 const client = axios.create({
6 baseURL: API_BASE_URL,
7 timeout: 20000,
8 });
9
10 export const setAuthToken = (token) => {
11 if (token) {
12 client.defaults.headers.common.Authorization = `Bearer ${token}`;
13 return;
14 }
15
16 delete client.defaults.headers.common.Authorization;
17 };
18
19 export const api = {
20 register: async (payload) => {
21 const response = await client.post('/auth/register', payload);
22 return response.data;
23 },
24 login: async (payload) => {
25 const response = await client.post('/auth/login', payload);
26 return response.data;
27 },
28 getMe: async () => {
29 const response = await client.get('/auth/me');
30 return response.data;
31 },
32 deleteMe: async () => {
33 const response = await client.delete('/auth/me');
34 return response.data;
35 },
36 getWorkingPrograms: async () => {
37 const response = await client.get('/working-programs');
38 return response.data;
39 },
40 getWorkingProgram: async (id) => {
41 const response = await client.get(`/working-programs/${id}`);
84
482 ЧДТУ 262261 12.01 3
42 return response.data;
43 },
44 createWorkingProgram: async (payload) => {
45 const response = await client.post('/working-programs', payload);
46 return response.data;
47 },
48 updateWorkingProgram: async (id, payload) => {
49 const response = await client.put(`/working-programs/${id}`, payload);
50 return response.data;
51 },
52 deleteWorkingProgram: async (id) => {
53 const response = await client.delete(`/working-programs/${id}`);
54 return response.data;
55 },
56 getDefaultTemplate: async () => {
57 const response = await client.get('/working-programs/template/default');
58 return response.data;
59 },
60 getTeachers: async () => {
61 const response = await client.get('/teachers');
62 return response.data;
63 },
64 createTeacher: async (payload) => {
65 const response = await client.post('/teachers', payload);
66 return response.data;
67 },
68 };
69
70 export const getPdfUrl = (id) => (
71 `${API_BASE_URL.replace(/\/$/, '')}/working-programs/${id}/pdf`
72 );
Файл frontend/src/App.jsx
1 import { useEffect, useMemo, useState } from 'react';
2 import {
3 BookOpen,
4 ClipboardList,
5 ExternalLink,
6 FileText,
7 FlaskConical,
8 GraduationCap,
9 Layers,
10 Library,
11 ListChecks,
12 LoaderCircle,
13 Plus,
14 RefreshCw,
15 Save,
16 Search,
17 ShieldCheck,
18 TableProperties,
19 Trash2,
20 UserRound,
21 X,
22 } from 'lucide-react';
23 import { api, getPdfUrl, setAuthToken } from './api';
24
25 const clone = (value) => JSON.parse(JSON.stringify(value ?? {}));
26
27 const ensureArray = (value) => (Array.isArray(value) ? value : []);
28
29 const getByPath = (object, path, fallback = '') => {
30 const value = path.split('.').reduce((current, key) => {
31 if (current === null || current === undefined) {
32 return undefined;
33 }
34
35 return current[key];
36 }, object);
37
38 return value === null || value === undefined ? fallback : value;
39 };
40
41 const setByPath = (object, path, value) => {
42 const keys = path.split('.');
43 const root = { ...(object || {}) };
44 let cursor = root;
45
46 keys.forEach((key, index) => {
47 if (index === keys.length - 1) {
48 cursor[key] = value;
49 return;
50 }
51
52 cursor[key] = { ...(cursor[key] || {}) };
53 cursor = cursor[key];
54 });
55
56 return root;
57 };
58
85
482 ЧДТУ 262261 12.01 4
59 const toNumberOrNull = (value) => {
60 if (value === '' || value === null || value === undefined) {
61 return null;
62 }
63
64 const parsed = Number(value);
65 return Number.isNaN(parsed) ? null : parsed;
66 };
67
68 const splitCsv = (value) => value
69 .split(',')
70 .map((item) => item.trim())
71 .filter(Boolean);
72
73 const AUTH_TOKEN_KEY = 'dyplom2026.authToken';
74 const AUTH_STORAGE_KEY = 'dyplom2026.authStorage';
75
76 const isBlank = (value) => value === null || value === undefined || String(value).trim() === '';
77
78 const isHttpUrl = (value) => {
79 try {
80 const url = new URL(value);
81 return url.protocol === 'http:' || url.protocol === 'https:';
82 } catch {
83 return false;
84 }
85 };
86
87 const validateAcademicYear = (value) => {
88 if (isBlank(value)) {
89 return 'Навчальний рік обовʼязковий.';
90 }
91
92 const match = String(value).trim().match(/^(\d{4})-(\d{4})$/);
93
94 if (!match) {
95 return 'Формат має бути YYYY-YYYY, наприклад 2025-2026.';
96 }
97
98 if (Number(match[2]) !== Number(match[1]) + 1) {
99 return 'Другий рік має бути наступним після першого.';
100 }
101
102 return '';
103 };
104
105 const validateChdtuEmail = (value) => {
106 if (isBlank(value)) {
107 return 'Email обовʼязковий.';
108 }
109
110 const email = String(value).trim().toLowerCase();
111
112 if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
113 return 'Вкажи коректний email.';
114 }
115
116 if (!email.endsWith('@chdtu.edu.ua')) {
117 return 'Для реєстрації потрібна пошта @chdtu.edu.ua.';
118 }
119
120 return '';
121 };
122
123 const validateScoreRange = (value) => {
124 if (isBlank(value)) {
125 return '';
126 }
127
128 const match = String(value).trim().match(/^(\d{1,3})(?:-(\d{1,3}))?$/);
129
130 if (!match) {
131 return 'Вкажи число або діапазон, наприклад 90-100.';
132 }
133
134 const from = Number(match[1]);
135 const to = match[2] ? Number(match[2]) : from;
136
137 if (from < 0 || to > 100 || from > to) {
138 return 'Бали мають бути в межах 0-100, від меншого до більшого.';
139 }
140
141 return '';
142 };
143
144 const getFieldValidation = ({ label, value, required = false, kind = 'text' }) => {
145 const normalizedLabel = String(label || '').toLowerCase();
146
147 if (required && isBlank(value)) {
148 return 'Обовʼязкове поле.';
149 }
150
151 if (isBlank(value)) {
152 return '';
86
482 ЧДТУ 262261 12.01 5
153 }
154
155 if (normalizedLabel.includes('навчальний рік')) {
156 return validateAcademicYear(value);
157 }
158
159 if (normalizedLabel.includes('email')) {
160 if (normalizedLabel.includes('chdtu')) {
161 const error = validateChdtuEmail(value);
162 return error === 'Email обовʼязковий.' && !required ? '' : error;
163 }
164
165 return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(String(value).trim())
166 ? ''
167 : 'Вкажи коректний email, наприклад [email protected].';
168 }
169
170 if (
171 normalizedLabel.includes('профайл')
172 || normalizedLabel.includes('розклад')
173 || normalizedLabel.includes('url')
174 ) {
175 return isHttpUrl(String(value).trim())
176 ? ''
177 : 'Посилання має починатися з http:// або https://.';
178 }
179
180 if (normalizedLabel.includes('семестри')) {
181 return /^(\d+\s*,\s*)*\d+$/.test(String(value).trim())
182 ? ''
183 : 'Семестри вкажи через кому, наприклад 1, 2.';
184 }
185
186 if (normalizedLabel.includes('бали')) {
187 return validateScoreRange(value);
188 }
189
190 if (kind === 'number') {
191 const numericValue = Number(value);
192
193 if (Number.isNaN(numericValue)) {
194 return 'Вкажи число.';
195 }
196
197 if (normalizedLabel === '№' && numericValue < 1) {
198 return 'Номер має бути 1 або більше.';
199 }
200
201 if (numericValue < 0) {
202 return 'Значення не може бути відʼємним.';
203 }
204 }
205
206 if (required && String(value).trim().length < 3) {
207 return 'Мінімум 3 символи.';
208 }
209
210 return '';
211 };
212
213 const getFieldHint = ({ label, required = false, kind = 'text' }) => {
214 const normalizedLabel = String(label || '').toLowerCase();
215
216 if (normalizedLabel.includes('навчальний рік')) {
217 return 'Тип даних: навчальний рік у форматі YYYY-YYYY, наприклад 2025-2026.';
218 }
219
220 if (normalizedLabel.includes('email')) {
221 return normalizedLabel.includes('chdtu')
222 ? 'Тип даних: корпоративний email @chdtu.edu.ua.'
223 : 'Тип даних: email, наприклад [email protected].';
224 }
225
226 if (
227 normalizedLabel.includes('профайл')
228 || normalizedLabel.includes('розклад')
229 || normalizedLabel.includes('url')
230 ) {
... фрагмент скорочено, у файлі всього 1933 рядків ...
Файл frontend/src/styles.css
1 :root {
2 color: #152238;
3 background: #eef4fb;
4 font-family:
5 Inter, ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI",
6 sans-serif;
7 font-size: 16px;
8 line-height: 1.45;
9 font-weight: 400;
10 --bg: #eef4fb;
87
482 ЧДТУ 262261 12.01 6
11 --surface: #ffffff;
12 --surface-muted: #f5f8fc;
13 --border: #d2dfec;
14 --border-strong: #9eb3ca;
15 --text: #152238;
16 --muted: #60728a;
17 --accent: #2563eb;
18 --accent-strong: #1d4ed8;
19 --accent-soft: #e8f0ff;
20 --danger: #a43d3d;
21 --danger-soft: #f7e8e8;
22 --warning: #9a641e;
23 --warning-soft: #fbf0df;
24 --success: #22683d;
25 --success-soft: #e5f2e9;
26 --shadow: 0 18px 48px rgba(23, 44, 77, 0.1);
27 }
28
29 * {
30 box-sizing: border-box;
31 }
32
33 body {
34 margin: 0;
35 min-width: 320px;
36 min-height: 100vh;
37 color: var(--text);
38 background: var(--bg);
39 }
40
41 button,
42 input,
43 select,
44 textarea {
45 font: inherit;
46 }
47
48 button {
49 border: 0;
50 }
51
52 .app-shell {
53 display: grid;
54 grid-template-columns: 320px minmax(0, 1fr);
55 min-height: 100vh;
56 }
57
58 .program-sidebar {
59 position: sticky;
60 top: 0;
61 height: 100vh;
62 padding: 18px;
63 overflow: auto;
64 border-right: 1px solid var(--border);
65 background: #f8fbff;
66 }
67
68 .brand-block {
69 display: flex;
70 gap: 12px;
71 align-items: center;
72 margin-bottom: 18px;
73 }
74
75 .brand-mark {
76 display: grid;
77 width: 42px;
78 height: 42px;
79 place-items: center;
80 border-radius: 8px;
81 color: #fff;
82 font-weight: 800;
83 background: var(--accent);
84 }
85
86 .brand-block strong,
87 .brand-block span {
88 display: block;
89 }
90
91 .brand-block span {
92 color: var(--muted);
93 font-size: 0.9rem;
94 }
95
96 .sidebar-actions,
97 .topbar-actions {
98 display: flex;
99 gap: 8px;
100 align-items: center;
101 }
102
103 .sidebar-actions {
104 margin-bottom: 12px;
88
482 ЧДТУ 262261 12.01 7
105 }
106
107 .primary-button,
108 .secondary-button,
109 .icon-button,
110 .danger-icon-button {
111 display: inline-flex;
112 min-height: 38px;
113 align-items: center;
114 justify-content: center;
115 gap: 8px;
116 border-radius: 8px;
117 cursor: pointer;
118 transition: background 0.15s ease, border-color 0.15s ease, transform 0.15s ease;
119 white-space: nowrap;
120 }
121
122 .primary-button {
123 padding: 0 14px;
124 color: #fff;
125 background: var(--accent);
126 font-weight: 700;
127 }
128
129 .sidebar-actions .primary-button {
130 flex: 1;
131 }
132
133 .primary-button:hover {
134 background: var(--accent-strong);
135 }
136
137 .primary-button:disabled {
138 cursor: not-allowed;
139 opacity: 0.68;
140 }
141
142 .secondary-button {
143 padding: 0 13px;
144 border: 1px solid var(--border);
145 color: var(--text);
146 background: var(--surface);
147 font-weight: 650;
148 }
149
150 .secondary-button.full-width {
151 width: 100%;
152 margin-bottom: 12px;
153 }
154
155 .secondary-button:hover,
156 .icon-button:hover {
157 border-color: var(--border-strong);
158 background: var(--surface-muted);
159 }
160
... фрагмент скорочено, у файлі всього 876 рядків ...
Файл backend/app.js
1 const express = require('express');
2 require('dotenv').config();
3
4 const app = express();
5
6 // Дозволяє Express читати JSON з body у POST/PUT запитах.
7 app.use(express.json());
8
9 const documentRoutes = require('./routes/documents');
10 const teacherRoutes = require('./routes/teachers');
11 const workingProgramRoutes = require('./routes/workingPrograms');
12 const authRoutes = require('./routes/auth');
13 const notFoundHandler = require('./middleware/notFoundHandler');
14 const errorHandler = require('./middleware/errorHandler');
15
16 app.use('/auth', authRoutes);
17 // Старий модуль документів лишаємо як попередній етап розробки.
18 app.use('/documents', documentRoutes);
19 app.use('/teachers', teacherRoutes);
20 // Основний модуль дипломної: робочі програми навчальних дисциплін.
21 app.use('/working-programs', workingProgramRoutes);
22 // Обробники помилок мають бути після всіх routes.
23 app.use(notFoundHandler);
24 app.use(errorHandler);
25
26 const PORT = process.env.PORT || 3000;
27
28 app.listen(PORT, () => {
29 console.log(`Server running on port ${PORT}`);
30 });
89
482 ЧДТУ 262261 12.01 8
Файл backend/db.js
1 const { Pool } = require('pg');
2
3 // Єдиний pool підключень до PostgreSQL для всіх service-файлів.
4 const pool = new Pool({
5 user: process.env.DB_USER,
6 password: process.env.DB_PASSWORD,
7 host: process.env.DB_HOST,
8 port: process.env.DB_PORT,
9 database: process.env.DB_NAME,
10 });
11
12 module.exports = pool;
Файл backend/database/schema.sql
1 -- Довідник викладачів. Дані звідси можуть копіюватися у snapshot робочої програми.
2 CREATE TABLE IF NOT EXISTS teachers (
3 id SERIAL PRIMARY KEY,
4 full_name TEXT NOT NULL,
5 degree TEXT,
6 academic_title TEXT,
7 position TEXT,
8 department TEXT,
9 university TEXT,
10 phone TEXT,
11 email TEXT,
12 profile_url TEXT,
13 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
14 updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
15 );
16
17 -- Користувачі системи для майбутньої реєстрації/авторизації.
18 -- password_hash має зберігати тільки bcrypt/argon2-хеш, не сирий пароль.
19 CREATE TABLE IF NOT EXISTS users (
20 id SERIAL PRIMARY KEY,
21 teacher_id INTEGER REFERENCES teachers(id) ON DELETE SET NULL,
22
23 full_name TEXT NOT NULL,
24 email TEXT NOT NULL,
25 password_hash TEXT NOT NULL,
26 role TEXT NOT NULL DEFAULT 'teacher'
27 CHECK (role IN ('teacher', 'methodist', 'admin')),
28
29 is_active BOOLEAN NOT NULL DEFAULT TRUE,
30 last_login_at TIMESTAMP,
31
32 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
33 updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
34
35 CONSTRAINT chk_users_chdtu_email
36 CHECK (email ~* '^[A-Z0-9._%+-]+@chdtu\.edu\.ua$')
37 );
38
39 CREATE UNIQUE INDEX IF NOT EXISTS idx_users_email_lower
40 ON users (LOWER(email));
41
42 -- Старий універсальний модуль документів. Лишений для сумісності з попереднім етапом.
43 CREATE TABLE IF NOT EXISTS documents (
44 id SERIAL PRIMARY KEY,
45 teacher_id INTEGER REFERENCES teachers(id) ON DELETE SET NULL,
46 title TEXT NOT NULL,
47 type TEXT NOT NULL,
48 data JSONB NOT NULL DEFAULT '{}'::jsonb,
49 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
50 updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
51 );
52
53 -- Основна таблиця дипломної: робочі програми навчальних дисциплін.
54 CREATE TABLE IF NOT EXISTS working_programs (
55 id SERIAL PRIMARY KEY,
56 teacher_id INTEGER REFERENCES teachers(id) ON DELETE SET NULL,
57
58 title TEXT NOT NULL,
59 discipline_name TEXT NOT NULL,
60 academic_year TEXT NOT NULL,
61
62 specialty_code TEXT,
63 specialty_name TEXT,
64 educational_program TEXT,
65 education_level TEXT,
66
67 -- У data JSONB зберігається велика вкладена структура документа.
68 data JSONB NOT NULL DEFAULT '{}'::jsonb,
69
70 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
71 updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
72 );
73
90
482 ЧДТУ 262261 12.01 9
74 -- Індекси для майбутнього пошуку/фільтрації у списку робочих програм.
75 CREATE INDEX IF NOT EXISTS idx_working_programs_academic_year
76 ON working_programs (academic_year);
77
78 CREATE INDEX IF NOT EXISTS idx_working_programs_discipline_name
79 ON working_programs (discipline_name);
80
81 CREATE INDEX IF NOT EXISTS idx_working_programs_specialty_code
82 ON working_programs (specialty_code);
Файл backend/routes/auth.js
1 const express = require('express');
2 const router = express.Router();
3 const validateRequest = require('../middleware/validateRequest');
4 const authMiddleware = require('../middleware/authMiddleware');
5 const {
6 registerSchema,
7 loginSchema,
8 } = require('../validators/authValidator');
9 const {
10 register,
11 login,
12 getMe,
13 deleteMe,
14 } = require('../controllers/authController');
15
16 router.post('/register', validateRequest(registerSchema), register);
17 router.post('/login', validateRequest(loginSchema), login);
18 router.get('/me', authMiddleware, getMe);
19 router.delete('/me', authMiddleware, deleteMe);
20
21 module.exports = router;
Файл backend/routes/workingPrograms.js
1 const express = require('express');
2 const router = express.Router();
3 const validateRequest = require('../middleware/validateRequest');
4 const {
5 createWorkingProgramSchema,
6 updateWorkingProgramSchema,
7 idParamSchema,
8 } = require('../validators/workingProgramValidator');
9
10 const {
11 getDefaultWorkingProgramData,
12 createWorkingProgram,
13 getWorkingPrograms,
14 getWorkingProgramById,
15 exportWorkingProgramPdf,
16 updateWorkingProgram,
17 deleteWorkingProgram,
18 } = require('../controllers/workingProgramController');
19
20 router.get('/template/default', getDefaultWorkingProgramData);
21 router.post('/', validateRequest(createWorkingProgramSchema),
22 createWorkingProgram);
23 router.get('/', getWorkingPrograms);
24 // Цей route має бути перед /:id, інакше "pdf" буде сприйнято як частину id.
25 router.get('/:id/pdf', validateRequest(idParamSchema, 'params'),
26 exportWorkingProgramPdf);
27 router.get('/:id', validateRequest(idParamSchema, 'params'),
28 getWorkingProgramById);
29 router.put(
30 '/:id',
31 validateRequest(idParamSchema, 'params'),
32 validateRequest(updateWorkingProgramSchema),
33 updateWorkingProgram,
34 );
35 router.delete('/:id', validateRequest(idParamSchema, 'params'),
36 deleteWorkingProgram);
37
38 module.exports = router;
Файл backend/controllers/authController.js
1 const authService = require('../services/authService');
2 const asyncHandler = require('../utils/asyncHandler');
3
4 exports.register = asyncHandler(async (req, res) => {
5 const result = await authService.register(req.body);
6 res.status(201).json(result);
7 });
8
9 exports.login = asyncHandler(async (req, res) => {
10 const result = await authService.login(req.body);
11 res.json(result);
91
482 ЧДТУ 262261 12.01 10
12 });
13
14 exports.getMe = asyncHandler(async (req, res) => {
15 const user = await authService.getMe(req.user.id);
16 res.json(user);
17 });
18
19 exports.deleteMe = asyncHandler(async (req, res) => {
20 const result = await authService.deleteMe(req.user.id);
21 res.json(result);
22 });
Файл backend/controllers/workingProgramController.js
1 const workingProgramService = require('../services/workingProgramService');
2 const pdfService = require('../services/pdfService');
3 const asyncHandler = require('../utils/asyncHandler');
4
5 exports.getDefaultWorkingProgramData = asyncHandler(async (req, res) => {
6 res.json(workingProgramService.getDefaultData());
7 });
8
9 exports.createWorkingProgram = asyncHandler(async (req, res) => {
10 const workingProgram = await workingProgramService.createWorkingProgram(req.body);
11 res.status(201).json(workingProgram);
12 });
13
14 exports.getWorkingPrograms = asyncHandler(async (req, res) => {
15 const workingPrograms = await workingProgramService.getWorkingPrograms();
16 res.json(workingPrograms);
17 });
18
19 exports.getWorkingProgramById = asyncHandler(async (req, res) => {
20 const workingProgram = await workingProgramService.getWorkingProgramById(req.params.id);
21 res.json(workingProgram);
22 });
23
24 exports.exportWorkingProgramPdf = asyncHandler(async (req, res) => {
25 const workingProgram = await workingProgramService.getWorkingProgramById(req.params.id);
26 const pdf = await pdfService.generateWorkingProgramPdf(workingProgram);
27 const filename = `working-program-${workingProgram.id}.pdf`;
28
29 // inline дозволяє браузеру/Postman показати PDF без примусового завантаження.
30 res.setHeader('Content-Type', 'application/pdf');
31 res.setHeader('Content-Disposition', `inline; filename="${filename}"`);
32 res.setHeader('Content-Length', pdf.length);
33 res.send(pdf);
34 });
35
36 exports.updateWorkingProgram = asyncHandler(async (req, res) => {
37 const workingProgram = await workingProgramService.updateWorkingProgram(req.params.id, req.body);
38 res.json(workingProgram);
39 });
40
41 exports.deleteWorkingProgram = asyncHandler(async (req, res) => {
42 const result = await workingProgramService.deleteWorkingProgram(req.params.id);
43 res.json(result);
44 });
Файл backend/services/authService.js
1 const bcrypt = require('bcrypt');
2 const jwt = require('jsonwebtoken');
3 const pool = require('../db');
4 const AppError = require('../utils/AppError');
5
6 const PASSWORD_SALT_ROUNDS = 12;
7 const JWT_SECRET = process.env.JWT_SECRET || 'dyplom2026-dev-secret-change-me';
8
9 const toPublicUser = (user) => ({
10 id: user.id,
11 teacher_id: user.teacher_id,
12 full_name: user.full_name,
13 email: user.email,
14 role: user.role,
15 is_active: user.is_active,
16 created_at: user.created_at,
17 updated_at: user.updated_at,
18 });
19
20 const normalizeEmail = (email) => String(email || '').trim().toLowerCase();
21
22 const assertChdtuEmail = (email) => {
23 if (!normalizeEmail(email).endsWith('@chdtu.edu.ua')) {
24 throw new AppError('Only @chdtu.edu.ua email addresses are allowed', 400);
25 }
26 };
27
28 const signToken = (user, remember = false) => jwt.sign(
92
482 ЧДТУ 262261 12.01 11
29 {
30 sub: user.id,
31 email: user.email,
32 role: user.role,
33 },
34 JWT_SECRET,
35 {
36 expiresIn: remember ? '30d' : '8h',
37 },
38 );
39
40 const getUserByEmail = async (email) => {
41 const result = await pool.query(
42 'SELECT * FROM users WHERE LOWER(email) = LOWER($1)',
43 [email],
44 );
45
46 return result.rows[0] || null;
47 };
48
49 const getUserById = async (id) => {
50 const result = await pool.query(
51 'SELECT * FROM users WHERE id = $1',
52 [id],
53 );
54
55 return result.rows[0] || null;
56 };
57
58 const register = async ({ full_name, email, password, remember }) => {
59 const normalizedEmail = normalizeEmail(email);
60 assertChdtuEmail(normalizedEmail);
61
62 const existingUser = await getUserByEmail(normalizedEmail);
63
64 if (existingUser) {
65 throw new AppError('User with this email already exists', 409);
66 }
67
68 const passwordHash = await bcrypt.hash(password, PASSWORD_SALT_ROUNDS);
69 const result = await pool.query(
70 `INSERT INTO users (full_name, email, password_hash)
71 VALUES ($1, $2, $3)
72 RETURNING *`,
73 [full_name, normalizedEmail, passwordHash],
74 );
75 const user = result.rows[0];
76
77 return {
78 user: toPublicUser(user),
79 token: signToken(user, remember),
80 };
81 };
82
83 const login = async ({ email, password, remember }) => {
84 const normalizedEmail = normalizeEmail(email);
85 assertChdtuEmail(normalizedEmail);
86
87 const user = await getUserByEmail(normalizedEmail);
88
89 if (!user || !user.is_active) {
90 throw new AppError('Invalid email or password', 401);
91 }
92
93 const passwordMatches = await bcrypt.compare(password, user.password_hash);
94
95 if (!passwordMatches) {
96 throw new AppError('Invalid email or password', 401);
97 }
98
99 await pool.query(
100 'UPDATE users SET last_login_at = CURRENT_TIMESTAMP, updated_at = CURRENT_TIMESTAMP WHERE id = $1',
101 [user.id],
102 );
103
104 return {
105 user: toPublicUser(user),
106 token: signToken(user, remember),
107 };
108 };
109
110 const getMe = async (userId) => {
111 const user = await getUserById(userId);
112
113 if (!user || !user.is_active) {
114 throw new AppError('User not found', 404);
115 }
116
117 return toPublicUser(user);
118 };
119
120 const deleteMe = async (userId) => {
... фрагмент скорочено, у файлі всього 139 рядків ...
93
482 ЧДТУ 262261 12.01 12
Файл backend/services/workingProgramService.js
1 const pool = require('../db');
2 const teacherService = require('./teacherService');
3 const AppError = require('../utils/AppError');
4 const deepMerge = require('../utils/deepMerge');
5 const buildWorkingProgramDefaultData = require('../templates/workingProgramDefaultData');
6
7 const hasOwn = (object, key) => Object.prototype.hasOwnProperty.call(object, key);
8
9 const requireText = (payload, field) => {
10 if (!payload[field] || typeof payload[field] !== 'string' || payload[field].trim() === '') {
11 throw new AppError(`${field} is required`, 400);
12 }
13
14 return payload[field].trim();
15 };
16
17 const getTeacherSnapshot = async (teacherId) => {
18 if (!teacherId) {
19 return null;
20 }
21
22 return teacherService.getTeacherById(teacherId);
23 };
24
25 // Будує тіло JSONB-документа: базова структура + дані користувача + snapshot викладача.
26 const buildProgramData = async (payload, existingData = null) => {
27 const teacher = await getTeacherSnapshot(payload.teacher_id);
28 const defaultData = buildWorkingProgramDefaultData(payload, teacher);
29 const baseData = existingData || defaultData;
30 // Deep merge оновлює вкладені JSON-поля, не стираючи сусідні поля.
31 const mergedData = deepMerge(baseData, payload.data || {});
32
33 return {
34 ...mergedData,
35 teacherInfo: {
36 ...(mergedData.teacherInfo || {}),
37 primaryTeacher: teacher,
38 },
39 };
40 };
41
42 const getDefaultData = () => buildWorkingProgramDefaultData();
43
44 const createWorkingProgram = async (payload) => {
45 const title = requireText(payload, 'title');
46 const disciplineName = requireText(payload, 'discipline_name');
47 const academicYear = requireText(payload, 'academic_year');
48
49 const programPayload = {
50 teacher_id: payload.teacher_id || null,
51 title,
52 discipline_name: disciplineName,
53 academic_year: academicYear,
54 specialty_code: payload.specialty_code || null,
55 specialty_name: payload.specialty_name || null,
56 educational_program: payload.educational_program || null,
57 education_level: payload.education_level || null,
58 data: payload.data || {},
59 };
60
61 const data = await buildProgramData(programPayload);
62
63 const result = await pool.query(
64 `INSERT INTO working_programs (
65 teacher_id,
66 title,
67 discipline_name,
68 academic_year,
69 specialty_code,
70 specialty_name,
71 educational_program,
72 education_level,
73 data
74 )
75 VALUES ($1, $2, $3, $4, $5, $6, $7, $8, $9)
76 RETURNING *`,
77 [
78 programPayload.teacher_id,
79 programPayload.title,
80 programPayload.discipline_name,
81 programPayload.academic_year,
82 programPayload.specialty_code,
83 programPayload.specialty_name,
84 programPayload.educational_program,
85 programPayload.education_level,
86 data,
87 ],
88 );
89
94
482 ЧДТУ 262261 12.01 13
90 return result.rows[0];
91 };
92
93 const getWorkingPrograms = async () => {
94 const result = await pool.query(
95 // Join потрібен лише для зручного списку; повний snapshot викладача лежить у data JSONB.
96 `SELECT
97 working_programs.*,
98 teachers.full_name AS teacher_full_name
99 FROM working_programs
100 LEFT JOIN teachers ON teachers.id = working_programs.teacher_id
101 ORDER BY working_programs.created_at DESC`,
102 );
103
104 return result.rows;
105 };
106
107 const getWorkingProgramById = async (id) => {
108 const result = await pool.query(
109 `SELECT
110 working_programs.*,
111 teachers.full_name AS teacher_full_name
112 FROM working_programs
113 LEFT JOIN teachers ON teachers.id = working_programs.teacher_id
114 WHERE working_programs.id = $1`,
115 [id],
116 );
117
118 if (result.rows.length === 0) {
119 throw new AppError('Working program not found', 404);
120 }
121
122 return result.rows[0];
123 };
124
125 const updateWorkingProgram = async (id, payload) => {
126 const existing = await getWorkingProgramById(id);
127
128 // Зберігаємо старі значення колонок, якщо запит оновлює тільки data JSONB.
129 const nextPayload = {
130 teacher_id: hasOwn(payload, 'teacher_id') ? payload.teacher_id : existing.teacher_id,
131 title: hasOwn(payload, 'title') ? payload.title : existing.title,
132 discipline_name: hasOwn(payload, 'discipline_name') ? payload.discipline_name :
existing.discipline_name,
133 academic_year: hasOwn(payload, 'academic_year') ? payload.academic_year : existing.academic_year,
134 specialty_code: hasOwn(payload, 'specialty_code') ? payload.specialty_code : existing.specialty_code,
135 specialty_name: hasOwn(payload, 'specialty_name') ? payload.specialty_name : existing.specialty_name,
136 educational_program: hasOwn(payload, 'educational_program')
137 ? payload.educational_program
138 : existing.educational_program,
139 education_level: hasOwn(payload, 'education_level') ? payload.education_level :
existing.education_level,
140 data: payload.data || {},
141 };
142
143 nextPayload.title = requireText(nextPayload, 'title');
144 nextPayload.discipline_name = requireText(nextPayload, 'discipline_name');
145 nextPayload.academic_year = requireText(nextPayload, 'academic_year');
146
147 const data = await buildProgramData(nextPayload, existing.data || {});
148
149 const result = await pool.query(
150 `UPDATE working_programs
151 SET
152 teacher_id = $1,
153 title = $2,
154 discipline_name = $3,
155 academic_year = $4,
156 specialty_code = $5,
157 specialty_name = $6,
158 educational_program = $7,
159 education_level = $8,
160 data = $9,
... фрагмент скорочено, у файлі всього 201 рядків ...
Файл backend/services/pdfService.js
1 const fs = require('fs');
2 const path = require('path');
3 const Handlebars = require('handlebars');
4 const puppeteer = require('puppeteer');
5 const AppError = require('../utils/AppError');
6
7 const workingProgramTemplateDir = path.join(__dirname, '..', 'templates', 'working-program');
8 const workingProgramTemplatePath = path.join(workingProgramTemplateDir, 'document.hbs');
9 const workingProgramStylesPath = path.join(workingProgramTemplateDir, 'styles.css');
10
11 // Puppeteer потрібен реальний браузер: спершу беремо шлях з env, потім типові шляхи Windows.
12 const browserExecutableCandidates = [
13 process.env.PUPPETEER_EXECUTABLE_PATH,
14 'C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe',
15 'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe',
95
482 ЧДТУ 262261 12.01 14
16 'C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe',
17 'C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe',
18 ].filter(Boolean);
19
20 const getBrowserExecutablePath = () => (
21 browserExecutableCandidates.find((candidatePath) => fs.existsSync(candidatePath))
22 );
23
24 // Показує запасне значення замість порожніх/null полів у незаповненому документі.
25 Handlebars.registerHelper('value', (value, fallback = '') => {
26 if (value === null || value === undefined || value === '') {
27 return fallback;
28 }
29
30 return value;
31 });
32
33 Handlebars.registerHelper('hasItems', (items) => Array.isArray(items) && items.length > 0);
34
35 Handlebars.registerHelper('inc', (value) => Number(value) + 1);
36
37 Handlebars.registerHelper('listValue', (value, fallback = '') => {
38 if (Array.isArray(value)) {
39 const items = value
40 .filter((item) => item !== null && item !== undefined && item !== '')
41 .map((item) => String(item));
42
43 return items.length > 0 ? items.join(', ') : fallback;
44 }
45
46 if (value === null || value === undefined || value === '') {
47 return fallback;
48 }
49
50 return value;
51 });
52
53 // Робить шаблон простішим: {{purposeAndTasks.purpose}} замість довгих шляхів через data.
54 const buildWorkingProgramViewModel = (workingProgram) => {
55 const data = workingProgram.data || {};
56
57 return {
58 ...workingProgram,
59 data,
60 titlePage: data.titlePage || {},
61 approvalPage: data.approvalPage || {},
62 teacherInfo: data.teacherInfo || {},
63 disciplineDescription: data.disciplineDescription || {},
64 purposeAndTasks: data.purposeAndTasks || {},
65 learningOutcomes: data.learningOutcomes || [],
66 courseProgram: data.courseProgram || [],
67 thematicPlan: data.thematicPlan || [],
68 labs: data.labs || [],
69 selfStudy: data.selfStudy || {},
70 assessment: data.assessment || {},
71 examQuestions: data.examQuestions || {},
72 literature: data.literature || [],
73 informationResources: data.informationResources || [],
74 teachingMethods: data.teachingMethods || [],
75 disciplinePolicy: data.disciplinePolicy || '',
76 prerequisites: data.prerequisites || '',
77 postrequisites: data.postrequisites || '',
78 };
79 };
80
81 // Об'єднує Handlebars HTML і CSS в один HTML-документ для друку.
82 const renderWorkingProgramHtml = (workingProgram) => {
83 const template = fs.readFileSync(workingProgramTemplatePath, 'utf8');
84 const styles = fs.readFileSync(workingProgramStylesPath, 'utf8');
85 const compiledTemplate = Handlebars.compile(template);
86
87 return compiledTemplate({
88 ...buildWorkingProgramViewModel(workingProgram),
89 styles,
90 });
91 };
92
93 // Відкриває невидимий Chrome/Edge, рендерить HTML і друкує його як PDF A4.
94 const generatePdfFromHtml = async (html) => {
95 const executablePath = getBrowserExecutablePath();
96
97 const launchOptions = {
98 headless: true,
99 args: ['--no-sandbox', '--disable-setuid-sandbox'],
100 };
101
102 if (executablePath) {
103 launchOptions.executablePath = executablePath;
104 }
105
106 let browser;
107
108 try {
109 browser = await puppeteer.launch(launchOptions);
96
482 ЧДТУ 262261 12.01 15
110 const page = await browser.newPage();
... фрагмент скорочено, у файлі всього 146 рядків ...
Файл backend/validators/authValidator.js
1 const Joi = require('joi');
2
3 const chdtuEmail = Joi.string()
4 .trim()
5 .lowercase()
6 .email()
7 .pattern(/@chdtu\.edu\.ua$/)
8 .required()
9 .messages({
10 'string.email': 'email must be valid',
11 'string.pattern.base': 'email must use @chdtu.edu.ua domain',
12 });
13
14 const registerSchema = Joi.object({
15 full_name: Joi.string().trim().min(3).required(),
16 email: chdtuEmail,
17 password: Joi.string().min(8).max(128).required(),
18 remember: Joi.boolean().default(false),
19 }).unknown(false);
20
21 const loginSchema = Joi.object({
22 email: chdtuEmail,
23 password: Joi.string().min(1).max(128).required(),
24 remember: Joi.boolean().default(false),
25 }).unknown(false);
26
27 module.exports = {
28 registerSchema,
29 loginSchema,
30 };
Файл backend/validators/workingProgramValidator.js
1 const Joi = require('joi');
2
3 // Часто текстове поле може бути ще не заповнене, тому дозволяємо '' і null.
4 const nullableText = Joi.string().trim().allow('', null);
5
6 // Перевіряємо верхній рівень data JSONB, але дозволяємо деталям секцій розвиватись поступово.
7 const workingProgramDataSchema = Joi.object({
8 meta: Joi.object().unknown(true),
9 titlePage: Joi.object().unknown(true),
10 approvalPage: Joi.object().unknown(true),
11 teacherInfo: Joi.object().unknown(true),
12 disciplineDescription: Joi.object().unknown(true),
13 purposeAndTasks: Joi.object({
14 subject: nullableText,
15 purpose: nullableText,
16 tasks: nullableText,
17 }).unknown(true),
18 learningOutcomes: Joi.array().items(Joi.object().unknown(true)),
19 prerequisites: nullableText,
20 postrequisites: nullableText,
21 courseProgram: Joi.array().items(Joi.object().unknown(true)),
22 thematicPlan: Joi.array().items(Joi.object().unknown(true)),
23 labs: Joi.array().items(Joi.object().unknown(true)),
24 selfStudy: Joi.object().unknown(true),
25 assessment: Joi.object().unknown(true),
26 examQuestions: Joi.object().unknown(true),
27 literature: Joi.array().items(Joi.object().unknown(true)),
28 informationResources: Joi.array().items(Joi.object().unknown(true)),
29 teachingMethods: Joi.array().items(Joi.alternatives().try(Joi.string(), Joi.object().unknown(true))),
30 disciplinePolicy: nullableText,
31 }).unknown(false);
32
33 const createWorkingProgramSchema = Joi.object({
34 teacher_id: Joi.number().integer().positive().allow(null),
35 // Ці три поля потрібні для списку, пошуку і назви майбутнього PDF.
36 title: Joi.string().trim().min(3).required(),
37 discipline_name: Joi.string().trim().min(3).required(),
38 academic_year: Joi.string().trim().pattern(/^\d{4}-\d{4}$/).required()
39 .messages({
40 'string.pattern.base': 'academic_year must use YYYY-YYYY format',
41 }),
42 specialty_code: nullableText,
43 specialty_name: nullableText,
44 educational_program: nullableText,
45 education_level: nullableText,
46 data: workingProgramDataSchema.default({}),
47 }).unknown(false);
48
49 const updateWorkingProgramSchema = Joi.object({
50 teacher_id: Joi.number().integer().positive().allow(null),
51 title: Joi.string().trim().min(3),
97
482 ЧДТУ 262261 12.01 16
52 discipline_name: Joi.string().trim().min(3),
53 academic_year: Joi.string().trim().pattern(/^\d{4}-\d{4}$/)
54 .messages({
55 'string.pattern.base': 'academic_year must use YYYY-YYYY format',
56 }),
57 specialty_code: nullableText,
58 specialty_name: nullableText,
59 educational_program: nullableText,
60 education_level: nullableText,
61 data: workingProgramDataSchema,
62 // PUT має оновлювати хоча б одне поле.
63 }).min(1).unknown(false);
64
65 // Params теж валідуємо, щоб /working-programs/abc не йшов до SQL.
66 const idParamSchema = Joi.object({
67 id: Joi.number().integer().positive().required(),
68 });
69
70 module.exports = {
71 createWorkingProgramSchema,
72 updateWorkingProgramSchema,
73 idParamSchema,
74 };
Файл backend/templates/working-program/document.hbs
1 <!doctype html>
2 <html lang="uk">
3 <head>
4 <meta charset="utf-8">
5 <title>{{value discipline_name "Робоча програма"}}</title>
6 <style>{{{styles}}}</style>
7 </head>
8 <body>
9 <main class="document">
10 <!-- Перша сторінка: титул робочої програми. -->
11 <section class="page title-page">
12 <div class="university-block">
13 <p>{{value titlePage.university "Черкаський державний технологічний університет"}}</p>
14 <p>{{value titlePage.faculty "Факультет інформаційних технологій і систем"}}</p>
15 </div>
16
17 <div class="approval-block">
18 <p class="approval-title">«ЗАТВЕРДЖУЮ»</p>
19 <p>{{value titlePage.approval.approverPosition "Голова вченої ради"}}</p>
20 <p>{{value titlePage.approval.approverName "________________________"}}</p>
21 <p>Протокол № {{value titlePage.approval.protocolNumber "___"}}</p>
22 <p>«{{value titlePage.approval.protocolDate "__"}}» __________ 20__ р.</p>
23 </div>
24
25 <div class="title-center">
26 <h1>РОБОЧА ПРОГРАМА</h1>
27 <h2>навчальної дисципліни</h2>
28 <h3>«{{value discipline_name "Назва дисципліни"}}»</h3>
29 <p>Шифр за ОПП - {{value titlePage.programCode "________"}}</p>
30 <p>підготовки здобувачів освітнього ступеня {{value education_level "________"}}</p>
31 </div>
32
33 <table class="plain-table title-meta">
34 <tr>
35 <td>Спеціальність</td>
36 <td>{{value specialty_code "___"}} {{value specialty_name "________________"}}</td>
37 </tr>
38 <tr>
39 <td>Освітня програма</td>
40 <td>{{value educational_program "________________"}}</td>
41 </tr>
42 </table>
43
44 <p class="academic-year">{{value academic_year "20__-20__"}} навчальний рік</p>
45 </section>
46
47 <!-- Друга сторінка: розробники, протоколи, погодження та підписи. -->
48 <section class="page approval-page">
49 <p>
50 Робоча програма навчальної дисципліни «{{value discipline_name "Назва дисципліни"}}»
51 підготовки здобувачів освітнього ступеня {{value education_level "________"}}
52 за спеціальністю {{value specialty_code "___"}} {{value specialty_name "________________"}},
53 освітня програма: {{value educational_program "________________"}}.
54 </p>
55
56 <h2>Розробники:</h2>
57 {{#if (hasItems approvalPage.developers)}}
58 {{#each approvalPage.developers}}
59 <p class="underline">{{full_name}}, {{degree}}, {{position}}</p>
60 {{/each}}
61 {{else}}
62 <p class="underline">______________________________</p>
63 {{/if}}
64
65 <p class="spaced">
66 Робоча програма навчальної дисципліни затверджена на засіданні кафедри
98
482 ЧДТУ 262261 12.01 17
67 {{value approvalPage.departmentApproval.departmentName "______________________________"}}
68 </p>
69
70 <p>
71 Протокол № {{value approvalPage.departmentApproval.protocolNumber "__"}}
72 від «{{value approvalPage.departmentApproval.protocolDate "__"}}» __________ 20__ року.
73 </p>
74
75 <div class="signature-row">
76 <span>Завідувач кафедри</span>
77 <span class="signature-line"></span>
78 <span>/{{value approvalPage.departmentApproval.headName "________________"}}/</span>
79 </div>
80
81 <h2 class="agreement-title">ПОГОДЖЕНО:</h2>
82
83 <div class="signature-row">
84 <span>Навчально-методичний відділ</span>
85 <span class="signature-line"></span>
86 <span>/________________/</span>
87 </div>
88 </section>
89
90 <!-- Основний зміст документа, який заповнюється з data JSONB. -->
91 <section class="content">
92 <h2>1. ІНФОРМАЦІЯ ПРО ВИКЛАДАЧА</h2>
93 <table class="info-table">
94 <tr>
95 <th>Прізвище, ім'я, по батькові</th>
96 <td>{{value teacherInfo.primaryTeacher.full_name "________________"}}</td>
97 </tr>
98 <tr>
99 <th>Науковий ступінь</th>
100 <td>{{value teacherInfo.primaryTeacher.degree "________________"}}</td>
101 </tr>
102 <tr>
103 <th>Вчене звання</th>
104 <td>{{value teacherInfo.primaryTeacher.academic_title "________________"}}</td>
105 </tr>
106 <tr>
107 <th>Посада</th>
108 <td>{{value teacherInfo.primaryTeacher.position "________________"}}</td>
109 </tr>
110 <tr>
111 <th>Місце роботи</th>
112 <td>{{value teacherInfo.primaryTeacher.department "________________"}}</td>
113 </tr>
114 <tr>
115 <th>Контактний телефон</th>
116 <td>{{value teacherInfo.primaryTeacher.phone "________________"}}</td>
117 </tr>
118 <tr>
119 <th>e-mail</th>
120 <td>{{value teacherInfo.primaryTeacher.email "________________"}}</td>
121 </tr>
122 <tr>
123 <th>Профайл дисципліни</th>
124 <td>{{value teacherInfo.disciplineProfileUrl "________________"}}</td>
125 </tr>
126 <tr>
127 <th>Розклад консультацій</th>
128 <td>{{value teacherInfo.consultationScheduleUrl "________________"}}</td>
129 </tr>
130 </table>
131
132 <h2>2. ОПИС НАВЧАЛЬНОЇ ДИСЦИПЛІНИ</h2>
133 <table class="description-table">
134 <tr>
135 <th>Галузь знань, спеціальність, освітня програма, освітній рівень</th>
136 <th>Загальні характеристики</th>
137 <th>Навчальне навантаження з дисципліни</th>
138 </tr>
139 <tr>
140 <td rowspan="7" class="description-profile-cell">
141 <p><strong>Галузь знань</strong><br>{{value disciplineDescription.knowledgeField
"________________"}}</p>
142 <p><strong>Спеціальність</strong><br>{{value specialty_code "___"}} {{value specialty_name
"________________"}}</p>
143 <p><strong>Освітня програма</strong><br>{{value educational_program "________________"}}</p>
144 <p><strong>Освітній рівень</strong><br>{{value education_level "________________"}}</p>
145 </td>
146 <td><span class="description-label">Статус дисципліни:</span> {{value
disciplineDescription.disciplineStatus "________________"}}</td>
147 <td><span class="description-label">Аудиторні години:</span> {{value
disciplineDescription.classroomHours "__"}}</td>
148 </tr>
149 <tr>
150 <td><span class="description-label">Курс підготовки:</span> {{value
disciplineDescription.courseYear "__"}}</td>
151 <td><span class="description-label">Лекції:</span> {{value
disciplineDescription.lecturesHours.fullTime "__"}} / {{value disciplineDescription.lecturesHours.partTime
"__"}}</td>
152 </tr>
153 <tr>
99
482 ЧДТУ 262261 12.01 18
154 <td><span class="description-label">Семестр підготовки:</span> {{listValue
disciplineDescription.semesters "__"}}</td>
155 <td><span class="description-label">Практичні:</span> {{value
disciplineDescription.practicalHours.fullTime "__"}} / {{value disciplineDescription.practicalHours.partTime
"__"}}</td>
156 </tr>
157 <tr>
158 <td><span class="description-label">Кількість кредитів ЄКТС:</span> {{value
disciplineDescription.credits "__"}}</td>
159 <td><span class="description-label">Лабораторні:</span> {{value
disciplineDescription.labHours.fullTime "__"}} / {{value disciplineDescription.labHours.partTime "__"}}</td>
160 </tr>
... фрагмент скорочено, у файлі всього 440 рядків ...
100
ДОДАТОК В
«Web-система формування робочих програм кафедри ПЗАС ЧДТУ»
Інструкція користувачеві
482 ЧДТУ 262261 34 01
Розробник ________________ Сергієнко Н. С.
Черкаси 2026
482 ЧДТУ 262261 34.01 2
Інструкція користувачеві
Інструкція призначена для користувачів web-системи формування робочих
програм кафедри ПЗАС ЧДТУ. Вона описує основні дії, необхідні для входу в
систему, створення робочої програми, заповнення її розділів, збереження даних та
формування PDF-документа.
Вимоги до робочого середовища:
1. наявність сучасного web-браузера;
2. доступ до локального або розгорнутого web-застосунку;
3. наявність облікового запису користувача;
4. підключення серверної частини та бази даних PostgreSQL.
Порядок роботи з системою
1. Вхід у систему
Користувач відкриває web-застосунок у браузері, вводить корпоративну
електронну адресу та пароль, після чого натискає кнопку входу. Якщо облікового
запису немає, користувач проходить реєстрацію.
2. Перегляд списку робочих програм
Після авторизації користувач переходить до списку робочих програм. У
цьому режимі можна переглядати наявні записи, відкривати програму для
редагування або створювати нову.
3. Створення робочої програми
Для створення нового документа користувач натискає відповідну кнопку,
після чого заповнює основні відомості: назву, дисципліну, навчальний рік,
спеціальність, освітню програму та рівень освіти.
4. Редагування розділів
Користувач послідовно заповнює розділи робочої програми: титульні дані,
інформацію про викладача, опис дисципліни, мету, результати навчання,
тематичний план, систему оцінювання та список літератури.
5. Перевірка та збереження
102
482 ЧДТУ 262261 34.01 3
Після заповнення даних система виконує перевірку обов'язкових полів і форматів.
Якщо виявлено помилки, користувач повертається до редагування. Якщо дані
коректні, робоча програма зберігається в базі даних.
6. Формування PDF
Після збереження користувач запускає формування PDF. Система
використовує дані робочої програми, HTML-шаблон і модуль генерації PDF, після
чого повертає готовий документ для перегляду або завантаження.
7. Видалення записів
За потреби користувач може видалити робочу програму. Перед видаленням
необхідно переконатися, що документ більше не потрібний для подальшої роботи.
Рисунок В.1 - Сторінка авторизації користувача
103
482 ЧДТУ 262261 34.01 4
Рисунок В.2 - Список робочих програм
Рисунок В.3 - Форма створення або редагування робочої програми
104
482 ЧДТУ 262261 34.01 5
Рисунок В.4 - Заповнення даних викладача та дисципліни
Рисунок В.5 - Повідомлення про перевірку або збереження даних
105
482 ЧДТУ 262261 34.01 6
Рисунок В.6 - Сформований PDF-документ робочої програми
106
ДОДАТОК Г
«Web-система формування робочих програм кафедри ПЗАС ЧДТУ»
Презентація
482 ЧДТУ 262261 90 01
Розробник ________________ Сергієнко Н. С.
Черкаси 2026
482 ЧДТУ 262261 90.01 2
Слайд 1 - Кваліфікаційна робота бакалавра
Слайд 2 - Вступ
108
482 ЧДТУ 262261 90.01 3
Слайд 3 - Аналіз технічної інформації
Слайд 4 - Актуальність задачі
109
482 ЧДТУ 262261 90.01 4
Слайд 5 - Аналіз існуючих рішень
Слайд 6 - Аналіз способів вирішення задачі
110
482 ЧДТУ 262261 90.01 5
Слайд 7 - Постановка задачі
Слайд 8 - Методика проектування системи
111
482 ЧДТУ 262261 90.01 6
Слайд 9 - Результати етапу аналізу вимог
Слайд 10 - Первинні та детальні вимоги
112
482 ЧДТУ 262261 90.01 7
Слайд 11 - Варіанти використання
Слайд 12 - Логічна структура системи
113
482 ЧДТУ 262261 90.01 8
Слайд 13 - Архітектурне проектування
Слайд 14 - Моделювання поведінки системи
114
482 ЧДТУ 262261 90.01 9
Слайд 15 - Обґрунтування вибору засобів реалізації
Слайд 16 - Структурна схема реалізованої системи
115
482 ЧДТУ 262261 90.01 10
Слайд 17 - Логічна схема системи
Слайд 18 - Структура бази даних
116
482 ЧДТУ 262261 90.01 11
Слайд 19 - Інтерфейс користувача
Слайд 20 - Модульне та інтеграційне тестування
117
482 ЧДТУ 262261 90.01 12
Слайд 21 - Системне та приймальне тестування
Слайд 22 - Приклад роботи програмного комплексу
118
482 ЧДТУ 262261 90.01 13
Слайд 23 - Результат роботи програмного комплексу
Слайд 24 - Робоча програма навчальної дисципліни
119
482 ЧДТУ 262261 90.01 14
Слайд 25 - Висновки
Слайд 26 - Подяка науковому керівнику та членам комісії
120
482 ЧДТУ 262261 90.01 15
Слайд 27 - Дякую за увагу
121