ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Публикационная активность

(сведения по итогам 2017 г.)
2-летний импакт-фактор РИНЦ: 0,500
2-летний импакт-фактор РИНЦ без самоцитирования: 0,405
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,817
5-летний импакт-фактор РИНЦ: 0,319
5-летний импакт-фактор РИНЦ без самоцитирования: 0,264
Суммарное число цитирований журнала в РИНЦ: 6012
Пятилетний индекс Херфиндаля по цитирующим журналам: 404
Индекс Херфиндаля по организациям авторов: 338
Десятилетний индекс Хирша: 17
Место в общем рейтинге SCIENCE INDEX за 2017 год: 527
Место в рейтинге SCIENCE INDEX за 2017 год по тематике "Автоматика. Вычислительная техника": 16

Больше данных по публикационной активности нашего журнале за 2008-2017 гг. на сайте РИНЦ

Вход


Забыли пароль? / Регистрация

Добавить в закладки

Следующий номер на сайте

4
Ожидается:
16 Декабря 2018

Построение системы моделирования DYANA на основе ООСУБД

Статья опубликована в выпуске журнала № 4 за 1997 год.[ 20.12.1997 ]
Аннотация:
Abstract:
Авторы: Прокопенко В.В. () - , , , Смелянский Р.Л. () - , ,
Ключевое слово:
Ключевое слово:
Количество просмотров: 7784
Версия для печати

Размер шрифта:       Шрифт:

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

Теоретические основы данной системы изложены в [6]. Ее характерными особенностями являются:

· имитационное дискретно-событийное моделирование;

· возможность моделирования как параллелизма типа чередования, так и реального параллелизма [7, 8];

· спецификация и проверка свойств модели;

· количественный и алгоритмический анализ по одному и тому же описанию модели [1];

· разнообразный набор инструментальных средств для описания и анализа функционирования модели [3-5];

· использование объектно-ориентированной СУБД (ООСУБД) для хранения и обработки информации.

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

Основными концепциями ИСР являются следующие.

1. Объектная ориентированность. С каждым объектом системы DYANA связан набор атрибутов и операций для отображения этих объектов. Объектно-ориентированный подход при создании среды моделирования обеспечивает возможность независимого создания отдельных инструментов системы и простоту наращивания системы, поскольку новый инструмент будет работать с заранее известным набором классов объектов. Набор классов может расширяться. Вместе с расширением набора классов будет расширяться и набор инструментов, будут создаваться инструменты, работающие с объектами новых классов. Если же новый класс является подклассом уже существующего класса, то для работы с объектами такого класса могут также применяться и уже существующие инструменты.

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

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

4.Использование гипертекстовой технологии. Если в описании какого-либо компонента встречается имя, то можно осуществить поиск описания, соответствующего этому имени.

5.Документирование в процессе разработки означает, что на каждом шаге создания модели можно документировать этот шаг. Таким образом, вместе с моделью будет создана документация по этой модели.

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

Объектная ориентированность

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

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

1. Тип сообщения. Описание типа сообщения, в свою очередь, является объектом класса среды разработки. Атрибуты: тип представления и описание типа сообщения. Операция: изменить представление.

2. Программный компонент. Этот класс имеет два подкласса: объекты одного подкласса предоставляют экранную форму для описания процессов, объекты же другого подкласса – для описания распределенных программ. Атрибуты: тип представления прототипа, описание прототипа, тип представления тела, описание тела. Операции: изменить представление прототипа или тела, оттранслировать программный компонент.

3. Компонент-исполнитель. Этот класс имеет два подкласса: подкласс, объекты которого предоставляют экранную форму для описания последовательного исполнителя, и подкласс, объекты которого предоставляют экранную форму для описания распределенного исполнителя. Атрибуты и операции такие же, как и у программных компонентов.

4. Архитектура последовательного исполнителя является отдельным описанием, что позволяет использовать одно и то же описание архитектуры в нескольких исполнителях. Атрибуты: тип представления и описание архитектуры. Операции: изменить представление, оттранслировать во внутреннее представление.

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

6. Спецификация. Объекты этого класса служат для описания спецификации, для выполнения алгоритмического анализа модели. Атрибуты: тип представления и спецификация. Операции: сменить тип представления, оттранслировать во внутреннее представление и проверить выполнимость спецификации.

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

