ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНДУСТРИАЛЬНЫЙ УНИВЕРСИТЕТ
Е.А. Роганов
Информатика Методические указания по выполнению курсовой работы для студентов направления «Прикладная математика и информатика» и специальности «Математическое обеспечение и администрирование информационных систем»
МГИУ Москва 2007
ББК 32.97 УДК 681.3 Р59 Рецензент: И.М. Белова, кандидат физико-математических наук, доцент Московского государственного индустриального университета
Р59
Роганов Е.А. Информатика: методические указания по выполнению кур совой работы для студентов направления «Прикладная математика и информатика» и специальности «Математи ческое обеспечение и администрирование информационных систем». — М.: МГИУ, 2007. — 32 c. Содержат изложение ряда теоретических понятий учебного курса «Информатика», краткое описание языка UML, общих принципов проектирования объектно-ориентированных систем и системы ком пьютерной вёрстки LATEX, несколько вариантов заданий на модифи кацию эталонного проекта и подробный разбор одного из них.
ББК 32.97 УДК 681.3
Редактор Подписано в печать 22.08.07 Формат бумаги 60x90/16 Усл.печ.л. 2,0 Уч.-изд.л. 2,1 Тираж 60
К.В. Шмат Сдано в производство 23.08.07 Бум. офсетная Изд. № 2-47/07 Заказ № 792
РИЦ МГИУ, 115280, Москва, Автозаводская, 16 www.izdat.msiu.ru
[email protected] тел. 677-23-15 © Е.А. Роганов, 2007 © МГИУ, 2007
Оглавление Предисловие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1. Введение
2. Игра «Кирпичики» . . . . . . . 2.1. Базовые компоненты игры 2.2. Физические основы игры . 2.3. Действия игрока . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
6 6 6 9
3. Проектный анализ . . . . . . . . . . . 3.1. Диаграммы случаев использования 3.2. Объекты и классы . . . . . . . . . . 3.3. Отношения между классами . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
10 10 12 13
4. Подготовка пояснительной записки . . . . . . . . . . 4.1. Общие положения . . . . . . . . . . . . . . . . . . . 4.2. Что такое LATEX и зачем он нам нужен . . . . . . . 4.3. Некоторые особенности набора русского языка . . 4.4. Правила оформления рисунков, таблиц и программ 4.5. Дополнительные рекомендации . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
22 22 22 23 24 24
5. Варианты заданий . . . . . . . . . . . . . . . . . . . . . . . . . .
25
6. Пример выполнения курсовой работы
. . . . . . . . . . . . .
28
Список литературы и интернет-ресурсов
. . . . . . . . . . . . .
31
Предисловие Методические рекомендации и указания подготовлены автором на осно ве многолетнего опыта чтения курсов «Основы информатики» и «Методы хранения и обработки информации» (разделы дисциплины «Информати ка») студентам Московского государственного индустриального универси тета (направление «Прикладная математика и информатика» и специаль ность «Математическое обеспечение и администрирование информацион ных систем»). Курсовая работа заключается в выполнении одного из заданий на мо дификацию описанного в пособии проекта — игры «Кирпичики». Этот проект был выбран для обучения студентов концепциям объектно-ориен тированного проектирования и программирования на языке Java потому, что он достаточно прост и допускает различные расширения. Текст эталон ного проекта на языке Java, содержащий многочисленные комментарии, и исходные тексты образца пояснительной записки выдаются студентам вместе с заданием. При разработке проекта и подготовке методического пособия было ис пользовано только свободное программное обеспечение. Его же рекомен дуется применять и при выполнении курсовой работы. Е.А. Роганов. Москва, 2007
1. Введение Эта курсовая работа является первым элементом следующей цепочки: курсовая работа на младших курсах, курсовая работа на старших курсах, дипломная работа, диссертационная работа. Чем дальше вы будете переме щаться по этой цепочке, тем содержательнее должно быть предварительно проводимое теоретическое исследование, больше объёмы написанного ко да, полнее выводы из полученных результатов. Хотя вы пока ещё только первокурсники, уже сейчас полезно пред ставлять себе некоторые аспекты реальной научной работы, более содер жательной и ответственной, чем курсовая. Рекомендации по содержанию именно курсовой работы приведены в разделе, описывающем подготовку пояснительной записки, а пока рассмотрим чуть более общую ситуацию. Следуя определённым традициям, во введении реальной научной ра боты обычно отмечаются следующие моменты, из которых только первые четыре целесообразно использовать в случае курсовой работы: • актуальность темы — следует пояснить, почему проведённая вами работа является важной и интересной; • цели и задачи работы — конкретизируйте, что же вы сделали; • методы исследования — укажите, знания в каких областях матема тики и информатики помогли вам справиться с задачей; • объём работы — количество страниц в пояснительной записке и строк в программах, которые вы написали при выполнении работы; • научная новизна; • практическая ценность; • апробация работы; • публикации.
2. Игра «Кирпичики» В этом разделе описываются правила интерактивной компьютерной иг ра «Kирпичики» (Bricks). Она очень похожа на игру Breakout, одну из первых коммерческих видеоигр, получивших в своё время широкое рас пространение среди пользователей компьютеров Apple II.
2.1 Базовые компоненты игры. «Кирпичики» — это аркадная игра (игра для компьютерных автоматов). Игровое поле представляет со бой прямоугольник, ограниченный двумя стенами, полом и потолком. На поле находится стопка кирпичей, называемая «кучей». Цель играющего за ключается в том, чтобы выбить все кирпичи из кучи, попадая в каждый из них шайбой. Шайба приводится в движение при помощи лопатки, управля емой игроком. При движении она отражается от стен, потолка, кирпичей (которые при этом разбиваются) и лопатки. Падая на пол, шайба выходит из игры. Игрок получает в свое распоряжение три шайбы, первая из которых в начале игры помещается в центр игрового поля и начинает двигаться вниз. Игрок, управляя лопаткой с помощью клавиатуры, должен перемещать её так, чтобы шайба отражалась от неё, а не падала на пол. Когда шайба ударяется об лопатку, она устремляется вверх. В случае падения шайбы на пол она выходит из игры и заменяется на одну из оставшихся шайб. Игра завершается проигрышем, если начальный запас шайб будет израсходован до полного разрушения всех кирпичей. 2.2
Физические основы игры. Во время своего движения по иг ровому полю шайба соприкасается с его различными компонентами. При этом они взаимодействуют между собой описанным ниже образом. • Потолок и стены. Шайба отражается от потолка и стен в соответ ствии с законами физики без учета сил трения и тяжести, в результате чего угол падения равен углу отражения (рис. 1). • Пол. Пол поглощает шайбу. Шайба, упавшая на пол, от него не от ражается, а выходит из игры. • Кирпичи. Шайба отражается от кирпича таким образом, что угол её падения равен углу отражения. При столкновении шайбы и кирпича последний разрушается. Обратим внимание на то, что шайба может ударять кирпич как сверху, так и снизу. Кирпич обладает достаточной толщиной, чтобы шайба могла попасть в него сбоку1 (рис. 2).
1 Реализация отскока шайбы от боковых стенок кирпича является одним из заданий кур совой работы.
Физические основы игры
7
a
a
a
a
a
a
a
Рис. 1. Взаимодействие шайбы с границами поля
#" # " #" # "
##" # " "# "# " # "# "# " #"#"#" ! !!! !!!!! a
Рис. 2. Взаимодействие шайбы с кирпичами
a
8
Игра «Кирпичики»
Ближняя треть
Средняя треть
a
a+e
Дальняя треть
a+e
a
a
a-e
a-e
a
Рис. 3. Взаимодействие шайбы с лопаткой
• Лопатка. Игрок использует лопатку, чтобы управлять движением шайбы. Шайба отскакивает от лопатки, после чего новое направ ление её движения определяется двумя факторами: прежним направ лением и той частью лопатки, о которую приходится удар. Разделим лопатку на три равные части и назовём ближней третью либо ле вую часть лопатки в случае, если шайба попадает в неё, двигаясь слева, либо правую часть, если шайба двигается справа. Дальняя треть определяется аналогично, a средней является оставшаяся часть лопатки. Отражение шайбы будем определять по следующим правилам2 (см. рис. 3): – если шайба попадает в ближнюю треть лопатки, то она отража ется точно в противоположном направлении; – если шайба попaдает в среднюю треть, то угол отражения немно го больше угла падения, однако новое направление движения не может быть вертикальным; – если шайба попадает в дальнюю треть лопатки, то угол отраже ния несколько меньше угла падения, но направление движения шайбы не может стать горизонтальным. 2 Данные правила не реализованы полностью в эталонном проекте — это является ещё одним из заданий на модификацию.
Действия игрока
9
• Шайба. В начале игроку выделяется несколько шайб, однако в игре постоянно участвует только одна шайба. Как только она падает на пол, в игру включается следующая шайба.
2.3 Действия игрока. Игра начинается после нажатия игроком клавиши S (start). Игрок может выйти из игры в любой момент до того, как он выиграет или проиграет, он может приостановить игру (объявить «паузу») и возобновить её после этого. Если игрок выигрывает, то на экран выводится поздравление, в противном случае программа выражает ему своё сочувствие.
3. Проектный анализ В этом разделе будет описано множество объектов, образующих в сово купности игру. Мы будем использовать UML (Unified Modeling Language — унифицированный язык моделирования) в качестве языка описания и Java в качестве языка программирования. Базовые понятия UML, необходи мые для изложения проекта, представлены ниже. Знание основ объектно ориентированного программирования и языка Java предполагаются. Для углублённого изучения рекомендуются следующие книги и интернет-ресур сы: [1–9] .
3.1
Диаграммы случаев использования. При разработке объ ектно-ориентированного программного обеспечения весьма эффективным является формулирование требований к отдельным объектам с помощью случаев использования. Случай использования (use case) описывает, как действующий субъ ект взаимодействует с системой. Действующие субъекты (актёры) испол няют различные роли, в которых пользователи выступают по отношению к системе. В нашем проекте явно присутствует только один субъект (иг рок), но можно предположить наличие ещё одного действующего субъекта (администратора), который при установкe игры на различные компьютеры будет изменять её параметры: размер игрового поля, количество и ско рость шайб и т. д. Основные случаи использования проекта перечислены в таблице 1. Таблица 1. Основные случаи использования
Наименование
Описание
Start (Начало) Pause (Приостановка) Resume (Возобновление) Stop (Конец)
Игрок Игрок Игрок Игрок
начинает сеанс игры делает перерыв в игре возобновляет сеанс игры завершает сеанс игры
Случаи использования упорядочены в иерархию с помощью двух отно шений: uses (использует) и extends (расширяет). Можно уточнить неко торые из случаев использования и развернуть их в наборы более специ фичных случаев (рис. 4). Подобная структура позволяет упростить поиск нужного случая. Следует отметить, что случаи использования являются
Диаграммы случаев использования
11
не программами, а требованиями, которым должно соответствовать про граммное обеспечение.
Рис. 4. Случаи использования игры «Кирпичики»
В контексте конкретного случая использования можно определить один или большее число сценариев. Например, случай использования «Двигать лопатку» порождает следующие сценарии перемещения лопатки влево пе ред её столкновением с шайбой, движущейся слева направо: • перемещение, обеспечивающее столкновение в средней трети лопат ки; • перемещение, обеспечивающее столкновение в дальней трети лопат ки; • перемещение, обеспечивающее столкновение в ближней трети лопат ки. Сценарии применяются к объектам, в которых значения атрибутов кон кретизированы. Это отличает их от случаев использования, которые ори ентированы на работу с объектами без конкретных значений атрибутов. Случаи использования обычно формулируют на естественном языке, а за тем представляют в графической форме в виде диаграммы (рис. 4).
12
Проектный анализ
3.2 Объекты и классы. Описав требования при помощи диаграмм использования, приступим к созданию модели классов игры, часто назы ваемой диаграммой классов. Сначала напомним базовые концепции объ ектно-ориентированного программирования и способы графического пред ставления различных компонент объектного мира при помощи языка UML. Объект — операционная категория, которая содержит значения дан ных (атрибуты) и программный код, манипулирующий этими данными (ме тоды). Объект является основой объектно-ориентированной программы, которую можно рассматривать как совокупность объектов. В процессе вы полнения программы объекты создаются, взаимодействуют друг с другом, изменяются и, наконец, уничтожаются. В игре «Кирпичики» имеется целый ряд различных объектов: лопатка, шайбы, кирпичи, игровое поле и его границы (стены, потолок, пол),— со своими наборами атрибутов и методов. Объект «шайба», например, инкап сулирует такие атрибуты, как размер, форма, положение на игровом поле и текущая скорость, а среди его методов содержатся операции перемещения шайбы и её удаления с игрового поля в случае падения шайбы на пол. Метод — запрос на выполнение определённой операции конкретным объектом. Он состоит из имени и параметров, используемых при выполне нии операции. Класс — описание множества объектов, которые разделяют общие свойства, отношения и смысл. Многие программисты рассматривают класс как шаблон для построения объекта. Объекты являются базовыми элемен тами при выполнении объектно-ориентированных программ, а классы — базовыми элементами при определении таких программ. Любой объект, используемый в объектно-ориентированной програм ме, должен быть экземпляром некоторого класса, который предварительно необходимо спроектировать и реализовать. Различают внешнее представ ление класса (интерфейс) и его реализацию. Интерфейс объявляет воз можности класса, но скрывает его структуру и поведение.
Рис. 5. Диаграмма класса PuckSupply
Отношения между классами
13
Интерфейс, как правило, состоит из объявлений всех операций (мето дов), применимых к экземплярам класса (объектам), и может быть разде лён на три части: • публичную (public), объявления которой доступны всем клиентам (в UML знак «+»); • защищённую (protected), используемую лишь объектами данного клас са и выведенными из него (знак «#»); • закрытую (private), доступную только самому классу (знак «−»). Интерфейс класса PuckSupply (склад шайб) изображён на рис. 5. Этот класс представляет собой набор шайб, выдаваемых игроку в начале игры. Когда шайба выходит из игры (падает на пол), программа заменяет её другой, если их запас ещё не исчерпан. А вот как может выглядеть реализация данного класса на языке Java. class PuckSupply { /* @_puck - массив шайб @_count - кол-во оставшихся у игрока шайб */ private Puck _pucks[]; private int _count; public PuckSupply(int N, PlayField pf, Image pic) { _pucks = new Puck[N]; for (int i = 0; i < N; i++) _pucks[i] = new Puck(pf, this, pic); _count = N; } public int size() { return _count; } /* Взять следующую шайбу из хранилища */ public Puck get() { return _count > 0 ? _pucks[--_count] : null; } }
3.3
Отношения между классами. Классы, используемые в том или ином проекте, не существуют изолированно друг от друга. Между ними всегда имеются определённые отношения, среди которых можно выделить ассоциацию, наследование, агрегацию и зависимость. Ассоциации обеспечивают взаимодействие объектов, принадлежащих разным классам. Они являются «клеем», соединяющим воедино все эле
14
Проектный анализ
менты программной системы. Примером ассоциации является связь класса PuckSupply и Puck (шайба). PuckSupply играет роль хранилища, в кото ром находятся шайбы. Данная ассоциация (рис. 6) предполагает двусторон нюю связь. Для экземпляра класса, реализующего склад шайб, выделяют ся все хранимые шайбы, а для шайбы выделяется экземпляр хранилища.
Рис. 6. Пример ассоциации
При графическом изображении ассоциации каждый из двух концов ли нии, её изображающей, иногда снабжают некоторой меткой, называемой именем роли. Ещё одним параметром, характеризующим классы, связан ные ассоциацией, является кратность, которая указывает количество объектов, участвующих в данном отношении. В нашем проекте количе ство шайб в хранилище может принимать значения от нуля до трёх, что и показано на рисунке. Символ «∗», использованный в качестве кратности, означает диапазон от нуля до бесконечности. Например, на игровом поле может находиться произвольное количество кирпичей. Вот несколько других примеров ассоциаций с различными кратностями: • у европейской жены один муж, у которого одна жена (отношение «один к одному»); • у восточной жены один муж, у которого может быть произвольное число жён (отношение «один ко многим»); • человек может посещать сколько угодно зданий, в каждом из кото рых может находиться произвольное число людей (отношение «мно гие ко многим»). Наследование — это отношение, при котором один класс разделяет структуру и поведение другого класса (простое наследование) или сра зу нескольких классов (множественное наследование). Новый класс на зывается выведенным, производным или подклассом. «Родительский» класс принято называть базовым или суперклассом. Совокупность клас сов, каждый элемент которой непосредственно или косвенно наследует свойства какого-то одного конкретного класса (корневого), называется иерархией наследования. Построим иерархию наследования нашего проекта, корнем которой бу дет класс Sprite. Спрайт — это абстракция, представляющая любой объ ект, который может появиться на игровом поле (слово «спрайт» имеет
Отношения между классами
15
исторические корни и является «стандартом» для аркадных игр). Его атри бутами являются: изображение (визуальный образ), положение на игровом поле и размеры (ширина и высота). MovableSprite (подвижный спрайт) — это спрайт, способный изме нять свое местоположение. С таким спрайтом ассоциирована скорость движения в текущий момент времени. Скорость (Velocity) представлена направлением движения и расстоянием, преодолеваемым за единицу вре мени. В нашем проекте подвижными спрайтами являются шайба (Puck) и лопатка (Puddle). StationarySprite (неподвижный спрайт) не меняет своего положения на игровом поле. Единственным примером такого спрайта в проекте явля ется кирпич (Brick). При изображении иерархии классов принято отно шение наследования указывать стрелкой с незакрашенным наконечником, направленной от производного класса к базовому (рис. 7).
Рис. 7. Иерархия классов
Агрегация — описывает отношение «является частью». Например, можно сказать, что двигатель и колёса являются частью автомобиля. Кро ме агрегации в языке UML определено более сильное понятие, называемое композицией. При композиции объект-часть может принадлежать только одному целому и, как правило, жизненный цикл части совпадает с жиз ненным циклом целого, то есть части живут и умирают вместе с целым. Агрегацию изображают в виде стрелки с наконечником в форме ромба. Зависимость — это отношение, которое показывает, что изменения в одном классе могут повлиять на другой. Графически зависимость изоб ражается пунктирной стрелкой, идущей от зависимого класса к тому, от которого он зависит. Наиболее часто зависимости показывают, что один
16
Проектный анализ
Рис. 8. Отношение зависимости
класс использует другой класс в качестве аргумента какого-то из своих методов. Например, в рамках нашего проекта подвижный спрайт может столкнуться с любым другим спрайтом. Данная зависимость представлена в виде метода collideInto класса MovableSprite, аргументом которого может быть любой спрайт, находящийся на игровом поле (рис. 8). Диаграмма классов, изображённая на рис. 9, представляет статическую картину проекта, учитывающую связи между различными классами. Функ ции многих из них уже были описаны, и теперь достаточно пояснить на значение оставшихся. Match — описывает сеанс игры, непосредственно связанный с игроком. Сеанс игры может быть начат (start), приостановлен (stop) и возоб новлён (resume). Игрок может проиграть (loose) или выиграть (win). С сеансом ассоциированы игровое поле, кирпичи и шайбы. Рассмотрим более подробно назначение класса PlayField (игровое по ле). На нём изображaются все игровые объекты, которые хранятся в спе циально созданном для этого классе — векторе спрайтов, отвечающем за обновление (update) и перерисовку (draw). Под обновлением подра зумевается любое изменение состояния спрайта, например, перемещение лопатки или разбивание кирпича шайбой, влекущее за собой его удаление с игрового поля. Классы PuckSupply и BrickPile — контейнеры. Первый содержит шайбы, а второй хранит кирпичи и задаёт положение каждого из них на игровом поле. С помощью PuckSupply можно узнать о проигрыше игро
Отношения между классами
17
Рис. 9. Диаграмма классов
ка (все шайбы закончились), а BrickPile предоставляет информацию о выигрыше (все кирпичи разбиты). Теперь расскажем более подробно о реализации класса Sprite. По ложение и размеры спрайта задаются атрибутом _pos типа Rectangle (прямоугольник). Пересечение двух спрайтов testCollision находится как пересечение двух принадлежащих им прямоугольников-позиций1 . Ме тод isDead отражает состояние спрайта: «жив» или «мёртв». «Мёртвый» спрайт удаляется с игрового поля. Вот как выглядит абстрактный класс Sprite: 1 Такой способ называется простой прямоугольной коллизией. Существуют и более со вершенные методы, основанные на данных изображения спрайта.
18
Проектный анализ
abstract class Sprite { /* @_img - изображение спрайта @_pf - игровое поле @_pos - позиция и размеры спрайта @_isDead - состояние - "мертв", "жив" * Мертвый спрайт удаляется с игрового поля. */ protected Image _img; protected PlayField _pf; protected Rectangle _pos; protected boolean _isDead; ... public void draw(Graphics g) { g.drawImage(_img, _pos.x, _pos.y, _pf); } /* Проверка на наличие коллизии. */ public boolean testCollision(Sprite s) { if (s != this) return _pos.intersects(s.getBounds()); return false; } /* Взять ограничивающий прямоугольник спрайта. */ public Rectangle getBounds() { return _pos; } /* Мертв или жив? */ public boolean isDead() { return _isDead; } ... }
MovableSprite расширяет базовый класс Sprite, добавляя возмож ность движения при помощи метода move, который контролирует также столкновения как с границами игрового поля, так и с другими спрай тами. В случаях столкновения с другими спрайтами вызывается метод collideInto, а столкновения с границами игрового поля обрабатываются отдельно. class Puck extends MovableSprite { ...
Отношения между классами
19
public void move() { if (!_isMoving) return; Rectangle b = _pf.getBoundary(); _prevPos = _pos; _pos.translate(_v.getSpeedX(), _v.getSpeedY()); /* Oбработка соударения со стенами, полом и потолком. */ if (_pos.x <= b.x) { _pos.x = b.x; _v.reverseX(); } else if (_pos.x + _pos.width >= b.width + b.x) { _pos.x = b.x + b.width - _pos.width; _v.reverseX(); } else if (_pos.y <= b.y) { _pos.y = b.y; _v.reverseY(); } else if (_pos.y + _pos.height > b.y + b.height) { /* Шайба упала на пол */ _isDead = true; if (_ps.size() == 0) { _pf.getMatch().loose(); } else { _pf.addSprite(_ps.get()); } } /* Обработка соударения с другими спрайтами. */ if (collideWith() != null) { _pos = _prevPos; collideInto(collideWith()); } } /* Реакция на возникновение коллизии. */ public void collideInto(Sprite s) { s.hitBy(this); } ... }
Класс Velocity отвечает за движение подвижного спрайта по полю; его компонентами являются абсолютная величина скорости и направление движения. Величина скорости задаётся в некоторых условных единицах, а направление — в градусах (при этом 0 означает движение на восток, 90 — на юг и так далее, см. рис. 10).
20
Проектный анализ
dx a dy
speed
Рис. 10. Задание скорости
Атрибут «скорость» разделён на две составляющих: dx и dy — про екции скорости на горизонтальную и вертикальную оси соответственно. В то время как величина скорости всегда неотрицательна, её составляющие могут принимать произвольные значения. class Velocity { /* @_dx - составляющая скорости по оси Х @_dy - составляющая скорости по оси Y @_speed - скорость спрайта */ private double _dx, _dy; private int _speed; public Velocity(int D, int S) { _speed = S; setDirection(D); } public int getSpeed() { return _speed; } public int getSpeedX() { return (int) _dx; } public int getSpeedY() { return (int) _dy; }
Отношения между классами
21
public void setDirection(int d) { _dx = Math.cos(Math.toRadians(d)) * (double) _speed; _dy = Math.sin(Math.toRadians(d)) * (double) _speed; } public int getDirection() { return ((int) Math.toDegrees(Math.atan2(_dy,_dx)))%360; } /* инвертировать направление движения */ public void reverse() { _dx = -_dx; _dy = -_dy; } /* инвертировать направление по оси Х*/ public void reverseX() { _dx = -_dx; } /* инвертировать направление по оси Y*/ public void reverseY() { _dy = -_dy; } }
Класс Velocity содержит также методы setDirection, reverseX, reverseY и reverse, позволяющие повысить эффективность программы, устраняя необходимость создания новых экземпляров класса всякий раз, когда изменяется направление движения.
4. Подготовка пояснительной записки 4.1 Общие положения. Обычно в любой работе должно быть не менее трёх разделов. Приложение (или приложения) с текстами программ ´ не должны составлять большую часть работы. Хорошо, когда в рабо те имеются таблицы, рисунки или диаграммы и математические форму лы. Возможна, например, следующая структура пояснительной записки (не включающая в себя такие компоненты, как оглавление и библиографи ческий список): • • • • • •
подробная постановка задачи (с точки зрения пользователя); взгляд на задачу с точки зрения программиста; изложение необходимых для решения задачи теоретических аспектов; описание используемых структур данных и применяемых алгоритмов; возможные обобщения рассматриваемой задачи; приложения с фрагментами программ.
Для подготовки записки следует использовать LATEX и пакет memoir, размещённый в сети по адресу [10]. В университетской сети все необходи мые программы установлены; для работы на домашнем компьютере, воз можно, потребуется установить ряд дополнительных пакетов, являющихся свободными. Вместе с вариантом задания выдаётся образец пояснительной запис ки, содержащий, в частности, головной файл main.tex и стилевой файл msiumemoirbooklet.sty, в котором подключаются дополнительные паке ты, определяются размеры полей, стиль оформления страниц и целый ряд иных параметров и макросов. Wikipedia — свободная интернет-энциклопедия — содержит весьма подробную информация о системе LATEX [11]. С кратким курсом по работе в этой системе можно ознакомиться, например, на сайте Интернет-универ ситета [12] . Небольшой фрагмент введения из этого курса приведён ниже.
4.2
Что такое LATEX и зачем он нам нужен. Система ком пьютерной вёрстки TEX (произносится «тех») была создана выдающимся американским математиком и программистом Дональдом Кнутом в конце 70-х годов XX века; издательские системы на её базе по сию пору широко используются и сдавать позиции не собираются. Чем объясняется столь редкое в компьютерном мире долголетие? На первый взгляд, всё свидетельствует против TEX’а. В самом деле, в отличие, допустим, от популярного Microsoft Word’а, TEX не является
Некоторые особенности набора русского языка
23
системой типа WYSIWYG (What You See Is What You Get): чтобы посмот реть, как будет выглядеть на печати набираемый текст, надо запустить отдельную программу. И по структуре файлов TEX несовместим с Word. Наконец, чтобы использовать TEX, надо потратить определённое время на его изучение: трудно представить себе книгу под названием "TEX for dummies" («TEX для болванов»). Вот краткий перечень достоинств системы компьютерной вёрстки TEX: 1) Никакая другая из существующих в настоящее время издательских си стем не может сравниться с ней в полиграфическом качестве текстов с математическими формулами. 2) Система TEX реализована на всех современных компьютерных плат формах, и все эти реализации действительно работают одинаково. 3) Благодаря этому TEX стал международным языком для обмена матема тическими, физическими и программистскими статьями: набрав свою статью, математик может послать её по электронной почте своему кол леге, даже если отправитель работает под Windows, а получатель — в Linux или, допустим, на Mac OS. 4) В Интернете существуют обширные «архивы препринтов», в которые каждый может послать (и из которых каждый может получить) статью; все эти статьи набраны опять-таки с использованием TEX. 5) Наконец, основные реализации системы компьютерной вёрстки TEXдля всех платформ распространяются бесплатно.
4.3 Некоторые особенности набора русского языка. При подготовке пояснительной записки рекомендуется использовать букву «ё», кавычки-ёлочки (например, <<Информационные технологии>>) и курсив при наборе единиц измерения (кг, м/сек2). При записи инициалов рекомен дуется применять «сверхтонкий пробел» (\+) между именем и отчеством и «неразрывный пробел» (~) между отчеством и фамилией: И.\+И.~Иванов. Следует использовать по назначению тире (—), «указатель диапазо на» (–), дефис (-) и математический знак «минус» (−). Перед тире ре комендуется ставить «неразрывный пробел», а после него — обычный: после него~--- обычный. Указатель диапазона применяется, например, при указании страниц: стр. 15–17 (набирается как стр. 15--17). Для на бора дефиса используют один минус: объектно-ориентированный, а для получения знака операции «минус» требуется применять математический режим: число −2 набирается как $-2$. Сокращения словосочетаний «и так далее» и «и тому подобное», ко торые завершают предложение, набираются так: и~т.\,д., и~т.\,п. Не
24
Подготовка пояснительной записки
рекомендуется использовать подобные сокращения для словосочетаний, находящихся в середине предложения.
4.4
Правила оформления рисунков, таблиц и программ.
Стандартный стиль оформления рисунков и таблиц — использование окру жений figure и table. При этом обязательно следует применять макрос caption для набора подписи. Алгоритмы и тексты программ целесообраз но размещать в отдельных файлах и подключать с помощью окружения programinput. Рисунки необходимо представлять в двух форматах (eps и png), а при наборе таблиц руководствоваться рекомендациями, содержа щимися в руководстве memman.pdf.
4.5 Дополнительные рекомендации. При наборе математиче ских формул следует нумеровать только те из них, на которые имеются ссылки. Для получения полужирного шрифта в математических форму лах можно применять команду \bm, а для набора теорем, лемм и дока зательств — окружения \theorem, \lemma и \proof соответственно. Настоятельно рекомендуется использовать только те команды пере ключения шрифтов, которые поддерживаются пакетом memoir без опции oldfontcommands. Для набора нумерованных списков целесообразно использовать окру жение \enumerate в следующем виде: \begin{enumerate}[1)]. При подготовке пояснительной записки обязательно просматривайте информацию, которую LATEX размещает в log-файле. Это поможет вам избежать многих ошибок и значительно облегчит последующую защиту курсовой работы. Более подробное изложение различных возможностей, предоставляе мых пакетом LATEX, содержится в книге С.М. Львовского [13] . Для более глубокого изучения предмета полезно ознакомиться с классической книгой Дональда Кнута [14]. Полезным может оказаться также изучение исход ных текстов данного методического руководства.
5. Варианты заданий В каждом из приведенных ниже вариантов курсовой работы требуется: 1) проанализировать полученное задание и найти способ модификации эталонного проекта, обеспечивающий выполнение задания; 2) изобразить все изменения, сделанные в проекте, при помощи диа грамм случаев использования и диаграммы классов; 3) реализовать новый проект, внеся необходимые изменения в интер фейсы и реализации классов. Все задания на включение нового типа кирпичей предполагают, что из общего количества кирпичей двадцать процентов будут новыми. Вариант 1. Добавить новый вид кирпичей. Крепкий кирпич (HardBrick) исчезает с игрового поля только при двукратном попадании в него шай бой. При первом попадании он должен покрыться трещинами (подмена растрового изображения). Вариант 2. Добавить новый вид кирпичей. При попадании в такой кирпич (PowerBrick) шайба увеличивает скорость движения на два пункта. Вариант 3. Добавить новый вид кирпичей. Кирпич (WallBrick) нельзя разбить шайбой. Игра заканчивается, когда разбиты все кирпичи, кроме таких. Вариант 4. Добавить новый вид кирпичей. При попадании в «липучий» кирпич (StickyBrick) шайба прилипает к нему на две единицы времени, а затем вертикально падает. Данный кирпич нельзя разбить шайбой. Игра заканчивается, когда разбиты все кирпичи, кроме «липучих». Вариант 5. Добавить новый вид кирпичей. Защищённый или бронирован ный кирпич (ArmorBrick) можно разбить только в том случае, когда шайба попадёт в него сверху (со стороны потолка). Вариант 6. Добавить новый вид кирпичей. При попадании шайбы в кир пич-ловушку (TrapBrick) снизу шайба теряется. Кирпич уничтожается при ударе шайбы с любой другой стороны. Вариант 7. Добавить редактор уровней. Информация о положении кир пичей на игровом поле должна содержаться в обычном текстовом файле в следующем формате: B означает наличие кирпича, а пробел — отсутствие. Файл конфигурации загружается при помощи меню в верхней панели.
26
Варианты заданий
Вариант 8. Добавить «мультфильмы», т.е. возможность воспроизведе ния игры (передвижения шайбы и лопатки, разбиваниe кирпичей) после её окончания. Вариант 9. Добавить таблицу очков. В случае выигрыша программа запра шивает у игрока имя и записывает его в файл score.txt вместе с числом набранных им очков, которое зависит от количества разбитых кирпичей и затраченного времени. Таблицу очков нужно просматривать с помощью меню. Вариант 10. Добавить свойство прилипания шайбы к лопатке. Игрок нажимает клавишу «пробел», после чего при столкновении шайбы с ло паткой шайба не отскакивает, как обычно, а остаётся на лопатке. Игрок может прицелиться, передвигая лопатку, и затем, выбрав цель, «выстре лить» шайбой, повторно нажав клавишу «пробел». Этой возможностью можно воспользоваться только один раз. Вариант 11. Изменить свойства стен таким образом, чтобы при отскоке шайба вылетала из противоположной стены, сохраняя при этом направле ние и скорость (рис. 11).
Рис. 11. Изменённый вариант отскока от стен
Вариант 12. Добавить «уровни». Каждый раз когда игрок выигрывает, программа создаёт новый уровень, случайным образом расставляя кирпичи в некотором ограниченном прямоугольнике игрового пространства. Вариант 13. Изменить реализацию классов-хранилищ PuckSupply и BrickPile таким образом, чтобы они использовали стандартный интер фейс java.utils.Enumeration. Вариант 14. Добавить возможность перемещения лопатки при помощи мыши.
Варианты заданий
27
Вариант 15. Добавить «бонусный» кирпич (BonusBrick), при разбивании которого появляется дополнительная шайба, которая падает вертикально вниз. С этого момента в игре участвуют одновременно две шайбы. Вариант 16. Добавить «бонусный» кирпич (BonusBrick), при разбива нии которого появляется «бонус» (красный круг), который затем падает вертикально вниз. Игра заканчивается проигрышем, если игрок не успеет поймать его при помощи лопатки. Вариант 17. Реализовать правила отскока шайбы от лопатки, описанные в первом разделе пособия (см. рис. 3). Вариант 18. Реализовать корректный отскок шайбы при её попадании в боковые стенки кирпича.
6. Пример выполнения курсовой работы Рассмотрим задание первого варианта, где требуется добавить новый вид кирпича, при попадании в который в первый раз кирпич изменяет свое графическое представление, а во второй раз — разбивается и удаляется с игрового поля. В начале игры число таких кирпичей должно составлять двадцать процентов от их общего количества. Начнём модернизацию с добавления нового класса в иерархию спрай тов. Очевидно, что HardBrick должен унаследовать свои свойства от клас са Brick. Нам необходимо добавить два новых атрибута: счётчик ударов шайбы (при создании равен одному) и графическое изображение повре ждённого кирпича. Далее необходимо переопределить метод hitBy, вы зываемый при ударе шайбы по кирпичу. Представим эти изменения при помощи диаграммы классов (рис. 12).
Рис. 12. Добавление HardBrick в иерархию спрайтов
Пример выполнения курсовой работы
29
Основные изменения в программном коде сводятся к модификации ме тода hitBy. import java.awt.Image; import java.awt.Rectangle; class HardBrick extends Brick { /* @_hitCount - количество допустимых ударов шайбой кирпич разрушается, как только атрибут будет равен нулю @_woundImg - изображение повреждённого кирпича заменяет исходное изображение при первом ударе шайбы */ private int _hitCount = 1; private Image _woundImg; public HardBrick(PlayField pf, BrickPile bp, Rectangle p, Image img, Image woundImg) { super(pf, bp, img, p); _woundImg = woundImg; } /* * Oбработка соударения с шайбой. Как только * значение _hitCount становится равным нулю, * кирпич будет удален с игрового поля */ public void hitBy(Puck p) { if (_hitCount > 0) { _img = _woundImg; _hitCount--; } else { _isDead = true; if (_bp.unbrokenCount() == 0) { _pf.getMatch().win(); } } p.getVelocity().reverseY(); } }
Теперь добавим новые кирпичи на игровое поле, для чего обратимся к классу BrickPile. Общее количество кирпичей, участвующих в игро
30
Пример выполнения курсовой работы
вом процессе, равно _rows ∗ _cols, следовательно, необходимо добавить (_rows ∗ _cols)*0.2 новых. Изменим код конструктора BrickPile. public class BrickPile { /* @_pf - игровое поле @_bricks - множество кирпичей @_rows - кол-во линий кирпичей @_cols - кол-во кирпичей в каждой линии */ private PlayField _pf; private Vector _bricks; private final int _rows = 4; private final int _cols = 10; public BrickPile(PlayField pf, Image img1, Image img2) { _pf = pf; int startx = 80; int x = startx, y = 10; for (int r = 0; r < _rows; r++) { for (int c = 0; c < _cols; c++) { Rectangle pos = new Rectangle(x,y,img1.getWidth(null),img1.getHeight(null)); // В зависимости от номера кирпича добавим на игровое поле // либо простой кирпич, либо крепкий. if (((r+1) * (c+1)) % (_rows * _cols * 0.2) == 0 ) { pf.addSprite(new HardBrick(_pf, this, pos, img1, img2)); } else { pf.addSprite(new Brick(_pf, this, img1, pos)); } x += img1.getWidth(null); } y += img1.getHeight(null) + 2; x = startx; } } ... }
Список литературы и интернет-ресурсов [1] Морган M. Java 2. Руководство разработчика. — М.: Вильямс, 2000. [2] http://en.wikipedia.org/wiki/Java_(programming_language) — Википедия (свободная энциклопедия) о языке Java. [3] Фаулер M. UML. Основы. 3-е издание. — СПб.: Символ-Плюс, 2005. [4] http://en.wikipedia.org/wiki/Unified_Modeling_Language Википедия (свободная энциклопедия) о языке UML.
—
[5] Эккель Б. Филосовия Java. — СПб.: Питер, 2003. [6] Орлов С.А. Технология разработки программного обеспечения. 2-е из дание. — СПб.: Питер, 2003. [7] Роганов Е.А. Основы информатики и программирования. — М.: МГИУ, 2001. [8] http://java.sun.com/docs/books/tutorial — Руководство по язы ку Java (in english). [9] http://www.javable.com/tutorials — Руководство по программи рованию на Java (по-русски). [10] http://www.ctan.org/tex-archive/macros/latex/contrib — Ар хив, содержащий пакет memoir. [11] http://en.wikipedia.org/wiki/LaTeX — Википедия (свободная энциклопедия) о системе LATEX. [12] http://www.intuit.ru/department/publish/latex — Описание работы в системе LATEX. [13] Львовский С.М. Набор и верстка в системе LATEX, 3-е изд., испр. и доп. — М., МЦНМО, 2003. Доступны исходные тексты этой книги. [14] Knuth D.E. The TEXbook. — Addison-Wesley, 1984. Русский перевод: Кнут Д.Е. Все про TEX. — Протвино, РДTEX, 1993.
Три шага к свободному ПО Не все знают, что стоимость проприетарного (коммерческого) программного обеспечения, способного превратить «компьютерное железо» в современный ком пьютер, значительно больше стоимости самого «железа». Не знают зачастую пото му, что используют контрафактное (то есть приобретённое без лицензии) ПО, что является нарушением действующего законодательства. В то же время сейчас отме чен небывалый рост интереса к свободным программным продуктам, которые могут быть приобретены совершенно законно бесплатно или за символическую цену. Последние 5–10 лет показывают, что в большей части стран мира уже произо шёл переход от преимущественного использования проприетарного обеспечения к свободному в самых разных областях — от организации на базе свободного про граммного обеспечения учебного процесса в школах и университетах до его исполь зования в государственных структурах управления. В таких странах, как Япония, Китай, Германия, Франция, Великобритания, Канада, США, операционная система Windows уступает место свободной ОС Linux. Зачастую такие решения принимают ся на государственном уровне, что легко обнаружить, выполнив на любом поиско вом сервере запрос «Linux правительство». Более 700 тысяч ссылок, получаемых в ответ на этот запрос на сервере http://www.google.ru, служат убедительным доказательством данного утверждения. Причиной является тот факт, что свободное ПО обладает целым рядом досто инств при сравнительно небольшом количестве недостатков. К достоинствам отно сятся: отсутствие зависимости от конкретной фирмы — производителя программ ного обеспечения, низкая стоимость или полная бесплатность, высокое качество, отсутствие «закладок», наличие исходного кода программ и практически полное отсутствие проблемы вирусов. Свободное ПО сейчас лучше превращает компью терное «железо» в удобный инструмент для работы, учёбы и отдыха, чем широко распространённые в России программные продукты от фирмы Microsoft. Мы гор димся тем, что учёный совет МГИУ ещё несколько лет назад принял решение о всемерной поддержке перехода от проприетарного ПО к свободному. Реализуя это решение, информационно-вычислительный центр МГИУ разработал програм му «Три шага к свободному ПО», основное назначение которой — познакомить пользователей компьютеров с миром свободного программного обеспечения и дать возможность переходить к его применению постепенно и безболезненно, шаг за шагом. Шаг 1 — FSF-Windows. Знакомство с лучшими свободными программами, устанавливаемыми на компьютер с операционной системой Windows. Шаг 2 — VMware ASPLinux. Установка на компьютер с ОС Windows эму лятора, позволяющего запускать «почти настоящий Linux», не нуждающийся в дополнительной настройке. Шаг 3 — MSIU ASPLinux. Переход к использованию доработанного в МГИУ дистрибутива ОС Linux, который может быть установлен на компьютер без удале ния имеющейся версии Windows. Компакт-диски и буклеты программы «Три шага к свободному ПО» можно приобрести в РИЦ МГИУ или по адресу ftp://ftp.msiu.ru/education.