учебники, программирование, основы, введение в,

 

Обучение методу

Профессиональная подготовка (тренинг) в индустрии
Давайте начнем с нескольких общих наблюдений по поводу обучения объектным технологиям профессионалов, уже освоивших другие подходы. Обучение может вестись либо на семинарах, либо согласно внутреннему плану переподготовки, разработанному в компании.
Парадоксально, но задача тренера теперь может быть труднее, чем в середине восьмидесятых, когда к этому методу было привлечено широкое внимание. Тогда он был нов для большинства людей и имел ауру еретика, что всегда привлекает слушателей. Сегодня никто не будет шокирован, если кто-то заявит о своем пристрастии к ОО-методу. От постоянного упоминания в компьютерной прессе - ОО это и ОО то - возник своего рода шумовой эффект, называемый mOOzak. Слова объект, класс, полиморфизм от частого употребления становятся затертыми, они кажутся знакомыми, но широко ли понимаются стоящие за ними концепции? Зачастую нет! Это накладывает на тренера новую ношу - объяснить обучаемым, что они знают не все. Невозможно научить чему-либо человека, если он думает, что он уже это знает.
Единственная стратегия, гарантирующая преодоление этой проблемы, состоит в следующем:


Начальный тренинг: стратегия "пройди его дважды"
  • T1 Пройди начальный курс.
  • T2 Попытайся выполнить ОО-разработку.
  • T3 Пройди начальный курс.

Выполнение этапа T3 кажется странным: применив ОО-метод в реальной разработке, снова слушать тот же курс. Компаниям, занимающимся ОО-обучением, не всегда удается применять эту стратегию, так как она выглядит подозрительно - вам дважды предлагают продать одну и ту же вещь. Но здесь обмана нет.
Понимание концепций по-настоящему приходит во время второй итерации. Хотя первая необходима для обеспечения основы, она не может быть полностью эффективной частично из-за эффекта mOOzak, частично из-за сложностей умозрительного восприятия концепций. Только тогда, когда слушатели сталкиваются день изо дня с ежедневными выборами ОО-конструирования - Нужен ли новый класс для этого понятия? Подходит ли здесь наследование? Следует ли ввести из-за этих двух компонентов новый узел в структуре наследования? Соответствует ли образец из курса моей ситуации? - только после этого они получают необходимую подготовку для правильного восприятия курса. Вторая сессия не будет, конечно же, идентична первой (по крайней мере, вопросы аудитории станут интереснее), она скорее находится на границе между тренингом и консультацией, но она действительно должна представлять вторую итерацию того же основного материала, ни в коей мере не являясь углубленным курсом, следующим за начальным.


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

Следующий принцип говорит о тематике обучения:


Принцип Темы Тренинга
В начальном курсе в особенности сфокусируйтесь на реализации и проектировании.

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


Принцип углубленной учебной программы
По меньшей мере 50% бюджета тренинга должно быть резервировано для невводных курсов.

Наконец, следует учить не только разработчиков:


Принцип Тренинга Менеджеров
Программа тренинга должна включать курсы для менеджеров, также как и для разработчиков.

Для компании, адаптирующей ОО-технологию, нереально надеяться на успех, обучая только разработчиков. Менеджеры, независимо от уровня их технической подготовки, должны быть знакомы с основными ОО-идеями, уметь оценивать их влияние на распределение задач, организацию команды, жизненный цикл проекта, экономику разработки ПО. Жизненный цикл обсуждается в следующей лекции (основательно в книгах, ориентированных на менеджеров, таких как [Goldberg 1995], [Baudoin 1996] и [M 1995]).


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

Вводные курсы

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

Филогенез и онтогенез

Когда следует начинать?
Чем раньше, тем лучше. ОО-метод обеспечивает прекрасную интеллектуальную дисциплину. Если вы согласны с ее целями и техникой, то нет причин в задержке обучения им ваших студентов. Фактически это должен быть первый подход, с которого следует начинать обучение. Начинающие положительно воспринимают ОО-подход не потому, что такова тенденция, а по причине его ясности и эффективности.
Эта стратегия предпочтительнее, чем вначале учить старым подходам, а затем переучивать, прививая ОО-мышление. Нет смысла в обходных путях, когда есть прямая дорога ОО-разработки.
Преподаватели неосознанно склонны применять идею, некогда популярную в биологии: онтогенез (развитие индивидуума) повторяет филогенез (развитие вида). Человеческий эмбрион на разных этапах своего развития напоминает лягушку, свинью и т. д. Применительно к нашему предмету рассмотрения это означает, что учитель, возможно, начинавший изучать Algol, затем перешедший к структурному проектированию, затем познавший объекты, захочет, чтобы и его студенты прошли тот же путь. Что было бы с начальным образованием, если бы детей учили считать, вначале используя римские цифры, и лишь потом вводили арабские? Если вы думаете, что знаете правильный подход, учите ему сразу.

