Репозиторій ЧДТУ
Репозиторій ЧДТУ зберігає і дозволяє легкий і відкритий доступ до всіх видів цифрового контенту, включаючи текст, зображення, анімовані зображення, MPEG і набори даних
Дізнатися більше
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/9101| Назва: | Мобільний застосунок студента університету: підсистема отримання навчальної інформації |
| Автори: | Заспа, Григорій Олександрович Григоренко, Антон Олексійович |
| Ключові слова: | Мобільний додаток;інформаційно-пошукова підсистема;Flutter;Dart;NestJS;Node.js;PostgreSQL;запити академічних довідок;управління навчальним планом;відображення оцінок;Mobile application;information retrieval subsystem;Flutter;Dart;NestJS;Node.js;PostgreSQL;academic reference queries;curriculum management;grade display |
| Дата публікації: | 10-чер-2025 |
| Короткий огляд (реферат): | АНОТАЦІЯ
Григоренко Антон Олексійович
Підсистема отримання інформації “Студент ЧДТУ”
121 - Інженерія програмного забезпечення
Черкаський державний технологічний університет
Черкаси, 2025
Дипломна робота присвячена розробці підсистеми отримання навчальної
інформації для мобільного застосунку «Студент ЧДТУ». У ній обґрунтовано
актуальність створення єдиного інструменту, що забезпечує швидкий доступ
студентів та викладачів до розкладу занять, індивідуальних навчальних планів,
поточних і історичних оцінок, а також механізмів подання академічних довідок і
анонімного оцінювання викладачів.
Проведено аналіз вимог із використанням інтерв’ю та опитувань, моделювання
предметної області за допомогою UML-діаграм та побудовано архітектуру клієнт-
серверного рішення на основі Flutter/Dart для мобільного клієнта. Використано
PostgreSQL для збереження структурованих.
У роботі описано реалізацію основних модулів підсистеми: динамічне
завантаження навчальних планів, відображення розкладу та оцінок, обробку запитів
на довідки, зміну пароля, анонімне оцінювання викладачів, вибір місця практики й
реєстрацію теми дипломної роботи. ANNOTATION Hryhorenko Anton Oleksiiovych The server part of the mobile application "Student CSTU" 121 - Software engineering Cherkasy State Technical University Cherkasy, 2025 The thesis is devoted to the development of a subsystem for obtaining educational information for the mobile application “Student of the ChSTU”. It substantiates the relevance of creating a single tool that provides students and teachers with quick access to class schedules, individual curricula, current and historical grades, as well as mechanisms for submitting academic transcripts and anonymous teacher evaluation. We analyzed the requirements using interviews and surveys, modeled the subject area using UML diagrams, and built a client-server solution architecture based on Flutter/Dart for the mobile clien. PostgreSQL is used to store structured data. The paper describes the implementation of the main modules of the subsystem: dynamic loading of curricula, display of schedule and grades, processing of requests for information, password change, anonymous evaluation of teachers, selection of an internship place and registration of a thesis topic. |
| URI (Уніфікований ідентифікатор ресурсу): | https://er.chdtu.edu.ua/handle/ChSTU/9101 |
| Розташовується у зібраннях: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Григоренко Антон Олексйович.pdf Restricted Access | 5.46 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«бакалавра»
освітній рівень
на тему: Мобільний застосунок студента університету: підсистема отримання
навчальної інформації
Виконав: студент 4 курсу, групи ПЗ-2104
Спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Григоренко А.О.
(прізвище та ініціали)
Керівник Заспа Г.О.
(прізвище та ініціали)
Рецензент Бутенко М.В.
(прізвище та ініціали)
Черкаси 2025
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
___________ Голуб С. В.
«___» _______________ 2025 року
ЗАВДАННЯ
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Григоренко Антон Олексйович
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Мобільний застосунок студента університету: підсистема отримання
навчальної інформації
Керівник проекту (роботи) Заспа Григорій Олександрович к. т. н., доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « » лютого 2025 року
№
Строк подання студентом проекту (роботи)
2. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління;
вимоги до проекту; календарне планування проекту; управління ресурсами
3. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ;
Існуючі методи та засоби розвʼязання поставлених завдань;
Проектування програмного забезпечення системи;
Розробка та тестування програмного забезпечення;
Реалізація та впровадження результатів;
Висновок;
Список використаних джерел;
Додаток А. Специфікація
Додаток Б. Лістинг програми
Додаток В. Інструкція користувача
Додаток Г. Графічні матеріали
4. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту);
Діаграма класів;
Діаграма пакетів;
Діаграма компонентів;
Діаграма розгортання;
Діаграма діяльності;
Діаграма послідовності;
Діаграма комунікації;
Функціональна схема системи;
5. Консультанти розділів проекту (роботи)
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
6. Дата видачі завдання 24 січня 2025 р.
КАЛЕНДАРНИЙ ПЛАН
Строк
виконання
№
Назва етапів випускної роботи етапів Примітки
п/п
випускної
роботи
1 Постановка задачі 05.12.2025 виконано
2 Підготовка завдання 13.12. 2025 виконано
3 Погодження завдання 16.12.2025 виконано
4 Затвердження завдання 17.01.2025 виконано
Основна стадія
1 Підбір матеріалів 02.02.2025 виконано
2 Аналіз шляхів вирішення поставленої задачі 27.02.2025 виконано
3 Розрахунок основних параметрів роботи 09.03.2025 виконано
4 Вибір кінцевого варіанту проектного рішення 17.03.2025 виконано
5 Оформлення первісної редакції роботи 28.03.2025 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 07.05.2025 виконано
керівником
2 Оформлення пояснювальної записки роботи в 08.05.2025 виконано
кінцевій редакції
3 Попередній захист роботи 13.05.2025 виконано
4 Затвердження роботи 29.05.2025
5 Рецензування роботи 01.06.2025
6 Захист роботи 08.06.2025
Студент _____________________ Григоренко А.О.
(підпис) (прізвище та ініціали)
Керівник проекту (роботи) _____________________ Заспа Г.О.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Григоренко Антон Олексійович
Підсистема отримання інформації “Студент ЧДТУ”
121 - Інженерія програмного забезпечення
Черкаський державний технологічний університет
Черкаси, 2025
Дипломна робота присвячена розробці підсистеми отримання навчальної
інформації для мобільного застосунку «Студент ЧДТУ». У ній обґрунтовано
актуальність створення єдиного інструменту, що забезпечує швидкий доступ
студентів та викладачів до розкладу занять, індивідуальних навчальних планів,
поточних і історичних оцінок, а також механізмів подання академічних довідок і
анонімного оцінювання викладачів.
Проведено аналіз вимог із використанням інтерв’ю та опитувань, моделювання
предметної області за допомогою UML-діаграм та побудовано архітектуру клієнт-
серверного рішення на основі Flutter/Dart для мобільного клієнта. Використано
PostgreSQL для збереження структурованих.
У роботі описано реалізацію основних модулів підсистеми: динамічне
завантаження навчальних планів, відображення розкладу та оцінок, обробку запитів
на довідки, зміну пароля, анонімне оцінювання викладачів, вибір місця практики й
реєстрацію теми дипломної роботи.
Ключові слова: Мобільний додаток, інформаційно-пошукова підсистема,
Flutter, Dart, NestJS, Node.js, PostgreSQL, запити академічних довідок, управління
навчальним планом, відображення оцінок
ANNOTATION
Hryhorenko Anton Oleksiiovych
The server part of the mobile application "Student CSTU"
121 - Software engineering
Cherkasy State Technical University
Cherkasy, 2025
The thesis is devoted to the development of a subsystem for obtaining educational
information for the mobile application “Student of the ChSTU”. It substantiates the
relevance of creating a single tool that provides students and teachers with quick access to
class schedules, individual curricula, current and historical grades, as well as mechanisms
for submitting academic transcripts and anonymous teacher evaluation.
We analyzed the requirements using interviews and surveys, modeled the subject area
using UML diagrams, and built a client-server solution architecture based on Flutter/Dart
for the mobile clien. PostgreSQL is used to store structured data.
The paper describes the implementation of the main modules of the subsystem:
dynamic loading of curricula, display of schedule and grades, processing of requests for
information, password change, anonymous evaluation of teachers, selection of an internship
place and registration of a thesis topic.
Keywords: Mobile application, information retrieval subsystem, Flutter, Dart,
NestJS, Node.js, PostgreSQL, academic reference queries, curriculum management, grade
display
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ .............................................................................. 5
ВСТУП ................................................................................................................................... 6
РОЗДІЛ 1 .............................................................................................................................. 10
ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ ЗАВДАНЬ.
10
1.1 Актуальні проблеми, що виникають в процесі виконання завдань ............ 10
1.2 Методи та засоби, які вже використовуються для усунення проблем та
виконання завдань ....................................................................................................... 11
1.3 Конкретизація завдань роботи ............................................................................. 12
РОЗДІЛ 2 .............................................................................................................................. 14
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ СИСТЕМИ .................... 14
2.1 Моделювання предметної області ....................................................................... 14
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області .................................................................................................... 14
2.1.2 Елементи моделювання предметної області .................................................. 16
2.1.3 Робоча область моделювання .......................................................................... 19
2.2 Формування та аналіз вимог ................................................................................ 21
2.2.1 Формування вимог до програмного забезпечення ........................................ 21
2.2.1.1 Первинні і детальні вимоги ..................................................................... 21
2.2.1.2 Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги ................................................................................................................... 22
2.2.2 Формування вимог за допомогою діаграми прецедентів ............................. 23
2.3 Проектування логічної структури програмного комплексу .......................... 24
2.3.1 Діаграми класів ................................................................................................. 24
2.4 Архітектурне проектування ................................................................................. 28
2.4.1 Діаграма компонентів ...................................................................................... 28
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ................................................................................................................ 29
2.5 Моделювання поведінки системи ........................................................................ 30
2.5.1 Діаграма діяльності .......................................................................................... 30
2.5.2 Діаграма послідовності .................................................................................... 31
ЧДТУ 24.2151.4 ПЗ
Зм Лист № документа Підпис Дата
Розроб. Григоренко. А. О. Літ. Лист Листів.
Керівник Заспа Г. О. Мобільний застосунок [н] 3 80
студента університету:
Н. контр. підсистема отримання ФІТІС,
Затверд. Голуб С. В. Кафедра ПЗАС, ПЗ-2104
навчальної інформації
2.5.3 Діаграма комунікації ........................................................................................ 32
2.5.4 Діаграма скінченного автомату....................................................................... 32
РОЗДІЛ 3 ............................................................................................................................. 33
РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ................... 33
3.1 Розробка програмного комплексу ....................................................................... 33
3.1.1 Обґрунтування вибору засобів реалізації....................................................... 33
3.1.2 Структурно-функціональне моделювання ..................................................... 36
3.1.3 Опис логічної схеми системи .......................................................................... 37
3.1.4 Розробка бази даних ......................................................................................... 38
3.1.5 Розробка інтерфейсу користувача .................................................................. 39
3.1.6 Опис розробки програмних компонентів ...................................................... 40
3.2 Тестування системи ...................................................................................................
3.2.1 Модульне тестування ...........................................................................................
3.2.2 Інтеграційне тестування ......................................................................................
3.2.3 Системне тестування ...........................................................................................
3.2.4 Приймальне тестування .......................................................................................
ВИСНОВКИ ............................................................................................................................
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ...........................................................................
ДОДАТОК А ............................................................................................................................
ДОДАТОК Б ............................................................................................................................
ДОДАТОК В ............................................................................................................................
ДОДАТОК Г ............................................................................................................................
ЧДТУ 24.2151.4 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
CRUD – Create, Read, Update, Delete (операції створення, зчитування,
оновлення, видалення)
UML – Unified Modeling Language (уніфікована мова моделювання)
ВНЗ – Вищий навчальний заклад
HTTP – HyperText Transfer Protocol (протокол передачі гіпертексту)
DTO – Data Transfer Object (об’єкт перенесення даних)
REST – Representational State Transfer («передача стану
представлення»)
SDK – Software Development Kit (комплект засобів розробки)
API – Application Programming Interface (інтерфейс програмування
застосунків)
MVC – Model-View-Controller (модель-подання-контролер)
БД – База даних
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
CRUD – Create, Read, Update, Delete
UML – Unified Modeling Language (уніфікована мова моделювання)
ВНЗ – Вищий навчальний заклад
HTTP – HyperText Transfer Protocol (протокол передачі гіпертексту)
DTO – Data Transfer Object (об’єкт перенесення даних)
REST – Representational State Transfer («передача стану представлення»)
SDK – Software Development Kit (комплект засобів розробки)
API – Application Programming Interface (інтерфейс програмування
застосунків)
MVC – Model-View-Controller (модель-подання-контролер)
БД – База даних
ВСТУП
Актуальність теми зумовлена зростаючими потребами сучасних студентів
та викладачів у оперативному доступі до ключової інформації та зручних каналах
комунікації. Традиційні методи інформування, такі як оголошення на стендах або
електронні листи, є неефективними для оперативного доступу до актуального
розкладу консультацій викладачів, швидкого сповіщення про зміни та
стандартизованого збору зворотного зв'язку про якість викладання.
Відсутність централізованої мобільної системи, яка б об'єднувала ці функції,
призводить до непорозумінь, затримок та зниження ефективності взаємодії в
освітньому процесі. Розробка такої підсистеми є ключовим завданням інженерії
програмного забезпечення, що вимагає системного проектування, архітектурного
планування, вибору оптимальних технологій, розробки, тестування та подальшої
підтримки.
Мобільний застосунок з інтегрованим функціоналом, що надає студентам
можливість швидко переглядати актуальний розклад консультацій викладачів,
отримувати своєчасні пуш-повідомлення про важливі події та залишати відгуки
про викладачів безпосередньо через додаток, значно покращить комунікацію та
прозорість освітнього середовища. Це дозволить мінімізувати рутинні операції,
знизити кількість помилок, підвищити прозорість та оперативність обміну
інформацією між учасниками освітнього процесу. Зростаючі вимоги до захисту
персональних даних, розмежування прав доступу та забезпечення
конфіденційності роблять впровадження такої спеціалізованої системи
необхідним.
Метою роботи є проектування та конструювання програмного забезпечення
з розширенням функціоналу мобільного застосунку студента університету шляхом
створення підсистеми, яка надасть користувачам (студентам та, за необхідності,
викладачам) можливість переглядати розклад консультацій викладачів,
отримувати пуш-повідомлення та брати участь у системі рейтингування й
оцінювання викладацької діяльності. Це сприятиме оптимізації комунікації,
забезпеченню своєчасного інформування та збору зворотного зв'язку для
покращення освітнього процесу, відповідно до сучасних вимог інженерії
програмного забезпечення.
Завдання
Для досягнення поставленої мети було визначено наступні завдання.
1 Провести аналіз та формалізацію функціональних і нефункціональних
вимог до підсистеми мобільного застосунку.
2 Здійснити порівняльний аналіз існуючих аналогів рішень щодо
організації розкладу консультацій, механізмів сповіщень та систем
оцінювання викладачів.
3 Виконати проектування архітектури інформаційної системи, орієнтованої
на модульність, масштабованість та безпеку.
4 Розробити серверні REST-сервіси для обробки запитів, управління
даними розкладу, оцінювання та доставки пуш-повідомлень.
5 Розробити клієнтську частину на Flutter/Dart для забезпечення зручного
та адаптивного користувацького інтерфейсу на мобільних платформах
iOS та Android.
6 Реалізувати механізми автентифікації (на основі JWT) та розмежування
прав доступу.
7 Впровадити інтеграцію з внутрішніми університетськими системами для
отримання актуальних даних про розклад консультацій та викладачів.
8 Забезпечити функціонал формування та доставки миттєвих пуш-
повідомлень через зовнішні API (наприклад, FCM).
9 Провести комплексне тестування програмного забезпечення (модульне,
інтеграційне, системне, віджетове) для забезпечення коректності,
надійності та відповідності вимогам.
Об’єкт розробки
Об’єктом розробки є процес розширення функціоналу мобільного застосунку
"Студент ЧДТУ" шляхом реалізації нової підсистеми, яка включає тісно
взаємопов’язані частини: кросплатформний клієнтський інтерфейс на Flutter/Dart
та серверні REST-сервіси. У сукупності вони утворюють платформу, що дозволяє
користувачам отримувати доступ до розкладу консультацій, отримувати пуш-
повідомлення та надавати оцінку викладачам у режимі реального часу, а також
забезпечує надійну основу для подальшого розширення функціоналу.
Інструментарій
Для реалізації програмного забезпечення було використано сучасні засоби та
технології, що дозволили побудувати надійний і масштабований клієнт-серверний
застосунок із підтримкою інтеграції з внутрішніми та зовнішніми сервісами.
1 Серверна частина: розроблена мовою програмування Java з
використанням фреймворку Spring Boot для створення REST API,
обробки запитів, реалізації авторизації (на основі JWT), валідації даних та
гнучкої конфігурації. Для зберігання інформації використано реляційну
базу даних PostgreSQL. Збирання та керування залежностями
здійснювалося за допомогою системи Gradle.
2 Клієнтська частина: реалізована з використанням мови Dart та
кросплатформного фреймворку Flutter, що дозволило побудувати
динамічний, багатофункціональний інтерфейс користувача з підтримкою
єдиної кодової бази для платформ iOS та Android. Для створення
адаптивного й зручного інтерфейсу застосовувалась бібліотека
компонентів, сумісна з Material Design.
3 Інтеграції: Реалізовано інтеграцію з Firebase Cloud Messaging (FCM)
для надійної та оперативної доставки пуш-повідомлень. Також
передбачено інтеграцію з внутрішніми університетськими системами
(через відповідні API) для синхронізації довідкових даних про розклад
консультацій та викладачів.
Методи проектування та конструювання
У процесі розробки програмного забезпечення було використано сукупність
сучасних підходів до проектування та реалізації інформаційних систем, які
забезпечують логічну побудову архітектури, масштабованість і зручність
підтримки. Ці методи дозволили ефективно організувати роботу над системою
відповідно до вимог до якості та безпеки програмного забезпечення в освітній
сфері. Зокрема, застосовано такі методи:
декомпозиція: розбиття системи на окремі логічні модулі та компоненти
(модулі розкладу консультацій, повідомлень, оцінювання викладачів,
авторизації);
об’єктно-орієнтоване проектування: побудова структури програмного
забезпечення з урахуванням принципів інкапсуляції, наслідування та
поліморфізму;
моделювання UML: візуалізація структури та взаємодії компонентів за
допомогою діаграм класів, прецедентів, діяльності, послідовності та
станів для детального розуміння системи;
інкрементальна розробка: реалізація функціоналу частинами з
поступовим нарощуванням можливостей системи;
принцип розділення відповідальностей (SRP): чітке розмежування
логіки за призначенням компонентів системи;
конструювання з можливістю перевірки: реалізація функцій з
орієнтацією на тестування та модульну перевірку працездатності.
Опис отриманих результатів
У результаті виконання роботи було розроблено програмне забезпечення
підсистеми мобільного застосунку "Студент ЧДТУ", що автоматизує доступ до
розкладу консультацій викладачів, забезпечує функціонал пуш-повідомлень та
інтегрує систему оцінювання викладачів. Система має модульну клієнт-серверну
архітектуру, простий і зручний інтерфейс, а також реалізовану автентифікацію
користувачів із розмежуванням ролей.
Практичне значення отриманих результатів
Розроблене програмне забезпечення має значне практичне значення для
освітнього процесу:
оптимізує комунікацію: забезпечує оперативний доступ до розкладу
консультацій та миттєве доведення важливих повідомлень до студентів і
викладачів;
покращує ефективність взаємодії: зменшує час на пошук інформації та
усуває необхідність у ручних способах обміну даними;
сприяє підвищенню якості викладання: надає стандартизований та
зручний механізм збору зворотного зв'язку від студентів, що є цінним для
адміністрації університету;
забезпечує прозорість та актуальність: інформація про розклад та
оцінки є централізованою та доступною в режимі реального часу;
підвищує мобільність: дозволяє студентам та викладачам управляти
своєю діяльністю та взаємодіяти з системою через мобільні пристрої.
Програма відповідає сучасним вимогам до збереження, структурування та
захисту освітньої інформації, сприяючи цифровізації університетського
середовища.
Особистий внесок автора
Особистий внесок автора полягає у:
проведенні аналізу предметної області та існуючих рішень у сфері
мобільних застосунків для освітніх установ;
розробці концептуальної та логічної моделі інформаційної системи
(UML-діаграми);
проектуванні архітектури програмного забезпечення та реляційної бази
даних;
реалізації серверної частини програмного забезпечення з використанням
Java, Spring Boot та PostgreSQL;
реалізації клієнтської частини програмного забезпечення з
використанням Flutter та Dart, включаючи розробку користувацького
інтерфейсу;
налаштуванні інтеграції з зовнішніми сервісами (FCM) та внутрішніми
університетськими системами через REST API;
проведенні комплексного тестування розробленої системи на різних
рівнях (модульне, інтеграційне, системне, віджетове).
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1 Актуальні аспекти, що виникають в процесі виконання завдань
Під час розробки підсистеми мобільного застосунку виникають труднощі,
пов’язані з інтеграцією даних із різних внутрішніх джерел університету, які можуть
містити інформацію, необхідну для формування розкладу консультацій викладачів,
отримання даних про викладачів для системи рейтингування, або ініціювання пуш-
повідомлень. Кожна з цих підсистем може використовувати власні формати та
структури даних, що ускладнює створення єдиної моделі даних для клієнтського
застосунку. Розробка проміжного шару - адаптерів для трансформації, валідації та
нормалізації інформації - потребує ретельного аналізу вихідних даних та оновлення
цих компонентів при змінах у внутрішніх сервісах.
Забезпечення своєчасного оновлення даних, зокрема розкладу консультацій,
передбачає баланс між продуктивністю і правдивістю інформації. Часті звернення
до сервера можуть його навантажувати, а великі інтервали оновлень призводять до
затримки відображення актуальних змін. Пошук оптимальної стратегії оновлення
потребує ретельного тестування.
Реалізація системи рейтингування та оцінювання викладачів натрапляє на
складнощі, пов'язані із забезпеченням анонімності, прозорості механізму
оцінювання та уникненням можливості маніпуляцій. Необхідно розробити чіткі
алгоритми збору, зберігання та агрегації оцінок.
Питання безпеки й конфіденційності даних користувачів, включаючи
інформацію про консультації, історію повідомлень та результати оцінювання,
лишається ключовим: слід забезпечити шифрування даних і захист каналів
передачі. Налаштування ролей і прав доступу, зокрема для управління розкладом
консультацій чи розсилкою повідомлень, вимагає чіткого документування і
перевірки всіх сценаріїв.
На рівні мобільного UI [10] складно гарантувати однакову якість взаємодії на
різних пристроях і версіях ОС [11]. Відображення довгих списків консультацій або
історії повідомлень може вимагати оптимізації. Необхідно впровадити
адаптивність і провести тестування на ширшій вибірці екранів. Продуктивність і
масштабованість бекенду [12] стають критичними під час піків активності —
наприклад, під час масової розсилки пуш-повідомлень або у період активного
оцінювання викладачів. Без запровадження кешування, пулінгу з’єднань та інших
оптимізацій сервер може не витримати навантаження, що призведе до збільшення
часу відповіді й перебоїв у роботі.
1.2 Методи та засоби, які вже використовуються для усунення
проблем та виконання завдань
Для вирішення задач узгодження даних із різних внутрішніх систем та
формування єдиної моделі застосовується шар адаптерів [13], який відповідає за
перетворення й нормалізацію вхідних записів з джерел, що містять дані для
розкладу консультацій, інформацію про викладачів та тригери для повідомлень.
Щоб гарантувати коректність і повноту даних, перед записом до бази
виконується централізована валідація. Правила перевірки описуються один раз і
застосовуються у всіх випадках прийому запитів (наприклад, при збереженні
розкладу консультацій чи результатів оцінювання).
Для підтримки актуальності інформації без надмірного навантаження на
сервер впроваджено механізм подачі оновлень за подіями або з використанням
оптимальних інтервалів запитів, що стосується, зокрема, розкладу консультацій.
Часто запитувані дані, наприклад, розклад консультацій викладачів або
зведені дані для рейтингування, кешуються з обмеженим терміном життя. Це дає
змогу віддавати відповіді на типові запити майже миттєво, знижуючи
навантаження на основну базу даних.
Захист конфіденційної інформації забезпечується за допомогою токен-
орієнтованої моделі авторизації та чіткої ролевої моделі доступу. Кожному типу
користувача (студент, викладач, адміністратор) призначені власні права на читання
й зміну даних, що виключає випадковий або несанкціонований доступ до
інформації про консультації, пуш-повідомлення чи рейтинги викладачів.
У клієнтському інтерфейсі застосовано підхід «поетапного завантаження»
даних та розбиття довгих списків на сторінки для відображення, наприклад,
розкладу консультацій або історії повідомлень. Це допомагає зберегти плавність
роботи програми.
Для забезпечення стабільності розробки та швидкого реагування на помилки
налаштовано автоматизовану збірку та тестування. Після кожного виправлення
коду запускаються комплекти модульних і інтеграційних тестів для перевірки
функціоналу розкладу консультацій, пуш-повідомлень та оцінювання викладачів.
Методи:
- шар адаптерів. Метод для узгодження даних із різних внутрішніх систем
та формування єдиної моделі шляхом перетворення й нормалізації
вхідних записів;
- централізована валідація даних. Метод для гарантування коректності та
повноти даних шляхом застосування єдиних правил перевірки перед
записом до бази;
- механізм подачі оновлень за подіями або з оптимальними інтервалами.
Метод для підтримки актуальності інформації без надмірного
навантаження на сервер (наприклад, для розкладу консультацій);
- токен-орієнтована модель авторизації. Метод для забезпечення безпеки та
автентифікації користувачів;
- поетапне завантаження та розбиття списків на сторінки. Метод для
оптимізації клієнтського інтерфейсу, що покращує плавність роботи
програми при відображенні великих обсягів даних;
- автоматизована збірка та тестування. Метод для забезпечення
стабільності розробки та швидкого реагування на помилки шляхом
автоматичного запуску тестів після змін коду.
Засоби:
- адаптери. Конкретні програмні модулі або компоненти, що реалізують
шар адаптерів для перетворення та нормалізації даних;
- механізми публікації/підписки подій або механізми планування запитів:
технічні засоби, що реалізують механізм оновлень за подіями або
інтервальними запитами;
- токени (наприклад, JWT). Ключові засоби для реалізації токен-
орієнтованої авторизації;
- клієнтський інтерфейс (Flutter/Dart). Конкретний програмний засіб, що
використовує підхід поетапного завантаження та пагінації;
- комплекти модульних і інтеграційних тестів. Конкретні реалізації тестів,
написані з використанням фреймворків тестування (наприклад, JUnit,
Mockito, flutter_test).
1.3 Аналіз існуючих аналогів інформаційних систем
Перед початком проектування та розробки нової підсистеми мобільного
застосунку "Студент ЧДТУ" було проведено детальний аналіз існуючих аналогів
інформаційних систем та мобільних додатків, що використовуються в освітній
сфері. Метою цього аналізу було виявлення поширених підходів до організації
освітніх процесів, оцінка їх ефективності та виявлення прогалин, які покликаний
заповнити даний проект. Аналізувалися як комплексні університетські системи, так
і спеціалізовані рішення.
Університетські інформаційні системи та веб-портали (SIS - Student
Information Systems). Це централізовані системи, що забезпечують управління
даними студентів, викладачів, розкладом занять, успішністю, фінансовими
питаннями тощо. Часто мають веб-інтерфейс, через який студенти можуть
отримати доступ до деякої інформаці;
Сильні сторони
1 Централізоване зберігання великих обсягів даних, інтеграція з іншими
внутрішніми системами університету (деканати, бухгалтерія),
забезпечення офіційної інформації.
Слабкі сторони (щодо завдань проекту)
1 Доступ до розкладу консультацій: Інформація про консультації часто є
статичною, публікується у вигляді документів (PDF, DOCX) або
оголошень на веб-сторінках кафедр. Це вимагає від студента постійного
моніторингу, не гарантує актуальності в реальному часі при змінах і
неоптимізовано для мобільного доступу.
2 Система сповіщень: Переважно обмежується електронною поштою або
новинами на порталі, що не забезпечує оперативної та миттєвої доставки
критично важливих повідомлень (наприклад, про раптову відміну
консультації) безпосередньо на мобільний пристрій.
3 Система оцінювання викладачів: Якщо присутня, то, як правило,
реалізована через незручні веб-форми або періодичні опитування, що не
сприяє високій участі студентів та не надає адміністрації оперативних і
повних даних для аналізу.
Системи управління (Moodle, Canvas, Blackboard). Платформи,
призначені для організації навчального процесу: розміщення навчальних
матеріалів, завдань, тестів, оцінок. Багато з них мають мобільні додатки.
Сильні сторони
1 Комплексний функціонал для підтримки навчального курсу, інтерактивні
елементи навчання, можливість базових сповіщень про події в рамках
курсу.
Слабкі сторони (щодо завдань проекту)
1 Доступ до розкладу консультацій: Хоча можуть містити розділ
"Оголошення" або "Форум", вони рідко мають інтегрований,
структурований та централізований функціонал саме для динамічного
розкладу консультацій всіх викладачів університету, що виходить за
рамки конкретного курсу.
2 Система сповіщень: Пуш-нотифікації зазвичай орієнтовані на події
всередині курсу (нові завдання, оцінки), але не на
загальноуніверситетські адміністративні сповіщення чи зміни в розкладі
консультацій, які можуть стосуватися групи студентів поза конкретним
курсом.
3 Система оцінювання викладачів: Механізми оцінювання викладачів як
таких рідко є вбудованими в LMS і зазвичай вимагають використання
зовнішніх інструментів.
Спеціалізовані сторонні мобільні застосунки для розкладу або
комунікації. Окремі мобільні додатки, розроблені сторонніми компаніями або
ентузіастами, що фокусуються на конкретній функції (наприклад, розклад занять,
студентські новини).
Сильні сторони
1 Часто мають сучасний дизайн, високу швидкість роботи та зручний,
орієнтований на мобільні пристрої інтерфейс.
Слабкі сторони (щодо завдань проекту)
1 Інтеграція: Як правило, неінтегровані з внутрішніми
університетськими системами, що вимагає ручного введення та
оновлення даних, створюючи ризик їхньої неактуальності та
дублювання.
2 Комплексність: Рідко поєднують у собі всі три необхідні функції
(розклад консультацій, пуш-повідомлення, оцінювання викладачів) у
єдиному, цілісному рішенні.
3 Надійність: Можуть мати проблеми з довгостроковою підтримкою та
безпекою даних через відсутність офіційної підтримки університету.
Проведений аналіз показав, що жодна з існуючих категорій систем не надає
комплексного, зручного та інтегрованого мобільного рішення, яке б ефективно
вирішувало завдання оперативного доступу до розкладу консультацій викладачів,
миттєвої доставки пуш-повідомлень та прозорої системи оцінювання викладачів.
Існуючі рішення або є занадто загальними, або мають значні функціональні та
технічні обмеження, що впливають на користувацький досвід та актуальність
даних. Це підтверджує актуальність та необхідність розробки нової підсистеми для
мобільного застосунку "Студент ЧДТУ", яка зможе заповнити ці прогалини,
надавши студентам та викладачам сучасний, ефективний та безпечний інструмент
для ключових аспектів їхньої взаємодії.
1.4 Конкретизація завдань роботи
1 З’ясувати потреби користувачів (студентів, викладачів) у функціоналі
перегляду розкладу консультацій викладачів, отриманні пуш-
повідомлень та оцінювання викладачів, сформувати детальний перелік
функціональних і нефункціональних вимог.
2 Розробити логічну та фізичну модель даних, UML-діаграми компонентів
і послідовностей для реалізації REST-API, а також спроектувати
клієнтську частину на Flutter, орієнтуючись на нові функції.
3 Створити проміжний шар для трансформації й нормалізації даних із
внутрішніх систем університету (що містять інформацію про викладачів
та їхній графік консультацій) у єдину схему, придатну для клієнтського
додатку.
4 Побудувати REST-ендпоінти для отримання розкладу консультацій,
управління системою пуш-повідомлень та обробки даних для
рейтингування й оцінювання викладачів, забезпечити їхню валідацію та,
за необхідності, кешування.
5 Реалізувати у Flutter екранні модулі для перегляду розкладу консультацій,
відображення пуш-повідомлень та інтерфейс для оцінювання викладачів.
Налаштувати адаптивне відображення та ефективне завантаження
інформації.
6 Провести юніт [14], інтеграційне [15] й приймальне тестування [16]
клієнтської та серверної частин, зосередившись на коректності роботи
нових функцій, виправити виявлені дефекти й оптимізувати
продуктивність.
7 Підготувати технічну та користувацьку документацію: опис REST-
інтерфейсів для нових функцій, UML-діаграм, інструкцій зі збирання й
розгортання системи та рекомендацій з подальшого супроводу.
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ
У Розділі 1 було проаналізовано ключові аспекти та виклики, що виникають
під час реалізації підсистеми мобільного застосунку "Студент ЧДТУ" з новим
функціоналом: переглядом розкладу консультацій викладачів, системою пуш-
повідомлень та рейтингуванням викладачів.
Актуальні аспекти, окреслені в підрозділі 1.1, включають складнощі
інтеграції з різнорідними внутрішніми системами університету, забезпечення
актуальності та узгодженості даних (особливо для розкладу консультацій), вимоги
до анонімності та прозорості у системі оцінювання викладачів, критичну
важливість безпеки та конфіденційності даних користувачів, а також питання
продуктивності, масштабованості бекенду та адаптивності користувацького
інтерфейсу в умовах зростаючого навантаження від нових функцій.
Для подолання цих проблем, як зазначено в підрозділі 1.2, застосовуються
вже перевірені методи та засоби. Це включає розробку адаптерів для нормалізації
та трансформації даних з внутрішніх джерел, централізовану валідацію вхідних
даних для забезпечення їх коректності, використання механізмів оновлень за
подіями та кешування часто запитуваної інформації для оптимізації
продуктивності. Питання безпеки вирішується за допомогою токен-орієнтованої
авторизації та детальної ролевої моделі доступу. На клієнтській стороні
застосовується поетапне завантаження та розбиття списків на сторінки для
покращення взаємодії, а процес розробки підтримується автоматизованим
тестуванням для забезпечення стабільності та якості.
Конкретизація завдань роботи, викладена в підрозділі 1.34, є прямим
відображенням шляху вирішення ідентифікованих проблем з використанням
згаданих методів. Завдання охоплюють весь життєвий цикл розробки: від
формування детальних вимог до проектування логічної та фізичної моделі даних,
розробки проміжного шару та REST-API, реалізації клієнтської частини на Flutter,
і аж до тестування та підготовки документації. Таким чином, розділ закладає
фундаментальну основу для подальшої розробки, визначаючи рамки та підходи до
створення ефективної підсистеми мобільного застосунку.
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ
2.1 Моделювання предметної області
Моделювання предметної області є фундаментальним етапом у розробці
програмного забезпечення, що передує безпосередньому проектуванню та
кодуванню. Його основна мета – створити чітке, абстрактне представлення
реального світу або конкретної проблемної сфери, яку має автоматизувати система.
Цей процес включає ідентифікацію ключових сутностей, їхніх характеристик
(атрибутів) та взаємозв'язків між ними, а також визначення правил і обмежень, що
діють у цій області. Ефективна модель предметної області слугує спільним
розумінням між усіма зацікавленими сторонами – замовниками, аналітиками,
архітекторами та розробниками – і стає надійною основою для подальшого
проектування бази даних, розробки бізнес-логіки та побудови архітектури
програмного рішення. Вона дозволяє виявити потенційні проблеми та
невідповідності на ранніх етапах, значно знижуючи ризики та вартість розробки.
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області
Предметною областю моделювання є комплексна система взаємодії між
ключовими учасниками освітнього процесу – студентами та викладачами – у
контексті розширеного функціоналу мобільного застосунку "Студент ЧДТУ". Ця
область охоплює низку взаємопов'язаних процесів, спрямованих на оптимізацію
комунікації, інформування та збір зворотного зв'язку, які традиційно були менш
ефективними або розрізненими
1 Організація та надання інформації про консультації: Включає в себе
створення, управління, публікацію та доступ до актуального розкладу
індивідуальних або групових консультацій, що проводяться викладачами.
Ключовим аспектом є забезпечення своєчасного відображення змін та
зручного пошуку інформації для студентів.
2 Обмін важливими повідомленнями: Стосується механізмів доставки
оперативних сповіщень (пуш-повідомлень) від адміністрації, викладачів
або системи до студентів чи груп студентів. Це включає повідомлення про
зміни у розкладі, скасування занять, важливі оголошення або
нагадування.
3 Збір зворотного зв'язку щодо якості викладання: Передбачає
стандартизований та прозорий механізм, що дозволяє студентам
залишати свої оцінки та коментарі щодо викладачів. Цей процес має
забезпечувати анонімність (де це необхідно) та надавати цінні дані для
аналізу та покращення освітнього процесу університетом.
Основна увага приділяється потребам користувачів у мобільному доступі до
актуальної, персоніфікованої інформації та зручних механізмів комунікації та
оцінювання. Моделювання фокусується на виявленні та формалізації сутностей
(таких як студенти, викладачі, розклад, повідомлення, оцінки) та їхніх
взаємозв'язків, а також на логіці процесів, що їх об'єднують. Це дозволяє створити
чітке, структуроване представлення реальності, необхідне для подальшого
проектування бази даних та розробки програмного забезпечення.
Модель предметної області [17] відображає сукупність сутностей і
взаємозв’язків, які необхідні для реалізації підсистеми, що забезпечує перегляд
розкладу консультацій викладачів, функціонал пуш-повідомлень та систему
рейтингування й оцінювання викладачів у мобільному застосунку “Студент
ЧДТУ”. Вона служить основою для побудови UML-діаграм, проектування бази
даних та формування бізнес-логіки.
Основні класи [18] та об’єкти [19] предметної області із врахуванням
поставлених завдань включають
1 Студент - зберігає дані про користувача: ім’я, прізвище, унікальний
ідентифікатор, групу, контактні дані. Ця сутність є ключовою для
ідентифікації користувача, який переглядає розклад консультацій,
отримує повідомлення та залишає відгуки.
2 Викладач - містить інформацію про педагога: ім’я, прізвище, кафедру,
контактні дані. Ця сутність є центральною для функціоналу розкладу
консультацій та системи оцінювання.
3 Група - унікальна назва, рік і тип навчання, список студентів. Може
використовуватися для фільтрації розкладу консультацій або адресування
пуш-повідомлень конкретним групам.
Крім базових об’єктів, до моделі включено сутності, що відповідають за
окремі функціональні блоки нових завдань:
розклад Консультацій - містить інформацію про конкретний час і місце
проведення консультації, пов'язаний з певним Викладачем. Може
включати день тижня, час початку/закінчення, аудиторію;
повідомлення - містить текст повідомлення, дату/час відправлення, тип
повідомлення (системне, про зміну в розкладі тощо) та інформацію про
адресатів (наприклад, конкретний студент, група, чи всі студенти);
оцінювання Викладача - запис, що зв'язує Студента з Викладачем та
містить значення оцінки (наприклад, бали, зірки), текстовий коментар
(відгук) та дату оцінювання.
Зв’язки між класами формалізують такі відношення: «Студент-Група»
(багато до одного), «Викладач–Розклад Консультацій» (один до багатьох),
«Викладач–Оцінювання Викладача» (один до багатьох, де багато записів оцінок
стосуються одного викладача), «Студент–Оцінювання Викладача» (один до
багатьох, де один студент може залишити багато оцінок різним викладачам).
Можливі також зв'язки, що визначають, які Повідомлення отримує конкретний
Студент або Група. Це дозволяє відобразити, яким чином інформація циркулює між
компонентами системи й якими шляхами клієнтський додаток отримує та надсилає
необхідні дані.
Побудована модель предметної області є вихідною точкою для розробки
фізичної схеми бази даних: класи відображаються як таблиці з полями-атрибутами,
а зв’язки - як зовнішні ключі та асоціативні таблиці. Крім того, вона покладає
основу для створення детальних UML-діаграм, які описуватимуть поведінку
сервісів і послідовність викликів у системі, пов'язаних з розкладом консультацій,
пуш-повідомленнями та оцінюванням викладачів.
Використання цієї моделі сприяє узгодженню бачення проекту серед
розробників і зацікавлених сторін, допомагає уникнути дублювання даних та
визначити чіткі обов’язки кожного модуля підсистеми, що реалізує новий
функціонал. Це забезпечує більш ефективний процес подальшого проектування,
реалізації та тестування всіх компонентів мобільного застосунку.
Словник предметної області
Студент – обліковий запис користувача мобільного застосунку, який може
переглядати розклад консультацій, отримувати пуш-повідомлення та залишати
відгуки про викладачів.
Викладач – педагогічний працівник університету, чий розклад консультацій
доступний для перегляду та чия діяльність може бути оцінена студентами через
систему рейтингування.
Група – організаційна одиниця, що об'єднує студентів за напрямом або
курсом; використовується для фільтрації розкладу консультацій та таргетування
пуш-повідомлень.
Розклад Консультацій – інформація про запланований час, місце
проведення та, за необхідності, тематику консультації, що належить певному
викладачу.
Повідомлення – інформаційне сповіщення (пуш-нотифікація), що
надсилається системно студентам або групам щодо важливих подій, змін у розкладі
чи інших оголошень.
Оцінювання Викладача – запис зворотного зв'язку від студента, що містить
значення оцінки (наприклад, бали, зірки) та, за бажанням, текстовий коментар
щодо діяльності конкретного викладача.
Інтеграція з внутрішніми системами – сервіс для синхронізації даних про
розклад консультацій та викладачів з існуючих внутрішніх інформаційних систем
університету.
Firebase Cloud Messaging (FCM) – хмарний сервіс, що використовується для
надійної та оперативної доставки пуш-повідомлень на мобільні пристрої
користувачів.
2.1.2 Елементи моделювання предметної області
У об’єктно-орієнтованому [20] підході першим кроком є виокремлення
ключових сутностей, які відображають предметну область підсистеми. Ці сутності,
наприклад, студенти, викладачі, розклад консультацій, повідомлення та оцінки
викладачів, групуються в класи - логічні контейнери для пов’язаних даних і
поведінки.
Перед початком кодування складається діаграма класів [21] аналітичного
рівня, що служить першим наближенням до статичної моделі системи. Вона
ілюструє основні елементи предметної області (Студент, Викладач, Розклад
Консультацій, Повідомлення, Оцінювання Викладача) та їхні взаємозв’язки
(асоціації, узагальнення, залежності), але не містить деталей реалізації.
Щоб не дублювати терміни в тексті опису випадків використання, цю
діаграму будують до опрацювання сценаріїв. У подальшому під час уточнення
прецедентів модель поповнюється або коригується, але фундаментальні назви та
зв’язки сутностей залишаються незмінними.
Під час виокремлення класів керуються такими правилами: іменники та
іменні групи, що представляють важливі концепції предметної області,
перетворюються на класи чи їхні атрибути, дієслова й дієслівні конструкції - на
операції або асоціації між класами. Визначення в родовому відмінку зазвичай
вказує на атрибут, а не на окремий клас.
Додатково, при формуванні початкового набору класів корисно звертатися
до документації вимог, описів сценаріїв використання (наприклад, "Студент
переглядає розклад консультацій", "Система надсилає пуш-повідомлення",
"Студент оцінює викладача") та отриманих від експертів рекомендацій. Це
гарантує, що жодна важлива концепція, пов'язана з новим функціоналом, не
залишиться поза моделлю й полегшить подальше проектування бази даних [22] і
сервісів [23].
Таким чином, модель предметної області відіграє роль своєрідної «мапи» для
розробки підсистеми, що реалізує функції розкладу консультацій, пуш-
повідомлень та оцінювання викладачів. Вона визначає, які об’єкти і в яких
взаємозв’язках потрібно реалізувати, і стає відправною точкою для створення
фізичної схеми даних і кодування бізнес-логіки сервера та клієнта.
Для моделювання предметної області [24] та системи використовують UML.
Для діаграм цієї мови є три типи візуальних позначень: графічні символи, зв’язки і
текстові позначення (як показано, наприклад, на рисунках 2.1-2.2, які відображають
діаграми класів або інші релевантні схеми для даної предметної області).
Рисунок 2.1 – Графічні символи в UML [49]
Рисунок 2.2 – Поєднувальні елементи в UML [49]
При проєктуванні підсистеми мобільного застосунку необхідно спершу
сформувати модель предметної області (рисунок 2.3) за допомогою базових UML-
діаграм. Діаграми класів для статичної структури, діаграми випадків використання
[25] для вимог, діаграми послідовностей [26] для поведінки та діаграми
компонентів [27] для фізичного розгортання. На етапі виявлення елементів
предметної області важливо зосередитися на ідентифікації ключових сутностей
(студент, викладач, розклад консультацій, повідомлення, оцінювання викладача
тощо) та встановити між ними асоціації, агрегації або узагальнення, не вдаючись
до деталізації атрибутів і методів. Отримана діаграма класів слугує своєрідним ER-
подібним кресленням, яке фіксує зв’язки між об’єктами незалежно від часових
аспектів, а надалі може бути уточнено у фізичній схемі бази даних. Таке поетапне
моделювання гарантує цілісність архітектури та спрощує перехід від аналітики до
реалізації.
2.1.3 Робоча область моделювання
Діаграма класів показує статичну модель підсистеми та відображає ключові
сутності й зв’язки між ними. Кожен прямокутник — це окремий клас, який
інкапсулює набір атрибутів для роботи з певним видом даних: студенти, викладачі,
записи розкладу консультацій, повідомлення та записи оцінювання викладачів.
Завдяки такому представленню можна отримати загальне уявлення про структуру
програми та бачити, які об’єкти існують у системі та як вони взаємодіють.
Взаємозв’язки між класами супроводжуються кардинальністю — наприклад,
один викладач може мати багато записів у розкладі консультацій (Teacher "1" –
“ConsultationSlot”), але кожен запис стосується лише одного викладача. Студент
може залишити багато записів оцінювання (Student "1" -- "" TeacherEvaluation), але
кожен такий запис стосується одного студента та одного викладача
(TeacherEvaluation "" -- "1" Teacher). Повідомлення можуть бути адресовані
конкретним студентам або групам (Student "many" - "many" Notification, Notification
"" - "0..1" Group).
Модель включає ключові сутності, що дозволяють реалізувати основні
функції системи:
управління розкладом консультацій: Класи Teacher та ConsultationSlot
відображають взаємозв'язок між викладачами та їхніми доступними
слотами для консультацій;
формування та доставка пуш-повідомлень: Класи Student, Notification та
Group моделюють систему сповіщень, дозволяючи надсилати
повідомлення як індивідуальним студентам, так і цілим групам
Рисунок 2.3 – Модель предметної області отримання інформації в додатку
підсистеми отримання навчальної інформації
2.2 Формування та аналіз вимог
Формування та аналіз вимог є критично важливим етапом у життєвому циклі
розробки програмного забезпечення. На цьому етапі відбувається збір,
документування, класифікація та детальний розгляд функціональних і
нефункціональних потреб до створюваної підсистеми. Функціональні вимоги
визначають, що саме система повинна робити (наприклад, дозволяти переглядати
розклад консультацій, надсилати пуш-повідомлення, збирати оцінки викладачів),
тоді як нефункціональні вимоги описують якісні характеристики системи
(наприклад, її продуктивність, безпеку, надійність, масштабованість та зручність
використання). Ретельний аналіз отриманих вимог дозволяє виявити потенційні
суперечності, невідповідності та неточності, забезпечуючи їх повноту, чіткість та
узгодженість. Результатом цього етапу є всебічне розуміння того, що має бути
реалізовано, що слугує міцною основою для подальшого проектування архітектури
системи та розробки її компонентів.
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні.
Вимоги замовника і розробника. Функціональні та нефункціональні вимоги
Формування вимог до програмного забезпечення є початковим та
фундаментальним етапом, який забезпечує чітке розуміння того, що повинна
робити система та яким критеріям вона має відповідати. Цей процес включає збір
інформації від усіх зацікавлених сторін, її аналіз, документування та валідацію. В
рамках розробки підсистеми мобільного застосунку "Студент ЧДТУ" вимоги були
сформовані поетапно, від загальних очікувань до детальних технічних
специфікацій, та класифіковані за джерелом (замовник/розробник) та типом
(функціональні/нефункціональні).
Первинні вимоги
Ця група відображає базові очікування користувачів (студентів, викладачів,
адміністрації) щодо нової функціональності:
можливість перегляду актуального розкладу консультацій викладачі;
отримання оперативних пуш-повідомлень про важливі події та зміни;
наявність зручного сервісу для рейтингування та оцінювання викладачів;
На цьому етапі вимоги формулюються простими реченнями, оформлюються
у вигляді коротких описів та діаграм прецедентів [28].
Детальні вимоги
Кожна первинна вимога розбивається на конкретні умови, які дозволяють
реалізувати очікувану поведінку системи:
функціональні умови: перелік REST-ендпоінтів для отримання розкладу
консультацій, надсилання/отримання повідомлень, збору/відображення
даних оцінювання викладачів; формати запитів/відповідей; обов’язкові та
опціональні параметри; правила валідації даних (наприклад, для записів
консультацій чи оцінок); каркас сценаріїв користувача у Flutter для
роботи з новим функціоналом;
нефункціональні умови: час відповіді API для ключових операцій
(наприклад, отримання розкладу консультацій) не більше N мс; підтримка
одночасної роботи Y користувачів; шифрування HTTPS/TLS для захисту
передачі даних про оцінювання; застосування JWT із ролями для
контролю доступу до функцій надсилання повідомлень чи управління
розкладом консультацій; версіонування API; логування ключових подій
системи пуш-повідомлень; адаптивний UI зі швидким відгуком елементів
інтерфейсу для екранів розкладу консультацій, повідомлень та
оцінювання;
умови інтеграції: узгодження форматів обміну з внутрішніми системами
університету, що є джерелом даних для розкладу консультацій або
інформації про викладачів; специфікації адаптерів для трансформації цих
даних; механізми обробки помилок у разі недоступності зовнішніх
сервісів.
Детальні вимоги документуються у вигляді таблиць, критеріїв,
доповнюються діаграмами активностей [29] і послідовностей, що описують
поведінку системи у ключових сценаріях використання нового функціоналу
(наприклад, "Студент переглядає консультації викладача", "Адміністратор
надсилає повідомлення групі", "Студент залишає оцінку викладачу");
Вимоги замовника
1 Доступ до актуального розкладу консультацій викладачів.
2 Отримання push-повідомлень на мобільний пристрій.
3 Можливість оцінювання викладачів та перегляду їхнього рейтингу.
4 Інтуїтивна навігація та зручний інтерфейс.
5 Підтримка безпечного з’єднання та конфіденційності даних
користувачів.
Вимоги розробника
1 Набір чітко визначених REST-ендпоїнтів для всіх операцій.
2 Проміжні шари-адаптери для інтеграції з внутрішніми системами
університету.
3 Централізована валідація й нормалізація вхідних даних.
4 Механізми кешування даних для прискорення доступу.
5 Реалізація надійного механізму push-повідомлень.
6 Модульна архітектура з можливістю горизонтального масштабування.
7 Детальна документація API та зрозумілі конвенції назв у коді.
8 Централізоване логування та моніторинг.
9 Забезпечення належного рівня безпеки даних та контролю доступу
відповідно до ролей.
Функціональні вимоги
1 Доступ до актуального розкладу консультацій викладачів.
2 Отримання push-повідомлень на мобільний пристрій.
3 Можливість оцінювання викладачів та перегляду їхнього рейтингу.
4 Набір чітко визначених REST-ендпоїнтів.
5 Проміжні шари-адаптери для інтеграції з системами університету.
6 Централізована валідація й нормалізація вхідних даних.
7 Механізми кешування даних.
8 Реалізація надійного механізму push-повідомлень.
Нефункціональні вимоги
1 Інтуїтивна навігація та зручний інтерфейс.
2 Підтримка безпечного з’єднання та конфіденційність даних.
3 Модульна архітектура з можливістю горизонтального масштабування.
4 Детальна документація API та зрозумілі конвенції назв.
5 Централізоване логування та моніторинг.
6 Забезпечення належного рівня безпеки даних та контролю доступу.
2.2.2 Формування вимог за допомогою діаграми прецедентів
Метою використання діаграми прецедентів (рисунок 2.4) на цьому етапі є:
визначення основних користувачів системи (акторів);
визначення всіх функціональних можливостей (прецедентів), які система
повинна надавати;
демонстрація взаємозв'язку між акторами та прецедентами, тобто хто і які
дії може виконувати в системі;
встановлення меж системи та її взаємодії з зовнішнім середовищем.
На наданій діаграмі прецедентів зображено "Mobile Application Subsystem"
(Підсистема мобільного застосунку) та три основні актори (користувачі):
Student (Студент):
"View Teacher Consultation Schedule" (Переглянути розклад консультацій
викладача) – студент може переглядати доступний розклад консультацій;
"Rate Teacher" (Оцінити викладача) – студент має можливість залишати
відгуки або оцінки викладачам;
"Receive Push Notification" (Отримати пуш-повідомлення) – студент
отримує миттєві сповіщення від системи.
Teacher (Викладач):
"View Own Rating / Evaluation Results (for Teacher)" (Переглянути власні
результати оцінювання/рейтингу) – викладач може бачити свій рейтинг
або результати оцінювання, залишені студентами.
Administrator (Адміністратор):
"Manage Teacher Rating System" (Керувати системою рейтингу
викладачів) – адміністратор має повноваження керувати процесом
оцінювання викладачів;
"Send Push Notification" (Надіслати пуш-повідомлення) – адміністратор
може розсилати миттєві сповіщення користувачам системи;
"Manage Consultation Schedules" (Керувати розкладом консультацій) –
адміністратор відповідає за внесення та зміну розкладу консультацій
викладачів.
Ця діаграма чітко показує, які дії можуть виконувати різні типи користувачів
у мобільній підсистемі, що є основою для подальшої деталізації функціональних
вимог.
Рисунок 2.4 - Діаграма прецендентів в додатку підсистеми отримання навчальної
інформації
2.3 Проектування логічної структури програмного комплексу
Проектування логічної структури програмного комплексу є ключовим
етапом у розробці системи, що слідує за аналізом вимог. На цьому етапі
відбувається перетворення сформованих функціональних та нефункціональних
вимог у цілісну, послідовну та масштабовану архітектуру. Метою є визначення
основних компонентів системи, їхніх функціональних обов'язків, взаємозв'язків та
інтерфейсів взаємодії. Логічна структура програмного комплексу описує систему з
високого рівня абстракції, зосереджуючись на тому, що вона робить, а не на тому,
як саме це буде реалізовано на технічному рівні. Таке проектування забезпечує
модульність, гнучкість, зручність подальшої розробки та супроводу, а також
дозволяє закласти основи для забезпечення надійності та продуктивності всієї
системи. Результати цього етапу зазвичай візуалізуються за допомогою діаграм
UML, що сприяє кращому розумінню архітектурних рішень усіма учасниками
проекту.
2.3.1 Діаграми класів
Діаграми класів (рисунки 2.4-2.7) у UML відіграють ключову роль у
проектуванні програмного забезпечення, оскільки вони надають детальне
відображення статичної архітектури системи. Кожен клас тут зображується
прямокутником, поділеним на три рівні: ім’я, атрибути та методи, що дозволяє
одночасно побачити і сутність, і її внутрішню структуру. За допомогою зв’язків —
асоціацій, агрегацій, композицій та наслідування — діаграма візуалізує, як об’єкти
взаємодіють між собою, які з них формують складові одного класу, а які є
спеціалізованими відгалуженнями від базових. Детальні маркування ролей,
кратності та напрямків навігації дають можливість чітко передати бізнес-правила:
вказати власників даних, підкреслити залежності, побачити, які класи повинні
об’єднуватися для виконання складних операцій. Крім того, позначення рівнів
доступу (public, private, protected) у поєднанні з підписами методів з аргументами й
типами повернення формують своєрідний контракт, на основі якого команда
розробників генерує шаблони коду та реалізує функціональність. Завдяки такій
уніфікованій моделі предметної області забезпечується не лише узгодженість
архітектурних рішень, а й проста комунікація між учасниками проєкту, оскільки
кожен розуміє, як елементи системи поєднуються в єдину, масштабовану і легко
підтримувану структуру.
Загальна діаграма класів відображає статичну структуру підсистеми
мобільного застосунку "Студент ЧДТУ", представляючи ключові сутності (класи)
та їхні взаємозв'язки. Вона слугує фундаментальною моделлю для проектування
бази даних та реалізації бізнес-логіки. На цій діаграмі показано, як інформація про
студентів, викладачів, розклад консультацій, повідомлення та оцінювання
взаємопов'язана в системі.
Опис діаграми
1 Student (Студент): Представляє користувача додатка.
2 Teacher (Викладач): Представляє педагогічного працівника.
3 Group (Група): Об'єднує студентів.
4 ConsultationSlot (Розклад Консультацій): Описує конкретний час і місце
консультації викладача.
5 Notification (Повідомлення): Представляє системне повідомлення, що
надсилається користувачам.
6 TeacherEvaluation (Оцінювання Викладача): Запис оцінки та коментаря
студента щодо викладача.
Взаємозв'язки
1 Один Teacher може мати багато ConsultationSlots (відношення 1..∗).
2 Один Student може надсилати багато TeacherEvaluations (відношення
1..∗).
3 Один TeacherEvaluation стосується одного Teacher (відношення 1..∗).
4 Student та Notification мають відношення "багато до багатьох" (many
receives many) – один студент може отримувати багато повідомлень, і
одне повідомлення може бути отримане багатьма студентами.
5 Notification може опціонально бути таргетоване на Group (відношення
0..1).
6 На загальній діаграмі класів, Student може бути членом однієї Group
(memberOf 0..∗).
7 Також, відповідно до загальної діаграми класів, Teacher може
опрацьовувати TeacherEvaluations.
Рисунок 2.4 – Загальна діаграма класів в додатку підсистеми отримання
навчальної інформації
Надані діаграми класів відображають ключові сутності та їхні взаємозв'язки
в системі мобільного застосунку:
Діаграма "Teacher" та "ConsultationSlot":
Клас Teacher (Викладач): Представляє сутність викладача. Містить такі
атрибути:
id (UUID): Унікальний ідентифікатор викладача;
firstName (String): Ім’я викладача;
lastName (String): Прізвище викладача;
department (String): Кафедра, до якої належить викладач.
Клас ConsultationSlot (Слот консультації): Представляє доступний час для
консультації. Містить атрибути:
id (UUID): Унікальний ідентифікатор слоту консультації;
dayOfWeek (String): День тижня консультаці;
startTime (Time): Час початку консультації;
endTime (Time): Час завершення консультації;
location (String): Місце проведення консультації;
subjectOrTopic (String): Предмет або тема консультації;
teacherId (UUID): Ідентифікатор викладача, до якого належить цей слот
(зовнішній ключ).
Зв'язок: Між Teacher та ConsultationSlot існує зв'язок "has" (має) з
кардинальністю "1" до "*" (один викладач може мати багато слотів консультацій).
Це означає, що кожен слот консультації пов'язаний рівно з одним викладачем.
Рисунок 2.5 - Діаграма класів "Розклад консультацій викладачів" в додатку
підсистеми отримання навчальної інформації
Діаграма "Student", "TeacherEvaluation" та "Teacher":
Клас Student (Студент): Представляє сутність студента. Містить такі
атрибути:
id (UUID): Унікальний ідентифікатор студента;
firstName (String): Ім'я студента;
lastName (String): Прізвище студента.
Клас TeacherEvaluation (Оцінка викладача): Представляє відгук або оцінку,
надану студентом викладачеві. Містить атрибути:
id (UUID): Унікальний ідентифікатор оцінки;
ratingValue (Number): Значення оцінки (наприклад, число від 1 до 5);
comment (String): Додатковий коментар до оцінки;
submittedAt (DateTime): Дата і час подання оцінки;
studentId (UUID): Ідентифікатор студента, який надав оцінку (зовнішній
ключ);
teacherId (UUID): Ідентифікатор викладача, якого оцінили (зовнішній
ключ).
Зв'язки:
між Student та TeacherEvaluation існує зв'язок "submits" (подає) з
кардинальністю "1" до "*" (один студент може подати багато оцінок);
між TeacherEvaluation та Teacher існує зв'язок "evaluates" (оцінює) з
кардинальністю "*" до "1" (багато оцінок можуть оцінювати одного
викладача).
Рисунок 2.6 - Діаграма класів "Рейтинг та оцінювання викладачів" в додатку
підсистеми отримання навчальної інформації
Діаграма "Student", "Notification" та "Group":
Клас Student (Студент): Той самий клас, що й у попередній діаграмі.
Клас Notification (Повідомлення): Представляє системне повідомлення, що
надсилається користувачам. Містить атрибути:
id (UUID): Унікальний ідентифікатор повідомлення;
text (String): Текст повідомлення;
sentAt (DateTime): Дата і час надсилання повідомлення;
type (String): Тип повідомлення (наприклад, "важливе", "нагадування").
Клас Group (Група):
id (UUID): Унікальний ідентифікатор групи;
name (String): Назва групи.
Зв'язки:
між Student та Notification існує зв'язок "receives" (отримує) з
кардинальністю "many" до "many" (багато студентів можуть отримувати
багато повідомлень). Це вказує на те, що одне повідомлення може бути
надіслано багатьом студентам, і студент може отримати багато
повідомлень;
між Notification та Group існує опціональний зв'язок "targets (optionally)"
(націлює (опціонально)) з кардинальністю "*" до "0..1" (повідомлення
може бути націлене на 0 або 1 групу). Це означає, що повідомлення може
бути загальним або надісланим конкретній групі.
Рисунок 2.7 - Діаграма класів "Пуш-повідомлень" в додатку підсистеми
отримання навчальної інформації
2.3.2 Діаграма пакетів
Діаграми пакетів (Package Diagrams) в UML відіграють критично важливу
роль на етапі архітектурного проектування програмного забезпечення. Вони
слугують інструментом для організації великих і складних систем у керовані,
логічно згруповані одиниці — пакети. Кожен пакет є контейнером для інших
елементів моделі UML, таких як класи, інтерфейси, компоненти або навіть інші
пакети, що дозволяє відобразити високорівневу структуру системи та її
модульність. Основна мета діаграм пакетів — спростити розуміння складної
архітектури, визначити межі підсистем та візуалізувати залежності між ними.
Наведена PlantUML діаграма пакетів детально відображає архітектурний
поділ та взаємодію ключових компонентів програмної системи, імовірно,
пов'язаної з функціоналом деканату та мобільного додатку для студентів. Вона
показує три основні високорівеві логічні групи:
Пакет "DeanOffice Backend
1 Цей пакет представляє основну бекенд-систему, яка, імовірно, керує
даними та логікою деканату.
2 Він містить внутрішні компоненти: api.teacher (API для викладачів),
service (бізнес-логіка), repository (шар доступу до даних) та entity (моделі даних).
3 Його роль полягає у наданні базових функціональних можливостей
системи обліку та управління деканатом.
Пакет "Mobile Backend"
1 Цей пакет є спеціалізованим бекендом, призначеним для обслуговування
мобільного додатку.
2 Він інкапсулює функціонал, орієнтований на мобільних користувачів, та
включає пакети curriculum (навчальні плани), selective (вибіркові
дисципліни) та auth (автентифікація).
3 Його мета — бути проміжною ланкою, що агрегує та адаптує дані з
DeanOffice Backend для потреб мобільного клієнта, а також керує
специфічною для мобільних пристроїв логікою (наприклад, мобільною
автентифікацією).
Пакет "Flutter App"
1 Цей пакет представляє безпосередньо клієнтський мобільний застосунок,
розроблений за допомогою фреймворку Flutter.
2 Він поділений на типові для Flutter архітектурні складові: bloc
(управління станом), models (клієнтські моделі даних), providers
(постачальники даних), widgets (UI-компоненти), screens (екрани
інтерфейсу) та utils (допоміжні утиліти).
3 Його функція - надати інтерфейс користувача та обробляти взаємодію
студента з системою.
Рисунок 2.8 – Діаграма пакетів в додатку підсистеми отримання навчальної
інформації
2.4 Архітектурне проектування
Архітектурне проектування є критично важливим етапом у процесі
створення програмного забезпечення, що слідує за формуванням вимог та логічним
моделюванням предметної області. На цьому етапі відбувається визначення
високоуровневої структури системи, її основних компонентів, їхніх взаємодій, а
також технологій, які будуть використані. Метою архітектурного проектування є
створення стабільної, масштабованої, безпечної та підтримуваної основи, яка
зможе ефективно реалізувати всі функціональні та нефункціональні вимоги. Воно
включає вибір архітектурних стилів (наприклад, клієнт-серверний,
мікросервісний), визначення шарів системи, механізмів інтеграції з зовнішніми
сервісами та баз даних, а також розробку стратегій для забезпечення надійності,
продуктивності та безпеки. Результатом цього етапу є архітектурний опис, який
слугує дорожньою картою для команд розробників та забезпечує узгодженість усіх
частин програмного комплексу.
2.4.1 Діаграма компонентів
Діаграма компонентів (рисунок 2.7) в UML використовується для
моделювання фізичної структури системи. Вона показує компоненти системи, їхні
взаємозв'язки та те, як вони взаємодіють між собою. Компоненти можуть бути
логічними або фізичними, такими як файли, бази даних, бібліотеки, виконувані
файли тощо.
Надана діаграма компонентів для "Mobile Application Subsystem"
(Підсистема мобільного застосунку) ілюструє основні складові системи та їхню
взаємодію:
Mobile Client (Flutter/Dart): Це мобільний застосунок, розроблений за
допомогою технологій Flutter/Dart. Він є основним інтерфейсом для
користувачів;
Backend Application (REST API): Це серверна частина застосунку, яка
надає REST API для взаємодії з мобільним клієнтом. Вона є центральним
вузлом обробки даних;
Database (PostgreSQL): Це база даних, яка використовується бекенд-
застосунком для читання та запису даних. Зокрема, вказано, що
використовується PostgreSQL;
Internal University Systems (Data Source): Це існуючі внутрішні
університетські системи, які слугують джерелом даних. Бекенд-
застосунок інтегрується з ними для отримання необхідної інформації;
Push Notification Service (FCM, APNS, etc.): Це зовнішній сервіс,
відповідальний за надсилання пуш-повідомлень. Бекенд-застосунок
надсилає сповіщення через цей сервіс до мобільних клієнтів.
Взаємодія компонентів:
Mobile Client "Uses API" (Використовує API) Backend Application. Це
означає, що мобільний застосунок звертається до бекенду через його
REST API для отримання та надсилання даних;
Backend Application "Reads/Writes" (Читає/Записує) дані до Database
(PostgreSQL). Бекенд є посередником між клієнтом і базою даних;
Backend Application "Integrates with" (Інтегрується з) Internal University
Systems (Data Source). Це дозволяє бекенду отримувати актуальні дані з
університетських систем;
Backend Application "Sends notifications" (Надсилає сповіщення) до Push
Notification Service. Сервіс пуш-повідомлень потім доставляє їх на
мобільні пристрої.
Рисунок 2.8 – Діаграма компонентів додатку підсистеми отримання навчальної
інформації
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Діаграма розгортання (Deployment Diagram) в UML використовується для
моделювання фізичного розгортання апаратних та програмних компонентів
системи (рисунок 2.8). Вона показує фізичні вузли (наприклад, сервери, пристрої),
які компоненти розгортаються на цих вузлах, та як вони взаємодіють між собою
через мережеві з'єднання.
Надана діаграма розгортання ілюструє, як різні частини вашої системи
розгортаються у реальному фізичному середовищі:
Mobile Device (Мобільний пристрій): Це фізичний пристрій (наприклад,
смартфон або планшет), на якому запускається мобільний застосунок;
всередині: Mobile Client (Мобільний клієнт) – це застосунок, розроблений
для користувачів;
Server / Cloud Environment (Серверне / Хмарне середовище): Це
середовище, де розміщена основна серверна логіка та база даних;
всередині: Backend Server (Бекенд-сервер), на якому виконується Backend
Application (Бекенд-застосунок);
поруч: Database Server (Сервер баз даних), що містить Database (Базу
даних);
Internal University Network (Внутрішня університетська мережа): Це
мережа, що містить існуючі внутрішні системи університету;
всередині: Internal Systems Servers (Сервери внутрішніх систем), де
розміщені Internal University Systems (Внутрішні університетські
системи);
External Network (Зовнішня мережа): Це зовнішня мережа, яка містить
сервіси, що не належать до внутрішньої університетської мережі;
всередині: Push Service Servers (Сервери пуш-сервісів), що надають Push
Notification Service (Сервіс пуш-повідомлень).
Зв'язки та взаємодія:
Mobile Client на Mobile Device "Connects via Internet" (З'єднується через
Інтернет) до Backend Server у Server / Cloud Environment;
Backend Server "Connects to Database" (Підключається до бази даних)
Database Server;
Backend Server "Accesses Internal Systems" (Отримує доступ до внутрішніх
систем) у Internal University Network;
Backend Server "Sends Notifications" (Надсилає сповіщення) до Push
Service Servers у External Network.
Рисунок 2.9 – Діаграма розгортання для теми в додатку підсистеми отримання
навчальної інформації
2.5 Моделювання поведінки системи
Моделювання поведінки системи є невід'ємною частиною процесу
проектування програмного забезпечення, яка доповнює статичне моделювання
структури. Цей етап зосереджується на динамічних аспектах системи, описуючи,
як компоненти взаємодіють між собою та з зовнішнім середовищем у відповідь на
різні події та стимули. Метою є візуалізація потоків даних, послідовності операцій
та станів, через які проходить система під час виконання своїх функцій. За
допомогою діаграм активностей, діаграм послідовностей, діаграм станів та інших
інструментів моделювання поведінки, розробники можуть деталізувати бізнес-
процеси, відстежувати життєвий цикл об'єктів та перевіряти логіку взаємодії, що є
критично важливим для забезпечення коректності, ефективності та надійності
функціонування програмного комплексу.
2.5.1 Діаграма діяльності
Діаграма діяльності (рисунок 2.9) в UML служить для моделювання потоку
робіт або бізнес-процесів у системі, де кожен крок описується як дія (прямокутник
із заокругленими кутами), а напрямок виконання позначається стрілками, що
з’єднують ці кроки. Запуск процесу завжди починається з початкової точки —
наповненого кружка — після чого потік може розгалужуватися в різні боки через
умовні вузли (ромби), які керують вибором наступної дії в залежності від перевірки
певної умови. Якщо необхідно виконати кілька завдань одночасно, модель
використовує спеціальні розгалуження (fork) та їхнє зворотне об’єднання (join), що
дозволяє показати паралельність або синхронізацію підпроцесів. Для
розпізнавання відповідальності за різні етапи процесу діаграми часто розбивають
на swimlane-зони, де кожна така смуга відводиться окремому виконавцю чи
компоненту системи. Завершується процес у кінцевій точці - позначеній подвійним
кружком або кружком із хрестиком - яка сигналізує, що всі заплановані дії
виконані, і процес більше не продовжується. Завдяки такому поєднанню графічних
елементів діаграми діяльності наочно виявляють послідовність операцій, умови
переходів, паралельні гілки виконання та розподіл обов’язків, що дуже допомагає
на етапі аналізу та оптимізації складних робочих процесів.
Надана діаграма діяльності описує процес перегляду розкладу консультацій
у системі, показуючи взаємодію між Користувачем, Мобільним застосунком та
Бекенд Сервісом:
Дії користувача:
користувач відкриває застосунок;
користувач переходить до розділу "Розклад консультацій".
Дії мобільного застосунку:
після переходу до розділу, мобільний фастосунок формує запит на
отримання розкладу;
мобільний застосунок надсилає запит до бекенд сервісу (rest api).
Дії бекенд сервісу:
бекенд сервіс отримує запит;
відбувається перевірка права доступу користувача (точка рішення);
отримує дані розкладу;
обробляє та форматує отримані дані;
формує успішну відповідь;
ні (прав доступу немає): бекенд формує відповідь з помилкою доступу;
бекенд сервіс надсилає відповідь мобільному застосунку.
Подальші дії мобільного застосунку:
мобільний застосунок отримує відповідь від бекенду;
відбувається перевірка відповідь успішна? (точка рішення);
так (відповідь успішна): мобільний застосунок відображає розклад
користувачеві;
ні (відповідь з помилкою): мобільний застосунок відображає
повідомлення про помилку.
Завершальна дія користувача:
користувач переглядає розклад консультацій.
Рисунок 2.10 – Діаграма діяльності в додатку підсистеми отримання навчальної
інформації
2.5.2 Діаграма послідовності
Діаграма послідовності (Sequence Diagram) в UML використовується для
моделювання взаємодії між об'єктами або учасниками системи в часовій
послідовності. Вона показує порядок викликів методів або обміну повідомленнями
між ними для виконання певної функції (рисунок 2.10).
Надана діаграма послідовності ілюструє процес отримання розкладу
консультацій викладача студентом:
Учасники (Lifelines):
Student (Студент): Ініціатор дії, користувач системи;
Mobile Client (Мобільний клієнт): Мобільний застосунок, яким
користується студент;
Backend API (Бекенд API): Серверна частина, яка обробляє запити;
Database (База даних): Зберігає дані розкладу;
Internal Systems (Внутрішні системи): Зовнішні джерела даних, звідки
також можуть надходити дані про розклад.
Рисунок 2.11 – Діаграма послідовності в додатку підсистеми отримання
навчальної інформації
2.5.3 Діаграма комунікації
Діаграма комунікації (Communication Diagram), також відома як діаграма
кооперації або колаборації в попередніх версіях UML, використовується для
моделювання взаємодії між об'єктами, фокусуючись на зв'язках між ними та
порядку обміну повідомленнями. Вона показує, як різні об'єкти співпрацюють для
виконання певної функції, акцентуючи увагу на ролях об'єктів у цій взаємодії
(рисунок 2.11).
Надана діаграма комунікації ілюструє процес отримання оцінок студентом:
Учасники взаємодії:
1 Student (Студент): Ініціатор процесу.
2 SobileApp (Мобільний застосунок): Клієнтська частина, яка взаємодіє зі
студентом та бекендом.
3 APIController (Контролер API): Частина бекенду, яка приймає вхідні
запити від мобільного застосунку.
4 GradeService (Сервіс оцінок): Сервісний шар бекенду, що відповідає за
бізнес-логіку роботи з оцінками.
5 Database (База даних): Місце зберігання даних про оцінки.
Послідовність повідомлень:
1 Студент надсилає "Запит оцінок" до Мобільного застосунку.
2 Мобільний застосунок надсилає "GET /grades" (HTTP-запит) до
APIController.
3 APIController викликає метод "fetchGrades userId" на GradeService.
4 GradeService виконує SQL-запит "SELECT * FROM grades" до Database.
5 Database повертає "gradeData" до GradeService.
6 GradeService повертає "return gradeData" до APIController.
7 APIController надсилає "JSON gradeData" до Мобільного застосунку.
8 Мобільний застосунок виконує "Відобразити оцінки" для Студента.
Рисунок 2.12 – Діаграма комунікації в додатку підсистеми отримання навчальної
інформації
2.5.4 Діаграма скінченного автомату
Діаграма скінченного автомату (State Machine Diagram, або Statechart
Diagram) в UML використовується для моделювання поведінки об'єкта або системи
шляхом відображення її станів та переходів між ними у відповідь на події. Вона
показує можливі стани, в яких може перебувати об'єкт, та правила, за якими він
переходить з одного стану в інший (рисунок 2.12).
Рисунок 2.12 – Діаграма скінченного автомату в додатку підсистеми
отримання навчальної інформації
Надана діаграма скінченного автомату описує життєвий цикл обробки
поданої студентом оцінки (відгуку) викладача:
1 Початковий стан: Позначається чорним колом. Процес починається з
події "Student submits evaluation" (Студент подає оцінку).
2 Submitted (Подано): Це перший стан, у який переходить система після
подання оцінки студентом.
3 Processing (Обробляється): Зі стану "Submitted" система переходить у стан
"Processing" за подією "System starts processing" (Система починає
обробку). У цьому стані оцінка аналізується та обробляється.
4 Переходи зі стану "Processing" (Обробляється): Зі стану "Processing"
можливі два результати, що призводять до різних кінцевих станів.
Completed (Завершено): Перехід відбувається за умови "Processing successful
(e.g., counted in rating)" (Обробка успішна, наприклад, враховано в рейтингу). Це
означає, що оцінка була коректною і успішно оброблена.
Rejected (Відхилено): Перехід відбувається за умови "Processing failed (e.g.,
invalid data, marked as spam)" (Обробка невдала, наприклад, недійсні дані,
позначено як спам). Це означає, що оцінка була відхилена з якихось причин.
Кінцевий стан - позначається колом з чорним колом всередині. Процес
завершується після переходу в стани "Completed" або "Rejected".
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ
У розділі 2 було детально розглянуто процес проектування програмного
забезпечення підсистеми мобільного застосунку "Студент ЧДТУ", що охоплює
функціонал розкладу консультацій викладачів, пуш-повідомлень та систему
оцінювання.
Моделювання предметної області (підрозділ 2.1) стало фундаментальним
етапом, де було ідентифіковано ключові сутності, такі як Студент, Викладач,
Група, Розклад Консультацій, Повідомлення та Оцінювання Викладача, а також
формалізовано їхні взаємозв'язки. Побудована модель предметної області,
візуалізована за допомогою діаграми класів, слугує надійним каркасом для
подальшої розробки бази даних та бізнес-логіки системи.
Підрозділ 2.2 був присвячений формуванню та аналізу вимог. Було чітко
розмежовано первинні (вимоги замовника) та детальні (вимоги розробника)
функціональні та нефункціональні аспекти. Візуалізація вимог за допомогою
діаграми варіантів використання дозволила системно представити очікувану
поведінку системи та взаємодію ключових акторів з новим функціоналом.
На етапі проектування логічної структури програмного комплексу (підрозділ
2.3) акцент було зроблено на діаграмах класів. Ці діаграми деталізували статичну
структуру системи, визначаючи атрибути класів, їхні методи та кардинальність
зв'язків. Цей етап є критично важливим для переходу від концептуальної моделі до
конкретного дизайну, який буде втілений у коді.
Таким чином, розділ 2 забезпечує всебічне проектування програмного
забезпечення, від глибокого розуміння предметної області до детальних
специфікацій вимог та логічної архітектури системи. Представлені моделі та
діаграми є дорожньою картою для розробки, що гарантує послідовність,
узгодженість та ефективність реалізації нового функціоналу.
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1 Розробка програмного комплексу
Розробка програмного комплексу є фазою реалізації, що слідує за етапами
аналізу та проектування, і передбачає безпосереднє створення всіх компонентів
системи відповідно до затвердженої архітектури та детальних вимог. Цей процес
охоплює написання коду для клієнтської (мобільний застосунок) та серверної
частин, конфігурацію баз даних, інтеграцію із зовнішніми сервісами та розгортання
необхідної інфраструктури. На етапі розробки застосовуються обрані технології та
фреймворки, дотримуються стандарти кодування та кращі практики для
забезпечення високої якості, продуктивності та безпеки програмного продукту.
Важливою складовою є також регулярне тестування (модульне, інтеграційне) на
всіх етапах розробки, що дозволяє оперативно виявляти та виправляти дефекти,
забезпечуючи відповідність кінцевого рішення поставленим завданням.
3.1.1 Обґрунтування вибору засобів реалізації
Успішна реалізація підсистеми мобільного застосунку "Студент ЧДТУ", яка
охоплює функціонал перегляду розкладу консультацій викладачів, системи пуш-
повідомлень та рейтингування, ґрунтується на свідомому виборі та ефективному
використанні сучасного стеку технологій. Кожне з обраних рішень було
застосовано для забезпечення високої продуктивності, масштабованості,
надійності та зручності розробки й подальшої підтримки системи.
Для розробки мобільного клієнта було обрано та успішно застосовано
фреймворк Flutter у поєднанні з мовою програмування Dart [30]. Це рішення
дозволило створити кросплатформний [31] застосунок, який функціонує як на
операційних системах iOS, так і на Android, використовуючи єдину кодову базу.
Такий підхід значно прискорив процес розробки, уніфікував користувацький
інтерфейс на різних пристроях та суттєво спростив подальше супроводження
програмного продукту. Завдяки компіляції Dart-коду в машинний код та
ефективному відтворенні інтерфейсу, реалізовані екрани для відображення
розкладу консультацій, управління повідомленнями та інтерфейс оцінювання
викладачів демонструють високу продуктивність та плавність анімації,
забезпечуючи оптимальний користувацький досвід. Для керування складним
станом застосунку, що є характерним для динамічних даних розкладу та потоку
повідомлень, було інтегровано архітектурний патерн BLoC [32] Він забезпечує
чітке відокремлення бізнес-логіки від інтерфейсу користувача, що зробило
розроблений код більш структурованим, легким для тестування та розуміння.
Дизайн користувацького інтерфейсу виконаний відповідно до принципів Material
Design [33], що забезпечило його інтуїтивну зрозумілість, естетичну привабливість
та консистентність на всіх платформах.
Серверна частина системи була реалізована з використанням мови Java [34]
та фреймворку Spring Boot [35]. Java була обрана як основна мова програмування
для бекенду завдяки її доведеній надійності, високій продуктивності та зрілості
екосистеми, що дозволило побудувати стабільне та масштабоване рішення для
обробки великих обсягів даних. Spring Boot був активно застосований для швидкої
та ефективної розробки REST API, значно мінімізуючи необхідну конфігурацію та
дозволяючи розробникам зосередитись безпосередньо на бізнес-логіці. Фреймворк
забезпечує повноцінну підтримку для створення REST сервісів, інтеграції з базами
даних та управлінні безпекою, що є критично важливим для захисту доступу до
розкладів консультацій, обробки конфіденційних даних оцінювання та керування
розсилками повідомлень. Реалізований бекенд демонструє здатність витримувати
значні навантаження, зокрема під час масових розсилок пуш-повідомлень або
пікових періодів активного оцінювання викладачів.
Для системи управління базами даних була обрана PostgreSQL [36]. Ця
потужна реляційна СУБД [37] з відкритим вихідним кодом активно
використовується для зберігання всіх структурованих даних проекту, включаючи
інформацію про студентів, викладачів, групи, детальні записи розкладу
консультацій, результати оцінювання та логування доставлення повідомлень.
PostgreSQL відома своєю високою надійністю, гарантуванням цілісності даних (та
широкими функціональними можливостями, такими як підтримка складних типів
даних та розширені інструменти для оптимізації запитів. Це забезпечило стабільне
та безпечне зберігання критично важливої інформації.
Нарешті, для реалізації функціоналу пуш-повідомлень була успішно
інтегрована платформа Firebase [38] та її сервіс Firebase Cloud Messaging (FCM)
[39]. FCM зарекомендував себе як надійний та масштабований кросплатформний
інструмент від Google [40], який забезпечує ефективну доставку повідомлень на
мобільні пристрої з мінімальними затримками. Його інтеграція була здійснена як
на стороні Flutter-клієнта (через відповідні плагіни), так і на стороні Spring Boot
бекенду, що дозволило централізовано керувати логікою відправки сповіщень про
зміни в розкладі або важливі події. Використання Firebase Console [41] додатково
спрощує керування кампаніями повідомлень та моніторинг їх доставки.
Таким чином, комбінація обраних технологій – Flutter/Dart для фронтенду,
Java/Spring Boot для бекенду, PostgreSQL для зберігання даних та Firebase/FCM для
повідомлень – сформувала потужний, гнучкий та масштабований технологічний
стек, який вже був успішно застосований для розробки та реалізації всіх
функціональних та нефункціональних вимог до підсистеми мобільного застосунку.
3.1.2 Опис структурної (функціональної схеми)
Структурно-функціональне моделювання дозволяє визначити ключові
компоненти системи та їхню взаємодію для реалізації поставлених завдань. У
контексті підсистеми мобільного застосунку "Студент ЧДТУ", бекенд реалізовано
як набір взаємопов'язаних сервісів, кожен з яких інкапсулює певну
функціональність та взаємодіє з клієнтською частиною через REST API. Кожна
підсистема описує собою набір REST контролерів, які засобами Spring Boot
викликаються у відповідь на запити за відповідною URL та HTTP-методом
(рисунок 3.1).
Розглянемо основні підсистеми, що складають програмний комплекс.
Підсистема розкладу консультацій:
Ця підсистема відповідає за управління та надання актуального розкладу
консультацій викладачів. Вона включає ендпоінти для отримання розкладу з
можливістю фільтрації за викладачем або датою (GET /consultations). Для
адміністраторів або викладачів можуть бути передбачені ендпоінти для створення,
редагування та видалення записів розкладу (POST /consultations, PUT
/consultations/{id}, DELETE /consultations/{id}). Підсистема здійснює запити до
основного сховища даних та, за необхідності, може інтегруватися з внутрішніми
університетськими системами для синхронізації базових даних про розклад.
Підсистема пуш-повідомлень:
Основне завдання цієї підсистеми – забезпечення механізму доставки
оперативних повідомлень студентам та групам. Вона містить ендпоінти, що
дозволяють адміністраторам ініціювати надсилання пуш-повідомлень (POST
/notifications/send), вказуючи текст повідомлення та цільових адресатів
(конкретний студент, група або всі студенти). На стороні клієнта реалізовано
механізм отримання цих повідомлень. Підсистема взаємодіє із зовнішнім сервісом
Firebase Cloud Messaging (FCM) для фактичної доставки повідомлень та зберігає
історію повідомлень у базі даних.
Підсистема оцінювання викладачів:
Ця підсистема відповідає за функціонал рейтингування та оцінювання
викладачів. Вона включає ендпоінти для подання студентами оцінок та коментарів
(POST /evaluations), що забезпечує збір відгуків. Також наявні ендпоінти для
отримання агрегованих рейтингів викладачів (GET /teachers/{id}/rating) та
перегляду індивідуальних коментарів (з урахуванням правил анонімності та
доступу). Підсистема обробляє отримані дані, забезпечує їх валідацію, зберігає
записи в базі даних та здійснює розрахунок загального рейтингу викладачів.
Взаємодія з базою даних:
Усі перелічені підсистеми безпосередньо взаємодіють з центральною базою
даних, яка слугує єдиним джерелом правди для зберігання всіх постійних даних
системи: інформації про студентів, викладачів, групи, детальних записів розкладу
консультацій, даних оцінювання викладачів та логів пуш-повідомлень.
Таким чином, розроблена структурно-функціональна модель дозволяє чітко
розмежувати відповідальність між компонентами системи, забезпечує їхню
модульність та спрощує подальший розвиток та супроводження.
Рисунок 3.1 – Структура схема додатку підсистеми отримання навчальної
інформації
Функціональна схема (рисунок 3.2) відображає основні процеси та взаємодії
в рамках підсистеми мобільного застосунку "Студент ЧДТУ", що охоплює розклад
консультацій, пуш-повідомлення та оцінювання викладачів. Вона ілюструє потік
даних та логіку взаємодії між ключовими компонентами системи.
Опис схеми
1 Ініціація Користувачем: Процес починається з того, що користувач
(студент, викладач або адміністратор) ініціює певну дію в мобільному
застосунку.
2 Центральна Обробка Запитів: Після успішної аутентифікації запит
спрямовується до відповідного функціонального блоку на серверній
стороні.
3 Підсистема розкладу консультацій: Обробляє запити, пов'язані з
розкладом консультацій. Для отримання актуальних даних звертається до
Внутрішніх Університетських Систем (через шар адаптерів) та/або до
Бази Даних (для кешованих даних).
4 Підсистема пуш-повідомлень: Керує надсиланням та отриманням
повідомлень. Адміністратор створює повідомлення, яке потім
відправляється через Сервіси Пуш-Повідомлень (наприклад, FCM) до
мобільних пристроїв. Історія повідомлень може зберігатись у Базі Даних.
5 Підсистема оцінювання викладачів: Забезпечує функціонал збору та
відображення оцінок. Студенти надсилають оцінки, які зберігаються у
Базі Даних. Викладачі можуть переглядати свої результати, які також
зчитуються з Бази Даних.
6 Відображення Результатів: Оброблена інформація або отримані
повідомлення відображаються користувачу в мобільному застосунку.
Рисунок 3.2 – Функціональна схема додатку підсистеми отримання навчальної
інформації
3.1.3 Опис логічної схеми системи
Логічна схема системи представляє її високорівневу архітектуру,
ілюструючи ключові програмні компоненти та їхні взаємозв'язки з функціональної
точки зору. Вона відображає, як різні частини системи співпрацюють для
досягнення поставлених цілей, не вдаючись у деталі фізичного розгортання. Для
підсистеми мобільного застосунку "Студент ЧДТУ" було визначено наступні
логічні компоненти:
1 Мобільний клієнт: Цей компонент є фронтендом системи, розробленим
на Flutter. Він відповідає за взаємодію з користувачем, відображення
даних (наприклад, розкладу консультацій, списку повідомлень,
інтерфейсу оцінювання викладачів) та збір введення від користувача.
Мобільний клієнт ініціює запити до бекенду для отримання даних та
надсилання інформації (наприклад, оцінок викладачів) та приймає пуш-
повідомлення.
2 Серверна частина (Бекенд застосунок): Реалізований на Java з
використанням Spring Boot, цей компонент є центральним ядром системи.
Він інкапсулює всю бізнес-логіку, обробляє запити від мобільного клієнта
через REST API, валідує дані, керує авторизацією та автентифікацією
користувачів. Бекенд координує взаємодію з базою даних, а також з
зовнішніми та внутрішніми сервісами.
3 База даних: Представлена PostgreSQL, база даних є сховищем для всіх
даних системи. Вона зберігає інформацію про студентів, викладачів,
групи, детальний розклад консультацій, записи оцінювання, а також
історію пуш-повідомлень. Бекенд застосунок є єдиною точкою доступу
до бази даних для забезпечення цілісності та безпеки даних.
4 Внутрішні системи університету: Ці зовнішні по відношенню до нової
підсистеми компоненти є джерелами базової інформації, необхідної для
функціонування застосунку. Наприклад, вони можуть надавати актуальні
дані про викладачів, академічні групи, або первинний розклад, який
використовується для формування розкладу консультацій. Бекенд
застосунок відповідає за інтеграцію з цими системами, трансформацію та
нормалізацію отриманих даних.
5 Сервіс пуш-повідомлень (Firebase Cloud Messaging - FCM): Цей зовнішній
компонент відповідає за надійну та масштабовану доставку пуш-
повідомлень на мобільні пристрої. Бекенд застосунок взаємодіє з FCM,
ініціюючи відправку повідомлень, а мобільний клієнт налаштований на їх
отримання.
6 Логічна схема системи відображає потік даних та взаємодію між цими
компонентами: мобільний клієнт обмінюється даними з бекендом через
REST API; бекенд взаємодіє з базою даних для читання/запису
інформації; бекенд також зв'язується з внутрішніми системами
університету для отримання необхідних даних та з сервісом пуш-
повідомлень для їх доставки на клієнтські пристрої. Ця модульна
структура забезпечує гнучкість, спрощує розробку та дозволяє незалежно
масштабувати різні частини системи.
Рисунок 3.3 - Логічна схема системи додатку підсистеми отримання навчальної
інформації
3.1.4 Розробка бази даних
Розробка ефективної та надійної бази даних є фундаментальним кроком у
створенні будь-якої програмної системи, оскільки вона забезпечує постійне
зберігання, управління та цілісність усіх даних. Для підсистеми мобільного
застосунку "Студент ЧДТУ" було спроектовано реляційну схему бази даних, що
відповідає принципам нормалізації, мінімізуючи надмірність та підтримуючи
високу консистентність даних (рисунок 3.3).
Рисунок 3.4 - Схема бази даних в додатку підсистеми отримання навчальної
інформації
В якості центральної системи управління базами даних (СУБД) було обрано
PostgreSQL. Таке рішення зумовлене її доведеною надійністю, розширеними
функціональними можливостями, високою продуктивністю в умовах значних
навантажень та потужною підтримкою спільноти. PostgreSQL забезпечує
підтримку транзакцій, що є критично важливим для збереження цілісності даних
при обробці операцій з розкладом, оцінками та повідомленнями.
Логічна модель даних, що лежить в основі розробленої бази, включає
наступні основні сутності (таблиці), які є відображенням предметної області
системи:
Students (Студенти): Ця таблиця містить вичерпну інформацію про
користувачів мобільного застосунку – студентів. Тут зберігаються їхні
ідентифікаційні дані, контактна інформація та ключовий зв'язок з академічною
групою, до якої вони належать.
Teachers (Викладачі): Призначення цієї таблиці – зберігання даних про
викладачів університету, які надають консультації та є об'єктами оцінювання з боку
студентів. Вона містить їхні ідентифікаційні та контактні дані, а також належність
до кафедр.
Groups (Групи): Ця сутність відповідає за зберігання інформації про всі
академічні групи студентів в університеті, включаючи назву групи, рік та тип
навчання.
Consultation_Slots (Розклад Консультацій): У цій таблиці деталізуються всі
заплановані слоти для консультацій викладачів. Вона містить інформацію про час,
місце проведення консультації, її предмет або тему, а також безпосередній зв'язок
з викладачем, що проводить цю консультацію.
Notifications (Повідомлення): Призначена для зберігання змісту та
метаінформації про всі системні повідомлення або пуш-сповіщення, які
генеруються системою. Це дозволяє зберігати історію комунікації та керувати її
розсилкою.
Teacher_Evaluations (Оцінювання Викладачів): Ця таблиця слугує для
фіксації оцінок та текстових відгуків, які студенти надають викладачам. Вона
пов'язує конкретну оцінку зі студентом-відправником та викладачем-отримувачем,
фіксуючи також час подання відгуку.
Notification_Recipients (Отримувачі Повідомлень): Ця допоміжна таблиця
реалізує зв'язок "багато-до-багатьох" між повідомленнями та студентами,
дозволяючи одному повідомленню бути надісланим багатьом студентам, і одному
студенту – отримати безліч повідомлень.
Взаємозв'язки між сутностями забезпечуються за допомогою зовнішніх
ключів (Foreign Keys), що дозволяє ефективно моделювати складні відносини між
об'єктами реального світу. Наприклад, один студент завжди належить до однієї
групи, тоді як один викладач може мати багато записів у розкладі консультацій та
отримати безліч оцінок. Повідомлення можуть бути адресовані конкретним
студентам через допоміжну таблицю отримувачів.
Проектування такої реляційної схеми гарантує цілісність даних, оскільки
взаємозв'язки між таблицями запобігають введенню некоректних або неповних
даних. Також, вона забезпечує масштабованість системи, дозволяючи легко
додавати нові дані та користувачів без значних змін в архітектурі. Структура
таблиць та індексування сприяють високій продуктивності запитів, що є важливим
для швидкого відображення розкладів та миттєвої доставки повідомлень. Гнучкість
схеми дозволяє її подальше розширення з додаванням нових функціональних
можливостей.
3.1.5 Розробка інтерфейсу користувача
Розробка інтерфейсу викладача була зосереджена на створенні інтуїтивно
зрозумілого, функціонального та ефективного середовища для управління
основними аспектами взаємодії зі студентами через мобільний застосунок.
Інтерфейс викладача реалізований як частина мобільного застосунку, розробленого
на Flutter, що забезпечує його нативну продуктивність та мультиплатформність.
Ключові функціональні можливості, доступні викладачеві через інтерфейс,
включають:
Перегляд розкладу консультацій:
Для викладача передбачено зручний екран, який відображає його особистий
розклад консультацій. Це може бути календарний вигляд або структурований
список, де кожен слот включає день, час, місце проведення та заявлену тему
консультації. Інтерфейс дозволяє легко орієнтуватися у своєму розкладі,
фільтрувати його за датою або статусом. Надані дані є статичними або
отримуються із зовнішніх джерел без можливості прямого керування ними з боку
викладача через застосунок.
Перегляд оцінок та відгуків (за потреби):
Хоча основний акцент системи оцінювання зроблено на збір відгуків від
студентів, інтерфейс викладача може включати спрощений доступ до агрегованих
статистичних даних щодо отриманих оцінок. Це дозволяє викладачеві отримувати
загальне уявлення про студентське сприйняття його викладання та консультацій.
Отримання системних сповіщень:
Викладач отримує пуш-повідомлення про важливі події, що стосуються його
розкладу (наприклад, зміни в графіку, нагадування) або нові відгуки (якщо це
передбачено системою). Ці повідомлення відображаються у стандартний для
мобільних пристроїв спосіб, а також можуть бути доступні для перегляду в
окремому розділі застосунку.
Дизайн та користувацький досвід:
Інтерфейс викладача розроблявся з урахуванням принципів Material Design,
що забезпечило його сучасний вигляд, інтуїтивну навігацію та послідовність у всіх
елементах. Використання стандартних компонентів Flutter дозволило досягти
високої швидкодії та плавності анімацій. Ергономіка інтерфейсу спрямована на
мінімізацію кількості кроків для виконання типових завдань, забезпечуючи
максимальну зручність для викладачів у щоденній роботі з розкладом та взаємодії
зі студентами. Адаптивний дизайн гарантує коректне відображення та
функціональність на мобільних пристроях з різними розмірами екранів.
3.1.6 Опис розробки програмних компонентів
Розробка програмних компонентів є ключовим етапом, на якому абстрактні
вимоги та логічна схема системи перетворюються на конкретні програмні модулі.
В рамках даного проекту, програмні компоненти були розроблені з використанням
обраного стеку технологій (Flutter/Dart для клієнтської частини та Java/Spring Boot
для серверної), забезпечуючи чітке розділення відповідальності та високу
модульність.
Розробка мобільного клієнта (Flutter-застосунок):
Мобільний клієнт є основним інтерфейсом для взаємодії користувачів з
системою та розроблявся як єдиний кросплатформний застосунок. Його
архітектура включає наступні ключові програмні компоненти:
Компоненти інтерфейсу користувача: Ці компоненти відповідають за
візуальне представлення даних та взаємодію з користувачем. Вони включають
екрани для перегляду розкладу консультацій, форми для оцінювання викладачів,
інтерфейс для відображення пуш-повідомлень та навігаційні елементи. Всі UI-
компоненти були побудовані з використанням багатого набору віджетів Flutter та
стилізовані згідно з принципами Material Design, що забезпечує інтуїтивність та
естетичну привабливість.
Компоненти управління станом (State Management Components): Для
ефективного керування складним станом застосунку був інтегрований
архітектурний патерн BLoC (Business Logic Component). Ці компоненти
інкапсулюють бізнес-логіку UI, роблячи її реактивною, легко тестуваною та
відокремленою від візуального шару. Це дозволяє ефективно обробляти зміни
даних, пов'язані з розкладом, оцінками та повідомленнями, зберігаючи при цьому
високу продуктивність.
Компоненти мережевої взаємодії: За взаємодію з бекендом відповідають
компоненти. Вони інкапсулюють [42] логіку відправлення HTTP-запитів до REST
API бекенду та обробки отриманих JSON-відповідей, забезпечуючи надійний та
безпечний обмін даними.
Компоненти для пуш-повідомлень: Інтеграція з плагінами Firebase Messaging
Plugin та Firebase Core Plugin дозволила реалізувати функціонал отримання та
обробки пуш-повідомлень, що надходять від бекенду через FCM.
Розробка серверної частини (Spring Boot застосунок):
Серверна частина є центральним компонентом системи, що обробляє бізнес-
логіку та керує доступом до даних. Вона була розроблена на Java з використанням
фреймворку Spring Boot та організована у кілька ключових шарів:
REST Контролери (Controllers) [43]: Ці компоненти є вхідними точками для
всіх запитів, що надходять від мобільного клієнта. Вони відповідають за
маршрутизацію запитів до відповідних сервісних компонентів, валідацію вхідних
даних та форматування відповідей у форматі JSON. Приклади контролерів
включають ConsultationController, NotificationController, EvaluationController.
Сервісні компоненти (Service Layer): Цей шар містить основну бізнес-логіку
застосунку. Сервісні компоненти отримують дані від контролерів, виконують
необхідні обчислення, валідацію, обробку даних та взаємодіють з шаром доступу
до даних. Саме тут реалізовано логіку отримання розкладу консультацій (у тому
числі з інтеграцією із зовнішніми системами), обробки поданих оцінок викладачів
та підготовки даних для відправки пуш-повідомлень.
Компоненти доступу до даних (Data Access Layer / Repositories): Цей шар
відповідає за взаємодію з базою даних PostgreSQL. З використанням Spring,
репозиторії надають абстрактний інтерфейс для CRUD-операцій [44] (створення,
читання, оновлення, видалення) з сутностями бази даних, такими як Student,
Teacher, ConsultationSlot, Notification, TeacherEvaluation.
Компоненти інтеграції: Це спеціалізовані компоненти, які забезпечують
взаємодію із зовнішніми сервісами. Зокрема, було розроблено компоненти для
інтеграції з Firebase Cloud Messaging (FCM) для ініціювання та відправки пуш-
повідомлень. Також можуть бути присутні компоненти для інтеграції з
внутрішніми університетськими системами для отримання актуальних даних про
розклад, викладачів та студентів.
Компоненти безпеки: Вся система безпеки реалізована за допомогою Spring
Security, яка забезпечує автентифікацію користувачів та авторизацію їх доступу до
ресурсів API. Це включає використання JSON Web Tokens (JWT) для безпечної
передачі інформації про користувача між клієнтом та сервером.
Такий модульний підхід до розробки програмних компонентів забезпечує
високу модульність, розширюваність та легкість супроводження системи,
дозволяючи незалежно розвивати та тестувати окремі функціональні блоки.
3.2 Тестування системи
Тестування є критично важливим етапом у життєвому циклі розробки
програмного забезпечення, що забезпечує якість, надійність та відповідність
готового продукту встановленим вимогам. Для підсистеми мобільного застосунку
"Студент ЧДТУ" був застосований багаторівневий підхід до тестування, який
включає модульне, інтеграційне, системне та приймальне тестування. Кожен з цих
рівнів має свої специфічні цілі та методи, дозволяючи виявляти дефекти на різних
стадіях розробки та з різних перспектив.
3.2.1 Модульне тестування
Модульне тестування [45] (Unit Testing) є першим і найфундаментальнішим
рівнем тестування, спрямованим на перевірку найменших, ізольованих і
самостійних одиниць коду. Його основна мета – підтвердити, що кожен окремий
метод, функція або клас працює коректно згідно зі своєю внутрішньою логікою та
визначеною специфікацією, незалежно від інших компонентів системи. Це
дозволяє виявляти помилки на найнижчому рівні абстракції.
Контекст проекту для серверної частини (Java/Spring Boot):
1 Тестувалися методи у сервісних шарах ConsultationService get
ConsultationsForTeacher(), TeacherEvaluationService calculateAverage
Rating(), NotificationService preparePushNotificationPayload()).
2 Перевірялася їхня внутрішня логіка, коректність обчислень, обробка
граничних випадків та виняткових ситуацій.
3 Проводилось тестування методів у REST-контролерах, щоб
переконатися, що вони правильно приймають вхідні дані, коректно
викликають відповідні сервісні методи та формують відповідні HTTP-
відповіді.
4 Для ізоляції тестування та уникнення залежностей від бази даних або
зовнішніх сервісів активно використовувались заглушки (mock-об'єкти).
Для мобільного клієнта (Flutter/Dart):
1 Тестувалися компоненти управління станом (BLoC-и), щоб перевірити
коректність їхніх станів та подій, а також правильність переходу між
станами у відповідь на різні події. Наприклад, як ConsultationBloc реагує
на LoadConsultationsEvent і чи емітує він правильний Consultations
LoadedState.
2 Перевірялася логіка у репозиторіях та моделях даних, включаючи методи
для парсингу JSON-відповідей від бекенду та формування запитів.
3 Проводилось тестування окремих віджетів (Widget Testing) для
підтвердження їхнього коректного візуального рендерингу та взаємодії з
користувачем.
4 Інструменти: Використовувався вбудований у Flutter фреймворк
flutter_test (для тестування віджетів та деякої Dart-логіки) та стандартний
пакет test для Dart. Для створення мок-об'єктів у Dart-коді ефективно
застосовувалася бібліотека Mocktail.
Таблиця 3.1
Результати модульного тестування компонентів
Сценарій Що перевіряли Результат
Внутрішня логіка вибірки
ConsultationService. Працює
консультацій, обробка порожніх та
getConsultationsForTeacher() коректно
граничних випадків
Розрахунок середнього балу,
TeacherEvaluationService. Працює
обробка поділу на нуль,
calculateAverageRating() коректно
округлення
Формування коректного JSON-
NotificationService. Працює
пейлоада для FCM, включно з
preparePushNotificationPayload() коректно
полями title/body/data
Продовження таблиці 3.1
Прийом валідних/невалідних
вхідних запитів, виклик певних Працює
REST-контролери
сервісів, правильні HTTP-статуси коректно
та контент у тілах відповідей
Реакція на LoadConsultationsEvent,
Працює
ConsultationBloc (Flutter) перехід у ConsultationsLoadedState
коректно
і обробка помилок
Серіалізація/десеріалізація JSON-
Репозиторії та JSON-моделі Працює
відповідей від бекенду, коректне
(Flutter) коректно
наповнення ConsultationSchedule
Рендеринг діалогів та списків
Працює
Widget Testing (Flutter) курсів, взаємодія з UI-елементами
коректно
(тапи, скрол тощо)
3.2.2 Інтеграційне тестування
Інтеграційне тестування [46] (Integration Testing) має на меті перевірку
коректності взаємодії та співпраці між різними програмними модулями або
підсистемами. Його ключове завдання – виявити дефекти, які виникають на стиках
компонентів, пов'язані з несумісністю інтерфейсів, неправильною передачею даних
або конфліктами при використанні спільних ресурсів.
Контекст проекту для серверної частини:
1 Тестувалися повноцінні потоки запитів, що проходять через декілька
шарів бекенду, наприклад, від REST-контролера до сервісного шару, а
потім до репозиторію та бази даних. Перевірялася коректність
збереження, оновлення та вибірки даних (наприклад, чи коректно
зберігається нова оцінка викладача і чи потім її можна отримати).
2 Особлива увага приділялася інтеграції з базою даних PostgreSQL. Для
цього використовувались тестові профілі Spring Boot та бібліотека
Testcontainers, яка дозволяє динамічно піднімати реальні екземпляри
PostgreSQL у Docker-контейнерах для кожного тесту. Це забезпечує
тестування з реальною базою даних, а не з in-memory заглушками.
3 Проводилась перевірка взаємодії з зовнішніми сервісами, такими як
Firebase Cloud Messaging (FCM). Хоча сама відправка пуш-повідомлень
могла бути мок-об'єктом, тестувався шлях формування запиту до FCM та
обробка його відповіді. Для імітації зовнішніх HTTP-сервісів міг
застосовуватись WireMock.
4 Інструменти: Spring Boot Test (@SpringBootTest) для завантаження
повного контексту застосунку, MockMvc для тестування REST-
ендпоінтів без необхідності запуску реального HTTP-сервера, а також
Testcontainers для контейнеризованих залежностей.
Для мобільного клієнта:
1 Тестувалась взаємодія між компонентами BLoC та репозиторіями, а
також коректність виконання мережевих запитів за допомогою бібліотеки
Dio. Перевірялося, чи правильно дані, отримані від бекенду, парсяться та
відображаються в UI.
2 Здійснювалася перевірка коректності серіалізації/десеріалізації об'єктів
моделі в/з JSON-формату для обміну даними з API.
3 Для повноцінного клієнт-серверного інтеграційного тестування,
мобільний застосунок тестувався з розгорнутим на тестовому середовищі
бекендом.
Таблиця 3.2
Результати інтеграційного тестування системи
Сценарій Що перевіряли Результат
Інтеграція з PostgreSQL Підняття реального контейнера Працює
через Testcontainers PostgreSQL, виконання CRUD-операцій у коректно
тестовому профілі Spring Boot, перевірка
транзакцій, ролбеків і схеми бази
Продовження таблиці 3.2
Повноцінний потік запиту через Чи коректно зберігається нова Працює
Сервіс → БД оцінка викладача в PostgreSQL коректно
Формування запиту до FCM і Імітація сервісу FCM за Працює
обробка відповіді допомогою WireMock, перевірка коректно
HTTP-пейлоаду, обробка статусів
відповіді та виняткових ситуацій
(наприклад, 429, 500)
Тест REST-ендпоінтів з Надсилання Працює
MockMvc без підняття GET/POST/PUT/DELETE запитів коректно
реального сервера до контролерів, верифікація
статусу відповіді, заголовків та
тіла, інтеграція з валідацією і
безпекою
BLoC + репозиторій Виклик LoadConsultationsEvent у Працює
(Flutter/Dart) ConsultationBloc, реальний HTTP- коректно
GET через Dio до тестового
бекенду, перевірка переходів
станів (ConsultationLoading →
ConsultationLoaded)
End-to-end клієнт-серверне Розгортання тестового бекенду на Працює
тестування (Flutter ↔ Spring іншому порті, підключення коректно
Boot) мобільного емулятора до цього
бекенду, перевірка повного
сценарію: логін → завантаження
розкладу → відкриття модалки
консультацій → відображення
даних із мок-сервісу
3.2.3 Системне тестування
Системне тестування [47] (System Testing) є етапом, на якому вся інтегрована
система перевіряється як єдине ціле. Його головна мета – оцінити відповідність
системи всім функціональним та нефункціональним вимогам, визначеним у
специфікації, з точки зору кінцевого користувача, без знання внутрішньої
структури коду (так зване "тестування чорної скриньки").
Функціональні вимоги (скрізні сценарії):
1 Перевірялися повні "наскрізні" сценарії роботи, наприклад: "Користувач
(студент) успішно входить у застосунок, переглядає свій
персоналізований розклад консультацій, подає оцінку викладачу, отримує
пуш-повідомлення про зміну в розкладі та виходить з облікового запису".
2 Тестувалася коректність всіх бізнес-процесів: відправлення повідомлень
адміністратором до групи студентів, агрегація та відображення
середнього рейтингу викладача.
Нефункціональні вимоги:
1 Тестування безпеки: Проводились перевірки на вразливості, такі як
спроби несанкціонованого доступу, коректність роботи механізмів
автентифікації та авторизації (включаючи життєвий цикл JWT-токенів),
захист від поширених атак (наприклад, SQL-ін'єкції, якщо застосунок мав
прямі форми введення, XSS для веб-компонентів.
2 Тестування продуктивності: Оцінювався час відгуку API-запитів при
піковому навантаженні (наприклад, одночасне завантаження розкладу
великою кількістю студентів), швидкість обробки запитів на збереження
оцінок. Використовувались такі інструменти як JMeter або Gatling для
імітації великої кількості користувачів.
3 Тестування навантаження: Перевірялася стабільність системи під
екстремальним навантаженням, щоб визначити її межі та виявити
потенційні "вузькі місця".
4 Тестування сумісності: Застосунок тестувався на різних мобільних
пристроях (смартфонах, планшетах) з різними версіями операційних
систем (різні версії Android та iOS), а також в умовах різної якості
мережевого з'єднання (Wi-Fi, 4G, 3G).
5 Тестування надійності/відновлення: Перевірялася поведінка системи при
тимчасових збоях.
Таблиця 3.3
Результати інтеграційного тестування системи
Сценарій Що перевіряли Результат
Повний наскрізний
Логін, завантаження розкладу,
сценарій “Логін →
відправка оцінки, отримання Працює коректно
Розклад → Оцінка →
пуш, вихід
Пуш → Логаут”
Надсилання
Створення та доставка пуш, збір
повідомлень
оцінок, обчислення середнього Працює коректно
адміністратором та
рейтингу
агрегація рейтингу
Тестування безпеки:
Доступ до ендпоінтів без токена
доступ без JWT та Працює коректно
(401/403), спроба SQL-ін’єкції
SQL-ін’єкції
Вимір latency (p95) та error rate
Навантаження API (500
при великій кількості Працює коректно
паралельних запитів)
одночасних запитів
Сумісність на різних
UI на Android/iOS різних версій,
пристроях і в умовах Працює коректно
робота при 3G/Edge
повільного зв’язку
Імітація втрати зв’язку з БД,
Надійність/відновлення перевірка обробки помилки і
Працює коректно
після збоїв відновлення роботи після
відключення контейнера
3.2.4 Приймальне тестування
Приймальне тестування [48] (Acceptance Testing) є заключним етапом
верифікації системи. Його основна мета – перевірити, чи відповідає розроблена
система бізнес-вимогам та очікуванням замовника (у даному випадку –
університету та його користувачів) та чи готова вона до розгортання у реальне
середовище. Це тестування виконується з точки зору кінцевого користувача.
Контекст проекту:
1 Учасники: Для проведення приймального тестування я активно залучав
представників цільової аудиторії: студентів та викладачів університету.
Їхній безпосередній зворотний зв'язок був ключовим для оцінки зручності
та корисності застосунку.
2 Сценарії: Я проводив тестування за реальними бізнес-сценаріями та
кейсами використання.
Приклади сценаріїв, які я перевіряв:
"як студент, я хочу безперешкодно увійти в застосунок, знайти свій
поточний розклад, а також розклад конкретного викладача.";
"як студент, я хочу залишити анонімний відгук та оцінку викладачу, щоб
допомогти іншим студентам.";
"як студент, я хочу отримувати персоналізовані пуш-повідомлення про
зміни в навчальному процесі.";
Таблиця 3.4
Результати приймального тестування системи
Сценарій користувача Що перевіряли Результат
Студент входить, переглядає Успішна автентифікація, Пройшло успішно
свій розклад та розклад завантаження обох
викладача розкладів, коректний
відображення дат і
вчителів
Продовження таблиці 3.4
Студент залишає анонімний Форма відгуку, серверний Пройшло успішно
відгук та оцінку викладачу запис оцінки, оновлення
середнього рейтингу
Студент отримує Доставка повідомлення Пройшло успішно
персоналізоване пуш- через FCM, правильний
повідомлення про зміну в роутинг до екрана
навчальному процесі повідомлень
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ
У цьому розділі було детально описано весь процес створення та
забезпечення якості підсистеми мобільного застосунку "Студент ЧДТУ". Розділ
послідовно висвітлює ключові етапи – від обґрунтування архітектурних рішень до
детального опису тестування системи.
На початку розділу було обґрунтовано та розкрито принципи вибору
сучасного та ефективного стеку технологій, який ліг в основу проекту. Flutter та
Dart були обрані для розробки кросплатформного мобільного клієнта,
забезпечуючи високу продуктивність та уніфікований користувацький досвід. Java
та Spring Boot були використані для створення надійного, масштабованого та
безпечного бекенду, що ефективно обробляє бізнес-логіку. PostgreSQL як
реляційна СУБД гарантує цілісність, персистентність та ефективне управління
даними. Інтеграція Firebase Cloud Messaging (FCM) забезпечила надійну та
оперативну доставку пуш-повідомлень. Обґрунтований вибір цих засобів реалізації
став міцним фундаментом для побудови високоефективної та зручної у
супроводженні системи.
Далі було представлено структурно-функціональне моделювання та опис
логічної схеми системи, що дозволило чітко визначити ключові підсистеми
(розклад консультацій, пуш-повідомлення, оцінювання викладачів), їхні
компоненти та взаємодію. Цей підхід забезпечив модульність, логічне
розмежування відповідальності та гнучкість архітектури. Детальна розробка бази
даних з використанням PostgreSQL включала проектування реляційної схеми, що
гарантує надійне зберігання та управління всією інформацією, оптимізоване для
високої продуктивності та цілісності даних.
Особливу увагу в розділі приділено розробці інтерфейсу користувача, який
був спроектований мною з акцентом на інтуїтивність, естетику та
функціональність, забезпечуючи оптимальний користувацький досвід як для
студентів, так і для викладачів. Детальний опис розробки програмних компонентів
підкреслив застосування архітектурних патернів та кращих практик програмування
для створення модульного та легкорозширюваного коду як на стороні мобільного
клієнта, так і на бекенді.
Завершальна частина розділу присвячена тестуванню системи, що є
ключовим для забезпечення її якості та надійності. Мною був застосований
комплексний, багаторівневий підхід, що включав модульне, інтеграційне, системне
та приймальне тестування. Кожен з цих етапів дозволив виявити та усунути
потенційні недоліки, перевірити коректність взаємодії компонентів, оцінити
відповідність системи функціональним та нефункціональним вимогам, а також
підтвердити її готовність до експлуатації з точки зору кінцевих користувачів.
Таким чином, у Розділі 3 було вичерпно розкрито весь шлях створення
програмного забезпечення – від архітектурного задуму та вибору технологій до
детальної реалізації компонентів та ретельного тестування. Результатом цієї роботи
є функціональна, надійна та зручна у використанні підсистема мобільного
застосунку "Студент ЧДТУ", повністю готова до впровадження та подальшого
розвитку.
ВИСНОВОК
У результаті виконання роботи було успішно розроблено та якісно
протестовано підсистему мобільного застосунку "Студент ЧДТУ", яка значно
розширює його функціонал за рахунок інтеграції перегляду розкладу консультацій
викладачів, системи пуш-повідомлень та рейтингування викладачів.
На початковому етапі було проведено глибокий аналіз актуальних проблем,
що виникають при реалізації подібних систем, включаючи складнощі інтеграції з
існуючими університетськими системами, забезпечення актуальності даних,
вимоги до безпеки та конфіденційності, а також питання продуктивності та
масштабованості. Для подолання цих викликів було окреслено ключові
методологічні підходи, такі як розробка адаптерів даних, централізована валідація,
механізми кешування та автоматизоване тестування, що заклало міцну основу для
всієї подальшої роботи.
Далі було деталізовано процес проектування програмного забезпечення,
починаючи з моделювання предметної області та ідентифікації ключових
сутностей, таких як Студент, Викладач, Розклад Консультацій, Повідомлення та
Оцінювання. Були формалізовані та візуалізовані функціональні та
нефункціональні вимоги за допомогою діаграм варіантів використання, а також
розроблена детальна логічна структура системи через діаграми класів, що стало
дорожньою картоною для реалізації.
У рамках практичної реалізації проекту та забезпечення його якості, було
обґрунтовано вибір технологічного стеку: Flutter/Dart для кросплатформного
мобільного клієнта, Java/Spring Boot для надійного бекенду та PostgreSQL для
ефективного управління даними, а також інтеграцію Firebase Cloud Messaging для
пуш-повідомлень. Представлено структурно-функціональне моделювання,
розробку бази даних та інтерфейсу користувача, зосереджуючись на інтуїтивності
та функціональності. Завершальний етап – тестування системи – був реалізований
як комплексний, багаторівневий процес, що охоплював модульне, інтеграційне,
системне та приймальне тестування, забезпечивши високу якість, надійність та
готовність застосунку до експлуатації.
Таким чином, уся робота демонструє цілісний підхід до розробки
програмного забезпечення: від ретельного аналізу проблем та формування вимог
до архітектурного проектування, детальної реалізації та всебічного тестування.
Результатом є функціональна, надійна та зручна у використанні підсистема
мобільного застосунку "Студент ЧДТУ", яка повною мірою відповідає
поставленим завданням та готова до успішного впровадження.
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Flutter/Dart [Електронний ресурс] – Режим доступу: https://flutter.dev/
2 REST-архітектура [Електронний ресурс] – Режим доступу:
https://developer.mozilla.org/en-US/docs/Glossary/REST
3 Мікросервісна архітектура [Електронний ресурс] – Режим доступу:
https://microservices.io/
4 Реляційна база даних [Електронний ресурс] – Режим доступу:
https://cloud.google.com/learn/what-is-a-relational-database
5 JWT [Електронний ресурс] – Режим доступу: https://jwt.io/
6 API [Електронний ресурс] – Режим доступу: https://aws.amazon.com/what-
is/api/
7 UML [Електронний ресурс]. Режим доступу:
https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/
8 Widget-тести [Електронний ресурс]. Режим доступу:
https://docs.flutter.dev/cookbook/testing/widget/introduction
9 QA [Електронний ресурс]. Режим доступу:
https://www.upwork.com/resources/what-is-qa-testing
10 Мобільного UI [Електронний ресурс]. Режим доступу:
https://www.uxdesigninstitute.com/blog/ultimate-guide-to-mobile-app-
design/
11 Версії ОС [Електронний ресурс]. Режим доступу:
https://www.folio3.com/mobile/blog/mobile-device-fragmentation-what-is-it/
12 Бекенд [Електронний ресурс]. Режим доступу:
https://www.geeksforgeeks.org/backend-development/
13 Адаптер [Електронний ресурс]. Режим доступу:
https://www.geeksforgeeks.org/adapter-pattern/
14 Юніт-тестування [Електронний ресурс]. Режим доступу:
https://aws.amazon.com/what-is/unit-testing/
brightsec.com+5aws.amazon.com+5en.wikipedia.org+5
15 Інтеграційне тестування [Електронний ресурс]. Режим доступу:
https://en.wikipedia.org/wiki/Integration_testing
en.wikipedia.org+3en.wikipedia.org+3en.wikipedia.org+3
16 Приймальне тестування [Електронний ресурс]. Режим доступу:
https://en.wikipedia.org/wiki/Acceptance_testing en.wikipedia.org
17 Модель предметної області [Електронний ресурс]. Режим доступу:
https://www.thoughtworks.com/insights/blog/agile-project-
management/domain-modeling-what-you-need-to-know-before-coding
18 Класи [Електронний ресурс]. Режим доступу:
https://www.geeksforgeeks.org/classes-objects-java/
19 Об’єкти [Електронний ресурс]. Режим доступу:
https://www.geeksforgeeks.org/difference-between-class-and-object/
20 Об’єктно-орієнтований підхід [Електронний ресурс]. Режим доступу:
https://www.tutorialspoint.com/system_analysis_and_design/system_analysis
_and_design_object_oriented_approach.htm
21 Діаграма класів [Електронний ресурс]. Режим доступу:
https://www.geeksforgeeks.org/unified-modeling-language-uml-class-
diagrams/
22 База даних [Електронний ресурс]. Режим доступу:
https://www.geeksforgeeks.org/basic-database-concepts/
23 Сервіс [Електронний ресурс]. Режим доступу: https://microservices.io/
24 Предметна область [Електронний ресурс]. Режим доступу:
https://www.geeksforgeeks.org/software-engineering-domain-modeling/
25 Діаграма випадків використання [Електронний ресурс]. Режим доступу:
https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/what-is-use-case-diagram/
26 Діаграма послідовностей [Електронний ресурс]. Режим доступу:
https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/what-is-sequence-diagram/
27 Діаграма компонентів [Електронний ресурс]. Режим доступу:
https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/what-is-component-diagram/
28 Діаграма прецедентів [Електронний ресурс]. Режим доступу:
https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/what-is-use-case-diagram/
29 Діаграмв активностей [Електронний ресурс]. Режим доступу:
https://www.visual-paradigm.com/guide/uml-unified-modeling-
language/what-is-activity-diagram/
30 Dart [Електронний ресурс]. Режим доступу: https://dart.dev/overview
reddit.com+8dart.dev+8docs.flutter.dev+8
31 Кросплатформний [Електронний ресурс]. Режим доступу:
https://www.monterail.com/blog/cross-platform-app-development
browserstack.com+5monterail.com+5builder.ai+5
32 BLoC [Електронний ресурс]. Режим доступу:
https://www.geeksforgeeks.org/bloc-pattern-flutter/
geeksforgeeks.org+11geeksforgeeks.org+11dhiwise.com+11
33 Material Design [Електронний ресурс]. Режим доступу:
https://m2.material.io/design/introduction interaction-
design.org+7m2.material.io+7m2.material.io+7
34 Java [Електронний ресурс]. Режим доступу:
https://www.geeksforgeeks.org/introduction-to-java/
geeksforgeeks.org+12geeksforgeeks.org+12ibm.com+12
35 Spring Boot [Електронний ресурс]. Режим доступу:
https://www.geeksforgeeks.org/introduction-to-spring-boot/
36 PostgreSQL [Електронний ресурс]. Режим доступу:
https://www.postgresql.org/about/
37 СУБД [Електронний ресурс]. Режим доступу:
https://www.splunk.com/en_us/blog/learn/dbms-database-management-
systems.html
38 Firebase [Електронний ресурс]. Режим доступу:
https://www.geeksforgeeks.org/firebase-introduction/
39 Firebase Cloud Messaging (FCM) [Електронний ресурс]. Режим доступу:
https://firebase.google.com/docs/cloud-messaging
40 Google [Електронний ресурс]. Режим доступу:
https://en.wikipedia.org/wiki/Firebase
41 Firebase Console [Електронний ресурс]. Режим доступу:
https://console.firebase.google.com/
42 Інкапсуляція [Електронний ресурс]. Режим доступу:
https://uk.wikipedia.org/wiki/Інкапсуляція_(програмування)
43 Controllers [Електронний ресурс]. Режим доступу:
https://www.geeksforgeeks.org/mvc-design-pattern/
44 CRUD-операцій [Електронний ресурс]. Режим доступу:
https://en.wikipedia.org/wiki/Create,_read,_update_and_delete
45 Модульне тестування [Електронний ресурс]. Режим доступу:
https://uk.wikipedia.org/wiki/Модульне_тестування
46 Інтеграційне тестування [Електронний ресурс]. Режим доступу:
https://uk.wikipedia.org/wiki/Інтеграційне_тестування
47 Системне тестування [Електронний ресурс]. Режим доступу:
https://uk.wikipedia.org/wiki/Системне_тестування
48 Приймальне тестування [Електронний ресурс]. Режим доступу:
https://uk.wikipedia.org/wiki/Приймальне_тестування
49 Методичні рекомендації з моделювання та проектування об’єктно-
орієнтованих систем [Електронний ресурс]. Режим доступу:
https://cz.chdtu.edu.ua/metodychni-rekomendacziyi-2/
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедри ПЗАС
проф. Голуб С.В.
МОБІЛЬНИЙ ЗАСТОСУНОК СТУДЕНТА УНІВЕРСИТЕТУ: ПІДСИСТЕМА
ОТРИМАННЯ НАВЧАЛЬНОЇ ІНФОРМАЦІЇ
Специфікація
ЧДТУ 252151.4 ПЗ
Листів 2
Розробник Григоренко А.О.
Керівник Заспа Г.О.
Н.Контроль Півень О.Б.
Черкаси 2025
Позначення Найменування Примітка
Документація
482 ЧДТУ 252151 12 01 Лістинг програми
482 ЧДТУ 252151 34 01 Інструкція користувача
482 ЧДТУ 252151 90 01 Графічні матеріали
ДОДАТОК Б
МОБІЛЬНИЙ ЗАСТОСУНОК СТУДЕНТА УНІВЕРСИТЕТУ: ПІДСИСТЕМА
ОТРИМАННЯ НАВЧАЛЬНОЇ ІНФОРМАЦІЇ
Лістинг програми
482 ЧДТУ 252151 12.01
Листів 12
Розробник: Григоренко А. О.
Черкаси 2025
TeacherController.java
@GetMapping("/teachers/{id}/consultations")
public ResponseEntity<ConsultationScheduleDTO> getConsultationsByTeacherId(
@PathVariable @Min(1) int id
) throws OperationCannotBePerformedException {
ConsultationScheduleDTO dto = teacherService.getConsultationSchedule(id);
return ResponseEntity.ok(dto);
}
TeacherService.java
public ConsultationScheduleDTO getConsultationSchedule(int teacherId)
throws OperationCannotBePerformedException {
if (teacherId == 345) {
return new ConsultationScheduleDTO(
"Ауд. 507",
Arrays.asList("02.12.2024", "09.12.2024", "13.01.2025",
"20.01.2025", "05.02.2025"),
"10:00 – 11:00"
);
}
if (teacherId == 512) {
return new ConsultationScheduleDTO(
"2 Корпус Ауд. 213",
Arrays.asList("05.11.2024", "12.11.2024", "19.11.2024",
"26.11.2024"),
"14:00 – 15:30"
);
}
throw new OperationCannotBePerformedException(
"Розклад консультацій для викладача з id=" + teacherId + " не знайдено"
);
}
private enum Result {
NONE,
ONE,
MORE_THAN_ONE
}
CourseService.java
private StudentCourseBean createStudentCourseBean(Course c, Teacher t, boolean
isSelective) {
Integer teacherId = (t != null ? t.getId() : null);
String teacherFullName = (t != null ? t.getName() + " " + t.getSurname() : "");
return new StudentCourseBean(c.getId(), c.getCourseName().getName(),
c.getHours(),
c.getCredits(), c.getSemester(), teacherFullName, teacherId,
c.getKnowledgeControl().getName(), isSelective
);
}
CurriculumController.java
@GetMapping("/consultations")
public ResponseEntity<ConsultationSchedule> getConsultations(
@RequestParam int teacherId) {
ConsultationSchedule schedule =
curriculumService.getConsultationSchedule(teacherId);
return ResponseEntity.ok(schedule);
}
CurriculumService.java
public ConsultationSchedule getConsultationSchedule(int teacherId) {
String url = Constants.BASE_URL + "/teachers/" + teacherId + "/consultations";
HttpEntity<?> request = new HttpEntity<>(HttpUtil.getHeaders());
ResponseEntity<ConsultationSchedule> response =
restTemplate.exchange(url, HttpMethod.GET, request,
ConsultationSchedule.class);
return response.getBody();
}
curriculum_content.dart
void _showTeacherDialog(
BuildContext context,
String teacherName,
int teacherId,
) {
showDialog(
context: context,
builder: (_) => BlocProvider(
create: (_) =>
ConsultationBloc()..add(LoadConsultationEvent(teacherId)),
child: AlertDialog(
titlePadding: EdgeInsets.fromLTRB(24, 20, 4, 0),
title: Row(
children: [
Expanded(
child: Text(
teacherName,
style: TextStyle(fontWeight: FontWeight.bold, fontSize: 20),
),
),
IconButton(
padding: EdgeInsets.zero,
constraints: BoxConstraints(),
icon: Icon(Icons.close, size: 22),
onPressed: () => Navigator.of(context).pop(),
),
],
),
content: BlocBuilder<ConsultationBloc, ConsultationState>(
builder: (context, state) {
if (state is ConsultationLoading) {
return SizedBox(
height: 80,
child: Center(child: CircularProgressIndicator()),
);
}
if (state is ConsultationLoaded) {
final s = state.schedule;
return Column(
mainAxisSize: MainAxisSize.min,
crossAxisAlignment: CrossAxisAlignment.start,
children: [
SizedBox(height: 8),
Text('Консультації:',
style: TextStyle(fontWeight: FontWeight.bold, fontSize: 16)),
SizedBox(height: 8),
Row(
crossAxisAlignment: CrossAxisAlignment.start,
children: [
Icon(Icons.calendar_today, size: 20, color: Colors.blue),
SizedBox(width: 8),
Expanded(
child: Column(
crossAxisAlignment: CrossAxisAlignment.start,
children:
s.consultationDates.map((d) => Text(d)).toList(),
),
),
],
),
SizedBox(height: 12),
Row(
children: [
Icon(Icons.access_time, size: 20, color: Colors.blue),
SizedBox(width: 8),
Text(s.consultationTime),
],
),
SizedBox(height: 12),
Row(
children: [
Icon(Icons.location_on, size: 20, color: Colors.blue),
SizedBox(width: 8),
Text(s.auditorium),
],
),
],
);
}
if (state is ConsultationEmpty) {
return SizedBox(
height: 80,
child: Center(
child: Text(
'Розклад консультацій відсутній',
style: TextStyle(
fontStyle: FontStyle.italic, color: Colors.black54),
),
),
);
}
if (state is ConsultationError) {
return Text(
'Помилка: ${state.message}',
style: TextStyle(color: Colors.red),
);
}
return Container();
},
),
actions: null,
),
),
);
}
consultation_bloc.dart
import 'package:bloc/bloc.dart';
import
'package:deanoffice_mobile_cross/models/consultation/consultation_schedule.dart';
import
'package:deanoffice_mobile_cross/repository/consultation/consultation_repository.dart'
;
part 'consultation_event.dart';
part 'consultation_state.dart';
class ConsultationBloc extends Bloc<ConsultationEvent, ConsultationState> {
final ConsultationRepository _repo = ConsultationRepository();
ConsultationBloc() : super(ConsultationInitial()) {
on<LoadConsultationEvent>((event, emit) async {
emit(ConsultationLoading());
try {
final schedule = await _repo.fetchSchedule(event.teacherId);
if (schedule.consultationDates.isEmpty) {
emit(ConsultationEmpty());
} else {
emit(ConsultationLoaded(schedule));
}
} catch (_) {
emit(ConsultationEmpty());
}
});
}
}
consultation_event.dart
part of 'consultation_bloc.dart';
abstract class ConsultationEvent {}
class LoadConsultationEvent extends ConsultationEvent {
final int teacherId;
LoadConsultationEvent(this.teacherId);
}
consultation_provider.dart
import
'package:deanoffice_mobile_cross/models/consultation/consultation_schedule.dart';
import 'package:deanoffice_mobile_cross/providers/dio.dart';
class ConsultationProvider {
final _dio = DioWrapper.getDio();
Future<ConsultationSchedule> getConsultationSchedule(int teacherId) async {
final response =
await _dio.get('/consultations?teacherId=$teacherId');
return ConsultationSchedule.fromJson(response.data);
}
}
consultation_repository.dart
import
'package:deanoffice_mobile_cross/models/consultation/consultation_schedule.dart';
import
'package:deanoffice_mobile_cross/providers/consultation/consultation_provider.dart';
class ConsultationRepository {
final ConsultationProvider _provider = ConsultationProvider();
Future<ConsultationSchedule> fetchSchedule(int teacherId) {
return _provider.getConsultationSchedule(teacherId);
}
}
consultation_schedule.dart
class ConsultationSchedule {
final String auditorium;
final List<String> consultationDates;
final String consultationTime;
ConsultationSchedule({
required this.auditorium,
required this.consultationDates,
required this.consultationTime,
});
factory ConsultationSchedule.fromJson(Map<String, dynamic> json) =>
ConsultationSchedule(
auditorium: json['auditorium'] as String,
consultationDates: List<String>.from(json['consultationDates'] as List),
consultationTime: json['consultationTime'] as String,
);
}
consultation_state.dart
part of 'consultation_bloc.dart';
abstract class ConsultationState {}
class ConsultationInitial extends ConsultationState {}
class ConsultationLoading extends ConsultationState {}
class ConsultationLoaded extends ConsultationState {
final ConsultationSchedule schedule;
ConsultationLoaded(this.schedule);
}
class ConsultationEmpty extends ConsultationState {}
class ConsultationError extends ConsultationState {
final String message;
ConsultationError(this.message);
}
ДОДАТОК В
МОБІЛЬНИЙ ЗАСТОСУНОК СТУДЕНТА УНІВЕРСИТЕТУ: ПІДСИСТЕМА
ОТРИМАННЯ НАВЧАЛЬНОЇ ІНФОРМАЦІЇ
Інструкція користувача
482 ЧДТУ 252151 34 01
Листів 3
Розробник: Григоренко А. О.
Черкаси 2025
Частина 1: Серверний застосунок (Бекенд)
1. Підготовка середовища:
- Встановіть Java Development Kit (JDK) (версія 17+) та Maven.
2. Налаштування бази даних PostgreSQL:
- Встановіть PostgreSQL, запустіть сервіс.
- Створіть базу даних (наприклад, student_chdtu_db) та користувача з
правами доступу.
3. Завантаження та встановлення застосунку:
- Завантажте (клонуйте) та розпакуйте вихідний код бекенду.
- У кореневій папці проекту (де pom.xml) виконайте: mvn clean install
4. Конфігурація застосунку:
- Відкрийте src/main/resources/application.properties (або .yml).
- Вкажіть дані для підключення до PostgreSQL: spring.datasource.url,
username, password.
- Додайте файл Service Account Key з Firebase до src/main/resources та
вкажіть шлях: firebase.credentials.path=classpath:your-key.json.
5. Запуск застосунку:
- У кореневій папці бекенду виконайте: java -jar
target/назва_вашого_jar_файлу.jar
- Сервер зазвичай працює на порту 8080.
6. Взаємодія з застосунком:
- Доступ до API через Swagger UI: http://localhost:8080/swagger-ui.html.
Частина 2: Мобільний клієнт (Flutter)
1. Підготовка середовища:
- Встановіть Flutter SDK.
- Налаштуйте Android Studio або Xcode для емулятора/симулятора.
2. Завантаження та встановлення застосунку:
- Завантажте (клонуйте) та розпакуйте вихідний код клієнта.
- У кореневій папці клієнта (де pubspec.yaml) виконайте: flutter pub get
105
3. Конфігурація застосунку:
- Для Firebase (пуш-повідомлення): помістіть google-services.json
(Android) у android/app/ та GoogleService-Info.plist (iOS) у ios/Runner/.
- Вкажіть URL бекенду у файлі конфігурації (наприклад,
lib/config/api_config.dart): const String BASE_URL =
'http://10.0.2.2:8080/api'; (для Android емулятора)
4. Запуск застосунку:
- Запустіть емулятор/симулятор або підключіть пристрій.
- У кореневій папці клієнта виконайте: flutter run
5. Взаємодія з застосунком:
- Взаємодійте з застосунком на пристрої для тестування функціоналу.
Завершення роботи:
- Для зупинки серверу або клієнта натисніть Ctrl + C у відповідному терміналі.
- Повторіть кроки для внесення змін у код або конфігурацію.
106
ДОДАТОК Г
МОБІЛЬНИЙ ЗАСТОСУНОК СТУДЕНТА УНІВЕРСИТЕТУ: ПІДСИСТЕМА
ОТРИМАННЯ НАВЧАЛЬНОЇ ІНФОРМАЦІЇ
Презентація
482 ЧДТУ 252151 90 01
Листів 12
Розробник: Григоренко А. О.
Черкаси 2025
107
ЧДТУ 25.2151.004 ПЗ
Рисунок Г1 – Слайд вступу
5
ЧДТУ 25.2151.004 ПЗ
Рисунок Г2 – Слайд актуальності теми
Рисунок Г3 – Слайд мети та завдання
6
ЧДТУ 25.2151.004 ПЗ
Рисунок Г4 – Слайд методів розробки
Рисунок Г5 – Слайд результатів та значення
7
ЧДТУ 25.2151.004 ПЗ
Рисунок Г6 – Слайд особистого внеску автора
Рисунок Г7 – Слайд способів вирішення задачі
8
ЧДТУ 25.2151.004 ПЗ
Рисунок Г8 – Слайд виконуваних функцій
Рисунок Г9 – Слайд проектування логічної структури
9
ЧДТУ 25.2151.004 ПЗ
Рисунок Г10 – Слайд діаграми пакетів
Рисунок Г11 – Слайд діаграми компонентів
10
ЧДТУ 25.2151.004 ПЗ
Рисунок Г12 – Слайд діаграми діяльності
Рисунок Г13 – Слайд діаграми послідовності
11
ЧДТУ 25.2151.004 ПЗ
Рисунок Г14 – Слайд діаграми комунікацій
Рисунок Г15 – Слайд вибору засобів реалізації
12
ЧДТУ 25.2151.004 ПЗ
Рисунок Г16 – Слайд функціональної схеми програми
Рисунок Г17 – Слайд структури бази даних
13
ЧДТУ 25.2151.004 ПЗ
Рисунок Г18 – Слайд розробки інтерфейсу користувача
Рисунок Г19 – Слайд тестування системи
14
ЧДТУ 25.2151.004 ПЗ
Рисунок Г20 – Слайд інтеграційного тестування
Рисунок Г21 – Слайд системного та приймального тестування
15