Г л а в а  6

РАССРЕДОТОЧЕННЫЙ НАБОР

      В предшествующих главах рассматривался ряд расширяемых конструкций, где включение однородных элементов в программу происходило следующим образом. Сначала в программном фонде накапливалась определенная совокупность относительно самостоятельных однородных элементов (которую мы теперь будем называть регулярным однородным набором). В собираемой расчетной программе с таким набором связывались одно или несколько гнезд. Затем при сборке в эти гнезда подставлялось некоторое подмножество элементов регулярного набора, задаваемое либо явно — описанием требуемой конкретной конфигурации, либо неявно — по умолчанию.
      В настоящей главе мы рассмотрим еще один механизм формирования совокупности однородных элементов, который будем называть рассредоточенным однородным набором. Состав этого набора определяет исходный текст конкретной собираемой конфигурации программы, точнее, разбросанные по нему («рассредоточенные») объявления специального вида. Если в собираемый исходный текст попадает такое объявление, то осуществляется заказанное в нем включение элемента в рассредоточенный набор.
      Объявляться могут имена элементов существующего в программном фонде регулярного однородного набора, и в этом случае совокупность разбросанных по исходному тексту объявлений высекает подмножество регулярного набора. Могут объявляться и непосредственно записываемые в точке объявления тексты вновь создаваемых элементов (возможно, составных), и тогда при сборке из них формируется совершенно новый однородный набор.
      Так или иначе, в результате образуется определенная совокупность однородных элементов — рассредоточенный набор. С помощью системных средств все элементы набора можно собрать вместе и, скажем, просмотреть на экране дисплея, что может послужить неплохим подспорьем при изучении программы. Однако более многообещающее применение собранного рассредоточенного набора — сведение воедино его элементов в наборном гнезде (рис. 6.1).

 
Рис. 6.1.  Рассредоточенный набор.
 
— модули программы,  — элементы набора,
— наборное гнездо,  — от объявления к гнезду

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

