ЗНАЕТЕ ЛИ ВЫ?

ОРЕТИЧЕСКИЕ ОСНОВЫ 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.


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

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

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





Последнее изменение этой страницы: 2016-06-06; Нарушение авторского права страницы

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.232.96.22 (0.021 с.)