Страница:
Изложение должно быть точным, полным и очень подробным. Часто пользователь будет обращаться только к одному определению, поэтому каждое из них должно повторять вс0 основные моменты, и все они должны быть согласованы между собой. Это превращает чтение/ руководства в весьма скучное занятие, но здесь^ точность важнее, чем живость изложения.
Единство "Принципов действия Системы 360" обусловлено тем, что они вышли из-под пера только двух авторов - Джерри Блау и Андриса Падегза. Идеи, в них изложенные, принадлежали примерно десятку людей, но для того, чтобы сохранить соответствие между продуктом и его описанием, превращать эти идеи в текстовые спецификации должны были один или два человека. Чтобы дать какое-нибудь определение, необходимо принять целый ряд мини-решений, которые не требуют подробного обсуждения. Примером такого рода в Системе 360 могут служить детали установления "кода условия" после каждой операции. Нетривиальным, однако, является принцип, согласно которому такие мини-решения должны быть полностью непротиворечивы.
Приложение к "Принципам действия Системы 3GO", написанное Джерри Блау, я считаю лучшим из всех когда-либо виденных мною руководств. В этом приложении очень точно и тщательно описываются пределы совместимости Системы 360, указывается, к чему следует стремиться, и перечисляются те области внешнего окружения, где архитектура умышленно хранит молчание и где результаты, полученные на разных моделях, могут отличаться друг от друга, где один экземпляр данной модели может отличаться от другого или где, наконец, система может отличаться от себя самой после каких-то технологических изменений. Авторы руководств должны стремиться именно к такому уровню точности, они обязаны определять то, чего нельзя делать, столь же тщательно, как и то, что можно.
Формальные описания
Английский язык, как и все другие естественные языки, нельзя считать идеальным средством для таких описаний. Поэтому Создатель руководства сам должен накладывать строгие ограничения на язык с тем, чтобы достичь необходимой точности. Использование формальной системы обозначений представляется очень привлекательным выходом из этого затруднения. В конце концов точность - это основа, смысл существования формальной системы обозначений.
Давайте рассмотрим сильные и слабые стороны формальных описаний. Как уже отмечалось, формальные описания точны. Они стремятся быть максимально полными; пробелы более заметны, а потому скорее заполняются. Зато они непонятны. Когда речь идет об английской прозе, всегда можно назвать принципы ее организации, указать структуру на различных эта-. пах или уровнях и привести примеры. Несложно перечислить исключения и выявить противоречия. И что важнее всего, можно объяснить, почему это так, а не иначе. Достаточно разработанные формальные описания вызывают изумление своей элегантностью и доверие - своей точностью. Но для того, чтобы их содержание можно было легко уяснить самому и объяснить другим, необходимы пояснения. По этим причинам я считаю, что будущие спецификации должны состоять как из формальных, так и текстовых описаний.
Старая пословица предупреждает: "Никогда не выходи в море с двумя хронометрами: бери один или три". Ее вполне можно отнести и к проблеме текстовых и формальных описаний. Если у вас есть и то, и другое, то одно должно быть стандартом, а второе - производным описанием, что следует указать ясно. В качестве исходного стандарта можно выбрать любое из них. Алгол-68 имеет в качестве стандарта формальное описание и, кроме того, поясняющее текстовое описание. Стандартное описание PL/I дано текстом, а формальное описание - как производное. Система 360 также имеет текстовое описание в качестве стандарта и рядом - производное формальное описание.
Существует множество способов представления формальных описаний. Бэкусова - Наурова форма (БНФ), разработанная для описания языков, широко освещена в литературе2). Формальное описание PL/I использует новую систему обозначении абстрактного синтаксиса, и она адекватно описана3). Язык APL, разработанный Айверсоном, применялся для описания машин, в частности, IBM-70904) и Системы 3605).
Белл и Ныоэлл предложили новую систему для описания конфигураций и архитектуры машин и проиллюстрировали ее на примере нескольких машин, включая PDP-8 фирмы DEC6), IBM-70906) и Системы 3607).
Почти псе формальные описания воплощают реализацию аппаратуры или системы программного обеспечения, внешние спецификации которой они определяют. Синтаксис можно описать и без этого, но семантику обычно описывают с помощью программы, которая выполняет определяемую операцию. Это, конечно, реализация, и как таковая она диктует архитектурные решения. Необходимо указать, что формальное описание приложимо только к внешним спецификациям, и следует сказать, что они собой представляют.
Не только формальное описание является реализацией, но и реализация может служить формальным описанием. Именно этот принцип использовался при создании первых совместимых ЭВМ. Новая машина должна соответствовать старой. Какие-то места в руководстве непонятны? "Спросите машину!". Нужно было разработать тестовую программу, определяющую поведение старой машины, и добиться того, чтобы новая машина проходила через этот тест.
Программы-имитаторы аппаратуры или математического обеспечения могут использоваться точно таким же образом. Это реализация; она работает. Поэтому все вопросы описания можно разрешить путем ее проверки.
Использование реализации в качестве описания имеет некоторые преимущества. Все вопросы разрешаются однозначно посредством эксперимента. Дискуссии не нужны, потому что ответы получаются быстро. Ответы всегда точны в той степени, которая нужна, ц они по определению верны. Но, кроме преимуществ, такой подход имеет и очень много недостатков. Реализация может вызвать переопределение даже внешних спецификаций. Ошибка в синтаксисе в реализации приводит к любому результату; в "чистой" системе этот результат является лишь указанием на некорректность и ничем больше. В "неряшливой" системе могут появиться самые разнообразные побочные эффекты, которые могут быть использованы программистами. Когда мы предприняли эмуляцию ЭВМ IBM-1401 на Системе 360, то обнаружилось около 30 различных "курьезов", или побочных эффектов, вызываемых, предположительно, ошибочными операциями, которые, однако, стали широко использоваться и должны теперь рассматриваться как часть описания. Реализация, выступающая в качестве описания, предлагает избыточные определения; она говорит не только о том, что машина должна делать, но, в значительной степени, и о том, как она это должна делать.
Кроме того, реализация будет иногда давать неожиданные и незапланированные ответы на трудные вопросы, это описание de facto оказывается неэлегантным в таких конкретных местах как раз потому, что они в свое время не были продуманы. Их воспроизведение в другой реализации может дорого обойтись. Например, некоторые машины не полностью очищают регистр множимого после умножения. Явление это по своей природе - часть фактического описания, однако его воспроизведение может помешать использованию более быстрого алгоритма умножения.
Наконец, использование реализации в качестве формального описания таит в себе опасную возможность перепутать, что именно является стандартом:
текстовое описание или формальное. Это особенно справедливо в отношении программных имитаторов;
Кроме того, нельзя вносить модификации в реализацию, пока она служит стандартом.
Прямое внесение
В распоряжении архитектора систем математического обеспечения есть превосходный метод распространения и внесения определений. Он особенно полезен для установления, если не семантики, то синтаксиса межмодульных сопряжении. Заключается этот метод в задании описания передаваемых параметров или совместно используемой памяти, и в требований, чтобы реализация включала данное описание через операции периода компиляции (макрокоманды или % INCLUDE в PL/I). Кроме того, если обращение ко всему сопряжению осуществляется только по символическим именам, то описание можно изменить путем добавления или введения новых переменных только ретрансляцией используемой программы без ее изменения.
Конференции и разбирательства
Нет никакой нужды говорить о том, что совещания необходимы. Кроме сотен частных консультаций, необходимы более формальные встречи. Мы считаем, что полезно их проводить на двух уровнях.
Первый- это еженедельные совещания всех архитекторов и официальных представителей разработчиков аппаратуры и математического обеспечения. Председательствует на них главный архитектор системы.
Каждый может вынести на обсуждение какую-нибудь проблему или предложить изменения, но обычно все предложения распространяются в письменной форме перед совещанием. Новая проблема, как правило, какое-то время обсуждается. Причем основное внимание уделяется не принятию решений как таковых, а процессу творческого поиска. Вся группа пытается найти возможные решения проблемы, затем некоторые из этих решений передаются одному или нескольким архитекторам, которые превращают их в строго сформулированные предложения, обосновывающие изменения в документах.
Далее начинается процесс принятия решений. Предложения внимательно изучаются разработчиками и пользователями, тщательно взвешиваются все "за" и "против". Если согласие достигнуто - отлично. В противном случае решение принимает главный архитектор. Время не тратится впустую, и решения быстро и широко распространяются.
Решения, принимаемые на еженедельных совещаниях, дают быстрый результат и не тормозят работу. Если кто-либо ими совершенно неудовлетворен, он может нeмeд^eннo апеллировать к руководителю проекта, но такое случается крайне редко.
Подобные совещания очень плодотворны по нескольким причинам:
1. Одна и та же группа архитекторов, пользователей и разработчиков встречается еженедельно в течение месяцев. Не нужно тратить время на то, чтобы ввести людей в курс дела.
2. Группа состоит из людей способных, изобретательных, хорошо разбирающихся в проблеме и глубоко заинтересованных в результатах. Ни один из них не выступает в роли "советчика". Каждый уполномочен принимать на себя обязательства.
3. Когда возникают проблемы, поиск их решения осуществляется как внутри очевидных границ, так и за их пределами.
4. Формализм письменных предложений позволяет сосредоточить внимание, стимулировать их решение и набежать противоречий.
5. Законодательная власть главного архитектора позволяет избежать компромиссов и задержек.
По прошествии времени некоторые решения устаревают. Отдельные частные способы решения не удовлетворяют того или иного участника. Другие решения вызывают непредвиденные затруднения, и иногда еженедельные совещания не в состоянии их разрешить. Так накапливается груз мелких жалоб, открытых вопросов пли недовольства. Для того, чтобы справиться со всем этим, мы ежегодно осенью проводили сессии "верховного суда", которые длились обычно две недели. (Если бы мне пришлось все начинать сначала, я бы их проводил каждые шесть месяцев.)
Эти сессии проводились непосредственно перед окончательным принятием главных разделов руководств. На них присутствовала не только вся группа архитекторов, представители разработчиков и пользователей, ответственные за связь с архитекторами, но и руководители групп пользователей, сбыта и реализации. Председательствовал руководитель проекта Системы 360. Повестка дня содержала обычно около 200 пунктов, в большинстве своем мелких, которые были перечислены на плакатах, развешенных по залу. Выслушивались мнения всех сторон и принимались решения. Багодаря чудесам машинного редактирования текстов (и прекрасной организации административных служб) каждый участник находил поутру на своем месте новый вариант руководства, уже содержащий вчерашние решения.
Эти "осенние фестивали" были ценны не только принимаемыми решениями, но и тем, что они сразу становились общим достоянием. Каждый мог высказаться, выслушать всех остальных и глубже проникнуть в суть взаимосвязей между решениями.
Совместные реализации
Архитекторы Системы 360 имели два почти беспрецедентных преимущества: достаточное время для тщательной и неторопливой работы и политическое равенство с разработчиками. Разумные сроки были обусловлены графиком выпуска новой техники; политическое равенство вытекало из факта одновременного ведения нескольких разработок. Необходимость их строгой совместимости служила наилучшей движущей силой проектирования.
В процессе создания вычислительных машин почти всегда наступает день, когда обнаруживается, что машина и документация по ее использованию не соответствуют друг другу. В последующем столкновении документ обычно терпит поражение, потому что его переделка обходится гораздо дешевле и требует меньше времени. Не так обстоит дело в случае разработки серии моделей. Тогда задержки и затраты, связанные с принятием серии плохих машин, могут перевешивать задержки и затраты на переделку машин для точного соответствия их документации.
При описании языков программирования следует иметь в виду это обстоятельство. Нужно отдавать себе отчет в том, что раньше или позже, но появятся несколько трансляторов или интерпретаторов, отвечающих различным целям. Описание будет яснее, а дисциплина - строже, если с самого начала ведутся по меньшей мере две реализации.
Журнал регистрации телефонных звонков
Как только начинается реализация, возникает бесчисленное множество вопросов, связанных с интерпретацией решений архитектора, независимо от того, насколько точны спецификации. Очевидно, что многие такие вопросы требуют дополнений и разъяснений в самом тексте документа, другие же просто отражают недопонимание.
Необходимо всячески поощрять практику выяснен ния неясных мест по телефону, когда озадаченный разработчик, вместо того, чтобы действовать наугад, звонит архитектору и получает исчерпывающий ответ. Столь же необходимо осознать, что ответы архитектора на такие вопросы представляют собой вполне официальные и авторитетные заявления, которые следует довести до каждого.
Очень полезен журнал регистрации телефонных звонков, который ведет архитектор. В нем он регистрирует каждый вопрос и каждый ответ. Каждую неделю журналы нескольких архитекторов объединяются вместе, репродуцируются и распространяются среди пользователей и разработчиков. Хотя этот механизм совсем не формален, но он быстр и понятен.
Проверка конечного продукта
Лучший друг руководителя проекта - это его каждодневный противник, независимая организация, проверяющая продукт. Эта группа проверяет соответствие машин и программ их спецификациям и выступает в роли адвоката дьявола, выискивая все почти неуловимые дефекты и несоответствия. Каждой проектной организации нужна такая независимая техническая ревизионная группа, чтобы все было честно.
Независимым ревизором в последней инстанции оказывается сам заказчик. В безжалостном свете реального использования выявится каждый изъян. В таком случае группа проверки - это заменитель заказчика. Шаг за шагом опытный проверяющий найдет все места, где слово не было услышано, где проектировочные решения были .неверно поняты или неаккуратно реализованы. Поэтому группа проверки является необходимым звеном в цепи, по которой проходит слово архитектора, и она должна работать одновременно и параллельно с проектом.
VII. ПОЧЕМУ ОБРУШИЛАСЬ ВАВИЛОНСКАЯ БАШНЯ
"На всей земле был один язык и одно наречие. Двинувшись с Востока, они нашли в земле Сенаар равнину и поселились там. И сказали друг другу: наделаем кирпичей и обожжем огнем. И стали у них кирпичи вместо камней, а земляная смола вместо извести. И сказали они: -построим себе город и башню, высотою до небес; и сделаем себе имя, прежде нежели рассеемся но лицу всей земли. И сошел Господь посмотреть город и башню, которые строили сыны человеческие. И сказал Господь: вот, один народ, и один у всех язык. и вот что -начали они делать, и не отстанут они от того, что задумали делать. Сойдем же, и смешаем там язык их так, чтобы один не понимал речи другого. Н рассеял их Господь оттуда по всей земле; и они перестали строить город".
(Бытие 11.1-8)
Анализ Вавилонского проекта с точки зрения административного управления
Как считает библия, Вавилонская башня была вторым важнейшим техническим предприятием человечества после Ноева ковчега, и Вавилон был первым техническим провалом.
История о Вавилонской башне имеет глубокий смысл и очень поучительна во многих отношениях. Давайте, однако, рассмотрим ее как чисто технический проект и выясним, какие административные уроки можно из него извлечь. Были ли созданы все предпосылки для успеха? Имели ли строители:
1. Ясную цель? - Да, хотя достичь ее абсолютно невозможно. Однако проект провалился задолго до того, как он столкнулся с этим фундаментальным ограничением.
2. Рабочую силу? - Сколько угодно.
3. Материалы? - Глина и битум имеются в Мессо-потамии в избытке.
4. Достаточно времени? - Да, не было и речи ни о каких ограничениях на время.
5. Соответствующую технологию? - Да, пирамидальные или конические конструкции очень просты и хорошо выдерживают нагрузку. С каменной кладкой строители были прекрасно знакомы. Проект потерпел крах до того, как он наткнулся на чисто технические трудности.
Итак, если у них все это было, то почему же проект провалился? Чего же не хватало строителям? У них не было, во-первых, связи, и, как следствие,организации. Они не смогли говорить друг с другом и, следовательно, не смогли координировать свои действия. Как только прекратилась связь, застопорилась и работа. Читая между строк, мы угадываем, что отсутствие связи привело к спорам, недоброжелательству, соперничеству между группами. Короче говоря, люди начали разбредаться в разные стороны, предпочитая изоляцию ссорам и пререканиям.
Связь в больших программистских проектах
Точно то же происходит и сегодня. Неувязка с графиком, функциональные несоответствия, ошибки в системе возникают только потому, что левая рука не знает, что делает правая. В ходе работы отдельные коллективы потихоньку меняют функции, размеры и быстродействие своих собственных программ, явно и неявно пренебрегая допущениями о том, что имеется на входе, и как использовать получаемое на выходе.
Например, разработчик функции сегментации программ может, вникнув в задачу, уменьшить ее скорость, основываясь на статистических данных о том, что эта функция редко используется в прикладных программах. Тем временем, следуя за ним по пятам, его коллега может разработать основную часть супервизора так, что он будет существенно зависеть от быстродействия функции сегментации. Таким образом, изменение быстродействия само становится изменением спецификаций, о нем следует широко объявить и рассмотреть с точки зрения всей системы.
Как отдельные группы должны поддерживать связь друг с другом? - Всеми возможными путями.
* Неформально. При наличии хорошей организации телефонной связи и четкого определения связей внутри группы могут состояться сотни телефонных разговоров, от которых зависит общая интерпретация написанных документов.
* Совещания. Регулярные совещания участников проекта, где группы обмениваются технической информацией, очень важны. Благодаря им рассеиваются сотни мелких недоразумений и вопросов.
* Рабочий документ. Формальный рабочий документ проекта следует вести с самого начала. Однако он заслуживает отдельного раздела.
Рабочий документ проекта
Что. Рабочий документ проекта - это не столько отдельный документ, сколько структура, накладываемая на документы, выпускаемые проектом.
Все документы проекта должны входить в эту структуру. Сюда относятся цели и задачи, внешние спецификации, спецификации сопряжении, технические стандарты, внутренние спецификации и административные меморандумы.
Зачем. Техническая проза почти бессмертна. Рассматривая генеалогию технического руководства по какой-то части оборудования или математического обеспечения, можно проследить, что не только идеи, но одни и те же предложения и даже абзацы сохраняются с самого первого меморандума, предлагающего продукт или поясняющего начальный проект. Ножницы и клей нужны создателю технического документа не менее, чем авторучка.
Поскольку это так, и поскольку завтрашние руководства вырастают из сегодняшних меморандумов, очень важно сохранять правильную структуру документов. Ранняя разработка рабочего документа проекта обеспечивает продуманную, а не случайную структуру документации. Более того, установление такой структуры позволяет всему, что написано позже, Придавать форму, соответствующую этой структуре.
Второй довод в пользу рабочих . документов - это необходимость контроля за распространением информации. Проблема здесь заключается не в ограничении доступа к информации, а в том, чтобы обеспечить соответствующей информацией всех, кому она нужна.
Первый шаг на этом пути - перенумеровать все меморандумы с тем, чтобы каждый работник имел в своем распоряжении упорядоченный список заголовков и мог обратиться к нужному. Дальнейшая организация рабочих документов заключается в установлении древовидной структуры меморандумов.
Механика. Как и многие другие проблемы руководства программистскими проектами, проблема технических меморандумов становится все более сложной по мере увеличения проектов. Для десяти человек документы можно просто перенумеровать. Для сотни людей будет достаточно нескольких линейных последовательностей. Для тысячи, неизбежно разбросанной по разным местам, потребность в структурированных рабочих документах возрастает, но вместе с ней растет п размер рабочих документов. Как справиться с этой проблемой?
Я думаю, что в проекте OS/360 это вполне удалось. На необходимости хорошо структурированных рабочих документов особенно настаивал О. С. Локен, который убедился в их эффективности на примере своего предыдущего проекта, операционной системы IBM 1410- 7010.
Мы быстро пришли к решению, что каждый программист должен видеть весь материал, т. е. он должен иметь свою собственную копию рабочих документов.
Своевременное появление рабочих документов крайне важно. Они должны отражать ежеминутное положение дел. Но добиться этого будет очень трудно, если при внесении в документ каждого изменения его придется перепечатывать полностью. В книге со сменными листами, однако, нужно менять только отдельные страницы. В нашем распоряжении была такая система редактирования текстов на ЭВМ, значение которой для своевременного ведения документов трудно переоценить. Копии с оригинала делались тут же, на печатающем устройстве, и весь цикл подготовки новых страниц занимал меньше одного дня.
Однако человек, получивший все эти новые варианты страниц, оказывался перед проблемой сравнения. Когда ему впервые попадает страница с изменениями, он хочет знать: "Что изменилось?". Когда же он позже обращается к ней, ему нужно знать: "А как это определяется сегодня?".
Последняя потребность удовлетворяется путем непрерывного ведения документов. Для того, чтобы явно и отчетливо показать внесенные изменения, нужно предпринять другие меры. Во-первых, нужно прямо на странице выделить текст, претерпевший изменения, например, с помощью вертикальной черты на полях против каждой измененной строки. Во-вторых, вместе с новыми страницами нужно распространять специально написанный краткий обзор, где перечисляются внесенные изменения и комментируется их значение.
Нашему проекту не исполнилось еще и полугода, как мы столкнулись с другой проблемой. Рабочие документы уже стали около 1,5 м толщиной! Если бы сложить друг на друга все 100 экземпляров, которыми пользовались наши программисты в своем здании на Манхэттене, то получилась бы башня выше самого дома. И далее, ежедневно распространялись изменения толщиной в 5 см, т. е. приблизительно 150 страниц вновь подшивалось в документ. В.едение рабочих документов стало занимать значительную часть каждого дня.
В этот момент мы переключились на микрофиши, что сэкономило нам миллион долларов, учитывая даже стоимость проекторов для чтения с микрофиш. Мы смогли прекрасно организовать производство микрофиш, объем рабочих документов сократился с 1,7 м3 до 0,004 м3 и, что важнее всего, изменения сразу вносились в куски по 100 страниц, тем самым в 100 раз облегчилась проблема организации документов.
Микрофиши имеют свои недостатки. С точки зрения руководителя, чем неудобнее вкладывать страницы в рабочий документ, тем больше вероятность, что изменения, в них содержащиеся, будут прочитаны, а именно этого он и добивается. Микрофиши могуг сделать процесс ведения рабочих документов слишком легким.
Кроме того, работая с микрофишами, -читатель не имеет возможности выделять в них главное, отмечать и оставлять свои комментарии, А документы, несущие на себе следы взаимодействия с читателем, более эффективны для автора и более полезны для читателя.
Единство "Принципов действия Системы 360" обусловлено тем, что они вышли из-под пера только двух авторов - Джерри Блау и Андриса Падегза. Идеи, в них изложенные, принадлежали примерно десятку людей, но для того, чтобы сохранить соответствие между продуктом и его описанием, превращать эти идеи в текстовые спецификации должны были один или два человека. Чтобы дать какое-нибудь определение, необходимо принять целый ряд мини-решений, которые не требуют подробного обсуждения. Примером такого рода в Системе 360 могут служить детали установления "кода условия" после каждой операции. Нетривиальным, однако, является принцип, согласно которому такие мини-решения должны быть полностью непротиворечивы.
Приложение к "Принципам действия Системы 3GO", написанное Джерри Блау, я считаю лучшим из всех когда-либо виденных мною руководств. В этом приложении очень точно и тщательно описываются пределы совместимости Системы 360, указывается, к чему следует стремиться, и перечисляются те области внешнего окружения, где архитектура умышленно хранит молчание и где результаты, полученные на разных моделях, могут отличаться друг от друга, где один экземпляр данной модели может отличаться от другого или где, наконец, система может отличаться от себя самой после каких-то технологических изменений. Авторы руководств должны стремиться именно к такому уровню точности, они обязаны определять то, чего нельзя делать, столь же тщательно, как и то, что можно.
Формальные описания
Английский язык, как и все другие естественные языки, нельзя считать идеальным средством для таких описаний. Поэтому Создатель руководства сам должен накладывать строгие ограничения на язык с тем, чтобы достичь необходимой точности. Использование формальной системы обозначений представляется очень привлекательным выходом из этого затруднения. В конце концов точность - это основа, смысл существования формальной системы обозначений.
Давайте рассмотрим сильные и слабые стороны формальных описаний. Как уже отмечалось, формальные описания точны. Они стремятся быть максимально полными; пробелы более заметны, а потому скорее заполняются. Зато они непонятны. Когда речь идет об английской прозе, всегда можно назвать принципы ее организации, указать структуру на различных эта-. пах или уровнях и привести примеры. Несложно перечислить исключения и выявить противоречия. И что важнее всего, можно объяснить, почему это так, а не иначе. Достаточно разработанные формальные описания вызывают изумление своей элегантностью и доверие - своей точностью. Но для того, чтобы их содержание можно было легко уяснить самому и объяснить другим, необходимы пояснения. По этим причинам я считаю, что будущие спецификации должны состоять как из формальных, так и текстовых описаний.
Старая пословица предупреждает: "Никогда не выходи в море с двумя хронометрами: бери один или три". Ее вполне можно отнести и к проблеме текстовых и формальных описаний. Если у вас есть и то, и другое, то одно должно быть стандартом, а второе - производным описанием, что следует указать ясно. В качестве исходного стандарта можно выбрать любое из них. Алгол-68 имеет в качестве стандарта формальное описание и, кроме того, поясняющее текстовое описание. Стандартное описание PL/I дано текстом, а формальное описание - как производное. Система 360 также имеет текстовое описание в качестве стандарта и рядом - производное формальное описание.
Существует множество способов представления формальных описаний. Бэкусова - Наурова форма (БНФ), разработанная для описания языков, широко освещена в литературе2). Формальное описание PL/I использует новую систему обозначении абстрактного синтаксиса, и она адекватно описана3). Язык APL, разработанный Айверсоном, применялся для описания машин, в частности, IBM-70904) и Системы 3605).
Белл и Ныоэлл предложили новую систему для описания конфигураций и архитектуры машин и проиллюстрировали ее на примере нескольких машин, включая PDP-8 фирмы DEC6), IBM-70906) и Системы 3607).
Почти псе формальные описания воплощают реализацию аппаратуры или системы программного обеспечения, внешние спецификации которой они определяют. Синтаксис можно описать и без этого, но семантику обычно описывают с помощью программы, которая выполняет определяемую операцию. Это, конечно, реализация, и как таковая она диктует архитектурные решения. Необходимо указать, что формальное описание приложимо только к внешним спецификациям, и следует сказать, что они собой представляют.
Не только формальное описание является реализацией, но и реализация может служить формальным описанием. Именно этот принцип использовался при создании первых совместимых ЭВМ. Новая машина должна соответствовать старой. Какие-то места в руководстве непонятны? "Спросите машину!". Нужно было разработать тестовую программу, определяющую поведение старой машины, и добиться того, чтобы новая машина проходила через этот тест.
Программы-имитаторы аппаратуры или математического обеспечения могут использоваться точно таким же образом. Это реализация; она работает. Поэтому все вопросы описания можно разрешить путем ее проверки.
Использование реализации в качестве описания имеет некоторые преимущества. Все вопросы разрешаются однозначно посредством эксперимента. Дискуссии не нужны, потому что ответы получаются быстро. Ответы всегда точны в той степени, которая нужна, ц они по определению верны. Но, кроме преимуществ, такой подход имеет и очень много недостатков. Реализация может вызвать переопределение даже внешних спецификаций. Ошибка в синтаксисе в реализации приводит к любому результату; в "чистой" системе этот результат является лишь указанием на некорректность и ничем больше. В "неряшливой" системе могут появиться самые разнообразные побочные эффекты, которые могут быть использованы программистами. Когда мы предприняли эмуляцию ЭВМ IBM-1401 на Системе 360, то обнаружилось около 30 различных "курьезов", или побочных эффектов, вызываемых, предположительно, ошибочными операциями, которые, однако, стали широко использоваться и должны теперь рассматриваться как часть описания. Реализация, выступающая в качестве описания, предлагает избыточные определения; она говорит не только о том, что машина должна делать, но, в значительной степени, и о том, как она это должна делать.
Кроме того, реализация будет иногда давать неожиданные и незапланированные ответы на трудные вопросы, это описание de facto оказывается неэлегантным в таких конкретных местах как раз потому, что они в свое время не были продуманы. Их воспроизведение в другой реализации может дорого обойтись. Например, некоторые машины не полностью очищают регистр множимого после умножения. Явление это по своей природе - часть фактического описания, однако его воспроизведение может помешать использованию более быстрого алгоритма умножения.
Наконец, использование реализации в качестве формального описания таит в себе опасную возможность перепутать, что именно является стандартом:
текстовое описание или формальное. Это особенно справедливо в отношении программных имитаторов;
Кроме того, нельзя вносить модификации в реализацию, пока она служит стандартом.
Прямое внесение
В распоряжении архитектора систем математического обеспечения есть превосходный метод распространения и внесения определений. Он особенно полезен для установления, если не семантики, то синтаксиса межмодульных сопряжении. Заключается этот метод в задании описания передаваемых параметров или совместно используемой памяти, и в требований, чтобы реализация включала данное описание через операции периода компиляции (макрокоманды или % INCLUDE в PL/I). Кроме того, если обращение ко всему сопряжению осуществляется только по символическим именам, то описание можно изменить путем добавления или введения новых переменных только ретрансляцией используемой программы без ее изменения.
Конференции и разбирательства
Нет никакой нужды говорить о том, что совещания необходимы. Кроме сотен частных консультаций, необходимы более формальные встречи. Мы считаем, что полезно их проводить на двух уровнях.
Первый- это еженедельные совещания всех архитекторов и официальных представителей разработчиков аппаратуры и математического обеспечения. Председательствует на них главный архитектор системы.
Каждый может вынести на обсуждение какую-нибудь проблему или предложить изменения, но обычно все предложения распространяются в письменной форме перед совещанием. Новая проблема, как правило, какое-то время обсуждается. Причем основное внимание уделяется не принятию решений как таковых, а процессу творческого поиска. Вся группа пытается найти возможные решения проблемы, затем некоторые из этих решений передаются одному или нескольким архитекторам, которые превращают их в строго сформулированные предложения, обосновывающие изменения в документах.
Далее начинается процесс принятия решений. Предложения внимательно изучаются разработчиками и пользователями, тщательно взвешиваются все "за" и "против". Если согласие достигнуто - отлично. В противном случае решение принимает главный архитектор. Время не тратится впустую, и решения быстро и широко распространяются.
Решения, принимаемые на еженедельных совещаниях, дают быстрый результат и не тормозят работу. Если кто-либо ими совершенно неудовлетворен, он может нeмeд^eннo апеллировать к руководителю проекта, но такое случается крайне редко.
Подобные совещания очень плодотворны по нескольким причинам:
1. Одна и та же группа архитекторов, пользователей и разработчиков встречается еженедельно в течение месяцев. Не нужно тратить время на то, чтобы ввести людей в курс дела.
2. Группа состоит из людей способных, изобретательных, хорошо разбирающихся в проблеме и глубоко заинтересованных в результатах. Ни один из них не выступает в роли "советчика". Каждый уполномочен принимать на себя обязательства.
3. Когда возникают проблемы, поиск их решения осуществляется как внутри очевидных границ, так и за их пределами.
4. Формализм письменных предложений позволяет сосредоточить внимание, стимулировать их решение и набежать противоречий.
5. Законодательная власть главного архитектора позволяет избежать компромиссов и задержек.
По прошествии времени некоторые решения устаревают. Отдельные частные способы решения не удовлетворяют того или иного участника. Другие решения вызывают непредвиденные затруднения, и иногда еженедельные совещания не в состоянии их разрешить. Так накапливается груз мелких жалоб, открытых вопросов пли недовольства. Для того, чтобы справиться со всем этим, мы ежегодно осенью проводили сессии "верховного суда", которые длились обычно две недели. (Если бы мне пришлось все начинать сначала, я бы их проводил каждые шесть месяцев.)
Эти сессии проводились непосредственно перед окончательным принятием главных разделов руководств. На них присутствовала не только вся группа архитекторов, представители разработчиков и пользователей, ответственные за связь с архитекторами, но и руководители групп пользователей, сбыта и реализации. Председательствовал руководитель проекта Системы 360. Повестка дня содержала обычно около 200 пунктов, в большинстве своем мелких, которые были перечислены на плакатах, развешенных по залу. Выслушивались мнения всех сторон и принимались решения. Багодаря чудесам машинного редактирования текстов (и прекрасной организации административных служб) каждый участник находил поутру на своем месте новый вариант руководства, уже содержащий вчерашние решения.
Эти "осенние фестивали" были ценны не только принимаемыми решениями, но и тем, что они сразу становились общим достоянием. Каждый мог высказаться, выслушать всех остальных и глубже проникнуть в суть взаимосвязей между решениями.
Совместные реализации
Архитекторы Системы 360 имели два почти беспрецедентных преимущества: достаточное время для тщательной и неторопливой работы и политическое равенство с разработчиками. Разумные сроки были обусловлены графиком выпуска новой техники; политическое равенство вытекало из факта одновременного ведения нескольких разработок. Необходимость их строгой совместимости служила наилучшей движущей силой проектирования.
В процессе создания вычислительных машин почти всегда наступает день, когда обнаруживается, что машина и документация по ее использованию не соответствуют друг другу. В последующем столкновении документ обычно терпит поражение, потому что его переделка обходится гораздо дешевле и требует меньше времени. Не так обстоит дело в случае разработки серии моделей. Тогда задержки и затраты, связанные с принятием серии плохих машин, могут перевешивать задержки и затраты на переделку машин для точного соответствия их документации.
При описании языков программирования следует иметь в виду это обстоятельство. Нужно отдавать себе отчет в том, что раньше или позже, но появятся несколько трансляторов или интерпретаторов, отвечающих различным целям. Описание будет яснее, а дисциплина - строже, если с самого начала ведутся по меньшей мере две реализации.
Журнал регистрации телефонных звонков
Как только начинается реализация, возникает бесчисленное множество вопросов, связанных с интерпретацией решений архитектора, независимо от того, насколько точны спецификации. Очевидно, что многие такие вопросы требуют дополнений и разъяснений в самом тексте документа, другие же просто отражают недопонимание.
Необходимо всячески поощрять практику выяснен ния неясных мест по телефону, когда озадаченный разработчик, вместо того, чтобы действовать наугад, звонит архитектору и получает исчерпывающий ответ. Столь же необходимо осознать, что ответы архитектора на такие вопросы представляют собой вполне официальные и авторитетные заявления, которые следует довести до каждого.
Очень полезен журнал регистрации телефонных звонков, который ведет архитектор. В нем он регистрирует каждый вопрос и каждый ответ. Каждую неделю журналы нескольких архитекторов объединяются вместе, репродуцируются и распространяются среди пользователей и разработчиков. Хотя этот механизм совсем не формален, но он быстр и понятен.
Проверка конечного продукта
Лучший друг руководителя проекта - это его каждодневный противник, независимая организация, проверяющая продукт. Эта группа проверяет соответствие машин и программ их спецификациям и выступает в роли адвоката дьявола, выискивая все почти неуловимые дефекты и несоответствия. Каждой проектной организации нужна такая независимая техническая ревизионная группа, чтобы все было честно.
Независимым ревизором в последней инстанции оказывается сам заказчик. В безжалостном свете реального использования выявится каждый изъян. В таком случае группа проверки - это заменитель заказчика. Шаг за шагом опытный проверяющий найдет все места, где слово не было услышано, где проектировочные решения были .неверно поняты или неаккуратно реализованы. Поэтому группа проверки является необходимым звеном в цепи, по которой проходит слово архитектора, и она должна работать одновременно и параллельно с проектом.
VII. ПОЧЕМУ ОБРУШИЛАСЬ ВАВИЛОНСКАЯ БАШНЯ
"На всей земле был один язык и одно наречие. Двинувшись с Востока, они нашли в земле Сенаар равнину и поселились там. И сказали друг другу: наделаем кирпичей и обожжем огнем. И стали у них кирпичи вместо камней, а земляная смола вместо извести. И сказали они: -построим себе город и башню, высотою до небес; и сделаем себе имя, прежде нежели рассеемся но лицу всей земли. И сошел Господь посмотреть город и башню, которые строили сыны человеческие. И сказал Господь: вот, один народ, и один у всех язык. и вот что -начали они делать, и не отстанут они от того, что задумали делать. Сойдем же, и смешаем там язык их так, чтобы один не понимал речи другого. Н рассеял их Господь оттуда по всей земле; и они перестали строить город".
(Бытие 11.1-8)
Анализ Вавилонского проекта с точки зрения административного управления
Как считает библия, Вавилонская башня была вторым важнейшим техническим предприятием человечества после Ноева ковчега, и Вавилон был первым техническим провалом.
История о Вавилонской башне имеет глубокий смысл и очень поучительна во многих отношениях. Давайте, однако, рассмотрим ее как чисто технический проект и выясним, какие административные уроки можно из него извлечь. Были ли созданы все предпосылки для успеха? Имели ли строители:
1. Ясную цель? - Да, хотя достичь ее абсолютно невозможно. Однако проект провалился задолго до того, как он столкнулся с этим фундаментальным ограничением.
2. Рабочую силу? - Сколько угодно.
3. Материалы? - Глина и битум имеются в Мессо-потамии в избытке.
4. Достаточно времени? - Да, не было и речи ни о каких ограничениях на время.
5. Соответствующую технологию? - Да, пирамидальные или конические конструкции очень просты и хорошо выдерживают нагрузку. С каменной кладкой строители были прекрасно знакомы. Проект потерпел крах до того, как он наткнулся на чисто технические трудности.
Итак, если у них все это было, то почему же проект провалился? Чего же не хватало строителям? У них не было, во-первых, связи, и, как следствие,организации. Они не смогли говорить друг с другом и, следовательно, не смогли координировать свои действия. Как только прекратилась связь, застопорилась и работа. Читая между строк, мы угадываем, что отсутствие связи привело к спорам, недоброжелательству, соперничеству между группами. Короче говоря, люди начали разбредаться в разные стороны, предпочитая изоляцию ссорам и пререканиям.
Связь в больших программистских проектах
Точно то же происходит и сегодня. Неувязка с графиком, функциональные несоответствия, ошибки в системе возникают только потому, что левая рука не знает, что делает правая. В ходе работы отдельные коллективы потихоньку меняют функции, размеры и быстродействие своих собственных программ, явно и неявно пренебрегая допущениями о том, что имеется на входе, и как использовать получаемое на выходе.
Например, разработчик функции сегментации программ может, вникнув в задачу, уменьшить ее скорость, основываясь на статистических данных о том, что эта функция редко используется в прикладных программах. Тем временем, следуя за ним по пятам, его коллега может разработать основную часть супервизора так, что он будет существенно зависеть от быстродействия функции сегментации. Таким образом, изменение быстродействия само становится изменением спецификаций, о нем следует широко объявить и рассмотреть с точки зрения всей системы.
Как отдельные группы должны поддерживать связь друг с другом? - Всеми возможными путями.
* Неформально. При наличии хорошей организации телефонной связи и четкого определения связей внутри группы могут состояться сотни телефонных разговоров, от которых зависит общая интерпретация написанных документов.
* Совещания. Регулярные совещания участников проекта, где группы обмениваются технической информацией, очень важны. Благодаря им рассеиваются сотни мелких недоразумений и вопросов.
* Рабочий документ. Формальный рабочий документ проекта следует вести с самого начала. Однако он заслуживает отдельного раздела.
Рабочий документ проекта
Что. Рабочий документ проекта - это не столько отдельный документ, сколько структура, накладываемая на документы, выпускаемые проектом.
Все документы проекта должны входить в эту структуру. Сюда относятся цели и задачи, внешние спецификации, спецификации сопряжении, технические стандарты, внутренние спецификации и административные меморандумы.
Зачем. Техническая проза почти бессмертна. Рассматривая генеалогию технического руководства по какой-то части оборудования или математического обеспечения, можно проследить, что не только идеи, но одни и те же предложения и даже абзацы сохраняются с самого первого меморандума, предлагающего продукт или поясняющего начальный проект. Ножницы и клей нужны создателю технического документа не менее, чем авторучка.
Поскольку это так, и поскольку завтрашние руководства вырастают из сегодняшних меморандумов, очень важно сохранять правильную структуру документов. Ранняя разработка рабочего документа проекта обеспечивает продуманную, а не случайную структуру документации. Более того, установление такой структуры позволяет всему, что написано позже, Придавать форму, соответствующую этой структуре.
Второй довод в пользу рабочих . документов - это необходимость контроля за распространением информации. Проблема здесь заключается не в ограничении доступа к информации, а в том, чтобы обеспечить соответствующей информацией всех, кому она нужна.
Первый шаг на этом пути - перенумеровать все меморандумы с тем, чтобы каждый работник имел в своем распоряжении упорядоченный список заголовков и мог обратиться к нужному. Дальнейшая организация рабочих документов заключается в установлении древовидной структуры меморандумов.
Механика. Как и многие другие проблемы руководства программистскими проектами, проблема технических меморандумов становится все более сложной по мере увеличения проектов. Для десяти человек документы можно просто перенумеровать. Для сотни людей будет достаточно нескольких линейных последовательностей. Для тысячи, неизбежно разбросанной по разным местам, потребность в структурированных рабочих документах возрастает, но вместе с ней растет п размер рабочих документов. Как справиться с этой проблемой?
Я думаю, что в проекте OS/360 это вполне удалось. На необходимости хорошо структурированных рабочих документов особенно настаивал О. С. Локен, который убедился в их эффективности на примере своего предыдущего проекта, операционной системы IBM 1410- 7010.
Мы быстро пришли к решению, что каждый программист должен видеть весь материал, т. е. он должен иметь свою собственную копию рабочих документов.
Своевременное появление рабочих документов крайне важно. Они должны отражать ежеминутное положение дел. Но добиться этого будет очень трудно, если при внесении в документ каждого изменения его придется перепечатывать полностью. В книге со сменными листами, однако, нужно менять только отдельные страницы. В нашем распоряжении была такая система редактирования текстов на ЭВМ, значение которой для своевременного ведения документов трудно переоценить. Копии с оригинала делались тут же, на печатающем устройстве, и весь цикл подготовки новых страниц занимал меньше одного дня.
Однако человек, получивший все эти новые варианты страниц, оказывался перед проблемой сравнения. Когда ему впервые попадает страница с изменениями, он хочет знать: "Что изменилось?". Когда же он позже обращается к ней, ему нужно знать: "А как это определяется сегодня?".
Последняя потребность удовлетворяется путем непрерывного ведения документов. Для того, чтобы явно и отчетливо показать внесенные изменения, нужно предпринять другие меры. Во-первых, нужно прямо на странице выделить текст, претерпевший изменения, например, с помощью вертикальной черты на полях против каждой измененной строки. Во-вторых, вместе с новыми страницами нужно распространять специально написанный краткий обзор, где перечисляются внесенные изменения и комментируется их значение.
Нашему проекту не исполнилось еще и полугода, как мы столкнулись с другой проблемой. Рабочие документы уже стали около 1,5 м толщиной! Если бы сложить друг на друга все 100 экземпляров, которыми пользовались наши программисты в своем здании на Манхэттене, то получилась бы башня выше самого дома. И далее, ежедневно распространялись изменения толщиной в 5 см, т. е. приблизительно 150 страниц вновь подшивалось в документ. В.едение рабочих документов стало занимать значительную часть каждого дня.
В этот момент мы переключились на микрофиши, что сэкономило нам миллион долларов, учитывая даже стоимость проекторов для чтения с микрофиш. Мы смогли прекрасно организовать производство микрофиш, объем рабочих документов сократился с 1,7 м3 до 0,004 м3 и, что важнее всего, изменения сразу вносились в куски по 100 страниц, тем самым в 100 раз облегчилась проблема организации документов.
Микрофиши имеют свои недостатки. С точки зрения руководителя, чем неудобнее вкладывать страницы в рабочий документ, тем больше вероятность, что изменения, в них содержащиеся, будут прочитаны, а именно этого он и добивается. Микрофиши могуг сделать процесс ведения рабочих документов слишком легким.
Кроме того, работая с микрофишами, -читатель не имеет возможности выделять в них главное, отмечать и оставлять свои комментарии, А документы, несущие на себе следы взаимодействия с читателем, более эффективны для автора и более полезны для читателя.