Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/9761| Назва: | Програма ведення журналу навантаження викладача |
| Автори: | Салапатов , Володимир Іванович Кобилки, Дмитра Віталійовича |
| Ключові слова: | журнал навантаження;автоматизація обліку;десктопний додаток;C#;.NET 8.0;WPF;Material Design;SQLite;Entity Framework Core;ClosedXML;статистика;експорт Excel;teacher workload journal;accounting automation;desktop application;C#;WPF;.NET 8.0;Material Design;SQLite;Entity Framework Core;ClosedXML;statistics;Excel expo |
| Дата публікації: | 17-чер-2026 |
| Короткий огляд (реферат): | АНОТАЦІЯ
Кобилка Д.В., кваліфікаційна робота бакалавра на тему «ПРОГРАМНИЙ КОМПЛЕКС "ЖУРНАЛ НАВАНТАЖЕННЯ ВИКЛАДАЧА"». Напрям підготовки 121 «Інженерія програмного забезпечення», ЧДТУ, Черкаси, 2026.
Мета виконання кваліфікаційної роботи бакалавра: проектування та конструювання десктопного програмного забезпечення для автоматизованого планування, оперативного обліку та аналізу індивідуального навчального навантаження науково-педагогічних працівників закладу вищої освіти з можливістю динамічного контролю та генерації звітності.
Завдання при проектуванні програмного забезпечення: провести аналіз існуючих методів та засобів обліку навчального навантаження; визначити їх переваги та недоліки; сформувати функціональні та нефункціональні вимоги до програмного комплексу; розробити логічну та архітектурну структуру системи та відобразити взаємодію її компонентів за допомогою UML-діаграм; обґрунтувати вибір засобів реалізації; реалізувати модулі ведення нормативно-довідкової інформації (довідники дисциплін та академічних груп); реалізувати підсистему планування годин та електронний журнал обліку проведених занять; розробити аналітичний модуль динамічного розрахунку статистики з автоматичним виявленням недопрацювань та перепрацювань годин і їх колірною індикацією; забезпечити експорт зведеної звітності у формат електронних таблиць MS Excel; провести модульне, інтеграційне, системне та приймальне тестування розробленого програмного забезпечення.
Об’єкт роботи: програмна реалізація інформаційної технології ведення журналу навантаження викладача
Предмет розробки: процес програмної реалізації інформаційної технології ведення журналу навантаження викладача Вирішено наступні поставлені задачі:
1. Проведено аналіз предметної області та оцінку існуючих програмних аналогів для автоматизації моніторингу навчального навантаження.
2 Формалізовано проблеми діючих алгоритмів обліку робочого часу та виявлено технічні недоліки наявних рішень, що стало основою для проектування нової системи.
3 Сформовано вимоги до програмного комплексу журналу навантаження викладача.
4 Розроблено логічну та архітектурну структуру системи з використанням UML-діаграм.
5 Спроектовано реляційну базу даних на основі підходу Code-First за допомогою Entity Framework Core та розгорнуто локальну СКБД SQLite.
6 Реалізовано користувацький інтерфейс на базі технології WPF з використанням бібліотеки MaterialDesignThemes.
7 Реалізовано підсистему оперативного обліку (електронний журнал занять) та планування навантаження із жорсткою реляційною прив'язкою даних.
8 Реалізовано аналітичний модуль динамічного розрахунку статистики з автоматичним виявленням перепрацювань/недопрацювань, розрахунком прогресу та кольоровою семантичною індикацією.
9 Реалізовано модуль програмного експорту звітів у формат MS Excel за допомогою ClosedXML із гнучким форматуванням і підсвічуванням рядків відхилення від плану.
10 Проведено комплексне тестування розробленого програмного забезпечення в умовах реальної експлуатації.
Обсяг кваліфікаційної роботи бакалавра – містить 3 розділи, рисунки, таблиці, джерела в списку посилань, додатки. ANNOTATION Kobylka D.V., bachelor’s qualification thesis on the topic “SOFTWARE COMPLEX 'TEACHER WORKLOAD JOURNAL'”. Field of study 121 “Software Engineering”, ChSTU, Cherkasy, 2026. The purpose of the bachelor’s qualification thesis is the design and development of desktop software for automated planning, operational accounting, and analysis of the individual teaching workload of faculty members in a higher education institution with the capability of dynamic monitoring and report generation. The tasks in software design are: to analyze existing analogues and methods for tracking teaching workload; to determine their advantages and disadvantages; to formulate functional and non-functional requirements for the software complex; to develop the logical and architectural structure of the system and represent the interaction of its components using UML diagrams; to justify the choice of implementation tools; to implement master data reference modules (disciplines and academic groups directories); to implement a hours planning subsystem and an electronic journal for tracking conducted lessons; to develop an analytical module for real-time statistics calculation with automatic detection of underworked and overworked hours and their color-coded indication; to ensure the export of consolidated reports to MS Excel spreadsheet format; to conduct unit, integration, system, and acceptance testing of the developed software. Object of the work: software implementation of information technology for maintaining a teacher workload journal. Subject of the development: the process of software implementation of information technology for maintaining a teacher workload journal. The following tasks were solved: 1 Existing system analogues for monitoring and accounting of teaching workload were analyzed. 2 The main problems of manual paper-based tracking of working hours and the disadvantages of existing software solutions were identified. 3 The requirements for the teacher workload journal software complex were formulated. 4 The logical and architectural structure of the system was developed using UML diagrams. 5 A relational database was designed based on the Code-First approach using Entity Framework Core, and a local SQLite DBMS was deployed. 6 A user interface was implemented based on WPF technology using the MaterialDesignThemes library. 7 An operational accounting subsystem and workload planning with strict relational data binding were implemented. 8 An analytical module for dynamic statistics calculation ("Statistics" module) with automatic detection of overworking/underworking, progress calculation, and color-coded semantic indication was implemented. 9 A module for programmatic export of reports to MS Excel format using ClosedXML with flexible formatting and highlighting of rows deviating from the plan was implemented. 10 Comprehensive testing of the developed software was conducted under real operating conditions. The scope of the bachelor’s qualification thesis includes 3 sections, figures, tables, sources in the reference list, and appendices. |
| URI (Уніфікований ідентифікатор ресурсу): | https://er.chdtu.edu.ua/handle/ChSTU/9761 |
| Розташовується у зібраннях: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Кобилка Дмитро Віталійович.pdf Restricted Access | 3.04 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«бакалавра»
освітній рівень
на тему: Програма ведення журналу навантаження викладача
Виконав: студент 4 курсу, групи ПЗ-2204
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Кобилка Д.В.
(прізвище та ініціали)
Керівник Салапатов В.І.
(прізвище та ініціали)
Рецензент Данилевський М.В.
(прізвище та ініціали)
Черкаси 2026
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
С. Голуб
«___» _______________ 2026 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Кобилки Дмитра Віталійовича
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Програма ведення журналу навантаження викладача
Керівник проекту (роботи) к.т.н., доцент Салапатов Володимир Іванович
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від «12» березня
2026року №56/03-03
2. Строк подання студентом проекту (роботи)
3. Вхідні дані до проекту (роботи)
Десктопна платформа .NET 8.0, мова програмування C# (версія 12), фреймворк графічних
інтерфейсів WPF (Windows Presentation Foundation), бібліотека стилізації
MaterialDesignThemes, вбудована локальна СКБД SQLite, ORM-фреймворк Entity Framework
Core (EF Core), бібліотека ClosedXML для роботи з документами формату OpenXML, системні
бібліотеки Microsoft.Win32 (SaveFileDialog),
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Розділ 1 Існуючі методи та засоби розв’язання поставлених завдань
Розділ 2 Впровадження результатів досліджень у практику проектування програмного
забезпечення інформаційних систем
Розділ 3 Розробка та тестування програмного забезпечення
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту):
Додаток А – специфікація. Додаток Б – Текст програми розробки. Додаток В – Інструкція
користувача. Додаток Г – Графічні матеріали
6. Консультанти розділів роботи
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
Дата видачі завдання 1.02.2025
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№
Назва етапів випускної роботи етапів випускної Примітки
п/п
роботи
1 Постановка задачі 1.02.2025 виконано
2 Підготовка завдання 10.02.2025 виконано
3 Погодження завдання 10.01.2026 виконано
4 Затвердження завдання 20.01.2026 виконано
Основна стадія 21.01.2026 виконано
1 Підбір матеріалів 15.02.2026 виконано
2 Аналіз шляхів вирішення поставленої задачі 1.03.2026 виконано
3 Розрахунок основних параметрів роботи 2.03.2026 виконано
4 Вибір кінцевого варіанту проектного рішення 10.04.2026 виконано
5 Оформлення первісної редакції роботи 20.04.2026 виконано
Заключна стадія 3.05.2026 виконано
1 Узгодження прийнятих проектних рішень з 15.05.2026 виконано
керівником
2 Оформлення пояснювальної записки роботи в 16.05.2026 виконано
кінцевій редакції
3 Попередній захист роботи 20.05.2026 виконано
4 Затвердження роботи 22.05.2026 виконано
5 Рецензування роботи 01.06.2026 виконано
6 Захист роботи 05.06.2026 виконано
Студент _____________________ Кобилка Д.В.
(підпис) (прізвище та ініціали)
Керівник проекту (роботи) _____________________ Салапатов В.І.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Кобилка Д.В., кваліфікаційна робота бакалавра на тему «ПРОГРАМНИЙ
КОМПЛЕКС "ЖУРНАЛ НАВАНТАЖЕННЯ ВИКЛАДАЧА"». Напрям підготовки
121 «Інженерія програмного забезпечення», ЧДТУ, Черкаси, 2026.
Мета виконання кваліфікаційної роботи бакалавра: проектування та
конструювання десктопного програмного забезпечення для автоматизованого
планування, оперативного обліку та аналізу індивідуального навчального
навантаження науково-педагогічних працівників закладу вищої освіти з
можливістю динамічного контролю та генерації звітності.
Завдання при проектуванні програмного забезпечення: провести аналіз
існуючих методів та засобів обліку навчального навантаження; визначити їх
переваги та недоліки; сформувати функціональні та нефункціональні вимоги до
програмного комплексу; розробити логічну та архітектурну структуру системи та
відобразити взаємодію її компонентів за допомогою UML-діаграм; обґрунтувати
вибір засобів реалізації; реалізувати модулі ведення нормативно-довідкової
інформації (довідники дисциплін та академічних груп); реалізувати підсистему
планування годин та електронний журнал обліку проведених занять; розробити
аналітичний модуль динамічного розрахунку статистики з автоматичним
виявленням недопрацювань та перепрацювань годин і їх колірною індикацією;
забезпечити експорт зведеної звітності у формат електронних таблиць MS Excel;
провести модульне, інтеграційне, системне та приймальне тестування розробленого
програмного забезпечення.
Об’єкт роботи: програмна реалізація інформаційної технології ведення
журналу навантаження викладача
Предмет розробки: процес програмної реалізації інформаційної технології
ведення журналу навантаження викладача
Вирішено наступні поставлені задачі:
1. Проведено аналіз предметної області та оцінку існуючих програмних
аналогів для автоматизації моніторингу навчального навантаження.
2 Формалізовано проблеми діючих алгоритмів обліку робочого часу та
виявлено технічні недоліки наявних рішень, що стало основою для
проектування нової системи.
3 Сформовано вимоги до програмного комплексу журналу навантаження
викладача.
4 Розроблено логічну та архітектурну структуру системи з використанням
UML-діаграм.
5 Спроектовано реляційну базу даних на основі підходу Code-First за
допомогою Entity Framework Core та розгорнуто локальну СКБД SQLite.
6 Реалізовано користувацький інтерфейс на базі технології WPF з
використанням бібліотеки MaterialDesignThemes.
7 Реалізовано підсистему оперативного обліку (електронний журнал занять)
та планування навантаження із жорсткою реляційною прив'язкою даних.
8 Реалізовано аналітичний модуль динамічного розрахунку статистики з
автоматичним виявленням перепрацювань/недопрацювань, розрахунком
прогресу та кольоровою семантичною індикацією.
9 Реалізовано модуль програмного експорту звітів у формат MS Excel за
допомогою ClosedXML із гнучким форматуванням і підсвічуванням
рядків відхилення від плану.
10 Проведено комплексне тестування розробленого програмного
забезпечення в умовах реальної експлуатації.
Обсяг кваліфікаційної роботи бакалавра – містить 3 розділи, рисунки,
таблиці, джерела в списку посилань, додатки.
Ключові слова: журнал навантаження, автоматизація обліку, десктопний
додаток, C#, .NET 8.0, WPF, Material Design, SQLite, Entity Framework Core,
ClosedXML, статистика, експорт Excel.
ANNOTATION
Kobylka D.V., bachelor’s qualification thesis on the topic “SOFTWARE COMPLEX
'TEACHER WORKLOAD JOURNAL'”. Field of study 121 “Software Engineering”,
ChSTU, Cherkasy, 2026.
The purpose of the bachelor’s qualification thesis is the design and development of
desktop software for automated planning, operational accounting, and analysis of the
individual teaching workload of faculty members in a higher education institution with
the capability of dynamic monitoring and report generation.
The tasks in software design are: to analyze existing analogues and methods for
tracking teaching workload; to determine their advantages and disadvantages; to
formulate functional and non-functional requirements for the software complex; to
develop the logical and architectural structure of the system and represent the interaction
of its components using UML diagrams; to justify the choice of implementation tools; to
implement master data reference modules (disciplines and academic groups directories);
to implement a hours planning subsystem and an electronic journal for tracking conducted
lessons; to develop an analytical module for real-time statistics calculation with automatic
detection of underworked and overworked hours and their color-coded indication; to
ensure the export of consolidated reports to MS Excel spreadsheet format; to conduct unit,
integration, system, and acceptance testing of the developed software.
Object of the work: software implementation of information technology for
maintaining a teacher workload journal.
Subject of the development: the process of software implementation of
information technology for maintaining a teacher workload journal.
The following tasks were solved:
1 Existing system analogues for monitoring and accounting of teaching workload
were analyzed.
2 The main problems of manual paper-based tracking of working hours and the
disadvantages of existing software solutions were identified.
3 The requirements for the teacher workload journal software complex were
formulated.
4 The logical and architectural structure of the system was developed using UML
diagrams.
5 A relational database was designed based on the Code-First approach using
Entity Framework Core, and a local SQLite DBMS was deployed.
6 A user interface was implemented based on WPF technology using the
MaterialDesignThemes library.
7 An operational accounting subsystem and workload planning with strict
relational data binding were implemented.
8 An analytical module for dynamic statistics calculation ("Statistics" module)
with automatic detection of overworking/underworking, progress calculation,
and color-coded semantic indication was implemented.
9 A module for programmatic export of reports to MS Excel format using
ClosedXML with flexible formatting and highlighting of rows deviating from
the plan was implemented.
10 Comprehensive testing of the developed software was conducted under real
operating conditions.
The scope of the bachelor’s qualification thesis includes 3 sections, figures, tables, sources
in the reference list, and appendices.
Keywords: teacher workload journal, accounting automation, desktop application,
C#, .NET 8.0, WPF, Material Design, SQLite, Entity Framework Core, ClosedXML,
statistics, Excel expo
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ ..................................................................... 6
ВСТУП ........................................................................................................................... 7
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ ................................................................................... 10
1.1 Актуальні проблеми, що виникають в процесі виконання завдань .............. 10
1.2 Методи та засоби, які вже використовуються для усунення проблем та
виконання завдань .................................................................................................... 11
1.3 Конкретизація завдань роботи .......................................................................... 14
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ ............................................................... 15
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ ............................................................................... 16
2.1. Моделювання предметної області ................................................................... 16
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області ................................................................................... 17
2.1.2. Елементи моделювання предметної області .......................................... 20
2.1.3. Робоча область моделювання .................................................................. 22
2.2. Формування та аналіз вимог ............................................................................ 23
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги ....................................................................................................................... 24
2.2.2 Формування вимог за допомогою діаграми прецедентів ...................... 26
2.3. Проектування логічної структури програмного комплексу ......................... 28
2.3.1. Діаграма класів .......................................................................................... 29
ЧДТУ 26. 2244.019 ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб. Кобилка Д.В. Літ. Лист Листів
Перевір. Салапатов В.І. Програма ведення журналу 4
Рецензент навантаження викладача
Н. Контр. ФІТІС, кафедра ПЗАС, ПЗ-2204
Затверд.
2.3.2. Діаграма пакетів ........................................................................................ 31
2.4. Архітектурне проектування ............................................................................. 32
2.4.1. Діаграма компонентів ............................................................................... 33
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ............................................................................................................... 34
2.5. Моделювання поведінки системи ................................................................... 36
2.5.1. Діаграма діяльності ................................................................................... 36
2.5.2. Діаграма послідовності ............................................................................ 39
2.5.3. Діаграма комунікації ................................................................................ 40
2.5.4. Діаграма скінченного автомату ............................................................... 42
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ ................................................................. 43
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ ...................................................................................................... 44
3.1 Розробка програмного комплексу .................................................................... 44
3.1.1 Обґрунтування вибору засобів реалізації ................................................ 45
3.1.2 Опис структурної (функціональної) схеми ............................................. 48
3.1.3 Опис логічної схеми системи ................................................................... 53
3.1.4 Розробка бази даних .................................................................................. 57
3.1.5 Розробка інтерфейсу користувача ............................................................ 60
3.1.6 Опис розробки програмних компонентів ................................................ 62
3.2 Тестування системи ........................................................................................... 65
3.2.1 Модульне тестування ................................................................................ 66
3.2.2 Інтеграційне тестування ............................................................................ 68
3.2.3 Системне тестування ................................................................................. 70
3.2.4 Приймальне тестування ................................................................................ 71
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ .............................................................. 79
ВИСНОВКИ ............................................................................................................... 81
ЧДТУ 26. 2244.019 ПЗ
Змн. Арк. № докум. Підпис Дата
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .............................................................. 83
ДОДАТКИ ................................................................................................................... 85
ЧДТУ 26. 2244.019 ПЗ
Змн. Арк. № докум. Підпис Дата
ЧДТУ 26. 2244.019 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
БД – База даних
ЗВО – Заклад вищої освіти
ІС – Інформаційна система
НПП – Науково-педагогічний працівник
ПЗ – Програмне забезпечення
ПЗАС – Програмне забезпечення автоматизованих систем (кафедра)
СКБД (СУБД) – Система керування базами даних
ЧДТУ – Черкаський державний технологічний університет
ACID – Atomicity, Consistency, Isolation, Durability (Атомарність, консистентність,
ізоляція, довговічність — набір властивостей транзакцій баз даних)
API – Application Programming Interface (Інтерфейс прикладного програмування)
CRUD – Create, Read, Update, Delete (Базові функції роботи з даними: створення,
читання, оновлення, видалення)
DTO – Data Transfer Object (Об'єкт передачі даних)
EF Core – Entity Framework Core (Фреймворк об'єктно-реляційного відображення
даних)
GUI – Graphical User Interface (Графічний інтерфейс користувача)
LINQ – Language Integrated Query (Мова інтегрованих запитів у середовищі .NET)
ORM – Object-Relational Mapping (Об'єктно-реляційне відображення баз даних)
UI – User Interface (Інтерфейс користувача)
UML – Unified Modeling Language (Уніфікована мова моделювання)
UX – User Experience (Досвід користувача)
WPF – Windows Presentation Foundation (Графічна підсистема для створення
десктопних додатків у .NET)
XAML – Extensible Application Markup Language (Розширювана мова розмітки
програм, що використовується у WPF)
6
ЧДТУ 26. 2244.019 ПЗ
ВСТУП
Актуальність теми: Ця робота належить спеціальності Інженерія
програмного забезпечення. Сучасний розвиток інформаційних технологій в
освітній сфері створює велику кількість можливостей для оптимізації рутинних
процесів, пов'язаних з організацією навчального процесу. Робота викладача вищого
навчального закладу супроводжується величезною кількістю паперової та звітної
документації, зокрема необхідністю постійного обліку виконаного академічного
навантаження (лекції, практичні, лабораторні заняття, консультації, перевірка робіт
тощо). У даних умовах ручне ведення журналів або використання
неспеціалізованих табличних редакторів призводить до втрати робочого часу,
ускладнює швидкий пошук потрібної інформації та підвищує ризик виникнення
помилок у розрахунках відпрацьованих годин.
Актуальність розробки програми ведення журналу навантаження викладача
зумовлена необхідністю автоматизації процесу обліку навчальної роботи. У
ручному режимі контролювати залишок запланованих годин та формувати зведені
звіти досить складно та незручно. Тому створення спеціалізованого програмного
інструменту, який дозволяє швидко вносити дані про проведені заняття,
автоматично підраховує загальну кількість вичитаних годин за різними видами
робіт та дисциплінами, дозволяє значно підвищити ефективність планування
робочого часу. Такий підхід сприяє швидкому доступу до статистики, допомагає
підтримувати документацію в актуальному стані та зменшує вплив людського
фактору під час підрахунку академічної успішності роботи викладача.
Розробка локального журналу навантаження також дозволяє структурувати
всі необхідні довідники (групи, дисципліни, види занять) в єдиній базі даних і
створити зручний інтерфейс для щоденного використання. У результаті це
забезпечує більш ефективний моніторинг виконання індивідуального плану
викладача та спрощує процес формування підсумкової звітності.
7
ЧДТУ 26. 2244.019 ПЗ
Мета розробки: Підвищення ефективності обліку та моніторингу
академічного навантаження шляхом розробки спеціалізованої програми, яка
автоматизує процеси фіксації проведених занять, підрахунку виконаних годин та
зберігання структурованої інформації про навчальний процес. Така система має
виступати як зручний інструмент повсякденної підтримки для викладача, надаючи
йому можливість оперативно контролювати виконання свого індивідуального
плану та мінімізувати час для роботи зі звітністю.
Завдання розробки:
1 Провести дослідження принципів планування та обліку академічного
навантаження у вищих навчальних закладах, проаналізувати вимоги до
ведення журналів.
2 Розробити архітектуру програмної системи та спроєктувати структуру
локальної бази даних для зберігання інформації про дисципліни, групи,
види занять та виконану роботу.
3 Розробити зручний користувацький інтерфейс для швидкого введення
даних про проведені пари та перегляду статистики.
4 Реалізувати алгоритми автоматичного підрахунку вичитаних годин та їх
порівняння із запланованим навантаженням.
5 Провести тестування розробленого програмного забезпечення, перевірити
коректність розрахунків і внести необхідні правки, щоб проєкт був
повністю готовий для практичного використання.
Об’єкт роботи: програмна реалізація інформаційної технології ведення
журналу навантаження викладача
Предмет розробки: процес програмної реалізації інформаційної технології
ведення журналу навантаження викладача
Методи проектування: під час розробки використано об'єктно-орієнтований
підхід до побудови програмної системи, що дозволяє розділити логіку роботи з
даними, бізнес-правила та інтерфейс користувача. Для реалізації програми
застосовано мову програмування C# та платформу .NET, що забезпечує високу
8
ЧДТУ 26. 2244.019 ПЗ
продуктивність та надійність десктопного додатка. Для організації зберігання даних
використано локальну реляційну базу даних (наприклад, SQLite), яка інтегрується
з програмою за допомогою технології ORM (Object-Relational Mapping), що
дозволяє зручно працювати з сутностями бази даних на рівні коду. Архітектура
програми побудована з урахуванням сучасних патернів проєктування для
забезпечення легкості підтримки та можливого подальшого розширення
функціоналу.
Практичне значення отриманих результатів: Розроблена програма
дозволить користувачу значно скоротити час на заповнення рутинної документації,
виключити математичні помилки при підрахунку годин, мінімізувати зусилля для
пошуку записів за минулі періоди та забезпечить постійний контроль над станом
виконання індивідуального плану навантаження.
Особистий внесок автора: у процесі виконання роботи автор самостійно
спроєктував, реалізував та протестував на практичних ситуаціях програмне
забезпечення ведення журналу навантаження.
9
ЧДТУ 26. 2244.019 ПЗ
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
У першому розділі буде розглянуто актуальні проблеми, що виникають під
час планування та обліку індивідуального навчального навантаження науково-
педагогічних працівників. Основну увагу приділено необхідності використання
спеціалізованого програмного забезпечення для автоматизованого ведення
журналів, оперативного обліку відпрацьованих годин та аналізу виконання
затвердженого плану. Також буде проведено аналіз існуючих рішень, визначено їх
переваги й недоліки та сформовано основні завдання для подальшої розробки
програмного комплексу.
1.1 Актуальні проблеми, що виникають в процесі виконання завдань
Організація навчального процесу у вищих навчальних закладах вимагає від
викладача не лише якісної подачі матеріалу, але й ретельного ведення документації.
Викладачі стикаються з проблемою оперативного обліку виконаного академічного
навантаження, такого як: прочитані лекції, проведені практичні та лабораторні
заняття, прийняті іспити та заліки, а також керівництво курсовими й дипломними
роботами.
Основною проблемою є неможливість ефективного ручного контролю за
виконанням індивідуального плану. Для відслідковування відпрацьованих годин
необхідно постійно звіряти розклад, робочі програми дисциплін та списки
студентів, що потребує значних часових витрат. Крім того, людський фактор
(втома, неуважність) часто призводить до математичних помилок при підрахунку
сумарного навантаження, що може вплинути на оплату праці або звітність перед
кафедрою.
Ще однією проблемою є відсутність зручного, локального та
спеціалізованого інструменту. Існуючі загальноуніверситетські системи часто є
10
ЧДТУ 26. 2244.019 ПЗ
перевантаженими, вимагають постійного підключення до мережі Інтернет або
мають незручний інтерфейс для щоденного використання звичайним викладачем.
Таким чином, актуальною задачею є створення персонального програмного
засобу, який дозволить автоматизувати процес ведення журналу навантаження,
забезпечить безпомилковий підрахунок годин та швидке формування звітів.
1.2 Методи та засоби, які вже використовуються для усунення проблем та
виконання завдань
Щоб визначити функціональні та нефункціональні вимоги до
розроблюваного програмного продукту, було проаналізовано існуючі підходи та
інструменти, які найчастіше використовуються викладачами для обліку
навантаження.
На рисунку показаний класичний метод – використання паперових журналів
та роздрукованих індивідуальних планів.
Рисунок 1.2 – Паперовий журнал обліку навантаження
11
ЧДТУ 26. 2244.019 ПЗ
– Особливості використання паперових носіїв:
– фіксація дати, теми заняття та кількості годин відбувається повністю
вручну;
– періодичний ручний підрахунок підсумків за семестр або рік.
Переваги паперових журналів:
– повна незалежність від комп'ютерної техніки та електроенергії;
– простота освоєння (не потребує комп'ютерної грамотності).
Недоліки паперових журналів:
– висока ймовірність помилок при математичному підрахунку загальної
кількості годин;
– складність внесення змін (виправлення виглядають неохайно, часто
доводиться переписувати сторінки);
– неможливість швидкого пошуку потрібної інформації за минулі місяці або
роки.
На рисунку показано приклад використання табличного процесора
(наприклад, Microsoft Excel або Google Sheets), що є найпопулярнішим кроком до
автоматизації.
Рисунок 1.3 – Облік навантаження у Microsoft Excel
Порівняно з попереднім методом, тут вже значно простіше працювати з
числами, використовуються формули для підрахунку та є можливість
форматування даних.
Особливості використання електронних таблиць:
– організація даних у вигляді рядків та стовпців з можливістю сортування;
12
ЧДТУ 26. 2244.019 ПЗ
– використання вбудованих формул для автоматичного підрахунку сум.
Переваги електронних таблиць:
– автоматизація математичних розрахунків, що зменшує кількість помилок;
– можливість швидкого форматування та підготовки документа до друку;
– швидкий пошук даних за допомогою вбудованих функцій пошуку.
Недоліки електронних таблиць:
– відсутність контролю цілісності даних (користувач може випадково
видалити клітинку з важливою формулою);
– відсутність зручного інтерфейсу для додавання записів (доводиться
вручну прокручувати великі масиви даних);
– відсутність автоматичних візуальних попереджень (наприклад, про
перевищення плану годин за конкретною дисципліною).
На рисунку показаний інтерфейс комплексної університетської системи
управління навчальним процесом (СУНП).
Рисунок 1.4 – Інтерфейс університетської СУНП
Це глобальний підхід, який охоплює весь заклад освіти і має зовсім іншу
механіку порівняно з персональними таблицями.
Особливості використання комплексних СУНП:
13
ЧДТУ 26. 2244.019 ПЗ
– централізована база даних для всього університету;
– жорстке розмежування прав доступу між деканатом та викладачами.
Переваги комплексних СУНП:
– наявність єдиної бази даних студентів, без потреби вводити їх самостійно;
– автоматичне формування базового навантаження адміністрацією закладу.
Недоліки комплексних СУНП:
– повна залежність від наявності стабільного інтернет-з'єднання та
працездатності центрального сервера;
– часто перевантажений та неінтуїтивний інтерфейс, що робить його
незручним для щоденного швидкого використання;
– неможливість гнучкого налаштування або ведення особистих,
неофіційних нотаток до пар.
1.3 Конкретизація завдань роботи
На основі проведеного аналізу існуючих рішень було визначено основні
вимоги до фінального продукту.
Майбутня програма ведення журналу навантаження повинна об’єднувати
надійність спеціалізованого програмного забезпечення зі зручністю локального
інструменту. У програмі повинні бути такі модулі:
– модуль ведення довідників (Дисципліни, Академічні групи, Види занять);
– модуль планування для введення загального плану годин;
– електронний журнал (форма для фіксування проведених занять);
– модуль статистики та автоматичного порівняння запланованих і фактично
вичитаних годин із візуальним сповіщенням;
– модуль експорту даних для генерації звітів та друку.
Також, програма повинна відповідати таким вимогам:
– висока швидкість роботи та збереження даних;
– незалежна робота в режимі офлайн (локальна база даних);
– інтуїтивно зрозумілий та неперевантажений користувацький інтерфейс;
14
ЧДТУ 26. 2244.019 ПЗ
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ
У першому розділі було розглянуто актуальні проблеми, що виникають під
час планування та обліку індивідуального навчального навантаження науково-
педагогічних працівників, а також проаналізовано існуючі методи та програмні
засоби, які використовуються для моніторингу відпрацьованого робочого часу.
Було встановлено, що сучасний освітній процес у закладах вищої освіти
характеризується великою кількістю навчальних дисциплін, різноманітністю видів
занять та постійними змінами у контингенті студентських груп. Через це ручний
або напівформалізований облік навантаження є малоефективним, оскільки
потребує значних часових витрат, постійної уваги викладача та регулярного
математичного перерахунку годин.
Користувачі стикаються з потребою швидкого й безпомилкового виявлення
таких показників, як загальний обсяг вичитаних годин, наявність недопрацювань
або перепрацювань відносно плану та поточний залишок часу за окремими
дисциплінами. Такі дані мають важливе значення для підготовки кафедральної
звітності та аналізу ефективності роботи, тому своєчасне та наочне інформування
користувача про стан виконання плану є однією з ключових вимог до майбутнього
програмного продукту.
Було проаналізовано декілька існуючих рішень, зокрема традиційний
паперовий облік, ведення журналів за допомогою електронних таблиць MS Excel та
використання глобальних університетських інформаційних систем. Аналіз показав,
що кожен із цих інструментів має власні переваги та недоліки.
Отже, у першому розділі було обґрунтовано актуальність розробки
автономного десктопного програмного комплексу «Журнал навантаження
викладача», розглянуто існуючі аналоги, визначено їх переваги та недоліки, а також
сформовано основні напрями подальшої розробки.
15
ЧДТУ 26. 2244.019 ПЗ
РОЗДІЛ 2. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
У другому розділі буде виконано проектування програмного забезпечення
десктопного програмного комплексу «Журнал навантаження викладача». Основну
увагу приділено моделюванню предметної області, формуванню функціональних і
нефункціональних вимог та визначенню логічної структури програмного
комплексу. Також у розділі буде побудовано UML-діаграми, які відображають
архітектуру системи, взаємодію її компонентів та поведінку підсистем додатка під
час планування й обліку годин навчального навантаження.
2.1. Моделювання предметної області
Моделювання предметної області є важливим етапом проектування
програмного забезпечення, оскільки дозволяє визначити основні об’єкти, процеси
та зв’язки, які повинні бути враховані під час розробки системи. У межах даної
кваліфікаційної роботи предметна область пов’язана з автоматизованим
плануванням, оперативним транзакційним обліком проведених занять та
аналітичним моніторингом виконання індивідуального навчального навантаження
науково-педагогічних працівників закладу вищої освіти.
Основною метою моделювання є опис логіки роботи програмного комплексу
«Журнал навантаження викладача» та визначення компонентів, які беруть участь у
процесі обробки інформації. До таких компонентів належать користувач (викладач
або відповідальний співробітник кафедри), підсистема автентифікації користувачів,
нормативно-довідкові модулі (довідники дисциплін та академічних груп),
підсистема планування годин, електронний журнал обліку проведених занять,
аналітичний модуль обчислення статистики виконання плану в режимі реального
часу та підсистема автоматизованої генерації звітності.
16
ЧДТУ 26. 2244.019 ПЗ
У процесі моделювання предметної області необхідно визначити, які саме
дані надходять до системи (затверджені обсяги годин, відомості про вичитані теми
та групи), як вони обробляються й консолідуються реляційними зв'язками, за якими
критеріями обчислюються відхилення від плану (недопрацювання чи
перепрацювання годин) та в який спосіб аналітичні результати і готові звітні форми
відображаються в інтерфейсі або експортуються користувачу. Це дозволяє
сформувати загальне уявлення про роботу десктопного програмного комплексу ще
до етапу його безпосередньої реалізації.
Таким чином, моделювання предметної області створює надійну основу для
подальшого формування специфікації вимог, побудови повного комплексу UML-
діаграм, проектування логічної структури й архітектури локальної бази даних, а
також безпосередньої розробки програмних компонентів журналу навантаження.
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметною областю дослідження є процес планування та обліку
навчального навантаження викладача закладу вищої освіти. Основним завданням у
цій сфері є моніторинг виконання навчального плану, фіксація проведених занять
та формування аналітичної звітності про фактично відпрацьовані години.
На сьогоднішній день ручний облік у паперових журналах або розрізнених
таблицях Excel є неефективним через складність оперативного аналізу даних, ризик
втрати інформації та великі трудовитрати на підрахунок підсумкових показників.
Розроблювана система являє собою десктопний додаток «Журнал навантаження
викладача», який автоматизує ці процеси.
У структурі предметної області виділено такі ключові компоненти:
– Джерела вхідних даних: навчальні плани, перелік дисциплін та списки
студентських груп.
– Модуль планування: підсистема для формування нормативного
навантаження на семестр/рік.
17
ЧДТУ 26. 2244.019 ПЗ
– Модуль обліку (Журнал): інтерфейс для щоденної фіксації виконаної
роботи (дати, теми, фактичні години).
– Аналітичний модуль: алгоритми розрахунку залишку годин, виявлення
перепрацювань або недопрацювань.
– Система авторизації: механізм розмежування доступу та персоналізації
даних викладача.
– Модуль експорту: генератор звітів у форматі MS Excel.
Взаємодія компонентів побудована за принципом послідовної обробки: після
авторизації викладач формує план навантаження, на основі якого заповнюється
журнал. Система автоматично співставляє ці дані, відображаючи актуальну
статистику в реальному часі.
Для забезпечення однозначності термінології розроблено словник предметної
області (таблиця 2.1).
Таблиця 2.1
Словник предметної області
Назва
№ Назва (укр.) Опис
(англ.)
Користувач User / Особа, яка здійснює облік власного
1
(Викладач) Teacher навантаження.
Навчальний предмет, закріплений за
2 Дисципліна Discipline
викладачем.
План Workload Перелік запланованих годин за видами
3
навантаження Plan занять для конкретних груп.
18
ЧДТУ 26. 2244.019 ПЗ
Продовження таблиці 2.1
Запис Journal Факт проведення заняття з описом теми та
4
журналу Record дати.
Навчальна Колектив студентів, для яких проводиться
5 Student Group
група заняття.
Категорія навчальної роботи (лекція,
6 Вид заняття Lesson Type
практичне, лабораторне).
Агреговані дані про виконання плану у
7 Статистика Statistics
відсотковому та часовому еквіваленті.
Сховище (SQLite) для довгострокового
8 База даних Database
зберігання інформації.
Процес перевірки прав доступу користувача
9 Авторизація Authentication
до системи.
Програмне формування документу Excel на
10 Експорт звіту Report Export
основі даних БД.
19
ЧДТУ 26. 2244.019 ПЗ
Модель предметної області
Модель предметної області відображає взаємодію користувача, внутрішніх
компонентів системи та локального сховища даних. Користувач (викладач або
відповідальний співробітник кафедри) взаємодіє з десктопним додатком через
графічний інтерфейс користувача, вносячи нормативно-довідкові відомості,
формуючи плани навантаження та фіксуючи проведені заняття в електронному
журналі. Система, у свою чергу, взаємодіє з локальною реляційною базою даних
SQLite, забезпечуючи надійне збереження, зчитування та модифікацію інформації
з дотриманням реляційної цілісності. Внесені відомості обробляються
обчислювальним ядром аналітичного модуля, який виконує агрегацію годин і
визначає стан виконання квот навантаження. У випадку виявлення відхилень
(недопрацювань або перепрацювань годин відносно початкового плану) система
автоматично перераховує відсоток прогресу та здійснює динамічну колірну
індикацію відповідних елементів інтерфейсу, а також передає сформовані масиви
даних до підсистеми експорту звітів у формат MS Excel. Таким чином, програмний
комплекс виступає ефективним інструментом автоматизації обліку навчального
навантаження, мінімізуючи людський фактор і звільняючи науково-педагогічного
працівника від рутинних ручних розрахунків.
2.1.2. Елементи моделювання предметної області
Для формалізації вимог та проектування архітектури системи обрано
уніфіковану мову моделювання UML (Unified Modeling Language). Використання
UML дозволяє візуалізувати логіку роботи програми, структуру бази даних та
сценарії взаємодії користувача з інтерфейсом.
Основними графічними елементами, що будуть використані при побудові діаграм
у наступних підрозділах, є стандартні символи UML, наведені у таблиці 2.2.
20
ЧДТУ 26. 2244.019 ПЗ
Таблиця 2.2
Елементи UML-моделювання, використані у проекті
Графічний
Назва елемента Опис
символ
Роль користувача (Викладач), що
![Актор] Актор (Actor)
взаємодіє з функціями системи.
Варіант
Окрема функція системи (напр., «Додати
![Прецедент] використання
запис у журнал»).
(Use Case)
Опис сутності (Дисципліна, Користувач)
![Клас] Клас (Class)
та її властивостей.
Відображення логічного зв’язку між
![Зв'язок] Асоціація
об’єктами або актором та функцією.
Залежність Вказує, що зміни в одному елементі
![Залежність]
(Dependency) можуть вплинути на інший.
Групування модулів (напр., моделі даних,
![Пакет] Пакет (Package)
інтерфейси користувача).
Відображає етапи життєвого циклу об’єкта
![Стан] Стан (State)
(напр., авторизований/неавторизований).
Повідомлення Передача виклику методу або даних між
![Повідомлення]
(Message) компонентами на діаграмі послідовності.
21
ЧДТУ 26. 2244.019 ПЗ
2.1.3. Робоча область моделювання
У якості робочої області моделювання розглядається програмна система у
вигляді десктопного додатку (WPF), призначена для автоматизованого планування,
обліку та аналізу навчального навантаження викладача. Робота системи
починається з авторизації користувача та завантаження його персональних даних
(переліку дисциплін, навчальних груп, затвердженого плану годин) з локальної бази
даних SQLite.
Після отримання доступу до системи користувач взаємодіє з модулями
обробки інформації, де кожен модуль відповідає за окремий бізнес-процес.
Зокрема, система виконує:
– управління довідниками (додавання, редагування та видалення
навчальних дисциплін);
– формування плану навантаження (розподіл годин між лекційними,
практичними та лабораторними заняттями для конкретних груп);
– ведення електронного журналу (фіксація дати, теми та кількості фактично
відпрацьованих годин);
– автоматичний розрахунок статистики виконання плану (порівняння
запланованих та проведених годин, виявлення перепрацювань або
недопрацювань);
– експорт аналітичних даних у формат MS Excel для подальшого друку або
подання на кафедру.
На основі внесених до журналу записів система в режимі реального часу
перераховує залишок годин та оновлює візуальні графіки (дашборди). Таким
чином, робоча область моделювання охоплює повний цикл документообігу
викладача: від первинного внесення нормативних показників до автоматизованої
генерації підсумкової звітності.
22
ЧДТУ 26. 2244.019 ПЗ
2.2. Формування та аналіз вимог
Формування та аналіз вимог є одним із ключових етапів проектування
програмного забезпечення, оскільки саме на цьому етапі визначається, які функції
повинна виконувати система та яким вимогам вона має відповідати під час роботи.
Для десктопного програмного комплексу «Журнал навантаження викладача»
вимоги формуються на основі аналізу предметної області, існуючих аналогів та
практичних потреб користувача (науково-педагогічного працівника).
Основною потребою користувача є зручний, безпомилковий та оперативний
облік відпрацьованого навчального часу, який складно ефективно контролювати
вручну через велику кількість дисциплін, академічних груп та різновидів занять.
Тому розроблювана система повинна забезпечувати зручне введення планових
нормативів та фіксацію фактично проведених пар, автоматично аналізувати ці дані
в режимі реального часу, обчислювати залишки годин і відхилення від плану, а
також формувати зведену звітність із можливістю автоматизованого експорту у
формат MS Excel.
У процесі аналізу вимог важливо врахувати не лише функціональні
можливості системи, а й якісні характеристики її роботи. Програмний комплекс
повинен працювати стабільно та повністю автономно без потреби у складному
налаштуванні серверів чи підключенні до мережі Інтернет. Система повинна мати
інтуїтивно зрозумілий та ергономічний інтерфейс, швидко обробляти дані за
допомогою оптимізованих запитів та забезпечувати надійне збереження реляційної
інформації. Також система має бути побудована за модульним принципом із чітким
розділенням графічного представлення та бізнес-логіки, щоб у майбутньому можна
було легко додавати нові аналітичні функції або формати звітів без повної
перебудови програмного забезпечення.
Таким чином, формування та аналіз вимог дозволяють визначити основні
функції майбутньої системи, її обмеження, очікувану поведінку та критерії якості.
На основі цих вимог у подальших підрозділах буде уточнено первинні й детальні
23
ЧДТУ 26. 2244.019 ПЗ
вимоги, вимоги замовника і розробника, а також функціональні та нефункціональні
вимоги до програмного комплексу.
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
Формування вимог є одним із ключових етапів розробки програмного
забезпечення, оскільки саме на цьому етапі визначається функціональність
системи, її поведінка та обмеження. Вимоги до програмного забезпечення
формуються на основі аналізу предметної області, а також дослідження існуючих
рішень, які були розглянуті у першому розділі. Вони відображають потреби
користувача та визначають, які функції повинна виконувати система. Процес
формування вимог включає в себе визначення первинних та детальних вимог, а
також розподіл їх на функціональні та нефункціональні.
Первинні і детальні вимоги:
Основною первинною вимогою до розроблюваної системи є створення
десктопного програмного засобу для автоматизованого планування, оперативного
обліку та аналізу індивідуального навчального навантаження викладача закладу
вищої освіти. Система повинна забезпечувати зручне введення нормативних даних,
безперервний та безпомилковий перерахунок відпрацьованих годин у режимі
реального часу, порівняння їх із затвердженим планом та формування зведеної
звітності. Детальні вимоги розробника конкретизують функціональність системи та
визначають її внутрішню логіку.
До детальних вимог можна віднести: – можливість ведення нормативно-
довідкової інформації (довідників дисциплін та академічних груп); – можливість
створення планів навантаження із зазначенням типу заняття та кількості годин; –
можливість щоденної фіксації проведених занять в електронному журналі із
жорсткою реляційною прив'язкою до плану; – можливість динамічного розрахунку
аналітичної статистики з автоматичним виявленням недопрацювань або
24
ЧДТУ 26. 2244.019 ПЗ
перепрацювань годин; – можливість автоматизованого експорту зведених даних у
формат електронних таблиць MS Excel; – можливість повністю автономної роботи
системи без підключення до мережі Інтернет із використанням локальної бази
даних.
Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
Вимоги до програмного забезпечення формуються з урахуванням потреб
замовника (науково-педагогічного працівника) та архітектурних можливостей
розробника.
Замовник (викладач) очікує отримати програмний продукт, який:
суттєво скорочує час на підрахунок відпрацьованих годин у кінці семестру;
– унеможливлює математичні помилки при зведенні статистики;
– дозволяє швидко знаходити інформацію про проведені заняття за минулі
місяці;
– має сучасний, приємний дизайн, що не перевантажує зір;
– працює автономно на робочому ноутбуці.
З точки зору розробника система повинна:
– бути побудована з використанням сучасного фреймворку (WPF) та
патерну проектування, що дозволяє легко оновлювати інтерфейс;
– використовувати ORM (Entity Framework Core) для безпечної та
структурованої взаємодії з базою даних;
– мати реляційну структуру бази даних (SQLite), що забезпечує цілісність
інформації (наприклад, каскадне видалення записів журналу при
видаленні дисципліни);
– забезпечувати обробку виключень (валідацію вводу), щоб програма не
"падала" при некоректних діях користувача.
Функціональні вимоги визначають безпосередні можливості системи:
– авторизація та управління профілем користувача (зміна логіну/паролю);
– додавання та редагування довідників (Дисципліни, Групи);
25
ЧДТУ 26. 2244.019 ПЗ
– створення записів у плані навантаження із зазначенням нормативної
кількості годин;
– ведення журналу фактично проведених занять із зазначенням дати та
теми;
– автоматичне обчислення залишку годин (різниця між планом та фактом);
– генерація зведеної таблиці статистики;
– експорт згенерованої статистики у файл формату .xlsx;
– перемикання між світлою та темною темами інтерфейсу.
Нефункціональні вимоги визначають характеристики роботи системи та
обмеження:
– операційна система: Windows 10/11;
– платформа: .NET 8.0 (або вище);
– час відгуку системи при перемиканні між вкладками не повинен
перевищувати 1 секунду;
– портативність бази даних (вся інформація має зберігатися в одному
локальному файлі .db);
– висока надійність збереження даних у разі раптового вимкнення живлення
комп'ютера;
– ергономічність графічного інтерфейсу, що відповідає стандартам Material
Design.
2.2.2 Формування вимог за допомогою діаграми прецедентів
Для візуалізації та формалізації функціональних вимог до розроблюваної
системи використовується діаграма прецедентів (Use Case Diagram) мови
моделювання UML. Цей інструмент дозволяє не лише відобразити взаємодію між
зовнішніми користувачами (акторами) та функціональними можливостями
програмного комплексу, але й чітко окреслити межі системи. Діаграма дає
можливість наочно представити всі доступні сценарії роботи, визначити
послідовність дій для досягнення конкретної бізнес-цілі та виявити приховані
26
ЧДТУ 26. 2244.019 ПЗ
залежності між окремими програмними модулями ще на етапі архітектурного
проектування.
У розроблюваній системі «Журнал навантаження викладача» виділено одну
основну дійову особу (актора) — Викладача. Зважаючи на обране архітектурне
рішення реалізувати програму як локальний десктопний додаток без клієнт-
серверного поділу ролей, цей користувач поєднує в собі як функції кінцевого
споживача інформації, так і функції адміністратора системи. Це означає, що
викладач має повний одноосібний контроль над життєвим циклом даних,
починаючи від їх первинного введення і закінчуючи генерацією підсумкової
звітності.
Основні варіанти використання системи включають:
1 Авторизацію в системі (перевірка логіну та паролю).
2 Управління профілем (зміна персональних даних та теми інтерфейсу).
3 Управління довідниками (додавання, редагування, видалення дисциплін
та груп).
4 Формування плану навантаження (визначення кількості нормативних
годин).
5 Ведення журналу (фіксація проведених занять).
6 Перегляд статистики (аналіз виконання плану).
7 Експорт даних (генерація звітів у форматі Excel).
Окремі прецеденти пов'язані між собою відношенням включення
(<<include>>). Наприклад, прецедент «Ведення журналу» обов'язково включає
перевірку наявності записів у базі даних, а сам процес роботи з системою
неможливий без успішного проходження прецеденту «Авторизація».
27
ЧДТУ 26. 2244.019 ПЗ
Рисунок 2.3 — Діаграма прецедентів системи обліку навантаження викладача
2.3. Проектування логічної структури програмного комплексу
На цьому етапі визначається логічна структура програмного комплексу, його
основні складові частини та взаємозв’язки між ними. Для розроблюваного
десктопного додатка «Журнал навантаження викладача» логічна структура повинна
відображати поділ системи на окремі функціональні модулі, кожен з яких
відповідає за обробку конкретного етапу життєвого циклу обліку робочого часу.
У межах програмного комплексу передбачено декілька основних модулів:
модуль ведення нормативно-довідкової інформації, модуль планування
навантаження, модуль оперативного обліку (електронний журнал) та модуль
аналітики й експорту. Модулі довідників та планування забезпечують введення
початкових даних щодо дисциплін, академічних груп та виділених нормативних
28
ЧДТУ 26. 2244.019 ПЗ
годин. Модуль електронного журналу фіксує фактично проведені заняття із
жорсткою прив'язкою до плану. Аналітичний модуль, у свою чергу, отримує ці дані
з локальної бази даних SQLite, динамічно обчислює залишки годин, визначає
наявність перепрацювань чи недопрацювань та формує візуальні індикатори
прогресу і зведені звіти у форматі MS Excel.
Кожен модуль має власну логіку взаємодії з користувачем через графічний
інтерфейс WPF, валідації введених даних та обміну інформацією з рівнем доступу
до даних за допомогою Entity Framework Core. Такий підхід забезпечує чітке
логічне розділення функціональності (відокремлення представлення від бізнес-
логіки), спрощує модульне та інтеграційне тестування окремих частин системи та
дозволяє в майбутньому розширювати програмний комплекс новими аналітичними
інструментами або форматами звітів без повної перебудови архітектури.
Отже, логічна структура програмного комплексу базується на модульному
принципі, за якого кожна підсистема виконує свою окрему задачу, але всі модулі
об'єднані спільною загальною метою — забезпеченням зручного, безпомилкового
та автоматизованого процесу планування, транзакційного обліку та контролю
індивідуального навчального навантаження науково-педагогічного працівника.
2.3.1. Діаграма класів
Діаграма класів використовується для відображення статичної структур
системи, її основних сутностей, їх атрибутів, методів та реляційних зв’язків між
ними. У розроблюваній системі діаграма класів відображає архітектуру бази даних
та предметної області.
Основними класами (моделями) є:
– User — зберігає облікові дані викладача.
– Discipline — описує навчальну дисципліну.
– StudentGroup — описує студентську групу.
29
ЧДТУ 26. 2244.019 ПЗ
– WorkloadPlan — об'єднує дисципліну, групу, тип заняття та нормативні
години.
– JournalRecord — фіксує факт проведення заняття (прив'язується до
плану).
– AppDbContext — контекст бази даних, що керує взаємодією між
моделями та SQLite.
Між класами встановлено відношення асоціації та композиції (наприклад,
один план навантаження може мати багато записів у журналі — зв'язок 1 до
багатьох).
Рисунок 2.4 — Діаграма класів системи обліку навантаження викладача
30
ЧДТУ 26. 2244.019 ПЗ
2.3.2. Діаграма пакетів
Діаграма пакетів використовується для відображення логічного групування
класів і компонентів системи в окремі функціональні частини. Вона дозволяє
показати внутрішню організацію програмного комплексу та взаємозв’язки між його
підсистемами.
Оскільки розроблювана система «Журнал навантаження викладача»
побудована з використанням об'єктно-орієнтованого підходу мови C# та
фреймворку WPF, діаграма пакетів відображає поділ проекту на простори імен
(namespaces). Це дозволяє зробити структуру коду більш зрозумілою, спрощує
реалізацію, тестування та подальше масштабування програмного продукту.
Рисунок 2.5 — Діаграма пакетів системи обліку навантаження викладача
У структурі розроблюваної системи виділено такі основні пакети:
– Пакет Views (Інтерфейс користувача): містить усі XAML-файли та
файли коду (code-behind), що відповідають за візуальне відображення
сторінок (Дашборд, Журнал, Налаштування тощо).
– Пакет Models (Моделі даних): містить класи, які описують сутності
предметної області (Викладач, Дисципліна, Запис журналу).
31
ЧДТУ 26. 2244.019 ПЗ
– Пакет Data (Доступ до даних): забезпечує взаємодію з базою даних,
містить контекст бази даних (AppDbContext) та класи для управління
сесією користувача.
– Пакет зовнішніх бібліотек (NuGet Packages): включає сторонні
залежності, такі як MaterialDesignThemes (для побудови сучасного
інтерфейсу) та Microsoft.EntityFrameworkCore (для роботи з
базою даних).
– Головний пакет системи (App): координує роботу всіх інших пакетів,
містить точку входу в програму та налаштування глобальних ресурсів.
Отже, діаграма пакетів дозволяє відобразити загальну модульну структуру
додатку та логіку взаємодії між відокремленими рівнями архітектури (дані, логіка,
інтерфейс).
2.4. Архітектурне проектування
Архітектурне проектування програмного забезпечення передбачає
визначення основних компонентів системи, способів їх взаємодії та принципів
організації програмної логіки. Для програмного комплексу «Журнал навантаження
викладача» архітектура повинна забезпечувати швидке та зручне введення
нормативно-довідкових даних, оперативний облік проведених занять, транзакційне
збереження інформації у локальній базі даних, а також динамічне обчислення
статистики та експорт зведеної звітності у форматі MS Excel.
Розроблювана система побудована за багаторівневим (шаруватим)
модульним принципом. Основними функціональними частинами є шар графічного
представлення (UI), шар бізнес-логіки та аналітики (BLL), а також шар доступу до
даних (DAL). Кожен модуль має власну зону відповідальності: взаємодія з
користувачем, агрегація відпрацьованих годин або реляційний мапінг об'єктів у
базу даних. Такий підхід дозволяє чітко розділити функціональність системи на
незалежні компоненти та спростити подальше супроводження й розширення
програмного комплексу.
32
ЧДТУ 26. 2244.019 ПЗ
Шар представлення, побудований на базі технології WPF, взаємодіє з
користувачем, приймаючи дані про вичитані години та теми занять. Шар доступу
до даних використовує технологію Entity Framework Core для взаємодії з локальною
СКБД SQLite, забезпечуючи виконання транзакційних операцій (CRUD) та
підтримку реляційної цілісності бази даних. Аналітичне ядро (модуль статистики)
отримує збережені дані, порівнює фактично відпрацьовані години із запланованим
навантаженням та динамічно обчислює відхилення (залишок або перепрацювання)
за допомогою запитів LINQ.
Після обробки даних обчислювальне ядро передає результати до інтерфейсу
користувача для візуалізації у вигляді прогрес-барів та колірних індикаторів
статусів виконання плану. Крім того, архітектурою передбачено модуль інтеграції,
який взаємодіє з бібліотекою ClosedXML. Цей модуль забезпечує автоматизоване
формування структурованого файлу звіту у форматі OpenXML (.xlsx),
форматування комірок та збереження готового документа на локальний диск
комп'ютера викладача.
2.4.1. Діаграма компонентів
Діаграма компонентів використовується для відображення фізичних
програмних частин системи (виконуваних файлів, бібліотек, баз даних) та зв’язків
між ними. Вона дозволяє показати, як логічна структура, описана на попередніх
етапах, перетворюється на реальні файли на комп'ютері користувача.
33
ЧДТУ 26. 2244.019 ПЗ
Рисунок 2.6 — Діаграма компонентів
У програмному комплексі виділено такі фізичні компоненти:
– Головний виконуваний файл (TeacherWorkloadJournal.exe):
основний компонент системи (десктопний додаток), який запускається
користувачем і містить усю бізнес-логіку та графічний інтерфейс.
– Локальна база даних (workload.db): фізичний файл формату SQLite,
який зберігається на диску комп'ютера і забезпечує надійне збереження
всіх записів, довідників та налаштувань профілю викладача.
– ORM-компонент (Entity Framework Core): набір динамічних
бібліотек (.dll), що виконують роль прошарку між об'єктно-орієнтованим
кодом програми та реляційною базою даних, автоматично генеруючи
SQL-запити.
– Компонент інтерфейсу (Material Design WPF): бібліотека, що
відповідає за відмальовування тіней, анімацій, іконок та інших елементів
сучасного дизайну.
– Компонент генерації звітів: вбудований модуль, який відповідає за
формування та збереження підсумкової статистики у вигляді зовнішнього
файлу формату Excel (.xlsx).
Діаграма компонентів дозволяє відобразити архітектурну побудову
програмного комплексу типу "товстий клієнт" (fat client), де обробка даних та їх
збереження відбуваються безпосередньо на локальному комп'ютері викладача без
необхідності підключення до мережевих серверів.
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Діаграма розгортання (Deployment Diagram) використовується для
відображення фізичної топології системи, розміщення програмних компонентів на
апаратних вузлах та показання шляхів комунікації між ними. Для системи «Журнал
34
ЧДТУ 26. 2244.019 ПЗ
навантаження викладача» діаграма розгортання є відносно простою, оскільки
архітектура передбачає роботу в режимі автономного десктопного додатку без
жорсткої прив'язки до зовнішніх серверів баз даних чи веб-сервісів.
Рисунок 2.7 — Діаграма розгортання системи обліку навантаження викладача
У розроблюваній системі виділено один основний фізичний вузол:
– Персональний комп'ютер викладача (Робоча станція): апаратний засіб
під управлінням ОС Windows, на якому розгортається вся система.
Всередині цього вузла виділяється середовище виконання (Execution
Environment) — .NET 8.0 Runtime, яке є необхідним для запуску WPF-
додатку.
На цьому вузлі розміщуються такі компоненти:
– Виконуваний файл додатку (.exe), що містить скомпільований код
інтерфейсу та бізнес-логіки.
35
ЧДТУ 26. 2244.019 ПЗ
– Файл локальної бази даних (workload.db), до якого звертається
програма за допомогою технології Entity Framework Core.
– Файлова система ОС, куди додаток має права записувати згенеровані звіти
(.xlsx).
У процесі розгортання системи викладач встановлює (або просто копіює)
папку з програмою на свій робочий або домашній комп'ютер. Уся взаємодія (від
авторизації до генерації звітів) відбувається локально, що гарантує працездатність
програми навіть за відсутності підключення до мережі Інтернет та забезпечує
високий рівень конфіденційності персональних даних.
2.5. Моделювання поведінки системи
Моделювання поведінки системи відображає динамічний аспект її
функціонування — послідовність дій, які виконує програмний комплекс у процесі
своєї роботи, а також показує логіку прийняття рішень під час взаємодії з
користувачем. Для «Журналу навантаження викладача» моделювання поведінки є
важливим етапом, оскільки система має чіткий бізнес-процес: від первинного
внесення нормативних планів до щоденної фіксації проведених занять та
автоматичного розрахунку підсумків.
2.5.1. Діаграма діяльності
Для деталізації динамічної поведінки системи та моделювання алгоритмів
виконання ключових бізнес-процесів використовується діаграма діяльності. Цей
тип діаграм візуалізує логіку роботи програми у вигляді орієнтованого графу
переходів від однієї дії до іншої, дозволяючи відстежити як основний потік
керування, так і альтернативні сценарії обробки виняткових ситуацій.
У розроблюваному програмному комплексі «Журнал навантаження
викладача» діаграма діяльності ілюструє один із найважливіших транзакційних
процесів — цикл додавання нового запису про фактично проведене заняття. Цей
36
ЧДТУ 26. 2244.019 ПЗ
процес є критичним для системи, оскільки він охоплює не лише взаємодію
користувача з графічним інтерфейсом, а й фонові операції з реляційною базою
даних та модулем розрахунку статистики.
Алгоритм розпочинається з початкового стану коли викладач, успішно
пройшовши процедуру авторизації, переходить на робочу вкладку «Журнал занять»
та ініціює створення нового запису. У відповідь на цю дію система виконує запит
до локальної бази даних SQLite за допомогою засобів Entity Framework Core.
Програма завантажує актуальні затверджені плани навантаження та динамічно
формує списки доступних дисциплін і академічних груп для подальшого вибору.
Після ідентифікації потрібної дисципліни користувач заповнює атрибути
заняття: вказує тему та кількість витрачених академічних годин. Наступним кроком
на діаграмі є вузол прийняття рішень, який відображає процес програмної валідації
введених даних. Обробник подій перевіряє повноту заповнення полів, коректність
форматів та загальну логічну цілісність запиту. Якщо виявлено невідповідність
вимогам, алгоритм переходить на альтернативну гілку: транзакція блокується,
система виводить відповідне візуальне повідомлення про помилку та повертає
користувача до етапу редагування форми, очікуючи на коректне введення.
За умови успішного проходження валідації ініціюється етап збереження
даних та виконання бізнес-логіки. Система генерує новий екземпляр класу-сутності
JournalRecord і виконує операцію збереження змін у базі даних SQLite. Одразу після
підтвердження транзакції автоматично запускається процес перерахунку
статистики: аналітичний модуль оновлює загальні показники виконання плану та
вираховує залишок нормативних годин з урахуванням щойно доданого заняття.
На завершальному етапі алгоритму система оновлює графічний інтерфейс
користувача. Завдяки механізмам двосторонньої прив'язки даних (Data Binding) у
WPF, таблиця електронного журналу та індикатори статистики миттєво
оновлюються, відображаючи актуальний стан навантаження. Після цього потік
керування досягає кінцевого вузла (Final Node), і бізнес-процес фіксації
проведеного заняття вважається успішно завершеним.
37
ЧДТУ 26. 2244.019 ПЗ
Рисунок 2.8 — Діаграма діяльності процесу додавання запису в журнал
Отже, діаграма діяльності дозволяє детально відобразити алгоритм роботи
програмного комплексу під час виконання ключової функції та врахувати можливі
розгалуження (обробку помилок вводу).
38
ЧДТУ 26. 2244.019 ПЗ
2.5.2. Діаграма послідовності
Діаграма послідовності (Sequence Diagram) дозволяє показати, які саме
об’єкти беруть участь у процесі обробки даних, у якій послідовності (в часі)
відбувається обмін повідомленнями між ними та як формується кінцевий результат
роботи системи. У додатку «Журнал навантаження викладача» діаграма
послідовності відображає типовий сценарій: перегляд і генерацію статистичного
звіту викладачем.
Рисунок 2.9 — Діаграма послідовності генерації статистичного звіту
Основні об’єкти діаграми:
– Викладач — користувач системи;
– Інтерфейс (StatisticsPage) — графічний шар системи;
– Контекст бази даних (AppDbContext) — об'єкт управління доступом до
даних;
– База даних (SQLite) — сховище інформації;
– Модуль експорту (ExcelExporter) — об'єкт генерації файлу .xlsx.
39
ЧДТУ 26. 2244.019 ПЗ
Спочатку Викладач відкриває вкладку «Статистика». Інтерфейс робить
синхронний запит до AppDbContext на отримання планів та журналів. Контекст
даних формує SQL-запит і надсилає його до SQLite. Отримавши дані, контекст
передає їх назад до Інтерфейсу, який відмальовує графіки та таблиці.
Після цього Викладач натискає кнопку «Експорт в Excel». Інтерфейс
викликає метод Модуля експорту, передаючи йому поточні списки даних. Модуль
формує таблицю Excel, зберігає файл на диск комп'ютера і повертає повідомлення
про успіх, яке Інтерфейс демонструє Викладачу. Отже, діаграма наочно відображає
життєвий цикл обробки даних від натискання кнопки користувачем до створення
фізичного файлу-звіту.
2.5.3. Діаграма комунікації
Діаграма комунікації (Communication Diagram) належить до групи діаграм
взаємодії в UML та призначена для візуалізації архітектурної організації об’єктів,
що обмінюються повідомленнями. На відміну від діаграми послідовності, яка
акцентує увагу на часовому аспекті подій, діаграма комунікації фокусується на
статичній (просторовій) структурі системи та ієрархії зв’язків між її елементами.
Вона дозволяє наочно продемонструвати, як саме об’єкти системи взаємодіють
один з одним для виконання конкретної бізнес-функції, підкреслюючи при цьому
архітектурні зв’язки та ролі, які відіграють окремі компоненти.
У розроблюваному програмному комплексі «Журнал навантаження
викладача» діаграма комунікації побудована для аналізу процесу автентифікації
користувача (викладача). Цей процес є критично важливим, оскільки він ініціює
створення глобальної сесії та визначає права доступу до подальших модулів
системи.
У процесі роботи користувач вводить логін і пароль у вікно авторизації
(LoginWindow). Далі LoginWindow формує запит на пошук користувача до
AppDbContext. Контекст БД виконує пошук у сховищі SQLite та повертає
знайдений об'єкт (або null). У разі успішної перевірки, LoginWindow надсилає
40
ЧДТУ 26. 2244.019 ПЗ
ідентифікатор користувача до глобального об'єкту AppSession, який зберігає ці дані
на час роботи програми. Після цього ініціюється створення і показ MainWindow
(головного вікна). Діаграма комунікації чітко показує, що LoginWindow виконує
роль координатора у цьому процесі.
Рисунок 2.10 — Діаграма комунікації процесу авторизації
41
ЧДТУ 26. 2244.019 ПЗ
2.5.4. Діаграма скінченного автомату
Діаграма скінченного автомату (State Machine Diagram) показує, у яких станах
може перебувати система (або її окремий об'єкт), за яких умов відбувається перехід
до іншого стану та яким чином система реагує на події. Для «Журналу
навантаження викладача» діаграма відображає зміну станів самої програми під час
сеансу роботи користувача.
Рисунок 2.11 — Діаграма станів системи обліку навантаження викладача
Після запуску система переходить у стан «Очікування авторизації». Якщо
користувач ввів некоректні дані, система залишається в цьому стані, виводячи
помилку. При успішному вході система переходить у стан «Робота з Дашбордом»
З цього стану викладач може перейти до «Редагування довідників», «Планування
навантаження» або «Ведення журналу». Під час додавання нового запису в журнал
програма переходить у стан «Валідації даних». Якщо валідація не пройдена —
повернення до редагування. Якщо пройдена успішно — система виконує запис у
БД і повертається до режиму перегляду.
42
ЧДТУ 26. 2244.019 ПЗ
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ
У другому розділі було виконано проектування програмного забезпечення
десктопного додатку «Журнал навантаження викладача». На основі аналізу
недоліків ручного обліку та існуючих інструментів (паперових журналів,
електронних таблиць) було сформовано вимоги до системи, визначено її ключові
функціональні можливості та технічні обмеження.
Було побудовано комплекс UML-діаграм, які дозволили всебічно описати
архітектуру майбутнього додатку. Діаграма прецедентів визначила основні сценарії
взаємодії викладача із системою. Діаграми класів та пакетів відобразили логічну
структуру програмного комплексу, організацію бази даних на основі Entity
Framework та використання патернів проектування WPF. Діаграма розгортання
продемонструвала принципи фізичного розміщення компонентів на локальному
комп'ютері. Моделювання поведінки системи за допомогою діаграм діяльності,
послідовності, комунікації та станів дозволило детально описати алгоритми
обробки даних, генерації звітів та життєвий цикл програми під час робочого сеансу
користувача.
Отже, результати другого розділу становлять повну проектну специфікацію,
яка концептуально та технічно обґрунтовує обрані інженерні рішення. Створена
архітектурна модель не лише гарантує відповідність майбутньої програми
поставленим завданням, але й забезпечує високий рівень її масштабованості та
зручності подальшого супроводу. Затверджений проектний фундамент є повністю
підготовленим для переходу до етапу безпосередньої програмної реалізації
(кодування модулів, розгортання локальної бази даних та конструювання
користувацького інтерфейсу), що буде детально висвітлено у наступному розділі
роботи.
43
ЧДТУ 26. 2244.019 ПЗ
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
У третьому розділі буде описано процес безпосередньої програмної реалізації
та тестування десктопного програмного комплексу «Журнал навантаження
викладача». Основну увагу приділено обґрунтуванню вибору засобів розробки,
опису структурної, функціональної та логічної схем системи, створенню графічного
інтерфейсу користувача на базі технології WPF, а також реалізації локальної бази
даних SQLite та модулів аналітики й експорту звітності. Також у розділі буде
наведено результати модульного, інтеграційного, системного та приймального
тестування розробленого програмного забезпечення, що підтверджують його
стабільність і відповідність поставленим вимогам.
3.1 Розробка програмного комплексу
Третій розділ кваліфікаційної роботи є фундаментальним етапом, на якому
здійснюється безпосередня практична реалізація інформаційної системи —
десктопного додатку «Журнал навантаження викладача». Даний етап передбачає
перехід від абстрактного теоретичного моделювання, системного аналізу
предметної області та побудови UML-діаграм до фізичного написання вихідного
програмного коду, налаштування інфраструктури зберігання даних та
конструювання графічного інтерфейсу користувача.
Розробка сучасного програмного забезпечення вимагає не лише знання
синтаксису мови програмування, але й глибокого розуміння архітектурних
патернів, принципів побудови реляційних баз даних, методів об'єктно-реляційного
відображення (ORM) та концепцій проектування людино-машинної взаємодії (HCI
- Human-Computer Interaction). У даному підрозділі здійснюється вичерпний опис
усіх етапів розробки: від науково обґрунтованого вибору технологічного стеку та
середовища розробки до детального розбору логіки роботи ключових програмних
компонентів, класів та методів. Значна увага приділяється реалізації адаптивного та
44
ЧДТУ 26. 2244.019 ПЗ
ергономічного графічного інтерфейсу (GUI) на базі декларативної мови розмітки, а
також конструюванню оптимізованих алгоритмів агрегації статистичних даних у
режимі реального часу. Опис програмної реалізації супроводжується аналізом
структурної та логічної схем, які визначають внутрішню організацію та життєвий
цикл створеного додатку.
3.1.1 Обґрунтування вибору засобів реалізації
Ефективність, надійність, безпека та подальша масштабованість будь-якого
програмного продукту безпосередньо залежать від правильно підібраного
інструментарію на етапі ініціалізації проекту. Вибір програмних платформ,
середовищ розробки, мов програмування та допоміжних сторонніх бібліотек для
створення додатку «Журнал навантаження викладача» здійснювався на основі
суворих критеріїв: повної автономності системи, високої продуктивності при роботі
з великими масивами звітних даних, забезпечення цілісності локальної бази даних
та відповідності сучасним стандартам UI/UX дизайну.
Вибір середовища розробки (IDE) та програмної платформи
Основним інтегрованим середовищем розробки (Integrated Development
Environment) було обрано Microsoft Visual Studio 2022. Цей вибір є закономірним та
обґрунтованим, оскільки Visual Studio на сьогоднішній день виступає
беззаперечним галузевим стандартом для розробки складного програмного
забезпечення в екосистемі операційних систем сімейства Windows. Дане
середовище надає розробнику комплексний набір передових інструментів, що
суттєво пришвидшують процес написання коду та мінімізують кількість
синтаксичних помилок, зокрема:
Програмний комплекс побудований на базі новітньої кросплатформної
інфраструктури .NET 8.0. На відміну від морально застарілої .NET Framework,
сучасна платформа .NET є високооптимізованою та модульною. Версія .NET 8.0
має офіційний статус довгострокової підтримки (LTS - Long Term Support), що
гарантує отримання критичних оновлень безпеки та виправлень стабільності від
45
ЧДТУ 26. 2244.019 ПЗ
корпорації Microsoft протягом щонайменше трьох років. Використання .NET 8.0
дозволило задіяти вдосконалений збирач сміття (Garbage Collector), який мінімізує
мікрозатримки (GC Pauses) під час звільнення пам'яті від непотрібних об'єктів, а
також багаторівневий JIT-компілятор (Tiered Compilation), що забезпечує швидкий
запуск десктопного додатку (Cold Start) та високу швидкість виконання циклічних
математичних обчислень.
Вибір мови програмування
У якості єдиної базової мови програмування для реалізації бізнес-логіки
системи, написання контролерів вікон та взаємодії з базою даних було обрано мову
C#. C# — це сучасна, об'єктно-орієнтована, строго типізована мова програмування
загального призначення з C-подібним синтаксисом. Вибір саме цієї мови
обґрунтовується наступними вагомими чинниками:
1 Строга статична типізація (Static Typing): Усуває величезний клас
помилок (TypeMismatch) ще на етапі розробки, оскільки тип кожної змінної
та об'єкта відомий компілятору до запуску програми. Це критично важливо
для додатку, який виконує підрахунок годин, оскільки унеможливлює
випадкове додавання текстових рядків до числових значень.
2 Повна підтримка парадигми об'єктно-орієнтованого програмування
(ООП): Використання принципів інкапсуляції, успадкування та
поліморфізму дозволило побудувати чітку, прозору ієрархію класів-моделей
(сутностей бази даних) та розділити зону відповідальності між різними
компонентами системи, зробивши код гнучким до майбутніх змін.
3 Технологія LINQ (Language Integrated Query): Вбудована безпосередньо
в синтаксис мови потужна мова запитів, яка дозволяє взаємодіяти з
колекціями об'єктів у пам'яті та реляційною базою даних за допомогою
зрозумілого та лаконічного декларативного підходу. Використання LINQ
46
ЧДТУ 26. 2244.019 ПЗ
(методи .Where(), .Sum(), .Include()) замінило необхідність написання
довгих і складних SQL-запитів вручну, знизивши ризик помилок.
4 Асинхронне програмування: Наявність конструкцій async та await
дозволяє виконувати ресурсомісткі операції (наприклад, звернення до
фізичного файлу бази даних на диску або генерацію великого Excel-звіту)
у фонових потоках (Background Threads). Завдяки цьому головний потік
інтерфейсу користувача (UI Thread) ніколи не блокується, і програма
залишається "чуйною" (Responsive) навіть під час інтенсивних
розрахунків.
Вибір технології розробки графічного інтерфейсу (GUI)
Для розробки візуальної частини додатку (Front-end шару) було обрано
передову технологію WPF (Windows Presentation Foundation). Хоча для Windows-
додатків історично використовувалася технологія Windows Forms, на сьогоднішній
день вона вважається застарілою, оскільки не підтримує векторну графіку нативно
та спирається на програмний рендеринг (GDI+), що ускладнює створення складних,
адаптивних інтерфейсів з анімаціями.
Вибір системи керування базами даних (СКБД) та технології доступу до
даних (ORM)
Програмний комплекс «Журнал навантаження викладача» від самого початку
проектувався як персональний, локальний інструмент. Використання повноцінних
клієнт-серверних СКБД промислового рівня (таких як Microsoft SQL Server, Oracle
або PostgreSQL) вимагало б від кінцевого користувача встановлення додаткового
серверного програмного забезпечення, налаштування мережевих портів та
адміністрування служб, що є абсолютно неприйнятним для викладача без навичок
системного адміністратора.
Виходячи з цих обмежень, для надійного збереження інформації було обрано
вбудовану реляційну СКБД SQLite.
SQLite — це ультракомпактна C-бібліотека, яка реалізує повноцінний SQL-
рушій бази даних без необхідності налаштування та запуску окремого серверного
47
ЧДТУ 26. 2244.019 ПЗ
процесу (Serverless Architecture). Вся без винятку інформація системи (нормативні
довідники, електронні журнали, хешовані облікові дані, налаштування) надійно
зберігається у єдиному файлі операційної системи (workload.db). Це робить
розроблений додаток максимально портативним: викладач може просто скопіювати
всю папку з програмою на USB-накопичувач і продовжити повноцінну роботу на
іншому комп'ютері зі збереженням усієї бази даних. Незважаючи на свою
компактність та файлову природу, SQLite повністю відповідає вимогам ACID
(Атомарність, Узгодженість, Ізольованість, Довговічність), підтримує транзакції,
зовнішні ключі (Foreign Keys) для забезпечення реляційної цілісності та індекси для
прискорення пошуку.
3.1.2 Опис структурної (функціональної) схеми
Структурна (або функціональна) схема є фундаментальним інструментом
архітектурного проектування, який забезпечує абстрактне візуальне та логічне
відображення організації програмного комплексу. Вона демонструє декомпозицію
складної монолітної системи на менші, незалежні, керовані та логічно завершені
функціональні блоки (модулі або підсистеми). Кожен такий модуль інкапсулює
всередині себе специфічну предметну область бізнес-логіки, відповідні алгоритми
обробки інформації та структури даних.
Такий підхід базується на ключових принципах інженерії програмного
забезпечення: мінімізації зв'язності (Low Coupling) та максимізації згуртованості
(High Cohesion) програмного коду, що гарантує високу стабільність системи та
легкість її подальшого масштабування чи модифікації. Окрім статичного поділу на
компоненти, ця схема чітко регламентує напрямки інформаційних потоків та
інтерфейси взаємодії між виділеними підсистемами. Зокрема, вона дозволяє наочно
розмежувати рівні графічного інтерфейсу, ядра аналітичної логіки та доступу до
локальних даних. Завдяки такій прозорості архітектури значно спрощується процес
ізольованого тестування окремих модулів та загальний супровід програмного
продукту.
48
ЧДТУ 26. 2244.019 ПЗ
Рисунок 3.1- Функціональна схема
Розроблений десктопний додаток «Журнал навантаження викладача» має
чітко виражену модульну архітектуру, яка логічно поділяється на шість ключових
функціональних підсистем, що тісно та безперервно взаємодіють між собою через
визначені програмні інтерфейси:
Підсистема безпеки, ідентифікації та керування сесією (Security &
Authentication Module):
Даний модуль є єдиною точкою входу в інформаційну систему і виконує
критичну функцію захисту персональних та звітних даних викладача від
несанкціонованого доступу з боку третіх осіб, які можуть мати фізичний доступ до
персонального комп'ютера. На структурному рівні підсистема обробляє подію
запуску програми, генерує графічну форму для введення облікових даних (логіну
та паролю) та виконує криптографічно безпечну верифікацію введеної інформації
шляхом її порівняння із записами у таблиці Users локальної бази даних.
У разі успішного проходження процедури автентифікації, модуль відповідає
за ініціалізацію глобальної користувацької сесії. Для цього використовується
архітектурний патерн Singleton, реалізований через статичний клас AppSession, у
49
ЧДТУ 26. 2244.019 ПЗ
пам'ять якого записується унікальний ідентифікатор авторизованого користувача
(CurrentUserId). Цей ідентифікатор надалі виступає в ролі маркера авторизації та
використовується всіма іншими підсистемами для персоніфікації інтерфейсу
(наприклад, виведення прізвища та ініціалів викладача у головному навігаційному
меню) та потенційного розмежування прав доступу.
Підсистема управління нормативно-довідковою інформацією (Master
Data Management Module):
Це базовий функціональний блок, що забезпечує централізоване ведення
статичних та напівстатичних довідників, інформація з яких є необхідною для
коректного функціонування всієї системи. До таких життєво важливих довідників
у розробленому додатку належать «Навчальні дисципліни» та «Студентські
академічні групи».
Підсистема реалізує повний, класичний цикл CRUD-операцій:
– Create (створення та реєстрація нової дисципліни або профілю групи);
– Read (витягнення даних з БД та їх форматоване виведення у таблиці
інтерфейсу);
– Update (безпечне редагування назви предмета або шифру групи без втрати
реляційних зв'язків);
– Delete (видалення неактуальних записів за умови проходження перевірки
на відсутність каскадних залежностей).
Впровадження цієї підсистеми відіграє критичну роль у забезпеченні логічної
цілісності бази даних. Оскільки дані з довідників використовуються в інших
операційних модулях виключно як елементи випадаючих списків (ComboBox), це
повністю унеможливлює введення некоректних або дубльованих назв (наприклад,
одночасне існування записів "Математика" і "Вища математика" через помилку
друку) під час щоденної роботи викладача.
Підсистема стратегічного планування навчального навантаження
(Workload Planning Module):
50
ЧДТУ 26. 2244.019 ПЗ
Модуль відповідає за ключовий бізнес-процес формування індивідуального
робочого плану викладача на поточний академічний семестр або повний
навчальний рік. У цій підсистемі користувач через спеціалізований графічний
інтерфейс створює комплексні записи, які встановлюють багатовимірний логічний
зв'язок між чотирма незалежними сутностями: обраною з нормативного довідника
дисципліною, обраною академічною студентською групою, типом запланованого
навчального заняття (лекційне, практичне або лабораторне) та нормативною
кількістю академічних годин, що затверджені навчально-методичним відділом
кафедри.
Створені у цій підсистемі агреговані записи виконують функцію генерації
цільових показників (квот навантаження), яких викладач об'єктивно має досягти
протягом поточного звітного періоду.
Підсистема оперативного обліку виконаної роботи (Electronic Journal
Module):
Це безпосереднє транзакційне ядро програмного комплексу, яке виступає
основним повсякденним робочим інструментом викладача. Даний модуль
призначений для регулярної щоденної фіксації факту проведення кожного
навчального заняття. На відміну від застарілого паперового журналу, де записи
часто дублюються або вносяться хаотично, тут кожен новий запис формується
шляхом створення жорсткої реляційної прив'язки до конкретного існуючого рядка
з плану навантаження.
Під час роботи з модулем викладач фіксує точну календарну дату проведення
пари за допомогою візуального компонента DatePicker, вводить короткий текстовий
опис теми заняття (конспект або номер лабораторної роботи) та вказує фактично
витрачену кількість академічних годин. Підсистема містить інтегровані алгоритми
валідації (Client-Side Validation), які блокують спроби зберегти порожній запис,
внести у числове поле годин літери або спеціальні символи, чим гарантується
абсолютна чистота даних, що надходять до СКБД.
51
ЧДТУ 26. 2244.019 ПЗ
Підсистема аналітики та моніторингу виконання плану (Analytics &
Monitoring Module):
Це найбільш високонавантажений обчислювальний модуль розробленої
системи. Його головне завдання полягає у динамічному зборі, агрегації та складній
математичній обробці великих масивів накопичених даних у режимі реального
часу. Під час активації модуль паралельно звертається до підсистеми планування
для отримання затверджених квот (PlannedHours) та до підсистеми журналу для
отримання повного масиву відпрацьованих годин (ConductedHours).
Далі виконується математичне підсумовування всіх проведених годин для
кожного окремого плану та знаходження їхньої різниці. На основі розрахованої
дельти (Delta) підсистема генерує інтелектуальний звіт, автоматично класифікуючи
поточний стан виконання кожного пункту плану за трирівневою шкалою:
– Залишок годин > 0 — статус «Недопрацювання» (потрібно провести ще
заняття);
– Залишок = 0 — статус «Норма виконана» (ідеальний стан);
– Залишок < 0 — статус «Перепрацювання» (викладач вичитав більше
годин, ніж передбачено планом).
Згенеровані аналітичні дані негайно передаються на інтерфейс користувача
для їхньої візуалізації у вигляді відсоткових прогрес-барів та колірних семантичних
індикаторів.
Підсистема експорту та генерації звітності (Reporting & Export Module):
Фінальний логічний блок, який виконує завдання комунікаційного мосту між
ізольованим локальним додатком та зовнішнім середовищем операційної системи.
Коли викладачу необхідно надати офіційний паперовий або електронний звіт на
кафедру, ця підсистема перехоплює агреговані дані від аналітичного модуля та
ініціює процес програмного формування двійкового файлу електронної таблиці
формату MS Excel (розширення .xlsx).
Внутрішні алгоритми підсистеми самостійно відповідають за структурування
колонок звітного документа, застосування стилізації заголовків (використання
52
ЧДТУ 26. 2244.019 ПЗ
напівжирного шрифту, центрального вирівнювання), циклічне, построкове
заповнення комірок розрахунковими даними та кінцеве збереження готового
документа на жорсткий диск комп'ютера з автоматично згенерованою унікальною
назвою, що містить штамп поточної дати та часу (Timestamp) для уникнення
перезапису попередніх звітів.
3.1.3 Опис логічної схеми системи
Логічна схема програмного комплексу (System Logic & Control Flow)
відображає динамічний аспект його функціонування. Вона детально описує строгу
послідовність дій, складні алгоритми обробки інформації та переходи між різними
станами системи під час її взаємодії з користувачем. На відміну від структурної
схеми, яка фіксує статичний поділ коду на об'єкти та модулі, логічна схема
зосереджена на життєвому циклі процесів від моменту ініціалізації додатка
операційною системою до його коректного завершення.
Фундаментальний алгоритм роботи розробленого десктопного додатку «Журнал
навантаження викладача» можна розділити на чотири послідовні логічні етапи
(фази):
Етап 1. Системна ініціалізація та розгортання інфраструктури
зберігання даних:
Життєвий цикл програми неминуче починається з події завантаження
(Application Startup), яка перехоплюється методом OnStartup у глобальному класі
додатку App.xaml.cs. На цьому ранньому етапі графічний інтерфейс ще не
відображається. Система першочергово звертається до ядра доступу до даних
(компоненту Entity Framework Core) з метою перевірки поточного стану локального
середовища. Виконується критичний метод Database.EnsureCreated(), який
перевіряє фізичну наявність файлу бази даних workload.db у робочій директорії
виконуваного файлу програми.
Якщо файл відсутній (що типово для першого запуску на новому робочому
місці), ORM-фреймворк автоматично ініціює повноцінний процес розгортання:
53
ЧДТУ 26. 2244.019 ПЗ
створює новий пустий файл БД, компілює описані розробником C#-моделі у
відповідні DDL-інструкції (Data Definition Language) специфічного формату SQLite
та створює всі необхідні реляційні таблиці, зовнішні ключі (Foreign Keys) та
оптимізаційні індекси. Відразу після успішного розгортання структури таблиць
спрацьовує вбудований механізм первинного наповнення (Data Seeding). Через
перевизначений метод OnModelCreating, Entity Framework невидимо для
користувача виконує SQL-інструкцію INSERT, яка створює обліковий запис
адміністратора за замовчуванням (з паролем, який в подальшому можна змінити).
Це архітектурне рішення гарантує, що система завжди, за будь-яких умов готова до
роботи "з коробки", що є критично важливою характеристикою для персональних
десктопних рішень.
Етап 2. Автентифікація користувача та встановлення захищеної сесії:
Після успішного завершення системної ініціалізації програма переходить до
етапу взаємодії з користувачем і завантажує візуальне вікно LoginWindow. З цього
моменту система переходить у стан очікування подій (Event-Driven Architecture).
Коли викладач вводить свій логін і пароль та натискає кнопку входу, операційна
система генерує подію Click. Програмний обробник цієї події спочатку виконує
базову локальну валідацію на стороні клієнта (наприклад, перевірку на порожні
поля за допомогою методу string.IsNullOrWhiteSpace).
Якщо базова валідація успішно пройдена, створюється новий тимчасовий
екземпляр контексту бази даних AppDbContext, за допомогою якого формується
комплексний LINQ-запит для пошуку відповідного користувача:
context.Users.FirstOrDefault(u => u.Username == username && u.PasswordHash ==
password). Внутрішній транслятор EF Core конвертує цей C#-вираз у безпечний
параметризований SQL-запит (що є абсолютним захистом від поширених атак типу
SQL-Injection), виконує його на рівні файлу БД та повертає результат. Якщо об'єкт
користувача знайдено, його унікальний числовий ідентифікатор Id записується у
статичну властивість глобального класу AppSession. Таким чином створюється
віртуальна "програмна сесію". Після цього вікно LoginWindow програмно
54
ЧДТУ 26. 2244.019 ПЗ
закривається і звільняє пам'ять, а замість нього ініціалізується та розгортається на
весь екран головне вікно системи MainWindow.
Етап 3. Маршрутизація (Routing) та обробка транзакцій життєвого циклу
CRUD:
Опинившись у середовищі MainWindow, користувач взаємодіє з
інтерактивним боковим навігаційним меню. Кожна кнопка цього меню жорстко
прив'язана до події, яка ініціює створення нового екземпляра відповідної робочої
сторінки (наприклад, new Views.WorkloadPlanPage()) та передає його у вбудований
навігаційний контейнер WPF через виклик методу Frame.Navigate().
У конструкторі кожної створеної сторінки автоматично викликається
спеціальний метод первинного завантаження даних (наприклад, LoadData()), який
ініціює SQL SELECT запит та динамічно прив'язує отриману колекцію об'єктів до
візуальної таблиці DataGrid за допомогою технології Data Binding.
Коли користувач ініціює намір додати новий інформаційний запис (наприклад,
внести проведену лекцію у Журнал), він заповнює візуальні поля форми.
Натискання фінальної кнопки "Додати" запускає складний транзакційний алгоритм
обробки:
– комплексна валідація: Система примусово перевіряє, чи обрано значення
у всіх критичних випадаючих списках (SelectedItem != null), та чи
коректно введено числові дані у текстові поля (int.TryParse для перевірки
на відсутність літер у полі кількості годин);
– маппінг об'єктів (Object Mapping): Чисті, провалідовані дані з елементів
інтерфейсу копіюються у відповідні властивості новоствореного
екземпляра C#-моделі (наприклад, створюється новий об'єкт
JournalRecord);
– додавання в контекст (Context Tracking): Створений об'єкт передається у
метод _context.JournalRecords.Add(). На цьому мікро-етапі об'єкт
потрапляє у кеш внутрішнього компонента Change Tracker зі статусом
"Added" (Доданий), але ще не записується у фізичний файл бази даних.
55
ЧДТУ 26. 2244.019 ПЗ
– фіксація транзакції ( C o m m i t ) : Викликається ключовий метод
_context.SaveChanges(). Entity Framework генерує відповідну
оптимізовану SQL-інструкцію INSERT, відкриває безпечну транзакцію у
SQLite, фізично виконує запис, повертає згенерований базою даних
первинний ключ (Id) назад у C#-об'єкт і закриває транзакцію,
гарантуючи її атомарність;
– синхронізація інтерфейсу (UI Refresh):В икликається метод LoadData(),
який оновлює візуальну таблицю з урахуванням щойно доданого запису,
а також метод ResetForm() для повного очищення полів вводу, готуючи
систему до наступної транзакції.
Етап 4. Логіка агрегації та обробки аналітичних даних:
Найбільш складна та ресурсомістка логічна гілка виконується алгоритмом при
переході користувача на сторінку "Статистика". Система повинна не просто
вивести існуючі дані, а провести їх глибокий аналіз "на льоту". Логіка передбачає
застосування механізму "жадібного завантаження" (Eager Loading) за допомогою
методу розширення Include(). Завдяки цьому, система одним складним запитом з
операторами JOIN витягує з бази даних всі наявні об'єкти "План навантаження"
разом із масивом всіх вкладених у них "Записів журналу".
Отримавши цей складний граф об'єктів у оперативну пам'ять, програма,
використовуючи цикл foreach, обходить кожен навчальний план. Всередині циклу
викликається функція Sum() для колекції пов'язаних журналів, яка з математичною
точністю підраховує загальну кількість фактично відпрацьованих годин за цим
планом. Наступним кроком обчислюється різниця: Відпрацьовано годин -
Заплановано годин. Залежно від математичного знаку отриманого результату (>0,
<0, ==0), алгоритм застосовує умовні розгалуження (if-else) для формування
фінального текстового вердикту та динамічного призначення візуального кольору
для інтерфейсу користувача.
56
ЧДТУ 26. 2244.019 ПЗ
Рисунок 3.2 – Логічна схема системи.
3.1.4 Розробка бази даних
Розробка надійної, масштабованої та логічно структурованої бази даних (БД)
є фундаментальним етапом проектування будь-якої сучасної інформаційної
системи, оскільки саме на цьому рівні забезпечується цілісність, довгострокове
зберігання та швидкий доступ до накопиченої цифрової інформації. У рамках
розробки додатку «Журнал навантаження викладача» базу даних було
спроектовано з використанням реляційної моделі (Relational Model), яка базується
на організації даних у вигляді взаємопов'язаних таблиць, що відповідають вимогам
нормалізації.
Для реалізації фізичного рівня бази даних було застосовано передовий підхід
Code-First (Спершу код) у рамках технології Entity Framework Core. Дана
методологія передбачає, що архітектура бази даних не створюється вручну в
сторонніх візуальних редакторах, а повністю визначається безпосередньо у
вихідному коді мовою C# за допомогою спеціалізованих класів-моделей (POCO —
Plain Old CLR Objects). На основі аналізу цих класів ORM-система автоматично
57
ЧДТУ 26. 2244.019 ПЗ
генерує та застосовує схему бази даних SQLite, що гарантує повну синхронізацію
між програмним кодом та структурою таблиць на диску.
Обґрунтування структури та нормалізація даних
Процес проектування схеми бази даних супроводжувався процедурою
нормалізації до третьої нормальної форми (3NF). Це дозволило усунути
надлишковість даних (Data Redundancy) та запобігти виникненню аномалій
оновлення, видалення та вставки. Структура БД спроектована таким чином, щоб
кожна інформаційна одиниця зберігалася лише в одному місці, а зв'язки між
сутностями реалізовувалися за допомогою зовнішніх ключів (Foreign Keys).
Спроектована архітектура бази даних складається з наступних ключових
сутностей (таблиць):
Сутність «Users» (Облікові записи):
Дана таблиця виконує роль фундаменту для підсистеми безпеки. Вона
призначена для зберігання персональних даних викладачів, які мають доступ до
системи. Кожен запис містить унікальний ідентифікатор (Id), логін користувача
(Username), а також хешоване значення пароля (PasswordHash) для забезпечення
конфіденційності. Наявність поля FullName дозволяє персоналізувати звіти та
інтерфейс програми під конкретного науково-педагогічного працівника.
Сутність «Disciplines» (Навчальні дисципліни):
Виконує функцію базового нормативного довідника. Вона містить перелік
усіх навчальних предметів, які викладаються на кафедрі. Винесення дисциплін в
окрему таблицю дозволяє уникнути дублювання довгих назв у кожному записі
журналу та забезпечує єдиний стандарт найменування дисциплін у всіх звітах.
Сутність «StudentGroups» (Студентські групи):
Ще один критично важливий довідник, який зберігає інформацію про
академічні групи. Таблиця містить унікальні шифри груп (наприклад, «ПЗ-2204»).
Реляційний зв'язок із цією таблицею дозволяє системі автоматично групувати
навантаження та фільтрувати записи журналу за конкретним контингентом
студентів.
58
ЧДТУ 26. 2244.019 ПЗ
Сутність «WorkloadPlans» (Плани навантаження):
Центральна вузлова сутність системи, яка реалізує складний логічний зв'язок
типу «багато-до-багатьох» між дисциплінами та групами через проміжну таблицю.
Кожен запис у цій таблиці визначає конкретну норму годин для викладача за
певним напрямом роботи. Вона містить посилання на дисципліну, групу, а також
перерахування (enum) типу заняття (лекційне, практичне, лабораторне) та числовий
атрибут запланованих годин. Саме ця таблиця виступає «еталоном» при підрахунку
статистики виконання плану.
Сутність «JournalRecords» (Записи журналу):
Таблиця операційного рівня, яка наповнюється викладачем щоденно. Кожен
запис жорстко прив’язаний до ідентифікатора плану навантаження, що дозволяє
системі автоматично асоціювати проведену пару з конкретною дисципліною та
групою. Таблиця фіксує дату проведення, тему заняття та кількість фактично
проведених годин.
Забезпечення цілісності та безпеки даних
Для підтримання реляційної цілісності даних (Referential Integrity) на рівні
СКБД SQLite було налаштовано механізм каскадного видалення (Cascade Delete).
Це архітектурне рішення гарантує, що при видаленні, наприклад, навчальної
дисципліни, система автоматично знищить усі пов'язані з нею плани та записи в
журналах, запобігаючи накопиченню «сміттєвих» даних, які не мають батьківських
записів. Крім того, Entity Framework Core забезпечує валідацію даних перед їх
фізичним записом на диск, що унеможливлює порушення типів даних або вставку
нульових значень у критично важливі поля (NOT NULL constraints). Завдяки такому
підходу розроблена система повністю відповідає принципам транзакційної
цілісності (ACID), гарантуючи надійне збереження інформації навіть у разі
непередбачуваного завершення роботи додатка. Це створює міцний архітектурний
фундамент для аналітичного модуля, дозволяючи йому миттєво та безпомилково
обчислювати статистику на основі завжди консистентних даних.
59
ЧДТУ 26. 2244.019 ПЗ
Рисунок 3.4 – Схема бази даних
3.1.5 Розробка інтерфейсу користувача
Графічний інтерфейс користувача (GUI — Graphical User Interface) є
ключовим компонентом розробленої системи, оскільки він забезпечує людино-
машинну взаємодію та безпосередньо впливає на продуктивність роботи викладача.
Проектування інтерфейсу додатку «Журнал навантаження викладача»
здійснювалося на основі принципів сучасного дизайну, ергономіки та
психофізіологічних особливостей сприйняття інформації.
Концептуальний підхід до дизайну
За основу візуального оформлення було обрано дизайн-систему Material
Design, яка базується на метафорі паперу та тіней. Використання бібліотеки
MaterialDesignThemes для WPF дозволило створити інтерфейс, який виглядає
легким, чистим та сучасним. Ключовим принципом стало забезпечення візуальної
ієрархії: важливі елементи управління (кнопки дії, активні поля вводу) виділяються
60
ЧДТУ 26. 2244.019 ПЗ
акцентними кольорами та тінями, тоді як допоміжна інформація залишається на
другому плані.
Архітектура вікон та навігація
Головне вікно програми спроектовано як єдиний робочий простір (Single
Window Application), розділений на дві функціональні зони:
Навігаційна панель (Sidebar): Розміщена в лівій частині вікна і має
фіксовану ширину. Вона містить логотип програми та вертикальний список
навігаційних кнопок. Кожна кнопка супроводжується векторною іконкою, що
підвищує швидкість розпізнавання функцій. Використання компонента Frame у
поєднанні з лівим меню дозволяє викладачу миттєво перемикатися між журналами,
планами та статистикою без відкриття нових вікон, що зберігає контекст роботи та
знижує когнітивне навантаження.
Контентна область (Main Content Area): Займає основну частину екрана.
Тут відображаються динамічні сторінки (Page), кожна з яких оптимізована під
конкретне завдання. Наприклад, сторінка журналу містить комбінацію форми вводу
та таблиці результатів, що забезпечує швидкий доступ до всіх функцій в один клік.
Реалізація тем інтерфейсу та адаптивності: Однією з важливих
нефункціональних вимог до системи була підтримка темної теми (Dark Mode).
Враховуючи, що робота викладача часто пов'язана з тривалим аналізом даних перед
монітором, наявність темної теми дозволяє значно знизити втому очей та
підвищити комфорт при слабкому освітленні. Реалізація перемикання тем виконана
за допомогою динамічної заміни ресурсів (ResourceDictionary) у реальному часі.
При натисканні на тумблер у меню, програма автоматично перераховує всі кольори
— від фону карток до тексту — зберігаючи при цьому високий контраст і
читабельність.
Елементи управління та зворотний зв'язок
Для мінімізації помилок при введенні даних було застосовано спеціальні
стилізовані елементи Material Design:
61
ЧДТУ 26. 2244.019 ПЗ
– Floating Hint TextBox: Текстові поля, де підказка плавно переміщується
вгору при фокусуванні, що дозволяє викладачу завжди бачити назву поля,
яке він заповнює.
– Validation States: Поля вводу підсвічуються червоним кольором у разі
введення некоректних даних (наприклад, від’ємної кількості годин), що
забезпечує миттєвий зворотний зв'язок.
– Interactive DataGrids: Таблиці підтримують сортування та виділення
рядків, а контекстні меню забезпечують швидкий доступ до операцій
редагування та видалення.
Завдяки використанню технології WPF, інтерфейс є повністю незалежним від
роздільної здатності монітора (Resolution Independence). Це означає, що програма
однаково якісно виглядає як на невеликих екранах ноутбуків, так і на великих
стаціонарних моніторах кафедральних комп'ютерів, автоматично підлаштовуючи
розміри елементів та шрифтів під системні налаштування масштабування Windows.
3.1.6 Опис розробки програмних компонентів
Внутрішня архітектура розробленого програмного комплексу базується на
принципах модульності та чіткого розділення відповідальності (Separation of
Concerns). Хоча класичний патерн MVVM (Model-View-ViewModel) є стандартом
для великих WPF-додатків, для даного персонального проекту було обрано
прагматичний підхід Code-Behind із застосуванням елементів MVC (Model-View-
Controller). Кожна візуальна XAML-сторінка (View) має нерозривно пов'язаний із
нею файл коду мовою C# (Code-Behind), який виконує роль локального контролера:
обробляє події інтерфейсу, звертається до бази даних та керує бізнес-логікою.
Усі програмні компоненти системи логічно згруповані у відповідні простори
імен (Namespaces): Models (сутності БД), Data (класи доступу до даних) та Views
(візуальні інтерфейси та їх контролери). Розглянемо детальну реалізацію ключових
програмних компонентів системи.
Компонент контексту бази даних (AppDbContext.cs)
62
ЧДТУ 26. 2244.019 ПЗ
Клас AppDbContext є фундаментальним компонентом шару доступу до даних
(Data Access Layer). Він успадковує базовий функціонал
Microsoft.EntityFrameworkCore.DbContext і діє як міст між об'єктно-орієнтованим
кодом мовою C# та реляційною базою даних SQLite.
У лістингу 3.1 наведено фрагмент реалізації цього класу. Колекції DbSet<T>
репрезентують фізичні таблиці. Метод OnConfiguring налаштовує рядок
підключення до локального файлу. Критично важливим є перевизначений метод
OnModelCreating, у якому за допомогою Fluent API (API вільного формату)
налаштовуються каскадні видалення та виконується первинне наповнення бази
даних (Data Seeding) обліковим записом адміністратора. Це інкапсулює логіку
розгортання БД всередині самого додатку, усуваючи необхідність зовнішніх SQL-
скриптів.
Глобальний менеджер стану сесії (AppSession.cs)
У десктопних додатках, які базуються на навігації між незалежними
сторінками (Page), виникає архітектурна проблема безпечної передачі інформації
про поточний стан (State Management). Замість передачі параметрів через
конструктори кожного вікна, було реалізовано глобальний статичний клас
AppSession.
Оскільки статичні класи існують в єдиному екземплярі та зберігаються у купі
(Heap) протягом усього часу роботи програми (Application Lifetime), цей клас
ідеально підходить для зберігання унікального ідентифікатора авторизованого
користувача (CurrentUserId). Після успішної перевірки пароля у вікні входу,
ідентифікатор викладача записується в цю змінну, що дозволяє будь-якому іншому
модулю (наприклад, сторінці профілю) миттєво отримати доступ до персональних
даних активного користувача.
Компонент контролю доступу (LoginWindow.xaml.cs)
Модуль автентифікації є першим рубежем захисту системи. Логіка цього
компонента інкапсульована в обробнику події натискання кнопки входу.
63
ЧДТУ 26. 2244.019 ПЗ
Алгоритм починається з читання даних із візуальних полів UsernameTextBox та
PasswordBox. Далі виконується локальна валідація для запобігання зайвим
зверненням до бази даних. Основним етапом є створення блоку using (var context =
new AppDbContext()), що гарантує коректне закриття з'єднання з базою та
вивільнення некерованих ресурсів після завершення операції. Для пошуку
користувача використовується LINQ-метод FirstOrDefault(), який транслюється в
оптимізований SQL-запит SELECT TOP 1.
Аналітичний компонент та обчислення статистики
(StatisticsPage.xaml.cs)
Найбільш ресурсомістким компонентом бізнес-логіки системи є модуль
обчислення статистики виконання навантаження. Проблема полягає в тому, що
Entity Framework Core не може напряму прив'язати до інтерфейсу динамічно
розраховані значення (такі як різниця між планом і фактом), оскільки вони фізично
не існують у базі даних.
Для вирішення цієї архітектурної проблеми було застосовано патерн DTO
(Data Transfer Object) — створено допоміжний клас StatisticsViewModel, який
слугує обгорткою для результатів обчислень. У лістингу 3.3 наведено метод
агрегації даних. Ключовим аспектом алгоритму є використання методу розширення
.Include(), що вмикає механізм "жадібного завантаження" (Eager Loading). Це
дозволяє витягти плани навантаження разом із вкладеним масивом журналів за
один масивний запит до БД (через оператор LEFT JOIN), уникаючи відомої
проблеми N+1 запитів, яка критично знижує продуктивність програми.
Модуль генерації звітів та експорту даних
Функціональність експорту зведеної інформації реалізовано у вигляді
окремого методу в рамках компонента статистики. Алгоритм використовує
технологію COM Interop (через бібліотеку Microsoft.Office.Interop.Excel) для
безпосередньої взаємодії з програмним забезпеченням MS Excel, що встановлене на
комп'ютері користувача.
64
ЧДТУ 26. 2244.019 ПЗ
Після ініціалізації екземпляра додатку Excel, алгоритм створює нову
віртуальну робочу книгу (Workbook) та активний аркуш (Worksheet). Першим
етапом виконується заповнення заголовків стовпців («Дисципліна», «Група»,
«План», «Факт», «Статус») з паралельним застосуванням базового форматування
(жирний шрифт Bold = true). На другому етапі запускається цикл for, який ітерує
через колекцію обчисленої статистики (statisticsList) та заповнює відповідні
комірки (Cells[row, column]) аркуша. На фінальному етапі викликається метод
AutoFit(), що автоматично підлаштовує ширину кожної колонки під обсяг тексту в
ній, після чого користувачу пропонується зберегти готовий файл у форматі .xlsx
через стандартне діалогове вікно SaveFileDialog операційної системи Windows.
3.2 Тестування системи
Тестування програмного забезпечення — це невід'ємний, складний і
критично важливий етап життєвого циклу розробки інформаційних систем (SDLC
- Software Development Life Cycle), спрямований на всебічну перевірку програмного
продукту на наявність дефектів (багів), підтвердження його повної відповідності
початковим технічним вимогам (процес верифікації) та доказ того, що створена
система дійсно вирішує бізнес-задачі кінцевого користувача (процес валідації).
Оскільки розроблений десктопний додаток «Журнал навантаження викладача»
оперує юридично значущими звітними даними, помилки в яких можуть призвести
до викривлення показників навантаження на кафедрі, забезпечення високої якості
коду (Quality Assurance) стало пріоритетним завданням на фінальному етапі
розробки.
Процес тестування здійснювався за стратегією «висхідного тестування»
(Bottom-Up Testing), що передбачає рух від перевірки найдрібніших функцій до
складних інтегрованих модулів. У роботі було застосовано метод «чорного ящика»
(Black-Box Testing), де тестувальник взаємодіє з програмою виключно через
інтерфейс, не заглиблюючись у внутрішню реалізацію коду, що дозволяє
змоделювати поведінку реального викладача. Комплексна перевірка якості була
65
ЧДТУ 26. 2244.019 ПЗ
розділена на чотири ієрархічні рівні: модульне, інтеграційне, системне та
приймальне тестування.
3.2.1 Модульне тестування
Модульне тестування (Unit Testing) є первинним рівнем перевірки, який
полягає у тестуванні найдрібніших, ізольованих і логічно завершених частин
вихідного коду — окремих методів, функцій або класів — на предмет їхньої
коректної роботи за різних вхідних умов. Головною метою цього етапу було
переконатися, що внутрішні алгоритми валідації введених користувачем даних,
складні математичні розрахунки в аналітичних модулях та базові операції CRUD-
циклу (Create, Read, Update, Delete) з об'єктами сутностей працюють безпомилково
і не викликають непередбачуваних виключень чи аварійного завершення програми.
Особлива увага приділялася перевірці «граничних умов» (Edge Cases) — ситуацій,
коли користувач вводить некоректні дані або залишає обов’язкові поля порожніми.
Для досягнення максимальної надійності програмного продукту загальний
обсяг тестового покриття було суттєво розширено. Загалом у процесі модульного
тестування було детально верифіковано 28 ключових функціональних вимог, що
гарантує безперебійність роботи усіх базових підсистем. Такий скрупульозний
підхід дозволив ізолювати та усунути логічні дефекти ще до етапу інтеграції
компонентів, зокрема у механізмах розрахунку статистики. Кожен розроблений
тестовий сценарій передбачав сувору перевірку фактичного результату на
відповідність очікуваному із ретельною фіксацією будь-яких відхилень. Це
забезпечило формування міцної основи для подальшого проведення комплексного
приймального тестування додатку. У таблиці 3.4 наведено детальну
репрезентативну вибірку сценаріїв модульного тестування компонентів графічного
інтерфейсу та локальної бізнес-логіки.
66
ЧДТУ 26. 2244.019 ПЗ
Таблиця 3.4
Результати модульного тестування ізольованих компонентів системи
Опис тестового
Фактичний
№ сценарію (Дія Очікуваний результат Статус
результат (Actual
з/п користувача / виклик (Expected Result) (Pass/Fail)
Result)
методу)
Авторизація:
Відображено
Натискання кнопки Локальна валідація має
червоний текст
«Увійти» при залишенні заблокувати SQL-запит
1 «Введіть логін та Успішно
полів «Логін» та до БД та вивести
пароль!». Запит до
«Пароль» повністю візуальне попередження.
бази не відправлено.
порожніми.
Авторизація: Введення Виведено
Система повинна
синтаксично стандартне
повернути помилку
некоректних даних повідомлення
2 авторизації, зберігаючи Успішно
(неіснуючий у базі логін «Невірний логін або
конфіденційність
або неправильний пароль». Доступ
існуючих логінів.
пароль). заборонено.
Валідація типів даних
Програма має Збереження
(Журнал): Введення
перехопити помилку відхилено. Показано
текстових символів
3 конвертації та MessageBox з Успішно
(наприклад, "дві") у поле
заблокувати збереження вимогою ввести
«Кількість годин», яке
об'єкта. числове значення.
очікує ціле число.
Цілісність довідників:
Блокування операції Збереження
Спроба збереження нової
_context.Add() через відхилено, поле
4 навчальної дисципліни Успішно
невідповідність Required підсвічено червоним
без введення назви
обмеженню моделі. кольором валідації.
(порожній рядок).
67
ЧДТУ 26. 2244.019 ПЗ
Продовження таблиці 3.4
Опис тестового
№ сценарію (Дія Очікуваний результат Фактичний результат Статус
з/п користувача / (Expected Result) (Actual Result) (Pass/Fail)
виклик методу)
Візуальна система: Усі глобальні ресурси
Тема успішно змінена в
натискання на тумблер кольорів (Background,
5 реальному часі за Успішно
«Темна тема» в меню Foreground) мають змінити
допомогою PaletteHelper.
навігації палітру на Theme.Dark.
Математична логіка:
Обчислено значення +2. В
розрахунок різниці Метод повинен повернути
інтерфейсі встановлено
6 між планом (30 год) та значення +2 та сформувати Успішно
статус
фактом (32 год) у статус «Перепрацювання».
«Перепрацювання».
класі статистики
3.2.2 Інтеграційне тестування
На відміну від модульного, інтеграційне тестування (Integration Testing)
спрямоване на виявлення дефектів у взаємодії між різними програмними модулями,
коли вони об'єднуються у цілісні підсистеми. У розробленому додатку головним
завданням на цьому етапі була перевірка коректності передачі даних між рівнем
графічного представлення (Front-end), об'єктно-реляційним прошарком (Entity
Framework Core) та фізичним рівнем зберігання інформації (SQLite).
Також критично важливо було перевірити логіку збереження реляційної
цілісності даних при виконанні складних операцій видалення. Окрім цього,
ретельній перевірці підлягала взаємодія аналітичного модуля з підсистемою
експорту (ClosedXML), щоб гарантувати точне та безперебійне перенесення
зведеної статистики у кінцевий документ. Для підтвердження достовірності
наскрізних алгоритмічних розрахунків навантаження, результати, отримані під час
спільної роботи цих компонентів, додатково верифікувалися за допомогою
обчислювальної системи WolframAlpha. Такий комплексний підхід забезпечив
абсолютну впевненість у відсутності втрат або спотворень інформації при її
транзиті через усі архітектурні шари програми.
68
ЧДТУ 26. 2244.019 ПЗ
Таблиця 3.5
Результати інтеграційного тестування взаємодії підсистем
Опис тестового Фактичний
№ Очікуваний результат Статус
сценарію (Взаємодія результат (Actual
з/п (Expected Result) (Pass/Fail)
компонентів) Result)
UI + БД (Cascade План видалено. У
СКБД SQLite має
Delete): Видалення базі даних
автоматично знищити всі
користувачем "Плану автоматично
1 10 записів журналу Успішно
навантаження", до очищено всі
(тригер каскадного
якого прив'язано 10 пов'язані записи
видалення).
записів у Журналі. журналу.
Статистика + БД
Інтерфейс
(Eager Loading): Система має виконати
статистики миттєво
Додавання в Журнал запит з Include(),
2 відображає оновлені Успішно
запису на 2 години з підсумувати години та
розрахунки та дельту
подальшим переходом оновити прогрес-бар.
виконання.
на вкладку статистики.
UI + Сесія
У верхній панелі
(AppSession):
Система має звернутися головного вікна
Відображення ПІБ
до AppSession.CurrentUserId та коректно
3 авторизованого Успішно
витягти FullName з таблиці відображено повне
викладача в Header-і
Users. ім'я авторизованого
головного вікна після
викладача.
логіну.
UI + БД (Transaction
Транзакцію
Integrity): Спроба База даних має відхилити
відхилено базою.
одночасного додавання транзакцію, EF Core
4 Користувач отримав Успішно
двох однакових повинен викинути
повідомлення про
дисциплін (Unique DbUpdateException.
дублювання назви.
Constraint).
69
ЧДТУ 26. 2244.019 ПЗ
3.2.3 Системне тестування
Системне тестування (System Testing) передбачає перевірку програмного
забезпечення в цілому як єдиного, повністю інтегрованого комплексу у середовищі,
що максимально відповідає реальному. Програма тестувалася як скомпільований
виконуваний продукт (.exe) на комп'ютері з операційною системою Windows 11.
Основна мета — перевірка відповідності системи всім функціональним та
нефункціональним вимогам (продуктивність, стабільність, портативність).
Таблиця 3.6
Результати системного тестування додатку в цільовому середовищі
Очікуваний
№ Характеристика / Фактичний результат Статус
результат (Expected
з/п Тестовий сценарій (Actual Result) (Pass/Fail)
Result)
Автономність Автоматичне
Базу успішно створено.
розгортання: Запуск створення файлу БД
Програма запустилася
1 програми на ПК, де ніколи SQLite, розгортання Успішно
без додаткових
не було файлу таблиць та Seeding
налаштувань.
workload.db. адміна.
Продуктивність (Load Відсутність затримок Завдяки UI
Test): Робота з таблицями (UI lags) при Virtualization у WPF,
2 при наявності 1000+ прокрутці таблиці та таблиця працює Успішно
тестових записів у перемиканні плавно. Час відгуку <
Журналі. вкладок. 0.1 сек.
Формування файлу Файл створено. Дані
Експорт даних (Excel
.xlsx без помилок структуровані, назви
Export): Натискання
3 COM-об'єктів та колонок Успішно
кнопки експорту
коректне відкриття в відформатовані.
згенерованої статистики.
MS Excel. Помилок немає.
70
ЧДТУ 26. 2244.019 ПЗ
Продовження таблиці 3.6
Очікуваний Фактичний
№ Характеристика / Статус
результат (Expected результат (Actual
з/п Тестовий сценарій (Pass/Fail)
Result) Result)
Коректне
Стабільність інтерфейсу: Споживання RAM
вивільнення
Швидке хаотичне стабільне (~100 МБ).
оперативної пам'яті,
4 перемикання між усіма 5 Програма працює Успішно
відсутність Memory
сторінками меню протягом надійно, без
Leaks та критичних
10 хвилин. виключень.
збоїв.
3.2.4 Приймальне тестування
Приймальне тестування (User Acceptance Testing, UAT) — це завершальна
стадія перевірки, яка проводилася з позиції кінцевого цільового користувача
(викладача закладу вищої освіти). Основною метою було підтвердити, що програма
дійсно вирішує поставлену задачу — повну автоматизацію рутинного обліку
навантаження та генерацію звітності.
Таблиця 3.7
Результати приймального тестування програмного комплексу
№ Вимога (Тестовий сценарій) Результат перевірки
1 Авторизація користувача в системі Виконується
2 Керування довідниками дисциплін та груп Виконується
71
ЧДТУ 26. 2244.019 ПЗ
Продовження таблиці 3.7
Результат
№ Вимога (Тестовий сценарій)
перевірки
3 Планування навантаження (встановлення норм) Виконується
4 Облік проведених занять в електронному журналі Виконується
5 Динамічний розрахунок аналітичної статистики Виконується
6 Колірна індикація виконання плану (UI) Виконується
7 Генерація та експорт звітів у формат .xlsx Виконується
8 Клієнтська валідація та обробка помилок вводу Виконується
9 Забезпечення реляційної цілісності даних (CRUD) Виконується
Локальний запуск (Portable-режим) та робота з БД
10 Виконується
SQLite
У таблиці 3.7 наведено результати приймального тестування програмного
забезпечення. Перевірка показала, що система виконує основні функціональні
вимоги, які були визначені на етапі проектування.
Модуль ведення довідників коректно забезпечує введення, редагування та
видалення нормативних даних щодо дисциплін та академічних груп. Модуль
електронного журналу коректно фіксує проведені заняття із жорсткою реляційною
прив’язкою до встановленого плану навантаження, забезпечуючи цілісність даних.
Аналітичний модуль динамічно обчислює обсяг відпрацьованих годин,
автоматично виявляє відхилення (недопрацювання чи перепрацювання) від
затвердженого плану та формує візуальну семантичну (колірну) індикацію
72
ЧДТУ 26. 2244.019 ПЗ
результатів. Модуль експорту коректно формує та зберігає звіти у форматі MS
Excel, зберігаючи структуру даних та необхідне форматування.
Також під час приймального тестування було підтверджено, що система є
зручною у використанні як автономний десктопний додаток. Користувацький
інтерфейс на базі технології WPF забезпечує швидку навігацію між розділами,
інтуїтивно зрозуміле керування та миттєвий відгук системи при роботі з локальною
базою даних SQLite. Структуровані звіти, які формує система, забезпечують
викладача всією необхідною інформацією для звітності перед кафедрою та
мінімізують ризики помилок при підрахунках.
Отже, результати приймального тестування підтвердили, що розроблене
програмне забезпечення відповідає поставленим вимогам і може
використовуватись як ефективний інструмент для автоматизованого планування,
оперативного обліку та контролю індивідуального навчального навантаження
викладача.
3.3 Приклади впровадженого програмного комплексу
У даному підрозділі наведено комплексну візуальну демонстрацію готового,
скомпільованого та протестованого десктопного додатку «Журнал навантаження
викладача». Розглянемо основні графічні інтерфейси (екрани) розробленої системи
в хронологічному порядку типового сценарію використання програми кінцевим
користувачем. Демонстрація інтерфейсів підтверджує практичну реалізацію
закладених на етапі проектування архітектурних та дизайнерських рішень, а також
ілюструє дотримання принципів ергономіки та юзабіліті.
Робота з програмним комплексом завжди починається з проходження
процедури ідентифікації та автентифікації. При запуску виконуваного файлу
TeacherWorkloadJournal.exe операційною системою, на екрані користувача
з'являється компактна, мінімалістична форма авторизації, яка зображена на рисунку
3.1. Завдяки програмному відключенню стандартних системних рамок вікна
операційної системи Windows (застосовано параметр XAML WindowStyle="None",
73
ЧДТУ 26. 2244.019 ПЗ
AllowsTransparency="True") та наявності округлених кутів з вираженими
фізичними тінями (через властивість Elevation), вікно виглядає максимально
сучасно і візуально нагадує інтерфейси передових мобільних або веб-додатків.
Користувач повинен ввести свій персональний логін та пароль у відповідні
текстові поля. Для запобігання несанкціонованому візуальному зчитуванню паролю
сторонніми особами (атака типу "Shoulder Surfing"), введення автоматично
приховується стандартними символами крапок завдяки використанню
спеціалізованого компонента PasswordBox. Якщо введені облікові дані не знайдено
в базі даних SQLite, безпосередньо під яскравою акцентною кнопкою входу миттєво
з'явиться червоне текстове повідомлення про помилку, а поле пароля буде
примусово очищено з міркувань безпеки. Лише після коректного вводу даних
ініціюється розгортання основного робочого середовища.
Рисунок 3.1 — Вікно безпеки та автентифікації користувача в системі
74
ЧДТУ 26. 2244.019 ПЗ
Після успішної авторизації користувач потрапляє у головне робоче вікно
інформаційної системи (MainWindow). З лівого боку екрану постійно
відображається статичне навігаційне меню (Sidebar) з чіткими іконками для
швидкого та безперешкодного доступу до всіх існуючих підсистем.
Особливістю реалізованого дизайну є нативна підтримка перемикання
візуальних тем (Theming). Якщо викладач працює у вечірній час доби або просто
віддає перевагу темному стилю оформлення ОС, він може активувати спеціальний
тумблер (ToggleButton) у нижній частині навігаційного меню. Система
використовує механізми динамічної заміни ресурсів Material Design для миттєвої,
плавної зміни кольорової палітри всієї програми (від біло-сірих до темно-синіх та
глибоких графітових відтінків). Це архітектурне рішення значно знижує теплове
випромінювання екрану та зменшує навантаження на зоровий апарат викладача під
час тривалої роботи.
На рисунку 3.2 продемонстровано ключову сторінку формування «Плану
навантаження». Як можна побачити, архітектура сторінки строго відповідає
класичному паттерну Master-Details. Верхня частина містить інтерактивну форму
для конструювання плану: вибору навчальної дисципліни, студентської групи та
виду заняття через зручні випадаючі списки (ComboBox), які автоматично
заповнюються верифікованими даними з відповідних довідників бази даних. Нижня
частина екрану представлена великою інтерактивною таблицею (DataGrid), яка
чітко та структуровано відображає вже заплановані години. Таблиця підтримує
сортування по колонках та дозволяє керувати записами через клік правою кнопкою
миші (викликаючи контекстне меню для редагування або видалення).
75
ЧДТУ 26. 2244.019 ПЗ
Рисунок 3.2 — Інтерфейс підсистеми формування нормативного плану
навантаження
Основним інструментом для щоденної оперативної фіксації виконаної
робочого часу є сторінка «Журнал занять», яка представлена на рисунку 3.3.
Інтерфейс спроектований таким чином, щоб додавання нового запису після кожної
фактично проведеної пари займало абсолютний мінімум зусиль та часу викладача
(мінімізація кількості кліків). Користувач обирає з випадаючого списку потрібний
навчальний план за допомогою вбудованого візуального календаря фіксує точну
дату заняття, текстом прописує тему лекції чи номер практичної роботи та вводить
кількість відпрацьованих академічних годин. Натискання кнопки "Додати" миттєво
переносить цю інформацію у загальну таблицю історії журналу, розміщену в
нижній половині екрану. Це повністю імітує та заміщує логіку ведення класичного
паперового журналу, але з беззаперечними перевагами цифрового сортування,
миттєвого пошуку та відсутності помарок.
76
ЧДТУ 26. 2244.019 ПЗ
Рисунок 3.3 — Електронний журнал для оперативного обліку проведених занять
В кінці звітного місяця, модульного контролю або наприкінці академічного
семестру викладач використовує сторінку «Статистика» (рисунок 3.4). На цьому
екрані програма візуалізує результати своєї фонової аналітичної роботи. Замість
виведення звичайних сухих таблиць або "сирих" цифр, система автоматично
співставляє записи з оперативного журналу з базовим планом навантаження і
формує наочні графічні індикатори прогресу (Progress Bars).
Якщо викладач вже відпрацював усі заплановані години і норма виконана,
прогрес-бар досягає 100% і зафарбовується в заспокійливий зелений колір. Якщо ж
годин вичитано більше, ніж потрібно за затвердженим планом система чітко та
агресивно сигналізує про це червоним текстом («Перепрацювання: +2 год.») та
відповідною зміною кольору індикатора. У верхній частині цієї сторінки також
розміщена головна функціональна кнопка «Експорт в Excel», клік по якій ініціює
програмну генерацію зведеного електронного звіту у форматі .xlsx.
77
ЧДТУ 26. 2244.019 ПЗ
Рисунок 3.4 — Аналітичний дашборд статистики та моніторингу виконання плану
78
ЧДТУ 26. 2244.019 ПЗ
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ
У третьому розділі кваліфікаційної роботи було ґрунтовно, послідовно і
всебічно описано процеси практичної розробки, програмної імплементації,
налаштування інфраструктури та комплексного тестування створеного
програмного забезпечення — десктопного додатку «Журнал навантаження
викладача».
Глибоко аргументовано та науково обґрунтовано вибір сучасного
технологічного стеку: використання передової об'єктно-орієнтованої мови C# на
базі високопродуктивної кросплатформної інфраструктури .NET 8.0, застосування
технології WPF (Windows Presentation Foundation) спільно з відкритою бібліотекою
MaterialDesignThemes для побудови сучасного, чуйного та адаптивного графічного
інтерфейсу, що використовує апаратне прискорення. Також було обґрунтовано
використання вбудованої реляційної СУБД SQLite разом із передовим ORM-
інструментом Entity Framework Core для надійного, безпечного та автономного
зберігання реляційних даних без потреби в інсталяції та підтримці складного
серверного програмного забезпечення.
Було детально розглянуто внутрішню архітектуру системи: від формування
структурної та логічної схем взаємодії підсистем до проектування реляційної
моделі бази даних за сучасним принципом Code-First. Розроблено та програмно
імплементовано п'ять взаємопов'язаних моделей даних (User, Discipline,
StudentGroup, WorkloadPlan, JournalRecord), що повністю покривають предметну
область завдання та забезпечують нормалізацію бази даних до третьої нормальної
форми (3NF). Здійснено глибокий опис внутрішньої логіки роботи основних
програмних компонентів, зокрема механізмів безпечної авторизації через
глобальну сесію, складних LINQ-алгоритмів обчислення аналітичної статистики в
режимі реального часу, валідації користувацького вводу та алгоритму програмного
експорту агрегованих даних за допомогою COM-технологій у формат електронних
таблиць MS Excel.
79
ЧДТУ 26. 2244.019 ПЗ
Для забезпечення високої надійності, безвідмовності розробленого
програмного продукту та його абсолютної готовності до реальної експлуатації було
проведено комплексне багаторівневе тестування (модульне, інтеграційне, системне,
приймальне). Результати тестування, наведені у відповідних таблицях,
документально підтвердили, що всі компоненти системи взаємодіють коректно,
програма стабільно та передбачувано обробляє помилкові дії користувача,
цілісність бази даних гарантовано зберігається завдяки транзакціям та тригерам
каскадного видалення, а загальна продуктивність відповідає найвищим стандартам
розробки десктопного ПЗ.
Наведені наприкінці розділу приклади візуальних інтерфейсів (скріншоти
роботи впровадженої системи) беззаперечно демонструють високу ергономічність
створеного додатку, наявність передових дизайнерських рішень (зокрема нативної
підтримки Dark Mode) та інтуїтивну зрозумілість системи для непідготовленого
користувача. Розроблений програмний комплекс у повному обсязі виконує
поставлені у завданні вимоги щодо автоматизації обліку навчального
навантаження, усуває всі критичні недоліки та ризики ручного паперового
документообігу та є повністю готовим до впровадження і ефективної повсякденної
практичної експлуатації у закладах вищої освіти.
80
ЧДТУ 26. 2244.019 ПЗ
ВИСНОВКИ
У кваліфікаційній роботі було розроблено десктопний програмний комплекс
«Журнал навантаження викладача», призначений для автоматизованого
планування, оперативного обліку, аналітичного моніторингу виконання
індивідуального навчального навантаження науково-педагогічних працівників
закладу вищої освіти та своєчасної генерації звітності.
Було проаналізовано актуальні проблеми, що виникають під час ручного
паперового обліку та контролю індивідуального навчального навантаження
викладачів. Через велику кількість навчальних дисциплін, різноманітність видів
занять, постійні зміни у контингенті студентських груп та необхідність регулярного
математичного перерахунку відпрацьованого часу користувач не може ефективно
та безпомилково відстежувати всі показники навантаження вручну. Також було
розглянуто існуючі аналоги інформаційних систем, визначено їхні ключові
переваги та недоліки. На основі цього було обґрунтовано доцільність створення
власного автономного десктопного програмного комплексу, який поєднує функції
ведення нормативних довідників, формування планів годин, щоденного обліку
занять, та автоматичного розрахунку аналітики виконання плану .
Було виконано проектування програмного забезпечення. Було визначено
предметну область, сформовано словник основних понять, детально описано
функціональні та нефункціональні вимоги до системи та побудовано комплекс
UML-діаграм, які всебічно відображають структуру, компоненти, логіку роботи та
поведінку майбутнього програмного комплексу. У процесі проектування було
визначено, що система має складатися з таких взаємопов'язаних модулів, як
підсистема автентифікації, управління довідниками (дисциплін та груп),
планування навантаження, оперативний електронний журнал занять, а також
аналітичний модуль статистики та підсистема генерації звітів. Такий підхід
дозволив забезпечити високу модульність, зрозумілу тришарову архітектуру та
можливість подальшого розширення системи.
81
ЧДТУ 26. 2244.019 ПЗ
Для розробки програмного комплексу було використано об'єктно-
орієнтовану мову програмування C# (версії 12), високопродуктивну платформу
.NET 8.0, фреймворк Windows Presentation Foundation (WPF), бібліотеку стилів
MaterialDesignThemes, вбудовану СКБД SQLite, ORM-фреймворк Entity Framework
Core та бібліотеку ClosedXML для формування документів формату OpenXML.
Підсистема оперативного обліку (електронний журнал занять) реалізує механізм
фіксації проведених пар із жорсткою реляційною прив'язкою до існуючих планів
навантаження. Модуль статистики в режимі реального часу виконує агрегаційні
обчислення відпрацьованого часу за допомогою LINQ-запитів, автоматично
визначає наявність недопрацювань або перепрацювань годин відносно початкового
плану, розраховує відсоток прогресу та здійснює динамічну колірну семантичну
індикацію елементів інтерфейсу. Модуль експорту забезпечує автоматизоване
формування офіційних звітів у форматі електронних таблиць MS Excel.
Під час тестування розробленого програмного забезпечення було перевірено
запуск додатка, ініціалізацію та автономне розгортання локальної бази даних,
проходження процедури автентифікації користувачів, ведення довідників,
формування планів, щоденне наповнення журналу, роботу аналітичного модуля
розрахунку статистики з прогрес-барами та динамічними кольорами, а також
стабільність механізму експорту звітних файлів. Було проведено модульне,
інтеграційне, системне та приймальне тестування за методом «чорного ящика».
Результати підтвердили, що програмний комплекс працює абсолютно коректно,
своєчасно реагує на задані користувачем операції, стабільно обробляє помилкові дії
вводу завдяки блокам валідації та повністю відповідає сформованим вимогам.
Отже, мету кваліфікаційної роботи досягнуто. У результаті було створено
сучасний десктопний програмний комплекс, який успішно автоматизує моніторинг
ринку навчального навантаження викладача, виявляє відхилення від затвердженого
плану, формує наочну статистику виконання й експортує структуровані звіти в
Excel, суттєво оптимізуючи робочий час науково-педагогічного працівника.
82
ЧДТУ 26. 2244.019 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Pressman, R. S. Software Engineering: A Practitioner’s Approach. 8th Edition. –
McGraw-Hill Education, 2014. – https://www.mheducation.com/
2. Sommerville, I. Software Engineering. 10th Edition. – Pearson, 2015. –
https://www.pearson.com/
3. Fowler, M. UML Distilled: A Brief Guide to the Standard Object Modeling Language. –
Addison-Wesley, 2003. – https://martinfowler.com/books/uml.html
4. Object Management Group. Unified Modeling Language Specification, Version 2.5.1. –
OMG, 2017. – https://www.omg.org/spec/UML/2.5.1/About-UML
5. ISO/IEC/IEEE 12207:2017. Systems and software engineering — Software life cycle
processes. – https://www.iso.org/standard/63712.html
6. ISO/IEC 25010:2011. Systems and software engineering — Systems and software Quality
Requirements and Evaluation. – https://www.iso.org/standard/35733.html
7. Nielsen, J. 10 Usability Heuristics for User Interface Design. – Nielsen Norman Group,
2020. – https://www.nngroup.com/articles/ten-usability-heuristics/
8. Microsoft Documentation. C# Programming Guide. – Microsoft, 2024. –
https://learn.microsoft.com/en-us/dotnet/csharp/
9. Microsoft Documentation. What's new in C# 12. – Microsoft, 2023. –
https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-12
10. Microsoft Documentation. .NET 8 Overview. – Microsoft, 2023. –
https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-8
11. Microsoft Documentation. Windows Presentation Foundation (WPF) Desktop Guide. –
Microsoft, 2024. – https://learn.microsoft.com/en-us/dotnet/desktop/wpf/
12. Smith, J. Patterns - WPF Apps With The Model-View-ViewModel Design Pattern. –
MSDN Magazine, 2009. – https://learn.microsoft.com/en-us/archive/msdn-
magazine/2009/february/patterns-wpf-apps-with-the-model-view-viewmodel-design-
pattern
83
ЧДТУ 26. 2244.019 ПЗ
13. Material Design In XAML Toolkit. Official Documentation and Repository. –
https://github.com/MaterialDesignInXAML/MaterialDesignInXamlToolkit
14. Material Design. Introduction. – Google Design. – https://m3.material.io/
15. Microsoft Documentation. Entity Framework Core Overview. – Microsoft, 2024. –
https://learn.microsoft.com/en-us/ef/core/
16. Microsoft Documentation. Migrations Overview (Entity Framework Core). – Microsoft,
2024. – https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/
17. SQLite. Official Documentation. – SQLite Consortium. –
https://www.sqlite.org/docs.html
18. ClosedXML. Official Documentation and GitHub Repository. –
https://closedxml.readthedocs.io/
19. Microsoft Documentation. Visual Studio 2022 IDE. – Microsoft, 2024. –
https://learn.microsoft.com/en-us/visualstudio/
20. Myers, G. J. The Art of Software Testing. 3rd Edition. – John Wiley & Sons, 2011.
84
ДОДАТКИ
ЗАТВЕРДЖЕНО
Зав. кафедри ПЗАС, професор
С.В. Голуб
«___» _______________ 2026 року
«Програма ведення журналу навантаження викладача»
Специфікація
482.ЧДТУ 26.2244.019
Листів 2
Розробник _______________________ Кобилка Д.В.
(підпис) (прізвище та ініціали)
Керівник ______________________ Салапатов В.І.
(підпис) (прізвище та ініціали)
2026
Позначення Найменування Примітка
482.ЧДТУ 26.2244.019 2
Документація
482.ЧДТУ 262244 12 01 Текст програми
482.ЧДТУ 262244 34 01 Інструкція користувача
482.ЧДТУ 262244 90 01 Графічні матеріали
86
Додаток Б
«Програмна реалізація інформаційної технології ведення журналу навантаження
викладача»
Текст програми
482.ЧДТУ 26.2244.12 01
Листів 14
Розробник _____________________ Кобилка Д.В.
(підпис) (прізвище та ініціали)
2026
482.ЧДТУ 26.2244.12 01 2
Файл: Models/Entities.cs (Сутності бази даних)
C#
using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
namespace TeacherWorkloadJournal.Models
{
public class User
{
[Key]
public int Id { get; set; }
[Required]
[MaxLength(50)]
public string Username { get; set; } = string.Empty;
[Required]
public string PasswordHash { get; set; } = string.Empty;
[MaxLength(100)]
public string FullName { get; set; } = string.Empty;
}
public class Discipline
{
[Key]
public int Id { get; set; }
[Required]
[MaxLength(200)]
public string Name { get; set; } = string.Empty;
public ICollection<WorkloadPlan> WorkloadPlans { get; set; } = new
List<WorkloadPlan>();
}
public class StudentGroup
{
[Key]
public int Id { get; set; }
[Required]
[MaxLength(50)]
public string Name { get; set; } = string.Empty;
public ICollection<WorkloadPlan> WorkloadPlans { get; set; } = new
List<WorkloadPlan>();
}
88
482.ЧДТУ 26.2244.12 01 3
public enum LessonType
{
Лекція,
Практичне,
Лабораторне,
Семінар,
Консультація
}
public class WorkloadPlan
{
[Key]
public int Id { get; set; }
public int DisciplineId { get; set; }
[ForeignKey("DisciplineId")]
public Discipline Discipline { get; set; } = null!;
public int StudentGroupId { get; set; }
[ForeignKey("StudentGroupId")]
public StudentGroup StudentGroup { get; set; } = null!;
[Required]
public LessonType Type { get; set; }
[Required]
public int PlannedHours { get; set; }
public ICollection<JournalRecord> ConductedLessons { get; set; } = new
List<JournalRecord>();
}
public class JournalRecord
{
[Key]
public int Id { get; set; }
public int WorkloadPlanId { get; set; }
[ForeignKey("WorkloadPlanId")]
public WorkloadPlan WorkloadPlan { get; set; } = null!;
[Required]
public DateTime Date { get; set; }
[MaxLength(500)]
public string Topic { get; set; } = string.Empty;
[Required]
public int HoursSpent { get; set; }
}
}
89
482.ЧДТУ 26.2244.12 01 4
Файл: Data/AppDbContext.cs (Контекст бази даних Entity
Framework)
C#
using Microsoft.EntityFrameworkCore;
using TeacherWorkloadJournal.Models;
namespace TeacherWorkloadJournal.Data
{
public class AppDbContext : DbContext
{
public DbSet<User> Users { get; set; } = null!;
public DbSet<Discipline> Disciplines { get; set; } = null!;
public DbSet<StudentGroup> StudentGroups { get; set; } = null!;
public DbSet<WorkloadPlan> WorkloadPlans { get; set; } = null!;
public DbSet<JournalRecord> JournalRecords { get; set; } = null!;
protected override void OnConfiguring(DbContextOptionsBuilder
optionsBuilder)
{
optionsBuilder.UseSqlite("Data Source=workload.db");
}
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
// Створення адміністратора за замовчуванням
modelBuilder.Entity<User>().HasData(
new User
{
Id = 1,
Username = "admin",
PasswordHash = "admin",
FullName = "Адміністратор системи"
}
);
// Налаштування каскадного видалення
modelBuilder.Entity<WorkloadPlan>()
.HasMany(p => p.ConductedLessons)
.WithOne(j => j.WorkloadPlan)
.HasForeignKey(j => j.WorkloadPlanId)
.OnDelete(DeleteBehavior.Cascade);
base.OnModelCreating(modelBuilder);
}
}
}
Файл: AppSession.cs (Керування сесією користувача)
C#
namespace TeacherWorkloadJournal.Core
{
90
482.ЧДТУ 26.2244.12 01 5
public static class AppSession
{
public static int CurrentUserId { get; set; }
public static string CurrentUserName { get; set; } = string.Empty;
public static void ClearSession()
{
CurrentUserId = 0;
CurrentUserName = string.Empty;
}
}
}
Файл: Views/LoginWindow.xaml.cs (Логіка вікна авторизації)
C#
using System.Linq;
using System.Windows;
using TeacherWorkloadJournal.Data;
using TeacherWorkloadJournal.Core;
namespace TeacherWorkloadJournal.Views
{
public partial class LoginWindow : Window
{
public LoginWindow()
{
InitializeComponent();
}
private void LoginButton_Click(object sender, RoutedEventArgs e)
{
string username = UsernameTextBox.Text.Trim();
string password = UserPasswordBox.Password;
if (string.IsNullOrWhiteSpace(username) ||
string.IsNullOrWhiteSpace(password))
{
ShowError("Введіть логін та пароль!");
return;
}
using (var context = new AppDbContext())
{
var user = context.Users.FirstOrDefault(u => u.Username == username
&& u.PasswordHash == password);
if (user != null)
{
AppSession.CurrentUserId = user.Id;
AppSession.CurrentUserName = user.FullName;
MainWindow mainWindow = new MainWindow();
mainWindow.Show();
91
482.ЧДТУ 26.2244.12 01 6
this.Close();
}
else
{
ShowError("Невірний логін або пароль!");
UserPasswordBox.Clear();
}
}
}
private void ShowError(string message)
{
ErrorMessageTextBlock.Text = message;
ErrorMessageTextBlock.Visibility = Visibility.Visible;
}
private void ExitButton_Click(object sender, RoutedEventArgs e)
{
Application.Current.Shutdown();
}
}
}
Файл: Views/StatisticsPage.xaml (Розмітка сторінки
статистики)
XML
<Page x:Class="TeacherWorkloadJournal.Views.StatisticsPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:materialDesign="http://materialdesigninxaml.net/winfx/xaml/themes"
Title="StatisticsPage">
<Grid Margin="30">
<Grid.RowDefinitions>
<RowDefinition Height="Auto"/>
<RowDefinition Height="*"/>
</Grid.RowDefinitions>
<Grid Grid.Row="0" Margin="0,0,0,30">
<StackPanel VerticalAlignment="Center">
<TextBlock Text="Статистика виконання"
Style="{StaticResource
MaterialDesignHeadline4TextBlock}"
Foreground="#1E293B"
FontWeight="Bold"/>
<TextBlock x:Name="TotalHoursTextBlock"
Style="{StaticResource MaterialDesignBody1TextBlock}"
Opacity="0.8"
Margin="0,5,0,0"/>
</StackPanel>
<Button HorizontalAlignment="Right"
Click="ExportToExcel_Click"
92
482.ЧДТУ 26.2244.12 01 7
Style="{StaticResource MaterialDesignRaisedButton}"
Background="#217346"
BorderThickness="0"
Height="45">
<StackPanel Orientation="Horizontal">
<materialDesign:PackIcon Kind="MicrosoftExcel" Width="20"
Height="20" Margin="0,0,10,0"/>
<TextBlock Text="Експорт в Excel" VerticalAlignment="Center"
FontSize="14"/>
</StackPanel>
</Button>
</Grid>
<ScrollViewer Grid.Row="1" VerticalScrollBarVisibility="Auto">
<ItemsControl x:Name="StatisticsItemsControl">
<ItemsControl.ItemTemplate>
<DataTemplate>
<materialDesign:Card Margin="0,0,0,20" Padding="25"
UniformCornerRadius="10" materialDesign:ElevationAssist.Elevation="Dp2">
<StackPanel>
<Grid Margin="0,0,0,10">
<TextBlock Text="{Binding Title, Mode=OneWay}"
Style="{StaticResource
MaterialDesignSubtitle1TextBlock}"
FontWeight="Bold"
FontSize="16"
Foreground="#1E293B"/>
<TextBlock Text="{Binding PercentageText,
Mode=OneWay}"
HorizontalAlignment="Right"
FontWeight="Bold"
FontSize="16"
Foreground="{Binding StatusColor,
Mode=OneWay}"/>
</Grid>
<ProgressBar Value="{Binding ProgressPercentage,
Mode=OneWay}"
Height="12"
Margin="0,5,0,10"
Foreground="{Binding StatusColor,
Mode=OneWay}"
Background="#E2E8F0"
BorderThickness="0"/>
<Grid>
<TextBlock Text="{Binding ProgressText,
Mode=OneWay}"
Style="{StaticResource
MaterialDesignBody2TextBlock}"
Opacity="0.7"
VerticalAlignment="Center"/>
93
482.ЧДТУ 26.2244.12 01 8
<TextBlock Text="{Binding StatusText,
Mode=OneWay}"
HorizontalAlignment="Right"
FontWeight="Bold"
FontSize="14"
Foreground="{Binding StatusColor,
Mode=OneWay}"
VerticalAlignment="Center"/>
</Grid>
</StackPanel>
</materialDesign:Card>
</DataTemplate>
</ItemsControl.ItemTemplate>
</ItemsControl>
</ScrollViewer>
</Grid>
</Page>
Файл: Views/MainWindow.xaml (Розмітка головного вікна та
меню навігації)
XML
<Window x:Class="TeacherWorkloadJournal.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:materialDesign="http://materialdesigninxaml.net/winfx/xaml/themes"
Title="Журнал навантаження викладача" Height="750" Width="1200"
WindowStartupLocation="CenterScreen" Background="{DynamicResource
MaterialDesignPaper}">
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="260"/>
<ColumnDefinition Width="*"/>
</Grid.ColumnDefinitions>
<materialDesign:Card Grid.Column="0" Background="#1E293B"
UniformCornerRadius="0" materialDesign:ElevationAssist.Elevation="Dp4">
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="Auto"/>
<RowDefinition Height="*"/>
<RowDefinition Height="Auto"/>
</Grid.RowDefinitions>
<StackPanel Grid.Row="0" Margin="20,30,20,20">
<materialDesign:PackIcon Kind="BookEducationOutline" Width="50"
Height="50" Foreground="#38BDF8" HorizontalAlignment="Center"/>
<TextBlock Text="НАВАНТАЖЕННЯ" Foreground="White" FontSize="18"
FontWeight="Bold" HorizontalAlignment="Center" Margin="0,10,0,0"/>
<TextBlock x:Name="UserNameTextBlock" Text="Викладач"
Foreground="#94A3B8" FontSize="14" HorizontalAlignment="Center" Margin="0,5,0,20"/>
94
482.ЧДТУ 26.2244.12 01 9
<Separator Background="#334155"/>
</StackPanel>
<StackPanel Grid.Row="1" Margin="0,10,0,0">
<Button Style="{StaticResource MaterialDesignFlatButton}"
Foreground="White" Height="50" Click="NavDictionaries_Click">
<StackPanel Orientation="Horizontal"
HorizontalAlignment="Left" Width="200">
<materialDesign:PackIcon Kind="BookOpenPageVariant"
Width="24" Height="24" Margin="0,0,15,0"/>
<TextBlock Text="Довідники" FontSize="16"
VerticalAlignment="Center"/>
</StackPanel>
</Button>
<Button Style="{StaticResource MaterialDesignFlatButton}"
Foreground="White" Height="50" Click="NavPlan_Click">
<StackPanel Orientation="Horizontal"
HorizontalAlignment="Left" Width="200">
<materialDesign:PackIcon Kind="ClipboardTextClock"
Width="24" Height="24" Margin="0,0,15,0"/>
<TextBlock Text="План навантаження" FontSize="16"
VerticalAlignment="Center"/>
</StackPanel>
</Button>
<Button Style="{StaticResource MaterialDesignFlatButton}"
Foreground="White" Height="50" Click="NavJournal_Click">
<StackPanel Orientation="Horizontal"
HorizontalAlignment="Left" Width="200">
<materialDesign:PackIcon Kind="Checkbook" Width="24"
Height="24" Margin="0,0,15,0"/>
<TextBlock Text="Журнал занять" FontSize="16"
VerticalAlignment="Center"/>
</StackPanel>
</Button>
<Button Style="{StaticResource MaterialDesignFlatButton}"
Foreground="White" Height="50" Click="NavStatistics_Click">
<StackPanel Orientation="Horizontal"
HorizontalAlignment="Left" Width="200">
<materialDesign:PackIcon Kind="ChartPie" Width="24"
Height="24" Margin="0,0,15,0"/>
<TextBlock Text="Статистика" FontSize="16"
VerticalAlignment="Center"/>
</StackPanel>
</Button>
</StackPanel>
<StackPanel Grid.Row="2" Margin="20,0,20,20">
<Separator Background="#334155" Margin="0,0,0,15"/>
95
482.ЧДТУ 26.2244.12 01 10
<StackPanel Orientation="Horizontal"
HorizontalAlignment="Center" Margin="0,0,0,15">
<materialDesign:PackIcon Kind="WeatherSunny"
Foreground="#94A3B8" VerticalAlignment="Center" Margin="0,0,10,0"/>
<ToggleButton x:Name="ThemeToggleButton"
Click="ThemeToggle_Click" Style="{StaticResource
MaterialDesignSwitchToggleButton}"/>
<materialDesign:PackIcon Kind="WeatherNight"
Foreground="#94A3B8" VerticalAlignment="Center" Margin="10,0,0,0"/>
</StackPanel>
<Button Style="{StaticResource MaterialDesignOutlinedButton}"
Foreground="#F87171" BorderBrush="#F87171" Click="Logout_Click">
<StackPanel Orientation="Horizontal">
<materialDesign:PackIcon Kind="Logout"
Margin="0,0,10,0"/>
<TextBlock Text="Вийти з системи"/>
</StackPanel>
</Button>
</StackPanel>
</Grid>
</materialDesign:Card>
<Frame x:Name="MainFrame" Grid.Column="1" NavigationUIVisibility="Hidden"/>
</Grid>
</Window>
Файл: Views/MainWindow.xaml.cs (Логіка навігації та
керування темою)
C#
using System.Windows;
using TeacherWorkloadJournal.Core;
using TeacherWorkloadJournal.Views;
using MaterialDesignThemes.Wpf;
namespace TeacherWorkloadJournal
{
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
// Встановлення ПІБ авторизованого користувача
UserNameTextBlock.Text = AppSession.CurrentUserName;
// Завантаження стартової сторінки
MainFrame.Navigate(new StatisticsPage());
}
private void NavDictionaries_Click(object sender, RoutedEventArgs e)
{
MainFrame.Navigate(new DictionariesPage());
96
482.ЧДТУ 26.2244.12 01 11
}
private void NavPlan_Click(object sender, RoutedEventArgs e)
{
MainFrame.Navigate(new WorkloadPlanPage());
}
private void NavJournal_Click(object sender, RoutedEventArgs e)
{
MainFrame.Navigate(new JournalPage());
}
private void NavStatistics_Click(object sender, RoutedEventArgs e)
{
MainFrame.Navigate(new StatisticsPage());
}
private void Logout_Click(object sender, RoutedEventArgs e)
{
AppSession.ClearSession();
LoginWindow loginWindow = new LoginWindow();
loginWindow.Show();
this.Close();
}
private void ThemeToggle_Click(object sender, RoutedEventArgs e)
{
var paletteHelper = new PaletteHelper();
var theme = paletteHelper.GetTheme();
if (ThemeToggleButton.IsChecked == true)
{
theme.SetBaseTheme(Theme.Dark);
}
else
{
theme.SetBaseTheme(Theme.Light);
}
paletteHelper.SetTheme(theme);
}
}
}
Файл: Views/WorkloadPlanPage.xaml.cs (Бізнес-логіка
планування)
C#
using System;
using System.Linq;
using System.Windows;
using System.Windows.Controls;
using Microsoft.EntityFrameworkCore;
using TeacherWorkloadJournal.Data;
97
482.ЧДТУ 26.2244.12 01 12
using TeacherWorkloadJournal.Models;
namespace TeacherWorkloadJournal.Views
{
public partial class WorkloadPlanPage : Page
{
private AppDbContext _context;
private WorkloadPlan _editingPlan = null;
public WorkloadPlanPage()
{
InitializeComponent();
_context = new AppDbContext();
LoadComboBoxes();
LoadData();
}
private void LoadComboBoxes()
{
DisciplineComboBox.ItemsSource = _context.Disciplines.ToList();
GroupComboBox.ItemsSource = _context.StudentGroups.ToList();
LessonTypeComboBox.ItemsSource = Enum.GetValues(typeof(LessonType));
}
private void LoadData()
{
// Eager loading для відображення повних назв
var plans = _context.WorkloadPlans
.Include(p => p.Discipline)
.Include(p => p.StudentGroup)
.ToList();
PlansDataGrid.ItemsSource = plans;
}
private void SavePlan_Click(object sender, RoutedEventArgs e)
{
if (DisciplineComboBox.SelectedValue == null ||
GroupComboBox.SelectedValue == null || LessonTypeComboBox.SelectedItem == null)
{
MessageBox.Show("Будь ласка, заповніть усі поля з випадаючих
списків.", "Помилка валідації", MessageBoxButton.OK, MessageBoxImage.Warning);
return;
}
if (!int.TryParse(HoursTextBox.Text, out int hours) || hours <= 0)
{
MessageBox.Show("Введіть коректну додатну кількість годин.",
"Помилка валідації", MessageBoxButton.OK, MessageBoxImage.Warning);
return;
}
98
482.ЧДТУ 26.2244.12 01 13
if (_editingPlan == null)
{
// Режим додавання нового
var newPlan = new WorkloadPlan
{
DisciplineId = (int)DisciplineComboBox.SelectedValue,
StudentGroupId = (int)GroupComboBox.SelectedValue,
Type = (LessonType)LessonTypeComboBox.SelectedItem,
PlannedHours = hours
};
_context.WorkloadPlans.Add(newPlan);
}
else
{
// Режим оновлення
_editingPlan.DisciplineId = (int)DisciplineComboBox.SelectedValue;
_editingPlan.StudentGroupId = (int)GroupComboBox.SelectedValue;
_editingPlan.Type = (LessonType)LessonTypeComboBox.SelectedItem;
_editingPlan.PlannedHours = hours;
_context.WorkloadPlans.Update(_editingPlan);
_editingPlan = null;
SaveButton.Content = "ДОДАТИ ПЛАН";
}
_context.SaveChanges();
ClearForm();
LoadData();
}
private void EditPlan_Click(object sender, RoutedEventArgs e)
{
if (PlansDataGrid.SelectedItem is WorkloadPlan selected)
{
_editingPlan = selected;
DisciplineComboBox.SelectedValue = selected.DisciplineId;
GroupComboBox.SelectedValue = selected.StudentGroupId;
LessonTypeComboBox.SelectedItem = selected.Type;
HoursTextBox.Text = selected.PlannedHours.ToString();
SaveButton.Content = "ЗБЕРЕГТИ ЗМІНИ";
}
}
private void DeletePlan_Click(object sender, RoutedEventArgs e)
{
if (PlansDataGrid.SelectedItem is WorkloadPlan selected)
{
var result = MessageBox.Show("Ви впевнені? Це також видалить всі
записи з журналу для цього плану!", "Підтвердження", MessageBoxButton.YesNo,
MessageBoxImage.Question);
if (result == MessageBoxResult.Yes)
{
99
482.ЧДТУ 26.2244.12 01 14
_context.WorkloadPlans.Remove(selected);
_context.SaveChanges();
LoadData();
}
}
private void ClearForm()
{
DisciplineComboBox.SelectedItem = null;
GroupComboBox.SelectedItem = null;
LessonTypeComboBox.SelectedItem = null;
HoursTextBox.Clear();
}
}
}
100
Додаток В
«Програмна реалізація інформаційної технології ведення журналу навантаження
викладача»
Інструкція користувача
482.ЧДТУ 26.2244.34 01
Листів 10
Розробник _____________________ Кобилка Д.В.
(підпис) (прізвище та ініціали)
2026
482.ЧДТУ 26.2244.34 01 2
Спочатку, користувачу необхідно відкрити папку з розробленим
програмним комплексом на локальному комп'ютері. Коли папку відкрито,
користувачу потрібно знайти виконуваний файл під назвою
TeacherWorkloadJournal.exe та двічі натиснути на нього лівою кнопкою миші для
запуску.
Рисунок В.1 – Запуск виконуваного файлу програми
Потім перед користувачем відкриється стартове вікно авторизації в системі.
Наступним кроком треба натиснути на текстове поле «Логін» та ввести свій
унікальний ідентифікатор викладача. Після цього необхідно натиснути на текстове
поле «Пароль» і ввести пароль доступу. Коли логін та пароль введено, користувачу
необхідно натиснути кнопку «Увійти», яка знаходиться під полями вводу.
102
482.ЧДТУ 26.2244.34 01 3
Рисунок Г.2 – Введення облікових даних у вікні авторизації
Якщо всі дії було виконано правильно і дані введені вірно, проект буде
відкрито і користувач побачить головне вікно програми (Дашборд).
Рисунок Г.3 – Відкрите головне вікно програми
103
482.ЧДТУ 26.2244.34 01 4
Для повного розуміння, інструкція написана для послідовного заповнення та
налаштування всіх модулів системи, починаючи від введення довідників до
експорту звіту. Першим кроком необхідно відкрити вкладку «Довідники», для
цього треба натиснути на відповідну кнопку у лівому боковому навігаційному
меню.
Рисунок Г.4 – Відкрита вкладка «Довідники»
Наступним кроком користувачу потрібно додати дисципліну. Для цього у
полі «Назва дисципліни» треба ввести назву предмету (наприклад, Інженерія ПЗ)
та натиснути кнопку «Додати».
Рисунок Г.5 – Відображення доданих даних у таблицях довідника
104
482.ЧДТУ 26.2244.34 01 5
Наступним кроком необхідно перейти до створення плану. Для цього у
лівому меню користувачу треба натиснути на вкладку «План навантаження».
Рисунок Г.6 – Відкрита вкладка «План навантаження»
Коли вкладку відкрито, користувачу необхідно натиснути на випадаючий
список «Дисципліна» та обрати потрібний предмет із тих, що були створені
раніше. Наступним кроком треба натиснути на випадаючий список «Група» та
обрати академічну групу. Далі необхідно натиснути на список «Тип заняття» та
вибрати формат проведення (Лекція, Практична або Лабораторна). Наступним
кроком користувачу треба звернути увагу на поле «Кількість годин», це поле
відповідає за норму навантаження, сюди необхідно ввести числове значення
запланованих годин.
Рисунок Г.7 – Заповнена форма плану навантаження
105
482.ЧДТУ 26.2244.34 01 6
Після того як користувач ввів всі необхідні йому налаштування, потрібно
натиснути кнопку «Зберегти план». Якщо всі дії було виконано правильно, новий
план навантаження одразу з'явиться у нижній таблиці на екрані.
Рисунок Г.8 – Збережений план у загальній таблиці
Наступним кроком для щоденної фіксації проведених пар користувачу
необхідно у лівому меню натиснути кнопку «Журнал занять».
Рисунок Г.9 – Відкрита вкладка «Журнал занять»
Щоб внести інформацію про проведену пару, користувачу необхідно
натиснути на кнопку «Додати запис». Коли форму відкрито, першим кроком
необхідно обрати «План навантаження» з відповідного випадаючого списку.
Наступним кроком необхідно натиснути на поле «Дата» і за допомогою
вбудованого календаря обрати день, коли була проведена пара. Далі користувачу
106
482.ЧДТУ 26.2244.34 01 7
потрібно натиснути на текстове поле «Тема заняття» та ввести короткий опис
вичитаного матеріалу. Наступним кроком треба звернути увагу на поле
«Відпрацьовано годин», сюди потрібно ввести кількість витрачених академічних
годин.
Рисунок Г.10 – Введення даних про проведене заняття
Після того як всі поля заповнені, користувачу необхідно натиснути кнопку
«Зберегти запис у журнал». Якщо всі дії було виконано правильно, новий запис
відобразиться у головній таблиці журналу занять.
Рисунок Г.11 – Відображення запису в таблиці журналу
107
482.ЧДТУ 26.2244.34 01 8
Коли вкладку «Статистика» відкрито, користувач побачить програмно
розраховані відсотки виконання плану та прогрес-бари по кожній дисципліні. Для
зручності орієнтування, якщо кількість проведених годин перевищує заплановану
норму, система автоматично змінить колір прогрес-бара на червоний, що сигналізує
про перепрацювання.
Рисунок Г.12 – Індикація прогресу та перепрацювань
Наступним та фінальним кроком у роботі з даними є експорт звіту. Для цього
користувачу необхідно натиснути кнопку «Експорт в Excel», яка знаходиться у
верхній частині вікна статистики.
Рисунок Г.13 – Натискання кнопки експорту
108
482.ЧДТУ 26.2244.34 01 9
Після натискання відкриється системне вікно збереження файлу.
Користувачу потрібно обрати місце на комп'ютері, куди він хоче зберегти звіт, та
натиснути кнопку «Зберегти».
Рисунок Г.14 – Системне вікно збереження файлу .xlsx
Якщо все було виконано правильно, програма згенерує файл, і користувач
отримає повідомлення про успішне збереження звіту. Додатково, для зміни
візуального оформлення програми, користувач може натиснути на перемикач
«Темна тема» у лівому нижньому куті вікна програми.
Рисунок Г.15 – Перемикання інтерфейсу на темну тему
109
482.ЧДТУ 26.2244.34 01 10
Для того, щоб завершити роботу та вийти з системи, користувачу
ОБОВ'ЯЗКОВО треба натиснути кнопку «Вийти», яка знаходиться в самому низу
лівого бокового меню.
Рисунок Г.16 – Кнопка виходу з системи
Після виконання користувачем цих дій, сесія закриється і програма перейде
в стартове положення до вікна авторизації.
110
Додаток Г
«Програмна реалізація інформаційної технології ведення журналу навантаження
викладача»
Графічні матеріали
482.ЧДТУ 26.2244.90 01
Листів 14
Розробник _____________________ Кобилка Д.В.
(підпис) (прізвище та ініціали)
2026
482.ЧДТУ 26.2244.90 01 2
Рисунок Г.1 – Тема роботи
Рисунок Г.2 – Мета та практична цінність
113
482.ЧДТУ 26.2244.90 01 3
Рисунок Г.3 – Аналіз технічної Інформації щодо предметної області
Рисунок Г.4 – Актуальність розробки програмного комплексу
114
482.ЧДТУ 26.2244.90 01 4
Рисунок Г.5 – Порівняльний аналіз існуючих засобів обліку
Рисунок Г.6 – Аналіз способів та архітектурних підходів, рішень
115
482.ЧДТУ 26.2244.90 01 5
Рисунок Г.7 – Технічна постановка задачі розробки
Рисунок Г.8 – Розділ 2
116
482.ЧДТУ 26.2244.90 01 6
Рисунок Г.9 – Аналіз вимог та результати архітектурного проектування
Рисунок Г.10 – Специфікація вимог
117
482.ЧДТУ 26.2244.90 01 7
Рисунок Г.11 – Моделювання прецедентів користувача
Рисунок Г.12 – Діаграми класів та пакетів
118
482.ЧДТУ 26.2244.90 01 8
Рисунок Г.13 – Діаграма діяльності
Рисунок Г.14 – Діаграма послідовності
119
482.ЧДТУ 26.2244.90 01 9
Рисунок Г.15 – Моделювання поведінки
Рисунок Г.16 – Обгрунтування вибору технологічного стеку розробки
120
482.ЧДТУ 26.2244.90 01 10
Рисунок Г.17 – Структурна та функціональна архітектурні схеми
Рисунок Г.18 – Логічна схема системи та розв’язування даних
121
482.ЧДТУ 26.2244.90 01 11
Рисунок Г.19 – Реляційна структура локальної бази даних
Рисунок Г.20 – Графічний інтерфейс користувача програмного забезпечення
122
482.ЧДТУ 26.2244.90 01 12
Рисунок Г.21 – Якість програмного забезпечення: Модульне та інтеграційне
тестування
Рисунок Г.22 – Якість програмного забезпечення: Системне та приймальне
тестування
123
482.ЧДТУ 26.2244.90 01 13
Рисунок Г.23 – Практика довгострокового використання та впровадження
Рисунок Г.24 – Загальні висновки до роботи (частина 1)
124
482.ЧДТУ 26.2244.90 01 14
Рисунок Г.25 – Загальні висновки до роботи (частина 2)
Рисунок Г.26 – Демонстраційне відео
125