Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9669| Title: | Інформаційна система університету. Клієнтська частина підсистеми роботи з індивідуальними предметами |
| Authors: | Заспа, Григорій Олександрович Різник, Олександр Михайлович |
| Keywords: | інженерія програмного забезпечення;інформаційна система;підсистема роботи з індивідуальними предметами;Angular;TypeScript;software engineering;information system;subsystem for working with individual courses;Angular;TypeScript;dean’s office |
| Issue Date: | 17-Jun-2026 |
| Abstract: | АНОТАЦІЯ
Виконавець: Різник Олександр Михайлович
Назва роботи: Інформаційна система університету. Клієнтська частина підсистеми роботи з індивідуальними предметами
Спеціальність: 121 Інженерія програмного забезпечення.
Навчальний заклад: «Черкаський державний технологічний університет» м.Черкаси, 2026 р.
У бакалаврській роботі розглядається розробка програмного забезпечення клієнтської частини підсистеми роботи з індивідуальними предметами. Основною метою роботи є створення програмного забезпечення, що надасть змогу працівникам деканату ЧДТУ зручно та ефективно працювати з індивідуальними предметами студентів, формувати відповідну документацію, що буде реалізовано у вигляді клієнтської частини підсистеми інформаційної системи університету.
У ході роботи, було проведено огляд аналогів, потім було поставлено конкретні задачі та було проведено детальний аналіз вимог до підсистеми. У результаті дослідження, було досягнуто наступних результатів:
- вимоги: було визначено основний функціональні вимоги до підсистеми, що включали в себе основні методи керування предметами та їх даними, формування документації, розпізнавання за допомогою сервісу, та нефункціональні вимоги, що включають в себе зрозумілість, зручність та ефективність;
- моделювання: було створено концептуальну та логічну моделі підсистеми, визначено основні сутності та компоненти, та їх взаємодія;
- реалізація: підсистема була розроблена згідно поставлених задач та вимог, за допомогою фреймворку Angular та мови програмування TypeScript. Результати розробки були задокументовані та описані в пояснювальній записці. SUMMARY Author: Oleksandr Mykhailovych Riznyk Title of thesis: University Information System. Individual courses management subsystem frontend Specialisation: 121 Software Engineering. Educational institution: ‘Cherkasy State Technological University’, Cherkasy, 2026 This bachelor’s thesis examines the development of software for the client-side of the subsystem for managing individual subjects. The main objective of the thesis is to create software that will enable staff at the Cherkasy State Technological University (CSTU) Dean’s Office to work conveniently and efficiently with students’ individual subjects and to generate the relevant documentation, which will be implemented as the client-side of the university information system’s subsystem. During the course of the work, a review of similar systems was conducted, followed by the formulation of specific objectives and a detailed analysis of the requirements for the subsystem. The research yielded the following results: - requirements: the main functional requirements for the subsystem were identified, including the primary methods for managing courses and their data, generating documentation, and recognition via a service; non-functional requirements were also identified, including clarity, usability and efficiency; - modelling: conceptual and logical models of the subsystem were created, and the main entities, components, and their interactions were defined; - implementation: the subsystem was developed in accordance with the set tasks and requirements, using the Angular framework and the TypeScript programming language. The results of the development were documented and described in an explanatory note. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9669 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Різник Олександр Михайлович_2026.pdf Restricted Access | 8.92 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
бакалавра
на тему: Інформаційна система університету. Клієнтська частина
підсистеми роботи з індивідуальними предметами
Виконав: студент 4 курсу, групи ПЗ-2204
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Різник О.М.
(прізвище та ініціали)
Керівник Заспа Г. О.
(прізвище та ініціали)
Рецензент Сметанін О. Г.
(прізвище та ініціали)
Черкаси 2026
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
С. Голуб
«___» _______________ 2026 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Різник Олександр Михайлович
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Інформаційна система університету. Клієнтська частина підсистеми
роботи з індивідуальними предметами
Керівник проекту (роботи) Заспа Григорій Олександрович к.т.н. доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від «12» березня
2026 року №56/03-03
2. Строк подання студентом проекту (роботи)
3. Вхідні дані до проекту (роботи)
Ноутбук з операційною системою Arch Linux, процесором Intel Core I5-10300H, відеокартою
NVIDIA GeForce GTX 1650 Mobile, 16 ГБ оперативної пам'яті DDR4.
Інструментальні засоби розробки: Мова програмування TypeScript, фреймворк для розробки
web-інтерфейсу (Angular) та об’єктно-реляційна система керування базами даних
(PostgreSQL).
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Розділ 1 Існуючі методи та засоби розв’язання поставлених завдань
Розділ 2 Впровадження результатів досліджень у практику проектування програмного
забезпечення інформаційних систем
Розділ 3 Розробка та тестування програмного забезпечення
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту):
Слайди презентації кваліфікаційної роботи.
6. Консультанти розділів роботи
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання 25.11.2025
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№
Назва етапів випускної роботи етапів випускної Примітки
п/п
роботи
1 Постановка задачі 05.12.2025 виконано
2 Підготовка завдання 11.12.2025 виконано
3 Погодження завдання 18.12.2025 виконано
4 Затвердження завдання 22.12.2025 виконано
Основна стадія виконано
1 Підбір матеріалів 12.01.2026 виконано
2 Аналіз шляхів вирішення поставленої задачі 16.01.2026 виконано
3 Розрахунок основних параметрів роботи 22.01.2026 виконано
4 Вибір кінцевого варіанту проектного рішення 10.02.2026 виконано
5 Оформлення первісної редакції роботи 16.02.2026 виконано
Заключна стадія виконано
1 Узгодження прийнятих проектних рішень з 12.03.2026 виконано
керівником
2 Оформлення пояснювальної записки роботи в 05.05.2026 виконано
кінцевій редакції
3 Попередній захист роботи 20.05.2026 виконано
4 Затвердження роботи 21.05.2026 виконано
5 Рецензування роботи 28.05.2026 виконано
6 Захист роботи виконано
Студент _____________________ Різник О.М,
(підпис) (прізвище та ініціали)
Керівник проекту (роботи) _____________________ Заспа Г.О.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Виконавець: Різник Олександр Михайлович
Назва роботи: Інформаційна система університету. Клієнтська частина
підсистеми роботи з індивідуальними предметами
Спеціальність: 121 Інженерія програмного забезпечення.
Навчальний заклад: «Черкаський державний технологічний університет»
м.Черкаси, 2026 р.
У бакалаврській роботі розглядається розробка програмного забезпечення
клієнтської частини підсистеми роботи з індивідуальними предметами.
Основною метою роботи є створення програмного забезпечення, що надасть
змогу працівникам деканату ЧДТУ зручно та ефективно працювати з
індивідуальними предметами студентів, формувати відповідну документацію,
що буде реалізовано у вигляді клієнтської частини підсистеми інформаційної
системи університету.
У ході роботи, було проведено огляд аналогів, потім було поставлено
конкретні задачі та було проведено детальний аналіз вимог до підсистеми. У
результаті дослідження, було досягнуто наступних результатів:
- вимоги: було визначено основний функціональні вимоги до підсистеми,
що включали в себе основні методи керування предметами та їх даними,
формування документації, розпізнавання за допомогою сервісу, та
нефункціональні вимоги, що включають в себе зрозумілість, зручність та
ефективність;
- моделювання: було створено концептуальну та логічну моделі
підсистеми, визначено основні сутності та компоненти, та їх взаємодія;
- реалізація: підсистема була розроблена згідно поставлених задач та
вимог, за допомогою фреймворку Angular та мови програмування TypeScript.
Результати розробки були задокументовані та описані в пояснювальній записці.
Ключові слова: інженерія програмного забезпечення, інформаційна
система, підсистема роботи з індивідуальними предметами, Angular, TypeScript,
деканат.
SUMMARY
Author: Oleksandr Mykhailovych Riznyk
Title of thesis: University Information System. Individual courses management
subsystem frontend
Specialisation: 121 Software Engineering.
Educational institution: ‘Cherkasy State Technological University’, Cherkasy,
2026
This bachelor’s thesis examines the development of software for the client-side
of the subsystem for managing individual subjects. The main objective of the thesis is
to create software that will enable staff at the Cherkasy State Technological University
(CSTU) Dean’s Office to work conveniently and efficiently with students’ individual
subjects and to generate the relevant documentation, which will be implemented as the
client-side of the university information system’s subsystem.
During the course of the work, a review of similar systems was conducted,
followed by the formulation of specific objectives and a detailed analysis of the
requirements for the subsystem. The research yielded the following results:
- requirements: the main functional requirements for the subsystem were
identified, including the primary methods for managing courses and their data,
generating documentation, and recognition via a service; non-functional requirements
were also identified, including clarity, usability and efficiency;
- modelling: conceptual and logical models of the subsystem were created, and
the main entities, components, and their interactions were defined;
- implementation: the subsystem was developed in accordance with the set
tasks and requirements, using the Angular framework and the TypeScript programming
language. The results of the development were documented and described in an
explanatory note.
Keywords: software engineering, information system, subsystem for working
with individual courses, Angular, TypeScript, dean’s office.
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ....................................................................6
ВСТУП.........................................................................................................................7
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ...................................................................................9
1.1. Аналіз технічної інформації.............................................................................9
1.2. Постановка задачі............................................................................................11
1.3. Огляд аналогів ................................................................................................12
1.3.1. Огляд інформаційно-аналітичної системи «Університет»....................13
1.3.2. Огляд інформаційно-аналітичної системи АСУ «ВНЗ»........................15
1.4. Опис технологій...............................................................................................16
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ..................................................................19
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ.............................................................................20
2.1. Моделювання предметної області.................................................................20
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області .............................................................................. 21
2.1.2. Елементи моделювання предметної області...........................................22
2.1.3. Робоча область моделювання ..................................................................23
2.2. Формування та аналіз вимог .......................................................................... 25
2.2.1. Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги...................................................................................................................25
2.2.2. Формування вимог за допомогою діаграми прецедентів......................29
2.3. Проектування логічної структури програмного комплексу........................33
2.3.1. Діаграми класів..........................................................................................33
2.3.2. Діаграми пакетів........................................................................................36
2.4. Архітектурне проектування............................................................................39
ЧДТУ 262259.020ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб. Різник О.М.
Перевір. Заспа Г.О. Інформаційна система Літ. Лист Листів
університету. Клієнтська частина 4
Н. Контр. Півень О.Б. підсистеми роботи з ФІТІС, кафедра ПЗАС, ПЗ-2204
Затверд. Голуб С.В. індивідуальними предметами
2.4.1. Діаграма компонентів...............................................................................39
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання..........................................................................................................41
2.5. Моделювання поведінки системи..................................................................43
2.5.1. Діаграма діяльності...................................................................................44
2.5.2. Діаграма послідовності.............................................................................48
2.5.3. Діаграма комунікації.................................................................................50
2.5.4. Діаграма скінченного автомату ............................................................... 54
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ................................................................... 62
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ ....................................................................................................64
3.1. Розробка програмного комплексу..................................................................64
3.1.1. Обґрунтування вибору засобів реалізації ...............................................64
3.1.2. Опис структурної (функціональної) схеми.............................................65
3.1.3. Опис логічної схеми системи...................................................................67
3.1.4. Розробка бази даних..................................................................................70
3.1.5 Розробка інтерфейсу користувача............................................................71
3.1.6. Опис розробки програмних компонентів ............................................... 73
3.2. Тестування системи.........................................................................................75
3.2.1 Модульне тестування.................................................................................75
3.2.2 Інтеграційне тестування............................................................................76
3.2.3 Системне тестування..................................................................................77
3.2.4 Приймальне тестування.............................................................................78
3.3 Приклади впровадженого програмного комплексу......................................79
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ..................................................................82
ВИСНОВКИ..............................................................................................................83
СПИСОК ВИКОРИСИТАНИХ ДЖЕРЕЛ..........................................................85
ДОДАТОК А .............................................................................................................88
ДОДАТОК Б .............................................................................................................90
ДОДАТОК В ...........................................................................................................118
ДОДАТОК Г ........................................................................................................... 130
ЧДТУ 262259.020 ПЗ
Змн. Арк. № докум. Підпис Дата
ЧДТУ 262259.020 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
Позначення Значення
API Application Programming Interface - програмний інтерфейс
застосунку
Angular Фреймворк для розробки вебзастосунків
ЄДЕБО Єдина державна електронна база з питань освіти
SPA Single Page Application - односторінковий вебзастосунок
АС Автоматизована система
АСУ Автоматизована система управління
ІС Інформаційна система
НДІ ПІТ Науково-дослідний інститут прикладних інформаційних
технологій
6
ЧДТУ 262259.020 ПЗ
ВСТУП
Актуальність теми. Дана кваліфікаційна робота бакалавра належить до
спеціальності інженерія програмного забезпечення. Актуальність розробки
визначається необхідністю створення програмного забезпечення модуля роботи
з індивідуальними предметами інформаційної системи університету, а саме
клієнтської частини, і зумовлена появою нових видів предметів (наприклад,
академічна мобільність) та необхідністю в додатках до диплому та інших
документах відображати перезарахування предметів окремо, що приводить до
необхідності виділення індивідуальних предметів студента в окрему сутність та
розробку функціоналу для роботи з ними.
Розробка цієї підсистеми також актуальна з точки зору дослідження роботи
систем з великою кількістю даних, а також взаємодії великої кількості модулів
між собою.
Клієнтську частину реалізовано за допомогою сучасних програмних
підходів, що забезпечують зручну та ефективну взаємодію користувача з
системою. В основі частини лежить робота з студентами, та їх індивідуальними
предметами. Ці дані будуть відображатись у веб-інтерфейсі підсистеми, і за
допомогою виборів елементів списку і відповідних кнопок, буде відбуватись їх
обробка.
Мета і завдання розробки
Мета розробки: розробити програмне забезпечення підсистеми роботи з
індивідуальними предметами, що надасть можливість працівникам деканатів
ЧДТУ зручно проводити всі необхідні дії з індивідуальними предметами
студентів, в тому числі коректно формувати документи, в яких задіяна
інформація про індивідуальні предмети шляхом створення клієнтської частини
підсистеми роботи з індивідуальними предметами інформаційної системи
університету.
Завдання розробки
1 Провести аналіз вимог до підсистеми та дослідити особливості
опрацювання індивідуальних предметів в деканаті.
7
ЧДТУ 262259.020 ПЗ
2 Розробити концепцію підсистеми та визначити основні модулі.
3 Створити архітектуру програмного забезпечення підсистеми.
4 Реалізувати основний функціонал підсистеми.
5 Провести тестування підсистеми і оптимізувати продуктивність.
6 Впровадити розроблену підсистему у використанні.
Об'єкт розробки: процес розробки програмного забезпечення
інформаційних систем в галузі освіти.
Предмет розробки: програмне забезпечення підсистеми роботи з
індивідуальними предметами студентів в інформаційно-аналітичній системі
підтримки освітньої діяльності університету
Методи проектування та конструювання
Методи проектування: для розробки було використано компонентно-
орієнтовану архітектуру Angular, а також об’єктно-орієнтоване програмування
з використанням мови TypeScript. Об’єднання цих двох підходів забезпечують
гнучку модульну архітектуру проекту, що робить її легко масштабованою і
створює передумови для розширення функціоналу в подальшому.
Практичне значення отриманих результатів
Розроблена підсистема використовується працівниками деканатів ЧДТУ
для підвищення ефективності їх роботи з інформацією про студентів та
формування відповідних документів.
Особистий внесок автора: у процесі виконання роботи автор самостійно
розробив компоненту архітектуру підсистеми, реалізував основний функціонал,
що включав в себе обробку індивідуальних предметів студента, і формування
документів з цими предметами.
8
ЧДТУ 262259.020 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1. Аналіз технічної інформації
Інформаційно-аналітична система підтримки освітньої діяльності
університету бере свій початок з 2018 року, коли під ініціативою університету і
декількох ІТ-компаній було створено проект, що дозволить студентами отримати
реальні практичні навички в програмуванні, і при цьому розробити програмне
забезпечення, що покращить якість і продуктивність роботи працівників
деканатів ЧДТУ.
Перша версія системи містила в собі 4 вкладки:
- «Початок року»;
- «Впродовж семестру»;
- «Кінець семестру»;
- «Документи».
Вкладка «Початок року» містила в собі наступні розділи:
- «Спеціальності»: працівник деканату може переглянути актуальні і не
актуальні спеціальності свого факультету;
- «Освітні програми»: працівник деканату може переглянути список
освітніх програм, а при потребі: створити нову освітню програму, відредагувати
існуючу або видалити непотрібну;
- «Групи»: працівник деканату може переглянути активні та неактивні
групи факультету, створити нову групу, або відредагувати чи видалити існуючу;
- «Предмети»: працівник деканату може переглянути всі наявні предмети,
що викладають в межах його факультету;
- «Предмети для груп»: працівник деканату може вибрати групу та
семестр, та переглянути список предметів що викладаються в групи, а також мав
змогу додати або видалити предмети для вибраної групи;
9
ЧДТУ 262259.020 ПЗ
- «Викладачі»: працівник деканату може переглянути список всіх
викладачів університету, або лише свого факультету. Також мав змогу додати
або видалити викладача, або відредагувати його дані;
- «Кафедри»: працівник деканату може переглянути список наявних
кафедр на факультеті, а також здійснити додавання нової кафедри, або
редагування чи видалення вже існуючої;
Вкладка «Впродовж семестру» містила в собі наступні розділи:
- «Студенти»: працівник деканату може переглянути список всіх
студентів факультету, а також виконувати наступні дії: переглядати та
редагувати особисту та навчальну інформацію, направляти в академічну
відпустку, відрахувати студента або зарахувати нового, додати і переглянути
тему дипломної роботи, а також сформувати виписку з залікової книжки;
- «Відраховані студенти»: працівник деканату може переглянути
інформацію про студентів, відрахованих за весь час, або лише за останні 5 років,
а також поновити їх;
- «Студенти в академ. відпустці»: працівник деканату може переглянути
інформацію про студентів що на даний момент знаходяться в академічній
відпустці, а також поновити їх;
- «Оцінки»: працівник деканату може вибрати групу та семестр, і
переглянути чи редагувати оцінки студентів цієї групи;
- «Стипендія»: працівник деканату може переглянути таблиці з
студентами різних груп, редагувати їх, і на їх основі формувати рейтинг
студентів;
- «Звіт з успішності»: працівник деканату може вибрати спеціальність, і
переглянути статистику успішності (кількість боргів) студентів всіх курсів.
При переході на вкладку «Кінець року», працівник деканату може
завершити навчальних рік. Перед ним відображались всі групи і їх студенти, і
він міг як відрахувати студентів, так і перевести їх на наступний курс.
Вкладка «Документи» містила в собі наступні розділи:
10
ЧДТУ 262259.020 ПЗ
- «Відомості»: працівник деканату може обрати групу, семестр та
предмети, і на їх основі сформувати документ відомості;
- «Зведені відомості»: працівник деканату може сформувати відомість
студентів-боржників, можливо з різних груп;
- «Додатки до диплому»: працівник деканату може обрати групу, обрати
студентів і на їх основі виконати наступні дії: перевірити дані та оцінки
студентів, перевірити переклад назв предметів, переглянути таблиці оцінок та
предметів студентів, а також сформувати додаток або відомості перед захистом
чи захисту випускників;
- «Виписки в особисті справи»: працівник деканату може обрати групи та
виділити всіх або конкретних студентів, сформувати або повну виписку, або
лише першу чи останню сторінку та сформувати індивідуальний план студента;
- «Додаткові документи»: працівник деканату може обрати групу та
семестр, і на їх основі сформувати наступні документи: виписку в журнал
відомостей, журнал оцінок, списки предметів в журнал оцінок та списки
студентів (повні та неповні).
Наступним кроком була можливість взяття інформації про студента з
ЄДЕБО. Цей крок допоміг заповняти дані студентів коректними даними, і
виправити некоректно введені дані до цього.
Наступним нововведенням, що пізніше переросло в проблему для
вирішення, стало введення атрибуту “Академічна різниця”, що пізніше
переросте в потребу створення нової сутності - індивідуальний предмет. З
появою потреби наявності предмету виду “Перезарахування”, було створено
сутність індивідуального предмету.
Індивідуальні предмети включатимуть в собі особисті предмети студента,
що не були пройдені в нашому університеті, і які потрібно або перезарахувати за
рахунок предметів вивчених на попередньому місці навчання, або самому
пройти курс і здати їх (академічна різниця). Також сюди будуть входити
предмети академічної мобільності, пройдені в інших закладах навчання.
1.2. Постановка задачі
11
ЧДТУ 262259.020 ПЗ
Метою кваліфікаційної роботи є надання можливості працівникам
деканатів ЧДТУ зручно проводити всі необхідні дії з індивідуальними
предметами студентів, в тому числі коректно формувати документи, в яких
задіяна інформація про індивідуальні предмети шляхом створення клієнтської
частини підсистеми роботи з індивідуальними предметами інформаційно-
аналітичної системи підтримки освітньої діяльності університету.
Для вирішення цієї проблеми, потрібно виконати наступні кроки:
1 Провести аналіз подібних систем і аналогів, їх принцип роботи, а також
дослідити особливості опрацювання індивідуальних предметів в деканаті.
2 Дослідити та освоїти стек технологій, що використовується для
розробки інтелектуально-аналітичної системи.
3 Розробити архітектуру підсистеми на основі компонентно-орієнтованої
архітектури фреймворку Angular, з урахуванням подальшої можливості
додавання компонентів і їх зв’язку в межах підсистеми.
4 Реалізувати:
- збереження, редагування та видалення предметів;
- зміну виду предмету;
- додавання предмету академічної мобільності і редагування її даних;
- завантаження зображення з додатку до диплому, і відправлення його
серверну частину для обробки;
- обробку даних, отриманих із зображення з додатку до диплому
(порівняння отриманих предметів з предметами навчального плану, і вибір
предметів для зарахування та академічної різниці);
5 Провести тестування створеного програмного забезпечення і
оптимізувати його роботу.
1.3. Огляд аналогів
Інформаційно-аналітичні системи підтримки освітньої діяльності
університету в сьогодення є необхідною складовою життя університету. Вона
12
ЧДТУ 262259.020 ПЗ
необхідна для автоматизації роботи, її пришвидшення та зменшення ймовірності
похибок, а також спростити роботу працівникам навчального закладу.
Одними з представників подібних систем в Україні є «Інформаційно-
аналітична система «Університет» (Сумський державний університет) і «АСУ
«ВНЗ».
1.3.1. Огляд інформаційно-аналітичної системи «Університет»
«Університет» – інформаційно-аналітична система, що використовується
в
Сумському державному університеті. Систему забезпечує підтримку процесів
керування навчальною, науковою та іншими видами діяльності університету та
забезпечує співробітників університету відповідним інструментарієм
ефективного виконання професійних функцій. Система підтримує керування
всіма етапами навчального процесу – від розробки навчальних планів та графіків
навчального процесу, розрахунку навантаження кафедр та викладачів, до
повного супроводження студентів протягом усього періоду їх навчання, що
починається під час вступної кампанії, та закінчується присвоєнням кваліфікації.
Система складається з 6 підсистем:
- «АБІТУРІЄНТ» – обробляє особові справи абітурієнтів, автоматично
формує конкурсні ситуації, протоколи, накази, а також друковані форми всіх
документів, статистичних та аналітичних звітів;
- «СТУДЕНТ» – обробляє навчальні картки студентів (з можливістю
завантаження фото, перегляду інформації по успішності студента, тощо),
автоматично формує на базі семестрових навчальних планів екзаменаційні
відомості студентів, накази по контингенту студентів на призначення стипендії,
на матеріальну допомогу та заохочення, додатки до дипломів, форми наказів,
відомостей та інших документів. Також веде електронний реєстр заяв студентів
щодо вибору дисциплін та зручний редактор для закріплення вибраних
дисциплін за студентами;
- «НАВЧАННЯ» – формує базові, робочі та семестрові навчальні плани,
робочі програми навчальних дисциплін, веде базові та робочі графіки, обробляє
13
ЧДТУ 262259.020 ПЗ
значення показників по структурним підрозділам та веде автоматизований
розрахунок рейтингових місць згідно затвердженої методики. Також має
спеціалізований модуль зі зручним інтерфейсом для формування розкладу
навчального процесу з механізмом блокування аудиторій, викладачів та
навчальних груп;
- «ФІНАНСИ» – обробляє договори на навчання студентів з механізмом
автоматизованого нарахування та формування поточного балансу по договору,
наукові договори, веде облік субрахунків підрозділів, автоматичне формування
залишків коштів на субрахунках у розрізі статей для забезпечення контролю
витрачення коштів, і автоматично розподіляє кошти по субрахункам підрозділів
згідно затверджених положень;
- «ДОКУМЕНТИ» – обробляє рішення вченої, наукової та методичної
рад, вхідних, вихідних та внутрішніх документів з механізмом автоматизованого
контролю виконання завдань, веде електронний реєстр нормативних документів
і автоматично формує посвідчення на відрядження;
- «ПЕРСОНАЛ» – веде особові справи співробітників, формує накази по
контингенту, лікарняні листи та підвищення кваліфікації.
Всі ці підсистеми зосередженні на роботі з документами, зв’язаними з
відповідною темою.
Також система має інформаційні сервіси, що забезпечують доступ до
різноманітної інформації з сайту університету.
Крім цього, система має інтеграцію з іншими системами:
- експорт-імпорт особових справ абітурієнтів,
- автоматична перевірка відповідності даних сертифікату на порталі
УЦОЯО,
- експорт даних до ІС «КОНКУРС» МОНМС України,
- інтеграція з системою EDBO МОНМС України,
- імпорт бібліотечного каталогу із «УФД/Бібліотека»,
- експорт даних до підсистеми «DP2000»,
14
ЧДТУ 262259.020 ПЗ
- автоматичний імпорт платіжних документів ПриватБанку з механізмом
розподілу по договорам,
- експорт наказів на призначення стипендії, матеріальної допомоги до
системи «Бухгалтерія»,
- імпорт платіжних документів та документів витрачення коштів по
науковим договорам з системи «Бухгалтерія».
1.3.2. Огляд інформаційно-аналітичної системи АСУ «ВНЗ»
АСУ «ВНЗ» – інформаційно-аналітична система, розроблена Науково-
дослідним інститутом прикладних інформаційних технологій (НДІ ПІТ).
Система складається з 4 основних компонентів (підсистем):
- АС «Приймальна комісія» – підсистема що повністю автоматизовує всі
етапи вступної кампанії, починаючи з реєстрації абітурієнтів та обробки заяв,
закінчуючи формування конкурсних списків та наказів про зарахування;
- АС «Деканат» – центральна підсистема, що автоматизовує весь
навчальний процес закладу навчання. Включає в себе ведення бази студентів,
формування навчальних планів, розкладу занять, журналів успішності, тощо;
- АС «Студмістечко» – підсистема що автоматизовує управління
студентських гуртожитків. Веде облік мешканців, договори, заяви, фінансову
звітність;
- АС «Конструктор звітів» – підсистеми що являє собою інструмент для
створення на редагування будь яких звітів, що містяться в системі.
Також система містить додаткові модулі та розширення:
- веб-кабінет студента – електронний кабінет, де студенти можуть
переглядати свої дані, навчальне навантаження, оцінки тощо;
- веб-кабінет викладача – електронний кабінет, де викладачі можуть
переглянути свої дані, розклад, вести журнал чи заповнювати екзаменаційні
відомості тощо;
- веб-розклад – веб-сторінка, що відображає розклад занять для студентів
та викладачів.
15
ЧДТУ 262259.020 ПЗ
- проект «Безпечний ЗВО» – додатковий комплекс для організації безпеки
з навчальному закладі.
Крім того, ця система є успішним комерційним проектом, який було
введено в понад 70 вищих навчальних закладів України, і має рекомендацію для
застосування від Міністерства Освіти України.
1.4. Опис технологій
У процесі розробки клієнтської частини підсистеми для роботи з
індивідуальними предметами буде використовуватись фреймворк Angular і мова
програмування TypeScript. Їх було вибрано, адже решта системи була написана
на цьому стеку технологій. Ці технології забезпечать високу продуктивність,
масштабованість та зручність подальшого супроводу програмного забезпечення.
Фреймворк Angular
Angular – це веб-фреймворк, розроблений компанією Google, який
використовується для створення динамічних односторінкових додатків (Single
Page Applications, SPA). Він дозволяє розробникам будувати високопродуктивні
веб-додатки з використанням мови програмування TypeScript.
Основними особливостями Angular є:
- компонентна архітектура: Angular побудований на основі компонентної
моделі, де веб-додаток розбивається на невеликі, самостійні компоненти. Кожен
компонент містить свій шаблон, стилі і логіку, що дозволяє розробникам легко
організовувати та управляти кодом;
- двостороннє зв’язування даних: Angular надає механізм двостороннього
зв’язування даних, що дозволяє автоматично синхронізувати дані між
компонентами та їх шаблонами. Це полегшує маніпулювання даними і
оновлення їх в реальному часі;
- залежності та ін’єкція залежностей: Angular має вбудовану систему
ін’єкції залежностей, що дозволяє легко управляти залежностями між
компонентами. Це спрощує розробку, тестування і підтримку коду;
16
ЧДТУ 262259.020 ПЗ
- роутинг: Angular надає механізм маршрутизації, що дозволяє
створювати багатосторінкові додатки. З його допомогою можна визначити, який
компонент відображати для кожного URL-шляху;
- розширюваність: Angular має широкий набір функціональності, яку
можна розширити за допомогою сторонніх модулів. Існує велика кількість
сторонніх бібліотек і модулів, які розширюють можливості фреймворка.
Всі ці особливості Angular допоможуть мені ефективно розробити
підсистему інформаційно-аналітичної системи, що складається з багатьох
взаємопов’язаних компонентів, зберігаючи чітку структуру підсистеми, та
спрощуючи їх взаємодію, супровід і масштабування в подальшій розробці
Мова програмування TypeScript
TypeScript – це мова програмування, яка розширює JavaScript, додаючи
статичну типізацію та деякі інші функції. TypeScript базується на JavaScript, тому
він дозволяє використовувати всі функції та бібліотеки JavaScript, але також
надає можливості для більш безпечного й організованого програмування.
Використання TypeScript у даній підсистемі забезпечує підвищення
надійності коду за рахунок статичної типізації, покращує читабельність та
структурованість програмного коду та надає можливість використовувати
об’єктно-орієнтований підхід.
Саме тому, використання TypeScript є доцільним для цієї підсистеми,
оскільки такі підсистеми зазвичай мають громіздку та складну бізнес-логіку і
велику кількість взаємопов’язаних сутностей, які потрібно чітко
структуризувати, і спростити їх подальше використання.
Мова стилів SCSS
SCSS (Sassy CSS) – це розширення стандартної каскадної таблиці стилів
CSS, яке використовується для створення та організації стилів користувацького
інтерфейсу вебзастосунків.
Основні особливості SCSS:
17
ЧДТУ 262259.020 ПЗ
- підтримка змінних: SCSS дозволяє створювати змінні, і надавати їм
значення конкретних кольорів, градієнтів, шрифтів та інших параметрів
оформлення та спрощує їх використання;
- вкладені правила: механізм вкладеності, що надає змогу описувати стилі
елементів відповідно до ієрархії в HTML, покращуючи читабельність та
зменшуючи кількість повторів;
- міксини: вони дозволяють багато разово використовувати набори стилів
з можливістю передачі параметрів, що набагато зменшує дублювання коду та
спрощує застосування стилів;
- наслідування та повторне використання стилістичних компонентів:
дозволяє розширювати та перевикористовувати вже існуючі стилістичні
компоненти, що спрощує їх використання та запобігає дублюванню коду;
Використання цього розширення у рамках розробки клієнтської частини
підсистеми дозволить забезпечити єдиний стиль веб-інтерфейсу, спростити
масштабування стилів в підсистемі і їх повторне використання, а також підвищує
зручність супроводу.
Поєднання з Angular також надає змогу застосовувати компонентний
підхід до оформлення інтерфейсу, ізолюючи стилі окремих компонентів, зо
зменшує ризик конфлікту стилів.
18
ЧДТУ 262259.020 ПЗ
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ
У першому розділі кваліфікаційної роботи було описано існуючу
інформаційно-аналітичну систему, було поставлено задачі та проаналізовані
аналоги, що використовуються в інших навчальних закладах. Також було
досліджено технології, за допомогою яких будуть реалізовані компоненти
підсистеми.
Опис існуючої інформаційно-аналітичної системи дозволив більше
детально ознайомитись з її структурою, а також визначити основну потребу
створення нової підсистеми і її функціоналу. Компонентно-орієнтована
архітектура спростить процес розробки, та надасть чітку структуру підсистемі,
зручну для подальшого масштабування.
Аналіз аналогів у вигляді інших інформаційно-аналітичних систем, що
використовуються в інших навчальних закладах, показав що всі вони мають
компонентно-орієнтовану архітектуру, що складається з декількох
функціональних компонентів (модулів), кожен з яких строго відповідає за своє
завдання, але загалом вони поєднуються в єдину систему.
Також було досліджено технології, що будуть використані в розробці.
Результати аналізу аналогів та опису вже існуючої системи остаточно
підтвердили компонентно-орієнтовану архітектуру підсистеми, для якої
використання Angular разом з TypeScript є відмінним вибором.
Дані отримані з аналізу аналогів та опису поточної системи разом з
отриманими знаннями від дослідження технологій розробки дозволять в
подальшому спростити та підвищити ефективність розробки підсистеми.
19
ЧДТУ 262259.020 ПЗ
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
2.1. Моделювання предметної області
Моделювання предметної області є важливим етапом у розробці
підсистеми інформаційно-аналітичної системи, адже це допоможе створити
абстрактне уявлення про архітектуру проекту, а також допоможе визначити
основні компоненти і модулі що будуть використовуватись, і зв’язок між ними.
На цьому етапі визначаються загальна кількість компонентів та модулів, їх
функціонал та структура веб-інтерфейсу підсистеми.
Концептуальна модель підсистеми визначає сутності предметної області
і їх властивості. Основними об’єктами підсистеми будуть індивідуальні
предмети студентів, предмети, студенти та контроль знань. Індивідуальні
предмети будуть містить в собі посилання на сутність предмету, кількість
кредитів, тип контролю знань (залік, екзамен чи курсова робота), викладача,
посилання на сутність студента, якому належить цей предмет, вид предмету
(академічна різниця, перезарахування чи академічна мобільність), вказівник чи
є цей предмет вибірковим, а також дані про попереднє місце навчання. Ці дані
міститимуть в собі назву закладу навчання, дата початку та кінця навчання, а
також дату та номер сертифікату. Сутність предмет містить в собі дані про назву
предмету, кількість годин і кредитів а також контроль знань. Контроль знань
містить в собі лише атрибут імені та ідентифікатор.
Логічна модель підсистеми описує дії користувача на основні об’єкти
підсистеми та описує бізнес-логіку її функціоналу. Працівник деканату ЧДТУ
матиме змогу переглядати групи і список їх студентів, а також які індивідуальні
предмети вони мають. Крім цього, користувач може створити власний предмет,
додати індивідуальні предмети студентам, редагувати та видаляти їх, змінювати
вид, за допомогою нейромережі обробляти зображення додатків до диплому і
порівнювати отримані предмети з предметами навчального плану, вказуючи які
20
ЧДТУ 262259.020 ПЗ
предмети перезарахувати, а які позначити як академічну різницю, а також
сформувати відомість з академічною різницею.
Цей підхід до моделювання предметної області дозволяє чітко продумати
архітектуру компонентів, їх взаємодію і дозволить в подальшому масштабувати
і доповнювати її.
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметна область моделювання підсистеми для роботи з
індивідуальними предметами студентів охоплює всі аспекти функціоналу по
роботі з ними. Основні об’єкти предметної області для підсистеми включають:
- індивідуальний предмет: предмет який призначається лише для
конкретного студента. Призначається предмет лише у випадку, коли студент
перевівся на навчання з іншого навчального закладу, або по обміну навчався в
іноземному закладі навчання, і з’являється потреба перезарахувати предмети
пройдені там, згідно навчального плану ;
- дані про попереднє місце навчання: дані, що містять в собі назву
навчального закладу, термін навчання, а також номер і дату сертифікату.
Потрібні для підтвердження проходження предмету для його перезарахування;
- предмет: містить в собі загальні дані про дисципліну, такі як назва,
кількість годин та кредитів, семестр та контроль знань;
- студент: містить в собі дані про студента, такі як група, спеціальність та
інші;
- контроль знань: містить в собі назву типу контролю знань, наприклад
іспит, залік, курсовий проект, тощо.
Моделювання предметної області дозволяє створити чітке уявлення про
структуру та функціонал підсистеми, визначити її компоненти та їх взаємодію,
а також переглянути наявні сутності в додати нові. Це допоможе забезпечити
ефективний процес розробки та впровадження підсистеми, мінімізувавши
ризики появи помилок, а також забезпечує можливість масштабування
підсистеми.
21
ЧДТУ 262259.020 ПЗ
Словник предметної області
Предмет – нормативна одиниця навчального плану, що містить в собі такі
дані, як назва предмету, семестр, тип контролю знань, кількість кредитів та
годин.
Студент – фізична особа, що проходиться навчання в нашому закладі
навчання. Містить атрибути що описують його особисті та навчальні дані
(прізвище, ім’я, назва групи, спеціальність тощо).
Індивідуальний предмет – предмет що зараховується студенту в
індивідуальному порядку, поза основним навчальним планом і є унікальним для
студента. Містить атрибути посилання на предмет, студента, вид предмету а
також дані про попереднє місце навчання.
Контроль знань – спосіб перевірки результату вивчення студентом
відповідної дисципліни.
Вид предмету – атрибут що класифікує індивідуальний предмет і визначає
підставу для зарахування предмету студенту в індивідуальному порядку.
Попереднє місце навчання – довідкова інформація, що містить в собі
посилання на сутність закладу навчання, дату та номер сертифікату, а також дати
початку на кінця навчання.
2.1.2. Елементи моделювання предметної області
У процесі моделювання предметної області для програмного забезпечення
клієнтської частини підсистеми роботи з індивідуальними предметами буде
використано різні елементи UML (Unified Modeling Language), які допоможуть
наочно представити структуру та функціональність підсистеми.
Для моделювання предметної області підсистеми будуть використані
діаграми UML (Unified Modeling Language), які є стандартним засобом для
візуалізації, специфікації, конструювання та документування артефактів
програмних систем. Основні елементи моделювання UML, що
використовуються для опису предметної області підсистеми, включають класи
(наприклад, індивідуальний предмет, студент), об'єкти (конкретні екземпляри
цих класів), атрибути (назва предмету, його вид, група студента), методи (дії, які
22
ЧДТУ 262259.020 ПЗ
можуть виконуватись над об’єктами), асоціації (зв'язки між об'єктами), та різні
типи діаграм.
Використання UML для моделювання підсистеми дозволяє отримати
наочну схему її архітектури та бізнес-логіки. Наочне відображення допомагає
краще розуміти будову підсистеми і принцип її робити. Також це є основою для
подальшого проектування сутностей, їх атрибутів і їх взаємозв’язків. Все це
значно поліпшить подальшу розробку та тестування програмного забезпечення.
2.1.3. Робоча область моделювання
Робоча область моделювання охоплює всі аспекти інтелектуальної
системи, що можна змоделювати для кращого розуміння архітектури проекту, її
аналізу та можливості проектування.
У контексті робочої області інтелектуальної системи визначаються
сутності, а також функціональні модулі, що використовуватимуться
працівником деканату під час роботи з індивідуальними предметами студентів
(рисунок 2.1).
Робоча область включає в себе наступні сутності та функціональні модулі:
- працівник деканату: основний користувач системи, що взаємодіє з
підсистемою для роботи з індивідуальними предметами, виконуючи операції
призначення, редагування, видалення індивідуальних предметів, розпізнавання
і обробка предметів з додатків до диплому, а також формування необхідної
документації;
- студент: сутність, до якої ведеться список індивідуальних предметів.
також використовується для отримання та створення індивідуального плану
навчання, та отримання даних про власника індивідуального предмету (ім’я та
прізвище, група, курс, спеціальність);
- індивідуальний предмет: ключова сутність підсистеми, що описує
дисципліну, яка призначається вибраним студентам. містить дані дисципліни
(назва предмету, контроль знань, години і тп.), тип предмету (перезарахування,
академічна мобільність чи академічна різниця) та дані про попереднє місце
навчання (якщо присутні);
23
ЧДТУ 262259.020 ПЗ
- навчальний план: сукупність предметів, передбачених освітньою
програмою. використовується для порівняння з розпізнаними предметами з
додатку для диплому;
- індивідуальний навчальний план: сутність індивідуальна для
окремого студента, що містить основні та індивідуальні предмети студента;
- дані про попереднє місце навчання: інформація предмету, що
використовується для перезарахування дисципліни;
- інтелектуальний модуль розпізнавання: функціональний модуль що
розпізнає предмети з додатку для диплому, порівнює їх з предметами
навчального плану, а також надає можливість їх обробки і перезарахування в
індивідуальному навчальному плані, або призначення їх як академічної різниці;
- додаток до диплому: документ, що містить інформацію про предмети,
пройдені студентом в попередньому місці навчання, які будуть використанні для
порівняння і можуть бути перезарахованими;
- відомість перезарахування: документ, що описує перезараховані
предмети вибраних студентів.
Рисунок 2.1 – Модель робочої області
24
ЧДТУ 262259.020 ПЗ
2.2. Формування та аналіз вимог
Формування вимог є важливим етапом для програмного забезпечення
клієнтської частини підсистеми для роботи з індивідуальними предметами. На
цьому етапі будуть сформовані основні вимоги до розробки підсистеми, а саме:
вимоги до програмного забезпечення, первинні вимоги, детальні вимоги, вимоги
замовника та розробника, вимоги функціональні та нефункціональні.
2.2.1. Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги.
Формування вимог до програмного забезпечення є фундаментальним
етапом у розробці будь-якої інформаційно-аналітичної системи, включаючи
програмне забезпечення підсистеми для роботи з індивідуальними предметами.
Цей процес полягає у зборі, аналізу, задокументовуванні та управлінні вимогами,
що забезпечить в майбутньому чітке розуміння логіки роботи підсистеми, та
мінімізує ризики розбіжностей між очікуваним результатом від замовника з
отриманим.
Первинні вимоги включають загальний функціонал, який підсистема
повинна мати для виконання своїх основних завдань. Вони визначають основні
цілі та обмеження підсистеми:
- працівник деканату повинен мати можливість переглядати індивідуальні
предмети студентів;
- працівник деканату повинен мати можливість у разі потреби додати
новий індивідуальний предмет, або відредагувати чи видалити вже існуючий;
- працівник деканату повинен мати можливість відправити зображення
додатку до диплому на обробку за допомогою нейромережі, і порівняти отримані
предмети з предметом навчального плану, і перезарахувати ті, що підходять.
Детальні вимоги включають більш точні та конкретні описи функцій,
інтерфейсів, даних та інших аспектів підсистеми. Вони уточнюють первинні
25
ЧДТУ 262259.020 ПЗ
вимоги і забезпечують основу для розробки технічної документації та реалізації
системи.
1 Призначення індивідуального предмету студенту
- працівник деканату може обрати групу, семестр та виділити студентів.
Потім в таблиці з доступними предмети він може обрати предмети, які він хоче
призначити. Після цього у випадаючому списку він може обрати вид предмету
(перезарахування, академічна мобільність, академічна різниця), і натиснути
кнопку «Призначити»;
- при натиснені кнопки «Призначити» перед користувачем має з’явитись
модальне вікно зі списком студентів і списком предметів що будуть призначені,
а також вибір підтвердити чи скасувати дію. У випадку якщо будуть
призначатись предмети виду «академічна мобільність», вікно матиме додаткові
поля введення де працівник деканату може вибрати попередній заклад навчання
(або створити новий), і ввести інформацію що стосується даних академічної
мобільності (дата та номер сертифікату, дати початку та кінця навчання), окремо
для кожного предмету або загалом для всіх предметів.
2 Редагування індивідуального предмету
- працівник деканату має мати змогу в окремому модальному вікні
відредагувати дані про саму дисципліну (назву, кількість годин і кредитів,
контроль знань), натиснувши збоку предмету відповідну кнопку;
- працівник деканату має мати змогу в окремому модальному вікні
відредагувати дані про академічну мобільність (заклад навчання, дата та номер
сертифікату, дати початку та кінця навчання) лише для одного обраного
предмета одного вибраного студента;
- працівник деканату має мати змогу в окремому модальному вікні
відредагувати вид обраних індивідуальних предметів для вибраних студентів.
3 Видалення індивідуальних предметів
- працівник деканату повинен мати змогу виділити студентів і їх
індивідуальні предмети. Після цього він може натиснути на кнопку «Видалити»;
26
ЧДТУ 262259.020 ПЗ
- при натисненні кнопки «Видалити» перед користувачем має
висвітлитись модальне вікно, де будуть відображені список студентів і список
предметів що будуть видалені і цих студентів.
4 Розпізнавання додатку до диплому
- працівник деканату повинен обрати лише одного студента, і має
висвітлитись кнопка «Розпізнати додаток».;
- після натиснення кнопки «Розпізнати додаток» повинне висвітлитись
модальне вікно з елементом перетягування або завантаження зображення, і
таблицею з предметами, в нижній панелі має бути випадаючий список з групами,
з чиїм навчальним планом буде порівнюватись розпізнані предмети, а також
кнопки «Порівняти», «Розпізнати» та «Скасувати»;
- працівник деканату повинен мати змогу перетягнути або завантажити з
локального пристрою. Після завантаження зображення, користувач має змогу
натиснути кнопку «Розпізнати», і в таблиці справа будуть відображені предмети,
розпізнані за допомогою нейромережі. При завантаженні ще зображень і їх
розпізнаванню, розпізнані предмети порівнюються з отриманими раніше,
дублікати відсіюються, а решта додається до таблиці;
- після розпізнавання всіх зображення, працівник деканату повинен мати
змогу перемкнутись за допомогою кнопки на режим редагування, і власноруч
відредагувати дані розпізнаних предметів. Після перевірки предметів,
користувач повинен мати змогу обрати всі, або декілька розпізнаних предметів,
і натиснути кнопку «Розпізнати»;
- при натисненні кнопки «Розпізнати», вибрані предмети і група обрана
для порівняння повинні бути відправлені на сервіс з векторною базою даних, де
їх порівняють з предметами з навчального плану обраної групи. Після
розпізнавання, в модальному вікні повинні з’явитись 2 стовпці таблиць. Зліва
будуть таблиці з одним предметом з навчального плану. Справа напроти неї
повинна бути таблиця з подібними предметами, розпізнаними семантично в
векторній базі даних, де предмети що повністю відповідають вимогам
перезарахування будуть позначені чорним шрифтом, а ті що або не зовсім
27
ЧДТУ 262259.020 ПЗ
відповідають вимогам – оранжевим. Якщо обрати предмет з таблиці справа (з
навчального плану), цей предмет буде призначено як академічна різниця, а якщо
буде обрано предмета з таблиці зліва (розпізнані предмети), він буде
призначений як перезарахування. Вибрані розпізнані предмети мають
автоматично блокуватись в інших таблицях, щоб запобігти повторному
зарахуванню одного предмету. Невикористані предмети повинні бути
відображені внизу в списку, з можливістю перезарахувати їх як вибіркові
дисципліни;
- після вибору предметів для перезарахування, працівник деканату
повинен мати змогу у верхній панелі модального вікна переглянути кількість
кредитів призначених як академічна різниця і як перезарахування окремо;
- у випадку потреби в редагуванні розпізнаного предмету, працівник
деканату повинен мати змогу перемкнутись на режим редагування, і
підкорегувати неточності в даних;
- після перевірки предметів, працівник деканату може натиснути кнопку
«Перезарахувати», і обрані предмети мають бути призначені студенту.
Вимоги замовника визначаються кінцевими користувачами системи
(працівниками деканату ЧДТУ) і включають функціональні та нефункціональні
вммоги, що мають забезпечити всі їх потреби:
- інтерфейс підсистеми повинен бути інтуїтивно зрозумілим і простим у
використанні;
- підсистема повинна давати можливість зручно та ефективно виконувати
всі дії, вказані в детальних вимогах.
Вимоги розробника визначаються розробником і включають технічні
аспекти реалізації підсистеми:
- клієнтська частина підсистеми повинна бути розроблена за допомогою
фреймворку Angular та мови програмування TypeScript;
- підсистема має мати налагоджену систему для взаємодії всіх
компонентів підсистеми між собою, а також з іншими компонентами системи
загалом;
28
ЧДТУ 262259.020 ПЗ
- підсистема повинна підтримувати масштабованість, що в подальшому
дозволить додати нові компоненти в підсистему.
Функціональні та нефункціональні вимоги
Функціональні вимоги описують специфічні функції, які підсистема
повинна виконувати:
- призначення індивідуальних предметів вибраним студентам;
- додавання нових індивідуальних предметів;
- редагування та видалення існуючих індивідуальних предметів;
- розпізнавання додатків до диплому, порівняння отриманих предметів з
навчальним планом і їх перезарахування.
Нефункціональні вимоги включають характеристики системи:
- продуктивність: підсистема має працювати стабільно, обробляються всі
індивідуальні предмети і їх дані без втрат та затримок;
- безпека даних: працівники деканату можуть працювати виключно з
даними свого факультету, решта користувачів доступ до цього функціоналу не
мають;
- зручність використання: інтерфейс має бути інтуїтивно зрозумілим для
користувача, і надавати весь необхідний функціонал для конкретного завдання
на одній сторінці.
2.2.2. Формування вимог за допомогою діаграми прецедентів
Діаграма прецедентів демонструє взаємодію головного актора (працівника
деканату ЧДТУ) з підсистемою. На цій діаграмі зображені всі основні дії
користувача, а також їх розгалуження (рисунок 2.2).
Згідно діаграми можна спостерігати, що в працівника деканату буде 4
основні дії:
- призначення індивідуальних предметів студентам;
- редагування індивідуальних предметів студентів;
- видалення індивідуальних предметів студентів;
- розпізнавання та порівняння предметів з додатку до диплому і їх
перезарахування.
29
ЧДТУ 262259.020 ПЗ
Рисунок 2.2 - Діаграма прецедентів підсистеми для роботи з індивідуальними
предметами студентів
Для покращення відображення варіантів використання при редагуванні та
розпізнаванні предметів було створено ще дві діаграми прецедентів для
редагування (рисунок 2.3) та розпізнавання (рисунок 2.4) предметів.
30
ЧДТУ 262259.020 ПЗ
Рисунок 2.3 – Діаграма прецедентів при редагуванні індивідуального предмету
31
ЧДТУ 262259.020 ПЗ
Рисунок 2.4 - Діаграма прецедентів при розпізнаванні предметів з додатку до
диплому
32
ЧДТУ 262259.020 ПЗ
2.3. Проектування логічної структури програмного комплексу
У цьому підрозділі буде детально розглянуто проектування логічної
структури програмного забезпечення клієнтської частини підсистеми для роботи
з індивідуальними предметами. Спочатку буде представлені діаграми класів, які
відображатимуть взаємодію між основними компонентами підсистеми, їх
атрибути та методи. Це надасть більш точне уявлення про структуру підсистеми
і її функціонал.
У вигляді класів відображені сутності, що використовуватись в підсистемі
(предмети, індивідуальні предмети, контроль знань, і т.д.) і класи компонентів,
в яких буде прописана бізнес-логіка для роботи з предметами.
2.3.1. Діаграми класів
Діаграма класів демонструє самі класи, їх вміст (поля і атрибути), а також
їх зв’язки один між одним і взаємодію. Ця діаграма допомагає чітко продумати
на змоделювати структуру проекту, особливо для проектів з компонентно-
орієнтованою архітектурою та об’єктно-орієнтованим підходом програмування.
У діаграмах класів без атрибутів (рисунок 2.5) та з атрибутами (рисунок
2.6) відображені наступні класи:
- CourseForStudent: сутність індивідуального предмету. Міститиме в собі
дані про самий предмет (дисципліну), ідентифікатор студента якому належатиме
предмет, тип контролю знань, вид предмету, а також дані академічно мобільності
(попередній заклад навчання, дата і номер сертифікату, дати початку та кінця
навчання);
- CourseForStudentWrite: допоміжна сутність, що необхідна для додавання
нового індивідуального предмету і призначення його. Містить в собі повний
набір атрибутів CourseForStudent, окрім ідентифікатора, оскільки він
автоматично буде назначений в базі даних;
- CourseForStudentUpdateHolder: допоміжна сутність, що необхідна для
редагування дисципліни існуючого індивідуального предмету. Містить в собі
старий ідентифікатор предмету, а також дисципліну;
33
ЧДТУ 262259.020 ПЗ
- EducationInstitution: сутність попереднього закладу навчання. Містить в
собі 4 поля з назвою закладу та місцем положенням на українській та англійській
мовах;
- EducationInstitutionWrite: сутність, що необхідна для додавання нового
закладу навчання. Містить в собі всі атрибути EducationInstitution, окрім
ідентифікатора;
- MatchedCourse: сутність розпізнаного предмету з додатку до диплома.
Містить в собі атрибути назви дисципліни, кількість годин та кредитів, тип
контролю знань і кількість балів;
- RecognisedCourse: сутність, що зберігає в собі об’єкт предмету з
навчального плану, і масив об’єктів MatchedCourse, котрі після порівняння
найбільше підходять для перезарахування предмету;
- CourseForStudentComponent: компонент клієнтської частини
підсистеми, що відповідає за отримання і відображення списків студентів та їх
предметів, а також їх виділення і вибір дії щодо них;
- CourseForStudentEditDialogComponent: компонент, призначений для
редагування даних дисципліни в індивідуальному предметів;
- ConfirmSelectedComponent: компонент, що призначений для
підтвердження дії у разі призначення чи видалення предметів у студентів.
Відображає список студентів і їх вибрані предмети. У випадку якщо
призначається предмет з видом “Академічна мобільність”, вікно має додаткові
поля введення інформації;
- CourseTypeEditComponent: компонент, що призначений для зміни виду
обраних індивідуальних предметів;
- AcademicMobilityDataEditComponent: компонент, що призначений для
редагування даних академічної мобільності вибраних предметів;
- ExtractFromDiplomaSupplementComponent: компонент, що призначений
для розпізнавання предметів з додатку для диплому, їх порівняння з предметами
навчального плану, і перезарахування у випадку співпадіння;
34
ЧДТУ 262259.020 ПЗ
Рисунок 2.5 – Діаграма класів без атрибутів та методів для програмного
забезпечення підсистеми для роботи з індивідуальними предметами студентів
35
ЧДТУ 262259.020 ПЗ
Рисунок 2.6 - Діаграма класів для програмного забезпечення підсистеми для
роботи з індивідуальними предметами студентів
2.3.2. Діаграми пакетів
Діаграма пакетів демонструє логічну структуру підсистеми, спираючись
на згрупування класів та сервісів в функціональні пакети, що відповідають за
36
ЧДТУ 262259.020 ПЗ
різні аспекти роботи системи. Кожен пакет відповідає за власну логічну
функціональну область (рисунок 2.7).
Рисунок 2.7 - Діаграма пакетів для програмного забезпечення підсистеми для
роботи з індивідуальними предметами студентів
1 CourseForStudent Package
- Базовий пакет підсистеми, що містить ключові сутності (студенти і їх
індивідуальні предмети), описані в попередньому розділі. Пакет відповідає за
отримання списків студентів та індивідуальних предметів з бази даних, а також
для вибору подальших дій з індивідуальними предмети.
2 CourseForStudent Add Package
37
ЧДТУ 262259.020 ПЗ
- Пакет підсистеми, що відповідає за додавання (призначення)
індивідуальних предметів студентам. Пакет отримує списки предметів та
студентів з базового пакету, формує індивідуальні предмети і відправляє запит
на їх призначення на серверну частину.
3 CourseForStudent Edit Package
- Пакет підсистеми, що відповідає за редагування індивідуальних
предметів студента. Пакет складається з 3 модальних вікон, в кожному з яких
відбувається одна відповідна дія редагування.
4 Course Edit Modal
- Пакет підсистеми, що відповідає за зміну даних дисципліни в середині
індивідуального предмету. Приймає в себе дані лише одного предмета з базового
пакету, над яким і буде відбуватись дія редагування.
5 CourseType Edit Modal
- Пакет підсистеми, що відповідає за зміну виду предмету. З базового
пакету отримує списки обраних студентів та їх індивідуальних предметів, після
чого відправляє список предметів і їх новий вид на серверну частину для їх зміни.
6 CourseForStudent Academic Mobility Data Edit Modal
- Пакет підсистеми, що відповідає за редагування даних академічної
мобільності. З базового пакету отримує списки обраних студентів та їх
індивідуальних предметів з видом «Академічна мобільність», записує зміни
даних і відправляє запит на їх зміну на серверну частину.
7 CourseForStudent Delete Package
- Пакет підсистеми, що відповідає за видалення предметів. Приймає в
себе і відображає списки вибраних студентів та предметів з базового пакету, і
відправляє запит на серверну частину
8 CourseForStudent Recognise Package
- Пакет підсистеми, що відповідає за розпізнавання предметів з додатків
до диплому і їх порівняння з предметами навчального плану. Зберігає в собі
масивиMatchedCourse і RecognisedCourse, і приймає з базового пакету вибраного
студента і його спеціальність.
38
ЧДТУ 262259.020 ПЗ
9 Recognise Course From Supplement Modal
- Пакет підсистеми, в якому відбувається розпізнавання предметів з
зображення додатку до диплому, і їх запис в масив MatchedCourse.
10 Compare Course From Supplement Modal
- Пакет підсистеми, в якому після розпізнавання предметів і їх порівняння
з навчальним планом можна буде перезарахувати предмети з додатку до
диплому.
2.4. Архітектурне проектування
У цьому підрозділі розглядається архітектура програмного забезпечення
клієнтської частини підсистеми для роботи з індивідуальними предметами
студентів. Головною метою архітектурного проектування є створення структури
проекту таким чином, щоб забезпечити в майбутньому її масштабованість та
можливість для подальшого розширення функціоналу.
Оскільки проект буде мати компонентно-орієнтовану архітектуру, було
вирішено при архітектурному проектуванні використовувати принцип
розділення відповідальностей (Seperation of Concerns), коли кожен компонент
підсистеми відповідатиме лише за один чіткий функціонал.
Для наочної демонстрації компонентної архітектури буде використана
діаграма компонентів, яка відображатиме основні компоненти підсистеми, а
також їх взаємодію і особливості.
Також у межах архітектурного проектування представлено діаграму
розгортання, яка демонструватиме розміщення підсистеми у середовищі
виконання. Клієнтська частина функціонуватиме в веб-браузері користувача, і
буде взаємодіяти з серверною частиною завдяки REST API запитам.
2.4.1. Діаграма компонентів
Діаграма компонентів в UML використовується для відображення
структури фізичної реалізації системи. Вона показує різні компоненти системи,
їх взаємозв'язки та залежності (рисунок 2.8).
39
ЧДТУ 262259.020 ПЗ
Рисунок 2.8 - Діаграма компонентів для програмного забезпечення
підсистеми роботи з індивідуальними предметами
Діаграма містить наступні компоненти:
1 CourseForStudentComponent: компонент, що відповідає за
відображення управління списками студентів, їх індивідуальних предметів у
клієнтській частині підсистеми, забезпечує вибір студентів, перегляд пов’язаних
з ними предметів і вибір дії з ними;
2 ConfirmSelectedComponent: компонент, що реалізує логіку
підтвердження вибору працівником деканату студентів та предметів перед їх
призначенням або видаленням;
3 CourseForStudentEditDialogComponent: компонент, що представляє
модальне діалогове вікно для редагування дисципліни індивідуального предмету
40
ЧДТУ 262259.020 ПЗ
студента, забезпечує зміну параметрів предмету та надсилання змінених даних
до сервісу для збереження;
4 CourseTypeEditCompoinent: компонент, що відповідає за зміну виду
індивідуального предмету, приймає списки предметів і студентів для
редагування та передає оновлені типи предметів на сервісний рівень;
5 AcademicMobillityDataEditComponent: компонент, що забезпечує
введення та редагування даних академічної мобільності для індивідуальних
предметів студентів, формує оновлені дані та передає їх до сервісу для
подальшого збереження або обробки;
6 ExtractFromDiplomaSupplementComponent: компонент, що відповідає
за ініціацію процесу розпізнавання предметів із додатку до диплому, формує
запити з відповідними списками студентів і предметів та передає їх до сервісного
рівня для подальшого аналізу;
7 CourseForStudentService: сервісний компонент клієнтської частини,
що реалізує взаємодію між інтерфейсними компонентами та серверною
частиною системи, забезпечує надсилання запитів на додавання, редагування,
видалення індивідуальних предметів, а також обробку результатів розпізнавання
та порівняння даних;
8 Серверна частина: компонент, що забезпечує обробку запитів від
клієнтської частини підсистеми, виконує бізнес-логіку збереження та обробки
індивідуальних предметів студентів, а також координує взаємодію з зовнішніми
сервісами;
9 Сервіс інтелектуалізованого порівняння імен: компонент, що
реалізує алгоритми інтелектуального зіставлення назв предметів, отриманих із
додатку до диплому, з предметами навчального плану, та повертає результати
розпізнавання і порівняння серверній частині системи.
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Діаграма розгортання показує фізичне розміщення програмних
компонентів
41
ЧДТУ 262259.020 ПЗ
на апаратних вузлах у системі (рисунок 2.9). Вона відображає взаємодію між
компонентами системи, а також користувача з системою.
Рисунок 2.9 - Діаграма розгортання для програмного забезпечення підсистеми
для роботи з індивідуальними предметами
Основні компоненти підсистеми:
- веб-браузер;
- клієнтська частина підсистеми;
42
ЧДТУ 262259.020 ПЗ
- серверна частина сервера;
- серверна частина сервісу інтелектуалізованого порівняння;
- REST API сервера;
- REST API сервісу інтелектуалізованого порівняння;
- база даних.
Підсистема складається з 4 вузлів:
- клієнтський пристрій: вузол, де користувач (працівник деканату)
взаємодіє з підсистемою. Містить в собі клієнтську частину та веб-браузер (як
інструмент для відображення клієнтською частини для користувача);
- сервер: вузол що приймає запити від клієнтського пристрою, виконує
частину бізнес-логіки, а також взаємодіє і виконує операції з базою даних. Також
приймає зображення, відправляє його в сервіс інтелектуалізованого порівняння
імен, і відправляє результати на клієнтський пристрій;
- сервіс інтелектуалізованого порівняння імен: вузол, що приймає
зображення (додаток до диплому або його частину), зчитує дисципліни, а також
порівнює їх з дисциплінами з навчального плану;
- база даних: вузол, що зберігає в собі всі дані (студентів, групи, предмети
і тп.).
2.5. Моделювання поведінки системи
У цьому підрозділі розглядатимуться моделі поведінки функціональної
частини клієнтської частини підсистеми для роботи з індивідуальними
предметами. Головною метою моделювання поведінки системи є відображення
можливих сценаріїв взаємодії працівника деканату з підсистемою, щоб
визначити чітку послідовність дій, їх результати та процеси що відбуваються, і
забезпечиии узгодженість між клієнтською системою та сервером.
Для демонстрації послідовності дій користувача та системи буде
використано діаграму діяльності. Загалом буде представлено 3 діаграми
послідовності: перша буде показувати дії для входу підсистему, друга – основні
дії в залежності від кількості обраних студентів, третя – редагування даних.
43
ЧДТУ 262259.020 ПЗ
Для відображення взаємодії між компонентами в залежності від дій
користувача буде представлена діаграма послідовності. Вона відображатиме
взаємодію клієнтської, серверної частини, сервісу інтелектуалізованого
порівняння імен та бази даних у вигляді впорядкованого обміну
повідомленнями.
Для ілюстрації структурних зв’язків між компонентами та їх
особливостями буде використана діаграма комунікації.
Для опису можливих станів підсистеми буде представлено діаграму
скінченного автомату. Загалом буде представлено 4 діаграми: діаграма
скінченного автомату призначення, видалення, редагування та розпізнавання.
2.5.1. Діаграма діяльності
Діаграма діяльності використовується для моделювання поведінки
підсистеми, відображаючи послідовність дій користувача від початкового до
кінцевого стану. Діаграма наочно демонструє основні дії при вході в систему
(рисунок 2.10), при виборі кількості студентів і наступних дій, наприклад, не
вибравши жодного студента, можна буде створити, а вибравши по крайній мірі
одного, можна буде призначати, видаляти, редагувати предмети студента
(рисунок 2.11), а також дії при редагуванні даних (рисунок 2.12).
Дії під час входу в систему:
1 працівник деканату відкриває веб-застосунок;
2 система перевіряє стан автентифікації користувача:
2.1 якщо користувач вже авторизований: система надає доступ до
функціоналу;
2.2 якщо користувач не авторизований: система виконує перехід на
сторінку входу;
3 працівник деканату виконує вхід у систему;
4 система перевіряє облікові дані та надає доступ до системи;
5 працівник деканату відкриває вкладку “предмети для студентів”;
6 працівник деканату вибирає студентів з якими буде працювати
44
ЧДТУ 262259.020 ПЗ
Рисунок 2.10 - Діаграма діяльності під час входу в підсистему для програмного
забезпечення підсистеми для роботи з індивідуальними предметами
45
ЧДТУ 262259.020 ПЗ
Дії під час вибору студентів:
1 Користувач обирає студентів у системі;
2 Система перевіряє наявність обраних студентів:
2.1 Якщо студентів обрано: система дозволяє обирати предмети та дій
над ними відносно студентів;
2.2 Якщо студентів не обрано: система дозволяє створити новий
предмет на основі вже існуючої дисципліни;
3 Система перевіряє наявність обраних предметів:
3.1 Якщо предмети вибрано: працівник деканату може їх додавати
студенту, видаляти або редагувати їх;
3.2 Якщо не вибраного жодного предмету: працівник деканату не має
доступу до функціоналу зв’язаного з роботою з ними, і може лише створити
новий предмет на основі вже існуючої дисципліни;
4 У разі якщо вибрано лише одного студента, і при цьому не було обрано
жодного предмету, працівник деканату може:
4.1 Отримати відомість для цього студента;
4.2 Розпізнати додаток до диплому за допомогою нейромережі і
перезарахувати йому предмети;
5 Система виконує обрану операцію;
6 Працівник деканату повертається до списку студентів для подальшої
роботи чи завершення сеансу, або редагування даних.
Дії під час редагування даних:
1 Працівник деканату перебуває на етапі редагування даних;
2 Працівник деканату обирає одну з опцій редагування даних:
2.1 Редагувати дисципліну (назва предмету, кредити, форма
контролю);
2.2 Редагувати предмет (загальні атрибути);
2.3 Редагувати вид предмету;
2.4 Редагувати дані академічної мобільності (якщо вид предмету –
Академічна мобільність);
46
ЧДТУ 262259.020 ПЗ
3 Працівник деканату виконує відповідні зміни і зберігає їх;
4 Працівник деканату повертається до списку студентів для подальшої
роботи чи завершення сеансу.
Рисунок 2.11 - Діаграма діяльності під час вибору студентів для програмного
забезпечення підсистеми для роботи з індивідуальними предметами
47
ЧДТУ 262259.020 ПЗ
Рисунок 2.12 - Діаграма діяльності під час редагування даних для програмного
забезпечення підсистеми для роботи з індивідуальними предметами
2.5.2. Діаграма послідовності
Діаграма послідовності відображає взаємодію між об'єктами системи в
певній послідовності (рисунок 2.13). Вона у форматі повідомлень відображає
порядок передачі повідомлень між об’єктами. В контексті інформаційної
системи діаграма демонструє процеси роботи з індивідуальними предметами
(від вибору студентів і предметів, до їх призначення та розпізнавання за
допомогою сервісу). Вона допоможе проаналізувати логіку основних операцій
та їх часові залежності.
48
ЧДТУ 262259.020 ПЗ
Рисунок 2.13 - Діаграма послідовності для програмного забезпечення
підсистеми для роботи з індивідуальними предметами
49
ЧДТУ 262259.020 ПЗ
Об’єкти діаграми послідовності:
- працівник деканату - безпосередній користувач, що працює з
підсистемою;
- клієнтська частина (Angular) – об’єкт, що надає користувачу графічний
інтерфейс і функціонал для роботи з підсистемою;
- серверна частина (Spring Boot) - об’єкт, що виконує частину бізнес-
логіки підсистеми, а також працює з базою даних;
- база даних (PostgreSQL) – об’єкт, що містить в собі дані, що
використовуються в підсистемі;
- сервіс інтелектуального порівняння предметів – об’єкт, що приймає
зображення, розпізнає предмети і порівнює їх з предмети з навчального плану.
2.5.3. Діаграма комунікації
Діаграма комунікації описує поведінку підсистеми як взаємодію об'єктів,
показуючи відносини між об'єктами та використовуючи нумерацію для
представлення послідовності повідомлень (рисунок 2.14).
Опис взаємодії в підсистемі:
1 Логін в систему: користувач вказує облікові дані для входу в підсистему.
2 Завантаження інтерфейсу: після успішного входу завантажується веб-
інтерфейс підсистеми і виконується перехід до компоненту для роботи з
індивідуальними предметами студентів.
3 Виклик сервісу REST API: в середині компонента завантажується сервіс,
що відправляє запити на серверну частину.
4 Перший запит даних до серверної частини: відбувається GET-запит на
серверну частину щоб дістати список груп та студентів вибраної групи.
5 Відповідь сервера: серверна частина дістає з бази даних списки груп і
студентів вибраної групи.
6 Обробка відповіді на клієнтській стороні: списків груп і студентів
обробляється і відображаються у веб-інтерфейсі підсистеми, надаючи доступ до
функціоналу підсистеми.
50
ЧДТУ 262259.020 ПЗ
7 Призначення предметів студентам: у веб-інтерфейсі працівник деканату
обирає студентів, а також предмети і їх вид.
8 Відправлення предметів та студентів до сервісу: після підтвердження дії,
вибрані предмети та студенти відправляються на сервіс.
Рисунок 2.14 - Діаграма комунікації для програмного забезпечення підсистеми
для роботи з індивідуальними предметами
51
ЧДТУ 262259.020 ПЗ
9 Відправлення предметів та студентів до серверної частини: сервіс
формує POST-запит і відправляє його на серверну частину.
10 Відповідь сервера: після надходження запиту, серверна частина записує
в базі даних нові призначенні предметі, і після операції відправляє повідомлення,
що включає в себе HTTP-відповідь та кількість успішно призначених предметів;
11 Обробка відповіді на клієнтській частині: оновлення даних у веб-
інтерфейсі, відображення нових призначених предметів. У разі помилки
відображення попередження, і виведення в консоль помилки.
12 Редагування вибраного індивідуального предмету: у веб-інтерфейсі
працівник деканату натискає на кнопку “Редагувати” біля індивідуального
предмету, і в модальному вікні редагує дані індивідуального предмету.
13 Відправлення відредаговано предмету до сервісу: після підтвердження
дії, відредагований предмет відправляється на сервіс.
14 Відправлення відредагованого предмету до серверної частини: сервіс
формує PUT-запит і відправляє його на серверну частину.
15 Відповідь сервера: після надходження запиту, серверна частину редагує
існуючий запис в базі даних, переписавши старі дані на нові, і після операції
відправляє повідомлення, що включає в себе HTTP-відповідь.
16 Обробка відповіді на клієнтській частині: оновлення даних про предмет
і їх відображення. У разі помилки відображення попередження, і виведення в
консоль помилки.
17 Редагування виду індивідуального предмету: у веб-інтерфейсі
працівник деканату обирає індивідуальні предмети, і натискає на кнопку
“Редагувати вид”. Далі в модальному вікні вибирає на який вид хоче змінити
вибрані предмети.
18 Відправлення предметів і нового виду до сервісу: після підтвердження
дії, список предметів і новий вид відправляється на сервіс.
19 Відправлення предметів і нового виду до серверної частини: сервіс
формує PUT-запит і відправляє його на серверну частину.
20 Відповідь сервера: після надходження запиту, сервер змінює поле виду
52
ЧДТУ 262259.020 ПЗ
для індивідульних предметів в базі даних, і після операції відправляє
повідомлення, що включає в себе HTTP-відповідь.
21 Обробка відповіді на клієнтській частині: оновлення даних про вид
відредагованих предметів і їх відображення. У разі помилки відображення
попередження, і виведення в консоль помилки.
22 Редагування даних академічної мобільності для індивідуальних
предметів: у веб-інтерфейсі працівник деканату вибирає предметів лише виду
“Академічна мобільність”, і натискає на кнопку “Редагувати
академмобільність”. Далі в модальному вікні редагує потрібні поля.
23 Відправлення відредагованих даних академічної мобільності до
сервісу: після підтвердження дії, відредаговані дані відправляються до сервісу.
24 Відправлення відредагованих даних академічної мобільності до
серверної частини: сервіс формує PUT-запит і відправляє його на серверну
частину.
25 Відповідь сервера: після надходження запиту, сервер змінює відповідні
поля в базі даних, і після операції відправляє повідомлення, що включає в себе
HTTP-відповідь.
26 Обробка відповіді на клієнтській частині: оновлення даних про
академічну мобільність предметів і їх відображення. У разі помилки
відображення попередження, і виведення в консоль помилки.
27 Видалення індивідуальних предметів: у веб-інтерфейсі працівник
деканату вибирає індивідуальні предмети які він хоче видалити і натискає на
кнопку “Видалити”.
28 Відправлення видалених індивідуальних предметів до сервісу: після
підтвердження дії, список предметів для видалення відправляється до сервіс.
29 Відправлення видалених індивідуальних предметів до серверної
частини: сервіс формує DELETE-запит і відправляє його на серверну частину.
30 Відповідь сервера: після надходження запиту, сервер видаляє рядки
(індивідуальні предмети) в базі даних, і після операції відправляє повідомлення,
що включає в себе HTTP-відповідь.
53
ЧДТУ 262259.020 ПЗ
31 Обробка відповіді на клієнтській частині: оновлення даних про
індивідуальні предмети студентів. У разі помилки відображення попередження,
і виведення в консоль помилки.
32 Формування відомості з академічною різницею: у веб-інтерфейсі
працівник деканату обирає студентів, і натискає кнопку “Відомість з АР”.
33 Відправлення списку студентів до сервісу: після натиснення кнопки,
список студентів відправляється до сервісу.
34 Відправлення списку студентів до серверної частини: сервіс формує
запит і відправляє його до серверної частини.
35 Відповідь сервера: після надходження запиту, сервер формує відомість
з вибраних студентів і відправляє файл.
36 Обробка відповіді на клієнтській частині: при надходженні файлу,
відбувається його завантаження.
37 Розпізнавання предметів з додатку до диплома: у веб-інтерфейсі
працівник деканату обирає одного студента і натискає на кнопку “Розпізнати
додаток”. У модальному вікні завантажує зображення.
38 Відправлення зображення до сервісу: після підтвердження
розпізнавання, зображення передається до сервісу.
39 Відправлення зображення до серверної частини: сервіс формує POST-
запит і відправляє його до серверної частини.
40 Відправлення зображення до сервісу розпізнавання: сервер формує
запит і відправляє зображення до сервісу розпізнавання.
41 Відповідь сервісу розпізнавання: сервіс розпізнає предмети із
зображення і відправляє їх список до серверної частини.
42 Відповідь сервера: після надходження запиту від сервісу розпізнавання,
відправляє предмети до клієнтської частини.
43 Обробка відповіді на клієнтській частині: при надходженні списку
предметів, з’являється можливість їх редагування та призначення студентові.
2.5.4. Діаграма скінченного автомату
54
ЧДТУ 262259.020 ПЗ
Діаграма скінченного автомату (діаграма станів) використовується для
моделювання поведінки об'єктів, що змінюють свій стан у відповідь на події.
Вона відображає всім можливі стани, в яких може перебувати програма (у
даному випадку – підсистема для роботи з індивідуальними предметами). Для
підсистеми було зроблено 4 діаграми скінченного автомату: призначення
(рисунок 2.15), редагування (рисунок 2.16), видалення (рисунок 2.17) та
розпізнавання (рисунок 2.18).
Рисунок 2.15 - Діаграма скінченного автомату призначення для програмного
забезпечення підсистеми для роботи з індивідуальними предметами
55
ЧДТУ 262259.020 ПЗ
Основні стани (рисунок 2.15):
1 Користувач не авторизований: початковий стан при відкритті веб-
інтерфейсу підсистеми.
2 Користувач авторизований: стан, коли користувач ввів свої облікові дані
і успішно виконав вхід в підсистему.
3 Веб-інтерфейс підсистеми відкрито: стан після успішної авторизації
користувача, коли користувачу відкривається доступ до функціоналу
підсистеми.
4 Студенти не вибрані: стан, коли ще не обрані студенти, яким будуть
призначені індивідуальні предмети.
5 Предмети не вибрані: стан, коли вже обрані студенти, проте не вибрані
предмети, котрі будуть їм призначені.
6 Вид предметів не визначено: стан, коли обрані студенти і предмети які
їм будуть призначені, проте не визначено їх вид (академічна різниця, академічна
мобільність чи перезарахування).
7 Очікування підтвердження дії: перехідний стан, де в залежності від виду
предметів наступним станом стане або їх призначення, або заповнення
додаткових даних.
8 Дані академічної мобільності не введено: стан, що настає лише у
випадку, коли вид предметів академічна мобільність, і є потреба у введені даних
академічної мобільності.
9 Предмети призначено: стан, що підтверджує призначення предметів, і
після якого настає кінцевий стан і програму завершено.
Основні стани (рисунок 2.16):
1 Користувач не авторизований: початковий стан при відкритті веб-
інтерфейсу підсистеми.
2 Користувач авторизований: стан, коли користувач ввів свої облікові дані
і успішно виконав вхід в підсистему.
56
ЧДТУ 262259.020 ПЗ
3 Веб-інтерфейс підсистеми відкрито: стан після успішної авторизації
користувача, коли користувачу відкривається доступ до функціоналу
підсистеми.
Рисунок 2.16 - Діаграма скінченного автомату редагування для програмного
забезпечення підсистеми для роботи з індивідуальними предметами
57
ЧДТУ 262259.020 ПЗ
4 Студенти не вибрані: стан, коли ще не обрані студенти, яким будуть
відредаговані індивідуальні предмети.
5 Предмети не вибрані: стан, коли вже обрані студенти, проте не вибрані
предмети, котрі будуть їм редагувати.
6 Модальне вікно відкрите: стан, який буде виконуватись незалежно від
подій попереднього стану, коли модальне вікно відкрите і готове до роботи.
7 Предмет не редагований: стан, що настає за умови якщо було натиснуто
кнопка редагування самого предмета і самий предмет ще не редагований.
8 Новий вид предметів не обрано: стан, що настає за умови, коли були
обрані предмети і було натиснуто на кнопку “редагувати вид”.
9 Дані про академічну мобільність предметів не редаговано: стан, що
настає за умови, що обрані предмети мають вид академічна мобільність, і було
натиснуто кнопку “редагувати академічну мобільність”.
10 Очікування підтвердження дії: перехідний стан, що настає за умови
коли редагування завершене, але дія ще не підтверджена.
11 Предмети відредаговано: стан, що підтверджує успішне редагування
предметів, і після якого настає кінцевий стан і програму завершено.
Рисунок 2.17 - Діаграма скінченного автомату видалення для програмного
забезпечення підсистеми для роботи з індивідуальними предметами
58
ЧДТУ 262259.020 ПЗ
Основні стани (рисунок 2.17):
1 Користувач не авторизований: початковий стан при відкритті веб-
інтерфейсу підсистеми.
2 Користувач авторизований: стан, коли користувач ввів свої облікові дані
і успішно виконав вхід в підсистему.
3 Веб-інтерфейс підсистеми відкрито: стан після успішної авторизації
користувача, коли користувачу відкривається доступ до функціоналу
підсистеми.
4 Студенти не вибрані: стан, коли ще не обрані студенти, яким будуть
видалені індивідуальні предмети.
5 Предмети не вибрані: стан, коли вже обрані студенти, проте не вибрані
предмети, котрі будуть їм видаляти.
6 Очікування підтвердження дії: перехідний стан, що настає за умови коли
обрані предмети не видалення ,але дія ще не підтверджена.
7 Предмети не видалено: стан, що настає за умови, коли дія підтверджена,
але ще не було відправлено запит на сервер.
8 Предмети видалено: стан, що підтверджує видалення предметів, і після
якого настає кінцевий стан і програму завершено.
Основні стани (рисунок 2.18):
1 Користувач не авторизований: початковий стан при відкритті веб-
інтерфейсу підсистеми.
2 Користувач авторизований: стан, коли користувач ввів свої облікові дані
і успішно виконав вхід в підсистему.
3 Веб-інтерфейс підсистеми відкрито: стан після успішної авторизації
користувача, коли користувачу відкривається доступ до функціоналу
підсистеми.
4 Студента не вибрано: стан, коли ще не обрано студента, якому будуть
розпізнавати предмети з додатку до диплому.
5 Модальне вікно відкрито: стан, що настає за умови, коли обрано
студента і натиснуто на кнопку “Розпізнати”.
59
ЧДТУ 262259.020 ПЗ
Рисунок 2.18 - Діаграма скінченного автомату розпізнавання для програмного
забезпечення підсистеми для роботи з індивідуальними предметами
6 Зображення для розпізнавання не завантажено: стан, коли зображення
ще не завантажене для розпізнавання.
7 Предмети розпізнано: стан, що настає за умови, коли було завантажено
зображення і натиснуто кнопку “Розпізнати”. Також з цього стану можливе
повернення до попереднього стану за умови, якщо буде розпізнаватись декілька
зображень за сесію.
8 Очікування підтвердження дії: стан, що настає за умови, розпізнавання
завершене.
9 Порівняння предметів з навчальним планом: стан, що настає за умови
що є розпізнані предмети і натиснуто кнопку “Порівняти”.
10 Предмети для перезарахування не вибрано: стан, що настає за умови
коли розпізнані предмети порівняні з навчальним планом.
60
ЧДТУ 262259.020 ПЗ
11 Очікування підтвердження дії: перехідний стан, що настає за умови
коли обрано предмети для перезарахування, але дія ще не підтверджена.
12 Предмети зараховано: стан, що підтверджує розпізнавання та
перезарахування предметів, і після якого настає кінцевий стан і програму
завершено.
61
ЧДТУ 262259.020 ПЗ
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ
У другому розділі було проведено проектування програмного
забезпечення підсистеми для роботи з індивідуальними предметами студентів.
На основі досліджень з попереднього розділу, було проведено моделювання
предметної області, робочої області, було сформовано та проаналізовано вимоги,
а також для наочної демонстрації було розроблено діаграми.
При моделюванні предметної області було розглянуто концептуальну та
логічну моделі підсистеми. Також було виведено основні об’єкти предметної
області та сформовано словник. Також було сформовано робочу область
підсистеми, що дозволило визначити основні сутності та функціональні модулі.
Далі було сформовано та проаналізовано вимоги до програмного
забезпечення. Загалом були сформовані первинні вимоги, детальні вимоги,
вимоги замовника та розробника, а також функціональні та нефункціональні
вимоги. Для зручного графічного представлення вимог було сформовано
діаграми прецедентів, загалом для підсистеми, і окремо для редагування та
розпізнавання.
Для проектування логічної структури програмного забезпечення було
визначено діаграми класи та пакетів. Вони допомогли більш детально
відобразити структуру підсистеми, визначити основні сутності, компоненти та
пакети (модулі), а також розподілити функціональність між окремими модулями.
Для архітектурного проектування було визначено компонентну структуру
підсистеми, а тако.ж продумано взаємодію між фізичними компонентами
підсистеми (клієнтської частини, серверної частини, сервісу порівняння імен і
бази даних). Побудовані діаграми компонентів та розгортання дозволили наочно
представити структуру підсистеми, а також розподілити відповідальності між її
елементами.
Для моделювання поведінки підсистеми було визначено діаграми
діяльності, послідовності, комунікації та скінченного автомату. Ці діаграми
дозволили описати сценарії взаємодії працівника деканату ЧДТУ з підсистемою,
62
ЧДТУ 262259.020 ПЗ
визначити послідовність виконання дій та стани, в який може перебувати
підсистеми під час роботи.
Проведене проектування дозволило сформувати цілісне уявлення про
структуру, архітектуру та поведінку підсистеми для роботи з індивідуальними
предметами студентів. Отримані результати буду використані в подальшому для
реалізації програмного забезпечення, надаючи можливість в подальшому
масштабувати та модифікувати підсистему.
63
ЧДТУ 262259.020 ПЗ
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1. Розробка програмного комплексу
В наступних підрозділах буде детально описано процес розробки
програмного забезпечення підсистеми для роботи з індивідуальними
предметами. Метою є детальний та чіткий опис процесу створення підсистеми,
починаючи від стеку технологій до вже готових функціональних модулів та
компонентів. Також буде описано процес реалізації бази даних, веб-інтерфейсу
користувача та всіх функціональних компонентів.
3.1.1. Обґрунтування вибору засобів реалізації
Для розробки програмного забезпечення підсистеми для роботи з
індивідуальними предметами важливо обрати технології, що забезпечать високу
продуктивність, масштабованість та зручність для подальшого супроводу
програмного забезпечення.
Клієнтська частина підсистеми реалізована як односторінковий застосунок
(SPA). Для цього було використано фреймворк Angular, адже його компонентно-
орієнтована архітектура, де кожен функціональний елемент реалізований у
вигляді окремого компонента. Такий підхід забезпечує чітке розділення
відповідальностей між компонентами. Також це покращує читабельність коду,
що дозволить в майбутньому його легко масштабувати та підтримувати.
Для реалізації логіки клієнтської частини підсистеми використовується
мова програмування TypeScript, яка є надбудовою над JavaScript, що забезпечує
статичну типізацію. Використання TypeScript підвищує надійність програмного
коду, полегшує його читання та супровід і також зменшує кількість помилок, які
могли б виникнути через відсутність типів в JavaScript. Також об’єктно-
орієнтований підхід мови дозволяє створювати сутності у вигляді класів, і
ефективно працювати з ними.
Взаємодія клієнтської частини з серверною частиною реалізована через
64
ЧДТУ 262259.020 ПЗ
REST API. Веб-застосунок надсилає запити CRUD для індивідуальних
предметів, а також запити для розпізнавання предметів з додатку до диплому.
Веб-інтерфейс застосунку реалізований за допомогою конпонентного
підходу Angular та за допомогою SCSS. Це дозволило створити зручні
стилізовані компоненти, з кодом стилів що можна повторно використовувати та
легко підтримувати.
У якості середовища розробки використовувався ноутбук з операційною
системою Arch Linux, процесором Intel Core I5-10300H, відеокартою NVIDIA
GeForce GTX 1650 Mobile, 16 ГБ оперативної пам'яті DDR4.
Обрані засоби реалізації дозволяють забезпечити надійну та масштабовану
архітектуру підсистеми. Використання фреймворку Angular разом з мовою
TypeScript забезпечує ефективну реалізацію складної бізнес-логіки підсистеми.
3.1.2. Опис структурної (функціональної) схеми
Структурна схема підсистеми для роботи з індивідуальними предметами
відображає основні функціональні компоненти, їх призначення та взаємодії між
ними (рисунок 3.1). Побудова схеми була виконана за принципом розподілення
системи на окремі логічні блоки, де кожен з них відповідає лише за реалізацію
конкретного набору функцій.
Основні функціональні компоненти підсистеми:
- веб-застосунок (Angular-додаток): забезпечує взаємодію працівника
деканату з системою. Включає в себе всі функціональні компоненти системи;
- компоненти для роботи з студентами та предметами: центрельний
компонент підсистеми, де працівник деканату може переглядати списки
студентів та їх предмети, а також вибирати відповідні дії над ними;
- компоненти редагування: набір компонентів, що надають можливість
змінювати дані предмету, їх вид та тип, або змінити дані академічної
мобільності;
- компонент підтвердження дій: компонент, що відображає предмети і
студентів при призначенні або видаленні, і містить кнопки підтвердження дії;
- компонент розпізнавання додатку до диплому: компонент, що відповідає
65
ЧДТУ 262259.020 ПЗ
Рисунок 3.1 - Функціональна схема
за завантаження зображень, їх обробку та розпізнавання предметів з нього
а потім і їх перезарахування;
- сервіс: модуль, що забезпечує взаємодію компонентів з серверною
частиною за допомогою REST-запитів;
- REST API: інтерфейс взаємодії між клієнтською та серверною
частинами, який передає всі запити та відповіді;
66
ЧДТУ 262259.020 ПЗ
- серверна частина: обробляє запити від клієнта, реалізує бізнес-логіку
підсистеми, а також керує взаємодією з базою даних та сервісами;
- сервіс інтелектуалізованого порівняння імен: виконує обробку
зображень, розпізнає предмети та виконує семантичне порівняння з предметами
з навчального плану;
- база даних: забезпечує зберігання всіх даних підсистеми.
Взаємодія між компонентами відбувається в клієнт-серверною
архітектурою: користувач взаємодіє з клієнтським інтерфейсом, далі
відправляється запит на серверну частину. Серверна частина обробляє запити,
взаємодію з базою даних та з сервісом, після чого повертає відповідь клієнту.
Функціональна схема підсистеми детально описує взаємодію компонентів
системи, показуючи який компонент взаємодіє з іншим. Це дозволяє більш
детально зрозуміти логіку роботи підсистеми, а також порядок виконання
операцій.
3.1.3. Опис логічної схеми системи
Логічна схема підсистеми для роботи з індивідуальними предметами
описує послідовність дій, що виконуються під час взаємодії користувача з
системою та обробки даних. Основною метою підсистеми є забезпечення
зручного керуванням індивідуальними предметами (їх призначення,
редагування, видалення та розпізнавання).
На рисунку 3.2 зображено логічну схему розробленої підсистеми.
Розглянемо поетапно цю схему.
Підсистему можна представити у вигляді послідовності логічних кроків:
1 Ініціалізація системи: після відкриття веб-застосунку, відбувається
завантаження веб-інтерфейсу підсистеми. ініціюється основний компонент, який
потім формує запити до серверної частини для отримання початкового
відображення (групи та предмети для призначення).
2 Отримання та відображення даних: веб-застосунок надсилає
сформовані запити через сервіс до серверної частини за допомогою REST API.
Сервер обробляє запит, звертається до бази даних, отримує потрібну інформацію
67
ЧДТУ 262259.020 ПЗ
та відправляє відповідь. Клієнтська частина після отримання відповіді обробляє
відповідь і відображає її в веб-інтерфейсі.
3 Вибір студентів та предметів: працівник деканату обирає студентів зі
списку. Система відображає відповідні індивідуальні предмети. Після цього в
залежності від вибору відбувається обробка дій.
4 Обробка дій: якщо
- вибрано студентів та обрані предмети для призначення, після
вибору виду, натиснення кнопки “Призначити” та підтвердження дії
студенти та предмети відправляютья на серверну частину, після чого вони
записуються в базу даних і повертаються у вигляді відповіді на клієнтську
частину, готові до відображення та взаємодії;
- вибрано студентів та індивідуальні предмети, і натиснуто на кнопку
“Видалити”, після підтвердження дії студенти на предмети відправляються
на серверну частину, знаходяться та видаляються в базі даних, і після
відповіді стираються з списку в клієнтській частині;
- натиснуто на кнопку “Редагувати” біля предмету, відкривається
модальне вікно з полям вводу для редагування даних предмету. Після
редагування, відредагований предмет відправляється на серверну частину, і
проходить пошук та оновлення в базі даних, і після відповіді оновлює дані
для відображення в клієнтській частині;
- вибрано студентів та індивідуальні предмети, предмети мають вид
лише “Академічна мобільність” і натиснуто “Редагувати академічну
мобільність”, з’явиться вікно з можливість редагування даних академічної
мобільності предметів. Після редагування, відредаговані предмети і їх дані
відправляються на серверну частину, і проходить пошук та оновлення в базі
даних, і після відповіді оновлює дані для відображення в клієнтській частині;
- вибрано студентів та індивідуальні предмети, і натиснуто “Змінити
вид предметів”, з’явиться модальне вікно з вибором нового виду предметів.
Після редагування, список предметів і їх новий вид відправляються на
68
ЧДТУ 262259.020 ПЗ
Рисунок 3.2 - Блок-схема логічної роботи системи
- серверну частину, і проходить пошук та оновлення в базі даних, і
після відповіді оновлює дані для відображення в клієнтській частині;
69
ЧДТУ 262259.020 ПЗ
- вибрано студентів і натиснуто “Відомість з АР”, список студентів
відправляється на серверну частину. На серверній частині формується
документ з предметами академічної різниці для обраних студентів, 0
відправляє файл на клієнт;
- вибрано лише одного студента, і натиснуто “Розпізнати”. Тоді
з’являється модальне вікно, де працівник деканату може завантажувати
зображення, які потім передаються запитом на серверну частину, де вони
розпізнаються за допомогою нейромережі Gemini. Потім розпізнанні
предмети повертаються і відображаються на клієнтській частині. Після
розпізнавання всіх зображень і вибору предметів, вибрані предмети і
спеціальність відправляються на зовнішній інтелектуалізований сервіс
порівняння імен, де вони порівнюються з навчальним планом і
встановлюються подібні предмети і повертаються на клієнтську частину.
Після цього користувач може вручну обрати предмети для перезарахування
та академічної різниці, і призначити їх;
5 Збереження результатів: незалежно від обраної дії, нові або оновлені
дані відправляються на серверну частину, а потім записуються або
перезаписуються в базі даних, і повертають відповідь на клієнтську частину.
6 Оновлення інтерфейсу: після збереження результатів та обробки
відповіді, веб-інтерфейс застосунку оновлюється в відображає оновлені дані.
3.1.4. Розробка бази даних
База даних є невід’ємною частиною будь-якої інформаційної системи.
Вона є єдиним і великим сховищем даних в системі, де зберігаються всі сутності
та інформація, які використовують всі компоненти система, такі як клієнтська
частина, серверна частина та зовнішні сервіси.
Для організації та структуризації даних у підсистемі
використовуватиметься реляційна база даних, що буде керуватись СУБД
PostgreSQL. Вона забезпечить зручне представлення даних у вигляді таблиць та
відображення зв’язків між ними. Це важливо для підсистеми, яка працює з
70
ЧДТУ 262259.020 ПЗ
взаємопов’язаними сутностями ( студенти, дисципліни та індивідуальні
предмети).
Процес розробки бази даних включав в собі три основні етапи:
1 концептуальна модель даних: вона формується на першому етапі.
Вона відображає предметну область з точки зору користувача (працівника
деканату ЧДТУ). На цьому етапі були визначені ключові сутності і формується
загальне уявлення про структуру даних;
2 логічна модель даних: на цьому етапі відбувалась деталізація
структури підсистеми з точки зору розробника. На ньому було досліджено вже
існуючу базу даних і її сутності, і було визначено нові сутності, її атрибути і
зв’язки з вже існуючими сутностями. Для її представлення також були
використані діаграми класів;
3 фізична модель даних: на цьому етапі було реалізовано в базі даних
нові сутності. Для кожної нової сутності було створено таблиці, були визначені
її атрибути та ключі.
3.1.5. Розробка інтерфейсу користувача
Розробка інтерфейсу користувача є важливим етапом створення
підсистеми, адже саме за його допомогою працівник деканату зможе взаємодіяти
з програмним забезпеченням. Основна мета розробки інтерфейсу – забезпечити
його зручність і зрозумілість, та підвищити ефективність виконання основних
операцій працівником деканату ЧДТУ.
Інтерфейс підсистеми розроблено з урахуванням специфіки роботи
працівників деканату та їхніх потреб у швидкому доступі до інформації,
зручному і простому редагуванні даних та мінімізації кількості дій для
виконання основних операцій. Під час проектування та безпосередньої розробки
напрацювання часто обговорювались та узгоджувались з працівниками
деканату.
При розробці інтерфейсу також було враховано основні евристики
зручності використання, запропоновані Якобом Нільсеном:
71
ЧДТУ 262259.020 ПЗ
- видимість стану системи: користувач завжди бачить актуальні дані
(обрані студенти, список предметів);
Рисунок 3.3 – Інтерфейс підсистеми для роботи з індивідуальними предметами
- відповідність реальному світу: в інтерфейсі використовується
зрозуміла термінологія, що відповідає тематиці підсистеми;
- контроль і свобода користувача: у всіх модальних вікнах де
виконуються дії передбачено можливість підтвердження чи скасування дії;
- послідовність і стандарти: всі елементи інтерфейсу виконані в єдиному
стилі;
- запобігання помилкам: критичні операції (такі як видалення)
потребують підтвердження перед виконанням;
- гнучкість та ефективність використання: основні робочі елементи
були зроблені так, щоб інтуїтивно було зрозуміло які дії вони виконують
(списки, кнопки, форми), а також для пришвидшення роботи було додатково
додано фільтрацію, пошук, сортування. Також можливість роботи зразу з
декількома елементами (студентами або предметами) дозволяє підвищити
ефективність системи;
72
ЧДТУ 262259.020 ПЗ
- естетика та мінімалізм: інтерфейс не перевантажений зайвими
елементами, що спрощує сприйняття інформації.
3.1.6. Опис розробки програмних компонентів
Розробка програмних компонентів підсистеми для роботи з
індивідуальними предметами здійснювалась відповідно до принципів
модульності та розділення відповідальностей. Такий підхід дозволяє спростити
підтримку програмного забезпечення, підвищити його гнучкість та забезпечити
можливість подальшого розширення функціональності без суттєвих змін у вже
реалізованих компонентах.
Підсистему поділено на кілька компонентів:
1 CourseForStudent: основний компонент. Він відповідає за відображення
студентів та предметів. Також він містить на собі всі основні функціональні
елементи (кнопки, списки, форми). Саме на ньому працівник деканату обирає
студентів, предмети і дії, які будуть виконуватись;
2 ConfirmSelected: компонент у вигляді модального вікна, що
використовується для підтвердження дії призначення, або видалення предметів.
Відображає в собі списки обраних студентів та предметів, а також кнопки для
підтвердження або скасування дії;
3 CourseForStudentEditDialog: компонент у вигляді модального вікна,
що надає можливість редагування даних одного вибраного індивідуального
предмету. Містить в собі форму з полям введення, що відповідають його
атрибутам та кнопки підтвердження або скасування дії;
4 CourseTypeEdit: компонент у вигляді модального вікна, що надає
можливість редагувати вид предметів. Містить в собі списки вибраних студентів
та предметів, а також панель з кнопками для вибору нового виду предметів та
кнопки для скасування або підтвердження дії;
5 AcademicMobilityDataEdit: компонент у вигляді модального вікна, що
надає можливість редагувати дані академічної мобільності для обраних
предметів. Містить в собі список обраних студентів, а також форму у вигляді
таблиці з обраними предметами та їх даними академічної мобільності. Внизу
73
ЧДТУ 262259.020 ПЗ
присутні кнопки підтвердження або скасування дії, та чекбокс для вибору
редагування всіх полів разом для всіх предметів;
6 ExtractFromDiplomaSupplement: компонент у вигляді модального
вікна, що надає можливість розпізнавати предмети з додатків до диплому,
порівнювати їх з навчальним планом та перезараховувати. В лівій половині
містить в собі поле, куди можна зображення перетягнути, або обрати локальний
файл, натиснувши на нього, або вставивши з буфера обміну. Зверху поля, після
завантаження зображення, можна переглянути зображення, а також прізвище та
ім’я студента. В правій половині знаходиться таблиця, де відображатимуться
розпізнані предмети. Також користувач має змогу відредагувати їх, натиснувши
на іконку з олівцем біля імені студента. В нижній частині вікна, можна обрати
групу, з чиїм навчальним планом буде проводитись порівняння, а також кнопки
для підтвердження або скасування дії. Після того як всі предмети з зображень
будуть розпізнані, і буде натиснуто на кнопку “Порівняти”, після отримання
відповіді з сервера, модальне вікно змінює свій вміст. Зверху, біля імені і
прізвища студента, відображаються додаткові повідомлення, що відображаються
скільки кредитів було перезараховано, а скільки було призначено як академічна
різниця. Тіло вікна поділене на дві половини: зліва – таблиці з предметом з
навчального плану, справа напроти нього – таблиця з порівняними предметами,
які семантично підходять для перезарахування. Щоб перезарахувати предмет,
потрібно вибрати предмет з таблиці справа. Якщо ж жоден із запропонованих
предметів не підходить для перезарахування, його можна призначити як
академічну різницю, обравши предмет в таблиці зліва. Також, якщо предмет не
зовсім підходить для перезарахування (замало кредитів), він позначається
помаранчевим кольоромщоб попередити працівника деканату. Предмет обраний
для перезарахування в одній таблиці потім блокується в решті таблиця, щоб не
було дублювання. Розпізнані предмети які залишаться в кінці, будуть
відображені нижче під таблицями у вигляді списку, я можуть бути
перезараховані у вигляді вибіркових предметів. Після цього, відбувається
підтвердження дій і призначення предметів студенту.
74
ЧДТУ 262259.020 ПЗ
3.2. Тестування системи
Тестування підсистеми для роботи з індивідуальними предметами є
важливим етапом розробки, метою якого є перевірка коректності
функціонування програмного забезпечення, виявлення можливих помилок та
підтвердження відповідності реалізованого функціоналу вимогам, поставлених
замовником
Об’єктом тестування виступає клієнтська частина підсистеми, разом із
взаємодією із серверною частиною та сервісом розпізнавання. Основною метою
тестування є забезпечення правильності обробки даних, стабільності роботи
системи та коректної взаємодії її компонентів.
В цьому розділі будуть описані наступні рівні тестування:
- Модульне тестування;
- Інтеграційне тестування;
- Системне тестування;
- Приймальне тестування.
3.2.1. Модульне тестування
Модульне тестування проводилось для перевірки окремих методів
компонентів підсистеми ізольовано від інших частин підсистеми. Тестування
проводилось шляхом виклику відповідних методів, їх логування та аналізу логів
і отриманих результатів.
Таблиця 3.1
Модульне тестування
Тестовий Очікуваний
Модуль Фактичний результат Статус
випадок результат
getStudentsB
Отримання Повертається Список студентів Пройде
y
списку студентів список студентів отримано но
GroupId()
75
ЧДТУ 262259.020 ПЗ
Продовження таблиці 3.1
getCoursesFo
Отримання Повертається Список предметів Пройде
r
списку предметівсписок предметів отримано і відображено но
Students()
Метод повертає Повернуто
selectCourses Пройде
Вибір студентів лише спільні відфільтрований
ByStudents() но
предмети список
Метод повертає
Підтвердження результат Дані успішно Пройде
save()
дії успішного збережено но
збереження
sendPicture Завантаження Файл передається Файл передано Пройде
ToAPI() файлу на сервер успішно но
Було протестовано основні модулі клієнтської частини, зокрема компонент
роботи із студентами та предметами (основний компонент), сервіс взаємодії з
сервером, компонент підтвердження дій (для призначення та видалення) та
компонент розпізнавання.
3.2.2. Інтеграційне тестування
Інтеграційне тестування проводилось з метою перевірки взаємодії між
окремими компонентами підсистеми. Особлива увага була приділена саме
передачі даних між клієнтською та серверною частинами, а також інтеграції з
сервісом розпізнавання.
Тестування виконувалось шляхом моделювання реальних сценаріїв роботи
системи, їх логування та аналізу результатів взаємодії компонентів
76
ЧДТУ 262259.020 ПЗ
Таблиця 3.2
Інтеграційне тестування
Модульна Очікуваний Фактичний
Тестовий випадок Статус
взаємодія результат результат
Component >Запит списку Дані передаються Дані передано
Пройдено
Service студентів через сервіс успішно
Service > Сервер повертає Дані повертаються
Отримання даних Пройдено
API > Server дані коректно
Дані зчитуються з Зчитані дані
Server > DB Отримання записів Пройдено
бази даних отримано
Recognition
Отримано список Дані оброблено та
> Server > Розпізнавання Пройдено
предметів отримано
AI
Server > Оновлення Дані Інтерфейс і дані
Пройдено
Client інтерфейсу відображаються оновлено
Результати інтеграційного тестування підтверджують, що основні
компоненти підсистеми взаємодіють між собою коректно. Було проведено тести
по обміну даних між клієнтською та серверною частинами, передача даних до
сервісу порівняння та зчитування записів з бази даних. Всі пройдені тести
підтвердили стабільну роботи підсистеми та підтвердили відсутність помилок,
здатних порушити цілісність даних.
3.2.3. Системне тестування
Системне тестування проводилось для перевірки роботи підсистеми
загалом. Тестування здійснювалось шляхом виконання типових сценаріїв роботи
працівника деканату. Було перевірено повний цикл роботи системи, починаючи
з призначення та редагування індивідуальних предметів, до їх розпізнавання та
порівняння.
77
ЧДТУ 262259.020 ПЗ
Таблиця 3.3
Системне тестування
Тестовий Очікуваний
Модуль Фактичний результат Статус
випадок результат
Предмет додається
Призначення
Підсистема вибраним Предмет додано Пройдено
предмету
студентам
Предмет
Видалення
Підсистема видаляється у Предмет видалено Пройдено
предмету
вибраних студентів
Редагування
Підсистема Дані оновлюються Дані змінено Пройдено
даних
Отримано список Отримано список
Розпізнавання
Підсистема розпізнаних предметів з Пройдено
диплому
предметів зображення
Представлено
Розпізнані
порівнянні предмети,
Порівняння предмети порівняні
Підсистема семантично подібні до Пройдено
предметів з розпізнаними і
предмету навчального
подібні до них
плану
Результати системного тестування підтвердили, що всі компоненти
підсистеми між собою працюють коректно. Всі можливі сценарії були пройдені
успішно, і жодних помилок виявлено не було.
3.2.4. Приймальне тестування
Приймальне тестування проводилось з метою оцінки підсистеми з точки
зору кінцевого користувача (працівника деканату ЧДТУ). Тестування
проводилось шляхом практичного використання підсистеми в реальних умовах.
78
ЧДТУ 262259.020 ПЗ
Основна увага була приділена зручності та зрозумілості інтерфейсу, а
також швидкості та надійності
Таблиця 3.4
Приймальне тестування
Тестовий Очікуваний Фактичний
Модуль Статус
випадок результат результат
Інтерфейс зрозумілий
Зручність Користування
Інтерфейс та зручний для Пройдено
використання зручне
користування
Операції виконуються
Швидкість
Підсистема швидко, без великих Затримки відсутні Пройдено
роботи
затримок
Користувачу зрозуміло Логіка була
Підсистема Логіка роботиякі дії і як він їх зрозумілою для Пройдено
виконує користувача
Не буде виявлено
критичних помилок,
Надійність Помилок виявлено
Підсистема що можуть пошкодити Пройдено
системи не було
дані або перешкодити
роботі підсистеми
Приймальне тестування підтвердило, що підсистема відповідає вимогам
працівників деканату ЧДТУ. Створений функціонал і інтерфейс набагато
спрощують роботу користувача, роблячи її виконання швидшим та
ефективнішим. Також розроблений інтерфейс потребує мінімального порогу
входу для розуміння функціоналу розміщених на ньому елементів та їх
призначення.
3.3. Приклади впровадженого програмного комплексу
79
ЧДТУ 262259.020 ПЗ
У цьому підрозділі наведено приклади впровадження розробленої
підсистеми для роботи з індивідуальними предметами студентів, а також
описано процес її розгортання на серверному середовищі.
Клієнтська частина підсистеми реалізована за допомогою фреймворку
Angular, а отже для її запуску потрібно зібрати проект. Під час збірки
створюються оптимізовані файли для запуску вебзастосунку. Під час збірки,
TypeScript-код автоматично трансформується у JavaScript, оскільки саме
JavaScript безпосередньо виконується в браузері. У результаті формується файл
index.html, а також набір JavaScript-скриптів та допоміжних ресурсів (рисунок
3.4)
Для збірки проекту було використано наступну команду:
npm run build --prod --aot=false --build-optimizer=false
Рисунок 3.4 – Файлова структура зібраного проекту
Сформовані файли вручну передаються на сервер за допомогою SSH-
з’єднання. Серверна частина підсистеми розгорнута на віртуальній машині, що
спрощує адміністрування системи, а також позбавляє від проблем, пов’язаних з
фізичної складовою (як от поломка пристрою сервера або відключення світла).
Налаштування серверного середовища дозволяє автоматично підключати
80
ЧДТУ 262259.020 ПЗ
HTTPS-сертифікати, завдяки чому забезпечується захищений обмін даними між
клієнтом і сервером.
Для розгортання клієнтської частини на сервері використовується
вебсервер Nginx, який забезпечує швидку обробку HTTP-запитів, роздачу
статичних файлів та перенаправлення запитів до серверної частини.
Використання Nginx дозволяє підвищити стабільність та продуктивність роботи
підсистеми.
Інтерфейс розробленої підсистеми наведено в “Додатку Б”.
Весь запланований функціонал було успішно реалізовано та розгорнуто.
Основні користувачі роботою підсистеми задоволені, та підкреслили її зручність
на ефективність.
81
ЧДТУ 262259.020 ПЗ
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ
У третьому розділі було розглянуто процес реалізації, тестування та
впровадження підсистеми для роботи з індивідуальними предметами студентів.
Описано особливості розробки компонентів підсистеми, їх взаємодію та
принципи організації клієнтської частини підсистеми.
У процесі тестування було перевірено коректність виконання роботи
окремих модулів, взаємодію між компонентами системи та функціонування
підсистеми загалом. Результати роботи підтвердили стабільність роботи
програмного забезпечення, коректність обробки даних та відповідність
функціоналу до поставлених вимог.
Також у розділі було розглянуто процес розгортання підсистеми у
серверному середовищі. Було описано збірку клієнтської частини, передачу
проекту на серверну частину та про технологію вебсервера Nginx. Реалізоване
рішення забезпечує стабільну роботу системи та захищений обмін даними.
82
ЧДТУ 262259.020 ПЗ
ВИСНОВКИ
На сьогодні автоматизація освітньої діяльності університетів є важливою
складовою для ефективного управління навчального процесу. Аналіз існуючих
інформаційних систем і їх підходу до керування навчальними предметами
показав, що вони потребують розширення існуючого функціоналу для
коректного обліку таких предметів, як академічна різниця, академічна
мобільність та перезарахування. Об’єктом розробки в межах кваліфікаційної
роботи виступав процес розробки програмного забезпечення інформаційних
систем у галузі освіти, а предметом розробки - програмне забезпечення
підсистеми роботи з індивідуальними предметами студентів в інформаційно-
аналітичній системі підтримки освітньої діяльності університету. У межах
кваліфікаційної роботи було розв’язано науково-практичну задачу розробки
клієнтської частини підсистеми робити з індивідуальними предметами студентів
у складі інформаційної системи університету, що підвищило зручність обробки
даних та ефективність роботи працівників деканату.
Для вирішення поставленої задачі було використано методи аналізу
предметної області, формування вимог (функціональних, нефункціональних,
первинних, детальних, та вимог від розробника і замовника), UML-
моделювання, проектування архітектури на основі компонентно-орієнтованого
підходу та об’єктно-орієнтоване програмування із застосуванням Angular і
TypeScript. У процесі роботи було проведено аналіз вимог до підсистеми,
розроблено концепцію підсистеми, визначено основні модулі, спроектовано
логічну структуру підсистеми, реалізовано функціонал створення, редагування,
видалення та зміни типів індивідуальних предметів, а також їх розпізнавання та
порівняння. На відмінну від вже існуючих рішень в аналогах, розроблена
підсистема забезпечує більш структуроване представлення індивідуальних
предметів, відділивши їх від основних предметів, і можливість подальшого
масштабування функціоналу.
Практична цінність отриманих результатів полягає у впровадженні
підсистеми в межах інформаційної системи університету. Достовірність
83
ЧДТУ 262259.020 ПЗ
результатів підтверджується проведеними тестами, що засвідчили коректність
та стабільність підсистеми, а також безпосереднім використанням працівниками
деканату підсистеми, що повністю задовільняє їх потреби та вимоги. Результати
роботи можуть бути використанні для подальшого розширення та вдосконалення
інформаційної системи університету.
84
ЧДТУ 262259.020 ПЗ
СПИСОК ВИКОРИСИТАНИХ ДЖЕРЕЛ
1 Морзе Н. В. Інформаційні системи : навч. посіб. / Н. В. Морзе, О. П.
Кузьмінська. — Київ : Видавнича група BHV, 2012. — 384 с.
2 Пономаренко В. С. Інформаційні системи в управлінні організацією : навч.
посіб. / В. С. Пономаренко. — Харків : ХНЕУ, 2008. — 424 с.
3 Копняк К. В. Проєктування інформаційних систем : навч. посіб. / К. В.
Копняк. — Київ : КПІ ім. Ігоря Сікорського, 2019. — 286 с.
4 Трофименко О. Г. Сучасні інформаційні технології та системи : навч. посіб.
/ О. Г. Трофименко. — Одеса : ОНПУ, 2020. — 238 с.
5 Глибовець М. М. Аналіз та проєктування інформаційних систем : навч.
посіб. / М. М. Глибовець. — Київ : НаУКМА, 2017. — 312 с.
6 Згуровський М. З. Основи системного аналізу : підручник / М. З.
Згуровський, Н. Д. Панкратова. — Київ : Видавнича група BHV, 2007. — 544 с.
7 Лавріщева К. М. Програмна інженерія : підручник / К. М. Лавріщева. —
Київ : Академперіодика, 2008. — 319 с.
8 Федасюк Д. В. Основи програмної інженерії : навч. посіб. / Д. В. Федасюк.
— Львів : Львівська політехніка, 2015. — 300 с.
9 Шаховська Н. Б. Інженерія програмного забезпечення : навч. посіб. / Н. Б.
Шаховська. — Львів : Львівська політехніка, 2018. — 432 с.
10 Sommerville I. Software Engineering / Ian Sommerville. — 10th ed. —
Boston : Pearson, 2016. — 816 p.
11 Pressman R. S. Software Engineering: A Practitioner’s Approach / Roger S.
Pressman, Bruce R. Maxim. — 8th ed. — New York : McGraw-Hill Education, 2014.
— 976 p.
12 Martin R. C. Clean Architecture: A Craftsman’s Guide to Software Structure
and Design / Robert C. Martin. — Boston : Prentice Hall, 2017. — 432 p.
13 Martin R. C. Clean Code: A Handbook of Agile Software Craftsmanship /
Robert C. Martin. — Boston : Prentice Hall, 2008. — 464 p.
85
ЧДТУ 262259.020 ПЗ
14 Gamma E. Design Patterns: Elements of Reusable Object-Oriented Software /
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. — Boston : Addison-
Wesley, 1994. — 395 p.
15 Fowler M. UML Distilled: A Brief Guide to the Standard Object Modeling
Language / Martin Fowler. — 3rd ed. — Boston : Addison-Wesley, 2003. — 208 p.
16 OMG. Unified Modeling Language (UML) Specification [Електронний
ресурс]. — Режим доступу: https://www.omg.org/spec/UML/.
17 Бондаренко М. Ф. Об'єктно-орієнтоване програмування : навч. посіб. / М.
Ф. Бондаренко. — Харків : ХНУРЕ, 2016. — 296 с.
18 Коваль З. О. Веб-технології та веб-дизайн : навч. посіб. / З. О. Коваль. —
Львів : Новий Світ-2000, 2021. — 344 с.
19 Flanagan D. JavaScript: The Definitive Guide / David Flanagan. — 7th ed. —
Sebastopol : O’Reilly Media, 2020. — 704 p.
20 Mozilla Developer Network. JavaScript Guide [Електронний ресурс]. —
Режим доступу: https://developer.mozilla.org/.
21 Mozilla Developer Network. HTML: HyperText Markup Language
[Електронний ресурс]. — Режим доступу: https://developer.mozilla.org/.
22 Mozilla Developer Network. CSS: Cascading Style Sheets [Електронний
ресурс]. — Режим доступу: https://developer.mozilla.org/.
23 Angular Documentation [Електронний ресурс]. — Google. — Режим
доступу: https://angular.io/docs.
24 Freeman A. Pro Angular / Adam Freeman. — 4th ed. — New York : Apress,
2022. — 780 p.
25 Angular Tutorial українською [Електронний ресурс]. — Режим доступу:
https://angular.tutorial.in.ua/.
26 TypeScript Documentation [Електронний ресурс]. — Microsoft. — Режим
доступу: https://www.typescriptlang.org/docs/.
27 Richardson L. RESTful Web APIs / Leonard Richardson, Mike Amundsen, Sam
Ruby. — Sebastopol : O’Reilly Media, 2013. — 408 p.
86
ЧДТУ 262259.020 ПЗ
28 Fielding R. T. Architectural Styles and the Design of Network-based Software
Architectures : Doctoral dissertation / Roy Thomas Fielding. — Irvine : University of
California, 2000. — 162 p.
29 Мельников В. І. Бази даних та інформаційні системи : навч. посіб. / В. І.
Мельников. — Київ : Академія, 2010. — 400 с.
30 Циганенко О. В. Організація баз даних : навч. посіб. / О. В. Циганенко. —
Київ : Центр навчальної літератури, 2018. — 256 с.
31 Elmasri R. Fundamentals of Database Systems / Ramez Elmasri, Shamkant
Navathe. — 7th ed. — Boston : Pearson, 2016. — 1272 p.
32 ISO/IEC 9075. Information technology — Database languages — SQL. —
Geneva : International Organization for Standardization, 2016.
33 Nielsen J. Usability Engineering / Jakob Nielsen. — Boston : Morgan
Kaufmann, 1994. — 362 p.
34 Krug S. Don’t Make Me Think / Steve Krug. — 3rd ed. — Berkeley : New
Riders, 2014. — 216 p.
35 Кудрявцева О. М. Основи UX/UI-проєктування : навч. посіб. / О. М.
Кудрявцева. — Київ : КПІ ім. Ігоря Сікорського, 2021. — 210 с.
36 Myers G. J. The Art of Software Testing / Glenford J. Myers, Corey Sandler,
Tom Badgett. — 3rd ed. — Hoboken : Wiley, 2011. — 256 p.
37 Каніщев О. Л. Тестування програмного забезпечення : навч. посіб. / О. Л.
Каніщев. — Харків : ХНУРЕ, 2019. — 278 с.
38 ISTQB Foundation Level Syllabus [Електронний ресурс]. — International
Software Testing Qualifications Board. — Режим доступу: https://www.istqb.org/.
39 ISO/IEC/IEEE 29119. Software Testing Standard. — Geneva : International
Organization for Standardization, 2013.
40 ISO/IEC/IEEE 12207. Systems and Software Engineering — Software Life
Cycle Processes. — Geneva : International Organization for Standardization, 2017.
41 SUMDU IT. Інформаційна система «Університет» [Електронний ресурс].
— Режим доступу: https://www.it.sumdu.edu.ua/.
87
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_________________ Голуб С.В.
„____” ______________ 2026 р.
Інформаційна система університету. Клієнтська частина підсистеми роботи з
індивідуальними предметами
Специфікація
482 ЧДТУ 262259.020
Листів 2
Розробник ________________ Різник О.М.
Керівник _________________ Заспа Г.О.
2026
ЧДТУ 262259.020 2
Позначення Найменування Примітка
482 ЧДТУ 262259 12 01 Лістинг програм
482 ЧДТУ 262259 90 01 Графічні матеріали
482 ЧДТУ 262259 34 01 Інструкція користувачеві
89
ДОДАТОК Б
Інформаційна система університету. Клієнтська частина підсистеми роботи з
індивідуальними предметами
Лістинг програм
482 ЧДТУ 262259 12 01
Листів 27
Розробник ________________ Різник О.М.
2026
482 ЧДТУ 262259 12 01 2
ЗМІСТ
Лістинг Б.1 – Клас сутності CourseForStudent..........................................................3
Лістинг Б.2 – Реалізація основного компоненту CourseForStudent .......................3
Лістинг Б.3 – HTML-розмітка компоненту CourseForStudent ..............................16
Лістинг Б.4 – Реалізація компоненту розпізнавання, порівняння та
перезарахування предметів з додатку до диплому
ExtractFromDiplomaSupplement................................................................................20
91
482 ЧДТУ 262259 12 01 3
Лістинг Б.1 – Клас сутності CourseForStudent
import {BaseEntity} from "./basemodels/BaseEntity";
import {StudentDegree} from "./StudentDegree";
import {Course} from "./Course";
import {Teacher} from "./Teacher";
import {CourseType} from "./course-type.enum";
import {EducationInstitution} from './EducationInstitution';
export class CourseForStudent extends BaseEntity {
course: Course;
studentDegree: StudentDegree;
teacher: Teacher;
courseType: CourseType;
selected?: boolean = false;
selective?: boolean;
educationInstitution?: EducationInstitution;
studyStarted?: Date;
studyFinished?: Date;
certificateNumber?: string;
certificateDate?: Date;
}
Лістинг Б.2 – Реалізація основного компоненту CourseForStudent
import { Component, OnInit, TemplateRef, ViewChild,
EventEmitter } from '@angular/core';
import {StudentGroup} from '../../models/StudentGroup';
import {GroupService} from '../../services/group.service';
import {CourseService} from '../../services/course.service';
import {Course} from '../../models/Course';
import {CourseCreationComponent} from '../shared/courses-
for/course-creation/course-creation.component';
import {StudentService} from '../../services/student.service';
import {StudentDegree} from '../../models/StudentDegree';
import {CourseForStudent} from '../../models/CourseForStudent';
import {CourseForStudentService} from '../../services/course-
for-student.service';
import {CourseType} from '../../models/course-type.enum';
import {BsModalRef, BsModalService} from 'ngx-bootstrap/modal';
import {ConfirmSelectedComponent} from './confirm-
selected/confirm-selected.component';
import {Utils} from '../shared/utils';
import {ExtractFromDiplomaSupplementComponent} from './extract-
from-diploma-supplement/extract-from-diploma-
supplement.component';
import {CourseForStudentEditDialogComponent} from './course-for-
student-edit-dialog/course-for-student-edit-dialog.component';
import {AcademicMobilityDataEditComponent} from './academic-
mobility-data-edit/academic-mobility-data-edit.component';
import {CourseTypeEditComponent} from './course-type-
edit/course-type-edit.component';
92
482 ЧДТУ 262259 12 01 4
@Component({
selector: 'courses-for-students',
templateUrl: './courses-for-students.component.html',
styleUrls: ['./courses-for-students.component.scss']
})
export class CoursesForStudentsComponent implements OnInit {
HOURS_PER_CREDIT = 30;
groups: StudentGroup[];
selectedGroup: StudentGroup;
selectedSemester: number;
courses: Course[];
selectedCourses: Course[] = [];
selectedStudents: StudentDegree[] = [];
selectedCourseForStudent: CourseForStudent;
selectedCoursesForStudent: CourseForStudent [] = [];
unfilteredSelectedCoursesForStudent: CourseForStudent [] = [];
students: StudentDegree[];
coursesForStudent: CourseForStudent[] = [];
studentCoursesMap: { [studentId: number]: CourseForStudent[] }
= {};
showPage = false;
searchText = '';
semesters: number[] = [];
courseType = CourseType;
courseTypeKey: Array<string>;
selectedCourseType: string;
studiedCoursesLoading = false;
@ViewChild(CourseCreationComponent, {static: false})
courseCreationChild: CourseCreationComponent;
assignCoursesModalRef: BsModalRef;
isCoursesTableMaster = true;
specializationGroups: StudentGroup[];
isSelectiveSortDirection: 'asc' | 'desc' = 'asc';
acadDiffExamReportLoading = false;
constructor(private groupService: GroupService, private
courseService: CourseService,
private studentService: StudentService, private
courseForStudentService: CourseForStudentService,
private modalService: BsModalService) {
}
ngOnInit() {
this.groupService.getGroups().subscribe(groups => {
this.groups = groups;
this.showPage = true;
});
this.courseTypeKey = Object.keys(CourseType);
this.selectedCourseType = this.courseTypeKey[0];
}
changeSemesters() {
93
482 ЧДТУ 262259 12 01 5
this.semesters = [];
for (let i = 1; i <= this.selectedGroup.studySemesters +
(this.selectedGroup.beginYears - 1) * 2; i++) {
this.semesters.push(i);
}
if (!this.semesters.includes(this.selectedSemester)) {
this.selectedSemester = this.semesters[0];
}
}
onSemesterChange() {
this.loadCoursesBySemester();
this.courseCreationChild.form.controls.semester.setValue(this.se
lectedSemester);
this.isCoursesTableMaster = true;
this.coursesForStudent = [];
this.loadCoursesForStudents();
if (this.students) {
this.students.forEach(student => student.selected =
false);
this.students.forEach(student =>
student.hasSelectedCoursesForStudent = false);
}
}
onGroupChange() {
const previousSemester = this.selectedSemester;
this.changeSemesters();
this.isCoursesTableMaster = true;
if (this.selectedSemester !== previousSemester) {
this.onSemesterChange();
}
this.studentService.getStudentsByGroupId(this.selectedGroup.id).
subscribe(students => {
this.students = students;
this.coursesForStudent = [];
this.loadCoursesForStudents();
});
this.selectedStudents = [];
}
loadCoursesBySemester() {
this.studiedCoursesLoading = true;
this.courseService.getCoursesBySemesterAndHoursPerCredit(this.se
lectedSemester, this.HOURS_PER_CREDIT).subscribe(cfg => {
this.courses = cfg;
this.studiedCoursesLoading = false;
});
94
482 ЧДТУ 262259 12 01 6
}
changeSelectedCourses(event) {
this.selectedCourses = this.courses.filter(course =>
course.selected);
}
onCourseCreation() {
if (this.selectedSemester) {
this.studiedCoursesLoading = true;
this.courseService.getCoursesBySemesterAndHoursPerCredit(this.se
lectedSemester, this.HOURS_PER_CREDIT).subscribe(cfg => {
this.courses = cfg;
this.studiedCoursesLoading = false;
})
}
}
addCoursesForStudents(template: TemplateRef<any>) {
const selectedStudents = this.students.filter(student =>
student.selected);
const isSaved = new EventEmitter<boolean>();
const header = 'Призначення предметів студентам';
this.assignCoursesModalRef =
this.modalService.show(ConfirmSelectedComponent,
{
initialState: {
selectedStudents: selectedStudents, selectedCourses:
this.selectedCourses, courseType: this.selectedCourseType,
header, isSaved
},
class: 'confirm-selected-modal'
});
isSaved.subscribe(saved => {
if (saved) {
this.loadCoursesForStudents().then(() => {
this.selectCoursesByStudents();
});
}
});
}
selectCoursesByStudents() {
if (this.isCoursesTableMaster) {
const selectedStudentIds = this.students
.filter(student => student.selected)
.map(student => student.id);
if (selectedStudentIds.length > 0) {
const studentCourses = selectedStudentIds.map(studentId
=> this.studentCoursesMap[studentId] || []);
95
482 ЧДТУ 262259 12 01 7
if (studentCourses.length > 0) {
const commonCourses = studentCourses.reduce((acc,
courses) =>
acc.filter(course =>
courses.some(c => c.course.id ===
course.course.id && c.courseType === course.courseType)
),
studentCourses[0]
);
const uniqueCourses = [];
for (let i = 0; i < commonCourses.length; i++) {
let isDuplicate = false;
for (let j = 0; j < uniqueCourses.length; j++) {
if (commonCourses[i].course.id ===
uniqueCourses[j].course.id &&
commonCourses[i].courseType ===
uniqueCourses[j].courseType) {
isDuplicate = true;
break;
}
}
if (!isDuplicate) {
uniqueCourses.push(commonCourses[i]);
}
}
this.coursesForStudent = uniqueCourses;
} else {
this.coursesForStudent = [];
}
} else {
this.coursesForStudent = [];
}
}
this.selectedStudents = this.students.filter(student =>
student.selected);
if (this.isCoursesTableMaster) {
this.sortCoursesForStudentByName();
}
}
getCoursesInGroup() {
const studentIds = this.students
.map(student => student.id);
if (studentIds.length > 0) {
this.coursesForStudent = studentIds
.map(studentId => this.studentCoursesMap[studentId] ||
[])
.reduce((acc, courses) => acc.concat(courses), [])
.filter((course, index, array) =>
array.findIndex(c =>
c.course.id === course.course.id && c.courseType ===
96
482 ЧДТУ 262259 12 01 8
course.courseType && c.selective === course.selective
) === index
);
} else {
this.coursesForStudent = [];
}
}
changeMasterTable(isCoursesTableMaster: boolean) {
this.isCoursesTableMaster = isCoursesTableMaster;
this.cleanAllCheck();
this.students.forEach(student => student.selected = false);
this.students.forEach(student =>
student.hasSelectedCoursesForStudent = false);
if (!isCoursesTableMaster) {
this.getCoursesInGroup();
} else {
this.selectCoursesByStudents();
}
}
checkCourse(isChecked: boolean, course) {
if (!this.isCoursesTableMaster) {
this.students.forEach(student => student.selected =
false);
if (isChecked) {
this.selectedCourseForStudent = course;
if (!this.selectedCoursesForStudent.some(c =>
c.course.id === course.course.id && c.courseType ===
course.courseType
&& c.course.knowledgeControl ===
course.knowledgeControl)) {
this.selectedCoursesForStudent.push(course);
}
this.students.forEach(student => {
const studentCourses =
this.studentCoursesMap[student.id];
if (studentCourses) {
student.hasSelectedCoursesForStudent =
this.selectedCoursesForStudent.every(selectedCourse =>
studentCourses.some(sc => sc.course.id ===
selectedCourse.course.id && sc.courseType ===
selectedCourse.courseType)
);
}
});
} else {
this.selectedCoursesForStudent =
this.selectedCoursesForStudent.filter(c =>
c.course.id !== course.course.id || c.courseType !==
course.courseType || c.selective !== course.selective);
97
482 ЧДТУ 262259 12 01 9
this.students.forEach(student => {
const studentCourses =
this.studentCoursesMap[student.id];
if (studentCourses &&
this.selectedCoursesForStudent.length !== 0) {
student.hasSelectedCoursesForStudent =
this.selectedCoursesForStudent.every(selectedCourse =>
studentCourses.some(sc => sc.course.id ===
selectedCourse.course.id && sc.courseType ===
selectedCourse.courseType)
);
} else {
student.hasSelectedCoursesForStudent = false;
}
});
}
this.selectedStudents = this.students.filter(student =>
student.selected);
} else {
if (isChecked) {
this.selectedCoursesForStudent.push(course);
} else {
this.selectedCoursesForStudent =
this.selectedCoursesForStudent.filter(c => c.course.id !==
course.course.id);
}
}
}
deleteCourseForStudents() {
const isDeleted = new EventEmitter<boolean>();
const header = 'Видалення предметів студентам';
this.assignCoursesModalRef =
this.modalService.show(ConfirmSelectedComponent,
{
initialState: {
selectedStudents: this.selectedStudents,
selectedCourses: this.selectedCoursesForStudent, courseType:
this.selectedCourseType,
header, isDeleted
},
class: 'confirm-selected-modal'
});
isDeleted.subscribe(deleted => {
if (deleted) {
this.loadCoursesForStudents().then(() => {
this.getCoursesInGroup();
this.students.forEach(student => student.selected =
false);
98
482 ЧДТУ 262259 12 01 10
this.students.forEach(student =>
student.hasSelectedCoursesForStudent = false);
});
}
});
}
changeTeacher(course) {
}
private loadCoursesForStudents(): Promise<void> {
return new Promise((resolve) => {
if (!this.students || this.students.length === 0
|| !this.selectedSemester) {
resolve();
return;
}
const studentIds = this.students.map(student =>
student.id);
this.studentCoursesMap = {};
this.courseForStudentService.getCoursesForStudents(studentIds,
this.selectedSemester)
.subscribe(coursesForStudent => {
coursesForStudent.forEach(courseForStudent => {
const studentId = courseForStudent.studentDegree.id;
if (!this.studentCoursesMap[studentId]) {
this.studentCoursesMap[studentId] = [];
}
this.studentCoursesMap[studentId].push(courseForStudent);
});
this.cleanAllCheck();
resolve();
});
});
}
private cleanAllCheck() {
this.selectedCourses.forEach(course => course.selected =
false);
this.selectedCoursesForStudent.forEach(course =>
course.course.selected = false);
this.selectedCoursesForStudent = [];
this.selectedCourses = [];
}
changeCourseType() {
this.selectedCoursesForStudent.forEach(course => {
99
482 ЧДТУ 262259 12 01 11
let newType: CourseType;
if (course.courseType ===
Utils.getEnumKeyByValue(CourseType,
CourseType.ACADEMIC_DIFFERENCE)) {
newType = Utils.getEnumKeyByValue(CourseType,
CourseType.RECREDIT);
} else {
newType = Utils.getEnumKeyByValue(CourseType,
CourseType.ACADEMIC_DIFFERENCE);
}
this.courseForStudentService.updateCourseForStudentType(course.i
d, newType).subscribe({
next: () => {
course.courseType = newType;
}
});
});
}
changeSelective(checked: boolean, courseForStudent:
CourseForStudent) {
this.courseForStudentService.updateCourseForStudentSelective(cou
rseForStudent.id, checked).subscribe();
}
showDiplomaSupplement() {
const selectedStudent = this.selectedStudents[0];
this.specializationGroups = this.groups.filter(group =>
group.specialization.id ===
this.selectedGroup.specialization.id);
this.assignCoursesModalRef =
this.modalService.show(ExtractFromDiplomaSupplementComponent, {
initialState: {selectedStudent: selectedStudent,
specializationGroups: this.specializationGroups},
class: 'extract-from-diploma-supplement-modal'
});
const modalContent = this.assignCoursesModalRef.content as
ExtractFromDiplomaSupplementComponent;
modalContent.onClose.subscribe((result: any) => {
if (result.updated) {
this.loadCoursesForStudents().then(() => {
this.selectCoursesByStudents();
});
}
});
}
showEditDialog(courseForStudent: CourseForStudent) {
100
482 ЧДТУ 262259 12 01 12
this.assignCoursesModalRef =
this.modalService.show(CourseForStudentEditDialogComponent, {
initialState: {courseForStudent: courseForStudent},
class: 'course-for-student-edit-modal'
});
const modalContent = this.assignCoursesModalRef.content as
CourseForStudentEditDialogComponent;
modalContent.onClose.subscribe((result: any) => {
if (result.updatedCourseForStudent) {
this.loadCoursesForStudents().then(() => {
this.selectCoursesByStudents();
});
}
});
}
showAcademicMobilityEditDialog() {
for (const cfs of this.selectedCoursesForStudent) {
if (cfs.courseType !== Utils.getEnumKeyByValue(CourseType,
CourseType.ACADEMIC_MOBILITY)) {
alert('Один з вибраних предметів не є предметом
академічної мобільності');
return;
}
}
this.assignCoursesModalRef =
this.modalService.show(AcademicMobilityDataEditComponent, {
initialState: {coursesForStudent:
this.selectedCoursesForStudent, students:
this.selectedStudents},
class: 'academic-mobility-data-edit-modal'
});
const modalContent = this.assignCoursesModalRef.content as
AcademicMobilityDataEditComponent;
modalContent.onClose.subscribe((result: any) => {
if (result.updatedCourseForStudentInstitution) {
this.loadCoursesForStudents().then(() => {
this.selectCoursesByStudents();
});
}
});
}
showCourseTypeEditDialog() {
this.unfilteredSelectedCoursesForStudent = [];
this.selectedStudents.forEach((student, i) => {
const studentCourses = this.studentCoursesMap[student.id];
if (studentCourses) {
this.selectedCoursesForStudent.forEach((course, j) => {
const matchingCourses = studentCourses.filter(sc =>
sc.course.id === course.course.id &&
101
482 ЧДТУ 262259 12 01 13
sc.studentDegree.id === student.id);
this.unfilteredSelectedCoursesForStudent.push(...matchingCourses
);
});
}
});
const uniqueIds = new Set();
this.unfilteredSelectedCoursesForStudent =
this.unfilteredSelectedCoursesForStudent.filter(course => {
if (uniqueIds.has(course.id)) {
return false;
}
uniqueIds.add(course.id);
return true;
});
this.assignCoursesModalRef =
this.modalService.show(CourseTypeEditComponent, {
initialState: {coursesForStudent:
this.unfilteredSelectedCoursesForStudent, students:
this.selectedStudents},
class: 'course-type-edit-modal'
});
const modalContent = this.assignCoursesModalRef.content as
CourseTypeEditComponent;
modalContent.onClose.subscribe((result: any) => {
if (result.updatedCourseForStudentType) {
this.loadCoursesForStudents().then(() => {
this.selectCoursesByStudents();
});
}
});
}
compareStringsWithUkrAndEngNames(str1, str2) : number {
str1 = str1.toLowerCase();
str2 = str2.toLowerCase();
const isCyrillicA = /[а-яґєії]/.test(str1.charAt(0));
const isCyrillicB = /[а-яґєії]/.test(str2.charAt(0));
if (isCyrillicA && isCyrillicB) {
return str1.localeCompare(str2, 'uk');
} else {
if (!isCyrillicA && !isCyrillicB) {
return str1.localeCompare(str2, 'en');
} else {
return isCyrillicA ? 1 : -1;
}
}
}
sortCoursesForStudentByName() {
102
482 ЧДТУ 262259 12 01 14
this.coursesForStudent.sort((a, b) => {
return
this.compareStringsWithUkrAndEngNames(a.course.courseName.name,
b.course.courseName.name);
});
}
sortCoursesForStudentByType() {
this.coursesForStudent.sort((a, b) => {
if (a.courseType != b.courseType)
return a.courseType.localeCompare(b.courseType, 'uk');
else
return
this.compareStringsWithUkrAndEngNames(a.course.courseName.name,
b.course.courseName.name);
});
}
sortCoursesForStudentByControl() {
this.coursesForStudent.sort((a, b) => {
const numberA = a.course.knowledgeControl.id;
const numberB = b.course.knowledgeControl.id;
if (numberA != numberB)
return numberA - numberB;
else
return
this.compareStringsWithUkrAndEngNames(a.course.courseName.name,
b.course.courseName.name);
});
}
sortCoursesForStudentByIsSelective() {
this.coursesForStudent.sort((a, b) => {
if (this.isSelectiveSortDirection === 'asc') {
if (a.selective && !b.selective) return 1;
if (!a.selective && b.selective) return -1;
} else {
if (a.selective && !b.selective) return -1;
if (!a.selective && b.selective) return 1;
}
return
this.compareStringsWithUkrAndEngNames(a.course.courseName.name,
b.course.courseName.name);
});
this.isSelectiveSortDirection =
this.isSelectiveSortDirection === 'asc' ? 'desc' : 'asc';
}
buildAcademicDifferenceExamReport() {
this.acadDiffExamReportLoading = true;
const studentDegreeIds : number[] =
this.selectedStudents.map(sd => sd.id);
103
482 ЧДТУ 262259 12 01 15
this.courseForStudentService.buildAcademicDifferenceExamReport(s
tudentDegreeIds).subscribe(() => {
this.acadDiffExamReportLoading = false;
});
}
isOnlyAcademicMobility() {
return this.selectedCoursesForStudent.every(cfs =>
cfs.courseType ===
Utils.getEnumKeyByValue(CourseType,
CourseType.ACADEMIC_MOBILITY));
}
}
1.15
<div class="container-fluid courses-for-groups">
<div *ngIf="!showPage">
<loading [size]="40"></loading>
</div>
<div *ngIf="showPage" class="selection row">
<div class="col-7">
<div class="menu-row">
<div class="element">
<div class="element-header">Група:</div>
<div class="col-2">
<select id="group" class="form-control mr-2"
[(ngModel)]="selectedGroup"
(change)="onGroupChange()">
<option *ngFor="let group of groups"
[ngValue]="group">{{ group.name }}</option>
</select>
</div>
</div>
<div class="element">
<div class="element-header">Семестр:</div>
<div class="col-1">
<select id="semester" class="form-control mr-2"
[(ngModel)]="selectedSemester"
(change)="onSemesterChange()">
<option *ngFor="let semester of semesters"
[ngValue]="semester">{{ semester }}</option>
</select>
</div>
</div>
<div class="col-7">
<input [(ngModel)]="searchText" placeholder="Пошук за
предметом"
class="form-control mr-2 search">
</div>
</div>
</div>
104
482 ЧДТУ 262259 12 01 16
</div>
<div class="row courses overflow-y-auto">
<div class="col-7 h-100">
<div class="studied-courses">
<studied-courses [loading]="studiedCoursesLoading"
(onSelectedCoursesChange)="changeSelectedCourses($event)"
[courses]="courses"
[searchText]="searchText"></studied-courses>
</div>
</div>
<div class="col-5">
<course-creation (onCourseCreation)="onCourseCreation()"
(onCourseAdding)="selectedCourses.push($event)"
[selectedSemester]="selectedSemester"
[courses]="courses"
>
</course-creation>
</div>
</div>
<div class="row">
<div class="col-12">
<div class="row align-items-center">
<div class="col-2">
<button type="button" class="btn btn-info btn-medium
ml-1" (click)="addCoursesForStudents(template)"
[disabled]="!selectedCourses.length
|| !selectedStudents.length">Призначити
</button>
</div>
<div class="col-2">
<select class="form-control"
[(ngModel)]="selectedCourseType">
<option *ngFor="let key of courseTypeKey"
[ngValue]="key">{{ courseType[key] }}</option>
</select>
</div>
<div class="col-2">
<label class="mr-auto ml-1 m-0">
<mat-slide-toggle
class="ml-1"
[checked]="isCoursesTableMaster"
[(ngModel)]="isCoursesTableMaster"
(change)="changeMasterTable($event.checked)">
{{ isCoursesTableMaster ? 'За студентами' : 'За
предметом' }}
</mat-slide-toggle>
</label>
</div>
<div class="col-2">
<button type="button" class="btn btn-danger btn-medium
ml-1" (click)="deleteCourseForStudents()"
105
482 ЧДТУ 262259 12 01 17
[disabled]="!selectedStudents.length">Видалити
</button>
</div>
<div class="col-2" *ngIf="isCoursesTableMaster">
<button type="button" class="btn btn-outline-dark ml-і
type-change-btn__text-wrap" (click)="showCourseTypeEditDialog()"
[disabled]="!selectedCoursesForStudent.length">Змінити вид
предметів
</button>
</div>
<div class="col-2" *ngIf="isCoursesTableMaster &&
selectedStudents.length == 1">
<button type="button" class="btn btn-outline-dark ml-
і" (click)="showDiplomaSupplement()">Розпізнати додаток
</button>
</div>
<button class="btn btn-outline-secondary"
*ngIf="selectedStudents.length > 0 &&
selectedCoursesForStudent.length > 0 &&
isOnlyAcademicMobility()"
(click)="showAcademicMobilityEditDialog()">
Редагувати академмобільність
</button>
<div class="col-2" *ngIf="isCoursesTableMaster &&
selectedStudents.length >= 1">
<button type="button" class="btn btn-warning ml-і"
(click)="buildAcademicDifferenceExamReport()">Відомість з АР
</button>
</div>
</div>
</div>
</div>
<div class="row h-100">
<div class="col-2 h-100 pl-2 pr-0">
<div class="table-wrapper-2">
<table class="student-table" [ngClass]="{'border-red':
isCoursesTableMaster}">
<thead>
<tr class="students-for-groups-student-header">
<th class="students-for-groups-student-
header">Студенти</th>
</tr>
</thead>
<tbody>
<tr *ngFor="let studentDegree of students; let i =
index">
<div class="students-for-groups-student-row
clickable-pointer" (click)="studentDegree.selected
= !studentDegree.selected; selectCoursesByStudents()"
[class.selected-
student]="studentDegree.selected ||
106
482 ЧДТУ 262259 12 01 18
studentDegree.hasSelectedCoursesForStudent">
<td>{{ i + 1 }}</td>
<td>
<input type="checkbox"
[(ngModel)]="studentDegree.selected"
[disabled]="!isCoursesTableMaster
&& !studentDegree.hasSelectedCoursesForStudent">
</td>
<td>{{ studentDegree.student.surname }}
{{ studentDegree.student.name }}</td>
</div>
</tr>
</tbody>
</table>
</div>
</div>
<div class="col-10">
<table class="table table-striped table-sm fs-13"
[ngClass]="{'border-red': !isCoursesTableMaster}">
<thead>
<tr>
<th></th>
<th (click)="sortCoursesForStudentByName()"
class="clickable-pointer">Назва</th>
<th (click)="sortCoursesForStudentByType()"
class="clickable-pointer">Вид</th>
<th (click)="sortCoursesForStudentByControl()"
class="clickable-pointer">Контроль</th>
<th class="text-right">Години</th>
<th class="text-right">Кредити</th>
<th (click)="sortCoursesForStudentByIsSelective()"
class="clickable-pointer">Вибіркова</th>
<th>Викладач</th>
<th></th>
<tr>
</thead>
<tr *ngFor="let course of coursesForStudent">
<td class="text-center"><input type="checkbox"
#selected (change)="checkCourse($event.target.checked, course)"
[checked]="allRowsIsSelected"></td>
<td>{{ course.course.courseName.name }}</td>
<td>{{ courseType[course.courseType] }}</td>
<td>{{ course.course.knowledgeControl.name }}</td>
<td class="text-right">{{ course.course.hours }}</td>
<td class="text-
right">{{ course.course.credits }}</td>
<td class="text-center">
<label class="container">
<input type="checkbox"
[(ngModel)]="course.selective"
(change)="changeSelective($event.target.checked, course)">
107
482 ЧДТУ 262259 12 01 19
<div class="checkmark"></div>
</label>
</td>
<td (click)="changeTeacher(course)">
<button class="btn btn-outline-secondary">
{{ (course.teacher | nameWithInitials) ||
'Вибрати' }}
</button>
</td>
<td>
<button class="btn btn-outline-secondary"
(click)="showEditDialog(course)">
Редагувати предмет
</button>
</td>
</tr>
</table>
</div>
</div>
</div>
Лістинг Б.4 – Реалізація компоненту розпізнавання, порівняння та
перезарахування предметів з додатку до диплому ExtractFromDiplomaSupplement
import {Component, HostListener, OnInit} from '@angular/core';
import {StudentDegree} from '../../../models/StudentDegree';
import {CourseForStudentService} from '../../../services/course-
for-student.service';
import {BsModalRef} from 'ngx-bootstrap/modal';
import {CourseForIdentification} from
'../../../models/CourseForIdentification';
import {finalize} from 'rxjs/operators';
import {StudentGroup} from '../../../models/StudentGroup';
import {RecognisedCourse} from
'../../../models/RecognisedCourse';
import {MatchedCourse} from '../../../models/MatchedCourse';
import {CourseForStudentWrite} from '../confirm-
selected/CourseForStudentWrite';
import {CourseType} from '../../../models/course-type.enum';
import {Utils} from '../../shared/utils';
import {Course} from '../../../models/Course';
import {CourseName} from '../../../models/CourseName';
import { Subject } from 'rxjs';
import {KnowledgeControl} from
'../../../models/KnowlegeControl';
@Component({
selector: 'extract-from-diploma-supplement',
templateUrl: './extract-from-diploma-
supplement.component.html',
108
482 ЧДТУ 262259 12 01 20
styleUrls: ['./extract-from-diploma-
supplement.component.scss']
})
export class ExtractFromDiplomaSupplementComponent implements
OnInit {
HOURS_PER_CREDIT = 30;
selectedStudent: StudentDegree;
isResponseReceived: boolean = false;
isPictureScaled: boolean = false;
imgSrc: string | ArrayBuffer | null = null;
uploadedFile: File | null = null;
generalReceivedCourses: CourseForIdentification[] = [];
selectedReceivedCourses: CourseForIdentification[] = [];
generalConvertedCourses: MatchedCourse[] = [];
receivedCourses: CourseForIdentification[] = [];
receivedRecognisedCourses: RecognisedCourse[] = [];
isEditing: boolean = false;
isReceiving: boolean = false;
isRecognizing: boolean = false;
isRecognized: boolean = false;
specializationGroups: StudentGroup[];
selectedGroup: StudentGroup;
onClose: Subject<any> = new Subject();
knowledgeControls = [
{id: 1, name: 'іспит'},
{id: 2, name: 'залік'},
{id: 3, name: 'курсова робота'}];
constructor(private courseForStudentService:
CourseForStudentService, public bsModalRef: BsModalRef) {
}
ngOnInit() {
this.selectedGroup = this.specializationGroups[0];
}
@HostListener('window:paste', ['$event'])
onPaste(event: ClipboardEvent) {
const clipboardData = event.clipboardData;
if (!clipboardData) {
return;
}
const items = clipboardData.items;
for (let i = 0; i < items.length; i++) {
const item = items[i];
if (item.type.startsWith('image')) {
const file = item.getAsFile();
if (file) {
this.uploadedFile = file;
this.readFile(file);
}
109
482 ЧДТУ 262259 12 01 21
}
}
}
onFileChange(event: any) {
const file: File = event.target.files[0];
if (file) {
this.uploadedFile = file;
this.readFile(file);
}
}
onDrop(event: DragEvent) {
event.preventDefault();
if (event.dataTransfer && event.dataTransfer.files.length >
0) {
const file = event.dataTransfer.files[0];
if (file.type.startsWith('image')) {
this.uploadedFile = file;
this.readFile(file);
}
}
}
changeEditMode() {
const editBtn = document.querySelector('.edit-btn') as
HTMLElement;
this.isEditing = !this.isEditing;
editBtn.style.backgroundImage = this.isEditing
? 'url("/assets/img/save.jpg")'
: 'url("/assets/img/edit.jpg")';
}
selectAllCourses(isSelect: boolean) {
this.generalReceivedCourses.forEach(course => {
course.selected = isSelect;
})
this.selectedReceivedCourses = isSelect ?
this.generalReceivedCourses : [];
}
onDragOver(event: DragEvent) {
event.preventDefault();
}
readFile(file: File) {
const reader = new FileReader();
reader.onload = () => {
this.imgSrc = reader.result;
};
reader.readAsDataURL(file);
110
482 ЧДТУ 262259 12 01 22
}
scalePicture() {
if (!this.isPictureScaled) {
this.isPictureScaled = true;
}
}
closePicture() {
this.isPictureScaled = false;
}
sendPictureToAPI() {
if (!this.uploadedFile) {
return;
}
this.isReceiving = true;
//
this.courseForStudentService.identifyWithGemini(this.uploadedFil
e)
this.courseForStudentService.identifyWithGeminiTest()
.pipe(
finalize(() => {
this.isReceiving = false;
})
)
.subscribe({
next: (response: CourseForIdentification[]) => {
this.receivedCourses = response;
const uniqueCourses =
this.receivedCourses.filter(newCourse =>
!this.generalReceivedCourses.some(existingCourse =>
existingCourse.courseName === newCourse.courseName
&&
existingCourse.knowledgeControl.id ===
newCourse.knowledgeControl.id
)
);
this.generalReceivedCourses.push(...uniqueCourses);
this.isResponseReceived = true;
},
error: (err) => {
}
});
}
onReceivedCourseSelected(checked: boolean, course:
CourseForIdentification) {
if (checked) {
111
482 ЧДТУ 262259 12 01 23
this.selectedReceivedCourses.push(course);
} else {
this.selectedReceivedCourses =
this.selectedReceivedCourses.filter(c => c !== course);
}
}
sendCoursesToAPI() {
this.isRecognizing = true;
const coursesUndefined = this.selectedReceivedCourses
.map(course => ({
name: course.courseName,
hours: course.hours,
credits: course.credits,
knowledgeControl: course.knowledgeControl,
points: course.points
}));
this.courseForStudentService.getMatchedCourses(coursesUndefined,
this.selectedGroup)
.pipe(
finalize(() => {
this.isRecognizing = false;
this.convertCoursesForIdentificationToMatchedCourse();
})
).subscribe({
next: (response: RecognisedCourse[]) => {
this.receivedRecognisedCourses = response;
this.isRecognized = true;
},
error: (err) => {
}
});
}
convertCoursesForIdentificationToMatchedCourse() {
this.generalReceivedCourses.forEach(course => {
if (course.selected) {
this.generalConvertedCourses.push(
{
id: 0,
name: course.courseName,
hours: course.hours,
credits: course.credits,
knowledgeControl: course.knowledgeControl,
fullMatch: false,
selected: false,
choosen: false,
blocked: false,
points: course.points
} as MatchedCourse
);
112
482 ЧДТУ 262259 12 01 24
}
});
}
blockSelectedMatchedCourse(selectedCourse: MatchedCourse,
planCourse: RecognisedCourse) {
selectedCourse.choosen = !selectedCourse.choosen;
const isSameCourse = (courseA: MatchedCourse, courseB:
MatchedCourse): boolean =>
courseA.name.trim() === courseB.name.trim() &&
courseA.knowledgeControl.id ===
courseB.knowledgeControl.id;
if (planCourse) {
planCourse.matchedCourses.forEach(matchedCourse => {
if (selectedCourse.choosen) {
matchedCourse.blocked = !isSameCourse(matchedCourse,
selectedCourse);
} else {
matchedCourse.blocked = false;
}
});
}
this.receivedRecognisedCourses.forEach(recognisedCourse => {
recognisedCourse.matchedCourses.forEach(matchedCourse => {
if (selectedCourse.choosen) {
if (isSameCourse(matchedCourse, selectedCourse) &&
!matchedCourse.choosen &&
matchedCourse !== selectedCourse) {
matchedCourse.blocked = true;
}
} else {
if (isSameCourse(matchedCourse, selectedCourse)) {
matchedCourse.blocked = false;
}
}
});
});
this.generalConvertedCourses.forEach(matchedCourse => {
if (selectedCourse.choosen) {
if (isSameCourse(matchedCourse, selectedCourse) &&
!matchedCourse.choosen) {
matchedCourse.blocked = true;
}
} else {
if (isSameCourse(matchedCourse, selectedCourse)) {
matchedCourse.blocked = false;
}
}
});
}
hasBlockedMatchedCourse(matchedCourse: MatchedCourse,
113
482 ЧДТУ 262259 12 01 25
planCourse: RecognisedCourse): boolean {
return matchedCourse.blocked ||
(planCourse.matchedCourses.some(c => c.blocked) &&
planCourse.matchedCourses.some(c => c.choosen));
}
hasChoosenMatchedCourse(matchedCourse: MatchedCourse[]):
boolean {
return matchedCourse.some(c => c.choosen);
}
saveCoursesAsCoursesForStudent() {
const courseForStudentList: CourseForStudentWrite[] = [];
this.receivedRecognisedCourses.forEach(recognisedCourse => {
if (recognisedCourse.matchedCourses.some(c => c.selected))
{
const selected = recognisedCourse.matchedCourses.find(c
=> c.selected);
const points: number | null = selected ?
(selected.points !== undefined ? selected.points : null) : null;
const courseForStudent = new
CourseForStudentWrite(recognisedCourse.course, null,
Utils.getEnumKeyByValue(CourseType,
CourseType.RECREDIT), false, points);
courseForStudentList.push(courseForStudent);
} else if (recognisedCourse.isAcademicDifference) {
const courseForStudent = new
CourseForStudentWrite(recognisedCourse.course, null,
Utils.getEnumKeyByValue(CourseType,
CourseType.ACADEMIC_DIFFERENCE), false, null);
courseForStudentList.push(courseForStudent);
}
});
this.generalConvertedCourses.forEach(matchedCourse => {
if (matchedCourse.selected) {
const course = new Course();
course.courseName = new CourseName();
course.courseName.name = matchedCourse.name;
course.semester = 1;
course.knowledgeControl =
Utils.getCreditKnowledgeControl();
course.hours = matchedCourse.hours;
course.credits = matchedCourse.credits;
course.hoursPerCredit = 30;
const courseForStudent = new
CourseForStudentWrite(course, null,
Utils.getEnumKeyByValue(CourseType,
CourseType.RECREDIT), true, matchedCourse.points);
courseForStudentList.push(courseForStudent);
}
})
114
482 ЧДТУ 262259 12 01 26
this.courseForStudentService.createCoursesForStudent(this.select
edStudent.id, courseForStudentList).subscribe({
next: (response) => {
this.onClose.next({ updated: true });
this.bsModalRef.hide();
},
error: (err) => {
}
});
}
blockMatchedCourseForRecognizedCourse(planCourse:
RecognisedCourse) {
const isSameCourse = (courseA: MatchedCourse, courseB:
MatchedCourse): boolean =>
courseA.name.trim() === courseB.name.trim() &&
courseA.knowledgeControl.id ===
courseB.knowledgeControl.id;
planCourse.matchedCourses.forEach(matchedCourse => {
if (planCourse.isAcademicDifference) {
matchedCourse.blocked = true;
} else {
const shouldStayBlocked =
this.receivedRecognisedCourses.some(recognisedCourse =>
recognisedCourse !== planCourse &&
recognisedCourse.matchedCourses.some(mc =>
isSameCourse(matchedCourse, mc) && mc.choosen)
);
matchedCourse.blocked = shouldStayBlocked;
}
}); }
getCreditsOfAcademicDifference(): number {
let credits = 0;
this.receivedRecognisedCourses.forEach(recognisedCourse => {
if (recognisedCourse.isAcademicDifference) {
credits += recognisedCourse.course.credits;
}
});
return credits;
}
getCreditsOfRecredit(): number {
let credits = 0;
this.receivedRecognisedCourses.forEach(recognisedCourse => {
recognisedCourse.matchedCourses.forEach(matchedCourse => {
if (matchedCourse.selected) {
credits += recognisedCourse.course.credits;
}
});
115
482 ЧДТУ 262259 12 01 27
});
return credits;
}
isSelectedCourseForRecreditOrAcademicDifference(): boolean {
return this.receivedRecognisedCourses.some(recognisedCourse
=>
recognisedCourse.matchedCourses.some(matchedCourse =>
matchedCourse.selected) ||
recognisedCourse.isAcademicDifference
) || this.generalConvertedCourses.some(matchedCourse =>
matchedCourse.selected);
}
onHoursChanged(course: CourseForIdentification) {
course.credits = parseFloat((course.hours /
this.HOURS_PER_CREDIT).toFixed(1));
}
onCreditsChanged(course: RecognisedCourse) {
course.course.hours = parseFloat((course.course.credits *
this.HOURS_PER_CREDIT).toFixed(1));
this.setZeroIdToCourse(course.course);
}
setZeroIdToCourse(course: Course) {
course.id = 0;
}
}
116
ДОДАТОК В
Інформаційна система університету. Клієнтська частина підсистеми роботи з
індивідуальними предметами
Інструкція користувачеві
482 ЧДТУ 262259 34 01
Листів 13
Розробник ________________ Різник О.М.
2026
482 ЧДТУ 262259 34 01 2
Для доступу до веб-інтерфейсу підсистеми, для початку користувач має
виконати вхід в систему. При відкритті веб-інтерфейсу підсистема, користувача
зустрічає вікно входу, де користувачу необхідно ввести свої облікові дані, для
отримання доступу до функціоналу в залежності від його ролі та привілегій.
Рисунок В.1 – Форма входу
Після входу в підсистему, користувачу у верхній панелі необхідно вибрати
пункт «Початок року», і у випадаючому списку обрати «Предмети для
студентів».
Рисунок В.2 – Головна сторінка інформаційної системи
118
482 ЧДТУ 262259 34 01 3
Після переходу, відображається веб-інтерфейс підсистеми для роботи з
індивідуальними предметами.
Рисунок В.3 – Веб-інтерфейс підсистеми
Для початку роботи, необхідно спочатку обрати групу, а потім - семестр.
Для цього зліва зверху у відповідних випадаючих списках користувач має обрати
групу, а потім і семестр, який група вже пройшла або проходить зараз. Після
вибору групи і семестру, в таблиці знизу висвітляться доступні предмети для
цього семестру, а також нижче під таблицею список студентів групи.
119
482 ЧДТУ 262259 34 01 4
Рисунок В.4 –Вибір групи та семестру
Далі, якщо користувач хоче призначити студенту або студентам предмети,
для початку він обирає зі списку студентів натиском на чекбокс, або на прізвище
студента. Також при виборі студентів, користувач може бачити справа в таблиці
всі індивідуальні предмети студента (якщо обрано лише одного), або спільні
предмети студентів (якщо обрано декілька студентів). Після цього, з таблиці
зверху, користувач має обрати предмети, які він хоче призначити, натиснувши
на чекбокс зліва від предмету. Після того як обрано предмети, у випадаючому
списку справа від кнопки «Призначити» потрібно вибрати вид предмету
(академічна різниця, перезарахування чи академічна мобільність), якщо вид за
замовчуванням не підходить. Послідовність вибору предметів та вибору виду є
довільною.
Рисунок В.5 – Вибір студентів
120
482 ЧДТУ 262259 34 01 5
Рисунок В.6 – Вибір предмету
Рисунок В.7 – Вибір виду предмету
Після вибору виду, і за умови що вибрано в студента, і предмети для
призначення, розблоковується кнопка «Призначити». При натисненні на кнопку
«Призначити», відкривається модальне вікно, де виводяться списки студентів,
предмети що будуть призначатись і дані про них. Після додаткової перевірки
обраних предметів та студентів, користувач може або підтвердити призначення,
або скасувати його для виправлення натиснувши на відповідні кнопки внизу
модального вікна.
121
482 ЧДТУ 262259 34 01 6
Рисунок В.8 – Модальне вікно призначення предметів
У випадку якщо буде призначатись предмет з видом «Академічна
мобільність», вікно призначення матиме альтернативний вигляд, з можливість
вписати дані академічної мобільності предмету, а також вказанням назви
університету. При введені назви університету також наявна функція підказок,
що дозволяє обрати університет зі списку, якщо він в ньому наявний. У випадку
якщо університету в списку не було, користувач може вручну заповнити поля, і
новий університет буде додано в базу даних. Також наявний чекбокс «Змінювати
всі дані для предметів одночасно», за допомогою якої дані академічної
мобільності одного предмету при введені дублюються для решти предметів зі
списку.
Рисунок В.9 – Альтернативний вигляд модального вікна призначення предметів
У випадку якщо предмету для призначення немає в таблиці, користувач
може окремо створити предмет, який потім відобразиться в таблиці вибору
122
482 ЧДТУ 262259 34 01 7
предметів. Для цього в верхній правій частині у формі «Створити предмет»
потрібно заповнити всі поля, і натиснути на кнопку «Створити».
Рисунок В.10 – Форма створення нового предмету
Для видалення призначених предметів, для початку потрібно обрати
студентів для яких користувач бажає видалити предмети. Після вибору, всі
наявні предмети студента (або спільні предмети для декількох вибраних), будуть
відображені в таблиці справа від списку студентів.
Рисунок В.11 – Вибір студентів
Після вибору студентів, в таблиці справа потрібно обрати бажані предмети
для видалення. Після вибору предметів, в панелі над предметами розблокується
кнопка «Видалити». Після її натиснення, відкривається модальне вікно з
виведеними списками вибраних студентів і предметів, і в низу вікна кнопки
підтвердження або скасування видалення.
123
8
482 ЧДТУ 262259 34 01 8
Рисунок В.12 – Вибір предметів для видалення та натиснення кнопки
«Видалити»
Рисунок В.13 – Модальне вікно видалення предметів
Також користувач може видалити предмети для студентів іншим
способом. Для цього, справа від випадаючого списку з видами предметів
потрібно перемкнути перемикач з режимі мастер-таблиці за студентами, на
мастер-таблицю за предметами. Після цього, контур уваги (червоне обведення
навколо блоку) перейди від блоку зі студентами до блоку з предметами, і в
таблиці будуть відображені всі індивідуальні предмети, що наявні в студентів
обраної групи.
124
482 ЧДТУ 262259 34 01 9
Рисунок В.14 – Перемикання мастер-таблиці
Рисунок В.15 – Виведення всіх індивідуальних предметів студентів
Далі в мастер-таблиці потрібно вибрати предмет який потрібно видалити.
В списку студентів, всі студенти що мають вибраний предмет (або якщо обрано
декілька предметів – мають одночасно всі вибрані предмети) будуть виділені
зеленим фоном. Далі користувач може обрати студента, який виділений зеленим
фоном, і обрати його. Після вибору предметів та студентів, користувач натискає
на кнопку «Видалити», і відкривається те ж модальне вікно, що і при першому
способі видалення.
125
482 ЧДТУ 262259 34 01 10
Рисунок В.16 – Вибір предметів та студентів
Для того щоб змінити вид предметів, потрібно знову вернутись до мастер-
таблиці за студентами. Потім потрібно вибрати студентів і їх індивідуальні
предмети, яким потрібно змінити вид. Потім, справа від кнопки «Видалити»,
буде розміщена кнопка «Змінити вид предметів». Після її натиснення,
відкриється модальне вікно зі списком обраних студентів та їх предметів, кнопки
підтвердження та скасування дії та панель з кнопками, де кожна кнопка
відповідає за один з видів предметів. Користувач може переглянути список
студентів та предметів, вибрати потрібний вид предметів та підтвердити, або
скасувати, дію.
Рисунок В.17 – Відкриття модального вікна зміни виду предметів
126
482 ЧДТУ 262259 34 01 11
Рисунок В.18 – Модальне вікно редагування виду предметів
Для редагування даних індивідуального предмету, користувачеві потрібно
вибрати студентів, і в таблиці предметів, в правій крайній комірці, навпроти
предмету натиснути на кнопку «Редагувати предмет». Після цього, користувачу
відкриється модальне вікно з формою. Для редагування даних предмету,
потрібно змінити інформацію у відповідних полях введення. Після редагування,
користувач може підтвердити або скасувати дію відповідними кнопками в
нижній частині модального вікна.
Рисунок В.19 – Натиснення кнопки «Редагувати предмет»
Рисунок В.20 – Модальне вікно редагування даних індивідуального предмету
127
482 ЧДТУ 262259 34 01 12
Також, у випадку якщо буде обрано предмети лише виду «академічна
мобільність», користувач може редагувати дані академічної мобільності
предмету, натиснувши на кнопку «Редагувати академмобільність», яка
з’являється на панелі лише за умови, що всі обрані предмети мають вид
«академічна мобільність».
Рисунок В.21 – Відкриття модального вікна редагування академічної
мобільності
Після натиснення кнопки «Редагувати академмобільність», відкривається
модальне вікно зі списком студентів та таблицею, де записані вибрані предмети.
Також в таблиці є поля введення, за допомогою яких можна змінювати відповідні
дані академічної мобільності. Також наявний чекбокс «Змінювати всі дані для
предметів одночасно», у випадку якщо дані дублюються. В нижній частині
модального вікна також присутні кнопки підтвердження та скасування дії.
Рисунок В.22 – Модальне вікно редагування даних академічної мобільності
індивідуальних предметів
128
482 ЧДТУ 262259 34 01 13
Також користувач може сформувати відомість з академічною різницею.
Для цього йому потрібно обрати в списку студентів, потрібний семестр і
натиснути на кнопку «Відомість з АР». Після чого, буде сформовано файл з
розширенням .docx, і завантажено на пристрій.
Рисунок В.23 – Створення відомості з академічною різницею для обраних
студентів
129
ДОДАТОК Г
Інформаційна система університету. Клієнтська частина підсистеми роботи з
індивідуальними предметами
Графічні матеріали
482 ЧДТУ 262259 90 01
Листів 19
Розробник ________________ Різник О.М.
2026
482 ЧДТУ 262259 90 01 2
ЗМІСТ
Рис. Г.1 – Титульний слайд презентації……………….......………………….......….……………4
Рис. Г.2 – Актуальність теми………......…………………………………….……………………..4
Рис. Г.3 – Мета та завдання розробки……....……….....………………….………………………5
Рис. Г.4 – Методи проектування та конструювання……….....………….………………….……5
Рис. Г.5 – Опис отриманих результатів………………………………..……….…………..……...6
Рис. Г.6 – Особистий внесок автора………………………….………......………………………..6
Рис. Г.7 – Огляд аналогів (ч.1)..........................................………………..………………………..7
Рис. Г.8 – Огляд аналогів (ч.2)....………………………………………………...………………...7
Рис. Г.9 – Стек технологій.......………........……………………………………...………………...8
Рис. Г.10 – Постановка задачі. Первинні та детальні вимоги..............................………………..8
Рис. Г.11 – Вимоги замовника та розробника..............................................................................…9
Рис. Г.12 – Функціональна та нефункціональні вимоги.……………...…….……………............9
Рис. Г.13 – Діаграма прецедентів..........................………………………...……………………...10
Рис. Г.14 – Діаграма класів...................……………………………………...……………………10
Рис. Г.15 – Діаграма пакетів.......……………………………………………...…………………..11
Рис. Г.16 – Діаграма компонентів.…………………………………………...…………………...11
Рис. Г.17 – Діаграма розгортання.......……………………………………………...………….....12
Рис. Г.18 – Діаграма діяльності (ч.1).…………………………………………….………………12
Рис. Г.19 – Діаграма діяльності (ч.2)...........……………...………………………...…………….13
Рис. Г.20 – Діаграма діяльності (ч.3)...............…………………………………...………………13
Рис. Г.21 – Діаграма послідовності..........................………......………………………………….14
Рис. Г.22 – Діаграма комунікації…………………………………..........................……………...14
Рис. Г.23 – Діаграма скінченного автомата (ч.1)...............……….……………………………...15
Рис. Г.24 – Діаграма скінченного автомата (ч.2)....…………………….………………………..15
Рис. Г.25 – Діаграма скінченного автомата (ч.3)………………………………………………...16
131
482 ЧДТУ 262259 90 01 3
Рис. Г.26 – Діаграма скінченного автомата (ч.4)……………..………………………………….16
Рис. Г.27 – Функціональна схема.....……………………………………………………………...17
Рис. Г.28 – Логічна схема...........................……………………………………………………….17
Рис. Г.29 – Інтерфейс користувача………………………………………………….....................18
Рис. Г.30 – Висновки.......................………………………………………………….....................18
Рис. Г.31 – Дякую за увагу..............………………………………………………….....................19
132
482 ЧДТУ 262259 90 01 4
Рис. Г.1 – Титульний слайд презентації
Рис. Г.2 – Актуальність теми
133
482 ЧДТУ 262259 90 01 5
Рис. Г.3 – Мета та завдання розробки
Рис. Г.4 – Методи проектування та конструювання
134
482 ЧДТУ 262259 90 01 6
Рис. Г.5 – Опис отриманих результатів
Рис. Г.6 – Особистий внесок автора
135
482 ЧДТУ 262259 90 01 7
Рис. Г.7 – Огляд аналогів (ч.1)
Рис. Г.8 – Огляд аналогів (ч.2)
136
482 ЧДТУ 262259 90 01 8
Рис. Г.9 – Стек технологій
Рис. Г.10 – Постановка задачі. Первинні та детальні вимоги
137
482 ЧДТУ 262259 90 01 9
Рис. Г.11 – Вимоги замовника та розробника
Рис. Г.12 – Функціональні та нефункціональні вимоги
138
482 ЧДТУ 262259 90 01 10
Рис. Г.13 – Діаграма прецедентів
Рис. Г.14 – Діаграма класів
139
482 ЧДТУ 262259 90 01 11
Рис. Г.15 – Діаграма пакетів
Рис. Г.16 – Діаграма компонентів
140
482 ЧДТУ 262259 90 01 12
Рис. Г.17 – Діаграма розгортання
Рис. Г.18 – Діаграма діяльності (ч.1)
141
482 ЧДТУ 262259 90 01 13
Рис. Г.19 – Діаграма діяльності (ч.2)
Рис. Г.20 – Діаграма діяльності (ч.3)
142
482 ЧДТУ 262259 90 01 14
Рис. Г.21 – Діаграма послідовності
Рис. Г.22 – Діаграма комунікації
143
482 ЧДТУ 262259 90 01 15
Рис. Г.23 –Діаграма скінченного автомата (ч.1)
Рис. Г.24 – Діаграма скінченного автомата (ч.2)
144
482 ЧДТУ 262259 90 01 16
Рис. Г.25 – Діаграма скінченного автомата (ч.3)
Рис. Г.26 – Діаграма скінченного автомата (ч.4)
145
482 ЧДТУ 262259 90 01 17
Рис. Г.27 – Функціональна схема
Рис. Г.28 – Логічна схема
146
482 ЧДТУ 262259 90 01 18
Рис. Г.29 – Інтерфейс користувача
Рис. Г.30 – Висновки
147
482 ЧДТУ 262259 90 01 19
Рис. Г.31 – Дякую за увагу
148