Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/8909
Назва: Програмне забезпечення комп’ютерної гри в «Покер»
Автори: Півень, Олександр Борисович
Олійніченко, Ярослав Павлович
Ключові слова: покер;Java;JavaFX;штучний інтелект;ігрові алгоритми;UML-моделювання;об'єктно-орієнтоване програмування;poker;Java;JavaFX;artificial intelligence;game algorithms;UML modeling;object-oriented programming
Дата публікації: 26-чер-2025
Короткий огляд (реферат): АНОТАЦІЇ Виконавець: Олійніченко Ярослав Павлович. Назва роботи: "Програмне забезпечення розробки гри в Покер". Спеціальність: 121 Інженерія програмного забезпечення. Навчальний заклад: «Черкаський державний технологічний університет» м. Черкаси, 2025р. Дипломна робота присвячена проектуванню та реалізації повноцінного програмного забезпечення для офлайн-гри в покер із застосуванням сучасних технологій Java та JavaFX. Метою роботи є створення інтерактивного покерного симулятора з розвиненим штучним інтелектом, що забезпечує реалістичний ігровий процес для навчання та розваги. Проведено комплексний аналіз існуючих рішень на ринку покерного програмного забезпечення, виявлено їх технічні обмеження та недоліки. На основі цього аналізу сформульовано вимоги до нової системи, що включають автономний режим роботи, модульну архітектуру, адаптивний штучний інтелект та інтуїтивний користувацький інтерфейс. Розроблено детальну архітектуру програмної системи з використанням UML-моделювання, включаючи діаграми класів, прецедентів, послідовності, діяльності та компонентів. Реалізовано три рівні складності ботів (початковий, середній, експертний) з різними стратегіями прийняття рішень, що базуються на аналізі сили руки, позиції за столом та поведінки опонентів. Створено сучасний графічний інтерфейс засобами JavaFX з підтримкою анімацій, візуальних ефектів та адаптивного дизайну. Система включає механізми збереження ігрового прогресу, збору статистики та аналізу результатів гри. Проведено комплексне тестування програмного забезпечення, що включає модульне, інтеграційне, системне та користувацьке тестування. Результати підтвердили відповідність системи поставленим вимогам та її готовність до практичного використання. Розроблене програмне забезпечення може використовуватися як навчальний інструмент для вивчення теорії ймовірностей та прийняття рішень, а також як платформа для розваги та вдосконалення покерних навичок.
ANNOTATIONS Performer: Oliinychenko Yaroslav Pavlovych. The title of the work: "Software Development for Poker Game". Specialty: 121 Software Engineering. Educational institution: Cherkasy State Technological University, Cherkasy, 2025. This thesis is dedicated to the design and implementation of comprehensive offline poker game software using modern Java and JavaFX technologies. The aim of the work is to create an interactive poker simulator with advanced artificial intelligence that provides a realistic gaming experience for learning and entertainment. A comprehensive analysis of existing solutions in the poker software market was conducted, revealing their technical limitations and shortcomings. Based on this analysis, requirements for the new system were formulated, including autonomous operation mode, modular architecture, adaptive artificial intelligence, and intuitive user interface. A detailed software system architecture was developed using UML modeling, including class diagrams, use case diagrams, sequence diagrams, activity diagrams, and component diagrams. Three levels of bot complexity (beginner, intermediate, expert) were implemented with different decision-making strategies based on hand strength analysis, table position, and opponent behavior. A modern graphical interface was created using JavaFX with support for animations, visual effects, and adaptive design. The system includes mechanisms for saving game progress, collecting statistics, and analyzing game results. Comprehensive software testing was conducted, including unit, integration, system, and user testing. The results confirmed the system's compliance with the requirements and its readiness for practical use. The developed software can be used as an educational tool for studying probability theory and decision-making, as well as a platform for entertainment and improving poker skills.
URI (Уніфікований ідентифікатор ресурсу): https://er.chdtu.edu.ua/handle/ChSTU/8909
Розташовується у зібраннях:121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)

Файли цього матеріалу:
Файл Опис РозмірФормат 
Кваліфікаційна робота бакалавра Олійніченко Ярослав Павлович.pdf
  Restricted Access
2.86 MBAdobe PDFПереглянути/Відкрити    Запит копії


Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.

Extracted text
 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«бакалавра» 
освітній рівень 
 
на тему: «Програмне забезпечення розробки гри в Покер» 
 
Виконав: студент 4 курсу, групи ПЗ-2104 
Спеціальності  
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
 
Студент Олійніченко Я.П. 
 (прізвище та ініціали) 
Керівник Півень О.Б. 
 (прізвище та ініціали) 
Рецензент Люта М.В. 
 (прізвище та ініціали) 
 
 
 
 
 
Черкаси 2025 
 
 
______________Черкаський державний технологічний університет___________________ 
повне найменування вищого навчального закладу 
Факультет  інформаційних технологій і систем  
Кафедра   програмного забезпечення автоматизованих систем  
Освітній рівень  бакалавр  
Спеціальність  121 «Інженерія програмного забезпечення»  
Освітня програма Інженерія програмного забезпечення  
 
ЗАТВЕРДЖУЮ 
Зав. кафедри ПЗАС, професор 
___________                  Голуб С.В. 
«___» _______________ 2025 року 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ 
___________________________Олійніченко Ярослав Павлович_______________________ 
(прізвище, ім’я, по батькові) 
Тему проекту (роботи) «Програмне забезпечення розробки гри в покер»  
Керівник проекту (роботи) Півень Олександр Борисович кандидат наук, доцент  
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання) 
Затверджені наказом Черкаського державного технологічного університету від «25» лютого 2025 
№53/03-03 
2. Строк подання студентом проекту (роботи)  16.червня 2025р 
3. Вхідні дані до проекту (роботи) Технічне завдання на розробку, методичні рекомендації до 
виконання бакалаврської роботи, автоматизовані системи, терміни та визначення.  
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)  
Вступ;  
Розділ 1. Існуючі методи та засоби розв’язання поставлених завдань;  
Розділ 2. Впровадження результатів досліджень у практику проектування програмного  
забезпечення інформаційних систем;  
Розділ 3. Розробка та тестування програмного забезпечення;  
Висновки;  
Список використаних джерел;  
Додатки.  
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту; 
Слайд 1; Слайд 2; Слайд 3; Слайд 4; Слайд 5; Слайд 6; Слайд 7; Слайд 8; Слайд 9; Слайд 10; Слайд 11; 
Слайд 12; Слайд 13; Слайд 14; Слайд 15; Слайд 16.  
6. Консультанти розділів проекту (роботи) 
 
Прізвище, ініціали та посади Підпис, дата 
Розділ 
консультанта Завдання видав Завдання прийняв 
1 
2 
3 
7. Дата видачі завдання 02 грудня 2024 р.
КАЛЕНДАРНИЙ ПЛАН 
Строк виконання 
№ 
Назва етапів випускної роботи етапів випускної Примітки 
п/п
роботи 
1 Постановка задачі 05.12.2024 виконано 
2 Підготовка завдання 13.12.2024 виконано 
3 Погодження завдання 16.12.2024 виконано 
4 Затвердження завдання 19.02.2025 виконано 
Основна стадія 
1 Підбір матеріалів 27.02.2025 виконано 
2 Аналіз шляхів вирішення поставленої задачі 04.02.2025 виконано 
3 Розрахунок основних параметрів роботи 10.03.2025 виконано 
4 Вибір кінцевого варіанту проектного рішення 17.03.2025 виконано 
5 Оформлення первісної редакції роботи 25.03.2025 виконано 
Заключна стадія 
1 Узгодження прийнятих проектних рішень з 31.04.2025 виконано 
керівником 
О2формлення пояснювальної записки роботи в 13.05.2025 виконано 
кінцевій редакції 
П3опередній захист роботи 15.05.2025 виконано 
З4атвердження роботи 31.05.2025 виконано 
Р5ецензування роботи 20.05.2025 виконано 
З6ахист роботи 20.06.2025 
Студент _____________________ Олійніченко Я.П. 
 (підпис)  (прізвище та ініціали) 
Керівник проекту (роботи) _____________________ Півень О.Б. 
 (підпис)  (прізвище та ініціали)
 
АНОТАЦІЇ 
Виконавець: Олійніченко Ярослав Павлович.  
Назва роботи: "Програмне забезпечення розробки гри в Покер".  
Спеціальність: 121 Інженерія програмного забезпечення. 
Навчальний заклад: «Черкаський державний технологічний університет» м. 
Черкаси, 2025р. 
Дипломна робота присвячена проектуванню та реалізації повноцінного 
програмного забезпечення для офлайн-гри в покер із застосуванням сучасних 
технологій Java та JavaFX. Метою роботи є створення інтерактивного покерного 
симулятора з розвиненим штучним інтелектом, що забезпечує реалістичний 
ігровий процес для навчання та розваги. 
Проведено комплексний аналіз існуючих рішень на ринку покерного 
програмного забезпечення, виявлено їх технічні обмеження та недоліки. На основі 
цього аналізу сформульовано вимоги до нової системи, що включають 
автономний режим роботи, модульну архітектуру, адаптивний штучний інтелект 
та інтуїтивний користувацький інтерфейс. 
Розроблено детальну архітектуру програмної системи з використанням 
UML-моделювання, включаючи діаграми класів, прецедентів, послідовності, 
діяльності та компонентів. Реалізовано три рівні складності ботів (початковий, 
середній, експертний) з різними стратегіями прийняття рішень, що базуються на 
аналізі сили руки, позиції за столом та поведінки опонентів. 
Створено сучасний графічний інтерфейс засобами JavaFX з підтримкою 
анімацій, візуальних ефектів та адаптивного дизайну. Система включає механізми 
збереження ігрового прогресу, збору статистики та аналізу результатів гри. 
Проведено комплексне тестування програмного забезпечення, що включає 
модульне, інтеграційне, системне та користувацьке тестування. Результати 
підтвердили відповідність системи поставленим вимогам та її готовність до 
практичного використання. 
 
 
Розроблене програмне забезпечення може використовуватися як навчальний 
інструмент для вивчення теорії ймовірностей та прийняття рішень, а також як 
платформа для розваги та вдосконалення покерних навичок. 
Ключові слова: покер, Java, JavaFX, штучний інтелект, ігрові алгоритми, 
UML-моделювання, об'єктно-орієнтоване програмування  
 
  
 
 
ANNOTATIONS 
Performer: Oliinychenko Yaroslav Pavlovych. 
The title of the work: "Software Development for Poker Game". 
Specialty: 121 Software Engineering. 
Educational institution: Cherkasy State Technological University, Cherkasy, 2025. 
This thesis is dedicated to the design and implementation of comprehensive 
offline poker game software using modern Java and JavaFX technologies. The aim of 
the work is to create an interactive poker simulator with advanced artificial intelligence 
that provides a realistic gaming experience for learning and entertainment. 
A comprehensive analysis of existing solutions in the poker software market was 
conducted, revealing their technical limitations and shortcomings. Based on this 
analysis, requirements for the new system were formulated, including autonomous 
operation mode, modular architecture, adaptive artificial intelligence, and intuitive user 
interface. 
A detailed software system architecture was developed using UML modeling, 
including class diagrams, use case diagrams, sequence diagrams, activity diagrams, and 
component diagrams. Three levels of bot complexity (beginner, intermediate, expert) 
were implemented with different decision-making strategies based on hand strength 
analysis, table position, and opponent behavior. 
A modern graphical interface was created using JavaFX with support for 
animations, visual effects, and adaptive design. The system includes mechanisms for 
saving game progress, collecting statistics, and analyzing game results. 
Comprehensive software testing was conducted, including unit, integration, 
system, and user testing. The results confirmed the system's compliance with the 
requirements and its readiness for practical use. 
The developed software can be used as an educational tool for studying 
probability theory and decision-making, as well as a platform for entertainment and 
improving poker skills. 
Keywords: poker, Java, JavaFX, artificial intelligence, game algorithms, UML 
modeling, object-oriented programming. 
 
 
  
 
ЗМІСТ 
ВСТУП ................................................................................................................... 6 
РОЗДІЛ 1 Аналіз предметної області та постановка задачі ............................ 11 
1.1 Актуальність розробки програмного забезпечення гри в покер .......... 11 
1.2 Аналіз існуючих програмних рішень для гри в покер .......................... 12 
1.3 Формування вимог до програмного забезпечення та обгрунтування 
вибору Java як мови програмування ....................................................................... 16 
1.4 Постановка задачі...................................................................................... 19 
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ ............................................................ 21 
РОЗДІЛ 2 Проєктування програмного забезпечення гри в Покер ................. 23 
2.1 Моделювання предметної області ........................................................... 23 
2.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області ......................................................................................... 24 
2.1.2 Побудова словника предметної області ........................................... 25 
2.1.3 Робоча область моделювання ............................................................ 26 
2.2 Формування та аналіз вимог .................................................................... 28 
2.2.1 Функціональні та нефункціональні вимоги до програмного 
забезпечення........................................................................................................... 28 
2.2.2 Формування вимог за допомогою діаграми прецедентів ............... 31 
2.3 Проектування логічної структури програмного комплексу .................. 35 
2.3.1 Діаграми класів .................................................................................. 35 
 
ЧДТУ 252164-018 ПЗ 
Змн. Арк . № докум. Підпис Дата 
Розроб. Олійніченко « Програмне забезпечення Літ. Лист Листів 
Перевір.  ЯП.іПве. нь О. Б. розробки гри в покер» 3  
Рецензент Люта М. В. Пояснювальна записка. 
Н. Контр.  Півень О. Б. ФІТІС, кафедра ПЗАС, ПЗ-2104 
 
Затверд. Голуб С. В. 
 
 
 
2.3.2 Діаграма пакетів ................................................................................. 37 
2.4 Архітектура проектування ....................................................................... 39 
2.4.1 Діаграма компонентів ........................................................................ 40 
2.4.2 Проєктування розгортання програмної системи ............................ 41 
2.5 Моделювання поведінки системи ............................................................ 44 
2.5.1 Розробка діаграми діяльності ........................................................... 44 
2.5.2 Проєктування діаграми послідовності ............................................. 47 
2.5.3 Побудова діаграми комунікації ......................................................... 48 
2.5.4 Розробка діаграми скінченного автомату ........................................ 50 
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ ............................................................. 52 
РОЗДІЛ 3 Реалізація програмного забезпечення для гри в покер .................. 53 
3.1 Вибір мови програмування, середовища розробки та бібліотек .......... 53 
3.1.1Загальна структура програмного забезпечення ............................... 55 
3.1.2 Реалізація логіки гри .......................................................................... 61 
3.1.3 Розробка графічного інтерфейсу користувача ................................ 67 
3.1.4 Тестування програмного забезпечення ............................................ 71 
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ ........................................................... 74 
ВИСНОВКИ ......................................................................................................... 75 
 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .................................................................... 77 
 
ЧДТУ 252155-008 ПЗ 
Змн. Арк. № докум. Підпис Дата 
      
 
ЧДТУ 252164.016ПЗ 
ВСТУП 
Актуальність теми зумовлена зростаючими вимогами до якості 
настільного програмного забезпечення, необхідністю створення офлайн-
додатків з розвиненим штучним інтелектом, а також потребою у впровадженні 
сучасних підходів до архітектурного проектування програмних систем. 
Розробка повноцінного покерного симулятора дозволяє продемонструвати 
практичне застосування принципів об'єктно-орієнтованого програмування, 
реалізувати складні алгоритми оцінки ігрових ситуацій та створити адаптивний 
користувацький інтерфейс засобами JavaFX. 
Метою роботи є проектування та розробка програмного забезпечення для 
офлайн-гри в покер із застосуванням сучасних технологій Java, що забезпечує 
реалістичний ігровий процес з ботами різних рівнів складності, інтуїтивний 
графічний інтерфейс та систему аналітики ігрового прогресу. 
Для досягнення поставленої мети необхідно вирішити такі завдання: 
 провести аналіз існуючих програмних рішень та виявити їх технічні 
обмеження з точки зору архітектури та функціональності; 
 розробити архітектуру програмної системи з використанням 
сучасних патернів проектування та принципів модульності; 
 спроектувати та реалізувати алгоритми штучного інтелекту для 
ботів з різними стратегіями поведінки; 
 створити адаптивний графічний інтерфейс користувача засобами 
JavaFX; 
 розробити систему зберігання та аналізу ігрових даних; 
 провести комплексне тестування програмного забезпечення з метою 
