Имитационное моделирование экономических процессов

Ш а г V. Генерация текста имитационной модели в операторах Pilgrim.

Итак, модель готова. Для нее сформирован граф, заданы пере­ менные, определены параметры узлов и функций. Для генера1щи программного файла необходимо в основном меню выбрать «Вы­ полнить», а затем - «Генерировать C++ файл». При этом конструк­ тором сначала будет вьшолнена проверка модели, в нашем случае не обнаружившая никаких ошибок или подозрительных участков на графе модели (рис. 5.24). После нажатия кнопки ОК будет выведено стандартное диалоговое окно, предлагающее сохранить файл с рас­ ширением «срр». Сохраненный конструктором файл можно далее компилировать в среде Visual C++.

Iripobeptid корректное!и

гВозможные ошибки;'

•"ок	'
f-; I iTf 1 ifr-r- 11 -1 -п	inr-T-T--im[-

Рис. 5.24. Окно проверки корректности модели

Программная модель, автоматически сгенерированная конструк­ тором и помещенная в срр-файл, имеет следующий вид:

#include	<Pilgrim.h>
forvrard
{
i n t	fw;

i n t proc_time;

191

modbeg("Производство под заказ", 107, 365,

(long) time (NULL) , none, 107, none,none, 2); ад("3аказы A", 105, 1, norm, 30, 10, none, 107); ад("3аказы B", 106, 2, norm, 5, 2, none, 107); network(dummy, dummy)

{

top(102):

if( t->pr == 1 )

{

proc_time =10 fw=103;

}

else

{

proc_time = 2 fw=104;

}

serv("Производство", 1, abs, norm, proc_time, proc_time/2, none, fw) ;

place;

top(103):

term("Отчет A"); v place;

top(104): term("Отчет В"); place;

top(107):

queue("Очередь заказов", prty, 102); place;

fault(123);

}

modend("pilgrim.rep", 1, 8, page); return 0;

}

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

192

5.5 РАЗВИТИЕ ПРОБЛЕМНООРИЕНТИРОВАННОГО ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА С МОДЕЛЯМИ

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

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

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

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

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

4.Расширяется круг разработчиков. В настоящее время (в отли­ чие от 1970-х - 1980-х гг., когда большинство разработчиков ПО являлись профессиональными программистами) все больший круг программных продуктов разрабатывается людьми, имеющими опьгг

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

5.Расширяется круг пользователей. Грань между пользователя­ ми и разработчиками оказьшается все более размытой. Практически

193

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

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

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

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

С появлением Windows 95/98/NT для Pilgrim бьши разработаны многочисленные модули, обеспечивающие графическое отображе­ ние результатов в окне Windows. Имеются возможности настройки окна отображения результатов в удобной для пользователя форме. Однако разработка самой модели оставалась задачей программиста. Новой задачей модификации Pilgrim стала разработка графического конструктора, позволяющего задавать модели в виде графа, отвлечь­ ся от кодирования и использовать иерархию процессов.

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

194

Следует также отметить, что первые версии пакета Pilgrim отли­ чались способностью переноса на различные платформы, единст­ венным требованием к которым было наличие компилятора C++. Библиотеку пакета можно было одинаково эффективно использовать и в среде Unix, и в среде MS DOS. Созданная для Unix модель могла успешно компилироваться и в MS DOS, а ориентированный на кон­ кретную платформу интерфейс только интерпретировал результаты выполнения.

При разработке интерфейса, естественно, возникает вопрос вы­ бора операционной системы. Первый интерфейс Pilgrim в виде гра­ фического окна был реализован при использовании MS DOS; многие графические функции появились с переходом к Windows 95. Однако основная вычислительная библиотека языка Pilgrim практически не изменяется. Она наращивается по количеству новых расчетных про грамм, постепенно повышается точность в связи с переводом про­ грамм на более длинную разрядную сетку. Создание конструктора и оснащение его функциями, приведенными ниже, должны отразиться не только на библиотеке Pilgrim, но и на функциях, используемых в моделях. Дальнейшая эволюция Pilgrim должна привести к более тесной интеграции интерфейса системы и библиотеки, содержащей описание моделируемых функций.

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

1) отображение процесса имитации на графе модели в реальном времени;

