Програмне забезпечення інформаційної системи безоплатної первинної правової допомоги: клієнтська частина

Шамов, Олексій Анатолійович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9105
Full metadata record
DC Field	Value	Language
dc.contributor.advisor	Заспа, Григорій Олександрович	-
dc.contributor.author	Шамов, Олексій Анатолійович	-
dc.date.accessioned	2026-03-25T18:47:08Z	-
dc.date.available	2026-03-25T18:47:08Z	-
dc.date.issued	2023-12-20	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/9105	-
dc.description.abstract	АНОТАЦІЯ Шамов О.А. Програмне забезпечення інформаційної системи безоплатної первинної правової допомоги: клієнтська частина 121 «Інженерія програмного забезпечення» Черкаський державний технологічний університет, Черкаси, 2023 Шляхом розробки інформаційної технології та відповідного їй програмного забезпечення в цій роботі запропоновано зменшити протиріччя між високим рівнем попиту населення на юридичні консультації та низьким рівнем пропозицій щодо працевлаштування від роботодавців для підготовлених фахівців без практичного досвіду, яке було виявлене в процесі дослідження предметної області у вирішенні проблеми задоволення потреб населення у правовій допомозі та генерації досвіду молодих спеціалістів.	uk_UA
dc.description.abstract	ANNOTATION Shamov O.A. Free primary legal aid information system software: client part 121 "Software engineering" Cherkasy State Technological University, Cherkasy, 2023 Through the development of information technology and its corresponding software, this work proposes to reduce the contradiction between the high level of public demand for legal advice and the low level of job offers from employers for trained specialists without practical experience, which was revealed in the process of researching the subject area in solving the problem of satisfaction needs of the population in legal assistance and generation of experience of young specialists.	uk_UA
dc.language.iso	uk	uk_UA
dc.subject	ОНЛАЙН ПЛАТФОРМА	uk_UA
dc.subject	ТЕКСТОВІ ЧАТИ	uk_UA
dc.subject	ЮРИДИЧНІ КОНСУЛЬТАЦІЇ	uk_UA
dc.subject	ПРАЦЕВЛАШТУВАННЯ	uk_UA
dc.subject	ГЕНЕРАТОР ДОСВІДУ	uk_UA
dc.subject	ONLINE PLATFORM	uk_UA
dc.subject	TEXT CHATS	uk_UA
dc.subject	LEGAL ADVICE	uk_UA
dc.subject	EMPLOYMENT	uk_UA
dc.subject	EXPERIENCE GENERATOR	uk_UA
dc.title	Програмне забезпечення інформаційної системи безоплатної первинної правової допомоги: клієнтська частина	uk_UA
dc.type	Master Thesis	uk_UA
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Files in This Item:
File	Description	Size	Format
Кваліфікаційнв робота магістра Шамов Олексій Анатолійович.pdf Restricted Access		9.66 MB	Adobe PDF	View/Open Request a copy
Show simple item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
магістра 
 
на тему:  Програмне забезпечення інформаційної системи безоплатної первинної 
правової допомоги: клієнтська частина 
 
Виконав: студент 2 курсу, групи МПЗ-2204 
Спеціальність 121 «Інженерія програмного забезпечення» 
 
Студент Шамов О.А. ___________________ 
 
Керівник Заспа Г.О. ___________________ 
 
Рецензент Корпань Є.О. ___________________ 
 
 
Черкаси 2023 
 
 
 
 1 
 
Черкаський державний технологічний університет 
 
Факультет    інформаційних технологій і систем 
Кафедра    програмного забезпечення автоматизованих систем 
Освітній рівень   магістр 
Спеціальність   121 «Інженерія програмного забезпечення» 
Освітня програма  Інженерія програмного забезпечення 
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
___________________Голуб С.В. 
«___» _______________ 2023 року 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
Шамову Олексію Анатолійовичу 
 
1.Тему проекту (роботи):  Програмне забезпечення інформаційної системи 
безоплатної первинної правової допомоги: клієнтська частина 
Керівник проекту (роботи):  
Заспа Григорій Олександрович к.т.н., доцент 
Затверджені наказом Черкаського державного технологічного університету від 
06.10.2023 №267/04. 
2. Строк подання студентом проекту (роботи) 6 грудня 2023 р. 
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; 
процеси управління; вимоги до проекту; календарне планування проекту; 
управління ризиками проекту; управління ресурсами 
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно 
розробити) 
Вступ 
1. Існуючі методи та засоби розв’язання завдань 
2. Теоретичні та експериментальні дослідження 
3. Впровадження результатів досліджень у практику проектування 
програмного забезпечення інформаційних систем 
4. Розробка та тестування програмного забезпечення 
Висновки 
Список використаних джерел 
Додатки  
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт 
проекту):  Слайд №1 “Мета досліджень”, Слайд №2 “Завдання досліджень”, Слайд 
№3 “Задача структурної ідентифікації  1/3”, Слайд №4 “Задача структурної 
ідентифікації  2/3”, Слайд №5 “Задача структурної ідентифікації  3/3”, Слайд №6 
“Аналіз потреб цільової аудиторії  1/3”, Слайд №7 “Аналіз потреб цільової аудиторії  
2/3”, Слайд №8 “Аналіз потреб цільової аудиторії  3/3”, Слайд №9 “Схема 
інформаційної системи”, Слайд №10 “Моделювання предметної області (UML) 
1/10”, Слайд №11 “Моделювання предметної області (UML) 2/10”, Слайд №12 
“Моделювання предметної області (UML) 3/10”, Слайд №13 “Моделювання 
 2 
предметної області (UML) 4/10”, Слайд №14 “Моделювання предметної області 
(UML) 5/10”, Слайд №15 “Моделювання предметної області (UML) 6/10”, Слайд 
№16 “Моделювання предметної області (UML) 7/10”, Слайд №17 “Моделювання 
предметної області (UML) 8/10”, Слайд №18 “Моделювання предметної області 
(UML) 9/10”, Слайд №19 “Моделювання предметної області (UML) 10/10”, Слайд 
№20 “Розробка програмного забезпечення”, Слайд №21 “Розробка інтерфейсу 
користувача 1/3”, Слайд №22 “Розробка інтерфейсу користувача 2/3”, Слайд №23 
“Розробка інтерфейсу користувача 3/3”. 
6. Консультанти розділів проекту (роботи) 
 Прізвище, ініціали Підпис, дата 
Розділ та посади  
консультанта Завдання видав         Завдання прийняв 
1    
2    
 
7. Дата видачі завдання 02 вересня 2023 р. 
 
КАЛЕНДАРНИЙ ПЛАН 
№  Строк Примітка 
п/п  виконання 
Назва етапів випускної роботи етапів 
випускної 
роботи 
1 Постановка задачі 02.09.2023 Виконано 
2 Підготовка завдання 13.09.2023 Виконано 
3 Погодження завдання 16.09.2023 Виконано 
4 Затвердження завдання 19.09.2023 Виконано 
 Основна стадія   
1 Підбір матеріалів  27.09.2023 Виконано 
2 Аналіз шляхів вирішення поставленої задачі  04.10.2023 Виконано 
3 Розрахунок основних параметрів роботи  10.10.2023 Виконано 
4 Вибір кінцевого варіанту проектного рішення  17.10.2023 Виконано 
5 Оформлення первісної редакції роботи  25.10.2023 Виконано 
 Заключна стадія   
1 Узгодження прийнятих проектних рішень з 31.10.2023 Виконано 
керівником 
2 Оформлення пояснювальної записки роботи в 13.11.2023 Виконано 
кінцевій редакції 
3 Попередній захист роботи  16.11.2023 Виконано 
4 Затвердження роботи  02.12.2023 Виконано 
5 Рецензування роботи  03.12.2023 Виконано 
6 Захист роботи  06.12.2023 Виконано 
 
 
 3 
Магістрант     _____________________  О.А.Шамов 
 
 
Керівник проекту (роботи)   _____________________  Г.О.Заспа  
 
АНОТАЦІЯ 
Шамов О.А. 
Програмне забезпечення інформаційної системи безоплатної первинної 
правової допомоги: клієнтська частина 
121 «Інженерія програмного забезпечення» 
Черкаський державний технологічний університет, Черкаси, 2023 
Шляхом розробки інформаційної технології та відповідного їй програмного 
забезпечення в цій роботі запропоновано зменшити протиріччя між високим рівнем 
попиту населення на юридичні консультації та низьким рівнем пропозицій щодо 
працевлаштування від роботодавців для підготовлених фахівців без практичного 
досвіду, яке було виявлене в процесі дослідження предметної області у вирішенні 
проблеми задоволення потреб населення у правовій допомозі та генерації досвіду 
молодих спеціалістів.  
 Ключові слова: ОНЛАЙН ПЛАТФОРМА, ТЕКСТОВІ ЧАТИ, ЮРИДИЧНІ 
КОНСУЛЬТАЦІЇ, ПРАЦЕВЛАШТУВАННЯ, ГЕНЕРАТОР ДОСВІДУ.  
 
ANNOTATION 
Shamov O.A. 
Free primary legal aid information system software: client part 
121 "Software engineering" 
Cherkasy State Technological University, Cherkasy, 2023 
Through the development of information technology and its corresponding software, 
this work proposes to reduce the contradiction between the high level of public demand for 
legal advice and the low level of job offers from employers for trained specialists without 
practical experience, which was revealed in the process of researching the subject area in 
solving the problem of satisfaction needs of the population in legal assistance and 
generation of experience of young specialists. 
 4 
Keywords: ONLINE PLATFORM, TEXT CHATS, LEGAL ADVICE, 
EMPLOYMENT, EXPERIENCE GENERATOR 
 
ЗМІСТ 
 
ВСТУП ................................................................................................................................. 9 
1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ ЗАДАЧ .... 12 
1.1. Аналіз наукової та технічної інформації щодо теми дослідження та 
існуючих в світі аналогів, систематизація отриманих даних ................................. 12 
1.2. Пошук методів та засобів, які вже використовуються; виявлення та усунення 
актуальних проблем, що виникають в процесі виконання завдань ....................... 16 
1.3. Конкретизація завдання ....................................................................................... 18 
Висновок стосовно необхідності проведення досліджень у даній галузі ............. 19 
2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ ................................ 20 
2.1. Теоретичні дослідження ...................................................................................... 20 
2.1.1. Інформаційний аналіз .................................................................................. 23 
2.1.2. Аналіз схожих платформ ............................................................................. 25 
2.1.3. Аналіз потреб цільової аудиторії ............................................................... 26 
2.1.4. Технічний аналіз .......................................................................................... 30 
2.1.5. Аналіз правових аспектів ............................................................................ 37 
2.1.6. Соціальний вплив ......................................................................................... 38 
2.1.7. Структурно-інформаційний аналіз............................................................. 39 
2.1.8. Потоки даних ................................................................................................ 41 
2.1.9. Функціональність ......................................................................................... 42 
2.1.10. Архітектура клієнтської частини системи .............................................. 43 
2.1.11. Взаємодія між користувачами .................................................................. 44 
2.1.12. Підтримка (support) .................................................................................... 46 
2.1.13. Моніторинг продуктивності ..................................................................... 46 
2.1.14. Потенційні ризики та загрози ................................................................... 47 
2.1.15. Пошук раціонального компромісу ........................................................... 49 
2.1.16. Розкриття невизначеностей ...................................................................... 50 
2.1.17. Дослідження багатофакторності ризиків, як елемент системного 
підходу до дослідження ......................................................................................... 52 
2.1.18 Теорія та гіпотеза дослідження ................................................................. 54 
2.1.18.1 Теорія дослідження: ........................................................................... 54 
2.1.18.2 Гіпотеза дослідження: ........................................................................ 54 
 5 
- Експериментальна гіпотеза ...................................................................... 54 
- Предметне визначення понять ................................................................. 55 
2.2. Експериментальні дослідження .......................................................................... 55 
2.2.1. Опис елементів ............................................................................................. 63 
2.2.2. Імітаційний метод ........................................................................................ 65 
2.2.3. Оцінка ефективності системи ..................................................................... 67 
2.2.4. Результати власних досліджень автора ..................................................... 70 
3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ ........................................................................................................................... 71 
3.1. Моделювання предметної області ...................................................................... 71 
3.1.1. Предметна область моделювання: ............................................................. 72 
3.1.2. Модель предметної області:........................................................................ 73 
3.1.3. Словник предметної області ....................................................................... 74 
3.1.4. Елементи моделювання предметної області ............................................. 75 
3.1.5. Робоча область моделювання ..................................................................... 76 
3.2. Формування вимог до програмного забезпечення ........................................... 76 
3.2.1. Вимоги замовника: ....................................................................................... 77 
3.2.2 Вимоги розробника: ...................................................................................... 77 
3.2.3. Детальні вимоги: .......................................................................................... 77 
3.2.3.1. Функціональні вимоги: ....................................................................... 77 
3.2.3.2. Нефункціональні вимоги: ................................................................... 78 
3.3. Формування вимог за допомогою діаграми прецедентів................................. 78 
3.4. Проектування логічної структури програмного комплексу ............................ 80 
3.4.1. Діаграми класів ............................................................................................ 80 
3.4.2. Діаграми пакетів........................................................................................... 86 
3.5. Архітектурне проектування ................................................................................ 91 
3.5.1. Діаграми компонентів ................................................................................. 91 
3.5.2. Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання. ............................................................................................................ 93 
3.6. Моделювання поведінки системи ...................................................................... 95 
3.6.1. Діаграми діяльності ..................................................................................... 95 
3.6.2. Діаграми послідовності ............................................................................. 101 
3.6.3. Діаграми комунікації ................................................................................. 105 
3.6.4. Діаграми скінченного автомату ................................................................ 107 
4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ .................. 120 
4.1. Розробка програмного комплексу .................................................................... 120 
 6 
4.1.1. Обґрунтування вибору засобів реалізації ................................................ 120 
4.1.2. Опис структурної (функціональної) схеми ............................................. 121 
4.1.3 Опис логічної схеми системи .................................................................... 122 
4.1.4. Розробка бази даних .................................................................................. 124 
4.1.5. Розробка інтерфейсу користувача ............................................................ 124 
4.1.6. Опис розробки програмних компонентів ................................................ 125 
4.2. Тестування системи ........................................................................................... 126 
4.2.1. Модульне тестування ................................................................................ 126 
4.2.2. Інтеграційне тестування ............................................................................ 128 
4.2.3. Системне тестування ................................................................................. 129 
4.2.4. Приймальне тестування ............................................................................ 130 
ВИСНОВКИ .................................................................................................................... 132 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ...................................................................... 134 
ДОДАТКИ………………………………………………………………………….....136 
 
  
 7 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ 
 
Скорочення Розшифрування 
HTML абревіатура від HyperText Markup Language — мова розмітки 
гіпертексту — стандартизована мова розмітки документів для 
перегляду вебсторінок у браузері. 
CSS абревіатура від Cascading Style Sheets - каскадні таблиці 
стилів 
FLEX від англ. гнучкий - модель одномірно-спрямованого макету; 
один із методів розподілу простору між елементами в 
інтерфейсі 
GRID від англ. сітка - техніка в каскадних таблицях стилів, що 
дозволяє створювати складні адаптивні макети вебдизайну 
UML Unified Modelling Language - універсальна мова моделювання; 
мова позначень або побудови діаграм, призначена для 
визначення, візуалізації і документування моделей 
зорієнтованих на об’єкти систем програмного забезпечення 
 
 
 
 
 
 
 
 
 8 
ВСТУП 
Актуальність теми. В умовах сучасного ринку праці є низькою вірогідність 
працевлаштування студентів-юристів вищих навчальних закладів та дипломованих 
юристів через відсутність практичного досвіду правової допомоги в реальних 
життєвих ситуаціях [1]. 
Доступ до первинної правничої допомоги  для значної кількості населення 
країни є утрудненим чи неможливим через відносно високу вартість послуг 
досвідчених правників. Крім того, має місце нерівномірне представлення в різних 
регіонах та населених пунктах країни досвідчених юристів у конкретних галузях 
права. Існує потреба набуття молодими юристами досвіду з метою подальшого 
працевлаштування а також потреба у безкоштовній базовій правовій допомозі для 
малозабезпечених верств населення незалежно від територіального розміщення. 
В процесі дослідження предметної області у вирішенні проблеми задоволення 
потреб населення у правовій допомозі та генерації досвіду молодих спеціалістів 
отримано висновок про існування протиріччя між високим рівнем попиту населення 
на юридичні консультації та низьким рівнем пропозицій щодо працевлаштування від 
роботодавців для підготовлених фахівців без практичного досвіду. В цій роботі 
запропоновано зменшити таке протиріччя шляхом розробки інформаційної 
технології та відповідного їй програмного забезпечення. 
Розробка програмного забезпечення інформаційних систем правового 
обслуговування вимагає особливої технології розробки програмного забезпечення, 
яка грунтується на методі об’єктно-орієнтованого програмування. 
Результати наступних досліджень показали необхідність удосконалення 
типового об’єктно орієнтованого програмування з розробки програмних систем для 
задоволення потреб населення у правовій допомозі та генерації досвіду молодих 
спеціалістів. 
Мета і завдання досліджень. Метою є удосконалення способів розробки 
програмних систем із забезпечення юридичних послуг шляхом удосконалення 
 9 
методу об'єктно-орієнтованого програмування із застосуванням структурно- 
функціонального підходу. 
Завданнями досліджень є: 1) дослідження способів створення програмного 
забезпечення інформаційної системи безоплатної первинної правової допомоги; 2) 
удосконалення методу об'єктно-орієнтованого програмування шляхом застосування 
структурно-функціонального підходу до розробки програмних систем із 
забезпечення юридичних послуг; 3) побудова формальної моделі та побудова 
прототипу програмного забезпечення інформаційної системи безоплатної первинної 
правової допомоги на основі створеної моделі. 
Об’єкт досліджень. Програмні системи комп’ютерно опосередкованої 
комунікації, призначені для надання інформаційної допомоги населенню та які 
можуть використовуватись для супутнього генерування досвіду молодих фахівців.    
Предмет досліджень. Моделі роботи програмної системи комп’ютерно 
опосередкованої комунікації з надання безоплатної первинної правової допомоги та 
генерування досвіду молодих фахівців (клієнтська частина). 
Методи досліджень. В даній роботі використані такі методи: 
Емпіричний аналіз: Вивчення роботи існуючих аналогічних платформ, щоб 
визначити їхні сильні та слабкі сторони. Аналіз практичного використання подібних 
систем юридичними фахівцями та користувачами. 
Спостереження: Спостереження за поведінкою користувачів на різних етапах 
взаємодії з платформою, щоб виявити можливі труднощі та покращення. 
Моделювання: Створення прототипів або макетів користувальницького 
інтерфейсу для попереднього тестування та збору фідбеку. 
Системний підхід: Дослідження системного впливу платформи на роботу 
юристів та користувачів через аналіз їхніх потреб і вимог. 
Експеримент: Проведення експерименту для оцінки ефективності та зручності 
використання різних елементів інтерфейсу. 
Формалізація: Визначення формальних вимог до функціоналу та інтерфейсу 
платформи для забезпечення стабільної роботи. 
 10 
Порівняння: Порівняння різних технічних рішень та підходів для вибору 
найоптимальніших. 
Синтез: Синтез інформації з різних джерел для створення повноцінного та 
оптимізованого клієнтського інтерфейсу. 
Комбінування цих методів дослідження дозволило створити вдалий та 
ефективний інтерфейс для онлайн-платформи з урахуванням потреб користувачів та 
функціональних вимог. 
Наукова новизна отриманих результатів. Удосконалено метод об'єктно-
орієнтованого програмування шляхом застосування структурно-функціонального 
підходу до розробки програмних систем із забезпечення юридичних послуг. 
Практичне значення одержаних результатів.  Одержані результати 
досліджень можуть бути використані для вдосконалення процесу розробки 
програмного забезпечення систем юридичних послуг. Розроблене програмне 
забезпечення є основою для впровадження інформаційної системи безоплатної 
первинної правової допомоги. 
Особистий внесок автора. Усі наукові результати, подані у кваліфікаційній 
роботі магістра, одержані здобувачем особисто. 
Публікації. Опубліковано тези доповіді: “Реалізація практичного варіанту 
застосування теоретико-методологічних засад використання інформаційних 
технологій для вирішення актуальної практичної задачі генерації досвіду молодих 
спеціалістів” на ІІ Міжнародній науково-практичній Інтернет-конференції 
"Інновації та перспективні шляхи  розвитку інформаційних технологій” (ІПШРІТ-
2023), 06 грудня 2023 року.  
  
 11 
1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ ЗАДАЧ 
Програмне створення онлайн-платформи для надання безоплатних юридичних 
консультацій переважно малозабезпеченим групам населення вимагає ретельного 
планування і використання різних методів та засобів. Ось деякі існуючі методи та 
засоби, які можна використовувати для розв'язання цього завдання: 
1 Розробка веб-сайту за допомогою HTML, CSS і JavaScript для створення 
інтерфейсу платформи, де користувачі матимуть доступ до юридичних 
консультацій. 
2 Форми зворотного зв'язку, щоб користувачі могли подавати свої запити і 
питання щодо юридичних консультацій. 
3 Автентифікація та реєстрація користувачів через впровадження системи 
реєстрації та аутентифікації користувачів, щоб забезпечити безпеку та 
відстежуваність запитів. 
4 База даних для зберігання інформації про користувачів та юридичні 
консультації. 
5 Чат-система або платформа для обміну повідомленнями у процесі 
спілкування користувачів і юристів. 
6 Ресурси для юристів: інструменти і матеріали, необхідні для відповідей на 
запити користувачів. 
7 Заходи забезпечення безпеки та конфіденційності інформації користувачів. 
8 Публікація та просування платформи серед малозабезпечених груп та 
юристів. 
9 Забезпечення доступності та використання UX/UI дизайну, щоб платформа 
була доступною для різних категорій користувачів і мала зручний інтерфейс. 
1.1. Аналіз наукової та технічної інформації щодо теми дослідження та 
існуючих в світі аналогів, систематизація отриманих даних 
У монографії 2021 року науковців Кафедри інформаційних систем 
 12 
управління Донецького національного університету імені Василя Стуса 
“Трансформаційні процеси у суспільній та соціокультурній сферах України” [2] 
особливу увагу дослідників зосереджено на явищі цифровізації як головного 
технічного чиннику формування суспільства, орієнтованого на життя в 
інформаційному просторі.  
Зокрема, дослідники звернули увагу на особливості становлення і розвитку 
інформаційних телемедичних сервісів у світі та Україні.  
Інформаційні телемедичні системи надають широкі можливості віддаленої 
комунікації між пацієнтом та лікарем. З ними людина стає ближчою до сервісів, 
доступ до яких раніше вимагав значно більших витрат часу, коштів й енергії.  
Влучним є вислів авторів вищевказаної монографії, який коротко описує 
головні орієнтири для створення подібної інформаційної системи (цитата): 
“Найкращі телемедичні рішення 2020 року – це ті, що ефективні у наданні якісних 
результатів та прості у використанні.”   
Систематизуючи зібрану інформацію, дослідники вказують на основні 
чинники успішного створення телемедичної системи: 
Канали комунікації: клієнт та спеціаліст комунікують посередництвом 
комп’ютера, телефона чи в мобільному додатку. Відповідно, реалізується 
можливість користуватись голосовим зв’язком, відеозв’язком чи текстовими чатами.      
 Географічне охоплення: інформаційна система дозволяє зв’язати клієнта і 
спеціаліста незалежно від місця знаходження кожного з них. Разом з тим, 
використання геолокаційної прив’язки дозволяє обрати для спілкування спеціаліста, 
який дистанційно знаходиться до клієнта найближче від усіх, що може бути 
особливо актуально для екстрених чи особливих випадків отримання медичної 
допомоги. 
Спеціалізація: інформаційна система може надавати клієнтам доступ як до 
широкого кола спеціалістів різної спеціалізації, так і пропонувати зв’язок з 
фахівцями вузької направленості, поділяючи види допомоги на класи та категорії. 
 13 
Близькість спілкування: інформаційна система може пропонувати свого роду 
аналог сімейного лікаря, коли одного разу залучений спеціаліст, сервіс якого 
повністю задовольняє клієнта, залишається постійним фахівцем для цієї людини, що 
значно підвищує рівень довіри та дозволяє спеціалісту краще вивчити потреби і 
особливості конкретного клієнта. 
 Окрему увагу дослідників привернув стан телемедичних сервісів в Україні. 
Зазначається, що до 2017 року використання інформаційних телемедичних систем в 
Україні мало випадковий нерегулярний характер та було ініціативою окремих 
лікувальних закладів чи спеціалістів. Проте, з 2017 року питання телемедії вийшло 
на державний рівень, з’явилась відповідна законодавча ініціатива. 
Потужним поштовхом для розвитку телемедії став спалах ковід-інфекції у 
2020 році, коли мільйони людей усього світу були змушені ізолюватись вдома, 
звести до мінімуму особисті контакти, використовуючи можливості мережі інтернет 
у максимально можливий для себе спосіб.  
Дослідники зазначають, що в Україні діють такі інформаційні телемедичні 
системи, як Medinet, Telemed24, “Поліклініка без черг”, Doctor Online, Medikit. На 
прикладі мережі Medinet повідомляється про більше 10 тис. проведених 
консультацій лише за перший рік діяльності інформаційної системи. 
На відміну від України, у всьому світі подібні інформаційні системи діють вже 
багато років. Серед поширених: Telados, iCliniq, MeMD, Doctor on Demand, 
Virtuweel, PlushCare, Maven Clinic, SteadyMD. 
У роботі  доцента кафедри загальної психології НУЦЗУ Афанасьєвої Н.Є. 
“Моделі і способи інтернет-консультування фахівців екстремальних видів 
діяльності”, 2013р. [3],  увагу сфокусовано на організації онлайн-служби 
психологічної допомоги.  
Автор вказує, що основною складністю організації такого інформаційного 
сервісу є вдале обрання інженерних рішень та їх практичне впровадження. 
Специфікою взаємодії в мережі Інтернет дослідник називає анонімність учасників 
комунікації, неконтактність взаємодії на фізичному рівні, можливість користуватись 
 14 
