4.7. Модуль типа направление

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

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

      4.7.2. Происхождение направлений. Интуитивно причины сосуществования различных направлений исследования сложной проблемы достаточно очевидны. Можно, однако, попытаться пояснить их и с позиций математики. Для этого сначала придется обратиться к некоторым особенностям задач вычислительного эксперимента, и в частности задач проектирования новых изделий.
      Процесс вычислительного эксперимента в глазах математика прежде всего ассоциируется с решением некоторой оптимизационной задачи. В качестве варьируемых параметров здесь выступают изменяемые факторы. Что же касается понятия оптимальности того или иного решения, то дать сколько-либо формальное его определение для достаточно сложного проектируемого изделия обычно не удается.
      Поэтому здесь не работают широко распространенные математические методы оптимизации, требующие, чтобы оптимизируемая функция была единственной и строго заданной. Несколько лучше отражают специфику рассматриваемой задачи методы многокритериальной оптимизации [Соболь, 1981], однако обычно и они оказываются непригодными в силу слишком большого числа варьируемых факторов, а также из-за дискретности и неупорядоченности значений этих факторов.
      Более того, границы пространства поиска окончательно определяются только в ходе вычислительного эксперимента. Для ранних стадий эксперимента весьма характерна ситуация, когда не только не реализована значительная часть исследуемых значений изменяемых факторов (т. е. не написана часть сменных модулей), но даже и мысль о самой возможности исследования некоторых новых значений просто еще не приходила в голову разработчику.
      Таким образом, можно заключить, что вычислительный эксперимент — плохо формализуемый процесс, требующий от участников постоянных творческих усилий. С точки зрения математика, этот процесс представляет собой целенаправленное движение в пространстве изменяемых факторов, позволяющее постепенно приближаться к искомому оптимуму. Поскольку толкование оптимальности здесь весьма нетривиально, следует ожидать, что в ходе вычислительного эксперимента будет обнаружено несколько представляющих интерес окрестностей локальных оптимумов. Одновременное изучение таких окрестностей можно интерпретировать как несколько сосуществующих направлений исследования. С точки же зрения программной реализации, каждой изучаемой окрестности сопоставляется модуль типа направление.