автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.11, диссертация на тему:Инструментальная среда для разработки проблемно-ориентированных систем

^ о£> РОССИЙСКАЯ АКАДЕМИЯ НАУК

СИБИРСКОЕ ОТДЕЛЕНИЕ ВЫЧИСЛИТЕЛЬНЫЙ ЦЕНТР

•ч

'Ч На правах рукописи

УДК 681.3.06

КВАШНИН Геннадий Александрович

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

Специальность 05.13.11 - математическое и программное обеспечение вычислительных машин, комплексов, систем' и сетей

Автореферат диссертации на соискание ученой степени кандидата физико-математических наук

Новосибирск - 1995

Работа выполнена в Вычислительном центре Сибирского отделения Российской Академии наук.

Научный руководитель: доктор физико-математических наук

Официальные оппоненты; доктор физико-математических наук

Ведущая организация: Институт вычислительных технологий Сибирского отделения Российской Академии наук

Защита диссертации состоится 19 декабря 1995г. в 14 час. 30 мин. на заседании специализированного совета Д 002.10.02 в Вычислительном центре Сибирского отделения Российской Академии наук по адресу: 630090, Новосибирск, 90, пр. акад. Лаврентьева, 6.

С диссертацией можно ознакомиться в библиотеке ВЦ со РАН.

Автореферат разослан "¿4" ноября 1995г.

Ученый секретарь специализированного совета Д 002.10.02,

Бежанова М.М.

Ильин В.П.,

кандидат физико-математических наук Калинина Н.А.

кандидат технических наук

Г.И. Эабиняко

ОБЩАЯ ХАРАКТЕРИСТИКА РАБОТЫ

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

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

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

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

Целью работы является создание в райках комплекса ТРАП инструментальной среды, обеспечивающей поддержку разработки проблемно-ориентированных систем.

Научная новизна работы:

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

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

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

Практическая значимость работы определяется тем, что с помощью комплекса ТРАП в ВЦ СО РАН был разработан ряд ППП и инструментальных систем. Использование средств комплекса ТРАП на практике существенно сократило время разработки программных систем.

Реализация результатов, исследование и разработка технологического комплекса ТРАП выполнены в рамках всесоюзной программы 0.80.01 по постановлению ГКНТ и распоряжению президиума АН СССР.

Технологический комплекс ТРАП использован при разработке ряда инструментальных подсистем и системного обеспечения ППП :

МЕНЮ - система ведения проблемно-ориентированного диалога;

ДИВПАК - подсистема диалогового ввода и формирования пакетных заданий;

ДИНА - комплекс динамических агрегатных типов данных;

СИНАПС - коллекция макетов системного наполнения простых прикладных систем;

ТЕМП - технология разработки многоверсионных программных моделей;

НЕРПА - комплекс системных и интерфейсных компонент пакета прикладных программ НЕКТ0Н-1 (пакет предназначен для решения кра-

евых задач теории пластин и трехмерных задач теории потенциала методом блуждания по сферам для областей со сложной геометрией и уравнений в детерминированной и стохастической постановке);

МИРТА - комплекс системных и интерфейсных компонент пакета прикладных программ МИРАЖ (пакет для расчета радиационного теплообмена между поверхностями тел, находящихся в вакууме).

РАМЗЕС - ППП для расчета электромагнитных и магнитостатичес-ких конструкций;

ГЕОС - ППП для моделирования сейсмических полей в двумерно-неоднородной слоисто-блоковой среде дифракционно-лучевым методом;

МОДИП - ППП для решения задач диффузии примесей в турбулентных средах методом Монте-Карло.

Указанные инструментальные подсистемы выполнены в рамках всесоюзной программы 0.80.01, прошли межведомственные испытания и переданы в фонд алгоритмов и программ. Информация о них опубликована в бюллетенях БНТИцентра. Ряд пакетов прикладных программ передан заказчикам.

