ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9107| Title: | Програмне забезпечення інформаційної системи безоплатної первинної правової допомоги: серверна частина |
| Authors: | Заспа, Григорій Олександрович Кретов, Олександр Валентинович |
| Keywords: | юрист;клієнт;досвід;програмна платформа |
| Issue Date: | 15-Dec-2023 |
| Abstract: | Анотація
Студент: Кретов Олександр Валентинович
Назва КРМ: Програмне забезпечення інформаційної системи безоплатної
первинної правової допомоги: серверна частина
Спеціальність: 121 “Інженерія програмного забезпечення”
Установа, де відбудеться захист: Черкаський Державний технологічний
університет
Місто, рік: Черкаси, 2023
Основні ідеї, результати та висновки:
Дана дипломна робота присвячена розробці програмної платформи,
спрямованої на вирішення проблеми набуття досвіду для починаючих юристів.
Платформа розрахована на два основних типи користувачів: малодосвідчених
юристів та клієнтів, які шукають безкоштовні консультації юриста.
Юристи-початківці отримують можливість отримати реальний досвід
роботи, що фіксується та документується. Для клієнтів, які шукають
консультації, ця платформа надає можливість отримати безкоштовну
консультацію юриста, зберігаючи при цьому анонімність. This work is dedicated to developing a software platform aimed at addressing the challenge of gaining experience for novice lawyers. The platform is designed for two primary user types: inexperienced lawyers and clients seeking free legal consultations. Novice lawyers are offered the opportunity to acquire real work experience, which is recorded and documented. For clients seeking consultations, this platform provides the possibility to receive free legal advice while maintaining anonymity. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9107 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота магістра Кретов Олександр Валентинович.pdf Restricted Access | 7.73 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Пояснювальна записка
до кваліфікаційної магістерської роботи
зі спеціальності 121 “Інженерія програмного забезпечення”
(освітньо-кваліфікаційний рівень)
на тему: «Програмне забезпечення інформаційної системи безоплатної первинної
правової допомоги: серверна частина»
Виконав: студент 1 курсу, групи МПЗ-2204
Спеціальності
121 “Інженерія програмного забезпечення”
(шифр і назва спеціальності)
Студент Кретов О.В.
(прізвище та ініціали)
Керівник Заспа Г.О.
(прізвище та ініціали)
Рецензент Захарова М.В.
(прізвище та ініціали)
2023 рік
Черкаський державний технологічний університет
(повне найменування вищого навчального закладу)
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень магістр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
________________ Голуб С.М.
«___» ____________ 2023 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Кретов Олександр Валентинович
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи): Програмне забезпечення інформаційної системи безоплатної
первинної правової допомоги: серверна частина
Керівник проекту (роботи): Заспа Григорій Олександрович, доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від «06» жовтня
2023 року №267/04
2. Строк подання студентом проекту (роботи): 15 грудня 2023 року
3. Вхідні дані до проекту (роботи): стандарти програмного забезпечення; моделювання
системи; вимоги до проект;
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити):
Вступ;
Існуючі методи і засоби розв’язання поставлених задач;
Теоретичні та експериментальні дослідження;
Впровадження результатів досліджень у практику проектування програмного забезпечення
інформаційних систем;
Розробка та тестування програмного забезпечення;
Висновки; Список використаних джерел;
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту):
слайд 1, слайд 2, слайд3, слайд 4, слайд 5, слайд 6, слайд 8, слайд 9, слайд11, слайд 12.__ ___ _
6. Консультанти розділів проекту (роботи):
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання: 05 вересня 2023 року
КАЛЕНДАРНИЙ ПЛАН
Строк
виконання
№
Назва етапів випускної роботи етапів Примітки
п/п
випускної
роботи
1 Постановка задачі 06.09.2023 виконано
2 Підготовка завдання 13.09.2023 виконано
3 Погодження завдання 20.09.2023 виконано
4 Затвердження завдання 27.09.2023 виконано
Основна стадія
1 Підбір матеріалів 04.10.2023 виконано
2 Аналіз шляхів вирішення поставленої задачі 11.10.2023 виконано
3 Розрахунок основних параметрів роботи 18.10.2023 виконано
4 Вибір кінцевого варіанту проектного рішення 25.10.2023 виконано
5 Оформлення первісної редакції роботи 01.11.2023 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з керівником 08.11.2023 виконано
2 Оформлення пояснювальної записки роботи в кінцевій редакції 15.11.2023 виконано
3 Попередній захист роботи 22.11.2023 виконано
4 Затвердження роботи 29.11.2023 виконано
5 Рецензування роботи 06.12.2023 виконано
6 Захист роботи 15.12.2023 виконано
Студент: Кретов О.В,
(підпис) (прізвище та ініціали)
Керівник проекту (роботи): Заспа Г.О.
(підпис) (прізвище та ініціали)
Анотація
Студент: Кретов Олександр Валентинович
Назва КРМ: Програмне забезпечення інформаційної системи безоплатної
первинної правової допомоги: серверна частина
Спеціальність: 121 “Інженерія програмного забезпечення”
Установа, де відбудеться захист: Черкаський Державний технологічний
університет
Місто, рік: Черкаси, 2023
Основні ідеї, результати та висновки:
Дана дипломна робота присвячена розробці програмної платформи,
спрямованої на вирішення проблеми набуття досвіду для починаючих юристів.
Платформа розрахована на два основних типи користувачів: малодосвідчених
юристів та клієнтів, які шукають безкоштовні консультації юриста.
Юристи-початківці отримують можливість отримати реальний досвід
роботи, що фіксується та документується. Для клієнтів, які шукають
консультації, ця платформа надає можливість отримати безкоштовну
консультацію юриста, зберігаючи при цьому анонімність.
This work is dedicated to developing a software platform aimed at addressing
the challenge of gaining experience for novice lawyers. The platform is designed for
two primary user types: inexperienced lawyers and clients seeking free legal
consultations.
Novice lawyers are offered the opportunity to acquire real work experience,
which is recorded and documented. For clients seeking consultations, this platform
provides the possibility to receive free legal advice while maintaining anonymity.
Ключові слова: юрист, клієнт, досвід, програмна платформа.
ЗМІСТ
ВСТУП ....................................................................................................................... 80
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ ................................................................................. 83
1.1 Центр правової допомоги ............................................................................. 84
1.2 Юристи.ua ........................................................................................................ 85
1.3 Правова допомога онлайн ............................................................................ 88
1.4 Юридична фірма Юдей ................................................................................. 90
1.5 «Правомен» ...................................................................................................... 91
РОЗДІЛ 2. ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ 96
2.1 Теоретичні дослідження ................................................................................ 96
2.2 Експериментальні дослідження .................................................................. 98
2.2.1 Аналіз програмного підходу ..................................................................... 99
РОЗДІЛ 3. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ ........................................................................... 103
3.1 Моделювання предметної області ............................................................. 103
3.1.1Предметна область моделювання ............................................................ 103
3.1.2 Модель предметної області ..................................................................... 104
3.1.3 Елементи моделювання предметної області.......................................... 105
3.1.4 Словник предметної області .................................................................... 106
3.2 Формування вимог за допомогою діаграми прецедентів ..................... 107
3.3 Формування та аналіз вимог ..................................................................... 110
3.3.1 Вимоги замовника ................................................................................... 110
3.3.2 Вимоги розробника ................................................................................. 110
3.3.3 Детальні вимоги ....................................................................................... 111
3.3.3.1 Функціональні вимоги .......................................................................... 111
3.3.3.1 Нефункціональні вимоги ...................................................................... 111
3.4 Моделювання поведінки системи. Діаграма діяльності....................... 113
3.4.1 Даграма комунікації ................................................................................. 116
3.4.2 Діаграма скінченного автомату (Діаграма станів) ............................... 117
РОЗДІЛ 4. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ .................................................................................................. 120
4.1 Розробка програмного комплексу ............................................................ 120
4.1.1 Обґрунтування вибору засобів реалізації .............................................. 120
4.1.2 Опис структурної схеми .......................................................................... 124
4.1.3 Опис логічної схеми системи .................................................................. 125
4.2 Розробка бази даних ..................................................................................... 127
4.3 Розробка інтерфейсу користувача ............................................................ 128
4.4 Тестування системи ..................................................................................... 129
4.4.1 Модульне тестування ............................................................................... 129
4.4.2 Інтеграційне тестування ........................................................................... 133
4.4.3 Системне тестування ................................................................................ 134
4.4.4 Приймальне тестування ........................................................................... 136
ВИСНОВКИ ........................................................................................................... 145
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .......................................................... 145
ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ
БД база даних
UML Unified Modeling Language
HTTP Hyper Text Transfer Protocol
API Application Programming Interface
JWT Json Web Token
DTO Об'єкти для передачі даних
ВСТУП
Актуальність теми. Сучасне суспільство стикається із зростанням
безробіття в галузі права та недостатністю доступу до безоплатної первинної
правничої допомоги. З урахуванням цих факторів виникає потреба в розробці
програмної платформи, спрямованої на вирішення цих проблем.
Застосування сучасних технологій у створенні програмної платформи для
практики молодих спеціалістів у сфері права відкриває шлях до набуття
необхідного досвіду та підвищення їхньої конкурентоспроможності на ринку
праці.
Підходи, використані у даній роботі, спрямовані на вирішення завдання
ефективної побудови програмного забезпечення, що дасть можливість сприяти
подоланню проблеми недостатньої доступності юридичних послуг для широкого
кола населення та розширення можливостей отримання якісної та безкоштовної
юридичної консультації для клієнтів.
Завдяки даній платформі розробляється ефективний механізм, що сприяє
вирішенню актуальних проблем сучасного юридичного середовища та розвитку
новаторських підходів до практичного навчання та доступу до юридичних
послуг для всіх шарів суспільства.
Мета і завдання досліджень. Метою даної роботи є удосконалення
методу розробки програмного забезпечення серверної частини інформаційних
систем первинної правової допомоги та розробка платформи, яка сприятиме
зменшенню безробіття в галузі права та розширенню можливостей отримання
безоплатної первинної правової допомоги.
Завданнями даного дослідження є:
аналіз потреб користувачів в даній галузі;
удосконалення методу розробки програмного забезпечення серверної
частини інформаційних систем первинної правової допомоги та розробка
платформи;
проектування серверної частини програмного забезпечення
інформаційної системи безоплатної первинної правової допомоги;
розробка та тестування серверної частини програмного забезпечення
інформаційної системи безоплатної первинної правової допомоги, з урахуванням
потреб до ефективності функціоналу та забезпечення платформи високим рівнем
безпеки.
Об’єкт досліджень. Програмні системи комп’ютерної комунікації,
призначені для надання правової допомоги населенню, що можуть також
використовуватись для супутнього генерування досвіду молодих фахівців.
Предмет досліджень. Методи розробки програмного забезпечення систем
комп’ютерної комунікації, призначених для надання правової допомоги
населенню, що можуть також використовуватись для супутнього генерування
досвіду молодих фахівців.
Методи досліджень. У ході досліджень використовувалися методи аналізу
вимог користувачів, проектування програмного забезпечення та тестування.
Емпіричний аналіз - це аналіз функціонування аналогічних платформ для
визначення їхнього потенціалу та обмежень. Оцінка реального використання
подібних систем юристами та користувачами для ідентифікації їх ефективності
та недоліків.
Порівняння – оцінка технічних рішень та методів для вибору тих, що
найбільш відповідають поставленим завданням і краще відповідають вимогам.
Розгляд різних підходів для вибору найефективніших та оптимальних рішень.
Моделювання – розробка ескізів або моделей інтерфейсу для попереднього
оцінювання та збору відгуків. Створення прототипів користувацького
інтерфейсу для перевірки його функціональності та ефективності перед
фінальною розробкою.
Формалізація – визначення точних вимог до функціоналу та інтерфейсу
платформи з метою забезпечення її надійної та стійкої роботи. Формалізація
параметрів функціоналу та інтерфейсу для забезпечення стабільної та
ефективної роботи платформи.
Комбінування цих методів дослідження дозволило створити вдале та
ефективне програмне забезпечення серверної частини інформаційних систем
первинної правової допомоги з урахуванням потреб користувачів та
функціональних вимог.
Наукова новизна отриманих результатів полягає в удосконаленні
методу об’єктно-орієнтованого програмування, що дозволяє отримати
вдосконалену структуру програмного забезпечення, забезпечуючи ефективніше
функціонування та підвищуючи загальну продуктивність системи шляхом
впровадження компонентно-базованого підходу до розробки серверної частини
інформаційних систем первинної правової допомоги.
Практичне значення отриманих результатів. Розроблені метод та
платформа можуть бути використані в сфері правозахисту та надання
безоплатної первинної правничої допомоги, полегшуючи взаємодію між
юристами та клієнтами.
Особистий внесок автора. Усі наукові результати, описані в даній роботі,
одержані здобувачем особисто.
Апробація результатів. Опубліковано тези доповіді «Програмне
забезпечення інформаційної системи безоплатної первинної правової допомоги:
серверна частина» в ІІ Міжнародній науково-практичній Інтернет-конференції
«Інновації та перспективні шляхи розвитку інформаційних технологій (іпшріт-
2023)».
РОЗДІЛ 1. ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
Під час аналізу інформації щодо теми дослідження, було виявлено п’ять
основних існуючих методів розв’язання поставленої задачі, а саме:
1 Центр правової допомоги [1] – компанія, яка надає безкоштовні
юридичні онлайн консультації;
2 Юристи.ua [2] – сайт, де надаються юридичні консультації, як платні
так і безкоштовні. Наявний каталог юристів;
3 Правова допомога онлайн [3] – сайт, де надаються платні юридичні
консультації в режимі онлайн, є можливість зв’язатись з юристом
любим зручним способом;
4 Юридична фірма Юдей [4] – фірма, яка надає юридичні консультації на
замовлення клієнта;
5 «Правомен» [5] – телеграм-бот, який відповідає на питання, які задає
клієнт.
Провівши аналіз даних методів було зроблено висновок, що всі ці методи
мають низку спільних параметрів для розв’язання задачі по наданню
консультації клієнту. Було виділено такі параметри:
1 Конфіденційність;
2 Безкоштовність;
3 Можливість обрати юриста;
4 Можливість ознайомитись з даними юриста;
5 Можливість комунікувати з юристом онлайн;
6 Співпраця з реальною людиною.
1.1 Центр правової допомоги
Взаємодія клієнта та юриста відбувається за допомогою сайту (рис.1.1), де
треба залишити заявку на юридичну консультацію, шляхом заповнення поля з
ім’ям, номером телефону, та вказанням міста.
Рис. 1.1 – Головна сторінка сайту «Центр правової допомоги»
Після подання заявки, на сайті з’являється повідомлення про те, що
звернення на отримання консультації прийнято (рис. 1.2). Також нижче
демонструються посилання на відгуки клієнтів у YouTube.
Рис. 1.2 – Повідомлення про прийняття в обробку звернення.
Проаналізувавши методи для розв’язання клієнтських задач, які
представлені даною компанією, було зроблено висновок, що ці методи
задовольняють деякі основні наведені вище параметри. Через те, що на сайті
треба залишати номер телефону, порушується конфіденційність. Надані
консультації є безкоштовними. На сайті немає можливості обрати юриста, та
переглянути каталог юристів, їхні дані, відгуки, тощо. Комунікація відбувається
онлайн з реальною людино (див. табл.1).
Таблиця 1.1
Задовільнені параметри «Центр правової допомоги»
Основні параметри Виконуються
Конфіденційність Ні
Безкоштовність Так
Можливість обрати юриста Ні
Можливість ознайомитись з даними юриста Ні
Можливість комунікувати з юристом онлайн Так
Співпраця з реальною людиною Так
1.2 Юристи.ua
Взаємодія клієнта та юриста також відбувається за допомогою сайту (див.
рис. 2), де є можливість задати питання, та обрати конкретного юриста. Після
переходу за посиланням «Знайти юриста», ми переходимо на сторінку, де можна
обрати свій населений пункт (рис. 1.3) та переглянути каталог юристів, з
відгуками та статистикою (рис. 1.4).
Рис. 1.2 – Головна сторінка сайту Юристи.ua
Рис. 1.3 – Перелік населених пунктів.
Рис. 1.4 – Каталог юристів
Для того щоб подати звернення, треба залишити своє ім’я, електронну
пошту, номер телефону та місто (рис. 1.5).
Рис. 1.5 – Форма для подання звернення
Аналогічно до компанії, представленої вище, методи «Юристи.ua» також
задовольняють деякі виділені параметри. Через те що необхідно вказувати ім’я,
номер телефону та місто, конфіденційність порушується. Наявні як платні, так і
безкоштовні консультації. На сайті є можливость обрати юриста, та переглянути
каталог юристів, їхні дані, відгуки, тощо. Комунікація відбувається онлайн з
реальною людино (див. табл.2).
Таблиця 1.2
Задовільнені параметри «Юристи.ua»
Основні параметри Виконуються
Конфіденційність Ні
Безкоштовність Так
Можливість обрати юриста Так
Можливість ознайомитись з даними юриста Так
Можливість комунікувати з юристом онлайн Так
Співпраця з реальною людиною Так
1.3 Правова допомога онлайн
Взаємодія клієнта та юриста відбувається за допомогою сайту (див. рис.
1.6). Клієнт може задати питання прямо на сайті в режимі онлайн, перейшовши
до чату зі спеціалістом (рис. 1.7).
Рис. 1.6 – Головна сторінка сайту «Правова допомога онлайн»
Рис. 1.7 – Вікно чату зі спеціалістом
Дослідивши запропоновані методи вирішення клієнтських проблем, було
зроблено висновок, що дана компанія аналогічно до попередніх не задовольняє
усім виділеним параметрам. Завдяки комунікації в режимі чату на сайті
зберігається конфіденційність. Надані консультації є платними. Немає
можливості обрати конкретного юриста, та переглянути його статистику та
відгуки. Співпраця відбувається з реальною людиною (див. табл. 3).
Таблиця 1.3
Задовільнені параметри «Юристи.ua»
Основні параметри Виконуються
Конфіденційність Так
Безкоштовність Ні
Можливість обрати юриста Ні
Можливість ознайомитись з даними юриста Ні
Можливість комунікувати з юристом онлайн Так
Співпраця з реальною людиною Так
1.4 Юридична фірма Юдей
Дана фірма представляє низку послуг для фізичних та юридичних осіб,
перелічених на сайті (рис. 1.8). Є можливість обрати вид послуги та замовити
зворотній зв’язок спеціаліста (рис. 1.9).
Рис. 1.8 – Головна сторінка сайту фірми Юдей
Рис. 1.9 – Замовлення послуги
Після дослідження структури взаємодії даної фірми з клієнтами було
зроблено висновок що вона також не відповідає усім поставленим параметрам.
Конфіденційність не зберігається через те що треба залишати ім’я, номер
телефону та електронну пошту. Надані послуги є платними. Немає можливості
обрати конкретного юриста, та переглянути його статистику та відгуки. Немає
можливості комунікувати з юристом в режимі онлайн. Співпраця відбувається з
реальною людиною (див. табл. 4).
Таблиця 1.4
Задовільнені параметри «Юридична фірма Юдей»
Основні параметри Виконуються
Конфіденційність Ні
Безкоштовність Ні
Можливість обрати юриста Ні
Можливість ознайомитись з даними юриста Ні
Можливість комунікувати з юристом онлайн Ні
Співпраця з реальною людиною Так
1.5 «Правомен»
Взаємодія з клієнтом відбувається за допомогою мессенджера Telegram.
Клієнт взаємодіє з ботом, який надає відповіді на запит клієнта (рис. 1.10). На
початку представлена коротка презентація для чого призначений даний бот.
Наступним кроком треба обрати тему, з переліку який надає бот (рис. 1.11). Після
обрання теми бот відправляє абстрактну інформацію по даній темі і пропонує
більш конкретні пункти цієї теми (рис. 1.12). Після обрання конкретного
питання, яке цікавить клієнта, бот надає розширену інформацію по цьому
питанню (рис. 1.13).
Рис. 1.10 – Початок взаємодії з ботом
Рис. 1.11 – Запропоновані теми
Рис. 1.12 – Вибір конкретного пункту тематики
Рис. 1.13 – Розширена інформація по обраній тематиці
Дане рішення є унікальним серед вищеперерахованих, через те, що воно
представлене не у вигляді сайту. Конфіденційність зберігається, тому-що
взаємодія з клієнтом відбувається за допомогою мессенджера. Надана
консультація є безкоштовно. Немає можливості обрати конкретного юриста,
тому-що всю інформацію клієнт отримує від бота. Немає можливості
комунікувати з юристом в режимі онлайн (див. табл. 5).
Таблиця 1.5
Задовільнені параметри «Юридична фірма Юдей»
Основні параметри Виконуються
Конфіденційність Так
Безкоштовність Так
Можливість обрати юриста Ні
Можливість ознайомитись з даними юриста Ні
Можливість комунікувати з юристом онлайн Ні
Співпраця з реальною людиною Ні
Постановка задачі
Розробити платформу, яка стане інноваційним рішенням для надання
юридичних консультацій, що відповідає вимогам сучасного ринку. Основуючись
на аналізі існуючих методів, поставлено завдання створення платформи з такими
ключовими параметрами:
1 Максимальна конфіденційність:
Забезпечення повного та надійного захисту особистих даних користувачів.
2 Безкоштовний доступ:
Забезпечення можливості безоплатного користування платформою для
всіх користувачів.
3 Вибір кваліфікованого юриста:
Можливість вибирати із доступного списку компетентних юристів.
4 Детальна інформація про юристів:
Забезпечення користувачів повною інформацією про кваліфікацію та
досвід юристів.
5 Онлайн комунікація:
Реалізація можливості взаємодії клієнтів з юристами у режимі онлайн.
6 Співпраця з реальними фахівцями:
Можливость співпраці з професійними юристами з реального життя.
Мета полягає у створенні платформи, яка повністю задовольнятиме
потреби користувачів у наданні якісних та доступних юридичних консультацій,
зберігаючи високий рівень конфіденційності та забезпечуючи оптимальний
вибір юристів для кожного клієнта.
Висновок до першого розділу
Зробивши дослідження вже існуючих методів для надання юридичних
консультацій для клієнтів було виявлено, що всі методи мають спільні риси з
платформою, яка представлена в даній роботі. Перевагою розроблюваної
платформи є те, що всі основні переважаючі параметри, в ній будуть
зберігаютися, на відміну від досліджуваних, де вони зберігались лише частково.
Всі перелічені нижче параметри задовольняються представленою в роботі
платформою:
1 Конфіденційність;
2 Безкоштовність;
3 Можливість обрати юриста;
4 Можливість ознайомитись з даними юриста;
5 Можливість комунікувати з юристом онлайн;
6 Співпраця з реальною людиною.
РОЗДІЛ 2. ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ
2.1 Теоретичні дослідження
Розробка на основі компонентівp [6] означає створення нового
програмного продукту за допомогою комбінування готових компонентів з
новими програмами. Цей процес включає у себе створення зв'язків між
компонентами та додавання нового функціоналу. Основними рисами є:
Можливість комбінування, заміни та повторного використання без
докладного розуміння внутрішньої структури: немає необхідності в
глибокому знанні дизайну та реалізації під час поєднання компонентів
у системі; можна заміняти або використовувати компоненти без
необхідності занурення в їхню детальну реалізацію в інших програмах.
Незалежний розвиток: компоненти можуть бути створені, реалізовані,
перевірені, валідовані та розгорнуті самостійно.
Сумісність: компоненти можуть мати різні мови програмування та
парадигми, проте їх можна поєднувати, з'єднувати та взаємодіяти між
собою.
За книгою Шиперського [7]: «Компонент - це одиниця композиції з
договірно визначеними інтерфейсами та повністю явними залежностями від
контексту, яку можна розгорнути незалежно і яка піддається композиції
сторонніми суб'єктами».
Отже, компонент має визначений та необов'язковий інтерфейс, причому
кожен з цих інтерфейсів пов'язаний зі специфікацією, яка називається його
контрактом.
Інтерфейс за формулою (2.1) оголошує набір полів та набір сигнатур
операцій без надання будь-якої семантичної інформації про їхні структури та
реалізації. Тут, з метою інкапсуляції, всі поля, оголошені в інтерфейсі,
припускаються локальними для базового контракту та компонента, тому
недоступні для його середовищ. Середовища можуть отримати доступ лише до
оголошених полів через оголошені методи. Кожне поле у FDec має форму x : T
змінної з її типом, а операція m(in inx, out outx) ∈ MDec оголошує назву операції
та її вхідні та вихідні параметри з їхніми типами. З метою спрощення, ми не
формально розглядаємо типи даних і припускаємо, що у методу є максимум один
вхідний параметр та один вихідний параметр і він записаний у формі m(in u, out
v) у подальшому тексті.
I = ❬FDec, MDec❭
(2.1)
FDec – набір полів
MDec – набір сигнатур
Розглянемо буфер цілих чисел. Він має інтерфейс, який дозволяє
користувачеві вводити та отримувати дані:
B1=❬buff :seq(int), {put(in x:int), get(out y:int)}❭
(2.2)
де seq(int) є типом скінченних послідовностей цілих чисел.
Інтерфейси можна об’єднувати та розширювати, додаючи нові операції.
Контракт інтерфейсу компонента надає семантичну інформацію, яка
визначає, як може бути використаний інтерфейс та дозволяє визначити
динамічну поведінку компонента на інтерфейсі. Тут ми цікавимося лише
компонентами конкурентних та розподілених програмних систем, тому нас
цікавить лише функціональність та протоколи взаємодії компонентів,
виключаючи питання реального часу та інші нефункціональні якості
обслуговуванн із сфери цієї роботи. Формально контракт це кортеж, що має
вигляд:
Ctr (I, Init, MSpec, Prot) (2.3)
де:
I – це інтерфейс;
Init — це предикат, який визначає початкові значення полів у I.FDec;
MSPec призначає кожній операції m(x; y) статичну функціональну
специфікацію;
Prot називається протоколом інтерфейсу, який є набором кінцевих
послідовностей подій виклику методів.
Гіпотеза:
Шляхом удосконалення методу програмування на основі компонентно-
базованого підходу до розробки програмного забезпечення можна покращити
ефективність процесу розробки та функціонування інформаційних систем
первинної правової допомоги.
2.2 Експериментальні дослідження
Головні функції, які повинен використовувати бекенд[8]:
Обробка запитів користувачів на консультації.
Реєстрація та аутентифікація користувачів.
Забезпечення безпеки та конфіденційності інформації користувачів.
Обробка запитів користувачів на консультації (P): Це включає в себе
прийом запитів від клієнтів (у цьому випадку, можливо, від фронтенду), їх
обробку та передачу відповідей. Можна сформулювати це наступним чином:
P = fqh (ЗК)
(2.4)
де ЗК – запити користувачів,
fqh – функція обробки запитів.
Реєстрація та автентифікація користувачів (R): Це може включати
перевірку ідентичності користувача та його реєстрацію в системі. Формула має
вигляд:
R = fa (К)
(2.5)
де К – користувачі,
fa – функція автентифікації.
Забезпечення безпеки та конфіденційності інформації користувачів (S): Це
може охоплювати заходи для збереження даних у безпеці, шифрування, контроль
доступу тощо:
S = fsm (ІК)
(2.6)
де ІК – інформація користувачів,
fsm – заходи безпеки.
2.2.1 Аналіз програмного підходу
Технологія TypeScript[9] була обрана для реалізації backend-частини
проекту з метою забезпечення високої швидкості розробки та підтримки великих
проектів. Завдяки строгій типізації та рядом переваг над «чистим» JavaScript,
мова TypeScript має широке застосування та популярність (рис. 2.1)[10].
Використання бібліотеки NestJS, яка базується на TypeScript, дозволило швидше
створювати масштабовані та стабільні API[11], а також забезпечити простоту
тестування та розширення системи.
Рис. 2.1 Статистика збільшення поширення TypeScript.
Для забезпечення безпеки використовується JWT (JSON Web
Token)(рис.2.2)[12] для автентифікації користувачів. Цей підхід дозволяє
безпечно передавати дані між сторонами, забезпечуючи шифрування та
перевірку цілісності даних.
Рис. 2.2 Статистика стрімкого зростання поширення JWT
Також були вибрані технології, які дозволяють забезпечити високу
продуктивність та ефективність, такі як TypeORM[13] для роботи з базою даних
PostgreSQL[14], що забезпечує оптимальну роботу з великими об'ємами даних.
PostgreSQL була обрана як база даних для цього проекту з кількох ключових
причин:
Надійність та стабільність: PostgreSQL[15] відома своєю надійністю та
стабільністю. Вона має добре розвинену систему контролю цілісності даних та
механізми, які забезпечують безпеку даних, що робить її надійним вибором для
застосунків з високими вимогами до стабільності та безпеки.
Розширені можливості: PostgreSQL має широкий набір функцій та
можливостей, таких як JSON-підтримка, розширені аналітичні можливості та
можливості геопросторових запитів, що дозволяє працювати з різними типами
даних та виконувати складні запити.
Активна спільнота та підтримка: PostgreSQL користується широкою
підтримкою активної спільноти, що робить її відмінним вибором для розвитку,
отримання допомоги, а також доступ до багатьох різноманітних ресурсів та
матеріалів для вивчення та оптимізації роботи з нею.
Сумісність із багатьма іншими технологіями: PostgreSQL інтегрується з
різними інструментами та технологіями, що дозволяє легко використовувати її в
різних екосистемах та забезпечувати максимальну сумісність з іншими
компонентами системи.
Широкі можливості масштабування: PostgreSQL має можливості для
горизонтального та вертикального масштабування, що робить її підходящим
варіантом для проектів, які мають потенціал для зростання обсягів даних та
навантаження на базу даних. Про наявні переваги свідчить статистика, з якої
видно що PostgreSQL є одною з найпоширеніших баз даних (рис. 2.3)[16].
Рис. 2.3 Статистика популярності баз даних.
На етапі вибору інструменту для побудови HTTP запитів було виявлено 2
основних набори інструментів, а саме Swagger і Postman [17].
Swagger [18] - це набір інструментів для розробки, документування та
тестування API. Основна мета Swagger - спростити процес розробки API шляхом
автоматизації створення його документації та надання зручного інтерфейсу для
взаємодії з API.
Swagger сприяє збільшенню ефективності розробки та спрощує взаємодію
між розробниками API та його споживачами, завдяки можливості автоматизації
процесу створення документації, стандартизації формату та спрощенню
тестування API.
Postman [19] - це платформа для розробки API, яка дозволяє створювати,
тестувати та документувати API. Основна мета Postman - полегшити розробку,
тестування та взаємодію з API через інтуїтивний інтерфейс та широкий спектр
функціональностей.
Вибір між Swagger і Postman залежить від конкретних потреб і етапу
життєвого циклу API, на якому ви зосереджується його розробка. Оскільки
основною метою є розробка, документування та забезпечення узгодженості API,
було обрано Swagger. Він чудово забезпечує стандартизований, машиночитаний
спосіб визначення та опису API за допомогою специфікації OpenAPI. Він сприяє
співпраці між командами, запроваджує найкращі методи розробки API та
пропонує інтерактивну документацію через інтерфейс користувача Swagger.
Висновок до другого розділу
У даному розділі було розглянуто ключові аспекти структурної
ідентифікації та функціональність бекенду програмної платформи юридичних
консультацій. Було детально проаналізовано модулі обробки запитів
користувачів, систему автентифікації та авторизації, а також аспекти безпеки та
захисту даних. Це дозволило визначити елементний склад та зв’язки між
підсистемами, забезпечуючи ефективну обробку запитів і забезпечуючи високий
рівень безпеки й доступу до даних.
РОЗДІЛ 3. ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
3.1 Моделювання предметної області
Мета створення моделі предметної області [20] полягає в створенні
візуального відображення логічної структури тієї області, яку досліджуємо.
Логічна модель намагається показати основні сутності у вигляді класів і
відобразити їх взаємозв'язки. Процес побудови цієї моделі розпочинається з
ідентифікації абстракцій, які існують у реальному світі – тобто тих ключових
концепційних об'єктів, що присутні у системі.
Створення моделі предметної області – це відповідальний етап у процесі
розробки. Цей процес передбачає уявлення основних абстракцій, що існують у
системі, та докладне розглядання їх функціональних аспектів. Розробка блок-
схеми з акторами та функціоналом проекту – це лише початок цього важливого
етапу, який вимагає уваги до деталей та глибокого розуміння сутності та
взаємозв'язків між компонентами системи.
3.1.1Предметна область моделювання
На початку моделювання [21] предметної (рис. 3.1) області було зроблено
висновок, що вона буде включати в себе таку сутність як користувачі.
Користувачі – це клієнти, юристи, адміністратори та ментори. Програмна
платформа повинна включати в себе такі функціональні можливості:
1 Отримання юридичної консультації;
2 Запити на консультацію;
3 Реєстрація та авторизація користувачів;
4 Можливості адміністрування та модерування системи.
Взаємодії між сутностями:
1 Юристи надають консультації клієнтам;
2 Клієнти відправляють запити на консультацію;
3 Адміністратори контролюють та модерують систему.
Рис. 3.1 – Основні сутності
3.1.2 Модель предметної області
Після проведення аналізу предметної області, була сформована її модель
(рис.3.2).
Рис. 3.2 – Модель предметної області
Алгоритм роботи платформи ділиться на 4 сценарії:
1 Сценарій клієнта;
2 Сценарій юриста;
3 Сценарій ментора;
4 Сценарій адміністратора;
3.1.3 Елементи моделювання предметної області
3.1.3.1 Сценарій клієнта
Клієнт має вільний доступ до сайту, може переглядати основні розділи
(презентація, команда юристів, команда менторів, відгуки, роботодавцю).
Доступна кнопка «Задати питання», після того як клієнт натискає на неї, його
система його переадресовує на авторизацію. Після успішної авторизації в нього
з’являється можливість почати співпрацю зі спеціалістом. Він може обрати
певного юриста по бажанню, або почати співпрацю з любим юристом.
3.1.3.2 Сценарій юриста
В першу чергу юрист повинен авторизуватись у системі. У нього буде
активна кнопка «Надати відповідь», після натискання на яку він може
переглянути список актуальних звернень і обрати одне з них. Після того як він
обирає звернення, він переходить у приватний чат із клієнтом, де вирішується
його питання.
3.1.3.3 Сценарій ментора
Аналогічно до юриста, ментор також з самого початку повинен пройти
авторизацію. Після авторизації у нього відкривається доступ до перегляду чатів
юристів з клієнтами. Він може обрати чат, який його цікавить, зайти в нього і
почати брати участь в обговоренні.
3.1.3.4 Сценарій адміністратора
Адміністратор також на початку проходить авторизацію. Після авторизації
він отримує доступ до основних можливостей адміністрування платформи:
Доступ до всіх чатів;
Доступ до даних усіх користувачів;
Можливість видаляти користувачів.
Рис. 3.3 – Сценарій дій клієнта
3.1.4 Словник предметної області
До словнику предметної області[22] входять такі поняття:
ПЗ: Додаток, який забезпечує взаємодію між клієнтами та юристами.
Аутентифікація: Процес підтвердження ідентичності користувача,
використовуючи електронну пошту та пароль.
Обліковий запис: Запис користувача, який включає його повне ім'я,
електронну адресу та захешований пароль.
Токен доступу: Унікальний ключ, який отримує користувач після
авторизації для виконання захищених запитів.
Відгук: Користувацький коментар, який може містити контент та рейтинг.
Список відгуків: Перелік відгуків, які користувач може переглядати у
встановленому порядку за датою створення.
Початківці-юристи: Користувачі, які знаходяться на початковому етапі
своєї професійної діяльності та шукають можливостей для отримання реального
досвіду.
Ментори: Досвідчені юристи, які надають допомогу та консультації
початківцям-юристам для вирішення проблем або для контролю роботи з
клієнтами.
Клієнти: Користувачі, які шукають безкоштовні консультації юристів або
хочуть залишатися анонімними під час отримання консультацій.
Суперкористувач (адміністратор): Користувач-адміністратор, який має
повний доступ та можливості керування платформою.
3.2 Формування вимог за допомогою діаграми прецедентів
Діаграми прецедентів (Use Case діаграми)[23] надають чітке візуальне
уявлення про очікування користувачів та способи взаємодії з системою. Вони
створюються для встановлення ключових сценаріїв використання системи та
визначення вимог замовника до її функцій.
Основна ідея полягає в уявленні функціональності системи через історії її
роботи. Ці історії використання допомагають у формулюванні різноманітних
завдань і представляють собою конкретні сценарії взаємодії між користувачами
та системою. Цей підхід дозволяє чітко визначити, як система має працювати у
реальних умовах і враховувати потреби користувачів.
Рис. 3.4 – Use Case діаграма платформи
Пояснення діаграми:
Дана діаграма представляє основні дії, які робитимуть усі користувачі
платформи.
Актори:
Юрист – цей актор представляє юриста, який надає консультації клієнтам.
Ментор – цей актор представляє ментора, який, за необхідності допомагає
юристам у вирішенні питань з клієнтами.
Адміністратор – цей актор представляє адміністратора, який має доступ до
усіх даних, та усіх функцій адміністрування.
Клієнт – цей актор представляє звичайного користувача, який відвідав
платформу для вирішення певного юридичного питання.
Рис. 3.5 – Діаграма компонентів
Пояснення діаграми:
Entities (Сутності):
User: Представляє модель користувача у системі.
Message: Відображає модель повідомлення, яке використовується у чаті.
Review: Представляє модель огляду користувача про інші об'єкти
(наприклад, товари, послуги тощо).
DTOs (Об'єкти для передачі даних):
CreateUserDto: Об'єкт для передачі даних для створення користувача.
CreateMessageDto: Містить дані для створення нового повідомлення в чаті.
CreateReviewDto: Використовується для передачі даних для створення
нового огляду.
Controllers (Контролери):
UsersController: Обробляє HTTP-запити, пов'язані з користувачами
(створення, оновлення, видалення).
ChatGateway: Контролер WebSocket, що відповідає за обробку повідомлень
у чаті.
ReviewsController: Обробляє HTTP-запити для дій, пов'язаних з оглядами.
Services (Сервіси):
UserService: Містить бізнес-логіку, пов'язану з користувачами, включаючи
взаємодію з базою даних.
ChatService: Забезпечує обробку логіки для чату та взаємодії з
повідомленнями.
ReviewsService: Містить функціональність для роботи з оглядами, зокрема,
із зберіганням, оновленням тощо.
Крім того, у діаграмі показані зв'язки між компонентами:
Контролери використовують сервіси для виконання логіки.
DTO використовуються для передачі даних між контролерами та
сервісами.
Кожен сервіс працює з відповідною сутністю (або декількома) та здійснює
операції зберігання та отримання даних.
Взаємодія компонентів:
Звичайно, основна взаємодія між компонентами проекту відбувається
через різні шари:
Контролери (Controllers): Це точка входу для взаємодії з системою через
HTTP або WebSocket. Вони отримують запити від клієнтів та передають їх
відповідним сервісам для подальшої обробки.
Сервіси (Services): Вони містять бізнес-логіку програми. Контролери
викликають методи сервісів для виконання конкретних операцій, таких як
створення користувача, відправка повідомлення у чаті або створення огляду.
DTO (Об'єкти для передачі даних):[24] Ці об'єкти використовуються для
передачі даних між контролерами та сервісами. Вони є засобом обміну
структурованою інформацією, що використовується для виконання операцій в
різних компонентах системи.
Сутності (Entities):[25] Представляють дані, що зберігаються в базі даних.
Сутності використовуються сервісами для здійснення операцій зберігання,
оновлення, видалення та отримання даних.
Взаємодія відбувається за допомогою викликів методів та обміну даними
між цими компонентами:
Контролери отримують HTTP-запити (або WebSocket-повідомлення) від
клієнтів, викликають відповідні методи Сервісів для обробки цих запитів та
передають дані з об'єктів DTO.
Сервіси виконують бізнес-логіку за допомогою отриманих даних та
взаємодіють з Сутностями для отримання або зберігання інформації у базі даних.
Сутності відповідають за зберігання та роботу з реальними даними в базі.
Це спрощена уявна модель взаємодії між компонентами системи. Кожен
компонент виконує свою функцію та спільно працює з іншими компонентами
для досягнення поставлених цілей програми.
3.3 Формування та аналіз вимог
3.3.1 Вимоги замовника
1 ПЗ передбачає створення веб-додатку, який забезпечує можливість
взаємодії клієнтів та юристів.
3.3.2 Вимоги розробника
1 Користувач повинен мати можливість аутентифікуватися в системі,
використовуючи свою електронну пошту та пароль.
2 Користувач може авторизуватися в системі, використовуючи свою
електронну пошту та пароль. Після успішної авторизації користувач отримує
токен доступу для подальшої аутентифікації при виконанні захищених запитів.
3 Користувач може створювати повідомлення, вказуючи контент
повідомлення, ID відправника та ID отримувача. Створені повідомлення
зберігаються в базі даних.
4 Користувач може отримувати список повідомлень та переглядати їх.
Повідомлення відображаються згідно з датою створення в порядку зростання.
5 Користувач може створювати відгуки, вказуючи контент відгуку та
рейтинг. Створені відгуки зберігаються в базі даних.
3.3.3 Детальні вимоги
3.3.3.1 Функціональні вимоги
1 Система має забезпечити безпечну та ефективну можливість реєстрації
та автентифікації для користувачів.
2 Користувач має можливість створювати облікові записи, вказуючи свої
повне ім'я, електронну адресу та пароль. Створені дані користувачів повинні
зберігатися в базі даних захешованими.
3 Користувач може переглядати список відгуків та їх рейтинг. Відгуки
відображаються згідно з датою створення в порядку зростання.
3.3.3.1 Нефункціональні вимоги
1 Забезпечення оперативного обміну даними та швидкого відгуку системи
на запити користувачів.
2 Здатність системи ефективно функціонувати й забезпечувати
родуктивність при збільшенні кількості користувачів.
3 Гарантування захисту особистої інформації користувачів та дотримання
найвищих стандартів безпеки для усіх оброблених даних.
3.3.4 Розгортання програмної системи на апаратних засобах. Діаграма
розгортання
Рис. 3.6 – Діаграма розгортання
Пояснення діаграми:
WebServer та WebClient: Це компоненти, що відповідають веб-серверу та
клієнтській стороні системи відповідно. Клієнтська сторона (WebClient)
взаємодіє з веб-сервером (WebServer).
WebSocket Server та WebClient: Веб-сокет-сервер взаємодіє з клієнтською
стороною (WebClient) для забезпечення двонаправленого зв'язку.
Database Server: Це сервер баз даних, який зберігає і обробляє дані. Він
взаємодіє зі своїм власним сервісом (DatabaseService).
Web Service, WebSocket Service та Database Service: Це сервіси, які
надають функціональність відповідно для веб-серверу, серверу веб-сокетів та
серверу баз даних. Наприклад, WebService надає функціональність веб-серверу
для обробки запитів від клієнтів.
PostgreSQL: Це конкретна система управління базами даних (СУБД), що
використовується для зберігання та керування даними в системі. Він
використовується DatabaseService для взаємодії з базою даних.
3.4 Моделювання поведінки системи. Діаграма діяльності
Модель поведінки системи [26] представляє собою опис алгоритму її
функціонування. Цей спосіб роботи системи визначається групою об’єктів, які
обмінюються повідомленнями та подається у вигляді діаграм діяльності, діаграм
взаємодії та діаграм кінцевого автомата. Щоб описати контрольний потік –
послідовність елементарних кроків під час виконання окремої операції або
складного сценарію використання – діаграма діяльності є зручним інструментом.
Взаємодія між кількома програмними об’єктами може бути описана через
діаграми взаємодії в одному з двох форматів (діаграми послідовності або
діаграми комунікації).
Рис. 3.7 – Діаграма діяльності системи
Пояснення діаграми:
Auth Module: Модуль автентифікації, в якому зосереджені всі
компоненти, необхідні для автентифікації користувачів.
Auth Controller: Контролер автентифікації обробляє запити, пов'язані з
автентифікацією, тобто отриманням доступу до системи.
Auth Service: Сервіс автентифікації виконує логіку автентифікації
користувачів, перевіряючи їхні облікові дані.
Users Module: Модуль користувачів, який містить всі компоненти,
пов'язані з користувачами системи.
Users Controller: Контролер користувачів обробляє запити, що стосуються
дій з користувачами (створення, оновлення, видалення).
Users Service: Сервіс користувачів має логіку, що стосується обробки
запитів до бази даних щодо користувачів.
Database: Це кінцевий пункт, де зберігаються дані користувачів. Всі
запити, що стосуються користувачів, обробляються та зберігаються тут.
Рис. 3.8 – Діаграма послідовності
Пояснення діаграми:
Вхід користувача (login()):
Користувач (актор) ініціює процес входу.
AuthController (контролер автентифікації) отримує запит на вхід.
AuthController передає запит сервісу AuthService (службі
автентифікації).
AuthService взаємодіє з UserService (служба користувачів),
запитуючи інформацію про користувача за електронною поштою.
UserService виконує запит до бази даних через TypeORM, щоб
отримати дані про користувача за його електронною поштою.
Після успішної автентифікації, AuthService повертає
AuthController токен доступу.
AuthController надсилає токен доступу користувачеві.
Реєстрація (signup()):
Користувач ініціює процес реєстрації.
AuthController отримує запит на реєстрацію.
AuthController передає запит до AuthService для реєстрації нового
користувача.
AuthService взаємодіє з UserService для створення нового
користувача.
UserService виконує запит до бази даних через TypeORM, щоб
створити новий запис користувача.
Після успішної реєстрації, AuthService повертає AuthController
повідомлення про успішну реєстрацію.
AuthController надсилає повідомлення про успішну реєстрацію
користувачеві.
Рис. 3.9 – Діаграма послідовності виконання HTTP-запиту в системі
3.4.1 Даграма комунікації
Рис. 3.10 – Діаграма комунікації
Пояснення діаграми:
Створення об'єктів: Клієнти системи (об'єкти User, Message, Review)
створюються через відповідні DTO (CreateUserDto,
CreateMessageDto, CreateReviewDto).
Відправлення та обробка даних сервісами: Створені DTO
відправляються до сервісів (UserService, ChatService,
ReviewsService), де дані обробляються та виконується відповідна
логіка.
Відповіді від сервісів: Після обробки даних, сервіси повертають
відповіді до відповідних об'єктів (User, Message, Review).
Керування через контролери: Інші об'єкти, такі як UsersController,
ChatGateway та ReviewsController, отримують дані від сервісів та
відправляють їх до клієнтів або інших компонентів системи для
подальшої обробки чи відображення.
3.4.2 Діаграма скінченного автомату (Діаграма станів)
Рис. 3.11 – Діаграма станів
Пояснення діаграми:
Неавторизований користувач (Стан 1): Початковий стан, коли користувач
ще не увійшов у систему. Це вихідний пункт для всіх користувачів.
Авторизація (Стан 2): Користувач вводить свої облікові дані для входу в
систему.
Аутентифікація (Стан 3): Система перевіряє введені дані користувача.
Успішна авторизація (Стан 4): Якщо введені дані вірні, користувач
успішно авторизується.
Неуспішна авторизація (Стан 5): Якщо введені дані невірні, користувачу
відмовлено в доступі.
Вихід (Стан 6): Користувач виходить із системи або завершує сеанс.
Перебуває в системі (Стан 7): Користувач вже авторизований і перебуває
в системі, виконуючи різні дії.
Рис. 3.12 Діаграма станів
Пояснення:
ModulesReady (Модулі ініціалізовані): У цьому стані відбувається
ініціалізація модулів програми. Коли модулі готові до використання, система
переходить у наступний стан.
ServicesReady (Сервіси ініціалізовані): Після ініціалізації модулів у стані
"ModulesReady", система продовжує ініціалізацію сервісів. Це означає, що всі
необхідні сервіси для функціонування програми готові.
ControllersReady (Контролери готові): Після успішної ініціалізації сервісів
система готова для ініціалізації контролерів. Це означає, що всі контролери, які
відповідають за обробку різноманітних запитів чи викликів, готові до
використання.
Повернення до початкового стану: Після успішного завершення усіх
необхідних ініціалізацій, система повертається до початкового стану для
можливості переходу до наступного циклу роботи чи обробки подій.
Рис. 3.13 – Діаграма класів
РОЗДІЛ 4. РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
4.1 Розробка програмного комплексу
4.1.1 Обґрунтування вибору засобів реалізації
В якості мови програмування був обраний TypeScript. TypeScript
розширює можливості мови програмування JavaScript і має ряд переваг[27], а
саме:
Статична типізація: TypeScript дозволяє визначати типи даних для змінних,
параметрів функцій, об'єктів та інших елементів. Це допомагає виявляти
помилки під час розробки та забезпечує більшу стабільність коду, оскільки
багато помилок можна виявити на етапі написання коду.
Підтримка ООП:[28] TypeScript підтримує концепції об'єктно-
орієнтованого програмування, такі як класи, спадкування, інтерфейси та багато
інших аспектів, що робить код більш структурованим та організованим,
особливо в більших проектах.
Інтеграція з інструментами розробки:[29] TypeScript інтегрується з
багатьма інструментами розробки та IDE, що забезпечує підказки,
автодоповнення та перевірку коду під час написання. Це сприяє покращенню
продуктивності та зменшенню кількості помилок.
Сумісність із сучасними стандартами:[30] TypeScript підтримує нові
функції та синтаксис JavaScript, але також дозволяє використовувати функції та
можливості, які ще не були офіційно внесені в стандарт JavaScript, забезпечуючи
можливість використання передових функцій.
Більша чіткість та зрозумілість коду:[31] За рахунок визначення типів та
більшої структуризації коду, TypeScript може зробити код більш зрозумілим для
інших розробників, що сприяє підтримці та спільній роботі над проектом.
NestJS Framework[32] був обраний як основа проекту через його
модульну структуру та можливість використання TypeScript. Цей фреймворк
ґрунтується на ефективній архітектурі, яка базується на принципах SOLID та
реалізує патерн MVC (Model-View-Controller), що сприяє створенню
масштабованих та підтримуваних застосунків. Основні переваги даного
фреймворку:
Модульність та структурованість:[33] NestJS пропонує модульну
структуру, що дозволяє розбити застосунок на логічні блоки, що полегшує
організацію коду та його підтримку. Це особливо корисно великим проектам.
Використання TypeScript:[34] Оскільки NestJS базується на TypeScript, він
пропонує переваги статичної типізації, що дозволяє виявляти помилки на етапі
розробки та покращує читабельність коду.
Підтримка HTTP фреймворків: NestJS використовує Express.js або Fastify
для обробки HTTP-запитів, що робить його досить швидким та потужним для
розробки веб-застосунків.
TypeORM[35] був обраний для роботи з базою даних, оскільки це
потужний ORM (Object-Relational Mapping) для TypeScript та JavaScript, що
дозволяє легко взаємодіяти з різними типами баз даних. Він пропонує простий
та зрозумілий спосіб роботи з моделями даних та міграціїми. До переваг входять
TypeORM:
Зручний синтаксис та TypeScript підтримка:[36] TypeORM надає чистий та
зрозумілий синтаксис, особливо для тих, хто використовує TypeScript. Він
забезпечує використання класів та декораторів для опису моделей бази даних,
що полегшує роботу з ними.
Підтримка багатьох СУБД: TypeORM підтримує різні бази даних,
включаючи PostgreSQL, MySQL, SQLite, MS SQL Server та інші, дозволяючи
розробникам працювати з тими системами, які найбільше підходять для їхніх
потреб.
Автоматичне створення таблиць: TypeORM може автоматично створювати
таблиці бази даних на основі описаних моделей, що спрощує розгортання та
розвиток додатків.
Міграції бази даних: Фреймворк надає засоби для керування версіями бази
даних через міграції, що дозволяє контролювати та робити зміни в схемі бази
даних з підтримкою версіювання.
Підтримка зв'язків та асоціацій між таблицями: TypeORM дозволяє
визначати різноманітні типи зв'язків між таблицями (зв'язок один до одного,
один до багатьох, багато до багатьох) за допомогою декораторів, що спрощує
роботу з реляційними даними.
Підтримка запитів та фільтрацій:[37] TypeORM надає можливості для
складання різноманітних SQL-запитів, фільтрацій та умовних виразів за
допомогою свого API, що робить маніпулювання даними більш гнучким.
WebSocketGateway та Socket.IO[38]
WebSocketGateway та бібліотека Socket.IO були використані для реалізації
взаємодії в реальному часі між клієнтом та сервером, забезпечуючи можливість
обміну повідомленнями в режимі реального часу.
JWT[39] був обраний як засіб для автентифікації та авторизації через його
простоту та ефективність. Він дозволяє створювати та верифікувати токени
доступу, зберігаючи стан користувача на стороні клієнта. Перевагами даного
засобу є:
Легкість передачі та компактність: JWT - це компактний токен, який можна
легко передавати через HTTP запити, URL або зберігати у вигляді даних у
браузері.
Самодостатність: JWT містить в собі всю необхідну інформацію про
користувача або його стан (зазвичай, це інформація про автентифікацію або
авторизацію), тому сервер не потребує додаткових запитів до бази даних для
перевірки токена.
Розширюваність та гнучкість: JWT має можливість додавати власні поля,
що робить його гнучким та розширюваним. Це дозволяє включати в токен будь-
яку корисну інформацію, необхідну для додатка.
Автентифікація та авторизація: JWT може бути використаний для
підтвердження автентичності користувача (після успішної автентифікації) та
контролю доступу (авторизації) до ресурсів або маршрутів.
Криптографічний захист: JWT може бути підписаний або зашифрований за
допомогою алгоритмів шифрування, що забезпечує безпеку та недоступність для
модифікацій під час передачі.
Широке використання: JWT використовується в багатьох сучасних
системах для забезпечення безпеки, автентифікації та авторизації, тому він має
широку підтримку та інтеграцію з різними фреймворками та бібліотеками.
Бібліотека class-validator використовується для валідації та перевірки
вхідних даних, що надходять від користувачів, щоб забезпечити правильність та
цілісність даних.
Бібліотека Joi разом з joi-extract-type використовується для валідації
конфігураційних параметрів, що дозволяє контролювати та валідувати вхідні
дані на рівні конфігурації застосунку. Переваги:
Чітка валідація даних: Joi дозволяє вам описати схеми даних у вигляді
об'єктів та визначити правила валідації для кожного поля. Це робить процес
перевірки даних більш чітким та зрозумілим.
Типізація для TypeScript: Joi в поєднанні з joi-extract-type надає можливість
генерації TypeScript типів з визначених схем Joi. Це допомагає у забезпеченні
типізації даних під час розробки, що робить код більш безпечним та
підтримуваним.
Гнучкість та налаштування валідації: Joi дозволяє налаштовувати правила
валідації для різних типів даних, використовуючи вбудовані або власні
валідатори. Це дозволяє гнучко налаштовувати перевірку даних під конкретні
потреби проекту.
Читабельність коду: Інтеграція з joi-extract-type дозволяє створювати
TypeScript типи на основі схем Joi, що робить код більш зрозумілим та легким
для сприйняття.
Підтримка варіантів та узагальнених типів: Joi дозволяє
використовувати варіанти (альтернативні варіанти для даних) та узагальнені
типи (відкриті або закриті групи даних) для створення складних схем даних.
4.1.2 Опис структурної схеми
Файлова структура проекту має наступний вигляд:
e-generator-backend
│
├── src
│ ├── app.controller.ts
│ ├── app.module.ts
│ ├── app.service.ts
│ ├── main.ts
│ │
│ ├── auth
│ │ ├── auth.controller.ts
│ │ ├── auth.module.ts
│ │ ├── auth.service.ts
│ │ ├── dto
│ │ │ ├── login.dto.ts
│ │ │ └── register.dto.ts
│ │ ├── guards
│ │ │ ├── jwt-auth.guard.ts
│ │ │ └── local-auth.guard.ts
│ │ └── strategies
│ │ ├── jwt.strategy.ts
│ │ └── local.strategy.ts
│ │
│ ├── chat
│ │ ├── chat.gateway.ts
│ │ ├── chat.module.ts
│ │ ├── chat.service.ts
│ │ └── dto
│ │ └── create-message.dto.ts
│ │ └── message.entity.ts
│ │
│ ├── config
│ │ ├── configuration.ts
│ │ └── validation.schema.ts
│ │
│ ├── reviews
│ │ ├── dto
│ │ │ └── create-review.dto.ts
│ │ ├── entities
│ │ │ └── review.entity.ts
│ │ ├── reviews.controller.ts
│ │ ├── reviews.module.ts
│ │ └── reviews.service.ts
│ │
│ └── users
│ ├── dto
│ │ ├── create-user.dto.ts
│ │ └── update-user.dto.ts
│ ├── entities
│ │ └── user.entity.ts
│ ├── users.controller.ts
│ ├── users.module.ts
│ └── users.service.ts
│
├── node_modules
├── test
├── .env
├── eslintrc.js
├── .gitignore
├── .prettierrc
├── prettierrc.json
├── app.js
├── eslint.json
├── nest-cli.json
├── ormconfig.json
├── ormconfig.ts
├── package.json
├── package-lock.json
├── README.md
├── ts-config.build.json
└── tsconfig.json
4.1.3 Опис логічної схеми системи
4.1.3.1 Модуль автентифікації (Auth Module)
Auth Controller: Обробляє запити для аутентифікації та авторизації
користувачів.
Auth Service: Здійснює перевірку ідентифікаційних даних користувача та
генерацію JWT-токенів для автентифікації.
LocalAuthGuard & JwtAuthGuard: Перевірка та автентифікація через JWT
та локальний стратегії.
4.1.3.2 Модуль користувачів (Users Module)
User Controller: Обробляє запити, пов'язані з користувачами.
User Service: Надає функціонал для створення, оновлення, видалення та
отримання даних користувачів.
User Entity: Визначає схему таблиці користувачів у базі даних.
User Repository: Робить запити до бази даних для роботи з користувачами.
4.1.3.3 Модуль чату (Chat Module)
Chat Gateway: Забезпечує взаємодію між клієнтом та сервером за
допомогою WebSocket.
Chat Service: Надає можливість відправки та отримання повідомлень у
реальному часі.
4.1.3.4 Модуль відгуків (Reviews Module)
Review Controller: Обробляє запити, пов'язані з відгуками.
Review Service: Надає функціонал для створення, оновлення, видалення та
отримання відгуків.
Review Entity: Визначає схему таблиці відгуків у базі даних.
4.1.3.5 Валідація та безпека
class-validator & bcrypt: Використовуються для валідації вхідних даних та
безпечного зберігання паролів.
JWT: Використовується для створення та верифікації токенів доступу.
Рис. 4.1 – Взаємодія сервісів та модулів
Рис. 4.2 – Діаграма класів системи
4.2 Розробка бази даних
В даній роботі існує база даних, яка включає в себе кілька сутностей для
зберігання даних користувачів, повідомлень та відгуків.
Таблиця користувачів (Users)
id: Унікальний ідентифікатор користувача (первинний ключ).
email: Email користувача (унікальний).
password: Закодований пароль користувача.
fullName: Повне ім'я користувача.
Таблиця повідомлень (Messages)
id: Унікальний ідентифікатор повідомлення (первинний ключ).
content: Зміст повідомлення.
senderId: Зовнішній ключ, що посилається на ідентифікатор користувача,
який є відправником.
receiverId: Зовнішній ключ, що посилається на ідентифікатор
користувача, який є отримувачем.
createdAt: Дата та час створення повідомлення.
updatedAt: Дата та час останньої зміни у повідомленні.
Таблиця відгуків (Reviews)
id: Унікальний ідентифікатор відгуку (первинний ключ).
content: Зміст відгуку.
rating: Оцінка, яку користувач виставив.
authorId: Зовнішній ключ, що посилається на ідентифікатор користувача,
який залишив відгук.
createdAt: Дата та час створення відгуку.
updatedAt: Дата та час останньої зміни у відгуку.
Ці таблиці взаємодіють з модулями проекту та дозволяють зберігати,
оновлювати та отримувати дані про користувачів, повідомлення та відгуки.
Кожна таблиця має відповідні поля для зберігання відповідних даних та
забезпечує зв'язок між різними елементами системи.
4.3 Розробка інтерфейсу користувача
Оскільки представлена робота відповідає за серверну частину програмного
продукту, в неї інтерфейс відсутній як такий. З цього приводу, функціонал був
візуалізований та задокументований через використання Swagger UI. Цей
інструмент надав зручний спосіб описати та перевірити ендпоінти API, що
забезпечило чітку структуру та доступність основних HTTP запитів. Цей
інтерфейс також слугував засобом тестування взаємодії між сервером та
клієнтами, надаючи можливість перевірити правильність обміну даними та
параметрами запитів. Такий підхід спростив розробку та документування API,
що відобразилося на ефективності роботи та зручності для подальшого розвитку
проекту.
4.4 Тестування системи
4.4.1 Модульне тестування
Модульне тестування - це перевірка окремих компонентів (модулів)
програмного забезпечення.
Модульні тести, або unit-тести, розробляють в процесі розробки
програмісти та, іноді, тестувальники білої скриньки (white-box testers). Зазвичай
unit-тести застосовують для того, щоб упевнитися, що код відповідає вимогам
архітектури та має очікувану поведінку[40].
Рис. 4.3 – Модульне тестування на GET запит
Даний код має на меті тестування API застосунку. В даному випадку
використовується бібліотека @nestjs/testing для створення тестового середовища
та supertest для виконання запитів до сервера.
Цей тест тестує базовий GET запит на головну сторінку застосунку ('/').
Після запуску сервера в тестовому середовищі він надсилає GET запит на / та
очікує отримати відповідь з кодом статусу 200 та текстом "Good".
Це простий тест для перевірки, чи працює базовий серверний маршрут.
Якщо запит буде успішним і відповідь відповідатиме очікуваному результату, то
тест пройде успішно.
Файл jest-e2e.json (рис.4.5) налаштовує конфігурацію Jest для тестування.
Рис. 4.5 – Jest конфігурація
Опис файлу:
"moduleFileExtensions": Вказує розширення файлів, які Jest повинен
розглядати як модулі.
"rootDir": Вказує кореневу директорію, звідки Jest почне пошук
файлів для тестів.
"testEnvironment": Вказує середовище, в якому будуть запускатися
тести. У цьому випадку, тести будуть запускатися в середовищі
Node.js.
"testRegex": Визначає регулярний вираз, який визначає файли з
тестами. Тут використовується регулярний вираз .e2e-spec.ts$, що
вказує на файли, які закінчуються на .e2e-spec.ts.
"transform": Налаштування для трансформації файлів під час
тестування. У цьому випадку, використовується ts-jest для компіляції
файлів TypeScript у JavaScript перед виконанням тестів.
Рис. 4.6 – Діаграма послідовності подій у тестуванні
Основні елементи діаграми:
Jest: Це тестовий фреймворк, який відповідає за запуск тестів із заданими
параметрами.
NodeEnvironment: Це оточення виконання для виконання тестів в
середовищі Node.js.
TestFiles: Це набір тестових файлів, які Jest знаходить у проекті за
допомогою регулярних виразів, що вказані у testRegex.
Опис взаємодії:
Jest запускає тести в NodeEnvironment, яке спеціально налаштоване для
виконання тестів.
NodeEnvironment шукає усі файли у проекті, які відповідають шаблону
*.e2e-spec.ts.
Коли файли знайдені, NodeEnvironment повідомляє Jest про знахідку.
Після цього Jest запускає тести знайдених файлів.
У цілому, діаграма показує послідовність дій, що відбуваються при запуску
тестів у Jest в середовищі Node.js, візуальне відображення ключових параметрів
та їх значень, необхідних для правильного виконання тестів у тестовому
середовищі Node.js за допомогою Jest.
Нижче будуть представлені таблиці з результатів тестування всіх
компонентів програми. Дані результати демонструють успішне розгортання
системи, наведене на рисунку 4.7.
Таблиця 4.1
Результати модульного тестування
Компонент Результат
AppModule Успішний запуск
InstanceLoader Успішне завантаження залежностей
TypeOrmModule Успішне завантаження залежностей
PassportModule Успішне завантаження залежностей
ConfigHostModule Успішне завантаження залежностей
ConfigModule Успішне завантаження залежностей
JwtModule Успішне завантаження залежностей
TypeOrmCoreModule Успішне завантаження залежностей
ChatModule Успішне завантаження залежностей
UsersModule Успішне завантаження залежностей
ReviewsModule Успішне завантаження залежностей
AuthModule Успішне завантаження залежностей
4.4.2 Інтеграційне тестування
Інтеграційне тестування спрямоване на перевірку взаємодії між різними
компонентами програмного забезпечення. Тут документується тестування
спільної роботи окремих модулів, їх інтеграція та взаємодія в межах
системи(див.рис.4.6).
Test Execution by Jest:
Файл jest-e2e.json визначає конфігурацію Jest для e2e тестів.
Запуск тестів відбувається у визначеному тестовому середовищі (Node.js).
Initialization:
Файл app.e2e-spec.ts містить тестовий сценарій.
Завантаження тестового модуля за допомогою Test.createTestingModule().
Before Each Test:
Перед кожним тестом виконується підготовка через beforeEach.
Створення інстансу застосунку app = moduleFixture.createNestApplication().
Test Execution:
Тестування виконується через методи it() та expect() з використанням
request(app.getHttpServer()).
HTTP Request:
Відправка HTTP-запиту до застосунку через supertest з вказанням
очікуваного результату (expect()).
Таблиця 4.2
Результати інтеграційного тестування
Інтегровані Компоненти Результат
AppModule + InstanceLoader + Успішне завантаження
TypeOrmModule залежностей
PassportModule + ConfigHostModule + Успішне завантаження
ConfigModule залежностей
JwtModule + TypeOrmCoreModule + Успішне завантаження
TypeOrmModule залежностей
TypeOrmModule + ChatModule Успішне завантаження
залежностей
UsersModule + ReviewsModule + Успішне завантаження
AuthModule залежностей
4.4.3 Системне тестування
Системне тестування описує перевірку системи як цілісності, включаючи
всі її складові. Тут виконується перевірка відповідності вимогам та
специфікаціям. Проводяться тести, що перевіряють роботу системи в цілому, її
здатність виконувати очікувані функції та сценарії взаємодії. Під час запуску
додатка система проходить через наступні події (див.рис.4.7):
Starting Nest application: Початок запуску додатка на основі Nest.js.
AppModule dependencies initialized: Ініціалізація залежностей
AppModule, модуля вашого додатка.
TypeOrmModule dependencies initialized: Ініціалізація залежностей
модуля TypeORM, що використовується для роботи з базою даних.
PassportModule dependencies initialized: Ініціалізація залежностей
модуля Passport, який може використовуватися для аутентифікації.
ConfigModule dependencies initialized: Ініціалізація залежностей модуля
Config, який може використовуватися для роботи з конфігурацією.
JwtModule dependencies initialized: Ініціалізація залежностей модуля
Jwt, який може використовуватися для роботи з токенами
аутентифікації.
ChatModule dependencies initialized: Ініціалізація залежностей модуля
чату.
UsersModule dependencies initialized: Ініціалізація залежностей модуля
користувачів.
ReviewsModule dependencies initialized: Ініціалізація залежностей
модуля відгуків.
AuthModule dependencies initialized: Ініціалізація залежностей модуля
аутентифікації.
ChatGateway subscribed to the "sendMessage" message: Підписка на
повідомлення "sendMessage" в чаті через веб-сокети.
ChatGateway subscribed to the "joinRoom" message: Підписка на
повідомлення "joinRoom" в чаті через веб-сокети.
ChatGateway subscribed to the "leaveRoom" message: Підписка на
повідомлення "leaveRoom" в чаті через веб-сокети.
RoutesResolver: Резольвер маршрутів, що відповідає за визначення
маршрутів вашого додатка.
RouterExplorer: Досліджувач роутів, який мапує URL-адреси на
відповідні функції (методи контролерів) вашого додатка.
Nest application successfully started: Повідомлення про успішний запуск
додатка.
Таблиця 4.2
Результати системного тестування
Функціональність/Сценарій Результат
AuthController Маппінг роутів успішний
RouterExplorer Маппінг роутів успішний
NestApplication Успішний запуск
Рис. 4.7 – Успішний запуск системи
4.4.4 Приймальне тестування
Для візуалізації роботи та тестування був обраний Swagger (рис 4.4). Це
інструмент для документування та тестування API. Його використання в проекті
має кілька ключових переваг. По-перше, Swagger надає можливість автоматичної
генерації документації API на основі самого коду, що дозволяє швидко та зручно
відстежувати всі доступні ендпоінти, їх параметри та структуру відповідей.
Крім цього, Swagger відображає структуру запитів і відповідей у
зрозумілій формі, що сприяє зручному використанню API для інших розробників
або команди, а також сприяє більш швидкому розгортанню проектів та спільній
роботі між різними командами.
Рис. 4.8 – Ендпоінти та можливі види запитів
На рисунку вище представлені ендпоінти. Взаємодія відбувається шляхом
HTTP (Hyper Text Transfer Protocol) запитів. В даній роботі присутні POST, GET,
PUT та DELETE запити.
Для того щоб створити запит та виконати його, треба обрати цікавлячий
ендпоінт та заповнити поле Request body (якщо це POST-запит). В цьому полі
вже написаний зразок тіла запиту (рис. 4.5). Такі зразки будуть написані також і
в інших полях, за допомогою шаблонів DTO (Data Transfer Object)(рис.4.6). Після
того як поле заповнене, натискаємо кнопку Execute і запит виконується (рис.4.7).
Рис. 4.9 – Початок виконання HTTP запиту
Рис. 4.10 – Шаблони створення та оновлення користувача
Рис. 4.11 – Успішне виконання запиту
На рисунку вище представлене успішне виконання HTTP запиту. У
відповідь на запит отримуємо Response body, в якому інформується що
користувач зареєстрований, та демонструються його дані. Завдяки
використанню bycript, пароль користувача закодований у набір символів, і в
такому вигляді буде зберігатись у базі даних.
Рис. 4.12 – Виконання запиту на авторизацію
Далі виконуємо запит на авторизацію (рис.4.13) новоствореного
користувача. Як і в минулому запиті, заповнюємо поле Request body, вказуючи
електронну пошту та пароль користувача.
Рис. 4.13 – Успішна авторизація
У відповідь отримуємо JWT-токен доступу. Переконавшись в тому, що
користувач створюється та успішно авторизується протестуємо GET запит
(рис.4.14) на перегляд користувачів, які вже зареєстровані. Оскільки це GET
запит, в нього немає полів для заповнення.
Рис. 4.14 – Виконання запиту на перегляд користувачів
Рис. 4.15 – Успішне виконання запиту на перегляд користувачів
У відповідь ми отримали Response body з об’єктами користувачів, які
зареєстровані.
Далі проводим тестування на залишення відгуку. Заповнюємо Request body
за зразком і виконуємо HTTP запит (рис. 4.16).
Рис. 4.16 – Створення відгуку
Рис. 4.17 – Успішне виконання запиту
Перевіряємо створення відгуку, за допомогою GET запиту за відповідним
еднпоінтом (рис. 4.18).
Рис. 4.18 – Виконання запиту на наявні відгуки
У відповідь отримаємо Response body з відгуком, який був створений
раніше. Отже, можемо переконатись у успішній роботі по збереженню даних у
базу.
Рис. 4.19 – Успішне виконання запиту
Створення користувачів та відгуків працює успішно. Тепер треба
перевірити можливість їх видалення. Виконуємо по черзі DELETE запити на
видалення користувача та відгуку. Після виконання, перевіряємо наявність
відповідних користувачів та відгуків у базі даних.
Рис. 4.20 – Виконання запиту на видалення відгуку
Рисунок 4.21 – Успішне виконання запиту на видалення відгуку
Бачимо, що при спробі знайти відгук з id 1, сервер повертає помилку зі
статус кодом 404 Not found і у Response body інформується що такий відгук не
знайдений, що свідчить про успішне виконання DELETE запиту.
Рис. 4.22 – Виконання запиту на видалення користувача
Рис. 4.23 – Успішне видалення користувача
Аналогічно до відгуків, отримуємо помилку 404 при спробі знайти
видаленого користувача. Response body також інформує про те що користувач не
знайдений.
Таблиця 4.1
Результати тестування роботи HTTP-запитів
Очікуваний Фактичний
№ Опис тесту Статус
результат результат
1 POST Успішний логін Успішний логін
Пройдено
/api/auth/login користувача користувача
2 POST Успішна Успішна Пройдено
/api/auth/signup реєстрація реєстрація
користувача користувача
3 GET Отримання Інформація про
/api/auth/profile профілю профіль Пройдено
користувача користувача
4 POST /api/users Додавання
Новий користувач
нового Пройдено
успішно доданий
користувача
5 GET /api/users Отримання
Список
списку Пройдено
користувачів
користувачів
Продовження таблиці 4.1
6 GET Отримання Інформація про
Пройдено
/api/users/{id} користувача за ID користувача за ID
7 PUT Оновлення Користувача
Пройдено
/api/users/{id} користувача за ID оновлено
8 DELETE Видалення Користувача
Пройдено
/api/users/{id} користувача за ID видалено
9 POST /api/reviews Додавання Новий відгук
Пройдено
нового відгуку успішно доданий
10 GET /api/reviews Отримання
Список відгуків Пройдено
списку відгуків
11 GET Отримання Інформація про
Пройдено
/api/reviews/{id} відгуку за ID відгук за ID
12 PUT Оновлення
Відгук оновлено Пройдено
/api/reviews/{id} відгуку за ID
13 DELETE Видалення
Відгук видалено Пройдено
/api/reviews/{id} відгуку за ID
ВИСНОВКИ
Дана робота є результатом отриманих знань та навичок, які були отримані
під час навчання. Досліджуючи предметну область, виявлено, що розробка
програмного забезпечення, головною метою якого, є створення спільної
платформи для клієнтів та юристів, значно полегшить задачу для початківців у
сфері юриспруденції та, водночас, буде корисним для малозабезпеченої верстви
населення, яка прагне отримати юридичну допомогу. Також дозволить юристам,
що тільки починають свою практику, отримати реальний досвід роботи з
клієнтами. Такий підхід сприятиме підвищенню їхньої компетентності та
наданню якісних безкоштовних консультацій для потенційних клієнтів. Це
дозволить не тільки безоплатно отримати якісні поради, але й сприятиме
заохоченню молодих фахівців до поглиблення своєї експертизи та забезпечить
клієнтам більший доступ до правової допомоги. Такий підхід відкриває нові
можливості для початківців у сфері права та сприяє підвищенню рівня
доступності юридичних послуг для громадян, що потребують допомоги.
Була реалізована серверна частина програмного забезпечення для такої
платформи з використанням сучасних рішень в бекенді, які на даний момент
користуються широкою популярністю. Програмна частина була створена
шляхом використання найсучасніших рішень та практик, які є на даний момент
в цій сфері.
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Центр правової допомоги, безкоштовна консультація юриста, URL:
https://urist24.com.ua/?utm_source=google&utm_medium=cpc&utm_campaig
n=g&utm_content=684782229737&utm_term=%D1%86%D0%B5%D0%BD
%D1%82%D1%80%20%D0%BF%D1%80%D0%B0%D0%B2%D0%BE%D
0%B2%D0%BE%D1%97%20%D0%B4%D0%BE%D0%BF%D0%BE%D0%
BC%D0%BE%D0%B3%D0%B8&gad_source=1&gclid=CjwKCAiAs6-
sBhBmEiwA1Nl8syvmgfvEQ0hiO7LFiz2hKt9C5zM_13_XKDpALA3w1cEX
XWzuygh9-RoCg8YQAvD_BwE
2 Юридична консультація онлайн, URL: https://uristy.ua/ua
3 Правова допомога юриста, адвоката URL: https://advice-online.net/
4 Юридична фірма юдей, URL: https://yudey.com.ua/
5 Правомен, чат-бот консультант з правових питань, URL:
https://pravoman.com/
6 Конспект лекцій Дніпровського державного технологічного університету
з дисципліни «Архітектура та проектування програмного забезпечення»,
ст. 14, URL: https://www.dstu.dp.ua/Portal/Data/3/19/3-19-kl34.pdf
7 C. Szyperski. Component Software: Beyond Object-Oriented Programming.
Addison-Wesley, 1997
8 The Key Purpose Of Backend Development And Its Importance, стаття у
мережі інтернет, URL: https://imarticus.org/blog/the-key-purpose-of-
backend-development-and-its-importance/
9 Офіційна сторінка TypeScript, URL: https://www.typescriptlang.org/
10 Статистика використання TypeScript на npmtrends, URL:
https://npmtrends.com/typescript
11 Прикладний програмний інтерфейс, URL:
https://uk.wikipedia.org/wiki/Прикладний_програмний_інтерфейc
12 Статистика використання JWT НА Drupal, URL:
https://www.drupal.org/project/usage/jwt
13 SQL (TypeORM), URL:https://docs.nestjs.com/recipes/sql-typeorm
14 PostgreSQL, головна сторінка, URL: https://www.postgresql.org/
15 Why PostgreSQL Is a Top Choice for Enterprise-level, стаття у мережі
інтернет, URL: https://www.percona.com/blog/why-postgresql-is-a-top-
choice-for-enterprise-level-databases/
16 Статистика популярності БД, Стаття у мережі інтернет, URL:
https://www.statista.com/statistics/809750/worldwide-popularity-ranking-
database-management-systems/
17 Swagger vs Postman | Top 10 Differences You Should Know, Стаття у
мережі інтернет, URL: https://testsigma.com/blog/swagger-vs-postman/
18 Swagger, головна сторінка, URL: https://swagger.io/
19 Postman, головна сторінка, URL: https://www.postman.com/
20 Предмета область, стаття у мережі інтернет, URL:
https://uk.wikipedia.org/wiki/Предметна_область
21 Процес моделювання предметної області. Гайд для бізнес-аналітиків,
Стаття у мережі інтернет, URL: https://dou.ua/forums/topic/42366/
22 Словники в предметній області, Стаття у мережі інтернет, URL:
http://blog.khmelyuk.com/2009/03/c.html
23 Конспект лекцій Дніпровського державного технологічного університету
з дисципліни «Архітектура та проектування програмного забезпечення»,
ст. 17, URL: https://www.dstu.dp.ua/Portal/Data/3/19/3-19-kl34.pdf
24 DTO - A typescript utility type, Стаття у мережі інтернет, URL:
https://dev.to/tamj0rd2/dto-a-typescript-utility-type-4o3m
25 Defining Entity Objects in TypeScript, Стаття у мережі інтернет, URL:
https://visualstudiomagazine.com/articles/2013/05/01/defining-entity-objects-
in-typescript.aspx
26 Лекція 12. Нотація UML. Моделювання поведінки, Луцький
національний технічний університет, URL:
https://elib.lntu.edu.ua/sites/default/files/elib_upload/%D0%9A%D0%BE%D0
%BD%D0%B4%D1%96%D1%83%D1%81%202%20%D0%B3%D0%BE%
D1%82%D0%BE%D0%B2%D0%B2%D0%B0/page15.html
27 TypeScript vs. JavaScript: Your Go-to Guide, Стаття у мережі інтернет,
URL: https://www.toptal.com/typescript/typescript-vs-javascript-guide
28 Object Oriented Programming with TypeScript Стаття у мережі інтернет,
URL: https://dev.to/kevin_odongo35/object-oriented-programming-with-
typescript-574o
29 Everything You’ve Always Wanted to Know About TypeScript’s Integration
in WebStorm, Стаття у мережі інтернет, URL:
https://blog.jetbrains.com/webstorm/2024/01/everything-you-ve-always-
wanted-to-know-about-typescript-s-integration-in-webstorm/
30 Using modern decorators in TypeScript, Стаття у мережі інтернет, URL:
https://blog.logrocket.com/using-modern-decorators-typescript/
31 TypeScript vs JavaScript: Know The Difference, Стаття у мережі інтернет,
URL: https://radixweb.com/blog/typescript-vs-javascript
32 Nest.JS, головна сторінка, URL: https://nestjs.com/
33 NestJS: A Double-Edged Sword of Structure and Complexity, Стаття у
мережі інтернет, URL: https://www.linkedin.com/pulse/nestjs-double-edged-
sword-structure-complexity-alex-koltun
34 Node.js, TypeScript, and Nest.js — A winning combination, Стаття у мережі
інтернет, URL: https://medium.com/israeli-tech-radar/node-js-typescript-and-
nest-js-a-winning-combination-ad31e4109385
35 TypeORM, головна сторінка, URL: https://typeorm.io/
36 TypeORM - it's not what you think., Стаття у мережі інтернет, URL:
https://www.reddit.com/r/typescript/comments/lwje83/typeorm_its_not_what_
you_think/?rdt=39013
37 TypeORM - Query, Стаття у мережі інтернет, URL:
Builderhttps://www.tutorialspoint.com/typeorm/typeorm_query_builder.htm
38 Socket.IO vs. WebSocket: Key differences and which to use, Стаття у мережі
інтернет, URL: https://ably.com/topic/socketio-vs-websocket
39 JWT, головна сторінка, URL https://jwt.io/
40 Модульне тесування, Стаття у мережі інтернет, URL:
https://uk.wikipedia.org/wiki/Модульне_тестування
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС,
професор
_____________ Голуб С.В.
„____” _________________ 2023 р.
Програмне забезпечення інформаційної системи безоплатної первинної
правової допомоги: серверна частина
Специфікація
482.ЧДТУ.232210.01
Листів 2
Розробник ________________ Кретов О.В.
2023
482.ЧДТУ.232210.01
Позначення Найменування Примітка
482.ЧДТУ. 221539.01 12 01 Текст програми
482.ЧДТУ. 221539.01 34 01 Інструкція користувача
482.ЧДТУ. 221539.01 90 01 Графічний матеріал
482.ЧДТУ.232210.01
ДОДАТОК Б
Програмне забезпечення інформаційної системи безоплатної первинної
правової допомоги: серверна частина
Текст програми
482.ЧДТУ. 221539.01 12 01
Листів 16
Розробник ________________ Кретов О.В
2023
79
482.ЧДТУ.232210.01
Код файлу login.dto.ts:
import { IsEmail, IsNotEmpty, IsString } from 'class-validator';
export class LoginDto {
@IsNotEmpty()
@IsEmail()
email: string;
@IsNotEmpty()
@IsString()
password: string;
}
Код файлу register.dto.ts:
import { IsEmail, IsNotEmpty, IsString, Matches, MinLength } from 'class-validator';
export class RegisterDto {
@IsNotEmpty()
@IsString()
fullName: string;
@IsNotEmpty()
@IsEmail()
email: string;
@IsNotEmpty()
@IsString()
@MinLength(8)
@Matches(/((?=.*\d)|(?=.*\W+))(?![.\n])(?=.*[A-Z])(?=.*[a-z]).*$/, {
message: 'Password too weak',
})
password: string;
}
Код файлу jwt-auth.guard.ts:
import { Injectable } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';
@Injectable()
export class JwtAuthGuard extends AuthGuard('jwt') {
constructor() {
super();
}
}
Код файлу local-auth.guard.ts:
import { Injectable } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';
@Injectable()
ЧДТУ 232210.012 ПЗ
export class LocalAuthGuard extends AuthGuard('local') {
constructor() {
super();
}
}
Код файлу auth.controller.ts:
import {Controller, Post, Body, Req, UseGuards, Get, HttpCode, HttpStatus} from
'@nestjs/common';
import { AuthService } from './auth.service';
import { CreateUserDto } from '../users/dto/create-user.dto';
import { LocalAuthGuard } from './guards/local-auth.guard';
import { JwtAuthGuard } from './guards/jwt-auth.guard';
import { Request } from 'express';
import {LoginDto} from "./dto/login.dto";
@Controller('auth')
export class AuthController {
constructor(private authService: AuthService) {}
@UseGuards(LocalAuthGuard)
@Post('login')
async login(@Body() login: LoginDto) {
console.log(login);
return this.authService.login(login);
}
@Post('signup')
@HttpCode(HttpStatus.CREATED)
async signup(@Body() createUserDto: CreateUserDto) {
const user = await this.authService.signup(createUserDto);
return { message: 'User successfully registered', user };
}
@UseGuards(JwtAuthGuard)
@Get('profile')
getProfile(@Req() req: Request) {
console.log(req);
}
}
Код файлу auth.module.ts:
import { Module } from '@nestjs/common';
import { AuthService } from './auth.service';
import { AuthController } from './auth.controller';
import { UsersModule } from '../users/users.module';
import { PassportModule } from '@nestjs/passport';
import { JwtModule } from '@nestjs/jwt';
import { LocalStrategy } from './strategies/local.strategy';
import { JwtStrategy } from './strategies/jwt.strategy';
import { ConfigModule, ConfigService } from '@nestjs/config';
@Module({
imports: [
UsersModule,
PassportModule,
81
ЧДТУ 232210.012 ПЗ
ConfigModule,
JwtModule.registerAsync({
imports: [ConfigModule],
useFactory: async (configService: ConfigService) => ({
secret: configService.get('JWT_SECRET'),
signOptions: { expiresIn: '60s' }, // Token validity period
}),
inject: [ConfigService],
}),
],
controllers: [AuthController],
providers: [AuthService, LocalStrategy, JwtStrategy],
exports: [AuthService], // Export AuthService to use it in other modules
})
export class AuthModule {}
Код файлу auth.service.ts:
import { Injectable } from '@nestjs/common';
import { JwtService } from '@nestjs/jwt';
import { UsersService } from '../users/users.service';
import * as bcrypt from 'bcrypt';
import {CreateUserDto} from "../users/dto/create-user.dto";
@Injectable()
export class AuthService {
constructor(
private usersService: UsersService,
private jwtService: JwtService,
) {}
async validateUser(email: string, pass: string): Promise<any> {
const user = await this.usersService.findByEmail(email);
if (user && await bcrypt.compare(pass, user.password)) {
const { password, ...result } = user;
return result;
}
return null;
}
async signup(createUserDto: CreateUserDto) {
const { password } = createUserDto;
const salt = await bcrypt.genSalt();
const hashedPassword = await bcrypt.hash(password, salt);
const newUser = {
...createUserDto,
password: hashedPassword,
};
82
ЧДТУ 232210.012 ПЗ
return this.usersService.create(newUser);
}
async login(user: any) {
const payload = { email: user.email, sub: user.id };
return {
access_token: this.jwtService.sign(payload),
};
}
}
Код файлу create-message.dto.ts:
import { IsNotEmpty, IsString, IsInt } from 'class-validator';
export class CreateMessageDto {
@IsNotEmpty()
@IsString()
content: string;
@IsNotEmpty()
@IsInt()
senderId: number;
@IsNotEmpty()
@IsInt()
receiverId: number;
}
Код файлу message.entity.ts:
import { Entity, Column, PrimaryGeneratedColumn, ManyToOne, CreateDateColumn,
UpdateDateColumn } from 'typeorm';
import {User} from "../../users/entities/user.entity";
@Entity()
export class Message {
@PrimaryGeneratedColumn()
id: number;
@Column('text')
content: string;
@Column()
senderId: number;
@Column()
receiverId: number;
@ManyToOne(() => User, (user) => user.sentMessages)
sender: User;
@ManyToOne(() => User, (user) => user.receivedMessages)
receiver: User;
@CreateDateColumn()
83
ЧДТУ 232210.012 ПЗ
createdAt: Date;
@UpdateDateColumn()
updatedAt: Date;
}
Код файлу chat.gateway.ts:
import {
WebSocketGateway,
SubscribeMessage,
MessageBody,
ConnectedSocket,
WebSocketServer,
} from '@nestjs/websockets';
import { Server, Socket } from 'socket.io';
import { ChatService } from './chat.service';
import { CreateMessageDto } from './dto/create-message.dto';
@WebSocketGateway({
cors: {
origin: '*',
},
})
export class ChatGateway {
@WebSocketServer()
server: Server;
constructor(private chatService: ChatService) {}
@SubscribeMessage('sendMessage')
async handleMessage(
@MessageBody() createMessageDto: CreateMessageDto,
@ConnectedSocket() client: Socket,
): Promise<void> {
const message = await this.chatService.sendMessage(createMessageDto);
this.server.to(message.receiverId.toString()).emit('messageReceived', message);
}
@SubscribeMessage('joinRoom')
handleJoinRoom(
@MessageBody() room: string,
@ConnectedSocket() client: Socket,
): void {
client.join(room);
}
@SubscribeMessage('leaveRoom')
handleLeaveRoom(
@MessageBody() room: string,
@ConnectedSocket() client: Socket,
): void {
client.leave(room);
}
84
ЧДТУ 232210.012 ПЗ
handleConnection(client: Socket, ...args: any[]) {
console.log(`Client connected: ${client.id}`);
}
handleDisconnect(client: Socket) {
console.log(`Client disconnected: ${client.id}`);
}
}
Код файлу chat.module.ts:
import { Module } from '@nestjs/common';
import { ChatGateway } from './chat.gateway';
import { ChatService } from './chat.service';
import { TypeOrmModule } from '@nestjs/typeorm';
import { Message } from './entities/message.entity';
import { UsersModule } from '../users/users.module';
@Module({
imports: [
TypeOrmModule.forFeature([Message]),
UsersModule,
],
providers: [
ChatGateway,
ChatService,
],
exports: [
ChatService,
]
})
export class ChatModule {}
Код файлу chat.service.ts:
import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { Message } from './entities/message.entity';
import { CreateMessageDto } from './dto/create-message.dto';
@Injectable()
export class ChatService {
constructor(
@InjectRepository(Message)
private messageRepository: Repository<Message>,
) {}
async sendMessage(createMessageDto: CreateMessageDto): Promise<Message> {
const message = this.messageRepository.create(createMessageDto);
await this.messageRepository.save(message);
return message;
}
async getChatHistory(userId1: number, userId2: number): Promise<Message[]> {
85
ЧДТУ 232210.012 ПЗ
return this.messageRepository.find({
where: [
{ senderId: userId1, receiverId: userId2 },
{ senderId: userId2, receiverId: userId1 }
],
order: {
createdAt: 'ASC',
},
});
}
}
Код файлу validation.schema.ts:
import * as Joi from '@hapi/joi';
import 'joi-extract-type';
export const validationSchema = Joi.object({
PORT: Joi.number().default(3000),
HOST: Joi.string().default('localhost'),
NODE_ENV: Joi.string()
.valid('development', 'production', 'test')
.default('development'),
DATABASE_HOST: Joi.string().required(),
DATABASE_PORT: Joi.number().default(5432),
DATABASE_USERNAME: Joi.string().required(),
DATABASE_PASSWORD: Joi.string().required(),
DATABASE_NAME: Joi.string().required(),
JWT_SECRET: Joi.string().required(),
EMAIL_SERVICE: Joi.string(),
EMAIL_USERNAME: Joi.string(),
EMAIL_PASSWORD: Joi.string(),
EXTERNAL_API_KEY: Joi.string(),
});
Код файлу create-review.ts:
import { IsInt, IsNotEmpty, IsString, Max, Min } from 'class-validator';
import {ApiProperty} from "@nestjs/swagger";
export class CreateReviewDto {
@ApiProperty({ example:'Your review' })
@IsNotEmpty()
@IsString()
content: string;
@ApiProperty({ example: 5})
@IsNotEmpty()
@IsInt()
@Min(1)
@Max(5)
rating: number;
@ApiProperty({ example: 25 })
@IsNotEmpty()
@IsInt()
authorId: number;
86
ЧДТУ 232210.012 ПЗ
}
Код файлу review.entity.ts:
import { Entity, Column, PrimaryGeneratedColumn, ManyToOne } from 'typeorm';
import { User } from '../../users/entities/user.entity';
@Entity()
export class Review {
@PrimaryGeneratedColumn()
id: number;
@Column({ type: 'text' })
content: string;
@Column()
rating: number;
@ManyToOne(() => User, user => user.reviews)
author: User;
}
Код файлу review.controller.ts:
import { Body, Controller, Delete, Get, Param, Post, Put } from '@nestjs/common';
import { ReviewsService } from './reviews.service';
import { CreateReviewDto } from './dto/create-review.dto';
import { Review } from './entities/review.entity';
@Controller('reviews')
export class ReviewsController {
constructor(private readonly reviewsService: ReviewsService) {}
@Post()
create(@Body() createReviewDto: CreateReviewDto): Promise<Review> {
return this.reviewsService.create(createReviewDto);
}
@Get()
findAll(): Promise<Review[]> {
return this.reviewsService.findAll();
}
@Get(':id')
findOne(@Param('id') id: number): Promise<Review> {
return this.reviewsService.findOne(id);
}
@Put(':id')
update(@Param('id') id: number, @Body() updateReviewDto: CreateReviewDto):
Promise<Review> {
return this.reviewsService.update(id, updateReviewDto);
}
@Delete(':id')
remove(@Param('id') id: number): Promise<void> {
return this.reviewsService.remove(id);
87
ЧДТУ 232210.012 ПЗ
}
}
Код файлу reviews.module.ts:
import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';
import { ReviewsController } from './reviews.controller';
import { ReviewsService } from './reviews.service';
import { Review } from './entities/review.entity';
@Module({
imports: [
TypeOrmModule.forFeature([Review]),
],
controllers: [ReviewsController],
providers: [ReviewsService],
})
export class ReviewsModule {}
Код файлу reviews.service.ts:
import { Injectable, NotFoundException } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { Review } from './entities/review.entity';
import { CreateReviewDto } from './dto/create-review.dto';
@Injectable()
export class ReviewsService {
constructor(
@InjectRepository(Review)
private reviewsRepository: Repository<Review>,
) {}
async create(createReviewDto: CreateReviewDto): Promise<Review> {
const review = this.reviewsRepository.create(createReviewDto);
await this.reviewsRepository.save(review);
return review;
}
async findAll(): Promise<Review[]> {
return this.reviewsRepository.find();
}
async findOne(id: number): Promise<Review> {
const review = await this.reviewsRepository.findOne({
where: {
id,
},
});
if (!review) {
throw new NotFoundException(`Review with ID "${id}" not found`);
}
return review;
}
88
ЧДТУ 232210.012 ПЗ
async update(id: number, updateReviewDto: CreateReviewDto): Promise<Review> {
const review = await this.findOne(id);
Object.assign(review, updateReviewDto);
await this.reviewsRepository.save(review);
return review;
}
async remove(id: number): Promise<void> {
const result = await this.reviewsRepository.delete(id);
if (result.affected === 0) {
throw new NotFoundException(`Review with ID "${id}" not found`);
}
}
}
Код файлу create-user.dto.ts:
import { IsEmail, IsNotEmpty, IsString, MinLength } from 'class-validator';
import {ApiProperty} from "@nestjs/swagger";
export class CreateUserDto {
@ApiProperty({ example: 'John Doe' })
@IsNotEmpty()
@IsString()
fullName: string;
@ApiProperty({ example:'[email protected]' })
@IsNotEmpty()
@IsEmail()
email: string;
@ApiProperty({ example:'qwerty123' })
@IsNotEmpty()
@IsString()
@MinLength(8)
password: string;
}
Код файлу update-user.dto.ts:
import { PartialType } from '@nestjs/mapped-types';
import { IsEmail, IsOptional, IsString, MinLength } from 'class-validator';
import { CreateUserDto } from './create-user.dto';
import {ApiProperty} from "@nestjs/swagger";
export class UpdateUserDto extends PartialType(CreateUserDto) {
@ApiProperty({ example: 'John Doe' })
@IsOptional()
@IsString()
fullName?: string;
@ApiProperty({ example:'[email protected]' })
@IsOptional()
@IsEmail()
email?: string;
@ApiProperty({ example:'qwerty123' })
89
ЧДТУ 232210.012 ПЗ
@IsOptional()
@IsString()
@MinLength(8)
password?: string;
// Add any additional optional fields that can be updated here
}
Код файлу user.entity.ts:
import { Entity, PrimaryGeneratedColumn, Column, OneToMany } from 'typeorm';
import {Message} from "../../chat/entities/message.entity";
import {Review} from "../../reviews/entities/review.entity";
@Entity()
export class User {
@PrimaryGeneratedColumn()
id: number;
@Column({ unique: true })
email: string;
@Column()
password: string;
@Column()
fullName: string;
@OneToMany(() => Message, message => message.sender)
sentMessages: Message[];
@OneToMany(() => Message, message => message.receiver)
receivedMessages: Message[];
@OneToMany(() => Review, review => review.author)
reviews: Review[];
}
Код файлу user.controller.ts:
import { Body, Controller, Delete, Get, Param, Post, Put } from '@nestjs/common';
import { UsersService } from './users.service';
import { CreateUserDto } from './dto/create-user.dto';
import { UpdateUserDto } from './dto/update-user.dto';
import { User } from './entities/user.entity';
@Controller('users')
export class UsersController {
constructor(private readonly usersService: UsersService) {}
@Post()
async create(@Body() createUserDto: CreateUserDto): Promise<User> {
return this.usersService.create(createUserDto);
}
@Get()
90
ЧДТУ 232210.012 ПЗ
async findAll(): Promise<User[]> {
return this.usersService.findAll();
}
@Get(':id')
async findOne(@Param('id') id: number): Promise<User> {
return this.usersService.findOne(id);
}
@Put(':id')
async update(@Param('id') id: number, @Body() updateUserDto: UpdateUserDto):
Promise<User> {
return this.usersService.update(id, updateUserDto);
}
@Delete(':id')
async remove(@Param('id') id: number): Promise<void> {
return this.usersService.remove(id);
}
}
Код файлу users.module.ts:
import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';
import { UsersController } from './users.controller';
import { UsersService } from './users.service';
import { User } from './entities/user.entity';
@Module({
imports: [
TypeOrmModule.forFeature([User]),
],
controllers: [UsersController],
providers: [UsersService],
exports: [UsersService]
})
export class UsersModule {}
Код файлу users.servise.ts:
import { Injectable, NotFoundException } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { CreateUserDto } from './dto/create-user.dto';
import { UpdateUserDto } from './dto/update-user.dto';
import { User } from './entities/user.entity';
@Injectable()
export class UsersService {
constructor(
@InjectRepository(User)
private userRepository: Repository<User>,
) {}
91
ЧДТУ 232210.012 ПЗ
async create(createUserDto: CreateUserDto): Promise<User> {
const user = this.userRepository.create(createUserDto);
console.log(user);
await this.userRepository.save(user);
return user;
}
async findAll(): Promise<User[]> {
return this.userRepository.find();
}
async findOne(id: number): Promise<User> {
const user = await this.userRepository.findOne({
where: {
id,
},
});
if (!user) {
throw new NotFoundException(`User with ID "${id}" not found`);
}
return user;
}
async findByEmail(email: string): Promise <User> {
const user = await this.userRepository.findOne({
where: {
email,
},
});
if (!user) {
throw new NotFoundException(`User with email "${email}" not found`);
}
return user;
}
async update(id: number, updateUserDto: UpdateUserDto): Promise<User> {
const user = await this.findOne(id);
Object.assign(user, updateUserDto);
await this.userRepository.save(user);
return user;
}
async remove(id: number): Promise<void> {
const result = await this.userRepository.delete(id);
if (result.affected === 0) {
throw new NotFoundException(`User with ID "${id}" not found`);
}
}
}
Код файлу app.module.ts:
import { Module } from '@nestjs/common';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { TypeOrmModule } from '@nestjs/typeorm';
import { AuthModule } from './auth/auth.module';
import { UsersModule } from './users/users.module';
92
ЧДТУ 232210.012 ПЗ
import { ChatModule } from './chat/chat.module';
import { ReviewsModule } from './reviews/reviews.module';
import { validationSchema } from './config/validation.schema';
import configuration from './config/configuration';
@Module({
imports: [
ConfigModule.forRoot({
isGlobal: true,
validationSchema,
}),
TypeOrmModule.forRootAsync({
imports: [ConfigModule],
useFactory: async (configService: ConfigService) => ({
type: 'postgres', // as an example, could be other database type
host: configService.get<string>('DATABASE_HOST'),
port: configService.get<number>('DATABASE_PORT'),
username: configService.get<string>('DATABASE_USERNAME'),
password: configService.get<string>('DATABASE_PASSWORD'),
database: configService.get<string>('DATABASE_NAME'),
entities: [__dirname + '/**/*.entity{.ts,.js}'],
synchronize: true,
// synchronize: configService.get<boolean>('database.synchronize'), //
Should be false in production
}),
inject: [ConfigService],
}),
AuthModule,
UsersModule,
AuthModule,
UsersModule,
ChatModule,
ReviewsModule,
],
})
export class AppModule {}
93
ЧДТУ 232210.012 ПЗ
ДОДАТОК В
Програмне забезпечення інформаційної системи безоплатної первинної
правової допомоги: серверна частина
Інструкція користувача
482.ЧДТУ.232210.01 34 01
Листів 4
Розробник ________________ Кретов О.В.
2023
94
ЧДТУ 232210.012 ПЗ
ЗАГАЛЬНІ ПОЛОЖЕННЯ
Для того, щоб запустити програму, необхідно завантажити її з GitHub за
посиланням: https://github.com/Lexander1108/e-generator-Backend
Для цього слід скористатись командою git clone <посилання на
репозиторій> в директорії, в яку вирішено зберегти програму.
Для того, щоб програма запустилася, необхідно переконатись, що на
комп’ютері встановлені Node.js та npm. Якщо вони відсутні, завантажуємо їх з
офіційного сайту Node.js. Переконавшись, що все встановлено, виконуємо команду
npm init для ініціалізації проекту та встановлення усіх необхідних залежностей.
Після цього виконуємо в терміналі команду npm start і переконуємося в
успішному запуску програми, якщо в терміналі з’являться логи наступного
вигляду:
Рис.1 Успішний запуск програми
95
ЧДТУ 232210.012 ПЗ
Після того, як програма запустилась, переходимо за посиланням
http://localhost:3000/api/docs, де можемо почати взаємодіяти з програмою. Тут ми
бачимо усі ендпоінти та типи запитів (рис.2).
Рис. 2 – Ендпоінти та можливі види запитів
Для того, щоб виконати запит, слід обрати потрібний ендпоінт та бажаний
тип запиту, наводимо курсор на любий запит, обираємо його, та натискаємо на
кнопку Try it out (рис.3).
Рис.4 – Вибір запиту
Тепер слід заповнити поле Request body (якщо це POST-запит). В цьому полі
вже написаний зразок тіла запиту (рис.5). Такі зразки будуть написані також і в
96
ЧДТУ 232210.012 ПЗ
інших полях, за допомогою шаблонів DTO (Data Transfer Object). Після того як поле
заповнене, натискаємо кнопку Execute і запит виконується (рис.7).
Рис. 5 – Початок виконання HTTP запиту
Рис. 6 – Шаблони створення та оновлення користувача
97
ЧДТУ 232210.012 ПЗ
Рис. 7 – Успішне виконання запиту
На рисунку вище представлене успішне виконання HTTP запиту. У відповідь
на запит отримуємо Response body, в якому інформується що користувач
зареєстрований, та демонструються його дані. Завдяки використанню bycript,
пароль користувача закодований у набір символів, і в такому вигляді буде
зберігатись у базі даних.
Таким чином можна обирати та виконувати усі типи запитів, представлені в
даній роботі.
98
ЧДТУ 232210.012 ПЗ
ДОДАТОК Б
Програмне забезпечення інформаційної системи безоплатної первинної
правової допомоги: серверна частина
Графічний матеріал
482.ЧДТУ. 221539.01 90 01
Листів 12
Розробник ________________ Кретов О.В
2023
99
ЧДТУ 232210.012 ПЗ
Рис. Г.1 – Актуальність теми
Рис. Г.2 – Мета роботи
100
ЧДТУ 232210.012 ПЗ
Рис. Г.3 – Завдання
Рис. Г.4 – Об’єкт досліджень
101
ЧДТУ 232210.012 ПЗ
Рис. Г.5 – Предмет досліджень
Рис. Г.6 – Методи досліджень
102
ЧДТУ 232210.012 ПЗ
Рис. Г.7 – Апробація результатів
Рис. Г.8 – Існуючі методи та засоби розв’язання поставлених
завдань
103
ЧДТУ 232210.012 ПЗ
Рис. Г.9 – Теоретичні дослідження
Рис. Г.10 – Експериментальні дослідження
104
ЧДТУ 232210.012 ПЗ
Рис. Г.11 – Впровадження результатів досліджень у практику
проектування програмного забезпечення інформаційних систем
Рис. Г.12 – Впровадження результатів досліджень у практику
проектування програмного забезпечення інформаційних систем
105
ЧДТУ 232210.012 ПЗ
Рис. Г.13 – Впровадження результатів досліджень у практику
проектування програмного забезпечення інформаційних систем
106
ЧДТУ 232210.012 ПЗ
Рис. Г.14 – Впровадження результатів досліджень у практику
проектування програмного забезпечення інформаційних систем
Рис. Г.15 – Розробка та тестування програмного забезпечення
107
ЧДТУ 232210.012 ПЗ
Рис. Г.16 – Розробка та тестування програмного забезпечення
Рис. Г.17 – Розробка бази даних
108
ЧДТУ 232210.012 ПЗ
Рис. Г.18 – Розробка бази даних
Рис. Г.19 – Розробка інтерфейсу користувача
109
ЧДТУ 232210.012 ПЗ
Рис. Г.20 – Тестування
Рис. Г.21 – Тестування
110