М.М. ГОРБУНОВ-ПОСАДОВ - Системное обеспечение пакетов прикладных программ (1184225), страница 15
Текст из файла (страница 15)
Наконец, части программ, связанные свзаимодействием с конкретной операционной системой, фиксированнымобразом выделяются и документируются.Проект OLYMPUS получил широкое международное признание.Журнал Computer physics communications регулярно публикует алгоритмы,разработанные в рамках этого проекта, которые используются многимиорганизациями в различных странах, в том числе в СССР.СоглашениясущественнооблегчаютпроведениеOLYMPUSвычислительного эксперимента и при отсутствии средств системнойподдержки.
Но с появлением таких средств отдача этих соглашениймногократно возрастает. Это утверждение в полной мере можно отнести какк повышению наглядности программ, так и к облегчению конструированиярасчетных вариантов.Мы уже упоминали ряд системных разработок, выполненных авторамипроекта OLYMPUS и ориентированных на то, чтобы сделать программыболее наглядными, облегчить процессы ознакомления с программнымфондом и составления документации. В то же время расчетные вариантыпрограмм конструировались авторами проекта на базе штатных системныхсредств.
Поэтому для формирования вариантов им приходилосьиспользовать универсальный текстовый процессор, составляя для каждогорасчета задания размером до нескольких сотен строк.Соглашения OLYMPUS поддерживает и описываемый в следующейглаве пакет прикладных программ Сафра. Однако в этом пакете, в отличиеот системных разработок авторов OLYMPUS, на первый план выдвигаетсязадача автоматизации конструирования программ вычислительногоэксперимента.Глава 3СИСТЕМА САФРА: КОНСТРУИРОВАНИЕ ПРОГРАММВЫЧИСЛИТЕЛЬНОГО ЭКСПЕРИМЕНТА3.1.
Технология конструированияСафра [115] - Система Автоматизации Физических РАсчетов предназначена для поддержки конструирования программ вычислительногоэксперимента. Ключевой проблемой вычислительного эксперимента с точкизрения программирования является организация многочисленныхизменений программ, отражающих различные решения, принимаемые входе эксперимента. Такие решения могут быть связаны и с модификациейисследуемой математической модели, и с выбором того или иногочисленного метода, и с пересмотром некоторых элементов алгоритма. Но влюбом из этих случаев изменение решений неизбежно влечет за собойизменение программы.Принимаемые в ходе эксперимента решения обычно не являютсяокончательными, нередко приходится возвращаться к отвергнутым наранних стадиях эксперимента моделям, методам или алгоритмам.
Поэтомуизменения программ связаны в основном не с заменой того или иногомодуля его улучшенной версией, а с пополнением программного фондановыми модулями, различные сочетания которых образуют расчетныепрограммы. Поскольку в процессе эксперимента часто требуетсяповторение выполнявшихся ранее расчетов, желательно организоватьработу таким образом, чтобы постоянные изменения программного фонда,связанные с появлением новых модулей, проходили безболезненно, т.е. незатрагивали текстов написанных ранее программ.Поясним проблему безболезненного внесения изменений на примере.Пусть с помощью вычислительного эксперимента исследуется поведениенекоторого устройства в зависимости от материала, из которого оноизготовлено. Пусть решено на начальной стадии эксперимента в качествематериала использовать сталь или медь, а затем исследо-вать какие-либо другие материалы.
Будем считать, что появление того илииного материала приводит к определенным изменениям в конструкцииустройства и поэтому для исследования каждого нового материала требуетсяпереписать некоторый фрагмент моделирующего алгоритма.Как следует организовать программу моделирования, если мы стремимсяминимизировать изменения существующих частей программы при появлениинового материала и соответственно нового фрагмента алгоритма?На первый взгляд, неплохо выглядит следующее решение. В том местепрограммы, где необходимо выполнять различные действия в зависимости отиспользования того или иного материала, записывается (к примеру, наПаскале) оператор выбора следующего вида:.
. .case материал ofсталь: < моделирование стали > ;медь: < моделирование меди >end { case }. . .Тогда, присваивая с помощью исходных данных расчета переменной«материал» значения «сталь» или «медь», можно переключать алгоритммоделирования с одного материала на другой. С точки зрения организациипоследующих изменений основной результат такого построения заключаетсяв том, что в программе неявно, но достаточно четко определено место дляразмещения новых фрагментов алгоритма, моделирующих новые материалы:такие фрагменты записываются в виде новых ветвей оператора выбора.Рассмотренное решение можно упрекнуть за то, что в немнепроизводительно расходуется оперативная память, поскольку впрограмму включаются все имеющиеся ветви выбора, а фактически в любомрасчете используется лишь одна из них.
Однако такой упрек можнодовольно легко парировать - достаточно превратить оператор выбора вконструкцию периода компиляции.Главный же технологический изъян применения в подобной ситуацииконструкции выбора несколько менее очевиден. Он заключается в том, чтопоявление новой ветви выбора неизбежно влечет за собой редактированиетекстов существующих программ, что, как известно, нередко приводит кпотере их работоспособности.Совершенно иное решение этой задачи, основанное на каркасномподходе и описанных в предыдущей главе согла-шениях проекта OLYMPUS, предлагается в системе Сафра. На местеоператора выбора в программе записывается специальная конструкцияINSERT (вставить) периода компиляции вида. . .INSERT материал.
. .Теперь фрагменты алгоритма, соответствующие различным материалам,оформляются в виде самостоятельных текстовых объектов и помещаются вспециализированный архив под соответствующими именами: «сталь»,«медь» и т.д. Для формирования расчетной программы, моделирующейповедение устройства, изготовленного из определенного материала, следуетзадать соответствие между именем, записанным в операторе INSERT(«материал»), и именем, под которым хранится соответствующий фрагменталгоритма (например, «сталь»):материал = стальСафра построит программу, заменив оператор INSERT указаннымфрагментом.С точки зрения технологичности внесения последующих измененийприведенное решение принципиально отличается от рассматривавшегосявыше использования оператора выбора. Здесь появление фрагментаалгоритма,соответствующегоновомуматериалу,невызываетредактирования уже имеющихся текстов программ.
Новый фрагмент простопомещается в архив под уникальным именем, что никак не может повлиятьна работоспособность других хранящихся там программ.Оператор INSERT - не единственная конструкция Сафры,поддерживающая «безболезненные» изменения программ. Если позволяютсоображения наглядности и эффективности, то все элементы наборафрагментов алгоритма, соответствующие альтернативным решениям, могутбыть оформлены в виде подпрограмм. Тогда вместо специального оператораINSERT периода компиляции в программе записывается обычный операторвызова подпрограммы периода выполнения. Например, если программапишется на Фортране, она будет выглядеть так:.
. .CALL МАТЕРИАЛ. . .Все альтернативные фрагменты алгоритма представляют собойподпрограммы с одним и тем же именем МАТЕРИАЛ, однако вспециализированный архив они помещаются под различными именами:«сталь», «медь» и т.д. Далее с точки зрения пользователя Сафрыформирование расчетных программ выполняется точно так же, как и дляоператора INSERT, - указывается соответствие между именем подпрограммы и именем, под которым хранится в архиве ее реализация. Например:материал = стальНа большинстве вычислительных установок, в частности, на ЭВМБЭСМ-6, для которой разрабатывалась Сафра, штатные системные средстване позволяют организовать эффективное использование описаннойтехнологии.
Дело в том, что точек ветвления, подобных рассмотренной впримере, в реальных программах насчитывается обычно несколько десятков.Для того, чтобы произвести все необходимые манипуляции с текстамипрограмм и организовать их последующие трансляцию и исполнение,прикладной программист вынужден выполнять множество рутинныхопераций. Сафра избавляет его от этой скучной и утомительнойдеятельности, существенно повышая тем самым производительность трудапри программировании задач вычислительного эксперимента.Точнее говоря, описанная технология конструирования явиласьотправной точкой для цикла работ, посвященного автоматизацииконструирования программ вычислительного эксперимента и приведшего ксозданию системы Сафра.
В последующих разделах приводятся краткиесведения об организации этих работ и описываются основные функциональные возможности Сафры.3.2. Организация и содержание работ по созданию СафрыСафра создавалась в рамках исследований по пакетам прикладныхпрограмм, проводимых в Институте прикладной математики имени М. В.Келдыша АН СССР под руководством академика А. А. Самарского. Перваяпроизводственная версия системы была реализована на ЭВМ БЭСМ-6 всреде операционной системы Диспак и мониторной системы Дубна в 1978году.В создании Сафры постоянно принимали участие две группыпрограммистов: прикладные и системные.
Прикладные программисты былизаняты созданием функционального наполнения пакетов, для которыхсредства, предоставляемые Сафрой, служили в качестве языка заданий исистемного наполнения. Системные программисты разрабатывали и совершенствовали средства, обеспечивающие хранение функциональногонаполнения (архив) и интерпретацию языка заданий, т.е.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