Апробация. Результаты работы докладывались на ряде конференций, семинаров и школ : Республиканский семинар "Общие вопросы технологии создания программного обеспечения" ( Вильнюс, 1985, 1988), VIII Сибирская школа по программному обеспечению ЭВМ новых поколений (Иркутск, 1989), IX Всесоюзная школа по программному обеспечению математического моделирования, управления и искусственного интеллекта (Адлер, 1991), международная научно-методическая конференция "Новые информационные технологии в университетском образовании" (Новосибирск, 1995), International Conference "Advanced Mathematics, Computations and Applications" (Novosibirsk, 1995), а также на семинарах ВЦ СО РАН (Новосибирск).

Публикация. По теме диссертации опубликовано 24 работы, список которых приводится в конце автореферата.

Структура и объем. Работа состоит из введения, пяти глав, заключения, списка литературы (119 наименований), одного приложения; изложена на 102 страницах, содержит 4 рисунка.

КРАТКОЕ СОДЕРЖАНИЕ РАБОТЫ

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

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

Для поддержки данного этапа в составе комплекса ТРАП разработаны и реализованы языковые и инструментальные средства, которые включают:

- язык проектирования САТРАП, основывающийся на лексике русского языка, на котором описывается программная система;

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

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

Выделено шесть подсистем комплекса: ВЗАИМОДЕЙСТВИЕ, СПЕЦИФИКАЦИЯ, СТРУКТУРА, ФОРМИРОВАНИЕ, КОНТЕКСТ, БАЗА МОДУЛЕЙ.

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

Подсистема СПЕЦИФИКАЦИЯ предназначена для поддержки описания модулей. Подсистема состоит из двух компонент: языка проектирования САТРАП и синтаксического анализатора. Синтаксис языка задается в виде набора диаграмм перехода. Ядром анализатора является сканер. В процессе анализа могут запускаться семантические

программы (вынесенные в подсистему ФОРМИРОВАНИЕ ), строящие внутреннее представление модуля.

Подсистема СТРУКТУРА предназначена для описания внутреннего представления модуля в виде трех его составляющих: таблицы символов, структуры модуля и функциональной схемы.

Таблица символов представляет собой таблицу идентификаторов и констант вместе с приписанными им атрибутами.

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

Функциональная схема является внутренним представлением компонент обработки модуля (функции, процедуры, операции), задаваемых в модуле на языке управления. Это представление удобно для алгоритмов интерпретации или компиляции функциональных схем.

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

Подсистема КОНТЕКСТ предназначена для выполнения работ по построению и проверке контекста (окружения) заданного модуля. При проверке правильности контекста контролируется определены ли все используемые модулем объекты, единственно ли это определение и т.п. Эти проверки выясняют также степень завершенности проектируемой модели и служат одним из доказательств ее правильности. По требованию может быть построено и размещено в базе модулей внутреннее представление контекстного модуля, содержащее все объекты контекста.

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

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

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

Конфигурация СИНТАКТОР используется для выполнения синтаксического анализа модуля, описанного на языке САТРАП. Модуль после анализа в базу не заносится.

Конфигурация ТРАНСЛЯТОР выполняет синтаксический анализ и, в случае отсутствия ошибок, записывает текстовое и внутреннее представление модуля в базу модулей.

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

Конфигурация КАТАЛОГ реализует действия пользователя по получению сводной информации о доступной ему части базы модулей, а также действия по некоторой ее корректировке. Можно вывести модуль на устройство вывода, запретить или разрешить доступ к нему других пользователей, уничтожить или скопировать модуль, какую-либо из его версий.

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

Представителями каждой из конфигураций комплекса ТРАП явля-

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

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

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

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

Модуль может иметь много версий. Многоверсионность полезна как средство фиксации изменений в модуле по мере его разработки и как средство определения одних и тех же понятий различными способами. Формально все версии модуля объединяет лишь общее имя модуля .

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