забезпечення його надійності та стабільності. 
Об'єктом дослідження є процеси проектування та розробки програмного 
забезпечення з настільного та реалізацією штучного інтелекту та графічного 
інтерфейсу користувача засобами платформи Java. 
Предметом дослідження є процеси створення програмного забезпечення 
та архітектури програмних систем, алгоритми прийняття рішень в умовах 
6 
ЧДТУ 252164.016ПЗ 
неповної інформації, а також засоби розробки інтерактивних користувацьких 
інтерфейсів. 
Методи дослідження включають: об'єктно-орієнтоване проектування 
програмних систем, UML-моделювання архітектури додатків, алгоритми 
штучного інтелекту для ігрових стратегій, технології розробки графічних 
інтерфейсів користувача, методи тестування програмного забезпечення. 
Опис отриманих результатів. У результаті виконання бакалаврської 
роботи було створено повнофункціональний програмний продукт — 
настільний симулятор гри в покер за правилами Техаського Холдему, який 
працює в офлайн-режимі та реалізує взаємодію з ботами різного рівня 
складності. На основі проведеного аналізу існуючих програмних рішень 
сформовано технічне завдання, яке лягло в основу архітектури застосунку. 
Система розроблена за принципами об'єктно-орієнтованого програмування з 
урахуванням модульності, повторного використання коду та забезпечення 
масштабованості. Під час реалізації було впроваджено архітектуру з чітким 
розділенням функціональних компонентів: логіки гри, штучного інтелекту, 
графічного інтерфейсу та обробки ігрових даних. Усі компоненти описано за 
допомогою UML-діаграм, що дозволило узгодити логіку системи ще на етапі 
проєктування. Ігрова логіка реалізована відповідно до класичних правил 
Техаського Холдему, включаючи послідовність роздачі, структуру раундів, 
систему ставок і визначення переможця на основі комбінацій карт. Для 
реалізації інтелектуальної поведінки створено три рівні складності ботів: від 
простого випадкового вибору дій до стратегічного аналізу ситуації на основі 
оцінки сили руки, поточних ставок та ймовірних результатів. Інтерфейс 
користувача реалізовано за допомогою JavaFX — він забезпечує візуалізацію 
ігрового процесу, взаємодію з гравцем, відображення стану гри, карт, банку та 
дій гравців. Також реалізовано систему зберігання ігрових даних із можливістю 
перегляду історії ігор та основних статистичних показників, що дозволяє 
аналізувати ефективність гри та прогрес користувача. Проведено комплексне 
тестування функціональних модулів та інтегрованої системи, що підтвердило її 
стабільну роботу, правильність обчислень і надійність у процесі експлуатації. 
7 
ЧДТУ 252164.016ПЗ 
Створене програмне забезпечення відповідає поставленим вимогам і може бути 
використане як повноцінний симулятор гри в покер для одного користувача з 
підтримкою гри проти інтелектуальних супротивників. 
Архітектура системи. Розроблено модульну архітектуру програмного 
забезпечення із чітким розділенням компонентів: логіки гри, обробки даних, 
графічного інтерфейсу та модуля штучного інтелекту. Проєкт було побудовано 
на основі патернів MVC (Model-View-Controller) та Strategy, що забезпечило 
легкість підтримки, розширюваність і масштабованість застосунку. 
Гра за правилами Техаського Холдему. У систему повністю 
інтегровано ігрову логіку покеру: ініціалізація гри, роздача карт, хід ставок, 
визначення комбінацій та обчислення переможця відповідно до стандартних 
правил. Реалізовано різні типи дій гравця (check, call, raise, fold), а також 
управління ігровим банком. 
Штучний інтелект. Розроблено три рівні складності ботів. Початковий 
рівень — випадковий вибір дій на основі базових умов. Середній рівень — 
аналіз сили руки та розрахунок імовірності перемоги. Високий рівень — оцінка 
потенційних комбінацій, поведінки супротивників та стратегічне моделювання 
дій. Це дозволяє користувачеві тренуватись проти ботів з різним рівнем 
навичок. 
Графічний інтерфейс користувача. Інтерфейс реалізовано з 
використанням JavaFX. Візуалізовано усі елементи гри: ігрове поле, карти, 
банк, статус гравців, кнопки управління. Застосовано анімації для динамічного 
оновлення станів та забезпечення зручної навігації для користувача. 
Система зберігання та аналітики. Реалізовано механізм збереження 
статистичних даних про перебіг ігор: кількість перемог, типи виграшних 
комбінацій, хід роздачі тощо. Це дозволяє проводити аналіз ігрового процесу, 
відстежувати прогрес користувача та формувати звіти. 
Тестування і стабільність. Було проведено модульне і системне 
тестування ключових компонентів. Застосунок показав стабільну роботу при 
багаторазових ігрових сесіях, коректно обробляв нештатні ситуації, наприклад, 
одночасний вихід кількох гравців із гри або відсутність доступних ходів. 
8 
ЧДТУ 252164.016ПЗ 
Узагальнюючи, результати роботи свідчать про створення якісного, 
надійного ігрового продукту з усіма необхідними складовими: логікою гри, ШІ, 
інтерфейсом, статистикою та тестованою архітектурою. Програмне 
забезпечення є готовим до практичного застосування, подальшого 
масштабування та розширення функціоналу. 
Особистий внесок автора. У процесі виконання бакалаврської роботи 
було реалізовано повний цикл розробки програмного забезпечення для 
симуляції гри в покер. На початковому етапі здійснено аналіз існуючих 
програмних рішень у цій сфері, зокрема покерних симуляторів з офлайн-грою, 
що дозволило визначити їхні функціональні обмеження та сформувати вимоги 
до власного застосунку. Відповідно до цих вимог спроєктовано архітектуру 
системи із застосуванням об’єктно-орієнтованого підходу та візуалізацією її 
компонентів за допомогою UML-діаграм.На основі проєктної документації 
реалізовано правила гри у Техаський Холдем, включаючи розподіл карт, 
формування банку,  раунди ставок та визначення переможця. Одночасно було 
створено систему штучного інтелекту, яка моделює поведінку ботів трьох 
рівнів складності, що відрізняються глибиною аналізу ігрової ситуації та 
стратегією прийняття рішень. Для забезпечення користувацької взаємодії 
розроблено інтуїтивний графічний інтерфейс засобами JavaFX, який візуалізує 
ігровий процес, дозволяє керувати ходами та відображає поточний стан гри. 
Також реалізовано модуль збереження ігрових даних із можливістю 
подальшого аналізу прогресу, використовуючи структури даних, адаптовані до 
умов офлайн-гри. Завершальним етапом стали тестування функціональних 
модулів, інтеграційна перевірка усієї системи, усунення виявлених помилок, 
оптимізація продуктивності та підготовка повної технічної документації, що 
супроводжує програмний продукт. 
Практичне значення отриманих результатів полягає у створенні 
повнофункціонального програмного продукту, що демонструє ефективне 
застосування сучасних технологій розробки ПЗ та може служити основою для 
подальших досліджень у галузі створення інтелектуальних ігрових систем. 
9 
ЧДТУ 252164.016ПЗ 
Особистий внесок автора полягає в розробці всіх компонентів 
програмного забезпечення, а саме: 
 архітектурного проектування системи з використанням UML-діаграм; 
 реалізації ігрової логіки та правил Техаського Холдему; 
 розробки алгоритмів штучного інтелекту для ботів трьох рівнів 
складності; 
 створення графічного інтерфейсу користувача засобами JavaFX; 
 проектування системи зберігання даних та статистичної аналітики; 
 проведення комплексного тестування та відлагодження системи; 
 написання технічної документації проекту. 
10 
ЧДТУ 252164.016ПЗ 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
1.1  Актуальність розробки програмного забезпечення гри в покер 
Розробка програмного забезпечення для гри в покер представляє значний 
інтерес у контексті сучасної інженерії програмних систем, оскільки демонструє 
практичне застосування складних архітектурних рішень, алгоритмів штучного 
інтелекту та технологій створення інтерактивних користувацьких інтерфейсів. З 
точки зору програмної інженерії, покерний симулятор є зразковим прикладом 
event-driven архітектури, де система повинна обробляти множину подій 
користувача, підтримувати складний внутрішній стан та забезпечувати 
синхронну взаємодію між компонентами. 
Реалізація такої системи вимагає застосування сучасних патернів 
проектування як Observer, Strategy, State, Command та принципів SOLID для 
створення масштабованого та підтримуваного коду. Технічні виклики розробки 
включають архітектурне проектування модульної системи з чіткими межами 
відповідальності між компонентами ігрової логіки, штучного інтелекту та 
графічного інтерфейсу, реалізацію алгоритмів прийняття рішень з урахуванням 
імовірнісних розрахунків та аналізу поведінки опонентів, створення thread-safe 
механізмів збереження та відновлення стану гри з підтримкою транзакційності 
операцій, а також оптимізацію алгоритмів для забезпечення плавної роботи 
інтерфейсу та мінімізації затримок при прийняття рішень ботами [1]. 
Актуальність створення офлайн-симуляторів покеру обумовлена 
сучасними тенденціями розробки програмного забезпечення: зростаючою 
потребою в автономних додатках, що не залежать від мережевої 
інфраструктури, розвитком алгоритмів машинного навчання для ігрових 
застосувань та підвищенням вимог до якості користувацького досвіду в 
інтерактивних додатках. Освітня цінність проекту полягає в демонстрації 
практичного застосування теоретичних концепцій програмної інженерії від 
11 
ЧДТУ 252164.016ПЗ 
моделювання предметної області засобами UML до реалізації складних 
багатопотокових  
алгоритмів. 
З освітньої точки зору, програмне забезпечення для гри в покер може 
слугувати ефективним інструментом для вивчення теорії ймовірностей, 
статистики та прийняття рішень. Користувачі можуть аналізувати різні 
ситуації, розуміти математичні принципи, що лежать в основі стратегій покеру, 
та вдосконалювати свої аналітичні здібності. Додавання функціоналу для 
відстеження статистики, аналізу партій та рекомендацій щодо оптимальних 
рішень перетворює гру з простої розваги на потужний навчальний засіб. 
Програмна реалізація покеру також становить цікаву технічну задачу для 
розробників. Вона вимагає проектування складної архітектури, що включає 
моделювання правил гри, розробку алгоритмів штучного інтелекту для ботів, 
створення інтуїтивного користувацького інтерфейсу та забезпечення надійності 
системи [2]. Ці технічні виклики роблять розробку такого програмного 
забезпечення корисним проектом для вдосконалення професійних навичок 
програмістів та демонстрації практичного застосування теоретичних знань у 
галузі розробки програмного забезпечення. 
1.2  Аналіз існуючих програмних рішень для гри в покер 
Сучасний ринок програмного забезпечення для покеру представлений 
широким спектром технологічних рішень, що варіюються від мобільних 
додатків до професійних настільних програм. Кожне з цих рішень має свої 
архітектурні особливості, технічні переваги та обмеження, що формують 
розуміння вимог до сучасних ігрових систем. 
PokerStars є найбільш відомим представником професійного покерного 
програмного забезпечення, розробленого на мові C++ з використанням 
бібліотеки Qt Framework версії 5.x для забезпечення роботи на різних 
платформах. Система використовує архітектуру клієнт-сервер з тонким 
клієнтом, де основна бізнес-логіка виконується на сервері, а клієнт відповідає за 
відображення та передачу команд користувача. Архітектурні особливості 
12 
ЧДТУ 252164.016ПЗ 
включають багатопотокову модель з окремими потоками для мережевої 
взаємодії, обробки графіки та користувацького введення, асинхронну обробку 
подій через механізм сигналів та слотів Qt та систему кешування ресурсів для 
мінімізації затримок. Додатково використовується OpenGL версії 3.0 і вище для 
високопродуктивної графіки та протокол передачі даних власної розробки для 
оптимізації мережевого трафіку. 
Основними перевагами PokerStars є висока стабільність мережевого 
з'єднання, масштабованість на тисячі одночасних користувачів та професійна 
якість графіки з підтримкою тривимірних анімацій. Проте недоліками з 
архітектурної точки зору виступають монолітна структура клієнтської частини, 
складність тестування через тісну інтеграцію з мережевим рівнем та обмежені 
можливості автономного режиму через залежність від серверної логіки. 
World Series of Poker від компанії Playtika представляє собою приклад 
сучасного підходу до розробки ігрового програмного забезпечення, 
реалізованого на ігровому рушії Unity 3D з використанням платформи .NET на 
мові C# та SQLite для локального зберігання даних. Система побудована на 
архітектурі компонент-сутність-система, що забезпечує модульність з 
незалежними компонентами для різних аспектів гри. Застосовується шаблон 
модель-вид-контролер для чіткого розділення між ігровою логікою, 
інтерфейсом та контролерами, впровадження залежностей через контейнер 
Unity для управління залежностями між компонентами та шаблон спостерігач 
для синхронізації стану інтерфейсу з ігровими подіями [3]. Для серверної 
взаємодії використовується програмний інтерфейс REST з форматом JSON для 
обміну даними. 
Переваги цього рішення включають модульну архітектуру, що дозволяє 
легко додавати нові функції, роботу на різних платформах завдяки рушію Unity 
та добру підтримку мобільних пристроїв з адаптивним інтерфейсом. Недоліки 
полягають у тому, що агресивна монетизація впливає на архітектурні рішення 
через додаткові модулі для внутрішніх покупок, а залежність від екосистеми 
Unity обмежує гнучкість технологічних рішень. 
13 
ЧДТУ 252164.016ПЗ 
Governor of Poker від Youda Games демонструє еволюцію веб-
технологій, оригінально розроблений на Flash з мовою ActionScript 3, а пізніше 
портований на HTML5 з JavaScript з використанням бібліотеки Phaser.js як 
ігрового рушія. Архітектура побудована на принципах керування подіями, де 
вся взаємодія здійснюється через систему подій, шаблонах скінченного 
автомата для управління різними фазами гри та переходами між ними, 
композитній структурі, де ігрові об'єкти створюються як композиція простіших 
компонентів, та конфігурації на основі JSON для зберігання налаштувань гри у 
зовнішніх файлах. 
Переваги включають легковажну архітектуру з швидким завантаженням, 
простоту розгортання без необхідності встановлення додаткового програмного 
забезпечення та роботу на різних платформах через веб-браузери. Недоліки 
полягають в обмеженій складності штучного інтелекту через обмеження 
продуктивності JavaScript, проблемах з продуктивністю при складних 
математичних обчисленнях та відсутності строгої типізації, що ускладнює 
підтримку великих кодових баз. 
Сучасні тенденції розвитку ігрового програмного забезпечення 
демонструють перехід до мікросервісної архітектури, де кожен аспект гри 
виділяється в незалежний сервіс з власним життєвим циклом. Це включає 
окремі сервіси для автентифікації, статистики, штучного інтелекту та платежів 
з програмним шлюзом як централізованою точкою входу та виявленням 
сервісів для автоматичного виявлення та балансування навантаження. 
Інтеграція машинного навчання стає стандартом через навчання з 
підкріпленням для створення адаптивних ігрових ботів, нейронні мережі для 
аналізу поведінки гравців та персоналізації досвіду, а також використання 
готових бібліотек машинного навчання як TensorFlow та PyTorch. 
Реактивне програмування набуває популярності для кращої чутливості 
через бібліотеки для обробки асинхронних потоків даних, збереження подій для 
зберігання стану як послідовності подій та розділення команд та запитів для 
кращої масштабованості. Розробка для хмарних технологій включає 
контейнеризацію через Docker та Kubernetes, безсерверну архітектуру з 
14 
ЧДТУ 252164.016ПЗ 
функціями як сервіс, а також граничні обчислення для розподілених обчислень 
та зменшення затримки. 
Методи вдосконалення існуючих архітектурних рішень включають 
застосування предметно-орієнтованого проектування з створенням багатих 
моделей предметної області замість знекровлених моделей, кореневих агрегатів 
для забезпечення узгодженості та обмежених контекстів для логічного 
розділення предметної області. Шестикутна архітектура забезпечує ізоляцію 
бізнес-логіки від зовнішніх залежностей через інверсію залежностей та 
адаптери для різних типів збереження даних. Архітектура керування подіями з 
сховищем подій надає незмінний журнал подій для повної аудитованості та 
відтворення подій для налагодження. 
Технологічні інновації включають інтеграцію WebAssembly для 
портування високопродуктивних алгоритмів у веб-середовище з 
продуктивністю, близькою до нативної, GraphQL замість REST для гнучких 
запитів даних з строго типізованою схемою та підписками в реальному часі, а 
також технології блокчейн для чесної гри з незмінними журналами ігор та 
децентралізованою генерацією випадкових чисел [4]. 
Застосування в реальних сценаріях демонструє широкі можливості 
покерного програмного забезпечення за межами розваг. Курс покеру в 
Массачусетському технологічному інституті використовує симулятори для 
викладання теорії ймовірностей з розрахунком шансів у реальному часі, теорії 
ігор з аналізом оптимальних стратегій та прийняття рішень для вивчення 
прийняття рішень в умовах неповної інформації. Технічна реалізація включає 
серверну частину на Python з бібліотекою для статистичного аналізу, клієнтську 
частину на React для візуалізації та PostgreSQL для зберігання результатів. 
Програма навчання в Goldman Sachs застосовує покерні симулятори для 
розвитку навичок трейдерів у управлінні ризиками з оцінкою ризиків в умовах 
волатильності, теорії портфеля, де диверсифікація розглядається як аналог 
управління банкролом, та поведінкових фінансах для розуміння когнітивних 
упереджень. Архітектура включає мікросервіси на Spring Boot, Apache Kafka 
для потокової передачі подій та Redis для управління сесіями. 
15 
ЧДТУ 252164.016ПЗ 
Дослідницький проект DeepStack з Університету Альберти демонструє 
прорив у штучному інтелекті для покеру через алгоритм мінімізації 
контрафактичного жалю для стратегічних ігор, глибоке навчання з нейронними 
мережами для оцінки позицій та пошук по дереву Монте-Карло для планування 
стратегій. Технічна реалізація включає C++ для основних алгоритмів, Python 
для конвеєра машинного навчання та CUDA для прискорення на графічних 
процесорах. 
Симуляція ризиків JPMorgan Chase використовує покер як метафору для 
фінансових ризиків у стрес-тестуванні з моделюванням екстремальних 
сценаріїв, розрахунку вартості під ризиком через симуляцію Монте-Карло та 
регуляторного дотримання з автоматизованою звітністю та аудиторськими 
слідами. 
1.3 Формування вимог до програмного забезпечення та 
обґрунтування вибору Java як мови програмування 
На основі проведеного аналізу існуючих рішень та виявлених технічних 
обмежень було сформульовано комплекс вимог до програмного забезпечення, 
що враховує сучасні тенденції розробки та потреби користувачів. 
Архітектурні вимоги включають модульність системи з незалежними 
компонентами та чітко визначеними інтерфейсами для забезпечення слабкого 
зв'язування та високої згуртованості. Система повинна забезпечувати 
розширюваність для додавання нових типів ботів, режимів гри та варіацій 
покеру без модифікації існуючого коду через принцип відкритості/закритості. 
Архітектура має гарантувати легке модульне та інтеграційне тестування з 
високим покриттям коду, а також підтримуваність через самодокументований 
код з мінімальною цикломатичною складністю та чітким розділенням 
обов'язків. 
Функціональні вимоги охоплюють реалізацію повної функціональності 
автономного режиму гри без залежності від мережевого з'єднання, що 
дозволить користувачам грати незалежно від наявності інтернету. Система 
повинна підтримувати різні варіанти покеру, зокрема Техаський Холдем як 
16 
ЧДТУ 252164.016ПЗ 
найпопулярніший різновид, з можливістю налаштування параметрів гри, 
включаючи кількість ботів за столом, початкову суму фішок, структуру 
блайндів та швидкість їх зростання. 
Штучний інтелект має бути реалізований із використанням сучасних 
алгоритмів, що забезпечуватимуть різні стилі гри та рівні складності. Програма 
повинна пропонувати щонайменше три рівні складності ботів: початковий із 
базовими стратегіями, середній із помірно агресивними підходами та 
експертний із застосуванням просунутих концепцій гри. Кожен бот матиме 
унікальний профіль, що визначає схильність до ризику, агресивність, частоту 
блефу та інші характеристики, які впливають на прийняття рішень. 
Система збору та аналізу статистики має фіксувати ключові показники, 
включаючи відсоток виграшів, середній розмір виграного банку, частоту 
застосування різних дій, показник агресивності гри та інші метрики з 
можливістю візуалізації через графіки та діаграми. Збереження ігрового 
прогресу забезпечуватиме зберігання профілів користувачів з їхньою 
статистикою, налаштуваннями та досягненнями. 
Нефункціональні вимоги встановлюють конкретні показники 
продуктивності з часом відгуку інтерфейсу менше 100 мілісекунд для 
забезпечення миттєвої реакції користувача, прийняттям рішень ботами за час не 
більше 2 секунд для підтримки природного темпу гри та надійністю системи 
для роботи протягом понад 8 годин безперервного використання без витоків 
пам'яті чи погіршення продуктивності [5]. 
Кросплатформність має забезпечувати підтримку операційних систем 
Windows, macOS та Linux з однаковою функціональністю на різних 
платформах. Вимоги до зручності використання включають інтуїтивний 
інтерфейс з мінімальною кривою навчання, відповідність загальноприйнятим 
конвенціям дизайну та доступність для користувачів з різним рівнем досвіду 
гри в покер. 
Обґрунтування вибору Java як технологічної платформи базується на 
комплексному аналізі технічних переваг та відповідності поставленим вимогам. 
Віртуальна машина Java надає автоматичне управління пам'яттю через 
17 
ЧДТУ 252164.016ПЗ 
досконалі алгоритми збирання сміття, що запобігає витокам пам'яті, 
характерним для мов з ручним управлінням пам'яттю. Безпечні для 
багатопотокового використання колекції з пакету java.util.concurrent 
забезпечують безпечний одночасний доступ до даних без необхідності явної 
синхронізації. Рефлексійний програмний інтерфейс та анотації дозволяють 
реалізувати впровадження залежностей та метапрограмування для створення 
гнучких архітектурних рішень. 
Об'єктно-орієнтована парадигма Java ідеально підходить для 
моделювання ігрового домену через чисту абстракцію концепцій покеру. Базові 
сутності, такі як карти, колода, гравці, ставки та комбінації, можуть бути 
представлені у вигляді класів з чітко визначеними атрибутами та методами. 
Застосування принципів об'єктно-орієнтованого програмування, таких як 
інкапсуляція, наслідування та поліморфізм, дозволить створити гнучку та 
розширювану архітектуру, здатну адаптуватися до різних варіантів гри. 
Екосистема Java включає потужні інструменти збирання, такі як Maven 
для управління залежностями, автоматизованого тестування та упакування з 
декларативною конфігурацією через файли опису проекту. Фреймворки 
тестування, такі як JUnit та TestNG, забезпечують всебічне покриття тестами з 
підтримкою параметризованих тестів, наборів тестів та інтеграційного 
тестування. Фреймворк Mockito дозволяє створювати фіктивні об'єкти для 
ізольованого тестування компонентів. Профілювання та моніторинг через 
JProfiler для виявлення витоків пам'яті, аналізу використання процесора та 
ідентифікації вузьких місць продуктивності забезпечує можливості оптимізації. 
JavaFX обрано для розробки графічного інтерфейсу як сучасну 
альтернативу Swing з архітектурою графа сцени для ефективного рендерингу 
через ієрархічну структуру візуальних елементів. Зв'язування властивостей 
дозволяє реалізувати реактивне зв'язування компонентів інтерфейсу з бізнес-
логікою без явної обробки подій. Стилізація через CSS забезпечує гнучке 
оформлення з можливістю тем та налаштувань. Програмний інтерфейс анімації 
надає плавні переходи для роздачі карт, переміщення фішок та інших 
візуальних ефектів. Розмітка FXML дозволяє декларативний опис інтерфейсу з 
18 
ЧДТУ 252164.016ПЗ 
розділенням обов'язків між рівнем презентації та бізнес-логікою. Інструмент 
Scene Builder забезпечує візуальне редагування інтерфейсів з функціональністю 
перетягування та миттєвим попереднім переглядом. Додаткові технології 
включають базу даних H2 як вбудоване рішення з налаштуванням без 
конфігурації, що не потребує окремого сервера бази даних. Відповідність 
принципам ACID забезпечує цілісність даних через підтримку транзакцій, а 
сумісність з SQL дозволяє використовувати стандартний синтаксис SQL з 
можливістю міграції на інші рушії баз даних у майбутньому. Малий розмір 
менше 2 мегабайт робить H2 ідеальним для настільних додатків. 
Apache Commons Math забезпечує готові реалізації складних 
математичних функцій для статистичних обчислень, розподіли ймовірностей 
для симуляцій Монте-Карло та описову статистику для аналізу ігрових 
результатів. Оптимізовані алгоритми забезпечують високу продуктивність 
навіть при інтенсивних обчисленнях. 
SLF4J з Logback надає структуроване журналювання з різними рівнями 
деталізації від налагодження до помилок, налаштовувані додатки для різних 
місць призначення виводу та оптимізоване за продуктивністю асинхронне 
журналювання для мінімізації впливу на продуктивність додатку [6]. 
Вибір Java як технологічної платформи забезпечує архітектурну гнучкість 
через потужну об'єктну модель та можливості метапрограмування, 
продуктивність завдяки оптимізаціям віртуальної машини, включаючи 
компіляцію на льоту та адаптивну оптимізацію, кросплатформність без 
компромісів у функціональності через філософію "написати один раз, запускати 
скрізь" та зрілу екосистему інструментів для розробки корпоративних додатків 
з високою надійністю та підтримуваністю. 
1.4 Постановка задачі 
Метою даної роботи є створення настільного програмного забезпечення 
для гри в покер за правилами Техаського Холдему, що дозволяє забезпечити 
реалістичний ігровий процес із підтримкою штучного інтелекту, зручним 
графічним інтерфейсом та базовою системою збереження ігрових даних. 
19 
ЧДТУ 252164.016ПЗ 
Для досягнення поставленої мети необхідно реалізувати наступні 
функціональні та технічні вимоги: 
 Створити архітектуру програмного забезпечення, яка забезпечує 
