Подход сканирования активностей
При использовании подхода сканирования активностей разработчик описывает действия, в которых принимают участие элементы системы, и задает условия, определяющие начало и окончание этих действий. События, которые начинают или завершают действие, не планируются разработчиком модели, а инициируются по условиям, определенным по данным действиям. Условия начала или окончания действия проверяются (сканируются) после очередного продвижения имитационного времени. Если заданные условия удовлетворяются, происходит соответствующее действие. Для того чтобы было выполнено каждое действие в модели, сканирование условий производится для всего множества действий при каждом продвижении имитационного времени.
Подход сканирования активностей обеспечивает простую схему моделирования для решения целого ряда проблем. Он наиболее эффективен для ситуаций, в которых продолжительность действия определяется в зависимости от того, насколько состояние системы удовлетворяет заданным условиям. Тем не менее, так как необходимо сканировать условия для каждого действия, подход сканирования активностей менее эффективен по сравнению с событийным подходом и поэтому имеет ограниченное применение в дискретной имитации.
Операторная схема для нашего примера модели сканирования активностей имеет вид:
Действие 1:
Условие начала: ПАРИКМАХЕР “СВОБОДЕН” И ЧИСЛО КЛИЕНТОВ В ОЧЕРЕДИ БОЛЬШЕ НУЛЯ
Выполнить: УМЕНЬШИТЬ ЧИСЛО КЛИЕНТОВ В ОЧЕРЕДИ НА ЕДИНИЦУ;
НА ВРЕМЯ ОБСЛУЖИВАНИЯ ПЕРЕВЕСТИ ПАРИКМАХЕРА В СОСТОЯНИЕ “ЗАНЯТ”
Действие 2:
Условие начала: КЛИЕНТ ПРИБЫЛ
Выполнить: УВЕЛИЧИТЬ ЧИСЛО КЛИЕНТОВ В ОЧЕРЕДИ НА ЕДИНИЦУ;
СГЕНЕРИРОВАТЬ ПРИХОД СЛЕДУЮЩЕГО КЛИЕНТА ЧЕРЕЗ Т ЕДИНИЦ ВРЕМЕНИ.
В этой модели первое действие происходит всякий раз, когда освобождается парикмахер и имеется клиент в очереди (в том числе только что пришедший и еще не ждавший в очереди). Действие сводится к занятию парикмахера на время обслуживания и уменьшению очереди. Второе действие происходит всякий раз, когда проходит время между приходами клиентов. Его следствием является мгновенное увеличение очереди на одного ждущего клиента.
Блок-схема процесса имитации при использовании сканирования активностей следующая (Рис.9):
Рис.9. Блок-схема реализации подхода сканирования активностей
Процессно-ориентированный подход
Имитационные модели содержат последовательности компонентов, которые возникают в них по определенной схеме, например очередь, в которой клиенты ожидают обслуживания. Логика возникновения компонентов по требуемой схеме может быть обобщена и задана в одном операторе. Имитационный язык затем транслирует такие операторы в последовательность событий, происходящих с компонентами системы.
Имитационные языки, включающие операторы для моделирования процесса прохождения элементов через систему, обычно называются процессно-ориентированными. Эти операторы определяют последовательность событий, которые автоматически выполняются имитационным языком, по мере того, как элементы продвигаются через систему. Например, следующий набор операторов может быть использован для описания процесса в модели парикмахерской:
СОЗДАВАТЬ ПРИБЫВАЮЩИХ КЛИЕНТОВ ЧЕРЕЗ КАЖДЫЕ Т ЕДИНИЦ ВРЕМЕНИ;
ОЖИДАТЬ ПАРИКМАХЕРА;
ПРОДВИНУТЬ ВРЕМЯ НА ПРОДОЛЖИТЕЛЬНОСТЬ ОБСЛУЖИВАНИЯ;
ОСВОБОДИТЬ ПАРИКМАХЕРА;
УДАЛИТЬ КЛИЕНТА.
Первый оператор генерирует прибывающих в систему клиентов через каждые Т единиц имитационного времени. Величина Т может быть константой или принимать случайные значения. Оператор “ожидать” определяет, что клиент ожидает до тех пор, пока кассир освободится. Этот тип оператора аналогичен понятию действия по условию, применяемого в подходе сканирования активностей и т.д.
Из приведенного примера видно, что процессно-ориентированный подход сочетает в себе черты событийного подхода и подхода сканирования активностей. Он обеспечивает описание прохождения компонентов через процесс, содержащий ресурсы. Простота этого подхода состоит в том, что определяемая операторами логика событий заложена в самом имитационном языке. Однако так как мы обычно вынуждены ограничивать набор стандартных операторов языка, этот подход является менее гибким, чем событийный. Кроме того, требуется постоянный анализ состояния ресурсов после их использования.