Вымощенная дорога к другим подходам

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

Выбор языка

Использование ОО-метода во вводном курсе имеет смысл только тогда, когда оно основано на окружении и языке, полностью поддерживающем эту парадигму и не отягощенном призраками прошлого. В частности, гибридные подходы, основанные на расширениях старых языков, не подходят для начинающих студентов, поскольку смешивают ОО-концепции с пережитками старых методов, принуждая преподавателя тратить больше времени на извинения, чем на сами концепции.
В языках, основанных на C, например, придется объяснять, почему массив и указатель следует рассматривать как одно и то же понятие - свойство, имеющее корни в технике оптимизации старой архитектуры компьютеров; на эти объяснения потребуется время и энергия в ущерб обучению понятиям проектирования программ. Более того, это ведет к тому, что студенты приучаются мыслить в терминах низкоуровневых механизмов - адресов, указателей, памяти, сигналов. Они будут тратить неоправданно много времени на борьбу с различными жучками в своих программах.
Задачи вводного курса разнообразны. Следует снабдить студентов ясным, логически связанным множеством практических принципов. Нотация должна непосредственно поддерживать эти принципы, устанавливая взаимно однозначное соответствие между методом и языком. Время, затрачиваемое на объяснение языка самого по себе, зря потрачено. Следует объяснять концепции и использовать язык как естественный способ их применения.
Главное качество языка, используемого во вводном курсе, это его структурная простота и поддержка ОО-идей: модульность, основанная на классах, проектирование по контракту, статическая типизация и наследование. Но не следует недооценивать роли синтаксической ясности. Например, тексты на C++ и Java наполнены строками, такими как:

