Програмне забезпечення розвиваючої гри «Таблиця множення масивів в двійковій системі числення» для мобільного додатку на основі Unity

Петренко, Сергій Сергійович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9145
Full metadata record
DC Field	Value	Language
dc.contributor.advisor	Півень, Олександр Борисович	-
dc.contributor.author	Петренко, Сергій Сергійович	-
dc.date.accessioned	2026-03-26T18:34:33Z	-
dc.date.available	2026-03-26T18:34:33Z	-
dc.date.issued	2023-06-17	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/9145	-
dc.description.abstract	АНОТАЦІЯ Дипломна робота на тему: " Розробка інтерактивно-розвиваючої rри для дітей за допомогою технології Unity' '. Робота присвячена створенню відеогри для дітей, щоб покращити та зробити uікавішим їх навчання. В холі дослідження було розроблено систему яка є продуктивною та надійною.	uk_UA
dc.description.abstract	ANNOTATION Thesis on the topic: "Development of interactive and developmental games for children using Unity technology." The work is dedicated to creating а video game for children to improve and make their learning more interesting. The study developed а system that is productive and reliable.	uk_UA
dc.language.iso	uk	uk_UA
dc.title	Програмне забезпечення розвиваючої гри «Таблиця множення масивів в двійковій системі числення» для мобільного додатку на основі Unity	uk_UA
dc.type	Bachelor Thesis	uk_UA
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Files in This Item:
File	Description	Size	Format
Кваліфікаційна робота бакалавра Петренко Сергій Сергійович.pdf Restricted Access		13.55 MB	Adobe PDF	View/Open Request a copy
Show simple item record
Extracted text
• 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УІ-ПВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
ПОЯСІ-ПОВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«бакалавра» 
освітній рівень 
на тему: Програмне забезпечення розвиваючої гри «Таблиця множення 
масивів в двійковій системі числення» для мобільного додатку на 
основі Unity 
Виконав: студент 4 курсу, групи ПЗ-1904 
Спеціальності 
121 «Інженерія програмного забезпечення» 
(шифр і назва напряму підготовки) 
Студент Петренко С.С. 
(прізвище та і11іціали) 
Керівник Півень О. Б. 
(прізвище та ініціали) 
Рецензент 
(прізв11ще та ініціали) 
Черкаси 2023 
Форма № У-9.ОІ 
Додаток 2 
Черкаський державний тех11ологічний у11іверситет 
Факультет інформаційних технологій і систем 
(noa11a 11азаа·.,---------------
Кафедра~п=:~ам=н~о~г~о~з~а~бсез::.!!.!п~еч~е~н~н~я~а~в~т~о~м~а~т~и~зо*в~а~н~и~х~си~с~т~е~м.~-------
(nоана назеа 
Напрям підготовки ІНЖЕНЕРІЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
(код. нiuaa) ---------
Спеціальність 121 «ІНЖЕНЕРІЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ» 
(код. 11азаа,---------
Зав. кафедрз ~ 
.. ,,,t,,,f( " ___2 ~. 
ЗАВДАННЯ 
на дипломний проект (роботу) освітньо-кваліфікацій11ого рівня 
" Бакалавр " 
(1111311 р18ІUІ) 
студенту Петренко С.С. 
(nр1за11щс, 1м'•• 110 батько&І) 
І .Тема проекту (роботи) Програмне забезпечення розвиваючої гри «Таблиця 
множення масивів в двійковій системі числення» для мобільного додатку на 
основі Unity 
затверджена наказом по університету від "24"02 2023р. №43/04 
2. Термін здачі студентом закінченого проекту (роботи) "08" 06 2023 р. 
3. Вихідні дані до проекту (роботи)~-------------------
ОПЕРАШЙНА CИCTEMA-MICROSOFТ WrNDOWS 7/10. 
(6U3начаються кілr,кіс11і або (та) якісні пока111и1щ яким пови11ен 6ідповІдати об ·скт проектуоа1111я 
наукового досліджет,я) 
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити) 
1. Опис напряму дослідження _______________________  
2.Аналіз існуючих рішень __________________________  
З. Аналіз середовища розробки. ____________ _ __________  
4.Оnис розробки rри_ ________ _____________ ___  
5.Висновки. ________________________________  
б.Додатки ______________________________  
5. Перелік графічного матеріалу 
Рисунок Г.1 - Головна сторінка. 
Рисунок Г.2 -Задачі дослідження. 
Рисунок Г.3 - Середовище розробки. 
Рисунок Г.4 - Існуючі програмні аналоги. 
Рисунок Г.5 - Опнс системи. 
6. Дата видачі завдан-юr _____________________  
Керівник /Z:frrш_ и., 
Завданна ориІнав до виконанна ~ 
(......-) 
КалеидарниІ план 
ізвище, ініціали) 
№ Назва етапів випускної маrістерської Строк виконання етапів Примі11 
з/п тн ти 
Постановка задачj ВиконаJ 
2 Підготовка завдання 
з Погодження завдання ВиконаJ 
4 Затве джеННJІ завданНJІ ВиконаJ 
Основна ста Викона~ 
Викона~ 
2 Викона~ 
3 Викона~ 
Вибір кінцевого варіанту проектного 
4 Викона~ 
5 О млення п Виконw 
Заключна стадія Виконw 
УзгоджеиWІ прийнятих проектних рішень з 
ке івником ВиконаJ 
ОформленНJІ пояснювальної записки 
2 . ї ВиконаJ 
3 ти 
4 з 
з.з Виконм 
з ВиконаF. 
ідент-дипломник 
~ v..O с . с , 
(N.ІІUІt) 
Керівник проекту 
,(Qt.~ ~j ,," 
/ n ( IIUll1llt) 
АНОТАЦІЯ 
Дипломна робота на тему: "Розробка інтерактивно-розвиваючої rри для 
дітей за допомогою технології Unity' '. 
Робота присвячена створенню відеогри для дітей, щоб покращити та 
зробити uікавішим їх навчання. 
В холі дослідження було розроблено систему яка є продуктивною та 
надійною. 
ANNOTATION 
Thesis on the topic: "Development of interactive and developmental games for 
children using Unity technology." 
The work is dedicated to creating а video game for children to improve and 
make their learning more interesting. 
The study developed а system that is productive and reliable. 
- --- -.. -- - -
31\fІСТ 
ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ .................................. 8 
ВСТУП ......................................................................................................................... 9 
1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ'ЯЗАННЯ ПОСТАВЛЕНИХ 
ЗАВДАНЬ .................................................................................................................. 14 
1.1 Оовt Іt&)'ЮЧВХ 1'ІtтодІв ва заtобів ввкорвrтаввх орв розробцІ ... ..... ... 14 
1.2 Ав1t.11Із tсвуючвх ава"1оrІв проrра1'1■ .......................................................... 19 
в■свовок до розділ.у  1 .............................................. ................................................ 25 
2 ВПРОВАдЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ШФОРМАЦІЙНИХ СИСТЕМ ............................................................................. 26 
2.1 Модt.11юв1tвв11 орf'дМtтвоУ об.11tсті ......... .... .................... ....... ....... ..... .......... 26 
2.1.1 Предметна область моделювання. Модель предметної області. J 
Словннк предметної області ..................................................... ..................... 2б  
2.1.2 Елеменn1 моделювання пред~1етвої області ............... ........................2 9 
2.1 .3 Робоча область моделювання ............. ...... ... ........... ...... ............... .. .......3 1 І 
2.2 Фор1'1ув1tвв11 та ава.111 ••~•or ...................................................................... 32 
2.2.1 Формування в11моr до проrрамноrо забезпечення. Первпнні і 
детальні ВІІМОПІ. В1~моп1 замовнпка і розробнІІка. Функuіональні та 
нефункціональні в111'1оп1 ................................................................................. 3 2 
2.2.2 Формування в11моr за допомогою діаrра:м11 преuедентів ................... 38 
2.3 Проектував ва лоrІчвоУ структур в ороrрамвоrо комолtксу ............... .4 l 
2.3.1 Дiarpa1'm класів .............................................................................. .........4 1 
2.3.2 Дiarpa1"UI пакетів ................................................. ...................... .. .......... .. 46 
2.4 АрхІтектурве проектував в я ............................................................ ............ 48 
2.4.1 Діаrра1'1а коl\tпоиентів ........................................................... ................. 48 
2.4.2 Розгортання програмної спстемu на апаратних засобах. Діаrар:ма 
розrортання ...................................................................................................... 50 
ЧДТУ. 231920 .005 ПЗ 
Nt доІ;)-м. Пі.Іш, Даn 
п~ос.с. ,..; !?_' ,,,, Проrр:ш.иезабезаечеЯВІІро.звиваючоrrри ....,.Лвt,____.,І_Лв_а_,.~Лв-сnа· _~ 
' І Півеш. о.ь. ~ ~ <,Таблнци :-,tяож.е:вп ~,асоів в .nійковій І І І 
л сясте:-,tі чясдеяю1» ЗЛJІ ~обільяоrо .10.1атr;у ФІТТС. кафе;жра ПЗАС. 
..,Н.,..__......,Пів·-=....,о,..,Б~._rv,,.~.,,,,..- ,++--1 ва основі~ ПЗ-1904 
І l(OBtp. еяь · · мп " ' (ПО2СЯЮ11а1п,яазшвСІ(а) 
Зmai;z Г0;1)·0С.В. '7 d W ~ 
~ 
<..___.,,,,' 
2.~ Модt.11юв•ввя повtдІвк■ СІІСТf~t■ .............................................................. 63 
2.5.lДiarpal\ta діяльвості ................................................................................. 52 
2.5.2Діаrрама послідовності ........................................................................... 56 
2.5.ЗДiarpal\ta комунікаuії ............................................................................... 59 
2.5.4Діаrрама скінченного автомату .. ................................... ........ ................ 61 
3 РОЗРОБКА ТА ТЕСТУВАІІНЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ... .. 63 
3.1 Розробка проrра11воrо комплексу. .... .................................. ...................... 63 
3.1 .1 Обrрунтуван.ня ВІІбору засобів реалізації. ........................................... 63 
3.1.2 Оп11с структурної (функціональної) схемІІ .......................................... 64 
3.1.3 Оп11с лоrічиоr CXel\tJI ...............................................................................6 6 
3.1.4 Розробка базrr данпх ............................................................................... 67 
3.1.5 Розробка іитерфеіісу корпстувача ........................................................ 67 
3.1.6 О ппс розробкп проrрамн11х компонентів ..................................... •·· •. .. 71 
3.2 TeCТ)'BRBBtl свстемв ....................................................................................... 73 
3.2. 1 Модульне тестування ............................................................................. 73 
3.2.2 Інrеrраціfіне тестування ........................................................................ 74 
3.2.3 СистеІ\tВе тестування ............................................................................. 75 
3.2.4 ПрmЇl\tальне тестування ........... .............................................................. 76 
В■свовкв до 3 розділу ............................................................................................. 78 
І ВИСНОВОК ..............................................................................•. .• . ...................... •• • •7 9 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .......................................................... 81 
ДДООМЩ Т ТООКК  АБ  ........................................................................ ::·::::..:. .......................................................  8835  
ДОДАТОК В .......................................................................... :. ................................. 91 
ДОІ 71' -'ТОК Г ......................... ................................................................. .................. 97 
~ ............................. ······················· .. .. ........ ..... ... . . 
ЧДТУ. 231920.005m 
11м....;,: С r-.r - ПроrрЮJне забезпе'Іеяяs роsаоаючої rрв Лпт І Лист І Ластів 
Іt;~~~-і1JПteПtpіCRвt~е;n;, Jо.~.oь~..C  t~-~УІ~"~ =~t==~ ;-·-'-- cв«cТtаe)бtJiІ J'ІШЯЖС )JJІеИвОвжяе»І ЗD.1UJ І) :t1а1осбиів.1іьвв •о .rоu iзhоoзаaтiай: у µІФ~ІІ.n.с.., 1к,аІф_е~др.а. .П1З•А~С~.~ "1 
h};і- t:о-в-тр-. -І-П~ів-е-::аь- о:.:.ь:. -lf,-,iri~~-"1 ва основі~ ПЗ-1904 
V/P!':_ / (ПОJІСИЮ8аІ!ЬІІ2 3ШИСU) 
~ Го11убС.В. / / :,ш~ 
ЧДТУ .231920.005 ПЗ 
ПЕРЕЛІК СКОРОЧЕНЬ т А УМОВНИХ ПОЗНАЧЕНЬ 
сУ система управління 
оУ · об'єкт управління 
слУ система автоматичного уnравлі1111я 
лСУ автоматизовані системи управління 
гг Інформаційні технології 
тз · Технічне завдання 
fE Front-eпd 
ВЕ · Back-end 
QЛ Quality Assurance 
СУБд. система упраш1іння базами даних 
UML (англ. Unified Modeling Language)- уніфікована мова 
моделювання 
6 
ЧДТУ .231920.005 ПЗ 
ВСТУП 
Актуаль11ість тем 11. У наш час неможливо уявити повсякденне життя, де 
постійно переливається щодня інформація. Тому використовуються сучасні 
мут,тимедіа засоби 1щя задоволення цих потреб: телебачення, Інтернет тощо. 
Комбінування різ11их форм представлення інформації на носії це 
муш,тимедія. Мультимедія класифікується як лінійна і нелінійна. 
Паралеллю лінійного способу є кіно. Людина, переглядаючи дане кіно, 
11іяк не впливає на зміст цього документу. Нелінійний спосіб, дозволяє людині 
приймати участь у подані інформації, взаємодіючи із засобом відображення 
даних мультимсді·а. Участь людини в п·одібному процес~ називається 
інтерактивністю. Даний спосіб взаємодії комп'тера і людини найбільш повно 
представлений у відеоіграх. 
Аналогом лінійного способу подання може бути юно. Людина, що 
переглядає да11ий · документ жодним чином не може вплинути на його зміст. 
Нелінійний спосіб nода1-шя інформанії дозволяє людині брати участь у поданні 
інформації, взаємодіючи якимось чином 1з засобом відображення 
мультимедійних даних. Участь л1одини в даному процесі також називається 
«інтерактивністю». Такий спосіб взаємодії людини й комп'ютера найбільш повно 
представлений у категоріях комп'ютерних відео ігор. 
Вілео гра - це електронна ·гра, в якій плеєр використовує інтерфейс для 
отримання зворотного зв'язку щодо відеообладнання. Електронні пристрої, які 
використовуються для гри, назившоться ігровими платформами. Наприклад, до 
таких платформ належать персональні комп'ютери та відеоігри. Пристрій 
введення, який використовується для управління грою, називається ігровим 
контролером. Це може бути, наприклад, джойстик, клавіатура та миша, геймпад 
або сенсорний екран. 
Комп'ютерні відеоігри за останні роки отримали небувалу популярність і 
зайняли почесне місце на ринку розваг і дозвілля. В результаті процвітає 
індустрія комп'ютерних ігор. 
7 
ЧДТУ.231920.005 ПЗ 
Для задоволення потреб розробників було створення величезної кількості 
інструментів та розробка нових. Спільною метою всіх інструментів є сприяння 
та вдосконалення розвитку, використання передових технологій обробки 
графіки, фізики, надання кросплатформних проектів [І]. 
Мстою роботи Метою даної роботи розробка програмного забезпечення 
вивчення таблиці множення.Для досягнення поставленої мети необхідно 
І 
вирішити наступні завда1шя: 
Створити головне меню, яке буде простим та інтуїтивно зрозумілим. 
Воно включатиме 11 себе такі кнопки: 
нова гра; 
налаштування; 
вихід. 
2 Створити мінімум 5 рівнів з різними прикладами. Рівні повинні мати 
наступ11і елементи: 
блоки на яких знаходяться ·відповіді; 
блоки з запитаннями; 
rшатформа для руху; 
задній фон; 
музичний су11ровід. 
З Зробити анімацію для наступних дій: 
руху героя; 
стрибку героя; 
переходу між рівнями . 
Об'сктом розробки даної дипломної роботи є процес навчання дитини 
через використання програмного забезпечення вивчення таблиці множення. 
Граючи в таку гру, дитина стимулює всі свої органи чуття і вчиться їх 
коорди1-1увати. Крім того, що дитина слідкує за тим, що відбувається на екрані за 
допомогою джойстика або клавіатури комп'ютера, дитина також відчуває 
8 
ЧДТУ .231920.005 ПЗ 
тактиль111 в 1дчуn-я - вона повинна узгоджувати рухи рук з п1м 1 що відбуваЄ'гься 
,,а екра НІ . 
Використання цього програмного забезпечення може бути корисним 
засобом 1-1авчання завдяки тому, що в порівнянні з іншими методами навчання 
воно має перевагу в тому, що воно базуються на структурі розповіді, яку легше 
запам'ятати, ніж суху інформацію. 
Ос11ов11а увага у даній роботі спрямовусться на розробку програмного 
забезпечення, що дозволить дитині ефективно вивчити таблицю множення. 
У даній роботі методи розробки включають інструментальні засоби для 
розробки ігор.які можна поділити на З rруппи: 
1 
І Фреймворк - програмна платформа, яка визначає структуру програмної 
системи; програмне забезпечення, що полегшує розробку і об'єднання різних 
1<ом1юнс11т1в великого r1роrрамного проекту. Фреймворк відрізняється від 
поняття бібліотеки тим, що бі.бліотека може бути використана в програмному 
продукті просто як набір підпрограм близькою функціональності, не впливаю .. ,и 
на архітектуру програмного продукту і не накладаючи на неї ніяких обмежень. 
У той чзс як фрсймворк диктує правила побудови архітектури додатку, задаючи 
на початковому етапі розробки поведінка за умовчанням, каркас, який потрібно 
, буде розширювати і змінювати відповідно до зазначених вимог. 
2 Ігровий рушій - центральний програмний компонент комп'ютерних та 
uідсоігор або інших інтерактивних додатків з графікою, оброблюваної в 
реальному часі. Він забез11ечус основні технології, спрощує розробку і •1асто дає 
грі можливість запускатися на декjлькох платформах, таких як ігрові консолі та 
настільні операційні системи, наприклад, GNU / Linux, Мас OS Х і Microsoft 
Window.s. Основну функціональність зазвичай забезпечує ігровий движок, що 
nключає движок рендеринга ("визуализатор"), фізичний движок, звук, систему 
• • • 'Ч • - • - r • 
скриптш, ан1машю, штучнии rнтелект, мережевии код, управшння пам яттю 1 
багатопоточність. Часто на процесі розробки можна заощадити за рахунок 
1ювторного використання одного ігрового движка для створення безлічі різних 
і1·ор. 
9 
ЧДТУ.231920.005 ПЗ 
З Конструктор ігор - програма, яка об'єднує в собі ігровий рушій і 
інтегроване середовище розробки, і, як правило, включає в себе редактор рівнів, 
що працює за принципом WYSIWYG. Такі програми значно спрощує процес 
розробки ігор, роблячи його доступним любителям-непрограмістів, і можуть 
бути використані в початковому навчанні програмуванню. 
В роботі бу демо досліджувати різноманітні представники всіх цих груп, 
проте будемо приділяти більшу увагу на інструменти, які мали реліз протяком 
останніх 5 років, оскільки світ мультимедія та ігрової індустрії дуже швидко 
оновлюется та прогресує, то набор інструментів 5-ти річної давності виявится 
неактуал1,ним в поточних реаліях[2] . 
Опис отриманих рсузльтатів. В даній роботі було програмне 
забезпечення розвиваючої гри «Таблиця множення» для мобільного додатку на 
основі Unity 
Практ~ч11с з11ачс11ня отриманих результатів, Було проведено 
дослідження що застосуuання розробленого програмного забезпечення. Такого 
типу 1гри стимулюють психічні процеси дитини, викликають асоціативне 
мислення , сприятливо впливають на інтуїцію та гіпотетичне мислення, 
підтримують координацію очей 1 рук, є корисним засобом навчання, 
звільняються від зайвих емоцій і пропонують негайну винагороду. 
Також програмне забезпечення вивчення таблиці множення стимулюють 
розумовий розвиток дитини і підвищують т. зв. пізнавальну активність, що є 
важливим фактором успіху в навчанні. Використання комп'ютера, а особливо 
' і гри , підтримує координацію рук і очей (процес, правильний розвиток якого є 
необхідною умовою для здобуття знань і шкільних навичок), оскільки вимагає 
високої швидкості реакції і часто тривимірної інтерпретації двовимірних 
зображень. 
Особистий внесок автора. У результаті розробки цього програмного 
забезпечення відбувся збір теоретичної інформації про сучасні засоби побудови 
ігор. Огляд і аналіз популярних представників. Постановка проблем для тестових 
10 
ЧДТУ.231920.005 ПЗ 
проект1в прототипну 1rop в контексті спрощених вимог до сучасних ігрових 
проектів. Детальний аналіз характерних представників кожного класу, розробка 
прототипну 1гор з їх допомогою. Визначення оптимальних областей 
використання інструментів на основі аналізу процесу складання прототипів. 
Таким чином, ця розробка є досить обгрунтованою і корисною для 
використання у молодших навчальних класах. 
І І 
ЧДТУ.231920.005 ПЗ 
І ІСНУІОЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ'J(ЗАННЯ ПОСТАВЛЕНИХ 
ЗАВДАІ-ІЬ 
І.І Опис ісJІуІОчих методів 11а засобів використаних при розробці 
Життєвий цикл розробки програмного забезпечення (SDLC - Software 
Development Life СусІе) - це послідовність кроюв розробки, необхідних для 
стrюреню, проекту, ві.п його первинної ідеї до виходу продукту на ринок І 
подальшої його підтримки. 
Життєвий цикл надає низку переваг командам розробниюв, які реалізують 
його правильно : 
Чітко описані цілі. 
Розробники чітко знають цілі, які стоять перед проектом, та результати, 
яких вони мають досягrи у встановлені терміни, знижуючи ризик витрати часу 
та ресурсів. 
2 Правильне тестування перед встановленням. 
Етап те-стування гарантує, що все програмне забезпечення протестоване 
перед розгортанням та готове до виходу на ринок. 
3 Послідовність етапів. 
Розробники не можуть перейти до наступного етапу, доки попередній не 
буде завершений та погоджений з менеджером проекту та замовником. 
4 Гнучкість учасників команди проекту. 
Оскільки SDLC використовують велику та зрозумшу технічну 
документацію та керівні документи, втрата навіть одного великого члена 
. . 
команди не поставить шд загрозу термtни проекту. 
Етапи жи1·rєвого циклу розробки програмного забезпечення. 
ета11 планування; 
етап збору вимог; 
етап проектування та прототипування; 
етап розробки програмного забезпечення; 
етап тестування програмного забезпечення; 
використання готового продукту на ринок; 
12 
ЧДТУ.231920.005 ПЗ 
етап експлуатації та технічного обслуговування; 
Тепер більш докладно розберемося, що являють собою ці етапи. 
І Планування. 
Мета етапу: зрозуміти який продукт мас бути на виході 
На цьому етапі команда фахівців та зацікавлених сторін узгоджує всі деталі 
майбутнього продукту, відповідаючи на важливі питання. Яка мета майбутнього 
продукту? Які проблеми він має вирішувати? Навіщо створюється продукт? 
Після відповіді ці питання, в усіх учасників формується однакове і правильне 
баче11ня майбут1Jьо1·0 продукту. LЦо полегшує розробку та мінімізує ризики при 
створенні ПЗ. 
2 Аналіз та збирання вимог. 
Мета етапу: зібрати та задокументувати вимоги до майбутнього 
програмного забезпечення · 
Етап аналізу та збору вимог, мабуть, один із найвідповідальніших етапів 
жи·гrєвого циклу ПЗ. На цьому етапі команда фахівців із командою замовників, 
а іноді навіть із потенційними споживачами майбутнього продукту, збирає всі 
деталі розробки проекту. Починаючи від маркетингових досліджень ринку, і 
закінчуючи визначенням стеку технологій та функціональністю майбутнього 
продукту. Вся ця інформація, за підсумком, записується в проектну 
документацію, на підставі якої формується графік та строки послідовних завдань 
та етапів розробки продуктів. 
З Проектування та дизайн. 
Мета етапу: втілити вимоги до розробки в дизайн 
Після того, як стали зрозумілі функціональні вимоги та стек технологій, 
можна переходити до проектування та дизайну. На цьому етапі розробники 
проектують майбутню архітектуру проекту у вибраній технології. Створюється 
здаптивний та юзабельний дизайн, продумується зв'язок front частини програми 
3 сервером, розробляються модулі та продумується система безпеки ресурсу. 
4 Етап розробки. 
Мета: створення реального програмного забезпечення 
13 
ЧДТУ .23 1920.005 ПЗ 
Стадія розробки - 11с етал, де вже фактично пишеться код. Техні\1ні фахівці 
беруп. проектну документацію, прототипи, дизайн та архітектуру, і на основі їх 
створюють майбутню програму або сайт. 
Завдання розділені між членами команди відповідно до їхньої галузі 
сnеuіалізаuії. Розробники відповідають за створення інтерфейсу та його зв'язок 
із сервером. Адміністратори бази даних додають необхідні дані до бази. Front
end розробники створюють чуйний інтерфейс майбутнього веб-додатку. 
Результатом цього етапу є програмний продукт, що працює. 
5 Тестування. 
Мета: забсз11счити відповідність готового продукту узгодженим вимогам 
Створення робочого 11родукту - це ще кінець жи1їєвого циклу розробки . 
Після розробки триває етап тестування. На цьому етапі команда порівнює 
задуманий додаток на етапі аналізу та збору вимог із тим, який створений після 
етапу розробки. Відповідає на запитання: 
Чи всі ці функції та інтеграції працюють правильно? 
Чи правильно відпрацьовують усі кнопки? 
Чи досягли того кінцевого результату, який було прописано у вимогах? 
Якщо кінцевий додаток відпрацьовує не зовсім правильно, це буде 
виявлено на цьому етапі і віддано на доопрашовання програмістам. 
Після виправлення та налагодження продукту, він готовий до наступного 
етапу. 
б Вихід на ринок (продакшн). 
Мета: надати готове програмне забезпечення кінцевим користувачам. 
Готова та протестована версія програми або веб-сайту випускається на 
основний сервер і поставляється на ринок (або як ми говоримо в ІС Studio -
"продакшн"). Служба підтримки або замовник збирає відгуки від користувачів. 
14 
--
ЧДТУ.231920.005 ПЗ 
Я.к1цо на цьому етапі виникають помилки в продукті, які не були виявлені на 
етапі тестува11ю1, але відповідають вимогам до продукту, їх передають 
розробникам і їх виправляють на наступ1-юму етапі жит,·євоrо циклу. 
7 Технічна r1ідтримка. 
Мста ста11у: нідтримка ,-ото1ю1·0 r1родукту 
Тепер проект переходить у режим технічного обслуговування. На цьому 
етапі відбувається постійна перевірка працездатності продукту, продуктивності 
системи, системи безпеки та старіння. 
Тех11іч11і фахівці виправляють проблеми, які могли б виникнути у 
користувачів веб-ресурсу. Це може включати обробку залишкових помилок, які 
не вдалося виправити перед запуском, або вирішення нових проблем, що 
виникають через звіти користувачів. Великі проекти можуть вимагати 
триваліших етапів обслуговування порівняно з невеликими. 
Методи управління жиrrєвим циклом розробки програмного забезпечення 
дозволяють ефективно планувати і дотримуватися процесу розробки крок за 
кроком, роблячи його максимально передбачуваним та зрозумілим. Кожен метод 
має власний підхід до процесу розробки продукту. Незалежно від того, яку 
модель ви оберете, етапи життєвого циклу залишаться незмінними. Нижче ми 
розглянемо дві найпоширеніші методології. 
Завдяки гнучкому підходу програмісти можуть швидко адаптуватися до 
ситуації на ринку, оскільки ця модель дозволяє їм вносити зміни до продукту на 
будь-якому етапі процесу розробки продукту. 
Agile є гарним рішенням для проектів з вимогами, що постійно 
змінюються. 
Цей метод дозволяє створювати продукти з використанням коротких 
циклів, де кожен цикл закінчується робочим продуктом з обмеженою кількістю 
функцій. У кожному з циклів є етапи проектування, розробки, тестування та 
розгортання на основному сервері для показу замовнику або фокус-групі. 
15 
ЧДТУ .231920.005 ПЗ 
Перевага цього підходу полягає в тому, що власники продуктів можуть 
бачити результати кожного короткого циклу, надавати свої відгуки та за 
необхід1юсті вносити внправле1111я. Таким чином, п1учкий життєвий цикл 
розробки програмного забезпечення відомий як безперервний процес[З). 
Ключові характеристики Agile: 
обмежені результати, додавання нових функцій на ходу; 
- тестува1н1я проводиться протягом усієї розробки програмного 
забезпечення; 
постійне спілкування м1ж клієнтами, розробниками програмного 
забезпечення, проектом, що призводить до покращення версій після 
кожного спринту; 
забезпечення якості є ключовим процесом. 
Модель водоспаду більше підходить для таких проектів, у яких чітко 
визначено очікування та вимоги до майбутнього продукту. Якщо Agile - це 
гнучкість, то Water·fall про жорстку послідовність всіх етапів циклу розробки. 
Наслідуюtщ цю модель, фахівці не можуть перейти до нового етапу, не 
закінчивши rюперед11ій. Таким чином, у процесі розробки не можна вносити 
буд1,-які зміни і в кінці буде лише одна версія готового продукту. У той час як 
при гнучкому підході, кожен новий цикл призводить до робочої версії продукту. 
Ключові характеристики моделі водоспаду: 
жорстка послідовність кроків розробки; 
- перехід 11а наступний етап розробки можливий лише після завершення 
попереднього етапу; 
клієнти не беруть участь у процесі розробки; 
усі зміни вносяться після реалізації готового програмного 
забезпечення. 
Маючи намічений життєвий цикл розробки програмного забезпечення, 
команда фахівців та замовники можуть відчувати блаженство передбачуваної 
розробки програмного продукту. Для розробників програмного забезпечення це 
16 
j 
ЧJtTY.231920.005 ПЗ 
oma'lac Р<Н),111111я 1010. що во1111 роб 1я1ь зараз і що буде далі, а для замовників 
: 1:.1< u11св111:11ісп,, що "іх11і1і 11родуК'r буде розроблений з1·ідно з усім а очікуванням~• 
тз) ВСТаJІОВ,ІСІІі 1срмі1111 . 
Так11м ч1111ом, усі проекти повинні мати 11ам іче11и й життєвий цикл 
р0Jробк11 програ,11юго забсзnсчеш1я , тому що це с1tиний спосіб гарантувати, що 
о 1r111\ta11с 11рогра:-.111с шбезr1счс1111я буде вілповіда rи вимогам як власників 
бізнесу, так і кінцевих користувачів. 
1.2 Л11а .r1із іс11ую•111 х аналогів програми 
Стра~·сгії - жанр гри , в якій запорукою до перемоги є планування 
стратепчне мисс1111Я людини. Самі відомі стратегії: Dota 2, Warcraft З, Rome: 
Total 'vVar. 
Рисунок 1.1-Головне вікно гри 
Аркадні - жанр rри. у якій rравцев1 дово.::опься д~яти швидко, 
покладаючись тільки на своє чугrя. Самі відомі аркадні ігри: Mortal Kombat, 
Assassin's Сгееd, N"ced for Speed [ 4]. 
17 
ЧДТУ.23 1920.005 ПЗ 
Рисунок 1.2 - Огляд машини в грі 
J Іогічні або го'JІОІЮJІОМ1<11 - жа11 р гри, в якій розвивастьсн логічне мисJ 1сн11я 
1 ·ра~щя , його ysiua та розвиток 11ам'нті . Самі відомі Jю1·і 1п1і ігри: пnзли, кубик
ру611ка , шахи, шашки. 
Рисунок 1.3 - Набір різних головоломок 
Рольові - жанр гри, де граваuь асоціюєтьс~ з конкретним персонажем, або 
л і.uером команди. Відомі рольові ігри: Fallout, Mass Effect, Far Cry. 
18 
ЧДТУ.23 1 920.005 ПЗ 
. 
: • ~ .h  ' ~,  
• 
-,, ~ 
' . 
Рисунок 1.4 - Постер гри 
Прнгод1шщ,кі - жанр гри, у якій керований гравцем герой просувасться по 
сюжету і взаємодіє з і1-ровим світом. Відомі пригодницькі ігри : Assassin's Creed, 
Princc or Persia, Наггу Potter. 
Рисунок 1.5 -- Фрагмент кліпу гри 
19 
Ч) tТУ.231920.005 І IJ 
30-Лcti on - жанр 1-ри, в якій успіх кравця залежить від його шв~1лкості, 
rеакнії та вмі1 1 11я 11рий11яти 11ір11с ріше1 111я. Відомі 30-Лction : Maria, GTА , Crysis, 
Са ІІ or Ot11y. 
Рисунок І .6 - Постер гри 
С иІ\•1 у;1ят<>р - >І<а 11 р гри, де с імітатори, меха~1ічні або комп'ютерн і, що 
імітують у 11 раш1і1111я 11еоним проttесом. Відомі симулятори: l~IFA, Sims, PES. 
Рисунок l. 7 - Фрагмент гри 
На просторах і11тер11сту, можна знайти в достатній кількості різноманітних 
розuиваючих комп 'ютерних ігор. Та хотілося б описати декілька цікавих з них. 
20 
ЧДТУ.231920.005 ПЗ 
Перша гра зустрічає 11ас яскравим головними меню 11а аttrлійській мові. В 
меню відображається 11азоа ком11аиії розробника, також присул11 дв~ 
к1ю11ки.І Іерша JtозвоJ1я є: 11срсйти н настуннс меню, Jtpyi·a яВJІЯЮ собою посилання 
11а інші ігри розроб11ика [5] . 
Рисунок 1.8 - Перше головне меню 
Далі п1сля натискання першої клавіші, ми переходимо вже до основного 
меню гри, де Ііас зустрічає герой мультфільмів Мікі Маус. Гра так і зветься Мікі 
маус математика. Тут також присутні дві кнопки, як і в попередньому скріншоті. 
Перша це посилання на інші ігри, друга перехід до самої гри. 
Рисунок 1.9 - Друге головне меню 
21 
ЧДТУ.231920.005 ПЗ 
Отже, враховуючи ІJсі 11аведс11і вище дан і , можна зробити висновок, що гра 
J toc итi, проста, має зрозум ілий простий інтерфейс, але на англійській мові, що 
JtClllO може усю,аднити їі проходження для україномовної дитини. Також має 
малу інтерактивність і прості текстури [6). 
І Іастуttна гра також ан1·ломо1ша, має досить цікаве головне меню з однією 
к~юнкою, яка 11сре11 осит1, нас до самої fl)И . Називається дітки динозаври 
~tатемати ка. 
Рисунок l . l О - Головне меню 
На наступному скріншоті видно, що є три рівня складності, це відображено 
D правому верхньому куті дошки. Кожен рівень має по 1О  завдань. На рішення 
всіх завдань дається 120 секунд, це відображено па центральному верхньому 
табло. Також є два види рекордів, перший загальний другий найкращий за день. 
Сенс гри полягає в тому щоб за допомогою мишки перетягувати листки на місце 
правильної відповіді. 
22 
І 
чдтУ.2з 1920.005 nз 
Рисунок l. . J l - Перше запитання легкого рівня 
Вис11овок до розділу І 
У цьому розділі ми розглянули існуrочі методи та засоби розв'язан11я 
поставлених завдань, а також nроаналізува.r~и існуючі аналоги програми. 
ІЗюшилось, що на сьогоднішній день існує низка програм, які допомагають 
учням з вивченням навчального матеріалу. Але, як бкачимо, гра залишається 
оажлиnим елементом у житті людини будь-якого віку. У сучасному суспільстві 
на 11срс;(ІІьому плані з'явилася комп'ютерна гра, яка зацікавила, як багатьох 
дітей так багатьох дорослих. Сучасна комп 'ютерна гра це 
баrатофу11кціо11альна програма, .яку використовують не тільки з розважальними, 
а й із навчальними та пропагандистськими цілями. Таким чином,реалізація 
даного програмного забезпечення підтверджує щодо існування позитивного 
uпливу комп'ютерних ігор на пізнавальну сферу особистості учня, а саме на його 
розумовий розвиток, загальні творчі здібності, невербальну креативність, 
тренува11ня короткочасної пам'яті. Також зв'язки низького рівня свідчать про 
позитивний вплив раціонального використання комп'ютера учнем у власних 
цілях, що сприяє покращенНJо його розвитку. 
23 
ЧДТУ.231920.005 ПЗ 
2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ 
2.1 Модел1ова1111я предмеп1ої області 
2.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області 
Комп'ютерні ігри привертають все більше і більше уваги з кожним роком. 
Комп 'ютерна графіка вийшла на рівень, коли вже важко розрізнити гру від 
реальності. Доходи від комп'ютерних, мобільних ігор становлять сотні мільярдів 
доларів. Ми живемо в час коли ігри перетворилися в перспективний бізнес для 
всіх. Існують різні безплатні/платні конструктори для їх розробки. На 
сьогоднішній день про комп'ютерні ігри знають абсолютно всі, адже в них є 
досить непогана реклама в усіх веб ресурсах. Навіть деякі армії світу 
використовують ігри симулятори, як тренувальну платформу, адже дешевше 
пройти тренування на симуляторі, ніж використовувати наприклад реактивний 
літак чи космічну ракету. Також· зараз використовують ігри, які наближенні 
діями до реального жиrrя для навчання штучного інтелекту, адже знову ж таки 
це швидше і простіше [7]. 
Давно відомо, що при розвитку мислення і формуванні особистості 
важливу роль відіграє не тільки освітній фактор, але і характер ігрової діяльності. 
Для дитини гра є провідною діяльністю, тому що саме у процесі гри дитина 
засвоює значення і способи вживання предметів, а також різні варіанти 
соціальних відносин. Гра залишається важливим елементом у житті людини 
будь-якого віку. Психологи давно та активно вивчають ігрову діяльність, 
психологічну теорі10 гри розробляли Л.С. Виготський, С.Л. Рубінштейн, Д.Б. 
Зльконін та ін. 
Психологічна природа, сутюсть, виховю та ІНШІ можливості гри як 
складного, багатофункціонального феномену втілені в її ознаках, одні з яких 
властиві будь-якій соціальній діяльності, інші - тільки грі. Дитяча гра зумовлена 
віковими особливостями особистості. 
24 
Ігрова діяльність впливає на формування довільних психічних процесів. 
Умови ~ ·ри вимагаюп, від r·раrщя зосередженості на змісті дій і сюжеті , на діючих 
особах чи предметах, що вклю~rені до ігрової ситуації. Ігрова ситуація впливає 
т1 мислення і психіку дитини, nідJ1ітка та дорослого, що грають. Гра сприяє 
розвитку рефлексії, оскільки в процесі гри виникає реальна можливість 
контролювати те, як виконується бущ,-яка дія, що входить у процес спілкування. 
У рольовій грі формується здатнісп, осмислюnат11 свої власні дії, передбачати 
реакцію інших людей. В ігровій діяльності підліток не тільки заміщає реальні 
предмети , але й приймає на себе ту чи іншу роль і починає діяти відповідно з 
цією роллю. Роль У сюжетній грі полягає саме в тому, щоб виконувати обов'язки, 
що накладаються роллю, і реалізовувати права стосовно інших учасників гри. 
Досвід ігрових і реальних взаємии у сюжетно-рольовій грі лягає в основу 
особливої внастивості мислення, 1цо дозволяє передбачити майбутню поведінку 
11ю;1ей й у залежності від ц1,ого булувати свою власну поведінку. 
Існує досить суперечлива гіпотеза, щодо впливу комп'ютерних відеоігор 
на агресію та поведінку тодини. Цим зайнялися вчені з Інституту людського 
розвитку Суспіт,ства Макса Планка за участю Сімоии Кюн. У їхньому 
експерименті взяли участr, 90 добровольців (48 жінок і 42 чоловіки, середиій вік 
28 років), які ніколи не грали у дві задіяні у дослідженні відеогри - GTA V і The 
Sims 3. Ні в кого з учасників не було психічних розладів. 
Учасників розділили на три 1 ·рупи. Перші дві групи - активна і активно-
1<011троль11а - грали у відсо і, ·ри. Лктив11а група грала в GTA V - свідомо 
"агресивну" rpy, а активно-контрольна грала в The Sims З - гру, яка (без умислу 
користувачів) агресії в геймплеї не вимагає. Добровольці грали щодня протягом 
двох місяuів, не менше ЗО хвилин в день. Третя група, пасивно-контрольна, в ігри 
не r·рала. 
До після закінчення 11ерюду активної гри учасники заповнили 
опитування на предмет вираженої агресії, емпатії та прояви просоціальної 
поведінки. Опитування також повторили ще через два місяці. Результати 
опитування показали, що рівень агресії та емпатії не змінився серед учасників 
25 
усіх тр1,ох • ·руп: як У порівнянні о;н111 з одним, так і у порівнянні з результатами 
опнтува 11ь У р1зних часових точ~<ах. 
Методоло~ ·ія - це система принципів, а також сукупн1сть ідей, понять, 
методів , способів та засобів, що визначають стиль розробки програмного 
забезпечення . Конкретні речі реал ізується через обрану методологію. Саме вона 
визначає, як виконуватиметься розробка. 
Існує багато успішних методологій створення програмного забезпечення. 
Вибір конкретної методології залежить від розміру команди, від специфіки та 
складності проекту, від стабільності та зрілості процесів у компанії та від 
особистих якостей співробітників. 
Rational Unified Process (RUP) - це основа технології розробки 
програмного забезпечення, розроблена та продається компанією Rational 
Software [9]. Він забезпечує дисциплінарний підХід до розподілу та управлінню 
завданнями та областями nідповідат,ності в організації, займається розробкою 
ПЗ. ItUP використовує ітеративний відхід, то є послідовність наростаючих 
кроків чи ітерацій. Кожна ітерація включає деякі або більшу частину дисциплін 
розробки (Виявлення вимог, аналіз, проектування, реалізацію тощо). Кожна 
ітерація має чітко визначений набір цілей, і вона створює частково працюючу 
реалізацію кінцевої системи . Кож1:,а наступна ітерація будується на результатах 
попередшх, розвиває та вдосконалює систему до того часу, доки створено 
кінцевий продукт [8]. 
Особливість методології у тому, що ступінь формалізації може 
змінюватись в залежності від потреб проекту. Можна по закінчення кожного 
етапу та кожної ітерації створювати всі необхідні документи і досягти 
максимального рівня формаJ1ізації, а можна створювати тільки необхідні для 
роботи документи, аж до повного їх відсутності. За рахунок такого підходу до 
формалізації процесів методологія с досить гнучкою та широко популярною. 
·модель життєвого циклу RUP с досить складною, детально опрацьованою 
ітератив110-інкрементною модел11ю з елементами каскаду. У моделі RUP 
виділяються 4 основні фази, 9 видів діяльності (процесів). 
26 
ЧДТУ .231920.005 ПЗ 
Основними фазами RUP є: 
- фаза початку проекту (lnceptjon); 
- фаза опрацюванНJІ (ElaЬoration ); 
- Фаза побудови (Construction); 
Фаза передачі (Тransition). 
Мета фази - зробити систему повністю доступною кінцевим 
корис,увачам. Тут відбувається остаточне розгортання системи на її робочому 
середовищі, прип&суваJІЮІ дрібних деталей під потреби користувачів. 
В рамках кожної фази можливе проведеНЯJІ кількох ітерацій, кількість 
яких визначається складвіе110 виконуваного проекту. 
Одним із основних стовпів, на ,псі спирається RUP, є процес створення 
моделей за допомогою ушфікованої мови модеmоВВНВJІ (UМL). Уніфікована 
мова моделювання (Unified Modeling Language, UМL) - це універсальна мова 
візуальної моделювання систем. Найчастіше UМL асоціюється з моделюванням 
об'єктно-орієнтованих програмних систем, але він має набагато більше широке 
застосуваню~ за.вдпн властивій ііому рооmирюваності. UМL не прив'язаний до 
будь-яхої коякретвої методолоп1 або життєвого циклу. Він може 
використовуватись з усіма існуючими методологіями. Основна ідея UМL -
можливість моделювати програмне забезпечення та інші системи як набори 
об'єктів, що взаємодіють. 
Методологія RUP є більш універсальною, mж інші розглянуті 
методолоrії, тому що застосовується ях у невеликих та швидких проекти, де за 
рахунок відсутності формалізації потрібно скоротити час виконання проекту та 
витрати, так і у великих та складних проектах, де потрібен високий рівень 
формалізму, саме тому вона буде вихористовуватися ях основна методологія 
розробки в даній роботі. 
2.1.2 Елементи модеmовання предметної області 
Моделювання предметної області розробки ігор може включати такі 
елементи: 
27 
ЧДТУ.231920.005 ПЗ . 
Концепт-арт: це процес створення малюнків та ілюстрацій, яю 
допомагають візуалізувати концепцію гри. Концепт-арт може включати дизайн 
персонажів, пока.цій і атмосфери гри. 
Гейм:плей-дизайн: це процес створенWІ правил та механік гри, які 
забезпечують певний рівень складності та захоплюючості. Геймллей-дизайн 
може вІСJІЮчати розробку і налаштування ігрових рівнів, балансування ігрових 
елементів і тестування геймплею. 
Архітектура движка: це процес розробки двиЖІСа rри, який є основою для 
створення ігрового контенту та забезпечує взаємодію між ігровими об'єктами. 
Архітектура движка може включати розробку ігрової логіки, візуалізацію і 
звукові ефекти. 
Розробка інтерфейсу користувача: це процес створепНJІ інтерфейсу, який 
полегшує управліНШІ rрою і забезпечує гарне візуальне сприйНJrГГJІ ігрового 
процесу. Розробка інтерфейсу користувача може включати в себе створення 
графічних елементів, анімації та налаштування управління. 
Тес'І)'ван:ня: це процес перевірки гри на наявність помилок, недолікjв та 
проблем, які можуть вnливути на досвід гравця. Тестування може включати 
тестування геймплея, rрафіки, звуку і продуктивності гри. 
Оптимізація: це процес оптимізації гри дm1 підвищекня продуктивності та 
покращеННJІ досвіду гравця. Оптимізація може включати оптимізацію графіки, 
звуку і управління ресурсами комп'ютера. 
Розробка та інтеrрація ш~учного інтелекту: це процес розробки та 
інтеграції опучвого інтелекту в гру, який дозволяє створювати більш реалістичні 
сценарїї та поведінку ігрових об'єктів. 
Модеmоваиня предметної області розробки ігор включає ряд елементів, 
пі можуть бути використані дm1 створенШІ ігрового процесу та ігрової механіки. 
Нижче наведено деякі з цих елементів: 
Ігровий движок (Game engine) - це програмне забезпечення, яке 
ВИІСористовується для створення ігор. Він включає інструменти дm1 створення 
28 
ЧДJУ.231920.005 ПЗ 
графіки, звукових ефектів, фізичної симуляції, управління персонажами та 
багатьох інших аспектів irpoвoro процесу. 
Моделі персонажів (Character models) - це ЗО-моделі, які представляють 
персонажів У rpi. Вони можуть бути створені за допомогою програмного 
забезпечення для ЗD-моделюваННJІ та вихорнстовуватися ДJUІ анімації та 
керування рухом персонажів у rpi. 
Анімації (Anirnations) - це рухи персонажів, які створюються за 
допомогою ЗО-моделювання та використовуються дл.я передачі дій персонажів 
у грі. 
Графіка та ефекти (Graphics and Effects) - це візуальні елементи гри, 
включаючи фоки, текстури~ освітлення, частиmси, дим та багато іншого. Вони 
створюються за допомогою графічних програм і використовуються для 
створення ефектів та атмосфери у грі. 
Звукові ефеІСТИ (Sound effects) - це звукові ефекти, які використовуються 
ДЛJІ передачі звукових подій у грі, таких як звуки пострілів, голоси персонажів 
та звуки навколишнього середовища. 
Штучний інтелект (Artificial Intelligence) - це технологія, яха 
використовується для створення поведінки комп'ютерних персонажів у грі . Вона 
може бути використана ДЛJІ створення розумних ворогів, союзників чи інших 
персонажів, .які можуть взаємодіяrи із гравцем та один з одним. 
Рівні та місії (Levels and Мissions) - це складові гри, яю створюються ДЛJІ 
того, щоб rравець міг пройти гру поетапно. Вони можуть включати різні 
завдання, сюжетні лінії та умови проходження гри [9]. 
Інтерфейс користувача (User Interface) - це компонеJП rрн, який 
використовується ДІІ.Я взаємодії. 
2.1.3 Робоча область моделювання 
Lucidchart.com - це онлайн-сервіс для створення діаграм, схем, блок-схем, 
макетів та інших візуальних матеріалів. Він надає користувачам можливість 
29 
ЧДТУ.23 І 920.005 ПЗ 
створювати та редаrувати діаrрами в режимі реального часу, ділитися ними 3 
ікurими користувачами та працювати над ними спільно. 
Має вели.ку кількість інструментів і функцій для створення різних типів 
діаграм, включаючи організаційні схеми, UМL-діаrрами, ЕR-діаграми, схеми баз 
даних, потокові діаrрами, діаrрами Ганта та багато іншого. За допомогою 
Lucidchart.com користувачі можуть легко створювати професійно діаграми без 
необхідності встаяоалеНЮІ спеціалізованого програм:пого забезпечення на свої 
комп'ютери. Також має інтеrрацію з іншими онлайн-сервісами, такими як Google 
Диск, Мicrosoft Office, Atlassian та іншими, що дозволяє користувачам зручно 
імпортувати та експортувати діаграми у різн·их форматах файлів. 
Lucidchart.com - це онлайн-платформа для створення діаграм та схем 
різних типів. Ця платформа надає користувачам зручний інс-rрументарій для 
створеННJІ діаrрам, блок-схем, графіків, організаційних діаграм, макетів та інших 
типів схем, які можуть бути використані для організації та візуалізації різних 
процесів, проектів, ідей та ін. Має безліч шаблонів і форматів, які дозволяють 
користувачам швидко створювати професійно діаграми і схеми, що виглядають, 
без необхідності в глибоких знаннях дизайну і програмування. Крім того, 
Lucidchart.com дозволяє створювати та спільно редаrувати діаграми з іншими 
користувачами в режимі реального часу, що зручно для колаборативної роботи 
над проектами та завданнями. 
2.2 Формуванн• та аналіз вимоr 
2.2.1 Формування вимог до програмного забезпечення. Первиню і детальні 
вимоги. Вимоm замовника і розробника. Функціональні та нефункціональні 
ВИМОГИ 
Вимоrу можна визначити, як «докладний опис того, що має бути 
реалізовано». Існує два основних типи вимог: 
- функціональні вимоги - я.ка поведінка має пропонувати систему; 
30 
А 
ЧДТУ.231920.005 ПЗ 
нефункціональні вимоги - особлива властивість або обмеження, що 
накладається на систему. 
Розглянемо спочатку системнЬJ вимоги. Системні вимоги -поняпя, яке 
використовується для опису характеристик, яхим має відповідати цифрове 
пристрій (ПК, гральна консоль, мобільний телефон тощо) дт1 коректної роботи 
певного програмного забезпечення, у нашому випадку rри. Ці вимоги можуть 
описувати як апаратне забезпечення, так і проrрамне забезпечення (потрібні 
драйвери, операційна система тощо). Розрізняють мінімальні та рекомендовані 
системні вимоги. Якщо мінімальні системні вимоги показують, яка конфігурація 
системи цілком потрібна для запуску ПЗ, то рекомендовані системні вимоги 
показують, яка конфіrураці.Jr здатна забезпечити максимально комфортні умови 
роботи ПЗ. Також іноді виділяють максимальні системні вимоги, за яких 
забезпечується повна фун!ІQJjовальність та можливість користуватися всіма 
послугами потрібної проrрами. Оскільки серед поширених проrрамних 
продуктів найбільш технічно вимогливими є відеоіrри, то для них відомості про 
системні вимоги є дуже бажаними. 
Нижче наведено мінімальні та рекомендовані системні вимоги: 
Мінімальні системні вимоги: 
операційна система: windows 7 spl+, macos 10.12+, ubuntu 16.04+ (64-
bit); 
процесор: з підтримкою sse2; 
графічна карта: за допомогою directx 11 або opengl 4.х; 
пам'ять: 4 rб оперативної пам'яті; 
місце на жорстІСому диску: 1О  rб вільного місця; 
додатково: підключення до інтернету для завантаження додаткових 
ресурсів. 
Рекомендовані системні вимоги: 
операційна система: windows Іо+, macos 10.15+; 
процесор: з підтримкою sse2; 
графічна карта: за допомогою directx 12 або vulkan; 
31 
ЧДТУ.231920.005 ПЗ 
- пам'ять: 8 rб оперативн0~1 п. ... , . . 
- ЯТІ чи 6щьwе; 
- місце на жорсткому днску: ssd з 20 rб вільного місця або більше. 
Додатково: ШВидкИй 
дос,уп до lитервеуу для заваитажевня додаткових 
ресурсів та вставоалеНЮІ nлагінів. 
tf'h.1t>vтw;oнaльвi в~о - . . .. . 
...,J  ~ 0.,- ГИ для розробки ігор це опис того, ЯІО функц11 та 
можливості мають бути реалізовані у грі, щоб вона відповідала заданим вимогам. 
Ці вимоги визначають, що повияна виковувати гра, m дії та завдання мають 
бути виконані гравцями, юсі фующії інтерфейсу мають буrи реалізоваm та яка 
має бути загальна іrрова механіка. 
Фуmсціовальві вимоги можуть вкmочати опис геймплея, рівнів, 
персонажів, ігрових об1єктів, сценаріїв, місій, інтерфейсу користувача і багатьох 
іяшИХ аспектів гри. Вони також можуть вІСЛJОчати вимоги до продуктивності, 
такі як частота JСаДJ>ів, час зававтажеRІІJІ і т.д. 
Важливо відзначити, що функціональні вимоги мають бути визначені до 
почапсу розробки гри, щоб команда розробників могла точно розуміти, я.кі 
фунхціі та можливості мають бути реалізовані. Це також допоможе уникнути 
проблем з розумінням очікувань замовmпса та покращити процес планування та 
розробки гри [10]. 
Функціональні вимоги визначаюrь те, що має робити гра і я:к вона має це 
робити. ВоRИ можуть включати: 
Ігровий процес: опис ігрових механік, рівнів та завдань, я:кі мають бути 
ви:кояаяіrравцем. 
УправліяюІ персонажем: як персонаж може переміщатися, я.кі дії може 
виконувати і як rpa реаrуватиме на ці дії. 
Штучний інтелект: опис поведінки комп'ютерних персонажів у грі. 
Графіка та анімація: візуальні ефекти, опис способу відображення 
ігрового свіrу та персонажІВ. 
Звук та музика: звукові ефекти, фонова музиха та звуковий супровід дій у 
rpi. 
32 
ЧДТУ .231920.005 ПЗ 
Інтерфейс та управ.л·і юц·•  сп - ... · ф й 
оса 6 взаємода1 гравця з грою через антер е с 
корис-rувача, хлавіатуру, мищу, джойстик і т.д. 
Функціональні вимоги . 
длJІ розробки ~гор є важливим компонентом 
процесу створенш rри та дозволяють переконатися, що гра відповідає 
очікуВЗНЮІМ rравців та виховує необхідні фунхції. 
Функціональ Н·І ·  вимоги rри включають в себе наступні пункти: 
1 Наявність головного меню, пе буде простим та інтуїтивно зрозумілим. 
Воно вкmочатиме в себе тахі ЮJопхи: 
- нова rpa; 
- налаш~увания; 
- вихід. 
2 1:fаявність мінімум 5 рівнів з різвимв прИІСЛадами. Рівні повинні мати 
наС1)'11НіелемеІПИ: 
блоки на яких знаходяться відповіді; 
блоки з запитаннями; 
платформа дm1 руху; 
задній фон; 
музичний супровід. 
З Виконання анімації дm1 наступних дій: 
руху героя; 
стрибку героя; 
переходу між рівнями. 
Нефункціональні вимоги для розробки ігор описують критерії, які не 
пов'язані з фуюсціональністю гри, але визначають .якість, продухтИВність, 
зручність вихориставня та безпеку гри. Нижче наведено нефунхціональнь1 
вимоги для для моєї rри: 
Продуктивність: rpa повинна працювати з достатньою швидкістю та 
плавністю, щоб забезпечити комфортну гру. Це вкmочає швидке завантаження 
гри та її рівнів, високу швидюсть кадрів в секунду (FPS), відсутність затримок і 
переривань. 
33 
ЧДТУ.23 І 920.005 ПЗ 
Сумісність: гра повинна працювати на різннх платформах, таких як ПК, 
консолі та мобільні пристрої, а також з різними операційними системами та 
дозволами екрану. 
Безпека: гра повинна бути захищена від атак хакерів, ппсідливого ПЗ та 
інших загроз безпеці, а також захистити дані користувачів. 
ДОС'І)'Пність: гра повинна бути доступною для людей з обмеженими 
можливостями та відповідати стандартам доступності, наприклад, бути 
доступною дrur людей з поруwеНЮІМ зору або слуху. 
Зручність вихориСТ8ВЮІ: інтерфейс гри має бути інтуїтивно зрозумілим та 
зручним для вихори~ щоб гравці могли швидко освоїти гру та почати 
грати. 
Якість графіки та звуку: гра повинна мати високоякісну графіку та 
звуковий супровід, щоб створити у гравця реалістичне та привабливе .ігрове 
середовище. 
Надійність: гра має бути стабільною і не фарбуватися, щоб гравці могли 
грати без переривань та зберігати свій прогрес. 
Масштабованість: гра повинна бути здатна працювати з різною кількістю 
гравців та масштабуватися за необхідності, наприклад, при зростанні числа 
гравців або оновленні ігрового контенту. 
Нефунхціональні вимоги є важливими дтr забезпечення якісної та 
успішної гри, .яха задовольюrrиме потреби користувачів та відповідатиме 
очікуваннямрюuсу. 
Первинні вимоги до розробки гри - це основні цілі та функції, які гра 
повинна виконувати. Вони вюначають, ,псим має бути геймплей та яхі функції 
мають бути доступні дл.я гравців. Нижче наведені первинні вимоги моєї гри: 
Цільова аудиторі.я: гра має бути націлена на конкретну аудиторію, і її 
геймплей, графіка, звук та інші аспекти мають бути відповідними. Моя цілбова 
аудкrорі.яі це діти молодшого шхільного віку. 
Жанр: гра повинна ставитись до конхретного жанру, такого як стратегія, 
RPG, mутер? головоломка і т.д. Жанр моєї гри - розвиваючий. 
34 
ЧДТУ .231920.005 ПЗ 
Історія та сюжет: rpa повинна мати захоплюючий сюжет, який привабить 
гравців та змусить їх продовжувати rpy. Історія моєї гри цікава і зрозуміла для 
дітей [І І]. 
Геймллей : rpa повинна мати унікальний і цікавий rеймплей, який 
заJІУЧ&тиме гравців і змушуватиме їх повертатися до гри. Геймплей не 
nереповненний обєктами, тому цікавий для дітей. 
Мультиплеєр: гра повинна мати мульmплеєрний режим, якщо це 
передбачено, щоб гравці могли грати один з одним. Така вимога в мене не 
використовується. 
Рівні складності: rpa повинна мати кілька рівнів складност1, щоб 
задовольНJІТИ гравців з різним рівнем досвіду і навичок. Рівні складності 
присутні. 
УправлінНJІ персонажем: rpa повинна мати зручне та іН1"Уїтивно зрозуміле 
управлінНJІ персонажем, щоб гравці могли швидко освоїтися з rрою. Можливість 
управляти легко персонажем є. 
Якість графіки та звуку: rpa повинна мати високоякісну графіку та 
звуковий супровід, щоб створити у rpaвwr реалістичне та привабливе ігрове 
середовище. Графіка розроблена на достатньому рівні для дитини. 
Ці первинні вимоги є основою розробки гри, і від їх правильного 
визначенНJІ залежить успіх і попутrрність гри. 
Вторинні вимоги для розробки гри - це додатхові функції та можливості, 
які покращують ігровий процес, але не є необхідними дл.я здійснення основних 
функцій гри. Дe,ud приклади вторинних вимог розробки гри: 
Режим VR: гра може мати додатховий режим вір,уальної реальності, який 
дозволяє гравцям глибше поринуrи у ігровий світ. 
Різні ігрові режими: rpa може мати кілька різних ігрових режимів, таких 
п кампанії, виживання:, змагання і т.д. 
Редактор рівнів: гра може мати вбудований редактор рівнів, який дозволяє 
гравцям створювати власні рівн.і та ділитися ними з іншими гравцями. 
35 
ЧДТУ.231920.005 ПЗ 
Система досягнень та нагород: гра може мати систему досягнень та 
нагород, які мотивують гравців грати та просуватися у грі. 
Ігрові елементи соціальних мереж: гра може мати елементи соціальних 
мереж, такі як можливість ділитися результатами гри із друзями, запрошувати 
друзів у гру тощо. 
Підтримка длЯ різних платформ: гра може мати можливість запускатись 
на різних платформах, таких як РС, консолі та мобільні пристрої. 
Різні мови та локалізація: гра може мати підтримку для різних мов та 
локалізацію, щоб гравці з усьоrо світу могли грати в гру своєю рідною мовою. 
Ці вторинні вимоги можуть зробити гру більш цікавою та привабливою 
дл.я гравців, але вони не є обов'язковими для успішної розробки гри. Вони 
можуть бути додані в гру в процесі розробки, якщо розробник вирішить, що вони 
покращать ігровий процес та залучать більше гравців. 
2.2.2 Формування вимог за допомогою діаграми прецедентів 
Ідентифікувати прецеденти і дійові особи це один з найважливіших 
моментів проектування системи. При ідентифікації виконуються наступні кроки: 
чітко розмежується система і її оточення; 
визначається, які дійові особи і як саме вони взаємодіють з системою, 
який функціонал (варіанти використання) очікується від системи; 
визначається і описується в словнику предметної області (глосарії) 
загальні понятrя, які необхідні для детального опису функціоналу 
системи (прецедентів). 
Подібний вид діяльності .зазвичай виконується в такій послідовності: 
1 Визначення дійових осіб; 
2 Визначення прецедентів (варіантів використання); 
З Складання опису кожного прецеденту; 
36 j 
ЧДТУ.231920.005 ПЗ 
4 Опис моделі прецедентів в цілому (цей етап включає в себе створення 
словника предметної області). Спочатку вимоги оформляються у вигляді 
звичаіtноrо текстового документа. який створюється або самим користувачем, 
або користувачем і розробником разом. Далі вимоги оформляють У вигляді 
таблиці. У ліву колонку поміщають прецеденти, а в праву - дійових осіб, що 
беруть участь в прецеденті. 
Для процесу управління етапами розробки проrрамноrо забезпечення за 
допомогою методу СRМ було створено нас,упні дійові особи або актори : 
користувач; 
система. 
Далі виділено наступні прецеденти: 
відкрипя rри; 
вибір рівня гри; 
проходження гри. 
виведення на екран результатів проходження. 
Діаграма прецедентів є графом, що складається з множини актор1в, 
прецедент1в {варіантів використання) обмежених границею системи 
(пр.ямокуrник), асоціацій між акторами та прецедентами, відношень серед 
прецедентів, та відношень узагальнення між акторами.[!] Діаrрами прецедентів 
відображають елементи моделі варіантів використання. Суть даної діаграми 
полягає в наступному: проектована система представляється у вигляді безлічі 
сутностей чи акторів, що взаємодіють із системою за допомогою так званих 
варіантів використання. Варіант використання (англ. use case) використовують 
для описання послуг, які система надає актору. Іншими словами, кожен варіант 
вихористання визначає деякий набір дій, яхяй виконує система при діалозі з 
актором. При цьому нічого не говориться про те, яким чином буде реалізована 
взаємодія акторів із системою. 
37 
ЧДТУ.231920.005 ПЗ 
рисунок 2. l - Графічне представлення відносин між актором і прецедентами 
У мові UМL є кілька стандартних видів відношень між акторами 
•-·-uи використання: 
gарІІІР •- ·· 
_ асоціації (англ. association relationship); 
_ включення ( англ. include relationship) ; 
_ розширення ( англ. extend relationship) ; 
_ узагальнення (англ. generalization re/ationship). 
При цьому загальні властивості варіантів використання можуть бути 
представлені трьома різними способами, а саме - за допомогою відношень 
8ключення, розширення і узагальнення. 
Відношення асоціації- одне з фундаментальних понять у мові UМL і в 
тій чи іншій мірі використовується при побудові всіх rрафічних моделей систем 
у формі канонічних діаграм. 
Включення (англ. include) у мові UМL- це р1зновид відношення 
залежності між базовим варіантом використання і його спеціальним випадком. 
При цьому відношенням залежності (англ. dependency) є таке відношення між 
двома елементами моделі, при якому зміна одного елемента (незалежного) 
приводить до зміни іншого елемента (залежного). 
Відношення розширення (англ. extend) визначає взаємозв'язок базового 
варіанта використання з іншим варіантом використання, функціональна 
38 
--
. ЧДТУ.231920.005 ПЗ 
rtоsедівка якого задІЮЄТЬся базовим не завжди, 
а тільки при ВИКОНЗННJ 
додаткових умов. 
2.3 ПроеКІу-вавв11 логічвоі 
. струк,урв програмного комплексу 
2.3.1 Дааrрами класів 
Діаrрама класів ( class dj::ior.:.-) 
~ кщ СЛ)'ЖИть дЛJІ подання статичної структури 
моделі системи в термінолоrії класів об' . 
єктно-ор1єнтованого програмування. 
Ді .. ~uа класів може відбивати . . 
а.а r-·- • зокрема, РІЗНІ взаємозв'язки між окремими 
UТІІОСТЯЮІ предметної області 'Nllvu•~ • 
С1 ·- ' -~ ях об'єкти й шдсистеми, а також описує 
їХ}ОО внутрішню структуру й ТИПИ відносин. На даній діаrраю не вказується 
іsформація про тимчасові аспекти фувкц,іонування системи. Із цього погляду 
діаrр&М& класів є подальшим розвитком концеmуальної моделі проектованої 
системи.Діаграма класів являє собою деякого графа, вершинами якого є 
елементи типу "кла си ф'~ катор ",  яхі зв'язані різними типами структурних 
відносин. Варто помітити, що діаграма класів може також містити інтерфейси, 
пакети, відносини й навіть окремі екземnляри, тахі як об'єкти й зв'язКІf . Коли 
говорять про дану діаграму, мають на увазі статичну структурну модель 
проектованої системи. Тому діаграму класів прийюrrо вважати графічним 
представленому таких структурних взаємозв'язюв лоrічної моделі системи, яю 
не залежать або інваріантні від часу. 
Діаграма класів складається з безлічі елементів, яю в сукупносn 
відбивають декларативні знанw1 про предметну область. Ці знання 
інтерпретуються в базових понятrях мови UМL, таких як класи, інтерфейси й 
відносини між ними і їхніми складовими компонентами. При цьому окремі 
компоненти цієї діаграми можуть утворювати пакети для подання більше 
загальної моделі системи. Якщо діаграма класів є частиною деякого пакета, то її 
компоненти повинні відповідати елементам цього пакета, включаючи можливі 
посилання на елементи з інmих пакетів. 
у загальному випадку пакет статичної структурної моделі може бути 
представлений у вигляді однієї або декількох діаграм класів. Декомпозиція 
депого подання на окремі діаграми виконується з метою зручності й графічної 
39 
ЧДТУ .231920.005 ПЗ 
ei:JYjl]liзauiї с:г"уктурних взаємозв'язків предметної області . При цьому 
" r.4flO"" енти д~аrрами відповідають елементам 
0 статичної семантично~··  модел і · 
tJодеЛЬ систем~. у свою чергу• повинна бути погоджена із внутрішньою 
c11'YJ('f)'Poю клас1в, що описується мовою UМL. 
iІ'r-'"' ac (class) у мові UМL служ ить длЯ позначення безт.ч.1  об' єкт1· в, які 
,.,в~оть однакову структуру• поводженням і відносинами з об'єктами з інших 
tсJІІ1с.1 в. Графічно клас зображується  У вигляд~•  прямокутника, що додатково може  
бутt' разділеннй горизонтальними лініями на розділи або секції. у цих розділах 
• І 
,_,0)1()'Ть вказуватися ІМ я класу, атрибути (змінні) і операції (методи). 
Обов'язковим елементів позначення класу є його ім'я . На початкових 
ef8JIIIX Розробки діаrрам_и окремі класи можуть позначатися простим 
пр.моJСУТНИКОМ із вказівкою тільки ім'я відповідного класу. у міру пророблення 
0кремих компонентів діаграми опису класів доповнюються атрибутами і 
оnераuіями.Передбачається, що остаточний варіант діаграми містить найбільш 
nовкий опис класів, які складаються із трьох розділів або секцій. Іноді в 
позначеннях класів використовується додатковий четвертий розділ, у якому 
приводиться семантична інформація довідкового характеру або явно вказуються 
вкняrкові ситуації. Ім'я класу повинне бути унікальним у межах пакета. що 
описується деякою сухупністю діаграм класів (можливо, однією діаграмою). 
Воно вказується в першій верхній секції прямокутника. 
На додаток до загального правила найменування елементів мови UМL, 
ім'я класу записується по центрі секції ім'я напівжирним шрифтом і повинне 
починатися із заголовної букви. Рекомендується як імена класів використовувати 
іменники, записані по практичних міркуваннях без пробілів. Необхідно 
пам'ятати, що саме імена класів утворять словних предметної області при ООАП. 
40 
ЧДТУ.231920.005 ПЗ 
у першій секції позначення класу можуть перебувати посилання н а 
,~ар 111і шаблони або аn",".•,І.-.' _актН І·  класи, в.щ  яких утворений.  дании- клас 1•  
piJlr1o siJIUO, від яких він успадковує власти • й 
вост~ методи. 
у цій секції може приводиТИся інформація про розроблювача даного 
J(J1acY й статус стану розробки, а також можуть записуватися й інші загальні 
sJІІІС'fІ{вості цього класу• що мають відвошеяня до інших класів діаrрами або 
С'fЗНдартНИХ елементів мови UМL.Клас може не мати екземплярів або об'єктів. 
у w,or.fY випадку він називається абстрактним класом, а для позначення його ім'.я 
ІJІfІ'ористовується похилий шрифт (курсив). у мові UМL прийн.ята загальна 
уrода про те, що будь-яхи:й текст, що ставиться до абстрактного елемента. 
записується курсивом. Дана обставина є семантичним аспектом опису 
sідJІовіднИХ елеменrів мови UМL. 
У проrрамі розробки гри може бути безліч класів, таких як: 
_ класи ігрових об'єктів, такі як гравець, вороги, предмети та ін. 
_ класи рівнів та рівневих елемеtпів, такі як платформи, пастки, двері 
тощо. 
_ класи користувача іtперфейсу, такі як меню, кнопки і т.д. 
_ класи ігрового двигуна, що відповідають за обробку ігрової логіки та 
фізики. 
- класи для роботи зі звуком та графікою, такі як класи для завантаження 
та обробки аудіо- та відеофайлів. 
Діаrрама класів може відобразити зв'язки між клас~ їх атрибути та 
методи. Наприклад, класи ігрових об'єктів можуть мати спільний батьківський 
клас "GameObject", .який містить основні методи та атрибути для всіх ігрових 
об'єктів. 
1 Клас рівнів та рівневих елементів: 
41 
> 
чдТУ.231920.005 ПЗ 
методи для створення та управління рівнями: ці методи можуть 
дозволяти розробникам створювати нові рівні. завантажувати 
рівні з файлів або мережі, зберігати та відновлювати прогрес 
гравця між рівнями, налаштовувати параметри рівнів і т.д. 
атрибути рівн.я: класи рівнів та рівневих елементів можуть мати 
атрибути, що визначають їх розмір, положення, фонове 
зображення, складність, кількість ворогів або інших об'єктів, які 
присуmі на рівні. 
2 Клас інтерфейсу користувача: 
методи для відображення елементів інтерфейсу: ці методи 
можуть дозволяти відображати різні елементи, такі як кнопки, 
текстові поля, індикатори прогресу, ігрові панелі тощо на екрані. 
методи для обробки введення користувача: класи інтерфейсу 
користувача можуть містити методи, яхj реагують на введення 
користувача, такі як натискання кнопок, переміщення курсора 
миші, торкання на екрані тощо. 
З Класи ігрового движка: 
Методи оновлення ігрової логіки: Ці методи виконуються на 
кожній ітерації головного ігрового циклу і відповідають за 
оновлення стану гри, рух об'єктів, перевірку умов виграшу або 
поразки, обробку взаємодій між об'єктами тощо. 
Методи розрахунку фізики: Ігрові двигуни можуть містити 
методи, які модетоють фізичні закони, такі як рух об'єктів, 
rравітація, столкнувшись зі С1інами або іншими об'єктами. 
4 Клас для роботи зі звуком: 
Методи для завантаження аудіофайлів: Ці методи дозволяють 
завантажувати аудіофайли з різних джере~ таких як локальні 
42 
ЧДТУ.231920.005 ПЗ 
файлові системи, мережі або вбудовані ресурси гри. Завантажені 
аудіофайли можуть бути збережені в пам'яті для подальшого 
відтворення. 
Методи для відтворення аудіофайлів: Ці методи дозволяють 
відтворювати завантажені аудіофайли. Вони можуть керувати 
різними аспектами відтворення, такими як гучність, швидкість, 
позиція звуку У просторі тощо. Також можуть бути дос-тупні 
функції паузи, відтворення з нового місця, зупинки та іншj 
операції. 
5 Класи для роботи з графікою: 
Методи для завантаження відеофайлів: Ці методи дозволяють 
завантажувати відеофайли з різних джерел, подібно до 
завантаження аудіофайлів. Завантажені відеофайли можуть бути 
збережені в пам'яті для подальшого відтворення. 
Методи для відтворення відеофайлів: Ці методи дозволяють 
відтворювати завантажені відеофайли на екрані. Вони можуть 
керувати аспектами відтворення, такими як розмір вікна, 
відображення в повноекранному режимі, контроль програвання 
(пауза, відтворення з нового місця, зупинка) тощо. 
Загалом, класи для роботи зі звуком та графікою дозволяють програмі 
зчитувати, завантажувати та відтворювати аудіо- та відеофайли, що додає 
звукові та візуальні ефекти до гри. 
Кожен клас може мати свої методи та атрибути, а також зв'язки з іншими 
, 
класами у програмі. Діаграма класів може допомогrи у розумінні структури 
програми та її компонентів [12] . 
43 
чдТУ.23 l 920.005 ПЗ 
··-- -- --- -...... 
-...... 
-· 
Рисунок 2.2 - Діаrрама класів 
2.3.2 Діаrрами пакетів 
Діаграма пакетів (Package diagram) _ це тип діаrрами UМL, який дозволяє 
відображати організацію та залежність між пакетами програмного забезпечення. 
Пакет - це група пов'язаних елементів програми, такі як класи, інтерфейси, 
перерахування, інші пакети тощо. Діаграма пакетів дозволяє організувати 
елементи програми в логічні блоки для зручнішого управління проектом та 
розуміння його структури. 
На діаrрамі пакетів пакети представлені у вигляді прямокутників, яю 
можуть бути вкладені один в одного та пов'язані відносинами залежності, 
агрегації, успадкування тощо. Для кожного пакета можна вказати його ім'я, 
атрибути та методи, а також залежність від інших пакетів та елементів програми. 
Діаrрама пакетів може бути використана для опису архітектури 
проrрамного забезпечення, а також для документації та комунікації між 
розробниками. Вона допомагає побачити зв'язки між компонентами програми та 
логічно розділити її на модулі для зручності супроводу та розширення.На даній 
діаграмі представлені пакети, які можуть бути використані для розробки гри 
представленій в бакалаврській роботі: 
44 
ЧДТУ.231920.005 ПЗ 
Гра - це пакет програмного забезпечення, який містить різноманітні класи 
JСомпоненти, необхідні длЯ реалізації ігрового процесу. Він складається з 
18 
piзtitD< модулів, які забезпечують роботу ігрового движка, обробку графіки та 
звУJСУ• управління введенням користувача, фізичну моделювання та створення 
itrrepфeйcy користувача. 
Пакет Graphics включає класи та компоненти, необхідні дл.я роботи з 
графікою у грі. Він надає можливості для відображення 2D та 3D графіки, роботи 
3 текстурами та анімацією. Цей пакет дозволяє реалізувати візуальну складову 
гри і створити привабливі графічні ефекти. 
Пакет Audio забезпечує функціональність для роботи зі звуком у грі. Він 
8ключає класи для відтворення музичних та звукових ефектів, керування 
гучністю та інші аспекти звукового середовища гри. Цей пакет дозволяє 
С1'ВОРИТИ насичений аудіо-супровід для ігрового досвіду. 
Пакет lnput включає класи та компоненти, які обробляють введення від 
JСористувача. Він дозволяє ігровій програмі взаємодіяти з різними пристроями 
введення, такими як клавіатура, миша, джойстик. Цей пакет забезпечує обробку 
вхідних сиmалів і їх трансформацію на відповідні дії в грі. 
Physics - це пакет програмного забезпечення, який містить класи та 
компоненти, необхідні для роботи з фізичним моделюванням у грі. Він 
забезпечує можливість симуляції руху об'єктів у грі, включаючи різноманітні 
аспекти фізики, такі як рух, колізії та сили. 
Завдяки класам та компонентам, доступним у пакеті Physics, розробники 
можуть втілити реалістичну фізичну поведінку об'єктів у грі. Наприклад, вони 
можуть задавати параметри об'єктів, такі як маса, форма та матеріал, і 
використовувати ц1 параметри для розрахунку їх руху та взаємодії з іншими 
об'єктами. 
UI (User Interface) - це пакет, який м~стить класи та компоненти, 
призначені для створення інтерфейсу користувача в грі. Він надає засоби для 
створення різноманітних елементів інтерфейсу, таких як меню, кнопки, текстові 
ПОЛЯ та інші. 
45 
ЧДТУ .23 1920.005 ПЗ 
- .. 
Рисунок 2.3 - Діаграма пакетів 
2.4 Архітектурне ороектуванн_а 
2.4.1 Діаграма комnоненrів 
ДіаІl)ама компонентів - це діаграма, яка відображає струК1УРУ системи та 
11 компонентів, а також зв'язки та залежності між ними. Діаграма компонентів 
використовуєrься для моделювання системи та її архітектури, щоб розумjти, j[J( 
різні компоненти системи взаємодіють один 3 одним і як вони можуть бути 
разроблені та реалізовані. У діаграмі компонентів компоненти зазвичай 
представлені прямокуmи:камн зі своїми іменами, а зв'язки між компонентами 
позначаються лініями, які можуть мати різні атрибути, такі як напрямок, тиn 
тощо. Діаграма компонентів може використовуватися .як засіб комунікації між 
разробниками, а також я:к документування та аналjзу системи. 
Правила складання діаrрами компонентів можуть змінюватись в 
залежності від використовуваної методологїї або стандар,у, однак деякі основні 
правила включають: 
Ідентифікація компонентів: необхідно ідентифікувати всі компоненти 
системи та призначити їм унікальні імена, які чітко визначають їхню 
функціональність. 
Визначення інтерфейсів: для кожного компонента слід визначити йоrо 
інтерфейси, тобто те, що компонент може надавати іншим компонентам 1 як 
може використовувати інтерфейси інших компонентів. 
Встановлення зв'язків: на діаграмі компонентів слід показати зв'язки між 
компонентами, включаючи залежності, взаємодії та взаємодію через інтерфейси. 
Використання стереотип1в: слід використовувати стереотипи для 
позначення типу компонента або його ролі у системі. 
46 
• 
ЧДТУ.231920.005 ПЗ 
Подання конфігурації: якщо система включає кілька екземплярів 
J(Оr,{JІонентів або різні конфігурації системи, слід показати їх на діаграмі. 
Дотримання стандартів методологій: при складанн• діаграми 
"0млонентів слід дотримуватись стандартів і методології, прийняті в організації 
або в іJІдУстрії. 
Документування діаграми: слід підтримувати документацію та опис 
діаJl)ЗМИ компонентів, щоб забезпечити розуміння системи та її архітектури 
іfІ11ІИМЯ розробнихами та зацікавленими сторонами. 
Ці правила допомагають забезпечити точність та зрозумілість діаrрами 
1<оfdІ)оНеНТІВ, що дозволяє ефективно проектувати, реалізовувати та 
супроводжувати систему. Діаграма компонентів - це діаграма, яка відображає 
різні компоненти системи та їхню взаємодію між собою. Для розробки гри, 
діаграма компонентів може вюпочати такі компоненти: 
Ігровий двигун: це основна компонента, яка керує всією логікою гри, 
відображенням графіки та взаємодією з користувачем. Цей компонент може 
включати підкомпоненти, такі як фізичний двигун, систему частинок і т.д. 
Графіка: це компонент, який управляє відображенням графіки у грі. Вона 
може містити підкомпоненти, такі як система освітлення, система візуалізації і 
т.д. 
Звук: це компонент, який керує звуковими ефектами та музикою у грі. 
Вона може містити підкомпоненти, такі як система звукових ефектів, система 
музичного відтворення і т.д. 
Штучний інтелект: це компонент, який управляє поведінкою штучного 
інтелекту в грі. Вона може містити підкомпоненти, такі як система прийнятrя 
рішень, система штучного інтелекту і т.д. Мережа: це компонент, яхий управляє 
взаємодією rравців через мережу. Вона може містити підкомпоненти, такі як 
система синхронізації ігрового стану, система обміну повідомленнями і т.д. [13]. 
Інтерфейс користувача: це компонент, який керує відображенням 
інтерфейсу користувача у грі. Вона може містити підкомпоненти, такі як система 
47 
ЧДтУ.231920.00S ПЗ 
снстема налаштувань і т.д. База 
~eJDO• . даних: це компонент який управляє 
ігаНJVІМ даних rри, таких як збереже . . ' 
9беР ~ . 81 •rри, налашrування гри і т.д. 
розr-.... ни-к 1нструменти: це 
. компонент, яки.й керує інструментами 
-лnню<а. яю вихористовуЮТЬся 
pO:JP"- • дЛЯ СТВорення та налагодження гри. Вона 
е ,.uСТИТИ nІдКомnоненти такі 
rJO)J( • ' як система управління версіями, система 
А.....,д,кення 1 т.д. 
11aJ1iu w 
кожен із цих компонентів мо 
же взаємодіяти з іншими компонентами У 
cJt".'. •.- -мі , що дозволяє створювати повн . . 
оц1нну гру. 
'NаЬіміо,, 
~~4-l(eyt)oa...;...__rdiМause;;;.;,;:;:=.,Pad~►_. 
User 
НDD 
IJNel 
Рисунок 2.4 - Діаграма компонентів 
2.4.2 Розгортання програмної системи на апаратних засобах. діаграма 
розгортання 
Діаграма розгортання - це д1аrрама UМL, яха використовується для 
моделювання фізичної архітектури системи та її компонентів на пристроях та 
серверах. Діаграма розгортання дозволяє відображати, як компоненти системи 
розгортаються та працюють на різних пристроях та серверах у мережі. 
48 
ЧДТУ.231920.005 ПЗ 
Діаграма розгортан.ня вкл-ю 
. чає пристрої та сервери, а також компоненти 
,retAИ яю розгортаються на . 
cttc ' . . них. Компоненти представлені у вигпяд• 
Jd0кутниюв, як1 можуть бути ро . . . • 
11Р" , • зташована на пристроях, пов'язаних л1н1ями 13 
.. ченням зв язк1в та залежностех . 
383n3 n МLЖ КОМПОНеНтами. 
Діаграма розгортанн.я мо . -
же 6 утн використана дт1 розуміння фазичноа 
•тектУР" системи та її комп . 
аР"а онентав, длЯ планування інфраструктури та 
rо...-rйнЮІ, а також дтu1 аналізу . в 
раз у•-- та оптимазації продуктивності системи. она 
)І(е допомогти розробникам та · t,tO Інженерам зрозуміти, як компоненти системи 
flP",".", rюють на різних пристроях та серверах, а також як керувати ресурсами та 
,..аспrrабувати систему в майбутньому. 
Діаграма розгортання дтu1 розробки гри може включати такі компоненти і 
приС1Рої: 
Клієнтський комп'ютер: пристрій, на якому запускається клієнтська 
qастина гри. Клієнтський комп'ютер може бути як персональний комп'ютер, і 
мобільний пристрій. 
Сервер гри: пристрій, на якому запускається серверна частина гри. Сервер 
гри забезпечує обробку запитів від клієнтів та синхронізацію ігрових станів між 
)(Лієнтами. 
База даних: це пристрій, на якому зберігається інформація про гравців, їх 
досяmення, статистику та інші параметри гри. 
CDN: це мережа доставки контенту, яка використовується для 
прискорення завантаження ігрових ресурсів, таких як текстури, звуки та інші 
медіа-файли. 
Сторонні послуги: це послуги, які можуть використовуватися в грі, такі ях 
послуги аутентифікації, платіжні системи, соціальні мережі та інші. 
На діаграмі розгортання розробки гри можна показати, як компоненти 
пов'язані друг з одним і яких пристроях вони розгортаються. Наприклад, 
клієнтський комп'ютер може взаємодіяти з сервером гри через інтернет, а сервер 
гри може вихористовувати базу даних для зберігання інформації про гравців та 
їх досягнення. Мережа доставки контен'І)' може використовуватися для 
49 
111111 
ЧДТУ.231920.00S ПЗ 
J(оренWІ завантаження jгn,,,.вих . б 
11J)lfC • yv ресурс1в, 8 сторонні ПОСЛУГИ МОЖ)'ТЬ ути 
itt-rerposaнi в гру для покращення її функціональності. 
Діаrрама розгортання длЯ 
· розробки гри може допомогти розробникам 
міти фізичну архіте".".".' . 
:Jр0ЗУ J  РУ гри, покращити продуктивн1сть та 
. .-бованість системи а ....,.,. без . 
t,tacw•- ' ·-0ж за nечити бшьш ефективне плануваНЮІ 
іtfфраструктури та розгортання гри. 
- . . . .. . .. - - ... . . . 
Рисунок 2.5 - Діаграма розгортання апаратних засобів системи 
2. 5 Моделюванн11 поведінки системи 
2.5.1 Діаrрама ДUUІЬності 
Діаграма діяльності - це одна з діаграм у мові UМL (Unified Modeling 
Language ), яха використовується для моделювання бізнес-процесів, алгоритмів 
або інших процесів, які можуть бути розбиті на послідовність дій чи кроків. 
Діаrрама діяльності складається з вузлів, що представляють дії або процеси, та 
С1Ріпок, які показують порядок виконання цих дій. 
Діаграма діяльності може використовуватися для опису складних 
процесів, які включають безліч дій і прийнятих рішень. Вона може допомогти 
розробникам та бізнес-аналітикам краще зрозуміти процес та виявити можливі 
проблеми у його виконанні. Діаrрама діяльності також може бути використана 
для опису алгоритмів програм чи бізнес-логіки. 
Основні елементи діаrрами діяльності включають: 
Початковий вузол: це точка початку діаграми діяльності, що означає 
початок процесу. 
Дії: це вузли, які становлять виконання конкретних дій чи завдань. 
50 
ЧДТУ.231920.005 ПЗ 
рішення: це вузли, які репрезентують . . 
р1зн1 можливі шляхи виконання 
ссу 8 залежності від прийнятих • 
,rp011 р1шень. 
зв'язки: це стрілки, які пок 
взують порядок виконання дій чи прийнятих 
ріІ.1JеНЬ, 
Фінальний вузол: це точк 
а завершення діаrрами діяльності, що означає 
:JІІСіfІЧеННЯ процесу. 
Діаrрама діяльності може б . 
ути використана для опису різних процес1в, 
яаJ1РИКЛад процесу розробки nроrрамного забезпечення, процесу виконання 
0 вленWІ в інтернет-маrазнні бо 
заМ а процесу оформлення кредиту в банку. Вона 
~о)І(е допомоn-и оптимізувати процеси, покращити їх ефективність та зменшити 
кількість помилок при виконанні процесу. 
На діаграмі розробки гри можуть бути показані основні кроки, які можуть 
бути виконані у процесі розробки гри: 
Визначення вимог: визначення того, які функції та можливості мають 
бути включені до гри. 
Проектування ігрового світу: створення концепції гри, визначення 
irpoвoro світу, геймплей та механіки гри. 
Розробка архітектури: проектування архітектури гри, вІСJDОчаючи вибір 
платформи та технологій, які будуть вихористовуватись у розробці. 
Розробка ігрових компонентів: створення ігрових компонентів, таких ях 
персонажі, рівні, сюжет, інтерфейс і т.д. 
Тестування та налагодження: перевірка гри на наявність помилок, 
налаrоджеНЮІ коду та виправлення виявлених проблем. 
Реліз та підтримка: випуск гри на ринок та її підтримка, включаючи 
виправлеНЮІ помилок та додавання нових функцій та можливостей. 
Діаrрама діяльності може допомогти розробникам ігор краще розуміти 
процес розробки та оцінювати просування розробки гри у часі. Вона також може 
51 
чдтУ.231920.005 ПЗ 
Jlonol'doгrи олтим:азувати процес розробки, покращити ефектнвні<;ТЬ та зменшити 
idlfЬ"jcn, помилок шд час виконання процесу. 
АJJГОритм роботи проrрами rри м,ожна описати за допомогою нас;упних 
iq,ordв, вюсористовуючи діаrраму діяльності: 
J Управління rравцем: 
rpa очікує введення від користувача. 
користувач здійсRЮє дії за допомогою клавіш керування. 
2 Пересування по ігровому полю: 
rpa отримує введення від користувача. 
перевіряється введення клавіш керування. 
якщо користувач натиснув клавішу для руху, гравець 
переміщується відповідним чином по ігровому полю. 
3 Взаємодія з об'єктами за допомогою клавіш керування: 
rpa отримує введення від користувача. . 
перевіряється введення клавіш керування. 
якщо користувач натиснув клавішу взаємодії, гравець взаємодіє з 
об'єктами, змінюючи їх стан або виконуючи певні дії. 
4 Зміна стану ігрового рівня: 
гра перевіряє умови для зміни стану ігрового рівня. 
яхщо умови виконуються~ стан рівня змінюєтьс.я, напри:клад, 
досягнення нас,упноrо рівня або закінчення гри. 
5 Виведення інформації про помилку: 
Під час виконання програми можуть виникати помилки або 
несправності, які потрібно обробити. 
52 
ЧДтУ.231920.005 ПЗ 
Гра перевіряє наявність помилок UUUІxoм аналізу різних умов або 
відповідних змінних. 
6 виведення результатів на екран: 
Після закінчення гри або досягнення певних умов для виведення 
результатів, гра виконує та:кі дії: 
Обчислює остаточні результати гравця, такі як зароблені 
бал.и, час, рівень досяmень тощо. 
Форматує ці результати в зручний для відображення 
вигляд, яІСИА може включати текст, числа, графічні 
елементи або комбінацію них. 
Виводить результати на екран грального інтерфейсу або 
окремого вікна, щоб гравець міг побачити сво1·· дося гнення 
та оцінити результат гри. 
Рисунок 2.6 - Діаграма діяльності 
53 
.. 
чдтУ.231920.005 ПЗ 
2.5.2Діаrрама послідовності 
Діаграма послідовності (Sequence d. . . . 
iagram)- це один 1з тишв д1аrрам UМL 
•f1ie d Modeling Language), ЯІ<Ий вик0 ... 
(1)111 РНстовуєrься для візуалізації взаємод11 
об'єктами або компонентами в сист . . 
~і)І( . ем1 в час1. 
діаграма посл1довностj показує . 
взаємодію об'єктів у систем~, 
ставтоочи їх у вигляді вертихал . . 
оред ьних ЛІНІЙ, які називаються "життєвими 
. " які з'єдпуються етn· . 
ліJІJю,иt ' --..,mками~ що показують порядок передач~ 
11o;s1-1оМЛеИЬ Мl
. Ж об' єктами В Часі · Дія-m<>н . • . 
..,..,..а може тахож м1стити р1зю елементи, 
-raJ<1 Я1< активації, обмеження та умови. 
Діаrрами посліцовності зазвич -
ав використовуються для моделювання 
сuенарїїв використання, які описують тиnові взаємодії між користувачами та 
сіfстемою або між різними компонентами системи. Вони допомагають 
разрйбнm<ЗМ зрозуміти взаємодію об'єктів у системі та покращити її архітектуру, 
8 також забезпечити більш ясне розуміння вимог до системи. 
На діаrрамі послідовності зображуються тільки ті об'єкти, що 
безпосередньо беруть участь У взаємодії і не показуються можливі статичні 
acouiauiї з іншими об'єктами. Діаграма послідовності має два виміри. Одне - у 
в11.ді вертикальних ліній, кожна з яких зображує лінію життя окремого об'єкта, 
що приймає участь У взаємодіі Графічно кожен об'єкт зображується 
прямокутником і розташовуєrься у верхній частині своєї лінії життя. У середині 
прямокутника вказуєrься ім'я об'єкта й ім'я класу, розділені двокрапкою. При 
w,ому весь запис п1дкреслюється, що є ознакою об'єкта, який являє собою 
екземпляр класу [14]. 
Другий вимір діаграми послідовності - вертикальна тимчасова в1сь, 
спрямований зверху вниз. Початковому моментові часу відповідає сама верхня 
частина діаІl)ами. При цьому взаємодії об'єктів реалізуються за допомогою 
повідомлень, що посилаються одними об'єктами іншим. Повідомлення 
.. .. t • • 
зобрЗ)І\.-уються у виді горизонтальних стр~лок з ІМ ям пов1домлення I так само 
54 
,..... 
ЧДтУ.231920.005 ПЗ 
ioJ01'Ь порядок за часом свого в 
у-rв<>Р • • • иникненн.я. Іншими словами, повідомлення, 
_,,, ,nоВЗНІ на д1аrрам1 nослідовноеті · 
р0з•- вище, ініціюються раніш тих, котр~ 
_,.,110вані нижче. При цьому м . б • 
р0з1...- асшта на осі часу не вказується, осюльки 
'nmаМЗ послідовності моделює лише . V 
д1111 r . . . · тимчасову упорядкованість взаємод1и 
'(1fffY " 
"ран1ше-шзн1ше . 
Лінія житrя об'єкта (оь·~ ect І ifeline) зображується пунктирною 
st"y"··'· "кальною лінією, асоційованою З єдин. им об'єктом над1.а rрам1.  ПОСЛІ.Д ОВНОСТІ·.  
Лінія )І(J{ТТЯ служить для позначення періоду часу, у плині якого об'єкт існує в 
снстемі і, отже, може потенційно брати участь у всіх її взаємодіях. Якщо об'єкт 
ісfІУЄ в системі постійно, то і його лінії життя повинна продовжуватися по всій 
fJJІOIWfHЇ діаrрами послідовності від самої верхньої її частини до самої нижньої. 
Окремі об'єкти, виконавши свою роль у системі, можуть бути знищені 
(зруІtНовані), щоб звільнити займані ними ресурси. Для таких об'єктів лінія 
)КІfІ11І переривається в момент його знищення. Для позначення моменту 
знищення об'єкта в мові UМL використовується спеціальний символ у формі 
датинської букви Х. Нижче цього символу пунктирна лінія не зображується, 
оскільки даного об'єкта в систем.і вже не існує, і цей об'єкт повинний бути 
виключений із усіх наступних взаємодій. 
У процесі функціонування об'єктна-орієнтованих систем одні об'єкти 
можуть знаходиться в активному стані, безпосередньо виконуючи визначені дії, 
або в стані пасивного чекання повідомлень від інших об'єктів. Для явного 
виділення подібної ахтивності об'єктів, у мові UМL застосовується спеціальне 
поwrrтя, що одержало назву фокуса керування (focus of control). Фокус 
керування зображується у формі витягнутого вузького прямокутника, верх.ня 
сторона якого позначає початок одержання фокуса керування об'єкта (початок 
активності), а її нижня сторона - закінчення фокуса управління (закінчення 
активності). Цей прямокутник розташовується нижче позначення відповідного 
55 
ЧДТУ .231920.005 ПЗ 
_.,-ra і r.1оже зам1няти його ліноо· ~
об'Q'·- ...... •~ . якщо на всьому її протяз1 він є 
l!J(ftl ptfHM · 
дjаrрама послідовності розроб · · 
кв грн детальніше описує взаємод1ю м~ж 
JCOrdJJof!eнтaм:и гри та діі, які відбуваються в процесі гри: 
1 Гравець запускає гру: 
Гравець запускає nporpяuv гри -
- ..J  на своєму пристро~. 
2 Гра завантажується та відображається на екрані: 
гра виконує процес завантаження, підготовки ресурсLВ та 
ініціалізації грального двиrуна. 
на екрані з'являється ігровий інтерфейс, який може включати 
головне меню, нал8Ш'Ту8ан]ut або початкову сцену rри. 
3 Гравець починає гру, натискаючи на кнопку "Старт": 
Гравець взаємодіє з і.rровим інтерфейсом та натискає на кнопку 
"Старт" або подібний елемент, щоб розпочати rpy. 
4 Гра запускається, і гравець взаємодіє з ігровим світом: 
гра активує головний ігровий ЦИЮІ, який постійно оновлює стан 
rри та забезпечує відображення на екрані 
гравець взаємодіє з ігровим світом, виконуючи різні дu, такі як 
рух, стрЇ.JumІІя, взаємодія з об'єктами тощо. 
ці дії можуть бути виконані за допомогою клавіш на клавіатурі, 
кнопок на екрані, рухів джойстика або інших вхідних пристроїв. 
5 Компонент rрн, що відповідає за керування rравuем, обробляє вхідні 
си:mали та оновлює став гравця: 
Компонент rри, відповідальний за обробку вхідних сиrнашв, 
отримує введення від корис,увача. 
Це лише один приклад діаrрами послідовності розробки rри. Реальна 
діаграма може бути складнішою, залежно від конкретних вимог до rри та її 
архітектури. 
56 
ЧдтУ.231920.ООs ПЗ 
[- - -] 
! 
' 
•····· ·-·- -·-····· 
---...... _ -- , 
~·---~ -····-·-·· 
Рисунок 2. 7 - Діаграма послідовності 
2.s.з Діаграма комунікаціі 
Діаrрама комунікації (Communication diagram), також відома як діаrрама 
ІСолаборації (CollaЬoration diagram) є ОднИМ з типів діаrрам UМL (Unified 
мodeling Language) , яхий використовується для візуаmзації взаємодії між 
об'єктами або компонентами в системі. 
Діаrрама комунікації показує об'єкти або компоненти системи, яю 
взаємодіють один з одним, та повідомлення,. які вони передають один одному під 
час виконання певної операції чи завдЗНЮІ. Діаrрама відображає об'єкти у 
• t • 
вигпяді прямокутників, яю з єднуютьея стрІЛКами, що вказують напрямок 
передачі між об'єктами. 
Діаrрами комунікації корисні для моделювання взаємодії між об'єктами 
чи компонентами в системі, а також для розуміння та оптимізації роботи 
системи. Вони можуть використовуватися для моделювання різних сценаріїв 
вихористання, відображення потоку даних або відображення зв'язків між 
об'єктами [15]. 
На відміну від послідовності діаrрам, діаграми комунікації не описують 
• • • • t • 
порядок передаЧІ повщомлень, а швидше показують вс1 можлив1 зв я.зки м1ж 
об'ЄА-тами в системі у вигляді графа. Це може бути особливо корисним для 
57 
.. 
чдТУ .231920.005 ПЗ 
~,,~ ,с систем, в яких об'єкти можуть взаємодіяти в різних сценаріях 
»стаиия. 
"''"ор у разі розробки гри для вивчен ня та бл иц~·  множенЮІ, діаграма комун1· каu·1·1·  
вІіглядати так: 
r,t о-к-е J-{a •v • • 
ЦІИ д1аграм1 показано взаємодію між гравцем, інтерфейсом 
11С1)'вача, компонентом генерації питань, компонентом перевірки відповідей "оР . 
f9 "оfdJІОИеНТОМ керування Ігровим процесом. 
Гра.веuь починає гру за допомогою інтерфейсу користувача. Компонент 
rевераUії rurnuiь генерує випадкові пнтанн.я з таблиці множенЮІ та відображає їх 
Jt& iJrfCpфeйci. Гравець вводить відповіді на запнтакн.я, і компонент перевірки 
відJ'Іовідей перевіряє правильність відповідей та дає зворотний зв'язок. 
•'"онент управління ігровим процесом контролює хід гри, підраховує 
!(о,..• • 
·.пь~dСТЬ правильних відповідей та відображає результати гри на екрані . 
~ V 
кожен компонент або об'єхт у цій діаграмі представлении 
ор~r,t0хутнихом, і стрілки вказують напрямок передачі повідомлень між 
об'є~сrаМ:И· На діа.rрамі також вихористані стереотипи для позначенНJІ конкретних 
'(1U1iB JСомлоневтів, таких JDC "<<generator>>" ДЛJІ компонента генерації питань та 
•<<contr01ler>>" для компонента управління ігровим процесом. 
На рисунку наведено приклад діаграми комунікації.  
- - . . . . . 
J8Cll]mtil 
• * 
~ ~ r Ім'І 18 І ,,М ~ТІТ • 
'Т ,-
г--- ~--"' 
Рисунок 2.8 - Діа.rрама комунікації 
58 
ЧдтУ .23 1920.005 ПЗ 
z.5.4 Діаграма скінченного автомату 
Діаrрама кінцевих автоматів (Finjte State Масhіле, FSM) - ue графічне 
"ке описує поведінку системи . . . · х 
,пен~• " У терм1нах стан1в, переход1в з-пом1ж ни 
~;одііt, JІJCi виJСЛихають ці переходи. FSM складастьс,r з набору станів, переходів 
1' ,11iit, . . • • 
стан - це умова чи ситуацUІ, У JІJCiA перебуває система у певннА час . Подtя 
-~з овяі111НіА вплив або сиrnал, що t.соже призвести до зміни стану системи. 
rtepe"iд- ue зміна.стану системи у відповідь подій. діJІ _ц е onepaцi.R або фун,сція, 
е~сJСо~єтьс• mд час перехо.цу з одного стану до іншоrо. 
ІР . . . 
Діаграма юнцевнх автомат~в скла.дасться з вершин (станів), стр~лок 
(аере"одів) та міток на переходах, JІкі позначають події або умови, необхідні для 
(ІСре,<ОдУ ДО НОВОГО стану· 
Приклад діаграми кінцевих автоматів може бути представлениА дл,1 
rтp11CJPOIO, .кюt має дві кнопки: кноmсу "увіюсненНJІ" та кнопку "вимнканНJІ". 
сsстема має два стани: "ввішснено" та "вимкнено". При натисканні кRоnкн 
•уеі"JСНеКШ" система переходкть у стан "ввімкнено", а при натискан.ні кнопхи 
•вІ{М}ІІ(8.НЮ" система переходить у стан "вимкнуто". 
Діаrрама кінцевих автоwатів дru1 гри на вивченш таблиці множення може 
екrл~JІЗТИ приблизно так: 
• 
--
Рисунок 2.9 - Діаrра.'!а скінчених автомаТІв 
На цііі діаграмі є три стани: 
59 
"" 
ЧДТУ .231920.005 ПЗ 
- поча11Совий стан. kОЛИ гра ще розпочато; 
- стан питаmu1, kОЛ'И гравцеві задається питання про таблицю множення; 
_ стан відповіді. kоли гравець вводнТЬ свою відповідь та отримує 
у;n,ТЗ1"-
ре' перехід між станами здійснюється при натисканні на кнопки, яю 
~я на екрані гри. У початховому ставі Jl)З.Вцеві пропонується розпочати 
,118"0 • • 
11а'fМСІ:І)'ВWИ в~дловІДН)' кнопху. Пicrur цього гравець переходить у стан 
rPY• 
~• де йому ставиться питання таблиці множення. Як тільки гравець введе 
відповідь і натисне кнопку "Перевірипt", гра переходить у стан відповіді, 
сВОJО 
ІІsодяться результат- правильно чи ні відповів гравець. Після цього гравець 
дев 
~oice або nереЙТИ до наступного питанм або закінчити гру. 
таким чином, ді811)11Ма хівцевих автоматів дnJІ гри на вивчення таблиці 
.~но•ення допомагає краще зрозуміти, яхі стани є у грі та як між ними 
""сНJОЮТЬСЯ переходи. Це може допомогrи розробникам ігор у більш 
, 3дІn 
ефеІ('1'НВНЇЙ розробці та налагодженні ігрового процесу. 
60 
ЧДтУ .23 1920 005 ПЗ 
03роБКА т А ТЕСfУвАН:ня п · 
Jf РОГРАМНОГОЗАБЕЗПЕЧЕННЯ 
.", . 1 розробка програмного kO"..". 'n 
лtксу. 
'І . J. I Qбrрунтування вибору засоб· . 
.J ІВ J)еал~зац•-
б 11. 
t]nit)' - агатоплатформовий . 
. . · •нетрумент дЛJІ розробки дво- та 
•~ІfРНИХ застосунюв та 1rop що п 
1111181 ' ра100є на операційних системах Windows і 
oS )(. 
Рисунок З .1 - Логотип комланії Unity 
Створені за допомогою Unity застосування працюють щд системами 
Windows, OS Х, Android, Apple iOS, Linux, а також на гральних консолях Wii, 
PlayStation 4 і ХВох Оnе.Є можливість створювати інтернет-застосунки за 
допомогою спеціального під'єднуваного модуля для браузера Unity, а також за 
допомогою експеримеJПаЛЬної реалізації в межах модуЛJІ АdоЬе Flash Player. 
Застосування, створені за допомогою Unity, підrримують DirectX та 
OpenGL. 30 Редактор Unity має простий Drag & Drop інтерфейс, який легко 
налаштовувати, що складається з різних вікон, завдяки чому можна проводити 
налагодження гри прямо в редактор~. 
Рушій підтримує три сценарних мови: С #, JavaScript (модифікація). 
Проект в Unity ділиться на сцени (рівні) - окремі файли, що містять свої ігрові 
світи зі своїм набором об'єктів, сценаріїв, і налаштувань. Сцени можуть містити 
в собі ЯJС, об'єкти (моделі), тах і порожні ігрові об'єкти - тобто ті які не мають 
61 
чдТУ.231920.oos ПЗ 
. ()61єкти, в свою чергу міст 
о11еЛ'· ять набори k • 
r,, у об'єктів з видимо- омпонеНТJв, з якими і взаємодіють 
,iq,нrt11f· І геометрією також . 
еНТ Mesh Renderer, що роб _ за замовчуванНJІм присутюй 
".V-n ~otl • • ИТЬ ІХ МОД,.,.. -
...,,о ІХ видимою 
f aJ<OЖ Unity пщтримує фізику тве . . · 
РдНх ТІЛ I тканини фізику типу Ragdoll 
іркова лялька). У редакторі єси ' 
(r,Jl1' . . стема успадкувания об1єктів; дочірні об'єкти 
...rrь повторювати вс1 зм1ни познцj" 
буw · 1• повороту і масштабу батькjвськоrо 
rfjєtfl· 
скрипти в редакторі прикріплю 
• • • ЮТЬсJІ до об'єктів у вигляді окремих 
онент1в. При 1мпорт1 текстури в •й 
JCO~JJ • руш~ можна згенерувати аJрhа-канал, mip-
. 1· nonnaJ-map, J1ght-map, карту відоб 
р1вJІ , ражень, проте безпосередньо на модель 
...rvny прикріпити не можна - б . 
тeJC..,•;r Уде створено матер1ал, з яким буде 
прнзначеннlі шейдер, і потім матеріал прнкріпиться до моделі. 
Редактор Unity підтримує Н8ПИС8ННJІ і редаrувания шейдерів. Крім того він 
~icnrrь компонент дmr створення анімації, анімацію також можна створити 
попередньо в ЗDредакторі та імпортувати разом з моделлю, а потім розбити на 
файли. 
У Unity вбудована nідтримха мережі. Ігровий рушій повністю пов'•заний 
із середовищем розробки. Це дозволяє випробовувати гру прямо в редакторі. 
Має вбудований генератор ландшафтів. До того ж Unity безкоштовна для 
студентів та розробників початківців, також безкоштовні допоміжні 
інформаційні матеріали, я.хі допоможуть дати відповіді на різні заnитания що до 
розробкн [16]. 
3.1.2 Опис стр}'К1УРНОЇ ( функціональної) схеми 
Інформаційна система яВЛJІє собою набір деяких структурних компонентів, 
m, кожен в свою черrу, виховують певні дії чи несуть конхретний функціонал. 
Кожна з частин має свою характеристику та прюначення, має вузьку 
спеціалізацію. І робота всих компонентів, залежно від потреби та СИ1)'ації, 
складає роботу всієї інформаційної системи. 
•u .___ розМJ·щуються об' єкти в перпrій сцені відеогри 
ut&чe приведено як 
62 
ЧДТУ .231920.005 ПЗ 
Carne 
.., GG:::t) Dlrec::-
Canva:n•• Llght 
GG::))  Platfo 
Ptatf~ PNG_O 
G:) Ptatf PNG_'1 
G:) Platfo rrn PNG.JS 
G, Platfo rrn PNG_6 
G, О onn.PNG-9 
G:) Н anger fІarne pNG 
"°" ero PNG '1 
.....,su.n -
G:) EventSyst.ern 
Рисунок З. 2 _ Список об- , є -ктt. в в перmій сuеиі. 
~дає за налаmтуваиня вибраних об'єІ(Тів 
~е наведено вікно ЯІСе відлов· 
fS~ofJOJC ---
J'исуІІОК 3.3 - вікно калаDffУВЗН" об'єктів 
HJl)l('le на рисункУ відобра,t<еІІе вікІІо p,oject. яке nоказує всі комnоие~rrи 
проеюу. А саме в oanui лssets міс,,rrься всі комnоиеІffІ! rри (скрипти, rраФічкі 
об' ЄІСІ1І і т.д.) В oanui PaCkJISes .,;сrятьс• фізичні комnовеІffІ! для об' єктів- Т ш<ож 
'два вікна console де відображаєrься скрюrr вибраиоrо комnоиеJІ11'. Та 
Animation ві.юІо )VUI етвореИИЯ аиіМаnій [ І 7]. 
63 
ЧДТУ.231920.005 ПЗ 
"88 )8-
Рисунок 3.4 - Вікно складу проекту та пакетів даних 
з.1.3 опис лоrічної еsеми 
Логічна схема rри на вивчення таблиці множення може буrи такою: 
вибір рівня rри 
вибір рівня «множення»; 
вибір рівня «додавання»; 
2 Інтерфейс rри: 
відображення ігрового поля, де користувач буде вибирати числа 
та вводити відповіді; 
генерація питань; 
перевірка відповіді користувача. 
З Управління грою: 
обробка дій користувача (натискання кнопки підтвердження 
відповіді); 
перехід до наступного питання після підтвердження відповіді; 
відображення закінчення гри та можлнвість почати нову гру. 
64 
t І 
ЧДТУ.231920.ООS ПЗ 
---
Рисунок 3.6 - Логічна схема 
з.І.4 Розробка бази даних 
так як тема роботи повязана з розробкою інтерактивної гри, то БД по темі 
Ne р<>зРоблялась, так як в цьому не має необхідності. 
з. І .5 Розробка інтерфейсу користувача 
J Установка гри 
знаходимо файл New Unity Project.exe, на комп'ютері, відкриваємо його, 
далі нам висвітить наступне вікно. 
Рисунок З . 7 - Вікно запуску гри 
65 
ЧДТУ .23 І 920.005 ПЗ 
iu.itroro залуску нас зуетрі не го 
•сJІІІ ycr1 . ловне меню гри де для запуску гри 
(11 сну1'И клав1шу «Грап1>> . 
1111-rИ 
с~•о 
,1іІ 
і ' 
Рисунок 3.8 - Головне меню гри 
,Яl(uto ми обираємо «Грати» нас перекидає на наступний вибір. 
Рисунок 3.9 - Головн:е мен:ю гри 
Правила гри - задача гравця, керую'іlІ персонажем за допомогою клавіш 
cipL~кa ліворуч(Ф) і стрілха праворуч(В), а також за допомогою стрибку 
66 
ЧдтУ .23 1920.005 ПЗ 
брати nотрібняй блок з правильною відловідцю та застрибнути на 
r,l) в» 
,.ifJi( stiбopi блоr..')' гравець переходИть на наступний. 
, . . r1pff • • д 
~Со• тискан111 р~вня « одаваннЯ>> починається навчання по прикладам на 
~ (1р11 tfB 
Рисунок 3.10 - Головне меню гри 
Над nриІ(Jlадом є лічильник кількості прикладів і кількості правильних 
. ~ Кожна правильна відповідь суnроводжусrься анімаuіоо 
9і,о.ПООІде11. 
• ю~м звуковим супроводженням . 
віJ!ПОВІД 
Рисунок 3 .11 - Головне меню гри 
67 
чдтУ .231920.005 ПЗ 
. .ма неправильна відповідь cynpo 
во.nжується відповідним звуковим 
}(011'-'' 
....ке Е{Н.ЯМ · 
!11'°801-''.-
і) flp•J 1:1атисканні рівня «Множе ння» починається навчання по приJ<J1адам на 
~!tЯ 
f ,1 
Рисунок З .12 - Головне меню rри 
ПрИJ<JІадИ множення ідуть по всій таблиці множення. 
Над приJ<J1адом є лічильник кількості прикладів і кіл.ькості правильних 
зідnоsідей. Кожна правильна відповідь супроводжується анімацією 
зіJІІ!ОВідниМ звуковим супроводженням. 
Рисунок З.ІЗ-Головне меню rри 
Кожна неправильна відповідь супроводжується відповідним звуковим 
супроводженням. 
68 
ЧДтУ.231920.005 ПЗ 
J. J .б опис розробки п~грамlіИХ компонентів. 
№ лочаТJ<У нам потр~бно стоврити головне меню, запустивши Unity та 
14sJ11J f лр<>еТ ми створюємо сцену, яка і буде нашим в майбутньому головним 
~ № того що бстворити сцени ми повинні клацнути правою клавішою 
~efllD· по лanui Scenes потім вибрати кнопху Create і потім найти в списку 
.1! f JffOf 
~ scene. Натиснувши ·11- нам потрібно лише Дати назву нашій ман~ бу тю.и - 
~011JCY 
. . rотово. 
e,11etU І 
.-----....---
.. _ 
__...., ___ - ---------
- -
.... -....- .. '- -
- - --- '_ ,_-- 
-- --
-
--- ..._ --
--- - -.
--
 
· 
Рисунок 3.14-Створення сцен:и 
Створивши сцену меню, ми можемо трішки налаштуємо розм,· р ка мери 
!11 об кра ще було видно самі об' єкти в грі . 
Риснунок з . 15 - Іконка створеної сцени в папці Scenes 
69 
-
ЧДТУ.231920.005 ПЗ 
·і- - - ·-
••·::-::··-- -,. ..... ..-- -. ,,_,_._ _ 
._.. .,.. __ --..... 
-..·_·. -. -...  
,_ ..... .. • 
Рисунок З .16 _ Налаwтув 
ання камери 
дал•·  ми створимо порожній об'єкт щ об можна було в нього додавати р1· зн1·  
нти. Дамо йому назву Menu. 
e,iei,Іe 
+.- ... .,,. .. .........,  с....- ......... 
! 
t 
Рисунок З .17 - Створення порожньrо об' єкту 
Після його створення, наш об' єкт відобразиться в лівій панелі під назвою 
Нierarhy. Далі вже до готового об' єкту ми із зарані підготованої папки з 
спрайтами додамо фон для нашого майбутнього меню. 
70 
-
чдТУ.231920.ООs ПЗ 
----·- --
$. . - -
-1,.-. · · - - • 
... - ..· -• •
•·· -·,...;
•; ...t.  - 
- ~ -· • t.,.  -
·.. 
Рисунок З .18 - Додаван НЯ ф ону до порожнього об' ,єкту 
J 1еетrвання системи 3
J.Z. l Модульне тестування 
модульне тестування rри вивчення таблиці множення є процес перевірки 
~ r,tодулів чи ком.~онентів гри на коректність їх роботи. у контексті цієї 
~0,цуляtdИ є функцн або класи, що відповідають за генерацію множень, 
11'11, 
IJJIЯ відповідей користувачем, перевірку правильності відповідей та 
~е . 
еід06Р3"'ення результат1в. 
При модульному тестуванні гри вивчення таблиці множення, кожен 
'і/ОдУЛЬ тестується окремо, із.оm.овано з інших компонентів гри. Для цього були 
('[ВОрені тестові сценарії, які перевіряють різні сценарії вихористання модуля та 
аереконуються у правильності його роботи. Тести включають введення різних 
~вачень, перевірку очікуваних результатів та обробку помилкових ситуацій. 
Модульне тестування допомагає виявити та виправити помилки та 
проблеми в окремих комnонентах гри, покращує якість та надійність 
ороrрамноrо коду, а також полегшує його підтримку та розширення. 
При модульному тестуванні гри вивчення таблиці множення були 
перевірені такі аспекти: 
І Генерація множень: Було перевірено, що модуль rенерацїї множень 
орацює правильно, генеруючи множення в потрібному діапазоні (наприклад, від 
І до 10) та дотримуючись правил таблиці множення. Також перевірено, що 
згенеровані множення є унікальними та не містять повторень. 
71 
-
ЧдтУ.23 І 920.005 ПЗ 
п nевірка відповідей кориl'."nІва . Б 
еу- -·J ча. уло п-вірено, чи модуль 
,,,  відnов1. де й корис-rувача коректно . -- . ч.н 
•pJCtl оц1нюс правильн1сть 
.,,е.е1 •1 ь відповідей. Перевірен0 · • 
fY Jll!Ьtt C1'  Р13НІ варіанти відповідей, включаючи 
1· •~r  . ,ідnовіді, неправильні відnовіді та гран . . 
iJІЬJII ИЧНІ випадки • 
ll•l"4  1' . обn..я,-ж--енRJІ результатів··  Було . . ,. . а 
3 Вtд переварено, що модуль в1дображен,.,. 
:rіІІ виводить інформацію про правильні та неправильні відповіді 
J(J,1 11 
f~i ,,.~а. а також загальну статиетюсу, таку JПС кількість правильних 
11і.11еІІ, вt· дс оток правильни. х в І· ДП. ов·i дe"n  та час nроходжеЮUІ. 
і1'0 ()6робка помилок: Було перевірено, п гра обробJUІє МО)І(JІИВі помилки, 
4 
. ,ic t1е,соректне вве~ення корис-rувача або непередбачені ситуації. Перевірено, 
~ ,соректио nов~доМJUІє про помилки та пропонує відповідні дії Д1UІ їх 
" rp8 
~ett~· . . . 
5 nрадуктивюсть. Було перев1рено продуктивність rри, особливо якщо 
•cnrrь складні обчислення або вели.ку кількість множень. Перевірено, що 
Jl?lla~ • • 
ораWОЄ безпереб1Яно, не викликаючи затримок або проблем 1з 
,i- . 
~вНІС1'Ю· 
ispO ).2.2 •" '-· 
Jнтerpaц1nne тестуванНJІ 
J.lf1'trpauiйнe тестування - це процес тестуванш, щд час якого 
оеревір•ЄТЬС•, чи працюють окремі компоненти системи правильно разом. 
,нтеrраціЯне тестуваиня зазвичай проводять niCJUІ того, як було виконано 
JІОдуЛЬ8е тестування окремих компонентів, але перед тим, як приступати до 
свстеNНоrо тестуваиНJІ системи в цілому. 
І1іц час івтеrраційноrо тестування тести зазвичай проводяться на декількох 
на рівні інтерфейсів між окремими компонектамн системи; 
на рівні взаємодії між сервісами, які можуть виконуватися на 
різних серверах або в різних контекстах виконання; 
на piвtri системної івтеrраціі, коли всі компоненти системи 
взаємодіють разом і тестується весь процес. 
72 
ЧдтУ.231920.005 ПЗ 
інтеграційному тестуванні гри 
f]ptl вивчення таблиці множення було 
·..eJ{O -rа.ІСі аспекть,: 
_&1111'- • • 
iJ<r І Jtf'J'erpaцiя модул~в: Перевірено, що різні модулі гри коректно 
. ь 0д:ин з одним. Перевірено 
.,,o10J1ІJO'f передачу даних між модулями, виклИ]<И 
,,.- . а обробку подій. 
J(11ІЙ 'f 
♦>lf! z потік гри: Протестовано пот· . . 
ІК гри вщ початку до кінця, перев1ривши, 
. ,аулі працюють узrодЖено бе . 
ве1 r.«0 та з помилок. Перев1рено, що гра 
~ через різю етапи, такі n п . 
oJllfl'Ь очаток гри, генерац~я множень, введення 
~ oei.lleii, перевірка результатів та завершення rри. 
~ 3 Обробка введення корнету вача..  П ерев1. репо, що гра правильно 
введення користувача. Пере · . 
~яє в1рено р1зю сценар1ї введення. 
JCOJJaJtтecЯ, що гра коректно реагує на введення та пропонує відповідний 
~ере . 
fІІІІЙ зв'язок користувачев1. 
,,:11' 4 Обробка помилок: Перевірено, ях гра обробляє можливі помилки як 
'8У1Рі.J:11Ні, так і зовнішні. Зроблено висновок, що гра правильно реагує на 
~ і пропонує правильні повідомлення про помилку або вирішення 
~еМВ• . . 
5 Продуктивн1сть 1 тестування навантаження: Перевірено 
ародrКТИВНість гри при інтеграціі модулів і обробці великої кількості даних. 
ЗрОблено висновок, що гра працює безперебійно навіть за наявності високого 
вавантаження на систему. 
[::Сумісність: Перевірено, що гра працює коректно на різних платформах, 
ооераціЙНИХ системах та браузерах, з якими вона має бути сумісна. 
3.2.3 Системне тестування 
Системне тестування (system testing) - це тип тестування програмного 
забезпечення, .який здійснюється з метою перевірки відповідності вимогам 
фупціональності, ефективності та ЯКОСТІ продукту в цілому. Системне 
. 
rес~ування зазвичай проводиться шсля проведення модульного та 
інrеrраційного тестування і включає тестування всієї системи в цшому, 
В11 !0чаючи її окремі компоненти та інтерфейси з користувачем. 
73 
-
ЧДтУ.231920.005 ПЗ 
в1-1ою метою.  системного тес ос110 тування є перевірка роботи сис-rеми 8 
••оВЗХ та В рІЗНИХ сценаріаv к1· 
ьtРІ" у... "л використаню, що дозволяє виявити дея 
rJs JI ...0  можуть виникнути при ~-· 
11erdll, ... l""VV • 1 з системою в щ.л ому. 
~r'° f]plf системному тестуванні гри вивчення таблиці множення було 
0 raJci аспекти: 
sipeH 
~ 1 Функціональність гри: Перевірено, що всі функції гри працюють 
~ьно. Переві~но ~равильність генерації множень, введення відповідей, 
~ ipJ(){ результат~в, вщображенtu статистики і т. д. Гра виконує основне 
8
0
гІfНЯ • допомагає користувачу вивчати таблицю множеннJІ. 
,аІІд • • рфе 
2 rе~tмплей I ІНте йс користувача: Оцінено зручність використання 
і iirrepфeйc користувача. Перевірено, що елемекти керуванНJІ працюють 
rptІ • Ф" . .. . 
аравипьно, tнтер enc 1нту1тивно зрозумілиА, а ігровий процес приємний 1 
~ілиА ДЛJІ користувача. 
3 Навігація та взаємодія : Перевірено, що користувач може вільно 
оереwіщатнся різними екранами та розділами гри, взаємодіяти з елементами 
іJ!ТеРФеіісу та виконувати всі необхтні дії без проблем. 
4 Обробка помилок та виtuткових ситуацій: Протестовано, як гра 
обробляє можливі помилки, неправильні відповіді та інші виняткові ситуації. 
5 Робота на різних платформах та пристроях: Перевірено, що гра працює 
кореК'11fО на різних платформах, операційних системах та пристроях, дт1 яких 
ІОНІ призначена. Перевірено, що гра адаптована під різні роздільні здатності 
еаранів та пристрої з різними можлиВОСТDІи. 
lілродуктивність та стабільність: Оцінена продуктивність гри та її 
mбільнjсть при тривалому вихористаню. Перевірено, що 11>а працює плавно, не 
ІИХІІихає затримок або зависань і не виявляє нестабільну поведінку . 
3.2.4 Приймальне тестування 
Приймальне тестування (англ. acceptance testing) • це вид тестуванНJІ 
npolj)aМ}loro забезпечення, я:кий здійснюється з метою перевірки відповідності 
"Р<>11>ами вимогам та очікуванням замовника. Цей вид тестуванНJІ проводиться 
74 
... чдту .2з t 920.oos nз 
ttiй стад11 розробки "Роrрами 
.,и110<1 ' коли вона вже повністю готова до 
, ,i,-- е~сплуатацію. 
~ ,.у в 
11fl'I' приїtМальному тестуванні гр 
' f1pi4 . и вивчення таблиці множення було 
JJВtlO тaJCJ аспекти: 
10 
Р_І' ,/)? ФyнJ<UJ• OHа льн1·сть та ц~· л1· сність • 
І ·- гри: Перевірено, що гра виконує вс~ 
і функцн та праЦІОє відпов· 
sftOsau ІдНо до вимог. Перевірено, що гра 
,11 1108не та правильне вивчення . 
11е,rує · та6 л иц~ множення, включаючи всі числа 
,Р3 ~біt111Uії• 
i,iO z В рифіt<адЇJІ результатів: Пере · . 
е в~рено, що гра правильно оwюоє 
. ориС'l'Увача на множення і дає т • 
. 08ідt JC • очн~ результати. Протестовано, що гра 
,iJl11 :11-ана.ч ає правилью та неправил~о в,_ · ьні вщп·о в· . 'й ,,.,.,,.к 
щ1 та надає зворотн1 зв ,...,.,, 
cfY1'8qeBl, 
~оРІІ 3 JfffepфeAc користувача: Оцінено зручність вихористан.RJІ інтерфейсу 
18 jіоГО відnовідність вимогам користувача. Перевірено, що елементи 
~йсУ яс.но _і зрозуміло позначені, інструкції та підказки доступні, а 
іJІ1Уі1fІВПа пав1гац~я. 
4 Графіка та звук: Перевірено якість графічних елементів та аудіоефектів 
rp1..  Перевірено, що вони відповідають очікуванням та створюють приємне у 
~зуальне та звукове враження. 
5 Продуктивність та надійність: Оцінено продуктивність гри та її 
сrабільність при тривалому використанні. Перевірено, що гра працює без 
проблем і не викликає збоїв, зависань або інших непередбачених проблем у 
~-
6 Сумісність та доступність: Перевірено, що гра сумісна з різними 
mtатформами, операційними системами та пристроями, дru1 яких призначена. 
Зроблено висновок, що гра доступна д1ІJІ широкого кола користувач1в та 
mезпечує доступність для людей з обмеженими можливостями. 
75 
~ 
..:-/ 
~ ЧдтУ.231920.ООS ПЗ 
В■сиоаu до 3 роJділу 
ь-rатом роботи, виконаної в ціІt частнні прое~сту, с готовнІt 
(JyJІ . 
r fОІЙ додаток аз задуманнЮt функціu.и. 
-;ІJrf'~1' e-ran i nроеК1'УваННJІ було описано всі асnеІСТИ створенНJІ модулів та 
ncY JJJ)Orpaми, вик.о ристо&увалас11 навчальна літера-rура дл• коректно~
- 
./, .~ ЗSд)'маних кроюв. 
·,sJlll 
,' роб()11f з проеасrуваню системи були реалізовані в кінцевому додатХ)', 
f1ратестоваяий• 
~~ б'/9 вкоМ тестува.иНJІ є кореІСТВа робота nроfl)ЗМИ без збоїв та У 
0"сt·ІnО  . . . Є 
області, Це nадтверджує, що розроблений додаток в1дпов~да 
r., в,1е-f1ІІ без . . 
оr&М та за печує оч1кувани-А фующіонал ДЛJІ користувач1в. 
~r,1вtUd 
76 
.. 
чдтУ .231920 .О О sпз 
. ВІtсоово" 
вJtдНО з цих матерtаnів за Ос . 
jlJC • • та1u11 PGІOt, відеоіrрн ~ . 
r,aзsar I дозвtЛJUІ . А в деяl<ИХ _ зайняли значну юwу 
JfJ',cy r- kра1нах 8Qаи . 
j!ІР _......а. все більше і більше ком . · нав,тьдосяrли статусу спорту 
c;-reu•~ . . Панtіі, що займ . . 
i,i/1 е nowrrr,r, як 1нд1-~ • • aJ011.c• розробкою 1rop. Кр~м 
є 'f8I< г-~t""'НИК І ІНДj . . • 
t0f0• і продають впаси· . -студtJІ - незалежн1 розробнихи, ,оо 
...оеtО'°,-ь І trpи, без підтримки . 
".,_.. все більше людей . великих компаюй. Ях 
f1," J(.1,-ra-r, стають зацікавлені 8 розв · · у 
кий попит на ін иnу в~део1rор. свою 
є веЛИ струменти яJСі сп 
4ePrf• • ·- ф. . ' РRЯІОть розробці, вдосконаленюо 
• oJ111fМJЗ8WI ІЗИІСИ ТОІЦо. Однак . . . 
rl"'ф•JCJf• . р~зиJ •нструменти мають конкретні 
нкористаиня залежно від типу жа 
~рІІ в . ·- ' нру, nлатформи тощо. Тож потреба в їх 
• . J(JІ&СИф1кац11 виrлядає дуже 
811'1'1з1 18 аJстуаm.ною, завд11ки моїм дослідженням 
~f{){I< зможе заощадити час і більщ доцільно вибрати необхідні йому 
і!ІС'ІРУменти. 
кожна J1>8 має свої слабкі сторони 1· . 
с илью сторони. Розглядаючи ці чотири 
••ожемо зробити висновок що кож . .. . 
ІfІІІ, r,(11 ,.. ' ен розробник ПJДХОДИТЬ ДО СВОLХ 1rop 
' ально .ІІХ З точки зору n1n"1hn, · 
іJІДJІВlдУ ' ,.,.-....пп,, так 1з  ТОЧІСИ зору процесу і значеНШІ Jl>H. 
1f 8)0IX t,ШІЬйонів є мільйон, адже розробка ігор не стоїть на місці і кожен день 
JІІJ!УСКаЄТЬСЯ все більше ігор різних жанрів і різної .якості. 
Ми розглянули найпопулярніші сучасні інструменти для розробки ігор, 
ооділили іх на класи та проаналізували їх основні заявлені функціональні 
11ожливості. Для більш детального аналізу ми виберемо по одному 
QІJТИМальному представниху від кожного класу для розробки прототипу 
навчального проекту. Серед ігрових двигунів у колі незалежних розробників 
найпопулярнішим останнім часом є Unity. Він повністю задовольняє нас своїми 
основними характеристиками та має сильну підтримку громадськості, що значно 
знижує поріг вступу. 
Серед конструкторів 1rop Construct 2 виглядає досить привабливо, 
Номінально обіцяє широкий спектр функціональності і крос-платформи. Крім 
того, знову ж таки, вона має велику популярність і підтримку спільноти 
kОрис,увачів, незважаючи на відносну молодість проекту. Єдиним недоліком є 
77 
., -, 
r ЧДТу .231920.005 ПЗ І 
І .1С  'fЬ лише на 2-D розроб . • І 
,11)1'etJ ." щ, що доведетьс,~ враховувати при ' 
~ре ... і JСОнцепцн дru1 ПJХ)1'отипів. 
r,f)'J:JIJIIP • • 
~ серед фреіІМВОРКlВ ДЛЯ розробки trop підх з фуюсціональнісt10 підход,rть-
-rа 111elon1S, яхщо ви не 38ер1'аєте уваrя на те, що вови також призначені 
І yt#r _D проектів. MelonJS був випущений раніше і має більше реалізованих 
2
~~IIJe J1)1JI pЬaser показав свою конкурентоспроможність і швиДJСо набирає 
.."11tJ('fis, але • . . · щувань 
РУ"' • на даний момент має майже в деспь раз,в б~льше в1дв 
1 JtJfpttІCTЬ, 
norrf " С'fОріІІІСИ 8 день. 
\ oФilljjU!OI 
... 
ЧДn,.23, 920.005 nз 
список ВИJсоРвст 
·аіІfНИЙ сайт Construct2 _ [Ел АНИХ дЖЕРЕЛ 
. 
оФ1 еІСТронння ресурс) - режим доступу: 
-rrв-coJJ1• 
w.sc• 
/ '(t oФiuiJtl{J{Й портал J)ОЗробfІКків XNA - [Ел у 
; . ьщ,s:ІІm sdn . еnроннин ресурсJ  - режим 
.mtcrosofi.cornІruRU/ 
Aff'i· Santes..<feve/oprnent-msdn 
1 
jrf' ··oФi ltiйJJИЙ сайт MONO ga,ne _ СЕле 
ІСТронняй ресурс] _ режим доступу: 
J ,,. •, .,;W 1110nogame.net 
f fV' ·• • V 
~!ІР oфiniitJUIЙ сант Phaser - CEлenpoJJJfJDi ресурс) - Режим доступу: 
J • / 
·/~ ьsser.10 
ьІІР· р . , ,._.,lS githaЬ репозиторіА р· ·· 
офіUJИJtІІЛ IXJJS - (Елеnронний ресурс] - Режим 
~: ьщ,s:J/github.com/pixijs'pixi.js 
оф:.rіЙfІ}ІЙ сайт Blender - [Еле""""'иьт~ l'IPJ'Vrv-J 
6 .~м• -•r,onnJS r~п"' - Режим доступу: 
;//wWW·b1ender.org/featurest 
ьiq,.i сайт г 
ОфіuійНИЙ ease~s - [ЕлеnроННИй ресурс) _ Режим доступу: 
1 ,. 
/ІІІР:І/ createjs.com/ease ~s 
портал розробнmсів НЬnІ5 іrор - (ЕлеК1рОнний ресурс] _ Режим дОСl)'пу: 
8 
ьщ,s://htrnf 5g ameengine.com/ 
9 Офіціюшй сайт Mefonjs - (Елеnроняий ресурс] - Режим доступу: 
ьap://melonjs.org/ 
ІО Офіційний сайт PandaJs - (Елепронний ресурс] - Режим доступу: 
bap:І/www.pandajs.net/ 
11 Офіційний сайт GameMaker - [Елепронннй ресурс] - Режим доступу: 
j bttp://www.yoyogames.com/gamemaker 
12 Офіційний сайт Unity - [Елепрояний ресурс] - Режим доступу: 
Ьttp://unityЗd.com/ru/ 
13 Портал ігрових новин - [Електронний ресурс] - Режим дос,упу: 
Ьttp:11wwwЗ dnews.ru/games/622071 
14 Портал ігрових новин - [Електронний ресурс] - Режим доступу 
http:t/WWw.skgaming.com/coпtent/4811 
79 
V чдтУ.2з1920.ооs п --
J1 m1дярнни портал ро~ . . . З 
O••J -yvvHRkJв Ігор [Е 
15 ~ · http://www.gamedev.net - Ле1<7рою,нд ресурс] - Режим 
oert••J. 
ft 8,6 nU ТЗ ЗНЗЧеННЯ ЇГОр _ [Е 
пР>'' ЛеКТJ>онннА J 
16 І d allЬest ru/ . ресурс - Режим доступу: 
ьt1P5:ІfkJ1°W е ge. · pedagogicsІ2c0Ь65635aЗad78a5c4Зb8852 І 216d3 7_ O .ht 
..,/ . . 
,.. · в1део1гор - [Е 
1 JC'fOPJJI леК'І'ронниА ресурс) - Режим дос-rупу: 
bІ ttpS ·,І J uk. wiJdpedja.org/wiki/O/od00/o86%d 1% 8 І o/od І %82%d0%Ьe%d І %800/od І %96 
rodl 01. gf o/od0%b2%d 1% 96%dOOloЬ4%dOO/ob5%dOO/oЬe%d І %96%dOO/ob3%dOO/oЬe% 
70 -
dl¾SO 
JrpoлiJCJf [Електронний ресурс] Режим дOC'J)'ny : 
18 
s://gaiychyna.if.ua/anaJytic/videoigri-vse-chastishe-stayut-ne-prostorozvagoyu-
bttP -~a,.Jyudey-a-y-y ihni'm. . Jikamjj 
1-
dJya-J1u1JJ• IV"f'VYТV ' 
о аАн іrри для дітей - [Електронний ресурс] - Режим дv--•J••.1 • 
19 нл 
http://WWW•game-game.eom.ua/uk/tags/965/ 
додлтокл 
ЗА ТВЕРд жЕНО: 
АС, професор 
Голуб С.В. 
--+-ь--~'І-L----
--~:.=:...--- 2023 Р· 
ic забезпечення розвиваючої гри «Таблиця мвоженНJІ)) для мобільного 
гра~• 
np<> додатку на основі Unity 
Специфікація 
482. ЧДТУ 221920.005 
Л1tстів 2 
Петренко С.С. 
Розробник 
ruвень О.Б. 
Керівник 
ЧеркасІІ 2023 poi-,Y 
-
.231920-
·rY.231920-0 
. ту.2з 1 920-о 
82 
доддтокt 
iJJC З абезпечсння розвиваючо1- гри «Табл~ множенюІ)) дл.я мо 1 
lil'fl"" долатху ІІа б"льноrо 
0<110,; Uoity 
Текст програми 
482.ЧДтУ.221920-01 12 01 
Лнстів6 
Розробник Петренко С.С. 
Черкаси, 2023 
.. 
~нs2.чдту 
-231920 ·О! 12 01 
2 
oaf1ger 
1•  system.Collections; 
,iflg . 
·,,g System.Collectюns.Gen,, en.c · 
1,151" • ' 
. UnityEngine; 
LJSІrlg 
bJic class Opasnosti : MonoBeh . 
рtІ av1our { 
. ate рІауег_  Control player· 
pfl"" І 
bJic Transfonn start; 
ptl 
pt1bf ic GameObject Explode; 
use this for initialization 
11 
void Star1 О { 
player = FindObjectOfГype<playe r_ С  ontrol> О; 
// Update is called once per framc 
void Update О { 
} 
void OnTriggerEnter2D(Collider2D other){ 
if (other .tag = "Player") { 
player.transform.position = start.position; 
ІI I nstaлtiate (Explode, player.transfonn.position, 
player.transform.rotation); 
Debug.Log ("R.estart!"); 
} 
} 
} 
84 
-
482 .чдту 23 
. 1920.01 12 01 3 
І ver Controll 
z. р 3; 
s1.І 1i:> system.Collections.Gen .
11 0 enc ; 
• l]nityEngine; 
0 
ttSІl1i:> 
рtІ ьІіс cla. ss.  player_ C on. tro\ : Мо no В ehaviour { 
рІJьІіС R.1g1dbody2D R1gВud; 
рІJьІіс noat movespeed; 
ptib\ic float jumpheight; 
рІJЬІіс ьооІ movcright; 
ptiblic ьооl movelefi; 
рІJЬІіс ьооІ jump; 
рІJЬІіс Transform groundCheck; 
рІJЬ\іс float groundCheckRadius; 
public LayerMask WolG; 
// Use this for initialization 
void Start О { 
RigBud = GetComponcnt <Rigidbody2D> 0; 
} 
void FixedUpdateQ{ 
} 
// tJpdate is called once per frame 
void Updatc () { 
і r (lnput.GctKey (KeyCodc.LeftArrow)) { 
RigBud.velocity = ne\V Vector2 (•movespeed, RigBud.ve\ocity.y); 
transform.юtation = Quatemion.Euler (О, І 80, О); 
Debug.Log ("moving Іeft"); 
} 
85 
482 чдтv 
. ·231920-01 12 01 -, 
4 
j((Lnput.GetKcy (KeyCodc .RightЛrro\v)) { 
RigBud.ve\ocity = nc\v у 
ector2 (movespeed, RigВud.ve\ocity.y); 
transform.rotation == Quatern· ,. 
ion.i:.ulcr (О, О, О); 
Debug.Log ("moving right"); 
} 
if (rnoveright) { 
RigВud.vclocity = nc\v Vcctor2 (movespecd, Rig,Вud.velocity.y); 
1ransfom1.rotatio11 = Quatcmion.Euler (0, о, О); 
} 
if (rnove\eft) { 
RigВud.velocity = new Vector2 (-movespeed, Rig,Вud.velocity.y); 
transform.rotation = Quatemion.Euler (О, 180, О); 
} 
if (lnput.GetKey (KcyCode.Space)) { 
RigВud.velocity = new Vector2 (RigВud.velocity.x, jumpheight); 
Debug.Log ("Jump"); 
} 
ifUump) { 
RigВU'd.velocity = new Vector2 (Ri· gВud.ve\oc,· ty.x, з· umph  е,·g ht)"•  
jump = fa \se; 
} 
} 
} 
3. Transition 
11sing UnityEngine; 
using System.Collections; 
86 
. UnityEngine.UJ; 
i,s1J1g 5 
І ·с cfass FadclnOщ • М 
ub • . onoBcha . 
Р V1our { 
J іс static ЬооІ scencEnd· 
ptJ Ь ' 
ьІіС noat fadcSpecd :.:: 1.5(-
рtІ , 
ьІіс int nextLevel; 
ptJ . 
private Jmage _1mage; 
p~vate ЬооІ sceneStarting; 
\·oid А wake О 
{ 
- image = GetComponent<fm age>Q; 
_image.enabled == true; 
sceneStarting = true; 
sccneEnd = fa lse; 
Cursor.visible == faJse· 
' 
void Update О 
{ 
і f( sceneStarting) StartScene(); 
і f( sceneEnd) EndSceneQ; 
} 
void StartScenc () 
f 
_image.color = Color.Lerplimage.color, Color.clear, fadeSpeed • 
rlD!e.deltaTime ); 
87 
482.ЧДТу 
,231920.011201 6 
j[(_image.color.a <= 0.0J f) 
{ 
_in,age.colo1• = СоІо r.c1 c ar· 
' 
_image.cnabled = false· 
' 
sceneStarting = falsc· 
' 
Cursor.visi blc = true· 
' 
} 
vo•'d  cndScene О 
i:. 
{ 
_image.enablcd = true; 
_i1r1age.color = Color.Lcrp(_image.color, Co\or.black, fadeSpeed • 
dclta Time ); 
(!nІС-
itLimage.color.a >= 0.95f) 
{ 
Cш·sor.visible = falsc; 
_ image.c'olor = Color.black; 
Application.LoadLevel(nextLevel); 
} 
} 
} 
88 
дОІJ.лтокв 
npo грам11е забсз6n"с чсн,ц розвиваt0чої rp11 «Таблиця множення» для 
мо 1льноrо додащ на основі Unity 
Інс--rр)'1(ція користувача 
482.ЧJffY.221920-013401 
Листів 6 
Петренко С.С. 
Розробник: 
Черкаси, 2023 
482.ЧДТУ.221920-0\ 34 01 
2 
ЗМІСТ 
ус1·1)ІІОU ка гри·· ····· · ····························• ......................... .. .....• .4 3  
"І запуск гри, правипа та керування персонажем ........ •·  · · · · · · · · · · · · · · ,, 
90 
482 Ч;•ту 
. ' ·22 1 920-ОІ 34 01 
3 
усн.1110ока гри 
[. 
311,,,,х оJІИ!\tо файл Ne\.v Uni1y Pr O·J CCL.cxc І • . . - . 
. , ia комп ютер1, вшкриоасмо иоrо, дат 
~,~, (Іі1'1'1'1'І> 11аступ11с ВІКІІО. 
13JІС 
Рнсунок 13. І - Вікно запуску гри 
Після успіш11оrо запуску нас зустріне головне меню гри де для запуску гри ми 
~,асмо натиснути клавішу «Грати». 
Рисунок В.2 - Головне меню гри 
91 
482 ЧJ (ТУ 221920-ОІ 34 01 
4 
51"' 110 м11 обнрз(,10 «r ра, и» ,, 
ас нерски '1ас ІІа наступний в11бір. 
Рнсунок В.З - Головне меню гри 
JІраонла гри - задача гравця, керуючи nерсо11 аже:-.1 за допомогою клавіш 
•~ка J1іооруч(Ф) і стрі11ка 11раuоруч(В), а також за допомогою стрибку в 1·ору(Ц) 
,rj11-
JJІ6paOI 1 101·ріб1111й блок з нраn11,1ь11ою ві.:tповідШо та застрибнути на 11ьо1 о, при 
пІІборі бноку граuсць 11среходи rь на 11астушшй. 
1І р11 11uт1 1ска1111 1 рівня «Додавання» починасться навчання по прикладам на 
10;1ава111 1я . 
Рисунок В.4 - Головне меню гри 
92 
482 ·4дтУ.22І920-ОІ 34 01 5 
, , 11 рнкладом с J1іч11JІ ь1tнк . 
І f!:I, 1 КІ JІькосп прикладів і кі!Іькості 11рави.1ьних 
. •
1101.1 1.дс 11 . Кожна r~равиль11а відпов· . 
1 ~дь С}Проводжується а1іі,1ацісю і відnовщни,1 
І . су11роводжс1111ям . 
\", 01Hf~ 
Рисунок В.5 - Головне ~1еню гри 
Кожна неправильна відповідь супровод:жується відповідним звуковим 
,)r~роводжсшrям. 
При натисканю рівня «Множення» починається навчання по прик.1ала~1 на 
10,1ава11ня. 
Рисрюк В.6- Головне меню гри 
93 
482 .ч дтv .221920-0\ 34 01 
J1р 11J<лади множення ідут ь по вс1·~и  таб . 6 
и3,ц прикладом є ліч лиц~ множення. 
Г' нльник . 
JJЇдеVИ - Кожна правильна КІЛЬКОСТі п . . 
• . · риклад1в I кількості правильних 
flo JJІv"I су11роводжс11ням вщrювщь суп роводжується анімацією і відповідним 
l~о . 
Рисунок В.7 -Головне меню rри 
Кожна неправильна відповідь супроводжується відповідним звуковим: 
уnроводжен.ням. 
94 
r -
додлтокг 
rtpOг рам11е забезпече11ня розвиваючої rри «Таблиця множе11ня» для 
мобіщ,11оrо додатку 11а основі Unity 
Текст програми 
482.ЧД1У.231920-ОІ 90 01 
Листів 10 
Розробник Петре"ко С.С. 
Чсркас11 , 2023 
482 чдту 
. .231920-0\ 90 01 2 
Тема: 
Програмне забезnече 
множення масивів ~ розвиваюqої rри «Таблиця 
мобільного 8 Р13них системи числення» для 
додатку на основі Unity 
Виконав: 
ПЕТРЕНКО Серrій 
Рисунок Г.1 - Слайд «Вступ» 
Постановка задачі 
Ме·1·ою роботu Метою даної робОПІ розробка проrрамного 
забезпечення внвч~ння табmщі множення. 
Об'сk-~'Ом розробк11 даної ди1шомtюї роботи с процес навчання 
дитини через використа11ня програмного забезпечення вивчення 
таблиці ~нюжсння. 
Оп11с отр1Jмао11х реузльтатів. В даній роботі було проrрамне 
забезпечення розвиваючої гри «Таблиця множеmіЯ» на основі Unity 
Рисунок Г.2 - Слайд «Постановка задачі» 
96 
482. ЧДТу .231920-О І -
90 О І з 
~~о~рамні аналоги 
-- - --- --------
--Рисунок Г.3 - Слаіщ «Аналоги» 
Проектування програмного 
забезпечення розвиваючої гри 
«Таблиця множеІШЯ>> 
-
Діаrрама прtцt.tuпІв 
-'~_ .- - ... . . 
__ _., ' ' . 
Рисунок Г.4 - СJІайд «Діаграма прецедент1в» 
97 
і 
482 .ЧдТУ.231920-ОІ 90 01 4 
Проектування програмного 
забезпечення розвиваючої гри 
-«Т-а-б-ли-ц·я- м-н-о-же-н-ня-»- -----
І ·• І • 
г----, - 1- І і \ 
, f 4 , t 
ДІаrр1м1 ІСЛа~Іа 
Рисунок Г.5 - Слайд «Діаграма класів» 
Проектування програмно~о 
забезпечення розвиваюча~ гри 
~{Табли1~я мн.о~ж&ї..еНt1Нt1Я}"J..>и.> _____  
ДІаrр1ш oaxnta 
-... --·.._- - . 
~ , ' . . 
Рисунок,  Г •6  _ Слайд «Діаграма пакет1в» 
98 
482·ЧдТУ.2З 1920-ОІ 90 01 5 
Проектування програ~~ого 
забезпечення розвиваючої гри 
«Таблиця множення» 
ДІаграш дІмьвоm 
Рисунок Г. 7 - Слайд «Діаграма ді.ял ьності» 
Прое1аування програмного 
забезпечення розвиваючої гри 
«Таблиця множен:.:.:н::.=я.-=-:>._> ______  
г:==-, 1--1, , __ , 
---Г- , І 
. - ' 
- · -~-
. ~ ---- --::-:---:... І 
. .. r ~ , .._ _ , • __-. .__- , -__ ., ... І ♦ 
І І І 
ДJnгра~,а поелuовнос:тІ 
~--- - -- .... ---;~;-- ..: ~_::.:• :- .,_,,_ е 
' • t • 
Рисунок r . 8 - слаид~ «Діаrрама послідовностш 
99 
... 
482.Ч JtTY .23 І 920.о І 90 О І -
6 
Прое1сrування програмного 
забезпечення розвиваючої гри 
«Табли~я _множення:.»::._ _____  
·---{~  J--{ -:~ 
Efu ~ 
Діаrрама комунІющІі 
Рисунок Г.9 - Слайд «Д1.а rрама ко мунікації» 
Опис середовища розробки 
. • .1.  .:•.  ' ,, .,  . .. • -. •· ~ , Г о _ Сл ан-д «Середа розробки» 
Рисунок . 1 
100 
482 ЧДГУ 231920-ОІ 7 
90 01 
Опис інтерфейсу 
Рис} нок Г. 11 - Слайд «Оп.ис 111тсрфсйср> 
Опис інтерфейсу 
--------------
Рисунок Г. І~ _ с.,ай;~ (<Опис інтерфейсу» 
І О І 
r 482 . ЧдТУ.231920-ОІ 90 01 8 
Оnис інтерфейсу 
Рисунок Г. 13 - Слайд <(Опис і11терфеtІсу>> 
ПРОВЕДЕННЯ МОДУЛЬНОГО ТЕСТУВАННЯ ДОДАТКУ 
П1•t.•~•"Hcit,l)·ttt')WHlll.1Іf)М t~t-6.1Jdua8:D,;tD1.,_Qirlp,4i J ,.._,8СОКТ11 
Гtмtр,щu N"CWttt• &)~ ntp(І4Pf-llO, шо "4.U)'a ,-..,..an.....,. ..... .,..м..о, mм,)10W ~ 8 aof~Y 
.S1&МJOМ (мnf!tta..U.,.&1,J І )О 10) J8.II01pat,1)"°'"8C:8np&IU1. ............. Т-коааwрс.ц . , .. МІІН'РDІІm ,....... е 
)~•. ..... ••• .,,n•n ,..~ . 
1 rltpt-8.lpD IUПQltutl І.Ор8СТ).....U ,ро kpnlpr80, W ~ ............... ~ І'Орt'ІП"° СІОІІІОС 
opuмw.Jfa v •~n;,мн.n1111С'1, ц.1.dМІМ't п.р...,... ,._. ....,.,. ~ 8'.1IO'UJICIO ,...._ ~ 
~'1wtl І~ 18 ІJ)МІІ"1tІ 8kl'l,UO. 
) &~,см p,,y.oit n • ~--- _,,...,._~ - ~ 1i1м;.11,f0&,.-- ,.')._,.,•  ..-.rn , ..._ _ ІІІРО ~ '"' 
Рисунок Г. 14 - Слайд «Проведення модульного тестування» 
102 
482 .Ч дтУ .23 І 920-0 І 90 О І 9 
ПРОВЕДЕННЯІНТ ЕГРАЦІwй НОГО ТЕСТУВАННЯ ДОДАТКУ 
111111 ,н1 ,,рм1,n110>1у r,crya111111 f ptl ....... . , •• 1a6,i І 
1 Ік1<rр•u І1 wouyn,1 Пtptafnoн ІU "•08
•1111• Oyno ntptal~o ,.1.1"м.-r. .,  
,_ІІІL< WІ.0: •· 0 • що р11н, wсцу,1\ 
••o~)'nJWII, ІІІІUІІІ~ІІ...., rр&І IIOpt"ТIJO ІИ<WО.'11ІОn 0.1118 1 O~MIIW, ПtрtІІрtІІО ncptJl-"Y 
т, МІuІR та o6po6ry DОзІ/І 
:.n01І• rp11: Про1ос1оuмо nori• rp 
м1 nowмo• ПереаІрttІО, 11 l ,w..  nourcy 11 
АО &І-,·  0 
tno Dtpflipuan1, ІІ1О асі » o;ry111 np&lll'>!On y,roD••
оі:&ІІо.Ь<n, rмр,аІро р....,.. rp., D"""°"1JІІ • ~tpe1  РІ' ••І nami, •Nd u ІІО'UІОІ rp11. m,tpaW-1 ..- •• .... .,. .. 
- ., ... .,,.,. • t• имрw•  .., rpu.. 
) Пpo:o"'IIIIMkl• І t t (tya&Mlla ,. ." '"'.._.,.., ПореІІр,м -k'n 1 ~~ir А"""І• І о6р0бuІ 
atni1'10i ••• •-•і 111111" 3-"· -.--,- ··- rpo аро .,.,.,..._ .,...,. . 
, · 1...,_"'-f1IO tltc8IOІO " шо tpl llpAU.IOt O.mtpt6/nlt0 ..., ,. ,. ІІUІМОС>Іі ІІІ(ОІ<ОfО 
1,a1,11tt•••1ш.1 ... Cl l(lt "ty. 
Рису11ок Г. 15 - Слайд «Інтеграційне тестування додатку» 
ПРОВЕДЕННЯ СИСТЕМНОГО ТЕСТУВАННЯ ДОДАТКУ 
І Ірн снс,t·••"О).~у 1tс-туwамн1 rpet '""tнма 1е6..,і1VЇ w.мrAІotN1lil 6y.to м,рttІ9«МО r•d кмкnr:-
' Фyt•~uioн1.;1ti,,11k.."11, rr11: Іlf1МІ1рtмо, сао м1 t)'мt.vit rptJ nрашсмо1" np1111.1WtO. Пtрr,;р,,мо epu.aa.,..м.lcr" 
Іfllrp&Ulr ... ~ f H. .. ІIUfHIU , unoe~ii. nt~• •pc,t ,-,у.11,1•т••· ai.:ao,6,pul.tUA С'tІПtсt•ІКІ1 і t. А, ~ ІІІ№"Уf 
осм-ое••• »lr.»Jltм.t • .Dоnома•.к ~ 'YN"Y .,,...,.. .. t.Ь.-u,u.,o "мо11'ft4МІ , 
2 r,ilмn....n і ім1,рфtІІ< -,yaau: Оuімtмо 'l'Y""i<n 8118>1)1КТ..,..,,,.. і .,,,<P+tn- ua; 1)- • п_,.,...,. 
1110 tl<М<МПІ '-'P)'UHHJ Пр.1\DОІОВ npoan.1•110• ІІПfІ'+аІе ~ ~ 8 ,rpoanJI ,,,.,...С ...,.... , 
1p<»ywln11il ,.,.. 100\)І>М)'W. ...,  
). Ho1inui.l ra 1.»ОІ~і.-: Пtpc:a1pttto. аао copttc"1')'18" моа 1!.t:uo IW$WWUl,ln1ca pitм11WІJ ~. ...~ н та роuі.'Іамн 
rр<І, . ,.,....,...,• • , UtWfNІINII ІІП,PФ,iicy " ..-,,yun, осі ..-~; .oil6d npoмno, 
• Ро6оІІ " pi,nnx в.1атфе>рм.U 18 npІl('IJ)On: ntptlip,МO, 0,0 rp8 .,,,.. .... ~ ма рnІСІІJ< .,,,аІ~ 
on,pauU·uno. aк-1t.wa., 1111 nJN.c1paa . .:1» аuІА .ом• ap.n....-wмa . Пс-рnі:,.ІеО. uao f'PI u,.n1oeau сьз pt1МJ 
poui..1'-"i 1,,3,11мос-1і t~--рані1 11 nрнстроr, рон1~ю1 ~ 1aonn.u. 
Рисунок Г .16 - Слайд «Системне тестування додатку» 
103 
-
482 10 
-ЧдТУ.23 1920-01900 1 
ПРОВЕДЕННЯ ПРИЙМАЛЬНОГО ТЕСТУВАННЯ ДОДАТКУ 
1·11:,11 11 J.)І\і'Іt-ІА ,1~.НО)І)' 1(СТ)'~,'ІІЩ грн І1tr1с-н"• ,.,. . . 
- -- --..;,:~ u.~11:~oж,ntR• 6y.io npot•C"ТOUHO fІІ(І ,cne- ...,. ··  
І Ф)"lt\HiOH3,11,.tІiC'f• ТВ 11,:. itн i c- tt, 11)11: Пerv■in.t,o rpa , . ф ·, , . n,,..UJCК , un.o•i:D«> 
· .,~ ,~ • ШО ІІІІ~:ОМ)'С І<І 1aMINOUNI )'МХDІ r-
;10 111).IOГ, lltJ)t'IЇJ~ltO. шо rp~ uбf·)nC"r)'( nо.ІІf' о Пpi1JL1Wilt ІfІW'МММ,І 18'б.11ІОі t>ІHO'ACt•Ot•, 1с..11ІО"'.а.,.. І І асі 11к..1• 
1 n аr.-о.мбін~шіr. 
2 .0fPнфiuui• 1J,t,1y.,,,oтi1: Пf"Р(1і~ко, шо fJ» np1111.1wю оujммн 1WI01i.:,.i t:Dp,К"ryuчa н• и.иd«кМ• і »с ,vс:мі 
;W"t)-:11.1'0T}I. п potect·o,a,to, wo rJ'.a 10\ШО ІЇЗ\НІЧ34; np,11ш,w,i 11 м,еnрааІL-1..Мі 1і,uю1Іт т• ІІ&lІІС 1-юроnн· n1 •'•""' 
~рІІСІ)'а.8'tс,ІЇ . 
.3.І tttt~ftc .:ор1 1сf)·е:ача: Ouitte110 11,У"'••іс,1,. 111ms,ttc-rtмм• aenri,фd\c)' rрн fl l\ot'o 1&m,oei.:ulicn ІJtJ,tOr•м . , 
n • , , , .-.••І :10С1')'ІDІІ, 8 
.,;0рНС-1)'•:.•13. tJ)(ІфеІІО, wo ~41t:t.4(1tn1 ltH~pфelky А(МО і ,poiywi.."IO no1мnt11I. імструпІІJ 11 oi.:JP---
it4"f)'Ї'JlllllA щ11іrоні1. 
4. J'р•Ф•"" 10 11у,:: Пrр,1ір,ио ••.irn. ~;,111.,. •ммем,іа 18 оу.,аі,..фсстіо у rpi. n,s,eoipdlO. uso 1<>МІ> 
, "'10 1i;won o-1i.:.)•uмtt111 10 с1-.орююn nр101ме ■і,уадWІt 11 U)'IDH араwаtНІ4 
. . , . Оц' 
s.Пpo:x>'1C"l•t1жct-. •• иuн,м.сn: 1неио npo.:ay,im11мk-n. rp11 n _у ... ....,.,,..'"'1. 
п nа6іл•міс·~ n,es 1p1u: 
ПtрrІЇр<ІІО, WO rpa Прі1ОО< 6,1 npo6.,rw і НО OIIIJIIID( >боfо. >&ІІІ<UІ• о6о 1-"'1 -~""" ароб.•М у 
rоб<>•і-
Рисунок Г. 17 - Слайд «Приймальне тестування додатку» 
104
ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
