Ты балда, Коломб, -
скажу по чести.
Что касается меня,
то я бы
лично -
я б Америку закрыл,
слегка почистил,
а потом
опять открыл -
вторично.
В.В. Маяковский "Христофор Коломб" (ПСС в 13-ти т., т. 7, с. 38)
Что такое "открытые системы", каждый, разумеется, понимает по-своему. Тем не менее многие согласятся, что одной из провозглашенных целей этого направления было обуздание гетерогенности, как аппаратной, так и программной. Здесь получены наиболее заметные результаты, позволившие, например, решить в достаточно общей постановке задачу организации распределенных вычислений в неоднородной среде. Однако всеобщее увлечение гетерогенностью имеет и оборотную сторону: на долгое время остались без должного внимания однородные программные конструкции, хотя именно они служат отправной точкой для дальнейшего продвижения в сторону открытости.
Главное, а может быть и единственное известное сегодня средство "открывания" систем - это стандартизация. Оформленные в соответствии с требованиями стандартов материалы приобретают необходимый запас однородности, позволяющий свободно манипулировать ими, успешно преодолевая враждебную гетерогенность среды. Иначе говоря, гетерогенные системы открыты ровно настолько, насколько они гомогенизированы.
Но представим себе, что все интересующие нас программные компоненты успешно стандартизованы, и попытаемся проследить их дальнейшую судьбу. Прежде всего каждый новый однородный компонент должен быть "принят на работу" операционной системой или системой программирования. И на этом шаге, когда, казалось бы, все трудности уже позади, возникают достаточно серьезные проблемы.
Открытость операционной системы
Возьмем, к примеру, широкораспространенную операционную систему MS DOS и ее оболочку Windows 3.11, и попытаемся проанализировать, как там поставлено дело в части подключения и отключения приложений. Иначе говоря, очевидным образом расширим толкование открытости системы, включив в него также и легкость перемещения приложения в обоих направлениях: пусть теперь открытая система должна обеспечивать и свободу добавления новых приложений, и свободу исключения существующих. Оказывается, что под таким углом зрения рассматриваемые системы выглядят недостаточно открытыми; более того, дела тут обстоят из рук вон плохо.
Если в организации процедуры добавления (инсталляции) приложения еще можно не разглядеть определенных недоработок, то уж деинсталляция буквально вопиет. Каждый, кому выпало хоть раз искоренять глубоко засевшее в бесчисленных системных файлах (config.sys, autoexec.bat, win.ini, system.ini, ...) приложение, не может без дрожи вспоминать об этих нескольких мучительных часах своего программистского бытия. Обиднее всего, что борьба эта, как правило, обречена на бесславное поражение: обычно так и не удается полностью выявить и изничтожить все крючья, которыми сложное приложение сцепилось с операционной системой.
Проблема эта давно замечена. В результате многие приложения, инсталлируемые в MS Windows, предстают теперь перед взором удивленного пользователя в виде двух иконок: одна для постоянного использования, обслуживающая повседневное обращение к приложению, и другая - одноразовая, для его деинсталляции. Если же специальной процедуры деинсталляции в некотором приложении не предусмотрено, на помощь могут прийти универсальные деинсталляторы - невероятно сложные программы, за создание которых, похоже, вскоре начнут присуждать премии Тьюринга.
В то же время, повнимательнее приглядевшись к организации хозяйства DOS и Windows, обнаруживаешь, что существует тривиальнейший выход из положения. Достаточно чуть усложнить аппарат работы с файлами, введя файл специального типа - паспорт приложения. В этом файле приложение размещает всю интересную для операционной системы информацию. При своей перезагрузке, а также при появлении на постоянном диске новых файлов-паспортов операционная система анализирует их содержимое, выдает, где сочтет нужным, диагностические сообщения об обнаруженных ошибках и растаскивает полученные сведения о заявивших о себе таким образом приложениях по своим таблицам.
Проблема решена. Теперь для удаления приложения достаточно всего лишь удалить его файл-паспорт. Не так важно, что при этом будет делать операционная система: соберет ли все свои таблицы заново, или же прицельно исключит соответствующие их элементы, для чего ей нужно будет хранить изначальные сведения о происхождении каждого элемента каждой таблицы. Главное, что в любом случае приложение удаляется предельно просто и исчезает совершенно бесследно.
Новую схему инсталляции имеет смысл оснастить некоторым сервисом для подготовленного пользователя. Хорошо бы позволить заглядывать в системные таблицы, построенные из материала файлов-паспортов, где о каждом элементе можно узнать, какие именно приложения потребовали его включения. Иногда это могло бы помочь при попытке вручную разрешить возникший конфликт приложений. Располагая подобным сервисом, пользователь оказывается в среде во всех отношениях значительно более благожелательной, чем существующая операционная среда MS DOS - Windows. Помимо радикального упрощения процессов включения и исключения приложений, он не только имеет удобный доступ к информации, которую ранее приходилось разыскивать в системных файлах, но и получает сведения о происхождении каждого элемента этой информации, что ранее было абсолютно недоступно.
Некоторое приближение к описанной схеме можно найти в Windows 95. Что же помешало разработчикам Microsoft с самого начала применить подобное решение? Причин можно назвать несколько, но лишь одна из них представляется достаточно весомой, хотя и далеко не очевидной.
По-видимому, разработчиками двигало желание приблизить создаваемые средства описания приложений к общеизвестным языкам программирования. Это стремление, во многом оправданное, имело и негативную сторону: средства описания унаследовали от языков их серьезный изъян - отсутствие поддержки однородных расширяемых наборов. Из-за относительной сложности языков класса Си или Паскаль печальные последствия небрежения однородными наборами не так заметны; в нашем же случае, на фоне простенького синтаксиса системных файлов, эти последствия проявились довольно-таки рельефно. Собирающаяся в системных файлах информация имеет выраженную двумерную структуру: вертикальные слои-приложения и горизонтальные слои-списки однородных системных ресурсов. Каждому из двух измерений необходимо придать конструктивное оформление, однако сделать это, не выходя за рамки распространенных языковых средств, не удается.
Сама по себе идея сосредоточения всех сведений об аппаратной и программной конфигурации данного компьютера не в ассоциативно формируемых таблицах, а в нескольких текстовых системных файлах вполне дееспособна. Пользователю удобно просматривать или редактировать эти файлы посредством своего любимого универсального текстового редактора. Однако беда в том, что такие редакторы создаются с оглядкой на запросы существующих языков программирования, и вслед за языками в редакторах традиционно отсутствуют ассоциативные конструкции, обслуживающие расширяемые однородные наборы. Но это означает, что фирма Microsoft, положившись в ранних версиях операционной системы на системные текстовые файлы, фактически подписала приговор надежной организации добавления или исключения однородных элементов-приложений.
Из-за отсутствия ассоциативных конструкций инсталляция нового приложения, как правило, требует редактирования текстов системных файлов. Здесь легко заметить сразу два источника неприятностей. Во-первых, любое редактирование находящегося в эксплуатации текста, и в особенности чужого текста, - процедура чрезвычайно деликатная. Далеко не каждое приложение успешно с ней справляется, и допущенные ошибки редактирования неумолимо делают свое черное дело: после небрежной инсталляции нередко не только не вызывается новое приложение, но и перестают работать его соседи, информация о которых, непосредственно записанная в редактируемых текстовых файлах, весьма уязвима и легко может быть повреждена. Во-вторых, редактирование обезличивает вносимые дополнения, порождая отмеченные выше сложности деинсталляции.
Напротив, если редактор поддерживает ассоциативные конструкции, перечисленные проблемы находят аккуратное решение. В том месте системного текстового файла, куда каждое приложение должно было вписать, скажем, сведения о добавляемых им драйверах определенного класса, теперь располагается ассоциативная конструкция со следующей семантикой: "Сюда включить объявления драйверов данного класса из всех файлов-паспортов приложений, хранящихся на постоянном диске". От редактора потребуется лишь обеспечить просмотр и выдачу системного файла в двух режимах: либо в форме исходного текста, либо с подставленными на место ассоциативных конструкций однородными объявлениями. Таким образом, исходная двумерность информации получает конструктивное оформление: вертикальные слои-приложения отображаются в файлы-паспорта, а горизонтальные слои-списки однородных ресурсов - в совокупности объявлений драйверов, предъявляемых редактором в точках размещения ассоциативных конструкций.
Оба предложенных решения задачи, и табличное, и текстовое, имеют свои плюсы и минусы и выглядят примерно равноценно. В пользу табличного решения говорит возможность применения специализированного редактора, способного, в частности, более оперативно реагировать на ошибки во вводимых значениях параметров и предоставляющего широкий диапазон разнообразных средств просмотра таблиц. Главное преимущество текстового решения - единое представление всех исходных материалов приложения, основной объем которого обычно составляют алгоритмы, представленные в текстовой форме.
Оформление табличного решения достаточно очевидно; один из его возможных вариантов, как уже упоминалось, можно найти в Windows 95. Текстовое решение требует ассоциативных конструкций. Две конструкции такого рода уже разбирались в [1]. Для нашего случая потребуется еще одна ассоциативная конструкция, рассредоточенный набор. Подробное его описание содержится в [2]. Здесь же, не вдаваясь в детали и не пытаясь охватить все нюансы отношений между операционной системой и приложениями, ограничимся беглым рассмотрением сравнительно простого, но достаточно показательного примера применения рассредоточенного набора в смежной области, для известной задачи о диагностических сообщениях. Используемая там схема без труда проецируется и на обслуживание приложений.
Рассредоточенный набор
Большинство разработчиков крупных программ когда-либо сталкивались со следующей проблемой. Пусть программа должна осуществлять тщательный анализ входных данных, результатом которого является, в частности, значительное число выдаваемых ею диагностических сообщений. Вопрос заключается в том, где следует разместить тексты сообщений: записать их непосредственно в тех точках программы, в которых обнаруживаются диагностируемые ситуации, или же свести в единый список. Каждая из альтернатив имеет свои сильные и слабые стороны.
Непосредственное размещение обладает целым рядом достоинств. Текст сообщения, записанный непосредственно в программе, является, как правило, наилучшим пояснением к фрагменту алгоритма, анализирующему диагностируемую ситуацию. При кодировании алгоритма значительно удобнее сразу разместить сообщение в создаваемой программе, чем включить его в список, формируемый на отдельном листке бумаги или на каком-либо его экранном аналоге, дополнив алгоритм ссылкой на вновь записанную строку списка. Списковое решение требует постоянного внимания к целостности программы: добавляя или исключая некоторый фрагмент алгоритма, необходимо строго следить за тем, чтобы тексты выдаваемых там диагностических сообщений были добавлены в список или, соответственно, исключены из него. При непосредственном размещении о целостности заботиться не надо.
В то же время аргументы в пользу списка также достаточно весомы. Лет 30 назад размеры оперативной памяти обычно не позволяли разместить тексты сообщений непосредственно в программе, что вынуждало выносить эти тексты в файл на внешней памяти, для формирования содержимого которого требовался сводный список сообщений. Но и в наши дни такой список во многих случаях оказывается весьма кстати. Он служит полезным дополнением к любой инструкции по эксплуатации программного продукта. При изучении алгоритма список дает возможность увидеть текст программы в новом интересном ракурсе. Анализируя и корректируя сводный список, легче добиться стилистического единства сообщений. Наконец, списковое представление позволяет избежать поиска разбросанных по программе текстов при необходимости создания версии программы, выдающей сообщения на другом языке.
Проблема размещения текстов сообщений достаточно серьезна, так что для ее решения иногда даже предлагают применять специализированные системные средства поддержки. Столь узкая специализация системных средств все же представляется нерациональной. Ведь если затратить чуть больше усилий, то вместо узконаправленного инструмента можно получить средства поддержки существенно более мощного механизма - так называемого рассредоточенного набора, - способные охватить также множество других практических задач, и в частности рассмотренную выше задачу обслуживания приложений. (При обсуждении обслуживания приложений речь шла о двух решениях, табличном и текстовом, однако в нашем случае таблицы абсолютно непригодны, поскольку из-за такой мелочи, как диагностические сообщения, заведомо не стоит ломать прочную плодотворную традицию текстового представления алгоритмов.)
Схема решения проблемы размещения сообщений с помощью механизма рассредоточенного набора проиллюстрирована на рисунке1. Тексты сообщений записываются рассредоточенно - непосредственно в программе, но оформляются в виде параметров так называемых экспортных заявок. Если в собираемом исходном тексте программы встречается такая заявка, то указанный в ней параметр включается в качестве элемента в формируемый таким образом рассредоточенный набор. Искомый сводный список сообщений в этом случае строится на основе наборного гнезда [1], в котором автоматически собираются все элементы рассредоточенного набора - все сообщения, экспортируемые из составляющих программу модулей. На месте же экспортных заявок при сборке программы формируются обращения к построенному списку. Нетрудно видеть, что данная схема успешно справляется со всеми перечисленными трудностями размещения сообщений.
Рисунок 1.
Рассредоточенный набор.
Интересовавшее нас решение проблемы обслуживания приложений теперь легко получить, если вместо модулей программы рассматривать файлы-паспорта, а в экспортных заявках разместить не тексты сообщений, а запросы на ресурсы операционной системы. Разумеется, здесь потребуется сформировать несколько рассредоточенных наборов, обслуживающих отдельные классы ресурсов.
Развивая начатую параллель, можно заявить, что программа, использующая механизм рассредоточенного набора, открыта для включения или исключения модулей, содержащих диагностические сообщения. В самом деле, разработчик такой программы полностью избавлен от всех технических забот по синхронной коррекции сводного списка. Далее закономерно возникает вопрос: а что еще можно было бы сделать для облегчения развития программы? Таким образом, мы вплотную подошли к обсуждению открытости систем программирования и алгоритмических языков.
Открытость системы программирования
Напомним, что открытость операционной системы мы интерпретировали как ее способность к свободному добавлению новых и исключению существующих приложений. Аналогичное определение открытости применимо и к системе программирования, только здесь в качестве добавляемых и исключаемых выступают элементы программы, модули. Интересно, что такое определение обычно представляется достаточно естественным и не вызывает возражений у программистов, однако дальнейшие аналогии между языками программирования и открытыми системами воспринимаются с трудом и требуют аргументации. Если в открытых системах лозунг "систему открывает стандартизация ее компонентов" с самого начала был начертан на знамени, то утверждение "открытость программы для последующего развития определяется степенью стандартизованности или гомогенизации ее модулей" встретишь нечасто.
Точнее, общепризнанно, что расчленение программы на модули - проверенное средство облегчения ее последующего развития. Еще в 70-х годах Парнас [3] предлагал: оформляйте в виде модуля каждое решение, принимаемое в процессе проектирования программы, и тогда последующие изменения будут строго локализованы, поскольку их причина - именно пересмотр проектных решений. Но какое отношение к открытости имеет стандартизация и проистекающая из нее однородность модулей?
Оказывается, между однородностью модулей и открытостью программы существует прямая связь, проследить которую сравнительно несложно. Например, выделение модуля по Парнасу означает, вообще говоря, что закладывается первый кирпич в основание будущего однородного набора. Если пересматриваемые в ходе развития программы решения не отбрасываются навсегда (поскольку к ним, возможно, придется когда-либо вернуться), то набор однородных модулей-реализаций решений непосредственно появляется в базе данных проекта. Но пусть даже новые варианты модуля никогда не соседствуют со старыми, пусть новые модификации просто приходят на смену устаревшим - и в этом случае однородный набор состоится; правда, виден он будет только при ретроспективном анализе развития программы.
Однородные модули могут не замещать друг друга, как вариантные модули по Парнасу, а одновременно присутствовать в выполняемой программе. Например, если в трансляторе стандартизовано оформление модулей, относящихся к реализации отдельных конструкций входного языка, то в выполнении трансляции одновременно участвуют все эти модули. Здесь также из однородности следует открытость: чем глубже продумана унификация модулей, чем четче очерчены их связи с внешним миром, тем легче пройдет подключение к действующей программе нового модуля, ответственного за новую конструкцию, расширяющую входной язык.
Если в систему включены средства поддержки однородных наборов, то она выходит на новый технологический уровень открытости: появляется возможность безболезненного [1] включения новых и удаления существующих однородных модулей. Безболезненность включения и удаления означает, что здесь не требуется какого бы то ни было редактирования находящихся в эксплуатации текстов программ. Тем самым устраняется главная опасность, главный тормоз свободного манипулирования модульным материалом, поскольку теперь никакие ранее отлаженные части не могут быть повреждены при добавлении новых или удалении существующих модулей.
Характерный пример безболезненного подключения - разобранное ранее решение задачи обслуживания приложений. Если предусмотрены средства системной поддержки однородных наборов, составляемых из запрашиваемых приложениями ресурсов, то вновь появившееся приложение всего лишь записывает на диск свой файл-паспорт, и при такой технологии тексты уже имеющихся на диске файлов-паспортов не подвергаются никакой угрозе. Если же однородный набор не поддержан, то мы закономерно приходим к проблемам Windows 3.11, где куски текстов, относящиеся к различным приложениям, реально соседствуют в одних и тех же системных файлах, добавление или удаление приложений требуют энергичного редактирования этих файлов, а при редактировании трудно не "зацепить" строчки, относящиеся к соседним приложениям.
К сожалению, тенденции программистской моды сейчас направлены в сторону от открытых однородных конструкций. Слишком много внимания взяло на себя объектно-ориентированное программирование. В результате при проектировании структуры программы разработчик увлечен исключительно вычленением взаимодействующих объектов и редко задумывается об их унификации, об унификации методов их обработки, и вообще о целенаправленном поиске однородностей, а ведь объекты и однородность - два равноправных, дополняющих друг друга ориентира проектирования. Однородность забыта, однородность не имеет системной поддержки, но без однородности нет открытости, и развитие программы из удовольствия превращается в опасную, мучительную процедуру.
Модный термин "масштабируемость", говорящий о потенциале наращивания мощности аппаратуры, почему-то мало кому приходит в голову применить и к программным структурам. Что случилось бы со строительством, если бы все архитекторы работали только над уникальными сооружениями, отказавшись и от типовых проектов, и от типовых строительных блоков?! А в программировании нередко проектируют уникальный, но консервативный зоопарк там, где требуется всего лишь серийный, но масштабируемый коровник или свинарник.
Даже очевиднейшие однородные конструкции в языках программирования обычно оказываются на задворках. Типичный пример - описание записи в Паскале. Девять из десяти разработчиков пытаются подчеркнуть однородность полей записи, выделяя под каждое из них отдельную строку своей программы. Однако синтаксис Паскаля разрушает намечающуюся таким образом гармонию, предписывая однородным полям неоднородное оформление: описания первых полей должны завершаться точкой с запятой, описание последнего - нет. Но любая однородность в программе - потенциальная точка развития. И действительно, разработчик достаточно часто добавляет или исключает поля записи, и всякий раз он вынужден задумываться: а не последнее ли поле исключается, - ведь в этом случае надо уничтожить не только строку текста, но и точку с запятой в предшествующей строке. Таким образом, открытость описания полей записи принесена в жертву сомнительным синтаксическим изыскам. Интересно, что в Си простановка точки с запятой в аналогичной позиции разрешена - и ничего, небо не обрушилось на землю.
Менее очевидный пример - оформление однородного набора ветвей программы, допускающих параллельное выполнение. Обслуживающая данную задачу конструкция сейчас нередко надстраивается над языком, когда создаются специализированные средства для эффективной загрузки параллельно работающего оборудования. Разработчик воспринимает ее как неизбежное зло, с которым приходится мириться, если хочешь осваивать новую технику. На самом же деле возможность параллельного выполнения подчеркивает однородность ветвей, и поэтому ее имеет смысл оформлять, даже если переход к параллельному оборудованию не планируется. Тем самым не только проявится важная особенность алгоритма, но и будет образована новая точка роста программы, в дальнейшем ее не спутаешь с последовательными частями и не придется ломать голову над тем, где разместить еще одну добавочную параллельную ветвь. Допускающие параллельное выполнение ветви встречаются в реальных программах на каждом шагу, однако отображающие их конструкции, к сожалению, отсутствуют в массовых алгоритмических языках.
Недальновидную традицию игнорирования нужд однородных конструкций продолжают и новейшие течения в программировании, в частности визуальное программирование. Попытайтесь в Delphi построить линейку, состоящую из плотно прижатых друг к другу однородных быстрых кнопок и открытую для модификации - поддерживающую очевидные действия: добавление новой кнопки в произвольное место линейки с автоматическим раздвиганием ее соседей и удаление произвольной кнопки, сопровождающееся "смыканием ряда" оставшихся в строю. И вы быстро почувствуете, что подобные проекты находились на периферии внимания создателей Delphi. Но визуальный стиль отчасти оправдывает его младенческий возраст, он даже не вошел еще в современные учебники [4], а вот затянувшееся проникновение крупных однородных конструкций в распространенные языки программирования объяснить действительно трудно.
Сложившаяся ситуация выглядит вдвойне противоестественно, если заметить, что в соседних областях, например в системах управления базами данных, царит относительное благополучие. Невозможно представить, что пользователю базы данных для включения в одну из таблиц новой строки предлагают обратиться к общецелевому текстовому редактору. Всем очевидно, что при такой постановке дела пользователь страдает не только из-за необходимости выполнять множество лишних вспомогательных действий, но и, главное, из-за постоянной опасности разрушения существующих данных при ошибке, допущенной в ходе редактирования.
Но текст программы представляет, вообще говоря, ничуть не меньшую ценность, чем строки таблицы базы данных. И модифицировать программы приходится достаточно часто. И средства, необходимые для организации безболезненных изменений, не так уж сложны в реализации. Тем не менее до сих пор подавляющее большинство выполняемых модификаций программы производится варварскими методами, с привлечением общецелевого редактора для коррекции драгоценных отлаженных ранее текстов.
Безрадостно выглядят и перспективы. Если оглянуться на многолетнюю историю операционных систем, систем программирования и алгоритмических языков, становиться ясно, что не приходится всерьез рассчитывать на имеющее место, но слишком вяло текущее стихийное движение к открытости. Здесь требуется радикальная ломка представлений. Надо сформировать атмосферу, где каждый, заявляя о том, что его программная система открыта, считал бы своим долгом не только предъявить свод стандартов на составляющие ее модули, но и продемонстрировать средства системной поддержки, обслуживающие свободное манипулирование возникающими в результате этой стандартизации однородными элементами программы.
Литература
[1]. Горбунов-Посадов М.М. Безболезненное развитие программы // Открытые системы. - 1996. - # 4(18). - С.65-70. http://www.osp.ru /os/1996/04/65.htm
[2]. Горбунов-Посадов М.М. Конфигурации программ. Рецепты безболезненных изменений. - 2-е изд., испр. и доп. - М.: Малип, 1994. - 272 с.
[3]. Parnas D.L. On the criteria to be used in decomposing systems into modules // Comm.ACM. - 1972. - V.15, # 12. - P.1053-1058.
[4]. Ben-Ari M. Understanding programming languages. - Chichester: John Wiley & Sons, 1996. - 360 p.
Работа выполнена при финансовой поддержке Российского фонда фундаментальных исследований.
