Репозиторій ЧДТУ

 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
бакалавра 
 
 
на тему:  Розробка WEB–сайту Звенигородської районної федерації футболу 
 
 
Виконав: студент 4 курсу, групи ПЗС–2144 
спеціальності  
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
 
Студент Кравець В. В. 
 (прізвище та ініціали) 
Керівник  Немов Р. Г. 
 (прізвище та ініціали) 
Рецензент   
 (прізвище та ініціали) 
 
 
 
Черкаси 2024 
 
Черкаський державний технологічний університет 
повне найменування вищого навчального закладу 
Факультет інформаційних технологій і систем 
Кафедра  програмного забезпечення автоматизованих систем 
Освітній рівень бакалавр 
Спеціальність 121 «Інженерія програмного забезпечення» 
Освітня програма Інженерія програмного забезпечення 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
____________________ С. Голуб  
«___» _______________ 2024 року 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
Кравець Владислав Володимирович 
(прізвище, ім’я, по батькові) 
1. Тему проекту Розробка WEB–сайту Звенигородської районної федерації футболу 
Керівник проекту Немов Руслан Григорович асистент 
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від «26» лютого 2024 року №60/04 
2. Строк подання студентом проекту (роботи)    03 червня 2024 
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління; вимоги до 
проекту; календарне планування проекту; управління ризиками проекту; управління ресурсами 
4. Зміст розрахунково–пояснювальної записки (перелік питань, які потрібно розробити) Вступ; 
Існуючі методи та засоби розв’язання поставлених завдань; 
Впровадження результатів дослідження у практику проетування програмного забезпечення інформаційних 
систем; 
Розробка та тестування програмного забезпечення; 
Висновки; 
Список використаних джерел; 
Додатки. 
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту; 
Слайд 1; Слайд 2; Слайд 3; Слайд 4; Слайд 5; Слайд 6; Слайд 7; Слайд 8; Слайд 9; Слайд 10; Слайд 11; Слайд 
12; Слайд 13; Слайд 14; Слайд 15; 
 
6. Консультанти розділів роботи 
Прізвище, ініціали та посади Підпис, дата 
Розділ 
консультанта Завдання видав Завдання прийняв 
1    
2    
3    
 
7. Дата видачі завдання 02 грудня 2023 р. 
 
  
ЧДТУ.242240 006 ПЗ 
 
ЗМІСТ 
ВСТУП ............................................................................................................... 6 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ ............................................................................... 10 
1.1 Актуальність розробки WEB–сайту для спортивних федерацій ............ 10 
1.2 Аналіз існуючих WEB–сайтів спортивних федерацій ............................. 11 
1.2.1 FIFA (Fédération Internationale de Football Association) ......................... 11 
1.2.2 UEFA (Union of European Football Associations) ................................ 12 
1.2.3 MLS (Major League Soccer) ................................................................... 12 
1.2.4 NBA (National Basketball Association) ................................................. 13 
1.2.5 Tennis Australia ....................................................................................... 14 
1.3 Використання готових CMS для спортивних сайтів ................................ 14 
ВИСНОВКИ ДО 1 РОЗДІЛУ ............................................................................ 19 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕННЯ У 
ПРАКТИКУ ПРОЕТУВА ННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ ............................................................................ 20 
2.1 Моделювання предметної області .............................................................. 20 
2.1.1 Предметна область моделювання. Модель предметної області. 
 
Словник предметної області .......................................................................... 21 
2.1.2 Елемента моделювання предметної області .................................... 23 
2.1.3 Робоча область моделювання ........................................................... 25 
2.2 Формування та аналіз вимог ....................................................................... 26 
2.2.1 Формування вимог до програмного забезпечення ................................ 26 
2.2.2 Діаграма прецедентів для розробки WEB–сайту Звенигородської 
районної федерації футболу .......................................................................... 29 
2.3 Проектування логічної структури програмного комплексу .................... 31 
2.3.1 Діаграми класів ...................................................................................... 31 
2.4 Архітектурне проектування ........................................................................ 34 
2.4.1 Діаграма компонентів ............................................................................ 34 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання ...................................................................................................... 35 
   
ЧДТУ 242240.006ПЗ 
Зм. Лист № документа Підпис Дата 
Р озроб. Кравець В. В. Розробка WEB–сайту Звенигородської Літ. Лист Листів 
Керівник Немов Р. Г. районної федерації футболу 20 2 114 
Пояснювальна записка  ФІТІС, 
Н.контр. Півень О . Б. 
 Голуб С. В. Кафедра ПЗАС, ПЗ–2134 4 
Затв.
ЧДТУ.242240 006 ПЗ 
2.5 Моделювання поведінки системи .............................................................. 36 
2.5.1 Діаграма діяльності ................................................................................ 36 
2.5.2 Діаграма послідовності ......................................................................... 37 
2.5.3 Діаграма комунікації ............................................................................. 39 
2.5.4 Діаграма скінченого автомату .............................................................. 41 
ВИСНОВКИ ДО 2 РОЗДІЛУ ............................................................................ 43 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
 ................................................................................................................................. 44 
3.1 Розробка програмного комплексу .............................................................. 44 
3.1.1 Обгрунтування вибору засобів реалізації ........................................ 44 
3.1.2 Опис структурної (функціональної) схеми ......................................... 47 
3.1.3 Опис логічної схеми системи ............................................................... 50 
3.1.4 Розробка бази даних .............................................................................. 51 
3.1.5 Розробка інтерфейсу користувача ........................................................ 58 
3.1.6 Опис розробки прогр амних компонентів ............................................ 61 
3.2 Тестування системи .................................................................................. 64 
 
3.2.1 Модульне тестування ............................................................................ 64 
3.2.2 Інтеграційне тестування ........................................................................ 70 
3.2.3 Системне тестування ............................................................................. 73 
3.2.4 Приймальне тестування ........................................................................ 76 
3.3 Приклади впровадження програмного комплексу ................................... 79 
ВИСНОВКИ ДО 3 РОЗДІЛУ ............................................................................ 83 
ВИСНОВКИ ........................................................................................................... 84 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ............................................................. 85 
ДОДАТОК А .......................................................................................................... 87 
ДОДАТОК Б .......................................................................................................... 89 
ДОДАТОК В .......................................................................................................... 90 
ДОДАТОК Г ........................................................................................................ 106 
 
  
 
 
ЧДТУ 242240.006ПЗ 
Зм. Лист № документа Підпис Дата 
    
    
  
4 
ЧДТУ.242240 006 ПЗ 
ПЕРЕЛІК УМОВНИХ ПОЗНАЧЕНЬ 
 
CMS      – Система управління контентом. 
UML     – Уніфікована мова моделювання. 
API      – Інтерфейс програмування застосунків. 
SQL      – Мова структурованих запитів. 
UI       – Інтерфейс користувача. 
UX      – Враження користувача. 
SSL      – Протокол безпеки рівня транспорту. 
HTML     – Мова розмітки гіпертексту. 
CSS      – Каскадні таблиці стилів. 
JavaScript    – Мова програмування для WEB–розробки. 
Backend   – Частина WEB–сайту, відповідальна за логіку та 
обробку даних. 
Frontend   – Частина WEB–сайту, яку бачить та взаємодіє з 
користувачем. 
Database   –  База даних, де зберігається інформація для WEB–                     
сайту. 
WEB–сайт   –    Електронний ресурс, доступний через мережу 
Інтернет, який містить інформацію та функціональність 
для користувачів. 
 
  
5 
ЧДТУ.242240 006 ПЗ 
ВСТУП 
В нинішньому світі інформаційних технологій роль WEB–сайтів стає 
надзвичайно важливою для забезпечення ефективної взаємодії та комунікації 
в різних сферах діяльності. У цьому контексті особливо актуальною задачею є 
створення WEB–простору для Звенигородської районної федерації футболу – 
невід'ємної частини спортивного життя громади. 
Ця кваліфікаційна робота бакалавра присвячена розробці та створенню 
WEB–сайту для Звенигородської районної федерації футболу, що має на меті 
об'єднати всі зацікавлені сторони та створити віртуальний простір для 
ефективної взаємодії та обміну інформацією. 
Цей WEB–сайт буде не лише візитною карткою федерації, але й зручним 
інструментом для всіх, хто цікавиться футболом на Звенигородщині. 
Відновлюючи та удосконалюючи традиційні функції WEB–простору, ми 
плануємо впроваджувати інноваційні рішення для надання комплексного та 
інформативного обслуговування. 
В рамках цього проекту планується реалізація різноманітних розділів на 
WEB–сайті, які будуть включати інформацію про турніри, найсвіжіші новини, 
фотографії подій та інші цікаві матеріали. Зручна навігація та інтуїтивно 
зрозумілі розділи сприятимуть легкому отриманню необхідної інформації для 
кожного користувача. 
Однією з ключових проблем, що виникає у контексті розробки WEB–
сайту для футбольної федерації, є необхідність створення ефективного 
інформаційного центру для гравців, вболівальників та адміністраторів. 
Актуальність полягає в створенні програмного забезпечення, яке надасть 
широкий спектр інформації, включаючи турнірну статистику, останні новини, 
галереї фотографій та інші важливі дані для розвитку та популяризації 
футбольного руху в Звенигородському районі. 
У сучасному цифровому світі, де доступ до інформації є необхідністю, 
WEB–сайт стає важливим інструментом для спортивних федерацій. Він 
виступає як платформа для комунікації з гравцями, вболівальниками та 
6 
ЧДТУ.242240 006 ПЗ 
адміністраторами, а також як джерело актуальних новин і статистики. 
Розробка такого WEB–сайту потребує комплексного підходу та використання 
ефективних методів та засобів. 
Метою даної роботи є створення програмного забезпечення, яке стане 
центральним пунктом комунікації та інформації для всіх учасників 
футбольного співтовариства в Звенигородському районі. 
Об’єктом розробки є технології побудови web–сайтів спортивних 
організацій. 
Предметом розробки є програмне забезпечення, яке забезпечить 
функціонування WEB–сайту для Звенигородської районної федерації 
футболу. 
Область застосування та практичне значення одержаних 
результатів полягає у тому, що web–сайт може використовуватися 
організаторами, гравцями і вболівальниками футбольних заходів у 
Звенигородському районі. 
Основні аспекти проекту:  
1  Взаємодія та комунікація: покращення комунікації між гравцями, 
тренерами, вболівальниками та адміністрацією федерації.  
2    Інформаційна підтримка: забезпечення легкого доступу до актуальної 
інформації про турніри, новини та інші події.  
3  Популяризація спорту: сприяння розвитку футбольної культури та 
залучення нових учасників до спортивного життя регіону.  
4  Оптимізація управління: покращення управління федерацією через 
ефективну організацію турнірів та ведення статистики.  
5 Технологічний прогрес: використання сучасних технологій для 
забезпечення якісної та інноваційної інформаційної платформи. 
Завдання розробки WEB–сайту: 
Основними завданнями є: 
 огляд аналогових систем; 
 аналіз сильних і слабких сторін наявних аналогових систем; 
7 
ЧДТУ.242240 006 ПЗ 
 опис загальних і функціональних вимог до системи; 
 побудова та опис UML–діаграми для сайту Федерації футболу 
Звенигородського району; 
 вибір мови опису: переваги та недоліки; 
 розробка та реалізація бази даних системи; 
 розробка програмних продуктів; 
 проведення тестів; 
 пояснення результатів розробки. 
Web–сайт Звенигородської районної федерації футболу повинен мати 
інтуїтивно–зрозумілий інтерфейс, який дозволить легко знаходити і 
модифікувати необхідну користувачу інформацію. 
Методи проектування та конструювання які були використані в процесі 
розробки WEB–сайту для Звенигородської районної федерації футболу: 
1  Аналіз потреб користувачів: цей метод дозволив з'ясувати 
очікування та вимоги потенційних користувачів щодо функціоналу та дизайну 
WEB–сайту. 
2  Прототипування: створення прототипів WEB–сайту допомогло у 
визначенні основних функцій та інтерфейсу користувача перед фактичною 
розробкою. 
3  Використання UML–діаграм: UML–діаграми були використані для 
візуалізації структури та взаємозв'язків між різними компонентами системи. 
4  Розробка бази даних: для зберігання та управління інформацією на 
WEB–сайті була розроблена та впроваджена база даних. 
5  Тестування: проведення тестів дозволило виявити та виправити 
помилки та недоліки в роботі WEB–сайту перед його запуском. 
Опис отриманих результатів є створення функціонального та інтуїтивно 
зрозумілого WEB–сайту для Звенигородської районної федерації футболу. 
Сайт містить розділи з інформацією про турніри, останні новини, фотографії 
подій та інші цікаві матеріали. Також реалізовано інформаційний центр для 
8 
ЧДТУ.242240 006 ПЗ 
гравців, вболівальників та адміністраторів, що надає широкий спектр 
інформації про турнірну статистику, останні новини та галереї фотографій. 
Практичне значення отриманих результатів полягає у створеному 
програмному забезпеченні, який має реальний вплив на футбольне 
співтовариство Звенигородського району. Це допомагає покращити 
спілкування між гравцями, тренерами, уболівальниками та керівництвом 
асоціації. Крім того сайте забезпечує отримання доступу до актуальної 
інформації про турніри, новини та інші події, допомагаючи просувати 
місцевий футбольний рух і залучати нових учасників. 
Особистий внесок автора цієї кваліфікаційної роботи бакалавра:  
 проведення аналізу аналогів та потребу користувачів; 
 розробив прототип WEB–сайту; 
 спроектував базу даних; 
 реалізував програмний код та провів тестування функціоналу.  
Крім того, автор забезпечив опис отриманих результатів та їх практичне 
значення для футбольного співтовариству Звенигородського району. 
Бакалаврська робота складається із вступу, 3 розділів, висновків, списку 
використаної літератури (найменувань). Робота містить 44 рисунки і 5 
таблиць. Роботу викладено на 114 сторінках друкованого тексту.   
  
9 
ЧДТУ.242240 006 ПЗ 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
В сучасному інформаційному середовищі, розробка WEB–сайту для 
спортивної федерації стає актуальною задачею, вимагаючи комплексного 
підходу та використання ефективних методів та засобів. Для аналізу цього 
питання, було проведено широкий огляд наукової та технічної інформації, 
включаючи наукові статті, підручники, технічні документації та Інтернет–
ресурси. 
1.1 Актуальність розробки WEB–сайту для спортивних федерацій 
Однією з ключових проблем, що виникає у контексті розробки WEB–
сайту для футбольної федерації, є необхідність створення ефективного 
інформаційного центру для гравців, вболівальників та адміністраторів. 
Актуальність полягає в потребі надання широкого спектру інформації, 
включаючи турнірну статистику, останні новини, галереї фотографій та інші 
важливі дані для розвитку та популяризації футбольного руху в 
Звенигородському районі. 
У сучасному цифровому світі, де доступ до інформації є необхідністю, 
WEB–сайт стає важливим інструментом для спортивних федерацій. Він 
виступає як платформа для комунікації з гравцями, вболівальниками та 
адміністраторами, а також як джерело актуальних новин і статистики. 
Розробка такого WEB–сайту потребує комплексного підходу та використання 
ефективних методів та засобів. 
Для проведення аналізу проблеми розробки WEB–сайту для спортивної 
федерації був здійснений широкий розбір наукових та технічних джерел 
інформації. Було вивчено наукові статті, підручники, монографії, технічні 
документації та Інтернет–ресурси, що дозволило отримати повну картину про 
актуальні методи та засоби розв’язання поставлених завдань. 
 
