Содержание к диссертации
Введение
1. Постановка задачи 13
1.1. Предполагаемые приложения 13
1.2. Процесс разработки 19
1.3. Архитектурные спецификации ИБО 22
2. Структура инструментально-базовой системы 26
2.1. Определение спецификаций системного наполнения 26
2.1.1. Язык заданий , 28
2.1.2. Регламент модуляризации функционального наполнения 30
2.1.3. Планирование вычислений 32
2.1.4. Информационное обеспечение 33
2.1.5. Операционные средства 36
2.2. Выбор базовых системных модулей 42
2.2.1. Языковый процессор 42
2.2.2. Процессор исполнения расчетной цепочки 43
2.2.3. Процессор интерфейса 44
2.2.4. Диалоговый процессор 44
2.2.5. Информационный процессор 45
2.2.6. Настраивающий процессор 46
2.3. Инструментальные средства системы 49
3. Проект инструментально-базовой системы 54
3.1. Базовая составляющая ИБО 54
3.1.1. Языковый процессор 55
3.1.2. Процессор исполнения расчетных цепочек 60
3.1.3. Процессор интерфейса 64
3.1.4. Диалоговый процессор 66
3.1.5. Информационный процессор 71
3.1.6. Настраивающий процессор 74
3.1.7. Сервисные средства 81
3.2. Использование реализаций системных модулей для построения системного наполнения пакетов 84
3.3. Инструментальные средства ИБО 87
4. Реэлизэдия инструментально-базовой системы 92
4.1. Реализация базовой составляющей ИБО 92
4.2. Реализация инструментальных средств ... 99
4.3. Использование ИБО для создания ППП 101
Заключение 103
Описок литературы 104
Приложения
- Архитектурные спецификации ИБО
- Регламент модуляризации функционального наполнения
- Процессор исполнения расчетных цепочек
- Реализация инструментальных средств
Введение к работе
Современный этап развития математического обеспечения ЗВМ характеризуется повышенным интересом к проблемам, связанным с пакетами прикладных програші /ППП/. Этот интерес объясняется необходимостью более широкого использования средств вычислительной техники специалистами самых различных профилей и вытекающей из этого потребностью в повышении тематической квалификации вычислительных систем [I-9J.
Расширение сферы использования пакетов прикладных программ, сложность их разработки и высокие требования к системной квалификации разработчиков выдвигает на первый план задачу автоматизации процесса создания ППП.
Одним из наиболее распространенных и эффективных подходов к решению этой задачи является использование для создания пакетов инструментально-базовых систем /ИБС/, например, СПОРА, ПРИЗ, ПШ, PLAN-БЗСМ-б и др. [Ю-17,58,59].
Здесь под инструментально-базовой системой будем понимать программную систему, средства которой могут быть использованы как в качестве инструмента для создания и развития пакета, так и в качестве базиса языка заданий и системного наполнения ППП.
Такие системы позволяют существенно повысить производительность труда, снизить требования к системной квалификации разработчиков пакетов и обеспечить при этом достаточно высокие показатели системного обеспечения создаваемых пакетов. Это достига-
#
ется за счет одноразовой разработки комплекса средств, которые могут использоваться при формировании языка и системного . на-
полнения конкретных пакетов. '
Имеющиеся в настоящее время инструментально-базовые системы являются универсальными, т.е. могут быть использованы для создания пакетов прикладных программ в самых различных приложениях.Однако, общепринятый способ формирования ППП с помощью универсальных ИБС, основанный на переносе всех системных средств инструментально-базовой системы во вновь создаваемый пакет приводит к некоторой избыточности системного наполнения этих ППП.Б ряде случаев, когда эта избыточность незначительна или несущественна, такое состояние дел вполне приемлемо.
Создание пакетов, системное наполнение которых реализует только те системные функции, которые необходимо, может быть осуществлено путем переноса в состав формируемого ППП только части системных средств ИБС. Для этого базовые системные средства ИБС 'должны быть организованы по модульному принципу.
Цель настоящей работы состоит в разработке архитектуры и принципов функционирования модульной инструментально-базовой системы, предназначенной для создания пакетов, ориентированных на решение пользователями, не являющимися профессиональными программистами, ограниченного круга смежных задач инженерно- технического характера.
Предлагается новый подход к созданию инструментально-базовых систем, характеризующийся модульной организацией базовой составляющей системы и поддержкой инструментальности в двух её аспектах -- предметном и системном.
Использование такого подхода позволит обеспечить эффективность и необходимое разнообразие архитектур пакетов, формируемых с помощью модульных инструментально-базовых систем.
- 6:-
Результаты работы могут быть использованы для создания инструментально-базовых систем для широкого круга приложений.
Диссертация состоит из введения, четырех глав, заключения, списка литературы и приложений.
В первой главе формулируется постановка задачи. Сначала анализируется организация работ и дисциплина проведения вычислений в приложениях, характерных для вычислительных центров высших учебных заведений.Это статистическая обработка результатов Физических экспериментов, некоторые задачи обучения студентов, задачи расчета электроэнергетических сетей большой протяженности, расчеты прочности и других характеристик для проектирования силовых самолетных конструкций.
При этом выделяются некоторые общие черты приложений (сравнительно небольшой круг решаемых задач, основными пользователями являются специалисты, не являющиеся профессиональными программистами, постоянное развитие предметной области в связи с расширением круга пользователей и решаемых задач) и отмечаются различия в дисциплинах проведения расчетов.
Проводится рассмотрение процесса разработки .пакетов прикладных программ, при этом в качестве основных выделены следующие этапы :
анализ прикладной деятельности ;
определение архитектуры пакета ;
модульный анализ алгоритмов предметной области ;
определение операционного обеспечения ;
реаяизация полученных проектных решений..
Показано, что имеется реальная возможность автоматизации четвертого и пятого этапов работы, а уровень требований, предъявляемых
к системной квалификации разработчиков ІЇЇЇЇІ в случае использования инструментально-базовой системы, может быть значительно снижен.
На основе проведенных исследований формулируется постановка задачи в виде требований к ИБС :
Базовые системные средства, включаемые в ИБС, ориентированную на указанные приложения, должны.реализовывать только те системные характеристики, которые необходимй для этих приложений.
Базовые системные средства должны быть разработаны на основе принципа модульности таким образом, чтобы в дальнейшем из них можно было бы собирать требуемые конфигурации системного обеспечения 11Ш1.
Инструментальность ИБС должна обеспечивать возможность не только адекватной предметной ориентации, т.е. определение языка заданий и формирование соответствующего функционального наполнения, но и возможность учета дисциплины проведения вычислений при создании системного наполнения пакета.
Вторая глава посвящена определению структуры инструментально-базовой системы, удовлетворяющей постановке задачи.
Вначале описывается обобщенная модель системного обеспечения пакетов в терминах системных характеристик, предложенная в работах [18-20] .
На основе этой модели определяются спецификации системного обеспечения пакетов, ориентированных на автоматизацию проведения вычислений в указанных приложениях.В качестве необходимых системных показателей выделяются следующие :
язык запросов ;
внутренний регламент модуляризации ;
полуавтоматическое планирование ;
внешнее информационное обслуживание ;
операционные средства :
а. полужесткий интерфейс ;
б. компиляция и интерпретация расчетной цепочки ;
в. хранение данных с помощью банка расчетных данных ;
г. хранение программ функционального наполнения с помощью
средств штатного математического обеспечения ;
д. общение с пользователем - диалог на всех этапах работы,
диалог на этапе формирования заданий, закрытый режим ;
е. настройка на предметную область ;
ж. дополнительные сервисные средства.
Производится выбор базовых системных модулей, удовлетворяющих определенным выше системным спецификациям с учетом возможных различий в реализациях одних и тех же показателей.
Формулируется внутренний регламент модуляризации базовых конструктивных элементов /системных модулей/. Принима.ется решение оБ -использовании жесткого интерфейса для организации информационной связи между системными модулями.
Определение состава и структуры инструментальных средств, отражающих системный аспект инструментальности, проводится на основе представления ИБО в виде некоторого пакета, предназначенного для формирования системного наполнения конкретных ШШ.Такое представление позволяет успешно применять при создании ИБС уже известные и хорошо зарекомендовавшие себя методики и подходы к разработке пакетов прикладных программ.
В процессе выбора архитектуры инструментальных средств большое внимание уделяется воп"оосу удешевления её реализации путем
максимального использования уже существующих средств штатного математического обеспечения.
Третья глава содержит проект основных компонентов инструментально-базовой системы.Определяется набор конкретных реализаций системных модулей, учитывающих особенности перечисленных приложений. Уточняются системные функции, описываются технические решения, направленные на их эффективную реализацию.
По проекту, в состав базовой компоненты инструментально-базовой системы включается девять реализаций системных модулей.
Для создания языкового процессора предлагается использовать подход, основанный на использовании метаязыка для определения синтаксиса и семантики вводимых конструкций и понятий языка заданий пакета. Декларативная составляющая этого метаязыка ориентируется на описание синтаксиса, а процедурная - на описание семантики языка заданий.Определение семантики предлагается вести в форме процедур, написанных на каком-либо алгоритмическом языке высокого уровня с тем, чтобы использовать их в дальнейшем подобно семантическим программам, применяемым в компиляторах.
Процессор исполнения расчетных цепочек предназначен для управления проведением расчетов модулями функционального наполнения. Задачей этого процессора является выполнение фиксированной последовательности действий по подготовке языковой и информационной среды для выполнения модулей функционального наполнения, организации защиты системного наполнения от возможных ошибок и сбоев Нтунк-ционального наполнения, а также по загрузке и выполнению требуемых модулей.
Проект процессора интерфейса ориентирован прежде всего на
поддержку межмодульного интерфейса, однако предполагает также реализацию функции хранения данных в период между сеансами расчетов. Работа этого процессора базируется на использовании банка расчетных данных.Если вся информация, необходимая для нормальной работы модуля функционального наполнения, может быть одновременно размещена в оперативной памяти, то процессор интерфейса обеспечивает её размещение и передачу модулю.В том случае, когда это невозможно, процессор интерфейса предоставляет функциональному наполнению средства, позволяющие обращаться прямо к информации, хранящейся в банке расчетных данных.Использование этих средств предполагает явное обращение к ним из модулей функционального наполнения.
Дяя обеспечения интерактивного взаимодействия с пользователем предлагается использовать две реализации диалогового процессора. Одна из них - более простая - ориентирована на вецение диалога только на этапе формирования задания, другая - для организации диалога на всех этапах работы.В обеих реализациях последовательность работы всего пакета обеспечивается локализацией асин-хронности, связанной с произвольностью момента ввода запроса пользователя, в рамках диалогового процессора. Это реализуется на основе очередей входных и выходных сообщений, служащих своеобразными буферами.Основными различиями между реализациями диалогового процессора являются количество очередей /в первой реализации две очереди, во второй - четыре/-и организация переключения с очереди на очередь.
Внешнее информационное обслуживание предлагается обеспечивать тремя реализациями информационного процессора.В тех случаях, когда пользователь слабо ориентируется в возможност.ях пакета, планируется применение информационного обслуживания по принципу
- II -
"меню", на которое ориентирована первая реализация.Иногда более удобно организовывать информационное обслуживание по запросам без учета места и момента их выдачи, для чего предусмотрена вторая реализация информационного процессора.
Учет контекста при обработке запроса может существенно упростить работу пользователя, позволяя опускать большое количество подробностей.Третья реализация информационного процессора, учитывающая контекст запроса на информационное обслуживание, кроме своей основной функции, обеспечивает отслеживание состояния пакета.
Тот р'акт, что в состав системного наполнения пакета прикладных программ могут быть включены различные реализации системных модулей в различных комбинациях, требующие различной настшйки,' делает весьма затруднительным создание настраивающего процессора в монолитном виде. В проекте предлагается сборка настраивающего процессора из компонентов, каждая из которых обеспечивает настройку той реализации системных модулей, которая включается в системное наполнение конкретного пакета.
С целью проверки полноты и неизбыточности спроектированных реализаций системных модулей проводится рассмотрение возможных конфигураций системного наполнения пакетов для всех перечисленных в постановке задачи приложений.Показывается возможность создания эффективных системных наполнений пакетов прикладных программ для всех указанных приложений.
Описывается состав инструментальных средств инструментально-базовой системы, в который входят :
инструментальный языковый процессор, поддерживающий язык сборки ;
инструментальный диалоговый процессор, поддерживающий интер-
активный режим работы во время формирования заданий ;
инструментальный информационный процессор, ориентированный на режим работы типа "меню" ;
инструментальный настраивающий процессор для обеспечения расширяемости инструментально-базовой системы.
Іредлагаются способы эффективной реализации этих средств, указы-заются возможности использования в процессе создания системного іаполнения ППП штатных средств математического обеспечения.
С целью проверки правильности проекта рассматривается процесс создания пакета прикладных программ с помощью предлагаемой шструментально-базовой системы.
В четвертой главе кратко описывается реализация первой версии инструментально-базовой системы.Обосновывается и перечисля-этся состав реализованных средств, указываются ограничения реа-тизации каждой из выбранных компонент.Рассматриваются технические трудности, возникшие при использований средств штатного математического обеспечения ОС EG ЗВМ. Приводятся данные о результатах экспериментального использования инструментально-базовой зистемы при создании конкретного пакета прикладных программ цля статистического анализа данных, на основе которых делается вывод о практической применимости проекта.Намечаются дальнейшие перспективы реализации и применения предложенной ИБС.
В заключении сформулированы основные результаты работы.
Приложения содержат примеры использования инструментальных средств для создания и настройки пакета прикладных программ, а также примеры работы с пакетом.
Автор глубоко признателен Д.А.Корягину за научное руководство и постоянное внимание к работе.
- ІЗ -
Архитектурные спецификации ИБО
Постановку задачи будем формулировать следующим обтазом. Сначала проанализируем организацию работ и дисциплину проведения вычислений в приложениях, для которых предполагается разрабатывать пакеты программ.
Затем проведем рассмотрение процесса разработки liiill, что позволит нам определить как этапы работы, которые необходимо автоматизировать, так и системную квалификацию разработчиков ППП, на которую должна быть рассчитана ИБС.
И, наконец, на основе проведенных рассмотрений сфошулируем постановку задачи в виде требований к архитектуре инструменталь-но-базовой системы, которая может быть использована для автоматизации разработки пакетов, ориентированных на работу в указанных приложениях.
Обсукдаемую в настоящей работе инструментально-базовую систему предполагается в первую очередь использовать при разработке ППП, ориентированных на автоматизацию круга расчетных работ, характерных для ВЦ Иркутского политехнического института и Иркутского института народного хозяйства.В рамках этих работ выделим те приложения, в которых назрела необходимость автоматизации проведения вычислений в форме пакетов прикладных программ, рассматривая при этом как характерные для всех анализируемых приложений черты, так и особенности каждого из них.
Особенности первого приложения - статистического анализа данных - определим на примере ППП "Статистика", разрабатываемого в Иркутском институте народного хозяйства и являющегося объединением и развитием ІШП САЕР и ЇЇПП ГС [40,57] .Основной целью этого пакета является статистическая обработка результатов физических экспериментов /исследование солнечного ветра/, причем в состав задач, решаемых исследователями, входят : а. анализ в рамках модели случайной выборки /точное и интервальное оценивание, проверка и сравнение гипотез/ ; б. анализ в рамках стационарного эргодического случайного процес са /проверка на стационарность, корреляционный и спектральный анализ, идентификация в классе линейных моделей /; в. имитация случайных процессов с требуемыми характеристиками ; г. отбор входной информации по: - интервалам времени проведения измерений ; -, интервалам значений величин или их отношений ; - областям пространства. Пользователи данного пакета могут быть разделены на две основные группы.Первая - это физики,специалисты в области космических исследований, задача которых - определение статистических закономерностей в полученных ими данных. Ко второй группе относятся специалисты различных профилей /экономисты, инженеры, научные работники/, работающие в Иркутском институте народного хозяйства и проводящие относительно простую статистическую обработку своих данных. Общей чертой, объединяющей обе эти группы, является то, что входящие в них специалисты не являются профессиональными программистами. В то же время дисциплина проведения вычислений у этих двух групп совершенно различная.Дисциплина работы первой группы характерна тем, что в начаяе проводится большое число "пробных" расчетов, предназначенных для выявления статистических закономерностей в данных, отобранных по различным критериям.После того, как наличие искомой статистической закономерности /или её отсутствие/ обнаружено, проводятся ..,дальнейшие расчеты по проверке этих результатов на большем объеме данных. Для проведения расчетов поискового характера наиболее целесообразно использовать адаптивные алгоритмы.Очень часто такие алгоритмы основаны на применении трудноформализуемых критериев, вследствие чего выбор тех или иных вариантов дальнейших вычислений на основе уже полученной информации как правило, возлагается на человека.Естественно, что эффективная реализация таких алгоритмов требует организации интерактивного взаимодействия с пользователем. Правильность решений, принимаемых пользователем в процессе интерактивной работы с пакетом, существенно зависит от того, получил ли он своевременно всю необходимую ему информацию, или только её часть.Очевидно, что знание специфики используемого алгоритма, возможностей дальнейших вычислений, формы допустимых ответов так же важны для получения правильного результата, как и инйорма-ция, полученная во время предыдущих вычислений.Наиболее удобным способом удовлетворения таких информационных потребностей пользователя в процессе вычислений, по-видимому, является интерактивное общение его с пакетом прикладных программ.
Регламент модуляризации функционального наполнения
Язык заданий - одна из наиболее важных составляющих пакета, поскольку он является средством общения пользователя с liiili. Он позволяет описывать последовательность выполнения различных .действий, обеспечивающих решение задачи или постановку задачи, по которой такая последовательность строится автоматически.По сущест-зу, язык заданий отражает функциональные и архитектурные спецификации пакета, уровень его фактической тематической квалификации.
Прежде чем перейти к рассмотрению языков заданий, необходимо )тметить, что стиль, структура и форма таких языков существенно зависят от дисциплины проведения работ в автоматизируемых приложениях. Обычно выделяют две, в некотором смысле полярные, дисциплины [15,25] : пассивная дисциплина работы, предполагающая создание программ и проведение по ним расчетов с использованием предусмотренных в па кете алгоритмов и модулей,реализованных в функциональном наполнении; активная дисциплина работы, предусматривающая возможность ПРИ создании программ и проведении по ним расчетов осуществлять моди фикацию и расширение имеющегося в пакете прикладного программного фонда. Пассивная дисциплина характерна для работы так называемых око-ечных пользователей, то есть специалистов, не имеющих ггоофессио - 29 нальной подготовки в области програшлирования, в то время, как активная дисциплина свойственна, деятельности прикладных проглэ.ммис-тов, создающих и сопровождающих функциональное наполнение ППП. В соответствии с этими дисциплинами работы можно определить и два основных класса языков заданий.
Один из них - языки сборки [14,21-23,25,26] - соответствует активной дисциплине работы. Характерной особенностью таких языков является то, что они предназначены в основном для описания процесса сборки программ для проведения требуемых расчетов из модулей функционального наполнения или для модификации и развития прикладного программного фонда 1МІ. pмyлиpoвaниe заданий на этих языках требует наличия определенной квалификации в области программирования.
К другому классу относятся языки запросов [31,7,17,32] , соответствующие пассивной дисциплине работы.Как правило, эти языки имеют достаточно простой синтаксис, ШИРОКО используют лексику предметной области и ориентированы главным-образом на Формулирование содержательных постановок задач.
Ранее было отмечено, что во всех рассмотренных приложениях имеет место пассивная дисциплина проведения расчетов, поэтому пакеты, ориентированные на работу в этих приложениях должны использовать языки запросов. Это означает, что при решении своих задал с помощью ППП пользователи должны иметь возможность оперировать теми понятиями и действиями, которые используются не при программировании, а при постановке задачи в предметной области.В случае статистического анализа, например, вместо описания вызова подпрограммы построения гистограммы, пользователю более удобно сформулировать запрос в виде В процессе эксплуатации пакетов прикладных программ в условиях выявленного ранее постоянного развития рассмотренных приложений необходимо проводить расгаирение и модификацию программ функционального наполнения и языка заданий.Для этого язык заданий пакета, кроме средств, ориентированных на формулирование оконечным пользователем содержательных постановок задач, должен содержать в себе конструкции, предназначенные для осуществления такого расширения и модификации прикладными программистами.
Регламент модуляризации функционального наполнения 111111 является системной характеристикой, определяющей принятую разработчиками форму представления программного материала в функциональном наполнении, а также способ его создания и развития.
Центральным моментом регламента модуляризации является понятие модуля функционального наполнения, ПРИ определении которого обычно подчеркивают два его основных свойства - конструктивность и совместимость.При -том, под конструктивностью понимается потенциальная применимость для решения некоторой части задачи из соответствующей предметной области, а под совместимостью - реальная приспособленность модулей к совместной работе.
Говоря о регламенте модуляризации, обычно уделяют основное внимание свойству совместимости модулей, поскольку их конструктивность в большей степени определяется неформально разработчиками ПШ1 на основе модульного анализа алгоритмов предметной области.
Можно выделить три основные варианта регламента модуляшзачии - внутреннюю, внешнюю и смешанную модуляризацию ГіЗ,І4і. Принцип внутренней модуляризации предполагает, что все положения регламента модуляризации должны быть соблюдены на ртапе разработки программных тел модулей.При этом фиксируется не только форма представления модуля, но и способы организации интерфейса как по данным, так и по управлению. Такой регламент модуляризации представляется наиболее целесообразным в случае создания Флгнкцио-наяьного наполнения "с самого начата" или использования у?,е готового стандартизованного программного фонда, поскольку не требует создания специализированных системных средств поддержки интерфейса.
В свою очередь, внешняя модуляризации означает, что системная адаптация /обеспечение совместимости/ программного материала осуществляется не при составлении програші, а на этапе включения их в функциональное нэлолнение пакета.Иначе говоря, програти, обладающие свойством конструктивности, при включении в функциональное наполнение дополняются некоторыми "описаниями", обеспечивающими совместимость на основе использования специальных средств.
Процессор исполнения расчетных цепочек
Исполнение расчетных цепочек может осуществляться двумя основными способами. В случае использования техники компиляции, по заданной цепочке генерируется текст программы на некотором базовом языке /возможно, в объектном коде/, после чего дальнейшая обработка программы и проведение расчетов выполняется уже с помощью ттатн ту; средств математического обеспечения.
При использовании техники интерпретации процессы генерации рабочей программы и расчета выполняются квазипараллельно под управлением системного обеспечения пакета. Оба тих способа имеют свои достоинства и недостатки.В случае закрытого режима обработки наиболее целесообразно использовать метод компиляции,, в случае интерактивного режима - интертгоета-ции І46КТак, например, при обучении студентов предпочтительнее использование интерпретации, а пріЦдлительньтх расчетах электроэнергетических сетей - метода компиляции. Анализируя дисциплину проведения вычислений в приложениях, мы видели, что в ряде случаев /например, при статистической обработке .данных/ необходимо проведение многосеансовых расчетов с одними и теми же .данными. Это требует обеспечить хранение данных в пакете на период между сеансами.Для этой цели, в частности, могут быть использованы системные средства поддержки полужесткого интерфейса. Если модули функционального наполнения имеют однородную Форму представления и одинаковые способы использования при генерации рабочей программы, то хранение их может быть обеспечено штатными средствами математического обеспечения.Поскольку наиболее устоявшейся формо4 представления программного материала в описанных приложениях является отдельно взятая подпрограмма /процедура/ в виде загрузочного модуля, то для хранения функционального наполнения не надо создавать никаких специальных средств. Как уже отмечалось, приложения, на которые мы ориентируемся, требуют реализации двух основных форм общения пользователя с пакетом - закрытого режима и интерактивного взаимодействия. Закрытый режим характерен для проведения длительных расчетов с использованием алгоритмов, не требующих вмешательства человека в. их работу.Например, закрытый режим наиболее целесообразен для проведения многосеансовых статистических расчетов рутинного характера или для расчета электроэнергетических сетей. Интерактивный режим более соответствует задачам исследовательского . или проектного характера, когда трудно или невоз - 39 можно заранее полностью определить порядок ведения вычислений в силу, например, неформальности логики управления протіессом обработки. Возможны два варианта такого режима в зависимости от того, предоставляется ли возможность интерактивного взаимодействия только в период генерации рабочей программы, или и в процессе счета. Первый вариант можно рекомендовать для обучения студентов, а второй - для решения задач статистической обработки данных, связанных с поиском статистических закономерностей при выборе данных по различным критериям. При анализе языков запросов отмечалось, что в них должны иметься изобразительные средства для модификации и расширения языка заданий и функционального наполнения, ориентированные на прикладных программистов.Естественно, что для их поддержки необходимо наличие и соответствующих системных средств настройки, выполняющих такую модификацию. И, наконец, для выполнения целого ряда работ по эксплуатации пакета, та.ких, как создание документации, копирование и восстановление данных, специфических для соответствующих пакетов, отладки Функционального наполнения и т.п., желательно иметь дополнительные сервисные средства. Итак, пакеты прикладных программ, создаваемые для автоматизации проведения расчетов в рассмотренных приложениях, должны удовлетворять определенным выше спецификациям, сведенным в табл. I. Как видно из этой таблицы, имеет место значительное сходство системных: показателей пакетов прикладных программ, предназначенных для автоматизации расчетов в перечисленных приложениях. Это обстоятельство позволяет использовать одни и те же , , решения цля обших показателей, что подтверждает целесообразность создания инструментально-базовой системы, ориентированной на данные приложения. В то же время в отдельных случаях имеющиеся различия- требуют принятия частных решений. Рациональное сочетание общих и частных решений при создании системного наполнения конкретных пакетов прикладных програм может быть достигнуто на основе модульного принципа.Иными словами, реали-зационые решения, обеспечивающие некоторые системные показатели, должны быть локализованы в рамках отдельных системных модз лей. Теперь, опираясь на сформулированные спецификации перейдем к определению состава базовой компоненты инструментально-базовой системы.
Реализация инструментальных средств
Принятый в настоящей работе подход к созданию инструменталь-но-базовых систем позволяет рассматривать их как некоторое пакеты для формирования системного наполнения ППП в конкретных приложениях. Поскольку инструментальные средства ИБО своим аналогом в ППП имеют системное наполнение, то имеет смысл определить спецификации этих средств таким же образом, как ранее определялись системные показатели ППП.
Вопрос об инструментальных средствах ЙБС, используемых для формирования системного наполнения пакетов прикладных пшгтамм, тесно связан с регламентом модуляризации и формой представления базовых средств.
До сих пор системные модули рассматривались только в конструктивном аспекте, без учета формы их представления и способа организации межмодульного интерфейса. Для обеспечения их согласованности теперь необходимо определить регламент модуляризации.
В связи с тем, что системные модули для разрабатываемой ИБС должны реализовываться заново, естественно применить ПРИ их создании внутренний регламент модуляризации.Сравнительно небольшое число таких модулей /а также сопряжений между ними/ и высокие требования к Э ффективности формируемого из них системного наполнения мотивируют организацию их взаимодействия на основе жесткого интерфейса.
Широкое применение ухе имеющихся средств штатного математического обеспечения, таких, как макропроцессоры, КОМПИЛЯТОРЫ, редакторы связей, для формирования системного наполнения может существенно упростить и удешевить как реализацию инструментальных средств ЙБС, так и пооцесс генерации.В этих условиях сборка конкретного экземпляра системного наполнения могла бы осуществляться несколькими способами.
Один из них заключается в том, что системные модули представляются в форме загрузочных модулей, а формирование системного наполнения осуществляется штатными средствами редактирования связей из выбранных разработчиком пакета модулей.Такой способ достаточно прост и эффективен, но, к сожалению, оставляет слишком мало возможностей даже для параметрической настройки программ.
Другой способ предполагает использование методов макрогенета-ции.При ,;)Том все системные модули оформляются в виде макроопределений, обработка которых при заданных параметрах обеспечивает получение текста, пригодного для обработки штатными средствами математического обеспечения, с последующим получением загрузочных модулей системного наполнения.Такой способ предоставляет широкие возможности для настройки, однако может потребовать слишком много времени для осуществления генерации даже простейших конфигураций системного наполнения.
При третьем способе системные модули рассматриваются не как нечто неделимое, а как совокупность нескольких подмодулей.Те подмодули, которые не требуют настройки, оформляются в виде загрузочного кода, те же, которые необходимо настраивать - в виде макроопределений. Вариант системного модуля, предназначенный для работы в составе конкретного пакета может быть получен после мэкрообра-ботки соответствующих макроопределений с последующей компиляцией, объединением и редактированием связей с уже готовым загрузочным кодом и будет представлять собой один загрузочннй модуль.В этом случае системное наполнение пакета прикладных программ может быть сформировано из подготовленных таким образом реализаций системных модулей с помощью средств штатного математического обеспечения. Третий способ сочетает простоту и эффективность первого с широкими возможностями цля настройки второго и представляется наиболее целесообразным.
Таким образом, задачей инструментальных средств является выбор в соответствии с заданием необходимых подмодулей, организация макрообработки тех из них, которые требуют настройки, и осуществление собственно формирования системного наполнения. Задание на. генерацию системного наполнения при этом естественно Формулировать на языке сборки.
Выбранный способ сборки позволяет переложить значительную часть работы по созданию системного наполнения конкретного пакета на уже имеющиеся средства штатного математического обеспечения.
Хранение системных модулей может быть реализовано средстваш также штатного математического обеспечения, поскольку способ использования одних и тех же подмодулей всегда одинаков.
Ограниченное число возможных конфигураций системного наполнения пакетов в рассмотренных приложениях позволяет сделать вывод о целесообразности реализации в инструментальных средствах методов полуавтоматического планирования.
Поскольку в процессе создания ППП не производятся какие-либо расчеты, результаты которых имеют самостоятельное знэление, то нет необходимости во включении Функции хранения данных в состав инструментальных: средств.
