Оболочка модульных программных систем со встроенными средствами развития

Размещено на http://www.allbest.ru

ОБОЛОЧКА МОДУЛЬНЫХ ПРОГРАММНЫХ СИСТЕМ СО ВСТРОЕННЫМИ СРЕДСТВАМИ РАЗВИТИЯ

В.П. Чистов, Р.Н. Шакиров

Россия, г. Екатеринбург

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

ВВЕДЕНИЕ

В создании, развитии и эксплуатации программных систем принимают участие три категории специалистов:

РАЗРАБОТЧИКИ системы в целом и отдельных ее проблемно-ориентированных модулей.

АДМИНИСТРАТОР, поддерживающий функционирование системы и развивающий ее.

КОНЕЧНЫЕ ПОЛЬЗОВАТЕЛИ - проблемные специалисты, использующие систему по прямому назначению.

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

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

Чтобы обеспечить такую возможность по отношению к администратору, следует снабдить систему встроенными СРЕДСТВАМИ РАЗВИТИЯ, исключающими необходимость в программировании. В каком-то смысле средства развития должны быть интеллектуальными, ибо они должны позволять администратору формулировать указания по развитию на уровне ЧТО сделать, а не КАК. Для этого необходимо канонизировать структуру модульной ПС и ее человеко-машинный интерфейс.

1. КАНОНИЧЕСКАЯ СТРУКТУРА МОДУЛЬНОЙ ПС

ПС представляется в виде совокупности проблемных модулей Mi, совместимых по формам представления данных Di и связанных в схемы потоков данных (СПД, пример на рис.1a).

Проблемные модули представляются в виде исполняемых программ базовой операционной системы. Информационный обмен между модулями выполняется через инструментальную базу данных (ИБД). ИБД состоит из БУФЕРОВ, в которых ведется обработка данных, и БИБЛИОТЕК, в которых идет накопление данных для повторного использования (рис.1б).

Кроме ИБД могут использоваться следующие вспомогательные средства хранения информации:

АРХИВ, предназначенный для долговременного хранения информации и переноса ее с одной машины на другую.

ВНЕШНЯЯ БАЗА ДАННЫХ, содержащая информацию в ином формате, не поддерживаемом программами ПС.

1.1 Инструментальная база данных

Для большинства приложений достаточна описанная ниже трехуровневая структура ИБД. Основной структурной компонентой ИБД является библиотека. Библиотека состоит из поименованных РАЗДЕЛОВ, в которых хранятся ОБЪЕКТЫ (проекты, функциональные компоненты и т.п.). Однотипные библиотеки группируются в КАНАЛЫ (рис. 2a). Для каждого канала декларируется структура раздела в виде множества ОПИСАНИЙ, предусмотренных для представления объекта (рис. 2б).

Каждое описание в общем случае представляется матрицей ЗНАЧЕНИЙ, где строки соответствуют АТРИБУТАМ объекта, а столбцы - индексированным вариантам их представления. В частном случае описание может быть простым атрибутом, строкой, столбцом атрибутов и, наконец, матрицей. Объем и формат значений может быть произвольным. В частности, они могут содержать ссылки на другие разделы той же или другой библиотеки.

Для организации доступа к объектам библиотеки создается БИБЛИОТЕЧНОЕ ОКНО (пример на рис.3), состоящее из перечня разделов и меню операций. Операции делятся на три группы:

Операции просмотра данных.

Библиотечные операции над разделами.

Услуги для поиска ссылок между объектами и удаления иерархий неиспользуемых объектов.

Для обработки объект извлекается (копируется) из раздела библиотеки в буфер (п. 2.3). В каждом буфере может находиться один объект произвольной структуры. После обработки объект может быть записан в любой раздел той же или другой библиотеки.

1.2 Проблемные модули, действия и процедуры

Все проблемные операции в ПС выполняются с помощью проблемных МОДУЛЕЙ, которые создаются разработчиками и предоставляются администратору в готовом виде.

Проблемные модули могут объединяться в иерархические проблемные ДЕЙСТВИЯ, представляемые в виде СПД. Для каждого действия задаются атрибуты ИБД с входными и выходными данными.