10 
ЧДТУ.242240 006 ПЗ 
1.2 Аналіз існуючих WEB–сайтів спортивних федерацій 
Проведений аналіз існуючих WEB–сайтів спортивних федерацій виявив 
широкий спектр підходів та різний рівень функціональності. Декілька 
визначених проектів відображають різні аспекти та тенденції у цій галузі. 
1.2.1 FIFA (Fédération Internationale de Football Association) 
 
 
Рисунок 1.1 – Вигляд сайту Fifa.com[1] 
 
Особливості: 
 широкий функціонал, охоплюючий всі аспекти світового футболу; 
 інтерактивна карта подій, що дозволяє користувачам слідкувати за 
матчами у режимі реального часу; 
11 
ЧДТУ.242240 006 ПЗ 
 велика кількість мультимедійного контенту: відео, фотографії, 
інтерв'ю. 
1.2.2 UEFA (Union of European Football Associations) 
 
 
Рисунок 1.2 – Вигляд сайту UEFA.com[2] 
 
Особливості: 
 спеціалізовані розділи для кожного чемпіонату та країни–учасниці; 
 інтерактивні графіки та статистика для кожного матчу; 
 онлайн–трансляції та архів відеоматеріалів. 
1.2.3 MLS (Major League Soccer) 
 
 
Рисунок 1.3 – Вигляд сайту MLSsoccer.com[3] 
12 
ЧДТУ.242240 006 ПЗ 
Особливості: 
 спрощений та лаконічний дизайн для зручності користувачів; 
 зосередженість на новинах, ігрових статистиках та взаємодії з 
командами; 
 можливість купівлі квитків та перегляду онлайн–трансляцій. 
1.2.4 NBA (National Basketball Association) 
 
 
Рисунок 1.4 – Вигляд сайту NBA.corr [4] 
 
Особливості: 
 підвищена інтерактивність через участь у фентезі–лігах та 
голосуваннях в іграх зірок; 
 широкий спектр статистичних даних та аналітики; 
 соціальна взаємодія через форуми та коментарі. 
13 
ЧДТУ.242240 006 ПЗ 
1.2.5 Tennis Australia 
 
 
Рисунок 1.5 – Вигляд сайту tennis.com[5] 
 
Особливості: 
 спеціалізований розділ для кожного турніру; 
 онлайн–магазин та можливість покупки квитків; 
 великий обсяг відео– та фотоматеріалів. 
Аналіз існуючих WEB–сайтів свідчить про те, що ефективний WEB–
проект спортивної федерації включає в себе не лише представлення 
інформації, але й активну взаємодію з аудиторією. Інноваційні підходи, такі як 
фентезі–ліги, інтерактивні карти подій та широкий спектр мультимедійного 
контенту, стають стандартом для сучасних WEB–сайтів спортивних 
федерацій. Отже, розробка WEB–сайту для Звенигородської районної 
федерації футболу має враховувати ці тенденції для досягнення 
максимального впливу та задоволення потреб користувачів. 
1.3 Використання готових CMS для спортивних сайтів 
Join.football  це спеціалізована система управління контентом (рис. 1.6), 
призначена для футбольних федерацій та спільнот. Її особливості та 
14 
ЧДТУ.242240 006 ПЗ 
можливості роблять її привабливою для створення та ефективного управління 
WEB–сайтами в цій галузі. 
 
Рисунок 1.6 – Вигляд CMS, на сайті join.football[6] 
 
Основні особливості: 
1  Інтуїтивний інтерфейс: 
Join.football пропонує простий та зрозумілий інтерфейс, що дозволяє 
користувачам швидко освоювати функціонал системи без додаткових навчань. 
2  Контентне управління: 
CMS дозволяє легко додавати та редагувати новини, статті, фото та 
відео, спрощуючи процес оновлення контенту на WEB–сайті. 
3  Турнірна система: 
Вбудована система дозволяє ефективно організовувати та вести турніри, 
включаючи реєстрацію команд, планування матчів та автоматичний 
підрахунок результатів. 
4  Статистика та аналітика: 
Join.football надає інструменти для ведення статистики команд, гравців 
та турнірів. Аналітичні звіти допомагають в оцінці та вдосконаленні 
діяльності. 
15 
ЧДТУ.242240 006 ПЗ 
5  Оптимізація для мобільних пристроїв: 
Система враховує мобільний трафік, надаючи користувачам зручний 
доступ до вмісту з різних пристроїв. 
Переваги CMS join.football: 
 ефективність та швидкість розгортання; 
 швидке створення та запуск WEB–сайту завдяки готовим шаблонам та 
інтуїтивному конструктору. 
Спеціалізований футбольний функціонал: адаптована для потреб 
футбольних організацій, з фокусом на турнірах, командах та новинах. 
Підтримка та активна спільнота: доступ до підтримки та обмін досвідом 
через спільноту користувачів join.football. 
Мінуси CMS join.football: 
 обмежена гнучкість; 
 в порівнянні з деякими загальнішими CMS, може бути меншою у 
гнучкості для великих та складних WEB–проектів. 
Вартість: існує певна вартість використання join.football, що може 
впливати на бюджет користувача, особливо для менших організацій. 
Мовні обмеження: з урахуванням політичної ситуації та мовних питань 
між Україною та Росією, можливість використання join.football, яка базується 
на російській мові, може становити обмеження для тих, хто прагне 
підтримувати мовну чистоту та політичну незалежність. Це може стати 
перешкодою для деяких організацій та користувачів при виборі CMS для свого 
WEB–сайту. 
Join.football є потужним інструментом для футбольних федерацій, який 
забезпечує просте та ефективне управління WEB–сайтом. Але в даному 
випадку вона не зовсім підходить для замовника. 
1.4 Постановка задачі 
У цьому підрозділі сформульовані основні завдання, які необхідно 
вирішити в рамках розробки WEB–сайту для Звенигородської районної 
16 
ЧДТУ.242240 006 ПЗ 
федерації футболу. Основною метою проекту є створення зручного та 
ефективного інструменту для взаємодії між федерацією, командами та 
фанатами футболу, що сприятиме розвитку спорту в регіоні. 
Основні задачі проекту: 
1  Розробка інформаційної системи для управління турнірами: 
 забезпечити можливість реєстрації турнірів з обов'язковим 
зазначенням назви, дати початку та закінчення, місця проведення; 
 реалізувати функціонал для планування матчів та введення 
результатів; 
 забезпечити зручний інтерфейс для перегляду та оновлення 
інформації про турніри. 
2  Розробка системи управління командами: 
 надати можливість реєстрації команд із зазначенням назви, складу 
гравців та тренера; 
 реалізувати функціонал для додавання та редагування інформації 
про команди; 
 забезпечити можливість участі команд у різних турнірах та 
публікацію новин команди. 
3  Розробка системи управління новинами та медіа контентом: 
 забезпечити можливість публікації новин про події, турніри, 
результати матчів та інші важливі новини федерації; 
 надати функціонал для додавання фотографій та створення 
фотоальбомів; 
 реалізувати можливість коментування новин для підвищення 
залученості користувачів. 
4  Забезпечення високої продуктивності та безпеки системи: 
 використати сучасні технології для забезпечення високої швидкодії 
системи при обробці великої кількості даних; 
 забезпечити захист персональних даних користувачів та 
конфіденційної інформації. 
17 
ЧДТУ.242240 006 ПЗ 
5  Розробка адаптивного та інтуїтивно зрозумілого інтерфейсу: 
 забезпечити зручний інтерфейс для користувачів, що дозволить 
легко знаходити необхідну інформацію та здійснювати необхідні дії; 
 забезпечити сумісність із різними пристроями та браузерами для 
зручності користувачів. 
Реалізація цих задач дозволить створити функціональний та зручний 
WEB–сайт для Звенигородської районної федерації футболу, який сприятиме 
розвитку футбольної спільноти в регіоні та покращенню комунікації між всіма 
зацікавленими сторонами. 
18 
ЧДТУ.242240 006 ПЗ 
ВИСНОВКИ ДО 1 РОЗДІЛУ 
Перший розділ визначив актуальні проблеми та використані методи в 
області розробки WEB-сайту для спортивних федерацій. Було розглянуто 
проблему створення ефективного інформаційного центру та необхідність 
надання широкого спектру інформації. Також були проаналізовані існуючі 
WEB-сайти федерацій та їх особливості. Було розглянуто використання 
загальної CMS системи управління турнірами. Висновок підкреслює 
важливість реалізації ефективних методів та засобів для розв'язання 
поставлених завдань. 
 
 
 
 
 
  
19 
ЧДТУ.242240 006 ПЗ 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕННЯ У 
ПРАКТИКУ ПРОЕТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ 
2.1 Моделювання предметної області 
Моделювання предметної області є важливим етапом при проектуванні 
програмного забезпечення для інформаційних систем. Цей підрозділ 
досліджує результати моделювання з метою кращого розуміння та адаптації їх 
до потреб проекту розробки WEB–сайту Звенигородської районної федерації 
футболу. Всі діаграми проектувалися за допомогою сайту plantUML[7] 
Застосування моделювання: 
1  Деталізація сутностей та взаємодій: моделювання допомагає 
деталізувати ключові сутності, такі як турніри, команди, новини та фотографії, 
та визначити їх взаємодії. Це формує основу для подальшої реалізації 
функціональності WEB–сайту. 
2  Оптимізація потоків інформації: моделювання допомагає визначити 
оптимальні потоки інформації між різними частинами системи, забезпечуючи 
швидкий та ефективний обмін даними. 
3  Реалізація системи управління турнірами: модель турнірів визначає 
способи реєстрації команд, планування та відстеження подій. Це стає основою 
для подальшої розробки системи управління турнірами на WEB–сайті. 
Віртуалізація та Тестування: 
1  Віртуалізація WEB–сайту: застосування моделей дозволяє створити 
віртуальну копію WEB–сайту для вивчення його функціоналу та забезпечення 
коректної взаємодії між різними компонентами. 
2  Тестування інтерфейсів та функцій: моделі надають можливість 
попереднього тестування інтерфейсів користувача, а також функціональності 
WEB–сайту. Це допомагає виявити та усунути можливі проблеми ще на етапі 
розробки. 
20 
ЧДТУ.242240 006 ПЗ 
2.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області 
Предметна область веб–сайту Звенигородської районної федерації 
футболу охоплює всі аспекти діяльності федерації, включаючи організацію та 
проведення турнірів, управління командами та гравцями, а також 
забезпечення інформаційної підтримки через публікацію новин і фотографій. 
Основними процесами у предметній області є: 
1  Організація турнірів: 
 планування та анонсування турнірів. 
 реєстрація команд–учасниць. 
 формування розкладу матчів. 
 визначення результатів та підведення підсумків турнірів. 
2  Управління командами та гравцями: 
 реєстрація та оновлення інформації про команди. 
 ведення списків гравців, їх ролей та статистики. 
 оновлення інформації про склад команд та зміни у ньому. 
3  Проведення матчів: 
 призначення дат, часу та місць проведення матчів. 
 призначення арбітрів та інших офіційних осіб. 
 ведення та публікація результатів матчів. 
4  Інформаційна підтримка: 
 публікація новин про діяльність федерації, турніри, матчі та інші 
події. 
 публікація фотографій, що ілюструють різні аспекти діяльності 
федерації. 
 взаємодія з вболівальниками та надання їм актуальної інформації. 
5  Адміністрування веб–сайту: 
 керування контентом сайту. 
 підтримка та оновлення технічної інфраструктури. 
 забезпечення безпеки та захисту даних. 
21 
ЧДТУ.242240 006 ПЗ 
Опис моделі предметної області WEB–сайту Звенигородської районної 
федерації футболу 
Модель предметної області WEB–сайту описує основні сутності та їх 
взаємозв'язки, що стосуються діяльності федерації. Ця модель слугує основою 
для подальшого проектування та розробки програмного забезпечення сайту. 
Основні компоненти моделі: 
 турніри:  
 визначення: змагання, де команди грають одна проти одної; 
 атрибути: назва, дата початку, дата закінчення, опис, список 
команд–учасниць. 
 команди:  
 визначення: група гравців, що представляють певний клуб чи 
організацію; 
 атрибути: назва, опис, список гравців. 
 гравці:  
 визначення: учасники команд, що беруть участь у турнірах; 
 атрибути: ПІБ, дата народження, амплуа, фотографія. 
 матчі:  
 визначення: ігри між двома командами в рамках турніру; 
 атрибути: дата, час, місце проведення, команда–господар, 
команда–гість, результат, арбітр. 
 арбітри:  
 визначення: особи, що відповідають за проведення матчів та 
дотримання правил; 
 атрибути: ПІБ, фотографія. 
 новини:  
 визначення: інформаційні повідомлення про події, турніри, 
результати матчів та інші важливі новини федерації; 
 атрибути: заголовок, дата публікації, текст, автор. 
22 
ЧДТУ.242240 006 ПЗ 
 фотографії:  
 визначення: зображення, що ілюструють події, матчі та інші 
аспекти діяльності федерації; 
 атрибути: назва, опис, дата завантаження. 
Словник предметної області: 
 турнір: організоване змагання між командами, яке має певні 
правила, графік та умови участі; 
 команда: група гравців, які разом тренуються та грають під одним 
ім'ям або представляють певну організацію; 
 гравець: фізична особа, яка є учасником команди та бере участь 
у футбольних матчах; 
 матч: спортивна зустріч між двома командами в рамках турніру; 
 арбітр: офіційна особа, яка контролює дотримання правил під час 
матчу; 
 новина: офіційне повідомлення про події, результати матчів, 
нововведення або інші важливі факти, що стосуються діяльності 
федерації; 
 фотографія: зображення, що документує певну подію або аспект 
діяльності федерації. 
2.1.2 Елемента моделювання предметної області 
Під час побудови моделей важливо чітко визначити та використовувати 
лише ті елементи та зв'язки мови UML, які дійсно необхідні. Це допоможе 
зберегти прозорість та інформативність моделей. 
Використання занадто великої кількості UML–елементів може 
призвести до наступних проблем: 
 зниження прозорості: моделі стають складними та важкими для 
розуміння; 
 втрата інформативності: важливою інформація стає прихованою 
в надлишку деталей; 
23 
ЧДТУ.242240 006 ПЗ 
 необхідність у додаткових зусиллях: витрачається час на 
розробку та підтримку непотрібних елементів. 
Для того, щоб уникнути цих проблем, рекомендується: 
 використовувати лише ті елементи UML, які дійсно необхідні для 
