microbik.ru
1 2 3 4
Министерство общего образования

Российской Федерации

Министерство атомной промышленности

Российской Федерации

МОСКОВСКИЙ ИНЖЕНЕРНО-ФИЗИЧЕСКИЙ ИНСТИТУТ

(ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ)

Кафедра экономической динамики

С.П. БЫЧКОВ, А.А. ХРАМОВ

MEТОДИЧЕСКИЕ УКАЗАНИЯ ДЛЯ ВЫПОЛНЕНИЯ ЛАБОРАТОРНЫХ РАБОТ

ПО КУРСУ

«МОДЕЛИРОВАНИЕ МАКРОЭКОНОМИЧЕСКИХ ПРОЦЕССОВ И СИСТЕМ»

(для групп У6-571, У6-572, У6-582, У6-584)

Москва, 2003

Содержание

ВВЕДЕНИЕ

1.1 Методика разработки объектно-ориентированных имитационных моделей.

1.2. Общая структура программы моделирования на языке simula…………..

1.3. Организация имитационных экспериментов………………………………..

2.Лабораторная работа № 1.

«Разработка имитационной модели системы управления запасами»…………………

3. Лабораторная работа № 2.

«Исследование имитационной модели системы управления запасами»……………..

4. Лабораторная работа № 3.

«Разработка объектно-ориентированной имитационной модели супермаркета»……

5. Лабораторная работа № 4.

«Исследование различных вариантов организации работы супермаркета

на его имитационной модели»……………………………………………………………..

ЛИТЕРАТУРА………………………………………………………………………..

ВВЕДЕНИЕ
Целью данного лабораторного практикума является приобретение студентами практических навыков разработки и исследования имитационных моделей экономических систем. В качестве методологической основы построения моделей используется объектно-ориентированный подход к анализу систем и разработке их моделей.

Предлагаемые лабораторные работы могут выполняться студентами как в компьютерном классе под руководством преподавателя, так и самостоятельно на домашнем компьютере. В последнем случае нужно выполнить установку необходимого программного обеспечения с дистрибутивной дискеты в соответствии с инструкцией, содержащейся в файле read.me на этой дискете.
*** может быть описать правила установки системы дома в приложении
Во введении дается краткое изложение (в основном, на примерах) методики разработки имитационных моделей с использованием объектно-ориентированного подхода (раздел 1.1), рассматривается общая структура программы моделирования на языке simula (раздел 1.2) и некоторые способы организации имитационных экспериментов с моделями (раздел 1.3).
1.1 Методика разработки объектно-ориентированных имитационных моделей
Объектно-ориентированный подход к построению имитационных моделей состоит в представлении моделируемой системы в виде совокупности взаимодействующих объектов, которые в дальнейшем будем называть процессами, и в описании сценариев поведения процессов с их локальной точки зрения. Рассмотрим методику построения объектно-ориентированных имитационных моделей на примере разработки простейшей модели магазина самообслуживания.

Пусть требуется смоделировать работу магазина самообслуживания с одной кассой, нагруженной потоком покупателей, входящих в магазин через случайные промежутки времени, равномерно распределенные в интервале от 3 до 7 мин. Время, затрачиваемое покупателем на покупки, и количество покупок будем также считать случайными величинами, распределенными равномерно в интервалах [10,20] и [4,12] соответственно. Положим, что кассир тратит 30 с на расчет за одну покупку и необходимо смоделировать работу магазина в течение 8 часов. Будем считать, что целью моделирования является определение следующих характеристик работы магазина:

  • общего количества обслуженных покупателей;

  • среднего времени пребывания покупателя в очереди к кассе;

  • загрузки кассира (доли времени, в течение которого кассир непосредственно занят проведением расчета с покупателями).

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

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

  1. Покупатели;

  2. Касса (кассир);

  3. Очередь покупателей к кассе;

  4. Генератор покупателей, т. е. объект, имитирующий поток входящих в магазин покупателей (клиентов магазина), путем создания через определенные интервалы времени объектов, отображающих покупателей.

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

Рассмотрим атрибуты и сценарии поведения выделенных нами объектов в модели магазина.

  1. Объект «покупатель».

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

  • время, затрачиваемое им на совершение покупок (Тр);

  • количество покупок (Кр);

  • момент входа в очередь к кассе (Tinq);

  • момент окончания оплаты покупок (Toutq).

