4.9. Задание конфигурации

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

имя_вариантного_гнезда  <–  имя_сменного_модуля

Как спроецировать эту конструкцию на страницу среды подготовки расчета?

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

 
Рис. 4.3.  Окрестность гнезда ввода имени сменного модуля.
 
— гнездо ввода

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

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

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

      4.9.4. Другие сервисные средства. Механизмы меню и ручного ввода имени сменного модуля составляют основу системной поддержки назначения содержимого вариантного гнезда. Однако помимо них в среде подготовки расчета могут быть предусмотрены и некоторые вспомогательные сервисные средства.
      Полезно, в частности, разрешить просматривать (или редактировать) текст сменного модуля, имя которого задано текущей строкой меню. Просмотр будет более наглядным, если он выполняется «в рабочем контексте», т. е. в окружении текста, содержащего заполняемое вариантное гнездо. Такие средства, наряду с уже упоминавшимися средствами доступа к окрестности обслуживаемого вариантного гнезда, обеспечивают необходимые связи между средой подготовки расчета и сопряженными с ней исходными текстами программ.
      Наращивание мощности сервисных средств можно было бы легко продолжить. Но мы предпочтем здесь остановиться, поскольку в наши намерения вовсе не входит построение законченного механизма задания конкретной конфигурации. На этих страницах мы стремились лишь проиллюстрировать основные проблемы, связанные с таким построением.

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

      4.9.6. Вариантный ввод. Существует еще одна важная связь между элементами описания конфигурации и исходными данными, соседствующими в среде подготовки расчета. Дело в том, что различные сменные модули, подставляемые в вариантное гнездо, могут, вообще говоря, требовать ввода различного состава исходных данных. Такой ввод, зависящий от конкретной конфигурации многовариантной программы, будем называть вариантным вводом.
      Пусть, например, для заполнения вариантного гнезда ДОСТУП_К_ТАБЛИЦЕ может быть назначен либо сменный модуль ХЕШИРОВАНИЕ, либо сменный модуль ЛИНЕЙНЫЙ_ПОИСК. Модуль ХЕШИРОВАНИЕ требует в качестве исходных данных имя используемой хеш-функции (функции расстановки). Если же для заполнения данного гнезда назначить сменный модуль ЛИНЕЙНЫЙ_ПОИСК, то, конечно, никакой хеш-функции задавать не потребуется.
      Ввод для модуля ХЕШИРОВАНИЕ может быть организован по-разному. Если переключение с одной хеш-функции на другую оформлено в виде оператора выбора, то для ввода имени понадобится гнездо ввода данных. Если же хеш-функции, в свою очередь, сопоставлено вариантное гнездо, то понадобится гнездо ввода имени сменного модуля. Но сейчас для нас существен не тип гнезда ввода, а то, что его заполнение требуется лишь в случае, когда назначен сменный модуль ХЕШИРОВАНИЕ; т. е. здесь мы имеем дело с вариантным вводом.
      Вероятно, неверно было бы запретить пользователю среды подготовки расчета сначала ввести имя хеш-функции и только потом сказать, что способ организации доступа к таблице — хеширование (хотя обратная последовательность представляется обычно более естественной). Ведь «пользователь всегда прав», и если ему почему-то покажется более удобной какая-либо последовательность заполнения гнезд ввода, он должен иметь возможность применить именно ее.
      Таким образом, можно заключить, что пользователю среды подготовки расчета всегда должны быть доступны все существующие гнезда ввода, даже если часть из них он заполнит напрасно, т. е. если их содержимое никак не отразится ни на составлении, ни на выполнении расчетной программы. Разумеется, параллельно надо принять меры для того, чтобы доступность гнезд не повредила надежности процесса их заполнения. Пользователь имеет право в любой момент потребовать показать ему все гнезда ввода, заполненные им «вхолостую». Кроме того, при желании он может легко избежать опасности заполнения «холостых» гнезд: для этого достаточно регулярно пользоваться клавишей Следующий ввод (см. разд. 4.8.2).

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