З А В Д А Н Н Я
________________________________ Бобошко Ярослава Юрьевича _______________________
(прізвище, ім’я, по батькові)
1. Тема проекту (роботи) Имитационное моделирование динамических систем и _________ процессов с использованием объектно-ориентированного подхода. Моделирование
игры _ «Змейка» __________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
2. Строк здачі студентом закінченого проекту (роботи) 06.06.2013 _______________________
3. Вихідні дані до проекту (роботи) модель проектирования системы, результаты ________ моделирования _________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
4. Зміст розрахунково-пояснювальної записки (перелік питань, які підлягають розробці) _____
Словарь предметной области, объектно-ориентированный словарь предметной области, CRC-карточки, диаграммы классов, объектов, состояний и переходов, взаимодействия, модулей, процессов, протоколы классов, реализация системы, руководство пользователя. ________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень) ____________
Диаграмма классов, диаграмма объектов, диаграмма состояний и переходов, диаграмма взаимодействия, диаграмма модулей, диаграмма процессов. _________________________
_________________________________________________________________________________
_________________________________________________________________________________
6. Дата видачі завдання 28.02.2013 ________________________________________________
| РЕФЕРАТ Пояснительная записка: 34с., 11 рис., 7 табл., 5 источников, 4 прил. Объектом разработки является система имитационного моделирования «Змейка». Целью курсового проектирования является разработка программного продукта – системы имитационного моделирования. В ходе решения поставленной задачи были проведены OOA, OOD и OOP предметной области с помощью метода Аббота и диаграмм Гради Буча. В результате выполнения курсового проектирования были получены такие данные: время игры, имя пользователя, кол-во набранных очков. Программный продукт отличается удобством, простотой в использовании, высокой скоростью выполнения, низким требованием к аппаратному обеспечению. К недостаткам отнесем отсутствие графического меню и графической таблицы статистики. Может применяться в игровой индустрии. В качестве имитационной модели, продукт может быть использован для анализа и оценки функциональности рассматриваемого объекта. ИМИТАЦИОННОЕ МОДЕЛИРОВАНИЕ, ПРОГРАММА, КЛАСС, ОБЪЕКТ, ДИАГРАММА, ИМИТАЦИОННОЕ МОДЕЛИРОВАНИЕ | ||||||||||||||||||||||||
| Д050201.5.01.10/014.КП | ||||||||||||||||||||||||
| Фамилия | Подпись | Дата | ||||||||||||||||||||||
| Разработал | Я. Ю. Бобошко | Имитационное моделирование динамических систем и процессов с использованием объектно-ориентированного подхода. Моделирование игры “Змейка” | Литера | Лист | Листов | |||||||||||||||||||
| Рук. проекта | C.П. Некрашевич | У | ||||||||||||||||||||||
| Е.В. Курило | ДонНТУ, каф. ПОИС группа ПИ 12Г | |||||||||||||||||||||||
| Н. контр. | C.П. Некрашевич | |||||||||||||||||||||||
| Зав. каф. | ||||||||||||||||||||||||
Приложение Б.............................................................................................................................. 25
СОДЕРЖАНИЕ
РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ........................................................................................ 25
Приложение Г. Листинг программы.............................................................. 30
| ||||||||||||||||||||||||
| Разработал | Фамилия | Подпись | Дата | Д050103.1.01.09/190.КП | Лист | |||||||||||||||||||
| ст. гр. ПИ 12Г | Я. Ю. Бобошко | |||||||||||||||||||||||
ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ, СИМВОЛОВ, ЕДИНИЦ,
СОКРАЩЕНИЙ И ТЕРМИНОВ
| ||||||||||||||||||||||||
| Разработал | Фамилия | Подпись | Дата | Д050103.1.01.09/190.КП | Лист | |||||||||||||||||||
| ст. гр. ПИ 12Г | Я. Ю. Бобошко | |||||||||||||||||||||||
ВВЕДЕНИЕ
Данный курсовой проект посвящен моделированию игры “Змейка”. Данная модель позволит с имитировать работу игры и собрать статистические данные. Иными словами, мы получим полностью работоспособный симулятор “Змейки”, проверим качество её работы, возможные недостатки и пути их устранения.
Актуальность данного решения вполне очевидна, создания симулятора с помощью ПО, позволяет не просто получить статистические данные рассматриваемого объекта, но и получить удовольствие.
Целью данного курсового проекта является наглядная демонстрация возможностей объектно-ориентированного программирования, за счет разработки программного обеспечения системы имитационного моделирования и получения статистических данных.
Задачами данного курсового проекта являются: проведение ООА предметной области; проведение ООП разрабатываемой системы; реализация программы с применением ООП; проведение имитационного моделирования и сбор статистических данных.
При моделировании работы игры “Змейка” нас интересует главным образом статистика. Данный курсовой проект показывает на примере как работает ООП.
1 ПОСТАНОВКА ЗАДАЧИ
1.1 Описание предметной области
Змейка двигается по полю 30 на 20 квадратов, которой управляет пользователь. Если змейка наезжает на фрукт, то её длина увеличивается на 1 квадрат и счетчик тоже увеличивается на единицу. Если змейка наезжает на камень, то игра заканчивается, в консоль и в файл выводится время и кол-во очков за игру, после чего счетчик обнуляется; автоматически начинается новая игра. Если змейка переезжает сама себя, то она укорачивается до того места, где переехала себя; показатель счетчика уменьшается на кол-во отброшенных квадратов. Если змейка въезжает на край поля, то она выезжает с противоположной стороны. При старте игры начинается отсчет времени, пока игры не закончится; после окончания игры, значение времени выводится на экран и в консоль, после чего обнуляется.
Характеристики змейки:
1)начальная длинна змейки 2 квадрата;
2)в начале игры змейка появляется в координате (5;5) и двигается вправо.
Характеристики счетчика:
1)начальное значение 0;
2)когда змейка наезжает на фрукт, счетчик увеличивается на 1;
3)когда змейка наезжает на камень, значение счетчика выводится в консоль и в файл, после чего обнуляется.
Характеристики таймера:
1)начальное значение 0;
2)идет отсчет времени, пока не конец игры;
3)как только конец игры, значение таймера выводится в консоль и в файл, после чего обнуляется.
1.2 Цели и задачи
Объектом разработки данной работы является программное обеспечение системы имитационного моделирования игры “Змейка”. Целью является разработка программного обеспечения системы имитационного моделирования и получения следующих статистических данных:
- время от начала до конца игры;
- кол-во набранных очков.
Для достижения поставленной цели необходимо решить следующие задачи.
1. Проведение объектно-ориентированного анализа предметной области;
2. Проведение объектно-ориентированного проектирования разрабатываемой системы;
3. Реализация программы с применением объектно-ориентированного программирования;
4. Проведение имитационного моделирования и сбор статистических данных.
1.3 Выбор средств
Для достижения поставленной цели и решения поставленных задач был выбран объектно-ориентированный подход, так как данный подход является оптимальным решением подобного рода задач и является наиболее простым способом достижения поставленной цели.
В процессе объектно-ориентированного анализа были использованы методы Аббота и CRC карточек. Данные методы как нельзя лучше подходят для выбора объектов и действий, которые в будущем станут операциями и классами нашей программы. Использование данных инструментов ООА существенно упрощают разработку структуры программы, и дают представление из каких модулей будет состоять разрабатываемое ПО.
ОО проектирование включает в себя использование метода диаграмм Гради Буча. За счет использования данных диаграмм, мы наглядно видим отношения составных частей программы и протекающих в ней процессов.
Языком реализации программы является C++ в среде Microsoft Visual Studio.
2 ВЫБОР МЕТОДА РЕШЕНИЯ
2.1 Теоретические сведения
Технология программирования включает в себя совокупность методов и средств разработки ПО и порядок применения этих методов и средств.
В основе ООП лежат следующие положения:
1. ООА. Метод анализа, согласно которому требования рассматриваются с точки зрения классов и объектов, составляющих словарь предметной области.
2. ОО проектирование. Методология проектирования, соединяющая процесс объектно-ориентированной декомпозиции и систему обозначений для представления логической и физической, статической и динамической моделей проектируемой системы.
3. ООП. Методология реализации, при которой программа организуется, как совокупность сотрудничающих объектов, каждый из которых является экземпляром какого-либо класса, а классы образуют иерархию наследования. При этом классы обычно статичны, а объекты очень динамичны, что поощряется динамическим связыванием и полиморфизмом.
4. Класс. Множество объектов с общей структурой и поведением. Термины "класс" и "тип" в большинстве случаев (но не всегда) взаимозаменяемы.
5. Объект. Нечто, чем можно оперировать. Объект имеет состояние, поведение и идентичность.
6. Состояние. Совокупный результат поведения объекта: одно из стабильных условий, в которых объект может существовать, охарактеризованных количественно; в любой конкретный момент времени состояние объекта включает в себя перечень (обычно, статический) свойств объекта и текущие значения (обычно, динамические) этих свойств.
7. Поведение. Действия и реакции объекта, выраженные в терминах передачи сообщений и изменения состояния; видимая извне и воспроизводимая активность объекта.
8. Протокол. Способы, которыми объекты могут действовать и реагировать; полное статическое и динамическое представление объекта; протокол объекта определяет допустимое поведение объекта.
9. Объектная модель. Совокупность основополагающих принципов, лежащих в основе объектно-ориентированного проектирования; парадигма программирования, основанная на принципах абстрагирования, инкапсуляции, модульности, иерархичности, типизации, параллелизма и устойчивости.
10. Инкапсуляция. Процесс разделения элементов абстракции, которые образуют ее структуру и поведение. Служит для отделения внешних обязательств объекта от его реализации.
11. Наследование. Отношение между классами, при котором класс использует структуру или поведение другого (одиночное наследование) или других (множественное наследование) классов. Наследование вводит иерархию "общее/частное" в которой подкласс наследует от одного или нескольких более общих суперклассов. Подклассы обычно дополняют или переопределяют унаследованную структуру и поведение.
12. Полиморфизм. Положение теории типов, согласно которому имена (например, переменных) могут обозначать объекты разных (но имеющих общего родителя) классов. Следовательно, любой объект, обозначаемый полиморфным именем, может по-своему реагировать на некий общий набор операций.
2.2 Описание входных и выходных данных
Входные данные - имя пользователя.
Выходные данные (результаты моделирования):
- кол-во набранных очков;
- имя пользователя;
- время от начала до конца игры.
3 МЕТОД РЕШЕНИЯ
3.1 Объектно-ориентированный анализ
Проведем объектно-ориентированный анализ предметной области, для этого рассмотрим основные сущности в нашей предметной области.
Используем метод Аббота, который заключается в словесном анализе предметной области и получении её словаря и объектно-ориентированного словаря. Нам нужно описать задачу или ее часть на простом языке, а потом подчеркнуть существительные и глаголы. Существительные – кандидаты на роль классов, а глаголы могут стать именами операций[1].
Выделим в заданной предметной области существительные, прилагательные и глаголы. Результаты представлены в таблице 3.1.
Таблица 3.1 – Словарь понятий предметной области
| Существительное | Глагол | Прочее |
| Время Snake Food Stone | Двигаться Есть Появляться | Кол-во очков Существовать Не существовать Время работы |
Далее создадим объектно-ориентированный словарь, выделив сущности, состояния, и функции. Результаты представлены в таблице 3.2.
Таблица 3.2 – ОО словарь предметной области
| Сущность /Сущность | Свойства/Состояние | Метод/Функция/Поведение |
| Snake | Время работы; Кол-во очков. | Двигаться; Есть. |
| Food | существовать; не существовать. | Появиться. |
| Stone | существовать; не существовать. | Появиться. |
Одним из методов при анализе и проектировании задач есть CRC-карточки – удобный способ для определения классов и их взаимодействия. Использование малых карточек позволяет минимизировать сложность дизайна. CRC-карты акцентируют внимание дизайнера на сущности класса и скрывают от него детали, рассмотрение которых на данном этапе будет контрпродуктивным. CRC-карты также заставляют дизайнера воздержаться от назначения классу слишком многих обязанностей [2]. CRC-карточки для классов представлены в таблицах 3.3- 3.5.
Таблица 3.3 – CRC-карточка класса snake
| snake | |
| Состояния: - двигаться | food stone |
Таблица 3.4 – CRC-карточка класса food
| Очередь | |
| Состояния: - существовать; - не существовать. | new |
Таблица 3.5 – CRC-карточка класса stone
| Контролер | |
| Состояния: - существовать; - не существовать. | new |
3.2 Объектно-ориентированное проектирование
Объектно-ориентированное проектирование — это часть объектно-ориентированной методологии, которая предоставляет возможность программистам оперировать понятием «объект», нежели понятием «процедура» при разработке своего кода. Объекты содержат инкапсулированные данные и процедуры, сгруппированные вместе, отображая сущность объекта. «Интерфейс объекта», описывает взаимодействие с объектом, то, как он определен. Программа, полученная при реализации объектно-ориентированного исходного кода, описывает взаимодействие этих объектов[3].
В данном курсовом проекте ОО проектирование будет проводиться при помощи диаграмм Буча. Для демонстрации взаимодействия элементов программы между собой, будут изображены следующие виды диаграмм: диаграмма классов, диаграмма объектов, диаграмма состояний и переходов, диаграмма взаимодействия, диаграмма модулей, диаграмма процессов.
3.2.1 Диаграмма классов
Диаграмма классов показывает классы и их отношения, тем самым представляя логический аспект проекта. Отдельная диаграмма классов представляет определенный ракурс структуры классов. На стадии анализа мы используем диаграммы классов, чтобы выделить общие роли и обязанности сущностей, обеспечивающих требуемое поведение системы. На стадии проектирования мы пользуемся диаграммой классов, чтобы передать структуру классов, формирующих архитектуру системы[1].
Диаграмма классов для заданной предметной области представлена на рисунке 3.1.
Рисунок 3.1 – Диаграмма классов
3.2.2 Диаграмма объектов
Диаграмма объектов показывает существующие объекты и их связи в логическом проекте системы. Иначе говоря, диаграмма объектов представляет собой мгновенный снимок потока событий в некоторой конфигурации объектов. Существенные элементы диаграммы объектов – объекты и их отношения.
Диаграмма объектов для данной предметной представлена на рисунке 3.2
3.2.3 Диаграмма состояний и переходов
Диаграмма состояний и переходов показывает: пространство состояний данного класса; события, которые влекут переход из одного состояний в другое; действия, которые происходят при изменении состояния.
Выделим состояния змейки. Для этого определим признаки, по которым эти состояния отличаются. Такими признаками являются: состояния змейки (0 – стоит; 1 –движется), состояния еды и камней(0 – не существует; 1- существует). Вышеперечисленных признаков 4, обозначим их номерами. Список состояний приведен в таблице 3.1.
Рисунок 3.2 – Диаграмма объектов
Таблица 3.6 – Состояния змейки
| № | Движение змейки | Еда | Камни | Характеристика |
| Змейка движется, камень и еда существуют | ||||
| Змейка съела еду, змейка стоит, камни существуют, еда не существует | ||||
| Змейка стоит, создается новая еда, камни существуют | ||||
| Змейка врезалась в камень(конец игры), камни и еду существуют |
Переходы между этими состояниями осуществляются при наступлении одного из следующих событий:
- движение змейки (д);
- змейка попала в еду (1);
- змейка попала в камень (2).
Диаграмма состояний и переходов для конвейера представлена на рисунке 3.3, в ней используются вышеперечисленные обозначения.
Рисунок 3. 3 – Диаграмма состояний и переходов
3.2.4 Диаграмма взаимодействия
Диаграмма взаимодействия есть просто другой способ представления диаграммы объектов. Преимущество диаграммы взаимодействия в том, что на ней легче читается порядок посылки сообщений. Диаграмма взаимодействия изображена на рисунке 3.4.
3.3 Объектно-ориентированное программирование
Объектно-ориентированное программирование проведено с помощью диаграмм модулей и процессов. Также, в данном разделе описаны протоколы классов.
3.3.1Диаграмма модулей
Диаграмма модулей показывает распределение классов и объектов по модулю в физическом проектировании системы. Каждая отдельная диаграмма модулей представляет некоторый ракурс структуры модулей системы. При разработке мы используем диаграмму модулей, чтобы показать физическое деление нашей архитектуры по слоям и разделам.
Диаграмма модулей системы изображена на рисунке 3.5.
Рисунок 3. 4 – Диаграмма взаимодействия
Рисунок 3.5 – Диаграмма модулей
3.3.2 Диаграмма процессов
Диаграмма процессов используется, чтобы показать распределение процессов по процессорам в физическом проекте системы. Отдельная диаграмма процессов показывает один ракурс структуры процессов системы. При разработке проекта мы используем диаграмму процессов, чтобы показать физическую совокупность процессов и устройств, обеспечивающих работу системы.
Диаграмма процессов представлена на рисунке 3. 6.
|
|
Рисунок 3.6 – Диаграмма процессов
3.3.3 Протоколы классов
В результате проведения объектно-ориентированный анализа предметной области, были выделены основные сущности данной работы. Такими сущностями являются Змейка, еда, камень. Каждая из этих сущностей представляет собой класс объектов.
Протокол класса Змейка.
class snake
{
public:
int x; //координата x
int y; //координата y
} s[500];
Протокол класса Еда.
class Food
{
public:
int x; //координата x
int y; //координата y
void New() //функция случайного создания "еды" на поле
{
x=rand() % N;
y=rand() % M;
}
void DrawApple() //функция цвета "еды"
{
glColor3f(0.0,0.8,0.0); //контур
glRectf(x*Scale,y*Scale,(x+1)*Scale,(y+1)*Scale);
glColor3f(0.1,0.9,0.1);
glRectf((x+0.1)*Scale,(y+0.1)*Scale,(x+0.9)*Scale,(y+0.9)*Scale);
}
} m[10];
Протокол класса Камень.
class Stone //класс камень
{
public:
int x; //координата x
int y; //координата y
void New() //функция случайного создания "камня" на поле
{
x=rand() % N;
y=rand() % M;
}
void Drawlol() //функция цвета "камня"
{
glColor3f(0.5,0.5,0.5); //контур
glRectf(x*Scale,y*Scale,(x+1)*Scale,(y+1)*Scale);
glColor3f(0.25,0.25,0.25); //
glRectf((x+0.1)*Scale,(y+0.1)*Scale,(x+0.9)*Scale,(y+0.9)*Scale);
}
} n[10];
ВЫВОДЫ
В ходе выполнения курсовой работы был проведен объектно-ориентированный анализ предметной области, в ходе которого были выделены основные сущности. На основе выделенных сущностей были спроектированы и реализованы классы.
Для написания данного проекта был выбран объектно-ориентированный подход. В нем собраны лучшие идеи, воплощенные в структурном программировании и сочетает их с мощными новыми концепциями, которые позволяют оптимально организовать программы.
После тестирования программного продукта сделано заключение, что программный продукт в целом удовлетворяет требованиям, предъявленным в техническом задании.
ПЕРЕЧЕНЬ ССЫЛОК
1. Г. Буч. Объектно-ориентированный анализ и проектирование. М. 1992.
2. CRC-карта, режим доступа: https://ru.wikipedia.org/wiki/CRC-карта
3. Объектно-ориентированное проектирование, режим доступа: https://ru.wikipedia.org/wiki/ Объектно-ориентированное_проектирование
4. С.П. Некрашевич, О.О. Савельев. Методические указания к выполнению курсового проектирования по дисциплине «Объектно-ориентированное программирование». – Донецк: ГУИ и ИИ, 2010. – 84 с.
5. Г. Шилдт. Самоучитель С++. 3-е издание. – СПб.: БВХ-Петербург, 2003. – 688 с.
6. С. Мейерс. Наиболее эффективное использование STL – М.: ДМК Пресс, 2002. – 300 с.
7. Т. Павловская. С/С++. Программирование на языке высокого уровня – СПб.: Питер, 2004. – 461 с.
8. Г. Довбуш, А. Хомоненко. VisualC++ на примерах. – СПб: БВХ-Петербург, 2007. – 528 с.
9. А.Н. Шушура. Методические указания по оформлению студенческих работ для студентов специальностей «Системы управления и автоматики», «Системный анализ и управление». – Донецк: ГУИ и ИИ, 2009. – 46с.
Приложение А
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
А.1 Общие сведения
Тема курсового проекта: «Имитационное моделирование динамических систем и процессов с использованием объектно-ориентированного подхода. Моделирование работы игры «Змейка»».
Система проектируется студентом 1-го курса Донецкого национального технического университета, факультета КНТ, группы ПИ - 12 г, Бобошко Я. Ю.
Основанием для разработки ПП является задание, выданное кафедрой ПОИС. Плановый срок начала работы по созданию системы имитационного моделирования: 28.02.2012, срок окончания: 06.06.2013. Курсовой проект должен выполняться согласно графику, приведенному в таблице А.1.
Таблица А.1 – Этапы, результаты и сроки разработки ПП
| № | Этап работы | Результат работы | Срок выполнения (№ недели) |
| Получение задания на КП | Задание на разработку (1 стр.) | 1-2 | |
| Выявление требований к разрабатываемому программному продукту | Техническое задание (3-5 стр.) | 3-4 | |
| Проведение ОО анализа предметной области | Словарь предметной области. Сценарии использования системы. ОО словарь предметной области. | 3-4 | |
| Проведение ОО проектирования | Диаграммы классов, объектов | 5-6 | |
| Проведение ОО проектирования | Диаграммы состояний и переходов, взаимодействия | 7-8 | |
| Проведение ОО проектирования | Диаграммы модулей, процессов | 10-11 | |
| Проектирование протоколов классов | Протоколы классов | 12-13 | |
| Реализация классов | Описание реализации классов | 12-13 | |
| Реализация и отладка программы. Проведение тестирования ПП. | Текст программы. Описание программы и тестов. | 13-14 |
Продолжение таблицы А.1
| № | Этап работы | Результат работы | Срок выполнения (№ недели) |
| Проведение имитационного моделирования, получение статистики работы. | Экранные формы (1-2 стр.). Руководство пользователя (1 стр.). | 13-14 | |
| Оформление пояснительной записки и сопроводительных материалов. | Прошитая ПЗ с CD-ROM (30-50 стр.), сдается преподавателю лично не позже чем за 3 дня до защиты КП. | ||
| Защита курсового проекта | 15-17 |
А.2 Назначения и цели создания программы
Данный программный продукт предназначен для имитации работы динамического объекта игра «Змейка» и получение статистических данных для хранения статистики игры. Статистические данные включают в себя (Имя пользователя, кол-во набранных очков).
А.3 Характеристика объекта автоматизации
Змейка двигается по полю 30 на 20 квадратов, которой управляет пользователь. Если змейка наезжает на фрукт, то её длина увеличивается на 1 квадрат и счетчик тоже увеличивается на единицу. Если змейка наезжает на камень, то игра заканчивается, в консоль и в файл выводится время и кол-во очков за игру, после чего счетчик обнуляется; автоматически начинается новая игра. Если змейка переезжает сама себя, то она укорачивается до того места, где переехала себя; показатель счетчика уменьшается на кол-во отброшенных квадратов. Если змейка въезжает на край поля, то она выезжает с противоположной стороны. При старте игры начинается отсчет времени, пока игры не закончится; после окончания игры, значение времени выводится на экран и в консоль, после чего обнуляется.
Характеристики змейки:
1)начальная длинна змейки 2 квадрата;
2)начале игры змейка появляется в координате (5;5) и двигается вправо.
Характеристики счетчика:
1)начальное значение 0;
2)когда змейка наезжает на фрукт, счетчик увеличивается на 1;
3)когда змейка наезжает на камень, значение счетчика выводится в консоль и в файл, после чего обнуляется.
А.4 Требования к программному продукту
А.4.1 Требования к системе в целом
В целом к системе предъявляются следующие требования:
а) имитация работы игры “Змейка;
б) вывод статистики: результаты работы модели,пока пользователь не выйдет с приложения, кол-во набранных очков за каждую игру, время каждой игры.
А.4.2 Требования к задачам и функциям программного продукта
В процессе работы необходимо обеспечить выполнение следующих функций:
1) ввод начальных параметров для моделирования;
2) вывод характеристик объектов на каждом шаге моделирования на экран:
- время каждой игры;
- имя пользователя;
- кол-во набранных очков в каждой игре.
3) вывод результатов моделирования на экран и в файл.
А.4.3 Требования к техническому обеспечению
К техническому обеспечению предъявляются следующие требования:
1) процессор – 32-битный x86-совместимый (уровня Pentium и выше);
2) объем оперативной памяти – не менее 32Мб;
3) свободное дисковое пространство – около 10 Мб. Не менее 5 Мб свободного дискового пространства для временных файлов;
4) графический адаптер – VGA-совместимый;
5) монитор – VGA-совместимый;
6) клавиатура.
А.4.4 Требования к программному обеспечению
Для стабильной работы к программному обеспечению предъявляется следующее требования:
1) обеспечить удобный и понятный пользовательский интерфейс;
2) реализовать программу в виде отдельных классов;
3) организовать защиту от некорректного ввода начальных
параметров;
4) обеспечить надежное хранение информации.
Программным обеспечением для проектирования программы является CASE-средство Microsoft Visio, а для разработки – Microsoft Visual Studio 2008. Для запуска программы необходимо наличие операционной системы Windows 8, и соответствующих библиотек Microsoft Visual C++ Redistributable.
А.4.5 Требования к организационному обеспечению
В программную документацию должны входить:
1) пояснительная записка;
2) приложения:
- техническое задание;
- руководство пользователя;
- экранные формы;
- листинг программы.
-
А.4.6 Требования к комплекту поставки ПП
Программный продукт поставляется с пояснительной запиской к курсовому проекту в файле ПЗ.doc, руководством пользователя в файле Help.doc, исходными кодами в виде проекта среды разработки в папке SRC, исполнительным файлом программы start.exe и файлом с данными о разработчике readme.txt.
Приложение Б