Сценарий поведения покупателя состоит в последовательном выполнении следующих действий:

  • совершение покупок в течение Тр единиц времени;

  • встать в очередь к кассе для оплаты покупок, отметив при этом время входа в очередь и оповестив кассира о своем подходе к кассе;

  • ожидание в очереди до момента окончания оплаты покупок;

  • по окончании оплаты

отметить время выхода из очереди

увеличить общее время ожидания всех покупателей на время своего пребывания в очереди от входа в нее до окончания оплаты покупок

увеличить на единицу общее количество обслуженных покупателей.


  1. Объект «Касса (кассир)».

Атрибутами кассира можно считать следующие данные:

  • время, затрачиваемое на обработку одной покупки (Cp);

  • момент времени начала простоя из-за отсутствия покупателей (Tbegw);

  • суммарное время простоя из-за отсутствия покупателей (Tw);

  • ссылку на обслуживаемого в данный момент покупателя (Cl).


*** С1(один) и Сl (эль) будут путать
Сценарий работы кассира состоит в циклическом выполнении следующих действий:

  • если в очереди есть хотя бы один покупатель, то на отображающий его объект устанавливается ссылка Cl и выполняются действия по его обслуживанию:

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

удаление обслуженного покупателя из очереди

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

  • по окончании обслуживания всех находившихся в очереди покупателей кассир переходит в пассивное состояние («засыпает») до тех пор, пока в очереди не появится очередной покупатель

  • при этом перед «засыпанием» кассир отмечает время начала «сна», а после «пробуждения» с приходом покупателя отмечает момент окончания «сна» и

  • увеличивает суммарное время простоя из-за отсутствия покупателей на продолжительность «сна»

  • после «пробуждения» кассир возобновляет обслуживание покупателей, переходя к первому пункту своего сценария поведения.

Указанные действия кассир выполняет в течение всего рабочего дня.

  1. Объект «очередь покупателей к кассе».

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

4. Объект «поток покупателей (генератор покупателей)»,

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

Сценарий работы генератора покупателей состоит в циклическом выполнении следующих действий:

  • установка начальных значений переменных, используемых в датчиках случайных чисел;

  • создание объекта, отображающего очередного покупателя, входящего в магазин, и его активизация;

  • задержка действий генератора на интервал времени между появлениями покупателей;

  • переход ко второму пункту сценария, что обеспечивает постоянную работу генератора по созданию покупателей;

После определения атрибутов объектов, составляющих моделируемую систему, и описания сценариев их поведения можно приступать к отображению этих объектов средствами некоторой инструментальной системы программирования, ориентированной на разработку имитационных моделей. Выбор конкретной системы моделирования определяется выбранным разработчиком модели (или ее заказчиком) подходом к представлению работы моделируемой системы и, далеко не в последнюю очередь, целым рядом организационных и экономических факторов. Вопросам выбора и сравнительного анализа инструментов моделирования уделяется достаточное внимание в литературе по имитационному моделированию ( см., например, [3, 5, 6] и др.), в связи с чем в данной работе эти вопросы обсуждаться не будут.

В данном лабораторном практикуме мы будем использовать в качестве инструмента для программирования имитационных моделей язык simula [1,2], в котором были впервые и в наиболее общем виде реализованы все основные идеи и средства объектно-ориентированного программирования и средства имитационного моделирования, ориентированные на отображение взаимодействующих процессов.

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

Для отображения объектов, составляющих моделируемую систему, в программе моделирования на языке simula необходимо описать их структуру атрибутов (имена и типы) и сценарии поведения в виде деклараций классов, а затем использовать эти декларации для создания нужного количества объектов каждого класса со своими конкретными значениями атрибутов. Отметим, что количество объектов в simula-программах ограничено лишь размером доступной программе оперативной памяти и это количество объектов, как и их взаимосвязи (взаимные ссылки), могут изменяться в ходе работы программы, что позволяет легко отображать динамические системы с переменным составом и переменной структурой.
В примере 1 представлены декларации классов CLIENT и KASSA, отображающие атрибуты и правила поведения покупателей и кассира в магазине самообслуживания, неформально описанные в начале данного раздела. Эти неформальные описания приведены в текстах примера в виде комментариев, обрамляемых в языке simula символами ! и ; или end и ; . Перед декларациями классов размещены описания ссылочных переменных (кратко – ссылок) QC и КАССА, используемых для обозначения очереди покупателей и кассы соответственно.

