ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/9111| Title: | Мобільна гра-платформер для заохочення читання |
| Authors: | Заспа, Григорій Олександрович Пустовіт, Андрій Володимирович |
| Keywords: | РОЗРОБКА;МОБІЛЬНА ГРА;ПЛАТФОРМЕР;ІГРОВИЙ РУШІЙ;ЧИТАННЯ;DEVELOPMENT;MOBILE GAME;PLATFORMER;GAME ENGINE;READING |
| Issue Date: | 17-Jun-2024 |
| Abstract: | АНОТАЦІЯ
Пустовіта Андрія Володимировича на кваліфікаційну робота бакалавра на тему
“Мобільна гра-платформер для заохочення читання” спеціальність 121 “Інженерія
програмного забезпечення” в Черкаському державному технологічному університеті
у місті Черкаси в 2024 році.
Проект присвячений розробці програмного забезпечення мобільної гри-
платформера для заохочення читання. Система призначена для збільшення попиту на
вивчення української літератури серед молоді.
Проект включає розробку мобільного застосунку з використанням ігрового
рушія Unity та мови програмування C#.
Процес тестування включає використання сучасних інструментів доступних
для мови програмування C#, таких як MSTest.
Результати досліджень впроваджені у практику проектування програмного
забезпечення, що дозволило створити ефективну та надійну систему для заохочення
читання яка задовольняє потреби користувачів. ABSTRACT Pustovit Andrii for bachelor's degree work on the topic ‘Mobile platformer game to encourage reading’, speciality 121 ‘Software Engineering’ at Cherkasy State Technological University in Cherkasy in 2024. The project is dedicated to the development of a mobile platformer game software to encourage reading. The system is designed to increase the demand for studying Ukrainian literature among young people. The project includes the development of a mobile application using the Unity game engine and the C# programming language. The testing process includes the use of modern tools available for the C# programming language, such as MSTest. The results of the research are implemented in the practice of software design, which allowed to create an effective and reliable system for encouraging reading that meets the needs of users. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/9111 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота бкалавра Пустовіт Андрій Володимирович.pdf Restricted Access | 7.56 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
бакалавра
на тему: Мобільна гра-платформер для заохочення читання
Виконав: студент 4 курсу, групи ПЗ-2004
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Пустовіт А.В.
(прізвище та ініціали)
Керівник Заспа Г.О.
(прізвище та ініціали)
Рецензент Заруба О.В.
(прізвище та ініціали)
Черкаси 2024
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень бакалавр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
________С. Голуб________
«___» _______________ 2024 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Пустовіт Андрій Володимирович
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Мобільна гра-платформер для заохочення читання
Керівник проекту (роботи) Заспа Григорій Олександрович к.т.н., доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від « 26 » лютого 2024
року №60/04
2. Строк подання студентом проекту (роботи) 31 травня 2024
3. Вхідні дані до проекту (роботи) стандарти програмного забезпечення; процеси управління;
вимоги до проекту; календарне планування проекту; управління ризиками проекту; управління
ресурсами
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити) Вступ;
Існуючі методи та засоби розв’язання поставлених завдань;
Впровадження результатів досліджень у практику проектування програмного забезпечення
інформаційних систем;
Розробка та тестування програмного забезпечення;
Висновки;
Список використаних джерел;
Додатки
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту);
Слайд 1; Слайд 2; Слайд 3; Слайд 4;
Слайд 5; Слайд 6; Слайд 7; Слайд 8;
Слайд 9; Слайд 10; Слайд 11; Слайд 12;
Слайд 13; Слайд 14; Слайд 15; Слайд 16;
Слайд 17; Слайд 18
6. Консультанти розділів роботи
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання 02 грудня 2023 р.
КАЛЕНДАРНИЙ ПЛАН
Строк
виконання
№
Назва етапів випускної роботи етапів Примітки
п/п
кваліфікаційної
роботи
1 Постановка задачі 05.12.2023 виконано
2 Підготовка завдання 13.12.2023 виконано
3 Погодження завдання 16.12.2023 виконано
4 Затвердження завдання 19.02.2024 виконано
Основна стадія
1 Підбір матеріалів 27.02.2024 виконано
2 Аналіз шляхів вирішення поставленої задачі 04.02.2024 виконано
3 Розрахунок основних параметрів роботи 10.03.2024 виконано
4 Вибір кінцевого варіанту проектного рішення 17.03.2024 виконано
5 Оформлення первісної редакції роботи 25.03.2024 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 31.04.2024 виконано
керівником
2 Оформлення пояснювальної записки роботи в 13.05.2024 виконано
кінцевій редакції
3 Попередній захист роботи 15.05.2024 виконано
4 Затвердження роботи 02.06.2024 виконано
5 Рецензування роботи 06.06.2024 виконано
6 Захист роботи 7.06.2024
Студент _____________________ Пустовіт А.В.
(підпис) (прізвище та ініціали)
Керівник роботи _____________________ Заспа Г.О.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Пустовіта Андрія Володимировича на кваліфікаційну робота бакалавра на тему
“Мобільна гра-платформер для заохочення читання” спеціальність 121 “Інженерія
програмного забезпечення” в Черкаському державному технологічному університеті
у місті Черкаси в 2024 році.
Проект присвячений розробці програмного забезпечення мобільної гри-
платформера для заохочення читання. Система призначена для збільшення попиту на
вивчення української літератури серед молоді.
Проект включає розробку мобільного застосунку з використанням ігрового
рушія Unity та мови програмування C#.
Процес тестування включає використання сучасних інструментів доступних
для мови програмування C#, таких як MSTest.
Результати досліджень впроваджені у практику проектування програмного
забезпечення, що дозволило створити ефективну та надійну систему для заохочення
читання яка задовольняє потреби користувачів.
Ключові слова: РОЗРОБКА, МОБІЛЬНА ГРА, ПЛАТФОРМЕР, ІГРОВИЙ
РУШІЙ, ЧИТАННЯ.
ABSTRACT
Pustovit Andrii for bachelor's degree work on the topic ‘Mobile platformer game to
encourage reading’, speciality 121 ‘Software Engineering’ at Cherkasy State Technological
University in Cherkasy in 2024.
The project is dedicated to the development of a mobile platformer game software to
encourage reading. The system is designed to increase the demand for studying Ukrainian
literature among young people.
The project includes the development of a mobile application using the Unity game
engine and the C# programming language.
The testing process includes the use of modern tools available for the C#
programming language, such as MSTest.
The results of the research are implemented in the practice of software design, which
allowed to create an effective and reliable system for encouraging reading that meets the
needs of users.
Keywords: DEVELOPMENT, MOBILE GAME, PLATFORMER, GAME
ENGINE, READING.
ЗМІСТ
ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ ............................................................................ 84
ВСТУП .............................................................................................................................. 85
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ ПОСТАВЛЕНИХ
ЗАВДАНЬ .............................................................................................................. 89
1.1 Ігри як засіб освіти .......................................................................................... 89
1.2 Технології та інструменти розробки ............................................................. 93
1.3 Методики заохочення читання ...................................................................... 95
1.4 Аналіз існуючих аналогів ............................................................................... 96
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ
СИСТЕМ ................................................................................................................ 99
2.1. Моделювання предметної області ................................................................ 99
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної
області .............................................................................................................. 10
0
2.1.2. Елементи моделювання предметної
області .............................................................................................................. 10
3
2.1.3. Робоча область
моделювання .................................................................................................... 10
8
2.2. Формування та аналіз
вимог ....................................................................................................................... 10
9
2.2.1. Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні
вимоги ......................................................................... ..................................... 11
1 ЧДТУ.242056.010 ПЗ
Зм. Лист № докумемента Підпис Дата
Розроб. Пустовіт А.В. Мобільна гра-платформер для Літ. Лист Листів
Перев. Заспа Г.О. Н 3 103
заохочення читання ФІТІС, кафедра ПЗАС,
Н.контр. Півень О.Б. (Пояснювальна записка)
ПЗ-2004
Затв Голуб С.В.
ЧДТУ.242056.010 ПЗ
2.2.2. Формування вимог за допомогою діаграми
прецедентів ...................................................................................................... 11
3
2.3. Проектування логічної структури програмного
комплексу ............................................................................................................... 11
4
2.3.1. Діаграми
класів ................................................................................................................ 11
5
2.3.2. Діаграми
пакетів .............................................................................................................. 11
7
5
482.ЧДТУ. 24 2056 12 01 2
2.4. Архітектурне
проектування .........................................................................................................
118
2.4.1. Діаграма
компонентів .....................................................................................................
119
2.4.2. Розгортання програмної системи на апаратних засобах.
Діаграма
розгортання. .....................................................................................................
120
2.5. Моделювання поведінки
системи ...................................................................................................................
121
2.5.1. Діаграма
діяльності .........................................................................................................
122
2.5.2. Діаграма
послідовності ...................................................................................................
125
2.5.3. Діаграма
комунікації .......................................................................................................
126
2.5.4. Діаграма скінченного
автомату ...........................................................................................................
127
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
.................................................................................................................................
131
3.1. Розробка програмного
комплексу ...............................................................................................................
131
3.1.1. Обґрунтування вибору засобів
реалізації ..........................................................................................................
131
3.1.2. Опис структурної (функціональної)
схеми .................................................................................................................
133
3.1.3. Опис логічної схеми
системи .............................................................................................................
135
83
ЧДТУ.242056.010 ПЗ
3.1.4. Розробка бази
даних 136
3.1.5. Розробка інтерфейсу
користувача ......................................................................................................
138
3.1.6. Опис розробки програмних
компонентів .....................................................................................................
141
3.2. Тестування
системи ...................................................................................................................
143
3.2.1. Модульне
тестування ........................................................................................................
144
3.2.2. Інтеграційне
тестування ........................................................................................................
146
3.2.3. Системне
тестування ........................................................................................................
147
3.2.4. Приймальне
тестування ........................................................................................................
149
3.3. Приклади впровадженого програмного
комплексу ...............................................................................................................
150
ВИСНОВКИ
.................................................................................................................................
155
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
.................................................................................................................................
157
ДОДАТОК А
.................................................................................................................................
159
82
ЧДТУ.242056.010 ПЗ
ДОДАТОК Б
.................................................................................................................................
161
ДОДАТОК В
.................................................................................................................................
90
ДОДАТОК Г
.................................................................................................................................
94
Лист
ЧДТУ.242056.010 ПЗ
4
Зм. № докумементу Підпис Дата
83
ЧДТУ.242056.010 ПЗ
ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ
ПЗ – Програмне забезпечення
ПК – Персональний комп'ютер
ООП – Об'єктно-орієнтоване програмування
СУБД – Система управління базами даних
SQL – Structured Query Language (Мова структурованих запитів)
UML – Unified Modeling Language (Уніфікована мова моделювання)
IDE – Integrated Development Environment (Інтегроване середовище
розробки)
SDK – Software Development Kit (Набір засобів розробки програмного
забезпечення)
UML – Unified Modeling Language (Уніфікована мова моделювання)
84
ЧДТУ.242056.010 ПЗ
ВСТУП
Актуальність теми
Актуальність визначається потребою у розробці програмного забезпечення
інформаційної системи мобільної гри-платформера для заохочення читання.
Сучасні технології значно впливають на різні аспекти нашого життя, включаючи
освіту. Мобільні ігри стали потужним інструментом, який може заохотити дітей
до навчання через інтерактивні та розважальні елементи. Особливо важливим є
заохочення до читання, адже це основна навичка, яка впливає на подальший
академічний успіх дитини. Розробка мобільної гри-платформера, що стимулює
дітей до читання, є актуальною задачею, яка поєднує освітні цілі з інноваційними
підходами в ігровій індустрії. Додаток може не лише розвивати читацькі навички,
але й сприяти розвитку критичного мислення, творчих здібностей та розширенню
словникового запасу.
Мета і завдання розробки
Метою роботи є розробка програмного забезпечення інформаційної
технології мобільної гри-платформера, яка заохочує дітей до читання. Для
досягнення цієї мети необхідно виконати наступні завдання:
1 Інформаційний пошук методів, засобів та методик побудови
програмного забезпечення інформаційних систем виконання
поставлених завдань.
2 Проектування програмного забезпечення інформаційної системи
мобільної гри-платформера для заохочення дітей до читання.
3 Конструювання програмного забезпечення інформаційної системи
мобільної гри-платформера для заохочення дітей до читання.
4 Тестування програмного забезпечення інформаційної системи мобільної
гри-платформера для заохочення дітей до читання.
5 Впровадження та супроводження програмного забезпечення
інформаційної системи мобільної гри-платформера для заохочення дітей
до читання.
85
ЧДТУ.242056.010 ПЗ
Об’єкт розробки
Процес побудови програмного забезпечення інформаційних систем.
Предмет розробки
Процес побудови програмного забезпечення інформаційної системи
мобільної гри-платформера для заохочення дітей до читання.
Методи проектування та конструювання
Для реалізації проекту були використані такі методи та підходи інженерії
програмного забезпечення:
1 Аналіз та моделювання предметної області: створення моделі
предметної області, словника та елементів моделювання.
2 Проектування вимог: формування первинних і детальних вимог до
програмного забезпечення, включаючи функціональні та
нефункціональні вимоги.
3 Узагальнене та детальне проектування: розробка діаграм класів, пакетів,
компонентів та розгортання.
4 Моделювання поведінки системи: створення діаграм діяльності,
послідовності, комунікації та скінченного автомату.
5 Розробка програмного комплексу: використання Unity для створення
гри, розробка бази даних, інтерфейсу користувача та програмних
компонентів.
6 Тестування: проведення модульного, інтеграційного, системного та
приймального тестування для забезпечення якості програмного
забезпечення.
Опис отриманих результатів
В результаті виконаної роботи було створено мобільну гру-платформер, яка
включає інтерактивні завдання на читання та систему перевірки знань і оцінок.
Гра має такі основні характеристики та функціональні можливості:
1 Інтерактивні завдання на читання:
- завдання розроблені для різних вікових груп дітей;
86
ЧДТУ.242056.010 ПЗ
- завдання інтегровані в ігровий процес, що робить навчання цікавим
та захоплюючим;
- завдання спрямовані на розвиток навичок читання, розуміння тексту
та розширення словникового запасу.
2 Система перевірки знань і оцінок:
- вбудована система автоматично перевіряє виконання завдань;
- система надає вчителям та батькам можливість відстежувати прогрес
дитини;
- оцінки ґрунтуються на правильності та швидкості виконання
завдань;
- вчителі можуть аналізувати результати та давати рекомендації щодо
подальшого навчання.
3 Тестування та результати:
- гра була протестована на вибірці дітей різного віку;
- результати тестування показали високу ефективність гри у
підвищенні мотивації дітей до читання. Діти, які користувалися
грою, показали кращі результати в читанні порівняно з тими, хто не
використовував цей інструмент.
Практичне значення отриманих результатів
Розроблена гра може бути використана як ефективний інструмент для
заохочення читання у дітей. Вона має наступні можливості застосування:
1 В освітніх закладах:
- використання гри на уроках як додатковий навчальний матеріал;
- інтеграція гри в навчальний процес для урізноманітнення методів
навчання;
- використання гри для оцінювання знань учнів у інтерактивній формі.
2 У домашньому навчанні:
- батьки можуть використовувати гру для додаткових занять з дітьми;
- гра допомагає батькам слідкувати за прогресом дитини в читанні;
87
ЧДТУ.242056.010 ПЗ
- можливість індивідуального підходу до навчання з урахуванням
особливостей дитини.
3 Для подальших досліджень та розробок:
- гра демонструє ефективність використання мобільних технологій в
освіті;
- може стати основою для подальшого розвитку навчальних мобільних
додатків;
- сприяє вивченню нових методів інтеграції ігрових елементів у
навчальний процес.
Особистий внесок автора
Виконано повний цикл розробки гри, включаючи наступні етапи:
1 Аналіз існуючих методів: дослідження та аналіз сучасних методик
навчання читання. Вивчення існуючих освітніх ігор та мобільних
додатків для дітей.
2 Моделювання предметної області: визначення основних потреб та вимог
до гри. Створення моделей ігрових завдань та логіки їх виконання.
3 Формування вимог: розробка технічних та функціональних вимог до гри.
Визначення критеріїв успішності та методів оцінювання результатів.
4 Проектування архітектури та логіки гри: створення архітектури
програмного комплексу. Проектування логіки гри та інтерактивних
завдань.
5 Розробка програмного комплексу: написання коду для реалізації всіх
функціональних можливостей гри. Інтеграція системи перевірки знань
та оцінок.
6 Тестування: проведення тестування гри на вибірці дітей. Аналіз
результатів тестування та внесення необхідних коректив.
Цей комплекс робіт дозволив створити ефективний навчальний інструмент,
який може бути використаний для розвитку навичок читання у дітей.
88
ЧДТУ.242056.010 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1 Ігри як засіб освіти
Ігри, як освітній інструмент, набувають все більшої популярності завдяки
своїй здатності ефективно залучати учнів і сприяти засвоєнню знань. Ігри
використовуються в різних освітніх контекстах, від початкової школи до
університетів, і в різних формах, таких як настільні ігри, комп'ютерні ігри та
мобільні додатки. Основні причини, чому ігри стали популярними в освіті, це:
- ігри забезпечують активне залучення учнів, що сприяє більш глибокому
розумінню матеріалу;
- ігрові елементи, такі як бали, рівні та нагороди, стимулюють учнів до
досягнення кращих результатів;
- ігри можуть бути розроблені для досягнення конкретних навчальних
цілей, що дозволяє ефективно інтегрувати їх у навчальний процес;
- ігри сприяють розвитку різноманітних навичок, включаючи критичне
мислення, вирішення проблем та роботу в команді;
- ігри надають можливість індивідуалізації навчання, дозволяючи
кожному учневі працювати у своєму темпі та зосередитися на особистих
потребах.
Ігри мають значний психологічний вплив на дітей, зокрема:
- ігрові завдання часто є більш цікавими та захоплюючими для дітей, ніж
традиційні методи навчання, що підвищує їхню мотивацію до навчання;
- ігри можуть сприяти зниженню стресу та тривожності, створюючи
безпечне середовище для помилок та експериментів;
- багатокористувацькі ігри сприяють розвитку комунікативних та
соціальних навичок, вчать дітей працювати в команді та вирішувати
конфлікти;
89
ЧДТУ.242056.010 ПЗ
- ігрові завдання допомагають дітям розвивати навички концентрації та
уваги, оскільки вони потребують постійного залучення та активної
участі.
Переваги ігрового навчання для дітей
Ігрове навчання має численні переваги для дітей, такі як:
- інтерактивний характер ігор дозволяє дітям краще запам'ятовувати
інформацію та застосовувати її на практиці;
- ігри сприяють розвитку логічного мислення, планування, прийняття
рішень та вирішення проблем;
- багато ігор можуть адаптуватися до рівня знань та навичок учнів,
забезпечуючи індивідуальний підхід до навчання;
- ігри роблять навчання більш веселим та захоплюючим, що підвищує
зацікавленість дітей у навчальному процесі.
Таким чином, використання ігор у навчанні має багато переваг, що робить їх
ефективним інструментом для підвищення якості освіти та розвитку навичок у
дітей.
Платформери в освіті
Платформери – це жанр відеоігор, в яких гравець керує персонажем, що
пересувається через рівні, уникає перешкод і взаємодіє з різними об'єктами.
Основні характеристики та механіки платформерів включають:
- пересування персонажа: Стрибки, біг, лазіння та інші форми руху по
платформам;
- перешкоди та виклики: Шипи, рухомі платформи, вороги та інші загрози,
які гравець повинен подолати;
- збирання предметів: Монети, ключі та інші предмети, що потрібно
зібрати для проходження рівня;
- прогресія рівнів: Гра складається з різних рівнів або світів, кожен з яких
має унікальні виклики та тематику;
90
ЧДТУ.242056.010 ПЗ
- головоломки: Інтерактивні елементи, що потребують логічного
мислення
для вирішення.
Платформери мають великий потенціал для освітнього використання
завдяки своїм інтерактивним та захоплюючим елементам. Основні освітні
можливості платформерів включають:
- розвиток когнітивних навичок: Гравці повинні використовувати логічне
мислення, планування та вирішення проблем для проходження рівнів;
- навчання через гру: Платформери можуть інтегрувати освітні завдання,
такі як вирішення математичних задач, читання текстів або вивчення
фактів під час гри;
- мотивація та залучення: Інтерактивний характер платформерів
стимулює учнів до активного навчання, підвищуючи їх зацікавленість та
мотивацію;
- інтерактивні історії: Платформери можуть використовувати наративні
елементи для створення захоплюючих історій, що можуть бути
використані для навчання мови, літератури та історії.
Існує багато освітніх платформерів, які демонструють, як можна поєднувати
навчальні елементи з ігровим процесом. Ось деякі з них:
Zoombinis [1] (рисунок 1.1) – гра, яка допомагає розвивати логічне мислення
та навички вирішення проблем через серію головоломок і завдань.
Math Blaster [2] (рисунок 1.2) – платформер, який інтегрує математичні
завдання в ігровий процес, допомагаючи дітям покращити свої навички з
математики.
Таким чином, платформери мають великий потенціал для використання в
освіті, оскільки вони можуть поєднувати захоплюючий ігровий процес з
ефективним навчанням та розвитком різних навичок у дітей. Платформери
91
ЧДТУ.242056.010 ПЗ
створюють інтерактивне середовище, де діти можуть навчатися через гру, що
робить навчальний
процес більш захоплюючим та мотивуючим.
Рисунок 1.1 – Рівень гри Zoombinis
92
ЧДТУ.242056.010 ПЗ
Рисунок 1.2 – Рівень гри Math Blaster
1.2 Технології та інструменти розробки
Unity [3] – це один із найпопулярніших і потужних інструментів для
розробки мобільних ігор. Його широко використовують як незалежні розробники,
так і великі студії. Основні характеристики Unity:
- кросплатформність: Unity підтримує розробку для різних платформ,
включаючи iOS, Android, Windows, MacOS, та інші;
- інтуїтивний інтерфейс: Зручний для новачків, але також має широкий
спектр інструментів для досвідчених розробників;
- широкий вибір інструментів та бібліотек: Включає вбудовані фізичні
двигуни, анімації, аудіоінструменти та багато іншого;
- спільнота та підтримка: Велика спільнота розробників, доступність
численних навчальних матеріалів, активна підтримка від розробників.
Unreal Engine [4] – це ще один потужний інструмент для розробки ігор,
відомий своїми високоякісними графічними можливостями.
Порівняння основних аспектів Unity та Unreal Engine:
- графічні можливості: Unreal Engine відомий своїми передовими
графічними функціями, що робить його популярним для розробки AAA-
ігор. Unity також підтримує високоякісну графіку, але більш відомий
своєю оптимізацією для мобільних та незалежних ігор;
- продуктивність: Unreal Engine може вимагати більше ресурсів для
досягнення високої якості графіки. Unity часто обирають для мобільних
ігор через ефективну оптимізацію продуктивності;
- простота використання: Unity має більш інтуїтивний інтерфейс і
простіший в освоєнні для початківців. Unreal Engine може мати круту
криву навчання через складніші інструменти та можливості;
- скриптові мови: Unity використовує C# [5] для скриптингу. Unreal Engine
використовує C++ [6] та свій візуальний скриптовий редактор Blueprints.
93
ЧДТУ.242056.010 ПЗ
Godot Engine [7] – це відкрита і безкоштовна платформа для розробки ігор,
яка стає все популярнішою серед незалежних розробників. Основні
характеристики Godot:
- безкоштовність: Відкритий код та безкоштовне використання без
ліцензійних зборів. Буде таким завжди;
- мова скриптів: Використовує власну мову GDScript, яка схожа на Python
[8], також підтримує C#, VisualScript та інші мови;
- кросплатформеність: Підтримка розробки для різних платформ,
включаючи мобільні пристрої, ПК та веб-браузери;
- інтуїтивний інтерфейс: Проста та зрозуміла структура для розробки,
зручна для новачків. Добре задокументований;
- активна спільнота: Розширена документація та активна спільнота, яка
постійно розвиває та підтримує проект.
Інші інструменти розробки мобільних ігор
Окрім Unity, Unreal Engine та Godot, існують й інші інструменти, які можуть
бути корисними для розробки мобільних ігор:
- Cocos2d-x [9]: Відкрита кросплатформна структура для розробки 2D-
ігор, відома своєю легкістю та продуктивністю;
- Corona SDK [10]: Популярний інструмент для швидкої розробки 2D-ігор
та додатків з використанням мови програмування Lua;
- GameMaker Studio [11]: Потужна платформа, яка дозволяє створювати
2D-ігри без необхідності глибоких знань програмування, завдяки
візуальному інтерфейсу;
- Construct [12]: Інструмент для розробки 2D-ігор, який використовує
візуальне програмування і підходить для швидкої прототипізації та
розробки.
Ці інструменти мають свої унікальні особливості та переваги, що дозволяє
розробникам обирати найкращий варіант для їх конкретного проекту та потреб.
94
ЧДТУ.242056.010 ПЗ
1.3 Методики заохочення читання
Інтерактивні завдання є одним із найбільш ефективних методів заохочення
читання серед учнів різного віку. Вони роблять процес читання більш залученим і
захоплюючим, сприяючи глибшому розумінню та запам'ятовуванню матеріалу.
Основні види інтерактивних завдань:
- квест-завдання: Учні виконують завдання, що пов'язані з прочитаним
текстом, наприклад, відповідають на питання, шукають ключові слова
або розгадують головоломки;
- гейміфікація: Включення ігрових елементів, таких як бали, рівні та
нагороди за виконані завдання, для підтримки мотивації та інтересу до
читання;
- інтерактивні оповідання: Тексти, що дозволяють учням робити вибір та
впливати на розвиток сюжету, що підвищує залученість та інтерес до
читання;
- віртуальні книги: Використання електронних книг з інтерактивними
елементами, такими як анімації, звукові ефекти та інтерактивні
ілюстрації.
Система перевірки знань та оцінок
Система перевірки знань та оцінок є важливим компонентом навчального
процесу, що дозволяє вчителям та учням оцінювати прогрес у читанні. Основні
елементи такої системи:
- тести та вікторини: Використання коротких тестів та вікторин для
перевірки розуміння прочитаного матеріалу;
- автоматизовані системи оцінювання: Інтерактивні платформи, що
автоматично оцінюють відповіді учнів, надаючи миттєвий зворотній
зв'язок;
95
ЧДТУ.242056.010 ПЗ
- динамічні звіти: Генерація звітів про прогрес учнів, що дозволяє
вчителям
відстежувати успіхи та визначати області, що потребують додаткової
уваги;
1.4 Аналіз існуючих аналогів
Аналіз існуючих освітніх ігор та програм допомагає визначити, які
методики, інструменти та підходи вже використовуються для досягнення освітніх
цілей. Ось декілька прикладів популярних освітніх ігор та програм, які
використовуються для заохочення читання та розвитку інших навичок:
- гра Duolingo [13]: Хоча ця платформа більше орієнтована на вивчення
мов, її інтерактивний та гейміфікований підхід до навчання може бути
застосований і для читання. Duolingo використовує різні типи завдань,
систему винагород та соціальні елементи для підтримки мотивації
користувачів;
- гра Khan Academy Kids [14]: Програма, орієнтована на дітей молодшого
віку, яка включає інтерактивні уроки з різних предметів, включаючи
читання. Використовує яскравий дизайн, інтерактивні завдання та
систему винагород;
- гра Epic! – Kids Books and Videos [15]: Ця платформа надає доступ до
великої бібліотеки книг та відео для дітей. Включає функції для
відстеження прогресу читання, інтерактивні завдання та соціальні
елементи, що сприяють залученню дітей до читання;
- гра ClassDojo [16]: Хоча основна мета цієї платформи – управління
класом та комунікація між вчителями, батьками та учнями, вона також
включає інструменти для заохочення читання та навчання через
інтерактивні завдання та соціальні елементи.
Порівняння з розроблюваним проектом
96
ЧДТУ.242056.010 ПЗ
Розроблювана мобільна гра-платформер для заохочення читання буде мати
деякі спільні риси з наведеними вище прикладами, але також включатиме
унікальні елементи для вирішення конкретних завдань та покращення процесу
навчання:
- інтерактивні завдання на читання: Подібно до Duolingo та Khan Academy
Kids, гра буде використовувати інтерактивні завдання для залучення
учнів до читання;
- система перевірки знань та оцінок: Як і в Epic!, гра буде включати
систему перевірки знань, що дозволяє вчителям відстежувати прогрес
учнів та надавати зворотний зв'язок.
Аналіз існуючих освітніх ігор та програм показує, що використання
гейміфікації, інтерактивних завдань та соціальних елементів є ефективними
методами заохочення читання та навчання. Проте, розроблювана мобільна гра-
платформер має потенціал для усунення деяких недоліків існуючих рішень, таких
як обмеження за віком та відсутність персоналізації, що дозволить створити більш
ефективний та привабливий інструмент для старшої аудиторії.
97
ЧДТУ.242056.010 ПЗ
Висновок до першого розділу
Було проведено аналіз огляд існуючих методів та засобів, що
використовуються для вирішення поставлених завдань у контексті освітніх ігор.
Важливість ігор як освітнього інструменту безсумнівна, оскільки вони не тільки
активізують навчальний процес, але й розвивають різноманітні навички у дітей,
такі як критичне мислення, вирішення проблем, робота в команді, а також
знижують стрес і тривожність, створюючи безпечне середовище для помилок і
експериментів.
Платформери, як жанр відеоігор, демонструють значний потенціал в
освітньому процесі завдяки своїм інтерактивним та захоплюючим елементам.
Вони сприяють розвитку когнітивних навичок, навчають через гру, мотивують
учнів до активного навчання та можуть використовуватися для інтерактивних
історій, що робить їх цінним інструментом у навчанні.
Сучасні технології та інструменти розробки, такі як Unity, Unreal Engine та
Godot, забезпечують розробникам широкий спектр можливостей для створення
якісних мобільних ігор. Вони мають свої переваги та особливості, що дозволяє
обрати найкращий інструмент для конкретного проекту. Крім того, існують інші
платформи для розробки мобільних ігор, які також надають широкі можливості
для розробників.
Методики заохочення читання, такі як інтерактивні завдання, гейміфікація,
інтерактивні оповідання та віртуальні книги, роблять процес читання більш
залученим і захоплюючим. Використання систем перевірки знань та оцінок
допомагає вчителям і учням відстежувати прогрес і оцінювати результати
навчання.
Аналіз існуючих освітніх ігор та програм показав, що інтерактивність,
гейміфікація та соціальні елементи є ефективними методами для заохочення
читання та навчання. Отже, використання ігрових технологій в освіті є
перспективним напрямом, який дозволяє не тільки підвищити якість навчання, але
й зробити його більш захоплюючим та мотивуючим для учнів різного віку.
98
ЧДТУ.242056.010 ПЗ
РОЗДІЛ 2 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
2.1. Моделювання предметної області
Модель предметної області (МПО) є графічним або текстовим
представленням, яке відображає об'єкти і взаємозв'язки між ними, що є важливими
для вирішення конкретної задачі в межах визначеної області знань. Це один із
ключових етапів у процесі розробки програмного забезпечення, оскільки дозволяє
розробникам, аналітикам та іншим зацікавленим сторонам краще зрозуміти і
структурувати інформацію, з якою буде працювати система.
Основні аспекти моделі предметної області:
- концептуалізація: Виділення та ідентифікація компонентів предметної
області, тобто основних об'єктів і взаємозв'язків між ними, що існують в
реальному світі. Це дозволяє створити чітке уявлення про те, які
елементи будуть важливими для майбутньої інформаційної системи (ІС);
- аналіз та моделювання: Перш ніж писати код, необхідно провести
детальний аналіз предметної області, щоб зрозуміти бізнес-процеси,
вимоги та умови задачі. Логічна модель предметної області допомагає
ілюструвати сутності у вигляді класів і взаємовідносини між ними;
- графічне представлення: Метою побудови МПО є отримання графічного
представлення логічної структури предметної області. Це може бути
діаграма класів UML, яка показує сутності (класи) та їх взаємовідносини
(асоціації);
- ітеративний процес: Модель предметної області може змінюватися і
розвиватися в процесі розробки програмного забезпечення.
Використання ітеративних методологій, таких як Rational Unified Process
(RUP) або екстремальне програмування (XP), передбачає постійне
оновлення моделі на кожному етапі ітерації, відображаючи нові сценарії
та вимоги, які реалізуються;
99
ЧДТУ.242056.010 ПЗ
Таким чином, модель предметної області є важливим інструментом для
забезпечення якісної розробки програмного забезпечення, оскільки вона
забезпечує глибоке розуміння того, якою інформацією повинна управляти
система, які об'єкти входять в її сферу і які логічні зв'язки існують між цими
об'єктами.
2.1.1. Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметна область моделювання
Це сукупність знань, понять, явищ та відношень, що описують певну сферу
реального світу, яка підлягає моделюванню. Це та частина реальності, яку
моделюють для досягнення певної мети, такої як дослідження, аналіз, управління
чи проектування.
Основні аспекти предметної області моделювання включають:
1 Об'єкти: конкретні елементи, що існують у предметній області
(наприклад, машини, люди, процеси).
2 Властивості: характеристики об'єктів (наприклад, розмір, вага, колір).
3 Взаємозв'язки: відношення між об'єктами (наприклад, ієрархії, асоціації,
залежності).
4 Правила та обмеження: закони та принципи, що визначають, як об'єкти
можуть взаємодіяти (наприклад, фізичні закони, нормативні вимоги).
5 Процеси: дії або події, що відбуваються у предметній області
(наприклад, виробничі процеси, бізнес-процеси).
Процес моделювання включає ідентифікацію цих елементів, їх
структурування та формалізацію для створення моделей, які можуть бути
використані для симуляції, аналізу або оптимізації. Наприклад, в бізнесі
предметною областю моделювання може бути управління запасами, а в технічних
науках — динаміка рідин.
Модель предметної області
На UML діаграмі класів (рисунок 2.1) представлена структура мобільної
гри-платформера, для заохочення читання. Ось детальний опис діаграми:
100
ЧДТУ.242056.010 ПЗ
Класи та їхні взаємозв'язки:
1 Гра - це основний клас, який управляє всім процесом гри. Він містить
поточний рівень, на якому перебуває гравець;
2 Рівень - клас, який представляє один з рівнів гри. Рівень складається з
кількох платформ, уривків тексту та неігрових персонажів (НПС). Клас
Рівень має композиційні зв'язки з класами Платформа та Уривок Тексту,
що означає, що платформи і уривки тексту є невід'ємною частиною рівня
і не можуть існувати без нього. Клас Рівень має агрегаційний зв'язок з
класом НПС, що означає, що НПС можуть бути частиною рівня, але
можуть існувати незалежно від нього;
3 Персонаж - це базовий клас для персонажів у грі, включаючи гравця та
НПС;
4 Гравець - клас, що наслідує від Персонаж і представляє керованого
гравцем персонажа. Гравець взаємодіє з іншими об'єктами в грі, зокрема
збирає уривки тексту та відповідає на питання;
5 НПС - клас, що також наслідує від Персонаж і представляє персонажів,
якими не керує гравець. НПС можуть взаємодіяти з гравцем, надаючи
додаткову інформацію або завдання;
6 Платформа - клас, що представляє елементи рівня, на яких гравець може
стояти, стрибати та пересуватися;
7 Уривок Тексту - клас, що представляє частину тексту або книги, яку
гравець може збирати під час гри. Ці уривки тексту використовуються
для заохочення читання. Клас Уривок Тексту має зв'язок з класом
Питання, що означає, що кожен уривок тексту може містити питання, на
які гравець повинен відповісти для прогресу в грі;
8 Питання - клас, що представляє вікторину або запитання, пов'язане з
уривком тексту. Гравець має відповідати на ці питання, використовуючи
знання, отримані з уривків тексту;
101
ЧДТУ.242056.010 ПЗ
9 Бібліотека - клас для зберігання всіх зібраних уривків тексту. Це сховище
дозволяє гравцеві переглядати всі уривки тексту, які він зібрав під час
гри.
Загальні взаємозв'язки:
- рівень має композиційні зв'язки з Платформа та Уривок Тексту, що
означає, що вони є невід'ємною частиною рівня. Рівень має агрегаційний
зв'язок з НПС, що означає, що НПС можуть бути частиною рівня, але не
обов'язково;
- містить уривки тексту, але ці уривки можуть існувати незалежно.
Діаграма (рисунок 2.1) надає структуроване уявлення про компоненти гри
та їх взаємозв'язки, що допомагає краще зрозуміти, як функціонує гра та як
інтегруються елементи для заохочення читання.
Рисунок 2.1 - Модель предметної області гри
Словник предметної області
- мобільна гра - відеогра, призначена для гри на мобільних пристроях,
таких як смартфони та планшети;
102
ЧДТУ.242056.010 ПЗ
- інтерактивне навчання - процес навчання, що передбачає активну
взаємодію з матеріалом;
- платформер - жанр відеоігор, в якому гравець керує персонажем, що
- пересувається по платформам та обминає перешкоди;
- геймдизайн - процес створення правил, механік та структури гри;
- персонаж - головний об'єкт у грі, яким керує гравець;
- неігровий персонаж (NPC) - персонаж у грі, яким не керує гравець, а його
поведінка визначається програмними алгоритмами;
- діалогова система - механізм, що дозволяє гравцеві взаємодіяти з NPC
через розмови та вибір варіантів відповіді;
- платформи - статичні або рухомі поверхні, по яких пересувається
персонаж;
- рівні - окремі частини гри, які гравець повинен пройти;
- завдання - цілі, які необхідно виконати для просування у грі;
- гейміфікація - використання ігрових механік у неігрових контекстах для
підвищення мотивації;
- мобільні платформи - операційні системи, такі як Android [17], iOS [18];
- ігрові двигуни - програмні засоби для створення ігор, такі як Unity,
Unreal Engine;
- інтерактивний контент - матеріали, з якими користувач може
взаємодіяти;
- інтерфейс користувача - елементи управління грою та її візуальне
оформлення.
2.1.2. Елементи моделювання предметної області
Основні графічні символи UML використовувані в роботі (таблиця 2.1):
- прямокутники, розділені на три частини (назва класу, атрибути, методи):
Це використовується для представлення класів в UML діаграмах. Кожен
прямокутник зазвичай містить три частини: назва класу, атрибути і
методи класу;
103
ЧДТУ.242056.010 ПЗ
- прямокутник з написом «інтерфейс» вгорі: Це використовується для
представлення інтерфейсів в UML діаграмах. Інтерфейси визначають
контракти, які класи можуть реалізовувати;
- прямокутник з підкресленою назвою об'єкта: Це використовується для
представлення об'єктів в UML діаграмах. Підкреслена назва об'єкта
може вказувати, що цей об'єкт є конкретним екземпляром класу;
- стік-людина, що представляє користувача або іншу систему: Це
використовується для позначення користувачів або інших систем, які
взаємодіють з діаграмованими об'єктами або системами;
- прямокутники з заокругленими кутами для дій, ромби для рішень,
стрілки для потоку управління: Ці елементи використовуються в
діаграмах активностей для представлення послідовності дій, рішень та
потоку управління в програмі або системі.
Таблиця 2.1
Основні графічні символи UML
Прямокутники, розділені на три частини
(назва класу, атрибути, методи)
Прямокутник з написом «інтерфейс»
вгорі
Прямокутник з підкресленою назвою
об'єкта, наприклад: `:Об’єкт`
Стік-людина, що представляє користувача або
іншу систему
Продовження таблиці 2.1
104
ЧДТУ.242056.010 ПЗ
Прямокутники з заокругленими кутами для
дій, ромби для рішень, стрілки для потоку
управління
Великі прямокутники з вкладеними
прямокутниками, які представляють групи
класів або об'єктів
Основні єднальні елементи UML включають (таблиця 2.2):
- порожня стрілка (трикутник) від похідного класу до базового: Це
використовується для позначення узагальнення або успадкування, де
похідний клас успадковує характеристики базового класу;
- пунктирна стрілка з порожнім трикутником від класу до інтерфейсу: Це
використовується для позначення реалізації, де клас реалізує інтерфейс,
тобто реалізує методи, визначені в інтерфейсі;
- порожній ромб на кінці лінії, що з’єднує частини з цілим: Це
використовується для позначення агрегації, коли частина може належати
цілому, але може і існувати самостійно;
- заповнений ромб на кінці лінії, що з’єднує частини з цілим: Це
використовується для позначення композиції, коли частина належить
цілому і не може існувати без нього;
- кола та стрілки, що представляють стани та переходи між ними.
Ці єднальні елементи дозволяють моделювати різноманітні аспекти
програмних систем за допомогою мови моделювання UML. Завдяки цим
елементам, розробники можуть точно та чітко описувати структуру та поведінку
програмного забезпечення. Наприклад, успадкування дозволяє створювати більш
загальні класи, які можна використовувати як основи для інших класів, що
полегшує повторне використання коду та спрощує його супровід. Реалізація
105
ЧДТУ.242056.010 ПЗ
інтерфейсів дозволяє визначати стандарти поведінки для класів, забезпечуючи
гнучкість та можливість зміни реалізацій без зміни загальної структури системи.
Таблиця 2.2
Єднальні елементи UML
Порожня стрілка (трикутник) від похідного
класу до базового
Пунктирна стрілка з порожнім
трикутником від класу до інтерфейсу
Порожній ромб на кінці лінії, що з’єднує
частини з цілим
Заповнений ромб на кінці лінії, що з’єднує
частини з цілим
Стрілки в діаграмах послідовності або
співпраці, які показують повідомлення між
об'єктами
Кола та стрілки, що представляють стани та
переходи між ними
На рисунку 2.2 представлена класифікація діаграм, які використовуються в
UML для моделювання різних аспектів програмних систем. Діаграми поділяються
на дві основні категорії: діаграми структури та діаграми поведінки. Кожна з цих
категорій містить підкатегорії, що представляють різні типи діаграм. Ось
детальний опис кожної частини:
106
ЧДТУ.242056.010 ПЗ
Діаграма структури:
- діаграма класів: Використовується для представлення класів та їх
взаємозв'язків, включаючи спадкування, асоціації тощо;
- діаграма пакетів: Моделює структуру системи у вигляді пакетів, що
містять класи та інші елементи;
- діаграма компонентів: Відображає фізичні компоненти системи та їх
зв'язки;
- діаграма розгортання: Показує фізичне розгортання компонентів
системи на апаратних вузлах;
Діаграма поведінки:
- діаграма прецедентів: Моделює взаємодію користувачів (акторів) з
системою через прецеденти (use cases);
- діаграма діяльності: Відображає потік діяльностей або робочих процесів
у системі;
- діаграма кінцевих автоматів: Показує стани об'єкта і переходи між цими
станами внаслідок подій;
- діаграма послідовності: Відображає послідовність повідомлень об'єктів
в часі;
- діаграма комунікації: Показує взаємодії між об'єктами з акцентом на їх
структурні зв'язки.
Ці діаграми допомагають візуалізувати, специфікувати, конструювати та
документувати артефакти програмних систем.
107
ЧДТУ.242056.010 ПЗ
Рисунок 2.2 – Основні діаграми UML
2.1.3. Робоча область моделювання
На рисунку 2.3 зображено робочу область моделювання. Клас "Гра"
відповідає за управління основним потоком гри. Він має атрибут "currentLevel",
який вказує на поточний рівень гри, і методи "start()" та "end()", які запускають і
завершують гру відповідно.
"Рівень" визначає параметри кожного окремого рівня гри. У нього є
атрибути, такі як "nextLevel", "platforms", "textFragments" та "npc", які зберігають
посилання на наступний рівень, список платформ, список текстових уривків та
список NPC відповідно. Методи "load()" та "complete()" відповідають за
завантаження та завершення рівня.
"Персонаж" представляє собою базовий клас для об'єктів, які можуть
рухатися та взаємодіяти з іншими елементами гри. Він має методи для руху
("move()"), стрибка ("jump()") та збору предметів ("collectItem()"). "Гравець" є
підкласом "Персонажа" та додає додаткові атрибути, такі як "lives" та "score", які
вказують на кількість життів і рахунок гравця. Методи "answerQuestion()" та
"earnPoints()" дозволяють гравцю відповідати на питання та заробляти очки.
"НПС" також успадковує функціональність "Персонажа" та має метод
"interact()", що дозволяє NPC взаємодіяти з гравцем.
108
ЧДТУ.242056.010 ПЗ
"Платформа" визначає атрибути, які описують певну платформу в грі, такі
як "position" та "isMovable".
"Уривок Тексту" містить інформацію про певний текстовий фрагмент, такий
як назва, автор та зміст. Метод "collect()" використовується для збору цього
фрагмента.
"Питання" описує окреме питання в грі з текстом питання, варіантами
відповідей та правильною відповіддю.
Рисунок 2.3 – Робоча область моделювання
2.2. Формування та аналіз вимог
Формування та аналіз вимог є ключовими етапами в процесі розробки
програмного забезпечення. Вони забезпечують розуміння того, що система
повинна робити, і визначають, як це буде реалізовано. Цей процес включає збір,
документування, аналіз та управління вимогами до системи.
Формування вимог:
1 Збір вимог – інтерв'ю та опитування: спілкування з кінцевими
користувачами, замовниками та іншими зацікавленими сторонами для
109
ЧДТУ.242056.010 ПЗ
виявлення їхніх потреб і очікувань від системи. Аналіз документів:
вивчення існуючої документації, таких як бізнес-процеси, правила та
політики, що можуть вплинути на вимоги до системи. Спостереження:
нагляд за поточними процесами та використанням системи для
виявлення реальних потреб. Мозковий штурм: колективне обговорення
для генерації ідей та вимог.
2 Документування вимог – вимоги до функціональності: визначають, що
система повинна робити (функціональні вимоги). Нефункціональні
вимоги: описують характеристики системи, такі як продуктивність,
надійність, безпека та інші. Вимоги до користувачів – описують вимоги
відносно інтерфейсу користувача та зручності використання. Бізнес-
вимоги: вимоги, що визначають бізнес-цілі та завдання, які система
повинна підтримувати.
Аналіз вимог:
1 Валідація вимог – перевірка на повноту та коректність: переконання, що
всі необхідні вимоги зібрані і правильно зрозумілі. Узгодженість:
переконання, що вимоги не суперечать одна одній. Реалістичність:
оцінка того, наскільки вимоги можуть бути реалізовані з врахуванням
технічних обмежень та ресурсів.
2 Пріоритизація вимог – визначення пріоритетів: визначення, які вимоги є
найважливішими для реалізації першочергово. Аналіз вартості та
вигоди: оцінка вартості реалізації кожної вимоги та вигоди, яку вона
принесе.
3 Моделювання вимог – створення моделей та прототипів: використання
діаграм, прототипів та інших візуальних засобів для представлення
вимог і їх перевірки з користувачами.
Управління вимогами:
1 Трасування вимог – відстеження походження кожної вимоги і її зв’язків
з іншими елементами системи.
110
ЧДТУ.242056.010 ПЗ
2 Управління змінами – процес обробки змін у вимогах, включаючи оцінку
впливу, затвердження та реалізацію змін.
3 Комунікація вимог – забезпечення постійної комунікації між усіма
зацікавленими сторонами щодо змін та статусу вимог.
Формування та аналіз вимог є критичними для успішного проекту з
розробки програмного забезпечення. Вони забезпечують, що кінцевий продукт
відповідає очікуванням користувачів і бізнес-цілям, а також допомагають
уникнути помилок і змін на пізніх етапах розробки.
2.2.1. Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги
ВИМОГИ ЗАМОВНИКА
1 ПЗ повинно заохочувати користувачів до читання за допомогою
інтеграції текстових уривків в ігровий процес.
2 ПЗ повинно мати декілька рівнів з різними сюжетними текстовими
уривками, що впливають на розвиток сюжету.
3 ПЗ повинно забезпечувати можливість гравцеві взаємодіяти з
неігровими персонажами (NPC), які будуть пропонувати питання та
завдання на основі текстових уривків.
4 ПЗ повинно мати бібліотеку, де користувач може переглядати та читати
зібрані текстові уривки.
5 ПЗ повинно мати систему балів та нагород для заохочення читання та
інтерактивної взаємодії з текстовими уривками.
6 ПЗ повинно мати графічний інтерфейс, що відображає всі зібрані
текстові
уривки та їх прогрес у грі.
ВИМОГИ РОЗРОБНИКА
1 Користувач повинен мати можливість збирати текстові уривки під час
гри.
111
ЧДТУ.242056.010 ПЗ
2 Текстові уривки повинні бути інтерактивними та доступними для
читання у будь-який момент гри.
3 Після збору текстових уривків користувач повинен отримувати певні
бонуси чи нагороди.
4 Кожен рівень гри повинен містити унікальні текстові уривки.
5 Текстові уривки повинні бути пов'язані між собою та створювати
цілісний сюжет.
6 Прогрес гравця через рівні повинен залежати від збору і читання
текстових уривків.
7 Кожен NPC повинен мати набір питань, які базуються на зібраних
текстових уривках.
8 Гравець повинен мати можливість відповідати на питання NPC для
отримання додаткових бонусів чи прогресу у грі.
9 Взаємодія з NPC повинна бути інтерактивною та впливати на розвиток
сюжету гри.
10 Бібліотека повинна мати зручний інтерфейс для перегляду зібраних
текстових уривків.
11 Користувач повинен мати можливість переглядати уривки за автором,
назвою та змістом.
12 Бібліотека повинна дозволяти користувачеві відзначати прочитані
уривки та отримувати за це додаткові нагороди.
13 Користувач повинен отримувати бали за кожен зібраний текстовий
уривок.
14 Користувач повинен отримувати додаткові бали за правильні відповіді
на питання NPC.
15 Система нагород повинна мотивувати користувача до збору та читання
всіх
доступних текстових уривків.
16 Графічний інтерфейс повинен відображати іконки для кожного
зібраного текстового уривка.
112
ЧДТУ.242056.010 ПЗ
17 Користувач повинен мати можливість переглядати свій прогрес у зборі
та читанні уривків.
18 Інтерфейс повинен бути інтерактивним та адаптивним для зручності
користувача на мобільних пристроях.
2.2.2. Формування вимог за допомогою діаграми прецедентів
Пояснення до діаграми з рисунку 2.4:
Актори:
- користувач: Основний користувач гри, який взаємодіє з нею;
- розробник: Відповідальний за реалізацію вимог.
Випадки використання (Use Cases):
- UC1: Заохочення читання текстових уривків: Основна мета гри -
заохочувати читання текстових уривків;
- UC2: Інтеграція текстових уривків в ігровий процес: Включення
текстових уривків у гру таким чином, щоб вони впливали на геймплей;
- UC3: Взаємодія з неігровими персонажами (NPC): Забезпечення
можливості взаємодії з NPC, які будуть задавати питання на основі зібраних
текстових уривків;
- UC4: Створення бібліотеки текстових уривків: Реалізація бібліотеки для
перегляду зібраних текстових уривків;
- UC5: Впровадження системи балів та нагород: Система винагород, яка
мотивує користувачів до збору та читання текстових уривків;
- UC6: Реалізація графічного інтерфейсу для зібраних текстових уривків:
Графічний інтерфейс, що відображає прогрес та зібрані текстові уривки;
- UC7: Початок гри: Користувач починає гру;
- UC8: Завершення гри: Користувач завершує гру;
- UC9: Перегляд прогресу: Користувач переглядає свій прогрес у грі;
- UC10: Відповідь на питання: Користувач відповідає на питання, які
задають NPC.
Залежності між випадками використання:
113
ЧДТУ.242056.010 ПЗ
- UC2 залежить від UC1, оскільки інтеграція текстових уривків в ігровий
процес є засобом для досягнення мети заохочення читання;
- UC3, UC4, UC5, UC6 залежать від UC2, оскільки взаємодія з NPC,
створення бібліотеки, система балів та нагород, а також графічний інтерфейс є
частинами інтеграції текстових уривків в ігровий процес;
- UC7 ініціює UC2, тобто початок гри запускає інтеграцію текстових
уривків в ігровий процес;
- UC8 завершує UC2, тобто завершення гри закінчує інтеграцію текстових
уривків в ігровий процес;
- UC10 відповідає на питання UC3, тобто відповідь на питання NPC є
частиною взаємодії з NPC;
- UC9 переглядає прогрес UC6, тобто перегляд прогресу відбувається через
графічний інтерфейс;
- UC1 залежить від UC10, оскільки включає відповідь на питання.
Рисунок 2.4 - Діаграма прецедентів до мобільної гри
2.3. Проектування логічної структури програмного комплексу
Якщо формування та аналіз вимог передбачають розробку концептуальної
моделі, яка описує всі можливі та прийнятні варіанти розв’язання задач і визначає,
що повинна робити система, то проектування логічної структури системи полягає
у створенні логічної моделі системи у вигляді моделей класів і пакетів, що
114
ЧДТУ.242056.010 ПЗ
визначають складові системи. Логічне проектування також називають детальним
проектуванням класів.
2.3.1. Діаграми класів
Опис класів, їх атрибутів та методів на рисунку 2.5:
Гра:
Атрибути:
-currentLevel: Рівень – поточний рівень гри.
Методи:
+start(): void – метод для початку гри.
+end(): void – метод для завершення гри.
Рівень:
Атрибути:
-nextLevel: Рівень – посилання на наступний рівень.
-platforms: List<Платформа> – список платформ на рівні.
-textFragments: List<УривокТексту> – список текстових уривків на рівні.
-npc: List<НПС> – список неігрових персонажів (NPC) на рівні.
Методи:
+load(): void – метод для завантаження рівня.
+complete(): void – метод для завершення рівня.
Персонаж:
Методи:
+move(): void – метод для руху персонажа.
+jump(): void – метод для стрибка персонажа.
+collectItem(Предмет): void – метод для збирання предметів персонажем.
Гравець (наслідує Персонаж):
Атрибути:
-lives: int – кількість життів гравця.
-score: int – рахунок гравця.
Методи:
+answerQuestion(Питання): void – метод для відповіді на питання.
115
ЧДТУ.242056.010 ПЗ
+earnPoints(Points): void – метод для заробляння очок.
НПС (наслідує Персонаж):
Методи:
+interact(Гравець): void – метод для взаємодії з гравцем.
Платформа:
Атрибути:
+position: Position – позиція платформи.
+isMovable: bool – чи може платформа рухатися.
УривокТексту:
Атрибути:
+title: String – назва текстового уривку.
+author: String – автор текстового уривку.
+content: String – зміст текстового уривку.
Методи:
+collect(): void – метод для збору текстового уривку.
Опис зв'язків між класами:
- гра асоціюється з Рівнем (Гра *-- Рівень), що означає, що гра містить
один або більше рівнів;
- рівень асоціюється з Платформою (Рівень *-- Платформа), що означає,
що рівень містить одну або більше платформ;
- Рівень асоціюється з уривкомтексту (Рівень *-- уривоктексту), що
означає, що рівень містить один або більше текстових уривків;
- Рівень має агрегацію з НПС (Рівень o-- НПС), що означає, що NPC
існують незалежно від рівня, але рівень може містити один або більше
NPC;
- гравець асоціюється з УривкомТексту (Гравець --> УривокТексту), що
означає, що гравець може взаємодіяти з текстовими уривками;
- гравець асоціюється з Питанням (Гравець --> Питання), що означає, що
гравець може відповідати на питання;
116
ЧДТУ.242056.010 ПЗ
- уривок тексту асоціюється з Питанням (УривокТексту --> Питання), що
означає, що уривок тексту може містити питання;
- бібліотека має агрегацію з УривкомТексту (Бібліотека o--
УривокТексту), що означає, що бібліотека містить один або більше
текстових уривків.
Ця діаграма відображає структуру і взаємодію класів у грі, що дозволяє
зрозуміти, як різні елементи гри пов'язані між собою.
Рисунок 2.5 – Діаграма класів до мобільної гри
2.3.2. Діаграми пакетів
На діаграмі (рисунок 2.6) показані взаємозв'язки між різними пакетами
(модулями) у системі, яка може бути, наприклад, грою. Ось детальний опис
кожного пакета та зв'язків між ними:
- гра: це головний пакет, який включає в себе інші пакети. Зв'язок: "Гра"
містить "Елементи рівня";
- персонажі: пакет, який містить персонажів гри. Зв'язок: "Елементи
рівня" містять "Персонажі";
117
ЧДТУ.242056.010 ПЗ
- елементи рівня: пакет, який містить всі елементи, необхідні для
створення рівнів у грі. Зв'язки: "Елементи рівня" містять "Персонажі".
"Гра" містить "Елементи рівня". "Елементи рівня" використовують
"Інтерактивні елементи". "Бібліотека" містить "Елементи рівня";
- інтерактивні елементи: пакет, який містить елементи, з якими можуть
взаємодіяти гравці або персонажі (наприклад, двері, перемикачі).
Зв'язок: "Елементи рівня" використовують "Інтерактивні елементи";
- бібліотека: пакет, який може містити загальні ресурси або компоненти,
які використовуються для побудови елементів рівня. Зв'язок:
"Бібліотека" містить "Елементи рівня".
Рисунок 2.6 – Діаграма пакетів до мобільної гри
2.4. Архітектурне проектування
Архітектурне проектування – це процес проектування на найвищому рівні,
що полягає у створенні логічної архітектури системи. Воно включає опис
принципової організації системи у вигляді пакетів, програмних класів і підсистем,
без визначення способів їх розгортання на фізичних комп’ютерах або в різних
операційних системах. Метою архітектурного проектування є об’єктно-
орієнтована декомпозиція системи до рівня переліку підсистем та їх зв’язків, а
також опис її логічної структури у вигляді діаграм компонентів.
118
ЧДТУ.242056.010 ПЗ
2.4.1. Діаграма компонентів
Діаграма (рисунок 2.7) відображає архітектурну структуру компонентів гри,
їх відносини та взаємодію між ними.
- графічні компоненти: Включають основні елементи графіки та
геймплею, такі як сама гра, рівні, платформи, фрагменти тексту та
персонажі. Гра використовує гравця та містить рівні, кожен із яких
містить різні елементи, такі як платформи для гри, текстові фрагменти
для відображення інформації або інструкцій, а також персонажі для
створення інтерактивності у світі гри;
- бібліотечні компоненти: Включають бібліотеку, яка містить різні
текстові фрагменти, що можуть використовуватися у грі. Це може
включати, наприклад, текст для діалогів персонажів, інструкції гри або
текстові ресурси;
- компоненти персонажів: Включають гравця та NPC, а також зв'язані з
ними елементи, такі як фрагменти тексту та питання. Гравець може
взаємодіяти з різними елементами гри, зокрема з текстовими
фрагментами та питаннями, що можуть виникати у процесі гри.
Ця діаграма допомагає зрозуміти, як компоненти гри взаємодіють між
собою, що дозволяє розробникам краще організувати та розробляти гру.
119
ЧДТУ.242056.010 ПЗ
Рисунок 2.7 – Діаграма компонентів до мобільної гри
2.4.2. Розгортання програмної системи на апаратних засобах. Діаграма
розгортання.
На діаграмі (рисунок 2.8) показано архітектуру взаємодії компонентів у грі
між клієнтським пристроєм (де запущений додаток гри), сервером гри та сервером
баз даних.
Клієнтський пристрій:
- додаток гри: Це програмне забезпечення, яке встановлюється на
пристрої користувача. Взаємодія з грою відбувається через інтерфейс
гравця;
- інтерфейс гравця: Інтерфейс, через який користувач взаємодіє з грою.
Сервер гри:
- логіка гри: Компонент, що відповідає за обчислення логіки гри та
взаємодію з гравцем;
- менеджер рівнів: Керує рівнями гри, включаючи платформи, фрагменти
тексту та НПС (неігрові персонажі);
120
ЧДТУ.242056.010 ПЗ
- менеджер платформ: Відповідає за управління платформами на рівні;
- менеджер фрагментів тексту: Керує текстовими фрагментами, які
відображаються у грі;
- менеджер НПС: Відповідає за управління неігровими персонажами, які
можуть взаємодіяти з гравцем;
- менеджер гравців: Відповідає за управління даними гравців та їх
взаємодію з грою;
- Сервер баз даних:
- база даних гри: Зберігає дані, необхідні для функціонування гри;
- таблиця фрагментів тексту: Таблиця, що містить текстові фрагменти, які
використовуються у грі;
- таблиця питань: таблиця, що містить питання, які можуть виникати у грі;
- дані гравця: Зберігає інформацію про гравців, яка використовується для
збереження прогресу гравців та їх статистики.
Рисунок 2.8 – Діаграма розгортання до мобільної гри
2.5. Моделювання поведінки системи
Моделювання поведінки системи – це процес, що відповідає на питання, як
працює система, тобто як відбувається її функціонування. Модель поведінки
121
ЧДТУ.242056.010 ПЗ
системи описує алгоритм роботи системи і визначає, як різні об’єкти системи
взаємодіють між собою через обмін повідомленнями.
Основні засоби моделювання поведінки системи включають:
- діаграми діяльності: використовуються для опису потоку управління,
тобто послідовності виконуваних елементарних кроків при виконанні
окремої операції або реалізації складного варіанта використання;
- діаграми взаємодії: описують взаємодію декількох програмних об’єктів
між собою. це може бути у формі діаграм послідовності або діаграм
комунікації;
- діаграми станів (кінцеві автомати): використовуються для опису
життєвого циклу конкретного об’єкта, поведінка якого залежить від його
історії, або для обробки асинхронних стимулів. стани кінцевого автомата
відповідають різним наборам значень атрибутів об’єкта, а переходи між
станами відповідають виконанню операцій.
Таким чином, моделювання поведінки системи за допомогою діаграм UML
(Unified Modeling Language) дозволяє відобразити динамічну модель системи,
ілюструючи події та стани об’єктів, таких як транзакції, прецеденти та інші.
Використання діаграм UML для моделювання системної поведінки дозволяє
зображувати динамічну структуру системи, показуючи різноманітні події та стани
об'єктів, такі як транзакції, прецеденти й інші.
2.5.1. Діаграма діяльності
Діаграма (рисунок 2.9) детально описує послідовність дій та можливі гілки
(умови) у процесі гри, забезпечуючи чітке розуміння того, як гравець взаємодіє
з грою.
Основні компоненти діаграми включають:
- зайти в гру: гравець відкриває додаток гри та заходить у гру;
- вибрати рівень: гравець вибирає рівень, який хоче пройти;
122
ЧДТУ.242056.010 ПЗ
- завантаження рівня: вибраний рівень завантажується для гри;
- почати проходження рівня: гравець починає проходити рівень;
- пересуватися по рівню: гравець рухається по рівню, досліджує його та
взаємодіє з навколишнім середовищем;
- поговорити з персонажем: гравець взаємодіє з персонажами на рівні, що
можуть давати підказки або завдання;
- отримати завдання: гравець отримує завдання від персонажів або через
сюжет рівня;
- умова: Знайдено тест: перевіряється, чи знайдено тест на рівні;
- якщо так: пройти тест: гравець проходить тест, пов'язаний з контентом
гри;
- умова: Тест пройдено успішно: перевірка, чи успішно гравець пройшов
тест;
- якщо так: перейти до наступного рівня: гравець переходить до
наступного рівня;
- якщо ні: спробувати ще раз: гравець може спробувати пройти тест ще
раз;
- якщо ні: продовжити проходження рівня: гравець продовжує проходити
рівень без тесту;
- досягти кінця рівня: гравець досягає кінця рівня;
- завершити рівень: гравець завершує рівень, отримуючи результати та
можливі нагороди;
- вибрати новий рівень або вийти: гравець може вибрати новий рівень для
проходження або вийти з гри;
- завершення: процес гри завершується.
123
ЧДТУ.242056.010 ПЗ
Рисунок 2.9 – Діаграма діяльності до мобільної гри
124
ЧДТУ.242056.010 ПЗ
2.5.2. Діаграма послідовності
Діаграма з рисунку 2.10 відображає взаємодію гравця з різними частинами
гри та бібліотекою текстових фрагментів. Основні компоненти включають:
- гравець: Гравець, який взаємодіє з грою;
- гра: Основний компонент гри, який керує ігровим процесом;
- рівень: Конкретний рівень гри, який завантажується гравцем;
- текстовий Фрагмент: Частина тексту або інформації у грі;
- питання: Питання, які можуть виникати під час гри;
- бібліотека: Місце, де зберігаються різні текстові фрагменти для
використання у грі.
Взаємодія гравця з грою включає наступні дії:
- гравець починає гру;
- гра завантажує рівень;
- рівень завантажує тексові фрагменти;
- гравець збирає текстові фрагменти;
- текстовий фрагмент відображає питання;
- гравець відповідає на питання;
- гра перевіряє відповідь гравця;
- гравець завершує рівень;
- гра оголошує, що рівень завершено;
- гра додає текстові фрагменти до бібліотеки;
- гравець завершує гру.
Таким чином, діаграма показує послідовність дій гравця та взаємодію з
різними компонентами гри під час геймплею. Ця структура дозволяє зрозуміти
логіку та потік інформації у грі.
125
ЧДТУ.242056.010 ПЗ
Рисунок 2.10 - Діаграма послідовності до мобільної гри
2.5.3. Діаграма комунікації
Діаграма (рисунок 2.11) показує послідовність взаємодій між різними
об'єктами під час гри.
- гравець (об'єкт "Гравець"): Починає гру, збирає предмети, відповідає на
питання та завершує гру;
- гра (об'єкт "Гра"): Керує ігровим процесом та взаємодіє з рівнями та
бібліотекою;
- рівень (об'єкт "Рівень"): Завантажується грою та завантажує текстові
фрагменти;
- текстовий Фрагмент (об'єкт "Текстовий Фрагмент"): Відображається на
рівні та містить інформацію;
- питання (об'єкт "Питання"): Показується гравцю, і гравець надає на
нього відповідь;
126
ЧДТУ.242056.010 ПЗ
- бібліотека (об'єкт "Бібліотека"): Зберігає текстові фрагменти.
Під час гри відбуваються такі дії:
- гравець починає гру;
- гра завантажує рівень;
- рівень завантажує текстові фрагменти;
- гравець збирає предмети;
- текстовий фрагмент відображає питання;
- гравець відповідає на питання;
- гра перевіряє відповідь;
- гравець завершує рівень;
- гра додає текстові фрагменти до бібліотеки;
- гравець завершує гру.
Ця діаграма демонструє основні кроки геймплею та взаємодії між різними
компонентами гри.
Рисунок 2.11 - Діаграма комунікації до мобільної гри
2.5.4. Діаграма скінченного автомату
Діаграма з рисунку 2.12 ілюструє послідовність дій у грі, від початку до
завершення рівня або гри.
- неактивний: Це початковий стан гри, коли гравець ще не розпочав грати.
У цьому стані гравець чекає на початок гри;
127
ЧДТУ.242056.010 ПЗ
- граємо: Гравець починає гру, викликаючи метод start(). Гра переходить
у цей стан, підготовлену для активного геймплею;
- завантаження Рівня: Гра завантажує наступний рівень, викликаючи
метод loadLevel(). Це може включати завантаження необхідних ресурсів,
обробку логіки рівня та інше;
- граємо Рівень: Рівень успішно завантажено, гра переходить у стан
активного геймплею. Гравець може взаємодіяти з грою та виконувати
різні дії;
- показ Питання: Під час геймплею гравець збирає текстові фрагменти.
Коли гравець збирає новий фрагмент, відображується питання, пов'язане
з цим фрагментом;
- відповідь на Питання: Гравець відповідає на питання, введене
користувачем. Гра перевіряє правильність відповіді;
- рівень Завершено: Якщо відповідь на питання вірна, гра переходить у
стан завершення рівня. Це означає, що гравець успішно завершив рівень
і може переходити до наступного;
- завершення Гри: Якщо гравець успішно завершує всі рівні гри або
вирішує закінчити гру, гра переходить у стан завершення гри. Гра
завершується, і гравець може повернутися до головного меню або почати
нову гру;
- завантаження Наступного Рівня: Якщо гравець не завершив гру, гра
завантажує наступний рівень, і гравець може продовжити грати.
128
ЧДТУ.242056.010 ПЗ
Рисунок 2.12 - Діаграма скінченного автомату до мобільної гри
129
ЧДТУ.242056.010 ПЗ
Висновок до другого розділу
У даному розділі було розглянуто процес впровадження результатів
досліджень у практику проєктування програмного забезпечення інформаційних
систем, зокрема, моделювання предметної області (МПО). Основна увага
приділялася концептуалізації, аналізу, графічному представленню та
ітеративному процесу розробки МПО. Важливість цього етапу полягає у створенні
чіткого уявлення про об'єкти та їх взаємозв'язки, що дозволяє розробникам та
аналітикам ефективніше структурувати інформацію і полегшити процес розробки.
На прикладі UML діаграм класів було продемонстровано структуру
мобільної гри-платформера для заохочення читання. Детально описані основні
класи та їх взаємозв'язки, що ілюструє як моделювання предметної області сприяє
кращому розумінню і функціонуванню складних систем.
Важливість використання графічних символів UML та їх пояснення
допомагає розробникам точно описувати структуру та поведінку програмного
забезпечення. Завдяки цим інструментам можливо не лише візуалізувати, але й
документувати різноманітні аспекти програмних систем, що сприяє ефективності
та якості процесу розробки.
Таким чином, моделювання предметної області є ключовим етапом у
розробці інформаційних систем, що забезпечує глибоке розуміння і чітку
структуризацію інформації, необхідної для успішної реалізації програмного
забезпечення.
130
ЧДТУ.242056.010 ПЗ
РОЗДІЛ 3 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
3.1. Розробка програмного комплексу
Розробка та тестування програмного забезпечення - це комплексний процес,
який включає в себе кілька етапів:
1 Вибір програмного середовища: визначення інструментів та технологій,
які будуть використовуватися під час розробки, таких як мови
програмування, фреймворки, середовища розробки тощо;
2 розробка алгоритмів та кодування: створення алгоритмів для вирішення
конкретних завдань програми та написання програмного коду, що
реалізує ці алгоритми;
3 Розробка бази даних: створення структури бази даних, включаючи
таблиці, зв'язки та індекси, а також написання SQL-запитів для роботи з
даними;
4 Проектування інтерфейсу користувача: розробка інтерфейсу, через який
користувач буде взаємодіяти з програмним забезпеченням. Це включає
створення візуальних елементів, таких як кнопки, поля введення, таблиці
тощо;
5 Тестування програмного забезпечення: виконання різноманітних тестів
для перевірки правильності роботи програми, виявлення та виправлення
помилок.
При цьому важливо використовувати сучасні технології розробки, такі як
гнучке програмування (Agile), хмарні технології та розробка web-сервісів для
забезпечення ефективності та гнучкості процесу розробки.
3.1.1. Обґрунтування вибору засобів реалізації
Середовище розробки: Unity
Unity було обрано як середовище розробки з наступних причин:
131
ЧДТУ.242056.010 ПЗ
- популярність і підтримка: Unity є однією з найпопулярніших платформ
для розробки ігор, що забезпечує доступ до великої кількості навчальних
матеріалів, документації та активної спільноти розробників;
- кросплатформеність: Unity дозволяє створювати ігри, які можуть бути
розгорнуті на різних платформах, включаючи iOS та Android, що є
важливим для мобільної гри;
- інструменти для 2D та 3D розробки: Unity пропонує потужні
інструменти для розробки як 2D, так і 3D ігор, що дозволяє гнучко
підходити до візуального стилю гри;
- інтеграція з сервісами: Unity підтримує інтеграцію з різними сторонніми
сервісами, такими як аналітика, рекламні мережі та інші SDK, що можуть
бути корисними для розвитку гри.
Мова програмування: C#
Для розробки на Unity основною мовою програмування є C#. Вибір C#
аргументується наступним:
- інтеграція з Unity: C# є основною мовою, підтримуваною Unity, що
забезпечує повну сумісність і оптимальну продуктивність;
- Простота у навчанні та використанні: C# має відносно низький поріг
входу, але при цьому є потужною мовою для розробки складних
додатків;
- обширна підтримка: Існує велика кількість ресурсів, бібліотек та
фреймворків, які можуть бути використані для розробки на C#.
Система керування базами даних (СКБД): SQLite [19]
SQLite обрано як СКБД для зберігання даних у грі з наступних причин:
- легкість у впровадженні: SQLite є легкою, вбудованою базою даних, яка
не потребує окремого серверу для роботи;
- кросплатформеність: SQLite підтримується на різних платформах, що
дозволяє використовувати її в мобільних додатках на iOS та Android;
- продуктивність: SQLite забезпечує високу продуктивність для
невеликих обсягів даних, що робить її ідеальною для мобільних додатків.
132
ЧДТУ.242056.010 ПЗ
Інші необхідні засоби
- Visual Studio [20]: IDE для розробки на C#, яке добре інтегрується з Unity
і надає розширені можливості для кодування, налагодження та
тестування;
- Adobe Photoshop [21] / Illustrator [22]: Програми для створення та
редагування графіки та спрайтів;
- Git [23]: Система керування версіями, яка дозволяє ефективно керувати
кодом та співпрацювати з іншими розробниками.
Конфігурація апаратних засобів
Для розробки гри на Unity необхідна наступна конфігурація апаратних
засобів:
Комп'ютер:
Процесор: Intel [24] Core i5 або еквівалентний
Оперативна пам'ять: 8 ГБ і більше
Графічний процесор: Відеокарта з підтримкою DirectX 11 [25]
Місце на диску: SSD на 256 ГБ або більше
Операційна система: Windows 10 [26] або macOS [27]
Мобільні пристрої для тестування:
Android-смартфон з ОС Android 7.0 або вище
iOS-смартфон з iOS 13 або вище
Ця конфігурація забезпечить оптимальні умови для розробки, тестування та
налагодження гри на різних платформах.
Вибір Unity як середовища розробки, C# як мови програмування та SQLite
як СКБД є обґрунтованим завдяки їхнім перевагам у продуктивності,
кросплатформеності та легкості впровадження. Додаткові інструменти, такі як
Visual Studio та Adobe Photoshop, сприятимуть ефективній розробці та оптимізації
процесу створення мобільної гри-платформера для заохочення читання.
3.1.2. Опис структурної (функціональної) схеми
На функціональній схемі зображено підсистеми: пересування по рівню,
взаємодія з неігровими персонажами, бібліотека уривків тексту, тестування знань.
133
ЧДТУ.242056.010 ПЗ
- ручне введення: команди на рух, вибір відповіді.
Пристрій пам’яті з прямим доступом для зберігання бази даних;
- дисплей для виведення всіх елементів підсистем: Пересування по рівню,
Взаємодія з неігровими персонажами, Бібліотека уривків тексту,
Тестування знань;
- пересування по рівню: Ця підсистема відповідає за рух головного
персонажа або ігрового об'єкта по рівнях гри. Вона може включати
управління героєм або ігровим об'єктом, його переміщення та взаємодію
з оточуючим світом;
- взаємодія з неігровими персонажами: Ця підсистема обробляє взаємодію
головного персонажа з неігровими персонажами, такими як NPC (non-
player characters). Вона може включати діалогову систему, штучний
інтелект NPC та механізми взаємодії з ними;
- бібліотека уривків тексту: Ця підсистема відповідає за управління
текстовими елементами гри, такими як діалоги, повідомлення, описи
тощо. Вона може зберігати текстові ресурси та забезпечувати їх
виведення в гру;
- тестування знань: Ця підсистема може включати ігрові завдання або
виклики, спрямовані на перевірку знань гравця. Вона може включати
питання, головоломки або інші завдання, які допомагають гравцю
підвищити свої навички або знання;
- ручне введення (команди на рух, вибір відповіді) вказує на можливість
взаємодії гравця з грою через клавіатуру або інший введений пристрій;
- пристрій пам'яті з прямим доступом для зберігання бази даних може
використовуватися для збереження інформації про стан гри, наприклад,
зберігання прогресу гравця, параметрів гри, налаштувань тощо;
- дисплей для виведення всіх елементів підсистем може
використовуватися для відображення графічних елементів гри, таких як
об'єкти, персонажі, текстові повідомлення тощо, а також для
відображення інтерфейсу користувача.
134
ЧДТУ.242056.010 ПЗ
Рисунок 3.1 – Функціональна схема
3.1.3. Опис логічної схеми системи
Опис послідовності дій для проектованого об'єкту, яка призводить до різних
результатів:
Початок гри: Гравець починає гру, запускаючи програму або ініціюючи гру
через інтерфейс користувача.
Гра переходить у стан очікування.
Завантаження рівня:
- гравець обирає рівень або продовжує гру з попереднього місця;
- гра завантажує обраний рівень;
- рівень може містити платформи, NPC та текстові уривки.
Взаємодія з рівнем: Гравець керує персонажем, рухається по рівню, стрибає,
збирає предмети та взаємодіє з NPC.
При досягненні певної точки на рівні або виконанні певних умов, гравець
переходить до наступного етапу.
135
ЧДТУ.242056.010 ПЗ
Відображення текстових уривків.
Під час руху гравця по рівню можуть відображатися текстові уривки.
Гравець взаємодіє з текстом, який може містити питання, на які потрібно
відповісти.
Відповідь на питання:
- гравець намагається дати правильну відповідь на питання, введене через
інтерфейс;
- система перевіряє відповідь та надає відповідний результат.
Завершення рівня або гри:
- після успішного виконання рівня гравець може переходити до
наступного рівня або закінчити гру;
- гра переходить до відповідного стану в залежності від дії гравця;
- цей опис відображає основні дії, які відбуваються у проектованій грі, та
їхній характер.
3.1.4. Розробка бази даних
Розробка бази даних - це процес створення та організації структури для
зберігання та управління даними в інформаційній системі. База даних виступає як
центральне сховище для даних і дозволяє їх зберігання, організацію та швидкий
доступ до них.
Основні етапи розробки бази даних включають:
1 Концептуальне моделювання даних: на цьому етапі створюються моделі,
які відображають поняття та структуру проблемної області з точки зору
замовника. Основними елементами є бізнес-моделі, які допомагають
зрозуміти потреби та вимоги до системи.
2 Логічне моделювання даних: на цьому етапі фіксуються вимоги до
системи з точки зору розробника та описується логічна організація бази
даних. Використовуються діаграми класів для представлення сутностей.
3 Фізичне моделювання даних: на останньому етапі проектується
внутрішня структура бази даних, включаючи таблиці, атрибути та
136
ЧДТУ.242056.010 ПЗ
відносини між ними. Застосовуються діаграми для відображення
фізичної структури бази даних.
Усі атрибути сутностей з логічної моделі автоматично перетворюються у
відповідні стовпці таблиць фізичної моделі. Під час побудови схеми бази даних
можна використовувати різні інструменти, включаючи розширення UML та
автоматизовані системи для моделювання баз даних.
Рисунок 3.2 – Структура бази даних
Таблиця Гравців (Players):
player_id (PRIMARY KEY): унікальний ідентифікатор гравця.
username: ім'я користувача гравця.
password: пароль гравця.
email: електронна пошта гравця.
score: кількість очок, набраних гравцем.
Таблиця Рівнів (Levels):
level_id (PRIMARY KEY): унікальний ідентифікатор рівня.
level_name: назва рівня.
difficulty: складність рівня.
Таблиця Предметів (Items):
137
ЧДТУ.242056.010 ПЗ
item_id (PRIMARY KEY): унікальний ідентифікатор предмета.
item_name: назва предмета.
description: опис предмета.
points: кількість очок, які гравець отримує за збирання предмета.
Таблиця Питань (Questions):
question_id (PRIMARY KEY): унікальний ідентифікатор питання.
question_text: текст питання.
options: варіанти відповідей.
correct_answer: правильна відповідь.
Таблиця Відповідей (Answers):
answer_id (PRIMARY KEY): унікальний ідентифікатор відповіді.
player_id (FOREIGN KEY): ідентифікатор гравця, який надав відповідь.
question_id (FOREIGN KEY): ідентифікатор питання, на яке було надано
відповідь.
chosen_answer: вибрана відповідь.
Таблиця Завершених Рівнів (CompletedLevels):
completion_id (PRIMARY KEY): унікальний ідентифікатор завершеного
рівня.
player_id (FOREIGN KEY): ідентифікатор гравця, який завершив рівень.
level_id (FOREIGN KEY): ідентифікатор завершеного рівня.
completion_date: дата завершення рівня.
3.1.5. Розробка інтерфейсу користувача
Головне меню гри:
Це перший екран, який гравець бачить при запуску гри.
Головне меню має чіткий та привабливий дизайн, що привертає увагу.
Включає в себе такі елементи, як кнопка "Нова гра", "Вибір рівнів",
"Бібліотека уривків творів", "Вихід". Кожна кнопка підсвічується при наведенні
курсора.
Вікно для проведення тестування (рисунок 3.6):
138
ЧДТУ.242056.010 ПЗ
Використовується для відображення запитань та варіантів відповідей під час
тестування або навчання. Включає в себе текст запитання, список варіантів
відповідей кнопку "Обрати відповідь" або "Закінчити тест".
Після завершення тестування відображається результат, з рекомендаціями і
подальшими кроками.
Рисунок 3.3 – Інтерфейс головного меню
139
ЧДТУ.242056.010 ПЗ
Рисунок 3.4 - Інтерфейс меню вибору рівнів – можна вибрати 1 з 3 рівнів
Рисунок 3.5 – Інтерфейс діалогового вікна
140
ЧДТУ.242056.010 ПЗ
Рисунок 3.6 – Інтерфейс меню тестів
3.1.6. Опис розробки програмних компонентів
У даному підрозділі представлено опис розроблених модулів та структурних
компонентів (рисунок 3.7) мобільної гри-платформера для заохочення читання,
розробленої на платформі Unity. У цьому розділі показано призначення кожного
модуля, їх взаємозв'язки з іншими компонентами розробки.
Компонент Гра
- призначення: основний модуль, який керує загальною логікою гри,
запуском рівнів та управлінням станом гри;
- зв’язки: взаємодіє з модулями Рівень, Гравець, НПС, Бібліотека.
Компонент Рівень
141
ЧДТУ.242056.010 ПЗ
- призначення: представляє окремий рівень гри, включаючи платформи,
персонажів та текстові уривки;
- зв’язки: взаємодіє з модулями Гра, Платформа, Персонаж, Уривок
Тексту.
Компонент Персонаж
- призначення: базовий клас для всіх персонажів у грі;
- зв’язки: спільний для модулів Гравець та НПС.
Компонент Гравець
- призначення: клас, що представляє гравця та його дії;
- зв’язки: спадкує від Персонаж, взаємодіє з модулем Рівень.
Компонент НПС
- призначення: клас, що представляє персонажів (NPC) у грі;
- зв’язки: спадкує від Персонаж.
Компонент Платформа
- призначення: клас, що представляє платформи на рівні;
- зв’язки: взаємодіє з модулем Рівень.
Компонент Уривок Тексту
- призначення: клас, що представляє текстові уривки, які гравець повинен
прочитати;
- зв’язки: взаємодіє з модулями Гравець, Рівень, Бібліотека.
Компонент Питання
- призначення: клас, що представляє питання для перевірки розуміння
тексту;
- зв’язки: взаємодіє з модулем Уривок Тексту.
Компонент Бібліотека
- призначення: клас, що містить всі доступні уривки текстів;
- зв’язки: взаємодіє з модулями Гра, Уривок Тексту.
142
ЧДТУ.242056.010 ПЗ
Рисунок 3.7 – Структура проекту
3.2. Тестування системи
Тестування системи - це процес, спрямований на підтвердження коректності
функціонування інформаційної системи в цілому та її програмного забезпечення
зокрема. Результатом цього процесу є виявлення дефектів або підтвердження
мінімального рівня прийнятності. Тестування може включати модульне,
інтеграційне або системне тестування.
Етапи тестування розробленої системи включають:
143
ЧДТУ.242056.010 ПЗ
1 Визначення об’єкту тестування: визначення частин системи, які будуть
піддані тестуванню.
2 Визначення мети тестування: встановлення цілей тестування, таких як
виявлення дефектів, перевірка відповідності вимогам, підтвердження
функціональності тощо.
3 Вибір технології тестування: вибір інструментів та методів для
проведення тестування.
4 Розробка програми тестування: створення скриптів, сценаріїв або
програм для автоматизованого або ручного тестування.
5 Проведення тестування за розробленою програмою: виконання тестів
згідно з розробленою програмою тестування.
6 Підведення висновків з тестування: аналіз результатів тестування,
виявлення дефектів та підготовка звіту з результатами тестування.
Додатково до основних рівнів тестування, необхідно розробити та
застосувати такі типи тестів:
- тести для класів, що базуються на реалізації поведінки;
- тести для класів і малих кластерів класів, що відповідальні за реалізацію
конкретних функцій;
- тести для об’єктно-орієнтованої системи загалом, що базується на
перевірці в робочому режимі.
3.2.1. Модульне тестування
Модульне тестування цих систем - це процес перевірки кожного модуля
окремо на предмет його коректності та відповідності вимогам специфікації перед
включенням їх до загальної системи гри. Ось як це може бути зроблено для
кожного з наведених вами модулів:
Модуль меню гри:
- тестування відображення елементів: перевірка, чи відображаються всі
необхідні елементи меню на екрані гравця;
144
ЧДТУ.242056.010 ПЗ
- тестування інтерактивності: перевірка можливості вибору пунктів меню,
правильного реагування на дії гравця;
- тестування налаштувань: перевірка можливості зміни налаштувань гри
та їх коректного застосування.
Модуль меню вибору рівнів:
- тестування списку рівнів: перевірка наявності всіх доступних рівнів та їх
правильного відображення;
- тестування вибору рівня: перевірка можливості коректного вибору рівня
та переходу до нього;
- тестування інформації про рівні: перевірка відображення інформації про
кожен рівень (наприклад, складність, прогрес тощо).
Система діалогів:
- тестування відображення тексту: перевірка правильного відображення
тексту діалогів на екрані;
- тестування інтерактивності: перевірка можливості вибору відповідей та
їх вплив на хід діалогів;
- тестування зворотного зв'язку: перевірка правильності зворотного
зв'язку після кожної відповіді гравця.
Система тестування знань:
- тестування різних типів питань: перевірка коректності відображення та
функціональності різних видів тестових питань;
- тестування відповідей гравця: перевірка правильності обробки
відповідей гравця та їх впливу на результати тестування;
- тестування оцінки результатів: перевірка правильності розрахунку
результатів тестування та відображення оцінки гравця.
Модуль керування головним героєм:
- тестування руху: перевірка коректності реалізації руху героя відповідно
до введення гравця;
- тестування взаємодії з об'єктами: перевірка можливості взаємодії героя з
оточуючими об'єктами та їхнім впливом на героя;
145
ЧДТУ.242056.010 ПЗ
- тестування анімації: перевірка коректності відображення анімацій руху
та інших дій героя.
Таблиця 3.1
Результати модульного тестування
Компонент Результат
Налаштування Успішний запуск
Список рівнів Успішний запуск
Вибір рівня Успішний запуск
Інформація про рівні Успішний запуск
Відображення тексту Успішний запуск
Запитання Успішний запуск
Оцінка результатів Успішний запуск
3.2.2. Інтеграційне тестування
Інтеграційне тестування цих систем полягає в перевірці їх спільної
працездатності та взаємодії як окремих компонентів. Основна мета -
переконатися, що всі модулі працюють разом і взаємодіють коректно, а також
виявити та виправити можливі конфлікти або проблеми, які можуть виникнути
при їх спільному використанні. Ось деякі кроки, які можуть бути включені в
процес інтеграційного тестування:
- тестування взаємодії модулів: перевірка взаємодії між модулем меню гри
та модулем меню вибору рівнів, наприклад, переконання, що вибраний
рівень правильно відображається у меню гри та спрацьовує коректно;
- тестування цілісності даних: перевірка правильності передачі даних між
модулями, наприклад, перевірка, чи правильно відображаються дані про
прогрес гравця з модуля тестування знань в інші частини гри;
146
ЧДТУ.242056.010 ПЗ
- тестування сценаріїв використання: спроба провести повні сценарії
використання гри, щоб переконатися, що всі модулі працюють разом із
за очікуваними діями гравця;
- тестування взаємодії з різними платформами: перевірка, як гра працює
на різних платформах або пристроях (наприклад, на пк, консолях або
мобільних пристроях), і вирішення можливих проблем адаптації;
- тестування умов реального світу: випробування гри в умовах, які можуть
виникнути в реальному світі, таких як відключення мережі під час гри,
зміна налаштувань пристрою, зміна розміру вікна тощо;
- тестування сумісності: перевірка сумісності гри з різними версіями
операційних систем, різними роздільними здатностями екранів, різними
конфігураціями пристроїв та іншими параметрами.
Таблиця 3.2
Результати інтеграційного тестування
Інтегровані Компоненти Результат
Взаємодія модулів Успішний запуск
Цілісності даних Успішне завантаження залежностей
Сценарій використання Успішне завантаження залежностей
Тестування сумісності Успішне завантаження залежностей
3.2.3. Системне тестування
Системне тестування цих систем - це останній етап тестування, під час якого
вся гра тестується як єдина система, щоб переконатися в її повній
функціональності та відповідності всім вимогам. Основна мета - визначити, чи гра
працює стабільно та ефективно в реальних умовах і вирішити всі виявлені
проблеми. Ось кілька кроків, які можуть бути проведені під час системного
тестування:
Тестування функціональності:
147
ЧДТУ.242056.010 ПЗ
- перевірка всіх основних функцій і можливостей гри згідно з її
специфікацією та вимогами. Включає в себе тестування всіх модулів та
їх взаємодію;
- тестування стабільності: Проведення тривалого тестування гри для
виявлення будь-яких проблем стабільності, таких як збої або витоки
пам'яті. Включає в себе тестування на максимальному навантаженні та в
різних умовах експлуатації;
- тестування відтворюваності помилок: Виявлення і документування всіх
виявлених помилок або несправностей з метою їх подальшого
виправлення. Перевірка, чи можуть виявлені помилки бути відтворені
відтворюваними кроками;
- тестування відновлення після збоїв: Перевірка здатності гри
відновлюватися після виникнення збоїв або втрати з'єднання. Перевірка
збереження прогресу гравця та інших даних;
- тестування звукового та візуального відтворення: Перевірка відтворення
звуків, музики та анімацій у грі на різних пристроях і платформах.
Перевірка наявності та відсутності візуальних або звукових збоїв;
- тестування продуктивності: Перевірка продуктивності гри на різних
пристроях та платформах. Включає в себе тестування швидкості
завантаження, часу відгуку та інші параметри продуктивності;
- тестування сумісності: Перевірка сумісності гри з різними операційними
системами, пристроями та версіями апаратного забезпечення.
Таблиця 3.3
Результати системного тестування
Функціональність/Сценарій Результат
Тестування стабільності Виконання успішне
Відтворення звуків Успішний запуск
Перевірка продуктивності Виконання успішне
Тестування сумісності Виконання успішне
148
ЧДТУ.242056.010 ПЗ
3.2.4. Приймальне тестування
Приймальне тестування (або приймальне випробування) цих систем - це
фінальний етап тестування, який проводиться з метою підтвердження готовності
продукту до випуску та його відповідності вимогам і очікуванням замовника або
клієнта. Основна мета - забезпечити, що гра відповідає всім вимогам та
функціональності, виконується стабільно та безперебійно, та готова до
використання. Ось деякі кроки, які можуть бути проведені під час приймального
тестування:
Перевірка виконання вимог замовника:
- перевірка того, чи були виконані всі вимоги, визначені у специфікації
вимог замовника;
- перевірка, чи всі функції та можливості системи працюють відповідно
до очікувань замовника.
Тестування сценаріїв використання клієнтом:
- проведення тестів, що відтворюють основні сценарії використання гри з
точки зору кінцевого користувача;
- перевірка, чи можна легко навігуватися по грі, вибирати рівні,
взаємодіяти з персонажами тощо;
Тестування стабільності та продуктивності:
- перевірка стабільності гри під час тривалого використання та в різних
умовах експлуатації;
- перевірка продуктивності гри на різних пристроях та платформах.
Тестування звукового та візуального відтворення:
- перевірка якості та правильності відтворення звуків, музики та анімацій
у грі;
- виявлення та виправлення будь-яких виявлених проблем або
несумісностей.
Таблиця 3.4
Результати приймального тестування
149
ЧДТУ.242056.010 ПЗ
Система Результат
Сценарії використання клієнтом Успішно
Стабільність та продуктивність Успішно
Звукове відтворення Успішно
Візуальне відтворення Успішно
3.3. Приклади впровадженого програмного комплексу
Після запуску програми користувач потрапляє в головне меню (рисунок 3.8).
Тут він може почати гру, що запустить перший рівень (рисунок 3.9), або вибрати
інший рівень через меню з рівнями (рисунок 3.10). Також є кнопка для перегляду
всіх розблокованих уривків тексту, щоб повторно їх переглянути. Розглянемо
можливості гри на прикладі першого рівня. Персонаж може взаємодіяти з
неігровими персонажами і оточенням, що викликає вікно репліки чи діалогу
(рисунок 3.11). А в кінці рівня з’являється вікно з тестами (рисунок 3.12) для
перевірки засвоєних знань користувачем. Після запуску програми користувач
опиняється в головному меню. Тут він має можливість розпочати гру, що
запустить перший рівень, або вибрати інший рівень через меню рівнів. Крім того,
є кнопка для перегляду всіх розблокованих уривків тексту, що дозволяє повторно
їх переглянути.
150
ЧДТУ.242056.010 ПЗ
Рисунок 3.8 – Інтерфейс головного меню
Рисунок 3.9 – Локація з твору «Кайдашева сім’я» у грі
151
ЧДТУ.242056.010 ПЗ
Рисунок 3.10 - Інтерфейс меню вибору рівнів – можна вибрати 1 з 3 рівнів
Рисунок 3.11 – Інтерфейс діалогового вікна
152
ЧДТУ.242056.010 ПЗ
Рисунок 3.12 – Інтерфейс меню тестів
153
ЧДТУ.242056.010 ПЗ
Висновок до третього розділу
У цьому розділі було описано процес розробки та тестування програмного
забезпечення, зокрема мобільної гри-платформера для заохочення читання,
використовуючи сучасні технології та інструменти. Основні етапи включали вибір
програмного середовища, розробку алгоритмів та кодування, створення бази
даних, проектування інтерфейсу користувача та тестування.
Для розробки було обрано Unity як основне середовище завдяки його
популярності, кросплатформеності та потужним інструментам для 2D і 3D
розробки. Основною мовою програмування став C# через його інтеграцію з Unity
та простоту у навчанні. SQLite обрано як СКБД через легкість у впровадженні,
кросплатформеність та продуктивність для невеликих обсягів даних.
Важливою частиною розробки стала база даних, структура якої включала
таблиці для гравців, рівнів, предметів, питань, відповідей та завершених рівнів. Це
забезпечувало організацію і зберігання даних, необхідних для функціонування
гри.
Проектування інтерфейсу користувача передбачало створення головного
меню, меню вибору рівнів, діалогового вікна та вікна для проведення тестування.
Це дозволяло забезпечити зручну та інтуїтивно зрозумілу взаємодію гравця з
грою.
Процес тестування системи був спрямований на підтвердження коректності
функціонування гри, виявлення та виправлення помилок. Було визначено, що
вибір Unity, C# та SQLite є обґрунтованим завдяки їхнім перевагам у
продуктивності, кросплатформеності та легкості впровадження, що сприяло
ефективній розробці та оптимізації процесу створення мобільної гри.
154
ЧДТУ.242056.010 ПЗ
ВИСНОВКИ
У кваліфікаційній роботі було успішно розроблено прототип мобільної гри-
платформера, що має на меті заохочення читання серед користувачів. У процесі
дослідження були враховані сучасні тенденції у галузі мобільних ігор,
психологічні аспекти мотивації та навчання через гру, а також технічні аспекти
розробки програмного забезпечення.
Результатом роботи є прототип гри, який поєднує елементи геймплею та
читання, стимулюючи інтерес до читання за допомогою захоплюючих ігрових
механік та інтеграції тексту. Вибір технологій Unity, C# та SQLite обґрунтовано їх
продуктивністю, кросплатформеністю та легкістю впровадження, що сприяло
ефективній розробці гри.
Отримані результати підтверджують потенціал використання мобільних
ігор як інструменту для навчання та розвитку, зокрема для підвищення читацької
активності серед дітей та дорослих. Прототип гри відкриває перспективи для
подальших досліджень та вдосконалення, зокрема для розширення
функціональності, підвищення ігрової складності та покращення інтерфейсу
користувача.
В ході роботи, використовуючи методи інженерії програмного
забезпечення, було проведено аналіз існуючих методів та засобів, що
використовуються для створення освітніх ігор, розроблено модель предметної
області, що охоплює всі необхідні компоненти мобільної гри, сформовано вимоги
до програмного забезпечення, враховуючи потреби замовника і кінцевих
користувачів, спроектовано логічну та архітектурну структуру програмного
комплексу, розроблено програмний комплекс, включаючи базу даних, інтерфейс
користувача та програмні компоненти, проведено тестування розробленого
програмного забезпечення для забезпечення його якості та надійності,
впроваджено гру та оцінено її ефективність у заохоченні дітей до читання.
Практичне значення отриманих результатів полягає в можливості
використання розробленої гри як ефективного інструменту для заохочення
читання у дітей. Гра може бути впроваджена в освітніх закладах або
155
ЧДТУ.242056.010 ПЗ
використовуватися батьками для додаткової навчальної діяльності вдома. Вона
демонструє можливості використання мобільних технологій в освіті та може стати
основою для подальших досліджень і розробок у цій сфері.
Таким чином, дана кваліфікаційна робота демонструє нові можливості
використання інтерактивних медіа у сучасному освітньому процесі та підкреслює
значення ігор як засобу стимулювання навчальних процесів.
156
ЧДТУ.242056.010 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Zoombinis [Електронний ресурс] – Режим доступу:
https://store.steampowered.com/app/397430/Zoombinis/
2 Math Blaster [Електронний ресурс] – Режим доступу:
https://apps.microsoft.com/detail/9nxrr8vlm7pm
3 Unity [Електронний ресурс] – Режим доступу: https://unity.com/
4 Unreal Engine [Електронний ресурс] – Режим доступу:
https://www.unrealengine.com/en-US
5 C# [Електронний ресурс] – Режим доступу: https://learn.microsoft.com/en-
us/dotnet/csharp/
6 C++ [Електронний ресурс] – Режим доступу:
https://learn.microsoft.com/en-us/cpp/?view=msvc-170
7 Godot [Електронний ресурс] – Режим доступу: https://godotengine.org/
8 Python [Електронний ресурс] – Режим доступу: https://www.python.org/
9 Cocos2d-x [Електронний ресурс] – Режим доступу:
https://www.cocos.com/en/cocos2d-x
10 Corona SDK [Електронний ресурс] – Режим доступу:
https://coronalabs.com/
11 Game Maker Studio [Електронний ресурс] – Режим доступу:
https://gamemaker.io/en
12 Construct [Електронний ресурс] – Режим доступу:
https://www.construct.net/en
13 Duolingo [Електронний ресурс] – Режим доступу: https://uk.duolingo.com/
14 Khan academy kids [Електронний ресурс] – Режим доступу:
https://learn.khanacademy.org/khan-academy-kids/
15 Epic! – Kids Books and Videos [Електронний ресурс] – Режим доступу:
https://www.getepic.com/
16 Classdojo [Електронний ресурс] – Режим доступу:
https://www.classdojo.com/uk-ua/
157
ЧДТУ.242056.010 ПЗ
17 Android [Електронний ресурс] – Режим доступу:
https://www.android.com/
18 iOS [Електронний ресурс] – Режим доступу: https://support.apple.com/uk-
ua/guide/iphone/iphfed2c4091/ios
19 SQLite [Електронний ресурс] – Режим доступу: https://sqlite.org/
20 Visual Studio [Електронний ресурс] – Режим доступу:
https://visualstudio.microsoft.com/
21 Adobe photoshop [Електронний ресурс] – Режим доступу:
https://www.adobe.com/ua/products/photoshop.html
22 Illustrator [Електронний ресурс] – Режим доступу:
https://www.adobe.com/ua/products/illustrator.html
23 Git [Електронний ресурс] – Режим доступу: https://www.git-scm.com/
24 Intel [Електронний ресурс] – Режим доступу:
https://www.intel.com/content/www/us/en/homepage.html
25 DirectX 11 [Електронний ресурс] – Режим доступу:
https://www.microsoft.com/en-us/download/details.aspx?id=35
26 Windows 10 [Електронний ресурс] – Режим доступу:
https://www.microsoft.com/uk-ua/software-download/windows10
27 macOS [Електронний ресурс] – Режим доступу:
https://www.apple.com/ua/mac/
158
ЧДТУ.242056.010 ПЗ
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. кафедрою ПЗАС, професор
_________________ Голуб С.В.
„____” ______________ 2024 р.
Мобільна гра-платформер для заохочення читання.
Специфікація
482. ЧДТУ 24 2056.010
Листів 2
Розробник ________________ Пустовіт А. В.
Керівник ________________ Заспа Г. О.
2024
159
ЧДТУ.242056.010 ПЗ
Позначення Найменування Примі
Документація тка
482.ЧДТУ. 24 2056 12 01 Текст програми
482.ЧДТУ. 24 2056 34 01 Інструкція
482.ЧДТУ. 24 2056 90 01 Графічні матеріали
160
ЧДТУ.242056.010 ПЗ
ДОДАТОК Б
Мобільна гра-платформер для заохочення читання.
Текст програми
482.ЧДТУ. 24 2056 12 01
Листів 8
Розробник ________________ Пустовіт А. В.
2024
161
ЧДТУ.242056.010 ПЗ
using UnityEngine;
using UnityEngine.SceneManagement;
public class SceneLoader : MonoBehaviour
{
public string sceneToLoad; // Ім'я сцени, яку ми хочемо завантажити
public string entranceTag = "Entrance"; // Тег для позначення входу
void Update()
{
// Перевіряємо, чи була натиснута клавіша "Пробіл"
if (Input.GetKeyDown(KeyCode.Space))
{
// Завантажуємо сцену з ім'ям sceneToLoad
SceneManager.LoadScene(sceneToLoad);
}
}
private void OnTriggerEnter(Collider other)
{
// Перевіряємо, чи об'єкт, який зіткнувся з тригером, має тег "Entrance"
if (other.CompareTag(entranceTag))
{
// Завантажуємо сцену з ім'ям sceneToLoad
SceneManager.LoadScene(sceneToLoad);
}
}
}
using System;
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class PlayerMovement : MonoBehaviour
{
public float groundSpeed;
public float jumpSpeed;
[Range(0f, 1f)]
public float groundDecay;
public Rigidbody2D body;
public BoxCollider2D groundCheck;
public LayerMask groundMask;
public bool isGrounded;
public float xInput;
public float yInput;
public Animator animator;
162
482.ЧДТУ. 24 2056 12 01 3
void Update()
{
GetInput();
moveWithInput();
}
void FixedUpdate()
{
CheckGround();
ApplyFriction();
}
private void moveWithInput()
{
if (xInput == 0)
{
animator.Play("IdleAnim");
}
else
{
animator.Play("WalkAnim");
}
if (Mathf.Abs(xInput) > 0)
{
body.velocity = new Vector2(xInput * groundSpeed, body.velocity.y);
float direction = Math.Sign(xInput);
transform.localScale = new Vector3(Mathf.Abs(transform.localScale.x) * direction,
transform.localScale.y, transform.localScale.z);
}
if (Mathf.Abs(yInput) > 0 && isGrounded)
{
body.velocity = new Vector2(body.velocity.x, jumpSpeed);
}
}
private void GetInput()
{
xInput = Input.GetAxis("Horizontal");
yInput = Input.GetAxis("Vertical");
}
private void CheckGround()
{
isGrounded = Physics2D.OverlapAreaAll(groundCheck.bounds.min,
groundCheck.bounds.max, groundMask).Length > 0;
}
private void ApplyFriction()
{
84
482.ЧДТУ. 24 2056 12 01 4
if (isGrounded && xInput == 0 && yInput == 0)
{
body.velocity *= groundDecay;
}
}
}
using UnityEngine;
public class NPCMovement : MonoBehaviour
{
public float speed = 2f; // швидкість руху NPC
public float distance = 5f; // відстань, на яку NPC буде рухатися вліво-вправо
private bool movingRight = true; // чи рухається NPC вправо
void Update()
{
// Рухаємо NPC в залежності від напрямку
if (movingRight)
{
transform.Translate(Vector2.right * speed * Time.deltaTime);
}
else
{
transform.Translate(Vector2.left * speed * Time.deltaTime);
}
// Перевіряємо, чи NPC досяг встановленої відстані
if (Mathf.Abs(transform.position.x) >= distance)
{
// Якщо NPC досяг встановленої відстані, міняємо напрямок
movingRight = !movingRight;
// Робимо обертання NPC, щоб він дивився у відповідному напрямку
Vector3 newScale = transform.localScale;
newScale.x *= -1;
transform.localScale = newScale;
}
}
}
using UnityEngine;
using System;
public class CameraFollowPlayer : MonoBehaviour
{
public Transform player; // Reference to the player's Transform component
private float offsetY; // Original y position of the camera
85
482.ЧДТУ. 24 2056 12 01 5
private float offsetZ; // Original z position of the camera
void Start()
{
// Store the initial y and z position offsets of the camera
offsetY = transform.position.y - player.position.y;
offsetZ = transform.position.z - player.position.z;
}
void LateUpdate()
{
// Keep the camera's y and z position unchanged
Vector3 newPosition = new Vector3(player.position.x, transform.position.y,
transform.position.z);
// Set the camera's position to the player's x position and the original y and z offsets
if (!(Mathf.Abs(player.position.x) > 9.5)) {
transform.position = newPosition;
}
}
}
using System;
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class Paralax : MonoBehaviour
{
public Camera cam;
public Transform subject;
Vector2 startPosition;
float startZ;
Vector2 travel => (Vector2)cam.transform.position - startPosition;
float distanceFromSubject => transform.position.z - subject.position.z;
float clippingPane => (cam.transform.position.z + (distanceFromSubject > 0 ?
cam.farClipPlane : cam.nearClipPlane));
float parallaxFactor => Math.Abs(distanceFromSubject) / clippingPane;
void Start()
{
startPosition = transform.position;
startZ = transform.position.z;
}
void Update()
{
Vector2 newPos = startPosition + travel * parallaxFactor;
86
482.ЧДТУ. 24 2056 12 01 6
transform.position = new Vector3(newPos.x, newPos.y, startZ);
}
}
using System.Collections;
using System.Collections.Generic;
using UnityEngine.UI;
using UnityEngine;
using TMPro;
public class DialogueManager : MonoBehaviour
{
public static DialogueManager Instance;
public Image characterIcon;
public TextMeshProUGUI characterName;
public TextMeshProUGUI dialogueArea;
private Queue<DialogueLine> lines;
public bool isDialogueActive = false;
public float typingSpeed = 0.2f;
public Animator animator;
private void Awake()
{
if (Instance == null)
Instance = this;
lines = new Queue<DialogueLine>();
}
public void StartDialogue(Dialogue dialogue)
{
isDialogueActive = true;
animator.Play("show");
lines.Clear();
foreach (DialogueLine dialogueLine in dialogue.dialogueLines)
{
lines.Enqueue(dialogueLine);
}
DisplayNextDialogueLine();
}
87
482.ЧДТУ. 24 2056 12 01 7
public void DisplayNextDialogueLine()
{
if (lines.Count == 0)
{
EndDialogue();
return;
}
DialogueLine currentLine = lines.Dequeue();
characterIcon.sprite = currentLine.character.icon;
characterName.text = currentLine.character.name;
StopAllCoroutines();
StartCoroutine(TypeSentence(currentLine));
}
//IEnumerator TypeSentence(DialogueLine dialogueLine)
//{
// dialogueArea.text = "";
// foreach (char letter in dialogueLine.line.ToCharArray())
// {
// dialogueArea.text += letter;
// yield return new WaitForSeconds(typingSpeed);
// }
//}
//IEnumerator TypeSentence(DialogueLine dialogueLine)
//{
// dialogueArea.text = "";
// foreach (string word in dialogueLine.line.Split(" "))
// {
// dialogueArea.text += word + " ";
// yield return new WaitForSeconds(typingSpeed);
// }
//}
IEnumerator TypeSentence(DialogueLine dialogueLine)
{
int maxVisibleChars = 0;
dialogueArea.text = dialogueLine.line;
dialogueArea.maxVisibleCharacters = maxVisibleChars;
foreach (char letter in dialogueLine.line.ToCharArray())
{
dialogueArea.maxVisibleCharacters = ++maxVisibleChars;
yield return new WaitForSeconds(typingSpeed);
}
}
88
482. ЧДТУ 24 2056 34 01 2
void EndDialogue()
{
isDialogueActive = false;
animator.Play("hide");
}
}
using System.Collections.Generic;
using UnityEngine;
[System.Serializable]
public class DialogueCharacter
{
public string name;
public Sprite icon;
}
[System.Serializable]
public class DialogueLine
{
public DialogueCharacter character;
[TextArea(3, 10)]
public string line;
}
[System.Serializable]
public class Dialogue
{
public List<DialogueLine> dialogueLines = new List<DialogueLine>();
}
public class DialogueTrigger : MonoBehaviour
{
public Dialogue dialogue;
public void TriggerDialogue()
{
DialogueManager.Instance.StartDialogue(dialogue);
}
private void OnTriggerEnter2D(Collider2D collision)
{
if (collision.tag == "Player")
{
TriggerDialogue();
}
}
}
91
ЧДТУ.242056.010 ПЗ
ДОДАТОК В
Мобільна гра-платформер для заохочення читання.
Інструкція користувачеві
482. ЧДТУ 24 2056 34 01
Листів 4
Розробник ________________ Пустовіт А.В.
2024
Після запуску програми користувач потрапляє в головне меню. Воно містить
4 кнопки: почати гру, вибір рівнів, бібліотека уривків творів, вихід (Рисунок B 1).
90
ЧДТУ.242056.010 ПЗ
Кнопка «почати гру» запускає перший рівень (Рисунок B 2). Кнопка «вибір
рівнів» відкриває меню (Рисунок B 3) де можна вибрати 1 з 3 рівнів. Кнопка
«бібліотека уривків творів» відкриває екран для перегляду всіх розблокованих
уривків тексту, щоб повторно їх переглянути.
На рівні персонаж може пересуватися в різні сторони і стрибати. Рух
відбувається за допомогою свайпів. Взаємодіяти з оточенням можна, коли на
екрані з’явиться відповідна пектограма. Є декілька видів взаємодій. Перший –
персонаж говорить репліки, які описують те що його оточує (Рисунок B 4). Вікно
діалогу виглядає так само за виключенням того, що змінюється ім’я і аватар
персонажа який говорить. Другий вид взаємодії – інтерактивне тестування
(Рисунок B 5)
Рисунок B.1 – Інтерфейс головного меню
91
482. ЧДТУ 24 2056 34 01 3
Рисунок B.2 – Локація з твору «Кайдашева сім’я» у грі
Рисунок B.3 - Інтерфейс меню вибору рівнів
92
482.ЧДТУ. 24 2056 90 01 2
Рисунок B.4 – Інтерфейс діалогового вікна
Рисунок В.5 – Інтерфейс меню тестів
95
ЧДТУ.242056.010 ПЗ
ДОДАТОК Г
Мобільна гра-платформер для заохочення читання.
Графічні матеріали
482.ЧДТУ. 24 2056 90 01
Листів 10
Розробник ________________ Пустовіт А.В.
2024
94
ЧДТУ.242056.010 ПЗ
Рисунок Г.1 – Слайд 1
Рисунок Г.2 – Слайд 2
95
482.ЧДТУ. 24 2056 90 01 3
Рисунок Г.3 – Слайд 3
Рисунок Г.4 – Слайд 4
96
482.ЧДТУ. 24 2056 90 01 4
Рисунок Г.5 – Слайд 5
Рисунок Г.6 – Слайд 6
97
482.ЧДТУ. 24 2056 90 01 5
Рисунок Г.7 – Слайд 7
Рисунок Г.8 – Слайд 8
98
482.ЧДТУ. 24 2056 90 01 6
Рисунок Г.9 – Слайд 9
Рисунок Г.10 – Слайд 10
99
482.ЧДТУ. 24 2056 90 01 7
Рисунок Г.11 – Слайд 11
Рисунок Г.12 – Слайд 12
100
482.ЧДТУ. 24 2056 90 01 8
Рисунок Г.13 – Слайд 13
Рисунок Г.14 – Слайд 14
101
482.ЧДТУ. 24 2056 90 01 9
Рисунок Г.15 – Слайд 15
Рисунок Г.16 – Слайд 16
102
482.ЧДТУ. 24 2056 90 01 9
Рисунок Г.17 – Слайд 17
Рисунок Г.18 – Слайд 18
102