модульність, масштабованість і зручність підтримки; 
 Розробити ігрову логіку, яка повністю відповідає правилам 
Техаського Холдему; 
 Реалізувати поведінку ботів, що діятимуть згідно з ігровими 
стратегіями трьох рівнів складності: базового, середнього та просунутого; 
 Розробити графічний інтерфейс користувача з використанням 
JavaFX, що буде інтуїтивно зрозумілим, адаптивним і привабливим для 
користувача; 
 Забезпечити збереження ігрової інформації, включаючи хід гри, 
виграші, дії користувача та ботів, із можливістю подальшого аналізу; 
 Реалізувати систему повідомлень та підказок для взаємодії з 
користувачем; 
 Провести тестування системи, щоб забезпечити її надійність, 
стабільність і відповідність функціональним вимогам. 
Таким чином, задача полягає в реалізації повноцінного програмного 
продукту, який поєднує алгоритми прийняття рішень в умовах неповної 
інформації, сучасний графічний інтерфейс та інструменти аналітики у межах 
настільного застосунку без потреби постійного підключення до Інтернету. 
 
 
 
 
 
 
 
 
 
 
20 
ЧДТУ 252164.016ПЗ 
ВИСНОВОК ДО ПЕРШОГО РОЗДІЛУ 
Проведений аналіз сучасного стану розробки програмного забезпечення 
ігрових систем виявив ключові технічні тенденції та архітектурні підходи, що 
формують вимоги до проектованої системи. 
Основні технічні висновки включають архітектурну еволюцію від 
монолітних рішень до модульних архітектур з чітким розділенням 
відповідальностей та слабким зв'язуванням компонентів. Сучасні системи 
демонструють перехід до архітектур керування подіями з асинхронною 
обробкою подій, мікросервісного підходу з незалежними компонентами та 
шаблонів реактивного програмування для кращої чутливості. 
Інтеграція штучного інтелекту стає обов'язковою вимогою для сучасних 
ігрових систем, що потребує архітектурної підтримки компонентів машинного 
навчання, адаптивних алгоритмів та можливостей статистичного аналізу. 
Технологічні тенденції включають використання підходів для хмарних 
технологій, контейнеризацію для розгортання та безсерверну архітектуру для 
специфічних робочих навантажень. 
Аналіз існуючих рішень виявив критичні недоліки, включаючи 
залежність від мережевої інфраструктури в PokerStars, обмежену складність 
штучного інтелекту в веб-базованих рішеннях та архітектурні компроміси через 
агресивну монетизацію у мобільних додатках. Ці обмеження формують 
технічні вимоги для нової системи з акцентом на автономній роботі, 
досконалих алгоритмах штучного інтелекту та принципах чистої архітектури. 
Обґрунтування технологічних рішень демонструє, що платформа Java 
оптимально відповідає поставленим вимогам через архітектурну гнучкість 
завдяки потужній об'єктній моделі та можливостям рефлексії, характеристики 
продуктивності через оптимізації віртуальної машини та збирання сміття, 
кросплатформну сумісність без функціональних компромісів та зрілу 
екосистему з всебічним інструментарієм для розробки, тестування та 
розгортання. 
JavaFX обрано для розробки користувацького інтерфейсу як сучасну 
альтернативу Swing з архітектурою графа сцени для ефективного рендерингу, 
21 
ЧДТУ 252164.016ПЗ 
декларативним інтерфейсом через розмітку FXML, реактивним 
програмуванням через зв'язування властивостей та апаратним прискоренням 
для плавних анімацій. Додаткові технології, такі як база даних H2 для 
вбудованого збереження, Apache Commons Math для статистичних обчислень та 
SLF4J для структурованого журналювання, створюють повний технологічний 
стек для корпоративного настільного додатку. 
Технічні вимоги до системи сформульовано на основі аналізу недоліків 
існуючих рішень та включають модульну архітектуру з шаблоном 
впровадження залежностей, асинхронну обробку з безпечними для 
багатопотокового використання компонентами, всебічну стратегію тестування з 
модульними та інтеграційними тестами, а також збереження даних з 
підтримкою транзакцій та можливостями міграції. 
Результати аналізу створюють міцний фундамент для архітектурного 
проектування та впровадження складної ігрової системи з сучасною 
архітектурою, високими стандартами якості коду та широкою 
функціональністю, що відповідає поточним найкращим практикам індустрії та 
забезпечує довгострокову підтримуваність і масштабованість. 
22 
ЧДТУ 252164.016ПЗ 
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У 
ПРАКТИКУ ПРОЕКТУВАННЯ 
2.1  Моделювання предметної області 
Модель предметної області гри в покер представляє собою структуровану 
сукупність концептуальних класів та відношень між ними, що відображає 
основні елементи та правила гри. Центральним елементом цієї моделі є 
карткова гра покер з її різноманітними варіаціями, найпопулярнішою з яких є 
Техаський Холдем. Саме ця варіація буде основою для розробки програмного 
забезпечення через її широку популярність та відносну простоту правил. У 
моделі предметної області покеру виділяються такі ключові елементи: карта, 
колода карт, гравець, стіл, ставка, банк, комбінація, раунд та гра. Карта є 
базовим елементом, що характеризується мастю (піки, чирви, бубни, трефи) та 
значенням (від двійки до туза). Колода карт складається з 52 карт стандартного 
набору. Гравець володіє певною кількістю фішок та може виконувати дії згідно 
з правилами гри. 
Стіл представляє віртуальний простір, за яким розміщуються гравці та 
відбувається гра. Він має обмежену кількість місць (зазвичай від 2 до 10) та 
містить спільні карти, що викладаються в центрі. Ставка є визначеною 
кількістю фішок, яку гравець вносить у гру, а банк - це сукупність усіх ставок у 
поточній роздачі. Комбінація карт визначає силу руки гравця і формується з 
карт на руках та спільних карт на столі. Існує визначена ієрархія комбінацій: від 
старшої карти до роял-флешу [7]. Раунд є структурним елементом гри, що 
включає певну послідовність дій гравців. Гра в Техаський Холдем складається з 
чотирьох раундів: преflop, flop, turn та river. 
Модель також включає різні стратегії гри, які можуть застосовувати боти. 
Ці стратегії базуються на ймовірнісних розрахунках, аналізі потенційної сили 
руки, позиції за столом та поведінкових шаблонах. Для реалізації ботів різних 
рівнів складності передбачається створення стратегій від простих (базованих 
лише на силі руки) до складних (з урахуванням психологічних аспектів). Окрім 
основних елементів гри, модель предметної області включає допоміжні 
23 
ЧДТУ 252164.016ПЗ 
компоненти: профіль гравця з історією та статистикою ігор, налаштування гри 
(зокрема, структуру блайндів, початкову кількість фішок), а також турнірні 
механіки для організації змагань з кількома столами та вильотом гравців [8]. 
Взаємодія між елементами моделі регламентується правилами гри, які 
визначають послідовність дій, можливі варіанти рішень гравців та алгоритм 
визначення переможця. Ця модель предметної області служитиме основою для 
подальшої розробки класів та їх відношень у програмній системі. 
2.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області 
Предметною областю даного програмного продукту є настільна 
карткова гра Техаський Холдем, що належить до ігор з неповною інформацією. 
Особливість даної області полягає в необхідності моделювання процесу гри з 
урахуванням різноманітних стратегій, ймовірностей та дій як з боку реального 
гравця, так і з боку ботів, керованих штучним інтелектом. Крім того, важливу 
роль відіграє візуалізація інтерфейсу та збереження даних про гру. 
Модель предметної області охоплює наступні сутності та взаємозв’язки: 
 Гравець (Player) — може бути користувачем або ботом. Має унікальний 
ідентифікатор, набір карт, банкрол, рівень інтелекту (для ботів) тощо. 
 Карткова колода (Deck) — містить 52 унікальні карти, які роздаються 
випадковим чином. 
 Стіл (Table) — ігрове середовище, на якому проходять роздачі. Має слоти 
для гравців, загальні карти, банк. 
 Комбінація (Hand) — найкраща п’ятикаркова комбінація, що формується 
з власних карт гравця та загальних карт. 
 Бот (AIPlayer) — підклас гравця з реалізованою логікою прийняття 
рішень. 
 Раунд (Round) — етап гри (префлоп, флоп, терн, рівер), у якому 
відбуваються ставки. 
 Ставка (Bet) — дія гравця (кол, рейз, фолд), що змінює стан гри. 
24 
ЧДТУ 252164.016ПЗ 
 Інтерфейс користувача (UI) — візуальний компонент, що забезпечує 
взаємодію між користувачем і системою. 
 База даних (GameStats) — сховище результатів ігрових сесій, дій гравців, 