опису моделі; 
 ретельно аналізувати модель, щоб видалити всі непотрібні 
елементи. 
 використовувати прості та зрозумілі діаграми; 
 застосовувати стандарти UML для забезпечення узгодженості 
моделей. 
Приклад використаних підмножин показано на рисунку  
 
 
Рисунок 2.1 – Елементи мови UML 
24 
ЧДТУ.242240 006 ПЗ 
 
Рисунок 2.2 – Зв’язки мови UML 
 
2.1.3 Робоча область моделювання 
На моделі зображена робоча модель WEB–сайту для Звенигородської 
районної федерації футболу, з послідовністю перетворення користувацьких 
дій в обробку даних та взаємодію з базою даних. Модель включає основні 
компоненти системи, такі як контролери, сервіси та репозиторії, що 
забезпечують функціональність системи, як показано на рис. 2.3. 
25 
ЧДТУ.242240 006 ПЗ 
 
Рисунок 2.3 – Модель робочої області додатку 
 
2.2 Формування та аналіз вимог 
У даному розділі розглядаються основні вимоги до системи, яка 
розробляється, а також проводиться їх аналіз для забезпечення повноти, 
несуперечності та можливості реалізації. Вимоги поділяються на 
функціональні та нефункціональні. 
2.2.1 Формування вимог до програмного забезпечення 
Первинні і детальні вимоги 
Первинні вимоги замовника: 
1  Система турнірів: 
 функціональні вимоги: 
 забезпечити можливість реєстрації турнірів з обов'язковим 
вказанням назви, дати початку та закінчення, місця проведення; 
26 
ЧДТУ.242240 006 ПЗ 
 забезпечити планування матчів та введення результатів. 
 нефункціональні вимоги: 
 забезпечити високу швидкодію системи при обробці великої 
кількості турнірів. 
2  Система команд: 
 функціональні вимоги: 
 можливість реєстрації команд із зазначенням назви, складу 
гравців, тренера; 
 дозвіл участі команд у різних турнірах та публікація новин 
команди. 
 нефункціональні вимоги: 
 забезпечити зручний інтерфейс для додавання та редагування 
інформації про команди. 
Вимоги замовника і розробника 
Вимоги замовника: 
1. Система турнірів: 
 функціональні вимоги: 
 забезпечити можливість реєстрації турнірів з обов'язковим 
вказанням назви, дати початку та закінчення, місця проведення; 
 забезпечити планування матчів та введення результатів. 
 нефункціональні вимоги: 
 забезпечити високу швидкодію системи при обробці великої 
кількості турнірів. 
2. Система команд: 
 функціональні вимоги: 
 можливість реєстрації команд із зазначенням назви, складу 
гравців, тренера; 
 дозвіл участі команд у різних турнірах та публікація новин 
команди. 
 нефункціональні вимоги: 
27 
ЧДТУ.242240 006 ПЗ 
 забезпечити зручний інтерфейс для додавання та редагування 
інформації про команди. 
Вимоги розробника: 
1  Архітектура та дизайн: 
 функціональні вимоги: 
 розробка зручної адміністративної панелі для управління 
турнірами, командами, новинами; 
 можливість розміщення фотографій та створення фотоальбомів. 
 нефункціональні вимоги: 
 використання сучасних технологій для забезпечення високої 
продуктивності та безпеки системи. 
2  Інтерфейс користувача: 
 функціональні вимоги: 
 розробка зручного інтерфейсу для перегляду турнірів, команд, 
новин та фотографій; 
 можливість коментування новин. 
 нефункціональні вимоги: 
 забезпечення адаптивності та сумісності із різними пристроями 
та браузерами. 
Функціональні та нефункціональні вимоги 
Функціональні вимоги: 
1  Реєстрація та керування турнірами, командами, новинами. 
2  Планування та введення результатів матчів. 
3  Можливість додавання та редагування інформації про команди та 
турніри. 
4  Перегляд фотографій та коментування новин. 
Нефункціональні вимоги: 
1  Висока продуктивність та швидкодія системи при обробці великої 
кількості даних. 
2  Зручний та інтуїтивно зрозумілий інтерфейс для користувачів. 
28 
ЧДТУ.242240 006 ПЗ 
3  Використання сучасних технологій для забезпечення безпеки та 
стабільності системи. 
2.2.2 Діаграма прецедентів для розробки WEB–сайту Звенигородської 
районної федерації футболу 
 
 
Рисунок 2.4 – Діаграма прецедентів для WEB–сайту Звенигородської 
районної федерації футболу 
29 
ЧДТУ.242240 006 ПЗ 
Опис діаграми прецедентів: 
1  Перегляд турнірів: 
 актори: Користувач 
 опис: Користувач має можливість переглядати інформацію про 
доступні турніри. 
2  Перегляд команд: 
 актори: Користувач 
 опис: Користувач може переглядати інформацію про команди, 
їх склад та інші деталі. 
3  Перегляд новин: 
 актори: Користувач 
 опис: Користувач може бачити останні новини, пов'язані з 
федерацією. 
4  Коментування: 
 актори: Користувач 
 опис: Користувач може залишати коментарі до новин та інших 
подій. 
5  Управління турнірами: 
 актори: Адміністратор 
 опис: Адміністратор має можливість додавати, редагувати та 
видаляти турніри. 
6  Управління командами: 
 актори: Адміністратор 
 опис: Адміністратор може керувати інформацією про команди, 
включаючи їхній склад. 
7  Управління новинами: 
 актори: Адміністратор 
 опис: Адміністратор може додавати, редагувати та видаляти 
новини на WEB–сайті. 
30 
ЧДТУ.242240 006 ПЗ 
Ця діаграма прецедентів визначає основні можливості користувачів 
(зазвичай клієнтів та адміністраторів) в системі розробки WEB–сайту для 
Звенигородської Районної Федерації Футболу. Кожен прецедент представляє 
окремий функціональний блок, який може бути реалізований у системі. 
2.3 Проектування логічної структури програмного комплексу  
Проектування логічної структури програмного комплексу є важливим 
етапом у створенні WEB–сайту Звенигородської районної федерації футболу. 
Цей розділ описує процес побудови логічної структури системи, що включає 
в себе визначення основних компонентів, їхніх функцій та взаємодій. 
2.3.1 Діаграми класів 
 
 
Рисунок 2.5 – Діаграма класів для WEB–сайту Звенигородської районної 
федерації футболу 
31 
ЧДТУ.242240 006 ПЗ 
На діаграмі відображено зв'язки між сутностями у базі даних для 
футбольного турніру: 
1  FootballTeam (Футбольна команда): має один до багатьох зв'язок з 
гравцями (Player) та одним до багатьох з матчами (Match) через команди 
team1Id та team2Id. 
2  Player (Гравець): кожен гравець належить одній команді 
(FootballTeam). Один гравець може мати багато голів (Goal) та карток (Card). 
3  Match (Матч): пов'язаний з двома футбольними командами 
(FootballTeam) та одним рефері (Referee). Матч може мати багато голів (Goal) 
та карток (Card). 
4  Goal (Гол): кожен гол пов'язаний з одним гравцем (Player) та одним 
матчем (Match). 
5  Card (Картка): кожна картка пов'язана з одним гравцем (Player), 
одним матчем (Match) та одним рефері (Referee). 
6  Referee (Рефері): кожен рефері може бути призначений на багато 
матчів (Match). 
7  News (Новини): кожна новина пов'язана з одним тегом (Tag) та 
одним фото (Photo). 
8  Photo (Фото): кожне фото пов'язане з одним тегом (Tag). 
9  Tag (Тег): кожен тег може бути пов'язаний з багатьма матчами 
(Match), новинами (News), фото (Photo) та турнірами (Tournament). 
10  Tournament (Турнір): кожен турнір пов'язаний з багатьма командами 
(FootballTeam) через TournamentTeams, з багатьма матчами (Match) та має 
один тег (Tag) і одне фото (Photo). 
11  TournamentTeams (Команди турніру): зв'язує багато команд 
(FootballTeam) з багатьма турнірами (Tournament). 
12  TournamentSettings (Налаштування турніру): налаштування для 
одного турніру (Tournament). 
13  TournamentTable (Турнірна таблиця): пов'язує багато команд 
(FootballTeam) з одним турніром (Tournament). 
32 
ЧДТУ.242240 006 ПЗ 
14  User (Користувач): кожен користувач може мати багато ролей (Role) 
через UsersRoles. 
15  Role (Роль): кожна роль може бути присвоєна багатьом користувачам 
(User) через UsersRoles. 
16  UsersRoles (Ролі користувачів): зв'язує багато користувачів (User) з 
багатьма ролями (Role). 
Загальна діаграма класів зі всіма атрибутами (більш детальніше про 
атрибути описано в 3 розділі). 
 
 
Рисунок 2.6 – Загальний вигляд бази даних зі всіма атрибутами 
33 
ЧДТУ.242240 006 ПЗ 
2.4 Архітектурне проектування 
Архітектурне проектування є критичним етапом у розробці програмного 
забезпечення, оскільки визначає загальну структуру системи та взаємодію між 
її компонентами. Для WEB–сайту Звенигородської районної федерації 
футболу була обрана багаторівнева архітектура, що включає фронтенд, бекенд 
та базу даних. Ця архітектура забезпечує гнучкість, масштабованість та 
спрощує підтримку і розширення системи. 
2.4.1 Діаграма компонентів 
 
 
Рисунок 2.7 – Діаграма компонентів для WEB–сайту Звенигородської 
районної федерації футболу 
 
Ця діаграма має три основні компоненти: Frontend, Backend та Database. 
Вони представлені у вигляді прямокутників. 
 frontend: Включає в себе користувацький інтерфейс (UI), 
представлення (Views) та контролери (Controllers). Фронтенд взаємодіє з 
бекендом через HTTP запити та відповіді; 
34 
ЧДТУ.242240 006 ПЗ 
 backend: Включає в себе API, бізнес–логіку та базу даних. Бекенд 
обробляє HTTP запити від фронтенду, виконує бізнес–логіку та взаємодіє з 
базою даних для збереження та отримання інформації; 
 database: Представляє базу даних, яка містить таблиці та 
використовується для збереження даних. Бекенд взаємодіє з базою даних через 
запити. 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання 
 
 
Рисунок 2.8 – Діаграма розгортання для теми WEB–сайту Звенигородської 
районної федерації футболу 
 
Ця діаграма має чотири основні вузли: "User's Device" (пристрій 
користувача), "Web Server" (WEB–сервер), "Application Server" (сервер 
додатків) та "Database Server" (сервер бази даних). Вони представлені у вигляді 
вузлів (node). 
35 
ЧДТУ.242240 006 ПЗ 
 user's Device: представляє пристрій користувача, такий як WEB–
браузер, який використовується для взаємодії з WEB–сайтом; 
 web Server: включає в себе фронтенд, який обслуговує запити від 
користувачів та відправляє їх до сервера додатків; 
 application Server: включає в себе бекенд, який обробляє логіку додатку 
та взаємодіє з базою даних для отримання та збереження інформації; 
 database Server: представляє сервер бази даних, який містить базу даних 
та обробляє запити від сервера додатків. 
Стрілки показують напрямок взаємодії між вузлами. Наприклад, запити 
від користувача проходять через "Web Server" та "Application Server", а доступ 
до бази даних відбувається через "Application Server". 
2.5 Моделювання поведінки системи 
Моделювання поведінки системи є важливим етапом розробки, який 
допомагає зрозуміти, як система буде реагувати на різні події та взаємодії з 
користувачами. Для цього використовуються різні типи діаграм, зокрема 
діаграми прецедентів, діаграми послідовностей та діаграми станів. 
2.5.1 Діаграма діяльності 
 
 
Рисунок 2.9– Діаграма діяльності для WEB–сайту Звенигородської районної 
федерації футболу 
36 
ЧДТУ.242240 006 ПЗ 
В даній діаграмі взаємодії представлено процес взаємодії користувача з 
WEB–сайтом Звенигородської районної федерації футболу. 
1 Користувач та WEB–сайт: 
 користувач може зайти на WEB–сайт, і йому буде надана 
можливість авторизуватися чи переглядати сайт як гість; 
 якщо користувач авторизований, йому виводиться особистий 
профіль; в іншому випадку виводиться загальна інформація. 
2 Перегляд інформації про турніри, новини, команди, фотографії: 
 користувач може обрати перегляд інформації про турніри, 
новини, команди чи фотографії; 
 якщо користувач обирає турніри, виводиться список доступних 
турнірів; 
 якщо користувач обирає новини, виводиться список новин; 
авторизований користувач може залишати коментарі; 
 якщо користувач обирає команди, виводиться список команд; 
 якщо користувач обирає фотографії, виводиться галерея 
фотографій. 
3 Повернення до початку взаємодії: 
 після перегляду інформації користувач може повернутися до 
початку і вибрати інший розділ для перегляду. 
4 Коментування новин: 
 якщо користувач авторизований та обрав перегляд новин, він 
може обрати залишити коментар під конкретною новиною; 
 користувач може відкрити форму додавання коментарів та 
зберегти свій коментар. 
2.5.2 Діаграма послідовності 
Діаграма послідовності ілюструє взаємодію користувача з WEB–сайтом, 
де він може взаємодіяти з різними функціональностями.  
37 
ЧДТУ.242240 006 ПЗ 
Рисунок 2.10 – Діаграма послідовності для WEB–сайту Звенигородської 
районної федерації футболу 
38 
ЧДТУ.242240 006 ПЗ 
Основні етапи взаємодії описані нижче: 
1  Запит на головну сторінку: 
 користувач починає взаємодію, зробивши запит на головну 
сторінку WEB–сайту. 
2  Перевірка авторизації: 
 WEB–сайт перевіряє авторизацію користувача. 
3  Головна сторінка: 
 якщо користувач авторизований, він отримує головну сторінку з 
доступом до різних функцій. 
4  Вибір перегляду турнірів, новин, команд чи фотографій: 
 користувач може вибрати перегляд турнірів, новин, команд чи 
фотографій. 
5  Відображення відповідних списків: 
 WEB–сайт відображає користувачеві список турнірів, новин, 
команд чи галерею фотографій, в залежності від вибору. 
6  Повернення на головну сторінку: 
 користувач може повернутися на головну сторінку у будь–який 
момент. 
7  Вибір новини для коментування: 
 користувач може вибрати конкретну новину для детального 
перегляду та коментування. 
8  Додавання коментаря: 
 після вибору новини користувач може додати свій коментар, 
який буде збережено в базі даних. 
Ця діаграма послідовності допомагає візуалізувати кроки взаємодії між 
користувачем та WEB–сайтом, надаючи загальний огляд процесу. 
2.5.3 Діаграма комунікації 
Діаграма комунікацій відображає взаємодію між основними об'єктами в 
системі. Основна мета цієї діаграми – показати, як користувач взаємодіє з 
39 
ЧДТУ.242240 006 ПЗ 
WEB–сайтом, який надає інформацію про футбольні турніри, новини, команди 
та фотографії. Основні об'єкти включають користувача, WEB–сайт і сервер. 
 
 
Рисунок 2.11 – Діаграма комунікації для WEB–сайту Звенигородської 
районної федерації футболу 
 