6.1. Примеры

      6.1.1. Вызовы процедуры. Один из наиболее часто встречающихся, но далеко не самый интересный из рассредоточенных наборов — вызовы процедуры. Однородность разбросанных по программе вызовов отдельной процедуры сразу бросается в глаза: все такие вызовы, как правило, имеют единообразное синтаксическое оформление, тот же состав параметров и т. д. Будучи собранными вместе, вызовы процедуры дают богатую пищу для размышлений об отношениях между данной процедурой и остальными частями программы. Иметь под рукой полную совокупность вызовов удобно и при модификации интерфейса с процедурой, т. е. при изменении количества или назначения параметров.
      Некоторые разработчики операционной среды находят нечто предосудительное в попытке изучения всей совокупности обращений к процедуре. Практически единодушно признается, что при анализе программы полезно иметь возможность спуститься от вызова процедуры к ее тексту и затем вернуться обратно; а вот систематический просмотр всех обращений к процедуре иногда встречает возражения. Наиболее весомые аргументы противников формирования рассредоточенного набора из вызовов процедуры происходят из области модуляризации программы.
      Действительно, при определении функционального содержания процедуры, вычленяемой в процессе модульного анализа, полезно абстрагироваться от конъюнктурных потребностей отдельных вызовов, придавая процедуре более общий характер, позволяющий, в частности, надеяться на ее многократное использование в будущем. Отказ от реализации механизма просмотра рассредоточенного набора обращений к процедуре зачастую мотивируется именно стремлением уберечь всех и каждого от соблазна учета особенностей отдельных вызовов. Однако насаждение какой бы то ни было дисциплины модуляризации такими диктаторскими методами вряд ли найдет понимание у пользователя операционной среды.
      Кроме того, не следует забывать, что излишняя увлеченность «обобщением» процедуры также чревата неприятными последствиями. Кстати говоря, один из характерных симптомов переобобщенности процедуры — постоянство (для всех вызовов) значений одного или нескольких параметров — проще всего обнаружить именно при просмотре собранного рассредоточенного набора вызовов процедуры.
      С точки зрения конфигурационных построений, вызовы процедуры не представляют особого интереса, поскольку этот рассредоточенный набор в собранном виде, как правило, требуется только на стадии анализа программы и никак не участвует в сборке конкретных конфигураций. Кроме того, просмотр вызовов процедуры неплохо реализуется и без рассредоточенного набора (см. разд. 4.11.3). Более убедительные свидетельства полезности рассредоточенных наборов содержатся в последующих примерах, где собранный набор фигурирует уже и как компонент формируемой программы.

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

      6.1.3. Библиографические ссылки. В настоящее время действуют определенные каноны подготовки научных публикаций, которые включают в себя, в частности, правила оформления библиографических ссылок на цитируемые или используемые работы. Все библиографические ссылки собираются в единый список литературы, размещаемый в конце публикации, а непосредственно в ее тексте записываются только компактные конструкции типа «[9]», отсылающие к элементу единого списка с указанным номером.
      Проблемы, возникающие при подготовке публикации в соответствии с данными правилами, весьма напоминают только что рассмотренные проблемы размещения диагностических сообщений. Основное отличие в том, что у автора публикации нет выбора: он обязан следовать существующим правилам и поэтому не может позволить себе поместить полную библиографическую ссылку непосредственно в текст (в то время как размещение диагностических сообщений непосредственно в тексте, вообще говоря, вполне допустимо). Таким образом, он вынужден, создавая основной текст публикации, параллельно на отдельном листочке формировать библиографический список.
      Автор обязан следить за целостностью пары «основной текст — список литературы». Исключая или добавляя содержащий ссылки фрагмент основного текста, он должен позаботиться о соответствующей коррекции имеющегося списка литературы.
      Вновь, как и в случае диагностических сообщений, проблема оказалась настолько острой, что многие разработчики систем подготовки публикаций включают в них специализированные средства поддержки библиографических ссылок. И вновь те же задачи с успехом может решить более общий механизм рассредоточенного набора. Он позволяет разместить текст полной библиографической ссылки непосредственно в тексте публикации, оформив его в виде объявления элемента набора. В конце публикации в надлежащем месте размещается наборное гнездо, в котором собираются из всего текста все объявленные библиографические ссылки.
      Тем самым, в частности, решается проблема целостности. Как уже упоминалось, состав наборного гнезда является производным от объявленных в тексте элементов набора. Поэтому в список литературы автоматически попадут те и только те ссылки, которые были объявлены в тексте.
      В научной литературе применяются различные схемы отсылки из основного текста к библиографическому списку. Одна из них, принятая в настоящей книге, использует для этой цели идентификатор, составляемый из фамилии первого автора и года издания, например «[Дейкстра, 1978]». При этой схеме имеет смысл оформить объявление составного элемента, состоящего из двух компонентов: идентификатора и текста ссылки. В формируемый список литературы будут включены оба компонента, а в основном тексте останется только первый из них.
      При другой популярной схеме отсылки в основном тексте помещается только номер позиции в списке литературы, например «[9]». Тут потребуется несколько дополнить конструкцию объявления, включив в нее возможность доступа к номеру объявляемого элемента, который он получает в рассредоточенном наборе (к этой теме мы вернемся в разд. 6.2.2). Заметим, что такое дополнение пригодилось бы и в рассмотренной ранее задаче о диагностических сообщениях.
      На примере библиографических ссылок удобно пояснить еще одну особенность применения рассредоточенного набора. Как вести себя в случае, если в подготавливаемом тексте встречается несколько ссылок на одну и ту же работу? Здесь приходится принимать во внимание сразу два новых обстоятельства.
      Во-первых, среди средств системной поддержки рассредоточенного набора хотелось бы иметь механизм, позволяющий не набирать каждый раз заново весь текст ссылки, а лишь указывать на текст, набранный ранее и уже включенный в набор. Реализация таких средств довольно проста и не представляет для нас особого интереса.
      Во-вторых, согласно существующим правилам, в список литературы (т. е. в формируемый рассредоточенный набор) от всей группы совпадающих ссылок должен быть включен только один элемент. Реализовать слияние ссылок также несложно. Однако возникает вопрос: всегда ли необходимо такое слияние?
      Из общих соображений можно было бы ожидать, что наряду с удовлетворившим нас сейчас набором, где совпадающие элементы сливаются в один, в некоторой другой предметной области понадобится набор, в который включается вся группа совпадающих объявлений, т. е. совпадающие элементы размножаются. Но практика применения рассредоточенного набора наводит на мысль о том, что наборы с размноженными совпадающими элементами, скорее всего, не нужны.
      Все известные автору приложения и, в частности, все рассматриваемые в данной главе примеры задач обслуживаются рассредоточенным набором с неразмноженными совпадающими элементами. Поэтому ожидаемых двух типов рассредоточенного набора тут введено не будет: в дальнейшем всегда предполагается, что от всей совокупности совпадающих элементов в набор делегируется только один представитель.
      Наконец, разбирая варианты обслуживания библиографических ссылок, нельзя не упомянуть и о возможности использования для этих целей специализированного архива. Пусть в программном фонде наряду с другими материалами хранится «библиографический архив», т. е. регулярный однородный набор, элементами которого являются ссылки на наиболее часто цитируемые источники. Тогда для того чтобы сослаться в подготавливаемой публикации на такой источник, уже не нужно выписывать текст ссылки целиком, а достаточно указать лишь имя, под которым требующаяся ссылка на источник хранится в наборе.
      При наличии библиографического архива подготовка публикации несколько упрощается, однако проблема поддержания целостности пары «основной текст — список литературы» остается столь же актуальной. Вновь, корректируя текст публикации, необходимо параллельно корректировать библиографический список. И вновь нас выручит рассредоточенный набор, но в данном случае потребуется другая его модификация: в объявлении надо будет задать не саму ссылку, а только ее имя. Точнее говоря, задается имя элемента, имеющегося в регулярном однородном наборе (в «библиографическом архиве») и содержащего полный текст нужной ссылки.
      Разумеется, в исходном тексте одной публикации можно сочетать обе модификации объявлений элементов, указывая как полные тексты библиографических ссылок, так и имена ссылок, извлекаемых из архива. В окончательном тексте публикации, получаемом на выходе препроцессора, все ссылки независимо от их происхождения соберутся на месте соответствующего наборного гнезда в единый список литературы.
      Библиографический список — далеко не единственный элемент публикации, нуждающийся в предлагаемой системной поддержке. Механизм рассредоточенного набора может с успехом применяться при подготовке словаря терминов, предметного или именного указателя, указателя обозначений и т. п.

      6.1.4. Рассредоточенный ввод. Одна из известных проблем, возникающих при проектировании программы, заключается в следующем. Пусть решаемая задача так или иначе расчленена на функционально самостоятельные части, и пусть каждой части сопоставлен модуль проектируемой программы. Между выделенными таким образом модулями проработаны интерфейсы по данным и управлению, позволяющие организовать их совместную деятельность.
      Далее, на стадии непосредственной реализации, нередко выясняется, что любой из выделенных модулей, вообще говоря, может потребовать ввода (извне, т. е. пользователем программы) каких-либо из своих параметров. Все параметры для всех модулей должны быть введены на начальной стадии выполнения программы. Это означает, что наряду со спроектированными ранее модульной структурой и интерфейсами требуется организовать в программе еще один, в некотором смысле ортогональный к ним процесс начального ввода. В нем должны быть собраны из всех модулей части, отвечающие за ввод параметров.
      Процесс начального ввода оформляется либо как среда подготовки расчета (см. разд. 4.8), функционирующая как самостоятельный объект до начала выполнения программы, либо, в более простом варианте, как специализированный модуль ввода, включаемый в программу на равных правах с другими, но выполняемый одним из первых. И в том, и в другом случае к формированию процесса начального ввода имеет смысл подключить механизм рассредоточенного набора. Разбросанные по модулям фрагменты программы, предназначенные для ввода параметров этих модулей, превращаются в объявления элементов рассредоточенного набора, которые затем собираются воедино в наборном гнезде либо в форме среды подготовки расчета, либо в форме модуля ввода.
      Если же операционная среда не поддерживает рассредоточенный набор, то организация такого рассредоточенного по модулям ввода сталкивается с серьезными трудностями. Разработчику программы придется вручную организовать все необходимые связи между модулями программы и процессом ввода. В частности, при непосредственном кодировании модуля разработчик вынужден будет завести для этого процесса отдельный листок бумаги, чтобы параллельно выписывать на нем фрагменты алгоритма, обеспечивающие начальный ввод появляющихся параметров модуля. Особенно много сложностей возникает при изменениях состава образующих программу модулей, поскольку им должны сопутствовать соответствующие ручные коррекции процесса ввода (см. разд. 4.9.6, 4.9.7), отражающие отказ от ввода параметров удаляемых модулей и добавление ввода параметров подключаемых модулей.
      В некоторых современных языках программирования удается построить и несколько иное решение задачи организации рассредоточенного начального ввода. Так, в Аде имеется механизм предвыполнения модуля, который позволяет, в частности, выполнить заданную последовательность операторов перед первым обращением к каким-либо данным или подпрограммам, составляющим модуль. Среди таких предвыполняемых операторов можно, по-видимому, разместить и операторы, обеспечивающие начальный ввод параметров модуля. Тем самым мы получаем решение проблемы рассредоточенного начального ввода, представляющееся на первый взгляд достаточно технологичным.
      Механизмы предвыполнения и рассредоточенного набора отличаются друг от друга и технологически, и по сфере применения. Предвыполнение имеет в Аде множество разнообразных приложений, и, возможно, далеко не все из них допускают построение своих аналогов в форме рассредоточенного набора. Однако в случае начального ввода более предпочтительным представляется применение именно рассредоточенного набора. В его пользу говорят следующие соображения.
      Прежде всего, с помощью предвыполнения легко строить только аналог модуля ввода, но существенно сложнее (а нередко и невозможно) сформировать таким образом самостоятельную среду подготовки расчета (см. разд. 4.8, 4.9).
      Кроме того, на практике нередко требуется «каскадный» начальный ввод, где параметры модулей вводятся и обрабатываются в несколько этапов. Каскадный ввод необходим, если каждый последующий этап ввода (точнее, инициализации) опирается на информацию, полученную на предыдущих этапах не только данным, но и соседними модулями. Каскадному вводу очевидным образом сопоставляется несколько рассредоточенных наборов, соответствующих этапам ввода. Аппарат же предвыполнения здесь оказывается непригодным.
      Наконец, часто встречаются ситуации, когда в самостоятельный процесс надо вынести не начальные, а промежуточные или завершающие действия. Например, при завершении работы некоторые модули могут пожелать записать во внешний статистический файл число выполненных обращений к каким-либо из содержащихся в них подпрограмм. (Другие примеры такого рода содержатся в следующем разделе, посвященном рассредоточенному выводу.) Поскольку постановки задач для всех этих процессов весьма близки, хотелось бы, чтобы и решались они сходными средствами. Рассредоточенный набор с равным успехом справляется и с начальным, и с промежуточным, и с завершающим процессами. Предвыполнение же в последних двух случаях, разумеется, абсолютно бессильно.

      6.1.5. Рассредоточенный вывод. Существует множество видов работ, где требуется собрать в единый процесс разбросанные по модулям фрагменты программы, обеспечивающие вывод определенной информации. Одна из таких работ — запись статистики обращений к подпрограммам — упоминалась в предыдущем разделе. Здесь мы рассмотрим еще две работы: организацию отладки и обеспечение надежности длительных расчетов.
      Необходимая составная часть организации отладки программы — выдача промежуточных или финальных (в частности, «посмертных», т. е. имевших место при аварии) значений отдельных переменных. Выдаваемые значения могут непосредственно выводиться на экран дисплея или на печать, а также записываться во внешнюю память для последующего анализа. Направление вывода нас интересовать не будет, для нас сейчас существенно лишь то, что значения обычно выдаются порциями, представляющими собой «мгновенный снимок» состояния указанных переменных.
      В выдаваемую порцию нередко входят переменные, определенные в различных модулях. Удобно в каждом таком модуле независимо указать интересные для отладки переменные, а не организовывать явно процесс промежуточной или «посмертной» выдачи. Для этого и потребуется рассредоточенный набор: интересные переменные не покидают пределов текста своего модуля, но объявляются однородными элементами набора, что позволяет автоматически собрать их вместе в наборном гнезде и превратить в искомый процесс отладочной выдачи.
      В качестве объявляемых элементов набора могут выступать имена как отдельных переменных, так и размещаемых в модулях подпрограмм вывода. Второй вариант нередко оказывается более предпочтительным, поскольку здесь для связи с процессом отладочной выдачи достаточно объявить входной точкой только имя подпрограммы вывода, но не требуется оформлять как входные все выводимые собственные переменные модуля. Однако в любом случае именно техника рассредоточенного набора позволяет избежать явного перечисления всего выводимого материала.
      Рассредоточенный вывод требуется также и при организации надежных длительных расчетов. Главная угроза проведению длительного расчета — случайный сбой ЭВМ, отключение питания и тому подобные аварии, которые могут случиться в ходе расчета и повлечь за собой потерю затраченного до момента аварии машинного времени. Для того чтобы сократить возможные потери, применяется техника так называемых контрольных точек.
      Все время выполнения расчета разбивается на интервалы (скажем, порядка 20 минут), после каждого из которых фиксируется контрольная точка, т. е. сохраняется во внешней памяти информация, достаточная для повторного запуска расчета с данной точки. При аварии расчет не начинается сначала, а продолжается с последней сохраненной контрольной точки. Таким образом, потери при аварии будут сравнительно невелики: они не превысят интервала времени между соседними контрольными точками.
      Известно два основных способа организации контрольной точки. При первом способе во внешнюю память записывается дамп, т. е. состояние всей оперативной памяти, содержимое регистров и др. Второй, более экономичный «ручной» способ (для которого, собственно, и потребуется рассредоточенный набор) подразумевает, что разработчик программы сам определяет, какую информацию следует сохранить в контрольной точке.
      При «ручном» способе для каждого из модулей программы может, вообще говоря, потребоваться сохранить в контрольной точке часть его собственных переменных. Указания о переменных, вошедших в число сохраняемых, удобнее записывать непосредственно в тексте содержащего их модуля. Это становится возможным благодаря конструкции объявления, делегирующей сохраняемые переменные из модуля в рассредоточенный набор. Элементы рассредоточенного набора собираются воедино в наборном гнезде и превращаются во фрагмент алгоритма, фиксирующий контрольную точку.

      6.1.6. Свойства химических веществ. В разд. 5.4.1 упоминалась задача построения и использования архива свойств химических веществ. Архив является компонентом программного фонда (точнее, регулярным однородным набором) и включает в себя сведения о многочисленных веществах, когда-либо требовавшихся в расчетах. В собираемую программу включается только определенное подмножество архива, поскольку в любом конкретном расчете фигурирует лишь несколько веществ.
      Задавать интересующее программу подмножество веществ можно двумя способами: компактно или рассредоточенно. В примере из разд. 5.4.1 задание подмножества выполнялось компактно — оно было элементом описания конкретной конфигурации. Однако во многих случаях более удобно рассредоточенное задание, когда заявки на включение в собираемую программу сведений о том или ином веществе выставляют модули, составляющие эту программу.
      Такие заявки, записываемые непосредственно в тексте модуля, представляют собой объявления имен однородными элементами (веществами), включаемыми в рассредоточенный набор ВЕЩЕСТВО. Полученный набор будет включать в себя имена всех требуемых веществ, т. е. он в полной мере способен заменить явное описание конфигурации. Как и ранее, на основе сведенных воедино в наборном гнезде элементов рассредоточенного набора формируется искомый фрагмент программы — таблица свойств используемых веществ.
      Обслуживание архива веществ иногда ставит и несколько более сложные задачи. Во-первых, среди атрибутов веществ встречаются и такие, которые задаются в форме фрагментов алгоритма. Если в подобных фрагментах, в свою очередь, содержатся заявки на включение в программу новых веществ, то реализация рассредоточенного набора усложняется.
      Во-вторых, число хранящихся в архиве различных атрибутов вещества может быть достаточно большим, в то время как в конкретном расчете обычно требуются не все, а лишь незначительная часть атрибутов. Затребованные в модулях собираемой программы атрибуты также имеет смысл оформить в виде рассредоточенного набора (АТРИБУТ). Тогда можно будет построить таблицу атрибутов сокращенного размера, вложив наборное гнездо АТРИБУТ в наборное гнездо ВЕЩЕСТВО.

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

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