вигаданим ім'ям. Дослідник вказує на можливість індивідуальних або групових 
сеансів зв’язку. Недоліком онлайн-формату дослідник називає звужену можливість 
для психолога зчитувати невербальні знаки в ході спілкування з клієнтом. Це може 
бути наслідком обмеженого куту огляду веб-камери, недостатньою якістю 
зображення і звуку, тощо. Разом з тим, певний формат взаємодії, наприклад 
текстовий, дозволяє спеціалісту спілкуватись одночасно з декількома клієнтами. 
У статті Ясточкіної І.А. “Інтернет-консультування як нова технологія в 
психолого-педагогічній практиці” [4] читачу пропонується поглянути на історію 
розвитку комп’ютерних технологій в контексті інтернет-консультування. Автор 
вказує, що сама ідея онлайн-консультування з’явилась одночасно з появою перших 
умовно доступних персональних комп’ютерів в США, починаючи з 1976 року. Вже 
через три роки цей процес набув у США загальнодержавних рис. З середини 90-х 
років минулого століття онлайн-консультування стало поширеним в інших країнах 
Заходу.  Автор окремо підкреслює прагнення сучасної молоді до віртуального 
спілкування, що може означати лиш збільшення і поглиблення процесів онлайн-
консультування у майбутньому.  
Тут дослідниця виокремлює головну цінність для кожної із сторін інтернет-
комунікації, не пов’язану з матеріальною стороною. Зокрема, фахівець у заочному 
режимі спілкування набуває досвіду оцінювати ситуацію виключно на основі 
інформаційних даних, без невербального контакту, що є для нього цінною 
професійною навичкою; в свою чергу, клієнт цінує швидкість, легкість доступу до 
сервісу та приватність. 
У статті Скрипнікова А.М., Бойко Д.І., Боднара Л.А. з Полтавського 
державного медичного університету [5] під назвою "Досвід набутий в умовах 
пандемії Covid-19 в період воєнного часу: телепсихіатрія", автори наводять 
відомості про появу перших сеансів телепсихіатрії за допомогою прямих 
телевізійних трансляцій ще у 1959 році (Інститут психіатрії, штат Небраска, США).  
Нині терміном “телепсихіатрія” називають комплекс мір, заснований на комунікації 
лікаря та пацієнта посередництвом інформаційних систем різного технічного 
 15 
виконання. Цікаво, що останній системний огляд ефективності роботи таких 
інформаційних систем показав високий рівень задоволення пацієнтів від 
використання саме дистанційних методів комунікації з використанням сучасних 
програмно-інженерних рішень.  
Автори звертають увагу на важливість розробки та впровадження більш 
досконалих алгоритмів взаємодії між учасниками комунікації. Такі алгоритми, серед 
іншого, інтегруються в інформаційну систему. Простим прикладом є  обов’язкове 
заповнення певних полів реєстраційної форми, послідовність тих чи інших процесів 
в інформаційній системі, тощо. 
У статті доктора психологічних наук, професора Яковенко С.І. та кандидата 
психологічних наук Гурлєвої Т.С. "Можливості дистанційного консультування в 
утруднених умовах життя" [6] підкреслюється наявність перспектив комунікації 
психолога з клієнтом саме через буквений текст.  
Автори зазначають, що дистанційне консультування сьогодні є, фактично, чи 
не єдиним найбільш доступним способом для великої кількості людей вчасно 
отримати потрібну їм допомогу в особливих умовах епідемій і воєнного стану.  
Разом з тим, в роботі відзначається, що донедавна більша частина опитаних 
респондентів, які потребували консультації психолога, віддавали перевагу саме 
очному способу комунікації. Зокрема, очному консультування віддавали перевагу 
53,8% опитаних, через пресу, сайти, посібники - 42,4%, посередництвом телефону 
довіри - 3,8%.  
Автори також відмічають недоліки окремих існуючих інформаційних систем, 
коли клієнт онлайн-сервісу не може відслідкувати результати надання послуги, не 
має механізму оскарження дій консультанта, не повною мірою розуміє загальний 
принцип роботи того чи іншого інформаційного ресурсу, що є однієї з поширених 
причин уникнення консультацій онлайн.  
Такі маркери мають бути враховані при розробці нових інформаційних систем. 
1.2. Пошук методів та засобів, які вже використовуються; виявлення та 
усунення актуальних проблем, що виникають в процесі виконання завдань  
 16 
В процесі створення моделі комп’ютерно опосередкованих комунікацій 
виникають проблеми технічної реалізації окремих блоків інформаційної системи. 
Наукова праця на тему “Створення веб-форуму при використанні сучасних 
технологій веб-розробки” опублікована в онлайн-журналі “Проблеми 
інформатизації та управління” (збірник наукових праць) 1(73)/2023 Національного 
авіаційного університету [7] містить напрацювання з безпосереднього створення 
інформаційної системи у вигляді веб-форуму.  
Автори праці Холявкіна Т.В., Резаєв Я.О., Харченко О.О. запропонували 
архітектуру системи на основі такого стеку технологій:  
Front-End: HTML5, CSS3, Vue.js, Materialize & Bootstrap 4; 
Back-End: PHP, Laravel, Socket.io, Amazon S3 & MySQL. 
 Як бачимо, основою для front-end обрано  HTML5 та CSS3, що дозволяє 
зверстати проєкт згідно вимог технічного завдання.  
Основою для back-end обрано PHP, а для спрощення розробки та економії 
часу, веб-фреймворком PHP обрано Laravel, що має відкритий сирцевий код та 
використовується для веб-додатків за схемою Model–view–controller (MVC) в основі 
якого лежить Symfony.    
Видається, що такий стек технологій оптимально відповідає виконанню 
поставленої задачі. Разом з тим, в нашому випадку використана не PHP а JavaScript 
з деяких причин. Серед них: можливість оновлення сторінки чи її частини без 
необхідності перезавантаження; використання JavaScript Object Notation, як 
полегшеного формату даних, що дає переваги Node.js в ході взаємодії з JSON.  
Серед проблем, вирішення яких має місце в ході виконання завдання щодо 
створення клієнтської частини, є забезпечення сумісності і коректної роботи 
інформаційного ресурсу на різних операційних системах, різних браузерах та різних 
платформах. Одним з методів вирішення тут є застосування webkit. 
Також має місце вирішення проблеми з швидкістю завантаження сторінок 
ресурсу, що досягається перевикористанням окремих блоків кода та адаптивним 
 17 
способом відображення контенту різної якості залежно від пристрою, з якого 
відбувається взаємодія з системою. 
Ще однією проблемою, подолання якої є обв’язковою умовою реалізації 
платформи, стала необхідність побудувати внутрішню архітектуру ресурсу таким 
чином, щоб залишалось доступним наступне масштабування системи з додавання 
нових блоків, збільшення ресурсоємності існуючих чи прибирання зайвих елементів 
без порушення функціональної цілісності.  
1.3. Конкретизація завдання 
Завданням даної кваліфікаційної роботи магістра є документування  процесів 
аналізу, планування, визначення архітектурних рішень та практичної реалізації 
моделі комп’ютерно опосередкованих комунікацій, здатної задовольняти потреби 
декількох зацікавлених груп (стейкголдерів). 
Посередництвом використання онлайн-платформи: 
- молоді юристи повинні мати можливість здобувати досвід надання 
юридичних консультацій у декількох галузях права;  
- запитувачі повинні мати просту доступну можливість отримувати вчасні 
безоплатні правничі консультації базового рівня складності;  
- досвідчені юристи повинні мати можливість поділитися набутим досвідом; 
- роботодавці повинні мати можливість обирати серед учасників проєкту 
нових працівників у сфері права. 
Програмна реалізація клієнтської частини має бути здійснена засобами 
HTML5, CSS3 та JavaScript із застосуванням таких технік в каскадних таблицях 
стилів, як Flex та Grid. 
1.4. Питання, що залишились невирішеними та власне місце магістранта 
у розв'язанні задачі 
 Під час реалізації проєкту на інженерному рівні не виявлено проблем, які 
могли б завадити створенню та функціонуванню онлайн-платформи, враховуючи 
 різноманіття інструментів програмної реалізації. 
 18 
 Натомість складною для вирішення залишається проблема швидкого 
поширення інформації про цей сервіс, враховуючи відсутність будь-якого 
фінансування  проєкту та його виконання виключно силами магістрантів та 
науковців Черкаського державного технологічного університету. 
 Власне місце автора у реалізації проєкту виражене у початковому 
проєктуванні й наповненні інформаційної системи правничим змістом з подальшою 
програмною реалізацією клієнтської частини коду.  
Висновок стосовно необхідності проведення досліджень у даній галузі 
Викладений вище аналіз доводить актуальність створення та мультиплікації 
інформаційних систем комп’ютерно опосередкованої комунікації, свідчить про 
наявність ряду проблем на шляху їх реалізації та існування методів для їх вирішення.  
Програмна платформа соціального проєкту на розв'язання проблеми 
безробіття в галузі права та розширення засобів безоплатної первинної правничої 
допомоги може бути корисною для суспільства, що вказує на необхідність 
проведення досліджень у даній галузі.    
  
 19 
2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ 
2.1. Теоретичні дослідження 
Задача: Розробити онлайн-платформу для надання безоплатних юридичних 
консультацій молодим юристами малозабезпеченим верствам населення з 
використанням HTML5 та CSS3 для написання клієнтської частини, з метою 
забезпечення доступності та якості юридичних послуг для цільової аудиторії. 
Класифікація задачі: 
Тип задачі: Розробка онлайн-платформи. 
Характер задачі: Проектування та розробка програмного забезпечення. 
Сфера задачі: Правова допомога, веб-розробка. 
Метод розв'язання: Використання HTML5, CSS3, JavaScript для створення 
клієнтської частини платформи. 
Цільова аудиторія: Молоді юристи та малозабезпечені верстви населення. 
Ідентифікація задачі: 
Основні завдання: 
- розробка інтерфейсу для користувачів. 
- розробка механізму реєстрації та аутентифікації користувачів. 
- підтримка системи зворотного зв'язку та відправлення запитів юристам. 
- забезпечення безпеки та конфіденційності інформації користувачів. 
- оптимізація продуктивності та доступності платформи. 
Прогнозування задачі: 
Прогнозування використання платформи молодими юристами та потреб 
користувачів у безоплатних юридичних консультаціях для малозабезпечених верств 
населення включає такі показники: 
Кількість зареєстрованих користувачів на платформі: 
Прогнозування може базуватися на історичних даних щодо темпів реєстрації 
користувачів. Наприклад, може розглядатись тенденція зростання реєстрацій із 
застосуванням методів часових рядів для прогнозування майбутніх значень. 
 20 
Кількість запитів користувачів на консультації: 
Прогнозування кількості запитів може ґрунтуватися на попередніх звітах та 
статистиці з розвитку платформи. Використання регресійних моделей або методів 
аналізу даних допоможе прогнозувати зростання або зменшення попиту на 
консультації. 
Якість та задоволеність користувачів: 
Прогнозування якості обслуговування та задоволеності користувачів може 
використовувати методи анкетування та звітування користувачів, а також дані про 
час очікування відповідей та задоволеність їхніми результатами. 
Ефективність роботи юристів: 
Для прогнозування ефективності роботи юристів на платформі можна 
використовувати аналіз часу відповіді на запити, якість наданих консультацій та 
зворотний зв'язок від користувачів. 
Залучення нових юристів: 
Прогнозування може базуватися на попередніх даних щодо процесів 
залучення нових юристів на платформу.  
Оптимізація задачі: 
Мета оптимізації: Забезпечення максимальної ефективності та доступності 
платформи для користувачів, а також забезпечення високої якості юридичних 
консультацій. 
Параметри оптимізації: 
Час відповіді на запити користувачів: Мінімізація часу очікування 
користувачів на відповіді від юристів для поліпшення їхнього досвіду користування 
платформою. 
Якість наданих консультацій: Максимізація якості юридичних консультацій 
для забезпечення задоволеності та задоволення потреб користувачів. 
Ефективність використання ресурсів: Ефективне використання ресурсів, 
включаючи людські ресурси (юристи), сервери та мережеві ресурси, для зниження 
витрат і підвищення продуктивності. 
 21 
Стратегії оптимізації: 
Паралельна обробка запитів: Передбачено використання технологій та 
серверних рішень для паралельної обробки запитів користувачів, зменшення часу 
очікування і підвищення продуктивності. 
Контроль якості: Заплановано на подальших етапах встановлення процедури 
та стандарту для контролю якості наданих консультацій, включаючи перевірку та 
оцінку відповідей юристів. 
Моніторинг продуктивності: Заплановано на подальших етапах  
використання інструментів моніторингу для відстеження продуктивності серверу, 
виявлення проблем та їх швидкого виправлення. 
Навчання та розвиток юристів: Заплановано на подальших етапах 
забезпечення навчання та професійного розвитку юристів на платформі для 
підвищення якості консультацій. 
Оптимізація ресурсів: Заплановано на подальших етапах  використання 
методів оптимізації ресурсів, такі як віртуалізація та хмарні рішення, для зменшення 
витрат та підвищення доступності. 
Вимірювання результатів: Заплановано на подальших етапах ключових 
показники ефективності (KPIs) для вимірювання результатів оптимізації, 
включаючи середній час відповіді, відсоток задоволених користувачів та витрати на 
обслуговування платформи. 
Ці стратегії оптимізації допоможуть забезпечити роботу платформи на 
ефективному рівні, надаючи високоякісні юридичні консультації малозабезпеченим 
верствам населення, і при цьому мінімізувати витрати та час очікування для 
користувачів. 
Математична форма класифікації для вищевказаної платформи може бути 
представлена у вигляді системи параметрів і критеріїв, що допомагають 
класифікувати та ідентифікувати основні характеристики системи, зокрема: 
Параметри класифікації: 
 22 
Рівень доступності: A - цей параметр визначається як функція, що враховує 
час відповіді на запити користувачів та доступність платформи у відсотках. 
Наприклад,  A = f(час_відповіді, доступність). 
Якість консультацій: Q - цей параметр визначається на основі оцінок якості 
наданих юридичних консультацій користувачами. Наприклад, Q = 
f(оцінки_консультацій). 
Продуктивність: P - цей параметр визначається як функція, що враховує 
кількість оброблених запитів користувачів та ефективність використання ресурсів. 
Наприклад, P = f(кількість_запитів, ефективність). 
Критерії класифікації: 
Рівень доступності (A): 
Високий рівень доступності: A > X (де X - порогове значення, яке визначає 
високий рівень). 
Середній рівень доступності: Y < A \ X (де Y - порогове значення, що визначає 
середній рівень). 
Низький рівень доступності: A \ Y. 
Якість консультацій (Q): 
Висока якість: Q > Z (де Z - порогове значення, яке визначає високу якість). 
Середня якість: W < Q \ Z (де W - порогове значення, що визначає середню 
якість). 
Низька якість: Q \ W. 
Продуктивність (P): 
Висока продуктивність: P > V (де V - порогове значення, яке визначає 
високу продуктивність). 
Середня продуктивність: U < P \ V (де U - порогове значення, що визначає 
середню продуктивність). 
Низька продуктивність: P \U. 
Ця математична форма дозволяє класифікувати платформу за визначеними 
критеріями на основі вимірюваних параметрів. Вона може бути корисною для 
 23 
визначення якості та ефективності роботи платформи та встановлення порогових 
значень для оцінки цих критеріїв. 
2.1.1. Інформаційний аналіз, як елемент системного підходу до дослідження 
Інформаційний аналіз - це важлива частина дослідження, яка допомагає 
розібратися у вже існуючих рішеннях та підходах до схожих проблем або проектів.  
Завдання роботи формалізується, як задача структурної ідентифікації 
інформаційної системи безоплатної первинної правової допомоги: 
Дано за результатами аналізу вимог:  
1 Перелік функцій, які повинна виконувати система: 
 
V = (V1, V2, …, Vn) (2.1) 
2 Задана мета функціонування M системи програмної реалізації технології 
“Програмне забезпечення інформаційної системи безоплатної первинної правової 
допомоги: клієнтська частина”. 
Необхідно забезпечити: 
структурну ідентифікацію інформаційної системи 
 
M = ⨏ (V1, V2, …, Vn), (2.2.) 
 
тобто необхідно визначити елементний склад множини підсистем S 
 
S ={s1, s2,..., sm}, (2.3) 
та множини їх зв’язків W: 
 
W={w1, w2, …, wk}, (2.4) 
за існуючих обмежень по ресурсам, множина яких задається виразом: 
 24 
 
R=[r1, r1, …, rl], (2.5) 
де: 
r1 - час відгуку системи; 
r2 - кваліфікація виконавців; 
r3 - витрати комп’ютерних ресурсів. 
Таким чином завданням дослідження є побудувати функціонал f, який забезпечує 
еквівалентність перетворень двох частин виразу: 
 
M = ⨏ (V, R, S, W), (2.6) 
 
де, M - мета, R - ресурси, V - множина вимог, S - структура елементів, W-зв’язки. 
2.1.2. Аналіз схожих платформ 
Платформа з надання консультацій у текстовому вигляді відрізняється від 
платформи з відеоконсультаціями лише форматом передачі даних. Глобально, суть 
роботи обох сервісів є однаковою - комунікація між фахівцями та їх клієнтами, 
результатом якої є надання допомоги клієнту та підвищення професійного рівня 
фахівця. Аналіз схожих платформ проведемо на прикладі телемедичних українських 
сервісів. 
Сервіс Medinet розпочав роботу у 2019 році, є платформою медичних 
відеоконсультацій, починав роботу з Одеської області і поступово поширювалась і 
інші регіони. Формати роботи: «лікар–лікар», «лікар–пацієнт». Особливістю, що 
вирізняє, є можливість спілкування між лікарями. Розробником цього продукту є 
група компаній IT4Medicine. 
Сервіс Поліклініка без черг є системою, що позбавляє від черг, для медзакладу 
містить повний функціонал для роботи з системою eHealth. Має функцію віддалених 
медичних консультацій у відеоформаті. Пацієнт потрапляє на консультацію до 
лікаря, завчасно обираючи зручний час в календарі. Модуль телемедицини у цій 
 25 
платформі є запозиченим з системи Medinet, оскільки обидві системи є розробкою 
компанії IT4Medicine. 
Telemed24 - ще одна платформа дистанційного консультування пацієнтів 
лікарями. Тут пацієнт може замовити дистанційну консультацію з лікарем, мати в 
доступі власну історію візитів та всіх зроблених для нього призначень, тут можна 
шукати потрібний медичний заклад а також потрібного фахівця, призначення щодо 
лікування надходить від лікаря в електронну медичну картку пацієнта. Доступ до 
системи є безоплатним. 
Doctor Online - додаток для отримання онлайн-консультацій від лікарів. 
Пропускна здатність системи дозволяє здійснити 5 тис. консультацій за добу. У 
пацієнта є вибір, спілкуватись з лікарем в чаті, по відео чи за допомогою 
аудіодзвінка. Пацієнт може відправити лікарю документи в електронному вигляді та 
отримати електронні направлення, зробити замовлення на доставку ліків, на місці 
зробити оплату посередництвом банківської картки. Пацієнт може завчасно 
ознайомитись з інформацією про досвід лікаря, його рейтинг, а по завершенні 
комунікації залишити відгук про роботу лікаря та платформи в цілому. 
Medikit – сервіс миттєвої онлайн-консультації з лікарем із будь-якого куточка 
світу. Він стартував у листопаді 2018 року. Первинна реєстрація на платформі є 
безкоштовною. Подальше користування сервісом передбачає оплату залежно від 
обраного тарифу. 
 Ми розглянули телемедичні сервіси України. Також маємо можливість 
коротко оглянути український онлайн-сервіс юридичних консультацій. 
 Protocol - онлайн маркетплейс дистанційного надання, юридичних послуг та 
консультацій. Має функцію безоплатних юридичних консультацій, реалізовану у 
вигляді текстових чатів. Містить широкий вибір юристів, які спеціалізуються в 
різних галузях права. 
2.1.3. Аналіз потреб цільової аудиторії 
 Молоді юристи без досвіду роботи потребують цього досвіду, оскільки 
наявність досвіду суттєво збільшує вибір вільних вакансій. 
 Використаємо можливості порталу robota.ua [8]  
 26 
 Станом на 08 листопада 2023 року спробуємо визначити кількість вакансій, що 
доступні юристам. 
 На рис. 2.1. показано застосування фільтрів, де серед іншого ми не обрали 
варіант “Тільки без досвіду роботи”   
 
 
Рисунок 2.1. — Опція “Тільки без досвіду роботи” не обрана 
 
Також, серед доступних рубрик для пошуку вакансії оберемо “Юристи, 
адвокати, нотаріуси” - див.Рис.2.2.  
 
 
Рисунок 2.2. — Рубрика “Юристи, адвокати, нотаріуси” - 1194 вакансії 
 
 Тут ми можемо бачити, що станом на 08 листопада 2023 року кількість 
вакансій для юристів з досвідом роботи складає 1194 одиниці. 
Тепер змінимо налаштування фільтру і оберемо опцію “Тільки без досвіду 
роботи” (див. Рис. 2.3.)    
 
 27 
 
Рисунок 2.3. — Опція “Тільки без досвіду роботи” - обрана 
 В результаті цього, у рубриці “Юристи, адвокати, нотаріуси” ми бачимо, що 
доступна кількість вакансій для юристів без досвіду складає 74 одиниці. 
 
 
Рисунок 2.4. — Рубрика “Юристи, адвокати, нотаріуси” - 74 вакансії 
  
 Якщо I - ймовірність отримати роботу, D - кількість вакансій для юристів з 
досвідом, B - кількість вакансій для юристів без досвіду, то ймовірність визначається 
рівнянням: 
I = D / B 
1194 / 74 =  16,135135 
 
Це наглядно демонструє, що наявність досвіду роботи збільшує шанси юриста 
отримати роботу у 16 разів. 
Можна побачити, що досвід у сфері торгівлі, який побічно відображався у 
фільтрах під час виконання нашого міні-експерименту, за тих же умов є менш 
значущим для претендента на роботу, тут досвід роботи дає перевагу лише у 6 разів. 
 28 
18430 / 2943 = 6,262317 
 
Разом з тим, в абсолютних цифрах кількість вакансій для роботи в торгівлі за 
наявності досвіду складає 18430 одиниць, а кількість вакансій в юриспруденції за 
тих же умов складає лише 1194 одиниці. Це вказує на той факт, що роботу в 
галузі торгівлі знайти у 15 разів легше, аніж у галузі юриспруденції. 
 
18430 / 1194 = 15,435510 
 
 З викладеного в цілому слідує, що роботи у сфері торгівлі в певний момент 
часу у 15 разів більше, аніж в юриспруденції, а наявність досвіду менш значуща 
для сфери торгівлі, адже збільшує шанс на отримання роботи лише у 6 разів, та 
суттєво більш значуща у сфері юриспруденції, адже збільшує шанс на отримання 
роботи у 16 разів. 
Потреба молодих юристів у набутті досвіду  очевидною і задачею нашого 
дослідження та його практичних результатів є надання можливості отримати такий 
досвід якомога більшій кількості молодих юристів.   
Проведено запит до популярного Google-сервісу Trends [9] скільки Google за 
останні 7 днів (станом на 04 листопада 2023 року) у певному регіоні зафіксовано 
запитів “консультація юриста”, а скільки “консультація лікаря” (див.Рис. 2.5.). 
 
 29 
 
Рисунок 2.5. — Задаємо вміст запитів у Google за останні 7 днів 
 
 Аналітична система Trends показала (див.Рис. 2.6.), що 04 листопада 2023 року 
запит “консультація юриста” здійснено 100 разів, а “консультація лікаря” - 24 рази. 
 
Рисунок 2.6. — Графік активності запитів у Google 
 
 Показане може свідчити, що в певний момент часу потреба людей у 
консультації юриста переважала потребу в консультації лікаря у 4 рази. 
 У підсумку: 
- є очевидною потреба молодих юристів отримати досвід практичної 
діяльності, як суттєву умову для успішного працевлаштування;  
- є очевидною потреба людини отримувати юридичні консультації, і ця 
потреба в певні моменти часу у кілька разів перевищує навіть базову 
потребу людини підтримувати власне здоров’я. 
 30 
2.1.4. Технічний аналіз 
Технічні аспекти створення платформи передбачають підбір інженерних 
інструментів, з використанням яких реалізація платформи є можливою. 
Для реалізація клієнтської частини нашої платформи мали бути використані 
такі інструменти: 
HTML5 
Мова гіпертекстової розмітки HTML (HyperText Markup Language) є 
стандартною мовою для створення та розмітки веб-сторінок. Ось деякі 
характеристики HTML: 
Розмітка тексту: HTML дозволяє визначати структуру та форматування 
тексту на веб-сторінці, включаючи заголовки, абзаци, списки, виноски та інше. 
Гіперпосилання: HTML дозволяє створювати гіперпосилання (посилання) на 
інші веб-сторінки, ресурси або файли. Гіперпосилання допомагають користувачам 
навігувати по інтернету. 
Мультимедійні елементи: HTML підтримує вставку мультимедійних 
елементів, таких як зображення, відео та аудіо, що дозволяє зробити веб-сторінки 
більш цікавими та інтерактивними. 
Форми: HTML надає можливість створювати веб-форми для збору даних від 
користувачів, такі як реєстраційні форми, пошукові поля і коментарі. 
Таблиці та списки: HTML дозволяє створювати таблиці для відображення 
даних у вигляді сітки та різні види списків (нумеровані, марковані, описові). 
Метадані: HTML дозволяє включати метатеги, які надають інформацію про 
веб-сторінку, таку як заголовок, мова, ключові слова та інше. 
Каскадні таблиці стилів (CSS): HTML може бути поєднаний з CSS для більш 
складного та красивого оформлення веб-сторінок. CSS дозволяє визначати стилі, 
кольори, розміри і розташування елементів сторінки. 
Сумісність із браузерами: HTML є стандартом, який підтримується більшістю 
сучасних веб-браузерів, що робить його ефективним для створення веб-сайтів, які 
працюють на різних платформах. 
 31 