Основні етапи взаємодії: 
1 Користувач входить на сайт: Користувач запускає взаємодію, 
входячи на WEB–сайт. 
40 
ЧДТУ.242240 006 ПЗ 
2 Вибір категорії інформації: Користувач обирає категорію 
інформації: турніри, новини, команди або фотографії. 
3 Запит на інформацію: WEB–сайт надсилає запит на сервер для 
отримання відповідної інформації. 
4 Надсилання даних від сервера: Сервер обробляє запит і надсилає 
відповідні дані на WEB–сайт. 
5 Відображення інформації: WEB–сайт відображає інформацію 
користувачеві. 
6 Деталізація вибору: Якщо користувач обирає конкретний елемент 
(турнір, новину, команду або фотографію), процес повторюється з новим 
запитом і відповіддю для отримання деталей. 
7 Авторизація та коментарі: Якщо користувач авторизований, він може 
залишити коментарі під новинами. 
Ця діаграма допомагає візуалізувати взаємодію між різними 
компонентами системи та події, що відбуваються під час взаємодії 
користувача з WEB–сайтом. 
2.5.4 Діаграма скінченого автомату 
 
 
Рисунок 2.12 – Діаграма скінченого автомату для WEB–сайту 
Звенигородської районної федерації футболу 
41 
ЧДТУ.242240 006 ПЗ 
Опис діаграми взаємодії: 
1  Гість: Початковий стан користувача, який не авторизований на сайті. 
2  Авторизація: Гість може ввійти в систему, вказавши свої дані 
авторизації. 
 якщо авторизація успішна, переходимо в стан "Авторизований"; 
 якщо авторизація не вдалася, користувач може спробувати ще раз 
або залишається гостем. 
3  Головна: Користувач, як гість або авторизований, може переглядати 
загальну інформацію на головній сторінці сайту. 
4  Турніри, Новини, Команди, Фотографії: Користувач може 
переходити до розділів сайту, де відображається конкретна інформація про 
турніри, новини, команди та фотографії. 
 деталізація виходить на окремі стани для конкретного перегляду 
деталей турнірів, новин, команд та фотографій. 
5  Авторизований: Спеціальний стан, який представляє авторизованого 
користувача. Авторизований користувач може переглядати інформацію як на 
головній сторінці, так і в конкретних розділах сайту, а також залишати 
коментарі під новинами. 
 користувач може вийти з авторизованого режиму, повернувшись 
до початкового стану "Гість". 
6  Коментування: Гість може переглядати коментарі під новинами, але 
тільки авторизований користувач може залишати свої власні коментарі. 
 після коментування користувач може повернутися до 
попереднього стану, закривши розділ коментарів. 
Ця діаграма передає можливості і поведінку користувачів на WEB–
сайту, різницю між гостями та авторизованими користувачами, а також їх 
можливості перегляду та комунікації на сайті. 
  
42 
ЧДТУ.242240 006 ПЗ 
ВИСНОВКИ ПО РОЗДІЛУ 2 
Другий розділ присвячено впровадженню результатів дослідження в 
практику розробки програмного забезпечення для інформаційної системи.  
У цьому розділі розглянуто основні аспекти процесу впровадження, такі 
як моделювання предметної області, виявлення та аналіз вимог, проектування 
логічної структури, архітектурне проектування та моделювання поведінки 
системи. Перш за все, слід визначити пріоритетність моделювання предметної 
області, яке передбачає розробку моделі, що описує ключові аспекти 
досліджуваної області. Наступним важливим кроком є виявлення вимог, 
пов'язаних з програмним забезпеченням. Це поняття включає в себе вимоги 
замовника та розробника, а також функціональні та нефункціональні вимоги. 
Нарешті, в розділі обговорюються різні аспекти проектування програмних 
комплексів, такі як проектування логічної структури, що включає 
використання діаграм класів, архітектурне проектування з діаграмами 
компонентів і розгортання, а також моделювання поведінки системи з 
використанням діаграм діяльності, послідовності, зв'язку і кінцевих автоматів. 
Цей розділ є важливим етапом у процесі розробки програмного 
забезпечення, оскільки дозволяє детально розібратися у вимогах та структурі 
програмного продукту перед його фактичною розробкою та впровадженням. 
  
43 
ЧДТУ.242240 006 ПЗ 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
У цьому розділі буде розглянуто процес розробки та тестування 
програмного забезпечення для WEB–сайту Звенигородської районної 
федерації футболу. Розробка включатиме вибір програмного середовища, 
розробку алгоритмів та кодування. Також буде детально описано процес 
розробки бази даних та проектування інтерфейсу користувача. 
3.1 Розробка програмного комплексу 
У цьому розділі розглядаються процеси проектування, розробки та 
впровадження програмного забезпечення для веб–сайту Звенигородської 
районної федерації футболу. Основна увага приділяється архітектурі системи, 
структурі її компонентів та реалізації функціональних можливостей. 
3.1.1 Обгрунтування вибору засобів реалізації 
Серед існуючих технологій для проєктування було обрано дві мови 
програмування та їхні середовища розробки, а також технології: Java, Spring 
Boot, JavaScript (JSX), React, HTML, CSS. 
 Java: Java[13] є однією з найпопулярніших мов програмування у 
світі. Вона відома своєю надійністю, переносимістю та високою 
продуктивністю. Java використовується для створення бекенд–систем, 
реалізації бізнес–логіки, обробки запитів і взагалі для розробки серверної 
частини додатків. Вона має широкий вибір інструментів та бібліотек, що 
полегшує розробку великих та складних систем; 
 Spring Boot: Spring Boot[14] – це фреймворк, що базується на Java, 
призначений для швидкої розробки WEB–додатків. Він надає удосконалені 
можливості для створення мікросервісів, WEB–додатків та RESTful API. 
44 
ЧДТУ.242240 006 ПЗ 
Spring Boot дозволяє зосередитися на бізнес–логіці, забезпечуючи при цьому 
конфігураційну простоту та підтримку великої кількості інтеграцій з іншими 
технологіями; 
 JavaScript (JSX[15]): JavaScript – це мова програмування, яка 
використовується для створення динамічних інтерактивних WEB–сторінок. 
JSX є розширенням JavaScript, яке дозволяє писати HTML–подібний код 
прямо в JavaScript, що полегшує роботу з інтерфейсом користувача; 
 React: React[16] – це бібліотека JavaScript для розробки інтерфейсів 
користувача. Вона дозволяє створювати компоненти UI, які можна повторно 
використовувати та підтримувати. React відомий своєю швидкодією, 
простотою використання та великою спільнотою розробників; 
 HTML: HTML[17] (Hypertext Markup Language) використовується 
для створення структури WEB–сторінок. Вона визначає скелет та структуру 
документа, включаючи заголовки, абзаци, списки, таблиці та інші елементи. 
 CSS: CSS[18] (Cascading Style Sheets) використовується для 
оформлення та стилізації WEB–сторінок, які створені за допомогою HTML. 
CSS дозволяє визначати вигляд та відображення елементів на WEB–сторінці, 
включаючи кольори, шрифти, відступи, рамки та інші властивості; 
Проект було розроблено та відредаговано з використанням 
інтегрованого середовища розробки (IDE) IntelliJ IDEA. IntelliJ IDEA є 
потужним інструментом для розробки програмного забезпечення на Java та 
інших мовах програмування. Вона надає широкий набір функцій, які 
полегшують процес написання коду, включаючи автоматичне доповнення, 
перевірку синтаксису, відлагодження коду та інші. IntelliJ IDEA також 
45 
ЧДТУ.242240 006 ПЗ 
підтримує інтеграцію з різними інструментами та технологіями, що дозволяє 
ефективно працювати з різноманітними проектами. 
 
 
Рисунок 3.1– Вигляд Intelij IDEA 
 
Використання IntelliJ IDEA[19] сприяло підвищенню продуктивності та 
зручності розробки, забезпечуючи зручне середовище для написання, 
редагування та відлагодження коду. Її інтуїтивний інтерфейс та широкі 
можливості роблять її популярним вибором серед розробників для створення 
високоякісного програмного забезпечення. 
Проект також використовував базу даних PostgreSQL[20] для зберігання 
та керування даними. PostgreSQL є потужною та надійною об'єктно–
реляційною системою керування базами даних (СКБД), яка підтримує 
розширений набір функцій та можливостей. 
Використання PostgreSQL дозволило ефективно зберігати та управляти 
даними про турніри, новини, фотографії та команди WEB–сайту 
Звенигородської районної федерації футболу. Його надійна та масштабована 
архітектура забезпечує стабільну роботу бази даних навіть при великих 
обсягах даних та навантаженнях. 
46 
ЧДТУ.242240 006 ПЗ 
За допомогою PostgreSQL можна здійснювати різноманітні операції з 
даними, такі як додавання, зміна, видалення та запити, що дозволяє легко 
отримувати доступ до необхідної інформації для WEB–сайту. Він також 
підтримує різні рівні безпеки та механізми аутентифікації, що забезпечує 
захист конфіденційності та цілісності даних. 
Узагальнюючи, використання PostgreSQL сприяло створенню надійної 
та ефективної системи керування базами даних, яка відповідає потребам 
проекту та забезпечує стабільну роботу WEB–сайту Звенигородської районної 
федерації футболу. 
3.1.2 Опис структурної (функціональної) схеми 
 
 
Рисунок 3.2 – Структурна схема додатку 
47 
ЧДТУ.242240 006 ПЗ 
Опис компонентів схеми 
 frontend: Цей компонент відповідає за інтерфейс користувача та 
візуальне представлення інформації. Включає в себе компоненти, такі як 
сторінки, кнопки, поля вводу та інші елементи, які взаємодіють з 
користувачем. Забезпечує відображення інформації про турніри, новини, 
фотографії та команди у зручному для користувача форматі; 
 backend: Цей компонент відповідає за обробку запитів користувачів 
та взаємодію з базою даних. Включає в себе серверні компоненти, які 
відповідають за обробку бізнес–логіки, автентифікацію, авторизацію та інші 
серверні операції. Забезпечує передачу даних між фронтендом та базою даних, 
виконуючи операції збереження, оновлення та видалення даних; 
 database: Цей компонент використовує PostgreSQL для збереження 
та управління даними про турніри, новини, фотографії та команди. Включає 
таблиці, які відповідають за зберігання різних типів інформації, таких як 
таблиця турнірів, новин, фотографій та команд. Забезпечує доступ до даних 
для бекенду WEB–сайту, дозволяючи виконувати операції зчитування, запису, 
оновлення та видалення даних. 
Ця структурна схема допомагає зрозуміти загальну архітектуру 
програмного забезпечення, його основні компоненти та їх взаємодію, що є 
важливим для розуміння функціональності системи та управління її розвитком 
та підтримкою. 
 
48 
ЧДТУ.242240 006 ПЗ 
 
Рисунок 3.3 – Функціональна схема додатку 
 
Логіка функціональної схеми 
Frontend: 
 взаємодія з користувачем: Фронтенд отримує введені дані від 
користувачів та відображає інформацію про турніри, команди, 
матчі, новини та фотографії; 
 запити до Backend: При будь–якій взаємодії з користувачем 
(наприклад, перегляд турнірів або додавання новин) фронтенд 
надсилає відповідні запити до бекенду. 
Backend: 
49 
ЧДТУ.242240 006 ПЗ 
 обробка запитів: Отримує запити від фронтенду, обробляє їх, 
здійснюючи необхідні операції, такі як автентифікація 
користувача, авторизація та виконання бізнес–логіки; 
 взаємодія з базою даних: Для виконання запитів бекенд 
звертається до бази даних, виконуючи операції зі збереження, 
отримання, оновлення або видалення даних; 
 відповідь Frontend: Після обробки запиту бекенд повертає 
результати на фронтенд для відображення користувачу. 
Database (PostgreSQL): 
 збереження та управління даними: База даних зберігає всю 
інформацію про турніри, команди, матчі, новини та фотографії. 
Вона відповідає за виконання CRUD (Create, Read, Update, Delete) 
операцій; 
 забезпечення доступу: Надає дані за запитами бекенду, 
підтримуючи цілісність та консистентність даних. 
Ця схема ілюструє взаємодію між компонентами системи, забезпечуючи 
цілісність та ефективність роботи WEB–сайту для Звенигородської районної 
федерації футболу. 
3.1.3 Опис логічної схеми системи 
Для опису логічної схеми системи можна скористатися алгоритмічним 
описом та блок–схемою алгоритму. 
 
 
Рисунок 3.4 – Блок–схема роботи WEB–сайту Звенигородської районної 
федерації футболу 
50 
ЧДТУ.242240 006 ПЗ 
Логічна схема системи для WEB–сайту Звенигородської районної 
федерації футболу описує основні інформаційні процеси, які відбуваються на 
сайті: 
1 Отримання запиту на відображення інформації: Система отримує 
запит від користувача про відображення певної інформації. 
2 Перевірка типу запиту: Система перевіряє тип запиту, щоб 
визначити, яка інформація потрібна користувачеві. 
3 Отримання та відображення інформації про турніри: Якщо 
користувач запитує інформацію про турніри, система отримує та відображає 
відповідні дані. 
4 Отримання та відображення новин: Якщо користувач запитує 
новини, система отримує та відображає відповідну інформацію. 
5 Отримання та відображення фотографій: Якщо користувач запитує 
фотографії, система отримує та відображає відповідні зображення. 
6 Отримання та відображення інформації про команди: Якщо 
користувач запитує інформацію про команди, система отримує та відображає 
відповідні дані. 
7 Відображення головної сторінки сайту: Якщо жоден з попередніх 
умов не виконується, система автоматично відображає головну сторінку 
WEB–сайту. 
Ця логічна схема дозволяє чітко розуміти послідовність дій, які виконує 
система для задоволення запитів користувачів та надання їм необхідної 
інформації. 
3.1.4 Розробка бази даних 
Щоб правильно спроектувати базу даних для WEB–сайту 
Звенигородської районної федерації футболу, спершу потрібно визначити 
ключові завдання, які вона має виконувати, а саме: 
1. Аутентифікація  
2. Показ та обробку турнірів 
3. Показ та обробку новин 
51 
ЧДТУ.242240 006 ПЗ 
4. Показ та обробку команд 
5. Показ та обробку фотографій 
База даних WEB–сайту Звенигородської районної федерації футболу 
складається з 16–ти взаємопов'язаних таблиць, що забезпечує оптимальну 
роботу системи. Детальну інформацію про структуру бази даних можна знайти 
на таблиці 3.1. 
Таблиця 3.1 
Структуру бази даних 
Назва Призначення Поля 
таблиці 
cards Зберігання даних про cardId, matchId, playerId, refereeId, 
картки гравців у матчах minute, cardType 
footballteams Зберігання інформації teamId, teamName, coach, district, tagId, 
про футбольні команди photoId 
goals Зберігання даних про goalId, playerId, matchId, minute, 
голи, забиті в матчах description 
matches Зберігання даних про matchId, tournamentId, matchDate, 
проведені матчі team1Id, team2Id, refereeId, tagId, 
team1TotalGoals, team2TotalGoals, 
matchTime, groupStage 
news Зберігання новин та їх newsId, title, content, publicationDate, 
вмісту author, tag_tagId, photoId 
photos Зберігання фотографій, photoId, path, tagId 
що використовуються на 
сайті 
players Зберігання інформації playerId, firstName, lastName, birthDate, 
про футбольних гравців position, shirtNumber, tagId, active, 
teamId 
 
