Оретические основы 1итационного моделирования

1);.

• Ithink—3.0.61 (компания «High Performance Systems», Ганновер, -Хэмпшир, США);

• Extend+BPR-3.1 (компания «Imagine That!», Сан-Хосе, Кали-
эрния, США);

• ReThink (фирма «Gensym», Кембридж, Массачусетс, США);

• Pilgrim (Россия).

Пакет Process Charter-1.0.2 имеет «интеллектуальное» средство строения блок-схем моделей. Он ориентирован в основном на юкретное моделирование. Имеет достоинства: удобный и простой использовании механизм построения модели, самый дешевый из гречисленных продуктов, хорошо приспособлен для решения задач:пределения ресурсов. Недостатки пакета: наименее мощный про-г, слабая поддержка моделирования непрерывных компонентов, эаниченный набор средств для анализа чувствительности и по-гния диаграмм.

Пакет Powersim-2.01 является хорошим средством создания не-эывных моделей. Имеет достоинства: множество встроенных 1Й, облегчающих построение моделей, многопользователь-зкий режим для коллективной работы с моделью, средства обработ-массивов для упрощения создания моделей со сходными компо­зитами. Недостатки пакета: сложная специальная система обозна­чений System Dynamics, ограниченная поддержка дискретного моде­лирования.

Пакет Ithink-3.0.61 обеспечивает создание непрерывных и дис­кретных моделей. Имеет достоинства: встроенные блоки для облег­чения создания различных видов моделей, поддержка авторского

моделирования слабо подготовленными пользователями, подробная обучающая программа, развитые средства анализа чувствительно­сти, поддержка множества форматов входных данных. Недостатки пакета: сложная система обозначений System Dynamics, поддержка малого числа функций по сравнению с Powersim-2.01.

Пакет Extend+BPR-3.1 (BPR - Business Process Reengineering) создан как средство анализа бизнес-процессов, использовался в NASA, поддерживает дискретное и непрерывное моделирование. Имеет достоинства: интуитивно понятная среда построения моделей с помощью блоков, множество встроенных блоков и функций для облегчения создания моделей, поддержка сторонними компаниями (особенно выпускающими приложения для «вертикальных» рын­ков), гибкие средства анализа чувствительности, средства создания дополнительных функций с помощью встроенного языка. Недостат­ки пакета: используется в полном объеме только на компьютерах типа Macintosh, имеет высокую стоимость.

Пакет ReThink обладает свойствами Extend+BPR-3.1 и в отличие от перечисленных пакетов имеет хороший графический транслятор для создания моделей. Работает под управлением экспертной обо­лочки G2. Имеет достоинства: все положительные свойства Extend+BPR-3.1 и общее поле данных с экспертной системой реаль­ного времени, создаваемой средствами G2.

Пакет Pilgrim обладает широким спектром возможностей имита­ции временной, пространственной и финансовой динамики модели­руемых объектов. С его помощью можно создавать дискретно-непрерывные модели. Разрабатываемые модели имеют свойство коллективного управления процессом моделирования. В текст моде­ли можно вставлять любые блоки с помощью стандартного языка C++. Различные версии этой системы работали на IBM-совместимых и DEC-совместимых компьютерах, оснащенных Unix или Windows. Пакет Pilgrim обладает свойством мобильности, т.е. переноса на лю­бую другую платформу при наличии компилятора C++. Модели в системе Pilgrim компилируются и поэтому имеют высокое быстро­действие, что очень важно для отработки управленческих решений и адаптивного выбора вариантов в сверхускоренном масштабе време­ни. Полученный после компиляции объектный код можно встраи­вать в разрабатываемые программные комплексы или передавать (продавать) заказчику, так как при эксплуатации моделей инстру­ментальные средства пакета Pilgrim не используются. Система имеет сравнительно невысокую стоимость.

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

В конце 1990-х гг. в России разработаны новые системы:

• пакет РДО (МГТУ им. Н.Э. Баумана);

• система СИМПАС (МГТУ им. Н.Э. Баумана);

• пятая версия Pilgrim (МЭСИ и несколько компьютерных

Ирм).

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

