Чтение онлайн

(Путеводитель по Рейнскому Собору)

Концептуальное единство

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

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

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

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

В этой и двух последующих главах мы рассмотрим именно эту сторону создания систем программирования и попытаемся ответить на вопросы:

* Как добиться концептуального единства проекта?

* Не подразумевает ли такая постановка проблемы деления на элиту, т. е. аристократов-архитекторов, и серую массу плебеев-программистов, творческие таланты и идеи которых всячески подавляются?

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

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

Как добиться концептуального единства

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

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

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

Заблуждения на этот счет распространены чрезвычайно широко. Создатели операционной системы OS/360 объявили ее лучшей из всех существующих на том основании, что она выполняет больше всех функций. Функциональные возможности, а не простота, всегда считались критерием ее качества. С другой стороны, система разделения времени для PDP-10 провозглашалась ее создателями наилучшей именно из-за ее простоты п немногочисленности идей, на которых она основывается. Однако по своим функциям система PDP-10 не может быть отнесена к тому же классу, что п OS/360. Коль скоро в качестве критерия выбирается простота в пользовании, то обе эти системы соответствуют идеалу только наполовину.

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

Аристократия и демократия

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

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

Отделение архитектурных проблем от реализации является весьма эффективным путем достижения концептуального единства очень больших проектов. Я убедился в этом на примере успешного создания фирмой IBM вычислительной машины Stretch и промышленной серии ЭВМ Системы 360.

Отсутствие такого подхода сказалось при разработке операционной системы OS/360.

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

Архитектор системы, как и архитектор, проектирующий здание,- агент пользователя. Его работа заключается в том, чтобы использовать свои профессиональные и технические знания исключительно в интересах пользователя, в противоположность интересам коммивояжера, производителя и т. д.2).

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