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

 Г л а в а  4
МНОГОВАРИАНТНОСТЬ
 
4.2. Эксперимент с материалом
 

 

4.2. Эксперимент с материалом

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

      4.2.1. Постановка задачи. Пусть с помощью вычислительного эксперимента исследуется поведение некоторого устройства в зависимости от материала, из которого оно изготовлено. И пусть решено на начальной стадии эксперимента в качестве материала использовать сталь или медь, а затем исследовать другие материалы. Будем считать, что применение того или иного материала приводит к определенным изменениям в конструкции устройства и поэтому для исследования каждого нового материала требуется новый фрагмент моделирующего алгоритма.
      Для облегчения эксплуатации и развития программного фонда здесь желательно, во-первых, упростить переключение расчетов с одного известного материала на другой и, во-вторых, минимизировать изменения существующих частей программы при появлении нового материала и соответственно нового фрагмента алгоритма. Как в этом случае следует сконструировать программу моделирования?

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

•    •    •
case  материал  of
      сталь :  моделирование_стали ;
      медь :  моделирование_меди
end  { case }
•    •    •

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

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

      4.2.4. Специализированные средства. Вернемся к эксперименту с материалами. Как можно улучшить рассмотренное решение, если не поскупиться на специализированные системные средства?
      Первый шаг — модуляризация — остается таким же, как и при традиционном программировании. В проектируемой программе вычленяется часть, реализующая изменяемый фактор — исследуемый материал. Однако оформляется эта часть не в виде оператора выбора, а в виде вариантного гнезда (см. разд. 1.8, 3.6.2), в которое при сборке расчетной программы будет подставлен тот или иной сменный модуль, моделирующий поведение конкретного материала.
      Два сменных модуля, моделирующие сталь и медь, реализуются и попадают в программный фонд сразу. Затем в ходе эксперимента по мере необходимости дописываются новые модули-материалы. Их размещение в программном фонде происходит безболезненно, не затрагивая ни текстов, ни работоспособности окружающих модулей.
      Можно было бы усмотреть преимущество оператора выбора в том, что его ветви помещаются непосредственно в окружение объемлющей программы, а сменные модули формируются как относительно самостоятельные объекты вне отведенного для них места (вариантного гнезда). Но средства системной поддержки без труда обеспечат ввод и просмотр текста сменного модуля в контексте окружения гнезда. Более того, в этом случае сменный модуль визуально будет находиться ближе к окружению, так как между ним и окружением не громоздятся соседние ветви оператора выбора.
      В тексте объемлющей программы вариантное гнездо может быть представлено какой-либо специальной конструкцией, например предложением #VARIANT вида

•    •    •
#VARIANT  МАТЕРИАЛ
•    •    •

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

МАТЕРИАЛ  <–  СТАЛЬ

где МАТЕРИАЛ — имя вариантного гнезда, указанное в предложении #VARIANT, а СТАЛЬ — имя сменного модуля.
      Конструкция назначения, помещаемая в описание конкретной конфигурации, ничуть не сложнее программной конструкции, которая присваивает начальное значение переменной, управляющей оператором выбора. Таким образом, переходя на специализированные средства, мы по меньшей мере ничего не прогадываем и в отношении простоты переключения с одного известного материала на другой.

Далее

Рейтинг@Mail.ru