Система СИМПАС (СИМПАС - СИстема-Моделирования-на-^Скале) в качестве основного инструментального средства ис­пользует язык программирования Паскаль. Недостаток, связанный |со сложностью моделирования на языке общего назначения, ком-' пенсируется специальными процедурами и функциями, введенными ■разработчиками этой системы. Проблемная ориентация системы -, это моделирование ^jra^o^MaiDiOHHbK процессов, компьютеров-)жной архитектуры[и^^комдьютёрньщ сетей. ~ """ Пятая версия Pilgrim - это новый программный продукт, соз-' данный в 2000 г. на объектно-ориентированной основе и учитываю­щий основные положительные свойства прежних версий. Достоин­ства этой системы:

• ориентация на совместное моделирование материальных, ин­
формационных и «денежных» процессов;

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

• наличие интерфейсов с базами данных;

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

• возможность управления моделями непосредственно в процес­
се их выполнения с помощью специальных окон диалога.

В данной книге при рассмотрении практических задач и приме­ров имитационного моделирования используются концепция, воз­можности и функциональные средства системы Pilgrim. Это объяс­няется тем, что в новом поколении Государственных образователь­ных стандартов высшего профессионального образования, введен­ном в России с 2000 г., идеология именно этой системы заложена в дидактическое содержание двух компьютерных дисциплин:

• «Имитационное моделирование экономических процессов» -
специальность 351400 «Прикладная информатика (по областям)» для
областей «экономика» и «менеджмент»;

• «Компьютерное моделирование» - специальность 351500
«Математическое обеспечение и администрирование информацион­
ных систем».

Однако читатели, знакомые с имитационным моделированием и применением других пакетов моделирующих программ (например, GPSS), могут убедиться в том, что подхЬды и методические приемы, используемые в данном пособии, могут быть реализованы с помо­щью разных моделирующих систем.

 

Ш

1.1

ОСНОВНЫЕ ПОНЯТИЯ. РАЗНОВИДНОСТИ ИМИТАЦИОННОГО

МОДЕЛИРОВАНИЯ

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

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

Имитационное моделирование как особая информационная тех-элогия состоит из следующих основных этапов. **; 1. Структурный анализ процессов. Проводится формализация '1чруктуры сложного реального процесса путем разложения его на Подпроцессы, выполняющие определенные функции и имеющие взаимные функциональные связи согласно легенде, разработанной I рабочей экспертной группой. Выявленные подпроцессы, в свою ■ очередь, могут разделяться на другие функциональные подпроцес­сы. Структура общего моделируемого процесса может быть пред-'■' ставлена в виде графа, имеющего иерархическую многослойную

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

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

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

• описание вручную на языке типа GPSS, Pilgrim и даже на Visual Basic. Последний очень прост, на нем можно запрограммиро­вать элементарные модели, но он не подходит для разработки реаль­ных моделей сложных экономических процессов, так как описание модели средствами Pilgrim компактнее аналогичной алгоритмиче­ской модели на Visual Basic в десятки-сотни раз;

• автоматизированное описание с помощью компьютерного гра­фического конструктора во время проведения структурного анализа, т.е. с очень незначительными затратами на программирование. Та­кой конструктор, создающий описание модели, имеется в составе системы моделирования в Pilgrim.

3. Построение модели (build). Обычно это трансляция и редак­тирование связей (сборка модели), верификация (калибровка) пара­метров.

Трансляция осуществляется в различных режимах:

• в режиме интерпретации, характерном для систем типа GPSS,
SLAM-II и ReThink;

• в режиме компиляции (характерен для системы Pilgrim).
Каждый режим имеет свои особенности. '

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

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

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

4. Проведение экстремального эксперимента для оптимизации определенных параметров реального процесса. Планированию таких экспериментов посвящена глава 7.

Примеры, приводимые в данной книге, в основном ориентирова­
ны на систему Pilgrim, получившую распространение в экономиче­
ских вузах России. Однако читатели, владеющие GPSS, SLAM-II или
ReThink, без особого труда увидят общие методические приемы, не
зависящие от выбранной системы. \

Концепция имитационного моделирования требует предвари­тельного знакомства читателя с методом Монте-Карло, с методоло­гией проведения проверок статистических гипотез, с устройством программных датчиков случайных (псевдослучайных) величин и с особенностями законов распределения случайных величин при мо­делировании экономических процессов, которые не рассматривают­ся в типовых программах дисциплины «Теория вероятностей».

Кроме того, необходимо рассмотреть специальные стохастиче­ские сетевые модели, которые дают представление о временных диаграммах специальных имитационных процессов при вьшолнении программной модели.

1.2

Государственной службы

1.4

И ВРЕМЕННЫЕ ДИАГРАММЫ

