close

Вход

Забыли?

вход по аккаунту

- MvStudium

код для вставкиСкачать
Ю. Колесов
Объектно-ориентированное моделирование систем
массового обслуживания
с помощью Rand Model Designer 7
Москва, 2014
Rand Model Designer (RMD) – это система визуального объектно-ориентированного моделирования непрерывных, дискретных и гибридных систем, ориентированная на парадигму языка UML. В RMD поддерживаются компонентные модели с направленными связями («блочное моделирование») и с ненаправленными
связями («физическое моделирование»). RMD работает на компьютерах платформы Intel в среде MS Windows. Основным отличием версии 7 является поддержка компонентных моделей с динамической структурой. Пользователь может создать динамический объект с помощью конструктора new и уничтожить с помощью процедуры destroy, а также создать динамическую связь с помощью процедуры connect и уничтожить ее с помощью процедуры disconnect. Ведены также переменные объектного типа, значением которых являются ссылки на объекты – статические или динамические. Ссылки можно присваивать, хранить в
массивах и списках и т.д.
Основным элементом входного языка RMD является активный динамический объект – расширение динамического объекта UML, в котором поведение может задаваться не только машиной состояний, но и системой обыкновенных дифференциально-алгебраических уравнений в произвольной форме (возможно, не
разрешенных относительно первых и вторых производных). Для описания поведения дискретных и гибридных объектов используется карта поведения – модификация диаграммы состояний UML, в которой
деятельностью в состоянии является активный динамический объект, возможно, имеющий свою внутреннюю структуру. Объект-деятельность может функционировать как во времени объекта-контейнера, так и в
«ортогональном» времени, когда его локальное функционирование произвольной длительности является
мгновенным для объекта-контейнера.
RMD создает выполняемую модель как независимый программный модуль – DLL. Для проведения интерактивной визуальной работы с моделью и отладки выполняемая модель запускается под управлением
специального интерактивного отладчика, имеющего мощные средства визуальной интерактивной отладки
и демонстрации результатов. Поддерживаются типовые вычислительные эксперименты – построение параметрической зависимости, определение математического ожидания и дисперсии значений переменных,
определение вероятности дискретного события, определение глобальной чувствительности. Выполняемая
модель может быть встроена во внешнее приложение, которое взаимодействует с ней через специальный
API.
Таким образом, RMD 7 является уникальным инструментом моделирования, который позволяет строить,
например, мультиагентные модели с ненаправленными связями.
В данном пособии рассматривается несколько примеров типовых моделей систем массового обслуживания: модель турникета, модель банковского офиса и модель управления запасами. Заметим, что это имитационные модели. Мы не рассматриваем вопроса, не сводятся ли решаемые задачи к какой-нибудь хорошо известной математической модели – например, к цепям Маркова. Априорно предполагается, что
пользователь решил решить задачу именно с помощью имитационного моделирования. Все эти модели
разработаны с использованием динамических объектов. Для лучшего понимания читателем принципов
объектно-ориентированного моделирования этого вида систем мы сначала будем строить эти модели, используя соответствующие стандартные классы, а затем рассмотрим, как работают эти стандартные объекты.
1
Модель турникета.
Пусть зрители подходят к турникету футбольного стадиона через интервал времени, распределенный согласно экспоненциальному закону со средним значением 7 секунд и встают в очередь, в которой находятся до тех пор, пока не пройдут на стадион. Проход через турникет занимает время,
распределенное по треугольному распределению со средним значением 5 секунд и минимальным
и максимальным значениями 2 и 8 секунд соответственно. Максимальная длина очереди к турникету – 10 человек. Предполагается, что в случае максимальной длины очереди зритель переходит к
другому турникету. Требуется определить время, необходимое для того, чтобы через турникет
прошло 300 человек.
Любая модель системы массового обслуживания включает в себя модель транзакции, модель генератора трансакций, модель очереди транзакций, модель обслуживания трансакций и модель
уничтожения трансакций. Эти модели реализованы как классы Transaction, Source, Queue, Servicer
и Sink в пакете QueueSystems.
Создадим новый проект Turnstile, задав тип модели «Объект общего вида» и добавим пакет
QueueSystems в список импортируемых пакетов. Затем, перетаскивая мышкой нужные классы из
пакета QueueSystems на страничку «Структура» класса Model, создадим необходимые объекты экземпляры этих классов. Добавив необходимые связи между этими объектами, получим схему,
показанную на Рис. 1
Рис. 1 Структурная схема модели турникета
Для соответствия условиям задачи необходимо установить действительные значения параметров
для объектов source и queue. Параметру source.T (среднее время генерации заявок) нужно присво2
ить значение 7. Параметру source.CServTime (параметры треугольного закона распределения времени обслуживания) нужно присвоить значение записи {Vmin=>2, Vmean=>5, Vmax=>8}. Параметру queue.Capacity (максимальная длина очереди) нужно присвоить значение 10. Объект sink
соответствует «стоку» обслуженных клиентов (прошедших через турникет зрителей), а объект
sink1 – «стоку» отвергнутых клиентов (зрителей, перешедших к другому турникету).
В самой модели (классе Model) добавляем параметр N – число зрителей, которые должны пройти
через турникет, и переменную T_N – время, за которое N зрителей проходят через турникет. Работа модели должна завершиться, когда значение переменной sink.Count станет равным N. Это обеспечивается срабатыванием перехода в карте поведения класса Model (Рис. 2) из состояния S1 в конечное состояние. В действиях этого перехода вычисляется значение T_N.
Рис. 2 Карта поведения модели турникета
Запустим визуальную модель (Рис. 3). Для удобства создадим виртуальную переменную (не заданную в самой модели, а определенную в окне визуальной модели для удобства отладки) T_N_m
– время прохода N зрителей в минутах.
3
Рис. 3 Визуальная модель турникета
Из результатов прогона модели видно, что 300 человек пройдут через турникет за 33.8 минуты,
среднее время ожидания в очереди 7.6 секунды, максимальное время ожидания 41.8 секунды, максимальная длина очереди 9 человек, коэффициент использования турникета 0.74. Значит ли это,
что задача решена? Конечно нет. Эти значения получены в результате одного прогона модели и
сами являются случайными. Если кнопкой «Рестарт» вернуть модель в исходное состояние и снова запустить, то последовательность значений случайных факторов будет другой и получатся несколько иные результаты. Этот вид моделирования и называется имитационным, поскольку мы
имитируем на компьютерной модели реальный эксперимент: пользователь может сидеть около
реального турникета с секундомером и засекать время прохода 300 человек. Поэтому данные имитационного эксперимента требуют такой же статистической обработки, как и данные реального
эксперимента.
Попробуем оценить вероятностные характеристики значения переменной T_N. С помощью команды меню «Моделирование / Типовой вычислительный эксперимент / Мат. ожидание значения
переменной…» перейдем в окно соответствующего вычислительного эксперимента (Рис. 4).
4
Рис. 4 Окно вычислительного эксперимента для определения математического ожидания и среднеквадратического отклонения величины T_N
Поскольку случайные факторы изначально заложены в функциональность модели, задавать законы распределения случайных параметров в данном случае не нужно. Укажем, что значение T_N
замеряется в конце прогона модели с доверительным интервалом плюс-минус 10 секунд и зададим
доверительную вероятность 0.95. Для заданной точности потребовалось 517 испытаний (прогонов
модели), чтобы определить значение математического ожидания и среднеквадратического отклонения времени прохода 300 человек через турникет. Следует правильно трактовать результат эксперимента: с вероятностью 0.95 математическое ожидание времени прохода находится в интервале 2097..2117 секунд. Для больших точностей число требуемых испытаний и соответственно время эксперимента резко возрастет. Таким образом, можно определить предельные значения времени прохода (математическое ожидание плюс-минус три среднеквадратических отклонения) – это
примерно 33-37 минут. Поскольку у нас стоял флажок «Гистограмма», можно посмотреть визуально и вид распределения времени прохода (Рис. 5).
5
Рис. 5 Гистограмма времени прохода через турникет
Попробуем теперь решить обратную задачу: определить, с какой вероятностью 300 человек пройдут турникет за 35 минут. С помощью команды меню «Моделирование / Типовой вычислительный
эксперимент / Вероятность события…» перейдем в окно оценки вероятности события (Рис. 6).
Рис. 6 Окно вычислительного эксперимента для определения вероятности прохода 300 человек через турникет за 35 минут
6
Событием будет выполнение условия «T_N<=2100» в конце работы модели. Оказалось, что необходимо провести 385 испытаний, чтобы определить, что с вероятностью 0.95 вероятность прохода
300 человек через турникет за 35 минут находится в диапазоне 0.46..0.56 (была задана абсолютная
погрешность 0.05).
Интересно оценить характер зависимости времени прохода от числа зрителей. С помощью команды меню «Моделирование / Типовой вычислительный эксперимент / Параметрическая зависимость…» перейдем в окно построения параметрической зависимости (Рис. 7а). Построим зависимость величины T_N от параметра N, который будет меняться в диапазоне 100..500 с шагом 100.
Результат показан на Рис. 7б. С учетом случайных разбросов величины T_N искомая зависимость
скорее всего близка к линейной.
а)
б)
7
Рис. 7 Зависимость времени прохода через турникет от числа зрителей
Как работают стандартные классы
В принципе, как было показано выше, желаемые результаты при исследовании систем массового
обслуживания методом имитационного моделирования можно получить и при «слепом» использовании стандартных компонентов. Однако, для «моделистов» крайне желательно знать хотя бы в
общих чертах, как работают эти компоненты. Это обусловлено как минимум двумя причинами:
• помогает правильно оценить адекватность применения стандартного подхода к конкретной
задаче и границы применимости полученных результатов;
• для задач, отличающихся от стандартных, помогает создать потомки стандартных классов,
отражающие особенности этих задач.
Например, далее мы рассмотрим модификацию рассмотренной задачи, отличающуюся учетом нового фактора: пусть каждый 10-й зритель, проходящий через турникет, оказывается «неуклюжим»
и время его прохода в два раза больше стандартного случайного. Это сродни учету редких неблагоприятных событий, то есть учету рисков.
Класс Transaction
Класс Transaction определяет абстрактную трансакцию и содержит атрибуты, необходимые для
определения времени ожидания и обслуживания конкретной трансакции, параметры распределения времени обслуживания, а также public-функцию servicingTime, возвращающую значение времени обслуживания данной трансакции.
Рис. 8 Определение класса Transaction
8
Класс Source
Объект класса Source генерирует трансакции (экземпляры класса Transaction) через интервалы
времени, распределенные по экспоненциальному закону со средним временем T: в действиях перехода, срабатывающего через случайное значение времени, создается новый экземпляр класса
Transaction с присвоением значения параметрам времени обслуживания и посылается выходной
сигнал NewTransaction с этим экземпляром в качестве параметра (Рис. 9).
Рис. 9 Карта поведения класса Source
Класс Queue
Объект класса Queue реализует очередь типа «Первым пришел – первым ушел» (FIFO) максимальной длины Capacity.
По входному сигналу NewTransaction его параметр – объект класса Transaction – либо заносится в
очередь последним, либо, если очередь уже имеет максимальную длину, передается в качестве параметра выходного сигнала DenialOfService (Рис. 10).
9
Рис. 10 Карта поведения класса Queue
Выборка трансакций из очереди осуществляется через коннектор Outlet типа TQueueOutlet.
type TQueueOutlet is
connector
output QSize: integer;
input GetTransaction: signal;
output NewTransaction: signal (X: Transaction);
end connector;
Текущий размер очереди передается через выход Outlet.QSize. По внешнему запросу - входному
сигналу Outlet.GetTransaction - из очереди извлекается первая транзакция и передается в качестве
параметра выходного сигнала Outlet.NewTransaction (Рис. 10).
Класс Servicer
Объект класса Servicer имитирует деятельность по обслуживанию трансакций - объектов класса
Transaction. Получение трансакций для обслуживания осуществляется через коннектор Inlet типа
TServicerInlet, «зеркального» по отношению к типу TQueueOutlet:
type TServiceInlet is
connector
input QSize: integer;
output GetTransaction: signal;
input NewTransaction: signal (X: Transaction);
end connector;
Обслуженные трансакции передаются в качестве параметра выходного сигнала ExitTransaction.
Карта поведения имеет два состояния – SEmpty (объект свободен) и Busy (объект занят обслуживанием транзакции) (Рис. 11). Внутренний переход в состоянии SEmpty (Рис. 12) срабатывает, ко10
гда входная очередь не пуста. В действиях этого перехода посылается сигнал Inlet.GetTransaction –
запрос следующей транзакции.
Рис. 11 Карта поведения класса Servicer
Рис. 12 Внутренний переход в состоянии SEmpty
По сигналу Inlet.NewTransaction объект переходит в состояние Busy, обслуживаемая трансакция –
параметр сигнала – запоминается в переменной CTransaction типа Transaction, с помощью вызова
функции servicingTime объекта, на который ссылается эта переменная, определяется конкретное
время обслуживания и в атрибуте t0 обслуживаемой трансакции запоминается время начала его
обслуживания. По истечении времени обслуживания вычисляются среднее время обслуживания и
коэффициент загрузки сервиса, далее обслуженный клиент передается как параметр выходного
сигнала ExitTransaction и объект возвращается в состояние Empty (Рис. 11).
Класс Sink
Объект класса Sink реализует «сток», в котором поступающие посредством сигнала NewTransaction транзакции уничтожаются (Рис. 13).
11
Рис. 13 Карта поведения класса Sink
Модифицируем стандартные классы
Попробуем сделать вариант модели, который учитывал бы «неуклюжих» зрителей.
Сохраним проект Turnstile под именем Turnstile1. Создадим в нем новый класс MySource – потомок QueueSystems.Source (Рис. 14).
Рис. 14 Карта поведения класса MySource
Добавим два параметра: pSC – вероятность того, что новый клиент будет особым, и K – коэффи12
циент увеличения времени обслуживания особого клиента. Переопределим действия унаследованного перехода, выделенного на Рис. 14. Теперь при появлении нового клиента разыгрывается случайное событие «Special Transaction» и, если оно происходит, время обслуживания увеличивается
в K раз и на единицу увеличивается значение счетчика особых клиентов N_SC.
В структурной схеме модели вместо заменим объект source на экземпляр класса MySource и зададим pSC=0.1 (примерно каждый десятый клиент особый) и K=3 (Рис. 15). Запустим визуальную
модель – время прохода стало несколько больше.
Рис. 15 Структурная схема модифицированной модели турникета
13
Модель банковского офиса
Пусть в отделении банка работает 4-8 операционистов и время обслуживания клиентов имеет треугольное распределение с минимальным средним значением 2.5, средним – 6 и максимальным –
11 минут. Пусть интервал между приходом клиентов в офис распределен экспоненциально со
средним значением, равным 1.5 минуты, а максимальная длина очереди составляет 15 человек
(при такой длине появившиеся клиенты не встают в очередь, а уходят). Требуется найти такое
число операционистов, при котором достигается разумный компромисс между коэффициентом их
загрузки, средней длиной очереди и числом ушедших клиентов. Измерения следует проводить для
10 часов непрерывной работы офиса.
Создадим проект BankOffice, импортируем в него пакет QueueSystems и соберем из стандартных
классов схему, показанную на Рис. 16. Эта схема очень похода на модель турникета, но вместо
класса Servicer в ней использован класс ServicePool, который моделирует работу N параллельных
сервисов. Зададим нужные параметры объекту source (за единицу модельного времени примем
минуту) и присвоим параметру N объекта tellers значение 4.
Рис. 16 Структурная схема модели банковского офиса
В карте поведения модели добавим переход в конечное состояние через 10 часов (600 минут), в
действиях которого вычисляется коэффициент загрузки операционистов путем вызова соответствующей public-функции объекта tellers (Рис. 17).
14
Рис. 17 Карта поведения модели банковского офиса
Запустим модель и проведем вычислительный эксперимент (Рис. 18).
Рис. 18 Результаты эксперимента при N=4
Результаты оказываются не очень хорошими – максимальное время ожидания почти полчаса,
среднее время – 16 минут, 21 клиент ушел, операционисты непрерывно загружены. Попробуем
задать N=6. При этом значении с временем ожидания все хорошо, ушедших клиентов нет, но
слишком низок коэффициент загрузки операционистов – 0.6. Проведем эксперимент с N=5. Похоже, это и есть разумный компромисс: ушедших клиентов нет, среднее время ожидания 3 минуты,
среднее – менее минуты и коэффициент загрузки 0.7.
15
Напоминаем: все эти цифры случайные, при повторных запусках они будут другими, на другом
компьютере они будут другими. Для принятия окончательного решения нужно оценить значение
математического ожидания этих величин.
Рассмотрим теперь как работает объект класса ServicePool.
Класс ServicePool
Объект класса ServicePool представляет собой контейнер, содержащий массив объектов класса
Service1, которые, собственно, и выполняют обслуживание конкретного клиента. Объект класса
Service1 начинает обслуживание клиента по входному сигналу NewTransaction (обслуживаемый
клиент передается как параметр этого сигнала) и по окончании обслуживания посылает широковещательный сигнал ServedTransaction с обслуженным клиентом в качестве параметра (Рис. 19).
Занятость объекта обслуживанием клиента индицируется выходом isEmpty.
Рис. 19 Определение класса Service1
Объект класса ServicePool при наличии непустой входной очереди и хотя бы одного свободного
обработчика клиентов забирает очередного клиента из очереди и передает его на обработку любому свободному обработчику с помощью посылки соответствующего сигнала (Рис. 20, Рис. 21).
При этом счетчик свободных обработчиков уменьшается на единицу. Получив сигнал ServedTransaction от какого-либо обработчика, объект передает обслуженного клиента на выход. При
этом счетчик свободных обработчиков увеличивается на единицу.
16
Рис. 20 Определение класса ServicePool
Отметим, что переходы, реализующие эту логику (Рис. 21), должны быть внутренними, поскольку
случайно могут выполниться условия срабатывания для нескольких переходов одновременно.
Напомним, что UML позволяет две трактовки такого случая: 1) ошибка; 2) срабатывает только
один из конкурирующих переходов (в RMD принята первая). Внутренние же переходы сработают
все в произвольном порядке, что и требуется в данном случае.
Рис. 21 Внутренние переходы в состоянии Activity
17
Модель управления запасами
Рассмотрим следующую задачу. Компания продает один вид продукции. Промежутки времени
между заказами покупателей на товар являются независимыми и представлены случайными величинами, имеющими одинаковое экспоненциальное распределение, со средним значением 0.1 месяца. Объемы заказов Q также являются независимыми и одинаково распределенными случайными величинами: 1 штука с вероятностью 1/6, 2 штуки с вероятностью 1/3, 3 штуки с вероятностью
1/3, 4 штуки с вероятностью 1/6. В начале каждого месяца компания пересматривает уровень запасов и решает, какое количество товара заказать у оптового поставщика. В случае, когда компания
заказывает Z единиц товара, она будет нести затраты, равные K+k*Z, где K – фиксированная стоимость выполнения заказа, k –затраты на единицу заказанного товара (K=20, k=3). Если Z=0, какие-либо затраты отсутствуют. Время между заказом оптовой партии товара и ее доставкой является случайной величиной, равномерно распределенной между 0.5 и 1 мес. Компания использует
постоянную стратегию управления запасами (Smin,Sr), чтобы определить, какое количество товара
заказывать: q(заказ) = Sr-S, если S<Smin, где S - уровень запасов на начала месяца, Sr- уровень запасов после поступления, Smin- минимальный уровень запаса на складе. Если S>=Smin, то заказывать на склад ничего не надо. При возникновении спроса на товар он немедленно удовлетворяется,
если уровень запасов, по меньшей мере, равен спросу на товар. Если спрос превышает уровень запасов, поставка той части товара, которая превышает спрос над предложением, откладывается и
выполняется при будущих поставках (что приводит к отрицательному уровню запасов). При поступлении заказа товар в первую очередь используется для максимально возможного выполнения
отложенных поставок (если такие имеются); остаток заказа добавляется в запасы. Пусть в нашей
системе затраты h на хранение в месяц составят 1 денежную единицу на единицу товара, имеющегося в (положительных) запасах. Издержки, связанные с отложенными поставками, равны 5 денежных единиц на единицу товара в отложенной поставке за месяц. Предположим, что исходный
уровень запасов равен на складе I(0)=60 ед. и у компании нет неполученных заказов. Смоделируйте работу системы в течении T=120 мес., вычислите средние общие расходы в месяц, чтобы сравнить следующие девять стратегий поставок оптовых партий:
Smin 20 20 20 20
Sr
40 40 40
60 60
40 60 80 100 60 80 100 80 100
Модель в целом
Из постановки задачи видно, что в модели должны функционировать как минимум три параллельных процесса:
• формирование заказов покупателей;
18
• оптовые поставки;
• деятельность компании – выполнение заказов покупателей, формирование заказов оптовых
партий, получение оптовых партий.
Поскольку параллельные процессы могут протекать только в различных объектах, модель в целом
(класс Model) будет иметь следующую структуру (Рис. 22).
Рис. 22 Структурная схема модели
Формирование заказов покупателей имитируется объектом Customers (экземпляр класса CCustomers). Деятельность компании имитируется объектом Seller (экземпляр класса CSeller). Действительные значения параметров Smin и Sr этого объекта равны аналагичным параметрам класса
Model. Оптовые поставки имитируются объектом Wholesaler (экземпляр класса CWholesaler).
Объекты взаимодействуют путем посылки сигналов по связям. Посылка заказа товара или оптовой
партии осуществляется с помощью сигналов Order с параметром Q – количество заказываемого
товара. Прием заказа осуществляется с помощью сигнала OrderReceipt. Пересылка заказанного товара или оптовой партии осуществляется с помощью сигнала SendOn с параметром Q – количество пересылаемого товара. Получение заказанного товара или оптовой партии товара осуществляется с помощью сигнала SecureOrder.
Параметр модели Texp задает время работы системы, для которого оцениваются затраты. По истечении этого времени значение затрат сохраняется в переменной E и модель останавливается (Рис.
23).
19
Рис. 23 Карта поведения класса Model
Формирование заказов покупателей
Карта поведения класса CCustomers показана на Рис. 24.
Рис. 24 Карта поведения класса CCustomers
Начальным состоянием является состояние Waiting. Через случайный интервал времени, распределенный по экспоненциальному закону со средним значением T (параметр) срабатывает переход
в вероятностную точку ветвления. Далее с указанными вероятностями срабатывают альтернативные переходы в состояние Ordering. В действиях альтернативных переходов определяется количество заказываемого товара n. Во входных действиях состояния Ordering посылается выходной
сигнал Order с параметром n и вычисляется общее количество заказанного товара N. Далее срабатывает безусловный переход в исходное состояние Waiting. Все действия по формированию и по20
сылке заказа являются мгновенными.
Оптовые поставки
Поскольку мы создаем модель для нашей конкретной задачи, то для упрощения модели оптовых
поставок можно использовать тот факт, что согласно условиям задачи поставка оптовой партии
всегда выполняется до поступления нового заказа. Поэтому можно задать достаточно простую
карту поведения класса CWholesaler (Рис. 25). При посуплении сигнала OrderReceipt срабатывает
переход из состояния OrderWaiting в состояние FillingOrder, в действиях которого разыгрывается
случайное значение времени выполнения заказа T, равномерно распределеное между значениями
TauMin и TauMax (параметры). По истечении этого времени срабатывает переход в исходное состояние OrderWaiting, в действиях которого посылается сигнал SendOn с параметром – количеством товара в партии – и вычисляется общее количество поставленного товара Q. Пределы применимости такой модели: заказы могут поступать только от одного источника, и интервал между
заказами не может быть меньше TauMax.
Заметим, что если бы мы разрабатывали модель оптового поставщика как библиотечный класс,
используемый в различных моделях, такого допущения мы уже не могли бы сделать, так как в общем случае нужно бы было предусматривать одновременное выполнение нескольких заказов, и
поступивший позже заказ мог быть выполнен раньше.
Рис. 25 Карта поведения класса CWholesaler
Деятельность компании
Карта поведения класса CSeller приведена на Рис. 26 а.
21
а)
б)
Рис. 26 Карта поведения класса CSeller: а) верная, б) неверная
Через интервал T (параметр) при выполнении условия S<Smin срабатывает переход в то же самое
состояние Waiting, в действиях которого посылается выходной сигнал заказа оптовой партии Order со значением параметра Q, равным Sr-S. Заметим, что если условие S<Smin указать в качестве
охраняющего (б), то такой переход сработает только если условие выполнится до истечения интервала T.
Прием заказа и обработка поступления оптовой партии имитируются внутренними переходами в
состоянии Waiting, показанными на Рис. 27.
22
Рис. 27 Внутренние переходы в состоянии Waiting
При поступлении заказа (сигнал OrderReceipt) товара проверяется, есть ли товар на складе и посылается сигнал SendOn с полным или частичным количеством заказанного товара в качестве параметра. Если полностью заказ выполнить невозможно, то увеличивается количество отложенных
поставок товара SD.
При поступлении оптовой партии товара (сигнал SecureOrder) текущее количество товара на складе увеличиваются на величину поступившей партии и затраты увеличиваются соответственно величине партии товара (предполагается, что оплата производится по получении товара). При ненулевых значениях отложенных поставок они по возможности выполняются.
Эти переходы должны быть внутренними, так как при поступлении соответствующих сигналов
текущее состояние должно сохраняться. Если сделать эти переходы внешними из Waiting в Waiting, то после обработки сигналов и повторном входе в состояние отсчет интервала времени для
перехода с условием «after» начнется сначала.
Затраты на хранение товара на складе пропорциональны времени хранения, количеству единиц
товара на складе и размеру отложенных поставок. RMD 7 позволяет вычислить их самым простым
способом – приписав состоянию Waiting дифференциальное уравнение – непрерывная деятельность “expense” (Рис. 28). Таким образом, значение переменной E (суммарные затраты) линейно
увеличивается, когда объект Seller находится в состоянии Waiting и меняется скачком в момент
поступления оптовой партии товара. Значения производной меняются скачком в момент поступления оптовой партии товара и возможно в момент получения заказа от покупателя, если величина
SD не нулевая. Таким образом, мы получили гибридную (непрерывно-дискретную) модель.
23
Рис. 28 Дифференциальное уравнение динамики затрат
Вычислительный эксперимент
Создадим визуальную модель и запустим ее. Вы можете открыть нужные окна и наблюдать анимацию работы карт поведения всех объектов модели (Рис. 29). Вы можете выполнять модель по
тактам, задавать условия останова по времени, по срабатыванию переходов, по входу в состояние,
по логическому выражению и т.д. Для наглядности можно использовать 2D и 3D-анимацию (на
Рис. 29 показана 2D-анимация, показывающая значения запасов товара и отложенных поставок в
виде динамических столбиков зеленого и красного цветов). С использованием интерактивных
возможностей вы проводите отладку модели и убеждаетесь в ее правильной работе. Наконец мы
запускаем модель в автоматическом режиме и доходим до конечного состояния.
24
Рис. 29 Визуальная модель
Система моделирования RMD всегда создает модель в виде выполняемого программного модуля
(DLL или EXE), поэтому вычисления выполняются быстро, что важно для стохастических вычислительных экспериментов.
Выполнив прогон модели, мы получим какое-то значение затрат, например, E=14669 единиц. Следует, однако, понимать, что это значение само является случайным. Если вы выполните еще один
прогон модели, то получите немного другое значение и т.д. Для уверенной оценки величины E
нужно определить ее математическое ожидание и среднеквадратическое отклонение.
Это можно сделать с помощью соответствующего типового вычислительного эксперимента RMD.
Задав абсолютную погрешность 50 единиц (ширина доверительного интервала 100) и доверительную вероятность 0.95, получим значения математического ожидания и среднеквадратического отклонения переменной E (Рис. 30). Для заданной точности понадобилось 453 прогона модели.
Установив соответствующий флажок, можно посмотреть и гистограмму распределения.
Рис. 30 Определение математического ожидания значения затрат
Можно также провести типовой вычислительный эксперимент по определению вероятности собы25
тия – того, что затраты не превышают заданного порога. На Рис. 30 показаны результаты вычислительного эксперимента по определению вероятности того, что E<=14800 (с вероятностью 0.95
значение вероятности выполнения этого условия находится в доверительном интервале 0.89..0.91).
Рис. 31 Определение вероятности выполнения условия
Теперь для решения поставленной задачи «сравнить девять стратегий поставок оптовых партий»
необходимо еще восемь раз изменить пары параметров (S_min,S_r) и найти математическое ожидание затрат E.
S_min
S_r
E (матем. ожидание)
20
40
14123 +-50
20
60
13567 +-50
20
80
14034 +-50
20
100
14765 +-50
40
60
13969 +-50
40
80
14382 +-50
40
100
15246 +-50
60
80
16128 +-50
60
100
16546 +-50
26
В принципе, поставленная задача решена. Однако, хотелось бы посмотреть, например, зависимости затрат от S_r для различных значений S_min и т.п. Для него необходимо перевести нахождение математического ожидания E в саму модель.
Модель для определения математического ожидания величины затрат
Сохраним отлаженную модель под другим именем и начнем ее преобразовывать. Сначала сохраним класс Model, который умеет находить одно случайное значение затрат, как независимый глобальный класс InvControl.
Новый класс Model должен уметь находить математическое ожидание затрат с заданной точностью. В пакете Statistics уже имеется «заготовка» такого класса – класс StochasticExp_mx. Этот
класс вычисляет математическое ожидание и среднеквадратическое отклонение некоторой величины «x», однократное случайное значение которой вычисляется соответствующей деятельностью, которая должна выполняться в состоянии «Испытание». Поэтому нам нужно сначала просто
определить класс Model как потомка класса Statistics.StochasticExp_mx (Рис. 32)..
Рис. 32 Класс Model как потомок класса Statistics.StochasticExp_mx
Теперь нужно доопределить класс Model применительно к нашей конкретной задаче (Рис. 33):
• добавить параметры P_Smin, P_Sr;
27
• состоянию «Испытание» приписать в качестве локальной деятельности экземпляр класса
InvControl с соответствующими действительными параметрами и режимом «ортогонального» времени;
• в выходных действиях состояния «Испытание» связать переменную «x» с реальной переменной «Испытание.E»;
• настроить значения унаследованных параметров точности вычисления, указав значения,
которые использовались в типовом эксперименте (Рис. 30): Nmin=40, Q=0.95, epsilon=50
(Рис. 34);
Рис. 33 Доопределенный класс Model
Обратите внимание: деятельность в состоянии «Испытание» выполняется в «ортогональном» времени – время основной модели не меняется, пока вычисляется отдельное значение величины затрат, карта поведения экземпляра класса InvControl выполняется в своем независимом времени.
Таким способом можно строить «эксперименты в эксперименте» любой глубины вложенности.
Рис. 34 Настройка унаследованных параметров
28
Запускаем новую модель и получаем такое же (в пределах заявленной точности) значение затрат
(переменная «mx» в данной модели), что и при выполнении типового эксперимента.
Теперь мы можем сравнить предложенные 9 стратегий без ручных манипуляций с моделью, чреватых ошибками, а с помощью типового вычислительного эксперимента «Расчет вариантов» (Рис.
35).
Рис. 35 Окно вычислительного эксперимента «Расчет вариантов»
Далее построим зависимости затрат от P_Sr при P_Smin=20,30,40 (Рис. 36). Из графиков видно,
что оптимальной является стратегия (P_Smin=30, P_Sr=55), которая отсутствует в предложенном
для анализа перечне.
а)
б)
в)
Рис. 36 Зависимости затрат от P_Sr при P_Smin=20 (а), 30 (б) и 40(в).
29
1/--страниц
Пожаловаться на содержимое документа