Пример 1.

ref (HEAD) QC; ref (KASSA) КАССА;

PROCESS class CLIENT (Tр, Кр);

real Тр; integer Кр;

!Тр - время, затрачиваемое на совершение покупок ;

!Кр - количество покупок ;

begin  real Тinq, Тoutq;

! Tinq - момент входа в очередь к кассе ;

! Toutq - момент окончания оплаты покупок ;

HOLD (Тр); !Совершение покупок в течение Тр единиц времени.;

INTO (QC); !Покупатель встал в очередь и, ;

Tinq:=TIME; ! отметив время входа в очередь;

activate КАССА delay 0; ! и "толкнув" кассира, ;

PASSIVATE; ! перешел в пассивное состояние, ;

END_ WATING: Тoutq:=TIME; ! Покупатель отметил время выхода из очереди ;

WTT:=WTT + Toutq-Tinq; !и увеличил общее время ожидания всех покупателей на время своего пребывания в очереди от входа в нее до окончания оплаты покупок ;

end CLIENT;
PROCESS class KASSA (Ср); real Cр;

!Ср - время, затрачиваемое кассиром на оформление одной покупки;

begin real Tbegw, Tw; ref (CLIENT) Cl;

! Tbegw - момент времени начала простоя из-за отсутствия покупателей ;

! Tw - суммарное время простоя из-за отсутствия покупателей ;

! Cl - ссылка на обслуживаемого в данный момент покупателя ;
WORK: ! Кассир берет из очереди первого стоящего там покупателя и, если таковой существует, выполняет расчет за сделанные им покупки;

for Cl:-QC.FIRST while Cl =/= none do

begin

HOLD (Cl.Кp*Сp); !Кассир обслужил покупателя,;

Cl.OUT; ! удалил его из очереди;

activate Cl ! и активизировал покупателя, дав ему возможность продолжать свои действия (с метки END_WAITING в объекте CLIENT);

Ncls:=Ncls + 1; !Увеличение общего количества обслуженных покупателей;

end work;

! В очереди не осталось покупателей:;

Тbegw:=TIME; ! кассир отмечает время начала простоя («сна»);

PASSIVATE; ! кассир переходит в пассивное состояние («засыпает») до тех пор, пока в очереди не появится очередной покупатель;

ENDW:TW:=TW + (TIME-Тbegw); !После «пробуждения» от «толчка» пришедшего покупателя кассир увеличивает суммарное время простоя из-за отсутствия покупателей на продолжительность окончившегося «сна» и;

goto WORK; ! переходит к обслуживанию пришедшего покупателя;

end KASSA;
В примере 1 предполагается, что процесс, отображающий кассира, имеет имя КАССА, а на набор, соответствующий очереди, ссылается переменная QC.

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

Оператор

aсtivate КАССА delay 0;

в теле декларации класса CLIENT планирует возобновление работы кассира, если в момент подхода покупателя к кассе кассир простаивал из-за отсутствия покупателей. Работа процесса KASSA начинается в этом случае с оператора с меткой ENDW. Указанный оператор aсtivate не окажет никакого воздействия на процесс КАССА, если он находится в приостановленном состоянии, т.е. выполняет оператор

HOLD (Cl.Кp*Сp), имитирующий обслуживание покупателя.

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

Пример 2.

PROCESS class GENERATOR;

begin integer U1,U2,U3; !Описание целых переменных U1, U2, U3, используемых в датчиках случайных чисел и;

U1:=1; U2;=3; U3;=5; !присваивание им начальных значений;