Розширюваність: HTML постійно оновлюється, і нові версії додають нові 
функції та можливості, що дозволяє розширювати можливості веб-розробки. 
HTML є важливою мовою для веб-розробки, і вона дозволяє створювати 
різноманітні веб-сторінки, від простих блогів до складних веб-додатків. 
HTML використовується для створення структури та макету веб-сторінок, але 
для створення онлайн-платформи для безоплатних текстових приватних юридичних 
консультацій нам також знадобиться інші технології, такі як серверна частина, база 
даних і програмування. Однак HTML грає важливу роль в розробці клієнтської 
частини нашої платформи.  
Нижче показано невеликий опис, як HTML може бути використаний: 
Створення сторінок інформації: HTML використовується для створення 
сторінок, які містять інформацію про нашу онлайн-платформу для юридичних 
консультацій, включаючи опис послуг, контактну інформацію та інші деталі. 
Форми для вводу даних: HTML дозволяє створювати веб-форми, які можуть 
бути використані користувачами для надсилання запитів на юридичні консультації. 
Форми можуть містити поля для введення ім'я, контактної інформації, питань та 
інших необхідних даних. 
Гіперпосилання та навігація: Ми можемо використовувати гіперпосилання 
(посилання) для створення зручної навігації на нашому веб-сайті. Наприклад, мати 
окремі сторінки для різних видів консультацій або інформації про наші юридичні 
послуги. 
Відображення результатів: HTML може бути використаний для 
відображення результатів або відповідей юристів на запити користувачів. 
Результати можуть бути відформатовані та представлені на веб-сторінці. 
Мобільна оптимізація: Важливо забезпечити, щоб наш веб-сайт був 
оптимізований для мобільних пристроїв, і HTML дозволяє створювати адаптивний 
дизайн для різних типів пристроїв. 
Проте, для реалізації функціональності платформи для безоплатних 
юридичних консультацій нам також знадобиться програмування (наприклад, мови 
 32 
програмування на стороні сервера, такі як Node.js для обробки і зберігання даних, а 
також база даних для зберігання інформації про користувачів та юридичні 
консультації. 
HTML використовується для створення візуальної частини веб-сторінок, але 
весь функціонал нашої онлайн-платформи буде реалізовано за допомогою інших 
технологій, таких як JavaScript, серверні мови програмування та база даних SQL. 
CSS3 (Cascading Style Sheets 3) є останньою версією мови CSS, яка 
використовується для опису стилів і вигляду веб-сторінок. CSS3 внесла безліч 
нововведень та поліпшень порівняно з попередніми версіями CSS (CSS1 та CSS2). 
Ось деякі з основних характеристик CSS3: 
Модульність: CSS3 розділена на модулі, кожен з яких визначає конкретну 
функціональність. Це дозволяє розробникам використовувати лише необхідні 
модулі, що полегшує керування та розвиток стилів. 
Змінні (Variables): CSS3 вперше вводить підтримку змінних, що дозволяє 
визначати і використовувати змінні для кольорів, розмірів шрифту, відступів та 
інших стилів, спрощуючи процес редагування та підтримки коду. 
Гнучка рамка (Flexbox): CSS3 Flexbox - це модель розміщення, яка спрямована 
на полегшення створення розкладки елементів в контейнері. Вона надає більшу 
гнучкість при розташуванні та вирівнюванні елементів. 
Модуль CSS Grid: CSS Grid - це модель розміщення, яка дозволяє створювати 
складні розкладки на веб-сторінках з легкістю. Вона надає контроль над 
розташуванням та розмірами елементів в таблицях та рядках. 
Анімація та переходи (Transitions): CSS3 дозволяє створювати анімацію та 
переходи між станами елементів, що поліпшує інтерактивність веб-сторінок. 
Затінення (Shadows): З CSS3 ви можете додавати тінь до елементів, що 
дозволяє створювати тривимірний вигляд та покращувати візуальну привабливість 
сторінок. 
 33 
Колір і прозорість (RGBA, HSLA): CSS3 вводить нові способи визначення 
кольорів, включаючи RGBA (кольори з прозорістю) та HSLA (кольори на основі 
відтінку, насиченості, світлоти). 
Підтримка шрифтів (Web Fonts): CSS3 дозволяє використовувати зовнішні 
шрифти, що покращує творчі можливості та вигляд тексту на веб-сторінках. 
Медіа-запити (Media Queries): CSS3 дозволяє використовувати медіа-запити 
для адаптивного дизайну, що дозволяє налаштовувати стилі в залежності від 
властивостей пристрою та вікна перегляду. 
Можливості трансформації (Transforms) та перетинання (Transitions): CSS3 
дозволяє використовувати 2D та 3D трансформації, а також створювати плавні 
переходи між станами елементів. 
CSS3 вдосконалила і розширила можливості стилізації веб-сторінок, 
зробивши веб-дизайн більш креативним і інтерактивним. Вона є невід'ємною 
частиною розробки веб-сайтів і допомагає створювати красиві та функціональні 
інтерфейси. 
В нашому випадку, CSS3 використаний для створення привабливого та 
функціонального дизайну онлайн-платформи безоплатних текстових приватних 
юридичних консультацій.  
Ось деякі з використаних функцій: 
Вигляд і макет: CSS3 дозволяє налаштовувати кольори, шрифти, розміри та 
відступи, щоб створити привабливий та чіткий дизайн для нашої платформи. Це 
дозволяє визначити стилі для заголовків, тексту, кнопок і інших елементів, щоб 
надати їм сучасний та професійний вигляд. 
Адаптивний дизайн: Використання медіа-запитів в CSS3 дозволяє створити 
адаптивний дизайн, який автоматично пристосовується до різних розмірів екрану та 
пристроїв. Це особливо важливо для забезпечення зручного користування на 
мобільних пристроях. 
 34 
Зображення та іконки: CSS3 дозволяє застосовувати зображення та іконки, 
включаючи мікроанімації, щоб надати нашій платформі ефектність та візуальний 
інтерес.  
Анімація та переходи: Використання CSS3 анімації та переходів допомагає 
зробити нашу платформу більш інтерактивною. Зокрема, додані анімовані кнопки 
для відправлення запитів на консультації та плавні переходи між сторінками. 
Форми та валідація: CSS3 дозволяє стилізувати веб-форми та повідомлення 
про валідацію полів. Ми використовуємо різні стилі для позначення правильно 
введених та невірно введених даних. 
Тінь та 3D-ефекти: CSS3 надає можливість додавати тіні до елементів, 
створювати тривимірний ефект та зробити деякі частини інтерфейсу більш 
виділяються. 
Прозорість та фонові зображення: CSS3 дозволяє використовувати 
прозорість для створення ефектів, а також встановлювати фонові зображення для 
різних елементів. 
Круглі кути та рамки: Ми заокруглили кути блоків, створили рамки 
 навколо елементів та налаштували їх вигляд. 
Трансформації: Використання трансформацій CSS3 дозволяє обертати, 
масштабувати та змінювати розміри елементів, що може бути корисним для 
відображення додаткової інформації або взаємодії користувача. 
В цілому, CSS3 грає важливу роль у створенні ефективного та привабливого 
дизайну для нашої платформи для юридичних консультацій, що робить її зручною 
та привабливою для користувачів. 
JavaScript (або скорочено JS) - це високорівнева, інтерпретована мова 
програмування, яка використовується для розробки веб-додатків і додатків для 
багатьох платформ. JavaScript є однією з найпоширеніших мов програмування у світі 
і відома своєю важливою роллю в розвитку веб-технологій. Ось декілька 
характеристик JavaScript: 
 35 
Веб-розробка: JavaScript використовується для створення інтерактивних веб-
сторінок і веб-додатків. Вона дозволяє додавати функціональність, яка реагує на дії 
користувачів, такі як кліки, наведення миші і введення даних. 
Крос-платформеність: JavaScript може виконуватися в браузерах на різних 
операційних системах, що робить його крос-платформеним і дозволяє розробникам 
створювати веб-додатки, які працюють на різних пристроях. 
Об'єктно-орієнтований підхід: JavaScript підтримує об'єктно-орієнтований 
стиль програмування, де дані та функції групуються в об'єкти, що полегшує 
організацію коду. 
Динамічна мова: JavaScript - це динамічно типізована мова, що дозволяє 
змінювати типи змінних та об'єктів під час виконання програми. 
Велика кількість бібліотек та фреймворків: Існують численні бібліотеки та 
фреймворки, які розширюють можливості JavaScript та спрощують розробку веб-
додатків. Найпопулярніші з них - jQuery, React, Angular, та Vue.js. 
Асинхронний код: JavaScript підтримує асинхронний код, що дозволяє 
виконувати операції, які не блокують інші частини програми, що забезпечує 
відзивчивість веб-сторінок. 
Специфікація ECMAScript: JavaScript базується на стандарті ECMAScript, який 
постійно оновлюється, додаючи нові функції та покращення. Найновіша версія - 
ECMAScript 2021. 
Використання поза вебом: JavaScript також використовується для розробки 
додатків поза веб-середовищем, таких як серверні додатки (за допомогою Node.js) 
та мобільні додатки (за допомогою фреймворків, таких як React Native). 
Спільнота та екосистема: JavaScript має велику та активну спільноту 
розробників, що робить його однією з найбільш підтримуваних мов програмування.  
В нашому випадку, JavaScript корисна для створення клієнтської частини 
онлайн-платформи безоплатних текстових приватних юридичних консультацій, щоб 
надати користувачам зручну та інтерактивну взаємодію з платформою.  
Ось деякі способи такого використання: 
 36 
Валідація та обробка форм: JavaScript дозволяє виконувати валідацію даних, 
які користувач вводить у форми на нашій платформі. Ми можемо перевіряти 
правильність введених даних та повідомляти користувача про помилки без 
необхідності перезавантаження сторінки. 
Автозавантаження та оновлення: JavaScript може бути використана для 
автоматичного завантаження нових даних або оновлень без необхідності оновлення 
всієї сторінки. Це корисно для відображення нових запитів на консультації або 
повідомлень. 
Інтерактивність чату: Для створення текстового чату між користувачем і 
юристом ми можемо використовувати JavaScript для надання можливості надсилати 
повідомлення в реальному часі та відображати їх на сторінці без необхідності 
оновлення. 
Управління вікнами і діалогами: JavaScript дозволяє створювати вікна, діалоги 
та сповіщення для покращення користувацького досвіду. Ми можемо відкривати 
діалогові вікна для запиту додаткової інформації або відображення результатів 
консультацій. 
Зміна стилів та анімація: JavaScript дозволяє динамічно змінювати стилі та 
анімувати елементи сторінки. Ми можемо застосовувати анімацію до переходів між 
сторінками або для виділення важливої інформації. 
Локалізація та переклад: Ми можемо використовувати JavaScript для 
підтримки різних мов та локалізацій на нашій платформі, щоб надати доступ 
користувачам з різних країн. 
Аутентифікація та безпека: JavaScript може бути використана для валідації 
аутентифікації користувачів та забезпечення безпеки даних на клієнтській стороні. 
Керування вмістом: JavaScript дозволяє динамічно відображати і оновлювати 
вміст сторінки, включаючи інформацію про запити на консультації, профілі 
користувачів та історію спілкування. 
 37 
Загалом, JavaScript робить нашу платформу більш інтерактивною та корисною 
для користувачів, дозволяючи їм легко взаємодіяти з вашими послугами та 
отримувати необхідну інформацію. 
2.1.5. Аналіз правових аспектів  
При розробці платформи враховано постулати Правил адвокатської етики [10] 
в частині дотримання адвокатської таємниці, правил комунікації між правником та 
клієнтом, стандартів якості надання правової допомоги.  
Окремим і не менш важливим аспектом правового регулювання роботи 
онлайн-платформи є дотримання в її роботі кожним учасником правил, закріплених 
у Законі України “Про захист персональних даних” [11].  
Крім того, діяльність платформи в цілому має відповідати правовим засадам, 
закріпленим у Цивільному кодексі України [12] та супутніх йому нормативно-
правових актів, що стосуються галузі надання послуг. 
Згідно Закону України «Про національну програму інформатизації» від 
04.02.1998 р. № 74/98-ВР (цитата): «Інформаційна технологія – цілеспрямована 
організована сукупність інформаційних процесів з використанням засобів 
обчислювальної техніки, що забезпечують високу швидкість обробки даних, 
швидкий пошук інформації, розосередження даних, доступ до джерел інформації 
незалежно від місця їх розташування» [13]. 
Відповідно до міжнародного стандарту ISO/IEC 38500:2015 «Управління 
інформаційними технологіями в організаціях» інформаційними технологіями 
ресурси, що необхідні для збору, обробки, зберігання і розповсюдження інформації 
[14].  
Розпорядженням Кабінету міністрів України «Про схвалення Концепції 
розвитку цифрової економіки та суспільства України на 2018–2020 роки та 
затвердження плану заходів щодо її реалізації» від 17 січня 2018 р. № 67-р. [15] 
визначено, що цифровізація – це насичення фізичного світу електронно-цифровими 
пристроями, засобами, системами та налагодження електронно-комунікаційного 
 38 
обміну між ними, що фактично уможливлює інтегральну взаємодію віртуального та 
фізичного, тобто створює кіберфізичний простір. 
Створювана нами платформа і є тим кіберфізичним простором для ефективних 
комунікацій. 
2.1.6. Соціальний вплив  
Складно оцінити реальний соціальний вплив того чи іншого проєкту допоки 
немає досить тривалого досвіду використання такої платформи.  
Разом з тим, якщо не брати до уваги економічні аспекти, саме по собі існування 
інформаційної системи, яка допомагає фахівцям генерувати досвід, одночасно 
приносячи суспільну користь від надання на безоплатній основі юридичних 
консультацій базового рівня, повинно спричинити певний позитивний соціальний 
вплив. 
На ринку праці буде більше досвідчених, впевнених у собі юристів, що 
позитивно відобразиться на їх працездатності, економіці відносин цієї галузі послуг 
в цілому. Загальний рівень суспільної правосвідомості може піднятись на кілька 
умовних пунктів за рахунок отримання членами суспільства більше 
правових рекомендацій.   
В очах міжнародної спільноти наша країна стане ще ближче до високих 
європейських стандартів доступності до правової допомоги для якомога ширших кіл 
суспільства.   
2.1.7. Структурно-інформаційний аналіз, як елемент системного підходу до 
дослідження 
Структурно-інформаційний аналіз спрямований на розгляд структури даних, 
процесів та взаємозв'язків всередині системи або проєкту. У дослідженні зі 
створення онлайн-платформи для надання юридичних консультацій молодим 
юристам для малозабезпечених верств населення, структурно-інформаційний аналіз 
є таким: 
 39 
Структура платформи: 
Клієнтська частина платформи структурно являє собою доступну відвідувачу 
презентаційну частину платформи а також окремі розділи “Теми на обговоренні”, 
“Юристи”, “Ментори”, “Відгуки”, “Роботодавцю”.  
Кожен з класів акторів має власний спосіб входу на платформу для відкриття 
індивідуальних для кожного з них набору функціональних можливостей платформи.  
Так, клас “Відвідувач” являє собою будь-яку сутність, що має вільний доступ 
до презентаційної частини платформи а також розділів “Теми на обговоренні”, 
“Юристи”, “Ментори”, “Відгуки”, “Роботодавцю”. В цьому варіанті використання 
“Відвідувачу” доступні загальні відомості кожного з розділів платформи, без 
розширеного доступу до їх вмісту. Так, наприклад, “Відвідувач” може оглянути 
кількість чатів (тем) на обговоренні, час створення теми, її назву, дані юриста, який 
давав відповідь. Проте, “Відвідувачу” не доступна інформація про внутрішній зміст 
будь-якого чату, про особу, яка отримала консультацію (див.Рис. 2.7.).    
 
 40 
 
Рисунок 2.7. — Структурна схема платформи 
 
 На рисунку видно, що кожен з класів акторів має власний спосіб входу. Так, 
“Відвідувач” може стати “Клієнтом”, якщо пройде процедуру авторизації. Йому 
буде відкрито доступ у кабінет “Клієнта” з формою для формування запитання 
“Юристу”. Всі консультації конкретного “Клієнта” зберігаються в його акаунті і 
доступні “Клієнту” для перегляду.  
“Юрист” і “Ментор” мають власні кабінети (акаунти), доступ до яких 
відкривається внаслідок авторизації. “Юрист” отримує доступ до переліку питань, 
поставлених “Клієнтами” і право обрати питання для формування відповіді на нього 
 41 
або відмовитись від надання відповіді. Всі консультації конкретного “Юриста” 
зберігаються в його акаунті і доступні “Юристу” для перегляду. 
“Ментор” включається в роботу, якщо “Клієнт” в ході отриманні консультації 
у приватному чаті з “Юристом” активував запит “Отримати рецензію ментора”. 
Також ми бачимо, що будь-яка стоворювана на платформі інформація 
зберігається в базі даних. Сюди постійно надходить інформація про кожне нове 
запитання та кожну надану консультацію; тут акумулюється інформація про 
активність юристів і менторів на платформі, яку потім можна отримати в 
структурованому вигляді. 
Функціонал платформи дозволяє “Відвідувачу” без авторизації за допомогою 
фільтру сортувати інформацію про “Юристів”, яка призначення для відбору юристів 
згідно потреб “Відвідувача”, який може потім використати цю інформацію як 
“Клієнт” або “Роботодавець”. Зокрема, це інформація про прізвище та ім’я, 
активність на платформі (кількість наданих консультацій, галузі права, рейтинг, 
відгуки) та особистий внутрішній ідентифікатор (id) для легкого пошуку під час 
замовлення “Клієнтом” консультації, адресованої конкретному “Юристу”. 
“Адмін”, в силу потреби виконувати свої функції, має необмежений доступ до 
всіх даних платформи та обов’язок збереження юридичної таємниці.  
2.1.8. Потоки даних 
Всередині системи відбувається рух даних, спричинений надходженням нових 
запитань, наданням відповідей на них, активністю кожного з класів акторів на 
платформі.  
Дані про кроки авторизації “Клієнта” надходять на сервер, передаються 
поштовому клієнту, звідки знову повертаються на сервер.   
Аналогічно відбувається рух даних при авторизації “Юриста” чи “Ментора”.  
Створення “Клієнтом” запитання має наслідком передачу даних на сервер та 
збереження у базі даних. Відповідь “Юриста” чи рецензія “Ментора” також 
призводить до передачі відповідних даних на сервер та у базу даних. 
 42 
Використання фільтрів при отриманні інформації про “Юристів” 
супроводжується читанням даних з бази даних та відображення результатів на 
клієнтській стороні. 
2.1.9. Функціональність 
Платформа дозволяє “Клієнту”: 
- легко доступитись до “живого” фахівця і в ході комунікації отримати 
корисну для себе інформацію у формі консультації; 
- отримати консультацію безоплатно; 
- здійснювати через фільтр ефективний цільовий відбір як виконавців 
консультаційних послуг, так і майбутніх працівників; 
- спілкуватись з “Юристом” приватно, не наражаючись на розкриття 
персональних даних; 
- отримати рецензію “Ментора” на консультацію “Юриста”; 
- зберігати історію своїх звернень, повертатись до них, уточнювати 
відповідь у конкретного “Юриста”; 
- оцінити роботу “Юриста” чи платформи (оцінка, відгук). 
Платформа дозволяє “Юристу”: 
- обирати запитання для надання відповідей; 
- зупиняти і поновлювати власну діяльність на платформі; 
- набувати й поглиблювати професійний досвід на реальних кейсах; 
- підтверджувати набутий досвід генеруванням сертифікату платформи. 
Платформа дозволяє “Ментору”: 
- обирати запити для надання рецензій; 
- зупиняти і поновлювати власну діяльність на платформі; 
- набувати й поглиблювати професійний досвід на реальних кейсах; 
- підтверджувати набутий досвід генеруванням сертифікату платформи. 
 43 
2.1.10. Архітектура клієнтської частини системи 
 
 
Рисунок 2.8. — Файлова архітектура клієнтської частини платформи  
 
 В основі клієнтської частини платформи знаходиться файл index.html, до 
якого підключено ряд інших файлів.  
Ключовий файл css-стилів названо style.css, він, в свою чергу, імпортує 
вміст додаткових css-файлів зі стилями до відповідних класів (див. рис. 2.8.). 
 44 
Назва css-файлу відповідає назві головного css-класу. Кожен допоміжний css-
файл підключений за допомогою @import до головного файлу style.css. 
 Той же принцип застосовано для підключення всіх html-сторінок до головного 
файлу index.html. Це реалізовано за допомогою внутрішнього перелінкування з 
метою пов'язування сторінок сайту між собою за допомогою гіперпосилань.   
 Врешті, така архітектура дозволяє легко переміщуватись від головної сторінки 
до інших сторінок, використовуючи сторінку меню для зручності. 
2.1.11. Взаємодія між користувачами 
Користувачами сайту є “Відвідувач”, “Клієнт”, “Юрист”, “Ментор”, 
“Адміністратор”.  
На початку роботи з платформою кожен з них, крім  “Адміністратора”, є 
“Відвідувачем”. 
Якщо “Відвідувач” хоче отримати консультацію, він проходить авторизацію в 
якості “Клієнта”, потрапляє на персоналізовану внутрішню сторінку для 
формування запитання (user’s account) і набуває статусу “Клієнт”. Його email тепер 
записаний в базу даних платформи і при наступному відвідувані платформи “Клієнт” 
вже матиме історію, що буде доступна йому на персоналізованій внутрішній 
сторінці для формуванням запитання (user’s account). 
Якщо “Відвідувач” хоче надавати консультації, він проходить авторизацію в 
якості “Юриста”, проходить перевірку “Адміністратора” та потрапляє на 
персоналізовану внутрішню сторінку для відповідей на нові запитання (lawyer’s 
account) і набуває статусу “Юрист”. Його email тепер записаний в базу даних 
платформи і при наступному відвідувані платформи “Юрист” вже матиме історію, 
що буде доступна йому на персоналізованій внутрішній сторінці для відповідей на 
нові запитання (lawyer’s account). Відмічаємо, що на стадії первинної авторизації 
(реєстрації) “Юрист” вперше взаємодіє з “Адміністратором”. 
Якщо “Відвідувач” хоче надавати рецензії на консультації юристів, він 
проходить авторизацію в якості “Ментора”, проходить перевірку “Адміністратора” 
та потрапляє на персоналізовану внутрішню сторінку для реагування на запити 
 45 
рецензій (mentor’s account) і набуває статусу “Ментор”. Його email тепер записаний 
в базу даних платформи і при наступному відвідувані платформи “Ментор” вже 
матиме історію, що буде доступна йому на персоналізованій внутрішній сторінці для 
реагування на запити рецензій (mentor’s account). Відмічаємо, що на стадії первинної 
авторизації (реєстрації) “Ментор” вперше взаємодіє з “Адміністратором”. 
Якщо “Відвідувач” прийшов на платформу як роботодавець, в пошуку нових 
працівників-юристів, то він не проходить жодної авторизації, а взаємодіє з 
платформою шляхом використання фільтру в розділі “Юристи”, де обирає потрібну 
йому конфігурацію відомостей про потрібного юриста (рейтинг, галузь права, 
кількість консультацій), в результаті чого отримує інформацію для зв’язку з 
“Юристом”. 
Взаємодія між “Клієнтом” та “Юристом” відбувається таким чином: 
- “Клієнт” у своєму акаунті заповнив форму для запитання та відправив її в 
систему; 
- “Юрист”  у своєму акаунті побачив запитання, вирішив відповісти, 
натиснув кнопку “Відповісти”, що перенаправило його на сторінку для 
консультації (chat page); 
- “Клієнт” у своєму акаунті  дочекався, коли стала активною кнопка “Увійти 
в чат з юристом” та натиснув її; або, перебуваючи поза акаунтом, в своїй 
електронній пошті (email) натиснув посилання з запрошенням “Увійти в 
чат з юристом”, яке надійшло на його особистий email у вигляді 
гіперпосилання  одразу після натискання “Юристом” кнопки “Відповісти” 
у своєму акаунті - ці дії направляють його на сторінку для консультації 
(chat page); 
- “Юрист” не чекає “Клієнта” на сторінці для консультації (chat page), а 
одразу починає заповнювати формуляр відповіді; 
- “Клієнт” на сторінці для консультації (chat page) бачить напис “Очікуйте, 
юрист пише відповідь” або, якщо “Юрист” вже її написав, “Клієнт” бачить 
текст самої відповіді; 
 46 
- якщо “Клієнт” хоче отримати рецензію “Ментора” на консультацію 
“Юриста”, він тисне кнопку “Отримати рецензію від Ментора”; 
- “Ментор”, відвідуючи сторінку для реагування на запити рецензій 
(mentor’s account) бачить запити “Клієнтів” на надання рецензій, за 
бажанням реагує на них, натиснувши кнопку “Надати рецензію”; 
- “Ментор” перенаправляється системою на сторінку для консультації (chat 
page) і, ознайомившись з запитанням “Клієнта” та відповіддю “Юриста”, 
вводить у відведене для цього поле (textarea) текст власної рецензії;   
- якщо “Клієнт” прочитав відповідь і більше не має питань, він залишає 
сторінку для консультації (chat page) без додаткових дій, або, за бажанням, 
одним рухом ставить “Юристу” оцінку (від однієї до п’яти зірочок) а 
також, за бажанням, у тут же розміщеному для цієї мети текстовому полі 
(textarea) залишає відгук про роботу “Юриста” чи платформи в цілому. 
2.1.12. Підтримка (support) 
Важливим елементом стабільної роботи платформи є підтримка користувачів, 
юристів, менторів, організація процесу розв'язання скарг і проблем, а також 
моніторинг продуктивності системи. 
Ці питання є зоною відповідальності “Адміністратора”. Будь-який користувач 
платформи може написати лист на email “Адміністратора” зі своїм питанням. 
Питання технічного характеру вирішуються “Адміністратором” самостійно, інші 
питання передаються кураторам платформи.   
2.1.13. Моніторинг продуктивності 
Важливим етапом для забезпечення якості обслуговування та покращення 
ефективності роботи платформи є методи технічного моніторингу: 
Аналіз текстових чатів: Використання алгоритмів обробки природної мови 
для аналізу текстових даних. Це дозволяє визначити ключові слова, теми чи настрій 
клієнтів і юристів. Визначення популярних запитань або тем для подальшої 
оптимізації процесу консультацій. 
 47 
Вимірювання часу відповіді: Моніторинг часу, який займає відповідь юриста 
на запитання клієнта. Швидка відповідь може позитивно впливати на задоволення 
клієнтів. 
Оцінка якості відповідей: Використання систем оцінювання відгуків клієнтів. 
Це може допомогти виявити недоліки та сильні сторони в роботі юристів. 
Моніторинг активності користувачів: Слідкування за активністю 
користувачів на платформі, включаючи кількість запитань, час проведений на 
платформі, та інші метрики. 
Аналіз частоти та обсягу консультацій: Визначення періодів пікової 
активності та обсягу консультацій для вчасного адаптування ресурсів. 
Використання аналітичних інструментів: Застосування веб-аналітики для 
вимірювання трафіку, конверсій та інших метрик продуктивності платформи. 
Тестування користувацького досвіду: Здійснення тестувань з метою 
вдосконалення інтерфейсу та забезпечення зручності використання для обох сторін 
– клієнтів і юристів. 
Ці методи можна комбінувати для отримання повного зображення 
ефективності та якості обслуговування на нашій онлайн-платформі з консультаціями 
юристів у текстових чатах. 
2.1.14. Потенційні ризики та загрози 
Онлайн-платформи з консультаціями юристів у приватних текстових чатах 
стикаються з численними потенційними ризиками, які стосуються безпеки, 
стабільності та приватності даних.  
Деякі з основних ризиків та стратегії управління ними включають: 
1 Безпека даних 
Ризик: Можливість несанкціонованого доступу до конфіденційних даних 
клієнтів та юристів. 
Стратегія управління ризиком: Застосування сучасних методів шифрування 
для захисту конфіденційної інформації. Регулярне оновлення заходів безпеки та 
аудит систем на предмет потенційних загроз. 
 48 
2 Стабільність системи: 
Ризик: Відмова системи або технічні проблеми можуть призвести до втрати 
доступу до інформації та порушити нормальний робочий процес. 
Стратегія управління ризиком: Проведення регулярних тестів на 
масштабування та витривалість системи. Розгортання систем з резервними 
серверами для забезпечення неперервності роботи. 
3 Приватність даних: 
Ризик: Можливість неправомірного використання особистих даних 
користувачів або їхнє розголошення. 
Стратегія управління ризиком: Розробка та впровадження політик 
конфіденційності та застосування механізмів для забезпечення дотримання цих 
політик. Освіта користувачів щодо безпеки та конфіденційності. 
4 Регулювання та відповідність: 
Ризик: Невідповідність з законодавством та регулюваннями, пов'язаними з 
захистом даних. 
Стратегія управління ризиком: Активне вивчення та дотримання відповідних 
законодавчих та регуляторних вимог. Залучення юридичних консультантів для 
оцінки відповідності та впровадження відповідних змін. 
5 Атаки з боку користувачів: 
Ризик: Можливість виникнення атак, таких як фішинг або атаки з 
використанням шкідливих програм. 
Стратегія управління ризиком: Проведення навчань з безпеки для персоналу 
та користувачів. Використання антивірусного програмного забезпечення та 
застосунків для виявлення та запобігання атакам. 
6 Втрата даних: 
Ризик: Можливість втрати даних через технічні або людські помилки. 
Стратегія управління ризиком: Регулярні резервні копії та використання 
систем відновлення даних для забезпечення можливості відновлення інформації в 
разі втрати. 
 49 
Здійснення комплексного підходу до безпеки, стабільності та приватності 
даних допоможе мінімізувати ризики та створити надійну та ефективну онлайн-
платформу для консультацій юристів. 
Отже, структурно-інформаційний аналіз допомагає краще усвідомити всі 
аспекти проєкту та відобразити їх в структурованій формі, що сприяє розумінню 
робочих процесів, взаємозв'язків і основних параметрів дослідження та проєкту в 
цілому. 
2.1.15. Пошук раціонального компромісу, як елемент системного підходу до 
дослідження 
Пошук раціонального компромісу у дослідженні і розробці онлайн-платформи 
для надання безоплатних юридичних консультацій може бути ключовим етапом в 
системному підході до проєкту, зокрема: 
Користувацький інтерфейс: Пріоритетом є компроміс між ефективністю та 
спрощенням користувацького інтерфейсу. Наприклад, забезпечення інтуїтивного та 
зручного інтерфейсу для користувачів, які можуть не мати юридичної освіти, є 
важливим. Одночасно, розробка інтерфейсу вимагає великих зусиль. Пошук балансу 
між зручністю та можливостями має постійно супроводжувати процес не тільки 
первинної розробки платформи, але й весь процес її діяльності. 
Безпека даних: Забезпечення конфіденційності даних користувачів і юристів 
має бути абсолютним. Але, при цьому, не можна перевантажувати систему занадто 
складними заходами безпеки. Вибір правильної технології шифрування та методів 
аутентифікації має бути раціональним компромісом. 
Ресурси та обладнання: Для розробки платформи достатньо базового 
обладнання у вигляді ноутбука чи стаціонарного персонального комп’ютера. Для 
роботи платформи також потрібен доступ до сервера і хостинга. Цілком достатньо 
поширених програмних ресурсів як от HTML5, CSS3 та JavaScript для повноцінної 
розробки клієнтської частини. Цим обладнанням та ресурсами досягається 
оптимальний компроміс між витратами та можливостями.  
 50 
Здатність до масштабування: Забезпечення масштабованості платформи, є 
завданням на найближче майбутнє, але не варто займатися надмірним розширенням, 
яке може вимагати додаткових ресурсів та витрат. Якщо кількість користувачів 
платформи зросте, раціональним компроміс може стати майбутнє масштабування. 
Зокрема, буде доцільним перехід від моноліту до мікро сервісів.  
Часові рамки: Строки розробки та впровадження платформи мають бути 
реалістичними. В нашому випадку, розробка клієнтської частини тривала близько 
трьох місяців. У випадку майбутнього масштабування, потрібно також реалістично 
підійти до планування строків готовності того чи іншого технічного рішення. 
Важливим чинником є баланс між швидкістю впровадження та якістю розробки. 
Залучення користувачів і юристів: залучення молодих юристів без досвіду 
доцільно розпочати з передачі інформації про нашу платформу усім юридичним 
навчальним закладам України, здійснення періодичних публікацій в на публічних 
соціальних майданчиках, що також має привернути увагу користувачів. 
Розвиток платформи вимагатиме включення маркетолога у команду кураторів 
платформи. 
Отже, раціональний компроміс полягає у знаходженні оптимальних рішень 
для всіх аспектів нашого проекту, які допоможуть досягти поставлених цілей без 
перевантаження ресурсами та забезпечити ефективність та задоволеність 
користувачів. 
2.1.16. Розкриття невизначеностей, як елемент системного підходу до 
дослідження 
Розкриття невизначеностей у дослідженні і розробці онлайн-платформи для 
надання безоплатних юридичних консультацій може включати в себе виявлення і 
пояснення невизначеностей, які виникають при розробці та впровадженні проєкту, 
зокрема: 
Вибір технологій: Невизначеність може виникнути щодо вибору конкретних 
технологій та інструментів для розробки клієнтської частини платформи. В нашому 
 51 
випадку обрано HTML5 та CSS3, як оптимальні для цієї задачі і максимально 
поширені інструменти. Складно обрати для цього щось інше з очевидних причин. 
Правові аспекти: Невизначеність може виникнути щодо правових аспектів, 
зокрема, щодо відповідності проєкту законодавству та захисту конфіденційної 
інформації.  
В нашому випадку діяльність проєкту у повній мірі відповідає діючому 
законодавству, є соціальним проєктом, неприбутковою волонтерською діяльністю. 
Кожен юрист ознайомлений та зобов’язаний дотримуватись правил адвокатської 
етики. Захист конфіденційної інформації є невід’ємною частиною проєкту. 
Здатність до масштабування: Невизначеність може виникнути щодо того, 
яким чином платформа буде масштабуватися зі зростанням користувацької бази. 
В нашому випадку масштабування доцільно проводити шляхом переходу від 
моноліту до мікро сервісів. Також може бути доцільним перехід на хмарні 
технології. 
Функціональність платформи: Невизначеність може виникнути стосовно 
обсягу функціональності, яка має бути доступна на платформі.  
В нашому випадку, усім користувачам платформи будуть доступні конкретно 
описані та ретельно реалізовані функції платформи, які в поєднанні й утворюють 
стабільно й ефективно працюючу систему.  
В майбутньому планується додавання нового функціоналу, який з очевидних 
причин стане необхідних в процесі експлуатації платформи. 
Безпека та конфіденційність: Невизначеність може виникнути стосовно 
засобів забезпечення безпеки та конфіденційності даних користувачів.  
В нашому випадку приватність і конфіденційність є психологічною основою 
роботи системи, джерелом ментального спокою користувачів, які мають бути 
впевнені, що не лише зміст їх розмов з юристами є юридичною таємницею, але і сам 
факт звернення на платформу також не підлягає розголосу за жодних умов.   
 52 
Таким чином, розкриття невизначеностей допомагає нам пояснити та 
обґрунтувати ключові аспекти нашого проекту і розробити плани для їх вирішення. 
Це важливий крок у системному підході до дослідження та розробки будь-якої 
подібної платформи. 
2.1.17. Дослідження багатофакторності ризиків, як елемент системного 
підходу до дослідження 
Дослідження багатофакторності ризиків в системному підході до створення 
онлайн-платформи для надання юридичних консультацій включає в себе вивчення 
різних аспектів та факторів, які можуть вплинути на успішність проекту, зокрема: 
Технічні ризики: Забезпечення безпеки та стійкостісті системи є пріоритетом в 
роботі “Адміністратора”.  
Серед можливих технічних проблем, поширеним є перенавантаження 
серверів, можливість атак на систему, вразливості безпеки тощо.  
Ефективними способами захисту є: використання шифрування для захисту 
конфіденційної інформації під час передачі даних між користувачами та серверами; 
TLS/SSL протоколи можуть бути використані для захисту комунікації; є доцільним 
використання принципу найменших прав доступу (least privilege) для обмеження 
доступу до конфіденційної інформації; є доцільним встановлення систем, які можуть 
виявляти та запобігати вторгненням в систему, що може включати в себе системи 
моніторингу журналів та виявлення аномалій; є доцільним проведення регулярних 
аудитів системи для виявлення слабких місць та потенційних загроз; аудити можуть 
включати в себе перевірку конфігурації системи, виявлення вразливостей та 
перевірку стандартів безпеки; є доцільним регулярно створювати резервні копії 
(backups) важливих даних і перевіряти їх на можливість відновлення - це допоможе 
у випадку втрати даних через технічні або людські помилки. 
 53 
Правові ризики: До правових ризиків може відноситись періодична неякісна 
правова допомога, викликана недостатньою мотивованістю чи рівнем підготовки 
консультантів. Разом з тим, кожен клієнт перед використанням функціоналу 
платформи в обов’язковому порядку повинен ознайомитись та прийняти правила 
платформи, в яких, серед іншого, окремо наголошено щодо ризику отримання 
неповної чи неякісної консультації, що пов’язане саме з відсутністю чи 
недостатністю практичного досвіду консультанта; правилами пропонується клієнту 
усвідомити цей ризик, прийняти його та не мати жодних правових претензій до 
якості консультування; взаємодіяти на платформі за принципом “візьми тут 
найкраще з можливого”. 
Фінансові ризики: До головного фінансового ризику відноситься скінченність 
ресурсів, що підтримують роботу платформи. Крім того, ризиком є циклічний 
наплив та відплив якісного складу менторів чи когось з команди кураторів 
платформи. Все це має негативний вплив на стійкість платформи та можливість 
продовження її функціонування.  Задачею маркетингу є уникнення мінімізація чи 
повне уникнення від впливу таких ризиків.  
Маркетингові ризики: Привернення уваги користувачів є маркетинговим 
ризиком, адже недостатньо мати повний штат консультантів якщо їм немає кого 
консультувати. Тут багато залежить від активності маркетингу та застосовуваних 
методів просування. Разом з тим, найціннішим активом всього проєкту є довіра 
людей, які вже скористались функціоналом платформи та повернулись знову або й 
привели нових відвідувачів. Збереження довіри передбачає кропітку щоденну 
роботу над якістю роботи платформи та кожного її учасника.   
Соціальні ризики: Серед соціальних ризиків є створення негативного образу 
платформи, що може ширитись в суспільстві внаслідок негативних відгуків або 
цілеспрямованих інформаційних атак. Боротись з цим явищем можна виключно 
 54 
двома головними способами: продовжувати якісно роботи свою справу та бути 
постійно присутніми в інфопросторі. 
Вплив роботи платформи на суспільство може бути виключно позитивним, 
адже зробити гіршим стан правової свідомості, щоденно консультуючи людей, 
практично неможливо; в той же час, будь-який незначний приріст правосвідомості 
окремих груп суспільства в цілому збільшує рівень цього соціального явища в 
суспільстві.  
Вивчення цих факторів допоможе розробити стратегію управління ризиками 
та зменшити невизначеність, пов'язану з нашим проектом. 
2.1.18 Теорія та гіпотеза дослідження 
2.1.18.1 Теорія дослідження: 
Онлайн-платформа для надання безоплатних юридичних консультацій 
розробляється з використанням сучасних методів програмування та підходів до 
створення інформаційних систем. Зосереджуючись на впровадженні технологій, 
мета полягає в покращенні якості та доступності юридичних послуг для населення. 
2.1.18.2 Гіпотеза дослідження: 
- Експериментальна гіпотеза 
"Інтеграція системи перевірки роботи молодих юристів на основі 
програмування в онлайн-платформу для безоплатних юридичних консультацій 
сприятиме підвищенню якості консультацій та ефективності юридичного 
обслуговування, забезпечуючи шлях до подальшого розвитку інформаційної 
системи." 
- Предметне визначення понять 
Інтеграція системи перевірки. Впровадження програмних модулів та функцій 
для систематичної перевірки та оцінки роботи молодих юристів на платформі. 
 55 
Програмування в інформаційній системі. Використання сучасних мов 
програмування та практик для розробки функціональності, що забезпечує взаємодію 
користувачів та забезпечує виконання бізнес-логіки. 
Підвищення якості консультацій. Забезпечення користувачам високоякісних 
та достовірних юридичних консультацій за допомогою інтеграції перевірки та 
вдосконалення програмного коду. 
Ефективність юридичного обслуговування. Здатність системи швидко та 
ефективно надавати юридичні консультації, реагуючи на потреби користувачів. 
Розвиток інформаційної системи. Можливість постійного вдосконалення та 
розширення функціоналу онлайн-платформи відповідно до вимог користувачів та 
ринкових тенденцій. 
2.2. Експериментальні дослідження 
Принципи дії і характеристики розробленої дослідницької програмної системи 
 Для наочного демонстрування принципу дії розробленої дослідницької 
програмної системи доцільно відобразити графічно елементи моделі, які в цьому 
варіанті представлення є окремими функціональними сторінками, такими як: 
- головна сторінка (main page);  
- сторінка меню (menu page); 
- сторінка тем, що перебувають на обговоренні (topics page);  
- сторінка з переліком юристів (lawyers page); 
- сторінка з переліком менторів (mentors page);  
- сторінки відгуків (reviews page); 
- сторінки з інформацією для роботодавця (employer page);  
- сторінки авторизації юристів і менторів (authorize page); 
- сторінка особистого кабінету “Ментора” (mentor’s account); 
- сторінка особистого кабінету “Юриста” (lawyer’s account); 
 56 
- сторінка особистого кабінету “Клієнта” (user’s account); 
- сторінка приватного чату між “Клієнтом” та “Юристом”, “Ментором” (chat 
page). 
Сторінки почергово показані на Рис.2.9.-2.14. нижче. 
 
Рисунок 2.9. — Сторінки “main page” та “menu page” 
 
 57 
 
Рисунок 2.10. — Сторінки “lawyers page” та “topics page” 
 
 58 
 
Рисунок 2.11. — Сторінки “reviews  page” та “mentors page” 
 
 59 
 
Рисунок 2.12. — Сторінки “authoriz  page” та “employer page” 
 60 
 
Рисунок 2.13. — Сторінки “lawyer’s account” та “mentor’s account” 
 61 
 
 
Рисунок 2.14. — Сторінки “lawyer’s account” та “mentor’s account” 
 
Вище були деталізовано показані сторінки платформи з їх змістом. На них 
видно фрагменти зв’язків, які потребують розкриття. Тому, на Рис.2.15 показана 
загальне структурне поєднання цих сторінок та спосіб їх взаємодії. 
 62 
 
Рисунок 2.15. — Загальне структурне поєднання сторінок та спосіб їх взаємодії 
 63 
2.2.1. Опис елементів 
Розглянемо структуру та взаємозв'язки між різними частинами клієнтської 
частини нашого програмного продукту.  
Головна сторінка (main page): має загальний опис-презентацію призначення 
нашої платформи, значок маскота, значок меню, форму для відправки email клієнта, 
яка призначена для створення і відправки на цей email посилання на вхід в 
клієнтський акаунт. 
Сторінка меню (menu page): тут доступні такі елементи меню, як: 
- сторінка тем, що перебувають на обговоренні (topics page);  
- сторінка з переліком юристів (lawyers page); 
- сторінка з переліком менторів (mentors page);  
- сторінки відгуків (reviews page); 
- сторінки з інформацією для роботодавця (employer page);  
- сторінки авторизації юристів і менторів (authorize page). 
Кожне з посилань у меню веде до своєї сторінки. 
Зокрема, сторінка тем, що перебувають на обговоренні (topics page), містить: 
- дату і час створення теми; 
- назву теми; 
- дані юриста, який дав відповідь. 
Сторінка з переліком юристів (lawyers page) містить такі дані: 
- ім’я та прізвище юриста; 
- його внутрішній системний id-ідентифікатор для легкого пошуку; 
- рейтинг на платформі; 
- кількість наданих консультацій; 
 64 
- галузі права, в яких він консультує. 
Сторінка з переліком менторів (mentors page) містить такі дані: 
- ім’я та прізвище ментора; 
- кількість наданих рецензій; 
- галузі права, в яких він надає рецензії. 
Сторінка відгуків (reviews page) містить такі дані: 
- текст відгуку; 
- хто з юристів надавав консультацію по темі з відгуком. 
Сторінка з інформацією для роботодавця (employer page) містить такі дані: 
- інструкція для роботодавця, як відбирати юристів для власних співбесід за 
допомогою фільтра за певними критеріями. 
Сторінка авторизації юристів і менторів (authorize page) вміщує: 
- форма для введення email для раніше зареєстрованих юристів і менторів; 
- форма з багатьма inputs для введення особистих даних, що підлягають 
перевірці перед допуском юриста чи ментора для роботи на платформі; 
- після перевірки даних, юрист чи ментор отримує через email посилання на 
особистий кабінет (lawyer’s account чи mentor’s account). 
Сторінка особистого кабінету “Клієнта” (user’s account) вміщує:  
- посилання на правила платформи з обов’язковим check-box 
підтвердженням про ознайомлення та прийняття; 
- форму для введення теми а також самого питання в розгорнутому вигляді 
(кількість символів обмедена до 400); 
- архів раніше заданих цим клієнтом питань; 
- з готовим питанням клієнт перенаправляється в чат (chat page). 
 65 
Сторінка особистого кабінету “Юриста” (lawyer’s account) вміщує:  
- перелік нових питань, їх час і дата 
- перелік особистих питань, заданих саме цьому юристу 
- функціонал генерування сертифікату платформи про досвід юриста 
(відколи консультує, особистий рейтинг, кількість консультацій, галузі 
права); 
- кнопка “Відповісти на питання” перенаправляє юриста  в чат (chat page). 
Сторінка особистого кабінету “Ментора” (mentor’s account) вміщує:  
- перелік нових запитів на рецензію, їх час і дата; 
- функціонал генерування сертифікату платформи про досвід ментора 
(відколи надає рецензії, кількість наданих рецензій, галузі права); 
- кнопка “Надати рецензію” перенаправляє ментора  в чат (chat page). 
Сторінка приватного чату між “Клієнтом” та “Юристом”, “Ментором” (chat 
page) вміщує:  
- тему і суть заданого питання 
- дані клієнта: email 
- дані юриста: прізвище, ім’я, внутрішній id; 
- текстове поле для відповіді юриста 
- текстове поле для рецензії ментора 
- кнопки для клієнта: запитати ще, отримати рецензію, завершити чат, 
залишити відгук (textarea), поставити оцінку (зірочки); 
- текстове поле для додаткового питання 
- кнопки для юриста: відповісти ще, консультація надана; 
- текстове поле для додаткової відповіді. 
 66 
2.2.2. Імітаційний метод 
Використовуючи імітаційний метод, на стадії розробки клієнтської частини 
платформи мною створене симуляційне середовище, де стало можливим імітувати 
роботу різних частин платформи та спостерігати, як умовний користувач взаємодіє 
з різними функціями (див.Рис. 2.16. нижче). 
Застосування імітаційних методів дозволяє експериментувати з різними 
варіантами перед тим, як запускати платформу в реальному середовищі, тим самим 
зменшуючи ризики та забезпечуючи більш якісний продукт. 
Зокрема, описані вище елементи платформи були реалізовані засобами 
HTML5 та CSS3 після чого файли проєкту завантажені на хостинг місцевого 
провайдера та з застосуванням тестового доменного імені http://test.pravo.ck.ua. 
 
 
 67 
Рисунок 2.16. — Імітація платформи засобами HTML5 та CSS3 
  
Різноманітне використання елементів сторінок в ролі “Відвідувача”, 
“Клієнта”, “Юриста”, “Ментора” неодмінно показувало отримання бажаного 
результату. Так “Відвідувач” вільно переміщувався між розділами меню, маючи 
можливість бачити всю доступну для нього інформацію сторінок. Особливо 
корисним було використання фільтру для обрання юриста за заздалегідь потрібними 
вимогами. В свою чергу, бажання задати питання неодмінно вимагало заповнення 
форми з email, в цей момент імітується взаємодія з поштовою скринькою “Клієнта”  
і перенаправлення в приватний акаунт останнього. Також, перевірена взаємодія з 
платформою “Юриста” і “Ментора”. Кожному з них потрібно було зайти на сторінку 
меню, звідки перейти на сторінку авторизації. Тут у кожного з них було два варіанти: 
якщо це не перше відвідування, актор вводив свій email, в цей момент імітується 
взаємодія з поштовою скринькою “Юриста/Ментора”  і перенаправлення в 
приватний акаунт останнього. Далі в особистому акаунті “Юрист” обирає одне з 
запитань і погоджується надати відповідь натисканням відповідної кнопки, що 
перенаправляє його в приватний чат з “Клієнтом”. У разі, коли відвідування 
платформи для “Юриста/Ментора” було першим, він успішно заповнював 
реєстраційну форму. Рецензія “Ментора” з особистого акаунту також виконується 
без помилок.  
Таким чином, імітаційний метод є корисним інструментом у перевірці 
функціоналу реалізованого програмного засобу.     
2.2.3. Оцінка ефективності системи 
 Оцінка ефективності системи - це процес визначення, наскільки добре система 
відповідає своїм завданням та досягає поставлених цілей. У нашому випадку, 
розглядаючи онлайн-платформу для юридичних консультацій, оцінка ефективності 
може включати в себе ряд аспектів. 
Інформаційна складова: 
 68 
Важливим показником є якість інформації, яку надає платформа 
користувачам. Найпростішим способом оцінити ефективність системи за цим 
показником, це зібрати якомога більше відгуків на самій платформі а також на 
сторонних ресурсах, які спеціалізуються на розміщення відгуків. Також про якість 
сервісу свідчить рейтинг як кожного окремо взятого юриста, такі і середній рейтинг 
юристів на платформі. 
Ще одним важливим показником є зручність використання та доступність 
інформації для кожної категорії користувачів. Імітація використання виявила 
достатній рівень зручності для будь-якого з акторів. Разом з тим, в ході фактичної 
експлуатації системи ми зможемо краще підлаштувати її під вимоги користувачів.  
Середовище: 
Адаптабельність системи до різних середовищ та пристосування до різних 
умов використання також є важливим чинником для оцінки. В нашому випадку 
засобами CSS3 забезпечено адаптивну верстку сторінок, що дозволяє одноково 
зручно користуватись платформою як з ноутбука чи стаціонарного комп’ютера, так 
і з телефона чи планшета. Технології FLEX та GRID забезпечують таку можливість. 
Фактори прямої та непрямої дії: 
Прямий вплив визначає те, як користувачі взаємодіють із системою та як це 
впливає на їхні потреби. Імітуючи роботу системи ми бачили досить зручне 
використання платформи користувачем. При цьому, головна потреба відвідувача є 
задоволеною, якщо він задав питання і отримав на нього відповідь, яка не 
потребувала додаткового запитання чи рецензії ментора. Разом з тим, задоволення 
потреби у додатковій відповіді чи рецензії також вказує на досягнення бажаного 
результату.  
Непрямий вплив визначає те, як платформа впливає на покращення роботи 
юристів та менторів. В даному випадку, головною метою юриста є акумулювання 
досвіду на практичних ситуаціях з реальними людьми. Він отримує цей досвід та 
може в будь-який момент підтвердити його генеруванням сертифікату платформи, 
дійсність його підтверджується належним чином. Ментор також реалізує свою 
 69 
головну мету, надаючи рецензії, реалізуючи свою потребу наставництва та маючи 
можливість також підтвердити це сертифікатом платформи. 
Ефективність рішень: 
Оцінка того, наскільки швидко та ефективно система вирішує питання 
користувачів є важливою частиною загальної оцінки ефективності системи. Імітація 
діяльності платформи показала, що задати питання не складно, адже форма 
пропонує прості і зрозумілі інструкції. В свою чергу, якщо юрист володіє знаннями 
для надання певної консультації, йому не потрібно багато часу для заповнення 
форми відповіді. Тож, в цілому, питання користувачів мають вирішуватись досить 
швидко. Разом з тим, виключно з плином часу та наповненням бази даних 
платформи даними про реальні консультації, ми зможемо предметно оцінити 
швидкість цього сервісу з точки зору користувача.  
Взаємодія користувачів: 
Важливою також є оцінка того, наскільки платформа сприяє взаємодії між 
юристами, менторами та користувачами. Проста система взаємодії сприяє швидкому 
і зрозумілому спілкуванню цих акторів між собою посередництвом текстового 
приватного чату. Крім того, запуском платформи ми сприяємо створенню окремої 
спільноти молодих правників, які отримали свій перший досвід саме на нашій 
платформі і зможуть надалі ділитись цим досвідом з іншими колегами, пробувати 
себе в якості наставників у нашій системі. 
Забезпечення конфіденційності та безпеки: 
Рівень захисту конфіденційності інформації користувачів та безпеки 
транзакцій та обміну даними на платформі є достатнім для збереження юридичної 
таємниці та персональних даних. Одним з рішень, що значно спрощують процедуру 
авторизації на нашій платформі є використання email актора, як універсальний 
спосіб доступу до функціоналу платформи. Жодному актору не потрібний окремий 
пароль для входу, його email вже має пароль, доступ до такого email є лише у 
конкретної особи, вхід реалізовано через отримання посилання на поштову 
скриньку, що забезпечує надійну авторизацію. 
 70 
Оцінка ефективності може включати в себе як кількісні, так і якісні показники, 
такі як час відповіді, рівень задоволення користувачів, кількість успішних 
консультацій і т.д. Для проведення цієї оцінки можна використовувати анкети, 
аналіз даних використання, тестування користувачів та інші методи,. що можливо 
вже під час реального використання платформи на практиці. 
2.2.4. Результати власних досліджень автора 
 Одним з ключових зовніших досліджень у цій роботі для автора був аналіз 
наявних в даний час в Україні сервісів, подібних до задуманого у нашому проєкті. 
Сервісів з аналогічним функціоналом в Україні немає. Ті сервіси, що також 
пропонують безкоштовні консультації, не мають того рівня приватності і 
збереження юридичної таємниці, який доступний на нашій платформі, а також 
жоден з інших сервісів не має інституту наставництва, що якісно відрізняє нашу 
інформаційну систему від всіх інших. 
 Результатом власних досліджень автора стало розуміння того, чого саме не 
вистачає вже існуючим системам та як зробити нову конкурентноздатну систему. 
 Власний новий внесок автора у вирішення проблеми якісного безоплатного 
консультування полягає у використанні загальнопоширених засобів інженерії 
програмного забезпечення для створення інформаційної системи, що вирішує задачу 
непоширеним новим способом. Серед іншого, це стало можливим завдяки 
особистому досвіду роботи в юриспруденції. Врешті, одночасне використання 
практичних навичок з двох різних галузей людської діяльності може призводити до 
створення якісно нових рішень. 
 
 
 
 
  
 71 
3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ 
3.1. Моделювання предметної області 
Для моделювання предметної області та виконуючи проектування 
інформаційної системи у цій роботі використана мова UML (Unified Modeling 
Language). Програмний комплекс Rational Rose дозволяє виконати цю роботу. 
Загальні відомості про Rational Rose: 
Моделювання UML: Rational Rose надає засоби для створення моделей 
програмного забезпечення з використанням мови UML (Unified Modeling Language). 
Це дозволяє розробникам створювати діаграми класів, діаграми послідовності, 
діаграми взаємодії та інші UML-діаграми для розробки та аналізу програмного 
забезпечення. 
Генерація коду: Rational Rose може генерувати початковий код програмного 
забезпечення на основі моделей UML. Це допомагає зменшити ризик помилок при 
ручній реалізації коду. 
Аналіз та тестування: Програма допомагає аналізувати та тестувати моделі 
програмного забезпечення, що дозволяє виявляти можливі проблеми та помилки на 
ранніх стадіях розробки. 
Підтримка командної роботи: Rational Rose підтримує спільну роботу 
декількох розробників, дозволяючи їм спільно працювати над моделями 
програмного забезпечення та обмінюватися даними. 
Документування: Програма дозволяє генерувати документацію на основі 
моделей, включаючи опис класів, методів, атрибутів та інших елементів 
програмного забезпечення. 
Підтримка різних мов програмування: Rational Rose підтримує генерацію 
коду для різних мов програмування, включаючи C++, Java, C#, і багато інших. 
 72 
Інтеграція з іншими інструментами: Rational Rose може інтегруватися з 
іншими інструментами розробки програмного забезпечення, такими як середовища 
розробки IDE (Integrated Development Environments) і системи керування версіями. 
Rational Rose була однією з популярних програм для моделювання 
програмного забезпечення, але вона може бути застарілою в деяких аспектах, 
оскільки ринок розробки програмного забезпечення постійно розвивається, і 
існують сучасні альтернативи для моделювання, такі як Enterprise Architect, Visual 
Paradigm і деякі інші. 
3.1.1. Предметна область моделювання: 
Система інженерії програмного забезпечення, яка розробляється, має на меті 
створення онлайн-платформи для безоплатних юридичних консультацій. Ця 
предметна область визначається рядом основних компонентів та взаємодій між 
ними. Молоді юристи, або користувачі, є основними учасниками системи та мають 
ряд визначених функціональностей: 
Автентифікація та Реєстрація. Автентифікація: Користувачі проходять 
процедуру автентифікації для доступу до своїх облікових записів. 
Реєстрація. Нові користувачі реєструються, надаючи необхідні дані та 
обираючи свої основні області інтересів у юридичній сфері. 
Профіль Користувача: Кожен молодий юрист має свій профіль, де 
відображається основна інформація, така як фахові навички, рейтинг та інші важливі 
параметри. 
Роль Наставників: Наставники виступають у ролі експертів, які надають 
допомогу та контролюють якість наданих консультацій: 
Перевірка Консультацій: Наставники мають можливість переглядати та 
оцінювати надані консультації молодих юристів. 
Система автоматично визначає звітні періоди для перевірки та взаємодії з 
юристами. 
Консультації та Взаємодія: Основна діяльність системи полягає в наданні 
юридичних консультацій та ефективній комунікації між учасниками: 
 73 
Створення та Пошук Консультацій: Молоді юристи можуть ініціювати 
консультації, додаючи їх до системи, та користувачі можуть шукати відповідні 
консультації за темою. 
Чат та Система Зворотного Зв'язку: Юристи та користувачі можуть 
взаємодіяти через вбудований чат для обговорення консультацій та отримання 
додаткових пояснень. 
Система збирає відгуки від користувачів та наставників для підвищення якості 
обслуговування. 
Цей опис предметної області є основою для подальшого розроблення системи 
та забезпечення її ефективного функціонування відповідно до вимог та очікувань 
користувачів. 
3.1.2. Модель предметної області: 
Модель предметної області для розроблюваної системи інженерії програмного 
забезпечення визначає структуру та компоненти, що становлять основу 
функціонування платформи для безоплатних юридичних консультацій. 
Основні сутності: 
Користувач (User): Включає молодих юристів, які надають консультації, і 
звичайних користувачів, які шукають юридичну допомогу. 
Має особистий профіль, де зберігається основна інформація та історія 
консультацій. 
Наставник (Mentor): Досвідчені юристи, які відгукуються на консультації 
молодих юристів. 
Мають можливість переглядати, оцінювати та надавати відгуки на 
консультації. 
Консультація (Consultation): Представляє собою окремий запис, який містить 
інформацію про консультацію, таку як тема, текст консультації, статус та інші 
атрибути. 
Взаємодії: 
 74 
Створення Консультації: Користувачі можуть ініціювати нові консультації, 
додаючи відповідні дані та опис теми. 
Перевірка Консультацій: Наставники мають можливість переглядати та 
оцінювати консультації молодих юристів, надаючи конструктивний фідбек. 
Чат та Взаємодія: Система надає можливість користувачам та наставникам 
спілкуватися через вбудований чат, обговорюючи деталі консультацій та надаючи 
додаткові пояснення. 
Оцінювання та Відгуки: Користувачі та наставники мають можливість 
оцінювати якість консультацій та залишати відгуки для покращення процесу 
надання юридичних порад. 
Робочий процес: Користувач реєструється та створює профіль, вказуючи свої 
основні дані та області інтересів. 
Молодий юрист ініціює консультацію, додаючи необхідні деталі та 
отримуючи доступ до системи чату. 
Наставник переглядає консультації, надає конструктивний фідбек та взаємодіє 
з юристами через чат. 
Користувач отримує поради, спілкуючись з наставниками та іншими 
користувачами. 
Ця модель предметної області надає відомості про основні аспекти системи та 
визначає ключові елементи, які будуть враховані при подальшій розробці та 
реалізації інформаційної платформи. 
3.1.3. Словник предметної області 
Терміни, використовувані у системі: 
Користувач (User): Особа, яка має доступ до системи, включаючи молодих 
юристів і звичайних користувачів, що шукають консультації. 
Молодий юрист (Young Lawyer): Користувач, який знаходиться на етапі 
початкового професійного розвитку та має можливість надавати юридичні 
консультації на платформі. 
 75 
Наставник (Mentor): Досвідчений юрист, який надає оцінку та конструктивний 
фідбек молодим юристам, а також контролює якість наданих консультацій. 
Консультація (Consultation): Окремий запис, який містить інформацію про 
юридичну пораду, включаючи тему, опис та статус консультації. 
Чат (Chat): Засіб комунікації на платформі, який дозволяє користувачам та 
наставникам спілкуватися для обговорення консультацій та інших питань. 
Реєстрація (Registration): Процес створення облікового запису користувача в 
системі, включаючи введення основних даних та налаштувань. 
Оцінювання (Rating): Система, що визначає якість консультацій та репутацію 
молодих юристів на основі отриманих відгуків та оцінок. 
3.1.4. Елементи моделювання предметної області 
Модель предметної області системи для платформи безоплатних юридичних 
консультацій включає в себе ряд ключових елементів, які визначають її структуру та 
функціональність. 
Елементи інтерфейсу користувача: 
Домашня сторінка (Home Page): Головна сторінка платформи, на якій 
користувачі можуть переглядати актуальні консультації та отримувати загальну 
інформацію. 
Профіль користувача (User Profile): Особистий кабінет користувача, де 
відображається основна інформація та історія консультацій. 
Сторінка консультації (Consultation Page): Сторінка, де користувач може 
переглядати та ініціювати нові консультації. 
Чат (Chat Interface): Інтерфейс для обговорення консультацій між 
користувачами та наставниками. 
Системні компоненти. Модуль Аутентифікації (Authentication Module): 
Відповідає за перевірку ідентичності користувачів під час входу в систему. 
Модуль Реєстрації (Registration Module): Управляє процесом створення нових 
облікових записів користувачів. 
 76 
Модуль Консультацій (Consultation Module): Включає логіку для створення та 
обробки консультацій, а також взаємодії між користувачами та наставниками. 
Модуль Чату (Chat Module): Забезпечує функціонал для спілкування 
користувачів та наставників у режимі реального часу. 
Сутності бази даних:  
Таблиця Користувачів (Users Table): Зберігає інформацію про всіх 
користувачів системи, включаючи молодих юристів та наставників. 
Таблиця Консультацій (Consultations Table): Містить дані про всі консультації, 
їхній статус та відповідність користувачам. 
Таблиця Оцінок (Ratings Table): Записує дані про оцінки та відгуки, які 
надають користувачі та наставники. 
Таблиця Чату (Chat Table): Зберігає повідомлення та іншу інформацію, яка 
виникає під час спілкування в чаті. 
3.1.5. Робоча область моделювання 
Як приклад робочої області моделювання розглянемо онлайн-платформу, де 
молоді юристи набувають досвід, надаючи юридичні консультації населенню. 
Роботу юристів може перевіряти наставник, який також є користувачем системи.   
3.2. Формування вимог до програмного забезпечення 
Програмне забезпечення має бути реалізоване таким чином, щоб забезпечити 
комп'ютерно-опосередковану комунікацію між юристом та клієнтом, що дозволяє 
задовольнити потребу клієнта у отриманні правової інформації та потребу юриста 
вдосконалити власний досвід. Також програма має бути здатною забезпечити 
залучення досвідчених правників, як третьої сторони комунікації, які на правах 
ментора-наставника можуть коригувати надані консультації. Система повинна 
забезпечувати приватність всіх розмов, бути стійкою до стороннього проникнення 
неавторизованих користувачів до внутрішнього функціоналу системи. 
Формулювання вимог до програмного забезпечення є критичним етапом у 
 77 
розробці платформи для безоплатних юридичних консультацій. На даному етапі 
визначаються як первинні, так і детальні вимоги, які враховують потреби як 
замовника, так і розробника. 
Первинні вимоги 
3.2.1. Вимоги замовника: 
- доступність: система повинна бути доступною для всіх користувачів з 
різних пристроїв та платформ. 
- безпека даних: забезпечення конфіденційності та інтегрована система 
безпеки для захисту особистої інформації користувачів. 
- зручний інтерфейс: створення інтуїтивно зрозумілого і зручного 
інтерфейсу для користувачів та наставників. 
- оцінювання та відгуки: введення системи оцінювання та збору відгуків для 
оцінки якості консультацій та підвищення репутації юристів. 
3.2.2 Вимоги розробника: 
- технічни стек: використання сучасних технологій та інструментів для 
розробки, таких як фреймворки, мови програмування і системи управління 
базами даних. 
- масштабованість: розробка системи, яка легко масштабується для обробки 
зростаючого обсягу консультацій та користувачів. 
- API для інтеграції: надання API для інтеграції з іншими юридичними 
системами та додатками. 
3.2.3. Детальні вимоги:  
3.2.3.1. Функціональні вимоги: 
- реєстрація та автентифікація: система повинна дозволяти користувачам 
реєструватися та автентифікуватися безпечно та швидко. 
- створення та пошук консультацій: молоді юристи повинні мати можливість 
ініціювати нові консультації, а користувачі - шукати відповідні 
консультації за темою. 
 78 
- чат та взаємодія: надання зручного чату для обговорення консультацій та 
взаємодії між користувачами та наставниками. 
3.2.3.2. Нефункціональні вимоги: 
- продуктивність: система повинна забезпечувати ефективний обмін даними 
та бути відзначеною низьким часом відповіді. 
- масштабованість та Витривалість: забезпечення стійкості та 
продуктивності системи при зростанні кількості користувачів та 
консультацій. 
- безпека: захист особистої інформації користувачів та дотримання 
найвищих стандартів безпеки. 
Ці вимоги формулюються з урахуванням потреб користувачів та вимог, які 
ставляться до системи замовником та розробниками, забезпечуючи підставу для 
подальшого проектування та реалізації програмного забезпечення. 
3.3. Формування вимог за допомогою діаграми прецедентів 
Діаграма прецендентів (варіантів використання) являє собою граф 
спеціального виду, що є графічною нотацією для представлення конкретних 
варіантів використання, акторів, можливо деяких інтерфейсів, і відношень між цими 
елементами. 
Діаграма варіантів використання (або діаграма сценаріїв) - це один із видів 
UML (Unified Modeling Language) діаграм, який використовується для моделювання 
функціональності системи з точки зору користувача або зовнішніх акторів. Діаграми 
варіантів використання допомагають описати, як система взаємодіє з різними 
сценаріями взаємодії користувачів або інших систем. 
Основними елементами діаграми варіантів використання є: 
1 Актори. Актори - це ролі або сутності, які взаємодіють з системою. Це 
можуть бути користувачі, зовнішні системи або будь-які інші агенти, які 
взаємодіють з системою. 
 79 
2 Варіанти використання (сценарії). Варіанти використання - це конкретні 
сценарії або історії, які показують послідовність подій та взаємодію акторів з 
системою. Кожен варіант використання описує одну конкретну функціональність 
або функціональний вимір системи. 
3 Відносини між акторами і варіантами використання. Діаграма варіантів 
використання відображає, які актори беруть участь у кожному варіанті використання 
і як вони взаємодіють з системою. 
Ця діаграма допомагає команді розробників і зацікавленим сторонам краще 
зрозуміти, як система повинна працювати з точки зору користувача або інших 
акторів. Вона може використовуватися на різних етапах розробки програмного 
забезпечення, включаючи аналіз вимог, проектування системи та тестування. 
 
 
Рисунок 3.1. — Діаграми варіантів використання у пакеті “Використання 
Відвідувачем інформації на Платформі в своїх інтересах” 
 
Зручним способом відображення діаграм варіантів використання є об’єднання 
їх в пакети, як це показано на рисунку нижче, де можна побачити приклад пакету, 
 80 
який вміщує діаграму варіанту використання щодо використання сутністю 
“Відвідувач” інформації з розділу “Юристи” для вибору конкретного 
Юриста.  
Тут можемо побачити вкладеність в одну діаграму варіанту використання 
декількох (шести) інших діаграм варіантів використання, які позначені лініями 
відношення виду “include”(включає) та “dependency” (залежить).  
Зокрема, це означає, що діаграма варіанту використання “Кінцевий вибір 
Юриста” прямо залежить від результатів виконання діаграм варіантів використання 
де сутність “Відвідувач” відбирає Юристів з найвищим рейтингом, найбільшою 
кількістю наданих консультацій, потрібною спеціалізацією. Врешті, сутність 
отримує бажаний результат. 
3.4. Проектування логічної структури програмного комплексу 
3.4.1. Діаграми класів 
Діаграма класів в мові UML - це один із найбільш базових та потужних типів 
діаграм, який використовується для моделювання структури системи, опису класів, 
їх взаємозв'язків та атрибутів. Діаграма класів надає візуальне представлення 
структури системи та структури даних, що використовуються в системі. Ось загальні 
характеристики діаграм класів в мові UML: 
Класи (Classes): Основними елементами діаграми класів є класи, які 
представляють абстракції, об'єкти чи сутності, які мають спільні атрибути, методи 
та поведінку. Класи зображаються у діаграмі як прямокутники, де ім'я класу 
знаходиться в верхній частині прямокутника. 
Атрибути (Attributes): Атрибути представляють характеристики класу, такі 
як поля або змінні, які містять інформацію про клас. Атрибути зазвичай 
зображуються під іменем класу та мають тип даних. 
Методи (Methods): Методи описують поведінку класу та визначають, як клас 
взаємодіє з іншими об'єктами або змінює свій стан. Методи зазвичай зображаються 
під атрибутами та включають ім'я методу, параметри та тип повернення. 
 81 
Відношення (Relationships): Діаграма класів включає відношення між 
класами, які вказують на зв'язки між ними. Типи відношень включають асоціації, 
агрегації, композиції, узагальнення та реалізацію. Відношення допомагають 
визначити, як класи співпрацюють та взаємодіють один з одним. 
Узагальнення (Inheritance): Узагальнення використовується для визначення 
ієрархії класів, де один клас є загальним батьківським класом, а інші класи 
спеціалізують його. Узагальнення позначається лінією зі стрілкою від класу-
підкласу до класу-батька. 
Реалізація (Realization): Реалізація використовується для визначення 
виконання інтерфейсу. Клас реалізує інтерфейс, визначаючи всі методи, які 
необхідно впровадити. Реалізація позначається лінією зі стрілкою від класу до 
інтерфейсу. 
Асоціація (Association): Асоціація вказує на зв'язок між двома або більше 
класами, але не передбачає визначення, яким чином цей зв'язок виконується. 
Асоціація зазвичай позначається лінією між класами. 
Агрегація (Aggregation) та Композиція (Composition): Ці відношення 
вказують на відношення "частина-ціле" між класами. Агрегація показує, що один 
клас має інший клас як свою частину, але ця частина може існувати самостійно. 
Композиція вказує на те, що один клас є нерозривною частиною іншого класу і не 
може існувати окремо від нього. Агрегацію та композицію зазвичай позначаються 
лініями з ромбами або стрілками між класами. 
Контекстні меню (Context Menu): Діаграми класів мають контекстне меню, 
яке містить різні опції для редагування та додавання класів, атрибутів, методів і 
відношень до діаграми. 
Документація: Важливо включити адекватну документацію до діаграм 
класів, щоб пояснити призначення класів, їх атрибутів та методів, а також 
взаємозв'язки між ними. Документація допомагає іншим розробникам краще 
зрозуміти структуру системи та її функціональність. 
 82 
На рис.3.2. ми можемо побачити діаграму класів. Деякі з класів мають 
атрибути. Також тут можемо побачити асоціації, які є зв'язками між екземплярами 
класів. 
Суть діаграми, яку має зрозуміти розробник, полягає у зображенні двох 
акторів, показаних у формі класів, які є Клієнтом та Юристом.  
 
 
Рисунок 3.2. — Діаграма класів щодо взаємодії класу Юрист з класом Клієнт 
 
Щоб Клієнт мав можливість отримати від Юриста відповідь на своє питання, 
він має скористатись функціоналом Платформи і прийняти публічну оферту, вказати 
свій email, використати посилання, яке автоматично прийде йому на цей email, 
задати у спеціальній формі своє питання та отримати відповідь. По отриманні 
послуги, Клієнту пропонується оцінити її якість (за бажанням), обрати рівень 
рейтингового балу для юриста і залишити коментар. 
На діаграмі класів нижче (рис. 3.3.) ми можемо спостерігати графічне 
зображення відношення сутностей, де зафарбований ромбик біля сутності вказує на 
 83 
відношення із залежністю, тобто це означає ситуацію, коли зміна в специфікації 
однієї сутності може вплинути на іншу сутність, яка її використовує. Сутність, до 
якої зафарбований ромбик знаходиться ближче, є незалежним класом, а сутність, до 
якої ромбик знаходиться у цьому відношення більш віддалено, є залежною від 
незалежної. Завершення існування незалежної сутності невідворотньо спричиняє 
зникнення і залежних від неї сутностей. 
 
 84 
 
Рисунок 3.3. — Діаграма класів для ілюстрації відношення композиції 
 
На діаграмі нижче (рис. 3.4.) ми спостерігаємо відношення узагальнення між 
класами.  
 
 85 
 
Рисунок 3.4. — Відношення узагальнення між класами 
 
Узагальнення дає класу можливість успадковувати відкриті або захищені 
атрибути і операції суперкласу (класу від якого успадковуються атрибути і операції). 
Тут суперкласом є Користувач, оскільки у це поняття вкладаються всі інші 
поняття/сутності, зазначені під ним. Так, користувачами є і звичайний відвідувач, і 
клієнт, і роботодавець, і юрист, і ментор, і адміністратор всієї системи. Вони мають 
однакові атрибути - адже кожен з них, наприклад, має ім’я. Разом з тим, кожен з них 
має свої індивідуальні атрибути,  наприклад, різний рівень прав доступу до 
функціоналу Платформи.  
На діаграмі нижче (рис. 3.5.) ми бачимо класи, що беруть участь в реалізації 
варіанту використання Register on Platform. Тобто, тут показано яким чином кожен з 
акторів проходить процедуру реєстрації на Платформі, щоб мати можливість 
скористатись її функціоналом. 
Як видно, верхній ряд має напис <<boundary>>, він означає класи, які служать 
посередниками при взаємодії зовнішніх об'єктів з системою. 
В свою чергу, середній ряд має напис <<control>>, що вказує на клас 
управляючий, який забезпечує координацію поведінки об'єктів в системі.  
 86 
 
 
Рисунок 3.5. — Класи, що беруть участь в реалізації варіанту використання  
Register on Platform 
 
І, нарешті, нижній клас має напис <<entity>>, що означає ключові абстракції 
(поняття) системи, яка розробляється. В даному випадку, це Клієнт, Юрист та 
Ментор. 
На діаграмі нижче (рис. 3.6.) ми можемо бачити створення класів аналізу і 
відповідної діаграми Private talk. 
 
 
Рисунок 3.6. — Створення класів аналізу і відповідної діаграми Private talk 
 87 
Тут видно, що “Юрист” та “Клієнт” діють через взаємне прийняття Публічної 
оферти, як основи співпраці та поведінки на Платформі. Юрист може отримати 
Питання та надати Відповідь, Клієнт може задати Питання та отримати відповідь. 
3.4.2. Діаграми пакетів 
У мові UML (Unified Modeling Language) діаграми використання можуть бути 
організовані в пакети або моделі для легшого управління складними системами та їх 
варіантами використання. Пакети допомагають структурувати та групувати варіанти 
використання, що належать до певних підсистем або модулів. Ось як це робиться: 
Створення пакетів: Спочатку потрібно створити пакети або моделі, які 
будуть вміщувати ваші варіанти використання. Пакети можна розглядати як 
контейнери для організації елементів UML. 
Додавання варіантів використання до пакетів: Після створення пакетів ви 
можете перетягувати або додавати варіанти використання до відповідних пакетів. 
Для цього ви можете використовувати властивість "contained" (вкладено) або просто 
перетягнути варіант використання в пакет на вашій діаграмі. 
Назва та документація пакетів: Не забудьте дати назви та, за необхідності, 
додати документацію для кожного пакета. Це допоможе іншим членам команди 
краще розуміти структуру системи. 
Лінії відносин: Ви також можете використовувати лінії відносин між 
пакетами, які вказують, як вони взаємодіють або залежать один від одного. Це може 
бути зроблено за допомогою ліній "включення" (include), "розширення" (extend), 
"залежність" (dependency) або інших відносин, які відображають логічні або фізичні 
зв'язки між пакетами. 
 88 
Отже, використанням пакетів покращує структуру та організацію діаграми 
варіантів використання і робить її більш зрозумілою та керованою, особливо в 
складних системах з багатьма варіантами використання. 
У мові UML, для графічного зображення пакету з діаграмами варіантів 
використання ми можемо використовувати такі елементи та практики: 
Пакет (Package): Сам пакет відображається у формі прямокутника з назвою 
пакета, розміщеною в верхній частині прямокутника. Назва пакета зазвичай 
розташовується в середині прямокутника. Ім'я пакета допомагає ідентифікувати цей 
пакет та може бути довільним текстом, який ви виберете. 
Вкладені діаграми варіантів використання: Ми можемо додавати вкладені 
діаграми варіантів використання всередину пакету. Це зазвичай відображається як 
ім'я діаграми варіанта використання (або посилання на неї) всередині прямокутника 
пакета. Візуально, це може бути зображено як малий прямокутник або лінію, яка 
вказує на вкладену діаграму варіанта використання всередину пакету. 
Лінії відношень: Якщо в пакеті містяться більше однієї діаграми варіанта 
використання, то ви можете використовувати лінії відношень (зв'язки) для показу 
взаємозв'язків між ними. Наприклад, відношення включення (include) або 
розширення (extend) можуть бути використані для відображення зв'язків між 
вкладеними діаграмами варіантів використання. 
Анотації та документація: Ми також можемо додавати анотації та 
документацію для пакета, щоб пояснити його призначення або надати додаткову 
інформацію. 
Загалом, графічне зображення пакету з діаграмами варіантів використання 
виглядає як контейнер, який містить вкладені діаграми варіантів використання та 
 89 
відображає зв'язки між ними, якщо вони є. 
Діаграми варіантів використання в мові UML містять певні типи елементів та 
відношень, що використовуються для моделювання варіантів використання системи. 
Ось деякі основні типи елементів та відношень, які характерні для діаграм варіантів 
використання: 
Типи елементів: 
Актори (Actors). Актори представляють зовнішніх користувачів або інші 
системи, які взаємодіють з системою. Актори зображаються у діаграмі варіантів 
використання як піктограми, такі як людина або іконки для інших систем. 
Варіанти використання (Use Cases). Варіанти використання описують 
конкретні функціональність чи функціональні вимоги системи з точки зору 
користувача або акторів. Кожен варіант використання описує конкретний сценарій 
взаємодії з системою. 
Система (System). Система являє собою контейнер для варіантів 
використання, що дозволяє групувати їх в рамках великої системи. 
Типи відношень: 
Включення (Include). Відношення включення показує, як один варіант 
використання може включати інший. Наприклад, певний варіант використання може 
включати у себе інший, менший варіант, як частину більшого сценарію. 
Розширення (Extend). Відношення розширення показує, як деякі додаткові дії 
можуть бути виконані в разі виникнення певних умов. Наприклад, певний варіант 
використання може розширювати інший варіант, якщо певна умова спрацьовує. 
Залежність (Dependency). Залежність використовується для показу 
 90 
взаємозв'язків між варіантами використання, акторами та іншими елементами 
системи. Вона показує, як один елемент може залежати від іншого. 
Загальний аліас (Generalization). Загальний аліас використовується для 
моделювання узагальнення та спеціалізації між варіантами використання. Вищий 
рівень варіанта включає загальні властивості, а більш нижній рівень спеціалізує ці 
властивості для конкретного сценарію. 
Ці елементи та відношення дозволяють створювати структуровані та зрозумілі 
діаграми варіантів використання для аналізу та моделювання функціональності 
системи з точки зору користувача і зовнішніх акторів. 
 
 
Рисунок 3.7. — Пакет 1 “Ознайомлення Відвідувача з Платформою” 
 91 
На рис. 3.7. можна побачити приклад пакету, який вміщує діаграму варіанту 
використання щодо ознайомлення сутності “Відвідувач” з вмістом Платформи. Як 
бачимо, сутність “Відвідувач” може бути одночасно і “Клієнтом” відносно будь-
якого “Юриста” і “Роботодавцем” відносно нього ж. Також тут можемо побачити 
вкладеність в одну діаграму варіанту використання декількох (п’яти) інших діаграм 
варіантів використання, які позначені лініями відношення виду “include”. 
 
 
Рисунок 3.8. — Пакет 2 “Отримання Відвідувачем інформації на Платформі” 
 92 
На рис. 3.8. можна побачити приклад пакету, який вміщує діаграму варіанту 
використання щодо отримання сутністю “Відвідувач” інформації з розділу 
“Юристи”.  
Тут видно вкладеність в одну діаграму варіанту використання декількох 
(п’яти) інших діаграм варіантів використання, які позначені лініями відношення 
виду “include”(включає).  
Зокрема, це означає, що отримання інформації (основна діаграма виду 
використання) включає в себе такі діаграми виду використання, як отримання 
інформації про загальну кількість Юристів на платформі, рейтинг кожного з них, 
кількість наданих кожним з них консультацій, тощо.  
3.5. Архітектурне проектування 
3.5.1. Діаграми компонентів 
Діаграми компонентів (Component Diagrams) в мові UML використовуються 
для моделювання структури програмної системи або додатку, зокрема компонентів, 
які становлять програму. Ось основні характеристики та особливості діаграм 
компонентів: 
Мета: Головна мета діаграм компонентів полягає в тому, щоб візуалізувати 
архітектурну структуру програмної системи та компонентів, з яких вона складається. 
Вони допомагають розробникам та архітекторам краще розуміти, як програма 
організована на рівні компонентів. 
Елементи: Діаграми компонентів містять елементи, такі як компоненти, 
інтерфейси, порти, абстракції та зв'язки між ними. Компоненти представляють 
функціональні частини програми, які можуть бути розглянуті окремо. 
Компоненти: Компоненти відображають різні частини програмної системи, 
такі як модулі, бібліотеки, підсистеми, сервіси, модулі та інші функціональні 
одиниці. 
 93 
Інтерфейси та Порти: Інтерфейси визначають способи взаємодії між 
компонентами, а порти (порти компонентів) вказують на точки доступу до 
функціональності компонента. 
Зв'язки: Діаграми компонентів показують зв'язки між компонентами та 
інтерфейсами, включаючи відносини залежності, агрегації та асоціації. 
Архітектурні рішення: Вони дозволяють виразити архітектурні рішення, такі 
як розподілені системи, шаровані архітектури та інші концепції, які впливають на 
організацію програмної системи. 
Розгортання: Діаграми компонентів також можуть використовуватися для 
моделювання фізичного розгортання компонентів на апаратному обладнанні, 
включаючи сервери, комп'ютери та інші пристрої. 
Загальною метою роботи є побудова та фактична реалізації Програмної 
платформи соціального проєкту на розв'язання проблеми безробіття в галузі права 
та розширення засобів безоплатної первинної правничої допомоги (клієнтська 
частина). 
На Рис. 3.9. (нижче) показана діаграма компонентів Платформи. 
 
 94 
 
Рисунок 3.9. — Діаграма основних компонентів платформи 
Тут видно, що Платформа в цілому складається з групи компонентів з 
розширенням .html. Ці компоненти містять в собі весь код програмного продукту. 
Тут ми бачимо, що від компонента index.html залежить компонент style.css. В 
свою чергу, від компонента style.css залежать компоненти topics.html, lawyers.html, 
mentors.html, reviews.html, author.html. 
В свою чергу компонент base.db є залежним від компонентів topics.html, 
lawyers.html, mentors.html, reviews.html, author.html, оскільки наповнюється даними 
з цих постійно оновлюваних джерел. 
Також ми можемо бачити графічне відображення інтерфейсів index.html, які 
реалізують перехід в меню, презентацію платформи а також відкривають 
 95 
користувачу доступ до функціоналу Платформи через IEnter інтерфейс реєстрації за 
email. 
Таке відображення платформи через компоненти дозволяє в цілому побачити 
принцип її функціонування та залежності між окремими компонентами.  
3.5.2. Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання. 
 Діаграма розгортання в інженерії програмного забезпечення використовується 
для візуалізації та опису фізичної архітектури системи, тобто розташування та 
взаємодії її компонентів на різних вузлах апаратного забезпечення. Нижче показано 
наповнення діаграми розгортання для нашої системи: 
1 Вузли. 
- веб-сервер: відповідальний за надання веб-інтерфейсу для користувачів та 
обробку їхніх запитань. 
- база даних: місце зберігання інформації про користувачів, консультації, 
відгуки та інші дані системи. 
- чат-сервер: забезпечує функціональність чату та обмін повідомленнями 
між користувачами та наставниками. 
2 Артефакти. 
- інтерфейс користувача: інтерфейс, який відображається на браузері 
користувача та надає можливість взаємодії з системою. 
- база даних: схема бази даних, таблиці та зв'язки між ними. 
- додатки: програмні компоненти, які виконують бізнес-логіку системи. 
- чат-інтерфейс: елемент, який забезпечує взаємодію між користувачами та 
наставниками через чат. 
 96 
3 Відносини: 
- з'єднання між веб-сервером та базою даних: вказує, що веб-сервер 
взаємодіє з базою даних для отримання і зберігання інформації. 
- з'єднання між сервером додатків та базою даних: вказує, що сервер 
додатків використовує базу даних для обробки даних та виконання бізнес-
логіки. 
- з'єднання між веб-сервером та чат-сервером: вказує, що веб-сервер 
взаємодіє з чат-сервером для забезпечення чат-функціональності. 
4 Артефакти вузла: 
- код додатків: використовується для позначення програмного коду, який 
виконується на сервері додатків. 
- база даних: вказує на наявність конкретної бази даних, яка 
використовується системою. 
Ці елементи та взаємодії відображають структуру та архітектурні компоненти 
нашої системи на діаграмі розгортання. Приклад показано на Рис.3.10. 
 
 97 
 
Рисунок 3.10. — Діаграма розгортання 
 
3.6. Моделювання поведінки системи 
3.6.1. Діаграми діяльності 
Діаграми діяльності в мові UML (Unified Modeling Language) 
використовуються для моделювання послідовності дій та процесів в системі. Вони 
допомагають візуалізувати, як об'єкти взаємодіють один з одним у різних сценаріях. 
Основні елементи діаграми діяльності включають в себе наступне: 
Процеси (activity): Процеси представляють окремі дії або кроки в системі. 
Кожен процес може мати свою назву та інструкції, що описують, що потрібно 
зробити. 
 98 
Дії (action): Дії - це конкретні кроки, які виконуються в рамках процесу. Вони 
можуть включати обчислення, взаємодію з іншими об'єктами або системними 
ресурсами. 
Рішення (decision): Рішення вказують на роздвоєння процесу, в залежності від 
умови. Вони представлені умовними діагональними стрілками з умовним виразом. 
Об'єднання (merge): Об'єднання вказують на збільшення двох або більше 
потоків діяльності в один. Вони представлені умовними діагональними стрілками 
без умовного виразу. 
Паралельні потоки (fork і join): Fork (розділення) вказує на поділ процесу на 
два або більше паралельних потоки діяльності, тоді як Join (об'єднання) вказує на їх 
об'єднання. 
Початковий та кінцевий вузли (initial і final): Початковий вузол вказує на 
початок діаграми, а кінцевий - на закінчення процесу. 
Об'єкти (object): Об'єкти можуть бути включені в діаграму діяльності для 
представлення конкретних екземплярів класів, які взаємодіють між собою. 
Pins: використовуються для передачі даних між діями або вхідною/вихідною 
точкою процесу. У діаграмах діяльності "pins" представляються як маленькі графічні 
об'єкти біля дій або кільцями поруч з діями, і вони можуть мати різні типи, такі як 
вхідний або вихідний параметр, тимчасова змінна і т. д. Вони використовуються для 
передачі даних між різними діями в діаграмі діяльності, вказуючи на вхідні та 
вихідні дані кожної дії. 
Структура діаграми діяльності включає в себе стрілки, які показують 
послідовність виконання дій та потоки керування між різними елементами. Діаграми 
діяльності допомагають розуміти, як система взаємодіє з об'єктами та як 
вона реагує на різні події та умови. 
Діаграми діяльності важливі для аналізу та проектування програмних систем, 
а також для моделювання бізнес-процесів та інших послідовностей дій. 
Щодо різниці між діаграмами станів та діаграмами діяльності: 
Діаграми станів і діаграми діяльності - це два різні види діаграм в мові UML, і 
вони використовуються для моделювання різних аспектів систем.  
 99 
Основна принципова різниця між ними полягає в тому, що діаграми станів 
моделюють стан об'єкта чи системи та його зміни, тоді як діаграми діяльності 
фокусуються на послідовності дій і процесів. Ось більше деталей про ці два види 
діаграм: 
Діаграми станів (State Diagrams): 
Моделювання станів: Діаграми станів використовуються для представлення 
станів об'єкта чи системи та переходів між ними в залежності від подій або умов. 
Зорієнтовані на стани: Головний фокус - це на визначенні різних станів об'єкта 
та умов, за яких він переходить з одного стану в інший. 
Зручно для систем зі складними станами та переходами: Використовується для 
моделювання систем, де важливо відстежувати стани та переходи між ними, 
наприклад, автомати, програмне забезпечення зі складними станами, тощо. 
Діаграми діяльності (Activity Diagrams): 
Моделювання дій та процесів: Діаграми діяльності використовуються для 
моделювання послідовності дій і процесів, які відбуваються в системі. 
Зорієнтовані на процеси та потоки роботи: Головний фокус - це на візуалізації 
послідовності дій та процесів, що відбуваються в системі. 
Зручно для опису бізнес-процесів та логіки програмного коду: 
Використовується для опису бізнес-процесів, управління послідовністю виконання 
програмного коду, опрацювання даних, тощо. 
На рис. 3.11. (нижче) розміщена діаграма діяльності, яка ілюструє 
послідовність та варіанти дій Юриста при використанні ним функціоналу 
Платформи. Обов’язковим є етап верифікації його особи через введення адреси 
email. Після верифікації Юрист має вибір - отримати сертифікат про 
результативність своєї роботи на Платформі, або ж продовжити працювати в 
напрямку надання консультацій клієнтам.  
Якщо Клієнт запитав рецензію Ментора, то Юрист має вибір щодо 
ознайомлення та врахування такої рецензії. 
 100 
 
Рисунок 3.11. — Діаграма діяльності  сутності класу "Юрист" з варіантами  
 101 
активності на Платформі 
 
 102 
Рисунок 3.12. — Діаграма діяльності  сутності класу "Клієнт" з варіантами 
активності на Платформі 
На рис. 3.12. розміщена діаграма діяльності, яка ілюструє послідовність та 
варіанти дій Клієнта, який бажає скористатись функціоналом Платформи. Ми 
бачимо, що стадія авторизації є обов’язковою у послідовності подій і дає можливість 
рухатись далі до мети. На етапі вибору Юриста, якому Клієнт хоче задати питання, 
система пропонує вибір, коли можна за id обрати конкретного Юриста, або ж 
доручити вибір Платформі, яка розмістить пропозицію в кабінеті кожного Юриста і 
відповідь надасть той, хто першим відгукнувся. 
Також ми бачимо, що Клієнт скористався функціоналом отримання рецензії на 
консультацію Юриста, яку дає Ментор. 
Також, Клієнт має вибір чи ставити рейтинг Юристу та чи залишати коментар 
щодо свого враження від роботи Юриста та Платформи в цілому. 
 
 103 
 
Рисунок 3.13. — Фрагмент діаграми діяльності Платформи 
 
На рис. 3.13. (вище) видно фрагмент діаграми діяльності Платформи “Юрист 
онлайн”, де можемо спостерігати одночасно за діями/процесами для чотирьох 
класів: Клієнт, Платформа, Юрист, Ментор. 
  Зокрема, на початку Клієнт ставить питання, яке Платформа передає на 
розгляд Юристу. Юрист читає питання та дає на нього відповідь посередництвом 
Платформи. Клієнт бажає отримати рецензію Ментора та надсилає про це 
відповідний запит. Платформа розгалужує роботу та інформує про запит одночасно 
і Юриста і Ментора, кожен з яких реагує згідно своїх функцій. Врешті, 
завершальним варіантом взаємодії Клієнта та Платформи може бути виставлення 
рейтингу та розміщення коментарю. 
 104 
3.6.2. Діаграми послідовності 
Діаграма логічного моделювання для представлення часових аспектів 
взаємодії об'єктів у мові UML називається "діаграмою послідовності" (Sequence 
Diagram). Ця діаграма структурно відображає, як об'єкти взаємодіють між собою 
впродовж певного часу і показує послідовність подій. 
Основні елементи діаграми послідовності включають: 
Об'єкти (об'єктні ліфти): Це учасники взаємодії, такі як класи або об'єкти, 
які взаємодіють між собою. Вони відображаються у верхній частині діаграми. 
Лінії життя: Лінії, які вказують на "життя" об'єкта протягом певного 
інтервалу часу, де взаємодія відбувається. 
Послідовність стрілок: Вони показують порядок виконання повідомлень або 
методів між об'єктами. Стрілки показують, який об'єкт відправляє повідомлення, і 
який об'єкт його приймає. 
Повідомлення: Це дії або повідомлення, які відправляються від одного об'єкта 
до іншого. Вони вказують, що та сама подія відбувається у взаємодії. 
Активація: Вказує період активності об'єкта під час взаємодії. Він показує, 
коли об'єкт виконує свої дії та коли неактивний. 
Нижче наведені англомовні назви основних елементів діаграми послідовності 
в мові UML: 
Objects (Lifelines): Об'єкти (Лінії життя). 
Sequence Diagram: Діаграма послідовності. 
Activation Bar: Активна смуга. 
Messages: Повідомлення. 
Activation: Активація. 
Execution Occurrence: Момент виконання. 
Interaction Fragment: Фрагмент взаємодії. 
Combined Fragment: Комбінований фрагмент. 
Operand: Операнд. 
Interaction Use: Використання взаємодії. 
 105 
Interaction Occurrence: Момент взаємодії. 
Ці терміни використовуються для опису різних елементів та концепцій, які 
використовуються при створенні діаграм послідовності в мові UML. 
Створимо діаграми послідовності і кооперативні діаграми для основного 
потоку подій варіанту використання Платформи “Юрист онлайн”. 
 На рис. 3.14. представлена кооперативна діаграма. Тут екземпляри об'єктів 
показані у вигляді піктограм. Лінії між ними означають повідомлення, обмін якими 
здійснюється в рамках даного варіанту використання. 
 
 
Рисунок 3.14. — Кооперативна діаграма 
На рис. 3.15. показана діаграма послідовності, яка ілюструє кроки, що робить 
Клієнт для отримання консультації.  Зокрема, він створює обліковий запис шляхом 
використання відповідного вікна у реєстраційній формі, що дає змогу під контролем 
Платформи опинитись в чат-сторінці і задати своє питання. При цьому чат-сторінка 
в ході спілкування відображає зміст розмови Клієнта з Юристом, рецензію Ментора 
а також можливість виставити рейтинг та залишити відгук. 
 
 106 
 
Рисунок 3.15. — Діаграма послідовності з отримання Клієнтом консультації 
 
На рис. 3.16. нижче показана діаграма послідовності дій Юриста при наданні 
Консультації Клієнту.  
Тут ми бачимо, що для початку Юрист має пройти етап авторизації, що дає 
можливість опинитись в персональному кабінеті. Тут є перелік нових запитань від 
Клієнтів, в тому числі персональні запитання.  
На діаграмі видно, що Юрист має вибір - відповідати чи відмовитись робити 
відповідь на персональне запитання.  
Врешті, коли Юрист робить вибір і пише відповідь на обране ним запитання, 
це відбувається з переходом в окрему чат-кімнату. 
Ми бачимо, що Клієнт може задати додаткове питання, а Юрист може надати 
на нього додаткову відповідь.  
Також, тут зображена фінальна дія Клієнта, який дає оцінку роботі Юриста та 
Платформи в цілому (рейтинг), а також залишає власний відгук. 
 
 107 
 
Рисунок 3.16. — Діаграма послідовності дій Юриста з надання Клієнту 
консультації 
 
На рис. 3.17. (нижче) показано процес вибору Відвідувачем конкретного 
Юриста.   
Зокрема, для отримання такої можливості Відвідувач робить перший крок і 
заходить в меню сайту. Тут він обирає сторінку з обговореннями, щоб побачити 
найбільш результативного Юриста у потрібній Відвідувачу галузі права.   
Читаючи заголовки тем та слідкуючи за тим, хто з Юристів давав відповідь, 
Відвідувач робить для себе відповідні висновки.  
Обравши декілька Юристів, які могли б його зацікавити, як Клієнта чи 
Роботодавця, він переходить на сторінку Юристи та використовуючи фільтри 
оцінює Юристів за декількома критеріями, після чого робить остаточний вибір, 
беручи до уваги ID конкретного Юриста і його прізвище та ім’я.  
 108 
Цей функціонал Платформи, показаний через діаграму послідовності дій 
Відвідувача, є зручним інструментом для ефективного використання головного 
цінного ресурсу Платформи, яким є група молодих талановитих Юристів. 
 
 
Рисунок 3.17. — Діаграма вибору Відвідувачем конкретного Юриста 
 
3.6.3. Діаграми комунікації 
 Діаграма комунікації в інженерії програмного забезпечення використовується 
для візуалізації та опису взаємодії між об'єктами або компонентами системи через 
обмін повідомленнями або викликами методів. Ось можливий підхід до наповнення 
діаграми комунікації для нашої системи: 
1 Учасники: 
- клієнт: Представляє користувача, який шукає юридичну консультацію. 
- молодий юрист: Представляє молодого юриста, який надає консультацію 
клієнту. 
 109 
- наставник: Представляє досвідченого наставника, який може перевіряти 
роботу молодого юриста за бажанням клієнта. 
2 Взаємодія: 
- запит на консультацію: Клієнт ініціює запит на консультацію, надсилаючи 
його молодому юристу. 
- радання консультації: Молодий юрист відповідає на запит, надаючи 
консультацію клієнту. 
- перевірка роботи: Клієнт може виразити бажання перевірити роботу 
молодого юриста. Якщо так, наставник взаємодіє з молодим юристом для 
здійснення перевірки. 
3 Повідомлення: 
- запит та відповідь на консультацію: Передача запиту на консультацію від 
клієнта до молодого юриста та відповідь на нього. 
- повідомлення перевірки: Випадкова або системна перевірка молодого 
юриста наставником. 
4 Сценарій: 
- клієнт ініціює запит на консультацію, відправляючи його молодому 
юристу. 
- молодий юрист отримує запит та відповідає на нього, надаючи 
консультацію клієнту. 
- клієнт може вирішити перевірити роботу молодого юриста, звернувшись 
до наставника. 
- наставник взаємодіє з молодим юристом для проведення перевірки та 
надає відповідні поради чи рекомендації. 
Ця діаграма взаємодії ілюструє ключові етапи взаємодії між клієнтом, 
молодим юристом та наставником на нашій платформі безоплатних юридичних 
консультацій. 
 
 110 
 
Рисунок 3.18. — Діаграма комунікації 
 
3.6.4. Діаграми скінченного автомату 
Структурна характеристика розробки діаграм скінченного автомату (або 
діаграм станів) в мові UML включає в себе ряд елементів та концепцій, які 
допомагають моделювати стани об'єктів та їхні переходи.  
Основні складові структури діаграм станів в UML включають такі елементи: 
Стани (States): 
Стани відображають конкретні фази або умови об'єкта в процесі його 
життєвого циклу. 
Стани можуть бути простими (без поділу на підстани) або складними (з 
підстави, що мають свої власні стани). Стани представляються у діаграмі як 
прямокутники з назвами. 
Події (Events): 
 111 
Події визначають вхідні події або сприймані сигнали, які можуть спричинити 
зміну стану об'єкта. 
Події представляються у діаграмі як стрілки, які вказують на перехід між 
станами. 
Переходи (Transitions): 
Переходи показують, як об'єкт переходить з одного стану в інший при 
виникненні певних подій. 
Переходи зазвичай пов'язані з певними умовами, які визначають, коли і яким 
чином вони мають бути виконані. 
Переходи представляються стрілками, що з'єднують стани та позначають події 
або умови, що їх спричиняють. 
Початковий стан (Initial State): 
Початковий стан вказує на початковий стан об'єкта в його життєвому циклі. 
Це стан, в який об'єкт переходить після його створення. 
Фінальний стан (Final State): 
Фінальний стан вказує на заключний стан об'єкта в його життєвому циклі. 
Після переходу в фінальний стан об'єкт завершує своє існування. 
Синхронізовані стани (Synchronized States): 
Синхронізовані стани використовуються для моделювання одночасних або 
паралельних процесів у системі. 
Зони станів (State Regions): 
Зони станів дозволяють групувати стани та їхні переходи в складних об'єктах. 
Регіони супроводу (History Regions): 
Регіони супроводу відстежують історію переходів об'єкта між станами. 
Структурна характеристика діаграми станів UML визначає, як ці елементи 
пов'язані між собою та як вони моделюють життєвий цикл об'єкта. Діаграми станів 
 112 
дозволяють візуалізувати різні стани об'єкта та логіку їхніх переходів, що сприяє 
кращому розумінню функціональності системи. 
На рис. 3.19. представлена діаграма станів екземпляра класу “Клієнт” в ході 
взаємодії з чат-системою Платформи.  
Видно, що доступ до функціоналу Платформи щодо отримання юридичної 
консультації можливий виключно через систему авторизації із задіянням особистого 
email Користувача.  
У разі обходу стадії авторизації, доступ до функціоналу Платформи відсутній. 
 
 
Рисунок 3.19. — Діаграма станів екземпляра класу "Клієнт" в ході взаємодії з чат-
системою Платформи 
 
 113 
На рис. 3.20. (нижче) представлено діаграму станів екземпляра класу 
“Користувач” при спробі доступу до функціоналу Платформи, призначеного 
виключно для Користувача класу “Юрист”.  
 
 
Рисунок 3.20. — Діаграма станів екземпляра класу "Відвідувач" при спробі доступу 
до Платформи з функціоналом для класу "Юрист" 
 
Тут база даних з відомостями про email кожного Юриста Платформи дозволяє 
порівняти введений Користувачем email з набором email Юристів Платформи, зарані 
введених і збережених у цй БД. Якщо введений email відсутній у БД, доступ до 
вказаного функціоналу неможливий. 
Разом з тим, security-функція полягає не лише у володінні Користувачем 
інформацією про найменування email зарані авторизованого Юриста, але і в 
 114 
можливості доступу до поштової скриньки такого Юриста, доступ до якої може мати 
лише особа, яка знає відповідний пароль до поштової скриньки.  
 
 
 
Рисунок 3.21. — Діаграма перетворення узагальнення 
 
На рис. 3.21. ми бачимо діаграму перетворення узагальнення. Тут видно, що 
взагалі кожен Користувач може, як людина, мати ім’я, дату народження та поточну 
адресу, і це дозволяє узагальнити відомості про будь-якого користувача системи. 
Разом з тим, підкласи “Юрист” і “Ментор”, хоча і мають багато спільних атрибутів, 
однак мають і суттєву відмінність. Зокрема, клас “Юрист” має атрибут “no 
 115 
experience”, а клас “Ментор” має протилежний за змістом атрибут “experience”, що і 
є їх головною відмінною рисою. На рис. 3.22. ми  можемо бачити в цілому модель 
діяльності Платформи “Юрист онлайн”. Ця діаграма дозволяє прослідкувати стани 
одночасно декількох класів в залежності від дій, що вчиняються. 
 
 
Рисунок 3.22. — Модель діяльності Платформи “Юрист онлайн” 
Тут видно, що будь-який з класів (акторів) на початку має рівні можливості, 
об’єднані для класу “Користувач”, проте з вчиненням дій щодо авторизації, для 
 116 
кожного з підкласів розкриваються свої власні варіанти дій та персональний 
функціонал, відмінний від функціоналів інших підкласів. 
 3.7. Діаграми кооперації 
Діаграма кооперації (Collaboration Diagram) в мові UML використовується для 
моделювання взаємодії об'єктів або елементів системи з точки зору їх структури та 
взаємодії.  
Вона надає засоби для візуалізації, як об'єкти співпрацюють між собою для 
досягнення певної функціональності в системі.  
Lіаграми кооперації включа.nm такі елементи: 
Об'єкти (Participants): Це об'єкти або класи, які беруть участь у взаємодії та 
виконують певні функції в системі. Вони представлені в діаграмі у вигляді 
прямокутників або еліпсів з іменами. 
Зв'язки (Links): Зв'язки між об'єктами показують, як вони співпрацюють між 
собою. Вони представлені стрілками або лініями, які з'єднують об'єкти. 
Ролі (Roles): Ролі визначають, як об'єкти взаємодіють в рамках певного 
контексту. На діаграмі вони вказують, яка частина об'єкта бере участь у конкретній 
взаємодії. 
Посилання (Links): Вони вказують на зв'язки між ролями об'єктів. Посилання 
можуть бути асоціативними або агрегаційними, відображаючи природу зв'язку. 
Обмеження (Constraints): Діаграма кооперації може включати обмеження, які 
описують умови чи обмеження на взаємодію між об'єктами. 
Повідомлення (Messages): Повідомлення вказують, які повідомлення 
передаються між об'єктами під час взаємодії. 
Фрейми (Frames): Фрейми можуть використовуватися для визначення 
контексту або обмежень взаємодії між об'єктами. 
Одиниця вимірювання часу: Діаграма кооперації може включати шкалу часу, 
яка показує послідовність подій та взаємодії в часовому контексті. 
 117 
Діаграми кооперації (Collaboration Diagrams) в мові UML відрізняються від 
інших видів діаграм за їхнім призначенням та способом представлення взаємодії між 
об'єктами. Ось декілька ключових відмінностей між діаграмами кооперації та 
іншими видами діаграм в UML: 
Призначення: Діаграми кооперації призначені для моделювання взаємодії між 
об'єктами або класами, зокрема їх структури та способу взаємодії. Їх основна мета - 
показати, як об'єкти співпрацюють один з одним для досягнення певної 
функціональності. 
Представлення взаємодії: Діаграми кооперації акцентують увагу на взаємодії 
між об'єктами у конкретний момент часу. Вони показують, як об'єкти взаємодіють, 
передають повідомлення та виконують функції в часовому контексті. 
Спрямованість: У діаграмах кооперації стрілки або лінії показують 
спрямовану взаємодію між об'єктами, вказуючи, який об'єкт ініціює взаємодію. 
Альтернатива із Sequence Diagrams: В деяких випадках, діаграми кооперації 
можна використовувати для подібних цілях, як і діаграми послідовності (Sequence 
Diagrams). Проте діаграми кооперації більше спрямовані на моделювання структури 
співпраці об'єктів, тоді як діаграми послідовності акцентують послідовний хід подій. 
Контекст моделювання: Діаграми кооперації зазвичай використовуються для 
детального моделювання конкретних сценаріїв взаємодії в системі, під час яких 
важливо враховувати структурні аспекти. 
На рис.3.23 представлене графічне зображення відношення узагальнення між 
окремими коопераціями.  
 Зокрема, ми бачимо, що під час першої взаємодії як клас “юрист” так і клас 
“клієнт” є узагальненими.  
 Однак, якщо Клієнту сподобалась послуга Юриста вперше, він може 
звернутись до того ж Юриста вдруге, застосувавши спосіб звернення через обрання 
конкретного, вже відомого Клієнту, Юриста для другої та послідуючих 
консультацій. 
 118 
 В такому випадку, зручно відобразити ці кооперації з елементом узагальнення, 
як це показано на рис. 3.23. 
 
 
 
Рисунок 3.23. — Графічне відображення відношення узагальнення 
між окремими коопераціями рівня специфікації 
 
На рис. 3.24. (нижче) показано графічне зображення мультиоб’єктів на 
діаграмі кооперації. Ми можемо бачити, як мультиоб’єкт “сервер” пов’язаний 
відношенням з базою даних. Більше детально ця обставина розглядається у 
подальших прикладах. 
 
 
Рисунок 3.24. — Графічне зображення мультиоб’єктів на діаграмі кооперації 
 
 119 
На рис. 3.25. представлено графічне зображення активного об’єкта (ліворуч) 
на діаграмі кооперації. Ми бачимо, що біля клієнта є позначення {active} - це 
додатковий спосіб зробити явним стан активності одного з елементів для 
стороннього спостерігача. 
 
Рисунок 3.25. — Графічне зображення активного об'єкта (ліворуч) на діаграмі 
кооперації 
 
На рис. 3.26. ми бачимо фрагмент діаграми кооперації для передачі питання на 
вирішення обраному серед багатьох юристу. База з юристами в даному випадку є 
мультиоб’єктом та врешті відувається вибір лише одного Юриста. Ми пам’ятаємо, 
що у Клієнта є два способи обрати Юриста: рандомниий, тобто питання бере в 
роботу перший вільний юрист, який вияив бажання; персональний - коли Клієнт 
обирає конкретного Юриста за його ID і таким чином питання набуває статусу 
персонального. 
 
 
Рисунок 3.26. — Фрагмент діаграми кооперації для передачі питання  
обраному серед багатьох (мульти) юристу 
 
 120 
На рис. 3.27. ми бачимо графічне зображення складеного об’єкта на діаграмі 
кооперації. Зокрема, коли Клієнт заходить на головну сторінку Платформи, він 
бачить сукупність об’єктів (складений об’єкт), які разом утворюють первинний 
функціонал Платформи. 
 
 
Рисунок 3.27. — Графічне зображення складеного об'єкта на діаграмі кооперації 
 
На рис. 3.28. представлено графічне зображення зв’язків з різними 
стереотипами. Тут представлена узагальнена схема роботи Платформи, яка вміщує 
команду Юристів (як відділ компанії, анонімний мультиоб'ект "Команда"). Остання, 
в свою чергу, складається з Юристів (анонімний мультиоб'ект "Юрист").  
 
 121 
 
Рисунок 3.28. — Графічне зображення зв’язків з різними стереотипами 
 
І врешті, на рис. 3.29. (нижче) представлена діаграма кооперації для 
моделювання консультаційного чату на Платформі. 
 Тут ми бачимо, як відбувається взаємодія всіх класів для кінцевого результату 
у вигляді консультаційного чату.  
Клієнт взаємодіє з реєстраційною формою, поштовою скринькою і власним 
кабінетом.  
Його дії спонукають Платформу створити консультаційний чат і передати 
питання Юристу за описаним вище алгоритмом.  
Юрист може прийняти питання чи відмовитись від нього, що є опцією для 
 122 
персональних питань. Відповідь Юриста доповнює консультаційний чат і 
відбувається те, заради чого ця система існує. 
 
 
Рисунок 3.29. — Діаграма кооперації для моделювання консультаційного чату 
  
 123 
4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
4.1. Розробка програмного комплексу 
4.1.1. Обґрунтування вибору засобів реалізації 
Клієнтська частина програмної платформи (front end) виконана з 
використанням HTML5, CSS3, JS, що обгрунтовано наступним:  
1 Широке поширення та підтримка 
HTML5, CSS3 і JS є широко використовуваними технологіями в сфері веб-
розробки та користуються великою підтримкою від різних браузерів. Вони 
забезпечують стабільну та сумісну роботу платформи на різних пристроях та 
платформах. 
2 Простота вивчення та розвиток 
HTML5, CSS3 та JS є відносно легкими для вивчення та розвитку 
технологіями, що полегшує роботу розробників. Для студентів-магістрів, які можуть 
мати різний рівень досвіду в програмуванні, це важливий аспект. 
3 Можливості візуального оформлення (CSS3) 
CSS3 надає багато можливостей для створення привабливого та сучасного 
дизайну, що є важливим для користувачів, особливо у сфері юридичних 
консультацій, де важлива чіткість та професійний вигляд. 
4 Динамічність та інтерактивність (JS) 
JavaScript дозволяє створювати динамічні та інтерактивні елементи на веб-
сайті. Це важливо для створення зручного інтерфейсу для користувачів та 
покращення взаємодії у чатах. 
5 Підтримка мобільних пристроїв 
Використання HTML5, CSS3 та JS дозволяє створювати респонсивний дизайн, 
що легко адаптується до різних розмірів екранів, що важливо для доступності 
платформи на мобільних пристроях. 
6 Забезпечення безпеки 
 124 
Використання стандартів безпеки, які вбудовані в HTML5 та JavaScript, 
дозволяє забезпечити високий рівень захисту конфіденційності та безпеки 
інформації користувачів. 
7 Спільнота та ресурси 
HTML, CSS та JS мають велику активну спільноту розробників, що спрощує 
пошук відповідей на питання та використання готових рішень. 
Загалом, обрані технології є зрозумілими, надійними та ефективними для 
створення клієнтської частини онлайн-платформи для надання юридичних 
консультацій. 
4.1.2. Опис структурної (функціональної) схеми 
 Опис структурної (функціональної) схеми клієнтської частини (front end) для 
створення онлайн-платформи з наданням юридичних консультацій включає такі 
ключові елементи та їхні функції: 
Головна сторінка (Main Page): 
- вітальне повідомлення та інформація про послуги платформи. 
- можливість швидкого доступу до основних розділів. 
Меню (menu page): 
- навігаційні елементи для розширення доступу до різних функцій. 
- можливість швидкої навігації між розділами платформи. 
Сторінка тем на обговоренні (topics page): 
- перелік тем, що обговорюються на платформі. 
- можливість фільтрації тем за категоріями. 
Сторінка переліку юристів (lawyers page): 
- інформація про доступних юристів. 
- можливість сортування та фільтрації за компетенціями. 
Сторінка переліку менторів (mentors page): 
- інформація про доступних наставників. 
- можливість сортування та фільтрації за компетенціями. 
Сторінка приватного чату (chat page): 
 125 
- інтерфейс для приватних текстових чатів між користувачами та юристами. 
- можливість відправлення текстових повідомлень, обрання варіантів 
поведінки. 
Сторінка відгуків (Reviews Page): 
- відгуки користувачів щодо наданих консультацій. 
- можливість залишення та перегляду відгуків. 
сторінка авторизації (authorize page): 
- форма для входу або реєстрації юриста чи ментора. 
- забезпечення безпеки та захисту даних. 
Особисті кабінети (User’s, Lawyer’s, Mentor’s Accounts): 
- особисті простори для кожної категорії користувачів з основною 
інформацією та налаштуваннями. 
Сторінка інформації для роботодавців (Employer Page): 
- інформація для потенційних роботодавців та можливість зв'язку. 
4.1.3 Опис логічної схеми системи 
Логічна схема системи для клієнтської частини онлайн-платформи надання 
юридичних консультацій виглядає наступним чином: 
Компонент "Головна сторінка" (Main Page): 
- мета: представлення основної інформації та забезпечення навігації. 
- логіка: завантаження заголовку, інформації та візуальних елементів. 
- реакція на взаємодію користувача. 
Компонент "Меню" (Menu): 
- мета: забезпечення зручної навігації між розділами платформи. 
- логіка: відображення та обробка натискань на навігаційні елементи. 
Компонент "Сторінка тем на обговоренні" (Topics Page): 
- мета: відображення доступних тем для обговорення. 
- логіка: запит на сервер для отримання списку тем. відображення та 
обробка вибору тем. 
Компонент "Сторінка переліку юристів" (Lawyers Page): 
 126 
- мета: показ переліку доступних юристів для консультацій. 
- логіка: запит на сервер для отримання списку юристів. відображення та 
обробка вибору юриста. 
Компонент "Сторінка переліку менторів" (Mentors Page): 
- мета: показ переліку доступних менторів для рецензій. 
- логіка: запит на сервер для отримання списку менторів. відображення та 
обробка вибору юриста. 
Компонент "Сторінка приватного чату" (Chat Page): 
- мета: забезпечення можливості обміну текстовими повідомленнями між 
користувачем, юристом, ментором. 
- логіка: відправка та отримання повідомлень, відображення чату в 
реальному часі. 
Компонент "Сторінки відгуків" (Reviews Page): 
- мета: відображення відгуків користувачів. 
- логіка: запит на сервер для отримання відгуків та рейтингів. відображення 
та обробка інформації. 
Компонент "Сторінка авторизації" (Authorize Page): 
- мета: забезпечення аутентифікації та реєстрації користувачів. 
- логіка: перевірка даних, відправка запитів на сервер для аутентифікації. 
Компоненти "Особисті кабінети" (User’s, Lawyer’s, Mentor’s Accounts): 
- мета: персоналізовані простори для різних категорій користувачів. 
- логіка: відображення та редагування особистої інформації, налаштувань, 
дій та їх наслідків. 
Компонент "Сторінка інформації для роботодавців" (Employer Page): 
- мета: представлення інформації для потенційних роботодавців та 
можливість зв'язку. 
- логіка: відображення інформації та обробка звернень. 
Цей опис логічної схеми відображає основні компоненти та їх взаємодію в 
клієнтській частині системи онлайн-платформи. 
 127 
4.1.4. Розробка бази даних 
 В даній частині роботі розробка бази даних не була спроектована, оскільки 
проектується в другій частині роботи - “Програмне забезпечення інформаційної 
системи безоплатної первинної правової допомоги: серверна частина”. 
4.1.5. Розробка інтерфейсу користувача 
Процес розробки інтерфейсу користувача (UI) для онлайн-платформи 
включив в себе ряд етапів та завдань, які були спрямовані на створення зручного та 
ефективного інтерфейсу для користувачів.  
Основні етапи включають: 
Дослідження та Аналіз: 
- вивчення цільової аудиторії та їх потреб. 
- аналіз аналогічних продуктів та конкурентів. 
- визначення функціональних та дизайнерських вимог. 
Прототипування: 
- створення скетчів або моделей інтерфейсу. 
- визначення основних елементів та їх розташування на сторінці. 
- розробка прототипу для тестування ідеї та концепції. 
Дизайн: 
- розробка графічного дизайну інтерфейсу. 
- вибір кольорової палітри та стилістики. 
- створення іконок, кнопок, шрифтів та інших графічних елементів. 
Верстка: 
- перенесення дизайну в код (html, css, іноді javascript). 
- створення розмітки та стилів для всіх елементів інтерфейсу. 
Анімація та Взаємодія: 
- додавання анімації та переходів для поліпшення взаємодії. 
- реалізація елементів взаємодії, таких як кнопки, форми, чати тощо. 
Тестування: 
 128 
- проведення тестів на різних пристроях і браузерах. 
- виявлення та виправлення помилок і недоліків в інтерфейсі. 
- забезпечення відповідності дизайну інтерфейсу зазначеним вимогам. 
Впровадження: 
- реліз версії інтерфейсу на виробництво або в мережу. 
- супровід та підтримка після випуску, вирішення можливих проблем. 
Оновлення та Покращення: 
- реакція на фідбек користувачів та оновлення інтерфейсу. 
- впровадження нових функцій та поліпшень. 
Процес розробки інтерфейсу користувача є ітеративним, і він може включати 
багато циклів удосконалення на основі змінених умов або фідбеку від користувачів. 
4.1.6. Опис розробки програмних компонентів 
Процес розробки клієнтської частини (Front-End) онлайн-платформи включає 
в себе кілька ключових етапів, в які входять різні завдання та процеси: 
Аналіз Вимог: 
- збір та аналіз вимог до інтерфейсу користувача. 
- визначення функціональності та основних завдань користувачів. 
Створення Дизайну: 
- розробка макетів інтерфейсу та дизайну за допомогою інструментів, таких 
як adobe xd, figma або sketch. 
- визначення структури сторінок та компонентів. 
Розробка HTML, CSS, та JavaScript: 
- написання html-розмітки для створення структури сторінок. 
- стилізація сторінок та компонентів за допомогою css. 
- використання javascript для реалізації динамічної взаємодії та 
функціональності. 
Використання Фреймворків та Бібліотек: 
- використання фреймворків, таких як react, angular, або vue.js для 
покращення організації та ефективності коду. 
 129 
- використання бібліотек, таких як bootstrap або material-ui, для швидкого 
оформлення та стилізації компонентів. 
Реалізація Взаємодії з Back-End: 
- взаємодія з серверною частиною за допомогою api-запитів. 
- обробка та відображення отриманих даних на сторінках. 
Тестування: 
- виконання тестів інтерфейсу на різних браузерах та пристроях. 
- виявлення та виправлення помилок та недоліків. 
Оптимізація та Перформанс: 
- оптимізація коду для підвищення швидкодії та продуктивності. 
- реалізація адаптивного дизайну для коректного відображення на різних 
пристроях. 
Розгортання: 
- внесення клієнтської частини на сервер або хмарну платформу. 
- перевірка стабільності та коректності розгортання. 
Підтримка та Оновлення: 
- супровід інтерфейсу та вирішення виявлених проблем. 
- випуск оновлень для додавання нових функцій та виправлення недоліків. 
Цей процес може варіюватися в залежності від конкретних вимог та 
технологій, використовуваних у проекті. 
4.2. Тестування системи 
4.2.1. Модульне тестування 
Опис модульного тестування для клієнтської частини (Front-End) нашої 
системи виглядає наступним чином: 
Назва тестового сценарію: Модульне тестування інтерфейсу чату 
Мета тестування: Перевірити правильність роботи інтерфейсу приватного 
чату між користувачами. 
Кроки тестування: 
 130 
1 Запуск інтерфейсу 
Переходимо до сторінки приватного чату. 
2 Відображення коректності елементів 
Перевіряємо, чи вірно відображаються елементи інтерфейсу чату, такі як поле 
для введення тексту, кнопка відправки повідомлення, список повідомлень та інші. 
3 Введення тексту 
Експериментально вводимо текстове повідомлення в поле введення та 
переконуємось, що введений текст коректно відображається. 
4 Відправка повідомлення 
Клацаємо на кнопці відправки повідомлення і перевіряємо, чи воно додається 
до списку повідомлень. 
5 Відображення вхідних повідомлень 
Впевнюємось, що вхідні повідомлення правильно відображаються в чаті. 
6 Взаємодія з іншим користувачем 
Пробуємо надіслати повідомлення та перевірямо, чи правильно воно 
відображаються для іншого користувача. 
7 Адаптивний дизайн 
Зменшуємо або збільшуємо розмір вікна браузера та переконуємося, що 
інтерфейс коректно реагує на зміни розміру екрану (адаптивний дизайн). 
8 Обробка помилок 
Штучно створюємо ситуацію, що може викликати помилки (наприклад, 
відключення мережі, помилкові запити) та перевіряємо, як система реагує на них. 
Отриманий результат: 
- всі елементи інтерфейсу працюють коректно та відповідають вимогам. 
- вхідні та вихідні повідомлення відображаються правильно. 
- система ефективно обробляє введений текст і реагує на дії користувача. 
- адаптивний дизайн пристосований до різних розмірів екрану. 
Такий сценарій тестування допомагає переконатися, що фронтенд частина 
системи працює коректно та відповідає функціональним вимогам. 
 131 
4.2.2. Інтеграційне тестування 
Назва тестового сценарію: Інтеграційне тестування чат-системи 
Мета тестування: Перевірити правильність взаємодії чат-системи з іншими 
компонентами та сервісами. 
Кроки тестування: 
1 Підготовка середовища: 
- заходимо у чат-систему та перевіряємо, чи всі внутрішні сервіси, необхідні 
для роботи, належним чином ініціалізуються. 
2 Інтеграція з сервером: 
- симулюємо обмін даними між клієнтом та сервером під час відправлення 
та отримання повідомлень.  
- переконуємось, що дані правильно передаються та обробляються. 
3 Інтеграція з базою даних: 
- здійснюємо взаємодію чат-системи з базою даних для збереження та 
отримання повідомлень.  
- перевіряємо коректність вставки, вилучення та оновлення даних. 
4 Взаємодія з іншими модулями: 
- переконуємося, що чат-система коректно взаємодіє з іншими модулями 
фронтенду, такими як авторизація, профіль користувача, та інші. 
5 Асинхронна взаємодія: 
- проводимо тест для перевірки асинхронної взаємодії системи, зокрема, 
здійснюємо одночасне відправлення повідомлень з різних вікон чату. 
6 Перевірка обробки помилок: 
- штучно провокуємо помилку, зокрема, втрату з'єднання, та перевіряємо, як 
система обробляє такі ситуації. 
7 Тестування під навантаженням: 
- запускаємо тести для перевірки реакції системи на велику кількість 
одночасних запитів і повідомлень. 
8 Отриманий результат: 
 132 
- інтеграція чат-системи з іншими компонентами пройшла успішно. 
- дані взаємодії з сервером та базою даних правильно обробляються. 
- взаємодія з іншими модулями фронтенду є стабільною та коректною. 
- система вірно реагує на асинхронні взаємодії та помилки. 
- під навантаженням система продовжує працювати стабільно та швидко. 
4.2.3. Системне тестування 
Назва тестового сценарію: Системне тестування клієнтської частини онлайн-
платформи 
Мета тестування: Перевірити функціональність, надійність та ефективність 
клієнтської частини системи. 
Кроки тестування: 
1 Тестування інтерфейсу користувача: 
- перевірив коректність та привабливість графічного інтерфейсу. 
- впевнився, що всі елементи інтерфейсу є інтуїтивно зрозумілими для 
користувача. 
- перевірив роботу всіх кнопок, полів вводу та інших елементів управління. 
2 Тестування функціональності: 
- переконався, що користувач може відправляти та отримувати 
повідомлення в чаті. 
- перевірив правильність відображення інформації про користувача та 
юриста в чаті. 
- впевнився, що система коректно реагує на всі можливі дії користувача. 
3 Тестування забезпечення безпеки: 
- перевірив, чи відбувається коректна обробка даних, що вводяться 
користувачем. 
- впевнився, що доступ до приватних чатів обмежений та вимагає 
аутентифікації. 
4 Тестування реакції на помилки: 
 133 
- штучно викликав помилку (зокрема, втрату з'єднання) та перевірив, як 
система реагує на них. 
5 Тестування продуктивності: 
- провів тести для перевірки швидкості відправлення та отримання 
повідомлень. 
- визначив, як система веде себе при великій кількості одночасних 
підключень. 
6 Отриманий результат: 
- графічний інтерфейс є зручним та естетично приємним. 
- всі функції клієнтської частини працюють коректно. 
- забезпечена висока рівень безпеки та конфіденційності. 
- система вірно реагує на помилки та продуктивно працює під 
навантаженням. 
4.2.4. Приймальне тестування 
Інструкції для тестування: 
1 Вхід в систему: 
- використовуючи власний email, увійшов в систему, як “Клієнт”. 
- перевірив, чи коректно відображається особистий кабінет “Клієнта”. 
2 Навігація: 
- переконався, що всі сторінки системи доступні з основного меню. 
- пройшов кожну сторінку та перевірив правильність відображення 
інформації. 
3 Чат: 
- запустив приватний чат з “Юристом”. 
- відправив та отримайте кілька повідомлень, переконався, що вони 
відображаються коректно. 
4 Функціональність: 
- перевірив кожну функцію, яку може використовувати користувач в чаті. 
- переконався, що можу завершити чат та вийти з системи. 
 134 
5 Адаптивність: 
- використовуючи різні пристрої (комп'ютер, планшет, смартфон), 
- перевірив, як гармонійно пристосовується система до різних розмірів 
екранів. 
6 Тестування безпеки: 
- спробував ввести некоректні дані  
- переконався, що вона реагує на них належним чином. 
Отриманий результат: 
- всі функції клієнтської частини працюють коректно та інтуїтивно. 
- система коректно взаємодіє з користувачем на різних пристроях. 
- безпека системи забезпечена, і вона вірно реагує на введення користувача 
та можливі помилки. 
Приклади впровадженого програмного комплексу показані в інструкції 
користувача (див.додатки). 
  
 135 
ВИСНОВКИ 
Виконуючи кваліфікаційну роботу магістра, було застосовано значну частину 
знань, здобутих в процесі навчання на освітньому ступені магістра.  
В процесі дослідження предметної області у вирішенні проблеми задоволення 
потреб населення у правовій допомозі та генерації досвіду молодих спеціалістів 
отримано висновок про існування протиріччя між високим рівнем попиту населення 
на юридичні консультації та низьким рівнем пропозицій щодо працевлаштування від 
роботодавців для підготовлених фахівців без практичного досвіду.  
В цій роботі запропоновано зменшити таке протиріччя, показано розробку 
інформаційної технології та відповідного їй програмного забезпечення. 
Розробка програмного забезпечення інформаційних систем правового 
обслуговування вимагає особливої технології розробки програмного забезпечення, 
яка грунтується на методі об’єктно-орієнтованого програмування. 
Результати досліджень показали необхідність удосконалення типового об’єктно 
орієнтованого програмування з розробки програмних систем для задоволення 
потреб населення у правовій допомозі та генерації досвіду молодих спеціалістів. 
В рамках роботи було проведено дослідження програмних систем 
комп’ютерно опосередкованої комунікації, призначених для надання інформаційної 
допомоги населенню та які можуть використовуватись для супутнього генерування 
досвіду молодих фахівців.  Було досліджено моделі та методи роботи програмної 
системи комп’ютерно опосередкованої комунікації з надання безоплатної первинної 
правової допомоги та генерування досвіду молодих фахівців (клієнтська частина). 
В рамках дослідження було: 1) досліджено способи створення програмного 
забезпечення інформаційної системи безоплатної первинної правової допомоги; 2) 
удосконалено метод об'єктно-орієнтованого програмування шляхом застосування 
структурно-функціонального підходу до розробки програмних систем із 
забезпечення юридичних послуг; 3) побудовано формальну модель та прототип 
програмного забезпечення інформаційної системи безоплатної первинної правової 
допомоги на основі створеної моделі. 
 136 
 Було удосконалено метод об'єктно-орієнтованого програмування шляхом 
застосування структурно-функціонального підходу до розробки програмних систем 
із забезпечення юридичних послуг. 
 Одержані результати досліджень можуть бути використані для вдосконалення 
процесу розробки програмного забезпечення систем юридичних послуг. Розроблене 
програмне забезпечення є основою для впровадження інформаційної системи 
безоплатної первинної правової допомоги. При доопрацюванні створеного 
програмного забезпечення розроблену систему можна використовувати для надання 
дистанційної первинної правової допомоги.  
 
 
  
 137 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1 Особливості процесу працевлаштування молоді на ринку праці :  (Електронний 
архів наукових та освітніх матеріалів КПІ ім. Ігоря Сікорського) [Електронний 
ресурс] / Л. С. Борданова, Н. В. Рощина // — С. 10. — Режим доступу: 
https://ela.kpi.ua/bitstream/123456789/18332/1/21Bordanova.pdf 
2 Трансформаційні процеси у суспільній та соціокультурній сферах України : 
(Монографія, Вінниця, ДонНУ, 2020) [Електронний ресурс] / О. М. Анісімова, Л. 
А.Ковальська, Г. П. Лукаш, О. В. Прігунов, О. С. Щербіна, Т. М. Яворська // — 
С. 176. — Режим доступу: http://195.34.206.236/bitstream/ 
123456789/1745/3/%d0%9c%d0%be%d0%bd%d0%be%d0%b3%d1%80%d0%b0%
d1%84%d1%96%d1%8f%2c%20%d0%92%d1%96%d0%bd%d0%bd%d0%b8%d1
%86%d1%8f%2c%20%d0%94%d0%be%d0%bd%d0%9d%d0%a3%2c%202020%2
c%20176%20%d1%81.-
%d0%90%d0%bd%d1%96%d1%81%d1%96%d0%bc%d0%be%d0%b2%d0%b0%2
c%20%d0%af%d0%b2%d0%be%d1%80%d1%81%d1%8c%d0%ba%d0%b0%20%d
0%a2.%d0%9c.%20%d1%82%d0%b0%20%d1%96%d0%bd%d1%88%d1%96..pdf 
3 Моделі і способи інтернет-консультування фахівців екстремальних видів 
діяльності : [Електронний ресурс] / Н. Є. Афанасьєва // Проблеми екстремальної 
та кризової психології. 2013. Вип. 13 — С. 9. — Режим 
доступу:https://r.donnu.edu.ua/bitstream/123456789/1755/1/%d0%9c%d0%be%d0%
b4%d0%b5%d0%bb%d1%96_%d1%96_%d1%81%d0%bf%d0%be%d1%81%d0%b
e%d0%b1%d0%b8_%d1%96%d0%bd%d1%82%d0%b5%d1%80%d0%bd%d0%b5
%d1%82-
%d0%ba%d0%be%d0%bd%d1%81%d1%83%d0%bb%d1%8c%d1%82%d1%83%d
0%b2%d0%b0%d0%bd%d0%bd%d1%8f.pdf  
4 Інтернет-консультування як нова технологія в психолого-педагогічній практиці : 
[Електронний ресурс] / І. А. Ясточкіна // — С. 7. — Режим доступу: 
https://enpuir.npu.edu.ua/bitstream/handle/123456789/25339/12.pdf?sequence=1&is
Allowed=y  
 138 
5 Досвід набутий в умовах пандемії covid-19 в період воєнного часу: 
телепсихіатрія : [Електронний ресурс] / А. М. Скрипніков, Д. І. Бойко, Л. А. 
Боднар // Полтавський державний медичний університет, м. Полтава  — С. 3. — 
Режим доступу: http://repository.pdmu.edu.ua/bitstream/123456789/18934/ 
1/Skripnikov_Dosvid.pdf  
6 Можливості дистанційного консультування в утруднених умовах життя : 
[Електронний ресурс] / С. І. Яковенко , Т. С. Гурлєва //  Актуальні проблеми 
психології, збірник наукових праць Інституту психології імені Г.С.Костюка 
НАПН України, том 14, випуск 3, Київ - Ніжин, 2020 — С. 357. — Режим 
доступу: https://lib.iitta.gov.ua/721736/1/zbirka_14_3_print%20(1).pdf#page=357  
7 Створення веб-форуму при використанні сучасних технологій веб-розробки : 
[Електронний ресурс] / Т. В. Холявкіна, Я. О. Резаєв, О. О. Харченко // НАУ, 
Проблеми інформатизації та управління, збірник наукових праць, 1(73)/2023 — 
Режим доступу: https://jrnl.nau.edu.ua/index.php/PIU  
8 Інтернет портал ТОВ «Робота Інтернешнл» © 2023 [Електронний ресурс]  Режим 
доступу: https://robota.ua/ukraine  
9 Google-сервіс [Електронний ресурс] Режим доступу: https://trends.google.com/   
10 Правила адвокатської етики : за станом на 21 листоп. 2023 р. / З'їзд адвокатів 
України. — 16 с. — [Електронний ресурс] Режим доступу: 
https://zakon.rada.gov.ua/rada/show/n0001891-17 . 
11 Закон України “Про захист персональних даних” : за станом на 21 листоп. 2023 
р. / Відомості Верховної Ради України, офіційне видання — 2010 р., № 34, стор. 
— 1188 с —  стаття 481. 
12 Цивільний кодекс України : за станом на 21 листоп. 2023 р. / Відомості Верховної 
Ради України, офіційне видання — 2003 р., № 40, стаття 356 
13 Закон України «Про національну програму інформатизації» від 04.02.1998 р. № 
74/98-ВР, Офіційний вісник України, офіційне видання — 2023 р., № 2, стор. 132, 
стаття 86, код акта 115711/2022 
 139 
14 Управління інформаційними технологіями в організаціях (Governance of IT for 
the organization) : ISO/IEC 38500:2015. – (Міжнародний стандарт). – 
[Електронний ресурс] Режим доступу : https://www.iso.org/obp/ui/#iso:std:iso-
iec:38500:ed-2:v1:en 
 
  
 140 
ДОДАТОК А 
 
ЗАТВЕРДЖЕНО: 
Зав. кафедрою ПЗАС, професор 
 Голуб С.В. 
„ ”  2023 р. 
 
 
 
 
 
 
Програмне забезпечення інформаційної системи безоплатної первинної 
правової допомоги: клієнтська частина 
 
 
 
 
 
 
Специфікація 
482.ЧДТУ.232224-01 
Листів 1 
 
 
 
Розробник   Шамов О.А. 
Керівник   Заспа Г.О. 
 
 
 
 
Черкаси 2023 
 141 
482.ЧДТУ.232224-01 2 
 
 
 
Позначення Найменування Примітка 
482.ЧДТУ 232224-12 01 Текст програми  
482.ЧДТУ 232224-34 01 Інструкція користувача  
482.ЧДТУ 232224-90 01 Графічний матеріал  
   
   
   
   
   
   
   
   
   
   
   
   
 142 
 
 
ДОДАТОК Б 
 
 
 
 
 
 
 
 
 
Програмне забезпечення інформаційної системи безоплатної первинної 
правової допомоги: клієнтська частина 
 
 
 
 
 
 
482.ЧДТУ 232224-12 01 
Текст програми 
Листів 7 
 
 
 
 
 
 
Розробник   Шамов О.А. 
 
 
 
Черкаси 2023 
 143 
 482.ЧДТУ 232224-12 01 2 
 
 ТЕКСТ ПРОГРАМИ 
Вміст файлу index.html : 
 
<!DOCTYPE html> 
<html lang="en" class="page"> 
<head> 
<meta charset="UTF-8"> 
<meta name="viewport" content="width=device-width, 
initial-scale=1.0"> 
<title>Юрист онлайн</title> 
<link rel="icon" type="image/x-icon" 
href="./images/favicon.png"> 
<link rel="preconnect" 
href="https://fonts.googleapis.com"> 
<link rel="preconnect" href="https://fonts.gstatic.com" 
crossorigin> 
<link 
href="https://fonts.googleapis.com/css2?family=Montserrat 
+Alternates:wght@100;200;300;400;500;700&family=Montserra 
t:wght@100;200;300;400;500;700&display=swap" 
rel="stylesheet"> 
<link rel="stylesheet" href="./styles/style.css"> 
</head> 
<body class="page body"> 
<header class="header"> 
<div class="top-bar menu top"> 
<div class="top-bar logotitle"> 
<a href="#" class="top-bar logo"> 
<img 
class="header logo" 
src="./images/logo.png" 
alt="logo"> 
</a> 
<p class="top-bar title">Юрист<br>онлайн</p> 
</div> 
 
<a href="../src/pages/menu.html#menu" class="icon 
icon--menu"></a> 
</div> 
</header> 
 144 
<form action="" class="main form"> 
482.ЧДТУ 232224-12 01 3 
<legend>Щоб задати питання юристу:</legend> 
<input 
type="email" 
placeholder="Вкажи свою електронну пошту" 
class="main input" 
> 
<legend>Ми надішлемо посилання на<br>вхід за 
вказаною адресою</legend> 
</form> 
<a href="../src/pages/customer.html" 
class="main button">Отримати посилання</a> 
</div> 
<div class="main presentation"> 
<h2 class="main presentation--title">Популярні 
запитання</h2> 
 
<article class="main presentation--article"> 
<p class="main presentation--order">1</p> 
<div class="main presentation--textBlock"> 
<h3>Навіщо цей сервіс?</h3> 
<p class="main presentation--text">Це доступ 
до безоплатних юридичних консультацій</p> 
</div> 
</article> 
 
<article class="main presentation--article"> 
<p class="main presentation--order">2</p> 
<div class="main presentation--textBlock"> 
<h3>Хто мене консультує?</h3> 
<p class="main presentation--text">Молоді 
юристи, які прагнуть бути найкращими</p> 
</div> 
</article> 
 
<article class="main presentation--article"> 
<p class="main presentation--order">3</p> 
<div class="main presentation--textBlock"> 
<h3>Хто контролює якість?</h3> 
 
<p class="main presentation--text">Досвідчені наставники 
завжди поруч</p> 
 145 
 
482.ЧДТУ 232224-12 01 4 
</div> 
</article> 
<article class="main presentation--article"> 
<p class="main   presentation--order">4</p> 
<div class="main   presentation--textBlock"> 
<h3>Ви бережете таємниці?</h3> 
<p class="main presentation--text">Розмови з 
юристом тільки в приватному чаті. Навіть твоє відвідування 
платформи - це таємниця.</p> 
</div> 
</article> 
<article class="main   presentation--article"> 
<p class="main   presentation--order">5</p> 
<div class="main   presentation--textBlock"> 
<h3>Чому це безкоштовно?</h3> 
<p class="main presentation--text">Твій 
інтерес - вирішити власну проблему; інтерес юриста - набути 
більше досвіду. У виграші обидва.</p> 
</div> 
</article> 
 
<article class="main presentation--article"> 
<p class="main presentation--order">6</p> 
<div class="main presentation--textBlock"> 
<h3>Реєстрація складна?</h3> 
<p class="main presentation--text">Легка. 
Вкажи електронну пошту і не потрібно нових паролів.</p> 
</div> 
</article> 
<br> 
<br> 
<h2>Про нас</h2> 
<br> 
<p> 
Тут люди отримують простий доступ до безкоштовної 
первинної правової допомоги незалежно від місця їх 
знаходження. 
<br> 
<br> 
Юристи накопичують досвід, реалізують професійний 
інтерес. 
 146 
 
482.ЧДТУ 232224-12 01 5 
<br> 
<br> 
До роботи платформи долучаються досвідчені 
наставники. Вони контролюють якість сервісу і за запитом 
відвідувача роблять рецензії на консультації. 
</p> 
<br> 
<br> 
<h2>Наші історії</h2> 
<br> 
<p> 
<h3>Вадим</h3>Дипломований юрист, та це лиш 
частина його життя. Він любить скейтборд і шахи. А ще мріє 
виступити на міжнародному юридичному форумі. 
</p> 
<br> 
<p> 
<h3>Катерина</h3>Була найкращою на юридичному 
факультеті, але їй не вистачало досвіду живого спілкування 
з реальними людьми та їх питаннями з права. Тепер цього 
спілкування аж занадто багато ;) 
</p> 
<br> 
<p> 
<h3>Дмитро</h3>Не вірив, що юридична справа для 
нього. Дмитро любить ранкові пробіжки і комп'ютерні ігри. Та 
саме його ідеї кілька разів рятували людину від юридичної 
катастрофи. 
</p> 
<br> 
<p> 
<h3>Володимир</h3>Десять років провів в судових 
баталіях, а тепер відчуває внутрішню потребу ділитись 
досвідом з молодшими колегами. Та не розрахував, що наша 
молодь може бути гіпер-допитливою ;) 
</p> 
<br> 
<p> 
Ми всі різні і прийшли сюди випадково, але залишились і 
полюбили це місце. Тут перетинаються долі людей, і щодня 
відбувається пошук справедливості! 
/p> 
</div> 
 147 
 