2)расширение графических средств отображения процесса ими­ тации;

3)установление на графе модели контрольных точек, при попа­ дании транзакта в которые возможно наступление различных собы­ тий, таких, как вывод диалогового окна или приостановка выполне­ ния имитации;

4)предоставление интерфейса ввода начальных параметров;

5)хранение моделей в виде проектов, содержащих в качестве компонентов граф модели, описание интерфейса и дополнительных функций.

Многие сервисные функции уже есть в различных версиях сис­ темы. Рассмотрим их подробнее.

Конструктор работает с графом модели, описание которого хра­ нится в собственном внутреннем формате. Граф можно сохранять,

195

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

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

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

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

Реализация дополнительных функций неизбежно приведет к из­ менению в составе и структуре конструктора (рис. 5.25). Основой для новых функ1щй является механизм обмена данными между вы­ полняющейся моделью и конструктором.

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

19в

		Графы
		model.pgf
CASE-конструктор системы Pilgrim
Обработка	Блок	Блок	Блок
входных	приема	«рисования»	генерации
данных	данных
		Текст
		model.cpp
	ППП	Компилятор	Библиотека
	системы	C + +	интерфейсов
	Pilgrim		Pilgrim
		I	Интерфейс
		Профэмма
		model.exe	входных
			параметров

Рис. 5.25. Технологическая схема взаимодействия компонентов системы имитационного моделирования

Перспективный состав функций блока обработки может быть очень широк. Например, он мог бы включать в себя функции управ­ ления модель10 через WEB или через рассылку электронных писем. Очевидно, такой блок должен и^еть иерархическую структуру, на нижнем уровне которой будут располагаться способы представления и обработки информации. Набор способов можно последовательно обновлять.

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

197

действия, осуществляемого моделью, при соблюдении некоторого условия контрольной точки.

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

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

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

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

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

Вы в о д ы

1.САЗЕ-конструктор имитационных моделей позволяет прово­ дить разработку многоуровневой Pilgrim-модели практически без применения языка Pilgrim.

198

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

3.Видимое увеличение слоев модели - это следствие борьбы с ошибками (дефектами) имитационной модели. Умелое добавление нового слоя в модель приводит к уменьшению суммарного числа узлов на всех уровнях иерархической структуры.

Вопросы для самопроверки

1.Для чего нужен конструктор имитационных моделей?

2.Какие достоинства CASE-технологий учитъшаются при автома­ тизированном создании имитационных моделей?

3.Из каких компонентов состоит имитационная модель «с точки зрения» конструктора Pilgrim?

4.В чем состоит основное достоинство конструктора Pilgrim?

5.Какие файлы должны бьпъ на входе и создаются на выходе кон­ структора?

6.Какие инструментальные приемы существуют для редактирова­ ния графа модели?

7.Как определяются и переопределяются параметры узла модели?

8.Каким образом можно определить параметры инициализации и завершения модели?

9.Возможно ли вьшолнять одновременно работу в разных плоско­ стях модели при ее проектировании?

10.Какие могут быть переменные в модели? Как они определяются? И. Для чего нужны дополнительные (специальные) функции конст­

руктора Pilgrim?

12.Какие возможности имеются для изменения настроек экрана конструктора?

13.Насколько подробно вьшолняется проверка корректности моде­ ли?

14.Какие особые приемы (средства) имеются для работы с планом бухгалтерских счетов?

15.Имеются ли средства однозначного поиска узла в сложной мно­ гослойной модели?

16.Какова технология копирования или вставки узла в модели?

17.Можно ли полностью очистить плоскость - слой модели?

199

18.Какие основные технологические шаги для создания модели не­ обходимо выполнить с помощью конструктора Pilgrim?

19.Почему появляется многослойная конструкция модели и что она дает разработчику?

20.Что может привести к уменьшению суммарного числа узлов на всех уровнях иерархической структуры модели?

21.Почему узел parent виртуален? Как проводится детализация с его помощью?

22.Можно ли использовать узел типа pay в качестве средства реали­ зации подпрограмм?

23.Какие основные технологические окна имеет конструктор Pilgrim?

24.В чем польза контрольных точек?

25.Какова технология генерации текста имитационной модели в операторах Pilgrim с помощью графического конструктора?