8. Результат проверки спецификации. Объекты этого класса служат для отображения результатов проверки спецификации. Кроме того, эти объекты имеют еще одно важное назначение – они содержат внутри себя результаты проверки каждой из подформул формулы, задающей спецификацию модели. Эти результаты могут быть потом использованы для проверки другой спецификации, в которой имеются такие же подформулы. Объект этого класса создается в процессе проверки спецификации. Атрибуты: выполнима ли спецификация, список выполнимых подформул.

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

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

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

Языковая ориентированность

Структура описания модели такова [2]:

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

· описания процессов и программ;

· описания последовательных и распределенных исполнителей;

· описания архитектур последовательных исполнителей;

· описание привязки.

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

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

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

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

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

Множественное представление описаний

Для упрощения разработки модели среда DYANA дает возможность определять одно и то же описание различными способами. Разработчик для каждого описания может выбрать свой тип представления, который ему кажется наиболее удобным.

program General ()

<

 output [ Marker ] cmd; /* буфер посылки команды FIRE */

>

Пример 1. описание прототипа программного компонента в текстовом представлении

 

Типы представлений для различных описаний компонентов

Тип описания

Типы представлений

тип сообщения

текст гипертекст таблица

прототип программного компонента

текст гипертекст таблица

реализация процесса

текст гипертекст блоксхема

реализация программы

текст гипертекст таблица

графическое

прототип исполнителя

текст гипертекст таблица

реализация последовательного исполнителя

текст гипертекст блок-схема

реализация распределенного исполнителя

текст гипертекст таблица

графическое

архитектура

текст таблица

привязка

текст гипертекст таблица

графическое

Описание имеет одно из нескольких представлений:

process General

{

 msg x;

 x = message Marker;

 nocomplex { x.delay = 1; }

 send( x, cmd );

 stop;

}

Пример 2. описание процесса в текстовом представлении

 

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

program W()

<

 input l_i, r_i;

 output l_o, r_o;

>

{

 component

 War1:Mid,

 War2:Mid;

 input

 {

 l_i = War1.l_i;

 r_i = War2.r_i;

 }

 output

 {

 l_o = War1.l_o;

 r_o = War2.r_o;

 }

 link

 {

 War1.r_o -> War2.l_i;

 War2.l_o -> War1.r_i;

 War1.c_o -> War1.c_i;

 War2.c_o -> War2.c_i;

 }

}

Пример 3. описание программы в текстовом виде

program General ()

<

 output [ Marker ] cmd; /* буфер посылки команды FIRE */

>

Пример 4. прототип программного компонента в гипертекстовом представлении


process General

{

 msg x;

 x = message Marker;

 nocomplex { x.delay = 1; }

 send( x, cmd );

 stop;

}

Пример 5. описание процесса в гипертекстовом представлении

output

[Marker]

cmd

буфер посылки команды FIRE

program General ()

Пример 6. описание прототипа программного компонента в табличном представлении

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

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

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

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

Рассмотрим, к примеру, описание программы. Эти описания можно представить в виде ориентированного графа, вершинами которого являются процессы и программы. У каждой вершины фиксировано количество входов и выходов. Каждый вход соответствует входному буферу, каждый выход – выходному. Дуга графа соответствует соединению буферов.

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

Использование гипертекстовой технологии

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

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

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

Гипертекстовая система редактирования имеет ряд преимуществ перед традиционными средствами редактирования программ.

1. Возможность перейти к описанию, используемому в данном компоненте, а также перейти к одному из описаний, которые используют данный компонент.

2. Поиск описания по имени. Программисту достаточно выбрать из списка имя нужного описания.

3. Простота переименования описаний: после переименования нет необходимости изменять все описания, в которых используется переименованный компонент, так как во всех этих описаниях стоит ссылка, не зависящая от имени описания.

Архитектура

Все компоненты среды моделирования DYANA можно разделить на три класса.

1. Средства описания моделей: списки компонентов, текстовый редактор, редактор структурных описаний, табличный редактор, редактор блок-схем.

2. Средства сборки и прогона моделей: транслятор, компоновщик, среда прогона.

