Глава 6 Донести слово

Он сядет здесь и будет распоряжаться: «Сделайте это! Сделайте то!» А дело и с места не сдвинется.
ГАРРИ С. ТРУМЕН. «О ПРЕЗИДЕНТСКОЙ ВЛАСТИ»[1]

Как менеджеру, имея опытных дисциплинированных архитекторов и достаточное число исполнителей, добиться того, чтобы все услышали, поняли и выполнили решения архитектора? Как группе из 10 архитекторов поддерживать концептуальную целостность системы, над которой трудится 1000 человек? Для достижения этого при осуществлении программы проектирования аппаратной части System/360 была разработана целая технология, которая в равной степени применима для проектов создания программного обеспечения.

Письменные спецификации — руководство

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

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

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

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

Единство «Принципов работы System/360» проистекает из того, что у них было лишь два автора: Джерри Блау и Андрис Падега. Авторами идей являются порядка десяти человек, но если требуется соблюсти согласованность описания и продукта, отливку решений в прозаические спецификации должны осуществлять не более двух человек. Для написания определения требуется принять массу мини-решений, которые не столь важны, чтобы выносить их на всеобщее обсуждение. Для System/360 примером служат подробности того, как после каждой операции устанавливается код условия. Однако задача всеобщей согласованности таких мини-решений не является тривиальной.

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

Формальные определения

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

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

Древнее изречение предупреждает о том, что в море нельзя выходить с двумя хронометрами: нужно взять один или три. То же, очевидно, применимо и к текстовым и формальным определениям. Если имеются оба вида, то один должен быть стандартом, а другой — производным описанием, о чем должно быть прямо указано. Основным стандартом может быть любой из них. В Algol 68 в качестве стандарта выбрано формальное определение, а текстовые определения являются описательными. В PL/I стандартом является текст, а формальное определение — производным. В System/360 также в качестве стандарта принят текст, а производными являются формальные описания.

Есть много средств создания формальных определений. Для определения языков часто используется форма Бэкуса-Наура, по которой есть богатая литература.[3]В формальном описании PL/I используются новые обозначения абстрактного синтаксиса, надлежащим образом описанные.[3]APL Иверсона был использован для описания машин, в частности, IBM 7090[4]и System/360.[7]

Белл и Ньюэлл предложили новые нотации для описания как конфигураций, так и машин, и проиллюстрировали их на нескольких машинах, включая DEC PDP-8,[6]7090[6]и System/360.[7]

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

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

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

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

значительное количество недостатков. Реализация может переопределять даже внешние спецификации. Даже при ошибочном синтаксисе всегда получается некоторый результат; в контролируемой системе этот результат является указанием на ошибку и ничем больше. В неконтролируемой системе могут возникнуть любые побочные эффекты и быть использованы программистами. Когда мы, например, эмулировали IBM 1401 на System/360, выявилось 30 различных «курьезов» — побочных эффектов предположительно незаконных операций, которые широко использовались и должны были быть признаны частью определения. Реализация в качестве определения возобладала. Она не только говорила о том, что должна делать машина, но и многое сказала о том, как машина не должна была это делать.

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

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

Прямое включение

У архитекторов программных систем есть чудесный метод распространения и внедрения определений. Он особенно полезен при установлении если не семантики, то синтаксиса межмодульных интерфейсов. Этот прием состоит в создании объявлений передаваемых параметров или совместно используемой памяти и требовании включения этих объявлений при операциях времени компиляции (макрос или %INCLUDE в PL/I). Если, кроме того, все ссылки на интерфейс происходят только по символическим именам, объявления можно менять, добавляя или вставляя новые имена и лишь заново компилируя, но не изменяя использующую его программу.

Конференции и суды

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

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

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

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

Плодотворность этих совещаний обусловлена несколькими причинами:

1. Одна и та же группа – архитекторы, разработчики и исполнители – на протяжении месяцев встречаются между собой каждую неделю. Не требуется времени, чтобы ввести людей в курс дела.

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

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

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

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

Со временем выясняется, что некоторые решения не в полной мере выполняются. Тот или иной из участников так и не принял всей душой какую-либо мелочь. Другие решения породили непредвиденные проблемы, и еженедельное совещание отказывается повторно их рассматривать. Так возникает хвост из мелких возражений, открытых тем или раздражения. Для их урегулирования мы проводим ежегодные "сессии верховного суда", обычно продолжающиеся две недели. (Если бы я проводил их сейчас, то делал бы это раз в полгода.)

Эти сессии проводились накануне важных дат окончательного принятия разделов руководства. Присутствовали не только представители программистов и проектировщиков по архитектуре, но и менеджеры программных, маркетинговых и реализационных проектов. Председательствовал менеджер проекта System/360. Повестка работы включала обычно около 200 пунктов, в основном мелких, перечисленных в развешанных по комнате списках. Заслушивались все стороны и принимались решения. Благодаря чуду компьютерной верстки (и превосходной работе сотрудников) каждое утро каждый участник обнаруживал на своем рабочем месте исправленное руководство, в которое были внесены решения, принятые накануне.

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

Множественные реализации

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

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

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

Журнал регистрации телефонных разговоров

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

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

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

Тестирование продукта

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

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

Оглавление