ИНТЕРВАЛОВ АКТИВНОСТИ

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

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

Идею предлагаемой концепции рассмотрим на примере из кон­кретного проекта «Открытое образование» («е-образование»), реали­зуемого под патронажем Международной академии открытого обра­зования (МАОО).

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

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

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

IB системе открытого образования ресурсы используются в рае­шном режиме. Ресурсы распределенного института можно на два типа: интеллектуальный ресурс (учитель) и учебный (далее - просто ресурс).

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

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

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

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

В университетах используется более подходящее слово «курс». Однако в есах поддержки общности с экономикой используется термин «процесс».

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

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

В более реальном случае (рис. 1.8,6) при конечных мощностях глобальных ресурсов появляется состояние ожидания ресурса, когда процессу (точнее, студенту в процессе изучения дисциплины) нуж­ны ресурсы (HP).

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

еще два состояния (рис.1.8,в): подготовка к выполнению (ТВ) ^завершение выполнения - контрольные мероприятия, экзамены,

(ЭЗ).

Рис. 1.8. Диаграммы состояний процессов (курсов): ! - мощности ресурсов бесконечны; б - мощности ресурсов конечны; в - мощности ресурсов конечны, есть накладные расходы времени; - ждет студентов; ГВ - готовится к выполнению; HP - нужны ресурсы; ПУ - учеба по дисциплине; ЭЗ - экзамен, зачет

k- Когда возникает потребность в незапланированных ресурсах, то «ожны обратные переходы типаПУ-»НР (рис. 1.8,5,1.8,в). Такие гходы могут привести к блокировкам, которые можно разрешить ющью известных решений задачи взаимного исключения.

Во время подготовки к выполнению (ГВ) осуществляется плани-ie ресурсов, а после завершения (ЭЗ) - возврат ресурсов в рас-яше планирующих и распределяющих процессов. Организация и взаимосвязь различных компонентов системы от-•го образования может быть рассмотрена относительно управ-процессами в следующих подразделениях университета tc. 1.9):

• управления учебной и учебно-методической работой (УУМР),
"Тагоров ведает всеми ресурсами, относящимися к учебному процессу;