482.ЧДТУ 232224-12 01 6 
<  </main> 
<footer></footer> 
</body> 
</html> 
 
Вміст файлу style.css : 
 
@import "variables.css"; 
@import "page.css"; 
@import "menu.css"; 
@import "top-bar.css"; 
@import "icon.css"; 
@import "main.css"; 
@import "nav.css"; 
@import "customer.css"; 
 
* { 
margin: 0; 
transition: 0.3s; 
} 
 
.header block { 
display: flex; 
justify-content: space-between; 
} 
 
legend { 
font-size: 12px; 
line-height: normal; 
text-align: center; 
} 
 
input[type=checkbox] { 
margin: 4px 0 0; 
line-height: normal; 
width: 20px; 
height: 20px; 
} 
.page-container { 
padding: 0 20px 20px; 
 148 
 
482.ЧДТУ 232224-12 01 7 
} 
.rating { 
unicode-bidi: bidi-override; 
direction: rtl; 
} 
.rating > span { 
display: inline-block; 
position: relative; 
width: 1.1em; 
} 
 
.rating > span:hover:before, 
.rating > span:hover ~ span:before { 
content: "\2605"; 
position: absolute; 
} 
 149 
 
ДОДАТОК В 
 
 
 
 
 
 
 
 
Програмне забезпечення інформаційної системи безоплатної первинної 
правової допомоги: клієнтська частина 
 
 
 
 
 
 
482.ЧДТУ 232224-34 01 
Інструкція користувача 
Листів 6 
 
 
 
 
 
 
Розробник   Шамов О.А. 
 
 
 
 
 
 
 
 
Черкаси 2023 
 150 
 