CREATE: activate new CLIENT(UNIFORM(10,20,U1), RANDINT (4 ,12,U2);

! Генератор создал и активизировал нового покупателя со случайными значениями атрибутов;

HOLD (UNIFORM (3,7,U3)); ! Задержка на случайное время, равномерно распределенное в интервале от 3 до 7 минут;

goto CREATE:; ! Переход на генерацию следующего покупателя;

end GENERATOR;

В декларации класса GENERATOR использованы определенные в языке SIMULA процедуры получения случайных чисел, распределенных по равномерному закону: функция UNIFORM (A,B,U) дает вещественные числа в интервале [A,B], а результатом процедуры RANDINT (M,N,U) служат целые числа, равномерно распределенные в интервале [M,N]. Фактические параметры U1, U2, U3 (целые переменные) обеспечивают взаимную независимость трех потоков псевдослучайных чисел, если их начальные значения различны и являются целыми положительными нечетными числами.

Более подробно встроенные процедуры случайного выбора рассматриваются в [1]. Для завершения построения законченной программы моделирования магазина необходимо познакомиться с общей структурой программы моделирования на языке simula, изложенной в разделе 1.2.
1.2. Общая структура программы моделирования на языке simula

В данном разделе рассматриваются вопросы общей организации программы моделирования и инициализации работы модели. Некоторые варианты проведения имитационных экспериментов с моделями рассмотрены в разделе 1.3.

Описание модели на языке SIMULA оформляется в виде блока с префиксом SIMULATION. Типичная структура программы моделирования приведена в примере 3. Описания блока SIMULATION begin ... end определяют декларации классов для процессов, которые будут функционировать в модели, задают переменные, массивы, процедуры, являющиеся общими для всех процессов. Операторы тела блока с префиксом SIMULATION обычно используются для инициализации работы модели и выдачи результатов моделирования.

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

SIMULA.
begin <описание глобальных переменных, массивов, процедур >;

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

SIMULATION begin<описания переменных, массивов, общих для всех процессов>;

PROCESS class P1 (...); . . . ;

PROCESS class P2 (...); . . . ;
PROCESS class Pm(...); . . . ;

class A1(...); . . .;

class A 2(...); . . .;

class An(...); . . .;

procedure F1(...); . . .;

procedure F2(...); .…;
procedure Fk (...); . . .;

<Операторы, задающие начальное значение общим переменным и массивам>;

<Операторы генерации процессов и объектов, отображающих исходное состояние моделируемой системы>

< Операторы, планирующие начальную активизацию процессов>

<Операторы, выполняющие задание условий окончания моделирования>;

<Вывод результатов работы модели>;

end блока SIMULATION;

<Продолжение операторов блока, охватывающего программу модели.>

end СИМУЛА-программы

Замечание.

Программа модели (блок SIMULATION begin . . . end) может охватываться несколькими блоками, а может и начинать программу, т.е. не охватываться другими блоками, если в этом нет необходимости.

Процесс "главная программа" имеет две особенности:

1) его первая активная фаза исполняется в нулевой момент системного времени, причем планирование этой фазы обеспечивается не пользователем , а операторами системного класса SIMULATION, выполняемыми при проходе управления через конструкцию SIMULATION begin;

2) атрибуты главной программы непосредственно доступны из всех процессов и других объектов, определенных в блоке с префиксом

SIMULATION.

В остальном главная программа ведет себя точно так же, как и другие процессы модели, в частности, исполнение ее правил действий может быть задержано с помощью оператора HOLD, главную программу можно перевести в пассивное состояние, а затем запланировать возобновление ее работы операторами activate или reactivate и т.д. На главную программу можно сослаться с помощью функции main.

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

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

Операторы СИМУЛА-программы, выполняемые после окончания моделирования, могут повторно передавать управление блоку с префиксом SIMULATION, обеспечивая тем самым многократный прогон модели для различных значений глобальных переменных. Иными словами, программа моделирования может быть составной частью СИМУЛА-программы и взаимодействовать с ней через глобальные переменные, массивы, процедуры, наборы данных и т.д., определяющие условия проведения имитационных экспериментов с моделью. В программе может присутствовать несколько блоков с префиксом SIMULATION, описывающих разные модели, которые могут взаимно использовать результаты работы друг друга.

Рассмотрим конкретный пример, иллюстрирующий структуру имитационной модели на языке SIMULA, и продемонстрируем на этом примере некоторые варианты организации экспериментов с моделью.
1.3. Организация имитационных экспериментов
В примере 1 приведены декларации классов CLIENT и КАССИР, описывающие поведение покупателей и правила работы кассиров в магазине самообслуживания. Для того, чтобы получить законченную СИМУЛА-программу, использование которой обеспечит проведение одного или нескольких имитационных экспериментов над моделью магазина, эти декларации классов должны быть охвачены описаниями и операторами, задающими исходные данные для работы модели и условия окончания моделирования и обеспечивающими выдачу его результатов.

