Инструментальные машины и служба данных

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

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

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

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

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

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

Библиотеки программ и учет. При создании OS/360 инструментальная машина очень успешно и с большой пользой применялась для ведения библиотек программ. Система, разработанная под руководством У. Р. Кт»ау-ли, состояла из двух сопряженных моделей IBM 7010, совместно использующих большой банк данных на дисках. Машины имели также ассемблер Системы 360. Все'; машинные программы, как исходные, так и оттранслированные модули загрузки, уже проверенные или проходящие проверку, хранились в этой библиотеке. Библиотека делилась на подбиблиотеки с различными правилами обращения к ним.

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

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

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

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

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

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

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

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

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

Во-вторых, подобное изобилие гораздо предпочтительнее, чем нехватка документации, характерная для большинства систем программирования. Я охотно соглашусь, однако, с тем, что некоторые места написаны не слишком хорошо и доработка может привести к уменьшению объема. Некоторые же части напя-саны очень хорошо, например, «Concepts and Facilities».

Модель производительности. Лучше иметь, чем не иметь. Делайте модель по методу «снаружи — внутрь» (подробно мы рассмотрим этот метод в следующей главе), Используйте тот же самый нисходящий подход приразработке модели производительности, логической модели и самого программного продукта. Начинайте де-лать\модель пораньше. Прислушайтесь к тому, что она будет вам говорить.

⇐ Предыдущая11121314151617181920Следующая ⇒

Поделиться: