Страница:
Аристократия и демократия
Концептуальное единство, в свою очередь, требует, чтобы весь проект исходил из одной головы, или же из нескольких, работающих в полном согласии.
Однако график требует, чтобы система создавалась многими людьми. Существуют два метода решения этой дилеммы. Первый - это тщательное разделение труда между разработкой архитектуры и реализацией системы. Второй - это новый способ организации коллективов программистов, предложенный выше.
Отделение архитектурных проблем от реализации является весьма эффективным путем достижения концептуального единства очень больших проектов. Я убедился в этом на примере успешного создания фирмой IBM вычислительной машины Stretch и промышленной серии ЭВМ Системы 360.
Отсутствие такого подхода сказалось при разработке операционной системы OS/360.
Под архитектурой системы я понимаю полную и подробную спецификацию ее сопряжения с пользователем. Для вычислительной машины это руководство по программированию. Для транслятора - руководство по входному языку. Для управляющей программы - руководство по одному или нескольким языкам, используемым для обращения к ее функциям. Для системы в целом - это объединение всех тех руководств, к которым должен обращаться пользователь, чтобы решить свою задачу.
Архитектор системы, как и архитектор, проектирующий здание,- агент пользователя. Его работа заключается в том, чтобы использовать свои профессиональные и технические знания исключительно в интересах пользователя, в противоположность интересам коммивояжера, производителя и т. д.2).
Необходимо тщательно отделять архитектуру от реализации. Как сказал Блау, "Там, где архитектура говорит, что происходит, разработка говорит, как это должно происходить"3). В качестве простого примера он приводит часы, архитектура которых - циферблат, стрелки и головка завода. Когда ребенок познакомится с этой архитектурой, он с одинаковой легкостью сможет определять время как по ручным часам, так и по башенным курантам. Разработка и реализация, однако, каждый раз описывают внутреннюю структуру механизмы, приводящие часы в действие и обеспечивающие точность хода.
В Системе 360, например, одна машинная архитектура реализована совершенно по-разному в каждой из девяти моделей, и наоборот, одна реализация, средства обмена, память и микропрограммы модели 360/30 используются в четырех различных архитектурах: серия ЭВМ Системы 360, мультиплексный канал с 224 логическими независимыми подканалами, селекторный канал и вычислительная машина IBM-14014).
Такое разграничение в равной степени применимо и к системам программирования. Существует стандартный фортран IV. Он является архитектурой для многих трансляторов. В рамках этой архитектуры возможны самые различные реализации: программа в оперативной памяти пли транслятор в оперативной памяти, быстрая трансляция или оптимизация, синтаксически ориентированный или "прямой" транслятор. Подобным образом любой язык ассемблера или язык управления задачами допускает разные реализации ассемблера или планировщика.
Теперь мы обратимся к более эмоциональной стороне проблемы: аристократия против демократии. Разве не образуют архитекторы своего рода аристократию, интеллектуальную элиту, которая указывает разработчикам, что им следует делать? Не отбирает ли эта элита всю творческую работу, отводя разработчикам роль "винтиков"? Может быть, конечный продукт улучшится, если, следуя принципам демократии, позволить всему коллективу генерировать идеи, а не ограничиваться спецификациями, разработанными всего несколькими людьми?
Последний вопрос самый легкий. Я, естественно, не собираюсь настаивать на том, что только у архитекторов могут быть хорошие архитектурные идеи. Довольно часто свежая мысль исходит от разработчика пли от пользователя. Однако весь мой опыт убеждает меня в том, что именно концептуальное единство системы определяет легкость ео использования, и я попытаюсь это показать. Предлагаемые средства и идеи сами по себе могут быть очень хороши, но если они не составляют единого целого с основными концепциями системы, от них лучше отказаться. Если же таких отличных, но несовместимых идей оказалось много, остается только выбросить в мусорную корзинку всю систему и заняться созданием новой, обладающей единством и построенной на других основных идеях.
Что касается вопроса о появлении новой аристократии, то следует ответить и да, и нет.
Да - в том смысле, что архитекторов всегда немного, а конечный продукт их деятельности живет дольше, чем результаты труда разработчиков, и архитектор находится в центре всех усилий по проектированию системы, защищая интересы пользователей. Если система должна обладать концептуальным единством, то необходим кто-то, следящий за этими концепциями. Это и есть та аристократия, которая не нуждается в извинениях.
Нет - потому что разработка внешних спецификаций - ничуть не более творческая работа, чем разработка проектов. Просто это другая работа. Разработка проекта, если архитектура уже имеется, требует от исполнителей и позволяет им в той же мере проявлять творческие способности и выдавать новые идеи, как и создание внешних спецификаций. По существу отношение стоимости продукта к его производительности в основном зависит от разработчика, в то время как простота пользования зависит от архитектора.
Существует множество примеров из других областей искусства и ремесла, заставляющих поверить в то, что дисциплина полезна. Как утверждает афоризм, распространенный среди художников, "форма освобождает". Хуже всего получаются сооружения, бюджет которых -больше, чем это нужно для достижения поставленной цели. Вряд ли необходимость каждую неделю писать по кантате отрицательно сказывалась на творческих возможностях Баха. Я уверен, что архитектура вычислительной машины Stretch много выиграла бы от введения более строгих ограничений; так, ограничения, накладываемые бюджетом модели 30 Системы 360, по моему мнению, положительно сказались на архитектуре модели 75. Аналогично я подметил, что заданная архитектура повышает, а не подавляет творческие возможности группы разработчиков. Они сразу же сосредоточиваются на той части проблемы, которой еще не занимались, и в результате появляются творческие находки. Если же на работу группы не накладывается никаких ограничений, то много времени и усилий, размышлений и обсуждений уйдет на архитектурные решения, а с самой реализацией они справятся очень быстро5).
Существование этого эффекта, который я наблюдал неоднократно, подтверждает Р. Конвей - руководитель группы, создавшей транслятор PL/G с языка PL/I в Корнелльском университете. Он говорит: "В конце концов, мы решили реализовать язык без всяких изменений и улучшений, потому что дебаты по этому вопросу отняли бы у нас все силы"6).
Чем может заполнить разработчик период ожидания?
Ошибка, стоимостью в несколько миллионов долларов, служит очень горестным уроком, но запоминается надолго. Я живо помню тот вечер, когда мы принимали решение о написании внешних спецификации для OS/360. Руководитель группы архитекторов ЭВМ, руководитель отдела разработки управляющих программ и я бились над планом, графиком и распределением обязанностей.
В группе архитекторов было 10 отличных специалистов. Ее руководитель утверждал, что они могут написать спецификации, и сделают это хорошо. Но на это потребуется 10 месяцев, на три месяца больше, чем допускал график.
В отделе управляющих программ было 150 человек. Ее руководитель говорил, что, взаимодействуя с архитекторами, они смогут подготовить практичные спецификации высокого качества и при этом уложиться в график. Если же этим займутся архитекторы, то его 150 человек будут десять месяцев бить баклуши.
На это архитектор отвечал, что если я поручу написание спецификаций отделу управляющих программ, то мы не только не дождемся результатов вовремя, но получим их на три месяца позже и они окажутся гораздо хуже. Так ц получилось. Архитектор был прав во всех отношениях. Кроме того, отсутствие концептуального единства увеличило стоимость создания и модификации системы п, по моим оценкам, удлинило срок отладки по меньшей мере па год.
Много факторов, конечно, повлияло на принятие этого ошибочного решения, но главными были график п желание дать работу 150 разработчикам. Сирены пели мне именно эту песню, ц теперь-то я вижу всю ее смертельную опасность.
Когда речь заходит о том, чтобы поручить маленькой группе архитекторов создание всех внешних спецификаций для вычислительной машины или системы программирования, разработчики выдвигают три возражения:
* спецификации будут слишком разнообразны по функциям, но не учтут практическую стоимость реализации;
* архитекторы сделают всю творческую часть работы, лишив разработчиков возможности что-либо придумать самим;
* большому числу разработчиков придется простаивать, в то время как спецификации будут проходить через игольное ушко, называемое группой архитекторов.
Первое представляет реальную опасность и подробнее будет рассматриваться в следующей главе. Два других возражения - не более, чем мираж. Как мы уже убедились, разработка - тоже творческая деятельность. Возможности для творчества и проявления изобретательности при разработке не уменьшаются сколько-нибудь значительно из-за необходимости работать с заданными внешними спецификациями, а степень проявления творческой активности может даже возрасти благодаря дисциплине. Конечный же продукт, вне всякого сомнения, от этого только выиграет.
Последнее возражение касается распределения времени и этапов работы. Первый ответ, приходящий на ум, заключается в том, что не нужно нанимать разработчиков до тех пор, пока не будут готовы спецификации. Именно так поступают при строительстве здания.
Однако в системном программировании темпы выше и график очень уплотнен. Насколько можно совместить этапы создания спецификаций и самого строительства?
Как подчеркивает Блау, в творческой деятельности выделяются три различные этапа: архитектура, разработка и реализация. На практике оказывается, что все этапы могут начинаться одновременно и проходить параллельно.
При проектировании вычислительной машины, например, разработчик уже может начинать работу, даже если он имеет довольно смутные представления о принципах действия, несколько более ясные технологические идеи и четко определенные понятия о стоимости и производительности. Он может начать проектировать информационные связи, управляющие последовательности, принципы компоновки п т. д. Он придумывает пли совершенствует средства, которые ему потребуются, особенно систему документирования, включая систему автоматизации проектирования.
Одновременно может проходить разработка и устранение недостатков у интегральных схем, плат, кабелей, стоек, источников питания, запоминающих устройств и т. д., и составляться документация для них.
Эта работа выполняется параллельно с созданием архитектуры и ее реализацией.
Аналогично обстоит дело и при проектировании систем программирования. Задолго до того, как завершены спецификации, у разработчика уже много дел. Обладая некоторыми приблизительными сведениями о функциях системы, которые получат свое отражение во внешних спецификациях, он уже может действовать. Он должен точно знать поставленные ему сроки и отведенные средства. Он должен знать машину, на которой будут пропускаться его программы. Далее он может приступить к разработке сопряжения модулей, структуры таблиц, алгоритмов, распределению работы по фазам. Некоторое время следует затратить на установление контактов с архитекторами.
Кроме того, и здесь на уровне реализации также много параллельной работы. В программировании тоже есть технология. Если машина новая, то предстоит большая работа с подпрограммами, супервизором, алгоритмами поиска и сортировки7).
Концептуальное единство действительно требует, чтобы система отражала единую философию и чтобы спецификации в том виде, в каком они доходят до пользователя, исходили от нескольких человек. Реалъное разделение труда на архитектуру, разработку и реализацию вовсе не означает, чуб на создание системы в целом, спроектированной таким образом, потребуется больше времени. Опыт показывает обратное, а именно, отдельные модули быстрее объединяются в систему, и на се отладку требуется меньше времени. Таким образом, широко распространенное горизонтальное разделение труда сокращается за счет вертикального разделения труда, при этом существенно упрощается обеспечение связи и повышается концептуальное единство проекта.
V. ЭФФЕКТ ВТОРОЙ СИСТЕМЫ
Если ответственность за функциональные спецификации отделить от ответственности за быстрое создание дешевого конечного продукта, то как поставить пределы творческому энтузиазму архитектора?
Фундаментальное решение этой проблемы заключается в установлении тесной, последовательной и основанной на симпатиях связи между архитектором и разработчиком. Но есть и более тонкий ее аспект, обычно ускользающий от нашего внимания.
Принципы совместной работы
Архитектор сооружения занимается финансовой сметой, используя собственные методы оценки, которые позже утверждаются подрядчиком, или же последний вносит в них свои коррективы. Часто оказывается, что величина затрат, определяемая подрядчиком, не укладывается в смету. Архитектору приходится тогда пересматривать свои методы оценки с точки зрения увеличения сметы и свой проект с точки зрения его удешевления. Однако он может предложить подрядчикам способы более дешевой реализации проекта, чем разработанные ими.
В аналогичной ситуации находится архитектор вычислительной системы или системы программирования. Он обладает, однако, тем преимуществом, что подрядчики сообщают ему свои цены на гораздо более ранних этапах проекта: ахитектор может практически в любой момент потребовать от них сведения о затратах. Но он обычно испытывает неудобства из-за необходимости работать только с одним подрядчиком, который может повышать или понижать свои цены в зависимости от степени удовлетворенности проектом. На практике ранняя и постоянная связь помогает архитектору иметь нужные данные о затратах, а разработчику - осуществлять непосредственное знакомство с проектом, при этом/различия в обязанностях не стираются.
Если архитектор оказался перед проблемой завышенных оценок, у него два выхода: урезать проект пли оспорить оценки, предложив более дешевую реализацию. Последний путь эмоционально очень опасен. Архитектор оспаривает метод выполнения работы строителя, предложенный самим строителем. Чтобы он привел к успеху, архитектор должен:
* помнить, что строитель несет творческую ответственность за реализацию, поэтому архитектор предлагает, но не приказывает;
* быть готовым к тому, чтобы предложить свой способ реализации продукта, спецификацию которого он написал, \i к тому, чтобы принять любой другой способ, если последний отвечает поставленным задачам;
* выдвигать такие предложения спокойно, в узком кругу;
* уметь отказываться от предлагаемых улучшенхщ. Обычно строитель начинает противиться предлагаемым изменениям в архитектуре. И зачастую он прав - какая-нибудь незначительная деталь может оказаться неожиданно дорогой в процессе реализации.
Самодисциплина. Эффект второй системы
В своей первой работе архитектор обычно проявляет умеренность и аккуратность. Он знает, что он не знает того, что делает, а потому делает это тщательно и держит себя "в рамках".
В процессе работы над своим первым проектом ему приходят па ум всякого рода находки и украшательства. Все они откладываются "до следующего раза". Рано или поздно работа над первой системой приходит к концу, и архитектор, преисполненный уверенности и продемонстрировавший свое мастерство на системах этого класса, готов заняться второй системой.
Эта вторая система - самая опасная из всех, которые когда-либо проектирует человек. Когда он будет делать следующие, опыт прежних разработок позволит ему установить общие характеристики таких систем, а различия между ними укажут на конкретные детали, не обобщаемые и не распространяющиеся на все системы.
Общая тенденция Заключается в создании сверхпроекта второй системы, путем использования всех идей и находок, от которых предусмотрительно отказались в первой. В результате, как сказал Овидии, получается "большая куча". Рассмотрим в качестве примера архитектуру ЭВМ IBM-709, позже воплотившуюся в модели IBM-7090. Это - вторая система по отношению к очень удачной IBM-704. Набор операций в модели IBM-709 настолько велик и разнообразен, что едва ли половина из них регулярно используется.
Еще более убедительный пример являет собой архитектура, разработка и даже реализация вычислительной машины Stretch, в которых нашли выход ранее сдерживаемые стремления многих людей к изобретательству, и которая была второй системой для большинства из них. Как говорит Стрейчив своем обзоре, "у меня создалось впечатление, что в известном смысле проект Stretch последнее звено в цепи развития. Как и некоторые предыдущие разработки, он в высшей степени хитроумен, в высшей степени усложнен, крайне эффективен, но в то же самое время он в чем-то не продуман, расточителен и неэлегантен, и чувствуется, что существуют гораздо лучшие способы создания таких вещей))1).
Операционная система OS/360 была второй системой для большинства ее разработчиков. В этот коллектив вошли создатели таких разных проектов, как операционная система DOS/1410-7010, операционная система Stretch, система реального времени в проекте Mercury и IBSYS для IBM-7090. Но почти никто из них не имел опыта создания двух операционных систем 2). Таким образом, OS/360 - это чистый пример эффекта второй системы, своего рода stretch*) в искусстве системного программирования, и к ней равно относятся и похвалы, и порицания Стрейчи.
Например, в OS/360 отводится 26 байтов оперативной памяти для постоянно хранящейся в ней программы, предназначенной для обработки даты "31 декабря" в високосном году (когда 366 дней). А это можно было бы оставить оператору.
Эффект второй системы имеет и другое проявление, отличное от чисто функциональных украшательств. Это - тенденция к усовершенствованию методов, само существование /которых становится ненужным из-за изменений /в исходных посылках системы. OS/360 может /^ать много примеров такого рода. //
Рассмотрим редактор связей, предназначенный для загрузки отдельно оттранслированных программ и обработки перекрестных ссылок. Кроме своих основных функций, он осуществляет также статистическую сегментацию программы. Это - одно из самых лучших средств сегментации, когда-либо придуманных. Оно позволяет осуществлять внешнюю сегментацию во время работы редактора связей, а не вводить ее в исходную машинную программу, что дает возможность менять структуру сегментов от прогона к прогону без повторной трансляции. Тем самым обеспечивается богатый набор полезных вариантов и возможностей. В определенном смысле это - кульминация развития метода статистической сегментации.
Но одовременно это и последний из динозавров. Дело в том, что это средство принадлежит системе, в которой мультипрограммирование является нормальным режимом работы, а динамическое распределение памяти - исходной посылкой, что находится в прямом противоречии с идеей использования статистической сегментации. Насколько лучше работала бы система, если усилия, затраченные на управление сегментацией, были бы направлены на то, чтобы осуществлять динамическое распределение памяти и динамические перекрестные ссылки по-настоящему быстро.
Далее, сам редактор связей требует такого большого объема памяти и содержит так много своих собственных сегментов, что если даже использовать его только для связи без управления сегментацией, то он работает медленнее большинства трансляторов. По иронии судьбы, сам редактор связей создавался для того, чтобы избежать ретрансляции. Как у конькобежца туловище опережает ноги, так и усовершенствования продолжаются до тех пор, пока исходные посылки системы не останутся позади.
Другим примером этой тенденции служит средство отладки Testran. Это высшая точка развития средст пакетной отладки, обладающая действительно элегантными возможностями моментальной выдачи и распечатки памяти. Testran использует концепцию управляющей секции и простой\метод избирательной трассировки и получения выдач\ памяти без накладных расходов или ретрансляции. Творческие концепции операционной системы Share для IBM-709 расцвели здесь пышным цветом3). Тем временем сама идея отладки в пакетном режиме без ретрансляции устарела. Диалоговые вычислительные системы,\ используя языковые интерпретаторы или интерпретирующие компиляторы, обеспечили наиболее фундаментальные преимущества. Но даже в системах пакетной обработки появление "быстро транслирующих-медленно выполняющих" трансляторов привело к тому, что предпочтение стало отдаваться методам отладки и выдачам памяти па внешнем уровне. Насколько лучше была бы система, если вместо создания Testran'a все усилия были бы направлены на разработку диалоговых средств и быстрой трансляции.
Еще одним аналогичным примером является планировщик, обеспечивающий превосходные возможности управления фиксированным потоком задач в пакетном режиме. На самом деле этот планировщик представляет собой улучшенную, усовершенствованную и приукрашенную вторую систему, созданную вслед за операционной системой DOS/1410-7010. Это - система пакетной обработки, не мультипрограммная, за исключением ввода/вывода, и предназначенная в основном для коммерческих приложений. В этом качестве планировщик OS/360 хорош. Но он почти совсем не удовлетворяет потребностям дистанционного ввода задач, мультипрограммирования и резидентных диалоговых подсистем, реализованным в OS/360.
Как архитектору избежать эффекта второй системы? Очевидно, что просто перескочить через свою вторую систему ему не удастся. Но он может помнить об опасностях этой системы и повысить самодисциплину с тем, чтобы уметь отказаться от функциональных излишеств и избежать экстраполяции тех функций, которые не сохраняются при изменении основных идей и назначения системы.
Чтобы не потерять бдительности, советуем архитектору присвоить каждой, даже самой малой, функции следующий показатель: средство х должно стоить не больше, чем т байтов памяти и п микросекунд.
Эти показатели подскажут исходные решения и в процессе реализации будут и указанием, и предостережением.
Как руководитель проекта может избежать эффекта второй системы? Во-первых, он должен проследить за тем, чтобы для главного архитектора эта система была, по меньшей мере, третьей. Кроме того, руководитель, зная о соблазнах, может вовремя проверить, насколько полно исходные концепции и поставленные задачи нашли свое отражение в подробно разработанном проекте.
VI. ПУТЬ СЛОВА
"Он сядет здесь и будет распоряжатъся: Сделайте то! Сделайте это!-- Но абсолютно ничто не сдвинется с места".
(Г. С. Т р у м е н. "О президентской власти")
Допустим, что в распоряжении руководителя есть несколько дисциплинированных и опытных архитекторов и большой коллектив разработчиков. Как руководитель сможет добиться того, чтобы все разработчики услышали, поняли и реализовали решения, предложенные архитекторами? Каким образом группа из 10 архитекторов сможет обеспечить концептуальное единство системы, которую создают 1000 человек? Целая технология, позволяющая это осуществить, была разработана для проекта Системы 360, и она равно приложима к проектам создания программного обеспечения.
Письменные спецификации - руководство
Руководство, пли письменная спецификация, является необходимым инструментом, хотя п недостаточным. Руководство - это внешняя спецификация конечного продукта. Оно описывает каждый элемент системы с точки зрения пользователя и предписывает его поведение. И как таковое представляет собой основной результат работы архитектора.
Круг за кругом проходит процесс его подготовки, и в это время обратная связь с пользователями и разработчиками показывает, где проект неудобен для использования или реализации. Для разработчиков важно, чтобы все изменения квантовались, т. е. в графике отмечались датированные версии.
Руководство должно описывать только все то, что видит пользователь, в том числе все сопряжения; оно не должно содержать описания того, что не видно пользователю. Этим занимается разработчик, и здесь его творческая свобода не должна ничем сковываться. Архитектор всегда должен быть готов -показать пример реализации того свойства, которое он описывает, но ему не следует и пытаться навязывать конкретную реализацию.
Концептуальное единство, в свою очередь, требует, чтобы весь проект исходил из одной головы, или же из нескольких, работающих в полном согласии.
Однако график требует, чтобы система создавалась многими людьми. Существуют два метода решения этой дилеммы. Первый - это тщательное разделение труда между разработкой архитектуры и реализацией системы. Второй - это новый способ организации коллективов программистов, предложенный выше.
Отделение архитектурных проблем от реализации является весьма эффективным путем достижения концептуального единства очень больших проектов. Я убедился в этом на примере успешного создания фирмой IBM вычислительной машины Stretch и промышленной серии ЭВМ Системы 360.
Отсутствие такого подхода сказалось при разработке операционной системы OS/360.
Под архитектурой системы я понимаю полную и подробную спецификацию ее сопряжения с пользователем. Для вычислительной машины это руководство по программированию. Для транслятора - руководство по входному языку. Для управляющей программы - руководство по одному или нескольким языкам, используемым для обращения к ее функциям. Для системы в целом - это объединение всех тех руководств, к которым должен обращаться пользователь, чтобы решить свою задачу.
Архитектор системы, как и архитектор, проектирующий здание,- агент пользователя. Его работа заключается в том, чтобы использовать свои профессиональные и технические знания исключительно в интересах пользователя, в противоположность интересам коммивояжера, производителя и т. д.2).
Необходимо тщательно отделять архитектуру от реализации. Как сказал Блау, "Там, где архитектура говорит, что происходит, разработка говорит, как это должно происходить"3). В качестве простого примера он приводит часы, архитектура которых - циферблат, стрелки и головка завода. Когда ребенок познакомится с этой архитектурой, он с одинаковой легкостью сможет определять время как по ручным часам, так и по башенным курантам. Разработка и реализация, однако, каждый раз описывают внутреннюю структуру механизмы, приводящие часы в действие и обеспечивающие точность хода.
В Системе 360, например, одна машинная архитектура реализована совершенно по-разному в каждой из девяти моделей, и наоборот, одна реализация, средства обмена, память и микропрограммы модели 360/30 используются в четырех различных архитектурах: серия ЭВМ Системы 360, мультиплексный канал с 224 логическими независимыми подканалами, селекторный канал и вычислительная машина IBM-14014).
Такое разграничение в равной степени применимо и к системам программирования. Существует стандартный фортран IV. Он является архитектурой для многих трансляторов. В рамках этой архитектуры возможны самые различные реализации: программа в оперативной памяти пли транслятор в оперативной памяти, быстрая трансляция или оптимизация, синтаксически ориентированный или "прямой" транслятор. Подобным образом любой язык ассемблера или язык управления задачами допускает разные реализации ассемблера или планировщика.
Теперь мы обратимся к более эмоциональной стороне проблемы: аристократия против демократии. Разве не образуют архитекторы своего рода аристократию, интеллектуальную элиту, которая указывает разработчикам, что им следует делать? Не отбирает ли эта элита всю творческую работу, отводя разработчикам роль "винтиков"? Может быть, конечный продукт улучшится, если, следуя принципам демократии, позволить всему коллективу генерировать идеи, а не ограничиваться спецификациями, разработанными всего несколькими людьми?
Последний вопрос самый легкий. Я, естественно, не собираюсь настаивать на том, что только у архитекторов могут быть хорошие архитектурные идеи. Довольно часто свежая мысль исходит от разработчика пли от пользователя. Однако весь мой опыт убеждает меня в том, что именно концептуальное единство системы определяет легкость ео использования, и я попытаюсь это показать. Предлагаемые средства и идеи сами по себе могут быть очень хороши, но если они не составляют единого целого с основными концепциями системы, от них лучше отказаться. Если же таких отличных, но несовместимых идей оказалось много, остается только выбросить в мусорную корзинку всю систему и заняться созданием новой, обладающей единством и построенной на других основных идеях.
Что касается вопроса о появлении новой аристократии, то следует ответить и да, и нет.
Да - в том смысле, что архитекторов всегда немного, а конечный продукт их деятельности живет дольше, чем результаты труда разработчиков, и архитектор находится в центре всех усилий по проектированию системы, защищая интересы пользователей. Если система должна обладать концептуальным единством, то необходим кто-то, следящий за этими концепциями. Это и есть та аристократия, которая не нуждается в извинениях.
Нет - потому что разработка внешних спецификаций - ничуть не более творческая работа, чем разработка проектов. Просто это другая работа. Разработка проекта, если архитектура уже имеется, требует от исполнителей и позволяет им в той же мере проявлять творческие способности и выдавать новые идеи, как и создание внешних спецификаций. По существу отношение стоимости продукта к его производительности в основном зависит от разработчика, в то время как простота пользования зависит от архитектора.
Существует множество примеров из других областей искусства и ремесла, заставляющих поверить в то, что дисциплина полезна. Как утверждает афоризм, распространенный среди художников, "форма освобождает". Хуже всего получаются сооружения, бюджет которых -больше, чем это нужно для достижения поставленной цели. Вряд ли необходимость каждую неделю писать по кантате отрицательно сказывалась на творческих возможностях Баха. Я уверен, что архитектура вычислительной машины Stretch много выиграла бы от введения более строгих ограничений; так, ограничения, накладываемые бюджетом модели 30 Системы 360, по моему мнению, положительно сказались на архитектуре модели 75. Аналогично я подметил, что заданная архитектура повышает, а не подавляет творческие возможности группы разработчиков. Они сразу же сосредоточиваются на той части проблемы, которой еще не занимались, и в результате появляются творческие находки. Если же на работу группы не накладывается никаких ограничений, то много времени и усилий, размышлений и обсуждений уйдет на архитектурные решения, а с самой реализацией они справятся очень быстро5).
Существование этого эффекта, который я наблюдал неоднократно, подтверждает Р. Конвей - руководитель группы, создавшей транслятор PL/G с языка PL/I в Корнелльском университете. Он говорит: "В конце концов, мы решили реализовать язык без всяких изменений и улучшений, потому что дебаты по этому вопросу отняли бы у нас все силы"6).
Чем может заполнить разработчик период ожидания?
Ошибка, стоимостью в несколько миллионов долларов, служит очень горестным уроком, но запоминается надолго. Я живо помню тот вечер, когда мы принимали решение о написании внешних спецификации для OS/360. Руководитель группы архитекторов ЭВМ, руководитель отдела разработки управляющих программ и я бились над планом, графиком и распределением обязанностей.
В группе архитекторов было 10 отличных специалистов. Ее руководитель утверждал, что они могут написать спецификации, и сделают это хорошо. Но на это потребуется 10 месяцев, на три месяца больше, чем допускал график.
В отделе управляющих программ было 150 человек. Ее руководитель говорил, что, взаимодействуя с архитекторами, они смогут подготовить практичные спецификации высокого качества и при этом уложиться в график. Если же этим займутся архитекторы, то его 150 человек будут десять месяцев бить баклуши.
На это архитектор отвечал, что если я поручу написание спецификаций отделу управляющих программ, то мы не только не дождемся результатов вовремя, но получим их на три месяца позже и они окажутся гораздо хуже. Так ц получилось. Архитектор был прав во всех отношениях. Кроме того, отсутствие концептуального единства увеличило стоимость создания и модификации системы п, по моим оценкам, удлинило срок отладки по меньшей мере па год.
Много факторов, конечно, повлияло на принятие этого ошибочного решения, но главными были график п желание дать работу 150 разработчикам. Сирены пели мне именно эту песню, ц теперь-то я вижу всю ее смертельную опасность.
Когда речь заходит о том, чтобы поручить маленькой группе архитекторов создание всех внешних спецификаций для вычислительной машины или системы программирования, разработчики выдвигают три возражения:
* спецификации будут слишком разнообразны по функциям, но не учтут практическую стоимость реализации;
* архитекторы сделают всю творческую часть работы, лишив разработчиков возможности что-либо придумать самим;
* большому числу разработчиков придется простаивать, в то время как спецификации будут проходить через игольное ушко, называемое группой архитекторов.
Первое представляет реальную опасность и подробнее будет рассматриваться в следующей главе. Два других возражения - не более, чем мираж. Как мы уже убедились, разработка - тоже творческая деятельность. Возможности для творчества и проявления изобретательности при разработке не уменьшаются сколько-нибудь значительно из-за необходимости работать с заданными внешними спецификациями, а степень проявления творческой активности может даже возрасти благодаря дисциплине. Конечный же продукт, вне всякого сомнения, от этого только выиграет.
Последнее возражение касается распределения времени и этапов работы. Первый ответ, приходящий на ум, заключается в том, что не нужно нанимать разработчиков до тех пор, пока не будут готовы спецификации. Именно так поступают при строительстве здания.
Однако в системном программировании темпы выше и график очень уплотнен. Насколько можно совместить этапы создания спецификаций и самого строительства?
Как подчеркивает Блау, в творческой деятельности выделяются три различные этапа: архитектура, разработка и реализация. На практике оказывается, что все этапы могут начинаться одновременно и проходить параллельно.
При проектировании вычислительной машины, например, разработчик уже может начинать работу, даже если он имеет довольно смутные представления о принципах действия, несколько более ясные технологические идеи и четко определенные понятия о стоимости и производительности. Он может начать проектировать информационные связи, управляющие последовательности, принципы компоновки п т. д. Он придумывает пли совершенствует средства, которые ему потребуются, особенно систему документирования, включая систему автоматизации проектирования.
Одновременно может проходить разработка и устранение недостатков у интегральных схем, плат, кабелей, стоек, источников питания, запоминающих устройств и т. д., и составляться документация для них.
Эта работа выполняется параллельно с созданием архитектуры и ее реализацией.
Аналогично обстоит дело и при проектировании систем программирования. Задолго до того, как завершены спецификации, у разработчика уже много дел. Обладая некоторыми приблизительными сведениями о функциях системы, которые получат свое отражение во внешних спецификациях, он уже может действовать. Он должен точно знать поставленные ему сроки и отведенные средства. Он должен знать машину, на которой будут пропускаться его программы. Далее он может приступить к разработке сопряжения модулей, структуры таблиц, алгоритмов, распределению работы по фазам. Некоторое время следует затратить на установление контактов с архитекторами.
Кроме того, и здесь на уровне реализации также много параллельной работы. В программировании тоже есть технология. Если машина новая, то предстоит большая работа с подпрограммами, супервизором, алгоритмами поиска и сортировки7).
Концептуальное единство действительно требует, чтобы система отражала единую философию и чтобы спецификации в том виде, в каком они доходят до пользователя, исходили от нескольких человек. Реалъное разделение труда на архитектуру, разработку и реализацию вовсе не означает, чуб на создание системы в целом, спроектированной таким образом, потребуется больше времени. Опыт показывает обратное, а именно, отдельные модули быстрее объединяются в систему, и на се отладку требуется меньше времени. Таким образом, широко распространенное горизонтальное разделение труда сокращается за счет вертикального разделения труда, при этом существенно упрощается обеспечение связи и повышается концептуальное единство проекта.
V. ЭФФЕКТ ВТОРОЙ СИСТЕМЫ
Если ответственность за функциональные спецификации отделить от ответственности за быстрое создание дешевого конечного продукта, то как поставить пределы творческому энтузиазму архитектора?
Фундаментальное решение этой проблемы заключается в установлении тесной, последовательной и основанной на симпатиях связи между архитектором и разработчиком. Но есть и более тонкий ее аспект, обычно ускользающий от нашего внимания.
Принципы совместной работы
Архитектор сооружения занимается финансовой сметой, используя собственные методы оценки, которые позже утверждаются подрядчиком, или же последний вносит в них свои коррективы. Часто оказывается, что величина затрат, определяемая подрядчиком, не укладывается в смету. Архитектору приходится тогда пересматривать свои методы оценки с точки зрения увеличения сметы и свой проект с точки зрения его удешевления. Однако он может предложить подрядчикам способы более дешевой реализации проекта, чем разработанные ими.
В аналогичной ситуации находится архитектор вычислительной системы или системы программирования. Он обладает, однако, тем преимуществом, что подрядчики сообщают ему свои цены на гораздо более ранних этапах проекта: ахитектор может практически в любой момент потребовать от них сведения о затратах. Но он обычно испытывает неудобства из-за необходимости работать только с одним подрядчиком, который может повышать или понижать свои цены в зависимости от степени удовлетворенности проектом. На практике ранняя и постоянная связь помогает архитектору иметь нужные данные о затратах, а разработчику - осуществлять непосредственное знакомство с проектом, при этом/различия в обязанностях не стираются.
Если архитектор оказался перед проблемой завышенных оценок, у него два выхода: урезать проект пли оспорить оценки, предложив более дешевую реализацию. Последний путь эмоционально очень опасен. Архитектор оспаривает метод выполнения работы строителя, предложенный самим строителем. Чтобы он привел к успеху, архитектор должен:
* помнить, что строитель несет творческую ответственность за реализацию, поэтому архитектор предлагает, но не приказывает;
* быть готовым к тому, чтобы предложить свой способ реализации продукта, спецификацию которого он написал, \i к тому, чтобы принять любой другой способ, если последний отвечает поставленным задачам;
* выдвигать такие предложения спокойно, в узком кругу;
* уметь отказываться от предлагаемых улучшенхщ. Обычно строитель начинает противиться предлагаемым изменениям в архитектуре. И зачастую он прав - какая-нибудь незначительная деталь может оказаться неожиданно дорогой в процессе реализации.
Самодисциплина. Эффект второй системы
В своей первой работе архитектор обычно проявляет умеренность и аккуратность. Он знает, что он не знает того, что делает, а потому делает это тщательно и держит себя "в рамках".
В процессе работы над своим первым проектом ему приходят па ум всякого рода находки и украшательства. Все они откладываются "до следующего раза". Рано или поздно работа над первой системой приходит к концу, и архитектор, преисполненный уверенности и продемонстрировавший свое мастерство на системах этого класса, готов заняться второй системой.
Эта вторая система - самая опасная из всех, которые когда-либо проектирует человек. Когда он будет делать следующие, опыт прежних разработок позволит ему установить общие характеристики таких систем, а различия между ними укажут на конкретные детали, не обобщаемые и не распространяющиеся на все системы.
Общая тенденция Заключается в создании сверхпроекта второй системы, путем использования всех идей и находок, от которых предусмотрительно отказались в первой. В результате, как сказал Овидии, получается "большая куча". Рассмотрим в качестве примера архитектуру ЭВМ IBM-709, позже воплотившуюся в модели IBM-7090. Это - вторая система по отношению к очень удачной IBM-704. Набор операций в модели IBM-709 настолько велик и разнообразен, что едва ли половина из них регулярно используется.
Еще более убедительный пример являет собой архитектура, разработка и даже реализация вычислительной машины Stretch, в которых нашли выход ранее сдерживаемые стремления многих людей к изобретательству, и которая была второй системой для большинства из них. Как говорит Стрейчив своем обзоре, "у меня создалось впечатление, что в известном смысле проект Stretch последнее звено в цепи развития. Как и некоторые предыдущие разработки, он в высшей степени хитроумен, в высшей степени усложнен, крайне эффективен, но в то же самое время он в чем-то не продуман, расточителен и неэлегантен, и чувствуется, что существуют гораздо лучшие способы создания таких вещей))1).
Операционная система OS/360 была второй системой для большинства ее разработчиков. В этот коллектив вошли создатели таких разных проектов, как операционная система DOS/1410-7010, операционная система Stretch, система реального времени в проекте Mercury и IBSYS для IBM-7090. Но почти никто из них не имел опыта создания двух операционных систем 2). Таким образом, OS/360 - это чистый пример эффекта второй системы, своего рода stretch*) в искусстве системного программирования, и к ней равно относятся и похвалы, и порицания Стрейчи.
Например, в OS/360 отводится 26 байтов оперативной памяти для постоянно хранящейся в ней программы, предназначенной для обработки даты "31 декабря" в високосном году (когда 366 дней). А это можно было бы оставить оператору.
Эффект второй системы имеет и другое проявление, отличное от чисто функциональных украшательств. Это - тенденция к усовершенствованию методов, само существование /которых становится ненужным из-за изменений /в исходных посылках системы. OS/360 может /^ать много примеров такого рода. //
Рассмотрим редактор связей, предназначенный для загрузки отдельно оттранслированных программ и обработки перекрестных ссылок. Кроме своих основных функций, он осуществляет также статистическую сегментацию программы. Это - одно из самых лучших средств сегментации, когда-либо придуманных. Оно позволяет осуществлять внешнюю сегментацию во время работы редактора связей, а не вводить ее в исходную машинную программу, что дает возможность менять структуру сегментов от прогона к прогону без повторной трансляции. Тем самым обеспечивается богатый набор полезных вариантов и возможностей. В определенном смысле это - кульминация развития метода статистической сегментации.
Но одовременно это и последний из динозавров. Дело в том, что это средство принадлежит системе, в которой мультипрограммирование является нормальным режимом работы, а динамическое распределение памяти - исходной посылкой, что находится в прямом противоречии с идеей использования статистической сегментации. Насколько лучше работала бы система, если усилия, затраченные на управление сегментацией, были бы направлены на то, чтобы осуществлять динамическое распределение памяти и динамические перекрестные ссылки по-настоящему быстро.
Далее, сам редактор связей требует такого большого объема памяти и содержит так много своих собственных сегментов, что если даже использовать его только для связи без управления сегментацией, то он работает медленнее большинства трансляторов. По иронии судьбы, сам редактор связей создавался для того, чтобы избежать ретрансляции. Как у конькобежца туловище опережает ноги, так и усовершенствования продолжаются до тех пор, пока исходные посылки системы не останутся позади.
Другим примером этой тенденции служит средство отладки Testran. Это высшая точка развития средст пакетной отладки, обладающая действительно элегантными возможностями моментальной выдачи и распечатки памяти. Testran использует концепцию управляющей секции и простой\метод избирательной трассировки и получения выдач\ памяти без накладных расходов или ретрансляции. Творческие концепции операционной системы Share для IBM-709 расцвели здесь пышным цветом3). Тем временем сама идея отладки в пакетном режиме без ретрансляции устарела. Диалоговые вычислительные системы,\ используя языковые интерпретаторы или интерпретирующие компиляторы, обеспечили наиболее фундаментальные преимущества. Но даже в системах пакетной обработки появление "быстро транслирующих-медленно выполняющих" трансляторов привело к тому, что предпочтение стало отдаваться методам отладки и выдачам памяти па внешнем уровне. Насколько лучше была бы система, если вместо создания Testran'a все усилия были бы направлены на разработку диалоговых средств и быстрой трансляции.
Еще одним аналогичным примером является планировщик, обеспечивающий превосходные возможности управления фиксированным потоком задач в пакетном режиме. На самом деле этот планировщик представляет собой улучшенную, усовершенствованную и приукрашенную вторую систему, созданную вслед за операционной системой DOS/1410-7010. Это - система пакетной обработки, не мультипрограммная, за исключением ввода/вывода, и предназначенная в основном для коммерческих приложений. В этом качестве планировщик OS/360 хорош. Но он почти совсем не удовлетворяет потребностям дистанционного ввода задач, мультипрограммирования и резидентных диалоговых подсистем, реализованным в OS/360.
Как архитектору избежать эффекта второй системы? Очевидно, что просто перескочить через свою вторую систему ему не удастся. Но он может помнить об опасностях этой системы и повысить самодисциплину с тем, чтобы уметь отказаться от функциональных излишеств и избежать экстраполяции тех функций, которые не сохраняются при изменении основных идей и назначения системы.
Чтобы не потерять бдительности, советуем архитектору присвоить каждой, даже самой малой, функции следующий показатель: средство х должно стоить не больше, чем т байтов памяти и п микросекунд.
Эти показатели подскажут исходные решения и в процессе реализации будут и указанием, и предостережением.
Как руководитель проекта может избежать эффекта второй системы? Во-первых, он должен проследить за тем, чтобы для главного архитектора эта система была, по меньшей мере, третьей. Кроме того, руководитель, зная о соблазнах, может вовремя проверить, насколько полно исходные концепции и поставленные задачи нашли свое отражение в подробно разработанном проекте.
VI. ПУТЬ СЛОВА
"Он сядет здесь и будет распоряжатъся: Сделайте то! Сделайте это!-- Но абсолютно ничто не сдвинется с места".
(Г. С. Т р у м е н. "О президентской власти")
Допустим, что в распоряжении руководителя есть несколько дисциплинированных и опытных архитекторов и большой коллектив разработчиков. Как руководитель сможет добиться того, чтобы все разработчики услышали, поняли и реализовали решения, предложенные архитекторами? Каким образом группа из 10 архитекторов сможет обеспечить концептуальное единство системы, которую создают 1000 человек? Целая технология, позволяющая это осуществить, была разработана для проекта Системы 360, и она равно приложима к проектам создания программного обеспечения.
Письменные спецификации - руководство
Руководство, пли письменная спецификация, является необходимым инструментом, хотя п недостаточным. Руководство - это внешняя спецификация конечного продукта. Оно описывает каждый элемент системы с точки зрения пользователя и предписывает его поведение. И как таковое представляет собой основной результат работы архитектора.
Круг за кругом проходит процесс его подготовки, и в это время обратная связь с пользователями и разработчиками показывает, где проект неудобен для использования или реализации. Для разработчиков важно, чтобы все изменения квантовались, т. е. в графике отмечались датированные версии.
Руководство должно описывать только все то, что видит пользователь, в том числе все сопряжения; оно не должно содержать описания того, что не видно пользователю. Этим занимается разработчик, и здесь его творческая свобода не должна ничем сковываться. Архитектор всегда должен быть готов -показать пример реализации того свойства, которое он описывает, но ему не следует и пытаться навязывать конкретную реализацию.