Пусть требуется смоделировать работу магазина самообслуживания с одной кассой, нагруженного потоком покупателей, входящих в магазин через случайные промежутки времени, равномерно распределенные в интервале от 3 до 7 мин. Время, затрачиваемое покупателем на покупки, и количество покупок будем также считать случайными величинами, распределенными равномерно в интервалах [10,20] и [4,12] соответственно. Положим, что кассир тратит 30 с на расчет за одну покупку и необходимо смоделировать работу магазина в течение 8 часов.

В примере 4 приведена законченная СИМУЛА-программа, обеспечивающая моделирование работы магазина в течение 8 ч и выдающая в качестве результата интересующие нас характеристики работы магазина, а именно:

  • общего количества обслуженных покупателей;

  • среднего времени пребывания покупателя в очереди к кассе;

  • загрузки кассира (доли времени, в течение которого кассир непосредственно занят проведением расчета с покупателями).


Предполагается, что единица системного времени соответствует 1 мин работы магазина. Тела деклараций классов те же, что и в примере 1 и 2.

Пример 4.
1.begin real ТМ;

2. ТМ:=480;

3.SIMULATION begin ref (KASSA) КАССА; ref (HEAD) QC;

  1. integer Ncls; real WTT;

5. PROCESS class KASSA (Cр);...;

6. PROCESS class CLIENT (Тр,Кр);...;

7. PROCESS class GENERATOR;...;

8. QC:-new HEAD;

9. КАССА:-new KASSA (0.5);

10. activate new GENERATOR delay 0;activate КАССА delay 0;

11. HOLD(ТМ);