• дирекции распределенного университета, которая совместно с
(.^ерриториально-распределенными филиалами университета (парт­
нерами) отвечает за реализацию учебного плана;

1\ • учебно-методологического совета (УМС), который работает дирекции в качестве коллегиального совещательного органа для >янного совершенствования государственных образовательных __лартов (ГОС), изменяющихся примерно раз в пять лет, и учеб-IJoro плана, который корректируется ежегодно (в рамках действую-

[егоГОС);

• кафедр (распределенных кафедр открытого образования). Ка-
лэы - это обладатели интеллектуального ресурса (профессорско-

^подавательского состава, тренеров (тьюторов-консультантов), жирантов, докторантов и других преподавателей).

Далее перейдем к оценке времени изучения студентами дисцип-_j учебного плана. Время прохождения всех дисциплин учебного гана студентом - это время пребывания заявки в стохастической ги (см. рис. 1.7). Заявки в такой сети будем называть «транзакта-[», чтобы отличать от других элементарных заявок. Транзакт, попадая из одного узла сети (процесс-производитель) в -ой узел (процесс-потребитель), свидетельствует о необходимо-изучения студентом следующей дисциплины учебного плана. Joane этого процесс-потребитель выводится из состояния ЖС и юпадает в состояние ГВ. После выделения ресурсов (HP), выполне­ния функции (ПУ) и завершения выполнения контрольных меро­приятий (ЭЗ) транзакт появляется на выходе узла-производителя, а •цесс возвращается в состояние ЖС. Случайный интервал време-ограниченный моментом выхода процесса из состояния ЖС в яале изучения дисциплины и ближайшим моментом попадания в [ало состояние, назовем интервалом активности процесса. Длитель­ность пребывания транзакта в соответствующем узле - это интервал [i активности. Для оценки времени реакции системы открытого обра-^„Зования, реализуемой в рамках распределенного института по учеб-f;HOMy плану, необходимо уметь рассчитывать значения интервалов (-(^тивности всех процессов, входящих в состав сети. % Оценка интервала активности процесса. Далее построим ите-ирационную процедуру, позволяющую провести соответствующие ^оценки. Обозначим А - начало очередной итерации; Б - конец оче-|редной итерации.

 

 

 

 

 

2.2

СОЗДАНИЕ

5.1

5.3

В СИСТЕМЕ PILGRIM

Конструктор моделей состоит из программного файла gem.exe, файлов настроек с расширением ini, файла помощи и примеров ими­тационных моделей. При запуске gem.exe на выполнение перед пользователем появляется основное окно, содержащее меню, панель «горячих кнопок», панель инструментов, информационную строку (рис. 5.4). Область построения графа модели пуста, для редактиро­вания необходимо создать новую модель либо загрузить ранее со­храненную. Рассмотрим сначала выполняемые конструктором опе­рации с файлами.

Всю информацию о модели конструктор сохраняет в файле с расширением «pgf» (Pilgrim graph file). При создании законченной версии имитационной модели пользователь может генерировать программный файл Pilgrim с расширением «срр» (с plus plus). Этот файл далее компилируется в среде Visual C++ с подключением не­обходимых библиотек и ресурсов Pilgrim. Создаваемый конструкто­ром программный файл с расширением «срр» при своей генерации

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

Создание новой модели, сохранение и загрузка версий выполня­ются выбором соответствующих пунктов раздела «Файл» основного меню программы или через «горячие кнопки».

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

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

В панели инструментов находится набор значков всех типов уз­лов системы (см. рис. 5.1). Следует заметить, что для нескольких различных типов узлов может существовать одно и то же обозначе­ние. Например, квадратом обозначаются узлы типа queue, send и attach. Поэтому под каждым значком с изображением узла находится кнопка с текущим типом создаваемых узлов данного обозначения. Для изменения типа достаточно щелкать мышью по кнопке с именем типа до появления необходимого. '

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

Аналогичным образом выполняется удаление узла: в панели ин­струментов необходимо захватить значок удаления узла и перета­щить его на узел, который требуется удалить. Узел будет удален вместе со всеми входящими и исходящими ссылками. Дополнитель­ные условия возникают при удалении узлов, содержащих переход на нижнюю плоскость. Например, если требуется удалить узел типа parent, то конструктором проверяется условие пустой детализирую­щей плоскости. Алгоритм конструктора не позволит удалить узел типа parent, пока на детализирующей его плоскости находится хотя бы один узел, так как это приведет к его потере. Чтобы упростить удаление множества узлов на плоскости, к которой ссылается, к примеру, parent, в меню «плоскость» существует специальный пункт «удалить все узлы текущей плоскости».

Несколько по-иному, чем для parent, реализовано разрешение на удаление узлов обращения к подпрограмме, т. е. pay, rent, down. Ес­ли в модели имеется плоскость-подпрограмма для единственного узла pay, rent или down, то его нельзя удалить, пока плоскость не пуста (так же как в случае с parent). Если же к подпрограмме обра­щаются несколько узлов типа pay, rent или down, то конструктор позволяет удалить любой из них, так как в этом случае плоскость-подпрограмма не теряется, поскольку продолжают существовать 172

сылки, на нее указывающие. Таким образом, смысл условий удале-узлов, порождающих плоскости, крайне прост: необходимо, 5ы в модели не был потерян ни один узел. Создание ссылок, или путей переходов транзактов, происходит недующим образом: в панели инструментов захватывается значок |ваправленной в экран стрелки (перекрестие, заключенное в круг) и деремещается на узел-источник транзакта. При отпускании кнопки f мыши за курсором потянется стрелка, обозначающая ссылку с невы-. эранным узлом-приемником транзакта. Для выбора узла-приемника

(

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

Следует помнить, что некоторые типы узлов не могут иметь 1 входящие или, напротив, исходящие ссылки. Конструктором посто-| янно выполняется проверка корректности действий пользователя, I запрещающая заведомо недопустимые преобразования графа моде­ли, в частности создание неправильных ссылок.

Определение параметров узла. Каждый узел модели характе­ризуется множеством параметров: типом, порядковым номером, I именем, принадлежностью к плоскости, ссылками и условиями пе­реходов, встроенным программным текстом, а также непосредствен­но параметрами, определяемыми спецификой типа узла, такими, как закон распределения для узла типа serv, приоритет для queue и т.п. Для просмотра или редактирования параметров узла необходимо дважды щелкнуть по нему левой кнопкой мыши либо один раз щелкнуть по узлу правой кнопкой, в результате чего отобразится всплывающее меню, и выбрать в нем пункт «параметры узла». Поя­вится диалоговое окно, определяющее параметры. На рис. 5.5 пока­зано окно параметров узла типа serv, номер 101, имеющего имя «Производство». Необходимо пояснить некоторые компоненты окна и способы работы с ними.

Номер узла присваивается конструктором при его создании. Обычно первые 100 номеров зарезервированы для узлов send - бух­галтерских счетов. Нумерация создаваемых узлов осуществляется последовательно, с номера 101. Смена номера узла возможна с по­мощью соседнего с номером диалогового поля, но не рекомендуется

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

Поле «Имя» содержит имя узла, отображаемое на схеме и при выполнении модели. Поле доступно для редактирования. Не реко­мендуется использовать имена, не умещающиеся в поле редактиро­вания.

Класс узла может быть выбран из списка. В списке приводятся только те типы узлов, которые имеют одинаковое обозначение. На­пример, узел типа send можно сменить на attach (но при этом изме­няется набор и смысл параметров). Поэтому функция смены типа полезна и имеет смысл только при создании нового узла;

I Поле «Плоскость» показывает, к какой плоскости принадлежит

«ел, и доступно только для просмотра.

* Модель получает дополнительную гибкость за счет использова­ния вставок C++ кода. Панель «Общий C++ текст» позволяет поль­зователю включить в процедуру обработки узла произвольный текст на языке C++. Текст делится на две части: одна выполняется до вы­зова функции узла, другая - после нее. Смысл такого разбиения за­ключается в том, что программный текст, выполняющийся до вызо­ва функции узла, может подготавливать какие-либо переменные, которые функцией будут использованы. Так, например, может быть Ьодсчитано время обслуживания транзакта перед выполнением функции узла типа serv. Программный текст, следующий после вы­зова функции узла, на ее выполнение уже никак не влияет и может ^пользоваться для обработки параметров выполненной функции ^яли подготовки параметров для других функций модели.

Узел может содержать несколько исходящих ссылок, по кото­рым способен переместиться транзакт. Выбор маршрута должен Осуществляться по условиям. Поэтому в правой нижней части окна шределейия параметров транзакта имеются поля, определяющие эти условия а также выполнение соответствующих им индивидуальных фрагментов программного кода. Выбор исходящей ссылки осущест­вляется щелчком мыши в диалоговом поле «Выходы». Как видно из рис 5 5, любой вход и выход можно удалить, нажав кнопку внизу

■списка.

! И наконец, необходимым компонентом представленного окна ^является кнопка «Определить параметры», нажатие на которую вы­зывает окно определения параметров самой функции обработки уз-!ла. Вид появляющегося диалогового окна зависит от типа узла. {Пример окна для узла типа serv приведен на рис. 5.6. I Итак, рассмотрена схема определения параметров узла типа serv. Аналогичным образом определяются параметры для узлов любого \ типа, но окно определения параметров функции узла (рис. 5.6) имеет * различный вид. Например, для узла типа queue окно содержит на­стройку единственного параметра - признака приоритета прохожде­ния транзактов, а для узлов типа term параметров функции узла и исходящих ссылок не существует вовсе.

Определение параметров инициализации/завершения моде­ли Модель имеет параметры инициализации и завершения, зада-; ваемые функциями modbeg и modend. Определение этих параметров " производится через диалоговые окна, вызываемые нажатием кнопок

«Modbeg» и «Modend»в основном окне редактора либо выбором подпунктов основного меню в разделе «Модель»

Окно определения параметров функции modbeg приведено на рис. 5.7. В его правой верхней части записывается какой-либо на­чальный текст на C++, если он необходим. Программный текст де­лится на две части: начальный C++ текст используется для подклю­чения внешних библиотек и настройки глобальных параметров; текст инициализации ресурсов подготавливает параметры конкрет­ных узлов типов attach и send. Другие поля окна позволяют редакти­ровать переменные, стандартные для функции modbeg.

Редактирование переменных функции modend осуществляется через диалоговое окно, приведенное на рис. 5.8.

Работа в плоскостях модели. При работе с большой моделью удобно пользоваться набором плоскостей построения. Для этого конструктор предлагает набор плоскостей с номерами 1 - 9, фраг­менты графов которых не пересекаются на уровне маршрутов тран-зактов. В каждой из плоскостей могут находиться узлы типа parent, pay, rent, или down, в свою очередь порождающие новые плоскости. Порождаемые плоскости имеют номера, начинающиеся с 10.

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

окно построения.

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

Для перехода на плоскость, детализирующую у