статистики. 
Словник предметної області 
Техаський Різновид покеру, в якому кожному гравцеві роздається по 2 
Холдем карти, а 5 карт — спільні. 
Гравець Учасник гри. Може бути людиною або програмним ботом. 
Бот Програмна реалізація гравця зі змодельованим інтелектом. 
Ставка Дія в межах раунду (кол, фолд, рейз). 
Комбінація П’ять найкращих карт з наявних у гравця і на столі. 
Банк Загальна сума ставок гравців. 
Візуальна частина програми, через яку здійснюється 
Інтерфейс 
управління. 
Раунд Один з етапів гри (префлоп, флоп, терн, рівер). 
Колода 52 унікальні карти, з яких формується роздача. 
Алгоритм, який приймає рішення на основі поточної ігрової 
Інтелект бота 
ситуації. 
Ігрова сесія Один повний цикл гри з результатами. 
2.1.2 Елементи моделювання предметної області 
Словник предметної області гри в покер формалізує термінологію, 
необхідну для розуміння та опису всіх елементів та процесів у системі. Він є 
основою для подальшого проектування та реалізації програмного забезпечення, 
забезпечуючи єдине розуміння термінів серед усіх учасників розробки. 
Карта (Card) - базовий елемент гри, що характеризується мастю та 
значенням. Масть (Suit) - одна з чотирьох категорій карт: піки, чирви, бубни, 
трефи. Значення (Value) - числове або символьне позначення карти від 2 до 
туза. Колода (Deck) - набір із 52 карт, що використовується для гри. Рука (Hand) 
- дві приватні карти, які отримує гравець на початку роздачі. 
25 
ЧДТУ 252164.016ПЗ 
Гравець (Player) - учасник гри, який має фішки, приймає рішення та може 
виграти або програти банк. Бот (Bot) - віртуальний гравець, керований 
комп'ютерним алгоритмом, який імітує стратегії гри людини. Користувач (User) 
- реальна людина, що використовує програму та грає проти ботів. Дилер 
(Dealer) - гравець, який роздає карти; у віртуальній грі ця роль виконується 
програмою. 
Стіл (Table) - віртуальний простір гри, де розміщуються гравці та спільні 
карти. Спільні карти (Community Cards) - карти, що викладаються в центрі 
столу і можуть використовуватись усіма гравцями для формування комбінацій. 
Позиція (Position) - місце гравця за столом відносно дилера, що впливає на 
стратегію гри. 
Ставка (Bet) - кількість фішок, яку гравець вносить у гру. Фішки (Chips) - 
ігрова валюта, що використовується для ставок. Банк (Pot) - загальна сума 
фішок від ставок усіх гравців у поточній роздачі. Малий блайнд (Small Blind) - 
обов'язкова початкова ставка, яку робить гравець зліва від дилера. Великий 
блайнд (Big Blind) - обов'язкова початкова ставка, яку робить гравець зліва від 
малого блайнду, зазвичай вдвічі більша за малий блайнд. 
Комбінація (Combination) - набір п'яти карт, що визначає силу руки 
гравця. До стандартних комбінацій належать: стрейт-флеш, каре, фул-хаус, 
флеш, стрейт, трійка, дві пари, пара та старша карта. Сила руки (Hand Strength) 
- числове значення, що визначає потенціал виграшу з певними картами. 
Раунд торгівлі (Betting Round) - етап гри, протягом якого гравці роблять 
ставки. У Техаському Холдемі є чотири раунди: префлоп, флоп, терн та рівер. 
Дія (Action) - рішення, яке приймає гравець під час свого ходу, наприклад: 
фолд, чек, колл, бет, рейз. Роздача (Deal) - один цикл гри від роздачі карт до 
визначення переможця. 
Турнір (Tournament) - змагання з визначеними правилами, де гравці 
починають з однаковою кількістю фішок і грають до вильоту. Кеш-гра (Cash 
Game) - формат гри, де гравці можуть приєднуватися та залишати гру в будь-
який момент, а фішки мають реальну вартість. 
2.1.3 Робоча область моделювання 
26 
ЧДТУ 252164.016ПЗ 
Робоча область моделювання гри в покер охоплює всі ключові елементи 
та процеси, необхідні для створення повноцінного програмного забезпечення. 
При цьому встановлюються чіткі межі системи, визначаються основні 
компоненти та їх взаємодія, а також окреслюються обмеження та припущення, 
що дозволяють сфокусувати розробку на найсуттєвіших аспектах. Центральним 
елементом робочої області є ігровий процес Техаського Холдему, що включає 
логіку роздачі карт, послідовність ходів гравців, визначення сили комбінацій та 
виявлення переможця. Система моделюватиме стандартні правила гри з 
можливістю налаштування таких параметрів, як початкова кількість фішок, 
структура блайндів та кількість гравців за столом. 
До робочої області також входить моделювання поведінки ботів різного 
рівня складності. Передбачається створення трьох рівнів ботів: початковий, 
середній та експертний. Боти початкового рівня прийматимуть рішення лише 
на основі сили своєї руки без урахування контексту гри. Боти середнього рівня 
враховуватимуть позицію за столом, розмір банку та базову статистику гравців. 
Боти експертного рівня додатково аналізуватимуть історію ходів та 
використовуватимуть елементи блефу та психологічної гри. У робочу область 
моделювання включається користувацький інтерфейс, який забезпечить 
візуалізацію ігрового процесу та зручну взаємодію користувача з системою. 
Інтерфейс відображатиме ігровий стіл, карти, фішки, дії гравців та надаватиме 
користувачу контроли для прийняття рішень. Також передбачається 
можливість налаштування зовнішнього вигляду та отримання підказок щодо 
оптимальних рішень. 
Система моделюватиме два основні режими гри: кеш-гра та турнір. У 
режимі кеш-гри користувач зможе приєднуватися до столу з обраною кількістю 
фішок та грати необмежену кількість роздач. У турнірному режимі всі гравці 
починатимуть з однаковою кількістю фішок, а блайнди зростатимуть за 
визначеним розкладом до визначення переможця. До робочої області також 
входить система збору та аналізу статистики гри, яка фіксуватиме ключові 
показники: відсоток виграшів, середній розмір виграного банку, частоту 
застосування різних дій (фолд, колл, рейз), показник агресивності гри та інші 
27 
ЧДТУ 252164.016ПЗ 
метрики. Ця статистика використовуватиметься для відображення прогресу 
гравця та надання рекомендацій щодо поліпшення стратегії. 
Важливою частиною робочої області є система збереження та 
завантаження прогресу гри, включаючи профілі користувачів з їхньою 
статистикою, налаштуваннями та досягненнями. Це дозволить користувачам 
продовжувати гру з того місця, де вони зупинилися, та відстежувати свій 
прогрес протягом тривалого часу. 
З робочої області моделювання свідомо виключаються деякі елементи, які 
не є критичними для основної функціональності або можуть бути реалізовані в 
наступних версіях програми. Зокрема, не передбачається реалізація 
мультиплеєрної гри через інтернет, підтримка рідкісних варіацій покеру окрім 
Техаського Холдему, інтеграція з платіжними системами та соціальними 
мережами. 
2.2 Формування та аналіз вимог 
2.2.1 Формування вимог до програмного забезпечення. Первинні і 
детальні вимоги. Вимоги замовника і розробника. Функціональні та 
нефункціональні вимоги  
Формування вимог до програмного забезпечення 
На основі аналізу предметної області та потреб користувачів сформовано 
комплекс функціональних та нефункціональних вимог до програмного 
забезпечення гри в покер. Ці вимоги встановлюють критерії, яким має 
відповідати кінцевий продукт, та слугують основою для подальшого 
проектування і розробки системи. Функціональні вимоги визначають конкретні 
функції, які система повинна виконувати. Головною функціональною вимогою 
є реалізація повноцінної гри в покер за правилами Техаського Холдему з 
підтримкою всіх стандартних етапів гри: роздача приватних карт, торгівля на 
етапах префлоп, флоп, терн та рівер, визначення сили комбінацій та виявлення 
переможця. Система повинна забезпечувати можливість користувачеві грати 
проти комп'ютерних опонентів без необхідності підключення до інтернету. 
28 
ЧДТУ 252164.016ПЗ 
Первинні вимоги сформульовані на основі загального бачення 
проєкту та включають ключові очікування замовника: створити офлайн-
застосунок для гри в покер із ботами, забезпечити реалістичний ігровий процес 
за правилами Техаського Холдему, надати користувачеві можливість гнучкого 
налаштування гри та отримання аналітики за результатами. 
Детальні вимоги були уточнені в процесі проєктування. До них 
належить реалізація повного циклу гри, підтримка двох режимів — кеш-гри та 
турніру, наявність трьох рівнів складності ботів, збереження статистики, а 
також функції експорту даних, збереження/завантаження гри, інтерактивний 
навчальний режим тощо. 
Вимоги розробника орієнтовані на забезпечення ефективної реалізації 
проєкту з технічної точки зору. Вони включають: використання об'єктно-
орієнтованого підходу до програмування, модульну структуру застосунку для 
полегшення підтримки та розширення, застосування JavaFX для графічного 
інтерфейсу, використання патернів проєктування, а також реалізацію чіткої 
структури даних та логіки взаємодії між модулями 
Система має підтримувати два основні режими гри: кеш-гра та турнір. У 
режимі кеш-гри користувач повинен мати можливість вибирати стіл з різними 
лімітами ставок, приєднуватися до нього з обраною кількістю фішок та вільно 
покидати гру в будь-який момент [9]. Турнірний режим має забезпечувати гру 
за правилами турніру з фіксованою початковою кількістю фішок, зростаючими 
блайндами та визначенням переможців за місцями. Програма повинна надавати 
можливість користувачеві взаємодіяти з системою через графічний інтерфейс, 
дозволяючи здійснювати всі стандартні дії гри в покер: фолд, чек, колл, бет, 
рейз. Інтерфейс має відображати всю необхідну інформацію: карти гравця, 
спільні карти, розмір банку, ставки інших гравців, кількість фішок у кожного 
гравця та поточну позицію дилера. 
Система повинна включати ботів з трьома рівнями складності 
(початковий, середній, експертний), які імітують різні стилі гри та стратегії. 
Боти повинні приймати рішення на основі сили своєї руки, позиції за столом, 
29 
ЧДТУ 252164.016ПЗ 
розміру банку та попередніх дій користувача, відповідно до свого рівня 
складності. Користувач повинен мати можливість вибирати кількість ботів за 
столом (від 1 до 9) та налаштовувати їхній рівень складності. Програмне 
забезпечення має зберігати статистику гри користувача, включаючи кількість 
виграшів та програшів, середній розмір виграного банку, частоту застосування 
різних дій, показник агресивності гри. Система має надавати можливість 
перегляду цієї статистики у вигляді таблиць та графіків, а також забезпечувати 
можливість її експорту. 
Функціональні вимоги також включають можливість збереження та 
завантаження стану гри, наявність навчального режиму з підказками щодо 
оптимальних рішень, можливість налаштування параметрів гри (початкової 
кількості фішок, структури блайндів, тривалості рівнів турніру), а також 
підтримку системи досягнень для мотивації користувача.  
Нефункціональні вимоги визначають характеристики та обмеження 
системи, які не пов'язані безпосередньо з виконуваними функціями. До них 
належать вимоги до продуктивності, надійності, безпеки, зручності 
використання та інші аспекти якості програмного забезпечення. Система 
повинна забезпечувати швидкодію, достатню для комфортної гри без відчутних 
затримок, навіть на пристроях з обмеженими ресурсами. Зокрема, час відгуку 
інтерфейсу не повинен перевищувати 0.5 секунди, а прийняття рішень ботами 
має відбуватися за час не більше 3 секунд. 
Програмне забезпечення має бути надійним і стабільним, без критичних 
помилок, які можуть призвести до втрати даних або неможливості продовжити 
гру. Система повинна коректно зберігати та відновлювати стан гри, навіть у 
випадку несподіваного завершення роботи. Програма повинна бути сумісною з 
різними операційними системами завдяки використанню Java та забезпечувати 
однакову функціональність на різних платформах. Вимоги до зручності 
використання включають інтуїтивно зрозумілий інтерфейс, відповідність 
30 
ЧДТУ 252164.016ПЗ 
загальноприйнятим конвенціям дизайну, наявність довідкової інформації та 
навчальних матеріалів, а також доступність для користувачів з різним рівнем 
досвіду гри в покер [10]. Система повинна бути легко розширюваною для 
додавання нових функцій та модифікації існуючих, мати модульну архітектуру 
та добре документований код. 
2.2.2 Формування вимог за допомогою діаграми прецедентів 
Діаграма прецедентів (use case diagram) є ефективним інструментом для 
візуалізації та формалізації функціональних вимог до програмного 
забезпечення. Вона дозволяє чітко визначити, які дії можуть виконувати 
користувачі системи та як ці дії взаємодіють між собою. У контексті 
програмного забезпечення для гри в покер діаграма прецедентів допомагає 
структурувати взаємодію користувача з системою та виділити ключові 
функціональні блоки. 
На діаграмі прецедентів для розроблюваного програмного забезпечення 
гри в покер виділено двох основних акторів: Користувач (Player) та Система 
(System). Користувач представляє реальну людину, яка взаємодіє з програмою, 
тоді як Система відповідає за автоматизовані процеси, зокрема, за поведінку 
ботів, роздачу карт та визначення переможця. 
Основні прецеденти, пов'язані з актором Користувач, включають: 
"Розпочати нову гру", "Вибрати режим гри", "Налаштувати параметри гри", 
"Зробити ставку", "Прийняти рішення в грі", "Переглянути статистику", 
"Зберегти гру" та "Завантажити гру". Прецедент "Розпочати нову гру" дозволяє 
користувачеві ініціювати новий ігровий сеанс і є відправною точкою для інших 
прецедентів. 
Прецедент "Вибрати режим гри" дозволяє користувачеві обрати тип гри 
(кеш-гра або турнір) та включає більш специфічні прецеденти: "Приєднатися до 
кеш-гри" та "Зареєструватися на турнір". Прецедент "Налаштувати параметри 
гри" дозволяє користувачеві визначити такі параметри, як кількість ботів за 
31 
ЧДТУ 252164.016ПЗ 
столом, їхній рівень складності, початкову кількість фішок та структуру 
блайндів. 
Прецедент "Прийняти рішення в грі" є ключовим і включає можливі дії 
користувача під час гри: "Зробити фолд", "Зробити чек", "Зробити колл", 
"Зробити бет" та "Зробити рейз". Цей прецедент тісно пов'язаний з прецедентом 
"Зробити ставку", який визначає кількість фішок, яку користувач ставить під 
час виконання відповідних дій. 
Для актора Система визначено прецеденти: "Роздати карти", "Керувати 
ботами", "Обчислити силу комбінацій", "Визначити переможця", "Збирати 
статистику" та "Керувати турніром". Прецедент "Керувати ботами" є 
комплексним і включає прецеденти нижчого рівня: "Аналізувати ситуацію", 
"Обчислити ймовірності" та "Прийняти рішення", що відповідають за різні 
аспекти штучного інтелекту ботів. 
Між прецедентами встановлено різні типи відношень. Відношення 
включення (include) використовується, коли один прецедент обов'язково 
включає поведінку іншого. Наприклад, прецедент "Визначити переможця" 
включає прецедент "Обчислити силу комбінацій", оскільки для визначення 
переможця необхідно порівняти сили комбінацій усіх учасників. 
Відношення розширення (extend) використовується, коли один прецедент 
може, але не зобов'язаний, розширювати поведінку іншого за певних умов. 
Наприклад, прецедент "Використати підказку" розширює прецедент "Прийняти 
рішення в грі", оскільки користувач може, але не зобов'язаний, запросити 
підказку перед прийняттям рішення. 
Відношення узагальнення (generalization) застосовано для представлення 
варіантів прецедентів. Наприклад, прецеденти "Приєднатися до кеш-гри" та 
"Зареєструватися на турнір" є спеціалізованими формами прецеденту "Вибрати 
режим гри". 
32 
ЧДТУ 252164.016ПЗ 
Діаграма прецедентів для програмного забезпечення гри в покер була 
створена з використанням UML-нотації та включає всі перелічені вище 
елементи. Вона представляє повну картину функціональних вимог до системи, 
чітко відображаючи взаємодію між користувачем, системою та окремими 
компонентами ПЗ. Ця діаграма слугуватиме основою для подальшого 
проектування, в тому числі для розробки діаграм класів, послідовностей та 
інших моделей, необхідних для реалізації системи (рис. 2.1). 
 
 
Рисунок 2.1 – Діаграма прецедентів програмного забезпечення гри в покер 
33 
ЧДТУ 252164.016ПЗ 
Представлена діаграма чітко розмежовує обов'язки між користувачем та 
системою, показує ієрархію прецедентів та їх взаємозв'язки через відношення 
включення, розширення та узагальнення, що забезпечує повне розуміння 
функціональних вимог до майбутньої системи. 
Гравець (Користувач) — основний користувач програми, взаємодіє з 
інтерфейсом для запуску гри, прийняття рішень тощо. 
Система (Автоматизована логіка) — відповідає за внутрішні 
обчислення, управління ботами, визначення переможця тощо. 
Основні групи дій 
Підготовка до гри 
 Розпочати нову гру — гравець ініціює нову сесію. 
 Вибрати режим гри — вибір між кеш-грою та турніром: 
 Приєднатися до кеш-гри; 
 Зареєструватися на турнір. 
 Налаштувати параметри гри — встановити ліміти, кількість гравців, 
рівень ботів тощо. 
Ігрова взаємодія 
 Прийняти рішення в грі — прецедент, який розкривається на: 
 фолд (скинути карти); 
 чек (перевірити); 
 колл (підтримати ставку); 
 бет (зробити ставку); 
 рейз (підвищити ставку). 
Розширені функції користувача 
 Зробити ставку 
 Переглянути статистику 
 Зберегти гру 
 Завантажити гру 
 Використати підказку 
34 
ЧДТУ 252164.016ПЗ 
Дії системи 
(Умовно від імені “системи” або внутрішньої логіки) 
 Роздати карти — ініціюється перед кожною роздачею. 
 Керувати ботами — містить вкладені прецеденти: 
 аналізувати ситуацію; 
 обчислити ймовірності; 
 прийняти рішення бота. 
 Обчислити силу комбінацій — система визначає переможця. 
 Визначити переможця 
 Збирати статистику 
 Керувати турніром — підтримує перебіг гри згідно з правилами 
турнірів (зростання блайндів, вибуття гравців тощо). 
Типи зв’язків 
 Association (лінії) — показують, хто ініціює прецедент (гравець чи 
система). 
 Include (стрілка з <<include>>) — означає, що один прецедент 
обов’язково включає інший (наприклад, “Керувати ботами” 
обов’язково включає “Обчислити ймовірності”). 
 Extend (не використано тут) — показав би додаткові дії, які 
виконуються за певних умов (тут не присутнє, але можна було б 
додати, наприклад, “Отримати досягнення”). 
2.3 Проєктування логічної структури програмного комплексу 
2.3.1 Розробка діаграми класів 
Діаграма класів є ключовим елементом об'єктно-орієнтованого 
проектування програмного забезпечення гри в покер, оскільки вона відображає 
статичну структуру системи, визначаючи класи, їхні атрибути, методи та 
взаємозв'язки. Для розроблюваної гри було створено комплексну діаграму 
класів, яка охоплює всі аспекти функціональності системи та забезпечує основу 
для реалізації програмного продукту мовою Java (рис. 2.2). 
35 
ЧДТУ 252164.016ПЗ 
 
Рисунок 2.2 - Діаграма класів програмного забезпечення гри в покер 
 
Центральним класом у системі є клас Game, який відповідає за 
управління ігровим процесом та координацію взаємодії між іншими 
компонентами. Цей клас містить атрибути, що описують поточний стан гри 
(currentRound, pot, communityCards), та методи для керування ходом гри 
(startGame(), endGame(), nextRound()). Клас Game має агрегаційні зв'язки з 
класами Player, Deck, Pot та асоціативні зв'язки з класами Table і HandEvaluator. 
Ієрархія класів, пов'язаних з представленням гравців, розпочинається з 
абстрактного класу Player, який визначає базові атрибути (name, chips, hand) та 
методи (bet(), fold(), check(), call(), raise()). Від цього класу успадковуються два 
конкретні класи: HumanPlayer, що представляє користувача та містить методи 
для взаємодії з інтерфейсом, та BotPlayer, який реалізує логіку автоматичного 
прийняття рішень. Клас BotPlayer має три підкласи, що відповідають різним 
рівням складності: BeginnerBot, IntermediateBot та ExpertBot, кожен із власною 
реалізацією стратегії гри. 
Для представлення карткової колоди та карт розроблено класи Deck та 
Card. Клас Card має атрибути suit (масть) та value (значення), а також методи 
для порівняння карт. Клас Deck містить колекцію об'єктів типу Card та методи 
36 
ЧДТУ 252164.016ПЗ 
для перемішування (shuffle()), видачі карт (dealCard()) та ініціалізації нової 
колоди (initialize()). Взаємозв'язок між цими класами реалізовано через 
композицію, оскільки карти не можуть існувати поза контекстом колоди у 
даній системі. 
Для оцінки сили карткових комбінацій створено клас HandEvaluator, який 
містить методи для визначення типу комбінації (evaluateHand()), порівняння 
рук гравців (compareHands()) та виявлення переможця (determineWinner()). Цей 
клас використовує допоміжний клас HandRank, який представляє ранг 
комбінації (від високої карти до роял-флешу) та містить методи для порівняння 
різних рангів. 
Для моделювання ігрового столу створено клас Table, який містить 
атрибути, що описують кількість місць (seats), позицію дилера (dealerPosition), 
розміри блайндів (smallBlind, bigBlind) та поточний раунд торгівлі 
(currentBettingRound). Цей клас включає методи для додавання та видалення 
гравців, зміни позиції дилера та керування процесом ставок. Клас Table має 
композиційний зв'язок з класом Seat, який представляє окреме місце за столом 
та містить інформацію про гравця, що його займає. 
Для відображення інтерфейсу користувача розроблено набір класів з 
префіксом UI: UIManager (загальне керування інтерфейсом), GameView 
(відображення ігрового столу), PlayerView (відображення інформації про 
гравця), CardView (візуалізація карт) та інші. Ці класи відповідають за 
відображення стану гри та забезпечення взаємодії користувача з системою 
через графічний інтерфейс. Вони пов'язані з відповідними класами моделі через 
патерн проектування MVC (Model-View-Controller). 
Для реалізації логіки збереження та завантаження стану гри, а також для 
роботи зі статистикою, створено класи GameSerializer, StatisticsManager та 
UserProfile. Клас GameSerializer містить методи для серіалізації та десеріалізації 
об'єктів гри, StatisticsManager відповідає за збір та аналіз статистичних даних, а 
UserProfile зберігає інформацію про користувача, включаючи його історію ігор 
та досягнення. 
2.3.2. Проєктування діаграми пакетів 
37 
ЧДТУ 252164.016ПЗ 
Діаграма пакетів для програмного забезпечення гри в покер представляє 
високорівневу організацію системи, розділяючи її на логічні модулі та 
визначаючи залежності між ними. Така структуризація забезпечує кращу 
модульність, повторне використання компонентів та спрощує підтримку і 
розширення системи в майбутньому. Основний пакет com.pokergame є 
кореневим і містить підпакети, які відповідають за різні аспекти 
функціональності системи. Цей пакет включає файл конфігурації програми та 
клас запуску додатку (Application). Від основного пакету виходять залежності 
до всіх інших пакетів, оскільки саме через нього здійснюється ініціалізація та 
координація роботи всіх компонентів системи (рис. 2.2). 
 
 
Рисунок 2.3 - Діаграма пакетів програмного забезпечення гри в покер 
 
Пакет com.pokergame.model містить класи, що представляють бізнес-
логіку та структуру даних додатку. Він включає підпакети: model.card (класи 
для представлення карт та колоди), model.player (класи для представлення 
гравців), model.game (класи для управління ігровим процесом) та 
38 
ЧДТУ 252164.016ПЗ 
model.evaluation (класи для оцінки сили комбінацій). Цей пакет є найбільш 
фундаментальним, оскільки його компоненти використовуються майже всіма 
іншими частинами системи. Пакет com.pokergame.ui відповідає за графічний 
інтерфейс користувача та включає підпакети: ui.views (компоненти 
відображення), ui.controllers (контролери для обробки дій користувача) та 
ui.resources (статичні ресурси, як-от зображення, звуки, стилі). Цей пакет 
залежить від пакету model, оскільки він відображає дані, що зберігаються в 
моделі, та пересилає дії користувача до відповідних компонентів бізнес-логіки. 
Пакет com.pokergame.ai містить реалізацію штучного інтелекту для ботів 
різних рівнів складності. Він включає підпакети: ai.strategy (стратегії гри), 
ai.evaluation (оцінка ситуації) та ai.decision (прийняття рішень). Цей пакет 
залежить від пакету model, оскільки використовує інформацію про стан гри для 
прийняття рішень та змінює стан об'єктів гравців. Пакет 
com.pokergame.persistence відповідає за збереження та завантаження даних, 
включаючи стан гри, профілі користувачів та статистику. Він містить 
підпакети: persistence.serialization (серіалізація/десеріалізація об'єктів), 
persistence.profile (робота з профілями користувачів) та persistence.statistics (збір 
та аналіз статистики). Цей пакет залежить від пакету model для доступу до 
даних, які потрібно зберегти або завантажити. 
Пакет com.pokergame.util містить допоміжні класи та утиліти, які 
використовуються різними частинами системи. Він включає компоненти для 
логування, обробки помилок, математичних розрахунків, генерації випадкових 
чисел та інші сервісні функції. Цей пакет не має залежностей від інших пакетів 
системи, але багато пакетів залежать від нього. Пакет 
com.pokergame.configuration відповідає за налаштування та конфігурацію 
системи, включаючи параметри гри, візуальні налаштування та керування 
локалізацією [11]. Цей пакет взаємодіє з усіма іншими пакетами, надаючи їм 
необхідні параметри конфігурації та дозволяючи змінювати поведінку системи 
без необхідності модифікації коду. 
2.4 Архітектурне проєктування 
39 
ЧДТУ 252164.016ПЗ 
2.4.1 Розробка діаграми компонентів 
Діаграма компонентів програмного забезпечення гри в покер відображає 
 фізичну структуру системи, демонструючи організацію та залежності між її 
програмними модулями. На відміну від діаграми класів, яка представляє 
логічну структуру, діаграма компонентів акцентує увагу на фізичних 
артефактах системи, таких як виконувані файли, бібліотеки, пакети та інші 
ресурси. Центральним компонентом системи є PokerGame.jar – основний 
виконуваний файл, який містить точку входу до додатку та координує роботу 
всіх інших компонентів. Цей компонент надає інтерфейси IGameController та 
IUserInterface, які використовуються іншими частинами системи для взаємодії з 
ядром додатку. Компонент PokerGame.jar залежить від усіх інших компонентів 
системи та відповідає за їх правильну ініціалізацію та взаємодію (рис. 2.3). 
 
 
Рисунок 2.4 - Діаграма компонентів програмного забезпечення гри в покер 
 
Компонент GameLogic.jar реалізує основну бізнес-логіку гри, включаючи 
правила покеру, визначення переможця та управління ігровим процесом. Він 
надає інтерфейси IGameRules, IHandEvaluator та IGameState, які 
40 
ЧДТУ 252164.016ПЗ 
використовуються іншими компонентами для доступу до функціональності гри. 
Цей компонент залежить від Model.jar, який містить основні класи даних, та 
Utilities.jar, що надає допоміжні функції. 
Компонент AI.jar відповідає за реалізацію штучного інтелекту ботів та 
надає інтерфейс IBotStrategy для взаємодії з різними рівнями ботів. Він 
залежить від GameLogic.jar для отримання інформації про стан гри та правила, 
а також від Utilities.jar для використання математичних функцій та генерації 
випадкових чисел. AI.jar використовує шаблон проектування «Стратегія» для 
реалізації різних підходів до гри в залежності від рівня складності бота. 
Компонент UI.jar реалізує графічний інтерфейс користувача, включаючи 
відображення карт, ставок, ігрового столу та контролів для взаємодії. Він надає 
інтерфейс IUserInput для обробки дій користувача та залежить від 
GameLogic.jar для доступу до стану гри, а також від Resources.jar, який містить 
графічні та звукові ресурси. UI.jar побудований з використанням бібліотеки 
JavaFX, що дозволяє створити сучасний та інтерактивний інтерфейс. 
Компонент Persistence.jar відповідає за збереження та завантаження 
даних, включаючи стан гри, профілі користувачів та статистику. Він надає 
інтерфейси IDataStorage та IStatistics для роботи з даними та залежить від 
Model.jar для доступу до об'єктів, які потрібно зберегти [12]. Цей компонент 
використовує серіалізацію Java для збереження об'єктів та SQLite для 
зберігання структурованих даних, таких як статистика та налаштування. 
2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання 
Діаграма розгортання для програмного забезпечення гри в покер 
представляє фізичну архітектуру системи, показуючи, яким чином компоненти 
програмного забезпечення розподіляються по апаратних вузлах та як ці вузли 
взаємодіють один з одним. Оскільки розроблюване програмне забезпечення є 
настільним додатком, його архітектура розгортання є відносно простою, але все 
ж важливою для забезпечення правильної роботи системи. 
Основним вузлом розгортання є комп'ютер користувача (Client 
Workstation), на якому запускається програмне забезпечення гри в покер. Цей 
41 
ЧДТУ 252164.016ПЗ 
вузол представлений у вигляді фізичного пристрою з операційною системою 
(Windows, macOS або Linux), на якій встановлена Java Virtual Machine (JVM). 
JVM є необхідною умовою для запуску додатку, розробленого на мові Java, і 
забезпечує його платформонезалежність. На цьому вузлі розміщуються всі 
основні артефакти програмного забезпечення: виконуваний JAR-файл, 
бібліотеки та ресурси. 
Додатковим вузлом, що може бути задіяний у системі, є локальна 
файлова система (Local File System), яка використовується для зберігання даних 
програми: профілів користувачів, збережених ігор, статистики та налаштувань. 
Цей вузол представлений як логічний пристрій, доступний через стандартний 
інтерфейс файлової системи операційної системи. Комунікація між основним 
додатком та файловою системою здійснюється через протокол доступу до 
файлів, що надається операційною системою. 
Для забезпечення крос-платформності програмного забезпечення, 
діаграма розгортання враховує різні конфігурації для різних операційних 
систем. Для Windows-системи передбачається розміщення програмних файлів у 
стандартному каталозі Program Files, для macOS – у каталозі Applications, а для 
Linux – у каталозі /opt або домашньому каталозі користувача. Дані програми 
(профілі, збережені ігри тощо) розміщуються у відповідних каталогах для 
користувацьких даних кожної операційної системи. 
Діаграма розгортання також відображає структуру основного артефакту – 
виконуваного JAR-файлу, який містить усі необхідні класи та ресурси для 
роботи програми. Цей файл створюється з використанням інструменту збірки 
Maven або Gradle, який забезпечує правильне включення всіх залежностей та 
ресурсів. Виконуваний JAR-файл є самодостатнім і може запускатися 
безпосередньо через JVM без необхідності встановлення додаткового 
програмного забезпечення. 
Для спрощення процесу встановлення та запуску програми 
передбачається створення інсталяційного пакету, який автоматично встановлює 
необхідну версію JVM (якщо вона відсутня), розгортає програмні файли в 
правильні каталоги та створює ярлики для запуску додатку [13]. Інсталяційний 
42 
ЧДТУ 252164.016ПЗ 
пакет також налаштовує необхідні системні змінні та права доступу, щоб 
забезпечити коректну роботу програми на комп'ютері користувача. 
 
