Если ответственность за функциональные спецификации отделить от ответственности за быстрое создание дешевого конечного продукта, то как поставить пределы творческому энтузиазму архитектора?
Фундаментальное решение этой проблемы заключается в установлении тесной, последовательной и основанной на симпатиях связи между архитектором и разработчиком. Но есть и более тонкий ее аспект, обычно ускользающий от нашего внимания.
Принципы совместной работы
Архитектор сооружения занимается финансовой сметой, используя собственные методы оценки, которые позже утверждаются подрядчиком, или же последний вносит в них свои коррективы. Часто оказывается, что величина затрат, определяемая подрядчиком, не укладывается в смету. Архитектору приходится тогда пересматривать свои методы оценки с точки зрения увеличения сметы и свой проект с точки зрения его удешевления. Однако он может предложить подрядчикам способы более дешевой реализации проекта, чем разработанные ими.
В аналогичной ситуации находится архитектор вычислительной системы или системы программирования. Он обладает, однако, тем преимуществом, что подрядчики сообщают ему свои цены на гораздо более ранних этапах проекта: ахитектор может практически в любой момент потребовать от них сведения о затратах. Но он обычно испытывает неудобства из-за необходимости работать только с одним подрядчиком, который может повышать или понижать свои цены в зависимости от степени удовлетворенности проектом. На практике ранняя и постоянная связь помогает архитектору иметь нужные данные о затратах, а разработчику - осуществлять непосредственное знакомство с проектом, при этом/различия в обязанностях не стираются.
Если архитектор оказался перед проблемой завышенных оценок, у него два выхода: урезать проект пли оспорить оценки, предложив более дешевую реализацию. Последний путь эмоционально очень опасен. Архитектор оспаривает метод выполнения работы строителя, предложенный самим строителем. Чтобы он привел к успеху, архитектор должен:
помнить, что строитель несет творческую ответственность за реализацию, поэтому архитектор предлагает, но не приказывает;
быть готовым к тому, чтобы предложить свой способ реализации продукта, спецификацию которого он написал, \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.
Как архитектору избежать эффекта второй системы? Очевидно, что просто перескочить через свою вторую систему ему не удастся. Но он может помнить об опасностях этой системы и повысить самодисциплину с тем, чтобы уметь отказаться от функциональных излишеств и избежать экстраполяции тех функций, которые не сохраняются при изменении основных идей и назначения системы. Чтобы не потерять бдительности, советуем архитектору присвоить каждой, даже самой малой, функции следующий показатель: средство х должно стоить не больше, чем т байтов памяти и п микросекунд.
Эти показатели подскажут исходные решения и в процессе реализации будут и указанием, и предостережением.
Как руководитель проекта может избежать эффекта второй системы? Во-первых, он должен проследить за тем, чтобы для главного архитектора эта система была, по меньшей мере, третьей. Кроме того, руководитель, зная о соблазнах, может вовремя проверить, насколько полно исходные концепции и поставленные задачи нашли свое отражение в подробно разработанном проекте.