РАЗРАБОТКА ИГРЫ «МОРСКОЙ БОЙ» С AI

     Из  таблицы 2 видно, что наиболее подходящей моделью жизненного цикла является спиральная модель, так как в ходе проекта ожидается возможное изменение требований.

5. Описание технического задания

     Требования  к функциональным характеристикам:

     Главной функцией игры является игра с искусственным противником, поэтому необходимо реализовать выбор ИИ игроком клетки на основе логики.

     Требования к надежности:

     Так как ПО разрабатывается для мобильного устройства, необходимо обеспечить стабильность работы программы, уделив внимание таким  событиям как входящий вызов, сообщение, сворачивание программы.

     Эргономические и техникоэстетические требования:

     Так как приложение должно гармонично выглядеть  внутри системы, разработку пользовательского  интерфейса необходимо производить  согласно рекомендациям разработчиков Android SDK.

     Требования к защите информации:

     Требования  безопасности к приложению не предъявляются, однако, необходимо защитить исходные коды программы т.к. приложение поставляется в apk файле являющимся обычным архивом.

     Другие требования к разработке:

     Не  предъявляются.

     Требования к аппаратно-программному комплексу:

     Приложение  не является кросс-платформенным, необходимо обеспечить работу приложения на последней  стабильной версии ОС.

     Требования к технологиям разработки:

     Необходимо  использовать среду разработки, обеспечивающее удобное написание Java-кода и стабильную работы плагинов для разработки приложений.

     Требования к составу технических средств при эксплуатации:

     Приложение  пишется для самой последней  версии ОС, следовательно,  для эксплуатации необходимо устройство, удовлетворяющее определённым требованиям.

 

     2 ПРОЕКТИРОВАНИЕ

     2.1 Выбор модели системы

     Игра  разрабатывается по модели локального приложения. Все компоненты приложения будут объединены в один файл, устанавливаемый на устройство.  Приложения будет взаимодействовать с необходимыми уровнями ОС. Использовать встроенные компоненты по работе с БД Sqlite.  Следуя идеологии разработки с использованием предложенных компонентов, в приложении используются компоненты, такие как виджеты ввода и вывода данных на экран и пр.

     2.2 Проектирование структуры  системы

     Основным  и главным компонентом приложения является класс, содержащий в себе функцию, создающую активный процесс. Данный компонент использует необходимые для работы компоненты, включенные в готовый установочный файл, либо предлагаемый ОС.

     

     Рисунок 1.Диаграмма компонентов 

     Как показано на рисунке 1, главный компонент программы обращается к файлам с изображениями, файлу manifest,  в котором описаны разрешения при работе программы. Статистика и аккаунты хранятся в базе данных Sqlite. 

Рисунок 2. Диаграмма классов 

     Для работы с базой данных используется SQLite. Это возможно благодаря классу SQliteOpenHelper и собственному классу DbOpenHelper. Main класс, в соответствие с рисунком 2, содержит необходимые методы для работы приложения в данной среде, такие как onCreate и onClick.

     2.3 Проектирование логики работы

     Большую часть времени система находиться в ожидании действия пользователя. Ожидание хода противника занимается небольшое количество времени, однако, ход не происходит мгновенно.

     Для осуществления противником хода используется неслучайный алгоритм выбора клетки. Алгоритм основан на предполагаемом размещении кораблей игрока. Искусственный противник не имеет  сведений о расположении кораблей игрока, благодаря чему оппоненты находятся  в относительно одинаковых условиях.

     При запуске, система находится в состоянии отображения меню, из которого возможен выход и дальнейшая работа с программой, что видно на рисунке 3. Выбор “начать игру” переводит систему в состояние самой игры, которое включает в себя такие состояния как: отображение игрового поля, расстановка кораблей, ожидание действия пользователя и прочее.  

     Рисунок 3. Диаграмма состояний

      Рисунок 4. Диаграмма Activity

     2.4 Проектирование интерфейса

     Меню  программы, рисунок 5. 

     

     Рисунок 5. Меню программы

 
Выбор способа расстановки в виде диалога, рисунок 6. 

     

     Рисунок 6. Диалог расстановки 

     Игровое поле, рисунок 7. На нём отображаются атаки противника. 

     

     Рисунок 7. Игровое поле 

     Окончание игры, рисунок 8. Поле победитель динамическое и изменяется.

     

     Рисунок 8. Поле окончания игры

     3 РАЗРАБОТКА ПРОГРАММНОГО КОДА

     По  ходу разработки программного кода были изучены такие такие программные средства как AndroidSDK,программирование на языке Java. Получен опыт разработки приложения для мобильных устройств.

     В приложении, учитывая необходимость  обеспечения максимальной производительности программы, были применены следующие меры:

• динамическая отрисовка игрового поля;
• многопоточность (в разных потоках выполняются функции расстановки кораблей и выполнения атаки ИИ противником).

 

     4 ВЕРИФИКАЦИЯ И АТТЕСТАЦИЯ

     4.1 Выбор методов верификации  и аттестации

     При разработке ПО применяются следующие методы:

