5.4. Задание конфигурации
Прежде чем говорить о задании конфигурации для интересующих нас сейчас однородных наборов, напомним, как задавались конкретные конфигурации многовариантной программы (см. гл. 4). Для каждого содержащегося в каркасе программы вариантного гнезда требовалось, вообще говоря, указать подставляемый в него в данной конфигурации сменный модуль. Такие указания имели форму назначений
имя_гнезда <– имя_сменного_модуля
Напротив, значительную часть имеющихся в программе наборных гнезд вообще не нужно упоминать в описании конфигурации. Модули, составляющие однородный набор, размещаются в программном фонде и снабжаются атрибутом, говорящим о принадлежности к данному набору. Поэтому при сборке текста программы заполнение наборного гнезда можно выполнить без всяких дополнительных указаний: извлекаются из программного фонда и подставляются в гнездо все однородные модули, принадлежащие набору, имя которого записано в заголовке гнезда. Например, именно так может быть организована сборка рассмотренной в предыдущем разделе программы заполнения основной надписи.
Но иногда бывает необходимо явно задать некоторую информацию об используемом при сборке однородном наборе. Во-первых, часто требуется включить в формируемую конкретную конфигурацию программы не все множество составляющих набор однородных модулей программного фонда, а лишь некоторое подмножество этих модулей. Во-вторых, бывает небезразлично, в какой последовательности располагаются в наборных гнездах однородные модули. Рассмотрим подробнее каждую из этих ситуаций.
5.4.1. Подмножество набора. Прежде всего приведем три примера задач, где необходимо вычленять некоторое подмножество однородного набора.
Пусть в программном фонде хранится несколько оформленных в виде однородных модулей методов расчета, сосуществующих в собранной программе и сменяющих друг друга в ходе ее выполнения. И пусть известно, что на предъявленной совокупности исходных данных лишь некоторая часть этих методов обладает свойством устойчивости. Тогда при задании конкретной конфигурации необходимо будет отсеять неустойчивые методы.
Если одновременно с проведением производственных расчетов идут работы по развитию используемой в расчетах программы, то в программном фонде наряду с отлаженными однородными модулями может оказаться сырой, не готовый к производственной эксплуатации материал из того же однородного набора. В этом случае понадобятся две различные конкретные конфигурации: при отладке в собираемую программу включаются все модули набора (что не требует никаких усилий), а при производственном счете — только отлаженные (что требует выделения подмножества).
Третий, последний пример. Пусть в программном фонде размещен архив свойств химических веществ, в котором в форме однородных модулей собраны сведения об огромном числе когда-либо требовавшихся в расчетах веществ. Архив настолько велик, что с трудом помещается даже на диске, так что не может быть и речи о размещении всей хранящейся в нем информации в выполняемой программе. Но архив целиком никогда и не нужен: в любом расчете фигурирует только несколько веществ (из которых, скажем, выполнены компоненты исследуемой установки), и в соответствующие наборные гнезда каркаса должны быть подставлены только модули, характеризующие используемые вещества.
Как и в других подобных ситуациях (см. разд. 3.4, 3.6.3), задавать необходимое подмножество модулей однородного набора можно либо перечислением, либо ассоциативно.
При перечислительной схеме задания все имена модулей, входящих в подмножество, указываются явно, т. е. назначение имеет вид
имя_набора <– (перечень_имен_модулей)
Например:
ВЕЩЕСТВО <– (ВОДОРОД, КИСЛОРОД)
Отметим, что здесь в левой части назначения фигурирует не имя гнезда (как это было в случае вариантных гнезд), а имя набора. Объясняется это особенностями работы с многокомпонентными модулями. Подобно сменному модулю для вариантного гнезда, однородный модуль набора может состоять из нескольких компонентов. Но соотношение между такими компонентами и гнездами тут несколько иное.
Каждому компоненту сменного модуля ставилось в соответствие свое вариантное гнездо, где мог размещаться только этот компонент. Как правило, существовало даже взаимно однозначное соответствие между компонентами и гнездами, что позволяло говорить о «многосвязном вариантном гнезде» (т. е. о совокупности вариантных гнезд), в которое подставляется «многосвязный сменный модуль» (т. е. совокупность компонентов сменного модуля). Эти понятия и фигурировали в конструкции назначения для вариантного гнезда.
В наборное гнездо может включаться сразу несколько различных компонентов однородного модуля, и поэтому наборные гнезда не имеют уникальных имен и их совокупность вовсе не повторяет состав компонентов однородного модуля набора. Это не позволяет корректно ввести понятие «многосвязное наборное гнездо» (как аналог неплохо послужившего нам в свое время многосвязного вариантного гнезда), и вместо него приходится адресоваться непосредственно к имени однородного набора. По той же причине и по отношению к модулям в случае однородного набора лучше не употреблять термин «многосвязный», а говорить о составных однородных модулях набора.
В среде подготовки расчета техника задания подмножества однородного набора во многом напоминает организацию ввода назначения сменного модуля для вариантного гнезда (см. разд. 4.9). Так же, как и там, центральное место среди сервисных средств ввода занимает меню, составленное из имен однородных модулей набора. Однако в этом меню нужно отметить не единственное имя, а целую группу имен, определяющую требуемое подмножество модулей.
Основной недостаток перечислительной схемы заключается в том, что она зачастую препятствует построению безболезненного механизма пополнения программного фонда (см. разд. 3.4.3). Проиллюстрируем это на одном из только что рассмотренных примеров.
Пусть параллельно с производственными расчетами идет отладка новых однородных модулей. И пусть в какой-то момент разработчик приходит к заключению, что очередной отлаживаемый однородный модуль достиг требуемых кондиций и пришла пора подключать его к производственной версии программы. Как будет происходить такое подключение?
При перечислительной схеме надо будет добавить к подмножеству имен входящих в версию однородных модулей еще одно имя. Такое добавление требует модификации первичного объекта — описания конкретной конфигурации производственной программы, т. е. ручного редактирования существующего отлаженного программного материала. Но это означает, что тут не выполняется требование безболезненности для окружения.
Безболезненное решение, как и раньше (см. разд. 3.4.2, 3.6.3), удается построить с помощью ассоциативной схемы. Все отлаженные однородные модули снабжаются атрибутом ОТЛАЖЕН, а в описании конфигурации имена модулей не указываются явно, лишь задается ссылка на их атрибут:
НАБОР <– * .ОТЛАЖЕН
Тогда для подключения нового модуля достаточно снабдить его этим атрибутом, что, разумеется, никак не затрагивает окружающие программные материалы, т. е. подключение выполняется безболезненно для окружения.
Разобранный пример демонстрирует также одно существенное отличие в способах организации работы с вариантными и с наборными гнездами. В многовариантной программе следует всячески избегать многофакторности, и если строго придерживаться этого указания, то в результате, как правило, только один атрибут сменного модуля будет участвовать в управлении конфигурацией.
Выбор по другому атрибуту высекает, вообще говоря, не один, а несколько сменных модулей. Даже если вдруг удалось с помощью «посторонних» атрибутов выделить ровно один модуль, то все равно такое решение неустойчиво: оно опирается лишь на сиюминутное состояние программного фонда и появление новых сменных модулей будет постоянно угрожать единственности сделанного выбора. Более того, указание «посторонних» атрибутов при задании содержимого вариантного гнезда изначально некорректно, поскольку другой вариантный атрибут должен иметь, очевидно, и другую область локализации в программе (см. разд. 4.4.4).
В наборном гнезде, напротив, вовсе не требуется единственность выбираемого модуля — любое подмножество модулей однородного набора, будучи подставленным в наборное гнездо, породит корректную (в определенном смысле) программу. Многие подмножества однородных наборов в самом деле способны нести важную функциональную нагрузку: в них строго локализуются некоторые существенные качества формируемой программы. Если наличие у однородного модуля требуемого качества оформлено в виде соответствующего атрибута модуля, то в описании конкретной конфигурации достаточно указать данный атрибут, ассоциативно высекающий нужное подмножество.
Так, в разобранном только что примере высечение подмножества отлаженных модулей позволяло при программировании «вширь» формировать дееспособную производственную версию программы. Или же, пусть имеется текстовый редактор, а требуется получить из него просмотрщик, не допускающий изменений изучаемых текстов. Для этого, вероятно, достаточно из однородного набора, реализующего различные функциональные клавиши редактора, высечь подмножество модулей, обладающих атрибутом «клавиша не изменяет исходного текста».
Следует, однако, иметь в виду, что далеко не всегда нужные качества программы локализуются в подмножествах ее однородных наборов. Например, можно выбрать подмножество однородных модулей, на которые в течение трех месяцев не поступало рекламаций, но это не будет означать, что сформированная таким образом конкретная конфигурация в целом будет обладать заданной степенью надежности. Ведь помимо однородных модулей в программу обязательно входят и модули каркаса, которыми нельзя управлять посредством рассматриваемого механизма высечения подмножеств. Модули каркаса будут включены в программу безусловно, невзирая на поступившие на них рекламации, и тем самым попытка обеспечения заданной надежности может потерпеть неудачу.
5.4.2. Последовательность модулей. Если отсутствуют какие-либо другие указания, то последовательность, в которой однородные модули размещаются в наборном гнезде, выбирается системой и будет (с точки зрения разработчика) совершенно произвольной. Единственное, на что разработчик, по-видимому, вправе рассчитывать в такой ситуации, — это на то, что во всех наборных гнездах собранной программы последовательность модулей будет одной и той же.
Однако нередко бывает нужно разместить модули в строгой последовательности, задаваемой разработчиком. Приведем два характерных примера программ, где требуется указать последовательность.
Если программа пытается одолеть некоторую задачу, применяя к ней несколько различных методов решения (оформленных в виде однородных модулей), то первыми имеет смысл испытать либо самые перспективные, либо самые быстрые из методов. Для того чтобы задать последовательность применения методов, обычно достаточно расположить однородные модули в соответствующем порядке.
В программе заполнения основной надписи (см. разд. 5.3.2) может быть реализована функциональная клавиша Следующий ввод, позволяющая конструктору заполнять графы надписи в последовательности, которая показалась разработчику программы наиболее рациональной. Для того чтобы закодировать такую последовательность, достаточно расположить в заданном порядке элементы таблицы граф (coord).
Требуемая последовательность может меняться от запуска к запуску, а может быть зафиксирована раз и навсегда. Например, перспективность методов может сильно зависеть от конкретной решаемой задачи, и поэтому последовательность модулей должна будет систематически меняться. Напротив, изменение последовательности заполнения граф может понадобиться, только если выяснится, что разработчик допустил там какой-либо просчет. Поэтому в зависимости от ситуации задание последовательности становится соответственно либо элементом конкретной среды подготовки расчета, либо постоянным атрибутом однородного набора.
Так или иначе, средства поддержки однородных наборов должны позволять задавать требуемую последовательность размещения модулей. Среди возможных способов задания последовательности выделим три: перечислительный, весовой и расстановочный.
При перечислительном способе последовательность модулей задается явным перечислением их имен в требуемом порядке. Если в описании конкретной конфигурации определяются и подмножество набора, и последовательность модулей, то эти части описания очевидным образом совмещаются: элементы подмножества перечисляются в нужной последовательности.
И опять приходится говорить о главном недостатке перечислительного способа — он препятствует безболезненному развитию программы. Подключение к программе нового однородного модуля влечет за собой модификацию существующей последовательности имен модулей: к ней придется добавить новое имя. Таким образом, безболезненность подключения обеспечена не будет.
Безболезненное развитие возможно при весовом способе задания последовательности. Каждому модулю из однородного набора присваивается некоторый вес — числовой атрибут, определяющий место модуля в последовательности. Имеется в виду, что модули располагаются в наборных гнездах в порядке возрастания (убывания) их весов. Новый модуль обретает свое место в последовательности за счет своего веса, никак не затрагивая существующие программные материалы, и, таким образом, подключение происходит безболезненно для окружения.
Весовой способ прекрасно работает, когда в качестве веса может быть использован какой-либо из уже существующих самостоятельных объектов программы, лучше всего — один из односвязных компонентов однородного модуля. Так, если в примере из разд. 5.3.2 потребуется разместить записи с координатами граф основной надписи в порядке возрастания значения верхней границы графы, то в роли веса сможет выступить компонент НАЧАЛО_Y.
Если же единственное назначение весов — задание последовательности, то работать с ними довольно неудобно, веса часто воспринимаются разработчиками как весьма далекий от первоначальной постановки задачи чужеродный механизм. Дополнительные сложности возникают, когда добавление и исключение модулей идут достаточно интенсивно и хаотично, в результате чего у весов нередко разрастаются излишне длинные дробные части.
Наиболее перспективным представляется расстановочный способ. Хотя по существу он ничем не отличается от перечислительного, тем не менее здесь за счет применения средств поддержки риск внесения ошибок в существующие материалы удается свести к минимуму. Поэтому на практике расстановочный способ можно без особой натяжки отнести к безболезненным, что позволяет ему успешно конкурировать с весовым способом.
При расстановочном способе включение нового модуля в существующую последовательность происходит следующим образом. В момент записи нового однородного модуля в программный фонд разработчику на экране дисплея предъявляется таблица упорядоченности, задающая последовательность размещения существующих модулей набора. Требуется с помощью мыши или функциональных клавиш указать позицию нового модуля в этой таблице. В процессе указания позиции разработчик не может изменить состав таблицы, т. е. не может добавить в нее имена других модулей или исключить имеющиеся имена. Если новый модуль участвует в нескольких описаниях конфигурации, где требуются различные последовательности, то разработчику предъявляется несколько таблиц.
Если формируется новое описание конфигурации, требующее новой упорядоченности входящих в него однородных наборов, то составителю описания предъявляются для задания требуемых последовательностей неупорядоченные таблицы имен модулей, принадлежащих этим наборам. В таких таблицах можно переставлять имена на нужные позиции, но, как и ранее, нельзя добавлять и/или исключать имена.
Таким образом, средства поддержки расстановочного способа позволяют придать ему все необходимые на практике качества. Действительно, процесс указания позиции достаточно безопасен с точки зрения сохранности имеющихся программных материалов и в то же время существенно более нагляден, чем применение весов.
Заканчивая разговор о последовательности модулей, упомянем еще одну довольно редкую ситуацию. Случается, что в различных наборных гнездах, относящихся к одному и тому же набору, требуются различные последовательности размещения модулей. В этой ситуации задается несколько последовательностей, которым присваиваются имена, а в наборных гнездах наряду с именем набора указывается и имя требуемой последовательности.
|