52 
ЧДТУ.242240 006 ПЗ 
Продовження таблиці 3.1 
referees Зберігання даних про refereeId, firstName, lastName, tagId, 
арбітрів birthDay, association, 
qualificationLevel 
roles Зберігання ролей id, name 
користувачів 
tags Зберігання тегів для tagId, tagName 
категоризації даних 
tournaments Зберігання інформації tournamentId, tournamentName, 
про футбольні турніри startDate, endDate, organizer, photoId, 
tag_tagId 
Зберігання tournamentId, pointsForWin, 
tournamentsettings налаштувань турнірів pointsForDraw 
Зберігання турнірної 
tournamenttable таблиці tableId, tournamentId, teamId, points 
Зберігання інформації tournamentTeamId, tournamentId, 
tournamentteams про команди в турнірі teamId 
Зберігання даних про 
users користувачів id, username, password, email 
Зв'язувальна таблиця 
для зв'язку 
users_roles користувачів і ролей user_id, role_id 
 
Більш детальний розгляду кожної з таблиць, що входять до складу бази 
даних, з їх атрибутами описано далі: 
1  cards: 
 cardId: унікальний ідентифікатор картки; 
 matchId: ідентифікатор матчу, до якого відноситься картка; 
53 
ЧДТУ.242240 006 ПЗ 
 playerId: ідентифікатор гравця, якому видали картку; 
 refereeId: ідентифікатор арбітра, який видає картку; 
 minute: хвилина, на яку видається картка; 
 cardType: тип картки (червона або жовта). 
2  footballteams: 
 teamId: унікальний ідентифікатор футбольної команди; 
 teamName: назва команди; 
 coach: ім'я тренера команди; 
 district: область або регіон, до якого відноситься команда; 
 tagId: ідентифікатор тега; 
 photoId: ідентифікатор фотографії команди. 
3  goals: 
 goalId: унікальний ідентифікатор голу; 
 playerId: ідентифікатор гравця, який забиває гол; 
 matchId: ідентифікатор матчу, в якому забито гол; 
 minute: хвилина, на яку забито гол; 
 description: опис голу. 
4  matches: 
 matchId: унікальний ідентифікатор матчу; 
 tournamentId: ідентифікатор турніру, до якого відноситься матч; 
 matchDate: дата проведення матчу; 
 team1Id: ідентифікатор першої команди; 
 team2Id: ідентифікатор другої команди; 
 refereeId: ідентифікатор арбітра матчу; 
 tagId: ідентифікатор тега; 
 team1TotalGoals: загальна кількість голів, забитих першою 
командою; 
 team2TotalGoals: загальна кількість голів, забитих другою 
командою; 
 matchTime: час тривалості матчу; 
54 
ЧДТУ.242240 006 ПЗ 
 groupStage: етап групового етапу (якщо є); 
 group_stage: те ж саме, що і groupStage. 
5  news: 
 newsId: унікальний ідентифікатор новини; 
 title: заголовок новини; 
 content: вміст новини; 
 publicationDate: дата публікації новини; 
 author: автор новини; 
 tag_tagId: ідентифікатор тега; 
 photoId: ідентифікатор фотографії новини. 
6  photos: 
 photoId: унікальний ідентифікатор фотографії; 
 path: шлях до файлу фотографії; 
 tagId: ідентифікатор тега. 
7  players: 
 playerId: унікальний ідентифікатор гравця; 
 firstName: ім'я гравця; 
 lastName: прізвище гравця; 
 birthDate: дата народження гравця; 
 position: позиція гравця на полі; 
 shirtNumber: номер на футбольній формі; 
 tagId: ідентифікатор тега; 
 active: активність гравця; 
 teamId: ідентифікатор команди, до якої відноситься гравець. 
8  referees: 
 refereeId: унікальний ідентифікатор арбітра; 
 firstName: ім'я арбітра; 
 lastName: прізвище арбітра; 
 tagId: ідентифікатор тега; 
 birthDay: день народження арбітра; 
55 
ЧДТУ.242240 006 ПЗ 
 association: асоціація, до якої відноситься арбітр; 
 qualificationLevel: рівень кваліфікації арбітра. 
9  roles: 
 id: унікальний ідентифікатор ролі; 
 name: назва ролі. 
10  tags: 
 tagId: унікальний ідентифікатор тега; 
 tagName: назва тега. 
11  tournaments: 
 tournamentId: унікальний ідентифікатор турніру; 
 tournamentName: назва турніру; 
 startDate: дата початку турніру; 
 endDate: дата закінчення турніру; 
 organizer: організатор турніру; 
 photoId: ідентифікатор фотографії турніру; 
 tag_tagId: ідентифікатор тега. 
12  tournamentsettings: 
 tournamentId: унікальний ідентифікатор турніру; 
 pointsForWin: кількість балів за перемогу; 
 pointsForDraw: кількість балів за нічию. 
13  tournamenttable: 
 tableId: унікальний ідентифікатор таблиці турніру; 
 tournamentId: ідентифікатор турніру; 
 teamId: ідентифікатор команди; 
 points: кількість балів команди. 
14  tournamentteams: 
 tournamentTeamId: унікальний ідентифікатор команди в турнірі; 
 tournamentId: ідентифікатор турніру; 
 teamId: ідентифікатор команди. 
15  users: 
56 
ЧДТУ.242240 006 ПЗ 
 id: унікальний ідентифікатор користувача; 
 username: ім'я користувача; 
 password: пароль користувача; 
 email: електронна адреса користувача. 
16  users_roles: 
 user_id: ідентифікатор користувача; 
 role_id: ідентифікатор ролі. 
Остаточний вид бази даних(див. рисунок 3.5). 
 
 
Рисунок 3.5 – Вигляд бази даних 
57 
ЧДТУ.242240 006 ПЗ 
3.1.5 Розробка інтерфейсу користувача 
Під час розробки WEB–сайту Звенигородської районної федерації 
футболу  виникла потреба створити зовнішній інтерфейс додатку. 
Візуальне представлення зовнішнього додатку можна знайти на рисунку 
3.6. 
 
Рисунок 3.6 – Головна сторінка сайту 
 
Головна сторінка сайту містить: 
 логотип федерації футболу. 
 меню з пунктами:  
58 
ЧДТУ.242240 006 ПЗ 
 про федерацію: цей пункт містить інформацію про федерацію 
футболу, та загальні спортивні нижче; 
 турніри: цей пункт містить інформацію про турніри, які організовує 
федерація футболу. 
 учасники: цей пункт містить інформацію про команди та 
футболістів, які беруть участь у турнірах; 
 новини: цей пункт містить новини про діяльність федерації футболу; 
 контакти: цей пункт містить контактну інформацію федерації 
футболу. 
Сторінка "Турніри" містить:  
 список турнірів, які організовує федерація футболу; 
 інформацію про кожен турнір, включаючи його назву, дати 
проведення, правила та учасників. 
 
Рисунок 3.7 – Сторінка турнірів 
59 
ЧДТУ.242240 006 ПЗ 
Сторінка "Учасники" містить:  
 загальний список команд та футболіста, які беруть участь у турнірах; 
 інформацію про кожну команду, включаючи її назву, склад, тренера 
та контактну інформацію; 
 інформацію про кожну учасника (футболіста).  
 
Рисунок 3.8 – Сторінка учасників 
 
сторінка "Новини" містить:  
 список новин про діяльність федерації футболу; 
60 
ЧДТУ.242240 006 ПЗ 
 детальну інформацію про кожну новину, включаючи її заголовок, 
текст, дату публікації та фотографії. 
 
 
Рисунок 3.9 – Сторінка новин 
 
Сторінка "Контакти" містить:  
 контактну інформацію федерації футболу, включаючи адресу, 
телефонний номер та адресу електронної пошти; 
 форму зворотного зв'язку, яку можна використовувати, щоб 
надіслати повідомлення федерації футболу. 
3.1.6 Опис розробки програмних компонентів 
1  AuthController.java: 
 призначення: контролер для автентифікації користувачів; 
 зв'язки: взаємодіє з сервісом автентифікації користувачів; 
61 
ЧДТУ.242240 006 ПЗ 
 особливості реалізації: обробляє запити для автентифікації 
користувачів, перевіряє правильність ідентифікаційних даних, 
генерує та повертає токени аутентифікації. 
2  CardController.java: 
 призначення: контролер для операцій з картками; 
 зв'язки: взаємодіє з сервісом керування картками; 
 особливості реалізації: обробляє запити для створення, 
оновлення, видалення та отримання інформації про картки 
гравців. 
3  FootballTeamController.java: 
 призначення: контролер для операцій з футбольними командами; 
 зв'язки: взаємодіє з сервісом керування футбольними командами; 
 особливості реалізації: оробляє запити для отримання інформації 
про команди, їх створення, оновлення та видалення. 
4  MatchController.java: 
 призначення: контролер для операцій з матчами; 
 зв'язки: взаємодіє з сервісом керування матчами; 
 особливості реалізації: обробляє запити для отримання 
інформації про матчі, створення нових матчів, оновлення даних 
про матчі та їх видалення. 
5  NewsController.java: 
 призначення: контролер для операцій з новинами; 
 зв'язки: взаємодіє з сервісом керування новинами; 
 особливості реалізації: обробляє запити для отримання 
інформації про новини, створення, оновлення та видалення 
новин. 
6  PhotoController.java: 
 призначення: контролер для операцій з фотографіями; 
 зв'язки: взаємодіє з сервісом керування фотографіями; 
62 
ЧДТУ.242240 006 ПЗ 
 особливості реалізації: обробляє запити для отримання 
фотографій, завантаження нових фотографій, оновлення даних 
про фотографії та їх видалення. 
7  PlayerController.java: 
 призначення: контролер для операцій з гравцями; 
 зв'язки: взаємодіє з сервісом керування гравцями; 
 особливості реалізації: обробляє запити для отримання інформації 
про гравців, їх створення, оновлення та видалення. 
8  ReferController.java: 
 призначення: контролер для операцій з арбітрами; 
 зв'язки: взаємодіє з сервісом керування арбітрами; 
 особливості реалізації: обробляє запити для отримання 
інформації про арбітрів, їх створення, оновлення та видалення. 
9  TagController.java: 
 призначення: контролер для операцій з тегами; 
 зв'язки: взаємодіє з сервісом керування тегами; 
 особливості реалізації: обробляє запити для отримання 
інформації про теги, їх створення, оновлення та видалення. 
10  TournamentController.java: 
 призначення: контролер для операцій з турнірами; 
 зв'язки: взаємодіє з сервісом керування турнірами; 
 особливості реалізації: обробляє запити для отримання 
інформації про турніри, їх створення, оновлення та видалення. 
11  TournamentTeamController.java: 
 призначення: контролер для операцій з командами в турнірах; 
 зв'язки: взаємодіє з сервісом керування командами в турнірах; 
 особливості реалізації: обробляє запити для отримання 
інформації про команди, їх створення, оновлення та видалення. 
  
63 
ЧДТУ.242240 006 ПЗ 
3.2 Тестування системи 
Тестування системи є важливою частиною розробки програмного 
забезпечення, яка включає в себе кілька етапів: модульне тестування, 
інтеграційне тестування, системне тестування та приймальне тестування. 
Кожен з цих етапів має свою мету та методологію, що дозволяє забезпечити 
високу якість програмного продукту. 
3.2.1 Модульне тестування 
Модульне тестування є ключовим етапом розробки програмного 
забезпечення, який спрямований на перевірку правильності роботи окремих 
модулів або компонентів системи. Для модульного тестування було 
використано набір стандартних інструментів, таких як JUnit для тестування 
Java–коду, Jest для тестування React–компонентів. 
Для створення тест кейсів свого додатку сайту Футбольного клубу, було 
використано бібліотеку тестів Jest. Це – виконавець тестів на JavaScript, який 
дає змогу взаємодіяти з DOM через jsdom. Попри те, що jsdom лише приблизно 
реалізує роботу браузера, у більшості випадків цього достатньо для тестування 
React–компонентів. Jest пропонує чудову швидкість ітерацій разом із 
потужними можливостями, як–от фіктивні модулі та таймери, які дають 
більше контролю над виконанням коду. 
Сам код тестування виглядає наступним чином: 
 
beforeEach(() => { 
    fetchMock.resetMocks(); 
}); 
 
test('Користувач може успішно авторизуватися', async () => { 
    // Відображення сторінки авторизації 
    render( 
        <MemoryRouter> 
            <LoginPage /> 
        </MemoryRouter> 
    ); 
 
    // Введення коректних даних користувача 
    act(() => { 
        fireEvent.change(screen.getByPlaceholderText(/логін/i), { target: { value: 'testuser' } }); 
        fireEvent.change(screen.getByPlaceholderText(/пароль/i), { target: { value: 'testpassword' } }); 
    }); 
 
    // Натискання кнопки авторизації 
64 
ЧДТУ.242240 006 ПЗ 
    act(() => { 
        fireEvent.click(screen.getByRole('button', { name: /увійти/i })); 
    }); 
 
    // Check if the redirect occurred 
    expect(window.location.pathname).toBe('/'); 
}); 
// Тест для Header компоненту 
test('Header рендериться коректно', () => { 
    // Монтаж компоненту 
    render(<Header />); 
 
    // Перевірка наявності тексту "Турніри" в меню 
    const tournamentLink = screen.getByText('Турніри'); 
    expect(tournamentLink).toBeInTheDocument(); 
 
    // Перевірка, чи відображається логотип 
    const logoImage = screen.getByAltText('Фото'); 
    expect(logoImage).toBeInTheDocument(); 
}); 
 
jest.mock('../services/apiTournament'); 
 