Проблемные ДЕЙСТВИЯ могут объединяться в последовательные проблемные ПРОЦЕДУРЫ с передачей данных через общие атрибуты ИБД. Для каждой процедуры декларируется ТЕНЕВОЕ ПРОБЛЕМНОЕ ОКНО (п. 2.3), позволяющее проходить процедуру по шагам.

1.3 Оболочка ПС

Для управления обработкой данных конечному пользователю предоставляется интерактивная оболочка ПС в виде иерархии ПРОБЛЕМНЫХ ОКОН.

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

В проблемном окне предусматриваются следующие операции:

ВЫБОР исходных данных из библиотек в буфера проблемного окна, для чего вызывается библиотечное окно.

Вызов действий и процедур для обработки данных в буфере. Вместо вызова процедуры может быть выполнен переход в ее ТЕНЕВОЕ ПРОБЛЕМНОЕ ОКНО для прохождения процедуры по шагам.

Вызов данных на экран для просмотра.

Переходы в СОПРЯЖЕННЫЕ ПРОБЛЕМНЫЕ ОКНА для выполнения вспомогательных операций над данными. Сопряженное окно использует буфера предшествующего окна.

ЗАПИСЬ результатов из буферов в библиотеки, для чего вызывается библиотечное окно.

2. ВСТРОЕННЫЕ СРЕДСТВА РАЗВИТИЯ ПС

Оболочка ПС может использоваться в двух режимах: в РЕЖИМЕ ЭКСПЛУАТАЦИИ и в РЕЖИМЕ РАЗВИТИЯ. В режиме эксплуатации доступны все ранее реализованные прикладные функции. Режим развития может использоваться только администратором ПС, которому разрешается:

Декларировать и модифицировать структуру ИБД путем декларации каналов, библиотек и описания структуры раздела в каждом канале ИБД.

Декларировать проблемные действия и процедуры, а также таблицы для отображения данных и режимных параметров проблемных модулей.

Декларировать оболочку ПС путем создания проблемных окон.

Переход в режим развития может выполняться из любого окна путем вызова меню развития. Возврат в режим эксплуатации происходит при выходе из меню развития.

2.1 Декларация структуры ИБД

Для декларации структуры ИБД из меню развития вызывается КАТАЛОГ КАНАЛОВ ИБД, в котором разрешается:

Создавать и удалять каналы.

Декларировать структуру разделов в КАТАЛОГЕ АТРИБУТОВ.

Создавать и удалять библиотеки в КАТАЛОГЕ БИБЛИОТЕК.

Декларировать библиотечное окно канала.

2.2 Декларация действий, процедур и таблиц

Проблемные модули создаются вне системы развития и помещаются в каталог проблемных модулей вместе с сопровождающей информацией, необходимой для тестирования, привязки к системе и запуска:

ПАСПОРТ, описывающий входные и выходные данные модуля.

ХАРАКТЕРИСТИКА - информация о ресурсах, необходимых для запуска модуля, кодах завершения и т.п.

Декларация действий, процедур и таблиц выполняется в соответствующих каталогах.

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

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

Для декларации таблицы администратор вводит табличную форму с описанием колонок таблицы и задает начальное заполнение таблицы. Содержимое таблицы хранится в текстовом файле, доступном проблемным модулям.

2.3 Декларация оболочки ПС

Декларация каждого проблемного окна выполняется с помощью меню развития (рис. 5).

Операция ЗАГОЛОВОК ОКНА гасит меню развития и переводит курсор в заголовок текущего окна для его ввода. Операция РИСУНОК позволяет отредактировать рисунок. Операция КОПИРОВАТЬ РИС. запоминает рисунок для его копирования в другое окно по операции ПОМЕСТИТЬ РИС.

Операция ДОБАВИТЬ ПУНКТ добавляет в меню текущего окна новый пункт. Операция УДАЛИТЬ ПУНКТ удаляет текущий пункт меню. Операция КОПИРОВАТЬ ПУНКТ запоминает текущий пункт меню для его копирования на другое место по операции ПОМЕСТИТЬ ПУНКТ. Операции ИМЯ и ЦВЕТ ПУНКТА предназначены для коррекции текущего пункта меню.

Далее следуют операции, предназначенные для привязки к пунктам меню переходов и операций вызова данных, действий и процедур.

