Страница 7 из 28
Пользование облегчается, если время, выигранное благодаря функциональным возможностям, больше времени, потерянного на изучение, запоминание и поиски в руководствах. В современных системах программирования этот выигрыш - больше затрат, хотя за последнее время отношение выигрыша к затратам уменьшилось в связи с появлением все более сложных функций. Я все еще вспоминаю, как просто было работать на машине IBM-650, даже без ассемблера и вообще без какого бы то ни было программного обеспечения.
Поскольку простота пользования - основная цель при проектировании, то соотношение между функциональными возможностями и концептуальной сложностью является высшим критерием системного проекта. Ни функциональность, ни простота сами по себе не гарантируют его высокого качества.
Заблуждения на этот счет распространены чрезвычайно широко. Создатели операционной системы OS/360 объявили ее лучшей из всех существующих на том основании, что она выполняет больше всех функций. Функциональные возможности, а не простота, всегда считались критерием ее качества. С другой стороны, система разделения времени для PDP-10 провозглашалась ее создателями наилучшей именно из-за ее простоты п немногочисленности идей, на которых она основывается. Однако по своим функциям система PDP-10 не может быть отнесена к тому же классу, что п OS/360. Коль скоро в качестве критерия выбирается простота в пользовании, то обе эти системы соответствуют идеалу только наполовину.
На заданном уровне функциональных возможностей следует, однако, признать наилучшей ту систему, в которой различные задания выражаются с максимальной простотой п непосредственностью. Только простоты недостаточно. Язык TRAC, разработанный Муерсом, и алгол-68 достигли простоты, если ее измерять числом различных элементарных понятий. Однако они не обладают непосредственностью. Для выражения требуемых функций там зачастую используются весьма неожиданные и запутанные комбинации основных средств. Недостаточно выучить только элементы и правила их сочетания; необходимо знать также случаи идиоматического употребления, целый свод сведений о том, как элементы сочетаются на практике. Простота и непосредственность вытекают из концептуального единства. Каждая часть должна следовать одним п тем же принципам и одной и той же балансировке наших потребностей. Каждая часть должна использовать одну и ту же технику синтаксиса и одинаковые понятия в семантике. Таким образом, простота в пользовании диктует требования единообразия, т. е. концептуального единства при проектировании.
Аристократия и демократия
Концептуальное единство, в свою очередь, требует, чтобы весь проект исходил из одной головы, или же из нескольких, работающих в полном согласии.
Однако график требует, чтобы система создавалась многими людьми. Существуют два метода решения этой дилеммы. Первый - это тщательное разделение труда между разработкой архитектуры и реализацией системы. Второй - это новый способ организации коллективов программистов, предложенный выше.
Отделение архитектурных проблем от реализации является весьма эффективным путем достижения концептуального единства очень больших проектов. Я убедился в этом на примере успешного создания фирмой IBM вычислительной машины Stretch и промышленной серии ЭВМ Системы 360.
Отсутствие такого подхода сказалось при разработке операционной системы OS/360.
Под архитектурой системы я понимаю полную и подробную спецификацию ее сопряжения с пользователем. Для вычислительной машины это руководство по программированию. Для транслятора - руководство по входному языку. Для управляющей программы - руководство по одному или нескольким языкам, используемым для обращения к ее функциям. Для системы в целом - это объединение всех тех руководств, к которым должен обращаться пользователь, чтобы решить свою задачу.
Архитектор системы, как и архитектор, проектирующий здание,- агент пользователя. Его работа заключается в том, чтобы использовать свои профессиональные и технические знания исключительно в интересах пользователя, в противоположность интересам коммивояжера, производителя и т. д.2).
Необходимо тщательно отделять архитектуру от реализации. Как сказал Блау, "Там, где архитектура говорит, что происходит, разработка говорит, как это должно происходить"3). В качестве простого примера он приводит часы, архитектура которых - циферблат, стрелки и головка завода. Когда ребенок познакомится с этой архитектурой, он с одинаковой легкостью сможет определять время как по ручным часам, так и по башенным курантам. Разработка и реализация, однако, каждый раз описывают внутреннюю структуру механизмы, приводящие часы в действие и обеспечивающие точность хода.
В Системе 360, например, одна машинная архитектура реализована совершенно по-разному в каждой из девяти моделей, и наоборот, одна реализация, средства обмена, память и микропрограммы модели 360/30 используются в четырех различных архитектурах: серия ЭВМ Системы 360, мультиплексный канал с 224 логическими независимыми подканалами, селекторный канал и вычислительная машина IBM-14014).
Такое разграничение в равной степени применимо и к системам программирования. Существует стандартный фортран IV. Он является архитектурой для многих трансляторов. В рамках этой архитектуры возможны самые различные реализации: программа в оперативной памяти пли транслятор в оперативной памяти, быстрая трансляция или оптимизация, синтаксически ориентированный или "прямой" транслятор. Подобным образом любой язык ассемблера или язык управления задачами допускает разные реализации ассемблера или планировщика.
Теперь мы обратимся к более эмоциональной стороне проблемы: аристократия против демократии. Разве не образуют архитекторы своего рода аристократию, интеллектуальную элиту, которая указывает разработчикам, что им следует делать? Не отбирает ли эта элита всю творческую работу, отводя разработчикам роль "винтиков"? Может быть, конечный продукт улучшится, если, следуя принципам демократии, позволить всему коллективу генерировать идеи, а не ограничиваться спецификациями, разработанными всего несколькими людьми?
Последний вопрос самый легкий. Я, естественно, не собираюсь настаивать на том, что только у архитекторов могут быть хорошие архитектурные идеи. Довольно часто свежая мысль исходит от разработчика пли от пользователя. Однако весь мой опыт убеждает меня в том, что именно концептуальное единство системы определяет легкость ео использования, и я попытаюсь это показать. Предлагаемые средства и идеи сами по себе могут быть очень хороши, но если они не составляют единого целого с основными концепциями системы, от них лучше отказаться. Если же таких отличных, но несовместимых идей оказалось много, остается только выбросить в мусорную корзинку всю систему и заняться созданием новой, обладающей единством и построенной на других основных идеях.
Что касается вопроса о появлении новой аристократии, то следует ответить и да, и нет.
Да - в том смысле, что архитекторов всегда немного, а конечный продукт их деятельности живет дольше, чем результаты труда разработчиков, и архитектор находится в центре всех усилий по проектированию системы, защищая интересы пользователей. Если система должна обладать концептуальным единством, то необходим кто-то, следящий за этими концепциями. Это и есть та аристократия, которая не нуждается в извинениях.
Нет - потому что разработка внешних спецификаций - ничуть не более творческая работа, чем разработка проектов. Просто это другая работа. Разработка проекта, если архитектура уже имеется, требует от исполнителей и позволяет им в той же мере проявлять творческие способности и выдавать новые идеи, как и создание внешних спецификаций. По существу отношение стоимости продукта к его производительности в основном зависит от разработчика, в то время как простота пользования зависит от архитектора.
Существует множество примеров из других областей искусства и ремесла, заставляющих поверить в то, что дисциплина полезна. Как утверждает афоризм, распространенный среди художников, "форма освобождает". Хуже всего получаются сооружения, бюджет которых -больше, чем это нужно для достижения поставленной цели. Вряд ли необходимость каждую неделю писать по кантате отрицательно сказывалась на творческих возможностях Баха. Я уверен, что архитектура вычислительной машины Stretch много выиграла бы от введения более строгих ограничений; так, ограничения, накладываемые бюджетом модели 30 Системы 360, по моему мнению, положительно сказались на архитектуре модели 75. Аналогично я подметил, что заданная архитектура повышает, а не подавляет творческие возможности группы разработчиков. Они сразу же сосредоточиваются на той части проблемы, которой еще не занимались, и в результате появляются творческие находки. Если же на работу группы не накладывается никаких ограничений, то много времени и усилий, размышлений и обсуждений уйдет на архитектурные решения, а с самой реализацией они справятся очень быстро5).