Назад Оглавление Вперед
На головную страницу М.М.Горбунов-Посадов
 
РАСШИРЯЕМЫЕ ПРОГРАММЫ
 

 Г л а в а  3
ПАКЕТ ПРОГРАММ
 
3.4. Механизмы сборки и безболезненность
 

 

3.4. Механизмы сборки и безболезненность

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

      3.4.1. Два вида безболезненности. При автоматическом планировании, рассмотренном в предыдущем разделе, вновь создаваемые модули врастали в существующий пакет удивительно органично. Добавление еще одного модуля позволяло сразу же не только решать новые, недоступные ранее задачи, но и, возможно, улучшить алгоритмы для тех задач, с которыми пакет так или иначе справлялся и до появления данного модуля. Автоматическое улучшение алгоритмов — безусловно полезное свойство, однако оно несет в себе серьезную угрозу работоспособности отлаженных версий программы. Ведь если новый модуль содержит ошибки, то при его подключении к имеющимся выполняемым программам их работоспособность может быть утрачена.
      Преодолеть этот недостаток и добиться гарантированной работоспособности сравнительно нетрудно. Достаточно, например, запретить подключение вновь появившихся модулей в версии программы для встречавшихся когда-либо ранее задач. Но в таком случае за безболезненность приходится платить, по-видимому, слишком высокую цену: механизм пополнения пакета новыми модулями во многом теряет свою первоначальную гибкость и продуктивность.
      Природа ассоциативного механизма всецело предохраняет программиста от редактирования существующих первичных объектов программного фонда. При появлении еще одного модуля тут не требуется исправлять что-либо не только в соседних модулях, но и в ранее сформулированных постановках задач. И тем не менее новый модуль может сразу включиться в решение этих задач, если планировщик отдаст ему предпочтение при анализе совокупности старых и вновь появившихся цепочек.
      Столь изысканное погружение модуля в программный фонд несомненно заслуживает внимания, несмотря на потенциально возможную потерю работоспособности некоторых версий программы. Такое погружение имеет смысл отнести к безболезненным, однако безболезненность здесь трактуется более широко, чем в гл. 1. Теперь мы будем различать два вида безболезненности.

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

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

      3.4.2. Безболезненность ассоциативной сборки. Итак, специфические особенности безболезненного развития, отличающие пакет с автоматическим планированием, объясняются тем, что там применяется ассоциативный механизм включения модулей в формируемую версию программы, когда модуль выбирается не посредством явного указания его имени, а за счет наличия у него некоторых свойств (атрибутов), запрашиваемых системными средствами пакета. (В школьной задаче, иллюстрировавшей разд. 3.3.2, таким свойством, запрашиваемым программой-планировщиком, было наличие известных входных данных.)
      Ассоциативный механизм формирования конкретной конфигурации программы еще не раз будет рассматриваться на страницах этой книги, и ему нередко будет сопутствовать возможность потери работоспособности отлаженных ранее версий при подключении новых модулей. Более того, если некоторый подход к построению пакета обладает свойством безболезненности для окружения, то единственной причиной, которая может помешать безболезненности для работоспособности, является именно ассоциативное подключение модулей.
      Другими словами, при отсутствии в управлении конфигурацией ассоциативных механизмов из безболезненности для окружения следует безболезненность для работоспособности. Действительно, если при задании конфигурации не используются ассоциативные механизмы, то новый модуль не может быть включен неявно в старую версию программы. Если же, кроме того, новый модуль не требует никаких изменений текстов его соседей (безболезненность для окружения), то на имеющиеся выполняемые программы его появление просто не окажет никакого влияния, т. е. их работоспособность не может пострадать.
      В то же время встречаются общие конфигурации, которые строятся посредством ассоциативного механизма, и это не мешает им, тем не менее, развиваться безболезненно для работоспособности. Одна из таких конфигураций — библиотека модулей — рассматривалась нами в предыдущей главе (разд. 2.2.3, 2.4.3). Секрет здесь в том, что в библиотеке ассоциативно составляемый набор модулей применяется только для обзора и контроля использования самой библиотеки, но не для формирования выполняемых программ.

      3.4.3. Безболезненность перечислительной сборки. Наряду с ассоциативным широко применяется перечислительный механизм сборки. Перечислительная сборка в определенном смысле проще ассоциативной, тут состав участвующих в сборке модулей задается посредством явного перечисления их имен в описании конкретной конфигурации формируемой программы. Характерный пример перечислительной сборки — задание конвейера в системе UNIX (см. разд. 3.2.1).
      Перечислительная сборка заметно отличается от ассоциативной возможностями обеспечения безболезненности. Обычно она обслуживает конфигурации, где вновь подключаемый модуль не должен участвовать в ранее отлаженных версиях программы. Так, на упомянутый выше конвейер в системе UNIX появление в программном фонде новых модулей не окажет никакого влияния. В подобных случаях, как легко видеть (см., например, разд. 3.2.3), с безболезненностью все обстоит вполне благополучно: появление модуля вовсе не затронет отлаженный материал, т. е. обеспечивается безболезненность для работоспособности.
      Если же новые модули должны подключаться к уже имеющимся версиям программы, перечислительная сборка значительно уступает ассоциативной. Подобно ассоциативной сборке, такое подключение неизбежно означает опасное вмешательство в отлаженные ранее версии программы, иначе говоря, оно ведет к потере безболезненности для работоспособности. Но, к сожалению, неприятности этим не исчерпываются.
      Строго говоря, в данном случае не обеспечивается даже безболезненность для окружения. Дело в том, что для подключения нового модуля надо вручную отредактировать первичный объект, содержащий перечень имен модулей формируемой выполняемой программы: к этому перечню требуется добавить имя нового модуля. Тем самым безболезненность для окружения нарушается. (Согласно разд. 3.4.1, из нарушения безболезненности для окружения следует и утрата безболезненности для работоспособности, но с последней потерей так или иначе приходится смириться, поскольку, как мы только что заметили, она неизбежна при любом подключении «необкатанного» материала к отлаженной версии программы.)
      Справедливости ради надо сказать, что выполняемые тут редактирующие действия значительно проще, чем, скажем, редактирование текста программы на каком-либо развитом алгоритмическом языке. Объект редактирования — перечень имен модулей — имеет очевидную структуру, да и изменить его требуется совсем немного: добавить к перечню новое имя. Даже термин «редактирование» здесь не совсем уместен, поскольку пополнение перечня производится обычно посредством «перетаскивания» добавляемого модуля с помощью мыши.
      И все же утрата безболезненности для окружения даже в столь незначительных, казалось бы, масштабах может иметь весьма серьезные последствия. Ведь перечень имен — самое сердце возводимой из модулей конструкции, и при частых модификациях программы это сердце надо будет многократно подвергать хирургическим операциям ручного редактирования. Так что если многочисленные отлаженные версии программы должны изменяться при появлении нового модуля, имеет смысл попытаться заменить перечислительный механизм сборки ассоциативным.

Далее

Рейтинг@Mail.ru