describe('Tournament Component', () => { 
    beforeEach(() => { 
        getTournament.mockResolvedValue([ 
            { 
                id: 1, 
                tournamentId: '123', 
                tournamentName: 'Test Tournament', 
                startDate: '2022–01–01', 
                endDate: '2022–01–10', 
                countTeam: 8, 
                status: 'Active', 
                tagName: 'Sports', 
                photoUrl: 'https://example.com/tournament–image.jpg', 
            }, 
        ]); 
    }); 
 
    it('renders the component with tournament data', async () => { 
        render(<Tournament />); 
 
        await waitFor(() => { 
            expect(screen.getByText('Test Tournament')).toBeInTheDocument(); 
        }); 
 
        expect(screen.getByText('2022–01–01 – 2022–01–10')).toBeInTheDocument(); 
        expect(screen.getByText('8 команд')).toBeInTheDocument(); 
        expect(screen.getByText('Active')).toBeInTheDocument(); 
        expect(screen.getByText('Sports')).toBeInTheDocument(); 
        expect(screen.getByAltText('Картинка для турніра')).toBeInTheDocument(); 
    }); 
 
    it('navigates to the tournament page when a tournament card is clicked', async () => { 
        render(<Tournament />); 
 
        // Wait for the data to be loaded 
        await waitFor(() => { 
            expect(screen.getByText('Test Tournament')).toBeInTheDocument(); 
        }); 
 
        // screen.debug(); 
65 
ЧДТУ.242240 006 ПЗ 
        // Click on the tournament card 
        act(() => { 
            userEvent.click(screen.getByText('Test Tournament')); 
        }); 
 
        // screen.debug(); 
 
        // Wait for navigation to complete 
        await waitFor(() => { 
            expect(window.location.pathname).toBe('/'); 
        }); 
    }); 
}); 
 
// Тест для PrivateRoute компоненту 
test('PrivateRoute перенаправляє на головну сторінку при відсутності авторизації', () => { 
    // Монтаж компоненту з неавторизованим користувачем 
    render( 
        <MemoryRouter initialEntries={['/private']}> 
            <PrivateRoute element={<div>Private Content</div>} roles={['admin']} /> 
        </MemoryRouter> 
    ); 
 
    // Перевірка, чи відбувається перенаправлення на головну сторінку 
    expect(window.location.pathname).toBe('/'); 
}); 
 
 
// // Тест для Home компоненту 
test('Home рендериться коректно', () => { 
    // Монтаж компоненту 
    render(<Home />); 
 
    // Перевірка наявності заголовка "Вітаємо на головній сторінці" 
    const welcomeMessage = screen.getByText('Інформаційний сайт'); 
    expect(welcomeMessage).toBeInTheDocument(); 
}); 
Що саме вони тестують: 
1  Тест для компоненту LoginPage: 
 рендерить сторінку авторизації; 
 змінює дані в текстових полях для введення логіну та паролю; 
 натискання кнопки "Увійти"; 
 перевірка, чи відбувається перенаправлення на головну сторінку 
('/'). 
2  Тест для компоненту Header: 
 рендерить компонент заголовку; 
 перевірка наявності тексту "Турніри" в меню; 
 перевірка, чи відображається логотип. 
3  Тести для компоненту Tournament: 
66 
ЧДТУ.242240 006 ПЗ 
 рендерить компонент з даними турніру; 
 перевірка наявності та коректності виведення даних турніру; 
 натискання на картку турніру і перевірка, чи відбувається 
перенаправлення на головну сторінку ('/'). 
4  Тест для компоненту PrivateRoute: 
 монтаж компоненту PrivateRoute з неавторизованим 
користувачем; 
 перевірка, чи відбувається перенаправлення на головну сторінку 
при відсутності авторизації. 
5  Тест для компоненту Home: 
 рендерить компонент головної сторінки; 
 перевірка наявності заголовка "Інформаційний сайт". 
 
 
Рисунок 3.9 – Вигляд успішного проходження тесту, додатку 
 
Таблиця 3.2 
Проходження тесту 
Компонент Опис тесту Очікуваний результат Результат 
виконання 
  
LoginPage Тест для компоненту 
LoginPage 
 
67 
ЧДТУ.242240 006 ПЗ 
Продовження таблиці 3.2 
 
Відображення Сторінка авторизації Успішно 
сторінки авторизації відображається 
 
Зміна даних у полях Дані в полях логіну та Успішно 
логіну та паролю паролю змінюються 
 
Натискання кнопки Кнопка "Увійти" Успішно 
"Увійти" натискається 
 
Перевірка Перенаправлення на Успішно 
перенаправлення на головну сторінку ('/') 
головну сторінку 
  
Header Тест для компоненту 
Header 
 
Рендер компоненту Компонент заголовку Успішно 
заголовку рендериться 
 
Перевірка наявності Текст "Турніри" Успішно 
тексту "Турніри" у присутній у меню 
меню 
 
Перевірка наявності Логотип присутній Успішно 
логотипу 
  
Tournament Тести для компоненту 
Tournament 
 
Рендер компоненту з Дані турніру рендеряться Успішно 
даними турніру 
 
Перевірка коректності Дані турніру Успішно 
виведення даних відображаються коректно 
турніру (назва, дати, кількість 
команд, статус, тег, 
картинка) 
 
68 
ЧДТУ.242240 006 ПЗ 
Продовження таблиці 3.2 
 
Натискання на картку Перенаправлення на Успішно 
турніру і перевірка головну сторінку ('/') 
перенаправлення на 
головну сторінку 
  
PrivateRoute Тест для компоненту 
PrivateRoute 
 
Монтаж компоненту Компонент рендериться Успішно 
PrivateRoute з для неавторизованого 
неавторизованим користувача 
користувачем 
 
Перевірка Перенаправлення на Успішно 
перенаправлення на головну сторінку при 
головну сторінку при відсутності авторизації 
відсутності 
авторизації 
  
Home Тест для компоненту 
Home 
 
Рендер компоненту Компонент головної Успішно 
головної сторінки сторінки рендериться 
 
Перевірка наявності Заголовок Успішно 
заголовка "Інформаційний сайт" 
"Інформаційний сайт" присутній 
 
Кожен модуль був ретельно протестований на відповідність 
функціональним вимогам та специфікаціям. Для кожного тесту створювалися 
відповідні вхідні дані, викликалися необхідні методи або функції, та 
перевірялось очікуваний результат. Використовувалися різні види тестів, такі 
69 
ЧДТУ.242240 006 ПЗ 
як позитивні тести для перевірки коректної роботи, негативні тести для 
перевірки обробки помилок та різні варіанти граничних значень. 
Після виконання модульного тестування було виявлено та виправлено 
деякі помилки, що дозволило підтвердити коректність роботи окремих 
модулів системи. Такий підхід дозволяє підтримувати стабільність та 
надійність програмного забезпечення, а також сприяє вчасному виявленню та 
усуненню можливих проблем. 
3.2.2 Інтеграційне тестування 
Інтеграційне тестування є наступним етапом після модульного 
тестування і спрямоване на перевірку коректної взаємодії між різними 
модулями або компонентами системи. Під час інтеграційного тестування 
перевіряється, чи працюють окремі модулі разом правильно, як очікується від 
системи в цілому. 
Для інтеграційного тестування використовувалися різні методи, такі як 
внутрішнє тестування API для перевірки взаємодії між серверними 
компонентами, тестування WEB–інтерфейсу для перевірки коректності 
відображення даних та інтерактивної взаємодії з користувачем, а також 
тестування бази даних для перевірки збереження та витягування даних. 
Під час інтеграційного тестування перевірялася взаємодія між 
серверними та клієнтськими компонентами системи, правильність передачі 
даних через API, а також взаємодія з базою даних. Було створено тестові 
набори для різних сценаріїв взаємодії, включаючи позитивні, негативні та 
граничні випадки. 
Таблиця 3.3 
Проходження інтеграційних тестів 
Компонент Опис тесту Очікуваний результат Результат 
/Модуль  в иконання 
API Тестування API авторизації 
Авторизації 
70 
ЧДТУ.242240 006 ПЗ 
Продовження таблиці 3.3 
 
Надсилання запиту з Користувач Успішно 
коректними даними для авторизований, 
авторизації повертається токен 
авторизації 
 
Надсилання запиту з Повертається помилка Успішно 
некоректними даними для авторизації 
 авторизації 
Перевірка збереження Токен зберігається у Успішно 
токену у базі даних  базі даних  
A PI Турнірів Тестування API турнірів 
Надсилання запиту для Повертається список Успішно 
 отримання списку турнірів турнірів 
Надсилання запиту для Новий турнір Успішно 
створення нового турніру створюється, дані 
зберігаються у базі 
 даних 
Надсилання запиту для Дані турніру Успішно 
редагування існуючого оновлюються у базі 
 турніру даних 
Надсилання запиту для Турнір видаляється з Успішно 
видалення турніру  бази даних  
Інтерфейс Тестування WEB–
Турнірів інтерфейсу для взаємодії з 
турнірами 
 
Перевірка відображення Список турнірів Успішно 
списку турнірів коректно 
відображається на 
 сторінці 
Перевірка функціональності Новий турнір додається Успішно 
створення нового турніру та відображається у 
 через інтерфейс списку турнірів 
Перевірка функціональності Зміни у турнірі Успішно 
редагування турніру через зберігаються та 
 інтерфейс відображаються 
Перевірка функціональності Турнір видаляється зі Успішно 
видалення турніру через списку 
інтерфейс 
71 
ЧДТУ.242240 006 ПЗ 
Продовження таблиці 3.3 
  
База даних Тестування взаємодії з 
( PostgreSQL) базою даних 
Перевірка збереження Дані нового турніру Успішно 
даних про новий турнір зберігаються у базі 
 даних 
Перевірка оновлення даних Дані існуючого турніру Успішно 
про існуючий турнір оновлюються у базі 
 даних 
Перевірка видалення даних Дані турніру Успішно 
про турнір видаляються з бази 
даних 
  
Загальна Перевірка інтеграції всіх 
інтеграція компонентів 
 
Перевірка взаємодії між Фронтенд коректно Успішно 
фронтендом, бекендом та взаємодіє з бекендом та 
базою даних базою даних, дані 
коректно передаються 
та відображаються 
 
Перевірка позитивних Усі позитивні сценарії Успішно 
сценаріїв успішно виконуються 
 
Перевірка негативних Негативні сценарії Успішно 
сценаріїв коректно 
обробляються, 
повертаються 
відповідні помилки 
 
Перевірка граничних Граничні випадки Успішно 
випадків обробляються 
коректно, система 
працює стабільно 
 
72 
ЧДТУ.242240 006 ПЗ 
Після успішного інтеграційного тестування було підтверджено, що всі 
компоненти системи працюють разом правильно та забезпечують очікувану 
функціональність. Цей етап допомагає впевнитися в стабільності та 
працездатності системи перед впровадженням в реальні умови. 
3.2.3 Системне тестування 
Системне тестування є останнім етапом тестування перед 
впровадженням системи в реальні умови. Його мета – перевірити, чи 
відповідає система вимогам, визначеним у вимогах до програмного 
забезпечення, та чи відповідає очікуванням користувачів і бізнес–завданням. 
Під час системного тестування проводяться різні види тестів, такі як 
функціональні тести, тести продуктивності, тести безпеки та інші, з метою 
визначення поведінки системи в реальних умовах. 
Тести функціональності перевіряють, чи виконує система очікувані 
функції відповідно до специфікацій та вимог, чи правильно обробляються 
введені дані та чи генеруються очікувані результати. 
Тести продуктивності оцінюють продуктивність системи, таку як 
швидкість відповіді, завантаження сервера та інші параметри, щоб 
переконатися, що система може працювати ефективно під час реального 
використання. 
Тести безпеки визначають, чи є система захищеною від зловживання, 
злому та несанкціонованого доступу, перевіряються механізми аутентифікації, 
авторизації та шифрування даних. 
Таблиця 3.4 
Проходження системних тестів 
Компонент/ Опис тесту Очікуваний Результат 
Модуль резуль тат викон ання 
Функціональність Перевірка 
коректності 
виконання всіх 
основних 
функцій системи 
 
73 
ЧДТУ.242240 006 ПЗ 
Продовження таблиці 3.4 
 
Реєстрація нових Користувач Успішно 
користувачів успішно 
реєструється, дані 
зберігаються у 
 базі даних 
Авторизація Користувач Успішно 
користувачів успішно 
авторизується, 
отримує доступ до 
відповідних 
функцій 
 
Додавання, Турніри успішно Успішно 
редагування та додаються, 
видалення редагуються та 
турнірів видаляються, 
зміни 
відображаються у 
 системі 
Перегляд та Новини Успішно 
коментування відображаються 
новин коректно, 
користувачі 
можуть додавати 
 коментарі 
Завантаження та Фотографії Успішно 
відображення успішно 
фотографій завантажуються та 
відображаються у 
систем і  
Продуктивність Перевірка 
швидкодії та 
стійкості 
системи при 
високому 
навантаженні 
 
74 
ЧДТУ.242240 006 ПЗ 
Продовження таблиці 3.4 
 
Навантажувальн Система працює Успішно 
е тестування з стабільно, 
великою відповіді на 
кількістю запити надходять 
користувачів у прийнятні 
 терміни 
Тестування часу Час відгуку на Успішно 
відгуку на операції 
основні операції відповідає 
(реєстрація, вимогам 
авторизація, 
додавання 
турнірів) 
  
Безпека Перевірка 
захищеності 
системи від 
 можливих загроз 
Тестування Система захищена Успішно 
захищеності API від основних 
(ін'єкції SQL, видів атак, 
XSS, CSRF) відповідні 
механізми 
безпеки 
працюють 
 коректно 
Перевірка Неавторизовані Успішно 
доступу до користувачі не 
захищених мають доступу до 
ресурсів (тільки захищених 
авторизовані ресурсів 
користувачі 
мають доступ)   
Сумісність Перевірка 
коректності 
роботи системи 
на різних 
платформах та 
браузерах 
Продовження таблиці 3.4 
75 
ЧДТУ.242240 006 ПЗ 
 
Тестування на Система Успішно 
різних WEB– коректно працює 
браузерах на всіх основних 
(Chrome, Firefox, WEB–браузерах 
 Edge, Safari) 
Тестування на Система Успішно 
різних пристроях коректно 
(ПК, планшети, відображається та 
смартфони) функціонує на 
всіх основних 
типах  пристроїв  
Користувацький Перевірка 
інтерфейс зручності та 
інтуїтивності 
інтерфейсу для 
 користувачів 
Тестування Користувачі Успішно 
навігації по сайту можуть легко 
знайти потрібну 
інформацію, 
інтерфейс 
інтуїтивно 
 зрозумілий 
Перевірка Інтерфейс Успішно 
адаптивності коректно 
дизайну адаптується до 
різних розмірів 
екранів 
 
Після успішного системного тестування можна вважати, що система 
готова до впровадження в реальні умови та забезпечить потрібну 
функціональність та надійність для користувачів. 
3.2.4 Приймальне тестування 
Приймальне тестування (User Acceptance Testing, UAT) є важливим 
етапом у процесі впровадження системи та полягає в перевірці системи на 
відповідність вимогам та очікуванням кінцевих користувачів. Цей вид 
тестування проводиться самими користувачами або їх представниками. 
76 
ЧДТУ.242240 006 ПЗ 
Метою приймального тестування є переконання, що система відповідає 
потребам та очікуванням кінцевих користувачів та функціонує в реальних 
умовах відповідно до їхніх вимог. Під час цього тестування користувачі 
перевіряють різні аспекти системи, такі як інтерфейс користувача, 
функціональність, зручність використання та інші параметри. 
Приймальне тестування може включати наступні етапи: 
 планування тестування: визначення обсягу тестування, 
складання плану тестування та визначення критеріїв успішності; 
 підготовка тестових випадків: створення тестових випадків або 
