CC BY
65
УДК 004.514
ПОДХОД К ОБУЧЕНИЮ ОБЪЕКТНО-ОРИЕНТИРОВАННОМУ ПРОЕКТИРОВАНИЮ И ПРОГРАММИРОВАНИЮ ЧЕРЕЗ РЕАЛИЗАЦИЮ
ИГРОВОГО ПРИЛОЖЕНИЯ
Искра Наталья Александровна, магистр технических наук, старший преподаватель кафедры ЭВМ, Белорусский государственный университет информатики и радиоэлектроники, Республика Беларусь,
г. Минск, natallia.iskra@gmail.com Близнюк Никита Михайлович, студент, Белорусский государственный университет информатики и
радиоэлектроники, Республика Беларусь, г. Минск, nikbleid@gmail.com Жешко Анастасия Андреевна, студентка, Белорусский государственный университет информатики и радиоэлектроники, Республика Беларусь, г. Минск, anastasiazheshko@gmail.com
Введение
Изучение и освоение объектно-ориентированных технологий - сложный и трудоёмкий процесс. Обучить и подготовить «профессионала под ключ» невозможно; профессионалом можно стать только в результате работы над реальными проектами [1]. В то же время, практико-ориентированный подход, процесс работы над учебным проектом, максимально приближенный к реальным условиям, уже в университете может стать хорошей отправной точкой в формировании специалиста.
Основные этапы освоения объектно-ориентированных технологий
Приёмы программирования на объектно-ориентированном языке (например, Java) можно освоить при работе над несложным игровым приложением [2]. У такого подхода можно выделить ряд преимуществ:
• правила игры известны заранее, их можно однозначно сформулировать, не затрачивая много времени на процесс сбора и извлечения требований;
• такой проект будет обладать простой (можно сказать, типовой) архитектурой;
• используя модульный подход к разработке, можно легко расширять функциональные возможности приложения (например, добавить режим мультиплеера, взаимодействие по сети, сбор и анализ статистики средствами анализа данных и т.д.);
• при работе над таким проектом можно освоить многие аспекты и возможности, предоставляемые языком программирования / технологией;
• и, наконец, такой проект интересно тестировать.
Рассмотрим основные этапы работы над подобного рода проектом:
Этап 1. Изучение основ и средств разработки. Этот этап носит скорее ознакомительный характер. На этом этапе обучаемый знакомится с базовыми приёмами взаимодействия со средствами разработки [3] и контроля версий [4], изучает базовые синтаксические конструкции языка, подходы к стилю кодирования [5]. Практическим результатом данного этапа является подготовленная к работе среда разработки.
Этап 2. Проектирование и создание графического интерфейса пользователя. Самым важным аспектом игрового приложения является интерактивность, то есть взаимодействие с пользователем и обработка событий. На данном этапе необходимо реализовать базовый интерфейс приложения. Работу на данном этапе могут облегчить средства визуального моделирования интерфейса (например, Scene Builder для JavaFX [6]); такие средства позволяют получать готовый исходный код приложения и позволяют лучше освоиться с рабочим языком программирования.
Этап 3. Реализация основных алгоритмов. На данном этапе разрабатывается и реализуется основной алгоритм игрового приложения, проектируется и обосновывается диаграмма классов приложения, разрабатывается системы исключений. В процессе работы
над алгоритмом практически применяются знания по темам «Классы», «Интерфейсы», «Наследование», «Обработка исключений», «Динамическая диспетчеризация методов» и т.д. Кроме того, при реализации алгоритма необходимо включать комментарии в исходный код и/или использовать принципы самодокументирования [7].
Этап 4. Рефакторинг архитектуры приложения на основе объектно-ориентированного и модульного подходов. На данном этапе происходит анализ архитектуры приложения, рефакторинг кода на основе использования паттернов объектно-ориентированного проектирования [11].
Далее, при желании, можно продолжить работу над приложением в следующих направлениях:
• работа с мультимедиа (графика, звук, видео);
• многопоточное программирование;
• взаимодействие по сети (мультиплеер);
• оптимизация вычислений (работа в реальном времени, повышение производительности);
• сбор и анализ статистических данных и др.
Для того, чтобы обучающийся получил представление об инженерии программного обеспечения в целом на данных этапах широко применяются средства моделирования иМЬ [8].
Особенности процесса разработки игрового приложения
Перед тем как перейти к описанию конкретного примера процесса разработки игрового приложения, необходимо отметить некоторые особенности разработки игры, как программного продукта:
• использование специфических алгоритмов обработки событий для обеспечения взаимодействия с пользователем в реальном времени;
• работа с фреймворками;
• особенности объектно-ориентированного анализа игры (например, использование подхода «страйпов» или «вариантов использования 60-ти секунд» [9]);
• использование специфических паттернов проектирования [10] наряду с классическими паттернами [11] или отказ от них в пользу производительности [12].
Рис. 1 - Диаграмма вариантов использования игрового приложения
Рис. 2 - Диаграмма последовательности для основного игрового алгоритма
Необходимо обратить внимание, что в данной работе рассматривается только процесс создания простого программного игрового продукта, то есть не учитываются такие области, как «игровые движки», продвижение продукта и т.п.
Пример процесса разработки
Рассмотрим пример процесса разработки игрового приложения с использованием объектно-ориентированного подхода:
Игра Evil Reign [18] представляет собой мобильную игру в жанре RPG от третьего лица. В игре будет возможен выбор начального класса персонажа, общее дерево развития (пассивные навыки), снаряжение (активные навыки), а также смена снаряжения. Мир будет разбит на зоны. Цель игры - победить финального противника. Сохранения будут храниться локально.
Необходимо реализовать следующие основные функциональные требования:
FR-1. Реализовать меню со следующими возможностями: начать новую игру; продолжить игру; настройки; просмотреть авторов; выход.
FR-2. Должен быть реализован графический интерфейс, содержащий следующую информацию: текущее здоровье; текущая энергия; миникарта.
FR-3. Основными характеристиками персонажей должны быть: сила; ловкость; интеллект; удача.
FR-4. Должны быть добавлены кнопки: инвентарь; дерево навыков; карта; меню.
FR-5. Должны быть реализованы 3 начальных класса персонажей: воин (больше силы и ловкости, меньше интеллекта и средняя удача); разбойник (больше ловкости и удачи, средняя ловкость и низки интеллект); маг (значительно больше интеллекта, больше удачи, мало ловкости и силы).
FR-6. Должна быть возможность сражаться с противником.
FR-7. Персонаж должен иметь возможность изучать новые способности.
Кроме того, при проектировании необходимо учитывать такие нефункциональные требования, как:
NF-1. Графический интерфейс должен занимать не более 25% от всего экрана (это даст возможность случайно не нажимать на кнопки GUI во время боя);
NF-2. Производительность игры должна быть как минимум на среднем уровне (20 fps);
NF-3. Размер игры должен быть менее 2 Гб.
Диаграмма вариантов использования приложения приведена на рисунке 1.
На диаграмме также показано логическое разделение на модули «Главное меню» и «Игра». При этом первый модуль может быть реализован исключительно средствами создания GUI, как описано выше (Этап 2), тогда как второй модуль требует проектирования основного игрового алгоритма. Модуль «Главное меню» соответствует функциональному требованию FR-1. Важно отметить, что для изучения новых способностей игрок обязан выполнять задания и сражаться с противниками (FR-6) для получения опыта, который повышает его уровень, что соответствует функциональному требованию FR-7.
Основной игровой алгоритм (Этап 3) показан на рисунке 2. Основным алгоритмом игры является вариант использования «Сражаться». На диаграмме последовательности показано, что игрок по нажатию на кнопку способности использует её, GameController получает информацию о способности, вычисляет вероятность промаха и наносит урон (при попадании) противнику. Противник, в свою очередь, также может нанести урон персонажу посредством использования своих способностей.
На четвёртом этапе работы над проектом, принимая во внимание нефункциональные требования, было решено провести рефакторинг архитектуры по направлению к использованию следующих характерных для игровых приложений паттернов проектирования:
1. Паттерн «Наблюдатель». Паттерн основан на классическом паттерне [13]. При нажатии на экран будет проанализировано место нажатия и в соответствии с этим обновлено GUI, либо изменены данные. Данный паттерн основан на реализации интерфейсов Observer для наблюдателя и Observable для субъекта. Observable содержит список всех наблюдателей, и при каком-либо событии уведомляет их. Класс Model является субъектом, следовательно реализует интерфейс Observable, класс View - наблюдатель, реализует интерфейс Observer. На рисунке 3 этот паттерн представлен следующими классами: Model, Observable, Observer, View и Controller.
2. Паттерн «Стратегия». Данный паттерн позволяет реализовать поведение различных типов оружия и добавления при необходимости новых видов без внесения изменений в класс, использующий данные оружия (персонаж). Он так же относится к классическим паттернам, однако может быть не менее успешно применен в данной игре. Каждый тип оружия по-своему реализует интерфейс WeaponBehaviour, что позволяет объекту, использующему определенный тип оружия, не заботиться о выполнении действий, характерных для данного типа оружия. Данный паттерн представлен классами WeaponBehaviour, OneHandWeapon, TwoHandWeapon, Weapon, Hero.
3. Паттерн «Game Loop» является специфическим для использования в игровых приложениях [14]. Его назначение - избавиться от строгой зависимости между прогрессом игрового времени, действиями пользователя и возможностями процессора. Этот паттерн относиться к группе паттернов, обеспечивающих улучшение ощущений пользователя при взаимодействии с игрой в реальном времени. На рисунке 3 паттерн представлен классом MainGameLoop, реализующий основные функции Update, OnStart, OnEnd, которые вызываются каждый раз перед началом потока кадров и после остановки кадров соответственно.
GameController
ю
о ft
п
s о
W р
я s to
Байт-код
'"d
s
о
OJ
to
S
Ъ
ъ
й
dodgeChance: Int -blockDamage: int ■»Get Dodge Chancel): int ♦GetBlockDamage(): Int
•GetMoveSpeed(): li
-moveSpeed: Int -dodgeChance: Int • GctMovcSpeed(): int *GetDodgeOianœ(): int
•Get BlockDamage(): int
♦GetReldOfViewO: Int
Стратегия
+OnSpellCllcked() •OnPauseClickedll +OnSpellistClicked() ♦ChecklnputO
ByteCodeParser Spell
-name: string
•GetSpelllnfo( string): string ->6etName(): string ♦Getlnfo(): string
-Items: Ust<ltem>
♦Addtem(ltem) •Removeltem(ltem) ♦Moveltem(ltem. int|2|)
Hero
-characteristics: Characterlstlcts spells: Ust<Spell> -inventory: Inventory
-shoes: Shoes -helmet: Helmet -pants: Pants -left Weapon: Weapon -rightWeapon: Weapon -quests: list<Quest>
•Equipltem(Clothes) <astSpell(lnt) •AddOue st (Quest) +Re move Que st(Quest)
-position: VectorB
Weapon
-damage: int
-attackSpeed: Int
-GetDamagel): int
• GetAttackSpeed(): int
+n*0
«Interface» Weapon Behaviour
Enemy
-spells: Llst<Spell>
-»CheckEnvtromentO -AttacM)
OneHandWeapon WeaponBehavioir wb
TwoHandWeapon WeaponBehaviour wb
¡Игровой цикл
MainGameLoop
•Start GameLoopO
•CndGameloopO
♦PauseGameLoop!)
-OnStartO
-Updated
-OnEndl)
-maxHealth; Int -currentHealth: int -maxEnergy: Int -currentEnergy: mt -strength: int -agility: Int
Int
♦SetHealth(mt)
•GetHealth|): int
+SetEnergy(lnt) ♦GetEnergy(): int ♦SetStrength(lnt) ♦GetStrength!): int ♦SetAglllty(lnt) ♦GetAgillty(): int ♦SetlnteHigence(int) ♦Getlntelllgence«: int
•SaveCurrentGame() •CreateNewGame!) ♦GetSaveFlleNamesI): string •loadGame!) ♦GetlnstanceO
«interface» Observable
objects: Ust<Object>
•AddObJect!) •Re move Object!) -UpdateObjectsf]
Наблюдатель
MainMenu Controller
«OnNewGameCllcked() •On LoadGameC ticked!) ♦OnSettingsCllckedO *On£jdtClicked()
♦AnalzeTap(Polnt) • Update!)
«Interface» Observer
NPC Quest
-descriprion: string
-quests: Map<int. Quest> О-
•GetAvaliableQuests(): List<Quest> ♦FlnlshQuest(Quest): Llst<ltem> •GetDescription(): suing •GetReward(): list<ttem>
4. Паттерн «Bytecode», ещё один специфический игровой паттерн [15]. Применение этого паттерна повышает гибкость игровых данных, что особенно важно при реализации требований FR-3, 4 и 5. Паттерн представлен классами ByteCodeParser и Spell. Данный паттерн позволяет описать поведение той или иной способности и чтение этих параметров игрой без необходимости повторной компиляции для внесения изменений. Информация о заклинаниях хранится в файлах, что позволяет достичь нужной гибкости.
Полная диаграмма классов проектирования с учётом паттернов показана на рисунке 3. Выводы
Таким образом, были рассмотрены основные этапы работы над учебным проектом для освоения технологий объектно-ориентированного проектирования и изучения объектно-ориентированного языка программирования.
В процессе проектирования обучающийся осваивает способы построения архитектуры программного продукта, применяет принципы объектно-ориентированного анализа и проектирования, возможности языка программирования. Широко используются методы объектно-ориентированного моделирования. Кроме того, особое внимание уделяется паттернам проектирования и рефакторингу, поскольку это важное обобщение практического опыта разработчиков [12, 16, 17].
Литература
1. Блинов, И.Н. Java. Методы программирования: уч.-мет. пособие / И.Н. Блинов, В.С. Романчик. -Минск: издательство «Четыре четверти», 2013. - 896 с.
2. Jackson, W. Beginning Java 8 Game Development / W. Jackson. - Apress, New York, 2014. - 461 p.
3. IntelliJ Idea [Электронный ресурс]. - Режим доступа: http://info.javarush.ru/blog/idea_help/. -Дата доступа: 25.10.2016.
4. Chakon, S. Pro Git: Second Edition / S. Chakon, B. Straub. - Apress, New York, 2014. - 574 p.
5. Google Java Style Guide [Электронный ресурс]. - Режим доступа: http://google.github.io/styleguide/javaguide.html. - Дата доступа: 13.10.2016.
6. JavaFX Overview (Release 8) [Электронный ресурс]: Oracle. Java Documentation. - Режим доступа: http://docs.oracle.com/javase/8/javafx/get-started-tutorial/jfx-overview.htm. - Дата доступа: 23.10.2016.
7. Макконнелл, С. Совершенный код: Мастер-Класс / С. Макконнелл, пер. с англ. - М.: Издательство «Русская редакция», 2016. - 896 с.
8. Rumbaugh, J. The Unified Moddeling Language Reference Manual / J. Rumbaugh, I. Jacobson, G. Booch. - Addison Weasley Longman Inc., 1999. - 568 p.
9. Flynt, J. Software Engineering for Game Developers / J. P. Flynt, O. Salem. - Thomson Course Technology, 2005. - 890 p.
10. Nystrom, R. Game Programming Patterns / R. Nystrom. - Genever Benning, 2014. - 354 p.
11. Гамма, Э. Приёмы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма [и др.]; пер. с англ. - СПб.: Питер, 2013. - 368 с.
12. Кериевски, Дж. Рефакторинг с использованием шаблонов: пер. с англ. - М.: Вильямс, 2006. -400 с.
13. Фримэн, Э. Паттерны проектирования / Э. Фримен [и др.]; пер. с англ. - СПб.: Питер, 2014. -656 с.
14. Game Loop. Sequencing Patterns. Game Programming Patterns [Электронный ресурс]. - Режим доступа: http://gameprogrammingpatterns.com/game-loop.html. - Дата доступа: 23.11.2016.
15. Bytecode. Behavioral Patterns. Game Programming Patterns [Электронный ресурс]. - Режим доступа: http://gameprogrammingpatterns.com/bytecode.html. - Дата доступа: 24.11.2016.
16. Фаулер, М. Рефакторинг. Улучшение существующего кода / М. Фаулер; пер. с англ. - СПб.: Символ, 2013. - 432 с.
17. Мартин, Р. Чистый код: создание анализ и рефакторинг. Библиотека программиста. - СПб.:
Питер, 2016. - 464 с.
18. NikitaBliznyuk/evilReign: Game for TRiTPO [Электронный ресурс]. - Режим доступа: https://github.com/NikitaBliznyuk/EvilReign. - Дата доступа: 25.11.2016.
УДК 004.4'236
МАКРО И МИКРОПРИНЦИПЫ ОРГАНИЗАЦИИ ТЕХНОЛОГИЙ РАСПРЕДЕЛЁННЫХ БАЗ ДАННЫХ НА ОСНОВЕ МУОРБД
Микляев Иван Александрович, к.ф-м.н., доцент кафедры информационных систем и технологий, филиал Северного (Арктического) федерального университета имени М. В. Ломоносова в г.Северодвинске Институт судостроения и морской арктической техники (Севмашвтуз), Россия,
Северодвинск, ivanmia 1@rambler.ru Никифоровых Даниил Викторович. студент, филиал Северного (Арктического) федерального университета имени М. В. Ломоносова в г.Северодвинске Институт судостроения и
морской арктической техники (Севмашвтуз), Россия, Северодвинск, nikifordan@gmail.com
Облака, большие данные, аналитика - эти три фактора современных ИТ не только взаимосвязаны. Работа с Большими Данными невозможна без облачных хранилищ и облачных вычислений. Если говорить о влиянии на индустрию в целом, то сегодня стали очевидны возросшие требования к масштабированию систем хранения. Это действительно необходимое условие - ведь заранее сложно предсказать, для каких информационных и аналитических процессов понадобятся те или иные данные и насколько интенсивно будет загружено существующее хранилище. Кроме этого, становятся одинаково важны требования как по вертикальному, так и горизонтальному масштабированию [1].
С другой стороны, при описании каждого экземпляра объектов реального мира необходимо иметь возможность регистрации любых его характерных свойств для любой предметной области задач, которые возникают у пользователей информационной системы, причем независимо от особенностей описания другого экземпляра объектов.
В идеале модель информационного поля объекта должна предельно приближаться реальному её содержанию. Но если оглянуться - мир вокруг нас не является плоским. Действительность многомерна, многогранна, многополярна. Даже если свести реальность к узкой предметной области, то для адекватного отражения необходимо провести всесторонний анализ объектов её составляющих: структурный, пространственный и темпоральный. Потому что большинство объектов из чего-то состоят, где-то находятся и как-то развиваются во времени [3].
Современная синергетическая парадигма науки предполагает системное видение мира, как совокупности динамически изменяющихся структурированных целостностей [2]. Один и тот же объект может включаться в разные системы, а его свойства и характеристики для разных систем имеют различную степень значимости.
Суть объектно-реляционного представления данных в том, что формируется информационное пространство <объект, свойство, свойство-отношение (как объект)> путем определения основных форм и видов информационных объектов, их свойств и природы свойств. Ядро матричной универсальной объектно-реляционной базы данных представляет собой пятимерное пространство, изложенное в семимерном массиве с шестью динамическими осями и одной статической. Сохранены все реляционные свойства, присущие базам данных на реляционной платформе, и реализован весь объектно-ориентированный подход.
Формализованное описание МУОРБД имеет вид:
На первом уровне дискредитации определяется БД из системы реляционных БД (РБД)[4]
