Платформно независимая система имитационного моделирования

 

---

Адрес авторов
    250027 г. Чернигов √ 27
    ул. Шевченко, 95
    Черниговский технологический институт
    Кафедра информационных компьютерных систем
    Тлф. (0462) 95-56-87

---

Аннотация

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

Annotation

In this article, the questions of improving of technology of simulation as basic method of researching of compound system with ramified process of function are considered. We describe the realization of the system of simulation in Java environment, including elaboration of threads controller, mechanism of priority and the basic component library. The system is supported the specialized graphical editor, which provides visual design of models from finished components, as far as from ones creating in the network, and it▓s initialization. Present application make it▓s possible for as to a full extant use the cross platform character of simulation process with possibility of employment of multi processor systems.

Ключевые слова

КОМПОНЕНТ МОДЕЛИ, ОБзЕКТ МОДЕЛИ, ПОТОК ВЫПОЛНЕНИЯ, МОДЕЛЬНОЕ ВРЕМЯ, ДИСПЕТЧЕР МОДЕЛЬНОГО ВРЕМЕНИ.

Вступление

Среди основных направлений исследований в области программной инженерии особое место занимает разработка программных средств моделирования. Хотя затрагиваемая в данном направлении проблематика не нова, современные тенденции в развитии распределенных вычислений и широкое использование Internet выдвигают ряд новых требований к структуре и принципам функционирования моделирующих программных систем [1]. Одним из таких требований является создание платформно-независимого программного обеспечения как средства построения моделей из распределенных в сети компонентов с перспективой организации параллельных вычислений на многопроцессорных системах.

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

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

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

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

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

Графическое представление механизма взаимодействия диспетчера и компонента показано на РИС. 1.

РИС. 1 Схема взаимодействия диспетчера и компонента модели

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

Синхронизация между несколькими подмоделями и реальное распараллеливание процесса выполнения модели может быть осуществлена по схеме, представленной на РИС. 2.

РИС. 2 Возможная схема распараллеливания процесса моделирования

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

Механизм приоритетов компонент

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

Типичным примером ситуации, требующей установки приоритета объекта компонента, является модель с двумя компонентами ⌠очередь с отказами■, соединёнными последовательно. Если максимальный размер очереди равен единице, а в начале моделирования очереди заполнены и в компонент поступает ещё один объект, то при установке одинаковых приоритетов обеим очередям, один из объектов будет сброшен как избыточный. Какой именно предсказать достаточно сложно. Однако установка приоритетов объектов компонент, способна однозначно разрешить данную проблему.

Запуск процесса моделирования

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

Фаза 1. Создание объекта - диспетчера.

В этой фазе создаётся объект диспетчера. Фаза 2. Создание объектов - компонент модели. В этой фазе создаются все объекты - компоненты модели. При создании каждый компонент получает ссылку на диспетчера и у него регистрируется. Регистрация необходима для корректного начала и завершения работы модели. Фаза 3. Инициализация компонент. В этой фазе устанавливаются все начальные параметры компонент. Фаза 4. Соединение компонент. Большинство компонент модели должны взаимодействовать друг с другом. В процессе соединения компонентов каждому из них сообщается с кем, и связью какого типа, он соединён. Фаза 5. Запуск потока выполнения диспетчера. Запускается поток выполнения диспетчера. Фаза 6. Запуск потоков выполнения компонент диспетчером. Диспетчер запускает потоки выполнения компонент поочерёдно, согласно очерёдности их регистрации. Запуская каждый поток, диспетчер дожидается его приостановки, перед запуском следующего. Фаза 7. Выполнение модели. В этой фазе диспетчер распределяет очерёдность выполнения потоков выполнения компонент согласно модельному времени. Фаза 8. Завершение работы модели. Получив от одного из компонент уведомление о необходимости завершить моделирование, диспетчер посылает всем своим зарегистрированным компонентам соответствующее сообщение, приняв которое компоненты должны подготовить статистическую информацию о своей работе и вывести её.

Механизм взаимодействия компонент между собой

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

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

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

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

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

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

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

Библиотека базовых компонентов

Назначение и выполняемые функции базовых компонентов заимствованы из языка СЛАМ II [2]. Также в библиотеку базовых компонентов включены генераторы псевдослучайных чисел наиболее распространённых распределений. Библиотека базовых компонентов снабжается описаниями, облегчающими работу с графическим редактором, и документацией.

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

К базовым компонентам системы отнесены:

1. Универсальный базовый компонент. Используется как базовый класс для быстрого построения других классов.
2. Очередь с обработкой переполнения.
3. Генератор объектов.
4. Счётчик объектов с генерацией события завершения моделирования после прихода заданного числа объектов.
5. Распределитель объектов. Распределяет приходящие объекты между несколькими другими компонентами.
6. Концентратор объектов. Объединяет несколько пришедших объектов в один.
7. Задвижка. Перекрывает путь прохождения объектов между компонентами модели.
8. Построитель гистограммы. Собирает данные и рисует гистограмму в конце моделирования.
9. Маркировщик объектов. Записывает в одно из полей массива объекта значение, из источника, определяемого пользователем. Используется совместно с построителем гистограммы и построителем графика.
10. Построитель графиков. Собирает данные и рисует одновременно несколько графиков.

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

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

РИС. 3 Пример графического представления результатов моделирования

Построение моделей

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

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

• копирование и исправление текста (в текстовом редакторе) уже существующего класса;
• полное создание файла средствами графической оболочки.

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

Графическая редактор для построения моделей

Его основное назначение √ сделать процесс построения программных моделей простым и наглядным. Редактор позволяет визуально собирать нужные модели из разработанных компонент с предоставлением возможности сохранять и загружать уже готовые к работе модели. Файлы сохранения моделей имеют текстовый формат, и при необходимости можно изменять их содержание вручную. Возможно объединение нескольких моделей в одну, что особенно удобно при построении моделей сложных систем, подсистемы которых моделировались и тестировались раздельно. Для графического изображения компонентов используются файлы стандартов GIF и JPEG.

На РИС. 4 в качестве примера приведено графическое представление простейшей модели системы массового обслуживания, состоящей из генератора объектов, очереди, обслуживающего устройства и приёмника объектов, соединенных линиями связей.

РИС. 4 Окно редактора модели

Помимо создания графического представления модели редактор позволяет сгенерировать исходного код модели на Java и далее откомпилировать его внешним компилятором и запустить модель на выполнение.

Выводы

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

---

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

1. Нортон Патрик, Шилдт Герберт. Полный справочник по Java.: Пер. с англ. ≈ К.: Диалектика, 1997. ≈ 592 с.: ил. ≈ Парал. тит. англ.
2. Прицкер А. Введение в имитационное моделирование и язык СЛАМ II: Пер. с англ.≈М.: Мир, 1987.≈ 646 с., ил.