сценаріїв, які будуть використовуватися під час тестування; 
 виконання тестів: користувачі або їхні представники виконують 
заплановані тестові випадки та реєструють результати; 
 аналіз результатів: оцінка результатів тестування, ідентифікація 
проблем та неузгодженостей, їхнє документування та вирішення; 
 затвердження системи: після успішного завершення 
приймального тестування система може бути затверджена для 
впровадження в реальні умови. 
Таблиця 3.5 
Проходження приймальних тестів 
Компонент Опис тесту Очікуваний результат Результат 
виконання 
/Модуль 
  
Функціональніст Перевірка основних 
ь функцій системи 
 
Реєстрація Користувачі можуть Успішно 
користувачів успішно 
реєструватися 
 
Авторизація Користувачі можуть Успішно 
користувачів успішно 
авторизуватися 
77 
ЧДТУ.242240 006 ПЗ 
Продовження таблиці 3.5 
 
Додавання, Турніри можуть бути Успішно 
редагування та успішно додані, 
видалення турнірів відредаговані та 
видалені 
 
Перегляд та Користувачі можуть Успішно 
коментування новин переглядати та 
коментувати новини 
 
Завантаження та Фотографії можуть Успішно 
відображення бути успішно 
фотографій завантажені та 
відображені 
  
Продуктивність Перевірка швидкодії та 
стійкості системи 
 
Тестування Система працює Успішно 
навантаженням стабільно під великим 
навантаженням 
 
Тестування часу Час відгуку Успішно 
відгуку відповідає вимогам 
  
Безпека Перевірка захищеності 
системи 
 
Перевірка захисту від Система захищена від Успішно 
основних видів атак основних видів атак 
(SQL ін'єкції, XSS, 
CSRF) 
 
Перевірка доступу до Неавторизовані Успішно 
захищених ресурсів користувачі не мають 
доступу до 
захищених ресурсів 
  
Сумісність Перевірка коректної 
роботи системи на 
різних платформах та 
браузерах 
 
78 
ЧДТУ.242240 006 ПЗ 
Продовження таблиці 3.5 
 
Тестування на різних Система коректно Успішно 
WEB–браузерах працює на всіх 
(Chrome, Firefox, Edge, основних WEB–
Safari) браузерах 
 
Тестування на різних Система коректно Успішно 
пристроях (ПК, відображається та 
планшети, смартфони) функціонує на всіх 
основних типах 
пристроїв 
  
Користувацький Перевірка зручності та 
інтерфейс інтуїтивності 
інтерфейсу для 
користувачів 
 
Тестування навігації Користувачі можуть Успішно 
по сайту легко знайти потрібну 
інформацію, 
інтерфейс інтуїтивно 
зрозумілий 
 
Перевірка Інтерфейс коректно Успішно 
адаптивності дизайну адаптується до різних 
розмірів екранів 
 
Приймальне тестування відображає реальне використання системи і 
дозволяє виявити потенційні проблеми або недоліки перед впровадженням 
системи в повний масштаб. 
3.3 Приклади впровадження програмного комплексу 
Впровадження програмного комплексу для Звенигородської районної 
федерації футболу включає декілька етапів, які забезпечують успішне 
інтегрування нової системи у вже існуючу структуру федерації. Основною 
метою цього процесу є безперебійний перехід до нової системи з 
79 
ЧДТУ.242240 006 ПЗ 
мінімальними зусиллями з боку користувачів та максимальним збереженням 
всіх існуючих даних. 
Етапи впровадження 
1  Підготовка інфраструктури: 
 оцінка поточної інфраструктури: Аналіз існуючих систем і 
технологій, які використовуються федерацією, для визначення 
необхідних змін та доповнень; 
 налаштування серверного середовища: Встановлення та 
конфігурація серверів для розміщення нового програмного 
комплексу, включаючи налаштування бази даних PostgreSQL та 
WEB–сервера. 
2  Міграція даних: 
 аудит існуючих даних: Перевірка та підготовка даних, які 
необхідно перенести в нову систему; 
 міграція даних: Перенесення існуючих даних про команди, 
турніри, матчі, гравців, новини та інші сутності з поточних 
систем у нову базу даних; 
 перевірка коректності міграції: Перевірка правильності 
перенесених даних для забезпечення їхньої цілісності та 
актуальності. 
3  Інтеграція з існуючими системами: 
 API–інтеграція: Налаштування інтеграцій з існуючими 
зовнішніми системами, які використовує федерація (наприклад, 
системи управління лігами або інші спортивні портали); 
 тестування інтеграцій: перевірка роботи всіх інтеграцій для 
забезпечення безперебійного обміну даними між системами. 
4  Навчання персоналу: 
 розробка навчальних матеріалів: Створення інструкцій та 
керівництв для користувачів системи; 
80 
ЧДТУ.242240 006 ПЗ 
 проведення навчальних сесій: Організація тренінгів та воркшопів 
для співробітників федерації, щоб навчити їх користуватися 
новим програмним забезпеченням. 
5  Тестування і налаштування: 
 тестування в реальних умовах: Проведення системного 
тестування та приймального тестування в умовах реальної 
експлуатації; 
 коригування налаштувань: Внесення необхідних змін та 
оптимізацій на основі зворотного зв'язку від користувачів та 
результатів тестування. 
6  Запуск системи в експлуатацію: 
 перехід на нову систему: Офіційне впровадження нової системи 
та відключення старих систем; 
 моніторинг та підтримка: Постійний моніторинг роботи системи 
для виявлення та усунення можливих проблем, а також надання 
технічної підтримки користувачам. 
Основні функціональні компоненти системи 
1. Головна сторінка: 
 Забезпечення користувачів актуальною інформацією про останні 
новини, анонси матчів та інші важливі події. 
2. Аутентифікація користувачів: 
 Надання можливості безпечного входу в систему для різних 
категорій користувачів, включаючи адміністраторів, тренерів, 
гравців та фанатів. 
3. Управління турнірами та матчами: 
 Створення, редагування та перегляд інформації про турніри та 
матчі, включаючи розклад, результати та статистику. 
4. Управління командами та гравцями: 
 Ведення детальної інформації про команди та гравців, 
включаючи їхні профілі, фотографії та статистичні дані. 
81 
ЧДТУ.242240 006 ПЗ 
5. Фотогалереї та медіа: 
 Завантаження та управління фотографіями, які ілюструють події 
та матчі, для покращення візуального контенту сайту. 
6. Система новин: 
 Створення та публікація новин про діяльність федерації, 
досягнення команд та інші релевантні події. 
7. Інтерактивні компоненти: 
 Форми для зворотного зв'язку, опитування та інші інтерактивні 
елементи для покращення взаємодії з користувачами. 
Впровадження нової інформаційної системи для Звенигородської 
районної федерації футболу сприятиме покращенню взаємодії між 
федерацією, командами та вболівальниками. Система забезпечить більш 
ефективне управління турнірами та матчами, покращить доступ до інформації 
та статистики, а також сприятиме популяризації футболу в регіоні. Успішне 
впровадження системи залежить від ретельного планування, підготовки та 
навчання персоналу, а також від постійної підтримки та оптимізації після 
запуску. 
  
82 
ЧДТУ.242240 006 ПЗ 
ВИСНОВКИ ПО РОЗДІЛУ 3 
Третій розділ присвячено детальному опису процесу створення і 
впровадження програмного комплексу для потреб Звенигородської районної 
федерації футболу. 
Спочатку розглядається обґрунтування вибору засобів реалізації, де 
виокремлені ключові аспекти та технології, які допомагають забезпечити 
оптимальну функціональність та ефективність системи. 
Далі викладений опис структурної (функціональної) схеми, яка ілюструє 
основні функції та взаємозв'язки між компонентами системи. 
Логічна схема системи подає послідовність дій, що відбувається у 
проектованому об'єкті, описуючи основні інформаційні процеси та їхній 
характер. 
Потім наведений опис розробки бази даних, в якому детально розглянуті 
структура таблиць та їх призначення у контексті системи футбольної 
федерації. 
Розробка інтерфейсу користувача відображає процес створення 
зручного та інтуїтивно зрозумілого інтерфейсу для користувачів системи. 
Опис розробки програмних компонентів включає у себе детальний огляд 
контролерів, які відповідають за обробку запитів на бекенді, що забезпечує 
функціональність та взаємодію всіх частин системи. 
Тестування системи проводиться на кількох рівнях – модульному, 
інтеграційному, системному та приймальному, забезпечуючи відповідність 
розробленого програмного забезпечення вимогам та стабільність роботи. 
У підрозділі "Приклади впровадження програмного комплексу" 
наведені конкретні кроки та етапи впровадження нової інформаційної системи 
для федерації футболу, що допомагає уникнути можливих проблем та 
забезпечити успішний перехід до нової системи. 
У цілому, розділ надає повну інформацію щодо процесу розробки, 
тестування та впровадження програмного комплексу, що допомагає 
забезпечити його ефективну та успішну реалізацію. 
83 
ЧДТУ.242240 006 ПЗ 
ВИСНОВКИ 
У результаті виконання кваліфікаційної роботи бакалавра було 
досягнуто поставлену мету – розроблено WEB–сайт для Звенигородської 
районної федерації футболу. 
Дана система дозволяє зручно взаємодіяти федерації, командам та 
фанатам футболу, забезпечуючи доступ до інформації про турніри, новини, 
фотографії та команди. 
У ході роботи були повністю вирішені задачі, які були поставлені в 
завданні на виконання кваліфікаційної роботи бакалавра: 
1  Проведено огляд систем аналогів WEB–сайту для футбольних 
федерацій. 
2  Проаналізовано переваги і недоліки існуючих систем аналогів. 
3  Обрано мови програмування та середовища розробки. 
4  Розроблено програмний продукт з описом прийомів оптимізації. 
5  Описано результати розробки. 
6  Проведено тестування розробленої системи. 
7  Впроваджено програмний комплекс у Звенигородську районну 
федерацію футболу. 
Інформаційна система була розроблена з використанням мов 
програмування Java, Spring Boot, JavaScript (JSX), React, HTML, CSS, а також 
бази даних PostgreSQL. 
Всі тести були пройдені успішно, і тому розроблений WEB–сайт готовий 
до впровадження та використання для розвитку футболу у Звенигородському 
районі. 
  
84 
ЧДТУ.242240 006 ПЗ 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1  Розглянутий аналог fifa.com [Електронний ресурс]. – Режим доступу: 
https://www.fifa.com/fifaplus/. Перевірено: 22.05.2024. 
2  Розглянутий аналог uefa.com [Електронний ресурс]. – Режим 
доступу: https://www.uefa.com/. Перевірено: 22.05.2024. 
3  Розглянутий аналог nba.corr [Електронний ресурс]. – Режим доступу: 
https://ua.tribuna.com/basketball/tournament/nba/?gr=www. Перевірено: 
22.05.2024. 
4  Розглянутий аналог mlssoccer.com [Електронний ресурс]. – Режим 
доступу: https://www.mlssoccer.com/. Перевірено: 22.05.2024. 
5  Розглянутий аналог tennis.com [Електронний ресурс]. – Режим 
доступу: https://www.tennis.com/. Перевірено: 22.05.2024. 
6  Розглянутий аналог join.football [Електронний ресурс]. – Режим 
доступу: https://go.join.football/. Перевірено: 22.05.2024. 
7  Сайт для розробки UML діаграм [Електронний ресурс]. – Режим 
доступу: https://plantuml.com/. Перевірено: 22.05.2024. 
8  Басс, Лен, Паул Клементс, Рік Казман. "Архітектура програмних 
систем". – Київ: Либідь, 2020. – 450 с. 
9  Мартін, Роберт. "Чиста архітектура: Керівництво для програмістів і 
архітекторів програмного забезпечення". – Харків: Видавництво "Фактор", 
2019. – 320 с. 
10  Соммервілль, Ян. "Інженерія програмного забезпечення". – Київ: 
Видавництво "Логос", 2018. – 880 с. 
11  Фаулер, Мартін. "Архітектурні патерни корпоративних додатків". – 
Львів: Видавництво "БаК", 2021. – 560 с. 
12  Гама, Еріх, Річард Хелм, Ральф Джонсон, Джон Влісідес. "Патерни 
проектування: Шаблони об'єктно–орієнтованого програмування". – Дніпро: 
Видавництво "Моноліт", 2017. – 395 с. 
13  Документація до Java [Електронний ресурс]. – Режим доступу: 
https://docs.oracle.com/en/java/. Перевірено: 22.05.2024. 
85 
ЧДТУ.242240 006 ПЗ 
14  Документація до Spring Boot [Електронний ресурс]. – Режим 
доступу: https://docs.spring.io/spring–boot/documentation.html. Перевірено: 
22.05.2024. 
15  Документація до JSX [Електронний ресурс]. – Режим доступу: 
https://legacy.reactjs.org/docs/introducing–jsx.html. Перевірено: 22.05.2024. 
16  Документація до React [Електронний ресурс]. – Режим доступу: 
https://legacy.reactjs.org/docs/getting–started.html. Перевірено: 22.05.2024. 
17  Документація до HTML [Електронний ресурс]. – Режим доступу: 
https://developer.mozilla.org/en–US/docs/Web/HTML. Перевірено: 22.05.2024. 
18  Документація до CSS [Електронний ресурс]. – Режим доступу: 
https://developer.mozilla.org/en–US/docs/Web/CSS. Перевірено: 22.05.2024. 
19  Документація до IDEA [Електронний ресурс]. – Режим доступу: 
https://www.jetbrains.com/help/idea/getting–started.html. Перевірено: 
22.05.2024. 
20  Документація до PostgreSQL [Електронний ресурс]. – Режим 
доступу: https://www.postgresql.org/docs/. Перевірено: 22.05.2024. 
  
86 
ЧДТУ.242240 006 ПЗ 
ДОДАТОК А 
ЗАТВЕРДЖЕНО: 
Зав. кафедрою ПЗАС, професор 
_________________ Голуб С.В. 
„____” ______________ 2024 р. 
 
 
Розробка WEB–сайту для Звенигородської районної федерації футболу 
 
 
 
 
Специфікація 
482. ЧДТУ 242240.005 
 
 
 
Розробник ________________ Кравець В. В. 
Керівник ________________ Немов Р. Г. 
 
 
 
 
 
 
 
 
2024 
87 
ЧДТУ.242240 006 ПЗ 
Позначення Найменування Примітка 
 Документація  
482. ЧДТУ 242240 12 01 Текст програми  
482. ЧДТУ 2422 40 34 01 Інструкція користувачеві  
482. ЧДТУ 2422 40 90 01 Презентація  
 
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
88 
 
ДОДАТОК Б 
  
  
  
  
Розробка WEB–сайту для Звенигородської районної федерації футболу 
 
  
   
  
 
 
  
Текст програми 
482. ЧДТУ 242240 12 01 
Листів 14 
  
  
  
 Розробник  ________________       Кравець В.В.  
  
 
 
 
 
 
  
  
2024 
 