482.ЧДТУ 232224-34 01 2 
1. Перед вами інформаційна система, яка забезпечує опосередковану 
комунікацію з фахівцями у галузі юриспруденції. Тут можна отримати 
консультацію юриста у текстовому вигляді а також, у разі необхідності, отримати 
рецензію наставника на консультацію відповідного юриста. 
2. Для входу в систему необхідно пройти авторизацію за допомогою наявної 
в тебе електронної пошти. Достатньо ввести адресу електронної пошти у відповідне 
поле на головній сторінці, що система запам’ятала ваас і автоматично 
перенаправила на сторінку користувача, де ви можете задати юристу своє 
запитання. 
3. Якщо ви вже проходили реєстрацію в системі і згодом знову хочете увійти 
в систему, процес авторизації залишається тим же: введіть адресу електронної 
пошти в спеціальне поле на головній сторінці та отримайте посилання на вхід у 
своїх вхідних повідомленнях. Це дозволяє не вигудувати і не тримати в пам’яті ще 
один пароль до ще одного вашого акаунту. 
4. Можна довірити системі обрати будь-якого вільного юриста для відповіді 
на запитання клієнта, або доручити відповідь конкретному юристу. Для цього у 
відповідному полі введіть службовий id такого юриста. Цей id можна знайти у 
списку юристів на окремій сторінці платформи. Також цей id відображається біля 
будь-якої відповіді такого юриста, в тому числі біля відповідей цього юриста на 
ваші минулі запитання. Перелік ваших минулих запитань доступний в нижній 
частині кабінету користувача. 
5. Коли на сторінці користувача ви ввели запитання, натисніть кнопку 
“Надіслати” і система перенаправить вас на сторінку приватного чату з 
відповідним юристом. 
6. Є можливість очікувати відповідь на цій сторінці, або зайти сюди пізніше з 
особистого кабінету користувача, обравши запитання серед архіву ваших запитань 
в нижній частині кабінету користувача. 
7. Юристи намагаються відповідати на запитання якомога швидше. Коли 
побачите відповідь юриста і матимете уточнюючі запитання, натисніть кнопку 
 151 
 
