Федеральное агентство по образованию   
САМАРСКИЙ ГОСУДАРСТВЕННЫЙ АЭРОКОСМИЧЕСКИЙ УНИВЕРСИТЕТ имени академика С.П. КОРОЛЕВА 
 

Факультет заочного обучения

Кафедра динамики полета и  систем управления 
 
 
 
 

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к курсовому  проекту по предмету

«Технология программирования» 
 
 
 

     Выполнил  студент 9651 группы: Матвеев О. В.

     Руководитель  проекта: Фадеенков П. В.  
 
 
 
 
 

Самара 2009

Содержание

Введение

     На  заре компьютерной эры очень трудно было написать большую программу, потому что возможности компьютеров были ограничены. Ограничения проистекали из объема оперативной памяти, скорости считывания информации с вторичных носителей и быстродействия процессоров. В 60-70-е годы прошлого века эффективность применения компьютеров резко возросла, цены на них стали падать, а возможности ЭВМ увеличились. В результате стало выгодно, да и необходимо создавать все больше прикладных программ повышенной сложности. В качестве основных инструментов создания программных продуктов начали применяться алгоритмические языки высокого уровня. Эти языки расширили возможности отдельных программистов и групп разработчиков, что в свою очередь привело к увеличению уровня сложности программных систем.

     Было  разработано много методов, помогающих справиться с растущей сложностью программ. Наибольшее распространение получило структурное проектирование по методу сверху вниз. Метод был непосредственно основан на топологии традиционных языков высокого уровня типа FORTRAN или COBOL. В этих языках основной базовой единицей является подпрограмма, и программа в целом принимает форму дерева, в котором одни подпрограммы в процессе работы вызывают другие подпрограммы. Структурное проектирование использует именно такой подход: алгоритмическая декомпозиция применяется для разбиения большой задачи на более мелкие.

     Тогда же стали появляться компьютеры еще  больших, поистине гигантских возможностей. Значение структурного подхода осталось прежним, но оказалось, что структурный подход не работает, если объем программы превышает приблизительно 100000 строк. В последнее время появились десятки методов, в большинстве которых устранены очевидные недостатки структурного проектирования. Большинство этих методов представляют собой вариации на одни и те же темы и их можно разделить на три основные группы:

• метод структурного проектирования сверху вниз;
• метод потоков данных;
• объектно-ориентированное проектирование.

     Структурный подход не позволяет выделить абстракции и обеспечить ограничение доступа к данным; он также не предоставляет достаточных средств для организации параллелизма. Структурный метод не может обеспечить создание предельно сложных систем, и он, как правило, неэффективен в объектных и объектно-ориентированных языках программирования.

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

     В основе объектно-ориентированного проектирования (ООП) лежит представление о том, что программную систему необходимо проектировать как совокупность взаимодействующих друг с другом объектов, рассматривая каждый объект как экземпляр определенного класса, причем классы образуют иерархию. Объектно-ориентированный подход отражает топологию новейших языков высокого уровня, таких как Object Pascal, C++, Java, C#  и др.

Постановка  задачи

     Разработать программу на произвольную тему с использованием принципов объектно-ориентированного программирования. Отразить следующие этапы проектирования: анализ, проектирование, эволюция, модификация.

     В качестве программы была выбрана компьютерная реализация азартной игры «Поймай палкой мячик!».

1 Анализ

     Цель  этапа анализа - максимально полное описание задачи. На этом этапе выполняется анализ предметной области задачи, объектная декомпозиция разрабатываемой системы и определяются важнейшие особенности поведения объектов (описание абстракций).

       Для анализа задачи рассмотрим правила игры:

• Игра идет летающей полкой.
• Цель игры: не дать упасть мячику и разбить все кирпичи.
• В начале игры игроку запускается мячик.
• После удара мячика об кирпич, кирпич исчезает, а мячик отскакивает и летит согласно законам отражения физики.
• Если игрок не успевает поймать мячик полкой, он проигрывает.
• Если разбиты все кирпичи, игрок выигрывает.

1.1 Объектная декомпозиция

     На  основе полученного анализа выполним объектную декомпозицию программы «XPBall».

     Игровой процесс можно смоделировать, используя два объекта: «Интерфейс» (блок управления, который получает и интерпретирует команды пользователя) и объекта – «Игра» (реализация игрового процесса), каждый со своими параметрами (рис. 1).

     

     Рисунок 1. Объектная декомпозиция игрового процесса 

     Далее выполним дальнейшую декомпозицию объектов. Объект «Интерфейс» реализуется из объекта «Форма» (управляющий объект), объекта «Кнопка» и движения мыши получающих команды от пользователя (рис. 2).

     

     Рисунок 2. Объектная декомпозиция объекта «Интерфейс»

     Выполним  декомпозицию объекта «Игра». Объект состоит из управляющего объекта «Движок» и объекта-потока «Поток» (рис. 3).

     

     Рисунок 3. Декомпозиция объекта «Игра» 

     Выполним  декомпозицию объекта «Движок». Объект состоит из объектов «Мяч», «Кирпичи» и «Планка» (рис 4).

     Рисунок 4. Декомпозиция объекта «Движок» 

     На  этом объектную декомпозицию можно  закончить. В результате поэтапной декомпозиции получился набор объектов с простым поведением. 

