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	1	1	1	Змейка движется, камень и еда существуют
2	0	0	1	Змейка съела еду, змейка стоит, камни существуют, еда не существует
3	0	1	1	Змейка стоит, создается новая еда, камни существуют
4	0	1	1	Змейка врезалась в камень( конец игры), камни и еду существуют

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

- движение змейки (д);

- змейка попала в еду (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.

Вывод

Процесс Snake

Процесс Food

Процесс Stone

Процесс main

Рисунок 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-карта, режим доступа: http://ru.wikipedia.org/wiki/CRC-карта

3. Объектно-ориентированное проектирование, режим доступа: http://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 стр.)	1-2
2	Выявление требований к разрабатываемому программному продукту	Техническое задание (3-5 стр.)	3-4
3	Проведение ОО анализа предметной области	Словарь предметной области. Сценарии использования системы. ОО словарь предметной области.	3-4
4	Проведение ОО проектирования	Диаграммы классов, объектов	5-6
5	Проведение ОО проектирования	Диаграммы состояний и переходов, взаимодействия	7-8
6	Проведение ОО проектирования	Диаграммы модулей, процессов	10-11
7	Проектирование протоколов классов	Протоколы классов	12-13
8	Реализация классов	Описание реализации классов	12-13
9	Реализация и отладка программы. Проведение тестирования ПП.	Текст программы. Описание программы и тестов.	13-14

Продолжение таблицы А.1

№	Этап работы	Результат работы	Срок выполнения (№ недели)
10	Проведение имитационного моделирования, получение статистики работы.	Экранные формы (1-2 стр.). Руководство пользователя (1 стр.).	13-14
11	Оформление пояснительной записки и сопроводительных материалов.	Прошитая ПЗ с CD-ROM (30-50 стр.), сдается преподавателю лично не позже чем за 3 дня до защиты КП.	14
12	Защита курсового проекта		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.