Язык САТРАП служит для описания этих представлений и распадается на две части - язык формальных спецификаций и язык функциональных спецификаций (называемый также языком управления).

На языке САТРАП спецификации модуля соответствует специальная конструкция вида :

СПЕЦИФИКАЦИЯ имя_экземпляра_модуля[паракетры_модуля]; [спецификация_интерфейса_модуля;] (спецификация_объекта_модуля);

КОНЕЦ_ОТЕЦИФИКАЦИИ [имя_экземпляра_модуля];

Имя_экэемпляра_модуля является составным именем, состоящим из имени модуля и имени версии этого модуля.

Спецификация_интерфейса_модуля описывает экспорт импорт модуля. Экспорт модуля задается в виде перечня определяемых

модулем объектов и, возможно, их подобъектов.

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

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

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

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

Язык САТРАП содержит конструкцию, соответствующую такому способу определения типа и называемую операционным типом данных (ОТД). Помимо ОТД в языке САТРАП можно определять операционные данные (ОД), как некоторые уникальные данные, описываемые путем задания множества допустимых для них операций. Спецификации операций ОТД и ОД подобны спецификациям функций или процедур.

ОГД и ОД являются составными объектами, их подобъек.тами являются их операции. Аналогично модулю ОТД и ОД содержат, описание импорта и экспорта (доступных извне операций), представление операционного типа скрыто.

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

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

Формальная спецификация процедурных обьектов модуля традици-онна: "заголовки" функций или процедур со спецификацией типов параметров и способов их передачи. Собственно описание элементарных алгоритмов можно сделать на языке функциональных спецификаций в в виде последовательности шагов крупных операторов управления, называемых группами.

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

Наряду с традиционными завершающими действиями (останов, возврат, конец) в языке управления имеется ряд дополнительных действий, расширяющих возможности групп управления: структурный выход из группы (ЗАВЕРШИТЬ), продолжение перебора вариантов (ПРОДОЛЖИТЬ) и возобновление исполнения группы с начала (ВОЗОБНОВИТЬ) .

Для выполнения синтаксического анализа языка САТРАП применяется таблично-управляемый способ распознавания структуры информации. Он удобен и эффективен в том плане, что позволяет модифицировать и пополнять синтаксис языка без изменения программ-анализаторов. Синтаксис языка задается в виде набора диаграмм переходов. Синтаксический анализ выполняется для формальной спецификации модуля и для функциональной спецификации на языке управления по одной и той же схеме.

В третьей главе описывается архитектура базы модулей (БМ) комплекса ТРАП. Рассматриваемая база модулей является оригинальной, хотя имеет ряд общих черт с другими системами подобного рода (иерархическая модель данных, механизм переиспользования дисковой памяти).

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

Фактически, пользователь комплекса вообще не знает о существовании ЕМ, а тем более об ее архитектуре. Такой подход, с одной стороны, позволяет комплексу ТРАП осуществлять защиту БМ в условиях коллективного доступа к ней нескольких пользователей, а с другой, освобождает пользователей от выполнения целого ряда мелких действий, связанных с хранением его модулей.

Вторая особенность рассматриваемой БМ состоит в том, что модуль с точки зрения системы поддержки является составным объектом. Модуль может иметь несколько версий. Версии модуля появляют-/ / ся как следствие временных и временных изменении, вносимых в

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

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

Обеспечение соответствия версий различным понятиям решается в рассматриваемой БМ путем именования модулей и версий.

Каждая версия модуля в БМ имеет несколько представлений. Доступными для пользователя являются два представления : спецификация версии модуля (на языке проектирования САТРАП) и ее реализация на языке программирования. Кроме указанных внешних представлений, версия модуля имеет несколько внутренних. Это таблица символов, структура модуля и функциональная схема. Последние скрыты от пользователя, образуются и используются различными алгоритмами комплекса поддержки и предназначены для эффективной работы этих алгоритмов.