482.ЧДТУ 232224-34 01 3 
“Задати ще запитання” і введіть його у відповідне поле, натисніть “Відправити”. 
Юрист надасть відповідь. 
8. Якщо відповідь юриста, на думку клієнта потрібно перевірити на 
коректність, є можливість замовити рецензію наставника (ментора). Для цього на 
сторінці приватного чату натисніть кнопку “Отримати рецензію ментора”. 
Ментори намагаються швидко надавати рецензії. 
9. Якщо після відповідей юриста/ментора, ви більше не маєте запитань, 
натисніть кнопку “Завершити чат” або можна просто покинути сторінку. 
10. Перед завершенням чату є можливість поставити оцінку юристу (рейтинг 
з п’яти зірочок) а також залишити тектовий відгук у полі, що пропонується тут же 
на сторінці приватного чату. Це дозволяє краще оцінювати як роботу кожного 
окремого юриста, так і платформи в цілому. 
11. Нижче показано скріншоти використання програми та загальний принцип 
взаємодії учасників: 
 152 
 
482.ЧДТУ 232224-34 01 4 
 
 
 
 
Рисунок В.1. — Взаємодія Клієнта з програмою та послідовність кроків програми 
 153 
 
482.ЧДТУ 232224-34 01 5 
 
 
 
 
Рисунок В.2. — Взаємодія Юриста з програмою для реагування на запитання 
Клієнта 
 154 
 