1.2 Описание абстракций

     В результате объектной декомпозиции можно выделить следующие абстракции:

     Объект «Мяч»: содержит свои координаты, градус полета, скорость полета, диаметр, получает сообщение «Передвинуть», «Отобразить»;

     Объект «Кирпичи»: содержит массив кирпичей с цветами, ширину и высоту одного кирпича, получает сообщение «Отобразить»;

     Объект  «Планка»: содержит свои координаты, высоту, ширину,  получает сообщения «Передвинуть» и «Отобразить»;

     Объект  «Движок»: содержит объекты «Мяч», «Кирпичи», «Планка»,  получает сообщения «Движение мышью» и «Отобразить»;

     Объект «Игра»: содержит объекты «Движок» и «Поток», получает сообщения «Начать игру», «Движение мышью», «Конец игры», «Отобразить».

     Объект «Форма»: содержит объекты «Кнопка» получает сообщение «Кнопка нажата».

     Объект «Кнопка»: передает сообщение «Кнопка нажата» (нажатие пользователем). 

1.3 Структурная схема программного продукта

     Структурная схема программного продукта приведена  на рис. 6.

     

     Рисунок 6. Структрурная схема программного продукта

2 Проектирование

     Проектирование  различают:

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

     Логическое  проектирование заключается в разработке структуры Объектов: определяются поля для хранения составляющих состояния объектов и алгоритмы методов, реализующих аспекты поведения объектов. При этом используются рассмотренные выше приемы разработки Объектов (наследование, композиция, наполнение, полиморфизм и т.д.). Результатом является иерархия или диаграмма Объектов, отражающие взаимосвязь Объектов, и описание Объектов.

     Физическое  проектирование включает объединение  описаний Объектов в модули, выбор схемы их подключения (статическая или динамическая компоновка), определение способов взаимодействия с оборудованием, с операционной системой и/или другим программным обеспечением (например, базами данных, сетевыми программами), обеспечение синхронизации процессов для систем параллельной обработки и т.д.

2.1 Логическое проектирование

     Из-за простоты  проекта основные структуры объектов уже были подробно описаны в разделе описания абстракций.

     Опишем  реализацию основных алгоритмов:

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

     Для равномерного полета мяча вместо использования  таймера реализован поток. 
 

2.2 Физическое проектирование

     Проект  реализован в среде Borland Delphi 7 и предназаначена для выполнения в ОС семейства Microsoft Windows.

     В проект входят следующие модули:

• uObj.pas – модуль  содержит объекты «мяч», «планка» и «кирпичи»;
• uEngine.pas – модуль содержит объект «Движок»;
• uMainThread.pas – модуль содержит объект «Поток»;
• uGame.pas – модуль содержит объект «Форма»;
• uMenu.pas – модуль содержит объект «Меню игры»;
• XPBall.dpr – основной файл проекта.

     Исходные  тексты модулей приведены в приложении А.

3 Эволюция

     Это процесс поэтапной реализации и  подключения классов к проекту. Процесс начинается с создания основной программы или проекта будущего программного продукта. Затем реализуются и подключаются классы, так чтобы создать грубый, но, по возможности, работающий прототип будущей системы. Он тестируется и отлаживается. Например, таким прототипом может служить система, включающая реализацию основного интерфейса программного продукта (передача сообщений в отсутствующую пока часть системы не выполняется). В результате мы получаем работоспособный прототип продукта, который может быть, например, показан заказчику для уточнения требований. Затем к системе подключается следующая группа классов, например, связанная с реализацией некоторого пункта меню. Полученный вариант также тестируется и отлаживается, и так далее, до реализации всех возможностей системы. 

     В данном проекте в процессе эволюции реализуем новое состояние для объекта «Игра» - «Инициализация». Данное состояние будет установлено при первом создании объекта «Движок».

4 Модификация

     Это процесс добавления новых функциональных возможностей или изменение существующих свойств системы. Как правило, изменения затрагивают реализацию класса, оставляя без изменения его интерфейс, что при использовании ООП обычно обходится без особых неприятностей, так как процесс изменений затрагивает локальную область. Изменение интерфейса - также не очень сложная задача, но ее решение может повлечь за собой необходимость согласования процессов взаимодействия объектов, что потребует изменений в других классах программы. Однако сокращение количества параметров в интерфейсной части по сравнению с модульным программированием существенно облегчает и этот процесс.