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