Регламент модуляризации функционального наполнения

Вернемся к определению модуля как конструктивного элемента, используемого на различных стадиях функционирования пакета. Что понимается здесь под конструктивностью модуля?

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

- формы представления программных модулей;

- способы организации информационных связей (через аппарат параметров, общие области памяти, общие файлы);

- методы разработки (сверху вниз, снизу вверх и др.)

программных комплексов, применяемые в приложении;

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

- ограничения на размеры прикладных программ;

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

Требования, вытекающие из алгоритмической и технологической конструктивности, а также из некоторых других свойств модулей, составляют в совокупности регламент модуляризации, т.е. принятую разработчиками пакета форму представления материала в функциональном наполнении, а также способы его создания и развития. Если описание языка задания рассматривать как спецификацию «сопряжения» пользователя с пакетом, то посредством регламента модуляризации определяется «сопряжение» с функциональным наполнением его разработчиков.

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

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

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

Таким образом, можно выделить два подхода к формированию регламента: внутреннюю и внешнюю модуляризации.

Внутренняя модуляризация предполагает, что совместимость модулей достигается за счет соблюдения всех требований регламента в период разработки программных тел модулей. Регламент фиксирует, в частности, способы организации интерфейса между модулями как по управлению, так и по данным. Внутреннюю модуляризацию используют при разработке пакета «с нуля». Кроме того, если программный фонд уже существует, но стандартизирован в соответствии с некоторым соглашением, регламент модуляризации пакета может наследовать регламент программного фонда, наследуя тем самым и совместимость модулей. При внутренней модуляризации обычно не требуется специальных системных средств поддержки межмодульных интерфейсов, совместимость модулей обеспечивается штатными средствами редактирования межмодульных связей.

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

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

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

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