Структура функционального наполнения

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

программ, где с помощью одной программы стараются охватить возможно более широкий класс задач. Главное достоинство пакетного подхода к модуляризации – возможность безболезненного развития программного фонда. Напротив, развитие «универсальной» программы всегда сопряжено с изменениями текстов написанных ранее частей программы. Вместе с тем необходимо отметить, что с пакетным подходом связана серьезная технологическая проблема – как организовать взаимодействие существующих модулей с вновь создаваемыми? Известно ее решение в рамках технологии искусственного интеллекта. С каждым модулем связывается и записывается в функциональное наполнение формальное описание его входных/выходных данных и условий его применимости, а вместо непосредственных вызовов модулей используются вызовы «по образцу», определяющие не конкретный модуль, а лишь стоящую перед ним задачу. Поэтому вновь появившийся модуль никак не воздействует на тексты модулей – своих потенциальных потребителей. Эти модули автоматически найдут его из-за соответствия его описания выставленным ими запросами. В существующих пакетах программ технология искусственного интеллекта применяется относительно редко, так как она часто приводит к значительной потере эффективности и требует от разработчиков пакета свободного владения весьма нетривиальным логическим аппаратом. В большинстве случаев, однако, удается найти более экономичное решение стоящих перед пакетом задач на основе существенно более простых программных конструкций. Действительно, во многих пакетах все расчеты ведутся по одной слабо меняющейся схеме. Ей соответствует вполне определенная структура всех формируемых пакетом расчетных программ. Многообразие проводимых расчетов здесь достигается не количеством схем счета, а многочисленными вариантами заполнения «гнезд» фиксированной программой структуры-каркаса. Например, в функциональном наполнении пакета может содержаться несколько модулей, реализующих различные методы расчета. Но в структуре программы для них предназначается единственное гнездо «Метод», в которое по указанию пользователя при формировании расчетных программ подставляется тот или иной модуль. При данном подходе, который называется каркасным, не накладывается ограничений на способы взаимодействия модулей. Однако свободой выбора способов взаимодействия разработчик пакета пользуется только на стадии проектирования каркаса программы, а в дальнейшем все модули должны программироваться в строгом соответствии с выработанными при проектировании каркаса требованиями к заполнению гнезд. Нетрудно видеть, что каркасный подход обеспечивает безболезненность развития программного фонда пакета. Появление нового модуля никак не затрагивает тексты ни его соседей по гнезду, ни вызывающих его модулей. Соседи по гнезду никогда не соседствуют в расчетных программах, а вызывающие модули программировались в рамках соглашений каркаса и потому могут с равным успехом обращаться к любой (в том числе и к новой) реализации гнезда.

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

Дата добавления: 2014-03-04; просмотров: 308; Нарушение авторских прав

Мы поможем в написании ваших работ!