482.ЧДТУ 232224-34 01 6 
 
 
 
Рисунок В.3. — Послідовність дій Клієнта й Юриста та послідовність кроків 
програми 
 155 
 
ДОДАТОК Г 
Програмне забезпечення інформаційної системи безоплатної первинної 
правової допомоги: клієнтська частина 
 
 
 
 
 
 
482.ЧДТУ 232224-90 01 
Графічні матеріали 
Листів 13 
 
 
 
 
 
 
 
 
 
 
 
 
Розробник   Шамов О.А. 
 
 
 
 
 
Черкаси 2023 
 156 
 
482.ЧДТУ 232224-90 01 2 
 
 
 
 
 
 
 
 
 
Рисунок Г.1.Слайд 1. — Мета досліджень 
 
 
 
 
Рисунок Г.2.Слайд 2. — Завдання досліджень 
 157 
 
482.ЧДТУ 232224-90 01 3 
 
 
 
 
 
 
Рисунок Г.3.Слайд 3. — Задача структурної ідентифікації 1/3 
 
 
 
 
 
 
 
Рисунок Г.4.Слайд 4. — Задача структурної ідентифікації 2/3 
 158 
 
482.ЧДТУ 232224-90 01 4 
 
 
 
 
 
 
Рисунок Г.5.Слайд 5. — Задача структурної ідентифікації 3/3 
 
 
 
 
 