Рисунок 2.5 – Діаграма розгортання 
 
Діаграма розгортання демонструє фізичне розташування компонентів 
програмного забезпечення на апаратних та логічних вузлах системи. Вона 
дозволяє зрозуміти, як структуровано працює десктопна гра в покер, які 
компоненти взаємодіють і які середовища їх підтримують. 
Client Workstation (ПК користувача) 
 Основне фізичне середовище, де запускається додаток. 
 Містить операційну систему (Windows/macOS/Linux), на якій 
встановлена Java Virtual Machine (JVM). 
Java Virtual Machine 
 Забезпечує виконання Java-додатку незалежно від ОС. 
 Містить 
43 
ЧДТУ 252164.016ПЗ 
 Poker Game App (JAR) — основний виконуваний файл з усією 
логікою гри. 
 AI Module — відповідає за поведінку ботів (3 рівні складності). 
 UI Module (JavaFX) — відображає інтерфейс користувача, карти, 
ставки, кнопки дій. 
 Analytics & Stats Module — збирає й обробляє статистику гри. 
Файлова система 
 Використовується для локального зберігання: 
 User Profiles — збереження налаштувань, рівня ботів тощо; 
 Saved Games — дозволяє продовжити гру після перезапуску; 
 Game Logs — журнал ігрових подій, який може бути використаний 
для аналітики або налагодження; 
 Взаємодія з додатком відбувається через файловий інтерфейс ОС. 
Інсталятор 
 У разі відсутності JVM автоматично її встановлює. 
 Розгортає JAR-файл у відповідну директорію: 
 Program Files (Windows) 
 Applications (macOS) 
 /opt або домашній каталог (Linux) 
 Створює ярлики запуску та встановлює змінні середовища. 
Комунікація 
 Між компонентами JVM відбувається внутрішньо, через виклики 
методів. 
 З файловою системою взаємодія забезпечується стандартними API 
доступу до файлів. 
 Компоненти модуля AI періодично звертаються до модуля аналітики 
для адаптації поведінки. 
2.5 Моделювання поведінки системи 
2.5.1 Розробка діаграми діяльності 
44 
ЧДТУ 252164.016ПЗ 
Діаграма діяльності для програмного забезпечення гри в покер надає 
графічне представлення алгоритмів та потоків роботи системи, що дозволяє 
чітко визначити послідовність дій та розгалуження при різних умовах. Для 
проектованої гри в покер була розроблена діаграма діяльності, яка моделює 
основний ігровий цикл, починаючи від ініціалізації гри і до визначення 
переможця раунду. 
Діаграма розпочинається з початкового вузла, після якого слідує дія 
"Ініціалізувати гру", що включає створення нової колоди карт, визначення 
початкових позицій гравців та розподіл фішок. Далі потік розділяється на 
паралельні дії: "Змішати колоду" та "Встановити позиції блайндів", які можуть 
виконуватися одночасно. Після виконання цих дій потік знову об'єднується, і 
система переходить до дії "Роздати початкові карти", при якій кожен гравець 
отримує по дві карти. Після роздачі карт розпочинається цикл ставок, що 
складається з декількох раундів: префлоп, флоп, терн та рівер. Для кожного 
раунду виконується набір дій: "Збір ставок", "Відкриття спільних карт" (крім 
преflop) та "Перевірка умов завершення раунду". Цикл ставок моделюється за 
допомогою розгалуження та злиття потоків, а також застосуванням вузлів 
рішення для визначення наступних кроків. Наприклад, якщо після збору ставок 
залишився лише один активний гравець, потік переходить до дії "Визначити 
переможця" без відкриття додаткових карт. 
Діаграма також включає моделювання поведінки гравців під час їхнього 
ходу. Коли настає черга гравця, система перевіряє, чи є він людиною або ботом. 
Якщо це людина, потік переходить до дії "Очікувати рішення користувача", яка 
може завершитися однією з п'яти дій: "Фолд", "Чек", "Колл", "Бет" або "Рейз". 
Якщо це бот, потік переходить до дії "Обчислити рішення бота", яка включає 
аналіз ситуації, оцінку сили руки та прийняття рішення відповідно до рівня 
складності бота [14]. 
Діаграма діяльності завершується після визначення переможця та 
розподілу фішок банку. Фінальний вузол розділяється на два варіанти: 
"Продовжити гру" (повернення до етапу змішування колоди та встановлення 
блайндів) або "Завершити гру" (перехід до фінального вузла), що залежить від 
45 
ЧДТУ 252164.016ПЗ 
вибору користувача або умов завершення гри, таких як вичерпання фішок у 
всіх гравців, крім одного (рис. 2.4).  
 
Рисунок 2.6 - Діаграма діяльності програмного забезпечення гри в покер 
 
Представлена діаграма наочно відображає циклічну природу ігрового 
процесу, логічні розгалуження на основі кількості активних гравців після 
кожного раунду торгівлі, а також паралельні процеси прийняття рішень 
46 
ЧДТУ 252164.016ПЗ 
різними типами гравців (користувач та боти). Діаграма служить основою для 
подальшої реалізації алгоритмічної логіки в програмному коді. 
2.5.2 Проєктування діаграми послідовності 
Діаграма послідовності для програмного забезпечення гри в покер 
демонструє хронологічний порядок взаємодії між об'єктами системи під час 
виконання певного сценарію. Для повноцінного моделювання гри було 
розроблено кілька діаграм послідовності, що відображають ключові сценарії 
взаємодії, такі як ініціалізація гри, проведення раунду ставок та визначення 
переможця. 
Діаграма послідовності для сценарію "Ініціалізація гри" починається з 
об'єкта GameController, який отримує повідомлення startNewGame() від 
користувача через інтерфейс. Далі GameController створює нові екземпляри 
об'єктів Game, Table та Deck. Після цього Game викликає метод initialize() 
об'єкта Deck, який створює та перемішує колоду карт. Паралельно 
GameController ініціалізує гравців, викликаючи метод createPlayer() для 
кожного учасника, та розміщує їх за столом за допомогою методу seatPlayer() 
об'єкта Table. 
Діаграма послідовності для сценарію "Проведення раунду ставок" 
ілюструє взаємодію об'єктів під час збору ставок з гравців. Вона починається з 
об'єкта Game, який викликає метод startBettingRound() об'єкта BettingRound. 
Далі BettingRound послідовно взаємодіє з кожним активним гравцем, 
викликаючи метод requestAction(). Якщо гравець є екземпляром класу 
HumanPlayer, BettingRound взаємодіє з UIManager для відображення опцій 
користувачу та отримання його рішення. Якщо гравець є екземпляром класу 
BotPlayer, BettingRound викликає метод calculateAction() об'єкта BotStrategy, 
який аналізує ситуацію та повертає рішення бота. 
Діаграма послідовності для сценарію "Визначення переможця" показує 
процес визначення переможця раунду після завершення всіх ставок. Вона 
починається з об'єкта Game, який викликає метод determineWinner() об'єкта 
HandEvaluator. Далі HandEvaluator для кожного активного гравця викликає 
метод evaluateHand(), який обчислює силу комбінації гравця. Після оцінки всіх 
47 
ЧДТУ 252164.016ПЗ 
рук HandEvaluator порівнює їх між собою за допомогою методу compareHands() 
та визначає переможця або переможців у разі нічиєї. Нарешті, Game викликає 
метод awardPot() об'єкта Pot для розподілу фішок між переможцями (рис. 2.5). 
 
 
Рисунок 2.7 - Діаграма послідовності для гри в покер 
 
Всі діаграми послідовності також включають обмін повідомленнями з 
об'єктом UIManager для відображення відповідної інформації користувачеві та 
отримання його вводу. Наприклад, після кожної дії системи, такої як роздача 
карт, збір ставок або визначення переможця, Game викликає методи 
updateView() або showMessage() об'єкта UIManager для оновлення інтерфейсу 
користувача. Особлива увага на діаграмах приділяється обробці виняткових 
ситуацій, таких як невалідні дії користувача або помилки обчислень. У таких 
випадках об'єкти системи обмінюються повідомленнями про помилки, які 
обробляються відповідними методами, що забезпечує стійкість системи до 
нестандартних сценаріїв використання. 
2.5.3 Побудова діаграми комунікації 
Діаграма комунікації для програмного забезпечення гри в покер є 
альтернативним способом представлення взаємодії між об'єктами системи, 
акцентуючи увагу на зв'язках між об'єктами, а не на часовій послідовності 
48 
ЧДТУ 252164.016ПЗ 
повідомлень. Для моделювання ключових аспектів гри була розроблена 
діаграма комунікації, яка доповнює інформацію, представлену на діаграмах 
послідовності (рис. 2.6). 
 
 
Рисунок 2.8 - Діаграма комунікації для гри в покер 
 
Центральне місце на діаграмі комунікації займає об'єкт Game, який має 
зв'язки з об'єктами Player, Table, Deck, HandEvaluator та BettingRound. Кожен 
зв'язок супроводжується повідомленнями, пронумерованими в порядку їх 
виконання. Наприклад, зв'язок між Game та Deck включає повідомлення "1: 
initialize()", "2: shuffle()" та "3: dealCard()", що відображає послідовність 
взаємодії цих об'єктів під час ініціалізації та роздачі карт. Об'єкти Player на 
діаграмі представлені двома екземплярами: humanPlayer та botPlayer, які мають 
зв'язки з об'єктами Hand (для зберігання карт) та Game. Повідомлення, що 
передаються між Game та Player, включають "4: placeBet(amount)", "5: 
checkOptions()" та "6: makeDecision()", що відображає процес прийняття рішень 
гравцями. Особливістю діаграми є те, що botPlayer також має зв'язок з об'єктом 
BotStrategy, який відповідає за обчислення оптимального рішення для бота. 
Діаграма комунікації також відображає зв'язки між об'єктами інтерфейсу 
користувача. Об'єкт UIManager має зв'язки з об'єктами GameView, PlayerView 
та CardView, через які передаються повідомлення для оновлення відображення 
49 
ЧДТУ 252164.016ПЗ 
гри. Наприклад, між UIManager та GameView передаються повідомлення "7: 
updateTable()" та "8: showMessage(text)", а між UIManager та PlayerView – 
повідомлення "9: updateChips(amount)" та "10: highlightActivePlayer()". 
Особливістю розробленої діаграми комунікації є використання стереотипів для 
позначення різних типів об'єктів. Об'єкти, що відносяться до моделі даних, 
позначені стереотипом «entity», об'єкти інтерфейсу користувача – стереотипом 
«boundary», а об'єкти, що відповідають за керування процесами – стереотипом 
«control» [15]. Це дозволяє візуально розділити компоненти системи за їхньою 
функціональною роллю та краще зрозуміти архітектуру програмного 
забезпечення. 
2.5.4 Розробка діаграми скінченного автомату 
Діаграма скінченного автомату для програмного забезпечення гри в покер 
моделює зміни станів системи у відповідь на події та дії. Вона особливо 
корисна для представлення ігрового процесу, який характеризується чіткою 
послідовністю станів та переходів між ними. Для проектованої гри в покер була 
розроблена діаграма скінченного автомату, що відображає життєвий цикл 
однієї гри від початку до завершення (рис. 2.7). 
 
 
Рис. 2.9 - Діаграма скінченного автомату для гри в покер 
 