12. outtext ("Загрузка кассира=''); outfix ((TM- КАССА.TW)/TM,2,10);

13. outtext (" Обслужено покупателей ''); outint(Ncls,8);

14. outtext (" Среднее время в очереди ''); outfix (TWT/Ncls,2,10);

15. end моdel;

16. end program

Рассмотрим назначение каждой строки приведенной программы.

Строка 1. Начало самого внешнего блока программы. Описываются глобальная переменная ТМ, определяющая интервал системного времени, в течение которого будет работать модель.

Строка 2. Задание конкретного значения переменной ТМ.

Строка 3. Начало блока с префиксом SIMULATION, содержащего описание модели. Описываются ссылочные переменные КАССА и QC для обозначения процесса, отображающего кассира, и набора, отображающего очередь покупателей.

Строка 4. Описание переменных, хранящих значения общего количества обслуженных покупателей (Ncls) и суммарного времени пребывания покупателей в очереди к кассе (WTT).

Строка 5 - 7. Декларация классов KASSA, CLIENT, GENERATOR (см. примеры 1 и 2).

Строка 8. Создание головы набора QC.

Строка 9. Создание процесса класса KASSA с временем расчета за одну покупку, равным 0.5 мин (атрибут Ср в декларации класса КАССИР). Присваивание созданному процессу имени КАССА.

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

Строка 11. Задержка дальнейшего исполнения главной программы на время ТМ. Центральное управление переходит на процесс класса GENERATOR, а локальное управление главной программы устанавливается на строку 12. Теперь работа программы вплоть до момента времени ТМ будет состоять во взаимодействии процессов, отображающих генератор, покупателей, приходящих в магазин, и кассира, выполняющего расчет с покупателями.

Строки 12 - 14. Вывод результатов моделирования. В результате исполнения приведенных операторов будет напечатана следующая строка:
Загрузка кассира=0.95 Обслужено покупателей 115 Среднее время в очереди 4.50
Строка 15. Конец блока с префиксом SIMULATION. При выходе управления через этот символ end моделирование прекращается независимо от того, есть в управляющем списке уведомления о запланированных, но еще не исполненных событиях, или их нет.

Строка 16. Конец СИМУЛА-программы, возврат управления в операционную систему.

В примере 4. был рассмотрен самый простой случай организации имитационного эксперимента: однократный прогон модели с определенными значениями параметров модели и с заданным временем моделирования. Богатые алгоритмические возможности языка SIMULA позволяют задавать любые условия проведения имитационных экспериментов. Ниже рассматриваются некоторые варианты организации многократных прогонов модели магазина самообслуживания.

Пусть требуется исследовать работу магазина при различных значениях времени, затрачиваемого кассиром на оформление одной покупки, сделанной покупателем. Эксперименты с моделью удобно выполнять, если исходные данные задаются не в тексте программы, а вводятся в процессе ее работы, что позволяет не производить каждый раз трансляцию программы (при условии, что она записана в архив вычислительной системы). Допустим, что нужно промоделировать 8 ч работы магазина при значениях скорости работы кассира от Cpmin мин на покупку до Cpmax с шагом изменения параметра DC. Для этого в программу примера 4 достаточно

внести следующие изменения:

- дополнить описания самого внешнего блока программы, добавив

после строки 1 строку 1.1:

1.1 real Cpmin, Cpmax, DC, CT;

- ввести значения параметров CMIN, CMAX, DC:

1.2. CMIN:= INREAL; CMAX:=INREAL; DC:=INREAL;

- внести блок с префиксом SIMULATION в тело цикла:

3.1. for CT:=CMIN step DC 'until' CMAX do

3.2. begin OUTTEXT ("ВРЕМЯ ОПЛАТЫ ПОКУПКИ="); OUTFIX (CT,2,6);

SIMULATION begin .... end model;

13.1. end of cycle

- изменить фактический параметр при генерации процесса класса

KASSA, т.е. строку 9 а примере 3 заменить на

9. КАССА :-new KASSA(СТ);

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

В качестве условия окончания моделирования можно задавать не только истечение некоторого интервала системного времени, но и достижение заданных ситуаций или определенных условий при работе модели. Пусть, например, моделирование работы магазина (пример 4) требуется проводить до тех пор, пока количество обслуженных покупателей не превысит 600 мин или пока не закончится время ТМ. Для этого достаточно предусмотреть активацию главной программы в момент достижения заданного условия. Напомним, что сослаться на процесс "главная программа" в можно с помощью встроенной функции main.

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

if Ncls>600 then reactivate main;

который немедленно запустит в работу главную программу, начиная со строки 12 (см. пример 4), обеспечивающей выдачу результатов моделирования. Чтобы узнать момент системного времени, в который было прекращено моделирование, после строки 14 можно поместить оператор вывода

14.1. outfix (time,2,10);

который выведет интересующее значение системного времени.

Если за время ТМ общее количество обслуженных покупателей не превысит 600 , процесс главная программа автоматически станет активным через ТМ единиц системного времени после начала моделирования, поскольку его первая активная фаза закончилась исполнением оператора HOLD (ТМ) (строка 11 в примере 4).

Одна СИМУЛА-программа может содержать несколько моделей, взаимодействующих друг с другом через глобальные переменные и наборы данных. В примере 5 приведена возможная структура СИМУЛА-программы, в которой результаты работы одной модели используются как исходные данные для другой.

Пример 5.

begin real P,C;

<вычисление значения параметра Р>;

SIMULATION begin

<Описание модели 1, зависящее от параметра Р.

Результатом моделирования служит значение параметра С>;

end модели 1;

SIMULATION begin

<Описание модели 2, зависящее от параметра С>;

end модели 2;

end программы

Достаточно мощные алгоритмические средства языка simula позволяют непосредственно использовать имитационные модели при решении задач оптимизации сложных систем в тех случаях, когда вычисление целевой функции, оценивающей качество системы, может быть наиболее эффективно проведено в процессе имитации ее работы в течение некоторого времени. Один из вариантов структуры СИМУЛА-программы, выполняющей поиск оптимального значения параметра Р для системы S, при котором достигается экстремум целевой функции F(P), приведен в примере 6.

Пример 6.

begin real P;

<Вычисление начального значения параметра Р>;

МОDEL: SIMULATION begin

<Описание имитационной модели системы S. В ходе моделирования определяется значение целевой функции F(P) для текущего значения Р>;

end мodel S;

<Оценка полученного значения F(P)>;

if <экстремум F(P) не достигнут> then

begin <Вычисление очередного приближения для P>;

goto МОDEL

end;

<Вывод оптимального значения Р>

end optimizaton program

2. Лабораторная работа № 1

«Разработка имитационной модели системы управления запасами»
Целью данной лабораторной работы является знакомство с системой программирования PC SIMULA путем написания и отладки симула-программы имитационной модели системы управления запасами.

Для выполнения работы необходимо:

  1. Ознакомиться с описанием моделируемой системы и уяснить постановку задачи по определению характеристик работы системы

следующая страница >>