Доступ к модулям, хранящимся в базе модулей, осуществляется с помощью таблицы имен модулей (ТИМ).

Для ТИМ определены операции создания,чтения и записи таблицы имен, нахождения, внесения и удаления имени, печати и ряд других.

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

Статус содержит информацию о пользователе, являющимся авто-

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

Постоянными носителями информации в БМ являются три файла : "таблица_имен", "версии" и "представления". Для отслеживания фрагментов свободной памяти в файлах "версии" и "представления" введены соответственно шкалы версий и представлений.

В целом связи, в рассматриваемой БМ, реализуют иерархическую структуру.

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

- операции для работы с базой модулей в целом, выполняющие ряд действий, связанных с созданием и инициализацией БМ;

- операции для работы с модулем в целом, выполняющие действия над модулями (внесение, уничтожение);

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

- операции для работы с представлениями, выполняющие создание и запись представления, чтение, уничтожение;

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

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

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

В четвертой главе описаны языковые и программные средства поддержки интерфейса пользователя с комплексом ТРАП, реализованные в виде подсистемы ВЗАИМОДЕЙСТВИЕ.

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

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

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

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

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

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

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

В комплексе ТРАП введены две категории пользователей: администратор и рядовой пользователь, идентифицирующиеся шифрами и ключами. Соответствие шифров и ключей фиксируется администратором комплекса. Шифры и ключи играют важную роль в защите модулей от несанкционированного доступа. Каждый модуль, хранящийся в базе модулей, характеризуется своим статусом, который содержит информацию о пользователе ( шифр, ключ ), создавшем этот модуль и о типе доступа к этому модулю ("общий" или "индивидуальный"). Статус модуля автоматически приписывается модулю при вводе его в базу модулей. Автор модуля может предоставить право чтения модуля всем пользователям, изменив его тип доступа на "общий" или сделать его недоступным, переопределив тип доступа на "индивидуальный". Администратор имеет право выполнять действия по открытию и закрытию всех модулей.

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

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

Протоколирование сеанса работы пользователя с комплексом позволяет соразработчикам ПОС отслеживать информацию о внесенных

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

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

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

В технологии ТРАП представлен широкий спектр механизмов и средств поддержки многоверсионности моделей. Не останавливаясь на их описании, отметим лишь, что при реализации ПОС МОДИП были использованы средства редактора связей и библиотекаря, командные файлы, реализованные с использованием средств DOS и нортоновских утилит, параметризация модели.

Для решения проблемно-ориентированной задачи необходимо не только тем или иным способом задать ее решение, но и определить контекст ( окружение, обстановку ), в которой будет исполняться этот алгоритм (его программная модель). Контекст включает в себя совокупность объектов, соответствующих понятиям данной предметной области.

В рассматриваемой ПОС источниками образования контекста являются: текстовая библиотека ПОС, содержащая функциональные модули; библиотека объектных модулей, содержащая основные и "вспомогательные" модули, библиотека фортран-компилятора, поставляющего стандартные подпрограммы и функции; последовательные наборы данных, объекты которых позволяют модифицировать модель.

Для образования контекста в ПОС МОДИП были использованы всевозможные средства, предоставляемые компонентами MS DOS: средства автовыэова и включения заданных наборов данных и программ, обее-

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

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

Интерфейс пользователя с ПОС МОДИП выполнен в рамках технологии ТРАП, в которой помимо учета общеизвестных требований к манере общения особое внимание уделено следующим вопросам:

- совмещение функций информатора о возможностях ПОС с функцией ввода сведений о задаче (для работы с ПОС не требуется никакой инструкции);

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

- разная степень подробности задания информации;

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

- индикация процесса исполнения программ.

Граф ведения диалога пользователя с ПОС МОДИП реализован в виде сети переходов.

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

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

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