Діаграма починається з початкового стану, з якого система переходить до 
стану "Ініціалізація гри" при виклику методу startGame(). У цьому стані 
відбувається створення та ініціалізація всіх необхідних об'єктів гри. Після 
завершення ініціалізації система переходить до стану "Роздача карт", де гравці 
отримують свої приватні карти. Далі система послідовно проходить через 
50 
ЧДТУ 252164.016ПЗ 
стани, що відповідають раундам торгівлі: "Префлоп", "Флоп", "Терн" та 
"Рівер". 
Переходи між станами раундів торгівлі відбуваються при виконанні 
певних умов. Наприклад, перехід зі стану "Префлоп" до стану "Флоп" 
відбувається, коли всі гравці зробили свої ставки (або склали карти), і в грі 
залишається більше одного активного гравця. Якщо ж після будь-якого раунду 
торгівлі в грі залишається лише один активний гравець, система переходить до 
стану "Визначення переможця" без проходження через наступні раунди 
торгівлі. 
Стан "Визначення переможця" включає обчислення сили комбінацій 
активних гравців, порівняння їх між собою та визначення переможця або 
переможців. Після визначення переможця система переходить до стану 
"Розподіл банку", де фішки розподіляються між переможцями відповідно до 
їхніх часток. З цього стану система може перейти або до стану "Завершення 
гри" (якщо гра закінчена), або повернутися до стану "Роздача карт" для початку 
нового раунду (якщо гра продовжується). 
Діаграма скінченного автомату також включає внутрішні стани для 
моделювання процесу прийняття рішень гравцями. Наприклад, стан "Хід 
гравця" включає підстани "Очікування дії користувача" (для людини) або 
"Обчислення дії бота" (для комп'ютерного опонента) [16]. Переходи між цими 
підстанами відбуваються залежно від типу поточного гравця, а переходи зі 
стану "Хід гравця" до інших станів системи залежать від прийнятого рішення 
(фолд, чек, колл, бет, рейз). 
51 
ЧДТУ 252164.016ПЗ 
ВИСНОВОК ДО ДРУГОГО РОЗДІЛУ 
У другому розділі було здійснено всебічне проєктування програмного 
забезпечення гри в покер з урахуванням об'єктно-орієнтованого підходу та 
принципів моделювання складних систем. Проведено формалізацію предметної 
області, визначено ключові сутності гри в Техаський Холдем та їхні 
взаємозв’язки. Побудовано словник термінів, який забезпечує уніфіковане 
трактування понять серед учасників розробки. У межах визначення робочої 
області змодельовано основні режими гри (кеш-гра та турнір), типи гравців 
(людина та боти різної складності), а також елементи інтерфейсу користувача й 
механізми збереження даних. Сформульовано повний перелік функціональних 
та нефункціональних вимог до системи, які покликані гарантувати її коректну, 
ефективну та зручну експлуатацію. На основі вимог побудовано комплексну 
систему UML-діаграм, що охоплює логічну, структурну, поведінкову та 
фізичну моделі системи: діаграми прецедентів, класів, пакетів, компонентів, 
розгортання, діяльності, послідовності, комунікації та скінченних автоматів. Ці 
моделі забезпечують чітке уявлення про архітектуру системи, її ключові 
елементи та процеси взаємодії між ними, що є фундаментом для подальшої 
реалізації програмного продукту. Таким чином, виконане проєктування 
програмного забезпечення гри в покер забезпечує структуровану основу для 
наступного етапу розробки, дозволяючи мінімізувати ризики, покращити 
масштабованість системи та підвищити якість кінцевого продукту. 
 
  
52 
ЧДТУ 252164.016ПЗ 
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАМЕЗПЕЧЕННЯ 
3.1. Вибір мови програмування, середовища розробки та бібліотек 
Вибір мови програмування, середовища розробки та бібліотек у процесі 
створення програмного забезпечення гри в покер базувався на аналізі 
функціональних вимог, очікуваної архітектури системи, потреб у 
кросплатформності та розширюваності, а також на наявних інструментах, що 
спрощують розробку інтерфейсу, логіки та штучного інтелекту. У якості 
основної мови програмування обрано Java, оскільки вона є об'єктно-
орієнтованою, має потужну стандартну бібліотеку, а також забезпечує 
незалежність від конкретної операційної системи завдяки використанню 
віртуальної машини JVM. Це дозволяє створити один виконуваний файл, що 
працюватиме на Windows, Linux та macOS без перекомпіляції, що суттєво 
спрощує розповсюдження і підтримку програмного продукту. 
Для реалізації проєкту використовувалося середовище розробки IntelliJ 
IDEA, яке надає зручні інструменти для написання коду, налагодження, 
рефакторингу та інтеграції з системами контролю версій. IntelliJ IDEA також 
має потужну підтримку роботи з JavaFX та Maven, що дозволило 
автоматизувати керування залежностями та процесом збірки проєкту. 
Середовище підтримує функцію автодоповнення коду, що пришвидшує 
написання логіки, а також має інтегрований інструментарій для тестування, що 
забезпечило контроль якості коду під час розробки. 
Для створення графічного інтерфейсу користувача було обрано JavaFX – 
сучасну бібліотеку для побудови GUI в середовищі Java. Вона забезпечує 
гнучкий механізм відображення елементів інтерфейсу, підтримує стильове 
оформлення за допомогою CSS, а також дозволяє реалізувати анімації, що є 
важливою частиною візуалізації карткової гри. JavaFX має зручну інтеграцію з 
FXML – розміткою для опису інтерфейсів, що дає можливість відокремити 
логіку програми від її візуального представлення. 
53 
ЧДТУ 252164.016ПЗ 
Для реалізації складної логіки штучного інтелекту та ймовірнісних 
обчислень у поведінці ботів було використано бібліотеку Apache Commons 
Math, яка надала готові інструменти для роботи з розподілами, ймовірностями, 
статистикою та математичними функціями. Це дозволило зосередитися 
безпосередньо на стратегіях гри, а не на реалізації низькорівневих 
математичних обчислень. Для збереження статистики, прогресу гри та профілів 
гравців використано вбудовану базу даних H2 Database, яка працює локально і 
не потребує окремого сервера. H2 ідеально підходить для десктопних додатків 
завдяки малій вазі, високій швидкодії та простоті інтеграції з Java-проєктами. 
Доступ до бази даних реалізовано через JDBC, а для спрощення SQL-запитів 
використовувалися DAO-класи, що розмежовують логіку зберігання від решти 
системи. 
Організація структури проєкту, управління залежностями та процесом 
складання здійснювалася за допомогою Maven – стандартного інструменту для 
побудови Java-проєктів. Він дозволив чітко визначити всі бібліотеки, що 
використовуються, автоматизувати збірку та тестування, а також забезпечити 
стабільне середовище для розгортання програми. Поєднання Java, JavaFX, 
Apache Commons Math, H2 Database, Maven та середовища IntelliJ IDEA 
дозволило створити кросплатформний, модульний та розширюваний додаток з 
потужною логікою штучного інтелекту, сучасним графічним інтерфейсом та 
підтримкою збереження ігрового прогресу. Усі обрані технології є стабільними, 
активно підтримуються спільнотою та добре задокументовані, що забезпечує 
надійність, масштабованість і перспективність подальшого розвитку 
програмного продукту. Використання згаданих технологій дозволило 
забезпечити гнучку архітектуру системи, де кожен компонент функціонує 
автономно, але водночас інтегрується у загальну модель через чітко визначені 
інтерфейси. Це особливо важливо для реалізації модульного підходу, адже під 
час розробки штучного інтелекту для ботів з різними рівнями складності було 
необхідно ізолювати стратегії прийняття рішень від загальної логіки гри, що 
забезпечило зручність в тестуванні, розширенні та вдосконаленні цих 
компонентів у майбутньому. 
54 
ЧДТУ 252164.016ПЗ 
Окрім цього, значну увагу було приділено збереженню стабільності гри 
навіть у випадку нештатних ситуацій, зокрема раптового завершення сесії. 
Завдяки застосуванню механізмів серіалізації в Java та інтеграції з H2 Database 
стало можливим зберігати поточний стан гри, статистику користувача та інші 
важливі параметри без втрати даних. Це дозволяє користувачеві повертатися до 
гри з того місця, де вона була перервана, що особливо цінно у турнірному 
режимі з поступовим зростанням блайндів. Не менш важливою складовою 
стало забезпечення користувацького досвіду через адаптивний графічний 
інтерфейс. JavaFX не лише надає змогу створити сучасний вигляд програми, 
але й підтримує масштабування компонентів відповідно до розміру вікна, що 
особливо важливо для забезпечення зручності гри на пристроях із різними 
роздільними здатностями. Анімації карт, плавна зміна станів гри та інтуїтивна 
візуалізація дій гравців та ботів дозволяють створити ефект присутності за 
реальним покерним столом, що, у свою чергу, підвищує залучення користувача. 
Особливо слід зазначити роль багатопотокової обробки, яку Java дозволяє 
реалізовувати за допомогою стандартних механізмів управління потоками. Це 
стало ключовим у побудові відповідей ботів, які обчислюють свої дії у 
фоновому режимі, не блокуючи основний інтерфейс програми. Таким чином, 
гравець не відчуває затримок під час гри, а програма функціонує плавно та без 
перебоїв навіть при наявності великої кількості паралельних обчислень, 
пов’язаних із розрахунком ймовірностей, оновленням інтерфейсу та 
збереженням даних. Вибір саме Java як мови програмування, JavaFX для 
візуального представлення, H2 Database для локального зберігання, а також 
використання IntelliJ IDEA як середовища розробки дозволив побудувати 
потужний, стабільний та естетично привабливий програмний продукт, що 
поєднує інтелектуальну гру з простотою у використанні, незалежністю від 
платформи та широкими можливостями для подальшого розвитку. 
3.1.1Загальна структура програмного забезпечення 
Загальна структура програмного забезпечення гри в покер сформована на 
основі принципів об'єктно-орієнтованого програмування та модульної 
архітектури, що дозволяє розділити систему на окремі логічні компоненти з 
55 
ЧДТУ 252164.016ПЗ 
чітко визначеними функціями та зонами відповідальності. В основі структури 
лежить концепція багаторівневої організації, де взаємодія між елементами 
реалізується через інтерфейси та патерни проєктування, що сприяє гнучкості, 
масштабованості та зручності в підтримці коду. 
Ядро системи становить ігровий рушій, який відповідає за контроль усіх 
етапів гри: ініціалізацію сесії, роздачу карт, управління раундами ставок, 
обробку дій гравців, формування комбінацій та визначення переможця. Цей 
компонент взаємодіє з іншими частинами системи через централізований 
контролер, який виступає посередником між бізнес-логікою та графічним 
інтерфейсом користувача. Контролер обробляє команди користувача, викликає 
відповідні методи логіки гри, оновлює візуальні компоненти та ініціює дії 
ботів. Логіка гри зосереджена в окремих класах, що моделюють сутності 
предметної області: карти, колода, гравці, ставки, банк, комбінації, стіл і 
раунди. Кожен із цих елементів має власні атрибути та методи, які 
забезпечують їхню поведінку відповідно до правил Техаського Холдему. 
Наприклад, клас гравця містить логіку виконання ставок, перевірки фішок та 
зберігає поточні карти, тоді як клас банку акумулює загальну суму ставок та 
відповідає за її розподіл після завершення роздачі. 
Особливе місце у структурі займає підсистема штучного інтелекту, 
реалізована у вигляді окремого модуля. Вона включає стратегії гри, адаптовані 
до різних рівнів складності ботів. Кожен бот аналізує поточний стан гри, силу 
своєї руки, поведінку інших гравців та приймає рішення відповідно до заданої 
моделі. Взаємодія ботів з ігровим рушієм здійснюється через загальний 
інтерфейс, що дозволяє легко змінювати або доповнювати поведінкові шаблони 
без втручання в основний код гри. 
Графічний інтерфейс, побудований на базі JavaFX, реалізує візуалізацію 
всіх аспектів ігрового процесу, включаючи відображення карт, фішок, ставок, 
повідомлень та діалогів. Інтерфейс адаптовано до різних розмірів екрану та 
забезпечено логічним розміщенням елементів для комфортної взаємодії з 
користувачем. Кожна дія гравця (наприклад, натискання кнопки для ставки або 
56 
ЧДТУ 252164.016ПЗ 
фолду) обробляється через контролери, які надсилають відповідні сигнали до 
ядра гри та оновлюють відображення відповідно до нового стану системи. 
Для збереження даних про користувача, його досягнення, статистику та 
налаштування використовується вбудована база даних, яка зберігає інформацію 
локально. Це дозволяє забезпечити незалежність від зовнішніх серверів та 
доступність офлайн. Всі операції з базою даних реалізовані через окремий 
модуль з підтримкою серіалізації об’єктів, що дає змогу зберігати повноцінні 
об'єкти гри без необхідності ручного розбору їх структури. 
Допоміжні сервіси, такі як генерація випадкових чисел, логування подій, 
обробка помилок та підтримка локалізації, згруповані в окремий утилітний 
модуль. Це дозволяє забезпечити централізований доступ до спільних функцій 
та мінімізує дублювання коду в інших частинах проєкту. Завдяки цьому 
архітектура залишається чистою, керованою та зручною для тестування. 
У підсумку, загальна структура програмного забезпечення побудована таким 
чином, щоб забезпечити максимальну модульність, незалежність компонентів 
та можливість масштабування. Це створює передумови для подальшого 
розвитку системи – наприклад, додавання нових режимів гри, розширення 
поведінки ботів або інтеграції з онлайн-сервісами – без потреби в радикальних 
змінах у вже реалізованій логіці (таблиця 3.1). 
 
Таблиця 3.1 
Характеристика компонентів програмного забезпечення гри в покер 
№ Назва Призначення Основні функції 
компонента 
1 Game Основний керуючий Ініціалізація гри, управління 
клас ігрового раундами, взаємодія з 
процесу гравцями та визначення 
переможця 
 
57 
ЧДТУ 252164.016ПЗ 
Продовження таблиці 3.1 
2 Player Абстрактне Містить атрибути та методи, 
представлення гравця спільні для людини й бота: 
ставки, карти, рішення 
3 HumanPlayer Реалізація гравця- Взаємодія з інтерфейсом, 
користувача прийняття рішень вручну 
4 BotPlayer Реалізація гравця- Автоматичне прийняття 
бота рішень відповідно до рівня 
складності 
5 Deck Представлення Створення, ініціалізація та 
колоди карт перетасовка колоди, видача 
карт 
6 Card Опис окремої карти Масть, значення, методи 
порівняння 
7 HandEvaluator Клас для оцінювання Визначення типу руки, 
сили комбінацій порівняння комбінацій, 
визначення переможця 
8 Table Модель віртуального Розміщення гравців, 
покерного столу управління позицією дилера, 
зберігання спільних карт та 
ставок 
9 UIManager Менеджер Відображення карт, ставок, 
графічного повідомлень, обробка вводу 
інтерфейсу користувача 
10 GameSerializer Компонент Серіалізація та десеріалізація 
збереження та об’єктів, збереження в файл 
завантаження стану або базу даних 
гри 
11 StatisticsManager Модуль збору та Фіксація виграшів, розмірів 
аналізу статистичних банків, дій гравців, побудова 
даних звітів 
58 
ЧДТУ 252164.016ПЗ 
Продовження таблиці 3.1 
12 BotStrategy Стратегія поведінки Алгоритми прийняття рішень 
бота на основі сили руки, позиції, 
історії ставок тощо 
13 ConfigurationMan Налаштування Зчитування конфігураційних 
ager параметрів гри, файлів, передача параметрів 
зовнішнього вигляду до інших компонентів 
та локалізації 
 
Після побудови таблиці компонентів стає очевидним, що така структура 
дозволяє реалізувати чітку ієрархію відповідальностей у межах програмного 
забезпечення, уникнувши дублювання коду та забезпечивши зручність 
супроводу. Взаємозв’язки між компонентами побудовані так, щоб ядро гри 
могло функціонувати незалежно від графічного інтерфейсу, а інтерфейс, у свою 
чергу, лише відображав стан системи, не змінюючи його напряму. Це дає змогу 
у майбутньому легко адаптувати додаток до нових платформ або впровадити 
альтернативні способи взаємодії, наприклад голосове управління чи мобільні 
адаптації. 
Крім того, таке розділення дозволяє ізолювати функціональність 
штучного інтелекту та зробити її легко змінною або розширюваною. Завдяки 
окремому блоку зі стратегіями ботів можливо поступово ускладнювати логіку 
їх поведінки, не порушуючи цілісності ігрового процесу. Це є надзвичайно 
важливим для створення реалістичної поведінки ботів, що імітує різні типи 
гравців — від новачків до професіоналів. Такий підхід також відкриває 
можливості для навчання гравців, які можуть спостерігати за діями ботів 
високого рівня, аналізувати їхню логіку і покращувати власну гру. 
Збереження та обробка статистики також винесені в окремий компонент 
для забезпечення повного контролю над ігровою аналітикою. Статистичний 
модуль дозволяє не тільки фіксувати результат кожної партії, а й формувати 
тренди поведінки гравця, виявляти сильні та слабкі сторони його стратегії. На 
59 
ЧДТУ 252164.016ПЗ 
базі таких даних можливо реалізувати систему персоналізованих рекомендацій, 
яка підказуватиме гравцеві, які аспекти його гри потребують покращення. 
Завдяки ізоляції механізмів конфігурації в окремий блок, налаштування 
параметрів гри стало зручним як для користувача, так і для розробника. Це 
дозволяє змінювати структуру блайндів, кількість ботів, оформлення 
інтерфейсу або мову без необхідності втручання в основний код гри. Така 
гнучкість є суттєвою перевагою, особливо при масштабуванні проєкту або 
створенні локалізованих версій для різних ринків. 
Загальна архітектура системи побудована з урахуванням майбутньої 
підтримки, тестування та оновлення. Модульний підхід, чітко окреслені 
функції кожного класу та контрольовані взаємозв’язки між ними створюють 
передумови для того, щоб програмне забезпечення залишалося актуальним, 
ефективним та легко адаптованим упродовж тривалого часу. У сукупності це 
забезпечує якісну основу для подальшого розвитку гри, з можливістю інтеграції 
нових сценаріїв, режимів гри або навіть переходу до повноцінного 
мультиплеєра в майбутньому. 
Зважаючи на описану архітектурну модель, можна стверджувати, що 
розроблене програмне забезпечення не лише відповідає вимогам щодо 
функціональності, а й забезпечує високий рівень масштабованості та гнучкості. 
В основі цієї системи лежить прагнення до забезпечення повноцінного 
користувацького досвіду без компромісів між продуктивністю, стабільністю та 
інтуїтивністю використання. Кожен елемент системи спроєктовано з 
урахуванням можливих змін, доповнень або адаптацій, що дозволяє уникнути 
потреби в радикальних перебудовах у разі розширення функціоналу чи зміни 
технологічних вимог. 
Паралельно з технічним проєктуванням особлива увага приділяється 
забезпеченню послідовності та логіки користувацької взаємодії. Візуальна 
складова гри не є другорядною — навпаки, вона слугує ключовим каналом 
комунікації між системою та користувачем. Кожна дія, яку виконує гравець, 
має миттєве відображення в інтерфейсі, що сприяє створенню ефекту реальної 
присутності за покерним столом. Це досягається не лише завдяки 
60 
ЧДТУ 252164.016ПЗ 
використанню JavaFX для побудови сучасного графічного інтерфейсу, але й 
завдяки чітко організованій архітектурі, яка дозволяє інтерфейсу миттєво 
реагувати на зміни у внутрішньому стані гри. 
Система також враховує важливість стабільності та стійкості до помилок. 
Завдяки передбаченому механізму обробки винятків та журналювання подій, 
розробник отримує змогу виявляти й усувати потенційні проблеми на ранніх 
етапах. Це критично важливо в контексті розробки настільного додатку, який 
повинен працювати в автономному режимі без втручання технічного 
персоналу. Саме тому внутрішні перевірки на коректність дій, обробка 
невалідних ситуацій та повідомлення про помилки реалізовано у вигляді 
системи захищених блоків із детальними повідомленнями та логами. 
Особливої уваги заслуговує реалізація збереження прогресу, оскільки 
вона забезпечує безперервність ігрового процесу, дозволяючи користувачеві 
повертатися до незавершеної гри навіть після неочікуваного завершення 
програми. Усі параметри, включаючи статистику, налаштування гри та 
поточний стан роздачі, фіксуються у вигляді серіалізованих об'єктів і 
зберігаються локально. Це гарантує збереження даних навіть у середовищах без 
стабільного доступу до зовнішніх сховищ чи інтернету, що є важливою 
перевагою офлайн-режиму. 
У такому вигляді програмне забезпечення виступає не просто засобом 
розваги, а повноцінною платформою для вдосконалення навичок гри в покер, 
аналізу власної стратегії та отримання зворотного зв’язку через аналітичні 
звіти. Завдяки злагодженій взаємодії всіх компонентів та добре спроєктованій 
архітектурі, система здатна забезпечити як новачків, так і досвідчених гравців 
інструментом, що відповідає їхнім очікуванням і стимулює до подальшого 
розвитку. 
3.1.2 Реалізація логіки гри 
Реалізація логіки гри є центральним аспектом програмного забезпечення, 
адже саме вона визначає, як буде відбуватися ігровий процес, якими будуть 
правила, послідовність дій гравців та реакція системи на події, що виникають 
під час гри. Логіка гри базується на строгому дотриманні правил Техаського 
61 
ЧДТУ 252164.016ПЗ 
Холдему, де кожна роздача проходить кілька етапів, починаючи з ініціалізації 
нової партії, роздачі карт гравцям, проведення раундів торгівлі і завершуючи 
визначенням переможця та розподілом банку. 
У центрі реалізації логіки знаходиться клас Game, який відповідає за 
координацію всіх дій та зберігає стан гри. Його методи керують перебігом 
раундів, черговістю ходів гравців, виявленням завершення гри та переходами 
між фазами. На етапі ініціалізації гри створюється нова колода карт, 
визначається дилер, встановлюються малі та великі блайнди, розподіляються 
фішки, та викликається процедура роздачі стартових карт кожному гравцеві. 
Після роздачі карт розпочинається перший раунд торгівлі — префлоп. 
Кожному активному гравцю послідовно надається хід. Якщо гравець є ботом, 
система автоматично викликає відповідну стратегію, що залежить від рівня 
складності. Якщо ж гравець — користувач, інтерфейс відображає доступні дії, і 
гра очікує на рішення. Кожна дія — фолд, колл, чек, бет або рейз — впливає на 
стан гри: змінюється кількість фішок у банку, визначається черговість ходу, або 
завершується раунд, якщо всі гравці зробили ставки або пас. 
Після префлопу система відкриває три спільні карти — флоп. 
Відбувається наступний раунд торгівлі за аналогічною логікою. Далі 
відкривається четверта карта (терн) і проводиться ще один раунд. Після нього 
— рівер, п’ята карта, і завершується останній раунд торгівлі. У будь-який 
момент, якщо всі гравці, крім одного, пасують, гра автоматично завершується і 
фішки з банку передаються останньому активному гравцеві. У разі, коли кілька 
гравців залишаються в грі до шоудауну, активується механізм визначення 
переможця. Комбінації карт кожного з гравців аналізуються через клас 
HandEvaluator. Його методи обчислюють силу руки шляхом поєднання двох 
карт гравця зі спільними картами на столі, після чого здійснюється порівняння 
рангу комбінацій. Перемагає гравець або гравці з найсильнішою комбінацією, і 
банк ділиться відповідно до кількості переможців. 
Після завершення роздачі гра переходить у стан очікування наступної 
партії. Якщо активовано турнірний режим, система перевіряє, чи залишились 
гравці з фішками, і якщо так — починається нова роздача з оновленими 
62 
ЧДТУ 252164.016ПЗ 
блайндами. Якщо ж гра завершена — відбувається оновлення статистики, 
збереження результатів у профіль користувача та перехід до головного меню 
або повторного старту гри. 
Логіка гри реалізується через взаємодію кількох модулів: ігрового 
контролера, моделей гравців, стола, карт і оцінювача комбінацій. Вся ця 
взаємодія побудована навколо подій і станів, кожен з яких має чітко визначену 
реакцію з боку системи. Такий підхід гарантує не лише коректність гри 
відповідно до правил, а й дозволяє легко розширювати функціонал, додаючи 
нові режими або вдосконалюючи алгоритми прийняття рішень ботами. 
Подальший розвиток логіки гри потребує особливої уваги до реалізації 
адаптивної поведінки ботів, оскільки саме ця складова суттєво впливає на 
якість користувацького досвіду. Алгоритм прийняття рішень ботами 
побудований на багаторівневій моделі, яка залежить від складності. На 
базовому рівні боти приймають рішення, спираючись лише на силу стартової 
руки без урахування позиції за столом або дій опонентів. Це дозволяє новачкам 
поступово звикати до гри, не стикаючись із надто складними суперниками. 
На середньому рівні бот вже враховує позицію за столом, відношення 
ставки до банку та історію торгівлі поточного раунду. Він оцінює ситуацію не 
лише за поточними картами, а й намагається проаналізувати можливі сценарії 
розвитку гри. Це підвищує реалізм, адже створює враження, що бот 
«спостерігає» за грою, адаптуючи стратегію. Найвищий рівень складності ботів 
реалізує умовну психологічну модель, яка імітує поведінку досвідченого 
гравця. Такий бот здатен змінювати стиль гри від пасивного до агресивного 
залежно від успішності попередніх роздач, виявляти слабкість опонента на 
основі статистики та використовувати блеф як окремий елемент стратегії. Це 
значно ускладнює передбачення його дій і вимагає від користувача розвивати 
навички читання гри. 
В основі всіх рівнів ботів лежить єдиний інтерфейс для оцінювання 
ситуації, що дозволяє модифікувати або замінювати логіку без втручання в 
основну структуру системи. Це забезпечує гнучкість при подальшому 
63 
ЧДТУ 252164.016ПЗ 
вдосконаленні стратегій, що особливо важливо, якщо в майбутньому буде 
реалізовано режим навчання або симуляційний аналіз ігрових сценаріїв. 
Іншою важливою частиною реалізації є система збереження ігрового 
прогресу. Після кожної завершеної гри система фіксує у профілі користувача 
всю релевантну інформацію: кількість роздач, відсоток перемог, середній 
розмір банку, частоту використання конкретних дій, а також співвідношення 
агресивних та пасивних стратегій. У подальшому ці дані слугують базою для 
виводу графіків, аналізу прогресу гравця та, за потреби, коригування складності 
гри. Особливий механізм передбачає захист користувача від втрати даних: гра 
зберігається автоматично після кожного завершеного раунду, а також за 
запитом гравця в будь-який момент. Це дозволяє миттєво повернутись до гри 
після закриття програми або збоїв системи, що особливо важливо в умовах 
офлайн-режиму. 
Уся логіка гри побудована відповідно до шаблону «подія-реакція», де 
кожен хід гравця, рішення бота або стан колоди викликає відповідні зміни в 
системі. Це забезпечує високу прозорість роботи програми, легкість тестування 
та відлагодження, а також підтримку модульності — ключового принципу при 
реалізації складних програмних систем. У підсумку, така реалізація логіки гри 
гарантує не лише дотримання правил, а й створює динамічний, гнучкий та 
інтелектуально насичений ігровий процес, який залишається захоплюючим 
навіть після десятків зіграних партій (рис. 3.1). 
    A[Початок гри] --> B[Ініціалізація колоди карт] 
    B --> C[Роздача двох карт кожному гравцю] 
    C --> D[Префлоп - перший раунд торгівлі] 
    D --> E{Більше одного активного гравця?} 
    E -- Так --> F[Флоп - відкриття трьох спільних карт] 
    F --> G[Другий раунд торгівлі] 
    G --> H{Більше одного активного гравця?} 
    H -- Так --> I[Терн - відкриття четвертої карти] 
    I --> J[Третій раунд торгівлі] 
    J --> K{Більше одного активного гравця?} 
64 
ЧДТУ 252164.016ПЗ 
    K -- Так --> L[Рівер - відкриття п'ятої карти] 
    L --> M[Четвертий раунд торгівлі] 
    M --> N{Більше одного активного гравця?} 
    N -- Так --> O[Шоудаун - порівняння комбінацій] 
    N -- Ні --> P[Визначення переможця] 
    O --> Q[Розподіл банку] 
    P --> Q 
    Q --> R{Продовжити гру?} 
    R -- Так --> B 
    R -- Ні --> S[Завершення гри] 
Схема, що зображує логіку гри в покер, слугує наочним підтвердженням 
послідовності та взаємозв’язку основних етапів ігрового процесу. Вона 
демонструє циклічну природу гри, в якій кожна нова роздача слідує після 
попередньої, якщо користувач не обрав завершення сеансу. Усі логічні гілки — 
від роздачі карт до відкриття спільних карт та визначення переможця — 
взаємопов’язані перевірками на кількість активних гравців, що забезпечує 
коректну та реалістичну поведінку системи. Рішення про продовження гри 
залишається за користувачем, або ж визначається завершенням турнірного 
режиму в разі вичерпання фішок у всіх, крім одного гравця. Такий підхід 
гарантує підтримку не лише класичної структури Техаського Холдему, а й 
створює гнучкий фундамент для реалізації додаткових варіантів гри, як-от Sit 
and Go, багатоетапні турніри чи навіть тренувальні симуляції з аналізом 
помилок. 
Важливою особливістю розробленої структури є чіткий розподіл 
відповідальностей між компонентами системи, що не лише полегшує її 
тестування та розширення, а й сприяє підвищенню стабільності, надійності та 
передбачуваності гри, що є критичним для позитивного користувацького 
досвіду. Якщо потрібно — можу додати пояснення до кожного блоку схеми або 
продовжити з іншим підрозділом. 
 
65 
ЧДТУ 252164.016ПЗ 
 
Рисунок 3.1 - Логічна схема гри в покер 
3.1.3 Розробка графічного інтерфейсу користувача 
66 
ЧДТУ 252164.016ПЗ 
Розробка графічного інтерфейсу користувача (GUI) для програмного 
забезпечення гри в покер є критичним етапом, що значною мірою визначає 
зручність, інтуїтивність і загальне враження від взаємодії з додатком. Основна 
мета цього інтерфейсу полягає у візуалізації всіх аспектів гри, починаючи з 
ігрового столу, розміщення карт і фішок, і завершуючи повідомленнями, 
підказками та аналітикою, доступною користувачеві. Оскільки додаток 
розробляється на мові програмування Java, для реалізації інтерфейсу було 
обрано фреймворк JavaFX, який забезпечує потужні можливості для створення 
сучасних, адаптивних та інтерактивних GUI-рішень. 
Інтерфейс гри в покер має умовний поділ на кілька візуальних областей. 
Центральна частина екрану відведена під віртуальний ігровий стіл, на якому 
розміщуються спільні карти, відображається банк і дії, що виконуються 
гравцями. Навколо столу розташовуються аватари або ідентифікатори гравців, 
включаючи як користувача, так і ботів, із вказанням їх кількості фішок, 
поточних ставок і статусу в роздачі. Кожен гравець має окрему панель, яка 
оновлюється в режимі реального часу відповідно до дій, що відбуваються у грі. 
У нижній частині екрана розміщується інтерактивна панель управління, за 
допомогою якої користувач може здійснювати ігрові дії: фолд, колл, чек, бет та 
рейз. Ця панель активується лише тоді, коли настає черга користувача, і 
автоматично вимикається під час ходів інших гравців. Система також 
відображає поточні можливі варіанти ставок та дозволяє користувачеві обирати 
суму рейзу зручним повзунком або через введення числового значення. 
Інтерфейс підтримує графічні ефекти для візуалізації переміщення карт і 
фішок, що робить ігровий процес більш динамічним і реалістичним. 
Наприклад, при кожній роздачі карти плавно «розлітаються» від дилера до 
гравців, а фішки переміщуються до центру столу з відповідними звуковими 
ефектами. Це створює ефект присутності, який суттєво підвищує залучення 
користувача. 
У правій частині екрана може відображатися статистична панель, де 
користувач бачить інформацію про попередні ходи, шанси на перемогу, 
структуру поточного банку, а також свою власну статистику: кількість 
67 
ЧДТУ 252164.016ПЗ 
виграних рук, середній банк, агресивність тощо. Цей компонент може бути 
прихованим або розкриватися за потреби, щоб не перевантажувати екран під 
час активної гри. Інтерфейс передбачає можливість налаштування вигляду та 
теми оформлення. Користувач може обрати стиль оформлення столу, сорочку 
карт, мову інтерфейсу та інші візуальні параметри через окреме меню 
налаштувань. Всі зміни застосовуються миттєво, що забезпечує комфортну 
персоналізацію ігрового середовища. 
Особлива увага приділяється обробці виняткових ситуацій. У разі 
помилок, невалідних дій чи втрати підключення (якщо у майбутньому буде 
реалізовано онлайн-функціонал), система надає зрозумілі повідомлення, 
підказки або автоматичні варіанти дій. Наприклад, якщо користувач не встигає 
зробити ставку за відведений час, система може автоматично виконати «фолд» 
або «чек» залежно від контексту (рис. 3.2 – 3.4). 
 
 
Рисунок 3.2 - Інтерфейс гри в покер 
 
68 
ЧДТУ 252164.016ПЗ 
 
Рисунок 3.3 - Інтерфейс гри в покер 
 
 
Рисунок 3.4 - Інтерфейс гри в покер 
69 
ЧДТУ 252164.016ПЗ 
Для забезпечення цілісності взаємодії між графічним інтерфейсом 
користувача та логікою гри було реалізовано архітектурний шаблон MVC 
(Model-View-Controller), який дозволяє чітко відокремити презентаційний 
рівень від бізнес-логіки. У контексті цієї гри модель відповідає за зберігання 
ігрового стану, включаючи інформацію про гравців, карти, ставки та банк. 
Представлення (View) реалізує візуальні компоненти інтерфейсу, а контролер 
(Controller) забезпечує логіку взаємодії між діями користувача та відповідними 
змінами в моделі. 
Під час гри користувач взаємодіє виключно з елементами представлення, 
які, в свою чергу, делегують обробку подій відповідним методам у контролері. 
Наприклад, коли гравець натискає кнопку для ставки або фолду, ця дія 
передається до контролера, який аналізує її контекст, перевіряє відповідність 
правилам гри та ініціює відповідну зміну стану моделі. Модель після оновлення 
генерує подію про зміну стану, яка автоматично оновлює інтерфейс, 
забезпечуючи відображення нового розташування фішок, зміни активного 
гравця або відкриття нових спільних карт. 
Окрім безпосередньої інтерактивної частини, графічний інтерфейс 
реалізує допоміжні елементи навігації, такі як головне меню, меню 
налаштувань, вікно статистики, діалог підтвердження виходу з гри, спливаючі 
підказки та навчальні повідомлення. Усі ці елементи підтримуються єдиною 
системою стилізації, яка визначає кольорову гаму, шрифти, розміри елементів 
та анімації, що забезпечує візуальну цілісність додатку. 
Для відображення карт і фішок використовуються SVG-графіка та ефекти 
JavaFX, які дозволяють змінювати масштаби елементів, обертати, створювати 
візуальні переходи та накладати прозорість. Це дозволяє моделювати ситуації, 
коли карти «підкидаються» на стіл, або фішки поступово переходять у центр, 
зберігаючи при цьому продуктивність навіть на слабких пристроях. Ефективне 
використання таких можливостей сприяє підвищенню естетичної 
привабливості гри та її загального візуального рівня. Оскільки проєкт 
розрахований на офлайн-режим, розробники приділили значну увагу 
забезпеченню стабільності інтерфейсу при будь-якому сценарії поведінки 
70 
ЧДТУ 252164.016ПЗ 
користувача. Наприклад, якщо під час гри користувач переміщує вікно 
програми або тимчасово згортає його, при відновленні фокус автоматично 
повертається на активного гравця, а всі елементи інтерфейсу зберігають свою 
позицію та стан. Завдяки цьому досягається ефект безперервності гри, який 
сприяє комфортному зануренню в процес. 
3.1.4 Тестування програмного забезпечення 
Тестування програмного забезпечення гри в покер передбачає перевірку 
правильності роботи всіх функціональних модулів системи, а також оцінку її 
стабільності, надійності та відповідності очікуванням користувача. Основна 
увага зосереджена на перевірці логіки гри, взаємодії гравців з інтерфейсом, 
поведінки ботів на різних рівнях складності, коректності відображення 
графічного інтерфейсу, обробки виняткових ситуацій і збереження прогресу. 
Процес тестування розпочинається з модульного тестування, під час 
якого окремі компоненти системи перевіряються ізольовано один від одного. 
Наприклад, тестується робота класу Card, зокрема створення об'єктів карт, їх 
порівняння та відображення. Для класу Deck перевіряється правильність 
ініціалізації, наявність усіх 52 карт, уникнення дублікатів при роздачі та 
результат роботи методу shuffle(). Клас Game тестується на коректність 
ініціалізації нової гри, проведення раундів ставок, переходів між фазами гри, а 
також на правильність визначення переможця за результатами комбінацій. 
Особлива увага приділяється тестуванню ботів. Для кожного рівня складності 
перевіряється логіка прийняття рішень у різних ігрових ситуаціях. Наприклад, 
боти початкового рівня повинні грати консервативно, ухилятись від ставок при 
слабкій руці та не робити необґрунтованих підвищень. Боти середнього рівня 
мають враховувати позицію за столом і розмір банку, а боти експертного рівня 
повинні демонструвати гнучку поведінку, включаючи блеф та агресивну гру. 
Усі ці сценарії тестуються шляхом запуску численних ігор з відстеженням дій 
ботів, які потім порівнюються з очікуваними шаблонами. 
Далі проводиться інтеграційне тестування, яке дозволяє перевірити 
взаємодію між компонентами. Наприклад, тестується взаємозв'язок між 
класами Game, Player та Table, а також взаємодія між графічним інтерфейсом та 
71 
ЧДТУ 252164.016ПЗ 
бізнес-логікою. Під час цього етапу імітуються дії користувача, такі як 
натискання кнопок у JavaFX-інтерфейсі, вибір дій під час гри, перегляд 
статистики, запуск нової гри та завершення поточної. Перевіряється, чи 
змінюється відображення відповідно до внутрішнього стану гри та чи немає 
затримок або збоїв у оновленні вмісту екрану. 
У рамках системного тестування перевіряється повна функціональність 
програми в умовах, максимально наближених до реальних. Це включає запуск 
програми на різних операційних системах (Windows, Linux, macOS), з різними 
версіями JVM, у середовищах з обмеженими ресурсами, а також тестування 
реакції програми на нештатні ситуації, такі як раптове завершення роботи, 
спроба відкрити пошкоджений файл збереження чи відсутність доступу до 
файлової системи. Усі ці тести мають підтвердити стабільність та надійність 
програми (рис. 3.5 – 3.7). 
 
 
Рисунок 3.5 - Тестування початку гри 
72 
ЧДТУ 252164.016ПЗ 
 
Рисунок 3.6 - Тестування створення команди 
 
 
Рисунок 3.7 - Тестування гри 
 
Після цього проводиться тестування продуктивності, яке включає 
вимірювання часу відгуку інтерфейсу, швидкість прийняття рішень ботами, час 
завантаження гри та інші показники, що впливають на користувацький досвід. 
Програма має демонструвати плавну роботу навіть при максимально можливій 
кількості ботів, великому обсязі статистичних даних та використанні 
ресурсомістких візуальних елементів. Остаточним етапом є тестування з боку 
кінцевого користувача, яке передбачає проведення ігор реальними гравцями з 
метою виявлення помилок, що не були зафіксовані під час попередніх етапів. 
Користувачі надають зворотний зв’язок щодо зручності інтерфейсу, логіки гри, 
поведінки ботів та загального враження від використання. Ці відгуки 
враховуються під час подальшого вдосконалення програмного продукту. 
 
 
73 
ЧДТУ 252164.016ПЗ 
ВИСНОВОК ДО ТРЕТЬОГО РОЗДІЛУ 
У третьому розділі було реалізовано повноцінне програмне 
забезпечення для гри в покер (Техаський Холдем), яке поєднує складну ігрову 
логіку, графічний інтерфейс, штучний інтелект та систему збереження даних. 
Реалізація охопила всі етапи життєвого циклу створення ПЗ — від вибору 
технологічного стеку до тестування продукту. В якості основної мови 
програмування було використано Java завдяки її кросплатформності, 
стабільності та підтримці об’єктно-орієнтованого підходу.  
Графічний інтерфейс реалізовано засобами JavaFX, що забезпечило 
сучасний вигляд гри та динамічну візуалізацію подій. Візуальна частина 
застосунку створена з урахуванням принципів адаптивності та зручності 
використання, а логіка побудована згідно з архітектурою MVC.  
Було реалізовано три рівні ботів, кожен з яких використовує власну 
стратегію прийняття рішень, що забезпечує реалістичну поведінку суперників і 
адаптацію гри до рівня користувача.  
Створено модуль для обчислення сили комбінацій та визначення 
переможців відповідно до офіційних правил Техаського Холдему. Система 
серіалізації й використання вбудованої бази даних H2 забезпечили збереження 
ігрового прогресу, статистики та конфігурацій, що є критичним для підтримки 
безперервного користувацького досвіду навіть в офлайн-режимі.  
Загальна архітектура програмного забезпечення виявилася гнучкою, 
масштабованою та придатною для подальшого розвитку. Проведене 
багаторівневе тестування підтвердило стабільність, коректність та ефективність 
роботи програми на різних операційних системах. Таким чином, результати 
реалізації підтверджують доцільність обраного підходу та високий рівень 
технічної реалізації поставлених завдань. 
74 
ЧДТУ 252164.016ПЗ 
ВИСНОВКИ 
У результаті виконання дипломної роботи було розроблено повноцінне 
програмне забезпечення для гри в покер у режимі офлайн з використанням 
мови програмування Java та графічного середовища JavaFX. Систему створено 
з урахуванням сучасних вимог до функціональності, продуктивності, 
масштабованості та зручності використання, що дозволяє їй ефективно 
виконувати поставлені задачі в контексті настільного програмного продукту. 
На основі аналізу існуючих рішень, представлених на ринку, було виявлено їх 
основні недоліки, серед яких: обмеження функціоналу в офлайн-режимі, 
слабкий штучний інтелект ботів, відсутність гнучкого налаштування параметрів 
гри та агресивна монетизація. Ці фактори стали основою для формування вимог 
до нового програмного продукту, який мав поєднувати високу якість гри, 
відсутність залежності від мережевого з’єднання та адаптивність до рівня 
користувача. 
У межах роботи було здійснено детальне моделювання предметної 
області покеру, зокрема визначено основні об’єкти, їх атрибути та 
взаємозв’язки, що забезпечило створення гнучкої та масштабованої 
архітектури. Побудовано діаграми класів, прецедентів, послідовності, станів, а 
також реалізовано розділення програмного забезпечення на логічні компоненти 
за допомогою діаграми пакетів і компонентів. Особливу увагу було приділено 
реалізації штучного інтелекту для ботів трьох рівнів складності. Розроблені 
алгоритми прийняття рішень дозволяють симулювати різні стилі гри: від 
базових пасивних стратегій до експертного рівня з елементами психологічного 
аналізу, блефу та оцінки потенціалу комбінацій. Це значно підвищує 
реалістичність гри та забезпечує її навчальний і розважальний потенціал. 
Графічний інтерфейс реалізовано на основі бібліотеки JavaFX, що 
забезпечило створення інтуїтивно зрозумілого, естетично привабливого та 
функціонального середовища для користувача. Візуалізація ігрового процесу, 
можливість керування ставками, перегляд історії та статистики, а також 
налаштування параметрів гри сприяють глибшому зануренню в ігровий процес. 
75 
ЧДТУ 252164.016ПЗ 
Програмне забезпечення пройшло всі етапи тестування, включаючи модульне, 
інтеграційне, системне та користувацьке. Результати тестування підтвердили 
правильність реалованої логіки, стабільність роботи програми, швидкодію 
навіть на системах з обмеженими ресурсами, а також відповідність усім 
функціональним і нефункціональним вимогам, сформованим на початковому 
етапі проєктування. 
Розроблена система задовольняє актуальні потреби користувачів у 
якісному офлайн-покерному рішенні та має потенціал для подальшого 
розвитку. У майбутньому програму можна розширити шляхом додавання 
мультиплеєрного режиму, підтримки інших варіацій покеру, покращення 
інтерфейсу користувача, розширення аналітичних функцій та впровадження 
машинного навчання для самонавчання ботів. 
76 
ЧДТУ 252164.016ПЗ 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1 Туголукова Є. В. Методи навчання з підкріпленням для гри в покер : 
дис. … канд. техн. наук : 05.13.06 / Є. В. Туголукова. – 2020.  
2 Москаленко А. Є. Управління впровадженням елементів інноваційної 
гри в публічній сфері : монографія / А. Є. Москаленко. – 2022. 
3 Кучар О. М. Програмний модуль навчання гри в покер : дис. … канд. 
техн. наук : 05.13.06 / О. М. Кучар ; Західноукраїнський національний 
університет. – Тернопіль, 2024.  
4 Степанова О. С. Реалізація ділової гри з управління ІТ-проєктами / О. 
С. Степанова // Наукові праці. – 2022. – № 3. 
5 Тишко Н. І. Розробка інтерактивного середовища соціалізації мовою 
програмування JavaScript, фреймворк Meteor JS : магіст. дис. / Н. І. 
Тишко ; Тернопільський національний технічний університет імені 
Івана Пулюя. – Тернопіль, 2019.  
6 Сухарський В. О. Розробка Android-застосунку для управління 
складом з використанням мови програмування Java та бази даних SQL 
Server : магіст. дис. / В. О. Сухарський ; Тернопільський національний 
технічний університет імені Івана Пулюя. – Тернопіль, 2024. 
7   Кучар О. М. Програмний модуль навчання гри в покер : дис. … канд. 
техн. наук / О. М. Кучар. – Тернопіль : ЗУНУ, 2024. 
8 Фомін О. В. Скорингові моделі поведінки гравців для оцінки 
фінансових показників компанії / О. В. Фомін. – 2018. 
9 Кімак В. Вибір нефункціональних вимог при розробці програмного 
забезпечення // 2023 2nd International Conference on Innovative 
Solutions in Software Engineering (ICISSE). – 2023. 
10 Котяй Д. А. Програмне забезпечення для обміну повідомленнями / Д. 
А. Котяй. – 2024. 
11 Шевченко І. В., Кузнецова Ю. А. Проектування програмного 
забезпечення. Основи побудови UML-діаграм. – 2019. 
77 
ЧДТУ 252164.016ПЗ 
12 Бзот С. В. Розробка компонентів системи підтримки прийняття рішень 
у сфері закупівлі озброєнь та алгоритмів її функціонування / С. В. 
Бзот. – 2024. 
13 Костик П. В. Методи і засоби проектування програмних інтерфейсів 
комп’ютерних систем : магістерська робота / П. В. Костик. – 2018. 
14 Аніловська Г. Я., Лебединський Д. М. Інструменти бізнес-аналізу 
діяльності підприємств // Академічні візії. – 2024. – № 33. 
15 Кухар О. О. Telegram-bot для підтримки комунікації з клієнтами у 
галузі краси / О. О. Кухар. – 2024. 
16 Сирота В. В. Моделювання та реалізація скінченного автомату / В. В. 
Сирота. – 2023. 
78 
ДОДАТОК А 
ЗАТВЕРДЖЕНО: 
Зав. кафедрою ПЗАС, професор 
_________________ Голуб С.В. 
„____” ______________ 2025 р. 
Розробка програмного забезпечення для гри в Покер 
Специфікація 
482. ЧДТУ 252155.008
Листів 1 
Розробник ________________ Олійніченко Я.П. 
Керівник ________________ Півень О.Б. 
Черкаси 2025 
 
482. ЧДТУ 252155.008
Позначення Найменування Примітки 
Документація 
482.ЧДТУ. 252164 12 01 Текст програми 
482.ЧДТУ. 252164 34 01 Інструкція користувачеві 
482.ЧДТУ. 252164 90 01 Графічні матеріали 
80 
ДОДАТОК Б 
Розробка програмного забезпечення гри в Покер 
Текст програми 
482. ЧДТУ 252155 12 01
Листів 14 
Розробник ________________ Олійніченко Я.П. 
Черкаси 2025 
 
482. ЧДТУ 252155 12 01 
У зв’язку зі значним обсягом програмного коду, у даній роботі представлено 
лише основні фрагменти, що ілюструють структуру та логіку реалізації. Повний 
код можна переглянути у репозиторії проєкту або отримати на запит. 
package model; 
 
public class Card { 
    public enum Suit {HEARTS, DIAMONDS, CLUBS, SPADES} 
    public enum Value { 
        TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, 
        NINE, TEN, JACK, QUEEN, KING, ACE 
    } 
 
    private final Suit suit; 
    private final Value value; 
 
    public Card(Suit suit, Value value) { 
        this.suit = suit; 
        this.value = value; 
    } 
 
    public Suit getSuit() { return suit; } 
    public Value getValue() { return value; } 
 
    @Override 
    public String toString() { 
        return value + " of " + suit; 
    } 
} 
package model; 
 
82 
482. ЧДТУ 252155 12 01 
import java.util.*; 
 
public class Deck { 
    private final List<Card> cards = new ArrayList<>(); 
 
    public Deck() { 
        for (Card.Suit suit : Card.Suit.values()) { 
            for (Card.Value value : Card.Value.values()) { 
                cards.add(new Card(suit, value)); 
            } 
        } 
        shuffle(); 
    } 
 
    public void shuffle() { 
        Collections.shuffle(cards); 
    } 
 
    public Card dealCard() { 
        if (!cards.isEmpty()) { 
            return cards.remove(0); 
        } 
        throw new IllegalStateException("No cards left in deck!"); 
    } 
} 
package model; 
 
import java.util.*; 
 
public abstract class Player { 
83 
482. ЧДТУ 252155 12 01 
    protected String name; 
    protected List<Card> hand = new ArrayList<>(); 
    protected int chips; 
 
    public Player(String name, int chips) { 
        this.name = name; 
        this.chips = chips; 
    } 
 
    public String getName() { return name; } 
    public List<Card> getHand() { return hand; } 
    public int getChips() { return chips; } 
 
    public void addCard(Card card) { 
        hand.add(card); 
    } 
 
    public void bet(int amount) { 
        chips -= amount; 
    } 
 
    public abstract String decideAction(); // For bot or user input 
} 
package model; 
 
public class BotPlayer extends Player { 
    public enum Level {BEGINNER, INTERMEDIATE, EXPERT} 
    private final Level level; 
 
    public BotPlayer(String name, int chips, Level level) { 
84 
482. ЧДТУ 252155 12 01 
        super(name, chips); 
        this.level = level; 
    } 
 
    @Override 
    public String decideAction() { 
        switch (level) { 
            case BEGINNER: 
                return "CALL"; 
            case INTERMEDIATE: 
                return Math.random() > 0.5 ? "RAISE" : "CALL"; 
            case EXPERT: 
                return Math.random() > 0.8 ? "RAISE" : (Math.random() > 0.4 ? 
"CALL" : "FOLD"); 
            default: 
                return "FOLD"; 
        } 
    } 
} 
package model; 
 
import java.util.*; 
 
public class Game { 
    private final List<Player> players; 
    private final Deck deck; 
    private final List<Card> communityCards; 
 
    public Game(List<Player> players) { 
        this.players = players; 
85 
482. ЧДТУ 252155 12 01 
        this.deck = new Deck(); 
        this.communityCards = new ArrayList<>(); 
    } 
 
    public void startGame() { 
        deck.shuffle(); 
        for (Player player : players) { 
            player.getHand().clear(); 
            player.addCard(deck.dealCard()); 
            player.addCard(deck.dealCard()); 
        } 
        communityCards.clear(); 
    } 
 
    public void flop() { 
        communityCards.add(deck.dealCard()); 
        communityCards.add(deck.dealCard()); 
        communityCards.add(deck.dealCard()); 
    } 
 
    public void turn() { 
        communityCards.add(deck.dealCard()); 
    } 
 
    public void river() { 
        communityCards.add(deck.dealCard()); 
    } 
 
    public List<Card> getCommunityCards() { 
        return communityCards; 
86 
482. ЧДТУ 252155 12 01 
    } 
} 
package ui; 
 
import javafx.application.Application; 
import javafx.geometry.Insets; 
import javafx.scene.Scene; 
import javafx.scene.control.*; 
import javafx.scene.layout.*; 
import javafx.scene.text.Font; 
import javafx.stage.Stage; 
import model.*; 
 
import java.util.ArrayList; 
import java.util.List; 
 
public class PokerApp extends Application { 
 
    private Game game; 
    private VBox communityCardsBox; 
    private VBox playerInfoBox; 
    private TextArea gameLog; 
 
    @Override 
    public void start(Stage primaryStage) { 
        primaryStage.setTitle("JavaFX Poker Game"); 
 
        // Створення гравців 
        List<Player> players = new ArrayList<>(); 
        players.add(new BotPlayer("Bot 1", 1000, BotPlayer.Level.BEGINNER)); 
87 
482. ЧДТУ 252155 12 01 
        players.add(new BotPlayer("Bot 2", 1000, 
BotPlayer.Level.INTERMEDIATE)); 
        players.add(new BotPlayer("Bot 3", 1000, BotPlayer.Level.EXPERT)); 
 
        game = new Game(players); 
 
        BorderPane root = new BorderPane(); 
 
        // Центр - спільні карти 
        communityCardsBox = new VBox(10); 
        communityCardsBox.setPadding(new Insets(10)); 
        Label cardsLabel = new Label("Community Cards:"); 
        cardsLabel.setFont(new Font(16)); 
        communityCardsBox.getChildren().add(cardsLabel); 
        root.setCenter(communityCardsBox); 
 
        // Ліва частина - інформація про гравців 
        playerInfoBox = new VBox(10); 
        playerInfoBox.setPadding(new Insets(10)); 
        root.setLeft(playerInfoBox); 
 
        // Нижня частина - лог гри та кнопки керування 
        VBox bottomBox = new VBox(10); 
        gameLog = new TextArea(); 
        gameLog.setEditable(false); 
        gameLog.setPrefHeight(150); 
 
        HBox buttonBox = new HBox(10); 
        buttonBox.setPadding(new Insets(10)); 
        Button startBtn = new Button("Start Game"); 
88 
482. ЧДТУ 252155 12 01 
        startBtn.setOnAction(e -> startNewGame()); 
        Button flopBtn = new Button("Flop"); 
        flopBtn.setOnAction(e -> drawFlop()); 
        Button turnBtn = new Button("Turn"); 
        turnBtn.setOnAction(e -> drawTurn()); 
        Button riverBtn = new Button("River"); 
        riverBtn.setOnAction(e -> drawRiver()); 
 
        buttonBox.getChildren().addAll(startBtn, flopBtn, turnBtn, riverBtn); 
        bottomBox.getChildren().addAll(buttonBox, gameLog); 
        root.setBottom(bottomBox); 
 
        Scene scene = new Scene(root, 800, 600); 
        primaryStage.setScene(scene); 
        primaryStage.show(); 
    } 
 
    private void startNewGame() { 
        game.startGame(); 
        communityCardsBox.getChildren().clear(); 
        communityCardsBox.getChildren().add(new Label("Community Cards:")); 
        playerInfoBox.getChildren().clear(); 
 
        for (Player player : game.getPlayers()) { 
            String hand = player.getHand().toString(); 
            Label info = new Label(player.getName() + " (" + player.getChips() + 
")\nHand: " + hand); 
            playerInfoBox.getChildren().add(info); 
        } 
 
89 
482. ЧДТУ 252155 12 01 
        gameLog.appendText("Game started. Cards dealt.\n"); 
    } 
 
    private void drawFlop() { 
        game.flop(); 
        updateCommunityCards("Flop drawn\n"); 
    } 
 
    private void drawTurn() { 
        game.turn(); 
        updateCommunityCards("Turn drawn\n"); 
    } 
 
    private void drawRiver() { 
        game.river(); 
        updateCommunityCards("River drawn\n"); 
    } 
 
    private void updateCommunityCards(String log) { 
        communityCardsBox.getChildren().clear(); 
        Label cardsLabel = new Label("Community Cards:"); 
        cardsLabel.setFont(new Font(16)); 
        communityCardsBox.getChildren().add(cardsLabel); 
        Label cards = new Label(game.getCommunityCards().toString()); 
        communityCardsBox.getChildren().add(cards); 
        gameLog.appendText(log); 
    } 
 
    public static void main(String[] args) { 
        launch(args); 
90 
482. ЧДТУ 252155 12 01 
    } 
} 
 
package ui; 
 
import javafx.application.Application; 
import javafx.geometry.Insets; 
import javafx.scene.Scene; 
import javafx.scene.control.*; 
import javafx.scene.layout.*; 
import javafx.scene.text.Font; 
import javafx.stage.Stage; 
import model.*; 
 
import java.util.ArrayList; 
import java.util.List; 
 
public class PokerApp extends Application { 
 
    private Game game; 
    private VBox communityCardsBox; 
    private VBox playerInfoBox; 
    private TextArea gameLog; 
 
    @Override 
    public void start(Stage primaryStage) { 
        primaryStage.setTitle("JavaFX Poker Game"); 
 
        // Створення гравців 
        List<Player> players = new ArrayList<>(); 
91 
482. ЧДТУ 252155 12 01 
        players.add(new BotPlayer("Bot 1", 1000, BotPlayer.Level.BEGINNER)); 
        players.add(new BotPlayer("Bot 2", 1000, 
BotPlayer.Level.INTERMEDIATE)); 
        players.add(new BotPlayer("Bot 3", 1000, BotPlayer.Level.EXPERT)); 
 
        game = new Game(players); 
 
        BorderPane root = new BorderPane(); 
 
        // Центр - спільні карти 
        communityCardsBox = new VBox(10); 
        communityCardsBox.setPadding(new Insets(10)); 
        Label cardsLabel = new Label("Community Cards:"); 
        cardsLabel.setFont(new Font(16)); 
        communityCardsBox.getChildren().add(cardsLabel); 
        root.setCenter(communityCardsBox); 
 
        // Ліва частина - інформація про гравців 
        playerInfoBox = new VBox(10); 
        playerInfoBox.setPadding(new Insets(10)); 
        root.setLeft(playerInfoBox); 
 
        // Нижня частина - лог гри та кнопки керування 
        VBox bottomBox = new VBox(10); 
        gameLog = new TextArea(); 
        gameLog.setEditable(false); 
        gameLog.setPrefHeight(150); 
 
        HBox buttonBox = new HBox(10); 
        buttonBox.setPadding(new Insets(10)); 
92 
482. ЧДТУ 252155 12 01 
        Button startBtn = new Button("Start Game"); 
        startBtn.setOnAction(e -> startNewGame()); 
        Button flopBtn = new Button("Flop"); 
        flopBtn.setOnAction(e -> drawFlop()); 
        Button turnBtn = new Button("Turn"); 
        turnBtn.setOnAction(e -> drawTurn()); 
        Button riverBtn = new Button("River"); 
        riverBtn.setOnAction(e -> drawRiver()); 
 
        buttonBox.getChildren().addAll(startBtn, flopBtn, turnBtn, riverBtn); 
        bottomBox.getChildren().addAll(buttonBox, gameLog); 
        root.setBottom(bottomBox); 
 
        Scene scene = new Scene(root, 800, 600); 
        primaryStage.setScene(scene); 
        primaryStage.show(); 
    } 
 
    private void startNewGame() { 
        game.startGame(); 
        communityCardsBox.getChildren().clear(); 
        communityCardsBox.getChildren().add(new Label("Community Cards:")); 
        playerInfoBox.getChildren().clear(); 
 
        for (Player player : game.getPlayers()) { 
            String hand = player.getHand().toString(); 
            Label info = new Label(player.getName() + " (" + player.getChips() + 
")\nHand: " + hand); 
            playerInfoBox.getChildren().add(info); 
        } 
93 
482. ЧДТУ 252155 12 01 
 
        gameLog.appendText("Game started. Cards dealt.\n"); 
    } 
 
    private void drawFlop() { 
        game.flop(); 
        updateCommunityCards("Flop drawn\n"); 
    } 
 
    private void drawTurn() { 
        game.turn(); 
        updateCommunityCards("Turn drawn\n"); 
    } 
 
    private void drawRiver() { 
        game.river(); 
        updateCommunityCards("River drawn\n"); 
    } 
 
    private void updateCommunityCards(String log) { 
        communityCardsBox.getChildren().clear(); 
        Label cardsLabel = new Label("Community Cards:"); 
        cardsLabel.setFont(new Font(16)); 
        communityCardsBox.getChildren().add(cardsLabel); 
        Label cards = new Label(game.getCommunityCards().toString()); 
        communityCardsBox.getChildren().add(cards); 
        gameLog.appendText(log); 
    } 
 
    public static void main(String[] args) { 
94 
482. ЧДТУ 252155 12 01 
        launch(args); 
    } 
} 
 
 
95 
ДОДАТОК В 
Програмне забезпечення розробки гри в покер 
Інструкція користувачеві 
482. ЧДТУ 252164 34 01
Листів 2 
Розробник ________________  Олійніченко Я.П. 
Черкаси 2024 
 
482. ЧДТУ 252164 34 01
Керівництво користувача до гри в покер 
Цей застосунок призначений для гри в покер за правилами Техаського 
Холдему проти комп’ютерних опонентів (ботів) з різними рівнями складності. 
Програма дозволяє користувачу не лише розважатися, а й вдосконалювати свої 
навички, аналізуючи хід гри та поведінку суперників. 
Реєстрація користувача та запуск гри 
1. Запуск застосунку:
o Відкрийте програму, запустивши відповідний виконуваний файл (.jar).
o У головному меню оберіть опцію «Почати гру» або «Реєстрація
користувача».
2. Створення профілю:
o Введіть своє ім’я (або нікнейм);
o Оберіть аватар;
o Оберіть мову інтерфейсу (українська або англійська);
o Задайте рівень складності ботів (легкий, середній або важкий);
o Натисніть «Створити профіль».
3. Налаштування нової гри:
o Вкажіть кількість гравців за столом (від 2 до 6);
o Установіть стартову кількість фішок;
o Оберіть режим гри (звичайна гра або турнір);
o Натисніть «Почати».
Основні функції гри 
1. Ігровий інтерфейс:
o Центральна частина – покерний стіл;
o Знизу – ваша панель дій (Fold, Check, Call, Bet, Raise);
o Ліворуч – ваша статистика;
o Справа – повідомлення про стан гри, дії інших гравців.
2. Хід гри:
o Гра проходить у кілька раундів: префлоп, флоп, терн, рівер;
o У кожному раунді ви маєте змогу зробити дію;
o Боти автоматично приймають рішення відповідно до стратегії.
3. Кінець гри:
o Переможцем оголошується гравець із найкращою комбінацією карт
або останній, хто залишився в грі;
o Після завершення партії ви можете переглянути детальну статистику.
Додаткові можливості 
 Збереження прогресу:
o Гра автоматично зберігає хід гри після кожної роздачі;
97 
482. ЧДТУ 252164 34 01 
o Ви можете в будь-який момент вийти та пізніше продовжити з того 
самого місця. 
 Історія та аналітика: 
o У розділі «Статистика» доступна інформація про: 
 кількість виграних роздач; 
 середній банк; 
 найчастіше використовувані дії; 
 частка агресивної/пасивної гри. 
 
 Налаштування: 
o Мова інтерфейсу; 
o Тема оформлення (світла або темна); 
o Зміна рівня складності ботів; 
o Звукові ефекти. 
Поведінка ботів 
 Легкий рівень – грають обережно, не роблять агресивних ставок. 
 Середній рівень – аналізують позицію, розмір банку, оцінюють 
ймовірності. 
 Високий рівень – застосовують блеф, змінюють стиль гри, враховують 
історію дій. 
Підтримка та допомога 
 Для ознайомлення з правилами покеру натисніть кнопку «Довідка» в 
головному меню. 
 Усі повідомлення та підказки супроводжуються коротким поясненням. 
 Якщо сталася помилка або програма завершила роботу, останній стан буде 
збережено. 
 
98