3. Средства анализа результатов: визуализатор трассы в виде временных диаграмм, аниматор, анализатор интегральных характеристик.

На рисунке изображена взаимосвязь между этими компонентами.

Как видно из рисунка, у среды моделирования DYANA имеется два сервера. Первый –информационный. Он существует в одном экземпляре для всех пользователей системы DYANA, работающих над одним множеством моделей. Этот сервер реализован на основе ООСУБД ObjectStore (Object Design, Inc.). Второй сервер – сервер управления, синхронизации работы различных инструментов и обмена данными между ними. Для одного запуска среды DYANA запускается один сервер управления.

Открытость архитектуры

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

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

· MM-описания, описывающие модель соответствующего элемента сети;

· правила соединения этого элемента с конструктивными элементами, моделирующими другие элементы сети;

· правила генерации MM-текста модели для данного конструктивного элемента;

· правила отображения элемента на схеме.

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

Использование ООСУБД

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

В среде моделирования DYANA в качестве информационного сервера используется ООСУБД ObjectStore, что позволяет:

· обеспечить поддержку распределенной разработки и моделирования;

· просто хранить сложные структуры данных, с которыми приходится работать системе моделирования DYANA;

· возложить часть функций по анализу функционирования моделей на ООСУБД.

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

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

Теперь рассмотрим то, как ООСУБД может помочь при анализе функционирования модели.

Как уже отмечалось, система DYANA позволяет проводить не только количественный, но и алгоритмический анализ поведения модели. В процессе анализа алгоритмических свойств зачастую приходится выполнять поиск подграфов в графе переходов состояний системы. ООСУБД, с одной стороны, позволяет достаточно просто представлять графы, а с другой – вложенные запросы, которые обеспечивают возможность формулировать задачу поиска подграфа в терминах запросов [9,10]. Таким образом, часть задачи алгоритмического анализа решается базой данных.

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

Таким образом, с помощью ООСУБД удается упростить задачи количественного и алгоритмического анализа. Следует отметить еще одно важное свойство объектного языка запросов – вычислительную полноту, то есть на объектном языке запросов можно написать любой запрос, реализуемый на языке программирования. Вычислительная полнота обеспечивается возможностью вызова функций (в ObjectStore написанных на C++) из запроса. Недостатком таких запросов является то, что обработка подобного запроса может выполняться только полным перебором. Но даже в этом случае ObjectStore предлагает методы оптимизации выполнения таких запросов. Одним из методов является возможность строить индексы по значениям определенной функции.

Описанная ИСР на данный момент реализована на платформе Sun. Дальнейшее развитие возможно по двум направлениям – по расширению типов представлений для описаний и средств визуализации и редактирования и по переносу среды на другие платформы.

Список литературы

1. Бакалов Ю.В., Смелянский Р.Л.. Язык спецификации поведения распределенных программ // Программирование. - № 5, 1996.

2. Описание ММ-языка, 1996.

3. Отчет по НИР “Салют-У”, 1993.

4. Отчет по НИР “Салют-У”, 1994.

5. Руководство пользователя системы DYANA, 1996.

6. Смелянский Р.Л. Анализ производительности распределенных микропроцессорных вычислительных систем на основе инварианта поведения программ: дис. ... д-ра физ.-мат. наук. - М., 1991.

7. Bakhmurov A.G. , Kubrak V.A. , Smeliansky R.L. MC ‑ the language for distributed computer systems simulation, PaCT-93, 1993.

8. Bakhmurov A.G., Smeliansky R.L. DYANA ‑ the pilot project for investigation of distributed programs and computer systems. // New High Information Technologies: research and development ‑ joint projects, 11-20, 1994.

9. Marc Gyssens, Jan Paredaens, Jan Van den Bussche, Dirk Van Gucht. A graph-oriented object database model. //Proceedings of the 1990 ACM SIGMOD International Conference on Management of Data. Т. 19:2, 24-33. ACM Press, 1990.

10. Marc Gemis, Jan Paredaens, Peter Peelman, Jan Van den Bussche. A computational model for generic graph functions, 1992.


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=1049
Версия для печати
Статья опубликована в выпуске журнала № 4 за 1997 год.

Возможно, Вас заинтересуют следующие статьи схожих тематик: