Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы

Снимки моментального состояния. Машины, для которых были разработаны дампы памяти, имели память размером 2000-4000 слов, или 8-16 Кбайт. Однако размер памяти рос огромными темпами, и делать дамп памяти стало нереальным. Поэтому разработали методы выборочного дампа, выборочной трассировки и вставки в программы команд для моментальных снимков. Вершиной развития этого направления стал TESTRAN в OS/360, позволявший вставлять в программу моментальные снимки без повторной сборки и компиляции.

Интерактивная отладка. В 1959 году Кодд (Codd) с коллегами [5] и Стрейчи (Strachey) [6] сообщили о работе, целью которой была отладка в режиме разделения времени, позволяющая одновременно достичь мгновенной оборачиваемости отладки в активном режиме и эффективно использовать машинное время, как при пакетной обработке заданий. Компьютер должен был иметь в памяти несколько программ, готовых к запуску. Терминал, управляемый только программой, должен был быть связан с каждой из отлаживаемых программ. Отладка должна была проходить под управлением программы-супервизора. Когда программист за терминалом останавливал свою программу, чтобы изучить ее выполнение или внести изменения, супервизор запускал другую программу, занимая таким образом машину.

Мультипрограммная система Кодда была разработана, но акцент был сделан на увеличение производительности благодаря эффективному использованию ввода-вывода, и интерактивная отладка не была осуществлена. Идеи Стрейчи были улучшены и в 1963 году воплощены Корбато с коллегами в МТИ в экспериментальной системе 7090. Это разработке привела к MULTICS, TSS и другим сегодняшним системам разделения времени.

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

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

Тем не менее интересные экспериментальные данные Голда (Gold) показывают, что во время первого диалога каждого сеанса достигается втрое больший прогресс в интерактивной отладке, чем при последующих диалогах. [8] Это убедительно говорит о том, что из-за отсутствия планирования мы не полностью реализуем потенциал диалоговой работы. Пора стряхнуть пыль со старых методов работы в интерактивном режиме.

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

Контрольные примеры. Что касается разработки фактических процедур отладки и контрольных примеров, особенно удачное изложение предлагает Грюнбергер (Gruenberger), [9] есть и более короткие описания в других известных учебниках. 10, [11]

Системная отладка

Неожиданно трудным этапом создания системы программирования оказывается тестирование системы. Я уже обсуждал некоторые причины как его трудности, так и непредсказуемости. Можно не сомневаться в двух вещах: системная отладка займет больше времени, чем предполагается, а ее сложность оправдывает досконально систематичный и плановый подход. Рассмотрим, что включает в себя такой подход. [12]

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

Далее общепринятая практика следует двумя путями. Первый подход — «свинти и попробуй». Видимо, он основывается на том, что кроме ошибок в компонентах найдутся и ошибки в системе (т.е. в интерфейсах). Чем скорее части будут соединены вместе, тем скорее всплывут системные ошибки. Легко также представить, что, используя компоненты для тестирования друг друга, можно в значительной мере избежать создания окружения для тестирования. И то, и другое, очевидно, является правдой, но, как показывает опыт, не всей правдой: значительно больше времени сберегается при тестировании системы с использованием чистых отлаженных компонентов, чем его тратится на создание окружения и доскональной проверки компонентов.

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

Все это означает принимать желаемое за действительное и происходит от стремления объяснить провал графика работ. Никто не знает всех возможных последствий известных ошибок. Если бы все было просто, системное тестирование не вызывало бы затруднений. Кроме того, исправление документированных ошибок, несомненно, приведет к внесению новых ошибок, и системный тест окажется испорченным.

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

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

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