public static void main(String[] args {
if (this->fd == -1 && !open_fd(this))
if ((xfrm = (char*)malloc(xfrm_len + 1)) == NULL) {

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

  • Первое, с чем они сталкиваются, это главная программа с заголовком: public static void main (String [ ] args), выбрасывающая исключения вида IOException. Здесь в одной строке встречается 6 различных понятий, которые студенты не готовы воспринимать.
  • Достаточно свободно можно осуществить вывод, но чтобы что-то ввести, потребуется попрыгать (import, declare, initialize). Единственный способ ввода числа с клавиатуры - это прочесть строку и разобрать ее. И снова с этим приходится сталкиваться уже на первой лекции.
  • Java рассматривает примитивные типы данных (int, char, boolean, float, long, ...) не так, как другие объекты. Здесь есть их объектные эквиваленты (Integer, Boolean, Character и т. д.). Но нет связи между int и Integer.
  • Класс String представляет специальный случай (для эффективности). Он используется только для строк, не меняющих значения. Есть также класс StringBuffer для строк, меняющих свое значение. Все прекрасно, но нет взаимосвязи между этими классами. Есть только несколько общих компонентов.
  • Отсутствие универсальности означает необходимость преобразования типов, например, при использовании коллекций элементов, таких как Stack или Hashtable. Все это создает помехи для начинающих студентов и уводит их в сторону от главных целей обучения.

Проф. Кларк далее сравнивает этот опыт с его практикой обучения с использованием нотации этой книги, о которой он пишет: "Я фактически не учил языку, помимо некоторых примеров кода".
Начальная нотация, используемая при обучении, крайне важна для формирования их будущего видения, она должна быть простой и ясной, позволять глубоко понимать базисные понятия. Даже Pascal, традиционный выбор вводного курса факультетов, специализирующихся в подготовке по информатике, предпочтительнее во многих отношениях, чем гибридные языки, так как обеспечивает компактный, согласованный базис, от которого позже студенты могут перейти к другому компактному, согласованному подходу. Конечно, было бы лучше, если бы базис был компактным, согласованным и объектно-ориентированным.
Некоторые гибридные языки имеют индустриальную значимость, но им следует учить позднее, когда студенты овладеют базисными концепциями. Это не новая идея: когда в семидесятых годах факультеты информатики (computing science departments) приняли Pascal, они также включали специальные курсы по изучению Fortran, Cobol или PL/I, что требовалось тогда индустрии. Аналогично современный учебный план может включать специальные курсы по C++ или Java для удовлетворения требований индустрии, давая возможность студентам включать требуемые шумовые слова в свои резюме. В любом случае студенты лучше поймут C++ и Java после изучения объектной технологии, используя чистый ОО-язык. Начальный курс, формирующий сознание у студентов, должен использовать лучший технический подход.
Некоторые преподаватели пытаются использовать гибриды C из-за ощущаемого давления индустрии. Но этого не стоит делать по ряду причин:

  • Требования индустрии изменчивы. В какие-то годы все хотели что-то подобное RPG и Cobol. В конце 1996 все начали требовать Java, но еще в 1995 никто и не слышал о Java. Что же будет стоять в списке 2010 или 2020? Мы не знаем, но мы обязаны наделить наших студентов потенциалом, который будет востребован на рынке и в эти годы. По этой причине особое внимание следует уделять долговременным навыкам проектирования и разумным (intellectual) принципам.
  • То, что мы начинаем обучать таким навыкам и принципам, вовсе не исключает обучения специфическим подходам. На самом деле, как отмечалось, скорее помогает. Студент, глубоко освоивший ОО-концепции, используя подходящую нотацию, будет лучшим C++- или Java-программистом, чем тот, для кого первая встреча с программированием включала битву с языком.
  • Исторический прецедент с Pascal показывает, что преподаватели информатики могут добиться успеха, благодаря собственному выбору. В середине семидесятых годов в индустрии никто не требовал Pascal; фактически почти никто в индустрии и не слышал о Pascal. В те времена индустрия требовала одного из Трех Теноров - Fortran, Cobol и PL/I. В преподавании и в науке было выбрано другое решение - наилучшее техническое решение, соответствующее тому уровню, на котором находилась программистская методология - структурное программирование. Результат себя оправдал, студентов стали обучать абстрактным концепциям и техническим приемам разработки программ, подготавливая их к изучению новых языков и инструментария.

Другие курсы

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

Терминология

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

  • Под средним образованием будем понимать средние школы, лицеи, гимназии (High school (US), lyceum, Gymnasium).
  • Высшее образование - первые несколько лет университета или их эквивалент (то, что называется "undergraduate studies" в США и других англо-саксонских странах, Gakubu в Японии). Во Франции и других странах, находящихся под влиянием ее системы образования, это соответствует комбинации классов preparatoires и первых двух лет инженерных школ или первому и второму циклу университетов. В системе образования Германии это соответствует Grundstudium. Термин высшее образование (undergraduate) будет использоваться ниже для этого уровня.
  • Наконец, для последних лет образования (магистратура, аспирантура), заканчивающихся присуждением научных степеней, будем использовать термин аспирантура (graduate - в США, postgraduate - в Англии, DEA, DESS - во Франции, Hauptstudium - в Германии, Daigakuin - в Японии).

Среднее и высшее образование

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

  • Структуры данных и алгоритмы. Фундаментом может служить техника Проектирования по Контракту: подпрограммы должны характеризоваться утверждениями, структуры данных специфицироваться инвариантами класса, с алгоритмами должны связываться инварианты и варианты циклов. Помимо этого, новаторским и эффективным способом является организация этого курса как проекта на базе существующей библиотеки программных компонентов в существующем ОО-окружении. Тогда, вместо того чтобы начинать с нуля, студенты могут заниматься повторением и улучшением компонентов. (Смотри ниже подробности на эту тему.
  • Инженерия ПО. ОО-метод обеспечивает отличную основу для введения студентов в проблемы индустриальной, командной разработки ПО. В частности, оценка способов управления проектами, метрики, применяемые в процессе разработки, экономика проекта, окружение разработки и другие вопросы, обсуждаемые в литературе по инженерии ПО (в дополнение к объектной ориентации).
  • Анализ и проектирование. Ясно, что все это может изучаться полностью на объектной основе. Снова в центре будет оставаться Проектирование по Контракту. В курсе должен делаться акцент на бесшовном переходе к реализации и сопровождению.
  • Введение в графику, введение в моделирование и так далее.

Вот курсы, которые могут получать преимущества от использования "тяжелых" или "легких" объектов. Операционные системы, где метод помогает освоить понятия процесса, парадигму обмена сообщениями, важность скрытия информации, четкого определения интерфейсов, ограничений коммуникационных каналов при проектировании подходящей архитектуры систем. Введение в формальные методы, Функциональное программирование, Логическое программирование, где упор должен делаться на связь с утверждениями. Введение в искусственный интеллект, где наследование является ключевым элементом представления знаний. Базы данных, где центральное место должно отводиться понятию АТД и обсуждению ОО-баз данных.
Даже на курс по архитектуре компьютеров влияют ОО-идеи: концепции модульности, скрытия информации и утверждения могут служить для представления материала ясным и убедительным способом.

Курсы для аспирантов

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

Полный учебный план (curriculum)

Этот неполный список показывает возможности повсеместного применения метода, так что возникает ощущение, что вокруг него можно построить полный учебный план по специальности (software curriculum). Несколько организаций уже добились некоторого успеха в этом направлении. Нет сомнений, что кто-то может сделать прорыв и довести до сознания руководства университета, что следует идти по этой дороге.

Вперед к новой педагогике для программистов

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

Стратегия "от потребителя к производителю"

ОО-курс по структурам данным и алгоритмам, как отмечалось выше, может быть построен вокруг библиотеки. Эта идея фактически имеет более широкую область применения.
Разочаровывающий эффект многих курсов зачастую связан с тем, что преподаватели дают только простые примеры и упражнения, так что студенты не работают с реальными интересными приложениями. Можно ли получить удовлетворение от вычисления первых 25 чисел Фибоначчи или от замены в тексте одного слова другим - типичные примеры элементарного программистского курса.
С ОО-методом, хорошим ОО-окружением и, что наиболее важно, хорошими библиотеками возможной становится другая стратегия, при которой студентам дается доступ к библиотекам, как можно раньше. В этой роли студенты выступают просто как потребители, используя библиотечные компоненты, как черные ящики в том их значении, как это было описано в одной из предыдущих лекций. Этот подход предполагает доступность описания компонентов без показа их внутреннего содержания. Тогда студенты могут сразу же начать строить осмысленные приложения: их задача состоит главным образом в том, чтобы собрать систему из существующих компонентов. Проблемы и радости разработки познаются лучше, чем при рассмотрении игрушечных примеров, которыми довольствуются многие вводные курсы.
Повторно используя данное им ПО, студенты за день могут создать впечатляющее приложение. Их первое задание может состоять из написания всего нескольких строчек, сводящихся к вызову предварительно построенного приложения и вывода поразительных результатов (подготовленных кем-либо ранее!). Желательно, кстати, использовать библиотеки, включающие графику, мультимедийные компоненты, чтобы вывод был по-настоящему захватывающим.
Шаг за шагом студенты будут идти дальше: анализируя тексты некоторых компонентов, они могут сделать некоторые модификации и расширения либо в самих классах, либо в их новых потомках. Наконец, они перейдут к написанию собственных классов (шаг, который был бы первым в традиционном учебном плане, но который не должен встречаться, пока есть обильное поле деятельности для работы с библиотеками).
Этот обучающий процесс может быть назван "постепенным открытием черных ящиков" или более коротко стратегией "от потребителя к производителю". ("Изнутри наружу" также было бы подходящим названием стратегии.)


Стратегия от потребителя к производителю
  • S1 Научитесь использовать библиотечные классы, зная их абстрактные спецификации.
  • S2 Научитесь понимать внутреннее устройство выбранных классов.
  • S3 Научитесь расширять выбранные классы.
  • S4 Научитесь модифицировать выбранные классы.
  • S5 Научитесь добавлять собственные классы.

Если вам нравятся автомобильные сравнения, то подумайте о том, кто первым научил вас водить машину, затем поднял капот и шаг за шагом рассказал вам о работе мотора, потом научил вас ремонтировать его и много позже, как проектировать собственные автомобили.

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

Абстракция

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

Ученичество

Стратегия "от потребителя к производителю" представляет применение к программистскому обучению техники, освященной временем, - ученичество. Ученик, отданный в обучение мастеру, учится, пока мастер не поймет, что техника подмастерья не хуже, чем у мастера. За отсутствием нужного числа доступных мастеров применимость такого способа (мастер - ученик) ограничена. Но, к счастью, нам не нужны сами мастера, достаточно иметь результаты их работы - повторно используемые компоненты.
Этот подход является продолжением тенденции, уже повлиявшей на обучение некоторым темам в программистском образовании, таких как конструирование компиляторов, еще до того, как объектная технология стала популярной. В семидесятых и в начале восьмидесятых годов типичный семестровый курс по компиляторам включал написание компилятора (интерпретатора) с нуля. Однако первые же задачи лексического анализа и разбора требовали столь больших усилий, что на практике компилятор мог быть построен только для игрушечного языка. Обычно дело не доходило до наиболее интересных вещей: семантического анализа, генерации кода и оптимизации. Когда же появился и стал широко применяться инструментарий для лексического анализа и разбора, такой как Lex и Yacc, то это позволило студентам тратить на эти задачи существенно меньше времени. Наша стратегия обобщает этот опыт.

Обращенный учебный план

Стратегия "от потребителя к производителю" имеет интересного двойника в электротехнической инженерии, где Бернар Кохен предложил "обращенный учебный план". Критикуя классическую последовательность изложения (теория поля, теория цепей, энергетика, устройства, теория управления, цифровые системы, VLSI проектирование), он предлагает системно-ориентированную последовательность:

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

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

Политика многих семестров

Стратегия "от потребителя к производителю" имеет интересный вариант применения в курсах, ориентированных на приложения, таких как Операционные системы, Графика, Конструирование компиляторов или Искусственный интеллект.
Идея состоит в том, чтобы дать студентам возможность построения системы путем последовательного расширения и обобщения, используя на каждом году обучения труд предыдущего года. Этот метод имеет очевидный недостаток на первом курсе, поскольку его труд служит основой для последующих расширений, но сам он не получает преимуществ повторного использования. Должен признаться, что я не видел систематического применения такого подхода, но на бумаге он выглядит привлекательным. Кажется, что вряд ли есть лучший способ дать студентам почувствовать все преимущества и трудности повторного использования, необходимости построения расширяющегося ПО, проблем улучшения кем-то сделанной работы. Такой опыт подготовил бы студентов к работе в их будущей компании, где шансы заняться сопровождением уже разработанного ПО гораздо выше участия в разработке нового продукта.
Даже если условия не допускают такой многолетней работы, следует избегать стандартных ловушек. Многие учебные планы высшего образования включают курс по "инженерии ПО", часто играющий ключевую роль для проекта, разрабатываемого группой студентов. Такая работа над проектом необходима, но зачастую оставляет разочарование из-за временных ограничений семестрового курса. Если это административно возможно, то желательно вести эту работу в течение всего года, даже при том же количестве часов. Трехмесячные проекты на границе абсурда, они либо заканчиваются на этапе анализа или проектирования, или результатом будет гонка в работе над кодом в течение последних нескольких недель с применением любых методов, часто противоречащих исходным целям образования. Нужно больше времени, чтобы студенты могли ощутить глубину проблем, стоящих при построении серьезного ПО. Проект, длящийся год, а еще лучше являющийся частью многосеместровой политики, благоприятствует этому процессу. Он плохо укладывается в типичные ста ндар тные планы, но за него стоит сражаться.
Объектно-ориентированный план
Идея стратегии многих семестров, основанная на повторном использовании, а также на организации всего учебного процесса вокруг ОО-концепций, может привести к более амбициозному подходу, захватывающему не только образование, но и исследования и разработки. Хотя эта концепция может быть привлекательной не для всех институтов, она заслуживает рассмотрения.
Рассмотрим факультет (кафедру) университета (информатики, информационных систем или их эквивалент) в поисках многосеместрового объединяющего проекта. Такой проект призван обеспечить лучшее обучение, разработку новых курсов, факультетские исследования, являлся бы источником публикаций, магистерских и кандидатских диссертаций, дипломных работ, допускал бы сотрудничество с индустрией и получение правительственных грантов. Сегодня большинство уважаемых факультетов именно так позиционируют себя, ориентируясь на многолетнюю коллективную работу.
ОО-метод является естественной основой таких попыток. Сосредоточиться необходимо не на разработке компиляторов, интерпретаторов или инструментария (это прерогатива компаний), но на библиотеках. То, что сегодня необходимо ОО-технологии, так это повторно используемые компоненты, ориентированные на приложения, называемые также прикладными библиотеками. Хорошее ОО-окружение уже обеспечивает, как отмечалось, множество библиотек общецелевого назначения, покрывающих такие универсальные потребности, как фундаментальные структуры данных и алгоритмы, графику, проектирование пользовательского интерфейса, грамматического разбора текстов. Открытыми остаются многие области приложений - от Web-документов до мультимедиа, от финансового ПО до анализа сигналов, от компьютерного проектирования документов до обработки документов. В подобных областях необходимость качественных компонентов является прямо кричащей.
Выбор разработки библиотеки в качестве проекта, объединяющего усилия факультета, дает несколько преимуществ:

  • Хотя проект рассчитан на длительную перспективу, частные результаты могут быть получены в короткие сроки. Компиляторы и подобные разработки относятся к категории "все или ничего" - пока они полностью не завершены, их распространение скорее повредит вашей репутации, чем поможет ей. С библиотеками дело обстоит по-другому, даже десятка два качественных повторно используемых классов могут оказать потрясающую службу своим пользователям и привлечь к ним значительное внимание.
  • Поскольку серьезная библиотека является большим проектом, то в ней найдется место для вклада многих людей - от хорошо подготовленных студентов до доцентов и профессоров. Предполагается, конечно, что правильно выбрана проблемная область, и она соответствует научным и другим ресурсам факультета или кафедры.
  • Если говорить о ресурсах, то проект может начинаться достаточно скромно, но быть прямым кандидатом для привлечения внимания организаций, занимающихся распределением фондов. Он также может быть предложен тем компаниям, для которых интересна выбранная проблемная область.
  • Построение хорошей библиотеки представляет привлекательную задачу, ставящую новые научные проблемы, так что выходом успешного проекта может быть не только ПО, но и публикации, диссертации. Возникающие при этом научные проблемы могут быть двух видов. Во-первых, конструирование повторно используемых компонентов представляет одну из наиболее интересных и трудных проблем инженерии программ, в решении которых метод оказывает некоторую помощь, но определенно не дает ответа на все вопросы. Во-вторых, любая успешная прикладная библиотека должна опираться на таксономию предметной области, требуя долговременных усилий в классификации известных концепций в этой области. Как хорошо известно, в естественных науках (вспомните обсуждение истории таксономии в) классификация является первым шагом в понимании сути. Такие усилия, предпринятые для новой проблемной области, известные как анализ предметной области, поднимают новые и интересные проблемы.
  • Предполагается возможность междисциплинарной кооперации с исследователями из различных областей приложения.
  • Кооперацию следует начинать с людей, работающих в соседних областях. Многие университеты располагают двумя группами специалистов: одних, ориентированных на инженерию программ (часто "comliuting science"), других - на проблемы бизнеса (часто "information systems"). Независимо от того, разделены эти две группы или являются частями одной структуры, проект может быть привлекателен для обеих групп, обеспечивая возможность сотрудничества.
  • Наконец, успешная библиотека, предоставляющая программные компоненты для важной проблемной области, может стать широко известной, принеся известность ее разработчикам.

Можно надеяться, что в ближайшие годы появятся университеты, вдохновившиеся этими идеями и создавшие "Повторно используемые Финансовые Компоненты X Университета -" или "Библиотека ОО-Обработки Текстов Y Политехнического института". Имена у них будут красивее приведенных, но столь же известны, как в свое время UCSD Pascal, Waterloo Fortran и система X Window, разработанная в MIT.

Ключевые концепции

  • В ОО-тренинге основное внимание уделяйте реализации и проектированию.
  • В начальном тренинге для профессионалов без колебаний повторяйте сессию, посвященную концепциям, после некоторой фазы практической работы.
  • Тренинг в компании должен включать курсы для менеджеров наряду с курсами для разработчиков.
  • Начальный курс по программированию и многие другие могут получать преимущества от введения ОО-приемов.
  • Для обучения используйте чистый ОО-язык, простой и понятный, поддерживающий полный спектр технологии, в частности утверждения.
  • Курсы должны, насколько возможно, основываться на библиотеках повторно используемых компонентов.
  • Стратегия "от потребителя к производителю" (подобная идеям обращенного учебного плана) - снабжать студентов существующими компонентами, позволяя им с самого начала создавать полноценные приложения, расширять их и создавать новые компоненты, имитируя процесс ученичества.
  • Долговременный проект по созданию библиотеки может объединить усилия кафедры или факультета.
 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика