М.М. ГОРБУНОВ-ПОСАДОВ - Системное обеспечение пакетов прикладных программ (1184225), страница 8
Текст из файла (страница 8)
Если же планируемое число комбинацийквазимодулей в формируемых расчетных программах невелико и может бытьточно определено заранее, внешнюю модуляризацию имеет смыслвыполнять путем разработки для каждого квазимодуля специальнойпрограммы (программного адаптера), обеспечивающей его совместимость сконкретными модулями функционального наполнения.В пакетах, осуществляющих планирование вычислений, применяетсясмешанная модуляризация, сочетающая возможности обоих подходов. Тут засчет соблюдения соответствующего внутренней модуляризации регламентапрограммирования функционального наполнения минимизируют издержки,связанные с организацией межмодульного интерфейса, а средства внешнеймодуляризации используют для описания семантики модулей, условий ихприменимости, цен и других показателей, необходимых для автоматическогопланирования вычислений [71].1.5.
Конфигурации модулейИтак, мы выяснили, каким образом проводится модульный анализпредметной области и как на его основе формируется базисный наборпрограммных модулей пакета. Рассмотрим теперь, какие конфигурациимогут образовывать эти модули в расчетных программах и какие существуютспособы задания конкретных конфигураций.Во многих пакетах все расчеты ведутся по одной слабо меняющейсясхеме. Ей соответствует вполне определенная структура всех формируемыхпакетом расчетных программ.
Многообразие проводимых расчетов здесьдостигается неколичеством схем счета, а многочисленными вариантами заполнения гнездфиксированной программной структуры - каркаса.Например, в функциональном наполнении пакета может содержатьсянесколько модулей, реализующих различные методы расчета. Но в структурепрограммы для них предназначается единственное гнездо «МЕТОД», вкоторое по указанию пользователя при формировании расчетных программподставляется тот или иной модуль.При данном подходе, который мы будем называть каркасным, ненакладывается ограничений на способы взаимодействия модулей. Однакосвободой выбора способов взаимодействия разработчик пакета пользуетсятолько на стадии проектирования каркаса программы, а в дальнейшем всемодули должны программироваться в строгом соответствии свыработанными при проектировании каркаса требованиями к заполнениюгнезд.Единообразное оформление модулей, принадлежащих одному гнездукаркаса, позволяет достаточно свободно сочетать в вариантах расчетныхпрограмм различные комбинации модулей.
Можно численно оценитьмощность множества расчетных программ, генерируемых пакетом прикаркасном подходе. Пусть в спроектированном каркасе содержится п гнезд идля i-го гнезда (1 ≤ i ≤ n) существует тi различных реализующих егомодулей. Тогда число Р расчетных программ, которые могут быть, вообщеговоря, порождены на базе данного функционального наполнения,выражается формулойОтметим, что при реальных расчетах возникают не все потенциальнодопустимые комбинации модулей.
Тем не менее во многихпроизводственных пакетах фактически используемое число вариантовблизко к приведенной оценке.Нетрудновидеть,чтокаркасныйподходобеспечиваетбезболезненность (см.п.1.3) развития программного фонда пакета.Действительно, развитие фонда идет, как правило, за счет написанияновых модулей-реализаций для выделенных гнезд каркаса программы.Появление такого нового модуля никак не затрагивает тексты ни егососедей по гнезду, ни вызывающих его модулей, т.е. проходит безболезненно.
Соседи по гнезду никогда не соседствуют в расчетныхпрограммах, а вызывающие модули программирова-лись в рамках соглашений каркаса и потому могут с равным успехомобращаться к любой (в том числе и к новой) реализации гнезда.При каркасном подходе для задания конкретной конфигурациинеобходимо для каждого гнезда каркаса программы указать, какой именномодуль из соотнесенного гнезду семейства должен быть помещен в этогнездо. Для этого на языке заданий пакета записывается совокупность парвида<имя гнезда> = <имя модуля>которая полностью определяет расчетный вариант. Некоторые способыупрощения задания конфигурации при каркасном подходе будут разбиратьсяв последующих главах при рассмотрении производственных пакетов.Реже встречаются предметные области, в которых многообразие связеймодулей по управлению удается ограничить последовательным выполнениеммодулей, не жертвуя при этом ни удобством составления программ, ниэффективностью их выполнения.
Расчетная программа здесь представляетсобой цепочку выполняемых друг за другом модулей, из-за чего данныйподход будем называть цепочечным.Обычно состав и порядок следования модулей в цепочке определяетсянекоторой внешней конструкцией, называемой планом вычислений. Новстречаются и пакеты, где в ходе выполнения цепочки каждый очередноймодуль сам динамически выбирает себе преемника.Кажый из модулей цепочки может вызывать какие-либо подпрограммы.Однако с точки зрения цепочечного подхода внутренние управляющиеструктуры звеньев цепочки несущественны, т.е.
вызываемые модулямиподпрограммы обезличены и цепочка воспринимается как линейнаяодноуровневая структура. Все манипуляции при формировании расчетныхвариантов программ не выходят, вообще говоря, за рамки различныхпоследовательностей модулей, вызываемых на одном, самом верхнем уровне.Напомним, что при каркасном подходе модули, формирующие расчетныйвариант, заполняют гнезда каркаса программы, которые могут располагатьсяна любом уровне иерархии управляющих связей.Столь жесткое ограничение, накладываемое на управляющие связицепочечным подходом, отчасти компенсируется тем, что положение модуля вцепочке, в отличие от каркасного подхода, не фиксируется.
Любой модульможет быть, вообще говоря, включен в любую позицию цепочки.Если считать, что модули в цепочке могут многократно повторяться, томожно заключить, что потенциально цепо-чечный подход на любом непустом наборе модулей позволяет генерироватьбесконечное число расчетных программ. Если даже ограничиться не болеечем однократным включением модуля в цепочку и считать порядок модулейв цепочке несущественным (в реальных пакетах нередко ни то, ни другоеограничение не выполняется), то тем не менее оценка числа Р потенциальновозможных расчетных программ составитР = 2м,(2)где М - число модулей в пакете.
Даже такая заниженная оценка выглядитнамного внушительнее, чем оценка (1) каркасного подхода. Однако напрактике при достаточно большом М подавляющая часть потенциальновозможных цепочек никогда не реализуется.Популярности цепочечного подхода в немалой степени способствует тообстоятельство, что многие современные операционные системы (преждевсего UNIX) предоставляют удобные средства для применения цепочечногоподхода при организации связей между задачами. В частности, в языкахуправления заданиями операционных систем часто встречается конструкция,инициирующая последовательное выполнение серии задач (программ),причем выходной поток каждой предшествующей задачи используется вкачестве входного потока для следующей за ней.
Эта конструкция позволяет,например, компактно и наглядно задать цепочку различных типовыхпреобразований данных, предназначенную для формирования печатногодокумента.В монографии [77], написанной под несомненным влиянием концепцийсистемы UNIX, предпринимается попытка применения цепочечного подходак программированию задач вычислительной математики. Автор считает этотподход одним из средств достижения повторной используемости(«переиспользуемости») программ. Все же основная масса крупныхпрограммных комплексов для решения вычислительных задач опирается накаркасный подход, который имеет не меньше оснований претендовать нароль инструмента для обеспечения повторной используемости.Относительно неширокая распространенность цепочечного подходаобъясняется, по-видимому, тем, что накладываемые им суровые ограниченияна управляющие связи модулей влекут за собой существенные трудностипри программировании и определенные потери эффективности привыполнении программ.В то же время для некоторых предметных областей, в частности, дляэлектротехнических расчетов, применениецепочечного подхода оказывается весьма плодотворным.
Цепочечная схемаудобна и при организации обработки результатов натурных иливычислительных экспериментов. Тут отдельные модули могут вычленятьинтересующиеэкспериментатораданные,различнымобразомпреобразовывать их и выводить на различные устройства визуализации.Наконец, цепочечный подход полезен в задачах искусственного интеллекта,когда непосредственное программирование решаемой задачи по каким-либопричинам затруднено или невозможно и в функции пакета входитпостроение алгоритма решения на базе имеющихся в пакете модулей и ихспецификаций.Цепочечный подход обеспечивает безболезненность развитияпрограммного фонда.
Если вновь написанный модуль соответствуеттребованиям аппарата формирования цепочек, то он легко вольется вколлектив написанных ранее модулей, поскольку появление его неповлечет за собой какой-либо переделки их текстов.Простейшая конструкция языка заданий пакета при цепочечномподходе - перечисление входящих в цепочку модулей. Если жеформируемая цепочка достаточно длинна или же явное перечислениемодулей по каким-то причинам неудобно, то используются более развитыеконструкции языка заданий, речь о которых пойдет в следующем разделе.Здесь остается только заметить, что многообразие схемконфигурирования модулей в пакетах не исчерпывается каркасным ицепочечным подходами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
