Глава 13 Целое и части

Глава 13 Целое и части

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

ШЕКСПИР, КОРОЛЬ ГЕНРИХ IV

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

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

Проектирование без ошибок

Защита определений от ошибок. Самые пагубные и неуловимые системные ошибки возникают из-за несоответствия допущений, сделанных авторами различных компонентов. Подход к концептуальной целостности, изложенных выше в главах 4, 5 и 6, непосредственно обращается к этим проблемам. Кратко говоря, концептуальная целостность продукта не только упрощает его использование, но также облегчает разработку и делает менее подверженным ошибкам.

Такую же роль выполняет детализированная трудоемкая работа по разработке архитектуры, подразумеваемая этим подходом. В. А. Высоцкий из проекта Safeguard, выполнявшегося в Bell Telephone Laboratories, говорит так: «Решающая задача — дать определение для продукта. Очень многие неудачи связаны именно с теми аспектами, которые не были вполне специфицированы». [1] Тщательное определение функций, тщательная спецификация и старательное избегание всех украшательств функций и полетов технической мысли — все это снижает количество системных ошибок, которые будут обнаружены.

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

Нисходящее проектирование. В очень четкой статье 1971 года Никлаус Вирт формализовал процедуру разработки, годами использовавшуюся лучшими программистами. [2] Более того, его замечания, сделанные в отношении разработки программ, полностью применимы к разработке сложных программных систем. Воплощением этих замечаний является разделение создания систем на проектирование архитектуры, разработку и реализацию. Более того, каждая из задач проектирования архитектуры, разработки и реализации лучше всего может быть решена нисходящими методами.

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

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

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

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

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

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

Структурное программирование. Другой важный круг идей для разработки, сокращающих число ошибок в программе, исходит то Дейкстры (Dijkstra) [3] и построен на теоретической структуре Бёма (Boehm) и Джакопини (Jacopini). [4]

В своей основе подход заключается в разработке программ, управляющие структуры которых состоят только из циклов, определяемых такими операторами, как DO WHILE и группами условно выполняемых операторов, ограниченных скобками с использованием операторов условия IF…THEN…ELSE. Бём и Джакопини показывают теоретическую достаточность таких структур. Дейкстра доказывает, что альтернативное неограниченное применение ветвление с помощью GO TO образует структуры, располагающие к появлению логических ошибок.

В основе, несомненно, лежат здравые мысли. При обсуждении сделано много критических замечаний — в частности, большое удобство представляют дополнительные управляющие структуры, такие как n-вариантный переход (так называемый оператор CASE) для различения среди нескольких случаев и аварийный выход (GO TO ABNORMAL END). Кроме того, некоторые догматически избегают всех GO TO , что представляется чрезмерным.

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

Отладка компонентов

За последние двадцать лет процедуры отладки программ прошли большой круг и в некоторых отношениях вернулись к начальной точке. Цикл прошел четыре этапа и любопытно проследить их, отметив мотивацию перехода.

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

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

Главным грехом было смело нажать кнопку START, не разбив предварительно программу на отлаживаемые секции с запланированными остановками.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предельный случай мини-файла — фиктивный файл, который фактически не существует. Язык управляющих заданий OS/360 имеет такое средство, и оно очень полезно для отладки компонентов.

Другой вид окружения — вспомогательные программы. Генераторы данных для тестирования, печать специального анализа, анализаторы таблиц перекрестных ссылок — все это примеры специальных приспособлений, которые может потребоваться создать. [13]

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

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

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

В технических моделях System/360 среди обычных желтых проводов можно было иногда видеть фиолетовые провода. При обнаружении дефекта делались две вещи. Быстро придумывалось исправление и устанавливалось в системе, чтобы продолжить отладку. Это изменение делалось фиолетовыми проводами, так что оно торчало как бельмо на глазу. Изменение регистрировалось в журнале. Тем временем готовился официальный документ о внесении исправлений, который запускался в жернова автоматизированного проектирования. В итоге это выливалось в измененные чертежи и списки проводов и новую заднюю панель, в которой изменения были сделаны на печатной плате или желтыми проводами. Теперь физическая модель и документация соответствовали друг другу, и фиолетовый провод исчезал.

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

Добавляйте компоненты по одному. Этот рецепт также очевиден, но им часто пренебрегают из-за оптимизма и лени. Чтобы следовать ему, требуются фиктивные программы и разное окружение, а это отнимает время. И в конце концов, вся эта работа может оказаться лишней! Может быть, ошибок и нет!

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

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

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

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

Леман и Белади дают свидетельства в пользу того, что квант изменений должен быть либо очень большим и редким, либо очень маленьким и частым. [14] Последняя стратегия, согласно их модели, больше подвержена неустойчивости. Мой опыт это подтверждает: я никогда не рискну использовать ее на практике.

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

Данный текст является ознакомительным фрагментом.