Возможно построение исполнителей, предназначенных для различных целей: выполнение вычислений, конструирование программных моделей и различных вариантов их, поиска и выдачи информации, ввод и редактирование данных и т.д.

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

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

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

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

Опыт использования системы при реализации интерфейса.для ПОС МОДИП показал, что ее полезно рассматривать не только как средст-

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

В заключении сформулированы основные результаты:

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

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

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

4. Предложенные технологические средства комплекса ТРАП использованы при разработке ряда ППП в ВЦ СО РАН.

Автор выражает благодарность научному руководителю д.ф.-м.н., с.н.с. М.М.Бежановой за замечания по написанию диссертации.

ПУБЛИКАЦИИ

Результаты диссертации опубликованы в следующих работах :

1. Бежанова М.М., Квашнин Г.А., Костюкова Н.И. и др. Проект системы поддержки проектирования ППП : Отчет / ВЦ СО АН СССР, N гр. 0285.0026751. - Новосибирск, 1984. - 220 с.

2. Бежанова М.М., Квашнин Г.А., Костюкова Н.И. Технический проект системы поддержки проектирования ППП : Отчет / ВЦ СО АН СССР, N гр. В1041847. - Новосибирск, 1985. - 261 с.

3. Бежанова U.M., Квашнин Г.А., Костюкова Н.И. и др. Методы и средства построения пакетов прикладных программ : Отчет / ВЦ со АН СССР, N гр. 0286.005426. - Новосибирск, 1985. - 95 с.

4. Бежанова М.М., Квашнин Г.А. Модель базы модулей в системе поддержки проектирования ППП. // Пакеты прикладных программ. -Новосибирск : ВЦ СО АН СССР, 1986. - С. 19-31.

5. Бежанова М.М., Квашнин г.А. Структурирование программ и использование средств управления в технологии разработки ППП.

- Новосибирск, 1987. - 22 с. (Препринт/ВЦ СО АН СССР; 702).

6. Бежанова М.М., Квашнин Г.А. Приемы тестирования и отладки в технологии разработки ППП. - Новосибирск, 1987.- 25 с. (препринт/ВЦ СО АН СССР; 703).

7. Бежанова М.М., Квашнин Г.А. Технологический комплекс проектирования пакетов прикладных программ на основе языка проектирования и проблемно-ориентированных банков модулей. Технический проект : Отчет / ВЦ СО АН СССР. - Новосибирск, 1987. - 67 с.

8. Квашнин Г.А. Средства обеспечения интерфейса пользователя с системой поддержки проектирования ППП.// Автоматизация построения алгоритмов для задач математической физики. - Новосибирск: ВЦ СО АН СССР, 1987. - С. 38-47.

9. Бежанова М.М., Квашнин Г.А., Колкер Н.И. Технологические аспекты тестирования программных систем ( оперативно-информационный материал). - Новосибирск: ВЦ СО АН СССР, 1988. - 103 с.

10. Бежанова М.М., Квашнин Г.А., Шкуропат Е.Л. Система поддержки разработки пакетов прикладных программ. // Программное обеспечение ЭВМ новых поколений. Тезисы докладов VIII Сибирской школы по пакетам прикладных программ. - Иркутск, 1989.- С. 36-37.

11. Квашнин Г.А., Трепакова С.Б. Некоторые аспекты разработки средств диалогового взаимодействия пользователя с системой поддержки ТРАП. // Математическое и архитектурное обеспечение параллельных вычислений. - Новосибирск : ВЦ СО АН СССР, 1989.

- С. 141-148.

12. Бежанова М.М., Квашнин Г.А. Коллекция макетов реализации основных понятий современного программирования (ПРИНС). N 50900000455 // Инф.бюллетень " Алгоритмы и программы " - М.: ВНТИцентр. - 1990. - N 9. - С. 14.

