Базовая схема формализации системы моделирования MICIC4

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

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2005
Автор:	Левчук, В.Д.
Формат:	Стаття
Мова:	Російська
Опубліковано:	Інститут програмних систем НАН України 2005
Теми:	Прикладне програмне забезпечення
Онлайн доступ:	https://nasplib.isofts.kiev.ua/handle/123456789/1323
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Цитувати:	Базовая схема формализации системы моделирования MICIC4 / В.Д. Левчук// Проблеми програмування. — 2005. — N 1.— С. 85–96. — Бібліогр.: 9 назв. — рос.

Репозитарії

Digital Library of Periodicals of National Academy of Sciences of Ukraine

_version_	1860089478285099008
author	Левчук, В.Д.
author_facet	Левчук, В.Д.
citation_txt	Базовая схема формализации системы моделирования MICIC4 / В.Д. Левчук// Проблеми програмування. — 2005. — N 1.— С. 85–96. — Бібліогр.: 9 назв. — рос.
collection	DSpace DC
description	Рассматривается базовая схема формализации, лежащая в основе системы моделирования MICIC4, в которой реализован транзактный способ имитации. Полная функциональность MICIC4 обеспечивается программируемым интерфейсом, который по своей сути близок к понятию "процесс". Определены базовые элементы и их свойства, статическая иерархическая структура и потоковая граф-схема имитационной модели, особенности реализации управляющей программы моделирования, графическое отображение механизмов обслуживания. Приводится методика формализации сложной системы согласно предложенной базовой схемы. Розглядається базова схема формалізації, що лежить в основі системи моделювання MICIC4, в якій закладено транзактний спосіб імітації. Повна функціональність MICIC4 забезпечена програмованим інтерфейсом, який за своєю суттю є близьким до поняття «процес». Сформульовані базові елементи i властивості, статична ієрархічна структура i потокова граф-схема імітаційної моделі, особливості реалізації керуючої програми моделювання, графічне відображення механізмів обслуговування. Приведена методика формалізації складної системи відповідно до запропонованої базової схеми. The base scheme of a formalization for the simulation engine MICIC4 to be controlled on the transaction way of a modeling is considered in the article. The full performance of MICIC4 is ensured by a programmed interface to be closed to the notion «process». The base elements and their features, a static hierarchal structure and flow graphs of a simulation model, details of the organization of a simulation control program are defined. The algorithm of a complex system formalization accordingly to the offered base scheme is given in conclusions.
first_indexed	2025-12-07T17:22:11Z
format	Article
fulltext	Прикладне програмне забезпечення © В.Д. Левчук, 2005 ISSN 1727-4907. Проблеми програмування. 2005. № 1 85 УДК 681.3 В.Д. Левчук БАЗОВАЯ СХЕМА ФОРМАЛИЗАЦИИ СИСТЕМЫ МОДЕЛИРОВАНИЯ MICIC4 Рассматривается базовая схема формализации, лежащая в основе систе- мы моделирования MICIC4, в которой реализован транзактный способ ими- тации. Полная функциональность MICIC4 обеспечивается программируемым интерфейсом, который по своей сути близок к понятию "процесс". Опреде- лены базовые элементы и их свойства, статическая иерархическая струк- тура и потоковая граф-схема имитационной модели, особенности реализа- ции управляющей программы моделирования, графическое отображение меха- низмов обслуживания. Приводится методика формализации сложной системы согласно предложенной базовой схемы. Введение Новая платформо-независимая версия системы имитационного мо- делирования MICIC4 (далее просто MICIC4) является развитием вер- сии 2.0 [1], реализованной в DOS-среде. В основе MICIC4 ле- жит более мощная базовая схема формализации (БСФ), под которой понимается совокупность понятий, используемых для построения фор- мального описания моделируемой системы и непосредственно пред- ставленных в языке моделирования [2]. В практике моделирования существует ряд способов формали- зации функционирования исследуе- мой системы [1–3]. Одним из них является транзактный способ [4, 5], когда объект моделирования представляется как сеть массово- го обслуживания (СМО). Для СМО характерны следующие статические элементы: • источники заявок на об- служивание — транзактов; • обслуживающие устройства (приборы); • очереди для сохранения транзактов перед занятыми уст- ройствами; • поглотители заявок; • множество дополнительных элементов (блоков), управляющих движением транзактов и модифици- рующих состояние как обслуживаю- щих устройств, так и самих до- полнительных элементов. При структуризации сложной системы (СС) с помощью БСФ МIСIС4 также предполагается ис- пользование транзактной схемы. Однако число базовых элементов сведено к минимуму в отличие от других средств моделирования данного типа. При этом полная функциональность MICIC4 (в смыс- ле возможности отображения взаи- модействия подсистем и элементов практически любой СС на высоком уровне детализации) реализуется за счет того, что обслуживание транзакта на устройстве обеспечи- вается программируемым интерфей- сом, который по своей сути бли- зок к понятию "процесс" [1, 3, 6]. Языки имитационного модели- рования включают в себя конст- рукции, соответствующие опреде- ленной БСФ, и по синтаксической основе подразделяются на три ка- тегории [2]: с собственным син- таксисом, расширяющие универ- сальный язык программирования или вложенные в него. Последняя группа языков по форме является библиотекой функций, объектов, шаблонов и т.д. Язык моделирова- ния MICIC4 также принадлежит данной группе и его интерфейс реализован системным модулем на объектно-ориентированном языке программирования С++ [7]. Сис- Прикладне програмне забезпечення 86 темный модуль можно оттранслиро- вать отдельно от информационного модуля, описывающего взаимодей- ствие составных элементов СС, а затем включать в проект любой имитационной модели (ИМ). Таким образом, для написа- ния программ ИМ с помощью MICIC4 разработчик модели должен вла- деть классическим универсальным языком программирования С++, а также изучить программный интер- фейс, являющийся отображением БСФ MICIC4. Ее основные положе- ния раскрываются в данной ста- тье. 1. Базовые элементы MICIC4 Построение формальной модели рекомендуется начинать с декомпо- зиции СС на подсистемы и элементы [1, 8]. Разработчик ИМ средства- ми MICIC4 рассматривает объект моделирования как совокупность следующих базовых элементов: ге- нераторов внешних событий (тран- зактов, в частности), обслужи- вающих устройств и транзактов (заявок на обслуживание). Устройства предназначены для обслуживания транзактов. Процесс обслуживания заключается в программной имитации функцио- нальных действий, совершаемых взаимодействующими элементами объекта моделирования. Обслужи- вание начинается с приходом транзакта на устройство и завер- шается после его ухода, т.е. без транзактов подпрограммы уст- ройств не получают управление. Транзакт после обслуживания на исходном устройстве может пере- меститься на следующее (целевое) устройство, быть уничтожен сис- темой моделирования, ожидать на- чала обслуживания или привести к аварийному окончанию эксперимен- та из-за невозможности его об- служивания целевым устройством. Элемент модели, самостоя- тельно порождающий произвольные события, называется генератором. Он позволяет отображать действие внешней среды как путем создания потока транзактов на обслужива- ние, так и изменением состояния элементов модели. Кроме того, генераторы можно использовать для внутренней синхронизации элементов или достижения специ- альных целей при программирова- нии ИМ (например, отладки, вери- фикации или мониторинга состоя- ния ИМ). Множество необходимых для эксперимента с ИМ устройств и генераторов требуется задавать заранее. С другой стороны, их можно уничтожить только по окон- чании эксперимента с ИМ. Тран- закты, наоборот, первоначально отсутствуют, а затем добавляются и уничтожаются в прогоне ИМ в произвольном порядке и количест- ве (точнее, ограниченном только имеющимся в наличии объемом опе- ративной памяти). В этом смысле транзакты являются динамическими элементами модели, а устройства и генераторы — статическими эле- ментами. Как известно, при дискрет- но-событийном моделировании со- стояния сложной системы изменя- ются в дискретные моменты мо- дельного времени, т.е. в моменты возникновения событий [1, 2]. Изменение состояния модели реа- лизуется путем вызова из управ- ляющей программы моделирования (УПМ) обработчика события, кото- рый называется активностью и представляет собой функцию или процедуру языка моделирования. В MICIC4 функционирование генератора в ИМ представляет со- бой множество активностей, объе- диненных в виде связного ориен- тированного графа, в котором ду- ги показывают возможные пути возникновения событий, обрабаты- ваемых активностями — вершинами. Никаких ограничений на структуру данного графа не накладывается, т.е. допускаются вместе с линей- Прикладне програмне забезпечення 87 ными участками условные переходы и циклы. После выполнения любой активности генератора управле- ние передается в УПМ. Причем до передачи управления обязательно необходимо запланировать следую- щую активность, а также модель- ное время ее вызова из УПМ или приостановить работу генератора. В теории имитационного мо- делирования ориентированная во времени последовательность со- бытий (активностей), отражающая поведение элемента СС, называ- ется процессом [8, 9]. Следова- тельно, каждому генератору ИМ, разрабатываемой согласно БСФ MICIC4, необходимо поставить в соответствие некоторый процесс. Поскольку переходы между актив- ностями процесса скрыты внутри самих активностей, то при добав- лении генератора в ИМ достаточно указать только начальную активность его процесса. Аналогичным графом активно- стей (процессом) отображается механизм обслуживания транзакта на устройстве. При поступлении транзакта на определенное уст- ройство УПМ вызывает начальную активность механизма обслуживания именно этого устройства. Гово- рят также, что УПМ инициализиру- ет (запускает) механизм обслужи- вания устройства. В начальной активности можно организовать как общий, так и уникальный спо- соб обработки различных типов транзактов. Как и для генерато- ра, начальную активность устрой- ства необходимо задать при его добавлении в ИМ. В отличие от генератора ка- ждый процесс — механизм обслужи- вания в конечном итоге следует завершить стандартной активно- стью УПМ, которая называется «Окончание обслуживания», или последней активностью. Ее назна- чение заключается в перемещении транзакта с исходного обслужи- вающего устройства на целевое, а также в поиске транзактов для обслуживания на освободившемся исходном устройстве. Внутри по- следней активности возможны че- тыре варианта обработки транзак- та: • на исходном устройстве транзакт заканчивает передвиже- ние по ИМ и автоматически удаля- ется УПМ; • целевое устройство готово начать обслуживание транзакта, что и реализуется УПМ; • целевое устройство не го- тово начать обслуживание, а ис- ходное устройство наделено свой- ством сохранить транзакт до тех пор, пока целевое устройство на- ходится в данном состоянии; • целевое устройство не го- тово начать обслуживание, но ис- ходное устройство не наделено свойством сохранения транзакта. Этот случай возникает тогда, ко- гда разработчик ИМ не учел все аспекты взаимодействия элементов модели или ошибся при задании свойств исходного устройства. Как следствие, УПМ аварийно ос- танавливает эксперимент с ИМ. Таким образом, правильная обработка возникающих при завер- шении механизма обслуживания транзакта всевозможных вариантов обеспечивается УПМ MICIC4. В ре- зультате разработчику ИМ доста- точно сосредоточить свои усилия только на внутреннем взаимодей- ствии транзакта и устройства, что существенно облегчает напи- сание программы ИМ. Как правило, в ИМ существу- ет несколько групп однотипных по функционированию генераторов, устройств и транзактов. Каждая такая группа в MICIC4 называется компонентом. Различие между ком- понентом и элементом напоминает соотношение между классом и объ- ектом в технологии объектно- ориентированного программирова- ния [7]. То есть компонент пред- ставляет собой некоторый шаблон Прикладне програмне забезпечення 88 (тип), который характеризует со- стояние (набор значений стан- дартных и уникальных переменных) соответствующих ему элементов, а также связанный со статическими компонентами процесс. Конкретные элементы любого статического компонента модели, т.е. вида устройства либо гене- ратора, называются версиями уст- ройства или генератора соответ- ственно. Для динамических эле- ментов, т.е. транзактов, ис- пользуется термин копия. Таким образом, элементы одного и того же компонента модели совпадают по набору атрибутов (параметров) и процессу, а различаются по конкретным значениям, присвоен- ным атрибутам элементов, и сле- дующей активности процесса. Зна- чения как стандартных, так и уникальных атрибутов элементов сохраняются между активностями. 2. Статическая иерархическая структура имитационной модели При декомпозиции многих СС исследователю недостаточно ее представления в виде совокупно- сти неделимых элементов [2, 9]. Он вводит подсистемы, которые в свою очередь также могут содер- жать конечное количество подсис- тем и элементов. В MICIC4 под- системе соответствует составное устройство, называемое узлом. Причем в состав узла можно вво- дить другие узлы, не ограничивая количество уровней вложенности. Поскольку узел реализован как устройство, то для него так- же надо определить механизм об- служивания. При необходимости в одной из активностей данного процесса транзакт перемещается на определенное устройство, вхо- дящее в узел. При этом переходе механизм обслуживания на узле останавливается, пока транзакт не вернется снова на узел из любого внутреннего устройства узла. Считается, что транзакт находится одновременно и на узле и на внутреннем устройстве этого узла. При наличии иерархической статической структуры ИМ для транзакта необходимо задавать глубину вложенности — максималь- ное количество уровней, на кото- рое он может опуститься. По умолчанию глубина вложенности равна нулю. Кроме попадания на узел из- вне транзакт может быть порожден внутри самого узла. Если требу- ется переместить этот транзакт за пределы узла, то первоначаль- но он отправляется на сам узел. В этой ситуации из УПМ будет инициализирован механизм обслу- живания транзакта на узле, где и реализуется его дальнейшая тра- ектория движения по ИМ. Компоненты, соответствующие узлам, содержат внутри себя дру- гие компоненты — генераторы, уз- лы и элементарные устройства в строго фиксированном количестве. Поэтому согласно рассматриваемо- му способу формализации ИМ со- ставляется граф вложенности компонентов. В MICIC4 на основе опыта моделирования различных СС принято ограничение, заклю- чающееся в невозможности включе- ния одного и того же компонента в два разных узла. Данное огра- ничение не является очень стро- гим. Оно тривиально обходится пу- тем создания двух одинаковых компонентов, но с разными иден- тификаторами. Так как любой ком- понент может входить только в один узел или находиться на верхнем уровне иерархии, то граф статической структуры ИМ являет- ся деревом. Из-за наличия иерархии ста- тические элементы ИМ в MICIC4 имеют двойную адресацию: абсо- лютную и относительную. В первом случае доступ к элементу модели происходит по имени компонента и его абсолютному номеру среди всех элементов ИМ данного типа. Во втором случае областью види- Прикладне програмне забезпечення 89 мости является только узел, в который входит статический эле- мент модели. Очевидно, чтобы по- лучить доступ к элементу, являю- щемуся единственным в узле, дос- таточно указать только имя ком- понента. Перевод относительных адресов в абсолютные обеспечива- ется УПМ MICIC4. 3. Потоковая граф-схема имитационной модели Статическая структура ИМ по- зволяет отобразить свойство вло- женности (подчиненности) компо- нентов. Но любому дереву компо- нентов можно поставить в соот- ветствие произвольное количество вариантов состава статических элементов внутри узла. При этом элементы не связаны друг с дру- гом. Следовательно, вторым аспек- том декомпозиции объекта модели- рования должно быть построение динамической структуры ИМ. Она образуется путем созда- ния связей между статическими элементами модели. Очевидно, признаком связи является возмож- ность перемещения транзакта меж- ду элементами, т.е. отображением динамической структуры объекта моделирования служит граф-схема движения потоков транзактов по устройствам ИМ. Для ее однознач- ной трактовки предлагается ис- пользовать графические примити- вы, приведенные на рис. 1. Верши- ны граф-схемы соответствуют ста- тическим элементам модели, а ориентированные дуги показывают возможные пути перемещения тран- зактов. При этом каждому типу транзакта ставится в соответст- вие направленная линия с уни- кальными параметрами оформления (толщина, штриховка, …), как и каждому типу устройства — уни- кальный графический блок. Струк- тура узла может приводиться как на одной и той же схеме, так и отдельно. В рассматриваемой схеме формализации нет отдельного гра- фического блока для удаления транзактов. Эта операция реали- зуется в рамках механизма обслу- живания обычного устройства. А на граф-схеме в данной ситуации из блока, соответствующего уст- ройству, которое удаляет тран- закт, выходит меньше дуг, чем входит. В общем случае несколько одинаковых дуг, входящих в блок или выходящих из него, символи- зируют различные потенциальные пути движения одного и того же типа транзактов в устройство или из него. При правильном построе- нии граф-схемы в элементарное устройство должна входить по крайней мере одна дуга, а в ге- нератор не должна входить ни од- на. T3 T2 T1 G генератор типа G D элементарное устройство типа D без сохранения транзактов транзакты типов Т1, Т2, Т3 Node узел типа Node Q устройство типа Q с сохранением транзактов �X(k)� � X(k) � k устройств типа X, последовательно соединенных потоком транзактов типа Т k устройств типа X, через которые проходит k параллельных потоков транзактов типа Т T T Рис. 1. Графические примитивы для создания граф-схемы ИМ Прикладне програмне забезпечення 90 4. Особенности реализации УПМ Главной структурой УПМ MICIC4, обеспечивающей реализацию алгоритма организации квазипа- раллелизма, является массив событий. Отдельный элемент мас- сива событий содержит следующую информацию: • о модельном времени на- ступления события; • об элементе модели (тран- закте или генераторе), с которым связано событие; • об активности, которая является обработчиком данного события. Так как любое устройство без транзакта всегда находится в состоянии бездействия, то в мас- сиве событий не может быть на него ссылки. С другой стороны, транзакт не может одновременно обслуживаться на двух устройст- вах (при передаче транзакта внутрь узла механизм обслужива- ния на узле прерывается). Поэто- му в массиве событий достаточно хранить информацию только о ге- нераторе или транзакте. Обслужи- вающее устройство может быть найдено среди атрибутов транзак- та. Массив событий упорядочен по времени наступления события. Чем раньше должно произойти со- бытие, тем меньший номер оно имеет в массиве. Из УПМ цикличе- ски вызывается активность, соот- ветствующая наиболее раннему со- бытию. Очевидно, оно находится в начале массива. Этот элемент массива будем называть начальным событием, а связанный с ним эле- мент ИМ — активным. В языке моделирования MICIC4 любая активность пред- ставляет собой функцию базового универсального языка программиро- вания и включает в себя: • алгоритм обработки собы- тия, изменяющий состояние эле- ментов ИМ; • указание активности — об- работчика следующего события, которое произойдет в активном элементе ИМ в зависимости от его нового состояния; • синхронизацию, т.е. пла- нирование времени наступления следующего события в текущем ме- ханизме обслуживания транзакта на устройстве (механизме функ- ционирования генератора) или удаление начального события из массива в силу того, что время наступления следующего события в данном механизме определяется в других элементах ИМ; • возврат в УПМ признака продолжения или окончания репли- ки (прогона) ИМ. Операция планирования вре- мени наступления следующего со- бытия заключается в увеличении значения модельного времени для начального события. Так как мас- сив событий упорядочен по данно- му атрибуту (полю), то после сортировки, как правило, в нача- ле массива оказывается другой элемент. Тем более такая ситуа- ция возникает при удалении на- чального события из массива. Во избежание трудно локализуемых ошибок моделирования в активно- сти после операции синхронизации должен быть только оператор воз- врата в УПМ. Массивы структур также ис- пользуются для работы с компо- нентами и всеми видами элементов модели: генераторов, устройств, транзактов. Массив компонентов прежде всего является отображе- нием дерева вложенности компо- нентов. Помимо этого он предна- значен для решения следующих за- дач: • преобразования относи- тельных адресов статических эле- ментов в абсолютные; • поиска статических эле- ментов одного и того же типа Прикладне програмне забезпечення 91 внутри соответствующих массивов устройств и генераторов; • определения начальных ак- тивностей статических компонен- тов; • задания дисциплин обслу- живания и последних активностей устройств. Массив компонентов инициа- лизируется начальными значениями еще на этапе загрузки программы ИМ в оперативную память компью- тера. Затем отдельные свойства его элементов корректируются по мере добавления генераторов и устройств в соответствующие мас- сивы. Они должны быть сформиро- ваны до начала эксперимента с ИМ. После старта имитационного эксперимента массив компонентов доступен только для чтения, а попытка добавить еще один стати- ческий элемент приведет к ошибке выполнения. Состояние массива транзак- тов, наоборот, много раз изменя- ется во время прогона ИМ. Тран- закту при создании отводится свободный элемент массива. Да- лее, независимо от маршрута дви- жения, транзакт сохраняется в этом элементе вплоть до его уда- ления из модели. Следовательно, для операций с транзактом доста- точно знать всего лишь его ин- декс в массиве транзактов. В си- лу такой организации в нем, как правило, присутствуют пустые элементы, что следует учитывать при написании программы ИМ. Одним из атрибутов массивов генераторов, устройств и тран- зактов является номер компонен- та, которому принадлежит элемент модели. Остальные поля массивов уникальны для каждого вида (класса) и предназначены для реализации рассматриваемого спо- соба формализации объекта моде- лирования. Так как невозможно охватить все варианты взаимодей- ствия элементов модели, то раз- работчику программы ИМ предос- тавляются механизмы пополнения компонентов новыми атрибутами в рамках концепции объектно- ориентированного программирова- ния — наследования [7]. Доступ к ним осуществляется через те же самые массивы. Далее рассматри- ваются свойства базовых элемен- тов ИМ, которые, как только что отмечалось, обеспечиваются набо- ром стандартных атрибутов и реа- лизованными в MICIC4 алгоритмами их обработки. 5. Свойства базовых элементов MICIC4 Обслуживающее устройство. В элементе массива событий присут- ствует только ссылка на обслужи- вающийся транзакт. Устройство, на котором данный транзакт нахо- дится, является одним из атрибу- том транзакта и автоматически корректируется УПМ при движении транзакта по ИМ. При этом сохра- няется время рождения транзакта и обновляется время прибытия на очередное обслуживающее устрой- ство. Если транзакт переходит на внутреннее устройство узла, то атрибуты обслуживающего устрой- ства и времени прибытия изменя- ются на новые. Когда транзакт возвращается на узел, то значе- ния данных атрибутов восстанав- ливаются. Выбор маршрута движения транзактов. Непосредственное пе- ремещение транзакта с одного (ис- ходного) устройства на другое (целевое) реализует последняя активность механизма обслужива- ния исходного устройства. В лю- бой предыдущей активности данно- го процесса необходимо обеспе- чить выбор целевого устройства для дальнейшего движения. В про- тивном случае транзакт будет пы- таться обслуживаться на том же самом исходном устройстве. Данная концепция реализует- ся с помощью указателя Прикладне програмне забезпечення 92 направления движения по устрой- ствам модели — стандартного ат- рибута, которым обладает каждый транзакт. В процессе обслужива- ния необходимо изменить значение указателя, чтобы определить це- левое устройство. Поскольку в механизме обслуживания можно из- менять значение указателя произ- вольное количество раз в любой активности, то справедливо гово- рить, что в MICIC4 реализован программируемый динамический способ движения транзакта по мо- дели. Например, не составляет труда организовать выбор целево- го устройства в зависимости от выполнения некоторого условия или по вектору вероятностей (в этом случае на граф-схеме ИМ из исходного устройства будет выхо- дить более одной дуги с одинако- выми параметрами оформления). Разработчику ИМ необходимо учитывать ограничения по видимо- сти целевого устройства. Указа- телю можно присваивать: • целевое устройство из то- го же узла, что и исходное (пе- реход на одном уровне иерархии); • специальное константное значение OUTSIDE. В этом случае транзакт удаляется из ИМ последней активностью; • внутреннее устройство из узла, на котором обслуживается транзакт. Непосредственное пере- мещение транзакта на уровень ни- же реализуется специальной функ- цией синхронизации. При этом ак- тивное событие с информацией о следующей активности сохраняется в транзакте и удаляется из мас- сива событий, а УПМ запускает механизм обслуживания на внут- реннем устройстве. Если послед- нее невозможно, то генерируется ошибка моделирования; • узел, в который входит исходное устройство. Перемещение на уровень выше обеспечивается последней активностью исходного устройства. Если транзакт был создан внутри целевого узла, то запускается его механизм обслу- живания. В противном случае транзакт возвращается наверх и УПМ добавляет в массив событий новый элемент, восстанавливая механизм обслуживания на узле. Количество транзактов, од- новременно обслуживаемых на уст- ройстве. В MICIC4 в любой момент модельного времени на устройстве можно одновременно обслуживать один и более транзактов либо во- обще ни одного. Иногда такое свойство устройства называют многоканальностью, где одному обслуживающемуся транзакту выде- ляется один канал устройства. В MICIC4 используется дру- гая концепция многоканальности. Она основана на том, что устрой- ство имеет неотрицательный цело- численный атрибут, называемый "максимальный объем каналов VmaxD", а транзакт обладает ат- рибутом "занимаемый объем каналов VoccT". Оба указанных ат- рибута по умолчанию равны 1, т.е. транзакту выделяется один обслуживающийся канал устройст- ва. Объем занятых каналов уст- ройства VoccD определяется как сумма занимаемых каналов тех транзактов, которые обслуживают- ся на устройстве D. Очевидно, объем свободных каналов VfreD = VmaxD — VoccD. Из определе- ния также следует, что как VD, так и VT могут принимать нулевые значения. Если транзакт перемещается на условно занятое устройство, то возникает ошибка моделирова- ния и эксперимент с ИМ заверша- ется. Устройство D считается условно занятым для транзакта T, если выполняется следующее усло- вие: сумма текущего объема заня- тых каналов устройства и зани- маемого объема каналов пришедше- го на обслуживание транзакта Прикладне програмне забезпечення 93 больше максимального объема ка- налов данного устройства, т.е. VoccD + VoccT > VmaxD. В противном случае говорят, что устройство для транзакта свободно. В процессе моделирования можно изменять объем каналов как у устройств, так и у транзактов. При уменьшении максимального объема каналов устройства или при увеличении занимаемого объе- ма каналов транзактом контроли- руется только возможность выпол- нения операции. Если новое зна- чение данного атрибута транзакта приведет к нарушению условия за- нятости устройства, то действие будет проигнорировано. Аналогич- но нельзя уменьшить максимальный объем каналов устройства до зна- чения, меньшего, чем суммарный объем занятых каналов обслужи- вающимися на устройстве транзак- тами. При уменьшении занимаемого объема каналов у транзакта, если он ожидает обслуживания, УПМ пробует запустить механизм об- служивания устройства по указа- телю направления движения этого транзакта. Если увеличивается максимальный объем каналов уст- ройства, то УПМ пытается запол- нить появившиеся каналы транзак- тами, ожидающими обслуживания на нем. Управление началом обслужи- вания по приоритету. На устрой- ство, имеющее нулевой максималь- ный объем каналов, могут попасть только транзакты, занимающие нуль каналов, причем не испыты- вая конкуренции со стороны дру- гих транзактов. Чтобы была воз- можность ограничить автоматиче- ское попадание транзактов с ну- левым объемом каналов, в MICIC4 введено дополнительное условие начала обслуживания транзакта на устройстве. Устройство и транзакт наде- лены стандартным неотрицательным целочисленным атрибутом PD и PT соответственно, который называет- ся "приоритет". Если PT > PD, т.е. приоритет транзакта больше при- оритета устройства, на которое перемещается данный транзакт, то говорят, что устройство условно закрыто и возникает ошибка моде- лирования, а эксперимент с ИМ завершается. Изменение приорите- та обслуживающегося транзакта (в отличие от корректировки зани- маемого им объема каналов) нико- им образом не сказывается на его текущем обслуживании. Аналогично изменение приоритета обслужи- вающего устройства не влияет на находящиеся на нем транзакты. Однако увеличение приоритета устройства приводит к попытке УПМ начать обслуживание тех транзактов, которые не могли по- пасть на данное устройства из-за своего высокого приоритета. Очевидно, если транзакт имеет нулевой приоритет и нуле- вой объем каналов, то он не име- ет ограничений по обслуживанию на любом устройстве. В общем случае, для начала обслуживания транзакта T на устройстве D должно выполняться следующее ус- ловие: VoccT ≤VfreD & PT≤PD . Варьирование объемом каналов и приоритетом позволяет эффектив- но реализовать взаимодействие ин- формационных и управляющих тран- зактов в ИМ. Режимы окончания обслужива- ния транзакта на устройстве. Уст- ройство может быть очередью или сервером. Устройство-очередь со- храняет транзакты, перемещающие- ся с него последней активностью на обслуживание на условно за- нятое или условно закрытое целе- вое устройство. Транзакты при этом переходят в ждущее состоя- ние (из serving в waitingstart). Когда появляется возможность продолжения движения на целевое Прикладне програмне забезпечення 94 устройство, УПМ запускает обра- ботчик данного события, в кото- ром разработчик ИМ может выпол- нить заключительные операции по обслуживанию (чаще всего это об- новление статистик моделирова- ния). По умолчанию устройство яв- ляется сервером, т.е. без сохра- нения транзактов. Для нормально- го выполнения последней активно- сти на сервере необходимо, чтобы целевое устройство, куда переме- щается транзакт, было для него свободно и открыто. Иначе возни- кает ошибка и эксперимент с ИМ завершается. Частным случаем очереди яв- ляется устройство, в котором транзакты сохраняются ограничен- ный интервал модельного времени, находясь в состоянии waitingtime. Если в течение дан- ного интервала целевое устройст- во оказалось готово начать об- служивание, то транзакт выходит из очереди. В противном случае по истечении заданного интервала УПМ вызывает обработчик события, где необходимо либо определить новый интервал ожидания, либо перенаправить транзакт на другое устройство. Уход транзакта с устройст- ва. После ухода транзакта Т1 с устройства D1 на некоторое уст- ройство D0 освобождается опреде- ленный объем каналов. Вследствие чего УПМ пытается найти для об- служивания транзакты, находящие- ся в ждущем состоянии в очередях и чей указатель направления дви- жения совпадает с исходным уст- ройством D1, т.е. тех транзак- тов, которые не смогли ранее на- чать обрабатываться из-за недос- таточного объема свободных кана- лов. Если находится такой тран- закт Т2, то УПМ запускает новый механизм обслуживания. При ос- тавшемся объеме свободных кана- лов на исходном устройстве D1 поиск транзактов продолжается. Следует обратить внимание, что механизмы обслуживания М1 — транзакта Т1 на устройстве D0 и М2 — транзакта Т2 на устройстве D1 начинаются в один и тот же мо- мент модельного времени. Однако в реальном времени УПМ отдает приоритет процессу М1. Если тре- буется изменить порядок выполне- ния процессов, то надо в первой активности механизма обслужива- ния М2 оставить состояние без изменения и запланировать сле- дующее событие через ничтожно малый момент модельного времени. Тем самым цель будет достигнута всего лишь за счет введения «лишней» активности. Поскольку прибывший тран- закт Т2 освобождает свой объем каналов на прежнем устройстве D2 (откуда он ушел), то УПМ пытает- ся найти транзакты на обслужива- ние и для этого устройства D2. Такой циклический процесс про- должается, пока не будет найдено ни одного транзакта на обслужи- вание. Иными словами, если име- ется последовательность уст- ройств Dn,…, D2, D1 с ограниченным объемом каналов, полностью заня- тых транзактами, находящимися в состоянии waitingstart или waitingtime, то при уходе тран- закта с устройства D1 УПМ реали- зует попытку перемещения тран- зактов с устройства Di на уст- ройство Di-1 для всех i от 2 до n. Очередность выбора транзак- тов на обслуживание. Порядок вы- бора транзактов на обслуживание на освободившееся или открывшее- ся устройство определяется дисциплиной обслуживания, пред- ставляющей собой функцию языка моделирования MICIC4. В нем реа- лизованы стандартные дисциплины обслуживания и предоставлены ме- ханизмы для создания уникальных дисциплин разработчиком ИМ. Ос- Прикладне програмне забезпечення 95 новная идея заключается в том, что УПМ находит пребывающие в состоянии waitingstatrt или waitingtime транзакты, указатель направления движения которых совпадает с устройством, запро- сившим транзакты. Если кандида- тов на обслуживание оказывается больше, чем способно принять устройство, то разработчик моде- ли с помощью дисциплины обслужи- вания разрешает конфликт. При таком подходе искомые транзакты не обязательно должны находиться в одной и той же оче- реди. Однако невозможно обеспе- чить обратное, т.е. переход транзактов на обслуживание из общей очереди на любое устройст- во из группы устройств DD = {D1, D2,…, Dn,}, которое освобо- дилось первым. Чтобы снять дан- ное ограничение, каждое устрой- ство имеет стандартный атрибут, называемый направляемым устройством. Этот атрибут для группы DD должен указывать на любое устройство из DD (но одно и то же!). Пусть для определен- ности это будет устройство D1. Если транзакт из общей очереди не может продолжить обслуживание ни на одном из устройств группы, то его указателю направления дви- жения необходимо присвоить зна- чение направляемого устройства D1. Как только любое из устройств группы DD освободится, то УПМ будет искать кандидатов на об- служивание также среди транзак- тов, ждущих освобождения направ- ляемого устройства D1. Таким образом, в MICIC4 от- сутствуют ограничения на порядок выбора транзактов на обслужива- ние из одной или более очередей. Внешние события для тран- закта. Практически в каждой ИМ приходится нарушать тривиальное обслуживание транзакта на уст- ройстве, заключающееся в синхро- низации с УПМ по временным за- держкам. Например, может понадо- биться прервать обслуживание при или до наступления определенного события; организовать параллель- ное движение нескольких тран- зактов с независимым или подчи- ненным управлением; сначала рас- щепить транзакт на несколько по- томков, а затем собрать их вме- сте и т.п. Эти операции реализу- ются через прием транзактом сле- дующих сигналов: «Задержать», «Отпустить», «Исключить», «Унич- тожить». Сигнал «Задержать» перево- дит транзакт в состояние delayed, перемещая соответствую- щее транзакту событие из массива событий в область стандартных атрибутов транзакта. Тем самым выполнение механизма обслужива- ния откладывается на неопреде- ленный интервал модельного вре- мени до получения транзактом сигнала «Отпустить». Данный сиг- нал возвращает событие в массив, и УПМ передает управление вос- становленной активности в задан- ный момент модельного времени. Эти сигналы подаются именно на транзакт, а не на устройство, чтобы исключить неоднозначность, связанную с многоканальностью устройства. В случае получения сигнала «Уничтожить» обслуживание тран- закта прерывается и он поглоща- ется УПМ. Также удаляется эле- мент массива событий, соответст- вующий транзакту, если он нахо- дится в состоянии serving. В ре- зультате уничтожения транзакта освобождаются соответствующие каналы как обслуживавшего уст- ройства, так и внешних узлов, через которые он попал на данное устройство. Как следствие, реа- лизуется попытка принять на об- служивание на эти устройства но- вые транзакты. Сигнал «Исключить» перево- дит транзакт в состояние "excluded", также прерывая об- Прикладне програмне забезпечення 96 служивание транзакта на устрой- стве с высвобождением занятых каналов обслуживавшего устройст- ва и внешних узлов, но не удаляя транзакт из ИМ. И только этим он отличается от сигнала «Уничто- жить». Время перехода транзакта в данное состояние заносится в его атрибут "время начала обслуживания". Далее в опреде- ленный момент исключенный тран- закт можно снова отправить на обслуживание, т.е. в состояние "serving", таким же точно обра- зом, как впервые созданный тран- закт. Если транзакт задерживает, исключает или уничтожает самого себя, то из массива событий уда- ляется начальный элемент. Как отмечалось выше, во избежание ошибки моделирования после лю- бого из данных действий в актив- ности необходимо сразу же воз- вратиться в УПМ. Внешние события для генера- тора. Генератор может принимать сигналы: «Пассивизировать», «Активизировать». Первый сигнал временно запрещает выполнение очередной активности процесса, убирая ее из массива событий. При этом в свойствах генератора сохраняется следующая выполняе- мая активность. Если генератор переводит в пассивное состояние самого себя, то данное действие в активности должно быть послед- ним. Второй сигнал, соответст- венно, возвращает отложенную ак- тивность генератора в массив со- бытий и передает на нее управле- ние в заданный момент модельного времени. Первоначально в ИМ ге- нератор добавляется в пассивном состоянии. Фактически, эта пара сигналов является полным анало- гом сигналов для транзакта «За- держать»/«Отпустить». Организация стохастического потока внешних событий посредст- вом генератора. Как отмечалось выше, генераторы предназначены для организации потоков внешних событий в ИМ. Причем в подавляю- щем большинстве случаев данные потоки являются стохастическими [2, 9]. Поэтому одним из стан- дартных свойств генератора явля- ется номер датчика случайных чисел, который будет давать реа- лизации случайной величины со- гласно требуемому закону распре- деления. Если для генератора требуется более одного потока, то их необходимо реализовать че- рез уникальные свойства генера- тора. Уникальные атрибуты элемен- тов ИМ. Если для отражения функ- ционирования элементов модели стандартных атрибутов недоста- точно, то устройства, транзакты и генераторы дополняются множе- ствами уникальных атрибутов. Прикладне програмне забезпечення 97 Обработка значений уникальных атрибутов реализуется внутри ак- тивностей с помощью всего арсе- нала средств базового языка про- граммирования ИМ. Важная особен- ность уникальных атрибутов за- ключается в сохранении состояния элементов между различными ак- тивностями одного и того же про- цесса. 6. Графическое отображение меха- низмов обслуживания Механизм обслуживания тран- закта на устройстве схематически задается графом переходов между активностями. При этом рекомен- дуется придерживаться обозначе- ний, представленных на рис. 2. Вершины соответствуют активно- стям, а маркированные направлен- ные дуги — переходам между ак- тивностями и внешним управляющим сигналам. Механизм обслуживания в лю- бом случае содержит по крайней мере две активности: начальную и конечную. У устройства-сервера они соединены одинарной сплошной дугой, а у очереди — пунктирной. E E w t FirstAct начальная активность с именем FirstAct( ) последняя активность StopService( ) LastAct последняя активность с именем LastAct( ), заканчивающаяся вызовом StopService( ) или вызываемая из StopService( ) Act внутренняя активность с именем Act( ) планирование события через модельное время t переход в состояние serving из состояния w (waitingstart, delayed или excluded), связанного с удалением из массива событий перевод в состояние serving внешним (-него) элементом (-та) Е t переход в состояние serving из состояния waitingtime через модельное время t удаление транзакта и связанного с ним события внешним элементом Е или удаление внешнего транзакта Е E перевод в состояние delayed или excluded внешним (-него) элементом (-та) Е Рис. 2. Условные обозначения при отображении механизма обслуживания транзакта на устройстве Прикладне програмне забезпечення 98 Двойные серые дуги являются ви- сячими и предназначены для ука- зания управляющих сигналов в направлении других элементов ИМ. Любой исходящей дуге должна со- ответствовать хотя бы одна вхо- дящая дуга в другом механизме обслуживания транзакта (функцио- нирования генератора) и наобо- рот. Данные дуги помечаются идентификаторами внешних элемен- тов. Аналогично отображается удаление транзакта из ИМ другим ее элементом. Для механизма функциониро- вания генератора используются те же самые графические примитивы. Активному состоянию генератора соответствует состояние транзак- та serving, а пассивному — delayed. Очевидно, что в меха- низмах функционирования генера- торов отсутствует последняя ак- тивность. Выводы Описанная концепция струк- туризации подсистем и элементов СС и представление динамики их взаимодействия с помощью выше- приведенных базовых конструкций носит название формализации объ- екта моделирования согласно БСФ MICIC4. Методика формализации включает следующую последова- тельность этапов: • определение иерархиче- ской статической структуры объ- екта моделирования; • выделение динамических потоков транзактов; • построение сетевой граф- схемы ИМ на каждом уровне иерар- хии; • определение уникальных атрибутов всех компонентов моде- ли; • графическое отображение механизмов функционирования ге- нераторов и обслуживания тран- зактов на устройствах; • алгоритмизация активно- стей механизмов. Прикладне програмне забезпечення 99 Овладение данной методикой необходимо для написания про- граммы ИМ на языке моделирования MICIC4, который предоставляет взаимно-однозначный программный интерфейс, позволяющий автомати- зировать дискретно-событийное мо- делирование СС на высоком (доста- точном) уровне детализации. 1. Задачи и модели ИСО. Ч.3. Техноло- гия имитации на ЭВМ и принятие ре- шений: Уч. пособие/ И.В. Максимей, В.Д. Левчук и др. — Гомель: БелГУТ, 1999. — 150 с. 2. Технология системного моделирова- ния/ Е.Ф. Аврамчук, А.А. Вавилов, С.В. Емельянов и др. Под общ. ред. С.В. Емельянова, В.В. Калашникова и др. — М.: Машиностроение, 1988. — 520 с. 3. Рыжиков Ю.И. Имитационное моделиро- вание. Теория и технологии. — М.: Альтекс-А, 2004. — 384 с. 4. Шрайбер Т.Дж. Моделирование на GPSS. — М.: Машиностроение, 1980. — 592 с. 5. Томашевский В.Н., Жданова Е.Г. Ими- тационное моделирование в среде GPSS. — М.: Бестселлер, 2003. — 416 с. 6. Прицкер А. Введение в имитационное моделирование и язык СЛАМ II. — М.: Мир, 1987. — 646 с. 7. Страуструп Б. Язык программирования C++: 3-е изд. — М.: БИНОМ, 1999. — 991 с. 8. Шеннон Р. Имитационное моделирова- ние систем: искусство и наука. — М.: Мир, 1978. — 418 с. 9. Лоу А., Кельтон В. Имитационное мо- делирование. Классика CS: 3-е изд. — СПб.: Питер, 2004. — 847 с. Получено 29.09.04 Об авторе Левчук Виктор Дмитриевич, доцент, канд. техн. наук Место работы автора: Гомельский государственный унивеситет им. Ф. Скорины, кафедра математических проблем управления 246699, Гомель, ул. Победы, 27а/31 Тел. 55 7828 (дом.), 56 4237 (раб.)
id	nasplib_isofts_kiev_ua-123456789-1323
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
issn	1727-4907
language	Russian
last_indexed	2025-12-07T17:22:11Z
publishDate	2005
publisher	Інститут програмних систем НАН України
record_format	dspace
spelling	Левчук, В.Д. 2008-07-25T15:40:08Z 2008-07-25T15:40:08Z 2005 Базовая схема формализации системы моделирования MICIC4 / В.Д. Левчук// Проблеми програмування. — 2005. — N 1.— С. 85–96. — Бібліогр.: 9 назв. — рос. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/1323 681.3 Рассматривается базовая схема формализации, лежащая в основе системы моделирования MICIC4, в которой реализован транзактный способ имитации. Полная функциональность MICIC4 обеспечивается программируемым интерфейсом, который по своей сути близок к понятию "процесс". Определены базовые элементы и их свойства, статическая иерархическая структура и потоковая граф-схема имитационной модели, особенности реализации управляющей программы моделирования, графическое отображение механизмов обслуживания. Приводится методика формализации сложной системы согласно предложенной базовой схемы. Розглядається базова схема формалізації, що лежить в основі системи моделювання MICIC4, в якій закладено транзактний спосіб імітації. Повна функціональність MICIC4 забезпечена програмованим інтерфейсом, який за своєю суттю є близьким до поняття «процес». Сформульовані базові елементи i властивості, статична ієрархічна структура i потокова граф-схема імітаційної моделі, особливості реалізації керуючої програми моделювання, графічне відображення механізмів обслуговування. Приведена методика формалізації складної системи відповідно до запропонованої базової схеми. The base scheme of a formalization for the simulation engine MICIC4 to be controlled on the transaction way of a modeling is considered in the article. The full performance of MICIC4 is ensured by a programmed interface to be closed to the notion «process». The base elements and their features, a static hierarchal structure and flow graphs of a simulation model, details of the organization of a simulation control program are defined. The algorithm of a complex system formalization accordingly to the offered base scheme is given in conclusions. ru Інститут програмних систем НАН України Прикладне програмне забезпечення Базовая схема формализации системы моделирования MICIC4 Базова схема формалізації системи моделювання MICIC4 The Base Scheme of a Formalization for the Simulation Engine MICIC4 Article published earlier
spellingShingle	Базовая схема формализации системы моделирования MICIC4 Левчук, В.Д. Прикладне програмне забезпечення
title	Базовая схема формализации системы моделирования MICIC4
title_alt	Базова схема формалізації системи моделювання MICIC4 The Base Scheme of a Formalization for the Simulation Engine MICIC4
title_full	Базовая схема формализации системы моделирования MICIC4
title_fullStr	Базовая схема формализации системы моделирования MICIC4
title_full_unstemmed	Базовая схема формализации системы моделирования MICIC4
title_short	Базовая схема формализации системы моделирования MICIC4
title_sort	базовая схема формализации системы моделирования micic4
topic	Прикладне програмне забезпечення
topic_facet	Прикладне програмне забезпечення
url	https://nasplib.isofts.kiev.ua/handle/123456789/1323
work_keys_str_mv	AT levčukvd bazovaâshemaformalizaciisistemymodelirovaniâmicic4 AT levčukvd bazovashemaformalízacíísistemimodelûvannâmicic4 AT levčukvd thebaseschemeofaformalizationforthesimulationenginemicic4

Базовая схема формализации системы моделирования MICIC4

Репозитарії

Схожі ресурси