Страница:
заявками подрядчиков. Часто случается, что все предложения выходят за рамки
сметы. Тогда архитектор пересматривает свои оценки в сторону увеличения
сметы, а проект - в сторону сокращения, и цикл повторяется. Иногда он
предлагает подрядчикам способы удешевления реализации его проекта в
сравнении с избранными ими способами.
Сходные процессы происходят с архитектором компьютерных или программных
систем. Однако у него есть то преимущество, что предложения подрядчика можно
получить на ранних стадиях проектирования, часто - в любой момент.
Недостатком обычно является то, что работа идет с единственным подрядчиком,
который может менять цену в зависимости от степени своей удовлетворенности
проектом. На практике, процесс общения, начатый на ранних этапах и
продолжающийся непрерывно, может дать архитектору верную оценку стоимости, а
разработчику - уверенность в проекте, не снимая при этом четкого
разграничения сфер ответственности.
У архитектора, когда он сталкивается с неприемлемо высокой стоимостью,
есть два выхода: сократить проект или воздействовать на стоимость, предлагая
более дешевые способы реализации. Второй способ неизбежно вызывает эмоции,
ведь архитектор оспаривает то, как строитель справляется со своим делом.
Чтобы успешно справиться с этим, архитектору необходимо:
- помнить, что ответственность за изобретательность и творчество,
проявляемые при реализации, несет строитель, поэтому архитектор предлагает,
а не требует;
- всегда быть готовым предложить некоторый способ реализации своих
замыслов и быть готовым согласиться с любым другим способом, позволяющим
решить задачу не хуже;
- выдвигая такие предложения, действовать без шума и огласки;
- не рассчитывать на признательность за сделанные предложения.
Обычно разработчик парирует предложением изменений в архитектуре. Часто
он прав - реализация какой-нибудь малосущественной детали может оказаться
неожиданно дорогостоящей.
Самодисциплина - эффект второй системы
Первый проект архитектора стремится к скромности и ясности. Архитектор
понимает, что не знает, чем занимается, поэтому он занимается этим со
старанием и самоограничением.
При работе над первым проектом ему постоянно приходят в голову то одни,
то другие "украшения". Они откладываются в сторону для использования "в
следующий раз". В конце концов, первая система закончена, и архитектор, с
твердой уверенностью в себе и продемонстрированным освоением этого класса
систем, готов к созданию нового проекта.
Эта вторая система таит наибольшие опасности для проектировщика. При
работе над третьей и последующими системами закрепляется полученный ранее
опыт в отношении общих характеристик таких систем, а различия между ними
выявляют те части опыта, которые носят частный характер и не могут быть
обобщены.
Общая тенденция заключается в перегруженности проекта второй системы
идеями и украшательствами, благоразумно отложенными в сторону при работе над
первым проектом. В результате получается, говоря словами Овидия, "большая
куча". Рассмотрим, например, архитектуру IBM 709, воплощенную позднее в
машине 7090. Это - модернизация, вторя система для очень успешной и хорошо
скроенной системы 704. Набор команд был настолько богат и изобилен, что
регулярно использовалась примерно лишь половина его.
Рассмотрим в качестве более сильного примера архитектуру, разработку и
даже реализацию компьютера Stretch, которые дали выход сдерживающимся
изобретательским стремлениям многих людей, для большинства которых это было
вторая система. Вот что пишет в своем обзоре Стрейчи (Strachey):
У меня создалось впечатление, что некоторым образом Stretch являет
собой окончание определенного направления разработок. Как и некоторые ранние
компьютерные программы, эта система чрезвычайно изобретательна, чрезвычайно
сложна и очень эффективна, но в то же время является сырой, расточительной и
неизящной, оставляя ощущение, что эти вещи можно делать лучшим образом.1
Operating System/360 была второй системой для большинства своих
проектировщиков. Группы проектировщиков пришли после работы над дисковой
операционной системой 1410-7010, операционной системой Stretch, системой
реального времени Project Mercury и IBSYS для 7090. Едва ли кто-то из них
имел опыт работы над двумя предшествующими операционными системами. Поэтому
OS/360 является ярким примером эффекта второй системы, аналогом Stretch в
искусстве программирования, к которому в полной мере применимы и похвалы, и
упреки приведенной критики Стрейчи.
Например, в OS/360 отводится 26 байт для резидентной процедуры
преобразования даты, чтобы правильно обрабатывать 31 декабря в високосном
году (когда это 366-й день). Это можно было оставить оператору.
Эффект второй системы имеет и другое проявление, кроме простого
украшательства функциями. Это - склонность к усовершенствованию методов,
само существование которых стало анахронизмом благодаря изменениям в базовых
принципах системы. OS/360 содержит многочисленные примеры, подтверждающие
это.
Рассмотрим редактор связей, предназначенный для загрузки независимо
скомпилированных программ и разрешения их перекрестных ссылок. Помимо этой
основной функции он также управляет программными оверлеями. Это одно из
лучших когда-либо созданных средств работы с оверлеями. Оно позволяет
создавать оверлейную структуру внешним образом при редактировании связей, не
трогая исходного кода. Оно позволяет изменять структуру оверлеев без
перекомпиляции при каждом прогоне. Оно предоставляет богатый выбор полезных
опций и возможностей. В известном смысле, это завершающий итог многолетней
разработки технологии статических оверлеев.
И в то же время это последний и совершеннейший динозавр, поскольку
входит в систему, в которой многопрограммность является обычным режимом, а
динамическое распределение памяти - базовым принципом. Это вступает в прямой
конфликт с понятием использования статических оверлеев. Несколько лучше
работала бы система, если бы усилия, потраченные на управление оверлеями,
были перенаправлены на то, чтобы ускорить работу средств поддержки
динамического распределения памяти и перекрестных ссылок!
Более того, редактор связей требует так много памяти, и сам содержит
столько оверлеев, что даже при использовании только для редактирования без
управления оверлеями уступает в скорости большинству системных компиляторов.
Ирония состоит в том, что назначение редактора связей - избежать повторной
компиляции. Как у конькобежца корпус оказывается впереди ног, так и
усовершенствования продолжались, пока не вышли далеко за рамки системных
принципов.
Другим примером этой тенденции является отладчик TESTRAN. Это
совершенный пакетный отладчик, предоставляющий действительно элегантные
средства получения мгновенных снимков и дампов памяти. В нем используется
понятие управляющих разделов и искусная технология генерации, позволяющие
осуществлять избирательную трассировку и получение мгновенных снимков без
дополнительных расходов на интерпретацию или рекомпиляцию. Здесь пышным
цветом расцвели впечатляющие концепции операционной системы Share Operating
System3 для модели 709.
Между тем устарела сама идея пакетной отладки без рекомпиляции. Главный
вызов был брошен интерактивным вычислительным системам с интерпретаторами
языков программирования и пошаговыми компиляторами. Но даже в системах с
пакетной обработкой появление компиляторов с быстрой компиляцией и медленным
выполнением сделало более предпочтительной технологию отладки на уровне
исходного кода и получения мгновенных снимков. Насколько лучше оказалась бы
система, если бы силы, потраченные на проект TESTRAN, были перенаправлены на
ускоренное создание лучших средств для интерактивной работы и быстрой
компиляции!
Еще один пример - планировщик, предоставляющий действительно отличные
возможности для управления потоком фиксированных пакетов заданий. На
практике этот планировщик является усовершенствованной, улучшенной и
наделенной разными украшениями второй системой, которой предшествовала
дисковая операционная система 1410-7010 - система пакетной обработки, не
являющаяся многопрограммной, за исключением ввода-вывода, и предназначенной,
главным образом, для деловых приложений. В этом качестве планировщик OS/360
хорош. Но на него почти никакого влияния не оказали потребности OS/360 в
удаленном вводе заданий, многопрограммности и резидентном размещении
интерактивных подсистем. И действительно, проект планировщика затрудняет
решение этих задач.
Как архитектору избежать эффекта второй системы? Очевидно, пропустить
свою вторую систему он не может. Но он может отдавать себе отчет в особых
опасностях, которым она его подвергает, и проявить дополнительную
самодисциплину, чтобы избежать функционального украшательства и сохранения
функций, нужда в которых отпала ввиду изменений в принципах и целях.
Порядок, способный открыть архитектору глаза, заключается в том, чтобы
присвоить численное значение каждой, пусть малой, функции: характеристика x
должна обойтись не более чем в m байтов памяти и n микросекунд на один
вызов. Эти величины должны служить руководством при принятии начальных
решений, а также напоминанием и руководством при реализации.
Как менеджеру проекта избежать эффекта второй системы? Настаивать на
том, чтобы его старший архитектор имел опыт разработки хотя бы двух систем.
Кроме того, будучи осведомленным о возможных опасностях, он может
предъявлять необходимые требования для того, чтобы в детальном проекте нашли
полное отражение идеологических концепций и цели.
Он сядет здесь и будет распоряжаться: "Сделайте
это! Сделайте то!" А дело и с места не сдвинется.
ГАРРИ С. ТРУМЕН. "О ПРЕЗИДЕНТСКОЙ ВЛАСТИ"1
Как менеджеру, имея опытных дисциплинированных архитекторов и
достаточное число исполнителей, добиться того, чтобы все услышали, поняли и
выполнили решения архитектора? Как группе из 10 архитекторов поддерживать
концептуальную целостность системы, над которой трудится 1000 человек? Для
достижения этого при осуществлении программы проектирования аппаратной части
System/360 была разработана целая технология, которая в равной степени
применима для проектов создания программного обеспечения.
Письменные спецификации - руководство
Руководство, или письменная документация, является необходимым, хотя и
не достаточным, инструментом. Руководство является внешней спецификацией
продукта. В нем расписаны все подробности того, что видит пользователь, и
потому оно является главным продуктом, который создает архитектор.
Его подготовка идет кругами, собирая замечания пользователей и
разработчиков о недостатках проекта, затрудняющих использование или
реализацию. Для удобства разработчиков необходимо квантовать изменения:
согласно определенным в графике датам выпускать очередные версии.
Инструкция должна не только описывать все, что видит пользователь, в
том числе все интерфейсы, но и воздерживаться от описания того, чего
пользователь не видит. Последнее - забота разработчика, и здесь свобода его
решений не должна быть ограничена. Архитектор всегда должен быть готов
показать пример реализации любой описанной им функции, но он не должен
пытаться навязывать определенную реализацию.
Стиль должен быть точным, полным и очень подробным. Пользователь часто
обращается к отдельному определению, поэтому во всех из них должны быть
повторены все существенные элементы, и все они должны быть согласованы друг
с другом. По этой причине инструкции часто скучно читать, но точность имеет
приоритет перед увлекательностью.
Единство "Принципов работы System/360" проистекает из того, что у них
было лишь два автора: Джерри Блау и Андрис Падега. Авторами идей являются
порядка десяти человек, но если требуется соблюсти согласованность описания
и продукта, отливку решений в прозаические спецификации должны осуществлять
не более двух человек. Для написания определения требуется принять массу
мини-решений, которые не столь важны, чтобы выносить их на всеобщее
обсуждение. Для System/360 примером служат подробности того, как после
каждой операции устанавливается код условия. Однако задача всеобщей
согласованности таких мини- решений не является тривиальной.
Думаю, что лучший виденный мной образец руководства - это написанное
Блау приложение к "Принципам работы System/360". В нем тщательно и точно
описаны границы совместимости System/360. Дано определение совместимости,
предписывается, к чему нужно стремиться, и перечислены те области внешних
проявлений, где архитектура намеренно молчит, и где результаты, полученные
на разных моделях, могут отличаться между собой, где разные экземпляры одной
модели могут дать различные результаты и даже один и тот же экземпляр может
давать различия после конструктивных изменений. Это уровень точности, к
которому стремятся составители руководств. Они должны одинаково описывать
как то, что можно делать, так и то, что делать нельзя.
Формальные определения
Английский язык, как и любой другой естественный язык, по своей
природе не является точным инструментом, пригодным для таких описаний.
Поэтому составитель руководства должен держать в узде себя и свой язык,
чтобы достичь необходимой строгости. Привлекательна возможность
использования для таких определений формальных обозначений. В конце концов,
целью является точность, что обусловливает право формальных обозначений на
жизнь.
Рассмотрим достоинства и слабости формальных определений. Как
отмечалось, формальные определения являются точными. Они тяготеют к полноте:
пробелы заметнее, а потому скорее восстанавливаются. Их недостаток -
трудность понимания. На английском языке можно описать структурные принципы,
очертить структуры по этапам или по уровням и привести примеры. Легко
отметить исключения и подчеркнуть противоположности. Еще важнее, что можно
объяснить причины. Предлагавшиеся до сих пор формальные определения вызывали
восхищение своей элегантностью и уверенность в их точности. Но они требовали
текстуальных пояснений для облегчения изучения своего содержания. По этой
причине я полагаю, что в будущем спецификации будут состоять как из
формальных, так и из текстовых описаний.
Древнее изречение предупреждает о том, что в море нельзя выходить с
двумя хронометрами: нужно взять один или три. То же, очевидно, применимо и к
текстовым и формальным определениям. Если имеются оба вида, то один должен
быть стандартом, а другой - производным описанием, о чем должно быть прямо
указано. Основным стандартом может быть любой из них. В Algol 68 в качестве
стандарта выбрано формальное определение, а текстовые определения являются
описательными. В PL/I стандартом является текст, а формальное определение -
производным. В System/360 также в качестве стандарта принят текст, а
производными являются формальные описания.
Есть много средств создания формальных определений. Для определения
языков часто используется форма Бэкуса-Наура, по которой есть богатая
литература.2 В формальном описании PL/I используются новые обозначения
абстрактного синтаксиса, надлежащим образом описанные.3 APL Иверсона был
использован для описания машин, в частности, IBM 70904 и System/360.7 Белл и
Ньюэлл предложили новые нотации для описания как конфигураций, так и машин,
и проиллюстрировали их на нескольких машинах, включая DEC PDP-8,6 70906 и
System/360.7
Почти все формальные определения оказались пригодными для воплощения
или описания аппаратных средств или программных систем, внешние спецификации
которых они регламентируют. Синтаксис можно описать без этого, но семантика
обычно определяется с помощью программы, выполняющей определяемую операцию.
Конечно, это является реализацией и в этом качестве переопределяет
архитектуру. Поэтому нужно указать, что формальное определение относится
только к внешним спецификациям, и объяснить, что ими является.
Не только формальное определение является реализацией, но и реализация
может служить формальным определением. Когда были созданы первые совместимые
компьютеры, использовалась именно эта технология. Новая машина должна была
соответствовать имеющейся. Руководство туманно в некоторых местах? Задайте
вопрос машине! Создавалась тестовая программа для выяснения поведения, и
новая машина строилась так, чтобы достигалось соответствие.
Программная модель аппаратной или программной системы может
использоваться точно таким же образом. Это - реализация. Она работает.
Поэтому все вопросы, связанные с определением, могут быть решены путем
проверки.
Использование реализации в качестве определения имеет некоторые
преимущества. Все проблемы можно однозначно решить путем эксперимента.
Дискуссий не требуется, поэтому ответ получается быстро. Ответ может быть
сколь угодно точным и, по определению, всегда является правильным. С другой
стороны, есть значительное количество недостатков. Реализация может
переопределять даже внешние спецификации. Даже при ошибочном синтаксисе
всегда получается некоторый результат; в контролируемой системе этот
результат является указанием на ошибку и ничем больше. В неконтролируемой
системе могут возникнуть любые побочные эффекты и быть использованы
программистами. Когда мы, например, эмулировали IBM 1401 на System/360,
выявилось 30 различных "курьезов" - побочных эффектов предположительно
незаконных операций, которые широко использовались и должны были быть
признаны частью определения. Реализация в качестве определения возобладала.
Она не только говорила о том, что должна делать машина, но и многое сказала
о том, как машина не должна была это делать.
Кроме того, на проницательные вопросы реализация иногда дает
неожиданные ответы, и определение де-факто часто оказывается неизящным в
этих особых случаях потому, что над ними никогда не задумывались.
Копирование этой неэлегантности в другой реализации часто оказывается
замедляющим или дорогостоящим. Например, в некоторых машинах в регистре
множимого после умножения остается мусор. Точная природа этого мусора
становится частью определения де-факто, однако его копирование может
помешать использованию более быстрого алгоритма умножения.
Наконец, использование реализации в качестве формального определения
может создать неясность, какое из описаний - текстовое или формальное - в
действительности является стандартом. Это относится особенно к программным
моделям. Следует также воздерживаться от внесения изменений в реализацию,
пока она служит в качестве стандарта.
Прямое включение
У архитекторов программных систем есть чудесный метод распространения
и внедрения определений. Он особенно полезен при установлении если не
семантики, то синтаксиса межмодульных интерфейсов. Этот прием состоит в
создании объявлений передаваемых параметров или совместно используемой
памяти и требовании включения этих объявлений при операциях времени
компиляции (макрос или %INCLUDE в PL/I). Если, кроме того, все ссылки на
интерфейс происходят только по символическим именам, объявления можно
менять, добавляя или вставляя новые имена и лишь заново компилируя, но не
изменяя использующую его программу.
Конференции и суды
Нет нужды говорить о том, что совещания необходимы. Сотни частных
консультаций должны дополняться крупными и более формальными собраниями. Мы
признали полезными два уровня таких собраний. Первый - это еженедельная
конференция всех архитекторов вместе с официальными представителями
разработчиков аппаратной и программной части и сотрудниками маркетинга
продолжительностью в половину рабочего дня под председательством главного
архитектора системы.
Предлагать задачи и изменения можно всем, но обычно предложения
распространяются в письменном виде до совещания. Обычно новая задача
некоторое время обсуждается. Упор делается на творческой стороне, а не
просто на принятии решения. Группа пытается предложить несколько решений
проблемы, затем ряд предложенных решений передается одному или нескольким
архитекторам для разработки подробных и точно сформулированных предложений
по внесению изменений в руководство.
Подробные предложения об изменениях затем выносятся для принятия
решения. Предложения тщательно изучаются исполнителями и пользователями, и
выясняются все "за" и "против". Если возникает всеобщее согласие, все в
порядке. В противном случае решение принимает главный архитектор. Ведется
протокол, и решения формально, оперативно и широко распространяются.
Решения еженедельных конференций дают быстрые результаты и позволяют
продолжить работу. Если кто-то очень недоволен, допускается немедленная
апелляция к менеджеру проекта, но это происходит очень редко.
Плодотворность этих совещаний обусловлена несколькими причинами:
1. Одна и та же группа - архитекторы, разработчики и исполнители - на
протяжении месяцев встречаются между собой каждую неделю. Не требуется
времени, чтобы ввести людей в курс дела.
2. Группа состоит из предприимчивых, способных, хорошо осведомленных в
вопросах и глубоко заинтересованных в конечном результате людей. Никто не
участвует с "совещательным" голосом. Все уполномочены принимать на себя
обязательства.
3. При возникновении проблем решения ищутся как внутри, так и вне
очевидных границ.
4. Благодаря формализму письменных предложений сосредоточивается
внимание, требуется принятие решения и устраняется несогласованность,
свойственная черновым решениям комиссий.
5. Открытое предоставление права принятия решения главному архитектору
помогает избежать поиска компромиссов и задержек.
Со временем выясняется, что некоторые решения не в полной мере
выполняются. Тот или иной из участников так и не принял всей душой
какую-либо мелочь. Другие решения породили непредвиденные проблемы, и
еженедельное совещание отказывается повторно их рассматривать. Так возникает
хвост из мелких возражений, открытых тем или раздражения. Для их
урегулирования мы проводим ежегодные "сессии верховного суда", обычно
продолжающиеся две недели. (Если бы я проводил их сейчас, то делал бы это
раз в полгода.)
Эти сессии проводились накануне важных дат окончательного принятия
разделов руководства. Присутствовали не только представители программистов и
проектировщиков по архитектуре, но и менеджеры программных, маркетинговых и
реализационных проектов. Председательствовал менеджер проекта System/360.
Повестка работы включала обычно около 200 пунктов, в основном мелких,
перечисленных в развешанных по комнате списках. Заслушивались все стороны и
принимались решения. Благодаря чуду компьютерной верстки (и превосходной
работе сотрудников) каждое утро каждый участник обнаруживал на своем рабочем
месте исправленное руководство, в которое были внесены решения, принятые
накануне.
Эти "осенние фестивали" были полезны не только для пересмотра решений,
но и для того, чтобы они были приняты. Каждый был услышан, каждый принимал
участие, каждый лучше понимал сложные ограничения и взаимосвязи между
решениями.
Множественные реализации
У архитекторов System/360 было два почти беспрецедентных преимущества:
достаточно времени для тщательной работы и такое же политическое влияние,
как у проектировщиков. Наличие времени было обеспечено графиком по новой
технологии; политическое равенство происходило благодаря одновременному
созданию нескольких реализаций. Необходимость их строгой совместимости лучше
всего способствовала исполнению спецификаций.
В большинстве компьютерных проектов наступает день, когда оказывается,
что машина и руководство по ее использованию не согласуются. В последующем
конфликте обычно проигрывает руководство, поскольку его можно изменить
значительно быстрее и меньшей ценой, чем машину. Однако это не так, если
существует несколько реализаций. Тогда временные и финансовые издержки,
связанные с исправлением машины с ошибками, могут быть ниже, чем связанные с
переделкой машин, верно следовавших руководству.
Это замечание можно с пользой применить при определении языка
программирования. Можно с уверенностью утверждать, что рано или поздно
потребуется создать несколько интерпретаторов или компиляторов для разных
целей. Определение будет яснее, а дисциплина более крепкой, если изначально
строятся как минимум две реализации.
Журнал регистрации телефонных разговоров
Какими бы точными не были спецификации, по ходу проектирования
возникает несчетное множество вопросов касательно интерпретации архитектуры.
Очевидно, многие из этих вопросов требуют более ясного изложения в тексте.
Прочие просто отражают неправильное понимание.
Важно, чтобы озадаченные исполнители звонили ответственным архитекторам
и задавали вопросы, а не продолжали работу на основании догадок. Важно также
сметы. Тогда архитектор пересматривает свои оценки в сторону увеличения
сметы, а проект - в сторону сокращения, и цикл повторяется. Иногда он
предлагает подрядчикам способы удешевления реализации его проекта в
сравнении с избранными ими способами.
Сходные процессы происходят с архитектором компьютерных или программных
систем. Однако у него есть то преимущество, что предложения подрядчика можно
получить на ранних стадиях проектирования, часто - в любой момент.
Недостатком обычно является то, что работа идет с единственным подрядчиком,
который может менять цену в зависимости от степени своей удовлетворенности
проектом. На практике, процесс общения, начатый на ранних этапах и
продолжающийся непрерывно, может дать архитектору верную оценку стоимости, а
разработчику - уверенность в проекте, не снимая при этом четкого
разграничения сфер ответственности.
У архитектора, когда он сталкивается с неприемлемо высокой стоимостью,
есть два выхода: сократить проект или воздействовать на стоимость, предлагая
более дешевые способы реализации. Второй способ неизбежно вызывает эмоции,
ведь архитектор оспаривает то, как строитель справляется со своим делом.
Чтобы успешно справиться с этим, архитектору необходимо:
- помнить, что ответственность за изобретательность и творчество,
проявляемые при реализации, несет строитель, поэтому архитектор предлагает,
а не требует;
- всегда быть готовым предложить некоторый способ реализации своих
замыслов и быть готовым согласиться с любым другим способом, позволяющим
решить задачу не хуже;
- выдвигая такие предложения, действовать без шума и огласки;
- не рассчитывать на признательность за сделанные предложения.
Обычно разработчик парирует предложением изменений в архитектуре. Часто
он прав - реализация какой-нибудь малосущественной детали может оказаться
неожиданно дорогостоящей.
Самодисциплина - эффект второй системы
Первый проект архитектора стремится к скромности и ясности. Архитектор
понимает, что не знает, чем занимается, поэтому он занимается этим со
старанием и самоограничением.
При работе над первым проектом ему постоянно приходят в голову то одни,
то другие "украшения". Они откладываются в сторону для использования "в
следующий раз". В конце концов, первая система закончена, и архитектор, с
твердой уверенностью в себе и продемонстрированным освоением этого класса
систем, готов к созданию нового проекта.
Эта вторая система таит наибольшие опасности для проектировщика. При
работе над третьей и последующими системами закрепляется полученный ранее
опыт в отношении общих характеристик таких систем, а различия между ними
выявляют те части опыта, которые носят частный характер и не могут быть
обобщены.
Общая тенденция заключается в перегруженности проекта второй системы
идеями и украшательствами, благоразумно отложенными в сторону при работе над
первым проектом. В результате получается, говоря словами Овидия, "большая
куча". Рассмотрим, например, архитектуру IBM 709, воплощенную позднее в
машине 7090. Это - модернизация, вторя система для очень успешной и хорошо
скроенной системы 704. Набор команд был настолько богат и изобилен, что
регулярно использовалась примерно лишь половина его.
Рассмотрим в качестве более сильного примера архитектуру, разработку и
даже реализацию компьютера Stretch, которые дали выход сдерживающимся
изобретательским стремлениям многих людей, для большинства которых это было
вторая система. Вот что пишет в своем обзоре Стрейчи (Strachey):
У меня создалось впечатление, что некоторым образом Stretch являет
собой окончание определенного направления разработок. Как и некоторые ранние
компьютерные программы, эта система чрезвычайно изобретательна, чрезвычайно
сложна и очень эффективна, но в то же время является сырой, расточительной и
неизящной, оставляя ощущение, что эти вещи можно делать лучшим образом.1
Operating System/360 была второй системой для большинства своих
проектировщиков. Группы проектировщиков пришли после работы над дисковой
операционной системой 1410-7010, операционной системой Stretch, системой
реального времени Project Mercury и IBSYS для 7090. Едва ли кто-то из них
имел опыт работы над двумя предшествующими операционными системами. Поэтому
OS/360 является ярким примером эффекта второй системы, аналогом Stretch в
искусстве программирования, к которому в полной мере применимы и похвалы, и
упреки приведенной критики Стрейчи.
Например, в OS/360 отводится 26 байт для резидентной процедуры
преобразования даты, чтобы правильно обрабатывать 31 декабря в високосном
году (когда это 366-й день). Это можно было оставить оператору.
Эффект второй системы имеет и другое проявление, кроме простого
украшательства функциями. Это - склонность к усовершенствованию методов,
само существование которых стало анахронизмом благодаря изменениям в базовых
принципах системы. OS/360 содержит многочисленные примеры, подтверждающие
это.
Рассмотрим редактор связей, предназначенный для загрузки независимо
скомпилированных программ и разрешения их перекрестных ссылок. Помимо этой
основной функции он также управляет программными оверлеями. Это одно из
лучших когда-либо созданных средств работы с оверлеями. Оно позволяет
создавать оверлейную структуру внешним образом при редактировании связей, не
трогая исходного кода. Оно позволяет изменять структуру оверлеев без
перекомпиляции при каждом прогоне. Оно предоставляет богатый выбор полезных
опций и возможностей. В известном смысле, это завершающий итог многолетней
разработки технологии статических оверлеев.
И в то же время это последний и совершеннейший динозавр, поскольку
входит в систему, в которой многопрограммность является обычным режимом, а
динамическое распределение памяти - базовым принципом. Это вступает в прямой
конфликт с понятием использования статических оверлеев. Несколько лучше
работала бы система, если бы усилия, потраченные на управление оверлеями,
были перенаправлены на то, чтобы ускорить работу средств поддержки
динамического распределения памяти и перекрестных ссылок!
Более того, редактор связей требует так много памяти, и сам содержит
столько оверлеев, что даже при использовании только для редактирования без
управления оверлеями уступает в скорости большинству системных компиляторов.
Ирония состоит в том, что назначение редактора связей - избежать повторной
компиляции. Как у конькобежца корпус оказывается впереди ног, так и
усовершенствования продолжались, пока не вышли далеко за рамки системных
принципов.
Другим примером этой тенденции является отладчик TESTRAN. Это
совершенный пакетный отладчик, предоставляющий действительно элегантные
средства получения мгновенных снимков и дампов памяти. В нем используется
понятие управляющих разделов и искусная технология генерации, позволяющие
осуществлять избирательную трассировку и получение мгновенных снимков без
дополнительных расходов на интерпретацию или рекомпиляцию. Здесь пышным
цветом расцвели впечатляющие концепции операционной системы Share Operating
System3 для модели 709.
Между тем устарела сама идея пакетной отладки без рекомпиляции. Главный
вызов был брошен интерактивным вычислительным системам с интерпретаторами
языков программирования и пошаговыми компиляторами. Но даже в системах с
пакетной обработкой появление компиляторов с быстрой компиляцией и медленным
выполнением сделало более предпочтительной технологию отладки на уровне
исходного кода и получения мгновенных снимков. Насколько лучше оказалась бы
система, если бы силы, потраченные на проект TESTRAN, были перенаправлены на
ускоренное создание лучших средств для интерактивной работы и быстрой
компиляции!
Еще один пример - планировщик, предоставляющий действительно отличные
возможности для управления потоком фиксированных пакетов заданий. На
практике этот планировщик является усовершенствованной, улучшенной и
наделенной разными украшениями второй системой, которой предшествовала
дисковая операционная система 1410-7010 - система пакетной обработки, не
являющаяся многопрограммной, за исключением ввода-вывода, и предназначенной,
главным образом, для деловых приложений. В этом качестве планировщик OS/360
хорош. Но на него почти никакого влияния не оказали потребности OS/360 в
удаленном вводе заданий, многопрограммности и резидентном размещении
интерактивных подсистем. И действительно, проект планировщика затрудняет
решение этих задач.
Как архитектору избежать эффекта второй системы? Очевидно, пропустить
свою вторую систему он не может. Но он может отдавать себе отчет в особых
опасностях, которым она его подвергает, и проявить дополнительную
самодисциплину, чтобы избежать функционального украшательства и сохранения
функций, нужда в которых отпала ввиду изменений в принципах и целях.
Порядок, способный открыть архитектору глаза, заключается в том, чтобы
присвоить численное значение каждой, пусть малой, функции: характеристика x
должна обойтись не более чем в m байтов памяти и n микросекунд на один
вызов. Эти величины должны служить руководством при принятии начальных
решений, а также напоминанием и руководством при реализации.
Как менеджеру проекта избежать эффекта второй системы? Настаивать на
том, чтобы его старший архитектор имел опыт разработки хотя бы двух систем.
Кроме того, будучи осведомленным о возможных опасностях, он может
предъявлять необходимые требования для того, чтобы в детальном проекте нашли
полное отражение идеологических концепций и цели.
Он сядет здесь и будет распоряжаться: "Сделайте
это! Сделайте то!" А дело и с места не сдвинется.
ГАРРИ С. ТРУМЕН. "О ПРЕЗИДЕНТСКОЙ ВЛАСТИ"1
Как менеджеру, имея опытных дисциплинированных архитекторов и
достаточное число исполнителей, добиться того, чтобы все услышали, поняли и
выполнили решения архитектора? Как группе из 10 архитекторов поддерживать
концептуальную целостность системы, над которой трудится 1000 человек? Для
достижения этого при осуществлении программы проектирования аппаратной части
System/360 была разработана целая технология, которая в равной степени
применима для проектов создания программного обеспечения.
Письменные спецификации - руководство
Руководство, или письменная документация, является необходимым, хотя и
не достаточным, инструментом. Руководство является внешней спецификацией
продукта. В нем расписаны все подробности того, что видит пользователь, и
потому оно является главным продуктом, который создает архитектор.
Его подготовка идет кругами, собирая замечания пользователей и
разработчиков о недостатках проекта, затрудняющих использование или
реализацию. Для удобства разработчиков необходимо квантовать изменения:
согласно определенным в графике датам выпускать очередные версии.
Инструкция должна не только описывать все, что видит пользователь, в
том числе все интерфейсы, но и воздерживаться от описания того, чего
пользователь не видит. Последнее - забота разработчика, и здесь свобода его
решений не должна быть ограничена. Архитектор всегда должен быть готов
показать пример реализации любой описанной им функции, но он не должен
пытаться навязывать определенную реализацию.
Стиль должен быть точным, полным и очень подробным. Пользователь часто
обращается к отдельному определению, поэтому во всех из них должны быть
повторены все существенные элементы, и все они должны быть согласованы друг
с другом. По этой причине инструкции часто скучно читать, но точность имеет
приоритет перед увлекательностью.
Единство "Принципов работы System/360" проистекает из того, что у них
было лишь два автора: Джерри Блау и Андрис Падега. Авторами идей являются
порядка десяти человек, но если требуется соблюсти согласованность описания
и продукта, отливку решений в прозаические спецификации должны осуществлять
не более двух человек. Для написания определения требуется принять массу
мини-решений, которые не столь важны, чтобы выносить их на всеобщее
обсуждение. Для System/360 примером служат подробности того, как после
каждой операции устанавливается код условия. Однако задача всеобщей
согласованности таких мини- решений не является тривиальной.
Думаю, что лучший виденный мной образец руководства - это написанное
Блау приложение к "Принципам работы System/360". В нем тщательно и точно
описаны границы совместимости System/360. Дано определение совместимости,
предписывается, к чему нужно стремиться, и перечислены те области внешних
проявлений, где архитектура намеренно молчит, и где результаты, полученные
на разных моделях, могут отличаться между собой, где разные экземпляры одной
модели могут дать различные результаты и даже один и тот же экземпляр может
давать различия после конструктивных изменений. Это уровень точности, к
которому стремятся составители руководств. Они должны одинаково описывать
как то, что можно делать, так и то, что делать нельзя.
Формальные определения
Английский язык, как и любой другой естественный язык, по своей
природе не является точным инструментом, пригодным для таких описаний.
Поэтому составитель руководства должен держать в узде себя и свой язык,
чтобы достичь необходимой строгости. Привлекательна возможность
использования для таких определений формальных обозначений. В конце концов,
целью является точность, что обусловливает право формальных обозначений на
жизнь.
Рассмотрим достоинства и слабости формальных определений. Как
отмечалось, формальные определения являются точными. Они тяготеют к полноте:
пробелы заметнее, а потому скорее восстанавливаются. Их недостаток -
трудность понимания. На английском языке можно описать структурные принципы,
очертить структуры по этапам или по уровням и привести примеры. Легко
отметить исключения и подчеркнуть противоположности. Еще важнее, что можно
объяснить причины. Предлагавшиеся до сих пор формальные определения вызывали
восхищение своей элегантностью и уверенность в их точности. Но они требовали
текстуальных пояснений для облегчения изучения своего содержания. По этой
причине я полагаю, что в будущем спецификации будут состоять как из
формальных, так и из текстовых описаний.
Древнее изречение предупреждает о том, что в море нельзя выходить с
двумя хронометрами: нужно взять один или три. То же, очевидно, применимо и к
текстовым и формальным определениям. Если имеются оба вида, то один должен
быть стандартом, а другой - производным описанием, о чем должно быть прямо
указано. Основным стандартом может быть любой из них. В Algol 68 в качестве
стандарта выбрано формальное определение, а текстовые определения являются
описательными. В PL/I стандартом является текст, а формальное определение -
производным. В System/360 также в качестве стандарта принят текст, а
производными являются формальные описания.
Есть много средств создания формальных определений. Для определения
языков часто используется форма Бэкуса-Наура, по которой есть богатая
литература.2 В формальном описании PL/I используются новые обозначения
абстрактного синтаксиса, надлежащим образом описанные.3 APL Иверсона был
использован для описания машин, в частности, IBM 70904 и System/360.7 Белл и
Ньюэлл предложили новые нотации для описания как конфигураций, так и машин,
и проиллюстрировали их на нескольких машинах, включая DEC PDP-8,6 70906 и
System/360.7
Почти все формальные определения оказались пригодными для воплощения
или описания аппаратных средств или программных систем, внешние спецификации
которых они регламентируют. Синтаксис можно описать без этого, но семантика
обычно определяется с помощью программы, выполняющей определяемую операцию.
Конечно, это является реализацией и в этом качестве переопределяет
архитектуру. Поэтому нужно указать, что формальное определение относится
только к внешним спецификациям, и объяснить, что ими является.
Не только формальное определение является реализацией, но и реализация
может служить формальным определением. Когда были созданы первые совместимые
компьютеры, использовалась именно эта технология. Новая машина должна была
соответствовать имеющейся. Руководство туманно в некоторых местах? Задайте
вопрос машине! Создавалась тестовая программа для выяснения поведения, и
новая машина строилась так, чтобы достигалось соответствие.
Программная модель аппаратной или программной системы может
использоваться точно таким же образом. Это - реализация. Она работает.
Поэтому все вопросы, связанные с определением, могут быть решены путем
проверки.
Использование реализации в качестве определения имеет некоторые
преимущества. Все проблемы можно однозначно решить путем эксперимента.
Дискуссий не требуется, поэтому ответ получается быстро. Ответ может быть
сколь угодно точным и, по определению, всегда является правильным. С другой
стороны, есть значительное количество недостатков. Реализация может
переопределять даже внешние спецификации. Даже при ошибочном синтаксисе
всегда получается некоторый результат; в контролируемой системе этот
результат является указанием на ошибку и ничем больше. В неконтролируемой
системе могут возникнуть любые побочные эффекты и быть использованы
программистами. Когда мы, например, эмулировали IBM 1401 на System/360,
выявилось 30 различных "курьезов" - побочных эффектов предположительно
незаконных операций, которые широко использовались и должны были быть
признаны частью определения. Реализация в качестве определения возобладала.
Она не только говорила о том, что должна делать машина, но и многое сказала
о том, как машина не должна была это делать.
Кроме того, на проницательные вопросы реализация иногда дает
неожиданные ответы, и определение де-факто часто оказывается неизящным в
этих особых случаях потому, что над ними никогда не задумывались.
Копирование этой неэлегантности в другой реализации часто оказывается
замедляющим или дорогостоящим. Например, в некоторых машинах в регистре
множимого после умножения остается мусор. Точная природа этого мусора
становится частью определения де-факто, однако его копирование может
помешать использованию более быстрого алгоритма умножения.
Наконец, использование реализации в качестве формального определения
может создать неясность, какое из описаний - текстовое или формальное - в
действительности является стандартом. Это относится особенно к программным
моделям. Следует также воздерживаться от внесения изменений в реализацию,
пока она служит в качестве стандарта.
Прямое включение
У архитекторов программных систем есть чудесный метод распространения
и внедрения определений. Он особенно полезен при установлении если не
семантики, то синтаксиса межмодульных интерфейсов. Этот прием состоит в
создании объявлений передаваемых параметров или совместно используемой
памяти и требовании включения этих объявлений при операциях времени
компиляции (макрос или %INCLUDE в PL/I). Если, кроме того, все ссылки на
интерфейс происходят только по символическим именам, объявления можно
менять, добавляя или вставляя новые имена и лишь заново компилируя, но не
изменяя использующую его программу.
Конференции и суды
Нет нужды говорить о том, что совещания необходимы. Сотни частных
консультаций должны дополняться крупными и более формальными собраниями. Мы
признали полезными два уровня таких собраний. Первый - это еженедельная
конференция всех архитекторов вместе с официальными представителями
разработчиков аппаратной и программной части и сотрудниками маркетинга
продолжительностью в половину рабочего дня под председательством главного
архитектора системы.
Предлагать задачи и изменения можно всем, но обычно предложения
распространяются в письменном виде до совещания. Обычно новая задача
некоторое время обсуждается. Упор делается на творческой стороне, а не
просто на принятии решения. Группа пытается предложить несколько решений
проблемы, затем ряд предложенных решений передается одному или нескольким
архитекторам для разработки подробных и точно сформулированных предложений
по внесению изменений в руководство.
Подробные предложения об изменениях затем выносятся для принятия
решения. Предложения тщательно изучаются исполнителями и пользователями, и
выясняются все "за" и "против". Если возникает всеобщее согласие, все в
порядке. В противном случае решение принимает главный архитектор. Ведется
протокол, и решения формально, оперативно и широко распространяются.
Решения еженедельных конференций дают быстрые результаты и позволяют
продолжить работу. Если кто-то очень недоволен, допускается немедленная
апелляция к менеджеру проекта, но это происходит очень редко.
Плодотворность этих совещаний обусловлена несколькими причинами:
1. Одна и та же группа - архитекторы, разработчики и исполнители - на
протяжении месяцев встречаются между собой каждую неделю. Не требуется
времени, чтобы ввести людей в курс дела.
2. Группа состоит из предприимчивых, способных, хорошо осведомленных в
вопросах и глубоко заинтересованных в конечном результате людей. Никто не
участвует с "совещательным" голосом. Все уполномочены принимать на себя
обязательства.
3. При возникновении проблем решения ищутся как внутри, так и вне
очевидных границ.
4. Благодаря формализму письменных предложений сосредоточивается
внимание, требуется принятие решения и устраняется несогласованность,
свойственная черновым решениям комиссий.
5. Открытое предоставление права принятия решения главному архитектору
помогает избежать поиска компромиссов и задержек.
Со временем выясняется, что некоторые решения не в полной мере
выполняются. Тот или иной из участников так и не принял всей душой
какую-либо мелочь. Другие решения породили непредвиденные проблемы, и
еженедельное совещание отказывается повторно их рассматривать. Так возникает
хвост из мелких возражений, открытых тем или раздражения. Для их
урегулирования мы проводим ежегодные "сессии верховного суда", обычно
продолжающиеся две недели. (Если бы я проводил их сейчас, то делал бы это
раз в полгода.)
Эти сессии проводились накануне важных дат окончательного принятия
разделов руководства. Присутствовали не только представители программистов и
проектировщиков по архитектуре, но и менеджеры программных, маркетинговых и
реализационных проектов. Председательствовал менеджер проекта System/360.
Повестка работы включала обычно около 200 пунктов, в основном мелких,
перечисленных в развешанных по комнате списках. Заслушивались все стороны и
принимались решения. Благодаря чуду компьютерной верстки (и превосходной
работе сотрудников) каждое утро каждый участник обнаруживал на своем рабочем
месте исправленное руководство, в которое были внесены решения, принятые
накануне.
Эти "осенние фестивали" были полезны не только для пересмотра решений,
но и для того, чтобы они были приняты. Каждый был услышан, каждый принимал
участие, каждый лучше понимал сложные ограничения и взаимосвязи между
решениями.
Множественные реализации
У архитекторов System/360 было два почти беспрецедентных преимущества:
достаточно времени для тщательной работы и такое же политическое влияние,
как у проектировщиков. Наличие времени было обеспечено графиком по новой
технологии; политическое равенство происходило благодаря одновременному
созданию нескольких реализаций. Необходимость их строгой совместимости лучше
всего способствовала исполнению спецификаций.
В большинстве компьютерных проектов наступает день, когда оказывается,
что машина и руководство по ее использованию не согласуются. В последующем
конфликте обычно проигрывает руководство, поскольку его можно изменить
значительно быстрее и меньшей ценой, чем машину. Однако это не так, если
существует несколько реализаций. Тогда временные и финансовые издержки,
связанные с исправлением машины с ошибками, могут быть ниже, чем связанные с
переделкой машин, верно следовавших руководству.
Это замечание можно с пользой применить при определении языка
программирования. Можно с уверенностью утверждать, что рано или поздно
потребуется создать несколько интерпретаторов или компиляторов для разных
целей. Определение будет яснее, а дисциплина более крепкой, если изначально
строятся как минимум две реализации.
Журнал регистрации телефонных разговоров
Какими бы точными не были спецификации, по ходу проектирования
возникает несчетное множество вопросов касательно интерпретации архитектуры.
Очевидно, многие из этих вопросов требуют более ясного изложения в тексте.
Прочие просто отражают неправильное понимание.
Важно, чтобы озадаченные исполнители звонили ответственным архитекторам
и задавали вопросы, а не продолжали работу на основании догадок. Важно также