Модель пакета прикладных программ

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

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

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

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

А. Выполнить описание этой задачи, т.е. в конечном итоге описать соответствующую программу и исходные данные . При этом . Описания , и задаются соответственно на языках описания задач , программ и данных , для которых .

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

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

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

В соответствии с проведенными описаниями ППП определяется следующими компонентами:

системным программным компонентом , в функции которого входят порождение прикладных программ, контроль за их исполнением и обеспечение их исполнения; проблемным программным компонентом р в виде совокупности модулей , или готовых программ ,;

языковым компонентом , содержащим средства описания создаваемых прикладных программ и исходных данных для ихработы;

внутренней базой данных.

Формальное представление ППП:

, где .

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

В работе [8] проведено сравнение первого (ППП С - типа) и третьего (ППП D – типа) путей решения задач; второй путь отличается от первого только тем, что созданная программа не запоминается на будущее. В пакетах С -типа одна сконструированная программа может использоваться при решении различных вариантов задач, т.е. исполняться много раз, в то время как в пакете D -типа конструирование программы производится всякий раз при решении каждого варианта. Кроме того, в течение всего времени работы пакета D -типа требуется ресурс памяти для разрешения его программного процессора. Программный процессор выполняет функции: интерпретации задания, на каждом шаге которой происходит вызов в работу некоторого программного модуля и осуществляется контроль его аргументов и результатов; контроля работы цепочки модулей; обмена данными между объектными модулями и внешней средой; обеспечения взаимодействия между процессором и объектными модулями по управлению и передаче данных; обеспечения передачи данных между внутренней и внешней базами данных.

Поэтому при решении одного и того же множества вариантов задач С – пакет оказывается более экономичным с точки зрения требований к ресурсам ЭВМ. В то же время при необходимости изменения модульного состава D - пакет оказывается более гибким и оперативным, нежели С -пакет. Действительно, при замене, например, одного модуля на другой в D-пакете нужно произвести замену только этого модуля, в то время в С -пакете придется вновь сконструировать все программы, в состав которых входил заменяемый модуль. Этот момент существенно затрудняет эксплуатацию С–пакетов, особенно при большом количестве готовых программ. Кроме того, в С - пакете вхождение одного модуля в объектном виде в разные программы требует повышенных ресурсов библиотечной памяти по сравнению с D -пакетом, в котором такое явление отсутствует.

Подготовка расчетов в D -пакете более трудоемка, так как в этом случае нужно задавать информации не только об исходных данных варианта (как в С -пакете), но и о требуемой программе (цепочке модулей) расчета. В то же время изменять ход вычислительного процесса в пакете, но и о требуемой программе (цепочке модулей) расчета. В то же время изменять ход вычислительного процесса в D -пакете проще, так как для этого в принципе нужно только остановить его работу в нужном месте, составить новые задания на дальнейший ход вычислительного процесса и запустить работу пакета дальше. Эти операции выполняются проще, если реализованы процедуры диалога пользователей с ЭВМ. В С-пакете подобное управление вычислительным процессом должно программироваться заранее внутри модулей и реализовываться заданием соответствующих исходных данных для варианта.

Таким образом, С -пакеты выгодны для относительно устойчивых предметных областей и групп пользователей, для которых характерны массовые (поточные) расчеты вариантов задач с помощью программ пакета. Такие расчеты связаны, например, с выбором оптимальных конструкций измерительных установок и приборов при их создании и модернизации, выбором оптимальных режимов их работы.

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

Использование для одного вычислительного эксперимента двух типов пакетов целесообразно только при условии единства модульного фонда. Отсюда возникает задача разработки такого представления программного модуля, которое отвечало бы условиям функционирования модуля в составе как С - пакета, так и D - пакета.

рис.2.1.Общая схема процесса вычислительного эксперимента.