Операция ВЫЗОВ АТРИБУТА организует вызов значения атрибута. Для этого вызывается СВОДНЫЙ КАТАЛОГ АТРИБУТОВ, в котором следует указать требуемый атрибут. Сводный каталог атрибутов пополняется вручную или автоматически по мере декларации структуры каналов ИБД. В каталоге предусматривается вся информация, необходимая для вызова атрибута, в частности, требуемая процедура или таблица.

Операция ВЫЗОВ ТАБЛИЦЫ организует вызов таблицы для отображения атрибута. Для этого вызывается каталог таблиц, в котором следует декларировать новую таблицу (п.3.2) или выбрать существующую. В каталоге задается вся информация, необходимая для вызова таблицы, в частности, имя атрибута.

Операции ВЫЗОВ ДЕЙСТВИЯ и ВЫЗОВ ПРОЦЕДУРЫ организует вызов исполняющих программ. Для этого вызывается каталог, в котором следует декларировать, либо выбрать действие или процедуру.

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

Информационная операция РАСКРЫТЬ ПУНКТ вызывает каталог с компонентой, задействованной в текущем пункте меню.

Служебная операция ЗАКРЫТЬ РАЗВИТИЕ гасит меню развития и позволяет ввести пароль администратора, который будет запрашиваться при повторном вызове меню развития.

3. ПРИМЕР СОЗДАНИЯ КОМПОНЕНТЫ ПС

Проект каждой новой компоненты ПС представляется в виде СПД. Примером может служить проект простой подсистемы автоматического синтеза логических схем по таблице истинности. Подсистема синтеза содержит одно проблемное окно и одно проблемное действие.

СПД проблемного окна (Рис. 6a) содержит следующие операции:

ВЫБОР ТАБЛИЦЫ истинности из ИБД.

Выбор БАЗИСА и РЕЖИМА синтеза.

СИНТЕЗ текстового описания ФУНКЦИИ для целей моделирования, СХЕМЫ и условного графического обозначения (УГО) для просмотра.

Запись результатов синтеза в ИБД.

Для декларации компоненты синтеза администратор:

Создает канал для размещения объектов с атрибутами ТАБЛИЦА, ФУНКЦИЯ, СХЕМА или выбирает существующий канал.

Вводит СПД действия СИНТЕЗ (рис. 6b).

Создает проблемное окно синтеза, изображенное на рис. 4 с помощью меню развития (п. 3.3). Проблемное окно содержит операции обмена ВЫБОР И ЗАПИСЬ, вызов действия СИНТЕЗ и атрибутов ТАБЛИЦА, БАЗИС, РЕЖИМ, ФУНКЦИЯ, СХЕМА. Способ вызова атрибутов задается в сводном каталоге атрибутов.

4. РЕАЛИЗАЦИЯ

Оболочка модульных ПС работает на IBM PC в средах MS Windows 3.x/95/98/NT и OS/2 3.x.

Создаваемые ПС ориентированы на использование в условиях локальной сети в режиме коллективного доступа.

Реализация ИБД проводилась с расчетом на хранение большого числа объектов. Для этого ИБД реализована средствами файловой системы, т.е. каждый атрибут хранится в отдельном файле, а структура ИБД представлена специальным образом в виде системы каталогов. ИБД тестировалась на базах, содержащих несколько тысяч объектов сложной структуры - проектов, микросхем и т.п. При использовании файловых систем типа HPFS и NTFS обеспечивается хранение нескольких миллионов различных объектов.

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

ЛИТЕРАТУРА

1. Шакиров Р.Н. Средства развития интегрированной САПР РЭА // Разработка и эксплуатация САПР в радиоэлектронике: Тез. докл. Всесоюзн. школы-семинара молодых учёных. Челябинск, 1991. С.23.

2. Захарова Г.Б., Чистов В.П., Шакиров Р.Н. Концепция интеллектуализации интегрированной САПР РЭА // Техн. кибернетика. 1993. N 5. С.221-227.

3. Г.Б.Захарова, И.А.Кононенко, В.Г.Титов, В.П.Чистов. Система автоматизации структурно-логического этапа проектирования. Статья в настоящем сборнике.

Размещено на Allbest.ru