111
программирования, является разработка подходов и инструментов для быстрого
создания макетов систем как части итеративного процесса разработки
спецификаций.
Макет программной системы моделирует главные интерфейсы и выполняет основные
функции предполагаемой системы, при этом не обязательно будучи связан теми же
ограничениями быстродействия компьютера, размера или стоимости. Обычно макеты
выполняют основные задачи системы, но не пытаются обрабатывать
исключительные ситуации, правильно реагировать на ввод недопустимых данных,
корректно прерывать работу и т.д. Назначение макета — показать, как воплощается
выбранная концептуальная структура, чтобы клиент мог проверить ее пригодность к
использованию и непротиворечивость.
Сегодня многие процедуры приобретения программного обеспечения основываются
на предположении, что можно заранее задать технические требования для желаемой
системы, рассмотреть предложения разработчиков, получить разработанную систему
и установить ее. Я думаю, что такое предположение в корне неверно, и из-за этой
ошибки проистекают многие проблемы при приобретении программ, поскольку эти
проблемы нельзя устранить без пересмотра основ, для которого требуется
интерактивная разработка и спецификации макетов и продуктов.
Пошаговая обработка: наращивать программу, а не строить сразу. Я до сих пор
помню испытанный в 1958 году удар, когда впервые услышал, как мой друг говорил
о строительстве (building) программ в противоположность написанию (writing). В
мгновение он расширил все мое представление о процессе программирования.
Применение метафоры было сильным и точным. Сегодня мы понимаем, что сходство
существует между созданием программы и другими строительными процессами, и
свободно используем другие элементы метафоры, такие как спецификации
(specifications), сборка компонентов (assembly of components), леса (scaffolding).
Метафора строительства пережила свое время. Пора снова вносить изменения. Если,
как я считаю, создаваемые сегодня концептуальные структуры слишком сложны,
чтобы их можно было точно специфицировать заранее, и слишком сложны, чтобы
строить без ошибок, тогда нужен радикально иной подход.
Обратимся к природе и рассмотрим сложность живых созданий, а не безжизненных
творений человека. Там мы обнаруживаем конструкции, сложность которых вселяет
в нас ужас. Один только мозг настолько сложен, что невозможно составить его
схему. Его мощь невозможно повторить, он богат своеобразием, способен к
самосохранению и самообновлению. Секрет в том, что мозг растет, а не строится.
Так же должны создаваться наши программные системы. Несколько лет назад
Харлан Миллз предложил наращивать программные системы путем пошаговой
разработки.
11
Это значит, что сначала систему надо заставить выполняться, даже
если при этом она не делает ничего полезного, кроме вызова некоторого числа
фиктивных подпрограмм. Затем она понемногу обрастает мясом, причем
подпрограммы, в свою очередь, разрабатываются сначала как вызовы пустых
фиктивных подпрограмм, находящихся на уровень ниже.
Настаивая на применении этой технологии разработчиками проектов на моих
лабораторных занятиях по программной инженерии, я стал свидетелем
поразительных результатов. За последнее десятилетие ничто другое не оказало
столь сильного влияния на мою собственную работу и ее эффективность. Этот
подход предполагает нисходящее проектирование, поскольку это — нисходящее
наращивание программы. Он позволяет легко отслеживать работу в обратном
направлении. Он предоставляет возможность раннего создания макетов. Каждая
новая функция или возможность работы с более сложными данными или условиями
органически вырастают на того, что уже имеется.
Воздействие на моральный дух ошеломительное. Когда есть хотя бы простая
работающая система, возрастает энтузиазм. Энергия удваивается, когда на экране
появляется картинка из новой графической программной системы, даже если это
всего лишь прямоугольник. И на каждой стадии процесса разработки существует