М.М. ГОРБУНОВ-ПОСАДОВ - Системное обеспечение пакетов прикладных программ (1184225), страница 16
Текст из файла (страница 16)
части,непосредственно не связанные с предметной областью.Конечно, все наиболее важные решения, касающиеся, например,расширения возможностей языка заданий, принимались на основесовместных обсуждений двух групп разработчиков. Тем не менее каждая изгрупп обладала известной автономией, не вникая, в частности, в менеесущественные детали деятельности другой группы.Предоставляемые Сафрой средства ориентированы в первую очередь наразработчиков больших программ для задач вычислительного эксперимента.Такие программы, создаваемые с помощью Сафры, характеризуютсяследующими параметрами: общее число модулей программного фонда около 1000, суммарная длина программ - около 50 тысяч предложений,число гнезд каркаса расчетных программ, используемых для формированиявариантов, - свыше 50.До появления Сафры столь обширное программное хозяйствоприходилось вести в основном на базе средств штатного программногообеспечения.
Это приводило к тому, что основная доля усилий попроведению вычислительного эксперимента уходила на чисто техническуюработу, связанную с организацией хранения и использования написанныхранее программ. Для проведения расчета прикладной программист долженбыл найти и подготовить тексты используемых модулей, оттранслироватьих, сформировать необходимую для данного расчета библиотеку объектныхмодулей и т.д.Определенную помощь в поиске и подготовке текстов программоказывала система PATCHY [40], идеология которой близка к проектуOLYMPUS. Сафра заимствовала из PATCHY некоторые техническиерешения, но пошла существенно дальше, взяв на себя, в частности, не толькоподготовку текстов, но и проблемы автоматизации трансляции и сборки.Технические трудности, возникающие при организации трансляции исборки, поясним на примерах из практики программирования на ЭВМБЭСМ-6.В одной библиотеке объектных модулей мониторной системы Дубнанельзя хранить несколько модулей с одним итем же именем (имя служит в качестве ключа модуля в библиотеке).
Ноесли при работе по технологии, описанной в предыдущем разделе,определено, что некоторый альтернативный фрагмент алгоритмаоформляется в виде подпрограммы, то все различные реализации этогофрагмента будут иметь вид подпрограмм с одним и тем же именем.Поэтому прикладной программист вынужден для каждой такой реализациизаводить отдельную библиотеку.
Число таких библиотек катастрофическирастет, что приводит к неэкономичному расходованию внешней памяти иусложнению процесса сборки расчетных вариантов.Другой пример связан с экономией времени трансляции. Для того,чтобы основную массу необходимых для очередного расчета модулей нетранслировать заново, а брать готовыми из библиотеки объектных модулей,необходимо постоянно поддерживать целостность пар «исходный текстмодуля - его объектный код». Для этого при внесении изменений в текстмодуля (или же в текст альтернативного фрагмента алгоритма, вставляемогов модуль посредством оператора INSERT) необходимо позаботиться обуничтожении старой версии объектного модуля в библиотеке.
Если текстмодуля включает в себя несколько независимых вставок (INSERT), торучноевыполнениетакогоотслеживаниястановитсякрайнезатруднительным.Сафра полностью избавляет своих пользователей от забот, связанных странсляцией. Конструирование программ ведется исключительно на уровнеисходных текстов, от пользователя скрыты получение, хранение ииспользование результатов трансляции. Трансляция и сборка напоминают осебе только в случае обнаружения ошибок. Обеспечивается компактноехранение объектных модулей, автоматическое поддержание соответствиямежду исходными текстами и объектными модулями, минимизация времениперетрансляции за счет автоматического выявления при сборке всех готовых объектных модулей.Особенностью процесса конструирования программ является его теснаясвязь с многочисленными компонентами штатного системногопрограммного обеспечения: редакторами, трансляторами, загрузчиками ит.д.
Успех попытки автоматизации конструирования во многомопределяется тем, насколько удачно разрабатываемые средства сочетаются сштатной системной средой. При создании Сафры пришлось потратитьнемало усилий для того, чтобы процесс конструирования не выгляделинородным телом в среде штатного обеспечения.Кроме того, с точки зрения пользователя известные трудности вызывалапопеременная работа с разнородными штатными средствами. По мересвоего развития Сафра брала на себя решение все более широкого кругапроблем, связанных с обработкой прикладных программ, сопроводительныхописаний и других материалов функционального наполнения.
В результатесформировался набор операций, в значительной мере экранирующийприкладного программиста от особенностей операционной системы,трансляторов, загрузчиков и т.д.Решение перечисленных выше проблем позволило превратить Сафру вэффективный инструмент разработки программ вычислительногоэксперимента. В ходе многолетней эксплуатации системы только вИнституте прикладной математики были сформированы и выполненыдесятки тысяч различных расчетных вариантов программ для задачматематической физики. Достижение такой производительности труда прикладных программистов без помощи Сафры вряд ли было бы возможно.С появлением промышленной версии Сафры контингент пользователейсистемы расширился, включив в себя целый ряд внешних организаций. Всвязи с этим разработчикам Сафры пришлось вплотную столкнуться со всем«многоцветьем» версий системного программного обеспечения ЭВМБЭСМ-6.
Потребовались специальные меры для того, чтобы Сафра«научилась» настраиваться на несколько независимо развиваемых ветвейоперационной системы Диспак, мониторной системы Дубна, на диалоговыередакторы Димон и Краб.Заслуживает упоминания и разработка специализированного архиваСафры, предназначенного для хранения исходных текстов программ,объектных модулей, сопроводительной документации и других материаловфункционального наполнения.
При реализации Сафры одним из наиболееузких мест оказалась эффективность организации хранения упомянутыхматериалов во внешней памяти. Поэтому многое зависело от решениявопроса о том, воспользоваться ли для организации хранения каким-либосуществующим внешним по отношению к Сафре инструментом или жезатратить усилия на создание собственного специализированного архива.Какие соображения можно привести в пользу специализированногоархива? В работе [100], например, убедительно показано, что традиционныеСУБД ориентированы в первую очередь на организационно-хозяйственныеприменения имало пригодны в задачах обработки результатов физических экспериментов.Есть все основания для того, чтобы распространить данное заключение и наобласть хранения программных материалов.
Напротив, специализированныйархив способен удовлетворить специфические, зачастую достаточно жесткиетребования, связанные, в частности, с эффективностью формированиярасчетных задач.Кроме того, Сафра постоянно развивается, выдвигая все новые запросы ксредствам хранения. Поэтому даже если некоторая СУБД представляласьпригодной на ранней стадии реализации Сафры, всегда существовалаопасность, что в дальнейшем появление новых запросов вынудит откадаться отнее.И все же рещение о реализации собственного специализированного архивапришло к разработчикам Сафры не сразу. Первая, макетная версия Сафрыиспользовала для хранения данных срежства системы УПД-6.Но затем, когда выяснилось, что объем работ по реализацииспециализированного набора средств хранения составит не более 15-20% отобхема работ по реализации Сафры в целом, было решено, что такую ценуможгно заплатить за уверенность в достижении любого требуемого уровняэффективности.
Создание, уничтожение или модификация модуляпрограммного архива требуют не более одной секунды процессорного времениБЭСМ-6. Сборка наиболее сложных вариантов программ (использующих до100 модулей из архива порядка 4 Мбайт) требует 15-20 секунд. Такиенакладные расходы представляются вполне допустимыми, поскольку,например, трансляция всех программ сложного варианта занимает 10-15 минутвремени процессора.3.3. АрхитектураПо современным представлениям архитектура (т.е.
представляющийсяпользователю внешний вид) реализации Сафры на ЭВМ БЭСМ-6 выглядитнесколько архаично. Дело в том, что ввиду скромных диалоговыхвозможностей вычислительной среды БЭСМ-6 Сафра была ориентирована напакетный режим работы. Однако, как показал опыт реализации Сафрына ЕС ЭВМ, основная часть операций пакетной Сафры очевидным образомотображается на диалоговый режим. Поэтому содержащееся в данном ипоследующих разделах описание возможностей пакетной Сафры позволяетполучить представление и о диалоговой версии Сафры. О спецификедиалоговой Сафры будет идти речь лишь в случае, если диалоговый режимвыполнения какой-либо операции добавляет новые интересные возможности.Итак, все виды работ, связанные с подготовкой и запуском программ наочередном витке вычислительного эксперимента, при использовании системыСафра оформляются с помощью языка заданий пакета.
Каждое задание состоитиз нескольких последовательно выполняемых пунктов, соответствующихотдельным операциям. Например, существуют операции, позволяющие:- записать (STORE) в архив пакета новый модуль;- исключить (DELETE) модуль, записаный ранее;- отредактировать (EDIT) тексты модулей, хранящихся в архиве;- распечатать каталог (CATALOG) модулей архива;- переписать архивный модуьл в файл редактора Димон (DIMON) илиКраб (CRAB);- собрать и выполнить (EXECUTE) конкретный расчетный вариант;- распечатать (BOOK) в двухстраничном формате с редактированиемтексты сопроводительных документов и т.д.Первая группа операций (STORE, DELETE, EDIT, PRINT, CATALOG)предназначена для модификации или распечатки содержимого архива пакета.С помощью операции STORE в архив может быть записан под указаннымименем произвольный текст. Любой текстовый объект, записанный в архивпосредством STORE, называется модулем, а имя, под которым он хранится, архивным именем модуля.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
