ChSTU repository

ґ
ЗМІСТ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ..............................................................................8
ВСТУП...................................................................................................................................9
РОЗДІЛ 1............................................................................................................................. 14
ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ ЗАВДАНЬ..
14
1.1 Актуальні проблеми, що виникають в процесі виконання завдань.....................14
1.2 Методи та засоби, які вже використовуються для усунення проблем та
виконання завдань..........................................................................................................15
1.3 Конкретизація завдань роботи................................................................................ 16
РОЗДІЛ 2............................................................................................................................. 18
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ СИСТЕМИ....................18
2.1 Моделювання предметної області.......................................................................... 18
2.1.1 Предметна область моделювання. Модель предметної області. Словник
предметної області.................................................................................................... 18
2.1.2 Елементи моделювання предметної області................................................. 19
2.1.3 Робоча область моделювання..........................................................................22
2.2 Формування та аналіз вимог................................................................................... 24
2.2.1 Формування вимог до програмного забезпечення........................................24
2.2.1.1 Первинні і детальні вимоги.................................................................... 24
2.2.1.2 Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги................................................................................................................... 25
2.2.2 Формування вимог за допомогою діаграми прецедентів.............................26
2.3 Проектування логічної структури програмного комплексу.................................27
2.3.1 Діаграми класів................................................................................................ 27
2.4 Архітектурне проектування.................................................................................... 31
2.4.1 Діаграма компонентів...................................................................................... 31
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання................................................................................................................32
2.5 Моделювання поведінки системи...........................................................................33
2.5.1 Діаграма діяльності..........................................................................................33
2.5.2 Діаграма послідовності................................................................................... 34
ЧДТУ 231918.004 ПЗ
Зм Лист № документа Підпис Дата
Розроб. Копилець. В. М. Літ. Лист Листів.
Керівник Метелап В. В. Серверна частина [н] 3 86
мобільного застосунку
Н. контр. Півень О. Б. “Викладач ЧДТУ” ФІТІС,
Затверд. Голуб С. В. Кафедра ПЗАС, ПЗ-1904
2.5.3 Діаграма комунікації........................................................................................34
2.5.4 Діаграма скінченного автомату...................................................................... 35
РОЗДІЛ 3.............................................................................................................................36
РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ...................36
3.1 Розробка програмного комплексу...........................................................................36
3.1.1 Обґрунтування вибору засобів реалізації......................................................36
3.1.2 Структурно-функціональне моделювання.................................................... 39
3.1.3 Опис логічної схеми системи......................................................................... 40
3.1.4 Розробка бази даних........................................................................................ 41
3.1.5 Розробка інтерфейсу користувача.................................................................. 42
3.1.6 Опис розробки програмних компонентів......................................................44
3.2 Тестування системи................................................................................................. 46
3.2.1 Модульне тестування...................................................................................... 46
3.2.2 Інтеграційне тестування..................................................................................48
3.2.3 Системне тестування.......................................................................................49
3.2.4 Приймальне тестування.................................................................................. 50
ВИСНОВКИ.......................................................................................................................52
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ...................................................................... 54
ДОДАТОК А.......................................................................................................................58
ДОДАТОК Б....................................................................................................................... 60
ДОДАТОК В....................................................................................................................... 76
ДОДАТОК Г....................................................................................................................... 78
ЧДТУ 231918.004 ПЗ
ЧДТУ 231918.004 ПЗ
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ
БД – база даних
ORM – Object-relational mapping, Об'єктно-реляційна проєкція
ВНЗ – Вищий навчальний заклад
UML – Unified Modeling Language, уніфікована мова моделювання
REST – Representational State Transfer, «передача репрезентативного
стану»
HTTP – HyperText Transfer Protocol, протокол передачі даних
API – Application Programming Interface, інтерфейс програмуванн
застосунків
Module – клас з анотацією “@Module” який потрібен для метаданих
NestJS
Endpoint – кінцева точка для доступу до методу сервіса за допомогою
HTTP
5
ЧДТУ 231918.004 ПЗ
ВСТУП
Актуальність теми: програмне забезпечення серверного застосунку для
мобільного застосунку "Викладач ЧДТУ" має велику актуальність в сучасному
світі, адже мобільні технології є невід'ємною частиною нашого життя.
Університетська освіта не є винятком, оскільки вона стикається з новими
викликами та можливостями, які відкривають мобільні технології. Тому
мобільні додатки можуть бути корисними для викладачів університетів у
багатьох відношеннях.
Однією з головних сфер, де мобільні додатки можуть змінити ситуацію, є
управління навчальним процесом - викладачі зможуть використовувати додаток
для постановки оцінок за предмети.
Також цей додаток дозволить викладачам переглядати свій особистий
розклад занять, включаючи інформацію про аудиторії, час та тип заняття. Він
також може надавати можливість автоматичного підбору оптимальних
параметрів розкладу. Підбір параметрів розкладу може бути як за особистими
даними викладача, так і за групами куратора (за наявності). Ще один аспект, де
цей мобільний додаток може бути корисним - це управління відпустками:
Додаток може допомагати викладачам заявляти та відстежувати свої відпустки,
а також переглядати інформацію про відпустки, взяті іншими викладачами
Крім того, мобільні програми можуть допомогти викладачам зберігати та
аналізувати навчальні дані студентів. За допомогою цих програм вчителі
можуть відстежувати прогрес учнів, визначати найефективніші методи
навчання та покращувати уроки на основі цих даних. Це сприяє підвищенню
якості навчання та забезпечує успішність студентів.
З відомих розвʼязків даної задачі відомо лише про один схожий додаток -
“KNU online” [1]. Цей застосунок вміщує в собі не лише електронний кабінет
викладача, а ще й електронний деканат, цифрову бібліотеку та електронний
кабінет студента. В цілому цей додаток дуже схожий по функціоналу на додатки
“Студент ЧДТУ” та “Викладач ЧДТУ”, але з певними відмінностями:
9
ЧДТУ 231918.004 ПЗ
1 В випадку “KNU Online” весь функціонал який стосується навчального
процесу був обʼєднаний один додаток, через що неминуче буде
негативний вплив як на розмір додатку, так і на його швидкодію, на
відміну від підходу який був застосований при розробці додатку
“Викладач ЧДТУ”.
2 Через те що в додаткові “Викладач ЧДТУ” немає стороннього
функціоналу, то викладачі не зможуть випадково через якийсь баг
побачити інформацію, яка призначена студентам.
3 В додаткові “Викладач ЧДТУ” на відміну від “KNU Online” є функціонал
для перегляду викладачами відпусток інших викладачів.
Загалом можна сказати, що мобільні додатки мають великий потенціал
для покращення навчального процесу у ВНЗ. Вони сприяють більш
ефективному та доступному навчанню учнів та полегшують роботу вчителів,
тим самим сприяючи підвищенню якості освіти. Тому тема цієї кваліфікаційної
роботи має велике практичне значення та важливе значення для подальшого
розвитку університетської освіти.
Метою роботи забезпечити викладачам університету зручний інструмент
для перегляду інформації повʼязаної з ними, також для оптимізації та
поліпшення роботи викладачів університету, щоб вони могли приділяти більше
уваги навчанню та розвитку своїх студентів. Деякі можливі функції, які були
реалізовані програмному забезпеченні серверній частині, описані далі.
Об'єктом розробки є програмне забезпечення серверної частини
мобільного застосунку "Викладач ЧДТУ". Ця частина системи відіграє важливу
роль, оскільки вона забезпечує основні функції та взаємодію з клієнтським
додатком на мобільних пристроях.
Серверна частина відповідає за обробку запитів, збереження та керування
даними, забезпечення безпеки та автентифікації, а також взаємодію з іншими
системами чи сервісами, які можуть бути потрібні для правильної роботи
додатку. Вона є основою для функціоналу, що надається користувачам та
забезпечується завдяки мобільному додатку.
10
ЧДТУ 231918.004 ПЗ
Без належно розробленої та функціональної серверної частини, більша
частина функціоналу мобільного застосунку може бути недоступною або
працювати некоректно. Наприклад, це можуть бути функції, пов'язані з
отриманням та відображенням актуальної інформації з бази даних, виконанням
розрахунків, комунікацією з іншими користувачами або системами, а також
збереженням та обробкою даних користувачів.
У процесі розробки серверної частини також враховуються вимоги
замовника. Оскільки серверна частина є складною системою, важливо ретельно
проаналізувати та документувати всі необхідні вимоги до неї, забезпечуючи їх
належну реалізацію.
Після успішної розробки серверної частини та її інтеграції з мобільним
додатком, система "Викладач ЧДТУ" буде готовою до використання.
Користувачі зможуть отримати доступ до функціоналу, який надається
застосунком, здійснювати різні дії та отримувати необхідну інформацію. В
рамках роботи також можна вивчати функціональні можливості застосунку,
його зручність використання викладачами та студентами, а також ефективність
його впливу на навчальний процес. До об'єкту розробки також можна включити
викладачів та студентів, які використовують застосунок, або які могли б
використовувати його в майбутньому.
Методи розробки:
1 Вивчення потреб і вимог користувачів: Проведення досліджень,
опитувань або спілкування з викладачами та кураторами груп для
визначення їх потреб і очікувань від додатку.
2 Аналіз ринку та існуючих рішень: Дослідження і аналіз існуючих
мобільних додатків для викладачів, вивчення їх функціональності,
користувацького досвіду та особливостей.
3 Проектування архітектури: Розробка архітектурного плану, включаючи
визначення компонентів, бази даних, інтерфейсів та взаємодії між ними.
4 Вибір технологій: Вибір підходящих технологій, мов програмування,
фреймворків та інструментів для реалізації серверної частини додатку.
11
ЧДТУ 231918.004 ПЗ
5 Розробка серверної частини: Реалізація логіки додатку, розробка API для
взаємодії з мобільними пристроями, розробка бази даних та виконання
розрахунків із збереженням даних.
6 Тестування та відлагодження: Проведення різних видів тестування, таких
як модульні тести, інтеграційні тести, випробування продуктивності та
забезпечення якості коду.
7 Інтеграція з мобільними платформами: Розробка інтерфейсу для
мобільних пристроїв, інтеграція з відповідними мобільними платформами
(наприклад, Android або iOS), щоб забезпечити зручний доступ до
функціоналу додатку.
8 Випробування та вдосконалення: Проведення тестування залежності між
компонентами, виявлення та виправлення помилок, а також впровадження
змін для вдосконалення функціональності та продуктивності додатку.
9 Підтримка та оновлення: Забезпечення постійної підтримки, вирішення
виявлених проблем, оновлення функціональності та впровадження нових
можливостей залежно від потреб користувачів.
Ці методи розробки допоможуть ефективно створити функціональну та
користувачам зручну систему "Викладач ЧДТУ".
Інструментарій. В якості мови програмування було обрано TypeScript [2],
у цієї мови є багато переваг перед іншими мовами програмування, що дозволяє
вирішувати її допомогою практично будь-які завдання. Ця мова є надбудовою
над JavaScript [3], головною перевагою якої є розширена система типів, на
кшталт як в C# [4], Java [5]. Але на жаль так як це надбудова над динамічно
типізованою мовою програмування, то TypeScript не має повноцінної
інкапсуляції [6]. Також так як для серверу був обраний фреймворк на Node.js [7]
платформі, то в рантаймі буде виконуватися JavaScript, тому TypeScript спершу
повинен скомпілюватися.
Також було обрано Nest.js [8]. Це універсальний фреймворк з відкритим
вихідним кодом для TypeScript. Однією з головних переваг даного фреймворку є
його гнучкий API, тому що його розробники зберегли потрібний рівень
12
ЧДТУ 231918.004 ПЗ
абстракцій. Також серед переваг цього фреймворку є його документація, в якій є
не лише короткий опис методів, сервісів, декораторів, і т.д, а ще й інструкції по
інтеграції різних інших технологій, в тому числі з найпопулярнішими ORM на
платформі Node.js [9], такими як - “Sequelize” [10], “Mongoose” [11],
“TypeORM” [12], “MicroORM” [13], логування, кешування, вебсокети і т.д.
Для розробки БД було обрано PostgreSQL [14]. PostgreSQL є
універсальним рішенням для серверних додатків. Зазвичай PostgreSQL
використовується як сервер, до якого звертаються локальні або видалені
клієнти. Серед плюсів цієї БД є велика кількість функціоналу як вбудованого,
так і стороннього коду в вигляді різноманітних розширень.
13
ЧДТУ 231918.004 ПЗ
РОЗДІЛ 1
ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ
1.1 Актуальні проблеми, що виникають в процесі виконання завдань
Під час розробки серверного застосунку мобільного додатку "Викладач
ЧДТУ" можуть виникнути різні проблеми [15], які варто враховувати на різних
рівнях абстракцій. Наприклад, на рівні безпеки можуть виникнути проблеми
забезпечення конфіденційності та цілісності даних [16].
Застосунок повинен мати механізми шифрування для захисту чутливої
інформації про викладачів та студентів. Також, для забезпечення безпеки та
контролю доступу до системи, необхідно розробити механізми аутентифікації
та авторизації. Одна з ключових проблем полягає в розділенні доступу до
даних, щоб кожен викладач мав можливість переглядати лише дані своїх груп.
Це вимагає встановлення відповідних прав доступу та розробки механізмів
аутентифікації та авторизації в системі.
Зважаючи на чутливість даних, наприклад, особистих даних студентів,
необхідно вжити відповідних заходів безпеки. Це може включати шифрування
даних, захист від несанкціонованого доступу та захист від атак на серверну
інфраструктуру. Забезпечення конфіденційності та цілісності даних є важливою
задачею, що вимагає встановлення надійних механізмів безпеки та системи
контролю доступу до інформації.
Проблеми інтеграції з іншими серверами, зокрема з серверами
"Deanoffice", також можуть виникнути під час розробки. Інтеграція з існуючими
системами університету може потребувати стандартизації протоколів та
форматів обміну даними, щоб забезпечити сумісність та співпрацю між різними
серверами. Крім того, необхідно забезпечити надійну передачу даних між
серверами і врахувати можливі проблеми, такі як непередбачувана відповідь
сервера або проблеми з доступом до мережі.
Розробка серверної частини мобільного застосунку викладача ЧДТУ
вимагає не тільки ретельного планування, аналізу й проектування, але й
14
ЧДТУ 231918.004 ПЗ
налагодження й тестування. Ці етапи є невід'ємною частиною процесу
розробки, оскільки дозволяють виявити та виправити можливі помилки та
недоліки перед впровадженням функціоналу модуля перегляду даних за
групами.
Під час тестування необхідно використовувати комплексний підхід,
включаючи автоматизовані тести, модульне та інтеграційне тестування.
Автоматизовані тести допомагатимуть ефективно перевірити різні сценарії
взаємодії з модулем та виявити можливі помилки. Модульне тестування
дозволить перевірити окремі компоненти функціоналу, впевнитися у їхній
правильній роботі. Інтеграційне тестування дозволяє перевірити співпрацю
різних модулів та компонентів системи.
Крім того, важливо створити механізми збору фідбеку від користувачів
після впровадження модуля. Це дозволить виявити потенційні проблеми, які
можуть виникнути в реальному середовищі, та вчасно реагувати на них. Збір
фідбеку можна здійснювати через зручні інтерфейси, наприклад, форми
зворотного зв'язку або кнопки "Повідомити про проблему". Розробники повинні
бути готові вносити виправлення та вдосконалення у функціонал на основі
зібраного фідбеку.
Також, успішна реалізація проекту вимагає надійної комунікації та
співпраці між розробниками, тестувальниками та адміністраторами системи. Це
дозволить ефективно вирішувати виникаючі проблеми, обмінюватись ідеями та
знаннями, а також вчасно реагувати на зміни та запити з боку користувачів.
Встановлення ефективного комунікаційного процесу та співпраця між всіма
учасниками проекту є ключовими факторами для досягнення успіху.
1.2 Методи та засоби, які вже використовуються для усунення
проблем та виконання завдань
Для усунення проблем та виконання завдань в розробці серверної частини
мобільного застосунку викладача ЧДТУ вже використовуються різні методи та
засоби. Декілька з них включають:
1 Методологія розробки: Використання певної методології розробки,
15
ЧДТУ 231918.004 ПЗ
наприклад, Agile [17] або Scrum [18], дозволяє організувати роботу
команди розробників, тестувальників та адміністраторів системи. Ці
методології сприяють гнучкому плануванню, ітеративному розвитку та
швидкому вирішенню проблем.
2 Інструменти для контролю версій: Використання систем контролю версій,
таких як Git [19], дозволяє ефективно керувати версіями коду та спільно
працювати над проектом. Вона дозволяє відстежувати зміни, об'єднувати
різні гілки розробки та відновлювати попередні версії, що полегшує
усунення проблем та відновлення працездатності системи.
3 Інструменти для автоматизованого тестування: Використання
автоматизованих тестів допомагає виявити помилки та недоліки у
функціоналі системи [20]. Це можуть бути модульні тести [21],
інтеграційні тести [22], функціональні тести [23] та інші. Автоматизоване
тестування дозволяє швидко та ефективно перевірити різні аспекти
роботи системи та виявити потенційні проблеми.
4 Механізми аутентифікації [24] та авторизації [25]: Для забезпечення
безпеки та контролю доступу до системи використовуються методи та
засоби аутентифікації та авторизації. Це можуть бути механізми, такі як
JWT (JSON Web Tokens) [26], OAuth 2.0 [27] та інші. Вони дозволяють
гарантувати, що лише авторизовані користувачі матимуть доступ до
системи та відповідним обсягом даних.
Ці методи та засоби є лише деякими прикладами того, що вже
використовується для усунення проблем та виконання завдань у розробці
серверної частини мобільного застосунку. Розробники постійно шукають нові
та ефективні рішення, щоб забезпечити якість, безпеку та успішне
функціонування системи.
1.3 Конкретизація завдань роботи
Завдання роботи з розробки серверної частини мобільного застосунку
"Викладач ЧДТУ" включають:
1 Проаналізувати наявність та функціональні можливості мобільних
16
ЧДТУ 231918.004 ПЗ
застосунків, що використовуються викладачами університету.
2 Визначити, які функції мобільних застосунків викладачі використовують
найчастіше, та їх вплив на результативність навчального процесу.
3 З’ясувати думки викладачів про зручність використання мобільного
застосунку в роботі та їх оцінку його ефективності.
4 Дослідити потреби та очікування викладачів і кураторів груп від
мобільного додатку, провести аналіз існуючих рішень на ринку мобільних
додатків для викладачів. Це допоможе зрозуміти, які функціональності та
можливості повинен мати додаток для задоволення потреб викладачів
ЧДТУ.
5 Розробити серверну частину мобільного додатку з використанням
технологій, таких як TypeScript, NestJS, Sequelize, PostgreSQL та інші. Це
включає проектування архітектури серверної частини, розробку
функціоналу, який відповідає потребам викладачів, та забезпечення
зручного та безперебійного функціонування серверу.
6 Реалізувати основні функції додатку, які можуть включати можливість
ставити оцінки за предмети, перегляд розкладу занять за різними
параметрами, перегляд відпусток, спілкування зі студентами та надання
ресурсів для навчання.
7 Протестувати та відлагодити серверну частину додатку, щоб забезпечити
надійність, безпеку та високу якість роботи.
17
ЧДТУ 231918.004 ПЗ
РОЗДІЛ 2
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ СИСТЕМИ
2.1 Моделювання предметної області
2.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області
Основні класи або об'єкти, які можна включити до моделі предметної області,
включають:
1 Викладач: Представляє викладача, який працює в університеті [28]. Може
мати атрибути, такі як ім'я, прізвище, контактна інформація,
спеціальність, статус зайнятості тощо.
2 Група: Представляє групу студентів, яку веде викладач [29]. Може мати
атрибути, такі як назва групи, рік навчання, спеціальність тощо.
3 Студент: Представляє студента, який навчається в університеті [30]. Може
мати атрибути, такі як ім'я, прізвище, контактна інформація, група,
академічний рейтинг тощо.
4 Предмет: Представляє навчальний предмет, який викладається в
університеті [31]. Може мати атрибути, такі як назва, опис, кількість
годин, тип предмету (лекція, практичне заняття тощо).
5 Оцінка: Представляє оцінку, отриману студентом за певний предмет [32].
Може мати атрибути, такі як предмет, студент, оцінка, дата отримання
тощо.
Ця модель предметної області [33] є графічним відображенням основних
концептуальних класів і зв'язків між ними, яке допомагає уявити, як реальний
світ взаємодіє з мобільним застосунком "Викладач ЧДТУ". Вона створена з
метою надати уявлення про структуру і функціональні можливості додатку, що
розробляється.
Ця модель є важливим етапом перед проектуванням бази даних та
розробкою функціональності додатку. Вона дозволяє ідентифікувати основні
сутності (класи) в системі та визначити взаємозв'язки між ними. Кожен клас
представляє окрему сутність або концепцію в контексті додатку "Викладач
18
ЧДТУ 231918.004 ПЗ
ЧДТУ", таку як користувач, курс, оцінка тощо. Зв'язки між класами
відображають взаємозв'язки та залежності між цими сутностями, що допомагає
зрозуміти логіку взаємодії між ними.
Ця модель може використовуватись як основа для подальшого
проектування бази даних, де класи моделі представляють таблиці, а зв'язки між
ними - відносини між таблицями. Також вона може послужити основою для
розробки функціональності додатку, де класи моделі відображають об'єкти та
операції, які можуть бути виконані над ними.
Використання цієї моделі допомагає розробникам і зацікавленим
сторонам отримати загальне уявлення про систему, зрозуміти її структуру та
взаємозв'язки між компонентами. Це забезпечує більшу ясність і точність під
час подальшого проектування та розробки додатку "Викладач ЧДТУ".
2.1.2 Елементи моделювання предметної області
У системах, що ґрунтуються на об’єктно-орієнтованому програмуванні,
структура коду визначається класами, які представляють узагальнені об’єкти.
Класифікація означає, що об’єкти з однаковими структурами даних і
поведінкою групуються у класи. Перед тим, як приступати до кодування,
необхідно визначити потрібні класи, для чого можна створити діаграму класів.
Це перший крок до отримання детальної статичної моделі системи, яку
потрібно буде уточнювати в процесі роботи над прецедентами.
Для уникнення дублювання понять в текстах варіантів використання
необхідно побудувати модель предметної області перед складанням варіантів.
Модель предметної області, яка є діаграмою класів аналітичного рівня, є
першим наближенням до статичної структури системи.
Для визначення класів краще використовувати високорівневий опис
завдання, низькорівневі вимоги, описи прецедентів та експертну оцінку
завдання. У процесі уточнення переліку необхідно враховувати, що іменники та
іменні групи стають об’єктами і атрибутами, а дієслова і дієслівні групи стають
операціями і асоціаціями. Родовий відмінок показує, що іменник має бути
атрибутом, а не об’єктом.
19
ЧДТУ 231918.004 ПЗ
Для моделювання предметної області та проектування системи
використовують мову UML [34]. Для діаграм мови UML існують три типи
візуальних позначень: графічні символи, зв’язки та текстові позначення
(рисунок 2.1-2.2) [35].
Рисунок 2.1 – Основні графічні символи UML
20
ЧДТУ 231918.004 ПЗ
Рисунок 2.2 – Єднальні елементи UML
Більшість розробників використовують лише частину мови UML при
створенні програмного забезпечення. Тому важливо знайти свою підмножину
UML, яка підходить для вирішення вашої задачі.
При проектуванні програмного забезпечення необхідно використовувати
21
ЧДТУ 231918.004 ПЗ
основні діаграми UML для моделювання предметної області, формування вимог
до системи, та моделювання логічної та фізичної структури та поведінки
системи. У процесі виявлення об'єктів з предметної області потрібно
встановити відношення між ними, зокрема узагальнення та агрегацію. Класи,
що відображають модель предметної області, увійдуть до статичної моделі
діаграми класів.
У результаті модель предметної області з асоціаціями між класами
повинна адекватно описувати аспекти завдання, що не залежать від часу, і
нагадувати діаграми сутність-зв'язок для моделювання даних. Важливо відвести
фіксований час на побудову початкової моделі предметної області, не
домагаючись її досконалості, і потім модифікувати її згідно з потребами.
Класи в UML служать для розміщення атрибутів і операцій об'єктів.
Проте, на початковій стадії моделювання не потрібно звертати багато уваги на
ідентифікацію атрибутів та операцій. На даний момент головне - виявити
об'єкти та їх відношення.
2.1.3 Робоча область моделювання
Малюнок 2.4 представляє повну модель предметної області для серверної
частини додатку "Викладач ЧДТУ". Ця модель відображає всі необхідні
прецеденти та класи, що відповідають вимогам системи та будуть
використовуватися на пізніших етапах розробки для задоволення потреб
замовника.
На діаграмі видно, що кожен клас представлений прямокутником, який
розділений на три частини. Перша частина містить назву класу, друга частина
відведена для відображення атрибутів або даних, які відносяться до цього класу,
а третя частина призначена для відображення операцій або методів, які можуть
бути викликані на цьому класі. Якщо клас не має атрибутів або операцій,
відповідні частини залишаються порожніми.
Цей підхід до відображення класів на діаграмі дозволяє зрозуміти
структуру системи та зв'язки між класами. За допомогою такої моделі
предметної області можна чітко визначити, які класи будуть використовуватися
22
ЧДТУ 231918.004 ПЗ
у системі, які дані вони зберігатимуть та які операції можуть бути виконані над
цими даними.
Ця повна модель предметної області є основою для подальшого
проектування бази даних та розробки функціональності додатку "Викладач
ЧДТУ". Вона допомагає розробникам та архітекторам системи отримати
уявлення про структуру додатку та визначити необхідні класи та їх
взаємозв'язки для успішної реалізації вимог замовника.
Рисунок 2.4 – Модель предметної області серверної частини додатку “Викладач
ЧДТУ”
23
ЧДТУ 231918.004 ПЗ
2.2 Формування та аналіз вимог
2.2.1 Формування вимог до програмного забезпечення.
2.2.1.1 Первинні і детальні вимоги
Процес визначення вимог для розробки додатку є важливим етапом, який
складається з двох основних категорій: вимоги замовника (первинні вимоги) та
вимоги розробника (детальні вимоги). Кожна з цих категорій має свої
особливості та вимоги до документації, що залежить від рівня деталізації та
опрацювання описів.
Первинні вимоги є вимогами, які відображають бажання та потреби
замовника. На цьому етапі вимоги формулюються зрозумілою мовою замовника
та детально описуються на етапі проектування, часто за допомогою діаграм
прецедентів. Головна мета цих вимог полягає в тому, щоб чітко відобразити
потреби та вимоги користувачів і зрозуміти, як система повинна їх
задовольняти. Цей етап роботи з вимогами називається збором вимог.
Детальні вимоги, з іншого боку, є більш докладними та структурованими
вимогами, які відображають деталізовані вимоги до системи. Вони
документуються у спеціальній формі, яка дозволяє більш детально описати
потреби та вимоги, що виникають на основі первинних вимог. Ці детальні
вимоги аналізуються та розробляються з урахуванням технічних обмежень,
архітектурних рішень та інших факторів. Робота з формуванням детальних
вимог називається аналізом вимог.
Аналіз вимог включає в себе ретельне дослідження первинних вимог,
розуміння контексту та потреб системи, а також врахування технічних
обмежень. На цьому етапі вимоги уточнюються, встановлюються пріоритети та
залежності між різними вимогами. Також враховуються архітектурні рішення та
технічні обмеження, які впливають на реалізацію цих вимог.
Важливо зазначити, що процес визначення вимог є ітеративним, тобто
вимоги можуть змінюватися та уточнюватися протягом всього процесу
розробки додатку. Вимоги розробника і первинні вимоги взаємодіють та
враховують один одного, забезпечуючи належний розвиток та реалізацію
24
ЧДТУ 231918.004 ПЗ
системи, що відповідає потребам замовника.
На етапі проектування системи детальні вимоги документуються
спеціальною структурованою мовою, яка дозволяє точно визначити потрібні
функції та взаємодії в системі. Для цього використовуються різні типи діаграм,
такі як діаграми діяльності та діаграми взаємодії. Ці діаграми відображають
послідовності дій, процеси та взаємодії між різними компонентами системи.
Використання структурованих мов та діаграм дозволяє уточнити вимоги
до системи, зрозуміти послідовності дій та взаємодій між компонентами. Це
забезпечує чіткість та однозначність у визначенні функціональності системи та
полегшує подальший процес розробки. Таким чином, робота з детальними
вимогами є важливим етапом у процесі розробки додатку.[36].
2.2.1.2 Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги
ВИМОГИ ЗАМОВНИКА
1 ПЗ повинно забезпечити можливість перегляду розкладу.
2 ПЗ повинно забезпечити можливість перегляду вільних дат для відпустки.
3 ПЗ повинно забезпечити можливість заповнення певної інформації через
додаток.
ВИМОГИ РОЗРОБНИКА
1.1 Викладач повинен мати можливість перегляду розкладу студентів груп,
в якій він є куратором.
1.2 Викладач повинен мати можливість перегляду розкладу дисциплін, які
він викладає.
1.3 Викладач повинен мати можливість перегляду розкладу за довільними
параметрами.
2.1 Викладач повинен мати можливість побачити дати відпусток
заброньовані іншими викладачами.
3.1 Викладач повинен мати можливість виставити семестрові оцінки
студентові за дисципліну (екзамен або залік).
3.2 Викладач повинен мати можливість обирати студентам теми
25
ЧДТУ 231918.004 ПЗ
кваліфікаційної роботи.
2.2.2 Формування вимог за допомогою діаграми прецедентів
Рисунок 2.5 - Діаграма використання
26
ЧДТУ 231918.004 ПЗ
2.3 Проектування логічної структури програмного комплексу
2.3.1 Діаграми класів
Рисунок 2.6 - Діаграма класів Vacation Module
27
ЧДТУ 231918.004 ПЗ
Рисунок 2.7 - Діаграма класів Shared Module
Рисунок 2.8 - Діаграма класів Database Module
Рисунок 2.9 - Діаграма класів Core Module
28
ЧДТУ 231918.004 ПЗ
Рисунок 2.10 - Діаграма класів SelectiveCourse Module
Рисунок 2.11 - Діаграма класів CuratedGroup Module
29
ЧДТУ 231918.004 ПЗ
Рисунок 2.12 - Діаграма класів Schedule Module
30
ЧДТУ 231918.004 ПЗ
2.3.2 Діаграми пакетів
Рисунок 2.13 - Діаграма пакетів
2.4 Архітектурне проектування
2.4.1 Діаграма компонентів
Рисунок 2.14 - Діаграма компонентів
31
ЧДТУ 231918.004 ПЗ
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Рисунок 2.15 - Діаграма розгортання
32
ЧДТУ 231918.004 ПЗ
2.5 Моделювання поведінки системи
2.5.1 Діаграма діяльності
Рисунок 2.16 - Діаграма діяльності
33
ЧДТУ 231918.004 ПЗ
2.5.2 Діаграма послідовності
Рисунок 2.17 - Діаграма послідовності
34
ЧДТУ 231918.004 ПЗ
2.5.3 Діаграма комунікації
Рисунок 2.18 - Діаграма комунікації для отримання розкладу
2.5.4 Діаграма скінченного автомату
Рисунок 2.19 - Діаграма скінченного автомату
35
ЧДТУ 231918.004 ПЗ
РОЗДІЛ 3
РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
3.1 Розробка програмного комплексу.
3.1.1 Обґрунтування вибору засобів реалізації.
Для вирішення поставлених завдань було обрано фреймворк NestJS з
Fastify [37] адаптером. Цей вибір має кілька вагомих переваг.
По-перше, NestJS пропонує модульний підхід, що дозволяє розбити
додаток на невеликі, логічно зв'язані блоки. Це забезпечує більш чистий,
організований та легкий для розуміння код. Крім того, така архітектура сприяє
швидкій розробці та змінам, оскільки окремі модулі можуть бути легко
модифіковані або замінені без впливу на решту додатку.
По-друге, NestJS повністю підтримує Typescript, що є великим плюсом
для розробки. Використання сильної типізації допомагає уникнути багатьох
помилок під час розробки і полегшує роботу з великими кодовими базами.
Typescript також надає більшу надійність та інструменти для підтримки
рефакторингу та автодоповнення коду.
По-третє, NestJS використовує архітектуру з підтримкою сервісів. Це
означає, що бізнес-логіка розділяється на окремі класи сервісів, які можуть бути
використані повторно в різних частинах додатку. Це сприяє більшій
перевикористовуваності коду, покращує структуру проекту та полегшує його
тестування.
Нарешті, NestJS має широку документацію, яка охоплює як високорівневі
концепції, так і низькорівневі деталі роботи фреймворку. Документація також
включає інструкції щодо інтеграції NestJS з іншими технологіями, що
допомагає розробникам ефективно використовувати фреймворк у своїх
проектах.
Загалом, використання NestJS з Fastify адаптером надає нам потужний,
модульний і типізований фреймворк, який полегшує розробку, забезпечує
більшу надійність коду та покращує швидкість розробки проекту.
Під час розробки було використано дві мови програмування - TypeScript
36
ЧДТУ 231918.004 ПЗ
та JavaScript. TypeScript був обраний як основна мова для розробки проекту,
оскільки він надає переваги типізації та дозволяє писати більш структурований
та безпечний код. JavaScript, з свого боку, був використаний для деяких
конкретних завдань, таких як конфігурація доступу до бази даних, написання
міграцій або доступ до основного бекенду "Deanoffice" та інші подібні сценарії.
Одним із найбільших переваг обох мов програмування є широке
співтовариство. Як TypeScript, так і JavaScript мають велику кількість
розробників, які активно працюють над розширенням функціональності,
вирішенням проблем та наданням підтримки. Це означає, що ви можете знайти
багато документації, питань та відповідей, прикладів коду та корисних ресурсів,
які допоможуть вам під час розробки.
Ще однією перевагою обох мов програмування є підтримка асинхронного
програмування. Це дозволяє ефективно працювати з асинхронними операціями,
такими як мережеві виклики або робота з базою даних, без блокування
виконання програми. Асинхронний підхід дозволяє розподіляти ресурси та
підвищувати продуктивність програми, забезпечуючи при цьому плавну та
безперебійну роботу.
Для для роботи з БД (PostgreSQL) були використані Sequelize,
Sequelize-Typescript [39], Sequelize-cli [40].
Sequelize та Sequelize-Typescript - це дві потужні технології, які
використовуються для роботи з базами даних з коду. Однією з найважливіших
переваг цих технологій є їх зрілість, особливо в контексті Sequelize. Sequelize є
однією з найстаріших ORM для Node.js, і завдяки своєму тривалому існуванню,
вона накопичила велику кількість функціоналу, який може виявитися відсутнім
в новіших ORM.
Однак, разом з перевагами зрілості, існує й певний недолік. Унаслідок
довгого існування та накопичення функціоналу, інтеграція новіших принципів
розробки може стати викликом. Це означає, що іноді може бути складніше
використовувати сучасні підходи і технології у контексті старіших версій
Sequelize.
37
ЧДТУ 231918.004 ПЗ
Тому виникає потреба у використанні окремого пакету -
Sequelize-Typescript. Цей пакет надає зручну інтеграцію між Sequelize та
TypeScript-екосистемою. Ви можете використовувати TypeScript-специфічні
функції та концепції, такі як декоратори, як от @Table, для опису анотацій
моделей та полів бази даних. Крім того, вам надається можливість
використовувати інші особливості TypeScript, такі як інтерфейси, енуми та
модифікатори доступу, для більш організованої та безпечної розробки вашого
коду.
Таким чином, використання Sequelize-Typescript сприяє зручній роботі з
базами даних з використанням TypeScript, поєднуючи потужність Sequelize з
перевагами типізації та розширення функціональності TypeScript.
Середовищем розробки виступає VS Code [41]. Він має свої переваги [42]:
1 Кросплатформовість: Visual Studio Code підтримує роботу на різних
операційних системах, таких як Windows, macOS і Linux. Це означає, що
можна використовувати одне і те ж середовище розробки на будь-якій
платформі без будь-яких проблем.
2 Розширюваність: Visual Studio Code відрізняється великою гнучкістю та
можливістю налаштування завдяки широкому спектру доступних
розширень. Ці розширення включають різні типи інструментів та
функцій, що створені, щоб забезпечити більш гладкий, ефективний та
продуктивний досвід програмування. Розширення можуть бути такими, як
прості теми оформлення, які змінюють вигляд та відчуття редактора, до
більш складних плагінів, що надають підтримку різних мов
програмування, інтеграцію з системами контролю версій, інструменти для
рефакторингу коду, автоматичного форматування та багато іншого.
3 Підтримка різних мов програмування: Visual Studio Code підтримує
багато мов програмування, включаючи JavaScript та TypeScript, які
використовуються в даному додатку.
4 Швидкодія: Visual Studio Code має швидку роботу і завантаження, що
робить процес розробки швидким і ефективним. Він також має
38
ЧДТУ 231918.004 ПЗ
можливість показувати підказки та автодоповнення, що допомагає
збільшити продуктивність під час розробки.
3.1.2 Структурно-функціональне моделювання
Рисунок 3.1 - Діаграма структурної схеми
Кожна підсистема описує собою набір REST контролерів, які засобами
NestJS викликаються коли на сервер приходить запит за відповідною URL та
відповідним HTTP методом.
Підсистема розкладу - в цій підсистемі знаходиться один контролер з
одним “POST” ендпоінтом. Цей endpoint приймає певний обʼєкт з параметрами
в тіло запиту, та обробляє їх відповідним шляхом, після чого робить запит на
сервер застосунку “Студент ЧДТУ”, в якому знаходиться endpoint по якому
можна отримати розклад за параметрами.
Підсистема відпусток - в цій підсистемі знаходяться endpoint для
створення, редагування, перегляду, та видалення відпусток з бази даних.
39
ЧДТУ 231918.004 ПЗ
Підсистема перегляду даних для кураторів груп - ця підсистема
включає в себе певну кількість “GET” endpoint’ів для перегляду даних за
групами, куратором яких є викладач. Серед цих даних є: академічні борги
студентів з груп, куратором яких є викладач; дисципліни та вибіркові
дисципліни всіх студентів в групах, куратором яких є викладач; студенти з груп,
куратором яких є викладач.
3.1.3 Опис логічної схеми системи
40
ЧДТУ 231918.004 ПЗ
Рисунок 3.2 - Діаграма логічної схеми системи
3.1.4 Розробка бази даних
Фізична модель даних
Рисунок 3.3 - Діаграма фізичної моделі даних
База даних має в собі 3 таблиці - user, curated_group, SequelizeMeta.
Таблиця “curated_group” (Кураторська група):
“id” заповнюється автоматично; тип даних – INTEGER
поле “active” являє собою прапорець, який описує чи запис є активним, чи
ні; тип даних - BOOLEAN
поле “userId” зв’язане зовнішнім ключем з полем id в таблиці user і
позначає таким чином користувача; тип даних - INTEGER
поле “groupId” позначає поле id з таблиці “student_group”з основної бази
даних “Deanoffice”; тип даних - INTEGER
Таблиця “user” (Користувач):
“id” заповнюється автоматично; тип даних – INTEGER
41
ЧДТУ 231918.004 ПЗ
поле “active” являє собою прапорець, який описує чи запис є активним, чи
ні; тип даних - BOOLEAN
поле “username” описує ім’я користувача, яке використовується для
ідентифікації користувача; тип даних - VARCHAR(255)
поле “password” описує пароль користувача, яке використовується для
ідентифікації користувача; тип даних - VARCHAR(255)
поле “teacherId” позначає поле id з таблиці “teacher”з основної бази даних
“Deanoffice”; тип даних - INTEGER
3.1.5 Розробка інтерфейсу користувача
Серверна частина додатку призначена для обробки запитів від
клієнтських додатків та надання відповідей на ці запити. Вона не призначена
для безпосередньої взаємодії з користувачем, тому інтерфейс користувача на
серверній стороні додатку недоцільний.
Основним завданням серверної частини додатку є забезпечення
правильної обробки запитів та відповідей, зберігання даних у базі даних,
взаємодія з іншими компонентами системи та забезпечення безпеки додатку. В
цьому контексті взаємодія з користувачем є завданням клієнтської частини
додатку, яка відповідає за візуальну сторону додатку та надання можливостей
користувачам взаємодіяти з ним.
Крім того, серверна частина додатку зазвичай не запускається на
комп'ютері користувача, а працює на віддаленому сервері. Тому інтерфейс
користувача на серверній стороні додатку не має сенсу, оскільки користувач не
має можливості безпосередньо взаємодіяти з ним.
Загалом, інтерфейс користувача повинен бути реалізований на клієнтській
стороні додатку, де користувач має доступ до додатку та може взаємодіяти з ним
за допомогою різних інтерфейсів, таких як веб-сторінки, мобільні додатки або
десктопні програми.
Найближчим по значенню до інтерфейсу користувача можливим
інструментом є Swagger - це інструмент автоматичної генерації документації
для API сервера, що дає змогу детально описати доступні ендпоінти, їх
42
ЧДТУ 231918.004 ПЗ
параметри, відповіді та статуси [43]. Swagger також дозволяє спробувати
виконати запити безпосередньо зі спеціальної веб-сторінки, що є корисним для
тестування та налагодження API.
Swagger (OpenAPI [44]) - це інструмент для опису та документування RESTful
API. Swagger дозволяє описувати структуру та формат даних, доступні ресурси
та їх параметри, типи запитів та їх відповіді. Крім того, Swagger дозволяє
генерувати код для клієнтських додатків та тестувати API безпосередньо з
інтерфейсу Swagger (рис. 3.4).
Рисунок 3.4 - Інтерфейс Swagger серверної частини “Викладач ЧДТУ”
Swagger є стандартом, який використовується в багатьох проектах для
документування та описування їх API. Swagger дозволяє створювати
документацію для API та робить його більш доступним для розробників, які
працюють з ним. Крім того, Swagger дозволяє автоматично генерувати
клієнтський код для різних мов програмування, що допомагає зменшити час
розробки та підвищити продуктивність команди розробників.
Swagger є відкритим стандартом та має широку підтримку серед
розробників та команд розробників. Документація Swagger може бути
43
ЧДТУ 231918.004 ПЗ
використана для генерації різних інструментів, таких як інтерактивна
документація, тестувальний інтерфейс, клієнтський код та інші інструменти для
розробників.
3.1.6 Опис розробки програмних компонентів
Спільний модуль (SharedModule) - це модуль в NestJS, який містить
загальний код, що використовується в різних модулях вашого додатку. Це
дозволяє забезпечити повторне використання коду і зменшити дублювання
функціональності. Цей модуль містить в собі “CustomHttpService”, який є
абстракцією над “HttpService” з пакету “@nestjs/axios”.
Тому цей модуль імпортується в більшості інших модулів.
Рисунок 3.5 - Використання імпорту SharedModule на прикладі GroupModule
Модуль розкладу - в цій підсистемі знаходиться один контролер з одним
“POST” endpoint’ом. Цей endpoint приймає певний обʼєкт з параметрами в тіло
запиту, та обробляє їх відповідним шляхом, після чого робить запит на сервер
застосунку “Студент ЧДТУ”, в якому знаходиться endpoint по якому можна
отримати розклад за параметрами.
У цього модуля є залежність на “SharedModule”.
Найголовніша частина бізнес логіки в цьому модулі знахаходиться в
методі “getScheduleByParams” (рисунок 3.6).
44
ЧДТУ 231918.004 ПЗ
Рисунок 3.6 - Метод “getScheduleByParams” з модуля розкладу
В цьому методові формуються і відправляються запити до серверної
частини застосунку “Студент ЧДТУ”, очікується на відповідь, витягується
розклад з відповіді і повертається користувачеві. Також тут відбувається
перевірка, чи параметрів для розкладу більше ніж 4 (такий ліміт є на вхідні
параметри в endpoint’i в серверній частині застосунку “Студент ЧДТУ”), якщо
їх більше, то параметри розбиваються на масиви по 4 елементи, і для кожного
подібного масиву формується окремий запит. В кінці результати всіх запитів
поєднуються в один масив.
Модуль відпусток - в цьому модулі знаходяться endpoint’и для створення,
редагування, перегляду, та видалення відпусток з бази даних. На даний момент
тут немає ніякої бізнес логіки, звичайний “CRUD” ресурс.
У цього модуля є залежність на “SharedModule”.
Модуль перегляду даних для кураторів груп - цей модуль включає в
себе певну кількість “GET” endpoint’iв для перегляду даних за групами,
куратором яких є викладач. Серед цих даних є: академічні борги студентів з
груп, куратором яких є викладач; дисципліни та вибіркові дисципліни всіх
студентів в групах, куратором яких є викладач; студенти з груп, куратором яких
є викладач.
45
ЧДТУ 231918.004 ПЗ
3.2 Тестування системи
3.2.1 Модульне тестування
Модульне тестування є невід'ємною частиною розробки програмного
забезпечення, включаючи серверну частину додатку "Викладач ЧДТУ".
Використання модульних тестів дозволяє розробникам перевіряти правильність
роботи окремих фрагментів коду, які називаються модулями.
У випадку серверної частини додатку "Викладач ЧДТУ", модульне
тестування може бути використано для перевірки функціональності сервера, що
відповідає за роботу з базою даних студентів і викладачів, та обмін даними з
клієнтською частиною додатку.
Також модульні тести можуть перевіряти належне функціонування
окремих функцій серверу, таких як:
Авторизація і аутентифікація користувачів.
Отримання даних про студентів і викладачів з бази даних.
Створення нових записів у базі даних.
Оновлення і видалення існуючих записів у базі даних.
Обмін даними з клієнтською частиною додатку через API.
Завдяки використанню модульного тестування можна певну впевненість у
тому, що окремі фрагменти коду працюють правильно, і зменшити кількість
помилок, які можуть виникати при інтеграції різних модулів додатку. Також це
допоможе швидше виявляти та усувати помилки, що зменшить витрати часу на
розробку та тестування.
Використання модульного тестування за допомогою фреймворку NestJS
дозволяє розробникам перевірити правильність роботи окремих модулів та
компонентів додатку "Викладач ЧДТУ". Цей підхід дозволяє виявляти та
виправляти помилки на ранніх етапах розробки, зменшує час на відлагодження
та пошук помилок, а також підвищує якість коду.
Для тестування окремих модулів та компонентів додатку можна
використовувати фреймворки Jest [45] або Mocha [46]. Вони надають
інструменти для створення тестів та перевірки результатів. За допомогою
46
ЧДТУ 231918.004 ПЗ
спеціальних декораторів розробник може позначити ті модулі та компоненти,
які потребують тестування.
Наприклад, для тестування контролерів (controllers) NestJS розробники
можуть використовувати спеціальний модуль @nestjs/testing, який надає функції
для створення тестових середовищ та виконання тестів. Також NestJS дозволяє
писати тести для провайдерів (providers), сервісів (services) та інших
компонентів.
Крім того, NestJS надає вбудовану підтримку для тестування
HTTP-запитів до додатку. Це дозволяє перевірити, чи працює API додатку
правильно, шляхом надсилання запитів до API та перевірки відповідей.
Узагальнюючи, використання модульного тестування за допомогою
фреймворку NestJS допомагає розробникам забезпечити високу якість коду
серверної частини додатку "Викладач ЧДТУ", зменшити кількість помилок та
збільшити швидкість розробки.
Наразі кількість написаних модульних тестів не є дуже великою, але в
майбутньому їх кількість обовʼязково буде більшою.
Рисунок 3.6 - Модульні тести для “LoginService”
47
ЧДТУ 231918.004 ПЗ
3.2.2 Інтеграційне тестування
Інтеграційне тестування за допомогою фреймворку NestJS дозволяє
розробникам перевірити взаємодію різних компонентів та модулів додатку
"Викладач ЧДТУ" в контексті реального середовища. Цей підхід дозволяє
виявляти та виправляти помилки, які можуть виникнути в процесі взаємодії
різних компонентів та модулів, що може сприяти покращенню загальної якості
додатку.
Для проведення інтеграційного тестування використовують фреймворки,
такі як Jest або Supertest [47]. Supertest дозволяє тестувати HTTP-запити до
додатку, а Jest - тестувати функціональні можливості різних компонентів та
модулів.
У NestJS є вбудований модуль @nestjs/testing, який дозволяє створювати
тестове середовище та імітувати роботу додатку в реальному середовищі. За
допомогою цього модуля можна створювати тестові запити до API та імітувати
роботу клієнтів. Також NestJS дозволяє тестувати бази даних та взаємодію з
іншими сервісами, використовуючи фреймворки, такі як TypeORM або
Mongoose.
Крім того, NestJS дозволяє проводити тестування в різних середовищах,
таких як розробка, тестування та продукція, що дозволяє розробникам
перевірити, як додаток буде працювати в різних умовах.
Узагальнюючи, використання інтеграційного тестування за допомогою
фреймворку NestJS допомагає розробникам перевірити взаємодію різних
компонентів та модулів додатку, що дозволяє виявляти та виправляти помилки
на ранніх етапах розробки, зменшуючи кількість помилок та підвищує загальну
якість додатку. Тестування допомагає також збільшити довіру до додатку,
оскільки воно дозволяє перевірити правильність роботи окремих компонентів
та їх взаємодію.
Інтеграційне тестування за допомогою NestJS може включати в себе
перевірку таких аспектів, як:
Перевірка правильності обробки HTTP-запитів та відповідей на них;
48
ЧДТУ 231918.004 ПЗ
Перевірка правильності роботи баз даних та взаємодії з ними;
Перевірка правильності взаємодії з іншими сервісами та системами;
Перевірка правильності обробки помилок та винятків.
Для проведення інтеграційних тестів за допомогою NestJS
рекомендується використовувати окрему базу даних, щоб тестові запити не
впливали на реальні дані. Також важливо враховувати, що інтеграційні тести
можуть бути повільнішими та складнішими у налаштуванні, ніж модульні
тести.
Наразі в серверній частині додатку "Викладач ЧДТУ" немає автоматичних
інтеграційних тестів.
3.2.3 Системне тестування
Системне тестування - це вид тестування, який перевіряє правильну
роботу всього додатку в цілому, включаючи всі його компоненти та модулі, які
взаємодіють між собою [48]. У фреймворку NestJS для системного тестування
можна використовувати такі інструменти, як End-to-End (E2E) [49] тестування
та Заглушки (Mocks) [50].
End-to-End тестування передбачає запуск тестового сценарію, що імітує
дії користувача у додатку. Це дозволяє перевірити, чи працює весь додаток
відповідно до очікувань користувача, включаючи усі його інтерфейси, бази
даних та взаємодію з іншими сервісами та системами. У фреймворку NestJS для
E2E тестування можна використовувати бібліотеку Protractor або Cypress.
Заглушки (Mocks) - це інша корисна техніка, що дозволяє тестувати
окремі компоненти додатку, не залежно від реалізації інших компонентів. Вони
замінюють реальні компоненти на фіктивні об'єкти, які повертають певні
значення, імітуючи реальну взаємодію з додатком. Заглушки можуть бути
корисними, якщо компоненти додатку, з якими взаємодіє тестируваний
компонент, не готові до тестування або не стабільні.
У фреймворку NestJS для системного тестування можна використовувати
такі інструменти, як NestJS Testing та Supertest. NestJS Testing - це вбудована
бібліотека, що дозволяє тестувати компоненти додатку та їх взаємодію в
49
ЧДТУ 231918.004 ПЗ
контексті середовища NestJS.
Рисунок 3.7 - Системні (e2e) тести для “AppController”
3.2.4 Приймальне тестування
Приймальне тестування є фінальним етапом тестування перед випуском
продукту в експлуатацію [51]. Воно перевіряє, чи відповідає додаток вимогам та
специфікації, і може бути виконано за допомогою ручного або автоматизованого
тестування.
У фреймворку NestJS приймальне тестування можна виконати,
наприклад, за допомогою вбудованої функціональності тестування [52]. NestJS
має можливість запускати тести у середовищі реального додатку, що дозволяє
перевірити його функціональність в реальних умовах. Для цього потрібно
запустити додаток в режимі тестування за допомогою команди npm run
test:e2e, яка запустить всі тести з папки e2e. У цій папці можна створювати
файли з тестами, які виконуються у реальному додатку.
Для автоматизації приймального тестування можна використовувати різні
50
ЧДТУ 231918.004 ПЗ
інструменти, наприклад, Selenium [53] або Puppeteer [54]. Для тестування
додатку з використанням цих інструментів можна скористатися фреймворком
Jest, який є вбудованим у фреймворк NestJS. Jest має багато функціональності
для автоматизованого тестування, таку як збір звітів, тестування забезпечення
безпеки, роботу з моками та фейками, що дозволяє розширити можливості
приймального тестування.
Також можна використовувати інші інструменти, такі як Cucumber [55],
що дозволяє створювати більш зрозумілі і детальні тестові сценарії, які можна
використовувати для приймального тестування.
51
ЧДТУ 231918.004 ПЗ
ВИСНОВКИ
В рамках даного КРБ було проведено дослідження серверної частини
застосунку викладача Черкаського державного технологічного університету. На
підставі аналізу роботи серверної частини було виявлено, що вона є важливою
складовою застосунку, що дозволяє викладачам зручно та ефективно
взаємодіяти зі студентами та управляти навчальним процесом.
Для реалізації дослідження було використано сучасні технології та методи
програмування. Було проведено аналіз функцій серверної частини та її
архітектури. В результаті було виявлено певні проблеми та недоліки, які
вимагають удосконалення та оптимізації.
На основі проведеного дослідження було запропоновано рекомендації
щодо поліпшення роботи серверної частини та підвищення її ефективності та
надійності. Зокрема, було запропоновано використання більш сучасних
технологій та методів програмування, оптимізацію бази даних, підвищення
безпеки даних тощо.
Отже, можна стверджувати, що проведене дослідження серверної частини
застосунку викладача Черкаського державного технологічного університету є
важливим кроком у поліпшенні якості навчального процесу. Рекомендації,
запропоновані в рамках даного КРБ, можуть бути використані у практичній
діяльності викладачів та розробників програмного забезпечення для
покращення ефективності та надійності застосунку.
Також важливо наголосити на тому, що під час дослідження було
виявлено потребу у подальшому розвитку серверної частини застосунку,
зокрема, впровадженні додаткових функцій та можливостей для викладачів та
студентів, покращенні інтерфейсу та зручності користування, підвищенні
швидкодії та стабільності роботи. Ці аспекти можуть бути враховані у
подальшому розробленні та вдосконаленні серверної частини.
Також слід зазначити, що результати дослідження можуть бути корисними
не лише для Черкаського державного технологічного університету, але й для
інших закладів вищої освіти та компаній, які займаються розробкою та
52
ЧДТУ 231918.004 ПЗ
впровадженням навчального програмного забезпечення. Зокрема, рекомендації
щодо використання більш сучасних технологій та методів програмування,
оптимізації бази даних та підвищення безпеки даних можуть бути корисними
для різних проектів у галузі інформаційних технологій.
Отже, дослідження серверної частини застосунку викладача Черкаського
державного технологічного університету є важливим кроком у поліпшенні
навчального процесу та може мати практичне значення для розробників
програмного забезпечення в галузі освіти.
53
ЧДТУ 231918.004 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 KNU Online – [Електронний ресурс] - Режим доступу:
https://www.ukrinform.ua/rubric-technology/3060294-universitet-u-smartfoni-
prezentuvali-dodatok-knu-online.html
2 TypeScript — це JavaScript із синтаксисом для типів - [Електронний
ресурс] - Режим доступу: https://www.typescriptlang.org/
3 JavaScript – [Електронний ресурс] – Режим доступу:
https://developer.mozilla.org/en-US/docs/Web/JavaScript
4 C# - [Електронний ресурс] - Режим доступу:
https://learn.microsoft.com/en-us/dotnet/csharp/
5 Java - [Електронний ресурс] - Режим доступу:
https://www.java.com/en/download/help/whatis_java.html
6 TypeScript encapsulation demystified - [Електронний ресурс] - Режим
доступу: https://generic-ui.com/blog/typescript-encapsulation
7 Node.js – [Електронний ресурс] – Режим доступу: https://nodejs.org/en
8 Документація | Nest.js – структура node.js, створена на основі TypeScript -
[Електронний ресурс] - Режим доступу: https://docs.nestjs.com/
9 Best 11 ORMs for Node.js, Query Builders & Database Libraries in 2022 -
[Електронний ресурс] - Режим доступу:
https://www.prisma.io/dataguide/database-tools/top-nodejs-orms-query-builder
s-and-database-libraries
10 Керівництво по Sequelize - [Електронний ресурс] - Режим доступу:
https://my-js.org/docs/guide/sequelize/
11 Mongoose for Application Development - Simon Holmes / Packt Publishing
(2013р.) – ст. 52.
12 TypeORM - [Електронний ресурс] - Режим доступу: https://typeorm.io/
13 MicroORM: Встановлення та використання - [Електронний ресурс] -
Режим доступу: https://mikro-orm.io/docs/installation
14 Документація PostgreSQL – [Електронний ресурс] - Режим доступу:
https://www.postgresql.org/docs/
54
ЧДТУ 231918.004 ПЗ
15 Top 10 Mistakes Backend Developers Make – [Електронний ресурс] - Режим
доступу: https://brainhub.eu/library/mistakes-backend-developers
16 8 Backend Security Risks and Ways to Prevent Them – [Електронний ресурс]
- Режим доступу:
https://www.makeuseof.com/backend-security-risks-and-preventions/
17 What is Agile – [Електронний ресурс] - Режим доступу:
https://www.atlassian.com/agile
18 What is Scrum – [Електронний ресурс] - Режим доступу:
https://www.atlassian.com/agile/scrum
19 What is Git – [Електронний ресурс] - Режим доступу:
https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F
20 Advantages of Automation Testing – [Електронний ресурс] - Режим
доступу: https://www.javatpoint.com/advantages-of-automation-testing
21 What is Unit Testing? – [Електронний ресурс] - Режим доступу:
https://smartbear.com/learn/automated-testing/what-is-unit-testing/
22 Integration Testing: What is, Types with Example – [Електронний ресурс] -
Режим доступу: https://www.guru99.com/integration-testing.html
23 What is Functional Testing? – [Електронний ресурс] - Режим доступу:
https://www.guru99.com/functional-testing.html
24 Authentication | NestJS - A progressive Node.js framework – [Електронний
ресурс] - Режим доступу: https://docs.nestjs.com/security/authentication
25 Authorization | NestJS - A progressive Node.js framework – [Електронний
ресурс] - Режим доступу: https://docs.nestjs.com/security/authorization
26 Introduction to JSON Web Tokens – [Електронний ресурс] - Режим доступу:
https://jwt.io/introduction
27 OAuth 2.0 – [Електронний ресурс] - Режим доступу: https://oauth.net/2/
28 Професія Викладач – [Електронний ресурс] - Режим доступу:
https://ukrlawcouncil.org/registers/profesiya-vykladach/
29 Академічна студентська група – [Електронний ресурс] - Режим доступу:
https://vue.gov.ua/%D0%90%D0%BA%D0%B0%D0%B4%D0%B5%D0%B
55
ЧДТУ 231918.004 ПЗ
C%D1%96%D1%87%D0%BD%D0%B0_%D1%81%D1%82%D1%83%D0%
B4%D0%B5%D0%BD%D1%82%D1%81%D1%8C%D0%BA%D0%B0_%D
0%B3%D1%80%D1%83%D0%BF%D0%B0
30 Статус і права студента визначені законодавчою базою – [Електронний
ресурс] - Режим доступу:
https://kubg.edu.ua/images/stories/Departaments/ppos/documents/profspilka_p
rava_i_oboviazky_stud.pdf
31 Предмет це – [Електронний ресурс] - Режим доступу:
https://uk.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D0%B4%D0%B
C%D0%B5%D1%82
32 Оцінювання результатів навчання: рекомендації МОН – [Електронний
ресурс] - Режим доступу: https://osvita.ua/school/estimation/87164/
33 Модель предметної області: поняття, структура і основні принципи -
[Електронний ресурс] - Режим доступу:
https://what.com.ua/model-predmetnoi-oblasti-poni/
34 UML: модель предметної області - [Електронний ресурс] - Режим
доступу: https://stud.com.ua/174168/informatika/model_predmetnoyi_oblasti
35 Елементи UML - [Електронний ресурс] - Режим доступу:
https://docs.kde.org/trunk5/uk/umbrello/umbrello/uml-elements.html
36 Визначення вимог: що це таке і як це застосовувати? - [Електронний
ресурс] - Режим доступу:
https://visuresolutions.com/uk/blog/requirements-definition/
37 Performance (Fastify) - [Електронний ресурс] - Режим доступу:
https://docs.nestjs.com/techniques/performance
38 Advantages and disadvantages of NestJS - [Електронний ресурс] - Режим
доступу:
https://themobilereality.com/blog/advantages-and-disadvantages-of-nestjs
39 Sequelize-Typescript- [Електронний ресурс] - Режим доступу:
https://github.com/sequelize/sequelize-typescript
40 Sequelize CLI - [Електронний ресурс] - Режим доступу:
56
ЧДТУ 231918.004 ПЗ
https://sequelize.org/docs/v6/other-topics/migrations/
41 VS Code - [Електронний ресурс] - Режим доступу:
https://code.visualstudio.com/
42 Why Visual Studio Code? - [Електронний ресурс] - Режим доступу:
https://code.visualstudio.com/docs/editor/whyvscode
43 Тестування API за допомогою Swagger: особливості та переваги -
[Електронний ресурс] - Режим доступу:
https://blog.ithillel.ua/ru/articles/api-testing-with-swagger
44 Getting Started | OpenAPI Documentation - [Електронний ресурс] - Режим
доступу: https://learn.openapis.org/
45 Jest - [Електронний ресурс] - Режим доступу: https://jestjs.io/
46 Mocha- [Електронний ресурс] - Режим доступу: https://mochajs.org/
47 Supertest: How to Test APIs Like a Pro - [Електронний ресурс] - Режим
доступу: https://www.testim.io/blog/supertest-how-to-test-apis-like-a-pro/
48 Системне тестування - [Електронний ресурс] - Режим доступу:
https://qalight.ua/baza-znaniy/sistemne-testuvannya/
49 What is End-to-End Testing? E2E Testing Full Guide - [Електронний ресурс]
- Режим доступу:
https://katalon.com/resources-center/blog/end-to-end-e2e-testing
50 What is mocks? [Електронний ресурс] - Режим доступу:
https://www.radview.com/glossary/what-is-mock-testing/
51 Що таке прийомне тестування? - [Електронний ресурс] - Режим доступу:
https://uk.myservername.com/what-is-acceptance-testing
52 NestJS: приймальне тестування - [Електронний ресурс] - Режим
доступу:https://docs.nestjs.com/fundamentals/testing#end-to-end-testing
53 Що таке Selenium? - [Електронний ресурс] - Режим доступу:
https://habr.com/ru/articles/152653/
54 Puppeteer - [Електронний ресурс] - Режим доступу: https://pptr.dev/
55 Cucumber - [Електронний ресурс] - Режим доступу:
https://cucumber.io/docs/guides/overview/
57
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедри ПЗАС
проф. Голуб С.В.
___________________________
СЕРВЕРНА ЧАСТИНА МОБІЛЬНОГО ЗАСТОСУНКУ «Викладач ЧДТУ»
Специфікація
ЧДТУ 231918.004 ПЗ
Листів 1
Розробник ________________ Копилець В.М.
Керівник ________________ Метелап В.В.
Н.Контроль ________________ Півень О.Б.
Черкаси 2023
Позначення Найменування Примітка
Документація
482.ЧДТУ.231918-004 12-01 Лістинг програми
482.ЧДТУ.231918-004 34-01 Інструкція користувача
482.ЧДТУ.231918-004 90-01 Презентація
59
ДОДАТОК Б
СЕРВЕРНА ЧАСТИНА МОБІЛЬНОГО ЗАСТОСУНКУ «Викладач ЧДТУ»
Лістинг програми
482.ЧДТУ.231918-004 12-01
Листів 16
Розробник: ________________________ Копилець В. М.
Черкаси 2023
482.ЧДТУ.231918-004 12-01
config.js
module.exports = {
deanofficeBackendUrl: process.env.DEANOFFICE_BACKEND_URL ||
'http://localhost:8080',
deanofficeBackendToken: process.env.DEANOFFICE_BACKEND_TOKEN
|| '',
deanofficeMobileBackendUrl:
process.env.DEANOFFICE_MOBILE_BACKEND_URL ||
'http://localhost:8075/',
deanofficeMobileBackendToken:
process.env.DEANOFFICE_MOBILE_BACKEND_TOKEN || '',
databaseConfig: {
username: process.env.DB_USERNAME || "postgres",
password: process.env.DB_PASSWORD || "postgres",
database: process.env.DB_DATABASE ||
"deanoffice-teacher-mobile",
port: process.env.DB_PORT || 5432,
host: process.env.DB_HOST || "127.0.0.1",
schema: process.env.DB_SCHEMA || 'public',
dialect: "postgres",
},
jwtSecret: process.env.JWT_SECRET || 'secret',
}
main.ts
import { ValidationPipe } from '@nestjs/common';
import { NestFactory } from '@nestjs/core';
import {
FastifyAdapter,
NestFastifyApplication,
} from '@nestjs/platform-fastify';
import { AppModule } from './app.module';
async function bootstrap() {
const app = await NestFactory.create<NestFastifyApplication>(
AppModule,
new FastifyAdapter({ logger: true }),
{
logger: ['error', 'warn', 'log', 'debug', 'verbose']
61
482.ЧДТУ.231918-004 12-01
}
);
app.useGlobalPipes(new ValidationPipe());
await app.listen(3000);
}
bootstrap();
Database Module
config/config.js
const config = require("../../../config.js");
module.exports = {
"development": config.databaseConfig
}
database.providers.ts
import { Sequelize } from 'sequelize-typescript';
import { databaseConfig } from '../../config';
import { Options } from 'sequelize';
import { User } from '../login/entities/user.entity';
import { CuratedGroup } from
'../curated-group/entities/curated-group.entity';
import { Vacation } from '../vacation/entities/vacation.entity';
export const databaseProviders = [
{
provide: 'SEQUELIZE',
useFactory: async () => {
const sequelize = new Sequelize(databaseConfig as
Options);
sequelize.addModels([
User,
CuratedGroup,
Vacation,
]);
await sequelize.sync();
return sequelize;
},
62
482.ЧДТУ.231918-004 12-01
},
];
database.module.ts
import { Module } from '@nestjs/common';
import { databaseProviders } from './database.providers';
@Module({
providers: [...databaseProviders],
exports: [...databaseProviders],
})
export class DatabaseModule {}
models/index.js
/* eslint-disable @typescript-eslint/no-var-requires */
'use strict';
const fs = require('fs');
const path = require('path');
const Sequelize = require('sequelize');
const process = require('process');
const basename = path.basename(__filename);
const env = process.env.NODE_ENV || 'development';
const config = require(__dirname + '/../config/config.js')[env];
const db = {};
let sequelize;
if (config.use_env_variable) {
sequelize = new Sequelize(process.env[config.use_env_variable],
config);
} else {
sequelize = new Sequelize(config.database, config.username,
config.password, config);
}
fs
.readdirSync(__dirname)
.filter(file => {
return (
file.indexOf('.') !== 0 &&
file !== basename &&
file.slice(-3) === '.js' &&
file.indexOf('.test.js') === -1
63
482.ЧДТУ.231918-004 12-01
);
})
.forEach(file => {
const model = require(path.join(__dirname, file))(sequelize,
Sequelize.DataTypes);
db[model.name] = model;
});
Object.keys(db).forEach(modelName => {
if (db[modelName].associate) {
db[modelName].associate(db);
}
});
db.sequelize = sequelize;
db.Sequelize = Sequelize;
module.exports = db;
models/User.js
'use strict';
import { Model } from 'sequelize';
export default (sequelize, DataTypes) => {
class User extends Model {
/**
* Helper method for defining associations.
* This method is not a part of Sequelize lifecycle.
* The `models/index` file will call this method
automatically.
*/
static associate(models) {
// define association here
}
}
User.init({
username: DataTypes.STRING,
password: DataTypes.STRING,
active: DataTypes.BOOLEAN,
teacherId: DataTypes.INTEGER
}, {
sequelize,
modelName: 'User',
timestamps: false,
64
482.ЧДТУ.231918-004 12-01
});
return User;
};
models/Vacation.js
'use strict';
const {
Model
} = require('sequelize');
module.exports = (sequelize, DataTypes) => {
class Vacation extends Model {
/**
* Helper method for defining associations.
* This method is not a part of Sequelize lifecycle.
* The `models/index` file will call this method
automatically.
*/
static associate(models) {
// define association here
}
}
Vacation.init({
fromDate: DataTypes.DATEONLY,
toDate: DataTypes.DATEONLY,
active: DataTypes.BOOLEAN,
userId: DataTypes.INTEGER
}, {
sequelize,
modelName: 'Vacation',
});
return Vacation;
};
models/CuratedGroup.js
'use strict';
const {
Model
} = require('sequelize');
module.exports = (sequelize, DataTypes) => {
class CuratedGroup extends Model {
/**
* Helper method for defining associations.
* This method is not a part of Sequelize lifecycle.
65
482.ЧДТУ.231918-004 12-01
* The `models/index` file will call this method
automatically.
*/
static associate(models) {
// define association here
}
}
CuratedGroup.init({
active: DataTypes.BOOLEAN,
userId: DataTypes.INTEGER,
groupId: DataTypes.INTEGER
}, {
sequelize,
modelName: 'curated_group',
});
return CuratedGroup;
};
migrations/20230506115555-create-user.js
'use strict';
/** @type {import('sequelize-cli').Migration} */
module.exports = {
async up(queryInterface, Sequelize) {
await queryInterface.createTable('user', {
id: {
allowNull: false,
autoIncrement: true,
primaryKey: true,
type: Sequelize.INTEGER
},
username: {
type: Sequelize.STRING
},
password: {
type: Sequelize.STRING
},
active: {
type: Sequelize.BOOLEAN
},
teacherId: {
type: Sequelize.INTEGER
},
});
66
482.ЧДТУ.231918-004 12-01
},
async down(queryInterface, Sequelize) {
await queryInterface.dropTable('user');
}
};
migrations/20230511180729-create-curated-group.js
'use strict';
/** @type {import('sequelize-cli').Migration} */
module.exports = {
async up(queryInterface, Sequelize) {
await queryInterface.createTable('curated_group', {
id: {
allowNull: false,
autoIncrement: true,
primaryKey: true,
type: Sequelize.INTEGER
},
active: {
type: Sequelize.BOOLEAN
},
userId: {
type: Sequelize.INTEGER,
references: {model: 'user', key: 'id'}
},
groupId: {
type: Sequelize.INTEGER
},
});
},
async down(queryInterface, Sequelize) {
await queryInterface.dropTable('curated_group');
}
};
migrations/ 20230520094032-create-vacation.js
'use strict';
/** @type {import('sequelize-cli').Migration} */
module.exports = {
async up(queryInterface, Sequelize) {
await queryInterface.createTable('vacation', {
id: {
allowNull: false,
67
482.ЧДТУ.231918-004 12-01
autoIncrement: true,
primaryKey: true,
type: Sequelize.INTEGER
},
fromDate: {
type: Sequelize.DATEONLY
},
toDate: {
type: Sequelize.DATEONLY
},
active: {
type: Sequelize.BOOLEAN
},
userId: {
type: Sequelize.INTEGER,
references: {model: 'user', key: 'id'}
},
});
},
async down(queryInterface, Sequelize) {
await queryInterface.dropTable('vacation');
}
};
Group Module
group.controller.ts
import { Controller, Get, Param, ParseArrayPipe, Query } from
'@nestjs/common';
import { Group } from './dto/group.dto';
import { GroupService } from './group.service';
import { GroupNameWithStudents } from '../core/models/models';
@Controller('groups')
export class GroupController {
constructor(private readonly groupService: GroupService) {}
@Get()
findAllByParams(
@Query('names', new ParseArrayPipe({ items: String,
separator: ',' })) names: string[]
): Group[] {
68
482.ЧДТУ.231918-004 12-01
return this.groupService.findAllByParams(names);
}
@Get('by-user/:userId')
findAllByUser(
@Query('userId') userId: string
): Promise<Group[]> {
return this.groupService.findAllByUser(userId);
}
@Get('students')
findStudentsByGroupNames(
@Query('names', new ParseArrayPipe({ items: String,
separator: ',' })) names: string[]
): Promise<GroupNameWithStudents[]> {
return this.groupService.findStudentsByGroupNames(names);
}
@Get('students/by-user/:userId')
findStudentsByUser(
@Query('userId') userId: string
): Promise<GroupNameWithStudents[]> {
return this.groupService.findStudentsByUser(userId);
}
@Get('courses')
findCoursesByGroupNamesAndSemester(
@Query('names', new ParseArrayPipe({ items: String,
separator: ',' })) names: string[],
@Query('semester') semester: number
) {
return
this.groupService.findCoursesByGroupNamesAndSemester(names,
semester);
}
@Get('courses/by-user/:userId')
findCoursesByUserAndSemester(
@Param('userId') userId: string,
@Query('semester') semester: number
) {
return this.groupService.findCoursesByUserAndSemester(userId,
semester);
}
69
482.ЧДТУ.231918-004 12-01
@Get('debt/academic')
finAcademicDebtsByGroupNames(
@Query('names', new ParseArrayPipe({ items: String,
separator: ',' })) names: string[],
) {
return this.groupService.finAcademicDebtsByGroupNames(names);
}
@Get('debt/academic/by-user/:userId')
finAcademicDebtsByUser(
@Param('userId') userId: string,
) {
return this.groupService.finAcademicDebtsByUser(userId);
}
}
group.module.ts
import { Module } from '@nestjs/common';
import { GroupService } from './group.service';
import { GroupController } from './group.controller';
import { SharedModule } from '../shared/shared.module';
@Module({
imports: [SharedModule],
controllers: [GroupController],
providers: [GroupService],
exports: [GroupService]
})
export class GroupModule {}
group.service.ts
import { Injectable, Logger, OnModuleInit } from '@nestjs/common';
import { catchError, firstValueFrom, forkJoin, map } from 'rxjs';
import { deanofficeBackendUrl } from '../../config';
import { CustomHttpService } from
'../shared/services/custom-http.service';
import { Group } from './dto/group.dto';
import { Course, GroupNameWithStudents,
GroupNameWithStudentDegrees, StudentDegree, GroupNameWithCourses }
from '../core/models/models';
import { CuratedGroup } from
'../curated-group/entities/curated-group.entity';
70
482.ЧДТУ.231918-004 12-01
export type AcademicDebt = Map<number, Course[][]>;
@Injectable()
export class GroupService implements OnModuleInit {
activeGroups: Group[]
private readonly logger = new Logger(GroupService.name);
constructor(private readonly customHttpService:
CustomHttpService) {
}
onModuleInit() {
// TODO: add cron job
this.loadActiveGroups();
}
private loadActiveGroups() {
this.logger.log('Request to get active groups started');
this.customHttpService.get(`${deanofficeBackendUrl}/groups`).pipe(
catchError((error) => {
this.logger.error('Request to get active groups
failed with error: ' + error);
throw error;
})
).subscribe((result) => {
this.activeGroups = result.data;
this.logger.log('Request to get active groups succeed');
});
}
public async findStudentDegreesByGroupNames(names: string[]):
Promise<GroupNameWithStudentDegrees[]> {
const groups = this.activeGroups.filter((group) =>
names.includes(group.name));
if (!groups.length) {
throw new Error('Group not found');
}
const requests = groups.map((group) => {
71
482.ЧДТУ.231918-004 12-01
return
this.customHttpService.get<StudentDegree[]>(`${deanofficeBackendUr
l}/groups/${group.id}/students`).pipe(
catchError((error) => {
this.logger.warn(`Error while loading student
degrees. Data: group: ${group.id}. Error: ${error}`);
throw error;
}),
map((result) => {
return {
groupName: group.name,
studentDegrees: result.data
}
})
);
})
return firstValueFrom(forkJoin(requests))
}
public findAllByParams(names: string[]): Group[] {
return this.activeGroups.filter((group) =>
names.includes(group.name));
}
public async findAllByUser(userId: string): Promise<Group[]>
{
const curatedGroups = await CuratedGroup.findAll({ where: {
userId } });
const groups = this.activeGroups.filter((group) => {
return curatedGroups.some((curatedGroup) =>
curatedGroup.groupId === group.id)
});
return groups;
}
public async findStudentsByGroupNames(names: string[]):
Promise<GroupNameWithStudents[]> {
const groups = this.activeGroups.filter((group) =>
names.includes(group.name));
const requests = groups.map((group) => {
72
482.ЧДТУ.231918-004 12-01
return
this.customHttpService.get<StudentDegree[]>(`${deanofficeBackendUr
l}/groups/${group.id}/students`).pipe(
catchError((error) => {
this.logger.warn(`Error while loading student
degrees. Data: group: ${group.id}. Error: ${error}`);
throw error;
}),
map((result) => {
return {
groupName: group.name,
students: result.data.map((studentDegree)
=> studentDegree.student)
}
})
);
})
return firstValueFrom(forkJoin(requests))
}
public async findStudentsByUser(userId: string):
Promise<GroupNameWithStudents[]> {
const curatedGroups = await CuratedGroup.findAll({ where: {
userId } });
const groups = this.activeGroups.filter((group) => {
return curatedGroups.some((curatedGroup) =>
curatedGroup.groupId === group.id)
});
const groupNames = groups.map((group) => group.name);
return this.findStudentsByGroupNames(groupNames);
}
public async findCoursesByGroupNamesAndSemester(names:
string[], semester: number): Promise<GroupNameWithCourses[]> {
const groups = this.activeGroups.filter((group) =>
names.includes(group.name));
const requests = groups.map((group) => {
return
this.customHttpService.get<Course[]>(`${deanofficeBackendUrl}/grou
ps/${group.id}/courses`, {
73
482.ЧДТУ.231918-004 12-01
params: {
semester
}
}).pipe(
catchError((error) => {
this.logger.warn(`Error while loading courses.
Data: group: ${group.id}. Error: ${error}`);
throw error;
}),
map((result) => {
return {
groupName: group.name,
courses: result.data
}
})
);
})
return firstValueFrom(forkJoin(requests))
}
public async findCoursesByUserAndSemester(userId: string,
semester: number): Promise<GroupNameWithCourses[]> {
const curatedGroups = await CuratedGroup.findAll({ where: {
userId } });
const groups = this.activeGroups.filter((group) => {
return curatedGroups.some((curatedGroup) =>
curatedGroup.groupId === group.id)
});
const groupNames = groups.map((group) => group.name);
return this.findCoursesByGroupNamesAndSemester(groupNames,
semester);
}
public async finAcademicDebtsByGroupNames(names: string[]):
Promise<AcademicDebt[]> {
const groups = this.activeGroups.filter((group) =>
names.includes(group.name));
const requests = groups.map((group) => {
return
this.customHttpService.get<AcademicDebt>(`${deanofficeBackendUrl}/
74
482.ЧДТУ.231918-004 12-01
grades/${group.id}/debt/academic`).pipe(
catchError((error) => {
this.logger.warn(`Error while loading debts.
Data: group: ${group.id}. Error: ${error}`);
throw error;
}),
map((result) => result.data)
);
})
return firstValueFrom(forkJoin(requests))
}
public async finAcademicDebtsByUser(userId: string):
Promise<AcademicDebt[]> {
const curatedGroups = await CuratedGroup.findAll({ where: {
userId } });
const groups = this.activeGroups.filter((group) => {
return curatedGroups.some((curatedGroup) =>
curatedGroup.groupId === group.id)
});
const groupNames = groups.map((group) => group.name);
return this.finAcademicDebtsByGroupNames(groupNames);
}
}
group.dto.ts
export class Group {
id: number;
name: string;
active: boolean;
studySemesters: number;
studyYears: number;
creationYear: number;
specialization: any;
tuitionForm: string;
tuitionTerm: string;
realBeginYears: number;
beginYears: number;
}
75
ДОДАТОК В
СЕРВЕРНА ЧАСТИНА МОБІЛЬНОГО ЗАСТОСУНКУ «Викладач ЧДТУ»
Інструкція по використанню
482.ЧДТУ.231918-004 34-01
Листів 1
Розробник: ________________________ Копилець В. М.
Черкаси 2023
482.ЧДТУ.231918-004 34-01
1 Підготовка середовища:
Встановіть Node.js на свою систему, якщо його ще немає.
Завантажити його можна з офіційного сайту Node.js
(https://nodejs.org).
2 Завантаження та встановлення застосунку:
Завантажте програмне забезпечення серверного застосунку
"Викладач ЧДТУ" з репозиторію проекту (GitHub).
Розпакуйте завантажений архів з кодом проекту.
Відкрийте командний рядок або термінал та перейдіть до папки
проекту.
Виконайте команду yarn install для встановлення всіх залежностей
проекту.
3 Налаштування бази даних:
Встановіть PostgreSQL на свою систему, якщо його ще немає.
Завантажити його можна з офіційного сайту PostgreSQL
(https://www.postgresql.org/download/).
Створіть базу даних, яка буде використовуватися програмним
забезпеченням серверного застосунку "Викладач ЧДТУ".
Відредагуйте конфігураційний файл застосунку (наприклад,
src/config.js) та вкажіть параметри підключення до бази даних.
4 Запуск серверного застосунку:
Виконайте команду yarn start для запуску серверного застосунку.
Після успішного запуску ви побачите повідомлення, що сервер
прослуховує певний порт (за замочуванням порт 3000).
5 Взаємодія з серверним застосунком:
Відкрийте веб-браузер та введіть URL-адресу сервера
(http://localhost:3000/api) для доступу до Swagger серверного
застосунку "Викладач ЧДТУ".
Виконуйте необхідні дії в застосунку, використовуючи доступний
функціонал з Swagger.
6 Завершення роботи:
Щоб зупинити серверний застосунок, перейдіть до командного
рядка або терміналу, в якому запущено застосунок, і натисніть Ctrl +
C.
За потреби внесіть необхідні зміни в код або конфігурацію
застосунку та повторіть кроки 4-6
77
ДОДАТОК Г
СЕРВЕРНА ЧАСТИНА МОБІЛЬНОГО ЗАСТОСУНКУ «Викладач ЧДТУ»
Презентація
482.ЧДТУ.231918-004 90-01
Листів 5
Розробник: ________________________ Копилець В. М.
Черкаси 2023
482.ЧДТУ.231918-004 90-01
Рисунок Г.1 – Слайд “Вступ”
Рисунок Г.2 – Слайд “Ідея”
79
482.ЧДТУ.231918-004 90-01
Рисунок Г.3 – Слайд “Мета”
Рисунок Г.4 – Слайд “Технології”
80
482.ЧДТУ.231918-004 90-01
Рисунок Г.5 – Слайд “Модель предметної області”
Рисунок Г.6 – Слайд “Діаграма використання”
81
482.ЧДТУ.231918-004 90-01
Рисунок Г.7 – Слайд “Реалізований функціонал”
Рисунок Г.8 – Слайд “Реалізований фунціонал”
82
482.ЧДТУ.231918-004 90-01
Рисунок Г.9 – Слайд “Що планується додати?”
Рисунок Г.10 – Слайд “Кінець”
83