13. Бежанова М.М., Квашнин Г.А. Технологический комплекс проектирования^пакетов прикладных программ на основе языка проектирования и проблемно-ориентированных банков модулей (ТРАП). Подсистема ВЗАИМОДЕЙСТВИЕ. N 50900000905 // Инф. бюллетень " Алгоритмы и программы " - М.: ВНТИцентр. - 1990. - N 12. - С. 12.

14. Бежанова М.М., Квашнин Г.А. Технологический комплекс проектирования пакетов прикладных программ на основе языка проектирования и проблемно-ориентированных банков модулей (ТРАП). Подсистема БАЗА МОДУЛЕЙ. N 50900000899 // Инф. бюллетень " Алгоритмы и программы " - М.: ВНТИцентр. - 1990. - N 12. - С. 3.

15. Бежанова М.М., Квашнин Г.А. Технологический комплекс проектирования пакетов прикладных программ на основе языка проектирования и проблемно-ориентированных банков модулей (ТРАП). Подсистема СПЕЦИФИКАЦИЯ. N 50900000901 // Инф. бюллетень " Алгоритмы и программы " - М.: ВНТИцентр. - 1990. - N 12. - С. 12.

16. Бежанова М.М., Квашнин Г.А. Технологический комплекс проектирования пакетов прикладных программ на основе языка проектирования и проблемно-ориентированных банков модулей (ТРАП). Подсистема ИНФОРМАТОР. N 509000008 98 // Инф. бюллетень " Алгоритмы и программы " - М.: ВНТИцентр. - 1990. - N 12. - С. 3.

17. Бежанова М.М., Квашнин Г.А. Технологический комплекс проектирования пакетов прикладных программ на основе языка проектирования и проблемно-ориентированных банков модулей (ТРАП). N 50900000906 // Инф. бюллетень " Алгоритмы и программы " - М.: ВНТИцентр. - 1990. - N 12. - С. 16.

18. Бежанова М.М., Квашнин Г.А. Синтаксический анализатор языка САТРАП. // Вычислительный эксперимент в задачах математической физики. - Новосибирск : ВЦ СО АН СССР, 1990. - С.- 3-10.

19. Бежанова М.М., Квашнин Г.А., Москвина Л.А. Обеспечение диалогового взаимодействия с проблемно-ориентированными системами в технологии ТРАП. // Вычислительный эксперимент в задачах математической физики. - Новосибирск: ВЦ СО АН СССР, 1991.- С. 22-33.

20. Бежанова М.М., Квашнин Г.А., Шкуропат Е.Л. Система поддержки разработки пакетов прикладных программ ТРАП. // Пакеты прикладных программ моделирования, прогнозирования и управления в региональных и производственных системах. - Новосибирск : Наука.-1991.

21. Квашнин Г.А., Москвина Л.А., Яковенко Г.Т. Адаптация системы МЕНЮ для реализации диалога с ППП. // Вычислительный эксперимент в задачах математической физики. - Новосибирск: ВЦ СО АН СССР. - 1991. - С. 133-148.

22. Бежанова М.М., Квашнин Г.А., Москвина Л.А. Технология обеспеченля диалогового взаимодействия с ППП.// Программное обес-

печение математического моделирования, управления и искусственного интеллекта. Тезисы докладов IX Всесоюзной школы по пакетам прикладных программ. - Иркутск. 1991. - С. 90-91.

23. Бежанова М.М., Квашнин Г.А- Системная оболочка проблемно-ориентированных систем на ЕС ЭВМ. // Вычислительные методы и технология решения задач математичесхой физики. - Новосибирск: ВЦ СО АН СССР. - 1993. - С. 91-98.

24. G.A. Kvashnin and N.I. Kostyukova. Facilities for the Support of Interface with the Problem-Oriented System for the Solution of the Diffusion Problems in Turbulent Media by the Monte-Carlo Method. - In : Advanced Mathematics, Computations and Applications, International Conference. - Novosibirsk, 1995, p. 204.

.^é'ieiiucuM^