Определение плагин-модулей и их подключение
Пятый, заключительный этап отвечает за определение необходимых параметров, которые задаются в спецификации к компоненте и требуются для формирования конечного кода. Поскольку может существовать целый набор подключаемых компонент, то ясно, что количество требуемых спецификаций должно в точности совпадать с величиной такого набора -- по одной спецификации на компоненту. Далее такую спецификацию будем называть плагин-модулем.
Плагин-модуль -- это конкретная спецификация с определенными параметрами для подключения компоненты, основанная на структуре, выработанной на третьем этапе. Используя имя компоненты, плагин-модуль указывает на ее файл регистрации, который, в свою очередь, и определяет набор текстовых блоков. При использовании некого управляющего приложения, на основе плагин-модуля формируются текстовые фрагменты, которые инсталлируются в гнезда исходного кода, указанные в данной спецификации и в самой компоненте. Также к плагин-модулю будем относить совокупность гнезд, необходимых для работы компоненты. Их основной задачей является указание мест встраивания соответствующих частей компонент. Например, плагин-модуль для простой вставки html текста в гнездо вызова компоненты и в блок <STYLE>,может иметь следующий вид:
(1)<!--!{(point,2)} -->
(2)<COPY>
(3) <MAKESTYLE>
(4) .bg {background: #ffffff; text-align: center}
(5) </MAKESTYLE>
(6) <DATA>
(7) <a href="picture1.html">pic1</a>
(8) <a href="picture2.html">pic3</a>
(9) <a href="picture3.html">pic4</a>
(10)</DATA>
(11)</COPY>
Здесь, в строке (1) указываются два управляющих параметра: имя гнезда для вставки тегов, заданных в строках (7)-(9) и приоритет для данного блока. Тег из строки (4) будет добавлен в блок <STYLE> генерируемого текста. Особенностью приведенного примера является тот факт, что у нас определено единственное гнездо, хотя предполагается появление двух независимых фрагментов (основного текста и стиля). Это объясняется тем, что недостающее гнездо явно указано в файле регистрации. Данный факт как раз показывает на “плавающий” характер управляющих параметров, часть которых может присутствовать в самом плагин-модуле, а часть -- в файле регистрации.
Структурная схема взаимодействия компонент кода и управляющего приложения
Работу приведенного алгоритма построения модифицируемого приложения следует рассматривать, как взаимодействие частей кода (рис. 1.) Схематично связь между отдельными частями кода во время сборки может быть представлена следующим образом:
Рис. 1. Структурная схема взаимодействия компонент кода и управляющего приложения
1. На начальной стадии управляющему приложению передается исходный код и плагин-модуль, удовлетворяющий необходимой структуре;
2. На основе плагин-модуля выясняется имя подключаемой компоненты, по которой определяется файл регистрации. В исходном коде локализуются гнезда.
3. Файл регистрации предоставляет управляющему приложению полную информацию о XSL стилях;
4. Исходя из плагин-модуля, его структуры (XML) и полученных XSL стилей формируются необходимые текстовые блоки;
5. На последнем этапе осуществляется инсталляция полученных фрагментов кода в найденные гнезда.
Заключение
Предложенный подход описывает построение инструментальных свойств для эффективного сопровождения и написания программы, а также позволяет:
? в кратчайшие сроки осуществлять всевозможные безболезненные (не затрагивающие имеющийся код) модификации;
? максимально повторно использовать код и данные;
? отделять логику приложения от содержания и дизайна;
Рассмотренный алгоритм построения кода позволяет реализовать мощные модифицируемые комплексы в различных средах, начиная от текстов программ и, кончая текстами обыкновенных статей. Действительно, в отличие от высокоуровневых языков, с процедурами, функциями и ООП подходом, призванных реализовывать декомпозицию, подобных средств при работе с обычными текстовыми файлами не существовало. К такого рода файлам можно отнести и HTML с его цельной текстовой структурой. Отдельно отметим, что предлагаемый подход не накладывает какие-либо ограничения на язык написания программы: он не сужает синтаксис и семантику используемых средств, а только предписывает некие требования к структуре программы
Список литературы
1. Горбунов-Посадов М.М. Безболезненное развитие программы. Открытые системы 1996, № 4, с. 65-70
2. Фуксман А.Л. Технологические аспекты создания программных систем. - М.: Статистика, 1979, 184 с.
3. Агафонов В.Н. Языки и средства спецификации программ // Сб. статей «Требования и спецификации в разработке программ». - М.: Мир, 1984, с. 285