Рисунок Г.6.Слайд 6. — Аналіз потреб цільової аудиторії 1/3 
 159 
 
482.ЧДТУ 232224-90 01 5 
 
 
 
 
 
 
Рисунок Г.7.Слайд 7. — Аналіз потреб цільової аудиторії 2/3 
 
 
 
 
 
Рисунок Г.8.Слайд 8. — Аналіз потреб цільової аудиторії 3/3 
 160 
 
482.ЧДТУ 232224-90 01 6 
 
 
 
 
 
Рисунок Г.9.Слайд 9. — Схема інформаційної системи 
 
 
 
Рисунок Г.10.Слайд 10. — Моделювання предметної області (UML) 1/10 
 161 
 
482.ЧДТУ 232224-90 01 7 
 
 
 
 
Рисунок Г.11.Слайд 11. — Моделювання предметної області (UML) 2/10 
 
 
 
 
Рисунок Г.12.Слайд 12. — Моделювання предметної області (UML) 3/10 
 162 
 
482.ЧДТУ 232224-90 01 8 
 
 
 
 
 
 
Рисунок Г.13.Слайд 13. — Моделювання предметної області (UML) 4/10 
 
 
Рисунок Г.14.Слайд 14. — Моделювання предметної області (UML) 5/10 
 163 
 
482.ЧДТУ 232224-90 01 9 
 
 
 
 
Рисунок Г.15.Слайд 15. — Моделювання предметної області (UML) 6/10 
 
 
 
Рисунок Г.16.Слайд 16. — Моделювання предметної області (UML) 7/10 
 164 
 
482.ЧДТУ 232224-90 01 10 
 
 
 
 
Рисунок Г.17.Слайд 17. — Моделювання предметної області (UML) 8/10 
 
 
 
 
 
Рисунок Г.18.Слайд 18. — Моделювання предметної області (UML) 9/10 
 165 
 
482.ЧДТУ 232224-90 01 11 
 
 
Рисунок Г.19.Слайд 19. — Моделювання предметної області (UML) 9/10 
 
 
 
 
 
 
 
Рисунок Г.20.Слайд 20. — Розробка програмного забезпечення 
 166 
 
482.ЧДТУ 232224-90 01 12 
 
 
 
 
 
Рисунок Г.21.Слайд 21. — Розробка інтерфейсу користувача 1/3 
 
 
 
 
 
 
 
Рисунок Г.22.Слайд 22. — Розробка інтерфейсу користувача 2/3 
 167 
 
 
 
 
Рисунок Г.23.Слайд 23. — Розробка інтерфейсу користувача 3/3
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