public class AuthController { 
    private final AuthService authService; 
    @PostMapping("/login") 
    public ResponseEntity<?> createAuthToken(@RequestBody JwtRequest 
authRequest) { 
        return authService.createAuthToken(authRequest); 
    } 
    @PostMapping("/registration") 
    public ResponseEntity<?> createNewUser(@RequestBody RegistrationUserDto 
registrationUserDto) { 
        return authService.createNewUser(registrationUserDto); 
    } 
    @GetMapping("/info") 
    public String userData(Principal principal) { 
        return principal.getName(); 
    } 
    @GetMapping("/admin") 
    @Secured("ROLE_ADMIN") 
    public String adminData() { 
        return "Admin data"; 
    } 
} 
public class CardController { 
    private final CardService cardService; 
    @Autowired 
    public CardController(CardService cardService) { 
        this.cardService = cardService; 
    } 
    @GetMapping 
    public List<Card> getAllCards() { 
        return cardService.getAllCards(); 
    } 
    @GetMapping("/{cardId}") 
    public Card getCardById(@PathVariable Integer cardId) { 
        return cardService.getCardById(cardId); 
    } 
    @PostMapping 
    public Card createCard(@RequestBody Card card) { 
        return cardService.createCard(card); 
    } 
    @PutMapping("/{cardId}") 
ЧДТУ.242240 006 ПЗ 
    public Card updateCard(@PathVariable Integer cardId, @RequestBody Card 
updatedCard) { 
        return cardService.updateCard(cardId, updatedCard); 
    } 
    @DeleteMapping("/{cardId}") 
    public boolean deleteCard(@PathVariable Integer cardId) { 
        return cardService.deleteCard(cardId); 
    } 
} 
public class FootballTeamController { 
    private FootballTeamService footballTeamService; 
    private FootballTeamMapper footballTeamMapper; 
    @GetMapping 
    public List<FootballTeams> getAllFootballTeams() { 
        return footballTeamService.getAllFootballTeam(); 
    } 
    @GetMapping("/footballTeamById/{footballTeamId}") 
    public FootballTeam getFootballTeamById(@PathVariable int footballTeamId) 
{ 
        return footballTeamService.getFootballTeamById(footballTeamId); 
    } 
    @GetMapping("/{footballTeamId}") 
    public FootballTeamDTO getFootballTeamId(@PathVariable int 
footballTeamId) { 
        return 
footballTeamMapper.toFootballTeam(footballTeamService.getFootballTeam(footb
allTeamId)); 
    } 
    @GetMapping("/getInfo/{footballTeamId}") 
    public FootballTeamInfo getInfoByFootballTeamId(@PathVariable int 
footballTeamId) { 
        return footballTeamService.getInfoByFootballTeamId(footballTeamId); 
    } 
    @GetMapping("/getMatches/{footballTeamId}") 
    public List<MatchInfo> getMatchesByFootballTeamId(@PathVariable int 
footballTeamId) { 
        return footballTeamService.getMatchesByFootballTeamId(footballTeamId); 
    } 
    @PostMapping 
    @Secured("ROLE_ADMIN") 
    public FootballTeam createFootballTeam(@RequestPart @Valid 
91 
ЧДТУ.242240 006 ПЗ 
FootballTeamDTO footballTeam, @RequestPart("file") MultipartFile file) { 
        return footballTeamService.createFootballTeam(footballTeam, file); 
    } 
    @PutMapping("/{footballTeamId}") 
    @Secured("ROLE_ADMIN") 
    public FootballTeam updateTeam(@PathVariable int footballTeamId, 
@RequestPart @Valid FootballTeamDTO footballTeam, 
                                   @RequestPart(value = "file", required = false) MultipartFile 
file) { 
        return footballTeamService.updateFootballTeam(footballTeamId, 
footballTeam, file); 
    } 
    @DeleteMapping("/{footballTeamId}") 
    @Secured("ROLE_ADMIN") 
    public ResponseEntity<Void> deleteFootballTeam(@PathVariable int 
footballTeamId) { 
        if (footballTeamService.deleteFootballTeam(footballTeamId)) { 
            return ResponseEntity.noContent().build(); 
        } else { 
            return ResponseEntity.notFound().build(); 
        } 
    } 
} 
public class MatchController { 
    private final MatchService matchService; 
    @GetMapping 
    public List<Match> getAllMatches() { 
        return matchService.getAllMatch(); 
    } 
    @GetMapping("/{matchId}") 
    public GetIDMatchDTO getMatchById(@PathVariable int matchId) { 
        return matchService.getMatchById(matchId); 
    } 
    @GetMapping("/getAllMathByTourId/{tourId}") 
    public List<MatchAllByTourId> getAllMatchByTourId(@PathVariable int 
tourId) { 
        return matchService.getAllMatchByTournamentId(tourId); 
    } 
 
    @PostMapping() 
    @Secured("ROLE_ADMIN") 
92 
ЧДТУ.242240 006 ПЗ 
    public Match createMatch(@RequestBody MatchDTO matchDTO) { 
        return matchService.createMatch(matchDTO); 
    } 
    @PutMapping(value = "/{matchId}") 
    @Secured("ROLE_ADMIN") 
    public Match updateMatch(@PathVariable int matchId, @RequestBody @Valid 
MatchDTO updateMatchDto) { 
        return matchService.updateMatch(matchId, updateMatchDto); 
    } 
    @DeleteMapping("/{matchId}") 
    @Secured("ROLE_ADMIN") 
    public ResponseEntity<Void> deleteMatch(@PathVariable int matchId) { 
        if (matchService.deleteMatch(matchId)) { 
            return ResponseEntity.noContent().build(); 
        } else { 
            return ResponseEntity.notFound().build(); 
        } 
    } 
} 
@AllArgsConstructor 
public class NewsController { 
    private final NewsService newsService; 
    private final NewsMapper newsMapper; 
    @GetMapping 
    public List<NewsGetAllDTO> getAllNews() { 
        return newsMapper.toNewsDTOList(newsService.getAllNews()); 
    } 
    @GetMapping("/{newsId}") 
    public NewsGetAllDTO getNewsById(@PathVariable int newsId) { 
        return newsMapper.toNewsDTO(newsService.getNewsById(newsId)); 
    } 
    @PostMapping(consumes = 
{MediaType.MULTIPART_FORM_DATA_VALUE, 
MediaType.APPLICATION_OCTET_STREAM_VALUE}, produces = 
MediaType.APPLICATION_JSON_VALUE) 
    @Secured("ROLE_ADMIN") 
    public ResponseEntity<News> createNews(@RequestPart("file") MultipartFile 
file, @RequestPart("news") NewsDTO news) { 
        News createdNews = newsService.createNews(news,file); 
        return ResponseEntity.status(HttpStatus.CREATED).body(createdNews); 
    } 
93 
ЧДТУ.242240 006 ПЗ 
    @PutMapping(value = "/{newsId}", 
            consumes = {MediaType.MULTIPART_FORM_DATA_VALUE, 
MediaType.APPLICATION_OCTET_STREAM_VALUE}, 
            produces = MediaType.APPLICATION_JSON_VALUE) 
    @Secured("ROLE_ADMIN") 
    public News updateNews(@PathVariable int newsId, @RequestBody @Valid 
NewsDTO updatedNews, @RequestPart("file") MultipartFile file) { 
        return newsService.updateNews(newsId, updatedNews, file); 
    } 
    @DeleteMapping("/{newsId}") 
    @Secured("ROLE_ADMIN") 
    public ResponseEntity<Void> deleteNews(@PathVariable int newsId) { 
        if (newsService.deleteNews(newsId)) { 
            return ResponseEntity.noContent().build(); 
        } else { 
            return ResponseEntity.notFound().build(); 
        } 
    } 
    @GetMapping("/global–news") 
    public ResponseEntity<Object> getSportNews() { 
        // URL for fetching top headlines in sports category for Ukraine 
        String newsUrl = "https://newsapi.org/v2/top–
headlines?country=ua&category=sport&apiKey=30bc5fff4e7b45bc934bc29e5077
b2da"; 
        // Creating a RestTemplate client 
        RestTemplate restTemplate = new RestTemplate(); 
 
        // Returning the response from the News API 
        return restTemplate.getForEntity(newsUrl, Object.class); 
    } 
} 
 
 
 
  
94 
ЧДТУ.242240 006 ПЗ 
ДОДАТОК В 
  
  
  
  
Розробка WEB–сайту для Звенигородської районної федерації футболу 
 
  
   
  
 
 
 
  
Інструкція користувачеві 
482. ЧДТУ 242240 34 01 
Листів 14 
  
  
  
 Розробник  ________________       Кравець В.В.  
  
 
 
 
 
 
  
  
2024 
95 
ЧДТУ.242240 006 ПЗ 
Головна сторінка 
1 Про федерацію 
  На головній сторінці знаходиться інформація про федерацію 
футболу Звенигородської об'єднаної територіальної громади Черкаської 
області. Тут ви можете подивитись головні новини України. 
 
Рисунок В1 – Головна сторінка сайту 
 
96 
ЧДТУ.242240 006 ПЗ 
2 Турніри 
  Розділ "Турніри" дозволяє переглядати інформацію про поточні та 
минулі турніри, організовані федерацією. Кожен турнір має свою картку, де 
вказано назву, дати проведення та кількість команд–учасниць. Для 
перегляду детальної інформації про турнір натисніть на відповідну картку. 
 
 
Рисунок Б2 – Сторінка з турнірами 
 
3 Учасники 
  У розділі "Учасники" можна переглянути список команд, які беруть 
участь у турнірах федерації. Ви можете знайти команду за назвою або 
переглянути всі доступні команди. Кожна команда має свою картку з 
97 
ЧДТУ.242240 006 ПЗ 
інформацією та фото. Для детальнішого ознайомлення з командою натисніть 
на її картку. 
 
 
Рисунок Б3 – Сторінка учасників проекту 
 
4 Новини 
 Розділ "Новини" містить останні новини зі світу спорту, 
зокрема про події та досягнення, пов'язані з футболом у регіоні. 
Натиснувши на новину, ви зможете прочитати повний текст статті. 
98 
ЧДТУ.242240 006 ПЗ 
 
Рисунок Б4 – Сторінка новин 
5 Контакти 
  У розділі "Контакти" знаходиться контактна інформація федерації, 
включаючи адресу, телефон та електронну пошту. Цей розділ також містить 
форму зворотного зв'язку, де ви можете залишити свої запитання або 
пропозиції. 
6 Авторизуватися 
  Кнопка "Авторизуватися" дозволяє увійти на сайт під своїм 
обліковим записом. Якщо ви ще не маєте облікового запису, ви можете 
зареєструватися, заповнивши відповідну форму реєстрації. 
 
99 
ЧДТУ.242240 006 ПЗ 
 
Рисунок Б5 – Сторінка авторизації 
 
Рисунок Б6 – Сторінка реєстрації 
 
100 
ЧДТУ.242240 006 ПЗ 
Перегляд турнірів 
1  Зайдіть у розділ "Турніри" через головне меню. 
2  Оберіть турнір, який вас цікавить, натиснувши на відповідну 
картку. 
3  На сторінці турніру ви зможете переглянути деталі про команди–
учасниці, розклад матчів та результати. 
Перегляд учасників 
1  Зайдіть у розділ "Учасники" через головне меню. 
2  Використовуйте пошук для швидкого знаходження потрібної 
команди або переглядайте всі доступні команди. 
3  Натисніть на картку команди для перегляду детальної інформації. 
Отримання останніх новин 
1  Зайдіть у розділ "Новини" через головне меню. 
2  Переглядайте заголовки та короткий опис новин. 
3  Натисніть на новину, щоб прочитати повний текст. 
Зворотній зв'язок 
1  Зайдіть у розділ "Контакти" через головне меню. 
2  Використовуйте надану контактну інформацію для зв'язку з 
федерацією. 
3  Заповніть форму зворотного зв'язку для відправлення запитань або 
пропозицій. 
Додаткові можливості після авторизації під адміністратором 
Після авторизації під обліковим записом адміністратора з'являються 
додаткові кнопки для керування вмістом сайту: 
 Турніри: У цьому розділі з'являється кнопка для додавання 
нових турнірів. Адміністратор може створювати нові турніри, 
101 
ЧДТУ.242240 006 ПЗ 
вказуючи їхні назви, дати проведення та іншу необхідну 
інформацію. 
 
 
Рисунок Б7 – Кнопка Додати турнір після авторизації 
 
 
Рисунок Б8 – Форма створення турніру 
102 
ЧДТУ.242240 006 ПЗ 
 
 Матчі: На сторінках турнірів з'являється можливість 
додавання матчів у рамках конкретного турніру. Адміністратор може 
вказувати команди, дату та час проведення матчу, а також результати 
після його завершення. 
 
 
Рисунок Б9 – Форма створення матчу 
 
 Учасники: У цьому розділі адміністратор може додавати нові 
команди–учасники, редагувати існуючі команди та видаляти команди, 
які більше не беруть участі у змаганнях. 
103 
ЧДТУ.242240 006 ПЗ 
 
Рисунок Б10 – Кнопка додати після авторизації 
 
Рисунок Б11 – Форма додавання команди 
104 
ЧДТУ.242240 006 ПЗ 
 
 Новини: У розділі новин з'являється кнопка для додавання 
нових статей. Адміністратор може створювати нові новини, 
публікувати статті та оновлювати інформацію. 
 
Рисунок Б12 – Форма додавання новин 
 
  
105 
ЧДТУ.242240 006 ПЗ 
ДОДАТОК Г 
  
  
  
  
Розробка WEB–сайту для Звенигородської районної федерації футболу 
 
  
   
  
  
Презентація 
482. ЧДТУ 242240.005   
Листів 14  
  
  
  
 Розробник  ________________       Кравець В.В.  
  
 
 
 
  
  
 
2024 
106 
ЧДТУ.242240 006 ПЗ 
 
Рисунок Г1 – Слайд 1 
 
Рисунок Г2 – Слайд 2 
107 
ЧДТУ.242240 006 ПЗ 
  
Рисунок Г3 – Слайд 3 
  
Рисунок Г4 – Слайд 4 
108 
ЧДТУ.242240 006 ПЗ 
 
 
Рисунок Г5 – Слайд 5 
 
 
Рисунок Г6 – Слайд 6 
 
109 
ЧДТУ.242240 006 ПЗ 
  
Рисунок Г7 – Слайд 7 
 
  
Рисунок Г8 – Слайд 8 
110 
ЧДТУ.242240 006 ПЗ 
  
Рисунок Г9 – Слайд 9 
 
 
Рисунок Г10 – Слайд 10 
 
111 
ЧДТУ.242240 006 ПЗ 
  
Рисунок Г11 – Слайд 11 
 
 
Рисунок Г12 – Слайд 12 
 
112 
ЧДТУ.242240 006 ПЗ 
 
Рисунок Г13 – Слайд 13 
 
  
Рисунок Г14 – Слайд 14 
113 
ЧДТУ.242240 006 ПЗ 
 
Рисунок Г15 – Слайд 15 
 
 
114