Имитационное моделирование

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

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

Одним из наиболее эффективных инструментов имитационного модели-
рования является система Arena фирмы System Modeling Corporation
(http: //www. sm. com). Arena позволяет строить имитационные модели, проигры-
вать их и анализировать результаты такого проигрывания. Имитационное моде-
лирование - это универсальное средство для оптимизации процессов, поэтому
модели с помощью Arena могут быть построены для самых разных сфер дея-
тельности - производственных технологических операций, складского учета,
банковской деятельности, обслуживания клиентов в ресторане и т. д. и т. п.
В настоящей книге описана версия Arena BE 3. 6. 1.

Имитационная модель Arena включает следующие основные элементы:
источники и стоки (Create и Dispose), процессы (Process) и очереди (Queue).
Источники - это элементы, от которых в модель поступает информация или
объекты. Скорость поступления данных или объектов от источника обычно
задается статистической функцией. Сток - это устройство для приема ин-
формации или объектов. Понятие очереди близко к понятию хранилища
данных - это место, где объекты ожидают обработки. Времена обработки
объектов (производительность) в разных процессах могут быть разными.
В результате перед некоторыми процессами могут накапливаться объекты,
ожидающие своей очереди. Часто целью имитационного моделирования яв-
ляется минимизация количества объектов в очередях. Тип очереди в имита-
ционной модели может быть конкретизирован. Очередь может быть похожа
на стек - пришедшие последними в очередь объекты первыми отправляются
на дальнейшую обработку (LIFO: last-in-first-out). Альтернативой стеку
может быть последовательная обработка, когда первыми на дальнейшую
обработку отправляются объекты, пришедшие первыми (FIFO: first-in-first-
out). Могут быть заданы и более сложные алгоритмы обработки очереди.
Процессы - это аналог работ в функциональной модели. В имитационной
модели может быть задана производительность процессов.

Простейшая имитационная модель, созданная в Arena, показана
на рис. 1. 4. 40.

Для построения моделей Arena имеет на-
бор средств, которые включают палитру ин-
струментов, набор гидов и др. Для создания
модели сначала нужно щелкнуть по кнопке
New на панели инструментов. Слева появля-
ется палитра инструментов (рис. 1. 4. 41), кото-
рая содержит два типа модулей.

Модули типа Flowchart (в том числе Create,
Dispose и Process) служат для отображения
потоков объектов и могут быть перенесены на
рабочее пространство модели drag & drop.
Модули типа Data (например, Queue) не могут
быть размещены в рабочем пространстве мо-
дели и служат для настройки параметров мо-
дели. Окно редактирования параметров появ-
ляется в нижней части модели, когда фокус
установлен на модуле типа Data.

Перенесем из панели инструментов в рабочее пространство модели
по одному модулю Create, Dispose и Process. Связи между модулями уста-
навливаются автоматически (хотя могут быть и переопределены вручную).
Модуль Create является источником сущностей в системе. Так, например,
если описывается изготовление изделий, то модуль Create может описывать
поступление заготовок на конвейер. Модуль Process отвечает за обработку
сущностей. Например, он может имитировать станок, обрабатывающий за-
готовки. Модуль Dispose является стоком сущностей из системы. Он может
моделировать снятие готовых изделий с конвейера.

Для задания свойств модулю типа Flowchart необходимо дважды щелк-
нуть по нему и в появившемся диалоге задать значения параметров. Для за-
дания свойств модулю Resourse (типа Data) необходимо щелкнуть по нему
один раз на панели инструментов и в нижнее окно внести значения пара-
метров (например, Busy/Hour = 15, Idle/Hour = 15 и Per Use = 2. 5).
Для контроля проигрывания модели необходимо внести в модель модуль
Simulate и задать параметры этого модуля (например, Run Length = 40,
Hours/Day = 8).

Для проигрывания модели необходимо перейти в меню Run/Go. После
проигрывания модели автоматически генерируются отчеты в формате
Crystal Reports (рис. 1. 4. 42).

Модель в Arena может быть гораздо более сложной, чем представленная
на рис. 1. 4. 40. Она может включать сотни модулей различных типов. Моду-
ли, обрабатывающие сущности (подобные модулю Server из примера), мо-
гут иметь различные состояния, например "ожидание" или "работа". Каж-
дому состоянию можно поставить в соответствие определенное изобра-
жение и тем самым анимировать имитационную модель. В поставку Arena
входит набор примеров. Один из примеров (файл Mortgage Extention 1. doe)
приведен на рис. 1. 4. 43.

Модель показывает систему обработки документа (закладной). Сначала
документ регистрирует секретарша (иконка слева в нижней части рисунка,
затем просматривает клерк (иконка справа). Затем клерк либо принимает
документ, либо возвращает. Очередь документов показывается в виде набо-
ра иконок сверху от процесса Review Application и в виде графика в правой
нижней части рисунка. Иконки, отображающие секретаря и клерка, могут
быть разными в зависимости от состояния (занят - ожидает), следовательно,
модель может быть анимирована.

Создавать имитационные модели без предварительного анализа бизнес-
процессов не всегда представляется возможным. Действительно, не поняв
сути бизнес-процессов предприятия, бессмысленно пытаться оптимизиро-
вать конкретные технологические процессы. Поэтому функциональные мо-
дели и имитационные модели не заменяют, а дополняют друг друга, при
этом они могут быть тесно взаимосвязаны. Имитационная модель дает боль-
ше информации для анализа системы; в свою очередь, результаты такого
анализа могут стать причиной модификации модели процессов. Наиболее
целесообразно сначала создать функциональную модель, а затем на ее осно-
ве строить имитационную модель. Для поддержки такой технологии инст-
рументальное средство функционального моделирования BPwin 4. 1 имеет
возможность преобразования диаграмм IDEF3 в имитационную модель
Arena (версии 3. 6 и выше). Для преобразования диаграммы IDEF3 в модель
Arena необходимо, чтобы BPwin 4. 1 и Arena одновременно были запущены.
В BPwin 4. 1 следует открыть диаграмму IDEF3 и затем выбрать меню
File/Export/Arena. Далее экспорт производится автоматически.

Поскольку имитационная модель имеет гораздо больше параметров,
чем диаграмма IDEF3, в BPwin 4. 1 имеется возможность задать эти пара-
метры с помощью свойств, определяемых пользователем (UDP). В поставку
BPwin 4. 1 входят примеры моделей с предварительно внесенными UDP для
экспорта в Arena (каталог Program Files/Computer Associates/BPwin 4. 1
/Samples/Arena/) и модель ArenaBEUDPs. bp1, в которой определены все не-
обходимые для экспорта UDP и которую можно использовать в качестве
шаблона для создания новых моделей. В том же каталоге находится файл
BPwin IDEF3 to Arena BE mappings. doc, содержащий описание UDP, необ-
ходимых для построения имитационной модели.

На рис. 1. 4. 44 показан пример функциональной модели, а на рис. 1. 4. 45 -
результат экспорта этой модели в Arena.

К сожалению, поставляемые с BPwin примеры после экспорта в Arena
не могут быть сразу же "проиграны". В свойствах модели содержатся ошиб-
ки. Arena не допускает использования символа & в названии работы и в ка-
честве разделителя дробной части для действительных чисел используется
не запятая, а точка. Ресурсы объектов модели могут быть исправлены
с помощью диалога Resource (рис. 1. 4. 46), после чего успешно "проиграны".

Совместное использование CASE-инструмента построения функци-
ональной модели BPwin и системы имитационного моделирования Arena
позволяет наиболее эффективно оптимизировать технологические процессы
практически в любой сфере деятельности.

1. 5. Использование обучающего
модуля BPwin

Для вызова обучающей программы в BPwin следует перейти в меню
Help/BPwin online Tutorial. Появляется диалог BPwin Tutorial (рис. 1. 5. 1),
в котором можно выбрать один из 10 уроков.

Уроки представляют собой последовательное изложение материала как
по методологии построения моделей (рис. 1. 5. 2) и нотациям IDEF0, IDEF3
и DFD, так и по технике работы с BPwin (рис. 1. 5. 3).

Глава 2

Создание модели данных с помощью
AllFusion ERwin Data Modeler 4. 1