Репозиторій ЧДТУ
Репозиторій ЧДТУ зберігає і дозволяє легкий і відкритий доступ до всіх видів цифрового контенту, включаючи текст, зображення, анімовані зображення, MPEG і набори даних
Дізнатися більше
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/9112| Назва: | Мобільний застосунок "Студент ЧДТУ": підсистема адміністрування |
| Автори: | Заспа, Григорій Олександрович Задорожний, Олександр Васильович |
| Ключові слова: | АВТОМАТИЗАЦІЯ ПРОЦЕСІВ;ІНФОРМАЦІЙНІ ТЕХНОЛОГІЇ;ВЕБ-СЕРВІС;ОБРОБКА ДАНИХ;РЕЄСТРАЦІЯ СТУДЕНТІВ;АВТОМАТИЧНА РОЗСИЛКА ЕЛЕКТРОННОЮ ПОШТОЮ;ВСТУП ДО УНІВЕРСИТЕТУ;AUTOMATION OF PROCESSES;INFORMATION TECHNOLOGY;WEB SERVICE;DATA PROCESSING;STUDENT REGISTRATION;AUTOMATIC EMAIL DISTRIBUTION;ADMISSION TO THE UNIVERSITY |
| Дата публікації: | 17-чер-2024 |
| Короткий огляд (реферат): | АНОТАЦІЯ
Задорожний О.В. – «Мобільний застосунок "Студент ЧДТУ": підсистема
адміністрування» кваліфікаційні робота бакалавра з спеціальності 121 -
«Інженерія програмного забезпечення » ЧДТУ, м.Черкаси 2024 рік.
Сучасний процес вищої освіти вимагає від університетів високої
ефективності в управлінні та автоматизації рутинних операцій для забезпечення
якісного та швидкого обслуговування студентів. Одним із ключових аспектів
оптимізації управління є впровадження сучасних інформаційних технологій,
особливо веб-сервісів.
Предметом даної бакалаврської роботи є розробка веб-сервісу для
адміністрації ВНЗ, метою якого є автоматизація процесу обробки даних про
прийом студентів. Зокрема, система здатна читати та обробляти CSV-файли, що
містять інформацію про заявників. Після обробки цих даних веб-сервіс
автоматично перевіряє їх відповідність базі університету та, якщо необхідно,
дозволяє додати нових студентів до бази даних.
Одним з важливих функціональних елементів є автоматична розсилка
електронною поштою листів з необхідною інформацією. Це не тільки спрощує
створення облікового запису для студентів, але й забезпечує високий рівень
безпеки та надійності.
Результатом роботи стане впровадження ефективної системи, яка
сприятиме підвищенню продуктивності роботи адміністрації університету та
надасть студентам швидке та якісне обслуговування на етапі їх вступу. ANNOTATION Zadorozhny O.V. – "Mobile application "Student ChDTU": administration subsystem" bachelor's qualification work on specialty 121 - "Software engineering" ChDTU, Cherkasy, 2024. The modern higher education process requires universities to be highly efficient in managing and automating routine operations to ensure high-quality and fast service to students. One of the key aspects of management optimization is the implementation of modern information technologies, especially web services. The subject of this bachelor's thesis is the development of a web service for university administration, which aims to automate the process of processing data on student admissions. In particular, the system is able to read and process CSV files containing information about applicants. After processing this data, the web service automatically checks whether it matches the university database and, if necessary, adds new students to the database. One of the essential functional elements is the automatic email sending of letters with the necessary information. This not only simplifies account creation for students, but also ensures a high level of security and reliability. The result of the work will be the implementation of an effective system that will help increase the productivity of the university administration and provide students with fast and high-quality service at the stage of their admission. |
| URI (Уніфікований ідентифікатор ресурсу): | https://er.chdtu.edu.ua/handle/ChSTU/9112 |
| Розташовується у зібраннях: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Кваліфікаційна робота бакалавра Задорожний Олександр Васильович.pdf Restricted Access | 8.72 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
бакалавра
на тему: Мобільний застосунок "Студент ЧДТУ": підсистема
адміністрування
Виконав: студент 4 курсу, групи ПЗ-2004
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Задорожний О.В.
(прізвище та ініціали)
Керівник Заспа Г. О.
(прізвище та ініціали)
Рецензент Стадник В. В.
(прізвище та ініціали)
Черкаси 2024
Черкаський державний технологічний університет__________________
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
____________________ Голуб С.В.
«___» _______________ 2024 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Задорожний Олександр Васильович
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Мобільний застосунок "Студент ЧДТУ": підсистема адміністрування
Керівник проекту (роботи) Заспа Григорій Олександрович
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « 26 » лютого
2024 року №60/04
2. Строк подання студентом проекту (роботи)
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління;
вимоги до проекту; календарне планування проекту; управління ризиками проекту; управління
ресурсами
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) Вступ;
Існуючі методи та засоби розв’язання поставлених завдань;
Впровадження результатів досліджень у практику проектування програмного забезпечення
інформаційних систем;
Розробка та тестування програмного забезпечення
Висновки;
Список використаних джерел;
Додатки.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту;
Слайд 1, Слайд 2, Слайд 3, Слайд 4, Слайд 5, Слайд 6, Слайд 7, Слайд 8, Слайд 9, Слайд 10,
Слайд 11, Слайд 12, Слайд 13, Слайд 14, Слайд 15, Слайд 16, Слайд 17, Слайд 18
6. Консультанти розділів роботи
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
7. Дата видачі завдання 02 грудня 2023 р.
КАЛЕНДАРНИЙ ПЛАН
Строк
виконання
№
Назва етапів випускної роботи етапів Примітки
п/п кваліфікаційної
роботи
1 Постановка задачі 05.12.2023 виконано
2 Підготовка завдання 13.12.2023 виконано
3 Погодження завдання 16.12.2023 виконано
4 Затвердження завдання 19.02.2024 виконано
Основна стадія
1 Підбір матеріалів 27.02.2024 виконано
2 Аналіз шляхів вирішення поставленої задачі 04.02.2024 виконано
3 Розрахунок основних параметрів роботи 10.03.2024 виконано
4 Вибір кінцевого варіанту проектного рішення 17.03.2024 виконано
5 Оформлення первісної редакції роботи 25.03.2024 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 31.04.2024 виконано
керівником
2 Оформлення пояснювальної записки роботи в 13.05.2024 виконано
кінцевій редакції
3 Попередній захист роботи 15.05.2024 виконано
4 Затвердження роботи 02.06.2024 виконано
5 Рецензування роботи 06.06.2024 виконано
6 Захист роботи 11.06.2024
Студент _____________________ Задорожний О.В.
(підпис) (прізвище та ініціали)
Керівник роботи _____________________ Заспа Г.О.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Задорожний О.В. – «Мобільний застосунок "Студент ЧДТУ": підсистема
адміністрування» кваліфікаційні робота бакалавра з спеціальності 121 -
«Інженерія програмного забезпечення » ЧДТУ, м.Черкаси 2024 рік.
Сучасний процес вищої освіти вимагає від університетів високої
ефективності в управлінні та автоматизації рутинних операцій для забезпечення
якісного та швидкого обслуговування студентів. Одним із ключових аспектів
оптимізації управління є впровадження сучасних інформаційних технологій,
особливо веб-сервісів.
Предметом даної бакалаврської роботи є розробка веб-сервісу для
адміністрації ВНЗ, метою якого є автоматизація процесу обробки даних про
прийом студентів. Зокрема, система здатна читати та обробляти CSV-файли, що
містять інформацію про заявників. Після обробки цих даних веб-сервіс
автоматично перевіряє їх відповідність базі університету та, якщо необхідно,
дозволяє додати нових студентів до бази даних.
Одним з важливих функціональних елементів є автоматична розсилка
електронною поштою листів з необхідною інформацією. Це не тільки спрощує
створення облікового запису для студентів, але й забезпечує високий рівень
безпеки та надійності.
Результатом роботи стане впровадження ефективної системи, яка
сприятиме підвищенню продуктивності роботи адміністрації університету та
надасть студентам швидке та якісне обслуговування на етапі їх вступу.
Ключові слова: АВТОМАТИЗАЦІЯ ПРОЦЕСІВ, ІНФОРМАЦІЙНІ
ТЕХНОЛОГІЇ, ВЕБ-СЕРВІС, ОБРОБКА ДАНИХ, РЕЄСТРАЦІЯ СТУДЕНТІВ,
АВТОМАТИЧНА РОЗСИЛКА ЕЛЕКТРОННОЮ ПОШТОЮ, ВСТУП ДО
УНІВЕРСИТЕТУ.
ANNOTATION
Zadorozhny O.V. – "Mobile application "Student ChDTU": administration
subsystem" bachelor's qualification work on specialty 121 - "Software engineering"
ChDTU, Cherkasy, 2024.
The modern higher education process requires universities to be highly efficient
in managing and automating routine operations to ensure high-quality and fast service
to students. One of the key aspects of management optimization is the implementation
of modern information technologies, especially web services.
The subject of this bachelor's thesis is the development of a web service for
university administration, which aims to automate the process of processing data on
student admissions. In particular, the system is able to read and process CSV files
containing information about applicants. After processing this data, the web service
automatically checks whether it matches the university database and, if necessary, adds
new students to the database.
One of the essential functional elements is the automatic email sending of letters
with the necessary information. This not only simplifies account creation for students,
but also ensures a high level of security and reliability.
The result of the work will be the implementation of an effective system that will
help increase the productivity of the university administration and provide students with
fast and high-quality service at the stage of their admission.
Keywords: AUTOMATION OF PROCESSES, INFORMATION
TECHNOLOGY, WEB SERVICE, DATA PROCESSING, STUDENT
REGISTRATION, AUTOMATIC EMAIL DISTRIBUTION, ADMISSION TO THE
UNIVERSITY.
ЗМІСТ
ВСТУП ............................................................................................................... 5
1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ .......................................................................................................... 7
1.1 Аналіз способів вирішення задачі ..................................................... 7
1.2 Аналіз існуючих аналогів ................................................................... 12
1.3 Специфікація вимог до розроблюваного веб-сервісу ...................... 17
2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ ............................................................................................................. 21
2.1 Моделювання предметної області ..................................................... 21
2.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області ............................................................ 21
2.1.2 Елементи моделювання предметної області ........................ 26
2.1.3 Робоча область моделювання ................................................. 28
2.2 Формування та аналіз вимог............................................................... 27
2.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги ................................................................... 27
2.2.2 Формування вимог за допомогою діаграми прецедентів ..... 28
2.3 Проектування логічної структури програмного комплексу ........... 30
2.3.1 Діаграми класів ........................................................................ 30
2.3.2 Діаграми пакетів ....................................................................... 33
2.4 Архітектурне проектування ............................................................... 35
2.4.1 Діаграма компонентів .............................................................. 35
ЧДТУ 242050.003ПЗ
Зм. Лист № документа Підпис Дата
Розроб.
Задорожний О. Мобільний застосунок "Студент ЧДТУ": Літ. Лист Листів
Керівник Заспа Г. О. 3 106
підсистема адміністрування Н
Н.контр. ФІТІС, кафедра ПЗАС,
Півень О .Б. Пояснювальна записка
Затв. Голуб С.В. ПЗ-2004
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання ....................................................................................... 36
2.5 Моделювання поведінки системи ..................................................... 36
2.5.1 Діаграма діяльності .................................................................. 36
2.5.2 Діаграма послідовності ........................................................... 37
2.5.3 Діаграма комунікації .............................................................. 38
2.5.4 Діаграма скінченного автомату ............................................. 41
3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ .... 43
3.1 Розробка програмного комплексу ..................................................... 43
3.1.1 Обґрунтування вибору засобів реалізації .............................. 43
3.1.2 Опис структурної (функціональної) схеми ........................... 47
3.1.3 Опис логічної схеми системи ................................................. 49
3.1.4 Розробка бази даних ................................................................ 52
3.1.5 Розробка інтерфейсу користувача .......................................... 54
3.1.6 Опис розробки програмних компонентів .............................. 57
3.2 Тестування системи ............................................................................ 59
3.2.1 Модульне тестування .............................................................. 59
3.2.2 Інтеграційне тестування .......................................................... 60
3.2.3 Системне тестування ............................................................... 61
3.2.4 Приймальне тестування........................................................... 63
3.3 Приклади впровадженого програмного комплексу......................... 65
ВИСНОВКИ ....................................................................................................... 66
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ......................................................... 68
Додаток А ........................................................................................................... 70
Додаток Б............................................................................................................ 72
Додаток В ........................................................................................................... 85
Додаток Г ........................................................................................................... 90
Ли ст
ЧДТУ. 242050.003ПЗ 4
Зм Лист № докум. Підпис Дата
ЧДТУ 242050 003ПЗ
ВСТУП
Актуальність теми. Актуальність визначається потребою у розробці
програмного забезпечення інформаційної системи для підсистеми
адміністрування мобільного застосунку «Студент ЧДТУ». В даний час інформація
про облікові записи студентів в мобільному застосунку «Студент ЧДТУ»
вводяться вручну; також вручну відсилаються електронні листи з логінами та
паролями. Це вимагає великих витрат часу адміністратора. Автоматизація даного
процесу зробить роботу адміністратора суттєво ефективнішою та зменшить
кількість помилок при виконанні задач адміністрування мобільного застосунку
університету.
Мета і завдання розробки. Метою роботи є розробка програмного
забезпечення інформаційної технології ефективного програмного забезпечення,
що забезпечує автоматизовану обробку даних студентів, перевірку їх
відповідності базі даних університету та можливість автоматичного створення
облікових записів нових студентів з інформуванням студентів про це. Цей проект
має на меті відповісти на потреби сучасної освіти шляхом підвищення
ефективності та результативності управління мобільним застосунком
університету.
Завдання:
1. Інформаційний пошук методів, засобів та методик побудови
програмного забезпечення інформаційних систем виконання поставлених завдань.
2. Проектування програмного забезпечення інформаційної системи для
підсистеми адміністрування мобільного застосунку «Студент ЧДТУ».
3. Конструювання програмного забезпечення інформаційної системи для
підсистеми адміністрування мобільного застосунку «Студент ЧДТУ».
4. Тестування програмного забезпечення інформаційної системи для
підсистеми адміністрування мобільного застосунку «Студент ЧДТУ».
5. Впровадження та супроводження програмного забезпечення
інформаційної системи для підсистеми адміністрування мобільного застосунку
«Студент ЧДТУ».
5
ЧДТУ 242050 003ПЗ
Об'єкт розробки. Об’єктом розробки є процес побудови програмного
забезпечення інформаційних систем для підсистеми адміністрування мобільного
застосунку «Студент ЧДТУ».
Предмет розробки. Предметом розробки є процес побудови програмного
забезпечення інформаційної системи для підсистеми адміністрування мобільного
застосунку «Студент ЧДТУ».
Методи розробки. Методи проектування та побудови базуються на
використанні сучасних інформаційних технологій та програмування, особливо
розробки програмного забезпечення з використанням веб-серверів та баз даних.
Процес розробки включає аналіз вимог, проектування архітектури, програмування
та тестування.
Опис отриманих результатів. Досягнуті результати полягають у створенні
функціонального програмного забезпечення, що дозволяє автоматизувати
процеси обробки та реєстрації студентів в мобільному застосунку студента
університету. Ця послуга відповідає потребам сучасної освіти у підвищенні
ефективності та швидкості управління прийомом студентів.
Практичне значення досягнутих результатів. Полягає у підвищенні
ефективності, продуктивності та надійності роботи адміністратора інформаційної
системи університету за рахунок використання розробленого програмного
забезпечення.
Особистий внесок автора полягає у комплексному дослідженні галузі,
аналізі потреб адміністратора інформаційної системи університету, а також
розробці та впровадженні ефективного програмного забезпечення для оптимізації
процесів обробки даних про вступ студентів. Автор брав активну участь у всіх
фазах проекту, від аналізу вимог до впровадження та тестування розробленого
веб-сервісу.
6
ЧДТУ 242050 003ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1 Аналіз способів вирішення задачі
Головна задача яку має вирішити дана робота це: даний CSV список із
іменами студентів та їх емейлами, потрібно кожного перевірити на наявність в базі
даних мобільного додатку, у разі відсутності додати студента до бази даних і
надіслати йому на емейл листа з логіном і паролем від мобільного додатку.
Зупинимося більш детально на різних аспектах складності виконання цього
завдання та необхідності його автоматизації.
По-перше, складність виконання цього завдання полягає в тому, що кожного
студента зі списку необхідно перевіряти на наявність у базі даних мобільного
додатку. Це може зайняти багато часу та ресурсів, особливо якщо список студентів
великий. Ви повинні уважно переглянути кожен запис у списку та запитати базу
даних, щоб перевірити, чи цей користувач уже зареєстрований. Якщо база даних
велика або доступ обмежений, це може сповільнити процес і збільшити
ймовірність помилок.
По-друге, процес додавання нових користувачів до бази даних і надсилання
електронних листів з іменем користувача та паролем є ще одним аспектом, який
потребує уваги. Створення кожного облікового запису та надсилання електронних
листів вручну може зайняти багато часу та бути схильним до таких помилок, як
неправильна інформація чи забуті паролі.
Тому необхідна автоматизація цього процесу. Розробивши сценарій або
програмне забезпечення, яке автоматизує ці завдання, ви можете значно скоротити
час, необхідний для виконання завдання, і уникнути помилок, пов’язаних з
ручною обробкою даних. Така автоматизація дозволяє заощадити час і сили, які
можна витратити на інші важливі завдання, і забезпечує швидку і точну обробку
інформації студента, що відображається на ефективності та продуктивності
робочого процесу.
Проаналізуємо різні способи автоматизації даного процесу.
7
ЧДТУ 242050 003ПЗ
Перший спосіб це створення веб-сервісу. Веб-сервіс – це програмне
забезпечення, що надає функціональність через мережу Інтернет. Основною його
функцією є обробка запитів, які надходять від клієнтських програм, і надання
відповідей на ці запити. Це може бути доступ до даних, виконання розрахунків,
взаємодія з іншими веб-сервісами та багато іншого [1].
Одним з ключових принципів веб-сервісів є їхня спроможність взаємодіяти
з різними типами клієнтських програм та платформ. Це досягається завдяки
використанню стандартних протоколів і форматів даних для обміну інформацією,
таких як HTTP, XML або JSON.
Одні з найпоширеніших типів веб-сервісів включають RESTful та SOAP.
RESTful веб-сервіси базуються на архітектурному стилі REST (Representational
State Transfer) і використовують HTTP-методи, такі як GET, POST, PUT та
DELETE, для взаємодії з ресурсами. SOAP (Simple Object Access Protocol) – це
протокол, що використовує XML для обміну повідомленнями між компонентами
програмного забезпечення через мережу.
Веб-сервіси використовуються для різноманітних завдань, включаючи
інтеграцію систем, обмін даними між різними додатками та створення
розподілених додатків, які працюють у різних середовищах. Вони є важливою
складовою сучасних програмних систем, дозволяючи розширювати
функціональність та підвищувати ефективність розробки програмного
забезпечення.
Переваги створення веб-сервісу для автоматизації цього завдання:
Доступ з будь-якого місця: доступ до веб-сервісу можна отримати з будь-
якого пристрою з доступом до Інтернету, що робить його зручним навіть в офісі.
Масштабованість: веб-сервіси можна легко масштабувати для роботи з
великими обсягами даних і великими робочими навантаженнями, одночасно
ефективними для великих обсягів даних студентів.
Недоліки створення веб-сервісів:
Складнісь розробки: створення веб-сервісу може бути складнішим,
особливо якщо його потрібно інтегрувати в існуючі університетські системи або
8
ЧДТУ 242050 003ПЗ
мобільний додаток.
Потенційні проблеми з безпекою: веб-сервіси загрожують безпеці даних, і
існує ймовірність хакерських атак або несанкціонованого доступу до інформації
студентів.
Залежність від Інтернету: використання веб-служби вимагає постійного
доступу до Інтернету, що може бути проблемою через обмежене підключення або
передчасні збої в мережі.
Порівняно з іншими варіантами, такими як створення мобільної програми
або використання локального програмного забезпечення, веб-служба може бути
більш гнучкою та корисною для користувачів. Однак можуть виникнути вищі
витрати та певні ризики безпеки та доступності.
Другий спосіб вирішення задачі це десктопна програма. Десктопна програма
– це програмне забезпечення, яке призначене для встановлення та виконання на
комп'ютері або ноутбуці. Вона запускається безпосередньо з робочого столу
(desktop) операційної системи та працює в локальному середовищі, не потребуючи
постійного підключення до Інтернету.
Десктопні програми можуть мати широкий спектр функціональності та
призначення. Вони можуть бути офісними програмами для обробки текстових
документів, електронних таблиць та презентацій, графічними редакторами,
програмами для роботи з базами даних, іграми, мультимедійними плеєрами, а
також спеціалізованими інструментами для розробки програмного забезпечення.
У сучасному світі десктопні програми все ще мають своє місце, особливо
для завдань, які вимагають великої продуктивності, повного доступу до ресурсів
комп'ютера або роботи в офлайн-режимі. Однак разом із зростанням популярності
веб-сервісів та хмарних додатків, десктопні програми все частіше поступаються
їм у виборі для багатьох завдань.
Десктопна програма може бути привабливим варіантом для автоматизації
цього завдання, оскільки вона працює безпосередньо на комп’ютері користувача.
Це означає, що користувач може отримати доступ до програми навіть за
9
ЧДТУ 242050 003ПЗ
відсутності підключення до інтернету, що зменшує залежність від мережі та
підвищує доступність. Настільна програма також може забезпечити більший
захист, оскільки дані обробляються локально на комп’ютері користувача, а не
передаються через мережу.
Використання мови сценаріїв, такої як Python, для автоматизації цього
завдання має декілька переваг, які роблять його швидшим і простішим в
порівнянні з іншими мовами програмування. Python відомий своєю простотою та
легкістю в освоєнні, що робить його ідеальним вибором для швидкого розв'язання
різноманітних завдань [2].
Однією з ключових переваг Python є наявність багатьох готових бібліотек
для обробки файлів CSV і роботи з базами даних. Наприклад, бібліотека pandas
надає широкий функціонал для роботи з даними у форматі CSV, включаючи
читання, запис та обробку даних у вигляді таблиць. Для взаємодії з базами даних
можна використовувати бібліотеки, такі як SQLAlchemy або psycopg2, які
забезпечують зручний доступ до реляційних баз даних, таких як PostgreSQL.
Крім того, Python є високорівневою мовою програмування, що дозволяє
зосередитися на вирішенні завдання, не витрачаючи багато часу на низькорівневі
деталі. Це дозволяє розробникам швидко реалізувати необхідні функції та
виконати завдання з мінімальними витратами часу та ресурсів. Більше того, Python
має велику активну спільноту розробників, що означає, що завжди є можливість
знайти допомогу або готовий код для вирішення конкретних завдань.
Google Apps Script – це інструмент, який також підходить для вирішення
задачі. Він дозволяє автоматизувати різноманітні завдання та розробляти додатки
безпосередньо в середовищі Google Workspace (раніше відомому як G Suite). Це
спеціальний інструмент для розробки сценаріїв, який базується на JavaScript, і
призначений для створення мікрододатків, розширень та інших корисних
інструментів для Google Apps. Він забезпечує можливості автоматизації обробки
даних, взаємодії з електронними таблицями та надсилання електронних
повідомлень. Цей скрипт може бути використаний для читання CSV файлу, в
10
ЧДТУ 242050 003ПЗ
якому зберігаються дані про студентів та їх електронні адреси.
Після читання CSV файлу, скрипт може здійснити з'єднання з базою даних
мобільного додатку. Він перевірить наявність кожного студента у цій базі даних.
Якщо студент відсутній у базі даних, скрипт може додати новий запис про
нього. Після цього, використовуючи вбудований сервіс електронної пошти,
Google Apps Script може створити та надіслати персоналізований лист кожному
новому студенту. Цей лист міститиме логін та пароль для доступу до мобільного
додатку.
Використання систем керування базами даних (СКБД), таких як MySQL або
PostgreSQL, для автоматизації обробки даних відкриває широкі можливості для
ефективного управління та аналізу великих обсягів інформації. Цей підхід може
бути особливо корисним у випадках, коли потрібно працювати зі складними та
структурованими наборами даних без необхідності створення власної веб-служби
чи десктопної програми [3].
Використання мови запитів SQL (Structured Query Language) у поєднанні зі
сценаріями на Python або іншій мові програмування дозволяє розробникам
створювати потужні та гнучкі інструменти для обробки даних. SQL забезпечує
можливість виконувати різноманітні операції з даними, включаючи пошук,
сортування, фільтрацію, об'єднання та агрегацію, що дозволяє швидко та
ефективно виконувати складні завдання аналізу даних.
Однією з головних переваг використання СКБД є їх здатність ефективно
зберігати та керувати великими обсягами даних. Вони використовують
оптимізовані структури даних та алгоритми, що дозволяють забезпечити швидкий
доступ до інформації незалежно від її обсягу.
Крім того, СКБД надають розширені можливості забезпечення безпеки
даних, включаючи механізми автентифікації, авторизації та шифрування, що
робить їх привабливим варіантом для обробки конфіденційної інформації.
З огляду на усі переваги і недоліки було прийнято рішення створювати веб-
11
ЧДТУ 242050 003ПЗ
сервіс.
1.2 Аналіз існуючих аналогів
На даний момент існує десктопна програма, яка виконує основні завдання,
пов'язані з обробкою даних студентів і автоматизацією адміністративних процесів
в університеті. Однак цей існуючий інструмент має свої обмеження та недоліки,
які вимагають розробки нового веб-сервісу.
1 Обмежена функціональність: за відгуками користувачів, функціонал
існуючої програми обмежений. Це дозволяє переглядати дані студентів лише по
одному, ускладнюючи процес обробки інформації та знижуючи продуктивність
адміністрації університету.
2 Незручний інтерфейс: інтерфейс існуючого додатку незручний для
користувачів, що спричиняє затримки та може призвести до помилок при введенні
даних. Це важливо при розробці нової веб-служби, спрямованої на покращення
взаємодії з користувачем.
3 Обмежені можливості редагування: існуюча програма не надає зручних
інструментів для редагування даних студентів. Це ускладнює оновлення
інформації та може призвести до неправильних або застарілих даних у системі.
4 Обмежена відправка листів: функціональність надсилання листів
обмежена, тому ви можете надсилати повідомлення лише одному студенту
одночасно. Це ускладнює широкомасштабну комунікацію з усім пулом заявників
і може потребувати значних зусиль.
Аналіз виконання ручної роботи без використання програмного
забезпечення показує, що такий підхід є неефективним, вимагає часу та ресурсів.
Ручне керування процесами прийому студентів призводить до значних затримок і
можливих помилок у введенні та обробці даних.
Враховуючи недоліки існуючої програми, новий веб-сервіс буде розроблено
з урахуванням сучасних стандартів та вимог користувачів. Функціонал розширено
для забезпечення зручності та оперативності. Нова веб-служба спробує вирішити
вищевказані проблеми та надасть користувачам потужний і простий у
використанні інструмент керування та обробки даних.
12
ЧДТУ 242050 003ПЗ
Рисунок 1.1 – Інтерфейс програми «Імпорт студентів»
Програмне забезпечення SendGrid
SendGrid – це платформа електронної пошти, спеціалізована на відправці
масових листів, тригерних повідомлень та іншої електронної комунікації для
підприємств. Вона надає інструменти для створення, відправлення та аналізу
електронних листів у великих обсягах. Заснована в 2009 році, SendGrid стала
однією з провідних платформ для електронної пошти, яка допомагає компаніям
будь-якого розміру досягти своїх цілей у сфері маркетингу та комунікацій. [4]
SendGrid частково підходить для виконання поставленої задачі, але
потребує додаткового налаштування та не є комплексним рішенням.
Як переваги SendGrid можна відмітити гнучкість завдяки якій SendGrid
дозволяє створювати шаблони листів з динамічними змінними, щоб підставити
ім'я студента, логін і пароль у текст листа. ще одна перевага це масштабованість
SendGrid, вона може обробляти великі обсяги розсилок, що робить його зручним
для роботи з великими списками студентів. Також SendGrid надає детальну
статистику про доставку листів, відкриття та переходи, що допоможе вам
відстежувати успішність розсилки.
Але програма має серйозні недоліки. Головний недолік це відсутність
інтеграції з базою даних. SendGrid не має вбудованої можливості підключатися до
нашої бази даних мобільного додатку. Нам потрібно буде написати код або
13
ЧДТУ 242050 003ПЗ
використовувати сторонній інструмент для імпорту списку студентів з CSV-файлу
в SendGrid. Крім того SendGrid пропонує безкоштовний план з обмеженнями на
кількість листів. Якщо вам потрібно розсилати більше листів, вам буде потрібно
перейти на платний план.
Рисунок 1.2 – Інтерфейс програми «SendGrid» [5]
Програмне забезпечення MailChimp
MailChimp – це веб-сервіс, який надає інструменти для електронної
розсилки, автоматизації маркетингу та аналітики. Основними функціями
MailChimp є створення, відстеження та оптимізація електронних розсилок
(розсилання листів електронної пошти), що дозволяє компаніям та іншим
користувачам ефективно взаємодіяти зі своїми аудиторіями через електронну
пошту.[6]
Однією з переваг MailChimp є його зручність у використанні та гнучкість,
що дозволяє швидко налаштувати розсилку без необхідності глибоких знань в
програмуванні чи базах даних.
Щодо поставленої задачі, MailChimp може бути використаний, але з
деякими обмеженнями. Він має можливість імпорту даних з CSV-файлу, що
14
ЧДТУ 242050 003ПЗ
означає, що список студентів з їх іменами та електронними адресами може бути
легко завантажений в систему. Після цього можна створити автоматизовану
кампанію, яка відправлятиме листи з логінами та паролями студентам, які не
знайдені у базі даних мобільного додатку. Також MailChimp надає можливість
налаштувати шаблони листів, щоб автоматично вставляти ім'я студента, логін і
пароль.
Однак важливо враховувати, що MailChimp в першу чергу призначений для
маркетингових розсилок і не є спеціалізованим інструментом для управління
базою даних користувачів мобільного додатку. Тому, хоча можна налаштувати
автоматизовані кампанії для надсилання листів з логінами та паролями, можуть
виникнути складнощі зі збереженням і оновленням цих даних у майбутньому,
якщо потрібно буде змінювати або додавати нових студентів.
Рисунок 1.3–Інтерфейс програми «MailChimp»[7]
15
ЧДТУ 242050 003ПЗ
Програмне забезпечення Constant Contact
Constant Contact – це платформа електронної комунікації, спеціалізована на
електронній розсилці, створенні і керуванні списками адресатів та аналізі
результатів розсилок. Вона надає інструменти для створення та відправлення
електронних листів, а також для автоматизації комунікації з клієнтами та
підписниками.[8]
Constant Contact може бути частково використана для виконання
поставленої задачі, але вона також потребує додаткового налаштування. Існують
переваги та недоліки використання Constant Contact для цієї задачі.
Однією з переваг Constant Contact є його інтуїтивний інтерфейс, який
дозволяє легко створювати розсилки та керувати списками адресатів. Крім того,
вона має можливість відправляти персоналізовані листи за допомогою шаблонів з
динамічними змінними, що дозволить вставити ім'я студента, логін і пароль у
текст листа. Також Constant Contact надає деяку аналітику щодо успішності
розсилок, таку як статистика відкриття листів та переходів за посиланнями.
Однак Constant Contact має свої недоліки. Перший недолік полягає в
обмеженні кількості листів, які можна відправити на безкоштовному плані. Якщо
вам потрібно відправляти багато листів, вам може доводитися перейти на платний
план. Крім того, аналітика Constant Contact може бути обмеженою у порівнянні з
іншими платформами, а також вона може не надавати досить детальної інформації
щодо доставки листів.
Найбільш значним обмеженням для цієї конкретної задачі є відсутність
можливості автоматизованого імпорту даних з CSV-файлу та перевірки наявності
студентів у базі даних мобільного додатку. Ви могли б знайти додаткові
інструменти або програми, що допоможуть вирішити це питання, але
безпосередньо Constant Contact не надає таких можливостей вбудовано. Тому для
виконання цієї задачі може бути потрібна інтеграція з іншими інструментами або
написання власного коду.
16
ЧДТУ 242050 003ПЗ
Рисунок 1.4 – Інтерфейс програми «Constant Contact»[9]
1.3 Специфікація вимог до розроблюваного веб-сервісу
Веб-сервіс, представляє собою веб-сайт для адміністрації університету який
забезпечує автоматичну обробку даних про студентів, перевірку їх відповідності
базі даних університету та можливість автоматичної реєстрації нових студентів.
Функціональні вимоги включають:
система повинна підтримувати авторизацію користувачів з різними
ролями, такими як адміністратори та користувачі з обмеженими правами;
користувачі повинні мати можливість завантажувати файли з
інформацією про студентів у різних форматах (наприклад, csv, excel);
система повинна перевіряти файли на наявність помилок, таких як
відсутні або некоректні дані, та повідомляти про це користувачів;
веб-сервіс повинен перевіряти наявність студентів у головній базі даних
та базі даних мобільного додатка, а також обробляти випадки, коли студентів
немає в базі або коли логін студента змінено;
17
ЧДТУ 242050 003ПЗ
система повинна формувати списки студентів з помилками та без
помилок на основі завантажених даних;
веб-сервіс повинен зберігати перевірені дані студентів у базі даних,
забезпечуючи при цьому їх актуальність та цілісність;
після обробки даних, система повинна надсилати повідомлення
студентам з інформацією про логін і пароль для авторизації в мобільному додатку.
Нефункціональні вимоги включають:
система повинна швидко обробляти великі об'єми даних, забезпечуючи
високу швидкість виконання запитів та операцій з файлами;
веб-сервіс має бути стійким до помилок та забезпечувати збереження
даних у разі збоїв або непередбачених ситуацій;
система повинна забезпечувати захист даних користувачів та студентів,
включаючи шифрування конфіденційних даних та захист від несанкціонованого
доступу;
веб-сервіс має бути здатним до масштабування для обробки збільшення
кількості користувачів та об'ємів даних без втрати продуктивності;
інтерфейс системи повинен бути інтуїтивно зрозумілим та зручним для
користувачів з різним рівнем технічної підготовки;
система повинна підтримувати роботу на різних платформах та
пристроях, включаючи мобільні додатки;
веб-сервіс повинен вести детальний журнал подій та помилок, а також
мати механізми для моніторингу стану системи та продуктивності.
Вимоги до інтерфейсу користувача:
– головний екран повинен містити зручну панель навігації з доступом до
основних функцій, таких як завантаження файлів, перегляд списків студентів,
налаштування профілю та вихід з системи;
– проста та зрозуміла форма авторизації з полями для введення логіну та
пароля, а також опцією відновлення пароля у випадку його втрати;
– зручний інтерфейс для завантаження файлів з інформацією про
студентів;
18
ЧДТУ 242050 003ПЗ
– інтерфейс повинен чітко відображати результати валідації даних,
включаючи повідомлення про помилки та успішні операції. Користувачам
повинні бути доступні детальні звіти про знайдені помилки з рекомендаціями
щодо їх виправлення;
– зручний перегляд списків студентів з можливістю сортування та
фільтрації за різними параметрами (наприклад, за спеціальністю, станом
перевірки тощо);
– інтерфейс повинен бути адаптивним і коректно відображатися на різних
пристроях та екранах різного розміру, включаючи мобільні телефони та
планшети;
– система повинна надавати реальні часові сповіщення про важливі події,
такі як завершення завантаження файлів або виявлення помилок.
19
ЧДТУ 242050 003ПЗ
Висновок до першого розділу
Перший розділ роботи присвячений аналізу існуючих методів та засобів
вирішення завдань автоматизації процесу перевірки та реєстрації студентів в базі
даних мобільного додатку. Основна задача, яку має вирішити дана робота, полягає
в автоматизації процесу перевірки студентів із наданого CSV списку на наявність
у базі даних мобільного додатку, додавання нових студентів у разі їх відсутності
та відправка їм електронних листів із логіном та паролем.
Розглянуті різні аспекти складності цього завдання підкреслюють
необхідність автоматизації для зменшення часу та ресурсів, необхідних для
виконання, а також для мінімізації помилок, пов’язаних із ручною обробкою
даних. Зокрема, аналіз показав, що ручна перевірка кожного студента та внесення
нових записів є вкрай трудомістким процесом, особливо при великих обсягах
даних.
Було проведено аналіз різних способів автоматизації цього процесу, таких
як створення веб-сервісу, розробка десктопної програми та використання скриптів
для автоматизації. Кожен з цих підходів має свої переваги та недоліки. Наприклад,
веб-сервіси забезпечують доступ з будь-якого місця та високу масштабованість,
але можуть бути складними у розробці. Десктопні програми не потребують
постійного підключення до Інтернету, але обмежують доступ до даних лише з
конкретного пристрою. Використання скриптів, таких як Python, є швидким і
ефективним рішенням, однак потребує додаткових навичок програмування.
Аналіз існуючих аналогів показав, що вже існують десктопні програми, які
частково вирішують поставлені завдання, але вони мають свої обмеження та не
забезпечують повної автоматизації процесу. Ручна обробка даних виявилася
неефективною та схильною до помилок, що підтверджує необхідність розробки
нового веб-сервісу.
На основі проведеного аналізу було визначено, що найкращим рішенням є
створення веб-сервісу, який забезпечить автоматичну обробку даних студентів,
перевірку їх наявності в базі даних університету та можливість автоматичної
реєстрації нових студентів.
20
ЧДТУ 242050 003ПЗ
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
2.1 Моделювання предметної області
Створення моделі предметної області є ключовим етапом розробки веб-
сервісу, призначеного для автоматичної обробки даних про студентів. Це
дозволить чітко окреслити логічну структуру системи, визначити її основні
елементи, їх взаємодію та функціональні можливості. На базі цієї 0моделі можна
буде ефективно планувати та реалізовувати веб-сервіс, мінімізуючи ризик
помилок та гарантуючи високу якість кінцевого продукту.
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області
Предметна область моделювання
У сучасному університетському середовищі ефективне управління даними
студентів має вирішальне значення для забезпечення якісної освіти та надання
різноманітних послуг студентам. У цьому контексті веб-сервіс, розроблений за
допомогою Angular, Java Spring і PostgreSQL, відіграє важливу роль у доступі,
обробці та управлінні даними студентів.
Управління даними студентів: система забезпечує повний життєвий цикл
даних студентів, починаючи від зберігання їхньої основної особистої інформації,
такої як ім’я та прізвище, адреса електронної пошти тощо. Дані студента
впорядковуються за різними критеріями, такими як групи, факультети,
спеціальності та інші характеристики та класифікації, які допомагають
відстежувати академічні досягнення та інші аспекти студентського життя.
Інтеграція з мобільним додатком: система взаємодіє з студентським
мобільним додатком і забезпечує передачу необхідних даних, таких як логіни та
паролі для авторизації користувачів у додатку. Це забезпечує студентам зручний і
безпечний доступ до системи через мобільні пристрої.
21
ЧДТУ 242050 003ПЗ
Обробити файли CSV: система дозволяє завантажувати та обробляти файли
CSV, що містять інформацію про студента. Після завантаження файлів система
аналізує їх, перевіряє наявність студентів у базі та додає нових студентів у разі їх
відсутності.
Комунікація зі студентами: ця функція дозволяє взаємодіяти зі студентами,
надсилаючи повідомлення на їхню електронну адресу. Особливо важливо
надсилати листи з логінами та паролями для доступу до мобільного додатку для
забезпечення зручності та безпеки користування системою студентами.
Предметна область моделювання для цього веб-сервісу охоплює широкий
спектр функцій, пов’язаних із керуванням даними студентів, авторизацією
користувачів, інтеграцією з мобільним додатком і обробкою вхідних файлів CSV.
Ефективне впровадження цієї теми допоможе забезпечити зручний та ефективний
доступ до інформації для всіх зацікавлених сторін університетської спільноти.
Модель предметної області для системи управління студентськими даними
в університетському середовищі складається з наступних сутностей:
1 студент (Student):
– ім'я (first_name): рядок – ім'я студента;
– прізвище (last_name): рядок – прізвище студента;
– електронна адреса (email): рядок – адреса електронної пошти студента;
– група (group): рядок – назва групи, до якої належить студент;
– статус (status): рядок – стан активності студента (активний, неактивний);
– дата реєстрації (registration_date): дата і час – дата реєстрації студента в
системі.
2 Користувач (User):
– ім'я користувача (username): рядок – ім'я користувача для авторизації;
– пароль (password): рядок – захешований пароль користувача;
– роль (role): рядок – роль користувача в системі (адміністратор, викладач,
студент);
– статус (status): рядок – стан активності облікового запису користувача
(активний, неактивний).
22
ЧДТУ 242050 003ПЗ
Система пропонує такі функції, управління студентами, користувачами,
інтеграцію з мобільним додатком, обробку CSV-файлів та комунікацію зі
студентами. Ці функції дозволяють додавати, редагувати та видаляти дані
студентів, керувати правами доступу користувачів, обмінюватися даними з
мобільним додатком, завантажувати та аналізувати CSV-файли з інформацією про
студентів та взаємодіяти зі студентами через електронну пошту.
У моделі описана бізнес-логіка, яка включає в себе перевірку прав доступу
користувачів, валідацію введених даних та спостереження за подіями системи для
забезпечення безпеки даних. Ця логіка гарантує правильне функціонування
системи та захищеність студентських даних.
Ця модель являє собою детальний опис сутностей, функціональності та
бізнес-логіки веб-сервісу, який може бути використаний для подальшої розробки
та реалізації системи управління студентськими даними в університетському
середовищі.
Рисунок 2.1 – Модель предметної області підсистеми адміністрування
представлена діаграмою класів
23
ЧДТУ 242050 003ПЗ
Словник предметної області
Адміністратор - користувач, який має права на управління системою,
зокрема на додавання, редагування та видалення даних студентів, а також на
контроль за процесом обробки даних.
Веб-сервіс - програмне забезпечення, що забезпечує обробку запитів від
клієнтів через мережу Інтернет. У даному проекті веб-сервіс обробляє дані
студентів, перевіряє їх у базі даних та реєструє нових студентів.
Дані студента - інформація про студентів, включаючи їхні імена, прізвища,
електронні адреси, логіни та інші ідентифікаційні дані.
CSV-файл - структура, що зберігає дані в електронному вигляді.
Користувач - особа, що взаємодіє із системою, зокрема адміністратор,
відповідальний за обробку даних студентів.
Модуль - окрема функціональна частина програмного забезпечення, яка
виконує певну задачу. Наприклад, модуль авторизації, модуль обробки файлу,
модуль збереження даних студентів тощо.
База даних - організована колекція даних, яка зберігає інформацію про
студентів та інші елементи, необхідні для функціонування системи. У даному
проекті використовується PostgreSQL.
Мобільний застосунок - програмне забезпечення, що встановлюється на
мобільні пристрої студентів і використовується для взаємодії з університетськими
системами. У даному проекті мобільний додаток перевіряє наявність студентів у
базі даних та надає їм доступ до системи.
Сервер - комп'ютерна система, яка обробляє запити та надає ресурси або
послуги іншим комп'ютерам (клієнтам). У даному проекті використовуються
сервер мобільного додатка та сервер deanoffice.
2.1.2 Елементи моделювання предметної області.
Елементи моделювання предметної області визначають фундаментальні
поняття, об’єкти та зв’язки, які складають систему. Ці елементи допомагають
зрозуміти та описати структуру та функціональність системи, а також визначити
24
ЧДТУ 242050 003ПЗ
спосіб взаємодії її компонентів. У контексті даної роботи елементи моделювання
предметної області включають різноманітні об’єкти та сервіси, які відображають
основні аспекти обробки даних про студентів, роботу з базою даних мобільного
додатку, обробку файлів CSV та взаємодію з користувачами через
користувальницькі інтерфейси. Детальне вивчення цих елементів допоможе
зрозуміти архітектуру і функціональність розглянутої в даній роботі системи.
Студенти представлені як основний об’єкт даних. Інформація про студентів
міститься у формі файлу CSV, який містить їхні імена та електронні адреси. Кожен
студент має унікальний ідентифікатор, який можна використовувати для
ідентифікації та відстеження його даних. Інформація про студента є важливою для
подальшої обробки і для перевірки наявності в базі даних мобільного додатку та
розсилки електронних листів з логінами та паролями.
База даних мобільного додатку є основною базою даних, у якій зберігаються
дані користувачів мобільних програм. Для кожного користувача, який є
студентом, зберігається його ID, логін, пароль та інші важливі дані. База даних
використовується для зберігання та керування даними користувачів, а також для
перевірки присутності студентів у системі.
Файл CSV є джерелом вхідних даних для системи. Він містить інформацію
про студента, яка потім імпортується для подальшої обробки. Цей файл може бути
завантажений користувачем через інтерфейс користувача, щоб дозволити системі
перевіряти та додавати нових студентів до бази даних.
Служба перевірки присутності бази даних використовується для перевірки
наявності студента в базі даних мобільного додатку. Він перевіряє, чи існує запис
із іменем та електронною адресою студента.
Функція додавання студентів використовується для додавання нового
студента до бази даних мобільного додатку, якщо студента немає в базі даних.
Додається новий запис, що містить інформацію про студента.
Сервіс для відправки листа відповідає за відправку листа на електронну
адресу студента за допомогою логіна та пароля з мобільного додатку. Він створює
25
ЧДТУ 242050 003ПЗ
та надсилає електронний лист із важливою інформацією для студента.
Інтерфейси користувача реалізовано за допомогою Angular і взаємодіє з
користувачем. Цей інтерфейс надає можливість завантажувати файл CSV,
переглядати статус операцій і отримувати повідомлення про результати обробки
даних.
2.1.3 Робоча область моделювання
Коли користувач заходить на веб-сервіс, він спочатку переходить на
сторінку авторизації, де він вводить свої облікові дані (логін та пароль). Після
успішної авторизації він потрапляє на головну сторінку веб-сервісу.
Він обирає функцію завантаження файлу та натискає на відповідну кнопку.
Після цього він вибирає файл зі списком студентів на своєму пристрої та натискає
кнопку "Завантажити файл".
Після завантаження файлу веб-сервіс аналізує його та відображає список
студентів на екрані. Користувач може прокручувати список та переглядати
інформацію про кожного студента.
Користувач обирає студентів, яких він хоче додати до бази даних мобільного
додатку. Він позначає їх прапорцями.
Після вибору студентів користувач натискає кнопку "Додати до бази даних".
Веб-сервіс виконує процес додавання обраних студентів до бази даних мобільного
додатку.
Після додавання студентів до бази даних користувач переходить до функції
відправлення листів. Він обирає студентів, яким потрібно надіслати листи. Після
цього користувач натискає кнопку "Надіслати листи".
Веб-сервіс виконує процес відправлення листів до обраних студентів.
Користувач отримує підтвердження про відправку листів.
Таким чином, користувач за допомогою веб-сервісу може авторизуватися,
завантажити файл зі списком студентів, переглянути цей список, вибрати
студентів для додавання до бази даних, додати їх, вибрати студентів для
надсилання листів та відправити їм листи.
26
ЧДТУ 242050 003ПЗ
Рисунок 2.3 – Модель предметної області для підсистеми адміністрування
2.2 Формування та аналіз вимог
Аналіз вимог використовується для визначення потреб та умов, щодо
продукту, враховуючи можливі вимоги різних замовників.[10]
Аналіз вимог є дуже важливим етапом у розробці будь-якого проекту. Він
допомагає чітко сформулювати завдання, уникнути помилок та розробити
продукт, який відповідає очікуванням.
2.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
Вимоги до програмного забезпечення для автоматичної обробки даних
студентів, перевірки їх відповідності базі даних університету та можливості
автоматичної реєстрації нових студентів, включає визначення первинних та
детальних вимог, які наведені нижче:
– система повинна забезпечувати авторизацію обробки даних користувачів;
– користувачі повинні мати можливість завантажувати файли з
інформацією про студентів у форматі CSV;
– система повинна перевіряти файли на наявність помилок, таких як
відсутні або некоректні дані, та повідомляти про це користувачів;
27
ЧДТУ 242050 003ПЗ
– веб-сервіс повинен перевіряти наявність студентів у головній базі даних
та базі даних мобільного додатка, а також обробляти випадки, коли студентів
немає в базі або коли логін студента змінено;
– система повинна добавляти дані про студентів до бази даних мобільного
застосунку;
– після обробки даних, система повинна надсилати листа студентам з
інформацією про логін і пароль для авторизації в мобільному додатку.
Первинні вимоги (замовника):
Функціональні вимоги: ПЗ повинно забезпечити засоби для обробки та
збереження даних про студентів до бази даних, також автоматизувати відправку
електронних листів студентам
Нефункціональні вимоги: ПЗ повинно взаємодіяти з іншим програмним
забезпеченням університету.
Детальні вимоги (розробника):
Функціональні вимоги: зчитування та обробка даних із CSV-файлу з
інформацією про студентів.
Перевірка та корекція формату даних у CSV-файлі.
Групування студентів із файлу на 5 списків:
– cписок існуючих студентів в базі мобільного застосунку;
– cписок студентів відсутніх в базі деканату;
– cписок відсутніх у базі мобільного додатку;
– cписок студентів чий логін змінився
– список тих, з даними яких виникла помилка.
Дії в залежності від того в якому студент списку:
– надсилаєм на email студенту його логін і пароль;
– виведення інформації;
– формує логін і пароль, додає до бази даних мобільного застосунку;
– оновлюємо дані бази даних;
– виведення інформації для їх аналізу користувачем.
2.2.2 Формування вимог за допомогою діаграми прецедентів
28
ЧДТУ 242050 003ПЗ
Діаграма прецедентів описує можливі дії користувачів та системи у веб-
додатку, що дозволяє завантажувати CSV-файл із списком студентів та їх
електронними адресами, перевіряти їх у базі даних мобільного додатку, і, в разі
необхідності, додавати нових студентів до бази даних та висилати їм листи з
реквізитами для авторизації. У програмі фігурують два учасники: користувач і
студент.
Користувач може увійти до системи, використовуючи свої облікові дані.
Завантажити CSV-файл із списком студентів та їх електронними адресами,
переглянути цей список, зберегти обраних студентів до бази даних мобільного
додатку, а також відправити вибраним студентам листи з реквізитами для
авторизації в мобільному додатку.
Студент може отримати листа з реквізитами для авторизації в мобільному
додатку.
Рисунок 2.4 – Діаграма прецедентів системи для підсистеми адміністрування
29
ЧДТУ 242050 003ПЗ
2.3 Проектування логічної структури програмного комплексу
Створення чіткої та логічної структури програмного комплексу є ключовим
етапом його розробки. Це передбачає визначення зв'язків та взаємодії між різними
компонентами програми, щоб вона могла ефективно виконувати свою функцію та
відповідати бізнес-потребам.
2.3.1 Діаграма класів
Рисунок 2.5 – Діаграма класів без атрибутів для підсистеми адміністрування
Діаграма класів – це структурна діаграма, яка відображає взаємозв'язки між
класами в системі програмування або програмному проекті. Кожен клас
представляє собою шаблон або формальний опис об'єкта, який має свої атрибути
(змінні) та методи (функції), що визначають його поведінку та характеристики.
Діаграма класів допомагає візуалізувати структуру програми, а також її
компоненти та зв'язки між ними.[11]
Діаграма включає в себе наступні класи:
StudentFromFileModel представляє модель студента, яка витягується з CSV-
файлу. Містить ім'я студента та його електронну адресу. Він має атрибути:
department (String) – відділ студента, specialty (String) – спеціальність студента,
30
ЧДТУ 242050 003ПЗ
fullName (String) – повне ім'я студента, personalEmail (String) – особиста
електронна адреса студента, corporateEmail (String) – корпоративна електронна
адреса студента, password (String) – пароль студента, microsoft365 (String) –
обліковий запис Microsoft 365, password365 (String) – пароль для Microsoft 365,
moodle (String) – обліковий запис Moodle, passwordMoodle (String) – пароль для
Moodle.
StudentWithoutErrorModel модель студента, яка не містить помилок при
обробці. Вона зберігає ім'я та електронну адресу студента, які успішно пройшли
перевірку. Має атрибути: name (String) – ім'я студента, surname (String) – прізвище
студента, patronymic (String) – по батькові студента, specialityCode (String) – код
спеціальності студента, username (String) – логін студента. Цей клас також має
метод setAllExtraProperties() (void) для встановлення додаткових властивостей
студента.
StudentWithErrorsModel цей клас представляє модель студента, у якого
виникли помилки під час обробки. Він містить інформацію про студента та опис
помилок, що виникли. Має атрибут errorMessage (String) – повідомлення про
помилку, пов'язане зі студентом.
AvailabilityListsInDbModel модель, яка представляє наявність списків
студентів у базі даних мобільного додатку. Зберігає інформацію про те, які списки
були завантажені та опрацьовані. Має атрибути: studentsExistInMobDb
(List<StudentWithoutErrorModel>) – список студентів, які існують у мобільній базі
даних, studentsNotExistInMainDb (List<StudentWithoutErrorModel>) – список
студентів, які не існують у основній базі даних, studentsExistOnlyInMainDb
(List<StudentWithoutErrorModel>) – список студентів, які існують лише в основній
базі даних, studentsLoginChanged (List<StudentWithoutErrorModel>) – список
студентів із зміненими логінами, studentsWithErrors
(List<StudentWithErrorsModel>) – список студентів із помилками. Цей клас також
31
ЧДТУ 242050 003ПЗ
має методи: addStudentsExistInMobDb(StudentWithoutErrorModel student) (void)
для додавання студента до списку студентів, які існують у мобільній базі даних,
addStudentsNotExistInMainDb(StudentWithoutErrorModel student) (void) для
додавання студента до списку студентів, які не існують у основній базі даних,
addStudentsExistOnlyInMainDb(StudentWithoutErrorModel student) (void) для
додавання студента до списку студентів, які існують лише в основній базі даних,
addStudentsLoginChanged(StudentWithoutErrorModel student) (void) для додавання
студента до списку студентів із зміненими логінами,
addStudentsWithErrors(StudentWithErrorsModel student) (void) для додавання
студента до списку студентів із помилками.
ProcessedStudentsModel цей клас представляє модель оброблених студентів,
які були додані до бази даних мобільного додатку. Містить інформацію про
студентів та результати їх обробки. Має атрибути: studentsWithoutError
(List<StudentWithoutErrorModel>) – список студентів без помилок,
studentsWithErrors (List<StudentWithErrorsModel>) – список студентів із
помилками. Взаємозв'язки між класами включають успадкування
StudentWithoutErrorModel та StudentWithErrorsModel від StudentFromFileModel,
що вказує на їх спільні властивості. AvailabilityListsInDbModel містить списки
об'єктів типу StudentWithoutErrorModel та StudentWithErrorsModel, а також методи
для додавання студентів до відповідних списків. ProcessedStudentsModel також
містить списки об'єктів типу StudentWithoutErrorModel та StudentWithErrorsModel.
User модель користувача системи. Містить інформацію про користувача,
таку як ім'я, електронну адресу, пароль та інші облікові дані. Дозволяє
авторизуватися в системі та виконувати дії, пов'язані з обробкою списків
студентів. Має атрибути: username (String) – ім'я користувача, password (String) –
пароль користувача, role (String) – роль користувача в системі.
32
ЧДТУ 242050 003ПЗ
Рисунок 2.6 – Діаграма класів з атрибутами для підсистеми адміністрування
2.3.2 Діаграма пакетів
Діаграма пакетів – це структурна діаграма, яка відображає організацію та
структуру компонентів системи в групи або пакети. Кожен пакет представляє
собою логічну частину системи, яка може містити класи, інші пакети або
компоненти. Діаграма пакетів допомагає візуалізувати структуру програми та
групувати пов'язані компоненти разом.[12]
База даних deanoffice цей пакет містить компоненти, пов'язані з базою даних
системи deanoffice, такі як класи для роботи з даними, схеми бази даних тощо.
33
ЧДТУ 242050 003ПЗ
Сервер deanoffice цей пакет містить компоненти, пов'язані з логікою та
обробкою запитів, які надходять до сервера deanoffice. Це різні сервіси,
контролери, ресурси API тощо.
База даних мобільного додатку цей пакет містить компоненти, пов'язані з
базою даних мобільного додатку, такі як класи для роботи з даними, схеми бази
даних тощо.
Сервер мобільного додатку цей пакет містить компоненти, які відповідають
за логіку і обробку запитів, що надходять від мобільного додатку. Сюди можуть
входити контролери, сервіси, ресурси API тощо.
Інтерфейс користувача цей пакет містить компоненти, пов'язані з
інтерфейсом користувача мобільного додатку, такі як класи відображення,
компоненти інтерфейсу тощо.
Рисунок 2.7 – Діаграма пакетів для підсистеми адміністрування
34
ЧДТУ 242050 003ПЗ
2.4 Архітектурне проектування
Архітектурне проектування полягає у визначенні основних структурних
характеристик системи, яку створюють, а саме: складу компонентів, способів їх
поєднання, та обмежень на їх взаємодію.[13]
Сучасні програмні системи являють собою досить складні поєднання різних
функцій, які реалізуються програмними модулями. Існують тисячі готових
програмних продуктів, які можна інтегрувати в будь-яку програмну систему для
виконання конкретних функцій. Примітивні функції можуть комбінуватися у
складніші композиції для реалізації загальних функцій, які, в свою чергу, можуть
бути об'єднані в нові композиції тощо.
2.4.1 Діаграма компонентів
Діаграма компонентів – це структурна діаграма, яка відображає
взаємозв'язки між компонентами програмної системи або додатку. Компонент в
цьому контексті – це самостійна частина програми, яка має визначену
функціональність та інтерфейс взаємодії з іншими компонентами.[14]
Користувач, використовуючи інтерфейс завантажує файл на сервер
мобільного застосунку. Сервер обробляє дані з файлу і повертає користувачу
відсортовані списки студентів, для обробки даних використовуються інформація
з баз даних мобільного додатку і бази даних deanoffice.
Рисунок 2.8 – Діаграма компонентів для підсистеми адміністрування
35
ЧДТУ 242050 003ПЗ
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Так як, розроблена система не являється самостійною, а представляє собою
додатковий функціонал до уже існуючих і розгорнутих систем, вважаю
недоцільним зосереджуватись на даному питанні.
2.5 Моделювання поведінки системи
Моделювання поведінки системи – це потужний інструмент, який дає
можливість глибоко дослідити та зрозуміти роботу програмного комплексу.
Завдяки цьому методу можна чітко уявити, як система взаємодіє з користувачами,
з іншими компонентами та з навколишнім середовищем.
2.5.1 Діаграма діяльності
Діаграма діяльності (або діаграма активності) – це один з видів структурних
діаграм UML (Unified Modeling Language), який використовується для
моделювання послідовності дій або процесів в програмному коді або бізнес-
процесах.
Процес починається з авторизації користувача. Користувач повинен увійти
в систему, щоб отримати доступ до функцій веб-сервісу. Після успішної
авторизації користувач завантажує файл з даними студентів на сервер мобільного
додатку. Якщо файл завантажено успішно, сервер мобільного додатку починає
його обробку.
Першим кроком обробки є перевірка наявності помилок у даних студента.
Після підтвердження наявності студента у головній базі даних, сервер мобільного
додатку перевіряє, чи існує студент у його власній базі даних. Якщо студент вже
є у базі, відбувається перевірка на зміну логіну студента. У випадку зміни логіну
або відсутності студента у базі, формуються відповідні списки: студенти, які вже
існують у базі, студенти, яких немає в базі deanoffice, студенти, яких немає у базі
мобільного додатку, студенти зі зміненими логінами та студенти з помилками у
даних (рис. 2.9).
36
ЧДТУ 242050 003ПЗ
Рисунок 2.9 – Діаграма діяльності веб-сервісу
37
ЧДТУ 242050 003ПЗ
Після формування списків користувач має можливість переглянути їх. Якщо
виявлено, що деякі студенти відсутні у базі мобільного додатку, користувач може
зберегти їх у базі даних, відправивши запит на сервер мобільного додатку. Сервер
додає нових студентів до бази даних і, за необхідності, надсилає листи студентам
з інформацією про логіни та паролі. Якщо користувач вирішує відправити листи
студентам, він також надсилає відповідний запит на сервер мобільного додатку,
який здійснює відправку повідомлень.
2.5.2 Діаграма послідовності
Діаграма послідовності – це один з видів діаграм UML, який
використовується для візуалізації послідовності взаємодії між об'єктами або
компонентами в системі. Ця діаграма дозволяє моделювати послідовність
повідомлень, які передаються між об'єктами або компонентами в певному порядку
часу для виконання певної функціональності або процесу.[16]
Користувач завантажує файл на сервер мобільного застосунку. Сервер
відправляє запит на сервер deanoffice для перевірки наявності студента у базі
даних deanoffice. Після цього сервер deanoffice відправляє запит до своєї бази
даних. Потім сервер мобільного застосунку отримує відповідь і відправляє запит
до своєї бази даних. Після цього користувач отримує відповідь від сервера. Крім
того, користувач може зберегти студентів до бази даних мобільного застосунку,
при цьому він відправляє запит із списком студентів до сервера, який у свою чергу
відправляє дані до бази. Крім того, користувач має можливість відправити
електронні листи вибраним студентам. При цьому він відправляє запит із списком
студентів до сервера, а сервер відправляє листи студентам.
38
ЧДТУ 242050 003ПЗ
Рисунок 2.10 – Діаграма послідовності для підсистеми адміністрування
2.5.3 Діаграма комунікації
Діаграма комунікації – це вид діаграми в мові моделювання UML, який
використовується для візуалізації взаємодії між об'єктами або компонентами в
системі. Ця діаграма є спеціальним випадком діаграми послідовності, яка
зорієнтована на показ взаємодії між об'єктами з акцентом на передачу повідомлень
інтерфейсами об'єктів.[17]
Користувач взаємодіє з сервером мобільного додатку. Він може надіслати
файл, відправити запит для додавання студентів до бази, відправити запит для
надсилання листів студентам, користувач може отримати список студентів.
Сервер мобільного застосунку взаємодіє з сервером deanoffice передаючи йому
список студентів для перевірки наявності у базі. Також сервер мобільного
застосунку комунікує із студентом відправляючи йому листа. Також сервер
взаємодіє з власною базою даних для перевірки наявності в ній даних про
студента, додавання нових даних про студента, логування листів. Сервер
deanoffice комунікує з власною базою даних для перевірки наявності студентів.
39
ЧДТУ 242050 003ПЗ
Рисунок 2.11 – Діаграма комунікації для підсистеми адміністрування
2.5.4 Діаграма скінченного автомату
Діаграма скінченного автомату (ДСА) – це вид діаграми, що моделює
поведінку системи з точки зору станів, переходів між цими станами та взаємодії
зовнішніх подій. Скінчений автомат може перебувати у певних станах, відповідно
до вхідних сигналів або подій, і здійснювати переходи між станами відповідно до
заданих правил.
Діаграма скінченного автомату складається з набору станів, символів подій,
переходів між станами та дій, що виконуються при кожному переході. Кожен стан
може мати вихідні події або дії, які спрацьовують при переході в цей стан.
Переходи між станами відбуваються відповідно до вхідних сигналів або подій.
40
ЧДТУ 242050 003ПЗ
Рисунок 2.12 – Діаграма скінченного автомату
41
ЧДТУ 242050 003ПЗ
Висновок до другого розділу
На початку було проведено моделювання предметної області, що включало
створення моделі предметної області та словника, визначення елементів
моделювання та робочої області. Це дозволило чітко визначити контекст та
ключові компоненти системи, що розробляється.
Наступним важливим кроком стало формування та аналіз вимог. Вимоги
було детально розділено на первинні та детальні, а також функціональні та
нефункціональні. Використання діаграм прецедентів дозволило наочно
представити взаємодію користувачів із системою, що сприяло глибшому
розумінню необхідних функцій та поведінки системи.
Проектування логічної структури програмного комплексу було здійснено за
допомогою діаграм класів та діаграм пакетів. Це дозволило чітко структурувати
об'єкти та їх взаємозв'язки, що є критично важливим для подальшої розробки та
підтримки системи.
Архітектурне проектування включало створення діаграми компонентів та
діаграми розгортання, що дозволило визначити, як різні частини системи будуть
взаємодіяти одна з одною та з апаратними засобами. Моделювання поведінки
системи за допомогою діаграм діяльності, послідовності, комунікації та
скінченного автомату дозволило детально описати динамічні аспекти
функціонування системи.
42
ЧДТУ 242050 003ПЗ
РОЗДІЛ 3. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1 Розробка програмного комплексу
Розробка програмного комплексу для веб-сервісу з автоматичної обробки
даних про студентів складається з кількох важливих етапів, які забезпечують
успішне виконання проекту. Ці етапи охоплюють проектування архітектури, вибір
технологій, реалізацію ключових функцій, тестування та впровадження системи.
3.1.1 Обґрунтування вибору засобів реалізації
Бекенд. Для написання бекенду була вибрана мова програмування Java, а
також фреймворк Java Spring. Вибір Java обґрунтовується її універсальністю,
високою продуктивністю та надійністю. Java є однією з найбільш поширених мов
програмування, яка використовується для розробки великих корпоративних
систем. Вона забезпечує високий рівень безпеки, має потужні вбудовані засоби
для роботи з пам'яттю та обробки багатопоточних завдань, що робить її ідеальною
для створення складних серверних застосунків. Крім того, Java має велику
спільноту розробників і широкий спектр бібліотек та інструментів, що значно
спрощує розробку і підтримку проектів.
Для реалізації бекенду був обраний фреймворк Java Spring, який є одним із
найстаріших і найстабільніших фреймворків для розробки веб-додатків. Завдяки
понад два десятиліття активного розвитку та підтримки від спільноти, він
забезпечує надійність і стабільність, що є критично важливим для будь-якого
проекту. Широка документація і велика кількість прикладів коду, доступних
онлайн, особливо корисні для академічних проектів, оскільки забезпечують
швидке вирішення можливих проблем.
Spring пропонує широкий набір інструментів і модулів, що дозволяє
вирішувати різні завдання, зокрема Spring Boot для спрощення конфігурації та
запуску додатків, Spring Data для простого доступу до баз даних, Spring Security
для реалізації безпеки та Spring MVC для створення веб-інтерфейсів і API. Це
забезпечує можливість швидко та ефективно реалізувати всі вимоги проекту, такі
43
ЧДТУ 242050 003ПЗ
як зчитування та обробка даних, робота з базами даних та інтеграція з іншими
системами.
Java Spring також розроблений з урахуванням високої продуктивності та
масштабованості. Це важливо для проектів, що мають потенціал зростання або
передбачають обробку великої кількості даних, оскільки використання Spring
гарантує ефективну роботу системи навіть при збільшенні навантаження.
Додатково, Spring добре інтегрується з іншими технологіями, такими як бази
даних (MySQL, PostgreSQL, MongoDB), хмарні сервіси (AWS, Azure) та інші
фреймворки. У моєму проекті, який вимагає інтеграції з сервером deanoffice, це
забезпечує зручний і надійний спосіб комунікації між різними системами.
Для мого проекту важливою є можливість створення RESTful сервісів для
обробки запитів. Spring MVC та Spring Boot надають зручні інструменти для
швидкої реалізації REST API, що значно спрощує процес обробки запитів. Велика
та активна спільнота розробників Spring означає, що будь-які питання чи
проблеми, які можуть виникнути під час розробки, можуть бути швидко вирішені
за допомогою доступних ресурсів, таких як форуми, блоги, офіційна документація
та інші.
Безпека є ще одним важливим аспектом, який забезпечується за допомогою
Spring Security – одного з найбільш потужних та гнучких інструментів для
забезпечення безпеки веб-додатків. Моя система, яка обробляє персональні дані
студентів, потребує надійного механізму захисту від несанкціонованого доступу,
що може бути легко реалізовано за допомогою Spring Security. Крім того, Spring
дозволяє легко масштабувати та розширювати систему, додаючи нові модулі та
функціональності без необхідності значних змін в існуючому коді. Це дуже
важливо для проекту, який може розвиватися та змінюватися з часом, враховуючи
потреби користувачів та нові вимоги.
Фронтенд. Для реалізації фронтенду був обраний фреймворк Angular. Цей
вибір обґрунтовується кількома вагомими причинами, що стосуються технічних
та практичних аспектів.
Angular є одним із найпотужніших і найпоширеніших фреймворків для
44
ЧДТУ 242050 003ПЗ
розробки односторінкових веб-додатків (SPA). Він розроблений і підтримується
Google, що гарантує стабільність і тривалу підтримку. Angular надає розробникам
комплексний інструментарій для створення динамічних і масштабованих веб-
додатків, забезпечуючи високу продуктивність і якість коду.
Однією з ключових особливостей Angular є двостороннє зв'язування даних
(two-way data binding). Це дозволяє автоматично синхронізувати модель даних і
представлення, що значно спрощує розробку інтерактивних інтерфейсів
користувача. Завдяки цьому, зміни у моделі даних миттєво відображаються в
інтерфейсі, і навпаки, що підвищує ефективність і зменшує кількість помилок при
написанні коду.
Angular також забезпечує модульність коду через використання
компонентного підходу. Кожен компонент в Angular є самодостатнім модулем,
який може бути легко повторно використаний в різних частинах додатка. Це
значно полегшує розробку, тестування та підтримку коду, а також сприяє його
масштабованості. Модульність Angular дозволяє легко розширювати
функціональність додатка, додаючи нові компоненти без необхідності значних
змін у вже існуючому коді.
Однією з важливих переваг Angular є потужний набір інструментів для
розробки та тестування. Angular CLI (Command Line Interface) забезпечує
автоматизацію багатьох рутинних завдань, таких як створення нових компонентів,
модулів, сервісів та проведення тестування. Це значно підвищує продуктивність
розробки та допомагає дотримуватися найкращих практик програмування. Крім
того, Angular має вбудовані засоби для юніт-тестування (Jasmine, Karma), що
сприяє написанню надійного і стабільного коду.
Angular забезпечує високу продуктивність і швидкість завантаження
додатків завдяки використанню таких технік, як Ahead-of-Time (AOT) компіляція
та Lazy Loading. AOT компіляція дозволяє компілювати код на етапі збірки, що
зменшує час завантаження додатка і покращує його продуктивність. Lazy Loading
забезпечує завантаження тільки тих модулів, які необхідні в даний момент, що
також сприяє швидшому завантаженню додатка та економії ресурсів.
45
ЧДТУ 242050 003ПЗ
Велика та активна спільнота розробників Angular є ще однією важливою
перевагою. Наявність численних ресурсів, таких як документація, форуми, блоги
та онлайн-курси, значно полегшує процес навчання і розв'язання проблем, які
можуть виникнути під час розробки. Крім того, регулярні оновлення і випуски
нових версій Angular забезпечують підтримку сучасних технологій і стандартів
веб-розробки.
Безпека також є важливим аспектом у виборі Angular для вашого проекту.
Angular надає вбудовані механізми захисту від поширених веб-загроз, таких як
XSS-атаки (Cross-Site Scripting) і CSRF-атаки (Cross-Site Request Forgery). Це
забезпечує додатковий рівень захисту для вашого веб-додатка, що особливо
важливо при роботі з персональними даними студентів.
Бази даних. Для реалізації бекенду була вибрана система управління
базами даних PostgreSQL. Вибір PostgreSQL обґрунтовується кількома вагомими
причинами, які стосуються її технічних можливостей і практичних аспектів.
PostgreSQL є однією з найпопулярніших і найпотужніших систем
управління базами даних з відкритим вихідним кодом. Вона відома своєю
стабільністю, надійністю та відповідністю стандартам SQL, що робить її
ідеальним вибором для будь-яких проектів, які вимагають високої продуктивності
та надійного зберігання даних. Однією з ключових переваг PostgreSQL є її
відповідність стандартам ACID (Atomicity, Consistency, Isolation, Durability), що
забезпечує високу надійність та цілісність даних, критично важливу для систем,
які обробляють персональні дані студентів.
PostgreSQL підтримує складні типи даних і розширені можливості обробки
запитів, що дозволяє ефективно працювати з великими обсягами даних і
виконувати складні аналітичні запити. Це особливо важливо для проектів, де
необхідна обробка великих наборів даних та виконання складних операцій, таких
як перевірка відповідності даних, групування та аналіз. Завдяки розширеним
можливостям роботи з JSON, PostgreSQL дозволяє легко інтегруватися з
сучасними веб-додатками, забезпечуючи зручне зберігання та обробку
напівструктурованих даних.
46
ЧДТУ 242050 003ПЗ
Однією з визначних рис PostgreSQL є її масштабованість та висока
продуктивність. PostgreSQL підтримує вертикальне і горизонтальне
масштабування, що дозволяє ефективно обробляти збільшення навантаження без
значного зниження продуктивності. Це забезпечує можливість розширення
системи в майбутньому, враховуючи можливе збільшення кількості користувачів
та обсягу даних. Крім того, PostgreSQL має потужні інструменти для оптимізації
продуктивності, такі як індекси, кешування та паралельне виконання запитів.
Безпека даних є ще одним важливим аспектом, який забезпечується
PostgreSQL. Вона надає розширені механізми контролю доступу, автентифікації
та шифрування даних, що дозволяє забезпечити високий рівень захисту даних від
несанкціонованого доступу. Це особливо важливо для систем, які обробляють
конфіденційні дані, такі як персональні дані студентів.
PostgreSQL також вирізняється активною спільнотою розробників та
великою кількістю доступних ресурсів, таких як документація, форуми, блоги та
інші. Це забезпечує швидке вирішення будь-яких проблем, які можуть виникнути
під час розробки та експлуатації системи, а також підтримку сучасних стандартів
і технологій.
3.1.2 Опис структурної (функціональної) схеми
Структурна схема – це графічне зображення, яке демонструє компоненти
системи та їх взаємозв'язки. Вона відображає структуру системи, розділяючи її на
окремі частини або підсистеми, та показує, як ці частини взаємодіють між собою
для виконання загальних функцій. Структурна схема використовується для
кращого розуміння організації системи та її компонентів.
Система адміністрування є центральним елементом, який координує роботу
всіх підсистем. Підсистема обробки файлу відповідає за отримання файлів з
даними студентів, їхню попередню обробку та перевірку на наявність помилок.
Цей компонент забезпечує коректність вхідних даних перед їх подальшою
обробкою.
Підсистема формування списків займається розподілом студентів на різні
категорії на основі перевірки даних. Вона формує декілька списків: студентів, які
47
ЧДТУ 242050 003ПЗ
вже є в базі мобільного додатку, студентів, відсутніх у базі deanoffice, студентів,
відсутніх у базі мобільного додатку, студентів, чий логін змінився, та студентів, з
даними яких виникла помилка. Цей етап є критично важливим для правильного
визначення статусу кожного студента та подальших дій щодо нього.
Підсистема збереження даних відповідає за додавання нових студентів до
бази даних мобільного додатку або оновлення інформації про існуючих студентів.
Вона забезпечує актуальність та повноту даних у базі, що є необхідним для
подальшого використання в системі.
Підсистема відправки повідомлень займається автоматичною відправкою
електронних листів студентам на основі сформованих списків. Вона надсилає
повідомлення про нові логіни та паролі, а також інформує студентів про будь-які
зміни або помилки в їхніх даних. Ця підсистема забезпечує оперативну
комунікацію між адміністрацією університету та студентами, що сприяє
ефективному управлінню та підтримці зворотного зв'язку.
Рисунок 3.1 – Структурна схема для підсистеми адміністрування
Функціональна схема демонструє складну систему для обробки
персональних даних студентів у межах веб-сервісу. Вона включає кілька
компонентів, кожен з яких виконує специфічні завдання, що сприяють
досягненню основної мети проекту – підвищення ефективності та якості
48
ЧДТУ 242050 003ПЗ
управління даними студентів.
Початкова точка процесу – це компонент "Відправка файлу", де користувач
завантажує CSV-файл з інформацією про студентів на сервер мобільного
застосунку. Далі файл передається до центрального елемента системи – "Системи
адміністрування", яка координує роботу всіх підсистем і забезпечує їх
взаємозв’язок.
Підсистема обробки файлу отримує завантажений файл і виконує перевірку
формату даних, видаляє можливі помилки та готує інформацію для подальшої
обробки. Після цього оброблені дані зберігаються в базі даних, що дозволяє
перейти до наступного етапу – формування списків.
Підсистема формування списків аналізує оброблені дані та розподіляє
студентів на п’ять різних списків: список існуючих студентів в базі мобільного
застосунку, список студентів, відсутніх в базі деканату, список студентів,
відсутніх у базі мобільного застосунку, список студентів, чий логін змінився, та
список студентів, з даними яких виникла помилка. Після формування списків дані
передаються на виведення для подальшого аналізу користувачем.
Наступна важлива частина системи – підсистема збереження даних, яка
відповідає за збереження всіх оброблених та перевірених даних у базі даних
мобільного застосунку. Це забезпечує доступ до актуальної інформації про
студентів і дозволяє її подальше використання.
Підсистема відправки повідомлень виконує функцію комунікації зі
студентами. Вона отримує списки студентів, яким необхідно надіслати
інформацію про логіни та паролі або повідомити про помилки в даних, і
відправляє відповідні електронні листи. Це забезпечує оперативність комунікації
та дозволяє студентам своєчасно отримувати важливу інформацію.
49
ЧДТУ 242050 003ПЗ
Рисунок 3.2 – Функціональна схема для підсистеми адміністрування
3.1.3 Опис логічної схеми системи
Структура фронтенду:
Кореневий компонент (app.component.ts, app.component.html) – це головний
компонент, який обгортає всю структуру вашого додатку.
Він містить основний шаблон HTML та код TypeScript для керування
головними функціями та поведінкою додатку.
Модуль додатка (app.module.ts):
Визначає основні модулі, компоненти, сервіси та інші функціональні блоки,
що використовуються в додатку.
Компоненти:
Вони розділені за функціональністю та відповідають за відображення
окремих частин додатку. Деякі з них:
credentials-file – компонент для відображення та обробки файлів з
обліковими даними студентів.
email-results-dialog – компонент, який відповідає за відображення
діалогового вікна для надсилання результатів по електронній пошті.
50
ЧДТУ 242050 003ПЗ
header – компонент, який відображає заголовок та інші елементи у верхній
частині сторінки.
Сервіси:
Вони відповідають за взаємодію з сервером, обробку даних та виконання
інших функцій, які не пов'язані з відображенням.
Наприклад, auth.service.ts відповідає за авторизацію користувачів, а
credentials-file.service.ts – за обробку файлів з обліковими даними студентів.
Інші файли:
app-routing.module.ts – визначає маршрутизацію в додатку.
main.ts – головний файл для запуску додатку.
styles.scss – файли зі стилями для додатку.
data/students-credentials-data.ts – файли для збереження даних про облікові
записи студентів.
environments – файли для налаштування середовища (наприклад, з'єднання з
сервером).
Рисунок 3.3 – Файли фронтенду
51
ЧДТУ 242050 003ПЗ
Бекенд мобільного додатку:
Контролери (Controllers):
AccountsController.java – відповідає за обробку HTTP-запитів, пов'язаних з
обліковими записами студентів.
Сервіси (Services):
AccountsService.java – містить бізнес-логіку для операцій з обліковими
записами студентів, такими як створення, оновлення та видалення.
Репозиторії (Repositories):
AccountRepository.java – відповідає за доступ до бази даних для операцій з
обліковими записами студентів.
EmailLogRepository.java – забезпечує доступ до бази даних для збереження
інформації про відправлені електронні листи.
Моделі (Models):
AvailabilityListsInDbModel.java – модель для представлення списків
доступності в базі даних.
EmailSendResultModel.java – модель для представлення результатів
відправлення електронних листів.
LetterLogsModel.java – модель для представлення журналу листів.
ProcessedStudentsModel.java – модель для представлення оброблених даних
про студентів.
StudentFromFileModel.java – модель для представлення даних про студентів,
отриманих з файлу.
StudentWithErrorsModel.java – модель для представлення даних про
студентів, у яких є помилки.
StudentWithoutErrorModel.java – модель для представлення даних про
студентів без помилок.
52
ЧДТУ 242050 003ПЗ
Рисунок 3.4 – Файли серверу мобільного додатку
3.1.4 Розробка бази даних
Фрагмент схеми бази даних deanoffice відображає чотири основні таблиці:
"student", "specialization", "student_degree" та "speciality". Всі ці таблиці пов'язані
між собою через ключі, що забезпечує логічну цілісність і взаємозв'язок даних у
базі даних.
Таблиця "student" містить інформацію про студентів. Вона включає поля для
зберігання ідентифікатора студента (id), його імені (name), по батькові
(patronimic), статі (sex), прізвища (surname), фактичної адреси (actual_address),
дати народження (birth_date), електронної пошти (email), інформації про батьків
(father_info, father_name, father_phone, mother_info, mother_name, mother_phone),
англійського варіанту імені (name_eng), приміток (notes), англійського варіанту по
53
ЧДТУ 242050 003ПЗ
батькові (patronimic_eng), URL фотографії (photo_url), адреси реєстрації
(registration_address), школи (school) та англійського варіанту прізвища
(surname_eng).
Таблиця "specialization" зберігає дані про спеціалізації, включаючи
ідентифікатор (id), назву (name), англійську назву (name_eng), код (code),
активність (active), дату видачі сертифіката (certificate_date), номер сертифіката
(certificate_number), оплату за заочне (payment_extramural) та денне навчання
(payment_fulltime), ідентифікатори ступеня (degree_id), кафедри (department_id),
факультету (faculty_id), спеціальності (speciality_id), керівника програми
(program_head_id), організації, що видала сертифікат (certificate_issued_by) та
англійську версію назви організації (certificate_issued_by_eng), назву спеціалізації
(specialization_name), англійську назву спеціалізації (specialization_name_eng),
нормативну кількість кредитів (normative_credits_number) та нормативний термін
навчання (normative_term_of_study).
Таблиця "student_degree" зберігає інформацію про ступені студентів,
включаючи ідентифікатор (id), активність (active), дату зарахування
(admission_date), дату наказу про зарахування (admission_order_date), номер
наказу про зарахування (admission_order_number), дату укладення контракту
(contract_date), номер контракту (contract_number), дату видачі диплома
(diploma_date), номер диплома (diploma_number), інформацію про оплату
(payment), дату попереднього диплома (previous_diploma_date), заклад, що видав
попередній диплом (previous_diploma_issued_by ,previous_diploma_issued_
by_eng), номер попереднього диплома (previous_diploma_number), тип
попереднього диплома (previous_diploma_type), дату протоколу (protocol_date),
назву дипломної роботи (thesis_name) та її англійський варіант (thesis_name_eng),
ідентифікатори спеціалізації (specialization_id) та студента (student_id).
Таблиця "speciality" містить дані про спеціальності, включаючи
ідентифікатор (id), назву (name), англійську назву (name_eng), активність (active),
код (code), галузь знань (field_of_study), код галузі знань (field_of_study_code),
англійську назву галузі знань (field_of_study_eng), родову назву (name_genitive),
54
ЧДТУ 242050 003ПЗ
ідентифікатор галузі знань (field_of_knowledge_id), міжнародну назву
(name_international), доступ до регульованої професії (regulated_profession_access),
англійський варіант доступу до регульованої професії (regulated_profession_
access_eng), сертифікати для вступу (entrance_certificates) та їх англійський варіант
(entrance_certificates_eng).
Взаємозв'язки між таблицями забезпечуються через зовнішні ключі.
Таблиця "student_degree" пов'язана з таблицями "student" та "specialization" через
поля "student_id" та "specialization_id", відповідно. Таблиця "specialization"
пов'язана з таблицею "speciality" через поле "speciality_id". Ці зв'язки забезпечують
цілісність даних та логічну структуру бази даних, дозволяючи зберігати і
отримувати інформацію про студентів, їхні спеціалізації та академічні ступені
ефективним та організованим чином.
Рисунок 3.6 – Схема бази даних deanoffice
55
ЧДТУ 242050 003ПЗ
Рисунок 3.7 – Схема бази даних мобільного застосунку
3.1.5 Розробка інтерфейсу користувача
Головною ціллю при розробці інтерфейсу користувача була зручність та
простота використання, тому був обраний простий і інформативний дезайн. У
верхньому меню навігації є вкладки для перегляду списків. Основна частина
інтерфейсу – це таблиця зі списком студентів. Кожен запис у таблиці має чекбокс
для вибору конкретних студентів для подальших дій, таких як надсилання листів.
Справа розміщені кнопки для завантаження CSV файлу зі списком студентів,
збереження змін у базі даних, відправлення листів вибраним студентам з логіном
і паролем, а також перегляду історії відправлених листів. У верхньому правому
56
ЧДТУ 242050 003ПЗ
куті знаходиться кнопка для виходу на сторінку авторизації.
Рисунок 3.7 – Форма авторизації
Рисунок 3.8 – Інтерфейс головної сторінки
3.1.6 Опис розробки програмних компонентів
Проект реалізує складну систему, що забезпечує автоматичну обробку
даних студентів, їх перевірку та автоматичну реєстрацію. У цьому розділі буде
детально описано розробку основних програмних компонентів, які складаються з
фронтенд і бекенд частин, а також зовнішніх сервісів та механізмів авторизації.
Фронтенд компоненти:
– Користувацький інтерфейс (UI), для реалізації UI використано сучасні
57
ЧДТУ 242050 003ПЗ
веб-технології, такі як HTML, SCSS та typescript, разом із фреймворками типу
React або Angular, що забезпечують зручний та інтерактивний інтерфейс.
Користувачі можуть завантажувати CSV-файли, переглядати списки студентів та
виконувати інші дії через інтуїтивно зрозумілий інтерфейс.
– Клієнтська логіка включає typescript-код, що відповідає за обробку подій
у браузері, взаємодію з сервером через API запити та відображення даних на UI.
Використовується бібліотека Axios для відправки HTTP запитів до серверу
мобільного додатку.
Бекенд компоненти:
– сервер мобільного додатку реалізований на Java Spring Boot, цей сервер
відповідає за обробку запитів від користувачів, перевірку даних, взаємодію з
базою даних та формування відповідей. Сервер мобільного додатку також
надсилає API-запити до бекенду deanoffice для отримання необхідних даних.
– сервер deanoffice також реалізований на Java Spring Boot, цей сервер
зберігає дані про студентів університету і надає API для доступу до цих даних.
Сервер deanoffice відповідає за перевірку існування студентів у своїй базі даних
та повернення відповідної інформації.
– база даних використовується PostgreSQL для зберігання інформації про
студентів. База даних мобільного додатку містить інформацію про зареєстрованих
студентів, їхні статуси, логіни та паролі. База даних deanoffice зберігає більш
детальну інформацію про всіх студентів університету.
– обробка даних з CSV-файлів включає модулі для зчитування та
перевірки даних із завантажених CSV-файлів. Ці модулі забезпечують перевірку
формату даних, виявлення помилок та формування списків студентів за різними
категоріями.
Взаємодія між бекендами:
– сервер мобільного додатку надсилає HTTP-запити до API серверу
deanoffice для перевірки існування студентів у базі даних університету. Ці запити
включають необхідні дані для ідентифікації студентів, а відповіді містять
інформацію про їхній статус у системі deanoffice.
58
ЧДТУ 242050 003ПЗ
– після отримання відповідей від серверу deanoffice, сервер мобільного
додатку обробляє ці дані, формує відповідні списки студентів та виконує
необхідні дії, такі як реєстрація нових студентів або оновлення інформації про
існуючих.
Електронна пошта:
– для надсилання електронних листів використовується модуль Spring
Boot Starter Mail, що дозволяє легко інтегрувати функціональність відправки
листів у додаток. Це включає налаштування SMTP сервера, шаблони листів та
логіку відправки.
– надсилання логінів та паролів: Після формування списків студентів
сервер мобільного додатку автоматично генерує логіни та паролі для нових
студентів і надсилає їх на електронну пошту студентам. Ця функція забезпечує
швидке та ефективне інформування студентів про їхні облікові дані.
Авторизація та аутентифікація:
– механізми авторизації реалізовані з використанням Spring Security, ці
механізми забезпечують перевірку ідентичності користувачів та контроль доступу
до ресурсів системи. Тільки авторизовані користувачі можуть взаємодіяти з
системою та виконувати адміністративні дії.: Angular, HTML, SCSS, typescript.
3.2 Тестування системи
Тестування програмного забезпечення – це процес оцінювання та перевірки
програмного продукту чи системи з метою виявлення дефектів та забезпечення
його якості. Тестування є невід'ємною частиною життєвого циклу розробки
програмного забезпечення і включає різні методи, техніки та підходи для
забезпечення того, що програмне забезпечення відповідає визначеним вимогам і
працює належним чином.
3.2.1 Модульне тестування
Модульне тестування – це тип тестування програмного забезпечення, який
фокусується на перевірці окремих компонентів або модулів програми незалежно
59
ЧДТУ 242050 003ПЗ
від інших частин системи. Модуль в цьому контексті може означати окрему
функцію, метод, процедуру або клас в програмному коді.
Для модульного тестування Java Spring Boot сервера я використовував
бібліотеку Junit, для тестування фронтенду я використовував бібліотеку Jasmine.
Таблиця 3.1
Модульне тестування
Компонент Результат
MobileApplication.java Успішний запуск
Application.java Успішний запуск
AccountsController.java Успішне завантаження залежностей
AccountsService.java Успішне завантаження залежностей
AccountRepository.java Успішне завантаження залежностей
AvailabilityListsInDbModel.java Успішне завантаження залежностей
app-routing.module.ts Успішне завантаження залежностей
app.component.html Успішне завантаження залежностей
app.component.ts Успішне завантаження залежностей
credentials-file.component.ts Успішне завантаження залежностей
app.module.ts Успішне завантаження залежностей
auth.service.ts Успішне завантаження залежностей
login.component.ts Успішне завантаження залежностей
credentials-file.service.ts Успішне завантаження залежностей
index.html Успішне завантаження залежностей
3.2.2 Інтеграційне тестування
Інтеграційне тестування – це тип тестування програмного забезпечення, що
фокусується на перевірці взаємодії між різними модулями або компонентами
системи. Мета інтеграційного тестування полягає в тому, щоб виявити дефекти,
60
ЧДТУ 242050 003ПЗ
які можуть виникнути в результаті інтеграції модулів, що вже пройшли модульне
тестування.
Таблиця 3.2
Інтеграційне тестування
Інтегровані Компоненти Результат
Index + App Успішне завантаження залежностей
login.component + auth.service Успішне завантаження залежностей
credentials-file.component.ts + Успішне завантаження залежностей
credentials-file.service.ts
AccountsController + AccountsService Успішне завантаження залежностей
+ AccountRepository
Результати інтеграційного тестування показують, що всі ключові
компоненти веб-сервісу успішно взаємодіють між собою та функціонують
відповідно до очікувань. Тестування було проведене для перевірки завантаження
залежностей і взаємодії між різними модулями системи. Нижче наведено
результати тестування:
Index і App успішно завантажили всі необхідні залежності, що забезпечує
стабільний запуск та роботу веб-додатка. Це свідчить про те, що основні
компоненти інтерфейсу користувача та серверної частини належним чином
інтегровані і можуть взаємодіяти без помилок.
Компонент login.component та сервіс auth.service також успішно
завантажили всі необхідні залежності. Це свідчить про коректну роботу механізму
аутентифікації користувачів. Інтерфейс для входу та відповідний сервіс для
перевірки даних користувача працюють стабільно, що є критично важливим для
забезпечення безпеки та контролю доступу до системи.
Компонент credentials-file.component.ts та сервіс credentials-file.service.ts
успішно завантажили всі необхідні залежності. Це вказує на те, що функціонал
завантаження та обробки файлів зі списками студентів працює коректно.
Компоненти, що відповідають за роботу з файлами, інтегровані належним чином,
що забезпечує безперебійний процес імпорту даних студентів.
61
ЧДТУ 242050 003ПЗ
Контролер AccountsController, сервіс AccountsService та репозиторій
AccountRepository також успішно завантажили всі необхідні залежності. Це
свідчить про коректну роботу всієї ланки, яка відповідає за управління обліковими
записами користувачів. Контролер, сервіс та репозиторій належним чином
взаємодіють між собою, забезпечуючи стабільну роботу функціоналу управління
акаунтами.
3.2.3 Системне тестування
Таблиця 3.3
Системне тестування
Функціональність/Сценарій Результат
Модуль авторизації Виконано успішно
Модуль обробки файлу Виконано успішно
Модуль збереження студентів до БД Виконано успішно
Модуль відправки електронних листів Виконано успішно
Модуль авторизації виконано успішно. Це свідчить про те, що система
коректно обробляє запити на вхід користувачів, перевіряє їхні облікові дані та
надає доступ до захищених ресурсів. Всі тести підтвердили, що процес
аутентифікації користувачів виконується без помилок, і жодних збоїв у цьому
модулі не виявлено.
Модуль обробки файлу також виконано успішно. Всі функції, пов’язані із
завантаженням та обробкою файлів зі списками студентів, працюють належним
чином. Модуль коректно обробляє різні формати файлів, виконує перевірку даних
та передає їх для подальшої обробки без втрат інформації чи помилок.
Модуль збереження студентів до бази даних виконано успішно. Система
успішно інтегрується з базою даних PostgreSQL, забезпечуючи надійне
збереження інформації про студентів. Всі операції додавання, оновлення та
62
ЧДТУ 242050 003ПЗ
видалення записів виконуються без збоїв, що підтверджує стабільну роботу
модуля.
Модуль відправки електронних листів виконано успішно. Використовуючи
Java Spring starter-mail, модуль коректно генерує та відправляє електронні листи з
логінами та паролями новим студентам. Всі тести підтвердили, що листи
відправляються у встановлений час та досягають адресатів без затримок або
помилок.
3.2.4 Приймальне тестування
Приймальне тестування – це вид тестування програмного забезпечення,
який проводиться для визначення, чи відповідає система визначеним вимогам та
критеріям прийняття. Основна мета приймального тестування полягає в тому, щоб
підтвердити, що програмний продукт готовий до використання замовником та
відповідає всім його очікуванням і вимогам.
Таблиця 3.4
Приймальне тестування
Ендпоінт Очікуваний результат
POST /process-students-credentials- 200
file
POST /save-students-credentials-data 200
POST /send-emails 200
POST /login 200
GET /search-by-name-and-code 200
Під час тестування методу POST /process-students-credentials-file перевірено
процес завантаження та обробки файлів зі студентськими обліковими даними.
Метод повернув статус 200, що свідчить про успішне виконання операції і
правильну обробку файлу.
63
ЧДТУ 242050 003ПЗ
Рисунок 3.9 – Результати запиту /process-students-credentials-file
Тестування методу POST /save-students-credentials-data було спрямоване на
перевірку збереження студентських даних у базі даних. Метод також повернув
статус 200, що означає успішне збереження даних у базі та підтвердження їх
коректності.
Рисунок 3.10 – Результати запиту /save-students-credentials-data
Під час тестування методу POST /send-emails перевірено функціональність
відправки електронних листів студентам. Метод повернув статус 200, що свідчить
про успішну інтеграцію з поштовим сервером та коректне відправлення
повідомлень.
Рисунок 3.10 – Результати запиту /send-emails
64
ЧДТУ 242050 003ПЗ
Метод POST /login перевірено для підтвердження правильності роботи
модуля авторизації. Метод повернув статус 200, що означає успішну авторизацію
користувачів із правильними обліковими даними.
Тестування методу GET /search-by-name-and-code мало на меті перевірку
можливості пошуку студентів за ім'ям та кодом. Метод повернув статус 200, що
вказує на успішне виконання запиту та коректне повернення даних відповідно до
запиту.
Таблиця 3.5
Приймальне тестування
№ Опис тесту Очікваний результат Фактичний результат Статус
1 POST /process- Повернено списоки Повернено списоки Пройдено
students- студентів студентів
credentials-file
2 POST /save- Дані студентів Дані студентів Пройдено
students- успішно збережено успішно збережено
credentials-data
3 POST /send- Електронні листи Електронні листи Пройдено
emails надіслано успішно надіслано успішно
4 POST /login Успішна авторизація Успішна авторизація Пройдено
користувача користувача
5 GET /search-by- Повернено результати Повернено Пройден
name-and-code пошуку студентів результати пошуку
студентів
3.3 Приклади впровадженого програмного комплексу
Впроваджено на хмарному сервері ЧДТУ. Доступно за адресою
maa.is.chdtu.edu.ua:4200. Розроблене серверне програмне забезпечення є частиною
існуючого серверного програмне забезпечення, яке виконує роль бекенда для
мобільного застосунку Студент ЧДТУ+. Клієнтське програмне забезпечення являє
собою окремий сайт; для доступу використовується веб-сервер nginx.
65
ЧДТУ 242050 003ПЗ
ВИСНОВКИ
Метою даної роботи було створення комплексного рішення, що забезпечить
автоматичну перевірку та реєстрацію студентів у мобільному додатку на основі
отриманих даних, знижуючи навантаження на адміністративний персонал та
мінімізуючи можливість помилок.
У першому розділі було проведено аналіз існуючих методів та засобів
розв'язання поставлених завдань. Це включало детальний розгляд способів
вирішення задачі, аналіз існуючих аналогів і вибір найбільш ефективного підходу
для автоматизації процесу перевірки та реєстрації студентів у мобільному
додатку.
У другому розділі описано процес впровадження результатів досліджень у
практику проектування програмного забезпечення інформаційних систем. Це
включало моделювання предметної області, де було створено модель предметної
області та словник, визначено елементи моделювання та робочу область.
Наступним етапом було формування та аналіз вимог до програмного
забезпечення, які були чітко розділені на функціональні та нефункціональні.
Використання діаграм прецедентів допомогло наочно представити взаємодію
користувачів із системою.
Проектування логічної структури програмного комплексу було здійснено за
допомогою діаграм класів та діаграм пакетів, що дозволило чітко структурувати
об'єкти та їх взаємозв'язки. Архітектурне проектування включало створення
діаграми компонентів та діаграми розгортання, які визначали взаємодію різних
частин системи та їх розміщення на апаратних засобах. Моделювання поведінки
системи за допомогою діаграм діяльності, послідовності, комунікації та
скінченного автомату дозволило детально описати динамічні аспекти
функціонування системи.
Третій розділ був присвячений розробці та тестуванню програмного
забезпечення. Було обґрунтовано вибір засобів реалізації, описано структурну та
логічну схеми системи, розроблено базу даних та інтерфейс користувача, а також
описано розробку програмних компонентів. Особлива увага приділялась
66
ЧДТУ 242050 003ПЗ
тестуванню системи, що включало модульне, інтеграційне, системне та
приймальне тестування. Кожен етап тестування був успішно виконаний, що
підтверджує правильність обраних підходів та високу якість реалізації.
В цілому, проведена робота показала, що розроблений програмний
комплекс ефективно вирішує поставлені завдання, автоматизуючи процес
перевірки та реєстрації студентів, що значно підвищує ефективність і точність
обробки даних. Впровадження цього програмного забезпечення дозволить
зменшити витрати часу та зусиль, а також покращити загальну продуктивність
адміністративних процесів в університеті.
67
ЧДТУ 242050 003ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Web Services [Електронний ресурс]. – Режим доступу:
https://www.w3schools.com/xml/xml_services.asp
2 Al Sweigart. Automate the Boring Stuff with Python / No Starch Press: 2021.
16 с.
3 Вікіпедія. SQL [Електронний ресурс]. – Режим доступу:
https://uk.wikipedia.org/wiki/SQL
4 Twilio Sendgrid Official Dite [Електронний ресурс]. – Режим доступу
https://sendgrid.com/en-us
5 Twilio Sendgrid program interface [Електронний ресурс]. – Режим доступу
https://www.dynamicyield.com/integration/sendgrid/
6 MailChimp Official Dite [Електронний ресурс]. – Режим доступу
https://mailchimp.com/
7 Newsletter Subscription using NEXT JS and Mailchimp API [Електронний
ресурс]. – Режим доступу https://codewithmarish.com/post/newsletter-subscription-
using-next-js-and-mailchimp-api
8 Constant Contact Official Dite [Електронний ресурс]. – Режим доступу
https://www.constantcontact.com/
9 Constant Contact Vs Mailchimp Email Template Building Options
[Електронний ресурс]. – Режим доступу https://www.purplepass.com/blog/constant-
contact-vs-mailchimp-template-building-options/
10 Вікіпедія. Аналіз вимог [Електронний ресурс]. – Режим доступу:
https://uk.wikipedia.org/wiki/Аналіз_вимог
11 Гаркуша І.М. Конспект лекцій з дисципліни «Проектування
інформаційних систем». Дніпро НТУ “ДП” 2020 21 с.
12 Вікіпедія. Діаграма пакетів [Електронний ресурс]. – Режим доступу:
https://uk.wikipedia.org/wiki/Діаграма_пакетів
13 Бевз О. М., Папінов В. М., Скидан Ю. А. Проектування програмних
засобів систем управління. Вінниця: ВНТУ, 2010. 120 с.
68
ЧДТУ 242050 003ПЗ
14 Гаркуша І.М. Конспект лекцій з дисципліни «Проектування
інформаційних систем». Дніпро НТУ “ДП” 2020 35 с.
15 Елементи UML. Діаграма діяльності [Електронний ресурс]. – Режим
доступу: https://docs.kde.org/trunk5/uk/umbrello/umbrello/uml-elements.html
16 Massimo Felici Sequence Diagrams діяльності [Електронний ресурс]. –
Режим доступу:
https://www.inf.ed.ac.uk/teaching/courses/seoc/2011_2012/notes/SEOC08_notes.pdf
17 Я.Ю. Дорогий сучасні технології автоматзованого проектування та
верифікації програм мова моделювання uml. Київ 2021 47 c.
69
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_________________ Голуб С.В.
„____” ______________ 2024 р.
Мобільний застосунок "Студент ЧДТУ": підсистема адміністрування
Специфікація
482. ЧДТУ 42050.003
Листів 2
Розробник ________________ Задорожний О. В.
________________
Керівник Заспа Г. О.
2024
482. ЧДТУ 42050.003 2
Позначення Найменування Примітка
Документація
482.ЧДТУ.42050 12 01 Текст програми
482.ЧДТУ.42050 34 01 Інструкція користувачеві
482.ЧДТУ.42050 90 01 Графічні матеріали
71
ДОДАТОК Б
Мобільний застосунок "Студент ЧДТУ": підсистема адміністрування
Текст програми
482.ЧДТУ.42050 12 01
Листів 15
Розробник ________________ Задорожний О. В.
2024
482.ЧДТУ.42050 12 01 2
Фронтенд
package.json
{
"name": "deanoffice-mobile-admin-frontend",
"version": "0.0.0",
"scripts": {
"ng": "ng",
"start": "ng serve",
"build": "ng build",
"watch": "ng build --watch --configuration development",
"test": "ng test"
},
"private": true,
"dependencies": {
"@angular/animations": "^15.0.0",
"@angular/cdk": "^15.2.9",
"@angular/common": "^15.0.0",
"@angular/compiler": "^15.0.0",
"@angular/core": "^15.0.0",
"@angular/forms": "^15.0.0",
"@angular/material": "^15.2.9",
"@angular/platform-browser": "^15.0.0",
"@angular/platform-browser-dynamic": "^15.0.0",
"@angular/router": "^15.0.0",
"@auth0/angular-jwt": "^5.0.2",
"@popperjs/core": "^2.11.8",
"ag-grid": "^18.1.2",
"ag-grid-angular": "^30.2.1",
"ag-grid-community": "^30.2.1",
"ag-grid-enterprise": "^30.2.1",
"angular-ui-bootstrap": "^2.5.6",
"bootstrap": "^5.3.2",
"ngx-bootstrap": "^5.6.2",
"popper.js": "^1.16.1",
"rxjs": "~7.5.0",
"tslib": "^2.3.0",
"zone.js": "~0.12.0"
},
"devDependencies": {
"@angular-devkit/build-angular": "^15.0.4",
"@angular/cli": "~15.0.4",
"@angular/compiler-cli": "^15.0.0",
"@types/jasmine": "~4.3.0",
"jasmine-core": "~4.5.0",
"karma": "~6.4.0",
"karma-chrome-launcher": "~3.1.0",
"karma-coverage": "~2.2.0",
"karma-jasmine": "~5.1.0",
"karma-jasmine-html-reporter": "~2.0.0",
"typescript": "~4.8.2"
}
73
482.ЧДТУ.42050 12 01 3
}
<!-– index.html -->
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>DeanofficeMobileAdminFrontend</title>
<base href="/">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="icon" type="image/x-icon" href="favicon.ico">
</head>
<body>
<app-root></app-root>
</body>
</html>
api-android-headers.ts
import { HttpHeaders } from '@angular/common/http';
export function getApiHeaders(): HttpHeaders {
const accessToken = localStorage.getItem('access_token');
return new HttpHeaders({
'X-App-Version': '1.1',
'Authorization': `Bearer ${accessToken}`,
});
}
auth.service.ts
@Injectable({
providedIn: 'root',
})
export class AuthService {
private isLoggedInSubject = new BehaviorSubject<boolean>(false);
isLoggedIn$ = this.isLoggedInSubject.asObservable();
private apiUrl = `${environment.apiUrl}/api/authenticate`;
private headers = getApiHeaders();
private jwtHelper = new JwtHelperService();
constructor(private http: HttpClient, private router: Router) {
this.checkAuthentication();
}
login(username: string, password: string): Observable<any> {
return this.http
.post<any>(this.apiUrl, { username, password }, { headers: this.headers })
74
482.ЧДТУ.42050 12 01 4
constructor(private http: HttpClient, private router: Router) {
this.checkAuthentication();
}
login(username: string, password: string): Observable<any> {
return this.http
.post<any>(this.apiUrl, { username, password }, { headers: this.headers })
.pipe(
map((response) => {
localStorage.setItem('access_token', response.token);
this.isLoggedInSubject.next(true);
return response;
}),
catchError((error) => {
this.isLoggedInSubject.next(false);
return throwError(error);
})
);
}
checkAuthentication(): void {
if (this.isLoggedIn()) {
this.isLoggedInSubject.next(true);
} else {
this.isLoggedInSubject.next(false);
this.router.navigate(['/login']);
}
}
isLoggedIn(): boolean {
const token = localStorage.getItem('access_token');
return !!token && !this.jwtHelper.isTokenExpired(token);
}
logout(): void {
localStorage.removeItem('access_token');
this.isLoggedInSubject.next(false);
this.router.navigate(['/login']);
}
}
credentials-file.service.ts
@Injectable()
export class CredentialsFileService {
private url = `${environment.apiUrl}/admin`;
private headers = getApiHeaders();
constructor(private http: HttpClient) {}
readCredentials(formData: FormData) {
return this.http.post(
75
482.ЧДТУ.42050 12 01 5
`${this.url}/process-students-credentials-file`, formData, {
headers: this.headers,
}
);
}
saveStudentAccounts(existOnlyInMainDb: any[], loginChanged: any[]) {
const requestData = {
existOnlyInMainDb: existOnlyInMainDb,
loginChanged: loginChanged
};
return this.http.post(`${this.url}/save-students-credentials-data`, requestData,
{
headers: this.headers,
});
}
sendEmail(existInMobDb: any[]) {
return this.http.post(`${this.url}/send-emails`, existInMobDb, {
headers: this.headers,
});
}
getLogs(studentData: any) {
return this.http.post(`${this.url}/get-email-logs`, studentData, {
headers: this.headers,
});
}
}
students-credentials-data.ts
export class StudentsCredentialsData {
private defaultStudentsData = {
studentsExistInMobDb: null,
studentsNotExistInMainDb: null,
studentsExistOnlyInMainDb: null,
studentsLoginChanged: null,
studentsWithErrors: null,
};
studentsData: any = { .this.defaultStudentsData };
constructor(private studentsDataInput?: any) {
if (studentsDataInput) {
this.studentsData = { .this.defaultStudentsData, .studentsDataInput };
}
}
getStudentsData(): any {
return this.studentsData;
}
}
app.module.ts
76
482.ЧДТУ.42050 12 01 6
@NgModule({
declarations: [
AppComponent,
HeaderComponent,
CredentialsFileComponent,
StudentsWithErrorTableComponent,
StudentsExistInMobDbComponent,
StudentsNotExistInMainDbComponent,
StudentsExistOnlyInMainDbComponent,
StudentsLoginChangedComponent,
LoginComponent,
LetterLogsDialogComponent,
EmailResultsDialogComponent
],
imports: [
BrowserModule,
AppRoutingModule,
BrowserAnimationsModule,
AgGridModule,
HttpClientModule,
TabsModule.forRoot(),
BsDropdownModule.forRoot(),
FormsModule,
MatDialogModule,
MatTableModule,
MatProgressSpinnerModule
],
providers: [
CredentialsFileService,
],
bootstrap: [AppComponent],
entryComponents: [LetterLogsDialogComponent]
})
export class AppModule { }
credentials-file.component.ts
@Component({
selector: 'app-credentials-file',
templateUrl: './credentials-file.component.html',
styleUrls: ['./credentials-file.component.scss'],
})
export class CredentialsFileComponent implements OnInit {
studentsData: StudentsCredentialsData = new StudentsCredentialsData();
studentsDataSubject = new BehaviorSubject<any>(null);
loginChanged: any;
formData = new FormData();
fileSelected: boolean = false;
isLoading: boolean = false;
@ViewChild('studentsExistInMobDb') studentsExistInMobDbView:
| StudentsExistInMobDbComponent
| undefined;
77
482.ЧДТУ.42050 12 01 7
@ViewChild('studentsExistOnlyInMainDb') studentsExistOnlyInMainDbView:
| StudentsExistOnlyInMainDbComponent
| undefined;
@ViewChild('studentsLoginChanged') studentsLoginChangedView:
| StudentsLoginChangedComponent
| undefined;
constructor(
private credentialsFileService: CredentialsFileService,
public dialog: MatDialog
) {}
ngOnInit(): void {
this.studentsDataSubject.subscribe((data) => {
this.studentsData = new StudentsCredentialsData(data);
});
}
onFileInput(event: any): void {
const file = event.target.files[0];
if (file) {
this.formData = new FormData();
this.formData.append('file', file);
this.fileSelected = true;
this.fileRequest();
}
}
fileRequest(): void {
this.credentialsFileService.readCredentials(this.formData).subscribe(
(response) => {
this.studentsDataSubject.next(response);
},
(error) => {
console.error('Error uploading file:', error);
}
);
}
saveStudentAccounts(): void {
let existOnlyInMainDb: any;
let loginChanged: any;
if (this.studentsExistOnlyInMainDbView && this.studentsLoginChangedView) {
existOnlyInMainDb = this.studentsExistOnlyInMainDbView.onSelectionChanged();
loginChanged = this.studentsLoginChangedView.onSelectionChanged();
if (existOnlyInMainDb.length > 0 || loginChanged.length > 0) {
this.credentialsFileService.saveStudentAccounts(existOnlyInMainDb,
loginChanged).subscribe(
() => {
this.fileRequest();
78
482.ЧДТУ.42050 12 01 8
},
(error) => {
console.error('Error saving students:', error);
}
);
} else {
console.warn('No students selected.');
}
}
}
sendEmail(): void {
let existInMobDb: any;
if (this.studentsExistInMobDbView) {
existInMobDb = this.studentsExistInMobDbView.onSelectionChanged();
if (existInMobDb.length > 0) {
this.isLoading = true;
this.credentialsFileService.sendEmail(existInMobDb).subscribe(
(results: any) => {
this.isLoading = false;
this.dialog.open(EmailResultsDialogComponent, {
width: '600px',
data: { results: results },
});
},
(error) => {
this.isLoading = false;
console.error('Error sending letter:', error);
}
);
} else {
alert('No students selected.');
}
}
}
getLogs(): void {
let existInMobDb: any;
if (this.studentsExistInMobDbView) {
existInMobDb = this.studentsExistInMobDbView.onSelectionChanged();
if (existInMobDb.length === 1) {
this.credentialsFileService.getLogs(existInMobDb[0]).subscribe(
(logs: any) => {
this.dialog.open(LetterLogsDialogComponent, {
width: '600px',
data: { logs: logs }
});
},
(error) => {
console.error('Error getting logs:', error);
}
);
} else if (existInMobDb.length === 0) {
79
482.ЧДТУ.42050 12 01 9
alert('No students selected.');
} else {
alert('More than one is selected.');
}
}
}
}
Бекенд
@RestController
@Secured("ROLE_ADMIN")
@RequestMapping("/admin")
public class AccountsController {
private AccountsService accountsService;
@Autowired
public AccountsController(AccountsService accountsService) {
this.accountsService = accountsService;
}
@GetMapping("/students-without-login")
public ResponseEntity<List<ShortStudentInfo>>
getStudentsWithoutLogin(@RequestParam(required = false) String facultyAbbr) {
return
ResponseEntity.ok(accountsService.getStudentsWithoutLogin(facultyAbbr));
}
@PostMapping("process-students-credentials-file")
public ResponseEntity processStudentsCredentialsFile(@RequestParam("file")
MultipartFile file) {
if (file.isEmpty()) {
return
ResponseEntity.status(HttpStatus.UNPROCESSABLE_ENTITY).body("Файл не було
надіслано");
}
try {
return
ResponseEntity.ok(accountsService.splitCsvStudentDataByCategories(file.getInputSt
ream()));
} catch (IOException e) {
return
ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body("Помилка обробки
файлу: " + e.getMessage());
}
}
@PostMapping("/save-students-credentials-data")
public void saveStudentsCredentialsData(@RequestBody Map<String,
List<StudentWithoutErrorModel>> studentsData) {
accountsService.addStudentAccountsToDb(studentsData.get("existOnlyInMainDb"));
accountsService.updateStudentAccountsInDb(studentsData.get("loginChanged"));
}
@PostMapping("/send-emails")
public ResponseEntity<List<EmailSendResultModel>> sendEmails(@RequestBody
List<StudentWithoutErrorModel> studentsData) {
return ResponseEntity.ok(accountsService.sendEmail(studentsData));
}
@PostMapping("/get-email-logs")
public ResponseEntity<List<LetterLogsModel>> getEmailLogs(@RequestBody
StudentWithoutErrorModel studentData) {
List<LetterLogsModel> logs = accountsService.getEmailLogs(studentData);
80
482.ЧДТУ.42050 12 01 10
return ResponseEntity.ok(logs);
}
}
AccountService
@Service
public class AccountsService {
private RestTemplate restTemplate;
private AccountRepository accountRepository;
private ApplicationUserRepository applicationUserRepository;
private JavaMailSender javaMailSender;
private EmailLogRepository emailLogRepository;
@Autowired
public AccountsService(AccountRepository accountRepository,
RestTemplateBuilder restTemplateBuilder,
ApplicationUserRepository applicationUserRepository,
JavaMailSender javaMailSender,
EmailLogRepository emailLogRepository) {
this.restTemplate = restTemplateBuilder.build();
this.accountRepository = accountRepository;
this.applicationUserRepository = applicationUserRepository;
this.javaMailSender = javaMailSender;
this.emailLogRepository = emailLogRepository;
}
public AvailabilityListsInDbModel splitCsvStudentDataByCategories(InputStream
file) {
List<StudentWithoutErrorModel> allStudents = new CsvToBeanBuilder(new
InputStreamReader(file))
.withSeparator(';')
.withType(StudentWithoutErrorModel.class)
.build()
.parse();
for (StudentWithoutErrorModel student : allStudents) {
if (student != null) {
student.setFullName(replaceApostrophes(student.getFullName()));
student.setName(replaceApostrophes(student.getName()));
student.setSurname(replaceApostrophes(student.getSurname()));
student.setPatronymic(replaceApostrophes(student.getPatronymic()));
student.setSpecialty(replaceApostrophes(student.getSpecialty()));
student.setDepartment(replaceApostrophes(student.getDepartment()));
}
}
return formFinalStudentsDataLists(allStudents);
}
private String replaceApostrophes(String input) {
if (input != null) {
input = input.replace("`", "'").replace("’", "'");
}
return input;
}
private AvailabilityListsInDbModel
formFinalStudentsDataLists(List<StudentWithoutErrorModel> allStudents) {
AvailabilityListsInDbModel availabilityListsInDb = new
81
482.ЧДТУ.42050 12 01 11
vailabilityListsInDbModel();
ProcessedStudentsModel processedStudents =
formCorrectAndIncorrectStudentsDataLists(allStudents);
availabilityListsInDb.addStudentsWithErrors(processedStudents.getStudentsWithErro
rs());
splitCorrectStudentsByAvailabilityInDBs(availabilityListsInDb,
processedStudents);
return availabilityListsInDb;
}
private ProcessedStudentsModel
formCorrectAndIncorrectStudentsDataLists(List<StudentWithoutErrorModel>
allStudents) {
List<StudentWithoutErrorModel> studentsWithoutError = new ArrayList<>();
List<StudentWithErrorsModel> studentsWithErrors = new ArrayList<>();
for (StudentWithoutErrorModel student : allStudents) {
ErrorMessage errorMessage = validateStudent(student);
if (errorMessage == null) {
studentsWithoutError.add(student);
} else {
studentsWithErrors.add(new StudentWithErrorsModel(student,
errorMessage.getMessage()));
}
}
studentsWithoutError.forEach(StudentWithoutErrorModel::setAllExtraProperties);
ProcessedStudentsModel processedStudents = new
ProcessedStudentsModel(studentsWithoutError, studentsWithErrors);
return processedStudents;
}
private ErrorMessage validateStudent(StudentWithoutErrorModel student) {
if (student.getSpecialty() == null ||
!student.getSpecialty().matches("\\d+\\s.+")) {
return ErrorMessage.INVALID_SPECIALTY;
} else if (student.getFullName() == null ||
student.getFullName().split("\\s+").length <= 1) {
return ErrorMessage.INVALID_FULL_NAME;
} else if (student.getPersonalEmail() == null ||
!student.getPersonalEmail().contains("@")) {
return ErrorMessage.INVALID_PERSONAL_EMAIL;
} else if (student.getCorporateEmail() == null ||
!student.getCorporateEmail().contains("@")) {
return ErrorMessage.INVALID_CORPORATE_EMAIL;
} else if (student.getPassword() == null) {
return ErrorMessage.INVALID_PASSWORD;
} else if (student.getMicrosoft365() == null ||
!student.getMicrosoft365().contains("@")) {
return ErrorMessage.INVALID_MICROSOFT365_EMAIL;
} else if (student.getPassword365() == null) {
return ErrorMessage.INVALID_PASSWORD365;
} else if (student.getMoodle() == null ||
!student.getMoodle().contains("@")) {
return ErrorMessage.INVALID_MOODLE_EMAIL;
} else if (student.getPasswordMoodle() == null) {
return ErrorMessage.INVALID_PASSWORD_MOODLE;
82
482.ЧДТУ.42050 12 01 12
} else {
return null;
}
}
private void
splitCorrectStudentsByAvailabilityInDBs(AvailabilityListsInDbModel
availabilityListsInDb, ProcessedStudentsModel processedStudents) {
for (StudentWithoutErrorModel student :
processedStudents.getStudentsWithoutError()) {
processCorrectStudent(availabilityListsInDb, student);
}
}
private void processCorrectStudent(AvailabilityListsInDbModel
availabilityListsInDb, StudentWithoutErrorModel student) {
String studentIdFromMainDb = getStudentIdFromMainDb(student);
if (studentIdFromMainDb.equals("NOT_EXIST")) {
availabilityListsInDb.addStudentsNotExistInMainDb(student);
} else if (studentIdFromMainDb.equals("EXIST_MANY")) {
availabilityListsInDb.addStudentsWithErrors(
new
StudentWithErrorsModel(student,ErrorMessage.EXIST_MANY_WITH_THAT_NAME.getMessage(
)));
} else {
processStudentExistingInMainDb(availabilityListsInDb, student,
Integer.valueOf(studentIdFromMainDb));
}
}
private String getStudentIdFromMainDb(StudentWithoutErrorModel student) {
String url = buildSearchUrl(student);
HttpEntity request = new HttpEntity(HttpUtil.getHeaders());
ResponseEntity<Integer[]> response = this.restTemplate.exchange(url,
HttpMethod.GET, request, Integer[].class);
if (response != null && response.getBody() != null &&
response.getBody().length == 1) {
return response.getBody()[0].toString();
} else if (response.getBody().length > 1) {
return "EXIST_MANY";
} else {
return "NOT_EXIST";
}
}
private String buildSearchUrl(StudentWithoutErrorModel student) {
return Constants.BASE_URL + "/students/search-by-name-and-code?" +
"surname=" + student.getSurname() +
"&name=" + student.getName() +
"&patronimic=" + student.getPatronymic() +
"&code=" + student.getSpecialityCode();
}
private void processStudentExistingInMainDb(AvailabilityListsInDbModel
availabilityListsInDb, StudentWithoutErrorModel student, int mainDbId) {
ApplicationUser userById = applicationUserRepository.findById(mainDbId);
if (userById != null) {
if (userById.getUsername().equals(student.getUsername())) {
availabilityListsInDb.addStudentsExistInMobDb(student);
} else {
availabilityListsInDb.addStudentsLoginChanged(student);
}
} else {
availabilityListsInDb.addStudentsExistOnlyInMainDb(student)
83
482.ЧДТУ.42050 12 01 13
}
}
public List<ShortStudentInfo> getStudentsWithoutLogin(String facultyAbbr) {
String url;
if (facultyAbbr != null) {
url = Constants.BASE_URL + "/students/all-active-
students?facultyAbbr=" + facultyAbbr;
} else {
url = Constants.BASE_URL + "/students/all-active-students";
}
HttpEntity request = new HttpEntity(HttpUtil.getHeaders());
ResponseEntity<ShortStudentInfo[]> response =
this.restTemplate.exchange(url, HttpMethod.GET, request,
ShortStudentInfo[].class);
ShortStudentInfo[] studentsInfo = response.getBody();
List<Integer> accountIds = accountRepository.getAllLoginIds();
List<ShortStudentInfo> filteredStudents = Arrays.stream(studentsInfo)
.filter(student ->
!accountIds.contains(student.getId().intValue()))
.collect(Collectors.toList());
return filteredStudents;
}
public void addStudentAccountsToDb(List<StudentWithoutErrorModel> students) {
for (StudentWithoutErrorModel student: students) {
if (checkIfUserExistsInMobileDb(student)) {
continue;
}
int studentsIdFromMainDb =
Integer.valueOf(getStudentIdFromMainDb(student));
ApplicationUser user = new
ApplicationUser(studentsIdFromMainDb,student.getUsername(),
generateRandomPassword());
applicationUserRepository.save(user);
}
}
private boolean checkIfUserExistsInMobileDb(StudentWithoutErrorModel student)
{
return applicationUserRepository.findByUsername(student.getUsername()) !=
null;
}
private static String generateRandomPassword() {
int i = 0;
String password = "";
Random random = new Random();
do {
int rand = 48 + random.nextInt(93);
if (rand >=65 && rand<=90 && random.nextInt(2)==0)
continue;
if ((!(rand >=48 && rand<=57) && !(rand >=65 && rand<=90) && !(rand
>=97 && rand<=122)) || rand==73 || rand==108)
continue;
password += (char)rand;
i++;
} while (i <= 8);
return password;
}
public void updateStudentAccountsInDb(List<StudentWithoutErrorModel>
84
482.ЧДТУ.42050 12 01 14
students) {
for (StudentWithoutErrorModel student: students) {
if (checkIfUserExistsInMobileDb(student)) {
continue;
}
int studentIdFromMainDb =
Integer.valueOf(getStudentIdFromMainDb(student));
ApplicationUser userById =
applicationUserRepository.findById(studentIdFromMainDb);
ApplicationUser user = new
ApplicationUser(studentIdFromMainDb,student.getUsername(),
userById.getPassword());
applicationUserRepository.save(user);
}
}
public List<EmailSendResultModel> sendEmail(List<StudentWithoutErrorModel>
studentsData) {
SimpleMailMessage message = new SimpleMailMessage();
List<EmailSendResultModel> results = new ArrayList<>();
for (StudentWithoutErrorModel studentData : studentsData) {
message.setTo(studentData.getPersonalEmail());
message.setSubject("Мобільний застосунок \"Студент ЧДТУ+\"");
message.setText("Логін: " + studentData.getUsername() + "\n" +
"Пароль: " +
applicationUserRepository.findByUsername(studentData.getUsername()).getPassword()
);
try {
javaMailSender.send(message);
saveSendingLog(studentData, message, true);
results.add(new
EmailSendResultModel(studentData.getPersonalEmail(), true, "Email sent
successfully"));
} catch (MailSendException e) {
saveSendingLog(studentData, message, false);
results.add(new
EmailSendResultModel(studentData.getPersonalEmail(), false, "Failed to send
email: invalid address or recipient server issue"));
} catch (MailException e) {
saveSendingLog(studentData, message, false);
results.add(new
EmailSendResultModel(studentData.getPersonalEmail(), false, "Failed to send
email: mail server issue"));
} catch (Exception e) {
saveSendingLog(studentData, message, false);
results.add(new
EmailSendResultModel(studentData.getPersonalEmail(), false, "Failed to send
email: " + e.getMessage()));
}
}
return results;
}
private void saveSendingLog(StudentWithoutErrorModel studentData,
SimpleMailMessage message, boolean sentSuccessfully) {
EmailsLog log = new EmailsLog();
ApplicationUser user =
applicationUserRepository.findByUsername(studentData.getUsername());
log.setUser(user);
log.setPersonalEmail(studentData.getPersonalEmail());
log.setSubject(message.getSubject());
log.setBody(message.getText());
85
482.ЧДТУ.42050 12 01 15
log.setSentSuccessfully(sentSuccessfully);
try {
emailLogRepository.save(log);
} catch (Exception e) {
System.err.println("Не вдалося зберегти лог для " +
studentData.getPersonalEmail());
}
}
public List<LetterLogsModel> getEmailLogs(StudentWithoutErrorModel
studentData) {
ApplicationUser user =
applicationUserRepository.findByUsername(studentData.getUsername());
List<EmailsLog> logs = emailLogRepository.findByUser(user);
return logs.stream().map(log -> new LetterLogsModel(
studentData.getSurname() + " " + studentData.getName() + " " +
studentData.getPatronymic(),
log.getPersonalEmail(),
log.getSentAt(),
log.getSubject(),
log.getBody(),
log.isSentSuccessfully()
)).collect(Collectors.toList());
}
}
86
ДОДАТОК В
Мобільний застосунок "Студент ЧДТУ": підсистема адміністрування
Інструкція користувачеві
482.ЧДТУ.42050 34 01
Листів 3
Розробник ________________ Задорожний О. В.
2024
482.ЧДТУ.42050 34 01 2
При вході на сайт користувач повинен авторизуватися за допомогою своєї
корпоративної пошти, вхід на сайт не авторизованих користувачів неможливий.
Рисунок В.1 – Форма авторизації
Потім користувач має вибрати розділ сайту, треба натиснути «CSV файл»
і «Вивести дані з файлу»
Рисунок В.2 – Вибір розділу сайту
На відкритий сторінці треба натиснути «Обрати файл»
Рисунок В.3 – Головний інтерфейс сайту
88
482.ЧДТУ.42050 34 01 3
Після чого відкриється вікно вибору файлу, де треба вибрати потрібний
файл.
Рисунок В.4 – Вікно вибору файлу
Після цього можна переключатись між списками студентів, у списку
«Наявні тільки у базі деканату» і «логін змінено» можна вибрати студентів і
натиснути кнопку «Зберегти» для збереження студентів до бази даних. У списку
«Наявні в базі моб. застосунку» можна вибрати студентів для відправки листа або
для перегляд логів відправлених листів.
Рисунок В.5 – Головний інтерфейс сайту
89
ДОДАТОК Г
Мобільний застосунок "Студент ЧДТУ": підсистема адміністрування
Графічні матеріали
482.ЧДТУ. 42050 90 01
Листів 10
Розробник ________________ Задорожний О. В.
2024
482.ЧДТУ. 42050 90 01 2
Рисунок Г.1 – Титульна сторінка
Рисунок Г.2 – Вікно з описом актуальності
Рисунок Г.3 – Вікно з описом мети розробки
91
482.ЧДТУ. 42050 90 01 3
Рисунок Г.4 – Вікно з описом отриманих результатів
Рисунок Г.5 – Вікно з описом способу вирішення задачі
92
482.ЧДТУ. 42050 90 01 4
Рисунок Г.6 – Вікно з описом складу функцій
Рисунок Г.7 – Вікно з описом діаграми класів
93
482.ЧДТУ. 42050 90 01 5
Рисунок Г.8 – Вікно з описом діаграми пакетів
Рисунок Г.9– Вікно з описом діаграми компонентів
94
482.ЧДТУ. 42050 90 01 6
Рисунок Г.10 – Вікно з описом діаграми діяльності
Рисунок Г.11 – Вікно з описом діаграми послідовності
95
482.ЧДТУ. 42050 90 01 7
Рисунок Г.12 – Вікно з описом діаграми комунікації
Рисунок Г.13 – Вікно з описом засобів реалізації
96
482.ЧДТУ. 42050 90 01 8
Рисунок Г.14 – Вікно з описом функціональної схеми
Рисунок Г.15 – Вікно з описом бази даних
97
482.ЧДТУ. 42050 90 01 9
Рисунок Г.16 – Вікно з описом інтерфейсу користувача
Рисунок Г.17 – Вікно з результатами тестувань
98
482.ЧДТУ. 42050 90 01 10
Рисунок Г.18 – Вікно з висновком
99