Фредерик П. Брукс

Вид материалаДокументы
Рабочие машины и службы данных
Машины для компилятора и ассемблера.
Библиотеки программ и учет.
Программные инструменты.
Система документации.
Эмулятор производительности.
Подобный материал:
1   ...   20   21   22   23   24   25   26   27   ...   48

Рабочие машины и службы данных


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

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

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

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

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

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

Библиотеки программ и учет. Очень успешным и важным применением вспомогательной машины в программе разработки OS/360 была поддержка библиотек программ. Система, разработанная под руководством У. Р. Кроули (W.R. Crowley), состояла из двух соединенных вместе машин 7010 и общей дисковойбазой данных. На 7010 поддерживался также ассемблер для S/360. В этойбиблиотеке хранился весь протестированный или находящийся в процессетестирования код, как исходный, так и ассемблированные загрузочные модули.На практике библиотека была разбита на подбиблиотеки с различными правамидоступа.

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

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

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

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

По моему мнению, это было одним из лучших решений в программе OS/360.Эта часть технологии управления была независимо разработана для несколькихкрупных программных проектов, в том числе в Bell Labs, ICL и Кембриджскомуниверситете.2 Она применима как к программам, так и к документации. Это -неоценимая технология.

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

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

Система документации. Из всех инструментов больше всего труда можетсберечь компьютеризированная система редактирования текста, действующая нанадежной машине. Наша система, разработанная Дж. У. Франклином (J. W.Franklin), была очень удобна. Я думаю, без нее руководства по OS/360появились бы значительно позднее и оказались бы более запутанными. Естьлюди, которые станут утверждать, что двухметровая полка руководств по OS/360является следствием недержания речи, и сама ее объемистость являет собойновый тип непостижимости. И доля правды в этом есть.

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

Во-вторых, это гораздо лучше, чем крайняя недостаточность документации,характерная для большинства систем программирования. Я охотно соглашусь, темне менее, что в некоторых местах текст можно было значительно улучшить, ирезультатом лучшего описания стал бы меньший объем. Некоторые части(например, "Концепции и средства") сейчас очень хорошо написаны.

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