• основной метод тестирование: “Тестирование Белого Ящика”. Подразумевает тестирование программы с доступными исходными текстами;
• при разработке пользовательского интерфейса применяется тестирование “Чёрного Ящика”, т.к. конечный пользователь не знает о внутреннем устройстве программы.

     Так как ПО создаётся в новой для разработчика среде  и необходимо следить, чтобы внесённые в новый модуль изменения не повлияли на работу остальных модулей, выполняется регрессионное тестирование.

     4.2 Инспектирование

     Требования к разработке:

1. Требования к функциональным характеристикам.

     Меню  приложения: требования невозможно идентифицировать, так как нет доступа к файлу, в котором описывается данная функция.

     Игра: требование описано в Communication Diagramm, пункты на диаграмме – 6 и 7.

     Расстановка кораблей ИИ: требование описано в Activity Diagramm – расстановка кораблей компонента, проверка на правильность расстановки – проверить на возможность расстановки корабля.

     Определение набора кораблей: требование описано в Use Сase Diagramm – выбрать стартовый набор кораблей.

     Просмотр статистики и регистрация: требование описано в Class Diagram – создание пользователя, работа с БД, Communication Diagramm – пункты 4 и 5.

2. Требования к надежности.

     Возможность сворачивания и разворачивание приложения обеспечивается методом onResume и onPause. События  ОС обрабатываются при постановке приложения на паузу. Невозможно проверить данное требование так оно не отражается  в диаграммах.

3. Эргономические и техникоэстетические требования.

     Дизайн  меню и элементов управления должен соответствовать дизайну ОС. Использовать объекты (виджеты), представленные в Android SDK. Не перегружать пользовательский интерфейс излишними элементами. Основное меню должно быть выдержано в тёмных тонах с фоновым изображением на морскую тематику. Игровое поле должно целиком помещаться на экране в вертикальном режиме отображения. Невозможно проверить данное  требование так как к диаграммам оно не относиться.

4. Требование к защите информации.

     Готовое приложение упаковано в apk файл. Защита от реверс-инжинеринга обеспечивается встроенной в среду разработки программой ProGuard. Невозможно проверить данное требование, так как оно не отражается в диаграммах.

5. Другие требования к разработке.

     Реализовать алгоритм выбора клетки для атаки  на основе уже выбранных клеток. Требование описано в ActivityDiagram – ИИ выбирает клетку

6. Требования к аппаратно-программному комплексу.

     Разработка  ориентирована на Android 2.3.4 API Level: 10. Работа возможна на устройствах с различным  типом экрана. Поддержка мультитача не требуется. Требование невозможно проверить, так как оно не отражается в  диаграммах.

7. Требования к технологиям разработки.

     Разработка  ведётся с использованием среды  разработки Eclipse 3.6 (Helios), с установленным ADK плагином, JDK и Android SDK. Требование невозможно проверить, так как оно не отражается в диаграммах.

8. Требования к составу технических средств при эксплуатации.

     Устройство  с поддержкой необходимой версии Android и удовлетворяющее описанным  характеристикам. Требование невозможно проверить, так как оно не отражается в диаграммах.

     Итог: При инспектировании работы были проверены требования в соответствии с техническим заданием. Проверить  удалось не все требования, так  как не все требования описывались в диаграммах. Те требования, что описывались в диаграммах, были выполнены качественно. Диаграммы полностью отображали работу системы на программном уровне. 

     4.3 Тестирование

     При тестировании белым ящиком данные для  теста выбирались с расчётом на рабочие  функции программы.

     При тестировании чёрным ящиком данные для  входных параметров функций генерировались случайно и основываясь на правилах игры. Учитывая, что все функции, отвечающие за игру противника, основаны на генераторе псевдослучайных чисел, необходимо было проводить достаточное количество тестов. 

     5 ПРОГРАММНАЯ ДОКУМЕНТАЦИЯ

     5.1 Инструкция по установке

     Приложение  поставляется в виде apk файла. Рекомендуемые системные требования: Android 2.2. Размер экрана не имеет значения т.к. приложение автоматически подстраивается под нужное разрешение. Для установки необходимо разрешить установку пакетов из сторонних источников.

     5.2 Инструкция пользователя

     При запуске на экране отображается главное  меню с выбором между началом  игры и выходом.

     При начале новой игры возможен выбор  между ручной и автоматической расстановкой кораблей (в данной версии возможно только автоматическая расстановка). Для атаки игрок должен нажать на выбранную клетку. Цвет клетки сообщает игроку о результате атаки. Зелёный - неоткрытая клетка, жёлтый - промах, красный-попадание.

     Во  время хода противника, игрок касается экрана в любой точке, после чего противник атакует. По окончании игры определяется победитель.

 

     ЗАКЛЮЧЕНИЕ

     На  данный момент времени разработаны  следующие компоненты программы:

• главное меню и финальный экран (описаны в xml-файле, следовательно, возможно их свободное редактирование в ходе дальнейшей разработки);
• классы отображения игровых полей и ситуации на поле (все игровые элементы представляют собой графические примитивы, обеспечивающие оптимизированное использование ресурсов устройства);
• классы, обеспечивающие игровые функции (выбор клетки, определение типа клетки, определение результата атаки);
• классы, обеспечивающие запуск и смену Activity, получения контекста устройства, установка связей между видами.