Имитационное моделирование экономических процессов
.pdf4.Какая переменная содержит номер узла?
5.Какие параметры узла доступны разработчику модели для ана лиза?
6.Для чего используется глобальная переменная errorl
7.Как непосредственно обратиться к датчикам псевдослучайных чисел?
8.Какие виды выходной информации используются для отладки моделей?
9.Что входит в итоговую таблицу результатов моделирования?
10.Какие существуют режимы трассировки, позволяющие ускорить процесс отладки?
11.Как осуществляется случайный выбор из класса узлов?
12.Как задать схему выбора дальнейшего пути продвижения транзакта в зависимости от значения некоторого его параметра?
13.Какие модели относятся к замкнутым корпоративным информа ционным системам (КИС) ?
14.Как производится зарядка одного многоканального сервера?
15.Каким образом осуществляется зарядка нескольких одноканальных серверов?
16.Как вьшолняется зарядка нескольких многоканальных серверов?
17.Как определить время ответа на запрос в КИС?
18.В какой среде обьино создается имитационная модель?
19.Как создать типовой проект модели?
20.Из каких файлов состоит типовой проект модели?
21.Как вьтолнить проект модели с диалоговым окном для управле ния параметрами? Из каких файлов состоит такой проект? Какие файлы необходимо откорректировать при создании данного про екта?
22.Как создать проект модели с функциональным окном для конеч ного пользователя?
23.Что входит в блок управления функциональным окном?
СОЗДАНИЕ МНОГОСЛОЙНЫХ МОДЕЛЕЙ
С ПОМОЩЬЮ ГРАФИЧЕСКОГО КОНСТРУКТОРА
5.1 CASE-ТЕХНОЛОГИЯ МНОГОСЛОЙНОГО ИМИТАЦИОННОГО МОДЕЛИРОВАНИЯ
В последние годы все большее распространение получают CASE-средства, позволяющие автоматизировать процессы проекти рования, разработки и поддержки программных приложений:
•компьютерных экономико-математических моделей;
•экономических информационных систем;
•вычислительных программ прикладной математики экономи ческого назначения.
САЗЕ-средствй активно используют методологию структурного анализа, предусматривающую наглядное и эффективное проектиро вание системы путем вьщеления ее составляющих и их последова тельного рассмотрения. Описание системы начинается с общего об зора и выделения основных ее компонентов или процессов. Для ви зуального представления создается первый уровень или слой, на ко тором отображаются выделенные процессы и их взаимосвязи. Далее для ряда процессов может быть проведена детализация, в свою оче редь вьщеляющая новые процессы в их структуре. Так, последова тельным усложнением описания объекта и его процессов разработ чик достигает необходимой детализации. Глубина детализации оп ределяется как необходимой точностью, так и набором исходных данных. В процессе структурного анализа выявляется иерархическая структура модели.
Рассмотренный ниже декомпозиционный подход реализуется в программных CASE-пакетах в различных вариациях, поскольку су-
162
ществует достаточно широкий круг задач, для которых схожие ме тоды могут быть применены. Однако все CASE-пакеты предостав ляют пользователю инструментарий работы с проектом, опираю щийся на мощные современные графические средства отображения информации в виде графов, диаграмм, схем и таблиц.
Одним из достаточно интересных и полезных применений CASE-средств является не только их интеграция в процессы проек тирования, разработки и поддержки структуры программного прое^с- та, но и автоматизация процесса создания или генерации програм много кода. Использование CASE-средств, дополненных такой воз можностью, имеет ряд несомненных преимуществ перед простым кодированием, поскольку позволяет:
•отвлечься от кодирования данных и обратить больщее внима ние на структуру разрабатываемой системы;
•избежать некоторых ошибок за счет автоматического кон троля;
•ускорить процесс проектирования и разработки проекта. Теперь рассмотрим CASE-технологии применительно к системе
имитационного моделирования. Для создания имитационной модели в отсутствие CASE-средств разработчику приходится писать про граммный код, использующий языковые средства системы модели рования Pilgrim. Модель имеет стандартную стр)тстуру. Внутри тек ста модели содержатся обращения к функциям Pilgrim, но может быть и произвольный C++ код.
Учитывая, что текст модели обрабатывается препроцессором и стандартным компилятором C++ (Microsoft, Borland и др.), можно выделить ряд проблем, возникающих перед пользователем при опи сании модели в операторах Pilgrim, а именно:
•необходимо знать элементы языка C++;
•нужно иметь отчетливое представление о структуре програм мы, опирающейся на библиотеку Pilgrim;
•требуется знать функции описания узлов и их п^аметров;
•имеется вероятность появления ошибки в порядке перечисле ния позиционных параметров, причем ошибка может бьггь не заме чена компилятором C++, в результате чего модель будет выполнять ся, но иметь на выходе неправильные результаты. Обнаружение та кой ошибки тем сложнее, чем большее количество узлов имеет мо дель;
1вЗ
• сложность описания больших моделей. Поскольку модель лю бого размера выглядит как простое линейное перечисление узлов и условий переходов между ними, то, чем больше текст модели, тем он сложнее воспринимается пользователем.
Конструктор моделей Pilgrim (далее - конструктор) позволяет автоматизировать процесс создания графа модели и автоматически генерировать код Pilgrim-программы. Тем самым снимаются отме ченные вьпие проблемы, возникающие при ручном кодировании мо дели в виде Pilgrim-файла:
•автоматическая генерация программного кода позволяет поль зователю не задумьшаться о структуре и синтаксисе программы, уделяя все внимание структуре и параметрам самой модели и ее узлов;
•генерация функций описания узлов конструктором исключает ошибки, связанные с неправильной последовательностью указания позиционных параметров или пропуском некоторых из них;
•анализируя модель, конструктор не позволяет пользователю вьшолнять заведомо неверные действия, а также предупреждает о возможных ошибках;
•поддержка конструктором множества плоскостей обеспечивает создание иерархических моделей, что может быть очень удобно при выполнении моделей с большим количеством узлов. Действительно, не только восприятие, но и отображение больших моделей в виде плоского одноуровневого графа на бумаге или экране монитора дос таточно затруднено.
5.2 ОСОБЕННОСТИ РЕАЛИЗАЦИИ КОНСТРУКТОРА МОДЕЛЕЙ GEM
Конструктор создан для работы под управлением Windows 95/98/NT и использует удобные диалоговые средства, предоставлен ные графическим интерфейсом этих операционных систем.
Модель с точки зрения конструктора Pilgrim можно представить как набор следующих компонентов:
•граф модели;
•параметры инициализации модели;
•переменные модели;
164
• включенные в модель фрагменты программного кода на языке C++.
Кратко рассмотрим каждый из перечисленных компонентов. Вершины графа модели представляют собой узлы - пункты об
работки транзактов. Для всех типов узлов имеются условные обо значения, упрощенные по сравнению с графическими изображения ми {см. рис. 2.3). Перечень таких обозначений приведен на рис. 5.1.
|
О О А |
1:serv |
||
queue |
eg |
— creat |
key |
|
send |
I—term |
- delet |
— manager |
|
_ attach |
|
|
direct |
|
pay |
parent |
—rent |
|
down |
|
Рис. 5.1. Условные обозначения узлов Pilgrim при работе с графическим конструктором
Внутри любого узла (кроме виртуального узла parent) происхо дит обработка транзакта, определяемая спецификой его типа. Дуги графа представляют собой пути миграции транзактов по графу мо дели и имеют направленность. Возможны ситуации, когда один узел имеет несколько выходов, тогда путь транзакта определяется усло виями, заданными в узле-источнике.
Каждый узел модели имеет собственные параметры, как общие для всех типов узлов (имя, номер, условия ссылок), так и специфи ческие, определяемые типом узла. Такие специфические параметры также можно назвать параметрами функции уъпй.
Параметры инициализации модели - это набор переменных, включенных в функции инициализации модели modbeg и заверше ния модели modend.
165
Конструктор также позволяет определять переменные модели - глобальные переменные, инициализируемые в начале текста программь!. Доступ к ним возможен из любого узла в любой момент вьшолнения программы.
Иногда пользователю необходимо включение в программу соб ственных программных вставок. Поэтому конструктор позволяет пользователю вводить произвольный С-и- код. Программный текст может размещаться в начале программы, вьшолняя подготовку ка ких-либо данных, и внутри любого из узлов.
Важнейшим моментом создания модели является построение графа, описьшающего зависимости между процессами моделируе мой системы. Для того чтобы изначально не зайти в тупик, пытаясь построить некорректный, трудно воспринимаемый или неудобный для дальнейшей работы граф, необходимо четко представлять мето ды, средства и ограничения конструктора по построению графа.
Основное достоинство конструктора Pilgrim заключается в том, что он позволяет:
•проводить многоуровневую (т.е. многослойную) иерархиче скую декомпозицию глобального процесса, разлагая его на состав ляющие компоненты (проводить структурный системный анализ);
•представлять каждый уровень структурной детализации в виде графического слоя;
•автоматически генерировать программный текст модели.
С помощью конструктора удобно строить многоуровневые, мо дели, организуя иерархию плоскостей построения модели.
Конструктор позволяет создавать множество плоскостей, на ко торых расположены слои модели с любьпи количеством узлов и ссы лок. Иерархические модели устроены следующим образом: верхний уровень модели содержит ряд узлов, среди которых есть такие, ко торые детализируются на нижних уровнях. При этом, создавая дета лизирующий уровень, пользователь опять может поместить на нем узлы, которые могут быть детализированы еще ниже; так граф моде ли примет иерархическую структуру. Число уровней вложенности не ограничено конструктором, т.е. пользователь может сколько угодно подробно детализировать и обобщать процессы модели.
При создании новой модели пользователь начинает работу с корневого уровня, и поэтому некоторые процессы модели могут быть представлены здесь в общем виде, с целью дальнейшей детали зации. Для выполнения структурной декомпозиции к набору узлов, определяемому системой Pilgrim, конструктор добавляет новьШ осо-
16в
бый тип - parent, использующийся исключительно как средство соз дания наглядных многоуровневьк моделей. Узел типа parent содер жит ссылку на плоскость, его детализирующую, т.е. используется для описания процессов, которые можно рассмотреть на отдельной плоскости. Узел parent не вьшолняет никаких действий по обработке транзакта и при генерации программного кода просто заменяется своей декомпозицией, т.е. порождаемым им слоем. Например, если пользователь создал узел типа parent с номером 4, то в программном файле узел с таким номером сгенерирован не будет. С точки зрения генератора программного файла узел parent представляет собой про стой маршрутизатор, который может иметь любое количество вхо дов, ссылку на детализирующий уровень и единственный выход.
Рассмотрим пример на рис. 5.2, где в плоскости 1 имеется после довательность узлов Клапан_1-^Действие_1->0чередь_1.
Узел Действие_1 является узлом типа parent и содержит детали зирующую плоскость 11. Плоскость И содержит цепочку Оче- редь_2->Сервер_2.
KnaiuK 1 |
Очврвда_1 |
-О О- |
Q |
|
3 |
Плоскость 1. Корень
Очервд»_2 |
Cepiep 2 |
|
Q |
* |
*" |
|
S |
|
4 |
|
5 |
|
|
|
ПщкостьИ. родитепь: Действие 1
Рис. 5.2, Детализация узла типа parent
В плоскости 11 стрелка, направленная из левого, верхнего угла экрана в узел Очередь_2, обозначает, что этот узел является входом на плоскость, а стрелка из узла Сервер_2 в правый верхний угол - что это выход с плоскости. При запуске генерации программного
167
файла получим следующую цепочку: Клапан_1->0чередь_2-> Сер- вер_2->0чередь_1, т. е. узел Действие_1 является лишь средством реализации многоуровневости и будет обработан генератором как узел Pilgrim.
Иногда при построении модели может возникнуть необходимость вьщеления некоторых типовых действий по обработке данных. Это могут быть запросы на вьшолнение бухгалтерской проводки, требова ния вьщеления моделируемого ресурса или какие-либо другие дейст вия. При возникновении такой задачи удобно обозначить подпрофаммы, обращение к которым было бы возможно из любого места модели. Для этого используются узлы типа pay, rent, down. Такие уз лы, так же как и parent, содержат переход на более низкий уровень модели, однако имеют несколько иной механизм действия и область применения. Если с помощью узла типа parent можно создавать ие рархические модели, имеющие на любой сколько угодно глубоко вложенной плоскости новые узлы parent, то с помощью узлов типа pay, rent, down возможно лишь реализовать подпрограммы на двух слоях модели и невозможно построить общую иерархию уровней.
Рассмотрим принцип работы таких узлов на примере узла pay (рис. 5.3). На плоскости 1 находится узел типа pay, содержащий об ращение к подпрограмме, расположенной в плоскости 12. Входом плоскости 12 является узел с названием «Расчетный счет фирмы», а выходом - узел с именем «Бухгалтерия». При генерации програм много файла а узле «Бухгалтерия» в качестве параметра, опреде ляющего номер следующего узла, на который переходит транзакт, будет указано не конкретное значение, а специальный параметр транзакта updown. При этом предполагается, что каждый транзакт, попадающий в выходной узел плоскости, содержит в параметре updown номер узла, на который следует выполнить переход. Пара метр транзакта updown инициализируется в узле типа pay, т.е. в на шем случае в узле с названием «Плата поставщику».
Аналогичным образом реализуется переход на подпрограмму с использованием узлов типа rent и down. Они также инициализируют переменную транзакта updown. Из вышеизложенного можно сделать вывод о невозможности использовать узлы типа pay, renf и down для реализации иерархических моделей по следующей причине: на уровне подпрограммы узла одного из перечисленных типов нельзя размещать никакой из узлов типа pay, rent, down, так как каждый из этих узлов заново вьшолнит инициализацию параметра транзакта updown, т.е. заменит значение updown, установленное уровнем вы-
168
ше, организуя циклическую ссылку (это приведет к семантической ошибке).
Чтобы защитить пользователя от совершения таких ошибок, конструктор не позволяет создавать в текущей плоскости узлы типа pay, rent, down, если управление передано с более высокого уровня через узел перечисленного типа. Однако узлы обращения к подпро грамме имеют одно важное преимущество перед узлом parent. Оно состоит в том, что транзакт сам «помнит», куда ему необходимо вернуться; поэтому из нескольких узлов (или слоев) можно обра щаться к общей плоскости, содержащей детальное вьшолнение ти пового действия.
Обратимся еще раз к примеру, приведенному на рис. 5.3. Пред положим, что имеется некоторая организация, имеющая собствен ный расчетный счет и выполняющая ряд операций по перечислению средств; часть операций необходимо смоделировать. В плоскости 12 создана подпрограмма «Плата поставщику», выполняющая бухгал терскую проводку по перечислению средств со счета фирмы. Если возникает необходимость смоделировать аналогичную ситуацию с перечислением средств (например, возврат кредита), то можно соз дать новый узел типа pay и указать ему в качестве подпрограммы плоскость 12.
Плата постмтюу
РАУ U
Ппоскость 1 .Кореньуг\
Р/счат фирмы |
Бухташерия |
22
Плоскость 12. родителе: Плата поставщику
Рис. 5.3. Пример использования узла типа pay в качестве средства реализации подпрограмм
169
в процессе работы с конструктором, при создации нового узла обращения к подпрограмме, появляется диалоговое окно с просьбой указать номер плоскости, на которой должна размещаться подпро грамма. По умолчанию это номер новой пустой плоскости, однако пользователь самостоятельно может задать номер уже существую щей плоскости.
Иногда в модели можно вьщелить ряд процессов, независимых на уровне транзактов, но пересекающихся на уровне моделируемых ресурсов. Например, это может быть моделирование процесса про изводства с участием нескольких независимых торговых компаний, приобретающих товар у производителя и имеющих свой финансо вый резерв и рынок ciSbrra. Тогда можно выделить как независимые процессы торговых компаний и процесс функционирования произ водителя. Для разработчика модели было бы неудобно восприни мать в одной корневой плоскости несколько параллельных процес сов, поэтому конструктор предоставляет возможность содержать несколько корневых плоскостей с целью размещения в них непере секающихся на уровне транзактов процессов.
5.3 РАБОТА С ГРАФИЧЕСКИМ KOHCTPYiaOPOM В СИСТЕМЕ PILGRIM
Конструктор моделей состоит из программного файла. gem.exe, файлов настроек с расширением ini, файла помощи и примеров ими тационных моделей. При запуске gem.exe на выполнение перед пользователем появляется основное окно, содержащее меню, панель «горячих кнопок», панель инструментов, информационную строку (рис. 5.4). Область построения графа модели пуста, для редактиро вания необходимо создать новую модель либо загрузить ранее со храненную. Рассмотрим сначала выполняемые конструктором опе рации с файлами.
Всю информацию о модели конструктор сохраняет в файле с расширением «pgf» (Pilgrim graph file). При создании законченной версии имитационной модели пользователь может генерировать программный файл Pilgrim с расширением «срр» (с plus plus). Этот файл далее компилируется в среде Visual C++ с подключением не обходимых библиотек и ресурсов Pilgrim. Создаваемый конструкто ром программный файл с расширением «срр» при своей генерации
170