CC BY
331
«Объектно-ориентированное программирование»
И.А. Барков
д.т.н, профессор кафедры «Автоматизированные системы обработки информации и
управления»
Казанский государственный технический университет им. А.Н. Туполева Ул. К. Маркса, 10, г. Казань, 420111, (843)231 00 28 shamin@kai.ru
АННОТАЦИЯ
Сформулированы проблемы преподавания объектно-ориентированного программирования, приведены размышления по организации и описан опыт преподавания объектно-ориентированного программирования в вузе. Object-oriented programming teaching problems are formulated. Object-oriented programming teaching practice and organization are described.
Ключевые слова
объектно-ориентированное программирование, проблемы обучения, опыт, рекомендации;
object oriented programming, learning problems, experience, recommendation.
Введение
В современном программировании объектно -ориентированный подход является одним из популярнейших. Он превратился в стандарт во многих фирмах и программистских сообществах. Средства для поддержки объектно-ориентированного программирования вошли практически во все профессиональные системы программирования. Этот стиль вместе с организационными нововведениями резко повысил качество программ, производительность труда отдельного программиста, эффективность коллективной работы программистов. Поэтому объектно-ориентированное программирование и объектно-ориентированная технология программирования уже стали неотъемлемой частью вузовских учебных программ по направлению «Информатика и вычислительная техника».
Объектно-ориентированное программирование, являясь в значительной мере развитой дисциплиной, включает как теоретические обоснования, так и богатый набор профессиональных практических приемов и рекомендаций. Например, в качестве теоретической основы в объектно-ориентированном программировании используются абстрактные типы данных. Целью данной теории является обоснование автоматизированной процедуры формирования понятий, изменения понятий в процессе наследования, использования для определения одних понятий других понятий. Очень важной стадией развития объектно-ориентированного программирования является объектно-ориентированная технология проектирования программных систем, которая предоставила средства и приемы предварительного описания и документирования сложных задач автоматизации и обогатила содержание этапа проектирования программных изделий.
Однако наличие совершенных для современного уровня развития инструментов не гарантирует получение качественных программ: необходимо в совершенстве овладеть как самими инструментами, так и приемами их совместного использования, приемами работы в коллективе.
Освоение программирования можно характеризовать тремя историческими этапами, отличающимися уровнем сложности получения профессиональной квали-
фикации.
Ранний этап характерен очень высоким уровнем сложности. Программирование осуществляется на языке кодов компьютера, позже - на языке ассемблера. От программиста требуются глубокие знания архитектуры компьютера: системы команд, методов управления памятью и управления вычислительным процессом и т.д. Появившаяся в те времена профессия «программист» относилась к элитным, загадочным.
С появлением языков программирования высокого уровня начался второй этап, характеризующийся резким снижением уровня начальной профессиональной подготовки. Идеи языка программирования стали доступны широкому кругу различных специалистов и, как следствие, программистская деятельность стала составной частью многих профессий. В этот период было создано огромное число достаточно простых программ. Потребность в автоматизации несложных (по современным меркам) задач была удовлетворена. Однако в конце двадцатого века стали резко усложняться передаваемые компьютеру задачи. На этом фоне усилились предъявляемые к программам требования: надежности, корректности, дружественного к пользователю интерфейса, простоты совершенствования и развития. На рубеже 80-х годов появилось понятие «кризис программирования». По экзотическим прогнозам тех лет к 2005-2010 годам для удовлетворения потребности в автоматизации труда все человечество должно было переключиться на программирование. В ответ на возникшие проблемы наука программирования выдвинула множество новых идей и пересмотрела старые. Была изучена и развита концепция типов данных языков программирования. Появилось понятие «инкапсуляция», с помощью которой удалось упорядочить вычислительные структуры. Использование полиморфизма и правил именования идентификаторов придало программам свойство модифицируемости. Переход к технологии персональных компьютеров, сделавший этот инструмент массовым, способствовал созданию специальных средств управления вычислительным процессом, получивших общее название «дружественный интерфейс». В практику программирования были введены концепции событийного программирования и защищенных от ошибок программных кодов. Наконец, сформировалась идея объектно -ориентированного программирования.
С появлением объектно-ориентированного программирования разговоры о «кризисе программирования» постепенно прекратились. Начался новый, третий, этап в сложности получения базовых знаний для занятия программистской деятельностью. Теперь весьма поверхностное освоение приемов программирования позволяет создавать несложные программы. Однако профессионал, как правило, найдет в таких программах множество недостатков. Чаще всего качество таких программ не удовлетворяет современным требованиям надежности, модифицируемости и, как следствие, время жизни программы будет небольшим. Легкость получения работающей программы создает у программистов иллюзию достаточной подготовленности. Однако для создания отвечающего всем современным требованиям сложного программного изделия необходимо глубокое понимание идей, принципов объектноориентированного программирования, реализации их в системе программирования, устройства объектно-ориентированной программы, объектно-ориентированной технологии создания программных систем.
Таким образом, программирование стало одновременно и простым (относительно), и сложным, а учебный процесс по изучению объектно-ориентированного программирования накопил целый ряд противоречий объективного и субъективного характера.
Вопрос: «Как написать хорошую программу на С++?» очень похож на вопрос «Как пишется хорошая английская проза». На него есть два ответа: «Нужно знать, что вы собственно хотите написать» и «Практика и подражание хорошему стилю». Оба совета пригодны для С++ в той же мере, что и для английского языка, и обоим достаточно трудно следовать.
Б. Страуструп
Перечислим основные проблемы, возникающие в учебном процессе по освоению1 объектно-ориентированного программирования.
Во-первых, объектно-ориентированное программирование ориентировано в первую очередь на создание сложных программ, а студент, выполняя лабораторные работы, решает простые задачи. В курсовых работах студент чаще всего решает локальные задачи. Руководителем проекта является преподаватель, на нем лежит ответственность за проект в целом. В результате, большая часть студентов не получает опыт создания сложных программ и, тем более, руководства процессом их разработки.
Во-вторых, объектно-ориентированное программирование создает хорошие возможности модификации программ, но эти возможности закладываются еще на этапе проектирования программы. У студента отсутствует мотивация обеспечения модифицируемости программы, т.к. стиль его работы - «сдал и забыл». На повестке дня стоит проблема выполнения заданий по другим предметам.
В-третьих, большинство преподавателей высшей школы являются представителями старшего поколения (по некоторым оценкам средний возраст преподавателей бюджетного ВУЗа в России начала XXI века составляет 60-65 лет). Как правило, они получили огромный опыт использования технологии структурного проектирования программ, основанной на алгоритмической декомпозиции больших систем. Большинство служащих примерами успешных программ разработано с применением технологии структурного проектирования. Поэтому обучение объектно -
ориентированному программированию находится под (объективным и субъективным) влиянием идей структурного проектирования программ. Накопление полезного опыта объектно-ориентированного программирования в этом случае становится делом самостоятельным на основе метода проб и ошибок.
В-четвертых, наука программирования быстро развивается, поэтому полученные обычно на начальных курсах знания приемов программирования к моменту окончания ВУЗа в значительной мере устаревают. Возникает парадокс: первокурсник профессионально более современен, чем выпускник. В этом смысле парадоксальным является даже само преподавание объектно-ориентированного программирования: где гарантия, что через 5-7 лет не появятся новые идеи и объектное программирование уйдет в историю, как уже ушло структурное программирование? Поэтому учебный процесс должен прививать специалисту качества оперативной реакции на новые идеи и технологии программирования.
В-пятых, сложность задач автоматизации неуклонно растет. Поэтому молодой специалист, получив представление об одном уровне сложности программных систем, попадает в условия следующего уровня сложности. Поэтому неизбежен этап адаптации к новым условиям. От выпускника опять требуются качества оперативного реагирования на изменившиеся условия работы.
В-шестых, качественная программа должна не только решать прикладную задачу, но и быть легко читаемой, легко понимаемой. В программистской практике нередка ситуация, когда уже разработанная программа передается другому програм-
1 Программирование в значительной мере является ремеслом, поэтому его нужно осваивать, изучение программирования оставим ученым.
мисту для ее сопровождения и развития, работа этого программиста начинается с изучения программы. Использование хороших правил именования идентификаторов и аналогичных методических приемов существенно повышает преемственность. Поэтому доступность понимания программы является, прежде всего, практическим принципом: как показывают научные исследования, при отладке программ до 90% времени тратится на чтение исходного текста. У программиста «пишущего» программу создается иллюзия ее ясности. С целью экономии времени студенты используют заложенные в систему программирования правила именования идентификаторов, по прошествии двух недель приходится восстанавливать в памяти то, что написано ранее. В результате, на вопрос «Какое назначение кнопки ВиИвпН?», студент отвечает только после внимательного просмотра и изучения своей программы. Большую помощь в чтении программы оказывает применение правил именования идентификаторов, однако часто студенты пренебрегают этими правилами.
В-седьмых, особенность организации учебного процесса в техническом ВУЗе состоит в том, что студент должен изучить большое число общеобразовательных, общетехнических и специальных дисциплин. Дифференциация наук достигла большого размаха и не прошла мимо объектно-ориентированного программирования, которое опирается на теорию алгоритмов, теорию абстрактных типов данных, теорию проектирования программ и др. Как правило, освоение разных дисциплин осуществляется под руководством разных преподавателей, в результате чего у студентов возникают затруднения в осознании целостности распределенного по разным дисциплинам учебного материала.
В-восьмых, перед преподавателем стоит проблема оценки знаний и навыков студентов в области объектно-ориентированного программирования, которая в значительной мере затрагивает интересы студента. Учитывая, что обсуждаемая технология ориентирована на создание сложных программ, преподавателю приходиться преодолевать серьезные трудности при выборе адекватных средств контроля или упрощать картину. Контроль знаний на уровне синтаксиса конструкций языка программирования трудно назвать удовлетворительным (см. сноску 1 в начале этого раздела) для объектно-ориентированного программирования.
В-девятых, создатели программных средств, как правило, считают реализацию программ коммерческой тайной, подробно раскрывается только внешняя логика программы. Поэтому хорошие примеры реализации объектно-ориентированных программ с комментариями по выбору решений фактически отсутствуют. По этой причине, предлагая примеры программ студентам, преподаватель действует субъективно, а студенты находятся в зависимости от профессиональных пристрастий конкретного преподавателя.
Наконец, остаются традиционные для учебного процесса проблемы. Во-первых, студенческий контингент неоднороден: одни студенты пришли получить профессию, другие - диплом, третьи - по рекомендации, а не по душе. В последнее время появился специфический студент - внебюджетник. Перед преподавателем стоит проблема выбора: на кого ориентироваться? Во-вторых, практические занятия опережают теоретические занятия. Преподаватель должен организовать самостоятельную работу студентов по предварительному овладению теоретическими знаниями. В-третьих, последовательность дисциплин в учебном процессе часто не отвечает требованиям первичности-вторичности получения знаний. И причина здесь не в плохой организации учебного процесса, а в сильной взаимосвязи многих дисциплин в рамках одной специальности. В последнем случае преподавателю часто приходиться отвлекаться на краткие экскурсы в другие дисциплины.
Таким, образом, в условиях учебного процесса студент не всегда имеет возможность в полной мере ощутить потребность в использовании рекомендаций объектно-ориентированного программирования и оценить их по достоинству. Выпускник ВУЗа, получивший образование в области информатики и вычислительной техники на примере простых программ, под руководством «структурноориентированных» преподавателей и на примере успешных «структурно -ориентированных» программ вынужден во время получения образования и на начальном этапе профессиональной деятельности самостоятельно отфильтровывать идеи структурного проектирования программ, несовместимые с идеями объектноориентированной технологии. Нельзя, конечно, утверждать, что эти идеи были плохими, но они уже сыграли свою роль и на смену им пришли новые. Кроме того, со-
временные системы программирования уже не содержат средства поддержки структурного проектирования программ.
2. Некоторые размышления по содержанию и организации учебного процесса
Подобно тому, как взявший в руки молоток начинает видеть во всем окружающем только гвозди, проектировщик с объектно-ориентированным мышлением начинает воспринимать весь мир в виде объектов.
Г. Буч
И инженер, и художник должны хорошо чувствовать материал, с которым они работают. В объектно-ориентированной методологии анализа и проектирования сложных программных систем основными строительными блоками являются классы и объекты, которые служат в качестве абстракции реальной действительности. Объектное мышление свойственно человеку. Мы привыкли видеть мир в виде совокупности объектов, причем каждый такой объект, обладая собственными структурой, состоянием и поведением, взаимодействует с окружающими объектами. Например, самолет, по определению, «совокупность элементов, каждый из которых по своей природе стремится упасть на землю, но за счет совместных непрерывных усилий преодолевающих эту тенденцию». Он летит только благодаря согласованным действиям своих компонентов. Эта близкая и понятная человеку идея лежит в основе объектно-ориентированного программирования. Однако учебный процесс в области программирования идет по тернистому пути.
Начальное обучение программированию в школе и на первом курсе ВУЗа осуществляется без использования объектно-ориентированных средств, неизбежно базируется на структурном программировании, на функциональной декомпозиции решаемых задач. У школьника и студента вырабатывается стереотип процедурного мышления. Переход к объектно-ориентированному программированию содержит в себе много неожиданностей. Использование объектной декомпозиции решаемых задач предполагает полную перестройку системного мышления. Поэтому разъяснение метафоры объектного программирования2 должно занимать существенную часть лекционного курса. Более глобальным решением данной проблемы является изучение объектно-ориентированного программирования в самом начале учебного процесса: в школе, на первом курсе ВУЗа. В этом случае неизбежная и порой болезненная перестройка профессионального мышления не будет помехой учебному процессу.
Следующим объектом наших рассуждений является содержание дисциплины «Объектно-ориентированное программирование».
А) Будем исходить из цели процесса программирования: создание программного изделия, реализующего проект информационной технологии. В этом случае студент должен получить предварительные представления о жизненном цикле, процессах анализа и проектирования программного изделия. Современное представление о технологии проектирования программных систем прочно связано с методологией объектно-ориентированного программирования. Преподаватели часто обвиняют студентов в том, что сначала создается программа, а уже потом, по готовой программе, - проект программного изделия. Давайте откровенно признаем, что мы их именно так и учим: как правило, вопросы проектирования программных изделий рассматриваются в дисциплине «Технология программирования», которая в учебном процессе по времени идет после дисциплины «Объектно-ориентированное программирование». Этот временной стереотип закрепляется в сознании студента. Этому же способствует желание, как можно раньше увидеть результаты своего труда в виде (правильно или неправильно) работающей программы.
2 Метафора в программировании означает соответствие между логическими компонентами языка программирования и привычными человеку понятиями.
Б) Студентам необходимо профессиональное общение. В настоящее время признанным программистским сообществом языком является UML. Как правило, UML изучается позже в отдельной дисциплине.
В) У студентов часто возникают вопросы по структуре объектноориентированной программы. Большинство вопросов относятся к раздельному описанию структуры и реализации классов. Кроме того, тщательного объяснения требует положение объектно-ориентированного программирования: в объекте открытыми без ограничений должны быть только свойства и методы. Исчерпывающие ответы на возникающие вопросы можно получить, познакомившись с теорией абстрактных типов данных.
Г) Основным инструментом программиста является система программирования, которая содержит средства для построения всего спектра современных информационных технологий. Многие учебники по объектно-ориентированному программированию представляют, по сути, справочники по визуальным компонентам и приемам их задействования в программе. Однако парадокс состоит в том, что все визуальные компоненты в обозначенное учебным планом время подробно рассмотреть невозможно. Поэтому преподавателю, решая задачу выбора перечня рассматриваемых компонентов, приходиться ранжировать компоненты, определяя важность, значимость каждого из них. Однозначно проранжировать компоненты невозможно, поэтому часто здесь присутствует субъективизм и личные пристрастия. Этим можно объяснить и тот факт, что в разных учебниках рассматриваются разные наборы визуальных компонентов. Основной путь получения профессиональных знаний и навыков использования визуальных компонентов заключается в самостоятельной работе. Не случайно появилось высказывание: «Чтобы научиться программированию, нужно программировать».
В этих условиях основной задачей преподавателя является обучение методике освоения программирования с использованием библиотеки визуальных компонентов. Во-первых, необходимо рассмотреть иерархию компонентов, которая является своеобразным путеводителем по компонентам и помогает понять взаимодействие компонентов. Во-вторых, целесообразно изучение начинать с корня иерархии компонентов, для каждого компонента подробно рассматриваются только те методы и свойства, которые впервые появились в нем, вспоминая при этом свойства и методы, которые компонент унаследовал. Продвижение по иерархии компонентов от корня к листьям осуществляется по армейскому принципу «копать яму от забора и до обеда», т.е. в отведенное учебным процессом время. Полученные знания позволят студентам самостоятельно добраться до листьев иерархии визуальных компонентов. В-третьих, необходимо изучить окружение программы, в котором работают компоненты. К счастью окружение оформлено также в виде компонентов: приложение, экран, принтер, буфер обмена и т.п.
Подведем теперь итог наших рассуждений относительно содержания дисциплины «Объектно-ориентированное программирование». В целом дисциплина состоит из двух частей. Первая часть, «Принципы и технология создания объектно -ориентированных программ», содержит описание инвариантных к языкам программирования понятий, приемов, методов. Методическая направленность первой части заключается в овладении методом объектно-ориентированного программирования. Основные темы первой части дисциплины: метафора объектно-ориентированного программирования, введение в технологию анализа и проектирования программных систем, математические основы объектно-ориентированного программирования, введение в язык системного моделирования UML.
Вторая часть, «Реализация объектно-ориентированной технологии в системе программирования», преподается, как правило, на примере конкретной системы программирования и методически направлена на овладение конкретными инструментами объектно-ориентированного программирования. В любой профессии предполагается, что специалист должен владеть рабочими инструментами в совершенстве. Основные темы второй части: устройство и функционирование программы, реализация в системе программирования наследования, инкапсуляции, полиморфизма, структура объектной надстройки системы программирования и важнейшие классы, взаимодействие с операционной системой.
Сказанное наводит на мысль: необходимо целостное изложение учебного материала, включающего метафору, абстрактные типы данных, сведения по анализу
и проектированию программных систем, языку UML и, наконец, по объектноориентированному программированию с использованием конкретной системы программирования и принципам построения библиотеки визуальных компонентов. Темы, которые традиционно изучаются в других дисциплинах (например, «Анализ и проектирование программных систем») могут излагаться в ограниченном объеме. Учебники такого содержания в настоящее время отсутствуют.
Обсудим теперь состав дисциплины и расстановку акцентов при проведении занятий. Типовые виды учебных занятий - это лекции, практические и лабораторные занятия, самостоятельная и курсовая работа. Другие виды занятий, как, например, составление рефератов являются неэффективными.
Основной акцент в лекционных занятиях нужно ставить на овладение идеями объектно-ориентированного программирования. Лекционные занятия должны содержать уже упоминавшиеся две части: «Принципы и технология создания объектно-ориентированных программ» и «Реализация объектно-ориентированной технологии в системе программирования». Для осознанного овладения объектноориентированным программированием необходимо во второй части заглянуть внутрь системы программирования и продемонстрировать студентам, как в ней реализуются основные идеи объектно-ориентированного программирования. К сожалению, устройство системы программирования авторами публично не распространяется, однако имеется доступ к исходным текстам многих модулей. Рассматривая устройство системы программирования, преподаватель имеет в своем распоряжении великолепный пример созданной в соответствии с рассматриваемой методологией объектноориентированной, доступной для изучения программы. Как уже упоминалось ранее, других примеров объектно-ориентированных программ преподаватель в своем распоряжении практически не имеет.
Методическая направленность практических занятий состоит в привитии базовых навыков объектно-ориентированного программирования. Эти занятия являются основными для передачи преподавателем своего опыта студентам. «Делай как я!» -это очень эффективный прием обучения. Содержанием практических занятий является решение задач по ключевым темам объектно-ориентированного программирования. Необходимость домашних заданий является спорной - перед студентами стоят серьезные самостоятельные задачи: выполнить лабораторные работы и курсовую работу. Однако рекомендация «Реализовать дома на компьютере рассмотренную на практическом занятии задачу» представляется очень полезной.
Лабораторные работы можно выполнять дома. В настоящее время практически все студенты имеют в распоряжении компьютеры. Выделенное на лабораторные работы учебное время используется для выдачи заданий, консультаций и защиты лабораторных работ. Лабораторная работа должна рассматриваться как создание небольшого программного изделия. При таком подходе студенты получают навыки профессиональной работы: получение и изучение задания, анализ и проектирование задачи автоматизации, реализация программного изделия и оформление документации (отчета по лабораторной работе), и, наконец, защита лабораторной работы.
Обсудим теперь проблему выбора сложности лабораторной задачи. Напомним, использование объектно-ориентированного программирования дает эффект только при решении сложных задач. Поэтому нужно найти грань между разумной сложностью задачи и ограниченным учебным временем, выделенным на выполнение лабораторной работы. Наиболее разумным представляется подход к формированию лабораторных заданий, в котором лабораторные работы представляют собой этапы создания одного программного изделия. В этом случае удается внести (относительную) сложность задачи в простые, по определению, лабораторные работы. В целом задание должно предполагать разработку 3-4 классов, нацеленных на решение общей задачи. В этом случае содержанием каждой лабораторной работы является расширение предыдущей работы одним или двумя классами. Действуя таким образом преподаватель имеет возможность решать целый ряд методических задач. Во-первых, студент имеет возможность поработать со структурой программной системы. Во-вторых, каждая очередная работа является продолжением предыдущей, поэтому студент вынужден заботиться о легком чтении и легком понимании исходного текста программы. В-третьих, имеется возможность (частично) освоить язык UML, с помощью которого можно сообщать и документировать профессиональные проектные решения. В-четвертых, переходя к очередной лабораторной работе, студент часто
вынужден выполнить изменения в существующих программах, поэтому быстро придет осознание необходимости заботиться о модифицируемости программы.
Теперь несколько слов о расчете трудоемкости лабораторной работы. Это очень непростая задача. Непросто оценить трудоемкость задания профессионалу. В нашем случае необходимо учитывать необходимость освоения языка программирования, системы программирования и средств отладки, операционной системы. Поэтому соотношение трудоемкости освоения инструментов и трудоемкости выполнения задания должно быть примерно 3 : 1. Это означает, что % времени лабораторной работы студент тратит на освоение инструментов, а У - на решение задачи. Приведенные оценки являются весьма приблизительными и приведены с целью демонстрации структуры рабочего времени студента в лабораторной работе. Главный вывод из сказанного: отведенное на самостоятельную работу учебное время должно быть в значительной степени использовано для освоения профессиональных инструментов программиста.
Относительно курсовых работ хочется высказать единственное соображение: курсовые работы должны быть курсовыми. Это означает, что они не должны быть привязаны к конкретной дисциплине, а выполняются в течение учебного года или в течение семестра. Существующая практика допускает выполнение в течение одного семестра так называемых «курсовых работ» по нескольким дисциплинам. В результате по согласованию с преподавателями выполняется одна и та же тема в «двух экземплярах», либо студент вынужден каждое задание выполнить кое-как. К чему такое распыление сил студента? Тем более этим мы приучаем студента к халтуре.
К сказанному хочется добавить еще одно соображение. Современные работодатели в области программной индустрии нередко предъявляют к соискателю должности требование: «наличие самостоятельно реализованного программного проекта». Если мы заботимся о своих выпускниках (в этом автор не сомневается), то необходимо создать студенту условия для получения за время обучения «самостоятельно реализованного программного проекта». Поэтому курсовые и дипломные работы, магистерские диссертации должны быть ориентированы на предоставление студенту такой возможности.
Конечной целью обучения программированию является умение самостоятельно создавать качественные программные изделия. Система контроля по дисциплине «Объектно-ориентированное программирование» должна быть ориентирована в первую очередь на оценку навыков разработки программ. Как правило, знание теории позволяет студенту и специалисту создавать качественные программы. Самостоятельная работа студента по созданию программных изделий осуществляется в рамках лабораторных, курсовых и дипломных работ. Курсовые и дипломные работы обычно оцениваются отдельно. Поэтому в системе дисциплинарной оценки важнейшее место принадлежит лабораторным работам. «Студент самостоятельно разработал программу - освоил программирование» - вот основная формула оценки. К этому нужно добавить то, что задания на лабораторные работы должны предусматривать использование инструментальных средств, освоение которых преподаватель считает делом первой очереди.
Бально-рейтинговая система оценки в нашей ситуации является идеальным средством подведения итогов обучения. Выполнение каждого важного шага лабораторной работы должно заканчиваться получением баллов. Набранными баллами определяется рейтинг. При этом студент должен заранее знать, какое количество баллов он получит за каждый конкретный этап лабораторной работы. В этом случае он будет действовать в соответствии со своими целями участия в учебном процессе («лишь бы не отчислили!», «получить максимум полезных знаний» и т.д.)
Переход на двухуровневую схему образования (бакалавр - магистр) создает определенные условия для преодоления указанных противоречий. На этапе бакалавриата студент получает базовые сведения и накапливает первоначальный опыт в области объектно-ориентированного программирования. На этапе магистратуры студент в течение двух лет должен решить в диссертации достаточно сложную задачу по созданию программных изделий. Возникает почти идеальная возможность применения полученных знаний и навыков. Для успешности завершающего этапа освоения учебного процесса необходимо учебные планы и требования к магистерской диссертации ориентировать на использование объектно-ориентированного программирова-
ния. В частности, защита магистерской диссертации должна включать обсуждение объектной декомпозиции решаемой задачи, объектной структуры программы.
В настоящее время разрабатываются учебники: «Объектно-ориентированное программирование с примерами на Object Pascal» и «Объектно-ориентированное программирование с примерами на C++», в которых автор попытался учесть обсуждаемые в настоящей статье проблемы и соображения по их преодолению. Издание учебников предполагается в 2010 году. Далее по тексту приведено содержание указанного первым учебника. Второй учебник отличается по содержанию от первого незначительно.
Введение
Часть I. Принципы и технология создания объектно-ориентированных программ.
1. Метафора объектно-ориентированного программирования. Включает: объекты (понятие объекта, свойства и сотояние объекта, поведение объекта, идентичность объекта), отношения между объектами (типы отношений, отношение связи, отношение агрегации), классы (понятие класса, интерфейс и реализация), отношения между класами (типы отношений, ассоциация, наследование, агрегация, использование, инстанцирование, метаклассы), взаимосвязь классов и объектов.
2. Объектно-ориентированная разработка программных систем. Включает: среда и объект проектирования (проблемы создания программных систем, пять признаков сложной системы, каноническая модель сложной системы, человеческие возможности и сложные системы, жизненный цикл программного изделия), проектирование программных систем (инженерное дело как наука и искусство, смысл проектирования, важность построения модели, элементы программного проектирования, объектно-ориентированные анализ, проектирование и программирование), принципы и инструменты объектно-ориентированного анализа (классификация и объектноориентированное программирование, трудности классификации, итеративная суть классификации, классическая категоризация, концептуальная кластеризация, теория прототипов, применение классических и новых теорий, объектно-ориентированный анализ), принципы и инструменты объектно-ориентированного проектирования (абстрагирование, инкапсуляция, модульность, иерархия, типизация, параллелизм, сохраняемость), преимущества объектной модели
3. Документирование результатов анализа и проектирования программных систем. Включает: особенности изображения диаграмм языка UML, диаграммы классов (классы, отношения между классами, шаблоны или параметризованные классы, рекомендации по построению диаграмм классов), диаграммы деятельности (состояние действия, переходы, дорожки, объекты, рекомендации по построению диаграмм деятельности), диаграммы последовательности (объекты, сообщения, пример построения диаграммы последовательности, заключительные рекомендации по построению диаграмм последовательности), автоматизация проектирования программных систем
4. Алгебраические основы типов данных. Включает: сигнатуры, алгебры, алгебры слов, теории, абстрактные типы данных, иерархические модели типов данных, типы и подтипы, типы типов, родовые типы данных, полиморфные операции, примеры спецификации типов данных.
Часть II. Реализация объектно-ориентированной технологии в системе программирования Делфи.
5. Делфи и операционные системы. Включает: общие сведения, среда разработки, язык программирования, объектно-ориентированное программирование, взаимодействие с операционной системой).
6. Устройство и функционирование программы. Включает: структура классов и объектов, класс Tobject, жизнь классов и объектов, доступ к структуре класса и методы класса, поля, методы, свойства.
7. Информация о типе времени исполнения.
8. Наследование. Включает: способы наследования, наследование полей и свойств, наследование методов, наследование статических методов, наследование динамических и виртуальных методов, отличие динамических и виртуальных методов.
9. Инкапсуляция. Включает: инкапсуляция как средство моделирования абстрактного типа данных, структура программного модуля, области видимости полей, свойств и методов.
10. Полиморфизм. Включает: импользование полиморфизма, общая схема реализации полиморфизма в программе, пример программы со свойством модифицируемости.
11. Важнейшие классы. Включает: управление ресурсами Windows и библиотека визуальных компонентов, класс Tpersistent, класс Tcomponent, класс Tcontrol, класс TwinControl, класс TcustomControl, класс TgraphicControl, класс Tapplication, класс Tscreen, класс Tprinter, класс Tdipboard, класс TForm, класс TiniFile.
12. Обработка событий и сообщений. Включает: операционная система Windows и обработка сообщений, общая схема обработки событий и сообщений, сообщения и динамические методы, реализация цикла «событие - сообщение - обработка», пример построения визуального компонента.
13. Обработка ошибок в программе. Включает: классификация ошибок по методам обнаружения, защищенное от ошибок программирование, ошибка как класс, глобальная система обработки ошибок.
Литература.
Приложения. Включает: историческая справка, правила именования идентификаторов, пример разработки программы, расположение программных компонентов в модулях Делфи
В тексте содержания не отмечены часто повторяющиеся структурные части. Во-первых, после каждого раздела уровня 1 приведены формулировки задач. Содержание задач связано с тематикой раздела и включает задания по анализу и проектированию автоматизированных систем (разделы 1, 2) задания по составлению диаграмм языка UML (раздел 3), задания по конструированию типов данных (раздел
4), задания на программирование (разделы 5 - 13).
Во-вторых, после каждого раздела уровня 2 приведены контрольные вопросы. Контрольные вопросы формулировались таким образом, чтобы выделить ключевые моменты раздела и дать возможность читателю выразить свои мысли относительно содержания раздела.
3. Опыт преподавания
Первая половина трудностей освоения программирования заключается в изучении идей, заложенных в язык программирования, вторая - в получении возможности выражать свои идеи с помощью языка программирования.
Автор неизвестен
Автор преподает дисциплину «Объектно-ориентированное программирование» в течение пятнадцати лет на примере языков программирования Object Pascal (Delphi) и C++(Builder). Можно ли выделить методические предпочтения в отношении служащей примером системы программирования? В целом ответ отрицательный. Однако имеются некоторые негативные моменты при выборе языка C++. Исторически язык С создавался как язык разработки операционных систем и в нем были предусмотрены расширенные средства доступа к ресурсам операционной системы. Поэтому в языке C++ присутствуют возможности, нарушающие парадигму объектноориентированного программирования. Например, использование «дружественных функций». Инкапсуляция, важнейшая составляющая технологии объектноориентированного программирования, предполагает использование управляемого доступа (public, private, protected) к ресурсам объекта. «Дружественные функции», напротив, предлагают легко нарушить условия управляемого доступа. Аналогичное противоречие присутствовало в технологии структурного программирования: в языках программирования содержалась конструкция goto, но использовать ее в программах не рекомендовалось. Скорее всего, с «дружественными функциями» необходимо поступать таким же образом.
3.1. Лекционные занятия. В таблицах 1 и 2 приведена краткая характеристика содержания лекционного курса. Структура материала соответствует разделению излагаемого материала на две части.
Характеристика содержания части 1________________Таблица 1
Номер раздела Название раздела Краткое содержание раздела Методическое содержание раздела
1 Метафора объектно- ориентированного программирования Природа классов и объектов, взаимоотношение между ними. Наследование. Инкапсуляция. Полиморфизм. Правила проектирования хороших абстракций. Знакомство с системой понятий. Формирование объектноориентированного мышления.
2 Объектноориентированная разработка программных систем Среда и объект проектирования. Жизненный цикл программного изделия. Объектноориентированные модели. Объектноориентированные анализ и проектирование. Инструменты объектноориентированного анализа и проектирования. Знакомство с содержанием и результатами процесса проектирования программных изделий.
3 Документирование результатов анализа и проектирования программных систем Язык UML. Диаграммы классов. Диаграммы деятельности. Диаграммы последовательности. Знакомство с объектно-ориентированным языком мышления и общения с коллегами.
4 Алгебраические основы типов данных Алгебраические модели построения иерархических типов данных. Раздельное описание интерфейса и реализации типа данных. Построение полиморфных операций. Понимание смысла процессов типообра-зования в языках программирования. Понимание причин выделения в структуре типа данных интерфейса и реализации.
Методически первая часть направлена на овладение методом объектно -ориентированного программирования.
Характеристика содержания части 2__________________Таблица 2
Номер раздела Название раздела Краткое содержание раздела Методическое содержание раздела
1 Устройство и функционирование программы Структура класса и структура объекта. Жизнь классов и объектов. Класс ТО^єй. Методы класса. Поля, свойства, методы. Примеры. Введение логических моделей построения классов и объектов с использованием графической символики. В дальнейшем логические модели используются для наглядного объяснения происходящих в программе процессов.
2 Наследование Реализация наследования в программе. Наследование полей и свойств. Статические Получение представления о правилах декомпозиции решаемой задачи и программы. Изучение и ос-
методы. Наследование статических методов. Примеры. воение приемов повторного использования классов и создания классов, пригодных для повторного использования.
3 Инкапсуляция Структура класса. Управляемый доступ к ресурсам объекта. Структура программного модуля. Примеры. Освоение управляемого доступа к ресурсам объекта. Санкционированное использование ресурсов объекта. Защита ресурсов объекта от несанкционированного использования.
4 Полиморфизм Виртуальные методы. Наследование виртуальных методов. Общая схема реализации полиморфизма. Примеры. Изучение приемов создания программ, обладающих свойством модифицируемости.
5 Важнейшие классы Изучение классов, входящих в ядро объектно- ориентированной надстройки над системой программирования. Примеры. Получение представления о способах формирования свойств и поведения компонентов. Демонстрация примера хорошей объектно - ориентированной программы в виде библиотеки визуальных компонентов.
6 Обработка событий и сообщений Взаимодействие с операционной системой с помощью сообщений. Цикл взаимодействия: событие - сообщение -обработка. Стандартные средства обработки цикла взаимодействия. Программирование событий и сообщений. Примеры. Изучение событийного программирования. Программирование цикла: событие-сообщение-обработка.
7 Обработка ошибок Виды ошибок по методам обнаружения. Защищенные от ошибок программные коды. Ошибка как класс. Глобальная система обработки ошибок. Систематизация методов и приемов обработки ошибок программы. Обработка ошибок как пример объектного подхода. Эта тема не является показательной для объектноориентированного программирования, но ее исключительная важность не вызывает сомнения.
Вторая часть методически направлена на овладение конкретными инструментами объектно-ориентированного программирования.
В разделе 1 части 2 Таблицы 1 упоминаются «логические модели классов и объектов». Авторы систем программирования не раскрывают подробно реализацию классов и объектов, однако знание реализации классов и объектов в системе программирования позволяет программисту глубоко освоить и осознанно применять приемы объектно-ориентированного программирования. Для выхода из затруднения студентам предлагается некоторая логическая модель реализации классов и объектов. Например, структура класса приведена на рис. 1.
Рис. 1. Структура класса Структура объекта отличается от структуры класса присутствием реализации полей и методов (как на рис. 1 в таблице методов класса). Использование логических моделей класса и объекта позволяет наглядно представить процессы создания и уничтожения объектов, процессы наследования полей, свойств и методов. Детально показывается отличие статического и динамического наследования методов путем прослеживания установления связи вызова метода и реализации метода в структуре объекта. Легко объясняются построение полиморфных операций и приемы придания программе свойства модифицируемости. Принципы создания повторно используемых компонентов также получают наглядное представление.
Раздел «Важнейшие классы» предназначен для изучения ядра библиотеки визуальных компонентов (см. «Содержание учебника» в предыдущем разделе). При рассмотрении каждого класса главное внимание уделяется принципам его построения и заложенным в класс моделям. Например, при рассмотрении класса ТСоПго1 студентам предлагается следующий рисунок (рис. 2).
Рабочая область владельца
Top
Left
Визуальный компонент
Height
Ось Х
Ось Y
Рис. 2. Местоположение и размер визуального компонента
С помощью рис. 2 вводятся основные модельные понятия («Рабочая область владельца», система координат) и обсуждаются конкретные свойства (Left, Top, Width, Height), содержащиеся в компоненте TControl и получаемые в процессе наследования его потомками. По замыслу автора такое изложение материала позволяет студентам получить глубокое представление о библиотеке визуальных компонентов и в дальнейшем самостоятельно освоить конкретные классы (TEdit, TButton, TTree-View и т.д.).
3.2. Практические занятия. Содержанием практических занятий является решение задач (на доске, на бумаге) по темам. Далее по тексту приведены формулировки некоторых задач. За основу принята система программирования Code Gear RAD
Studio for Microsoft Windows, в которой имеется возможность создавать программы на языках программирования Object Pascal и C++.
Задача 1. Написать программу для решения квадратного уравнения вида Ax2 + Bx + С = 0. Предусмотреть поля ввода коэффициентов и кнопки вывода справочной информации и решения. Для построения экранной формы использовать визуальные компоненты TForm, TLabel, TEdit, TButton. Для управления программой использовать событие OnClick компонента TButton. Экранная форма имеет вид (рис. 3):
W Квадратное уравнение
Введите коэффициенты уравнения и щелкните на кнопке Решение.
Справка
Ь
F-
Корни уравнения
н1=-1
к2=1
Рис. 3. Экранная форма задачи 1
Задача 2. Написать программу «Секундомер». Предусмотреть поля для отображения текущего времени, отображения интервала смены показаний текущего времени. Предусмотреть кнопки пуска и останова секундомера, а также сброса текущего времени. Для построения экранной формы использовать стандартные визуальные компоненты ТЬаЪе1, ТЕй, ТБШоп, TUpDown, ТБогш. Для управления секундомером использовать стандартный невизуальный компонент ТТтег. Для управления программой использовать событие ОпСИск компонента ТБийоп. Для изменения интервала использовать событие OnChangingEx компонента TUpDown. Экранная форма имеет вид (рис. 4):
Рис. 4. Экранная форма задачи 2
Задача 3. Написать программу, для создания списка преподавателей и студентов. Предусмотреть поля ввода атрибутов: фамилии, группы или кафедры, а также выбор с помощью компонента TRadioButton статуса вносимого в список (студент или преподаватель), кнопки для внесения в список и отображения списка студентов
или преподавателей. Для построения экранной формы использовать стандартные визуальные компоненты ТБогш, ТЬаЪе1, TEdit, ТВШйп, TRadioБutton. Список преподавателей и студентов отображается с помощью визуального компонента ТМешо, расположенного в отдельной экранной форме. Использовать события: ОпО^ компонента ТБийо^ ОпО^ компонента TRadioButton.
Требования к реализации: 1) Создать базовый класс ТРегео^ затем, на основе базового, - TTeacher и Т8^еШ 2) Для размещения сведений о студентах и преподавателях использовать единый массив.
Экранная форма имеет вид (рис. 5):
25^ Полиморфизм
Фамилия
I
Группа или кафедра
(* студент С преподаватель
Добавить Список
Рис. 5. Экранная форма задачи 3
Задача 4. При запуске программы на форме нарисован круг. При нажатии на кнопку круг передвигается вправо на 5-7 миллиметров. При решении задачи использовать метод базовой точки. Экранная форма имеет вид (рис. 6):
.Вперед
Рис. 6. Экранная форма задачи 4
Задача 5. При запуске программы на экранной форме появляются две фигуры: круг и квадрат. С помощью устройства «мышь» фигуры должны перемещаться по форме. Используются события класса ТБогш: OnMouseDown, OnMouseMove, Оп-Мошеир. Ограничение: фигуры не должны пересекать границы клиентской области формы. Предусмотреть класс фигура (TFigure) и его потомков: круг (ТОгс1е), квадрат (TSquare). Метод перемещения фигур должен быть полиморфным.
Требование: предполагается, что в будущем могут появиться новые фигуры, а существующие - исключены, поэтому программа должна обладать свойством модифицируемости.
Экранная форма имеет вид (рис. 7):
Рис. 7. Экранная форма задачи 5
Задача 6. При запуске программы на форме появляется линия. При наведении курсора на линию изменяются толщина и цвет линии. Нажатие в этом состоянии на левую клавишу мыши изменяет форму курсора:
если курсор находился на конце линии, то форма курсора отражает состояние «резиновая нить», в этом состоянии мы можем изменить положение конца линии путем перемещения мыши в другую точку;
если курсор находился в средней части линии, то форма курсора отражает состояние «перенос линии», в этом состоянии перемещение мыши приводит к параллельному перемещению линии по экранной форме.
Отпускание мыши приводит задачу в исходное состояние, при этом линия остается в положении, которое она приняла в результате манипуляций.
Используются события класса TForm: OnMouseDown, OnMouseMove, Оп-МошеИр. Для моделирования состояния задачи ввести с помощью перечислимого типа данных значения состояний: «исходное», «параллельный перенос линии», «сдвигать линию относительно конца 1», «сдвигать линию относительно конца 2». Требование: линия должна моделироваться отдельным классом.
Экранная форма имеет вид( рис. 8):
Рис. 8. Экранная форма задачи 6
Задача 7. Стандартный визуальный компонент класса TPane1 с помощью устройства «мышь» не перемещается по форме во время исполнения программы. На основе класса TPane1 создать новый класс TRre1ocatab1ePane1, экземпляры класса которого обладают возможностью перемещения. Зарегистрировать полученный визуальный компонент в системе программирования.
Создать опубликованные свойства-события класса TNotifyEvent: OnLeftBut-tonDown, OnLeftButtonUp, OnMouseMove .
Ввести в программе обработку сообщений Windows: wm_LButtonDown, wm_LButtonUp, wm_MouseMove.
Изменение положения панели в клиентской области формы осуществляется путем изменения значений унаследованных свойств класса TRrelocatablePanel: Left и Top.
3.3. Лабораторные занятия. Для выполнения лабораторных работ нужен справочник по визуальным компонентам. Далее по тексту приведены задания на лабораторный практикум по объектно-ориентированному программированию. Для лучшего представления о содержании работ приведены также методические указания, правила защиты и оценки.
Лабораторная работа №1. Программирование графики.
Задание. При запуске программы на форме приложения появляется геометрическая фигура, которая в последующих работах будет рассматриваться как траектория движения другой геометрической фигуры. Поэтому далее фигура называется траекторией. Предусмотреть: регулятор изменения размера (масштабирования) траектории, настройку цвета фона рабочей области, цвета прорисовки траектории. Экранная форма имеет вид( рис. 9):
Лайпрлтлрнаа райптл №1 [ а | [s]
Размер траектории Г" о [ Цвет траектории ] Цвет фона
Возможные действия 1, Изменить размер траектории 2, Изменить цвет траектории 3, Изменить цвет фона 4, Изменить размер формы
Рис. 9. Экранная форма лабораторной работы № 1 Требования:
1. Центр траектории всегда должен совпадать с центром клиентской области
формы.
2. Траектория не должна выходить за пределы рабочей области.
3. При уменьшении линейных размеров траектории масштаб не должен становиться отрицательным (траектория не должна «выворачиваться наизнанку»).
4. При изменении размеров формы масштаб и центр прорисовки траектории должны соответственно измениться, т.е. изображение всегда должно быть вписано в клиентскую область формы (см. также требования 1 и 2).
5. Для моделирования траектории в программе предусмотреть отдельный класс, размещенный в отдельном программном модуле.
6. Необходимо использовать правила именования идентификаторов.
Варианты заданий (приведены на рис 10).
1.
2.
3.
с;
чУ ''-У С.............. _.■ у........'>
5. 6. 7. 8.
Рис. 10. Варианты траекторий Методические указания.
1) Для моделирования траектории рекомендуется использовать метод базовой точки. Масштабирование траектории осуществляется использованием координатной сетки (на бумаге при проектировании изображения траектории) вида(рис 11):
Рис. 11. Метод базовой точки
Пусть кружок (рис. 11) обозначает центр траектории с координатами ^0, Y0). Тогда координата точки 1 будет иметь значение (X - 4Д, Y0 - 3Д), где Д - размер клетки. Координата точки 2 будет вычисляться как ^о, Y0 + 2,5Д). Если теперь изменить значение Д, то изменится масштаб рисования траектории, а расположение центра фигуры (X, Y0) задает положение траектории в области моделирования.
2) Прорисовку траектории удобно осуществлять методом Ро^оп^Д) компонента ТСапуаз, где M - массив координат точек концов отрезков, координата точки задается стандартным типом ТРот1; k - количество используемых точек.
3) Уравнения траекторий 3-8 имеют вид: X = Cos(A)*R; Y= Sin(B)*R, где А -угол (в радианах), B=k*A, k=1,2,3, ... ; R - радиус фигуры Лиссажу. Траекторию необходимо представить совокупностью отрезков вида (рис. 12):
Рис. 12. Аппроксимация линии отрезками
Размер отрезков подбирается экспериментально. Изменение параметра А подбирается таким образом, чтобы дискретность линии сделать на экране незаметной.
4) Можно рисовать изображения на компоненте TPaintBox (раздел System), так как замечено, что на этом компоненте прорисовка идет быстрее. В этом случае центром прорисовки траектории будет центр рассматриваемого компонента.
5) Для выполнения масштабирования траектории рекомендуется использовать компонент TTrackBar (раздел Win32).
6) Цветовое оформление осуществляется с помощью компонента TColorDia-log (раздел Dialogs)
7) Перерисовка клиентской области осуществляется в методе OnPaint класса TForm, событие перерисовки вызывать методом Invalidate() класса TWinControl (класс TForm является потомком класса TWinControl).
Содержание отчета.
Титульный лист.
Текст задания с описанием варианта задания.
Диаграмма классов.
Исходный текст программы.
Результаты работы программы (копия экранной формы приложения).
Отчет представляется в электронном виде. При защите лабораторной работы после зачетной недели отчет должен быть напечатан.
Защита лабораторной работы.
Студент демонстрирует созданный программный продукт. Необходимо заранее подготовить аргументы, показывающие лучшие особенности программы и качество разработки.
Студент демонстрирует степень выполнения задания.
Студент демонстрирует авторство путем ответов на вопросы по исходному
тексту программы.
Оценка результатов.
В дисциплинах «Программирование» конечным результатом обучения является приобретение профессиональных навыков разработки программ. Поэтому результаты лабораторных работ напрямую формируют аттестационные баллы. Максимальное количество баллов за программу - 17. Максимальное количество баллов за отчет - 8.
Отчет считается недействительным при отсутствии исходного текста программы и при отсутствии диаграммы классов, за остальные недочеты снижаются баллы.
Критерии оценки программы
Задание Оценка
Нарисована траектория 4
Изменяется цвет траектории 1
Изменяется цвет фона 2
Траектория масштабируется от «движка» 5
Траектория масштабируется при изменении размеров формы 5
Всего 17
Корректировочные коэффициенты при оценке программы
Степень выполнения Полученные результаты Коэффициент
1 Нет исходного текста программы 0,0
2 Есть исходный текст программы, но нет чистой трансляции 0,2
3 Лабораторная работа сделана не самостоятельно 0,2
4 Имеются серьезные недоработки. 0,5-0,8
6 Имеются погрешности в работе программы 0,9
7 Программа работает верно. 1,0
Если при выполнении работы получены оригинальные решения, то по усмотрению преподавателя могут быть добавлены поощрительные баллы.
Рекомендуемый срок выполнения и защиты. Конец сентября.
Обязательный срок выполнения и защиты. До первой аттестации. Представленная позже этого срока работа аттестационные баллы не получает.
Лабораторная работа №2. Программирование анимации.
Задание. Взять программу из лабораторной работы № 1 и расширить ее следующими средствами: геометрическая фигура перемещается по траектории и постоянно изменяет свой масштаб («дышит»). Предусмотреть: регулятор скорости перемещения фигуры по траектории, регуляторы диапазона и скорости масштабирования («дыхания»), настройку цвета прорисовки фигуры.
Дополнительное задание для любознательных студентов. Предусмотреть вращение и регулировку скорости вращения фигуры. Экранная форма представлена на рис. 13.
^5 Лабораторная работа №2 1—1ЕЫЗ.)
[ Цвет фона 1
Размер траектории
/' \ | Цвет траектории |
^1 ? Размер фигуры
\ / 1 и
\ / I Цвет фигуры
х Скорость фигуры 1 и
X X Скорость дыхания 1 и
— 2. Изменить цвет траектории 3, Изменить цвет фона
1. Изменить Разнер фигуры 2. Изменить цвет фигуры 3. Изменить скорость фигуры
Рис. 13. Экранная форма лабораторной работы № 2
Требования:
1. При уменьшении линейных размеров фигуры масштаб не должен выходить в отрицательную область (фигура не должна «выворачиваться наизнанку»).
2. Изменение размеров фигуры не должно влиять на скорость «дыхания»
фигуры.
3. Скорость перемещения фигуры по траектории никоим образом не связана со скоростью прорисовки кадров, а определяется величиной шага смещения (чем больше шаг - тем выше скорость).
4. Для моделирования фигуры в программе предусмотреть отдельный класс, размещенный в отдельном модуле.
5. Необходимо использовать правила именования идентификаторов.
Варианты заданий (представлены на рис. 14)
Методические указания:
1. Для прорисовки фигуры рекомендуется использовать метод базовой точки, краткое описание которого приведено в методических рекомендациях к лабораторной работе № 1. Шаг движения фигуры осуществляется путем перемещения позиции базовой точки фигуры в другое место: погасить изображение фигуры, передвинуть базовую точку, высветить изображение фигуры. При использовании метода InvaHdateO заботиться об удалении изображения фигуры не нужно.
2. Управление анимацией осуществляется с помощью компонента TTimer. В процедуру обработки события OnTimer (конца интервала таймера) необходимо включить обработку одного шага анимации (см.п.1).
3. При использовании таймера для перемещения фигуры по траектории с целью обеспечения эффекта мультипликации (непрерывного движения со скоростью прорисовки 25 кадров в секунду) интервал таймера следует принять равным 40мс.
4. Управление скоростью движения фигуры целесообразно осуществлять увеличения или уменьшения расстояния, на которое перемещается фигура за один шаг движения фигуры.
Разделы содержание отчета, защита лабораторной работы, оценка результатов, сроки выполнения задания формулируются аналогично соответствующим разделам лабораторной работы № 1 .
Лабораторная работа № 3. Программирование взаимодействия программы с окружением.
Задание. Взять программу из лабораторной работы № 2 и расширить ее следующими средствами:
- организовать сохранение и восстановление настроек интерфейса приложения: размеров и положения формы приложения, размеров траектории и фигуры, скорости движения и «дыхания» фигуры, цвета фона и тона прорисовки;
- предусмотреть возможность редактирования фигуры из текстового поля;
- предусмотреть возможность сохранения фигуры в буфере обмена и восстановления фигуры из буфера обмена.
Требования:
1. После выполнения операций сохранения и восстановления настроек интерфейса состояние экранной формы приложения должно оставаться неизменным.
2. При окончании выполнения приложения настройки интерфейса должны сохраняться автоматически.
3. При запуске приложения сохраненные настройки интерфейса должны восстанавливаться автоматически.
4. При изменении текстового поля изображение фигуры должно изменяться автоматически.
5. Операции с буфером обмена выполнять в текстовом формате.
6. Необходимо использовать правила именования идентификаторов.
Варианты заданий. Отсутствуют.
Методические указания.
1. Для сохранения и восстановления настроек интерфейса предлагается использовать компонент TIniFile. TIniFile не является визуальным компонентом и по-
этому мы его не найдем в Палитре компонентов (Tool Palette). Описание типа данных TIniFile находится в пространстве имен IniFiles.hpp, возможность использования TIniFile достигается включением в программный модуль строки
#include <IniFiles.hpp>
2. Действия по сохранению настроек интерфейса рекомендуется включать в метод обработки события OnClose - событие закрытия формы. В Ini - файле рекомендуется создать три раздела: форма, траектория и фигура.
3. Действия по восстановлению настроек интерфейса включать в метод обработки события формы OnCreate.
4. Для редактирования фигуры необходимо разработать формат текста, например, для фигуры «квадрат» формат текста может быть следующим:
Квадрат -100, -100 100, -100 -100, 100 -100, -100
Первой строкой, как показано в этом примере, может быть имя фигуры, а в следующих строках координаты вершин. Другие фигуры, например «круг», рекомендуется отображать в текстовом поле также системой координат отдельных точек.
5. Моделирование текстового поля в программе рекомендуется осуществлять визуальным компонентом TMemo (раздел Standard).
6. Для выполнения операций копирования и вставки фигуры в буфер обмена рекомендуется использовать компонент TClipboard. Описание невизуального компонента TClipboard находится в пространстве имен Clipbrd.hpp.
Разделы содержание отчета, защита лабораторной работы, оценка результатов, сроки выполнения задания формулируются аналогично соответствующим разделам лабораторной работы № 1.
Лабораторная работа № 4. Программирование обработки сообщений и событий.
Задание. Взять программу из лабораторной работы № 3 и расширить ее следующими средствами:
- предусмотреть перехват события WM_DRAWCLIPBOARD (изменение содержимого буфера обмена) - отобразить новое содержимое буфера в поле Memo и новую фигуру в окне прорисовки освоение обработки ошибок;
- с помощью класса Exception сделать порождение и обработку исключительных ситуаций на файловые операции.
Разделы содержание отчета, защита лабораторной работы, оценка результатов, сроки выполнения задания формулируются аналогично соответствующим разделам лабораторной работы № 1 .
Проведение лабораторных работ по рассмотренной схеме позволило сформулировать следующие наблюдения.
Некоторые студенты стараются выполнить задания с повышенным энтузиазмом, предлагая оригинальные решения или выполняя нечто, находящееся за рамками задания. В итоге они получают (кроме очевидного опыта) поощрительные баллы. К сожалению, такие дополнительные баллы плохо вписываются в стандартную бальнорейтинговую систему. Как было бы замечательно поощрять таких студентов более материально!
Другие студенты приходя на защиту лабораторной работы сразу осознанно заявляют о получении баллов отличных от максимальных.
Наиболее эмоционально проходят защиты выполненных несамостоятельно лабораторных работ. Факт несамостоятельно выявляется достаточно просто, однако приходиться корректно «убеждать» в этом студента.
3.4. Итоговая оценка. Итоговой оценкой по дисциплине в настоящее время является «зачет». Для получения итоговой оценки необходимо:
- выполнить все четыре лабораторных работы (независимо от набранных баллов);
- набрать не менее 51 аттестационного балла.
При нехватке аттестационных баллов зачет проходит в теоретической форме в виде ответов на вопросы по содержанию лекционного курса.
При завершении дисциплины экзаменом замечены казусы. Например, студент N пришел на экзамен, до оценки «отлично» ему не хватало пяти баллов. За экзамен он мог получить максимум двадцать баллов. Ответив на один из трех вопросов билета он заявил, что необходимые пять баллов он заработал, а на остальные вопросы отвечать небудет, т.к. просто не готов ответить. Чтобы не дескредитировать бально-рейтинговую систему пришлось поставить ему «отлично».
Заключение
Автор намеренно в некоторых случаях сгустил краски и не ставит перед собой задачу дать исчерпывающие ответы на все поставленные вопросы. Скорее наоборот, цель статьи - обозначить проблемные моменты и привлечь коллективный разум к их преодолению. Нужны методические эксперименты.
Литература
1. Буч Г. Объектно-ориентированный анализ и проектирование приложений на Си++. -М.: Бином; СПб.: Невский диалект, 2001. -560с.
2. Дал У., Дейкстра Э., Хоор К. Структурное программирование. -М. Мир, 1975. -247с.
